XenCenter

高可用性

August 27, 2026

寄稿者:

X X

XenServer® の高可用性により、基盤となるハードウェア障害やサーバーの損失が発生した場合に、VMが自動的に再起動できるようにします。高可用性は、重要なVMがリソースプール内で常に稼働していることを保証するものです。高可用性が有効になっている場合、いずれかのサーバーで障害が発生すると、そのVMは同じプール内の他のサーバーで再起動します。この機能により、システムまたはコンポーネントの障害が発生した場合でも、最小限のサービス中断で重要なサービスを復元できます。

プールコーディネーターサーバーで障害が発生した場合、XenServer の高可用性は、新しいサーバーをプールコーディネーターとして引き継ぐように選択します。プール内の任意のサーバーがプールコーディネーターサーバーになることができます。XenServer は、プールデータベースをすべてのノードにわたって常にレプリケートします。また、追加の安全性のため、ハートビートSR上の共有ストレージにデータベースをバックアップします。

XenServer の高可用性には、次の2つの重要な側面があります。

サーバー障害の確実な検出
迅速な復旧を可能にする障害計画の計算

可用性のためのハートビート

サーバー障害を確実に検出することは困難です。サーバーが一時的に消えたのか、壊滅的な障害が発生したのかをリモートで区別する必要があるためです。高可用性が誤ってプールコーディネーターサーバーが故障したと判断し、新しいプールコーディネーターを選出した場合、元のサーバーが復帰すると予期せぬ結果が生じる可能性があります。同様に、ネットワークの問題によりプールが2つの等しい半分に分割された場合、両方が同時に共有ストレージにアクセスするのではなく、片方のみがアクセスするようにする必要があります。XenServer は、ストレージハートビートとネットワークハートビートという2つのメカニズムを持つことで、これらすべての問題を解決します。

プールで高可用性を有効にすると、iSCSI、Fibre Channel、またはNFSストレージリポジトリをハートビートSRとして指定します。XenServer は、このSR内にいくつかの小さな仮想ディスクを自動的に作成します。最初のディスクは、リソースプール内のすべてのサーバーによって共有クォーラムディスクとして使用されます。各サーバーは、共有ディスク内に一意のブロックを割り当て、そのブロックに定期的に書き込むことで、自身が稼働中であることを示します。高可用性が起動すると、すべてのサーバーはストレージチャネルとネットワークチャネルの両方でデータを交換します。ネットワークハートビートは、ポート694を介したUDPトランスポートを使用します。この動作は、両方のチャネルでどのサーバーが見えるかを示し、どのI/Oパスが機能していて、どのI/Oパスが機能していないかを示します。この情報は、固定点に達し、プール内のすべてのサーバーが互いに見えるものについて合意するまで交換されます。この合意が成立すると、高可用性が有効になり、プールが保護されます。この高可用性有効化プロセスは、大規模なプールでは安定するまでに数分かかることがありますが、高可用性を最初に有効にする場合にのみ必要です。

高可用性がアクティブになった後、各サーバーは、ハートビート仮想ディスクにストレージ更新を定期的に書き込み、管理インターフェイスを介してネットワークパケットを送信します。ネットワークアダプターが冗長性のためにボンディングされており、ストレージインターフェイスがサポートされている場合は動的マルチパスを使用していることを確認してください。この構成により、単一のアダプターまたは配線の障害が発生しても、可用性の問題が発生することはありません。

詳細については、以下を参照してください。

サーバーフェンシング

高可用性にとって最悪のシナリオは、サーバーがオフラインであると見なされているにもかかわらず、共有ストレージに書き込みを続けている場合です。このシナリオは、永続データの破損につながる可能性があります。XenServer は、この状況を防ぐためにサーバーフェンシングを使用します。サーバーは自動的に電源がオフになり、プール内の共有リソースへのアクセスから隔離されます。フェンシングは、障害が発生したサーバーが共有ディスクに書き込むのを防ぎます。この動作により、保護された仮想マシンがプール内の他のサーバーに移動される自動フェールオーバー中に、保存されたデータが損傷するのを防ぎます。

