Agile Cat — in the cloud

やったぜ! Facebook の Open Compute Project がオープン・スイッチに挑戦だ!

Posted in .Selected, Data Center Trends, Facebook, Network, Open Compute by Agile Cat on May 14, 2013

Heck yeah! Facebook’s Open Compute Project is making an open source switch
http://wp.me/pwo1E-66u
By
Stacey Higginbotham
http://gigaom.com/2013/05/08/heck-yeah-facebooks-open-compute-project-is-making-an-open-source-switch/

_ Gigaom

Summary: Not content with open sourcing the server and storage hardware inside data centers, Facebook’s Open Compute Project has teamed up with others to build an open source top of rack switch. Here’s why it matters.

Summary: データセンター内のサーバーおよびストレージといったハードウェアを、オープンにするだけでは満足しないようだ。 Facebook の  Open Compute Project は、ラックのトップに置かれるスイッチをオープンソースで構築するために、そのメンバーたちと協力し始めた。なぜ、それが重要なのが、説明しよう。

ーーーーー

The Open Compute Project, which Facebook launched a little more than two years ago, has decided that utterly disrupting the server and storage market isn’t enough. On Wednesday, it said it would solicit input on an open source top-of-rack switch.

2年と少し前に Facebook が立ち上げた Open Compute Project は、サーバーとストレージの市場を完全に破壊するだけでは、充分ではないと判断したようだ。 そして、この水曜日(5/8)には、オープンソースの top-of-rack switch に関して、仲間を募ると述べた

The project, in a presentation by Frank Frankovsy at Interop, said it was taking a slightly different tack with its design, deciding to get input from others before actually making and releasing the hardware to the community. However, just because the hardware isn’t designed yet, Facebook isn’t going to twiddle its thumbs for a traditional multi-year design cycle. Frankovsky told me in an interview that he expects the hardware to be out in 9 to 12 months.

Interop での Frank Frankovsy のプレゼンテーションによると、このコミュニティのために、実際にハードウェアを作りリリースを解する前に、他者からの意見を取り入れるという点で、これまでの方針とは少し異なる取り組みになる。ただし、まだハードウェアがデザインされていないからといって、Facebook がノンビリと、従来からの複数年にまたがるデザイン・サイクルに甘んじるつもりはないようだ。Frankovsky は私とのインタビューで、9 〜 12ヶ月の間で、出荷できるようにしたいと答えている。

“We have built these islands of openness in the data center but the last element, and the one that was connecting the compute and storage, was the network,” said Frankovsky. “And there is a lot of pent-up passion out there for breaking open this appliance model.”

「 私たちは、データセンターの中に、オープンな島々を構築してきたが、また、最後の要素が残っている。 それは、コンピューティングやストレージのためのコネクションであり、つまりはネットワークのことなのだ。そして、周囲を見れば、現行のアプライアンス・モデルをこじ開けようとする、爆発寸前の情熱にあふれている」と、Frankovsky は発言している。

Networking is the last bastion of proprietary profits

Prepare to be disaggregated, switch!

For those who don’t dwell in data centers, the top-of-rack switch is the networking gear that sits on the top of a rack of servers directing traffic between those boxes and between the other racks in the data center. While the networking world is all aflutter over the promise of OpenFlow and software-defined networking, very little real progress has been made in building switches for the webscale data center.

データセンターの住人ではない人のために説明しておくが、top-of-rack スイッチとは、サーバー・ラックの最上部に置かれるネットワーク機器のことであり、データセンター内のラック間で、トラフィックをやり取りするボックスとして提供されている。 ネットワークの世界は OpenFlow と SDN (software-defined networking) の約束に翻弄されているが、Web スケールのデータセンターにおけるスイッチ群の構築については、きわめて小さな進歩しか達成されていない。

Google, a few years back, had famously issued a request for a new type of switch that would fit its very specific scaled-out needs and no one responded. Now the search giant makes its own hardware. But soon after that, Andy Bechtolsheim saw the need for Google-like speeds and scale and started Arista, a switch company that has dominated in the webscale, financial and high-performance switching space. Meanwhile, at the lower end, Cisco’s cheaper Nexus line of switches have done really well.

数年前の、とても有名な出来事だが、スケールアウトのニーズに合った新しいタイプのスイッチを、Google が要求していたのだが、どのメーカーもそれに応えなかった。 したがって、このサーチ・ジャイアントは、いまでは自身でハードウェアを作る状況になっている。 しかし、その直後に Andy Bechtolsheim が、Googleが言うようなスピードとスケールの必要性を理解し、Arista を立ち上げた。 同社は、Web スケールや金融が、高性能スイッチング・スペースを支配する会社になった。 その一方で、ローエンドでは、Cisco の安価な Nexus ラインナップが頑張っている。

Facebook’s Najam Ahmad.

Yet, these options aren’t palatable for Frankovsky or Najam Ahmad of Facebook (Ahmad will be at our Structure conference in June discussing more about Facebook’s networking strategy). On the existing product side, Frankovsky is frustrated by hardware that doesn’t play nicely at scale. He specifically mentioned that the side venting of heat on switches means he can’t place them right next to another switch. Ahmad, who is in charge of the social-networking giant’s network, is concerned about getting out of the proprietary OS model.

しかし、こうした選択肢は、Facebook の Frankovsky や Najam Ahmad( Structure conference in June で Ahmad は、Facebook のネットワーク戦略についての詳細を語る)の好みではない。既存のプロダクトに対して Frankovsky は、スケールを上手く達成できないと不満をつのらせていた。とりわけ彼は、スイッチで排熱サイド・ベントにより、スイッチの横に何も置くことができないことを指摘している。また、このソーシャル·ネットワーキングの巨人において、ネットワークを担当している Ahmad は、プロプライエタリ OS モデルからの脱出を検討している。

“We want it to be OS-agnostic so we can use one from our existing provider or build our own,” he said. He added that he’d prefer an open Linux-based implementation. These proprietary OSes — Cisco has IOS, Juniper has Junos and Arista has EOS — are one of the reasons that companies are locked into one networking gear provider. They are also stuck using proprietary code to make changes.

「 私たちは、OS の種類に気遣いしたくない。 そうすれ、既存のプロバイダからのものを使用することも、独自に構築することも可能になる」と、彼は発言している。そして、オープンな Linux ベースの実装を好むだろうと、付け加えている。 プロプライエタリな OS( Cisco の IOS/Juniper の Junos/Arista の EOS)は、ユーザー企業を特定のネットワーク・ギア・プロバイダにロックインさせる、もう1つの理由でもある。そして、それらの企業も、プロプライエタリなのコードを変更することで、立ち往生している。

Who will be the Red Hat of the networking OS?

Networking cables along the ceiling at Facebook HQ.

If you are chock full of technically savvy people, losing the agility that comes from writing your own code as well as paying higher prices for the proprietary hardware and software combination is probably maddening. Hence Facebook’s interest in the open source OS. Of course, building out the underlying hardware is only the first step, the next will be supporting an OS that runs on top of that system.

たくさんの、テクノロジーに精通した人々を有する場合、独自のコードからもたらされるアジリティの喪失だけではなく、プロプライエタリなハードウェアとソフトウェアの組み合わせに対して、高い費用を支払うことは腹立たしいことだろう。それ故に、Facebook の関心はオープンソース OS に集約される。もちろん、基礎となるハードウェアを構築することは単なる最初のステップであり、そのシステム上で動作する OS のサポートが次に続く。

While Facebook might build its own OS, not every company will want to do that, and Facebook may not open source its own networking OS if it ever makes one. That leaves a market opportunity. Perhaps a firm like Arista might move in here with an open source version of EOS, although given that Arista uses merchant silicon in its boxes, putting up an open-source version of its software would eat into its margins.

Facebook は、独自の OS を構築するかもしれないが、すべての企業が、必ずしもそれを構築するとは限らない。 そして、Facebook がグループの一員でなければ、その独自ネットワーク OS がオープンにならない可能性もある。それにより、マーケットにはチャンスが残される。Arista のような会社は、EOS のオープンソース版を携えて、ここに移動するかもしれない。しかし、その BOX で市販のシリコンを使用し、そこにソフトウェアのオープンソース版を入れて、マージンを得ることが前提となるだろう。

This is neither Open Flow nor SDN

But let’s go back to the box. Facebook is working with Broadcom, Intel, The Open Daylight Foundation, the Open Networking Foundation and Big Switch as some of its collaborators on this project. The box itself might run x86 hardware or a proprietary ASIC, according to Frankovsky. As for the protocols, Open Compute is going to see what the other collaborators want.

ここで BOX の話に戻ろう。 Facebook は、このプロジェクトへの協力者として、Broadcom/Intel/The Open Daylight Foundation/Open Networking Foundation/Big Switch などと協調している。 Frankovsky の話によると、その BOX 自体は、x86 ハードウェアやプロプライエタリな ASIC を走らせることになりそうだ。 そして、プロトコルとしては、他の協力者たちが欲するものを、Open Compute が見定めていくことになる。

Software-defined networking

But for those wondering about Open Flow support, it’s likely. Frankovsky said that the Open Networking Foundation asked Facebook to get involved via the Open Compute Project with making open networking hardware. While Frankovsky and Ahmad didn’t cop to it, I know there has been frustration in many areas of the webscale and networking world that the promise of commodity hardware that Open Flow could offer has not really hit the market in a way that offers the most flexibility for data center operators.

しかし、Open Flow のサポートについては、疑問を抱くものにいるかもしれない。Frankovsky が言うには、オープンなネットワーク・ハードウェアを作ること関連して、Open Networking Foundation は Open Compute Project を介したかたちで、Facebook に参加を求めてきたようだ。 Frankovsky と Ahmad は、それに迎合しなかった。私が認識しているのは、Web スケールとネットワークの世界において、コモディティ・ハードウェアに対する約束がないという、不満が募っているという状況である。つまり、Open Flow は、実際のデータセンター事業者に対して、最大の柔軟性を提供するという点で、マーケットの要求を満たしていないのだ。

Frankovsky said that the ONF approached Open Compute (Facebook is a founding member of both organizations) in part because it believed it could move quickly on this. And it will. But it’s worth noting that this announcement is about an open source top-of-rack switch, not a controller and not some type of software-defined networking play.

また、ONF が Open Compute にアプローチしてきたのは(Facebook は双方の設立メンバーである)、彼らの活動を迅速に進めたいからだとも、Frankovsky は述べている。もちろん、それは可能だろう。しかし、今回のアナウンスメントが、何らかのコントローラや SDN ではなく、オープンソースの  top-of-rack switch を示していることに注目すべきだろう。

Other companies may take this box and perhaps an open source OS if one is developed, and then layer on some type of controller software to make a software-defined network, but this is just a box.

ここで説明するものが開発されるなら、おそらく他の企業は、おそらく BOX とオープンソース OS を採用した後に、SDN を構築するためのコントローラ・レイヤに取り組むだろうが、ここでの話は BOX に限られたものである。

That being said, this is a box that could seriously disrupt the existing players in networking, from giants like Cisco and Dell all the way to smaller startups like NoviFlow or even Pica8. Much like Facebook is changing the server market with Open Compute, we’ll see if it can tweak the model and do the same in networking.

そうは言っても、Cisco や Dell などの大手から、NoviFlow や Pica8 といったスタートアップにいたるまで、この BOX がもたらす破壊は、かなり深刻なものになるだろう。それは、Facebook が Open Compute を用いて、サーバー市場を変革しようとする流れと同じだ。 これまでのモデルに手を加え、ネットワークに変革をもたらすことができるのかどうか、私たちは検証していくことになるのだろう。

Related research

ーーーーー

imageOpen Compute Project の中でも、最もホットな動きです。以前から、誰もが思っていた、ネットワーク・スイッチのオープン化が始まります。すでに、無印サーバーが、かなりのシェアを占めているわけですが、こうした実績を背景に、今度はスイッチに取り組むことになります。 Arista の Andy Bechtolsheim は、Open Compute がファンデーション化されたときから、ボード・メンバーを務めているので、いつかは、こういう日がくるのだろうと感じていた人も多いかと思いますが、予想以上に早かったというのが Agile_Cat の感想です。そして、文中にもあるように、年内もしくは来年の初めには、何らかの結果が出てくるとのことです。 とても、楽しみですね。image141

ーーーーー

<関連>

Facebook の空母のような DC: 効率/温度/湿度 を Web モニタリング!
OCP データセンターと、高温多湿気候との関係について
Facebook が Iowa にもデータセンターを作る? これも デカイ!
Open Compute と Quanta : 台湾の無印サーバーが 米国マーケットを席巻する!
Intel と Facebook が実現する、100 Gbps でラックを貫く光学素材とは?

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

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

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

image

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

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

ーーーーー

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

ーーーーー

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

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

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

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

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

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

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

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

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

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

Did you have any setbacks of note?

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

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

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

● How far away is OpenFlow from being fully baked?

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

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

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

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

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

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

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

● What are the next steps?

次のステップは?

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

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

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

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

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

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

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

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

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

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

<終わり>

ーーーーー

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

ーーーーー

<関連>

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

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

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

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

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

image

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

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

ーーーーー

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

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

ーーーーー

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

● Are you actually pumping in fake traffic?

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

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

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

<続く>

ーーーーー

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

ーーーーー

<関連>

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

 

 

 

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

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

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

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

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

ーーーーー

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ーーーーー

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

ーーーーー

<関連>

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

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

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

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

_ Gigaom

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

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

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

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

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

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

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

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

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

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

VMware’s networking products.

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

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

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

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

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

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

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

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

Related research and analysis from GigaOM Pro:

ーーーーー

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

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

ーーーーー

<関連>

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

 

Google と OpenFlow と SDN について本音を語ろう – Urs Holzle

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

Google’s next OpenFlow challenge: taking SDNs to the consumer
http://wp.me/pwo1E-48b
By
Stacey Higginbotham Apr. 17, 2012
http://gigaom.com/cloud/googles-next-openflow-challenge-taking-sdns-to-the-consumer/

_ Gigaom

Google is running all of its backbone traffic on a software-defined network built using OpenFlow, and it hopes that this year it can begin the process of extending that type of programmable network to its consumer-facing network: the network that delivers applications such as Maps and YouTube to consumers and businesses. Urs Hölzle, SVP of technical infrastructure and Google Fellow, today at the Open Networking Summit detailed how Google is using OpenFlow on its network to lower costs and reduce complexity, which I wrote about last week.

Google は、すべてのバックボーン・トラフィックを、OpenFlow を用いて構築した SDN 上で走らせている。そして、今年は、この種のプログラマブル・ネットワークが、コンシューマと接するネットワークにまで、拡大していくプロセスが始まることを希望している。 つまり、そのコンシューマ対応のネットワークとは、一般消費者や企業に対して、Maps と YouTube といったアプリケーションを配信するネットワークのことである。 Google の SVP of Technical Infrastructure である Urs Holzle は、今日の Open Networking Summit で、同社における OpenFlow の用法について説明した。それは、先週に私が書いたように、ネットワークの複雑さを、より低コストで解決していくというものであった。

Urs Hölzle, SVP of technical
infrastructure at Google

But in that talk he also said that Google hopes to build an SDN that could handle the far more complex and important types of traffic that it delivers to users. That network requires much more reliability and also has to interface with far more devices and protocols, making the task of turning it into an SDN more fraught. As an example, Hölzle told me he expects the internal WAN network to achieve a 99.95 or a 99.99 percent reliability rate (it’s not quite that yet) but any user-facing service has to achieve something closer to the telecom ideal of five nines.

その話の中で、Google が望むものは、ユーザーに配信される遥かに複雑で重要なトラフィック・タイプを、SDN の構築により処理することだとも、彼は説明している。 そのネットワークは更なる安定性を必要とし、また、より多くのデバイスおよびプロトコルとインタフェースを取らなければならない。その結果として、SDN への置き換えるべきタスクが、さらに膨らんでくる。 例として Holzle が挙げたのは、インターナル WAN ネットワークが 99.95%~99.99% の安定レート(まだ、そこまでい届いていない)を達成することを、彼が期待していることだ。しかし、いかなるユーザーと接するサービスであっても、ファイブ・ナインというテレコムに理想に近い値を達成しなければならない。

Another issue associated with changing the external network to a software-defined network is the gear. In his talk, Hölzle explained the type of gear Google began building in 2010 in order to build this OpenFlow network. It was a basic switch using merchant silicon and running almost no software, just the software needed to get it up and running, and an OpenFlow agent. Everything else was handed off to a controller.

エクスターナル・ネットワークの SDN への置き換えに付随する、もう1つのテーマはネットワーク・ギアである。 彼の話によると、同社における OpenFlow ネットワークを構築するために、この種の装置を、Google は 2010年から作り始めている。 それは、ベーシックなスイッチであり、商用の半導体を用い、ソフトウェアはほとんど走らせないものとなる。 ただし、起動と実行のために必要なソフトウェアと、OpenFlow エージェントだけは例外である。そして、その他のすべてが、コントローラに受け渡された。

imageBut to take such a network to the external site, Google wants someone else to build the hardware. Hölzle says it does look like firms will build the type of gear he wants that uses OpenFlow as the management API, and he expects Google to start looking at the problem of how to move the external-facing network to an SDN this year. That doesn’t mean it will happen anytime soon–although Google did manage to transfer all of its WAN traffic to an OpenFlow network in two years–but that it will happen.

しかし、このようなネットワークを外部サイトに展開するためにも、誰かがハードウェアを作ってくれることを、Google は期待している。 彼の望むネットワーク・ギアをつくる企業は、マネージメント API として OpenFlow を使う事になると、Holzle は言う。そして、Google は年内までに、外部に接するネットワークを SDN に置き換える方式において、どのような問題が生じるのか、それに注目してきたいと付け加えている。 それは、直ぐにというものではないが、必ず実現される。なぜなら、Google は 2年の歳月をかけて、すべての WAN トラフィックの、OpenFlow ネットワークへの移行を、成し遂げているからだ。

And that’s important because the same cost savings that Google is seeing on its WAN network could end up helping lower the cost of delivering bits over consumer broadband networks, and thus help ISPs reduce their costs. Hölzle hopes that might reduce the need for ISP network protection schemes such as broadband caps, but I’m not as optimistic.

そして、こうした一連のことが重要な理由は、コンシューマ・ブロードバンド・ネットワーク上で配信するコストを、Google の WAN ネットワークが低減してきたことを、同社が確認していることであり、また、その方式が ISP のコストを低減させる点にある。さらに 、ISP ネットワークのプロテクション・スキームである、たとえばブロードバンド・キャップなどの必要性を低減することも、Holzle は望んでいるようだが、私は それほど楽天的にはなれない。

Related research and analysis from GigaOM Pro:

 

ーーーーー

TAG index先週にポストした「Google 先生の OpenFlow 講座 – DC 間接続を低コストで達成するには」の続編という感じですね。Santa Clara で開催された Open Networking Summit からは、Google による OpenFlow のコミットという話が伝わってきていますが、おそらく、この記事も前回と同様に、Holzle さんへの事前のインタビューから起こされたのでしょう。 そして、Summit の終了後なら公開できる内容を、まとめているのだと思います。Google による OpenFlow と SDN への取り組みが、どのように進んでいくのか、とても楽しみですね。 ーーー __AC Stamp 2

ーーーーー

<関連>

クリエーションラインが展開する、CloudStack/MidoNet/Cloudian 統合戦略とは?
OpenFlow 1.2 が ONF の評議会で承認された – NTT Com も委員に
Juniper がデベロッパーに対して、OpenFlow ソースコードを提供し始めた
OpenFlow を使うのは 誰? – NEC に聞く
OpenFlow と Big Data の 深い関係について

OpenFlow 1.2 が ONF の評議会で承認された – NTT Com も委員に

Posted in .Selected, Network, OpenFlow by Agile Cat on December 19, 2011

ONF: OpenFlow 1.2 Marks Big Step Forward for Software Defined Networking
Dec. 15, 2011, 8:00 a.m. EST
http://www.marketwatch.com/story/onf-openflow-12-marks-big-step-forward-for-software-defined-networking-2011-12-15

ONF approves its first major update, adding IPv6 support and increasing experimenter and protocol flexibility to facilitate cloud development

PALO ALTO, Calif., Dec 15, 2011 (BUSINESS WIRE) — The Open Networking Foundation (ONF) announced today the Board’s approval of OpenFlow Switch Specification Version 1.2 — the first update of the OpenFlow Software Defined Networking (SDN) standard since the ONF’s launch in March, 2011. The new release builds significantly on Stanford University’s Version 1.1 in a number of ways, including support for IPv6, extensible matches, and greater flexibility for ongoing experimentation. Also announced today was the appointment of NTT Communications to the ONF Board of Directors, and the ONF’s membership passing the 50 mark after just eight months.

PALO ALTO, Calif., Dec 15, 2011 (BUSINESS WIRE) — 今日(12/15)のことだが、Open Networking Foundation (ONF)の評議会が、OpenFlow Switch Specification Version 1.2 を承認したという発表があった。 この OpenFlow Software Defined Networking (SDN) スタンダードのアップデートは、March 2011 に ONF が発足して以来、初めてのことになる。 この新しいリリースは、Stanford University Version 1.1 を大幅に改善するものとなり、また、IPv6 のサポートや拡張可能なマッチングなどが組み入れられ、進行中の実験に対して多大な柔軟性を提供するものとなる。 さらに、今日のアナウンスメントには、NTT Communications が ONF Board of Directors として選任されたことも含まれていた。そして、ONF のメンバーシップは、設立から僅か 8ヶ月の間に、50 社を数えるに至った。

“ONF continues to grow globally, with Korea Telecom and Spirent Communications our latest members” says Dan Pitt, ONF’s Executive Director. “There is a shared vision of OpenFlow as the vital foundation upon which a dynamic, policy-based orchestration layer is being created — allowing processes to be defined on the fly and deployed automatically to deliver agile, scalable cloud services to a satisfy a wide range of user needs in every geography.”

「ONF は最新のメンバーとして Korea Telecom と Spirent Communications を加え、世界規模で成長し続けている。そして、ダイナミックなポリシー・ベース・オーケストレーションの上に、活力のある基盤が構築されるにつれて、OpenFlow の共有ビジョンが広がっていく。つまり、対象となるプロセスが、On The Fly/Agile で自動的に供給され、すべての国々におけるユーザーニーズ充たす、スケーラブルなクラウド・サービスを実現していくようになる 」と、 ONF の Executive Director である Dan Pitt は発言する。

imageThe OpenFlow Switch Specification 1.2 includes three significant improvements:

この OpenFlow Switch Specification 1.2 における改善点には、以下の 3つの大項目が含まれる:

– Support for IPv6. In addition to the previous support for IPv4, MPLS, and L2 headers, OpenFlow 1.2 now supports matching on IPv6 source address, destination address, protocol number, traffic class, ICMPv6 type, ICMPv6 code, IPv6 neighbor discovery header fields, and IPv6 flow labels.

– IPv6 のサポート: IPv4/MPLS/L2 ヘッダー に対する従前からのサポートに加えて、OpenFlow 1.2 は新たに、IPv6 ソース・アドレス/ディスティネーション・アドレス/プロトコル・ナンバー/トラフィック・クラス/ICMPv6 タイプ/ICMPv6 コード、IPv6 Neighbor Discovery Header Field/IPv6 フロー・ラベルとの整合性をサポートする。

– Support for extensible matches, addressing a larger number of parameters and providing far greater flexibility for current and future protocols.

– 拡張可能なマッチングのサポートおよび、より多数のパラメータへの対応、現在と将来の未来のプロトコルに対する更に優れた柔軟性の提供。

– Support for experimenter extensions through dedicated fields and code points assigned by ONF, facilitating experimentation and fine-tuning by a growing population of developers across academia and industry.

– ONF が割り当てる専用のフィールドとコード・ポイントを介して、実験者による拡張をサポート。 それにより、学界と産業界のいたるところで増大していくデベロッパー人口により、実験と促進と微調整を容易にする。

Software Defined Networking using the OpenFlow standard addresses the challenges faced by service providers, data-center operators, and enterprises in aligning the network with an increasingly dynamic and customized computing infrastructure. OpenFlow defines a communication protocol between a logically centralized control plane and the network’s data delivery plane, together with a standardized network management interface potentially allowing, for example, a data-center network to be made as flexible and responsive as the virtual servers that it supports.

OpenFlow スタンダードを用いる Software Defined Networking は、動的なカスタマイズに対応するコンピューティング・インフラストラクチャとネットワークを提携させることで、サービス・プロバイダ/データセンター運用者/エンタープライズが直面する課題に取り組んでいく。また、OpenFlow は、論理的にセンタライズされた制御プレーンと、ネットワークのデータ供給プレーンの間の、コミュニケーション・プロトコルを定義し、標準化されたネットワーク・マネージメント・インターフェイスの潜在能力と組み合わせていく。それにより、たとえば、仮想サーバーがサポートする柔軟性および応答性と同じレベルで、データセンター・ネットワークの仮想化を実現していく。

The new Director representing NTT Communications is Yukio Ito, Senior Vice President, Services and Infrastructure, NTT Communications Corporation. His deputy is Dr. Kenji Takahashi, President and CEO, NTT Multimedia Communications Laboratories, Inc., a wholly owned subsidiary of NTT Communications. Mr. Ito commented: “NTT strongly supports the ONF’s goals and has deeply engaged technical experts actively contributing to ONF working groups, underlining NTT’s strong commitment to developing and deploying the OpenFlow standard.”

NTT Communications を代表する新しい Director とは、 NTT Communications Corporation で Senior Vice President Services and Infrastructure を務める Yukio Ito である。 彼を補佐するのは、NTT Communications Corporation の 100% 子会社である、 NTT Multimedia Communications Laboratories の President and CEO を務める Dr. Kenji Takahashi  である。Mr. Ito は、「 NTT は ONF の目的を強力にサポートし、また、ONF の WG に貢献するテクニカル・エキパートを専任させる。 それにより、OpenFlow スタンダードの開発/展開について、NTT が強くコミットしていくことを明確にする」 と、コメントしている。

With other working and discussion groups actively engaged on a number of related enhancements, further significant updates to the OpenFlow specification are anticipated throughout 2012.

その他のワーキング・グループやディスカッション・グループのアクティビティは、関連する数多くの拡張に対して割り振られていく。そして更に、OpenFlow 仕様に対する大幅なアップデートが、2012 年を通じて展開されるはずである。

imageAbout the Open Network Foundation (ONF)

Founded in 2011 by Deutsche Telekom, Facebook, Google, Microsoft, Verizon, and Yahoo!, the Open Networking Foundation (ONF) is a nonprofit organization with over 50 members whose goal is to rethink networking and quickly and collaboratively bring to market standards and solutions. ONF will accelerate the delivery and use of Software-Defined Networking (SDN) standards and foster a vibrant market of products, services, applications, customers, and users. For further details visit their website at: http://www.opennetworking.org

SOURCE: Open Network Foundation

ーーーーー

TAG index先ほど、ONF のドキュメント紹介ページを調べてみましたが、Version 1.2 仕様書は見当たりませんでした。 読まなければと思いつつ、棚上げしていた OpenFlow の仕様書ですが、おそらく近いうちに新バージョンが提供されると思います。 来年こそは、この Version 1.2 を、絶対に読もうと思っています。 ーーー __AC Stamp 2

ーーーーー

<関連>

OpenFlow のゴールとは?
OpenFlow のスイッチとは?
OpenFlow 専門家になるための近道とは?
OpenFlow により、ネットワーク業界は HOT になるのか?

 

Juniper がデベロッパーに対して、OpenFlow ソースコードを提供し始めた

Posted in .Selected, Network, OpenFlow by Agile Cat on November 16, 2011

Juniper Offers OpenFlow Source Code To Developers
Posted by Steve Wexler –
October 27, 2011
http://www.networkcomputing.com/next-gen-network-tech-center/231901753

image

Juniper Networks is jumping on the OpenFlow bandwagon, putting the OpenFlow source code in the Junos software development kit (SDK). The company says that the OpenFlow application works within the SDK to change the control plane to create more dynamic network programmability for custom applications that run on top of the Junos operating system. “The new levels of programmability enabled by OpenFlow simplify control of network devices and allow more rapid innovation of intelligent applications and solutions across the entire network infrastructure.”

Juniper Networks は、自社の Junos SDK に OpenFlow 対応のソースコードを取り入れ、その時流に乗ろうとしている。同社の説明によると、その SDK で開発される OpenFlow アプリケーションは、Junos OS 上で動作するカスタム・アプリケーションに対応する、ネットワークを介したダイナミックなプログラミングを実現するために、そのコントロール・パネルを変更できることになる。 「OpenFlow が実現する、プログたミングに対応した新しいレベルは、ネットワーク・デバイスの制御を単純化し、また、ネットワーク・インフラ全体を横断するインテリジェントなアプリケーションとソリューションを、急速に進化させていく」

A founding member of the Open Networking Foundation, Juniper has more than 500 organizations in the SDK developer community. The company says its priority is making the networking infrastructure more efficient and effective for customers, and OpenFlow is an important step on the path to greater programmability.

Juniper は Open Networking Foundation の設立メンバーであり、また、自社の SDK デベロッパー・コミュニティには 500以上の組織を抱えている。そして、顧客のための効率と効果を考えた、ネットワーキング・インフラを最優先の課題とし、そのプログラマビリティを高める重要なステップとして OpenFlow を捉えていると、同社は発言している。

imageJuniper believes that the next frontier in networking will be bridging the gap between the application and network worlds. Today, the two exist as silos, often separated by organizational boundaries, separate priorities and even different budgets. The company says that network programmability–the idea that information can be shared bi-directionally between the application and the network–will be key to unlocking the power of each and, to that end, OpenFlow is a critical component.

Juniper は、アプリケーションの世界とネットワークの世界を隔てる、ギャップをブリッジするものが、次世代ネットワークのフロンティアになると確信している。 今日の時点において、組織のカベにより切り離され、異なる優先順位をもち、さらには予算も別口という、2つのサイロが存在するというのが、一般的な状況である。 同社の言うネットワーク・プログラマビリティとは、アプリケーションとネットワークの間で、双方向で情報が共有される概念である。 つまり、双方のパワーを解き放すことを目指しているが、そのために不可欠なコンポーネントとして、OpenFlow が存在することになる。

At minimum, the company expects its developers to use the OpenFlow application as an example. In this capacity it is a great learning tool. Beyond that, Juniper says, this OpenFlow application is a working OpenFlow client. It has demonstrated several use cases and expects that there are countless others. Using the application as-is to explore use cases will help highlight where the OpenFlow standard is sufficient and where it needs work.

少なくとも同社は、デベロッパーたちが OpenFlow アプリケーションをサンプルとして利用することを期待している。 その範囲において、OpenFlow は価値のあるツールとなる。 また、それを超えたところでは、OpenFlow アプリケーションは OpenFlow クライアントを動かすと、Juniper は発言する。 そこでは、いくつかのユース・ケースが実証されているが、ユース・ケースの範囲は無限の広がりと見せると期待されている。 ユースケースを探究するために、現状のままのアプリケーションを使用することは、OpenFlow 標準で事足りる領域と、それが必要とされる領域を浮き彫りにするだろう。

Additionally, the company says, there are customers and partners who have very strong developer roots. For these customers, the source code for the OpenFlow application is really a starting point. Take it, extend it, bend it, shape it, says Juniper.

さらに同社は、きわめて強力なデベロッパーをルーツに持つ、顧客とパートナーを擁していると発言している。それらの顧客にとって、こうした OpenFlow アプリケーションのソースコードが、本当の意味での出発点になる。 それを手にした後に、拡張し、加工し、形作っていくはずだと、Juniper は言う。

The announcement of OpenFlow has some people in networking optimistic that we are about to see a significant change in innovation and progress on network management, writes Network Computing contributor Greg Ferro. OpenFlow is a nascent networking specification that has three key elements: a software controller, the OpenFlow protocol and a client on the network device. It’s important to understand that all three elements combine to create a single coherent solution.

OpenFlow の発表は、ネットワーク・マネージメントの革新と進歩に、大きな変化が訪れることを確認しようとする、ネットワーク楽観主義者を想定していると、Network Computing コントリビュータである Greg Ferro は記している。 OpenFlow は発生期のネットワーキング仕様であり、ソフトウェア・コントローラーおよび、OpenFlow プロトコル、ネットワーク・デバイスの上のクライアントという、3つの主軸を有している。 この 3つの要素を組み合わせることで、一貫性のあるソリューションが実現されることを、理解する必要がある。

imageAccording to a prepared statement provided by Juniper from Glen Hunt, principal analyst at Current Analysis, the implementation of OpenFlow enables a consistent management policy across a large number of devices, which can reduce processing requirements and simplify management while delivering the expected application performance: “Juniper is helping to drive this level of programmability, which will be required to support the steep ramp in network-aware application development.” He says by making OpenFlow available in its SDK, Juniper is in a leadership position to help the development community and service providers leverage network assets and intelligence to help deliver differentiated services.

Juniper が用意した、Current Analysis の主席アナリストである Glen Hunt のステートメントによると、OpenFlow の実装は、多種多様なデバイスをまたいだ、一貫したマネージメント・ポリシーを実現する。それにより、期待されるアプリケーション性能を提供しながら、処理要件を減らし、マネージメントを単純化していく。「 Juniper は、ネットワーク対応アプリケーションの開発という、厳しいステップをサポートしていくための、プログラマビリティのレベルを促進しようとしている」と、彼は語っている。 つまり Juniper は、SDK の中で OpenFlow を提供することで、開発コミュニティとサービス・プロバイダたちにリーダーシップを発揮し、また、多様なサービスを提供するためのネットワークの資産と知財の活用を促進していくことになる。

Last week, a Cisco fellow said that software-defined networking, an emerging technology that moves intelligence out of switches and routers to a software controller and which is evolving in concert with the development of the OpenFlow networking standard, is seen as a potential threat to networking vendors, particularly market leader Cisco Systems. According to sister publication InformationWeek, OpenFlow-based networking would enable enterprises to replace high-end switches with lower-cost, commodity switches, which could be 70% cheaper than high-end switches such as Cisco’s.

先週のことだが、ある Cisco フェローが、インテリジェンスをスイッチやルーターへと移行させる、Software Defined Networking(SDN)にという先端テクノロジーについて語っている。それは、OpenFlow の開発とも関係するネットワーク標準のことであり、ネットワーク機器ベンダーにとって、とりわけ Cisco Systems にとて、潜在的な脅威になると思われる。 姉妹誌である InformationWeek によると、 OpenFlow ベースのネットワークは、エンタープライズにおけるハイエンド・スイッチを普及品のスイッチに置き換え、Cisco のハイエンド製品と比較して、70% のコスト・ダウンを実現するという。

In August, HP revealed work it is doing on OpenFlow networking at HP Labs. Like Juniper, a member of the Open Network Foundation, HP says networks should be easier to manage, saying part of the reason it is this hard is that there hasn’t been enough competition to push the providers to provide better solutions.

8月には、HP Labs で OpenFlow ネットワークでの作業が進んでいるという、同社からの発表があった。 Juniper と同様に、Open Network Foundation のメンバーである HP は、ネットワークのプロバイダたちが、適切なソリューションを実現していくうえで、充分な競争力を維持できなくなった理由について言及している。 裏返せば、ネットワークの管理は、もっと容易なものなる必要性を有している。

See more on this topic by subscribing to Network Computing Pro Reports Strategy: Inside OpenFlow (subscription required).

ーーーーー

openflow

OpenFlow: Enabling Innovation in Campus Networks には ・・・

「一般的に、商用のスイッチとルーターは、そのハードウェアやソフトウェアを仮想化する手段の提供は言うまでもなく、オープンなソフトウェア・プラットフォームを提供していない。また、商用ネットワークのプラクティスでは、外部インターフェイスの標準化は狭い範囲に留まり(すなわち、単なるパケット)、スイッチ内部のフレキシビリティについては、その全てが隠されれている。その内部は、ベンダーごとに異なるため、研究者が新しいアイデアを実験するための、標準的プラットフォームにならない。さらに、ネットワーク装置のベンダーたちは、ボックス内のインターフェイスを開示することについて、必要以上にナーバスになっている。つまり、彼らは何年にもわたり、壊れやすい分散プロトコルとアルゴリズムを、実装し調整してきたわけである。そして、新しい実験により、ネットワークがクラッシュし、ダウンすることを恐れる。そして、もちろん、オープン・プラットフォームにより、新しいベンダーにとっての参入障壁が引き下げられる。

・・・ と記載されています。このドキュメントが作成されたのは 2008 年 4月ですので、そこから 3年半が経過しているわけですが、ついに大きな変化が訪れたわけです。オープン化の大きなうねりは、まだまだ勢いを増していくのでしょうね。 ーーー __AC Stamp 2

ーーーーー

<関連>

Broadcom は NetLogic を買収し、リアルタイム・クラウドを目指す
OpenFlow を使うのは 誰? – NEC に聞く
OpenFlow と Big Data の 深い関係について
スタンフォード大学の Open Networking Summit と OpenFlow
OpenFlow により、ネットワーク業界は HOT になるのか?

%d bloggers like this: