view paper/chapter/technology_overview.tex @ 15:d3d797fc378e

update tex
author Ken Miyahira <e175733@ie.u-ryukyu.ac.jp>
date Fri, 15 Jan 2021 14:36:55 +0900
parents 466739d28bc7
children 6e43d7a51315
line wrap: on
line source

\chapter{技術概要}

本章では, 本研究で使われる技術, 本コースで利用しているサービスについて概要を説明する。

\section{仮想化}
仮想化はコンピュータの CPU やメモリ, ディスクなどハードウェアのリソースを分割又は統合して, 
仮想的なコンピュータやネットワーク環境を生成し提供する技術である。
仮想化技術にはホストのどの部分から仮想化するかによってホスト型, ハイパーバイザー型, コンテナ型に分けることができる。

\subsection{ホスト型}
ホスト型の仮想化は, ホストとなるOS上 (以下, ホストOS) に仮想化ソフトウェアをインストールし, 仮想化ソフトウェア上で別のOS (以下, ゲストOS) を稼働させる手法である (図\ref{fig:host})。
仮想化ソフトウェアをホストOSのアプリケーションの1つとして導入及び管理できるため, 手軽に仮想化を実現することができる。
しかし, ゲストOSの処理はホストOSを経由しなければならないため, オーバーヘッドが大きくなる。
\begin{figure}[H]
    \begin{center}
        \includegraphics[width=120mm]{fig/host.pdf}
    \end{center}
    \caption{ホスト型}
    \label{fig:host}
\end{figure}

\subsection{ハイパーバイザー型}
ハイパーバイザー型の仮想化は, 仮想化システムを直接ハードウェアにインストールし, ハイパーバイザー上で複数のゲストOSを稼働させる手法である (図\ref{fig:hyper})。
ハイパーバイザーが直接ハードウェアを管理するため仮想化によるオーバーヘッドを小さくすることで, リソースを効率的に利用することができる。
\begin{figure}[H]
    \begin{center}
        \includegraphics[width=120mm]{fig/hyper.pdf}
    \end{center}
    \caption{ハイパーバイザー型}
    \label{fig:hyper}
\end{figure}

\subsection{コンテナ型}
コンテナ型の仮想化は,  OS レベルの仮想化技術を利用して複数のコンテナと呼ばれる独立空間を形成し, 独立空間でアプリケーションをそれぞれ構築することができる手法である (図\ref{fig:container})。
各コンテンはオペレーティングシステムカーネルによって独立したプロセスとして実行される。
前述のホスト型やハイパーバイザー型と比べ, コンテナはゲストOSを起動することなくアプリケーションを実行することができるため, リソース効率が良く処理が軽量である。

\begin{figure}[H]
    \begin{center}
        \includegraphics[width=120mm]{fig/container.pdf}
    \end{center}
    \caption{コンテナ型}
    \label{fig:container}
\end{figure}

\section{KVM}
KVM (Kernel-based Virtual Machine)\cite{kvm} は Linux カーネル 2.6.20 以降に標準搭載されているハイパーバイザーである。
KVM は Intel VT 及び AMD-V を含む x86 ハードウェア上の完全仮想化をサポートしている。
KVM はハイパーバイザーと各仮想マシン間のレイヤーとして Virtio API を使用して, 仮想マシンに準仮想化デバイスを提供する。
これにより, 仮想化によるオーバーヘッドを少なくできる。

\section{Docker}
Docker\cite{docker} は Docker 社が開発, 提供する Linux 上で動作する隔離された Linux コンテナをデプロイ, 実行するアプリケーションである。
Docker はコンテナを実行するだけでなく, コンテナイメージの作成や共有する仕組みも提供している。
Docker コマンドを処理するには Docker daemon と呼ばれるデーモンプロセスを実行する必要がある。
この Docker deamon は Docker で行う処理を一箇所で実施する (図\ref{fig:docker})。
\begin{figure}[H]
    \begin{center}
        \includegraphics[width=150mm]{fig/docker.pdf}
    \end{center}
    \caption{Docker}
    \label{fig:docker}
\end{figure}

