GFSという分散ファイルシステムをつかうためには、サーバ間でクラスタを構成しなくてはいけないのですが、その前にiSCSIを使ったボリューム共有について書いてみます。
Linuxというマルチタスク環境下でも、ファイルへのアクセスはカーネル経由で行われるため、ファイルのデータそのもの及びファイルシステムを管理するデータ=メタファイルも、基本的には一貫性が確保されています。
つまり、各プロセスやタスクで非同期にファイル操作を行っても、ファイルシステムとしての不具合は発生しないということです。
もちろん、同一ファイルを複数のプログラム（プロセス）で操作した場合の排他制御に関しては、アプリケーション層の話であり、ファイルシステムの話とはレイヤーが異なります。
※ファイル単位やレコード単位の排他制御の話…
iSCSIのようにSCSIベースのシステムの場合、ブロックデバイスの物理レベルのアクセス及び、ファイルシステムとしての最小アクセス単位（HDDのセクター等）においての、排他制御は働きます。
しかし、これはプロトコルレベルの話であり、実際にサーバ側で動いているキャッシュ（特にwriteキャッシュ）は考慮されていません。
つまり、ある特定のファイルに複数のサーバがアクセスした場合、そのファイルへ直接に読み書きを行っている訳でなく、キャッシュに書き込むという遅延書き込みをおこなっているので、サーバ上にキャッシュをHDDに書き出したとき、そのキャッシュ内容がHDD上の物理情報と合致している事が担保されない（時間差があるので）ということです。
特にデータそのものに関しては、アプリケーション層で排他制御をかけることは可能ですが、ファイルシステムの制御はカーネル内部の話ですから、アプリケーションでは手を出せません。
このことは、今回の検証で最初に行ったiSCSIでのマウントを行う場面でも発現しています。
あるサーバがiSCSI経由であるボリュームをマウントした場合、そのボリュームにとって最初のマウントであれば問題ありませんが、もし、すでにマウントされているボリュームを違うサーバがマウントしようとすると、当然Cleanではないといわれます。
そして、マウント時に自動的にfsckライクな処理が走ります。
もちろん、この作業で動作中のファイルシステムのメタファイルが壊れてアクセス不能になることはありませんが、正直気持ちのよいものではありません。
※ファイルシステムを作っている人から言わせると、そういう利用形態は推奨されません！ ですね…
ですので、GFSのような分散ファイルシステムを使わないで、iSCSIだけでボリューム共有を行う場合、運用の仕方には注意が必要です。
例えば、iSCSIのターゲットマシンのボリュームに、仮想サーバのイメージがおいてある場合、そこを参照する（マウントする）仮想マシンの母艦＝Domain0は、完全なアクティブ・スタンバイなら大丈夫だと個人的には思っています。
つまり、アクティブ側ですべての仮想サーバが稼動し、スタンバイ側ではDomain0だけが稼動していて、仮想サーバは動いていない状態。
アクティブ側のDomain0をメンテするときに限り、ライブマイグレーションでスタンバイ側へ仮想サーバを移動させ、メンテ終了後、再びライブマイグレーションでフェイルバックするようなイメージです。
これなら、排他制御がらみの問題は気にしなくて良いかもしれません。
もちろん、運用する側から見ればアクティブ・アクティブで、負荷を分散したいところですから、そうなるとどうしてもクラスタ＋分散ファイルシステムの出番となります。
■次回は、クラスタ+GFSについて、実際の設定例や運用方法について書いてみることにします。