Cisco ACIとVMware NSXは競合製品なのか?

本エントリーは 2016年の vExpert Advent Calendar の〆を飾る?最終エントリーとなります。参加されたvExpertな皆さん、お疲れ様でした。年末休暇で暇な皆さま、このAdvent Calendarをはじめとして、多くのAdvent Calendarが面白いネタで25日間に渡ってリレーされていますので、それらをじっくりと読んでみるのも面白いかもしれませんよ。

さて、では vExpert Advent Calendar の最後に、こんなタイトルで 〆てみたいと思います。たまにぶっこみすぎじゃね?と言われることがあるんですが、別に私自身はそんなつもりないんですけれどもね。中の人ではないからこそ書けることがあると思っています。

では、本題。

結論から書いてしまえば、たしかにごく一部の部分においてCisco ACI (Application Centric Infrastructure) とVMware NSXはいってみれば「競合」している部分があるのは事実でしょう。別の会社の、それぞれの会社の戦略の中で開発・買収・提供が行われている製品同士なのですから、それはアタリマエのことです。しかし、私の個人的な見解としては、Cisco ACIとVMware NSXは大半の範囲については異なる位置づけの製品だと思います。言ってみれば、ルータとスイッチぐらいには異なる製品です。ネットワーク製品というくくりでは同じであっても、ルータとスイッチの使われ方や役割は異なることは誰もがおわかりでしょう。ルータにスイッチポートを搭載することができても、スイッチがルーティングの機能を持つようになっても、今でも両方の製品が使われているように、Cisco ACI とVMware NSXは根本的な製品の位置づけが異なると考えています。

本エントリーは、どちらかといえばCisco ACIの視点からみたNSXの位置づけについて考えてみたものとなりますが、世の中にあまりこうした視点でNSXについて書かれた情報はない気がしますので、何か参考になればいいなと思います。

Cisco ACIから見てVMware NSXとは

Cisco ACIから見ると、VMware NSXは数多くある管理対象として扱うことができるアプリケーションの1つです。つまり、VMware ESXiホスト上の仮想マシンに対して様々なサービスを提供するアプリケーションです。Cisco ACIとVMware NSXはお互いサポート対象ではありませんよね?と言われることがありますが、Windows上で動作するアプリケーションが、そのWindows自身の動作環境となっているハードウェアのベンダーに制約要件を持たない*1ように、NSXというネットワークを使ったアプリケーションをACIがサポートする・しないという制約条件はありません。

Cisco ACIは主にサーバが配置されるデータセンター向けのネットワークファブリックを基盤としたソリューションです。先日のエントリーでも書きましたが、Cisco ACIは連携する・しないはさておき、IPプロトコルを用いた通信である限り*2、あらゆる機器からのあらゆる通信に対応します。UNIXからの通信であっても、物理サーバからの通信であっても、そしてNSXからの通信であっても、そこに区別はありません。

割り切った書き方をすると誤解を生じる可能性があるので難しいのですが、Cisco ACIはネットワークファブリックとSDNを融合したソリューションです。対して、VMware NSXはSDNとNFVを融合したソリューションといえます。SDN部分で一部重なっている機能がありますが、ACIはNFV的な機能は自身では提供していませんし、NSXはすべてをソフトウェアだけで実現するためにネットワークファブリックは自身で提供していません。そしてSDN部分。製品の思想というか根幹の部分の考え方の違いとしかいいようがありませんが、「一部の仮想化環境のみを対象としたものではない、あらゆるネットワーク接続デバイスすべてを結びつけるネットワーク」に対するSDNは、ネットワークファブリックをベースとしているからこそ可能となると私は考えています。

■VXLAN on VXLAN?

VMware NSXはVXLANを使うことができますが、NSX Controllerを制御プレーンとして使用する仕組みになっています。基本的にはOVSDBを拡張したような仕組み?(教えて詳しい人。)を使ってデータプレーンとなるNSX仮想スイッチや、NSX対応した物理スイッチを制御します。つまりNSX Controllerとその共通言語でつながっている範囲でしかそのVXLANを解釈することができませんので、ACIがNSXによって制御されているVTEPによって包まれたVXLANを解釈することは残念ながらできません。

Ciscoなど、各社の間でVXLAN EVPN仕様の標準化が進められていますので、将来的には制御プレーンとして独自仕様ではなくEVPN MP-BGPを使う仕組みが標準化していけば、マルチベンダーで真の互換性のあるVXLAN相互接続が可能になるかもしれませんが、VXLANはフレーム仕様は標準化されていてもマルチキャストに依存した当初の構成ではネットワークの構成における制約や、柔軟な制御が難しいなどの課題があったため、現時点では各社が独自の制御プレーンの実装を進めてしまうという残念な状況が現時点のステータスです。

そもそもの話としてVXLANについて個人的に思うこととしては、VXLANを誰もが必要とするなら、VXLANが登場した当初にみんな飛びついたはずなのです。なのに、VXLANが今だにまだ一般化したと言えない理由は、VXLANをVXLANとして意識する使い方は、そんなに多くの人が望んでいるものではないのではないでしょうか。VLANの約4000という壁やら、マルチテナント対応やら、L3を超えたL2接続性やらと、ベンダー側はVXLANのメリットを訴えますが、逆にVXLANの存在を意識させない使い方にこそVXLANの価値はあるのではないかと思います。ACIでもマルチテナントを実現するなどの手段として内部的にVXLANを使ってはいますが、それらを意識して構成・管理するような必要性は全くありません。いわば意識せずに使うことができるVXLANがその裏側にはあるわけです。

そんなわけで、ACIはNSXのVXLANを連携によって認識はしませんが、各ESXiホストにあるVTEP間の通信はVLANに紐付いた単なるUTPパケット通信ですので、当たり前ですが認識できます。内部的にはVXLAN on VXLANになっているのでしょうが、だからどうこうといった問題はまったくありません。EthernetフレームであればL2スイッチング、IPパケットであればL3ルーティングできるという部分は一般的なスイッチと違いは一切ありません。

また、NSX仮想スイッチは分散仮想スイッチに依存していますので、ACIのvCenter連携によって作成された分散仮想スイッチに対してであっても、NSX仮想スイッチの実体としてのポートグループを作ることも可能です。もちろん、別の分散仮想スイッチを使用することも可能です。これらは、アップリンクに使用する物理NIC(もしくは、Cisco UCSでは標準的に使われている論理NIC)を分離するかどうかという構成次第での設計となります。


ACIのEPG (End Point Group)にどの単位でマッピングするのかも自由なところも、NSXを使う場合であってもACIをネットワークファブリックとして使うことのメリットの1つといえます。クラスター単位やポッド単位、ラック単位など、通信量やエラー状況を把握したい単位でNSXがVXLAN通信のためのVTEPポートとして使用するVMkernelのポートグループをEPGマッピングすれば、ACI側からも通信の量やエラーを把握するヘルススコアなどを把握することが可能となります。また、EPG間のContractとしてVXLAN通信に使用する4789/utpだけを通す様に構成しておくことで、セキュリティ的にも望ましい状態を作り出すことができます。


NSXのVXLANは使わなくてもいい

NSXのマイクロセグメンテーション機能がセキュリティなのかと言われると、私としてはあるなら使ったほうが程度のものだと思ったほうがいいのではないかと思っています。仮想マシン単位の隔離だけでは、なぜ侵入が発生したのか、どういう経路だったのか、どのアプリケーションがどういう動作をして、どこに通信しようとしているのか、そして究極的にどう問題を解決するのか等のセキュリティ的な確認・対応をしてくれるものではないからです。しかし、ほぼインフラ基盤がvSphereベースなので分散ファイアウォールを使いたい場合や、アンチウィルス連携など仮想化環境と蜜に連携しているからこそ可能となる機能を必要としている方もいるでしょう。そして、NSXを選択する理由としてそれらの機能をつかいたから、という方もいらっしゃるかもしれません。

さてそうした場合に、ネットワークそのものもNSXのVXLAN機能を使わなければならないかというと、実はそうではありません。NSXのVMkernelモジュールを展開すると、VXLANの構成を行わなくても分散ファイアウォールなどの機能は使用可能となります。また、NSX Controllerの展開も不要です。なぜならNSXの分散ファイアウォールNSX EdgeなどはNSX Managerから直接管理されており、NSX Controllerに依存していないからです。つまり、ネットワークそのものはACIで構成し、ネットワークファブリックを活用した10/40/100GbEトラフィック性能や、EPG (End-Point Group)とContractによるネットワークのポリシー管理、ACIが提供するハードウェアベースの分散ルーティングやスイッチング、L3接続などの機能を活用し、vSphereだけに限定されない物理サーバや物理ファイアウォール・ロードバランサなども柔軟にネットワークに組み込むことを可能としつつ、分散ファイアウォールを使ってNSXのセキュリティグループを活用することが可能となります。

当然ながら、仮想マシンを含め、すべてのネットワーク接続をACI側で確認することができるようになるため、この組み合わせだとNSXのService Composerからも、APICGUIからも、仮想マシン毎に認識することができるようになります。

NSXが提供する分散ファイアウォールと、各社LB/FW連携によって構成されるEPG間や外部L3接続との間に挿入されるACI管理のセキュリティ機能であるService Grapthを組み合わることによって、より柔軟かつ実用的なネットワークを構成することが可能となります。

■単なる連携よりも、代替できたり、ない機能を提供したりできる方がよくないですかね?

NSXと連携するスイッチにしておきたいからと、Nexus/ACIではないスイッチだけを選択肢として考えることがあるかもしれませんが、NSX Controllerによって管理できるハードウェアVTEPとして連携できる物理スイッチは、単にNSX仮想スイッチに接続した仮想マシンと通信できる物理サーバを接続できるだけです。NSXを使わなければ、それこそどんなスイッチであってもVLANさえ処理できれば物理サーバと仮想マシンの間で通信できる構成を作ることになんの制約もないのに、NSXにしたが故に拡張OVSDBベースでのNSX連携できるスイッチでないと接続性を構成できないとか、あまりよくわかりません。しかも物理スイッチ連携を使用する場合は分散ルーティングの機能が制限されるなど、組み合わせと構成がややこしい気がします。

だったら、冒頭にも書きましたが、NSXであっても1つのアプリケーションとして扱ってしまうような、直接的な連携はせずともそれ単体でも様々な機能を提供することができて、必要であれば置き換え/代替することも可能で、NSXにはない機能も提供するACIのようなソリューションを組み合わせておいたほうが、なにかと利用者にとってもメリットが大きいのではないかと思うのですが、いかがでしょうか?

NSXを使わなくてもACIは使うことができますし、NSXの機能の多くを置き換えることも可能です。また、ACIは単なるSDN専用のネットワークソリューションではないので、コントローラによって統合管理されたあたかも巨大なL2/L3スイッチとして使うことができるネットワークファブリックとして使うだけでも多くのメリットを得ることができます。無理してSDN的な使い方やAPI制御、各種連携などをしなければ使えないというものでもありません。

話が大きくなりすぎてしまう気もしますが、元々同じコンピュータであったネットワーク・サーバ・ストレージがそれぞれの役割に特化していったのは、それぞれの役割に特化して分離することによるメリットがあったからです。HCIなど、いわゆるエンタープライズ向けの市場において最近はトレンドのゆり戻りの流れの中でこれらの要素を統合する流れであるように思いますが、逆に先を行くクラウドの中ではあらためてハードウェアの機能を活用する実装への揺り返しが進みつつあったりします。どちらがよいとかではなく、いずれにしてもソフトウェアだけ、でもハードウェアだけでもない、それぞれのいい面を上手く引き出していくことが価値を生み出す手段としてより重要になっていくでしょう。

ネットワークは、あらゆるネットワークに接続してくる要素(=点)をつなぎ合わせるいわば面ですので、限られた点だけを対象とした面では、全体的な面にはなりえません。ある特定の仮想化基盤、ある特定のアプリケーション、ある特定のシステムのためだけのネットワークを作るのであればそれでもいいかもしれませんが、vSphereなどのサーバ仮想化が目指したところは、アプリケーションごと・システムごとの垂直なIT基盤の作り方から、共通化された統合的なIT基盤への発展であったはずです。であるならば、それに対応したネットワークは、特定の要素にだけ対応するネットワークではなく、あらゆる要素に共通のポリシー・管理性を提供できるような包括的な仕組みを提供できるネットワークソリューションであるべきなのではないかと、私は思います。

そんなわけで、Cisco ACIとVMware NSXは競合製品なのかどうか、あなたはどう思いますか?

Happy Holiday season and New Year!!

*1:もちろん、特定のハードウェアに依存したアプリケーションにはハードウェア要件がありますけど。

*2:IPに加えて、FCoE NPVによるFC通信にも対応