目的
前回、偶数台ノードではクォーラムだけではスプリットブレインの対策としては不十分であるとお伝えしました。今回は２台構成のクラスタを例に挙げて、どのように対応するのかざっくりと説明することを目的としています。
この記事でわかること
- 2ノード構成クラスタの注意点（おさらい）
- スプリットブレイン対策①（フェンシング）
2ノード構成の注意点（おさらい）
ハートビート通信が切れると、互いに生き残りだと誤解してリソースを重複起動してしまう。これがスプリットブレインだと説明しました。
クラスタではクォーラム（多数決）によってスプリットブレインを防ぎます。しかし、2ノード構成だとお互いが１票をもつため過半数を獲得できず、クォーラムは正しく機能しません。
クォーラムが機能しない場合
２ノード構成の場合、どちらのノードも過半数を取れず、クラスタを維持することができなくなります。
これでは、止まらない構成を作るためのクラスタの意味がなくなってしまいます。
pacemakerではこれを回避するようクォーラムを満たさなくてもクラスタを継続できるよう設定（no-quorum-policy=ignore）できます。
しかし、ここで注意しないといけないのが、クォーラムを満たさなくてもクラスタを構成できるということは、両方のノードでクラスタが構成され、スプリットブレインを発生させる可能性があります。
スプリットブレイン対策その①：フェンシング
スプリットブレインを防ぐための基本的な対策が、フェンシングです。
PacemakerではSTONITHと呼ばれたりもします。
STONITH（Shoot The Other Node In The Head：他ノードを撃ち殺す）とは、
通信できなくなった相手ノードを強制的に停止させることで、リソースの多重起動を防ぐ仕組みです。
まずは下図のような2ノードクラスタ構成でPacemakerを使い、
クォーラムが満たされなくてもリソースを起動できる設定
（no-quorum-policy=ignore）になっている場合を考えます。
この状態では、Node1 側でリソースが起動しており、
Node2 ともハートビート通信ができているため、問題なくクラスタが維持されています。
次に、ハートビート通信にのみ障害が発生した場合
Node2側でクラスタを構成してリソースを起動しようとします。
しかし、Node1側でも起動しているので、このままではリソースの多重起動になってしまいます。
そこで、フェンシング(STONITH)の機能を使います。 ここではNode1側にNode2がおかしい時にHW側からOS停止するフェンシング設定が入っているケースを考えます。
Node1はNode2が死んだと判断し、事前に設定されていたフェンシング設定によりNode2のOSを強制停止させ、スプリットブレインを回避します。
実際には、Node2側にもフェンシング設定が入っていたり、このフェンシングがうまく実行されなかったりと100％スプリットブレインを防ぐことができるわけではありませんが、フェンシングはスプリットブレインを防ぐ最後の砦として機能します。
まとめ
- 2ノード構成では過半数をとれないので、設定によってクォーラム判定を無視してリソースを起動し続ける場合がある
- その場合、フェンシング（STONITH）によって、リソースの多重起動を防ぐ