Agile Cat — in the cloud

ネットワークの仮想化へ向けた論証 – Ben Cherian

Posted in .Selected, Network, OpenFlow, SDN, Virtualization by Agile Cat on March 7, 2013

Making a Case for Network Virtualization

Ben Cherian, Chief Strategy Officer, Midokura – January 24, 2013

_ all things D

At the beginning of this century, server virtualization burst onto the IT scene and changed the way modern IT organizations think about server hardware. The basic concept behind server virtualization is that multiple “virtual” servers can be run on a single physical server. This consolidation of servers resulted in much higher utilization of physical servers, which dramatically reduced the capital expenditure (capex) costs required to provide IT services. Using fewer physical servers also lowered power, cooling and datacenter space requirements. Other indirect benefits were increased agility, since the IT department could provision a server in minutes or hours versus the weeks and months it used to take to procure, set up and turn on new physical servers.

今世紀の初めに忽然として登場したサーバーの仮想化が、ハードウェア・サーバーを検討している近代的な IT 組織の、考え方を変えてしまった。 サーバーの仮想化を背後から支える基本概念は、単一の物理サーバー上で多数の仮想サーバーを走らせらるというものである。 このサーバー・コンソリデーションは、物理サーバーの有用性を大幅に高め、IT サービスの提供に必要とされる CAPEX(capital expenditure)を劇的に削減することになった。 さらに、使用する物理サーバーの数を減らすことで、使用電力および、冷却のコスト、そして、必要とされるデータセンター・スペースも引き下げられた。 その他の間接的なメリットしては、IT 部門が数分あるいは数時間で、サーバーをプロビジョニングできるようになるという、アジリティが挙げられる。それに対して、仮想化が始まる前は、新しい物理サーバーを入手し、設定し、電源を入れるまでに、数週間から数ヶ月が必要だったはずだ。

Image copyright Johannes Kornelius

By all accounts, server virtualization adoption has been extremely successful. One look at VMware’s revenue numbers and there’s no doubting this fact. In the early 2000s, the predominant question that many in IT asked was, “Why should I virtualize?” Today, the predominant question you’ll hear is, “Why can’t the servers be virtualized?”

誰に訊いても、サーバーの仮想化に関する適用は、素晴らしい成功を収めてきた。 VMware の収益を一目見れば、この事実を疑わなる。 2000年代の初期には、IT に従事する多くの人々が、「なぜ 仮想化すべきか?」という質問を繰り返していた。 そして、いま、人々が繰り返す質問は、「なぜ サーバーを仮想化できないのか?」である。

The rise of self-service IT

We’re going through a similar paradigm shift today with self-service IT. Internal business units want the breadth of services and speed of provisioning that they can get outside of the firewall through cloud service providers like Amazon Web Services. In response, forward-thinking IT departments have been changing their traditional role into one that looks more like a service provider and have begun offering a full menu of solutions to their constituents. One of the staples on the menu is a private Infrastructure-as-a-Sevice (IaaS) cloud offering. A few concrete business drivers underlying this offering are:

いま、私たちは、セルフ・サービスの IT を用いて、そのときと同様のパラダイム・シフトを体験している。 社内のビジネス・ユニットが望むものは、幅広いサービスの選択肢と、プロビジョニングのスピードであるが、たとえば Amazon Web Services などのクラウド・サービス・プロバイダを介して、それらをファイヤー・ウォールの外側で得ることができる。 それに応えるかたちで、前向きな IT部門は、サービス・プロバイダーのような業者に、従来からのロールを移行している。 そして、彼らが構成する要素の中で、フルメニューのソリューションを提供し始めている。 そのメニューに欠かせないものとして、プライベート IaaS クラウドの提供がある。 この提供物の基礎となり、また、具体的にビジネスを推進していくものは、以下のとおりである:

  • Fine-grained control over the infrastructure which lowers risk and increases ability to deal with compliance concerns
  • A lower cost when compared to external services like Amazon
  • Lowered operational expenditures with regard to provisioning resources
  • A much faster provisioning speed than internal IT typically offers
  • Better disaster recovery options
  • Increased application availability
  • コンプライアンにおける関心事を取り扱うための、インフラストラクチャの制御。それを微調整することで、リスクを低減し、能力を増大していく
  • Amazon のような外部のサービスに対抗し得る、低コストの実現
  • リソースのプロビジョニングに関連する、運用コストの低減
  • 一般的な社内 IT よりも迅速な、プロビジョニングのスピード
  • 災害からのリカバリーに関する、より優れた選択肢
  • アプリケーションの可用性を向上させる

Elements of an IaaS cloud

There are four elements needed to build an IaaS cloud: a cloud management system, compute (also known as the hypervisor), storage and networking. The cloud management system handles all the provisioning and orchestration of the underlying compute, storage and network components. Examples of such systems are OpenStack, Citrix CloudStack, Eucalyptus and VMware’s Vsphere product.

IaaS クラウドを構築するには、マネージメント・システムおよび、コンピューティング(ハイパーバイザー)、ストレージ、そしてネットワークという、4つの要素が必要とされる。 マネージメント・システムにより、すべてのプロビジョニングとオーケストレーションが処理され、それが、コンピューティング、ストレージ、そしてネットワークの基礎となる。 このようなシステムの例としては、OpenStack および、Citrix CloudStack、Eucalyptus、VMware Vsphere といったものが挙げられる。

For compute, storage and networking, cloud architects look for solutions that linearly scale out (adding new capacity incrementally) rather than scaling up (buying bigger devices). This approach keeps costs low by consistently maximizing utilization. Even if cost weren’t an issue, this scale out approach is highly favored because it increases availability and reduces service interruptions of your cloud. In a well-thought distributed IaaS design, a single large device would never be an integral component of your cloud. Adhering to distributed design philosophies is a key reason why cloud service providers can consistently achieve very high levels of availability.

コンピューティング、ストレージ、ネットワークに関しては、クラウド・アーキテクトがソリューションを探すことになるが、それらはスケールアップ(大容量デバイスの購入)ではなく、リニアにスケールアウト(キャパシティの追加)していくものになる。このアプローチにより、最大の有用性を連続して保ち、コストを低く抑えていくことが可能になる。たとえ、コストが問題視さればいケースでも、このスケールアウトのアプローチは、クラウドの可用性を高め、停止を抑制するため、必ず好まれるはずだ。あなたのクラウドが、分散 IaaS デザインを用いて適切に構成されているなら、個々のデバイスを大容量化する必要性も、もはや無いはずだ。 分散デザインは、クラウド・サービス・プロバイダーが、きわめて高レベルな可用性を、安定して供給するために、欠かすことのできない考え方となっている。

Another item cloud architects look for are products that can integrate with the cloud management systems so that they are fully automated. Scaling out and automating compute is a known problem and all the cloud management systems solve it with ease. As for cloud storage, there are now great distributed options like Ceph, SolidFire and OpenStack Swift that linearly scale out and can be easily automated.

また、クラウド・アーキテクトは、クラウドを完全に自動化するために、クラウド・マネージメント・システムとの統合が可能なプロダクトも、探し出さなければならない。コンピューティングのスケールアウトと自動化は、広く認識されている問題であるが、すべてのクラウド・マネージメント・システムにより、容易に解決できるものでもある。 クラウド・ストレージに関しては、Ceph および、SolidFire、OpenStack Swift といった、分散化のための素晴らしい選択肢が提供されている。そして、それらを用いることで、リニアなスケールアウトと、容易なオートメーションが実現されていく。

Networks are hard to provision and scale

imageThese newly minted cloud architects are beginning to realize something that those in the cloud service provider business have known for a while. Network devices weren’t designed to be automated, and they definitely weren’t designed to be provisioned at the granularity and high-churn rate than IaaS clouds demand of them. Also, some network devices, instead of linearly scaling out as demand increases, tend to adopt a scale up model.

これらの、新たに誕生すべきクラウド・アーキテクトちは、クラウド・サービス・プロバイダー事業者が取り組んできた、何らかのものを理解し始めている。 まず、ネットワーク・デバイスは、自動化に対応するようデザインされていないことが挙げられる。そして、プロビジョニングする際の微調整にも対応せず、また、IaaS クラウドが要求するネットワークの組み換えにも対応できなかった。 さらに言えば、いくつかのネットワーク・デバイスは、要求が増大するときに、リニアにスケールアウトせず、スケールアップする傾向のある、モデルとして提供されている。

Networks aren’t flexible enough for cloud requirements

A common use case for an IaaS cloud is disaster recovery, which often requires the recreation of complex network topologies. This can be problematic because that typically would require the physical network to be purpose built for that specific disaster recovery scenario, thereby eliminating the cost benefits and general purpose nature of the IaaS cloud. Another very common use case is migrating existing applications to the cloud. Many applications are reliant on very specific network design patterns. These apps would pose problems if they were moved to the cloud and might even have to be rewritten to fully operate in a cloud environment.

IaaS クラウドにおける共通ユース・ケースは DR であり、複雑なネットワーク・トポロジーの再構築が頻繁に要求される。 それが問題になり得るのは、特定の DR シナリオのための物理ネットワークが、一般的には要求されるからであり、それにより、IaaS クラウドの費用対効果と多目的性が阻害されている。もう1つの、きわめて一般的なユース・ケースは、既存アプリケーションの、クラウドへの移行である。 そして、数多くのアプリケーションが、特定のネットワーク・デザイン・パターンに大きく依存している。もし、そのようなアプリがクラウドに移行されると、問題を引き起こすかもしれない。そして、さらに、クラウド環境で完全に稼働させるために、書き直しが必要になるかもしれない。

Enter overlay-based network virtualization

Overlay-based network virtualization is a technology that allows cloud users to provision virtual network devices such as virtual switches, virtual routers, virtual firewalls and virtual load balancers. These virtual network devices can then be connected to VM’s as well as other virtual network devices to create complex network topologies. Since these virtual devices live in software, the underlying network (a.k.a. the physical network) only needs to be an IP network which allows all the compute hosts to see each other. Two leading examples of overlay-based network virtualization solutions are Midokura’s MidoNet and Nicira’s Network Virtualization Platform. These particular solutions have an added benefit that they are designed to be fully distributed; that means the scaling model is linear and can be scaled out incrementally as demand increases. They are also integrated with cloud management solutions so that virtual network device provisioning is automated. Those who spent their lives deploying production clouds think of overlay-based network virtualization as the best way to handle networking for cloud environments.

オーバーレイ・ベースの仮想ネットワークは、仮想化されたスイッチ/ルーター/ファイアウォール/ロードバランサーいった仮想ネットワーク・デバイスを、クラウド・ユーザーにプロビジョニングさせるためのテクノロジーである。 それらの仮想ネットワーク・デバイスは、その後に VM に接続されるだけではなく、複雑なネットワーク・トポロジーを構成するために、その他の仮想ネットワーク・デバイスとも接続される。 それらの仮想デバイスはソフトウェアとして機能し、また、基本的なネットワーク(物理ネットワークのこと)は、すべてのホスト・コンピュータが相互に存在を確認するための、IP ネットワークとしてのみ必要となる。 このオーバーレイ方式をベースとした仮想ネットワーク・ソリューションの、2つの先進的な事例としては、Midokura の MidoNet と Nicira の Network Virtualization Platform が挙げられる。この種のソリューションは、完全な分散デザインという、付加的なメリットを提供する。 つまり、リニアに伸びるスケーリング・モデルのことであり、要求の増大に応じた段階的なスケール・アウトを実現していく。また、それらは、クラウド・マネージメント・ソリューションとも統合されるため、仮想ネットワーク・デバイスの自動的なプロビジョニングにも対応できる。 それらのソリューションは、オーバーレイ・ベースの仮想ネットワークの方式でディプロイされた、実運用クラウド環境に配置されるため、クラウドのネットワークを操作する上で最適な方式となる。

Predictions and prognostications

Now it’s time for me to put on my Nostradamus hat. Server virtualization adoption has grown at an extremely fast pace since its debut and has fundamentally changed the IT landscape. The next phase is widespread self-service IT adoption, and consequently, the proliferation of IaaS clouds. These concepts, as well as the technology behind them, will become essential to how the modern enterprise will deliver IT services. Because overlay-based network virtualization solves the very real problems stated above, it will soon become the preferred method of handling cloud networking. Now is a great time to start researching overlay-based network virtualization to better understand how it will fit within your IT future.

いまこそ、Nostradamus のように予言すべきだろう。 仮想サーバーの適用は、そのデビュー以来、きわめて速いペースで増大し、IT の基本となる風景を大きく変えてきた。 次のフェーズは、広範囲におよぶセルフ・サービス IT の適用であり、それに続いて IaaS クラウドの拡散が生じてくる。 その背景となるコンセプトだけではなく、そのためのテクノロジーも、近代的なエンタープライズが IT サービスを提供するときに、欠かすことにできない本質になるだろう。 オーバーレイ・ベースの仮想ネットワークは、そこで生じるきわめて現実的な問題を解決するため、クラウド・ネットワークの運用における、最も好ましい方式として、評価される日も間近のはずだ。オーバーレイ・ベースの仮想ネットワークが、あなたの IT の未来にフィットすることを理解するためにも、いまこそ調査を開始すべきである。 その時が やってきた。

Ben Cherian is a serial entrepreneur who loves playing in the intersection of business and technology. He’s currently the Chief Strategy Officer at Midokura, a network virtualization company. Prior to Midokura, he was the GM of Emerging Technologies at DreamHost, where he ran the cloud business unit. Prior to that, Ben ran a cloud-focused managed services company.


TAG indexMidokura の Ben Cherian さんが、All Things D に寄稿した記事です。なぜ、仮想化が必要なのか? どのような仮想化が必要なのか? ・・・という視点で、これまでに私たちがたどってきた道筋の延長線上に、SDN(Software Defined Networks)が待っているのですよと、とても分かりやすく説明してくれます。SDN という言葉が指し示す範囲は広大であり、また、広すぎるが故に、理解し難かったのですが、オーバーレイ・ベースという考え方と、ソフトウェアとして機能する仮想デバイスという概念が、とても重要なのだと思えてきました。image



Midokura : SDN の巨人たちを標的に捉える
Midokura と SDN : どのように Layer 2-4 をサポートすべきか_1
Midokura と SDN : どのように Layer 2-4 をサポートすべきか_2
Apigee は、テレコムのための SDN を考える
Cisco が占有する スイッチ と ルーターの世界 : それを示す1枚のチャート

Comments Off on ネットワークの仮想化へ向けた論証 – Ben Cherian

Cisco が占有する スイッチ と ルーターの世界 : それを示す1枚のチャート

Posted in .Selected, Cisco, Data Center Trends, Network, OpenFlow, Research, SDN by Agile Cat on March 1, 2013

Chart: Cisco owns the switching and routing world

Stacey Higginbotham – Fab 27, 2013

_ Gigaom

Summary: Cisco may be facing an existential threat to its switching and router business, but a chart out from a research firm shows exactly how much the networking giant stands to lose.

Summary: Cisco は、スイッチとルーターのビジネスが、脅かされるという危機感に直面しているかもしれないが、あるリサーチ会社から提供されたチャートを見れば、このネットワークの巨人が維持しているものが正確に把握できる。


While Cisco may see long-term threats to its business from software-defined networking, VoIP and competing collaboration and video conferencing products, the networking giant is sitting pretty with 54 percent of the market share in the six networking categories shown below for 2012.

Cisco のビジネスは、SDN および、VoIP の競合、ビデオ会議プロダクトといった、長期間におよぶチャレンジを受けているが、 このネットワークの巨人は、2012年においても、以下の6つのネットワーク・カテゴリーにおいて、54% ものシェアを確保している。

Research from Synergy shows that Cisco has the lion’s share of the market in switches and routing, reaching roughly 65 percent and 70 percent respectively. In 2012 the six main segments within the enterprise networking market generated $45 billion in revenues for technology vendors, with Ethernet switches now accounting for almost half of all spending.

Synergy が提供する調査結果によると、Cisco はスイッチとルーターのカテゴリーにおいて、65% と 70% という、圧倒的なシェアを保持していることが分かる。 2012年のエンタープライズ・ネットワーク市場では、テクノロジー・ベンダーたちが $45 billion を稼ぎ出している。そして、その市場を、6つのメイン・セグメントに分けてみると、Ethernet Switches の項目が、全体の約半分を占めるという状況が分かってくる。

So even as Cisco comes off a successful reorganization and faces existential threats to its networking business from the commodification of the router, it’s daunting to see what its fighting to keep. It will not go gently.

Cisco は組織の再編を終え、また、ルーターのコモディティ化という、ネットワーク・ビジネスにおける現実的な脅威に立ち向かっていくが、このチャートを見れば、そのコンペティタたちも怯むだろう。決して、ヤワな相手ではないのだ。

Check out Cisco at our Structure Data conference in New York City March 20 and 21.

Related research





imageモバイル以前に、そして、クラウド以前に、プレゼンスを発揮していた大手企業が、このところ、ハードもソフトも軒並み不調という流れですが、Cisco に関しては、そんな心配も不要のようですね。文中にあるように、時代に合わせた組織の再編が、とても大切なんだろうと思えてきます。image



Cisco が Piston Cloud に出資 : さらなる OpenStack へのコミットか?
Cisco は vCider を買収し、分散クラウドを加速する
Cisco の経営陣は、Google と IBM から学ぶべきだ
Cisco 予測 2017年 : 世界のモバイル・トラフィックは 11.2 EB/月


Comments Off on Cisco が占有する スイッチ と ルーターの世界 : それを示す1枚のチャート

みんなが 注目の SDN/OpenFlow 特集

Posted in .Selected, OpenFlow, SDN by Agile Cat on December 14, 2012

昨年のおさらいから、イケイケの Midokura まで ・・・


imageやはり、今年のキーワードとして、SDN(Software-Defined Network)と OpenFlow は図抜けた存在だったと思います。 どちらかと言うと、話題としては OpenFlow が先行し、それを SDN が追いかけるという展開でした。

また、この領域におけるスタートアップである Nicira を VMware が、そして、Vyatta を Brocade がというふうに買収劇が進行し、いま現在は、Juniper が Contrail を買収という話も浮上してきています。 来年も、まだまだ、いろんな動きがあるだろうと思われる、SDN と OpenFlow の世界です。

Oct   4:
OpenFlow 関連ポストへのリンク集(20本強)
Nov 16: Juniper がデベロッパーに対して、OpenFlow ソースコードを提供開始
Dec 19: OpenFlow 1.2 が ONF の評議会で承認された – NTT Com も委員に

Jan 30:
Creation Line が展開する統合戦略とは?
Jan 11: OpenStack における SDN コネクションを探求する _1
Jan 13: OpenStack における SDN コネクションを探求する _2
Apr 11: Google 先生の OpenFlow 講座 – DC 間接続を低コストで達成するには
Apr 17: Google と OpenFlow と SDN について本音を語ろう – Urs Holzle
Apr 25: VMware の考える SDN は、OpenFlow だけでは完成しない
May 17: VMware が考える、ソフトウェア定義によるデータセンターとは?
Jun 25: OpenFlow @ Interop 2012 のマトメ・ページ
Jun 26: Google の OpenFlow バックボーンは、どのように機能しているのか_1
Jun 28: Google の OpenFlow バックボーンは、どのように機能しているのか_2
Jul   2: VMware は OpenFlow を静観する_1
Jul   4: VMware は OpenFlow を静観する_2
Jul   6: VMware は OpenFlow を静観する_3
Jul 24: VMware が Nicira を $1.26B を買収 : その背景にあるものは?
Jul 25: VMware の言うクラウド選択の自由と、Nicira の買収は矛盾しないのか?
Aug   7: Intel が思い描く、コモディティ SDN の構想 _1
Aug   9: Intel が思い描く、コモディティ SDN の構想 _2
Sep 25: Midokura と SDN : どのように Layer 2-4 をサポートすべきか_1
Sep 27: Midokura と SDN : どのように Layer 2-4 をサポートすべきか_2
Sep 28: Apigee は、テレコムのための SDN を考える
Oct 25: Cisco は vCider を買収し、分散クラウドを加速する
Nov   6: Brocade が Vyatta を買収
Nov 13: Midokura : SDN の巨人たちを標的に捉える


Agile_Cat_2012そして、SDN のスタートアップには、日本発のスタートアップである Midokura がいます。 世界の強豪たちにまじり、最先端の技術で戦い続ける Midokura は、Agile_Cat としても、応援していきたい対象です。 頑張れ、Midokura ! image



みんなが 期待の Open Cloud 特集
みんなが 注目の SDN/OpenFlow 特集
みんなの 先生 James Hamilton 特集
みんなを 支える Data Center 特集
2012 – 2013 海外 マトメ・ポストを、マトメてみました 62本
泣いて、笑って、驚いて、今年も暮れる WeekEnd 特集

Comments Off on みんなが 注目の SDN/OpenFlow 特集

Midokura と SDN : どのように Layer 2-4 をサポートすべきか_2

Posted in .Selected, Network, OpenFlow, SDN by Agile Cat on September 27, 2012

Midokura’s MidoNet: a Layer 2-4 virtual network solution

Thursday, August 30, 2012


初めての方は:Midokura と SDN : どのように Layer 2-4 をサポートすべきか_1


Midokura’s MidoNet: a L2-4 virtual SDN

A month ago Ben Cherian left a comment on my blog saying “Our product, MidoNet, supports BGP, including multihoming and ECMP, for interfacing MidoNet virtual routers with external L3 networks.” Not surprisingly, I wanted to know more and he quickly organized a phone call with Dan Mihai Dimitriu, Midokura’s CTO. This is one of the slides they shared with me … showing exactly what I was hoping to see in a virtual networks solution:

1ヶ月前のことだが、Ben Cherian が「 私たちのプロダクトである MidoNet は、外部 L3 ネットワークと MidoNet 仮想ルーターをインタフェースさせるために BGP をサポートし、そこに Multihoming と ECMP を取り込んでいる」というコメントを、私のブログに残している。 当然のことながら、より多くのことを、私は知りたくなった。 そして、すぐに Ben は、Midokura の CTO である Dan Mihai Dimitriu との電話会談をセットしてくれた。 以下のスライドは、そのときに私たちがシェアしたものである。 それは、仮想ネットワークにおいて、私が確認したいと望んでいた、まさに、そのものである:

Typical MidoNet virtual network topology

As expected, they decided to implement virtual networks with GRE tunnels between hypervisor hosts. A typical virtual network topology mapped onto underlying IP transport fabric would thus like this:

期待していたように、彼らは、ハイパーバイザ・ホスト間に GRE トンネルを配置する、仮想ネットワークの実装を決定していた。基礎となる IP トランスポート・ファブリック上にマップされる、典型的な仮想ネットワークトのトポロジは、以下のようになるだろう:

MidoNet virtual networks implemented with commodity
compute nodes on top of an IP fabric

Short summary of what they’re doing:


  • Their virtual networks solution has layer-2 virtual networks that you can link together with layer-3 virtual routers.
  • Each virtual port (including VM virtual interface) has ingress and egress firewall rules and chains (inspired by Linux iptables).
  • Virtual routers support baseline load balancing and NAT functionality.
  • Virtual routers are not implemented as virtual machines – they are an abstract concept used by hypervisor switches to calculate the underlay IP next hop.
  • As one would expect in a L3 solution, hypervisors are answering ARP and DHCP requests locally.
  • The edge nodes run EBGP with the outside world, appearing as a single router to external BGP speakers.
  • 彼らの仮想ネットワーク・ソリューションは、Layer-2 仮想ネットワークを持っており、それにより、Layer-3 仮想ルーターとのリンクが実現される。
  • それぞれの仮想ポート(VM 仮想インターフェイスを含む)は、ファイヤーウォールのルールとチェーンに対して、入力を出力を有する。
  • 仮想ルーターは、ベースライン・ロード・バランシングと NAT の機能をサポートする。
  • これらの仮想ルーターは、仮想マシンとしては実装されない。 つまり、基礎となる IP Next Hop を計算するために、ハイパーバイザ・スイッチが用いる抽象概念となる。
  • L3 ソリューションで期待されるものとして、ローカルな ARP および DHCP リクエストに対する、ハイパバイザからの回答が提供される。
  • 外の世界との接点として EBGP を実行するエッジ・ノードは、シングル・ルーターとして、外部の BGP スピーカーから参照される。

Interestingly, they decided to go against the current centralized control plane religion, and implemented most of the intelligence in the hypervisors. They use Open vSwitch (OVS) kernel module as the switching platform (proving my claim that OVS provides all you need to implement L2-4 functionality), but replaced the OpenFlow agents and centralized controller with their own distributed software.

興味深いことに、彼らは、センタライズされたコントロール・プレーンという、いま流行りの信仰に逆らうことを決め、また、大半のインテリジェンスをハイパーバイザ内に実装した。彼らは、Open vSwitch(OVS)カーネル・モジュールを、スイッチング・プラットフォームとして使用するが( OVS は、すべての必要とされる L2-L4 機能の、実装を提供するという、私の主張を証明している)、 OpenFlow エージェントとセンタライズされたコントロール・プレーンを、自身で配布するソフトウェアで置き換えている。

MidoNet packet forwarding process

This is how Dan and Ben explained a day in the life of an IP packet passing through the MidoNet overlay virtual networks (I haven’t set it up to see how it really works):

以下は、MidoNet オーバーレイ仮想ネットワークを通過していく IP パケットが、どのような一生をたどるのかという視点で、Dan と Ben が説明してくれたものである(ただし、実際の動作に関して、私の方では確認していない):

Their forwarding agents (running in user space on all hypervisor hosts) intercept traffic belonging to unknown flows (much like the ovs-vswitchd), but process the unknown packets locally instead of sending them to central OpenFlow controller.

そこでは、MidoNet のフォワーディング・エージェント(すべてのハイパーバイザ・ホスト上のユーザー・スペースで実行される)が、未知のフローに属するトラフィックをインターセプトする(ほぼ、ovs-vswitchd と同じ方式)。しかし、それらのパケットはローカルで処理され、センタライズされた OpenFlow コントローラには送信されない。

The forwarding agent receiving an unknown packet would check the security rules, consult the virtual network configuration, calculate the required flow transformation(s) and egress next hop, install the flow in the local OVS kernel module, insert flow data in a central database for stateful firewall filtering of return traffic, and send the packet toward egress node encapsulated in a GRE envelope with the GRE key indicating the egress port on the egress node.

このフォワーディング・エージェントは、まず、セキュリティ・ルールをチェックすべき未知のパケットを受信する。そして、仮想ネットワークのコンフィグレーションを調べる。続いて、必要とされるフロー変換と、次のホップへ向けた出力を計算する。さらに、ローカルな OVS カーネル・モジュールに、対象となるフローをインストールする。そして、リターン・トラフィックに関する、ステートフルなファイヤーウォール・フィルタリングのための、センタライズされたデータベース内にフローデータを挿入する。最後に、GRE エンベロープ内でカプセル化された出力ノードへ向けて(出力ノード上の出力ポートを指し示す GRE Key を用いる)、対象となるパケットを送信する。

According to Midokura, the forwarding agents generate the most-generic flow specification they can – load balancing obviously requires microflows, simple L2 or L3 forwarding doesn’t. While the OVS kernel module supports only microflow-based forwarding, the forwarding agent doesn’t have to recalculate the virtual network topology for each new flow.

Midokura によると、このフォワーディング・エージェントは、可能な限り汎用的なフロー仕様を生成する。 つまり、ロード・バランシングは、はっきりとマイクロ・フローを要求し、また、シンプルな L2 および L3 の転送は行われない。 この OVS カーネル・モジュールは、マイクロフロー・ベースの転送だけをサポートするが、それぞれの新しいフローのための仮想ネットワーク・トポロジを、このフォワーディング・エージェントにより再計算する必要はない。

The egress OVS switch has pre-installed flows that map GRE keys to output ports. The packet is thus forwarded straight to the destination port without going through the forwarding agent on the egress node. Like in MPLS/VPN or QFabric, the ingress node performs all forwarding decisions, the “only” difference being that MidoNet runs as a cluster of distributed software switches on commodity hardware.

この、出力 OVS スイッチは、GRE keys を出力ポートにマップするために、いくつかのフローをプリ・インストールしている。 したがって、対象となるパケットは、出力ノード上のフォワーディング・エージェントを通過することなく、ディスティネーション・ポートへと向けてダイレクトに転送される。 MPL/VPN や QFabric と同様に、対象となる入力ノードにより、すべての転送が決定される。 そして、唯一の違いは、コモディティ・ハードウェア上の分散ソフトウェア・スイッチとして、MidoNet が実行される点にある。

Asymmetrical return traffic is no longer an issue because MidoNet uses central flow database for stateful firewall functionality – all edge nodes act as a single virtual firewall.

ステートフルなファイヤーウォール機能のために、MidoNet ではセンタライズされたフローデータ・ベースが用いられる。そのため、非対称のリターン・トラフィックという問題が、もはや生じることもない。つまり、すべてのエッジ・ノードは、単一の仮想ファイヤーウォールの役割を果たすことになる。

The end result: MidoNet (Midokura’s overlay virtual networking solution) performs simple L2-4 operations within the hypervisor, and forwards packets of established flows within the kernel OVS.

The end result: MidoNet (Midokura のオーバーレイ方式バーチャルネットワーク化解法)は、ハイパーバイザの中で、シンプルな L2-L4 オペレーションを実行する。そして、カーネル OVS の中で確立されたフローにより、パケットを転送していく。

Midokura claims they achieved linerate (10GE) performance on commodity x86 hardware … but of course you shouldn’t blindly trust me or them. Get in touch with Ben and test-drive their solution.

Midokura は、コモディティ x86 ハードウェア上で、ラインレート(10GE)のパフィーマンスを達成したと主張する。 しかし、もちろん、、、それを闇雲に信頼すべきではない。 Ben にコンタクトし、彼らのソリューションを試すべきである。


Midokura と SDN : どのように Layer 2-4 をサポートすべきか_1


image文中の 『 センタライズされたコントロール・プレーンという、いま流行りの信仰に逆らうことを決め、また、大半のインテリジェンスをハイパーバイザ内に実装した』という表現が興味深いですね。 以前に抄訳としてポストした Google 先生の OpenFlow 講座 – DC 間接続を低コストで達成する では、『OpenFlow がもたらすものは、ネットワークをアプリケーションのように振る舞わせることであり、センタライズされたコントローラの中に、インテリジェントに組み合わされたネットワーク・ギアを論理的に配置していく能力だ 』と明記されています。 Google のようなサービスと、一般的なエンタープライズ・サービスでは、同じ ” 仮想ネットワーク ” という言葉で括られても、その目的は随分と異なるものになるはずです。 だからこそ、SDN に多様性が生じるのでしょうし、その実装形態の1つとして、OpenFlow があるのだという見方が成り立つのでしょう。 とても難しい話ですが、頑張って追いかけていきたいと思います。



Intel が思い描く、コモディティ SDN の構想 _1
Intel が思い描く、コモディティ SDN の構想 _2
VMware の言うクラウド選択の自由と、Nicira の買収は矛盾しないのか?
VMware が Nicira を $1.26B を買収 : その背景にあるものは?
VMware の考える SDN は、OpenFlow だけでは完成しない


Comments Off on Midokura と SDN : どのように Layer 2-4 をサポートすべきか_2

Midokura と SDN : どのように Layer 2-4 をサポートすべきか_1

Posted in .Selected, Network, OpenFlow, SDN by Agile Cat on September 25, 2012

Midokura’s MidoNet: a Layer 2-4 virtual network solution

Thursday, August 30, 2012


Almost everyone agrees the current way of implementing virtual networks with dumb hypervisor switches and top-of-rack kludges (including Edge Virtual Bridging – EVB or 802.1Qbg – and 802.1BR) doesn’t scale. Most people working in the field (with the notable exception of some hardware vendors busy protecting their turfs in the NVO3 IETF working group) also agree virtual networks running as applications on top of IP fabric are the only reasonable way to go … but that’s all they currently agree upon.

間抜けなハイパーバイザ・スイッチと、ラックのトップに配置された即席の解決策Edge Virtual Bridging – EVB or 802.1Qbg – and 802.1BRを 含む)による、現在の仮想ネットワークがスケールしないことを、大半の人々が理解している。 また、フィールドで働く大半の人々も( ただし、NVO3 IETF ワーキング・グループで、いくつかのハードウェア・ベンダーが、自らの芝生を守ろうとしていることは、顕著な例外である)、IP ファブリックのアプリケーションとして動作する仮想ネットワークだけが、唯一の妥当な方式であることに同意しているが、、、それが、現時点における合意のすべてである。

Traditional VLAN-based virtual networks
implemented in the physical switches

Virtual networks implemented in the hypervisor
switches on top of an IP fabric

A brief overview of where we are

Cisco, VMware and Microsoft disappointingly chose the easiest way out: VXLAN and NVGRE are MAC-over-IP virtual networks with no control plane. They claim they need layer-2 virtual networks to support existing applications (like Microsoft’s load balancing marvels) and rely on flooding (emulated with IP multicast) to build the remote-MAC-to-remote-IP mappings in hypervisor virtual switches.

残念なことに、Cisco/VMware/Microsoft は、最も易しい方法を選択した。 つまり、VXLAN と NVGRE は、コントロール・プレーンを持たない MAC-over-IP 仮想ネットワークである。 彼らは、Layer-2 仮想ネットワークが、現存のアプリケーション(あの Microsoft のロード・バランシングのような)をサポートするために必要であり、また、ハイパーバイザ仮想スイッチ内で Remote-MAC-to-Remote-IP マッピングを構築するために、フラッディング(Flooding :IP マルチキャウストによりエミュレートされたもの)に依存すると主張する。

VXLAN architecture

Nicira’s Network Virtualization Platform is way better – it has a central control plane that uses OpenFlow to distribute MAC-to-IP mapping information to individual hypervisors. The version of their software I’m familiar with implemented simple layer-2 virtual networks; they were promising layer-3 support, but so far haven’t updated me on their progress.

Nicira の Network Virtualization Platform のほうが、ずっと良い 。 こそでは、MAC-to-IP マッピング情報を、個々のハイパーバイザに分散するために、OpenFlow を用いたコントロール・プレーンが使用される。私が知っている Nicira のバージョンは、シンプルな Layer-2 仮想ネットワークで実装されたものである。 そして、彼らは Layer-3のサポートを約束しているが、これまでのところ、アップデートの知らせは無い。

The Missing L3-4 Problem

We know application teams trying to deploy their application stacks on top of virtual networks usually need more than a single virtual network (or security zone). A typical scale-out application has multiple tiers that have to be connected with load balancers or firewalls.

仮想ネットワーク上にアプリケーション・スタックを実装しようとするアプリケーション・チームが、通常では 1つ以上の仮想ネットワーク(あるいはセキュリティ・ゾーン)を必要とすることは、周知の事実である。 そして、典型的なスケール・アウト型のアプリケーションが持つマルチ・ティアは、ロードバランサあるいはファイアウォールと接続される必要がある。

Simplified scale-out application architecture

All the vendors mentioned above are dancing around that requirement claiming you can always implement whatever L3-7 functionality you need with software appliances running as virtual machines on top of virtual networks. A typical example of this approach is vShield Edge, a VM with baseline load balancing, NAT and DHCP functionality.

これまでに説明してきたすべてのベンダーは、仮想ネットワーク上に仮想マシンとして動作するソフトウェア・アプライアンスが必要な、L3~L7 機能を用いるあらゆる要件でも実装できると、あなたの周囲で踊り続けるだろう。このアプローチの典型的な例は vShield Edge であり、そこではベースライン・ロードバランシングを用いた VM と、NAT と、DHCP 機能が組み合わされる。

Load balancer as a VM appliance

To keep the record straight: VMware, Cisco, Juniper and a few others offer hypervisor-level firewalls; traffic going between security zones doesn’t have to go through an external appliance (although it still goes through a VM if you’re using VMware’s vShield Zones/App). Open vSwitch used by Nicira’s NVP could be easily configured to provide ACL-like functionality, but I don’t know how far Nicira got in implementing it.

ここで、記録としての情報を列挙してみる。 VMware/Cisco/Juniper などは、ハイパーバイザ ・レベルのファイヤーウォールを提供する。 つまり、セキュリティ・ゾーン間のトラフィックは、外部のアプライアンスを通り抜ける必要がない(しかし、VMware の vShield Zones/App を使っているなら、依然として何らかの VM を通り抜けることになる)。 Nicira の NVP が用いる Open vSwitch は、ACL ライクな機能を提供するよう、簡単にコンフィグレーションできる。 しかし、それを Nicira が実装するのが、どれくらい先になるのか、私は知らない。

続く: Midokura と SDN : どのように Layer 2-4 をサポートすべきか_2


