VCF9のNSX VPCでネットワークをセルフサービス化してみる #TGW/中央集中型接続編

こんにちは。ネットワールドSEの藤田です。

先日、ついにVMware Cloud Foundation9.0（以下、VCF9）がリリースされましたね。モダンプライベートクラウドのためのプラットフォームとして多くの機能強化がなされています。情報収集されている方も多いのではないでしょうか。

個人的に気になるアップデートはたくさんありましたが、特に興味を惹かれたのはNSXのVirtual Private Cloud（以下、VPC）の機能強化です。VPCはNSXのマルチテナント機能を支える機能です。VPCによりネットワークの管理をテナントごとに分離し、簡単にセルフサービス化することができます。VCF Automationによる仮想基盤の自動化・セルフサービス化には必須の機能になるでしょう。

そのVPCに突如「Transit Gateway」（以下、TGW）なるものが現れました。え、NSXにTGW、、？AWSのTransit Gatewayが頭をよぎります。いったいこの子は何なの！？と動揺してしまったわけですが、以下のブログに整理された情報がありました。なるほどねぇ、、
blogs.vmware.com

さらにアーキテクチャについて知りたい方は以下の資料が参考になります。
VMware NSX - Application Networking and Security

詳細な解説は上記にお任せし、ここでは実際のオペレーションに即してTransit Gatewayを用いたVPCによるネットワークのセルフサービス化がどのようなものになるか迫ります。
※本記事はVCFの評価モードで確認した結果を報告しています
　そのため、アドオン機能に付随する機能については触れておりません

免責事項
目的
NSX VPCの補足
VPCのオペレーション
まとめ

免責事項

本書は、株式会社ネットワールド（以下弊社）が作成・管理します。
本書の記載内容の一部または全部を弊社に無断で改変・転載することを禁じます。
本書の記載内容は、一部または全部が将来予告無く変更されることがあります。
本書の利用は、利用者様の責任において行われるものとします。
本書の記載内容には、最善の注意を払っておりますが、正確性・完全性を保証するものではありません。従いまして、本書の利用によって生じたあらゆる損害に関して、弊社は一切の責任を負いかねます。

目的

このブログでは、NSX VPCによりネットワークをセルフサービス化することにより、具体的にどのようなオペレーションになるのかご紹介していきます。ロールを分け、それぞれがどのようなオペレーションになるのか確認していきましょう。一連のオペレーションを通し、NSX VPCの理解を深めて頂ければ幸いです。また、最初に見通しを良くするため、NSX VPCについて最低限の補足をしてから始めたいと思います。

NSX VPCの補足

これからNSXのVPCを設定していくわけですが、理解をスムーズにするためにいくつか最初に補足させて頂きます。

VPCを導入すると何ができるのか？

ネットワークの管理は大変ですよね？依頼のある度に対応しなければなりませんし、調整も必要です。設定ミスによる影響が発生してはいけないので、ユーザーに任せるわけにもいきません。

これがAWS、AzureのようなパブリッククラウドのIaaSではどうでしょうか。VPC/VNet単位でネットワークの影響範囲が切り出されているため、ユーザーがその範囲内で責任を持ち運用しているケースも多いのではないでしょうか。

オンプレミスでもこのような運用をしたいですよね。

そこでNSXのVPCです。NSXのVPCは影響範囲を分割し、ユーザーにネットワークの設定を公開することができる機能です。問題が発生しても影響はVPC内に留まるため、管理者はユーザーへネットワーク管理を安心して委任できます。

マルチテナント化した基盤では、セルフサービス化の要望が出てきます。その中でもネットワークのセルフサービス化を支えるのがVPCということになります。

今回はNSX単体でのセルフサービス化についてご紹介します。VCF Automationと組み合わせれば、ネットワークに限らないより包括的な仮想基盤のセルフサービス化が実現できるでしょう。

どのようにNSXのリソースはマルチテナント化されているのか？

セルフサービス化の前に、まずNSXによるマルチテナントはどのようなものか簡単に見てみましょう。まず以下の図をご確認下さい。

VPCを理解するために、まずマルチテナント機能が三階層になっていることをイメージしましょう。

NSX
- NSX全体の設定が含まれる
- エンタープライズ管理者により管理される範囲
Project
- テナントごとのネットワーク設定が含まれる
  - 本記事でテナントと表記する時、このProjectを指しているとお考え下さい
- プロジェクト管理者により管理される各テナントの範囲
VPC
- VPC専用ルーターごとのネットワーク設定が含まれる
- VPC管理者により管理される各VPCの範囲

まずクラウドサービスの基盤を管理するエンタープライズ管理者が存在し、サービス基盤を管理しています。その基盤を切り出してマルチテナントを構成します。切り出された各テナントがPrejctに該当し、プロジェクト管理者により管理されます。さらにそのテナント内で個別に管理したいネットワークをVPCとして切り出し、各VPCのVPC管理者が管理します。

TGWを構成したVPCはどのようなネットワークになるのか？

Transit GatewayはVPCの構成に必須ではありませんが、今回はTGWを前提とした構成をご紹介します。提供形態は二種類あります。

中央集中型接続
- NSX Edgeを構成する接続形態
- NSX Edgeに付随するネットワークサービスを活用することが可能
分散接続
- NSX Edgeを構成しない接続形態
- ESXiホストで完結する分散サービスによりVPC通信を処理

本記事では「中央集中型接続」を前提にご紹介します。「分散接続」も面白い構成なので、こちらは機会を改めてご紹介したいと思います。

「中央集中型接続」は以下のようなネットワークが構成されます。

各階層にルータが配置されます。それぞれの役割を見てみましょう。

Tier-0 Gateway（Provider Gateway）
- 基盤管理者が提供する外部ネットワークへの接続口
Transit Gateway
- テナント（Project）単位でVPC Gatewayを集約するルータ
- 外部接続は持たず、Tier-0 GatewayとVPC Gateway間の接続を提供
VPC Gateway
- VPCごとに構成されるルータ
- 以下のサブネットを配下に構成可能
  - Public
    - Tier-0 Gatewayまで本サブネットの経路情報を保持
  - Private TGW
    - Transit Gatewayまで本サブネットの経路情報を保持
  - Private VPC
    - VPC Gatewayまで本サブネットの経路情報を保持

このように各階層にルータを配置することにより、管理/疎通範囲を分離しています。

VPC Gateway配下のサブネットの違いは、どのルータまで経路情報を保持するか、という伝搬範囲に関わるものです。そのままアクセス可否を決定する設定ではありません。そのため、NATの構成により通信を確保することもできます。

以下は複数のProject、VPCがある場合の伝搬例です。

VCF9で導入されたTransit Gatewayにより、プロバイダ/テナント/VPCのそれぞれの管理区分にルータを配置できるようになりました。従来のTier-0/Tier-1の二階層構成ですと、プロバイダ/テナント単位での分割しかできません。そのため、テナント毎に複数のルータが必要な場合、テナント内通信に工夫が必要でした。Transit Gatewayの導入により柔軟な対応ができそうです。

さて、前置きが長くなりました。設定に移りましょう。

VPCのオペレーション

作成するVPC

今回作成するVPCは以下のようなものです。

エンタープライズ管理者は、僭越ながらこの私が対応させて頂きます。そして順々にプロジェクト管理者である佐藤さん、VPC管理者である鈴木さんと操作を渡していきたいと思います。

ここで重要な点なのですが、Tier-0 Gatewayより上のことを佐藤さんも鈴木さんも知る必要がありません。それは基盤の管理者である私の仕事だからです。AWSやAzureで基盤がどうなっているのか意識する必要がないのと同じです。そのため、ここではVPCの出入口であるTier-0 Gatewayを漠然と記載するに留めます。

Tier-0 Gatewayは構成済みです。ここから設定作業を開始します。それぞれのタスクの概要を確認しましょう。

まずはエンタープライズ管理者の設定から開始しましょう。

エンタープライズ管理者

外部接続

外部接続はテナント内部から外部への接続を抽象化した設定です。

「外部接続」はTransit Gatewayの接続形態を予め定義し、テナント側の構成ミスによる影響を防止することができます。また、Transit Gatewayの種類（中央集中型接続/分散接続）もここで定義します。ここでは必要最小限の設定を行います。

名前
- 任意の名前を指定
タイプ
- 「中央集中型接続」を選択
Tier-0ゲートウェイ
- 構成済みのTier-0を指定

プロジェクトの作成

次にプロジェクトを作成しましょう。テナントごとにプロジェクトは作成します。

画面左上の「Default」→「管理」をクリックします。
ちなみに「Default」もその名の通りデフォルトで用意されているプロジェクトです。明示的にプロジェクトを作成しない場合、すべての設定はこのDefaultに紐づきます。

次に「プロジェクトを追加」をクリックし、以下の値を入力します。その後、「保存」→「閉じる」で設定を完了させます。

名前
- 任意のプロジェクト名前を指定
Transit Gatewayの外部接続
- 作成した外部接続を指定
Edgeクラスタ
- プロジェクトで使用するEdgeクラスタ
外部IPアドレスブロック
- VPC Gateway配下の「Public」サブネットで使用する範囲
  - このサブネットは細分化されて利用されます

プロジェクト管理者への権限付与

次にこのプロジェクトのプロジェクト管理者として佐藤さんに権限付与します。
作成したプロジェクト左側のドットマークより「編集」をクリックします。

[ユーザー/ユーザーグループ]の「設定」をクリックします。

「ロールの割り当ての追加」より追加するユーザーのタイプを選択します。ここではローカルユーザーを選択しました。そしてユーザー名を入力し、[ローカル/範囲]の「設定」をクリックします。

「ロールの追加」をクリックし、[ロール]より「プロジェクト管理者」を選択します。
その後、「追加」→「適用」→「保存」→「閉じる」→「編集を終了」→「閉じる」とクリックを進め、設定を終わらせます。

※今回はローカルユーザーで追加しました。ローカルユーザーはデフォルトで「監査者」のロールが割り当たっているため、こちらは別途削除しています。

現状はここまで構成が完了しています。

さて、ここからは基盤管理者の手から離れ、佐藤さんに管理をお願いしようと思います。私としてはここから先はもう知らんぷりです。

プロジェクト管理者（佐藤さん）

それでは佐藤さんにログインしてもらいましょう。

すると権限を紐づけたプロジェクトへアクセスしていることがわかります。権限を与えられていない「Default」プロジェクトも見えません。佐藤さんはプロジェクトに含まれる範囲での設定が可能です。それではVPCを構成する準備を進めていきましょう。

Transit Gatewayの設定

Transit GatewayはProjectと一緒に作成されていますので、そちらを設定をしていきます。Transit Gateway左側のドットマークより、「編集」をクリックします。

[外部接続]に、作成済みの外部接続を指定します。これにより、VPC側での設定ミスによる外部への影響を防止することができます。「保存」をクリックして設定を完了させます。

VPCプロファイルの作成

まず「VPC接続プロファイル」を作成します。この設定により各VPCに共通な外部接続（Tier-0～TGW）までのネットワーク情報を定義します。この定義により、VPCのユーザーは簡単な操作でネットワークを新規に作成できるようになります。以下の情報を入力します。

名前
- 任意のプロファイル名前を指定
外部IPアドレスブロック
- プロジェクト設定により定義された外部IPアドレスブロックを指定
プライベート - Transit Gateway IP アドレスブロック
- TGWまでルーティング可能なネットワークの範囲を定義
- 「Private TGW」サブネットで利用
Edgeクラスタ
- プロジェクトと同じものを指定

次に「VPCサービスプロファイル」の設定を行います。これはサブネットに対するDHCP設定、また、作成したネットワークの細かな挙動を制御する設定項目です。
ここではDHCPの設定を行いましょう。

名前
- 任意のプロファイル名前を指定
DHCPサーバ構成の有効化
- はい
DNSサーバIP
- DHCPで配布するDNSサーバ情報
NTPサーバのIPアドレス
- DHCPで配布するNTPサーバ情報

VPCの作成

準備ができたので、VPCを作成しましょう。「VPC」→「Virtual Private Cloud」→「VPCの追加」をクリックし、以下を入力します。

名前
- 任意のVPC名前を指定
接続プロファイル
- 作成した接続プロファイル
- 「Public」、「Private TGW」で使用されるサブネット定義が含まれます
サービスプロファイル
- 作成したサービスプロファイル
プライベート - VPC IP CIDR
- VPC Gatewayまで伝搬されるネットワーク
- 「Private VPC」で使用されるサブネット定義です

このまま佐藤さんにVPCを設定してもらってもいいのですが、せっかくなので鈴木さんにバトンタッチしましょう。「いいえ」をクリックし、設定を完了させます。

現状、ここまで用意ができました。

ここでエンタープライズ管理者より、鈴木さんに「VPC管理者」の権限を作成したVPCに対して付与します。先ほどの操作の繰り返しですので、ここでは割愛します。

さて、これで鈴木さんの仕事は終わりです。後のVPC管理は信頼できる鈴木さんへお任せします。

VPC管理者（鈴木さん）

それでは鈴木さんにログインしてもらいましょう。

特定のVPCを管理するだけなので、閲覧できるメニューも最低限です。それではVPCの残りの設定を進めていきましょう。

サブネットの作成

それでは仮想マシンが接続するサブネットを作成しましょう。

編集対象のVPC左側のドットマークより「編集」をクリックします。

「次へ」をクリックします。

[サブネット]の「設定」をクリックします。Public/Private TGW/Private VPCと順番に作成していきましょう。

「サブネットの追加」をクリックし、以下順番に設定し、「保存」をクリックして設定を反映させます。

共通
- 名前
  - 任意のサブネット名
- アクセスモード
  - それぞれ以下を選択する
    - Public : パブリック
    - Private TGW : プライベート - Transit Gateway
    - Public : プライベート - VPC
- ゲートウェイ接続
  - はい
- IP CIDR
  - 自動割当
    - 有効
  - サブネットサイズ
    - 任意のホスト数
      - 指定数量のIPアドレスが利用可能なようにサブネットを切り出します
- DHCPの構成
  - DHCPサーバ
    - サブネットでDHCPサーバが動作し、割り当てられたサブネット内よりIPアドレスを配布します
Public

Private TGW

Private VPC

これでネットワークが完成しました。トポロジを見てましょう。

IPアドレスが動的に払い出されていますね。まとめると以下のようになります。

vCenterサーバからはどう見えるか確認しましょう。VPCがオブジェクトして表示され、その配下のサブネットが表示されていることがわかります。これはオプションで階層表示を有効化しているためで、無効化すると従来のNSXセグメントのように分散仮想スイッチ配下に表示することもできます。

また、今回は新規にプロジェクトを作成しましたが、「Default」プロジェクトであれば、鈴木さんが行った操作をvCenterサーバからも実施することができます。これもまた気になる機能追加ですね。

まとめ

NSXのVPC機能によるセルフサービス化を具体的なオペレーションに即してご紹介しました。今回は説明を一直線にするために、1Project/1VPC構成としましたが、もちろんここからプロジェクトもVPCも拡張してくことが想定されます。ここでは個人で記載していますが、その単位は部署、プロジェクトや企業であったりと様々でしょう。