XenServer® エンタープライズ リファレンス アーキテクチャ

概要

このリファレンスアーキテクチャは、エンタープライズ規模のワークロードをサポートするためにXenServerを設計、展開、運用するための推奨アプローチを定義します。これは、Citrix Virtual Apps and Desktops™ (CVAD) 環境のホスティング、および一般的なサーバー仮想化のための検証済み基盤を提供し、スケーラビリティ、回復性、運用上のシンプルさに焦点を当てています。

このアーキテクチャは、XenServerリソースプールをスケールと管理のコア単位とする概念に基づいて構築されています。各リソースプールは、単一のデータセンター（または密接に接続されたデータセンターのセット）内で動作するように設計されており、予測可能で高性能なワークロード実行をサポートします。展開は、追加のリソースプールを追加することで水平方向に拡張でき、増大する容量と組織の要件に対応できます。

設計原則

以下の原則は、設計アプローチを要約したものです。

• スケール単位としてのリソースプール: 明確に定義されたリソースプール内でワークロードを展開および管理し、追加のプールを追加することで水平方向に拡張する
• 設計によるワークロード分離: 特定のワークロードタイプにリソースプールを合わせて、一貫したパフォーマンスと運用動作を確保する
• N+1キャパシティモデル: 単一ホストの障害が発生してもワークロードの可用性に影響を与えない十分なキャパシティを維持する
• 関心の分離: 管理、VM、ストレージのトラフィックを明確に分離し、パフォーマンス、回復性、セキュリティを確保する
• 明示的な回復性戦略: データセンター内の回復性とデータセンター間の災害復旧を、別個のアーキテクチャ上の懸念事項として扱う
• 運用上のシンプルさ: 明確な価値を提供する場合にのみオプション機能を導入し、不必要な複雑さを避ける

これらの原則は、スケーラブルで回復力があり、運用が簡単でありながら、進化するワークロードと組織の要件に適応できるXenServer環境を設計するための一貫したフレームワークを提供します。

このアーキテクチャは、リモートブロックストレージの使用、Active Directoryを介した統合ID管理、およびTLSを介したセキュアな管理を前提としています。ワークロードバランシング (WLB)、高可用性 (HA)、災害復旧 (DR) などのオプション機能は、ワークロード要件に基づいて組み込むことができますが、それぞれ追加の運用上の考慮事項を伴い、明示的に計画する必要があります。 このリファレンスアーキテクチャは、予測可能なパフォーマンスと強力な運用制御を必要とするエンタープライズ環境を対象としています。非常に大きな個々のVMディスク (>2 TB) やGPU集約型ワークロードなどの特殊なシナリオには最適化されておらず、代替設計や適応が必要になる場合があります。

全体として、このドキュメントは設計ガイドと運用フレームワークの両方として機能し、組織がXenServerを一貫性のあるサポート可能な方法で展開しながら、時間の経過とともにプラットフォームを拡張および進化させる柔軟性を維持できるようにします。

前提条件と範囲

このアーキテクチャは、規模、インフラストラクチャ、および運用プラクティスに関する一連の基本的な前提に基づいています。

• 使用されるすべてのハードウェアは、XenServerのハードウェア互換性リスト (HCL)に記載されている必要があります。

• 各リソースプールは最大1,000台の仮想マシンをサポートすることが想定されており、全体的なデプロイメントは、単一のプールを無期限に拡張するのではなく、追加のプールを追加することでスケールし、最大200プールまでとなります。プール内のすべてのホストは、密接に結合されたネットワーク境界内で動作し、共有ストレージへの一貫した信頼性の高いアクセスを保証すると想定されています。
  • ホストは、必要なワークロードとコントロール ドメインをサポートするのに十分なRAMと、パフォーマンス キャッシュ要件（リソースプールのサイジングを参照）を満たす必要があります。最大6 TBまでです。
  • ホストは、XenServer OS用のローカルストレージ（最小46 GB、理想的には70 GB）を持つか、SANから起動できる必要があります。
  • ホストはUEFIファームウェアを使用する必要があります。XenServer 9ではレガシーBIOSはサポートされていません。

• ストレージは、リモートのブロックベースシステムを介して提供されると想定されており、XenServerはLVMベースのストレージリポジトリを使用します。効率性と回復性は、主に基盤となるストレージプラットフォームによって提供され、これには使用時にアクティブな割り当てを可能にするシンプロビジョニングやマルチパスなどの機能が含まれます。継続的で信頼性の高いストレージ接続は、重要な要件です。

• ネットワークは、管理、仮想マシン、ストレージトラフィック間の厳密な分離モデルに従います。これを実現するために、ホストは最低でも2つのNICと2つのファイバーチャネル接続、または4つのNICを装備する必要があります。この分離は、ボンディングされたネットワークインターフェースと組み合わされて、回復性とスループットを提供し、不要な依存関係やパフォーマンスの制約を導入する構成を回避します。

• セキュリティとIDは設計に不可欠なものとして扱われます。管理通信はTLSを使用して保護され、認証とロールベースのアクセス制御にはActive Directoryとの統合が想定されています。管理アクセスは、ローカルアカウントの使用を制限し、管理インターフェースの公開を制御するなど、標準的なエンタープライズセキュリティプラクティスに従うことが期待されます。

• 運用上、リソースプールはN+1容量モデルを中心に設計されており、ホストのメンテナンス中や単一ホスト障害発生時でもワークロードが継続して実行できるようにします。サポート可能性とセキュリティを維持するために、更新とアップグレードは定期的に適用されることが期待されます。ディザスタリカバリが必要な場合は、シームレスまたは完全に自動化されたフェイルオーバー機能としてではなく、調整された運用プロセスとして実装されます。

