\chapter{教育情報システムの構築}

本章では，2020年9月に行われたシステム更新，演習や研究用に利用できる仮想環境について述べる．

\section{新システムのオンプレミス環境}
新システムでは，表\ref{tb:newserver}の汎用サーバを4台採用した．
旧システムのストレージはHDDであったが，ストレージの高速化を図りSSDを搭載した．
また，旧システムの課題でもあったGPUの要求に伴い，汎用サーバに演習や研究等で利用できるようGPUも搭載した．

\begin{table}[H]
  \begin{center}
    \caption{新システムの汎用サーバ}
    \begin{tabular}{|c|c|} \hline
	  CPU & Intel Xeon Gold 6238 (2.10GHz/22Core) \\ \hline
    CPUユニット数 & 2 \\ \hline
    GPU & Nvidia Tesla V100S \\ \hline
	  メモリ & 512GB\\ \hline
    SAS SSD & 5TB \\ \hline
    NVMe SSD & 1.5TB \\ \hline
    \end{tabular}
	\label{tb:newserver}
  \end{center}
\end{table}

次にユーザのデータなどを補完するために，表\ref{tb:newdiskserver}のストレージサーバを2台採用した．
2台のストレージサーバにはCephを構築するため，RAIDを構成せず利用する．
そのため，旧システムでは全体容量が40TBであったが，新システムでは90TBと増加した．

\begin{table}[H]
  \begin{center}
    \caption{新システムのストレージサーバ}
    \begin{tabular}{|c|c|} \hline
	  CPU & Intel Xeon Silver 4208\\ \hline
    メモリ & 32GB \\ \hline
	  SAS HDD & 300GB/15000rpm x 2 \\ \hline
    NLSAS HDD & 4TB/7200rpm x 12 \\ \hline
    \end{tabular}
	\label{tb:newdiskserver}
  \end{center}
\end{table}

新システムは，基幹サービスを主にコンテナで提供する．
これまでのシステムはVMベースでサービスを提供していたが，コンテナに移行することでリソースを効率よく利用し，管理を容易にする狙いがある．
また，基幹サービスのデータをSSD上に保存することで，サービスの高速化を図る．

\subsection{VM貸出サービスの移行}
旧システムではVMベースでシステムを構築していたが，新システムではコンテナベースでの構築行った．
システムはコンテナベースとなるが，VM貸出サービスであるAkatsuki，ie-virshは利用を継続する．
また，ie-virshは新たに以下の機能を追加した．
\begin{itemize}
    \item VMのテンプレートから差分で新しくVMを作成する
    \item 利用者が作成したVMのリソースを変更可能にする
\end{itemize}
新システムでは旧サーバと比べディスク容量が増加したため，VMイメージを汎用サーバのディスクドライブに保存する．
また，SSDの搭載によりVMの起動速度の高速化を図ることができる．
旧システムではVMの作成は申請が必要であったが，利用者は申請をせずVMを作成できるように機能を追加した．
しかし，利用者が制限なくVMを作成するとディスクリソースを圧迫する恐れがある．
そこで，VMの作成にはクローンではなく差分で作成することで，VMイメージサイズを小さくすることができる．

\subsection{コンテナ環境の導入}
新システムでもVM貸出サービスを継続するが，新しく搭載されるGPUをVMで利用するためにはPCIパススルーなどの設定が必要となる．
しかし，PCIパススルーでは，VMとGPUが1対1の関係になるため，GPU希望する利用者全てに割り当てることができない．
また，貸出VMは利用者の好み環境構築ができる反面，VMを作成するごとに同じような作業が必要となり利用者の手間となる．
そこで，アプリケーションの実行環境として採用されているコンテナ技術を利用する．
\par
システムは学生や教授などが利用するため，マルチユーザで利用できるコンテナエンジンが必要となる．
そのため，コンテナエンジンにはマルチユーザに対応しているPodmanとSingularityを採用する．
Podmanは開発段階でもあるため一部機能が不安定だったり，設定が上書きされる場合がある．
管理するシステム管理チームの学生の教育には適しているが，演習や研究用で利用するには適さない場合がある．
そのため，HPC環境に設計されているSingularityも同時に利用する．
\par
Singularityはコンテナ内で実行ユーザの権限を引き継ぐため，利用者が作成したプログラムの実行には向いている．
だが，Webなど特権が必要なサービスを実行することはできない．
特権が必要なWebなどをを実行する場合はPodmanを利用する．
Podmanはネットワーク設定を行うことで，コンテナ個別にIPアドレスを割り当てることができるが，ルートレスでは割り当てができない．
IPアドレスの割り当てにはネットワークデバイスの関連付けが必要だが，root権限が必要なためである．
rootlessでWebなどのサービスを実行しアクセスするにはポートフォワードを設定する必要がある．
だが，利用者が使用するポートを汎用サーバで開放することはセキュリティ的に対応できない．
そこで，Podmanをwrapperしたie-podmanを作成した．
ie-podmanはコンテナに個別のIPアドレスを割り当てる際に利用する．