\subsection{Docker Registry}
Docker Registry は Dcoker イメージを保存, 配布できるサーバサイドアプリケーションである\cite{registry}。
以下の場合に利用される。
\begin{itemize}
  \item イメージの保存場所を厳密に管理する
  \item イメージを配布するパイプラインを全て所有する
  \item イメージの保存と配布を社内や学内の開発ワークフローに密に統合する
\end{itemize}

\section{Podman}
Podman は RedHat 社が開発, 提供する Linux 上でOCIコンテナを開発, 管理, 実行するためのデーモンレスコンテナエンジンである\cite{podman}。
Podman は OCI準拠のコンテナランタイムに依存するため, 前述した Docker など他のコンテナエンジンと互換性を持つ。
また, Podman CLI は Docker CLI と同じ機能を提供する。
Podman はコンテナとイメージストレージ, コンテナランタイムを介してLinxuカーネルと直接対話することで, デーモンレスで実行される (図\ref{fig:podman})。
Podman の制御下にあるコンテナは, 特権ユーザ又は非特権ユーザのいずれかによって実行することができる。
\begin{figure}[H]
    \begin{center}
        \includegraphics[width=120mm]{fig/podman.pdf}
    \end{center}
    \caption{Podman}
    \label{fig:podman}
\end{figure}

\section{Singularity}
Singularity\cite{singu} とは, HPC環境向けに設計されたコンテナプラットフォームである。
Singularity は マルチユーザに対応しており,コンテナ内での権限は実行ユーザの権限を引き継ぐため,ユーザに特別な権限の設定が必要ない。
またデフォルトで, \$HOME, /tmp, /proc, /sys, /dev がコンテナにマウントされ, サーバ上の GPU を簡単に利用できる。
コンテナイメージは Singularity Image Format (以下, sif) と呼ばれる単一ファイルベースのため, アーカイブや共有が容易である。

%\newpage
\section{Ceph}
Ceph は, RedHat 社が開発, 提供する分散ファイルシステムである。
Ceph は分散オブジェクトストレージであるRADOS (Reliable Autonomic Distributred Object Storage) がベースとなっている (図\ref{fig:ceph})。
オブジェクトストレージはデータをオブジェクトという単位でやり取りをするストレージシステムである。
複数のストレージを束ねて利用できるオブジェクトストレージが分散オブジェクトストレージである。
RAODS では, Object Storage Daemon (OSD) にデータ格納する。
オブジェクトの配置には, クラスタマップを元に Controlled Replication Under Scalable Hashing (CRUSH) アルゴリズムによりオブジェクトの格納先を選択する。
配置の計算に必要とする情報はごくわずかであるため, Cephクラスタ内のすべてのノードは保存されている位置を計算できる。
そのため, データの読み書きが効率化される。また, CRUSH はデータをクラスタ内のすべてのノードに均等に分散しようとする。
\par
RODOS はクラスタに保存されるデータの管理を待ち受け, 保存オブジェクトへのアクセス方法として Object Gateway, RADOS Block Device (以下, RBD), CephFS がある。
Object Gateway は HTTP REST 経由でクラスタに保存されるオブジェクトへ直接アクセスが可能である。
RBD はブロックデバイスとしてアクセスが可能で, libvirt を組み合わせてVMのディスクとして使用できる。
また, RBDドライバを搭載したOSにマップし ext4 や XFS などでフォーマットして利用できる。
CephFS は POSIX互換のファイルシステムである。
\begin{figure}[H]
    \begin{center}
        \includegraphics[width=120mm]{fig/ceph.pdf}
    \end{center}
    \caption{Cephのアーキテクチャ}
    \label{fig:ceph}
\end{figure}

\par
Ceph では, ノードとはクラスタを構成するサーバであり, ノードでは以下の4つのデーモンが実行できる。
\begin{itemize}
  \item Ceph Monitor
  \item Ceph OSD
  \item Ceph Manager
  \item Ceph Metadata Server
\end{itemize}

\subsection{Ceph Monitor}
Ceph Monitor (以下, MON) ノードはクラスタのヘルス状態に関する情報, データ分散ルールを維持する。
障害が発生した場合, クラスタ内のMONノードでPaxosという合意アルゴリズムを使用して, どの情報が正しいかを多数決で決定する。
そのため, 奇数個のMONノードを設定する必要がある。

\subsection{Ceph OSD}
Ceph OSD (以下, OSD) は物理ストレージになる。このデーモンは1台のHDDなどの物理ストレージに対して, 1つのデーモンが動作する。
OSD は MON と通信し, OSD デーモンの状態を提供する。

\subsection{Ceph Manager}
Ceph Manager (以下, MGR) ノードはクラスタ全体から状態情報を収集する。
MGR は MON と共に動作し, 外部のモニタリングシステムや管理システムのインターフェースとして機能する。

\subsection{Ceph Metadata Server}
Ceph Metadata Server (以下, MDS) ノードは CephFS のメタデータを保存する。

\section{Ansible}
Ansible\cite{ansible} は RedHat 社が開発, 提供するシステム構成, ソフトウェアの展開などを行う自動化ツールである。
あらかじめ用意した設定ファイルに従ってソフトウェアのインストールや設定を自動的に実行できるため, コンピュータクラスタを構築する際に時間の短縮やミスの削減に有用である。
Ansible の特徴としてエージェントレスがある。構成管理を行う機器が Python が使用可能で SSH で疎通することが可能であれば対象とすることができる。
Ansible の一連の処理は Playbook という単位にまとまられ, YAML形式で記述される。YAML形式で記述されていることで, 可読性が高く学習が容易である。
また, インフラストラクチャをコードとして残すことができる。

\section{Slurm}
Slurm\cite{slurm} は Linuxクラスタ向けのフォールトトレラント設計のジョブスケジューリングシステムです。
Slurm には以下の3つの主要機能を提供する。
\begin{itemize}
  \item 計算を実行するユーザに対してリソースへの排他的, 非排他的なアクセスを割り当てる
  \item 割り当てられたノード上のジョブの開始, 実行, モニタリングを行う
  \item 待機中のジョブキューを管理することにより, リソースの競合を解決する
\end{itemize}
\par
Slurm では主に slurmctld と slurmd で構成される (図\ref{fig:slurm})。
また, slurmdbd を有効にすることで, データベースへアカウンティング情報を記録することができる。
アカウンティング情報を記録することで, ジョブの優先度を調整することが可能となる。
\begin{figure}[H]
    \begin{center}
        \includegraphics[width=150mm]{fig/slurm.pdf}
    \end{center}
    \caption{Slurmのアーキテクチャ}
    \label{fig:slurm}
\end{figure}

%\section{GitLab}
%GitLab\cite{gitlab} とは バージョン管理システムである Git のリポジトリマネージャである。
%Git リポジトリの管理に加えて, コードレビュー, 継続的インティグレーション, 継続的デリバリ, GitLab Container Registry などの機能も有している。

\section{rsnapshot}
rsnapshot\cite{rsnapshot} は rsycn に基づく差分バックアップユーティリティである。
ローカルマシンやリモートマシンのスナップショットを取ることができる。
リモートマシンとは SSH 経由で通信を行う。
rsnapshot は設定された数のスナップショットを保持するため, 使用されるディスク領域は継続的に増加することはない。
データの復元にはバックアップの保存先から rsync などを用いてコピーを行うことで, 特定のファイルの復旧などにも迅速に対応できる。
バックアップを自動化するには cron などと併用する必要がある。

\section{Akatsuki}
Akatsuki は本コースで利用している VM貸出システム, 有線LAN接続サービス, 内部DNSの機能を提供する Webコントロールパネルである。
Ruby で記述されており, フレームワークとしRuby on Rails を採用している。
本コースの学生は学科のアカウントでログインしVMの作成などを行う。現在はシステム管理チームが管理, 保守を行っている。

\section{ie-virsh}
ie-virsh\cite{ie-virsh} は本コースで利用している virsh をラップした VM管理ツールである。
ユーザの UID 及び GID 情報を使用し, 他のユーザ VM を操作させない仕組みを持つ。
ie-virsh は VM管理だけでなく, Linux Kernel のデバッグを行うことができる。
そのため, 本コースの Operating System という授業で, OS について学ぶ一環として課題で利用されている。
現在はシステム管理チームが管理, 保守を行っている。