JP2005032242A - リソースの利用およびアプリケーションの性能の監視システムおよび監視方法 - Google Patents

Abstract

【課題】 アプリケーションのリソースの利用およびアプリケーションの性能を監視する。
【解決手段】 本発明にかかるシステムは、リソースデータ、アプリケーションデータ、ポリシーデータおよび監視エージェントを備える。リソースデータは、複数のリソースに関する情報を含む。これらのリソースには、複数のコンピュータが含まれる。アプリケーションデータは、１つまたは２つ以上のアプリケーションプロファイルを含む。アプリケーションプロファイルのそれぞれは、性能プロファイルおよびリソースプロファイルを有する。リソースプロファイルは、リソース利用情報を含む。ポリシーデータは、１つまたは２つ以上のアプリケーション性能ポリシーおよび１つまたは２つ以上のリソース利用ポリシーを含む。最後に、監視エージェントは、ポリシーデータに準拠しているかについてアプリケーションデータを監視する。
【選択図】図３

Description

本発明は、リソースの利用およびアプリケーションの性能の監視システムおよび監視方法に関する。

現代のデータセンターにおける重要な課題は、アプリケーションの需要が突然のピークになった時に、コンピュータサーバなどの十分なリソースが、データセンターにおいて各アプリケーションまたは各アプリケーションコンポーネントに利用可能であることを保証することである。
米国特許公開２００２／０１２９１２７ 米国特許公開２００２／００１６８１２ 米国特許公開２００２／００６９２７９ 米国特許出願０９／７０９７０５ 米国特許出願１０／２０６５９４ 米国特許出願０９／４９３７５３ 米国特許出願０９／５６２５９０ Sun Microsystems, Inc., White Paper, "Transforming the Economics of Computing", Optimizing IT Infrastructure Utilization, 2003, Chapters 1-5 Sun Microsystems, Inc., White Paper, "N1-Introducing Just in Time Computing", An Executive Brief, 2002 Sun Microsystems, Inc., N1 Technology Brief, "The I-Fabric", A core component of Sun's Trraspring software, 2002 Sun Microsystems, Inc., N1 Technology Brief, "The I-Fabric", A core component of Sun's Trraspring software, 2002 IBM Think Research papers: 1) eWLM: Distributed Computing; 2) eWLM: Managing Complexity; 3) eWLM: Allocating for Effeciency; 4) The Great Balancing Act; and 5) eWLM: Automatic Computing; 2002, eWLM: Enterprise Workload Management IBM Presentation: "Workload Management for e-Business": eWLM, Mike Smith, 4/1/2003

この問題は、集合アプリケーション（aggregate application）の場合に複雑になる。
集合アプリケーションは、多層アーキテクチャで配備され、各層に１つまたは２つ以上のサーバを必要とする。
例えば、集合アプリケーションは、そのアプリケーションのクライアントが接続を行う１つまたは２つ以上のウェブサーバと、そのアプリケーションのビジネスロジックを実施する１組のアプリケーションサーバと、そのアプリケーションが必要とするデータを操作する１つまたは２つ以上のデータベースサーバとを含むことがある。
この集合アプリケーションの性能目標を満たすには、各層に十分なリソースを設けなければならない。

また、複数のアプリケーションコンポーネントが、共有リソース上に集約されることもある。
これにより、共有リソースの利用を増大させることが可能になる。
しかしながら、ピーク需要の必要量を満たすために、アプリケーションコンポーネントに割り当てられる共有リソースの比率は、必要とされるものよりも大きくなることがある。

アプリケーションのリソースの利用およびアプリケーションの性能を監視するためのシステムおよび方法が開示される。
一実施の形態では、システムは、リソースデータ、アプリケーションデータ、ポリシーデータ、および監視エージェントを備える。
リソースデータは、複数のリソースに関する情報を含む。
これらのリソースには、複数のコンピュータが含まれる。
アプリケーションデータは、１つまたは２つ以上のアプリケーションプロファイルを含む。
アプリケーションプロファイルのそれぞれは、性能プロファイルおよびリソースプロファイルを有する。
リソースプロファイルは、リソース利用情報を含む。
ポリシーデータは、１つまたは２つ以上のアプリケーション性能ポリシーおよび１つまたは２つ以上のリソース利用ポリシーを含む。
最後に、監視エージェントは、ポリシーデータに準拠しているかについてアプリケーションデータを監視する。

別の実施の形態では、アプリケーションの性能を動的に監視して管理するための方法が開示される。
この方法は、１つまたは２つ以上の性能ポリシーに準拠しているかについてアプリケーションデータを監視することを含む。
アプリケーションデータは、１つまたは２つ以上のアプリケーションプロファイルを含む。
アプリケーションプロファイルのそれぞれは、性能プロファイルおよびリソースプロファイルを有する。
リソースプロファイルは、アプリケーションに関連したリソース利用情報を含む。
アプリケーションは、それぞれ、ドメインに関連したコンテナで実行される。
ドメインは、それぞれ、１つまたは２つ以上のリソースを含む。
これらのリソースには、複数のコンピュータが含まれる。
ポリシーの違反に応じて、リソースがコンテナにどのようにマッピングされるかを再割り当てすることにより、ポリシーの強制が自動的に行われる。

本発明の例示の実施の形態は、図面に示される。

図１に、複数のリソースの全体にわたってアプリケーションの性能を監視する例示のシステムを示す。
コントローラ１００は、リソースデータ１０４を含む。
このリソースデータ１０４は、複数のリソースに関する情報を含む。
リソースには、サーバ、すなわちラック／ブレードアーキテクチャのブレードなどの複数のコンピュータが含まれ得る。
また、リソースには、サーバ内のパーティションなどの他の種類の計算リソース、および、負荷分散装置、ファイアウォール、ネットワークスイッチなどの他のデバイスも含まれ得る。
一例として、リソースデータ１０４は、そのリソースの容量に関する情報、そのリソースのネットワークアドレス、ならびにそのリソースをインスタンス化（初期化、ブート、およびコンフィギュレーション）する方法を含むことができる。

また、コントローラ１００は、アプリケーションデータ１１０も含む。
このアプリケーションデータは、１つまたは２つ以上のアプリケーションプロファイル１１２、１１４、１１６を含む。
アプリケーションは、シングルアプリケーション（single application）であってもよいし、複製アプリケーション（replicated application）であってもよいし、集合アプリケーションであってもよい。
複製アプリケーションは、シングルアプリケーションの１組の複製インスタンスであってもよく、この１組の複製インスタンスが、協同して単一の機能を実行する。
一例として、複製アプリケーションは、ウェブサーバファームであってもよいし、Ｏｒａｃｌｅ（登録商標）のリアルアプリケーションクラスタ（ＲＡＣ（Real Application Cluster））などの複製データベースアプリケーションであってもよい。
集合アプリケーションは、複数の層の全体にわたる複数のシングルアプリケーションおよび／または複製アプリケーションを組み合わせたものであってもよい。

一実施の形態では、アプリケーションプロファイル１１２〜１１６は、リソースプロファイルおよび性能プロファイルの１つまたは２つ以上のものを含むことができる。
リソースプロファイルは、アプリケーションが必要とするリソースの量に関するリソース需要情報と、リソース利用情報とを含むことができる。
リソース利用情報は、アプリケーションが現在割り当てられているリソースの量に関するリソース割り当て情報、および／または、アプリケーションが使用中であるかもしくはある時間にわたり使用したリソースの量に関するリソース消費情報を含むことができる。
一例として、アプリケーションのＣＰＵ、メモリ、Ｉ／Ｏ、ネットワークの比率または絶対消費量に関する情報をある時間にわたって追跡し、リソースプロファイルに記憶することができる。
性能プロファイルは、応答時間など、アプリケーションレベルまたはユーザレベルでのアプリケーションの性能に関する情報を含むことができる。
最後に、要求プロファイルは、アプリケーションの内部アクティビティを計測することができる。
アプリケーションプロファイル１１２〜１１６は、アプリケーションおよびそのコンポーネントの相対的な優先順位、性能をどのように監視すべきかに関する詳細、アプリケーションのインストールおよびコンフィギュレーションの方法に関する命令などの付加情報も含むことが可能であることが理解されるべきである。

一実施の形態では、アプリケーションは、コンテナに関連付けることができる。
コンテナは、アプリケーションまたはアプリケーションコンポーネントが存在する論理的なコンピュータであってもよい。
コンテナは、オペレーティングシステムのそれ自身のコピーを有することもできるし、オペレーティングシステム内で実施することもできる。
一例として、コンテナは、シングルアプリケーションを実行する区画されていないサーバ、ハードウェアパーティション、ソフトウェアベースのパーティション、プロセッサセット、サブＣＰＵリソースパーティション（単一のＣＰＵリソースのパーティション）、クラスタの複数のノード、または他の組もしくは他のユニットのコンピュータリソースであってもよい。

コントローラ１００は、複数のクライアントエージェント１２０、１２２、１２４からアプリケーションプロファイル１１２〜１１６の性能情報を受け取ることができる。
各クライアントエージェントは、あるリソースのオペレーティングシステムのインスタンス上で実行することができ、そのオペレーティングシステムのインスタンス上で実行されるアプリケーションの性能を監視することができる。
代替的な実施の形態では、代替的な方法によりアプリケーションプロファイルの性能情報を取得できることが理解されるべきである。

ポリシーデータ１０８も、コントローラ１００によってアクセス可能である。
このポリシーデータ１０８は、アプリケーションまたはアプリケーションコンポーネントに関連した１つまたは２つ以上の性能ポリシーを含むことができる。
一例として、アプリケーションポリシーは、アプリケーションコンポーネントの１回の遷移あたりの平均応答時間が、９５％は２秒であるというものであってもよい。
また、ポリシーデータは、リソース、アプリケーション、またはコンテナに関連した１つまたは２つ以上のリソース利用ポリシーを含むこともできる。
例えば、利用ポリシーは、コンテナまたはリソースに許容された最大利用が８０％であるというものであってもよい。
他の性能ポリシーおよびリソース利用ポリシーも考慮することができる。
さらに、いくつかの実施の形態では、これらのポリシーの１つまたは２つ以上のものに相対的な優先順位を割り当てることもできる。

コントローラ１００は、ポリシーデータに準拠しているかについてアプリケーションデータを監視する監視エージェント１０２をさらに含む。
一実施の形態では、監視エージェントは、アプリケーション性能ポリシーまたはアプリケーション利用ポリシーへの準拠を維持するか、または、回復させるために取ることができる可能な動作に関する助言情報を提供することができる。
後にさらに詳述するように、他の実施の形態では、監視エージェントは、リソースを調整して（例えば、リソースの割り当て、再割り当て、または割り当て解除を行って）、ポリシーを強制することができる。

コントローラ１００は、ドメイン定義データ１０６をさらに含む。
このドメイン定義データは、１つまたは２つ以上のドメインに関する情報を含む。
各ドメインは、１つまたは２つ以上のアプリケーションまたはアプリケーションコンポーネントによって共有される共有プールを提供するリソースをグループ化したものを含む。
これらのリソースは、１つまたは２つ以上のコンピュータやコンテナなどである。
一例として、ドメインは、ハイパーテキスト転送プロトコル（ＨＴＴＰ）サーバから構成することができる。
これらのサーバのすべては、いくつかのアプリケーションへのウェブアクセスを提供するジョブを共有できるものである。
また、ドメイン定義データは、ドメインの１つまたは２つ以上のもののリソース利用情報を含むこともできる。
一実施の形態では、監視エージェントは、ドメインリソース利用情報を監視でき、ドメインポリシーに準拠するようリソースの利用を維持するか、または、回復させるために取ることができる可能な動作に関する助言情報を提供することができる。
他の実施の形態では、監視エージェントは、リソースを動的に調整して、ドメインポリシーを強制することができる。

図１は、上述したさまざまなコンポーネントを含むコントローラ１００を示しているが、これらのコンポーネントの代替的な実施の形態を組み合わせることもできるし、代替的な実施の形態が、異なる物理的位置に存在できることも理解されるべきである。
例えば、リソースデータは、コントローラ１００によってアクセス可能なデータベースに存在することもできるし、アプリケーションデータは、別のデータベースに存在することもできる。
あるいは、ドメイン定義データ、リソースデータ、およびアプリケーションデータは、ある情報データベースに結合することもできる。

図２は、ドメイン２００、２１０、２２０へのリソースの例示のグループ化を示している。
ドメイン２００は、３つのリソース２０２、２０４、２０６を含む。
一例として、リソース２０２〜２０６は、サーバ、クラスタのノード、ラック／ブレードアーキテクチャのブレードサーバ、または他の種類のコンピュータリソースであってもよい。
ドメイン２１０は、２つのリソース２１２、２１４を含む。
これらのリソースも、サーバ、クラスタのノード、ブレードサーバ、または他の種類のコンピュータリソースであってもよい。
ドメイン２２０は、単一のリソース２２２を含む。
この単一のリソース２２２は、一例として、区画されたヒューレットパッカードスーパードーム（Hewlett Packard Superdome）コンピュータなどのネストされたリソースであってもよい。
監視エージェント１０２は、ドメインが追加のリソースを必要とする場合には、リソースドメインを拡張することができるし、ドメインが未使用の余分な容量を有する場合には、ドメインを縮小することができる。
一例として、ドメインは、キャパシティオンデマンドプロセッサ（capacity-on-demand-processor）を使用することにより、または、ステージングエリアからサーバまたはブレードを取得することにより拡張することができる。
後にさらに詳述するように、あるドメイン全体にわたってリソースをアービトレーションすることもできる（例えば、コンテナにリソースをどのように割り当てるかを決定する）。
拡張情報およびアービトレーション情報は、ポリシーデータ１０８、ドメイン定義データ１０６、または別の位置に含めることができる。

いくつかの実施の形態では、コントローラ１００は、リソースドメイン内で自動アービトレーションを行って、１つまたは２つ以上のポリシーを強制することができる。
ポリシーを強制する（３００）ために使用できる一方法を図３に示す。
前述したように、監視エージェント１０２は、ポリシーデータ１０８に準拠するように１つまたは２つ以上のアプリケーションプロファイル１１２〜１１６を監視する（３０５）。
監視エージェントが、ポリシー違反または予想されるポリシー違反を検出すると（３１０）、そのポリシーに関連した１つまたは２つ以上の動作を取って、そのポリシーを自動的に強制することができる（３１５）。
これらの動作には、より多くのリソースをドメインに追加することによるドメインの拡張、または、ドメイン内でのアービトレーションの実行が含まれ得る。
あるポリシーを強制できない場合には、ポリシーに関連した優先順位を使用して、ポリシーをアービトレーションすることができ、低い優先順位のポリシーを満たすことができない旨のメッセージをユーザに提供することができる。

ポリシーを強制するために使用できる一方法を、図４Ａ〜図４Ｄおよび図５を参照して説明することができる。
図４Ａ〜図４Ｄは、サーバの複数のパーティションへの例示の区画を示している。
リソース２２２は、複数のハードウェアパーティション３０２〜３０６に区画することができる。
ハードウェアパーティション（例えば、Hewlett PackardのｎＰａｒｓ）は、オペレーティングシステムのそれ自身のコピーを実行することができ、他のハードウェアパーティションから電気的に分離することができる。
これらのハードウェアパーティションの１つまたは２つ以上のものは、アプリケーション用のコンテナ３０４を提供することができる。

さらに、ハードウェアパーティション３０２は、プロセッサセット３１２、３１４に区画することができる。
これらのプロセッサセットの１つまたは２つ以上のものは、アプリケーション用のコンテナ３１４であってもよい。
プロセッサセットは、オペレーティングシステムの単一のコピー内で実施されるリソースパーティションであってもよく、１つまたは２つ以上のＣＰＵを含む。
さらに、ハードウェアパーティション３０６は、複数のソフトウェアベースのパーティション３２２、３２４に区画することができる。
ソフトウェアベースのパーティション（例えば、Hewlett PackardのｖＰａｒｓ）は、ソフトウェアで実施されるパーティションであってもよく、オペレーティングシステムのそれ自身のコピーを有するが、他のソフトウェアベースのパーティションから電気的に分離されていない。
これらのソフトウェアベースのパーティションの１つは、アプリケーション用のコンテナ３２４に関連付けることができる。
別のソフトウェアベースのパーティション３２２は、サブＣＰＵリソースパーティション３３２〜３３６にさらに分割されて、ＣＰＵリソースのフラクションを配分することができる。
サブＣＰＵリソースパーティションの１つまたは２つ以上のものは、それぞれ、コンテナ３３２、３３４に関連付けられて、アプリケーションを実行することができる。

アプリケーションまたはコンテナ３３２に関連したポリシーを強制するために（３１５Ａ）、リソースがそのコンテナにどのようにマッピングされるかを再割り当てすることにより、コンテナ３３２を拡張することができる（５０５）。
パーティションの１つまたは２つ以上のもののサイズを変更することにより、リソースを再割り当てすることができる。
一例として、ＣＰＵリソースのより大きな比率を含むように、コンテナ３３２を拡張することができる。
ソフトウェアベースのパーティション３３２および／またはハードウェアパーティション３０６も、サイズを変更して、コンテナ３３２またはコンテナ３３２で実行されているアプリケーションに関連した１つまたは２つ以上のポリシーを強制することができる。
同様に、サーバのさまざまなレベルで、パーティションのサイズを変更して、コンテナ３０４、３１４、３２４、３３２、３３４、またはそれらのコンテナで実行されているアプリケーションのポリシーを強制することもできるし、満たすこともできる。

ポリシーを強制する（３１５）ために使用できる代替的な方法は、図６および図７を参照して説明することができる。
図７は、クラスタから構成されるドメインを示している。
このクラスタは、２つのコンテナ７１０、７２０を含む。
これらのコンテナのそれぞれは、アプリケーションに関連付けられている。
コンテナ７１０は、ノード７１２、７１４、７１６を含む。
コンテナ７２０は、ノード７２２、７２４を含む。
一例として、コンテナ７１０は、ウェブサーバをホストすることができ、コンテナ７２０は、バッチワークロードをホストしていてもよい。
コンテナ７２０は、現在、ノード７２４を使用して、バッチワークロードを実行しているだけであってもよい。

ウェブサーバアプリケーションに関連したポリシーを強制する（３１５Ｂ）ために、監視エージェント１０２は、コンテナ７２０からコンテナ７１０にノード７２２を転送することができる。
ウェブサーバアプリケーションをノード７２２上でインスタンス化できるように、ノード７２２上で実行されているどのアプリケーションもシャットダウンすることができる。
ウェブサーバアプリケーションをインスタンス化する方法に関する命令は、そのウェブサーバアプリケーションに関連したアプリケーションプロファイル１１２に配置することができる。

上述した方法は、ハードウェアコンポーネントによって実行することもできるし、マシン実行可能命令シーケンスで具体化することもできることが理解されるべきである。
このマシン実行可能命令を使用すると、汎用プロセッサもしくは専用プロセッサ、または、それらの命令でプログラミングされた論理回路などのマシンに、図３、図５、および図６で述べた動作を実行させることができる。
あるいは、上述した方法は、ハードウェアおよびソフトウェアを組み合わせたものによって実行することができるし、マシン実行可能命令は、部分的または全体的に図１に示すコントローラ１００に組み込むことができる。

アプリケーションの性能を監視するためのシステムの一実施の形態を示す。 図１のコントローラが監視できるドメインへのリソースの例示のグループ化を示す。 図１のコントローラが使用できるポリシーを強制するための例示の方法を示すフロー図である。 複数のハードウェアパーティションであって、その１つが、図１のコントローラが監視できるアプリケーション用のコンテナである、複数のハードウェアパーティションへのサーバの例示の区画を示す。 複数のプロセッサセットであって、その１つがアプリケーション用のコンテナである、複数のプロセッサセットへの図４Ａのハードウェアパーティションの１つのさらなる例示の区画を示す。 複数のソフトウェアベースのパーティションであって、その１つがアプリケーション用のコンテナである、複数のソフトウェアベースのパーティションへの図４Ａのネットワークパーティションの１つのさらなる例示の区画を示す。 複数のサブＣＰＵリソースパーティションであって、その２つがアプリケーション用のコンテナである、複数のサブＣＰＵリソースパーティションへの図４Ｃのソフトウェアベースのパーティションの１つのさらなる例示の区画を示す。 図４Ａ〜図４Ｄのサーバのポリシーを強制するために図１のコントローラが使用できる、ポリシーを強制するための例示の方法を示すフロー図である。 クラスタドメインのポリシーを強制するために図１のコントローラが使用できる、ポリシーを強制するための例示の方法を示すフロー図である。 図１のコントローラが監視できるクラスタ環境で実施されるドメインの一実施の形態を示す。

符号の説明

１００・・・コントローラ、
１０２・・・監視エージェント、
１０４・・・リソースデータ、
１０６・・・ドメイン定義データ、
１０８・・・ポリシーデータ、
１１０・・・アプリケーションデータ、
１１２〜１１６・・・アプリケーションプロファイル、
１２０〜１２４・・・クライアントエージェント、
２００，２１０，２２０・・・ドメイン、
２０２〜２０６，２２２・・・リソース、
３０４，３１４，３２４，３３２，３３４・・・コンテナ、
３１４・・・アプリケーション用のコンテナ、
７１０，７２０・・・コンテナ、
７１２，７１４、７１６，７２２，７２４・・・ノード、

Claims (10)

1. 複数のリソースであって、該リソースには複数のコンピュータが含まれる、複数のリソースに関する情報を含むリソースデータ（１０４）と、
   １つまたは２つ以上のアプリケーションプロファイル（１１２、１１４、１１６）であって、各アプリケーションプロファイルは、性能プロファイルおよびリソースプロファイルを有し、該リソースプロファイルは、リソース利用情報を含む、１つまたは２つ以上のアプリケーションプロファイルを含むアプリケーションデータ（１１０）と、
   １つまたは２つ以上のアプリケーション性能ポリシーおよび１つまたは２つ以上のリソース利用ポリシーを含むポリシーデータ（１０８）と、
   前記ポリシーデータに準拠しているかについて前記アプリケーションデータを監視する監視エージェント（１０２）と
   を備えるシステム。
2. 前記アプリケーションの少なくとも１つは、前記コンピュータの少なくとも２つで実行される集合アプリケーション
   を含む請求項１に記載のシステム。
3. 前記監視エージェントは、さらに、前記ポリシーの１つの違反に応じて、前記コンピュータの１つまたは２つ以上をグループ化したドメイン（２００）内でアービトレーションを実行する
   請求項１または２に記載のシステム。
4. 前記監視エージェントは、さらに、ポリシー違反に応じて、前記コンピュータの１つまたは２つ以上をグループ化したドメインを拡張する
   請求項１〜３のいずれかに記載のシステム。
5. 複数のドメインであって、各ドメインが、１つまたは２つ以上のコンピュータをグループ化したものを含み、該ドメインの１つまたは２つ以上（７００）はクラスタである、複数のドメインに関する情報を含むドメイン定義データ（１０６）
   をさらに備える請求項１〜４のいずれかに記載のシステム。
6. 前記クラスタは、
   第１の組のノード（７１２〜７１６）上のアプリケーションの１組の複製インスタンスを実行する第１のコンテナ（７１０）と、
   第２の組のノード（７２２、７２４）を有する第２のコンテナ（７２０）と
   を備え、
   前記監視エージェントは、さらに、前記ポリシーの１つの違反に応じて、前記第２のコンテナから前記第１のコンテナへノードを転送する（６０５）
   請求項５に記載のシステム。
7. 前記リソースプロファイルは、アプリケーションが必要とするリソースの量に関するリソース需要情報
   をさらに含む
   請求項１〜６のいずれかに記載のシステム。
8. 前記リソース利用情報は、
   アプリケーションに現在割り当てられているリソースの量に関するリソース消費情報と、
   アプリケーションが現在使用しているリソースの量に関するリソース消費情報と、
   アプリケーションがある時間にわたって使用したリソースの量に関するリソース消費情報と
   の少なくとも１つを含む
   請求項１〜７のいずれかに記載のシステム。
9. 前記コンピュータの１つ（２２２）は、複数のコンテナ（３０４、３１４、３２４、３３２、３３４）に関連付けられ、
   各コンテナは、前記アプリケーションの１つを実行する
   請求項１〜８のいずれかに記載のシステム。
10. 前記コンテナの少なくとも１つは、パーティションであり、
    前記監視エージェントは、さらに、前記ポリシーの１つの違反に応じて、該パーティションのサイズを変更する
    請求項９に記載のシステム。

Images