|
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を利用したことがある学生は抵抗なく利用できる．
|
|
51
|
61 また，Singularityの導入により，GPUを手軽に利用できるため，演習や研究等での利用も広がると考えられる．
|
|
|
62 \par
|
|
|
63 RootlessのPodman，Singularityの不便な点を補うため，Podmanのwrapperであるie-podmanを作成した．
|
|
56
|
64 ie-podmanにより特権が必要な機能も，利用者に特別な権限を与えることなく利用できるようになる．
|
|
55
|
65 また，ie-podmanはrootfullのPodmanをwrapperすることにより，コンテナやイメージがSSD上に保存される．
|
|
51
|
66 そのため，rootlessのPodmanより高速化を図ることが可能になる．
|
|
36
|
67 \par
|
|
51
|
68 そこで，ie-podmanでのイメージのBuild速度の比較を行う．
|
|
|
69
|
|
|
70 \subsection{実験概要}
|
|
|
71 実験に使用する環境は，表\ref{tb:newserver}のサーバ1台を使用する．
|
|
|
72 一般的なコンテナエンジンであるDockerを含め，比較するコンテナエンジンは以下である．
|
|
|
73 \begin{itemize}
|
|
|
74 \item Docker
|
|
|
75 \item Podman (rootless)
|
|
|
76 \item ie-podman (Podman rootfull wrapper)
|
|
|
77 \end{itemize}
|
|
|
78
|
|
|
79 使用するDockerfileはソースコード\ref{pg:dockerfile}である．
|
|
|
80 また，時間の計測にはtimeコマンドを使用する．
|
|
|
81
|
|
|
82 \begin{lstlisting}[caption=Dockerfile, label=pg:dockerfile]
|
|
|
83 FROM ubuntu:20.04
|
|
|
84 RUN apt-get update && \
|
|
|
85 apt-get upgrade -y
|
|
|
86 \end{lstlisting}
|
|
|
87
|
|
|
88 \subsection{イメージのBuild速度比較}
|
|
|
89 図\ref{fig:ie-podman-review}はDocker, Podman, ie-podmanにおけるイメージのBuild速度である．
|
|
|
90 \begin{figure}[H]
|
|
|
91 \begin{center}
|
|
|
92 \includegraphics[width=150mm]{file/benchmark/pdf/container2.pdf}
|
|
|
93 \end{center}
|
|
|
94 \caption{書込み速度の比較}
|
|
|
95 \label{fig:ie-podman-review}
|
|
|
96 \end{figure}
|
|
|
97
|
|
|
98 \subsection{考察}
|
|
|
99 Dockerやie-podmanのBuildに掛かる時間は1分未満だが，rootlessのPodmanでは3分程掛かっている．
|
|
|
100 RootlessのPodmanはコンテナイメージをユーザのホームディレクトリに保存する．
|
|
|
101 また，rootlessでは重複排除をサポートしていないVFSストレージに制限される．
|
|
|
102 RootlessのPodmanは独自の名前空間内で特権機能を利用できるようにするため，rootfullと比べ経由する関数が多くなる．
|
|
|
103 そのため，rootlessではrootfullと比べsyscallが多く呼ばれることにより，他と比べイメージのBuild速度が遅くなっているのではないかと考える． |
