\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) と呼ばれる単一ファイルベースのため, アーカイブや共有が容易である。

\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 では一連の処理を YAML 形式のファイルで記述し, エージェントレスで SSH を介してタスクを実行する。
そのため, インフラストラクチャをコードとして残すことができる。

\section{Slurm}

\section{GitLab}

\section{rsnapshot}

\section{Akatsuki}

\section{ie-virsh}