JP2008033852A - リソース管理システム及びその方法 - Google Patents

Abstract

【課題】既に他の情報処理システムが稼動中である場合にも影響を与えないリソースを求め、業務サービスの継続的な実行と共有リソースを有効活用できる手段を提供すること。
【解決手段】業務アプリケーションごとに、各業務アプリケーションを実行するコンピュータシステムを識別する情報、及び各コンピュータシステムを構成するリソースの利用率を含むリソース利用率情報（４１０、４１２）を格納した記憶部と、業務アプリケーションが、新たにコンピュータシステムのリソースの使用を要求する場合に、リソース利用率情報（４１０、４１２）を用いて、変更後の当該コンピュータシステムを構成する各リソースの利用率を集計して出力する影響範囲調査部４０９と、を備えるリソース管理システム。
【選択図】図４

Description

本発明は情報処理システムのリソース管理に関し、情報処理システムのオブジェト化による仮想化の技術と情報処理システム運用管理用のポリシー制御技術を利用し、高負荷や障害が発生した場合に情報処理システムを継続実行するための対策を行うリソース管理システム及びその方法に関する。

近年、企業等における多くの業務サービスは情報処理システムを用いて行われており、情報処理システムには高い信頼性と可用性が求められている。
このような情報処理システムに想定外の過負荷、障害及び異常等のトラブルが発生した場合には、業務サービスの停止等による経済損失や、情報処理システムを利用する顧客等からの信用低下を最小限に留めるため、迅速かつ的確な対策の実施が求められる。

そのため、情報処理システムにトラブルが発生した場合には、トラブル状況の診断を行い、トラブルを回避する対処を行うためのポリシー制御処理の技術が開発されている。
一般的にはポリシー制御処理として、障害の状態であれば代替用のコンピュータシステムを割り当て、過負荷の場合にはコンピュータシステムの動的追加を行い対処する（この具体的な対処の処理をポリシーアクションと定義する）。

ここで、代替用に割り当てるコンピュータシステムが利用可能か否かを検証する検証方法として、当該コンピュータシステムが既に何らかの障害状態かどうかを検証するほかに、特許文献１及び特許文献２には、過負荷となった処理を共有するコンピュータシステムに割り当てる方法が提案されている。

なお、本発明における情報処理システムが提供する業務サービスには、例えば企業内における給与計算や販売管理等があるが、それらだけに限定されるものではなく、情報処理システムを用いて実現される様々な処理や機能等を含んでいる。例えば、Ｗｅｂ情報提供やチケット予約販売、オンライン販売等のサービスを提供するための処理や機能、あるいはサービスそのものも業務サービスに含まれる。
特開２００３−３３０８９９号公報（段落００２７〜００３０、図２） 特開２００４−３２８１５７号公報（段落００２３〜００３２、図１、図２）

企業等において利用する情報処理システムは、各ベンダーから提供され異なるアーキテクチャにより多種多様存在し、かつ、リソースはできる限り有効的に活用されることが望ましい。また、情報処理システムが提供する業務サービスは大規模化、高機能化、高信頼性化等により複雑な利用形態に合わせて１つのリソースによる構成でなく、複数のリソースを組み合わせた構成となっていることが多い。

前記した特許文献１及び特許文献２では、単一の構成による業務サービスや単一のリソースを扱うため、多階層で複数のリソースから構成される情報処理システムである場合や、さまざまな処理形態がある業務サービス（Ｗｅｂシステム、バッチ処理、ＤＢ（Data Base）、帳票出力等）を扱う場合には適用が難しいという問題点がある。
したがって、本発明の目的は、共有リソースが使える環境下において、多階層で複数のリソースから構成され、リソースを重複して利用する複数の情報処理システムのポリシー制御の中で利用するリソースに対して、既に他の情報処理システムが稼動中である場合にも影響を与えないリソースを求める手段を提供することである。

前記の課題を解決するために、本発明に係るリソース管理システムは、複数のコンピュータシステムを共有利用でき、複数のコンピュータシステムを組み合わせて実行される業務アプリケーションによりサービスを提供するシステム環境におけるリソース管理システムであって、業務アプリケーションごとに、各業務アプリケーションを実行するコンピュータシステムを識別する情報、及び各コンピュータシステムを構成するリソースの利用率を含むリソース利用率情報を格納した記憶部と、業務アプリケーションが、新たにコンピュータシステムのリソースの使用を要求する場合に、リソース利用率情報を用いて、変更後の当該コンピュータシステムを構成する各リソースの利用率を集計して出力する影響範囲調査部と、を備えることを特徴とする。
本発明の他の態様については、後記する実施の形態において詳しく説明する。

本発明によると、複数のリソースを組み合わせて業務サービスを提供する情報処理システムで、ポリシー制御の実行によるリソース確保においてすでに稼動している他のコンピュータシステムに対する影響を求めることができる。これにより、有効的にリソースの活用ができるようになり、情報処理システムの稼働率を高めることができ、情報処理システムの信頼性の向上にもつながる。

以下、本発明の実施の形態について、添付した図面を参照しつつ、詳細に説明する。

［第１実施形態］
＜システム構成例＞
本実施形態が適用されるシステムの全体構成例を図１に示す。
図１に示すように、本実施形態のシステムは、業務アプリケーションを稼働し、クライアントに対して業務サービスを提供する複数の業務サーバ１０６と、業務アプリケーションの実行制御及び業務アプリケーションのポリシー制御を行うマネージャ１０１と、マネージャ１０１に接続し業務アプリケーションの実行状況やポリシーの制御状況を参照可能なコンソール１０２と、各業務サーバ１０６を個別に監視するエージェント１０４とを含んで構成され、各構成要素は管理用ネットワーク（１０３，１０５）により接続されている。また、業務サーバ１０６は、業務ネットワーク１０７を介して業務クライアント１０８に対して業務サービスの提供を行っている。
なお、マネージャ１０１は特許請求の範囲のリソース管理システムに相当している。

業務アプリケーションを実行する業務サーバ１０６は、さまざまなＯＳ（Operating System）やコンピュータの種類に応じて多種多様で複数台存在しており、業務アプリケーションを稼働させるための条件のもとで選ばれたリソースに対して業務アプリケーションを動的に配備し、業務サービスを提供する。

なお、図１に示した構成ではエージェント１０４を複数配置し業務サーバをそれぞれ監視する構成としているが、一台のエージェント１０４のみを配置し複数の業務サーバ１０６を監視できるようにすることも可能であり、また、エージェントプログラムとして各業務サーバ１０６に配備し、業務サーバ１０６自身が監視を行うことも可能である。
また、業務サーバ１０６については、一般的にセキュリティ面を考慮して、例えば、業務サーバ１０６の一部を別の保護用のネットワークへ配置したり、業務サーバ１０６の外側のネットワークに対してファイヤーウォール等の装置を設置したりすることがあるが、本発明とはあまり関連性が無いことから省略している。

また、本実施形態では、業務サーバ１０６及び業務クライアント１０８は例として、それぞれ４台、３台となっているが、この台数に制限するものではなく、図１に示した台数よりも多く存在していてもよく、また図１に示した台数よりも少なく存在していてもよい。また、業務サーバ１０６を監視するエージェント１０４についても同様である。
また、業務ネットワーク１０７については、一般的にはＬＡＮ（Local Area Network）やＷＡＮ（Wide Area Network）等が挙げられるが、業務サーバ１０６から業務クライアント１０８に対してサービスを提供できる形態であれば特に種類を問わない。
また、マネージャ１０１については、多階層型にして、マネージャ１０１の持つ処理を分散化させることもできる。

次に、図２には図１に示したシステムの構成において、業務サービスを提供するための業務システム構成の一例を示している。例えば、業務サーバ１０６である、Ｗｅｂサーバ２０１、ＡＰ（Application）サーバ２０２、及びＤＢサーバ２０３が、図１に示した管理用ネットワーク１０５により接続されてＷｅｂ３階層アプリケーションを構成し、複数の業務サーバ１０６を組み合わせて１つのサービスを提供している。また、業務ネットワーク１０７を介して、業務クライアント１０８であるＷｅｂブラウザ２０５で業務サービスを利用することができる。
なお、図２において、参照符号２０６で示すボックスは、Ｗｅｂサーバ２０１、ＡＰサーバ２０２及びＤＢサーバ２０３の内部構成を示すブロックであり、参照符号２０７で示すボックスは、Ｗｅｂブラウザ２０５の内部構成を示すブロックである。また、図２において破線矢印を用いて、これらの関連を示している。

図２では、業務サービスを提供するＷｅｂ３階層アプリケーションを複数の業務サーバにより構成する例を挙げているが、単一の業務サーバ１０６により業務サービスを提供するシステムであってもよいし、もっと多階層からなるシステムであってもよい。
また、図２の参照符号２０６は、Ｗｅｂサーバ２０１、ＡＰサーバ２０２、及びＤＢサーバ２０３等の業務サーバ１０６の内部構成を示しており、まず、ＯＳ（Operating System）があり、その上でミドルウェアやコンテナサーバが動作し、さらにその上で業務アプリケーションが動作したり、業務用のデータを管理したりする（ただし、ＯＳ上で直接業務アプリケーションが動作する構成であってもよい）。また、図２の参照符号２０７は、Ｗｅｂブラウザ２０５（業務クライアント１０８）の内部構成を示しており、ＯＳ上でＷｅｂブラウザやクライアント専用のプログラムが動作する。

＜機器構成＞
図３には、図１に示したマネージャ１０１、エージェント１０４、業務サーバ１０６、及び業務クライアント１０８等の各装置の構成例を示す図面である。図３に示した装置３０１は、ＣＰＵ（Central Processing Unit）３０２、メモリ３０５、記憶装置３０６、ネットワークＩ／Ｆ（インタフェース）３０７、Ｉ／ＯポートＩ／Ｆ３０８を含んで構成されることを示している。また、各装置には必要に応じて、記録媒体３０３に記録された情報を読み取る記録媒体読取装置３０４、キーボード等の入力装置３０９、又はプリンタ等の出力装置３１０を備えることもできる。
各装置は、ほぼ同一の構成となるが、構成が必ずしも同一で無い場合、例えば仮想コンピュータ等においても、同じ役割をする構成が存在していればよい。また、各装置は、例えば、記憶装置３０６に格納された専用のプログラムを実行することで、各装置としての機能を実現する。

＜業務サービスの提供方法＞
本実施形態で扱うシステムは、業務アプリケーション及び業務アプリケーションのポリシー実行処理を１つのジョブとして実行し、業務アプリケーションの実行による業務サービスの提供と、業務アプリケーションの監視とトラブル発生時の対処を行い、業務アプリケーションを継続運用できるようにしたことを特徴としている。業務アプリケーションの例としてＷｅｂ３階層のＷｅｂアプリケーションシステムを挙げているが、リソース上に動的配備を行うことにより業務アプリケーションを実行できる環境であればよく、必ずしも同じでなければならないことではなく、本実施形態以外の構成による業務アプリケーションであってもかまわない。
また、本実施形態のように動的配備するシステムだけでなく、ポリシー制御により業務アプリケーションを継続実行するシステムであれば本発明は適用可能である。
なお、ポリシー実行処理の具体例については後記する。

