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枚のチャート

みんなが 注目の 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 特集

Midokura : SDN の巨人たちを標的に捉える

Posted in .Selected, OpenStack, SDN by Agile Cat on November 13, 2012

SDN Startup Midokura Takes on IT Giants

Posted by Andrew Conry Murray – October 18, 2012

_Network Computing

Software-defined networking just got a new player. Midokura is a startup that’s attacking network virtualization with an ambitious software platform called MidoNet that aims to upend the traditional networking market. Midokura announced its U.S. launch and its MidoNet software at the OpenStack developer conference in San Diego this week. It also announced MidoNet integration with OpenStack.

SDN の世界に、新しいプレーヤーが登場した。 Midokura は、従来からのネットワーク市場をひっくり返すという目的を持つ、MidoNet と呼ばれる野心的なソフトウェア・プラットフォームを用いて、仮想ネットワークにアタックするスタートアップである。 今週(10月中旬)のことだが、Midokura は San Diego で開催された OpenStack デベロッパー・カンファレンスで、アメリカにおける始動と、MidoNet ソフトウェアを発表した。そして、さらに、MidoNet とOpenStack のインテグレーションについても発表している。

clip_image001The MidoNet software, currently in beta, is designed to provide network virtualization to enable cloud providers and enterprises to build infrastructure as a service environments for either public or private clouds. Midokura was founded in 2010 in Japan. It has raised $5.5 million in venture capital, and has offices in Tokyo as well as in San Francisco and Barcelona.

MidoNet ソフトウェアは、現時点ではベータであるが、パブリック/プライベートのクラウドで、IaaS 環境を構築するクラウド・プロバイダーおよびエンタープライズに対して、仮想ネットワークを提供するためにデザインされている。 Midokura は、2010年に Japan で設立されている。同社は VC から $5.5 million を集め、また、Tokyo/San Francisco/Barcelona にオフィスを持っている。

Midokura’s approach embraces many of the general principles of SDN, including the abstraction of the physical network and software-driven, dynamic provisioning of network services. However, unlike some other SDN approaches, Midokura does not rely on a centralized controller or the use of the OpenFlow protocol. Instead, it creates a virtual network overlay on top of an IP-connected network. MidoNet software, which is designed to run on Linux servers, is deployed at the edge of the network and connected to a customer’s aggregation router. The software creates tunnels to pass traffic through the physical network devices.

Midokura のアプローチは、SDN における一般的原理を数多く取り入れるものであり、そこには、ネットワーク・サービスにおける、物理的ネットワーク/ソフトウェア駆動/ダイナミック・プロビジョニングなどが含まれる。 しかし、いくつかの SDN アプローチとは異なり、Midokura はセンタライズされたコントローラや、OpenFlow プロトコルの利用に依存していない。 それに代えて、IP 接続ネットワークのトップに、仮想ネットワーク・オーバーレイを提供する。 Linux サーバー上で走るようにデザインされた MidoNet ソフトウェアは、ネットワークのエッジにディプロイされ、また、顧客のアグリゲーション・ルーターに接続される。このソフトウェアは、物理的なネットワーク・デバイスを介して、トラフィックを受け渡すためのトンネルを作り出す。

"We push the intelligence to the edges of the network, which are the hosts running the software," says Ben Cherian, chief strategy officer at Midokura. "The hosts provide L2 and L3 services."

「私たちは、ソフトウェアを実行するホストとしての、ネットワーク・エッジにインテリジェンスをプッシュしていく。 それらのホストは、L2 と L3 のサービスを提供する」と Midokura の Chief Strategy Officer である  Ben Cherian は発言している。

This approach is similar to network virtualization that’s enabled by draft protocols such as VXLAN, backed by Cisco Systems and VMware, and NVGRE, backed by Microsoft and others.

このアプローチは、Cisco Systems と VMware が支援する VXLAN や、Microsoft などが進める NVGRE といった、ドラフト・プロトコルで実現される仮想ネットワークに類似している。

Midokura is nothing if not ambitious. In addition to competing against other network virtualization and SDN players such as VMware and Cisco Systems, and startups like Big Switch Networks and Embrane, the company is also going after F5 and Citrix, which provide higher-layer network services such as load balancing. Cherian says customers can use MidoNet’s own load balancing and firewall features and get rid of traditional vendors.

Midokura は、どう見ても、野心的である。 VMware や Cisco Systems といった仮想ネットワークと SDN のプレーヤーおよび、Big Switch Networks や Embrane といったスタートアップとの競合に加えて、ロードバランシングなどの高位層ネットワーク・サービスを提供する F5 や Citrix を、同社は追いかけている。 MidoNet を利用する顧客は、そのロードバランシングとファイアウォールの機能を利用することが可能であり、また、従来からのベンダーから離れられると、Cherian は発言する。

It’s bold talk from a tiny company, but boldness may be required to get noticed in an emerging market that’s already churning with startups and big-name vendors alike, each of which has its own technological approach to SDN.

それは、小さな会社の大胆な発言であるが、この新興成長マーケットで注意を引きつけるためには、こうした大胆さが必要なのだろう。 そこでは、SDN テクノロジーに関する自身のアプローチを持つ、スタートアップやビッグネームが、すでに激しく動き回っている。

Aside from the competitive landscape, Midokura also has to fight for what is, at present, a limited customer base of cloud service providers and very large enterprises that have a pressing need to build multitenant networks that can scale on demand. The wider market of general enterprise customers have an interest in building private clouds and streamlining network provisioning, but they take a cautious approach to re-architecting their networks. As Mike Fratto pointed out in a Network Computing column this spring, "I bet most companies aren’t going to seriously consider SDN for some years–a long enough time for the VC money to dry up and larger vendors to pick up the carcasses."

競合という風景から離れても、いまの Midokura は、クラウド・サービス・プロバイダと大手エンタープライズにおける、限定された顧客ベースを獲得するために戦わなければならない。そこでは、オンデマンドでスケールする、マルチ・テナント・ネットワークの構築が、差し迫ったニーズとなる。 一般的なエンタープライズ・カスタマのための、広範囲なマーケットは、プライベート・クラウドの構築と、ネットワークの合理化に集約されるが、自身のネットワークを再構築するという点において、用心深いアプローチが取られる。同様に Mike Fratto は、今年の春の  Network Computing のコラムで、「 大半の企業は、この数年の間は、SDN について真剣に考えないと確言する。それは、VC の資金を干上がらせるに充分な時間であり、また、大手ベンダーが死体を拾い上げることになる」と、指摘している。

Midokura knows this. "Our primary focus is cloud service providers," said Cherian. "Enterprises have to grapple with culture and other issues. I think it will take them longer to figure out how to use self-service IT in the enterprise."

そのことは、Midokura も知っている。 「 私たちは、クラウド・サービス・プロバイダに、一番にフォーカスしていく。エンタープライズは、そのカルチャーと、それに関連する問題に取り組まなければならない。 エンタープライズにおけるセルフサービスの IT を、どのように使うべきかと、彼らが理解するためには、もっと時間が必要だと思う」と、Cherian は発言している。

As mentioned, MidoNet is currently in beta. Midokura will make the software available to early customers, partners and developers. Cherian said the software would be generally available in a few months.

前述のとおり、いまの MidoNet は、ベータの段階にある。 Midokura は、アーリーアダプタとしてのカスタマ/パートナー/デベロッパーに対して、このソフトウェアを提供するだろう。Cherian は、この数ヶ月の間に、このソフトウェアを提供できると発言している。


image以下のリンクにある、『Midokura と SDN : どのように Layer 2-4 をサポートすべきか_2』 では、Midokura の考え方が端的に語られています。 ーーー 興味深いことに、彼らは、センタライズされたコントロール・プレーンという、いま流行りの信仰に逆らうことを決め、また、大半のインテリジェンスをハイパーバイザ内に実装した。彼らは、Open vSwitch(OVS)カーネル・モジュールを、スイッチング・プラットフォームとして使用するが( OVS は、すべての必要とされる L2-L4 機能の、実装を提供するという、私の主張を証明している)、 OpenFlow エージェントとセンタライズされたコントロール・プレーンを、自身で配布するソフトウェアで置き換えている。ーーー  おそらく、より本質的なところから SDN に取り組んでいるのが Midokura だと思います。 がんばれぇ~~~ image



OpenStack Essex のコントリビューターたちに感謝! – including MIDOKURA
Midokura と SDN : どのように Layer 2-4 をサポートすべきか_1
Midokura と SDN : どのように Layer 2-4 をサポートすべきか_2
OpenStack の検証プロジェクトが日本で始まる – Bit-Isle / TERRAS / Midokura

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 だけでは完成しない


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 だけでは完成しない

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

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

Cloud News Japan から抽出しました・・・

OpenFlow Category

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


NTTデータが OpenFlow コントローラーを独自開発、2012年内に発売
Posted on 2012/06/10 

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

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

image「INTEROP Tokyo 2012」への出展について

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

NTT Com、ネットワーク仮想化を活用したセルフマネージメント型クラウド
Posted on
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デモンストレーションなどについて語った。

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

OpenFlow を世界規模で活用した

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

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

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

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

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

クラウド・OpenFlow で元気を取り戻した今年の Interop
Posted on


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

OpenStack Essex のコントリビューターたちに感謝! – including MIDOKURA

Posted in .Chronicle, .Selected, OpenStack by Agile Cat on April 17, 2012

Who Wrote OpenStack Essex? A Deep Dive Into Contributions
By Joe Brockmeier / April 9, 2012

_ Read Write

It’s always interesting to see who really contributes to open source projects. That’s doubly true when it comes to projects that are corporate-driven, because they provide a lot of insight into which companies are driving a project and have a stake in supporting it. Looking at the numbers for OpenStack’s Essex release, it’s clear that only a small subset of companies involved in OpenStack are driving development.

このオープンソース・プロジェクトに対して、現実にコントリビュートしてきた企業を見ていくのは、常に興味深いことである。 こうした企業がドライブするプロジェクトには、彼らが数多くの洞察を提供し、また、そのサポートにおいて利害を持つという、2つの真実がある。今回の Essex リリースに参加した人数をみれば、OpenStack に関与する企業の一部分だけが、この開発を促進してきたことが明確になる。

clip_image001Mark McLoughlin, an OpenStack contributor and Red Hat employee, took the time to come up with stats  culled from the commits and Gerrit  code reviews for Essex.

OpenStack のコントリビュータであり、また、Red Hat の従業員でもある Mark McLoughlin は、Essex に対してコミットされたコードと、Gerrit レビューから抽出された統計値の解析に時間を費やした

McLoughlin provides several different pieces of the puzzle when looking at the OpenStack picture. He’s looked at the developers who’ve had the most change sets for the release cycle, the most changed lines, and the most lines removed. He’s also looked at lines reviewed, as well as the number of developers by employer.

McLoughlin は、 OpenStack の状況を説明しながら、パズルのような、いくつかの謎も提供している。 そして、彼が注目したのは、リリース・サイクルの更新および、コードの改善と削除において、最も貢献したデベロッパーである。

It’s not a perfect picture, of course. Having the most changes doesn’t mean that the changes were important, for instance. It does give a clearer picture of what’s really going on in OpenStack development.

つまり、OpenStack の開発において、現実に起こっている事象を明らかにするだけのものである。

Developers by Employer

The first figure to consider is the number of developers contributing by company. No one should be shocked to see that Rackspace leads by a wide margin with 51 employees. To put that in perspective, Rackspace’s Stefano Maffulli identified more than 200 people and 50 companies that contributed to OpenStack in the Essex development cycle. McLoughlin’s figures say 226 developers.

最初の図は、コントリビュートしたデベロッパーの数を企業ごとに参照し、考えていくためのものである。 Rackspace が 51人の従業員を参加させ、大差でリードするのを見ても、それに驚く人はいないはずだ。 順番に考えていこう。まず、Rackspace の Stefano Maffulli は、Essex 開発サイクルにおいて OpenStack にコントリビュートしたのは、200人以上の人々と、50社の企業だと認識している。 それに対して McLoughlin は、226人のデベロッパーだとしている。

クリックで拡大 ⇒

This means that more than a fifth of the contributors to OpenStack are on Rackspace’s payroll.

それは、OpenStack へのコントリビュータの 1/5 以上が、 Rackspace からの経費により賄われていることを意味する。

HP has made a big public commitment to OpenStack, and it seems to be living up to it. HP has 19 people identified as contributors to OpenStack Essex.

HP は OpenStack に対して、膨大なパブリック・コミットメントを行なっており、期待に答えているように思われる。 HP は、OpenStack Essex において、19人がコントリビュートしたと認識している。

We told you that Red Hat was contributing heavily to OpenStack in February. But at that time it wasn’t entirely clear where Red Hat fell. Turns out, it’s third in developers, with 12 developers contributing.

2月の時点において、Red Hat が OpenStack にたしいて、大きなコントリビューションを行なっていると説明した。 しかし、その時点において、Red Hat が失速していることを、私は認識していなかった。 結局のところ、12社の デベロッパー・コンロリビューションの中で、同社は第3位となる。

After Red Hat, there’s Citrix (9), Nebula (8), Cisco Systems (6), Canonical (6), Piston Cloud (6), Dreamhost (4) and SUSE (4) in the top 10.

その後に続く Top-10 としては、Citrix (9), Nebula (8), Cisco Systems (6), Canonical (6), Piston Cloud (6), Dreamhost (4),  SUSE (4) の順となる。

The number of bodies, though, can be misleading. It may be that HP and Red Hat developers are not exclusively tasked with OpenStack, though. Some of Red Hat’s developers, for instance, are also doing work packaging OpenStack for Fedora and/or working on OpenShift. A company might only have two employees doing OpenStack work, but they may be doing it full time and/or doing some of the most difficult work.

組織ごとに数えることは、少々紛らわしくもある。しかし、HPと Red Hat のデベロッパーが、専有的に OpenStack の仕事を請け負ったというわけではないだろう。 現実に、何人かの Red Hat デベロッパーも、Fedora および OpenShift のために OpenStack をパッケージングするという作業時従事している。。 ひょっとすると、同社は OpenStack に関して、2人の従業員だけを割り当てているのかもしれない。しかし、もし そうなら、フル・タイムでの作業となり、また、最も困難な作業をこなしているのかもしれない。

Code Influence

To get a clearer picture than we have just by looking at developers, we can also see what companies are responsible for the most code changes and code reviews.


OpenStack uses Gerrit for code review, so it’s possible to see who’s reviewing and approving code. Rackspace dominates here, with 68.1% of reviews. Nebula is next with 12.6% of the reviews, Red Hat has 4.4%, HP has 3.7% and Nicira has 2.4%. When you get to the bottom of the top 10 (Piston Cloud, Canonical) you’re looking at less than 1%.

OpenStack では、コード・レビューのために Gerrit が用いられている。 したがって、コードのレビューを承認を行なってきた企業が分かるようになっている。 Rackspace によるレビューは、全体の 68.1% という圧倒的なものになる。2番手は Nebula であり、レビューの 12.6% を占めている。 そして、その後には、Red Hat の 4.4 %、HP の 3.7%、Nicira の 2.4% が続く。この Top-10 の下位グループ(Piston Cloud と Canonical)に目をやると、その比率が 1% 以下であることが分かるだろう。

クリックで拡大 ⇒

In terms of lines changed by employer, Rackspace is at the top with 46.8%. Nebula has 24.4%, Red Hat has 5.4% and Citrix has 4.0%. Midokura , a company I hadn’t heard of until doing this piece, is in fifth place. Despite Dell’s vocal support for OpenStack, the company doesn’t seem to be contributing a great deal.

コードの改善におけるライン数では、 Rackspace が 46.8% でトップとなる。 2番手の Nebula は 24.4% であり、その後に、Red Hat の 5.4%と、Citrix の 4 % が続く。 この項目を書くまで、私は Midokura を知らなかったが、同社は 5 番手のポジションにある。 (イェーイ!!!) Dell に関しては、OpenStack をサポートする掛け声は高くても、実質的なコントリビュートは行なわれていないようだ。

Change sets are a slightly different story. Rackspace still dominates, with 55.2%. Nebula has 10%, Red Hat has 7.9%, HP has 2.9% and Canonical has 2.6%.

更新の件数になると、少し異なるストーリーとなる。 ここでも、Rackspace が 55.2% でトップとなる。 続いて、Nebula が 10%、Red Hat が 7.9%、HP が 2.9%、Canonical が 2.6% と続く。

Another view we have is bugfixes, out of the Launchpad statistics. Again, Rackspace is at the top with 800, Nebula comes in with 240, Red Hat has 140, Nicira has 69 and Canonical has 50.

バグ・フィックスという視点は、Launchpad 統計から外れたものとなっている。 再び、Rackspace が 800 件でトップであり、Nebula の 240件、Red Hat の 140件、Nicira の 69件、Canonical の 50件が続く。

クリックで拡大 ⇒

In every case, the drop-off after the first five or ten companies is very significant. For example, in terms of lines changed – Canonical is the 11th company by lines changed and only claims 0.6% of changes.

すべてのケースにおいて、トップから 5社~10社に成果が集中しており、その後の落ち込みが顕著である。 たとえば、コード改編における 11番手は Canonical であり、同社が処理したライン数は、全体の 0.6% に留まっている。

What It Means

Despite the effort to paint OpenStack as a widely supported project with lots of developer commitment , it’s still Rackspace that’s doing the lion’s share of the work.

たくさんのデベロッパーがコミットする、広く支援されたプロジェクトとして、OpenStack を見せる労力にもかかわらず、その作業においては、依然として Rackspace が圧倒的な比率を占めている。

Nebula is also pulling a lot of weight in the project, though it has fewer contributors than HP or Red Hat. The top 10 corporate contributors are pulling a disproportionate share of the load in OpenStack.

さらに、このプロジェクトでは Nebula が大きな役割を担っているが、そのコントリビュータは HP や Red Hat より少ない。全体としては、Top-10 の企業コントっリビュータが、OpenStack の作業負荷において、不均衡な比率を占めている。

This isn’t abnormal for an open source project, though. If you look at Linux kernel development , you’ll see that the top contributors are doing more than the long tail of companies that are involved in kernel development.

Linux カーネルの開発に目を向けると、トップ・コントリビュータが、カーネル開発に関与する企業よりも、ロイングテールの観点から、より多くの貢献を達成していることが分かるだろう。

But the disparity is striking. No company is shouldering nearly 50% of kernel development by any measure.

しかし、OpenStack との相違は顕著である。 どんな尺度で測っても、Linux カーネルの開発において、50% 近い負荷を担っている企業はいない。

Looking at recent kernel development, you’ll see Red Hat at the top of companies contributing to the kernel. But Red Hat sits at the top of the list (after developers with no corporate affiliation), with 10.7% of the changes from the 2.6.36 kernel to the 3.2 kernel. Intel has 7.2%, Novell 4.3%, IBM 3.7% and so on – down to a long list of companies contributing tiny bits.

Linux カーネルにおける、最近の開発状況を見てみよう。 そのトップである Red Hat が、カーネルにコントリビュートしているのが分かるだろう。 しかし Red Hat は、カーネル 2.6.36 ~3.2 の間で 10.7% の変更に留まっていることが、そのリスト(after developers with no corporate affiliation)に示されている。その後には、Intel の 7.2%、Novell の 4.3%、IBM の 3.7% と続き、その長いリストの最後には、きわめて低い比率の企業が記されている。

The real contributor community outside of Rackspace doing significant development is smaller than one might think given the figures coming out of OpenStack. It looks like it’s on its way to a healthy mix, but I’m not sure it’s quite there yet.

OpenStack から得られる成果と比較して、Rackspace の外で重要な開発に従事している、実際のコントリビューター・コミュニティは小さいのかもしれない。 そして、健全に混じりあう途上にあるとは思えるのだが、その道程を走破できると信じられる道程には、まだ到達していないと、私は確信している。

See Also


TAG indexこうして、コントリビューション全体が俯瞰できることは、とても良いことですね。 そして、現時点での大きな問題点として、Rackspace への過大な異存が明らかになりました。 文中の、Linux コミュニティとの比較により、OpenStack の特殊性が強調されてしまいますが、まだ走り始めたばかりの若いコミュニティですので、長い目で見てあげたいですね。 それにしても、MIDOKURA の頑張りはスゴイです。 あまり、日本を意識してはイケナイのでしょうが、日本人として嬉しいです! ーーー ac-stamp-232



OpenStack は Essex で、どう変わったのか?
Red Hat と IBM は、OpenStack に参画するのだろうか?
CloudStack は Apache へと走るが、OpenStack に問題は生じないのか?
OpenStack デベロッパーに朗報! Sandbox とAPI Reference






OpenStack は Essex で、どう変わったのか?

Posted in .Selected, OpenStack by Agile Cat on April 12, 2012

“Essex” version of OpenStack debuts
Paula Rooney | April 5, 2012


Summary: The fifth release of OpenStack, code named “Essex,” debuted today, with enhanced quality, usability and extensibility across enterprise, service provider and high performance computing (HPC) deployments, the project announced. Essex is integrated in Canonical’s Ubuntu 12.04.

Summary: Essex というコードネームの、OpenStack における 5回目のリリースは、品質/有用性/拡張性を向上させたものであり、エンタープライスおよび、サービス・プロバイダ、HPC デプロイメントに対応するプロジェクトだという発表があった。 また、Essex は、Canonical の Ubuntu 12.04 とインテグレートされている。


In a week when it was upstaged by rival open source CloudStack,OpenStack got a shot in the arm with its fifth major release, dubbed “Essex,” on Thursday.

オープンソースのライバルである CloudStack に話題を奪われた週だったが、その木曜日に OpenStackが得たのは、5回目のメジャー・バージョンアップとなる、Essex というカンフル剤だった。

The “Essex” release, which is said to contain more than 150 new features, was developed by more than 200 developers, the open source project noted in a statement today, which highlighted the core improvements, including:

Essex のリリースには、150 以上の新機能が含まれ、また、200 人以上のデベロッパーにより開発されたと言われている。このオープンソース・プロジェクトは、今日のステートメントにおいて、コアとなる改善ポイントを強調したが、その中には以下の項目が含まれる:

  • imageOpenStack Compute (code-name Nova) – Focus on stability and integration with Dashboard and Identity, including enhancements to feature parity among the tier one hypervisors — making it a seamless user experience across each hypervisor — improved authorization and live migration with multi-host networking. There were also contributions to support high-performance computing and additional block storage options, including support for Nexenta, SolidFire, and NetApp storage solutions.
  • OpenStack Object Storage (code-name Swift) – Significant new features to improve compliance and data security with the ability to expire objects according to document retention policies, more  protections against corruption and degradation of data, and sophisticated disaster recovery improvements. Also new capabilities important to service providers including the ability to upload data directly from an authenticated web page and the ability to restrict the maximum number of containers per account.
  • OpenStack Dashboard (code-name Horizon) – The first full release of OpenStack Dashboard provides administrators and users the ability to access, provision and automate cloud-based resources through a self-service portal. The extensible design makes it easy to plug in and expose third party products and services, such as monitoring.
  • OpenStack Identity (code-name Keystone) – The first full release of OpenStack Identity unifies all core projects of the cloud operating system with a common authentication system. The technology provides authorization for multiple log-in credentials, including username/password, token-based and AWS-style logins.
  • OpenStack Image Service (code-name Glance) – The Image Service received several key updates to improve usability, authorization and image protection.
  • OpenStack Compute (code-name Nova) – 安定性と、Dashboard との統合、そして Identity にフォーカスし、認証を改善するティア・ワン・ハイパーバイザーのパリティと、マルチホスト・ネットワークを用いたライブ・マイグレーションの拡張も含む(個々のハイパーバイザをまたいだシームレスなユーザー・エクスペリエンスを実現)。さらに、HPC(high-performance computing)および、Nexenta/SolidFire/NetApp のサポートも含めた追加型ブロック・ストレージ・オプションも、コントリビュートされている。
  • OpenStack Object Storage (code-name Swift) – ドキュメント・リテンション・ポリシーにしたがう、重要な新機能によりオブジェクトに期限を定め、コンプライアンスとデータ・セキュリティを改善する。また、データの破損と劣化からの保護および、DR 機能の洗練させるための改善も含む。さらに、サービス・プロバイダにとって重要な機能として、認証された Web ページからの、ダイレクトなデータのアップロードと、アカウントごとの最大コンテナ数の制限も含まれる。
  • OpenStack Dashboard (code-name Horizon) – OpenStack Dashboard における初めてのフル・リリースは、クラウド・ベース・リソースに関するアクセス/プロビジョニング/自動化の能力を、セルフ・サービス・ポータルを介してアドミニストレーターとユーザーに提供する。 たとえばモニタリングのようなサードパーティーのプロダクトおよびサービスは、拡張可能なデザインにより、そのプラグインとエクスポーズを容易にする。
  • OpenStack Identity (code-name Keystone) – OpenStack Identity における初めてのフル・リリースは、クラウド・オペレーティング・システムの全てのコア・プロジェクトを、共通の認証システムを用いて統一していく。このテクノロジーにより、マルチ・ログイン証明に関する認証が提供され、また、Username/Password と、トークン・ベースの AWS-style ログインも取り込まれる。
  • OpenStack Image Service (code-name Glance) – Image Service に関しては、ユーザビリティおよび、認証、イメージ保護を改善するための、いくつかの重要なアップデートが施されている。

NASA, Rackspace, Intel, Dell, Canonical-Ubuntu, HP and SuSE are among 155 companies that support the open source cloud OS architecture.

このオープンソース・クラウド OS アーキテクチャをサポートする155 社の中には、NASAおよび、Rackspace、Intel、Dell、Canonical-Ubuntu、HP、SuSE などがいる。

Citrix was an original backer but this week switched gears, dropped OpenStack and donated its CloudStack to Apache to try to build up support for that open source cloud OS effort.

Citrix は元からの支援者であったが、今週に方向を転換することになった。 つまり、OpenStack から離れて、CloudStack を Apache を寄贈し、オープンソース・クラウド OS の確立を試みる。

Red Hat and IBM have also demonstrated support for OpenStack but have yet to announce it publicly. Red Hat purchased OpenStack-focused Glusters last year and its sponsored open source Linux project recently integrated OpenStack in the latest rev of Fedora.

さらに、Red Hat と IBM も、OpenStack をサポートする意思を示しているが、まだ、公にはアナウンスしていない。 昨年のことだが、Red Hat は OpenStack にフォーカスする Glusters を買収している。そして、Fedora の最新 Rev に OpenStack を統合するという、オープンソース Linux プロジェクトをサポートしている。

One OpenStack backer said it may take time for the open source cloud OS market to shake out but he has made his bet.  “We are in an early market, and it will take 5-10 years until we potentially see a single winner.  In the near term, there will be many winners and there is little profit in handicapping the game in absolute terms,” said Alan Cohen, VP Marketing, Nicira. “Nicira likes the raw energy and momentum toward open cloud frameworks.   We are deep and public into OpenStack — we love the community, the innovation –  but we also have other customers who use different cloud management frameworks.  At the end of the day, customers will make this decision.”

ある OpenStack 支援者が言うには、オープンソース・クラウド OS 市場は、時間をかけながら淘汰と再編を繰り返すことになる。 そして、彼はそこに賭けている。「 私たちは、黎明期のマーケットにあり、ハッキリとした勝者を認識するまでに 5年~10年を要するだろう。  また、近いうちに、数多くの勝者が出現するだろうが、絶対的なゲームにおけるハンディとしての、きわめて小さな利益を得るだけだ。Nicira は、オープン・クラウド・フレームワークに対して、少ない労力と推進力で取り組んでいきたいと思ってている。   私たちは、OpenStack の本質をパブリックにコミットしている。 つまり、そのコミュニティとイノベーションを評価しているのだ。しかし、その一方で、異ななるクラウド・マネージメント・フレームワークを利用する顧客も有している。  結局のところ、最終的な判断は、顧客に委ねられるだろう」と、Nicira の VP Marketing である Alan Cohen は発言している。


TAG indexこのところ、Apache へと路線を変更した CloudStack に、話題という面では遅れをとってしまった感じの OpenStack ですが、以下の <関連> にもあるように、Red Hat/IBM/Sony といったメジャー・プレイヤーの動きも気になりますし、AWS API をめぐる Eucalyptus や CloudStack とのつばぜり合いも気になります。しばらくの間は、この辺りにホットな話題が集中しそうですね。 ーーー __AC Stamp 2



Red Hat と IBM は、OpenStack に参画するのだろうか?
CloudStack は Apache へと走るが、OpenStack に問題は生じないのか?
Eucalyptus と OpenStack のドックファイトが、さらに高度なクラウド戦争を引き起こす
Amazon の新たな悩みは、Sony と OpenStack の蜜月にあるのか
OpenStack デベロッパーに朗報! Sandbox とAPI Reference


%d bloggers like this: