Agile Cat — in the cloud

VMware が Nicira を $1.26B を買収 : その背景にあるものは?

Posted in .Selected, OpenFlow, SDN, VMware by Agile Cat on July 24, 2012

VMware to buy Nicira for $1.26B in a strategic leap of faith
http://wp.me/pwo1E-4tR

By
Stacey Higginbotham Jul. 23, 2012
http://gigaom.com/cloud/vmware-to-buy-nicira-for-1-26b-in-a-strategic-leap-of-faith/

_ Gigaom

VMware will shell out $1.26 billion in cash and an assumption of existing equity to buy Nicira, a company that has built software to do for networking what VMware has done to virtualize computing. That’s a lot of money, especially when you consider how few production-level implementations there are of the software-defined networks that Nicira is building.

VMware は Nicira に対して $1.26 billion のキャッシュを支払い、現時点で発行されている同社の株式を引き受けることになる。 Nicira は、VMware が仮想化したコンピューティングを、ネットワークで接続するためのソフトウェアを開発することになる。 この買収額は膨大なものであるが、Nicira が構築した SDN が、プロダクション・レベルでは僅かであると考えるとき、その思いが強くなるであろう。

Nicira’s CTO Martin Casado

Ncira was created five years ago and has raised $50 million from investors that included Diane Greene, an original founder of VMware. It makes controller software that helps free the act of moving data and packets around a network from the constraints of networking hardware  – an increasingly tough problem inside highly virtualized and webscale data centers. As I explained in a story on its launch (it was titled, “Meet Nicira. Yes, people will call it the VMware of networking”):

Ncira の創業は 5年前である、昔からの VMware ファウンダーである Diane Greene を含む投資家から、これまでに $50 million の資金を集めている。 同社のソフトウェアは、ネットワークにおけるデータとパケットを、ハードウェアの拘束から解放するための、コントローラという機能を持つ。つまり、高度に仮想化された、Web スケールのデータセンターにおいて、増殖している問題を解決するものなる。 私が、Nicira の立ち上げにおいて、以下の記事を執筆している(タイトル:Meet Nicira. Yes, people will call it the VMware of networking)。

Nicira is one of several companies attempting to solve the problem that Greene helped create when she co-founded VMware to push hypervisors and virtualization. Once servers were virtualized, it created an easy way to separate computing from the physical infrastructure. The benefits of server virtualization were more-agile compute infrastructures — a developer would spin up a server in minutes as opposed to waiting days for approvals — as well as consolidating IT. Storage followed, but holding the whole virtualized infrastructure effort back was networking. Like a bird with its wings clipped, IT was tethered to the physical hardware by networking.

この問題を解決しようとする企業の中に Nicira がいる。それは、ハイパーバイザと仮想化を推し進めるために、Greene が VMware を共同で設立したときに目指したものである。 サーバーが仮想化された直後から、コンピューティングを物理的なインフラから分離するための、容易な方式がもたらされた。 サーバーの仮想化から得られたものには、よりアジャイルなコンピューティング・インフラだけではなく(デベロッパーたちは、承認のために何日も待つのではなく、ものの数分でサーバーを立ち上げるようになった)、IT のコンソリデーションもある。(デベロッパーたちは、承認のために何日も待つのではなく、ものの数分でサーバーを立ち上げるようになった)それにストレージが続いたが、仮想化されたインフラ全体を支えるためには、ネットワークに対応せざるを得なかった。 小鳥のような身軽さで、ネットワークを用いいることで、IT と物理的なハードウェアが接続されていく。

Nicira has plenty of paying customers including eBay, AT&T, Rackspace and NTT, but it’s unclear how many of these are running Nicira’s controllers in their production environment. With this purchase, my sense is that VMware is paying big money to get in on this space because its collaborations with Cisco have failed to deliver on a true solution for many of its customers, and it can’t afford to be left behind as the wave of interest and eventual spending on software-defined networking hits a peak.

Nicira の収益は、eBay/AT&T/Rackspace/NTT などの、数多くの顧客によりもたらされているが、そのらのうちの何社のプロがクション環境で、Nicira のコントローラーが稼働しているかは不明である。 今回の買収により、この領域に対して VMware は、膨大な投資を継続することになったと、私は感じる。 なぜなら、Cisco とのコラボレーションが、それらの顧客の多くに対して、有用なソリューションを提供できなかったからであり、また、SDN への興味がピークを迎える前に、最終的な投資を実施するという観点において、残された時間が少なくなったからである。

imageIn a blog post covering the deal, VMware CTO Steve Herrod explains that Nicira will fit in with VMware’s vision of a software defined data center — although the specifics of that vision have yet to be unveiled. And it’s true that if we consider how Nicira customer Calligo is using the Nicira controller, it fits within what I would think of as a software-defined data center — essentially a pool of compute resources that are tied together with software and where the physical hardware can reside in different data centers and pulled up for use as needed. The whole process is programmable and automated.

今回の買収をカバーしているブログ・ポストにおいて、VMware CTO である Steve Herrod は、同社のビジョンである Software Defined Data Center に対して、Nicira がフィットすると説明するが、そのビジョンの詳細は明らかにされていない。 そして、Nicira のユーザーである Calligo が、どのように Nicira コントローラを用いているかと考えるなら、私たちが  Software Defined Data Center だと推測するものに、フィットすることも確かである。つまり、本質的な観点において、コンピューティング・リソースのプールは、ソフトウェアと密接に結び付けられる。そして、そこには、それぞれのデータセンターに配置された物理的なハードウェアが存在し、必要に応じて利用できるようになる。さらに、そのプロセス全体がプログラマブルなものであり、また、自動化されたものとなる。

In pushing this model, VMware was always going to have to sign partnerships to deliver the software-defined networking elements, because its own VXLAN option was more of a an encapsulation scheme than a true separation of the networking logic from the hardware pushing the bits. By buying Nicira, VMware has chosen a software-defined networking vendor that plays with open protocols such as Open Flow, but is still focused on keeping a proprietary edge to its business. That’s a similar strategy that VMware seems to be pursuing as well.

このモデルをプッシュする経緯において、SDN の要素を提供したがるパートナーたちと、VMware は契約をかわさなければならない状況にあった。なぜなら、同社における VXLAN の選択肢は、ビット転送を行うハードウェアから、ネットワーク・ロジックを完全に分離するための、さらなるカプセル化を提供する方式だからである。そして Nicira を買収することで、VMware は SDN ベンダーの道を選び、Open Flow などのオープン・プロトコルに取り組むことになるが、そのそのビジネスにおいては、プロプライエタリの優位性を、依然としてキープしていくことになる。 それは、VMware が追求している戦略に、沿ったものになるだろう。

The deal is expected to close during the second half of this year. The deal includes approximately $1.05 billion in cash plus approximately $210 million of assumed unvested equity awards.

この買収は、今年の後半にクローズすると予想されている。 また、取引額としては $1.05 billion のキャッシュが報じられているが、不確定な持株授与として $210 million も含まれるようだ。

Related research and analysis from GigaOM Pro:

ーーーーー

imageいやぁ~~~ ビックリしましたね。 でも、よくよく考えてみると、OpenFlow と SDN に関して、それを使う側からの発言を繰り返していたのは、Google と VMware であり、このような買収劇が起こるにしても、辻褄は合っているようにも思えます。 Paul Maritz のポジションまでも含めた、大幅な体制の刷新をおこなったばかりの VMware ですが、いきなりの大型爆弾投下ですね! ーーーimage

ーーーーー

<関連>

VMware が考える、ソフトウェア定義によるデータセンターとは?
VMware の考える SDN は、OpenFlow だけでは完成しない
VMware は OpenFlow を静観する_1
VMware は OpenFlow を静観する_2
VMware は OpenFlow を静観する_3

 

VMware は OpenFlow を静観する_3

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

VMware networking CTO on OpenFlow_3
http://wp.me/pwo1E-4oF
Shamus McGillicuddy Published: 19 Jun 2012
http://searchnetworking.techtarget.com/news/2240158351/VMware-networking-CTO-on-OpenFlow

_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

VMware は OpenFlow を静観する_2

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

VMware networking CTO on OpenFlow
http://wp.me/pwo1E-4oo

Shamus McGillicuddy Published: 19 Jun 2012
http://searchnetworking.techtarget.com/news/2240158351/VMware-networking-CTO-on-OpenFlow

_Tech Target

ーーーーー

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

ーーーーー

Question: In part two of our Q&A with Allwyn Sequeira, CTO and vice president of cloud, networking and security, we delve into VMware’s position on OpenFlow.

 Does the VMware networking strategy include support for OpenFlow?VMware のネットワーク戦略には、OpenFlow のサポートが取り込まれているのだろうか?

Sequeira: We are part of original team with the Open Networking Foundation and part of the founding team of ONRC [Open Networking Research Center] Labs.

私たちは、Open Networking Foundation のオリジナル・チームに属し、また、ONRC [Open Networking Research Center] Labs の創設メンバーでもある。

ーーー

Sequeira は、VMware における SDN and Network Virtualization の CTO である。 そして、以下は、Q&A に先立って、Sequeira との議論を整理したものである。

ーーー

If you look at SDN and OpenFlow, [they] prescribe a certain way of doing things. Extract the control plane, control the forwarding plane via the OpenFlow protocol, and have a centralized management scheme.

もし、あなあたが SDN と OpenFlow に注目しているなら、それを実現する確かな方式を、[彼ら]は規定していると思うべきだ。 それは、コントロール・プレーンを抽出し、OpenFlow プロトコルを介したプレーンの転送をコントロールし、そして、センタライズされたマネージメント・スキームを持つことである。

We are mostly there today. If all the equipment on the network were OpenFlow-enabled, we would be able quickly manipulate all boxes in the network via OpenFlow, and life would be good.

多かれ少なかれ、私たちは、現在という時勢に拘束されている。 もし、ネットワーク上のすべての装置が OpenFlow に対応するなら、OpenFlow を介したネットワーク上で、それらのボックスを操作できる。 そうすれば、すべてが上手くいくだろう。

The reality is that less than 1% of enterprise switches today are OpenFlow-enabled. So for our specific view, we will take an intermediate step. We will do SDNs and notions of Ethernet abstractions, network service abstractions like firewalls, load balancers, etc. It all dovetails with software defined networking, with a centralized control plane. With things like VXLAN we overlay the current network. And yet at a higher level from SDN perspective, we still realize the same services that SDN provides. Give me a network, allow me to add VMs to that network, plug in a firewall service; it preserves northbound APIs. But on the southbound side, rather than start with programming OpenFlow agents, we have overlay networks and VXLANs.

しかし、現実を見れば、エンタープライズ・スイッチで OpenFlow に対応しているものが、1% にも満たないことが分かってくる。 したがって、私たちは自身の視界を得るために、中間的なステップをとることになる。 つまり、SDN を Ethernet 抽象概念に取り組み、また、ファイアウォールやロードバランサといった、ネットワーク・サービスの抽象概念に取り組むことになる。 それら全てが、Software Defined Networking および、センタライズされたコントロール・プレーンと噛み合う。 つまり、VXLAN のようなものを用いて、既存のネットワークをオーバーレイしていく。 その一方で、SDN の視野に基づく高い抽象レベルにおいては、SDN が提供するものと同じサービスを、さらに理解する。 ネットワークを提供し、そこへの VM の追加を実現し、ファイヤーウォール・サービスを接続するような、軌道に沿った API を維持する。また、もう一方の軌道においては、OpenFlow エージェントのプログラミングよりも、オーバーレイ・ネットワークと VXLAN を活用していく。

imageNow as OpenFlow agents become available in the enterprise, we can map VXLANs on top of OpenFlow. VXLAN is an encapsulation that rides across the network. If the underlying network is OpenFlow-enabled, we can map the VXLAN and program the VXLAN across the underlying network. In the meantime, all the investments our customers made with northbound APIs and network virtualization, with VXLANs, all that is preserved. Then we can continue to evolve that network and go more into leveraging native OpenFlow when it has meaningful penetration of the enterprise market.

いまや、OpenFlow エージェントがエンタープライズで利用され始めているが、私たちは OpenFlow の上に、VXLAN をマップしている。 VXLAN はカプセル化され、ネットワークの向こう側に受け渡される。 もし、基本的なネットワークが OpenFlow 対応なら、VXLAN をマップすることが可能であり、また、それらのネットワークを横断するよう、VXLAN をプログラムすることが可能である。 その一方では、私たちの顧客による投資は、VXLAN に関連する API とネットワークの仮想化へと向けられ、その全てが維持されていく。 そして、OpenFlow がエンタープライズ市場に、意味のあるかたちで浸透していくとき、前述のネットワークを発展させ続け、また、OpenFlow の本質を活用することが可能となる。

It’s the same thing we did with server virtualization. In the early days we used to be on the outside looking in. Once you reach the point with 50% virtualization, you begin to optimize for virtual environments and bridge to the physical. The same [will happen] with networks. We are beginning to optimize for network virtualization and VXLANs. When OpenFlow reaches 50% penetration, we will optimize for OpenFlow. I look at this as a continuum rather than OpenFlow versus VXLAN. This allows us to bring OpenFlow into an organization gently versus a forklift upgrade. OpenFlow is a specific way to program the network, but SDN doesn’t mean you can only do it with OpenFlow.

それは、サーバーの仮想化において、私たちが行なってきたことに等しい。 その初期には、私たちは外から中を覗き込んでいる人に過ぎなかった。 そして、仮想化の比率が 50% に達すると、そのための環境を最適なものにし、また、物理環境とのブリッジを作り始めた。 それは、ネットワークにおいても同じであり、また、同じように展開するだろう。 そして、いま、私たちはネットワークの仮想化と VXLAN のための、最適化に着手し始めた。 そして、OpenFlow の浸透率が 50% に達するとき、OpenFlow を最適化していくだろう。 OpenFlow と VXLAN の関係については、対決というより連続的なものと見ている。 それにより、何らかの組織に OpenFlow を取り込むとき、フォークリフト的な極端なアップグレードではなく、穏やかな改善として取り扱うことが可能になる。つまり OpenFlow は、ネットワークをプログラムする際の、1つの方式に過ぎない。 それに対して SDN は、その相手を OpenFlow だけに限定するものでない。

続く>

ーーーーー

TAG index以前に、WMware の、こんなコメントを読んだことがあります。 ーーー 「 サーバーの仮想化はハードウェアを抽象化し、その上でソフトウェア走らせるようにする。 そして、その数だけの仮想マシンを、1台のサーバー上に配置できるようにする。 さらに、ネットワークの仮想化は、アプリケーションの要求に応じて、ケーブルとポートを抽象化していく。 しかし、それでは十分と言えない 」 ーーー 最終回である、その3 をお楽しみに。 ーーー __AC Stamp 2

ーーーーー

<関連>

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 を静観する_2

VMware は OpenFlow を静観する_1

Posted in .Selected, OpenFlow, SDN, Virtualization, VMware by Agile Cat on July 2, 2012

VMware networking CTO on SDN, OpenFlow and network virtualization
http://wp.me/pwo1E-4nj

Shamus McGillicuddy Published: 19 Jun 2012
http://searchnetworking.techtarget.com/news/2240158349/VMware-networking-CTO-on-SDN-OpenFlow-and-network-virtualization

_Tech Target

ーーーーー

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

ーーーーー

Although VMware is best known as a server virtualization company, its impact on the networking industry has been profound. VMware-based server consolidation has driven up bandwidth requirements; the embedded distributed virtual switch in VMware’s hypvervisor software has virtualized the server access layer of most data centers; and the dynamic nature of virtual machines is driving much of the competitive innovation in the data-center networking market today.

サーバーの仮想化を推進する企業として、VMware は最も有名な企業であるが、ネットワーク産業に対する大きな影響力も有している。 VMware ベースのサーバー・コンソリデーションは、帯域幅の要件を引き上げてきた。 また、VMware の ハイパーバイザー・ソフトウェアにエンベッドされた分散仮想スイッチは、大半のデータセンターにおけるサーバー・アクセス・レイヤーを仮想化してきた。そして更に、仮想マシンにおける動的な特性が、今日のデータセンター・ネットワーク市場における、競合のためのイノベーションを激しくドライブしている。

During his keynote at Interop Las Vegas recently, Steve Herrod, VMware CTO and senior vice president of R&D, introduced the concept of the software-defined data center, a term which is naturally evocative of one of the hottest areas of networking today: software defined networking (SDN). SearchNetworking.com spoke recently with Allwyn Sequeira, CTO and vice president of cloud, networking and security, to learn more about VMware’s views on the software-defined data center, network virtualization and SDN.

先日に Las Vegas で開催された Interop のキーノートで、VMware の CTO and Senior VP of R&D である Steve Herrod は、データセンターをソフトウェアにより定義していくというコンセプトを提起した。それは、現在のネットワーク市場において、最も人気のエリアである SDN を彷彿とさせるものである。 最近のことだが SearchNetworking.com は、同社の CTO and VP of Cloud, Networking and Security である Allwyn Sequeira にインタビューする機会を得た。 そして、ソフトウェアによるデータセンターの定義および、ネットワークの仮想化、そして SDN について、VMware の視点を聞き出すことに成功した。

Question: VMware has started promoting the concept of the software-defined data center. This sounds evocative of the software-defined-networking movement. Could you elaborate on this?

VMware は、ソフトウェアによるデータセンターの定義というコンセプトを促進し始めた。 それは、SDN の盛り上がりを彷彿とさせる。 その点について、詳述して欲しいのだが?

Allwyn Sequeira: The thinking was, we had vSphere and life was good. Now we need to virtualize the rest of the data center. As we started to evolve our thinking toward networking, the software-defined-networking momentum also happened to be in play at the same time. Most of our concepts of network virtualization, and some of the notions of SDN, are very applicable across network, compute, storage and security. It’s a natural evolution to take the SDN construct and parlay that into a larger construct, which is the software-defined data center. Over time, we expect to see less and less specialty hardware [in data centers] and more x86 hardware with specialty software.

その考え方は、私たちが vSphere を有し、また、それが上手くいっているという現実に根ざしている。 ただし、私たちは、データセンターにおける残りの部分を仮想化する必要性が生じてきた。 私たちの発想がネットワークの領域におよび始めるにつれて、SDN へ向けた推進力も、同時に高まってきている。 ネットワークの仮想化における大半のコンセプトと、SDN における若干のコンセプトは、ネットワーク/コンピュート/ストレージ/セキュリティのいたるところで、大いに適用できるものである。 それは、SDN の構成を自然に発展させたものであり、ソフトウェアによるデータセンターの定義という、さらに大きな構成を運用するものとなる。 長い時間をかけながら、データセンターにおけるハードウェア間の差異は減少し、また、ソフトウェアにより差別化された x86 ハードウェアが増えていくと、私たちは期待している。

The other theme is that the virtual machine [VM] as a container has stood up well and become the abstraction in the workload space, whether it be Amazon or VMware. The VM has become a unit of server virtualization and desktop virtualization. Likewise, what’s left of the data center, the virtual data center, becomes a new container.

もう 1つのテーマは、コンテナとしての仮想マシン[ VM ]が上手く立ち上がり、それが Amazon であろうと VMware であろうと、ワークロード・スペースの抽象概念になることである。 いまや VM は、サーバーの仮想化と、デスクトップの仮想化における、ユニットになっている。 それと同様に、データセンターへの取り組みにおいて残されているのは、仮想データセンターの概念であり、それが新しいコンテナになることだ。

imageQuestion: What do you mean when you speak of data centers being composed of x86 hardware with specialty software? Is this the VMware networking vision?

x86 ハードウェアと専用のソフトウェアで構成されるデータセンターについて話すとき、それは何を意味するのか? それは、VMware におけるネットワークのビジョンなのか?

Sequeira: A broader statement is x86 and merchant silicon is clearly the trend that exists. My point there is that the Ciscos of the world have spent lot of time and energy on ASICs, but a lot of software and control is increasingly happening on the x86 portion. Most of [data center] gear is headed that way. If you look at an F5 [Networks] device, it’s mostly x86s. Look at a Cisco ASA, where they have firewalls and load balancers. That’s all x86-based. We have versions of Cisco routers working with embedded hypervisors running on x86 to enable a whole bunch of VMs to run on them. If you look at some Cisco devices, they run with a hypervisor embedded. Not many people recognize it, but an increasing part of hardware, even in the Cisco world, is x86-based and merchant silicon. So the better way to say it is that X86 and commercial off-the-shelf merchant silicon is going to be prevalent in data center servers and the network itself.

広義の意味で x86 を引き合いに出しているが、トレンドとして存在するシリコン・シップという意味である。 私が指摘したいのは、Cisco たちの世界で、ASIC の開発に時間と神経が浪費されていることであり、また、ソフトウェアとコントロールにおける大半の部分が、x86 の領域に移行していることである。 データセンター・ギアにおける大半が、その方向へ向かっている。 F5 [Networks]  デバイスを見てみれば、その大半が x86 だと理解するだろう。 ファイヤーウォールとロードバランサーが集約される、Cisco ASA を見ると良い。 それは、完全に x86 ベースとなっている。私たちは、いくつかの Cisco ルーター・バージョンを持っているが、それらは x86 上で走るエンベデッド・ハイパーバイザーにより機能し、また、たくさんの VM を実行している。 いくつかの Cisco デバイスを確認してみれば、それらがエンベッドされたハイパーバイザーにより動いていることが解るだろう。 多くの人々が、そのことを認識していない。 しかし、Cisco の世界であっても、ハードウェアの役割が増大しているのは、x86 ベースの商用チップのパートである。 もう少し上手い言い方をすると、X86 および普及品のシリコン・チップが、データセンターにおけるサーバーとネットワークを構築していくことになる。

Question: I think Cisco might disagree with you. It continues to argue that ASICs give it an edge in the data center.

Cisco は、あなたと違う意見を持っていると思う。 同社は、データセンターにおけるエッジは、ASIC が握っていると主張し続けている。

Sequeira: If I were Cisco that’s what I would say. And if I were Cisco, I would still look at merchant silicon. If I purely based my franchise on merchant silicon, that really says the networking play moves to software. What I think they’re saying is that all that merchant silicon and x86 is fine, but when you get to higher and higher consolidation, there is still a need to scale out with rows of x86-based, top-of-rack switches. You still need to come out to core. And at the heart of it, you still need very fast switching silicon there, the likes of which are only produced by the Ciscos and Junipers of the world. And that is a valid statement.

もし、私が Cisco の人間なら、同じことを言うだろう。 そして、並行して、商用のシリコン・チップに注目するだろう。 さらに、商用人シリコン・チップの上に、私の基盤が確立するなら、ネットワークの舞台がソフトウェアに移行したと発言するだろう。彼らも、商用シリコン・チップや x86 について、素晴らしいと考えているはずだと、私も捉えているしかし、きわめて高度なコンソリデーションを行う場合には、ラック・スイッチの上に大量の x86 を並べて、スケールアウトする必要がある。 そこで、また議論はコアへと戻ってくる。 そして、その心臓部においては、依然として超高速のスイッチング・シリコンが必要となる。 それらは、この世界において Ciscos と Juniper だけが生産できるものである。 そして、それは妥当な発言である。

Any Cisco box has three components: input and output ports, software processing and then the fastpath. The fastpath — tagging and protocols — is where Cisco has always distinguished itself from its peers. Inside the very core of these boxes, having that fast and specialized silicon might make sense. But all the programmability and scale-out and manipulability will come out of the slowpath and control plane portions of these boxes.

あらゆる Cisco ボックスは、IN/OUT ポートと、ソフトウェア・プロセッシング、Fast Path という、3つのコンポーネントから構成される。 タグ付けとプロトコルに関する Fast Path は、常に Cisco が、他社に対して差別化しているポイントである。 それらのボックにの、きわめてコアな部分で、超高速の特殊なシリコンを有することは意味をなすだろう。 しかし、すべてのプログラミング能力および、スケールアウトとマニュピレーションは、それらのボックスにおけるコントロール・プレーンと Slow Path に依存するものとなる。

続く>

ーーーーー

TAG index2012年4月に VMware は、Open Networking Research Center という SDN に関する業界コンソーシアムを立ち上げるために、Stanford および Berkeley とチームを構成しています。 いくつかの企業は、ネットワークにおける急激な刷新(破壊)を共有しようと試みますが、サーバーの仮想化において、つまりハイパー・バイザで実績を積み上げてきた同社は、そのようには見ていないようです。ーーー __AC Stamp 2

ーーーーー

<関連>

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

 

 

 

 

 

Google の OpenFlow バックボーンは、どのように機能しているのか_2

Posted in Google, OpenFlow, SDN by Agile Cat on June 28, 2012

How Google’s OpenFlow backbone works
http://wp.me/pwo1E-4mm
By:
John Dix  On: 09 Jun 2012  For: Network World (U.S.)
http://www.itworldcanada.com/news/how-googles-openflow-backbone-works/145582

image

Using software-defined networking, the search engine giant gets close to 100 per cent utilization of its WAN links

Google は SDN により、その WAN 接続リソースを、100% に近いレベルで活用しているという。

ーーーーー

Google の OpenFlow バックボーンは、どのように機能しているのか_1

ーーーーー

● So you cut over this new network but didn’t take down the old one; what do you estimate the new network is accounting for in terms of your total inter-data center load?

この新しいネットワークをカット・オーバーしたわけだが、古いネットワークも保持している。データセンター間の全体的な負荷という観点で、この新しいネットワークを、どのように評価するのか?

Over a two-year period we have been shifting, incrementally, over to the new network, and it’s fair to say that a substantial majority of the traffic is now on the new network.

これまで、2年の期間をかけながら、新しいネットワークへと段階的に移行してきた。そして、公平に見て、いまでは大多数のトラフィックが、新しいネットワーク上に移り住んでいる。

● Was OpenFlow fully baked as you were implementing it, or did you have to improvise a lot?

OpenFlow を実装していたとき、その仕上がり具合はどうだったのだろう? 間に合わせて対処しなければならない点が、数多くあったのだろうか?

We had to improvise. OpenFlow is standardizing the interface, and I think this is very important for the community. So what OpenFlow and software-defined networking really enables us to do is separate the evolution path for hardware and software. In other words, you can get the hardware that meets your needs and separate that from the software that meets your needs for a particular deployment. Historically, those two things have been wedded together.

いろいろと、やるべきことがあった。 OpenFlow はインタフェースを標準化しているが、そのことは、コミュニティにとって最も重要だと思う。 つまり、OpenFlow と SDN が、私たちに提供する本質とは、ハードウェアとソフトウェアのための進化の経路を切り離すことである。言い換えれば、ニーズを満たすハードウェアの入手が可能となり、また、個々のディプロイメントに対応するソフトウェアから、それを分離できるようになった。 歴史的にみて、この 2つのものを、切り離せないでいた。

So from an OpenFlow standardization perspective, it’s very, very important to have hardware that can interoperate with a variety of software controllers. From our side, since we’re building our own hardware, that was less important. But we definitely had to improvise, and certainly the OpenFlow standard has evolved and we’ve had to be nimble with that internally.

したがって、OpenFlow における標準化の観点から、さまざまなソフトウェア・コントローラーとのインターオペラビリティを実現する、ハードウェアを有することが重要になってくる。自身でハードウェアを作っている私たちにとって、この件は、それほど重要でなかった。 しかし、いろいろと実施すべきことがあった。つまり、確実に進化している OpenFlow スタンダードに、迅速に対応しなければならなかった。

Did you have any setbacks of note?

副作用に関する注意点はあるのか?

I think Urs Hölzle [senior vice president of technical infrastructure and Google Fellow] said it best when he said it actually has gone more smoothly than he expected with less down time. The main issues we ran into from an OpenFlow perspective is the first version doesn’t fully allow you to take advantage of all of the hardware capabilities in modern switch silicon in an easy way. That’s not to say it’s not possible, it’s just not easy. So we have to do some work to get around some of those mismatches and, if you will, interface them. But this is now substantially improved from the OpenFlow standard perspective.

ダウンタイムの低減というより、スムースな運用に論点があると発言した、Urs Holzle [Senior Vice President of Technical Infrastructure and Google Fellow ]の言葉が、最もよく言い表していると、私は思う。 OpenFlow の展望に取り組み始めたときの、最初のバージョンにおける主要な問題は、最新のスイッチ・シリコンによるハードウェアの全能力を、容易に利用できない点にあった。 不可能だったとは言わないが、容易ではなかったのだ。 したがって、このミスマッチを取り除くために、いくつかの作業が必要になった。 いうなれば、インターフェイスに関連するものだ。しかし、それらの問題は、いまでは OpenFlow 標準の観点から、大幅に改善されている。

● How far away is OpenFlow from being fully baked?

OpenFlow が完全なものになるには、どれくらいの時間が必要になるのか?

I think it’s going to be a multi-year process, but the message we want to send is it’s at a point now where it’s incredibly useful and can deliver substantial benefits in a variety of settings.

長年にわたるプロセスが必要になると思うが、現時点で私たちが伝えたいメッセージは、多様なセッティングにおいて、驚くほど有用であり、また、多大なメリットをもたらすことである。

● Given the advantages, do you expect to see service providers move to OpenFlow?

アドバンテージが提供されるなら、サービス・プロバイダーたちは OpenFlow に移行していくと予測するか?

Well, we certainly hope so. What we’re hearing from the large service providers is that it is difficult to scale and make money. With OpenFlow I think we’ve demonstrated how to make your network much, much more efficient.

そうなることを、たしかに期待している。 大手のサービス・プロバイダーたちから聞いていることは、スケーリングと収益性に関する難しさである。 OpenFlow を用いることで、各種ネットワークの効率を大幅に高められることを、私たちは例証してきたと捉えている。

● What are the next steps?

次のステップは?

The whole industry is just getting going. I think five years from now we’re going to be able to look back with some sense of accomplishment. But we have the baseline for introducing new functionality and now we can do that much more rapidly than we could have otherwise. So for example, we have made the first steps in our optimization algorithms for managing traffic, but now we can deploy a whole range of new, more advanced optimization techniques. But at a technical level, we need to tighten the control loop. Today the time to measure, react and reprogram is a big challenge in software-defined networking overall because many of these software and hardware components weren’t designed for having a tight control loop. So we have to address that.

この業界全体が、淡々と前進している。 いまから 5年も経てば、いくつかの達成感が得られ、また、過去を振り返られると思っている。 しかし、新しい機能の導入に際して有用な、ベースラインになるものを、私たちは持っている。 そして、これまでと比較して、ずっと素早く、それらに対処できるようになった。 たとえば、トラフィックの管理において、私たちは第一歩となる最適化のアルゴリズムを持っている。 しかし、いまでは、全体をスコープとして最適化させていく、より進化したテクニックを有している。 ただし、テクニカルなレベルにおいて、コントロール・ループを引き締めていく必要がある。 現時点で進められている測定/対処/再プログラムは、SDN 全体における大きなチャレンジである。なぜなら、ソフトウェアとハードウェアにおける大半のコンポーネントが、タイトなコントロール・ループを持つようにデザインされていないからだ。 したがって、私たちは、それに取り組まなければならない。

● Is your network controlled from a single NOC(Network Operations Center)?

単一の NOC(Network Operations Center) から、ネットワークをコントロールするのか?

No, it is replicated and distributed for fault tolerance. And again, from a community perspective and certainly from our own perspective, coming up with the right software architectures to have in an SDN paradigm, replicated distributed control is fundamental. And getting that right in a repeatable way will be a very important challenge for the community in the next few years.

いや、フォールト・トレランスのために分散され、リプリケートされる。 繰り返しになるが、コミュニティの観点からして、また、私たちの観点からして、的確に SDN パラダイムを取り込んだソフトウェアのアーキテクチャが考案されていくが、そこでも、分散とリプリケーションのコントロールが基本となる。 そして、今後の数年においては、優れたリプリケーション方式の実現が、コミュニティにとって最重要のチャレンジになるだろう。

● Anything that we didn’t touch on that you think is important to get out?

あなたが重要と考え、また、私が見落としているものは?

One of the key points here is that the Internet has been remarkably successful and really couldn’t have gotten to the point that it’s gotten to without fully decentralized control and operation. But for it to get to the next level it does require logically centralized control. In other words, logical centralization can be fundamentally more efficient. We have built these amazing protocols over a 40-year period and now we’re essentially transitioning to maybe the next step in the Internet’s growth.

ここでキー・ポイントすべきものは、これまでのインターネットが、驚くほどの成功を収めている点に集約される。 それは、完全に分散された制御と管理がなければ、達成し得なかったものである。 しかし、次のレベルに達するためには、論理的なセンタライズが必要となってくる。 言い換えれば、論理的なセンタライズは、基本的ところで、より効率の良いものになり得る。 私たちは 40年の歳月をかけて、一連の驚くべきプロトコルを構築してきた。 そして、いま、インターネットの成長における次期ステップへと、本質的な意味で移行しているのだと思う。

<終わり>

ーーーーー

TAG indexOpenFlow から SDN へと向けて、Amin Vahdat さんの話し方が、だんだんと変化しているようにも思えます。 論理的なセンタライズという観念について、今後も語ってくれると良いですね。 今年の 1月にポストした、「OpenStack における SDN コネクションを探求する」という抄訳では、「SDN 構築を実現するためのテクノロジーの 1つが、OpenFlowである」と説明されています。 来週は、VMware が OpenFlow と SDN について語る、「VMware networking CTO on OpenFlow」の抄訳を予定しています。 Google との温度差が、とても興味深いです。 ご期待ください。 ーーー __AC Stamp 2

ーーーーー

<関連>

Google の OpenFlow バックボーンは、どのように機能しているのか_1
ーーーーー
Google 先生の OpenFlow 講座 – DC 間接続を低コストで達成するには
Google と OpenFlow と SDN について本音を語ろう – Urs Holzle
OpenFlow @ Interop 2012 のマトメ・ページ
Google が IaaS を立ちあげ、Amazon と Microsoft に挑んでいく

Comments Off on Google の OpenFlow バックボーンは、どのように機能しているのか_2

Google の OpenFlow バックボーンは、どのように機能しているのか_1

Posted in .Selected, Google, OpenFlow, SDN by Agile Cat on June 26, 2012

How Google’s OpenFlow backbone works
http://wp.me/pwo1E-4lL

By:
John Dix  On: 09 Jun 2012  For: Network World (U.S.)
http://www.itworldcanada.com/news/how-googles-openflow-backbone-works/145582

image

Using software-defined networking, the search engine giant gets close to 100 per cent utilization of its WAN links

Google は SDN により、その WAN 接続リソースを、100% に近いレベルで活用しているという。

ーーーーー

FRAMINGHAM, Mass. — Google, an early backer of software-defined networking and OpenFlow, shared some details at the recent Open Networking Summit about how the company is using the technology to link 12 worldwide data centers over 10G links. I caught up with Google principal engineer Amin Vahdat to learn more.

FRAMINGHAM, Mass. —  Google は SDN と OpenFlow を早い時期から支援してきており、また、先日の Open Networking Summit では、いくつかの詳細な情報を共有している。それは、このテクノロジーを用いて、世界の 12ヶ所に点在するデータセンターを、10G リンク上にリンクさせる手法に関するものである。そして、私は、さらなる詳細を知るために、Google の主任エンジニアである Amin Vahdat に話を聞いた。

ーーーーー

● Why did you guys set out down the OpenFlow path? What problem were you trying to solve?

なぜ、OpenFlow パスを辿ろうとしたのか? そして、どのような問題を解決しようとしていたのか?

We have a substantial investment in our wide-area network and we continuously want to run it more efficiently. Efficiency here also meaning improved availability and fault tolerance. The biggest advantage is being able to get better utilization of our existing lines. The state-of-the-art in the industry is to run your lines at 30 per cent to 40 per cent utilization, and we’re able to run our wide-area lines at close to 100 per cent utilization, just through careful traffic engineering and prioritization. In other words, we can protect the high-priority traffic in the case of failures with elastic traffic that doesn’t have any strict deadline for delivery. We can also route around failed links using non-shortest path forwarding, again with the global view of network topology and dynamically changing communication characteristics.

私たちは、広域ネットワークに対して多大な投資を行なってきたが、これからも継続的に、効率のよい運用を目指していきたい。 そこでの有用性とは、可用性の向上とフォールト・トレラントの改善のことである。 最大の長所は、私たちの既存のラインを、より良いかたちで利用できる点にある。これまでだと、この業界の最新技術を用いるにしても、一般的な利用効率 30% ~ 40% に留まっていた。しかし、私たちは、トラフィックを工学的に捉え、その優先順位付けに注意深く対応するだけで、100% に近いレベルで自身のラインを活用できている。 言い換えれば、配送において厳密な期限を持たない、エラスティック・トラフィックによる優先性を、失敗が生じたケースにおいても高いレベルで維持できる。さらに、非最短路のフォワーディングを用いて、失敗したリンクをルーティングすることも可能だ。 その時には、ネットワーク・トポロジのグルーバル・ビューを再利用し、また、コミュニケーションの特質を動的に変更していく。

Standard network protocols try to approximate an understanding of global network conditions based on local communication. In other words, everybody broadcasts their view of the local network state to everybody else. This means if you want to affect any global policy using standard protocols you’re essentially out of luck. There is no central control plan that you can tap into. So what OpenFlow gives us is a logically centralized control plan that has a global view of the entire network fabric and can make calculations and determinations based on that global state.

標準的なネットワーク・プロトコルは、ローカルな通信をベースにして、グルーバル・ネットワークの条件を理解しようとする。 言い換えれば、すべての人々から、すべての人々へと、ローカル・ネットワーク・ステートのビューがブロードキャストされる。 つまり、標準的なプロトコルを用いて、グローバル・ポリシーに影響を与えようとしても、その本質からして上手くいかないことを意味する。 つまり、あなたがアクセスすることが可能な、センタライズされたコントロールの仕組みが存在しないのだ。 したがって、OpenFlow が提供するものは、全体的なネットワーク・ファブリックのグローバル・ビューを持ち、論理的にセンタライズされたコントロールの仕組みとなる。 そして、それらはグローバル・ステートに基づいた計算と判断を可能にする。

● One hundred percent utilization is incredible. And you can do that without fear of catastrophe?

100% の有用性は信じ難いことである。 それにしても、大惨事を恐れることなく、それを実現できるのか?

Right, because we can differentiate traffic. In other words, we are very careful to make sure that, in the face of catastrophe, the traffic that is impacted is the relatively less important traffic.

言い換えれば、大惨事に直面するときには、相対的に重要度の低いトラフィックが、影響を受けるトラフィックになるよう、きわめて慎重に確認している。

● Is control of the network completely removed from the routing hardware and shifted to servers?

ネットワークのコントロールは、ルーティング・ハードウェアから完全に取り除かれ、サーバーに移行されるのか?

