\chapter{Shien システム}

 本章では Shien システムの構成について述べる。

Shien システムは、複数のアカウントの計算機資源の使用を管理できるよう補助するシステムである。アカウント所有者が開発したアプリケーションのデプロイや、コンテナ・VM を使った実験を行える環境を提供する。

\section{Fedora}

Shien システムは、本学科の次期システムに合わせて設計する。そのためには最新のソフトウエアを取り入れ、次期システムが稼働する頃に安定な構成を検証する必要がある。

Fedora は最新の技術を積極的に取り込んでおり、その成果は Red Hat Enterprise Linux に取り込まれるといった、検証目的の位置づけになっている。また、本学科の基幹システムでは主に CentOS が使われている。CentOS は Red Hat Enterprise Linux と完全互換を目指した Linux ディストリビューションである。

つまり、最新の Fedora を使用することによって、教育用 OS 管理システムで使われる OS やソフトウエアを予測し、また、検証することが可能である。そのため、今回のシステムでは Fedora を利用し、次期システムが稼働する際の環境を構築し、検証を行った。

\section{Global File System 2 (GFS2)}

iSCSI に対応しており、複数のノードからのアクセスに対して整合性のある読み書きをするファイルシステムとして、GFS2 を選択する。

GFS2 は、Linux カーネルファイルシステムインターフェィスに直接的に対応するカーネルファイルシステムである。単独システム内、またはクラスタ設定の一部として使用することができる。GFS2 では、すべてのノードから同じ共有ストレージへアクセスできる。クラスタファイルシステムの一部として使用された場合、GFS2 は分散型メタデータと複数ジャーナルを運用する。

GFS2 でフォーマットされたディスクへアクセスするノードは、クラスタ構成になっていなければならない。

\section{Distributed Lock Manager (DLM)} 

GFS2 を使用する Red Hat のクラスタでは、ロック機構として DLM が使用される。DLM は GFS2 ファイルシステムへのアクセスなどの、クラスタ内のリソースへのアクセスを制御する。DLM がない場合、共有ストレージへのアクセス制御がなくなり、クラスタ内のノードが相互のデータを破損させる可能性がある。

DLM は、各クラスタノードで実行され、またロック管理はクラスタ内のすべてのノードを対象として行われる。

Quorum は、ノードがクラスタのメンバとして、過半数と通信できるノードがクラスタとして動作できる権利である。二台の場合は過半数が無いため無効化される。

DLM をクラスタで動作させるには、以下のように設定する必要がある。

\begin{itemize}
    \item ノードをクラスタの一部として設定する
    \item すべてのノードがクラスタのメンバーであり、Quorum を所持している
    \item ノード同士が IP アドレスで通信できる必要がある。
\end{itemize}
　
\section{Pacemaker} 

高可用性クラスタソフトウエアであり、クラスタを構成する。クラスタの状態を伝搬、クラスタへのノードの参加判断、クラスタノード感における情報の同期、一定間隔で相手ノードと通信して生死を確認、などのクラスタ制御を行うことができる。

\section{The corosync Cluster Engine (corosync)} 

Pacemaker でクラスタを構成するためには、クラスタの基盤が必要である。corosync は、高可用性を実現するクラスタ基盤ソフトウエアである。

Extended virtual syncrony と呼ばれる形式で、マルチキャストやブロードキャストを使ったノード間のメッセージング機能を提供する。また、クラスタ全体でプロセスグループを管理するための管理機能や、基礎的なアプリケーションの監視などの機能も提供する。

今回使用する Fedora では、過去にクラスタを管理するために使用されていた Cluster Manager (CMAN) が削除されているため、今後使用できない。Shien システムの設計をするためには CMAN を外す必要がある。

\section{Logical Volume Manager (LVM)} 

LVM とは、複数のハードディスクやパーティションにまたがった記憶領域を、一つの論理的なディスクとして扱うことのできるディスク管理機能である。

図\ref{fig:lvm}を用いて説明を行う。LVM はハードディスク内に、Physical Volume と呼ばれる LVM 用のパーティションを用意する。その Physical Volume を初期化し、Physical Extent と呼ばれる小さな領域に分割する。複数の Physical Volume をまとめて新たに作られる管理単位が、Volume Group になる。そして、実際のパーティション同様に利用できる Volume 、Logical Volume を作成する。

Logical Volume は物理的なディスクのパーティションと同様に利用することができる。この Logical Volume を GFS2 でフォーマットする。

\begin{figure}[htpb]
  \begin{center}
    \includegraphics[scale=0.7]{figures/lvm.pdf}
    \caption{LVM}
    \label{fig:lvm}
  \end{center}
\end{figure}

\section{Clustered Logical Volume Manager (CLVM)}

クラスタを構成するノード間で LVM を使用する場合は、CLVM を使う。

LVM のクラスタリング拡張機能のセットである。一部のホストが変更した LVM 情報を他のホストに通知する。クラスタは、 LVM を使用した共有ストレージを管理できるようになる。GFS2 は CLVM を利用して複数ノードからのアクセスに対応する。

\section{構成}

図\ref{fig:gfs2cluster} がブレードサーバの構成である。サーバ全てに Fedora を導入し、クラスタを構成する。クラスタの構成には corosync を使う。クラスタのノード同士は corosync を使用し、互いに通信を行う。

\begin{figure}[htpb]
  \begin{center}
    \includegraphics[scale=0.7]{figures/gfs2cluster.pdf}
    \caption{GFS2 Cluster}
    \label{fig:gfs2cluster}
  \end{center}
\end{figure}

iSCSI ディスクに LVM で使用できるパーティションを割り当てる。パーティションを一つにする場合は、Physical Volume と Volume Group、Logical Volume は全て一つである。Logical Volume を GFS2 でフォーマットする。フォーマット時に journaling を指定しなければならない。journaling 数は、GFS2 を参照する計算機の数である。

GFS2 でフォーマットされた一つの iSCSI ストレージを共有し、iSCSI ストレージに VM のディスクイメージ、コンテナで動かすアプリケーションを保存する。これにより複数のブレードサーバ間で VM のイメージの共有や移動、コンテナイメージの移動を簡単に行える。 


\section{Docker}

Docker とは、 Docker 社が開発してるオープンソースのコンテナ型仮想化ソフトウエアである。Linux 上で Linuxコンテナ (LXC) を活用し、コンテナ型の仮想環境を作成する。図\ref{fig:container} は Docker のアーキテクチャである。

\begin{figure}[htpb]
  \begin{center}
    \includegraphics[scale=0.7]{figures/container.pdf}
    \caption{Container architecture}
    \label{fig:container}
  \end{center}
\end{figure}

コンテナは OS 環境を複数のグループに区切って別のサーバのように利用する技術である。KVM などの hypervisor 型の仮想化とは異なり、ホスト OS がまとめて管理する。
Docker は、コンテナでアプリケーションを実行するため、コンピュータリソースの隔離・制限や、他のホスト、他のコンテナとのネットワーク構成や、ファイル・ディレクトリの世代と差分の管理などの機能を持つ。また容易に配布して実行することもできる。

Docker では新しい独自技術をほとんど用いていない。しかし新たなサーバ資源の運用方法として注目されており、学生が学ぶのに必須な技術の一つである。

\section{ie-docker}

ie-docker は本研究で新たに開発を行った、Docker をラップし複数のユーザで利用することのできるコンテナ管理ツールである。他のアカウントのコンテナを操作させない。またアカウントの使える docker の機能を制限する。表\ref{table:iedockerfunc}が ie-docker の機能である。


\begin{tiny}
    \begin{table}[ht]
        \begin{center}
            \caption{ie-docker のコマンド}
            \label{table:iedockerfunc}
            \small
            \begin{tabular}[t]{c|l}
                \hline
                run & XML の template を元に domain を作成 \\
                \hline
                build & define で作成した domain を削除 \\
                \hline
                attach & 動作しているコンテナに attach する\\
                \hline
                images & docker image を一覧表示する\\
                \hline
                rmi & docker image を削除する\\
                \hline
                rm & docker process を削除する\\
                \hline
                start & docker process を起動する\\
                \hline
                stop & docker process を停止する\\
                \hline
            \end{tabular}
        \end{center}
    \end{table}
\end{tiny}

またウェブサービスを ie-docker で動作させる際、複数のコンテナが外部に向けて同一の Port を使用することはできない。そのため図\ref{fig:iedockerport} ie-docker では、docker run を実行すると自動的に Port を取得する。

Port を取得後は、リバースプロキシを使用して外部に公開する IP アドレスやドメイン名に Port を割り当て、外部からウェブサービスが参照できるようにする。

\begin{figure}[htpb]
  \begin{center}
    \includegraphics[scale=0.7]{figures/iedockerport.pdf}
    \caption{ie-docker による Port の付与}
    \label{fig:iedockerport}
  \end{center}
\end{figure}

\section{ie-docker による資源の制限}

Docker はコンテナごとに使用するメモリの上限を指定することができる。ie-docker では、コンテナのメモリ使用量の制限をユーザ全てに管理者が付与できるよう実装した。docker run で Docker のコンテナを起動する。起動時に -m (memory) を指定することでメモリの指定が可能だが、今回は ie-docker でラップし -m (memory) を自動的に付与するよう実装を行った。

また ie-virsh と同様に、1 ユーザが使用可能なコンテナの数を 8 つに制限した。

\section{クラウド上での使用}

クラウドサービスではコンテナをユーザに使用させる。コンテナが VM と比べて高速なためであり、またクラウドサービス上へ VM イメージを送信するよりもデプロイしやすいためである。ie-docker は LDAP を参照してユーザに与える資源を制限しているため、クラウド上でも本学科の LDAP を利用する必要がある。