高可用性
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とメモリ容量
-
-
Server failure limit. You can define this value as part of the high availability configuration which specifies the number of server failures to allow in the pool, within the plan. For example, when the server failure limit for a pool is 3, XenServer calculates a failover plan that allows any 3 servers to fail and all protected VMs can still run in the pool. You can configure the server failure limit to a value that is lower than the maximum failure capacity, making it less likely that the pool becomes overcommitted. This configuration can be useful in an environment with RBAC enabled. For example, this setting allows RBAC users with lower permissions than Pool Operator to bring more VMs online without breaking the high availability plan. For more information, see the High availability and Role-Based Access Control (RBAC) section.
最大障害許容数の値がサーバー障害制限に指定された値を下回ると、システムアラートが生成されます。
オーバーコミット保護
プールで高可用性が最初に有効にされたとき、その時点で利用可能なリソースに基づいて障害計画が計算されます。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を起動できるようになります。これにより、障害計画を脅かすことなく、プールのフェイルオーバー容量が削減されます。