Agile Cat — in the cloud

VMware は OpenFlow を静観する_3

Posted in OpenFlow, SDN, Virtualization, VMware by Agile Cat on July 6, 2012

VMware networking CTO on OpenFlow_3
Shamus McGillicuddy Published: 19 Jun 2012

_Tech Target


VMware は OpenFlow を静観する_1
VMware は OpenFlow を静観する_2
VMware は OpenFlow を静観する_3


Question: If OpenFlow or some other SDN protocol takes off and you’re able to abstract directly at each device rather than relying on an overlay technology, what kind of value can you derive from that?

もし、OpenFlow や他の SDN プロトコルが本格的に運用されるなら、オーバーレイ・テクノロジーに依存するのではなく、それぞれのデバイスをダイレクトに抽象化することが可能になる。 こうした流れの中で、どのような価値を引き出そうとしているのか?

Sequeira: I think what we have today is good enough for most of what we are trying achieve for network virtualization. Ultimately the number one problem we’re trying to solve in enterprise data centers is speed and agility of provisioning and efficiency. The whole point of a software-defined data center is to virtualize the rest of the data center. VMware-enabled provisioning allowed provisioning of servers within two minutes and for $300, whereas in the past it took 10 days and $10,000.

現時点において、私たちが有しているテクノロジーは、ネットワークの仮想化を達成するための、充分な能力を備えていると考える。エンタープライズ・データセンターにおいて、私たちが解決しようとしている最大の問題を突き詰めると、プロビジョニングにおけるスピードとアジリティであり、また、その有用性となる。データセンターをソフトウェア定義する際のポイントを俯瞰すると、その残りの部分を仮想化することにいたる。 VMware が実現するプロビジョニングは、2分以内の所要時間と $300 の対価で、複数のサーバーを立ちあげていくが、過去においては、10日間と $10,000 を要していた。

The rest of the problem is it takes five days to provision the rest — VLANs, IP address management, firewalls, storage availability. If you can provision these networks quickly, you have solved that problem. We believe with VXLAN and SDN we have solved that problem substantially. So customers aren’t asking us for OpenFlow. They are asking for agility of provisioning and seamlessness of experience when they start to bring up compute with network and storage alongside. In that particular instance, OpenFlow doesn’t bring you immediate value.

残された問題は、その他の部分の、つまり VLAN/IP アドレス管理/ファイアウォール/ストレージなどを利用可能にするために、5日を要する点である。 もし、これらのネットワークのプロビジョニングを、より短期間で達成できるなら、その問題を解決していることになる。 私たちは VXLAN と SDN により、この問題を充分に解決していると信じている。 したがって、私たちの顧客が、OpenFlow を求めるということはない。 それらの顧客が求めているのは、ネットワークやストレージと並行して、コンピューティングを構築し始めるときの、プロビジョニングのアジリティであり、シームレスなエクスペリエンスである。そして、特定のインスタンスにおいて、OpenFlow が即効性の価値をもたらすことはない。

Then why even consider OpenFlow in the data center? With OpenFlow you get a lot more granularity of visibility and control. With overlays, for the most part, it works. Most people build their fabrics and have headroom in their fabric. With OpenFlow you can be much more efficient, much like Google showed in their WAN. You can program each flow; you can bring up applications and say, ‘I want this application to take this specific path through the network.’ When you want much more specific control over your traffic, then you can look at OpenFlow. Likewise, you can ultimately get a lot more diagnostic capabilities because you know what is happening when an application has an issue with a server. You can quickly pinpoint what went wrong with the server.

それなら、データセンターで OpenFlow を考慮する理由は、どこになあのだろうか? OpenFlow を用いることで、さらに詳細なレベルにおいて、可視性とコントロールが得られる。 そして、オーバーレイを用いても、その大部分は機能する。 大半の人々は、自身のファブリックを作成し、その中に空き空間を持っている。 OpenFlow を用いることで、Google などの WAN で示されるような、さらなる効率が得られる。 つまり、それぞれフローをプログラミングできるようになる。具体的には、アプリケーションを指し示し、「 このアプリケーションのための特定パスを、ネットワークを介して取得できる」と、説明できるようになる。 自身のトラフィック上で、より詳細なコントロールを必要とするとき、OpenFlow に注目するようになるだろう。 さらに突き詰めれば、アプリケーションが問題を引き起こしたサーバーを認識できるため、さらなる診断能力が得られることになる。 つまり、支障をきたしているサーバーを、より素早く指摘できるようになる。

But people aren’t ready for it yet. Today people want to monitor networks with existing tools. Even if the technology was 100% there today, it takes a while for organizations to change people and processes. If you have 200 Stanford Ph.D.s and you own your own fiber and can build your own boxes in your backyard and you own your own traffic and have proprietary applications, then [Openflow] is for you [now].

しかし、そのための準備を、人々は済ませていない。 現時点で望まれているのは、既存のツールを用いた、ネットワークのモニタリングである。 たとえ、完全なテクノロジーが存在するにしても、組織における人員とプロセスを変更するには、しばらくの期間を要する。 もし、200人の Stanford Ph.D をスタッフとしてい抱え、また、自身のファイバーを所有し、裏庭で自身のためのデバイスを作成し、自身のトラフィックとプロプライエタリなアプリケーションを持つなら、すでに Openflow は、あたなのためのものである。

Question: So enterprises don’t need OpenFlow, and they will probably wait until somebody commercializes it?

そうなると、エンタープライズは OpenFlow を必要とせず、また、誰かが商用化するまで、それを待つことになるのか?

Sequeira: Exactly. If all you are doing is working on your own proprietary applications like Google, Facebook or Zynga, that’s one problem. Our problem is very different. The reason VMware is so solidly grounded in enterprises is because 90% of these applications have been running in networks for years and years. VMware enabled these existing applications to be containerized and you’re able to insert the virtualization layer, which allows you slip in new hardware without touching the applications. All these new applications we talk a lot about — big data and Hadoop — that’s not what most enterprises are facing today. It’s the 95% of applications in enterprise that we want move forward.

まさに、そのとおりだ。 もし、行うべき全ての作業が、Google/Facebook/Zynga のような、プロプライエタリなアプリケーション上で完結するなら、その問題は一点に絞られる。 しかし、私たちの問題は、きわめて多様なものとなる。 VMware がエンタープライズの強固な基礎として用いられてきた理由は、そこでのアプリケーションの 90% が、何年にもわたりネットワーク上で動作してきたからである。 VMware が実現してきたのは、既存アプリケーションのコンテナ化であり、また、仮想化レイヤーの挿入である。 そして、それらを実現することで、アプリケーションに触れることなく、新しいハードウェアを追加できるようにしてきた。 また、Big Data や Hadoop といった、新しいアプリケーション・スタイルについても言及してきたが、大半のエンタープライズは、それらに直面するという状況にない。つまり、その他の 95% のエンタープライズ・アプリケーションを、さらに前進させたいと考えている。

Question: Do you see VMware competing with Nicira Networks, Big Switch Networks and NEC?

VMware は、Nicira/Big Switch/NEC などと競合するのか?

Sequeira: The real question is: Are Nicira and Big Switch a feature in VMware? We are not looking to compete with them. The onus is on them to find an important and relevant area that solves a unique problem. Solving network virtualization in the context of a VMware stack? We’ve got that nailed. In other words, we don’t believe that we need an outside answer to solve a virtualization problem for our VMware stack.

現実には、VMware は Nicira や Big Switch をプッシュするかという質問だと理解する。 私たちは、彼らとの競合を望むわけではない。 彼らの責任は、ユニークな問題を解決するための、重要かつ適切なエリアを見つけ出すことである。 VMware スタックのコンテキストにおいて、ネットワークの仮想化という問題を解決するだろうか? すでに、私たちは、その問題を捉えている。 言い換えれば、VMware スタックにおける仮想化の問題を、外部の力を借りて解決する必要性があるとは信じていない。



TAG index3回に分けて掲載してきた、この「VMware は OpenFlow を静観する」ですが、Sequeira による一連のコメントには、このマーケットをリードする者の「強気」が見え隠れしているように思えます。 たとえば、2012年 4月にポストした「アメリカの 最強 IaaS プロバイダー Top-10 をリストアップ!」という抄訳では、そのうちの 4社に対して Key Building Block を提供する存在として、VMware が紹介されています。 Open Networking Summit で OpenFlow へのコミットを明確にした Google と比べて、その対極に位置する VMware のスタンスには、これからも注目していきたいと思います。 ーーー image



VMware は OpenFlow を静観する_1
VMware は OpenFlow を静観する_2

VMware は OpenFlow を静観する_3
VMware が考える、ソフトウェア定義によるデータセンターとは?
VMware の考える SDN は、OpenFlow だけでは完成しない
Google の OpenFlow バックボーンは、どのように機能しているのか_1
Google の OpenFlow バックボーンは、どのように機能しているのか_2
トップを快走する AWS と、それを追いかける 7人の チャレンジャー

Comments Off on VMware は OpenFlow を静観する_3

%d bloggers like this: