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

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

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

How Google’s OpenFlow backbone works
John Dix  On: 09 Jun 2012  For: Network World (U.S.)


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

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


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


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


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


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

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

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

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

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

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

Did you have any setbacks of note?


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

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

● How far away is OpenFlow from being fully baked?

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

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


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

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

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

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

● What are the next steps?


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

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

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

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

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

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

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


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

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



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



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

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

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

How Google’s OpenFlow backbone works

John Dix  On: 09 Jun 2012  For: Network World (U.S.)


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

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


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

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


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

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

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

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

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

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

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

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

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


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


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

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

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


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

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

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

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

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

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

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


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

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

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

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

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

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

● Are you actually pumping in fake traffic?


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

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



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



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




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

VMware が考える、ソフトウェア定義によるデータセンターとは?

Posted in .Selected, Data Center Trends, SDN, VMware by Agile Cat on May 17, 2012

VMware: ‘The software-defined data center is coming’
By Derrick Harris May. 9, 2012

_ Gigaom

VMware CTO Steve Herrod is taking the stage at Interop on Wednesday morning to deliver a message about the future of enterprise data centers: “[S]pecialized software will replace specialized hardware throughout the data center.” What server virtualization via hypervisors did for computing, new methods of virtualization and software-defined networks are doing at every other layer of IT stack. “Software-defined data centers” are coming, and they’ll redefine infrastructure for the next generation of applications.

VMware CTO の Steve Herrod は水曜の朝の Interopステージに立ち、「データセンター全体を通じて、特化されたソフトウェアが、特化されハードウェアを置き換えるだろう」という、エンタープライズ・データセンターの未来についてメッセージを投げかけた。 ハイパーバイザーによるサーバーの仮想化は、コンピューティングのために何をしたのだろう。 そこから生まれた、新しい仮想化の手法と SDN(Software Defined Networks )が、IT スタックの全レイヤーに影響を及ぼしている。 そして、それに続く「 Software Defined Data Centers 」が、次世代アプリケーションのためのインフラを再定義していくだろう。

herrodHerrod, who shared his vision with me during a call last week, said one problem in IT has been that for decades applications drove the infrastructure. Batch processing begot mainframes, web applications begot the LAMP stack, and they all still exist, turning data centers into a hodgepodge of specialized legacy systems. “Today’s data center is almost a history museum of past IT ideas,” Herrod said.

先週に電話で話した際に、私と Herrod は視点を共有した。 つまり、IT が何十年も抱えてきた問題は、アプリケーションがインフラをドライブしてきたことである。 バッチ処理がメインフレームを生み出し、また、Web アプリケーションが LAMP スタックを生じ、それらは今でも存在し続けている。 その結果としてデータセンターは、特化されたレガシー・システムの寄せ集めになってしまった。 「今日のデータセンターは、これまでの IT における、アイデア・ヒストリーの博物館といっても過言ではない」と、Herrod は発言している。

On the contrary, Herrod explained,  software-defined data centers are “generation-proof.” They collapse disparate systems into a singularity built atop commodity x86 processors and other gear. Software provides everything that’s needed to adapt the data center to new situations and new applications, and to manage everything from storage to switches to security. Although VMware will always work with hardware partners, Herrod said, “If you’re a company building very specialized hardware … you’re probably not going to love this message.”

それに対して、 Software Defined Data Centers は「Generation Proof」であると、Herrod は説明する。 そこでは、本質的に異なるシステムが分解され、また、コモディティな x86 プロセッサや各種ギアの上に構築されていく。つまり、新しいシチュエーションとアプリケーションに対してデータセンターを適用するために、また、ストレージからセキュリティ・スイッチまでを管理するために、必要とされるあらゆるものをソフトウェアが提供していく。 VMware はハードウェア・パートナーと常に協調していくが、「あまりにも特殊なハードウェアを作る会社は、私たちのメッセージを嫌うかもしれない」と、Herrod は発言している。

Essentially, Herrod said, software-defined data centers will bring the dynamic natures of Google, Facebook and Zynga data centers into the mainstream. Yes, it will be a bit more difficult to do this in environments running more than one application, many of them legacy apps, but it’s possible. “Virtualization and the hardware vendors have [already] gotten us to a place where we can deal with the big modern trends [around scalability and performance],” Herrod said.

本質的に Software Defined Data Centers は、その主流の中に Google/Facebook/Zynga のデータセンターにおける、ダイナミックな特質を取り込むものとなると、Herrod は言う。つまり、その大半がレガシーなものとなる、複数のアプリケーションを実行する環境で、それを実現することが難しくても、それらも現実には可能となる。 「仮想化とハードウェアのベンダーは、(スケーラビリティとパフォーマンスに関連する)近代トレンドを取り扱うことが可能な場所を、(すでに)有している」と、Herrod は発言している。

VMware’s networking products.

That’s good news for CIOs and other IT managers who feel pressure to run data centers as efficiently, dynamically and inexpensively as Google and its ilk do, but who know getting to that point using legacy methods will be an exercise in pain tolerance. ”To actually stand there and say this platform can handle all your applications is pretty bold,” Herrod said. However, he added, the current state of IT represents “a point in time where the pieces have come together to do this.”

Google などのようにデータセンターを効果的/動的/経済的に運用するという、プレッシャーにさらされる CIO や IT Manager にとって、それはとても良い知らせである。しかし、レガシーな手法を用いて、そのポイントに達することを知っている人々にとっては、痛みに耐えるエクササイズとなるだろう。 「実際に、そのような状況において、このプラットフォームが、すべてのアプリケーションを処理すると発言することは、かなり大胆なことである」と、Herrod は言う。 しかし、IT における現状は、「 それを実現するための要因は、いずれ揃うことになる」と表現するだけに過ぎない。

Aside from virtualization, the ubiquity of which has laid the foundation for VMware’s software-defined vision, Herrod attributes much of the momentum to broad acceptance of software-defined networks. They help eliminate “the last bastion of pain” in creating a fluid data center.

VMware における Software Defined ビジョンを遍在させる仮想化は別として、SDN(Software Defined Networks)を幅広く受け入れる勢いにも、大きな要因があると Herrod は考えている。 それらは、可変性に富んだデータセンターにおける、「最後の痛みの要塞」を率先して排除していくだろう。

Herrod will be expanding on VMware’s plans for the software-defined data centers during an onstage discussion with me at our Structure conference next month, and again at VMworld in August. But if you’ve been following the company for the past couple years, you can probably see where it’s headed. It wants to own the next-generation data center from bottom to top, from infrastructure to applications platformsto applications.

Herrod は、Software Defined Data Centers の計画について、これから拡張していくことになるが、それについて、来月に開催される Structure カンファレンスで、そして、8月の VMworld の ステージで、説明してくれるだろう。 これまでの数年間にわたり、同社の動きを追いかけてきた人々には、おそらく、その方向性が見えるのだろう。 それは、次世代データセンターのボトムからトップまでを、つまり、インフラからプラットフォームアプリケーションにまで到る、すべてを所有することである。

As usual, VMware’s vision is compelling, and it has many of the pieces in place to pull it off. It’s up to the Microsofts, Citrixes and Openstacks of the world to develop compelling alternatives or risk seeing VMware — if it can deliver on what it’s promising — expand its hypervisor empire up the stack.

いつものように、VMware のビジョンには説得力が備わっており、また、それを適切に実現していく領域に、数々の要因を保有している。 それに対する説得力のある代案は、Microsoft/Citrixe/Openstack の世界が構築していくものに委ねられる。 そして、VMware の約束するものが提供されるなら、同社のハイパーバイザー帝国が、さらに積み上げられる状況を魅せつけられることになる。

Related research and analysis from GigaOM Pro:


TAG indexう~ん、とても難しい記事ですね。 おそらく、サーバーやネットワークの仮想化の先には、データセンター全体の仮想化が待っているということなのでしょうが、Agile_Cat の頭の中では、それを構成する要素が、まだ、整理しきれません。 しかし、そのような未来が徐々に近づいていることは、なんとなく感じますし、それを実現する最右翼として、VMware が存在していることも分かります。 もっと、勉強しなければ :) ーーー __AC Stamp 2



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

Google 先生の OpenFlow 講座 – DC 間接続を低コストで達成するには

Posted in .Selected, Google, OpenFlow, SDN by Agile Cat on April 11, 2012

How Google is using OpenFlow to lower its network costs
Stacey Higginbotham Apr. 9, 2012

_ Gigaom

Google is checking out a new form of networking protocol known as OpenFlow in the communications networks that run between its data centers. The search giant is testing the use of software-defined networks using OpenFlow in order to lower the cost of delivering information between its facilities, says Urs Hölzle, SVP of technical infrastructure and Google Fellow in an interview with me.

Google は、データセンター間を結ぶコミュニケーション・ネットワークにおいて、OpenFlow として知られる新しい形式の、ネットワーク・プロトコルを調査している。 この検索の大手は、そのファシリティ間で情報を配信するコストを低減するために 、OpenFlow を用いる SDN(Software Defined Networks)をテストしていると、Google Fellow であり SVP of Technical Infrastructure でもある Urs Holzle が、私とのインタビューで話してくれた。

Google’s infrastructure is the stuff of engineer dreams and nightmares. The company’s relentless focus on infrastructure has led it to create a competitive advantage because it can deliver search results faster and for less money than the next guy. Much like Dell conducts studies showing that lowering a table where people assemble its computers saves seconds and costs, Google understands that investing in infrastructure can help it shave a few cents off delivering its product. And the next area that’s ripe for some infrastructure investment might be networking, specially using the OpenFlow protocol to create software defined networks.

Google のインフラストラクチャには、エンジニアの夢と悪夢が詰め込まれている。 そして、同社のインフラに対する執拗なフォーカスにより、競争上の優位性が引き出され、誰よりも速く安く検索結果を届けるという結果をもたらしてきた。 Dell などの数多くの企業は、コンピュータをアセンブルする際の、時間の短縮とコストの低減を実現するための研究を行なっている。 その一方で Google は、インフラへの投資により、オンライン配信における数セントの削減が、積み上げられることを理解している。 そして、いくつかのインフラストラクチャ投資における次の領域として、OpenFlow プロトコルを活用した SDN 構築という目的がある。

For Google, at a certain point, communications between servers at such a large-scale can be a problem, notes Hölzle, who is speaking at the Open Networking Summit in Santa Clara next week. He explains that the promise of OpenFlow is that it could make networking behave more like applications thanks to its ability to allow the intelligence associated with networking gear to reside on a centralized controller.

Google の場合には、あるポイントにおいて、このようなラージ・スケールのサーバー間で、コミュニケーションに問題が生じるかも知れないと、来週に Santa Clara で開催される、Open Networking Summit のスピーカーでもある Holzle は指摘している。OpenFlow がもたらすものは、ネットワークをアプリケーションのように振る舞わせることであり、センタライズされたコントローラの中に、インテリジェントに組み合わされたネットワーク・ギアを論理的に配置していく能力だと、彼は説明する。

Previously, each switch or piece of networking gear had its own intelligence that someone had to program. There was no holistic view, nor a way to abstract out network activities from the networking hardware. But with OpenFlow the promise is you can program the network and run algorithms against it that can achieve certain business or technical goals.

これまでのスイッチやネットワーク・ギアは、誰かがプログラムしなければならない、それら自身のインテリジェンスを持っていた。 そこには、全体論的な視野が無く、また、ネットワーク・ハードウェアから離れて、そのアクティビティを抽象化する術もなかった。 しかし、OpenFlow を用いることで、ビジネスおよびテクニカルにおける特定のゴールを達成していくための、ネットワークのプログラミングと、アルゴリズムの実行が約束される。

“I think what we find exciting is OpenFlow is pragmatic enough to be implemented and that is actually looks like it has some legs and can realize that promise,” he said. However, he added, “It’s very early in the history and too early to declare success.”

「私たちが気づいている気分の高揚は、プログラムによる OpenFlow の実装が十分な意味を持ち、また、実際にいくつかの経路を利用できそうなことだ。 それにより、目論見を実現できそうだと、私は考えている」と、彼は発言している。 しかし、「その歴史はきわめて短く、また、成功を宣言するにはあまりにも早すぎる」とも、付け加えている。

Google is trying the protocol out between data centers, although Hölzle didn’t disclose details about how much Google is saving and how widespread the implementation is. Hölzle said the search giant was trying to see how it could make its wide-area network and long-distance network more flexible and speed up the delivery of services to users without adding costs. However, costs for Google aren’t just measured in terms of bandwidth, but also in terms of people required to operate the network or configuring it.

Google は、データセンター間のプロトコルについては公表しようとしているが、その範囲と費用対効果について、Hölzle は詳細を明らかにしなかった。 Holzle が言うには、この検索の大手が確認しようとしているのは、広域におよぶ長距離ネットワークの柔軟性を、さらに高めるための方式であり、また、コストを増大することなく、ユーザーに対するサービスの配信を高速化する方法である。 しかし、Google におけるコストは、ネットワークの帯域幅という観点でけでは測定できない。つまり、ユーザーが必要とする運用や設定という視点も、欠かせない要因となる。

TAG index“The cost that has been rising is the cost of complexity — so spending a lot of effort to make things not go wrong. There is an opportunity here for better network management and more control of the complexity, and that to me is worth experimenting with,” Hölzle said. “The real value is in the [software-defined network] and the centralized management of the network. And the brilliant part about the OpenFlow approach is that there is a practical way of separating the two things: where you can have a centralized controller and it’s implementable on a single box and in existing hardware that allows for a range of management and things that are broad and flexible.”

「コストにおける上昇分は、複雑さからくるものである。 つまり、物事を間違った方向へ向かわせないように、膨大な労力を費やしていることになる。 そして、より良いネットワーク管理を実現し、複雑さをコントロールするチャンスがある。それが OpenFlow であり、また、私にとって実験する価値のあるものとなる。現実の価値は、SDN の中にあり、また、ネットワークのセンタライズされた制御の中にある。 そして OpenFlow アプローチの素晴らしい部分は、2つのものを切り離すための、現実的な方式を提供する点である。 センタライズされたコントローラーを利用でき、また、シングルボックスもしくは既存のハードウェア上に、それを実装できるなら、幅広い管理が実現され、また、物事に広がりと柔軟性が提供される」と、 Holzle は言う。

But OpenFlow still requires some work. Hölzle said that there are issues with how you communicate between OpenFlow networks and those that aren’t. So, today, Google takes its OpenFlow traffic and hands it over to a router running alternative network protocols such as MPLS or BGP, what Hölzle calls a “normal” router. He expects that to change over time as things standardize within OpenFlow and among vendors. As he said at multiple times throughout the conversation, these are early days for OpenFlow and software-defined networks.

しかし、OpenFlow には、いくつかの課題が残されている。 Holzle は、OpenFlow ネットワークと、それ以外のネットワークを結ぶ通信の方法に問題があると発言している。 したがって、いまの Google では、受け取った OpenFlow トラフィックを、MPLS もしくは BGP などのネットワーク・プロトコルを実行するルーターに手渡している。 それらについて、Holzle は NORMAL ルーターと呼んでいる。そして、それらのものが、OpenFlow の中で、あるいはベンダー間において、長い時間をかけて標準化されていくと、彼は予想している。この会談において、彼が何度も繰り返して言ったように、OpenFlow と SDN(Software Defined Networks)は黎明期にある。

Related research and analysis from GigaOM Pro:




TAG index他にもあるのでしょうが、Agile_Cat が知るかぎり、Google が OpenFlow や SDN について初めて語るコンテントです。 価値は、OpenFlow ではなく SDN にあるとは、とても良い言葉で、さすが Google 先生と言わざるを得ません。 また、DC の 内と外では、使うべきプロトコルが違いますよと示唆しているようにも聞こえます。 来週の Open Networking Summit では、どんな発表があるのでしょうか? とても楽しみです。 ーーー __AC Stamp 2



OpenStack における SDN コネクションを探求する _1
OpenStack における SDN コネクションを探求する _2
OpenFlow 1.2 が ONF の評議会で承認された – NTT Com も委員に
Juniper がデベロッパーに対して、OpenFlow ソースコードを提供し始めた
OpenFlow 関連ポストへのリンク集(20本強)


%d bloggers like this: