vSphere クラスタ設計では、ワークロードの特性に応じて、標準クラスタ、ストレッチ クラスタ、リモート クラスタ、およびクラスタ内の ESXi ホストのライフサイクル管理の要件を考慮する必要があります。

VMware Cloud Foundation の論理 vSphere クラスタ設計

クラスタ設計では、クラスタに展開されるワークロードの特性を考慮する必要があります。

vSphere でクラスタ レイアウトを設計する場合は、次のガイドラインを考慮します。

  • より大きな ESXi ホストを少なく購入する場合の資本コストと、より小さな ESXi ホストを多く購入するコストを比較します。コストは、ベンダーとモデルによって異なります。スケールアップされたクラスタで 1 台の大規模なホストが失われるリスクと、スケールアウト クラスタで 1 台以上の小規模なホストが失われる可能性が高くなる場合のビジネスへの影響を評価します。

  • いくつかの ESXi ホストを管理する場合の運用コストと、より多くの ESXi ホストを管理するコストを評価します。

  • クラスタの目的（管理、コンピューティング専用、Edge およびコンピューティング、または Edge 専用のクラスタ）を考慮します。

  • NSX Edge 専用クラスタの場合は、vSphere クラスタ内の ESXi ノードの物理 NIC の数を考慮します。

  • ESXi ホストとクラスタの制限の合計数を考慮します。

図 1. VMware Cloud Foundation の単一のアベイラビリティ ゾーンを持つ論理 vSphere クラスタ レイアウト

各 VMware Cloud Foundation インスタンスで、1 つのアベイラビリティ ゾーンを持つセットアップの場合は、ESXi ホストの vSphere クラスタのワークロードを編成します。

図 2. VMware Cloud Foundation の複数のアベイラビリティ ゾーンの論理 vSphere クラスタ レイアウト

2 つのアベイラビリティ ゾーンを持つセットアップの場合は、vSAN ストレッチ クラスタでワークロードを編成します。

リモート クラスタの設計に関する考慮事項

リモート クラスタは、中央サイトの管理インフラストラクチャによって管理されます。

表 1. リモート クラスタの設計に関する考慮事項

リモート クラスタ属性

検討事項

リモート クラスタあたりのホストの数

  • 最小：2（外部ストレージを使用）

  • 最大：16

VMware Cloud Foundation インスタンスにリモート クラスタがある VI ワークロード ドメイン。

  • 最大：24
VI ワークロード ドメインあたりのリモート クラスタの数

  • 最大：30

VI ワークロード ドメインごとのクラスタ タイプ

VI ワークロード ドメインには、ローカル クラスタまたはリモート クラスタのいずれかを含めることができます。

中央サイトとリモート サイト間の遅延

  • 最大：100 ミリ秒

中央サイトとリモート サイト間の帯域幅

  • 最小：10 Mbps

VMware Cloud Foundation の vSphere クラスタ ライフサイクル方法の設計

vSphere Lifecycle Manager は、各ワークロード ドメイン内の vSphere クラスタを管理するために使用されます。

ワークロード ドメインを展開する場合は、組織の要件に基づいて vSphere クラスタのライフサイクル管理方法を選択できます。ワークロード ドメイン内の追加のクラスタでは、特定の要件を満たすために、別の vSphere クラスタ ライフサイクル管理方法を柔軟に選択できます。

表 2. vSphere Lifecycle Manager の選択肢

クラスタのライフサイクル管理方法

説明

メリット

デメリット

vSphere Lifecycle Manager のイメージ

vSphere Lifecycle Manager のイメージには、基本イメージ、ベンダー アドオン、ファームウェア、ドライバが含まれます。

  • NVIDIA GPU 対応クラスタをサポートします。

  • 2 ノード NFS、FC、または vVols クラスタをサポートします。

  • vSAN ESA および vSAN OSA クラスタをサポートします。

  • ワークロード ドメインまたはクラスタの展開中は、最初のクラスタ イメージが必要です。

vSphere Lifecycle Manager のベースライン

アップグレード ベースラインには ESXi イメージが含まれており、パッチ ベースラインには ESXi ホストのそれぞれのパッチが含まれています。

  • NSX のインプレース アップグレードをサポート

  • NVIDIA GPU 対応クラスタではサポートされません。

  • 2 ノード NFS、FC、または vVol クラスタではサポートされません。

  • vSAN ESA クラスタではサポートされません。

  • 廃止されました。

VMware Cloud Foundation の vSphere クラスタ設計の要件と推奨事項

vSphere クラスタの設計には、ホストの最小数、設計要件、および設計に関する推奨事項が適用されます。

vSAN 設計の要件と推奨事項については、「VMware Cloud Foundation の vSAN 設計の要件と推奨事項」を参照してください。

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

vSphere クラスタの設計に関する考慮事項

標準クラスタとストレッチ vSAN クラスタのストレージ タイプと特定のリソース要件に応じて、クラスタごとに異なるホスト数を考慮します。

表 3. クラスタごとのホスト関連の設計に関する考慮事項

属性

仕様

管理ドメイン（デフォルト クラスタ）

管理ドメイン（追加クラスタ）または VI ワークロード ドメイン（すべてのクラスタ）

ESXi ホスト数の最小値

vSAN（単一のアベイラビリティ ゾーン）

4

3

vSAN(2 つのアベイラビリティ ゾーン)

8

6

NFS、FC、または vVol

サポート対象外

  • 2

    • VI ワークロード ドメインのみ

    • vSphere Lifecycle Manager イメージが必要

  • 3

    • 追加の管理クラスタ

クラスタあたりのESXiホスト障害を処理するための予約済み容量

単一のアベイラビリティ ゾーン

  • 25% の CPU とメモリ

  • 1 台のホスト障害を許容

  • 33% の CPU とメモリ

  • 1 台のホスト障害を許容

2 つのアベイラビリティ ゾーン

  • 50% の CPU とメモリ

  • 1 つのアベイラビリティ ゾーンの障害を許容

  • 50% の CPU とメモリ

  • 1 つのアベイラビリティ ゾーンの障害を許容

VMware Cloud Foundation の vSphere クラスタ設計の要件

VMware Cloud Foundation の vSphere クラスタ設計では、標準クラスタとストレッチ クラスタについて次の設計要件を満たす必要があります。クラスタ設計では、クラスタのストレージ タイプ、環境のアーキテクチャ モデル、およびライフサイクル管理方法が考慮されます。

表 4. VMware Cloud Foundation の vSphere クラスタ設計要件

要件 ID

設計の要件

理由

影響

VCF-CLS-REQD-CFG-001

ESXi ホストの初期セットの各ワークロード ドメインにクラスタを作成します。

  • ユーザー ワークロードから管理ワークロードを分離することで、構成を簡素化します。

  • ユーザー ワークロードが管理スタックに影響を与えないことを確認します。

複数のクラスタおよび vCenter Server インスタンスを管理すると、運用上のオーバーヘッドが増加します。

VCF-CLS-REQD-CFG-002

展開するクラスタ タイプに応じて、ESXi ホストの最小数を割り当てます。

  • 正しいレベルの冗長性を確保して、クラスタ内のホスト障害から保護します。

冗長性をサポートするには、追加の ESXi ホスト リソースを割り当てる必要があります。

VCF-CLS-REQD-CFG-003

統合ワークロード ドメインを使用する場合は、次の vSphere リソース プールを構成して、管理ワークロードとユーザー ワークロード別にリソース使用量を制御します。

  • cluster-name-rp-sddc-mgmt

  • cluster-name-rp-sddc-edge

  • cluster-name-rp-user-edge

  • cluster-name-rp-user-vm

  • 管理コンポーネントに十分なリソースを確保します。

vSphere リソース プールの設定は、一定期間管理する必要があります。

VCF-CLS-REQD-CFG-004

vSAN クラスタの場合、vSAN Max クラスタを除き、クラスタの隔離アドレスとして vSAN ネットワーク ゲートウェイの IP アドレスを構成します。

vSphere HA はホストが vSAN ネットワークから隔離されているかどうかを検証できます。

追加の IP アドレスを割り当てる必要があります。

VCF-CLS-REQD-CFG-005

vSAN クラスタの場合、vSAN Max クラスタを除き、クラスタの詳細設定 das.usedefaultisolationaddress を false に設定します。

vSphere HA がデフォルトの管理ネットワーク ゲートウェイ アドレスではなく手動隔離アドレスを使用していることを確認します。

なし。
表 5. VMware Cloud Foundation を使用した vSAN ストレッチ クラスタの vSphere クラスタ設計要件

要件 ID

設計の要件

理由

影響

VCF-CLS-REQD-CFG-006

2 番目のアベイラビリティ ゾーンの vSAN ネットワークの IP アドレスを、クラスタの追加の隔離アドレスとして構成します。

両方のアベイラビリティ ゾーンのホストに対して、ホストが vSAN ネットワークから隔離されているかどうかを、vSphere HA で検証できるようにします。

vSAN ネットワーク ゲートウェイの IP アドレスは、高可用性があり、ICMP 要求に応答する必要があります。

VCF-CLS-REQD-CFG-007

すべての ESXi ホストの vSAN VMkernel アダプタで、[このアダプタのデフォルト ゲートウェイをオーバーライド] 設定を有効にします。

vSAN データ トラフィックを管理ゲートウェイ経由ではなく、vSAN ネットワーク ゲートウェイ経由でルーティングできるようにします。

アベイラビリティ ゾーン間の vSAN ネットワークには、相互にルートが必要です。

VCF-CLS-REQD-CFG-008

アベイラビリティ ゾーンごとにホスト グループを作成し、ゾーン内の ESXi ホストをそれぞれのグループに追加します。

どの仮想マシンがどのアベイラビリティ ゾーンで実行されるかを簡単に管理できます。

仮想マシンとホスト間の DRS グループ ルールを作成して維持する必要があります。

VMware Cloud Foundation の vSphere クラスタ設計の推奨事項

vSphere クラスタ設計では、標準クラスタとストレッチ クラスタに特定のベスト プラクティスを適用できます。

表 6. VMware Cloud Foundation の vSphere クラスタ設計の推奨事項

推奨 ID

設計の推奨事項

理由

影響

VCF-CLS-RCMD-CFG-001

vSphere HA を使用して、すべての仮想マシンを障害から保護します。

vSphere HA は、ESXi ホストと仮想マシンの可用性の両方に対して堅牢なレベルの保護をサポートします。

ホストが停止した場合にそれらのホストで仮想マシンを再起動できるように、残りのホストに十分なリソースを提供する必要があります。

VCF-CLS-RCMD-CFG-002

vSAN の場合、ホスト隔離時の対応を [パワーオフ] に設定し、vSphere HA で仮想マシンを再起動します。

vSAN では、ホスト隔離時の対応を [パワーオフ] に設定し、使用可能な ESXi ホスト上の仮想マシンを再起動する必要があります。

誤検知イベントが発生すると、仮想マシンはパワーオフされ、ESXi ホストが誤って隔離されていると宣言されます。

VCF-CLS-RCMD-CFG-003

1 台の ESXi ホストの障害および割合ベースのフェイルオーバー キャパシティのアドミッション コントロールを構成します。

仮想マシンの CPU またはメモリの予約が変化し、CPU またはメモリの予約が大量になる場合に、割合ベースの予約を使用すると適切に機能します。

vSphere は、許容する ESXi ホスト障害の数とクラスタ内の ESXi ホストの数に応じて、予約された割合を自動的に計算します。

4 台の ESXi ホストが含まれるクラスタでは、3 台の ESXi ホストのリソースのみを使用できます。

VCF-CLS-RCMD-CFG-004

各クラスタの仮想マシンの監視を有効にします。

仮想マシンを監視すると、ほとんどの仮想マシン ワークロードにゲスト内保護が提供されます。仮想マシンで実行されているアプリケーションまたはサービスは、再起動後に、または、仮想マシンの再起動が十分でない場合に、正常に再起動できる必要があります。

なし。

VCF-CLS-RCMD-CFG-005

管理アプライアンスのストレージおよびネットワーク I/O アクティビティの監視を無効にするには、クラスタの詳細設定 das.iostatsinterval を 0 に設定します。

OS 障害が発生し、ハートビートが VMware Tools から受信されない場合に、I/O チェックが完了するまで追加で待機する代わりに、管理アプライアンスの再起動をトリガできるようにします。

I/O 監視を特別に有効にする場合は、[das.iostatsinterval] の詳細設定を構成する必要があります。

VCF-CLS-RCMD-CFG-006

中程度のしきい値でデフォルトの完全自動化モードを使用して、すべてのクラスタで vSphere DRS を有効にします。

vSphere vMotion によるロード バランシングと不要な移行の間で最適なトレードオフが提供されます。

vCenter Server の停止が発生した場合、仮想マシンから ESXi ホストへのマッピングを特定するのが難しい場合があります。

VCF-CLS-RCMD-CFG-007

管理ドメイン内のすべてのクラスタで Enhanced vMotion Compatibility (EVC) を有効にします。

仮想マシンのダウンタイムなしでクラスタのアップグレードをサポートします。

EVC は、クラスタに同じベンダーの CPU を搭載したホストが含まれている場合にのみ有効にする必要があります。

ブリングアップ中に、デフォルトの管理ドメイン クラスタで EVC を有効にする必要があります。

VCF-CLS-RCMD-CFG-008

クラスタ EVC モードを、クラスタ内のホスト上で最も低い CPU アーキテクチャでサポートされている使用可能な最も高いベースラインに設定します。

仮想マシンのダウンタイムなしでクラスタのアップグレードをサポートします。

なし。

VCF-CLS-RCMD-LCM-001

イメージを、すべてのワークロード ドメインのライフサイクル管理方法として使用します。

  • vSphere Lifecycle Manager イメージを使用すると、ファームウェアとベンダー アドオンの管理を手動で簡素化できます。

  • vSAN ESA クラスタをサポートします。

  • VI ワークロード ドメインまたはクラスタの展開中は、クラスタ イメージが必要です。

  • 管理ドメインにクラスタを追加する場合は、クラスタ イメージが必要です。
表 7. VMware Cloud Foundation での vSAN ストレッチ クラスタの vSphere クラスタ設計の推奨事項

推奨 ID

設計の推奨事項

理由

影響

VCF-CLS-RCMD-CFG-009

アドミッション コントロールの割合を、クラスタ内の ESXi ホストの半分に増やします。

ストレッチ クラスタの半分のみを割り当てると、アベイラビリティ ゾーンが停止した場合にすべての仮想マシンに十分なリソースが確保されます。

8 台の ESXi ホストが含まれるクラスタでは、4 台の ESXi ホストのリソースのみを使用できます。

デフォルトの管理クラスタに ESXi ホストを追加する場合は、アベイラビリティ ゾーンごとに 1 台ずつ、ペアで追加します。

VCF-CLS-RCMD-CFG-010

アベイラビリティ ゾーンごとに仮想マシン グループを作成し、ゾーン内の仮想マシンをそれぞれのグループに追加します。

割り当てられたアベイラビリティ ゾーンにのみ仮想マシンが配置されるようにして、不要な vSphere vMotion 移行を回避します。

割り当てられたグループに仮想マシンを手動で追加する必要があります。

VCF-CLS-RCMD-CFG-011

同じアベイラビリティ ゾーン内の各ホストのグループの仮想マシンのグループごとに実行するために、グループ内のホストで実行する必要がある仮想マシンとホスト間のアフィニティ ルールを作成します。

割り当てられたアベイラビリティ ゾーンにのみ仮想マシンが配置されるようにして、不要な vSphere vMotion 移行を回避します。

ルールを手動で作成する必要があります。