リソースプール
リソースプールは、複数のXenServer®ホストインストールで構成され、仮想マシンをホストできる単一の管理エンティティとして結合されます。共有ストレージと組み合わせることで、リソースプールは十分なメモリを持つ任意のXenServerホストでVMを起動できるようにします。
プールコーディネーター（旧称「プールマスター」）は、リソースプール内のサーバーであり、管理インターフェイス（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-ジーシーエム@オープンエスエスエイチ・ドット・コム
メッセージ認証コード:
- エイチマック-エスエイチエー2-256
- エイチマック-SHA2-512
- エイチマック-SHA1
KexAlgorithms:
- カーブ25519-SHA256
- イーシーディーエイチ-エスエイチエー2-ニストピー256
- ecdh-sha2-nistp384 (アルゴリズム)
- ecdh-sha2-nistp521 (アルゴリズム)
HostKeyAlgorithms:
- イーシーディーエスエー-エスエイチエー2-ニストピー256
- イーシーディーエスエー-エスエイチエー2-ニストピー384
- イーシーディーエスエー-エスエイチエー２-エヌアイエスティーピー５２１
- エスエスエイチ-イーディー２５５１９
- エスエスエイチ-アールエスエー
重要:
当社は、製品の暗号化機能に対するお客様による変更をサポートしていません。ただし、XenServer ホストへの SSH アクセスを無効にする場合は、ホストの SSH アクセスを無効にする または プールの SSH アクセスを無効にする を参照してください。
ホストがリソースプールに参加するとどうなりますか?
新しいホストがリソースプールに参加すると、参加するホストはローカルデータベースをプール全体のデータベースと同期し、プールからいくつかの設定を継承します。
-
VM、ローカル、およびリモートストレージ構成がプール全体のデータベースに追加されます。この構成は、ホストがプールに参加した後でリソースを明示的に共有しない限り、プール内の参加ホストに適用されます。
-
参加ホストは、プール内の既存の共有ストレージリポジトリを継承します。新しいホストが既存の共有ストレージに自動的にアクセスできるように、適切な PBD レコードが作成されます。
-
ネットワーク情報は、参加ホストに部分的に継承されます。NIC、VLAN、およびボンディングされたインターフェースの構造に関する詳細はすべて継承されますが、ポリシーに関する情報は継承されません。再構成が必要なこのポリシー情報には、以下が含まれます。
-
管理 NIC の IP アドレスは、元の構成から保持されます。
-
管理インターフェースの場所は、元の構成と同じままです。たとえば、他のプールホストがボンディングされたインターフェース上に管理インターフェースを持っている場合、参加ホストは参加後にボンディングに移行する必要があります。
-
専用ストレージ NIC は、XenCenter または CLI から参加ホストに再割り当てし、それに応じてトラフィックをルーティングするために PBD を再接続する必要があります。これは、IP アドレスがプール参加操作の一部として割り当てられず、ストレージ NIC は正しく構成されている場合にのみ機能するためです。CLI からストレージ NIC を専用にする方法の詳細については、ネットワークの管理 を参照してください。
-