|
39
|
1 \chapter{教育情報システムの評価}
|
|
5
|
2
|
|
41
|
3 本章では，教育情報システムの評価を行う．
|
|
|
4 新たに採用したCephとの比較，VM貸出サービス，コンテナ環境の評価を述べる．
|
|
35
|
5
|
|
|
6 \section{ファイルシステムの評価}
|
|
|
7
|
|
41
|
8 旧システムのVM保存場所として利用していたGFS2，ユーザのホームディレクトリとして利用していたNFSとの速度比較を行う．
|
|
35
|
9
|
|
|
10 \subsection{実験概要}
|
|
|
11
|
|
41
|
12 実験に使用する汎用サーバ環境は，表\ref{tb:newserver}を使用する．
|
|
|
13 また，Cephの構成は図\ref{fig:system}となっている．
|
|
35
|
14 \par
|
|
41
|
15 ベンチマークにはddというファイル変換やコピーを目的としたGNU/Linuxのコアユーティリティを用いる．
|
|
|
16 ddは，低レベルのI/Oフロー制御機能を備えており，シーケンシャル書き込み，または読み取りの速度を測定できる．
|
|
|
17 データの変換方法にfdatasyncを指定することで，書き込み終了の直前にsyncを1回要求するため，実際の動作に近い動作で測定が可能である．
|
|
35
|
18 \par
|
|
49
|
19 書き込みにはソースコード\ref{pg:dd}のコマンドを用いる．
|
|
|
20 \begin{lstlisting}[caption=ベンチマークコマンド, label=pg:dd]
|
|
35
|
21 $ dd if=/dev/zero of=benchmark bs=64K count=2K conv=fdatasync
|
|
48
|
22 \end{lstlisting}
|
|
41
|
23 また，ファイルサイズは128MB，256MB，512MB，1GB，2GB，4GBの書き込みを行う．
|
|
|
24 5回測定を行い平均を比較する．
|
|
35
|
25
|
|
|
26 \subsection{ファイルシステムの速度比較}
|
|
41
|
27 図\ref{fig:write}はCephFS，Ceph RBD，GFS2，NFSにおけるファイルサイズに対する書き込み速度である．
|
|
35
|
28
|
|
|
29 \begin{figure}[H]
|
|
|
30 \begin{center}
|
|
|
31 \includegraphics[width=150mm]{file/benchmark/pdf/Write.pdf}
|
|
|
32 \end{center}
|
|
|
33 \caption{書込み速度の比較}
|
|
|
34 \label{fig:write}
|
|
|
35 \end{figure}
|
|
|
36
|
|
|
37 \subsection{考察}
|
|
41
|
38 旧システムのホームディレクトリは，iSCSI経由でマウントされたデバイスをNFSから提供していた．
|
|
|
39 iSCSIの通信には10Gbpsの回線で接続されているが，NFSの提供はVMで行われており，1Gbpsで提供されていた．
|
|
|
40 そのため，10Gbpsの回線で接続し，マウントしているCephでは書き込み速度の改善が見られる．
|
|
|
41 しかし，GFS2は10Gbpsで接続されたクラスタで構成されているが，Cephより低速である．
|
|
|
42 旧システムでは，パッケージ等のアップデートがされておらず，Kernelの更新もされていなかった．
|
|
|
43 KernelはI/Oに関する多くの機能を提供するため，GFS2の書き込みより，Cephが高速になったのではないかと考えられる．
|
|
35
|
44 \par
|
|
41
|
45 今回の計測では，読み込み速度の測定を行えなかった．
|
|
|
46 これは，旧システムで読み込み時にバッファキャッシュを削除せずに測定を行ったためである．
|
|
|
47 そのため，純粋な読み込み速度を測定することができなかったことは反省点である．
|
|
35
|
48
|
|
33
|
49 \section{VM貸出サービスの評価}
|
|
41
|
50 本コースのVM貸出サービスでは，VMの作成やスペックの変更にはシステム管理チームへの申請が必要であった．
|
|
|
51 これは，VMがリソースを過剰に使用できないようシステム管理チームで管理するためである．
|
|
|
52 VMの作成やスペックの変更申請が届くと，システム管理チームと利用者の間でやりとりを行い対応していた．
|
|
|
53 しかし，システム管理チームの状況によっては迅速に対応できず利用者を待たせることもあった．
|
|
|
54 新システムでは，VMの作成やスペックの変更はie-virshから対応できるようになり，システム管理チームや利用者の手間を減らすことが可能になった．
|
|
36
|
55 \par
|
|
41
|
56 また，これまでのVM貸出サービスはテンプレートのVMイメージをCloneしていたため，新しくVMを作成すると10GBの容量を使用していた．
|
|
|
57 そこで，ie-virshでは差分でVMを作成機能が追加され，新しく作成されるVMは数十MBになることで，使用するディスク容量を抑えることが可能になった．
|
|
7
|
58
|
|
36
|
59 \section{コンテナ環境の評価}
|
|
41
|
60 新しく導入したPodmanは，Dockerと同じCLIを提供するため，Dockerを利用したことがある学生は抵抗なく利用できる．
|
|
|
61 また，ie-podmanにより特権が必要な機能も，利用者に特別な権限を与えることなく利用できるようになる．
|
|
|
62 Singularityの導入により，GPUを手軽に利用できるため，演習や研究等での利用も広がると考えられる．
|
|
36
|
63 \par
|
|
41
|
64 VMでは新しく作成するたびに環境構築が必要であったが，コンテナイメージを作成することで環境構築は一度のみになる．
|
|
|
65 また，学科のレジストリーにイメージを登録することで，他の利用者に共有も可能となる．
|
|
|
66 Singularityでは単一ファイルのsifのコピーを配布することで，同じ環境でプログラムの実行することができる．
|
|
36
|
67 \par
|
|
41
|
68 これまでのVMベースのシステムから，コンテナベースのシステムへの移行により，汎用バーバのリソースを効率よく利用できる．
|
|
|
69 また，学生も気軽に利用できるようになったのではないかと考えられる． |
