view paper/chapter/conclusion.tex @ 37:e567e87d19f5

update conclusion
author Ken Miyahira <e175733@ie.u-ryukyu.ac.jp>
date Mon, 08 Feb 2021 20:19:13 +0900
parents 899991f158c2
children a967cf51ba92
line wrap: on
line source

\chapter{まとめ}

本章では, 本論文で述べたことのまとめ, 今後の課題について述べる。

\section{総括}
本論文では, 2020年9月に行われたシステム更新を中心に, 本コースの学生や教師などが利用できる教育計算機システムの構築について述べた。
\par
以下, 本論文について振り返る。
\par
第1章では, 本研究の背景や目的, また本コースのシステムの運用管理を担当するシステム管理チームについて述べた。
\par
第2章では, 本研究で利用した技術概要について述べた。
\par
第3章では, 2015年から稼働していた旧システムのオンプレミス環境, 演習や研究等で利用できるVM貸出サービスについて述べ, これらの問題点を示した。
まず, VM貸出サービスにはAkatsukiとie-virshがあり, Akatsukiはテンプレートから新しくVMを作成し利用できるサービスである。
ie-virshは手元のPCで作成したVMイメージを学科サーバへデプロイを行うサービスである。
AkatsukiはVM貸出だけでなく, 有線LAN接続サービスの機能を持っているが, VM貸出サービスはあまり周知されていなかった。
また, VM貸出サービスは本コースの学生や教師が利用可能であるが, VMの作成やスペックの変更には申請が必要で余り利用されていなかった。
そのため, 旧システムの汎用サーバのリソースは余っていた。
\par
第4章では, 新システムで構築したオンプレミス環境, 仮想環境, 新たに導入したコンテナ環境やジョブスケジューラについて述べた。
また, これらのシステムでの構成についても述べた。
新システムでは新たにGPUが搭載され, 学生が利用できる環境が求められた。
そこで, VMベースでシステムを構築するのではなく, コンテナベースで構築した。
また, 学生もコンテナを利用できるよう, マルチユーザに対応しているSingularityとPodmanを導入した。
マルチユーザで利用できるため, リソースの競合を防ぐためにジョブスケジューラであるSlurmを導入した。
一方, ファイルシステムにはCephを採用した。
CephはRBDやブロックデバイス, POSIX互換のファイルシステムなど, 複数のアクセス方法が利用可能であるため, 用途により柔軟に対応することができる。
\par
第5章では, 第4章で構築したシステムの管理や利用方法について述べた。
システムのユーザの管理には旧システムと同様にLDAPを採用した。
また, 旧システムから移行し改良を加えたVM管理サービスの利用, 管理方法について述べた。
次に, 新しく導入したPodmanの利用方法, SingularityとSlurmを用いGPUを使用する方法について述べた。
\par
第6章では, 第4章で構築したシステムの評価について述べた。
まず, ファイルシステムの評価を行う。
旧システムで利用していたGFS2, NFSとCephの比較を行い, 書き込み速度の改善が見られた。
次に, 旧システムから利用するVM貸出サービスの評価を行う。
VMの作成やスペックの変更を申請なしに利用できるようになり, 管理者と利用者の手間が省けた。
また, 差分による作成によりVMが使用する容量を小さくした。
一方, 新しくコンテナ環境を整えることで, システムのリソースを効率よく利用できるようにした。

\section{今後の課題}

本研究で構築した教育計算機システムの今後の課題について述べる。

\subsection{教育計算機システムの周知}
旧システムのVM貸出サービスは講義等で告知されたりしたが, 実際にはあまり周知されておらず利用も少なかった。
これは, システム管理チームからの利用方法について周知等が少なかったことも原因として挙げられる。
本研究で構築した教育計算機システムは, VMからコンテナまで利用できる。
だが, 利用は主にCLIから操作を行い, プログラムの実行にはSlurmを利用する。
VM貸出サービスの変更や, コンテナ環境の利用方法についてまとめる必要がある。
また, SlurmのJobの投下方法や必要なリソースの要求方法などをまとめ, 定期的な周知を行う必要がある。

\subsection{ie-podmanのネットワーク構成}
rootlessのPodmanではコンテナに個別にIPアドレスを割り当てられないため, Podmanをwrapperしたie-podmanを作成した。
ie-podmanを利用することで, コンテナに個別にIPアドレスを割り当てられる。
しかし, 現在のネットワーク構成はプレフィックス長が24のため, 最大254個のIPアドレスしか割り当てできない。
コンテナを削除することでIPアドレスは返却されるが, コンテナを削除せず停止のままでは, 割り当て可能なIPアドレスが枯渇する。
そのため, ie-podmanが利用するネットワーク構成の変更を行うか, コンテナが停止のまま数日経つ場合にie-podmanから自動削除する必要がある。

\subsection{バックアップの運用}
新システムのバックアップにはCephとさくらインターネットが提供する専用サーバを利用している。
Cephはブロックデバイスとしアクセスを行い, XFSでフォーマットを行い利用する。
だが, 新システム構築の試験時にCephのMONのIPアドレスを変更後, Cephに保存したデータが全て取れない問題が発生した。
これはCephのMONがIPアドレスの変更を想定していないためであった。
これからCephを運用するにあたり障害が起きないとは限らない。
Cephは自己修復機能を搭載しているが, 万が一修復できない場合, ユーザのホームディレクトリや, バックアップデータが消える恐れがある。
その時に備え専用サーバにも保存しているが, 専用サーバではさくらインターネットからデータ取得するため, ホームディレクトリ等を復元するには時間が掛かる。
そのため, Cephと専用サーバ意外にもバックアップ先を用意する必要がある。