JP2022519102A - 異常イベントに対する仮想マシンの処理能力の増加 - Google Patents

Abstract

システムおよび関連方法は、アクティブ状態の第１のコア、および当初は非アクティブ状態の第２のコアを備えるプロセッサ・ユニットのセットを備える計算リソースの第１のセットを、データ処理システム（ＤＰＳ）内に提供する。プロセッサは、ＤＰＳ上でホストされるパーティションに計算リソースの第１のセットをアロケートする。パーティションは、第２のコアがアクティブ化される前に、第１のコアを使用して動作する。リソース・マネージャは、異常イベントに基づいて、処理能力を増加させるべきかどうかを判定する。プロセッサは、次に、非アクティブ状態からアクティブ状態に第２のコアをアクティブ化する。パーティションは、次に、（アクティブ化された）第１のコアと第２のコアの両方を使用して動作する。所定の判断基準に応じて、第２のコアは、アクティブ状態から非アクティブ状態に非アクティブ化される。

Description

本発明は、データ処理システムに関する。

データ処理システムであって、異常イベントが発生したときに、データ処理システムの対応するパーティション上で実行している１つまたは複数の仮想マシンの処理能力を動的に増加させるためのデータ処理システムを本明細書で開示する。

組織は、一般に、製品の製造、サービスの実施、内部活動、および他の適切な動作の際に、ネットワーク・データ処理システムを使用する。組織によっては、ハードウェアおよびソフトウェアが組織によって所有され、維持されるネットワーク・データ処理システムを使用するものもある。これらのタイプのネットワーク・データ処理システムは、ローカル・エリア・ネットワーク、広域ネットワーク、および他の適切な形をしていてもよい。これらのタイプのネットワークでは、リソースを維持し、管理する負担が組織にかかる。場合によっては、組織は、ネットワーク・データ処理システムのメンテナンスを外部委託することもある。他の組織は、ハードウェアおよびソフトウェアがサード・パーティによって置かれ、維持されることがあるネットワーク・データ処理システムを使用することもある。このタイプの組織に関して言えば、組織は、コンピュータ・システムを使用して、ネットワーク・データ処理システムにアクセスする。このタイプのアーキテクチャに関して言えば、組織には、使用し、維持するべきハードウェアが少ない。

また、このタイプのネットワーク・データ処理システムは、クラウドと呼ばれることがある。クラウド環境では、クラウドは、インターネットを通じてアクセスされることが多く、組織は、コンピュータまたは簡単なネットワーク・データ処理システムを使用して、これらのリソースにアクセスする。さらに、クラウドに関して言えば、組織に提供される計算リソースの数が動的に変化することがある。例えば、組織が、より多くの計算リソースを必要とすると、組織は、これらの計算リソースをリクエストすることができる。

結果として、クラウドを使用する組織は、ハードウェアおよびソフトウェアを所有しない。さらに、これらの組織は、計算リソースのメンテナンスのための設備投資および費用を避ける。組織は、使用した計算リソースの代金を支払う。組織は、実際の処理時間およびストレージ空間、または他のリソース使用など、実際に使用したリソースに基づいて支払うこともある。また、組織は、定額の計算リソースの代金を定期的に支払うこともある。例えば、組織は、選択した量のストレージおよび処理能力の代金を毎月支払うこともある。この使用量は、電気またはガスなどのリソースに似ている。

本開示は、クラウド・コンピューティングについての詳細な説明を含んでいるが、本明細書で列挙される教示についての実装形態は、クラウド・コンピューティング環境に限定されない。むしろ、実施形態は、現在知られているか、後で開発される他の任意のタイプのコンピューティング環境とともに実装することができる。

１つまたは複数の実施形態によれば、コンピュータ実行方法は、プロセッサを使用して、プロセッサ・ユニットのセットを備える計算リソースの第１のセットを、データ処理システム（ＤＰＳ：data processing system）内で提供することを含む。プロセッサ・ユニットのセットは、アクティブ状態の１つまたは複数の第１のコア、および当初は非アクティブ状態の１つまたは複数の第２のコアを備える。１つまたは複数の第２のコアは、非アクティブ状態の間、プロセッサ・ユニットのセット内に予め存在している潜在的なＣＰＵ能力（ＬＣＣ：latent CPU capacity）に相当する。プロセッサは、アクティブ状態の１つまたは複数の第１のコアを伴うプロセッサ・ユニットのセットを備える計算リソースの第１のセットを、ＤＰＳ上でホストされるパーティションにアロケートする。パーティションは、１つまたは複数の第２のコアがアクティブ化される前、１つまたは複数の第１のコアを使用して動作する。リソース・マネージャは、異常イベントの発生に基づいて、ＬＣＣを利用してパーティションのために処理能力を増加させるべきかどうかを決定する。増加の決定に応答して、プロセッサは、非アクティブ状態からアクティブ状態に１つまたは複数の第２のコアをアクティブ化する。パーティションは、次に、１つまたは複数の第２のコアがアクティブ化された後、１つまたは複数の第１のコアと１つまたは複数の第２のコアの両方を使用して動作する。所定の判断基準に応じて、１つまたは複数の第２のコアは、アクティブ状態から非アクティブ状態に非アクティブ化される。

１つまたは複数の実施形態によれば、コンピュータ実行方法は、プロセッサを使用して、プロセッサ・ユニットのセットを備える計算リソースの第１のセットを、データ処理システム（ＤＰＳ）内で提供することを含み、プロセッサ・ユニットのセットは、アクティブ状態の１つまたは複数の第１のコア、および当初は非アクティブ状態の１つまたは複数の第２のコアを備える。１つまたは複数の第２のコアは、非アクティブ状態の間、プロセッサ・ユニットのセット内に予め存在している潜在的なＣＰＵ能力（ＬＣＣ）に相当する。プロセッサは、アクティブ状態の１つまたは複数の第１のコアを伴うプロセッサ・ユニットのセットを備える計算リソースの第１のセットを、ＤＰＳ上でホストされるパーティションにアロケートする。パーティションは、１つまたは複数の第２のコアがアクティブ化される前、１つまたは複数の第１のコアを使用して動作する。リソース・マネージャは、異常イベントの発生に基づいて、ＬＣＣを利用してパーティションのために処理能力を増加させるべきかどうかを決定する。増加の決定に応答して、１つまたは複数の第２のコアは、非アクティブ状態からアクティブ状態にアクティブ化される。パーティションは、次に、１つまたは複数の第２のコアがアクティブ化された後、１つまたは複数の第１のコアと１つまたは複数の第２のコアの両方を使用して動作する。所定の判断基準に応じて、１つまたは複数の第２のコアは、アクティブ状態から非アクティブ状態に非アクティブ化される。プロセッサは、１つまたは複数の第２のコアのアクティブ化および非アクティブ化に関連して、情報のロギング、追跡、または検査のうちの少なくとも１つを実施する。

１つまたは複数の実施形態によれば、異常イベントによってトリガされた仮想マシンの増加した処理能力を測定し、レポートするためのコンピュータ実行方法は、プロセッサを使用して、異常イベントの発生によってトリガされた、パーティションのための処理能力の増加のために、追加のリソースがパーティションに適用されたと判定することを含む。プロセッサは、次に、追加のリソースの適用の範囲および持続期間を決定することと、追加の処理リソースのアクティブ化および非アクティブ化に関連して、情報のロギング、追跡、または検査のうちの少なくとも１つを実施することとを行う。

１つまたは複数の実施形態によれば、異常イベントのために仮想マシンの処理能力を増加させるためのコンピュータ・システムを提供する。コンピュータ・システムは、命令を実行するように構成されたプロセッサを備え、命令は、プロセッサ上で実行されると、プロセッサ・ユニットのセットを備える計算リソースの第１のセットを、データ処理システム（ＤＰＳ）内で提供することをプロセッサに行わせる。プロセッサ・ユニットのセットは、アクティブ状態の１つまたは複数の第１のコア、および当初は非アクティブ状態の１つまたは複数の第２のコアを備える。１つまたは複数の第２のコアは、非アクティブ状態の間、プロセッサ・ユニットのセット内に予め存在している潜在的なＣＰＵ能力（ＬＣＣ）に相当する。システムは、アクティブ状態の１つまたは複数の第１のコアを伴うプロセッサ・ユニットのセットを備える計算リソースの第１のセットを、ＤＰＳ上でホストされるパーティションにアロケートする。システムは、１つまたは複数の第２のコアがアクティブ化される前、１つまたは複数の第１のコアを使用してパーティションを動作させる。リソース・マネージャは、異常イベントの発生に基づいて、ＬＣＣを利用してパーティションのために処理能力を増加させるべきかどうかを決定する。増加の決定に応答して、システムは、非アクティブ状態からアクティブ状態に１つまたは複数の第２のコアをアクティブ化し、１つまたは複数の第２のコアがアクティブ化された後、１つまたは複数の第１のコアと１つまたは複数の第２のコアの両方を使用してパーティションを動作させる。所定の判断基準に応じて、システムは、アクティブ状態から非アクティブ状態に１つまたは複数の第２のコアを非アクティブ化する。

１つまたは複数の実施形態によれば、コンピュータ・プログラム製品は、プロセッサ上で実行されると、データ処理システム（ＤＰＳ）内で提供するためのコンピュータ可読プログラム・コードが具現化されたコンピュータ可読ストレージ媒体を備える。計算リソースの第１のセットは、プロセッサ・ユニットのセットを備え、プロセッサ・ユニットのセットは、アクティブ状態の１つまたは複数の第１のコア、および当初は非アクティブ状態の１つまたは複数の第２のコアを備える。１つまたは複数の第２のコアは、非アクティブ状態の間、プロセッサ・ユニットのセット内に予め存在している潜在的なＣＰＵ能力（ＬＣＣ）に相当する。プロセッサは、プログラム・コードを使用して、アクティブ状態の１つまたは複数の第１のコアを伴うプロセッサ・ユニットのセットを備える計算リソースの第１のセットを、ＤＰＳ上でホストされるパーティションにアロケートすることと、第２のコアがアクティブ化される前、第１のコアを使用してパーティションを動作させることとを行う。コードは、異常イベントの発生に基づいて、ＬＣＣを利用してパーティションのために処理能力を増加させるために、リソース・マネージャが増加指示を受け取ることを可能にする。コードは、増加リクエストに応答して、非アクティブ状態からアクティブ状態に第２のコアをアクティブ化し、第２のコアがアクティブ化された後、第１のコアと第２のコアの両方を使用してパーティションを動作させるようにプロセッサに指図する。コードは、所定の判断基準に応じて、アクティブ状態から非アクティブ状態に第２のコアを非アクティブ化するようにプロセッサに指図する。

さらなる特徴および長所が、本発明の技法によって実現される。本発明の他の実施形態および態様は、本明細書で詳細に説明され、特許請求される発明の一部とみなされる。この長所および特徴とともに本発明をより良く理解するために、説明および図面を参照する。

以下の詳細な説明は、添付の図面とともに行われ、下記で直接、簡単に説明され、以下で、より詳細に論じられることがある。

本明細書で開示された１つまたは複数の実施形態による、クラウド・コンピューティング環境の例を示す絵図である。 本明細書で開示された１つまたは複数の実施形態による、抽象化モデル層の例の絵図である。 本明細書で開示された１つまたは複数の実施形態による、ＤＰＳのブロック図である。 本明細書で開示された１つまたは複数の実施形態による、リソース管理環境のブロック図である。 本明細書で開示された１つまたは複数の実施形態による、ＤＰＳ内のリソース管理モジュールのブロック図である。 本明細書で開示された１つまたは複数の実施形態による、ＤＰＳ内のパーティションのセットのブロック図である。 本明細書で開示された１つまたは複数の実施形態による、特定のイベント処理中にプロセッサ・コアの処理能力を増加させるための実例の方法の流れ図である。 本明細書で開示された１つまたは複数の実施形態による、特定のイベント処理中にプロセッサ・コアの処理能力を増加させるための別の方法の例の流れ図である。

本明細書で開示した１つまたは複数の実施形態は、異常イベントの検出後、追加の計算リソースの配信を容易にすることができる。典型的なコンピューティング・システムは、様々な異常イベントの後、パフォーマンスが低下する。また、低下したパフォーマンスは、診断情報の収集、ハードウェアおよびソフトウェア・サービス・パッチの適用、このような異常イベント後の更新、ならびに、システム機能停止からの回復により、引き起こされることもある。診断情報の収集は、ダンプおよびトレースの収集を含むことができる。

異常イベントからの回復には、例えば、トリガされたＩＰＬ、または、コンピューティング・システムの１つもしくは複数のパーティションのブートにより、かなりの時間およびリソースが、さらにかかることがある。このような動作（診断情報の収集／回復）は、通常動作中の典型的な予想システム・ワークロードを上回るワークロードを含むことがあるので、追加の時間が必要になることがある。代替としてまたはさらに、初期プログラム・ロード（ブート）、または予定の更新／パッチなどの、計画イベントにより、コンピューティング・システムのパフォーマンスが低下することがある。低下したパフォーマンスの持続期間を軽減するため、および、機能停止後、または追加のワークロードを含む予定の動作中に、パフォーマンスの向上を可能にするために、追加の計算リソースをコンピューティング・システムに追加することができる。

以下の定義を下記で使用する。

以下の頭字語を下記で使用することがある。

本開示は、クラウド・コンピューティングについての詳細な説明を含むが、本明細書で列挙される教示の実装形態は、クラウド・コンピューティング環境に限定されないことを理解されたい。むしろ、本発明の実施形態は、現在知られているか、後で開発される他の任意のタイプのコンピューティング環境とともに実装することができる。

クラウド・コンピューティングは、最低限の管理努力、またはサービスの提供者との対話により、迅速に提供し、公開することが可能な、構成可能な計算リソースの共用プール（例えば、ネットワーク、ネットワーク帯域幅、サーバ、処理、メモリ、ストレージ、アプリケーション、仮想マシン、およびサービス）への便利なオン・デマンドのネットワーク・アクセスを可能にするためのサービス配信のモデルである。このクラウド・モデルは、少なくとも５つの特性、少なくとも３つのサービス・モデル、および少なくとも４つの導入モデルを含むことができる。

特性は、以下のようなものである。
オン・デマンド・セルフサービス：クラウドの利用者は、サービスの提供者との人間対話を必要とすることなく、必要に応じて自動的に、サーバ時間およびネットワーク・ストレージなどのコンピューティング能力を一方的に提供することができる。
ブロード・ネットワーク・アクセス：能力は、ネットワークで利用可能であり、異種のシンまたはシック・クライアント・プラットフォーム（例えば、携帯電話、ラップトップ、およびＰＤＡ）による使用を推進する標準メカニズムを通じてアクセスされる。
リソース・プーリング：プロバイダの計算リソースは、マルチ・テナント・モデルを使用して複数の利用者に供給するためにプールされ、異なる物理および仮想リソースが、需要に応じて動的に割り当てられ、再割当てされる。利用者には、一般に、提供されたリソースの正確な位置についての制御権も知識もないが、抽象化のより高いレベル（例えば、国、州、またはデータセンタ）で位置を特定できることがあるという位置独立の感覚（a sense of location independence）がある。
迅速な伸縮性（rapid elasticity）：能力は、素早くスケール・アウトするために迅速かつ伸縮自在に、場合によっては自動的に提供すること、および、素早くスケール・インするために迅速に公開することができる。利用者にとって、提供するために利用可能な能力は、無制限のように見えることが多く、いつでも任意の量で購入することができる。
計測されるサービス（measured service）：クラウド・システムは、サービスのタイプ（例えば、ストレージ、処理、帯域幅、およびアクティブ・ユーザ・アカウント）に適した抽象化のいくつかのレベルで計量能力を活用することによって、リソース使用を自動的に制御し、最適化する。リソース使用率の監視、制御、およびレポートを行うことができ、利用されるサービスの提供者と利用者双方に透明性をもたらす。

サービス・モデルは、以下のようなものである。
サービスとしてのソフトウェア（ＳａａＳ）：利用者に提供される能力は、クラウド・インフラストラクチャ上で動くプロバイダのアプリケーションを使用することである。アプリケーションは、ウェブ・ブラウザ（例えば、ウェブベースの電子メール）などのシン・クライアント・インターフェースを通じて、様々なクライアント・デバイスからアクセス可能である。利用者は、限定的なユーザ固有のアプリケーション構成設定を例外とする可能性はあるが、ネットワーク、サーバ、オペレーティング・システム、ストレージ、または、ことによると、個々のアプリケーション能力を含んだ、基礎をなすクラウド・インフラストラクチャの管理も制御も行わない。
サービスとしてのプラットフォーム（ＰａａＳ）：利用者に提供される能力は、プロバイダによってサポートされるプログラミング言語およびツールを使用して作成された、利用者が作成した、または獲得したアプリケーションを、クラウド・インフラストラクチャ上に配布することである。利用者は、ネットワーク、サーバ、オペレーティング・システム、またはストレージを含んだ、基礎をなすクラウド・インフラストラクチャの管理も制御も行わないが、配布されたアプリケーション、および場合によっては、アプリケーション・ホスティング環境構成を制御することができる。
サービスとしてのインフラストラクチャ（ＩａａＳ）：利用者に提供される能力は、オペレーティング・システムおよびアプリケーションを含むことができる任意のソフトウェアを利用者が配布し、動かすことができる、処理、ストレージ、ネットワーク、および他の基本的な計算リソースを提供することである。利用者は、基礎をなすクラウド・インフラストラクチャの管理も制御も行わないが、オペレーティング・システム、ストレージ、配布されたアプリケーションの制御、および場合によっては、選択したネットワーク構成要素（例えば、ホスト・ファイアウォール）の限定的な制御を行うことができる。

導入モデルは、以下のようなものである。
プライベート・クラウド：クラウド・インフラストラクチャは、組織のために単に運用される。クラウド・インフラストラクチャは、組織またはサード・パーティによって管理されてもよく、オンプレミスであっても、オフプレミスであってもよい。
コミュニティ・クラウド：クラウド・インフラストラクチャは、いくつかの組織によって共有され、関心（例えば、ミッション、セキュリティ要件、ポリシ、およびコンプライアンスの考慮）を共有してきた特定のコミュニティをサポートする。クラウド・インフラストラクチャは、組織またはサード・パーティによって管理されてもよく、オンプレミスであっても、オフプレミスであってもよい。
パブリック・クラウド：クラウド・インフラストラクチャは、一般大衆または大規模な業界団体が利用でき、クラウド・サービスを売る組織によって所有される。
ハイブリッド・クラウド：クラウド・インフラストラクチャは、一意のエンティティのままだが、データおよびアプリケーションの移植性（例えば、クラウド間のロード・バランスのためのクラウド・バースティング）を可能にする標準または独自の技術でまとめられた２つ以上のクラウド（プライベート、コミュニティ、またはパブリック）の構成である。

クラウド・コンピューティング環境は、ステートレス状態（statelessness）、疎結合、モジュール性、および意味論的相互運用性（semantic interoperability）に重点を置くサービス指向のものである。クラウド・コンピューティングの中心には、相互接続ノードのネットワークを含むインフラストラクチャがある。

次に図１を参照すると、例証的なクラウド・コンピューティング環境５０が描写されている。図示のように、クラウド・コンピューティング環境５０は、例えば、携帯情報端末（ＰＤＡ）もしくはセルラー電話５４Ａ、デスクトップ・コンピュータ５４Ｂ、ラップトップ・コンピュータ５４Ｃ、または自動車コンピュータ・システム５４Ｎ、あるいはその組合せなど、クラウドの利用者によって使用されるローカル・コンピューティング・デバイスが通信することができる１つまたは複数のクラウド・コンピューティング・ノード１０を含む。ノード１０は、互いに通信することができる。ノード１０は、上述のようなプライベート、コミュニティ、パブリック、またはハイブリッド・クラウド、あるいはその組合せなど、１つまたは複数のネットワークにおいて、物理的または仮想的にグループ化することができる（図示せず）。これにより、クラウド・コンピューティング環境５０は、クラウドの利用者がローカル・コンピューティング・デバイス上にリソースを維持する必要のないサービスとして、インフラストラクチャ、プラットフォーム、またはソフトウェア、あるいはその組合せを提供することができる。図１に示したコンピューティング・デバイス５４Ａ～５４Ｎのタイプは、単に例証であることを意図するものであり、コンピューティング・ノード１０およびクラウド・コンピューティング環境５０は、（例えば、ウェブ・ブラウザを使用して）任意のタイプのネットワーク、またはネットワーク・アドレス可能接続、あるいはその両方で、任意のタイプのコンピュータ化されたデバイスと通信できることを理解されたい。

次に図２を参照すると、クラウド・コンピューティング環境５０（図１）によって提供される機能的抽象化層のセットが示されている。図２に示した構成要素、層、および機能は、単に例証であることを意図するものであり、本発明の実施形態は、これに限定されないことを予め理解されたい。図示のように、以下の層および対応する機能が提供される。
ハードウェアおよびソフトウェア層６０は、ハードウェアおよびソフトウェア構成要素を含む。ハードウェア構成要素の例は、メインフレーム６１、ＲＩＳＣ（縮小命令セット・コンピュータ）アーキテクチャ・ベースのサーバ６２、サーバ６３、ブレード・サーバ６４、ストレージ・デバイス６５、ならびに、ネットワークおよびネットワーク構成要素６６を含む。いくつかの実施形態では、ソフトウェア構成要素は、ネットワーク・アプリケーション・サーバ・ソフトウェア６７、およびデータベース・ソフトウェア６８を含む。
仮想化層７０は、仮想サーバ７１、仮想ストレージ７２、仮想プライベート・ネットワークを含む仮想ネットワーク７３、仮想アプリケーションおよびオペレーティング・システム７４、ならびに、仮想クライアント７５という、仮想エンティティの例を提供することができる抽象化層を提供する。

１つの例では、管理層８０が、下記で説明される機能を提供することがある。リソース提供８１は、クラウド・コンピューティング環境内でタスクを実施するために利用される計算リソースおよび他のリソースの動的な調達を行う。計量および価格設定８２は、クラウド・コンピューティング環境内でリソースが利用されるときの費用追跡、および、これらのリソースの消費量についての請求書送付またはインボイス送付を行う。１つの例では、これらのリソースは、アプリケーション・ソフトウェア・ライセンスを含むことができる。セキュリティは、クラウドの利用者およびタスクについての本人確認、ならびに、データおよび他のリソースのための保護を提供する。ユーザ・ポータル８３は、クラウド・コンピューティング環境へのアクセスを、利用者およびシステム・アドミニストレータに提供する。サービス・レベル管理８４は、必要なサービス・レベルを満たすように、クラウド・計算リソースの割当ておよび管理を提供する。サービス・レベル契約（ＳＬＡ）計画立案およびフルフィルメント８５は、ＳＬＡによる、将来の要件が予想されるクラウド・計算リソースの事前配置、および調達を行う。

ワークロード層９０は、クラウド・コンピューティング環境が利用されることがある機能の例を示す。この層から提供することができるワークロードおよび機能の例は、マッピングおよびナビゲーション９１、ソフトウェア開発およびライフサイクル管理９２、仮想クラスルーム・エデュケーション配信９３、データ分析処理９４、トランザクション処理９５、ならびにモバイル・デスクトップ９６を含む。

図３は、１つまたは複数の実施形態による、実例のＤＰＳのブロック図である。ＤＰＳは、クラウド・コンピューティング・ノード１０として使用することができる。この例証的な例では、ＤＰＳ１００は、プロセッサ・ユニット１０４、メモリ１０６、永続ストレージ１０８、通信ユニット１１０、Ｉ／Ｏユニット１１２、およびディスプレイ１１４の間の通信を提供することができる通信バス１０２を含むことができる。

プロセッサ・ユニット１０４は、メモリ１０６にロードすることができるソフトウェアのための命令を実行するように機能する。プロセッサ・ユニット１０４は、特定の実装形態に応じて、いくつかのプロセッサ、マルチプロセッサ・コア、または、プロセッサの他のいくつかのタイプであってもよい。番号は、項目を参照しながら本明細書で使用されるように、１つまたは複数の項目を意味する。さらに、プロセッサ・ユニット１０４は、単一のチップ上にメイン・プロセッサが２次プロセッサとともに存在する、いくつかの異種プロセッサ・システムを使用して実装することができる。別の例証的な例として、プロセッサ・ユニット１０４は、同じタイプの複数のプロセッサを収める対称型マルチプロセッサ・システムであってもよい。

メモリ１０６および永続ストレージ１０８は、ストレージ・デバイス１１６の例である。ストレージ・デバイスは、例えば、限定することなく、データ、関数形式のプログラム・コード、または他の適切な情報、あるいはその組合せなどの情報を、一時的または永続的あるいはその両方で格納することができるハードウェアのいずれかであってもよい。メモリ１０６は、これらの例では、例えば、ランダム・アクセス・メモリ、または、他の任意の適切な揮発性もしくは不揮発性のストレージ・デバイスであってもよい。永続ストレージ１０８は、特定の実装形態に応じて、様々な形をしていてもよい。

例えば、永続ストレージ１０８は、１つもしくは複数の構成要素またはデバイスを収めることができる。例えば、永続ストレージ１０８は、ハード・ドライブ、フラッシュ・メモリ、書換え可能光ディスク、書換え可能磁気テープ、または、上記のいくつかの組合せであってもよい。永続ストレージ１０８によって使用される媒体も、取外し可能であってもよい。例えば、取外し可能ハード・ドライブを、永続ストレージ１０８のために使用することができる。

これらの例における通信ユニット１１０は、他のＤＰＳまたはデバイスとの通信を提供することができる。これらの例では、通信ユニット１１０は、ネットワーク・インターフェース・カードである。通信ユニット１１０は、物理通信リンクとワイヤレス通信リンクのどちらかまたは両方を使用して通信することができる。

入出力ユニット１１２は、ＤＰＳ１００に接続することができる他のデバイスとのデータの入力および出力を可能にすることができる。例えば、入出力ユニット１１２は、キーボード、マウス、または他のいくつかの適切な入力デバイス、あるいはその組合せを通じたユーザ入力のための接続を行うことができる。さらに、入出力ユニット１１２は、プリンタに出力を送ることができる。ディスプレイ１１４は、ユーザに情報を表示するためのメカニズムを提供することができる。

オペレーティング・システム、アプリケーション、またはプログラム、あるいはその組合せのための命令は、通信バス１０２を通じてプロセッサ・ユニット１０４と通信中のストレージ・デバイス１１６内に置くことができる。これらの例証的な例では、命令は、永続ストレージ１０８上の関数形式である。これらの命令は、プロセッサ・ユニット１０４による実行のために、メモリ１０６にロードすることができる。異なる実施形態の処理は、メモリ１０６などのメモリ内に置くことができるコンピュータ実行命令を使用して、プロセッサ・ユニット１０４によって実施することができる。

これらの命令は、プログラム・コード、コンピュータ使用可能プログラム・コード、またはコンピュータ可読プログラム・コードと呼ばれ、プロセッサ・ユニット１０４におけるプロセッサによって読み込まれ、実行することができる。異なる実施形態におけるプログラム・コードは、メモリ１０６または永続ストレージ１０８などの、異なる物理的または有形のコンピュータ可読媒体上に具現化されてもよい。

プログラム・コード１１８は、選択的に取外し可能なコンピュータ可読媒体１２０上に関数形式で置くことができ、プロセッサ・ユニット１０４による実行のために、ＤＰＳ１００にロードまたは移送することができる。プログラム・コード１１８およびコンピュータ可読媒体１２０は、これらの例では、コンピュータ・プログラム製品１２２を形成することができる。１つの例では、コンピュータ可読媒体１２０は、コンピュータ可読ストレージ媒体１２４またはコンピュータ可読信号媒体１２６であってもよい。コンピュータ可読ストレージ媒体１２４は、例えば、永続ストレージ１０８の一部であるハード・ドライブなどのストレージ・デバイスに移送するための、永続ストレージ１０８の一部であるドライブまたは他のデバイスに挿入されるか、置かれた、光学または磁気ディスクを含むことができる。また、コンピュータ可読ストレージ媒体１２４は、ＤＰＳ１００に接続されたハード・ドライブ、サム・ドライブ、またはフラッシュ・メモリなどの、永続ストレージの形をしていてもよい。いくつかの事例では、コンピュータ可読ストレージ媒体１２４は、ＤＰＳ１００から取外し可能でなくてもよい。これらの例証的な例では、コンピュータ可読ストレージ媒体１２４は、非一過性のコンピュータ可読ストレージ媒体である。

代替として、プログラム・コード１１８は、コンピュータ可読信号媒体１２６を使用して、ＤＰＳ１００に移送することができる。コンピュータ可読信号媒体１２６は、例えば、プログラム・コード１１８を収めた伝搬データ信号であってもよい。例えば、コンピュータ可読信号媒体１２６は、電磁気信号、光信号、または他の任意の適切なタイプの信号、あるいはその組合せであってもよい。これらの信号は、ワイヤレス通信リンク、光ファイバ・ケーブル、同軸ケーブル、ワイヤ、または他の任意の適切なタイプの通信リンク、あるいはその組合せなどの、通信リンクで伝送することができる。言い換えれば、通信リンクまたは接続あるいはその両方は、例証的な例では、物理的またはワイヤレスであってもよい。

いくつかの例証的な実施形態では、プログラム・コード１１８は、ＤＰＳ１００内で使用するために、コンピュータ可読信号媒体１２６を通じて別のデバイスまたはＤＰＳから永続ストレージ１０８に、ネットワークでダウンロードすることができる。例えば、サーバＤＰＳ内のコンピュータ可読ストレージ媒体に格納されたプログラム・コードは、サーバからＤＰＳ１００にネットワークでダウンロードすることができる。プログラム・コード１１８を提供するＤＰＳは、プログラム・コード１１８を格納し、伝送することができる、サーバ・コンピュータ、クライアント・コンピュータ、または他のいくつかのデバイスであってもよい。

ＤＰＳ１００について示した異なる構成要素は、異なる実施形態を実装できる手法に、構造的に限定するためのものではない。異なる例証的な実施形態は、ＤＰＳ１００について示したものに加えて、またはその代わりに、構成要素を含むＤＰＳ内で実装することができる。図１に示した他の構成要素は、示した例証的な例から変化してもよい。

図４を参照すると、１つまたは複数の実施形態による、実例のリソース管理環境のブロック図が描写されている。リソース管理環境２００は、例証的な実施形態を実装することができる環境の例である。例証的な実施形態のリソース管理環境２００は、例えば、サーバであることもある（一括してまたは例として、参照番号２０２で言及されることがある）複数のＤＰＳ２０２ａ～２０２ｃを含むサーバ・クラスタに実装することができる。ＤＰＳ２０２は、ＤＰＳ１００の実装形態の例であってもよい。例証では、ＤＰＳブロックのうちの１つについてだけ、詳細が示されているが、他のＤＰＳ２０２が、類似のアーキテクチャを含むことがある。さらに、３つのＤＰＳブロック２０２だけが図３に示されているが、他の例では、リソース管理環境２００は、他の任意の数のＤＰＳを含むことができる。

ＤＰＳ２０２のそれぞれは、リソース・マネージャ２０３、およびリソースのセット２０６を含むことができる。リソース・マネージャ２０３は、１つまたは複数のリソース２０６の使用を管理する。さらに、リソース・マネージャ２０３は、他のＤＰＳ２０２との間で追加の計算リソース２０６を提供する／受け取るために、リソース管理環境２００における他のＤＰＳ２０２の対応するリソース管理モジュールと通信することができる。リソース・マネージャ２０３は、図に単一のブロックとして示されているが、その機能の様々な部分を、リソース管理環境２００の全体にわたって拡散させることができる。

リソースのセット２０６は、ＤＰＳ２０２内の１つまたは複数の計算リソースを指すことができる。例えば、リソースのセット２０６は、デバイス２０８を含むことができる。デバイス２０８は、例えば、プロセッサ・ユニット１０４、メモリ１０６、永続ストレージ１０８、通信ユニット１１０、入出力（Ｉ／Ｏ）ユニット１１２、およびディスプレイ１１４などのデバイスを含むことができる任意の数の異なるデバイスを含むことができる。デバイス２０８は、ＤＰＳ２０２の外部にあるデバイスも含むことができる。例えば、デバイス２０８は、ユニバーサル・シリアル・バス（ＵＳＢ）または他の適切なコネクタによって接続された、カメラまたは外部ストレージ・デバイスなど、ＤＰＳに接続されたデバイスを含むことができる。

様々な例証的な実施形態では、リソース管理プロセス２０４は、リソースの増加についてのリクエスト２１０を受け取ることができる。リソース管理プロセス２０４は、図４に示したように、ユーザ・インターフェース２１４を介して、ユーザからリクエスト２１０を受け取ることができる。それでも、リソース管理プロセス２０４は、リソース管理環境２００の一部を形成する他のエンティティからもリクエスト２１０を受け取ることができる。図５を参照すると、リクエスト２１０は、リソース・マネージャと対話するハイパーバイザ３３０から来ることがある。図６を参照すると、リクエスト２１０は、パーティション４１４ａのオペレーティング・システム４３０、または、このパーティション内で動き、パーティション・メモリ２１６を利用するアプリケーション４３５からも来ることがある。図には示していないが、いくつかの実施形態では、リクエスト２１０は、厳密には、リソース・マネージャ２０３によって受け取られる実際の通信を伴わないこともあるが、同様に、リソース・マネージャ２０３に含まれるロジック、および、リソース・マネージャ２０３が利用可能なリソース管理環境２００の様々なリソースの情報へのアクセスに基づく「推測のリクエスト」であってもよい。言い換えれば、「推測のリクエスト」は、また、いくつかの必要な（しかし、明示的にリクエストされない）リソースを独自に決定するリソース・マネージャ２０３と本明細書で解釈することもできる。本明細書で使用されるような用語「リクエスト」２１０の使用は、簡潔さのために、このような「推測のリクエスト」を含むことができる。推測のリクエストは、また、増加指示と解釈することもできる（すなわち、増加指示は、パーティションのために処理能力を増加させることを明示的にリクエストしていない、いくつかの必要なリソースを決定するものと解釈することができる）。

これらの例では、リクエスト２１０は、リソースのセット２０６における能力またはパフォーマンスの増加についての増加リクエストであってもよい。例えば、リクエスト２１０は、ＣＵｏＤについてのリクエストであってもよい。１つの例では、リクエスト２１０は、リソースのセット２０６の処理能力２１２を増加させたいというリクエストである。別の例では、リクエスト２１０は、リソースのセット２０６のためのメモリ２１６の増加についてのリクエストである。さらに別の例証的な例では、リクエスト２１０は、リソースのセット２０６のための入出力デバイスのセット２１８の増加についてのリクエストであってもよい。増加の決定は、１つの実装形態では、リソース・マネージャ２０３によって受け取られた増加リクエストに基づくことができる。リクエストは、パーティション内で動くオペレーティング・システムに、または、パーティション内のオペレーティング・システム上で動くアプリケーションに、あるいはその両方に由来してもよい。

リソースのセット２０６の処理能力２１２を増加させたいというリクエスト２１０を、リソース管理プロセス２０４が受け取る（または推測する）と、リソース管理プロセス２０４は、複数のコア２２２の非アクティブコア２２０をアクティブ化するべきかどうかを判定し、リクエスト２１０を承認することができる。これらの例では、コア２２０は、プロセッサのセット２２４内の複数のコア２２２に含まれるコアである。例えば、複数のコア２２２内のコアのセット２２６は、プロセッサのセット２２４においてアクティブ状態２２３にある。本明細書で使用されるように、プロセッサ内のコアに言及するときの「アクティブ」は、命令を動作および実行し、プロセッサのための動作を実施するために、コアが現時点で利用可能であることを意味する。コア２２０は、プロセッサのセット２２４内で非アクティブであってもよい。本明細書で使用されるように、プロセッサ内のコアに言及するときの「非アクティブ」は、命令を実行し、プロセッサのための動作を実施するために、コアが現時点で利用可能でないことを意味する。例えば、コア２２０は、非アクティブ状態２２１であっても、アクティブ状態２２３であってもよい。コア２２０の非アクティブ状態２２１は、命令を実行するために、コア２２０が現時点で利用可能でないときである。例えば、コア２２０は、プロセッサ・ユニットのセット２２４において非アクティブ状態２２１である間、スリープ状態であってもよい。リソースのセット２０６においてアクティブ状態２２３になるようにコア２２０をアクティブ化すると、リソースのセット２０６の処理能力２１２を増加させることができる。１つの実施形態では、非アクティブコアは、また、通常動作中にユーザに利用されないコアであってもよく、一定の条件下でのみアクティブ化される潜在的なプロセッサ能力を表す。したがって、非アクティブ状態のプロセッサは、プロセッサ・ユニットのセット内に予め存在している潜在的なＣＰＵ能力（ＬＣＣ）に相当する。

リソース管理プロセス２０４は、コア２２０をアクティブ化するためのリソースの使用が、ＤＰＳ２０２における１つまたは複数のリソース使用ポリシまたはルール２３０を満たすかどうかを判定することができる。例えば、１つまたは複数のポリシ２３０は、ＳＬＡ、ＤＰＳ２０２における電力の使用についてのルールを示す電力使用ポリシ、等を含むことができる。例えば、一定量の処理能力だけが、ＤＰＳ２０２での使用に利用可能であってもよい。１つまたは複数のポリシは、ＤＰＳのどのユーザまたはクライアント・デバイスが、ユーザとのＳＬＡに基づいて、ＤＰＳ２０２における一定のリソースを使用することができるかについてのルールも含むことができる。

第１の周波数２２８でコア２２０をアクティブ化することによって生じるリソースの使用が１つまたは複数のポリシ２３０を満たすとリソース管理プロセス２０４が判定すると、リソース管理プロセス２０４は、第１の周波数２２８でコア２２０をアクティブ化することができる。例えば、リソース管理プロセス２０４は、第１の周波数２２８を確立すること、および、コア２２０上での命令を予定することによって、コア２２０をアクティブ化することができる。その一方で、１つまたは複数のポリシ２３０を満たしていない場合、リソース管理プロセス２０４は、処理能力２１２を増加させたいというリクエスト２１０を拒否することができる。リソース管理プロセス２０４は、処理能力２１２を増加させたいというリクエスト２１０が利用不可能であるという指示２２７を提供することができる。例えば、リソース管理プロセス２０４は、ユーザ・インターフェース２１４を介したユーザへの指示２２７、または、示されたリクエストについてのメッセージングまたはロギングのいくつかの形を提供することができる。

これらの例では、最低動作周波数は、コアが動作できる最低周波数であってもよい。最低周波数は、コアの物理的な特性、コアの論理設計の結果、または、システムの様々な構成要素を相互接続するバスのサイズなど、システムの別の特性によるものであってもよい。限界の原因が何であっても、明確に定義された最低動作周波数があってもよい。

リソース管理プロセス２０４は、次に、コア２２０の第１の周波数２２８を増加させることができる。これらの例証的な例では、第１の周波数２２８の所望の値は、リソースのセット２０６のための処理能力２１２の増加量に基づいて選択することができる。この例では、コア２２０およびコアのセット２２６は、同じ周波数で動作することができる。それでも、この同じ周波数は、コア２２０のアクティブ化前の、コアのセット２２６の第２の周波数２３２より低くてもよい。

上記の例は、プロセッサ周波数の調節の形でリソースを調節することを説明しているが、他の例では、異なるタイプのリソースを調節することができる。例えば、リクエスト２１０は、また、リソースのセット２０６におけるメモリ２１６の増加についてのリクエストであってもよい。例えば、上記で説明したユーザまたは他のエンティティは、キャパシティ・アップグレード・オン・デマンドで追加のメモリをリクエストすることができる。代替としてまたはさらに、リソース管理プロセス２０４は、データがメモリ２１６に読み書きされる速度２４４を識別することができる。リソース管理プロセス２０４は、例えば、スロットリングによって、速度２４４を調節することができる。スロットリングは、メモリ２１６上で実施される動作に休眠期間を挿入するという処理である。例えば、一定期間、メモリ２１６は、非アクティブであってもよい。メモリ２１６が非アクティブだと、データがメモリ２１６に読み書きされる速度２４４が低下する。１つまたは複数の例では、特定の機能のために以前に予約された専門のコンピュータ・リソースも、限定的な期間、ユーザに利用可能にされてもよい。

さらに、１つまたは複数の例では、リクエスト２１０は、また、リソースのセット２０６のための入出力デバイスのセット２１８の増加についてのリクエストであってもよい。例えば、上記で説明したユーザまたは他のエンティティは、キャパシティ・アップグレード・オン・デマンドで追加の入出力デバイスをリクエストすることができる。入出力デバイスのセット２１８は、例えば、永続ストレージ１０８および通信ユニット１１０などの、永続ストレージまたは通信ユニットあるいはその両方を含むことができる。

本明細書で説明される１つまたは複数の実施形態によれば、リソース管理プロセス２０４は、リソースのセット２０６を監視し、リクエスト２１０を管理することができる。リソース管理プロセス２０４は、リクエスト２１０が許可された後、ＤＰＳ２０２におけるリソース２０６の使用を監視することができる。リソース２０６の使用がＳＬＡまたは他のポリシを満たさない場合、リソース管理プロセス２０４は、リソースのセット２０６におけるデバイス２０８のパラメータのセット２４８を調節することができる。例えば、リソース管理プロセス２０４は、メモリ２１６の転送速度２４４を調節することができる。リソース管理プロセス２０４は、コアのセット２２６の第２の周波数２３２、またはコア２２２のセットに供給される電圧を調節することができる。周波数および電圧の調節は、スケーリングと呼ばれることがある。リソース管理プロセス２０４は、電力使用ポリシ２３０を満たすように、周波数および電圧をスケーリングすることができる。リソース管理プロセス２０４は、また、コア２２０が非アクティブ状態２２３になるようにコア２２０を、メモリ２１６の一部を、または、入出力デバイスのセット２１８におけるデバイスを、あるいはその組合せを非アクティブ化することができる。

１つの例証的な例では、リソース管理プロセス２０４は、処理能力２１２を維持するために、リソースのセット２０６におけるアクティブ状態２２３にあるべきコアのセット２２６のコア２２０の数を識別することができる。リソース管理プロセス２０４は、コアのセット２２６が動作している第２の周波数２３２を監視することができる。リソース管理プロセス２０４は、次に、この第２の周波数２３２を、コアのセット２２６の公称周波数２５０と比較することができる。公称周波数２５０は、周波数の変化（低減／増分）がない状態で、コアのセット２２６が動作できることが期待される周波数である。

１つまたは複数の実施形態によれば、ＤＰＳ２０２におけるリソースのセット２０６は、ＤＰＳ２０２内のパーティションであってもよい。例えば、リソースのセット２０６は、共通筐体内の、デバイス２０８が置かれる物理パーティションであってもよい。メモリ２１６および入出力デバイスのセット２１８も、共通筐体内に置くことができる。他の例証的な実施形態では、プロセッサのセット２２４、メモリ２１６、および入出力デバイスのセット２１８は全て、１つまたは複数の通信ユニットを介して相互接続され、互いに外部に置かれたリソース・プールの一部であってもよい。リソース管理プロセス２０４は、デバイス２０８をアロケートして、リソースのセット２０６を形成することができる。リソースの所与のセット２０６は、１つまたは複数のユーザによって同時に使用することができる。

別の例では、コア２２０は、リソースのセット２０６の一部でなくてもよい。処理能力２１２を増加させたいというリクエスト２１０をリソース管理プロセス２０４が受け取ったとき、リソースのセット２０６内の全てのコアが動作していてもよい。リソース管理プロセス２０４は、リソースの異なるセットからリソースのセット２０６に、コア２２０をアロケートすることができる。同様に、メモリ２１６および入出力デバイスのセット２１８も、リソースのセット２０６にアロケートすることができる。

さらに別の例では、リクエスト２１０は、一時的なリクエストであってもよい。リクエスト２１０は、ただ１つの期間の能力の増加についてのリクエストであってもよい。この期間の後、リソース管理プロセス２０４は、リクエスト２１０を許可するためにアクティブ化されたデバイスを非アクティブ化することができる。他の例では、リクエスト２１０は、時間を基準値として使用すること以外の、サービス請求基準または別のポリシ・ベースの判断基準に基づいてもよい。

図５は、１つまたは複数の実施形態による、リソース・マネージャ２０３について詳細に説明するＤＰＳ２０２の実例のブロック図である。リソース・マネージャ２０３は、リソース管理プロセス２０４およびアップグレード管理プロセス３０６を含むことができる。例えば、リソース管理プロセス２０４は、ＤＰＳ２０２におけるデバイスによる計算リソースの使用を管理することができる。アップグレード管理プロセス３０６は、例えば、リクエスト２１０などの能力の増加についてのリクエストを管理することができる。

ＤＰＳ２０２は、リソースのセット２０６を含むことができる。リソースのセット２０６は、基板のセット３１０、メモリ２１６、および入出力デバイスのセット２１８を含むことができる。基板のセット３１０、メモリ２１６、および入出力デバイスのセット２１８は、これらの例におけるリソースのセット２０６内にあってもよいリソースである。基板のセット３１０は、いくつかのプロセッサ３１６を含むことができる。例えば、基板のセット３１０は、プロセッサ３１６ａ、３１６ｂを含むことができる。他の例では、基板のセット３１０は、任意の数のプロセッサを含むことができる。これらの例では、基板のセット３１０は、ＤＰＳ内に構成要素を配置するため、および、ＤＰＳ内の構成要素間の接続を行うための、任意の表面であってもよい。例えば、限定することなく、基板のセット３１０は、プリント回路基板、マザーボード、ブレッドボード、または他の適切な表面、あるいはその組合せであってもよい。

１つまたは複数の例では、基板のセット３１０は、プロセッサ３１６を制御するコントローラ３２４も含むことができる。例えば、コントローラ３２４は、プロセッサ３１６ａ、または、プロセッサ３１６ａの内部にある複数のコア２２２におけるコア２２０ａの１つをアクティブ化することができる。コントローラ３２４は、複数のコア２２２におけるコア２２０のそれぞれが動作する周波数も制御することができる。コントローラ３２４は、複数のコア２２２におけるコア２２０に印加される電圧も制御することができる。コントローラ３２４は、例えば、限定することなく、マイクロコントローラ、プロセッサ、電圧および周波数センサ、発振器、または他の任意の適切なデバイス、あるいはその組合せなどのハードウェア・デバイスを含むことができる。他の例では、コントローラ３２４は、プロセッサ３１６を制御するためのプログラム・コードを含むことができる。

リソース管理プロセス２０４およびアップグレード管理プロセス３０６は、コントローラ３２４と通信して、リソースのセット２０６におけるリソースを管理する。例えば、リソース・マネージャ２０３は、ユーザ・インターフェース２１４、または上記で論じた他の要素からの、リクエスト２１０を介して、リソースのセット２０６の能力を増加させたいというリクエストを受け取ることができる。リクエスト２１０は、複数のコア２２２における１つまたは複数のコア２２０をアクティブ化することによって処理能力を増加させたいというリクエストであってもよい。複数のコア２２２におけるいくつかのコアは、非アクティブ状態２２１であってもよい。リソースのセット２０６は、一定数のコアをアクティブ化することを許可されることもある。言い換えれば、リソースのセットは、複数のコア２２２における一定数のコア２２０を使用するように、ライセンスされることもある。１つまたは複数の例では、リクエスト２１０は、ライセンス・コードを含むことができる。ライセンス・コードは、コア２２０ａの識別子、およびコア２２０ａをアクティブ化するためのキーを含むことができる。リソース・マネージャ２０３は、ライセンス・コードを受け取り、ハイパーバイザ３３０と通信して、複数のコア２２２の中のどのコアにライセンスするかを決定することができる。

ハイパーバイザ３３０は、複数のオペレーティング・システムをＤＰＳ２０２上で動かすことができることがあるモジュールである。ハイパーバイザ３３０は、リクエストからのライセンス・コードを、ストレージ・デバイスに格納されたライセンス・コードのセット３３２と比較することができる。これらの例では、複数のコア２２２の中の各コアは、ライセンス・コードのセット３３２におけるライセンス・コードを有する。リクエストからのライセンス・コードが、ライセンス・コードのセット３３２におけるライセンス・コードに一致する場合、ハイパーバイザ３３０は、ライセンス・コードのセット３３２において一致したライセンス・コードに、複数のコア２２２におけるどのコアが対応するかを判定する。判定されたコアは、リソースのセット２０６におけるライセンス予定のコア２２０である。ハイパーバイザ３３０は、リソースのセット２０６におけるライセンス予定のコア２２０をリソース・マネージャ２０３に伝達する。その一方で、リクエストにおけるライセンス・コードが、ライセンス・コードのセット３３２におけるライセンス・コードに一致しない場合、リクエスト２１０を拒否することができる。下記でより詳細に説明される一定の状況下では、リクエスト２１０を受け入れるか、利用可能なリソースを増加させるために、このようなライセンス・コード３３２を使用する必要がない。

追加として、リソースのセット２０６がＤＰＳ２０２内のパーティションである場合、ハイパーバイザ３３０は、パーティション・マネージャ３３４と通信して、どのリソースがパーティション４１４（図６）の一部であるかを判定することができる。例えば、処理能力を増加させたい（計算リソースの増加）というリクエスト２１０は、特定のパーティションにおける能力を増加させたいというリクエストであってもよい。ハイパーバイザ３３０は、複数のコア２２２の中の、ライセンスされたいとリクエストされたコア２２０ａが、パーティション４１４の一部であることを確認することができる。パーティション・マネージャ３３４は、特定のパーティション４１４の一部であるリソースのリスト化を続けることができる。ライセンスされたいとリクエストされたコア２２０ａが、能力の増加をリクエストするパーティションの一部でない場合、パーティション・マネージャ３３４は、パーティション４１４にコア２２０ａをアロケートすることができる。次に、ハイパーバイザ３３０は、リソースのセット２０６におけるライセンス予定のコア２２０ａを、リソース・マネージャ２０３に伝達することができる。

これらの例証的な例では、リソース・マネージャ２０３は、コア２２２におけるライセンス予定のコア２２０ａを識別する情報を受け取ることができる。アップグレード管理プロセス３０６は、次に、コントローラ３２４に命令を送り、複数のコア２２２におけるライセンス予定のコア２２０ａをアクティブ化することができる。１つまたは複数の例では、アップグレード管理プロセス３０６は、コア・パフォーマンス・センサ３３６を含むことができる。コア・パフォーマンス・センサ３３６は、コア２２２からの１つまたは複数のコアのパフォーマンスを監視する。例えば、コア・パフォーマンス・センサ３３６は、複数のコア２２２の中のアクティブコアが動作する周波数を監視することができる。アップグレード管理プロセス３０６は、図４のコア２２０について以前に論じたように、複数のコア２２２における他のアクティブコアと同じ周波数になるように、コア２２０ａをアクティブ化することができる。他の例では、アップグレード管理プロセス３０６は、第１の周波数でコア２２０ａをアクティブ化し、周波数を調節して、リソースのセット２０６における複数のコア２２２の処理能力を増加させることができる。

ＤＰＳ２０２におけるリソース・マネージャ２０３の図は、異なる特徴を実装することができる手法を物理的または構造的に限定することを意味するためのものではない。図示したものに加えて、またはその代わりに、あるいはその両方で、他の構成要素を使用することができる。また、いくつかの機能的な構成要素を図示するために、ブロックを提示する。これらのブロックの１つまたは複数は、異なる例証的な実施形態で実装されるとき、異なるブロックへの結合または分割あるいはその両方を行うことができる。これは、当業者によって理解されるように、図に示したブロックのいずれかに当てはまる。

例えば、限定することなく、いくつかの例証的な実施形態では、リソース・マネージャ２０３は、ＤＰＳ２０２の一部でなくてもよい。リソース・マネージャ２０３は、ＤＰＳ２０２から遠くに置くことができる。例えば、リソース管理プロセス２０４およびアップグレード管理プロセス３０６は、ＤＰＳ２０２から遠くに置かれたコンピューティング・システム上で動いていてもよい。リソース管理プロセス２０４およびアップグレード管理プロセス３０６は、他のデータ処理要素と通信して、ＤＰＳ２０２における電力の使用を監視し、制御することができる。

他の例証的な実施形態では、リソースのセット２０６は、基板のセット３１０のような、任意の数の基板を含むことができる。リソースのセット２０６における各基板には、例えばコントローラ３２４などの別個のコントローラがあってもよい。コントローラ３２４は、リソースのセット２０６の基板のセット３１０における２つ以上の基板上のプロセッサも制御することができる。いくつかの例証的な実施形態では、コア・パフォーマンス・センサ３３６などのセンサは、リソースのセット２０６における各基板上に置くことができる。他の例では、リソースのセット２０６は、各リソースのためのセンサを含むことができる。コア・パフォーマンス・センサ３３６におけるセンサは、プロセッサ３１６における個々のプロセッサ、および、複数のコア２２２におけるコアの一部であってもよい。

図６は、例証的な実施形態による、ＤＰＳ２０２におけるパーティションのセット４０２の例を示すブロック図である。ＤＰＳ２０２は、パーティションのセット４０２を含む。図示の例では、リソース・マネージャ２０３は、ＤＰＳ２０２におけるパーティションのセット４０２についてのリソース使用ポリシ２３０を含むことができる。リソース使用ポリシ２３０は、ＤＰＳ２０２における計算リソースの使用を指定するポリシ、またはルールのセットを組み込むことができる。例えば、リソース使用ポリシ２３０は、リソース制限４０８を含むことができる。リソース制限４０８は、ＤＰＳ２０２での使用に利用可能な計算リソースの量の制限であってもよい。リソース制限４０８は、また、パーティションのセット４０２からのパーティション４１４ａが「消費する」または「使用する」ことができる電力量の制限であってもよい。１つまたは複数の例では、リソース制限４０８は、パーティションに関するＳＬＡに基づくことができ、ＳＬＡは、パーティションを使用しているユーザとともに定められる。

これらの例証的な例では、リソース使用ポリシ２３０は、パーティション４１４ａについての閾値のセット４１２を含むことができる。閾値のセット４１２は、パーティション４１４ａにおけるデバイスについてのリソース使用閾値を含むことができる。例えば、閾値のセット４１２は、基板のセット３１０からの各基板、メモリ２１６、または入出力デバイスのセット２１８、あるいはその組合せについてのリソース使用閾値を含むことができる。したがって、閾値のセット４１２における電力使用閾値は、パーティション４１４ａにおけるデバイスに固有のものであってもよい。同様に、プロセッサのセット２２４における各プロセッサ、およびコアのセット２２２における各コアは、電力の使用についての閾値のセット４１２における閾値を有することができる。

リソース・マネージャ２０３は、パーティション４１４ａにおけるデバイスによる計算リソースの使用を監視することができる。リソース・マネージャ２０３は、パーティション４１４ａにおけるデバイスによる計算リソースの使用が、閾値のセット４１２における閾値内であるかどうかを判定することができる。計算リソースの使用が閾値内ではない場合、リソース・マネージャ２０３は、計算リソースの使用が、リソース使用ポリシ２３０を満たしていないと判定することができる。

リソース・マネージャ２０３は、パーティション４１４ｂおよび４１４ｃで使用される計算リソースも監視することができる。例えば、リソース使用ポリシ２３０は、パーティション４１４ｂにおけるデバイスによる計算リソースの使用についての閾値のセット４１２ｂを含むことができる。閾値のセット４１２ｂは、パーティション４１４ｂにおける計算リソースの使用を制限することができる。例えば、リソース・マネージャ２０３は、パーティション４１４ｂにおける能力を増加させたいというリクエスト２１０を受け取ることができる。リソース・マネージャ２０３は、計算リソースの使用が、閾値のセット４１２ｂ内であり、リソース使用ポリシ２３０を満たす場合、リクエストの許可から生じる計算リソースの使用のリクエストを許可することができる。パーティション４１４ｂについての閾値のセット４１２ｂは、パーティション４１４ｂにおけるデバイスによる計算リソースの使用の増加が、例えば、ＳＬＡによる契約値を超えないことを保証することができる。したがって、リソース・マネージャ２０３は、リクエストによって能力がＳＬＡ値を超えるようにさせるとき、１つのパーティションにおける能力を増加させたいというリクエストを許可することができない。

リソース・マネージャ２０３は、リソース管理環境２００における別のＤＰＳ２０２からリソース２０６をアロケートすることができる。例えば、診断イベント、初期プログラム・ロード、トレースのキャプチャ、または他の任意のこのような計算負荷の高い動作を含むことができる、第１のＤＰＳ２０２の内部イベント、または通常動作から外れた状況のために、第１のＤＰＳのプロセッサ２２４のうちの１つが使用されている場合、リソース・マネージャ２０３は、第１のＤＰＳ２０２における１つまたは複数の動作／ワークロードをハンドリングするために、第２のＤＰＳ２０２からプロセッサ２２４の１つをアロケートすることができる。同様に、第１のＤＰＳ２０２の計算リソース２０６のいずれかが、異常イベントのために使用されている場合、第２のＤＰＳ２０２の他の任意のタイプのリソース２０６を、第１のＤＰＳ２０２のタスク／動作を実施するためにアロケートすることができる。

１つまたは複数の例では、レポート・モジュール４４０は、パーティションのセット４０２におけるパーティションのそれぞれによる計算リソース使用量を受け取る。レポート・モジュール４４０は、対応するパーティションによって使用された計算リソースに応じて、１つまたは複数のそれぞれのユーザ（クライアント・デバイス）への請求を自動的に生成することができる。例えば、レポート・モジュール４４０は、特定の計算リソースがパーティション４１４によって使用された持続期間を受け取ることができる。レポート・モジュール４４０は、パーティション４１４を使用しているユーザのＳＬＡを使用して、パーティション４１４によって使用された計算リソースの１つまたは複数についての料金を決定することができ、ＳＬＡに従ってユーザへの請求額を計算することができる。

ＤＰＳ２０２におけるパーティションのセット４０２の図は、異なる特徴を実装できる手法に、物理的または構造的に限定することを意味するためのものではない。他の構成要素は、図示したものに加えて、またはその代わりに、あるいはその両方で、使用することができる。

異常イベントの場合、１つまたは複数の計算リソースは、異常イベントに対処するために使用することができる。計算リソースのこのような使用は、異常イベントに対処することを、ＤＰＳ２０２の内部イベントとみなすことができるので、ユーザに請求する必要はない。さらに、異常イベントによって、ユーザは、ユーザによって提供されるサービスを機能停止させることができる。例えば、ユーザは、機能停止の最も小さいものであっても大きな影響をもたらすことがある、ソーシャル・ネットワーク・プロバイダ（例えば、ＦａｃｅＢｏｏｋ（登録商標））、ｅコマース・プロバイダ（例えば、Ａｍａｚｏｎ（登録商標））、金融機関（例えば、銀行）、ヘルス・サービス・プロバイダ（例えば、医者、病院、保険プロバイダ）などの、クラウド・サービス・プロバイダであってもよい。本明細書で説明されるように、１つまたは複数の例では、クラウドの機能停止および他の異常イベントは、ＤＰＳ２０２のインフラストラクチャにおける故障の結果になることがある。代替としてまたはさらに、故障は、クラウド・サービス・プロバイダ、またはクラウド・サービス・プロバイダのエンド・ユーザによってもたらされるワークロードによって引き起こされることがある。機能停止または異常イベントの原因に関わらず、ＤＰＳ２０２上で実行するシステムができるだけ速く、通常の実行状態で動作していることが重要である。

典型的には、故障状態の診断は、リソース負荷の高い診断を必要とする。例えば、詳細なトレース記録の作成、および追加のデータ・ロギングを、故障診断が必要とするとき、追加のプロセッサ・リソースを消費することがある。１つまたは複数のプロセッサの分岐トレースなど、ハードウェア機能の中には、著しいプロセッサのオーバヘッドをもたらすことがあるものもある。さらに、ｘ８６アーキテクチャなど、プロセッサ上のスタック・オーバレイのデバッグは、追加のプロセッサが、ポインタおよび制御スタック配置をチェックすることを必要とすることがある。１つまたは複数の例では、計算リソース負荷の高いトレースまたは診断を必要とする故障状態の原因となる異常イベントが、パーティション４１４で発生することがあるが、他のパーティションは、通常の処理を続け、故障状態ではない。

１つまたは複数の例では、このような機能停止をハンドリングするために、クラスタ化されたコンピューティングが、ＨＡ処理を提供するための共通の技法である。ＨＡシステムでは、複数のマシンがセットアップされ、それぞれが、ワークロードを実行することができる。１つまたは複数の例では、ワークロードを、クラスタ内の複数のマシン上で分担し、同時に実行することができる。クラスタ内の１つのマシンが機能停止、または故障状態になると、クラスタ内の第２のマシンからの追加のプロセッサが、機能停止の診断をサポートすることができる。代替としてまたはさらに、クラスタ内の第２のマシンは、故障している第１のマシンが動作させていた追加のワークロードを負担することができる。このような場合、フォールバック・システム、つまり、この場合、第２のマシンにかかる追加のワークロードは、第２のマシンとしての定常状態の負荷より高い。さらに、第２のマシンは、１次システム、つまり、故障している第１のマシンが機能していない間に生じた、何らかのバックログのワークロードを完了させるために、追加の動作を実施しなければならないことがある。このフォールバック動作は、計画的であることも、計画的でないこともある。

したがって、故障状態を解消することは、計算リソース負荷の高いものになることがある。例えば、故障状態を解消することは、トレース動作を実施してシステム・ダンプをキャプチャし、キャプチャしたシステム・ダンプのデータを使用してＤＰＳ２０２を診断することを含むことがある。さらに、解消は、パーティション４１４におけるオペレーティング・システムをリスタートすることを含むことがあり、これは、ＩＰＬ（ブートすること）を含むことがある。ＩＰＬは、計算負荷の高い処理になることがある。計算リソースのこのような使用は、ＳＬＡで契約できるレベルのパフォーマンスをユーザが受け取らないので、ユーザとのＳＬＡに影響を及ぼすことがある。

追加または代替として、１つまたは複数の例では、１つのＤＰＳからもう１つのＤＰＳにワークロードを移すことが必須になることがある。例えば、米国政府は、銀行業界および他の機密を扱う業界が、２つ以上のＤＰＳ間で処理の定期的な移転を実施して、コンプライアンスを示すことを要求するという規制を行っている。ワークロードのこのような移転は、ＤＰＳがＩＰＬを実施する原因となる。

このような故障状態の解消およびＩＰＬは、ＤＰＳの動作を遅くするという技術的問題の原因となる。さらに、この技術的問題は、ユーザによる通常のワークロード以外の動作のために、計算リソースを使用することを含むことがある。それどころか、計算リソースは、ユーザには見えない内部データ処理動作のために使用されることがある。

したがって、１つまたは複数の実施形態は、プロセッサから、またはクラスタ内の１つもしくは複数のプロセッサから処理能力を奪う異常イベントを検出することによって、このような技術的問題に対処し、これらの条件下で、追加のＣＰＵまたは他のリソースを提供することができる。１つまたは複数の実施形態によれば、１つのハイパーバイザ（またはパーティション）におけるＩＰＬ／ブートをＤＰＳが検出すると、ＤＰＳは、１つまたは複数のハイパーバイザと連動して、ブート・システムまたはパーティションによって使用されるプロセッサの処理能力を増加させることができる。増加は、リソースのこのような増加に対して、ユーザへの対応する請求または会計を行わずに実施することができる。ＤＰＳは、ＩＰＬ／ブートを検出することができるが、ハイパーバイザも、１つの実施形態では、ハンドリングのために、ＤＰＳにＩＰＬをレポートすることができ、または、リクエスト２１０を介して、追加のリソースについてのリクエストをレポートすることができる。同様に、パーティション内のＯＳまたはアプリケーションが、類似のリクエストを行うことができる。

能力増加の持続期間は、所定のウォール・クロック（すなわち、世界）時間、所定の数のプロセッサ・サイクル、または所定のイベントであってもよい。持続期間は、これらまたは他の判断基準のいずれかを考慮する所定のルールのセットによって同様に影響を受けることがある。この文脈で使用される用語「所定の」は、異常イベントの発生の前に、いずれかのエンティティによって定義されることを意味する。

ブート／ＩＰＬ／回復を現在行っていない他のパーティション（仮想マシン）のために安定したパフォーマンスを維持しつつ、パーティション（仮想マシン）のブート／ＩＰＬ／回復をサポートするために、改善されたパフォーマンスをターゲットにすることができる。１つまたは複数の実施形態は、ベア・メタル・マシンに、また、レベル１およびレベル２のハイパーバイザを含む様々なレベルのハイパーバイザに、適用することができる。

「ベア・メタル」マシンは、典型的には、単一のオペレーティング・システムまたはハイパーバイザをホストし、ベア・メタル上で動くオペレーティング・システムのブート／ＩＰＬ／回復時間をブーストするための能力を含むことができる。第１レベルのハイパーバイザは、１台のベア・メタル・マシン上で動き、単一のオペレーティング・システムまたはハイパーバイザをそれぞれがホストできる多くのマシンをシミュレートする。第１レベルのハイパーバイザは、ベア・メタル・マシンと連動して、第１レベルのハイパーバイザの下で動くオペレーティング・システムのうちの１つまたは複数のブート／ＩＰＬ／回復時間をブーストするための能力を提供することができる。ＩＢＭ ｚ１４（登録商標）上のＬＰＡＲは、第１レベルのハイパーバイザの例である。第２レベルのハイパーバイザは、第１レベルのハイパーバイザによってホストされるハイパーバイザである。第２レベルのハイパーバイザも、単一のオペレーティング・システムまたはハイパーバイザをそれぞれ動かすことができるマシンをシミュレートすることができる。第２レベルのハイパーバイザは、第１レベルのハイパーバイザと、また、ベア・メタル・マシンと連動して、第２レベルのハイパーバイザの下で動くオペレーティング・システムのうちの１つまたは複数のブート／ＩＰＬ／回復時間をブーストするための能力を提供することができる。ＩＢＭ ｚ１４（登録商標）上のＬＰＡＲの下で動くｚＶＭ（登録商標）は、第２レベルのハイパーバイザの例である。ＩＢＭ ｚ１４（登録商標）上のＬＰＡＲの下で動いているｚＶＭ（登録商標）の下で動くｚＶＭ（登録商標）は、第３レベルのハイパーバイザの例である。ハイパーバイザの下のハイパーバイザのチェーンは、無限に続けることができる。これらのハイパーバイザのそれぞれは、ハイパーバイザがホストするオペレーティング・システムのためのブート／ＩＰＬ／回復時間をブーストすることができる。パフォーマンス・ブーストを許可および分離するためのメカニズムは、ハイパーバイザの各レベルでわずかに異なることがあるが、基本的な概念および価値命題は同じままである。

増加したパフォーマンスは、ＤＰＳ２０２において、少なくとも２つの方式で使用することができる。第１に、計算リソースの増加は、ブート／ＩＰＬ／回復プロセスを短くすることができる。第２に、計算リソースの増加は、ブート／ＩＰＬ／回復プロセスの完了後に、ワークロードのバックログを完了させるために使用できる追加の処理能力をもたらすことができる。計算リソースの増加は、ＤＰＳ２０２のパフォーマンス能力の増加を容易にすることができ、ブートが完了すると、ワークロードのバックログの完了をより速くするために使用することができる。

１つまたは複数の例では、第２のＤＰＳ２０２から計算リソースをアロケートすることによって得られたパフォーマンスの増加は、第１のＤＰＳ２０２に十分な能力をもたらすことを容易にすることができるが、サーバ・クラスタ（すなわち、リソース管理環境２００）の１つまたは複数のメンバには、異常イベントによる追加の処理コストがかかる。１つまたは複数の例では、第１のＤＰＳ２０２と第２のＤＰＳ２０２の両方が、同じサーバ・クラスタの一部である場合、第２のＤＰＳ２０２は、第１のＤＰＳ２０２（または他の任意のＤＰＳ）に追加の計算リソースを許可することができる。代替としてまたはさらに、１つまたは複数の例では、第２のＤＰＳ２０２は、第２のサーバ・クラスタ（リソース管理環境２００）の一部であるＤＰＳ２０２の処理コストを相殺するために、追加の計算リソースを提供することができる。１つまたは複数の例では、第２のサーバ・クラスタからの計算リソース２０６を使用すると、異常イベントを完了させるために費やされる処理コストを相殺し、例えば、トレースなどの診断イベントといった、異常イベントを解消することができる。

プロセッサ２２４は、異なるコスト／パフォーマンスのトレード・オフを行うことができる。例えば、ＩＢＭ ｚ１４（登録商標）などのプロセッサは、２６個の別個の能力レベルを提供し、したがって、プロセッサのセットが６つあるＤＰＳは、合計１５６個の能力設定（２６×６）を提供することができる。１つまたは複数の例では、プロセッサ２２４は、パーティション４０２の定常状態動作中に、人為的に低減させた能力レベルで動作することができる。能力レベルは、追加の計算リソースを使用するようにプロセッサ２２４に命令すること、プロセッサ２２４が動作する周波数を変えることなどによって増加させることができる。追加としてまたは代替として、能力レベルは、非アクティブ状態２２１の１つまたは複数のコア２２０をアクティブ化することによって増加させることができる。プロセッサ２２４は、ＡＲＭ（登録商標）プロセッサ、Ｘ８６アーキテクチャ・ベースのプロセッサなど、上記の例以外の任意のプロセッサのタイプであってもよいことに留意されたい。

プロセッサ・スピードを増加させること、非アクティブコアを追加すること、または両方によって、プロセッサ・リソースを増加させるべきかどうかについての決定を、リソース・マネージャ２０３によって決定することができる。ほとんどのパーティション、またはパーティション内の活動、あるいはその両方が、プロセッサ・スピードの増加から恩恵を受けていると、堅牢である。それでも、全てのパーティションまたはパーティション内の活動が、追加のアクティブコアの導入による恩恵を受けることができるわけではない。したがって、リソース・マネージャ２０３は、リソースをブーストするときに、どのアプローチが有益になる可能性が最も高いかについて決定するのに役立てることができるデータベースを備えることができ、様々な状況下で追加することになるリソースの範囲を決定するのに役立つルールをさらに含むことができる。１つの実施形態では、パーティション、またはパーティションで動く動作、あるいはその両方が、別個のコア上でそれぞれ動くことができる複数のスレッドとともに動くことができると判定されたとき、ハイパーバイザは、第２のコアのアクティブ化が異常イベントの対処に有益であると判定することができる。

追加として、異常イベントは、異常イベントのステージ、または異常イベントのサブイベント、あるいはその両方で構成されてもよく、これらのステージ／サブイベントに応じて、異なる量のリソースを追加することができる。所与の状況で追加すべきリソースの量は、テーブルまたはデータベースに格納することができ、利用可能な実際のハードウェアの様々な特性、異常イベントのタイプ、未使用リソースの量に依存することがある。追加すべきリソースの量は、数あるものの中でも、所定の格納された値を利用した、計算した公式の値にさらに基づくことができる。非アクティブなプロセッサをアクティブ化するという形でリソースを適用するとき、１つの実装形態では、このような追加および除去は、プロセッサ・スピードの修正とも組み合わせることができ、このような組合せでは、システム処理能力のなめらかな遷移が、別途発生することがある突然の変化とは対照的に、エンド・ユーザによって知覚されることがある。

さらに、増加したリソースがシステムで利用されるときに、システム・パフォーマンスを評価するのに役立てるために、ロギング／追跡／検査（ＬＴＡ：logging/tracking/audit）手順を利用することができる。ＬＴＡ手順は、関連する持続時間のタイミング情報を含むことができる。タイミング情報は、異常イベントの持続期間および追加のリソース処理の持続期間などの、これらの持続期間の開始日および終了日、ならびに時間で構成することができる。ＬＴＡ手順は、異常イベントおよび増加した処理の持続期間についての、このようなタイミング情報をキャプチャすることができる。ＬＴＡ手順は、また、増加した処理の持続期間中に、または増加した処理の様々なステージで提供されたリソースの量、増加した処理の前、中、後のシステム・レスポンス時間、および他の関連データについての情報を含むことができる。関連するパーティション、および、パーティション内またはパーティション外で動く処理についての情報も含むことができる。ＬＴＡデータを見直し、分析することによって、適用すべき範囲のリソースに関する様々なパラメータの調節を可能にすることができる。

マルチ・パーティション・システムでは、２つ以上のパーティションが異常イベントを同時に経験するか、これらのそれぞれの異常イベントの発生が時間内に重複する可能性があり得る。それぞれの第１および第２のパーティションは、これらに対処するために、追加のリソースを同時にまたは重複して適用することによって、恩恵を受けることができる。このような状況では、利用可能なリソースをどのようにアロケートするかを決定することは、上記で説明したような単一のパーティションにリソースを提供する手法（テーブル、公式計算、等）に類似の手法で決定することができる。１つの実施形態では、異常イベントのハンドリングが完了するまで、より高い優先度の異常イベントのパーティションに、全ての（または最大数／量の）利用可能なリソースを与えることができ、この後、全ての利用可能なリソースが、より低い優先度のイベントに与えられる。別の実施形態では、利用可能なリソースは、これらの間で分けることができる。別の実施形態では、発生することになる「第１の異常イベント」は、利用可能なリソースより高い優先度を得るか、場合によっては、後で発生する異常イベントが、より早く発生した異常イベントと同じか、これより低い優先度のものである場合だけ、優先度を得ることができる。

図７は、１つまたは複数の実施形態による、特定のイベント処理中にプロセッサ・コア２２０の処理能力を増加させることについての実例の処理７００の流れ図である。処理７００は、動作７１０において、ＤＰＳ２０２におけるパーティションのセット４０２からのパーティション４１４における異常イベントを監視することを含むことができる。１つまたは複数の例では、ハイパーバイザ３３０またはパーティション・マネージャ３３４は、異常イベントについて、パーティションのパフォーマンスを監視することができる。パーティション４１４における異常イベントは、パーティション４１４の出力レベルを監視することによって検出することができ、ここで、異常イベントは、パーティション４１４が予想レベルの出力を出す能力に悪影響を及ぼす状態である。異常イベントは、パーティション４１４のオペレーティング・システム４３０のＩＰＬをさらに含むことができる。１つまたは複数の例では、オペレーティング・システム４３０は、クラウドまたはハイパースケール環境内にある。

動作７２０において異常イベントが検出されるまで、（動作７２０：いいえ）パーティション４１４は、動作７３０において、割り振られた計算リソース２０６を使用して、動作し続けることができる。割り振られた計算リソース２０６は、パーティション４１４を使用するユーザ／クライアントとのＳＬＡに基づくことができる。これは、パーティション４１４の「定常状態」または「通常動作」と呼ばれ、このとき、パーティションは、ＳＬＡによるデフォルトの計算リソース設定を使用して動作している。

異常イベントが検出された場合（７２０：はい）、パーティション４１４によって使用されている計算リソース２０６を、動作７４０において識別することができる。さらに、動作７５０において、リソース・マネージャ２０３は、コア・スピードを増加させること、非アクティブコア２２０をアクティブ化すること、および上記で論じた他の技法を使用することなどによって、パーティション４１４に割り振られた計算リソース２０６を増加させることで、パーティション４１４の処理能力を増加させることができる。提供される追加の計算リソースは、第１のＤＰＳ２０２、第２のＤＰＳ２０２、または他の任意のＤＰＳ２０２からのものであってもよい。

例えば、追加される追加のリソースは、非アクティブ状態２２１の可能性があるコア２２０をアクティブ状態２２３にすることを含むことができる、パーティション４１４にアロケートされるコア２２２の数を増加させることによって出すことができる追加の処理能力を含むことができる。代替としてまたはさらに、処理能力は、コア２２２あたりの処理能力を増加させることによって増加させることができる。例えば、プロセッサ２２４のハードウェア・エンジンを有効および無効にするために、オン／オフＣｏＤを使用して、プロセッサ２２４の動作を調節することができる。代替としてまたはさらに、処理能力は、仮想化システム上の仮想マシンの優先度を変えることによって増加させることができる。

１つまたは複数の例では、パーティション４１４の追加の処理能力は、入出力デバイス２１８を増加させること、メモリ２１６を増加させること、または、他のこのような計算リソース２０６をパーティション４１４にアロケートすることによって、提供することができる。代替としてまたはさらに、追加の能力は、異常イベントのパフォーマンス・インパクトを部分的または完全に相殺するために、追加の能力を出すことができる別のＤＰＳ２０２に、ライブ・ゲスト・リロケーション技法を使用して、パーティション４１４のオペレーティング・システム・イメージを移すことによって出すことができる。この場合、パーティション４１４が移される他のＤＰＳ２０２は、バックアップＤＰＳ２０２と呼ばれることがある。１つまたは複数の例では、バックアップＤＰＳ２０２のリソース・マネージャ２０３は、１つまたは複数の計算リソース２０６を、第３のＤＰＳ２０２からリロケートされたパーティション４１４にアロケートすることができる。本明細書で説明したように、パーティション４１４にアロケートされる計算リソースは、ＣｏＤまたは他の技法を使用するなどして、動的にさらに構成することができる。

追加の処理能力は、リソース・マネージャ２０３によって提供することができる。１つまたは複数の例では、パーティション４１４は、異常イベントのタイプを示し、これに応じて、処理能力は、本明細書で説明されるような、１つまたは複数の追加の計算リソース２０６を提供することによって増加される。

追加の処理能力が提供されると、動作７６０において、増加した処理能力でパーティションの処理が続く。動作７７０において、異常イベント処理が完了したかどうかについて判定することができる。これは、上記で論じた判断基準のいずれかに基づいて行うことができる。異常イベント処理が完了していない場合（７７０：いいえ）、動作７６０において、増加した処理能力が続く。そうでなければ（７７０：はい）、パーティション４１４の動作についての処理は完了し、動作７８０において、通常の処理能力に動作が復元され、動作７３０において、通常の定常状態でのパーティションの動作が続く。異常イベントを解消することは、異常イベントの完了後に実施される動作を含むことができる。例えば、異常イベントがＩＰＬである場合、追加の計算リソース２０６は、ＩＰＬを定常状態の計算リソースと比較して、パーティション４１４が、短くなった時間でＩＰＬを完了させるのを容易にすることができる。

さらに、１つまたは複数の例では、異常イベントを解消するために、追加の計算リソースがパーティションによって使用される。異常イベントを解消することは、異常イベントの原因を判定することなどのために、１つまたは複数のフォローアップ動作を実施することを含むことができる。例えば、異常イベントが、計画外のシステム・シャットダウンにより引き起こされたＩＰＬである場合、解消は、システム診断、トレース、および他のタイプの分析を実施して、異常イベントの原因を判定することを含むことができる。異常イベントを解消するためのこのような動作も計算負荷が高いことがあるので、リソース・マネージャ２０３は、追加の計算リソースがこのような診断または分析動作を完了させるのを容易にすることができる。

処理７００は、連続的に動作するように設計することができる。パーティション４１４の計算リソースを復元することは、パーティション４１４にアロケートされた追加の計算リソースのアロケートを取り消すことを含むことができる。使用することができる処理７００を説明するために、パーティションの例として、パーティション４１４を上記で説明したが、他の例では、パーティションのセット４０２からの異なるパーティションが、異常イベントに遭遇することがある。

図８は、本明細書で開示した１つまたは複数の実施形態による、特定のイベント処理中にプロセッサ・コアの処理能力を増加させるための別の方法の例の流れ図である。処理８００は、動作８０５において、プロセッサ・ユニットのセット２２４を備える計算リソースの第１のセット、アクティブ状態２２３の第１のコア２２０ａを備えるプロセッサ・ユニットのセット２２４、および当初は非アクティブ状態２２１にある第２のコア２２０ｂを、ＤＰＳ２０２上でホストされるパーティション４１４ａにアロケートすることによって始めることができる。第２のコア２２０ｂは、非アクティブ状態２２１の間、プロセッサ・ユニットのセット２２４内に予め存在するＬＣＣを表すことができる。通常状態または通常動作モードでシステムが動いているとき、動作８１０において、システムは、第１のコア２２０ａで動作するが、第２のコア２２０ｂは動作していない。動作８１５において、異常イベントによって作り出された処理負荷の増加に対処するために、パーティション４１４ａの処理能力を増加すべきであることを示す、ＩＰＬなどの異常イベントの指示を、リソース・マネージャ２０３で判定するか、受け取ることができる。動作８２０において、第２のコア２２０ｂを、非アクティブ状態２２１からアクティブ状態２２３に変化させ、これにより、第１のコア２２０ａと第２のコア２２０ｂ両方を使用して、パーティション４１４ａに処理能力を提供する。

動作８２５において、第２の異常イベントによって作り出された処理負荷の増加に対処するために、第２のパーティション４１４ｂの処理能力を増加すべきであることを示す、ＩＰＬなどの第２の異常イベントの指示を、リソース・マネージャ２０３で判定するか、受け取ることができる。動作８３０において、第２のパーティション４１４ｂと関連付けられた第３のコア２２０ｃを、非アクティブ状態２２１からアクティブ状態２２３に変化させ、これにより、第２のパーティション４１４ｂに追加の処理能力を提供する。動作８３５において、第１のパーティション４１４ａにおいて異常イベントが終わると、または、上記で説明した所定もしくは他の判断基準が発生したとき、第１のパーティション４１４ａにおける第２のコア２２０ｂを、アクティブ状態２２３から非アクティブ状態２２１に変化させることができる。同様に、第２のパーティション４１４ｂにおいて異常イベントが終わると、または、上記で説明した所定もしくは他の判断基準が発生したとき、第１のパーティション４１４ａにおける第３のコア２２０ｃを、アクティブ状態２２３から非アクティブ状態２２１に変化させることができる。

本明細書で論じた１つまたは複数の実施形態は、したがって、異常イベントが検出され、イベントの検出に基づいて追加のリソースが提供されるシステムを提供する。異常イベントは、ＳＬＡまたは他の閾値の通りに予想レベルの出力を出すための、ＤＰＳ、特に、ＤＰＳのパーティションの能力に影響を及ぼす状態である。追加のリソースの適用の持続期間は、イベントの持続期間を超えて延長することができる。例えば、ＩＰＬ（ブート）中に適用される追加のリソースは、ＩＰＬ（ブート）などの異常イベントの後、一定期間、利用可能であり続けてもよい。

１つまたは複数の実施形態によれば、コンピュータ・サーバなどのＤＰＳは、パーティションにおける異常イベントを検出し、これに応じて、このパーティションに追加の計算リソースを提供することができる。出力の所望のレベル、例えばＳＬＡで提供された、１つまたは複数の閾値を含むことができる。

１つまたは複数の例では、検出される異常イベントは、物理ハードウェアまたは仮想ハードウェアのいずれか上でのオペレーティング・システムのＩＰＬ（ブート）である。１つまたは複数の例では、オペレーティング・システムのＩＰＬ（ブート）は、クラウドまたはハイパースケール環境内のものある。

１つまたは複数の例では、追加される追加のリソースは、コアごとに処理能力を増加させることによって（例えば、サブ・キャパシティ・モデルからフル・スピード・モデルへの能力の増加）、または、仮想化システム上の仮想マシンの優先度を変えることによって、あるいはその両方によって、追加のコアを介して出すことができる追加の処理能力である。追加される追加の能力は、パーティション４１４が使用するためにアロケートされる入出力デバイス、メモリ、または他のハードウェア電子回路機器を含むことができる。１つまたは複数の例では、追加される追加の能力は、異常イベントのパフォーマンス・インパクトを部分的にまたは完全に相殺するために、影響を受けたパーティションのオペレーティング・システム・イメージを、追加の能力を出すことができる環境に移すことによって出される。

本明細書で開示した１つまたは複数の実施形態は、したがって、コンピュータ技術に改善をもたらす。例えば、クラウド・コンピューティング・プロバイダは、１つまたは複数の実施形態を使用して、ハイパーバイザの優先度の調整を通じて、仮想化環境内のパーティションにおける仮想マシンで見られるような実際の処理パフォーマンスを増加させることができる。仮想マシンは、様々なワークロードをハンドリングし、仮想マシンをホストするコンピュータ・サーバからだけではなく、コンピュータ・サーバのサーバ・クラスタの一部になることがある別のコンピュータ・サーバからもアロケートすることができる追加の計算リソースをリクエストすることができる。さらに、１つまたは複数の例では、特に、複数のパーティションを伴うＤＰＳについて、第２のパーティションからの計算リソースを、計算リソースの需要が高い方のパーティションにアロケートすることができる。本明細書で説明したように、計算リソースは、コンピュータ・ユーザにとってのダウンタイムの主要な原因になることがある、ブート／ＩＰＬ／回復時間などの、計画的なまたは計画外のあるいはその両方のイベントの検出に応答してアロケートされる。本明細書における１つまたは複数の実施形態は、ブート／ＩＰＬ／回復時間によるこのようなダウンタイム、または他のイベントを短くし、したがって、ＤＰＳのパフォーマンスを改善する。

他の例では、Ｏｒａｃｌｅ Ｅｘａｄａｔａ（登録商標）などのデータベース・サーバは、１つまたは複数の実施形態を使用して、データベース・アプライアンス内でトレースを実行する間、インパクトがない状態で、ワークロードが処理し続けることができる。データベース・サーバは、また、サーバ機能停止後に追加の処理能力を提供し、追加の計算リソースをアロケートして、ワークロードの機能停止を解消することによって、ワークロードの機能停止からクライアントが回復するのを助けることができる。

図の流れ図およびブロック図は、様々な実施形態による、システム、方法、およびコンピュータ・プログラム製品の可能な実装形態のアーキテクチャ、機能、および動作を示す。この点に関して、流れ図またはブロック図の中の各ブロックは、コードのモジュール、セグメント、または一部を表すことができ、指定の論理機能を実行するための１つまたは複数の実行可能命令を含む。

いくつかの代替実装形態では、ブロックに記された機能は、図に記された順序とは異なる順序で発生してもよい。例えば、連続して示された２つのブロックは、実際には、実質的に同時に実行されてもよく、または、ブロックは、時には、含まれる機能に応じて逆の順序で実行されてもよい。ブロック図または流れ図あるいはその両方の各ブロック、および、ブロック図または流れ図あるいはその両方におけるブロックの組合せは、指定の機能もしくは行為を実施する専用ハードウェア・ベースのシステム、または、専用ハードウェアとコンピュータ命令の組合せによって、実行できることにも留意されたい。

本明細書における開示の実施形態は、システム、方法、またはコンピュータ・プログラム製品、あるいはその組合せを含むことができる。コンピュータ・プログラム製品は、本発明の態様をプロセッサに実行させるためのコンピュータ可読プログラム命令を有するコンピュータ可読ストレージ媒体（または複数の媒体）を含むことができる。

コンピュータ可読ストレージ媒体は、命令実行デバイスによる使用のための命令を保持および格納することができる有形デバイスであってもよい。コンピュータ可読ストレージ媒体は、例えば、電子ストレージ・デバイス、磁気ストレージ・デバイス、光ストレージ・デバイス、電磁気ストレージ・デバイス、半導体ストレージ・デバイス、または前述の任意の適切な組合せであってもよいがこれらに限定されない。コンピュータ可読ストレージ媒体のより具体的な例の完全に網羅されていないリストは、ポータブル・コンピュータ・ディスケット、ハードディスク、ＲＡＭ、ＲＯＭ、ＥＰＲＯＭまたはフラッシュ・メモリ、ＳＲＡＭ、ＣＤ－ＲＯＭ、ＤＶＤ、メモリ・スティック（登録商標）、フロッピー（登録商標）・ディスク、命令が記録されたパンチ・カードまたは溝内隆起構造などの機械的にエンコードされたデバイス、および前述の任意の適切な組合せを含む。コンピュータ可読ストレージ媒体は、本明細書で使用されるように、電波もしくは他の自由に伝搬する電磁波、導波路もしくは他の伝送媒体を通じて伝搬する電磁波（例えば、光ファイバ・ケーブルを通過する光パルス）、またはワイヤを通じて伝送される電気信号などの、本質的に一過性の信号であると解釈されるべきではない。

本明細書で説明されるコンピュータ可読プログラム命令は、コンピュータ可読ストレージ媒体からそれぞれの計算／処理デバイスに、あるいは、例えば、インターネット、ローカル・エリア・ネットワーク、広域ネットワーク、もしくはワイヤレス・ネットワーク、またはその組合せといったネットワークを介して外部コンピュータまたは外部ストレージ・デバイスに、ダウンロードすることができる。ネットワークは、銅伝送ケーブル、光伝送ファイバ、ワイヤレス伝送、ルータ、ファイアウォール、スイッチ、ゲートウェイ・コンピュータ、またはエッジ・サーバ、あるいはその組合せを備えることができる。各計算／処理デバイス内のネットワーク・アダプタ・カードまたはネットワーク・インターフェースは、コンピュータ可読プログラム命令をネットワークから受け取り、それぞれの計算／処理デバイス内のコンピュータ可読ストレージ媒体に格納するためにコンピュータ可読プログラム命令を転送する。

本発明の動作を実行するためのコンピュータ可読プログラム命令は、アセンブラ命令、ＩＳＡ命令、機械語命令、機械依存命令、マイクロコード、ファームウェア命令、状態設定データ、または、Ｓｍａｌｌｔａｌｋ（登録商標）、Ｃ＋＋、もしくは同様のものなどのオブジェクト指向プログラミング言語、および、「Ｃ」プログラミング言語、もしくは類似のプログラミング言語などの従来の手続き型プログラミング言語を含む１つもしくは複数のプログラミング言語の任意の組合せで書かれたソース・コードもしくはオブジェクト・コードのいずれかであってもよい。コンピュータ可読プログラム命令は、スタンド・アロンのソフトウェア・パッケージとして、全面的にユーザのコンピュータ上で、または部分的にユーザのコンピュータ上で実行することができ、あるいは、部分的にユーザのコンピュータ上および部分的にリモート・コンピュータ上で、または全面的にリモート・コンピュータもしくはサーバ上で実行することができる。後者のシナリオでは、リモート・コンピュータは、ＬＡＮもしくはＷＡＮを含む任意のタイプのネットワークを通じてユーザのコンピュータに接続することができ、または、接続は、（例えば、ＩＳＰを利用して、インターネットを通じて）外部コンピュータに対して行われてもよい。いくつかの実施形態では、例えば、プログラム可能論理回路機器、ＦＰＧＡ、またはＰＬＡを含む電子回路機器が、本発明の態様を実施するために、コンピュータ可読プログラム命令の状態情報を利用して電子回路機器を個別化にすることによって、コンピュータ可読プログラム命令を実行することができる。

本発明の態様は、本発明の実施形態による方法、装置（システム）、およびコンピュータ・プログラム製品の流れ図またはブロック図あるいはその両方を参照しながら、本明細書で説明される。流れ図またはブロック図あるいはその両方の各ブロック、ならびに流れ図またはブロック図あるいはその両方におけるブロックの組合せは、コンピュータ可読プログラム命令によって実行できることが理解されよう。

これらのコンピュータ可読プログラム命令は、コンピュータまたは他のプログラム可能データ処理装置のプロセッサによって実行する命令が、流れ図またはブロック図あるいはその両方の１つまたは複数のブロックで指定された機能／行為を実行するための手段を作り出すべく、汎用コンピュータ、専用コンピュータ、または他のプログラム可能データ処理装置のプロセッサに提供されてマシンを生み出すものであってよい。これらのコンピュータ可読プログラム命令は、流れ図またはブロック図あるいはその両方の１つまたは複数のブロックで指定された機能／行為の態様を実行する命令を含む製品を、命令を格納したコンピュータ可読ストレージ媒体が備えるべく、コンピュータ可読ストレージ媒体に格納され、コンピュータ、プログラム可能データ処理装置、または他のデバイス、あるいはその組合せに特定の手法で機能するように指示することができるものであってもよい。

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

様々な実施形態の説明を例証のために提示してきたが、網羅的であること、または開示の実施形態に限定することを意図するものではない。説明した実施形態の範囲および思想から逸脱することなく、多くの変更形態および変形形態が当業者には明らかであろう。本明細書で使用される専門用語は、実施形態の原理、実用的用途、もしくは市場で見つかる技術に対する技術的改善を最もよく説明するように、または、本明細書で開示された実施形態を他の当業者が理解できるように、選ばれた。

Claims (25)

1. 異常イベントのために仮想マシンの処理能力を増加させるためのコンピュータ実行方法であって、プロセッサを使用して、
   プロセッサ・ユニットのセットを備える計算リソースの第１のセットを、データ処理システム（ＤＰＳ）内で提供することであって、プロセッサ・ユニットの前記セットが、アクティブ状態の１つまたは複数の第１のコア、および当初は非アクティブ状態の１つまたは複数の第２のコアを備え、前記１つまたは複数の第２のコアが、前記非アクティブ状態の間、プロセッサ・ユニットの前記セット内に予め存在している潜在的なＣＰＵ能力（ＬＣＣ）に相当する、前記提供することと、
   アクティブ状態の前記１つまたは複数の第１のコアを伴うプロセッサ・ユニットの前記セットを備える計算リソースの前記第１のセットを、前記ＤＰＳ上でホストされるパーティションにアロケートすることと、
   前記１つまたは複数の第２のコアがアクティブ化される前、前記１つまたは複数の第１のコアを使用して前記パーティションを動作させることと、
   異常イベントの発生に基づいて、前記ＬＣＣを利用して前記パーティションのために処理能力を増加させることを、リソース・マネージャによって決定することと、
   前記増加の前記決定に応答して、前記非アクティブ状態から前記アクティブ状態に前記１つまたは複数の第２のコアをアクティブ化することと、
   前記１つまたは複数の第２のコアがアクティブ化された後、前記１つまたは複数の第１のコアと前記１つまたは複数の第２のコアの両方を使用して前記パーティションを動作させることと、
   所定の判断基準に応じて、前記アクティブ状態から前記非アクティブ状態に前記１つまたは複数の第２のコアを非アクティブ化することと
   を含む、方法。
2. 前記１つまたは複数の第２のコアが、前記パーティションをホストしている前記ＤＰＳの一部である、請求項１に記載の方法。
3. 前記増加の前記決定が、前記リソース・マネージャによって受け取られた増加リクエストに基づく、請求項１に記載の方法。
4. 前記異常イベントが、前記パーティションで実行するオペレーティング・システム・インスタンスの初期プログラム・ロードである、請求項１に記載の方法。
5. 前記所定の判断基準が、前記異常イベントの完了である、請求項１に記載の方法。
6. 前記所定の判断基準が、前記１つまたは複数の第２のコアをアクティブ化してからの所定の持続期間、およびプロセッサ出力の所定の量の使用のうちの少なくとも１つである、請求項１に記載の方法。
7. 前記異常イベントの所定の負荷要件または検出した負荷要件のうちの少なくとも１つに基づいて、前記パーティションのためにアクティブ化することになる追加の非アクティブコアの数を決定することをさらに含む、請求項１に記載の方法。
8. 前記パーティションについての所定の優先度値、または前記パーティションに関連付けられた履歴データのうちの少なくとも１つに基づいて、前記パーティションのためにアクティブ化することになる前記１つまたは複数の第２のコアの数を、前記リソース・マネージャによって決定することをさらに含む、請求項１に記載の方法。
9. 前記リソース・マネージャが、前記パーティションの作成、終了、および動作を監督するハイパーバイザを含む、請求項８に記載の方法。
10. 前記パーティション内のオペレーティング・システムまたはアプリケーションによって前記異常イベントを検出することをさらに含み、前記増加の前記決定が、前記異常イベントを検出した前記パーティションの前記オペレーティング・システムまたは前記アプリケーションによってリクエストされた増加リクエストに基づく、請求項１に記載の方法。
11. 前記パーティションの作成、終了、および動作を監督するハイパーバイザによって前記異常イベントを検出することをさらに含み、前記増加の決定が、前記ハイパーバイザが前記異常イベントを検出することに基づく、請求項１に記載の方法。
12. 前記１つまたは複数の第２のコアのアクティブ化が前記異常イベントに対処するのに有益であるときをハイパーバイザによって決定することをさらに含む、請求項１に記載の方法。
13. 前記パーティションへの計算リソースの追加と時間内に重複する第２の異常イベントの発生に基づいて、前記ＬＣＣを利用して第２のパーティションのために処理能力を増加させることを、前記リソース・マネージャによって決定することと、
    前記第２のパーティションのための前記増加の前記決定に応答して、ａ）アクティブ化された前記１つもしくは複数の第２のコアによって提供されるリソースを増加させること、またはｂ）前記第２のパーティションに１つもしくは複数の第３のコアをアロケートすること、からなるグループから選択される、前記第２のパーティションにさらなるリソースを提供することと、
    前記１つまたは複数の第３のコアがアクティブ化された後、前記第１のパーティションにおける前記１つもしくは複数の第１のコア、または前記１つもしくは複数の第２のコアのうちの少なくとも１つと時間的に重複する前記第２のパーティションにおける前記１つまたは複数の第３のコアを使用して、前記第２のパーティションを動作させることと、
    第２の所定の判断基準に応じて、ａ）アクティブ化された前記１つもしくは複数の第２のコアによって提供されたリソースを減少させること、またはｂ）前記第２のパーティションからの前記１つもしくは複数の第３のコアのアロケートを取り消すこと、からなるグループから選択される、前記第２のパーティションに以前に提供された前記さらなるリソースを除去することと
    をさらに含む、請求項１に記載の方法。
14. 前記１つまたは複数の第３のコアの前記アロケートが、前記非アクティブ状態から前記アクティブ状態に１つまたは複数の第３のコアをアクティブ化することを含み、
    前記１つまたは複数の第３のコアの前記アロケート取消しが、前記アクティブ状態から前記非アクティブ状態に前記１つまたは複数の第３のコアを非アクティブ化することを含む、請求項１３に記載の方法。
15. 前記１つまたは複数の前記第３のコアの前記アロケートが、前記第１のパーティションから前記第２のパーティションに前記第２のコアのうちの１つまたは複数を部分的または完全に再割当てすることを含み、
    前記１つまたは複数の第３のコアの前記アロケート取消しが、前記第２のパーティションから前記１つまたは複数の第３のコアの再割当てを取り消すことを含む、請求項１３に記載の方法。
16. 異常イベントのために仮想マシンの処理能力を増加させるためのコンピュータ実行方法であって、プロセッサを使用して、
    プロセッサ・ユニットのセットを備える計算リソースの第１のセットを、データ処理システム（ＤＰＳ）内で提供することであって、プロセッサ・ユニットの前記セットが、アクティブ状態の１つまたは複数の第１のコア、および当初は非アクティブ状態の１つまたは複数の第２のコアを備え、前記１つまたは複数の第２のコアが、前記非アクティブ状態の間、プロセッサ・ユニットの前記セット内に予め存在している潜在的なＣＰＵ能力（ＬＣＣ）に相当する、前記提供することと、
    アクティブ状態の前記１つまたは複数の第１のコアを伴うプロセッサ・ユニットの前記セットを備える計算リソースの前記第１のセットを、前記ＤＰＳ上でホストされるパーティションにアロケートすることと、
    前記１つまたは複数の第２のコアがアクティブ化される前、前記１つまたは複数の第１のコアを使用して前記パーティションを動作させることと、
    異常イベントの発生に基づいて、前記ＬＣＣを利用して前記パーティションのために処理能力を増加させることを、リソース・マネージャによって決定することと、
    前記増加の前記決定に応答して、前記非アクティブ状態から前記アクティブ状態に前記１つまたは複数の第２のコアをアクティブ化することと、
    前記１つまたは複数の第２のコアがアクティブ化された後、前記１つまたは複数の第１のコアと前記１つまたは複数の第２のコアの両方を使用して前記パーティションを動作させることと、
    所定の判断基準に応じて、前記アクティブ状態から前記非アクティブ状態に前記１つまたは複数の第２のコアを非アクティブ化することと、
    前記１つまたは複数の第２のコアのアクティブ化および非アクティブ化に関連して、情報のロギング、追跡、または検査のうちの少なくとも１つを実施することと
    を含む、方法。
17. 異常イベントによってトリガされた仮想マシンの増加した処理能力を測定し、レポートするためのコンピュータ実行方法であって、プロセッサを使用して、
    異常イベントの発生によってトリガされた、パーティションのための処理能力の増加のために、追加のリソースが前記パーティションに適用されたと判定することと、
    前記追加のリソースの前記適用の範囲および持続期間を決定することと、
    前記追加のリソースのアクティブ化および非アクティブ化に関連して、情報のロギング、追跡、または検査のうちの少なくとも１つを実施することと
    を含む、方法。
18. 異常イベントのために仮想マシンの処理能力を増加させるためのコンピュータ・システムであって、命令を実行するように構成されたプロセッサを備え、前記命令は、前記プロセッサ上で実行されると、
    プロセッサ・ユニットのセットを備える計算リソースの第１のセットを、データ処理システム（ＤＰＳ）内で提供することであって、プロセッサ・ユニットの前記セットが、アクティブ状態の１つまたは複数の第１のコア、および当初は非アクティブ状態の１つまたは複数の第２のコアを備え、前記１つまたは複数の第２のコアが、前記非アクティブ状態の間、プロセッサ・ユニットの前記セット内に予め存在している潜在的なＣＰＵ能力（ＬＣＣ）に相当する、前記提供することと、
    アクティブ状態の前記１つまたは複数の第１のコアを伴うプロセッサ・ユニットの前記セットを備える計算リソースの前記第１のセットを、前記ＤＰＳ上でホストされるパーティションにアロケートすることと、
    前記１つまたは複数の第２のコアがアクティブ化される前、前記１つまたは複数の第１のコアを使用して前記パーティションを動作させることと、
    異常イベントの発生に基づいて、前記ＬＣＣを利用して前記パーティションのために処理能力を増加させることを、リソース・マネージャによって決定することと、
    前記増加の前記決定に応答して、前記非アクティブ状態から前記アクティブ状態に前記１つまたは複数の第２のコアをアクティブ化することと、
    前記１つまたは複数の第２のコアがアクティブ化された後、前記１つまたは複数の第１のコアと前記１つまたは複数の第２のコアの両方を使用して前記パーティションを動作させることと、
    所定の判断基準に応じて、前記アクティブ状態から前記非アクティブ状態に前記１つまたは複数の第２のコアを非アクティブ化することと
    を前記プロセッサに行わせる、コンピュータ・システム。
19. 前記異常イベントが、前記パーティションで実行するオペレーティング・システム・インスタンスの初期プログラム・ロードであり、
    前記所定のイベントが、前記異常イベントの完了、前記第２のコアをアクティブ化してからの所定の持続期間、およびプロセッサ出力の所定の量の使用のうちの少なくとも１つであり、
    前記リソース・マネージャが、前記パーティションの作成、終了、および動作を監督するハイパーバイザを含み、
    前記命令が、前記第２のコアのアクティブ化が前記異常イベントに対処するのに有益であるときを、前記ハイパーバイザによって決定することを前記プロセッサにさらに行わせる、
    請求項１８に記載のシステム。
20. 前記命令が、前記第２のコアのアクティブ化および非アクティブ化に関連した情報のロギング、追跡、または検査のうちの少なくとも１つを実施することを前記プロセッサにさらに行わせる、請求項１９に記載のシステム。
21. コンピュータ・プログラム製品であって、コンピュータ可読プログラム・コードが具現化されたコンピュータ可読ストレージ媒体を備え、前記コンピュータ可読プログラム・コードは、プロセッサ上で実行されると、
    プロセッサ・ユニットのセットを備える計算リソースの第１のセットを、データ処理システム（ＤＰＳ）上でホストされるパーティションにアロケートすることであって、プロセッサ・ユニットの前記セットが、アクティブ状態の第１のコア、および当初は非アクティブ状態の第２のコアを備え、前記第２のコアが、前記非アクティブ状態の間、プロセッサ・ユニットの前記セット内に予め存在している潜在的なＣＰＵ能力（ＬＣＣ）に相当する、前記アロケートすることと、
    前記第２のコアがアクティブ化される前、前記第１のコアを使用して前記パーティションを動作させることと、
    異常イベントの発生に基づいて、前記ＬＣＣを利用して前記パーティションのために処理能力を増加させるために、増加リクエストをリソース・マネージャによって受け取ることと、
    前記増加リクエストに応答して、前記非アクティブ状態から前記アクティブ状態に前記第２のコアをアクティブ化することと、
    前記第２のコアがアクティブ化された後、前記第１のコアと前記第２のコアの両方を使用して前記パーティションを動作させることと、
    所定の判断基準に応じて、前記アクティブ状態から前記非アクティブ状態に前記第２のコアを非アクティブ化することと
    を行う、コンピュータ・プログラム製品。
22. 具現化された前記プログラム・コードが、前記第２のコアのアクティブ化が前記異常イベントに対処するのに有益であるときをハイパーバイザによって決定するようにさらに構成される、請求項２１に記載のコンピュータ・プログラム製品。
23. 具現化された前記プログラム・コードが、
    異常イベントの発生に基づいて、前記ＬＣＣを利用して前記パーティションのために処理能力を増加させるための増加リクエストを、リソース・マネージャによって受け取ることと、
    前記増加リクエストに応答して、前記非アクティブ状態から前記アクティブ状態に前記第２のコアをアクティブ化することと、
    前記パーティションにおける前記異常イベントと時間内に重複する第２の異常イベントの発生に基づいて、前記ＬＣＣを利用して第２のパーティションのために処理能力を増加させるための第２の増加リクエストを、前記リソース・マネージャによって受け取ることと、
    前記第２の増加リクエストに応答して、前記非アクティブ状態から前記アクティブ状態に第３のコアをアクティブ化することと、
    前記第３のコアがアクティブ化された後、前記第１のパーティションにおける前記第２のコアと時間的に重複する前記第２のパーティションにおける前記第３のコアを使用して、前記第２のパーティションを動作させることと、
    第２の所定の判断基準に応じて、前記アクティブ状態から前記非アクティブ状態に前記第３のコアを非アクティブ化することと
    を行うようにさらに構成される、請求項２１に記載のコンピュータ・プログラム製品。
24. 前記異常イベントが、前記パーティションで実行するオペレーティング・システム・インスタンスの初期プログラム・ロードであり、
    前記所定の判断基準が、前記異常イベントの完了、前記第２のコアをアクティブ化してからの所定の持続期間、およびプロセッサ出力の所定の量の使用のうちの少なくとも１つであり、
    前記リソース・マネージャが、前記パーティションの作成、終了、および動作を監督するハイパーバイザを含み、
    具現化された前記プログラム・コードが、前記第２のコアのアクティブ化が前記異常イベントに対処するのに有益であるときを、ハイパーバイザによって決定することをさらに含む、
    請求項２３に記載のコンピュータ・プログラム製品。
25. 具現化された前記プログラム・コードが、
    前記パーティションの作成、終了、および動作を監督するハイパーバイザによって前記異常イベントを検出するようにさらに構成され、前記増加リクエストが、前記ハイパーバイザが前記異常イベントを検出することに応答するものである、
    請求項２４に記載のコンピュータ・プログラム製品。

Images