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

設計の詳細については、「VMware Cloud Foundation の NSX 設計」を参照してください。

NSX Manager 設計の要素

表 1. VMware Cloud Foundation の NSX Manager 設計の要件

要件 ID

設計の要件

理由

影響

VCF-NSX-LM-REQD-CFG-001

NSX Manager クラスタのアプライアンスを管理ドメインの仮想マシン管理ネットワークに配置します。

  • 同じ VLAN とサブネットを使用して、管理仮想マシンの IP アドレス指定を簡素化します。

  • 同じ VLAN ネットワーク内の管理仮想マシンへの簡素化された安全なアクセスを提供します。

なし。

VCF-NSX-LM-REQD-CFG-002

ワークロード ドメインのネットワーク サービスを構成および管理するために、管理ドメインのデフォルトの vSphere クラスタに 3 つの NSX Manager ノードを展開します。

NSX Manager クラスタの高可用性をサポートします。

3 つの NSX Manager ノードを実行するため、管理ドメインのデフォルト クラスタに十分なリソースが必要です。

表 2. VMware Cloud Foundation の NSX Manager 設計の推奨事項

推奨 ID

設計の推奨事項

理由

影響

VCF-NSX-LM-RCMD-CFG-001

ワークロード ドメインの NSX Manager クラスタに適切なサイズのノードを展開します。

ワークロード ドメインごとのリソースの可用性と使用効率を確実に実現します。

管理ドメインのデフォルト サイズは [中] で、VI ワークロード ドメインの場合は [大] です。

VCF-NSX-LM-RCMD-CFG-002

ワークロード ドメインの NSX Manager クラスタについて仮想 IP (VIP) アドレスを作成します。

NSX Manager のユーザー インターフェイスと API の高可用性を実現します。

  • VIP アドレス機能は高可用性のみを実現します。クラスタ全体にわたる要求のロード バランシングは行いません。

  • VIP アドレス機能を使用する場合は、すべての NSX Manager ノードを同じレイヤー 2 ネットワークに展開する必要があります。

VCF-NSX-LM-RCMD-CFG-003

vSphere Distributed Resource Scheduler (vSphere DRS) の仮想マシン間の非アフィニティ ルールを NSX Manager アプライアンスに適用します。

高可用性を実現するために、NSX Manager アプライアンスを異なる ESXi ホストで実行し続けます。

ESXi ホスト障害が発生しても 3 台の NSX Manager アプライアンスが引き続き実行されるように、少なくとも 4 台の物理ホストを割り当てる必要があります。

VCF-NSX-LM-RCMD-CFG-004

vSphere HA で、各 NSX Manager アプライアンスの再起動の優先順位ポリシーを高に設定します。

  • NSX Manager は、仮想ネットワーク セグメントの制御プレーンを実装します。vSphere HA は最初に NSX Manager アプライアンスを再起動します。これにより、制御プレーンがオフラインの間、パワーオンされた、または vSphere vMotion を使用して移行された他の仮想マシンは、制御プレーン クォーラムが再確立されるまでの間だけ接続を失います。

  • 再起動の優先順位を高に設定すると、NSX Manager より前に起動する必要があるサービスを追加できるように、最も高い優先順位が予約されます。

別の管理アプライアンスに最も高い再起動の優先順位が設定されている場合、管理アプライアンスの接続遅延が長くなります。

表 3. VMware Cloud Foundation のストレッチ クラスタに関する NSX Manager 設計の推奨事項

推奨 ID

設計の推奨事項

理由

影響

VCF-NSX-LM-RCMD-CFG-006

NSX Manager アプライアンスを最初のアベイラビリティ ゾーンの仮想マシン グループに追加します。

デフォルトで、NSX Manager アプライアンスがプライマリ アベイラビリティ ゾーンのホストでパワーオンされるようにします。

なし。

NSX グローバル マネージャ設計の要素

NSX グローバル マネージャの設計の要件と推奨事項については、構成タスクを手動で実行する必要があります。

表 4. VMware Cloud Foundation の NSX グローバル マネージャ設計の要件

要件 ID

設計の要件

理由

影響

VCF-NSX-GM-REQD-CFG-001

VMware Cloud Foundation インスタンスの管理仮想マシン ネットワークに、NSX グローバル マネージャ クラスタのアプライアンスを配置します。

  • 管理仮想マシンの IP アドレス指定を簡素化します。

  • 同じ VLAN ネットワーク内のすべての管理仮想マシンへの簡素化された安全なアクセスを提供します。

なし。

表 5. VMware Cloud Foundation の NSX グローバル マネージャ設計の推奨事項

推奨 ID

設計の推奨事項

理由

影響

VCF-NSX-GM-RCMD-CFG-001

ワークロード ドメインに 3 つの NSX グローバル マネージャ ノードを展開して、VMware Cloud Foundation インスタンス間の NSX フェデレーションをサポートします。

NSX グローバル マネージャ クラスタの高可用性を実現します。

3 つの NSX グローバル マネージャ ノードを実行するため、管理ドメインのデフォルト クラスタに十分なリソースが必要です。

VCF-NSX-GM-RCMD-CFG-002

ワークロード ドメインの NSX グローバル マネージャ クラスタに適切なサイズのノードを展開します。

VMware 構成の上限を確認して、スケールのニーズに適した NSX グローバル マネージャ フォーム ファクタを選択します。

ワークロード ドメインごとのリソースの可用性と使用効率を確実に実現します。

NSX グローバル マネージャのサイズが正しくないと、要件に応じてスケーリングする機能に影響する可能性があります。

VCF-NSX-GM-RCMD-CFG-003

ワークロード ドメインの NSX グローバル マネージャ クラスタについて仮想 IP アドレス (VIP) アドレスを作成します。

NSX グローバル マネージャのユーザー インターフェイスと API の高可用性を実現します。

  • VIP アドレス機能は高可用性のみを実現します。クラスタ全体にわたる要求のロード バランシングは行いません。

  • VIP アドレス機能を使用する場合は、すべての NSX グローバル マネージャ ノードを同じレイヤー 2 ネットワークに展開する必要があります。

VCF-NSX-GM-RCMD-CFG-004

vSphere DRS の仮想マシン間の非アフィニティ ルールを NSX グローバル マネージャ アプライアンスに適用します。

高可用性を実現するために、NSX グローバル マネージャ アプライアンスを異なる ESXi ホストで実行し続けます。

ESXi ホスト障害が発生しても 3 台の NSX Manager アプライアンスが引き続き実行されるように、少なくとも 4 台の物理ホストを割り当てる必要があります。

