先日のエントリー「抽象化されたリソースはサービスになっていく」で触れたように、VMwareはvCloud Service Director (仮称／Project Redwood)というIaaS基盤の提供を目前にしています(おそらく8/30からサンフランシスコで開催されるVMworld 2010にて正式発表されることになるのではないかと推測します)が、それを前にすでにvCloud APIと呼ばれるクラウド向けAPIを公開しています。2009/8にVersion0.8として公開されたvCloud APIは2010/4にVersion0.9に改訂されています。vCloud Service Directorの正式リリースと合わせてVersion1.0が公開されることになるのかもしれませんが、それでもこのVersion0.9のドキュメントから、vCloud Service Directorによって実現されるVMware Cloudの姿をすでに垣間見ることができます。
vCloud APIはXMLとHTMLを用いたRESTfulなAPI実装が行われています。技術的な実装ではありますが、具体的なリソースの細かい制御を行うAPIというよりも、リソースをサービス化するために抽象化する仕組みを提供しているAPI仕様となっています。ドキュメント"vCloud API Programming Guide"には、このAPIを使用する構成についての説明が簡易にではありますが記載されています。本エントリーではまずこのドキュメントの記載からvCloudについて見ていきたいと思います。なお、以下の記載には私の考察や推測が含まれています。VMwareが公開している情報については必ずソース資料にあたるようにしてください。
vCloud virtual datacenter (vDC)を実現するために、vCloud APIでは2つの階層のvDCを定義しています。
1つ目は"Provider" vDCs。vSphereによって実装された仮想化リソース環境をさらに1段階抽象的することによって、サービスとして扱うことができる「パッケージ化されたvDS」を構成します。サーバやストレージ、ネットワークなどの具体的なパラメータ設定を隠蔽し、それらから構成されるリソースを「具体的な仕様」から「抽象的なサービスレベル」へと変換します。インフラ管理者によって提供されたvSphereリソースを使って、IaaS利用者に対してサービス化されたリソースを割り当てる「サービス管理者が管理するvDC階層」といえます。
2つ目は"Organization (Org)" vDCs。Provider vDC階層から提供された「抽象化されたリソース」を使って仮想マシンを構成する「利用者にとってのvDC」となります。vSphere環境において直接仮想マシンを構成する場合と異なり、IaaSサービス上で構成される仮想マシンなので具体的な実行サーバや配置されているストレージが見えるわけではありませんので、使用するリソースは契約に基づいて提供されるサービスレベルによって決定されます。利用者側の管理者は、自身のOrg vDCを管理して「IaaSによって提供されるサービス」としてのリソースを利用するということになります。
続いてvCloud APIではカタログという概念が用いられます。
vCloudではサービスを提供する側とサービスを利用する側が異なり、さらに複数の組織がサービスの利用者として並列に存在することになるため、サービスを提供する側は利用者が共通して使用できるvAppのひな形となるもを提供します。これがカタログです。おそらくProvider vDC管理者によって提供される共通カタログと、Org vDC管理者が用いる自身のOrg vDCの範囲の中だけで使用することができるプライベートなカタログが使用できるのではないかと思われます。
カタログの実体はOVFフォーマットのvAppテンプレートであったり、メディアイメージであったりするわけですが、カタログの使いやすさは利用者にとってのvCloudの使いやすさに直結する重要な要素です。
次はvCloud APIにおけるネットワークについてです。
vDCが2階層となる構成においては、ネットワークもまた2種類が必要となります。1つはProvider vDC側が提供するネットワークです。Provider vDCが用意するネットワークは仕様により異なるとは思いますが、基本的にはPublicなネットワークとOrg vDC単位で利用することができるPrivateなネットワークの2つが基本となるでしょう。もう1つはOrg vDC側が用いるvAppのために用いるハートビートやバックエンド通信などに用いる一種のInternal Networkです。ネットワークはIaaSサービスにおいては根幹となりますし、セキュリティやパフォーマンスの面からも安定性や確実性が求められます。Org vDCの中でFirewallやNAT, ロードバランシングなどが用いられる場合もあるかと思いますので、柔軟性がどこまで得られるのかもポイントになってくるでしょう。
そしてユーザおよびグループについてです。
アカウント管理については、Org vDCの管理者権限についてはProvider vDC側が厳密に管理を行う必要がありますが、それとは別に、Org vDCにおいて用いることができる柔軟なアカウント管理の仕組みが必要です。vCloud APIではOrg vDC管理者がLDAPや独自のアカウント管理などの自由度が得られる仕組みとなっています。
タスクについて。
Org vDCにおいてはタスクの管理も重要です。特にバックアップやクローンなどといった処理にある程度の時間を要するタスクについては、インフラ管理者、サービス管理者、そして利用者側の管理者それぞれがステータスを把握できる必要があります。Org vDC内においては各VMごとに管理者が設定されている場合もあるかと思いますので、各レイヤーの管理者がタスクステータスを把握できる仕組みは障害時における問題切り分けなどのためにも重要です。
vCloud APIの中身について入る前に長くなってしまいましたので今回はここまでにしておきます。vCloud APIについては私自身ドキュメントを読み込みつつ、継続的に続きを書いていきたいと思います。
