Mercurial > hg > Papers > 2021 > mk-thesis
comparison prepaper/pre.tex @ 56:467f33670092
update prepaper
author | Ken Miyahira <e175733@ie.u-ryukyu.ac.jp> |
---|---|
date | Sun, 14 Feb 2021 23:38:36 +0900 |
parents | a822207b796f |
children | e2149fb556e4 |
comparison
equal
deleted
inserted
replaced
55:a822207b796f | 56:467f33670092 |
---|---|
68 またデフォルトで,\$HOME,/tmp,/proc,/sys,/dev がコンテナにマウントされ,サーバ上のGPUを簡単に利用できる. | 68 またデフォルトで,\$HOME,/tmp,/proc,/sys,/dev がコンテナにマウントされ,サーバ上のGPUを簡単に利用できる. |
69 コンテナイメージはSingularity Image Format(以下,sif)と呼ばれる単一ファイルベースのため,アーカイブや共有が容易である. | 69 コンテナイメージはSingularity Image Format(以下,sif)と呼ばれる単一ファイルベースのため,アーカイブや共有が容易である. |
70 | 70 |
71 \section{Slurm} | 71 \section{Slurm} |
72 Slurm\cite{slurm}はLinuxクラスタ向けのフォールトトレラント設計のジョブスケジューリングシステムである. | 72 Slurm\cite{slurm}はLinuxクラスタ向けのフォールトトレラント設計のジョブスケジューリングシステムである. |
73 ジョブスケジューラではサーバ上で実行される処理を「Job」という単位で管理する. | |
74 ユーザはプログラムの実行手順,実行に必要とするリソースを記したbatchファイルを作成し,ジョブスケジューラにJobの実行を依頼する. | |
75 ジョブスケジューラは要求するリソース,実行時間を考慮し,複数の計算ノードからJobを実行するノードを決定する. | |
76 このようにサーバ上でのプログラム等の実行,サーバのリソースを管理するのがジョブスケジューラである。 | |
77 Slurmには以下の3つの主要機能を提供する. | 73 Slurmには以下の3つの主要機能を提供する. |
78 \begin{itemize} | 74 \begin{itemize} |
79 \item 計算を実行するユーザに対してリソースへの排他的,非排他的なアクセスを割り当てる | 75 \item 計算を実行するユーザに対してリソースへの排他的,非排他的なアクセスを割り当てる |
80 \item 割り当てられたノード上のジョブの開始,実行,モニタリングを行う | 76 \item 割り当てられたノード上のジョブの開始,実行,モニタリングを行う |
81 \item 待機中のジョブキューを管理することにより,リソースの競合を解決する | 77 \item 待機中のジョブキューを管理することにより,リソースの競合を解決する |
95 また,RBDドライバを搭載したOSにマップし ext4 や XFS などでフォーマットして利用できる. | 91 また,RBDドライバを搭載したOSにマップし ext4 や XFS などでフォーマットして利用できる. |
96 CephFS は POSIX互換のファイルシステムである. | 92 CephFS は POSIX互換のファイルシステムである. |
97 複数のアクセス方法を提供することで,用途に合わせ柔軟に変更することができる. | 93 複数のアクセス方法を提供することで,用途に合わせ柔軟に変更することができる. |
98 | 94 |
99 \section{教育情報システムの構築} | 95 \section{教育情報システムの構築} |
100 旧システムでは,学生が演習などで利用できる環境として貸出VMのみであった.そのため以下のような問題が生じた. | 96 新システムは,VMベースのシステムからコンテナベースへ移行する. |
101 | 97 新システムでもVM貸出サービスを継続するが,新しく搭載されるGPUをVMで利用するためにはPCIパススルーなどの設定が必要となる. |
102 \begin{itemize} | 98 しかし,PCIパススルーでは,VMとGPUが1対1の関係になるため,GPU希望する利用者全てに割り当てることができない. |
103 \item 仮想環境の貸出サービスにおいて,新しく仮想環境を作成するにはシステム管理チームへ申請が必要であった. | 99 そのため,コンテナに移行することにでリソースを効率よく利用し,管理を容易にする狙いがある. |
104 そのため,一部学生は申請の方法が分からなかったり,貸出サービスがあることが周知されていなかったため,旧システムのリソースが余っていた. | 100 また,基幹サービスのデータをSSD上に保存することで,サービスの高速化を図る. |
105 \item 機械学習の演習ではGPUが求められる.だが,旧システムにはGPUが搭載されていないため,要求されるリソースを提供できない. | 101 \par |
106 そのため,貸出サービスではなく研究室ごとの機器が多く利用された. | 102 システムは学生や教授などが利用するため,マルチユーザで利用できるコンテナエンジンが必要となる. |
107 \item 旧システムのクラスタファイルシステムであるGFS2のロックマネージャーを担当するサーバが停止すると,ファイルシステムにアクセスができなくなっった. | 103 そこで,マルチユーザに対応しているPodmanとSingularityを採用する. |
108 そのため,学科のサービスを提供できなくなった. | 104 Podmanは独自の名前空間でコンテナ内で特権機能を利用できるため,特権が必要なサービスなどの実行に向いている. |
109 \end{itemize} | 105 また,Singularityはコンテナ内で実行ユーザの権限を引き継ぐため,利用者が作成したプログラムの実行には向いている. |
110 | 106 だが,Podmanのrootlessでは実行できない機能があり,SingularityではイメージのBuildがキャッシュされず低速である. |
107 そこで,Podmanをwrapperしたie-podmanを作成した. | |
108 \par | |
109 | |
110 | |
111 \par | |
112 旧システムで使用したファイルシステムのGFS2はロックマネージャの影響が大きく,GFS2上のデータにアクセスできなくなることがあった. | |
113 そこで,新システムでは | |
111 | 114 |
112 \section{教育情報システムの利用} | 115 \section{教育情報システムの利用} |
116 | |
117 構築した教育情報システムの管理方法,利用方法について述べる. | |
118 | |
113 \subsection{ie-podmanの利用} | 119 \subsection{ie-podmanの利用} |
114 ie-podmanはPodmanをwrappし複数ユーザで利用することができるコンテナ管理ツールである. | 120 ie-podmanはPodmanをwrappし複数ユーザで利用することができるコンテナ管理ツールである. |
115 Podmanはマルチユーザに対応しているため,ie-podmanを利用せずともコンテナの作成などを行える. | 121 Podmanはマルチユーザに対応しているため,ie-podmanを利用せずともコンテナの作成などを行える. |
116 だが,コンテナへのIPアドレスの割り当てには,root権限が必要となるためrootlessでは実行できない. | 122 だが,コンテナへのIPアドレスの割り当てには,root権限が必要となるためrootlessでは実行できない. |
117 そのため,Webなどを実行しアクセスするにはポートフォワードを設定し,SSHポートフォワードを行う必要がある. | |
118 そこで,ie-podmanではPodmanのすべての機能をwrappするのではなく,rootlessでは実行できない機能を提供する. | 123 そこで,ie-podmanではPodmanのすべての機能をwrappするのではなく,rootlessでは実行できない機能を提供する. |
124 \par | |
125 新しいコンテナの作成は,Podmanのrunと同じように実行できる. | |
126 run時に--gpuオプションを指定することでコンテナ内にGPUを割り当てる. | |
127 また,--ipオプションを指定することで,使用されていないIPアドレスが割り振られる. | |
128 ie-podmanを使用して,新しいコンテナの作成はソースコード\ref{pg:ie-run}のように行う. | |
129 \begin{lstlisting}[caption=コンテナの作成, label=pg:ie-run] | |
130 $ ie-podman run --ip --gpu [IMAGE_NAME] | |
131 \end{lstlisting} | |
132 \par | |
133 Singularityからsifファイルの作成はPodmanと違いイメージのBuild時にレイヤーごとにキャッシュされない. | |
134 そのため,Build中にエラーが発生すると一からBuildを再開する必要がある. | |
135 そこで,ie-podmanで作成したイメージをsifファイルへ変換する機能を作成した. | |
136 ie-podmanでイメージを作成し,ソースコード\ref{pg:ie-sif}の操作を行うことでsifファイルへ変換が行える. | |
137 \begin{lstlisting}[caption=イメージのsif変換, label=pg:ie-sif] | |
138 $ ie-podman sif [IMAGE_NAME] | |
139 \end{lstlisting} | |
140 | |
141 \subsection{GPUの利用方法} | |
142 新システムでは,汎用サーバに搭載されるGPUをコンテナから利用できる. | |
143 SingularityからGPUを利用には--nvオプションを指定することで,コンテナからGPUを利用することが可能になる. | |
144 Singularityのコンテナの実行は,ソースコード\ref{pg:sing-run}の操作で行える. | |
145 \begin{lstlisting}[caption=Singularityの実行, label=pg:sing-run] | |
146 $ singularity run --nv [SIF_NAME] | |
147 \end{lstlisting} | |
148 | |
149 コンテナの実行にはrun,exec,shellのサブコマンドがあり,runではsifファイルを作成する際に指定が可能なrunscriptが実行される. | |
150 また,execではイメージ内にインストールされている任意のコマンドを実行することが可能である. | |
151 PodmanやDockerではexecを実行するにはコンテナを作成する必要があるが,Singularityではsifファイルからコマンドを実行することが可能である. | |
152 これらのサブコマンドを利用し,SlurmにJobを投下時に利用するJobの実行手順を記述したBatchファイルを作成する. | |
153 BatchファイルにはJobに必要とするリソースの定義,Jobで実行したい処理を記述する. | |
154 ソースコード\ref{pg:batchfile}は2$\sim$8行目にJobに必要とするリソースを定義する. | |
155 リソースの定義した後にプログラムを実行する処理を記述する. | |
156 \begin{lstlisting}[caption=Batchファイル, label=pg:batchfile, language=Bash, numbers=left, breaklines=true, basicstyle=\ttfamily\footnotesize, frame=single] | |
157 #!/bin/bash | |
158 #SBATCH --job-name sample | |
159 #SBATCH --output logs/%x-%j.log | |
160 #SBATCH --error logs/%x-%j.err | |
161 #SBATCH --nodes 1 | |
162 #SBATCH --cpus-per-task 8 | |
163 #SBATCH --gpus tesla:1 | |
164 #SBATCH --time 01:00 | |
165 | |
166 singularity exec --nv [SIF_NAME] [COMMANDS] | |
167 \end{lstlisting} | |
168 | |
169 Batchファイルを作成後,ソースコード\ref{pg:s-cmd}の1行目の操作でJobを投下することが可能である. | |
170 また,2行目の操作でJobの各種情報,3行目で投下したJobを停止することができる. | |
171 SlurmはユーザごとにJobが管理されるため,他ユーザのJobを停止するこはできない. | |
172 \begin{lstlisting}[caption=Jobの投下, label=pg:s-cmd, frame=single, numbers=left] | |
173 sbatch [BATCH_FILENAME] | |
174 squeue | |
175 scansel [JOB_ID] | |
176 \end{lstlisting} | |
119 | 177 |
120 \section{教育情報システムの評価} | 178 \section{教育情報システムの評価} |
121 \subsection{ie-podmanの評価} | 179 \subsection{ie-podmanの評価} |
180 RootlessのPodman,Singularityの不便な点を補うため,Podmanのwrapperであるie-podmanを作成した. | |
181 ie-podmanにより特権が必要な機能も,利用者に特別な権限を与えることなく利用できるようになる. | |
182 また,ie-podmanはrootfullのPodmanをwrapperすることにより,コンテナやイメージがSSD上に保存される. | |
183 そのため,rootlessのPodmanより高速化を図ることが可能になる. | |
184 \par | |
185 そこで,ie-podmanでのイメージのBuild速度の比較を行う. | |
186 速度の比較を行うコンテナエンジンは,Docker,ie-podman,rootlessのPodmanである。 | |
187 図\ref{fig:ie-podman-review}はコンテナエンジンにおけるイメージのBuild速度である. | |
188 \begin{figure}[H] | |
189 \begin{center} | |
190 \includegraphics[width=90mm]{fig/container2.pdf} | |
191 \end{center} | |
192 \caption{書込み速度の比較} | |
193 \label{fig:ie-podman-review} | |
194 \end{figure} | |
195 | |
196 Dockerやie-podmanのBuildに掛かる時間は1分未満だが,rootlessのPodmanでは3分程掛かっている. | |
197 RootlessのPodmanはコンテナイメージをユーザのホームディレクトリに保存する. | |
198 また,rootlessでは重複排除をサポートしていないVFSストレージに制限される. | |
199 RootlessのPodmanは独自の名前空間内で特権機能を利用できるようにするため,rootfullと比べ経由する関数が多くなる. | |
200 そのため,rootlessではrootfullと比べsyscallが多く呼ばれることにより,他と比べイメージのBuild速度が遅くなっているのではないかと考える. | |
201 | |
122 \subsection{ファイルシステムの評価} | 202 \subsection{ファイルシステムの評価} |
203 旧システムのVM保存場所として利用していたGFS2,ユーザのホームディレクトリとして利用していたNFSとの速度比較を行う. | |
204 ベンチマークにはddコマンドを使用する. | |
205 データの変換方法にfdatasyncを指定することで,書き込み終了の直前にsyncを1回要求するため,実際の動作に近い動作で測定が可能である. | |
206 \par | |
207 図\ref{fig:write}はCephFS,Ceph RBD,GFS2,NFSにおけるファイルサイズに対する書き込み速度である. | |
208 \begin{figure}[H] | |
209 \begin{center} | |
210 \includegraphics[width=90mm]{fig/Write.pdf} | |
211 \end{center} | |
212 \caption{書込み速度の比較} | |
213 \label{fig:write} | |
214 \end{figure} | |
215 | |
216 旧システムのホームディレクトリは,iSCSI経由でマウントされたデバイスをNFSから提供していた. | |
217 iSCSIの通信には10Gbpsの回線で接続されているが,NFSの提供はVMで行われており,1Gbpsで提供されていた. | |
218 そのため,10Gbpsの回線で接続し,マウントしているCephでは書き込み速度の改善が見られる. | |
219 しかし,GFS2は10Gbpsで接続されたクラスタで構成されているが,Cephより低速である. | |
220 旧システムでは,パッケージ等のアップデートがされておらず,Kernelの更新もされていなかった. | |
221 KernelはI/Oに関する多くの機能を提供するため,GFS2の書き込みより,Cephが高速になったのではないかと考えられる. | |
222 \par | |
223 今回の計測では,読み込み速度の測定を行えなかった. | |
224 これは,旧システムで読み込み時にバッファキャッシュを削除せずに測定を行ったためである. | |
225 そのため,純粋な読み込み速度を測定することができなかったことは反省点である. | |
123 | 226 |
124 \section{まとめ} | 227 \section{まとめ} |
228 今年度のシステム更新で教育情報システムの構築を行い,VMベースからコンテナベースへの移行ができた. | |
229 また,学生が利用できる学習環境としてVM貸出サービスだけでなく,コンテナ環境も利用できるようにしたことにより,学生が自由にサーバのリソースを利用できるようになった. | |
230 コンテナ環境として採用したPodman,Singularityの不便な点を補うために作成したie-podmanの評価を行った. | |
231 新しく採用したCephと,旧システムのファイルシステムとして利用されたGFS2,NFSとの書き込み速度の比較を行い,速度向上がみられた. | |
125 | 232 |
126 \section{今後の課題} | 233 \section{今後の課題} |
234 旧システムのVM貸出サービスは講義等で告知されたりしたが,実際にはあまり周知されておらず利用も少なかった. | |
235 これは,システム管理チームからの利用方法について周知等が少なかったことも原因として挙げられる. | |
236 本研究で構築した教育情報システムは,VMからコンテナまで利用できる. | |
237 だが,利用は主にCLIから操作を行い,プログラムの実行にはSlurmを利用する. | |
238 VM貸出サービスの変更や,コンテナ環境の利用方法についてまとめる必要がある. | |
239 また,SlurmのJobの投下方法や必要なリソースの要求方法などをまとめ,定期的な周知を行う必要がある. | |
240 \par | |
241 ie-podmanで使用するネットワーク構成はプレフィックス長が24であるため,最大254個のIPアドレスしか割り当てできない. | |
242 そのため,コンテナを削除せず停止のままでは,割り当て可能なIPアドレスが枯渇する. | |
243 そこで,ie-podmanが利用するネットワーク構成の変更を行う,もしくはコンテナが停止のまま数日経つ場合にie-podmanから自動削除する必要がある. | |
127 | 244 |
128 \begin{thebibliography}{9} | 245 \begin{thebibliography}{9} |
129 | 246 |
130 \bibitem{podman} Podman,https://podman.io/,2021/1/4. | 247 \bibitem{podman} Podman,https://podman.io/,2021/1/4. |
131 \bibitem{singularity} Singularity,https://sylabs.io/singularity/,2021/1/8. | 248 \bibitem{singularity} Singularity,https://sylabs.io/singularity/,2021/1/8. |