You used an interesting word — completely. There’s going to be some vestiges of control left back on the main device, but maybe for simplicity’s sake let’s say it’s completely removed. We’ve shifted it from running on an embedded processor in individual switches — and that embedded processor is usually two or three generations old; if you open up a brand new switch today it wouldn’t surprise me if you found an 8-year-old Power PC processor — to a server, which could be the latest generation, multicore processor, etc. So getting 10X performance improvements is easy and even more than that isn’t hard.

その「完全に」というのは、面白い単語である。 メイン・デバイス上には、コントロールが取り除かれたという若干の痕跡があるだろうが、話を簡単にするために、完全に取り去られたと言おう。 個々のスイッチにエンベッドされたプロセッサで、コントロールを実行するという方式を廃止した。 (それらのエンベッドされたプロセッサは、一般的に2世代から3世代ほど古いものとなる。 真新しいスイッチを分解してみれば良い。8年も昔の Power PC processor が出てきても、私は驚かない) つまり、最新のマルチコア・サーバーへと、移行させることになった。 したがって、10倍のパフォーマンスを得ることが可能となったが、それは難しいことではない。

● I understand you built your own gear for this network?

このネットワークのために、独自のギアを構築していると理解してよいか?

We built our own networking gear because when we started the project two years ago there was no gear that could support OpenFlow.

私たちが独自に構築した背景には、このプロジェクトがスタートした2年前に、OpenFlow をサポートするギアが無かったという理由がある。

● Will you continue to use your homegrown gear or make the shift as companies come out with OpenFlow tools?

これからも、独自のギアを使い続けるのか? それとも、他社が OpenFlow ツールを発表するなら、そちらにシフトするのか?

Our position is that, once there are switches out there that deliver the functionality we need with a nice OpenFlow agent, we would be very open to them.

私たちの立場は、必要とする機能を提供するスイッチと、素晴らしいOpenFlow エージェントが登場するなら、それらに対してきわめてオープンに取り組むものとなる。

● Is there a hell of a lot of difference between a switch and a server these days anyway, beside the interfaces, obviously?

最近のスイッチとサーバーの間には、インタフェースに関連する大きな差異が、明確に存在するのか?

Great question. I think that there is a fair amount of difference in terms of instruction set and flexibility, but there certainly is an increasing amount of similarity. One thing I think the switching world would benefit from is an increasing amount of programmability. Having more flexibility in being able to do different things with different bits in your packets would be useful. There are some startups looking in this direction.

重要な論点だ。 インストラクション・セットと柔軟性に関して、かなりの相違があると思うが、確実に類似点が増えてきている。 スイッチの世界がメリットを得るだろうと思うものに、プログラミング能力の向上がある。 個々のパケットにおける特定のビットを用いて、各種の処理を実現する柔軟性を持つことは、有用なものとなるだろう。 この方向性に注目している、いくつかのスタートアップがある。

● I understand another key benefit of SDN/OpenFlow is being able to play with a lot of “what if” scenarios to enable you to fine-tune the network before going live.

SDN / OpenFlow の主要なメリットとして、「もし ~だったら」シナリオに対応する能力があると考える。それにより、ネットワークを実運用する前に、微調整が可能となる。

Exactly. So one of the key benefits we have is a very nice emulation and simulation environment where the exact same control software that would be running on servers might be controlling a combination of real and emulated switching devices. And then we can inject a number of failure scenarios under controlled circumstances to really accelerate our test work.

まさに、そのとおりだ。 そして、私たちにとっての重要なメリットの 1つは、きわめて洗練されたエミュレーションとシミュレーションの環境である。サーバー上で走るものと完全に同じコントロール・ソフトウェアにより、現実と架空のスイッチ・デバイスを結合できる。 そして、私たちはテストの進捗を加速させるために、制御された状況の下で、数多くの不具合シナリオを投じることができる。

● Are you actually pumping in fake traffic?

実際に、偽のトラフィックを送り込むのか?

Yes, there’s some amount of fake traffic. Obviously, we’re not necessarily able to reproduce the complete scale. The nice thing is, if you think in terms of the total amount of traffic we might have in a data center, it’s going to be substantially larger than total WAN traffic, so while our WAN traffic is substantial, LAN traffic is substantially more.

そうだ、若干量の偽トラフィックがある。 完全なスケールを、必ずしも再現しなくても構わない。私たちがデータセンターに保持している、トラフィックの総量という観点で考えるなら、全体的な WAN トラフィックより、それの方が大きくなるところが好都合だ。つまり、私たちの WAN トラフィックは相当量であるが、LAN トラフィックは更に大きなものとなっている。

<続く>

ーーーーー

TAG index今月の前半に見つけた記事ですが、けっこう長いので、なかなか手を付けられずにいました。 ただ、その内容は、Google における SDN と OpenFlow について、詳細までを伝えてくれる貴重なインタビューだったので、こうして抄訳ができて、ほっとしているところです。 その_2 となる後半も、すでに下訳が終わっていますので、近々にポストできると思っています🙂 ご期待くださ~い! ーーー __AC Stamp 2

ーーーーー

<関連>

Google の OpenFlow バックボーンは、どのように機能しているのか_2
ーーーーー
Google 先生の OpenFlow 講座 – DC 間接続を低コストで達成するには
Google と OpenFlow と SDN について本音を語ろう – Urs Holzle
OpenFlow @ Interop 2012 のマトメ・ページ
Google が IaaS を立ちあげ、Amazon と Microsoft に挑んでいく

 

 

 

Comments Off on Google の OpenFlow バックボーンは、どのように機能しているのか_1

OpenFlow @ Interop 2012 のマトメ・ページ

Posted in .Chronicle, Events, OpenFlow by Agile Cat on June 25, 2012

Cloud News Japan から抽出しました・・・
http://wp.me/pwo1E-4lF

OpenFlow Category
http://cloudnewsj.com/category/openflow/

OpenFlow 祭り さながらだった Interop 2012 の、マトメ・ページです。 Google で検索しても、ヒットしてしまうトピックが余りにも多すぎて、必要な情報が得られませんでした。 そんなときに頼りになるのが、この Cloud News Japan のカテゴリです。 以下は、同サイトのカテゴリからリスト・アップした、OpenFlow 関連の情報です。ーーー __AC Stamp 2

ーーーーー

NTTデータが OpenFlow コントローラーを独自開発、2012年内に発売
Posted on 2012/06/10 
NTTデータは2012年6月8日、同社が開発したOpenFlowコントローラー「バーチャルネットワークコントローラVer2.0」の販売を開始すると発表した。ソフトウエア製品で、発売時期は2012年内。同ソフトウエアを利用したネットワーク構築、システム開発、導入コンサルティングサービスなどを含め、2013年度に1年間で10億円の売り上げを目指す。

NTTデータ、overlay と hop-by-hop に対応した OpenFlow コントローラ
Posted on
2012/06/11
株式会社NTTデータは8日、SDN(Software-Defined Networking)関連ビジネスを2012年中に本格開始すると表明。あわせて、同社が開発中のOpenFlowコントローラ・ソフトウェアの新バージョン「バーチャルネットワークコントローラ Ver2.0」の概要紹介を行った。

OpenFlowを最大活用!NTT Com のグローバルクラウド始動
Posted on
2012/06/12
6月11日、NTTコミュニケーションズはOpenFlowによるネットワーク仮想化技術を採用した新クラウドサービス「Bizホスティング Enterprise Cloud」を発表した。グローバルネットワーク「Arcstar Universal ONE」と直結し、2012年度内には全世界8箇所で展開される予定となっている。Bizホスティング Enterprise Cloudは、「通信事業者ならではのクラウドサービス」を目指すべく昨年11月に発表した「グローバルクラウドビジョン」に基づいた初の商用サービス。

image「INTEROP Tokyo 2012」への出展について
[NTTコミュニケーションズ]