オプション機能は必要に応じて組み込むことができますが、デフォルトでは想定されていません。これらには以下が含まれます。

• ワークロードバランシング (WLB)
• ワークロードのハイアベイラビリティ (HA)
• データセンター間のディザスタリカバリ (DR)

それぞれが運用上の複雑さを増し、明確なワークロードとビジネス要件に基づいて採用されるべきです。

範囲外

このリファレンスアーキテクチャは、すべてのシナリオ向けに設計されているわけではなく、普遍的なソリューションとして扱われるべきではありません。特に、以下の点には直接対応していません。

• 2 TBを超える個別の仮想ディスクを必要とするワークロード
• GPUアクセラレーションまたはGPU依存のワークロード
• 地理的に分散したデータセンター間でシームレスなアクティブ/アクティブワークロードモビリティを必要とするアーキテクチャ

これらの場合でも、この設計の要素は適用可能である可能性がありますが、追加のアーキテクチャ上の考慮事項と適応が必要になります。

定義

このリファレンスアーキテクチャの読解と理解を助けるための用語と定義。

アーキテクチャの設計図

リソースプールに関する期待事項は以下のとおりです。

• 各リソースプールは、最大1000台の実行中のVMに対応するように設計されています。
• 各リソースプールは、単一のデータセンター内、または近接する複数のデータセンターに完全に配置されます。
• 各リソースプールは、可用性とパフォーマンスに関してすべてのワークロードが同様の特性を持つ、特定のユースケースに対応します。小規模な展開では、複数のユースケースを混在させることも可能ですが、リソースプールの負荷分散と障害モードを考慮する際には注意が必要です。

単一ユースケースの例は次のとおりです。

• CVAD展開用の仮想デスクトップ
• CVAD展開用のアプリケーションサーバー
• CVADインフラストラクチャ
• 一般的なサーバー仮想化ワークロード

各リソースプールには以下の属性があります

• すべてのリモートブロックストレージにLVMプロトコルを使用します。GFS2プロトコルの使用は推奨されません。
• プールコーディネーター管理のための高可用性
• すべての管理通信にTLS 1.2を使用
• オプション: ワークロードVMのワークロードバランシング (WLB)
• オプション: ワークロードVMの高可用性 (HA)
• オプション: ディザスタリカバリ (DR)
• オプション: XenServer Conversion Managerがインストールされていること

注:

この設計は、データセンター内またはデータセンター間で複数のリソースプールを作成することで拡張でき、必要な場所にワークロードを提供できます。

各リソースプールは、以下のセクションで定義されているように構築します。

コアリソースプールの構成

新しいリソースプールを構築する際、ベストプラクティスは、必要なネットワークおよびストレージ構成を持つスタンドアロンホストを構成し、その後、他のホストをこのプールに追加することです。追加されたホストは、リソースプールに追加されると構成を取得します。

ロールベースのアクセス制御を構成する

すべてのリソースプールを信頼されたActive Directoryドメインに接続し、ADユーザーとグループを簡単に管理および監査できるようにし、XenServerリソースプールへのアクセスと権限を制御します。

注:

AD資格情報（例：ADドメインコントローラーの障害）を介して認証できない緊急時を除き、管理にデフォルト（root）アカウントを使用しないでください。

ホストの証明書プロビジョニング

すべてのリソースプール内のすべてのホストは、管理ネットワークで使用するためのプロビジョニングされたTLS証明書を持つ必要があります。CVADワークロードの場合、ホストはDNSでFQDNによって解決可能である必要があります。

すべてのホストには証明書がプロビジョニングされている必要があります。これは共有ワイルドカード証明書でも、ホストごとの証明書でも構いません。

注:

XenServer APIを使用する一部のアプリケーション（Citrix Apps and Desktopsの古いバージョンなど）では、各ホストに個別の証明書を使用する必要があり、ワイルドカード証明書の使用は許可されていません。詳細については、関連ドキュメントを参照してください。

• DaaS
• CVAD 2507以降
• CVAD 2507以前

リソースプールへのサードパーティ接続は、TLSとFQDNを使用してリソースプール内のホストをアドレス指定する必要があります。

リソースプールへの通信の保護

• ポート80を無効にする
• 管理ツールスタックが失敗した場合にSSHが自動的に有効になるように、SSHを自動モードに設定します。

セキュアブートを有効にする

XenServer 9ホストは、ファームウェアでセキュアブートを有効にして実行するように構成できます。これにより、ブートプロセスの各段階で署名検証が強制され、ホストオペレーティングシステムが完全にロードされる前に、信頼されていない悪意のあるコードが実行されるリスクが軽減されます。

各ホストのファームウェア設定でセキュアブートを有効にします。XenServer 9のすべてのDom0カーネルモジュールは署名されているため、標準のホスト操作には影響しません。一部のホストでセキュアブートが有効になり、他のホストで無効になっている混合プールもサポートされています。

完全な構成手順については、「XenServer 9のセキュアブート」を参照してください。

リソースプールネットワーク構成

以下のネットワークには分離が必要です。

• 管理ネットワーク
• VMネットワーク
• ストレージネットワーク（ネットワークベースのストレージを使用する場合）

この分離は、個別のNICを使用するか、同じNICを使用してVLANを使用することで提供できます。ネットワークベースのストレージを使用する場合は、パフォーマンス上の理由から個別のNICを使用することを強くお勧めします。

管理ネットワークとVMネットワーク

管理ネットワークとVMネットワークは、冗長性とスループットを提供するために、ボンディングされたNICで運用する必要があります。

帯域幅の可用性を最大化しながら、接続損失に対する最適な応答を確保するために、可能な限りLACPボンディングとして構成する必要があります。これには、スイッチを一致する構成で設定する必要があります。スイッチがLACPをサポートするように構成できない場合、VMネットワークにはアクティブ/アクティブが有利です。管理ネットワークは、影響なくアクティブ/パッシブを使用できます。詳細については、「ボンディングの種類」を参照してください。

可能な限り、ネットワーク転送における単一障害点がないことを確実にするために、スイッチはNICにクロスリンクされるべきであり、それらは個別の電源または冗長な電源を使用すべきです。詳細については、ネットワークのベストプラクティスを参照してください。

プール内のすべてのホストは、管理ネットワーク上に固定IPアドレスを持つ必要があります。XenServerは、DHCPによって発行されたホストIPアドレスが変更されるシナリオをサポートしていません。固定DHCPアドレスを使用する場合、DHCP環境は信頼性高く利用可能であると想定されるべきであり（例：ネットワークインフラの一部として）、そのDHCPサーバーに依存するホスト上で実行されているVMによって提供されるべきではありません。インフラストラクチャには静的アドレス指定が推奨されます。

すべてのホスト管理ネットワークは、クロックが同期された状態を保つために、同期されたNTPサーバーへの接続を許可する必要があります。これは、ロールベースのアクセス制御のためにコンピューターおよびユーザーアカウントを提供するActive Directoryで使用されるものと同じ時刻ソースであるべきです。これにより、クロックドリフトが発生して通信パスが途絶えることがなくなります。また、これによりすべてのシステムログに一貫したタイムスタンプが確保されます。

環境の運用を可能にするために必要な完全な接続要件は、こちらに記載されています。

ストレージネットワーク

ネットワークベースのストレージを使用する場合のベストプラクティスは、ストレージからのマルチパスサポートを使用することです。これには独立したネットワーク（つまり、異なるサブネット）が必要です。これは通常、ボンディングではなく単一のNICを使用し、それぞれに適切なサブネットを設定することを意味します。詳細な推奨事項については、ストレージプロバイダーにお問い合わせください。

リソースプールストレージ構成

マルチパスは有効にする必要があります。これはすべてのホストで個別に設定する必要があり、すべてのストレージリソースに対して少なくとも2つのパスが利用可能であるべきです。これらのパスは、ネットワーク/ファイバーチャネルインフラストラクチャ全体で多様であるべきです。

LVMはシックプロビジョニングされたストレージであるため、XenServerは作成されたVMディスクに必要なストレージの全量を要求します。これは、それらのディスクのごく一部しか使用されていない場合でも、すべてのディスクとテンプレートが利用可能な全容量を占有することを意味します。

ストレージの効率的な使用を確実にするために、独自のシンプロビジョニング機能を提供するSANを使用することが推奨されます。SANのシンプロビジョニングは、VDIの仮想サイズ全体を事前に割り当てるのではなく、仮想ディスクにデータが書き込まれる際にVDIにディスクストレージスペースを割り当てることで、利用可能なストレージをより有効に活用します。使用されるストレージ量は、SANベンダーが提供するツールを使用して管理者が慎重に監視する必要があります。

SANでシンプロビジョニングを使用する場合、ストレージの使用状況を監視することが重要です。SANの容量が枯渇し、それ以上の書き込みができなくなると、VMの障害やデータ破損につながる可能性があります。

Citrix®環境のワークロードをプロビジョニングするためにMCSを使用する場合、ゴールデンイメージをすべてのLUNにコピーする必要があるため、少数の大きなLUNを使用することが推奨されます。これは時間がかかり、イメージプロビジョニングにかなりの時間を要し、更新されたイメージの展開を遅らせる可能性があります。

回復性戦略

XenServerリソースプールは、そのストレージリソースとともに、単一のデータセンター内（または近接するデータセンターの集合内）で運用されます。

これらのリソースプールは、データセンター内のローカルサーバー、ストレージ、およびネットワークの障害に対して回復性を持つように構成できます。さらに、データセンターが障害を起こし、リソースプール全体が失われた場合に備えて、リソースプールを組み合わせて災害復旧機能を提供することもできます。

これらについては、以下で個別に検討します。

データセンター内のレジリエンス

データセンター内のワークロードは、以下で説明するように完全なDR構成によって保護できますが、各リソースプール内には、リソースの高可用性を確保するためのレジリエンスメカニズムがあります。これらのメカニズムは、より一般的でローカライズされた問題から保護するために、自動化され、より頻繁に使用されるように設計されています。以下の機能が利用可能です。

• 管理の高可用性（計画外の停止時の自動コーディネーター選出による）
• ワークロードコンピューティングの高可用性（計画外の停止時の自動VM再起動による）
• ストレージのレジリエンス（ストレージマルチパスによる）
• ネットワークのレジリエンス（ネットワークボンディングとスイッチ構成による）

これを達成するには、リソースプールが最低N+1台のホストで動作することが期待されます。ここでNはワークロードを動作させるために必要なホストの数です。これにより、1台のホストが利用できない状態でも、リソースプールをフルキャパシティで動作させることができます。

注記：

N+1ホスト容量により、ワークロードの停止なしにリソースプールを更新およびアップグレードでき、セキュリティ更新プログラムや機能強化を簡単に適用できます。

これらの機能は、データセンター内または近接するデータセンター間で完全に運用される、回復力の高いデプロイメントを提供します。地理的に分散したデータセンター間での回復力はサポートしません。これをサポートする唯一の方法は、以下で説明するDR機能を使用することです（データセンター間のレジリエンスを参照）。

オプション機能

ワークロードバランシング (WLB)

• 使用する場合： VMワークロードの実行中に、利用パターンが大幅に異なり、時間とともに変化し、パフォーマンスを維持するために自動推奨や再バランシングが必要な場合。
• 避ける場合： ワークロードが非常に均一である（例えば、多くの類似した非永続VDI VMなど）場合で、初期配置と通常のライフサイクル操作で既に十分なバランスが取れている場合、または移行が運用上望ましくない場合。
• 運用上の影響: 運用および監視する追加のアプライアンスが追加され、WLB処理が利用できない日次メンテナンスウィンドウが含まれます。

WLBは、ワークロードの使用状況が時間とともに変化するにつれて、最適なホスト利用率とパフォーマンスを維持するために使用できます。

アプライアンスをリソースプールにインポートし、その接続には管理ネットワークを使用します。Workload Balancing (WLB) アプライアンスは、XenServerダウンロードページからダウンロードできます。

アプライアンスのデフォルトのサイジング（2 GB RAM、30 GBディスク、2 vCPU）を使用する必要があります。

ワークロードの適合性

WLBは、VMの実行期間中にワークロードの需要が動的に変化する場合にのみ必要とされます。WLBを使用する場合、VMが停止して再度起動されるたびに、現在のワークロードに対してすぐに最適に配置されるため、VMはホストの利用率が変化した場合にのみ移動が必要となります。ユースケースが、すべて同様のタスクを実行する多くの類似したVMを提供する場合、WLBを使用する価値はほとんどなく、初期のVM配置に依存してワークロードバランシングを提供できます。

データベースメンテナンスウィンドウの調整

WLBアプライアンスは毎日ルーチンメンテナンスを実行します。デフォルトでは、これはUTC 00:05に行われます。このプロセス中に最大30分間のWLB処理停止が発生するため、リソースプールのアクティビティが低いときに実行されるように構成する必要があります。これは通常の操作には影響せず、配置最適化の決定にのみ影響します。WLBはメンテナンスが完了するとすぐにアクションを完了します。

WLBパラメーター構成

多くの構成設定はデフォルトのままにできます。これにより、WLB機能は管理者に推奨事項を提示するように設定され、管理者はこれらのアクションを適用する必要があります。

このブループリントのデフォルトおよび推奨される構成では、リソースプールが最高のパフォーマンスで動作できるように、「クリティカルしきい値」と重みを調整するだけで済みます。これらは使用を通じて最適化できますが、いくつかの推奨される初期値は次のとおりです。

• CPU使用率: これのデフォルトは、最大重み付けで90%のクリティカルしきい値です。これにより、ホストCPUが過去1.5分間で平均90%の負荷に達すると、WLBサービスはVMを実行するための代替場所を評価します。

  • VMのパフォーマンスが低いCPU使用率で影響を受けている場合、可能な限りホスト全体の平均CPU使用率を低い値に保つことを目的として、このクリティカルしきい値を調整できます。
  • 推奨される初期クリティカルしきい値: 90%
  • 推奨される初期メトリック重み付け値: 最重要
• 空きメモリ: ホストに空きメモリを保持することによって得られる特定のパフォーマンスはありません。そのため、メモリを空けるためにマシンを移行することは不要なオーバーヘッドです。
  • 推奨される初期のクリティカルしきい値: 0
  • 推奨される初期メトリック重み付け値: 最も重要度が低い
• ネットワークの読み取りと書き込み: これらのデフォルト値は25 MB/秒です。これは、いずれかのホストが読み取りまたは書き込みにより多くの帯域幅を使用している場合、再配置の対象となることを意味します。このパラメータは、重いネットワークワークロードを実行しているVMがあり、他のVMへの影響を回避することが重要である場合にのみ関連します。
  • 多くのアプリケーションにとって、これは関連する要因ではなく、重み付けは最も重要度の低い設定にすべきです。
  • 多くの最新のネットワークにとって、これは非常に低い値であり、この設定が関連する場合は、別のホストへの移行を検討する前に、この帯域幅を有効に活用できるように設定することをお勧めします。
  • 推奨される初期のクリティカルしきい値: 利用可能な帯域幅の90%
  • 推奨される初期メトリック重み付け値: 中程度の重要度
• ディスクの読み取りと書き込み: これらのデフォルト値は25 MB/秒です。これは、いずれかのホストが読み取りまたは書き込みにより多くの帯域幅を使用している場合、再配置の対象となることを意味します。このパラメータは、重いディスクワークロードを実行しているVMがあり、他のVMへの影響を回避することが重要である場合にのみ関連します。リモートストレージが使用されている場合、ファブリックの帯域幅がボトルネックでない限り、これは価値がありません。なぜなら、リモートストレージへの影響は、それが動作しているホストに関係なく、そのストレージを使用するすべてのVMのパフォーマンスに影響を与えるからです。
  • ほとんどの最新のストレージとファブリックにとって、これは低い値であり、この設定が関連する場合は、帯域幅を有効に活用できるように、より高い値に設定する必要があります。これは、不要なときにVMの営業時間外の定期メンテナンスによって大量の移行が発生しないように、十分に高く設定する必要があります。
  • 推奨される初期のクリティカルしきい値: 利用可能な帯域幅の90%
  • 推奨される初期メトリック重み付け値: 中程度の重要度

リソースプールにおける高可用性 (HA)

HAの完全なドキュメントはこちらで入手できます。

XenServerの高可用性に関して考慮すべき要素が2つあります。

• 管理HA：リソースプール内のコーディネーターホストで予期せぬ障害が発生した場合に、管理操作を自動的に維持する機能
• VM HA：リソースプール内のホストで予期せぬ障害が発生した場合に、ワークロード操作を維持する機能

