クラスタと仮想化は、言わば正反対の技術だ。クラスタは複数のマシンを束ねて共通のサービスを提供する技術、仮想化は一台のマシンを複数に分割して仮想的に複数台のマシンに見せかける技術だ。この正反対の技術を組み合わせて使うこともなかろうに、という意見も当然あるだろう。しかし、クラスタと仮想化を組み合わせて使う理由はいくつかある。
まず、クラスタへのメンバの追加の手間が減ることがある。クラスタにメンバを追加する(あるいは、新規にクラスタを生成する)場合、通常であれば、
- 追加するメンバの数だけマシンを準備し、
- それらにそれぞれOSをインストールし、
- Congaなりのクラスタ管理ツールを利用してクラスタに追加する、
一方、クラスタメンバをXenなどを使った仮想マシンで構成した場合を考えてみよう。マシンの購入の手続きは変わらないが、余裕を持った高性能機を買い足すことで、購入回数は減る(その分、稟議を通すのが難しくはなるが)。実ハードウェアに対するOSのインストール手順は変わらないが、仮想マシンへのインストールは、一回で済む。仮想マシンを増やす手間は、イメージファイルのコピーだけで済むからだ(正確には、設定ファイルのコピーや、DHCPサーバ・DNSサーバの設定変更などもあるが、これは事前にまとめて済ませておくことも可能。このあたりについては、その内解説する…多分)。
また、ハードウェア台数が減ると、一般に処理能力は同じでも消費電力は少なくなる。消費電力が少なくなれば、サーバルームの冷却の点でも有利だ。電力や冷却の問題は、はクラスタを運用するようなデータセンターでは非常に重要になりつつある。
クラスタへの計算機資源管理の面でも仮想化との組み合わせは有効だ。ハードウェアを直接クラスタメンバにする場合、基本的にハードウェアの全資源をクラスタに投入する以外に選択はない。一方、仮想化機構を介してクラスタメンバとして仮想マシンを提供すると、仮想化機構のリソース管理機能を使って、割り当てるCPU使用率、CPU数およびメモリ等を細かく設定し、クラスタに投入することができる。
さらに、『VLANとXenを組合わせて使う』で紹介した方法を使えば、まったく違う複数のサービス領域に対して、一台のDom0からクラスタメンバとしてDomUを提供することもできる。クラスタをサービスとして複数の顧客に提供する場合、価格・納期・SLA等の点で利点となる。
逆に、仮想マシンの提供という観点から考えると、クラスタで構成された可用性の高いストレージ上に仮想マシンのイメージファイルを置けば、仮想マシンサービスの可用性も向上する。さらに、Xenで言うLive Migrationの類の技術も採用しやすくなる。Live Migrationとは、稼働中のDomUをあるDom0機から別のDom0機へほぼ無停止で移動する技術だが、Dom0機間でのイメージファイルの共有が必要だ。
最後に、フェンスデバイスの問題を採り上げたい。クラスタでは、サービス不能になったメンバを、クラスタサービスから取り除く操作が必要になる。これをフェンス(fencing)と言う。具体的には、そのメンバをシャットダウンしたり、サービスに必要なストレージから切り離したり、と言った操作を行う。RHCSでは、さまざまなフェンス手段が準備されているが、FCスイッチや、ネットワーク電源スイッチなど、それほど一般的でないハードウェアに特化したものが多く、これらは高価で採用しにくい(ハードウェアに特化したもので採用しやすいのには、APCの無停電電源装置を利用するものがあるが、データセンターでは、そもそも無停電電源装置は不要だ。IBMのRSA IIやDellのDRACなど、各サーバベンダーのサーバ管理モジュールに対応したものは、比較的安価で採用しやすいが、それでも只ではない)。
RHCSには、virtual machine fencingというフェンス手段が準備されている。これは、Dom0に対してクラスタメンバに対応するDomUをシャットダウン(あるいは、再起動)するように指示するものだ。これは、ソフトウェアのみで実現できるため、採用しやすい(他にも、ソフトウェア的なフェンス手段として、前にも述べたGNBD fencingもある)。
追記(2008/2/24):
検証を再開した。
『Red Hat Cluster: CentOS 5.1上でRHCSを使ってみる』
