米国時間4月20日のことだ。昨年3月の発表以来、昨秋には2.1.1a、年末には2.1.2、そして今回のGAが2.2.1、ほぼ１年という早業だ。 Intercloudは周知のように複数プロバイダーのPublic Cloudを連携させた広大なネットワークだが、利用する企業ユーザから見れば、ハイブリッドクラウド基盤のひとつと考えても良い。現在、このネットワークではAmazon
Web ServiceやMicrosoft
Azureと自社Private Cloudの連携が出来るが、今後は整備が進むCiscoパートナーの各種クラウド群との接続も可能となる。 
念のため、Cisco Intercloudのポイントを押さえておこう。
Intercloudとは、Private Cloud上のVMイメージを変換して提携プロバイダーのPublic Cloud上で実行するものである。前述のようにハイブリッド基盤のひとつとはそういう意味だ。ユーザ企業はこの機能を使い、自社クラウドの運用費用削減や繁忙日のオーバーフロー対策などに役立てる。連携にあたって、外部クラウドにロックインされることはない。ここがIntercloudのウリだ。つまり、ユーザは自由に外部プロバイダーを乗り換えることも出来る。このような複数クラウドが織りなすネットワークを「ファブリック（Fabric-織物）」という。このIntercloud Fabric（下図）を構成するコンポーネントは3つ。まず、①ユーザ側にあって、どのようなクラウドやサービスがネットワーク上にあるのかを管理するIntercloud Fabric Director、次に、②自社と外部クラウドを安全に接続する仕組みがSecure Cloud Extention、そして、③外部クラウドプロバイダー上の実行環境がIntercloud Fabric Provider Platformだ。
 |
| Intercloud fabric Architecture |
＝外部クラウド接続を可能とするIntercloud Fabric Director！＝
もう少し細かく見てみよう。
まずユーザ側にインストールされるIntercloud Fabric Directorは、ユーザとIT管理者にそれぞれポータルを提供する。IT管理者はこのポータルからファブリック全体を管理し、ユーザはPublic Cloudと連携させるワークロードの作成や停止などを実行する。このポータルからのマイグレーション（Private Cloud→Public Cloud）指示がトリガーとなって当該するVMがPrivate Cloudで稼働中であればシャットダウンし、連携するPublic CloudのVMフォーマットに変換される。これで該当するVMをPublic Cloudに送り出す準備が整う。
 |
| Intercloud Fabric Director Features |
次に、Private CloudとPublic Cloud間の連携を見よう。
IntercloudではセキュアなPrivate Cloud環境をPublic Cloudまで拡張させる。この役目を果たすのがSecure Cloud Extentionだ。これには企業サイドのIntercloud Extenderとプロバイダサイドに入るIntercloud Switchの２つがある。これらのモジュールが対となってセキュアなLayer２を延伸してTLSトンネルを確立し、また、Intercloud Fabric環境下のVM間通信にも同様なセキュア環境を提供する。
 |
| Secure Cloud Extension |
こうして送り込まれたVMイメージをプロバイダ側で実行するイネーブラがIntercloud Fabric Providor Platform（ICFPP）だ。 ICFPPはPrivate Cloud上のIntercloud Fabric Directorと連携して、VMイメージの実行のためにPublic Cloud側のインフラを展開させる。Intercloudではこれらの通信のためにCloud APIを定義しているが、プロバイダー側で使うPlatform固有のAPIは異なるので、Adopterで変換・実行する。例えば、VMの起動や停止などの要求をIntercloud Fabric Director経由で受けると、それをPublic Cloudのインフラに合わせてAdopterで変換してプラットフォームに引き渡すといった具合だ。VM実行時の課金やログ情報などはICFPPからプロバイダーのOSS（Operation Support System）ないしBSS（Business Support System）に吐き出され、必要な処理が行われる。ただ、この際、課金はVM使用料のみで、Intercloudのサービスには発生しない。尚、現段階でサポートされているAWSとAzureは、Intercloud Fabric Directorで直接ネイティブAPIを使用しているので、プロバイダー側にはICFPPもなく、Adopterもない。GAでサポート対象となっているGuest OSは、RHEL 6.0 - 6.5（64-bit）、CentOS 6.2-6.5（64-bit）、Windows 2008 R2 SP1、Windows 2012、Windows 2012 R2、SUSE Linux 11 SP2 and SP3の6種である。
 |
| Intercloud Fabric Provider Platform |
さて、InterCloudは魅力的だが、それ以前に、うちではまだPrivate Cloudも導入していないという企業も多い。そこで同社ではCisco OpenStack Private Cloudを整備してきた。実際のところ、このエディションは昨年9月に買収したMetacloudのプラットフォームだ。MetacloudはOpenStack-as-a-Serviceをビジネスモデルに掲げ、独自OpenStackディストリビューションで企業のPrivate Cloudを構築支援し、24Hの遠隔監視を提供してきた。Ciscoの提供するPrivate Cloudはこの技術が引き継がれたものである。このシステムの販売はCiscoパートナーがパートナー自身のPublic Cloudと組み合わせて行う予定だ。この方式は、現在、NTT傘下のDimension DataがCisco Hybrid Cloud Bundleとして提供しているが、利用に当たっては費用が発生する。
Intercloud Fabricはリリースされたばかりだ。
課題は幾つかある。まずはパートナーのクラウド連携を加速させることだ。現在、パートナーとして60社以上が参加を表明し、世界50ヶ国350のデータセンタで展開（3/11現在）が予定されている。AWS、Azureに加えて、これらが動き出せば企業ユーザもついてくるだろう。ただ、これはPublic Cloudの価格競争を加速させることになるかもしれない。ユーザにとってはあり難い話だが、パートナーのプロバイダーは及び腰にならないだろうか。次に機能強化だ。現在のIntercloudは、VMイメージの転送実行機能を提供する。この形の延長上で、Private Cloud側に残ったアプリと転送されたアプリが本来連動されていたものなら、VLANを介してハイブリッドとして稼働する。しかし、転送されたVMとPublic Cloud上で固有のサービス機能（Amazon S3など）を利用して作られたアプリなどの連携では、クラウドの境界に仮想ルータを置かなければならない。もし、これらの制約が次期版などで緩和されれば、プロバイダーの参加も企業ユーザの利用も大きく進むだろう。真のIntercloud、それは皆の願いである。
