\chapter{Shien システムの評価}

本章では Shien システムの評価を行う。新たに使用した GFS2 との比較と、授業で使用した際の評価を述べる。

\section{実験環境}

Shien システムの検証目的の一つは、本学科の次期システムでの使用を検討するためである。評価には本学科でのブレードサーバ環境を使用した。ブレードサーバの仕様は表\ref{tab:server_spec}となっている。

\begin{table}[!htbp]
\caption{ブレードサーバの仕様}
\label{tab:server_spec}
  \begin{center}
    \begin{tabular}{|c||c|} \hline
      名前 & 概要 \\ \hline \hline
      CPU & Intel(R) Xeon(R) CPU X5650@2.67GHz \\ \hline
      物理コア数 & 12 \\ \hline
      論理コア数 & 24 \\ \hline
      Memory & 132GB \\ \hline
      OS & Fedora 20 \\ \hline
    \end{tabular}
  \end{center}
\end{table}


現在の本学科のブレードサーバと接続されているストレージは Fibre Channel ストレージである。そのため Fibre Channel ストレージを用いて GFS2 の性能計測を行った。

\section{実験概要}

ベンチマークは Filebench というベンチマークツールを用いて行った。Filebench はファイルシステムパフォーマンスの測定と比較のためにファイルシステムのワークロードをフレームワーク化したものである。シンプルなワークロード構築用の言語 .f 言語が搭載されている。

Filebench は .f 言語で書かれた基本的なワークロードを持っている。今回はそのワークロード randomread.f と randomwrite.f を用いて計測を行った。

\section{Filesystem の速度比較}

図\ref{fig:filesystem_randomread}と図\ref{fig:filesystem_randomwrite}は ext4 、ZFS 、GFS2 における読み書きを行うファイルのサイズに対する速度である。

\begin{figure}[htpb]
  \begin{center}
    \includegraphics[scale=1.0]{gnuplot/filesystem_read_bench.pdf}
    \caption{Filesystem ごとの Random read 性能比較}
    \label{fig:filesystem_randomread}
  \end{center}
\end{figure}

\begin{figure}[htpb]
  \begin{center}
    \includegraphics[scale=1.0]{gnuplot/filesystem_write_bench.pdf}
    \caption{Filesystem ごとの Random write 性能比較}
    \label{fig:filesystem_randomwrite}
  \end{center}
\end{figure}

\subsection{考察}

Linux の標準的に使用されている Filesystem の ext4 は、Linux から直接アクセスされるため高速である。しかし今回の計測結果では、GFS2 の読み込み速度は ext4 と殆ど変わらない。読み込み速度に関しては、Linux のローカルファイルと同等の速度で読み込める。

そのためアプリケーションや VM が GFS2 上にあったとしても、読み込み速度はローカルディスクと変わらないため GFS2 が原因で速度が低下することはないと考えられる。

また Write に関してもファイルサイズが 100 MB の場合までは ext4 と比べ殆ど変わらない速度となっている。しかし 1GB 以上の大きなファイルへの読み込み速度は ZFS とともに極端に落ちてしまう。

VM は内部で VM イメージに対して停止した時に書き込むため、VM が停止した際の書き込み量によっては極端に遅くなると考えられる。

\section{GFS2 上の複数ノードの計測}

図\ref{fig:3node_randomread}と図\ref{fig:3node_randomwrite}は GFS2 の Fibre Channel ストレージを、同時に複数のブレードサーバから読み書きしたものである。読み書きしたファイルは別々のディレクトリにある。

\begin{figure}[htpb]
  \begin{center}
    \includegraphics[scale=1.0]{gnuplot/3node_read_bench.pdf}
    \caption{GFS2 から参照したノード数ごとの Random read 性能比較}
    \label{fig:3node_randomread}
  \end{center}
\end{figure}

\begin{figure}[htpb]
  \begin{center}
    \includegraphics[scale=1.0]{gnuplot/3node_write_bench.pdf}
    \caption{GFS2 から参照したノード数ごとの Random write 性能比較}
    \label{fig:3node_randomwrite}
  \end{center}
\end{figure}

\subsection{考察}

GFS2 のロック機構、DLM は inode ごとにロックを管理している。そのため全く同一のファイルに対して読み書きを行わなければ、一定の速度で読み書きすることができる。今回計測を行った 3 ノードからのアクセスでも殆ど変わらない結果が見て取れる。

\section{VM とコンテナとの比較}

図\ref{fig:vmconrandomread}と図\ref{fig:vmconrandomwrite} はベンチマークをホストから GFS2 を計測した場合と、VM とコンテナ上から計測した場合のグラフである。VM は Fibre Channel ストレージ上に VM イメージを置き、KVM を Hypervisor として起動した VM 内から Filebench を使用しベンチマークを計測した。 

\begin{figure}[htpb]
  \begin{center}
    \includegraphics[scale=1.0]{gnuplot/each_guest_read_bench.pdf}
    \caption{VM 、コンテナの Random read 性能比較}
    \label{fig:vmconrandomread}
  \end{center}
\end{figure}

\begin{figure}[htpb]
  \begin{center}
    \includegraphics[scale=1.0]{gnuplot/each_guest_write_bench.pdf}
    \caption{VM、コンテナの Random write 性能比較}
    \label{fig:vmconrandomwrite}
  \end{center}
