# HG changeset patch # User Ken Miyahira # Date 1613313516 -32400 # Node ID 467f3367009247a3a8b992ce19125cce96b6242a # Parent a822207b796f131368306390f6977f12a671df05 update prepaper diff -r a822207b796f -r 467f33670092 paper/chapter/system_review.tex --- a/paper/chapter/system_review.tex Sun Feb 14 16:29:06 2021 +0900 +++ b/paper/chapter/system_review.tex Sun Feb 14 23:38:36 2021 +0900 @@ -57,22 +57,11 @@ そこで，ie-virshでは差分でVMを作成機能が追加され，新しく作成されるVMは数十MBになることで，使用するディスク容量を抑えることが可能になった． \section{コンテナ環境の評価} -%新しく導入したPodmanは，Dockerと同じCLIを提供するため，Dockerを利用したことがある学生は抵抗なく利用できる． -%また，ie-podmanにより特権が必要な機能も，利用者に特別な権限を与えることなく利用できるようになる． -%Singularityの導入により，GPUを手軽に利用できるため，演習や研究等での利用も広がると考えられる． -%\par -%VMでは新しく作成するたびに環境構築が必要であったが，コンテナイメージを作成することで環境構築は一度のみになる． -%また，学科のレジストリーにイメージを登録することで，他の利用者に共有も可能となる． -%Singularityでは単一ファイルのsifのコピーを配布することで，同じ環境でプログラムの実行することができる． -%\par -%これまでのVMベースのシステムから，コンテナベースのシステムへの移行により，汎用バーバのリソースを効率よく利用できる． -%また，学生も気軽に利用できるようになったのではないかと考えられる． - 新しく導入したPodmanは，Dockerと同じCLIを提供するため，Dockerを利用したことがある学生は抵抗なく利用できる． また，Singularityの導入により，GPUを手軽に利用できるため，演習や研究等での利用も広がると考えられる． \par RootlessのPodman，Singularityの不便な点を補うため，Podmanのwrapperであるie-podmanを作成した． -iepodmanにより特権が必要な機能も，利用者に特別な権限を与えることなく利用できるようになる． +ie-podmanにより特権が必要な機能も，利用者に特別な権限を与えることなく利用できるようになる． また，ie-podmanはrootfullのPodmanをwrapperすることにより，コンテナやイメージがSSD上に保存される． そのため，rootlessのPodmanより高速化を図ることが可能になる． \par diff -r a822207b796f -r 467f33670092 prepaper/fig/Write.pdf Binary file prepaper/fig/Write.pdf has changed diff -r a822207b796f -r 467f33670092 prepaper/fig/container2.pdf Binary file prepaper/fig/container2.pdf has changed diff -r a822207b796f -r 467f33670092 prepaper/pre.pdf Binary file prepaper/pre.pdf has changed diff -r a822207b796f -r 467f33670092 prepaper/pre.tex --- a/prepaper/pre.tex Sun Feb 14 16:29:06 2021 +0900 +++ b/prepaper/pre.tex Sun Feb 14 23:38:36 2021 +0900 @@ -70,10 +70,6 @@ \section{Slurm} Slurm\cite{slurm}はLinuxクラスタ向けのフォールトトレラント設計のジョブスケジューリングシステムである． -ジョブスケジューラではサーバ上で実行される処理を「Job」という単位で管理する． -ユーザはプログラムの実行手順，実行に必要とするリソースを記したbatchファイルを作成し，ジョブスケジューラにJobの実行を依頼する． -ジョブスケジューラは要求するリソース，実行時間を考慮し，複数の計算ノードからJobを実行するノードを決定する． -このようにサーバ上でのプログラム等の実行，サーバのリソースを管理するのがジョブスケジューラである。 Slurmには以下の3つの主要機能を提供する． \begin{itemize} \item 計算を実行するユーザに対してリソースへの排他的，非排他的なアクセスを割り当てる @@ -97,33 +93,154 @@ 複数のアクセス方法を提供することで，用途に合わせ柔軟に変更することができる． \section{教育情報システムの構築} -旧システムでは，学生が演習などで利用できる環境として貸出VMのみであった．そのため以下のような問題が生じた． - -\begin{itemize} - \item 仮想環境の貸出サービスにおいて，新しく仮想環境を作成するにはシステム管理チームへ申請が必要であった． - そのため，一部学生は申請の方法が分からなかったり，貸出サービスがあることが周知されていなかったため，旧システムのリソースが余っていた． - \item 機械学習の演習ではGPUが求められる．だが，旧システムにはGPUが搭載されていないため，要求されるリソースを提供できない． - そのため，貸出サービスではなく研究室ごとの機器が多く利用された． - \item 旧システムのクラスタファイルシステムであるGFS2のロックマネージャーを担当するサーバが停止すると，ファイルシステムにアクセスができなくなっった． - そのため，学科のサービスを提供できなくなった． -\end{itemize} +新システムは，VMベースのシステムからコンテナベースへ移行する． +新システムでもVM貸出サービスを継続するが，新しく搭載されるGPUをVMで利用するためにはPCIパススルーなどの設定が必要となる． +しかし，PCIパススルーでは，VMとGPUが1対1の関係になるため，GPU希望する利用者全てに割り当てることができない． +そのため，コンテナに移行することにでリソースを効率よく利用し，管理を容易にする狙いがある． +また，基幹サービスのデータをSSD上に保存することで，サービスの高速化を図る． +\par +システムは学生や教授などが利用するため，マルチユーザで利用できるコンテナエンジンが必要となる． +そこで，マルチユーザに対応しているPodmanとSingularityを採用する． +Podmanは独自の名前空間でコンテナ内で特権機能を利用できるため，特権が必要なサービスなどの実行に向いている． +また，Singularityはコンテナ内で実行ユーザの権限を引き継ぐため，利用者が作成したプログラムの実行には向いている． +だが，Podmanのrootlessでは実行できない機能があり，SingularityではイメージのBuildがキャッシュされず低速である． +そこで，Podmanをwrapperしたie-podmanを作成した． +\par +\par +旧システムで使用したファイルシステムのGFS2はロックマネージャの影響が大きく，GFS2上のデータにアクセスできなくなることがあった． +そこで，新システムでは + \section{教育情報システムの利用} + +構築した教育情報システムの管理方法，利用方法について述べる． + \subsection{ie-podmanの利用} ie-podmanはPodmanをwrappし複数ユーザで利用することができるコンテナ管理ツールである． Podmanはマルチユーザに対応しているため，ie-podmanを利用せずともコンテナの作成などを行える． だが，コンテナへのIPアドレスの割り当てには，root権限が必要となるためrootlessでは実行できない． -そのため，Webなどを実行しアクセスするにはポートフォワードを設定し，SSHポートフォワードを行う必要がある． そこで，ie-podmanではPodmanのすべての機能をwrappするのではなく，rootlessでは実行できない機能を提供する． +\par +新しいコンテナの作成は，Podmanのrunと同じように実行できる． +run時に--gpuオプションを指定することでコンテナ内にGPUを割り当てる． +また，--ipオプションを指定することで，使用されていないIPアドレスが割り振られる． +ie-podmanを使用して，新しいコンテナの作成はソースコード\ref{pg:ie-run}のように行う． +\begin{lstlisting}[caption=コンテナの作成, label=pg:ie-run] +$ ie-podman run --ip --gpu [IMAGE_NAME] +\end{lstlisting} +\par +Singularityからsifファイルの作成はPodmanと違いイメージのBuild時にレイヤーごとにキャッシュされない． +そのため，Build中にエラーが発生すると一からBuildを再開する必要がある． +そこで，ie-podmanで作成したイメージをsifファイルへ変換する機能を作成した． +ie-podmanでイメージを作成し，ソースコード\ref{pg:ie-sif}の操作を行うことでsifファイルへ変換が行える． +\begin{lstlisting}[caption=イメージのsif変換, label=pg:ie-sif] +$ ie-podman sif [IMAGE_NAME] +\end{lstlisting} + +\subsection{GPUの利用方法} +新システムでは，汎用サーバに搭載されるGPUをコンテナから利用できる． +SingularityからGPUを利用には--nvオプションを指定することで，コンテナからGPUを利用することが可能になる． +Singularityのコンテナの実行は，ソースコード\ref{pg:sing-run}の操作で行える． +\begin{lstlisting}[caption=Singularityの実行, label=pg:sing-run] +$ singularity run --nv [SIF_NAME] +\end{lstlisting} + +コンテナの実行にはrun，exec，shellのサブコマンドがあり，runではsifファイルを作成する際に指定が可能なrunscriptが実行される． +また，execではイメージ内にインストールされている任意のコマンドを実行することが可能である． +PodmanやDockerではexecを実行するにはコンテナを作成する必要があるが，Singularityではsifファイルからコマンドを実行することが可能である． +これらのサブコマンドを利用し，SlurmにJobを投下時に利用するJobの実行手順を記述したBatchファイルを作成する． +BatchファイルにはJobに必要とするリソースの定義，Jobで実行したい処理を記述する． +ソースコード\ref{pg:batchfile}は2$\sim$8行目にJobに必要とするリソースを定義する． +リソースの定義した後にプログラムを実行する処理を記述する． +\begin{lstlisting}[caption=Batchファイル, label=pg:batchfile, language=Bash, numbers=left, breaklines=true, basicstyle=\ttfamily\footnotesize, frame=single] +#!/bin/bash +#SBATCH --job-name sample +#SBATCH --output logs/%x-%j.log +#SBATCH --error logs/%x-%j.err +#SBATCH --nodes 1 +#SBATCH --cpus-per-task 8 +#SBATCH --gpus tesla:1 +#SBATCH --time 01:00 + +singularity exec --nv [SIF_NAME] [COMMANDS] +\end{lstlisting} + +Batchファイルを作成後，ソースコード\ref{pg:s-cmd}の1行目の操作でJobを投下することが可能である． +また，2行目の操作でJobの各種情報，3行目で投下したJobを停止することができる． +SlurmはユーザごとにJobが管理されるため，他ユーザのJobを停止するこはできない． +\begin{lstlisting}[caption=Jobの投下, label=pg:s-cmd, frame=single, numbers=left] +sbatch [BATCH_FILENAME] +squeue +scansel [JOB_ID] +\end{lstlisting} \section{教育情報システムの評価} \subsection{ie-podmanの評価} +RootlessのPodman，Singularityの不便な点を補うため，Podmanのwrapperであるie-podmanを作成した． +ie-podmanにより特権が必要な機能も，利用者に特別な権限を与えることなく利用できるようになる． +また，ie-podmanはrootfullのPodmanをwrapperすることにより，コンテナやイメージがSSD上に保存される． +そのため，rootlessのPodmanより高速化を図ることが可能になる． +\par +そこで，ie-podmanでのイメージのBuild速度の比較を行う． +速度の比較を行うコンテナエンジンは，Docker，ie-podman，rootlessのPodmanである。 +図\ref{fig:ie-podman-review}はコンテナエンジンにおけるイメージのBuild速度である． +\begin{figure}[H] + \begin{center} + \includegraphics[width=90mm]{fig/container2.pdf} + \end{center} + \caption{書込み速度の比較} + \label{fig:ie-podman-review} +\end{figure} + +Dockerやie-podmanのBuildに掛かる時間は1分未満だが，rootlessのPodmanでは3分程掛かっている． +RootlessのPodmanはコンテナイメージをユーザのホームディレクトリに保存する． +また，rootlessでは重複排除をサポートしていないVFSストレージに制限される． +RootlessのPodmanは独自の名前空間内で特権機能を利用できるようにするため，rootfullと比べ経由する関数が多くなる． +そのため，rootlessではrootfullと比べsyscallが多く呼ばれることにより，他と比べイメージのBuild速度が遅くなっているのではないかと考える． + \subsection{ファイルシステムの評価} +旧システムのVM保存場所として利用していたGFS2，ユーザのホームディレクトリとして利用していたNFSとの速度比較を行う． +ベンチマークにはddコマンドを使用する． +データの変換方法にfdatasyncを指定することで，書き込み終了の直前にsyncを1回要求するため，実際の動作に近い動作で測定が可能である． +\par +図\ref{fig:write}はCephFS，Ceph RBD，GFS2，NFSにおけるファイルサイズに対する書き込み速度である． +\begin{figure}[H] + \begin{center} + \includegraphics[width=90mm]{fig/Write.pdf} + \end{center} + \caption{書込み速度の比較} + \label{fig:write} +\end{figure} + +旧システムのホームディレクトリは，iSCSI経由でマウントされたデバイスをNFSから提供していた． +iSCSIの通信には10Gbpsの回線で接続されているが，NFSの提供はVMで行われており，1Gbpsで提供されていた． +そのため，10Gbpsの回線で接続し，マウントしているCephでは書き込み速度の改善が見られる． +しかし，GFS2は10Gbpsで接続されたクラスタで構成されているが，Cephより低速である． +旧システムでは，パッケージ等のアップデートがされておらず，Kernelの更新もされていなかった． +KernelはI/Oに関する多くの機能を提供するため，GFS2の書き込みより，Cephが高速になったのではないかと考えられる． +\par +今回の計測では，読み込み速度の測定を行えなかった． +これは，旧システムで読み込み時にバッファキャッシュを削除せずに測定を行ったためである． +そのため，純粋な読み込み速度を測定することができなかったことは反省点である． \section{まとめ} +今年度のシステム更新で教育情報システムの構築を行い，VMベースからコンテナベースへの移行ができた． +また，学生が利用できる学習環境としてVM貸出サービスだけでなく，コンテナ環境も利用できるようにしたことにより，学生が自由にサーバのリソースを利用できるようになった． +コンテナ環境として採用したPodman，Singularityの不便な点を補うために作成したie-podmanの評価を行った． +新しく採用したCephと，旧システムのファイルシステムとして利用されたGFS2，NFSとの書き込み速度の比較を行い，速度向上がみられた． \section{今後の課題} +旧システムのVM貸出サービスは講義等で告知されたりしたが，実際にはあまり周知されておらず利用も少なかった． +これは，システム管理チームからの利用方法について周知等が少なかったことも原因として挙げられる． +本研究で構築した教育情報システムは，VMからコンテナまで利用できる． +だが，利用は主にCLIから操作を行い，プログラムの実行にはSlurmを利用する． +VM貸出サービスの変更や，コンテナ環境の利用方法についてまとめる必要がある． +また，SlurmのJobの投下方法や必要なリソースの要求方法などをまとめ，定期的な周知を行う必要がある． +\par +ie-podmanで使用するネットワーク構成はプレフィックス長が24であるため，最大254個のIPアドレスしか割り当てできない． +そのため，コンテナを削除せず停止のままでは，割り当て可能なIPアドレスが枯渇する． +そこで，ie-podmanが利用するネットワーク構成の変更を行う，もしくはコンテナが停止のまま数日経つ場合にie-podmanから自動削除する必要がある． \begin{thebibliography}{9}