第６回　HAクラスター構成の敵「スプリットブレイン対策」はこれだ！

こんにちは、SCSK　池田です。

早いもので2023年も終わりを告げようとしています。皆さんにとってはどのような１年でしたか？
私は、このTech HarmonyでLifeKeeperに関するブログを投稿し始めた思い出深い１年となりました。

さて前回は、前田さんより、AWS環境におけるLifeKeeperで対応可能ないくつかの接続方法についてお伝えしました。
６回目の今回は、HAクラスター構成の敵とも言える「スプリットブレイン」についてLifeKeeperでどのよぅな対策がなされているのかについてお伝えします。

スプリットブレインとは？

「スプリットブレイン？」「脳が分かれる？」。またまた聞きなれない用語が出てきました。「スプリットブレイン」とはどのような状態なのでしょうか？

HA クラスターシステムは、多くの場合において、2台のサーバでアクティブ-スタンバイの構成となり、2台のうちのどちらか一方だけのサービスが起動している状態です。ところがある条件下において、2台ともがサービスを起動しようとしてしまい、正しくサービスが提供できなくなることがあります。
この状態のことを「スプリットブレイン」もしくは「スプリットブレイン シンドローム」と呼びます。

本来1台だけでサービス提供するところ、
誤って2台が提供しようとして障害になってしまうのは問題だね

ではどんな時にスプリットブレインが起きてしまうのでしょうか？

まず2台のサーバでクラスタを構成している前提とします。2台はお互いの死活状態を確認しています。
この動作をハートビートと言いますが、ネットワークの障害など何らかの原因によって、お互いの死活状態を確認できなくなった場合に、それぞれのサーバは、相手のサーバが停止しサービス提供ができなくなったと判断し、自らが稼働系になろうとします。これによってスプリットブレイン状態になってしまうのです。

スプリットブレイン状態となった時に一番怖いのが、両方のサーバから共有ディスクに書き込んだ場合です。これが起きてしますと最悪共有ディスク上のデータで不整合が発生して、データ破損に繋がってしまいます。

せっかくのHAクラスタ構成なのに
データの不整合が起きてしまうのは避けたいわ

LifeKeeper では、この様なスプリットブレインを発生させないために、Quorum/Witness(クォーラム/ウィットネスと呼びます) をいう機能を利用することが出来ます。

Quorum/Witnessとはなに？

また新しい言葉が出てきましたが「Quorum/Witness」とは、スプリットブレインが発生した場合に、どちらのサーバが稼働系になるべきかを判断する為の機能となります。

「Quorum」の主な機能は、多数決の仕組みを使って稼働系となるべきサーバを決定する機能です。「Witness」は障害が発生したノードのステータスについて「セカンドオピニオン」を取る機能です。「Quorum」による多数決だけでは、本当に稼働すべきサーバか判断が付きかねる場面において、障害が発生していると思われるサーバについて、Witnessサーバの「セカンドオピニオン」を取ることで、より確実な判断をすることができるようになります。
まずは一般的な障害シナリオを見てみましょう。

シナリオ１　サーバAと他の全ノードとの間の通信に障害発生(サーバAに障害発生)

シナリオ２　サーバAとサーバBの間の通信で障害発生

次に、サーバ間の通信で障害が発生したものの、Quorum/Witnessサーバがいるお陰で、不要なフェイルオーバを抑止するパターンをご紹介します。

シナリオ２の場合では、もしもQuorum/Witnessサーバが存在しなかった場合は、サーバAで継続してサービス提供可能にも関わらず、フェイルオーバが発生してしまい、一時的ではありますが、サービスが利用できない時間帯ができてしまいます。

Quorum/Witness機能を実装するために必要な費用及び維持していく費用と、要求する可用性レベルとの天秤になるポイントとなりますので、お客様との十分なすり合わせが必要となります。

まとめ

今回は、Quorum/Witness機能についてご説明しましたがいかがでしたでしょうか？
システムとしてデータの整合性や一貫性が損なわれてしまうのは一大事ですよね。
非常に重要な機能ではありますが、LifeKeeperではQuorum/Witnessがオプションとして用意されているので、簡単に組み込むことができます。

まとめますと

次回は、「たった１台で可用性を高められる！？　～ Single Server Protection ～」についてお伝えします。お楽しみに！！

良いお年を！！