(57)【要約】【課題】サーバ・クラウド中のサーバのためのキャパシティ・オン・デマンドを管理するクラウド・キャパシティ・オン・デマンド・マネージャを提供すること。【解決手段】クラウド・キャパシティ・オン・デマンド・マネージャが、サーバ・クラウド中のサーバのためのキャパシティ・オン・デマンドを管理する。クラウド・キャパシティ・オン・デマンド・マネージャは、１つまたは複数のサーバからキャパシティを借りることができ、あるサーバから借りたキャパシティをサーバ・クラウド中の異なるサーバに貸すことができる。サーバ・クラウドがもはや完全な状態でないとき、サーバ・クラウド中にもはやないサーバから借りたキャパシティはディセーブルにされ、サーバ・クラウド中にもはやないサーバは、サーバ・クラウドに貸したキャパシティを回収する。【選択図】図１
2015149097.tif 000002
【特許請求の範囲】
【請求項１】
サーバ・クラウド中の複数のサーバのために複数のリソースのキャパシティを管理するための、少なくとも１つのプロセッサによって実行されるコンピュータ実装方法であって、
（Ａ）前記サーバ・クラウド中の前記複数のサーバのうちの少なくとも１つのサーバから、前記複数のリソースのうちの少なくとも１つのリソースのキャパシティを借りるステップと、
（Ｂ）前記サーバ・クラウドが完全な状態である限り、前記借りたキャパシティを前記サーバ・クラウド中の前記複数のサーバのうちの異なるサーバに貸すステップと、
（Ｃ）前記サーバ・クラウドがもはや完全な状態でないとき、クラウド・キャパシティ・オン・デマンド・マネージャが、借りたキャパシティをディセーブルにし、貸したキャパシティを回収するステップとを含む方法。
【請求項２】
前記サーバ・クラウド中の前記複数のサーバのうちの少なくとも１つのサーバ中のクラウド永続キャパシティを、前記サーバ・クラウド中の別のサーバと共有するステップをさらに含み、前記クラウド永続キャパシティが、前記サーバ・クラウド中の前記複数のサーバのうちの前記１つのサーバ上で永続的にイネーブルにされるキャパシティであって前記サーバ・クラウド中の他のサーバと共有できるキャパシティである、請求項１に記載の方法。
【請求項３】
前記複数のリソースがプロセッサを含む、請求項１に記載の方法。
【請求項４】
前記複数のリソースがメモリを含む、請求項１に記載の方法。
【請求項５】
ステップ（Ｃ）が、
前記複数のサーバのうちの１つのサーバがもはや前記サーバ・クラウド中にないせいで前記サーバ・クラウドがもはや完全な状態でないときに、
前記複数のサーバ全てからの全ての借りたキャパシティをディセーブルにするステップと、
前記複数のサーバ全てからの全ての貸したキャパシティを回収するステップとを含む、請求項１に記載の方法。
【請求項６】
ステップ（Ｃ）が、
前記複数のサーバのうちの１つのサーバがもはや前記サーバ・クラウド中にないせいで前記サーバ・クラウドがもはや完全な状態でないときに、
前記１つのサーバから借りた、借りたキャパシティをディセーブルにするステップと、
前記１つのサーバ上の貸したキャパシティを回収するステップと、
まだ前記サーバ・クラウド中にある複数のサーバについての他の借りたキャパシティおよび貸したキャパシティを保持するステップとを含む、請求項１に記載の方法。
【請求項７】
サーバ・クラウド中の複数のサーバのために複数のリソースのキャパシティを管理するための、少なくとも１つのプロセッサによって実行されるコンピュータ実装方法であって、
前記サーバ・クラウド中の前記複数のサーバのうちの少なくとも１つのサーバから、前記複数のリソースのうちの少なくとも１つのリソースのクラウド永続キャパシティを借りるステップであって、前記複数のリソースがプロセッサおよびメモリを含み、前記クラウド永続キャパシティが、前記サーバ・クラウド中の前記複数のサーバのうちの前記１つのサーバ上で永続的にイネーブルにされるキャパシティであって前記サーバ・クラウド中の他のサーバと共有できるキャパシティである、前記借りるステップと、
前記サーバ・クラウドが完全な状態である限り、前記借りたキャパシティを前記サーバ・クラウド中の前記複数のサーバのうちの異なるサーバに貸すステップと、
前記複数のサーバのうちの１つのサーバがもはや前記サーバ・クラウド中にないせいで前記サーバ・クラウドがもはや完全な状態でないときに、
前記１つのサーバから借りた、借りたキャパシティをディセーブルにするステップ、
前記１つのサーバ上の貸したキャパシティを回収するステップ、ならびに、
まだ前記サーバ・クラウド中にある複数のサーバについての他の借りたキャパシティおよび貸したキャパシティを保持するステップを実施するステップとを含む方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、一般にコンピュータ・システムに関し、より詳細には、サーバ・クラウド中
の複数のサーバとのキャパシティ・オン・デマンドを管理することに関する。
【背景技術】
【０００２】
コンピュータ・システムに関する今日の問題の１つは、コンピュータ・ハードウェアの
コストと、コンピュータ・リソースに対する需要の変動とのバランスをとることである。
ほとんどのネットワーク化されたコンピュータ・システムでは、コンピューティング需要
が比較的低いときもあれば、コンピューティング需要が非常に高いときもある。会社が、
ピーク需要を満たすことのできるコンピュータ・システムを購入した場合、このコンピュ
ータ・システムのキャパシティの多くは、ピーク時以外の間は使用されないことになる。
加えて、ピーク需要を満たすためのキャパシティを購入するのにはコストがかさむ。会社
が、平均需要を満たすことのできるコンピュータ・システムを購入した場合、コストはよ
り低いが、ピーク時の間、コンピュータ・システムの性能は損なわれる。
【０００３】
よりフレキシブルな解決法をもたらすための方法の１つは、いくつかのリソースがイン
ストールされているが最初はこれらがディセーブルにされているコンピュータ・システム
を、コンピュータ・ユーザが購入できるようにするものである。より大きなキャパシティ
が必要であると顧客が決定したとき、顧客は、コンピュータ・システムのプロバイダとの
手続きに入り、いくつかのリソースを固定期間にわたってイネーブルにすることができる
。これは、季節的なピークを有する会社の場合には特にうまくいく。会社は、ピーク・シ
ーズンの間は強化されたコンピューティング・パワーを提供する能力のあるコンピュータ
・システムを、妥当なコストで購入することができる。必要時に追加のキャパシティを購
入できることは、キャパシティ・オン・デマンドとして知られる。
【０００４】
単純な例で説明する。カタログ販売を介して商品を販売する会社が、ホリデー・ショッ
ピングのため毎年１１月および１２月にピーク需要を経験すると仮定する。この会社は、
インストールされているが最初はディセーブルにされている１つまたは複数の追加プロセ
ッサを有するコンピュータ・システムを、購入することができる。次いで会社は、コンピ
ュータ・システムのプロバイダと契約を交わし、設定された期間にわたって追加プロセッ
サ（複数可）をイネーブルにすることができる。コンピュータ・システムが２つの追加プ
ロセッサを有すると仮定し、また、ピーク購買期間が１１月１５日〜１２月１４日の３０
日間に及ぶと仮定する。顧客は、１１月１５日から始まる６０プロセッサ日の追加キャパ
シティを購入することができる。次いで、この２つの追加プロセッサは、３０日間にわた
ってイネーブルにされることになる（６０プロセッサ日の追加キャパシティを提供する）
。６０プロセッサ日が経過すると、２つの追加プロセッサはディセーブルにされる。
【０００５】
サーバ・クラウドは、異なるコンピュータ・システムが共に働くことを可能にする。各
サーバは、インストールされているがイネーブルにされていない追加リソース（例えばプ
ロセッサ、メモリなど）を有する場合があるが、これらの追加リソースは、キャパシティ
・オン・デマンドに基づいて、必要に応じてイネーブルにすることができる。しかし、ク
ラウド中のサーバがジョブの処理においては通信し協働することができるにもかかわらず
、各サーバのキャパシティ・オン・デマンド能力は、他の全てのサーバとは別々であり異
なる。したがって、あるサーバが、処理すべき計算集約型のジョブを有し追加のプロセッ
サ・キャパシティを必要とする場合、このサーバは、サーバ・クラウド中の他のサーバを
考慮することなしに、それ自体の利用可能なプロセッサ・キャパシティに基づくやり方で
そのようにする。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
本発明の目的は、従来技術における課題を解決することにある。
【課題を解決するための手段】
【０００７】
クラウド・キャパシティ・オン・デマンド・マネージャが、サーバ・クラウド中のサー
バのためのキャパシティ・オン・デマンドを管理する。クラウド・キャパシティ・オン・
デマンド・マネージャは、１つまたは複数のサーバからキャパシティを借りることができ
、あるサーバから借りたキャパシティをサーバ・クラウド中の異なるサーバに貸す。サー
バ・クラウドがもはや完全な状態でないとき、サーバ・クラウド中にもはやないサーバか
ら借りたキャパシティはディセーブルにされ、サーバ・クラウド中にもはやないサーバは
、サーバ・クラウドに貸したキャパシティを回収する。
【０００８】
前述および他の特徴および利点は、添付の図面に示す後続のより詳細な記述から明らか
になるであろう。
【０００９】
本開示は、添付の図面との関連で述べる。図面では、同様の名称は同様の要素を示す。
【図面の簡単な説明】
【００１０】
【図１】クラウド・キャパシティ・オン・デマンド・マネージャを備える装置のブロック図である。
【図２】キャパシティ・オン・デマンド・マネージャをそれぞれが有する４つのサーバを含む従来技術のサーバ・クラウド・システムのブロック図である。
【図３】クラウド・キャパシティ・オン・デマンド・マネージャを備えるサーバ・クラウド・システムのブロック図である。
【図４】サーバ・クラウド中のサーバ間で共有されるキャパシティを示す、図３のサーバ・クラウド・システムのブロック図である。
【図５】サーバ・クラウド中のサーバ間でキャパシティを共有する方法の流れ図である。
【図６】クラウド永続プロセッサを含むサーバ・クラウド・システムのブロック図である。
【図７】サーバ・クラウド中のサーバ間で共有されるキャパシティを示す、図６に示すサーバ・クラウド・システムのブロック図である。
【図８】クラウド・キャパシティ・オン・デマンド・マネージャをハードウェア管理コンソール中に備えるサーバ・クラウド・システムのブロック図である。
【図９】クラウド・キャパシティ・オン・デマンド・マネージャの一実装形態のブロック図である。
【図１０】図９に示す借りたキャパシティおよび貸したキャパシティについての特定の一実装形態となり得る実例的なクラウド・リソース・テーブルを示すブロック図である。
【発明を実施するための形態】
【００１１】
本明細書における特許請求の範囲および開示は、サーバ・クラウド中のサーバのための
キャパシティ・オン・デマンドを管理するクラウド・キャパシティ・オン・デマンド・マ
ネージャを提供する。クラウド・キャパシティ・オン・デマンド・マネージャは、１つま
たは複数のサーバからキャパシティを借りることができ、あるサーバから借りたキャパシ
ティをサーバ・クラウド中の異なるサーバに貸すことができる。サーバ・クラウドがもは
や完全な状態でないとき、サーバ・クラウド中にもはやないサーバから借りたキャパシテ
ィはディセーブルにされ、サーバ・クラウド中にもはやないサーバは、サーバ・クラウド
に貸したキャパシティを回収する。
【００１２】
図１を参照すると、コンピュータ・システム１００は、クラウド・キャパシティ・オン
・デマンド・マネージャを備えるサーバ・コンピュータ・システムの適切な一実装形態で
ある。サーバ・コンピュータ・システム１００は、ＩＢＭ  ｅＳｅｒｖｅｒ  Ｓｙｓｔｅ
ｍ  ｘコンピュータ・システムである。しかし、コンピュータ・システムが複雑なマルチ
ユーザ・コンピューティング装置であろうとシングルユーザ・ワークステーションであろ
うと組込み制御システムであろうと、本明細書の開示がどんなコンピュータ・システムに
も等しく適用されることは、当業者なら理解するであろう。図１に示すように、コンピュ
ータ・システム１００は、１つまたは複数のプロセッサ１１０、メイン・メモリ１２０、
大容量記憶インタフェース１３０、表示インタフェース１４０、およびネットワーク・イ
ンタフェース１５０を備える。これらのシステム・コンポーネントは、システム・バス１
６０の使用によって相互接続される。大容量記憶インタフェース１３０は、ローカル大容
量記憶デバイス１５５などの大容量記憶デバイスをコンピュータ・システム１００に接続
するのに使用される。ある特定のタイプのローカル大容量記憶デバイス１５５は、読取可
能かつ書込可能なＣＤ−ＲＷドライブであり、これは、ＣＤ−ＲＷ１９５に対してデータ
の記憶および読取りを行うことができる。
【００１３】
メイン・メモリ１２０は、データ１２１、オペレーティング・システム１２２、クラウ
ド処理メカニズム１２３、クラウド・キャパシティ・オン・デマンド・マネージャ１２４
、インストールされたリソース１２５、永続リソース１２６、クラウド永続リソース１２
７、借りたリソース１２８、および貸したリソース１２９を含むことが好ましい。データ
１２１は、コンピュータ・システム１００中の任意のプログラムへの入力または任意のプ
ログラムからの出力としての働きをする、任意のデータを表す。オペレーティング・シス
テム１２２は、マルチタスキング・オペレーティング・システムである。クラウド処理メ
カニズム１２３は、サーバ１００とサーバ・クラウド中の他のサーバとの間の協働をサポ
ートするソフトウェアである。クラウド・キャパシティ・オン・デマンド・マネージャ１
２４は、サーバ・クラウド中のサーバのためのキャパシティ・オン・デマンドを管理し、
あるサーバからキャパシティを借りてこのキャパシティを異なるサーバに貸すことができ
る。インストールされたリソース１２５は、使用されるようにイネーブルにされているか
否かにかかわらず、サーバ１００にインストールされたリソースを含む。永続リソース１
２６は、サーバ１００上で永続的にイネーブルにされるリソースを含む。クラウド永続キ
ャパシティ１２７は、サーバ１００がメンバとして属するサーバ・クラウド中の任意のサ
ーバに対して永続的にイネーブルにされるリソースのキャパシティを含む。借りたキャパ
シティ１２８は、サーバ１００がサーバ・クラウド中の他のサーバから借りたリソースの
キャパシティを含む。貸したキャパシティ１２９は、サーバ１００がサーバ・クラウド中
の他のサーバに貸したリソースのキャパシティを含む。サーバ・クラウド中の他のサーバ
からキャパシティを借りることによって、クラウド・キャパシティ・オン・デマンド・マ
ネージャ１２４は、サーバ・クラウド中の追加のリソースを用いて動作するためのより大
きなフレキシビリティおよびより低いコストを提供する。
【００１４】
コンピュータ・システム１００は、周知の仮想アドレッシング・メカニズムを利用する
。この仮想アドレッシング・メカニズムにより、コンピュータ・システム１００のプログ
ラムは、複数のより小さい記憶エンティティ（メイン・メモリ１２０およびローカル大容
量記憶デバイス１５５など）へのアクセスではなく、大きい連続したアドレス空間へのア
クセスのみを有するかのように挙動することができる。したがって、データ１２１、オペ
レーティング・システム１２２、クラウド処理メカニズム１２３、クラウド・キャパシテ
ィ・オン・デマンド・マネージャ１２４、インストールされたリソース１２５、永続リソ
ース１２６、クラウド永続キャパシティ１２７、借りたキャパシティ１２８、および貸し
たキャパシティ１２９は、メイン・メモリ１２０中にあるように示されているが、これら
のアイテムは必ずしも全てが完全にメイン・メモリ１２０中に同時に含まれるとは限らな
いことは、当業者なら認識するであろう。また、「メモリ」という用語は、本明細書では
コンピュータ・システム１００の仮想メモリ全体を指すのに総称的に使用され、コンピュ
ータ・システム１００に結合された他のコンピュータ・システムの仮想メモリを含む場合
があることにも留意されたい。
【００１５】
プロセッサ１１０は、１つまたは複数のマイクロプロセッサまたは集積回路あるいはそ
の両方から構築されたものとすることができる。プロセッサ１１０は、メイン・メモリ１
２０に記憶されたプログラム命令を実行する。メイン・メモリ１２０は、プロセッサ１１
０がアクセスできるプログラムおよびデータを記憶する。コンピュータ・システム１００
が起動したとき、プロセッサ１１０は最初に、オペレーティング・システム１２２を構成
するプログラム命令を実行する。プロセッサ１１０はまた、クラウド・キャパシティ・オ
ン・デマンド・マネージャ１２４を実行する。
【００１６】
コンピュータ・システム１００は単一のプロセッサおよび単一のシステム・バスのみを
備えるように示されているが、複数のプロセッサまたは複数のバスあるいはその両方を有
するコンピュータ・システムを使用してクラウド・キャパシティ・オン・デマンド・マネ
ージャを実践できることは、当業者なら理解するであろう。加えて、使用されるインタフ
ェースはそれぞれ、計算集約型の処理をプロセッサ１１０からオフロードするのに使用さ
れる完全にプログラムされた別々のマイクロプロセッサを備えることが好ましい。しかし
、Ｉ／Ｏアダプタを使用してこれらの機能を実施することもできることは、当業者なら理
解するであろう。
【００１７】
表示インタフェース１４０は、１つまたは複数の表示装置１６５をコンピュータ・シス
テム１００に直接に接続するのに使用される。これらの表示装置１６５は、ノンインテリ
ジェント（すなわちダム）端末である場合と、完全にプログラム可能なワークステーショ
ンである場合とがあるが、これらの表示装置１６５を使用して、コンピュータ・システム
１００と交信する能力がシステム管理者およびユーザにもたらされる。しかし、１つまた
は複数の表示装置１６５との交信をサポートするために表示インタフェース１４０が設け
られているが、ユーザおよび他のプロセスとの必要な全ての対話はネットワーク・インタ
フェース１５０を介して行うこともできるので、コンピュータ・システム１００は必ずし
も表示装置１６５を必要とするとは限らないことに留意されたい。
【００１８】
ネットワーク・インタフェース１５０は、ネットワーク１７０を介してコンピュータ・
システム１００を他のコンピュータ・システムまたはワークステーション１７５に接続す
るのに使用される。ネットワーク・インタフェース１５０は、ネットワーク１７０が今日
のアナログ技法もしくはディジタル技法またはその両方を含むか、あるいは将来の何らか
のネットワーキング・メカニズムを介するかにかかわらず、電子デバイスを相互接続する
ための任意の適切な方法を広く表す。ネットワーク・インタフェース１５０は、ネットワ
ーク１７０上の通信を可能にするハードウェアとソフトウェアの組合せを含むことが好ま
しい。ネットワーク・インタフェース１５０中のソフトウェアは、適切なネットワーク・
プロトコルを使用した他のコンピュータ・システム１７５とのネットワーク１７０経由の
通信を管理する通信マネージャを含むことが好ましい。多くの異なるネットワーク・プロ
トコルを使用してネットワークを実現することができる。これらのプロトコルは、コンピ
ュータがネットワークを介して通信するのを可能にする特殊化されたコンピュータ・プロ
グラムである。ＴＣＰ／ＩＰ（伝送制御プロトコル／インターネット・プロトコル）は、
ネットワーク・インタフェース１５０内で通信マネージャによって使用できる適切なネッ
トワーク・プロトコルの一例である。
【００１９】
当業者には理解されるであろうが、本発明の態様は、システム、方法、またはコンピュ
ータ・プログラム製品として具体化することができる。したがって、本発明の態様は、完
全にハードウェアの実施形態、完全にソフトウェアの実施形態（ファームウェア、常駐ソ
フトウェア、マイクロコードなどを含む）、または、ソフトウェアとハードウェアの態様
を組み合わせた実施形態の形をとることができ、本明細書ではこれらを全て「回路」、「
モジュール」、「プロセス」、または「システム」と一般に呼ぶ場合がある。さらに、本
発明の態様は、コンピュータ可読プログラム・コードが組み入れられた１つまたは複数の
コンピュータ可読媒体において具体化されるコンピュータ・プログラム製品の形をとるこ
ともできる。
【００２０】
１つまたは複数のコンピュータ可読媒体の、任意の組合せを利用することができる。コ
ンピュータ可読媒体は、コンピュータ可読信号媒体またはコンピュータ可読記憶媒体とす
ることができる。コンピュータ可読記憶媒体は、例えば、電子、磁気、光学、電磁、赤外
線、もしくは半導体の、システム、装置、またはデバイス、あるいはこれらの適切な組合
せとすることができるが、これらに限定されない。コンピュータ可読記憶媒体のより具体
的な例（非網羅的なリスト）は、１つもしくは複数のワイヤを有する電気接続、ポータブ
ル・コンピュータ・ディスケット、ハード・ディスク、ランダム・アクセス・メモリ（Ｒ
ＡＭ）、読取専用メモリ（ＲＯＭ）、消去可能プログラム可能な読取専用メモリ（ＥＰＲ
ＯＭもしくはフラッシュ・メモリ）、光ファイバ、ポータブル・コンパクト・ディスク読
取専用メモリ（ＣＤ−ＲＯＭ）、光学記憶デバイス、磁気記憶デバイス、またはこれらの
任意の適切な組合せを含むことになる。この文書のコンテキストでは、コンピュータ可読
記憶媒体は、命令実行システム、装置、もしくはデバイスによって使用されるかまたはそ
れらに関連して使用されるプログラムを、収録あるいは記憶することのできる、任意の有
形媒体とすることができる。
【００２１】
コンピュータ可読信号媒体は、例えばベースバンド中にまたは搬送波の一部として、コ
ンピュータ可読プログラム・コードが組み入れられた伝搬データ信号を含むことができる
。このような伝搬信号は、電磁、光学、またはこれらの任意の適切な組合せを含めた（た
だしこれらに限定されない）様々な形のうちのいずれかをとることができる。コンピュー
タ可読信号媒体は、コンピュータ可読記憶媒体でない任意のコンピュータ可読媒体であっ
て、命令実行システム、装置、もしくはデバイスによって使用されるかまたはそれらに関
連して使用されるプログラムを、通信するか伝搬するかあるいは搬送できる、任意のコン
ピュータ可読媒体とすることができる。
【００２２】
コンピュータ可読媒体上に組み入れられたプログラム・コードは、ワイヤレス、有線、
光ファイバ・ケーブル、ＲＦなど、またはこれらの任意の適切な組合せを含めた（ただし
これらに限定されない）、任意の適切な媒体を使用して伝送することができる。
【００２３】
本発明の態様に関する動作を実施するためのコンピュータ・プログラム・コードは、Ｊ
ａｖａ（Ｒ）、Ｓｍａｌｌｔａｌｋ（Ｒ）、Ｃ＋＋などのオブジェクト指向プログラミン
グ言語、および、「Ｃ」プログラミング言語、Ｓｔｒｅａｍｓ処理言語、または同様のプ
ログラミング言語などの従来の手続き型プログラミング言語を含めた、１つまたは複数の
プログラミング言語の任意の組合せで書かれてよい。プログラム・コードは、スタンドア
ロンのソフトウェア・パッケージとして、完全にユーザのコンピュータ上で実行されるか
部分的にユーザのコンピュータ上で実行されるか、一部はユーザのコンピュータ上で実行
され一部はリモート・コンピュータ上で実行されるか、または完全にリモート・コンピュ
ータもしくはサーバ上で実行されてよい。最後のシナリオでは、リモート・コンピュータ
は、ローカル・エリア・ネットワーク（ＬＡＮ）もしくはワイド・エリア・ネットワーク
（ＷＡＮ）を含めた任意のタイプのネットワークを介してユーザのコンピュータに接続さ
れてよく、または、接続は、外部コンピュータに対して（例えばインターネット・サービ
ス・プロバイダを使用してインターネットを介して）行われてもよい。
【００２４】
本発明の態様を、本発明の実施形態による方法、装置（システム）、およびコンピュー
タ・プログラム製品のフローチャート説明またはブロック図あるいはその両方に関して本
明細書に述べる。フローチャート説明またはブロック図あるいはその両方の各ブロック、
ならびに、フローチャート説明またはブロック図あるいはその両方の中のブロックの組合
せを、コンピュータ・プログラム命令によって実現できることは理解されるであろう。こ
れらのコンピュータ・プログラム命令を、汎用コンピュータ、専用コンピュータ、または
他のプログラム可能データ処理装置のプロセッサに提供して、マシンを生み出すことがで
き、したがって、コンピュータまたは他のプログラム可能データ処理装置のプロセッサを
介して実行される命令は、フローチャートもしくはブロック図またはその両方の１つある
いは複数のブロック中で指定される機能／行為を実現する手段をもたらす。
【００２５】
これらのコンピュータ・プログラム命令はまた、コンピュータ可読媒体に記憶されてよ
く、このコンピュータ可読媒体は、コンピュータ、他のプログラム可能データ処理装置、
または他のデバイスに、特定の方式で機能するよう指示することができ、したがって、コ
ンピュータ可読媒体に記憶された命令は、フローチャートもしくはブロック図またはその
両方の１つあるいは複数のブロック中で指定される機能／行為を実現する命令を含む製造
品を生み出す。
【００２６】
コンピュータ・プログラム命令はまた、コンピュータ、他のプログラム可能データ処理
装置、または他のデバイスにロードされてよく、それにより、コンピュータ、他のプログ
ラム可能装置、または他のデバイス上で一連の動作ステップが実施されて、コンピュータ
実装プロセスが生み出され、したがって、コンピュータまたは他のプログラム可能装置上
で実行される命令は、フローチャートもしくはブロック図またはその両方の１つあるいは
複数のブロック中で指定される機能／行為を実現するためのプロセスを提供する。
【００２７】
本明細書に開示する方法は、ウェブベースのサービスを提供することの一部として実施
することができる。このようなサービスは、例えば、この方法を支払いと引き換えにオン
ライン・ユーザに提供することを含んでよい。
【００２８】
図２を参照すると、サーバ・クラウド中のサーバの実例的な従来技術構成が、サーバ・
クラウド・システム２００として示されている。サーバ・クラウド・システム２００は、
４つのサーバ２１０Ａ〜２１０Ｄを含み、これらのサーバは全て、サーバ・クラウド２３
０中で何らかのネットワーキング・メカニズムを介して相互接続される。各サーバは、イ
ンストールされたプロセッサおよび永続プロセッサを備える。インストールされたプロセ
ッサは、サーバに物理的にインストールされたプロセッサの数を指定し、永続プロセッサ
の数は、サーバ上で永続的にイネーブルにされるプロセッサの数を指定する。図２の特定
の例では、各サーバは、２２５Ａ〜２２５Ｄおよび２２６Ａ〜２２６Ｄに示すように、８
つのインストールされたプロセッサおよび２つの永続プロセッサを備える。従来技術のサ
ーバ・クラウド・システム２００中では、各サーバは、それ自体のキャパシティ・オン・
デマンド・マネージャ２３２Ａ〜２３２Ｄを備え、これらのキャパシティ・オン・デマン
ド・マネージャは、キャパシティ・オン・デマンドを提供するための既知の方法によって
、各サーバのキャパシティを増大させることができる。しかし、サーバごとのキャパシテ
ィ・オン・デマンド・マネージャは、サーバ・クラウド２３０中の他のサーバ上のキャパ
シティから独立して扱われる。したがって、各キャパシティ・オン・デマンド・マネージ
ャ２３２Ａ〜２３２Ｄの機能は、サーバがサーバ・クラウド２３０の一部であるときと、
サーバがサーバ・クラウド２３０の一部でないときとで違いがない。
【００２９】
図３に、従来技術のサーバ・クラウド・システム２００にいくつかの点で類似するサー
バ・クラウド・システム３００を示す。サーバ・クラウド・システム３００は、サーバ・
クラウド３３０中で何らかのネットワーキング・メカニズムを介して相互接続される４つ
のサーバ３１０Ａ〜３１０Ｄを含む。サーバ３１０Ａ〜３１０Ｄはそれぞれ、図１に示す
サーバ・コンピュータ・システム１００とすることができる。各サーバは、８つのインス
トールされたプロセッサ３２５Ａ〜３２５Ｄ、および２つの永続プロセッサ３２６Ａ〜３
２６Ｄを備える。しかし、サーバ３１０Ａは追加で、クラウド・キャパシティ・オン・デ
マンド・マネージャ１２４も備え、これは、サーバ・クラウド中のサーバのためのキャパ
シティ・オン・デマンドを管理し、必要時に、あるサーバから、別のサーバに貸されるキ
ャパシティを借りることができる。各サーバ３１０Ａ〜３１０Ｄは、キャパシティを借り
ることとキャパシティを貸すことの両方ができるので、各サーバは、借りたプロセッサ３
２８Ａ〜３２８Ｄ、および貸したプロセッサ３２９Ａ〜３２９Ｄを追跡する。３２８Ａ〜
３２８Ｄは、図３では「借りたプロセッサ」として示されているが、実際には、借りた、
プロセッサのキャパシティである。同様に、３２９Ａ〜３２９Ｄは、図３では「貸したプ
ロセッサ」として示されているが、実際には、貸した、プロセッサのキャパシティである
。図３に示す構成では、各サーバが、その２つの永続プロセッサによってそれ自体の処理
負荷を扱うことができると仮定する。
【００３０】
次に図４に移るが、この例では、サーバ３１０Ｄが処理負荷の増大のせいで追加のプロ
セッサ・キャパシティを必要とすると仮定し、さらに、サーバ３１０Ｄが、既にイネーブ
ルにされている２つの永続プロセッサ３２６Ｄに加えて、３つの追加プロセッサのキャパ
シティを必要とすると仮定する。従来技術では、サーバ３１０Ｄ上のキャパシティ・オン
・デマンド・マネージャが、インストールされたプロセッサのうちのさらに３つをイネー
ブルにすることができ、その結果、サーバ３１０Ｄには合計５つの永続プロセッサがある
ことになる。しかし、クラウド・キャパシティ・オン・デマンド・マネージャ１２４は、
サーバ・クラウド中の１つまたは複数のサーバから一時的に借りてサーバ３１０Ｄに貸す
ことのできる未使用キャパシティがサーバ・クラウド中にある可能性があると認識する。
図４の特定の例では、サーバ３１０Ａ、３１０Ｂ、および３１０Ｃの各々が、各サーバ上
の２つの永続プロセッサのうちの一方を使用してそれらの作業負荷を処理できると仮定す
る。このことは、各サーバが、追加のキャパシティを必要とするサーバ３１０Ｄに貸せる
１つのプロセッサのキャパシティを有することを意味する。したがって、クラウド・キャ
パシティ・オン・デマンド・マネージャ１２４は、図４の３２６Ａ〜３２６Ｃに示すよう
に、永続プロセッサの数を２から１に減少させ、図４の３２９Ａ〜３２９Ｃに示すように
、貸したプロセッサの数を０から１に増加させる。次いで、クラウド・キャパシティ・オ
ン・デマンド・マネージャは、図４の３つの借りたプロセッサ３２８Ｄを提供する矢印付
き点線によって示すように、これらの貸したプロセッサ３２９Ａ〜３２９Ｃのキャパシテ
ィをサーバ３１０Ｄに貸すことができる。図４で貸されるものおよび借りられるものは、
プロセッサ・キャパシティであることに留意されたい。したがって、図３に示すサーバ・
クラウド・システム３００中でイネーブルにされるプロセッサの総数は、４つの各サーバ
上の２つの永続プロセッサ３２６Ａ〜３２６Ｂであり、合計８つのプロセッサがイネーブ
ルにされる。図３に示すサーバ・クラウド・システム３００中でイネーブルにされるプロ
セッサの総数は依然として８つであり、これらは、３つのサーバの各々からの１つの永続
プロセッサ３２６Ａ〜３２６Ｃと、サーバ３１０Ｄ上の２つの永続プロセッサ３２６Ｄと
、サーバ３１０Ｄ上の３つの借りたプロセッサ３２８Ｄである。クラウド・キャパシティ
・オン・デマンド・マネージャが、あるサーバからキャパシティを借りてこのキャパシテ
ィをサーバ・クラウド中の異なるサーバに貸すことができることにより、顧客が特定のサ
ーバのために追加のキャパシティを購入するのではなくサーバ上の未使用キャパシティを
利用するのを可能にすることになる極めてフレキシブルなシステムがもたらされる。この
結果、サーバ・クラウド中の総キャパシティをより効率的に、よりコスト効果のある方式
で使用するシステムとなる。
【００３１】
図５を参照すると、方法５００は、サーバ・クラウドが確立されるときに開始する（ス
テップ５１０）。サーバ・クラウドが完全な状態であり（ステップ５２０＝はい）、サー
バ・クラウド中のサーバが追加のキャパシティを必要とし（ステップ５３０＝はい）、サ
ーバ・クラウド中の１つまたは複数の他のサーバが貸すためのキャパシティを有するとき
（ステップ５４０＝はい）は、１つまたは複数の他のサーバはキャパシティを貸し（ステ
ップ５５０）、サーバは借りたキャパシティを使用する（ステップ５６０）。サーバ・ク
ラウド中のどのサーバも追加キャパシティを必要としないとき（ステップ５３０＝いいえ
）は、方法５００はステップ５２０にループバックして継続する。同様に、他のどのサー
バも貸すためのキャパシティを有さないとき（ステップ５４０＝いいえ）は、方法５００
はステップ５２０にループバックして継続する。方法５００は、サーバ・クラウドがもは
や完全な状態でなくなるまで（ステップ５２０＝いいえ）継続することができ、サーバ・
クラウドが完全な状態でなくなった時点で、借りたキャパシティはディセーブルにされ（
ステップ５７０）、貸したキャパシティは回収される（ステップ５８０）。ステップ５７
０および５８０は、２つの異なる方式で機能する場合があることに留意されたい。第１の
実装形態では、あるサーバがもはやサーバ・クラウドのメンバでないせいでサーバ・クラ
ウドがもはや完全な状態でないとき（ステップ５２０＝いいえ）は、サーバ・クラウド中
の全てのサーバ上の借りたキャパシティはステップ５７０でディセーブルにされ、サーバ
・クラウド中の全てのサーバ上の貸したキャパシティは回収される。第２の実装形態では
、あるサーバ（紛失サーバ）がもはやサーバ・クラウドのメンバでないせいでサーバ・ク
ラウドがもはや完全な状態でないとき（ステップ５２０＝いいえ）は、紛失サーバからキ
ャパシティを借りてまだサーバ・クラウド中にあるサーバがあればそのサーバ中で、紛失
サーバに対する借りたキャパシティはステップ５７０でディセーブルにされる。紛失サー
バは、それ自体がもはやサーバ・クラウドのメンバでないことを検出すると、ステップ５
８０で、貸したキャパシティを回収する。第１の実装形態は、オール・オア・ナッシング
手法であり、サーバ・クラウド中のいずれかのサーバが失われると、全ての借りたキャパ
シティはディセーブルにされ、全ての貸したキャパシティは回収される。第２の実装形態
では、選択的に、紛失サーバから借りたキャパシティがディセーブルにされ、紛失サーバ
上の貸したキャパシティが回収されるが、サーバ・クラウド中の残りのサーバは、紛失サ
ーバが失われたことによって影響を受けない借りたキャパシティおよび貸したキャパシテ
ィを使用して機能することができる。
【００３２】
ステップ５２０で、サーバ・クラウドが完全な状態であるかどうかの判定は、任意の適
切な方式で行うことができる。例えば、特定の一実装形態では、サーバ・クラウド中のサ
ーバ間でトークンが回されて、サーバ・クラウドが維持される。あるサーバがそのトーク
ンを定義済み期間内に送らなかった場合は、このサーバはもはや正しく機能していないと
見なされ、このことは、サーバ・クラウドがもはや完全な状態でないことを意味する。代
替の一実装形態では、クラウド・キャパシティ・オン・デマンド・マネージャは、サーバ
・クラウドのメンバのログをとることができ、サーバ・クラウド中の各サーバに定期的に
問い合わせることができる。各サーバが適切な応答によって応答した場合、クラウド・キ
ャパシティ・オン・デマンド・マネージャは、サーバ・クラウドがまだ完全な状態である
ことを知る。サーバのうちの１つが応答しなかった場合は、クラウド・キャパシティ・オ
ン・デマンド・マネージャは、応答しなかったサーバが正しく機能していないこと、した
がってもはやサーバ・クラウド中にないことを知る。次いで、クラウド・キャパシティ・
オン・デマンド・マネージャは、上に論じた措置を講じて、借りたキャパシティをディセ
ーブルにし、貸したキャパシティを回収することができる。本明細書における開示および
特許請求の範囲は、現在知られている方法であろうと将来開発される方法であろうと、サ
ーバ・クラウドが完全な状態であるかどうか判定するための任意の適切な方法に及ぶ。
【００３３】
クラウド・キャパシティ・オン・デマンド・マネージャ１２４は、サーバ・クラウド中
のサーバにまたがってキャパシティを管理することができるので、このことは、図６に示
す新しい概念を引き起こす。サーバ・クラウド・システム６００は、４つのサーバ６１０
Ａ〜６１０Ｄを含み、これらのサーバは、同じインストールされたプロセッサ３２５Ａ〜
３２５Ｄ、永続プロセッサ３２６Ａ〜３２６Ｄ、借りたプロセッサ３２８Ａ〜３２８Ｄ、
および貸したプロセッサ３２９Ａ〜３２９Ｄを有する。サーバ６１０Ａ〜６１０Ｄはそれ
ぞれ、図１に示すサーバ・コンピュータ・システム１００とすることができる。加えて、
「クラウド永続プロセッサ」と本明細書で呼ぶ新しい概念が導入され、それにより、永続
的にイネーブルにされサーバ・クラウド中のどのサーバによっても使用できる、サーバ上
のキャパシティが表される。図６の特定の例では、各サーバ６１０Ａ〜６１０Ｄは、２つ
のクラウド永続プロセッサ６２７Ａ〜６２７Ｄを備える。これらのクラウド永続プロセッ
サについてのこれらのキャパシティは、クラウド永続プロセッサが存在するサーバを含め
た、サーバ・クラウド６３０中のどのサーバによっても使用することができる。
【００３４】
図７を参照するが、キャパシティの貸し借りを促した図４の条件と同じ条件、すなわち
、サーバ６１０Ｄがさらに３つのプロセッサ分の３つのキャパシティを必要とするという
条件を仮定する。サーバ６１０Ｄは、２つのクラウド永続プロセッサ６２７Ｄを使用する
ことができ、図７の矢印付き点線で示すように、第３の必要なプロセッサをサーバ６１０
Ｃから借りることができる。サーバ６１０Ｃ上の１つの貸したプロセッサ３２９Ｃは、ク
ラウド永続プロセッサ６２７Ｃの数を２から１に減少させることに留意されたい。クラウ
ド永続プロセッサと呼ばれるこの新しい特徴を定義することによって、クラウド・キャパ
シティ・オン・デマンド・マネージャは、サーバ・クラウド中のサーバ間でどのリソース
が借りられるかまたは貸されるかに関して、より大きなフレキシビリティを有することが
できる。例えば、クラウド・キャパシティ・オン・デマンド・マネージャ１２４は、最初
に、全てのクラウド永続プロセッサを借りることができる。というのは、これらは、サー
バ上のいずれかの永続プロセッサを借りる前にクラウド処理のために確保されるからであ
る。代替方式では、クラウド永続プロセッサは、サーバ・クラウド中のサーバ間で共有す
ることが許可される唯一のキャパシティとすることができる。永続プロセッサとは別に定
義されたクラウド永続プロセッサのキャパシティを有することによって、クラウド・キャ
パシティ・オン・デマンド・マネージャ１２４は、サーバ・クラウド全体にわたるキャパ
シティの貸し借りにおいてより大きなフレキシビリティを有する。
【００３５】
図３、４、６、および７では、クラウド・キャパシティ・オン・デマンド・マネージャ
１２４は、サーバ・クラウド中の１つのサーバ上にあるように示されている。代替の一実
装形態では、クラウド・キャパシティ・オン・デマンド・マネージャ１２４は、図８に示
すように、サーバ・クラウド中の別個のエンティティ上にあってもよい。サーバ・クラウ
ド・システム８００では、４つのサーバ８１０Ａ、６１０Ｂ、６１０Ｃ、および６１０Ｄ
が、サーバ・クラウド８３０中で相互接続される。サーバ・クラウド８３０中ではハード
ウェア管理コンソール８２０も接続され、ハードウェア管理コンソール８２０は、クラウ
ド・キャパシティ・オン・デマンド・マネージャ１２４を備える。ハードウェア管理コン
ソール８２０は、サーバ・クラウド中のサーバを構成するのを可能にし、サーバ・クラウ
ド中のサーバ中のリソースおよびキャパシティを管理するためのユーザ・インタフェース
を提供する。ハードウェア管理コンソール８２０はまた、サーバ・クラウド中のサーバを
監視することができ、サーバ・クラウドがもはや完全な状態でないときを検出することが
できる。このように、ハードウェア管理コンソール８２０は、サーバの関係をサーバ自体
に管理させるのではなく、サーバ外の独立した制御ポイントを提供し、これにより、サー
バがサーバ・クラウドを去るときがより容易になる。例えば、図７で、サーバ６１０Ａが
動作不良を起こして応答しなくなった場合、クラウド・キャパシティ・オン・デマンド・
マネージャ１２４は、もはやその仕事を行うことができない。図８に示すようにクラウド
・キャパシティ・オン・デマンド・マネージャ１２４を別個のハードウェア管理コンソー
ル８２０中に配置することによって、クラウド・キャパシティ・オン・デマンド・マネー
ジャ１２４は、どのサーバがサーバ・クラウドを去るかにかかわらず機能し続けることが
できる。
【００３６】
図９を参照すると、クラウド・キャパシティ・オン・デマンド・マネージャ１２４は、
クラウド・メンバシップ９１０、すなわちどのサーバがサーバ・クラウドのメンバである
かを追跡し、借りたキャパシティ９２０および貸したキャパシティ９３０を追跡する。ク
ラウド・キャパシティ・オン・デマンド・マネージャ１２４はまた、キャパシティ照会メ
カニズム９４０を備え、このキャパシティ照会メカニズム９４０は、サーバ・クラウド中
の各サーバに照会して、サーバが貸すためのキャパシティを有するかどうか判定すること
ができる（図５のステップ５４０参照）。借りたキャパシティ９２０および貸したキャパ
シティ９３０は、任意の適切な方式で追跡することができる。例えば、図１０に示すクラ
ウド・リソース・テーブル１０１０は、借りたキャパシティ９２０および貸したキャパシ
ティ９３０の状況を常に把握するための適切な方法の１つを表す。エントリ１０２０は、
Ｐ３のキャパシティＩＤ、プロセッサのリソース・タイプ、および、サーバＡがこのキャ
パシティの所有元でありこのキャパシティがまだ貸し出されていないことを示す。エント
リ１０３０は、Ｐ１４のキャパシティＩＤ、プロセッサのリソース・タイプ、および、サ
ーバＣがこのキャパシティの所有元でありこのキャパシティがサーバＤに貸されたことを
示す。借りたキャパシティおよび貸したキャパシティの状況を常に把握することによって
、クラウド・キャパシティ・オン・デマンド・マネージャ１２４は、サーバ・クラウドが
もはや完全な状態でないときに、借りたキャパシティをディセーブルにすることができる
（図７のステップ５７０参照）。各サーバは、サーバがもはやサーバ・クラウド中にない
ときを検出できるメカニズムを備えることが好ましく、それに応答して、クラウド中の他
のサーバに既に貸し出したキャパシティがあればそれを回収することになることに留意さ
れたい（図８のステップ５８０参照）。
【００３７】
上記の例ではプロセッサについて論じているが、プロセッサは、サーバ・クラウド内で
貸し借りできるキャパシティを有するリソースの適切な一例を表す。本明細書における開
示および特許請求の範囲は、サーバ中の任意の適切なリソース、およびサーバ・クラウド
中の任意の適切なリソースに明白に及び、限定ではないがこれらのリソースは、プロセッ
サ、メモリ、入出力（Ｉ／Ｏ）スロット、ネットワーク・アダプタなどを含む。また、ク
ラウド・キャパシティ・オン・デマンド・マネージャによって貸し借りされているものは
、リソース自体ではなく、リソースのキャパシティであることにも留意されたい。したが
って、サーバ３１０Ｄが２つの永続プロセッサ３２６Ｄおよび３つの借りたプロセッサ３
２８Ｄを有するとき、このことは、サーバ３１０Ｄ中の８つのインストールされたプロセ
ッサ３２５Ｄのうちの５つを使用できることを意味する。「借りたプロセッサ」３２８Ｄ
は、他のサーバから借りた、プロセッサのキャパシティを表す。サーバ上の永続プロセッ
サと借りたプロセッサの合計は、インストールされたプロセッサの総数を超えることはで
きないことに留意されたい。
【００３８】
本開示および特許請求の範囲は、サーバ・クラウド中のサーバのためのキャパシティ・
オン・デマンドを管理するクラウド・キャパシティ・オン・デマンド・マネージャに関す
る。クラウド・キャパシティ・オン・デマンド・マネージャは、１つまたは複数のサーバ
からキャパシティを借りることができ、あるサーバから借りたキャパシティをサーバ・ク
ラウド中の異なるサーバに貸すことができる。サーバ・クラウドがもはや完全な状態でな
いとき、サーバ・クラウド中にもはやないサーバから借りたキャパシティはディセーブル
にされ、サーバ・クラウド中にもはやないサーバは、サーバ・クラウドに貸したキャパシ
ティを回収する。
【００３９】
請求項の範囲内で多くの変形が可能であることは、当業者なら理解するであろう。した
がって、本開示について特に図示および上述しているが、請求項の主旨および範囲を逸脱
することなく、形式および詳細におけるこれらおよび他の変更を本開示に加えることがで
きることは、当業者には理解されるであろう。
【図１】
2015149097.tif 000003
【図２】
2015149097.tif 000004
【図３】
2015149097.tif 000005
【図４】
2015149097.tif 000006
【図５】
2015149097.tif 000007
【図６】
2015149097.tif 000008
【図７】
2015149097.tif 000009
【図８】
2015149097.tif 000010
【図９】
2015149097.tif 000011
【図１０】
2015149097.tif 000012