Agile Cat — in the cloud

NIST Cloud Computing Standards Roadmap ってなに? その_4

Posted in NIST by Agile Cat on April 25, 2012

第4章は、クラウドのユースケースの話です ・・・
http://wp.me/pwo1E-495
NIST Cloud Computing Standards Roadmap Spec. Publ. 500-291
http://www.nist.gov/itl/cloud/publications.cfm

NIST

4 Cloud Computing Use Cases

Cloud computing use cases describe the consumer requirements in using cloud computing service offerings. Analyzing business and technical cloud computing use cases and the applicable standards provides an intuitive, utility-centric perspective in surveying existing standardization efforts and identifying gaps. This clause leverages the business and technical use case outputs from other NIST Cloud Computing Program Working Groups and presents an analysis on how existing cloud-related standards fit the needs of USG cloud consumers and where the gaps for standardizations are.

クラウドコン・ピューティングのユースケースとは、クラウド・コンピューティングのサービスを使用する際の、顧客の要件を記述するものとなる。 クラウド・コンピューティングのユースケースを、ビジネス面とテクニカル面から、また、適用可能なスタンダードの視点から分析していく。また、これまでの正規化における努力を測り、現実とのギャップを識別することで、直観的で実用性を重視した観点を提供していく。 この項では、NIST における Cloud Computing Program Working Groups から提供される、ビジネスとテクニカルに関するユースケースのアウトプットを活用する。そして、クラウドに関連する既存のスタンダードが、USG クラウド消費者のニーズに適していると思われる領域と、標準化における現実とのギャップの位置について分析していく。

4.1 Business Use Cases

The Target Business Use Case Working Group has produced a template for documenting specific use cases. This template includes a section titled “Concept of Operations” in which “Current System” and “Desired Cloud Implementation” states are described. The template also gathers information about integration with other systems, security requirements, and both local and remote network access considerations. A set of business use cases is being drafted describing candidate USG agency cloud deployments. The stories captured in these business use cases help to identify business drivers behind the adoption of cloud computing in USG agencies, provide background information on the relevant usage context, and expose general agency consumer concerns and issues through specific scenarios. These use cases thus help us to document key technical requirements for USG cloud-related standards in the areas of security, interoperability and portability as required for the formulation of this roadmap.

Target Business Use Case Working Group は、特定のユースケースをドキュメント化する際に有用な、テンプレートを作成している。 このテンプレートには、「Concept of Operations」というセクションが含まれ、「Current System」と「Desired Cloud Implementation」のステートが記述されている。 さらに、このテンプレートには、他システムとの統合や、セキュリティ要件、ローカル/リモート・ネットワーク・アクセスについて、検討すべきポイントが集められている。 ビジネス・ユース・ケースのセットは、USG 政府機関用のクラウド・ディプロイメントを記述するドラフトの段階にある。 これらのビジネス・ユース・ケースで取り込まれたストーリーは、USG 政府機関におけるクラウド・コンピューティングの適用において、その背後からビジネスを推し進める役割を識別していく。そして、適切な用法コンテキストの背景となる情報を提供し、また、 特定のシナリオを介して通して、政府機関が検討すべき関心事と問題を明らかにする。 したがって、これらのユース・ケースは、ロードマップを形成するために必要な、セキュリティ/インターオペラビリティ/ポータビリティの領域で、USG のクラウド関連スタンダードにおける、主要テクニカル要件の文書化を促進することになる。

The “Cloud First” business use case called out by the Federal CIO is a more general expansion of this analysis to multiple interacting current systems and cloud implementations. This expansion is to support evolving business processes as cloud deployments are implemented. It requires interoperability and portability across multiple cloud deployments and enterprise systems.

Federal CIO から要請された「Cloud First」ビジネスユース・ケースは、既存システムとクラウド実装におけるマルチ・インタラクションを分析するために、さらに拡張されている。 クラウド・ディプロイメントが実装されるにつれて、進化していくビジネス・プロセスを、この拡張によりサポートしていく。 そして、さらに、マルチ・クラウド・ディプロイメントとエンタープライズ・システムの全体を横断する、インターオペラビリティとポータビリティを要求していく。

ーーーーー

TAG indexこの 4章は、上記の「4.1 Business Use Cases」に加え、以下の「4.2 Technical Use Cases」と「4.3 Deployment Scenario Perspective」という項目により構成されています。 このドキュメント全体を通してみると、この辺りから興味深い内容になっていきます。ーーー ac-stamp-232

4.2 Technical Use Cases

SAJACC Working Group は、SAJACC のプロセスを通して、最初のパスとなるプロジェクトのために、準備段階としてのユース・ケースのセットを作成した。 NIST は、一連のオープン・ワークショップを通して、また、パブリック・コメントとフィードバックを通して、これらのユース・ケースを洗練させ、新しいユース・ケースを加え続けるだろう。

4.3 Deployment Scenario Perspective

この「“Cloud First」ビジネスユース・ケースは、USG 政府機関クラウド消費者と、クラウド・プロバイダを結ぶ、さらに詳細なインタラクションを要求する。 このインタラクションのシナリオには、3 つのメイン・グループがある:

ーーーーー

<関連>

NIST Cloud Computing Standards Roadmap ってなに? その_3
NIST Cloud Computing Standards Roadmap ってなに? その_2
NIST Cloud Computing Standards Roadmap ってなに? その_1
NIST がクラウドのための Roadmap と Architecture を発表

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本強)

 

%d bloggers like this: