JP5680105B2

JP5680105B2 - クラウド・コンピューティング環境内におけるクラウド間のリソース共有

Info

Publication number: JP5680105B2
Application number: JP2012541370A
Authority: JP
Inventors: パターソン、ロバート、チャールズ、ジュニア; ブルックバンクス、マイケル、ダドリー; ネラットラ、ティルマル; ドーソン、クリストファー、ジェームズ; コフィー、ブレンダン; シーマン、ジェームズ、ウェスリー
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2009-12-03
Filing date: 2010-10-18
Publication date: 2015-03-04
Anticipated expiration: 2030-10-18
Also published as: GB2488253A; GB201204293D0; DE112010003819T5; DE112010003819B4; US20110137805A1; CN102640475A; CN102640475B; WO2011067029A1; JP2013513139A

Description

本発明は、一般に、クラウド・コンピューティングに関する。本発明は、特に、クラウド・コンピューティング環境内におけるクラウド間のリソース共有に関する。

クラウド・コンピューティングは、種々の情報技術（ＩＴ）概念をサービスとして提供する一般的な方法となった。１つの実装形態において、コンシューマ又はリクエスタは、彼らが望むサービスを要求し、必要なサービスについてクラウド・プロバイダとトランザクションを行うことができる。クラウド・プロバイダの事業機会は、導入されている物理的なリソースによって、又は、付加的なリソースを適時に費用効率の高い方法で調達する能力によって、制限又は制約されることがある。多くの場合、カスタマ（サービス・リクエスタ）に十分な準備期間がなければ、要求は、クラウド・プロバイダによって満たされない可能性が高く、又は適時の方法では満たされない可能性が高い。

ＰｅｔｅｒＭｅｌｌ及びＴｉｍＧｒａｎｃｅ著、「ＤｒａｆｔＮＩＳＴＷｏｒｋｉｎｇＤｅｆｉｎｉｔｉｏｎｏｆＣｌｏｕｄＣｏｍｐｕｔｉｎｇ」、２００９年１０月７日

本発明は、クラウド・コンピューティング環境内におけるクラウド間のリソース共有のシステム及び方法に関する

本開示は、主クラウド・インフラストラクチャの物理的な増設を必要とすることなくクラウド・リソース要求の動的な拡張／縮小に途切れなく対処できるように、クラウド間リソース共有の合意及びポリシーを確立し、付加的なリソースの必要性又は付加的なリソースを提供する申し出を、確立された市場を通して仲介できることを広告する、システム及び方法を説明する。金融取引は、サプライヤ／コンシューマの代替ビジネル・モデル（an alternating supplier/consumer business model）とより良好に整合する、共生的な双方向の公平共有方法（a symbiotic bi-lateral fair-share method）をサポートする。このシステム及び方法を用いることにより、所与のクラウド・サービス要求に応答するのに必要な時間が短縮する一方で、確立されたクラウド・プロバイダ間のリソース共有モデルに利点がもたらされる。

特に、本発明は、クラウド・プロバイダが、確立された市場の中で自らのリソース要件を広告し、既存のクラウド・プロバイダの要求を満たすように自らのリソースを提供し、及び／又は、リソース要求に対してどのように資金供給されるかを管理する「公平共有（fair-sharing）」方法を利用する、ことを可能にする。

本発明の第１の態様は、クラウド・コンピューティング環境におけるクラウド間のリソース共有のための方法であって、第１のクラウド・プロバイダにおいて受信された要求を満たすのに必要なリソース要件を評価することと、第１のクラウド・プロバイダが、リソース要件を満たすのに利用可能なリソースを有するかどうかを判断することと、第１のクラウド・プロバイダが利用可能なリソースとリソース要件との間のいずれかの不足を満たすことができる第２のクラウド・プロバイダを識別することと、第２のクラウド・プロバイダのリソースを用いて不足を満たすために、第１のクラウド・プロバイダと第２のクラウド・プロバイダとの間で交渉することとを含む、方法を提供する。

本発明の第２の態様は、クラウド・コンピューティング環境におけるクラウド間のリソース共有を管理するためのクラウド・マネージャであって、命令を含むメモリ媒体と、メモリ媒体に結合されたバスと、命令を実行したときに、クラウド・マネージャに、第１のクラウド・プロバイダにおいて受信された要求を満たすのに必要なリソース要件を評価させ、第１のクラウド・プロバイダが、リソース要件を満たすのに利用可能なリソースを有するかどうかを判断させ、第１のクラウド・プロバイダが利用可能なリソースとリソース要件との間のいずれかの不足を満たすことができる第２のクラウド・プロバイダを識別させ、第２のクラウド・プロバイダのリソースを用いて不足を満たすために、第１のクラウド・プロバイダと第２のクラウド・プロバイダとの間で交渉させる、バスに結合可能なプロセッサとを含む、クラウド・マネージャを提供する。

本発明の第３の態様は、クラウド・コンピューティング環境におけるクラウド間のリソース共有を管理するためのプログラム製品を含むコンピュータ可読媒体であって、コンピュータ・システムに、第１のクラウド・プロバイダにおいて受信された要求を満たすのに必要なリソース要件を評価させ、第１のクラウド・プロバイダが、リソース要件を満たすのに利用可能なリソースを有するかどうかを判断させ、第１のクラウド・プロバイダが利用可能なリソースとリソース要件との間のあらゆる不足を満たすことができる第２のクラウド・プロバイダを識別させ、第２のクラウド・プロバイダのリソースを用いて不足を満たすために、第１のクラウド・プロバイダと第２のクラウド・プロバイダとの間で交渉させるためのプログラム・コードを含む、コンピュータ可読媒体を提供する。

本発明の第４の態様は、クラウド・コンピューティング環境におけるクラウド間のリソース共有を管理するためのシステムを配置する方法であって、第１のクラウド・プロバイダにおいて受信された要求を満たすのに必要なリソース要件を評価し、第１のクラウド・プロバイダが、リソース要件を満たすのに利用可能なリソースを有するかどうかを判断し、第１のクラウド・プロバイダが利用可能なリソースとリソース要件との間のあらゆる不足を満たすことができる第２のクラウド・プロバイダを識別し、第２のクラウド・プロバイダのリソースを用いて不足を満たすために、第１のクラウド・プロバイダと第２のクラウド・プロバイダとの間で交渉するように動作可能なコンピュータ・インフラストラクチャを準備することを含む方法を提供する。

本発明のこれらの特徴及び他の特徴は、添付の図面と併せた本発明の種々の態様についての以下の詳細な説明からより容易に理解されよう。

本発明によるクラウド・システムのノードを示す。本発明によるクラウド・コンピューティング環境を示す。本発明によるクラウド抽象モデル層を示す。本発明によるクラウド間のリソース共有の例を示す。サービス・コンシューマが、本発明による主クラウド・プロバイダによってどのようにサービスにアクセスするかの例を示す。本発明による図４、図５の例に従うクラウド・トランザクション追跡の例を示す。本発明による方法のフロー図を示す。

図面は必ずしも縮尺通りではない。図面は、単なる概略的な表現であり、本発明の特定のパラメータを表現することを意図するものではない。図面は、本発明の典型的な実施形態のみを示すことを意図しており、したがって、本発明の範囲を限定するものと考えられるべきではない。図面において、同一の符号は同一の要素を表す。

便宜上、発明を実施するための形態は、以下のセクションを有する。
Ｉ．クラウド・コンピューティングの定義
ＩＩ．好ましい実施形態の詳細な実装

Ｉ．クラウド・コンピューティングの定義

以下の定義は、非特許文献１に基づくものである。

「クラウド・コンピューティング」は、最小限の管理努力又はサービス・プロバイダとの対話で、迅速に供給及び解放することができる構成可能なコンピューティング・リソース（例えば、ネットワーク、サーバ、ストレージ、アプリケーション、及びサービス）の共有プールに対する、利便性の高いオンデマンドのネットワーク・アクセスを可能にするモデルである。このクラウド・モデルは、可用性を高めるものであり、少なくとも５つの特性と、少なくとも３つのサービス・モデルと、４つの配置モデルとで構成される。特性は、下記の通りである。

オンデマンド・セルフサービス：コンシューマは、各々のサービス・プロバイダとの人的対話を必要とすることなく、必要に応じて自動的に、サーバ時間及びネットワーク・ストレージのようなコンピューティング能力を一方向に供給することができる。

広範なネットワーク・アクセス：機能は、ネットワークを介して利用可能であり、異なるシン・クライアント・プラットフォーム又はシック・クライアント・プラットフォーム（例えば、携帯電話、ラップトップ、及びＰＤＡ）による使用を促進する標準機構を通じてアクセスされる。

リソースのプール：プロバイダのコンピューティング・リソースは、プールされて、マルチテナント・モデルを用いて複数のコンシューマにサービスされ、異なる物理リソース及び仮想リソースが、コンシューマの要求に応じて動的に割り当て及び再割り当てされる。コンシューマは、一般に、提供されるリソースの正確な場所を制御したり、場所に関する知識を有したりすることはないが、より高次の抽象レベルで場所（例えば、国、州、又はデータセンタ）を指定することができるという点で、場所非依存性が存在する。リソースの例として、ストレージ、処理、メモリ、ネットワーク帯域、及び仮想マシンが挙げられる。

迅速な弾力性：機能は、迅速かつ弾力的に、場合によっては自動的に供給して素早くスケールアウトし、迅速に解放して素早くスケールインすることが可能である。コンシューマにとっては、供給のために利用可能な機能は、多くの場合、制限がないように見え、いつでも任意の量で購入することができる。

計測されるサービス：クラウド・システムは、サービスの種類（例えば、ストレージ、処理、帯域幅、及びアクティブ・ユーザ・アカウント）に適したいくつかの抽象化レベルで計量機能を活用することによって、リソースの使用を自動的に制御し、最適化する。リソース使用量を監視し、制御し、報告することで、使用されているサービスのプロバイダ及びコンシューマの両方に対して透明性を提供することができる。

サービス・モデルは、以下の通りである。

クラウド・サービスとしてのクラウド・ソフトウェア（Cloud Software as a CloudService）（ＳａａＳ）：コンシューマに提供される機能は、クラウド・インフラストラクチャ上で実行されるプロバイダのアプリケーションを使用することである。アプリケーションは、ウェブ・ブラウザ（例えば、ウェブベースの電子メール）のようなシン・クライアント・インタフェースを通じて、種々のクライアント・デバイスからアクセス可能である。コンシューマは、限定されたユーザ固有のアプリケーション構成設定を除いて、ネットワーク、サーバ、オペレーティング・システム、ストレージ、又は個々のアプリケーションの機能も含む、基盤となるクラウド・インフラストラクチャを管理又は制御することはない。

クラウド・サービスとしてのクラウド・プラットフォーム（Cloud Platform as a CloudService）（ＰａａＳ）：コンシューマに提供される機能は、プロバイダがサポートするプログラミング言語及びツールを用いて作成された、コンシューマが作成又は獲得したアプリケーションを、クラウド・インフラストラクチャ上に配置することである。コンシューマは、ネットワーク、サーバ、オペレーティング・システム、又はストレージを含む、基盤となるクラウド・インフラストラクチャを管理又は制御することはないが、配置されたアプリケーションと、可能であれば環境構成をホストするアプリケーションとを制御する。

クラウド・サービスとしてのクラウド・インフラストラクチャ（Cloud Infrastructure asa Cloud Service）（ＩａａＳ）：コンシューマに提供される機能は、処理、ストレージ、ネットワーク、及びその他の基本的なコンピューティング・リソースの提供であり、コンシューマは、オペレーティング・システム及びアプリケーションを含むことができる任意のソフトウェアを配置し、実行させることが可能である。コンシューマは、基盤となるクラウド・インフラストラクチャを管理又は制御することはないが、オペレーティング・システム、ストレージ、配置されたアプリケーションを制御し、可能であれば選択ネットワーキング・コンポーネント（例えば、ホストのファイアウォール）を限定的に制御する。

配置モデルは、以下の通りである。

プライベート・クラウド：クラウド・インフラストラクチャは、１つの組織のためだけに動作する。これは、その組織又は第三者によって管理することができ、構内（premise）又は構外（off premise）に存在することができる。

コミュニティ・クラウド：クラウド・インフラストラクチャは、いくつかの組織によって共有され、共通の利害関係（例えば、任務、セキュリティ要件、ポリシー、及びコンプライアンスの考慮事項）を有する特定のコミュニティをサポートする。これは、それらの組織又は第三者によって管理することができ、構内又は構外に存在することができる。

パブリック・クラウド：クラウド・インフラストラクチャは、公衆又は大きな産業グループが利用可能できるようにされており、クラウド・サービスを販売する組織によって所有される。

ハイブリッド・クラウド：クラウド・インフラストラクチャは、２つ又はそれより多いクラウド（プライベート、コミュニティ、又はパブリック）を組み合わせたものであり、これらのクラウドは、固有のエンティティのままであるが、データ及びアプリケーションのポータビリティを可能にする標準化技術又は専有技術によって互いに結合される（例えば、クラウド間の負荷バランスのためのクラウド・バースティング）。

クラウド・ソフトウェアは、無国籍、粗結合性、モジュール性、及び意味的相互運用性に焦点を合わせたサービス指向のものとすることによって、クラウドの理論的枠組みを十分に活用する。

ＩＩ．好ましい実施形態の実装

上述のように、本開示は、主クラウド・インフラストラクチャの物理的な増設を必要とすることなくクラウド・リソース要求の動的な拡張／縮小に途切れなく対処できるように、クラウド間のリソース共有の合意及びポリシーを確立し、付加的なリソースの必要性又は付加的なリソースを提供する申し出を、確立された市場を通して仲介できることを広告する、システム及び方法を説明する。金融取引は、サプライヤ／コンシューマの代替ビジネル・モデルとより良好に整合する、共生的な双方向の公平共有方法をサポートする。このシステム及び方法を用いることにより、所与のクラウド・サービス要求に応答するのに必要な時間が短縮する一方で、確立されたクラウド・プロバイダ間のリソース共有モデルに利点がもたらされる。

特に、本発明は、クラウド・プロバイダが、確立された市場の中で自らのリソース要件を広告し、既存のクラウド・プロバイダの要求を満たすように自らのリソースを提供し、及び／又は、リソース要求に対してどのように資金供給されるかを管理する「公平共有」方法を利用する、ことを可能にする。

クラウド・プロバイダの１つの価値は、必要性を示した他のクラウド・プロバイダにリソースを提供することによって、又は、自らのリソースを使用するよう提示しているクラウド・プロバイダからそのリソースを要求することによって、リソースの使用を最適化できることである。このことによって、クラウド・プロバイダが、一時的な需要のために新しいクラウド・アセットを調達することに資本を費やすことなく、自らのクラウド・インフラストラクチャの容量を動的に拡張する費用効率の高い機構が可能になる。クラウド・プロバイダは、正当化できる可能性の低い大きな資本支出を避け、より高い割合で自らのカスタマのサービス要求に積極的に応じることが可能である。さらに、「費用中立（cost-neutral）」アルゴリズムは、ビジネス・ネットワークに参加しているクラウド・プロバイダ間で、クラウド・プロバイダの出て行く需要要求をクラウド・プロバイダの出て行く供給要求で最適化しようとするものであり、したがって、資本及び経費の支出をさらに減少させようとするものである。

今日、クラウド・プロバイダは、１つのドメインで存在し、所与のリソースを提供すること、例えば、コンピュータ、コンピュータ・ストレージ、ビジネス・アプリケーションなどへのアクセスを重視している。これらのクラウド機能をそのカスタマに提供するためには、クラウド・プロバイダは、ＩＴインフラストラクチャを構築することに金、時間、及びエネルギを投資して、自らのクライアントから期待される需要を満たすことが必要である。構築が過剰な場合には、資本投資収益率が低下し、構築が不足する場合には、成長の機会を失うことになる。資本投資収益率を含まずに生じる需要を満たすことができれば、企業の収益性を高めることに役立つ。この手法の実行を可能にするためには、確立された主クラウド・インフラストラクチャの外から、必要な量のクラウド・リソースにアクセスできるようにするためのシステム及び方法を必要とする。

これは、リソースの利用可能性と参加クラウド・プロバイダの確立された市場間におけるリソースの必要性とを記述する配信機構によって、及び、いずれかの所与のプロバイダに対する未処理のトークン数が将来のトランザクションに対するメンバーの選択に影響を与えるトークン・ベースの方法を介して各クラウド・プロバイダ間のトランザクションを管理するアルゴリズムによって、達成される。請求スイープ（billing sweep）機構が、特定の間隔で呼び出され、通常のトークンのトランザクションを通してコスト中立目標に達しなかった残高を支払う。全体的に、本発明は、クラウド環境内で発生する動的なリソース需要を満たすことと、クラウド間トランザクションを達成するための「公平共有」方法を構成することと、短期資本インフラストラクチャ費用の必要性を低減させることとを効率的に行うための新規な方法を提供する。

ここで図１を参照すると、例示的なクラウド・コンピューティング・ノードの概略図が示される。クラウド・コンピューティング・ノード１０は、適切なクラウド・コンピューティング・ノードの一例に過ぎず、本明細書に説明される本発明の使用又は機能の範囲について、いかなる限定をも示唆することを意図するものではない。それにもかかわらず、クラウド・コンピューティング・ノード１０は、上記のセクションＩに説明される機能のいずれかを実装及び／又は実施することができる。

クラウド・コンピューティング・ノード１０においては、多くの他の汎用又は専用コンピューティング・システム環境又は構成と共に動作可能なコンピュータ・システム／サーバ１２が存在する。コンピューティング・システム／サーバ１２での使用に適したものとすることができる周知のコンピューティング・システム、環境、及び／又は構成の例として、パーソナル・コンピュータ・システム、サーバ・コンピュータ・システム、シン・クライアント、シック・クライアント、ハンドヘルド又はラップトップ型デバイス、マルチプロセッサ・システム、マイクロプロセッサ・ベースのシステム、セット・トップ・ボックス、プログラム可能な家庭用電化製品、ネットワークＰＣ、ミニコンピュータ・システム、メインフレーム・コンピュータ・システム、及び上述のシステム又はデバイスのいずれかを含む分散型クラウド・コンピューティング環境などが挙げられるが、これらに限定されない。

コンピュータ・システム／サーバ１２は、コンピュータ・システムによって実行される、プログラム・モジュールのようなコンピュータ・システム実行可能命令との関連で説明することができる。一般に、プログラム・モジュールは、特定のタスクを実行するか又は特定の抽象データ・タイプを実装するルーチン、プログラム、オブジェクト、コンポーネント、論理、データ構造などを含む。例示的なコンピュータ・システム／サーバ１２は、通信ネットワークを通してリンクされる遠隔処理デバイスによってタスクが実行される分散型クラウド・コンピューティング環境において実施することができる。分散型クラウド・コンピューティング環境においては、メモリストレージ・デバイスを含むローカル及びリモートの両方のコンピュータ・システム・ストレージ媒体に、プログラム・モジュールを配置することができる。

図１に示されるように、クラウド・コンピューティング・ノード１０におけるコンピュータ・システム／サーバ１２は、汎用コンピュータ装置の形態で示される。コンピュータ・システム／サーバ１２のコンポーネントは、１つ又は複数のプロセッサ又は処理ユニット１６と、システム・メモリ２８と、システム・メモリ２８を含む種々のシステム・コンポーネントをプロセッサ１６と結合するバス１８とを含むが、これらに限定されない。

バス１８は、メモリ・バス又はメモリ・コントローラと、周辺バスと、アクセラレーティッド・グラフィックス・ポートと、様々なバス・アーキテクチャのいずれかを用いるプロセッサ又はローカル・バスとを含む、幾つかのタイプのバス構造のうちのいずれか１つ又は複数を表わす。限定ではなく例として、そうしたアーキテクチャは、業界標準アーキテクチャ（ＩＳＡ：Industry Standard Architecture）バス、マイクロチャネル・アーキテクチャ（ＭＣＡ：Micro Channel Architecture）バス、エンハンストＩＳＡ（ＥＩＳＡ：Enhanced ISA）バス、ビデオ・エレクトロニクス・スタンダーズ・アソシエーション（ＶＥＳＡ）ローカル・バス、及び周辺機器コンポーネント相互接続（ＰＣＩ：Peripheral Component Interconnects）バスを含む。

コンピュータ・システム／サーバ１２は、典型的には、様々なコンピュータ・システム可読媒体を含む。こうした媒体は、コンピュータ・システム／サーバ１２によってアクセス可能ないずれかの利用可能媒体とすることができ、これは、揮発性及び不揮発性の両方の媒体、取り外し可能及び取り外し不可能の両方の媒体を含むことができる。

システム・メモリ２８は、ランダム・アクセス・メモリ（ＲＡＭ）３０及び／又はキャッシュ・メモリ３２のような揮発性メモリの形態のコンピュータ・システム可読媒体を含むことができる。コンピュータ・システム／サーバ１２は、他の取り外し可能／取り外し不可能なコンピュータ・システム・ストレージ媒体、揮発性／不揮発性のコンピュータ・システム・ストレージ媒体をさらに含むことができる。一例に過ぎないが、取り外し不可能な不揮発性磁気媒体（図示されておらず、典型的には「ハード・ドライブ」と呼ばれる）に対して読み込み及び書き込みを行うために、ストレージ・システム３４を設けることができる。図示されてはいないが、取り外し可能な不揮発性磁気ディスク（例えば「フロッピー・ディスク」）に読み込み及び書き込みを行うための磁気ディスク・ドライブと、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ又は他の光学媒体などの取り外し可能な不揮発性光学ディスクに読み込み及び書き込みを行うための光学ディスク・ドライブとを設けることができる。こうした場合には、１つ又は複数のデータ媒体インターフェースによって、各々をバス１８に接続することができる。以下にさらに示され、説明されるように、メモリ２８は、本発明の機能を実行するように構成されたプログラム・モジュールの組（例えば、少なくとも１つ）を有する少なくとも１つのプログラム製品を含むことができる。

プログラム・モジュール４２の組（少なくとも１つ）を有するプログラム／ユーティリティ４０は、一例として、メモリ２８内に格納することができ、限定されるものではないが、オペレーティング・システム、１つ又は複数のアプリケーション・プログラム、他のプログラム・モジュール、及びプログラム・データも同様である。オペレーティング・システム、１つ又は複数のアプリケーション・プログラム、他のプログラム・モジュール、及びプログラム・データ又はその幾つかの組み合わせの各々は、ネットワーキング環境の実装形態を含むことができる。プログラム・モジュール４２は、一般に、本明細書に説明される本発明の機能及び／又は方法を実現する。

コンピュータ・システム／サーバ１２はまた、キーボード、ポインティング・デバイス、ディスプレイ２４等の１つ又は複数の外部デバイス１４、ユーザがコンピュータ・システム／サーバ１２と対話することを可能にする１つ又は複数のデバイス、及び／又はコンピュータ・システム／サーバ１２が１つ又は複数の他のコンピュータ装置と通信することを可能にするいずれかのデバイス(例えば、ネットワーク・カード、モデム等)と、通信することができる。こうした通信は、Ｉ／Ｏインターフェース２２を介して行うことができる。さらにまた、コンピュータ・システム／サーバ１２は、ネットワーク・アダプタ２０を介して、ローカル・エリア・ネットワーク（ＬＡＮ）、一般的なワイド・エリア・ネットワーク（ＷＡＮ）、及び／又は公衆ネットワーク（例えば、インターネット）のような１つ又は複数のネットワークと、通信することができる。示されるように、ネットワーク・アダプタ２０は、バス１８を介して、コンピュータ・システム／サーバ１２の他のコンポーネントと通信する。図示されてはいないが、他のハードウェア及び／又はソフトウェア・コンポーネントをコンピュータ・システム／サーバ１２と共に使用できることを理解すべきである。例として、マイクロコード、デバイス・ドライバ、冗長処理ユニット、外部ディスク・ドライブ・アレイ、ＲＡＩＤシステム、テープ・ドライブ、データ・アーカイバル・ストレージ・システム等を含むが、これらに限定されない。

ここで図２を参照すると、例示的なクラウド・コンピューティング環境５０が示されている。図示されるように、クラウド・コンピューティング環境５０は、例えば、携帯情報端末（ＰＤＡ）又は携帯電話５４Ａ、デスクトップコンピュータ５４Ｂ、ラップトップコンピュータ５４Ｃ、及び／又は自動車コンピュータ・システム５４Ｎのようなコンピュータ装置が通信する、１つ又は複数のクラウド・コンピューティング・ノード１０を含む。これによって、インフラストラクチャ、プラットフォーム及び／又はソフトウェアをクラウド・コンピューティング環境５０からの（セクションＩにおいて上述されたような）サービスとして提供し、各クライアントがそうしたリソースを別個に保持する必要をなくすことが可能になる。図２に示されるコンピュータ装置５４Ａ−Ｎのタイプは、例示のみを意図していること、並びに、クラウド・コンピューティング環境５０は、あらゆるタイプのネットワーク及び／又はネットワーク／アドレス可能な接続を介して（例えば、ウェブ・ブラウザを用いて）あらゆるタイプのコンピュータ化装置と通信できることを、理解されたい。

ここで図３を参照すると、クラウド・コンピューティング環境５０（図２）によって提供される機能抽象化層の組が示される。図３に示されるコンポーネント、層、及び機能は、例示のみを意図しており、本発明はこれらに限定されるものではないことを理解されたい。図示されるように、以下の層及び対応する機能が提供される。

ハードウェア及びソフトウェア層６０は、ハードウェア及びソフトウェア・コンポーネントを含む。ハードウェア・コンポーネントの例として、ＩＢＭ（登録商標）ｚＳｅｒｉｅｓ（登録商標）システムを一例とするメインフレーム、ＩＢＭｐＳｅｒｉｅｓ（登録商標）システムを一例とするＲＩＳＣ（縮小命令セット・コンピュータ）アーキテクチャ・ベースのサーバ、ＩＢＭｘＳｅｒｉｅｓ（登録商標）、ＩＢＭＢｌａｄｅＣｅｎｔｅｒ（登録商標）システム、ストレージ・デバイス、ネットワーク及びネットワーキング・コンポーネントが挙げられる。ソフトウェア・コンポーネントの例として、ＩＢＭＷｅｂＳｐｈｅｒｅ（登録商標）アプリケーション・サーバ・ソフトウェアを一例とするネットワーク・アプリケーション・サーバ・ソフトウェア、及び、ＩＢＭＤＢ２（登録商標）データベース・ソフトウェアを一例とするデータベース・ソフトウェアが挙げられる。（ＩＢＭ、ｚＳｅｒｉｅｓ、ｐＳｅｒｉｅｓ、ｘＳｅｒｉｅｓ、ＢｌａｄｅＣｅｎｔｅｒ、ＷｅｂＳｐｈｅｒｅ及びＤＢ２は、米国、他の国々又は両方におけるインターナショナル・ビジネス・マシーンズ・コーポレーションの商標である）。

仮想化層６２は、以下の例示的な仮想エンティティ、すなわち、仮想サーバ、仮想ストレージ、仮想私設ネットワークを含む仮想ネットワーク、仮想アプリケーション、及び仮想クライアントを与えることができる、抽象層を提供する。

管理層６４は、以下に説明される例示的な機能を提供する。リソース供給は、クラウド・コンピューティング環境内でタスクを実行するのに使用されるコンピューティング・リソース及び他のリソースの動的な調達を提供する。計量及び価格決定は、リソースがクラウド・コンピューティング環境内で使用されるときのコスト追跡と、これらのリソースの消費についての請求書作成又はインボイス作成を提供する。一例として、これらのリソースは、アプリケーション・ソフトウェア・ライセンスを含むことができる。セキュリティは、ユーザ及びタスクについての識別情報確認、並びに、データ及び他のリソースの保護を提供する。ユーザ・ポータルは、ユーザ及びシステム管理者の両方に、クラウド・コンピューティング環境へのアクセスを提供する。サービス・レベル管理は、要求されるサービス・レベルに合うように、クラウド・コンピューティング・リソース割り当て及び管理を提供する。サービス・レベル契約（ＳＬＡ：Service Level Agreement）計画及び履行は、ＳＬＡに従って将来の要求が予期されるクラウド・コンピューティング・リソースのための、事前構成及び調達を提供する。

作業負荷層６６は、クラウド・コンピューティング環境が使用される機能を提供する。この層から提供することができる作業負荷及び機能の例として、マッピング及びナビゲーション、ソフトウェア開発及びライフ・サイクル管理、仮想教室教育の配信、データ解析処理、トランザクション処理、及びクラウド・サービス・カタログ管理が挙げられる。

一般に、リソース管理機能は、図４から図７に関連して本発明書に説明される本発明の機能を実装する。上述のように、本発明は、自らのクラウド・リソースの利用可能性をこのプライベート・コミュニティの他のメンバーに配信するクラウド・プロバイダのウェブベースのディレクトリを提供する。１つの実施形態では、コミュニティへの参加は、使用料ベースとすることができる。

ディレクトリは、リソースのタイプ、リソースの量、リソースの計画済みの及び現在の利用可能性、いずれかのリソース使用制限、及び適用されることになる諸条件（例えば、一日／一使用当たりのストレージの＄／テラバイトについての料金構成）を記述する。支払条件は、所与のメンバーが特定のリソースの使用について容認する意志がある合意済みの値を反映する（例えば、一日／一使用当たりのストレージの＄／テラバイトは、一日／一使用当たり２ＣＰＵに相当する）。トランザクション・エンジンは、ディレクトリ及び特定のトランザクション要求の両方に対して解析を適用する。トランザクションは、トークン・ベースの交換システムを通して表現される。各々のメンバーは、ディレクトリのエントリを見ることができるが、彼らが参加していないリソースのトランザクションを見ることはできない。

ここで図４を参照すると、これらの概念は、２つの例示的なクラウド、すなわち、クラウドＡ及びクラウドＢの文脈で説明される。特に、この図は、２つのクラウドによる広告されるサービスのセクション例を示す。クラウドＡが、コンピュータ・システム及びストレージ・システムの両方を必要とするサービスの要求を受け取る例を考える。この場合には、クラウドＡは、ストレージを提供する能力がないため、要件を完全に満たすことができないこともさらに仮定する。クラウド・プロバイダのディレクトリは、ストレージを提供できる可能性がある、私設ネットワーク内の他のクラウド・プロバイダを発見するのに用いられる。複数のクラウド・プロバイダ（そのうちの１つがクラウドＢである）が発見されたものと仮定する。両方の組み合わせを用いて、能力、価格、及び優先順位付けリスト（これらに限定されない）のための必要要件の整合性を生成することができる。トークン数を考慮することもできる。すなわち、数字又は数は、クラウドＡが、検索されたクラウドに対してどのくらい「負債がある（ＩＮＤＥＢＴ）」かを表わすことができる。図４の例では、クラウドＢは−２だけ負債があると考えることができる。これは、クラウドＢはクラウドＡを２度使用したが、その逆は行われていないことを意味する。したがって、クラウドＢは、クラウドＡに対して負債があるために、選択される。数学の計算に基づいて、トークン数をクラウドＢから差し引いて、クラウドＡに加えることができる。図４において、例示的な制限は、米国、他の国々のＴｈｅＯｐｅｎＧｒｏｕｐの商標である用語Ｕｎｉｘ（登録商標）と、米国及び／又は他の国々におけるＩＢＭ社の商標である用語ＤＢ２（登録商標）とを含む。

期間の終わりには、「調整（true up）」が行われることがあり、これによって、価格決定及び他の金融債務が計算される。目標は、公平共有を保証することによって資金転送を最小にすることである。図５の例においては、サービス・コンシューマ７０は、主クラウド・プロバイダ７２Ａでサービスにアクセスしている。クラウド・プロバイダ７２Ａは、ウェブ・ポータル又は他の媒体７６を通して、クラウド・コミュニティにサービス要求を行うことができる。ポータル７６は、利用可能なリソース及び各リソースの特定の属性（例えば、価格、利用可能性、タイプ等）のディレクトリ７８を保持する。さらに、クラウド・プロバイダ７２Ｂ−Ｎは、彼らのリソースの必要性又は申し出を配信することができる。トランザクション・エンジン８０は、どのプロバイダが所与のトランザクションに「最適（best fit）」であるかの解析評価を進める。

クラウド・プロバイダの確立されたメンバーシップとそれぞれのリソースとが文書化され、ディレクトリにおいて利用可能になったときには、クラウド・メンバーは、必要に応じて、ディレクトリに照会することが可能になる。例えば、図６を参照すると、アクメ・クラウド・プロバイダ８２Ａが、自らのクライアントの必要性を満たすために、付加的なコンピュータ・サーバが必要であると判断した場合には、自らの必要性を満たすのに利用可能なリソースについて、ディレクトリ７８に照会することができる。この例においては標準クラウド・プロバイダ８２Ｂとトランザクションの合意に達した場合には、この情報は、トランザクション・エンジン８０に取り込まれる。一般に、トランザクション・エンジン８０は、各メンバーのトランザクションを追跡するアルゴリズムを実装しており、その結果、将来のトランザクションは、コスト中立目標に向かって最適化される。この場合には、トークンは、アクメ・クラウド・プロバイダ８２Ａに割り当てられており、標準クラウド・プロバイダ８２Ｂに対して未処理の残高があることを表わしている。以下の例においては、トランザクション・エンジン８０は、少なくとも２つのクラウド・プロバイダがアクメ・クラウド・プロバイダ８２Ａのリソース要求を満たすことができることを確認し、「クラウド・プロバイダ：標準」がアクメ・クラウド・プロバイダ８２Ｂに対して負のトークン残高を有する一方、「クラウド・プロバイダ：エース」が正のトークン残高を有することもさらに認識している。したがって、アクメにとっては、この場合には、エースに対して有する未処理のトークン残高を増加させるより、標準クラウドとトランザクションを行うことが利益となる。トランザクション・エンジン８０は、アクメと標準との間のトークン残高を更新し、トランザクションを確定する。予め定められたスイープ・サイクルの前にアクメと標準との間にさらなるトランザクションが生じない場合には、標準クラウド・プロバイダ８２Ｂは、アクメ・クラウド・プロバイダ８２Ａに対する未処理トークンの負債（例えば、２）を支払う義務がある。