以下のいずれかが当てはまる場合を除き、いずれかのハートビート障害が発生した場合、サーバーは自己フェンスします (つまり、電源をオフにして再起動します)。

すべてのサーバーでストレージハートビートが存在するものの、ネットワークがパーティション化されている (つまり、現在2つのサーバーグループが存在する) 場合。この場合、最大のネットワークパーティションのメンバーであるすべてのサーバーは稼働し続け、より小さいネットワークパーティション内のサーバーは自己フェンスします。ここでの前提は、ネットワーク障害によってVMが隔離され、動作するネットワークを持つサーバーで再起動されなければならないということです。ネットワークパーティションが同じサイズの場合、安定した選択機能に従って、そのうちの1つだけが自己フェンスします。
ストレージハートビートが失われ、ネットワークハートビートが残っている場合、サーバーはネットワーク経由で他のすべてのサーバーを認識できるかどうかを確認します。この条件が当てはまる場合、サーバーはストレージデバイスが故障したという前提で稼働し続けます。このアクションはVMの安全性を損なうものではありませんが、ネットワークハートビートが失われるとフェンシングが発生します。それは両方のハートビートが消失したことを意味するからです。

障害に対するキャパシティプランニング

ハートビートシステムは、サーバー障害の信頼性の高い通知を提供するため、高可用性の第2ステップである障害に対するキャパシティプランニングに進みます。

リソースプールは複数のサーバー (例えば32台) で構成され、それぞれが異なる量のメモリと異なる数の実行中のVMを持つ可能性があります。XenServerの高可用性は、あらゆるサーバー障害で実行されるアクションを計算する障害計画を動的に計算します。この障害計画は、単一のサーバー障害によって、そのVMを別のサーバーで再起動することが不可能にならないようにします (例えば、他のサーバーのメモリ不足のため)。単一サーバーの障害に対処することに加えて、XenServerの高可用性は、プール内の複数のサーバーの損失に対処できます。例えば、ネットワークパーティションの障害によってサーバーのグループ全体が停止した場合でも、高可用性は対処できます。

実行されるアクションを計算することに加えて、障害計画は、プール内で許容できるサーバー障害の数を考慮します。プールの高可用性計画を計算する上で、2つの重要な考慮事項があります。

最大障害許容数。この値は、プール内のすべての保護されたVMを実行するためのリソースが不足するまでに障害が発生する可能性のあるサーバーの最大数です。最大障害許容数を計算するために、XenServerは以下を考慮します。
- プール内のVMの再起動の優先順位
- プール内のサーバーの数
- サーバーのCPUとメモリ容量
サーバー障害制限。この値は、計画内でプールで許可されるサーバー障害の数を指定する高可用性構成の一部として定義できます。例えば、プールのサーバー障害制限が3の場合、XenServerは、任意の3台のサーバーが障害を起こしても、すべての保護されたVMがプール内で稼働し続けられるフェイルオーバー計画を計算します。サーバー障害制限を最大障害許容数よりも低い値に構成することで、プールがオーバーコミット状態になる可能性を低くすることができます。この構成は、RBACが有効な環境で役立ちます。例えば、この設定により、プールオペレーターよりも低い権限を持つRBACユーザーは、高可用性計画を破ることなく、より多くのVMをオンラインにすることができます。詳細については、「高可用性とロールベースのアクセス制御 (RBAC)」セクションを参照してください。

最大障害許容数の値が、サーバー障害制限で指定された値を下回った場合、システムアラートが生成されます。

オーバーコミット保護

プールで高可用性が最初に有効にされたとき、その時点で利用可能なリソースに基づいて障害計画が計算されます。XenServerの高可用性は、例えば新しいVMの起動など、プールに影響を与える可能性のあるイベントに応じて、新しい障害計画を動的に計算します。プール全体でリソースが不足しているために新しい計画を計算できない場合、プールはオーバーコミット状態になります。リソース不足の例としては、十分な空きメモリがないこと、または、どのVMがどのサーバーで再起動されるかに影響する仮想ディスクやネットワークの変更などが挙げられます。

