「OpenFlowの父」が語る、OpenFlowとSDNの真実：クラウドHot Topics（7）（2/2 ページ）

—— OpenFlowプロトコルを、なぜあなたの製品の制御に適用しているのかについて確認したい。この製品を利用するという観点からいえば、仮想スイッチ（間の通信）を十分に制御できるかぎりにおいて、どんなプロトコルを使ってもいいはずではないか。

　（NVPでは、）コントローラがvSwitchとゲートウェイを制御する。そしてOpenFlowを使って、これらを制御している。十分なものであるかぎり、どんなプロトコルを使ってもかまわないというのは正しい。しかし、実際にこれを実現できるプロトコルはほかにない。

—— そしてOpenFlowに対応したOpen vSwitchが、オープンソースとして提供されることで、多くの人に広がるというメリットがあるということか？

　Amazon Web Services、Rackspaceなど、世界で最も大規模なクラウドの多く、というかそのほとんどが、LinuxベースのXenあるいはKVMを使っている。しかし残念なことに、Linuxはあまりいい仮想スイッチを持っていなかった。そこで、クラウドを構築する素晴らしい方法として、Open vSwitchに注目した。

　VMwareは非常にいい仮想スイッチを持っていたのに、Linuxにはそれがなかった。われわれはここで助けを差しのべられると思った。

　シスコなどの競合他社を含め、多くの企業がOpen vSwitchを使っている。これほど数々のイノベーションが起こっているのは素晴らしいことだと思う。多くのハードウェア企業がOpen vSwitchをハードウェアスイッチに組み込んでいる。多くのクラウドがNicira（の製品）とは関係なくこれを利用している。競合他社にも使われている。これは素晴らしいエコシステムだ。

　われわれにとっては、ネットワークというレイヤでイノベーションを起こしたくても、そのための適切なテクノロジがなかった。だからわれわれはつくった。これがなければ、われわれのような企業はイノベーションを起こせない。

—— しかし、今後（Open vSwitchやOpenStackに関する活動）は、だんだんあなたたちの会社の事業の成長に直接貢献しない活動になっていくのではないか？

　それは素晴らしい質問だ。私は、OpenStackとOpen vSwitchの周辺に、より多くのイノベーション、ユーザー、コミュニティが集まることで、オープンなエコシステムがさらに拡大し、われわれもさらに多くのメリットを享受できるようになると思う。

　このエコシステムを成長させることが重要だ。誰でもが使えるということがユーザーベースを広げ、他のすべての人々にもメリットとなる。われわれがやりたいのは、オープンなエコシステムを成長させることで、われわれが競争に参加できるようにすることだ。なぜなら、OpenStackやOpen vSwitchがなければ、従来型のベンダしか競争できないからだ。

　だからこそ、これらのテクノロジのサポートは、当社にとって得策だし、誰にとっても利益となると思う。

ポリシー管理をネットワークから分離する

—— では、OpenFlowそのものについていくつか聞きたい。ネットワーク運用担当者にとっての最大の悪夢は、ネットワークの構成、スイッチのトポロジーの拡張性や再構成にあり、この問題はファブリック・メカニズムを備えた新しい世代のスイッチによって解決されつつあると考える。どう思うか。

　そうとは思わない。私は、ネットワークにおける問題の最たるものは、運用におけるステートのすべてを管理することだと思う。これまでIPネットワークを構築することは非常に容易だった。最大級のデータセンターはみな、IPベースのネットワークを構築してきた。構成はシンプルで、構築も拡張も簡単だった。

　しかし、今日では、ACL、セキュリティグループ、QoSなどのステートを管理しなければならなくなっており、これが非常に難しい作業になってきた。

　ファブリックでレイヤ3をやるだけなら、非常に簡単だ。しかし、QoSをはじめとしたさまざまなことをやるのが非常に難しい。このため、Niciraでは、ファブリックにシンプルなネットワークの転送管理部分はまかせ、ステートの管理をすべてエッジに移行するべきだと考えている。

　qfabricのような新しいファブリック技術は、非常にシンプルなネットワークを内部で構成し、たしかに一部の管理をエッジに移行できるようにしている。

　問題は、これらの技術がハードウェアにとどまっていることだ。しかし本来これは、ソフトウェアの問題だ。（仮想マシンの）移動をどう確保するかという問題があるし、まずどうやってイノベーションを起こしていくか、サービスの進化をどう先取りしていけるかという問題がある。そしてもう1つ、こうした技術はベンダ独自のものだ。

　われわれが言うのは、物理的なネットワークは好きなようにつくってくださいということだ。日立電線（のスイッチ）などは素晴らしい物理ネットワークを構築できる。レイヤ3で、非常に美しいネットワークが作れる。

　シンプルで、オーバーサブスクライブされることがなく、管理も展開もシンプルに実行できる。われわれはエッジにいて、どんなベンダ（の製品）も使える。（テナント）分離やQoSなど、すべてのオペレーションがエッジで行える。

—— 分離の部分は分かるが、QoSの部分は理解できない。物理レイヤを十分認識し、あるいは制御することなく、どうやってエンド・ツー・エンドのQoSを確保できるのか。

　これは素晴らしい質問だ。日立電線のようなところは、オーバーサブスクライブされないネットワークをつくることができる。こうした製品を使えば、ネットワークのエッジからすべてを制御できる。消費帯域の上限や優先度を行使できる。

　しかし複数のフローが同一のスイッチで競合するケースでは、ファブリックが（QoSを）確保しなければならない。

　例えば多数の仮想マシンが単一の仮想マシンと通信し、これが単一のスイッチを通る場合がある。こうした場合にできるのは、どのパケットをドロップするか判断することだけだ。われわれは、仮想的な優先度をトンネルの外側に移動することができる。すなわちわれわれはエッジからいろいろなことを行使できるが、スイッチがローカルにパケットをドロップする判断ができるように、QoSビットを外側のヘッダに配置できる。

—— しかし、仮想的なネットワークを構築して管理する際の基本的な課題は、それでも物理的なネットワーク・トポロジや境界を意識する必要性が残るということだと感じる。

　そうだ。物理ネットワークはそれほど賢くない。しかし多くの大規模データセンターにおいて、物理ネットワークは太いレイヤ3ファブリックで構築されている。このため、エンド・ツー・エンドの帯域幅がオーバーサブスクライブされないようにできる。安価にこれを実現するために、彼らはレイヤ3ネットワークを構築している。彼らだってトポロジーを意識したくないからだ。

　しかし、オーバーサブスクライブされるような従来型のトポロジーであるならば、あなたは本当に正しい。これがわれわれにとっての課題になる。しかし将来は、（従来型の）データセンターも安価なIPファブリックに移行するだろう。そうすれば、われわれはエッジからの制御がしやすくなる。

あなたがOpenFlowでできることは、おそらく何もない

—— OpenFlowが革新的あるいは進化を促進するテクノロジだと感じる人は多い。しかし、あなたたちの会社の製品が実現するようなネットワーク分離を除くと、一般的なエンタープライズ・ネットワークでどう活用できるのか分からなくなってしまう人も多い。

　OpenFlowは顧客のためのテクノロジではない。システムをつくる人たちのためのテクノロジだ。Niciraのような会社や、シスコのような会社が、より良いネットワークをつくるために使うものだ。

　混乱の原因の1つは、顧客がOpenFlowプロトコルを使って何ができるのかと考えてしまうことだ。これに対する答えは「おそらく何もありません」だ。非常に優れたプログラマが労力をかけてやることであり、OpenFlowが実現するのは、顧客がわれわれのようなベンダを使って、より良いネットワークを手に入れられるようにすることだ。

—— 私の観察では、サーバの人たち（server guys）がOpenFlowに対して恍惚感を感じている。なぜなら彼らはネットワークの人たち（network guys）の柔軟性のなさに、フラストレーションを感じてきた部分があるからだ。

　（日本語で）ソウデス。

　スイッチのなかには、転送を実行する部分と処理を制御する部分がある。処理を制御する部分はプログラム可能だ。これらに加えて、オペレーション上のステートがある。ACL、QoS、ポリシールーティングといった部分だ。これらすべてが、現在はネットワークの人たちに管理されている。パケットを動かすということは、たしかにネットワークの問題だ。しかしサーバの人たちも、ワークロードレベルで自分のやりたいことができなければならなくなっている。

　そこでOpenFlowとSDNは、（セキュリティやQoSなどを）プログラムとして提示する。これをサーバの人がプログラムできるようにするわけだ。

　あなたの言うことはまったくそのとおりで、ネットワークの人はあまりうれしくないかもしれない。彼らのやっていることが奪われるからだ。しかしサーバの人は、やりたいことができるようになる。

—— Open vSwitchに関連する開発の難しさについてはすでに聞いたが、ある意味でこれはすでに終わった作業だろう。さらにあなたは、コントローラで差別化していくと言っている。より具体的には、コントローラのどの部分で差別化していくのか。

　Open vSwitch（に関するメインの作業）はすでに終わっている。しかしこれを制御するコントローラは、あらゆるサービスについてステートを制御しなければならない。非常に難しいことだ。ステートがいつも正しく保たれているような形でやらなければならない。何か障害が起こっても、（仮想）ネットワークは正しく動作しなければならない。例えば2つの分離しなければならないアプリケーションがあり、何かが起こった場合に、短時間でもこのアプリケーション間で通信が実現してしまってはいけない。セキュリティ・ポリシーは短時間でも損なわれてはならない。いつでも正しく動かなければならない。

　伝統的なネットワークは、こうした形でステートを管理するやりかたを理解しない。伝統的なネットワーキングでは、何か障害が起こった場合、短時間なら正しくない状態になってもオーケーだとされる。ネットワーク仮想化の世界では、それは許されない。

　従って、われわれの課題は、大規模にステートを管理しながら、常時正しい状態を保つということにある。通常、時々正しくない状態を許して大規模化を図る、あるいは常時正しい状態を維持するが大規模化ができない。しかしわれわれは大規模化しても常時正しい状態を保つことをやっている。