Mercurial > hg > Papers > 2021 > mk-thesis

comparison paper/chapter/conclusion.tex @ 33:44a8408a59a6

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
update conclusion
author Ken Miyahira <e175733@ie.u-ryukyu.ac.jp>
date Sat, 06 Feb 2021 18:49:30 +0900
parents e32786ab9366
children 899991f158c2
comparison
equal deleted inserted replaced
32:09c722303c60 33:44a8408a59a6
1 \chapter{まとめ} 1 \chapter{まとめ}
2 2
3 本章では, 本論文で述べたことのまとめ, 今後の課題について述べる。
4
5 \section{総括}
6 本論文では, 2020年9月に行われたシステム更新を中心に, 本コースの学生や教師などが利用できる教育計算機システムの構築について述べた。
7 \par
8 以下, 本論文について振り返る。
9 \par
10 第1章では, 本研究の背景や目的, また本コースのシステムの運用管理を担当するシステム管理チームについて述べた。
11 \par
12 第2章では, 本研究で利用した技術概要について述べた。
13 \par
14 第3章では, 2015年から稼働していた旧システムのオンプレミス環境, 演習や研究等で利用できるVM貸出サービスについて述べ, これらの問題点を示した。
15 まず, VM貸出サービスにはAkatsukiとie-virshがあり, Akatsukiはテンプレートから新しくVMを作成し利用できるサービスである。
16 ie-virshは手元のPCで作成したVMイメージを学科サーバへデプロイを行うサービスである。
17 AkatsukiはVM貸出だけでなく, 有線LAN接続サービスの機能を持っているが, VM貸出サービスはあまり周知されていなかった。
18 また, VM貸出サービスは本コースの学生や教師が利用可能であるが, VMの作成やスペックの変更には申請が必要で余り利用されていなかった。
19 そのため, 旧システムの汎用サーバのリソースは余っていた。
20 \par
21 第4章では, 新システムで構築したオンプレミス環境, 仮想環境, 新たに導入したコンテナ環境やジョブスケジューラについて述べた。
22 また, これらのシステムでの構成についても述べた。
23 新システムでは新たにGPUが搭載され, 学生が利用できる環境が求められた。
24 そこで, VMベースでシステムを構築するのではなく, コンテナベースで構築した。
25 また, 学生もコンテナを利用できるよう, マルチユーザに対応しているSingularityとPodmanを導入した。
26 マルチユーザで利用できるため, リソースの競合を防ぐためにジョブスケジューラであるSlurmを導入した。
27 一方, ファイルシステムにはCephを採用した。
28 CephはRBDやブロックデバイス, POSIX互換のファイルシステムなど, 複数のアクセス方法が利用可能であるため, 用途により柔軟に対応することができる。
29 \par
30 第5章では, 第4章で構築したシステムの管理や利用方法について述べた。
31 システムのユーザの管理には旧システムと同様にLDAPを採用した。
32 また, 旧システムから移行し改良を加えたVM管理サービスの利用, 管理方法について述べた。
33 次に, 新しく導入したPodmanの利用方法, SingularityとSlurmを用いGPUを使用する方法について述べた。
34 \par
35 第6章では, 第4章で構築したシステムの評価について述べた。
36 %まず, 旧システムから利用するVM管理サービスの評価
37
3 \section{今後の課題} 38 \section{今後の課題}
39 \subsection{ie-podmanのネットワーク構成}
40 %ie-podmanのネットワーク構成, ip不足とか
41 rootlessのPodmanではコンテナに個別にIPアドレスを割り当てられないため, Podmanをwrapperしたie-podmanを作成した。
42 ie-podmanを利用することで, コンテナに個別にIPアドレスを割り当てられる。
43 しかし, 現在のネットワーク構成はプレフィックス長が24のため, 最大254個のIPアドレスしか割り当てできない。
44 コンテナを削除することでIPアドレスは返却されるが, コンテナを削除せず停止のままでは, 割り当て可能なIPアドレスが枯渇する。
45 そのため, ie-podmanが利用するネットワーク構成の変更を行うか, コンテナが停止のまま数日経つ場合にie-podmanから自動削除する必要がある。
46
47 \subsection{ジョブスケジューラの周知}
48 %ジョブスケジューラの周知, 投げ方やリソースの要求等
49 ジョブスケジューラの構成は汎用サーバ1台がログインノードと計算ノードを兼用し, 残りの3台が計算ノードとなっている。
50 コンテナからプログラムの実行はSlurmにJobを投下しなくても, ログインノードで実行できる。
51 また, GPUリソースを要求していなくても, SingularityやPodmanからGPUを使用るすことが可能である。
52 SlurmによるJobやリソースの管理を行うことで, 利用者同士のリソースの競合を防ぐことができる。
53 そのため, SlurmにJobの投下方法や必要なリソースの要求などを定期的な周知する必要がある。
54
55 \subsection{バックアップの運用}
56 %cephの運用, バックアップの保存場所等
57 新システムのバックアップにはCephとさくらインターネットが提供する専用サーバを利用している。
58 Cephはブロックデバイスとしアクセスを行い, XFSでフォーマットを行い利用する。
59 だが, 新システム構築の試験時にCephのMONのIPアドレスを変更後, Cephに保存したデータが全て取れない問題が発生した。
60 これはCephのMONがIPアドレスの変更を想定していないためであった。
61 これからCephを運用するにあたり障害が起きないとは限らない。
62 Cephは自己修復機能を搭載しているが, 万が一修復できない場合, ユーザのホームディレクトリや, バックアップデータが消える恐れがある。
63 その時に備え専用サーバにも保存しているが, 専用サーバではさくらインターネットからデータ取得するため, ホームディレクトリ等を復元するには時間が掛かる。
64 そのため, Cephと専用サーバ意外にもバックアップ先を用意する必要がある。