Mercurial > hg > Papers > 2021 > mk-thesis
view 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 |
line wrap: on
line source
\documentclass[twocolumn,twoside,9.5pt]{jarticle} \usepackage[dvipdfmx]{graphicx} \usepackage{picins} \usepackage{fancyhdr} \usepackage{abstract} \usepackage{here} \usepackage{url} \usepackage{listings,jlisting} %\pagestyle{fancy} \lhead{\parpic{\includegraphics[height=1zw,keepaspectratio,bb=0 0 251 246]{pic/emblem-bitmap.pdf}}琉球大学主催 工学部工学科知能情報コース 卒業研究発表会} \rhead{} \cfoot{} \setlength{\topmargin}{-1in \addtolength{\topmargin}{15mm}} \setlength{\headheight}{0mm} \setlength{\headsep}{5mm} \setlength{\oddsidemargin}{-1in \addtolength{\oddsidemargin}{11mm}} \setlength{\evensidemargin}{-1in \addtolength{\evensidemargin}{21mm}} \setlength{\textwidth}{181mm} \setlength{\textheight}{261mm} \setlength{\footskip}{0mm} \pagestyle{empty} \renewcommand{\abstractname}{Abstract} \begin{document} \title{コンテナ技術を用いた\\教育情報システムの構築} \author{175733E {宮平 賢}\\ 指導教員 : {河野 真治} } \date{} \twocolumn [ \maketitle \begin{onecolabstract} ab,ab,ab,ab, abstract \end{onecolabstract}] \thispagestyle{fancy} \section{教育向けの情報システム} 情報通信技術の普及に伴い学生が学ぶ学習環境が必要となる.その学習環境としてVMやコンテナにより,手軽に開発し試せる技術が普及している. だが,手元のPC上でVMやコンテナを立ち上げ,開発を行うことはできるが,VMやコンテナの使用には高性能PCや有料のクラウドサービスが必要になる場合がある. これらの負担をIT技術を学ぶ学生に負わせない新たな仕組みが必要である. \par 本コースでは希望する学生に学科の汎用サーバから仮想環境を貸出するサービスを行っている. 貸出をするVMの基本スペックとしてCPU1コア,メモリ1GB,ストレージ10GBである. 基本スペックでは不足する場合は要望に応じてスペックの変更を行っている. しかし,機械学習などの演習ではCPUよりGPUが求められる場合がある. VM上でGPUを共有するにはPCIパススルーを利用することで可能である. だが,PCIパススルーではGPUとVMは1対1の関係となり,GPUを希望する利用者すべてに割り当てることはできない. \par 本研究では,学生が貸出VMだけでなく,学科の汎用サーバのリソースを効率的に利用できる教育情報システムを提案する. 教育情報システムには複数の汎用サーバと大容量ストレージサーバが存在する. 複数のサーバを利用するにあたり,分散ストレージが必要となる. また,学習環境として利用されることから,複数の並列なアクセスに耐えられ,信頼性の高いファイルシステムが必要である. この用件を満たすストレージソフトウェアとしてCephを採用した. 汎用サーバのリソースを効率的に利用するために,コンテナエンジンであるPodman,Singularity,ジョブスケジューラであるSlurmを採用した. これらのソフトウェアを合わせ教育情報システムの構築を行った. \section{Podman} PodmanはRedHat社が開発,提供するLinux上でOCIコンテナを開発,管理,実行するためのデーモンレスコンテナエンジンである\cite{podman}. PodmanはOCI準拠のコンテナランタイムに依存するため,前述したDockerなど他のコンテナエンジンと互換性を持つ. また,Podman CLIはDocker CLIと同じ機能を提供する. Podmanはコンテナとイメージストレージ,コンテナランタイムを介してLinxuカーネルと直接対話することで,デーモンレスで実行される. Podmanの制御下にあるコンテナは,特権ユーザ又は非特権ユーザのいずれかによって実行することができる. \section{Singularity} Singularity\cite{singularity} とは,HPC環境向けに設計されたコンテナプラットフォームである. Singularityはマルチユーザに対応しており,コンテナ内での権限は実行ユーザの権限を引き継ぐため,ユーザに特別な権限の設定が必要ない. またデフォルトで,\$HOME,/tmp,/proc,/sys,/dev がコンテナにマウントされ,サーバ上のGPUを簡単に利用できる. コンテナイメージはSingularity Image Format(以下,sif)と呼ばれる単一ファイルベースのため,アーカイブや共有が容易である. \section{Slurm} Slurm\cite{slurm}はLinuxクラスタ向けのフォールトトレラント設計のジョブスケジューリングシステムである. Slurmには以下の3つの主要機能を提供する. \begin{itemize} \item 計算を実行するユーザに対してリソースへの排他的,非排他的なアクセスを割り当てる \item 割り当てられたノード上のジョブの開始,実行,モニタリングを行う \item 待機中のジョブキューを管理することにより,リソースの競合を解決する \end{itemize} \section{Ceph} Cephは,RedHat社が開発,提供する分散ファイルシステムである. Cephは分散オブジェクトストレージであるRADOS(Reliable Autonomic Distributred Object Storage)がベースとなっている. RAODSでは,Object Storage Daemonにデータ格納する. オブジェクトの配置には,クラスタマップを元に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互換のファイルシステムである. 複数のアクセス方法を提供することで,用途に合わせ柔軟に変更することができる. \section{教育情報システムの構築} 新システムは,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では実行できない. そこで,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} \bibitem{podman} Podman,https://podman.io/,2021/1/4. \bibitem{singularity} Singularity,https://sylabs.io/singularity/,2021/1/8. \bibitem{slurm} Slurm, https://slurm.schedmd.com/overview.html, 2021/1/14. \bibitem{ceph} Ceph,https://docs.ceph.com/en/latest/,2021/1/12. \bibitem{ie-virsh} 平良 太貴 and 河野 真治,OS 授業向けマルチユーザ VM 環境の構築,研究報告システムソフトウェアとオペレーティング・システム(OS)(2014). \bibitem{kido} 城戸翔太,安里悠矢,城間政司,長田智和,谷口祐治,"情報系学科における教育情報システムの構築及び運用管理に関する取り組み",研究報告インターネットと運用技術(IOT)(2016). \end{thebibliography} \nocite{*} \bibliographystyle{junsrt} \bibliography{reference} \end{document}