高可用性再起動優先度は、プールがオーバーコミットされたときにどのVMを起動するかを決定するために使用されます。HA構成ダイアログボックスまたはHA構成ウィザードで保護したいVMの再起動優先度を構成すると、プールの最大障害許容数が動的に再計算されます。この情報により、ビジネスニーズに応じてVMの再起動優先度のさまざまな組み合わせを試すことができます。プール内の重要なVMに必要な保護レベルに対して、最大障害許容数が適切であるかどうかを確認できます。

VMを起動または再開しようとして、そのアクションによってプールがオーバーコミットされる場合、XenCenterに警告が表示されます。設定されている場合、メッセージは電子メールアドレスにも送信できます。操作をキャンセルするか、続行してプールをオーバーコミット状態にするかを選択できます。

HAが有効なプールでの作業

高可用性のベストプラクティスは、高可用性が有効になっている間はプールの構成変更を行わないことです。代わりに、これは「午前2時のセーフガード」として意図されており、管理者が近くにいない場合に問題が発生したときにサーバーを再起動します。ソフトウェアアップデートの適用など、プールで積極的に構成変更を行っている場合は、これらの変更中に高可用性を無効にしてください。

XenCenterから保護されたVMをシャットダウンしようとすると、XenCenterはVMを障害計画から削除してからシャットダウンするオプションを提供します。このオプションにより、偶発的なVMシャットダウンがダウンタイムを引き起こすことはありませんが、必要であれば保護されたVMを停止することができます。
高可用性が有効になっているときにサーバーを再起動する必要がある場合、XenCenterはVMの再起動優先度を自動的に使用して、この再起動がプールの障害計画を無効にするかどうかを判断します。計画に影響しない場合、サーバーは正常にシャットダウンされます。計画が違反されるが、最大障害許容数が1より大きい場合、XenCenterはプールのサーバー障害制限を1つ下げるオプションを提供します。このアクションはプールの全体的な回復力を低下させますが、常に少なくとも1つのサーバー障害が許容されることを保証します。サーバーが復帰すると、計画は自動的に再計算され、適切な場合は元のサーバー障害制限が復元されます。
アップデートのインストールウィザードを使用してソフトウェアアップデートをインストールする場合、HAをオフにするを選択してプールの高可用性を無効にする必要があります。アップデートのインストール後に高可用性を再度有効にできます。高可用性を無効にしない場合、アップデートは進行しません。アップデートのインストール中は、サーバー障害がプールの操作を妨げないように、プールを手動で監視してください。
高可用性が有効になっている場合、VMの再起動計画を危険にさらす可能性のある一部の操作（プールからのサーバーの削除など）は無効になることがあります。これらの操作を実行するには、一時的に高可用性を無効にするか、続行する前に保護されたVMをシャットダウンすることができます。

高可用性とロールベースのアクセス制御 (RBAC)

ロールベースのアクセス制御 (RBAC) が実装されているXenServer環境では、すべてのユーザーがプールの高可用性構成設定を変更できるわけではありません。たとえば、VMオペレーターは、HAが有効なプールのフェイルオーバー容量を調整するのに十分な権限を持っていません。VMを起動すると、許可されるサーバー障害の最大数が現在の値よりも低い値に減少する場合、VMオペレーターはVMを起動できません。許可されるサーバー障害の数を構成できるのは、プール管理者またはプールオペレーターレベルのユーザーのみです。

この場合、プール管理者またはプールオペレーターは、サーバー障害制限を許可される最大障害数よりも低い値に設定できます。この設定により、余裕のある容量が作成され、権限の低いユーザーが新しいVMを起動できるようになります。これにより、障害計画を脅かすことなく、プールのフェイルオーバー容量が削減されます。