Posted on
2012/06/12
NTTコミュニケーションズグループは、2012年6月13日(水)~15日(金)に幕張メッセで開催される「INTEROP Tokyo 2012」に出展します。NTTコミュニケーションズグループブースでは、「Seamless Cloud for the World」のコンセプトのもと、ネットワークの仮想化技術を活用した世界初の企業向けクラウドサービス「Bizホスティング Enterprise Cloud」のデモンストレーションをはじめ、さまざまなサービスを展示します。

NTT Com、ネットワーク仮想化を活用したセルフマネージメント型クラウド
Posted on
2012/06/13 
NTTコミュニケーションズ(NTT Com)は、2011年10月に発表した「グローバルクラウドビジョン」に基づく初のサービスとして、企業向けのプライベートクラウドサービス「Bizホスティング Enterprise Cloud」を6月29日より提供すると発表した。

未来のネットワークはすべて SDN ベースに- OpenFlow標準化団体のダン・ピット氏
Posted on 2012/06/13
今週開催される「Interop Tokyo 2012」に合わせ来日した Open Networking Foundation(ONF)のエグゼクティブ・ディレクター、ダン・ピット(Dan Pitt)氏は6月11日、ONFの記者説明会に出席し、ONFの目指す目標、Software Defined Network(SDN)や「OpenFlow」プロトコルの価値、Interop Tokyoで公開されるOpenFlowデモンストレーションなどについて語った。

NTTグループの「OpenFlowコミット」で日本市場は大きく変わる?
Posted on 2012/06/14
6月13日、ネットワークの総合イベント「Interop Tokyo 2012」の展示会がスタートした。IPv6や40/100GbE、スマホ対応、ファブリックなどを抑えて、今年のテーマとなったのはOpenFlowだ。各社のブースを見ていこう。今年のInteropのテーマは、ずばりOpenFlowだ。展示会場でも、OpenFlow ShowCase 展示&デモンストレーションが用意されている。グローバルで見ても、日本でのOpenFlowへの関心がきわめて高く、昨年はブロケードCEOをして「日本はOpenFlowクレイジーだ!」と言わしめたほど。しかし、昨年のInteropでほぼ影も形もなかったOpenFlowが、ここまで大きくなると想像した人はあまり多くなかったのではないだろうか?

OpenFlow を世界規模で活用した
NTTコミュニケーションズのクラウド

Posted on
2012/06/15
NTTコミュニケーションズの「Bizホスティング Enterprise Cloud」は、グローバル展開を図る企業がプライベートクラウドを運営するためのホスティングサービスである。このためにネットワーク仮想化技術「OpenFlow」をデータセンター間にも活用しているのが特徴。

IBM PureSystems は IT の新常識を提案する–SDN/OpenFlow にも対応
Posted on
2012/06/19 
「Interop Tokyo 2012」3日目となる6月15日、米IBM システムズ&テクノロジー・グループ システムズ・チーフ・エンジニアでIBMフェローも務めるGururaj Rao(グルラジ・ラオ)氏による「新たなコンピューティング時代の幕開け~ITの常識と経済性を根底から変えるIBM PureSystemsの全貌~」と題した基調講演が行われた。同社が発表した「
IBM PureSystems」がビッグデータ時代において求められる、ITの新たな常識を提案するものであることを強調する内容となった。

Interop Tokyo 2012:SDN、OpenFlow に注目集まる
Posted on
2012/06/19 
ネットワーク関連技術のイベント「Interop Tokyo 2012」が6月13~15日(コンファレンスは6月12~15日)幕張メッセで開催された。SDN(Software Defined Network)、OpenFlowのユースケースが多数展示、展示会初日の13日は約3万7000人が足を運んだ。

NTT Com、ネットワーク仮想化を使ったプライベートクラウドサービスを発表
Posted on
2012/06/19 
NTT コミュニケーションズ(NTT Com)は2012年6月11日、ネットワーク仮想化技術を採用したプライベートクラウドサービス「Bizホスティング Enterprise Cloud」を発表し、「INTEROP TOKYO 2012」で展示を行った。6月29日に提供を開始する。同サービスは、ネットワーク制御技術「Openflow」を商用化し、より広範囲に提供できるよう検証を重ねて開発したという。世界展開しているデータセンターを、1つの拠点として管理・設定できるのが特長だ。

OpenFlow はクラウド時代のセキュリティを変えるか?
Posted on
2012/06/20  
6月13日から15日まで開催されたInterop Tokyo 2012の出展社数は、前年を大きく上回る370社超(各種併設イベント含む)で、100GBの伝送技術やOpenFlow/SDN(Software Defined Network)に関連する展示でにぎわった。とくにOpenFlowは、クラウド環境や仮想化サーバ環境において、ネットワークの構成も仮想化し、物理的なサーバや回線にとらわれない柔軟な設定が可能として非常に注目された。今回はこのOpenFlowをセキュリティ対策の面から評価してみたい。

クラウド・OpenFlow で元気を取り戻した今年の Interop
Posted on
2012/06/23 
今年のInteropについて、社団法人日本ネットワークインフォメーションセンター(JPNIC)インターネット推進部部長の前村昌紀氏にうかがった。出展者もお客さんも、みんな元気でしたが、昨今のインターネットの一大トレンドであるクラウド・コンピューティング、そしてOpenFlowという、ふたつの技術に寄るところが大きいのではないでしょうか。クラウドは様々なユーザーに対するサービス基盤として拡大し続けており、クラウドによって通信サービスが活性化するという図式が明確なものとなっています。

ーーーーー

TAG indexまさに、話題沸騰の OpenFlow ですが、以下のリンクにもあるように、それぞれの利用者としての立場から、とても興味深いコメントを発信しているのが、VMware と Google です。 よろしければ、それらの関連情報も、合わせて ご覧ください。 ーーー __AC Stamp 2 

ーーーーー

<関連>

VMware の考える SDN は、OpenFlow だけでは完成しない
Google と OpenFlow と SDN について本音を語ろう – Urs Holzle
Google 先生の OpenFlow 講座 – DC 間接続を低コストで達成するには
OpenStack における SDN コネクションを探求する _1
OpenStack における SDN コネクションを探求する _2

Comments Off on OpenFlow @ Interop 2012 のマトメ・ページ

VMware の考える SDN は、OpenFlow だけでは完成しない

Posted in .Selected, OpenFlow, SDN, VMware by Agile Cat on April 25, 2012

VMware isn’t going to let network virtualization pass it by
http://wp.me/pwo1E-491
By
Stacey Higginbotham Apr. 11, 2012
http://gigaom.com/cloud/vmware-isnt-going-to-let-network-virtualization-pass-it-by/

_ Gigaom

VMware teamed up with Stanford and Berkeley on Tuesday to create an industry consortium around software defined networks, called the Open Networking Research Center. The company, famous for hypervisors that virtualize servers isn’t about to watch while companies attempt to build the same disruption in networking. The consortium counts CableLabs, Cisco, Ericsson, Google, Hewlett-Packard, Huawei, Intel, Juniper, NEC, NTT Docomo, Texas Instruments and VMware as its founding sponsors.

この火曜日に VMware は、Open Networking Research Center という SDN に関する業界コンソーシアムを立ち上げるために、Stanford および Berkeley とチームを構成した。 いくつかの企業は、ネットワークにおける急激な刷新(破壊)を共有しようと試みるが、サーバーの仮想化において、つまりハイパー・バイザで実績を積み上げてきた同社は、そのようには見ていないようだ。なお、このコンソーシアムは、CableLabs/Cisco/Ericsson/Google/Hewlett-Packard/Huawei/Intel/Juniper/NEC/NTT Docomo/Texas Instruments/VMware を、そのファウンディング・スポンサーとして数える。

Much as server virtualization abstracts the hardware for the software that runs on it, allowing people to put different virtual machines on top of one server, virtualizing the network abstracts the cables and ports from the demands of the applications. But that’s not enough. To really achieve the flexibility that webscale and cloud companies demand, the network must be both virtualized and programmable.

サーバーの仮想化はハードウェアを抽象化し、その上でソフトウェア走らせるようにする。 そして、その数だけの仮想マシンを、1台のサーバー上に配置できるようにする。 さらに、ネットワークの仮想化は、アプリケーションの要求に応じて、ケーブルとポートを抽象化していく。 しかし、それでは十分と言えない。 Web スケールとクラウド・カンパニーが必要とする柔軟性を、ほんとうの意味で達成するには、仮想化とプログラマブルという要因をネットワークに加えなければならない。

The current enabler for this shift in networking is OpenFlow, a protocol developed out of Stanford and championed by a group formed last March called the Open Networking Forum. Many of the companies that have joined the VMware at the ONRC are also members of the ONF, including VMware. OpenFlow is a means to separate the intelligence associated with moving packets around the network with the gear that does the moving. At that point the intelligence can run on commodity servers, a factor that was seen as bad news for Cisco, Juniper and other networking companies which may see their margins drop and profits erode.

現時点において、このネットワークのシフトを可能にする存在は、Stanford で開発されたプロトコルの OpenFlow となる。それは、この 3月に組織化された、Open Networking Forum というグループにより支持されている。 ONRC で VMware と行動をともにする数多くの企業は、この ONF のメンバーであり、また、VMware も参加している。 OpenFlow とは、パケットを転送する装置を用いて、ネットワーク上を飛び交うパケットから、インテリジェンスを分離するための手段である。 その点において、このインテリジェンスは普及品サーバーで動作するため、Cisco や Juniper などのネットワーク・デバイス会社にとって BAD ニュースとなる。 なぜなら、それらの企業はマージンが下がり、利益が圧迫されるからだ。

imageAllwyn Sequeira, CTO and VP for security and networking for VMware says that the creation of the ONRC is designed to push the concepts of software defined networks in general rather than the OpenFlow protocol. He said an SDN requires three elements: a controller that manages the networking gear; the controller protocol fused to control the devices (this may not be OpenFlow); and the apps on top of the controller that direct the network.

VMware の CTO であり、 VP for Security and Networking でもある Allwyn Sequeira は、OpenFlow プロトコルというより SDN のコンセプトをプッシュするところに、ONRC を結成した意味があると発言している。 SDNを構成するには、① ネットワーク・ギアを管理するコントローラおよび、② いくつかのデバイス(OpenFlow 非対応も含む)を制御するために結合されたプロトコルのコントローラ、そして、③ コントローラを介してネットワークを操作するアプリケーションという、3つの要素が必要になると彼は言う。

And he notes that OpenFlow adds the critical element of programmability to networking, likely residing in the controller with other protocols, but the creation of a software defined network doesn’t need it. He points to VMware’s own firewall and load balancing products as well as its VXLAN and other networking software as an example.

また、OpenFlow などのプロトコルを用いる既存のコントローラには、ネットワークをプログラミングするための重要な要素が加えられているが、それらが SDN の作成において必要とされることはない、彼は指摘している。 なぜなら、VMware のファイヤー・ウォールやロード・バランシングのプロダクトに加えて、VXLAN などのネットワーク・ソフトウェアが、その例として挙げられるからだと、彼は言う。

VMware’s networking products.

That’s a common argument from the industry, with folks from Juniper and Cisco pointing to their existing fabrics and products as an example of network virtualziation. So the key for the ONCR and the industry moving forward seems to be about how to make SDNs programmable since they already exist. Sequeira says this requires OpenFlow.

それは、仮想ネットワークの例として、現存のファブリックとプロダクトを指し示す、Juniper や Cisco のテーマというより、この業界における共通のテーマとなる。 この業界と ONCR には、すでに存在する資産があるため、SDN をプログラマブルにする方式が重要となり、また、それを模索しながら前進していくと思われる。 そして Sequeira は、そのために OpenFlow が必要になると発言している。

“We had a complete SDN stack with no OpenFlow and it was good enough for almost all the things that customers wanted to do,” Sequeira said. “There is the virtualization of the switches and firewalls and none of that requires OpenFlow. However, to program it requires OpenFlow even though even a little of that can be done without it.”

「 私たちは、OpenFlow に頼ることなく、完璧な SDN スタックを積み上げており、それは、ほとんど全ての顧客の要求に対応できる。 スイッチとファイアーウォールの仮想化は存在しており、そこでは、少しも OpenFlow を必要としない。 しかし、それをプログラムするためには、すべてにおいて必要というわけではないが、OpenFlow が要求される」と Sequeira は発言している。

And while Sequeira recognizes the importance of OpenFlow, he doesn’t see some wholesale migration to OpenFlow-only networks. Current networking software and gear will work with OpenFlow but will not solely use the protocol. Which, given the statements by Urs Hölzle, SVP of technical infrastructure at Google, that there is no easy way for OpenFlow to communicate with other network protocols, have me thinking that we’re going to need more efficient ways to communicate from one network protocol to OpenFlow.

そして Sequeira は、OpenFlow の重要性を認識する一方で、いくつかの Wholesale は OpenFlow-ony ネットワークへ移行しないだろうと見ている。 最新のネットワークを構成するソフトウェア/ギアは、OpenFlow に対応するだろうが、そのプロトコルだけを使うわけではない。 Google の VP of Technical Infrastructure である Urs Holzle のステートメントを前提にすると、OpenFlow と他のネットワーク・プロトコルを連携させるための、容易な方式は無いということになる。 つまり、こうした現実から生じるものとして、他のネットワーク・プロトコルから OpenFlow にコミュニケートするための、より効率の良い方式が求められるようになってくる。

So the biggest battle in SDNs looks like it will be for the controller, which companies such as IBM, Nicira and Big Switch have developed. The question is: will OpenFlow be the lingua franca between rival controllers or will each strive to create it’s own proprietary network — programmable, running on commodity hardware, but still a fundamentally locked ecosystem?

したがって、SDN における最大のバトルは、IBM/Nicira/Big Switch などが開発を進めている、コントローラに関するものになるだろう。 残される疑問は、以下のとおりである。 まず、OpenFlow は、ライバルであるコントローラ間の共通語になる気があるのか? それとも、それぞれのプロトコルは、自身によるプロプライエタリ・ネットワークを構築するために競い合うのか?つまり、プログラマブルであり、コモディティ・ハードウェア上で走るにしても、基本的にはロックインされているエコシステムに過ぎないのか?

Related research and analysis from GigaOM Pro:

ーーーーー

TAG indexこの辺りの、OpenFlow をめぐる議論が、これから活発になってくるのでしょうね。 以前にポストした「OpenStack における SDN コネクションを探求する」にも、似たような記載がありました。 これは、OpenStack に OpenFlow を取り込む場合の記事ですが、VMware の指摘と同じことが語られています。 前後編で、ちょっと長いですが、お薦めのコンテントです。 ーーー __AC Stamp 2

したがって、OpenStack における Quantum と OpenFlow は、機能的に補完関係にあると説明されている。 ただし、Urquhart が指摘するように、OpenFlow の位置づけは、Quantum 抽象概念上のプラグインから利用できる、1つのメカニズムに過ぎない。 その点について、心に留めておいてもらいたいのは、OpenStack wiki で詳細に記述されるように、「OpenStack ネットワークにプラグインされる先進的なネットワーク・サービス(オープン・ソース/クローズド・ソース)」を構築するために、また、先進的なネットワーク機能を導入する、新しいプラグインの開発を容易にするために、Quantum  の利用が可能だという点だ。

ーーーーー

<関連>

Google と OpenFlow と SDN について本音を語ろう – Urs Holzle
Google 先生の OpenFlow 講座 – DC 間接続を低コストで達成するには
OpenFlow 1.2 が ONF の評議会で承認された – NTT Com も委員に
Juniper がデベロッパーに対して、OpenFlow ソースコードを提供し始めた
OpenFlow 関連ポストへのリンク集(20本強)

 

Comments Off on VMware の考える SDN は、OpenFlow だけでは完成しない

%d bloggers like this: