【Oracle Cloud Infrastructure, OCI】Oracle Cloud VMware Solution (OCVS) にてマルチテナントモデルを構築する

1. 要旨

　OCVS (Oracle Cloud VMware Solution) は、OCI (Oracle Cloud Infrastructure) 上でVMware製品バンドルを利用できるサブスクリプション型サービスで、vSphereやNSXなど管理用コンポーネントへのルート権限をユーザーに付与することや、VLANの利用が可能なことなど、クラウドサービスとしてはユニークな特徴を有しています。
　このような特徴によって、柔軟なネットワーク構成が実現可能です。その最たるものとして、本記事ではマルチテナントモデルを取り扱います。例えば、CSPやホスティングプロバイダーが単一の環境で複数エンドユーザー顧客を収容する用途において非常に有効です。
　このマルチテナントモデルを実装するにあたり、NSX 3.0以降で登場したVRFゲートウェイを利用します。このVRFゲートウェイは、新たなNSX Edgeをデプロイすることなく、NSXのオーバーレイ・セグメントを分離することができます。
　本記事は、OCIブログ『Achieve multitenancy within Oracle Cloud VMware Solution using VRF gateways in NSX-T』に提示された手順に沿って実際に構築を行っていき、要所要所でポイントの確認や解説を行ったものになります。OCVSの使用感をイメージするための一助としてお役立てください。

2. 注意点

• 投稿内容は個人の見解であり、所属組織とは関係ありません
• 筆者はOCIを主な守備範囲にしており、VMware製品に関する記述には不正確な点を含む可能性がございますが、ご容赦願います
• 本記事の内容はあくまで検証結果をもとにOCVSのユースケースを論じるものとご認識ください。実案件における構成の策定や構築時において、本記事の内容を参考にしたことに起因する瑕疵への責任は負いかねます
• 途中でスクリーンショットを差し替えた部分があり、前後の設定値に機微な齟齬がある箇所もございますが、適当に読み替えていただければと思います

3. 前章：ネットワーク構成の解説

　本編の構築ログに入る前に、構築するネットワーク構成について解説します。SDDC作成の段階でNSX Edge Uplink1 VLANとそこに接続するTier-0ゲートウェイがデフォルトで作成されますが、今回、その隣に新たなVLANとそこに接続するVRF Uplink1 VLANを作成し、セグメント分離を実現します（図）。OCVSやOCIを初見の方にも理解いただけるよう、OCIの基礎的な部分からゴールとなるネットワーク構成にかけて順に解説します。

3-1. VCN (Virtual Cloud Network, 仮想クラウドネットワーク) の構成とVLANの理解

　OCIでは仮想クラウドネットワークをVCNというサービスで提供しています（AWSのVPCやAzureのVNetに相当します）。各コンポーネントの概要についてはOCIチュートリアル等に解説を譲りますが、CIDR範囲を指定し（一つのVCNで飛び飛びの複数のCIDRを指定可能）、その中からサブネットを作成し、コンピュート・インスタンスやロードバランサなどのサービスを展開します。
　このサブネットに加え、VCNの大きな特徴として、OCVSの利用に限ってVLANを作成して利用することができます。クラウドネットワークは通常、Layer3（IPルーティング）の通信を想定して設計されていますが、OCIのVLANではブロードキャストなどのLayer2の通信もサポートしています。これによって、コンピュート・インスタンスなどのOCIコンポーネントと同一のVNCにVMwareコンポーネントを展開できます（今回は通信のテスト用に10.16.33.0/28のサブネットにWindows Serverコンピュート・インスタンスを配置しました）。
　サブネットやESXiホスト、VLANなどのインフラ基盤はOCIの範疇で、この基盤の上にVMware製品を展開していきます。

3-2. OCVSをデプロイしたタイミングで作成されるコンポーネント

　OCVSのSDDCはデフォルトでNSXワークロード・セグメントを利用できるように構成されます。本記事における内容に関連するものを列挙します（一部省略あり）。

• NSX Edge Uplink1 VLAN
• サブネットとESXiホスト（通常は3台構成が最小ですが、検証用途では単一ノードが利用できます）
  • ESXiホストはサブネットとNSX Edge Uplink1 VLANにVNICで接続しています（図中、赤色の線）