VCF-NSX-GM-RCMD-CFG-005

vSphere HA で、各 NSX グローバル マネージャ アプライアンスの再起動の優先順位ポリシーを中に設定します。

  • NSX グローバル マネージャは、グローバル セグメントとファイアウォール用の管理プレーンを実装します。

    制御プレーンとデータ プレーンの接続には、NSX グローバル マネージャは必要ありません。

  • 再起動の優先順位を「中」に設定すると、NSX の制御プレーンまたはデータ プレーンに影響するサービスのために優先順位「高」が予約されます。

  • NSX グローバル マネージャの仮想マシンが再起動するまで、NSX グローバル コンポーネントの管理は使用できません。

  • NSX グローバル マネージャ クラスタは、仮想マシンの合計数が制限され、再起動の優先順位のために他の管理コンポーネントと競合する管理ドメインに展開されます。

VCF-NSX-GM-RCMD-CFG-006

2 番目の VMware Cloud Foundation インスタンスに、追加の NSX グローバル マネージャ クラスタを展開します。

最初の VMware Cloud Foundation インスタンスで障害が発生した場合に、2 番目の VMware Cloud Foundation インスタンスで NSX グローバル マネージャの復旧性を有効にします。

2 番目の VMware Cloud Foundation インスタンスに、追加の NSX グローバル マネージャ ノードが必要です。

VCF-NSX-GM-RCMD-CFG-007

2 番目の VMware Cloud Foundation インスタンスの NSX グローバル マネージャ クラスタをワークロード ドメインのスタンバイとして設定します。

最初のインスタンスで障害が発生した場合に、2 番目の VMware Cloud Foundation インスタンスで NSX グローバル マネージャの復旧性を有効にします。

手動で実行する必要があります。

VCF-NSX-GM-RCMD-SEC-001

SDDC Manager を使用して証明書が更新されるたびに、NSX グローバル マネージャで NSX ローカル マネージャ証明書のサムプリントをキャプチャして更新する運用上のプラクティスを確立します。

NSX Manager インスタンス間の安全な接続が確実に行われるようにします。

各証明書には、独自の一意のサムプリントがあります。NSX グローバル マネージャは、セキュリティを強化するために、NSX ローカル マネージャ インスタンスの一意のサムプリントを保存します。

NSX グローバル マネージャと NSX ローカル マネージャの間で認証エラーが発生した場合、NSX グローバル マネージャから作成されたオブジェクトは SDN に伝達されません。

管理者は、サムプリントを最新の状態に保つため、ランブックまたは自動プロセスを使用して、運用方法を確立し、それに沿う必要があります。

表 6. VMware Cloud Foundation のストレッチ クラスタの NSX グローバル マネージャ設計の推奨事項

推奨 ID

設計の推奨事項

理由

影響

VCF-NSX-GM-RCMD-CFG-008

NSX グローバル マネージャ アプライアンスを最初のアベイラビリティ ゾーンの仮想マシン グループに追加します。

デフォルトで、NSX グローバル マネージャ アプライアンスがプライマリ アベイラビリティ ゾーンのホストでパワーオンされるようにします。

クラスタをストレッチするときに、 VMware Cloud Foundation によって自動的に実行されます。

NSX Edge 設計の要素

表 7. VMware Cloud Foundation の NSX Edge 設計の要件

要件 ID

設計の要件

理由

影響

VCF-NSX-EDGE-REQD-CFG-001

各 NSX Edge ノードの管理インターフェイスを仮想マシン管理ネットワークに接続します。

NSX Manager クラスタから NSX Edge への接続を実現します。

なし。

VCF-NSX-EDGE-REQD-CFG-002

  • vmnic0 と vmnic1 のように、NSX Edge アプライアンスのアップリンクとして 2 つの物理 NIC を使用します。

  • 各 NSX Edge アプライアンスの fp-eth0 インターフェイスを、ホストの 1 つの物理 NIC (vmnic0) に固定された VLAN トランク ポート グループに接続します(別の物理 NIC (vmnic1) にフェイルオーバー可能)。

  • 各 NSX Edge アプライアンスの fp-eth1 インターフェイスを、ホストの物理 NIC (vmnic1) に固定された VLAN トランク ポート グループに接続します(最初の物理 NIC (vmnic0) にフェイルオーバー可能)。

  • 各 NSX Edge アプライアンスの追加の fp-eth2 および fp-eth3 インターフェイスは使用しないままにします。

  • VLAN トランク ポート グループはすべての VLAN のトラフィックを渡すため、VLAN タギングが、デプロイ後の構成を容易にするために NSX Edge ノード自体で行われる場合があります。

  • 2 つの個別の VLAN トランク ポート グループを使用すると、必要に応じて Edge ノードから特定のホスト ネットワーク インターフェイスおよびトップオブラック スイッチにトラフィックを転送できます。

  • トップオブラック スイッチで障害が発生した場合、VLAN トランク ポート グループは他の物理 NIC にフェイルオーバーし、fp-eth0fp-eth1 の両方を使用できるようにします。

なし。

VCF-NSX-EDGE-REQD-CFG-003

ホスト オーバーレイ VLAN とは異なる Edge オーバーレイに専用 VLAN を使用します。

専用の Edge オーバーレイ ネットワークは、複数のアベイラビリティ ゾーンやマルチラック クラスタなどの高度な展開をサポートする Edge モビリティをサポートします。

  • Edge オーバーレイとホスト オーバーレイの VLAN 間のルーティングが必要です。

  • Edge オーバーレイ用に、データセンター インフラストラクチャに別の VLAN を割り当てる必要があります。

VCF-NSX-EDGE-REQD-CFG-004

3 つのチーミング ポリシーを使用して、Edge ノードに 1 つのアップリンク プロファイルを作成します。

  • アクティブ アップリンク uplink1uplink2 の両方を持つロード バランシング ソースのデフォルトのチーミング ポリシー。

  • 単一のアクティブ アップリンク uplink1 を持つ(スタンバイ アップリンクなし)、フェイルオーバーの順序の名前付きチーミング ポリシー。

  • 単一のアクティブ アップリンク uplink2 を持つ(スタンバイ アップリンクなし)、フェイルオーバーの順序の名前付きチーミング ポリシー。

  • 単一の N-VDS を使用する NSX Edge ノードに設定できるアップリンク プロファイルは 1 つのみです。

  • 回復性とパフォーマンスを向上するため、ESXi ホスト上の両方の物理 NIC を介した両方の Edge アップリンクの同時使用をサポートします。

  • デフォルトのチーミング ポリシーは、複数の TEP を使用し、オーバーレイ トラフィックのバランシングを行うことで、オーバーレイのパフォーマンスと可用性を向上します。

  • 名前付きチーミング ポリシーを使用すると、Edge アップリンクを特定のホスト アップリンクに接続し、そこからデータセンター内の特定のトップオブラック スイッチに接続できます。

  • NSX Edge ノードは、2 つの異なる VLAN を介して物理ネットワークにアップリンクできるため、ECMP を有効にします。

なし。

表 8. VMware Cloud Foundation の NSX マルチラック Edge の可用性設計の要件

要件 ID

設計の要件

理由

影響

VCF-NSX-MR-EDGE-REQD-ENV-001

Edge クラスタごとに少なくとも 1 台の Edge 仮想マシンを、別のラックにある各 vSphere クラスタに配置します。

ラックまたは vSphere クラスタで障害が発生した場合に可用性を提供します。

追加のコンピューティング リソースが必要です。

VCF-NSX-MR-EDGE-REQD-CFG-001

各ラック内の各 NSX Edge ノードの管理インターフェイスを、そのラックの仮想マシン管理ネットワークに接続します。

NSX Manager クラスタから NSX Edge への接続を実現します。

なし。

VCF-NSX-MR-EDGE-REQD-CFG-002

マルチラック NSX Edge クラスタの展開に使用される各ラックの Edge オーバーレイ ネットワークに専用の IP アドレス プールを使用します。

ラックごとの専用 Edge オーバーレイ ネットワークとサブネットは、リーフ ノードにレイヤー 2 境界を持つレイヤー 3 リーフ/スパイン物理ネットワーク設計をサポートします。

追加のラックごとに追加の IP アドレス プールを管理する必要があります。

VCF-NSX-MR-EDGE-REQD-CFG-003

ラックごとに Edge アップリンク プロファイルを作成します。

ラックごとに専用の Edge オーバーレイ VLAN を使用して、リーフ ノードにレイヤー 2 境界を持つレイヤー 3 リーフ/スパイン物理ネットワーク設計をサポートできるようにします。

なし。
表 9. VMware Cloud Foundation での NSX フェデレーションの NSX Edge 設計の要件

要件 ID

設計の要件

理由

影響

VCF-NSX-EDGE-REQD-CFG-005

Edge オーバーレイ VLAN とは異なる Edge RTEP オーバーレイに個別の VLAN を割り当てます。

RTEP ネットワークは、Edge オーバーレイ VLAN とは異なる VLAN 上にある必要があります。これは、ネットワークごとに異なる MTU サイズを構成するためのサポートを提供する NSX 要件です。

データセンター インフラストラクチャに別の VLAN を割り当てる必要があります。

表 10. VMware Cloud Foundation の NSX Edge 設計の推奨事項

推奨 ID

設計の推奨事項

理由

影響

VCF-NSX-EDGE-RCMD-CFG-001

適切なサイズに設定された NSX Edge 仮想アプライアンスを使用します。

ワークロード ドメインごとのリソースの可用性と使用効率を確実に実現します。

選択したアプライアンス サイズをサポートするのに十分なコンピューティング リソースを用意する必要があります。

VCF-NSX-EDGE-RCMD-CFG-002

ワークロード ドメインのデフォルトの vSphere クラスタに NSX Edge 仮想アプライアンスを展開し、ワークロードと Edge アプライアンス間でクラスタを共有します。

構成を簡素化し、初期展開に必要な ESXi ホストの数を最小限に抑えます。

ワークロードと NSX Edge は同じコンピューティング リソースを共有します。

VCF-NSX-EDGE-RCMD-CFG-003

ワークロード ドメインのデフォルトの vSphere クラスタ内の Edge クラスタに 2 台の NSX Edge アプライアンスをデプロイします。

可用性の要件を満たしながら、最小サイズの NSX Edge クラスタを作成します。

VI ワークロード ドメインの場合、帯域幅の増加要件を満たすために、追加の Edge アプライアンスが必要になる場合があります。

VCF-NSX-EDGE-RCMD-CFG-004

NSX Edge クラスタの仮想マシンに、vSphere DRS の仮想マシン間の非アフィニティ ルールを適用します。

高可用性を実現するために、NSX Edge ノードを異なる ESXi ホストで実行し続けます。

なし。

VCF-NSX-EDGE-RCMD-CFG-005

vSphere HA で、各 NSX Edge アプライアンスの再起動の優先順位ポリシーを高に設定します。

  • NSX Edge ノードは、オーバーレイ セグメントの North-South データ パスの一部です。vSphere HA は、Edge 仮想マシンがオフラインになる時間を最小限に抑えるために、最初に NSX Edge アプライアンスを再起動します。

  • 再起動の優先順位を高に設定すると、今後必要になったときに備えて、最も高い優先順位が予約されます。

クラスタ内の別の仮想マシンの再起動の優先度が最も高い場合、Edge アプライアンスの接続遅延が長くなります。

VCF-NSX-EDGE-RCMD-CFG-006

クラスタ内の NSX Edge ノード間でのデフォルトの双方向の転送検出 (BFD) 構成を使用して、NSX Edge クラスタを作成します。

  • デフォルトで、可用性の要件を満たします。

  • NAT、物理ネットワークへのルーティング、ロード バランシングなどのサービスを作成するには、Edge ノードを引き続き使用できる必要があります。

なし。

VCF-NSX-EDGE-RCMD-CFG-007

NSX Edge ノードで単一の N-VDS を使用します。

  • Edge ノードの展開を簡素化します。

  • Edge フォーム ファクタに関係なく、同じ N-VDS スイッチ設計を使用できます。

  • Edge ノードで複数の TEP インターフェイスをサポートします。

  • Edge ノードでは、vSphere Distributed Switch はサポートされていません。

なし。

表 11. VMware Cloud Foundation のストレッチ クラスタに関する NSX Edge 設計の推奨事項

推奨 ID

設計の推奨事項

理由

影響

VCF-NSX-EDGE-RCMD-CFG-008

NSX Edge アプライアンスを最初のアベイラビリティ ゾーンの仮想マシン グループに追加します。

デフォルトで、NSX Edge アプライアンスがプライマリ アベイラビリティ ゾーンのホストでパワーオンされるようにします。

なし。

VMware Cloud Foundation の BGP ルーティング設計の要素

表 12. VMware Cloud Foundation の BGP ルーティング設計の要件

要件 ID

設計の要件

理由

影響

VCF-NSX-BGP-REQD-CFG-001

Tier-0 ゲートウェイとレイヤー 3 デバイス(ToR スイッチまたはアップストリーム デバイス)間で ECMP を有効にするには、2 つの VLAN を作成します。

ToR スイッチまたはアップストリーム レイヤー 3 デバイスは、2 つの VLAN のいずれかに SVI を持ち、クラスタ内の各 Edge ノードには各 VLAN のインターフェイスがあります。

Tier-0 ゲートウェイで複数の等コスト ルートをサポートして、ネットワークでの回復性を向上し、帯域幅の使用を強化します。

追加の VLAN が必要です。

VCF-NSX-BGP-REQD-CFG-002

VLAN セグメントへの名前付きチーミング ポリシーをレイヤー 3 デバイス ペアに割り当てます。

各セグメントの VLAN トラフィックをターゲット Edge ノード インターフェイスに固定します。トラフィックは、そこから、ターゲットのトップオブラック スイッチに接続されているホストの物理 NIC に送信されます。

なし。

VCF-NSX-BGP-REQD-CFG-003

Edge アップリンク トラフィック用の VLAN トランスポート ゾーンを作成します。

Edge ノードの N-VDS で VLAN セグメントの構成を有効にします。

Edge ノードが同じトップオブラック スイッチ ペアに接続されていない場合は、追加の VLAN トランスポート ゾーンが必要になる場合があります。

VCF-NSX-BGP-REQD-CFG-004

Tier-1 ゲートウェイを展開し、Tier-0 ゲートウェイに接続します。

2 層ルーティング アーキテクチャを作成します。

SDN サービスを提供する論理コンポーネントから、物理データセンターと通信する NSX 論理コンポーネントを抽象化します。

Tier-1 ゲートウェイは、単一の Tier-0 ゲートウェイにのみ接続できます。

複数の Tier-0 ゲートウェイが必要な場合は、複数の Tier-1 ゲートウェイを作成する必要があります。

VCF-NSX-BGP-REQD-CFG-005

Tier-1 ゲートウェイを NSX Edge クラスタにデプロイします。

SDDC 管理コンポーネントのステートフル サービス(ロード バランサや NAT など)を有効にします。

Tier-1 ゲートウェイは常にアクティブ/スタンバイ モードで動作するため、ゲートウェイはステートフル サービスをサポートします。

なし。

表 13. VMware Cloud Foundation の NSX マルチラック Edge の可用性のための BGP ルーティング設計の要件

要件 ID

設計の要件

理由

影響

VCF-NSX-MRE-BGP-REQD-CFG-001

Tier-0 ゲートウェイとレイヤー 3 デバイス(リーフ スイッチやアップストリーム デバイスなど)間で ECMP を有効にするには、各ラックの Edge ノードに 2 つの個別のアップリンク VLAN を作成します。

リーフ スイッチまたはレイヤー 3 アップストリーム デバイスは、各ラックの 2 つの VLAN のいずれかに SVI を持ち、ラック内の各 Edge ノードには各 VLAN のインターフェイスがあります。

Tier-0 ゲートウェイで複数の等コスト ルートをサポートし、各ラックにリーフ スイッチのペアを持つ複数のラックにまたがるネットワークでの回復性と帯域幅の使用を強化します。

追加の VLAN が必要です。

VCF-NSX-MRE-BGP-REQD-CFG-002

VLAN セグメントへの名前付きチーミング ポリシーを各ラックのレイヤー 3 デバイス ペアに割り当てます。

各セグメントの VLAN トラフィックをターゲット Edge ノード インターフェイスに固定します。トラフィックは、そこから、ラック内のターゲット リーフ スイッチに接続されているホストの物理 NIC に送信されます。

なし。

表 14. VMware Cloud Foundation でのストレッチ クラスタの BGP ルーティング設計の要件

要件 ID

設計の要件

理由

影響

VCF-NSX-BGP-REQD-CFG-006

アップリンク VLAN をトップオブラック スイッチに拡張して、両方のアベイラビリティ ゾーン間で VLAN が拡張されるようにします。

NSX Edge ノードはアベイラビリティ ゾーン間でフェイルオーバーされるため、 は、NSX Edge ノードが存在するゾーンに関係なく、両方のアベイラビリティ ゾーンのトップオブラック スイッチへのアップリンク接続を確保します。

物理ネットワーク インフラストラクチャを使用して、アベイラビリティ ゾーン間で拡張レイヤー 2 ネットワークを構成する必要があります。

VCF-NSX-BGP-REQD-CFG-007

ラック スイッチの上部にこの SVI 構成を指定します。

  • 2 番目のアベイラビリティ ゾーンで、2 つのアップリンク VLAN のそれぞれに SVI を使用して、トップオブラック スイッチまたはアップストリーム レイヤー 3 デバイスを構成します。

  • 両方のアベイラビリティ ゾーンのトップオブラック スイッチ SVI を、アベイラビリティ ゾーン間の共通の拡張レイヤー 2 ネットワークの一部にします。

同じアップリンク VLAN を介して、両方のアベイラビリティ ゾーンのトップオブラック スイッチへのNSX Edge ノードの通信を有効にします。

物理ネットワーク インフラストラクチャを使用して、アベイラビリティ ゾーン間で拡張レイヤー 2 ネットワークを構成する必要があります。

VCF-NSX-BGP-REQD-CFG-008

次の VLAN 構成を指定します。

  • Tier-0 ゲートウェイとレイヤー 3 デバイス(トップ オブラック スイッチまたはリーフ スイッチ)間の ECMP を有効にするには、2 つの VLAN を使用します。

  • ToR スイッチまたはアップストリーム レイヤー 3 デバイスは、2 つの VLAN のいずれかへの SVI を持ち、各 NSX Edge ノードには各 VLAN へのインターフェイスがあります。

Tier-0 ゲートウェイで複数の等コスト ルートをサポートし、ネットワークでの回復性と帯域幅の使用を強化します。

  • 追加の VLAN が必要です。

  • アベイラビリティ ゾーン間でアップリンク VLAN を拡張する必要があります

VCF-NSX-BGP-REQD-CFG-009

デフォルトの IP プリフィックス リストを使用する代わりに、any ネットワークによるルート アドバタイズへのアクセスを許可する IP プリフィックス リストを作成します。

ルート マップで使用され、2 番目のアベイラビリティ ゾーンの BGP ネイバーの 1 つ以上の自律システム(AS-path プリペンド)へのパスの先頭に追加されます。

デフォルトと同一の IP プリフィックス リストを手動で作成する必要があります。

VCF-NSX-BGP-REQD-CFG-010

カスタム IP プリフィックス リストと、Tier-0 ローカル AS に設定された AS-path プリペンド値を 2 回追加したルート マップアウトを作成します。

  • 2 番目のアベイラビリティ ゾーンのレイヤー 3 デバイスとのネイバー関係を構成するために使用されます。

  • すべての入力方向トラフィックが最初のアベイラビリティ ゾーンを通過することを確認します。

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

2 台のNSX Edge ノードは、最初のアベイラビリティ ゾーンの BGP ネイバーへの接続が失われた場合(たとえば、トップのラック スイッチ ペアまたはアベイラビリティ ゾーンで障害が発生した場合)にのみ、2 番目のアベイラビリティ ゾーンを経由して North-South トラフィックをルーティングします。

VCF-NSX-BGP-REQD-CFG-011

デフォルトの IP プリフィックス リストを使用する代わりに、ネットワーク 0.0.0.0/0 によるルート アドバタイズへのアクセスを許可する IP プリフィックス リストを作成します。

ルート マップで使用され、2 番目のアベイラビリティ ゾーンの BGP ネイバーの学習済みのデフォルト ルートでローカルリファレンスを構成します。

デフォルトと同一の IP プリフィックス リストを手動で作成する必要があります。

VCF-NSX-BGP-REQD-CFG-012

デフォルト ルート 0.0.0.0/0 の IP プリフィックス リストを含むルート マップインを適用し、学習したデフォルト ルートに低いローカルプリファレンス(80 など)を割り当て、学習した任意のルートに低いローカルプリファレンス(90 など)を割り当てます。

  • 2 番目のアベイラビリティ ゾーンのレイヤー 3 デバイスとのネイバー関係を構成するために使用されます。

  • すべての出力方向トラフィックが最初のアベイラビリティ ゾーンを通過することを確認します。

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

2 台のNSX Edge ノードは、最初のアベイラビリティ ゾーンの BGP ネイバーへの接続が失われた場合(たとえば、トップのラック スイッチ ペアまたはアベイラビリティ ゾーンで障害が発生した場合)にのみ、2 番目のアベイラビリティ ゾーンを経由して North-South トラフィックをルーティングします。

VCF-NSX-BGP-REQD-CFG-013

ルート マップを In フィルタと Out フィルタとしてそれぞれ使用するように、2 番目のアベイラビリティ ゾーンのネイバーを設定します。

AS パスが長く、ローカルの設定が低いため、2 番目のアベイラビリティ ゾーンとの間のパスの優先度を下げます。その結果、すべてのトラフィックが最初のゾーンを通過します。

2 台のNSX Edge ノードは、最初のアベイラビリティ ゾーンの BGP ネイバーへの接続が失われた場合(たとえば、トップのラック スイッチ ペアまたはアベイラビリティ ゾーンで障害が発生した場合)にのみ、2 番目のアベイラビリティ ゾーンを経由して North-South トラフィックをルーティングします。

表 15. VMware Cloud Foundation での NSX フェデレーションの BGP ルーティング設計の要件

要件 ID

設計の要件

理由

影響

VCF-NSX-BGP-REQD-CFG-014

Tier-0 ゲートウェイを 2 番目の VMware Cloud Foundation インスタンスに拡張します。

  • NSX Edge クラスタ内のすべてのノードで ECMP North-South ルーティングをサポートします。

  • クロスインスタンス Tier-1 ゲートウェイとクロスインスタンス ネットワーク セグメントのサポートを有効にします。

2 番目のインスタンスに展開された Tier-0 ゲートウェイが削除されます。

VCF-NSX-BGP-REQD-CFG-015

Tier-0 ゲートウェイをすべての VMware Cloud Foundation インスタンスのプライマリとして設定します。

  • NSX フェデレーションでは、Tier-0 ゲートウェイは、接続された Tier-1 ゲートウェイからの出力方向トラフィックをプライマリの場所でのみ許可します。

  • ローカルの入力方向トラフィックと出力方向トラフィックは、Tier-1 レベルで個別に制御されます。Tier-0 ゲートウェイに直接プロビジョニングされるセグメントはありません。

  • 追加の Tier-0 ゲートウェイや Edge ノードを必要とせずに、ネットワーク範囲(VMware Cloud Foundation インスタンスに対してローカルまたは複数のインスタンスにまたがる)の混在が有効になります。

  • VMware Cloud Foundation インスタンスで障害が発生した場合、他のインスタンスのローカル インスタンス ネットワークは、手動による介入なしに引き続き使用できます。

なし。

VCF-NSX-BGP-REQD-CFG-016

グローバル Tier-0 ゲートウェイから、2 番目の VMware Cloud Foundation インスタンスに接続されている、ToR スイッチへの BGP ネイバー ピアリングを確立します。

  • 2 番目の VMware Cloud Foundation インスタンスで、ルートの学習とアドバタイズを有効にします。

  • 1 番目から 2 番目の VMware Cloud Foundation インスタンスへのネットワークの潜在的な自動フェイルオーバーを容易にします。

なし。

VCF-NSX-BGP-REQD-CFG-017

ストレッチ Tier-1 ゲートウェイを使用し、クロスインスタンス ネットワークの Tier-0 ゲートウェイに接続します。

  • VMware Cloud Foundation インスタンス間のネットワーク範囲を有効にします(NSX ネットワーク セグメントは接続先のゲートウェイの範囲に従うため)。

  • 2 層ルーティング アーキテクチャを作成します。

なし。

VCF-NSX-BGP-REQD-CFG-018

VMware Cloud Foundation インスタンスの NSX Edge クラスタを、拡張した Tier-1 ゲートウェイに割り当てます。1 番目の VMware Cloud Foundation インスタンスをプライマリとして設定し、2 番目のインスタンスをセカンダリとして設定します。

  • 1 番目と 2 番目の VMware Cloud Foundation インスタンスの間のクロスインスタンス ネットワーク範囲を有効にします。

  • クロスインスタンス ネットワークの確定的な入力方向トラフィックと出力方向トラフィックを有効にします。

  • VMware Cloud Foundation インスタンスの障害が発生した場合は、Tier-1 トラフィック フローの確定的なフェイルオーバーを有効にします。

  • アクセス不能な VMware Cloud Foundation インスタンスのリカバリ中に、Tier-1 トラフィック フローの確定的なフェイルバックを有効にし、意図しない非対称ルーティングを回避します。

  • 場所の設定とフェイルオーバーに影響する、1 番目と 2 番目の VMware Cloud Foundation インスタンスでの BGP 属性の使用が必要なくなります。

スタンバイ NSX グローバル マネージャからクロスインスタンス ネットワークを手動でフェイルオーバーしてフェイル バックする必要があります。

VCF-NSX-BGP-REQD-CFG-019

VMware Cloud Foundation インスタンスの NSX Edge クラスタを、その VMware Cloud Foundation インスタンスのローカル Tier-1 ゲートウェイに割り当てます。

  • インスタンス固有のネットワークを特定のインスタンスに隔離できるようにします。

  • インスタンス固有のネットワークの入力方向トラフィックと出力方向トラフィックの確定的なフローを有効にします。

ネットワーク サービスの Tier-1 ゲートウェイ用に作成されたサービス ルーターを使用できます。ただし、このような構成はネットワーク接続には必要ありません。

VCF-NSX-BGP-REQD-CFG-020

各ローカル Tier-1 ゲートウェイをそのインスタンスのプライマリとしてのみ設定します。他のインスタンスでは、このゲートウェイをセカンダリとして設定しないでください。

インスタンスの入力方向/出力方向の設定に影響する、プライマリ インスタンスとセカンダリ インスタンスでの BGP 属性の使用が必要なくなります。

なし。

表 16. VMware Cloud Foundation の BGP ルーティング設計の推奨事項

推奨 ID

設計の推奨事項

推奨事項の理由

推奨事項の影響

VCF-NSX-BGP-RCMD-CFG-001

アクティブ/アクティブ Tier-0 ゲートウェイを展開します。

NSX Edge クラスタ内のすべての Edge ノードで ECMP North-South ルーティングをサポートします。

アクティブ/アクティブ Tier-0 ゲートウェイは、NAT などのステートフル サービスを提供できません。

VCF-NSX-BGP-RCMD-CFG-002

トップオブラック スイッチと Tier-0 ゲートウェイの間で、BGP キープ アライブ タイマーを 4 に設定し、ホールド ダウン タイマーを 12 以下に設定します。

トップオブラック スイッチと Tier-0 ゲートウェイ間の障害検出、およびキープアライブ トラフィックによるトップオブラック スイッチへの過負荷との間でバランスを調整します。

ルーターが応答していないかどうかを検出するために長いタイマーを使用すると、このようなルーターに関するデータはルーティング テーブルに長く残ります。その結果、アクティブなルーターは停止しているルーターにトラフィックを送信し続けます。

これらのタイマーは、組織のデータセンター ファブリック設計に合わせて調整する必要があります。

VCF-NSX-BGP-RCMD-CFG-003

BGP ネイバー間でグレースフル リスタートを有効にしないでください。

トラフィックの損失を回避します。

Tier-0 ゲートウェイでは、すべてのゲートウェイからの BGP ピアが常にアクティブになります。グレースフル リスタート機能を有効にすると、フェイルオーバー時に、リモート ネイバーが代替 Tier-0 ゲートウェイを選択するまでに時間がかかります。その結果、BFD ベースのコンバージェンスが遅延します。

なし。

VCF-NSX-BGP-RCMD-CFG-004

BGP ネイバー間のグレースフル リスタート モードでヘルパー モードを有効にします。

トラフィックの損失を回避します。

ルーターの再起動中、ヘルパー モードは、アップストリーム ルーターのグレースフル リスタート機能と連携して、フォワーディング テーブルを維持します。これにより、BGP タイマーが切れた後もダウン ネイバーにパケットが転送され、トラフィックの損失が生じます。

なし。

VCF-NSX-BGP-RCMD-CFG-005

Inter-SR iBGP ルーティングを有効にします。

Edge ノードのすべての North バウンド eBGP セッションが停止している場合、North-South トラフィックは、トラフィックを別の Edge ノードにルーティングすることで引き続き流れます。

なし。

VCF-NSX-BGP-RCMD-CFG-006

非プリエンプティブ フェイルオーバー モードで Tier-1 ゲートウェイを展開します。

障害が発生した NSX Edge トランスポート ノードがオンラインに戻った後、ゲートウェイ サービスを引き継いで、サービスが短時間停止することがないようにします。

なし。

VCF-NSX-BGP-RCMD-CFG-007

Tier-1 ゲートウェイのスタンバイ再配置を有効にします。

Edge で障害が発生した場合に、スタンバイ Tier-1 ゲートウェイが別の Edge ノードで作成されるようにします。

なし。

表 17. VMware Cloud Foundation の NSX フェデレーションに関する BGP ルーティング設計の推奨事項

推奨 ID

設計の推奨事項

理由

影響

VCF-NSX-BGP-RCMD-CFG-008

Tier-1 ゲートウェイを使用して、VMware Cloud Foundation インスタンスで、ネットワークの範囲、および入力方向トラフィックと出力方向トラフィックを制御します。

追加の Tier-0 ゲートウェイや Edge ノードを必要とせずに、ネットワークの範囲(VMware Cloud Foundation インスタンスに隔離されるか、複数のインスタンスにまたがる)の混合が有効になります。

場所の範囲を制御するには、Tier-1 ゲートウェイを Edge クラスタに割り当てる必要があるため、Tier-1 SR コンポーネントがあります。SR を伴う Tier-1 ゲートウェイ間の East-West トラフィックは、Edge ノードを物理的にトラバースする必要があります。

VCF-NSX-BGP-RCMD-CFG-009

インスタンス固有のネットワークの各インスタンスに Tier-1 ゲートウェイを割り当て、拡張した Tier-0 ゲートウェイに接続します。

  • 2 層ルーティング アーキテクチャを作成します。

  • VMware Cloud Foundation インスタンス間にまたがらないローカル インスタンス ネットワークを有効にします。

  • 別の VMware Cloud Foundation インスタンスで障害が発生した場合でも、ローカル インスタンス ネットワークを引き続き使用できるようにします。

なし。

VMware Cloud Foundation のオーバーレイ設計の要素

表 18. VMware Cloud Foundation のオーバーレイ設計の要件

要件 ID

設計の要件

理由

影響

VCF-NSX-OVERLAY-REQD-CFG-001

ワークロード ドメイン内のすべての ESXi ホストを NSX のトランスポート ノードとして構成します。

分散ルーティング、論理セグメント、分散ファイアウォールを有効にします。

なし。

VCF-NSX-OVERLAY-REQD-CFG-002

トランスポート ノード プロファイルを使用して、各 ESXi ホストをトランスポート ノードとして構成します。

  • ESXi ホストとその上で実行する仮想マシンを NSX オーバーレイおよび VLAN ネットワークに参加できるようにします。

  • トランスポート ノード プロファイルは、クラスタ レベルでのみ適用できます。

なし。

VCF-NSX-OVERLAY-REQD-CFG-003

仮想ネットワーク機能をワークロードに提供するには、NSX Edge ノードと分散ルーティングを備えたオーバーレイ ネットワークを使用します。

  • 隔離されたマルチテナント ブロードキャスト ドメインをデータセンター ファブリック全体にわたって作成し、物理ネットワークの境界をまたぐ、柔軟性に優れた論理ネットワークを展開します。

  • データセンター ネットワークからレイヤー 2 抽象化を採用することで、高度なデプロイ トポロジを有効にします。

MTU サイズが 1,600 バイト以上のトランスポート ネットワークを構成する必要があります。

VCF-NSX-OVERLAY-REQD-CFG-004

共有 NSX インスタンスを使用して、ワークロード ドメインまたは複数のワークロード ドメインのホストと NSX Edge トランスポート ノードにまたがるすべてのオーバーレイ トラフィックに対して、NSX インスタンスに単一のオーバーレイ トランスポート ゾーンを作成します。

  • サービスと North-South ルーティングのために、オーバーレイ セグメントが NSX Edge ノードに接続されていることを確認します。

  • トランスポート ノードとして構成されているすべての ESXi ホストおよび NSX Edge ノードですべてのセグメントを使用できるようにします。

同じ NSX Manager を共有するすべてのワークロード ドメイン内のすべてのクラスタは、同じオーバーレイ トランスポート ゾーンを共有します。

VCF-NSX-OVERLAY-REQD-CFG-005

ESXi ホスト用の 2 つのアクティブなアップリンクを含む、ロード バランシング ソース チーミング ポリシーを備えたアップリンク プロファイルを作成します。

回復性とパフォーマンスの向上のため、トランスポート ノードとして構成された ESXi ホストで両方の物理 NIC を同時に使用することをサポートします。

なし。

表 19. VMware Cloud Foundation のマルチラック コンピューティング VI ワークロード ドメイン クラスタのオーバーレイ設計の要件

要件 ID

設計の要件

理由

影響

VCF-NSX-L3MR-OVERLAY-REQD-CFG-001

ラックごとに個別のホスト TEP トランスポート VLAN ID を使用して、各ラックのアップリンク プロファイルを作成します。

ホスト TEP トラフィックのトップオブラック スイッチでレイヤー 3 境界を有効にします。

ラックごとに追加のホスト TEP VLAN ID が必要です。

VCF-NSX-L3MR-OVERLAY-REQD-CFG-002

ラックごとにサブネットが割り当てられ、サブネットにゲートウェイが割り当てられたホスト TEP IP アドレス プールをラックごとに作成します。

  • 各ラックのホスト TEP IP アドレス指定を提供します。

  • ホスト TEP トラフィックのトップオブラック スイッチでレイヤー 3 境界を有効にします。

  • ラック間のホスト TEP にルーティング機能を提供します。

ラックごとに追加のサブネットが必要です。

VCF-NSX-L3MR-OVERLAY-REQD-CFG-003

追加のラックに対して NSX ホスト サブトランスポート ノード プロファイルを作成します。

  • ラックごとに NSX ホスト トランスポート ノード構成を有効にします。

なし

表 20. VMware Cloud Foundation のオーバーレイ設計の推奨事項

推奨 ID

設計の推奨事項

理由

影響

VCF-NSX-OVERLAY-RCMD-CFG-001

静的 IP アドレス プールを使用して、ホスト TEP インターフェイスに IP アドレスを割り当てます。

  • ホスト オーバーレイ VLAN の外部 DHCP サーバが不要になります。

  • NSX Manager を使用して、静的 IP アドレス プールの構成を確認できます。

なし。

VCF-NSX-OVERLAY-RCMD-CFG-002

すべてのオーバーレイ セグメントで階層型の 2 層レプリケーションを使用します。

階層型の 2 層レプリケーションは、ホストに異なる TEP サブネットがある場合に、ソース ESXi ホストがトラフィックをレプリケートする ESXi ホストの数が少なくて済むため、より効率的です。これは通常、クラスタが複数の場合に当てはまり、そのシナリオではパフォーマンスが向上します。

なし。

表 21. VMware Cloud Foundation のストレッチ クラスタのオーバーレイ設計の推奨事項

推奨 ID

設計の推奨事項

理由

影響

VCF-NSX-OVERLAY-RCMD-CFG-003

NSX サブトランスポート ノード プロファイルを構成します。

  • 各アベイラビリティ ゾーンのホスト TEP に静的 IP アドレス プールを使用できます。

  • 各アベイラビリティ ゾーンのホスト TEP に 2 つの個別の VLAN を使用する場合、vSphere Lifecycle Manager イメージに基づくクラスタでは、必要に応じて NSX トランスポート ノード プロファイルは接続されたままになります。

  • 両方のアベイラビリティ ゾーンでホスト オーバーレイ VLAN に外部 DHCP サーバを使用する必要はありません。

ホスト トランスポート ノードの構成に対する変更は、vSphere クラスタ レベルで行われます。

VMware Cloud Foundation のアプリケーション仮想ネットワーク設計の要素

表 22. VMware Cloud Foundation のアプリケーション仮想ネットワーク設計の要件

要件 ID

設計の要件

理由

影響

VCF-NSX-AVN-REQD-CFG-001

VMware Aria Suite アプリケーションのコンポーネント、または VMware Cloud Foundation インスタンス間のモビリティを必要とする別のソリューションに対して、1 つのクロスインスタンス NSX セグメントを作成します。

複雑な物理ネットワーク構成なしで、VMware Cloud Foundation の上に、VMware Aria Suite などのソリューションを展開するための環境を準備します。

VMware Aria Suite アプリケーションのコンポーネントは、再構成の必要なく、VMware Cloud Foundation インスタンス間で簡単に移動できる必要があります。

各 NSX セグメントには、一意の IP アドレス空間が必要です。

VCF-NSX-AVN-REQD-CFG-002

VMware Aria Suite アプリケーションのコンポーネント、または特定の VMware Cloud Foundation インスタンスに割り当てられている別のソリューションの 1 つ以上のローカル インスタンス NSX セグメントを作成します。

複雑な物理ネットワーク構成なしで、VMware Cloud Foundation の上に、VMware Aria Suite などのソリューションを展開するための環境を準備します。

各 NSX セグメントには、一意の IP アドレス空間が必要です。

表 23. VMware Cloud Foundation での NSX フェデレーションのアプリケーション仮想ネットワーク設計の要件

要件 ID

設計の要件

理由

影響

VCF-NSX-AVN-REQD-CFG-003

クロスインスタンス NSX セグメントを 2 番目の VMware Cloud Foundation インスタンスに拡張します。

複雑な物理ネットワーク構成なしでワークロード モビリティを有効にします。

VMware Aria Suite アプリケーションのコンポーネントは、再構成の必要なく VMware Cloud Foundation インスタンス間で簡単に移動できる必要があります。

各 NSX セグメントには、一意の IP アドレス空間が必要です。

VCF-NSX-AVN-REQD-CFG-004

VMware Cloud Foundation インスタンスで、追加のローカル インスタンス NSX セグメントを作成します。

複雑な物理ネットワーク構成なしで、VMware Cloud Foundation インスタンス内のワークロード モビリティを有効にします。

VMware Cloud Foundation インスタンスには、その VMware Cloud Foundation インスタンスに隔離されたワークロードをサポートするネットワーク セグメントが必要です。

各 NSX セグメントには、一意の IP アドレス空間が必要です。

VCF-NSX-AVN-REQD-CFG-005

VMware Cloud Foundation インスタンスで、ローカル インスタンス NSX セグメントを、対応するローカル インスタンス Tier-1 ゲートウェイに接続または移行します。

ローカル インスタンス NSX セグメントを必要なサイトでのみ構成します。

ローカル インスタンス セグメントには、個別の Tier-1 ゲートウェイが必要です。

表 24. VMware Cloud Foundation のアプリケーション仮想ネットワーク設計の推奨事項

推奨 ID

設計の推奨事項

理由

影響

VCF-NSX-AVN-RCMD-CFG-001

オーバーレイによってバッキングされた NSX セグメントを使用します。

  • 複数の VMware Cloud Foundation インスタンスについて、デプロイ トポロジへの拡張をサポートします。

  • データセンター ファブリックに必要な VLAN の数を制限します。

オーバーレイでバッキングされた NSX セグメントを使用する際は、データセンター ファブリックと Edge ノード間で、ルーティング(eBGP を推奨)が必要です。

VMware Cloud Foundation のロード バランシング設計の要素

表 25. VMware Cloud Foundation のロード バランシング設計の要件

要件 ID

設計の要件

理由

影響

VCF-NSX-LB-REQD-CFG-001

スタンドアローンの Tier-1 ゲートウェイを展開して、他の管理コンポーネントの高度なステートフル サービス(ロード バランシングなどの)をサポートします。

高度な展開シナリオに対応するため、North-South Tier-1 ゲートウェイ間の非依存性を実現します。

個別の Tier-1 ゲートウェイを追加する必要があります。

VCF-NSX-LB-REQD-CFG-002

アプリケーション仮想ネットワークのロード バランシング サービスを作成する場合は、スタンドアローン Tier-1 ゲートウェイをクロスインスタンス NSX セグメントに接続します。

クロスインスタンス ネットワークに接続されているアプリケーションにロード バランシングを提供します。

ロード バランシングが必要な各ネットワークにゲートウェイを接続する必要があります。

VCF-NSX-LB-REQD-CFG-003

ロード バランサへの接続を提供するために、セグメントのネクスト ホップを Tier-1 ゲートウェイとして、スタンドアローン Tier-1 ゲートウェイ上にデフォルトのスタティック ルートを構成します。

Tier-1 ゲートウェイはスタンドアローンであるため、ルートは自動構成されません。

なし。

表 26. VMware Cloud Foundation での NSX フェデレーションのロード バランシング設計の要件

要件 ID

設計の要件

理由

影響

VCF-NSX-LB-REQD-CFG-004

2 番目の VMware Cloud Foundation インスタンスにスタンドアローン Tier-1 ゲートウェイを展開します。

NSX グローバル オブジェクトとしては現在サポートされていない高度なサービスを必要とするクロスインスタンス ネットワーク上のサービスをサポートするために、2 番目の VMware Cloud Foundation インスタンス用に、コールド スタンバイの非グローバル サービス ルーター インスタンスを提供します。

  • 個別の Tier-1 ゲートウェイを追加する必要があります。

  • サービスは手動で構成し、1 番目と 2 番目の VMware Cloud Foundation インスタンスにある非グローバル サービス ルーター インスタンス間で同期する必要があります。

  • 2 つの VMware Cloud Foundation インスタンス間のネットワーク競合を回避するには、プライマリとスタンバイの両方のネットワーク サービスが同時にアクティブになっていないことを確認します。

VCF-NSX-LB-REQD-CFG-005

2 番目の VMware Cloud Foundation インスタンスにあるスタンドアローン Tier-1 ゲートウェイを、クロスインスタンス NSX セグメントに接続します。

2 番目の VMware Cloud Foundation インスタンスにあるクロスインスタンス ネットワークに接続されているアプリケーションにロード バランシングを提供します。

ロード バランシングが必要な各ネットワークにゲートウェイを接続する必要があります。

VCF-NSX-LB-REQD-CFG-006

ロード バランサへの接続を提供するために、接続先セグメントのネクスト ホップを Tier-1 ゲートウェイとして、2 番目の VMware Cloud Foundation インスタンスにあるスタンドアローン Tier-1 ゲートウェイ上にデフォルトのスタティック ルートを構成します。

Tier-1 ゲートウェイはスタンドアローンであるため、ルートは自動構成されません。

なし。

VCF-NSX-LB-REQD-CFG-007

最初の VMware Cloud Foundation インスタンスにあるロード バランサ インスタンスに加えられた変更が、2 番目のインスタンスにある切断されたロード バランサに手動で適用されるようにするプロセスを確立します。

最初の VMware Cloud Foundation インスタンスで障害が発生した場合に、フェイルオーバー ロード バランサ インスタンスのネットワーク サービスをアクティブ化できるように準備します。

ネットワーク サービスはグローバル オブジェクトとしてサポートされていないため、各 VMware Cloud Foundation インスタンスで手動で構成する必要があります。1 つ目のインスタンスのロード バランサ サービスは接続済みでアクティブになっている必要があり、もう一方のインスタンスのサービスは切断され、非アクティブになっている必要があります。

  • VMware Cloud Foundation インスタンス間の構成が正しくないため、2 番目のインスタンスのロード バランサ サービスが、無効または不完全な構成のままオンラインになる場合があります。

  • VMware Cloud Foundation インスタンスが両方ともオンラインでアクティブな場合、サービス間の競合が発生し、場合によっては停止する可能性があります。

  • 管理者は、ランブックまたは自動プロセスを使用して、構成の変更が各 VMware Cloud Foundation インスタンスで再現されるようにするため、運用方法を確立し、それに沿う要があります。