CFクラスタ内の各ノードは、クラスタ内で他のノードの状態を監視します。ノードの状態は、UP (起動中)、DOWN (停止中)、またはLEFTCLUSTERの3通りです。
LEFTCLUSTERとは、UPとDOWNの中間の状態です。つまり、通信不能のため、ノードの状態を判別できません。
たとえば、以下の図に示す3ノードクラスタについて考えてみます。
図5.1 接続が確立されている3ノードクラスタ
各ノードから見たすべてのノードの状態が、ノードごとのテーブルに格納されます。
次に、ノードCとの接続が失われたクラスタパーティションがあるとします。この結果を以下の図に示します。
図5.2 接続が失われた3ノードクラスタ
ネットワーク通信が分断されているので、ノードAとBはノードCの正しい状態を確認できません。したがって、ノードAとBは状態テーブルを更新してノードCの状態をLEFTCLUSTERと判断します。同様に、ノードCはノードAとBの正確な状態を確認できないので、状態テーブルでノードAとBの状態をLEFTCLUSTERと判断します。
注意
LEFTCLUSTERは、特定のノードから他のノードを見たときの状態であり、そのノード自身を見た状態ではありません。たとえば、“図5.2 接続が失われた3ノードクラスタ”で、LEFTCLUSTERとなった各ノードは自分自身はUP (起動中) であると認識しています。
LEFTCLUSTER状態を使用するのは、CFを使用するサービスに、別のノードとの接続が失われたこと、およびそのノードの状態を判別できないことを警告するためです。これはRMSにとって非常に重要です。
たとえば、ノードB とC で切り替えられるようにRMSが設定されているとします。
ユーザ業務が同時に起動されると、共用ディスクのデータが破損するので、アプリケーションがどちらか一方のノードで稼動していることを確認する必要があります。
仮に、LEFTCLUSTER状態が存在しないという前提でネットワーク通信が失われたとすると、すぐに各ノードは通信不能になったノードをDOWNとマークします。するとノードB上のRMSは、ノードCがDOWN状態であると認識します。次に、フェイルオーバプロセスの一部として、ノードC上のアプリケーションのインスタンスを起動します。しかし、ノードCは本当にDOWN状態ではなく、ノードCとの通信が失われただけですので、アプリケーションはノードC上でまだ稼動しています。アプリケーションは共用ディスクに排他的にアクセスしているという前提でデータを更新しますが、相互に干渉し合ってデータが破損します。
しかし、LEFTCLUSTER状態を導入することにより、このような状況を回避することができます。RMSおよび、CFを使用中の他のアプリケーションは、接続が失われた状態 (通信不能のため状態が不明なノード) と完全に停止しているノードを区別することができます。
SFはノードがLEFTCLUSTER状態であると判断すると、SA (シャットダウンエージェント) と通信し、LEFTCLUSTER状態のノードを停止するように、SAに依頼します。SFは運用中のアプリケーションとクラスタノード自体に設定された生存優先度から、ネットワークパーティションで分断されたクラスタノード群の生存優先度を計算し、優先度の低いものを強制停止させ、最も優先度の高いクラスタノード群の運用を継続します。PRIMECLUSTERでは、どのノードを残し、どのノードをシャットダウンするかは、重みを計算して決定します。たとえば、ノードCで停止させてはいけない重要なアプリケーションが運用中の状態である場合は、たとえ生存ノード数が少なくても、ノードAとBを強制停止させ、ノードCは運用を継続します。その時点でLEFTCLUSTER状態はクリアされ、ノードCはノードAとBをDOWNとみなします。SFの設定とSAの詳細については、“第7章 シャットダウン機構 (SF)”を参照してください。
注意
ノードがクラスタ内の他のノードからLEFTCLUSTER状態とみなされている間は、既存のクラスタに参入することはできません。既存のクラスタに参入する前に、LEFTCLUSTER状態から回復する必要があります。