image一言で SDN といっても、それぞれのベンダーにおけるコンセプトが、きわめて多様なものであることが分かります。 また、SDN に取り組んでいる、取り組んでいない、という表層的な話ではなく、どのようなレベルで設計/実装しているのかと、その辺りを見極めなければならないことも、この記事を読むと、よく分かってきます。 長い記事なので 2回に分けてポストしますが、後半は MidoNet にフォーカスした内容となりますので、どうぞ、お楽しみに!



Intel が思い描く、コモディティ SDN の構想 _1
Intel が思い描く、コモディティ SDN の構想 _2
VMware の言うクラウド選択の自由と、Nicira の買収は矛盾しないのか?
VMware が Nicira を $1.26B を買収 : その背景にあるものは?
Google 先生の OpenFlow 講座 – DC 間接続を低コストで達成するには
VMware の考える SDN は、OpenFlow だけでは完成しない

Comments Off on Midokura と SDN : どのように Layer 2-4 をサポートすべきか_1

Intel が思い描く、コモディティ SDN の構想 _2

Posted in OpenFlow, SDN by Agile Cat on August 9, 2012

Intel® Ethernet Switch FM6000 Series – Software Defined Networking Recep Ozdag Intel Corporation


初めての方は:Intel が思い描く、コモディティ SDN の構想 _1


Administrators need to be freed from the physical infrastructure to simplify the task of managing large and virtualized networks. Software Defined Networking (SDN) is a new networking paradigm that separates, abstracts and centralizes the control information of the network from the underlying distributed data forwarding infrastructure. This centralized view of the network, as illustrated in the figure below, combined with splitting the control and data planes creates a far more dynamic, flexible, automated and manageable architecture that also results in increased reliability and reduced costs. SDN provides the opportunity for the networks to be managed through intelligent orchestration software that supports virtualized networking and on-demand resource allocation. SDN provides a global network wide data flow control to the administrator, allowing administrators to define network flows that meet the requirements of end users. The SDN controller, which implements the control plane functionality, logically centralizes and manages switches and routes packets through the network.

大規模な仮想ネットワークの管理を簡潔にするためには、アドミニストレータを物理的なインフラから解放してあげる必要がある。 Software Defined Networking(SDN)は、基礎をなす分散データ・フォワーディング・インフラから、ネットワークのコントロール情報を分離し、抽象化し、センタライズするための、新しいネットワーク・パラダイムである。以下の図に示すセンタライズされたネットワークのビューは、コントロールとデータのプレーンを分離し、それらを組み合わせるものとなる。それは、信頼性を高めコストを削減するためのアーキテクチャでもあり、また、柔軟性と自動化を達成する、さらにダイナミックで、容易な管理を実現するアーキテクチャでもある。 SDN は、仮想化されたネットワークとオン・デマンドによるリソース割り当てをサポートする、インテリジェントなオーケストレーション・ソフトウェアを介して、ネットワークを管理するための機会を提供する。そして SDN がアドミニストレータに対して、グローバル・ネットワークに対応するデータ・フロー・コントロールを提供することで、彼らはエンドユーザーの要件を充たすための、ネットワークの定義を実現していく。そして SDN コントローラは、このネットワークを介して、コントロール・プレーン機能を実装し、また、スイッチの論理的なセンタライズと管理を行い、パケットをルーティングしていく。

Some of the high level goals of SDN include the following:

– Flexible control of flows passing through the network
・Forwarding of packets according to software defined rules
・Load balancing of packets according to software defined
   heuristics combined with hardware flow hashing
・Flexible modification of the frame (NAT, Tunneling, tag rewrites)
   to aid in interfacing between hosts, local networks,
   and external network interfaces
・Intelligent flow classification (security, virtual domaining, etc.)
   that is software defined and is done in parallel with forwarding 
   and frame modifications
– Vendor independent interface to the switching elements
– Ability to work beside existing protocols (hybrid switch)
– Ability to overlay SDN intelligence using tunneling

SDN における、いくつかのハイレベル・ゴールには、以下の項目が含まれる:

– 対象ネットワークを通過していくフォローの柔軟なコントロール
   フレーム(NAT、Tunneling、Tag Rewrite)の柔軟な修正
・インテリジェントなフロー分類(Security、Virtual Domaining など)
– スイッチングの要素に対する、ベンダー非依存のインターフェイス 
– 既存プロトコルと別に機能するための、能力の提供(Hybrid Switch)
– トンネリングを用いてSDN インテリジェンスをオーバーレイする機能


The OpenFlow protocol is one method to enable SDN. OpenFlow provides software control of the flow tables that instruct switches how do handle traffic within an SDN based network. OpenFlow provides access to the data plane of the network and allows software to determine the path that data packets or flows will take.

OpenFlow プロトコルは、SDN を実現していくための 1つの方法論である。 OpenFlow は、SDN ベースのネットワークにおいて、どのようにトラフィックをスイッチすべきかと指示する、フロー・テーブルをコントロールするソフトウェアを提供する。OpenFlow は、ネットワークのデータ・プレーンへのアクセスを提供し、また、データのパケットあるいはフローが向かう経路を、ソフトウェアにより決定させる。

OpenFlow depends on switches with internal flow tables and an interface to add, remove and manipulate flow entries that can be controlled via software running on an external and decoupled control plane. The controller and the switch communicate via the OpenFlow protocol. OpenFlow uses a number of packet header fields to define a flow. Each entry in the flow table contains a set of packet fields against which incoming traffic is matched and an associated action is performed on the matched flow. When the switch encounters a flow that it cannot match, the packet is sent to the controller to determine how to handle the packet. The controller may define a new flow and a new action based on this unmatched packet, and populate the switch’s flow table accordingly.

OpenFlow は、インターナルなフロー・テーブルを伴う複数のスイッチに依存し、また、フロー・エントリーの追加/削除/操作を実行する。それらのコントロールは、コントロール・プレーンとは分離された、外部に置かれるソフトウェアにより行われる。このコントローラーとスイッチは、OpenFlow プロトコルを介してコミュニケートする。 OpenFlow は、フローを定義するために、数多くのパケット・ヘッダ・フィールドを使用する。 フロー・テーブル内の個々のエントリーは、入力トラフィックに適合するパケット・フィールドと、適合するフォロー上で実行されるアクションのパケット・フィールドの、セットを内包している。そして、スイッチとフローが適合しない場合には、対象となるパケットの操作方法を決定するために、そのパケットがコントローラへ向けて送信される。それを受信したコントローラは、適合しないパケットに基づいた新しいフローとアクションを定義し、それに応じたスイッチのフロー・テーブルをポピュレートするだろう。

While OpenFlow provides a new networking paradigm that is gaining traction, it must co-exist with traditional networks – the transition to SDN or OpenFlow will not happen overnight. For the transition to be smooth, OpenFlow must be supported by hybrid switches that also support traditional L2/L3 switching and IP routing.

OpenFlow がもたらす、新しいネットワーク・パラダイムが推進力を得ているが、SDN および OpenFlow への移行期においては、従来からのネットワークと共存しなくてはならないこれも、ひと晩で解決する問題ではない。この移行をスムースに行うためには、これまでの L2 / L3 スイッチングと IP ルーティングをサポートする、ハイブリッド・スイッチにより OpenFlow をサポートする必要性が生じる。


imageこのあとは、FM6000 Series の詳細へと入って行きますが、お仕事でその部分が必要だったので、この序文をお裾分けとして掲載しました。Intel が、この領域に参入してくるということは、SDN や OpenFlow のコモディティ化を狙ってのことであり、これまで Cisco や Juniper の聖域とされたきた高速スイッチが、より多くのソフトウェア・ベンダーや OSS などに開放されるということです。 この先、どのような変化がマーケットに生じるのか、注目したいですね。 ーーー image



Intel が思い描く、コモディティ SDN の構想 _1
VMware が Nicira を $1.26B を買収 : その背景にあるものは?
VMware の言うクラウド選択の自由と、Nicira の買収は矛盾しないのか?
Google Compute Engine の立ち位置を、RightScale が分析する _1
Google Compute Engine の立ち位置を、RightScale が分析する _2
VMware は OpenFlow を静観する_1
VMware は OpenFlow を静観する_2
VMware は OpenFlow を静観する_3

Comments Off on Intel が思い描く、コモディティ SDN の構想 _2

Intel が思い描く、コモディティ SDN の構想 _1

Posted in .Selected, OpenFlow, SDN by Agile Cat on August 7, 2012

Intel® Ethernet Switch FM6000 Series – Software Defined Networking Recep Ozdag Intel Corporation×2


Software Defined Networking (SDN) promises to provide a flexible and simple management approach to traditional, heavily protocol driven networks by separating the control and data forwarding planes and abstracting the control and management functions into a software based controller that presents a centralized view of the network. OpenFlow, which is one method to enable SDN, provides software control of the flow tables that instruct switches in the network how do direct traffic within a network. While both SDN and OpenFlow provide real benefits to users, the move from traditional networking will not happen overnight. In this paper we present Intel’s low latency, high performance and extremely programmable, 10GbE FM6000/FM7000 Ethernet switch silicon as a key enabler for network administrators to gradually migrate to OpenFlow and SDN. The FM6000 series hybrid Ethernet switch provides superb support for OpenFlow and SDN with its unique FlexPipe® frame processing pipeline architecture while it continues its role as a traditional data center switching solution.

Software Defined Networking(SDN)が約束するものは、従来からのヘビーなプロトコル駆動型ネットワークに対する柔軟でシンプルなマネージメントのアプローチの提供である。具体的には、コントロールとデータ・フォワードのプレーンを切り離すことで、また、そのためのコントロールとマネージメントの機能を、ネットワークのセンタライズされたビューを表現する、ソフトウェア・ベースのコントローラーへ向けて抽象化することになる。 OpenFlow は、SDN を実現するための 1つの方式であり、ネットワーク内でのトラフィックの行先をスイッチに指示する、フロー・テーブルのためのソフトウェア・コントロールを提供するものである。 SDNと OpenFlow は、どちらも現実的なメリットをユーザーに提供するものであるが、これまでのネットワークからの移行が、ひと晩で起こるというものでもない。このペーパーにおいて Intel は、ロー・レイテンシ/ハイ・パフォーマンスと、高度なプログラミングを可能にする、10GbE FM6000/FM7000 イーサネット・スイッチ・シリコンを説明していく。それにより、ネットワーク・アドミニストレーターは OpenFlow と SDN へと向けて、段階的な移行を実現していけるだろう。 FM6000 シリーズのハイブリッド・イーサネット・スイッチは、独自の FlexPipe フレーム・アーキテクチャによるパイプライン処理により、OpenFlow と SDN に対する素晴らしいサポートを提供する。しかし、その一方では、伝統的なデータセンター・スイッチ・ソリューションとしての役割も担える。


Server and network infrastructure virtualization are of tremendous help to data center administrators, who have to address increased demand for computing resources on a constrained budget. However, the increased growth of both physical and virtual devices in the data center as well as the demand to seamlessly move virtual machines (VM) also results in added complexity for these same administrators who manage dynamic networks that need to quickly adapt to user needs. Unfortunately, management and control of these virtualized and complex networks have not kept pace with the changes in the data center and largely remain unchanged.


imageTraditional networks rely on IP addresses to locate servers and each distributed switch device relies on one or more instances of a L2/L3 control plane. Traditional switches and routers using legacy networking protocols can take too long to converge for today’s networks, which need to be faster and more flexible. Traditional networking methods and protocols were acceptable for yesterday’s static networks. But managing complex and dynamic virtual networks has become extremely labor-intensive, far too time consuming and expensive to remain feasible and competitive in modern networks.

従来からのネットワークは、サーバーのロケーションを定めるために、IP アドレスに頼ることになる。そして、それぞれの分散されたスイッチ・デバイスは、単体あるいは複数の、L2 / L3 コントロール・プレーンのインスタンスに依存する。 レガシー・ネットワーク・プロトコルを用いる、従来からのスイッチとルーターは、今日のネットワークを一点に集約するのに、あまりに時間をかけすぎるため、さらなる高速化とフレキシビリティが必要とされる。さらに言えば、これまでのネットワークにおける方法論とプロトコルは、昨日までのスタティックなネットワークのためのものだ。 そして、複雑でダイナミックな仮想ネットワークを管理することは、きわめて労働集約な作業になり始め、また、実現が可能な近代的なネットワークとして、その競争力を維持し続けるには、あまりにも時間と費用がかかり過ぎている。

Dominated by virtual device mobility and multi-tenancy, modern networks need to quickly adapt to business needs. Furthermore, traditional data center networks heavily borrow from the enterprise with complex network protocols that have not been concerned with scalability or server migration.


続く:  Intel が思い描く、コモディティ SDN の構想 _2


image先日、都内某所で、Cisco や Juniper がスイッチ・デバイスのために開発する ASIC 部分を、Intel がチップレベルで実装してきたら、どのように SDN マーケットは変化していくのだろうという雑談をしてきました。 そして、帰ってきて調べてみたら、すでに、このような立派なホワイト・ペーパーが提供されていることに気付きました。冒頭のサワリ部分だけですが、今回と次回に分けて、ご紹介したいと思います。ーーー image



Intel が思い描く、コモディティ SDN の構想 _2
VMware が Nicira を $1.26B を買収 : その背景にあるものは?

VMware の言うクラウド選択の自由と、Nicira の買収は矛盾しないのか?
Google Compute Engine の立ち位置を、RightScale が分析する _1
Google Compute Engine の立ち位置を、RightScale が分析する _2
VMware は OpenFlow を静観する_1
VMware は OpenFlow を静観する_2
VMware は OpenFlow を静観する_3

Comments Off on Intel が思い描く、コモディティ SDN の構想 _1

VMware の言うクラウド選択の自由と、Nicira の買収は矛盾しないのか?

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

With Nicira buy, VMware claims cloud freedom of choice

Derrick Harris Jul. 23, 2012

_ Gigaom

Three weeks, two acquisitions — DynamicOps and Nicira — and a lot of talk about freedom of choice. What gives, VMware?

3週間のあいだに DynamicOps と Nicira という、2つの買収劇が起こり、選択の自由について、たくさんのトピックが溢れ出た。 それにより、なにが VMware にもたらされるのだろう?

The answer is simple: VMware sees the writing on the wall, it knows acting like a dictator won’t work in an IT society that craves democracy. Half of the story around VMware’s rumored cloud computing spin-out focused on the need for the company to focus on its core virtualization business in order to fend off advances from the likes of Microsoft, Citrix, OpenStack and others. Most experts agree that embracing those competitors is VMware’s best chance to blunt their attacks.

その答えはシンプルである。 つまり、VMware が発表することに、注意深く見ていくことである。そうすれば、民主主義のキャンバスを持つ IT の社会で、たとえば独裁者のように振る舞っても、その望みを達成できないことが分かるだろう。 VMware に関するウワサ話の半分が、同社の必要性に焦点を合わせるために、何らかのスピンアウトをクラウド・コンピューティングの周辺で起こすというものだ。そうすることで、Microsoft/Citrix/OpenStack などの先行者利得を回避するための、コアとなる仮想化ビジネスに焦点を合わせるという。 大半の専門家が同意するのは、それらのコンペティタを抱え込んでしまうことが、VMware へ向けた彼らからの攻撃を鈍らせる、最良の選択肢になるという点だ。

On July 2, VMware announced it was buying virtualization- and cloud-management vendor DynamicOps, which VMware rationalized in its press release thusly:

VMware believes that customers will benefit most by a standardized architecture, but will build solutions that make it easy for customers to choose the model that best works for their needs, including heterogeneous environments/management. … DynamicOps builds on the capabilities of vCloud Director by enabling customers to consume multi-cloud resources (e.g., physical environments, Hyper-V- and Xen-based hypervisors, and Amazon EC2).

7月2日のことだが、VMware は仮想化とクラウド・マネージメントのベンダーである DynamicOps を買収すると発表した。 それについて、VMware はプレス・リリースで、以下のように合理性を説明した:

VMware が信じているのは、最も標準化されたアーキテクチャから、顧客がメリットを得ることである。しかし、ヘテロジニアスな環境とマネージメントも含めて、そのニーズに応じて最も適切に機能するモデルを、容易に選べるようにするソリューションを、顧客は構築していくとも確信している。・・・ DynamicOps が vCloud  Director の機能をベースに構築する機能は、マルチ・クラウド・リソースを消費する(たとえば 物理環境/Hyper-V/Xen Based ハイパーバイザ/Amazon EC2など)、顧客により実現されるものとなる。

On Monday, it was software-defined networking golden boy Nicira. In his blog post explaining the acquisition, VMware CTO Steve Herrod goes out of his way to talk about openness:

They [Nicira] are major contributors to the networking capabilities of other hypervisors (via the Open vSwitch community) as well as to the “Quantum Project”, one of the key subsystems of OpenStack.

I can imagine skepticism as to whether we will continue this substantial embrace of non-VMware hypervisors and clouds. Let me be clear in this blog… we are absolutely committed to maintaining Nicira’s openness and bringing additional value and choices to the OpenStack, CloudStack, and other cloud-related communities.

そして月曜日(7/23)には、SDN のゴールデン・ボーイである Nicira だ。 この買収について説明する、VMware CTO の Steve Herrod のブログ・ポストでは、オープンネスの説明について、ことさらの努力が伺える:

彼ら[ Nicira ]は、他のハイパーバイザー上のネットワーク機能を推進する主要コントリビュータであるだけでなく(Open vSwitch コミュニティを介して)、OpenStack の重要なサブシステムである “Quantum Project” に対しても同様である。

こうして、VMware 以外のハイパーバイザーやクラウドを受け入れてきたわけだが、私たちが今後も継続するだろうかという観点で、懐疑心が生じると想像できる。 このブログで明らかにさせて欲しいのだが、私たちは Nicira のオープンネスを絶対に維持し、また、OpenStack や CloudStack といったクラウド関連コミュニティから見た、もう1つの価値と選択肢を維持していく。

VMware’s Herrod and I talking software-defined data centers at Structure.

It might sound counterintuitive that VMware would embrace the hypervisor and cloud-management competition, but it’s actually common sense. If VMware is going to position itself as the provider of intelligence in software-defined data centers, hypervisors have to be treated as the workers that merely carry out the management layer’s commands. If all they’re there to do is create virtual machines that are part of a resource pool, the hypervisor shouldn’t really matter.

ハイパーバイザーとクラウド・マネージメントにおける競合を、VMware が抱え込むという状況は、直感に反するように聞こえるかもしれないが、実際には共通の認識である。VMware が Software Defined Data Center におけるナレッジ・プロバイダーとして、自身のポジションを位置づけるなら、ハイパーバイザーについては、マネージメント・レイヤーのコマンドを実行する、単なるワーカーとして扱われなければならない。 もし、VMware の行うことが、リソース・プールの一部としての仮想マシン作成だけにあるなら、ハイパーバイザー重要なものになってはいけない。

If we’re talking about supporting multiple cloud environments, such as OpenStack and CloudStack, I have to assume VMware will simply claim its superiority. So it might not prevent people from using OpenStack for test-dev workloads and web sites, but it will make the case that customers will want to use VMware for mission-critical apps.

OpenStack と CloudStack といったマルチ・クラウド環境のサポートについて議論するなら、そこで VMware が優位性を主張するということも想定する必要がある。つまり、ワークロードと Web サイトに関するテスト/開発のために、OpenStack が用いられることを妨害するものではないだろうが、ミッション・クリティカルなアプリケーションに関して、顧客が VMware を使いたがるという状況をもたらすだろう。

Supporting multiple clouds doesn’t mean encouraging their use. It’s the same logic that underpins VMware’s efforts with CloudFoundry — developers are free to use whatever components they want, but writing in Java and using Spring means VMware support and access to the gamut of SpringSource tools such as Spring Hadoop and everything falling under the vFabric banner. Want to run Hadoop on your VMs? You might be interested in VMware’s efforts to make Hadoop run on its vSphere hypervisor.

マルチ・クラウドのサポートが、その利用を奨励すると考えるなら、そこに落とし穴がある。 それは、CloudFoundry を用いることで、VMware のインフラを支えようとするロジックに等しい。つまり、デベロッパーは、必要とされるあらゆるコンポーネントを自由に利用できるが、Java による記述と Spring の使用は、VMware をサポートすることであり、また、Spring Hadoop などの SpringSource ツールにアクセスし、vFabric の名のもとに集められた、すべての領域へアクセスすることを意味する。 そのような状況で、あなたは、自身の VM 上で Hadoop を走らせようと望むだろうか?おそらく、vSphere ハイパーバイザー上で Hadoop を実行する、VMware のインフラに興味を持つだろう。

But don’t mistake VMware’s newfound love of openness for a sign incredible vision. If anything, it’s reactionary. In a world where the alternatives — even Microsoft — all play increasingly nice with each other, VMware can’t afford to be the odd man out. And in this case, what’s good for VMware should be good for customers, too.

しかし、VMware が新たに見出した、信じ難いビジョンの兆候と、オープンネスへの愛情を誤解してはいけない。 どちらかと言うと、それは反動的なものである。 常に代替が存在する世界において、Microsoft でさえ競合に明け暮れる、このステキな世界において、お人好しでいられるほどの余裕は、VMware にもないのだ。 そして、今回のケースにおいて、VMware にとっての幸福は、顧客にとっての幸福でもあるべきなのだ。

Image courtesy of Shutterstock user Chris Howey.

Related research and analysis from GigaOM Pro:


imageこの 4月ですが、「アメリカの 最強 IaaS プロバイダー Top-10 をリストアップ!」という抄訳をポストしました。 そこでは、そのうちの 4社が VMware を利用し、また、そのような背景からして、VMware 自身もリストに入れられています。 それほどまでに強大な VMware ですが、さまざまな OSS プロジェクトにコミットしてきた Nicira を買収したことで、オープン性が損なわれると危惧する声が大きいようですね。 ーーー image



VMware が Nicira を $1.26B を買収 : その背景にあるものは?
Paul Maritz が VMware CEO を退任するらしい
トップを快走する AWS と、それを追いかける 7人の チャレンジャー
EMC が Pivotal Labs を買収!
VMware の Cloud Foundry が、デベロッパーの 人気 No.1 になる理由は?


%d bloggers like this: