JP2008515106A - サービス・パフォーマンスとアプリケーション配置管理を調整する装置、システム、方法 - Google Patents

Abstract

【課題】 パフォーマンス管理とアプリケーション配置管理のタスクを動的に調整する装置、システム、方法を提供する。
【解決手段】 あるプロセス例は、分散型コンピュータ・システムへの要求負荷の変動、および前記分散型コンピュータ・システム内のサーバへのアプリケーションの配置の定期的な調節に対して動的である。前記プロセスには需要予測機能と容量調節機能の２つの相反する機能の流れがある。調整システムは、パフォーマンス・マネージャおよびアプリケーション配置マネージャの適切なインターフェースとともに、需要エスティメータと容量アジャスタの２つのサブシステムを包含する。この結果、アプリケーション配置プロセスは需要の変動により素早く反応し、サービスの様々なクラスに割り当てるリソースを再配列することによってパフォーマンス保証をよりよく満たし、管理システムは非監視モードで動作するため、手動による運用管理コストと人為的な間違いを減らす。
【選択図】図４

Description

本発明は、コンピュータ・システムにおいて、サービス要求負荷の変動があっても提供するサービス品質のレベルを最善に満たすように、サービスをオンデマンドで供給することに関係し、さらに具体的には、様々なサービスの容量ニーズおよびコンピュータ・システム内のサーバにサービスを提供するアプリケーションの配置の調節をよりよく予測するための、パフォーマンス・マネージャとアプリケーション配置マネージャのタスクの調整に関係する。

ひとつまたは複数のサーバからなり、それぞれサービス品質のパフォーマンスを保証する多数のサービス品質クラスにそれぞれ要求があり、要求負荷が時間によって変動するコンピュータ・システムを想定する。このようなシステムでは、パフォーマンス・マネージャが、リソースの割り当てを最適にし、スケジューラ、並列処理コントローラ、およびルータに適切な指示を出すことによって、各要求のそれぞれのクラス品質のパフォーマンスを保証するように動的に働く。同様に、アプリケーション配置マネージャは、サービスを提供するアプリケーションの複数のインスタンスをサーバに最適に配置するように動的に働く。パフォーマンス・マネージャとアプリケーション配置マネージャが同期して動作していなければ、いずれか一方のマネージャが全体的な目的を考慮せずにその局部的な目標を達成しようとするか、または一方のマネージャのパフォーマンスの改善が他方のマネージャに厳しい制約を課すような形で双方のマネージャが互いに反する動作をすることがある。そのため、パフォーマンス・マネージャとアプリケーション配置マネージャの動作を調整する必要がある。

先行技術は、パフォーマンス・マネージャとアプリケーション配置マネージャがそれぞれのタスクをふたつの別々の管理ドメインで実行することを提案している。システム・アドミニストレータは、パフォーマンス保証の履行とサーバへのアプリケーションの配置を調整する動的で自動的なプロセスを用いずに、いくつかの管理構成パラメータを手動で設定する。

以上の問題を克服するために、本発明の一つの側面は、分散型コンピュータ・システムにおいてパフォーマンス・マネージャとアプリケーション配置マネージャの動的な調整をする装置、システム、および方法を提供することである。

本発明の別の側面は、分散型コンピュータ・システムにおいてパフォーマンス・マネージャからアプリケーション配置マネージャに、需要予測とリソース割り当て情報を伝達するプロセスのシステムおよび方法を提供することである。

本発明のさらに別の側面は、分散型コンピュータ・システムにおいてアプリケーション配置マネージャからパフォーマンス・マネージャに容量負荷の制約条件を伝達するプロセスのシステムおよび方法を提供することである。

本発明の別の側面は、分散型コンピュータ・システムにおいてパフォーマンス・マネージャとアプリケーション配置マネージャとを動的に調整するシステムおよび方法を提供することである。

本発明は、パフォーマンス・マネージャとアプリケーション配置マネージャのタスクを動的に調整するプロセスを導入する。さらに、本発明は、調整プロセスを実装するシステムを紹介する。このプロセスは、分散型コンピュータ・システムへの要求負荷の変動、および分散型コンピュータ・システムにおけるアプリケーションのサーバへの配置の定期的な調節に対して動的なものである。プロセスにはふたつの相反する機能的な流れ、すなわち需要予測機能と容量調節機能がある。調整システムは、パフォーマンス・マネージャおよびアプリケーション配置マネージャの適切なインターフェースとともに、ふたつのサブシステム、需要エスティメータと容量アジャスタを包含する。パフォーマンス・マネージャとアプリケーション配置マネージャの動的な調整にはいくつかの利点がある。まず、アプリケーション配置プロセスが要求の変動に対してより素早く反応する。次に、パフォーマンス保証は、様々なサービスのクラスに割り当てるリソースを再配列することによってよりよく満たされる。３番目に、管理システムが非監視モードで動作するため、手動の運用管理コストと人為的な間違いが減る。

本発明の上記およびその他の側面、特徴、並びに利点は、図面に照らしながら以下の発明の詳細な説明を熟慮すれば明らかになるであろう。

本発明は、パフォーマンス・マネージャとアプリケーション配置マネージャのタスクを調整する装置、システム、および方法を提供する。このプロセスは、コンピュータ・システムへのサービス要求負荷の変動、およびコンピュータ・システムにおけるアプリケーションのサーバへの配置の定期的な調節に対して動的なものである。プロセスにはふたつの相反する機能的な流れ、すなわち容量予測機能と容量調節機能がある。調整システムは、パフォーマンス・マネージャおよびアプリケーション配置マネージャの適切なインターフェースとともに、ふたつのサブシステム、容量エスティメータと容量アジャスタを包含する。パフォーマンス・マネージャとアプリケーション配置マネージャの動的な調整にはいくつかの利点がある。まず、アプリケーション配置プロセスが要求の変動に対してより素早く反応する。次に、パフォーマンス保証は、様々なサービスのクラスに割り当てるリソースを再配列することによってよりよく満たされる。３番目に、管理システムが非監視モードで動作するため、手動の運用管理コストと人為的な間違いが減る。

本明細書で使用するサービスとは、クライアントの要求を、要求に対するアクションを実行するために必要な接続性、接続エレメント、アプリケーションの呼び出し、およびリソースを提供することによって満たすことを含む。申し分のないサービスとなるためには、サービスは申し込みの手段、十分な応答性に関しリソースの割り当てを含めたサービス品質の提供を請け負って、保証するサービス品質を規定し約束する手段をもつのが望ましい。アプリケーションは、ウエブ・コンテンツへの静的および動的なアクセス、エンタープライズ・アプリケーション、およびデータベース・サーバへのアクセスを含む。さらに具体的には、アプリケーションはＷｅｂｓｐｈｅｒｅ環境でＨＴＴＰウエブ・サーバ、サーブレット、Ｅｎｔｅｒｐｒｉｓｅ Ｊａｖａ（登録商標） Ｂｅａｎｓ（ＥＪＢ）、データベース・クエリによって提供できる。ある特定のサービスとは、ひとつまたは複数のサービスの単独もしくは複合のあらゆる組み合わせから構成されるであろう。

ある特定のアプリケーションへのサービス要求が増大すると、増大した負荷に対応するために、オンデマンド・プロビジョニング・システムがアプリケーションの追加インスタンスをデプロイする。アプリケーションのインスタンスはそのアプリケーションに固有の実時間環境でデプロイされる。例えば、ウエブ・ページの検索はウエブ・サーバを必要とし、サーブレットはウエブ・コンテナを必要とし、ＥＪＢアプリケーションはＥＪＢコンテナを必要とし、データベース・アプリケーションはデータベース・サーバを必要とする。ひとつまたは複数のコンピュータ・システムに様々な実時間環境が提供されて、分散型コンピュータ・システムを作る。

サービス・プロバイダは、カスタマーに対してひとつまたは複数のアプリケーションを実行することによって満たされるサービスを提供する。カスタマーがあるサービスを申し込むとき、各々に対しサービス品質保証が定義されている多くのサービス・クラスからひとつを選択する。例えば、サービス品質保証は、サービス要求に対する平均応答時間の目標値であることも、または応答時間が規定の閾値を上回るサービス要求の目標であることもある。サービス・プロバイダとカスタマーとのサービス契約には通常、サービス品質保証が満たされるとき、もしくは満たされないときにとるべき措置が記載されている。当該措置は金銭的な性質かつ法的な性質、もしくは金銭的な性質または法的な性質のことがある。サービス・プロバイダの目標は、提供するすべてのサービス品質クラスおよびすべてのサービスに対してサービス品質保証をできるだけ多く満たすことである。その目標を達成するためには、（１）リソースを多数のサービス品質クラスに属するサービス要求に動的に割り当てる、および（２）アプリケーションのインスタンスを動的にデプロイおよびアンデプロイする、オンデマンドの管理環境をもつことが極めて重要である。

最初のステップは、コンピュータ・システムに配置されるアプリケーションの一連のインスタンスが与えられる場合に、ストレージ、演算能力、実行スレッド、およびアプリケーション・サーバとデータベース・サーバとの接続などの様々なリソースの容量を、様々なサービス品質クラスに属するサービス要求に割り当てるサービス・パフォーマンス・マネージャに関わる。このステップは様々なリソースのパフォーマンスのモデル化とリソース割り当ての最適化を含む。

２番目のステップは、様々なアプリケーションの容量ニーズとコンピュータ・システムにおけるその容量所要量および利用できる容量が与えられた場合に、デプロイする必要がある各アプリケーションのインスタンスの数を決定するアプリケーション配置マネージャに関わる。このステップはさらに、容量上制約になる配置最適化問題の解と、アプリケーションのインスタンスをデプロイおよびアンデプロイするステップを含む。後者は手作業で、監視モードで、または完全自動化モードで行うことができる。

包括的な目標は、提供するすべてのサービス品質クラスとすべてのサービスに対してサービス品質保証を最善に満たすことである。その目的を達成するために、パフォーマンス管理とアプリケーション配置管理の調整を追求する。調整のプロセスは、（１）サービス品質保証を達成する理想容量を計算するステップ、（２）アプリケーションのサーバへの配置の決定にあたりその理想容量を採用するステップ、（３）配置に基づいてサービスとアプリケーションの容量限界を計算するステップ、および（４）配置および容量限界を条件として、サービス品質保証を満たす容量の割り当てを決定するステップに関わる。このプロセスは、定期的に、かつ例えばモニタしたパフォーマンスが低下したときあるいはあるサービス品質保証が満たされていないときなど、ある基準に基づいて、もしくは定期的にまたはある基準に基づいて繰り返す。

ある実施例では、理想容量を計算するステップは、何らかのアプリケーション配置の制約条件を無視しながらサービス品質の達成を最適化するステップを含む。

いくつかの実施例では、採用するステップは、理想容量が現在のアプリケーションの配置によって満たされるかどうかを判別するステップを含む。満たされる場合、現在の配置をアプリケーションの配置の解として使用する。満たされない場合、アプリケーションの配置問題を解決する方法へのインプットとして、理想容量を使用する。

いくつかの実施例では、容量限界を計算するステップが、コンピュータ・システム内のサーバの配置行列とサーバの容量を調べるステップを含み、かつ容量の割り当てを決定するステップがサービス品質を達成するための最適化問題を解決するステップを含み、もしくは容量限界を計算するステップがコンピュータ・システム内のサーバの配置行列と容量を調べるステップを含み、または容量の割り当てを決定するステップがサービス品質を達成するための最適化問題を解決するステップを含み、最適化問題はアプリケーション配置行列による制約を受ける。

いくつかの実施例では、方法は、サービス品質保証を満たすにあたり、コンピュータ・システムのパフォーマンスをモニタするステップと、サービス品質保証が満たされないとき、サービス品質保証が満たされるまで、理想容量を計算し；採用し；容量限界を計算し；決定する各ステップを繰り返すステップとを含む。場合により、モニタするステップをあるモニタリング基準に基づいて行い、かつモニタするステップをあるモニタリング基準に基づいて行う、もしくはモニタするステップをあるモニタリング基準に基づいて行い、またはモニタするステップをあるモニタリング基準に基づいて行う。

いくつかの実施例では、方法は、少なくともひとつのアプリケーションが複数のサービスに対する複数のサービス要求を満たすステップと、すべてのサービス要求およびすべてのサービスに対してサービス品質保証が満たされるまで、理想容量を計算し；採用し；容量限界を計算し；決定する各ステップを繰り返すステップとを含む。

いくつかの実施例では、方法は、少なくともひとつのアプリケーションが複数のサービスに対する複数のサービス要求を満たすステップと、すべてのサービス要求およびすべてのサービスに対してサービス品質保証が満たされるまで、理想容量を計算し；採用し；容量限界を計算し；決定する各ステップを繰り返すステップとを含む。

最初のステップは、すべてのサービス品質クラスについてパフォーマンス測定基準（メトリクス）をモニタするステップに関わる。パフォーマンス・メトリクスは、サービス要求のトラフィック密度、サービス要求の応答時間、サービス要求を満たすアセンブリのリソース使用量を含むが、それだけに限定されない。次に、当該パフォーマンス・メトリクスをモデルパラメータとして使用して、パフォーマンス・モデルを構成する。モデルを分析して、様々なサービス品質クラスに対する割り当て容量の関数として、サービス品質の測定値を提供する。モデルを使用して、サービス品質保証を達成するために理想容量を計算する。モデルが与えられて、アプリケーション・インスタンスの数とそのサーバへの配置による制約を受けなければ、最適化問題はサービス品質クラス間に全体の容量を最善に配分するように解決される。すなわち、最初のステップは、測定を基に、モデルで導いた、制約を受けないリソース割り当て問題の解である。得られる解は、アプリケーションの容量の制約条件があれば実現できるかもしれないし、または実現できないかもしれない。

２番目のステップはステップ１で導き出した理想容量を使用して、理想容量の可用性を最善に実現するために、アプリケーションのサーバへの最善の配置を決定する。現在のアプリケーションの配置が理想容量を実現する場合、配置は同じままである。そうでなければ、新たなアプリケーションの配置を求める。各アプリケーション・インスタンスは、ストレージ所要量および演算サイクルなど、所定の量のリソースを必要とする。当該リソースは容量の限られたサーバから提供される。アプリケーションおよびサービスが多数あるため、アプリケーション配置ステップは多重クラスのナップザック問題（ｋｎａｐｓａｃｋ ｂｉｎ ｐａｃｋａｇｉｎｇ ｐｒｏｂｌｅｍ）の解に関わる。実際上、最適化問題はヒューリスティック技術を用いて解決する。最適化問題のアウトプットはアプリケーション配置行列であり、行はアプリケーションを表し、列はサーバを表し、セルへの１（または０）の入力はある特定のアプリケーションのある特定のサーバへの配置（または欠落）を表す。配置行列は、アプリケーション・インスタンスを現在のアプリケーション配置にデプロイ（およびアンデプロイ）することによって実現する。最適化問題の目的は、配置行列を実現させるためのオーバーヘッドの最小化である。

３番目のステップは、新たなアプリケーションの配置によってもたらされる容量限界の計算に関わる。アプリケーション行列を調べて、利用できるサーバ容量を測定することによって、アプリケーションのサブセットの容量限界を求める。各アプリケーションはひとつまたは複数のサービス品質クラスを満たす。このため、サービス品質クラスのサブセットの容量限界を計算する。計算した容量は、ステップ１で計算した理想容量とは異なり、アプリケーション配置行列による制約を受ける。

４番目のステップはステップ３で計算した容量限界を、制約のあるリソース割り当て問題を解決するときの制約条件として使用する。このような問題の目的は、様々なサービス品質クラスについてサービス品質保証を最善に満たすことである。最適化基準は、サービス品質の測定値とその目標の全体の効用関数の最大化、またはサービス品質保証を相対的に満たすためにサービス品質クラス間でのリソースのバランシングとすることができるであろう。

コンピュータ・システムのオンデマンド・サービス・プロビジョニングとパフォーマンス管理の高次レベルの階層図を図１に表す。分散型コンピュータ・システム４０と運用・制御システム８０と調整管理システム９０の３つのレイヤがある。様々なサービスのクラスに属する要求１０が分散型コンピュータ・システム４０に依頼されて、そこで処理され、適切な応答５０が出される。運用・制御システム８０は処理されるときの要求１０のパフォーマンスと、分散型コンピュータ・システム４０のリソースの使用量をモニタする。モニタされたデータ３０は分散型コンピュータ・システム４０のモニタから収集されて、運用・制御システム８０に伝達される。加えて、運用・制御システム８０は分散型コンピュータ・システム４０のアクチュエータに指示する制御アクション２０を発行する。トップ・レイヤは、運用・制御システム８０から統計データ７０を受け取って、制御パラメータ６０を運用・制御システム８０に送ることによって応答を返す調整管理システム９０からなる。

図２は分散型コンピュータ・システム４０を表す。様々なサービスのクラスに属する要求１０がスケジューラに到着すると、そこで要求がサービス・クラスに基づいて多数のキュー４１０に入れられるとともに、要求１０が並列処理コントローラに到着すると、そこでシステムがサービスを提供することになる各クラスの要求の数を制限する。ディスパッチされると、要求はルータ４２０から指定のサーバに送られ、そこでサーバはそのサーバにすでに配置されているアプリケーションの実行からそのサービスを受け取り、さらに応答５０を出す。図２はふたつのサーバ４３０および４４０と、３つのアプリケーション、アプリケーション１、アプリケーション２、アプリケーション３を示す。アプリケーション１のインスタンスは４５０および４７０のふたつあり、それぞれサーバ４３０および４４０で動作する。対して、アプリケーション２のインスタンスはサーバ４３０で動作する４６０のひとつだけ、アプリケーション３のインスタンスはサーバ４４０で動作する４８０のひとつだけである。キュー４１０はモニタ済みデータ３０を収集して、それを運用・制御システム８０に送る。それに応答して、運用・制御システム８０は、キュー４１０を制御するキュー・アクション２１０と、ルータ４２０を制御するルーティング・アクション２２０と、アプリケーション・インスタンスのサーバへの配置を制御する配置アクション３２０を送る。

図３は運用・制御システム８０を表す。キュー・コントローラ８１０はスケジューラと並列処理コントローラを制御し、調整管理システム９０からそのキュー制御パラメータ６１０を受け取る。また、モニタ済みデータ３０が収集されて、キュー・モニタ８２０が調整管理システム９０に統計データ７０を供給する。また、ルーティングの重み２２０が調整管理システム９０によってルータ・コントローラ８３０に供給される。配置コントローラ８４０は調整管理システム９０から受け取った配置変更６３０の指示を与えて、対応する配置アクション２３０を行う。

図４は調整管理システム９０を表す。パフォーマンス・マネージャ９２０は、サービス・マネージャ９１０が提供するパフォーマンス目標を満たすよう努めながら、システムのパフォーマンスを最適化する。アプリケーション配置マネージャ９５０は、システム構成マネージャ９６０が提供する構成パラメータを使って、サーバへのアプリケーション・インスタンスの最適な配置を発行する。パフォーマンス・マネージャ９２０とアプリケーション配置マネージャ９５０との調整は、容量エスティメータ９３０と容量アジャスタ９４０を通じて行う。容量エスティメータ９３０は最適な容量所要量（配置による制約がない）および統計データを使って、アプリケーションに対する負荷を予測する。得られた予測と構成情報をアプリケーション配置マネージャ９５０が使って、配置変更６３０を作成する。さらにこの新たな配置データを容量アジャスタ９４０が使って、新たな配置により制約を受ける新たな容量限界のセットを計算する。

パフォーマンス・マネージャ９２０とアプリケーション配置マネージャ９５０はともに、ブラックボックス制御アプローチではなく、それぞれ独自のモデルと最適化問題を採用しているため、調整プロセスを繰り返し述べる必要はないことを付け加えておく。

調整プロセスのフロー図を図５に示す。このプロセスは決定１０７０に基づいて繰り返すが、決定１０７０は所定の制御期間で定期的に起こるか、またはシステムのパフォーマンスが低下し始めたときに起動される。プロセスの最初のステップ１０１０は、様々なサービス・クラスの容量ニーズの予測に関わる。現在のアプリケーションの配置による制約がなければ、容量エスティメータはサービス品質を最適化するように様々なサービス・クラスの間への全体の容量の最適な割り当てを計算する。ステップ１０２０で、計算した理想容量は他のローディング情報とともにアプリケーション配置マネージャに伝達される。理想容量が現在のアプリケーション配置で満たされるかどうかの決定１０３０を行う。満たされれば、変更は必要ない。満たされなければ、理想容量と予想負荷に基づいて新たなアプリケーション配置を決定する１０４０。アプリケーション配置を決定するアルゴリズムは所定の配置ポリシーを使ってもよい。新たなアプリケーション配置は容量アジャスタに伝達されて、そこでサービス・クラスとサーバのすべての対に対応する容量の制約条件を計算する１０５０。さらに当該容量限界をパフォーマンス・マネージャにインプットとして供給する。次に、パフォーマンス・マネージャはサービス品質を最適化するようにサービス・クラス間への容量の最適な割り当てを計算する１０６０。

このように、本発明はパフォーマンス管理とアプリケーション配置管理を調整する方法を含む。方法は、サービス要求の様々なサービス・クラスの容量ニーズを推定するステップと、サービス要求に対する少なくともひとつのアプリケーションの理想容量を計算するステップと、現在のアプリケーションの配置によって理想容量が満たされているかどうかを判別するステップと、理想容量が満たされている場合、現在のアプリケーションの配置に変更を行わないステップと、理想容量が満たされない場合、理想容量と予想負荷に基づいて新しいアプリケーションの配置を決定するステップと、サービス・クラスとサーバのすべての対について対応する容量の制約条件を計算するステップと、サービス品質を最適化するようにサービス・クラスの間への容量の最適な割り当てを計算するステップとを含む。

いくつかの実施例では、方法は、繰返し基準に基づいて、予測し；理想容量を計算し；決定し；対応する容量の制約条件を計算し；最適な割り当てを計算する各ステップを繰り返すステップを含む。

本発明は、少なくともひとつのサービスの品質サービス・レベルを満たす少なくともひとつのアプリケーションをプロビジョニングする方法も含む。方法は、コンピュータ・システムでサービス・パフォーマンス・マネージャとアプリケーション配置マネージャを調整するステップを含み、サービス・パフォーマンス・マネージャが少なくともひとつのサービスのパフォーマンスを管理し、アプリケーション配置マネージャが少なくともひとつのアプリケーションの配置を管理し、アプリケーションがある特定のサービス要求を満たす。調整するステップは、特定のサービスに対して定義されるサービス品質レベルを達成する理想容量を計算するステップと、配置ポリシーに従い少なくともひとつのアプリケーションをコンピュータ・システム内の少なくともひとつのサーバへの配置を決定するにあたり、アプリケーション配置マネージャが理想容量を採用するステップと、配置に基づいて少なくともひとつのアプリケーションに対する特定のサービスの容量限界を計算するステップと、パフォーマンス・マネージャが配置および容量限界を条件としてサービス品質レベルを満たす容量の割り当てを決定するステップとを含む。

いくつかの実施例では、方法は、理想容量をアプリケーション配置マネージャに伝達するステップと、配置および容量限界をサービス・パフォーマンス・マネージャに伝達するステップとを含む。いくつかの実施例では、理想容量を伝達するステップが、理想容量を、理想容量ベクトルの１要素がサービス品質レベルに対応する理想容量ベクトルとして表すステップを有し、かつ配置および容量限界を伝達するステップが、配置を、配置行列の行または列がアプリケーションに対応し、配置行列の列または行がサーバに対応する配置行列として表すステップと、容量限界を、容量限界ベクトルの１要素がサーバに対応する容量限界ベクトルとして表すステップを有し、もしくは理想容量を伝達するステップが、理想容量を、理想容量ベクトルの１要素がサービス品質レベルに対応する理想容量ベクトルとして表すステップを有し、または配置および容量限界を伝達するステップが、配置を、配置行列の行または列がアプリケーションに対応し、配置行列の列または行がサーバに対応する配置行列として表すステップと、容量限界を、容量限界ベクトルの１要素がサーバに対応する容量限界ベクトルとして表すステップを有する。

本発明は、少なくともひとつのサービス品質保証を満足する少なくともひとつのアプリケーションをプロビジョニングする装置も含む。前記少なくともひとつのアプリケーションはある特定のサービスに対する複数のサービス要求を満たす。装置は、特定のサービスに対して定義されるサービス品質レベルを達成する理想容量を計算する手段と、配置ポリシーに従い前記少なくともひとつのアプリケーションをコンピュータ・システム内の少なくともひとつのサーバへの配置を決定するにあたり、理想容量を採用する手段と、配置に基づいて前記少なくともひとつのアプリケーションに対する特定のサービスの容量限界を計算する手段と、配置および容量限界を条件としてサービス品質レベルを満たす容量の配置を決定する手段とを含む。

本発明は、パフォーマンス管理とアプリケーション配置管理を調整する装置も含む。装置は、サービス要求の様々なサービス・クラスについて容量ニーズを予測する手段と、サービス要求について少なくともひとつのアプリケーションの理想容量を計算する手段と、理想容量が現在のアプリケーションの配置によって満たされるかどうかを判別する手段と、理想容量が満たされる場合、現在のアプリケーションの配置に変更を行わない手段と、理想容量が満たされない場合、理想容量と予想負荷に基づいて新たなアプリケーションの配置を決定する手段と、サービス・クラスとサーバのすべての対について対応する容量の制約条件を計算する手段と、サービス品質を最適化するようにサービス・クラス間への容量の最適な割り当てを計算する手段とを含む。

本発明は、少なくともひとつのサービスに対する品質サービス・レベルを満たす少なくともひとつのアプリケーションをプロビジョニングする装置も含む。装置は、コンピュータ・システムでサービス・パフォーマンス・マネージャとアプリケーション配置マネージャを調整する手段を含み、サービス・パフォーマンス・マネージャが前記少なくともひとつのサービスのパフォーマンスを管理する手段を含むとともに、アプリケーション配置マネージャが少なくともひとつのアプリケーションの配置を管理する手段を含み、アプリケーションがある特定のサービスに対するサービス要求を満たす。

調整する手段は、特定のサービスに対して定義されるサービス品質レベルを達成する理想容量を計算する手段であって、配置ポリシーに従いコンピュータ・システム内の少なくともひとつのサーバへの前記少なくともひとつのアプリケーションの配置を決定するにあたり、アプリケーション配置マネージャが理想容量を採用する手段を含む、前記計算する手段と、配置に基づいて前記少なくともひとつのアプリケーションに対する特定のサービスの容量限界を計算する手段と、パフォーマンス・マネージャが配置および容量限界の条件を受けてサービス品質レベルを満たすように容量の割り当てを決定する手段を含む。

本発明は、ハードウェア、ソフトウェア、またはハードウェアとソフトウェアの組み合わせにおいて実現できる。本発明は、１台のコンピュータ・システムで集中的に、または多様な要素が相互接続された複数のコンピュータ・システムに分散する分散的に実現できる。あらゆる種類のコンピュータ・システム（または本明細書に記載する方法を実施するようになされた他の装置）が適する。ハードウェアとソフトウェアの典型的な組み合わせは、ロードされて実行されるとき、本明細書に記載の方法を実施するようにコンピュータ・システムを制御するコンピュータ・プログラムを搭載した汎用コンピュータ・システムであろう。本発明は、本明細書に記載する方法の実施を可能にするすべての特徴を有し、かつコンピュータ・システムにロードされるとき、これら方法を実施できるコンピュータ・プログラム製品に埋め込むこともできる。

この状況におけるコンピュータ・プログラム手段またはコンピュータ・プログラムとは、情報処理能力を備えるシステムに、直接的にあるいは、別の言語、コード、表記法および異なる複製物もしくはそれらの組み合わせに変換後、ある特定の機能をさせるよう意図した命令のセットのあらゆる言語、コード、または表記法でのあらゆる表現を意味する。

以上本発明のより関連の深い側面および実施例のいくつかを概説してきたことに留意する。本発明は多くのアプリケーションに使用できる。このため、特定の構成および方法について説明しているが、本発明の意図および概念は他の構成およびアプリケーションにも適しかつ適用可能である。本発明の精神および範囲を逸脱することなく、開示した実施例に他の変更を行えることは当業者には明らかであろう。説明した実施例は、本発明のより顕著な特徴および適用のいくつかを単に例証したものにすぎないと解釈するべきである。開示した発明を別の方法で適用する、または発明を当業者に周知の方法で変更することにより、他の有益な結果が実現できる。

本発明のある実施例によるシステム全体像のブロック図である。 本発明のある実施例による分散型コンピュータ・システムを示す図である。 本発明のある実施例による運用・制御システムを示す図である。 本発明のある実施例による調整管理システムを示す図である。 本発明のある実施例による調整プロセスのフロー図である。

Claims (27)

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. 前記理想容量を伝達するステップが、前記理想容量を、理想容量ベクトルの１要素が前記サービス品質レベルに対応する理想容量ベクトルとして表すステップを有し、
    前記配置および前記容量限界を伝達するステップが、配置行列の行が前記アプリケーションに対応するとともに、配置行列の行が前記サーバに対応する配置行列として前記配置を表すステップと、容量限界の１要素が前記サーバに対応する容量限界ベクトルとして前記容量限界を表すステップとを有する、請求項１２に記載の方法。
26. 少なくともひとつのサービスに対する品質サービス・レベルを満たす少なくともひとつのアプリケーションを供給させる、コンピュータ読み取り可能プログラムコード手段を内蔵するコンピュータ使用可能媒体を有する製造物であって、前記製造物内のコンピュータ読み取り可能プログラムコード手段が、
    コンピュータに、
    コンピュータ・システムでサービス・パフォーマンス・マネージャとアプリケーション配置マネージャを調整するステップで、前記サービス・パフォーマンス・マネージャが前記少なくともひとつのサービスのパフォーマンスを管理し、前記アプリケーション配置マネージャが少なくともひとつのアプリケーションの配置を管理し、前記アプリケーションがある特定のサービスに対するサービス要求を満たす、調整するステップを実行させるコンピュータ読み取り可能プログラムコード手段を有し、前記調整するステップが、
    前記特定のサービスに対して定義する前記サービス品質レベルを達成する理想容量を計算するステップと、
    配置ポリシーに従い、前記少なくともひとつのアプリケーションの前記コンピュータ・システム内の少なくともひとつのサーバへの配置を決定するにあたり、前記アプリケーション配置マネージャが前記理想容量を採用するステップと、
    前記配置に基づいて前記少なくともひとつのアプリケーションに対する前記特定のサービスの容量限界を計算するステップと、
    前記パフォーマンス・マネージャが、前記配置および容量限界を条件として、前記サービス品質レベルを満たすように容量の割り当てを決定するステップとを有する、製造物。
27. 少なくともひとつのサービスに対する品質サービス・レベルを満たす少なくともひとつのアプリケーションを供給する方法ステップを実施するマシンで実行可能な命令のプログラムを実体として具有する、マシンで読み取り可能なプログラム・ストレージ・デバイスであって、前記方法ステップが請求項１１のステップを有する、プログラム・ストレージ・デバイス。

Images