＜マネージャ＞
図４は、本発明の実施形態に係るマネージャ１０１を構成するモジュール及びテーブルの構成例を示す図面である。また、図中の矢印は、各モジュールとテーブルの関連を示している。
マネージャ１０１が備えるモジュールとして、業務アプリケーションの実行管理を行う業務アプリケーション制御部４０３、業務アプリケーションに設定されるポリシーの実行制御を行うポリシー制御部４０４、ポリシーアクション実行時の対象となるリソースを検索するためのリソースブローカ部４０６、リソースの負荷状況の取得を行う負荷状況調査部４０８、ポリシーアクション実行時の影響を調査する影響範囲調査部４０９、ジョブ実行状況やポリシーアクションを実行の実行状況を表示する表示部４１１及び各リソースの利用状況を定期的に収集する利用率収集部４１５がある。

また、以上の各モジュールが利用するテーブルとして、業務アプリケーションを識別するためのＩＤと名称により実行中の業務アプリケーションを管理する業務オブジェクトテーブル４０２、業務アプリケーションに発生した事象と、その事象によりどのような対処処置を行うかを記述したポリシーアクション記述（対処処置をポリシーアクションと呼ぶ）を管理する業務ポリシーテーブル４０５、及びリソースをオブジェクト化しリソースを識別するためのＩＤとリソース毎の属性と属性値を管理するリソースオブジェクトテーブル４０７を備える。

さらに、業務アプリケーションを構成する業務構成オブジェクトがリソースの上で動作するときのリソース内のサブリソース（リソースを構成する「ＣＰＵ」「メモリ」等をサブリソースと定義する）毎に定義された利用率（「ユーザ定義の利用率」）、又はエージェント１０４から実際に収集した利用率（「利用率測定部による利用率」）を管理するリソース利用率テーブル４１０、業務アプリケーションと業務アプリケーションを構成する業務構成オブジェクト、さらには業務構成オブジェクトが実際に利用するリソースとの関連情報を管理する業務構成テーブル４１２、マネージャ１０１が備える各モジュールが動作を制御するため情報を管理する業務ポリシー実行パラメータテーブル４１４、及び業務アプリケーションと業務構成オブジェクトの関連情報およびその属性情報を管理する業務構成オブジェクト属性テーブル４１３がある。なお、リソース利用率テーブル４１０のサブリソースは表に定義してある項目に限定されることなく、業務アプリケーション間の指標となる項目があれば追加可能である。また、業務アプリケーションに応じて、参照する項目をあらかじめ定義しておくことも可能である。
なお、前記した各モジュールや各テーブルは、図３に示す機器構成におけるメモリ３０５や記憶装置３０６に配置され利用される。また、各テーブルの詳しい構成及びそれに格納される情報の例については、別途図を参照して後記する。また、マネージャ１０１が備える各テーブルは、特許請求の範囲の記憶部に相当している。

また、前記のテーブルのうち、業務構成テーブル４１２（図１７に示して後記）及びリソース利用率テーブル４１０は、特許請求の範囲のリソース利用率情報に相当し、業務ポリシーテーブル４０５は、特許請求の範囲のポリシー情報に相当している。

＜エージェント＞
図５は、エージェント１０４のモジュール構成例を示す図面である。
エージェント１０４は、リソースの状態変化を認識するための状態監視と状態の変化（過負荷、障害等）となったときにイベントメッセージを送信する状態監視部５０２、リソースの負荷状況を定期的に収集する利用率測定部５０３を備える。各モジュールは、図３に示す機器構成におけるメモリ３０５や記憶装置３０６に配置され利用される。エージェントにおいても制御に必要なテーブル（例えば初期設定用のテーブルや何の項目について測定中であるかを示すテーブル等）を持つ必要はあるが、本発明の本質ではないためモジュールのみの説明を行い、各モジュール固有の機能等についての説明は省略する。

＜マネージャとエージェントのインタラクション＞
図６は、マネージャ１０１とエージェント１０４とのインタラクションを示している。マネージャ１０１側は、稼働する業務アプリケーションのポリシー実行の起点となるためのトラブル兆候の状態を得る必要があるため、ポリシー制御部４０４から業務アプリケーションの状態監視の指示を状態監視部５０２に対して行い、状態に何らかの変化があった場合は、状態監視部５０２が状態変更のイベントメッセージを送信し、ポリシー制御部４０４がイベントメッセージを受け取り、ポリシー制御処理の実行を開始する。

また、ポリシー制御処理を行う際の要素として業務アプリケーション及びリソースに関する利用率を収集する必要があり、負荷状況調査部４０８及び利用率収集部４１５から利用率取得の指示を利用率測定部５０３に対して行い、エージェントにて取得した利用率情報を利用率測定部５０３から送信し、負荷状況調査部４０８及び利用率収集部４１５が受け取り、テーブルに利用率の値を格納する。テーブルに格納された利用率の値をポリシー制御処理において参照する。
なお、図６においては、状態監視部５０２がエージェント側にある構成を示しているが、マネージャ１０１側に状態監視部５０２を持ち、マネージャ１０１側から利用率を定期的に収集し、状態の変化を判定するようなポーリング型のインタラクションであってもよい。

＜影響範囲の調査方法及びポリシーアクション＞
図７は、業務アプリケーション、業務アプリケーションを構成する業務オブジェクト、及びリソースのオブジェクトモデルの関係を示した図面である。業務アプリケーションを示す参照符号７０１の「Ｇ００００００１」は、業務構成オブジェクトを示す参照符号７０２の「Ａ００００００１」、参照符号７０３の「Ａ００００００２」、参照符号７０４の「Ａ００００００３」により構成されている。参照符号７０２の「Ａ００００００１」、参照符号７０３の「Ａ００００００２」、参照符号７０４の「Ａ００００００３」は、それぞれリソースのオブジェクトを示す参照符号７０９の「Ｒ００００００１」、参照符号７１１の「Ｒ００００００２」、参照符号７１３の「Ｒ００００００３」を使用して稼動していることを矢印で示している。この関係は、図２に示した業務システムに対応させると、参照符号７０２の「Ａ００００００１」がＷｅｂサーバ２０１、参照符号７０３の「Ａ００００００２」がＡＰサーバ２０２、参照符号７０３の「Ａ００００００３」がＤＢサーバ２０３を例えてモデル化しており、１つの業務サービスを構成していることを示している。

また、別の業務アプリケーションを示す参照符号７０５の「Ｇ００００００２」は、業務構成オブジェクトを示す参照符号７０６の「Ａ００００００４」、参照符号７０７の「Ａ００００００５」、参照符号７０８の「Ａ００００００６」により構成されており、参照符号７０６の「Ａ００００００４」、参照符号７０７の「Ａ００００００５」、参照符号７０８の「Ａ００００００６」は、それぞれリソースオブジェクトである参照符号７１０の「Ｒ００００００４」、参照符号７１２の「Ｒ００００００５」、参照符号７１３の「Ｒ００００００３」を使用して稼動することを矢印で示している（本図では、業務アプリケーション「Ｇ００００００１」と「Ｇ００００００２」とでリソースを共有しているが、必ずしも「Ｇ００００００１」と「Ｇ００００００２」とは同一の性質を持つ業務サービスとは定義しない。）。
また、業務アプリケーション「Ｇ００００００１」と「Ｇ００００００２」とは、リソース「Ｒ００００００３」を共有していることを示す。これら業務アプリケーションを構成する業務構成オブジェクトは、多種多様なリソースが存在するリソースのプールの中から選ばれた（リソースブローカリング）リソースに対して動的に配備され実行するものとする。なお、業務アプリケーションと業務構成オブジェクト、業務構成オブジェクトとリソースの関係は後に記述する業務構成テーブル４１２と業務構成オブジェクト属性テーブル４１３にて情報を保持している。

図８は、図７に示す構成における影響範囲の調査方法を説明する図面である。ここでは、業務アプリケーション「Ｇ００００００１」において過負荷の現象が発生し、業務アプリケーションを継続実行するためのポリシー制御処理で、ポリシーアクション処理がまさに実行されている状況であり、ポリシー制御処理において過負荷の状況であること確認し、それに対処するポリシーアクションとして、参照符号８０１の「Ａ００００００１」には参照符号８０２に示す「Ａ００００００１」を追加し、参照符号８０３の「Ａ００００００２」には、参照符号８０４に示す「Ａ００００００２」をそれぞれ追加することにより、それまで利用していたリソースで処理しきれない処理分をスケールアウトにより負荷分散を実行しようとしていることを示している。
ここで、参照符号８０２の「Ａ００００００１」の配備・実行先がリソースをブローカリングした結果から参照符号８１０の「Ｒ００００００４」となり、参照符号８０４の「Ａ００００００２」の配備・実行先はリソースをブローカリングした結果から参照符号８１２の「Ｒ００００００５」となったこととする（矢印で関係を示している。）。

ここでのリソースのブローカリングでは利用するリソースをできるだけ共用し有効活用をはかるため、共有リソースを検索条件とする。スケールアウトによる業務アプリケーションの影響を調査するため、参照符号８１０の「Ｒ００００００４」上で動作する業務構成オブジェクトである参照符号８０６の「Ａ００００００４」のリソースの利用率と、参照符号８０２の「Ａ００００００１」の負荷分散分のリソース利用率との合算値から、スケールアウトの実行が妥当かどうかを判断する。
また、参照符号８１２の「Ｒ００００００５」上で動作する業務構成オブジェクトである参照符号８０７の「Ａ００００００５」のリソースの利用率と、参照符号８０４の「Ａ００００００２」の負荷分散分のリソース利用率との合算値から、スケールアウトの実行が妥当かどうかを判断する。

さらに、同時に業務アプリケーション「Ｇ００００００１」のポリシー制御の実行が他の業務アプリケーションへ与える影響を判断するために「Ｇ００００００２」との共有リソースである参照符号８１３の「Ｒ００００００３」の負荷状況確認も合わせて行う。各リソースにおいて、リソースを利用する業務構成オブジェクト分のリソース利用率の合算値を求め、利用率の合算値が当該リソースで処理できる範囲以上（本実施形態では１００としたが、任意に設定可能）になった場合は、既に正常に稼働している他業務へ影響があることを判断する。また、例えば、参照符号８１０の「Ｒ００００００４」、参照符号８１２の「Ｒ００００００５」のリソースが高いスペックであって、仮にスケールアウトに成功しても、参照符号８１３の「Ｒ００００００３」のリソースが必要最小限のスペックで動作していた場合において影響を及ぼすことも考えられることから、業務アプリケーション間で共有し使用するリソースに対しても影響が発生しているかどうかを利用率により判断する。

ここで、利用率は、リソースを構成するサブリソースである「ＣＰＵ」「メモリ」等、サブリソースごとに利用率の合算値を求めて判断する。例えば「Ｇ００００００１」「Ｇ００００００２」の業務アプリケーションがまったく異なる処理形態であれば、それぞれの業務アプリケーションが個別のサブリソースを利用するため、同一リソース上で並行動作しても業務アプリケーションは続行可能であり、同様の処理形態であればリソース内の同一のサブリソースを利用するため競合が発生し、共有化が難しくなることが判断できる。

ここでは例として２つの業務アプリケーションがリソースを共有するケースを挙げているが、３つ以上の業務アプリケーションがリソースを共有するシステムであってもかまわない。

＜処理の流れ＞
以下に、図４に示したマネージャ１０１における処理の流れを、各機能部の処理手順を示すフローチャートを参照しながら説明する（適宜、図４参照）。マネージャ１０１が動作する前提として、いくつかのテーブルにはあらかじめ情報が格納されている。まず、予め情報が登録されたテーブルの例を説明する。

図９は、業務オブジェクトテーブル４０２に格納された情報の例を示す図面である。図９に示した業務オブジェクトテーブル４０２には、業務アプリケーションを識別するための業務ＩＤ９０１と、それに対応する業務アプリケーションの名称９０２が格納されている。図９に示した例では、３つの業務アプリケーションを示す業務ＩＤ９０１の「Ｇ００００００１」から「Ｇ００００００３」と、それに対応する業務アプリケーションの名称９０２が格納され、現在実行されている業務アプリケーションを示している。また、この業務オブジェクトテーブル４０２には、実行する必要のあるジョブの数だけエントリが追加される。９０３にはその業務アプリケーションが提供するサービスのＳＬＯ（Service Level Object：サービスレベル目標）を格納する。ここで、ＳＬＯの内容は、ＳＬＡ（Service Level Agreement）、つまり、事業者が利用者にサービスの品質を保証する内容の項目であり、ＳＬＯの内容とＳＬＡとは対応している。９０３の項目をＳＬＡにおけるサービスレベルといった要求事項としてもよい。
なお、業務アプリケーションに関する情報を表示したい場合には名称９０２以外の属性を示す列情報を追加してもよい。

次に、図１０は、業務ポリシーテーブル４０５に格納された情報の例を示す図面である。図１０に示した業務ポリシーテーブル４０５には、業務アプリケーションを示す業務ＩＤ１００１が、事象１００２の項目に示す事象が発生したとき（きっかけは、例えばエージェントからのイベントメッセージの通知等による。）、ポリシーアクション１００３の項目に示すポリシーアクション（具体的な対処の実行方法）の情報が格納されている。１つの事象について、数パターンのポリシーアクションを優先度（本実施形態ではエントリ順）にしたがって設定できる。また、名称１００４及び説明１００５の項目には当該ポリシーを実行中である旨の表示をコンソール１０５に行う場合にポリシーアクションを識別できるための情報を格納する。

図１０に示した例では、業務の「Ｇ００００００１」のポリシーアクションが設定されている。「Ｇ００００００１」の事象として３つの事象「事象内容１」、「事象内容２」、及び「事象内容３」が挙げられ、「事象内容１」に対して優先順位が１から３までのポリシーアクションを設定し、「事象内容２」に対して優先順位が１から２までのポリシーアクションを設定し、「事象内容３」に対して優先順位が１から２までのポリシーアクションを設定している。

次に、図１１は、リソースオブジェクトテーブル４０７に格納された情報の例を示す図面である。図１１に示したリソースオブジェクトテーブル４０７には、リソースを識別するリソースＩＤ１１０１と、そのリソースの属性１１０２及びそのリソースの属性値１１０３が格納されている。図１１に示した例では、リソースＩＤ１１０１が「Ｒ００００００１」で示されるリソースと、そのリソースが持つ属性情報（属性１１０２及び属性値１１０３）を例として示している。
なお、図１１では属性として、「ＣＰＵ」、「ＣＰＵクロック数」等を示しているが、図１１で示している属性に限定されず他の属性にも設定可能である。

次に、図１２及び図１３は、リソース利用率テーブル４１０に格納された情報の例を示す図面である。図１２に示したリソース利用率テーブル４１０は、業務アプリケーションを構成する業務構成オブジェクトが、あるリソース上で動作したときのサブリソースの利用率を格納している。
このうち、参照符号１２１２で示したユーザ定義の利用率である「ユーザ見積もり利用率」１２０６には、業務構成オブジェクトがリソースを利用する場合の利用率の予想値を格納し、「日時指定のピークの利用率」１２０７には、指定した日時に利用率がある程度上昇することを見込んだ利用率の予想値を格納する。ここで、「日時指定のピークの利用率」１２０７のフォーマットの内容として、参照符号１２０１に示した例では「２００６年１０月２５日の１７：００〜２０：００に４０％の利用率であること」を示している。

また、実際にエージェント１０４から取得した利用率を示す参照符号１２１３の「利用率測定部による利用率」である「１ｈの平均利用率」１２０８には、過去１時間の稼働における利用率の平均値が格納され、「１ｄａｙ／１ｗｅｅｋの利用率」１２０９には、過去一日もしくは一週間で稼働したときの利用率の平均値が格納され、「トータル時間の利用率」１２１０には、過去に稼働したトータルの時間における利用率の平均値が格納され、最大利用率１２１１には過去に稼働したなかで最大の利用率を格納する。特に「ユーザ定義の利用率」１２１２である「ユーザ見積もり利用率」１２０６の項目と、必要に応じて「日時指定のピークの利用率」１２０７の項目とはあらかじめ設定しておく必要がある。

また、図１２に示した例では、業務アプリケーションを示す業務ＩＤ１２０２「Ｇ００００００１」を構成する業務構成ＩＤ１２０３「Ａ００００００１」と、リソースＩＤ１２０４「Ｒ００００００１」及び「Ｒ００００００４」に対応するサブリソース種別１２０５である「ＣＰＵ」、「メモリ」、「ディスク量」、「プリンタポート」、「ネットワークリソース」のそれぞれの利用率（１２０６、１２０７）を格納している。それぞれのサブリソースの利用率を設定する際には、業務アプリケーションの動作の評価時等に取得した利用率を蓄積し、この蓄積した利用率に基づいてサブリソースの利用率を設定することが望ましい（業務サービスの運用開始以降も再設定することも可能であるため、業務サービス運用において得た値を反映してもよい。）。また、ここでは「ＣＰＵ」、「メモリ」、「ディスク量」、「プリンタポート」、「ネットワークリソース」等のサブリソースを挙げているが、この項目に限定している訳ではなく他の項目があってもよい。

次に、図１４は、業務構成オブジェクト属性テーブル４１３に格納された情報の例を示す図面である。図１４に示した業務構成オブジェクト属性テーブル４１３には、業務アプリケーションを構成する業務構成オブジェクトの属性として、業務ＩＤ１４０１、業務構成オブジェクト１４０２、名称１４０３、サブリソース種別１４０４、優先サブリソース種別１４０５、リレーション情報１４０６を設定する。名称１４０３には業務構成オブジェクトの名称を格納する。サブリソース種別１４０４には、業務構成オブジェクトが利用するサブリソースで利用率の評価に用いるサブリソースを格納する。優先サブリソース種別１４０５には、リソースの利用率の評価において（例えばポリシーの自動実行等において）優先的に評価を行うサブリソースの種別を格納する。リレーション情報１４０６には、業務オブジェクトを構成する業務構成オブジェクトの関連を示している。
図１４に示した例では、業務構成オブジェクト属性テーブル４１３の一例として、業務アプリケーションを示す業務ＩＤ１４０１の「Ｇ００００００１」は、業務構成オブジェクト１４０２の「Ａ００００００１」（Ｗｅｂサーバ）、「Ａ００００００２」（ＡＰサーバ）、「Ａ００００００３」（ＤＢサーバ）により構成されていることを示す。ここで、業務ＩＤ１４０１「Ｇ００００００１」の業務構成オブジェクトは、「Ａ００００００１」−「Ａ００００００２」−「Ａ００００００３」の関連を持っていることを示している。また、「Ａ００００００１」（Ｗｅｂサーバ）の利用率の評価の対象とするリソースは「ＣＰＵ」と「メモリ」であり、このうち「ＣＰＵ」を優先的に扱うリソースであることを示している。

次に、図１５は、業務ポリシー実行パラメータテーブル４１４に格納された情報の例を示す図面である。図１５に示した業務ポリシー実行パラメータテーブル４１４には、マネージャの各モジュールが動作する際の振る舞いを変更するために、業務ＩＤ１５０１と、パラメータ情報１５０２とが格納されている。
図１５に示した例では、業務ＩＤ１５０１「Ｇ００００００１」から「Ｇ００００００３」を有する各業務アプリケーションに、業務アプリケーション独自のパラメータが設定されていることを示す。参照符号１５０３には、一例として業務ＩＤ１５０１「Ｇ００００００１」のパラメータ情報１５０２を示す。ここでは、影響範囲の調査の際に、どの利用率を参照するのか、ポリシーの実行を画面に表示するか又は表示せずに利用率が最小な値となるリソ−スを自動的に選択し処理するのか、ポリシーの実行状況を表示する場合のリソースの表示順をどのように決めるのかのルールを格納している。

次に、以上に説明した各テーブルがマネージャ１０１に格納された状態で、図４に示したマネージャ１０１の動作について説明する。
まず、図１６に示すフローチャートは業務アプリケーション制御部４０３における処理手順を示しており、業務アプリケーションの起動、停止を行う処理である。なお、１つの業務アプリケーション（ポリシー制御処理を含む）の起動を本実施例では１つのジョブとして扱うものとする。

図１６に示すフローチャートの最初の処理は、ジョブの操作待ちの状態であり（ステップ１６０１）、何らかの操作があった場合にジョブの操作内容を判断する。ジョブの開始の場合（ステップ１６０２で‘Ｙ’）は、ジョブの開始として業務アプリケーションの配備、起動を行う。また、業務アプリケーションのポリシー制御を起動するため、ポリシー制御部４０４を呼び出して、図１８に示す処理を実行する（ステップ１６０４）。

この段階で、図１７に示す業務構成テーブル４１２には、業務アプリケーションを構成する業務構成オブジェクトに関する情報として、業務ＩＤ１７１０、業務構成オブジェクト１７１１、利用するリソースＩＤ１７１２、負荷分散バランスレート１７１３が格納されている。図１７に示した例は、２つの業務アプリケーションを構成する業務構成オブジェクトの内容を示している。業務ＩＤ１７１０の項目が「Ｇ００００００１」の業務アプリケーションは、Ｗｅｂ３階層のアプリケーションを示しており、業務構成オブジェクト１７１１の「Ａ００００００１」、「Ａ００００００２」、「Ａ００００００３」から構成されており、さらには、業務構成オブジェクトが実際に利用するリソースを示す、利用するリソースＩＤ１７１２について情報も格納する。「Ａ００００００１」から「Ａ００００００３」の業務構成オブジェクト１７１１は、それぞれ「Ｒ００００００１」から「Ｒ００００００３」の利用するリソースＩＤ１７１２を有するリソースを利用していることを示している。また、負荷分散バランスレート１７１３には、例えば、ある業務構成オブジェクトが複数のリソースに跨り並行して動作する場合に処理の分散率を格納するものである。この段階ではそれぞれの業務構成オブジェクトは１つのリソースを利用しているため、負荷分散バランスレート１７１３はすべて「１００」となっている。

