VMware NSX Cloud の Overlayネットワーク

NSX Cloud

NSX Cloudはパブリッククラウド(現時点で対応しているのはAWSのUSリージョンのみ)に対して、ネットワークとセキュリティ機能を提供するサービスです。パブリッククラウド内の論理ネットワークを単一の管理画面で管理し、複数のパブリッククラウドに関するネットワーク及びセキュリティに対して共通のAPIを提供します。
NSX Cloudが提供する分散ファイアウォールを利用することにより、パブリッククラウド上のワークロードを保護、隔離することができます。分散ファイアウォールによって実現されるマイクロセグメンテーションセキュリティルールは、インスタンス名、OSタイプ、AMI-ID、ユーザ定義タグを利用してダイナミックに設定することができます。
従来のVMware製品と大きく異なるのは、VMwareのハイパーバイザーを必要としない点と、サービスとして提供される点です。

メリット

• 複数のAWSアカウントを持ち、それぞれのアカウントに複数のVPCが存在する場合、これらを一元的に管理することは困難です。NSX Cloudを利用することにより、単一の管理画面から複数アカウントのVPCを表示し、各VPC内のインスタンスの状態を把握することが可能になります。
• 通常AWS利用者はインスタンス作成時に、適切なセキュリティグループを適用する必要がありますが、NSX Cloudを利用することにより、NSX Cloudの管理者が設計したポリシーを利用者に強制し、利用者はインスタンスの名前やタグによって適切なセキュリティポリシーを選択することが可能になります。
• (将来的に)複数のパブリッククラウドにおけるネットワーク・セキュリティの管理をNSX Cloudが提供する単一のAPI/管理画面から一元的に行い、クラウド毎に異なる管理画面を操作する必要がなくなります。

コンポーネント

NSX Cloudは以下のコンポーネントで構成されます。

• CSM (Cloud Service Manager)
  • AWS環境のインベントリ情報の取得と、AWSのAPIを利用してNSX Managerの設定内容とAWS環境内の構成を同期する。
  • VMwareの所有するVPC内で起動し、NSX Cloudサービスの一部として提供される。
• NSX Manager
  • 論理ネットワークとセキュリティ機能を管理するためのAPIとGUIを提供。
  • VMwareの所有するVPC内で起動し、NSX Cloudサービスの一部として提供される。
• NSX Controller
  • 論理ネットワークとセキュリティ機能に関する状態の管理と制御。
  • VMwareの所有するVPC内で起動し、NSX Cloudサービスの一部として提供される。
  • CCP - Central Control Planeとも呼ばれる
• PCG (Public Cloud Gateway)
  • CSMの管理画面を利用して、NSX Cloudの管理対象となるVPC上にデプロイする。
  • NSX Controllerと通信を行い、論理ネットワーク及びセキュリティ機能に関する状態の管理と制御をVPC単位で提供する。
  • LCP - Local Control Planeとも呼ばれる。
  • Overlay構成を利用する場合、North-Southトラフィックのゲートウェイとして利用され、ルーティングとNATを提供する。
• NSX Cloud Agent
  • AWS上で起動するインタンス(VM)に対してインストールするNSX Cloud向けのモジュール。現時点でUbuntu 14.04とWindows Server 2012に対応。PCGからダウンロードしてインストールする。

利用形態

2種類の利用形態があります。

• Micro Segmentation モード

  • PCGはデータパスではなくローカルコントロールプレーンとして機能
  • NSXの分散ファイアウォール機能によるアプリケーションの分離
  • インスタンスの属性に基づく動的なファイアウォールポリシーの設定
  • ルーティング等のネットワークサービスはAWSのVPC機能を利用

• Overlay モード

  • NSXの分散ファイアウォール機能によるアプリケーションの分離
  • GENEVEカプセル化による論理スイッチへの接続
  • 分散ルーティング
  • Edge Gateway Serviceが以下のサービスを提供
    • OverlayとUnderlayの接続
    • Overlayネットワーク向けのDNAT/SNAT
    • Overlayネットワーク向けのDHCP

使い方の概要

1. NSX Cloudを契約する (CSMとNSX Manager/Controllerがデプロイされ、管理画面にログイン可能になります)
2. AWS管理画面からCloudFormatinoテンプレートを実行してIAMの設定を行う(CSMからAWSを管理するために利用するIAM Roleが作成されます)
3. AWS管理画面からCloudFormatinoテンプレートを実行してVPCを作成する
4. CSMから管理対象のVPCに対してPCGを作成する
   • PCGは3つのサブネットに対してインターフェースを持ちます
   • NSX Cloudで利用されるSecurity GroupがVPCに対して作成されます
5. インスタンスにNSX Cloud Agentをインストールする
6. NSX ManagerにDHCPサーバーを作成し、Logical Switchに接続する (* Overlayモードの場合のみ)
7. 自動的に作成されているTier-0 Routerに対してLogical Switchを接続する (* Overlayモードの場合のみ)
8. インスタンスにnsx:networkタグを適用する
   • Microsegmentation Modeの場合 : nsx:network = default
   • Overlay Modeの場合 : nsx:network = 接続するLogical SwitchのID

設定に利用するCloudFormationテンプレートははNSX Cloudの管理画面からダウンロード可能です。

VPCの構成

CloudFormationテンプレートによって作成されるVPCにはUplink/Downlink/Managentの3種類のサブネットが存在します。デフォルトの状態ではDownlikサブネットはPrivate Route Tableに構成され、インターネットゲートウェイには接続されていないので注意が必要です。

PCGの作成

CSMからVPC上にPCGを作成します。作成時には、PCGを作成するAvailable Zoneを選択し、PCGを接続するUplink/Downlink/Managemntのサブネットを選択します。PCGをHigh Availability構成にする場合、Avalability Zoneを複数指定します。

こんな形でPCGが作成されます。

Overlayモードに関して

Overlayモードでは、Downlinkサブネットに接続されたインスタンス上に、Overlayネットワークが構成され、VPC外とのNorth−SouthトラフィックはPCGによりルーティング/NATされます。
NSX Manager上で、Overlayネットワーク向けにDHCPサービスを提供することで、Overlayモードに参加する各インスタンスはNSX IPが割り当てられ、NSX Cloud Agentのインストールによって設定されるopenvswitchのブリッジとネットワークネームスペース上に設定されます。

NSX Cloud Agentのインストール

Ubuntu 14.04もしくはWindows Server 2012のAMIからインスタンスを作成し、Downlinkサブネットに接続します。踏み台用のインスタンスを用意して、踏み台経由で作成したインスタンスにアクセスし、以下のようにAgentインストール用のスクリプトをダウンロードします。(PCG作成時にRoute53にAレコードとして、nsx-gw.vmware.localがPCGの管理用アドレスとして追加されています。)

ubuntu@ip-10-99-3-248:~$ wget http://nsx-gw.vmware.local:8080/factory_default/trusty_amd64/install_nsx_vm_agent.sh
ubuntu@ip-10-99-3-248:~$ chmod +x install_nsx_vm_agent.sh
ubuntu@ip-10-99-3-248:~$ sudo ./install_nsx_vm_agent.sh

インストールスクリプトによりopenvswitch 2.7等NSX Cloudに必要なパッケージがインストールされます。上記コマンドによりapt-get updateが実行されるため、インストール時はPublic IPが必要になります。

nsx:networkタグの追加

NSX Cloud Agentインストール後、インスタンスをNSXの管理対象とするには、インスタンスに対してnsx:networkタグを付与します。タグの値はOverlay VMを接続する先のLogical Switchに関するNSX Switch Tagの値を指定します。この値はCSM上で確認することができます。(Micro-segmentationモードで利用する場合は、値としてdefaultを指定します)

NSX Switch Tagの確認

インスタンスに対するタグの追加

タグの追加により、インスタンスはNSXの管理対象となり、NSX Manager上で指定したLogical Switchに対して接続されます。Overlay VMの場合はDownlinkサブネット(Underlayネットワーク)で利用されるsshdがポート8888番で起動し、Underlayネットワーク経由ではインスタンスに対してポート22番でsshアクセスができなくなります。

nsxcliによる状態の確認

NSX Cloudの管理下になったインスタンスでは、nsxcliコマンドで状態を確認することができます。

ubuntu@ip-10-99-3-248:~$ sudo nsxcli

ip-10-99-3-248> get gateway connection status
Public Cloud Gateway  : nsx-gw.vmware.local:5555
Connection Status     : **ESTABLISHED**
Connection Time       : Fri Dec 22 05:22:18 2017

ip-10-99-3-248> get vm-network-mode
VM-Network-Mode : **overlay**
Interface       : eth0

インスタンスのネットワーク構成

Overlay VMではインスタンス内でopenvswitch有効になり、Underlay用のveth(nsx-vtep0.0)と、Overlay用のveth(nsx-eth0)がIPアドレスを持ちます。Downlinkサブネット内のインスタンスは、nsx-vtep0.0間でオーバーレイネットワークを利用して通信できるようになります。

ovsの設定

ubuntu@ip-10-99-3-248:~$ sudo ovs-vsctl show
413bddd4-4ec0-4cfc-9958-eb2efa481862
    Manager "unix:/var/run/vmware/nsx-agent/nsxagent_ovsdb.sock"
        is_connected: true
    Bridge nsx-switch
        Controller "unix:/var/run/vmware/nsx-agent/nsxagent_vswitchd.sock"
            is_connected: true
        fail_mode: secure
        Port "eth0"
            Interface "eth0"
        Port "nsx-vtep0.0"
            Interface "nsx-vtep0.0"
                type: internal
        Port nsx-switch-
            Interface nsx-switch-
                type: patch
                options: {peer="nsx-switch+"}
        Port nsx-switch
            Interface nsx-switch
                type: internal
    Bridge nsx-managed
        Controller "unix:/var/run/vmware/nsx-agent/nsxagent_vswitchd.sock"
            is_connected: true
        fail_mode: secure
        Port "nsx-switch+"
            Interface "nsx-switch+"
                type: patch
                options: {peer=nsx-switch-}
        Port nsx-managed
            Interface nsx-managed
                type: internal
        Port "geneve174261036"
            Interface "geneve174261036"
                type: geneve
                options: {csum="true", key=flow, remote_ip="10.99.3.44", tos=inherit}
        Port "geneve174261243"
            Interface "geneve174261243"
                type: geneve
                options: {csum="true", key=flow, remote_ip="10.99.3.251", tos=inherit}
        Port "geneve174261061"
            Interface "geneve174261061"
                type: geneve
                options: {csum="true", key=flow, remote_ip="10.99.3.69", tos=inherit}
        Port "nsx-eth0-peer"
            Interface "nsx-eth0-peer"
    ovs_version: "2.7.0.6814985"

vethのIPアドレス

デフォルトのネットワークネームスペースに、Underlay用のvethとIPアドレスが構成されます。

ubuntu@ip-10-99-3-248:~$ ip a show dev nsx-vtep0.0
6: nsx-vtep0.0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc pfifo_fast state UNKNOWN group default qlen 1000
    link/ether 06:17:1e:54:96:3a brd ff:ff:ff:ff:ff:ff
    inet 10.99.3.248/24 brd 10.99.3.255 scope global nsx-vtep0.0
       valid_lft forever preferred_lft forever
    inet6 fe80::417:1eff:fe54:963a/64 scope link
       valid_lft forever preferred_lft forever

nsx-rootネットワークネームスペースに、Overlay用のvethとDHCPで払い出されたIPアドレスが構成されます。

ubuntu@ip-10-99-3-248:~$ sudo ip netns exec nsx-root ip a show dev nsx-eth0
9: nsx-eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8943 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 06:17:1e:54:96:3a brd ff:ff:ff:ff:ff:ff
    inet 192.168.100.3/24 brd 192.168.100.255 scope global nsx-eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::417:1eff:fe54:963a/64 scope link
       valid_lft forever preferred_lft forever

Overlayネットワークにおける通信

OverlayネットワークのパケットはGeneve(draft-ietf-nvo3-geneve-05)によってカプセル化されて通信が行われます。Underlayネットワークとしては、VPCのサブネット(Downlink)が利用されます。

geneveパケット

インスタンスのnsx-rootネームスペースでパケットをキャプチャすると、送受信されるパケットがgeneveによりカプセル化されていることが確認できます。tcpdumpはgeneveパケットをデコードできるため、アウター/インナーヘッダの内容を確認することができます。
Overlayネットワークでは、分散ルーティングが利用できるため、異なるLogical Switchに接続されたインスタンス同士のL3通信が、Underlayネットワークでルーティングされずに通信できています。

06:26:11.607582 IP (tos 0x0, ttl 64, id 17009, offset 0, flags [DF], proto UDP (17), length 142)
    10.99.3.251.49289 > 10.99.3.248.6081: Geneve, Flags [C], vni 0x238c, options [class VMware (0x104) type 0x80(C) len 8]
	IP (tos 0x0, ttl 63, id 56060, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.99.9 > 192.168.100.3: ICMP echo request, id 7079, seq 938, length 64
06:26:11.607660 IP (tos 0x0, ttl 64, id 22643, offset 0, flags [DF], proto UDP (17), length 142)
    10.99.3.248.666 > 10.99.3.251.6081: Geneve, Flags [C], vni 0x2388, options [class VMware (0x104) type 0x80(C) len 8]
	IP (tos 0x0, ttl 63, id 48220, offset 0, flags [none], proto ICMP (1), length 84)
    192.168.100.3 > 192.168.99.9: ICMP echo reply, id 7079, seq 938, length 64

VPC外部からOverlay VMに対する通信

外部に公開したいインスタンスに対してnsx:publicipタグとしてAWSのElastic IPを割り当てることにより、指定したelastic ipを利用してOverlay VMを公開することが可能です。

2段階のNAT

上記の設定を行うことにより、CSMがEC2/VPCの設定を変更し、nsx:publicipとして指定されたElastic IPはPCGのUplink InterfaceのセカンダリIPに対して有効になります。Elastic IP向けに着信したパケットはPCGのUpliknインターフェースのセカンダリIPアドレスに変換され、PCGに着信します。PCGはセカンダリIP向けに着信したパケットをもう一度NSX IPに変換し、PCG配下にあるインスタンスに対してパケットを転送します。

NSX Manager上のNAT設定

インスタンスに対して、nsx:publicipタグを追加すると、CSMがこれを検出してNSX Managerに対して必要なNATルールを追加します。

まとめ

NSX Cloudを使って、AWS VPC内でオーバーレイネットワークを作成し、インターネットと通信できることを確認できました。
NSX Cloudは主にオンプレ向けに販売されているNSX-Tとほぼ同じバイナリを利用しており、NSX-Tに加えて、CSMを利用することで、パブリッククラウドとの連携を実現しているようです。NSX Managerの管理画面はNSX-Tとほぼおなじ機能を提供し、VPCにデプロイされるPCGはNSX-TのTier-0と同等のものです。将来的にはオンプレも含めて管理できるようになるんじゃないでしょうか。