解説

XenServer HAのホスト監視とホストが動作し続ける条件について

　XenServerの高可用性（HA）機能では、ネットワークとストレージを介してハートビートと呼ばれる通信を行うことで、各ホストが互いの健全性を確認している。また、XenServerの管理モジュールは、ここで得られた健全なホストの一覧を利用して、障害が発生した仮想マシン（VM）をフェイルオーバーさせることでVMの可用性を維持している。

XenServer HA機能の仕組み

　ハートビートによるホスト監視における最悪のシナリオは、あるホストが外部との通信パスを切断されているにもかかわらず、そのホスト上で稼働中のVMが共有ストレージにデータを書き込み続ける事態である。この場合、そのホストは他のホストから障害が発生したと認識され、同一のVMが複数のホストで同時に稼働し、結果、共有ストレージのデータを破損させてしまう（いわゆる、ネットワークパーティション《分断》状態におけるスプリットブレインシンドローム）。

　この事態が発生しないよう、XenServer HAでは、ハイパーバイザーレベルでのホスト隔離（フェンス、強制停止）機能などを活用し、プールが複数のパーティションに分割されて動作しないように維持している。隔離すべきホストの選択には完全な分散アルゴリズムが実装されており、各ホストが独立して自ホストの状況を見極め、必要な処理を行う。具体的には、次のような条件を満たさないホストをプールから隔離し強制停止する。

• 条件1

XenServer管理レイヤー（XAPI）が自ホスト上で稼働中かつ自ホストからハートビートSR（Storage Repository）へのアクセスが可能。自ホストがネットワーク上で最大ホスト数のパーティションに属している。

• 条件2

XAPIが自ホスト上で稼働中かつ全てのホストが稼働中であるが、どのホストからもハートビートSRへのアクセスができなくなっている。

　また、このアルゴリズムは、単一のホストだけがネットワークから分断されることのみを想定したものではなく、複数のホストが複数のパーティションに複雑に分断されても最悪の事態を防げるよう設計されている。

　なお、条件2で稼働しているときに一部のホストが停止すると、どのホストでも条件2を適用できなくなり、結果として全ホストが隔離される。これは、データ破損を避けるフェイルセーフ設計によるものである。現場での混乱を避けるために事前に理解しておきたい。ただし、多くのケースでは、ハートビートSRとVMデータを格納しているSRは同一の共有ストレージ上にあると考えるので、適切に設計されたシステムであれば、大きな問題にはならないだろう。

補足解説

　実際のシステムでどうかはさておき、一般的に、ホスト間の通信パスは「きれいに」切断されるとは想定できない。例えば、［A→B］通信はできるが、［B→A］の通信はできない場合がある。この複雑さは、双方向通信ができるもののみを通信可能と判断することで比較的簡単に排除できる。

　本当に難しい問題は次のような場合である。例えば、［A－B］［A－C］［A－D］［B－C］［C－D］の通信はできる（上記の通り片方向通信は排除してあるので通信パスの向きは無視している）が、［B－D］の通信はできないといった状況である。このような状況でホストDをプールに含めてしまうと、BとDは互いに通信できないため、さまざまな不都合が起こり得る。これを避けるために、ホストDを隔離したい。すなわち、全ホストと通信できるホスト集合のうち、ホスト数最大の集合を発見したい。この問題は、「最大クリーク問題」と呼ばれており、現実的な計算時間で最適解を発見するのは難しいことが知られている。詳しいアルゴリズムは割愛するが、XenServer HAでは、近似的な計算を行うことで現実的な時間で隔離すべきホストを選択している。