次に、ジョブの操作が開始ではなく（ステップ１６０２で‘Ｎ’）、ジョブの停止である場合（ステップ１６０３で‘Ｙ’）は、ジョブの停止として業務アプリケーションの停止、破棄を行う。また、業務アプリケーションのポリシー制御を停止するため、ポリシー制御部４０４に対して停止メッセージを送信する（ステップ１６０５）。
なお、本システムでは、「開始」、「停止」以外のジョブの操作が行われる場合もあり（例えばジョブの表示等、ステップ１６０６で‘Ｙ’）、その操作指示に応じた処理を行うこともできる（ステップ１６０７）が、本発明においては重要な部分ではないので詳細は省略する。
そして、一連の処理を終了後、再びステップ１６０１のジョブの操作待ち状態となる。以上、図１６に示す業務アプリケーション制御部４０３の処理は、一般的にはジョブを開始したり、又は停止したりする画面がコンソール１０２（図１参照）上に表示されユーザが利用しやすい形態となっているが、本発明においては重要な部分ではないので説明は省略する。

次に、図１８に示したフローチャートは、ポリシー制御部４０４における処理手順を示しており、業務アプリケーションのポリシーの実行制御を行う処理である。
最初の処理は、当該業務アプリケーションが異常な状態にないかを監視するため、エージェントの起動を行い（ステップ１８０１）、さらに業務アプリケーションを構成する業務構成オブジェクトのリソースの利用率を取得するため、利用率収集部４１５を呼び出す。そして、エージェント１０４からのイベントメッセージの通知、または業務アプリケーション制御部４０３からジョブの停止メッセージの通知を待つ（ステップ１８０２）。なお、本実施形態においては、エージェントからのイベントメッセージは過負荷状態のイベントメッセージ内容とする（障害イベントのケースは別途説明する）。

ここで、図１９に示したフローチャートは、利用率収集部４１５における処理手順であり、利用率収集部４１５は、ポリシー制御部４０４の呼び出しにより起動し、業務アプリケーションを構成する業務構成オブジェクトが利用するリソースのサブリソースごとの利用率を、リソース利用率テーブル４１０（図１２参照）のサブリソース種別１２０５である「ＣＰＵ」、「メモリ」、「ディスク量」、「プリンタポート」、「ネットワークリソース」について、「１ｈの平均利用率」１２０８、「１ｄａｙ／１ｗｅｅｋの利用率」１２０９、「トータル時間の利用率」１２１０、「最大利用率」１２１１の取得方法に従って、エージェント１０４を介して取得する処理を行う（ステップ１９０１）。ここではリソース利用率テーブル４１０（図１２参照）に基づいて値を取得しているが、その他の監視項目についても取得可能である。

図１８に戻って、業務アプリケーション制御部４０３からジョブの停止メッセージがあった場合は（ステップ１８０３で‘停止要求’）、エージェントを停止し、本処理を停止する（ステップ１８０５から‘Ｅｎｄ’へ）。エージェント１０４からのイベントメッセージの通知の場合は（ステップ１８０３で‘イベント受信’）、業務アプリケーションが提供するサービスのＳＬＯ（Service Level Object：サービスレベル目標）が達成されているか否かを判断する（ステップ１８０４）。
ここで、ＳＬＯが達成されている場合は（ステップ１８０４で‘Ｙ’）、イベントメッセージの通知を無視して再度、ステップ１８０２に戻って待ち状態となる。ＳＬＯが達成されていない場合は（ステップ１８０４で‘Ｎ’）、本業務アプリケーションを構成する業務構成オブジェクトが利用するリソースでの業務構成オブジェクトのリソース利用率を求めるため、負荷状況調査部４０８を呼び出す（ステップ１８０６）。

ここで、図２０に示したフローチャートは、負荷状況調査部４０８における処理手順であり、負荷状況調査部４０８は、ポリシー制御部４０４の呼び出しにより起動し、指定された業務アプリケーションの業務構成オブジェクトが利用するリソースのサブリソースごとの利用率（例えば「ＣＰＵ」、「メモリ」、「ディスク量」、「プリンタポート」、「ネットワークリソース」）を、エージェント１０４を介して取得することで、エージェント１０４から、当該リソースまたはそのリソース上の業務オブジェクトの負荷状況を取得する処理を実行する（ステップ２００１）。
なお、前記のように、負荷状況調査部４０８及び利用率収集部４１５の動作はほぼ同様であるため、１つの動作部としてもよい。このため、特許請求の範囲の「利用率収集部」は、負荷状況調査部４０８及び利用率収集部４１５に相当している。

図１８に戻って、ステップ１８０６で、負荷状況調査部４０８から得られた業務アプリケーション（業務構成オブジェクト）の詳細な負荷状況に応じて、業務ポリシーテーブル４０５（図１０参照）から実行するポリシーアクション１００３（ポリシー制御処理における具体的な対処処理）を取得し、ポリシーアクションの対象となる候補のリソースを取得するため、リソースブローカ部４０６を呼び出す（ステップ１８０７）。

ここで、図２１に示したフローチャートは、リソースブローカ部４０６における処理手順であり、リソースブローカ部４０６は、ポリシー制御部４０４の呼び出しにより起動し、ポリシーアクションの対象となるリソースを、呼び出し元の指定に従いリソースオブジェクトテーブルから検索して、決定する処理を行う（ステップ２１０１）。システムが過負荷の状況であるとすると、リソースを追加するスケールアウトによる対処と判断し、スケールアウトの対象とするリソースの条件として、リソースの有効活用を目的に他の業務アプリケーションも利用している共有リソースであることを優先的な条件とする（さらには付帯条件として検索するリソースの特定の属性値を盛り込んだ条件を木目細かに設定することも可能である。また、その内容はポリシーアクション記述に記載されているものとする。）。ここで、ポリシーアクションの対象となるリソースの数は１つと限らず２つ以上のリソースが候補として挙げられることもある。

図１８に戻って、リソースブローカ部４０６において、対象となるリソースが決定したら、ポリシーアクションの実行による他の業務アプリケーションへの影響を検証するため、影響範囲調査部４０９を呼び出す（ステップ１８０８）。なお、影響範囲調査部４０９における処理は後記する。

後記する影響範囲調査部４０９における処理において、仮にポリシーアクションの実行による影響が見られる場合は、「Ａ」に移動し第２候補以降のポリシーアクション記述を求めて、ステップ１８０６の処理から再実行する。
また、影響が見られない場合は処理を継続し、ポリシーアクションを実行する（ステップ１８０９）。そして、ＳＬＯを達成したか否かを判定する（ステップ１８１０）。
ここで、ＳＬＯが未達成である場合は（ステップ１８１０で‘Ｎ’の場合）、ステップ１８０６ないしステップ１８１０の処理を繰り返す。
一方、ＳＬＯが達成されたと判断すると（ステップ１８１０で‘Ｙ’の場合）、再びステップ１８０２のエージェントからのイベントメッセージの通知又は業務アプリケーション制御部からジョブ停止要求の通知の待ち状態となる。
ＳＬＯの達成は、ポリシーアクションを実行した業務アプリケーションだけでなく、念のためリソースを共有する業務アプリケーション側について検証してもよい。
なお、ステップ１８０９によるポリシーアクションの実行が１００％正しい処置であるならば、ポリシーアクション後における業務アプリケーションのＳＬＯ達成の検証は不要であるため、ステップ１８１０の処理を実行しないことも可能である。

ここで、正しくポリシーアクションが行われた場合、ポリシー制御部４０４は、業務構成テーブル４１２を、実行したポリシーアクションに沿って更新する。一例として図２２に、ポリシーアクションを実行する前と、実行した後で業務構成テーブル４１２に格納された情報の例を示す。参照符号２２０１で示した業務構成テーブル４１２は変更前で、参照符号２２０２で示した業務構成テーブル４１２は変更後である。
参照符号２２０２で示した業務構成テーブル４１２は、ポリシーアクションとして、「Ａ００００００１」の業務構成オブジェクトのスケールアウトによる対処が行われたため、「Ａ００００００１」が、２つのリソースを利用することになり、２つのリソース間の負荷分散バランスレート１７１３として５０％を設定していることを示している。リソースの１つは、「Ｒ００００００１」であり、もう２つは参照符号２２０３に示すようにポリシーアクションの対象としたリソースＩＤが設定される（図中では仮のリソースとして「Ｒｘｘｘｘｘｘｘ」とした）。

次に、図２３、図２４及び図２５のフローチャートは、影響範囲調査部４０９における処理手順であり、影響範囲調査部４０９は、ポリシー制御部４０４の呼び出し（図１８のステップ１８０８）により起動し、ポリシーアクションの対象となるリソースの追加により、他の業務アプリケーションに影響を与えるかどうかを調査する処理である。
まず、ポリシーアクションの対象となるリソースを利用している業務構成オブジェクトを業務構成テーブル４１２から取得する。そして、業務構成オブジェクトにより構成される業務オブジェクトを業務構成テーブル４１２から取得する。次に、業務オブジェクトを構成する業務構成オブジェクトと業務構成オブジェクトが利用するリソースを業務構成テーブル４１２から取得する（ステップ２３０１）。
つまりは、ポリシーアクションの対象となるリソース上で動作する業務アプリケーションの業務構成オブジェクトと、業務アプリケーションが使用するすべてのリソースを求める。なお、当該リソースを利用する業務構成オブジェクトが複数存在する場合は、すべての業務構成オブジェクトについて求める。

次に、ポリシーアクションによる影響範囲の特定をどのように行うかを、業務ポリシー実行パラメータテーブル４１４から求める（ステップ２３０２）。この結果、現在の負荷状況から利用率の取得を行う場合（ステップ２３０３で‘現在の負荷状態を取得’）、ステップ２３０１で取得したポリシーアクション対象のリソースにおける業務構成オブジェクトが利用するサブリソースごとの利用率を、負荷状況調査部４０８（図２０参照）を呼び出して取得する（ステップ２３０５）。対象となるサブリソースは、業務構成オブジェクトが利用するサブリソースとする。業務構成オブジェクト属性テーブル（図１４参照）で定義された業務構成オブジェクトに対応するサブリソース種別（１４０４）から求める。

一方、リソース利用率テーブル４１０から利用率の取得を行い（ステップ２３０３で‘リソース利用率テーブルから取得’）、リソース利用率テーブル４１０の「利用率測定部による利用率」１２１３（図１２参照）の項目から利用率を取得する場合（ステップ２３０４で‘Ｎ’）、ステップ２３０１で取得したポリシーアクション対象のリソースにおける業務構成オブジェクトが利用するサブリソースごとの利用率をリソース利用率テーブル４１０の「利用率測定部による利用率の項目」１２１３のうち、「１ｈの平均利用率」１２０８、「１ｄａｙ／１ｗｅｅｋの利用率」１２０９、「トータル時間の利用率」１２１０、最大利用率１２１１のいずれか、もしくはすべての項目について、業務構成オブジェクトとリソースとの組み合わせから求める。これにより、ステップ２３０１で取得した業務構成オブジェクトと、そのリソースの利用率をリソース利用率テーブル４１０から取得する（ステップ２３０６）。対象となるサブリソースは、業務構成オブジェクトが利用するサブリソースとする。業務構成オブジェクト属性テーブル（図１４参照）で定義された業務構成オブジェクトに対応するサブリソースから求める。