• Tier-0ゲートウェイとOCI側の外部アクセスポイント
• Tier-0ゲートウェイに接続するTier-1ゲートウェイ
• Tier-1ゲートウェイに接続するNSXオーバーレイセグメント

　ポイントは、OCIのVCNとNSXのオーバーレイのセグメントがNSX Edge Uplink1 VLANを介して接続していることです。ここを境に、Tier-0ゲートウェイなどのVMwareのコンポーネントはNSX Managerコンソールで管理することになります。NSX Managerについても、ユーザーに管理者権限が付与されているので、このデフォルト構成を参考に二個目、三個目のTier-1ゲートウェイやNSXセグメントを自由に追加することができます。ただ、NSXセグメント間を明確に分離するためにTier-0ゲートウェイを作成したい場合、新たなNSX Edgeを増設する必要があり手間とライセンスコストがかかるため（NSX-T VRFの作成 - ネットワークチェンジニアとして）、NSX Edgeを増設せずに要件を満たすためにVRFゲートウェイの利用を検討します。

3-3. 本記事でOCVSに構築するコンポーネント

　本記事では、VRFゲートウェイを追加することでマルチテナントモデルを実装します。とはいえ、OCVSのデフォルトのTier-0ゲートウェイからNSXワークロード・セグメントまでの間の構成から大きく変わる点はなく、注目すべきポイントはTier-0ゲートウェイがVRFゲートウェイに代わることだけです（図の左半分）。新たに作成するコンポーネントについても列挙しておきます（一部省略あり）。

• VRF用Uplink VLAN
• ESXiホストのVNIC
  • ESXiホストのVNICを追加し、新たに作成したUplink VLANに接続します（図中、青色の線）
• VRFゲートウェイとOCI側の外部アクセスポイント
• VRFゲートウェイに接続するTier-1ゲートウェイ
• Tier-1ゲートウェイに接続するNSXオーバーレイセグメント
  

4. 本編：構築ログと解説

　それでは、OCIブログに沿って、環境構築を行っていきます！
NSX Managerにログインして、検証環境の元々のネットワークトポロジーを確認しておきます。上部がOCIのNSX Edge Uplink1 VLAN側でそこからTier-0ゲートウェイ、Tier-1ゲートウェイ、さらにその先のオーバーレイのセグメントが三つ作成されています（うち二つは誰かが作ったのだと思います。共有の検証環境なので悪しからず）。

　セグメントを拡大し、SDDC作成の段階で作成された、デフォルトのworkload1セグメントを確認します（ゲートウェイCIDR10.16.33.129/28が表示されています）。既に仮想マシンが一台配置されています（IPアドレスは.140）。

　現段階ではデフォルトで構成されたedge-ns論理スイッチに設定されているVLAN ID=4069はNSXアップリンク1のVLAN IDに対応しており、VLANタグの付け外しを行っています。

　OCIコンソールからNSX Uplink1 VLANのIDを確認できます（3-2項にて、本記事の内容に影響しないため割愛していましたがUplink1 VLANを含めてデフォルトで10個のVLANが作成されます。これらは主にSDDCの管理用に利用されます）。

　vSphere Clientからも、NSXの分散ポートグループとしてedge-ns論理スイッチを確認できます。

　また、デフォルトで作成されたVLANバッキングのセグメントであるNSX-Edge-VCN-Segmentも確認しておきます。VLAN ID=0が設定されており、既存の構成ではこのセグメントでVLANタグの付け外しは行っておらず、edge-ns論理スイッチにその仕事を担わせています。

　変更前、ワークロード・セグメントとOCIのサブネット間で問題無く疎通できていることを確認しました。まずはクライアントのWindows Server (10.16.44.13) からワークロード・セグメントVM (10.16.33.140) へ。

PS C:\Users\opc> ping 10.16.33.140

Pinging 10.16.33.140 with 32 bytes of data:
Reply from 10.16.33.140: bytes=32 time<1ms TTL=62
Reply from 10.16.33.140: bytes=32 time<1ms TTL=62
Reply from 10.16.33.140: bytes=32 time<1ms TTL=62
Reply from 10.16.33.140: bytes=32 time<1ms TTL=62

Ping statistics for 10.16.33.140:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

　その逆、ワークロード・セグメントVMからクライアントWindows Serverへ。

[opc@vm-workload-1 ~]$ ping -c 3 10.16.33.13
PING 10.16.33.13 (10.16.33.13) 56(84) bytes of data.
64 bytes from 10.16.33.13: icmp_seq=1 ttl=126 time=0.775 ms
64 bytes from 10.16.33.13: icmp_seq=2 ttl=126 time=0.595 ms
64 bytes from 10.16.33.13: icmp_seq=3 ttl=126 time=0.734 ms

--- 10.16.33.13 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2035ms
rtt min/avg/max/mdev = 0.595/0.701/0.775/0.080 ms

　デフォルトではNSX Edge Uplink1 VLAN（VLAN ID=4069）だけがedge-ns論理スイッチを利用していましたが、この後、VRFゲートウェイ専用のVLANを新規に作成することを想定して、edge-nsのVLAN設定をトランクに書き換えます。この操作によりVLAN ID＝4069以外のVLANタグが付いているフレームもedge-ns論理スイッチを素通りするようになります。ただ、edge-nsで特定のVLANタグの付け外しなどの処理ができなくなるので、ブログにもある通り、次の操作を行うまでは通信が通らなくなります。

　最終的な構成では、VLANバッキングの各セグメントにおいてVLANタグの付け外し処理を行うので、NSX-Edge-VCN-SegmenのVLAN設定をNSX Edge Uplink1 VLANの値=4096に設定します。

　これらの変更後、問題無く疎通できていることを確認しました。クライアントWindows Serverからワークロード・セグメントVMへ。

Pinging 10.16.33.140 with 32 bytes of data:
Reply from 10.16.33.140: bytes=32 time<1ms TTL=62
Reply from 10.16.33.140: bytes=32 time<1ms TTL=62
Reply from 10.16.33.140: bytes=32 time<1ms TTL=62
Reply from 10.16.33.140: bytes=32 time<1ms TTL=62

Ping statistics for 10.16.33.140:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

その逆、ワークロード・セグメントVMからクライアントWindows Serverへ。

[opc@vm-workload-1 ~]$ping -c 3 10.16.33.13
PING 10.16.33.13 (10.16.33.13) 56(84) bytes of data.
64 bytes from 10.16.33.13: icmp_seq=1 ttl=126 time=1.30 ms
64 bytes from 10.16.33.13: icmp_seq=2 ttl=126 time=0.661 ms
64 bytes from 10.16.33.13: icmp_seq=3 ttl=126 time=0.672 ms

--- 10.16.33.13 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2030ms
rtt min/avg/max/mdev = 0.661/0.878/1.302/0.300 ms

　VRFを接続するためのアップリンクのVLANを新たに作成してきます！
まずは空いているVLAN IDとVLANゲートウェイCIDRを確認します。VLAN IDは今日の日付である1122が未使用ですね。

　VLAN ID=1122とCIDR=10.16.34.208/28に決定し、ルート表とNSGはNSX Edgeアップリンク1と共用にします。ルート表とNSG (Network Security Group) の概要を記しておきます。

• ルート表
  • VCN CIDRの範囲外へのルートを書きこむことでルーティングを確立できます。特にOCVSにおいては、workload1などNSXセグメントを宛先としたルートを書きこむ必要があります
    • VCN CIDR範囲内についてはデフォルトでルーティングが確立しているため、個別にルートを書きこむ必要はありません
• NSG
  • VLAN内の通信を許可する通信のルールを書きこみます
    • VCNではファイヤーウォールで全ての通信が遮断されているため、NSGに許可したい通信のルールを書きこむ必要があります
    • ちなみに、サブネットに関してはセキュリティ・リストを利用できます（VLANは利用不可です）
      

　VLAN 1122が追加されました！

　このVLANにESXiホストのVNICを接続していきます。OCVSのESXiホストの実体はベアメタルのコンピュート・インスタンスです。これにVNICやボリュームを追加できます。

　このESXiホストのインスタンスにアタッチされたVNICを確認します。このインスタンスはBM.DenseIO.E4.128シェイプで作成されており（物理NICの枚数はシェイプに依って変わります）、物理NICを2枚搭載しています（コンソール上でNIC ０、NIC 1と表示されます）。3章では、簡単に説明するために省略しましたが、実際は一つのプライマリVNICがNIC 0に作成されてサブネットに接続し、複数のセカンダリVNICがVLANごとにNIC 0とNIC 1それぞれに作成され、冗長に接続されています。
　ちなみに、シェイプ名の意味合いですが、BMはベアメタルの意で、DenseIOはNVMe SSD内蔵型のシェイプです。また、E4シリーズはAMD EPYC 7J14プロセッサを搭載しているタイプで、128はコア数を表しています。

　NIC 0にVNICを作成し、接続するVLANには先ほど作成したVRFのアップリンクVLANを指定します。

　NIC 1にもVNICを作成します。接続先は同じくVRFのアップリンクVLANを指定し、接続を冗長化します（繰り返しになりますが、物理NICの枚数はシェイプに依ります）。

　これにてESXiホストはVRF Uplink1 VLANに接続されました！今回は検証用の単一ノードSDDCを利用しているため、ESXiホストのVLANへの接続構成はこれだけで完了ですが、本番用クラスタ構成は最小が3ノードからで、ホストごとに、同様の作業を繰り返します（3ノード構成のクラスタなら合計3回作業を繰り返します）。

　次は外部アクセスを追加していきます。VRFゲートウェイのUplink VLAN側のインターフェースIPアドレスを外部アクセスとして設定することで、OCI側でルート表に書き込むエンティティとして登録できます。コンソールの文言が述べているように、例えばコンピュート・インスタンスが存在するサブネットから、VRFゲートウェイの先のNSXセグメントを宛先とした通信を行うためには、ネクスト・ホップとしてこの外部アクセスに向かうルールをルート表に書き込む必要があります（繰り返しになりますが、NSXワークロード・セグメントはOCIのCIDR範囲外なので、ルート表に明示的にルートを書きこむ必要があります）。

外部アクセスにより、VLANワークロードはサブネット、オンプレミスのホスト、インターネットなど、VLANの外部のリソースと通信できます。プライベートIPがVLANに割り当てられて、VLANへのネットワーク・ルーティングの「次のホップ」が提供されます。インターネット・アクセスが必要な場合、予約済パブリックIPを割り当てることもできます

　今回、外部アクセスへはインターネットを通じて通信しないので「ルート・ターゲットのみ」で作成します。VRF Uplink1 VLANのCIDRである10.16.34.208/28のうち、二つ目のアドレスまでは利用できませんので（二つ目の10.16.34.209にはVLANのゲートウェイがあります）、三つ目の10.16.34.210を設定します。

　外部アクセスも追加できました！これでOCI側の設定は終了です。NSXの設定に入っていきます。

　VRF用のトランスポートゾーンの作成を始めます。まず、デフォルトのトランスポート・ゾーンを確認します。

　空のトランスポートゾーンを作成します。

　トランスポート・ゾーンの作成はできましたが、この時点では、トランスポート・ノードとしてNSX-EdgeのノードやESXiホストが何も属していません。

　作成したトランスポート・ゾーンをホストの持つデフォルト・プロファイルに追加します。まずはESXiホストから設定します。

　Host Switchの設定を編集します。

　先ほど作成したVLAN-TZ-VRFトランスポートゾーンを追加します。

　VLAN-TZ-VRFにホストを属させることができました！

　NSX EdgeノードもVLAN-TZ-VRFトランスポートゾーンに追加します。NSX EdgeノードはSDDC作成の段階で2台作成され、Tier-0, Tier-1ゲートウェイをNSX Edgeは「Nodes」の項目にあります。まずはnsx-edge-01から編集します。

　Edge Switchが二つあるので間違えないように注意したいです。Cluster-oci-w01-vds01はOverlay-TZとVLAN-TZに属しています。

　下にスクロールしてCluster-oci-w01-vds02のトランスポートゾーンに新たに作成したVLAN-TZ-VRFを追加します（元々VLAN-TZ2に属しています）。

　同様にnsx-edge-02も編集します。これにて二つのNSX EdgeノードもVLAN-TZ-VRFに所属させることができました！

　続いて、VRFゲートウェイ用にVLANバッキングのセグメントを作成します（VRF-NSX-Edge-Segmentという名前にしました）。前述の通り、NSX-Edge-VCN-Segmentと共有しているedge-ns論理スイッチはトランク化されており、NSXセグメント側でVLANタグの付け外し処理を行いますので、VLAN ID=1122を設定することがポイントです。

　いよいよ、VRFゲートウェイを作成します！Tier-0 Gatewaysの設定画面から「ADD GATEWAY」のボタンをクリックします。

　VRFを選択します。

　Connect to Tier-0 Gatewayで既存のTier-0ゲートウェイを選択します。

　VRFゲートウェイのインターフェースを作成します。ゲートウェイの実体はNSX Edgeなので、二台のNSX Edgeそれぞれのインターフェースを作成します。そして、それらのインターフェースが接続する先は、先ほど作成したVRF-NSX-Edge-VCN-Segmentです。
※ブログでは指示されていませんが、MTU=9,000で設定しています（OCIのネットワークではジャンボフレームが採用されています）。

　二台とも設定を行いました。

　ちなみに、この時点でVRF-NSX-Edge-VCN-SegmentのPorts/Interfacesの列に2個のインターフェースが表示されます（さっきまでは0でした）。

　「2」のリンクをクリックすると、二つのインターフェースが確認できます。

　さて、再びVRF-Uplink1の設定に戻ります。二つのインターフェースを束ねるHA VIPを設定します。このVIPアドレスはOCIで設定した「外部アクセス」のIPアドレスに一致させます。

　OCI、あるいはOCIの先のインターネットに出ていく際に必要なルートを静的ルートで書き込みます。ネクストホップはVRF Uplink1 VLANのゲートウェイIPである10.16.34.209を指定します。

設定を振り返ります。

　続いて、VRF Gatewayに繋がるTier-1 Gatewayの作成を行います。ポイントは、Linked Tier-0 Gatewayでは作成したVRF Gatewayを選択し、Route Advertisementの設定では、All Static Routes、All DNS Forwarder Routes、All Connected Segments & Service Portsをオンにすることです。

　DHCPサーバーの設定をしておきましょう。このTier-1ゲートウェイに接続するワークロード・セグメントにおいて、仮想マシンのIPアドレスを自動で払い出したり、DNSの情報をクライアントにプッシュするために必要です。Workload-DHCP-Serverというプロファイルがデフォルトで作成されていました。

　オーバーレイのワークロード・セグメントを作っていきます。Gateway CIDRは10.16.33.145/28で設定します（workload2という名前にしました）。

　ワークロード・セグメントにDHCPの設定をしておきます。DHCP TypeはGateway DHCP Serverを設定します。先ほど設定したTier-1ゲートウェイのDHCP設定と連動してIPアドレスの払い出しを行ってくれます。
　また、DNS ServersはUplink1 VLANのゲートウェイを指定しておきます。名前解決はOCIのVCNリゾルバで行います（OCIチュートリアル応用編 -『プライベートDNSを使って名前解決をする』も参考になります）。

　NATのルールを書きこみます。

　改めて、NSX Managerからネットワーク・トポロジーを見てみると、設定が反映されていることが確認できます。

　VRFゲートウェイが正しく構成できていそうです。VRFゲートウェイのアップリンク側はVRF Uplink1 VLANに二個のインターフェースが接続されており、その反対側はTier-1ゲートウェイ、さらにその先にワークロード・セグメントが接続されています。

　トポロジー図の一番右端に表現されているのがVRF-NSX-Edge-VCN-Segmentで、このセグメントがVLAN Backedなセグメントとして1122番のVLANタグの処理を行っています。

　vSphere Client側から仮想マシンをworkload2セグメントに接続してPower Onします。

　仮想マシンが接続されたことをトポロジーから確認できます。

　ウェブコンソールから仮想マシンに入り、設定を確認すると、DHCPが機能してens192インターフェースにIPアドレスが適切に割り当たっています（10.16.33.146が割り当たったようです）。これでクライアントのWindows ServerからSSHで接続できるはず。

　また、DNS Serverの設定もできていることを確認しました。

[opc@vm-workload2 ~]$ cat /etc/resolv.conf
# Generated by NetworkManager
nameserver 10.16.34.209

　workload2セグメントの仮想マシンからクライアントWindows Serverへ疎通確認をしました。

[opc@vm-workload2 ~]$ ping -c 3 10.16.33.13
PING 10.16.33.13 (10.16.33.13) 56(84) bytes of data.
64 bytes from 10.16.33.13: icmp_seq=1 ttl=126 time=0.698 ms
64 bytes from 10.16.33.13: icmp_seq=2 ttl=126 time=0.614 ms
64 bytes from 10.16.33.13: icmp_seq=3 ttl=126 time=0.602 ms

--- 10.16.33.13 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2069ms
rtt min/avg/max/mdev = 0.602/0.638/0.698/0.042 ms

　その逆、クライアントWindows Serverからworkload2セグメントの仮想マシンへ疎通確認をします。

PS C:\Users\opc> ping 10.16.33.146

Pinging 10.16.33.146 with 32 bytes of data:
Reply from 10.16.33.146: bytes=32 time<1ms TTL=62
Reply from 10.16.33.146: bytes=32 time<1ms TTL=62
Reply from 10.16.33.146: bytes=32 time<1ms TTL=62
Reply from 10.16.33.146: bytes=32 time<1ms TTL=62

Ping statistics for 10.16.33.146:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

　workload2セグメントの仮想マシンからは、もちろんworkload1の仮想マシンへは通信は通らないです。

[root@vm-workload2 ~]# ping -c 3 10.16.33.140
PING 10.16.33.140 (10.16.33.140) 56(84) bytes of data.

--- 10.16.33.140 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2025ms

　その逆も然り、workload1の仮想マシンからworkload2の仮想マシンへの通信も通らないです。

[opc@vm-workload-1 ~]$ ping -c 5 10.16.33.146
PING 10.16.33.146 (10.16.33.146) 56(84) bytes of data.

--- 10.16.33.146 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4130ms

　OCI側のコンポーネントであるVLANのレベルで通信経路を分離しているので、VLANに紐づくルート表やNSGを明示的に設定しない限りは通信できません。そして、そのルート表やNSGを編集できるのはOCI側で適切な権限を持ったユーザーだけです。OCIのIAMサービスの説明はここでは割愛しますが、コンパートメントやポリシー・ステートメントといったユニークで便利な権限管理の仕組みがあります（OCI技術資料 : IDおよびアクセス管理 (IAM) 概要）。
　
　セグメントが適切に分離できていることは確認できたので、今度は通信ができるように設定をしていきたいと思います！
　NSX Edge Uplink1 VLANとVRF Uplink1 VLANで共有しているルート表にルートを書きこんであげます。具体的には以下のルートを書きこむことでVCN範囲外へのルーティングが行われます（ここでは、VCNからオーバーレイのNSXセグメントへのルーティング）。それに合わせてNSGのイングレスルールも設定します。

• 宛先が10.16.33.128/28のとき、ネクストホップが10.16.34.18
  • VCNからworkload1へ向かうとき、NSX Edge Uplink1 VLAN内の外部アクセスVIPに向かう（そして、外部アクセスVIPはTier-0ゲートウェイのインターフェースのHA IPアドレス）
• 宛先が10.16.33.144/28のとき、ネクストホップが10.16.34.210
  • VCNからworkload2へ向かうとき、VRF Uplink1 VLAN内の外部アクセスVIPに向かう（そして、外部アクセスVIPはVRFゲートウェイのインターフェースのHA IPアドレス）
    

workload1の仮想マシンからworkload2の仮想マシンへ疎通確認とtracerouteをしてみます。

[opc@vm-workload-1 ~]$ ping -c 3 10.16.33.146
PING 10.16.33.146 (10.16.33.146) 56(84) bytes of data.
64 bytes from 10.16.33.146: icmp_seq=1 ttl=60 time=1.17 ms
64 bytes from 10.16.33.146: icmp_seq=2 ttl=60 time=0.861 ms
64 bytes from 10.16.33.146: icmp_seq=3 ttl=60 time=0.884 ms

--- 10.16.33.146 ping statistics ---

[opc@vm-workload-1 ~]$ traceroute 10.16.33.146
traceroute to 10.16.33.146 (10.16.33.146), 30 hops max, 60 byte packets
 1  gateway (10.16.33.129)  0.384 ms  0.343 ms  0.328 ms
 2  100.64.0.0 (100.64.0.0)  0.315 ms  1.692 ms  1.672 ms
 3  10.16.34.211 (10.16.34.211)  1.624 ms  1.603 ms  1.595 ms
 4  100.64.0.3 (100.64.0.3)  1.575 ms  1.554 ms  1.533 ms
 5  10.16.33.146 (10.16.33.146)  1.509 ms !X  1.487 ms !X  1.466 ms !X

　その逆、workload2の仮想マシンからworkload1の仮想マシンへ疎通確認とtracerouteをしてみます。

[root@vm-workload2 ~]# ping -c 3 10.16.33.140
PING 10.16.33.140 (10.16.33.140) 56(84) bytes of data.
64 bytes from 10.16.33.140: icmp_seq=1 ttl=60 time=1.26 ms
64 bytes from 10.16.33.140: icmp_seq=2 ttl=60 time=1.15 ms
64 bytes from 10.16.33.140: icmp_seq=3 ttl=60 time=1.03 ms

--- 10.16.33.140 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 1.034/1.150/1.261/0.100 ms

[root@vm-workload2 ~]# traceroute 10.16.33.140
traceroute to 10.16.33.140 (10.16.33.140), 30 hops max, 60 byte packets
 1  gateway (10.16.33.145)  0.328 ms  1002.196 ms  1002.205 ms
 2  100.64.0.2 (100.64.0.2)  0.252 ms  2.405 ms  2.392 ms
 3  10.16.34.18 (10.16.34.18)  0.978 ms  0.968 ms  0.932 ms
 4  100.64.0.1 (100.64.0.1)  0.990 ms  1.034 ms  0.953 ms
 5  10.16.33.140 (10.16.33.140)  1.338 ms !X  1.323 ms !X  1.304 ms !X

　tracerouteを観察すると、一度、OCIのVLANを経由して通信が行われていることが分かります。tracerouteでworkload2へ向かう通信ではVRFゲートウェイのHA VIP=10.16.34.210が表示されない点だけ気になりますが（workload1へ向かう際はHA VIP=10.16.34.18が利用されています）、それ以外は想定通りの挙動でした。

5. 結論

　OCVSにおいてVRFゲートウェイを用いたマルチテナントモデルを実装し、実際にセグメント間の通信が分離されていることを確認しました。VFRゲートウェイの構築にあたっては、VCNにおけるVLANのサポート、ESXiホスト本体であるコンピュート・インスタンスへの操作権限、NSXやvSphereへのルート権限でのアクセスなど、オンプレミス環境さながらのOCIの自由度の高さを大いに活用しました。OCIのレイヤーにおいては、VLANの作成やESXiホストのVNICの接続、ルート表やNSGの設定など簡単な操作を行うだけでVMware製品を展開するためのインフラを構築することができ、VMware製品のレイヤーにおいては、オンプレミスと全く同じ管理用仮想マシン上での操作によってオーバーレイのネットワークを構築することができました。
　今回は一つのVCNで完結する構成でしたが、この構成を応用し、セグメント間の分離性をより高めた構成を考えることも可能です。新たにVCNとその中のVLANを追加し、それらをESXiホストのVNICの接続先として指定することで、VCNを跨いだマルチテナント構成を実現できます（図中、緑色の線）。

　以上のように、VRFゲートウェイによる通信の分離というテーマ一つをとっても様々な応用を考えることができますが、本記事を通してお伝えしたかったポイントはオンプレミスさながらのOCVSの柔軟性、そして、その柔軟性を活用することによってオンプレミスにおけるVMware構成を踏襲しうるということです。
　ここでは詳説は割愛しますが、例えば、オンプレミスでNSXを利用しておらずOCVSにおいてもNSXの利用を前提としない場合も、vDSを利用したVLAN backingのセグメントを構成することができたり(オラクルへのクラウド移行検討　第4回)、同じVCN内でSDDCのクラスタを分離したりと、オンプレミスの環境をそのままクラウドに持ってきたかのような構成を取ることが可能です。オンプレミスのVMware環境で特殊な構成を採用していて、思いもよらない上手な使い方をしている場合、移行先としてOCVSは要件を満たせるソリューションになりえます。また、OCI IaaSやPaaSとの連携についてはほぼ触れませんでしたが、そこまでを含めて考えると、OCVSにはまだまだ多くの可能性が秘められているはずです。