高可用性
XenServer® の高可用性 (HA) 機能は、最小限のダウンタイムとデータ破損なしで、VM を稼働し続けることを保証します。ホストのハードウェア障害やネットワーク障害などの問題が発生した場合、XenServer プールは、影響を受けた VM をプール内の安定したホストで再起動することで対応します。この機能により、ハードウェアの問題を解決できるまで VM を稼働し続けることができます。
XenServer は、以下の方法で VM の高可用性を確保します。
- ネットワークハートビートを使用して、プール内のホスト間の接続を確認する。
- ストレージハートビートを使用して、ホストと共有ストレージ間の接続を確認する。
- ホストが故障したかどうかを検出する。
- 1つまたは複数のホストが到達不能になったかどうかを検出する。
- プール内のホストの最大のパーティションと通信できないホストをフェンシングする。フェンシングされたホストは直ちに再起動し、その上で実行されているすべてのVMを停止させます。再起動後、リソースプールに再参加しようとします。この予防措置により、VMが同時に2つのホストで実行され、データ破損のリスクが生じるのを防ぎます。
- 故障した、フェンシングされた、または到達不能なホストを、プール内のライブホストセットの一部ではないとマークする。
- そのホストで実行されていたVMをすべて停止済みとマークする。
- 故障した、フェンシングされた、または到達不能なホストがプールコーディネーターである場合、コーディネーターの役割をプール内の別のホストに再割り当てする。
- 設定したフェイルオーバー計画に従って、停止したVMを再起動する。
- プール構成への変更を監視し、設定されたフェイルオーバー計画が実行可能であることを確認する。
HA機能はプール内の他のホストでVMを自動的に再起動するため、XenServerはVMの元の（故障した、または到達不能な）ホストがVMを実行していないことを確認する必要があります。同じVMの2つのインスタンスが同時に実行されると、VMのデータが破損する可能性があります。この可能性を防ぐため、HAが有効なプール内のXenServerホストは、同じVMの2つのインスタンスが実行される可能性のある状況にある場合、積極的に自己フェンシングを行います。
HA機能は、基盤となるハードウェアまたはネットワークの問題を解決できるまで、重要なVMを稼働し続けます。HAイベントが発生したことを認識したら、基盤となる障害を調査して解決し、プールを完全な容量に戻してください。
この記事では、高可用性の概念、要件、および期待される動作について説明します。高可用性の構成と管理については、「高可用性の構成」を参照してください。
要件
高可用性機能を使用するには、環境に次の項目が必要です。
-
XenServerプール：HA機能は単一のリソースプール内で動作します。
- プールは均一であることをお勧めします。プール内の各ホストは、同じCPU機能セットをVMに公開し、VMがプール内のどこでも再起動しやすくなります。
- ハートビートメカニズムが効果的に機能するためには、プールに少なくとも3つのホストがあることをお勧めします。
- HAを有効にする前に、プール内のすべてのホストがオンラインであることを確認してください。
-
プール内のすべてのホスト用の共有ストレージ：障害発生後にプール内の任意のVMをプール内の任意のホストで再起動できるようにするには、プール内のすべてのホストがVMディスクが保存されているSRにアクセスできる必要があります。
-
ハートビートSR：このSRは、VMディスクが保存されているSRと同じにすることができます。プールは、障害発生時に障害検出と回復を調整できるようにする情報を保存します。
- ハートビートSRは、iSCSI、NFS、またはファイバーチャネルLUN上にある必要があります。SMBまたはCHAP認証を使用してiSCSIで接続されたストレージは、ハートビートSRとして使用できません。このSRは、低遅延で信頼性の高いものであることをお勧めします。
-
XenServer 8.4では、ハートビートSRに4 GBが必要です。
ハートビートSRに保存される情報には、次のものが含まれます。
- 4 MBのハートビートボリューム：ストレージハートビートを提供し、プール内のホストがストレージにアクセスできることを確認します。
- メタデータボリューム：プールコーディネーターのフェイルオーバーが発生した場合に使用されるプールコーディネーターのメタデータを保存します。このボリュームは、必要な残りのスペースを占有します。
-
ハートビートSR用の信頼性の高い冗長ストレージ通信：HA機能が共有ストレージにアクセスできるホストを最も正確に把握できるように、ストレージトラフィックが信頼できることを確認するように環境を構成してください。iSCSIおよびファイバーチャネルSRの場合は、マルチパスを構成します。NFS SRの場合は、回復力のあるボンディングされたネットワークをストレージネットワークとして使用します。
-
すべてのホストの静的IPアドレス: HAは、ホストのIPアドレスの変更をホストが接続を失ったものとみなし、ホストのネットワークが障害を起こしたと判断します。その結果、ホストがフェンスされる可能性があります。プールでは静的IPのみを使用することで、これを回避してください。
-
管理ネットワーク上の専用ボンディングインターフェース: HA機能がプール状態を最も正確に把握するためには、ホスト間の信頼性と冗長性のあるネットワーク通信が必要です。
-
管理ネットワークはポート694経由のネットワークハートビートUDPトラフィックを許可する: ネットワークハートビートは、プール内のホストが稼働しており、互いに通信できることを確認します。
-
すべてのプールホスト間の近接接続: プール内のすべてのホストは、5ミリ秒未満のラウンドトリップ遅延と10 Gbps以上のネットワークスループットで接続されている必要があります。複数のデータセンターに分散されたホストは、それらのデータセンターが近接定義を満たしている場合にのみプールを共有できます。ホスト間の高遅延は、ハートビートの欠落による誤ったフェンシングのリスクを高めます。
注記:
HAはデータセンターの境界を認識しません。ホスト障害後にVMを再起動する際、HAは利用可能なメモリに基づいて、データセンターの親和性や優先順位の概念なしに、プール内の利用可能な任意のホストにVMを配置します。プールを2つの近接データセンターにまたがって展開し、データセンター全体が障害を起こした場合、HAは影響を受けたVMを生き残ったホストで再起動しようとしますが、その結果は利用可能な容量と、共有ストレージがそれらのホストから引き続きアクセス可能であるかどうかに依存します。これは、制御されたデータセンターレベルのフェイルオーバーを構成するものではありません。データセンター全体の障害に対する回復性については、ディザスタリカバリを参照してください。
高可用性プールで実行されているVMを保護するには、以下の構成でVMを設定します。
- VMディスクをプール内のすべてのホストで利用可能な共有ストレージに保存します。
- 仮想ネットワークインターフェースをプール全体のネットワーク上に設定します。
- VMがライブマイグレーションを使用できることを確認します。詳細については、マイグレーション互換性要件を参照してください。
- VMをローカルDVDドライブに接続しないでください。
これらすべての基準を満たすVMは、アジャイルと呼ばれます。
NVIDIA vGPUまたはGPUパススルーを使用するVMは、HAによって保護できません。ただし、HAメカニズムは、このVMをベストエフォートで再起動しようと試みることができます。
GFS2クラスタープールに関する要件
GFS2クラスタープールの高可用性動作は、異なる基盤メカニズムを使用するため、いくつかの異なる要件と動作があります。詳細については、GFS2クラスタープールを参照してください。
HAフェイルオーバー計画
HAメカニズムは、以下の基準に基づいてプール全体のフェイルオーバー計画を計算します。
- VMの復旧要件: 各VMには、再起動の優先順位と起動順序を定義できます。
- 利用可能なプールリソース: 考慮される主なリソースはホストメモリです。
- 許容するホスト障害の数: プールでHAを有効にすると、XenServerは、保護されたVMが再起動できなくなるまでにプール内で障害が発生する可能性のあるホストの最大数を計算できます。許容するホスト障害の数を、この値以下に設定できます。
これらの基準を満たすフェイルオーバー計画を計算できない場合、プールはオーバーコミットされていると見なされます。保護されたVMをプール内で再起動できない場合、XenServerはシステムアラートを発生させます。このアラートは、XenCenter®の通知パネルにも表示されます。
プール内のすべてのVMについて、その復旧動作を定義できます。
再起動の優先順位
VMには、以下のいずれかの再起動優先順位を割り当てることができます。
-
保護: VMまたはそのホストが予期せずオフラインになった場合、HAは別のホストでVMを再起動します。プールがオーバーコミットされておらず、VMがアジャイルである場合、この再起動は保証されます。VMの再起動が失敗した場合、HAはプールに余分な容量があるときにVMを起動しようとします。この値はxe CLIでは
restart、XenCenterでは再起動です。 -
ベストエフォート: VMを実行しているホストが予期せずオフラインになった場合、HAは別のホストでVMを再起動しようとします。この試行は、すべての保護されたVMが正常に再起動された後にのみ行われます。高可用性は、ベストエフォートVMの再起動を1回だけ試行します。この試行が失敗した場合、高可用性はVMの再起動をそれ以上試行しません。この値はxe CLIでは
best-effort、XenCenterでは可能な場合は再起動です。 - 保護なし: VMまたはそのホストが予期せずオフラインになった場合、HAはVMの再起動を試行しません。これはデフォルト設定です。この値はxe CLIでは空の文字列、XenCenterでは再起動しないです。
高可用性は、より高い再起動優先順位を持つVMを再起動するためにリソースを解放するために、実行中のVMを停止または移行することはありません。
起動順序
起動順序は、障害発生時にXenServerの高可用性が保護されたVMを再起動しようとする順序です。この値は保護されたVMにのみ使用されます。デフォルト値は0で、これは最高の優先順位です。起動順序の値が0の保護されたVMが最初に再起動されます。起動順序の値が高いほど、VMはシーケンスの後半で再起動されます。
プール動作
XenServerプールでHAを有効にすると、プールは以下の動作を示します。
セットアップ中の動作
プールでHAを有効にすると、プールコーディネーターは以下のセットアップを実行します。
- 初期フェイルオーバープランを計算します。
- ハートビートSRに更新を書き込むようにデータベースを設定します。この設定により、ホストが故障した場合でもVM構成の変更が失われないようにします。
- ハートビートSR上にプールコーディネーターのメタデータを設定します。
すべてのプールメンバー：
- 相互にネットワークハートビートを送信します。その結果、プール内のホストが相互に通信できることを確認するため、管理ネットワークトラフィックがわずかに増加します。このネットワークトラフィックは、HAが有効になっている間継続します。
通常動作中の動作
通常動作中、HAプールのプールコーディネーターは（通常の機能に加えて）以下の動作を実行します。
- フェイルオーバープランを動的に維持します。このプランは、プール内の一連のホストが任意の時点で故障した場合に何をすべきかを詳細に示します。このプランは、許容できるホスト障害の最大数を考慮し、すべての保護されたVMが再起動できることを保証します。プランは、VMのライフサイクル操作と移動に基づいて動的に再計算されます。変更（たとえば、プールへの新しいVMの追加）により、最大数のホスト障害後にすべての保護されたVMを再起動できなくなった場合、プランは計算できず、プールはオーバーコミット状態になります。プールがオーバーコミット状態になると、XenServerはXenCenter、電子メール、SNMPトラップ、またはNRPEアラートを介してアラートを発生させます。
通常動作中、HAプールの各メンバーは（通常の機能に加えて）以下の動作を実行します。
- プールコーディネーターが稼働していることを確認します。ホストは、共有ストレージ上の「マスターロック」を取得しようとすることでこれを行います。プールコーディネーターがすでに存在する場合、この試行は失敗します。
- ネットワークハートビートを送信します。このネットワークハートビートは、管理ネットワーク上のポート694を介してUDPを使用して、プール内の他のすべてのホストに送信されます。
- プール内のホストのライブセットの記録を維持します。各個々のホストによるホストのライブセットは、そのホストが稼働中であると信じている他のホストのセットです。ホストがHAタイムアウト（デフォルトでは60秒）で指定された期間内に別のホストからネットワークハートビートを受信しなかった場合、プール内の他のホストと通信して、ライブセットを更新する必要があるかどうかを合意します。
- ストレージハートビートボリューム上の状態ファイルに書き込みます。このアクションにより、ホストがストレージへのアクセスを維持していることを確認します。また、ホストが互いの状態を通信できるようにします（ネットワークハートビートによる通信に加えて）。
- ハートビートSR上のデータベースを更新します。ホストは、ホストしているVMのVM構成に対する変更を記録します。
HAが有効になっている場合、一部のプール操作はブロックされるか、推奨されません。これらの操作を実行するには、一時的に高可用性を無効にしてください。
- プールにホストを追加する。
- プールからホストを削除する。このアクションによりプールがオーバーコミット状態になる可能性がある場合、ブロックされます。
- プール内のホストをシャットダウンする。このアクションによりプールがオーバーコミット状態になる可能性がある場合、ブロックされます。
- 管理ネットワークを変更する。
- プールに接続されているSRを変更する。
- クラスタリングを有効にする。クラスタ化されたプールでは、高可用性の動作と要件が異なります。詳細については、「クラスタ化されたプール」を参照してください。
通常の操作中、プールでこれらのアクションを実行しても、HAフェイルオーバープランはアクティブになりません。
- XenCenterまたはxe CLIからのVMのクリーンシャットダウン。HAメカニズムは、このVMが失敗したとは見なさず、再起動を試みません。このアクションの詳細については、「高可用性によって保護されているVMをシャットダウンする」を参照してください。
- ゲストOS内からのVMクラッシュまたはクリーンシャットダウン（HAが内部シャットダウン時にVMを自動的に再起動しないように構成されている場合）。この場合、HAメカニズムはVMが失敗したとは見なさず、再起動を試みません。この設定の詳細については、「内部的にシャットダウンされたVMの再起動動作を構成する」を参照してください。
- XenCenterまたはxe CLIからのホストのクリーンシャットダウン。HAメカニズムは、このホストが失敗したとは見なさず、そのホストでホストされていたVMの再起動を試みません。ただし、このアクションによりプールがオーバーコミット状態になる場合、XenServerによってブロックされます。このアクションの詳細については、「高可用性が有効な場合にホストをシャットダウンする」を参照してください。
ハードウェア障害またはインフラストラクチャの不安定性発生時の動作
このフェーズでは、プール内のすべてのホストが、自身の接続ステータスを検出し、プール内の他のホストの接続ステータスに同意する責任を負います。
XenServer HA は、以下の種類の障害を検出して処理します。
- 障害が発生したホスト: この状況では、残りのすべてのホストは、障害が発生したホストが状態ファイルの更新を停止し、ネットワークハートビートを送信しなくなったことに非常に迅速に気づきます。適切な遅延の後、これらのホストはライブセットから削除されます。
- ネットワークパーティション: この状況では、1つ以上のホストが他の1つ以上のホストと通信できません。ホストは、定義されたタイムアウト内に他の1つ以上のホストからネットワークハートビートを受信していないことに気づき、障害ハンドラーを開始します。この障害ハンドラープロセスは、状態ファイルと動作中のネットワークハートビートを介して通信し、その情報を使用して、どのようなネットワークパーティション（相互に通信できるホストのグループ）が存在するかを判断します。最大のパーティション内のホストがライブセットとなり、存続します。同じサイズのパーティションがある場合、最も低いホスト UUID を持つホストを含むパーティション内のホストが存続します。
- ストレージ接続の障害: この状況では、ホストはストレージに到達できないことに気づくか、他のホストは自身の更新がストレージに存在しないことに気づきます。ホストはネットワークハートビート通信を介して、他のホストがストレージアクセスを失ったかどうかを確認します。
- すべてのホストがストレージを失ったが、ネットワークは失っていない場合、これは一時的なストレージの損失と見なされ、ホストはストレージが復旧するのを待つために稼働し続けます。それ以上の障害が発生すると、プール内のすべてのホストがフェンスされます。このルールにより、ストレージが単一障害点となることを防ぎます。
- 一部のホストのみがストレージアクセスを失ったが、すべてのホストがまだネットワークアクセスを持っている場合、これらのホストはライブセットから削除されます。
ホストが、プールの大半に対して障害が発生しているか到達不能であると認識した場合、そのホストは自己フェンスします。フェンシングは、VM データを保護するための対策として設計された予期される動作です。これにより、VM が同時に2つの場所で実行されないようにします。ホストは、自己フェンスする必要があると判断するために、以下の基準を使用します。
- ホストのツールスタックが実行されておらず、再起動できない場合、ホストは自己フェンスします。
- ホストがネットワークとストレージの両方のハートビートを失った場合、ホストは自身が到達不能であると判断し、自己フェンスします。
- ホストがストレージハートビートを失ったが、まだネットワークハートビートを受信している場合:
- ホストが他のすべてのプールメンバーとまだ連絡が取れ、それらのすべてのメンバーもストレージハートビートを失っている場合、ホストは稼働し続けます。このケースは、ストレージが単一障害点として機能し、プール全体をフェンスすることを防ぎます。
- ホストがプール内の1つ以上の他のホストと連絡が取れない場合、自己フェンスします。
- ホストがネットワークハートビートを失ったが、まだストレージハートビートを持っている場合、それが最大のネットワークパーティションに属しているかどうかを判断します。そうでない場合、ホストは自己フェンスします。
- ネットワーク通信障害により、プールが同じサイズのパーティションに分割される可能性があります。ハートビート SR 上の状態ファイルの情報を使用して、ホストがそのようなネットワークパーティションに属していることを認識した場合:
- パーティションに最小UUIDを持つホストが含まれている場合、そのホストは稼働し続けます。
- パーティションに最小UUIDを持つホストが含まれていない場合、そのホストは自己フェンスします。
フェンスアクションが実行されると、ホストは即座に突然再起動し、その上で実行されているすべてのVMが停止します。フェンスされたホストは再起動シーケンスに入り、再起動が完了するとリソースプールへの再参加を試みます。
リカバリ中の動作
プールコーディネーターが、障害が発生した、フェンスされた、または到達不能になったホストである場合、他のホストはマスターロックの取得を試みます。成功したホストが新しいコーディネーターになります。
自己フェンスしたホストは再起動し、プールへの再参加を試みます。
ホストが「デッド」とマークされ、そのVMが停止された場合、プールコーディネーターは以下のリカバリ操作を担当します。
- フェイルオーバー計画に従って、すべての保護されたVMを再起動します。
- すべての保護されたVMを起動するのに十分なリソースがない場合、プールコーディネーターはリソースが利用可能になるまで待機し（例えば、以前フェンスされたホストがプールに再参加した場合など）、その後保護されたVMの起動を試みます。
- すべての保護されたVMが正常に起動された後、プールコーディネーターは各ベストエフォートVMの再起動を1回試みます。