これらの両方の側面には、特定のストレージおよびネットワーク構成が必要です。これについては、以下のセクションで説明します。

利用可能なストレージLUNの1つがXenServerハートビートSRとして選択されます（この要件の詳細については、可用性のためのハートビートを参照してください）。複数のLUNが利用可能な場合、どれが選択されても問題ありません。HA機能を提供するために、このLUNから少量のスペース（5 GB未満）が割り当てられます。

このリファレンスアーキテクチャは、単一ホストの予期せぬ損失の範囲内でワークロードの維持をサポートするように設計されています。「許容する障害数」の設定は1に設定する必要があります。

注:

HAを使用する際には、以下の特性に注意することが重要です

• リソースプールには少なくとも3つのホストが必要です
• フェンシングとは、障害が発生した、または安全でないと見なされるホストを強制的に隔離し、仮想マシンが別の場所で再起動される前に共有リソース（特に共有ストレージ）にアクセスできないようにするメカニズムを指します。リソースプールが大きいほど、ホストフェンシングの影響は大きくなり、通信経路の要件により発生する可能性が高くなります。この点に関して、>16 ホストのプールについては慎重な検討が必要です。
• これらのメンテナンス活動が実施されている間、予期せぬ停止のリスクを軽減するために、ホスト/リソースプールのメンテナンス操作中はHAを無効にする必要があります。
• HAを使用する場合、HAステートファイルSRへのストレージ接続とネットワークが中断されないように注意する必要があります。これらの接続の中断は、リソースプールの操作を保護するためにホストが予期せずフェンスする原因となる可能性があります。これは、接続が失われないようにインフラストラクチャのメンテナンスを行う際には、慎重な検討が必要であることを意味します。

管理HAの代替アプローチ

信頼性の高い、高可用性の管理接続を提供するためにHAを使用している場合は、上記の制限を回避するために、以下の方法も検討する必要があります。

ホスト監視の実装

XenServerホストをサードパーティの監視ソリューションと統合し、ホストが応答しないときに検出します。

管理接続を手動で復旧する

連絡不能なホストがコーディネーターであり、管理操作が利用できない場合、リソースプール内の他のすべてのホストは緊急モードに入り、それらへのリモート接続を確立して、そのうちの1つを新しいプールコーディネーターとして選出できるようにします。これは、リモート言語バインディングを使用して実行できます。以下の例は、xe CLIとPowerShellについて示されています。

xe CLI:

xe -s <server_IP> -u <username> -pw <password> host-is-in-emergency-mode                     -> Confirm election possibility
xe -s <server_IP> -u <username> -pw <password> pool-emergency-transition-to-master           -> Designate current host as new master
xe -s <server_IP> -u <username> -pw <password> pool-recover-slaves                           -> Reconfigure member servers to new coordinator

<!--NeedCopy-->

PowerShell:

Invoke-XenPool -XenAction EmergencyTransitionToMaster          -> Designate current host as new master
Invoke-XenPool -XenAction RecoverSlaves                        -> Reconfigure member servers to new coordinator

<!--NeedCopy-->

VM 高可用性

ワークロードバランシング (WLB) VM

このVMは、予期せぬ停止後にWLB機能が失われないように、再起動優先度を「再起動」に設定する必要があります。最初の起動グループ0に属している必要があります。

その他のVM

XenServerの正確な使用方法に応じて、追加のVMがVM HAを使用するように構成される場合があります。以下に、いくつかのユースケースの提案を示します。

意思決定ガイド (VM HA): 予期せぬホスト停止後の自動再起動がサービス継続性を大幅に向上させ、プールが停止を吸収するためにN+1でサイジングされているワークロードにはVM HAを使用します。外部のブローカー/オーケストレーションがすでに再起動またはスケールアウトの動作を提供しているワークロード (たとえば、多くの非永続的なCVADワークロード) や、再起動の順序と依存関係の制御が難しいワークロードにはVM HAの使用を避けてください。

注:

HAが構成された後にリソースプールに追加されたVMは、デフォルトで「再起動しない」になります。必要に応じて、VMが環境に追加された後にHAを再構成する必要があります。

• PVSおよび非永続MCS VM: これらのVMにはHAを構成しないでください。これらがDo Not Restartに設定されていることを確認してください。他のVMはエンドユーザーに即座のサービスを提供できる必要があり、Citrix Virtual Apps and Desktopsは、エンドユーザーが必要とする場合、または予想される需要をサポートするための自動スケール機能を通じて、これらのVMの再起動をサポートする電源管理機能を提供します。AutoScaleを参照してください。これにより、統合されたCitrix環境にとってより最適化された結果が得られます。

• MCS永続VM: これらは「再起動」に設定する必要があります。設計されている構成は、1つのホストがサービス停止中 (更新、メンテナンス、または停止のため) の場合でも、プール内のすべてのVMを動作させるのに十分なRAMとCPUが利用可能であることを保証する必要があり、これによりこの構成が可能になります。

• 一般的なサーバー仮想化ワークロード (Citrix VDAの実行に使用されていないワークロード): これらは「再起動」に設定する必要があります。設計されている構成は、1つのホストがサービス停止中 (更新、メンテナンス、または停止のため) の場合でも、プール内のすべてのVMを動作させるのに十分なRAMとCPUが利用可能であることを保証する必要があり、これによりこの構成が可能になります。VMは、ワークロードが必要に応じて再起動するように、必要に応じて起動グループと遅延を使用するように構成できます。これは、Active Directory、DHCP、DNSサービスプロバイダーなど、他のサービスが依存するワークロードの優先順位付けに使用できます。

データセンター間の回復性

