リソースプール

最終公開日 : Oct 07, 2026
リソースプールは、複数のXenServer®ホストインストールで構成され、仮想マシンをホストできる単一の管理エンティティとして結合されます。共有ストレージと組み合わせると、リソースプールにより、十分なメモリを持つ任意のXenServerホストでVMを起動できるようになります。
プールコーディネーター (旧称「プールマスター」) は、リソースプール内のサーバーで、管理インターフェイス (XenCenter®およびxe CLIとして知られるXenServerコマンドラインインターフェイスによって使用されます) を公開します。プールコーディネーターは、必要に応じて個々のメンバーにコマンドを転送します。
この記事では、リソースプールに関する概念、要件、およびベストプラクティスについて説明します。プールを作成および管理する方法については、プールを管理するを参照してください。
Related information
プールを管理するホストを管理する証明書の検証GFS2 クラスタープール

リソースプールの利点

XenServerホストをスタンドアロンホスト (実質的に1つのプール) として編成することもできますが、XenServerは共有ストレージを持つリソースプールにグループ化されたホスト向けに最適化されています。高可用性やライブマイグレーションなど、いくつかの機能は、複数のホストで構成されるリソースプールでのみ利用可能です。XenServerホストをリソースプールに編成する利点は次のとおりです。
  • VMモビリティ: VMがプール上で実行されており、ディスクがプール共有ストレージ上にある場合、これらのVMは、実行中にXenServerホスト間で動的に移動できます (ライブマイグレーション)。また、個々のXenServerホストでハードウェア障害が発生した場合、管理者は、同じリソースプール内の別のXenServerホストで障害が発生したVMを再起動できます。
  • 高可用性 この機能は、ワークロード内のVMを保護し、ハードウェアまたはホスト障害が発生した場合にダウンタイムを最小限に抑えるように機能します。リソースプールで高可用性が有効になっている場合、VMはホストが失敗すると別のホストで自動的に再起動できます。プールコーディネーターが失敗した場合、高可用性は別のプールコーディネーターを選出します。詳細については、高可用性を参照してください。
  • ワークロードバランシング ワークロードバランシングは、リソースプールとそこで実行されているVMワークロードを評価し、VMの最適な配置を推奨できます。また、ワークロードバランシングがその配置推奨事項に自動的に従い、プール内のホスト間でVMを移行するように選択することもできます。詳細については、ワークロードバランシングを参照してください。
  • アンチアフィニティVM配置: グループ内のVMがプール内のホスト全体に均等に分散されるようにします。詳細については、VM配置を参照してください。
  • 管理の容易さ: 各XenServerホストを個別に管理するのではなく、リソースプールをXenCenterに追加し、その中のすべてのホスト、SR、およびVMをまとめて管理します。詳細については、XenCenterを参照してください。

リソースプールを作成するための要件

XenServerデプロイメントを設計し、プール構成を決定する際には、次の要件を考慮してください。

ハードウェア要件

XenServerリソースプール内のすべてのサーバーは、広範に互換性のあるCPUを搭載している必要があります。つまり:
  • CPUベンダー（Intel、AMD）は、すべてのサーバーのすべてのCPUで同じである必要があります。
  • すべてのCPUで仮想化が有効になっている必要があります。
CPUの類似性に応じて、プールは次のいずれかのタイプになります。
  • 同種プール: 同種リソースプールは、同一のCPUを持つサーバーの集合体です。同種リソースプールに参加するサーバーのCPUは、すでにプール内にあるサーバーのCPUと同じベンダー、モデル、および機能を備えている必要があります。
  • 異種プール: 異種プールの作成は、Intel (FlexMigration) および AMD (Extended Migration) のCPUに搭載されている、CPUのマスキングまたはレベリングを提供するテクノロジーを使用することで可能になります。これらの機能により、CPUを実際とは異なるメーカー、モデル、または機能セットを提供しているかのように見せかけるように構成できます。これらの機能により、異なるCPUを持つホストのプールを作成しつつ、ライブマイグレーションを安全にサポートできます。この機能のマスキングまたはレベリングの結果、CPUのフルパフォーマンスが得られない場合があります。

ホスト参加の要件

