(57)【特許請求の範囲】
【請求項１】
適当なコンピューティング装置上のプログラムとして実施される、資源キャパシティ計画システムの機能及び作業負荷管理システムの機能を統合するためのシステムであって、
複数の作業負荷の実行、資源タイプ、数、及びキャパシティに関するデータを前記資源キャパシティ計画システムから受信して、１つ又は２つ以上の考え得る資源構成の選択肢を生成する、シミュレーションモジュールと、
該１つ又は２つ以上の考え得る資源構成の選択肢を該シミュレーションモジュールから受信し、及び１つ又は２つ以上の特定の基準を前記作業負荷管理システムから受信し、該１つ又は２つ以上の考え得る資源構成の選択肢及び該１つ又は２つ以上の特定の基準に基づいて、前記複数の作業負荷間での１つ又は２つ以上の計画された資源割り当ての選択肢を作成する、モデル化モジュールとを備えており、
前記資源キャパシティ計画システムが、前記モデル化モジュールから前記１つ又は２つ以上の計画された資源割り当ての選択肢を受信し、及び該１つ又は２つ以上の計画された資源割り当ての選択肢をユーザによる再検討のために提示する、
資源キャパシティ計画システムの機能及び作業負荷管理システムの機能を統合するためのシステム。
【請求項２】
前記１つ又は２つ以上の計画された資源割り当ての選択肢を前記モデル化モジュールから受信し、及び該１つ又は２つ以上の計画された資源割り当ての選択肢を特定の基準に従って評価する、評価モジュールを更に備えており、前記資源キャパシティ計画システムが、前記１つ又は２つ以上の計画された資源割り当ての選択肢とその評価結果とを該評価モジュールから受信して、該１つ又は２つ以上の計画された資源割り当ての選択肢とその評価結果とをユーザによる再検討のために提示する、請求項１に記載のシステム。
【請求項３】
前記１つ又は２つ以上の特定の基準が、サービスレベル目標、性能評価基準、及び作業負荷−資源割り当てポリシーを含む、請求項１又は請求項２に記載のシステム。
【請求項４】
前記資源が、完全に認可された資源及びインスタントキャパシティ資源である、請求項１ないし請求項３の何れか一項に記載のシステム。
【請求項５】
前記モデル化モジュールが、前記１つ又は２つ以上の計画された資源割り当て計画の選択肢の各々毎に資源コストを計算する、請求項１ないし請求項４の何れか一項に記載のシステム。
【請求項６】
前記評価モジュールが、
更なる資源構成の選択肢を作成することを前記シミュレーションモジュールに指示する手段と、
前記１つ又は２つ以上の計画された資源割り当ての選択肢のうちの１つ又は２つ以上が前記特定の基準に達さなかったときをユーザに知らせる手段と、
ポリシー設定を変更して、該変更の前記１つ又は２つ以上の計画された資源割り当ての選択肢に対する影響を評価する手段と
を含む、請求項２及び請求項２を直接的又は間接的に引用する請求項３ないし請求項５の何れか一項に記載のシステム。
【請求項７】
前記１つ又は２つ以上の資源割り当ての選択肢が、時間と共に変動する、請求項１ないし請求項６の何れか一項に記載のシステム。
【請求項８】
適当にプログラミングされたコンピューティング装置上で実施される、キャパシティ計画システムの機能及び作業負荷管理システムの機能を統合するための方法であって、
複数の作業負荷の実行による資源の使用に関する履歴データ及びシミュレートされたデータの１つ又は２つ以上を前記キャパシティ計画システム及び／又は前記作業負荷管理システムから受信し、
該受信した履歴データ及びシミュレートされたデータの１つ又は２つ以上に基づいて考え得る資源需要構成を計算し、
該考え得る資源需要構成を前記作業負荷管理システムへ送信し、
該作業負荷管理システムにおいて該考え得る資源需要構成に基づいて前記複数の作業負荷間での１つ又は２つ以上の資源割り当ての選択肢を作成し、
該１つ又は２つ以上の資源割り当ての選択肢をユーザに対する表示のために前記キャパシティ計画システムへ送信する、
という各ステップを含む、キャパシティ計画システムの機能及び作業負荷管理システムの機能を統合するための方法。
【請求項９】
前記１つ又は２つ以上の資源割り当ての選択肢を特定の基準に従って評価し、
その評価結果を前記ユーザに対する表示のために前記キャパシティ計画システムへ送信する、
という各ステップを更に含む、請求項８に記載の方法。
【請求項１０】
前記作業負荷管理システムの１つの設定ファイルから、前記複数の作業負荷に関するポリシー、性能評価基準、及びサービスレベル目標を抽出し、
その抽出結果を使用して前記複数の作業負荷間での前記１つ又は２つ以上の資源割り当ての選択肢を作成する、
という各ステップを更に含む、請求項８又は請求項９に記載の方法。
【請求項１１】
前記１つ又は２つ以上の資源割り当ての選択肢が時間と共に変動する、請求項８ないし請求項１０の何れか一項に記載の方法。
【請求項１２】
前記考え得る資源需要構成の何れかがインスタントキャパシティ資源を含むか否かを判定し、この際に該インスタントキャパシティ資源に関するコストが計算され、
該コストをユーザに対する表示のために前記キャパシティ計画システムへ送信する、
という各ステップを更に含む、請求項８ないし請求項１１の何れか一項に記載の方法。
【請求項１３】
適当にプログラミングされた装置上で実施される、コンピュータシステムにおけるキャパシティ計画システムの機能及び作業負荷管理システムの機能を統合するためのアーキテクチャであって、
複数の作業負荷の実行、資源タイプ、数、及びキャパシティに関するデータを前記キャパシティ計画システムから受信する手段と、
該受信したデータに基づいて１つ又は２つ以上の考え得る資源構成の選択肢を生成するための手段と、
該１つ又は２つ以上の考え得る資源構成の選択肢と前記作業負荷管理システムから受信した１つ又は２つ以上の特定の基準とに基づいて、前記複数の作業負荷間での１つ又は２つ以上の計画された資源割り当ての選択肢を作成するための手段と、
前記１つ又は２つ以上の計画された資源割り当ての選択肢をユーザに伝える手段と
を含む、コンピュータシステムにおけるキャパシティ計画システムの機能及び作業負荷管理システムの機能を統合するためのアーキテクチャ。
【請求項１４】
特定の基準に従って前記１つ又は２つ以上の計画された資源割り当ての選択肢を評価するための手段を更に備えており、
前記１つ又は２つ以上の計画された資源割り当ての選択肢をユーザに伝える前記手段が、前記評価の結果を前記ユーザに伝えるための手段を更に備えている、
請求項１３に記載のアーキテクチャ。
【請求項１５】
前記１つ又は２つ以上の特定の基準が、サービスレベル目標、性能評価基準、及び作業負荷−資源割り当てポリシーを含む、請求項１３又は請求項１４に記載のアーキテクチャ。
【請求項１６】
前記資源が、完全に認可された資源である、請求項１３ないし請求項１５の何れか一項に記載のアーキテクチャ。
【請求項１７】
前記資源が、オンデマンドのインスタントキャパシティ資源を含む、請求項１３ないし請求項１５の何れか一項に記載のアーキテクチャ。
【請求項１８】
前記１つ又は２つ以上の計画された資源割り当ての選択肢を作成するための前記手段が、前記１つ又は２つ以上の計画された資源割り当ての選択肢の各々毎に資源コストを計算する手段を含む、請求項１７に記載のアーキテクチャ。
【請求項１９】
前記１つ又は２つ以上の計画された資源割り当ての選択肢が時間と共に変動する、請求項１３ないし請求項１８の何れか一項に記載のアーキテクチャ。
【請求項２０】
前記サービスレベル目標、性能評価基準、及び作業負荷−資源割り当てポリシーが、前記作業負荷管理システムの設定ファイル内に格納される、請求項１５及び請求項１５を直接的又は間接的に引用する請求項１６ないし請求項１９の何れか一項に記載のアーキテクチャ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータ資源のキャパシティ計画及び作業負荷管理に関するものである。
【背景技術】
【０００２】
コンピュータシステムは、プロセッサ等の複数の資源を用いて、該コンピュータシステム上で実行している１つ又は２つ以上の作業負荷を支援することが可能である。これらの資源の割り当て及び動作を監視し制御するために該コンピュータシステムにキャパシティ計画システム及び作業負荷管理システムをインストールすることが可能である。作業負荷管理システムは、コンピュータシステム上で実行している複数の作業負荷が特定の性能目標を達成するように資源の割り当て及び再割り当てを行うことが可能である。キャパシティ計画システムは、作業負荷の実行を支援する資源の最初の取得計画及びそれ以降の取得計画のために使用することが可能なものである。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
現在のコンピュータシステムでは、作業負荷管理システム及びキャパシティ計画システムは統合されておらす、この統合の欠如は、コンピュータシステムの全体的な効率的動作を本質的に失わせるものである。
【課題を解決するための手段】
【０００４】
資源のキャパシティ計画及び作業負荷管理を統合するためのシステムであって、該システムは、適当なコンピューティング装置上のプログラムとして実施され、作業負荷の実行に関するデータ、資源のタイプ、個数、及びキャパシティを受信して１つ又は２つ以上の考え得る資源構成の選択肢を生成するシミュレーションモジュール、該資源構成の選択肢を受信し１つ又は２つ以上の特定の基準に基づいて複数の作業負荷間における１つ又は２つ以上の計画された資源割り当てを決定するモデル化モジュール、及び該計画された資源割り当てを受信して該計画された資源割り当てをユーザによる再検討のために提示する通信モジュールを含む。
【図面の簡単な説明】
【０００５】
【図１Ａ】作業負荷管理システム及びキャパシティ計画システムが実施された現在のコンピュータシステムを示している。
【図１Ｂ】作業負荷管理機能及びキャパシティ計画機能を結合させるよう統合化アーキテクチャが実施されたコンピュータシステムを示している。
【図２】キャパシティ計画システム及び作業負荷管理システムの機能を統合させるための統合化アーキテクチャの例示的なブロック図である。
【図３】代替的な統合化アーキテクチャの例示的なブロック図である。
【図４Ａ】図２及び図３の統合化アーキテクチャの例示的な動作を示すフローチャートである。
【図４Ｂ】図２及び図３の統合化アーキテクチャの例示的な動作を示すフローチャートである。
【発明を実施するための形態】
【０００６】
以下で参照する図面において、同様の符号は同様の対象物を示している。
【０００７】
作業負荷管理は、計算作業負荷の動作を監視し、及び作業負荷が特定の性能目標を確実に満たすように利用可能な資源を必要に応じて割り当てることにより、機能する。作業負荷管理は典型的には、作業負荷管理システム（WLMS）の制御下で行われる。
【０００８】
WLMSは、１つ又は２つ以上のポリシーに従って動作することが可能である。例えば、ユーザは、作業負荷Aが月曜日から金曜日の午前８時から午後５時の間に実行された場合に該作業負荷Aがそれが必要とする資源の100％を受容することになるというポリシーを設定することが可能である。このポリシーを満足させるために、WLMSは、他の実行中の作業負荷から資源を移すことが可能であり、又は暫定的な資源を稼働させることが可能である。
【０００９】
理想的な状況では、WLMSにより決定される資源の移動は瞬間的に行われることになる。しかし、如何なるコンピュータシステムにおいても、資源の移動には時間がかかり、場合によっては長時間を要し、これは遅延を意味し、これはコンピュータ時間という観点からすれば大きなものであり、かかる遅延は、現行のWLMSの動作の非効率性の一因となる。
【００１０】
キャパシティ計画とは、コンピュータシステムで特定の作業負荷を支援するのにどのぐらいの量の機器（例えば、複数のCPU等の資源）が必要であるかを判定するプロセスを意味する。このため、キャパシティ計画は、１）どの作業負荷が様々な資源を効率的に共用することが可能であるか、及び２）作業負荷の今後の資源要求を満たすための資源のサイズ（すなわち、資源の個数）及びその構成（例えば、全権（full-rights）を有する資源、暫定キャパシティ資源）を予測しようとする。キャパシティ計画は典型的には、キャパシティ計画システム（CPS）の制御下で行われる。CPSは、（典型的には現在構成されているコンピュータシステムの動作に関する履歴データを収集することにより）キャパシティ計画プロセスを支援するツールを含むことが可能である。現在構成されているコンピュータシステム上で実行されている特定の作業負荷による今後の影響に関する情報をCPSが提供することができるように、前記収集された履歴データが次いで将来に投影される。コンピュータシステムの管理者は、CPSにより提供された情報を使用して、コンピュータシステムの資源プールの将来的なサイズ及び性質を如何なるものとすべきか及びコンピュータシステム内に特定の資源を如何に配置すべきかを判断することができる。
【００１１】
現在のコンピュータシステムでは、CPSは、WLMSが作業負荷の資源消費を管理することになるという事実を実際に全く考慮することなく、その指定された機能を実行する。更に詳細には、現在のCPSは、よくても、WLMSの動作に関する仮定に類似し又はそれを単純化したものである。この極めて複雑な事象の単純化は、WLMSにより作業負荷が資源に実際に割り当てられる場合に不精確なキャパシティ計画をもたらすものとなる。更に、現在のCPSは、WLMSが使用されていることに「気付く」ことすらない可能性がある。例えば、現在のCPSは、仮想パーティションが実際には動的な変化を受ける場合であっても、該仮想パーティションが単一の固定サイズを有するものであると見なす場合がある。この固定サイズの仮定の結果として、CPSは仮想パーティションを大きくしすぎる。これは、仮想パーティションが変化する可能性についてCPSが責務を負うことができないからである。このため、CPSは、実際の資源管理に関する知識の欠如の責務を負うべく必要となる資源キャパシティを膨張させ、又はCPSは、該CPSのキャパシティ計画が要求する資源割り当ての効率をWLMSが実際には達成することができないため、必要とされる資源キャパシティを過小評価することになり、それらが故に、CPSにより実行されるキャパシティ計画は不精確なものとなる。
【００１２】
図１Ａは、キャパシティ計画システム（CPS）300及び作業負荷管理システム（WLMS）200を実施する典型的なコンピュータシステム10を示している。該コンピュータシステム10は、ハードパーティション20及び仮想パーティション30の両方を含むことが可能である。該コンピュータシステム10上で１つ又は２つ以上の作業負荷（WL）40が実行され、該作業負荷40は、完全に認可された（fully-licensed）資源50により、及び一実施形態ではインスタントキャパシティ資源60により、支援される。
【００１３】
現在の構成では、WLMS 200は、作業負荷に対する共用資源の割り当てを含む多数の資源監視及び制御機能を実行する。これらの共用資源は、コンピュータシステム10により使用されるプロセッサ、メモリ、帯域幅、及び記憶容量を含む。WLMS 200は、データベース240に格納されている設定ファイル220に従って設定することが可能なアービタ（調停手段）210を含み、該アービタは共用資源を割り当てるために使用することが可能である。代替的に、資源の割り当ては、コンピュータシステム10内の各パーティション20/30毎に個々の作業負荷管理（WLM）インスタンスを実施することにより、個々のパーティション内で分配することが可能である。
【００１４】
資源の割り当ては、各作業負荷毎の所定のサービスレベル目標（SLO）、他の性能評価基準、個々に又はグループ毎に作業負荷について定義されたポリシー、及び作業負荷について定義された資源プールに基づいて行うことが可能である。これらの定義品質は通常はコンピュータシステム管理者により明示的に行われるが、かかる明示的な定義が存在しない場合には、アービタ210は、設定ファイル220の一部として設定されたユーザデフォルト設定を使用することが可能である。
【００１５】
WLMS 200はまた監視モジュール230を含み、該監視モジュール230は作業負荷の実行及び資源の消費を監視するために使用される。該監視モジュール230は、その指定された監視機能を実行するための特定のツールを含み、該ツールには、作業負荷に資源を割り当てるための割り当てツール、作業負荷性能（SLO状態、性能評価基準、及び資源使用量を含む）を監視するための監視ツール、及びコンピュータシステム10上の設定ファイル220を含む作業負荷管理設定に対する変更を可能にするための再検討ツールが含まれる。
【００１６】
図１Ａから分かるように、現行のコンピュータシステムは、CPS機能及びWLMS機能を統合するための機構を提供しないものである。簡単に言えば、現在のコンピュータシステムの場合、該コンピュータシステムの管理者は、CPSを使用して（典型的には履歴データを使用して）資源の需要を推定し、該推定に従って資源を取得する。管理者は次いでWLMSをインストールしてコンピュータシステムを動作させ、該WLMSが、取得した資源を実行中の作業負荷へ割り当てる。しかし、WLMS及びCPSが通信機構を有さないため、WLMSによる割り当てがキャパシティ計画プロセスで考慮されることはない。一例として、CPSは、WLMSの動作の結果として１つの作業負荷から別の作業負荷へ資源が移動することにより課せられる遅延を考慮に入れない。現在のシステムでは、作業負荷の実行の「定常状態」条件のみが利用可能となる。実際に、１つの作業負荷の需要が増大し、他の作業負荷の需要が、資源の需要が資源のキャパシティと等しい第１の定常状態条件から資源の需要が資源のキャパシティと等しい第２の定常状態条件へと減少する際に、全体的な資源需要が利用可能な資源を超過する可能性がある。このため、資源の実際の割り当ては、それら資源の理論的に最適な割り当てに遠く及ばないことが多い。
【００１７】
現在のキャパシティ計画システム及び作業負荷管理システムにおける制限を克服すべく、及び資源計画を資源需要に一層近いものとすべく、本書で説明し図１Ｂの単純化したブロック図に示すものは、キャパシティ計画と作業負荷管理を結合させるようCPS及びWLMSを統合するアーキテクチャ100である。該統合アーキテクチャ100は、WLMS 200及びCPS 300と共に、単一のプラットフォーム又はコンピュータシステム上にインストールすることが可能である。代替的に、アーキテクチャ100、WLMS 200、及び／又はCPS 300は、別個のマシンにインストールすることが可能であり、及び２つ以上のコンピューティングプラットフォームで実行されている作業負荷の制御に使用することが可能である。該統合アーキテクチャ100は、既存のWLMS、CPS、又はCPS及びWLMSの両方を修正したものとして実施することが可能である。例えば、例示的な実施形態では、CPSがWLMSへの接続を確立することを可能にするように、該WLMSを修正することが可能である。この接続により、CPSを使用するキャパシティ計画者は、以下の機能及び能力を得ることができる：１）管理すべく入手可能なポリシー、資源、及び作業負荷に関する情報を取得すること、２）更なるポリシー及び「仮想的な」資源コンテナ及び作業負荷を設定すること、３）既存の及び／又はキャパシティ計画者が作成したポリシー、資源コンテナ、及び作業負荷を参照する共用資源領域の定義を提供すること、並びに、４）該定義された共用資源領域内の作業負荷／資源コンテナのためのサンプル動作パラメータを提供すること、及びあたかもWLMSがかかる領域を管理しており及び提供されたサンプル値を実際に測定していたかのように、所与のサンプル動作パラメータについての該領域の期待される作業負荷管理結果を取得すること。このため、本書で開示する統合アーキテクチャ100は、CPSが、該CPSにより決定された作業負荷の実行のための計画された資源需要をWLMSへ渡すことを可能にし、これにより、WLMSは、作業負荷を管理する態様を該作業負荷の実際の実行に先立って決定することが可能となる。
【００１８】
上述のように、CPSは一般に履歴データで機能し、及び本書で開示する統合アーキテクチャ100は、かかる履歴データを用いてCPSと共に動作することが可能である。しかし、一実施形態では、該統合アーキテクチャは、シミュレーションプロセスを含むことが可能であり、この場合には、CPSは、履歴データに依存する代わりに、コンピュータシステム上での作業負荷の実行のシミュレーションに基づいて、その資源計画機能を開始する。このため、コンピュータシステム管理者は、例えば、１週間という期間にわたる様々な時刻での作業負荷A-Dの実行を１つのモデルとして指定することが可能であり、キャパシティ計画システムは、該モデル化された作業負荷A-Dについての考え得る作業負荷特性を判定することになる。シミュレートされた作業負荷データは次いでWLMSへ渡され、該WLMSが、作業負荷A-DがそれらのSLO、他の決定された性能評価基準、又は管理者が決定したポリシーを満たすように、資源の実際の割り当て及び作業負荷の管理を如何に行うかのシミュレーションを提供することになる。このシミュレーション機能を促進させるために、統合アーキテクチャ100は、監視モジュールとの別個の接続231を含むことが可能である。このため、監視モジュールは、キャパシティ計画の改善のために使用されるシミュレートされたデータ、及び接続を監視する通常のデータという２つの入力を受信する。
【００１９】
更に別の代替例では、CPSは、履歴データ及びモデル化の組み合わせを使用して、WLMSが関連する作業負荷を如何に管理することになるかを予測できるように、該WLMSへシミュレートされた作業負荷の分配を提供することが可能である。
【００２０】
図２は、統合アーキテクチャ100の例示的なブロック図である。該統合アーキテクチャ100は、WLMS 200及びCPS 300とそれぞれ通信するための通信モジュール110,120を含む。該アーキテクチャ100は更に、シミュレーションモジュール130（一実施形態ではCPS 300に対して追加又は修正を行ったものとして構成される）、それに対応するモデル化モジュール140（一実施形態では、WLMS 200に対して追加又は修正を行ったものとして実施される）、及び評価モジュール160を含む。
【００２１】
シミュレーションモジュール130は、CPS 300の他の構成要素からの入力を受信する。例えば、システム管理者は、インタフェイス310を使用してシミュレーションモジュール130と対話して、予測又はその他のシミュレートされた作業負荷情報（作業負荷の識別及びタイプ、作業負荷の実行日時、作業負荷の一意の特性又は需要、SLO、性能評価基準、及び作業負荷に関する資源需要をモデル化するのに必要な他の情報を含む）を入力することが可能である。また、シミュレーションモジュール130は、任意数の作業負荷（同じプラットフォームで、同じパーティション内で、及び同じ日時に実行することが予想される作業負荷を含む）について作業負荷情報を受信することが可能である、ということに留意されたい。シミュレーションモジュール130はまた、作業負荷の実行及びそれに対応するWLMS 200からの資源の割り当てに関する履歴データを通信モジュール110,120を介して受信することが可能である。最後に、シミュレーションモジュール130は、作業負荷実行及び資源割り当て履歴データをCPS 300から受信することが可能である。実際の作業負荷実行及び資源割り当て履歴データ又はシミュレートされた作業負荷実行及び資源割り当てデータ、又はそれらのデータの任意の組み合わせを用いて、シミュレーションモジュール130は、かかる特定の作業負荷実行データのための計画された資源割り当てを決定する。シミュレーションモジュール130は、該計画された資源割り当て及び作業負荷実行データをモデル化モジュール140へ送る。
【００２２】
モデル化モジュール140は、シミュレーションモジュール130からの入力、並びに、設定ファイル220に記述されたSLO、性能評価基準、及びポリシーを受信する。モデル化モジュール140は、該入力を使用して資源割り当て計画を決定する。次いで該資源計画がCPS 300及びフィードバックモジュール320へ返される。該フィードバックモジュール320は、受信したデータをコンピュータシステム管理者へ表示すべくフォーマットし、該表示可能データをインタフェイス310へ送り、該データを表示装置上で見ること又はプリントすることが可能となる。フィードバックモジュール320はまた、受信したデータを格納すべくフォーマットし、該フォーマットされたデータを短期又は長期記憶のためにデータベース330へ送ることが可能である。
【００２３】
評価モジュール160は、シミュレーションモジュール130及び通信モジュール120に接続されており、及びモデル化モジュール140により作成された計画された資源割り当て構成の選択肢を受信する。評価モジュール160は、統合アーキテクチャ100のWLMS部分から返された構成の選択肢を分析して該構成の選択肢を望ましさに関して分類するために使用される評価アルゴリズムを含む。該評価の選択肢は、コンピュータシステム管理者により設定された様々なルール及びポリシーに従うものとすることが可能である。例えば、コンピュータシステム管理者は、80％を越える資源割り当てを必要とするあらゆる組み合わされた作業負荷による共用が低い望ましさを有すること及び90％を越える資源割り当てが禁止されることを設定することが可能である。次いで該評価プロセスの結果が、フィードバックモジュール320及びインタフェイス310を使用してコンピュータシステム管理者に対して提示すべくフォーマットされる。統合アーキテクチャ100のWLMS部分から返された構成の選択肢が所定のしきい値又は性能目標を全く満たさない場合には、評価モジュール160は、代替的な資源割り当ての選択肢を考慮すべきことを判定することが可能である。次いで、この更なる判定ステップの結果として、コンピュータシステム管理者に対して警告を提示することが可能であり、又は他の資源評価の選択肢を確立するようシミュレーションモジュール130に指示し、次いで該シミュレーションモジュール130がモデル化モジュール140と通信して、統合アーキテクチャ100のWLMS部分においてモデル化することが可能である。
【００２４】
評価モジュール160はまた、CPS 300の他の要素と連携して使用して、WLMS 200による実際の作業負荷の管理に使用されるべきポリシー設定の決定を可能とすることが可能である。更に詳細には、評価モジュール160は、シミュレーションモジュール130と協働して、同じ組又はグループの作業負荷のためのポリシー設定を変更することが可能であり、この場合には、評価モジュール160が、モデル化モジュール140による後続のモデル化の結果を評価し、望ましさの順位に基づいて、コンピュータシステム管理者に推奨すべき１組又は２組以上のポリシーパラメータを選択する。
【００２５】
上記で開示した統合アーキテクチャ100はまた、全使用権資源（すなわち、コンピュータシステム管理者が全権を有する資源）及び制限使用権資源（例えば、インスタントキャパシティ（iCAP）及び暫定インスタントキャパシティ（TiCAP）資源（以下、インスタントキャパシティ資源））を含む、あらゆるタイプの資源について使用することが可能である。複数の作業負荷間で資源の割り当て及び再割り当てを行うための１つの方法は、インスタントキャパシティ資源及びそれに関連するインスタントキャパシティソフトウェアの使用を伴うものである。インスタントキャパシティ資源は、必要な使用権又は利用可能な許可を越えて１つ又は２つ以上のコンピュータシステムパーティションにインストールされたコンピュータ資源（プロセッサ、メモリ）から構成される。インスタントキャパシティソフトウェアは、異なるパーティションにおける資源需要を満たすよう必要に応じてインスタントキャパシティ資源を選択的に活動状態、非活動状態、及び再活動状態にすることが可能となるように、利用可能な使用権を移動し又は再割り当てする能力を提供するものである。インスタントキャパシティソフトウェアの動作は、全てのパーティションの許可状態の精確な記録の維持、実際のインスタントキャパシティ資源の活動化がインスタントキャパシティ許可要件に準拠することの確実化、及び異なるパーティション間でのインスタントキャパシティ資源の再割り当ての調整及び同期化を伴うものである。インスタントキャパシティ資源の設定状態は、以下ではインスタントキャパシティ持続状態と称することとする。インスタントキャパシティシステムを実施したコンピュータシステムは、活動化すべきインスタントキャパシティ資源の個数がコンピュータシステム管理者が出費したものと一致する限り、インスタントキャパシティ許可要件に準拠しているものと見なされる。
【００２６】
インスタントキャパシティソフトウェアのこれらの動作要件の結果として、インスタントキャパシティ資源の割り当て／再割り当ては時間のかかるものとなり得る。新しい資源割り当てが行われると、低優先順位の作業負荷から高優先順位の作業負荷へと資源を移す際の遅延は、作業負荷管理の効率及びコンピュータシステムの動作効率を悪化させるものとなる。
【００２７】
例えば、作業負荷管理システムが、多数の作業負荷を監視しており、及び第２の作業負荷ではなく第１の作業負荷によりインスタントキャパシティプロセッサを使用する必要があると判定した場合、作業負荷管理システムは、該作業負荷に関与するインスタントキャパシティソフトウェアと通信して、該インスタントキャパシティソフトウェアが該インスタントキャパシティプロセッサをオフにすることを要求することが可能である。次いでインスタントキャパシティソフトウェアは該非活動化要求を実行する。次に、作業負荷管理システムは、第２の作業負荷に関与するインスタントキャパシティソフトウェアが以前に非活動化させたプロセッサを活動化させることを要求する。インスタントキャパシティソフトウェアは次いで、該プロセッサを再活動化させて、該プロセッサが第２の作業負荷の実行を支援するようにする。
【００２８】
図３は、コンピュータシステム上で実行されている作業負荷に対するインスタントキャパシティ資源の割り当てを責務とする代替的な統合アーキテクチャ400の例示的なブロック図である。前記アーキテクチャ100の構成要素に加えて、該統合アーキテクチャ400は、シミュレーションモジュール130の場合と類似した情報を提供するために使用されるインスタントキャパシティモジュール410を含む。
【００２９】
別個のインスタントキャパシティ制御システム（図示せず）が、任意に実施されたインスタントキャパシティ体制（regime）で、コンピュータシステム10の準拠状態の監視の責務を負うことが可能である。このため、例えば、コンピュータシステム10には、８つのインスタントキャパシティプロセッサがインストールされていることが可能であるが、実施された体制は、一度に５つ以上のインスタントキャパシティプロセッサを活動化させないことを必要とすることが可能である。該インスタントキャパシティ制御システムは、この要件にアクセスし、コンピュータシステム10の動作を監視して、該要件との準拠を判定し、及び説明責任のためにインスタントキャパシティプロセッサの実際の使用を記録する。
【００３０】
インスタントキャパシティシミュレーションモジュール410は、コンピュータシステム管理者からの入力を受信し、該入力は、完全に認可されたiCAP及びTiCAP資源の様々な許可された組み合わせ、及びかかる様々な資源の固有の又は管理者により割り当てられたコストを含む。コンピュータシステム管理者はまた、インスタントキャパシティ資源の使用に関するポリシー、並びに完全に認可された資源のために規定されるポリシーを提供する。最後に、該モジュール410は、予想される資源需要データを受信する。
【００３１】
該シミュレーションモジュール410は、上述した入力を使用して、完全に認可された資源及びインスタントキャパシティ資源の様々な組み合わせを含む資源構成出力を生成する。この資源構成は次いでiCAPモデル化モジュール430へ提供される。モデル化モジュール140,430は、管理者が指定したポリシーが満たされたとき又は満たされなかったときの割合及びインスタントキャパシティ資源の使用頻度又は使用量といった作業負荷管理の性能を含む動作結果を予測するために、資源構成情報並びに特定のポリシー及び作業負荷データを使用してWLMS動作のモデルを生成する。この計算されたモデルを用いて、iCAPモデル化モジュール430は次いで、例えば、資源の購入コスト、及びTiCAP資源等の時間ベースで使用料が発生する資源の消費コストを考慮に入れて、各々の考え得る資源構成及びそれに対応する需要データの組み合わせに関する金銭的なコストを計算する。TiCAPモデル化モジュール430は次いで、資源構成によるコスト及び性能データ並びに推奨を収集し、その結果を最終的に資源計画活動に携わっているコンピュータシステムのユーザに対して表示すべくフィードバックモジュールへ送る。
【００３２】
上記で開示した統合アーキテクチャ400は、作業負荷に資源を割り当てる際のWLMS動作の特性がキャパシティ計画（インスタントキャパシティ資源の取得のための計画を含む）に精確に反映されるため、より精確なインスタントキャパシティ計画を提供するものとなる。
【００３３】
図４Ａ及び図４Ｂは、統合アーキテクチャ100,400の例示的な動作600を示すフローチャートである。該動作600は、図４Ａのブロック605で開始し、この場合、コンピュータシステム10は動作中であり、CPS 300及びWLMS 200は、作業負荷の実行及びそれに対応する資源割り当てに関する履歴データを確立している。ブロック610で、シミュレーションモジュール130には、作業負荷の実行並びに資源の需要及び割り当てに関する履歴データ又はそれらのシミュレーションの何れか一方又は両方、又は履歴及びシミュレーションデータの組み合わせが提供される。該データは、インタフェイス310を介してコンピュータシステム管理者により提供することが可能であり、又は該データは、データベース240及び／又は330から抽出することが可能である。
【００３４】
ブロック615で、シミュレーションモジュール130は、考え得る資源需要構成を計算し、該構成データをWLMS 200へ（より詳細にはモデル化モジュール140へ）送る。ブロック620で、モデル化モジュール140は、供給された構成データに基づき、SLO、性能評価基準、及びポリシーを考慮に入れて、時間と共に変動する資源割り当ての選択肢を判定する。
【００３５】
ブロック625で、モデル化モジュール140は、割り当てに利用可能な資源がインスタントキャパシティ資源を含むか否かを判定する。該資源構成データにインスタントキャパシティ資源が含まれている場合には、モデル化モジュール140は、各々の考え得る資源割り当ての選択肢に関するコストを計算する（ブロック630）。ブロック625又は630に続いて、動作600は、ブロック635（図４Ｂ）へ移り、モデル化モジュール140が資源割り当ての選択肢を評価モジュール160へ送る。ブロック640で、評価モジュール160は、評価アルゴリズムを使用して、計画された資源割り当て構成の選択肢の何れかが特定の基準、しきい値条件、又は性能目標を満たすか否か、及び該構成の選択肢の各々の望ましさが如何なるものであるかを判定する。該構成の選択肢の何れも、十分な望ましさの順位に達さない場合、又は該構成の選択肢のうちの一部のみが所定の望ましさの値に達する場合には（ブロック645）、評価モジュール160は、統合アーキテクチャ100のWLMS部分でモデル化するための更なる資源構成を生成するようシミュレーションモジュール130に指示することが可能であり、この場合には動作600はブロック615に戻る。評価モジュール160は代替的に又は追加的に、この状態の通知をコンピュータシステム管理者へ提供することが可能である。前記構成の選択肢の望ましさの順位が所定のしきい値、基準、及び目標を満たす場合には、動作600はブロック650へ移り、該構成の選択肢が、フォーマット処理及びコンピュータシステム管理者への表示のために、CPS 300のフィードバックモジュール320及びインタフェイス310へ送られる。ステップ655で、動作600が終了する。
【００３６】
おそらくは統合アーキテクチャ100により実施可能となるCPS 300とWLMS 200との間の上記対話（例えば、動作600）は、少なくとも２つの異なる態様で進行することが可能である。第１の態様は、バッチプロセスで、統合アーキテクチャ100のCPS部分（シミュレーションモジュール130）が、全ての資源構成データ及び全ての動作データ（すなわち、多数の管理期間についてのデータ）を該統合アーキテクチャ100のWLMS部分へ送り、次いで該WLMS部分が、期待される動作結果全体からなる１ブロックのデータを返すことになる。第２の態様は、対話プロセスで、統合アーキテクチャ100のCPS部分が、先ず資源構成を確立し、及び単一の管理期間についての動作データを該統合アーキテクチャ100のWLMS部分へ提供する。次いでモデル化モジュール140が該データを処理し、その結果として得られる資源割り当て構成の選択肢を評価モジュール160へ返す。次いでシミュレーションモジュール130が次の期間を提供する、といった具合であり、動作600は、評価モジュール160により必要とされる限り、ピンポン態様で実行される。
【００３７】
様々な開示された実施形態は、方法、システム、及び／又は装置として実施することが可能である。一例として、例示的な実施形態は、本書に開示した方法を実施するための１つ又は２つ以上のコンピュータソフトウェアプログラムとして実施される。該ソフトウェアは、１つ又は２つ以上のモジュール（サブルーチンコード、又はオブジェクト指向プログラミングでは「オブジェクト」とも称す）として実施される。該ソフトウェアの場所は、様々な代替的な実施形態によって異なる。ソフトウェアプログラミングコード、例えば、コンピュータ又はサーバの１つ又は２つ以上のプロセッサにより、リムーバブルディスク又はハードディスクドライブを含む何らかのタイプ（半導体、磁気、及び光学的な装置等）の長期記憶媒体からアクセスアクセスされる。該コードは、かかる媒体上に分配することが可能であり、又は特定のコンピュータシステムのメモリ又は記憶装置から何らかのタイプのネットワークを介して他のコンピュータシステムへ分配して、かかる他のコンピュータシステムの操作者により使用されるようにすることが可能である。代替的に、該プログラミングコードは、メモリ（手持ち式の携帯型電子装置のメモリ等）内で実施し、バスを使用してプロセッサによりアクセスすることが可能である。メモリ内や物理媒体上でソフトウェアプログラミングコードを実施し及び／又はネットワークを介してソフトウェアコードを分配する技術及び方法は周知であり、本書ではこれ以上説明しないこととする。
【００３８】
本書で使用した用語及び説明は、例示のみを目的としたものであって、制限を意味するものではない。当業者には理解されるように、以下の特許請求の範囲に記載の本発明並びにそれと等価なものの思想及び範囲内で多数の変形例が実施可能であり、特許請求の範囲における全ての用語は、特に言及しない限り、その最も広い考え得る意味で理解されるべきである。
【図１Ａ】
0005352683.tif 000002
【図１Ｂ】
0005352683.tif 000003
【図２】
0005352683.tif 000004
【図３】
0005352683.tif 000005
【図４Ａ】
0005352683.tif 000006
【図４Ｂ】
0005352683.tif 000007