リソースプール
A リソースプールは、複数のXenServer®ホストインストールで構成され、仮想マシンをホストできる単一の管理エンティティに結合されます。共有ストレージと組み合わせると、リソースプールにより、十分なメモリを持つ任意のXenServerホストでVMを起動できます。
The プールコーディネーター（旧称「プールマスター」）は、管理インターフェイス（XenCenter®およびxe CLIとして知られるXenServerコマンドラインインターフェイスで使用）を公開するリソースプール内のサーバーです。プールコーディネーターは、必要に応じて個々のメンバーにコマンドを転送します。
この記事では、リソースプールに関する概念、要件、およびベストプラクティスについて説明します。プールの作成と管理方法については、「プールの管理」を参照してください。
リソースプールの利点
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で、CPUベンダー（Intel、AMD）が同じである必要があります。
-
すべての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リースを持っている必要があります。
推奨されるプールサイズ
記載されている構成制限の32は、プールでサポートされるホストの最大数です。ただし、ほとんどのワークロードにとって管理またはパフォーマンスの観点から最適なサイズではないことが多いため、推奨されるプールサイズではありません。デプロイメントに最適なサイズを決定する際には、次の要素を考慮してください。
-
管理に関する考慮事項: ほとんどの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は、管理APIトラフィックを暗号化するためにTLS 1.2プロトコルを使用します。XenServerと管理APIクライアント（またはアプライアンス）間のすべての通信は、TLS 1.2プロトコルを使用します。
重要:
製品の暗号化機能に対するお客様による変更はサポートしていません。
XenServerは以下の暗号スイートを使用します。
- ECDHE-RSA-AES256-GCM-SHA384
- ECDHE-RSA-AES128-GCM-SHA256
SSH
SSHクライアントを使用してXenServerホストに直接接続する場合、以下のアルゴリズムを使用できます。
暗号：
- エーイーエス128-シーティーアール
- aes256-ctr
- aes128-gcm@openssh.com
- エーイーエス256-ジーシーエム@オープンエスエスエイチ.コム
MACs (メッセージ認証コード):
- hmac-sha2-256 (アルゴリズム)
- hmac-sha2-512 (アルゴリズム)
- エイチマック-シャーワン
KexAlgorithms:
- カーブ25519-シャーニーゴーロク
- イーシーディーエイチ-エスエイチエー2-ニストピー256
- ecdh-sha2-nistp384
- ecdh-sha2-nistp521
HostKeyAlgorithms:
- イーシーディーエスエー・エスエイチエー２・エヌアイエスティーピー２５６
- イーシーディーエスエー・エスエイチエー２・エヌアイエスティーピー３８４
- イーシーディーエスエー・エスエイチエー２・ニストピー５２１
- エスエスエイチ・イーディー２５５１９
- エスエスエイチ・アールエスエー
重要:
当社は、製品の暗号化機能に対するお客様による変更をサポートしていません。ただし、XenServer ホストへの SSH アクセスを無効にする場合は、ホストの SSH アクセスを無効にする または プールの SSH アクセスを無効にする を参照してください。
ホストがリソースプールに参加するとどうなりますか?
新しいホストがリソースプールに参加すると、参加するホストは、そのローカルデータベースをプール全体のデータベースと同期し、プールからいくつかの設定を継承します。
-
VM、ローカル、およびリモートストレージの設定がプール全体のデータベースに追加されます。この設定は、ホストがプールに参加した後にリソースを明示的に共有しない限り、プール内の参加ホストに適用されます。
-
参加するホストは、プール内の既存の共有ストレージリポジトリを継承します。新しいホストが既存の共有ストレージに自動的にアクセスできるように、適切な PBD レコードが作成されます。
-
ネットワーク情報は、参加するホストに部分的に継承されます。NIC、VLAN、およびボンディングされたインターフェースの構造に関する詳細はすべて継承されますが、ポリシーに関する情報は継承されません。再構成が必要なこのポリシー情報には、以下が含まれます。
-
管理 NIC の IP アドレスは、元の構成から保持されます。
-
管理インターフェースの場所は、元の構成と同じままです。たとえば、他のプールホストがボンディングされたインターフェース上に管理インターフェースを持っている場合、参加するホストは参加後にボンディングに移行する必要があります。
-
専用ストレージ NIC は、XenCenter または CLI から参加ホストに再割り当てする必要があり、それに応じてトラフィックをルーティングするために PBD を再接続する必要があります。これは、IP アドレスがプール参加操作の一部として割り当てられないためであり、ストレージ NIC は正しく構成されている場合にのみ機能するためです。CLI からストレージ NIC を専用にする方法の詳細については、ネットワークの管理 を参照してください。
-