LifeKeeper によるクラスタシステムの構築や保守をご担当される方を対象に、スプリットブレインと、LifeKeeperにおけるスプリットブレインの対策（フェンシング）についてご説明いたします。
1.スプリットブレインとは
「スプリットブレイン」とは、クラスタ配下の複数のノードにて、同時に同じリソースやアプリケーションが起動している状況を指します。
スプリットブレインが発生しますと、クライアントからクラスタ環境のノードへの通信にて、稼働系ノード、待機系ノードのどちらにも接続できてしまう危険があり、両ノードにてデータベース等の情報に不一致が発生する恐れがあります。
このため、クラスタシステムではいくつかのスプリットブレイン対策が用意されています。
※重要※
製品としてスプリットブレイン対策があっても、タイミングなどによりスプリットブレインが発生するケースは少なからずあります。
そのため、LifeKeeper にて保護されるディスク（共有ディスクやデータレプリケーション対象のディスク）内のデータにつきましては、定期的にバックアップを取得する等の対策もご検討ください。
2.スプリットブレインが発生する主な原因について
「スプリットブレイン」は、ノード障害によるフェイルオーバーや各ノードを監視しているネットワーク回線の不具合において発生することがあります。
ノード障害が発生する主な原因は、次のとおりです。（[Linux][Windows] フェイルオーバーの仕組みについて）
主な発生ケース
※スプリットブレイン対策を実施していない場合。
1）稼働系ノードにて、意図しない再起動が発生した場合
稼働系ノードが障害などで再起動した事によるフェイルオーバーにおいては、待機系ノードにてリソースやアプリケーション起動が行われます。
このため、待機系ノードでリソースやアプリケーション起動が行われている中、稼働系が再起動してくる事により稼働系でもアプリケーションやリソースが起動されてしまうことがあります。
このような時、稼働系、待機系の両方でリソースやアプリケーションが起動されスプリットブレインとなります。
2）稼働系ノードと待機系ノードの通信にて切断が発生した場合
通常、クラスタシステムでは、お互いのノードが正常に動作しているかを確認するためにネットワークを使い監視します。
このため、各ノードは健全に動作しているにも関わらず、監視に利用しているネットワークに何らかの不具合が生じた場合、待機系ノードは稼働系ノードがダウンしたと判定しフェイルオーバーを開始します。
この際、待機系ノードは自ノードのリソースやアプリケーション起動させます。
しかし、実際は稼働系は健全に動作していますので、結果としてスプリットブレインとなります。
3.スプリットブレインの対策
スプリットブレインへの対策として、LifeKeeper では次のフェンシング方法をご用意しております。
- Quorum/Witness（Linux版 及び Windows版は v8.9.0以降）
- SCSI リザベーション（Linux版 のみ）
- STONITH（Linux版 のみ）
- Watchdog（Linux版 のみ）
上記対策の概要は、それぞれ次のとおりです。
Quorum/Witness（Linux版 及び Windows版v8.9.0以降）
Quorum/Witness の特徴は、稼働系ノード、待機系ノードの他に、第三の環境（ノード、もしくはストレージ）を設置する点にあります。
ノード障害を判定するコミュニケーションパス全断が発生した際、稼働系ノード、待機系ノードは第三の環境にそれぞれ接続し、フェイルオーバーの要否を判定します。
要否判定の結果、フェイルオーバーが不要と判断できた状況ではフェイルオーバーは行われません。反対にフェイルオーバーが必要と判断した状況では、待機系ノードではフェイルオーバー(リソース起動)を実施します。
稼働系ノードでは設定に応じて、OS のシャットダウン、OS 再起動、リソースの停止のいずれかを実施いたします。
※第三の環境につきましては、サーバ（majority モード）、もしくはストレージ（storage モード）のご利用を推奨いたします。
また、クラウド環境ではネットワーク上のノードを第三の環境とする tcp_remote モードのご利用を推奨しておりません。
利用可能な方式と組み合わせはマニュアルの該当箇所を参照ください。
- マニュアル（Linux版）：Quorum/Witness ※v9.9.0の場合
- マニュアル（Windows版）：Quorum/Witness ※v8.10.1の場合
SCSI リザベーション（Linux版 のみ）
LifeKeeper の認定ストレージをご利用いただく場合、LifeKeeper のディスクリソースとして保護することで機能します。
※ディスクリソースはファイルシステムリソース作成時に作成されます。
SCSI-2 および SCSI-3 の仕様に準拠した、SCSI reserveによるフェンシング方式となり、高いレベルで共有ディスクのスプリットブレイン発生を抑制します。
詳細は次のサイトのご案内のとおりですが、ノード間のコミュニケーションパス全断が発生した際、
待機系ノードにてディスクリソースが起動後、稼働系ノードでは OS のシャットダウンが実行される事でスプリットブレインを抑止します。
[Linux] 共有ストレージを使用しています。ハートビートが全て切断された場合、どのような挙動を示しますか
※LifeKeeper のサポート対象となるストレージをご利用しない環境においては、Quorum/Witness を導入してください。
[Linux]ストレージサポートポリシー（Any Storage）について
STONITH（Linux版 のみ）
物理環境、仮想環境、AWS、Azure 、かつ、STONITHが利用できる環境にてご利用可能です。
対向先ノードとのコミュニケーションパス全断を検知した際、対向先ノードに対して、シャットダウンを強制的に命令します。
注意点としては、稼働系ノード、待機系ノードの両ノードにて双方にシャットダウンを命令（受信）を実行してしまう事があります。
Watchdog（Linux版 のみ）
対向先ノードではなく、自身の環境における、LifeKeeper のプロセスを定期的に監視します。
監視の結果、反応を確認できない状況が一定期間続く場合、自身の OS の再起動を実施します。
4.Windows 版 LifeKeeper 特有の仕様
Windows 版 LifeKeeper では、スプリットブレインの発生率を低減させるための仕組みとして、LifeKeeper のコミュニケーションパス（対向先ノードとの通信経路）の動作に次の特徴があります。
■すべてのコミュニケーションパスが切断された際、フェイルオーバーには即時に移行せず、コミュニケーションパスに設定していない NIC がある場合は該当の NIC を使用して、対向先ノードとの通信を試みます。
対向先ノードとの通信が成功する場合、フェイルオーバーは不要と判断いたします。
※[Windows] コミュニケーションパス全断が発生した際の挙動について
■コミュニケーションパスの設定として、ネットワーク（TCP）の他、共有ディスクを用いることが可能です。
なお、Quorum/Witness におけるストレージ（storage モード）のご利用とは異なり、コミュニケーションパスでの共有ディスクの設定においては、ディスクアクセスが不可となる状態が発生しましても、自身にて起動しているリソースを停止させることはありません。