NSX 4.2 Federationのレイテンシ要件は何ですか？

NSX Federationは、Global ManagerとLocal Manager間で150ms以下のレイテンシ（RTT）を必要とします。アプリケーションパフォーマンスの低下を避けるためには、延伸されたレイヤー2セグメントで理想的には10ms未満が望ましいです。

Stretched Tier-0 Gatewayを使用すべき理由は何ですか？

Stretched T0はサイト間でのIPモビリティを可能にし、VMがデフォルトゲートウェイを変更することなくサイトAからサイトBへ移動できるようにします。ただし、これは最適ではないルーティングを防ぐために慎重なBGPエンジニアリングを必要とします。

vDefendはNSX 4.2マルチサイトとどのように統合されますか？

vDefendはNSX 4.2でブランド変更され強化されたセキュリティスイートであり、DFW、IDS/IPS、マルウェアプロテクションを含みます。マルチサイト設定では、vDefendポリシーは一貫した適用のためGlobal Managerで管理されます。

2つの異なるデータセンターでアクティブ-アクティブエグレスを持つことはできますか？

はい、可能ですが注意点があります。ヘアピニングを防ぐためには「Local Egress」設定を使用すべきですが、NATやロードバランシングなどのステートフルサービスは、特定のサイトのEdge Clusterに固定される場合があります。

FederationにおけるEdge Nodeの最小サイジングはどれくらいですか？

本番環境のマルチサイト環境では、「Large」Edge VM（8 vCPU、32GB RAM）が、集中的な同期とルーティングのオーバーヘッドを処理するために推奨される最小値です。

NSX 4.2 FederationはSite Recovery Manager (SRM)に取って代わりますか？

NSX Federationはネットワーク接続性とセキュリティポリシーの永続性を提供しますが、VMのパワーオンシーケンスやストレージレプリケーションをオーケストレーションするものではありません。そのためには、やはりSRMまたは同様のツールが必要です。

高度なNSX 4.2マルチサイト設計：Federationとセキュリティの進化

2026年において、マルチサイトネットワーキングは、レガシーなハートビート要件を満たすためのレイヤー2の延伸ではなく、障害ドメインを横断するセキュリティ態勢とステートフルサービスのプログラムによる同期を意味します。VMware NSX 4.2（現在はVCF 5.x/9.xサイクルの一部）では、「事後的なGlobal Manager」から「真の情報源としてのGlobal Manager」への移行が完了しており、もし今でも手動のスクリプトベースの同期を行うサイロ化されたLocal Managerを構築している場合、プライベートクラウドに技術的負債を組み込んでいることになります。

NSX Federation 4.2の進化

NSX Federationは、バグの多かった3.x時代の「Global」オブジェクトから、複数のサイトを単一の論理ファブリックとして扱う堅牢な同期エンジンへと成熟しました。NSX 4.2では、アーキテクチャの軸足はvDefend（旧NSX Distributed Firewall）との統合、そしてGlobal Manager（GM）とLocal Manager（LM）間で大規模なスケーリングを処理する能力にあります。

2026年の標準的な設計では、冗長な2台のGlobal Managerが関与します。これらはデータプレーンから物理的に分離された管理クラスタでホストされるのが理想的です。GMはデータパスには存在しません。GMはコントロールプレーンオーケストレータです。GMがダウンしてもトラフィックは流れ続けますが、セキュリティポリシーの更新やサイト間のルーティング変更を行う能力は失われます。高可用性のために、3ノードのGMクラスタを推奨します。vDefendの高度な脅威防御テレメトリによるオーバーヘッドを処理するため、各ノードに32 vCPUと128GB RAMが必要です。

Tier-0およびTier-1 Gatewayの設計：Stretched vs. Local

NSX 4.2マルチサイト設計における最も重要な決定は、North-South（南北）通信の出口点です。主要なパターンは3つありますが、高性能エンタープライズにとって実行可能なのは2つだけです。

Primary-Secondary Stretched T0: 1つのサイトがすべてのNorth-Southトラフィックに対してアクティブになります。サイトAが故障した場合、BGP再収束によってサイトBが引き継ぎます。これは管理が最も単純ですが、サイトBからの出力トラフィックに対して最適ではない「トロンボーニング」を発生させます。
Active-Active Stretched T0 (All Primary): レイテンシ問題を解決するために導入され、両サイトでのイングレス/エグレスを可能にします。ただし、対称的な戻りパスを確保するために、慎重なBGP操作（AS-Pathプリペンドまたはコミュニティ）が必要です。
Local Egress: T0は各サイトにローカルですが、T1は延伸されます。これは2026年のゴールドスタンダードです。

# 例：NSX CLI経由でのStretched T0におけるBGP設定
set service bgp 65001
set neighbor 10.255.1.1 remote-as 65100
set neighbor 10.255.1.1 route-map PREPEND_OUT out
!
# イングレスに影響を与えるためのセカンダリサイトでのプリペンド
route-map PREPEND_OUT permit 10
 set as-path prepend 65001 65001 65001

BGP-EVPNとStretched VNIの複雑さの終焉

NSX 4.2では、マルチサイト向けのBGP-EVPNの実装が大幅に改善されました。NSXはトランスポートノード（TEP）間で内部的にGENEVEカプセル化を使用しますが、物理コア（Cisco Nexus 9300やArista 7050X3）へのハンドオフは、マルチテナンシーを維持するためにEVPNに依存することがよくあります。4.2では、「ルートサーバー」モードが大規模なFederationのデフォルトになりつつあります。これにより、Global ManagerはRoute Target（RT）およびRoute Distinguisher（RD）の設定を手動の衝突管理なしでLocal Managerにプッシュできます。

これらのサイト間リンク（ISL）を設計する際は、MTUを不足させないでください。GENEVEオーバーヘッド（50バイト）と内部タグ付けを考慮に入れると、最低1700バイトが必要です。プロバイダーのMPLSまたはダークファイバー経由で、1700以上のMTUが提供できない場合、断片化によりNSXのパフォーマンスは低下します。

vDefend (NSX DFW) ポリシー同期

セキュリティは今日のNSX Federationの主要な推進要因です。4.2のvDefendでは、Global Managerを使用してタグに基づいた「Global Security Group」を定義できます。VMがロンドンからニューヨークに（HCXまたはvMotion経由で）移動した場合、env:productionタグがそれに追従し、マイクロセグメンテーションルールはニューヨークのvSphereホストに即座にローカルに適用されます。

ただし、注意点が1つあります。Distributed IDS/IPS（D-IDS/IPS）シグネチャはGMレベルで管理されます。4.2では、16以上のサイト間でシグネチャアップデートの同期頻度が30秒未満に調整されています。「Global-First」ポリシーアプローチを推奨します。「Ring-0」（管理、AD、NTP）および「Ring-1」（本番、開発、テスト）ルールはGMレベルで定義してください。アプリ固有の、サイト固有のルールのみをLocal Managerにプッシュすべきです。

vSphere 8.0u3 + NSX 4.2：ハードウェアアクセラレーションのエッジ

レガシーなBroadwellまたはSkyLake CPUでNSX 4.2を実行することは、ライセンス収益の無駄です。vDefendのサンドボックス化およびNTA（ネットワークトラフィック分析）の全機能を利用するには、NVIDIA BlueField-2やAMD PensandoのようなDPU（Data Processing Unit）を備えたvSphere 8.0u3上にデプロイする必要があります。これにより、TEPカプセル化とDFWルックアップがx86コアからDPU SmartNICにオフロードされます。

マルチサイト設計において、DPUは、延伸されたセグメント全体で集中的なDPI（Deep Packet Inspection）を適用している場合でも、100Gbpsのラインレートスループットを維持できます。DPUがない場合、高負荷環境ではNSXのカプセル化/非カプセル化だけでESXiホストのCPUオーバーヘッドが20～30%増加することが予想されます。

ディザスタリカバリ：SRM vs. NSX Federation

アーキテクトはしばしばNSX FederationをDRオーケストレータと混同します。Federationは配管（IPの可用性とセキュリティポリシー）を提供しますが、Site Recovery Manager（SRM）またはVMware Live Cyber Recovery（VLCR）が自動化を提供します。4.2では統合がより密接になり、SRMがAPIを介して「Global Manager Switchover」をネイティブにトリガーできるようになりました。これにより、プライマリリージョンが壊滅した場合にスタンバイGMをアクティブに昇格させることができます。

これらのレイヤーの統合に関する詳細は、vSphere 8ネットワーキングのディープダイブに関する弊社のガイドを参照してください。目標は、数時間ではなく数分での回復時間目標（RTO）達成であり、これはネットワークがFederationによってセカンダリサイトで既に「ウォームアップ」されている場合にのみ可能です。

Edge Clusterのサイジングとスケーリング

Edge Nodeをケチらないでください。マルチサイト4.2の展開では、LargeまたはX-LargeのEdge VMフォームファクター（8～16 vCPU）を推奨します。NAT、ロードバランシング（AVI）、VPNなどのステートフルサービスを延伸されたT1で使用する場合、それらのサービスはEdge Nodeで実行されなければなりません。4.2では、「Active-Active Site-A/Site-B」T1はローカルエグレスを提供しますが、ステートフルサービスはプライマリサイトに固定されます。T1が延伸されており、その上でステートフルファイアウォールを使用している場合、トラフィックはそのT1の「Active」インスタンスが存在するサイトへヘアピンすることになります。

ファブリックの運用化

マルチサイトNSXファブリックの監視は、vRealize Operations（Aria Operations）だけでは不十分です。サイト間のフローを可視化するために、NSX Intelligence（現在はNSX Manager内のコンテナ化されたサービス）が必要です。4.2では、NSX IntelligenceがFederationを横断できるようになり、サイトAのWebサーバーからサイトBのデータベースへのトラフィックの流れを「神の視点」で把握できます。これを使用しない場合、ローカルな障害時に手探り状態で運用することになります。

これらのライセンス（VCF EnterpriseまたはNSX Advanced/Enterprise Plus）のコストはかなり高く、バンドル時にはCPUソケットあたり5,000ドルを超えることも少なくありません。この投資を無駄にしないよう、GUIがグローバル同期イベント中に必然的に遅延する際に、コントロールプレーンのトラブルシューティングのためにget logical-routersコマンドやget firewall threshold CLIコマンドを使用できるようにチームを訓練してください。

TechLeagueのチームは、Fortune 500企業向けの高可用性NSX展開を専門としています。もし現在の設計がVLANと手動のファイアウォールルールが広がる混乱状態に見えるなら、モダナイズする時です。techleague.ioで弊社のコンサルティングオプションとアーキテクチュラルレビューをご確認ください。