VMware NSX 4.1.1 以降では、NSX マルチテナントや NSX VPC といった仮想ネットワークをセルフポータルのサービス機能が実装され、プライベートクラウドをセルフサービス化して使いやすくなりました。また、そうしたセルフサービスに NSX Advanced Load Balancer ( NSX ALB ) も連携でき、シームレスで高度なネットワーク・セキュリティ・ロードバランサまでそろったプライベートクラウドが利用できるようになりました。
本ブログでは、 NSX VPC と NSX ALB の連携の動作解説をします。動作概要をざっくりとお伝えすると、このようになります。
NSX VPC ごとのデータプレーンと NSX ALB が連携しており、VPC で NSX ALB が有効化 (詳細は後述) されると、VPC が属している NSX テナント名が NSX ALB コントローラにも同じ名前でテナントが自動作成（下図のオレンジ文字で「テナントの自動作成」と表示される部分）されます。そして、NSX ALB のテナントと連携したVPC の中にデプロイした仮想サービス（VS）は、VPC セグメントで VIP を動作させ、VPC T1 Gateway に VIP 向けの Static Route を追加する動作をします。この T1 Gateway の Static Route を使う動作など連動する部分の多くは、過去ブログで紹介した内容と同じです。本ブログをお読みになる前に、NSX と NSX Advanced Load Balancer の連携を扱った 過去ブログで紹介した内容をじっくりご確認いただくことをお勧めいたします。また、NSX VPC のことを復習されたい方は、こちらのブログをご参照ください。
今回の連携のポイントは、これまでの連携動作が NSX VPC にも対応し、テナント生成も自動化されている部分です。この連携によりテナント生成も自動化され、NSX と NSX ALB でテナント名が同一になるため、NSX と NSX ALB でのテナント管理者も、ネットワーク管理者として同じ 管理者 ID を用いして管理するとより効率的です。この管理者 ID については、次回のブログで扱いたいと思います。
ここまでのお話を図で示すと、以下のようになります。まずは、連携の流れをなんとなく抑えていただけたらと思います。そして、ここから先は深掘りの解説をさせていただき、より実装の理解を深めていただけるようにしております。それでは、 Let’s deep dive！
NSX VPC とNSX ALB との連携動作の相関図
vSphere 環境においては、NSX ALB Controller は vCenter と連動することにより NSX ALB Service Engine（SE）の初期プロビジョニングやスケールアウト、スケールイン時におけるライフサイクル管理とともに、必要に応じた設定投入を自動化します。そして、これに連動する形で NSX Manager と連携し、データセンター内におけるルーティングとセキュリティコンポーネントに対する自動的なメンテナンスを提供します。アプリ開発者がロードバランサの設定を投入したところからを Step 1 とし、連携動作の順序を以下に示します。
NSX
Step 0. NSX VPCを作成し、「NSX Advanced Load Balancer 用に有効化」にチェックを入れる
Step 0. NSX VPC の属する NSX テナント名で NSX ALB テナントが自動作成される
NSX ALB
Step 1. Virtual Serviceを作成 (アプリ開発者）
vCenter/vSphere
Step 2. SE VM イメージ が自動生成され、SE の vNIC が VPC の論理スイッチに自動接続される
Step 3. ESXi 上に SE が自動デプロイされる
NSX
Step 4. VPC T1 Gateway から VIP 宛のルーティング、NSGroups, Servicesが自動作成される
NSX VPC とNSX ALB との 連携動作のトポロジーからの理解
ここまでの流れを、動きのある構成図（トポロジー）で一緒に確認してみましょう。それぞれのコンポーネント間の連携や、ネットワークがどのように自動生成されるかがイメージしやすくなるかと思います。
NSX と NSX ALB の管理インターフェイスを用いた設定ポイント（準備編）
ここからは実際の設定内容を、それぞれの管理インターフェイスの画面サンプルを使って解説していきます。まずは、準備編ということで、前述の Step 0. に関する部分を解説します。
まずは、NSX ALB の管理インターフェイスです。 「クラウド」の作成で NSX-T Cloud の登録をしていきます。以下のように、NSX 4.1.1 以降の NSX Manager を登録します。また、NSX VPC による連携を利用するため、「VPCモードの有効化」にチェックを入れます。
次に、NSX Managerの持つトランスポートゾーンを指定して、管理ネットワークとデータネットワークに利用します。
管理ネットワークは、全てのテナント共通となります。NSX 「Enterprise Admin」 が管理する T1 Gateway とセグメントを指定します。
データネットワークは、NSX VPC 単位での自動登録になります。以下の管理画面にある「データネットワークセグメント」への追加は不要です。NSX VPCとは別の用途で、NSX 「Enterprise Admin」 が管理する T1 Gateway とセグメントをここに追加して、VPCと異なる目的で NSX ALB を併用することもできます。
次に、NSX の管理インターフェイスです。 NSXのNSX VPCを作成し、以下のように「NSX Advanced Load Balancer 用に有効化」にチェックをいれます。
上記のチェックがあることで、NSX ALB ではチェックの入った VPC T1 Gateway が「データネットワークセグメント」に自動登録され、自動作成した SE 専用のオーバーレイセグメント（その T1 Gateway 配下）も自動登録されます。下の管理画面の「データネットワークセグメント」の上３つは、NSX ALB の有効化のチェックの入った VPC によって自動登録されたものになります。
さらに、上記のVPCの自動登録に連動して、NSX ALB ではチェックの入った VPC のテナント名が NSX ALB テナントとして自動登録されます。（以下参照）
ここまでで、NSX VPC と NSX ALB のインフラとしての準備が完了しました。NSXとNSX ALBとで同じテナントが作成されましたので、テナント管理者（NSX Project Admin・NSX ALBテナントAdmin）はLDAPなどを用いで管理者IDを一元管理しておくと便利です。この管理者 ID については、こちらのブログで詳細に触れています。
NSX と NSX ALB の管理インターフェイスを用いた設定ポイント（VS作成編）
ここからはVS作成時の設定内容を、それぞれの管理インターフェイスの画面サンプルを使って解説していきます。前述の Step 1. 以降に関する部分の解説となります。
NSX ALB 管理画面で、VPCが有効になっているテナントでVSを新規作成します。以下のように、テナントで有効になっているVPCがデータネットワーク（VRFコンテキスト）として選択できるようになります。
ここでは、VSを配置したいVPCを選択するようにします。
VRFを選択したら、次はVSに割り当てるVIPの設定を行います。VIPの作成では以下のように、先ほど指定したVPCに紐づいた「クラウド」「VRF」「VPC T1 Gateway」が自動選択されます。
VIPの編集では、以下のようにVIPの自動割り当てが利用できます。「VIPアドレス割り当てネットワーク」で「PUBLIC」を選択するとことで、ここでのVIPアドレスは パブリック（外部）IP アドレスブロックから払い出され、VPC の外部から疎通性のある IP アドレスとなります。
また、このIPアドレスは VPC T1 Gateway に Static Route (/32の Host Route）が自動投入され、デフォルトでは上位の T0 Gateway にこの Host Route が経路広報されるように設定されています。そのため、この T0 Gateway が上位の外部ネットワークにこの Host Route を経路広報し、外部からのVIPへの疎通性を確保するには、T0 Gateway で以下のように T1 Gateway から学習した 「スタティックルート」を「ルート再配布」の設定で有効にしておく必要がありますので、経路制御の設計にはご留意ください。
次に、ロードバランス対象のプールでサーバの選択をします。ここでは、NSXの「セキュリティグループ」が利用できます。この「セキュリティグループ」は、VPCで使われている「グループ」（VPCグループ）のことであり、「VPC Admin」グループとして作成したものがDFWのルールだけでなく、NSX ALBのプールとして利用できます。ここでは、「セキュリティグループ」で「project-red-hr-dev-vpc vms」というVPCグループを選択し、そのグループに属する仮想マシンのIPアドレスが自動登録されています。
この「project-red-hr-dev-vpc vms」というVPCグループは、以下のようにあらかじめ NSX の VPC Admin が作成したグループです。
このVPCグループは、「project-red-hr-dev-vpc-web」のサブネットに属する仮想マシンを自動的にグループ化するダイナミックグルーピングが使われています。グルーピング方法は、設計や運用方針に適した方法をご選択ください。
NSX VPC に関わる VS 作成時の設定内容は以上となります。他のVSとしての設定内容は NSX VPC への依存を意識することなく、様々なNSX ALBの特徴的な設定や機能が利用できます。
ここまでの設定が完了すると、Step1-4までが自動適用され、VIPとしての利用が始まることになります。アプリ管理者がVSの作成をするだけで、システム側では「SEのデプロイ」「VIP Host Routeの経路広報」が自動的に行われ、VIPを外部に公開できます。
実はもう一つ大切なことが
お疲れ様でした。これで無事 NSX VPCでデプロイしたアプリが外部公開されましたね。途中経路のルータでも Host Route は学習できますし、外部からVIPアクセスしてみましょう。
あれ、アクセスできませんね。。
そうでした。 １つ設定で大事なことを忘れていました。セキュリティ設定ですね。VPC にデフォルトで適用されている DFW のルールを思い出してください。詳細は、NSX VPC によるネットワークのテナント分離のブログをご確認ください。VPCは「E-W ファイアーウォール」で以下のようにデフォルトルールで、VPC 内部の仮想マシン間通信は許可、DHCP によるアドレス取得に関わる通信も許可、それ以外の通信はすべてドロップとなっています。これは、VPCをセキュアな状態を維持するために、とても重要なデフォルトルールです。
つまり、外部からのVIPアクセスを「E-W ファイアーウォール」で許可しないといけません。もう少し具体的には、VPC 内部の仮想マシンである SE の VIP が外部からのアクセスされるわけですので、以下のような許可ルールがあるとよいでしょう。
送信元：「任意」
宛先：「VIP アドレス」
適用先： 「SEが含まれるVPCグループ」
「SEが含まれるVPCグループ」は、NSX ALBが有効なVPCであれば、以下のようなVPCグループが自動生成されますので、こちらを利用しても良いでしょう。(グループ名は設定に依存）
これで無事 NSX VPCでデプロイしたアプリが外部公開され、アクセスできるようになりました。
上記の方法以外にも、以下のような SE自体をDFWの除外リストにいれる方法など、より運用に適する他の手段もあると思います。設計段階でよりよい手段をご検討いただけたらと思います。ここでは、皆様の今後の検討のヒントとなれば幸いです。
設定のポイント解説は、以上となります。最後までお付き合いいただき、ありがとうございました。
おまけ
NSX VPC と NSX ALB の連携では、VSの L3 scale out がサポートされています。VPC T1 Gateway の Static Route を利用した ECMP によって、VS の処理を複数のSEに分散させ、VSの処理性能をスケールアウトにより拡張することができます。今回はあえて、5台のSEまでスケールアウトしていましたので、「VPC Admin」が NSX 管理インターフェースからVPC T1 Gateway に５つのStatic Routeが自動投入されているかを確認してみたいと思います。以下は、NSX ALBで 5 台のSEにスケールアウトしたところを確認し、その後 NSX VPC 管理画面で VPC T1 Gateway に５つのStatic Routeが投入された結果を確認しているところです。このように、NSX ALBでスケールアウトを一つ操作するだけで、バックグラウンドでは SE が自動生成され、Static Route が管理されるといった完全に自動化された性能拡張を可能としています。NSX VPCの中で、ロードバランサまで含め、さらに性能拡張まで考慮されたアーキテクチャがすでに揃っています。このように、皆様の次の世代のプライベートクラウドをより高度にセルフサービス化を支援する機能になっていますので、ぜひこうした連携をご活用いただけたらと思います。
さいごに
今回のブログでは、NSX VPCでアプリケーションをデプロイし、NSX ALBで外部公開するプロセスについて詳しく解説しました。特に、VPCのセキュリティ設定とその重要性、そしてE-Wファイアーウォールのデフォルトルールについて触れました。また、NSX VPCとNSX ALBの連携によるVIPの性能拡張についても触れました。VSのL3 scale outがサポートされており、Static Routeによって処理性能をさらに拡張することができ、この機能は次世代のプライベートクラウドにおいても非常に有用なものとなります。
最後に、本ブログが皆様のプライベートクラウドのネットワーク設計や運用に役立つ情報となれば幸いです。本当に、お疲れ様でした。