XenServerは、プールに参加するホストについて、以下の条件が満たされていることを確認します。
  • プール内の既存のホストと同じバージョンのXenServerを、同じ更新レベルで実行している必要があります。
  • 参加するホストは、既存のリソースプールのメンバーではないこと。
  • 参加するホストに共有ストレージが構成されていないこと。
  • 参加するホストが、実行中または一時停止中のVMをホストしていないこと。
  • 参加するホスト上のVMで、VMのシャットダウンやエクスポートなどのアクティブな操作が進行中でないこと。
  • 参加するホストのクロックが、プールコーディネーターと同じ時刻に同期されていること（例：NTPを使用）。
  • 参加するホストの管理インターフェースがボンディングされていないこと。ホストがプールに正常に参加した後で、管理インターフェースを構成できます。
  • 参加するホストの管理IPアドレスが静的であること（ホスト自体で構成されているか、DHCPサーバーで適切な構成を使用していること）。
  • 参加するホストの管理インターフェースは、リソースプールと同じタグ付きVLAN上にある必要があります。
  • 参加するホストは、プールにすでに存在するホストと同じリビジョンの同じ補足パックで構成されている必要があります。
  • 参加するホストは、プールにすでに存在するホストと同じXenServerライセンスを持っている必要があります。プールに参加した後、任意のプールメンバーのライセンスを変更できます。最も低いライセンスを持つホストが、プール内のすべてのメンバーに利用可能な機能を決定します。
    XenCenterを使用してホストをプールに追加する場合、XenCenterは一致するライセンスが参加するホストに適用されることを保証します。ただし、xe CLIを使用してプールに参加する場合は、プールに参加する前にホストに一致するライセンスを割り当てることをお勧めします。
  • 参加するホストは、プールと同じデータセンターにあるか、または近接定義を満たすデータセンターにあり、低遅延（往復5ms未満）、高帯域幅（10Gbps以上）のネットワークで接続されている必要があります。

ストレージ要件

リソースプールで使用される共有ストレージには、以下の要件があります。
  • プールに共有NFSまたはiSCSIストレージを提供するサーバーは、静的IPアドレスまたは静的DHCPリースを持っている必要があります。

推奨されるプールサイズ

記載されている構成制限の64は、プールでサポートされるホストの最大数です。ただし、これは推奨されるプールサイズではありません。ほとんどのワークロードにとって、管理またはパフォーマンスの観点から最適なサイズではないことが多いためです。デプロイメントに最適なサイズを決定する際には、以下の要素を考慮してください。
  • 管理に関する考慮事項: ほとんどのXenServer管理はプールレベルで実行されます。プールが大きいほど、必要な管理の量が減り、より多くのホストをまとめて管理できます。ただし、プールへの更新の適用など、一部の管理操作は、ホストが多いほど時間がかかる場合があります。これは、操作がプール内の各ホストで順次実行される必要があるためです。この場合、大規模なプールで特定の操作を完了するには、複数の小規模なプールよりも長いメンテナンスウィンドウが必要になる場合があります。
  • リソース共有: XenServerプールは通常、ストレージリポジトリなどのリソースをホスト間で共有します。プールが大きいほど、より多くのホストがリソースを共有でき、メリットがあります。たとえば、Citrix Virtual Apps and Desktops™環境では、複数のプールで複数のコピーを作成する必要がなく、より多くのホストがゴールドイメージを共有できます。ただし、共有リソースに選択する特定のデバイスには、小規模なホストグループを使用する方が良い特定のパフォーマンス上の考慮事項がある場合があります。
  • コントロールプレーンのパフォーマンス: XenServerプールでは、すべての操作がプールコーディネーターによって管理されます。プールにホストを追加するにつれて、このホストのツールスタックの負荷が増加します。各ホストからのバックグラウンドアクティビティが増え、同時操作の予想数が増加するためです。ツールスタックの負荷が増加すると、各操作にかかる時間が増加する可能性があります。その結果、1つの大規模なプールは、2つの小規模なプールよりも著しく遅く動作する可能性があります。
  • 障害分離: XenServerまたはプールにとって重要な別のコンポーネント（たとえば、ストレージデバイス）に問題が発生した場合、大規模なプールでは、そのワークロードが複数の小規模なプールに分割されている場合よりも、ワークロードに大きな影響を与える可能性があります。
  • GFS2ストレージ: ブロックストレージでシンプロビジョニングにGFS2ストレージを使用する場合、XenServerは最大16台のホストをサポートします。これは、GFS2実装の制限と、ストレージを管理するためにホスト間で必要となる通信の増加によるものです。
  • 高可用性: VMを保護するために高可用性機能を使用する場合、プール内のすべてのホストは互いを継続的に監視し、そのステータスを通信します。プールが大きくなるにつれて、各ホストがこの監視の一部として送受信しなければならないメッセージの量が増加します。コントロール ドメインに高い負荷がかかると、これらの監視メッセージの一部が失われる可能性が高まります。極端なシナリオでは、メッセージの損失により、安全のためにホストが予期せずフェンスされることがあります。高可用性機能を使用する場合は、予期せぬフェンシングのリスクを減らすために、最大16ホストのより小さなプールを使用することをお勧めします。
ほとんどのCitrix Virtual Apps and Desktopsのユースケースでは、プールサイズは16ホストを推奨し、最大サイズは32です。
これらの要素を考慮してプールサイズを計画するだけでなく、実行中の環境でプールサイズを変更する必要があるかどうかを判断するために、プールの動作を観察および監視してください。

XenServerホストおよびリソースプールとの通信

TLS

XenServerは、TLS 1.2プロトコルを使用して管理APIトラフィックを暗号化します。XenServerと管理APIクライアント（またはアプライアンス）間のすべての通信は、TLS 1.2プロトコルを使用します。
重要:
製品の暗号化機能に対するお客様による変更はサポートしていません。
XenServerは以下の暗号スイートを使用します。
  • ECDHE-RSA-AES256-GCM-SHA384
  • ECDHE-RSA-AES128-GCM-SHA256

SSH

SSHクライアントを使用してXenServerホストに直接接続する場合、以下のアルゴリズムを使用できます。
暗号:
MACアルゴリズム:
  • hmac-sha2-256 アルゴリズム
  • エイチマック-SHA2-512
  • エイチマック-SHA1
KexAlgorithms:
  • カーブ25519-SHA256
  • ECDH-SHA2-NISTP256
  • イーシーディーエイチ-エスエイチエー2-エヌアイエスティーピー384
  • イーシーディーエイチ-エスエイチエー2-エヌアイエスティーピー521
HostKeyAlgorithms:
  • イーシーディーエスエー-エスエイチエー2-ニストピー256
  • イーシーディーエスエー-エスエイチエー2-ニストピー384
  • イーシーディーエスエー・エスエイチエー２・ニストピー５２１
  • ssh-ed25519 キー
  • エスエスエイチ-アールエスエー
重要:
製品の暗号化機能に対するお客様による変更はサポートしていません。ただし、XenServer ホストへの SSH アクセスを無効にする場合は、ホストの SSH アクセスを無効にする または プールの SSH アクセスを無効にする を参照してください。

ホストがリソースプールに参加するとどうなりますか?

新しいホストがリソースプールに参加すると、参加するホストは、そのローカルデータベースをプール全体のデータベースと同期し、プールからいくつかの設定を継承します。
  • VM、ローカル、およびリモートストレージ構成がプール全体のデータベースに追加されます。この構成は、ホストがプールに参加した後にリソースを明示的に共有しない限り、プール内の参加ホストに適用されます。
  • 参加するホストは、プール内の既存の共有ストレージリポジトリを継承します。新しいホストが既存の共有ストレージに自動的にアクセスできるように、適切な PBD レコードが作成されます。
  • ネットワーク情報は、参加するホストに部分的に継承されます。NIC、VLAN、およびボンディングされたインターフェースの構造に関する詳細はすべて継承されますが、ポリシーに関する情報は継承されません。再構成が必要なこのポリシー情報には、以下が含まれます。
    • 管理 NIC の IP アドレスは、元の構成から保持されます。
    • 管理インターフェースの場所は、元の構成と同じままです。たとえば、他のプールホストがボンディングされたインターフェース上に管理インターフェースを持っている場合、参加するホストは参加後にそのボンディングに移行する必要があります。
    • 専用ストレージ NIC は、XenCenter または CLI から参加ホストに再割り当てし、トラフィックを適切にルーティングするために PBD を再接続する必要があります。これは、IP アドレスがプール参加操作の一部として割り当てられず、ストレージ NIC は正しく構成されている場合にのみ機能するためです。CLI からストレージ NIC を専用にする方法の詳細については、ネットワークの管理 を参照してください。