Mercurial > hg > Papers > 2021 > mk-thesis
annotate paper/chapter/technology_overview.tex @ 24:697579cf6cf8
update usage
author | Ken Miyahira <e175733@ie.u-ryukyu.ac.jp> |
---|---|
date | Mon, 01 Feb 2021 18:35:00 +0900 |
parents | 6e43d7a51315 |
children | a967cf51ba92 |
rev | line source |
---|---|
5 | 1 \chapter{技術概要} |
2 | |
3 本章では, 本研究で使われる技術, 本コースで利用しているサービスについて概要を説明する。 | |
4 | |
9 | 5 \section{仮想化} |
6 仮想化はコンピュータの CPU やメモリ, ディスクなどハードウェアのリソースを分割又は統合して, | |
7 仮想的なコンピュータやネットワーク環境を生成し提供する技術である。 | |
8 仮想化技術にはホストのどの部分から仮想化するかによってホスト型, ハイパーバイザー型, コンテナ型に分けることができる。 | |
9 | |
10 \subsection{ホスト型} | |
11 ホスト型の仮想化は, ホストとなるOS上 (以下, ホストOS) に仮想化ソフトウェアをインストールし, 仮想化ソフトウェア上で別のOS (以下, ゲストOS) を稼働させる手法である (図\ref{fig:host})。 | |
12 仮想化ソフトウェアをホストOSのアプリケーションの1つとして導入及び管理できるため, 手軽に仮想化を実現することができる。 | |
13 しかし, ゲストOSの処理はホストOSを経由しなければならないため, オーバーヘッドが大きくなる。 | |
14 \begin{figure}[H] | |
15 \begin{center} | |
16 \includegraphics[width=120mm]{fig/host.pdf} | |
17 \end{center} | |
18 \caption{ホスト型} | |
19 \label{fig:host} | |
20 \end{figure} | |
21 | |
22 \subsection{ハイパーバイザー型} | |
23 ハイパーバイザー型の仮想化は, 仮想化システムを直接ハードウェアにインストールし, ハイパーバイザー上で複数のゲストOSを稼働させる手法である (図\ref{fig:hyper})。 | |
24 ハイパーバイザーが直接ハードウェアを管理するため仮想化によるオーバーヘッドを小さくすることで, リソースを効率的に利用することができる。 | |
25 \begin{figure}[H] | |
26 \begin{center} | |
27 \includegraphics[width=120mm]{fig/hyper.pdf} | |
28 \end{center} | |
29 \caption{ハイパーバイザー型} | |
30 \label{fig:hyper} | |
31 \end{figure} | |
32 | |
33 \subsection{コンテナ型} | |
34 コンテナ型の仮想化は, OS レベルの仮想化技術を利用して複数のコンテナと呼ばれる独立空間を形成し, 独立空間でアプリケーションをそれぞれ構築することができる手法である (図\ref{fig:container})。 | |
35 各コンテンはオペレーティングシステムカーネルによって独立したプロセスとして実行される。 | |
36 前述のホスト型やハイパーバイザー型と比べ, コンテナはゲストOSを起動することなくアプリケーションを実行することができるため, リソース効率が良く処理が軽量である。 | |
37 | |
38 \begin{figure}[H] | |
39 \begin{center} | |
40 \includegraphics[width=120mm]{fig/container.pdf} | |
41 \end{center} | |
42 \caption{コンテナ型} | |
43 \label{fig:container} | |
44 \end{figure} | |
45 | |
5 | 46 \section{KVM} |
8 | 47 KVM (Kernel-based Virtual Machine)\cite{kvm} は Linux カーネル 2.6.20 以降に標準搭載されているハイパーバイザーである。 |
48 KVM は Intel VT 及び AMD-V を含む x86 ハードウェア上の完全仮想化をサポートしている。 | |
49 KVM はハイパーバイザーと各仮想マシン間のレイヤーとして Virtio API を使用して, 仮想マシンに準仮想化デバイスを提供する。 | |
50 これにより, 仮想化によるオーバーヘッドを少なくできる。 | |
5 | 51 |
52 \section{Docker} | |
8 | 53 Docker\cite{docker} は Docker 社が開発, 提供する Linux 上で動作する隔離された Linux コンテナをデプロイ, 実行するアプリケーションである。 |
10 | 54 Docker はコンテナを実行するだけでなく, コンテナイメージの作成や共有する仕組みも提供している。 |
55 Docker コマンドを処理するには Docker daemon と呼ばれるデーモンプロセスを実行する必要がある。 | |
56 この Docker deamon は Docker で行う処理を一箇所で実施する (図\ref{fig:docker})。 | |
9 | 57 \begin{figure}[H] |
58 \begin{center} | |
59 \includegraphics[width=150mm]{fig/docker.pdf} | |
60 \end{center} | |
61 \caption{Docker} | |
62 \label{fig:docker} | |
63 \end{figure} | |
8 | 64 |
5 | 65 \subsection{Docker Registry} |
10 | 66 Docker Registry は Dcoker イメージを保存, 配布できるサーバサイドアプリケーションである\cite{registry}。 |
67 以下の場合に利用される。 | |
68 \begin{itemize} | |
69 \item イメージの保存場所を厳密に管理する | |
70 \item イメージを配布するパイプラインを全て所有する | |
71 \item イメージの保存と配布を社内や学内の開発ワークフローに密に統合する | |
72 \end{itemize} | |
5 | 73 |
74 \section{Podman} | |
10 | 75 Podman は RedHat 社が開発, 提供する Linux 上でOCIコンテナを開発, 管理, 実行するためのデーモンレスコンテナエンジンである\cite{podman}。 |
76 Podman は OCI準拠のコンテナランタイムに依存するため, 前述した Docker など他のコンテナエンジンと互換性を持つ。 | |
77 また, Podman CLI は Docker CLI と同じ機能を提供する。 | |
78 Podman はコンテナとイメージストレージ, コンテナランタイムを介してLinxuカーネルと直接対話することで, デーモンレスで実行される (図\ref{fig:podman})。 | |
11 | 79 Podman の制御下にあるコンテナは, 特権ユーザ又は非特権ユーザのいずれかによって実行することができる。 |
9 | 80 \begin{figure}[H] |
81 \begin{center} | |
82 \includegraphics[width=120mm]{fig/podman.pdf} | |
83 \end{center} | |
84 \caption{Podman} | |
85 \label{fig:podman} | |
86 \end{figure} | |
5 | 87 |
88 \section{Singularity} | |
16
6e43d7a51315
update introduction
Ken Miyahira <e175733@ie.u-ryukyu.ac.jp>
parents:
15
diff
changeset
|
89 Singularity\cite{singularity} とは, HPC環境向けに設計されたコンテナプラットフォームである。 |
11 | 90 Singularity は マルチユーザに対応しており,コンテナ内での権限は実行ユーザの権限を引き継ぐため,ユーザに特別な権限の設定が必要ない。 |
91 またデフォルトで, \$HOME, /tmp, /proc, /sys, /dev がコンテナにマウントされ, サーバ上の GPU を簡単に利用できる。 | |
92 コンテナイメージは Singularity Image Format (以下, sif) と呼ばれる単一ファイルベースのため, アーカイブや共有が容易である。 | |
5 | 93 |
15 | 94 %\newpage |
5 | 95 \section{Ceph} |
11 | 96 Ceph は, RedHat 社が開発, 提供する分散ファイルシステムである。 |
97 Ceph は分散オブジェクトストレージであるRADOS (Reliable Autonomic Distributred Object Storage) がベースとなっている (図\ref{fig:ceph})。 | |
12 | 98 オブジェクトストレージはデータをオブジェクトという単位でやり取りをするストレージシステムである。 |
99 複数のストレージを束ねて利用できるオブジェクトストレージが分散オブジェクトストレージである。 | |
100 RAODS では, Object Storage Daemon (OSD) にデータ格納する。 | |
101 オブジェクトの配置には, クラスタマップを元に Controlled Replication Under Scalable Hashing (CRUSH) アルゴリズムによりオブジェクトの格納先を選択する。 | |
102 配置の計算に必要とする情報はごくわずかであるため, Cephクラスタ内のすべてのノードは保存されている位置を計算できる。 | |
103 そのため, データの読み書きが効率化される。また, CRUSH はデータをクラスタ内のすべてのノードに均等に分散しようとする。 | |
104 \par | |
11 | 105 RODOS はクラスタに保存されるデータの管理を待ち受け, 保存オブジェクトへのアクセス方法として Object Gateway, RADOS Block Device (以下, RBD), CephFS がある。 |
106 Object Gateway は HTTP REST 経由でクラスタに保存されるオブジェクトへ直接アクセスが可能である。 | |
107 RBD はブロックデバイスとしてアクセスが可能で, libvirt を組み合わせてVMのディスクとして使用できる。 | |
108 また, RBDドライバを搭載したOSにマップし ext4 や XFS などでフォーマットして利用できる。 | |
109 CephFS は POSIX互換のファイルシステムである。 | |
110 \begin{figure}[H] | |
111 \begin{center} | |
112 \includegraphics[width=120mm]{fig/ceph.pdf} | |
113 \end{center} | |
114 \caption{Cephのアーキテクチャ} | |
115 \label{fig:ceph} | |
116 \end{figure} | |
117 | |
118 \par | |
119 Ceph では, ノードとはクラスタを構成するサーバであり, ノードでは以下の4つのデーモンが実行できる。 | |
120 \begin{itemize} | |
121 \item Ceph Monitor | |
122 \item Ceph OSD | |
123 \item Ceph Manager | |
124 \item Ceph Metadata Server | |
125 \end{itemize} | |
126 | |
127 \subsection{Ceph Monitor} | |
128 Ceph Monitor (以下, MON) ノードはクラスタのヘルス状態に関する情報, データ分散ルールを維持する。 | |
129 障害が発生した場合, クラスタ内のMONノードでPaxosという合意アルゴリズムを使用して, どの情報が正しいかを多数決で決定する。 | |
130 そのため, 奇数個のMONノードを設定する必要がある。 | |
131 | |
132 \subsection{Ceph OSD} | |
133 Ceph OSD (以下, OSD) は物理ストレージになる。このデーモンは1台のHDDなどの物理ストレージに対して, 1つのデーモンが動作する。 | |
134 OSD は MON と通信し, OSD デーモンの状態を提供する。 | |
135 | |
136 \subsection{Ceph Manager} | |
137 Ceph Manager (以下, MGR) ノードはクラスタ全体から状態情報を収集する。 | |
138 MGR は MON と共に動作し, 外部のモニタリングシステムや管理システムのインターフェースとして機能する。 | |
139 | |
140 \subsection{Ceph Metadata Server} | |
141 Ceph Metadata Server (以下, MDS) ノードは CephFS のメタデータを保存する。 | |
142 | |
5 | 143 \section{Ansible} |
11 | 144 Ansible\cite{ansible} は RedHat 社が開発, 提供するシステム構成, ソフトウェアの展開などを行う自動化ツールである。 |
13 | 145 あらかじめ用意した設定ファイルに従ってソフトウェアのインストールや設定を自動的に実行できるため, コンピュータクラスタを構築する際に時間の短縮やミスの削減に有用である。 |
146 Ansible の特徴としてエージェントレスがある。構成管理を行う機器が Python が使用可能で SSH で疎通することが可能であれば対象とすることができる。 | |
147 Ansible の一連の処理は Playbook という単位にまとまられ, YAML形式で記述される。YAML形式で記述されていることで, 可読性が高く学習が容易である。 | |
148 また, インフラストラクチャをコードとして残すことができる。 | |
5 | 149 |
150 \section{Slurm} | |
13 | 151 Slurm\cite{slurm} は Linuxクラスタ向けのフォールトトレラント設計のジョブスケジューリングシステムです。 |
152 Slurm には以下の3つの主要機能を提供する。 | |
153 \begin{itemize} | |
154 \item 計算を実行するユーザに対してリソースへの排他的, 非排他的なアクセスを割り当てる | |
155 \item 割り当てられたノード上のジョブの開始, 実行, モニタリングを行う | |
156 \item 待機中のジョブキューを管理することにより, リソースの競合を解決する | |
157 \end{itemize} | |
158 \par | |
159 Slurm では主に slurmctld と slurmd で構成される (図\ref{fig:slurm})。 | |
160 また, slurmdbd を有効にすることで, データベースへアカウンティング情報を記録することができる。 | |
161 アカウンティング情報を記録することで, ジョブの優先度を調整することが可能となる。 | |
162 \begin{figure}[H] | |
163 \begin{center} | |
164 \includegraphics[width=150mm]{fig/slurm.pdf} | |
165 \end{center} | |
166 \caption{Slurmのアーキテクチャ} | |
167 \label{fig:slurm} | |
168 \end{figure} | |
5 | 169 |
15 | 170 %\section{GitLab} |
171 %GitLab\cite{gitlab} とは バージョン管理システムである Git のリポジトリマネージャである。 | |
172 %Git リポジトリの管理に加えて, コードレビュー, 継続的インティグレーション, 継続的デリバリ, GitLab Container Registry などの機能も有している。 | |
13 | 173 |
8 | 174 \section{rsnapshot} |
24 | 175 rsnapshot\cite{rsnapshot} は rsycn に基づく増分バックアップユーティリティである。 |
15 | 176 ローカルマシンやリモートマシンのスナップショットを取ることができる。 |
177 リモートマシンとは SSH 経由で通信を行う。 | |
178 rsnapshot は設定された数のスナップショットを保持するため, 使用されるディスク領域は継続的に増加することはない。 | |
179 データの復元にはバックアップの保存先から rsync などを用いてコピーを行うことで, 特定のファイルの復旧などにも迅速に対応できる。 | |
180 バックアップを自動化するには cron などと併用する必要がある。 | |
14 | 181 |
5 | 182 \section{Akatsuki} |
15 | 183 Akatsuki は本コースで利用している VM貸出システム, 有線LAN接続サービス, 内部DNSの機能を提供する Webコントロールパネルである。 |
14 | 184 Ruby で記述されており, フレームワークとしRuby on Rails を採用している。 |
185 本コースの学生は学科のアカウントでログインしVMの作成などを行う。現在はシステム管理チームが管理, 保守を行っている。 | |
5 | 186 |
15 | 187 \section{ie-virsh} |
188 ie-virsh\cite{ie-virsh} は本コースで利用している virsh をラップした VM管理ツールである。 | |
189 ユーザの UID 及び GID 情報を使用し, 他のユーザ VM を操作させない仕組みを持つ。 | |
190 ie-virsh は VM管理だけでなく, Linux Kernel のデバッグを行うことができる。 | |
191 そのため, 本コースの Operating System という授業で, OS について学ぶ一環として課題で利用されている。 | |
192 現在はシステム管理チームが管理, 保守を行っている。 |