一例において、標準クラウド・プロバイダ８２Ｂが、アクメにリソースを提供するために６回のトランザクションを行い、したがってアクメ・クラウド・プロバイダ８２Ａに対して６つの未処理のトークンを有する場合には、トランザクション・エンジンは、標準クラウド・プロバイダ８２Ｂに対して、標準クラウド・プロバイダ８２Ｂが有するあらゆる将来のリソース需要についてアクメ・クラウド・プロバイダ８２Ａとの間で最優先してトランザクションを行うことを提案する。同様に、標準クラウド・プロバイダ８２Ｂが、所与のメンバーにリソースを提供したトランザクションを有する場合には、将来のリソース需要は、それらのメンバーが優先される。トランザクション・エンジンに組み込まれる付加的な優先順位付けは、価格、サービスの品質、及びサービス・レベル合意についての選択（preferences）を含む。

ここで図７を参照すると、本発明による方法のフロー図が示される。図示されるように、ステップＳ１において、クラウド・サービスの要求が第１のクラウド・プロバイダによって受信される。ステップＳ２において、要求を満たすのに必要なリソース要件が評価される。ステップＳ３において、第１のクラウド・プロバイダがリソース要件を満たすのに利用可能なリソースを有するかどうかが判断される。利用可能なリソースを有する場合には、ステップＳ７において、要求が満たされる。利用可能なリソースがない場合には、ステップＳ４において、第１のクラウド・プロバイダが利用可能なリソースとリソース要件との間のあらゆる不足を満たすことができる第２のクラウド・プロバイダが識別される。ステップＳ５において、第２のクラウド・プロバイダのリソースを用いて不足を満たすために、第１のクラウド・プロバイダと第２のクラウド・プロバイダとの間でリソースの割り当てが交渉される。ステップＳ６において、不足に対処するために、第２のクラウド・プロバイダの必要な／欠落したリソースが第１のクラウド・プロバイダに割り当てられ、ステップＳ７において要求を満たすことができるようになる。

本発明は、本明細書においてはクラウド間リソース共有／管理ソリューションとして示され、説明されるが、種々の代替的な実施形態をさらに提供するものであることが理解される。例えば、１つの実施形態においては、本発明は、コンピュータ・インフラストラクチャが本明細書において説明されたクラウド間リソース共有／管理機能を提供できるようにするコンピュータ・プログラム・コードを含むコンピュータ可読／使用可能媒体を提供する。そのために、コンピュータ可読／使用可能媒体は、本発明の種々のプロセスの各々を実装するプログラム・コードを含む。コンピュータ可読媒体又はコンピュータ使用可能媒体という用語は、プログラム・コードのいずれかのタイプの物理的実施形態のうちの１つ又は複数を含むことが理解される。具体的には、コンピュータ可読／使用可能媒体は、１つ又は複数の携帯可能ストレージ製品（例えば、コンパクト・ディスク、磁気ディスク、テープなど）上に、メモリ２８（図１）及び／又はストレージ・システム３４（図１）（例えば、固定ディスク、読み出し専用メモリ、ランダム・アクセス・メモリ、キャッシュ・メモリなど）のようなコンピュータ装置の１つ又は複数のデータ・ストレージ部分上に、及び／又は、（例えば、プログラム・コードの有線／無線による電子的な配布の際に）ネットワーク上で送受信されるデータ信号（例えば、伝播信号）として、具体化されたプログラム・コードを含むことができる。

別の実施形態において、本発明は、加入契約、広告、及び／又は使用料ベースで本発明のプロセスを実施する方法を提供する。すなわち、ソリューション・インテグレータなどのサービス・プロバイダは、クラウド間リソース共有／管理機能を提供することを提案することができる。この場合には、サービス・プロバイダは、１又は複数のカスタマのために本発明のプロセスを実施するコンピュータ・システム１０２（図１）のようなコンピュータ・インフラストラクチャを開発し、保持し、サポートすることなどが可能である。それと引き換えに、サービス・プロバイダは、加入契約及び／又は使用料契約の下で１又は複数のカスタマから支払いを受けることができ、及び／又は、１又は複数の第三者に対する広告コンテンツの販売からの支払いを受けることができる。

さらに別の実施形態において、本発明は、クラウド間リソース共有／管理機能を提供するためのコンピュータ実装方法を提供する。この場合には、コンピュータ・システム１０２（図１）のようなコンピュータ・インフラストラクチャを提供することができ、本発明のプロセスを実施するための１つ又は複数のシステムを取得し（例えば、開発する、購入する、使用する、変更するなど）、コンピュータ・インフラストラクチャに配置することができる。そのためには、システムの配置は、（１）コンピュータ・システム１０２（図１）のようなコンピュータ装置上に、コンピュータ可読媒体からプログラム・コードをインストールすること、（２）１つ又は複数のコンピュータ装置をコンピュータ・インフラストラクチャに追加すること、及び、（３）コンピュータ・インフラストラクチャが本発明のプロセスを実施できるように、コンピュータ・インフラストラクチャの１つ又は複数の既存のシステムを組み込む及び／又は変更すること、のうちの１つ又は複数を含むことができる。

本明細書で用いられるときには、「プログラム・コード」及び「コンピュータ・プログラム・コード」という用語は同義であり、直接的に、又は、（ａ）別の言語、コード、若しくは表記への変換、及び／又は（ｂ）異なる材料形態での複製のいずれか又は両方の後で、情報処理能力を有するコンピュータ装置に特定の機能を実行させるように意図された命令セットの、いずれかの言語、コード、又は表記によるいずれかの表現を意味することが理解される。そのためには、プログラム・コードは、アプリケーション／ソフトウェア・プログラム、コンポーネント・ソフトウェア／関数ライブラリ、オペレーティング・システム、特定のコンピュータ装置についての基本デバイス・システム／ドライバ等の１つ又は複数として具体化することができる。

プログラム・コードを格納及び／又は実行するのに適したデータ処理システムを以下において提供することができ、これは、システム・バスを介して、直接的に又は間接的に、メモリ要素に通信可能に結合される少なくとも１つのプロセッサを含むことができる。メモリ要素は、プログラム・コードの実際の実行中に用いられるローカル・メモリと、大容量記憶装置と、実行中に大容量記憶装置からコードを取り出さなければならない回数を減らすために少なくとも幾つかのプログラム・コードの一時的な記憶場所を提供するキャッシュ・メモリとを含むことができるが、これらに限定されるものではない。入力／出力デバイス（キーボード、ディスプレイ、ポインティング・デバイスなどを含むがこれらに限定されない）は、システムに、直接的に、又は介在するデバイス・コントローラを通じて、結合することができる。

データ処理システムが、介在する私設又は公衆ネットワークのいずれかの組み合わせを通じて他のデータ処理システム、遠隔プリンタ、ストレージ・デバイス及び／又はその他に結合できるように、ネットワーク・アダプタをシステムに結合することもできる。例示的なネットワーク・アダプタとして、モデム、ケーブル・モデム、及びイーサネット・カードが挙げられるが、これらに限定されるものではない。

本発明の種々の態様についての上記の説明は、例示及び説明の目的で提示されたものである。これは、網羅的であること又は本発明を開示された形態そのものに限定することを意図するものではなく、また明らかに、多くの修正及び変形が可能である。当業者には明らかなこうした修正及び変形は、特許請求の範囲によって定められる本発明の範囲内に含まれることが意図されている。

Claims

クラウド・コンピューティング環境におけるクラウド・プロバイダ間のリソース共有のための方法であって、前記クラウド・プロバイダそれぞれは、コンシューマ又はリクエスタによって要求されたサービスを提供し、且つ他のクラウド・プロバイダにリソースを提供することが可能であり、ウェブ・ポータル・システムが第１のクラウド・プロバイダ及び第２のクラウド・プロバイダと接続されており、並びに、前記ウェブ・ポータル・システムが、各クラウド・プロバイダの利用可能なリソースのタイプ、リソースの量、リソースの計画済みの及び現在の利用可能性、及びリソース使用制限を記述するリソース・ディレクトリと、トランザクション・エンジンとを備えており、
前記トランザクション・エンジンが、前記第１のクラウド・プロバイダが利用可能なリソースと、前記第１のクラウド・プロバイダにおいて受信された要求を満たすのに必要なリソース要件との間のいずれかの不足を満たすことができる第２のクラウド・プロバイダを、前記リソース・ディレクトリを参照して識別するステップ
を実行し、
前記第２のクラウド・プロバイダのリソースを用いて前記不足を満たすために、前記第１のクラウド・プロバイダと前記第２のクラウド・プロバイダとの間で交渉が行われて、当該交渉の成功に基づいて、前記不足に対処するために前記第２のクラウド・プロバイダの前記リソースが前記第１のクラウド・プロバイダに割り当てられる、前記方法。
前記識別が、前記第１のクラウド・プロバイダが前記第２のクラウド・プロバイダに対してどのくらい過去に使用されたか、及び、前記第２のクラウド・プロバイダが前記第２のクラウド・プロバイダに対してどのくらい過去に使用されたか、に基づいて行われる、請求項１に記載の方法。
前記識別が、過去の使用回数の負債を消すように行われる、請求項２に記載の方法。
前記交渉が、前記第２のクラウド・プロバイダの前記リソースの使用について、前記第１のクラウド・プロバイダと前記第２のクラウド・プロバイダとの間で補償の交換を交渉することを含む、請求項１〜３のいずれか一項に記載の方法。
前記リソース要件は、ストレージ空間の利用可能性又はプロセッサの利用可能性のうちの少なくとも１つを含む、請求項１〜４のいずれか一項に記載の方法。
クラウド・コンピューティング環境におけるクラウド・プロバイダ間のリソース共有のためのウェブ・ポータル・システムであって、前記クラウド・プロバイダはそれぞれ他のクラウド・プロバイダにリソースを提供することが可能であり、
前記ウェブ・ポータル・システムが第１のクラウド・プロバイダ及び第２のクラウド・プロバイダと接続されており、
前記ウェブ・ポータル・システムが、
各クラウド・プロバイダの利用可能なリソースのタイプ、リソースの量、リソースの計画済みの及び現在の利用可能性、及びリソース使用制限を記述するリソース・ディレクトリと、
トランザクション・エンジンと
を備えており、
前記トランザクション・エンジンが、前記第１のクラウド・プロバイダが利用可能なリソースと、前記第１のクラウド・プロバイダにおいて受信された要求を満たすのに必要なリソース要件との間のいずれかの不足を満たすことができる第２のクラウド・プロバイダを、前記リソース・ディレクトリを参照して識別し、
前記識別によって、前記第２のクラウド・プロバイダのリソースを用いて前記不足を満たすために、前記第１のクラウド・プロバイダと前記第２のクラウド・プロバイダとの間で交渉が行われて、当該交渉の成功に基づいて、前記不足に対処するために前記第２のクラウド・プロバイダの前記リソースが前記第１のクラウド・プロバイダに割り当てられる、前記ウェブ・ポータル・システム。
前記識別が、前記第１のクラウド・プロバイダが前記第２のクラウド・プロバイダに対してどのくらい過去に使用されたか、及び、前記第２のクラウド・プロバイダが前記第２のクラウド・プロバイダに対してどのくらい過去に使用されたか、に基づいて行われる、請求項６に記載のウェブ・ポータル・システム。
前記識別が、過去の使用回数の負債を消すように行われる、請求項７に記載のウェブ・ポータル・システム。
前記リソース要件は、ストレージ空間の利用可能性又はプロセッサの利用可能性のうちの少なくとも１つを含む、請求項６〜８のいずれか一項に記載のウェブ・ポータル・システム。