JP2015508207A - サーバ・クラウドにおけるキャパシティ・オン・デマンドを管理するための装置、コンピュータ実装方法、および製造品（サーバ・クラウドにおけるキャパシティ・オン・デマンドの管理） - Google Patents

Abstract

【課題】サーバ・クラウド中のサーバのためのキャパシティ・オン・デマンドを管理するクラウド・キャパシティ・オン・デマンド・マネージャを提供すること。【解決手段】クラウド・キャパシティ・オン・デマンド・マネージャが、サーバ・クラウド中のサーバのためのキャパシティ・オン・デマンドを管理する。クラウド・キャパシティ・オン・デマンド・マネージャは、１つまたは複数のサーバからキャパシティを借りることができ、あるサーバから借りたキャパシティをサーバ・クラウド中の異なるサーバに貸すことができる。サーバ・クラウドがもはや完全な状態でないとき、サーバ・クラウド中にもはやないサーバから借りたキャパシティはディセーブルにされ、サーバ・クラウド中にもはやないサーバは、サーバ・クラウドに貸したキャパシティを回収する。【選択図】図１

Description

本開示は、一般にコンピュータ・システムに関し、より詳細には、サーバ・クラウド中の複数のサーバとのキャパシティ・オン・デマンドを管理することに関する。

コンピュータ・システムに関する今日の問題の１つは、コンピュータ・ハードウェアのコストと、コンピュータ・リソースに対する需要の変動とのバランスをとることである。ほとんどのネットワーク化されたコンピュータ・システムでは、コンピューティング需要が比較的低いときもあれば、コンピューティング需要が非常に高いときもある。会社が、ピーク需要を満たすことのできるコンピュータ・システムを購入した場合、このコンピュータ・システムのキャパシティの多くは、ピーク時以外の間は使用されないことになる。加えて、ピーク需要を満たすためのキャパシティを購入するのにはコストがかさむ。会社が、平均需要を満たすことのできるコンピュータ・システムを購入した場合、コストはより低いが、ピーク時の間、コンピュータ・システムの性能は損なわれる。

よりフレキシブルな解決法をもたらすための方法の１つは、いくつかのリソースがインストールされているが最初はこれらがディセーブルにされているコンピュータ・システムを、コンピュータ・ユーザが購入できるようにするものである。より大きなキャパシティが必要であると顧客が決定したとき、顧客は、コンピュータ・システムのプロバイダとの手続きに入り、いくつかのリソースを固定期間にわたってイネーブルにすることができる。これは、季節的なピークを有する会社の場合には特にうまくいく。会社は、ピーク・シーズンの間は強化されたコンピューティング・パワーを提供する能力のあるコンピュータ・システムを、妥当なコストで購入することができる。必要時に追加のキャパシティを購入できることは、キャパシティ・オン・デマンドとして知られる。

単純な例で説明する。カタログ販売を介して商品を販売する会社が、ホリデー・ショッピングのため毎年１１月および１２月にピーク需要を経験すると仮定する。この会社は、インストールされているが最初はディセーブルにされている１つまたは複数の追加プロセッサを有するコンピュータ・システムを、購入することができる。次いで会社は、コンピュータ・システムのプロバイダと契約を交わし、設定された期間にわたって追加プロセッサ（複数可）をイネーブルにすることができる。コンピュータ・システムが２つの追加プロセッサを有すると仮定し、また、ピーク購買期間が１１月１５日〜１２月１４日の３０日間に及ぶと仮定する。顧客は、１１月１５日から始まる６０プロセッサ日の追加キャパシティを購入することができる。次いで、この２つの追加プロセッサは、３０日間にわたってイネーブルにされることになる（６０プロセッサ日の追加キャパシティを提供する）。６０プロセッサ日が経過すると、２つの追加プロセッサはディセーブルにされる。

サーバ・クラウドは、異なるコンピュータ・システムが共に働くことを可能にする。各サーバは、インストールされているがイネーブルにされていない追加リソース（例えばプロセッサ、メモリなど）を有する場合があるが、これらの追加リソースは、キャパシティ・オン・デマンドに基づいて、必要に応じてイネーブルにすることができる。しかし、クラウド中のサーバがジョブの処理においては通信し協働することができるにもかかわらず、各サーバのキャパシティ・オン・デマンド能力は、他の全てのサーバとは別々であり異なる。したがって、あるサーバが、処理すべき計算集約型のジョブを有し追加のプロセッサ・キャパシティを必要とする場合、このサーバは、サーバ・クラウド中の他のサーバを考慮することなしに、それ自体の利用可能なプロセッサ・キャパシティに基づくやり方でそのようにする。

本発明の目的は、従来技術における課題を解決することにある。

クラウド・キャパシティ・オン・デマンド・マネージャが、サーバ・クラウド中のサーバのためのキャパシティ・オン・デマンドを管理する。クラウド・キャパシティ・オン・デマンド・マネージャは、１つまたは複数のサーバからキャパシティを借りることができ、あるサーバから借りたキャパシティをサーバ・クラウド中の異なるサーバに貸す。サーバ・クラウドがもはや完全な状態でないとき、サーバ・クラウド中にもはやないサーバから借りたキャパシティはディセーブルにされ、サーバ・クラウド中にもはやないサーバは、サーバ・クラウドに貸したキャパシティを回収する。

前述および他の特徴および利点は、添付の図面に示す後続のより詳細な記述から明らかになるであろう。

本開示は、添付の図面との関連で述べる。図面では、同様の名称は同様の要素を示す。

クラウド・キャパシティ・オン・デマンド・マネージャを備える装置のブロック図である。 キャパシティ・オン・デマンド・マネージャをそれぞれが有する４つのサーバを含む従来技術のサーバ・クラウド・システムのブロック図である。 クラウド・キャパシティ・オン・デマンド・マネージャを備えるサーバ・クラウド・システムのブロック図である。 サーバ・クラウド中のサーバ間で共有されるキャパシティを示す、図３のサーバ・クラウド・システムのブロック図である。 サーバ・クラウド中のサーバ間でキャパシティを共有する方法の流れ図である。 クラウド永続プロセッサを含むサーバ・クラウド・システムのブロック図である。 サーバ・クラウド中のサーバ間で共有されるキャパシティを示す、図６に示すサーバ・クラウド・システムのブロック図である。 クラウド・キャパシティ・オン・デマンド・マネージャをハードウェア管理コンソール中に備えるサーバ・クラウド・システムのブロック図である。 クラウド・キャパシティ・オン・デマンド・マネージャの一実装形態のブロック図である。 図９に示す借りたキャパシティおよび貸したキャパシティについての特定の一実装形態となり得る実例的なクラウド・リソース・テーブルを示すブロック図である。

本明細書における特許請求の範囲および開示は、サーバ・クラウド中のサーバのためのキャパシティ・オン・デマンドを管理するクラウド・キャパシティ・オン・デマンド・マネージャを提供する。クラウド・キャパシティ・オン・デマンド・マネージャは、１つまたは複数のサーバからキャパシティを借りることができ、あるサーバから借りたキャパシティをサーバ・クラウド中の異なるサーバに貸すことができる。サーバ・クラウドがもはや完全な状態でないとき、サーバ・クラウド中にもはやないサーバから借りたキャパシティはディセーブルにされ、サーバ・クラウド中にもはやないサーバは、サーバ・クラウドに貸したキャパシティを回収する。

図１を参照すると、コンピュータ・システム１００は、クラウド・キャパシティ・オン・デマンド・マネージャを備えるサーバ・コンピュータ・システムの適切な一実装形態である。サーバ・コンピュータ・システム１００は、ＩＢＭ ｅＳｅｒｖｅｒ Ｓｙｓｔｅｍ ｘコンピュータ・システムである。しかし、コンピュータ・システムが複雑なマルチユーザ・コンピューティング装置であろうとシングルユーザ・ワークステーションであろうと組込み制御システムであろうと、本明細書の開示がどんなコンピュータ・システムにも等しく適用されることは、当業者なら理解するであろう。図１に示すように、コンピュータ・システム１００は、１つまたは複数のプロセッサ１１０、メイン・メモリ１２０、大容量記憶インタフェース１３０、表示インタフェース１４０、およびネットワーク・インタフェース１５０を備える。これらのシステム・コンポーネントは、システム・バス１６０の使用によって相互接続される。大容量記憶インタフェース１３０は、ローカル大容量記憶デバイス１５５などの大容量記憶デバイスをコンピュータ・システム１００に接続するのに使用される。ある特定のタイプのローカル大容量記憶デバイス１５５は、読取可能かつ書込可能なＣＤ−ＲＷドライブであり、これは、ＣＤ−ＲＷ１９５に対してデータの記憶および読取りを行うことができる。

メイン・メモリ１２０は、データ１２１、オペレーティング・システム１２２、クラウド処理メカニズム１２３、クラウド・キャパシティ・オン・デマンド・マネージャ１２４、インストールされたリソース１２５、永続リソース１２６、クラウド永続リソース１２７、借りたリソース１２８、および貸したリソース１２９を含むことが好ましい。データ１２１は、コンピュータ・システム１００中の任意のプログラムへの入力または任意のプログラムからの出力としての働きをする、任意のデータを表す。オペレーティング・システム１２２は、マルチタスキング・オペレーティング・システムである。クラウド処理メカニズム１２３は、サーバ１００とサーバ・クラウド中の他のサーバとの間の協働をサポートするソフトウェアである。クラウド・キャパシティ・オン・デマンド・マネージャ１２４は、サーバ・クラウド中のサーバのためのキャパシティ・オン・デマンドを管理し、あるサーバからキャパシティを借りてこのキャパシティを異なるサーバに貸すことができる。インストールされたリソース１２５は、使用されるようにイネーブルにされているか否かにかかわらず、サーバ１００にインストールされたリソースを含む。永続リソース１２６は、サーバ１００上で永続的にイネーブルにされるリソースを含む。クラウド永続キャパシティ１２７は、サーバ１００がメンバとして属するサーバ・クラウド中の任意のサーバに対して永続的にイネーブルにされるリソースのキャパシティを含む。借りたキャパシティ１２８は、サーバ１００がサーバ・クラウド中の他のサーバから借りたリソースのキャパシティを含む。貸したキャパシティ１２９は、サーバ１００がサーバ・クラウド中の他のサーバに貸したリソースのキャパシティを含む。サーバ・クラウド中の他のサーバからキャパシティを借りることによって、クラウド・キャパシティ・オン・デマンド・マネージャ１２４は、サーバ・クラウド中の追加のリソースを用いて動作するためのより大きなフレキシビリティおよびより低いコストを提供する。

コンピュータ・システム１００は、周知の仮想アドレッシング・メカニズムを利用する。この仮想アドレッシング・メカニズムにより、コンピュータ・システム１００のプログラムは、複数のより小さい記憶エンティティ（メイン・メモリ１２０およびローカル大容量記憶デバイス１５５など）へのアクセスではなく、大きい連続したアドレス空間へのアクセスのみを有するかのように挙動することができる。したがって、データ１２１、オペレーティング・システム１２２、クラウド処理メカニズム１２３、クラウド・キャパシティ・オン・デマンド・マネージャ１２４、インストールされたリソース１２５、永続リソース１２６、クラウド永続キャパシティ１２７、借りたキャパシティ１２８、および貸したキャパシティ１２９は、メイン・メモリ１２０中にあるように示されているが、これらのアイテムは必ずしも全てが完全にメイン・メモリ１２０中に同時に含まれるとは限らないことは、当業者なら認識するであろう。また、「メモリ」という用語は、本明細書ではコンピュータ・システム１００の仮想メモリ全体を指すのに総称的に使用され、コンピュータ・システム１００に結合された他のコンピュータ・システムの仮想メモリを含む場合があることにも留意されたい。

プロセッサ１１０は、１つまたは複数のマイクロプロセッサまたは集積回路あるいはその両方から構築されたものとすることができる。プロセッサ１１０は、メイン・メモリ１２０に記憶されたプログラム命令を実行する。メイン・メモリ１２０は、プロセッサ１１０がアクセスできるプログラムおよびデータを記憶する。コンピュータ・システム１００が起動したとき、プロセッサ１１０は最初に、オペレーティング・システム１２２を構成するプログラム命令を実行する。プロセッサ１１０はまた、クラウド・キャパシティ・オン・デマンド・マネージャ１２４を実行する。

コンピュータ・システム１００は単一のプロセッサおよび単一のシステム・バスのみを備えるように示されているが、複数のプロセッサまたは複数のバスあるいはその両方を有するコンピュータ・システムを使用してクラウド・キャパシティ・オン・デマンド・マネージャを実践できることは、当業者なら理解するであろう。加えて、使用されるインタフェースはそれぞれ、計算集約型の処理をプロセッサ１１０からオフロードするのに使用される完全にプログラムされた別々のマイクロプロセッサを備えることが好ましい。しかし、Ｉ／Ｏアダプタを使用してこれらの機能を実施することもできることは、当業者なら理解するであろう。

表示インタフェース１４０は、１つまたは複数の表示装置１６５をコンピュータ・システム１００に直接に接続するのに使用される。これらの表示装置１６５は、ノンインテリジェント（すなわちダム）端末である場合と、完全にプログラム可能なワークステーションである場合とがあるが、これらの表示装置１６５を使用して、コンピュータ・システム１００と交信する能力がシステム管理者およびユーザにもたらされる。しかし、１つまたは複数の表示装置１６５との交信をサポートするために表示インタフェース１４０が設けられているが、ユーザおよび他のプロセスとの必要な全ての対話はネットワーク・インタフェース１５０を介して行うこともできるので、コンピュータ・システム１００は必ずしも表示装置１６５を必要とするとは限らないことに留意されたい。

ネットワーク・インタフェース１５０は、ネットワーク１７０を介してコンピュータ・システム１００を他のコンピュータ・システムまたはワークステーション１７５に接続するのに使用される。ネットワーク・インタフェース１５０は、ネットワーク１７０が今日のアナログ技法もしくはディジタル技法またはその両方を含むか、あるいは将来の何らかのネットワーキング・メカニズムを介するかにかかわらず、電子デバイスを相互接続するための任意の適切な方法を広く表す。ネットワーク・インタフェース１５０は、ネットワーク１７０上の通信を可能にするハードウェアとソフトウェアの組合せを含むことが好ましい。ネットワーク・インタフェース１５０中のソフトウェアは、適切なネットワーク・プロトコルを使用した他のコンピュータ・システム１７５とのネットワーク１７０経由の通信を管理する通信マネージャを含むことが好ましい。多くの異なるネットワーク・プロトコルを使用してネットワークを実現することができる。これらのプロトコルは、コンピュータがネットワークを介して通信するのを可能にする特殊化されたコンピュータ・プログラムである。ＴＣＰ／ＩＰ（伝送制御プロトコル／インターネット・プロトコル）は、ネットワーク・インタフェース１５０内で通信マネージャによって使用できる適切なネットワーク・プロトコルの一例である。

当業者には理解されるであろうが、本発明の態様は、システム、方法、またはコンピュータ・プログラム製品として具体化することができる。したがって、本発明の態様は、完全にハードウェアの実施形態、完全にソフトウェアの実施形態（ファームウェア、常駐ソフトウェア、マイクロコードなどを含む）、または、ソフトウェアとハードウェアの態様を組み合わせた実施形態の形をとることができ、本明細書ではこれらを全て「回路」、「モジュール」、「プロセス」、または「システム」と一般に呼ぶ場合がある。さらに、本発明の態様は、コンピュータ可読プログラム・コードが組み入れられた１つまたは複数のコンピュータ可読媒体において具体化されるコンピュータ・プログラム製品の形をとることもできる。

１つまたは複数のコンピュータ可読媒体の、任意の組合せを利用することができる。コンピュータ可読媒体は、コンピュータ可読信号媒体またはコンピュータ可読記憶媒体とすることができる。コンピュータ可読記憶媒体は、例えば、電子、磁気、光学、電磁、赤外線、もしくは半導体の、システム、装置、またはデバイス、あるいはこれらの適切な組合せとすることができるが、これらに限定されない。コンピュータ可読記憶媒体のより具体的な例（非網羅的なリスト）は、１つもしくは複数のワイヤを有する電気接続、ポータブル・コンピュータ・ディスケット、ハード・ディスク、ランダム・アクセス・メモリ（ＲＡＭ）、読取専用メモリ（ＲＯＭ）、消去可能プログラム可能な読取専用メモリ（ＥＰＲＯＭもしくはフラッシュ・メモリ）、光ファイバ、ポータブル・コンパクト・ディスク読取専用メモリ（ＣＤ−ＲＯＭ）、光学記憶デバイス、磁気記憶デバイス、またはこれらの任意の適切な組合せを含むことになる。この文書のコンテキストでは、コンピュータ可読記憶媒体は、命令実行システム、装置、もしくはデバイスによって使用されるかまたはそれらに関連して使用されるプログラムを、収録あるいは記憶することのできる、任意の有形媒体とすることができる。

コンピュータ可読信号媒体は、例えばベースバンド中にまたは搬送波の一部として、コンピュータ可読プログラム・コードが組み入れられた伝搬データ信号を含むことができる。このような伝搬信号は、電磁、光学、またはこれらの任意の適切な組合せを含めた（ただしこれらに限定されない）様々な形のうちのいずれかをとることができる。コンピュータ可読信号媒体は、コンピュータ可読記憶媒体でない任意のコンピュータ可読媒体であって、命令実行システム、装置、もしくはデバイスによって使用されるかまたはそれらに関連して使用されるプログラムを、通信するか伝搬するかあるいは搬送できる、任意のコンピュータ可読媒体とすることができる。

コンピュータ可読媒体上に組み入れられたプログラム・コードは、ワイヤレス、有線、光ファイバ・ケーブル、ＲＦなど、またはこれらの任意の適切な組合せを含めた（ただしこれらに限定されない）、任意の適切な媒体を使用して伝送することができる。

本発明の態様に関する動作を実施するためのコンピュータ・プログラム・コードは、Ｊａｖａ（Ｒ）、Ｓｍａｌｌｔａｌｋ（Ｒ）、Ｃ＋＋などのオブジェクト指向プログラミング言語、および、「Ｃ」プログラミング言語、Ｓｔｒｅａｍｓ処理言語、または同様のプログラミング言語などの従来の手続き型プログラミング言語を含めた、１つまたは複数のプログラミング言語の任意の組合せで書かれてよい。プログラム・コードは、スタンドアロンのソフトウェア・パッケージとして、完全にユーザのコンピュータ上で実行されるか部分的にユーザのコンピュータ上で実行されるか、一部はユーザのコンピュータ上で実行され一部はリモート・コンピュータ上で実行されるか、または完全にリモート・コンピュータもしくはサーバ上で実行されてよい。最後のシナリオでは、リモート・コンピュータは、ローカル・エリア・ネットワーク（ＬＡＮ）もしくはワイド・エリア・ネットワーク（ＷＡＮ）を含めた任意のタイプのネットワークを介してユーザのコンピュータに接続されてよく、または、接続は、外部コンピュータに対して（例えばインターネット・サービス・プロバイダを使用してインターネットを介して）行われてもよい。

本発明の態様を、本発明の実施形態による方法、装置（システム）、およびコンピュータ・プログラム製品のフローチャート説明またはブロック図あるいはその両方に関して本明細書に述べる。フローチャート説明またはブロック図あるいはその両方の各ブロック、ならびに、フローチャート説明またはブロック図あるいはその両方の中のブロックの組合せを、コンピュータ・プログラム命令によって実現できることは理解されるであろう。これらのコンピュータ・プログラム命令を、汎用コンピュータ、専用コンピュータ、または他のプログラム可能データ処理装置のプロセッサに提供して、マシンを生み出すことができ、したがって、コンピュータまたは他のプログラム可能データ処理装置のプロセッサを介して実行される命令は、フローチャートもしくはブロック図またはその両方の１つあるいは複数のブロック中で指定される機能／行為を実現する手段をもたらす。

これらのコンピュータ・プログラム命令はまた、コンピュータ可読媒体に記憶されてよく、このコンピュータ可読媒体は、コンピュータ、他のプログラム可能データ処理装置、または他のデバイスに、特定の方式で機能するよう指示することができ、したがって、コンピュータ可読媒体に記憶された命令は、フローチャートもしくはブロック図またはその両方の１つあるいは複数のブロック中で指定される機能／行為を実現する命令を含む製造品を生み出す。

コンピュータ・プログラム命令はまた、コンピュータ、他のプログラム可能データ処理装置、または他のデバイスにロードされてよく、それにより、コンピュータ、他のプログラム可能装置、または他のデバイス上で一連の動作ステップが実施されて、コンピュータ実装プロセスが生み出され、したがって、コンピュータまたは他のプログラム可能装置上で実行される命令は、フローチャートもしくはブロック図またはその両方の１つあるいは複数のブロック中で指定される機能／行為を実現するためのプロセスを提供する。

本明細書に開示する方法は、ウェブベースのサービスを提供することの一部として実施することができる。このようなサービスは、例えば、この方法を支払いと引き換えにオンライン・ユーザに提供することを含んでよい。

図２を参照すると、サーバ・クラウド中のサーバの実例的な従来技術構成が、サーバ・クラウド・システム２００として示されている。サーバ・クラウド・システム２００は、４つのサーバ２１０Ａ〜２１０Ｄを含み、これらのサーバは全て、サーバ・クラウド２３０中で何らかのネットワーキング・メカニズムを介して相互接続される。各サーバは、インストールされたプロセッサおよび永続プロセッサを備える。インストールされたプロセッサは、サーバに物理的にインストールされたプロセッサの数を指定し、永続プロセッサの数は、サーバ上で永続的にイネーブルにされるプロセッサの数を指定する。図２の特定の例では、各サーバは、２２５Ａ〜２２５Ｄおよび２２６Ａ〜２２６Ｄに示すように、８つのインストールされたプロセッサおよび２つの永続プロセッサを備える。従来技術のサーバ・クラウド・システム２００中では、各サーバは、それ自体のキャパシティ・オン・デマンド・マネージャ２３２Ａ〜２３２Ｄを備え、これらのキャパシティ・オン・デマンド・マネージャは、キャパシティ・オン・デマンドを提供するための既知の方法によって、各サーバのキャパシティを増大させることができる。しかし、サーバごとのキャパシティ・オン・デマンド・マネージャは、サーバ・クラウド２３０中の他のサーバ上のキャパシティから独立して扱われる。したがって、各キャパシティ・オン・デマンド・マネージャ２３２Ａ〜２３２Ｄの機能は、サーバがサーバ・クラウド２３０の一部であるときと、サーバがサーバ・クラウド２３０の一部でないときとで違いがない。

図３に、従来技術のサーバ・クラウド・システム２００にいくつかの点で類似するサーバ・クラウド・システム３００を示す。サーバ・クラウド・システム３００は、サーバ・クラウド３３０中で何らかのネットワーキング・メカニズムを介して相互接続される４つのサーバ３１０Ａ〜３１０Ｄを含む。サーバ３１０Ａ〜３１０Ｄはそれぞれ、図１に示すサーバ・コンピュータ・システム１００とすることができる。各サーバは、８つのインストールされたプロセッサ３２５Ａ〜３２５Ｄ、および２つの永続プロセッサ３２６Ａ〜３２６Ｄを備える。しかし、サーバ３１０Ａは追加で、クラウド・キャパシティ・オン・デマンド・マネージャ１２４も備え、これは、サーバ・クラウド中のサーバのためのキャパシティ・オン・デマンドを管理し、必要時に、あるサーバから、別のサーバに貸されるキャパシティを借りることができる。各サーバ３１０Ａ〜３１０Ｄは、キャパシティを借りることとキャパシティを貸すことの両方ができるので、各サーバは、借りたプロセッサ３２８Ａ〜３２８Ｄ、および貸したプロセッサ３２９Ａ〜３２９Ｄを追跡する。３２８Ａ〜３２８Ｄは、図３では「借りたプロセッサ」として示されているが、実際には、借りた、プロセッサのキャパシティである。同様に、３２９Ａ〜３２９Ｄは、図３では「貸したプロセッサ」として示されているが、実際には、貸した、プロセッサのキャパシティである。図３に示す構成では、各サーバが、その２つの永続プロセッサによってそれ自体の処理負荷を扱うことができると仮定する。

次に図４に移るが、この例では、サーバ３１０Ｄが処理負荷の増大のせいで追加のプロセッサ・キャパシティを必要とすると仮定し、さらに、サーバ３１０Ｄが、既にイネーブルにされている２つの永続プロセッサ３２６Ｄに加えて、３つの追加プロセッサのキャパシティを必要とすると仮定する。従来技術では、サーバ３１０Ｄ上のキャパシティ・オン・デマンド・マネージャが、インストールされたプロセッサのうちのさらに３つをイネーブルにすることができ、その結果、サーバ３１０Ｄには合計５つの永続プロセッサがあることになる。しかし、クラウド・キャパシティ・オン・デマンド・マネージャ１２４は、サーバ・クラウド中の１つまたは複数のサーバから一時的に借りてサーバ３１０Ｄに貸すことのできる未使用キャパシティがサーバ・クラウド中にある可能性があると認識する。図４の特定の例では、サーバ３１０Ａ、３１０Ｂ、および３１０Ｃの各々が、各サーバ上の２つの永続プロセッサのうちの一方を使用してそれらの作業負荷を処理できると仮定する。このことは、各サーバが、追加のキャパシティを必要とするサーバ３１０Ｄに貸せる１つのプロセッサのキャパシティを有することを意味する。したがって、クラウド・キャパシティ・オン・デマンド・マネージャ１２４は、図４の３２６Ａ〜３２６Ｃに示すように、永続プロセッサの数を２から１に減少させ、図４の３２９Ａ〜３２９Ｃに示すように、貸したプロセッサの数を０から１に増加させる。次いで、クラウド・キャパシティ・オン・デマンド・マネージャは、図４の３つの借りたプロセッサ３２８Ｄを提供する矢印付き点線によって示すように、これらの貸したプロセッサ３２９Ａ〜３２９Ｃのキャパシティをサーバ３１０Ｄに貸すことができる。図４で貸されるものおよび借りられるものは、プロセッサ・キャパシティであることに留意されたい。したがって、図３に示すサーバ・クラウド・システム３００中でイネーブルにされるプロセッサの総数は、４つの各サーバ上の２つの永続プロセッサ３２６Ａ〜３２６Ｂであり、合計８つのプロセッサがイネーブルにされる。図３に示すサーバ・クラウド・システム３００中でイネーブルにされるプロセッサの総数は依然として８つであり、これらは、３つのサーバの各々からの１つの永続プロセッサ３２６Ａ〜３２６Ｃと、サーバ３１０Ｄ上の２つの永続プロセッサ３２６Ｄと、サーバ３１０Ｄ上の３つの借りたプロセッサ３２８Ｄである。クラウド・キャパシティ・オン・デマンド・マネージャが、あるサーバからキャパシティを借りてこのキャパシティをサーバ・クラウド中の異なるサーバに貸すことができることにより、顧客が特定のサーバのために追加のキャパシティを購入するのではなくサーバ上の未使用キャパシティを利用するのを可能にすることになる極めてフレキシブルなシステムがもたらされる。この結果、サーバ・クラウド中の総キャパシティをより効率的に、よりコスト効果のある方式で使用するシステムとなる。

図５を参照すると、方法５００は、サーバ・クラウドが確立されるときに開始する（ステップ５１０）。サーバ・クラウドが完全な状態であり（ステップ５２０＝はい）、サーバ・クラウド中のサーバが追加のキャパシティを必要とし（ステップ５３０＝はい）、サーバ・クラウド中の１つまたは複数の他のサーバが貸すためのキャパシティを有するとき（ステップ５４０＝はい）は、１つまたは複数の他のサーバはキャパシティを貸し（ステップ５５０）、サーバは借りたキャパシティを使用する（ステップ５６０）。サーバ・クラウド中のどのサーバも追加キャパシティを必要としないとき（ステップ５３０＝いいえ）は、方法５００はステップ５２０にループバックして継続する。同様に、他のどのサーバも貸すためのキャパシティを有さないとき（ステップ５４０＝いいえ）は、方法５００はステップ５２０にループバックして継続する。方法５００は、サーバ・クラウドがもはや完全な状態でなくなるまで（ステップ５２０＝いいえ）継続することができ、サーバ・クラウドが完全な状態でなくなった時点で、借りたキャパシティはディセーブルにされ（ステップ５７０）、貸したキャパシティは回収される（ステップ５８０）。ステップ５７０および５８０は、２つの異なる方式で機能する場合があることに留意されたい。第１の実装形態では、あるサーバがもはやサーバ・クラウドのメンバでないせいでサーバ・クラウドがもはや完全な状態でないとき（ステップ５２０＝いいえ）は、サーバ・クラウド中の全てのサーバ上の借りたキャパシティはステップ５７０でディセーブルにされ、サーバ・クラウド中の全てのサーバ上の貸したキャパシティは回収される。第２の実装形態では、あるサーバ（紛失サーバ）がもはやサーバ・クラウドのメンバでないせいでサーバ・クラウドがもはや完全な状態でないとき（ステップ５２０＝いいえ）は、紛失サーバからキャパシティを借りてまだサーバ・クラウド中にあるサーバがあればそのサーバ中で、紛失サーバに対する借りたキャパシティはステップ５７０でディセーブルにされる。紛失サーバは、それ自体がもはやサーバ・クラウドのメンバでないことを検出すると、ステップ５８０で、貸したキャパシティを回収する。第１の実装形態は、オール・オア・ナッシング手法であり、サーバ・クラウド中のいずれかのサーバが失われると、全ての借りたキャパシティはディセーブルにされ、全ての貸したキャパシティは回収される。第２の実装形態では、選択的に、紛失サーバから借りたキャパシティがディセーブルにされ、紛失サーバ上の貸したキャパシティが回収されるが、サーバ・クラウド中の残りのサーバは、紛失サーバが失われたことによって影響を受けない借りたキャパシティおよび貸したキャパシティを使用して機能することができる。

ステップ５２０で、サーバ・クラウドが完全な状態であるかどうかの判定は、任意の適切な方式で行うことができる。例えば、特定の一実装形態では、サーバ・クラウド中のサーバ間でトークンが回されて、サーバ・クラウドが維持される。あるサーバがそのトークンを定義済み期間内に送らなかった場合は、このサーバはもはや正しく機能していないと見なされ、このことは、サーバ・クラウドがもはや完全な状態でないことを意味する。代替の一実装形態では、クラウド・キャパシティ・オン・デマンド・マネージャは、サーバ・クラウドのメンバのログをとることができ、サーバ・クラウド中の各サーバに定期的に問い合わせることができる。各サーバが適切な応答によって応答した場合、クラウド・キャパシティ・オン・デマンド・マネージャは、サーバ・クラウドがまだ完全な状態であることを知る。サーバのうちの１つが応答しなかった場合は、クラウド・キャパシティ・オン・デマンド・マネージャは、応答しなかったサーバが正しく機能していないこと、したがってもはやサーバ・クラウド中にないことを知る。次いで、クラウド・キャパシティ・オン・デマンド・マネージャは、上に論じた措置を講じて、借りたキャパシティをディセーブルにし、貸したキャパシティを回収することができる。本明細書における開示および特許請求の範囲は、現在知られている方法であろうと将来開発される方法であろうと、サーバ・クラウドが完全な状態であるかどうか判定するための任意の適切な方法に及ぶ。

クラウド・キャパシティ・オン・デマンド・マネージャ１２４は、サーバ・クラウド中のサーバにまたがってキャパシティを管理することができるので、このことは、図６に示す新しい概念を引き起こす。サーバ・クラウド・システム６００は、４つのサーバ６１０Ａ〜６１０Ｄを含み、これらのサーバは、同じインストールされたプロセッサ３２５Ａ〜３２５Ｄ、永続プロセッサ３２６Ａ〜３２６Ｄ、借りたプロセッサ３２８Ａ〜３２８Ｄ、および貸したプロセッサ３２９Ａ〜３２９Ｄを有する。サーバ６１０Ａ〜６１０Ｄはそれぞれ、図１に示すサーバ・コンピュータ・システム１００とすることができる。加えて、「クラウド永続プロセッサ」と本明細書で呼ぶ新しい概念が導入され、それにより、永続的にイネーブルにされサーバ・クラウド中のどのサーバによっても使用できる、サーバ上のキャパシティが表される。図６の特定の例では、各サーバ６１０Ａ〜６１０Ｄは、２つのクラウド永続プロセッサ６２７Ａ〜６２７Ｄを備える。これらのクラウド永続プロセッサについてのこれらのキャパシティは、クラウド永続プロセッサが存在するサーバを含めた、サーバ・クラウド６３０中のどのサーバによっても使用することができる。

図７を参照するが、キャパシティの貸し借りを促した図４の条件と同じ条件、すなわち、サーバ６１０Ｄがさらに３つのプロセッサ分の３つのキャパシティを必要とするという条件を仮定する。サーバ６１０Ｄは、２つのクラウド永続プロセッサ６２７Ｄを使用することができ、図７の矢印付き点線で示すように、第３の必要なプロセッサをサーバ６１０Ｃから借りることができる。サーバ６１０Ｃ上の１つの貸したプロセッサ３２９Ｃは、クラウド永続プロセッサ６２７Ｃの数を２から１に減少させることに留意されたい。クラウド永続プロセッサと呼ばれるこの新しい特徴を定義することによって、クラウド・キャパシティ・オン・デマンド・マネージャは、サーバ・クラウド中のサーバ間でどのリソースが借りられるかまたは貸されるかに関して、より大きなフレキシビリティを有することができる。例えば、クラウド・キャパシティ・オン・デマンド・マネージャ１２４は、最初に、全てのクラウド永続プロセッサを借りることができる。というのは、これらは、サーバ上のいずれかの永続プロセッサを借りる前にクラウド処理のために確保されるからである。代替方式では、クラウド永続プロセッサは、サーバ・クラウド中のサーバ間で共有することが許可される唯一のキャパシティとすることができる。永続プロセッサとは別に定義されたクラウド永続プロセッサのキャパシティを有することによって、クラウド・キャパシティ・オン・デマンド・マネージャ１２４は、サーバ・クラウド全体にわたるキャパシティの貸し借りにおいてより大きなフレキシビリティを有する。

図３、４、６、および７では、クラウド・キャパシティ・オン・デマンド・マネージャ１２４は、サーバ・クラウド中の１つのサーバ上にあるように示されている。代替の一実装形態では、クラウド・キャパシティ・オン・デマンド・マネージャ１２４は、図８に示すように、サーバ・クラウド中の別個のエンティティ上にあってもよい。サーバ・クラウド・システム８００では、４つのサーバ８１０Ａ、６１０Ｂ、６１０Ｃ、および６１０Ｄが、サーバ・クラウド８３０中で相互接続される。サーバ・クラウド８３０中ではハードウェア管理コンソール８２０も接続され、ハードウェア管理コンソール８２０は、クラウド・キャパシティ・オン・デマンド・マネージャ１２４を備える。ハードウェア管理コンソール８２０は、サーバ・クラウド中のサーバを構成するのを可能にし、サーバ・クラウド中のサーバ中のリソースおよびキャパシティを管理するためのユーザ・インタフェースを提供する。ハードウェア管理コンソール８２０はまた、サーバ・クラウド中のサーバを監視することができ、サーバ・クラウドがもはや完全な状態でないときを検出することができる。このように、ハードウェア管理コンソール８２０は、サーバの関係をサーバ自体に管理させるのではなく、サーバ外の独立した制御ポイントを提供し、これにより、サーバがサーバ・クラウドを去るときがより容易になる。例えば、図７で、サーバ６１０Ａが動作不良を起こして応答しなくなった場合、クラウド・キャパシティ・オン・デマンド・マネージャ１２４は、もはやその仕事を行うことができない。図８に示すようにクラウド・キャパシティ・オン・デマンド・マネージャ１２４を別個のハードウェア管理コンソール８２０中に配置することによって、クラウド・キャパシティ・オン・デマンド・マネージャ１２４は、どのサーバがサーバ・クラウドを去るかにかかわらず機能し続けることができる。

図９を参照すると、クラウド・キャパシティ・オン・デマンド・マネージャ１２４は、クラウド・メンバシップ９１０、すなわちどのサーバがサーバ・クラウドのメンバであるかを追跡し、借りたキャパシティ９２０および貸したキャパシティ９３０を追跡する。クラウド・キャパシティ・オン・デマンド・マネージャ１２４はまた、キャパシティ照会メカニズム９４０を備え、このキャパシティ照会メカニズム９４０は、サーバ・クラウド中の各サーバに照会して、サーバが貸すためのキャパシティを有するかどうか判定することができる（図５のステップ５４０参照）。借りたキャパシティ９２０および貸したキャパシティ９３０は、任意の適切な方式で追跡することができる。例えば、図１０に示すクラウド・リソース・テーブル１０１０は、借りたキャパシティ９２０および貸したキャパシティ９３０の状況を常に把握するための適切な方法の１つを表す。エントリ１０２０は、Ｐ３のキャパシティＩＤ、プロセッサのリソース・タイプ、および、サーバＡがこのキャパシティの所有元でありこのキャパシティがまだ貸し出されていないことを示す。エントリ１０３０は、Ｐ１４のキャパシティＩＤ、プロセッサのリソース・タイプ、および、サーバＣがこのキャパシティの所有元でありこのキャパシティがサーバＤに貸されたことを示す。借りたキャパシティおよび貸したキャパシティの状況を常に把握することによって、クラウド・キャパシティ・オン・デマンド・マネージャ１２４は、サーバ・クラウドがもはや完全な状態でないときに、借りたキャパシティをディセーブルにすることができる（図７のステップ５７０参照）。各サーバは、サーバがもはやサーバ・クラウド中にないときを検出できるメカニズムを備えることが好ましく、それに応答して、クラウド中の他のサーバに既に貸し出したキャパシティがあればそれを回収することになることに留意されたい（図８のステップ５８０参照）。

上記の例ではプロセッサについて論じているが、プロセッサは、サーバ・クラウド内で貸し借りできるキャパシティを有するリソースの適切な一例を表す。本明細書における開示および特許請求の範囲は、サーバ中の任意の適切なリソース、およびサーバ・クラウド中の任意の適切なリソースに明白に及び、限定ではないがこれらのリソースは、プロセッサ、メモリ、入出力（Ｉ／Ｏ）スロット、ネットワーク・アダプタなどを含む。また、クラウド・キャパシティ・オン・デマンド・マネージャによって貸し借りされているものは、リソース自体ではなく、リソースのキャパシティであることにも留意されたい。したがって、サーバ３１０Ｄが２つの永続プロセッサ３２６Ｄおよび３つの借りたプロセッサ３２８Ｄを有するとき、このことは、サーバ３１０Ｄ中の８つのインストールされたプロセッサ３２５Ｄのうちの５つを使用できることを意味する。「借りたプロセッサ」３２８Ｄは、他のサーバから借りた、プロセッサのキャパシティを表す。サーバ上の永続プロセッサと借りたプロセッサの合計は、インストールされたプロセッサの総数を超えることはできないことに留意されたい。

本開示および特許請求の範囲は、サーバ・クラウド中のサーバのためのキャパシティ・オン・デマンドを管理するクラウド・キャパシティ・オン・デマンド・マネージャに関する。クラウド・キャパシティ・オン・デマンド・マネージャは、１つまたは複数のサーバからキャパシティを借りることができ、あるサーバから借りたキャパシティをサーバ・クラウド中の異なるサーバに貸すことができる。サーバ・クラウドがもはや完全な状態でないとき、サーバ・クラウド中にもはやないサーバから借りたキャパシティはディセーブルにされ、サーバ・クラウド中にもはやないサーバは、サーバ・クラウドに貸したキャパシティを回収する。

請求項の範囲内で多くの変形が可能であることは、当業者なら理解するであろう。したがって、本開示について特に図示および上述しているが、請求項の主旨および範囲を逸脱することなく、形式および詳細におけるこれらおよび他の変更を本開示に加えることができることは、当業者には理解されるであろう。

Claims (19)

1. 少なくとも１つのプロセッサと、
   前記少なくとも１つのプロセッサに結合されたメモリと、
   前記メモリ中にあり前記少なくとも１つのプロセッサによって実行されるクラウド・キャパシティ・オン・デマンド・マネージャとを備える装置であって、前記クラウド・キャパシティ・オン・デマンド・マネージャが、前記装置を含むサーバ・クラウド中の複数のサーバのために複数のリソースのキャパシティを管理し、前記クラウド・キャパシティ・オン・デマンド・マネージャが、前記サーバ・クラウド中の前記複数のサーバのうちの少なくとも１つのサーバから、前記複数のリソースのうちの少なくとも１つのリソースのキャパシティを借り、前記サーバ・クラウドが完全な状態である限り、前記借りたキャパシティを前記サーバ・クラウド中の前記複数のサーバのうちの異なるサーバに貸し、前記サーバ・クラウドがもはや完全な状態でないとき、前記クラウド・キャパシティ・オン・デマンド・マネージャが、借りたキャパシティをディセーブルにし、貸したキャパシティを回収する、装置。
2. 前記複数のサーバのうちの少なくとも１つのサーバが、前記サーバ・クラウド中のいずれか他のサーバと共有できるクラウド永続キャパシティを備え、前記クラウド永続キャパシティが、前記サーバ・クラウド中の前記複数のサーバのうちの前記１つのサーバ上で永続的にイネーブルにされるキャパシティであって前記サーバ・クラウド中の他のサーバと共有できるキャパシティである、請求項１に記載の装置。
3. 前記複数のリソースがプロセッサを含む、請求項１に記載の装置。
4. 前記複数のリソースがメモリを含む、請求項１に記載の装置。
5. 前記複数のサーバのうちの１つのサーバがもはや前記サーバ・クラウド中にないせいで前記サーバ・クラウドがもはや完全な状態でないとき、前記クラウド・キャパシティ・オン・デマンド・マネージャが、前記複数のサーバ全てからの全ての借りたキャパシティをディセーブルにし、前記複数のサーバ全てからの全ての貸したキャパシティを回収する、請求項１に記載の装置。
6. 前記複数のサーバのうちの１つのサーバがもはや前記サーバ・クラウド中にないせいで前記サーバ・クラウドがもはや完全な状態でないとき、前記クラウド・キャパシティ・オン・デマンド・マネージャが、前記１つのサーバから借りた、借りたキャパシティをディセーブルにし、前記１つのサーバ上の貸したキャパシティを回収し、まだ前記サーバ・クラウド中にある複数のサーバについての他の借りたキャパシティおよび貸したキャパシティを保持する、請求項１に記載の装置。
7. サーバ・クラウド中の複数のサーバのために複数のリソースのキャパシティを管理するための、少なくとも１つのプロセッサによって実行されるコンピュータ実装方法であって、
   （Ａ）前記サーバ・クラウド中の前記複数のサーバのうちの少なくとも１つのサーバから、前記複数のリソースのうちの少なくとも１つのリソースのキャパシティを借りるステップと、
   （Ｂ）前記サーバ・クラウドが完全な状態である限り、前記借りたキャパシティを前記サーバ・クラウド中の前記複数のサーバのうちの異なるサーバに貸すステップと、
   （Ｃ）前記サーバ・クラウドがもはや完全な状態でないとき、クラウド・キャパシティ・オン・デマンド・マネージャが、借りたキャパシティをディセーブルにし、貸したキャパシティを回収するステップとを含む方法。
8. 前記サーバ・クラウド中の前記複数のサーバのうちの少なくとも１つのサーバ中のクラウド永続キャパシティを、前記サーバ・クラウド中の別のサーバと共有するステップをさらに含み、前記クラウド永続キャパシティが、前記サーバ・クラウド中の前記複数のサーバのうちの前記１つのサーバ上で永続的にイネーブルにされるキャパシティであって前記サーバ・クラウド中の他のサーバと共有できるキャパシティである、請求項７に記載の方法。
9. 前記複数のリソースがプロセッサを含む、請求項７に記載の方法。
10. 前記複数のリソースがメモリを含む、請求項７に記載の方法。
11. ステップ（Ｃ）が、
    前記複数のサーバのうちの１つのサーバがもはや前記サーバ・クラウド中にないせいで前記サーバ・クラウドがもはや完全な状態でないときに、
    前記複数のサーバ全てからの全ての借りたキャパシティをディセーブルにするステップと、
    前記複数のサーバ全てからの全ての貸したキャパシティを回収するステップとを含む、請求項７に記載の方法。
12. ステップ（Ｃ）が、
    前記複数のサーバのうちの１つのサーバがもはや前記サーバ・クラウド中にないせいで前記サーバ・クラウドがもはや完全な状態でないときに、
    前記１つのサーバから借りた、借りたキャパシティをディセーブルにするステップと、
    前記１つのサーバ上の貸したキャパシティを回収するステップと、
    まだ前記サーバ・クラウド中にある複数のサーバについての他の借りたキャパシティおよび貸したキャパシティを保持するステップとを含む、請求項７に記載の方法。
13. サーバ・クラウド中の複数のサーバのために複数のリソースのキャパシティを管理するための、少なくとも１つのプロセッサによって実行されるコンピュータ実装方法であって、
    前記サーバ・クラウド中の前記複数のサーバのうちの少なくとも１つのサーバから、前記複数のリソースのうちの少なくとも１つのリソースのクラウド永続キャパシティを借りるステップであって、前記複数のリソースがプロセッサおよびメモリを含み、前記クラウド永続キャパシティが、前記サーバ・クラウド中の前記複数のサーバのうちの前記１つのサーバ上で永続的にイネーブルにされるキャパシティであって前記サーバ・クラウド中の他のサーバと共有できるキャパシティである、前記借りるステップと、
    前記サーバ・クラウドが完全な状態である限り、前記借りたキャパシティを前記サーバ・クラウド中の前記複数のサーバのうちの異なるサーバに貸すステップと、
    前記複数のサーバのうちの１つのサーバがもはや前記サーバ・クラウド中にないせいで前記サーバ・クラウドがもはや完全な状態でないときに、
    前記１つのサーバから借りた、借りたキャパシティをディセーブルにするステップ、
    前記１つのサーバ上の貸したキャパシティを回収するステップ、ならびに、
    まだ前記サーバ・クラウド中にある複数のサーバについての他の借りたキャパシティおよび貸したキャパシティを保持するステップを実施するステップとを含む方法。
14. 非一時的コンピュータ可読記憶媒体に記憶されたソフトウェアを含む製造品であって、前記ソフトウェアが、
    サーバ・クラウド中の複数のサーバのために複数のリソースのキャパシティを管理するクラウド・キャパシティ・オン・デマンド・マネージャを備え、前記クラウド・キャパシティ・オン・デマンド・マネージャが、前記サーバ・クラウド中の前記複数のサーバのうちの少なくとも１つのサーバから、前記複数のリソースのうちの少なくとも１つのリソースのキャパシティを借り、前記サーバ・クラウドが完全な状態である限り、前記借りたキャパシティを前記サーバ・クラウド中の前記複数のサーバのうちの異なるサーバに貸し、前記サーバ・クラウドがもはや完全な状態でないとき、前記クラウド・キャパシティ・オン・デマンド・マネージャが、借りたキャパシティをディセーブルにし、貸したキャパシティを回収する、製造品。
15. 前記複数のサーバのうちの少なくとも１つのサーバが、前記サーバ・クラウド中のいずれか他のサーバと共有できるクラウド永続キャパシティを備え、前記クラウド永続キャパシティが、前記サーバ・クラウド中の前記複数のサーバのうちの前記１つのサーバ上で永続的にイネーブルにされるキャパシティであって前記サーバ・クラウド中の他のサーバと共有できるキャパシティである、請求項１４に記載の製造品。
16. 前記複数のリソースがプロセッサを含む、請求項１４に記載の製造品。
17. 前記複数のリソースがメモリを含む、請求項１４に記載の製造品。
18. 前記複数のサーバのうちの１つのサーバがもはや前記サーバ・クラウド中にないせいで前記サーバ・クラウドがもはや完全な状態でないとき、前記クラウド・キャパシティ・オン・デマンド・マネージャが、前記複数のサーバ全てからの全ての借りたキャパシティをディセーブルにし、前記複数のサーバ全てからの全ての貸したキャパシティを回収する、請求項１４に記載の製造品。
19. 前記複数のサーバのうちの１つのサーバがもはや前記サーバ・クラウド中にないせいで前記サーバ・クラウドがもはや完全な状態でないとき、前記クラウド・キャパシティ・オン・デマンド・マネージャが、前記１つのサーバから借りた、借りたキャパシティをディセーブルにし、前記１つのサーバ上の貸したキャパシティを回収し、まだ前記サーバ・クラウド中にある複数のサーバについての他の借りたキャパシティおよび貸したキャパシティを保持する、請求項１４に記載の製造品。

Images