オプション:

データセンター間のディザスターリカバリー (DR)。このリファレンスアーキテクチャは、必要に応じてDRをサポートできますが、追加の設計および運用上の考慮事項が必要です。

DRに関する意思決定ガイダンス

• 使用する場合: サイトの回復性に関する明確なビジネス要件、レプリケーション可能なストレージプラットフォーム、およびセカンダリサイトでのVMリカバリを必要とする合意済みのリカバリ手順 (RPO/RTO) がある場合。
• 避けるべき場合: サイト間で頻繁なワークロードモビリティが必要な場合、またはフェイルオーバー/フェイルバックプロセスをテストおよび実行するための運用能力がない場合。CVADの場合、調整されたCVAD DR設計なしに、ハイパーバイザーの接続と証明書がシームレスにフェイルオーバーすると仮定しないでください。
• 運用上の影響: DRは完全に自動化されていません。フェイルオーバー/フェイルバックには、計画されたランブック、ストレージレプリケーション制御へのアクセス、および定期的なテストが必要です。

ここで説明するXenServerのディザスターリカバリー (DR) 構成は、インフラストラクチャの極端な予期せぬ停止をサポートするために、めったに使用されない操作として想定される回復性のモードです。この操作は自動化されておらず、リカバリには慎重な計画と運用が必要です。DRモデルは、最適な配置ではないかもしれない一時的な場所でのワークロードの運用を可能にしますが、停止期間中の重要なビジネス運用をサポートします。

XenServer DRモデルは複雑なソリューションであり、サイト障害から保護するための他の方法もあります。たとえば、非永続VMを使用してサービスを提供するCitrixワークロードの場合、一時的なサービスを提供するために、追加のVMをリカバリサイトにプロビジョニングできます。これらのオプションは、実装が容易である可能性があるため、XenServer DR機能を使用する前に検討する必要があります。

CVADに適したDRソリューションがない限り、Citrix VDIワークロードにDRを使用することは避けることをお勧めします。ネットワークと証明書のマッピングにより信頼性が低下する可能性があるため、同じハイパーバイザー接続がXenServer DRサイトにフェイルオーバーできると仮定するのは安全ではありません。

データセンター障害とワークロード (またはワークロードの重要な部分) の損失のリスクを軽減するために、セカンダリデータセンターの場所をディザスターリカバリー機能の提供に使用できます。詳細なドキュメントはこちらで入手できます。

DRサイトの1つ以上のリソースプールは、ワークロードのリカバリ場所であることに加えて、他のワークロードにも使用できますが、必要に応じて追加のワークロードを実行できるように、必要な予備容量を維持する必要があります。

障害発生時にDRサイトでワークロード全体を運用する必要はありません。プライマリサイトで完全な運用が復元されるまで、部分的なワークロードをリカバリできますが、ワークロードは1つのリソースプールから単一のリカバリリソースプールにリカバリする必要があるという要件があります。ワークロードを複数のリカバリプールに分散することはできません。

重要:

プライマリサイトのLUNからDRサイトにデータをミラーリングするストレージレプリケーションプロセスは、XenServerツールセットの外部で構成する必要があり、この再構成は、フェイルオーバーを担当する管理者が利用できるようにする必要があります。これは、このプロセスに関連する操作の一部としてミラーリングを解除およびリセットする必要があるためです (詳細については、操作セクションを参照してください)。

このデプロイメントを構築する際：

• VM仮想ディスクに使用されるすべてのストレージは、プライマリ環境からバックアップ環境にレプリケートされる必要があります
• プールメタデータに使用されるすべてのストレージは、プライマリ環境からバックアップ環境にレプリケートされる必要があります
• DRサイトのハードウェアインフラストラクチャは、プライマリサイトと一致する必要はありませんが、同じプロセッサベンダーを使用する必要があります。必要なすべてのフェイルオーバーVMを再作成して起動できるように、十分なメモリ、CPU、およびネットワーク容量をスタンバイリソースプールに構成する必要があります。
• リカバリサイトのXenServerリソースプールは、プライマリサイトと同じリリースおよびパッチレベルであるか、それよりも新しい必要があります（これを実現する方法の詳細については、XenServer version management across deploymentsを参照してください）。

運用モデル

デプロイメント全体でのXenServerバージョン管理

XenServerデプロイメントは、1つ以上のリソースプールと1つ以上のデータセンターから構築され、大規模な高性能ワークロードを提供できる、スケーラブルで堅牢かつ安全なデプロイメントを提供します。

これらのデプロイメントは、テスト環境と本番環境を提供でき、これらの環境を通じて変更を展開するためのワークフローを構築できます。

オプション：

ホストテストフェーズとワークロードテストフェーズはオプションです。リファレンスアーキテクチャは、これらのフェーズの有無にかかわらず運用をサポートします。

ホストテストとワークロードテストの段階は、別々の段階である必要はなく、組み合わせることができます。これにより、変更が本番環境に到達するまでの時間を短縮できるため、有利です。XenServerの更新ストリームは堅牢で完全にテストされており、継続的なデプロイメントを可能にします。セキュリティ、堅牢性、およびパフォーマンスを維持するためには、更新が本番環境に到達するまでの時間を最小限に抑えることが重要です。

各フェーズの期待事項は次のとおりです。

• 早期リリーステスト： このフェーズは、更新の早期可視化と機能の検証を目的としています。このフェーズのホストは、通常チャネルよりも2週間早く新しいバージョンへのアクセスを提供する早期リリースチャネルを使用するように構成されています。このフェーズのホストは、XenServerコンテンツ配信ネットワーク（CDN）にアクセスするために、インターネットへのアウトバウンド接続（直接またはプロキシサーバー経由）が必要です。
• ホストテスト: このフェーズの目的は、XenServerソフトウェアリリース更新プロセスをテストすることです。リリースは、XenServer CDNからインターネット経由で、またはオフラインチャネル配信メカニズムを通じて入手できます。
• ワークロードテスト/UAT: このフェーズでは、XenServerホストを本番環境に近いワークロードでテストし、スケールと回復力を検証できます。リリースは、XenServer CDNからインターネット経由で、またはオフラインチャネル配信メカニズムを通じて入手できます。
• 本番環境への展開: 本番ワークロードを実行しているホストは、以前のテストフェーズの後（直接またはオフライン配信メカニズムを通じて）更新できます。

注:

オフライン更新を使用すると、XenServerの予期されるバージョンがUATおよび本番環境に展開されていることを確認できます。別のリソースプールから直接更新を同期することは可能ですが、同期されていてもソースプールにまだ適用されていない更新がある場合、それらが宛先プールに適用され、宛先プールでより高いパッチバージョンになる可能性があります。

サポートを維持するためには、すべてのリソースプールを定期的に更新し、6か月以上古くならないようにする必要があります。

Driver Multi-Versioning (DMV) を使用したドライバー管理

XenServer 9では、Driver Multi-Versioning (DMV) が導入され、承認されたドライバーバージョンが標準のストリーミングホスト更新チャネルを通じて提供されるため、ほとんどの場合、個別のドライバーディスクは不要になります。

DMVを使用すると、オペレーターは更新ストリームで利用可能な複数の承認済みドライバーバージョンから選択できます。XenServerは、各ホストのハードウェアと互換性のあるドライバーバリアントのみを提示します。誤ったドライバーが適用された場合でも、ホストを再インストールすることなく正しいバージョンを選択してインストールできますが、変更を有効にするには再起動が必要です。XenServer 9は署名済みドライバーの検証を強制し、未承認のサードパーティ製バイナリをブロックします。

詳細については、「ドライバーのマルチバージョン化」を参照してください。

リソースプールの監視

ホストまたはVMのいずれかでリソースプールにアラートが発生した場合、それらはXenCenter®のアラートセクションで利用できます。

これらのアラートは、SNMP統合または電子メールSMTP統合を介して、外部監視ツールでも利用できるようにすることができます。

考慮すべき監視には2つのタイプがあります。

• 利用状況の監視。予期せぬ容量の問題が迅速に特定され、対処できるようにするためです。
• システムイベントを監視し、インフラストラクチャが正しく動作していること、および予期せぬ変更が発生していないことを確認します。

これらは統合設計で考慮されるべき事項として、以下に詳述されています。

サードパーティの監視製品との統合は、こちらで説明されているSNMP機能を通じて行うことができ、これらのサードパーティツールに統合されるアラートを提供できます。

注:

プールに新しいホストを追加する際は、新しいホストがSNMP統合に含まれるようにSNMP設定を再構成する必要があります（詳細は制約事項を参照）。

使用状況の監視

過剰なCPU使用率などの検出のために設定できるアラートがあります。詳細はパフォーマンスアラートを参照してください。

以下は、これらのイベントに対して発行されたSNMPトラップで提供されるデータの例です。

2026-02-19 09:44:35 <UNKNOWN> [UDP: [10.71.64.14]:53876->[10.81.143.35]:162]:
iso.3.6.1.2.1.1.3.0 = Timeticks: (196826250) 22 days, 18:44:22.50       iso.3.6.1.6.3.1.1.4.1.0 = OID: iso.3.6.1.4.1.60953.1.10.1   iso.3.6.1.4.1.60953.1.10.1.1.0 = STRING: "add"  iso.3.6.1.4.1.60953.1.10.1.2.0 = STRING: "OpaqueRef:eea63153-f96c-25f5-17b9-08ce49e7ccf4"   iso.3.6.1.4.1.60953.1.10.1.3.0 = STRING: "83a9c805-a172-f1b2-55d4-081ec180893b" iso.3.6.1.4.1.60953.1.10.1.4.0 = STRING: "ALARM"    iso.3.6.1.4.1.60953.1.10.1.5.0 = INTEGER: 3     iso.3.6.1.4.1.60953.1.10.1.6.0 = STRING: "VM"       iso.3.6.1.4.1.60953.1.10.1.7.0 = STRING: "681e4064-16cb-4d0c-9c2c-887623bc623f" iso.3.6.1.4.1.60953.1.10.1.8.0 = STRING: "20260219T09:45:55Z"       iso.3.6.1.4.1.60953.1.10.1.9.0 = STRING: "The memory required by the control domain on \"Control domain on host: pm-demolab-3\" is about 5.7% of its allocated memory. Occasional performance degradation can be expected when memory swapping is forced to happen.
This alarm is set to be triggered when the memory required by the control domain is above 5.0% of its allocated memory."
<!--NeedCopy-->

システムイベントの監視

システムアラートはこちらで説明されています。

以下は、これらのイベントに対して発行されたSNMPトラップで提供されるデータの例です。