もしくは、リソース利用率テーブル４１０から利用率の取得を行い（ステップ２３０３で‘リソース利用率テーブルから取得’）、リソース利用率テーブル４１０の「ユーザ定義の利用率」１２１２の項目から利用率を取得する場合（ステップ２３０４で‘Ｙ’）、ステップ２３０１で取得したポリシーアクション対象のリソースにおける業務構成オブジェクトのサブリソースの利用率をリソース利用率テーブル４１０の「ユーザ定義の利用率」１２１２の項目のうち、「ユーザ見積もり利用率」１２０６、「日時指定のピークの利用率」１２０７のいずれか、もしくはすべての項目から利用率を、業務構成オブジェクトとリソースの組み合わせから求める。ただし、求めた利用率は、業務構成テーブル４１２（図１７参照）に格納された業務構成オブジェクト１７１１の負荷分散バランスレート１７１３の割合による値とする（ステップ２３０７）。このとき、対象となるサブリソースは、業務構成オブジェクトが利用するサブリソースとする。業務構成オブジェクト属性テーブル（図１４参照）で定義された業務構成オブジェクトに対応するサブリソース種別（１４０４）から求める。

次に、ステップ１８０６でのポリシーアクションを実行した業務構成オブジェクトがポリシーアクション対象となるリソースを利用した場合のサブリソースごとの利用率をリソース利用率テーブル４１０の「ユーザ見積もり利用率」１２０６から求めて（ただし、ステップ２３０２のように、業務ポリシー実行パラメータテーブル４１４（図１５参照）に振る舞いを保持し、ユーザ見積もり利用率以外の利用率から求めることも可能）、ステップ２３０５、ステップ２３０６、及びステップ２３０７で求められたサブリソースごとの利用率を足して利用率の合算値を求める（ステップ２３０８）。
ここでは一例として、業務によりリソースの中の使用する箇所が異なることを考慮してサブリソースである「ＣＰＵ」、「メモリ」、「ディスク量」、「プリンタポート」、「ネットワークリソース」について合算を行う。ただし、対象となるサブリソースは、業務構成オブジェクトが利用するサブリソースとする。業務構成オブジェクト属性テーブル（図１４参照）で定義された業務構成オブジェクトに対応するサブリソース種別（１４０４）から求める。

ここで、ステップ１８０６で求める業務構成オブジェクトのサブリソースの利用率については、ステップ１８０７で実施するポリシーアクションにおいて設定した負荷分散バランスレートの割合を適用する。例えばスケールアウトによる対処であれば、追加するリソースの数に応じて処理の負荷分散バランスレートを設定するはずであり、利用率をその負荷分散バランスレートの割合により算出する。例えば、リソース利用率テーブルのサブリソースの一つである「ＣＰＵ」に示す利用率が６０％であって、負荷分散バランスレートが５０％であれば利用率は３０％とみなす。
また、ステップ１８０７で得たポリシーアクションの対象となるリソースの候補が複数ある場合は、ステップ２３０１からステップ２３０８の処理をリソースの数分だけ実行する。このため、すべてのポリシーアクション対象のリソースについて処理をしたか否かを判定し（ステップ２３０９）、すべての処理が終了するまで、ステップ２３０１の処理に戻る。すべてのリソースにおける利用率を求めたら、「Ｂ」の処理である図２４のフローチャートへ処理を進める。

次に、図２４に示したフローチャートの最初の処理として、ポリシーアクションにおける他の業務アプリケーションへの影響確認を自動実行の指定を（ポリシーアクションまで処理するか否か）、業務ポリシー実行パラメータテーブル４１４から求める（ステップ２４０１）。ここで、ポリシーアクションまで自動的に行う場合（ステップ２４０２で‘Ｙ’）は、ステップ２３０８（図２２参照）で求めた各サブリソースの利用率の合算値が、すべて１００を超えるか否かを判断する（ステップ２４０４）。
各サブリソースの利用率の合算値がすべて１００を超える場合は（ステップ２４０４で‘Ｙ’）、図１８のポリシー制御部４０４が実行するフローチャートの「Ａ」に戻り、第２候補以降のポリシーアクションを実行する。
なお、本実施形態では、ステップ２４０４の判定で、利用率の合算値が「１００」を超えるか否かを判定したが、この値は任意に設定可能なしきい値であり、システム管理者等がシステムの安全性を考慮して決定することもできる。

また、ポリシーアクションとして複数の業務構成オブジェクトに対する処理が必要となった場合、かつステップ１８０７で複数のリソースが候補となっている場合には、各サブリソースの利用率の合算値が１００を超えていないリソースで、かつ業務構成オブジェクト属性テーブル４１３（図１４参照）の優先サブリソース種別１４０５に設定したサブリソース（例えば、Ｗｅｂサーバであれば「ＣＰＵ」を設定する等。）で、このサブリソースの利用率の合算値が最小となるリソースを最適リソースとして選択して、最適リソースの組み合わせを選択し（ステップ２４０７）、「Ｃ」の処理である図２５のフローチャートへ処理を進める。

また、ポリシーアクションを自動的に行わない場合（ステップ２４０２で‘Ｎ’）は、ポリシー実行による影響範囲の表示を、表示部４１１を呼び出して行う（ステップ２４０３）。ここで、図２６に示したフローチャートは、表示部４１１における処理手順であり、表示部４１１は、コンソール１０２に表示する情報を出力する（ステップ２６０１）。
ここで、表示部４１１が表示する内容は、第１にポリシーアクションを実行した業務アプリケーションの業務オブジェクト、業務構成オブジェクト、及び業務構成オブジェクトが利用するリソースであり、第２にポリシーアクションの対象候補となるすべてのリソースと属性、そのリソースを利用している業務アプリケーションの業務オブジェクト、業務構成オブジェクト、業務オブジェクトの属性である。第１及び第２の業務オブジェクトの表示には業務構成オブジェクト属性テーブル４１３（図１４参照）を参照して業務アプリケーションの形態を表示する。また、業務オブジェクトとリソースとの関係は、業務構成テーブル４１２（図２１参照）を参照し表示する。

さらに、表示部４１１が表示する内容は、第３に、ポリシーアクションの対象となるすべてのリソースにおけるサブリソースごとの利用率の合算値であり、第４に、第３に表示するリソースにおいて、サブリソースごとの利用率の合算値に応じた表示（例えば、１００以上で赤色、８０〜９９で黄色）である。業務構成オブジェクト属性テーブル（図１４参照）のサブリソース種別１４０４に示すサブリソースのみを表示しても良い。さらに、第５に、第２のリソースの表示において、リソースの名称等属性に依存した表示順の他に、第３に表示したリソースにおけるサブリソースごとの利用率の合算値で、業務アプリケーションの優先項目に基づいたリソース順の並べ替えや優先表示する。業務アプリケーションによっては使用するリソース（サブリソース）に偏りがあるため、あらかじめ業務構成オブジェクト属性テーブル４１３（図１４参照）の優先サブリソース種別１４０５に優先的に表示する項目を設定しておく（例えばＷｅｂサーバであれば「ＣＰＵ」を設定する等）。
なお、以上の表示例を図２７及び図２８に示し、その説明は後記する。

次に、表示と同時にポリシーアクションを実行可否の待ちとなり、ステップ２４０３における表示結果を参照した上で選択された、ポリシーアクション対象となるいずれかのリソースを選択する情報の取得待ちになる（ステップ２４０５）。そして、リソースを選択する情報を取得すると（ステップ２４０６で‘Ｙ’）、ポリシーアクションを実行するために、「Ｃ」の処理である図２５のフローチャートへ処理を進め、リソースを選択する情報を取得しない場合は（ステップ２４０６で‘Ｎ’）、図１８に示したフローチャートの「Ａ」に戻り第２候補以降のポリシーアクションを実行する。

次に、図２５に示したフローチャートにおいて最初の処理として、図２４に示したフローチャートのステップ２４０５またはステップ２４０７での処理で求められたリソースを使用する業務アプリケーションが使用するすべてのリソースと、ポリシーアクションを実行した業務アプリケーションが使用しているすべてのリソースのうち、共有しているリソースについてのサブリソースごとの利用率を求め、共有するリソースの負荷状況を求める（ステップ２５０１）。また、この求めた負荷状況を、表示部４１１を呼び出してコンソール１０２に表示することもできる。
ここで、リソースから業務オブジェクトを求めるには、これまでと同様に業務構成テーブル４１２（図２２参照）を参照し求める。また、利用率は、図１８に示したフローチャートのステップ１８０６で求めた利用率と、図２３と同様にリソース利用率テーブル４１０からそれぞれ求める。本処理はポリシーアクションの実行により共有利用しているリソースに影響がないかどうかを確認するものである。ポリシーアクションを自動的に実行しない設定を行っている場合は、表示部４１１を呼び出してコンソール１０２に、求めた利用率をコンソール１０２に表示してもよい。なお、その表示例を図３３に示し、その説明を後記する。

次に、ステップ２５０１において共通するリソースが存在し、サブリソースごとの利用率の合算値のうち１００を超えるサブリソースがあり（ステップ２５０２で‘Ｙ’）、ポリシーアクションを自動的に実行する設定の場合は（ステップ２５０３で‘Ｙ’）、図１８に示したフローチャートの「Ａ」に戻り、第２候補以降のポリシーアクションを実行し、ポリシーアクションを自動的に実行しない設定の場合は（ステップ２５０３で‘Ｎ’）、ポリシーアクションが現在の設定では正しく行われない旨の警告メッセージを、表示部４１１を呼び出して表示する（ステップ２５０４）。そして、第２候補以降のポリシーアクションを実行するか否かを判断し（ステップ２５０５）、第２候補以降のポリシーアクションを実行する場合は、図１８に示したフローチャートの「Ａ」に戻り、実行しない場合は図２４の「Ｄ」の処理へ進み、ポリシーアクション対象のリソースの選択をやり直す。

そして、ステップ２５０１で得たリソースの利用率の合算値が１００を超えるリソースが無い場合（ステップ２５０２で‘Ｎ’）、図１８に示したフローチャートのステップ１８０９に戻りポリシーアクションの実行を行う。

＜日時指定の利用率による評価＞
図１２に示すリソース利用率テーブル４１０において、「日時指定のピークの利用率」１２０７の列として日時指定の利用率を設定するようにしてあり、設定される内容を参照符号１２０１に一例として示している。ここでは、ある日時、ある曜日、期間、もしくはある時間帯において、高い利用率で利用することを示している。ここで示すフォーマットは一例であり、例えばセパレータ記号の種別により、複数の期間や時間を設定することも可能である。したがって当該業務システムがそのリソースを利用する時間帯に合わせて評価する。時間帯がテーブル内の時間帯に重なる場合には、テーブルに設定された利用率を適用する。時間帯が合わない場合には利用率を０％として扱う。
また、将来的な利用率の評価の方法として、当該業務アプリケーションが将来的に高い利用率でサブリソースを使用することが分かっている場合は、その将来の高利用率での時間帯とテーブル中にある日時指定の時間帯と一致するかどうかを判断した上で利用率の合算による評価を行い、当該リソースの利用を判断することもできる。

＜画面表示例＞
図２７に、図２３に示したフローチャート２３０３の処理における画面の表示例を示す。参照符号２７０１で示す画面では、「業務１」の業務アプリケーションで過負荷の状態を検知しスケールアウトのポリシーを実行しようとしている状況である。
図２７を参照して、「業務１」２７０２を構成する業務構成オブジェクトとして「Ｗｅｂ ｓｅｒｖｅｒ」２７０３、「ＡＰ ｓｅｒｖｅｒ」２７０４、及び「ＤＢ ｓｅｒｖｅｒ」２７０５のアイコンがあり、参照符号２７０１に示す画面の左側に示されている。この左側の部分には、業務を構成する業務構成オブジェクトの一覧を表示する。さらに、ポリシーアクションが必要な業務構成オブジェクトには強調表示し分かりやすいように表示する（図２７では、「Ｗｅｂ Ｓｅｒｖｅｒ」２７０３と「ＡＰ Ｓｅｒｖｅｒ」２７０４とを強調表示している）。

