VMware Cloud Foundation 環境向けの ESXi ホスト構成の設計では、各ワークロード ドメイン クラスタ内の仮想マシンをサポートするために必要なリソース、ネットワーク、セキュリティ ポリシーを考慮します。

VMware Cloud Foundation の ESXi の論理設計

ESXi の論理設計では、仮想インフラストラクチャを管理コンポーネントとワークロード コンポーネントに提供するために、ESXi ホストと VMware Cloud Foundation インスタンスの他のコンポーネントの高レベル統合を決定します。

VMware Cloud Foundation インスタンスの管理コンポーネントとワークロード コンポーネントを実行するために必要なリソースを提供するために、各 ESXi ホストは次の要素で構成されます。

  • CPU とメモリ

  • ストレージ デバイス

  • アウトオブバンド管理インターフェイス

  • ネットワーク インターフェイス

図 1. VMware Cloud Foundation の ESXi 論理設計

ESXi ホストには、コンピューティング用の CPU とメモリ、vSAN ローカル ストレージと非ローカル ストレージ、仮想スイッチ アップリンク用の NIC、アウトオブバンド ホスト管理用の Intelligent Platform Management Interface (IPMI) があります。

VMware Cloud Foundation の ESXi のサイジングに関する考慮事項

クラスタあたりの ESXi ホストの数と、ESXi ホストあたりの物理ディスクの数を決定します。

展開する VMware Cloud Foundation インスタンスの全体的なプロファイルに応じたサイジングの詳細については、「 VMware Cloud Foundation プランニングおよび準備ワークブック」を参照してください。

各システムの構成と組み立てのプロセスは、すべてのコンポーネントを同様の手順で各 ESXi ホストにインストールするように標準化されている必要があります。ESXi ホストの物理構成の標準化により多様化が排除されるため、インフラストラクチャを簡単に管理およびサポートできます。ESXi ホストは、すべてのクラスタ メンバーで、ストレージおよびネットワーク構成などが同じ構成で展開されます。たとえば、物理ネットワーク インターフェイス コントローラと仮想ネットワーク リソースの正確なマッピングには、特にネットワーク インターフェイス コントローラに対して一貫した PCIe カード スロット配置が不可欠です。同一の構成を使用することで、ストレージ リソースとコンピューティング リソース間で仮想マシン ストレージ コンポーネントのバランスが均等になります。

表 1. ハードウェア要素別の ESXi サーバのサイジングに関する考慮事項

ハードウェア要素

検討事項

CPU

  • クラスタで実行されているワークロードの合計 CPU 要件。

  • ホストの障害とメンテナンスのシナリオ。

    仮想 CPU と pCPU のオーバー コミットメント比率は、管理ドメインでは 2:1 以下、VI ワークロード ドメインでは 8:1 以下で維持します。

  • 追加のサードパーティ管理コンポーネント。

  • 論理コアではなく、物理コアの数。Intel CPU のハイパースレッドなど、CPU での同時マルチスレッド (SMT) テクノロジーは、同じ CPU コアで複数のスレッドを並行して実行できるようにすることで、CPU パフォーマンスを向上させます。1 つの CPU コアを 2 つの論理コアとして表示できますが、パフォーマンスの向上は CPU 電力の 100% 増加には相当しません。また、環境によっても異なります。

メモリ

  • クラスタで実行されているワークロードの合計メモリ要件。

  • クラスタ内の ESXi ホストのメモリ サイズを設定する場合、フェイルオーバーまたはメンテナンスのために 1 台のホストのリソースを予約するには、アドミッション コントロールの設定を N+1 に設定します。これにより、1 台のホストのリソースがフェイルオーバーまたはメンテナンスのために予約されます。

  • vSAN OSA。ESXi ホスト上の vSAN ディスク グループとディスクの数。

    ディスク グループの最大数をサポートするには、32 GB の RAM を指定する必要があります。設計およびサイジングのガイダンスを含むディスク グループの詳細については、vSphere ドキュメントの「VMware vSAN の管理」を参照してください。

  • vSAN ESA。512 GB の RAM を指定する必要があります。

ストレージ

  • 起動デバイスにハード ドライブや SSD などの高耐久性デバイスを使用します

  • 128 GB の起動デバイスを使用して、ESX-OS データで使用可能な容量を最大化します

  • vSAN OSA
    • 少なくとも 1 つの 600 GB キャッシュ ディスクを指定します。

    • 少なくとも 2 つのキャパシティ ディスクを使用します。

  • vSAN ESA。少なくとも 2 つの NVME デバイスを使用します。

  • 同種の構成のホストを使用します。

VMware Cloud Foundation の ESXi 設計要件と推奨事項

VMware Cloud Foundation のワークロード ドメイン内の ESXi ホストの要件は、ドメインでホストされているワークロードのシステム要件に関連しています。ESXi 要件には、数、サーバ構成、ハードウェア リソースの量、ネットワーク、および証明書管理が含まれます。同様のベスト プラクティスは、最適な環境操作の設計に役立ちます。

ESXi サーバ設計の要件

VMware Cloud Foundation 展開に含まれるワークロード ドメイン内の ESXi ホストの場合は、次の設計要件を満たす必要があります。

表 2. ESXi サーバの設計の要件

要件 ID

設計の要件

要件の理由

要件の影響

VCF-ESX-REQD-CFG-001

展開するクラスタ タイプに必要な最小台数以上の ESXi ホストをインストールします。

  • 可用性の要件が満たされていることを確認します。

  • 障害またはメンテナンス イベントが原因でいずれかのホストが使用できない場合、CPU のオーバー コミットメント率は 2:1 になります。

なし。

VCF-ESX-REQD-CFG-002

各 ESXi ホストが、必要な CPU、メモリ、およびストレージの仕様に合致していることを確認します。

  • 障害やメンテナンス中でも、競合が発生することなくワークロードが実行されるようにします。

予測される展開サイズに基づく VMware Cloud Foundation プランニングおよび準備ワークブック のサイズに応じて、サーバの仕様と台数を組み合わせます。

VCF-ESX-REQD-SEC-001

ホストに FQDN を割り当てた後、各 ESXi ホストの証明書を再生成します。

ワークロード ドメインの展開中に VMware Cloud Builder との安全な接続を確立し、中間者攻撃 (MiTM) を防止します。

ワークロード ドメインを展開する前に、ESXi ホストの証明書を手動で再生成する必要があります。

ESXi サーバ設計の推奨事項

VMware Cloud Foundation の ESXi ホスト設計では、特定のベスト プラクティスを適用できます。

表 3. ESXi サーバの設計の推奨事項

推奨 ID

推奨事項

理由

影響

VCF-ESX-RCMD-CFG-001

管理ドメインの各 ESXi ホストに、vSAN ストレージを持つ vSAN ReadyNode を使用します。

管理ドメインは、展開時の vSAN と完全に互換性があります。

vSAN 対応の物理サーバのモデルについては、「vSAN ReadyNode での vSAN 互換性ガイド」を参照してください。

ハードウェアの選択は制限される場合があります。

vSAN ReadyNode ではないサーバ構成を使用する場合は、CPU、ディスク、および I/O モジュールについて、『VMware Cloud Foundation 5.2 リリース ノート』で指定されている ESXi バージョンに合致する、「VMware 互換性ガイド」の「CPU シリーズ」と「vSAN 互換性リスト」の記載を参照してください。

VCF-ESX-RCMD-CFG-002

デフォルトの管理 vSphere クラスタ全体に対し、構成を統一したホストを割り当てます。

負荷が分散されているクラスタには、次の利点があります。

  • ハードウェアで障害が発生してもパフォーマンスが予測可能

  • 再同期または再構築の操作によるパフォーマンスへの影響を最小化

均一化されたサーバ ノードに対するベンダー ソーシング、予算策定、および調達に関する考慮事項は、クラスタ単位で適用する必要があります。

VCF-ESX-RCMD-CFG-003

CPU のサイジング時には、マルチスレッド テクノロジーや、関連するパフォーマンスの向上は考慮しないでください。

マルチスレッド テクノロジーは CPU パフォーマンスを高めますが、パフォーマンスの向上は、実行中のワークロードに依存し、状況に応じて異なります。

物理 CPU コアを増やす必要があるため、コストは増加し、ハードウェアの選択肢は制限されます。

VCF-ESX-RCMD-CFG-004

デフォルトの管理クラスタにすべての ESXi ホストをインストールし、128 GB 以上のデバイスを使用して起動するように構成します。

vSAN を使用する場合は、メモリが大きい（512 GB を上回る）ホストにスクラッチ パーティション用の十分な容量を用意します。

なし。

VCF-ESX-RCMD-CFG-005

デフォルトの管理クラスタ内のすべての ESXi ホストで、スクラッチ パーティションのデフォルト構成を使用します。

  • vSAN クラスタで障害が発生しても、ESXi ホストは引き続き応答し、ログ情報にも引き続きアクセスできます。

  • スクラッチ パーティションに vSAN データストアを使用することはできません。

なし。

VCF-ESX-RCMD-CFG-006

デフォルトの管理クラスタで実行されているワークロードの場合は、仮想マシン スワップ ファイルをデフォルトの場所に保存します。

構成プロセスが簡素化されます。

ディザスタ リカバリ プロセスの一環として、リカバリされる管理ワークロードのレプリケーション トラフィックの量が増えます。

VCF-ESX-RCMD-NET-001

ESXi ホストを、仮想マシン管理ネットワークとは別のホスト管理ネットワーク上の各管理ドメイン クラスタに配置します。

セキュリティ上の理由から、ESXi ホストとその他の管理コンポーネント間の物理 VLAN を分離できるようにします。

仮想マシン管理ネットワークは、VI ワークロード ドメイン内のマルチラック コンピューティング専用クラスタには必要ありません。

必要な VLAN の数を増やします。

VCF-ESX-RCMD-NET-002

各 VI ワークロード ドメイン内の ESXi ホストを個別のホスト管理 VLAN によってバッキングされたネットワークに配置します。

セキュリティ上の理由から、異なる VI ワークロード ドメイン内の ESXi ホスト間の物理 VLAN を分離できるようにします。

 必要な VLAN の数を増やします。VI ワークロード ドメインごとに、個別の管理サブネットを割り当てる必要があります。

VCF-ESX-RCMD-SEC-001

SSH サービスを停止し、デフォルトの SSH サービス ポリシー Start and stop manually を使用することで、管理ドメイン内のすべての ESXi ホストで SSH アクセスを無効にします。

『vSphere セキュリティ設定ガイド』およびセキュリティのベスト プラクティスに準拠していることを確認します。

SSH アクセスを無効にすると、SSH インターフェイスを介した、ESXi ホストに対するセキュリティ攻撃のリスクが軽減されます。

ワークロード ドメインの展開後、VMware Cloud Foundation が ESXi ホストでの SSH を無効にするため、トラブルシューティングやサポート アクティビティ用に SSH アクセスを手動で有効にする必要があります。

VCF-ESX-RCMD-SEC-002

管理ドメイン内のすべての ESXi ホストで、詳細設定の UserVars.SuppressShellWarning を 0 に設定します。
  • 『vSphere セキュリティ設定ガイド』およびセキュリティのベスト プラクティスに準拠していることを確認します。
  • ESXi ホストで SSH アクセスが有効になるたびに vSphere Client に表示される警告メッセージを有効にします。

トラブルシューティングまたはサポート アクティビティを実行する場合は、SSH 有効化の警告メッセージを手動でオフにする必要があります。