\end{figure}

\subsection{考察}

コンテナとホストからの計測は、Read と Write の性能ともに殆ど変わらないため、コンテナは直接の計算機からの Read や Write と変わらず使用することができる。

しかし VM に関しては、Read や Write ともに性能が低下している。Docker はホストと Linux kernel を共有しているため、IO が高速である。Docker と異なり VM はハードウエアもエミュレートしているため、速度が低下する。

Read と Write の多いアプリケーションを実装する場合はコンテナを使用するのがよい。VM は Kernel も独立に動作するため、Linux 以外の OS を動作させる場合に使用する。

\section{授業 Operating System での使用}

情報工学科では Operating System という授業が行われている。授業 Operating System で実際に ie-virsh を使用した。複数人の学生による VM の使用を、管理側の負担を抑えて管理することができた。

授業ではまず、受講生が自身の PC で VM を install し環境設定する。今回は Vagrant を使用した。Vagrant は Virtual Box を利用するため、VM image の形式も Virtual Box に則した ovf 形式である。設定した ovf 形式の VM image を Fibre Channel ストレージ上にアップロードし、KVM で起動することのできる形式 qcow2 へ変換する。

その VM image を元に ie-virsh で VM を起動する。

\section{外部へ公開}

本学科では学生に向けてグローバル IP アドレスを配布しており、ie-virsh で管理される VM はグローバル IP アドレスを割り当て、公開していた。

しかし授業 Operating System での使用の際、全ての VM にグローバル IP アドレスを割り当てていたため、学生に VM のセキュリティ設定が委ねられていた。

授業の課題のために起動し放置していた、外部からの攻撃に対して脆弱な VM があった場合は VM の停止を呼びかけるか、VM のPort やユーザ名、パスワードが脆弱でないか調査する仕組みが必要である。


\section{Vagrant}

Vagrant は異なる環境に移行可能な開発環境を構築・管理・配布することができる開発環境作成ツールである。手軽にテスト環境を導入・破棄することができ、変更が加わっても開発環境・本番環境に自動的に適用できる。

VirtaulBox などのプロバイダを使って、VM を Vagrant 経由で立ち上げる。手軽に起動・停止・ssh ログインできるため、Web サービスの開発や開発環境の配布などに利用される。 

Vagrant は KVM をプロバイダとするプラグインを持っており、 KVM を VirtualBox のようにプロバイダとして動作させることができる。KVM 上の VM を Vagrant の操作と同じように起動・停止・設定することが可能となっている。

\section{Vagrant Box}
 Vagrant で VM を利用する際に、VM のベースとなるイメージファイルが Vagrant Box である。 Vagrant で Vagrant Box を VM イメージとして起動し、設定し、開発環境を配布することができる。また配布されている Vagrant Box を取得して起動し、使用することができる。

\section{Vagrant Box について}

授業 Operating System では、ie-virsh の VM イメージに Vagrant Box を使用した。受講者の PC 上で Vagrant を使って開発環境を作成させ、その VM イメージをブレードサーバにアップロードして変換し、ie-virsh で起動する。そうすることで Vagrant で作成した開発環境を ie-virsh からそのまま使用することができる。

Vagrant Box イメージは簡易なパスワードとユーザ名で Vagrant から管理されていたため、そのままブレードサーバへアップロードしサーバ用途に使用してしまうと、簡単に外部から侵入され乗っ取られてしまう。そのため Vagrant Box イメージを使用する際は、外部から攻撃されないような設定か確認し、脆弱な設定なら設定し直す必要がある。

\section{さくらクラウド}

さくらインターネット株式会社\cite{sakura}の運営する、高性能なサーバと拡張性の高いネットワークをクラウド上に自在に構築できるパブリッククラウドサービスである。次期システムでクラウドサービスとして使用する予定となっている。

\section{さくらクラウドへの VM イメージ送信}

クラウドサービスへのサービスのデプロイ方法の一つとして、VM イメージを直接クラウドサービスにアップロードするという方法がある。

本学科のブレードサーバから、VM イメージをさくらインターネットの石狩リージョンへ向けて送信した。さくらクラウドへ VM イメージを送信する場合、まずアーカイブを作成する。作成後に FTPS の URL とホスト名・パスワードが表示される。その情報を使用して curl を使い FTPS 接続し送信する。

\begin{verbatim}
% curl --ftp-ssl -T fedora20.img ftp://username:password@hostname:21
\end{verbatim}

送信時間は表\ref{tab:vmimgsend}のようになる。

\begin{table}[!htbp]
\caption{VM イメージ送信}
\label{tab:vmimgsend}
  \begin{center}
    \begin{tabular}{|c||c|} \hline
      VM イメージサイズ & 10.0 GB \\ \hline
      VM イメージ形式 & raw \\ \hline
      送信速度 & 34.9 M  \\ \hline
      送信時間 & 00:04:53 \\ \hline
    \end{tabular}
  \end{center}
\end{table}

授業 Operating System で使用すると、一回で 60 名の受講生が VM をさくらクラウドへ向けて送信するため、現実的ではない。そのため VM 以外の方法を使う必要がある。