また、参照符号２７０１で示す画面の右側には追加対象の候補であるリソース一覧のアイコンを示している。ここでは、「業務１」を構成する「Ｗｅｂ ｓｅｒｖｅｒ」２７０３及び「ＡＰ ｓｅｒｖｅｒ」２７０４について、それぞれスケールアウトを試みようとしており、「Ｗｅｂ ｓｅｒｖｅｒ」２７０３には「ＣｏｍｐｕｔｅｒＡ」２７０６、「ＣｏｍｐｕｔｅｒＢ」２７０７、「ＣｏｍｐｕｔｅｒＣ」２６０８が追加の候補、「ＡＰ ｓｅｒｖｅｒ」２７０４には、「ＣｏｍｐｕｔｅｒＤ」２７０９、「ＣｏｍｐｕｔｅｒＥ」２７１０が追加対象の候補であることを示している。

参照符号２７０１で示す画面において、リソース（例えば、２７０６、２７０７、２７０８）は、業務構成オブジェクトごとに設定された優先サブリソース種別（「ＣＰＵ」「メモリ」「ディスク」等）の利用率の合算値が低い順番に左から右へ並べられる。これは、業務の安定稼働を考慮し利用率の合算値が低いリソースを優先的に表示し、左のソースほど最適リソースであることを示している。
また、サブリソースの利用率の合算値が１００を超えている場合、又は１００に近い値の場合にはアイコンそのものを赤色表示や黄色表示、もしくはアイコンの形状を変更する形にしてもよい。
また、表示順はリソースオブジェクトテーブル４０７（図１１参照）から参照可能なリソースの持つ何らかの属性に従って変更することも可能である（業務ポリシー実行パラメータテーブル４１４（図１５参照）に表示順を設定しておく）。

そして、参照符号２７０１で示す画面において、リソースを示すアイコン（２７０６、２７０７、２７０８、２７０９、２７１０）のいずれか１つを選択（マウスクリック）することで、ポリシーアクション対象のリソースを選択することになる。
例えば、「Ｗｅｂ Ｓｅｒｖｅｒ」２７０３の場合は、「ＣｏｍｐｕｔｅｒＡ」２６０６から「ＣｏｍｐｕｔｅｒＣ」２７０８のリソースのいずれかを、「ＡＰ ｓｅｒｖｅｒ」２７０４の場合は、「ＣｏｍｐｕｔｅｒＤ」２７０９または「ＣｏｍｐｕｔｅｒＥ」２７１０のいずれかを選択する。画面の下部には次の制御を行うための「リソースを選択し次へ」ボタン２７１１と別のポリシーを選択する「別のポリシーを選択」ボタン２７１２とを配置していることを示している。ポリシーアクション対象のリソースを選択し、次の処理へ移行する場合は、「リソースを選択し次へ」ボタン２７１１を選択し、別のポリシーにより実行を行う場合は、「別のポリシーを選択」ボタン２７１２を選択する。

次に、図２８は、図２７に示した画面２７０１において、業務構成オブジェクトを示すアイコンやポリシーアクション対象のリソースのアイコンに対応した詳細情報をポップアップさせる画面例である。
図２８に示した画面２８０１において、例えば、業務構成オブジェクトである「Ｗｅｂ Ｓｅｒｖｅｒ」からは、参照符号２８０２で示すように、オブジェクトの持つ属性情報や業務構成オブジェクトが使用するリソースやそのリソースの属性を表示することができることを示している。また、リソースのアイコンである「Ｃｏｍｐｕｔｅｒ Ｄ」からは、参照符号２８０３で示すように、利用率の合算値の内訳としてサブリソースごとの利用率の合算値を表示できること、リソースの属性情報、リソースを使用する業務構成オブジェクトと業務オブジェクトの構成情報、表示順の変更を指示できることを示している。
これらをポップアップさせる契機は、例えば、アイコンをマウスの右クリック等で、表示可能なメニューを表示し、メニューを選択することにより、ポップアップ表示する。
また、さらに詳細な情報を、他のポップアップウィンドウ等により表示することもできる（その一例として、利用率の内訳のポップアップ画面を図３３に挙げ、その説明を後記する）。

図２９は、図２７または図２８で選択されたポリシーアクション対象のリソースを使用する業務アプリケーションと、ポリシーアクションを実行した業務アプリケーションで共有するリソースについて利用率を表示する画面を示している。
図２９に示した画面２９０１では、共有するリソースを使用している業務構成オブジェクトを、左側の業務構成オブジェクトのアイコンを強調表示することで示し、共有利用するリソースを右側のリソースのアイコンで表示していることを示している。例えば、「業務１」２９０２の実行中のポリシーの名称と構成する業務構成オブジェクトとして、「Ｗｅｂ ｓｅｒｖｅｒ」２９０３、「ＡＰ ｓｅｒｖｅｒ」２９０４、及び「ＤＢ ｓｅｒｖｅｒ」２９０５のアイコンがあり、画面２９０１の左側に表示している。ここで、共有リソースを利用する業務構成オブジェクトとして「ＤＢ ｓｅｒｖｅｒ」２９０５を強調表示している。

また、画面２９０１の右側にはポリシーアクション対象としたリソースとして「Ｃｏｍｐｕｔｅｒ Ａ」２９０６及び「Ｃｏｍｐｕｔｅｒ Ｂ」２９０７を強調表示し、対象外のリソースは薄く表示している（図２９では破線で囲って示した「Ｃｏｍｐｕｔｅｒ Ｂ」、「Ｃｏｍｐｕｔｅｒ Ｃ」及び「Ｃｏｍｐｕｔｅｒ Ｅ」が該当する）。また、共有するリソースとして「Ｃｏｍｐｕｔｅｒ Ｆ」２９０８が新たに表示されたことを示している。
さらに、画面２９０１の下部には、次の制御を行うための「ポリシーアクションの実行」ボタン２９０９と別のポリシーを選択する「別のポリシーを選択」ボタン２９１０とを配置していることを示している。ポリシーアクションを実行する場合は「ポリシーアクションの実行」ボタン２９０９を選択し、別のポリシーにより実行を行う場合は「別のポリシーを選択」ボタン２９１０を選択する。本画面２９０１においても、図２８に示した画面２８０１と同様に、各アイコンを右クリックによるメニューから属性等の表示を行うことができる。以上、図２７ないし図２９に示したように、本実施形態の表示画面（２７０１、２８０１、２９０１）により、共有リソースの利用率を確認の上で次の処理へ進むことができる。

＜運用の具体例＞
ポリシーアクションとしてスケールアウトによる負荷分散を行ったときの実際の運用例を以下に記載する。
図７に示すような業務アプリケーションを示すモデル「Ｇ００００００１」があり、「Ａ００００００１」７０２、「Ａ００００００２」７０３、「Ａ００００００３」７０４の業務構成オブジェクトで構成されており、これらの業務構成オブジェクトは、図１４に示した業務構成オブジェクト属性テーブル４１３の業務ＩＤ１４０１が「Ｇ００００００１」の３つのエントリに示すように、Ｗｅｂ３階層の業務アプリケーションを構成しているものとする。この業務アプリケーションを、図１６に示したフローチャートに従ってジョブの実行を行った場合に、ステップ１６０１、ステップ１６０２、及びステップ１６０４の処理の順序でジョブとして実行される。このときの、業務構成オブジェクトの配備、実行先も、図１７に示した業務構成テーブル４１２の業務ＩＤ１７１０が「Ｇ００００００１」である３つのエントリに示すとおり、参照符号１７１４で示した「Ａ００００００１」の業務構成オブジェクトが「Ｒ００００００１」のリソースに、参照符号１７１５で示した「Ａ００００００２」の業務構成オブジェクトが「Ｒ００００００２」のリソースに、参照符号１７１６の「Ａ００００００３」の業務構成オブジェクトが「Ｒ００００００３」のリソースに行われているものとする。

続いて、図１８に示したフローチャートに従って、ポリシー制御が実行され、ステップ１８０１、ステップ１８０２の処理の順序でエージェントに対して、業務アプリケーションの状態変更の監視と業務構成オブジェクトごとにサブリソースの利用率の取得が行われる。しばらくして過負荷の状態が発生すると、エージェントからのイベントメッセージを受け取る（ステップ１８０３）。そのイベントメッセージから、ステップ１８０４においては業務のＳＬＯを維持できない状態であることが判明し、ステップ１８０６の処理として、「Ａ００００００１」、「Ａ００００００２」、「Ａ００００００３」の業務構成オブジェクトが利用するリソースの利用率を求める。

また、ステップ１８０７の処理として過負荷が発生している状況と、ステップ１８０６で得たリソース（サブリソース）の利用率から、実行するポリシーを図１０に示した業務ポリシーテーブル４０５から取得する。このとき取得したポリシーの記述内容は、業務構成オブジェクト「Ａ００００００１」のスケールアウトの実行であることとし、その実行対照となる候補のリソースを、リソースブローカ部４０６を呼び出し求める。ここでは、業務構成オブジェクト「Ａ００００００１」に対して、「Ｒ００００００７」及び「Ｒ０００００１０」の２つのリソースが候補として得られたこととする（ちなみに過負荷の状態によっては。業務構成オブジェクトの「Ａ００００００２」、「Ａ００００００３」に対しても当然ながらスケールアウトのポリシー制御を実行できる）。

次に、１つ以上の得られたリソースの候補について、ステップ１８０８の処理として、ポリシーアクションにおける影響範囲調査を行うために、影響範囲調査部４０９を呼び出して、図２３ないし図２５に示した処理を実行させる。
まず、図２３に示したフローチャートのステップ２３０１の処理として、リソース「Ｒ００００００７」、「Ｒ０００００１０」を使用する業務構成オブジェクトを求める。そのため、「Ｒ００００００７」、「Ｒ０００００１０」をキーとして、業務構成テーブル４１２（図２２参照）を検索する。結果、業務構成オブジェクト「Ａ００００００８」、「Ａ０００００１２」がそれぞれ得られることになる。また、同時にその業務オブジェクトが利用するすべてのリソースも求める。
ここでは、ステップ２３０２、ステップ２３０３、ステップ２３０４の処理の流れで、図１２に示したリソース利用率テーブル４１０の「１ｈの平均利用率値」１５０８を用いて影響範囲調査を行うこととし、ステップ２３０６の処理として「Ｒ００００００７」及び「Ａ００００００８」と、「Ｒ０００００１０」及び「Ａ０００００１２」との組み合わせで、リソース利用率テーブルよりサブリソースごとの利用率の取得を行う。

ここで、図３０及び図３１は、リソース利用率テーブル４１０の他の例を示す図面である。この図３０及び図３１に示したリソース利用率テーブル４１０において、「Ｒ００００００７」及び「Ａ００００００８」の利用率は、参照符号３１０１に示す部分であり、「Ｒ０００００１０」及び「Ａ０００００１２」の利用率は、参照符号３１０２に示す部分から求められる。続いて、ステップ２３０８の処理として、ポリシーアクションを実行した業務アプリケーションの「Ａ００００００１」が、「Ｒ００００００７」及び「Ｒ０００００１０」で動作するときのサブリソースごとの利用率を、リソース利用率テーブル４１０から取得し、ポリシーアクションにおける負荷分散バランスレートを仮に５０％として求める（小数以下は四捨五入とする）。対象となるサブリソースは、業務構成オブジェクト属性テーブル（図１４）に示すサブリソース種別にて定義されるが、本例においては「ＣＰＵ」、「メモリ」、「ディスク量」、「プリンタポート」、「ネットワークリソース」が定義されているものとする。

図３０における「Ｒ００００００７」の場合は、参照符号３００１に示す部分になり、「ＣＰＵ」は１５％、「メモリ」は１０％、「ディスク量」は３％、「プリンタポート」は０％、「ネットワークリソース」は５％と算出でき、「Ｒ０００００１０」の場合は、参照符号３００２に示す部分になり、「ＣＰＵ」は２５％、「メモリ」は１５％、「ディスク量」は５％、「プリンタポート」は０％、「ネットワークリソース」は１０％と算出できる。
この結果、「Ｒ００００００７」の場合は、図３０の参照符号３００１で示す領域と、図３１の参照符号３１０１で示す領域とから利用率の合算値を取得でき、「Ｒ０００００１０」の場合は、図３０の参照符号３００２で示す領域と図３１の参照符号３１０２で示す領域とから利用率の合算値を取得できる。説明の都合上、「Ｒ００００００７」、「Ｒ０００００１０」を合わせて説明したが、実際は、ステップ２３０１からステップ２３０８について、リソースごとに個別に処理を行っている。

次に、前記のように取得したサブリソースごとの利用率の合算値を元に、図２４に示したフローチャートのステップ２４０３において表示を行う。例として図３２に実行結果を示す。図３２に示した画面３２０１では、「Ｗｅｂ Ｓｅｒｖｅｒ」３２０２のポリシー実行の対象リソースとして、「Ｒ００００００７」３２０３か、「Ｒ０００００１０」３２０４のいずれかのリソースを利用率の結果から選択し、ポリシーアクションの実行を行う。また、合算したサブリソースごとの利用率のうち、値が１００％を超える場合は、そのリソースの選択はできない。例えば、「Ｒ０００００１０」及び「Ａ０００００１２」の組み合わせにおいて、サブリソースの「ＣＰＵ」の利用率が７０％以上になった場合に、「ＣＰＵ」の利用率の合算値が１００％を超えるため、画面３２０１において「Ｒ０００００１０」３２０４を選択することはできなくなる。
ここで、図３３には、図３２に示した「Ｒ００００００７」３２０３のリソースの利用率の合算値を表示した画面例を示している。

次に、ポリシーアクションの実行を自動で行う場合のステップ２４０７（図２４参照）の処理においては、業務構成オブジェクト属性テーブル４１３（図１４参照）の優先サブリソース種別１４０５を業務構成オブジェクトの性質に合わせてあらかじめ設定しておけば、そのサブリソース種別の利用率の合算値から優先とするポリシー実行対象のリソースを自動的に求めることもできる（サブリソースごとの利用率が１００％を超えてなく、指定したサブリソースの種別のうち、最小の利用率の合算値となるリソースを選択）。

次に、ステップ２５０１（図２５参照）の処理としてポリシーアクション対象のリソースを利用する業務アプリケーションが利用する他のリソースと、業務構成オブジェクト「Ａ００００００１」以外の「Ａ００００００２」や「Ａ００００００３」等が利用するリソースのうち、共有するリソースについてサブリソースごとの利用率を評価する。そして、ポリシーアクションを実際に行った後には、業務構成テーブル４１２の更新を行う（その例を図２２に示す。）。本実施形態では「Ａ００００００１」の業務構成オブジェクトのみをポリシーアクションの対象としたが、「Ａ００００００２」や「Ａ００００００３」等の業務構成オブジェクトも対象とすることができ、「Ａ００００００２」や「Ａ００００００３」等の業務構成オブジェクトに対して、複数のポリシーアクションの対象となるリソースの候補があった場合でも、これまでの説明のとおり、サブリソースごとの利用率の合算値を求めることができ、影響度を判断することができる。

以上、説明した本実施形態によると、複数のリソース構成からなる業務システムにおいて、ポリシー実行対象となるリソースを選択する際に同時に稼働している他の業務アプリケーションに影響を与えることないリソースを容易に選択するための情報を提供できるようになる。また、他の業務に影響を与えることないリソースを自動的に求めることもでき、自動的にポリシー制御を実行することもできる。
さらに、１つのリソースを構成するサブリソースごとの利用率を評価することにより、処理実行形態が異なる業務間でのリソース共有についても正確に影響を評価することが可能となる。
これにより、業務サービスの信頼性の向上及び稼働率向上を図ることができる。

なお、本実施形態では、リソースとサブリソースの関係を、コンピュータシステムとコンピュータシステムを構成する「ＣＰＵ」や「メモリ」等とに適用したが、例えばリソースを扱う単位として、「データセンター」と「コンピュータリソース」、「ブレードサーバ」と「コンピュータリソース」等にも応用することができる。

以下に、第１実施形態の変更例を説明する。以下に示す変更例において、主要な構成は第１実施形態と同様であるため、その詳細な説明は省略する。また、図１ないし図２６を適宜参照のこと。

［第２実施形態］
第２実施形態は、第１実施形態以外の他のトラブル現象におけるポリシー制御による実施形態である。
第１実施形態では、過負荷の状態によるスケールアウトを例にしたが、ポリシー制御実施には障害代替によるリソース入れ替えのポリシー制御もあり、第１実施形態に、４つの改造を施すことで具現できる。
第１、に状態変更のイベントメッセージに障害状態になった旨の情報を設定する。第２に、図１８に示したフローチャートのステップ１８０６において業務アプリケーションを構成する業務構成オブジェクトのどの部分が障害の状態になっているかを求める。第３に、同じくステップ１８０７におけるポリシーアクションの選択においては障害代替のポリシーアクションが選択されることになり、サブリソースの利用率を求める際には業務構成テーブル４１２（図２２参照）の業務構成オブジェクトにおける参照符号２２１３で示す負荷分散バランスレートを適用する。第４に、業務構成テーブル４１２の更新は、元々利用していたリソースのエントリを削除して障害代替のリソースをエントリする。
これにより、様々な事象に対処するポリシー制御技術に本発明を適用することが可能となる。

［第３実施形態］
第３実施形態は、リソース利用率テーブルの参照の自動切り替えを行う実施形態である。
第１実施形態では、リソース利用率テーブル４１０（図１２、図３０、図３１参照）の参照方法を、あらかじめ業務アプリケーションごとに設定したパラメータにより選択するようにしていた。ここで、リソース利用率テーブル４１０では、ユーザがあらかじめ設定した利用率と実際に測定した利用率の両方を保持している。実際の業務において、業務運用の初期段階においては実際に測定した利用率が正しく入っていないことも考えられる。そのため、最初はユーザが設定した利用率を割り当て、運用がある程度順調に行われ信頼できる実績値として実際に測定した利用率が使えるようになったら、それを利用できるようにする。

そのためには、業務アプリケーションごとに設定する業務ポリシー実行パラメータテーブル４１４（図１５参照）に、例えば、業務の累積した運用時間と合わせて、図１２に示したリソース利用率テーブル４１０の「ユーザ定義の利用率」１２１２と「利用率測定部による利用率」１２１３とを切り替える設定ができるようにし、この設定を切り替える処理を、図２３に示したフローチャートのステップ２３０２以降に設定することで具現できる。
また、業務アプリケーションが実行した累積の運用時間を業務オブジェクトテーブル４０２（図９参照）や業務構成オブジェクト属性テーブル４１３（図１４参照）に１つの属性として保持する。この方法をとることにより、実際の運用形態により近い利用率の適用が可能となる。

［第４実施形態］
第４実施形態は、リソース利用率テーブルの自動更新を行う実施形態である。
第１実施形態では、実際のリソースを示すリソースオブジェクトの何らかの属性に変更が生じたときに、リソースオブジェクトテーブル４０７（図１１参照）及びリソース利用率テーブル４１０（図１２参照）の利用率の情報を自動的にアップデートする。
図１に示したマネージャ１０１とエージェント１０４とを常時接続するようにし、業務サーバ１０６のリソースの構成変更が生じた場合に、エージェントからマネージャにイベントメッセージを通知し、リソースオブジェクトテーブル４０７の属性１１０２や属性値１１０３及びリソース利用率テーブル４１０の利用率を更新する。例えば、サブリソースの「ＣＰＵ」におけるＣＰＵチップのアップグレード交換等の構成変更での利用率の変更は難しい（性能の比較テーブル等を設置すれば可能である）が、サブリソースの「メモリ」や「ディスク量」等容量をアップグレードする構成変更の場合は変更に比例して利用率の更新が可能である。これにより、ユーザがコンピュータのメンテナンスを実施した際にもリソースオブジェクトテーブル４０７及びリソース利用率テーブル４１０の両方を手動でメンテナンスする必要がなくなり、運用の手間が軽減される。

［第５実施形態］
第５実施形態は、ジョブ実行時（業務アプリケーションの配備）において本発明を適用する実施形態である。
第１実施形態では、ポリシーアクションを実行した際の対象となるリソースについて他業務への影響を調査したが、ジョブ実行時のリソースの確保においても、本発明を適用することができる。
第１実施形態ではポリシーアクションを実行した時点での実際の利用率をもとに影響度を判定する手順を有しているが、リソース利用率テーブル４１０（図１２参照）での「ユーザ定義の利用率」１２１２の「ユーザ見積もり利用率」１２０６を用いることにより、ジョブを配備する際のリソースの決定時においても、他業務アプリケーションへの影響を判断することができる。これにより、ジョブ配備時にも、リソースの有効活用のための検証手段を与えることができる。

［第６実施形態］
第６実施形態は、ポリシーアクションとしてスケールアウトを実行する場合の負荷分散バランスレートの調整による利用率の合算値を調整する実施形態である。
第１実施形態では、スケールアウトのポリシーアクションにおいて、負荷分散バランスレートに基づいてサブリソースの利用率の算出を行っている。負荷分散バランスレートの比率によっては、サブリソースごとの利用率の合算の結果に影響があり、ポリシーアクションを実行できる可能性が生じる。
そのため、図２４に示したフローチャートのステップ２４０３で、ポリシーアクションの対象となっているリソースのうち、サブリソースごとの利用率の合算値が１００％を超えているものについて、ユーザの指示（例えば画面のボタン選択のタイミング）により、合算値が１００％以上にならないよう、ポリシーアクション対象のリソースへの負荷分散バランスレートを徐々に下げていき最適な負荷分散バランスレートを求める。そして、最適な負荷分散バランスレートを画面上に表示し、ユーザの確認を得たのち、図１８に示したフローチャートのステップ１８０９のポリシーアクション処理に得た負荷分散バランスレートをフィードバックする。
これにより、ポリシーアクションによる業務サービスの継続ができる手段を提供することができ、稼働率の向上につながる。

［第７実施形態］
第１実施形態では、業務構成オブジェクト属性テーブル４１３（図１４参照）に、優先サブリソース種別１４０５を設定し、図２４に示したフローチャートのステップ２４０７では優先サブリソース種別の利用率の合算値に基づいて、ポリシーアクションにおける追加するリソースの決定を行った。
業務種別が異なっていれば、主に利用するサブリソースも異なってくる考え方から、ステップ２４０７の処理で優先サブリソース種別の他に、異なる業務アプリケーションまたは異なる業務の業務構成オブジェクトが利用するリソースを選択することを、優先度を決めるもう１つの目安とする。
このためには、業務オブジェクトテーブル４０２（図９参照）、業務構成オブジェクト属性テーブル４１３（図１４参照）に業務の処理形態を示す属性情報を設定し、ステップ２４０７におけるリソースの決定処理や、ステップ２４０３におけるリソースの表示順において属性を参照することで可能となる。以上のことも、ポリシーアクションによる業務サービスの継続ができる手段のひとつであり、業務サービスの稼働率の向上につながる。

［第８実施形態］
これまでは、ポリシーアクションの対象とするコンピュータシステムを選択する際にはコンピュータシステムを構成する各リソースの利用率の合算値から評価を行った。第８実施形態は、これに合わせて、対象となるコンピュータシステムの上で動作する業務アプリケーションのシステムのネットワーク形態も評価の対象とする。ネットワークの形態は、業務構成テーブルから求めることができる。例えば、ポリシーアクションの対象が複数あった場合に、負荷分散を目的に多重化しているコンピュータシステムを選択することで、共有先となる業務アプリケーションに対する影響をより少なくすることができる。システムが多重化している状態かどうかは、業務構成テーブルの業務構成オブジェクトの列を参照し、同一の業務構成オブジェクトが存在することで確認できる。本処理は、影響範囲調査部４０９に位置し、図２３に示すフローチャートの２３０８の後に処理を追加することで実施可能となる。

システムの全体構成例を示す図面である。 業務システムの構成例を示す図面である。 システムを構成する機器の構成例を示す図面である。 マネージャのモジュール構成例を示す図面である。 エージェントのモジュール構成例を示す図面である。 マネージャとエージェントとのインタラクションを説明する図面である。 業務アプリケーション、業務オブジェクト、及びリソースの関係を示す図面である。 図７に示す構成における影響範囲の調査方法を説明する図面である 業務オブジェクトテーブルに格納された情報の例を示す図面である。 業務ポリシーテーブルに格納された情報の例を示す図面である。 リソースオブジェクトテーブルに格納された情報の例を示す図面である。 リソース利用率テーブルに格納された情報の例を示す図面である。 リソース利用率テーブルに格納された情報の例を示す図面である。 業務構成オブジェクト属性テーブルに格納された情報の例を示す図面である。 業務ポリシー実行パラメータテーブルに格納された情報の例を示す図面である。 業務アプリケーション制御部における処理手順を示すフローチャートである。 業務構成テーブルに格納された情報の例を示す図面である。 ポリシー制御部における処理手順を示フローチャートである。 利用率収集部における処理手順を示フローチャートである。 負荷状況調査部における処理手順を示すフローチャートである。 リソースブローカ部における処理手順を示すフローチャートである。 ポリシーアクションを実行する前と実行した後とに業務構成テーブルに格納された情報の例を示す図面 影響範囲調査部における処理手順を示すフローチャートである。 影響範囲調査部における処理手順を示すフローチャートである。 影響範囲調査部における処理手順を示すフローチャートである。 表示部における処理手順を示すフローチャートである。 表示部が表示する画面表示例を示す図面である。 表示部が表示する画面表示例を示す図面である。 表示部が表示する画面表示例を示す図面である。 リソース利用率テーブルに格納された情報の他の例を示す図面である。 リソース利用率テーブルに格納された情報の他の例を示す図面である。 表示部が表示する画面表示例を示す図面である。 表示部が表示する画面表示例を示す図面である。

符号の説明

１０１ マネージャ
１０３，１０５ 管理用ネットワーク
１０４ エージェント
１０６ 業務サーバ
１０７ 業務ネットワーク
４０２ 業務オブジェクトテーブル
４０３ 業務アプリケーション制御部
４０４ ポリシー制御部
４０５ 業務ポリシーテーブル
４０６ リソースブローカ部
４０７ リソースオブジェクトテーブル
４０８ 負荷状況調査部
４０９ 影響範囲調査部
４１０ リソース利用率テーブル
４１１ 業務構成テーブル
４１２ 業務構成オブジェクト属性テーブル
４１３ 業務構成テーブル
４１４ 業務ポリシー実行パラメータファイル
４１５ 利用率収集部
５０２ 状態監視部
５０３ 利用率測定部

Claims (16)

1. 複数のコンピュータシステムを共有利用でき、前記複数のコンピュータシステムを組み合わせて実行される業務アプリケーションによってサービスを提供するシステム環境におけるリソース管理システムであって、
   前記業務アプリケーションごとに、各業務アプリケーションを実行する前記コンピュータシステムを識別する情報、及び各コンピュータシステムを構成するリソースの利用率を含むリソース利用率情報を格納した記憶部と、
   前記業務アプリケーションが、新たに前記コンピュータシステムのリソースの使用を要求する情報を取得すると、前記リソース利用率情報から前記業務アプリケーションが要求するリソースの利用率を取得し、
   変更後の当該コンピュータシステムを構成するリソースの利用率を集計する影響範囲調査部と、
   を備えることを特徴とするリソース管理システム。
2. 前記記憶部に、前記業務アプリケーションに対する前記コンピュータシステムの各リソースの割り当ての変更を規定する情報であるポリシーアクションを含むポリシー情報をさらに格納し、
   前記ポリシー情報に含まれる前記ポリシーアクションに基づいて、前記業務アプリケーションが新たに前記コンピュータシステムのリソースの使用を要求する場合に、当該コンピュータシステムの各リソースの利用率を、前記影響範囲調査部に問い合わせ、前記影響範囲調査部が出力した当該コンピュータシステムの各リソースの利用率が、所定のしきい値以下であり、ＳＬＡの要求が満たされる場合に、前記ポリシーアクションに基づいて各リソースの割り当てを変更するポリシー制御部をさらに備えること、
   を特徴とする請求項１に記載のリソース管理システム。
3. 前記ポリシー制御部は、
   各リソースの割り当てを変更すると、当該ポリシーアクションに基づいて、前記リソース利用率情報に含まれる各業務アプリケーションを実行する前記コンピュータシステムを識別する情報を更新すること、
   を特徴とする請求項２に記載のリソース管理システム。
4. 前記コンピュータシステムから各リソースの利用率を取得して、前記リソース利用率情報に含まれる利用率を更新する利用率収集部をさらに備えること、
   を特徴とする請求項１ないし請求項３のいずれか1項に記載のリソース管理システム。
5. 前記利用率収集部は、前記影響範囲調査部が前記リソース利用率情報を利用する前に、前記コンピュータシステムから各リソースの利用率を取得すること、
   を特徴とする請求項４に記載のリソース管理システム。
6. 前記ポリシー制御部は、
   前記ポリシー情報から、前記コンピュータシステムの各リソースの利用率のうち、前記所定のしきい値より大きなリソースがあると、それに対処可能に設定された前記ポリシーアクションを選択すること、
   を特徴とする請求項４または請求項５に記載のリソース管理システム。
7. 前記リソース利用率情報には、規定された各リソースの利用率と、前記利用率収集部が取得した各リソースの利用率とをそれぞれ含み、
   前記影響範囲調査部は、処理実行回数が所定回数までは規定された各リソースの利用率を使用し、所定回数以降は、前記利用率収集部が取得した各リソースの利用率を使用すること、
   を特徴とする請求項４ないし請求項６のいずれか１項に記載のリソース管理システム。
8. 複数のコンピュータシステムを共有利用でき、前記複数のコンピュータシステムを組み合わせて実行される業務アプリケーションによってサービスを提供するシステム環境において、
   前記業務アプリケーションごとに、各業務アプリケーションを実行する前記コンピュータシステムを識別する情報、及び各コンピュータシステムを構成するリソースの利用率を含むリソース利用率情報を記憶部に格納したリソース管理システムが、
   前記業務アプリケーションから、新たに前記コンピュータシステムのリソースの使用を要求する情報を取得すると、
   前記リソース利用率情報から、前記業務アプリケーションが要求するリソースの利用率を取得し、
   変更後の前記コンピュータシステムを構成するリソースの利用率を集計すること、
   を特徴とするリソース管理方法。
9. 前記リソース管理システムの前記記憶部には、前記業務アプリケーションに対する前記コンピュータシステムの各リソースの割り当ての変更を規定する情報であるポリシーアクションを含むポリシー情報がさらに格納され、
   前記リソース管理システムは、
   前記ポリシー情報に含まれる前記ポリシーアクションに基づいて、前記業務アプリケーションが新たに前記コンピュータシステムのリソースを要求する場合に、当該コンピュータシステムの各リソースの利用率を集計し、この集計した当該コンピュータシステムの各リソースの利用率が、所定のしきい値以下であり、ＳＬＡの要求が満たされる場合に、前記ポリシーアクションに基づいて各リソースの割り当てを変更すること、
   を特徴とする請求項８に記載のリソース管理方法。
10. 前記リソース管理システムは、各リソースの割り当てを変更すると、当該ポリシーアクションに基づいて、前記リソース利用率情報に含まれる、各業務アプリケーションを実行する前記コンピュータシステムを識別する情報を更新すること、
    を特徴とする請求項９に記載のリソース管理方法。
11. 前記リソース管理システムは、
    前記コンピュータシステムから各リソースの利用率を取得して、前記リソース利用率情報に含まれる利用率を更新すること、
    を特徴とする請求項８ないし請求項１０のいずれか１項に記載のリソース管理方法。
12. 前記リソース管理システムは、
    前記リソース利用率情報を利用する前に、前記コンピュータシステムから各リソースの利用率を取得すること、
    を特徴とする請求項１１に記載のリソース管理方法。
13. 前記リソース管理システムは、
    前記ポリシー情報から、前記コンピュータシステムの各リソースの利用率のうち、前記所定のしきい値より大きなリソースがあると、それに対処可能に設定された前記ポリシーアクションを選択すること、
    を特徴とする請求項１１または請求項１２に記載のリソース管理方法。
14. 前記リソース管理システムは、
    前記リソース利用率情報に、規定された各リソースの利用率と、前記取得した各リソースの利用率とをそれぞれ含み、
    処理実行回数が所定回数までは規定された各リソースの利用率を使用し、所定回数以降は、前記取得した各リソースの利用率を使用すること、
    を特徴とする請求項１１または請求項１３に記載のリソース管理方法。
15. 請求項８ないし請求項１４のいずれか１項に記載のリソース管理方法を、前記リソース管理システムとしてコンピュータに実行させるプログラム。
16. 請求項２に記載の影響範囲調査部において、変更後の当該コンピュータシステムを構成する各リソースすべての利用率を集計し、所定のしきい値以下かどうか判断することに加えて、当該コンピュータシステムに配備されている業務アプリケーションを構成するためのネットワーク形態の情報を取得し、負荷分散処理を実施しているコンピュータシステムをポリシーアクションの対象と判断することを特徴とするリソース管理システム。

Images