OpenFlow／SDN、誤解の構造【第5回】

【技術動向】結局、SDNに求められるものとは何か

本連載では、OpenFlowとSoftware Defined Networking（SDN）に関する誤解と建設的な理解について解説してきた。最終回の今回は、SDNの本質に迫る。

　本連載では、OpenFlowとSoftware Defined Networking（SDN）についての建設的な解釈を提示してきた。「利用者が、やりたいことを実現するために最短距離の方法で、ネットワークの構成や機能の活用ができる」という定義を示し、特定の技術を示す言葉であってはならないと述べた。この定義を受け入れたくない読者は当然いるだろう。しかし、どんな定義を採用するとしても、その技術の目的は、上記と同一であるはずだ。目的が違うのであれば、「SDN」と呼ぶ意味はない。これは、今後広がっていくと思われる、「Software Defined Datacenter」「Software Defined Storage」などの「Software Defined Everything」の動きにも当てはまる。

即時性、自動化、柔軟性がクラウドでのキーワード

　まず、第4回「【技術動向】SDNで何を議論すべきなのか」での、 クラウドサービス事業者におけるSDNについての議論の続きをお届けする。

　第4回で、クラウドサービス事業者に求められているのは自動化であり、クラウド運用基盤との連携であることを説明した。「SDNはネットワークをプログラマブルにする」という表現が誤解であることは、この点でも証明される。

　まず、クラウドサービス事業者であっても、以前説明したように、OpenFlowプロトコルを直接使ってプログラムすることはあり得ない。それどころか、ネットワーキングをいちいちコーディングする余地はない。

即時性、自動化、柔軟性はクラウドサービス事業者の生命線であり、プログラミングなどという作業を行っていたのでは間に合わない。あるテナントが新たに作成した仮想マシンは、作成時点で、そのテナントに割り当てられた仮想ネットワークセグメントに属さなければならない。

　すなわち、クラウド運用基盤と直接、リアルタイムに連携する必要がある。これについては、OpenFlowを使ったソリューションのベンダーも、既存のネットワークベンダーも、VLAN設定を自動化する特定クラウド運用基盤へのプラグインを提供するなどで、対応を進めている。従って、これについては、既存ネットワークベンダーが特に劣る点はない。

　確かに既存ネットワークベンダーの対応は、現状ではベンダー単位であるため、機器ベンダーを変更する際に問題となる可能性はある。だがベンダー間の差異は、適切なプロトコル翻訳機能を備えた管理ツールが提供されれば解消できる。こうしたツールに追加コストを払わなくても、クラウド運用基盤と連動した、マルチベンダーのネットワーク設定が可能になるべきだ。

　複数のネットワークベンダーの製品を混在利用するケースは多くないとしても、ベンダーを移行することは十分あり得る。「SDNでできることは既存のネットワーク技術でできる」というのなら、既存ネットワーク製品ベンダーは、以前にも増してベンダー間の移行の可能性に注目し、対応しなければならない。なぜなら、SDNとは「利用者が、やりたいことを実現するために最短距離の方法で、ネットワークの構成や機能の活用ができる」ことだからだ。

VLANの限界はクラウドサービスのリアルな問題

　クラウドサービス事業者における別のリアルな課題の1つは、従来のVLAN機能ではVLAN IDが12ビットしかないため、仮想ネットワークセグメントが4094しか作成できず、そのままでは大規模なサービスを支えることができない点にある。

　これまでの対策としては、VLANを階層的に構成する、あるいはMPLSのような別のメカニズムを使う、といった運用上の逃げ道がある。だが、いずれの方法でも対応手段が複雑化することは確かだ。この複雑さを十分にマスクして、クラウド運用担当者に意識させないようにすることは可能だろう。しかし、容易な運用環境を提供するための準備作業が複雑では即時性や柔軟性に欠ける。

　これに比べれば、OpenFlowによるトラフィック・ステアリングを使った手法や、VXLAN、NVGREなどを使ったソフトウェアによる分散仮想トンネリングは、上記のような目的を踏まえて開発されたこともあり、単一のシンプルなメカニズムで対応できる。

　また、運用については、クラウド運用基盤との連携さえ十分に実現されていれば完全に自動化される。OpenFlowによるトラフィック・ステアリングを使ったテナント分離も、分散トンネリングプロトコルも、パフォーマンスおよび拡張性については、現在各種の検証が進められているところだ。これらが実証されさえすれば、大規模クラウドサービスにおけるテナント分離については、既存ネットワーク技術よりも有利だ（VMware vSphereのvCloud Directorでは、NATを使ったテナント分離も提供していることを付記しておく）。

　テナント分離だけが注目されがちだが、クラウドサービス事業者における重要なニーズはもう1つある。テナント単位、あるいは各テナントにおけるシステム単位での負荷分散およびファイアウォールをどう構成するかという点だ。

　VMware vSphereでは、テナント単位および仮想マシン単位のファイアウォール機能をソフトウェアで提供し、集中制御するとともに、各テナントが自社の仮想ネットワークセグメント内で自ら構成できるようにしている。ヴイエムウェアは、同社が買収したNiciraについても、同様な環境を実現しようとしている。近い将来、NiciraのNVPでテナント分離を行った上で、テナント単位のセキュリティサービスを構成できるようになるはずだ。これは、OpenStackとの連動も実現する可能性があることを意味する。

　一方、OpenFlowでは、一般的なハードウェアスイッチの機能を使って、負荷分散やレイヤー4までのファイアウォールの機能を提供できる点がメリットの1つとされている。1つのメカニズムで、テナント分離とこれらの機能のどちらにも包括的に対応できるのは、シンプルさという点で有利だ。

　しかし、いずれの場合でも、より高度なニーズにはどう対応すべきかという課題が残る。負荷分散にしても、高度なルールを適用したい場合がある。SSL終端をどこで行うかという問題もある。要するに、現在「アプリケーションデリバリーコントローラー（ADC）」と呼ばれる製品群が提供している機能を、クラウドサービス上でどう活用できるようにしていくかという問題だ。

OpenFlow／SDN、誤解の構造

この連載の記事をもっと見る

この記事の著者