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プールまでとなります。プール内のすべてのホストは、密結合されたネットワーク境界内で動作し、共有ストレージへの一貫した信頼性の高いアクセスを保証すると想定されています。
  • ホストは、必要なワークロードとコントロール ドメインを、パフォーマンス キャッシュ要件 ((#sizing-the-resource-pool)を参照) とともにサポートするのに十分なRAMを備えている必要があり、最大6 TBまでです。
  • ホストは、XenServer OS用のローカルストレージ（最小46 GB、理想的には70 GB）を備えているか、SANから起動できる必要があります。

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

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

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

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

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

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

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

範囲外

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

• 個々の仮想ディスクが2TBを超えるワークロード
• 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を自動モードに設定します

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

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

• 管理ネットワーク
• 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は、ワークロードの使用状況が時間とともに変化するにつれて、最適なホスト利用率とパフォーマンスを維持するために使用できます。

アプライアンスをリソースプールにインポートし、その接続には管理ネットワークを使用します。ワークロードバランシング (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/sです。これは、いずれかのホストが読み取りまたは書き込みにより多くの帯域幅を使用している場合、再配置の対象となることを意味します。このパラメーターは、重いネットワークワークロードを実行している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ホストをサードパーティの監視ソリューションと統合し、ホストが応答しないときに検出します。

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

連絡不能なホストがコーディネーターであり、管理操作が利用できない場合、リソースプール内の他のすべてのホストは緊急モードに入り、それらのいずれかを新しいプールコーディネーターとして選出するために、リモート接続を確立できるようになります。これはリモート言語バインディングを使用して実行できます。以下の例は、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のデプロイメント間バージョン管理を参照してください）。

運用モデル

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

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

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

オプション:

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

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

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

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

注:

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

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

リソースプールの監視

ホストまたは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-->

システムイベントの監視

システムアラートについては、(/ja-jp/xenserver/8/monitor-performance/alerts.html#system-alerts)で説明しています。

以下に、これらのイベントで発生する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が同じ仕様であると仮定しています。

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オーバーコミットを提供するために、動的メモリ制御 (DMC) は使用されません。XenServer は通常稼働時にこれをサポートしていません。これは、必要なワークロードを稼働させ続けるための他の選択肢がない場合に、計画的で管理された短期間のメンテナンス中にのみ使用されることが想定されています。

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