Agile Cat — in the cloud

Gartner Quadrant : x86 仮想サーバー編 2013

Posted in Cloud Stack, Joyent, Microsoft, Oracle, Research, Virtualization, VMware by Agile Cat on July 8, 2013

Gartner releases its 2013 Magic Quadrant for x86 Server Virtualization Infrastructure
http://wp.me/pwo1E-6ly

Posted by Kenneth van Surksum   | July 2nd, 2013
http://virtualization.info/en/news/2013/07/gartner-releases-its-2013-magic-quadrant-for-x86-server-virtualization-infrastructure.html

image

Gartner has released its annual Magic Quadrant for x86 Server Virtualization Infrastructure, positioning VMware and Microsoft in the leaders Quadrant. Leaders in this market have a clear strategy and road map for their offerings, understand virtualization’s role in infrastructure and operations transformation, and have a clear vision with respect to cloud computing.

Gartner がリリースした、今年の Magic Quadrant for x86 Server Virtualization Infrastructure では、 VMware と Microsoft が、この Quadrant の Reader として位置づけられている。 このマーケットにおける Leader は、自社プロダクトに対して明確な戦略とロードマップを有し、インフラとオペレーションを変革させる仮想化の役割を理解し、さらには、クラウド・コンピューティングに対して明確なビジョンを持つものとなる。

It’s interesting to notice that Citrix has left the leaders Quadrant (where it was in 2012) and can now be found in the visionairies Quadrant. Visionaries in the x86 server virtualization infrastructure market have a differentiated approach or product, but they aren’t meeting their potential from an execution standpoint. It will be interesting to see, if Citrix is able to become a leader again after its recent decision to hand over the development of the Xen Hypervisor to the Linux Foundation. For now, the just released XenServer 6.2, contains new features, but also has lost support of a lot retired and deprecated features as mentioned in the Release notes. For more information also read the post on XenServer 6.2 by Andreas Groth, who also publishes the Virtualization Matrix.

興味深いのは、この Quadrant における Citrix のポジションが、Leader から Visionairies へと後退していることだ(2012年は Leader)。 x86 Server 仮想インフラストラクチャ市場の Visionaries は、差別化が可能なアプローチやプロダクトを持っているが、実行力という観点からすると、そのポテンシャルを満たしていないものとなる。Xen Hypervisor の開発を Linux Foundation に譲り渡すという、Citrix における最近の判断が実施された後に、再び同社が Leader に返り咲くなら、とても興味深い展開となるだろう。いまは、XenServer 6.2 がリリースされたばかりであるが、新機能が含まれるだけではないのだ。 つまり、Rerlease Note に記載されるように、廃止された機能に対するサポートの喪失が問題となっている。詳細については、Virtualization Matrix を発行している Andreas Groth の XenServer 6.2 に関するポストを参照して欲しい。

Oracle stays in the challengers Quadrant. Challengers in this market have a strong ability to execute but a more focused marketing or product vision.And both Parallels and Red Hat stay in the nice player Quadrant. Niche Players have either not capitalized on their opportunity yet or are focused on specific niches where they can be successful versus competitors that have a more general approach.

この Quadrant において、Oracle は Challengers の位置に留まっている。このマーケットにおける Challengers は、その目的を遂行するためのパワフルな能力を有するが、マーケティングとプロダクトにおけるビジョンに対してフォーカスするものとなる。Parallels と Red Hat は、Niche Player のポジションに留まっている。Niche Player の定義は、そのチャンスを具体的なビジネスに転化できていないもの、もしくは、グローバルなアプローチをつ競合他社との比較において、特定されたニッチな市場で、成功することに焦点を当てているものとなる。

ーーーーー

imageこの Gartner の Magic Quadrant ですが、いつ頃からあるのでしょうかね? もう、すっかりお馴染みになってきましたが、今回のように、Leaders/Visionaries/Challengers/Niche Player の定義を完結にまとめてくれる記事は初めてだったので、とても助かりますというのが本音です。 それにしても、この仮想化の分野になると VMware の強さが目立ちます。Microsoft については、何の言及もありませんでしたが、Citrix と Oracle へのコメント見ると、ナルホドと思えてきますね。image

ーーーーー

<関連>

VMware による仮想化の実績を、インフォグラフで視覚化する
Gartner の IaaS マーケット論評 : その 15 社とは?
アメリカの 最強 IaaS プロバイダー Top-10 をリストアップ!
PaaS をリードする : Top-10 プロバイダー とは?
IaaS はコスト削減ではなく、アジリティの増大に寄与する – Gartner

 

ネットワークの仮想化へ向けた論証 – Ben Cherian

Posted in .Selected, Network, OpenFlow, SDN, Virtualization by Agile Cat on March 7, 2013

Making a Case for Network Virtualization
http://wp.me/pwo1E-5J2

Ben Cherian, Chief Strategy Officer, Midokura – January 24, 2013
http://allthingsd.com/20130124/making-a-case-for-network-virtualization/

_ all things D

At the beginning of this century, server virtualization burst onto the IT scene and changed the way modern IT organizations think about server hardware. The basic concept behind server virtualization is that multiple “virtual” servers can be run on a single physical server. This consolidation of servers resulted in much higher utilization of physical servers, which dramatically reduced the capital expenditure (capex) costs required to provide IT services. Using fewer physical servers also lowered power, cooling and datacenter space requirements. Other indirect benefits were increased agility, since the IT department could provision a server in minutes or hours versus the weeks and months it used to take to procure, set up and turn on new physical servers.

今世紀の初めに忽然として登場したサーバーの仮想化が、ハードウェア・サーバーを検討している近代的な IT 組織の、考え方を変えてしまった。 サーバーの仮想化を背後から支える基本概念は、単一の物理サーバー上で多数の仮想サーバーを走らせらるというものである。 このサーバー・コンソリデーションは、物理サーバーの有用性を大幅に高め、IT サービスの提供に必要とされる CAPEX(capital expenditure)を劇的に削減することになった。 さらに、使用する物理サーバーの数を減らすことで、使用電力および、冷却のコスト、そして、必要とされるデータセンター・スペースも引き下げられた。 その他の間接的なメリットしては、IT 部門が数分あるいは数時間で、サーバーをプロビジョニングできるようになるという、アジリティが挙げられる。それに対して、仮想化が始まる前は、新しい物理サーバーを入手し、設定し、電源を入れるまでに、数週間から数ヶ月が必要だったはずだ。

Image copyright Johannes Kornelius

By all accounts, server virtualization adoption has been extremely successful. One look at VMware’s revenue numbers and there’s no doubting this fact. In the early 2000s, the predominant question that many in IT asked was, “Why should I virtualize?” Today, the predominant question you’ll hear is, “Why can’t the servers be virtualized?”

誰に訊いても、サーバーの仮想化に関する適用は、素晴らしい成功を収めてきた。 VMware の収益を一目見れば、この事実を疑わなる。 2000年代の初期には、IT に従事する多くの人々が、「なぜ 仮想化すべきか?」という質問を繰り返していた。 そして、いま、人々が繰り返す質問は、「なぜ サーバーを仮想化できないのか?」である。

The rise of self-service IT

We’re going through a similar paradigm shift today with self-service IT. Internal business units want the breadth of services and speed of provisioning that they can get outside of the firewall through cloud service providers like Amazon Web Services. In response, forward-thinking IT departments have been changing their traditional role into one that looks more like a service provider and have begun offering a full menu of solutions to their constituents. One of the staples on the menu is a private Infrastructure-as-a-Sevice (IaaS) cloud offering. A few concrete business drivers underlying this offering are:

いま、私たちは、セルフ・サービスの IT を用いて、そのときと同様のパラダイム・シフトを体験している。 社内のビジネス・ユニットが望むものは、幅広いサービスの選択肢と、プロビジョニングのスピードであるが、たとえば Amazon Web Services などのクラウド・サービス・プロバイダを介して、それらをファイヤー・ウォールの外側で得ることができる。 それに応えるかたちで、前向きな IT部門は、サービス・プロバイダーのような業者に、従来からのロールを移行している。 そして、彼らが構成する要素の中で、フルメニューのソリューションを提供し始めている。 そのメニューに欠かせないものとして、プライベート IaaS クラウドの提供がある。 この提供物の基礎となり、また、具体的にビジネスを推進していくものは、以下のとおりである:

  • Fine-grained control over the infrastructure which lowers risk and increases ability to deal with compliance concerns
  • A lower cost when compared to external services like Amazon
  • Lowered operational expenditures with regard to provisioning resources
  • A much faster provisioning speed than internal IT typically offers
  • Better disaster recovery options
  • Increased application availability
  • コンプライアンにおける関心事を取り扱うための、インフラストラクチャの制御。それを微調整することで、リスクを低減し、能力を増大していく
  • Amazon のような外部のサービスに対抗し得る、低コストの実現
  • リソースのプロビジョニングに関連する、運用コストの低減
  • 一般的な社内 IT よりも迅速な、プロビジョニングのスピード
  • 災害からのリカバリーに関する、より優れた選択肢
  • アプリケーションの可用性を向上させる

Elements of an IaaS cloud

There are four elements needed to build an IaaS cloud: a cloud management system, compute (also known as the hypervisor), storage and networking. The cloud management system handles all the provisioning and orchestration of the underlying compute, storage and network components. Examples of such systems are OpenStack, Citrix CloudStack, Eucalyptus and VMware’s Vsphere product.

IaaS クラウドを構築するには、マネージメント・システムおよび、コンピューティング(ハイパーバイザー)、ストレージ、そしてネットワークという、4つの要素が必要とされる。 マネージメント・システムにより、すべてのプロビジョニングとオーケストレーションが処理され、それが、コンピューティング、ストレージ、そしてネットワークの基礎となる。 このようなシステムの例としては、OpenStack および、Citrix CloudStack、Eucalyptus、VMware Vsphere といったものが挙げられる。

For compute, storage and networking, cloud architects look for solutions that linearly scale out (adding new capacity incrementally) rather than scaling up (buying bigger devices). This approach keeps costs low by consistently maximizing utilization. Even if cost weren’t an issue, this scale out approach is highly favored because it increases availability and reduces service interruptions of your cloud. In a well-thought distributed IaaS design, a single large device would never be an integral component of your cloud. Adhering to distributed design philosophies is a key reason why cloud service providers can consistently achieve very high levels of availability.

コンピューティング、ストレージ、ネットワークに関しては、クラウド・アーキテクトがソリューションを探すことになるが、それらはスケールアップ(大容量デバイスの購入)ではなく、リニアにスケールアウト(キャパシティの追加)していくものになる。このアプローチにより、最大の有用性を連続して保ち、コストを低く抑えていくことが可能になる。たとえ、コストが問題視さればいケースでも、このスケールアウトのアプローチは、クラウドの可用性を高め、停止を抑制するため、必ず好まれるはずだ。あなたのクラウドが、分散 IaaS デザインを用いて適切に構成されているなら、個々のデバイスを大容量化する必要性も、もはや無いはずだ。 分散デザインは、クラウド・サービス・プロバイダーが、きわめて高レベルな可用性を、安定して供給するために、欠かすことのできない考え方となっている。

Another item cloud architects look for are products that can integrate with the cloud management systems so that they are fully automated. Scaling out and automating compute is a known problem and all the cloud management systems solve it with ease. As for cloud storage, there are now great distributed options like Ceph, SolidFire and OpenStack Swift that linearly scale out and can be easily automated.

また、クラウド・アーキテクトは、クラウドを完全に自動化するために、クラウド・マネージメント・システムとの統合が可能なプロダクトも、探し出さなければならない。コンピューティングのスケールアウトと自動化は、広く認識されている問題であるが、すべてのクラウド・マネージメント・システムにより、容易に解決できるものでもある。 クラウド・ストレージに関しては、Ceph および、SolidFire、OpenStack Swift といった、分散化のための素晴らしい選択肢が提供されている。そして、それらを用いることで、リニアなスケールアウトと、容易なオートメーションが実現されていく。

Networks are hard to provision and scale

imageThese newly minted cloud architects are beginning to realize something that those in the cloud service provider business have known for a while. Network devices weren’t designed to be automated, and they definitely weren’t designed to be provisioned at the granularity and high-churn rate than IaaS clouds demand of them. Also, some network devices, instead of linearly scaling out as demand increases, tend to adopt a scale up model.

これらの、新たに誕生すべきクラウド・アーキテクトちは、クラウド・サービス・プロバイダー事業者が取り組んできた、何らかのものを理解し始めている。 まず、ネットワーク・デバイスは、自動化に対応するようデザインされていないことが挙げられる。そして、プロビジョニングする際の微調整にも対応せず、また、IaaS クラウドが要求するネットワークの組み換えにも対応できなかった。 さらに言えば、いくつかのネットワーク・デバイスは、要求が増大するときに、リニアにスケールアウトせず、スケールアップする傾向のある、モデルとして提供されている。

Networks aren’t flexible enough for cloud requirements

A common use case for an IaaS cloud is disaster recovery, which often requires the recreation of complex network topologies. This can be problematic because that typically would require the physical network to be purpose built for that specific disaster recovery scenario, thereby eliminating the cost benefits and general purpose nature of the IaaS cloud. Another very common use case is migrating existing applications to the cloud. Many applications are reliant on very specific network design patterns. These apps would pose problems if they were moved to the cloud and might even have to be rewritten to fully operate in a cloud environment.

IaaS クラウドにおける共通ユース・ケースは DR であり、複雑なネットワーク・トポロジーの再構築が頻繁に要求される。 それが問題になり得るのは、特定の DR シナリオのための物理ネットワークが、一般的には要求されるからであり、それにより、IaaS クラウドの費用対効果と多目的性が阻害されている。もう1つの、きわめて一般的なユース・ケースは、既存アプリケーションの、クラウドへの移行である。 そして、数多くのアプリケーションが、特定のネットワーク・デザイン・パターンに大きく依存している。もし、そのようなアプリがクラウドに移行されると、問題を引き起こすかもしれない。そして、さらに、クラウド環境で完全に稼働させるために、書き直しが必要になるかもしれない。

Enter overlay-based network virtualization

Overlay-based network virtualization is a technology that allows cloud users to provision virtual network devices such as virtual switches, virtual routers, virtual firewalls and virtual load balancers. These virtual network devices can then be connected to VM’s as well as other virtual network devices to create complex network topologies. Since these virtual devices live in software, the underlying network (a.k.a. the physical network) only needs to be an IP network which allows all the compute hosts to see each other. Two leading examples of overlay-based network virtualization solutions are Midokura’s MidoNet and Nicira’s Network Virtualization Platform. These particular solutions have an added benefit that they are designed to be fully distributed; that means the scaling model is linear and can be scaled out incrementally as demand increases. They are also integrated with cloud management solutions so that virtual network device provisioning is automated. Those who spent their lives deploying production clouds think of overlay-based network virtualization as the best way to handle networking for cloud environments.

オーバーレイ・ベースの仮想ネットワークは、仮想化されたスイッチ/ルーター/ファイアウォール/ロードバランサーいった仮想ネットワーク・デバイスを、クラウド・ユーザーにプロビジョニングさせるためのテクノロジーである。 それらの仮想ネットワーク・デバイスは、その後に VM に接続されるだけではなく、複雑なネットワーク・トポロジーを構成するために、その他の仮想ネットワーク・デバイスとも接続される。 それらの仮想デバイスはソフトウェアとして機能し、また、基本的なネットワーク(物理ネットワークのこと)は、すべてのホスト・コンピュータが相互に存在を確認するための、IP ネットワークとしてのみ必要となる。 このオーバーレイ方式をベースとした仮想ネットワーク・ソリューションの、2つの先進的な事例としては、Midokura の MidoNet と Nicira の Network Virtualization Platform が挙げられる。この種のソリューションは、完全な分散デザインという、付加的なメリットを提供する。 つまり、リニアに伸びるスケーリング・モデルのことであり、要求の増大に応じた段階的なスケール・アウトを実現していく。また、それらは、クラウド・マネージメント・ソリューションとも統合されるため、仮想ネットワーク・デバイスの自動的なプロビジョニングにも対応できる。 それらのソリューションは、オーバーレイ・ベースの仮想ネットワークの方式でディプロイされた、実運用クラウド環境に配置されるため、クラウドのネットワークを操作する上で最適な方式となる。

Predictions and prognostications

Now it’s time for me to put on my Nostradamus hat. Server virtualization adoption has grown at an extremely fast pace since its debut and has fundamentally changed the IT landscape. The next phase is widespread self-service IT adoption, and consequently, the proliferation of IaaS clouds. These concepts, as well as the technology behind them, will become essential to how the modern enterprise will deliver IT services. Because overlay-based network virtualization solves the very real problems stated above, it will soon become the preferred method of handling cloud networking. Now is a great time to start researching overlay-based network virtualization to better understand how it will fit within your IT future.

いまこそ、Nostradamus のように予言すべきだろう。 仮想サーバーの適用は、そのデビュー以来、きわめて速いペースで増大し、IT の基本となる風景を大きく変えてきた。 次のフェーズは、広範囲におよぶセルフ・サービス IT の適用であり、それに続いて IaaS クラウドの拡散が生じてくる。 その背景となるコンセプトだけではなく、そのためのテクノロジーも、近代的なエンタープライズが IT サービスを提供するときに、欠かすことにできない本質になるだろう。 オーバーレイ・ベースの仮想ネットワークは、そこで生じるきわめて現実的な問題を解決するため、クラウド・ネットワークの運用における、最も好ましい方式として、評価される日も間近のはずだ。オーバーレイ・ベースの仮想ネットワークが、あなたの IT の未来にフィットすることを理解するためにも、いまこそ調査を開始すべきである。 その時が やってきた。

Ben Cherian is a serial entrepreneur who loves playing in the intersection of business and technology. He’s currently the Chief Strategy Officer at Midokura, a network virtualization company. Prior to Midokura, he was the GM of Emerging Technologies at DreamHost, where he ran the cloud business unit. Prior to that, Ben ran a cloud-focused managed services company.

ーーーーー

TAG indexMidokura の Ben Cherian さんが、All Things D に寄稿した記事です。なぜ、仮想化が必要なのか? どのような仮想化が必要なのか? ・・・という視点で、これまでに私たちがたどってきた道筋の延長線上に、SDN(Software Defined Networks)が待っているのですよと、とても分かりやすく説明してくれます。SDN という言葉が指し示す範囲は広大であり、また、広すぎるが故に、理解し難かったのですが、オーバーレイ・ベースという考え方と、ソフトウェアとして機能する仮想デバイスという概念が、とても重要なのだと思えてきました。image

ーーーーー

<関連>

Midokura : SDN の巨人たちを標的に捉える
Midokura と SDN : どのように Layer 2-4 をサポートすべきか_1
Midokura と SDN : どのように Layer 2-4 をサポートすべきか_2
Apigee は、テレコムのための SDN を考える
Cisco が占有する スイッチ と ルーターの世界 : それを示す1枚のチャート

Cisco は vCider を買収し、分散クラウドを加速する

Posted in .Selected, Cisco, Network, OpenStack, SDN, Virtualization by Agile Cat on October 5, 2012

Cisco buys vCider to boost its distributed cloud vision
http://wp.me/pwo1E-4YJ

By
Barb Darrow – Oct 4, 2012
http://gigaom.com/cloud/cisco-buys-vcider-to-boost-its-distributed-cloud-vision/

_ Gigaom

vCider’s virtual networking smarts will help Cisco build distributed cloud infrastructure that ties into its own Open Networking Environment. The move is seen as a counter to VMware’s acquisition of Nicira.

vCider の仮想ネットワークにおける賢さは、Cisco が構築する分散クラウドインフラと、自身の Open Networking Environment の接続を、促進するものになるだろう。 この動きは、VMware による Nicira 買収へのカウンターのようにも見えてくる。

ーーーーー

Cisco is buying vCider, a specialist in virtual network overlay technology (and a former GigaOM Structure LaunchPad finalist). The move is a response to  VMware’s acquisition of Nicira and its software-defined networking technology in July which has strained the once close partnership between Cisco and VMware.

Cisco が買収する vCider は、仮想ネットワーク・オーバーレイ・テクノロジーのスペシャリストである(前回の GigaOM Structure LaunchPad のファイナリストでもある)。 そして、この動きは、7月に Nicira と SDN テクノロジーを買収した、VMware に対する回答でもある。 なぜなら、その買収劇により、Cisco と VMware を結んでいたパートナーシップに、歪が生じていたからである。

vCider’s technology works in much the same way as VXLAN, VMware’s attempt to get virtual machines to span dispersed data centers as part of the same local area network.

vCider のテクノロジーは、大まかなところで VXLAN と同じように機能する。 つまり、仮想マシンを用いることで、同一のローカルエリア・ネットワークの一部として、複数のデータセンターを分散させていこうとする、VMware の試みに似ている。

Cisco can use vCider’s expertise to build a unified yet distributed Cisco-based cloud. The networking giant will also integrate technology vCider used in its multi-tenant distributed virtual network controller into its work on the OpenStack Quantum network subsystem, according to a Cisco blog post announcing the deal, terms of which were not disclosed.

Cisco は vCider のテクノロジーを用いて、集約と分散という 2つの属性を持った、Cisco ベースのクラウドを構築できる。 さらに、このネットワーク界の巨人は、OpenStack Quantum ネットワーク・サブ・システムで、マルチ・テナント分散された仮想ネットワーク・コントローラを機能させるために、vCider のテクノロジーを統合するだろう。このことは発表されていないが、Cisco のブログ・ポストには、そのように記述されている。

Mountain View, Calif.-based vCider, as Stacey Higginbotham reported last year, aims to help companies, “span clouds while keeping security and compliance intact by installing software on a virtual machine instance in a cloud and then creating a mesh-like Layer 2 network that the administrator can control.”

Mountain View, Calif. をベースとする vCider は、昨年に Stacey Higginbotham がレポートしたように、『 クラウド上の仮想マシン・インスタンスに、ソフトウェアをインストールすることで、セキリティとコンプライアンスが損なわれないことを担保しながら、アドミンが制御できる、メッシュ上の Layer 2 ネットワークを構築するクラウド 』を目指す企業を支援してきた。

imageIn theory, vCider’s smarts will make it easier for Cisco to build easily distributed cloud infrastructure and incorporate that into Quantum. Quantum’s goal is to boost programmability of both virtual and physical networks that tie into Cisco’s own Open Networking Environment (ONE), according to the blog.

理論上は、vCider の賢さにより、Cisco は分散クラウド・インフラを容易に構築し、それを Quantum に取り込んでいくだろう。そのブログによると、Quantum の目標は、Cisco の Open Networking Environment(ONE)に接続される、物理/仮想ネットワークの双方において、プログラミング能力を引き上げることだとされている。

Cisco’s plans call for vCider to be integrated into Cisco’s Cloud Computing group which reports to CTO Lew Tucker. Cisco joined the OpenStack open-source cloud computing effort nearly two years ago and Tucker is vice chairman of OpenStack Foundation board.

Cisco のプランは、同社 CTO の Lew Tucker にレポートラインを持つ、Cisco Cloud Computing グループに、vCider を統合していくことである。 約 2年前から、Cisco は OpenStack OSS クラウド・コンピューティングに参加しており、また、Tucker は OpenStack Foundation ボードの Vice Chairman を務めている。

For more on the state of network come to Structure:Europe in Amsterdam on Oct. 16 and 17, to hear Nicira’s former CEO Steve Mullaney respond to the news.

さらなる詳細については、Structure:Europein Amsterdam on Oct. 16 and 17 に参加して欲しい。 そこでは、Nicira の前 CEO である Steve Mullaney が、このニュースに触れるはずだ。

Subscriber Content

 

 

 

ーーーーー

image名前は知っていましたが、どのような SDN を目指しているのかまでは、調べてことのない vCider です。 先ほど、急いで Web を見に行きましたが、すでに 『 vCider is now part of Cisco 』と書き換えられていました。 したがって、いまは Cisco のブログが頼りなのですが、この GigaOM の記事と比較して、それほど詳しい情報が記載されているとも思えません。 Cisco と vCider が、具体的に、どのような展開を見せるのかとなると、まだ、見えてこない状況です。 image

ーーーーー

<関連>

Apigee は、テレコムのための SDN を考える
Midokura と SDN : どのように Layer 2-4 をサポートすべきか_1
Midokura と SDN : どのように Layer 2-4 をサポートすべきか_2
Intel が思い描く、コモディティ SDN の構想 _1
Intel が思い描く、コモディティ SDN の構想 _2

 

VMware は Cloud Foundry に、独自の道を歩ませるべきだ

Posted in .Selected, PaaS, Virtualization, VMware by Agile Cat on July 30, 2012

VMware Needs Focus; Shedding Cloud Foundry Will Help
http://wp.me/pwo1E-4vh
Posted by
Mike Fratto – July 17, 2012
http://www.networkcomputing.com/virtualization/240003872

image

ーーーーー

注記:この記事がポストされたのは、Nicira の買収が発表される前となります。

ーーーーー

If the news coming from GigaOM that VMware is spinning out Cloud Foundry, Greenplum and Project Rubicon are true, it’ll be a good thing for VMware and EMC. VMware has lost some focus in the last few years in trying to branch out into applications and cloud services.

GigaOM が伝えるように、ほんとうに VMware が Cloud Foundry/Greenplum/Project Rubicon がをスピンアウトしていくなら、それは VMware と EMC にとって良いことになるだろう。アプリケーションとクラウドサービスに手を広げるという観点において、これまでの数年で VMware は、いくつかのフォーカスを失っている。

VMware built up its virtualization product suite in the early years with a single-minded focus on products that built on and augmented server virtualization. Add-on features like vMotion, Distributed Resource Scheduler, High Availability, Fault Tolerance and Site Recovery Manager added significant value to server virtualization, letting IT do things unheard of prior to the hypervisor. And VMware’s been on the right track; features like those are highly desired, according to our 2011 InformationWeek survey, “State of Virtualization.” VMware was the only game in town for a long time, but the company hasn’t sat idly by. It brought wave after wave of useful products to market. VMware also fostered a vibrant partner program, which further enhanced its products. Meanwhile, competitors like Citrix and Microsoft fumbled for strategies like a one-handed juggler.

VMware は、早い時期に仮想化スイートを構築したが、それはサーバーの仮想化の上に構成/拡張されたプロダクトにだけ、フォーカスするものであった。そして、vMotion/Distributed Resource Scheduler/High Availability/Fault Tolerance/Site Recovery Manager といったアドオン機能を加え、サーバーの仮想化に大きな価値を与え、ハイパーバイザーの以前には予想も出来なかったことを、IT により具体化していった。そして、私たちの 2011 InformationWeek 調査である “State of Virtualization” において、VMware は適切な方向へ向かっており、その役割に大きな期待が集まっていると評価された。 そして、長い期間において、VMware は最上のものというポジションを維持していたが、その間に同社が何もしなかったというわけでもない。 つまり、有用なプロダクトを、次から次へとマーケットにもたらしたのだ。 さらに VMware は、自身のプロダクトを拡張していく、活気に満ちたパートナー・プログラムを促進していった。 その一方で、Citrix や Microsoft といったコンペティタたちは、片腕のジャグラーのような戦略で、商機を掴み損ねていた。

imageAs VMware added more features and integrated more of its own products with vSphere, there was always the threat that it would cross over the line with partners that offered competing products. Since VMware owned the ecosystem, it would naturally have an unfair advantage that it could exploit at the expense of its partners/competitors. Yet, due to VMware’s overwhelming market share in server virtualization, vendors with competing products had nowhere else to turn.

VMware は、さらに多くの機能を加えていった。 そして、それ自身のプロダクトを vSphere と統合するにつれて、競合製品を提供しているパートナーとの境界線を、踏み越えてしまうと危機に遭遇するようになった。 このエコシステムは VMware に所有されるため、パートナー/コンペティタを犠牲にする、不公平な優位性を常に有することになった。そして、VMware が仮想サーバーのマーケット・シェアを占有するため、競合製品を手にするベンダーたちは、方向転換すら困難になっていった。

When VMware announced Cloud Foundry, it was the company’s big move into PaaS. It had both a commercial service run by VMware and an open source software archive hosted at CloudFoundry.org. This was VMware’s first move to expand its reach outside of vSphere and server virtualization, but CloudFoundry.com never quite took off. PaaS is more attractive to startups that are launching new services where a PaaS offers a number of advantages, like low operational overhead and manageable costs over IaaS, or owning your own hardware. However, enterprises have been slow to adopt PaaS as a strategy. In fact, many organizations are still in the midst of getting their private cloud off the ground, and haven’t even considered a move to a PaaS service.

VMware が Cloud Foundry を発表したときに、同社は PaaS へ向けた大きなシフトを示した。 そして、そこには VMware が推進する商用サービスと、CloudFoundry.org がホストする OSS の双方が存在した。 つまり、vSphere と仮想サーバーの外側に広がる、VMware としての最初の動きであったが、まったくと言ってよいほど CloudFoundry.com は離陸していかなかった。 PaaS は、新しいサービスを立ち上げるスタートアップにとって魅力的であり、また、より多くのアドバンテージを提供する。たとえば、ハードウェアを所有する場合よりも、さらには IaaS を利用する場合よりも、低く抑えられた運用上のオーバーヘッドとコストが、その利点として挙げられる。 しかしエンタープライズは、これまでのところ、戦略をして PaaS を採用するに至っていない。 実際のところ、依然として数多くの組織は、そのプライベート・クラウドを立ち上げる途上にあり、また、PaaS への移行については、検討さえ行なわれていない状況にある。

There’s still a lot of opportunity in the server virtualization and private cloud markets. In our InformationWeek Report, “Private Cloud Vision vs Reality, only 21% of respondents said they had a private cloud and 30% were starting a private cloud project. In both camps, VMware was the top vendor chosen as part of respondents’ private cloud efforts. However, only 16% of the respondents had settled on a bundled private cloud offering. Thirty-eight percent were going to use best-of-breed products, 30% were undecided, and 16% will use open source and commercial offerings. Neither VMware’s continued dominance in server virtualization nor its ability to expand its share in private cloud are assured.

仮想サーバーとプライベート・クラウドの市場には、依然として大きなビジネス・チャンスが残されている。 私たちの InformationWeek Report である ”Private Cloud Vision vs Reality” では、回答者の 21% のみがプライベート・クラウドを保有しているとし、また、30% がプライベート・クラウドを立ち上げていると状況にあった。 その両方の領域において、VMware はプライベート・クラウドのプラットフォームとして、トップ・ベンダーに選ばれている。 しかし、回答者の 16% に過ぎないが、それらの企業は、セットとして提供されるプライベート・クラウドの採用を決定していた。 また、38% がベスト・オブ・ブリードのプロダクトを使うとし、30% が未決定であり、16% が OSS および商用プロダクトを使うと回答した。 仮想サーバーにおける VMware の優位性と拡張性を、プライベート・クラウドにも継続して展開できるかというと、そこに確実性は存在しない。

Given the strong interest in private cloud, the large majority of organizations that have yet to move to a private cloud, and the company’s market share, VMware is well positioned to thrive. Cutting loose distractions like Cloud Foundry, Greenplum and Project Rubicon will let VMware focus on its core strengths in a very lucrative market.

プライベート・クラウドへの強い関心と、大半の組織がプライベート・クラウドに移動していないという状況、そして、VMware のマーケット・シェアを前提にすると、同社の未来は明るい。 Cloud Foundry のような混迷を切り離すことで、Greenplum と Project Rubicon は VMware のフォーカスを、利益性の高いマーケットにおける基本的な強さへと向かわせるであろう。

And while the company is of a mind to spin out products, the acquisitions of slideware service SlideRocket, miro-blogging Socialcast and collaboration service Zimbra still seems like an off-the wall set of acquisitions with no supporting strategy. VMware should spin them out as well.

そして、同社がいくつかのプロダクトをスピンアウトさせたいと考える一方で、スライドウェア・サービスの SlideRocket や、マイクロ・ブログの Socialcast、そしてコラボレーション・サービスの Zimbra といった一連の企業買収には、戦略的な視点が欠けているように見える。 VMware は同様に、それらを上手くスピンアウトさせるべきだ。

Mike Fratto is editor of Network Computing. You can email him, follow him on Twitter, or join the Network Computing group on LinkedIN. He’s not as grumpy as he seems.

ーーーーー

image実は、この記事、先週の月曜日にポストの予定だったのですが、Nicira 買収の発表により延期となってしまった経緯があります。 それにしても VMware は、どちらの方向を向いていくのでしょうか? ここで指摘されるように、Cloud Foundry のスピンアウトは、VMware にとっても良い結果をもたたすように思えるのですが、そうなると Nicira 買収の意味は何処にあるのかという、新しい疑問が湧いてきてしまいますね。 ーーー

ーーーーー

<関連>

VMware の言うクラウド選択の自由と、Nicira の買収は矛盾しないのか?
VMware が Nicira を $1.26B を買収 : その背景にあるものは?
Paul Maritz が VMware CEO を退任するらしい
VMware は OpenFlow を静観する_1
VMware は OpenFlow を静観する_2
VMware は OpenFlow を静観する_3

 

VMware は OpenFlow を静観する_3

Posted in OpenFlow, SDN, Virtualization, VMware by Agile Cat on July 6, 2012

VMware networking CTO on OpenFlow_3
http://wp.me/pwo1E-4oF
Shamus McGillicuddy Published: 19 Jun 2012
http://searchnetworking.techtarget.com/news/2240158351/VMware-networking-CTO-on-OpenFlow

_Tech Target

ーーーーー

VMware は OpenFlow を静観する_1
VMware は OpenFlow を静観する_2
VMware は OpenFlow を静観する_3

ーーーーー

Question: If OpenFlow or some other SDN protocol takes off and you’re able to abstract directly at each device rather than relying on an overlay technology, what kind of value can you derive from that?

もし、OpenFlow や他の SDN プロトコルが本格的に運用されるなら、オーバーレイ・テクノロジーに依存するのではなく、それぞれのデバイスをダイレクトに抽象化することが可能になる。 こうした流れの中で、どのような価値を引き出そうとしているのか?

Sequeira: I think what we have today is good enough for most of what we are trying achieve for network virtualization. Ultimately the number one problem we’re trying to solve in enterprise data centers is speed and agility of provisioning and efficiency. The whole point of a software-defined data center is to virtualize the rest of the data center. VMware-enabled provisioning allowed provisioning of servers within two minutes and for $300, whereas in the past it took 10 days and $10,000.

現時点において、私たちが有しているテクノロジーは、ネットワークの仮想化を達成するための、充分な能力を備えていると考える。エンタープライズ・データセンターにおいて、私たちが解決しようとしている最大の問題を突き詰めると、プロビジョニングにおけるスピードとアジリティであり、また、その有用性となる。データセンターをソフトウェア定義する際のポイントを俯瞰すると、その残りの部分を仮想化することにいたる。 VMware が実現するプロビジョニングは、2分以内の所要時間と $300 の対価で、複数のサーバーを立ちあげていくが、過去においては、10日間と $10,000 を要していた。

The rest of the problem is it takes five days to provision the rest — VLANs, IP address management, firewalls, storage availability. If you can provision these networks quickly, you have solved that problem. We believe with VXLAN and SDN we have solved that problem substantially. So customers aren’t asking us for OpenFlow. They are asking for agility of provisioning and seamlessness of experience when they start to bring up compute with network and storage alongside. In that particular instance, OpenFlow doesn’t bring you immediate value.

残された問題は、その他の部分の、つまり VLAN/IP アドレス管理/ファイアウォール/ストレージなどを利用可能にするために、5日を要する点である。 もし、これらのネットワークのプロビジョニングを、より短期間で達成できるなら、その問題を解決していることになる。 私たちは VXLAN と SDN により、この問題を充分に解決していると信じている。 したがって、私たちの顧客が、OpenFlow を求めるということはない。 それらの顧客が求めているのは、ネットワークやストレージと並行して、コンピューティングを構築し始めるときの、プロビジョニングのアジリティであり、シームレスなエクスペリエンスである。そして、特定のインスタンスにおいて、OpenFlow が即効性の価値をもたらすことはない。

Then why even consider OpenFlow in the data center? With OpenFlow you get a lot more granularity of visibility and control. With overlays, for the most part, it works. Most people build their fabrics and have headroom in their fabric. With OpenFlow you can be much more efficient, much like Google showed in their WAN. You can program each flow; you can bring up applications and say, ‘I want this application to take this specific path through the network.’ When you want much more specific control over your traffic, then you can look at OpenFlow. Likewise, you can ultimately get a lot more diagnostic capabilities because you know what is happening when an application has an issue with a server. You can quickly pinpoint what went wrong with the server.

それなら、データセンターで OpenFlow を考慮する理由は、どこになあのだろうか? OpenFlow を用いることで、さらに詳細なレベルにおいて、可視性とコントロールが得られる。 そして、オーバーレイを用いても、その大部分は機能する。 大半の人々は、自身のファブリックを作成し、その中に空き空間を持っている。 OpenFlow を用いることで、Google などの WAN で示されるような、さらなる効率が得られる。 つまり、それぞれフローをプログラミングできるようになる。具体的には、アプリケーションを指し示し、「 このアプリケーションのための特定パスを、ネットワークを介して取得できる」と、説明できるようになる。 自身のトラフィック上で、より詳細なコントロールを必要とするとき、OpenFlow に注目するようになるだろう。 さらに突き詰めれば、アプリケーションが問題を引き起こしたサーバーを認識できるため、さらなる診断能力が得られることになる。 つまり、支障をきたしているサーバーを、より素早く指摘できるようになる。

But people aren’t ready for it yet. Today people want to monitor networks with existing tools. Even if the technology was 100% there today, it takes a while for organizations to change people and processes. If you have 200 Stanford Ph.D.s and you own your own fiber and can build your own boxes in your backyard and you own your own traffic and have proprietary applications, then [Openflow] is for you [now].

しかし、そのための準備を、人々は済ませていない。 現時点で望まれているのは、既存のツールを用いた、ネットワークのモニタリングである。 たとえ、完全なテクノロジーが存在するにしても、組織における人員とプロセスを変更するには、しばらくの期間を要する。 もし、200人の Stanford Ph.D をスタッフとしてい抱え、また、自身のファイバーを所有し、裏庭で自身のためのデバイスを作成し、自身のトラフィックとプロプライエタリなアプリケーションを持つなら、すでに Openflow は、あたなのためのものである。

Question: So enterprises don’t need OpenFlow, and they will probably wait until somebody commercializes it?

そうなると、エンタープライズは OpenFlow を必要とせず、また、誰かが商用化するまで、それを待つことになるのか?

Sequeira: Exactly. If all you are doing is working on your own proprietary applications like Google, Facebook or Zynga, that’s one problem. Our problem is very different. The reason VMware is so solidly grounded in enterprises is because 90% of these applications have been running in networks for years and years. VMware enabled these existing applications to be containerized and you’re able to insert the virtualization layer, which allows you slip in new hardware without touching the applications. All these new applications we talk a lot about — big data and Hadoop — that’s not what most enterprises are facing today. It’s the 95% of applications in enterprise that we want move forward.

まさに、そのとおりだ。 もし、行うべき全ての作業が、Google/Facebook/Zynga のような、プロプライエタリなアプリケーション上で完結するなら、その問題は一点に絞られる。 しかし、私たちの問題は、きわめて多様なものとなる。 VMware がエンタープライズの強固な基礎として用いられてきた理由は、そこでのアプリケーションの 90% が、何年にもわたりネットワーク上で動作してきたからである。 VMware が実現してきたのは、既存アプリケーションのコンテナ化であり、また、仮想化レイヤーの挿入である。 そして、それらを実現することで、アプリケーションに触れることなく、新しいハードウェアを追加できるようにしてきた。 また、Big Data や Hadoop といった、新しいアプリケーション・スタイルについても言及してきたが、大半のエンタープライズは、それらに直面するという状況にない。つまり、その他の 95% のエンタープライズ・アプリケーションを、さらに前進させたいと考えている。

Question: Do you see VMware competing with Nicira Networks, Big Switch Networks and NEC?

VMware は、Nicira/Big Switch/NEC などと競合するのか?

Sequeira: The real question is: Are Nicira and Big Switch a feature in VMware? We are not looking to compete with them. The onus is on them to find an important and relevant area that solves a unique problem. Solving network virtualization in the context of a VMware stack? We’ve got that nailed. In other words, we don’t believe that we need an outside answer to solve a virtualization problem for our VMware stack.

現実には、VMware は Nicira や Big Switch をプッシュするかという質問だと理解する。 私たちは、彼らとの競合を望むわけではない。 彼らの責任は、ユニークな問題を解決するための、重要かつ適切なエリアを見つけ出すことである。 VMware スタックのコンテキストにおいて、ネットワークの仮想化という問題を解決するだろうか? すでに、私たちは、その問題を捉えている。 言い換えれば、VMware スタックにおける仮想化の問題を、外部の力を借りて解決する必要性があるとは信じていない。

<終わり>

ーーーーー

TAG index3回に分けて掲載してきた、この「VMware は OpenFlow を静観する」ですが、Sequeira による一連のコメントには、このマーケットをリードする者の「強気」が見え隠れしているように思えます。 たとえば、2012年 4月にポストした「アメリカの 最強 IaaS プロバイダー Top-10 をリストアップ!」という抄訳では、そのうちの 4社に対して Key Building Block を提供する存在として、VMware が紹介されています。 Open Networking Summit で OpenFlow へのコミットを明確にした Google と比べて、その対極に位置する VMware のスタンスには、これからも注目していきたいと思います。 ーーー image

ーーーーー

<関連>

VMware は OpenFlow を静観する_1
VMware は OpenFlow を静観する_2

VMware は OpenFlow を静観する_3
ーーーーー
VMware が考える、ソフトウェア定義によるデータセンターとは?
VMware の考える SDN は、OpenFlow だけでは完成しない
Google の OpenFlow バックボーンは、どのように機能しているのか_1
Google の OpenFlow バックボーンは、どのように機能しているのか_2
トップを快走する AWS と、それを追いかける 7人の チャレンジャー

VMware は OpenFlow を静観する_2

Posted in OpenFlow, SDN, Virtualization, VMware by Agile Cat on July 4, 2012

VMware networking CTO on OpenFlow
http://wp.me/pwo1E-4oo

Shamus McGillicuddy Published: 19 Jun 2012
http://searchnetworking.techtarget.com/news/2240158351/VMware-networking-CTO-on-OpenFlow

_Tech Target

ーーーーー

VMware は OpenFlow を静観する_1
VMware は OpenFlow を静観する_2
VMware は OpenFlow を静観する_3

ーーーーー

Question: In part two of our Q&A with Allwyn Sequeira, CTO and vice president of cloud, networking and security, we delve into VMware’s position on OpenFlow.

 Does the VMware networking strategy include support for OpenFlow?VMware のネットワーク戦略には、OpenFlow のサポートが取り込まれているのだろうか?

Sequeira: We are part of original team with the Open Networking Foundation and part of the founding team of ONRC [Open Networking Research Center] Labs.

私たちは、Open Networking Foundation のオリジナル・チームに属し、また、ONRC [Open Networking Research Center] Labs の創設メンバーでもある。

ーーー

Sequeira は、VMware における SDN and Network Virtualization の CTO である。 そして、以下は、Q&A に先立って、Sequeira との議論を整理したものである。

ーーー

If you look at SDN and OpenFlow, [they] prescribe a certain way of doing things. Extract the control plane, control the forwarding plane via the OpenFlow protocol, and have a centralized management scheme.

もし、あなあたが SDN と OpenFlow に注目しているなら、それを実現する確かな方式を、[彼ら]は規定していると思うべきだ。 それは、コントロール・プレーンを抽出し、OpenFlow プロトコルを介したプレーンの転送をコントロールし、そして、センタライズされたマネージメント・スキームを持つことである。

We are mostly there today. If all the equipment on the network were OpenFlow-enabled, we would be able quickly manipulate all boxes in the network via OpenFlow, and life would be good.

多かれ少なかれ、私たちは、現在という時勢に拘束されている。 もし、ネットワーク上のすべての装置が OpenFlow に対応するなら、OpenFlow を介したネットワーク上で、それらのボックスを操作できる。 そうすれば、すべてが上手くいくだろう。

The reality is that less than 1% of enterprise switches today are OpenFlow-enabled. So for our specific view, we will take an intermediate step. We will do SDNs and notions of Ethernet abstractions, network service abstractions like firewalls, load balancers, etc. It all dovetails with software defined networking, with a centralized control plane. With things like VXLAN we overlay the current network. And yet at a higher level from SDN perspective, we still realize the same services that SDN provides. Give me a network, allow me to add VMs to that network, plug in a firewall service; it preserves northbound APIs. But on the southbound side, rather than start with programming OpenFlow agents, we have overlay networks and VXLANs.

しかし、現実を見れば、エンタープライズ・スイッチで OpenFlow に対応しているものが、1% にも満たないことが分かってくる。 したがって、私たちは自身の視界を得るために、中間的なステップをとることになる。 つまり、SDN を Ethernet 抽象概念に取り組み、また、ファイアウォールやロードバランサといった、ネットワーク・サービスの抽象概念に取り組むことになる。 それら全てが、Software Defined Networking および、センタライズされたコントロール・プレーンと噛み合う。 つまり、VXLAN のようなものを用いて、既存のネットワークをオーバーレイしていく。 その一方で、SDN の視野に基づく高い抽象レベルにおいては、SDN が提供するものと同じサービスを、さらに理解する。 ネットワークを提供し、そこへの VM の追加を実現し、ファイヤーウォール・サービスを接続するような、軌道に沿った API を維持する。また、もう一方の軌道においては、OpenFlow エージェントのプログラミングよりも、オーバーレイ・ネットワークと VXLAN を活用していく。

imageNow as OpenFlow agents become available in the enterprise, we can map VXLANs on top of OpenFlow. VXLAN is an encapsulation that rides across the network. If the underlying network is OpenFlow-enabled, we can map the VXLAN and program the VXLAN across the underlying network. In the meantime, all the investments our customers made with northbound APIs and network virtualization, with VXLANs, all that is preserved. Then we can continue to evolve that network and go more into leveraging native OpenFlow when it has meaningful penetration of the enterprise market.

いまや、OpenFlow エージェントがエンタープライズで利用され始めているが、私たちは OpenFlow の上に、VXLAN をマップしている。 VXLAN はカプセル化され、ネットワークの向こう側に受け渡される。 もし、基本的なネットワークが OpenFlow 対応なら、VXLAN をマップすることが可能であり、また、それらのネットワークを横断するよう、VXLAN をプログラムすることが可能である。 その一方では、私たちの顧客による投資は、VXLAN に関連する API とネットワークの仮想化へと向けられ、その全てが維持されていく。 そして、OpenFlow がエンタープライズ市場に、意味のあるかたちで浸透していくとき、前述のネットワークを発展させ続け、また、OpenFlow の本質を活用することが可能となる。

It’s the same thing we did with server virtualization. In the early days we used to be on the outside looking in. Once you reach the point with 50% virtualization, you begin to optimize for virtual environments and bridge to the physical. The same [will happen] with networks. We are beginning to optimize for network virtualization and VXLANs. When OpenFlow reaches 50% penetration, we will optimize for OpenFlow. I look at this as a continuum rather than OpenFlow versus VXLAN. This allows us to bring OpenFlow into an organization gently versus a forklift upgrade. OpenFlow is a specific way to program the network, but SDN doesn’t mean you can only do it with OpenFlow.

それは、サーバーの仮想化において、私たちが行なってきたことに等しい。 その初期には、私たちは外から中を覗き込んでいる人に過ぎなかった。 そして、仮想化の比率が 50% に達すると、そのための環境を最適なものにし、また、物理環境とのブリッジを作り始めた。 それは、ネットワークにおいても同じであり、また、同じように展開するだろう。 そして、いま、私たちはネットワークの仮想化と VXLAN のための、最適化に着手し始めた。 そして、OpenFlow の浸透率が 50% に達するとき、OpenFlow を最適化していくだろう。 OpenFlow と VXLAN の関係については、対決というより連続的なものと見ている。 それにより、何らかの組織に OpenFlow を取り込むとき、フォークリフト的な極端なアップグレードではなく、穏やかな改善として取り扱うことが可能になる。つまり OpenFlow は、ネットワークをプログラムする際の、1つの方式に過ぎない。 それに対して SDN は、その相手を OpenFlow だけに限定するものでない。

続く>

ーーーーー

TAG index以前に、WMware の、こんなコメントを読んだことがあります。 ーーー 「 サーバーの仮想化はハードウェアを抽象化し、その上でソフトウェア走らせるようにする。 そして、その数だけの仮想マシンを、1台のサーバー上に配置できるようにする。 さらに、ネットワークの仮想化は、アプリケーションの要求に応じて、ケーブルとポートを抽象化していく。 しかし、それでは十分と言えない 」 ーーー 最終回である、その3 をお楽しみに。 ーーー __AC Stamp 2

ーーーーー

<関連>

VMware は OpenFlow を静観する_1
VMware は OpenFlow を静観する_2
VMware は OpenFlow を静観する_3
ーーーーー
VMware が考える、ソフトウェア定義によるデータセンターとは?
VMware の考える SDN は、OpenFlow だけでは完成しない
Google の OpenFlow バックボーンは、どのように機能しているのか_1
Google の OpenFlow バックボーンは、どのように機能しているのか_2
トップを快走する AWS と、それを追いかける 7人の チャレンジャー

VMware は OpenFlow を静観する_1

Posted in .Selected, OpenFlow, SDN, Virtualization, VMware by Agile Cat on July 2, 2012

VMware networking CTO on SDN, OpenFlow and network virtualization
http://wp.me/pwo1E-4nj

Shamus McGillicuddy Published: 19 Jun 2012
http://searchnetworking.techtarget.com/news/2240158349/VMware-networking-CTO-on-SDN-OpenFlow-and-network-virtualization

_Tech Target

ーーーーー

VMware は OpenFlow を静観する_1
VMware は OpenFlow を静観する_2
VMware は OpenFlow を静観する_3

ーーーーー

Although VMware is best known as a server virtualization company, its impact on the networking industry has been profound. VMware-based server consolidation has driven up bandwidth requirements; the embedded distributed virtual switch in VMware’s hypvervisor software has virtualized the server access layer of most data centers; and the dynamic nature of virtual machines is driving much of the competitive innovation in the data-center networking market today.

サーバーの仮想化を推進する企業として、VMware は最も有名な企業であるが、ネットワーク産業に対する大きな影響力も有している。 VMware ベースのサーバー・コンソリデーションは、帯域幅の要件を引き上げてきた。 また、VMware の ハイパーバイザー・ソフトウェアにエンベッドされた分散仮想スイッチは、大半のデータセンターにおけるサーバー・アクセス・レイヤーを仮想化してきた。そして更に、仮想マシンにおける動的な特性が、今日のデータセンター・ネットワーク市場における、競合のためのイノベーションを激しくドライブしている。

During his keynote at Interop Las Vegas recently, Steve Herrod, VMware CTO and senior vice president of R&D, introduced the concept of the software-defined data center, a term which is naturally evocative of one of the hottest areas of networking today: software defined networking (SDN). SearchNetworking.com spoke recently with Allwyn Sequeira, CTO and vice president of cloud, networking and security, to learn more about VMware’s views on the software-defined data center, network virtualization and SDN.

先日に Las Vegas で開催された Interop のキーノートで、VMware の CTO and Senior VP of R&D である Steve Herrod は、データセンターをソフトウェアにより定義していくというコンセプトを提起した。それは、現在のネットワーク市場において、最も人気のエリアである SDN を彷彿とさせるものである。 最近のことだが SearchNetworking.com は、同社の CTO and VP of Cloud, Networking and Security である Allwyn Sequeira にインタビューする機会を得た。 そして、ソフトウェアによるデータセンターの定義および、ネットワークの仮想化、そして SDN について、VMware の視点を聞き出すことに成功した。

Question: VMware has started promoting the concept of the software-defined data center. This sounds evocative of the software-defined-networking movement. Could you elaborate on this?

VMware は、ソフトウェアによるデータセンターの定義というコンセプトを促進し始めた。 それは、SDN の盛り上がりを彷彿とさせる。 その点について、詳述して欲しいのだが?

Allwyn Sequeira: The thinking was, we had vSphere and life was good. Now we need to virtualize the rest of the data center. As we started to evolve our thinking toward networking, the software-defined-networking momentum also happened to be in play at the same time. Most of our concepts of network virtualization, and some of the notions of SDN, are very applicable across network, compute, storage and security. It’s a natural evolution to take the SDN construct and parlay that into a larger construct, which is the software-defined data center. Over time, we expect to see less and less specialty hardware [in data centers] and more x86 hardware with specialty software.

その考え方は、私たちが vSphere を有し、また、それが上手くいっているという現実に根ざしている。 ただし、私たちは、データセンターにおける残りの部分を仮想化する必要性が生じてきた。 私たちの発想がネットワークの領域におよび始めるにつれて、SDN へ向けた推進力も、同時に高まってきている。 ネットワークの仮想化における大半のコンセプトと、SDN における若干のコンセプトは、ネットワーク/コンピュート/ストレージ/セキュリティのいたるところで、大いに適用できるものである。 それは、SDN の構成を自然に発展させたものであり、ソフトウェアによるデータセンターの定義という、さらに大きな構成を運用するものとなる。 長い時間をかけながら、データセンターにおけるハードウェア間の差異は減少し、また、ソフトウェアにより差別化された x86 ハードウェアが増えていくと、私たちは期待している。

The other theme is that the virtual machine [VM] as a container has stood up well and become the abstraction in the workload space, whether it be Amazon or VMware. The VM has become a unit of server virtualization and desktop virtualization. Likewise, what’s left of the data center, the virtual data center, becomes a new container.

もう 1つのテーマは、コンテナとしての仮想マシン[ VM ]が上手く立ち上がり、それが Amazon であろうと VMware であろうと、ワークロード・スペースの抽象概念になることである。 いまや VM は、サーバーの仮想化と、デスクトップの仮想化における、ユニットになっている。 それと同様に、データセンターへの取り組みにおいて残されているのは、仮想データセンターの概念であり、それが新しいコンテナになることだ。

imageQuestion: What do you mean when you speak of data centers being composed of x86 hardware with specialty software? Is this the VMware networking vision?

x86 ハードウェアと専用のソフトウェアで構成されるデータセンターについて話すとき、それは何を意味するのか? それは、VMware におけるネットワークのビジョンなのか?

Sequeira: A broader statement is x86 and merchant silicon is clearly the trend that exists. My point there is that the Ciscos of the world have spent lot of time and energy on ASICs, but a lot of software and control is increasingly happening on the x86 portion. Most of [data center] gear is headed that way. If you look at an F5 [Networks] device, it’s mostly x86s. Look at a Cisco ASA, where they have firewalls and load balancers. That’s all x86-based. We have versions of Cisco routers working with embedded hypervisors running on x86 to enable a whole bunch of VMs to run on them. If you look at some Cisco devices, they run with a hypervisor embedded. Not many people recognize it, but an increasing part of hardware, even in the Cisco world, is x86-based and merchant silicon. So the better way to say it is that X86 and commercial off-the-shelf merchant silicon is going to be prevalent in data center servers and the network itself.

広義の意味で x86 を引き合いに出しているが、トレンドとして存在するシリコン・シップという意味である。 私が指摘したいのは、Cisco たちの世界で、ASIC の開発に時間と神経が浪費されていることであり、また、ソフトウェアとコントロールにおける大半の部分が、x86 の領域に移行していることである。 データセンター・ギアにおける大半が、その方向へ向かっている。 F5 [Networks]  デバイスを見てみれば、その大半が x86 だと理解するだろう。 ファイヤーウォールとロードバランサーが集約される、Cisco ASA を見ると良い。 それは、完全に x86 ベースとなっている。私たちは、いくつかの Cisco ルーター・バージョンを持っているが、それらは x86 上で走るエンベデッド・ハイパーバイザーにより機能し、また、たくさんの VM を実行している。 いくつかの Cisco デバイスを確認してみれば、それらがエンベッドされたハイパーバイザーにより動いていることが解るだろう。 多くの人々が、そのことを認識していない。 しかし、Cisco の世界であっても、ハードウェアの役割が増大しているのは、x86 ベースの商用チップのパートである。 もう少し上手い言い方をすると、X86 および普及品のシリコン・チップが、データセンターにおけるサーバーとネットワークを構築していくことになる。

Question: I think Cisco might disagree with you. It continues to argue that ASICs give it an edge in the data center.

Cisco は、あなたと違う意見を持っていると思う。 同社は、データセンターにおけるエッジは、ASIC が握っていると主張し続けている。

Sequeira: If I were Cisco that’s what I would say. And if I were Cisco, I would still look at merchant silicon. If I purely based my franchise on merchant silicon, that really says the networking play moves to software. What I think they’re saying is that all that merchant silicon and x86 is fine, but when you get to higher and higher consolidation, there is still a need to scale out with rows of x86-based, top-of-rack switches. You still need to come out to core. And at the heart of it, you still need very fast switching silicon there, the likes of which are only produced by the Ciscos and Junipers of the world. And that is a valid statement.

もし、私が Cisco の人間なら、同じことを言うだろう。 そして、並行して、商用のシリコン・チップに注目するだろう。 さらに、商用人シリコン・チップの上に、私の基盤が確立するなら、ネットワークの舞台がソフトウェアに移行したと発言するだろう。彼らも、商用シリコン・チップや x86 について、素晴らしいと考えているはずだと、私も捉えているしかし、きわめて高度なコンソリデーションを行う場合には、ラック・スイッチの上に大量の x86 を並べて、スケールアウトする必要がある。 そこで、また議論はコアへと戻ってくる。 そして、その心臓部においては、依然として超高速のスイッチング・シリコンが必要となる。 それらは、この世界において Ciscos と Juniper だけが生産できるものである。 そして、それは妥当な発言である。

Any Cisco box has three components: input and output ports, software processing and then the fastpath. The fastpath — tagging and protocols — is where Cisco has always distinguished itself from its peers. Inside the very core of these boxes, having that fast and specialized silicon might make sense. But all the programmability and scale-out and manipulability will come out of the slowpath and control plane portions of these boxes.

あらゆる Cisco ボックスは、IN/OUT ポートと、ソフトウェア・プロセッシング、Fast Path という、3つのコンポーネントから構成される。 タグ付けとプロトコルに関する Fast Path は、常に Cisco が、他社に対して差別化しているポイントである。 それらのボックにの、きわめてコアな部分で、超高速の特殊なシリコンを有することは意味をなすだろう。 しかし、すべてのプログラミング能力および、スケールアウトとマニュピレーションは、それらのボックスにおけるコントロール・プレーンと Slow Path に依存するものとなる。

続く>

ーーーーー

TAG index2012年4月に VMware は、Open Networking Research Center という SDN に関する業界コンソーシアムを立ち上げるために、Stanford および Berkeley とチームを構成しています。 いくつかの企業は、ネットワークにおける急激な刷新(破壊)を共有しようと試みますが、サーバーの仮想化において、つまりハイパー・バイザで実績を積み上げてきた同社は、そのようには見ていないようです。ーーー __AC Stamp 2

ーーーーー

<関連>

VMware は OpenFlow を静観する_1
VMware は OpenFlow を静観する_2
VMware は OpenFlow を静観する_3
ーーーーー
VMware が考える、ソフトウェア定義によるデータセンターとは?
VMware の考える SDN は、OpenFlow だけでは完成しない
Google の OpenFlow バックボーンは、どのように機能しているのか_1
Google の OpenFlow バックボーンは、どのように機能しているのか_2
トップを快走する AWS と、それを追いかける 7人の チャレンジャー

 

 

 

 

 

Intel 48 Cores + Hadoop

Posted in Hadoop, MS-MapReduce, Parallel, Virtualization by Agile Cat on December 4, 2009

Futuristic Intel Chip Could Reshape How Computers are Built, Consumers Interact with Their PCs and Personal Devices

Intel 48 cores

SANTA CLARA, Calif., Dec. 2, 2009 – Intel Labs 研究者がデモンストレーションしたのは、48-core Intel プロセッサであり、つまりは、シングルチッ・プクラウド・コンピュータであり、ラップトップや、PC、サーバーなどのデザインで用いられている、現在における数多くのアプローチを再考させるものである。 この未来のチップは、現時点で広く利用されているIntel Core ブランド・プロセッサと比較して、10~20倍の能力のある処理エンジンを内部に持つ。

この研究における長期的なゴールは、まったく新しいソフトウェア・アプリケーションと、コンピュータのマンマシン・インターフェイスをドライブするための、途方も無いスケールを加えていくことである。Intel が来年に計画しているのは、新しいソフトウェア・アプリケーションとプログラミング・モデルの具体的な研究のために、100 個以上の実験用チップを、産業界と教育機関で共有していくことだ。

Intel は、2010 年の前半には、Core ブランド・チップの新しいラインに主要な特徴を統合し、後半には 6-core と 8-core のプロセッサに、それらを導入する。その一方で、このプロトタイプを用いて、1つのシリコン・チップ上に、プログラムを処理できる48個の Intel プロセッシング・コアを取り込んでいく。さらに、 情報共有のための、高速のオン・チップ・ネットワークと、新たに開発されたパワー・マネジメント技術も取り込む。それにより、わずか25ワットから、最大性能時における 125ワットまでの間で、48コアにおける全てをエネルギーを、きわめて効率的に操作できる(今日の Intel プロセッサの消費電力は、標準的な家庭用電球2個分ほど)。

<中略>

マルチ・コア・プロセッサのプログラミングは、シングル・シリコン・チップ上の Many Core へ向かう、コンピュータとソフトウェアのメーカーにとって、重要なチャレンジとして認識されている。 このプロトタイプが実現するのは、一般的で効果的な並列プログラミングのアプローチであり、クラウド・データセンターのソフトウェアで用いられ、このチップに適用されるものとなる。

Intel 48 cores Hadoop

こんな画面も、Youtube の動画でチラッ見られますよ~~~

Intel/HP/Yahoo の Open Cirrus コラボレーションからの研究者により、この 48 IA コアチップへのクラウド・アプリケーションのポートが始まっている。それは、Java framework を用いる Hadoop であり、Rattner が証明しているような、データ・セントリッな分散アプリケーションをサポートしている。 

詳しくは、↓ こちらで ど~ぞ。
http://www.intel.com/pressroom/archive/releases/2009/20091202comp_sm.htm

この実験に Hadoop が使われることが、とても自然に思えます。 Many Core の活躍の場を、Hadoop が作っていくと言っても過言ではないでしょう。 --- A.C. 

<関連>
Nehalem と仮想化

%d bloggers like this: