OCVSにおけるNSX Federation (2026/04/30)
OCVSにおけるNSX Federation (2026/04/30)
https://blogs.oracle.com/cloud-infrastructure/nsx-fed-ocvs
投稿者：Bilal Ahmed | Virtualization Back Belt
はじめに
組織がマルチリージョンおよびハイブリッドクラウドアーキテクチャへと移行するにつれ、拠点間で一貫したネットワークおよびセキュリティポリシーを維持することがますます複雑になります。そこでVMware NSX Federationが強力なソリューションとなります。
NSX Federationを使用すると、顧客はグローバルマネージャを使用して複数のNSX展開（サイト）にわたるネットワークおよびセキュリティポリシーを一元的に管理でき、ローカルマネージャ上でローカルにポリシーが適用されます。
NSX Federationの主な利点は以下のとおりです。
- 中央集権的な政策管理
- サイト全体で一貫したセキュリティ体制
- 災害復旧とモビリティの簡素化
Oracle Cloud VMware Solution (OCVS) において、NSX Federation は特に価値があります。なぜなら、NSX 内のオーバーレイ ネットワークを単一の管理画面から運用制御しながら、ソフトウェア定義ネットワークを複数の SDDC またはリージョンに拡張できるからです。
OCVSでNSXフェデレーションを行う理由とは？
OCVS（VCF BYOLライセンス付き）は、Oracle Cloudインフラストラクチャ上でネイティブに動作するVMware SDDCスタック全体を提供します。NSX Federationと組み合わせることで、以下のことが可能になります。
- 複数リージョンへのアプリケーションデプロイ
- 一貫したネットワーク接続による災害復旧
- 中央集権的なセキュリティポリシーの適用
- SDDC間でのワークロードのモビリティ
NSX環境をそれぞれ個別に構成するのではなく、フェデレーション機能により、ネットワーク構成要素（ティア0、ティア1、セグメント、ファイアウォールルール）を一度定義してグローバルに適用することが可能になります。
そのため、リージョン固有のVLANを使用してネイティブOCIサービスに直接アクセスしたり、NSXオーバーレイセグメントをすべてのVMwareワークロードに使用したりすることで、ビジネスニーズに合わせて柔軟に運用を行うことができます。
NSXフェデレーションのコアコンポーネント
グローバルマネージャー（GM） – ローカルマネージャーと同様に、各サイトに3台の仮想マシン（VM）としてデプロイされます。1つのサイトがプライマリ、残りのサイトはスタンバイとなります。お客様は、SDDCのデプロイ後にOVAファイルからこれらのVMをデプロイする必要があります。
• フェデレーションの制御プレーン
• 次のようなグローバルオブジェクトを定義します。
• Tier-0 / Tier-1 ゲートウェイ
• セグメント
• セキュリティ ポリシー
ローカルマネージャー（LM） – 標準のSDDC展開の一環として、3台のローカルマネージャーが展開されます。
担当業務：
• グローバルマネージャーからプッシュされた構成を実現する
• ローカルでの強制と状態を管理する
NSX Federationの要件
考慮すべき重要な点：
SDDCの展開
これが私たちが目指す最終状態です。
今回の導入では、フランクフルトとアムステルダムにそれぞれ1つずつ、同一のSDDC（ソフトウェア定義データセンター）を2つ導入します。
フランクフルトVCNは172.21.0.0/22を使用しています。
フランクフルトSDDCは172.21.2.0/23を使用しています。
アムステルダムVCNは172.23.0.0/22を使用しています。
アムステルダムSDDCは172.23.0.0/23を使用しています。
SDDCの作成後、各サイトにEdge RTEP用のVLANを1つ追加で作成する必要があります。これにより、エッジノード同士が通信し、サイト間でトラフィックを送信できるようになります。
フランクフルトでは、172.21.3.128/27 VLAN 1407 を使用します。
アムステルダムでは、172.23.3.128/27 VLAN 3909を使用します。
各VLANは独自のルーティングテーブルとネットワークセキュリティグループを持ち、両方のVCNはローカルDRGに接続され、DRGは地域間ルーティングのためにピアリングされます。
これら2つのVLANのルーティングテーブルとネットワークセキュリティグループを調査すると、次のことがわかります。
フランクフルトからは、アムステルダムRTEP CIDRへのDRG路線があります。
ネットワークセキュリティグループ（NSG）には2つのルールがあり、1つはアムステルダムのRTEPからのトラフィックの流入を許可するルール、もう1つはすべての出力を許可するルールです。
アムステルダムからフランクフルトCIDRへのDRGルートがあります。
ネットワークセキュリティグループ（NSG）には2つのルールがあり、1つはアムステルダムのRTEPからのトラフィックの流入を許可するルール、もう1つはすべての出力を許可するルールです。
セキュリティポリシーや要件によっては、これらの設定をより厳しくすることも可能ですが、テスト目的においてはこれらの設定で十分です。詳細については 、 https://ports.broadcom.com/home/NSXを参照してください。
NSXグローバルマネージャーの展開
各SDDCには、SDDCの展開の一環として既に作成されている3つのローカルマネージャーに加えて、3つのグローバルマネージャーを展開する必要があります。
最初のグローバルマネージャは、vCenterにOVA経由でデプロイされます。
マネージャーに必要なサイズを選択してください。
今回展開するネットワークはvSphereネットワークです。
その理由は、SDDC 用の VMware 管理コンポーネントはすべてデフォルトでこのネットワークにデプロイされるため、ローカルマネージャ、グローバルマネージャ、vCenter/ESXi ホスト間の通信が容易になるためです。
重要なのは「グローバルマネージャー」オプションを選択することです。
これにより、OVAファイルからグローバルマネージャーが確実にデプロイされ、別のローカルマネージャーがデプロイされることはありません。
OCVS VLANでは、最初に使用可能なIPアドレスは常にゲートウェイであり、このIPアドレスはDNSとNTPにも使用されることに注意してください。したがって、フランクフルトのvSphere VLANは172.21.3.0/27で、172.21.3.1がゲートウェイです。すべて静的に割り当てられ、DHCPは使用されていないため、使用する未使用のIPアドレスを見つける必要があります。
デプロイと電源投入が完了したら、デプロイ時に指定したユーザー名「admin」とパスワードを使用してグローバルマネージャーにログインしてください。
vCenterをグローバルマネージャにコンピューティングマネージャとして追加します。
これで、グローバルマネージャーインターフェイスの「NSXアプライアンスの追加」オプションを使用して、残りの2つのグローバルマネージャーをデプロイできます。
次に、VIPを設定する必要があります。なぜなら、すべての操作においてこのVIPが参照されるからです。
フランクフルトについては、以下の設定を行いました。
次に、もう一方のサイトでも全く同じ手順を実行してください。
アムステルダムでは、以下の設定を行いました。
NSX Global Managerがアムステルダムにインストールされました
今回のデプロイメントではフランクフルトがプライマリサイトとなるため、アムステルダムのグローバルマネージャーをスタンバイサイトとして追加する必要があります。これはフランクフルトのインターフェースから行い、リモートサイトのグローバルマネージャーにはVIPを使用する必要があります。
この処理が完了すると同期処理が開始され、同期中にいくつか奇妙なエラーメッセージが表示される場合がありますが、これらは数分後には解消されます。
この部分を実行できずエラーが発生する場合は、おそらく両サイトのvSphere VLANにおけるルーティングルールとNSGルールに問題があると考えられます。ルーティングテーブルはDRGへのトラフィックをルーティングできる必要があり、NSGは適切なトラフィックを通過させる必要があります。
フランクフルトのvSphere VLANには、以下のものが含まれています。
アムステルダムOCVS環境へのすべてのトラフィックは、ローカルの分散ルーティングゲートウェイ（DRG）に送信されます。
NSGは、両方のデプロイメントからのすべてのトラフィックへのアクセスと、すべての送信トラフィックの通過を許可するように構成されています。
アムステルダムのvSphere VLANには、以下のものが含まれています。
フランクフルトOCVS環境へのすべてのトラフィックは、ローカルDRGに送られます。
NSGは、両方のデプロイメントからのすべてのトラフィックへのアクセスと、すべての送信トラフィックの通過を許可するように構成されています。
両拠点の現地マネージャーを追加
アクティブなグローバルマネージャー（この場合はフランクフルト）から、両拠点のローカルマネージャーを追加できます。
NSXローカルマネージャクラスタにはVIPを使用する必要があります
プライマリグローバルマネージャーを介して両方のローカルマネージャーセットを追加できます。追加が完了すると、次のようになります。
グローバルマネージャーの場合と同様に、同期処理が行われ、完了までに数分かかる場合があります。その間、時折奇妙なエラーが表示されることがありますが、これは正常な動作であり、想定内のことです。
RTEPの設定
リモートTEP（RTEP）インターフェースは、特定のサイトのエッジクラスタ内の各エッジノードに設定され、拡張ネットワーク機能を実現します。これらのインターフェースは、サイト間通信が必要な場合にのみ必要となります。RTEPは、標準のエッジTEPインターフェースで使用されるVLANとは別のVLAN上に配置する必要があります。現在、各エッジノードは1つのRTEPインターフェースのみをサポートしています。
RTEPの設定後、各エッジノードは他のサイトのエッジノードとフルメッシュのGeneveトンネル（内部トランスポートセグメントとして使用）を形成します。これらのトンネルは、リモートエッジノードの可用性を監視するためのハートビートトラフィックを伝送します。
以前の NSX-T バージョンでは、サイト間通信にハイパーバイザー TEP を使用していましたが、現在はハイパーバイザー TEP はレイヤ 2 拡張のためにサイト間に Geneve トンネルを作成しません。代わりに、サイト間のレイヤ 2 トラフィックはすべて、エッジ ノード上の RTEP 間に確立されたトンネルを介して伝送されます。拡張された各レイヤ 2 セグメントは、RTEP 対応のエッジ ノードにデプロイされた L2 フォワーダー コンポーネントに関連付けられています。この L2 フォワーダーは、設計に応じてアクティブ/スタンバイ モードまたはアクティブ/アクティブ モードのいずれかで動作できます。その結果、RTEP 対応のエッジ ノードが、関連付けられたセグメントのサイト間トラフィック転送を処理します。
各ローカルマネージャで「IPアドレスプール」を選択し、RTEP用のプールを作成します。
フランクフルト向けには、以下のものを作成しました。
以前作成した VLAN が 172.21.3.128/27 であることがわかっているので、172.21.3.130-172.21.3.135 を使用しました。
最初のIPは常にG/Wなので、この場合、最初に使用可能なIPは.130です。
アムステルダム向けには、以下のものを作成しました。
以前作成した VLAN が 172.23.3.128/27 であることがわかっているので、172.23.3.130-172.23.3.135 を使用しました。
最初のIPは常にG/Wなので、最初の使用可能なIPは.130です。
これで設定が完了したので、グローバルマネージャのインターフェースからRTEPを設定できます。
インターフェースから「ネットワーク」オプションを選択してください。
次にウィザード画面が表示され、必要な情報を入力します。
チーミングポリシーとMTUはデフォルトのままで構いません。
両方のサイトでこれを実行してください。
新しく作成されたシステムトランスポートゾーンが正しいスイッチに接続されていることを確認することが重要です。
各ローカルマネージャで、各エッジノードを編集し、新しいシステムトランスポートゾーンがvds02に接続されていることを確認します。
デフォルトではvds01が選択される可能性がありますが、これは誤りです。vds02にはfp-eth1アップリンクがあり、これはすべての南北トラフィックを処理するedge-nsネットワークスイッチに接続されています。
次のステップは、各ローカルマネージャ内のエッジns論理スイッチにRTEP VLANを追加することです。
見つけにくい場合は、検索機能を使って「edge-ns」で検索してください。
フランクフルトの場合、RTEP VLANは1407であることがわかっています。
アムステルダムの場合、RTEP VLANは3909であることがわかっています。
最後のステップは、各ローカルサイトでデフォルトのトランスポートゾーンを設定することです。
Overlay-TZがデフォルトに設定されていることを確認してください。これはOCVSで使用するために設定されている設定です。この設定は両方のサイトで行う必要があります。
これらが追加されると、エッジデバイスは安全な接続を確立し、トラフィックの複製を開始できるようになります。
グローバルT0/T1およびセグメントを作成する際に、以下のいずれかのエラーが発生する場合は、以下の手順に従ってください。
Overlay-TZをデフォルトに設定しなかったことが原因です。
これはセグメント設定で確認できます。
nsx-overlay-transportzoneなどを使用している場合、エッジは正しいトランスポート ゾーンの一部とはならず、データは通過しません。
この時点で全てが緑色になっているはずですので、グローバルT0/T1とセグメントを自由に作成できます。
VMトラフィックフロー
クロスサイトVM通信
同一セグメント内のサイト間で通信する必要のある仮想マシン（VM）の場合、トラフィックはエッジノードを経由する必要があります。なぜなら、エッジノードはネットワークレベルでサイト同士を接続する唯一の方法だからです。
それによって遅延が発生するため、ワークロードの配置場所に関する決定に影響を与える可能性があります。
ゲートウェイアクセス
OCIサービスやインターネットにアクセスする必要のあるVMは、エッジを通過する必要があり、セグメント内の出口ポイントは常に片側にしか存在しません。
アムステルダムのVM Bが10.10.10.1ゲートウェイを経由する必要がある場合、ローカルのNSX Edgeを使用してフランクフルトへ接続し、フランクフルトのエッジがルーティングを行います。VM Aが10.10.10.1ゲートウェイへ接続する必要がある場合、ローカルのNSX Edgeを使用してローカルで接続します。
謝辞
寄稿者：スティーブ・ドッカー（ブロードコム）およびアディール・アミン
コメント
コメントを投稿