NSX-T Edge のポイント

2020年に入り、VMware NSX-Tがこれまで以上に注目されています。また、それには様々な理由があると感じています。主だった要因としては、VMC on AWSに代表されるVMware Cloudに採用されていること、VCFに含まれていること、vSphere 7 with Kubernetesに必須のインフラであること、更改時期を迎えているVDI環境のインターネット分離に必要なこと、などが挙げられるのではないでしょうか。

そして、注目度が高まるにつれ、NSX-Tのキャッチアップを始める方が増えていると感じます。NSX-TはNSX-vを知っていたとしても難しく感じます。なので、少しでも理解が深まるようなポイントを取り上げて解説していきます。今回はNSX-T Edgeです。

私は仕事でVMware製品を拡販していますが、本ブログは所属会社に一切関係ありませんのでご了承ください。ただのエンジニアとして情報をアウトプットし、その結果、誰かの助けになれば嬉しいなというモチベーションで書いてます。

また、本ブログはNSX-T 3.0時点の情報で書かれています。アーキテクチャコンポーネント、単語などの解説は含まれていないため、VMware Docs等で補完していただければと思います。

VMware NSX-T Data Center のドキュメント

 Edge はあくまでリソース

Edgeは仮想マシンとしてvSphere環境にデプロイするか、物理サーバにインストールします。今回は、仮想マシンを想定します。Edgeは関連するサービスを提供するためにCPU、メモリ、ストレージといったリソースが必要なため、仮想ハードウェアでこれらを提供します。あくまでリソースなので、環境の規模や使用するサービスに応じてサイジングが必要となります。

EdgeサイズはSmall、Medium、Large、Extra Largeから選択します。サイジングの目安としては以下のイメージです。

  • Small:ラボやPoc
  • Medium:ハイパーバイザー64台以下の本番環境
  • Large:ハイパーバイザー64台以上の本番環境、または、ロードバランサを使用する場合
  • Extra Large:ロードバランサの負荷が高くリソースがLargeで足りない場合、または、URLフィルタリングやL7ファイアウォールといったアドバンスサービスを使用する場合

リソース要件やサイジングの公式ドキュメントは以下リンク先を参照してご確認ください。

NSX Edge 仮想マシンのシステム要件

実際にTier-0ゲートウェイなどをEdgeにホストする場合、Edgeではなく、Edge Clusterを選択します。Edge Clusterは複数台のEdgeを束ねたオブジェクトです。仮に、Edgeが1台だけであったとしても、Edge Clusterには追加する必要があります。

f:id:kncyd13:20200830221311p:plain

Edgeは物理ネットワークとの接続点

例えば、NSX-Tで自由にオーバーレイネットワークを構築しても、物理ネットワークとの接続点がなければインターネットを含む物理環境とアクセスできません。EdgeはvNICを仮想スイッチに接続することでオーバーレイネットワークと物理ネットワークを繋げます。Edgeには計4つのvNICがあり、それぞれEdge内部のインターフェイスとリンクしています。

詳細については以下リンク先を参照ください。

NSX Edge のネットワーク設定

eth0は管理ネットワークで固定ですが、あとはEdgeが属するトランスポートゾーンで変わります。仮に、Edgeがオーバーレイトランスポートゾーンに属する場合、fp-eth0はOverlay N-VDSにリンクされます。EdgeがVLANトランスポートゾーンに属する場合、fp-eth1はVLAN N-VDSのアップリンクセグメントにリンクされます。そして、冗長構成を目的に、Edgeが物理ネットワークと2つの接続点を持つ場合、fp-eth2もVLAN N-VDSのアップリンクセグメントにリンクされます。冗長化が目的のため、fp-eth1とfp-eth2は異なるVLANに設定します。

f:id:kncyd13:20200830233537p:plain

続いて、2台のEdgeが追加されたEdge Clusterに、Tier-0ゲートウェイをホストした構成のアップリンク接続について考えてみます。Tier-0ゲートウェイの作成では対象となるEdge ClusterとHAモードを選択します。HAモードはActive-Standby、または、Active-Activeを選択でき、それぞれ使用できる機能が異なります。例えば、Active-StandbyならゲートウェイファイアウォールやNATのようなステートフルサービスが使用できる、といった具合です。Active-Standbyで設定した場合、Tier-0ゲートウェイはEdge01とEdge02にそれぞれホストされ、障害発生時にはフェイルオーバーします。

f:id:kncyd13:20200830233600p:plain

Edge TEPの注意点

NSX-Tでオーバーレイネットワークを使用する場合、仮想マシンやコンテナが実行されているホストトランスポートノード(ESXiやKVM)と同じオーバーレイトランスポートゾーンにEdgeを追加する必要があります。これは、物理ネットワークへの接続点を持つEdgeへ、ホストトランスポートノードから通信が到達するために、Geneveカプセル化プロトコルのトンネルエンドポイント(以下TEP)をEdgeに作成する必要があるためです。しかし、Edge TEPのIPアドレスを設定する際には、Edgeのデプロイ場所に依存する問題に注意が必要です。

NSX-Tでは3つのクラスタデザインが紹介されています。検証や学習目的でNSX-T環境を構築する際には、多くの場合、小規模DCデザインのシングルクラスタ構成が採用されるかと思います。

f:id:kncyd13:20200830235815p:plain

シングルクラスタの場合、ホストの台数は少なく、高確率でホストトランスポートノード上にEdgeトランスポートノードをデプロイする構成となります。また、IPアドレスプールもホストトランスポートノードとEdgeトランスポートノードでわざわざ分けるようなことはせず、TEP用と一括りにするかと思います。このような構成で、EdgeのTEPとリンクされているvNICをNSX-Tが管理するVDS 7.0やN-VDSに接続すると、Edge TEPが他のTEPとトンネルを張れない問題が発生します。

f:id:kncyd13:20200831011713p:plain

この問題には3つの回避策があります。1つ目は、中規模DCデザインのようにコンピュートクラスタとEdgeクラスタを分け、ホストトランスポートノード上にEdgeトランスポートノードをデプロイする構成を避けること。2つ目は、ホストTEPとEdge TEPで使用するIPアドレスプールを分け、ホストTEPとEdge TEPを別VLANにすること。3つ目は、Edge TEPがリンクされているfp-eth0を、NSX-Tで管理していない仮想スイッチに接続することです。

偶然にもこの問題は、検証や学習環境の構築時に条件を満たしやすいです。ホスト間はトンネルが張れているにもかかわらず、Edgeとはトンネルが張れない場合、この問題を疑うのが、解決への近道となるかもしれません。

また、この構成に関連するKBも出ています。

VMware Knowledge Base (70745)

KBはEdge TEPがリンクされたvNICを、トランクのポートグループや論理スイッチに接続しないでくださいという内容です。

今回取り上げた問題は設定次第で解決できるものでしたが、このようなトラブルを未然に回避するためにも、コンピュートクラスタとEdgeクラスタは分けた方が良さそうです。

 さいごに

今回はNSX-T Edgeについて、ドキュメントだけではイメージしづらい内容や、私が検証環境を構築した際に直面した問題を取り上げてみました。正直、Edge上でホストするサービスの方がより抽象的で理解するのが難しいと思うので、今後の投稿でゆっくりと紐解いていこうと思います。