高可用性
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をシャットダウンする」を参照してください。
- ゲスト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回試行します。