XenCenter

高可用性

XenServerの高可用性により、リソースプール内のハードウェアや個々のサーバーに障害が発生した場合に、仮想マシンが自動的に再起動します。高可用性は、重要な仮想マシンがリソースプール内で常に動作することを保証するためのものです。高可用性を有効にすると、サーバーの1つに障害が発生した場合、その仮想マシンは同じリソースプール内の別のサーバーで再起動します。この機能により、システムやコンポーネントの障害発生時に、サービスの中断を最小限に抑えながら重要なサービスを復元できます。

プールコーディネーターサーバーに障害が発生すると、XenServerの高可用性で別のサーバーがプールコーディネーターとして動作を開始するよう自動的に選択されます。リソースプール内の任意のサーバーをプールコーディネーターサーバーにできます。XenServerにより、プールのデータベースは常にすべてのノード間で複製されます。また、安全性を高めるため、データベースがハートビートストレージリポジトリ上の共有ストレージにバックアップされます。

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

  • サーバー障害の正確な検出
  • 迅速な回復を可能にするフェイルオーバープランの計算

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

サーバーの障害を確実に検出することは、サーバーの一時的な消失と壊滅的な障害とをリモートから区別しなければならないため、非常に困難です。高可用性でプールコーディネーターサーバーの障害を誤って検出して新しいプールコーディネーターを選択してしまうと、元のサーバーが復帰したときに予期できない問題が発生する可能性があります。また、ネットワークの問題によりプールが2つに分割された場合に、どちらか一方だけが共有ストレージにアクセスするようにして、両方が同時にアクセスしないようにする必要があります。これらの問題を解決するために、XenServerにはストレージハートビートとネットワークハートビートの2つのメカニズムが組み込まれています。

リソースプールの高可用性を有効にするときに、iSCSI、ファイバチャネル、またはNFSのストレージリポジトリをハートビートストレージリポジトリとして指定します。このストレージリポジトリ上には、いくつかの小さな仮想ディスクが作成されます。これらの仮想ディスクの最初のディスクは、リソースプール内のすべてのサーバーにより、共有クォーラムディスクとして使用されます。各サーバーは、この共有ディスク内の固有のブロックに割り当てられて、そこに定期的に書き込みを行います。これにより、そのサーバーが動作中であることが確認されます。高可用性が開始されると、すべてのサーバーがネットワークチャネルおよびストレージチャネルを使ってデータを交換します。このアクションにより、各サーバーが相互に両方のチャネルでアクセス可能であることが確認されます。この通信に問題が検出される場合は、どの入出力パスが動作していないかが示されます。このデータ交換は特定の時間が経過して、プール内のすべてのサーバーで相互通信に問題がないことが確認されるまで継続されます。この確認が行われると、高可用性が有効になり、プールが保護されます。この準備処理は、大規模なリソースプールで数分かかることがありますが、高可用性を最初に有効にするときにのみ実行されます。

高可用性が有効になると、各サーバーは定期的にストレージ更新情報をハートビート仮想ディスクに書き込み、管理インターフェイスにネットワークパケットを送信します。耐障害性を向上させるため、ネットワークアダプタをボンディングし、ストレージインターフェイスで動的マルチパスを使用してください。この構成により、単一アダプタの障害や書き込みの失敗が結果として可用性の問題になることを避けることができます。

詳しくは、次のトピックを参照してください:

サーバーの隔離

高可用性にとって最悪のシナリオは、オフラインとして認識されたサーバーが共有ストレージへの書き込みを続けることです。これにより、永続的なデータが破損することがあります。これを避けるため、XenServerはそのサーバーを隔離します。そのサーバーは自動的にシャットダウンし、プール内のすべての共有リソースへのアクセスが停止します。フェンスは、障害が発生したサーバーが共有ディスクに書き込みを行うことを防ぎます。この動作により、保護された仮想マシンをプール内のほかのサーバー上に移行している間に、自動フェイルオーバー中に保存されたデータが破損するのを防ぐことができます。

ハートビートの問題が検出されると、サーバーが自己隔離(つまりシャットダウン後に再起動)されます。ただし、以下のいずれかが当てはまる場合、サーバーは隔離されません:

  • すべてのサーバーでストレージハートビートは正しく動作していますが、ネットワークが分割された場合(つまりプール内に2つのサーバーグループが存在する)。この場合、規模が小さい方のグループのサーバーだけが隔離され、大きい方のグループのサーバーは継続して動作します。これは、ネットワーク障害により仮想マシンが到達不能になったという想定の下で、ネットワークが機能しているサーバー上でその仮想マシンが再起動されるようにするためです。分割されたサーバーグループの規模が同じ場合は、いずれか一方のグループだけが自己隔離されます。
  • ストレージハートビートに問題が生じ、ネットワークハートビートに問題がない場合。この場合、各サーバーがネットワーク経由でほかのすべてのサーバーにアクセスできるかどうかを確認します。この状況が続く場合、ストレージハートビートサーバーがオフラインになったという想定の下で、各サーバーは動作を続けます。このアクションにより仮想マシンの安全性が損なわれることはありませんが、ネットワーク障害の場合は両方のハートビートが消失するため、サーバーの隔離が発生します。

リソースプールの能力の評価

ハートビートによる信頼性の高いサーバー障害検出の次は、リソースプールの能力評価について説明します。

搭載されているメモリの量や実行中の仮想マシンの数が異なる複数のサーバーで構成されるリソースプールで、XenServerの高可用性は、サーバー障害に対して実行されるアクションを計算する障害プランを動的に計算します。この障害プランにより、1台のサーバーで障害が発生した場合に、(たとえば、他のサーバーでのメモリ不足などが原因で)別のサーバーでその仮想マシンを再起動できなくなるという事態を回避できます。この機能では、単一サーバーの障害だけでなく、プールの複数のサーバーが到達不能になった場合もXenServerの高可用性で対処できます。たとえば、ネットワークパーティションの障害によってサーバーのグループ全体に影響が及んだ場合でも、高可用性によって対応できます。

フェイルオーバープランでは、障害発生時に実行すべきアクションの決定に加えて、プール内でフェイルオーバーできるサーバー障害数が考慮されます。フェイルオーバープランの計算には、以下の2つの項目が考慮されます:

  • 最大許容障害数。この値は、保護対象のすべての仮想マシンに必要なリソースを維持したまま許容される最大サーバー障害数です。最大許容障害数を計算するために、XenServerは以下のことを考慮します:

    • プール内の仮想マシンの再起動優先度
    • プール内のサーバーの数
    • サーバーのCPUとメモリ容量
  • サーバー障害の制限。この値は、そのプラン内のプールで許可するサーバー障害数であり、高可用性の設定時に管理者が設定します。たとえば、プールに対して許可するサーバー障害の数として3を設定すると、そのプール内の任意の3台のサーバー障害までは保護され、そのサーバー上の仮想マシンをほかのサーバー上で再起動するというフェイルオーバープランがXenServerで計算されます。管理者は、そのプールで許可するサーバー障害数として、算出される最大許容障害数よりも小さい値を設定します。これにより、プールがオーバーコミット状態になることを回避できます。役割ベースのアクセス制御(RBAC)が有効な環境では、サーバー障害の制限の設定により、特定の管理者が起動できる仮想マシンの数を制御できます。これにより、プールオペレータとしての権限を持たない管理者でも、フェイルオーバープランに影響しない範囲で仮想マシンを起動できるようになります。詳しくは、「高可用性と役割ベースのアクセス制御(RBAC)」セクションを参照してください。

最大許容障害数が、管理者により設定されたサーバー障害の制限よりも小さくなると、システムアラートが生成されます。

オーバーコミット保護

