Mercurial > hg > Papers > 2015 > taiki-master
changeset 9:741bd4ff00c0
update pdf
author | taiki |
---|---|
date | Sun, 08 Feb 2015 22:39:26 +0900 |
parents | bc41d38f98d0 |
children | cbc7ac08e590 |
files | paper/chapter1.tex paper/chapter3.tex paper/chapter4.tex paper/chapter5.tex paper/master_paper.pdf paper/thanx.tex |
diffstat | 6 files changed, 117 insertions(+), 28 deletions(-) [+] |
line wrap: on
line diff
--- a/paper/chapter1.tex Fri Feb 06 11:07:58 2015 +0900 +++ b/paper/chapter1.tex Sun Feb 08 22:39:26 2015 +0900 @@ -5,7 +5,7 @@ VMWare が無償で配布している Hypervisor であり、計算機に直接インストールし使用することができる。現在本学科では VMWare ESXi を Hypervisor として VM を管理している。 \section{VMWare ESXi による VM 管理システム} - オンプレミスのブレードサーバで構成されており、VMWare ESXi で動作している VM を VMWare vSphere Client で管理している。図\ref{fig:iesystem} のように、VM の所有者はメールでシステム管理者へ VM 作成依頼を行い、本学科の提供する Web サービスで VM の起動・停止などの操作を行う。 + オンプレミスのブレードサーバで構成されており、VMWare ESXi で動作している VM を VMWare vSphere Client で管理している。図\ref{fig:iesystem} のように、VM の所有者はメールでシステム管理者へ使用 VM を増やす依頼を行い、ユーザは本学科の提供する Web サービスから VM を作成する。 \begin{figure}[htpb] \begin{center} @@ -21,6 +21,46 @@ 本学科のシステムでは、VM の操作は Web サービス実装を通して行う。VM の作成はメールなどの連絡手段を使って、管理者を通して行う。既成の VM をブレードサーバへアップロードするにも、管理者と連絡し手続きを取る。 +Web サービスのポータル画面は図\ref{fig:ieportal}のようになる。本学科では IP アドレスもこの画面で配布している。 + +\begin{figure}[htpb] + \begin{center} + \includegraphics[scale=0.35]{images/ie_sc_portal.png} + \caption{本学科の Web サービス} + \label{fig:ieportal} + \end{center} +\end{figure} + +VM を作成するためには、図\ref{fig:ieportal}の VM 新規作成をクリックする。クリックすると図\ref{fig:iemakevm}の画面に移る。図\ref{fig:iemakevm}で必要な情報をすべて入力し、「ok」をクリックすることによって VM を作成することができる。 + +\begin{figure}[htpb] + \begin{center} + \includegraphics[scale=0.35]{images/ie_sc_makevm.png} + \caption{Web サービスの VM 作成画面} + \label{fig:iemakevm} + \end{center} +\end{figure} + +VM 作成後は VM を選択すると、図\ref{fig:ievmop} へ移り、VM を管理することができる。 + +\begin{figure}[htpb] + \begin{center} + \includegraphics[scale=0.35]{images/ie_sc_vmop.png} + \caption{Web サービスの VM 管理画面} + \label{fig:ievmop} + \end{center} +\end{figure} + +管理画面で可能なことは、下記になる。 + +\begin{itemize} + \item 起動 + \item 停止 + \item サスペンド + \item 再起動 + \item スタンバイ +\end{itemize} + \section{VMWare vSphere Client} GUI で VM を操作することができ、豊富な機能と高度な操作が可能となっている。管理者は VMWare vSphere Client での管理を行っている。VM などの資源に対する操作の権限を細かく扱うことができるため、利用者に対して権限を配布することが可能である。しかし GUI が複雑なため、操作に習熟する必要がある。
--- a/paper/chapter3.tex Fri Feb 06 11:07:58 2015 +0900 +++ b/paper/chapter3.tex Sun Feb 08 22:39:26 2015 +0900 @@ -68,8 +68,7 @@ \section{構成} -複数のブレードサーバでクラスタを構成する。クラスタの構成には corosync を使う。 - +図\ref{fig:gfs2cluster} がブレードサーバの構成である。複数のブレードサーバでクラスタを構成する。クラスタの構成には corosync を使う。クラスタのノード同士は corosync を使用し、互いに通信を行う。 \begin{figure}[htpb] \begin{center} @@ -79,7 +78,8 @@ \end{center} \end{figure} -図\ref{fig:gfs2cluster} がブレードサーバ一台の構成である。GFS2 でフォーマットされた一つの iSCSI ストレージを共有し、iSCSI ストレージに VM のディスクイメージ、Docker のアプリケーションを保存する。これにより複数のブレードサーバ間で VM のイメージの共有や移動、コンテナイメージの移動を簡単に行える。 +corosync +GFS2 でフォーマットされた一つの iSCSI ストレージを共有し、iSCSI ストレージに VM のディスクイメージ、Docker のアプリケーションを保存する。これにより複数のブレードサーバ間で VM のイメージの共有や移動、コンテナイメージの移動を簡単に行える。 \section{ie-virsh による資源の制限} @@ -191,4 +191,4 @@ \section{クラウド上での使用} -クラウドサービスではコンテナをユーザに使用させる。 ie-virsh 、ie-docker は LDAP を参照して資源を制限しているため、クラウド上でも本学科の LDAP を利用する必要がある。 +クラウドサービスではコンテナをユーザに使用させる。コンテナが VM と比べて高速なためである。ie-docker は LDAP を参照してユーザに与える資源を制限しているため、クラウド上でも本学科の LDAP を利用する必要がある。
--- a/paper/chapter4.tex Fri Feb 06 11:07:58 2015 +0900 +++ b/paper/chapter4.tex Sun Feb 08 22:39:26 2015 +0900 @@ -4,25 +4,25 @@ \section{LDAP による権限管理} -VMWare vSphere Client では VM やシステムに対する権限を細かく設定できる。しかし各利用者に対して適切な権限を振るのは多くの時間を要するため、自動的に権限を配布する必要がある。 +VMWare vSphere Client では VM やシステムに対する権限を細かく設定できる。しかし各ユーザに対して適切な権限を振るのは多くの時間を要するため、自動的に権限を配布する必要がある。 -教育用の計算機システムでは、権限は管理者と利用者のみに分けられる。そのため権限の配布は同一の権限を利用者に一度に振るのがよい。 +教育用の計算機システムでは、権限は管理者とユーザのみに分けられる。そのため権限の配布は同一の権限をユーザに一度に振るのがよい。 -本研究で提案する計算機システムでは、LDAP から取得したアカウントによって権限を配布する。情報工学科では学生や教師などの利用者アカウントを LDAP で管理しており、そのアカウントをそのまま権限配布に使用することができるためである。 +本研究で提案する計算機システムでは、LDAP から取得したアカウントによって権限を配布する。情報工学科では学生や教師などのユーザアカウントを LDAP で管理しており、そのアカウントをそのまま権限配布に使用することができるためである。 -またデータや VM のイメージを保存する Fibre Channel ストレージに各利用者へディレクトリを自動的に作成し、そのディレクトリにそれらを保存する。ディレクトリに各利用者と管理者だけがアクセスできるように権限を設定する。 +またデータや VM のイメージを保存する iSCSI ストレージに各利用者へディレクトリを自動的に作成し、そのディレクトリにそれらを保存する。ディレクトリに各ユーザと管理者だけがアクセスできるように権限を設定する。 Shien システムの利用者は他の利用者の VM やコンテナに対して操作を行うことができず、またデータや VM を操作・改編することができない。 -そのように、LDAP を使用して権限を管理することが可能である。 +そのように、LDAP を使用して権限を管理できる。 \section{ie-virsh で使用する VM イメージのアップロード} -利用者は Fibre Channel ストレージに VM イメージを保存する。この計算機システムでは各 VM 所有者ごとにディレクトリを分けて使う。 +ユーザは iSCSI ストレージに VM イメージを保存する。この計算機システムでは各 VM 所有者ごとにディレクトリを分けて使う。 -VM 使用者は手元の PC で VM イメージを作成し、実験・開発環境を作成する。次に VM イメージを Fibre Channel ストレージにアップロードする。アップロード先は Fibre Channel ストレージ上にある所有者自身のディレクトリである。ie-virsh は VM を設定する XML ファイルをテンプレートから作成するため、VM イメージの形式は固定である。そのため、VM イメージをテンプレートに合わせた形式にしなければならない。 +VM 使用者は手元の PC で VM イメージを作成し、実験・開発環境を作成する。次に VM イメージを iSCSI ストレージにアップロードする。アップロード先は iSCSIストレージ上にあるユーザ自身のディレクトリである。ie-virsh は VM を設定する XML ファイルをテンプレートから作成するため、VM イメージの形式は固定である。そのため、VM イメージをテンプレートに合わせた形式に変換する。 -アップロードした後は、ie-virsh で XML テンプレートを使用したドメインを作成する。ie-virsh は virsh のドメインを自動的に定義することができる、define コマンドを持っており、そのコマンドを利用する。 +アップロードした後は、ie-virsh で XML テンプレートを使用したドメインを作成する。ie-virsh は virsh のドメインを自動的に定義することができる define コマンドを持っており、そのコマンドでドメインを作成する。 ドメインの定義は下記のように行う。 @@ -30,11 +30,11 @@ % ie-virsh define [01 - 04] \end{verbatim} -ドメインは 01 から 04 までの名前をつけることができる。 +ドメインは 01 から 04 までの名前をつけることができる。これは一人のユーザに対し、VM を4台に制限しているためである。 \section{VM の起動} -ie-virsh を使用して、VM を起動する。 +ie-virsh を使用して、作成したドメインの VM を起動する。 起動するには、下記の操作を行う。 \begin{verbatim} @@ -62,13 +62,13 @@ \section{VM の停止} -VM の停止は virsh と同じである。 +VM の停止は下記のコマンドで行う。 \begin{verbatim} % ie-virsh destroy [01 - 04] \end{verbatim} -virsh の destroy コマンドをラップしているため、VM を強制的に停止させる。 +virsh の destroy コマンドをため、VM を強制的に停止させる。 \section{VM への console ログイン} @@ -102,15 +102,21 @@ 実行すると Port の Pool から Port を取得する。取得した Port を使用し Kernel debug のための VM が起動する。 VM の起動後に自動的に gdb が立ち上がる。取得した Port を使い、gdb から Kernel debug のための VM に接続する。 -\section{Docker の起動} +\section{ie-docker によるコンテナの起動} -本研究で新たに実装を行った ie-docker は Docker のラッパーとなっている。任意の Process name を下記のコマンドを使用して割り当てる。 +任意の Process name を下記のコマンドを使用して割り当て、コンテナを起動する。 \begin{verbatim} % ie-docker run -it --name [process name] [image name] [exec command] \end{verbatim} -Process name は任意に割り当てることができる。また process name はアカウント名が ie-docker によって補完されるため、他のアカウントと被ることはない。 +Process name は任意に割り当てることができる。同名の Process name は使用できない。また process name はアカウント名が ie-docker によって補完されるため、他のユーザが作成したp Process name と被ることはない。 + +一度 run を行ったコンテナに対しては、run を打たなくても下記のように起動することができる。 + +\begin{verbatim} +% ie-docker start [process name] +\end{verbatim} \section{Docker からの iSCSI ストレージの使用} @@ -125,6 +131,6 @@ --name [process name] fedora:20 /bin/bash \end{verbatim} -実行されたコンテナはホストのディレクトリにマッピングされた、任意の名前のディレクトリを参照することができる。iSCSI ストレージ上にアプリケーションのリポジトリを配置し、コンテナでそのリポジトリ上のアプリケーションを動作させる。 +実行されたコンテナはホストのディレクトリにマッピングされた、任意の名前のディレクトリを参照することができる。iSCSI ストレージ上にアプリケーションの Repository を配置し、コンテナでその Repository 上のアプリケーションを動作させる。 - +また ie-docker は指定したディレクトリにまとめてユーザの Repository を作成する。管理者は指定したホストのディレクトリに対して容量の制限をかければよい。
--- a/paper/chapter5.tex Fri Feb 06 11:07:58 2015 +0900 +++ b/paper/chapter5.tex Sun Feb 08 22:39:26 2015 +0900 @@ -1,10 +1,10 @@ \chapter{Shien システムの評価} - +本章では Shien システムの評価を行う。新たに使用した GFS2 との比較と、授業で使用した際の評価を述べる。 \section{実験環境} -Shien システムの検証目的の一つは、本学科の次期システムでの使用を検討するものである。評価には現在本学科でのブレードサーバ環境を使用した。ブレードサーバの仕様は表\ref{tab:server_spec}となっている。 +Shien システムの検証目的の一つは、本学科の次期システムでの使用を検討するものである。評価には本学科でのブレードサーバ環境を使用した。ブレードサーバの仕様は表\ref{tab:server_spec}となっている。 \begin{table}[!htbp] \caption{ブレードサーバの仕様} @@ -21,14 +21,21 @@ \end{center} \end{table} -また現在の、本学科の計算機システムと接続されているストレージは Fibre Channel ストレージである。そのため Fibre Channel ストレージを用いて GFS2 の計測を行った。 + +現在の本学科のブレードサーバと接続されているストレージは Fibre Channel ストレージである。そのため Fibre Channel ストレージを用いて GFS2 の計測を行った。 + +\section{実験概要} -Benchmark は Filebench というベンチマークツールを用いて行った。Filebench はファイルシステムパフォーマンスの測定と比較のためにファイルシステムのワークロードをフレームワーク化したものである。シンプルなワークロード構築用の言語 .f 言語が搭載されている。 +ベンチマークは Filebench というベンチマークツールを用いて行った。Filebench はファイルシステムパフォーマンスの測定と比較のためにファイルシステムのワークロードをフレームワーク化したものである。シンプルなワークロード構築用の言語 .f 言語が搭載されている。 -Filebench は .f 言語で書かれた基本的なワークロードを持っている。今回はそのワークロードを用いて計測を行った。 +Filebench は .f 言語で書かれた基本的なワークロードを持っている。今回はそのワークロード randomread.f と randomwrite.f を用いて計測を行った。 + +\section{} \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} @@ -47,19 +54,48 @@ \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{GFS2 上の VM イメージを使った複数ノードの計測} \subsection{考察} \section{VM とコンテナとの比較} + \subsection{考察} + + \section{授業 Operating System での使用} 情報工学科では Operating System という授業が行われている。授業 Operating System で実際に ie-virsh を使用した。複数人の学生による VM の使用を、管理側の負担を抑えて管理することができた。 @@ -78,6 +114,7 @@ \section{Vagrant} + Vagrant は異なる環境に移行可能な開発環境を構築・管理・配布することができる開発環境作成ツールである。手軽にテスト環境を導入・破棄することができ、変更が加わっても開発環境・本番環境に自動的に適用できる。 VirtaulBox などのプロバイダを使って、VM を Vagrant 経由で立ち上げる。手軽に起動・停止・ssh ログインできるため、Web サービスの開発や開発環境の配布などに利用される。 @@ -93,7 +130,7 @@ Vagrant Box イメージは簡易なパスワードとユーザ名で Vagrant から管理されていたため、そのままブレードサーバへアップロードしサーバ用途に使用してしまうと、簡単に外部から侵入され乗っ取られてしまう。そのため Vagrant Box イメージを使用する際は、外部から攻撃されないような設定か確認し、脆弱な設定なら設定し直す必要がある。 -\section{Cloud 上での使用} +\section{クラウド上での使用} \section{VM イメージの転送速度} \section{コンテナの使用}
--- a/paper/thanx.tex Fri Feb 06 11:07:58 2015 +0900 +++ b/paper/thanx.tex Sun Feb 08 22:39:26 2015 +0900 @@ -1,2 +1,8 @@ \chapter*{謝辞} \addcontentsline{toc}{chapter}{謝辞} + + 本研究を行うにあたりご多忙にも関わらず日頃より多くの助言、ご指導をいただきました河野真治准教授に心より感謝いたします。 + +研究を行うにあたり、環境の調整、意見、実装に協力いただいた並列信頼研究室の全てのメンバーに感謝いたします。 + + 最後に、大学の修士まで支えてくれた家族に深く感謝します。