Agile Cat — in the cloud

Snapchat の CTO が、Google Cloud Platform Live に登壇するということは?

Posted in Events, Google, SnapChat, Social, Web Scale by Agile Cat on March 15, 2014

Snapchat CTO and co-founder Bobby Murphy to appear at Google Cloud Platform Live on March 25
http://wp.me/pwo1E-7jG

Posted: Tuesday, March 4, 2014
http://googlecloudplatform.blogspot.jp/2014/03/snapchat-cto-and-co-founder-bobby.html

Bobby Murphy, CTO and co-founder of Snapchat, will be joining Google Senior Vice President Urs Hölzle on stage during the keynote of Google Cloud Platform Live. Bobby will be sharing his experience building one of the world’s most popular apps on Google Cloud Platform.

Snapchat の CTO and  Co-Founder である Bobby Murphy だが、Google Cloud Platform Live でキーノートを務める Senior VP Urs Hölzle のステージに登壇するようだ。 そして、Bobby は、この世界で大人気のアプリを Google Cloud Platform で、構築したときのエクスペリエンスを共有することになる。

Snapchat’s users share over 400 million snaps everyday.

なんせ、Snapchat のユーザーたちは、400 million 以上のスナップを、毎日のように飛ばし合っているのだ。

Google Cloud Platform Live is taking place 3 weeks from today. Bobby will be joining a great line up of other speakers, including Google Senior Fellow Jeff Dean. We’ll announce new features, take a deep dive on tips, tricks and technology, and share our vision for the future of cloud computing.

Google Cloud Platform Live は、3週間後に開催される。そして Bobby は、Google の Senior Fellow である Jeff Dean といった、素晴らしいスピーカーたちによるラインナップに参加する。私たちは、そこで提供される新しい機能や、ティップス、テクノロジーを追いかけ、また、このクラウド・コンピューティングにおける未来のビジョンを共有していく。

We are nearly at capacity in all our locations, but for people who are still interested in attending you can request an invitation to join us in-person in San Francisco or attend a livestream of the keynote at Google New York City, Google Seattle or Google London. And for those who can’t make it in person, you can always tune in online.

すべてのロケーションにおいて、私たちのキャパシティは満杯に近いが、参加したいのなら San Francisco にリクエストして欲しい。 また、 Google New York City および、Google SeattleGoogle London でも、ライブ・ストリームが提供される。それも無理な人は、オンラインで参加することも可能だ。

ーーーーー

imageSnapchat が Google Cloud Platform というのは意外ですが、ウルトラ・ハイパー・スケールを狙っている同社が、このようなスター・プレイヤーを誘致したとしても、それは、それで、ナルホドと思える話です。 Nameservers を調べてみたら GoDaddy なのですが、システムの本体は Google にあるということなのでしょうか? ついでに、Whatsapp も調べたら、Nameservers は SoftLayer になっていました。 なんか、ワクワクする展開ですね。ac-stamp-232

ーーーーー

<関連>

Google Compute Engine 対 Amazon EC2 : 性能をチャートで比較する
GCE が正式にリリースされた : どのようにして、AWS と戦っていくのか?
Google Compute Engine は、どこで Amazon AWS を上回るのか?
GCE の登場で、どのような影響が IssS 業界に?
Google Compute Engine の立ち位置を、RightScale が分析する _1
Google Compute Engine の立ち位置を、RightScale が分析する _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 の 深い関係について

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
http://wp.me/pwo1E-46j
By
Stacey Higginbotham Apr. 9, 2012
http://gigaom.com/cloud/how-google-is-using-openflow-to-lower-its-network-costs/

_ 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: