高可用性
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にすることができます。プールは、障害発生時に障害検出と回復を調整できるようにする情報を保存します。
- ハートビート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をシャットダウンする」を参照してください。
- HAが内部シャットダウン時にVMを自動的に再起動しないように構成されている場合、ゲストOS内からの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回試みます。