SDN « Agile Cat — in the cloud

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

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

VMware: ‘The software-defined data center is coming’
http://wp.me/pwo1E-4dU
By Derrick Harris May. 9, 2012
http://gigaom.com/cloud/vmware-the-software-defined-data-center-is-coming/

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 」が、次世代アプリケーションのためのインフラを再定義していくだろう。

Herrod, 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 platforms to 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:

ーーーーー

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

ーーーーー

Tagged with: Facebook, Google, SDN, Software Defined Networks, Steve Herrod, VMware, Zynga

1 comment

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

Posted in 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/

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 ニュースとなる。なぜなら、それらの企業はマージンが下がり、利益が圧迫されるからだ。

Allwyn 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 非対応も含む）を制御するために結合されたプロトコルのコントローラ、そして、③ コントローラを介してネットワークを操作するアプリケーションという、３つの要素が必要になると彼は言う。

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:

ーーーーー

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

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

ーーーーー

Tagged with: Allwyn Sequeira, Berkeley, Cisco, Google, Juniper, ONF, ONRC, Open Networking Forum, Open Networking Research Center, OpenFlow, SDN, Software Defined Networking, Stanford, Urs Holzle, VMware, VXLAN

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

Posted in 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/

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 におけるコストは、ネットワークの帯域幅という観点でけでは測定できない。つまり、ユーザーが必要とする運用や設定という視点も、欠かせない要因となる。

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

ーーーーー

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

ーーーーー

Tagged with: Google, Open Networking Summit, OpenFlow, SDN, Software Defined Networking, Software Defined Networks, Urs Holzle

1 comment

クリエーションラインが展開する、CloudStack／MidoNet／Cloudian 統合戦略とは？

Posted in Cloud Businesses, Cloud Stack, OpenFlow, SDN by Agile Cat on January 30, 2012

日本発クラウド･スタートアップの、クリエーションライン、ミドクラ、ジェミナイの三社提携
http://wp.me/pwo1E-3RM

Agile_Cat_Loupe

昨年末のことですが、クリエーションライン、ミドクラ、ジェミナイの三社提携が発表されました。その後、クリエーションラインの安田さんと会い、この件の概要を教えてもらうという機会を得ました。

この三社の守備範囲は、それぞれ、クリエーションラインが CMS（Cloud Management Systems）で、ミドクラが SDN（Software Defined Networking ）、そしてジェミナイが Storage という分担です。そして、この提携のコアは CloudStack であり、また、クリエーションラインがハブになることで、この３つの要素をつなげていくというものです。

つまり、シングル･ポイント･ビューを実現する CMS の管理画面から、クラウド･フレームワークと、ネットワークと、ストレージを透過的に管理できるようになるわけです。 CloudStack については、他にも情報がありますので、ここでは説明を割愛しますが、なぜ、SDN とストレージがキー･コンポーネントになるのかという点について、クリエーションラインが考えていることを、簡単にまとめていきます。

まず、SDN ですが、最近のクラウドのトレンドとして、データセンター内の管理を容易にするというニーズが高まっているとのことです。つまり、膨大な数のサーバーを確実に管理するには、物理的な結線を一度行ったら、その後はソフトウェアを介して管理する方が、その運用が容易になるという発想です。ここで管理する要素としては、NAT や、ファイヤーウォール、ロードバランシングといったものを含む、ネットワーク全体が対象になります。

クラウド･シフトの理由の 1つとして、性能／信頼性／コストという条件に応じて、適切なプロバイダーをいつでも選び直せるという点があります。しかし、こうしたデータセンター内のネットワーク管理が、従来からの物理的な結線や各アプライアンスといった、個別の設定変更に依存しているのでは、その効果も半減してしまいます。それは、クラウドを拡張する際にも言えることであり、単にコストに留まらず、安全な運用をという視点からも考えるべき、重要な問題となります。

SDN の役割としては、前述のとおりデータセンター内の運用というレベルがありますが、クラウドが進化していくにつれて、マルチ･データセンター間での連携というステージが浮上してきます。そのときに、どのレベルのネットワーク･レイヤーが要求されるのでしょう？少なくとも、L３以上が必要になるわけですが、L4 ～ L7 も考慮すべきなのかも知れません。ミドクラの MidoNet は、L3 はもちろんのこと、それより上位のレイヤーも視野に入れています。つまり、将来のネットワーク･アーキテクチャを、長期的なスパンでカバーできる点に、クリエーションラインは魅力を感じているようです。

その一方で、SDN と比べると、ストレージは成熟した市場です。そして、エクスペリエンスが広く共有され、１つの指標となっているのが Amazon S3 の存在です。そのような背景から、数多くのストレージ･ベンダーが、Amazon S3 用に開発されたソフトウェア資産をターゲットに、新しいプロダクトやサービスを展開しているという、ワールドワイドなトレンドがあります。その流れに乗り、SDN のミドクラと同様に、世界のマーケットへ向けて、日本発のテクノロジーを展開しているのがジェミナイです。（Agile_Cat は以前、ジェミナイって海外ベンダーだと勘違いしていました）

ジェミナイの提供する Cloudian は Cassandra ベースのストレージであり、S3 互換の API を備えているため、ユーザーはもちろんのこと、ツール類を提供するサードパーティへも訴求していけます。そして、すでに Nifty などへの導入実績があることも魅力とのことです。Cassandra は、Rackspace からスピンアウトした DataStax（元 riptano）が商用化を目指していた、Apache の NoSQL プロジェクトです。 NoSQL の宿命ともいえる、コンシステンシーとパフォーマンスという相反する要素を、ニーズに合わせてカスタマイズできるプロダクトだと認識していますが、どのようにジェミナイが処理しているのか、とても興味があります。

クリエーションラインとしては、ClousStack／MidoNet／Cloudian を統合する環境を提供していくことになります。つまり、それらのサービスが提供する各種 API に精通し、また、ノウハウを蓄積している点が、同社のエクスペリエンスであり、またセールスポイントだということです。この領域は、ユーザーが個別にソリューションを考えるより、たとえばクリエーションラインの CRM のような、汎用化された統合テクノロジーを利用する方が効率化を図れます。そして、クリエーションラインは、CloudStack だけに特化したソリューションを提供するのではなく、OpenStack などを含むオープンクラウド全般に取り組んでいくとのことです。そのときにも、MidoNet と Cloudian の API を介して、SDN とストレージを効果的に利用していくソリューションが提供されるはずです。

今後、クリエーションラインでは実証実験などを行なっていくとのことです。そして、時期が来たら、その結果を公表するとのことです。目指すはワールドワイド･マーケットですが、この三社は日本発のクラウド･スタートアップであり、日本のビジネス･スタイルに最適化したサービスの提供も考えています。これまで、世界の市場と向き合ってきたのは、主として大手のベンダーであり、国内で確立したビジネスをベースに、新たに海外を狙っていくというスタンスでした。ところが、この三社は、それぞれの設立時から、ビジネスを国内に限定することなく、テクノロジーを磨き上げてきた会社です。海外のスタートアップを見れば、それが当たり前なのですが、ようやく日本でも、そのような兆しが見えてきたことを嬉しく思います。

ーーーーー