Agile Cat — in the cloud

Savvis が AppFog を買収? Cloud Foundry エコシステムへの影響が心配だ!

Posted in PaaS, VMware by Agile Cat on June 15, 2013

Breaking: Savvis to buy AppFog
http://wp.me/pwo1E-6fy

By
Barb Darrow
http://gigaom.com/2013/06/13/breaking-savvis-to-buy-appfog/

_ Gigaom

Summary: With AppFog, Savvis will get a Cloud Foundry-based Platform as a Service to run atop its own VSphere or vCloud Director-based infrastructure.

Summary: AppFog を得ることになれば、Savvis の vSpher および vCloud Director 上で、Cloud Foundry ベースの PaaS が動き出すことになる。

Savvis is about to buy AppFog, a Platform-as-a-Service startup based in Portland, Ore., according to several sources. Savvis, a data center operator, was acquired itself two years ago by CenturyLink in a $3.2 billion bid to build a cloud and hosted managed services powerhouse.

いくつかの情報源によると、Portland, Ore ベースの PaaS である AppFogを、Savvis が買収しようとしているらしい。 このデータセンター・オペレーターである Savvis も、クラウドとマネード・ホスティングのサービスを構築するために、2年前に CenturyLink  により、$3.2 billion で買収されている

Details are scarce since AppFog had no comment and Savvis could not be reached for comment but sources with knowledge of the deal expect the news to be announced Monday. Founded in 2010, AppFog garnered about $10 million in venture funding from Ignition Partners, Xen founder Simon Crosby, Madrona Venture Group, First Round Capital and Founders Co-Op.

AppFog からはコメントがなく、Savvis にはコンタクトさえ取れないので、詳細な情報が不足しているが、この買収劇に精通しているニュース・ソースは、月曜日には発表されると予想しているようだ。AppFog 自身は、Ignition Partners および、Xen founder Simon Crosby、Madrona Venture Group、First Round Capital、Founders Co-Op といった、VC からの $10 million ほどの出資により、2010年に設立されている。

Given that Savvis is a big VMware vSphere and vCloud Director partner, AppFog could give it a “house brand” PaaS of its own. AppFog’s PaaS builds atop standard Cloud Foundry technology, which came out of VMware. Its pitch was that AppFog abstracted out messy details of base cloud infrastructure so developers could move their apps from Amazon to Rackspace to HP or other public clouds at will. That eliminated cloud lock-in at least at the Infrastructure-as-a-Service (IaaS) layer. In April, however, AppFog dropped support for Rackspace and seemed to be narrowing its focus.

Savvis が、VMware vSphere および vCloud Director のビッグ・パートナーであることを考えると、AppFog により自社ブランド PaaS が登場する可能性もある。AppFog の PaaS は、VMware から提供される、標準的な Cloud Foundry テクノロジーの上に構築されている。そして、その宣伝文句は、AppFog が抽象化を進めることで、基本的なクラウド・インフラにおける煩雑さがなくなるため、Amazon から Rackspace や HP などのパブリック・クラウドへと、開発者たちは自分のアプリを、思いのままに移行できるちいうものだった。それは、少なくとも、IaaS におけるクラウド・ロックインを排除しようというものだった。しかし、4月に入ると、AppFog は Rackspace のサポートを取りやめ、フォーカスする対称を絞り込んでいくように見えた。

At the time, word was that VMware’s decision to spin off Cloud Foundry to Pivotal and offer it as a commercial PaaS hurt members of the ecosystem — including ActiveState, Uhuru and AppFog — it had recruited to build PaaSes atop that technology. That led to talk of a possible fork of Cloud Foundry.

VMware の決定が、Pivotal に Cloud Foundry をスピンオフさせ、商用 PaaS がエコシステムのメンバー(ActiveState/Uhuru/AppFog を含む)を傷つけると言われていたころ、このテクノロジー上での PaaS を構築する勢力が求められていた。 そして、Cloud Foundry がフォークするかもしれないという話に結びついていった。

Given this news, it looks like AppFog technology will be more tightly wedded to Savvis/VMware infrastructure, but no one’s saying.

したがって、今回のニュースを考えると、AppFog のテクノロジーと Savvis/VMwareのインフが密着していくように見えるが、それを、誰も指摘していない。

