2007/09/28

Red Hat Cluster: RHCSとXen

ちっとも実践編に進まないので気が引けるが、今回はクラスタと仮想化について考えてみたい。

クラスタと仮想化は、言わば正反対の技術だ。クラスタは複数のマシンを束ねて共通のサービスを提供する技術、仮想化は一台のマシンを複数に分割して仮想的に複数台のマシンに見せかける技術だ。この正反対の技術を組み合わせて使うこともなかろうに、という意見も当然あるだろう。しかし、クラスタと仮想化を組み合わせて使う理由はいくつかある。

まず、クラスタへのメンバの追加の手間が減ることがある。クラスタにメンバを追加する(あるいは、新規にクラスタを生成する)場合、通常であれば、
  1. 追加するメンバの数だけマシンを準備し、
  2. それらにそれぞれOSをインストールし、
  3. Congaなりのクラスタ管理ツールを利用してクラスタに追加する、
という手順をとる。このうち、最後のものは大した手間ではないが、前の二つは手間がかかる。企業であれば、見積もりを取り、マシン購入の稟議をまわし、購買部門に手続きを依頼し、…と言った手順が必要で、マシン到着までに一ヶ月以上待たされることも珍しくないだろう。OSのインストールに関しては、プレインストールを利用すればよいが、それにしても、実際の稼動環境に適合するように設定する手間は省けない。
一方、クラスタメンバを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を使ってみる

2007/09/26

Red Hat Cluster: GNBD, CLVM and GFS・その3

GNBDでブロックデバイスをクラスタ上で共有できるので、ブロックデバイスが共有されていることを前提としているGFSと組合せて使うとよい。これが前回および前々回までの要点だ。

GNBDでブロックデバイスを共有すると、GNBDクライアント上に/dev/gnbd*というデバイスができる。これに対するアクセスは、GNBDサーバ上の対応するブロックデバイスへのアクセスと等価だ。当然これを直接GFS(GFS2)でフォーマットし、マウントして使うこともできる。
しかし、この方法は柔軟性に欠ける。例えば、GNBDサーバ上の対応するブロックデバイスが/dev/sda1の様な物理ディスクのパーティションだと、サイズを変更することができない。この問題は、LVMを使えば解決できる。GNBDサーバ側でLVMを用いてVGを組み、LVをGNBDでエクスポートすればよい。

しかし、これより更によい方法がある。それがCluster Logical Volume Manager(CLVM)だ。CLVMは、読んで字の如く、クラスタ上で共有されるLVMだ。CLVMを使えば、どのクラスタメンバ上でも同じ内容・同じ名前でVGやLVをアクセスできる。
これに加え、異なるGNBDサーバからエクスポートされた複数のブロックデバイスでVGを組むことも可能という利点もある。GNBDサーバ側でVLMを組む場合にはこのようなことはできない。
さらに、Device Mapper Multipath (DM-MP)と併用すれば、冗長構成を採ることにより、耐障害性を高めることもできる(その内詳しく解説します…多分)

CLVMは、LVM(LVM2)の自然な拡張になっており、クラスタを意識しない場合のLVMのCUIやGUIとほとんど同じ操作で管理できる。違いは、クラスタを構成した後、各クラスタメンバ上で
# lvmconf --enable-cluster
を実行することと、最初にVGを組む場合に、クラスタ対応VGだと指示することくらいだ。


これまで三回に渡り、GNBD、CLVMおよびGFSについて概説してきた。以上を元に、次のことを今後の目標とし、実際にシステムを組んでみたい。
  1. GNBDでディスクデバイスを共有する
  2. GNBDで共有されたブロックデバイスから、CLVMでクラスタ上で共有されるVGおよびLVを生成する。
  3. CLVMで生成したLV上にGFSを作成し、各クラスタメンバ上でマウントする。

解説: その1その2その3
kernel-xenにバグか?
その4・CentOS 5.1での注意点
その5・GNBDの設定
その6・CLVMの設定
その7・GFS2の設定
その8・Congaからの設定
その9・ベンチマーク


追記(2008/2/24):
検証を再開した。
Red Hat Cluster: CentOS 5.1上でRHCSを使ってみる

Red Hat Cluster: GNBD, CLVM and GFS・その2

前回、GFSを利用するには、クラスタメンバ間でブロックデバイスを予め共有しておく必要がある、と述べた。ここでは、GNBDを使うが、他の方法について概説する。

ブロックデバイスについては、ここに解説してある。
ブロックデバイスとは、ブロックサイズの倍数、典型的には 512 か 1024 バイトでのみ読み書きするデバイスである。ブロックデバイスはバッファキャッシュ経由でアクセスされ、ランダムなアクセス、すなわちデバイス上のどこにあるブロックでも読み書きできるアクセス方法が利用されることが多い。ブロックデバイスへのアクセスは、それぞれに対応したデバイススペシャルファイルを経由しても可能であるが、ファイルシステム経由でアクセスするほうがより一般的である。マウントされるファイルシステムをサポートできるのはブロックデバイスだけである。
つまり、ブロックデバイスは、主にディスク等の物理デバイスをデバイスドライバを通してアクセスする仕組みだ。GFSは、ネットワーク越しに共有された物理デバイスをブロックデバイススペシャルファイルを通じてアクセスする。つまり、ブロックデバイスの共有だ。

物理ディスクをブロックデバイスとして共有する方式はいくつかある。いわゆるStorage Area Network (SAN)と呼ばれるものが代表的だ。SANには、ファイバーチャネルを利用するFibre Channel SAN (FC-SAN)や、IPを利用するIP-SANなどがある。

FC-SANは、FCインターフェースを備えた専用ディスク装置、FCスイッチおよびFCインターフェースを備えたコンピュータで構成されるのが一般的だ(FC-SANはお金持ちの道具なので、私は使ったことがない)。FC装置に関する知識が必要で、対応できる技術者が少ないことが問題になる。

IP-SANの代表選手はiSCSIだ。これは、SCSIをIPでカプセル化してネットワーク越しにデバイスを共有する仕組みだ(これと似た仕組みにATA over Ethernet (AoE)というものがあるらしいが、詳しくは知らない)。IP-SANは、Ethernetポートを備えた専用のディスク装置、EthernetスイッチおよびEthernetポートを備えたコンピュータで構成されるのが一般的だ。後の二つは、ごく一般的な機器なので、特殊な知識を必要とせず、FC-SANに比べ導入のハードルが低い。特にiSCSIであれば、専用のディスク装置でなく、PC上でiSCSIサーバを走らせることで代用可能だ。CentOS 5には、Linux上のiSCSI実装の一種であるOpen-iSCSIがRPMで準備されている。パッケージ名はiscsi-initiator-utilsだ。

一方GNBDは、IPネットワーク上でブロックデバイスを共有する仕組みで、通常、クラスタ環境で使用される(が、クラスタ環境は必須ではない。後述)。GNBDは、クライアント=サーバ構成になっており、GNBDサーバ上のブロックデバイスを、複数のGNBDクライアントからアクセス可能にする。この意味では、PC上でiSCSIサーバを動作させる場合に非常によく似ている。ただ、GNBDは、RHCSのfence deviceとしても使えるので、クラスタとの親和性が高い。
なお、上図で、GNBDは、ローカルに接続されたディスクドライブに対するブロックデバイスを共有しているが、FCのポート単価はEthernetに比べて高いことに着目して、FCとGNBDの折衷案も考えられる。FCポート数を減らし、Ethernetポートで置き換えると、性能は多少落ちるが、全体のコストは下がる(これは、RHELのマニュアルでも触れられている)

GNBDは、基本的にクラスタ環境で使用するが、実はiSCSIの様にクラスタと無関係に使うこともできる。GNBDのサーバ側では、gnbd_servというサーバプロセスが動くのだが、起動時に-nというオプションを与えると、クラスタとは無関係に動作する。
ただし、GFSを使う場合は、このオプションを使うことはできないようだ。なぜなら、gnbd_servのマニュアルを見ると、このオプションを使うと、キャッシュ無しのデバイスをエクスポートすることはできない、と書いてあり、gnbd_exportのマニュアルを見ると、GNBD上でGFSを使う場合は、キャッシュを有効にしてはいけない、と書いてある。

さて、GNBDを使えば、クラスタ上でブロックデバイスを共有できることが判った。では、そのデバイスを直接使ってGFSを構成すべきだろうか?

解説: その1その2その3
kernel-xenにバグか?
その4・CentOS 5.1での注意点
その5・GNBDの設定
その6・CLVMの設定
その7・GFS2の設定
その8・Congaからの設定
その9・ベンチマーク


追記(2008/2/24):
検証を再開した。
Red Hat Cluster: CentOS 5.1上でRHCSを使ってみる

2007/09/25

Red Hat Cluster: GNBD, CLVM and GFS・その1

レッドハットクラスタ(RHCS)を使いこなすべく、調査中。そのメモを残す。

クラスタを構成するには、クラスタのメンバ(クラスタを構成するサーバマシン)が資源を共有する場合が多い。例えば、HTTPサービスをクラスタで提供する場合、少なくとも/var/www/htmlの様なコンテンツ領域を共有する必要があるだろう。ファイル共有であれば、NFSを使うという手もあるのだが、ここはクラスタらしく、GFS(GFS2)を使いたい。

GFS(Global File System)は、ネットワークファイルシステムである。ということは、前出のNFSやCIFS(Widowsのネットワーク共有、SAMBAなど)と同列だ。ただし、NFSやCIFSと決定的に違う点がある。実際にファイルやディレクトリを格納するブロックデバイスを、別途GFSを使うマシン群で共有しておかなければならない、という点だ。
例えばNFSでファイル共有を行う場合、通常NFSサーバ上にブロックデバイス(例えば/dev/sda)が存在し、NFSクライアントからこのブロックデバイスへのアクセスは、NFSプロトコルによってカプセル化される。このためNFSクライアント側では、このブロックデバイスを直接アクセスする必要はまったくない(というより、してはいけない)
一方GFSでは、ブロックデバイスは既にGFSを使うクラスタメンバ(GFSはクライアント=サーバシステムではないので、GFSクライアントと呼ぶのは正しくない)間で共有されていることを前提としている。つまり、クラスタメンバは、実際にファイルやディレクトリを格納するブロックデバイスへのアクセスが必要、ということだ。この意味では、ブロックデバイスの存在を前提としているext3等のローカルファイルシステムと同列と言える。GFSとこれらのローカルファイルシステムの違いは、当然ながら、ネットワーク共有可能か否かにある(この違いは、分散ロック機構と複数ジャーナル機構などから生まれるのだが、ここでは解説しない)
Linuxにおいて、ファイルシステムとは、VFSを通じて呼ぶことのできる記憶装置(/procファイルシステムの様に記憶装置でないファイルシステムもあるが)である。ファイルやディレクトリと言った概念を用いてアクセスできる記憶装置と言い換えることもできるだろう。図を見てもらうと解ると思うが、NFSは、ファイルシステムの上にファイルシステムを架した構成になっている(従って、VFSが二回介在する)ため、オーバヘッドが大きい。
一方、GFSは、ブロックデバイスをネットワーク共有した後でファイルシステムが存在しているだけなので、オーバーヘッドは少ない(ブロックデバイス共有機構の効率にもよるが、一般には、ファイルI/OよりもブロックデバイスI/Oの方が単純なので)

では、GFSの前提となるブロックデバイス共有機構は何を使えばいいのか?この解答の一つがGNBDである。

解説: その1その2その3
kernel-xenにバグか?
その4・CentOS 5.1での注意点
その5・GNBDの設定
その6・CLVMの設定
その7・GFS2の設定
その8・Congaからの設定
その9・ベンチマーク


追記(2008/2/24):
検証を再開した。
Red Hat Cluster: CentOS 5.1上でRHCSを使ってみる

2007/09/13

Red Hat Cluster: SELinuxを停止

前回に引き続き、RHCSをCongaで構成してみる話。
前回に述べた通りに/etc/redhat-releaseを詐称してCongaでクラスタを構成しようとしても、メンバはluciの管理下に入るものの、新規クラスタを作成できない、という現象が発生する場合がある。
これは、メンバ側でSELinuxが動いている場合に起こる現象のようだ。これを回避するためには、SELinuxを止めてしまう(disabled)か、警告のみ(permissive)に設定変更すればよい。これは、system-config-securitylevelもしくはsystem-config-securitylevel-tuiを使って設定変更すればよい。テキストエディタを使って、/etc/sysconfig/selinuxの中を、
SELINUX=disabled
もしくは
SELINUX=permissive
に変更してもOKだ。

前回提示した図(Congaのホームページから借用)

を見て欲しい。ここでricciは一般ユーザ権限で動作している。しかしながら、ricciは、luciからの要求に従ってシステムの設定を変更しなければならない。この権限問題を解決するために、ricciはdbus(messagebus)を通じてoddjobdへ設定変更を命令する。このoddjobdは、適切な権限をもって予め定められたジョブを実行する。

従って、SELinuxでricciからdbus経由でoddjobが実行するジョブに対するアクセス制御を適切に書いてあげればよいのだが、これがまだ不十分のようだ。将来的には修正されるのだろうと思う。

2007/10/31追記:
SELinuxをすべて停止するのではなく、デーモン単位に制御する方法について追記した。
SELinuxのアクセス制御をデーモン単位に停止

2007/09/07

Red Hat Cluster: 予告編+x

しばらくサボっていたが、再開の予定。今シリーズのテーマはクラスタ。Red Hat Cluster Suite(RHCS)を使ってクラスタを構成する。まずは、Congaを使ってクラスタを構成して行く。
Congaは、サーバ・エージェント・アーキテクチャのシステムで、サーバからクラスタメンバや、ストレージサーバを統合管理する。
フロントエンドはウェブブラウザで、SSLでサーバデーモンであるluciに接続する。サーバデーモンluciは、クラスタメンバやストレージ上のエージェントデーモンricciにXML-RPC over SSLで接続する。



OSはCentOS 5を使用するが、RHEL 5でも同様…と言いたい所だが、早速違いを見つけてしまった。RHEL 5のマニュアルを見ながら手順通りやっても、CentOSではエラーになってしまう。Luciで、クラスタメンバを指定し、新規クラスタを作成すると、クラスタメンバの設定を自動的に行ってくれるのだが、このとき
A problem occurred when installing packages: failed to locate/execute module
と言ったメッセージがブラウザ上に表示され、メンバはluciの管理下に入るが、クラスタを構成できない。
原因は、/etc/redhat-release。クラスタメンバ側でこれをRHEL5だ、と詐称しなければ上手く動作しないようだ。以下のとおりrootで実行する。
# mv /etc/redhat-release /etc/redhat-release.orig
# echo "Red Hat Enterprise Linux Server release 5 (Tikanga)" > /etc/redhat-release
どうもluciは、クラスタメンバ間のOSバージョンの違いを検査しているらしく、ひとつのクラスタに違うOS・バージョンを混在させることを認めないようだ。このチェックのため、/etc/redhat-releaseを参照するらしい。

参考: 0001931: Ricci module "ricci-modrpm" crashes, preventing Cluster configuration from Luci

2007/11/6追記:
上の様に/etc/redhat-releaseを修正すると、カーネル更新後にGRUB画面にカーネルバージョンが表示されなくなる。この問題に対する解決法を記事にした。

追記(2008/2/24):
検証を再開した。
Red Hat Cluster: CentOS 5.1上でRHCSを使ってみる