仮想化ベンダーの守備範囲はどこまでか！ －クラウドの今後はどうなる（1）－

シリーズでマルチハイパーバイザー管理のクラウドマネージメントについて述べてきた。
そこでホットになりつつあるクラウドマネージメントソリューション市場を起点に、今後、クラウドがどのような方向に向かうのか、そのポイントについて纏めてみようと思う。クラウドマネージメント市場の形成には幾つかの背景がある。まず、①ユーザー企業の環境を見ると、仮想化でVMwareが絶対優位とは言っても、Xen、Hyper-V、そしてKVMの登場で、複数のハイパーバイザーを利用する時代になってきた。そして、必然的な結果として、②ユーザー企業は仮想化ベンダー固有の技術に縛られることを好まず、仮想化技術を抽象化したいと考えは始めた。これが“Cloud Management Solution”開発が活発になってきた理由である。


◆　仮想化ベ ンダーはハイパーバイザーに留まるべきだ
つまり、仮想化はハイパーバイザーとしてOSに含まれる機能だが、上位のミドルウェアやアプリケーション領域とは関係がない。これがユーザー企業の声になりつつある。MicrosoftのWindowsにHyper-V、Red HatのKVM、そしてまだ噂の域を出ないが、VMwareによるNovellのSUSE部門買収が現実になれば、SUSEにVMwareとなる。
実際のところ、今年6月中、VMwareはNovellと提携し、7月中旬からリリースの始まったvSphere4.1からSUSE Linux Enterprise Server（SLES）が同梱されている。そして、8月30日からのVMWorld 2010では“Novell SUSE Linux Enterprise Server for VMware”の提供を開始すると宣言した。これはVMware用にチューニングしたSUSE Linuxを出荷し、合わせてSUSEのサポートもユーザーに提供するというものだ。ここまでくると、買収が不首尾に終わっても実質的には同じだ。このように仮想化とOSのタイトな関係が深まれば、次の問題として、それらを抽象化するクラウドマネージメントの必要論が出てきておかしくない。
今、我われはこの時点にいる。

◆ 　仮想マシンOSとアプライアンス
またハイパーバイザーと関連して、仮想マシンOSとアプライアンスの関係も重要だ。
現在、アプライアンス用の軽量化されたOS－JeOS（Just enough OS）には、rPath、Ubuntu JeOS、Red Hat Appliance OS、SUSE JeOS、LimeJeos、Oracle Enterprise Linux JeOSなどがある。初期のJeOSはソフトウェア・アプライアンスの作成が主目的だったが、現在では仮想マシン上で容易にソフトウェアを扱う方法と して成長してきた。これに伴いISVが適用するソフトウェアも、これまでのライセンス付きインストールものから、マシンイメージものが増えてきた。 Microsoftは今のところ沈黙だが、改良版Windows Starterがこの範疇として登場するか、一時噂だったMidoriなどが登場する可能性も否定できない。
アプライアンスの作成ツールでは、こ れまでrPathのrBulderが市場をリードしてきた。
そしてNovellやVMwareも熱心だ。VMwareはVM Studioを提供してvAppsライブラリーの整備を進め、NovellもSUSE StudioでSUSE Appliance Programを推進してきた。しかし事情が変わり、VMwareではvAppに最適なものとしてSUSE JeOSを採用することが既定路線となったらしい。

◆　OSと仮想 化ベンダーの一体化
こう見ると、期待されていることは、OSと仮想化ベンダーのより一層の一体化である。
特にVMwareとNovellの関係が要注意だ。この買収が成功すれば、エンタープライズ領域のOSベンダーの一体化が完了する。その結果、データセンター側ではハイパーバイザー、仮想マシン上ではJeOSとアプライアンスの整備が進む。さらにハイパーバイザーと仮想マシンOS間の機能連携強化の可能性も出てくる。現在の仮想マシンOSは、スタンドアローンOSの転用で本格的なクラウド時代にはややそぐわない。同様にJeOSもアプライアンスの転用である。大事なことは、開発自体はほぼオンプレミスで行い、実行の多くが仮想環境となる点だ。勿論、実行環境では、オンプレミスと仮想マシンの完全な互換性は必須である。このような視点から、仮想マシンOSの整備が進めばユーザーは、大きなメリットを享受できる。

◆　現実はどうか？
ベンダー競争の現実は厳しい。理想的な機能よりも、売上げが先だ。
特に仮想化市場を牽引するVMwareは、これまでの実績をベースに、より上位領域に手を広げてきた。クラウドインフラとなるvCloudやSaaS領域のSpringなどだ。この動きはCitrixやRed Hatも同様である。しかし、ここに来て、ハイパーバイザーを抽象化するクラウドマネージメント製品やクラウドインフラなどが複数のベンダーから登場し、 軌道修正が必要な時期に来ている。クラウド市場は、第2ラウンドに入り始めた。彼らがどう動くのか注目である。

スペインからやってきたAbiquo －クラウドマネージメント(4)－

Abiquoのデモを始めて見たのは3年も前だ。
当時のデモは画面上で機器構成を描き出すツールのようだった。同社はもともとスペインが本社。スペインと言えば、クラウド構築ツールOpenNebulaのようにクラウドが盛んなところである。当時はスペインから米国にカンファレンスのたびに出向いていた。その時のプロトタイプと現在の製品は殆ど別物だが、技術は継承されて部分的に組み込まれているようだ。その後、クラウドの波に乗り、2009年にクラウド管理ツールのα版、2010年2月、オープンソースのCommunity Editionをリリース、そして3月、Redwood Cityに米国本社を開いてシリコンバレーにやってきた。

◆　Abiquoとは
Abiquoの製品には前述のオープンソース版（Community Edition）とEnterprise Editionの2つがあり、共に以下のマルチハイパーバイザーを管理する。この分野にはこれまで報告してきたように色々な製品が登場してきたが、Abiquoの特徴は、実存する殆どの仮想化技術をサポートしていることである。実際には、以下のような製品が提供するAPIを利用し、異なる仮想化技術が搭載されたサーバーのプロビジョニングを実行する。

• VMware ESX and ESXi
• Microsoft Hyper-V
• Citrix XenServer
• Virtual Box
• Xen
• KVM

◆　Abiquoの構造
Abiquoのコンポーネントは下図のように大きく分けて3つ。
①マルチハイパーバイザー管理の“Abiquo Server”、②マシンイメージを変換する“OVF Repository Space”、そして③運用管理用の“Abiquo Portal”だ。


要となるAbiquo Serverは、異なる仮想化技術が適用され、実際にはバラバラに設置されている物理サーバーを論理的に管理する。ユーザーはこのAbiquo Serverを介して仮想マシンのCPUやメモリー、ストレージなどの容量を決める。

次にOVF Repository Spaceでは、DMTFが定めたOVF(Open Virtual Format)を用いて、各社固有のマシンイメージをDrag & Dropで変換することができる。実際の処理は、OVFはラッパーなので、変換にはこのラッパーを解いて、各社が用意している変換ツールが内部的に実行されている。


システム管理のAbiquo Portalを見ると、同社が初期に開発していたビジュアル機器構成管理ツールが進化したことがわかる。これが同社のウリのひとつである。機能的には、①物理構成を管理する“Infrastructure”、②複数台の仮想マシンをデータセンターに見立てる“Virtual Datacenter”、
③アプライアンスなどのアプリケーション管理“App Library”、その他“Users”や“Events”などの管理ツールが用意されている。

◆　ユーザー調査に見るIT部門とユーザーの意識差
次にAbiquoの特徴を伺い知るために、同社がDownloadユーザー2万社に行ったユーザー調査（8月末）を見てみよう。それによると、今日のクラウド利用には以下のような５つの課題がある。まず、1)のSecurityやComplianceについては、他の調査でもほとんど同様の指摘があるので割愛するが、5)は、仮想化やクラウド技術による囲い込みが進み、ユーザーにとっては大きな懸念材料となっている。

1) Security and Compliance

2) IT Organization Overload

3) Lack of Visibility into Virtual Environments

4) Unrealized Utilization Improvements

5) Vendor Lock-in

さらに2)～4)は、仮想化されたクラウド環境を提供するIT部門と利用ユーザー間にかなりの意識差があることがわかる。2)は、現在の不況下のコスト削減から、仮想化によるサーバー統合やクラウド利用は進むが、IT部門には大きな負担となり、負担軽減の効果的なツールが求められている。さらに3)では、仮想環境の透明性が低く、4)利用率向上が進んでいない。その結果、一度使った仮想マシンやストレージがそのまま放置されており、ここでも有益なツールが必要となっている。

つまりこれらの課題を解決するのがAbiquoだということで、我田引水の感は否めない。しかし、それはそれとして、クラウドが動き出した後のこのような問題指摘は謙虚に受け止めるべきだろう。このブログで、数回にわたって紹介しているクラウドマネージメント製品が活況なのは、このような理由だからだ。

Novell Cloud Manager －クラウドマネージメント(3)－

9月13日、NovellからCloud Managerの出荷が始まった。
これは 今年5月、マルチハイパーバイザーのクラウド管理ツールとして、欧州中近東、アフリカ向けBrainShare EMEA 2010でデモが披露されたものだ。Novell Cloud Managerは、より正確には昨年末にプリアナウンスがあったPlateSpinの機能追加プロジェクトAtlanticとBluestarがベースと なっている。

◆　物理/仮想マシンを連携するPlateSpin
PlateSpin は2008年Novellが買収した会社で、それまでVMwareのパートナーとして、物理環境と論理環境を相互移動させる運用管理ツールを開発してい た。この製品は、任意の物理マシン上のソフトウェアをImage Archiveとしてマシンメージファイルに落とし、それを仮想マシンに移して実行する。当然だがこのような製品は、現在の仮想化やクラウ ドには欠かせない。少しPlateSpinを復習しよう。通常のシステム移行ではPhisical Server （物理マシン）からImage Archiveへ「P2I」で実行ファイルを確保し、それを「I2V」でVirtual Machine（仮想マシン）に移して実行する。直接「P2V」での実行も可能だが、転送するバンド幅や処理時間、本番テストなどを考えると「P2I」→ 「I2V」の流れが自然だ。PlateSpinには、多様な機能があるが、PlateSpin ReconとPlateSpin Migrateがコア製品だ。Reconは物理マシンから仮想マシンへの移行情報を収集し て移行シナリオを描き出し、Migrateが前述のような実際のイメージファイル処理を実行する。

◆　登場したCloud Manager 1.0
今回リリースされた Cloud ManagerはPlateSpinによるシステム移行を受けて、その後のクラウド実行環境を運用管理する。対応する仮想化技術はXen、VMware、 そしてHyper-Vだ。KVMについては来年上期の予定だ。つまりマルチハイパーバイザー管理コンソールである。この分野ではEnomalyがやや先行しているがまだ実績に乏 しく、新しい市場（Cloud Management Solution）と言っていい。ユーザーはこれまでどの仮想化技術を使っているかで、運用管理も異なっていた。EnomalyやNovell Cloud Managerはこれまでの主戦場だった仮想化技術を抽象化し、ユーザーは仮想化技術を意識することなく、混在状態の運用管理が可能となる。


Cloud Managerは、コストを意識した実行仮想マシンのテンプレート作成にも威力を発揮する。まずアプリケーションを実行するには“Business Service”のテンプレートを作成する。その実行環境（CPU、Memory、Disk）となる情報は、逐一作成するのではなく、あらかじめ用意され た“Workload”カタログから適当なもの利用する。この際、必要があれば修正し、後はCloud Managerが自動的にLicenseの承認やAdminの許可を受けて仮想マシン上で実行する。Cloud Managerはテンプレート作成段階で、利用リソースのコスト見積もりはもちろん、多くのソフトウェアアプライアンスを揃え、それらのLicense /Utility費用も表示してくれる。


◆　クラウドライフサイクルのWorkload IQ
Cloud ManagerはNovellのProduct Portfolio全体からみるとWorkload IQの 一部である。このWorkload IQとは、ビルド（Build‐構築）→セキュア（Secure‐安全）→マネージ（Manage‐管理）→メジャー（Measure‐評価）の4つの分 野をカバーするクラウド・ライフサイクルとして整備が進められているも のだ。ビルド段階ではハイパーバイザーベースのSUSE、仮想マシン上の軽量JeOS、アプライアンス作成のSUSE StudioやAppliance Toolkit、ソフトウェア自動更新のNovell ZENworksなど、セキュア分野ではNovell ID/Access Manager、Access Governance Suite、Privileged User Managerなどを使用する。運用管理段階では、前述したPlateSpinとCloud Managerがセットとなって仮想環境とWorkloadを管理し、評価段階ではNovell SentinelやLog Managerが効果的だ。

こ うして、クラウドは初期の仮想化技術を抜け出した。
Cloud ManagerはXenやVMware、Hyper-V、KVMなどに捕らわれずにクラウドを運用管理し、さらにクラウドの構築／安全性／運用管理／評価 などライフサイクル化するところまできた。同様の傾向はマルチハイパーバイザーではないがクラウド運用管理のVMware Directorにもみることができるし、MicrosoftのSystem Center Virtual Machine ManagerではHyper-VとVMware環境が管理でき、来年投入の次期版ではCitrix XenServerにも対応する。いよいよ、本格的なクラウド時代の到来である。

参考記事：　実行環境管理のPlateSpin　－クラウド運用管理2－　
　　　　　　　マルチハイパーバイザー管理コンソールのEnomaly

共通APIでクラウド連携を目指すDeltacloud －クラウドマネージメント(2)－

ApacheのDeltacloud Projectは、現在インキュベーションステージにある。
元はRed Hatが始めたものをApacheに寄贈したのが始まりだ。Deltacloudは2009年9月始めのRed Hat SummitでProject Hailと共に発表された。Hailはプログラミング言語やOSに依存しない可用性の高い分散コンピューティングを目指し、もうひとつの Deltacloudは現存する複数の有力クラウド間の差異を抽象化する。この2つによって、デベロッパーは真に自由になり、クラウド上でのアプリケー ション開発に専念することが出来る。

◆ Apache Deltacloud Project
Red Hatの寄贈したDeltaCloudは今年5月に、プロジェクト準備となる“Incubation Stage”に入り、現在最終調整が進められている。DeltacloudのようにApacheには
ベンダーが開発した多くの案件が持ち込まれ る。Apacheでは、これらの中からオープンソースとしての有用性を判断し、且つ、既存Apacheプロジェクトとの関連、さらに大事なことは持ち込ん だベンダーの言い分だけでなく、競合相手などの異なる意見を聞き、その上でプロジェクトを興すかどうかを判断する。そして実行にあたっては、プロジェクト マネージメントとデベロッパーの構成が重要となる。一般にコードを持ち込んだベンダーが自社社員をそのまま提供するケースが多いが、これだけでは公平な作 業としてリスクがあるので他のデベロッパーの参加を募り、かつマネージメントは経験あるApacheメンバーから出す。こうしてプロジェクトの全景が描き 出せればスタートだ。


◆ Deltacloudとは何か
さ てDeltacloudの仕組みを見てみよう。Deltacloudは既存クラウドを抽象化して、同一に扱えるようにする試みだ。そのためにデベロッパー には仮想マシンのスタート／ストップなどのREST APIを提供する。デベロッパーはこれらのAPIを使ってクラウドプロバイダーを意識することなく、仮想マシンの制御ができる。そして、それらのAPIは Amazonなどのクラウドプロバイダーが提供する本来のAPIに翻訳されて実行される。DeltacloudではRest APIからNative APIに変換するコンポーネントをドライバーという。

もちろんドライ バーの論理的な数は、対応するクラウドと制御動作の種類を乗じたものになるが、物理的にはどこまで束ねるかに依存する。現在のコードで対応しているクラウ ドはAmazon(Xen)、GoGrid(Xen)、OpenNebula(Xen/KVM)、Rackspace(Xen)、RHEV- M(KVM)、RimuHosting(Xen)、Terremark(VMware)、vCloud(VMware)の８種類だ。括弧内は採用している 仮想化技術であり、聞きなれないRimuHostingはオーストラリアのプロバイダーである。クラウドの制御機能はComputeとStorageに分 れ、ComputeではInstance(仮想マシン)のCreate(作成)、Start(起動)、Stop(停止)、Reboot、Destroy、 Hardware Profileなど９種類。Storageは当初のAmazon S3とRackspace CloudFilesに、Windows AzureとGoogle Storageが追加されることになった。ストレージのAPIは構造化された一般ファイルと、ストリーミングなどのの非構造化データを扱うBlobがあ る。


◆ DeltaCloudをDMTFに標準化要請したRed Hatの思惑
さ てその後、２つの動きがあった。ひとつは今年6月末のRed Hat Summitで発表したCloud Foundationの続編だ。このCloud Foundationとは、パブリックやプライベートクラウド構築をツールからトレーニングまで総合的にサポートするプログラムで、これにはRed Hat Enterprise Virtualization(RHEV)やJBossなどが含まれていたが、さらにDeltacloudを加えるというものだ。そしてもうひとつは8月 27日、同社はDeltacloudをDMTF（Distributed Management Task Force）に標準化として申請し、Working Groupに参加すると発表した。

これら一連の動きを見ていると慌しい感じがする。
Red HatのKVM実装が正式に登場したのはちょうど１年前のRed Hat Summitだ。
このバージョンはRHEL 5.4だった。そして半年後の今年3月末にRHEL 5.5、さらに4月26日にはRHEL 6βをリリースした。事前の予告とおりこの6βにはKVMのみでXenは含まれていなかった。問題は何時RHEL 6が正式にリリースされるかである。というよりは、周りの環境整備がいつまでに揃い、先行するVMwareやCitrixと戦う体制になるかだ。そうでな ければ6だけ出してもユーザーはついて来ない。単純に製品だけみれば、要となるのは運用管理のRHEV-M（Red Hat Enterprise Virtualization Manager）だ。
しかし、これだけでは後発として何とも歯がゆい。VMware Infrastructure 3の数年前と同じだからだ。その後、VMwareは改良型のvSphare 4を出し、クラウド構築vCloudの整備、Spring FrameworkによるSalesforce(VMforce)やGoogle(Google App Engine Business Edition)との提携をものにしている。Citrixにしても、基軸のXenがXen 4になり、XenServer（サーバー仮想化）とXenCenter（運用管理）はXenServer 5.5から統合されて無償化となった。さらにXen Clientを発表し、XCP(Xen Could Platform)の開発も進んでいる。追う立場のRed HatにとってDeltacloudはだからこそ大事なのである。気がかりは、ApacheとDMTFへの対応だ。同社としては既にApacheプロジェ クト立ち上げの見通しが立ったとの判断から、DMTFへの標準化を申請したのであろうが、もう少し丁寧な取り組みが必要なようにも思う。いずれにしても RHEL 5のXenは2014年まで5年間サポートが続けられるので、それまでが勝負である。

IaaSプラットフォームCloud.comの選択

Cloud.com（旧VMOps）はSunでJVM（Java Virtual Machine）のリードデベロッパーだったSheng Liang氏が2008年に立ち上げたスタートアップだ。設立以来の社名はVMOps。Liang氏の経歴と社名、プリアナウンスなどからクラウド企業で あることはわかっていたが、詳細は解らずStealth Modeが続いていた。

◆　クラウド第1ステップへ（CloudStackの発表）
今年5月4日、Series Bの$11Mの資金(Series Aは$6.6M、これまでの合計$17.6M)を受け、社名もCloud.comに変更。そしてStealth Modeを抜けて、第1ステップへと踏み出した。CloudStackの発 表である。CloudStackはPrivateはもちろんPublicのIaaS構築のツールとして、Enterprise EditionとService Provider Edition、さらにCommunity Editionの３つがある。もっとも当面は、Open SourceのCommunity Editionを基本とし、次にEnterprise、そしてService Providverの順に開発を行う。Community版はUbuntuやFedora上で稼働し、仮想化技術はXenとKVMをサポートする。計画に よるとEnterpriseやService Provider版の仕組みはかなり大掛かりなもので、ゾーンと呼ばれる複数のサーバー群をIaaSプラットフォームとして含めることができる。このゾー ンはデータセンターと考えても良い。つまり、複数データセンターをひとつのクラウドとして管理することが出来る。さらにこれらのサーバー群を管理する Management Serverは主たるPrimaryとバックアップ用のSecondaryの設定が可能だ。

◆　クラウド第２ステップへ（OpenStackへの参加）
７月２１日、Cloud.comは OpenStack initiativeへ参加すると発表した。 OpenStackの発表は７月１９日、２日後のことである。CloudStackの目指すオープンソースのIaaSプラットフォームと、 Rackspaceが主導してNASA Ames Reseach Centerと組んだOpenStackは、ある意味では完全な競合関係にある。このプロジェクトではRackspaceのObjectベースのクラウド ストレージCloud FilesとAmes Research Centerが進めているMebulaのクラウドコンピュートNovaの採用が決まっており、９月から１０月にかけて初期版がリリースされる。 RackspaceはAmazonに次いでクラウドでは第2位の実績があるし、NASAのNebulaは大掛かりなプロジェクトだ。問題は、 Cloud.comがOpenStackにどのように取り組むかである。同社によると、短期的にはRackspaceのObject StorageをCloudStackに採用し、併せてOpenStack APIも適用する。

◆　クラウド第３ステップへ（サクセスストーリーになれるか）
その後の中長期計画では、Cloud.comの影響力を拡大し、同社のユーザー に代わってOpenStackにコードの貢献をする。つまり、OpenStackにCloudStackのコードを提供して、Rackspaceと NASA Amesだけでなく、Cloud.comもコアメンバーになって、オープンソースIaaSプラットフォームの普及に尽力するというわけである。このストー リーを裏打ちするように、これまでのXen/KVM対応から、8月25日、VMwareのvSphere4のサポートも公表し、さらにAmazon Web ServicesやCitrix Cloud Center(C3)、VMware vCloudの各APIもサポートすると発表した。

◆　Amazon .vs. Rackspace
デベロッパーの一部は AmazonとRackspaceが対立関係にあることに気付いている。Amazonのサービスは機能的で優れているけれど、基本構造はモジュール型で、 これらは標準仕様ではなく、Proprietaryな感じを受ける。そして利用料金も決して廉くない。翻って、Rackspaceは低価格で仮想マシンを 提供し、その上では何もしない。つまり何の制約もなく、デベロッパーもISVも自由に仮想空間を利用できる。一方でIaaSの基盤となる Rackspace Cloud ServersとFilesのAPIを整備して公開してきた。これによって、iPhoneから仮想マシンを走らせたり、興味あるISVは Rackspace周りの製品整備を始めた。その上でServersとFilesのオープンソース化を実行し、より一層の普及のため、NASA Amesに協力を求めてOpenStackを組織化したという流れである。米国クラウド市場で１番のAmazonと２番のRackspaceの戦いは激し くなってきた。追うRackspaceの錦の御旗はOpenStackだ。現在プロジェクトに参加している30数社の動機はバラバラだが、 Cloud.comのように生き残りを賭けているところもあり、NASAの影響力も大きい。Nebulaプロジェクト独自開発のNovaが上手く動き出せ ば、Eucalyptusも危うくなる。それらを味方につけることが出来れば、状況は動きだす。

関連記事：連邦政府のクラウド推進計画(3)－Data.govからNASA Nebulaまで－

Private CloudのAmazonを狙うNimbula －クラウドマネージメント(1)－

設立以来、ステルスモードだったNimbulaが動き出した。
この会社がどのような製品を出すのかずっと見守ってきた。というのは、この会社の創業者で現CEOのChris Pinkham氏と仲間のWillen van Biljon氏（現VPプロダクト担当）に注目していたからである。

◆　Amazonクラウドを考え出した男たちのStart-up！
今日のクラウドは、2006年、Amazonが発表したS3（2006/3）とEC2(2008/8)で始まった。そのクラウドを考え出したのはPinkham氏だ。氏は当時、AmazonのVPでGlobal IT Infrastructureの責任者だった。自分の担当する世界中のデータセンターのインフラを利用して新しいビジネスを提案したのがAWSである。Pinkham氏がEC2のグランドデザインをし、もうひとりのCristopher Brown氏が補佐、Willen van Biljon氏がプロダクト開発の責任者だった。しかし、Pinkhan氏とBiljon氏はAmazonを退社して、シリコンバレーにやってきた。そして2009年始め、2人がFounderとなってNimbulaを立ち上げた。最初の資金$5.75MはSequoia CapitalとVMwareから出た。その後、Accel Partnerも参加、現在のBoard Memberはこの2人とVC2社、そして何と元VMware CEOだったDiane Green女史である。設立以来、NimbulaはまったくのStealth Modeが続いた。突然の発表は6月23日、出てきた製品はProvate Cloudインフラを制御するNimbula Director（以下、Nimbula）”だ。

◆　Cloud OSとなるか、Nimbula Director
大手企業では、クラウドが費用削減などで効果があることは解っているが、運用管理の難しさが壁となってなかなか進まない。Nimbulaは、このような状況を解決し、Amazonのようなクラウドをプライベートとして容易に管理することを目指している。そのため、Nimbulaでは、固有の仮想化技術や物理的な構造（Physical View）を抽象化（Abstract View）し、その上で、それらを管理する手段として、APIやWeb Interface、Command Line Interfaceを提供している。これによって、AdminやUserはWeb Interface/Command Lineのどちらでも利用ができるし、さらにSoftwareへの組込みも可能となっている。現在のβ版では仮想化のXenとKVM対応し（VMwareは未定）、Nimbulaがこれらの総合的にリソースを管理する。将来的にはNimbulaの用意するFederation経由で外部EC2などもリソース管理の対象となる模様だ。仮想マシンの扱いは、PolicyベースのWorkload Managementが担当し、マシンイメージは基本的にOVFとなる。


このようにNimbula Directorを調べてみると、そのポジションが気にかかる。
この分野には、以前、このブログで紹介した「管理コンソール」のEnomalyのようなものから、vSphere4やWindows Azure Platform などの「Cloud OS」がある。個人的な見解だが、2つの違いは、後者が自社製品のみ（VMwareやMicrosoft）を適用対象とするのに対して、前者はそうでなく並列に扱い、かつ、彼らが提供するシステム運用部分を補完している。その意味では、NimbulaもEnomalyの管理コンソールに近い製品だ。ただ、Cloud OSの定義も定かではないし、同社がNimbula DirectorをCloud OSを目指すと主張していることから、ともあれ、今後の動きに要注意だ。現在、全世界で6社がβ版のテスト中、正式出荷は今年下期が予定である。

参考記事：マルチハイパーバイザー管理コンソールのEnomaly

Top 10 Cloud Players－その10 －PUE1.1を目指すYahoo!の新データセンタ－

「米国クラウド十傑(Top 10 Cloud Players)」の10回目。
今回が一応、最後ということで、これまでと少し毛色は違うがデータセンターについて取りあげてみようと思う。データセンターというとすぐにGoogleだと思う人が多い。Googleのセンターは以前からエコ対応だがひとつひとつはそれ程大きくはなく、他と比べて数が多い。これは彼らの戦略によるもののようだ。おやっと思うかもしれないが、今回取りあげるのはYahoo!のデータセンタである。

◆第1世代から第4世代へ
1990年代末からの第1世代データセンターでは、電源や空調設備を持った器となるビルに機器を持つ込んで構築した。第2世代では工場でサーバーをラックに組み上げ、それをセンターに持ち込むようになり、第3世代ではそれらは省エネ、省スペースなどからコンテナーの中に組み込まれて、センターに持ち込まれるようになった。現在始まった第4世代型のデータセンターは、これらを加速し、さらに環境対策がテーマである。


◆災害対策から始まったコンテナー型データセンター
初期の「コンテナー型データセンター」は、災害対策用から始まったと言ってもいい。２００５年８月、米観測史上最大のハリケーン・カトリーナがニューオリンズを襲って大災害となったことはまだ記憶に残る。公共機関や企業のコンピュータはもちろん、一般電話やインターネットもほとんどが麻痺し、やっと役立ったのは携帯電話ぐらいだった。その携帯電話も地上局の破壊や電源停止が多発して混乱状態となった。米携帯キャリアは、この経験を活かして、その後、移動型電話基地局や移動型発電設備などに多くの投資をしてきた。また連邦緊急事態管理局では、これを機に傘下の緊急対策センター向けに、トラック積載型の「モバイル・エマージェンシーデータセンター」を開発した。これはパラボラアンテナを搭載してインターネットや電話アクセスを確保し、トラックのエンジン発電とバッテリーで何台かの積載コンピュータを動かすものだが、廉価で用途も広く好評となった。


◆鳥小屋から学んだヤフーの超省エネ型データセンター
GoogleやMicrosoftを追って、Yahoo!やFacebook、そしてeBayも動き出した。Yahoo!が新設したデータセンターの外見は巨大な養鶏場だ。４棟並ぶうちの３棟には、両側にゆるやかに広がる屋根の上に養鶏場や工場などでみかける換気塔のような大きな２階部分がある。建物の中は確認できないが、ゆったりした空間にサーバーラックがとなりと十分な距離をおいて設置されているに違いない。コンテナー型データセンターでは、サーバーはラックに積み重ねられ、人が歩けるだけの通路を確保して、中には全ての機器が詰め込まれていた。工場生産のコンテナーをトレーラーで持ち込み、電源と冷却チラーを繋げば出来上がりだ。この方法は建設時間の短縮と災害対策には役立つが、これだけでは十分ではない。第４世代に入ると省エネが大きなテーマとなった。クラウドの登場によって、世界中のＩＴ機器が集中傾向にあるし、原油の枯渇や大気汚染による地球温暖化などが叫ばれているからである。Yahoo!は多くを語らない。新データセンターは大きな建物全体に外気を取り入れて対流させ、それを屋上の換気塔から放出するフリークーリング設計で、冷却設備を持たない。場所はナイアガラ瀑布のすぐ近く、ニューヨーク州Buffalo郊外の町、Lockportである。


東京ドーム３つ分に匹敵する３０エーカー（１２万㎡）の敷地に、総工費１・５億㌦（約１５０億円）をかけた。ここでは完全な省エネを目指して、目標となるＰＵＥ値は、１・１以下だ。エネルギー効率を表す「ＰＵＥ（Power Usage Effectiveness）」とは、分子をデータセンターで使う総電力（空調や照明などを含む）、分母はＩＴ機器の消費電力として、割ったもの。端的に言えば、サーバーなどのＩＴ機器以外にどれだけ余分な電力を使っているかを示す指数である。この値が限りなく「１」に近いということは照明も空調もないということを意味する。Buffaloは夏の盛りの７月や８月でも、昼は２５度、夜は１５度程度。この気候とナイアガラの廉価な水力発電を活用し、さらにサーバーのラック方法と建物内空気の流れに工夫を施した。目標通りの稼働が実現できれば世界最高水準のデータセンターとなる。