VMC on AWS のネットワーク – 内部ネットワーク

この記事は Nicolas Vibert 氏のブログ Networking on VMC on AWS - Internal Networking の翻訳です。 翻訳の一覧はこちら。

この短い記事では VMware Cloud on AWS の内部ネットワークの構成と、どのように NSX が活用され構成されているかを説明します。

VMware Cloud on AWS では、2 つの論理的なドメインが存在します。一つは ESXi ホスト、vCenter、NSX マネージャー、NSX コントローラーがデプロイされる “管理リソース”、もう一つはワークロード VM がデプロイされる “コンピュート リソース” です。

VMware Cloud on AWS における NSX

VMware Cloud on AWS のネットワーク設定の全ては、インフラのプロビジョニングの一部として自動化されています。

マネージャー、コントローラーといった全ての NSX コンポーネントは管理リソース プールにデプロイされます。

論理セグメント

VMware Cloud on AWS の管理者は、コンピュート VM がどこのサブネットに配置されるかを決定することができます。

セグメント (論理スイッチあるいは論理ネットワークと呼ばれることもあります) を作成するために、クラウド コンソールまたは API を利用できます。分散仮想スイッチに新しいポートグループを追加することはできないことに注意してください。その代わり新しい論理ネットワークを作成することができます。

仮想マシンに接続する新しいセグメントを作成するには、‘クラウド コンソール / ネットワークとセキュリティ / ネットワーク / セグメント’ と辿ります。

これらのネットワークは、CGW に適切なファイアウォールが設定されていれば CGW を通してインターネットに NAT 越しに接続することができます。CGW から出て行くトラフィックにより発生するデータ転送料金は、VMware Cloud on AWS のアカウントを通じて課金されることに注意していください。

SDDC 内のルーティング ネットワーク間の接続はローカルにルーティングされ、SDDC 内にトラフィックが閉じます。しかし、拡張ネットワークの場合、デフォルト ゲートウェイはオンプレミス側に必ず存在するため、ルーティングさせるためにはトラフィックはオンプレミスのネットワークを経由する必要があります。

分散仮想スイッチ – NSX-V と NSX-T

VMware Cloud on AWS やその内部ネットワーキングに関する様々なドキュメントやブログを思い浮かべると、矛盾する情報を見かけるかもしれません。これらは、初期の VMware Cloud on AWS において ‘NSX for vSphere (NSX-V)’ バージョンを利用している事実に基づいて説明されていますが、現在 VMC の新しいお客様は ‘NSX-T’ ベースとなっているためです。この ‘NSX-T’ は ‘NSX-V’ にはなかった機能を持っています。

VMC のお客様にとってはこれは透過的であるべきではありますが、なぜいくつかのドキュメントに一貫性がないのかを説明します。

以下のいくつかの情報は知る必要のないものかもしれませんが、好奇心を満たすものかもしれません。

VMware Cloud on AWS の NSX-V では、分散仮想スイッチがデプロイされ、論理スイッチ/セグメントは分散仮想スイッチ上に作成されます。分散仮想スイッチに追加のポートグループを作成することはできませんが、新しい論理ネットワークを作成することができます。

VMware Cloud on AWS の NSX-T (2019 年の今ではデフォルトの構成) では、クラウドの vCenter では分散仮想スイッチを見つけることができません。これは、NSX-T の分散仮想スイッチ (N-VDS) が利用されているためです。NSX-T は様々なハイパーバイザー、ベアメタルサーバー、ネイティブ クラウド インスタンスなどにデプロイできるため、NSX-T は NSX-V と同じように vCenter と対になるのではないことを覚えておいてください。

その代わり、(クラウド コンソールで作成された) 論理ネットワークは ‘ネットワーク’ セクションで確認することができます。