Mercurial > hg > Papers > 2021 > mk-thesis
annotate paper/chapter/new_system.tex @ 64:f2bc4135c9a6 default tip
del comment
| author | Ken Miyahira <e175733@ie.u-ryukyu.ac.jp> |
|---|---|
| date | Tue, 16 Feb 2021 00:55:48 +0900 |
| parents | 5334697f98bf |
| children |
| rev | line source |
|---|---|
| 39 | 1 \chapter{教育情報システムの構築} |
| 21 | 2 |
| 40 | 3 本章では，2020年9月に行われたシステム更新，演習や研究用に利用できる仮想環境について述べる． |
| 21 | 4 |
| 5 \section{新システムのオンプレミス環境} | |
| 40 | 6 新システムでは，表\ref{tb:newserver}の汎用サーバを4台採用した． |
| 7 旧システムのストレージはHDDであったが，ストレージの高速化を図りSSDを搭載した． | |
| 51 | 8 また，旧システムの課題でもあったGPUの要求に伴い，汎用サーバに演習や研究等で利用できるようGPUも搭載した． |
| 21 | 9 |
| 10 \begin{table}[H] | |
| 11 \begin{center} | |
| 47 | 12 \caption{新システムの汎用サーバ} |
| 21 | 13 \begin{tabular}{|c|c|} \hline |
| 14 CPU & Intel Xeon Gold 6238 (2.10GHz/22Core) \\ \hline | |
| 15 CPUユニット数 & 2 \\ \hline | |
| 16 GPU & Nvidia Tesla V100S \\ \hline | |
| 17 メモリ & 512GB\\ \hline | |
| 18 SAS SSD & 5TB \\ \hline | |
| 19 NVMe SSD & 1.5TB \\ \hline | |
| 20 \end{tabular} | |
| 21 \label{tb:newserver} | |
| 22 \end{center} | |
| 23 \end{table} | |
| 24 | |
| 40 | 25 次にユーザのデータなどを補完するために，表\ref{tb:newdiskserver}のストレージサーバを2台採用した． |
| 26 2台のストレージサーバにはCephを構築するため，RAIDを構成せず利用する． | |
| 27 そのため，旧システムでは全体容量が40TBであったが，新システムでは90TBと増加した． | |
| 21 | 28 |
| 29 \begin{table}[H] | |
| 30 \begin{center} | |
| 31 \caption{新システムのストレージサーバ} | |
| 32 \begin{tabular}{|c|c|} \hline | |
| 33 CPU & Intel Xeon Silver 4208\\ \hline | |
| 34 メモリ & 32GB \\ \hline | |
| 35 SAS HDD & 300GB/15000rpm x 2 \\ \hline | |
| 36 NLSAS HDD & 4TB/7200rpm x 12 \\ \hline | |
| 37 \end{tabular} | |
| 38 \label{tb:newdiskserver} | |
| 39 \end{center} | |
| 40 \end{table} | |
| 41 | |
| 51 | 42 新システムは，基幹サービスを主にコンテナで提供する． |
| 43 これまでのシステムはVMベースでサービスを提供していたが，コンテナに移行することでリソースを効率よく利用し，管理を容易にする狙いがある． | |
| 44 また，基幹サービスのデータをSSD上に保存することで，サービスの高速化を図る． | |
| 45 | |
|
31
acbdce4a79d7
update newsystem section title
Ken Miyahira <e175733@ie.u-ryukyu.ac.jp>
parents:
29
diff
changeset
|
46 \subsection{VM貸出サービスの移行} |
| 40 | 47 旧システムではVMベースでシステムを構築していたが，新システムではコンテナベースでの構築行った． |
| 45 | 48 システムはコンテナベースとなるが，VM貸出サービスであるAkatsuki，ie-virshは利用を継続する． |
| 40 | 49 また，ie-virshは新たに以下の機能を追加した． |
| 21 | 50 \begin{itemize} |
| 40 | 51 \item VMのテンプレートから差分で新しくVMを作成する |
| 52 \item 利用者が作成したVMのリソースを変更可能にする | |
| 21 | 53 \end{itemize} |
| 40 | 54 新システムでは旧サーバと比べディスク容量が増加したため，VMイメージを汎用サーバのディスクドライブに保存する． |
| 55 また，SSDの搭載によりVMの起動速度の高速化を図ることができる． | |
| 56 旧システムではVMの作成は申請が必要であったが，利用者は申請をせずVMを作成できるように機能を追加した． | |
| 57 しかし，利用者が制限なくVMを作成するとディスクリソースを圧迫する恐れがある． | |
| 58 そこで，VMの作成にはクローンではなく差分で作成することで，VMイメージサイズを小さくすることができる． | |
| 21 | 59 |
|
31
acbdce4a79d7
update newsystem section title
Ken Miyahira <e175733@ie.u-ryukyu.ac.jp>
parents:
29
diff
changeset
|
60 \subsection{コンテナ環境の導入} |
| 40 | 61 新システムでもVM貸出サービスを継続するが，新しく搭載されるGPUをVMで利用するためにはPCIパススルーなどの設定が必要となる． |
| 62 しかし，PCIパススルーでは，VMとGPUが1対1の関係になるため，GPU希望する利用者全てに割り当てることができない． | |
| 63 また，貸出VMは利用者の好み環境構築ができる反面，VMを作成するごとに同じような作業が必要となり利用者の手間となる． | |
| 64 そこで，アプリケーションの実行環境として採用されているコンテナ技術を利用する． | |
| 21 | 65 \par |
| 40 | 66 システムは学生や教授などが利用するため，マルチユーザで利用できるコンテナエンジンが必要となる． |
| 67 そのため，コンテナエンジンにはマルチユーザに対応しているPodmanとSingularityを採用する． | |
| 68 Podmanは開発段階でもあるため一部機能が不安定だったり，設定が上書きされる場合がある． | |
| 69 管理するシステム管理チームの学生の教育には適しているが，演習や研究用で利用するには適さない場合がある． | |
| 70 そのため，HPC環境に設計されているSingularityも同時に利用する． | |
| 21 | 71 \par |
| 40 | 72 Singularityはコンテナ内で実行ユーザの権限を引き継ぐため，利用者が作成したプログラムの実行には向いている． |
| 73 だが，Webなど特権が必要なサービスを実行することはできない． | |
| 74 特権が必要なWebなどをを実行する場合はPodmanを利用する． | |
| 75 Podmanはネットワーク設定を行うことで，コンテナ個別にIPアドレスを割り当てることができるが，ルートレスでは割り当てができない． | |
| 76 IPアドレスの割り当てにはネットワークデバイスの関連付けが必要だが，root権限が必要なためである． | |
| 77 rootlessでWebなどのサービスを実行しアクセスするにはポートフォワードを設定する必要がある． | |
| 51 | 78 だが，利用者が使用するポートを汎用サーバで開放することはセキュリティ的に対応できない． |
| 40 | 79 そこで，Podmanをwrapperしたie-podmanを作成した． |
| 80 ie-podmanはコンテナに個別のIPアドレスを割り当てる際に利用する． | |
| 21 | 81 |
|
31
acbdce4a79d7
update newsystem section title
Ken Miyahira <e175733@ie.u-ryukyu.ac.jp>
parents:
29
diff
changeset
|
82 \subsection{ジョブスケジューラの構築} |
| 40 | 83 旧システムではVMベースのため，利用者が演習や研究等のプログラムは決められたリソースで実行する必要があった． |
| 84 新システムはコンテナベースに変更したことにより，利用者は汎用サーバのリソースを利用できる． | |
| 85 そのため，複数の利用者が多くのリソースを要求するプログラムを実行した場合，リソース不足やリソースの競合が考えられる． | |
| 86 そこで，汎用サーバのリソースを効率よく利用できるようにするため，ジョブスケジューラであるSlurmにより管理を行う． | |
| 51 | 87 Slurmの利用方針として，最悪待ち時間を減らすのではなく，計算リソースの利用効率を上げることを重視する． |
| 40 | 88 そのため，Jobの優先順位は以下のように設定を行う． |
| 29 | 89 \begin{itemize} |
| 90 \item 要求するリソースの少ないJobの優先度を高くする | |
| 91 \item 実行時間が短いJobの優先度を高くする | |
| 92 \item これまでのJobの実行履歴で優先度は変化しない | |
| 93 \end{itemize} | |
| 40 | 94 また，Slurmに登録されるJobはバックフィルを採用する． |
| 95 バックフィルは図\ref{fig:backfill}のように，後から投下されたJobが，現在処理されているJobの実行時間以内であり，空きリソースで処理可能ならば，先に投下されたJobより先に処理される． | |
| 29 | 96 \begin{figure}[H] |
| 97 \begin{center} | |
| 98 \includegraphics[width=150mm]{fig/backfill.pdf} | |
| 99 \end{center} | |
| 100 \caption{バックフィル} | |
| 101 \label{fig:backfill} | |
| 102 \end{figure} | |
| 103 | |
|
31
acbdce4a79d7
update newsystem section title
Ken Miyahira <e175733@ie.u-ryukyu.ac.jp>
parents:
29
diff
changeset
|
104 \subsection{ファイルシステムの構築} |
| 40 | 105 旧システムではVMのイメージをクラスタファイルシステムであるGFS2に保存し運用していた． |
| 106 このGFS2の運用には別途クラスタを構成する必要があるため，単一障害の発生により多くのサービスに影響を与えることがあった． | |
| 107 また，ユーザのホームディレクトリもGFS2をマウントしたVMからNFSで提供されていた． | |
| 108 そのため，NFSを提供するVMが停止することでユーザへの影響があった． | |
| 109 そこで，新システムではVMイメージの保存には汎用サーバのディスクドライブ，ユーザのホームディレクトリにCephを採用する． | |
| 21 | 110 \par |
| 40 | 111 新システムでは汎用サーバにSAS SSDが5TBと旧システムより多く搭載されている． |
| 112 2台のサーバに演習や研究用で利用する貸出VMのイメージを保存し，残り2台には本コースで利用しているサービスを提供するVMを保存する． | |
| 113 汎用サーバに保存することで，単一障害時の影響を小さくすることができる． | |
| 114 Cephは自己修復と自己管理機能を持つため，信頼性の高いファイルシステムとして利用できる． | |
| 115 そのため，ユーザのホームディレクトリを配置するファイルシステムとして利用する． | |
| 116 また，CephはObject Gateway，ブロックデバイス，POSIX互換のファイルシステムなど，用途によって柔軟にアクセス方法を変更できる． | |
| 117 ブロックデバイスとしてアクセスすることでVMイメージのバックアップとしても利用できる． | |
| 21 | 118 |
|
31
acbdce4a79d7
update newsystem section title
Ken Miyahira <e175733@ie.u-ryukyu.ac.jp>
parents:
29
diff
changeset
|
119 \subsection{バックアップ戦略} |
| 40 | 120 旧システムにはSAN用ストレージの他に大容量ストレージが導入されており，バックアップ用として利用されていた． |
| 121 バックアップはWebやデータベース，ユーザのホームディレクトリなどを月に一度フルバックアップ，週に一度差分バックアップを行っていた． | |
| 122 しかし，新システムではストレージサーバ2台のため，毎月のフルバックアップではディスク容量を圧迫してしまう． | |
| 123 そこで，新システムでは，さくらインターネット株式会社(以下，さくらインターネット)が提供する専用サーバへバックアップを行う． | |
| 124 専用サーバは4TBのSASディスクを12台搭載しており，実行容量は24TBを有している． | |
| 125 その専用サーバへのバックアップはWebのデータ，ユーザのホームディレクトリをrsnapshotを用いて増分バックアップを行う． | |
| 126 旧システムより容量は少ないが，増分バックアップのため使用されるディスク領域を抑えることができる． | |
| 127 また，指定する数のスナップショットのみ保存するため，ディスク領域は継続的に増えることがない． | |
| 128 データの復元にはrsyncなどでコピーを行うだけのため，クラウドサーバであっても特定のファイルのみを迅速に復旧できる． | |
| 129 rsnapshotは以下のように設定を行い，1年分のデータを保存する． | |
| 25 | 130 \begin{itemize} |
| 40 | 131 \item 毎日0時に増分バックアップを実行し，最大7個のスナップショットを保存する |
| 132 \item 毎週月曜の9時に一週間分のスナップショットを取得し，最大4個のスナップショットを保存する | |
| 133 \item 毎月1日の12時に1ヶ月分のスナップショットを取得し，最大12個のスナップショットを保存する | |
| 25 | 134 \end{itemize} |
| 135 | |
| 21 | 136 \subsection{構成} |
| 40 | 137 新システムでは，各サーバに演習や研究用で利用できるPodmanとSingularityを用い，ジョブスケジューラであるSlurmを用いて管理を行う． |
| 138 汎用サーバ1台をSlurmのコントローラ/計算ノードとし，残りは計算ノードとすることで，システムのリソースを最大限利用可能にする． | |
| 139 Cephはディスクサーバのみで構成するのではなく，汎用サーバ3台も含める． | |
| 140 ディスクサーバはOSDを持ち，汎用サーバがMON，MDS，MGRを担当する． | |
| 141 汎用サーバを含めることで，最大1台の障害を許容できるようになる． | |
| 142 そのため，利用者への影響を少なくすることができる． | |
| 143 これらの技術を用いて構成したシステム構成図を図\ref{fig:system}に示す． | |
| 21 | 144 \begin{figure}[H] |
| 145 \begin{center} | |
| 146 \includegraphics[width=150mm]{fig/system.pdf} | |
| 147 \end{center} | |
| 148 \caption{システム構成図} | |
| 149 \label{fig:system} | |
| 150 \end{figure} |