第2回「VMware環境を複数の論理ネットワークに分割するには」で解説した通り、VMware vCloud Directorはプライベートクラウド基盤を構成するソフトウェアとなり、このソフトウェアの1つの機能としてVXLANも実装されている。

　VMware vCloud Directorは、「vCloud Director Cell」「vCNS（vCloud Network And Security）」「vSphere」の3つのコンポーネントで構成され、それぞれが連携している。ユーザーは、vCloud DirectorのWebポータルからvApp（あるアプリケーションを構成する単一または複数の仮想マシン群）を作成すると、ESXi上に仮想マシン、そして通信に必要なポートグループが作成され、加えて自動的に「vShiled Edge Gateway」と呼ばれる仮想マシンが展開される。このvShiled Edge Gatewayは、クラウド基盤でNAT、ファイアウォール、DHCP、ロードバランサなどの多様なネットワーク機能を提供するためのコンポーネントとなる。

　VXLANの機能はvDS（vNetwork Distributed Switch）の機能の一部としてインストールされ、VXLANの設定はvCNS上で行う。vCNS上で、VXLAN IDとVXLANで使用するマルチキャストアドレスの範囲を設定することで、各ESXi上にはVTEP（VXLAN Tunnel End Point：VXLAN終端ポイント）の役割をするVMkernelが自動生成される。

　VMware vCloud Directorにはネットワークプールという概念があり、vCloud Director 5.1以降では、VXLANに対応したネットワークプール作成機能が実装されている。vCloudを使用するユーザーは、このプールからネットワークリソースを切り出し、「組織ネットワーク」や「vAppネットワーク」と呼ばれる、用途に合わせたネットワークを作成することができる。

　これらのネットワークを作成する際に、vCloud Director はvCNSと連携し、あらかじめ定義したVXLAN IDやマルチキャストアドレスの範囲から自動的に割り当てられた値を元にVXLANを構成することで、レイヤー2ネットワークを提供する。

　vCloudでは、必要とする通信の形態によって3つのネットワークが選択できる。外部と接続を行わない「隔離」、外部ネットワークに直接接続する「直接」、そして、vShiled Edge Gatewayを介し、ファイアウォールやNAT等の機能が使用可能な「経路指定」だ。これは、組織ネットワーク、vAppネットワークともに選択可能である。

　「直接」の場合は、「上位ネットワークとの接続のためにあらかじめ定義されたポートグループに、vAppが直接接続される」というシンプルな構成となる。「経路指定」の場合、ファイアウォールやNATの機能を提供するために、そのネットワークに仮想マシンが接続されると、vShiled Edge Gatewayがデプロイされ、外部ネットワークや組織ネットワークと接続される。

図1 「経路指定」の場合の論理ネットワーク

　「経路指定」の場合のVXLAN動作を説明する。ネットワークプールから新しくVXLANによるレイヤー2ネットワークが払い出され、ESXi上には対象となるポートグループが作成される。そして、デプロイされたvShiled Edge Gatewayはそれぞれのネットワークで使用されているポートグループに接続される。

　図1において、”org-gw”と”vApp-gw”はvShiled Edge Gatewayである。これは、「外部ネットワーク」、「組織ネットワーク」、「vAppネットワーク」の各々のネットワーク間でのNATやファイアウォールなどの機能を提供している論理イメージの例だ。

　このように、VMware vCloud Directorでは、vCNSとの連携によって、VXLANを使用したレイヤー2ネットワークの作成のみならず、複数のネットワークにかかわる機能を提供することができる。

VMware vCloud Directorネットワークの課題

　ただし、VXLANの利用に伴う課題もある。1つは、連載第3回「VXLANとは何か、どう使われていくのか」で触れたように、マルチキャストに対応した物理ネットワークが必要となる点だ。現時点でvCNSだけでは、解決することができない課題ではあるが、Cisco Nexus 1000Vと連携させることにより、後述するCisco Nexus 1000VのユニキャストVXLANを使用できる。このように複数製品の組み合わせにより、マルチキャストに対応した物理ネットワークを必要とすることなく、VXLANを使用することも可能となる。

　もう1点課題がある。通信経路の複雑化だ。各ネットワークはポートグループで管理されており、論理的には図1で示したように、単純な構成で表すことができる。ただし、実際には仮想マシンとvShiled Edge Gatewayが異なるESXiホストにある場合を考慮する必要がある。仮想マシン間の通信は特に課題とはならないが、外部との通信を検討するとどうだろうか。

図2 仮想マシンとvShiled Edge Gatewayが異なるESXiホストにある場合の経路

　図2の場合、vApp内の仮想マシンとvShiled Edge Gatewayが異なるホスト上に展開されている。仮想マシンからのパケットは、組織ネットワークに出ていくために一度VXLANトンネルを通り、vShiled Edge Gatewayが稼働しているホストを経由し、NATされ、ESXi2から外部に転送される。

　このように、ESXiホスト間を行き来する必要が生じるため、帯域の過剰な消費や、サービスのターンアラウンドタイム悪化につながる可能性も考えられる。これはレイヤー2ネットワークのみならず、複数のネットワーク機能を実装しているための課題とも考えられる。

Cisco Nexus 1000Vと、新たに実装されたユニキャストVXLAN

　連載第1回「VMware環境の仮想スイッチはどう進化してきたか」で紹介したように、Ciscoが提供する仮想スイッチとしてCisco Nexus 1000Vがある。Cisco Nexus 1000Vは、バージョン4.2（1）SV1（5.1）からVXLANを実装しており、プライベートクラウドに必要なネットワークの要件である「拡張性」と「迅速性」を仮想スイッチの形で満たしている。さらに、ユニキャストバージョンのVXLAN が新たに実装されており、VXLANの課題であったマルチキャストの点が改善された。

　ここで、新しい実装となるユニキャストバージョンのVXLANの動作について解説する。

　Cisco Nexus 1000Vには2つのコンポーネントがあり、VEM（Virtual Ethernet Module）とVSM（Virtual Supervisor Module）で構成される。

　VEMは、ハイパーバイザーにインストールされるソフトウェアであり、VSMは仮想マシンとして提供される。Ciscoのモジュール型スイッチである「Cisco Catalyst 6500」の構成要素で例えると、スイッチモジュールに当たるのがVEMであり、Supervisor EngineがVSMに当たる。つまり、VSMはVEMをモジュールであるかのように認識するため、コンフィグはVSMに投入する。

図3 ユニキャストVXLAN

　まず前回紹介した、マルチキャストを使ったVXLANを振り返る。図3のVXLAN ID 10001の192.168.1.1が192.168.1.10に通信を行う場合、一番左のホストのVTEPでARPリクエストがマルチキャストアドレスでカプセル化され、マルチキャストルーティングを使い、VXLAN ID 10001が所属している全てのホストに送信される。そして192.168.1.10の仮想マシンがARPリプライを行うが、ARPリプライは、VTEPでユニキャストアドレスのカプセル化が行われる。

　一方、新しく実装されたユニキャストのVXLANでは、VEMがVXLAN ID 10001の所属しているホストのVTEPのIPアドレスを把握しているため、192.168.1.1から192.168.1.10へ通信を行うと、まずARPがユニキャストアドレスでカプセル化され、一番左のホストのVTEPからVXLAN ID 10001が所属している全てのホストのVTEPへ送信される。

　このように仮想マシンが所属しているホストを探すためにマルチキャストは使われず、ARPはVTEPでコピーされ、VXLAN ID 10001が所属している全てのホストに送信される。（現時点では、ARPリクエストを送信するときに、VTEPでコピーが必要なる。）その後の動作は、マルチキャストのVXLANと同様で、ARPリプライは、ARPを送信してきたVTEPにユニキャストアドレスで送信される。

　このように、Nexus 1000Vでは、マルチキャストを使用しないVXLANの通信が可能になったことで、物理ネットワークの設計上の制約を緩和できる。ただし、仮想スイッチである本製品のみでは、プライベートクラウドに要求されるネットワークの「柔軟性」にかかわるロードバランサなどのネットワーク機能を使用することができない。そのため、柔軟性を高めるコンポーネントが、別に用意されている。

将来におけるクラウド基盤のネットワーキング機能

　これまで紹介したように、転送の効率化とクラウドに必要な機能双方を備えるネットワークを提供するという観点が重要となるが、現状の実装では、まだ幾つかの課題も見受けられている。

　本連載の最後のパートとして、これらの課題を解決する将来のテクノロジーを紹介したい。共通しているテーマは、柔軟性や多機能性に加え、転送の効率性も検討している点だ。

　また、以降の内容に関しては、正式リリース前の情報のため、実際には異なる動作となる可能性があることをご了承願いたい。

Cisco DFA（Dynamic Fabric Automation）

　Ciscoの新規テクノロジーとして、DFAと呼ばれる技術が登場する（英語の説明PDFは、こちらをご覧いただきたい）。物理ネットワークはリーフ／スパイン（アクセススイッチとコアスイッチの2階層）構造となるが、ネットワークのプロビジョニング（導入設定）が自動化される。

　具体的には、VMware vCloud Directorを代表とするクラウドオーケストレーションソフトウェアによって仮想マシンをデプロイすると、リーフのCisco Nexus上にテナントごとのVRF （Virtual Routing and Forwarding）が作成される。このVRF内には、VLANおよびデフォルトゲートウェイとなるSVI（Switch Virtual Interface）も作成される。また、テナントが作成したネットワークごとにセグメントIDが付与され、ホスト間ではセグメントIDを使って通信する。

　これによって、VLANは、ホストと上位スイッチ間で閉じられ、VLAN数の制約を受けにくくなる。仮想マシンのIPアドレスは、/32のホストルートとしてBGP（Border Gateway Protocol）で配信され、リーフのCisco Nexusは、どのリーフのCisco Nexusの配下に通信相手がいるかをBGPの経路交換で把握し、通信相手のCisco Nexusへは、FabricPathを使って送信を行う。

　このように、仮想マシンがデプロイされたときには、仮想マシンに必要なネットワークが自動的に作成され、より効率的な転送を実現する。さらに、クラウドオーケストレーションソフトウェアとの連携によって柔軟性も両立する。物理ネットワークの機能・性能を十分に生かしながら、プライベートクラウド環境に必要なネットワークの要素も満たし、柔軟性を提供することが可能だ。

VMware NSX

　現状、多くの企業において、同一メーカーの製品で構成され、さらに、そのメーカーが推奨するトポロジーになっているというネットワーク環境は非常に少ない。このような環境下では、VMware NSXによって、物理ネットワークに依存しない論理ネットワークを構成するという方策も考えられる。

　具体的には、VMware vCloud Directorをはじめとするクラウドオーケストレーションソフトウェアによって仮想マシンを作成すると、コントローラクラスタと連携し、ESX上のvSwitchやゲートウェイコンポーネントに対して命令を出し、必要なネットワーク環境をデプロイする形だ。VMware NSXが提供するネットワーク機能を幾つか挙げる（ただし、リリース時期や機能実装を確約するものではない）。

• L2 over L3トンネル （ユニキャスト）
• 負荷分散機能 （Global Server Load Balancer機能を含む）
• 分散ファイアウォール機能
• VPN（サイト間）

図4 VMware NSXの動作

　このように、従来からのVMwareテクノロジーと同様、仮想マシンがデプロイされたときには、仮想マシンに必要なネットワークが自動作成されることはもちろんのこと、複雑な物理環境に依存せず、柔軟性、多機能性に加え、転送の効率性も実装した新しいアーキテクチャが実装予定となっている。

おわりに

　クラウド基盤のネットワーキング機能は、各メーカーによって実装する切り口は異なるものの、「拡張性」「迅速性」「柔軟性」を満たすために着実に進歩を遂げている。これによって選択肢は広がる一方、ユーザーやインテグレーターにとっては、システム全体として最適な技術を適切に見極めることがさらに重要となる。