2026-02-19 09:43:39 <UNKNOWN> [UDP: [10.71.64.14]:46982->[10.81.143.35]:162]:
iso.3.6.1.2.1.1.3.0 = Timeticks: (196820650) 22 days, 18:43:26.50       iso.3.6.1.6.3.1.1.4.1.0 = OID: iso.3.6.1.4.1.60953.1.10.1   iso.3.6.1.4.1.60953.1.10.1.1.0 = STRING: "add"  iso.3.6.1.4.1.60953.1.10.1.2.0 = STRING: "OpaqueRef:ca95e2da-06b7-9aa5-fa4b-ddf007a50c59"   iso.3.6.1.4.1.60953.1.10.1.3.0 = STRING: "525e459c-51bc-c71c-9c52-dcd747e9a84f" iso.3.6.1.4.1.60953.1.10.1.4.0 = STRING: "ALL_RUNNING_VMS_IN_ANTI_AFFINITY_GRP_ON_SINGLE_HOST"      iso.3.6.1.4.1.60953.1.10.1.5.0 = INTEGER: 3iso.3.6.1.4.1.60953.1.10.1.6.0 = STRING: "Pool"  iso.3.6.1.4.1.60953.1.10.1.7.0 = STRING: "419d6735-5d11-56b1-8cdc-2853ce709a27"     iso.3.6.1.4.1.60953.1.10.1.8.0 = STRING: "20260219T09:44:59Z"   iso.3.6.1.4.1.60953.1.10.1.9.0 = STRING: "<body><message>Breach on VM anti-affinity rules</message><VM_group>3224f9d9-9492-06f7-3c92-da610cde33a8</VM_group><host>ce2a3c26-6bbc-4d23-8626-fba28d3dc651</host></body>"
<!--NeedCopy-->

リモートロギング

これの主な目的は、サポート対応を可能にすることです。問題解決中にこのデータの可用性を確保するために、syslog転送を設定できます。これにより、ホストから直接ログを取得できない場合や、ホスト上のログが改ざんされた疑いがある場合に、ログを取得できるようになります。

これが設定されている場合、プール内のすべてのホストで設定する必要があります。

このデータはかなりのスペースを消費する可能性があります。この機能とデータの使用および保持は、社内のセキュリティポリシーに基づいてお客様の裁量に委ねられます。

キャパシティプランニングモデル

リソースプールのサイジング

各リソースプールには、1台のホストがダウンしてもリソースプールが完全なワークロードを運用できるだけの十分なリソースが含まれている必要があります。これにより、以下が可能になります。

• 1台のホストで一度に必要に応じて計画的な停止が発生する
• ワークロードの停止なしにリソースプールの更新が行われる
• 1台のホストが予期せず故障した場合でも、ワークロードの停止を最小限に抑える

これを達成するためには、リソースプール内のすべてのホストがワークロードをサポートする同じ能力を持っていること（つまり、同じ構成、RAM、CPU）が期待されます。これにより、停止中にCPUオーバーコミットのレベルが高くなる可能性がありますが、これは停止状態が解消されるまで短期間であると予想されます。

リソースプール内で2台以上のホストが失われた場合、すべてのワークロードを維持することはできなくなり、ホストが復旧するまでワークロードの停止が発生する可能性があります。

注記：

ハードウェアの更新/リフレッシュなどのアクティビティ中に、ホストが一時的に同一の容量を持たない場合、最も多くのメモリを持つホストの障害に備える必要があります。

リソースプールのキャパシティ計算

このリファレンスアーキテクチャでは、各リソースプールが特定の目的のためにあると仮定しています。その結果、以下の計算では、リソースプール内のすべてのVMが同じ仕様であると仮定しています。

NUMA最適化

XenServer 9は、デフォルトでNUMA配置の最適化を有効にしています。VMのvCPUとメモリがホスト上の単一のNUMAノード内に収まる場合、ワークロードはメモリアクセス遅延が低減され、より一貫したパフォーマンスを実現します。これにより、ホストあたりのVM密度を高めることもでき、追加のサーバーの必要性を減らすことができます。

最良の結果を得るには、VMのメモリが単一の物理NUMAノード内に収まるようにVMをサイジングしてください。VMが単一ノードが提供できる以上のメモリを必要とする場合、XenServerはVMを複数のノードに分散させ、最適化のメリットが減少します。NUMAノードの境界を超えるVMサイジングは、標準ではなく例外として扱われるべきです。

VMごとのNUMAメトリックは、配置を監視し、アフィニティ違反を検出するために利用できます。詳細については、XenServer 9でのNUMA最適化を参照してください。

リソースプール容量の計算

Dom0のサイズは32 GB RAMです。ただし、PVSアクセラレータを使用している場合は、アクセラレーションをサポートするためにvdiskあたり少なくとも5 GB増やす必要があり、これらの計算で考慮に入れる必要があります。

入力

出力

注記:

ホストの障害、メンテナンス、または更新操作中に vm_host = vm_pool_max / (hosts_total - 1)

計算例

• vm_host_max = (1000 - 32 - 2) / 16 = 60 max VMs per Host
• vm_pool_max = 60 * (8 - 1) = 420 max VMs per pool
• srs_total = 420 * (3 + 0) / 1000 = 1.26 SRs (>1 so need 2 SRs spread over 2 LUNS)
• 通常運用時:
  • vm_host = 420 / 8 = 52.5 VMs per host (round down to 52)
  • host_cpu_overcommit = ((52 * 4) + 16 + 2) / 128 = 1.77 vCPU per pCPU
• 単一ホストの停止時、または更新/メンテナンス操作時:
  • vm_host = 420 / 7 = 60 VMs per host
  • host_cpu_overcommit = ((60 * 4) + 16 + 2) / 128 = 2.01 vCPU per pCPU

注:

RAMオーバーコミットを提供するためにDynamic Memory Control (DMC) は使用されません。XenServerは通常の運用中にこれをサポートしていません。これは、必要なワークロードを実行し続けるための他の選択肢がない場合に、計画的で管理された短期間のメンテナンス中にのみ使用されることが想定されています。

オーバーコミットが高すぎる場合、プール内のVMの数を許容できるレベルに達するまで減らす必要があります。