目的
スプリットブレインを、クラスタ初心者に向けてざっくり説明することを目的としています。
この記事でわかること
- スプリットブレインとは何か
- スプリットブレインへの対策
スプリットブレインってなに？
前回、Corosyncがハートビートによりお互いの生存確認をしていると説明しましたが、
障害によってはこのハートビートのみが障害を起こす場合があります。
２ノード構成で通常時はNode1でリソースが起動しているAcitve/Standbyのクラスタ構成で考えてみます。
ハートビート通信でお互いに正常であることが確認できているため、何も起きません。
しかし、ハートビート通信のみ障害が起きた場合は以下のような状況になります。
両ノードともに自身は正常だけどもう１台のノードが死んだと勘違いします。
そのため、自身がクラスタの生き残りだと判断して、各自がクラスタを構成しようとします。
それがスプリットブレインです。
その際に、仮想IPが複数起動されることでIPアドレスが重複したり、DBを両ノードが起動してデータの整合性がおかしくなったりと問題が発生してしまいます。
どうやって防ぐ？
軽い感じで書きましたが、実際に発生したらとんでもない障害です。
そのため、クラスタや可用性を設計する際はかならずスプリットブレインを起こさないよう検討する必要があります。クラスタにはこれを回避する仕組みが存在します。
クォーラムによる多数決
スプリットブレインを引き起こさない考え方としてクォーラム（多数決）があります。
クラスタの主導権を握るのは過半数以上のノードが存在する側で、主導権を握った側がリソースの起動ができるようにするというものです。
例えば3台のノードでクラスタを組んでいる場合を考えてみます。
この構成ではクォーラムを獲得するには２票必要になります。
この構成でNode3のハートビート通信に異常がおきたケースは以下のようになります。
障害が発生したノードは１票、それ以外の側が２票を持つため、２票側でのみクラスタが構成されスプリットブレインを回避できます。
偶数台ノードでのクラスタ構成の注意
たとえば２台構成の場合、１台と１台にクラスタが分断されてしまい、どちらもクォーラム（過半数）をとれず、スプリットブレイン発生、もしくはクラスタ停止が発生してしまします。こういった場合はフェンシング（STONITH）と呼ばれるサーバの強制停止機能でリソースの多重起動を防ぐ手段やクォーラムサーバ等のクラスタ外部の存在を利用することで解決します。
まとめ
- スプリットブレインは、ハートビート通信切断等によって発生するクラスタリソースの多重起動のこと
- クォーラム（多数決）によりクラスタのスプリットブレインを防ぐ
- 偶数台のクラスタ構成ではクォーラムの考えだけでは問題が発生するため、フェンシングや外部のクォーラムを利用することを検討する