PaaS as a category hasn’t gained a ton of traction in the enterprise — even some in the market concede that it lacks a killer app to convince CIOs to buy into the concept. Developers at companies often use these platforms hosted on outside cloud infrastructure to build and test software but when the time comes to deploy, the apps typically come in-house.

カテゴリーとしての PaaS は、エンタープライズを変化させるだけの推進力を得ていない。さらに、PaaS コンセプトの導入においては、CIO たちを説得するたけのキラー・アプリが欠落していると、いくつかの市場で確認されている。 それらの企業における大半の開発者たちは、ソフトウェアの構築/テストを進めるために、外部のクラウド・インフラ上にホストされるプラットフォームを使用する。 しかし、一般的には、デプロイを行う段階で、インハウスへと移行することになる。

Pivotal trotted out General Electric’s $105 million investment in its new venture as proof that enterprise adoption of PaaS is on the upswing. Red Hat this week made its enterprise-focused OpenShift PaaS generally available. OpenShift adoption could be a bellwether for the category.

エンタープライズでの PaaS 採用が、回復基調にあることを証明するものとして、Pivotal が引き合いに出しているのは、General Electric が $105 million を新事業に投資していることだ。 その一方で、今週の Red Hat は、エンタープライズにフォーカスする OpenShift PaaS を、一般的に提供し始めた。 このカテゴリーでリードするために、OpenShift と採用するという可能性も生じてくるだろう。

Related research

ーーーーー

PaaS の特質は、その生産性の高さと、ロックインによる制約にあるのでしょう。 先日に、『 Google App Engine ケース・スタディ:その API が Angry Birds を元気にする 』という抄訳で、Google App Engine が好調だと伝えましたが、『 Elastic Beanstalk とは? 』で Amazon CTO の Werner Vogels が語っていた、ロックイン排除の難しさを思い出しました。その意味で、複数のプロバイダーが、Cloud Foundry を提供する形態は、ある種の理想だと思っていたのですが、なかなかうまく行かないようですね。 image

ーーーーー

<関連>

Cloud Foundry がフォークする? : その可能性について調べてみよう
VMware は Cloud Foundry に、独自の道を歩ませるべきだ
Cloud Foundry と OpenStack の統合は、Piston Cloud が引き受けた!
Cloud Foundry が .NET をサポートする!
VMware の Cloud Foundry が、デベロッパーの 人気 No.1 になる理由は?

 

VMware と Ubuntu が連携 : OpenStack とのインターオペラビリティ

Posted in OpenStack, VMware by Agile Cat on April 23, 2013

VMware Adds Interoperability With Ubuntu OpenStack Cloud
http://wp.me/pwo1E-60F

Charles Babcock| April 18, 2013
http://www.informationweek.com/cloud-computing/infrastructure/vmware-adds-interoperability-with-ubuntu/240153156

_ Information week

The next Ubuntu release, coming soon, will include VMware plug-ins for the Quantum networking platform in OpenStack.

もう直と言われている、次期 Ubuntu のリリースだが、OpenStack の Quantum  ネットワーク・プラットフォームに対応する、VMware のプラグインが含まれるようだ。

VMware has contributed plug-ins to the OpenStack Project that guarantees the project’s networking platform will recognize and work with virtual machines running under VMware’s vSphere management environment and VMware’s Nicira Network Virtualization Platform.

VMware は、OpenStack のプロジェクトに対して、いくつかのプラグインをコントリビュートしてきた。それは、OpenStack プロジェクトのネットワーク・プラットフォームが、VMware における vSphere のマネージメント環境および Nicira Network Virtualization Platform で動作する仮想マシンを認識し、また、協調動作することを保証するものである。

VMware acquired startup Nicira last July for $1.26 billion and has made its NVP the basis of future virtualized networking in what it terms "the software-defined data center." The Network Virtualization Platform from Nicira, a leader in OpenFlow network protocol concepts, is also the basis for the Quantum networking platform in OpenStack. Nicira was a heavy contributor to OpenStack before the acquisition, and it remains one now. At the OpenStack Summit on Tuesday, VMware gave these contributions a particular cast. Through close collaboration between Canonical and VMware, they will work inside the Ubuntu distribution of OpenStack, according to VMware’s VP of vSphere product management Joshua Goodman.

昨年の7月に、VMware は $1.26 billion を費やして、スタートアップである Nicira を買収した。そして、同社が Software Defined Data Center と定義する、将来の仮想ネットワークの基盤として、Nicira の NVP を位置づけている。Nicira は OpenFlow ネットワーク・プロトコル・コンセプトのリーダーでもある。 そして、同社から提供される、この Network Virtualization Platform は、OpenStack における Quantum ネットワーキンク・プラットフォームの基盤でもある。 VMware に買収される以前の Nicira は、OpenStack における重要なコントリビュータであり、それは、今も継続している。そして、火曜日(4/16)の OpenStack Summit で VMware は、それらのコントリビューションに特別な役割を与えた。VMware の VP of vSphere Product Management である Joshua Goodman によると、Canonical と VMware は、その緊密なコラボレーションを介して、OpenStack の Ubuntu のディストリビューションに手を加えてきた。

Suse Linux and Red Hat also have distributions of OpenStack. Red Hat’s KVM hypervisor is the one native to the OpenStack cloud open source code. Suse Linux is often cited as the version that works most closely with Windows Server and its hypervisor, Hyper-V. Both are keen competitors of VMware’s ESX Server.

SUSE LINUX と Red Hat も、OpenStack ディストリビューションを持っている。 Red Hat の KVM ハイパーバイザーは、OpenStack クラウド・オープンソース・コードに対するネイティブである。 SUSE LINUX は、Windows Server および、そのハイパーバイザーである Hyper-V と密接に連携するバージョンとして、頻繁に引用されている。そして、どちらも、VMware の ESX Server に対する強力なコンペティタである。

The move also reflects VMware’s growing realization that it is likely to need to live with many OpenStack implementations in the future, despite its early hopes that its own cloud software stack, the vCloud Director suite, would be the basis of private and public clouds everywhere. The collaboration with Canonical gives it an OpenStack partner that is less an immediate competitor than either Red Hat or Suse.

この動向は、VMware が達成したいと考える、未来像にも影響を与える。つまり、その初期で期待していた OpenStack 独自のクラウド·ソフトウェア·スタック(すべてのプライベート/パブリック・クラウドの基礎となる vCloud Director スイートを望んでいた)ではなく、数多くの OpenStackの 実装と共存していく可能性が高いことを意味する。Canonical とのコラボレーションにより、OpenStack パートナーに与えるものが生じるが、 Red Hat や Suse と比べれば、その影響は少ないものとなる。

VMware contributed the plug-ins for the Grizzly release of OpenStack, which came out April 4. Canonical has not yet included Grizzly in its version of OpenStack, but it plans to do so by the end of the month.

VMware は、4月4日にリリースされた、OpenStack Grizzly 用のプラグインも提供している。 現時点では、Canonical は Grizzly に対応したバージョンを持たないが、今月の末までには、対応する計画だという。

On Wednesday, Martin Casado, founder of Nicira and now chief architect of networking at VMware, posted a blog on the VMware website reading, "The transformation to the software-defined data center will take many forms, and VMware understands that many customers will want to piece together different technologies based on their requirements… "

この水曜日に、Nicira の Founder であり、VMware の Chief Architect of Networking でもある Martin Casado は、「 Software Defined Data Center に切り替えていく道筋には、いくつかの形態がある。 そして、数多くのカスタマたちは、その要件にしたがって、それぞれのテクノロジーを組み合わせたいきたいはずだと、VMware は理解している」と、VMware Web サイトのブログにポストしている。

He said VMware is committed to having its virtualization environment work with OpenStack, despite perceived competition between them, and VMware has "almost doubled the number of developers working on OpenStack" compared to Nicira’s previous level of contribution. Through its Nicira-acquired developers VMware was among the top ten contributors of code to the Grizzly release, he added.

彼の発言によると、OpenStack の仮想化環境における競合は理解しているが、そこに対して、VMware はコミットしていくことになる。そして、これまでの Nicira によるコントリビューションと比較して、VMware は「 OpenStack に対して 2倍のデベロッパーを投入している」と発言している。さらに、Nicira が獲得したデベロッパーを介して、VMware は Grizzly リリースに対して、Top-10 に入るだけのコードをコントリビュートしていると、彼は付け加えている。

[ Want to learn more about how VMware plans to work with the open source cloud project OpenStack? See VMware Does Complicated Dance With Open Source Code]

ーーーーー

imageOpenStack と Nicira、そして、VMware と Nicira。 この三者の関係が、これから、どのように整理されてくるのかと考えると、興味が尽きませんね。 昨年の7月に、『 VMware の言うクラウド選択の自由と、Nicira の買収は矛盾しないのか?』という抄訳をポストしましたが、その後に、VMware の OpenStack 参加があり、PayPal が VMware から OpenStack へ移行するという話まで出てきています。 その一方で Ubuntu は、中国政府との提携を進めるという、とても目を引く動きを見せています。 次には、どのような展開が待ち受けているのでしょうかね? image

ーーーーー

<関連>

VMware が OpenStack に参加って マヂ ですか?
ちょっと待ってね VMware さん – from OpenStack
待たせしました VMware さん – from OpenStack
OpenStack Summit から学ぶべき、5つのポイントとは?
Microsoft クラウド・パートナーが、そのメニューに OpenStack を加えた!
VMware から OpenStack へ : PayPal が 8万台のサーバーを移行させる

ネットワークの仮想化へ向けた論証 – 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枚のチャート

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人の チャレンジャー

 

 

 

 

 

VMworld – Maritz – レガシー・アプリケーションは、もう口紅では繕えない

Posted in .Selected, Events, PaaS, VMware by Agile Cat on August 30, 2011

VMware’s Maritz: No more putting lipstick on legacy apps
By
Derrick Harris Aug. 29, 2011, 6:39pm PT
http://gigaom.com/cloud/vmwares-maritz-no-more-putting-lipstick-on-legacy-apps/

_ Gigaom

Speaking to a jam-packed room of thousands, VMware CEO Paul Maritz kicked off today’s VMworld conference by declaring, once again, the advent of the cloud era. If you don’t believe him, just look at the numbers. As Maritz highlighted, there are now more virtual workloads deployed worldwide than there are physical workloads. There is 1 VM deployed every six seconds. There are more than 20 million VMs deployed overall.

今日、VMware CEO である Paul Maritz は、すし詰め状態になっている数千人のオーディエンスに、クラウド時代の到来を改めて宣言することで、VMworld カンファレンスをキックオフした。 もし、彼が信じられないなら、この数字を見るべきだ。 Maritz が強調したように、いまや、世界中に展開された仮想サークロードは、物理的なワークロードよりも多いのだ。 6秒ごとに、1つの VM がディプロイされていく。 そして、ディプロイされた全ての VM の数は、2000万以上に達しているのだ。  

Assuming that most of those are running atop some version of VMware’s hypervisor, there’s a lot of reason to care what Maritz has to say about the future of the cloud. His company will have a major role in defining the transition from virtualization to cloud computing.

それらの大部分が、VMware ハイパーバイザーの各バージョン上で実行されるなら、Maritz が語るクラウドの未来は、傾聴すべきものとなる。 そして、仮想化からクラウド・コンピューティングへ向けた移行の定義で、VMware は主要な役割を受け持つだろう。

Maritz noted that there’s a lot of hype around the cloud, even acknowledging that “We at vmworld are not immune to cloud fever,” but it’s more than just a fad, he said. Maritz thinks there are three very profound, and very real, forces driving the move to cloud computing: modernization of infrastructure; investment in new and renewed applications; and entirely new modes of end-user access.

Maritz は、クラウドの周辺に数多くの誇大宣伝があることを指摘し、「 VMworld に集まった私たちもクラウド熱に免疫がない」とさえ認めている。 しかし、単なる流行よりも、多くの事柄があるとも言う。 Maritz は、クラウド・コンピューティングへと向かう推進力について、きわめて深遠で現実的な、3つの事柄を考えている。それらは、インフラストラクチャの近代化であり、新規あるいは刷新されたアプリケーションへの投資であり、完全に新しいエンドユーザー・アクセス・モードのことである。

However, there’s a big difference between what drove the world to deploying 20 million VMs and what will drive it to modernize infrastructure even further with the cloud. Consolidation largely drove the move to virtualization, but applications and mobile devices will drive the move to cloud computing.

しかし、2000万の VM をディプロイしてきた推進力と、クラウドを見据えた近代的なインフラストラクチャをディプロイする推進力には、現実世界との距離感において、大きな隔たりがある。 仮想化への移行を、主として促進させたのはコンソリデーションである。 しかし、クラウド・コンピューティングへの移行をドライブするのは、アプリケーションとモバイル・デバイスになるだろう。

On the application front, Maritz looks to “canonical applications.” “When canonical applications change, that’s when you see really profound change [across the computing ecosystem],” Maritz said. He pointed to bookkeeping applications as indicative of the mainframe era, and to ERP, CRM and e-commerce as the defining applications of the client-server era.

そのようなアプリケーションの最優先項目として、 Maritz は「規範的アプリケーション」に目を向けている。 「規範的アプリケーションが変化するとき、ほんとうに深遠な変化が(コンピューティング・エコシステムの随所で)見えてくる」と、Maritz は言う。 彼は、メインフレーム時代の指標として経理アプリケーションを挙げ、また、クライアント・サーバ時代を特徴づけたアプリケーションとして、ERP/CRM/eCommerce を指摘した。

Real-time and high-scalability capabilities — both in terms of traffic and data — are driving the development of new applications. Being able to analyze data days after it’s generated, or to adapt to new traffic patterns within days, just isn’t good enough anymore. We can’t keep “putting lipstick around” current applications and expect them to meet these new demands, Maritz said.

リアルタイムとハイ・スケーラビリティの能力が、トラフィックとデータの観点において、新しいアプリケーションの開発を促進させている。 生成されたデータを数日内に分析することや、新しいトラフィック・パターンに数日内に順応することでは、もはや不十分である。 現在のアプリケーションに 「口紅をつけて」維持していくことや、新しい要求を充たしていくことには無理がある、と Maritz は言う。

How we write those applications also will be critical, because they’ll have to run on a variety of non-PC devices. We’re approaching the intersection of consumerization and next-generation enterprise IT, Maritz explained, which means that companies like VMware have to plan for very serious change. Running enterprise applications on consumer devices, especially of the mobile variety, is a big change.

それらのアプリケーションを記述していく方式も重要になる。なぜなら、それらのアプリケーションは、多様な非 PC デバイス上で動く必要があるからだ。 私たちは、コンシューマ化と次世代エンタープライズの IT 交差点へアプローチしており、また、VMware のような企業は、きわめて重大な変化に対して、きわめてシリアスに準備しなければならないと、Maritz は説明した。 エンタープライズ・アプリケーションを、コンシューマ・デバイス上で実行することが、とりわけ多様なモバイルで実行することが、大きい変化である。

They’ll have to embrace things such as HTML5 to enable cross-platform applications, and new programming frameworks to attract young developers that demand a simple, dynamic development experience. Companies will also have to figure out how to secure corporate data against the myriad threats that accompany employees downloading apps willy-nilly and operating often on unsecured (0r at least less-secured) networks. VMware CTO Steve Herrod actually will be highlighting VMware’s role in the mobile ecosystem at our Mobilize conference next month, and it’s safe to assume these will be among the topics he addresses.

たとえば、HTML5 のような、クロス・プラットフォームのアプリケーションと、新しいプログラミング・フレームワークを受け入れなければならないだろう。それにより、シンプルでダイナミックな開発エクスペリエンスを求める、若いデベロッパーたちを惹きつける。 企業サイドとしても、コーポレート・データを無数の脅威から守る方式について、理解しなければならないだろう。その時には、従業員によるアプリケーションのダウンロードを否応なく受け入れ、時には、セキュアとは思えない(少なくともセキュリティ・レベルが低い)ネットワーク接続が生じることになる。 VMware CTO である Steve Herrod は、来月に Gogaom が主催する Mobilize カンファレンスで、モバイル・エコシステムでの VMware の役割を強調し、彼が取り組むトピックにおいて、それらがセキュアだと推測するだろう。

Maritz, of course, thinks VMware has strong plays in all of these spaces — vSphere, Cloud Foundry, Horizon, the list does on — and he highlighted them. However, as my colleague Stacey Higginbotham pointed out while highlighting the key VMworld trends, VMworld isn’t alone in making this realization. It has major competition, including from companies like Microsoft that know both the enterprise and the consumer spaces very well.

もちろん Maritz は、それら全ての空間で VMware が力強く機能していると考え、また、vSphere/Cloud Foundry/Horizon といったラインアップを強調した。 しかし、私の同僚である Stacey Higginbotham が指摘するように、VMworld のキートレンドを強調しても、こうした変革は VMworld 単独で達成できるものではない。つまり、エンタープライズとコンシューマの領域で、広く認識されている Microsoft などと、大きな戦いを繰り広げなければならないのだ。

Every year at VMworld, Maritz highlights the movement toward cloud computing and how VMware is driving that migration. In large part, he’s right every time on the latter point. Now that almost everyone is on board with Maritz’s vision, though, I’m interested to see how long VMworld, and VMware in general, continues to drive the discussion around the future of IT.

VMworld では毎年、 クラウド。コンピューティングへ向けた移行と、それを促進する VMware を、Maritz が強調してきた。 大まかなところで、彼が指摘するポイントは、つねに正しい。 いまでは、ほとんどの人々が Maritz のビジョンに乗っているが、どれだけ長く VMworld と VMware が魅力的であり、また、未来の IT をめぐる論議を促進させるのか、その点に私は興味を覚える。

Related research and analysis from GigaOM Pro:

 

 

ーーーーー

imageこれと言って、VMware を贔屓するつもりはありませんが、Maritz の話を楽しみながら、未来の IT を想像するのは、とても楽しい事です。 Ray Ozzie が愛想を尽かして辞めてしまってからというもの、次のオピニオン・リーダ-は誰にと、すこし心配してしまいましたが、さすが Paul Maritz、たいしたものという感じです。引き続き、VMworld に注目していきたいです。 ーーー  __AC Stamp 2

ーーーーー

<関連>

Dell クラウドの 第一弾は VMware に決定! 第二弾で Azure と Openstack
VMware が目指す、クラウド OS への道とは?
VMware による仮想化の実績を、インフォグラフで視覚化する
VMware は Socialcast を買収し、その SaaS 戦略にマイクロブログを加える
NYSE と EMC と VMware が、ウォール・ストリートに浮かべるクラウドとは?
VMware を分析すると、OS を持たない 新しい Microsoft に見えてくる
Dell は OpenStack を、Lotus 1-2-3 のように簡単にする!

 

未来派 クラウド OS を、かたちにする Joyent とは?

Posted in .Selected, Joyent by Agile Cat on August 17, 2011

Joyent launches a new OS for the cloud
By Stacey Higginbotham Aug. 15, 2011
http://gigaom.com/cloud/joyent-launches-a-new-os-for-the-cloud/

_ Gigaom

Joyent, the company behind private cloud software and the Node.js event-driven programming language, has open-sourced its cloud operating system. Called SmartOS and already utilized in Joyent’s public cloud and SmartDataCenter private-cloud software, it will be available via an open-source license much like the Joyent-led Node.js effort is, says Joyent CTO Jason Hoffmann.

プライベート・クラウド・ソフトウェアと、Node.js イベント駆動型プログラム言語を支える Joyent は、そのクラウド OS をオープン化している。それは SmartOS と呼ばれ、また、Joyent パブリック・クラウドと、SmartDataCenterプライベート・クラウドにおいて、すでに利用されている。そして、Joyent がリードする Node.js のケースのように、オープンソース・ライセンスにより利用できるようになると、Joyent の CTO である Jason Hoffmann は発言する。

Jason Hoffman ⇒

Hoffman calls SmartOS the “only modern OS,” and the only new one developed in about a decade. In a conversation with me, he went through the details of SmartOS as well as the changes occurring in IT that merit a new operating system.

Hoffman は SmartOS のことを「 唯一の近代的な OS」と呼び、また、この 10年で開発された、唯一の新しい OS だとする。 私との会話の中で彼は、SmartOS の細部を説明するだけではなく、新しいオペレーティング・システムにメリットをもたらす、IT に起こりつつある変化についても言及した。

Regardless of what the rest of the world thinks of the offering, Joyent will be using SmartOS as part of its cloud buildouts for companies, including telecommunications firms; it is more efficient and more secure because it offers a container model. From the release:

Hoffman は SmartOS のことを「 唯一の近代的な OS」と呼び、また、この 10年で開発された、唯一の新しい OS だとする。 私との会話の中で彼は、SmartOS の細部を説明するだけではなく、新しいオペレーティング・システムにメリットをもたらす、IT に起こりつつある変化についても言及した。Joyent のオファーに対して、その他の世界が何を考えるかには関係なく、Joyent はSmartOS を、顧客となる企業のクラウドを形成する、パーツとして利用していくだろう。それらの顧客には、テレコム企業も含まれるが、コンテナ・モデルが提供されるため、さらなる効率と安全が実現される。 以下は、同社のリリースから:

Joyent is the only vendor that offers enterprises and developers the best of both virtualization worlds in a single operating system: One can employ hardware virtualization with KVM when there are operating system dependencies, and operating system-level virtualization when the language runtime is important, as in a Platform as a Service (PaaS) or Software as a Service (SaaS) offering. With Joyent’s operating system-level virtualization, companies are able to host more users on a single server, realizing greater efficiency and increased revenue potential while saving on unnecessary hardware investments.

Joyent は、エンタープライズとデベロッパーの両者に対して、シングル OS によりベストな仮想化の世界を提供する、唯一のベンダーである:OS への依存性があるときには、KVM を用いたハードウェア仮想化を利用できる。 そして、開発言語ランタイムが重要なときには、OS レベルの仮想化を利用できる。さらに、それらは、SaaS においても PaaS においても、同様に提供される。 Joyent における OS レベルの仮想化を用いれば、顧客となる企業は、シングル・サーバー上に、これまで以上のユーザーをホストできる。それにより、不要なハードウェア投資を抑えながら、さらなる効率化と、増収の可能性が得られる。

Because it is open source, anyone can license it if they like. Hoffman says Joyent open-sourced the OS because it was good, and Hoffman believes in offering high-quality tools back to the community and “making the world a better place.”

それがオープン・ソースであるが故に、それを望む誰もが、それを利用できる。 そして、良いものであるから、この OS を Joyent はオープン・ソースにしたと Hoffman は発言する。 そして、さらに、高品質のツールがコミュニティを支え、[ この世界をもっと良い場所にする」と、Hoffman は信じている。

So what exactly is SmartOS? It’s an OS for servers akin to Windows Server or RHEL from Red Hat, or VMware’s ESX. Here is a breakdown of the OS package:

正確にいうと、SmartOS とは、どのようなものなのだろう?それは、Windows Server と同類と言えるし、Red Hat に基づく RHEL や、VMware の ESX とも同類だと言える。以下に、この OS のパッケージ分類を示す:

  • KVM Hypervisor: for abstracting the software from the underlying hardware
  • DTrace: for troubleshooting and systems monitoring
  • ZFS file system: to connect the servers to a variety of storage systems

KV-what? Just tell me why this is happening!

_ joynetMore than what it is, a more interesting question about this is, Why? While some might point to Android or iOS as entirely new operating systems, Hoffman has a more narrow view and is thinking in terms of servers and webscale applications. But Smart OS tries to build on that to take advantage of the virtualization hooks now built into chips and then looks ahead. As I see it, SmartOS could take advantage of the following trends:

それが何かという質問よりも、それは何故かという問のほうが、興味深くないだろうか? 何人かの人々は、Android や iOS を、まったく新しい OS として指摘するかもしれないが、Hoffman は、さらに絞り込んだ視界を持っており、サーバーと Web スケール・アプリケーションについて考えている。 そして、まさに Smart OS は、いまではチップに実装されている仮想化のアドバンテージの上に構築され、さらなる未来を見つめている。 私の観点からすると、SmartOS は、以下のトレンドを活用することが見えてきた:

  • A flatter network architecture inside the data center. By using ZFS, which allows data-center architects to connect a variety of storage to their servers, the Smart OS falls in line with those toward more commodity gear and less hierarchy in the data center. Where there was once a fine line between servers and storage, that line is blurring as companies want faster access to stored data.
  • ZFS を用いることで、各種ストレージとサーバーを接続するための、データセンター・アーキテクチャを実現すしていく。 そして、Smart OS は、データセンター内のコモディティ製品に浸透させ、階層を減らしていく。 かつて、サーバーとストレージの間に、紙一重の違いがあった場合、ストレージ・データへの高速アクセスが望まれるにつれて、その境界線が曖昧になっていった。
  • Distributed compute nodes. The addition of DTrace helps sys admins see where issues might arise in their architectures when they are running SmartOS, and because they can see them, theoretically they can solve those issues quickly, making it faster and easier to build out distributed nodes.
  • DTrace を追加することで、SmartOS を実行する個々のアーキテクチャに生じる問題を、システム管理者が探し易くする。そして、それらを発見した後に、問題を論理的かつ迅速に解決することが可能となり、その結果として分散型ノードを、さらに短期間で容易に構築させる。
  • The rise of embedded devices. SmartOS only requires 128 MB of RAM to boot, which means it can be used for a variety of smaller gadgets such as digital signs, set-top boxes and even high-end sensors. Looking ahead, having an OS that can work at both the data-center level and on sensors in the field enables a sensor-rich network.
  • SmartOS のブートに必要なのは、128MB の RAM に過ぎない。 したがって、デジタル・サインや、セット・トップ・ボックス、ハイエンド・センサーといった、多様で小型のガジェットにも利用できる。 将来を見据えて、データセンターとフィールド・センサーの双方で機能する OS により、センサー・リッチなネットワークを実現していく。
  • The acceptance of virtualization. The KVM hypervisor aspect of SmartOS takes advantage of virtualization hooks that chip makers have been including in their silicon for the past few years. This makes it run faster and more efficiently. Other hypervisors also take advantage of these hooks but in their second- or third-generation versions.
  • SmartOS における KVM ハイパーバイザーのアスペクトは、この何年かの間にチップ・メーカーがシリコンの中に取り込んだ、仮想化のための Hook を活用するものとなる。 それにより、されに高速で、効率のよい環境が実現する。 もちろん、他のハイパーバイザーも、これらの Hook を利用するが、その 第2世代あるいは、第3世代のバージョンでとなる。

Joyent launched SmartOS soon after VMware upset some of its customers by changing its VSphere licensing model. Although it changed the pricing in response to customer complaints, it’s possible that SmartOS could rise in popularity as folks become disenchanted with VMware, although there are still other options available. For more on SmartOS, check out the page dedicated to it.

VMware が、VSphere ライセンス・モデルを変更したことで、その顧客に若干の動揺がが走った直後に、 Joyent は SmartOS を立ち上げた。 WMware は顧客からの苦情に応えるかたちで、その価格設定を変更したが、人々が VMware に幻滅するなら、その他の選択肢の中から、SmartOS が急上昇する可能もある。 SmartOS の詳細については、以下のページでチェックして欲しい

Related research and analysis from GigaOM Pro:

 

 

 

ーーーーー

Amazon-EC2-Comparison1-525x389いままで、ずっと気になっていた Joyent ですが、ようやく、概要を説明する記事に出会って、とても嬉しいです。 今年の初めに、Jack of all Clouds で存在を知りましたが、4月には ProgrammableWeb が、右のグラフにあるような、Joyent の強烈なパフォーマンスを説明するにいたりました。 その時にも、訳しておきたいと思ったのですが、手付かずで今日まで来てしまいました。 この Gigaom の記事を読むと、AWS との違いや、このフラフが示すデータの、裏付けも分かってきます。 なお、vSphere 対抗とのことですが、同じフィールドには Citrix もいれば、Red Hat もいます。  そんな強敵を相手にして、どこまで Joyent が頑張るのか、興味シンシンといったところです。ーーー __AC Stamp 2

ーーーーー

<関連>

VMware が目指す、クラウド OS への道とは?
NYSE と EMC と VMware が、ウォール・ストリートに浮かべるクラウドとは?
Amazon AWS が Equinix に、ハイブリッド用のダイレクト接続を提供
OpenStack は商用化へ向けて準備を整える
この一年で、OSS への支出が 56% に跳ね上がった

%d bloggers like this: