Cluster Shared Volumeの制御について前回は憶測アーンド推測を述べたわけですが、ついでに通常のクラスタディスクはどういう制御をしているかについて述べてみた。

普通のクラスタディスクドライバ（clusdisk.sys)の場合は、SCSIコマンドを使用した排他制御が行われている。（このあたりの記載はhttp://support.microsoft.com/kb/309186/jaに書かれているよ。）

• クラスタディスクドライバが起動すると、reserveコマンドを発行して、対象のディスクを掴みに行く。こうして最初にディスクを掴んだものがdefenderとなる。
• reserveコマンドは先に別のノードで実行され、掴まれている状態では失敗する。こうして失敗したノードはchallengerと呼ばれる。
• defenderは3秒間隔でreserveコマンドを発行し、ディスクを独占する。
• 一定期間ハートビートが途絶すると、アービトレーション（調停処理）が開始される。
  • 検知したchallengerはbusresetコマンドを発行して、SCSIバスをリセットする。
  • challengerは10秒（だったと思う）程度待機し、reserveコマンドを発行してdefenderの所有するディスクを奪いにかかる。
  • もし、defenderが生存していれば、その間にreserveコマンドが発行されている為、ディスクの所有権は移動しない。
  • もし、defenderが死亡していれば、そのディスクはreserveされていない為、見事所有権を獲得することができ、自身がdefenderとなる。
  • この時、全てのハートビートが途絶した状態の場合、Quorumディスクのdefenderが唯一生存を許されるノードとなり、稼働することができる。それ以外のノードは全てクラスタサービスを停止し、スプリットブレーンの発生しない状況に持っていく。（自殺処理）

このように、Windows Server 2003以前のMSCSでは動いており、こうした排他制御を「ハードウェア排他」と呼んでいる。これに対してCLUSTERPROは所謂ソフトウェア排他 を行っているらしい。ソフトウェア排他は柔軟なカスタマイズが可能なのがウリなのだけど、制御がハード主体に比べて弱いので、スプリットブレーンのリスク は比較的高いと言われている。この逆がハードウェア排他には言えるわけで。業界的にはハード排他のケースが多いような気がする。

ちなみに、Cluster Serviceを停止したにもかかわらず、ディスクの設定が変更できなかったり、ベーシックディスクの拡張ができなかったりするのは、このclusdisk.sysが動いているせいだったりする。クラスタディスクの完全復旧を行う際、Cluster Serviceの無効化だけでなく、このクラスタディスクドライバの無効化も行う必要があったもんね。

Windows Server 2008になってから、これをオンラインで対応できる「メンテナンスモード」と言う機能が出たのには驚いたよ。ほんと。

Windows Serverも進化してるんだねーと実感した今日この頃。