VMware Cloud Foundation の物理ネットワーク設計の要素

この設計決定リストを、単一または複数の VMware Cloud Foundation インスタンスがある環境での物理ネットワークの構成に関する参照資料として使用してください。この設計では、インスタンスに含まれるアベイラビリティ ゾーンが 1 つか複数かどうかも考慮されます。

設計の詳細については、「VMware Cloud Foundation の物理ネットワーク インフラストラクチャの設計」を参照してください。

表 1. VMware Cloud Foundation のリーフ/スパイン物理ネットワーク設計の要件

要件 ID	設計の要件	理由	影響
VCF-NET-REQD-CFG-001	ESXi ホスト アップリンクには、EtherChannel（LAG、LACP、または vPC）構成を使用しないでください。	トップオブラック スイッチの構成を簡素化します。 vSphere Distributed Switch で使用可能なチーミング オプションは、ロード バランシングとフェイルオーバーを提供します。 EtherChannel の実装には、ベンダー固有の制限がある場合があります。	なし。
VCF-NET-REQD-CFG-002	VLAN を使用して物理ネットワーク機能を分離します。	多くの NIC を必要とせずに物理ネットワーク接続をサポートします。 SDDC のさまざまなネットワーク機能を分離して、必要に応じて差別化されたサービスと優先順位付けされたトラフィックを提供できるようにします。	ESXi ホストで使用できるすべてのトランクに均一な構成とプレゼンテーションが必要です。
VCF-NET-REQD-CFG-003	VLAN を 802.1Q トランクのメンバーとして設定します。	すべての VLAN は、ESXi ホスト上の同じ物理ネットワーク アダプタで使用できるようになります。	必要に応じて、管理 VLAN はネイティブ VLAN として機能できます。
VCF-NET-REQD-CFG-004	次のトラフィック タイプをサポートする、物理スイッチ ポート、vSphere Distributed Switch、vSphere Distributed Switch ポート グループ、および N-VDS スイッチ上の MTU サイズを 1,700 バイト以上に設定します（ジャンボ フレームの場合は 9,000 バイトを推奨）： オーバーレイ (Geneve) vSAN vSphere vMotion	トラフィックのスループットを向上します。 MTU サイズを 1,600 バイト以上に増やすことで Geneve をサポートします。 Geneve は拡張可能なプロトコルです。MTU サイズは、今後の機能で増加する可能性があります。1,600 バイトで十分ですが、1,700 バイトの MTU サイズを使用すると、物理インフラストラクチャの MTU サイズを変更することなく Geneve MTU サイズを増やすための余地ができます。	MTU パケット サイズを調整するときは、同じ MTU パケット サイズをサポートするようにネットワーク パス全体（VMkernel ネットワーク アダプタ、仮想スイッチ、物理スイッチ、ルーター）も構成する必要があります。 複数のアベイラビリティ ゾーンがある環境では、ゾーン間のネットワーク パス全体で MTU を構成する必要があります。

表 2. VMware Cloud Foundation に対するマルチラック コンピューティング VI ワークロード ドメイン クラスタのリーフ/スパイン物理ネットワーク設計の要件

要件 ID	設計の要件	理由	影響
VCF-NET-L3MR-REQD-CFG-001	マルチラック コンピューティング VI ワークロード ドメイン クラスタの場合は、各ネットワーク機能のラックごとに個別の VLAN を指定します。 ホストの管理 vSAN vSphere vMotion ホスト オーバーレイ	レイヤー 3 リーフ/スパイン ファブリックは、各ラックのリーフ スイッチにレイヤー 3 境界を持ち、ラック間にレイヤー 3 境界を作成します。	ラックごとに追加の VLAN が必要です。
VCF-NET-L3MR-REQD-CFG-002	マルチラック コンピューティング VI ワークロード ドメイン クラスタの場合、ラックごとの各ネットワークのサブネットは、ルーティング可能で他のラックのリーフ スイッチにアクセスできる必要があります。 ホストの管理 vSAN vSphere vMotion ホスト オーバーレイ	各ネットワークのトラフィックがラック間を流れることができるようにします。	ネットワークをラック間でルーティング可能にするには、追加の物理ネットワーク構成が必要です。

表 3. VMware Cloud Foundation に対するマルチラック NSX Edge 可用性のリーフ/スパイン物理ネットワーク設計の要件

要件 ID	設計の要件	理由	影響
VCF-NET-MRE-REQD-CFG-001	マルチラック NSX Edge 可用性を実現するには、Edge ノード専用の各ラックで、次の VLAN を使用してリーフ スイッチを構成します。 仮想マシン管理 Edge アップリンク 1 Edge アップリンク 2 Edge オーバーレイ	レイヤー 3 リーフ/スパイン ファブリックは、各ラックのリーフ スイッチにレイヤー 3 境界を持ち、ラック間にレイヤー 3 境界を作成します。	ラックごとに追加の VLAN が必要です。
VCF-NET-MRE-REQD-CFG-002	マルチラック NSX Edge 可用性を実現するには、Edge ノード専用の各ラックで、次のネットワークのサブネットがルーティング可能で、他のラックのリーフ スイッチにアクセスできる必要があります。 仮想マシン管理 Edge オーバーレイ	Edge TEP ネットワークのトラフィックがラック間を流れることができるようにします。	ネットワークをラック間でルーティング可能にするには、追加の物理ネットワーク構成が必要です。

表 4. VMware Cloud Foundation での NSX フェデレーションのリーフ/スパイン物理ネットワーク設計の要件

要件 ID	設計の要件	理由	影響
VCF-NET-REQD-CFG-005	次のトラフィック タイプの VMware Cloud Foundation インスタンス間にある物理ネットワークのコンポーネントで、MTU サイズを少なくとも 1,500 バイト（1,700 バイトを優先、ジャンボ フレームには 9,000 バイトを推奨）に設定します。 NSX Edge RTEP	VMware Cloud Foundation インスタンス間ではジャンボ フレームは必要ありません。ただし、MTU を増やすと、トラフィックのスループットが向上します。 RTEP MTU を 1,700 バイトに増やすと、VMware Cloud Foundation インスタンス間にある標準サイズのワークロード パケットの断片化が最小限に抑えられます。	MTU パケット サイズを調整する場合は、仮想インターフェイス、仮想スイッチ、物理スイッチ、ルーターなどのネットワーク パス全体も同じ MTU パケット サイズをサポートするように構成する必要があります。
VCF-NET-REQD-CFG-006	NSX フェデレーションで接続されている VMware Cloud Foundation インスタンス間の遅延が 500 ミリ秒未満であることを確認します。	NSX フェデレーションでは、遅延が 500 ミリ秒未満であることが必要です。	なし。
VCF-NET-REQD-CFG-007	NSX フェデレーションで接続されている VMware Cloud Foundation インスタンス内の NSX Manager クラスタ間で、経路指定された接続を提供します。	NSX フェデレーションを構成するには、NSX グローバル マネージャ インスタンス、NSX ローカル マネージャ インスタンス、NSX Edge クラスタ間の接続が必要です。	フォルト ドメインごとに一意のルーティング可能な IP アドレスを割り当てる必要があります。

表 5. VMware Cloud Foundation のリーフ/スパイン物理ネットワーク設計の推奨事項

推奨 ID	設計の推奨事項	理由	影響
VCF-NET-RCMD-CFG-001	ラックごとに 2 台の ToR スイッチを使用します。	各サーバへの 2 つの 10 GbE（25 GbE 以上を推奨）リンクの使用をサポートし、冗長性を提供して、全体的な設計の複雑さを低減します。	ラックごとに 2 台の ToR スイッチが必要で、これによりコストが増加する可能性があります。
VCF-NET-RCMD-CFG-002	次の物理ネットワーク アーキテクチャを実装します。 ESXi ホスト アップリンク（ホストから ToR）の各 ToR スイッチに少なくとも 1 つの 25 GbE（最低でも 10 GbE）ポート。 BGP をサポートするレイヤー 3 デバイス。	スイッチ障害時の可用性を提供します。 BGP 動的ルーティング プロトコルのサポートを提供します	ハードウェアの選択肢が制限される場合があります。 物理ネットワークで動的ルーティング プロトコルを構成する必要があります。
VCF-NET-RCMD-CFG-003	BGP ルーティングの隣接関係用に構成された物理ネットワークを使用します。	マルチサイト ワークロードとマルチテナント ワークロードをルーティングするための設計の柔軟性をサポートします。 BGP は、NSX フェデレーションでサポートされる唯一の動的ルーティング プロトコルです。 ECMP Edge アップリンク間のフェイルオーバーをサポートします。	物理ネットワークで BGP 構成が必要です。
VCF-NET-RCMD-CFG-004	動的 IP アドレス プールのアドレス指定の代わりに静的 IP アドレス プールを使用する NSX トンネル エンドポイント (TEP) にパーシステント IP アドレス構成を割り当てます。	エンドポイントにパーシステント TEP IP アドレスがあることを確認します。 VMware Cloud Foundation では、すべてのトポロジに静的 IP アドレス プールを使用した TEP IP アドレスの割り当てが推奨されます。 この構成により、外部 DHCP サービスの要件はすべて排除されます。	クラスタにホストを追加するには、静的 IP アドレス プールを増やす必要がある場合があります。
VCF-NET-RCMD-CFG-005	ESXi NIC に接続されているトランク ポートを trunk PortFast として構成します。	ポートを転送状態に移行する時間を短縮します。	この設計では STP は使用されませんが、通常、スイッチにはデフォルトで STP が構成されています。
VCF-NET-RCMD-CFG-006	これらのネットワークに VRRP、HSRP、または別のレイヤー 3 ゲートウェイの可用性方法を構成します。 管理 Edge オーバーレイ	アベイラビリティ ゾーン間で拡張された VLAN が高可用性ゲートウェイに接続されていることを確認します。そうしないと、レイヤー 3 ゲートウェイで障害が発生すると、SDN セットアップのトラフィックが中断します。	データセンターのレイヤー 3 ゲートウェイに高可用性テクノロジーを構成する必要があります。
VCF-NET-RCMD-CFG-007	各クラスタのネットワーク機能に個別の VLAN を使用します。	レイヤー 2 ブロードキャスト ドメインのサイズを単一の vSphere クラスタに縮小します。	VMware Cloud Foundation インスタンスに必要な VLAN の総数を増やします。

表 6. VMware Cloud Foundation に対する専用 Edge のスケールとパフォーマンスのリーフ/スパイン物理ネットワーク設計の推奨事項

推奨 ID	設計の推奨事項	理由	影響
VCF-NET-DES-RCMD-CFG-001	次の物理ネットワーク アーキテクチャを実装します。 ESXi ホスト アップリンク（ホストから ToR）の各 ToR スイッチに 2 つの 100 GbE ポート。 BGP をサポートするレイヤー 3 デバイス。	大規模な展開では、高帯域幅と 1 秒あたりのパケット数の要件をサポートします。	100 GbE ネットワーク スイッチが必要です。

表 7. VMware Cloud Foundation での NSX フェデレーションのリーフ/スパイン物理ネットワーク設計の推奨事項

推奨 ID	設計の推奨事項	理由	影響
VCF-NET-RCMD-CFG-008	NSX フェデレーション セットアップで接続されているすべての VMware Cloud Foundation インスタンス間で BGP ルーティングを提供します。	BGP は、NSX フェデレーションでサポートされるルーティング プロトコルです。	なし。
VCF-NET-RCMD-CFG-009	ワークロード モビリティのために、NSX フェデレーションで接続されている VMware Cloud Foundation インスタンス間の遅延が 150 ミリ秒未満であることを確認します。	次の機能では、遅延が 150 ミリ秒未満であることが必要です。 vCenter Server 間の vMotion	なし。