プールの高可用性を有効にすると、その時のリソースに基づいてフェイルオーバープランが計算されます。新しい仮想マシンの起動など、プールに変化が生じると、新しいフェイルオーバープランが動的に計算されます。プール全体のリソース不足のために新しいプランを計算できない場合、そのプールはオーバーコミット状態になります。リソース不足の場合とは、たとえば空きメモリ領域が足りない場合や、どの仮想マシンをどのサーバーで再起動するかに影響する仮想ディスクとネットワークの変更が生じた場合などです。

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

仮想マシンを起動または一時停止しようとしたときに、その操作によりプールがオーバーコミット状態になる場合は、XenCenterに警告が表示されます。この警告メッセージがメールで送信されるように設定することもできます。このとき、仮想マシンの起動や再開をキャンセルしたり、続行したりできます。操作を続行すると、プールがオーバーコミット状態になります。

高可用性が有効なプールの管理

高可用性が有効になっている場合、プールの構成を変更しないのがベストプラクティスです。Citrix Hypervisorの高可用性機能は「午前2時の保護手段」であり、管理者の勤務時間外の障害に対処して仮想マシンを再起動するためのものです。ソフトウェアアップデートの適用など、プール構成に変更を加える場合は、次善に高可用性を無効にします。

  • 保護された仮想マシンをXenCenterからシャットダウンしようとすると、その仮想マシンをフェイルオーバープランから削除してからシャットダウンするためのオプションがXenCenterで表示されます。このオプションにより、保護された仮想マシンを誤ってシャットダウンしてしまうことが避けられると同時に、必要な場合はプールの高可用性を無効にしなくても仮想マシンをシャットダウンできます。
  • 高可用性が有効なプールのサーバーをXenCenterから再起動しようとすると、各仮想マシンの再起動優先度が考慮されて、この再起動によってフェイルオーバープランが影響を受けるかどうかが決定されます。フェイルオーバープランが影響を受けない場合、サーバーが通常どおりシャットダウンします。フェイルオーバープランが影響を受けても、最大許容障害数が1よりも大きい場合は、サーバー障害の制限を1つ減らすかどうかを確認するメッセージがXenCenterで表示されます。サーバー障害の制限を減らすとプールの全体的な耐障害性が低下しますが、少なくとも1台のサーバーの障害がフェイルオーバーされます。サーバーの再起動が完了すると、フェイルオーバープランが自動的に再計算され、サーバー障害の制限が元の値に戻ります。
  • アップデートのインストールウィザードを使用してソフトウェア更新プログラムをインストールする場合、[高可用性の無効化] を選択して、プールで高可用性を無効にする必要があります。アップデートのインストール後に、高可用性を再度有効にできます。高可用性を無効にしないと、アップデートは停止します。アップデートをインストールしている間、プールでサーバー障害が発生していないかどうかを管理者自身が監視してください。
  • 高可用性を有効にすると、プールからサーバーを削除するなど、仮想マシンのフェイルオーバープランを変更するような操作が無効になる場合があります。このような操作を実行するには、一時的に高可用性を無効にするか、保護された仮想マシンをシャットダウンします。

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

役割ベースのアクセス制御(RBAC)が実装されたXenServer環境では、一部の管理者ユーザーはプールの高可用性設定を変更できません。たとえば、VMオペレータは、高可用性の許容障害数に影響するような操作を実行できません。このため、このような管理者は、サーバーの最大許容障害数を現在の値よりも小さな値に減少させるような仮想マシンの起動を行うことはできません。許可するサーバー障害の制限値を変更できるのは、プール管理者とプールオペレータレベルの管理者のみです。

プール管理者またはプールオペレータは、許可するサーバー障害の制限を(XenCenterにより算出された)最大許容障害数よりも少なく設定できます。これにより、低い権限を持つ管理者も新しい仮想マシンを起動できるようになります。フェイルオーバープランに影響はありません。

高可用性