\subsection{ジョブスケジューラの構築}
旧システムではVMベースのため，利用者が演習や研究等のプログラムは決められたリソースで実行する必要があった．
新システムはコンテナベースに変更したことにより，利用者は汎用サーバのリソースを利用できる．
そのため，複数の利用者が多くのリソースを要求するプログラムを実行した場合，リソース不足やリソースの競合が考えられる．
そこで，汎用サーバのリソースを効率よく利用できるようにするため，ジョブスケジューラであるSlurmにより管理を行う．
Slurmの利用方針として，最悪待ち時間を減らすのではなく，計算リソースの利用効率を上げることを重視する．
そのため，Jobの優先順位は以下のように設定を行う．
\begin{itemize}
    \item 要求するリソースの少ないJobの優先度を高くする
    \item 実行時間が短いJobの優先度を高くする
    \item これまでのJobの実行履歴で優先度は変化しない
\end{itemize}
また，Slurmに登録されるJobはバックフィルを採用する．
バックフィルは図\ref{fig:backfill}のように，後から投下されたJobが，現在処理されているJobの実行時間以内であり，空きリソースで処理可能ならば，先に投下されたJobより先に処理される．
\begin{figure}[H]
    \begin{center}
        \includegraphics[width=150mm]{fig/backfill.pdf}
    \end{center}
    \caption{バックフィル}
    \label{fig:backfill}
\end{figure}

\subsection{ファイルシステムの構築}
旧システムではVMのイメージをクラスタファイルシステムであるGFS2に保存し運用していた．
このGFS2の運用には別途クラスタを構成する必要があるため，単一障害の発生により多くのサービスに影響を与えることがあった．
また，ユーザのホームディレクトリもGFS2をマウントしたVMからNFSで提供されていた．
そのため，NFSを提供するVMが停止することでユーザへの影響があった．
そこで，新システムではVMイメージの保存には汎用サーバのディスクドライブ，ユーザのホームディレクトリにCephを採用する．
\par
新システムでは汎用サーバにSAS SSDが5TBと旧システムより多く搭載されている．
2台のサーバに演習や研究用で利用する貸出VMのイメージを保存し，残り2台には本コースで利用しているサービスを提供するVMを保存する．
汎用サーバに保存することで，単一障害時の影響を小さくすることができる．
Cephは自己修復と自己管理機能を持つため，信頼性の高いファイルシステムとして利用できる．
そのため，ユーザのホームディレクトリを配置するファイルシステムとして利用する．
また，CephはObject Gateway，ブロックデバイス，POSIX互換のファイルシステムなど，用途によって柔軟にアクセス方法を変更できる．
ブロックデバイスとしてアクセスすることでVMイメージのバックアップとしても利用できる．

\subsection{バックアップ戦略}
旧システムにはSAN用ストレージの他に大容量ストレージが導入されており，バックアップ用として利用されていた．
バックアップはWebやデータベース，ユーザのホームディレクトリなどを月に一度フルバックアップ，週に一度差分バックアップを行っていた．
しかし，新システムではストレージサーバ2台のため，毎月のフルバックアップではディスク容量を圧迫してしまう．
そこで，新システムでは，さくらインターネット株式会社(以下，さくらインターネット)が提供する専用サーバへバックアップを行う．
専用サーバは4TBのSASディスクを12台搭載しており，実行容量は24TBを有している．
その専用サーバへのバックアップはWebのデータ，ユーザのホームディレクトリをrsnapshotを用いて増分バックアップを行う．
旧システムより容量は少ないが，増分バックアップのため使用されるディスク領域を抑えることができる．
また，指定する数のスナップショットのみ保存するため，ディスク領域は継続的に増えることがない．
データの復元にはrsyncなどでコピーを行うだけのため，クラウドサーバであっても特定のファイルのみを迅速に復旧できる．
rsnapshotは以下のように設定を行い，1年分のデータを保存する．
\begin{itemize}
    \item 毎日0時に増分バックアップを実行し，最大7個のスナップショットを保存する
    \item 毎週月曜の9時に一週間分のスナップショットを取得し，最大4個のスナップショットを保存する
    \item 毎月1日の12時に1ヶ月分のスナップショットを取得し，最大12個のスナップショットを保存する
\end{itemize}

\subsection{構成}
新システムでは，各サーバに演習や研究用で利用できるPodmanとSingularityを用い，ジョブスケジューラであるSlurmを用いて管理を行う．
汎用サーバ1台をSlurmのコントローラ/計算ノードとし，残りは計算ノードとすることで，システムのリソースを最大限利用可能にする．
Cephはディスクサーバのみで構成するのではなく，汎用サーバ3台も含める．
ディスクサーバはOSDを持ち，汎用サーバがMON，MDS，MGRを担当する．
汎用サーバを含めることで，最大1台の障害を許容できるようになる．
そのため，利用者への影響を少なくすることができる．
これらの技術を用いて構成したシステム構成図を図\ref{fig:system}に示す．
\begin{figure}[H]
    \begin{center}
        \includegraphics[width=150mm]{fig/system.pdf}
    \end{center}
    \caption{システム構成図}
    \label{fig:system}
\end{figure}