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