view paper/chapter5.tex @ 13:db3b8eaba7b0 default tip

add presen
author sugi
date Fri, 22 Feb 2013 16:18:39 +0900
parents 52dff3fd4f40
children
line wrap: on
line source

\chapter{スケーラビリティの評価}
\label{chap:experiment}
前章ではAliceによって作成されたアプリケーションについて説明した。本章ではAliceがスケーラビリティを持つかどうかの実験方法その結果についてまとめを行い、Aliceを評価する。
\section{実験方法}
Aliceがスケーラビリティを持っているかどうかを実験するために、学科にある教養のブレードサーバーと並列信頼研で管理しているブレードサーバーを用いた。それぞれVMwareとKVMという仮想化ソフトウェアで管理されている。また、実験を行う際にTORQUE Resource Managerというジョブスケジューラーを使用した。

\subsection{TORQUE Resource Manager}
TORQUE Resource Managerは計算機クラスターのジョブを管理するジョブスケジューラである。
構成は、ジョブを管理するヘッドノード、及び実際の計算を行う計算ノードから構成される。


ヘッドノードからシェルスクリプトで記述されたジョブをスケジューラーに渡す。
この際に、利用したいマシン台数、CPUコア数等をしてすることができる。
スケジューラーは計算ノードのリソース状況を見て投入されたジョブを計算ノードへ伝える。


\subsection{実験環境}
今回はブレードサーバー(表 \ref{tb:blade8})上でVMwareにより管理されている仮想マシン(表 \ref{tb:VMware})よる仮想クラスタ環境とブレードサーバー(表 \ref{tb:blade3})上でKVMにより管理されている仮想マシン(表 \ref{tb:KVM})よる仮想クラスタ環境を用いて実験した。

\begin{table}[htbp]
\caption{共有ブレードサーバーの詳細}
\label{tb:blade8}
\begin{center}
\begin{tabular} {|l|l|}
  \hline1
  {\bf マシン台数}&8台\\
  \hline
  {\bf CPU}&Intel(R) Xeon(R) X5650 @ 2.67GHz\\
  \hline
  {\bf 物理コア数}&12\\
  \hline
  {\bf 論理コア数}&24\\
  \hline
  {\bf CPU キャッシュ}&12MB\\
  \hline
  {\bf Memory}&132GB\\
  \hline
\end{tabular}
\end{center}
\end{table}

\begin{table}[htbp]
\caption{仮想クラスタの詳細}
\label{tb:VMware}
\begin{center}
\begin{tabular} {|l|l|}
  \hline
  {\bf マシン台数}&44台\\
  \hline
  {\bf CPU}&Intel(R) Xeon(R) X5650 @ 2.67GHz\\
  \hline
  {\bf 物理コア数}&2\\
  \hline
  {\bf 仮想コア数}&4\\
  \hline
  {\bf CPU キャッシュ}&12MB\\
  \hline
  {\bf Memory}&8GB\\
  \hline
\end{tabular}
\end{center}
\end{table}

\begin{table}[htbp]
\caption{並列信頼研ブレードサーバーの詳細}
\label{tb:blade3}
\begin{center}
\begin{tabular} {|l|l|}
  \hline1
  {\bf マシン台数}&3台\\
  \hline
  {\bf CPU}&Intel(R) Xeon(R) X5650 @ 2.67GHz\\
  \hline
  {\bf 物理コア数}&12\\
  \hline
  {\bf 論理コア数}&24\\
  \hline
  {\bf CPU キャッシュ}&12MB\\
  \hline
  {\bf Memory}&132GB\\
  \hline
\end{tabular}
\end{center}
\end{table}

\begin{table}[htbp]
\caption{仮想クラスタの詳細}
\label{tb:KVM}
\begin{center}
\begin{tabular} {|l|l|}
  \hline
  {\bf マシン台数}&16台\\
  \hline
  {\bf CPU}&Intel(R) Xeon(R) X5650 @ 2.67GHz\\
  \hline
  {\bf 物理コア数}&2\\
  \hline
  {\bf 仮想コア数}&4\\
  \hline
  {\bf CPU キャッシュ}&12MB\\
  \hline
  {\bf Memory}&8GB\\
  \hline
\end{tabular}
\end{center}
\end{table}

\section{実験概要}
TopologyManagerを使用して仮想クラスタサーバー16台、44台を任意のツリー状に構成する。トップノードから子ノードに対してData Segmentを送信し、Data Segmentがツリーの最下層まで伝搬されトップノードに戻ってくるまでの時間を測定する。1台に43台を繋げた際の平均応答時間よりもツリー状に構成した時の平均応答時間が短ければ、Aliceがスケーラビリティを持つということがいえる。


またKVMとVMwareどちらの環境が良いかという比較を行う。

\begin{figure}[htbp]
\begin{center}
\includegraphics[width=160mm]{fig/experiment.pdf}
\end{center}
\caption{Data Segmentを送信して戻ってくるまでの時間を測定する}
\label{fig:experiment}
\end{figure}

図\ref{fig:experiment}のように親に接続しているノードの個数が2台の場合、ここでは便宜上二分木と呼ぶこととする。更に図\ref{fig:experiment}の場合親を除いて2段層があるのでこの場合は、二分木二段と呼ぶ。

\begin{figure}[htbp]
\begin{center}
\includegraphics[width=170mm,height=75mm]{fig/bitree.pdf}
\end{center}
\caption{二分木五段}
\label{fig:bitree}
\end{figure}
二分木五段(図 \ref{fig:bitree})、三分木三段、四分木三段、六分木二段のツリーを構成し、その応答時間を計測した。


\section{実験結果}
実験結果は(図\ref{fig:cs-result})のようになった。


1台に43台を繋げるよりも、ツリー状にトポロジーを形成したほうが応答時間が短くなることがわかる。しかし、16台の場合だと15台を1台に接続をさせたほうが二分木、三分木を構成するよりも早いという結果になっている。
特に四分木三段で構成した場合1台に集中させるよりも2.5ms早く応答時間が全体に行き渡る事がわかった。
KVMとVMwareの比較の方ではKVMのほうがVMwareよりも1.8倍程度遅い。


\begin{figure}[htbp]
\begin{center}
\includegraphics[width=160mm]{fig/cs-result.pdf}
\end{center}
\caption{44台における様々なツリー状の応答時間}
\label{fig:cs-result}
\end{figure}

\begin{figure}[htbp]
\begin{center}
\includegraphics[width=160mm]{fig/compare.pdf}
\end{center}
\caption{16台における様々なツリー状の応答時間}
\label{fig:compare}
\end{figure}


\section{考察}
44台の結果からは(図\ref{fig:cs-result})Aliceがスケーラビリティを持つということがわかった。しかし、16台で構成した際には1台に接続をしたほうが良いという結果になってしまっている。これは1段間に入ると2ms遅くなってしまう。ノード間の通信自体が現在遅いので調整する必要がある。
全体の応答時間を良くするためには1台に接続を集中させ過ぎないということもあるがしかし、二分木五段のように段差を増やしすぎてもかえって応答時間が悪くなってしまう。

KVMのほうが遅い理由には調査した結果いくつか理由がある。まずひとつには完全仮想環境の標準のI/Oの性能が良くない。
また、KVMのゲスト環境ではCPUのキャッシュメモリーにヒットしなかった場合qemu-kvm(ホスト環境上で動くユーザープロセス)のメモリー空間に割り当てられたメインメモリーにアクセスすることになるがアクセス処理が複雑になるため、オーバーヘッドが大きい。


またKVMの改善方法としてはI/Oを司るデバイスドライバを準仮想化で動作させることで性能を1.5倍程度向上させることができる。