「OpenFlowの父」が語る、OpenFlowとSDNの真実：クラウドHot Topics（7）（1/2 ページ）
日本ではOpenFlowに対する期待がインフレ気味だ。「OpenFlowで何でもできる」と思いこんでいる人も多いようだ。そこで、米Nicira Networksのマーティン・カサド（Martin Casado）氏へのインタビューをお届けする
日本ではOpenFlowに対する期待がインフレ気味だ。「OpenFlowで何でもできる」と思いこんでいる人も多いようだ。
そこで、米Nicira Networksのマーティン・カサド（Martin Casado）氏へのインタビューをお届けする。このインタビューは2012年2月22日、同社による日本での事業展開の発表と同日に行った。
カサド氏はスタンフォード大学で、OpenFlowプロトコルを生み出した1人。その後Niciraの共同創業者となり、同社のCTOを務めている。今回はOpenFlow、Open vSwitch（NiciraはOpen vSwitchの開発にもかかわってきた）、Software-Defined Networking（SDN）、そしてNiciraの製品であるNVPの関係について、かなり突っ込んだ質問をし、カサド氏もこのインタビューにおける質問内容を評価してくれている。最後までお読みいただければ幸いだ。
—— 今回のNVPは、あなたたちのOpenFlowに関する知見やノウハウを活用する最初の製品という位置づけなのか？
そうではない。われわれの会社がやっているのはネットワーク仮想化だ。われわれの会社で今後やろうとしているのもこれだけだ。
—— 「ネットワーク仮想化」という言葉は、いろいろな意味に受け取れる。
まったくそのとおりだ。当社が目標としているのは、運用面、ベンダからの独立、シンプルさ、俊敏さといった点で、ネットワークが（仮想）サーバと同じような属性を実現できるようにすることだ。
われわれにとって「ネットワーク仮想化」とは、仮想マシンの管理と同じようにネットワークを管理できることだ。動的に作成でき、どこにでも動かすことができ、どんなワークロードでもサポートでき、ネットワーク・ハードウェアから独立しているということだ。
これが実現することで、やっとデータセンター全体をクラウド化できる。なぜなら今日のデータセンターを見ると、ネットワークが最大の問題だからだ。Niciraがやろうとしているのはこれだ。伝統的なネットワークでは、現在の問題に応えることができない。
この問題を検討しているうちに、SDN（Software-Defined Networking）の初期の技術を開発し、OpenFlowも開発することになった。そしてこれがスタンフォード大学の同僚に取り上げられ、さまざまな問題に適用されることになった。問題解決を考える過程で開発したのがOpenFlowだ。
SDNは、OpenFlowに比べて大きなテーマだととらえることもできる。そしてわれわれ（の会社）は、いわばSDN市場の一部だといえる。
OpenFlow自体は、ほとんど何をするわけでもない
—— 私の質問の意図はこういうことだ。OpenFlowへの関心が日本で非常に高まっていることを聞いているかもしれない。Software-Defined Netwokingという言葉も注目されている。しかし、OpenFlowでできること、SDNでやろうとしていることについて、大きな混乱が見られる。多くの人が考えるのは、OpenFlowがスイッチやルータのハードウェアのネットワークトラフィック処理を制御できるということだ。あなたたちがやろうとしているのはそれではない。ハードウェアを制御するのでなく、IPネットワークならなんでも対象にすることのできる、トンネリングおよびネットワーク分割の、自己完結的なメカニズムだろう。
OpenFlow自体は、ほとんど何をするわけでもない。インターフェイスというだけの存在だ。USBがコンピュータのインターフェイスであるのと同じように、USBマウスやキーボードのようなUSBを使うデバイスがなければ、プロトコル自体では何もできない。伝統的にネットワークではこうしたインターフェイスがなかった。このため、新たな機能をソフトウェアで追加することが難しかった。
顧客がOpenFlow対応のスイッチを買ったとしても、新たなセキュリティだろうが、トラフィック・エンジニアリングだろうが、よりよい管理だろうが、何か面白いことをしたければ、それをやるための支援機能を作り込まなければならない。
しかし、OpenFlowが役に立つ用途はたくさんある。トラフィック・エンジニアリングに使われているし、セキュリティにも、負荷分散にも使われている。
だが、われわれはそれをやっているわけではない。われわれのOpenFlowの使い方は、ネットワーク仮想化をするためにネットワークのエッジを制御することだ。
ネットワーク仮想化はOpenFlowとはまったく異なるものだ。OpenFlowはスイッチを1つ1つ制御する。そのスイッチがいなくなってしまうと、ソフトウェアはこの変化に対処しなければならない。（OpenFlow自体は）ネットワークの見え方を、ネットワークそのものから完全に切り離すことをしない。
われわれがやっているのは抽象化を行い、ネットワークの仮想的な見え方を作り出すことだ。物理的なネットワークで何が起ころうとも、その見え方は変わらない。これによって物理スイッチの追加、移動、変更から完全に独立できる。あるいは同一の物理ネットワークを、多数の仮想ネットワークで共有できるようになる。
これは、実現するためのソフトウェアを書かないかぎり、OpenFlowではできないことだ。そしてこれを実現するためのソフトウェアを書くのは、とんでもなく難しい。
OpenFlowを生み出すのはとても普通な作業だ。しかし、ネットワークを仮想化するソフトウェアをつくるのは、膨大な労力がかかる。非常に難しい問題だ。このソリューションの難しさを解決するのが、われわれの仕事だ。
OpenFlowもSDNも、複雑な問題の解決を可能にしてくれる。しかし、SDNなしでは、ネットワーク仮想化の問題を解決することができない。伝統的なネットワークでは、この問題を解決できなかった。なぜならその上にツールが存在しなかったからだ。
OpenFlowもSDNも、Niciraやその他の会社が、ハードなネットワーキングの問題を解決できる機会を与えてくれる。しかし、この問題を（本当に）解決しなければならない。これがわれわれのやっていることだ。
—— あなたはポイントソリューションだと切り捨てるかもしれないが、例えばVMwareの世界では、すでにvNetwork Distributed Switchを使い、仮想マシンのインターフェイス（注：正確にはインターフェイス群）にVLAN IDを割り当てることができる。
それについて話そう。
VLANは物理ネットワークの一部だ。VLANに属する仮想マシンにとっては、最初のポップのゲートウェイが物理サブネット上にあることには変わりない。仮想マシンを別のサブネットに移動することはできない。IPアドレスが変わってしまい、アプリケーションが使い続けられなくなってしまうからだ。これではネットワークの仮想化ではない。同一のVLANのなかで構成を移動できるようにしているだけだ。
われわれがやっているのは、物理的な存在にひもづく部分をなくすことだ。すべてのアドレス、ゲートウェイ、すべてが仮想化される。ある仮想マシンをサブネット間でも、データセンター間でも移動することができる。
もう1つ大きな違いがある。VLANではレイヤ2のプライベートネットワークを持てるだけだ。しかしクラウド上の多くのアプリケーションは、別のタイプのプロトコルを必要とする。例えばレイヤ3だ。
MapReduceなど、大規模な解析のワークロードではレイヤ3が必要だ。スケールさせるためには、多数のエンドホストが協調動作する必要があるからだ。
われわれの方法では、レイヤ2でもレイヤ3でも、すべてを仮想化できる。仮想マシンが動きまわったとしても、すべてのサービスが（一緒に）動き回れる。従ってこれはNexus 1000Vとも、ヴイエムウェアのvDSとも非常に異なる。
—— しかし簡単にいえば、あなたたちのやろうとしているのは、基本的にはレイヤ2パケットのレイヤ3トンネリングだ。
それはオン・ザ・ワイヤの（注：ネットワーク的な）メカニズムだ。しかしすべての複雑さをNiciraの（製品の）なかで処理している。パケットをネットワーク上でやり取りするという作業は、このソリューションのなかではシンプルな部分だ。
もっと難しいのは、各仮想マシンに仮想的なアドレス、仮想的なセキュリティ・ポリシー、仮想的なブロードキャスト・ドメインを見せることだ。こうしたことの多くは物理ネットワーク上で共有されなければならない。ある仮想マシンが動くと、すべてのポリシーやセキュリティは更新されなければならない。ステートを管理すること、これが難しい部分だ。
ネットワーク上でパケットをどのように運ぶか。レイヤ3トンネルを使うこともある。物理ネットワークによってはレイヤ2タグを使うこともある。もし大規模なレイヤ2ネットワークであれば、タグを使うだけでもいい。しかしレイヤ3ネットワークでは、サブネットを超える必要があるため、レイヤ3トンネリングを行う。だが、パケットの移動の部分は難しいことではない。
—— しかし、あなたのソリューションのパフォーマンスに影響を与えるはずだ。
パフォーマンス上、われわれのトンネリング（注：STT）は一番優れている。Linux上の仮想マシンに対し、10Gbpsのパフォーマンスを提供できる。トンネリングをしない場合とほとんど同じパフォーマンスが達成可能だ。秘訣は、標準的なNICならどれでも備えているハードウェア加速化機構を使うことだ。
—— 実際にはどのようにやるのか。
（図を描いて）仮想マシン、vSwitch、ハイパーバイザ、NICがあるとする。（仮想スイッチとNICの間を指し）パケット送信に際して、一番高くつくのはこの境界を超えるところだ。
そこでわれわれは、仮想マシンに対して大きなウィンドウサイズを伝え、仮想ネットワークが非常に大きな帯域を持つと思い込ませる。そしてNICを使い、パケットをより小さなパケットに分割する。これはハードウェアによる分割ができるからだ。私の知る限り、現在これをやっているのは当社だけだ。
—— NVP開発にあたってOpen vSwitch関連で難しかったというのはどういうポイントだろう。ハードウェアのOpenFlowスイッチと同じような動きを仮想スイッチにさせるということではないのか。
そうだ。ハードウェアのOpenFlowスイッチと同じように動作する。
しかし仮想の世界と物理の世界との間の翻訳をしなければならない。サーバ仮想化では、仮想アドレスと物理アドレスが存在し、この間でのマッチングを行う。これと同じことをやらなければならない。多くのサーバと通信していて、仮想スイッチ群の上に何千ものアドレスを管理しているとする。ここに仮想セキュリティ・ポリシーを適用し続けていかなければならない。いわば鎖から解き放たれたステート管理を大量に行わなければならない。これが難しい。
トンネリング手法そのものは重要ではない
—— NVPはトンネリングあるいはカプセル化のテクノロジから独立しているといえるか？
そうだ。多数のトンネリングプロトコルをサポートしている。GRE、われわれの発明したトンネリングプロトコルであるSTT、IPsec、GRE＋IPsecをサポートしている。レイヤ2のカプセル化プロトコルもサポートしている。今後も顧客のニーズに応じてさらに多くのプロトコルをサポートするつもりだ。
—— そのなかでユーザーに使わせたいのはどれか。
突出して速いのは、Niciraが開発したSTTだ。先ほど説明したNICの機能を使うのはこれだ。パフォーマンスが非常に優れているため、STTを選択する人は多い。特殊なハードウェアを必要とせずに、10倍もの高速化を実現している。これが当社としてのおすすめだ。しかし、GREを使いたければ、それでもかまわない。
おそらく、これを話すのはあなたが最初だと思うが、来週われわれは、これを標準化するつもりだ。
注：Niciraはその後、STTについてドラフトをIETFに提出した。
http://nicira.com/blog/opening-the-tunnels
http://www.ietf.org/id/draft-davie-stt-01.txt
—— ホワイトペーパーでは、「VXLANもサポートできる」と言っている。
そうだ。あらゆるトンネリングプロトコルに対応する。VXLANは事実上、NVGREに非常に近い。われわれはNVGREにも対応するし、VXLANにも対応する。
—— クラウドサービス事業者が各テナントに対し、分離されたネットワークセグメントを提供するというユースケースを考えたとき、例えば顧客側拠点にトンネリングのエンドポイントが必要になる。こうしたCPEあるいはCPSの提供予定はどうなっているのか。
ゲートウェイと呼ぶものを作っている。ソフトウェア、仮想アプライアンス、あるいは仮想アプライアンスを動かす物理アプライアンスの形式で提供する。これで顧客の物理ネットワークをクラウドに拡張できる。ハードウェアプラットフォームを提供すべく、現在ハードウェアパートナーとの協業も行っている。既存のバックボーン（サービス）との統合も考えており、NTTのような事業者がサービスとして提供できるようにもしていく。
Copyright © ITmedia, Inc. All Rights Reserved.