JP2005174201A - リソース割り当てシステム、方法及びプログラム - Google Patents

Abstract

【課題】様々なアプリケーションの種類に対応して、サービスレベル目標に基づいた性能情報の測定結果に基づいて、リソースの割り当て変更を自動的に行う。
【解決手段】サーバ、ネットワーク、ストレージを含むリソース表３０４と、これらのリソース上で稼動するアプリケーションの構成要素を示すアプリケーション表３０３と、リソースのアプリケーションへの割り当て表３０５とを保持し、これらの構成情報から性能情報の測定項目を生成する性能測定項目テンプレート５０１、この性能情報の測定項目を性能測定エンジンによって測定する性能測定エンジン２０１、前記構成情報からリソースの割り当て変更に用いるリソース割り当て変更ルール３０２を生成する手段、および前記生成したリソース割り当て変更ルールと構成情報に従って、リソースの割り当て変更を行う。
【選択図】図１

Description

本発明は、アプリケーションの安定稼動を実現するため、リソースをアプリケーションに自動的に割り当てる技術に関する。

インターネット上のオンラインシステムや、企業内システムは、計算機上に稼動している多数のアプリケーションによって構成されている。これらのアプリケーションは計算機上で直接実行されているものもあるが、計算機上で稼動するインタープリタプログラム上で実行されているものもある。アプリケーションにはオンライン業務、バッチジョブ、などの様々な種類があり、それぞれが、アプリケーション固有の構成に従って設計・実装されたプログラムによって実現され、稼動している。

このようにアプリケーションの実装および稼動形態は様々であるが、アプリケーションの動作する環境は、アプリケーションとそれが稼動しているシステムリソースに二分でき、後者は特にホスティング環境と呼ばれている。アプリケーションを稼動させる計算機やそれらを接続するネットワークなどのシステム基盤の保守管理コストを削減するため、前記ホスティング環境の構築・保守業務をアウトソーシングする企業が多い。そのアウトソーシング先がデータセンタと呼ばれるサービス業者である。データセンタはアプリケーションが稼動するための計算機やネットワーク接続などのホスティング環境を提供する。例えば、企業ホームページのシステム基盤をアウトソーシングする場合がこのホスティング環境の利用に該当する。

また、計算機などの基盤上で稼動するアプリケーションそのものも、保守コスト削減の目的で、アプリケーションサービスプロバイダ(ASP)と呼ばれるサービスにアウトソーシングすることも多い。例えば、メールサーバの運営・保守業務をアウトソーシングする場合が好例である。

オンラインシステムであっても、企業内システムであっても、一般にアプリケーションはネットワーク分散した複数の計算機上で実現されている場合が多く、複雑な構成を持っている。複数の構成要素からなる業務アプリケーションを実現するシステムを安定稼動させるためには、システムの構成要素のどの部分に問題があるか、即ちボトルネックや異常が存在しているかどうかということを常に監視・分析する必要がある。前述の様に、アプリケーション構成は複雑であり、人手によって全てを監視し、問題に対処することは困難である。そのため、このプロセスを自動化しようとする試みがなされている。

ネットワークやサーバ計算機等のシステムリソースのリモート監視は一般的に行われており、非特許文献１に示すSNMP(Simple Network Management Protocol)などの標準化されたプロトコルを通じて、各種システムリソースを遠隔監視し、障害発生や故障を検知するということが可能である。また、非特許文献２に示すWBEM(Web Based Enterprise Management)の様に、Webベースでシステムリソースの管理を行うための仕様も策定されており、運用管理の容易化がキーポイントとなっている。

従来のシステムはこれらSNMP等によって得られた監視情報に基づいて、システム管理者が人手によって、システム構成変更や、障害の発生した機器のリプレースなどの作業を行っていた。この人手による作業を支援するために、測定した性能情報に基づいてシステムのどの要素に問題があるか、性能上のボトルネックがあるかということを分析し、システム構成の変更に利用する。これによってシステム管理者の負担が軽減され、システム運用管理コストが低下する効果がある。このようなボトルネックの解析を行うため、性能評価すべきＷｅｂシステム３０に接続される複数のクライアントを仮想的に実現して性能測定用コンピュータに対して負荷を課してボトルネックを含む性能に関する情報を測定し、現用のＷｅｂシステムの性能に関する情報及びボトルネック回避に関する情報を含む評価するものが知られている（特許文献１）。

性能情報の測定から、システム構成の変更までの全てのプロセスを自動化するための指標としては、アウトソーシングを行う企業と、データセンタなどのサービスを提供する企業との間で締結される、サービス品質などに関する契約がある。これは一般にサービスレベル契約(SLA：Service Level Agreement)と呼ばれ、データセンタにおいてはサービスレベル契約に従ったサービスレベルを維持することが求められる。

このようなサービスレベルを自動的に維持するための技術としては、計算機の稼動状況のモニタ結果に基づき自動的にユーザ識別子ごとにサービスレベル契約と比較して計算資源の量を増減するもの（特許文献２）や、クライアントの利用パターンに応じて、共有サーバの資源をクライアントに割当てるもの（特許文献３）、サービスレベルに基づいてアプリケーションに割り当てる最大の資源を決定し、さらにユーザサービスレベルに基づいて資源割当率を決定して、両者の積によりアプリケーションに割り当てる各資源の資源量を決定するもの（特許文献４）等が知られている。

これらの手法を含め、実際にサービスレベル契約に基づいて、システムを自動的に運用管理するためには、サービスレベル目標(SLO: Service Level Objective)と呼ぶ具体的な指標を設定し、これを達成するようなフィードバック系を構築する方法が知られている。また、サービスレベル契約は具体的なサービスレベル目標値を指定して締結されることが多い。
特開２００３−１３１９０７号公報 特開２００２−２４１９２号公報 特開２００２−３１８７９１号公報 特開２００１−１９５２６８号公報 SNMP仕様書(RFC1157)、IETF発行、「平成１５年１１月１８日検索」、インターネット＜URL:http://www.ietf.org/rfc/rfc1157.txt＞ WBEM仕様書、DMTF発行、「平成１５年１１月１８日検索」、インターネット＜URL:http://www.dmtf.org/standards/wbem＞

しかしながら、前記従来技術では、アプリケーションの種別を限定してリソースの割り当てプロセスを自動化するために、測定する性能情報の項目や測定結果に基づいたリソースの割り当て変更ルールを、あらかじめ測定プログラムあるいは、リソースの割り当て変更プログラムに埋め込んで置く必要がある。

つまり、性能情報の測定や測定結果に基づいたボトルネック解析がアプリケーション固有の構成に依存しているため、新しい種類のアプリケーションに対応したリソース割り当てを行うためには、性能情報測定プログラムやリソース割り当て変更プログラムに対して、性能情報測定項目やリソース割り当て変更ルールを新規に実装する必要があり、新たなアプリケーションを実行する度に、前述のような測定項目や変更ルールを作成しなければならない、という問題があった。

また、実際のサービスレベル目標はオンラインアプリケーションにおけるレスポンスタイムの様な比較的抽象度の高い物理的指標として表現されることが多い。アプリケーションは一般に複数の要素によって構成されているために、各構成要素のレスポンスタイムの様な、より具体的な性能指標の形で表されなくてはサービスレベル目標を維持することができない、という問題があった。

そこで本発明は、上記問題点に鑑みてなされたもので、様々なアプリケーションの種類に対応して、サービスレベル目標に基づいた性能情報の測定を行うことを目的とし、さらに、性能情報の測定結果に基づいて、リソースの割り当て変更を自動的に行うことを目的とする。

本発明は、サーバ、ネットワーク、ストレージを含むリソース群の構成情報と、これらのリソース上で稼動するアプリケーションの構成情報と、前記リソースのアプリケーションへの割り当て情報とを構成管理手段に保持しておき、これらの構成情報から性能情報の測定項目を生成する測定項目生成手段、および前記生成した性能情報の測定項目を性能測定エンジンによって測定する性能測定手段、前記構成管理エンジンに保持されている構成情報から、リソースの割り当て変更に用いるリソース割り当て変更ルールを生成する手段、および前記生成したリソース割り当て変更ルールと構成情報に従って、リソースの割り当て変更を行う。

また、様々なアプリケーションの種別に対応するために、アプリケーション固有の構成を記述する手段および、記述したアプリケーション構成に従って前記性能情報の測定項目とリソース割り当て変更ルールを生成する。

さらに、抽象度の高いサービスレベル目標を、抽象度の低いサービスレベル目標に分解して測定項目の生成とリソース割り当て変更ルールを生成する。

したがって、本発明は、性能情報の測定結果に基づいてシステムのボトルネックとなっているリソースに対して、適切なリソースを自動的に割り当てることが可能となり、管理者などの労力を低減しながらも、システム（リソース）に要求されるサービスレベルを満足させてアプリケーションの安定稼動を実現することが可能となる。

以下、本発明の一実施形態を添付図面に基づいて説明する。

図１は、本実施形態の一例を示すシステムの構成図で、管理サーバ１０１がWebコンテナ１０３〜１０５、AP（アプリケーション、以下同様）コンテナ１０６、１０７、DBサーバ１０８の３層からなる３階層Webアプリケーションシステム（管理対象リソース群２０５）を監視して、Webコンテナの稼動状態が所定の条件（例えば、レスポンスタイムが1秒以上）になった場合に、Webコンテナを追加するという処理を自動的に行うリソース割り当てシステムの一例を示す。

管理サーバ１０１は、本発明によるリソース割り当てシステムが稼動しているサーバ計算機で、図示はしないが、ＣＰＵ、メモリ、ストレージを備えるものである。管理サーバ１０１上ではリソース割り当てシステムを構成する性能測定エンジン２０１、リソース管理エンジン２０２、構成管理エンジン２０３、およびテンプレートリポジトリ２０４が稼動している。

なお、図１では、前記各エンジン２０１〜２０４の各コンポーネントが同一の管理サーバ１０１上で稼動している例を示しているが、複数の管理サーバ上でそれぞれが独立して稼動していてもよく、それぞれのエンジンが複数あり、それらがネットワーク上で連携して動作していてもよい。

Webコンテナ１０３〜１０５、APコンテナ１０６、１０７およびDBサーバ１０８はネットワーク１０２を介して管理サーバ１０１と接続されている。３階層Webアプリケーション機能を実現するネットワーク接続は、ネットワーク１０２と同一であってもよいし、別々であってもよいが、実施形態では同一のネットワーク１０２を共有するものとする。

Webコンテナ１０３〜１０５では、それぞれWebサービスを行うアプリケーションが実行される。AP（アプリケーション）コンテナ１０６、１０７ではWebコンテナ１０３〜１０５からの要求に応じてDB（データベース）コンテナ１０８へデータを要求し、抽出したデータを要求に応じた形式で返送するアプリケーションが実行され、このアプリケーションとしては、例えば、EJB（Enterprise Java（登録商標）Beans）やCGIなどである。また、DBコンテナ１０８では、APコンテナ１０６、１０７からの要求に応じてデータベースからデータを検索するデータベースアプリケーションが実行される。

ネットワーク１０２は、企業内のローカルエリアネットワークのような小規模のものでもよいし、インターネットのような大規模のものでもよい。

リソース割り当てシステムを構成する性能測定エンジン２０１は、後述するように性能測定項目表３０１（図５参照）を作成し、性能測定制御部４０１を含んでいる。性能測定項目表３０１は管理対象リソース群２０５に関する性能情報の測定項目一覧が保存されており、性能測定制御部４０１は前記性能測定項目表３０１に従って、管理対象リソース群２０５を構成する各コンテナ（コンポーネント）の性能測定を行う。なお、実際の性能測定処理は性能測定エンジン２０１自身が行っても良いし、別の性能測定プログラムが行っても良く、本実施形態では、各コンテナで性能測定プログラムをそれぞれ実行し、これらの測定結果を性能測定エンジン２０１が取得するものとする。

リソース管理エンジン２０２は、管理対象リソース群２０５に関するリソース割り当て変更ルール表３０２（図６参照）を保持し、リソース割り当て制御部４０２を含んでいる。リソース割り当て変更ルール表３０２には、管理対象リソース群２０５の性能情報の測定結果にしたがって、リソース割り当てを変更するリソース割り当て変更ルールがリソース毎に詳細な変更ルールとして保持されており、リソース管理制御部４０２によって当該ルールが実行・処理される。

図６において、リソース割り当て変更ルール表３０２は、ルールIDに対応して、指定したリソース（コンテナ）の稼動状態に応じて、３階層Webアプリケーションのリソース割り当てを変更するルール（条件）がそれぞれ設定される。例えば、ルールID＝１には、Webコンテナ１０３のレスポンスタイム（応答時間）が１秒を超えたら、３階層WebアプリケーションにひとつのWebコンテナを追加する、というリソース割り当て変更の条件が保持される。

構成管理エンジン２０３は、図７（Ａ）に示すアプリケーション表３０３、図７（Ｂ）に示すリソース表３０４、および図７（Ｃ）に示すアプリケーションとリソースの間の割り当て情報を含む割り当て表３０５の３つの表を保持している。

アプリケーション表３０３は、図７（Ａ）のように、管理対象リソース群２０５で実行されるアプリケーションの構成情報を、構成要素の階層構造の形で保持している。例えば、アプリケーションID＝１には、アプリケーション全体を指す３階層Webアプリケーションがアプリケーション名に設定され、親子関係を示す親アプリケーション欄には、ブランクが設定される。つまり、３階層Webアプリケーションは最上位のアプリケーションとして設定される。そして、アプリケーションID＝２には、アプリケーション名にWebアプリケーションが設定され、このアプリケーションIDの親アプリケーション欄には、アプリケーションID＝０が設定される。他のアプリケーションIDについても、それぞれ上記と同様に設定される。

次に、リソース表３０４は、図７（Ｂ）で示すように、システムリソースのリソースIDとリソース名との関連を保持している。

つまり、リソースID毎に、管理対象リソース群２０５を構成する全てのコンテナの名称がそれぞれ設定されており、リソースID＝１〜３には、Webコンテナ１０３〜１０５が設定され、リソースID＝４、５にはAPコンテナ１０６、１０７が設定され、リソースID＝６にはDBサーバ１０８が設定される。なお、このリソース表３０４には、管理対象リソース群２０５を構成する全てのコンポーネントを記載する。

図７（Ｃ）に示す、割り当て表３０５は、どのリソースがどのアプリケーションに割り当てられているかを示す表であり、上記図７（Ｂ）のリソース表３０４のリソースIDと、図７（Ａ）のアプリケーション表３０３のアプリケーションIDとの関連が保持されている。例えば、リソースID＝１には、アプリケーションID＝２が割り当てられていることから、リソース表３０４とアプリケーション表３０３から、リソースID＝１のWebコンテナ１０３が、アプリケーションID＝２のWebアプリケーションを実行していることを指し示している。

また、テンプレートリポジトリ２０４には、３階層Webアプリケーション用の性能測定項目テンプレート５０１およびリソース割り当てテンプレート５０２が格納されている。テンプレートリポジトリ２０４の内容を図３に示す。

テンプレートリポジトリ２０４は、前記性能測定エンジン２０１、リソース管理エンジン２０２で利用する性能測定項目リスト（テンプレート５０１）とリソース割り当て変更ルール（テンプレート５０２）のテンプレート情報の組を格納しておくエンジンであり、アプリケーションの種別ごとに１組のテンプレートをあらかじめ格納しておく。本実施形態では３階層アプリケーションを想定しているため、図３で示すように、３階層アプリケーションに要求されるリソース全体の性能を指示するサービスレベル目標を満足するように設定されたテンプレートが格納されている。

まず、性能測定項目テンプレート５０１には、３階層アプリケーションを実行する管理対象リソース群２０５のコンテナ（コンポーネント）についてどのような性能について測定するのか、測定すべき性能の項目がコンテナの種別毎に定義される。例えば、性能測定項目テンプレート５０１の測定項目ID＝１は、測定対象がWebコンテナで、測定内容がレスポンスタイムであることが定義され、測定項目ID＝２は、測定対象がAPコンテナで、測定内容がレスポンスタイムであることが定義されている。なお、DBサーバは管理対象リソース群２０５内に１台しか存在しないので、本実施形態ではリソース割り当て変更の対象とはならない。もちろん、複数のDBサーバが存在する場合では、性能測定項目テンプレート５０１に測定対象をDBサーバとした測定項目IDを作成すればよい。

次に、テンプレートリポジトリ２０４でリソース割り当て変更ルールを規定するリソース割り当て変更ルールテンプレート５０２は、図３で示すように、上記性能測定項目テンプレート５０１で定義された測定項目IDに対応して、リソース割り当てを変更する条件が設定されている。

例えば、図３ではルールID＝１に対応する性能測定項目テンプレート５０１の測定項目ID＝１には、Webコンテナのレスポンスタイムが１秒を超えたらWebコンテナを一台追加する、というリソース割り当ての変更条件が定義されている。同様に、測定項目ID＝２には、性能測定項目テンプレート５０１の測定項目ID＝２に対応するAPコンテナのレスポンスタイムが１秒を超えたらAPコンテナを追加する、という変更条件が定義されている。

このように、テンプレートリポジトリ２０４には、３階層アプリケーションに要求される性能を満たすのに必要な各コンテナの性能の測定項目と、性能を維持するための性能の閾値と、閾値を超えたときのリソースの変更条件が設定されている。なお、本実施形態では、性能が低下したとき（レスポンスタイムが１秒を超えたとき）にリソースを追加する例を示したが、性能が余剰となったとき（例えば、レスポンスタイムが０．３秒以下となったとき等）には、コンテナを削減するように設定することができる。また、上記テンプレート５０１、５０２はアプリケーションの作成者や管理者が、新しい種別のアプリケーションを稼動しようとするときに作成するものである。

次に、初期状態割り当て状態における、各表の内容を説明する。

図４は初期状態のリソースのアプリケーションへの割り当て状態を示す説明図であり、３階層Webアプリケーション６０１は、図１の管理対象リソース群２０５を構成する各コンテナ１０３〜１０８で実行されるWebアプリケーション６０２、APアプリケーション６０３、DBアプリケーション６０４によって階層的に構成されている。このアプリケーション構成情報は、上述した図７（Ａ）のアプリケーション表３０３に含まれており、アプリケーション表３０３のそれぞれの列にはアプリケーションのIDとアプリケーション名および、そのアプリケーションの親となるアプリケーションのIDが含まれている。

図４のリソース割り当て情報８０１に示すように、Webアプリケーション６０２、APアプリケーション６０３、DBアプリケーション６０４にはそれぞれ、Webコンテナ１０３、１０４、APコンテナ１０６、１０７、DBサーバ１０８のリソースが割り当てられている。
システムに存在する全てのリソースは図７（Ｂ）のリソース表３０４に記述されており、リソース表３０４にはリソースのIDとリソース名が含まれている。なお、図中破線で示す枠外にあるWebコンテナ１０５は、３階層アプリケーションは割り当てられておらず、待機中の状態を示す。リソースの割り当て情報８０１の内容は図７（Ｃ）の割り当て表３０５に記憶されており、それぞれの列がリソースのIDとアプリケーションのIDを含んでおり、割り当てられているリソースIDとアプリケーションIDの関係を示している。

図４の初期状態では、図３のテンプレート５０１、５０２と図７（Ａ）〜（Ｃ）の構成情報に従って図５の性能測定項目表３０１と図６のリソース割り当て変更ルール表３０２が作成されている。

次に図２に従って、性能情報に基づいてリソース割り当て変更を行う処理の流れを説明する。

まず、性能測定エンジン２０１はテンプレートリポジトリ２０４に対して、性能測定項目テンプレート要求７０１を送信する。その結果としてテンプレートリポジトリ２０４は、性能測定エンジン２０１に性能測定項目テンプレート応答７０２によって性能測定項目テンプレート５０１を返す。

次に性能測定エンジン２０１は、現在の構成情報を取得するために構成情報要求７０３を構成管理エンジン２０３に対して送信する。その結果、構成管理エンジン２０３は要求された構成情報すなわちアプリケーション表３０３、リソース表３０４、及び割り当て表３０５を性能測定エンジン２０１に構成情報応答７０４によって返す。

次に、性能測定エンジン２０１内の性能測定制御部４０１は、前記受け取った性能測定項目テンプレート５０１と、構成情報に従って、図６に示す具体的な性能測定項目表３０１を作成する。

性能測定項目テンプレート５０１にはアプリケーションの構成情報に対応した性能測定項目が記述されているため、性能測定制御部４０１は、これを割り当てられているリソースに対応する性能測定項目に変換し、図５に示した性能測定項目表３０１を作成する。

すなわち、性能測定エンジン２０１は、テンプレートリポジトリ２０４から取得した性能測定項目テンプレート５０１に記載された測定項目IDと測定項目から、管理対象リソース群２０５のどのコンポーネントからどのような性能情報を測定するのかを決定する。そして、現在稼動状態のアプリケーションとリソースの関係を示す割り当て表３０５が指し示すリソースから、上記決定に基づいたコンポーネントをリソース表３０４から選択して、性能測定項目表３０１を作成するのである。

例えば、性能測定項目テンプレート５０１の測定項目ID＝１から測定対象がWebコンテナで、測定内容がレスポンスタイムであることから、現在の割り当て表３０５のリソースIDから、対象となるWebコンテナをリソース表３０４から選択する。この結果、現在稼動状態のリソースID＝１、２のWebコンテナ１０３、１０４が選択されて性能測定項目表３０１の測定項目ID＝１、２に記載される。

次に、性能測定エンジン２０１は、管理対象リソース群２０５の各コンテナでそれぞれ稼動している性能測定プログラムに、前記作成した性能測定項目表３０１の測定を指示するメッセージ７０５を送信し、性能測定結果７０６を受信する。性能測定エンジン２０１は受信した性能測定結果７０６をリソース管理エンジン２０２に転送する。

次に、リソース管理エンジン２０２は、テンプレートリポジトリ２０４に対して、リソース割り当て変更ルールテンプレート要求７０８を送信し、その結果、リソース割り当て変更ルールテンプレート応答７０９によって、リソース割り当て変更ルールテンプレート５０２を受け取る。

リソース割り当て変更ルールテンプレート５０２は、測定した性能情報に従ってリソース割り当てを変更するためのルールを記述しておき、上述のようにそれぞれのルールを具体的なリソースに対応したルールに変換したもので構成される。

テンプレートリポジトリ２０４は、管理対象リソース群２０５の各コンテナで実行される３階層Webアプリケーション６０１の全体的な性能が与えられると、性能測定項目テンプレート５０１に設定された各測定項目IDの測定内容が、全体的な性能を満たすようにルールの詳細を作成しておく。

次に、リソース管理エンジン２０２は、構成情報要求７１０を構成管理エンジン２０３に送信する。その結果、構成管理エンジン２０３は要求された構成情報すなわちアプリケーション表３０３、リソース表３０４、及び割り当て表３０５を構成情報応答７１１によってリソース管理エンジン２０２に返す。リソース管理エンジン２０２内のリソース割り当て制御部４０２は、取得した構成情報と前記取得したリソース割り当て変更ルールテンプレート５０２に従って、リソース割り当て変更ルール表３０２を生成する。

ここで、本実施形態では、性能の測定結果が図８で示すようにリソースID＝１のWebコンテナ１０３が閾値を超えた場合について説明する。図６のリソース割り当て変更ルールのうち、ルールID＝１のルールが実行されることになる。

従って、リソース割り当て制御部４０２は、構成管理エンジン２０３に対して割り当て変更７１２としてWebコンテナを追加する処理を要求する。これを受けた構成管理エンジン２０３は、図７（Ｂ）のリソース表３０４と図７（Ｃ）の割り当て表３０５から、アプリケーションが割り当てられていないWebコンテナ１０５を選択し、このWebコンテナ１０５にアプリケーションID＝２のWebアプリケーション６０２を割り当てることでリソースを追加し、割り当て変更を実行する（７１３）。

図９は割り当てを変更した後のリソースへのアプリケーションへの割り当てを示す模式図を示している。リソース割り当て情報８０２によって、新規にWebコンテナ１０５がWebアプリケーション６０２に関連づけられている。構成管理エンジン２０３内の構成情報は図１２（Ａ）〜（Ｃ）のようになっており、リソース割り当て情報８０２の内容は図１２（Ｃ）の割り当て表３０８で表される。図１２（Ｃ）の割り当て表３０８における最終行が新たに追加された割り当てを示す。また、このリソース割り当て変更に伴って、次回の図２の手順実行時の性能測定項目表３０６および、リソース割り当て変更ルール表３０７は、それぞれ図１０、図１１のように新たにテンプレートから生成されることになる。この新しく生成された表を、次回の処理に用いることで変更されたリソース割り当てに対応できるようになる。

以上のような手順を繰り返し行うことで、性能情報項目テンプレート５０１およびリソース割り当て変更ルールテンプレート５０２に記述された内容に従って、常に安定的にアプリケーションを稼動させることができる。

したがって、性能測定項目テンプレート５０１とリソース割り当て変更ルールテンプレート５０２をサービスレベルの目標を満足する値に設定しておくことにより、様々なアプリケーションの種類に対応して、サービスレベル目標に基づいた性能情報の測定を行うことができ、さらに、性能情報の測定結果に基づいて、リソースの割り当て変更を自動的に行うことが可能となる。特に、テンプレートリポジトリ２０４にはシステム全体の性能を満足させるための性能測定項目テンプレート５０１とリソース割り当て変更ルールテンプレート５０２を設けたので、システムのボトルネックとなっているリソースに対して、適切なリソースを自動的に割り当てることが可能となる。これにより、管理者などの労力を低減しながらも、サービスレベルを満足させてアプリケーションの安定稼動を実現することが可能となる。

さらに、アプリケーションの種類を追加したときには、アプリケーションに応じたテンプレート５０１、５０２及びリソース割り当て変更ルール表３０２を生成することでシステムを変更することなく対応可能となり、可用性を高めることができる。

また、構成管理エンジン２０３に保持されている構成情報から、リソースの割り当て変更に用いるリソース割り当て変更ルール５０２を分析、生成し、前記生成したリソース割り当て変更ルール５０２と構成情報に従って、リソースの割り当て変更を行うことにより、分析結果に従って、サービスレベル目標を達成するリソースの割り当て変更を自動的に行うことが可能となる。

また、新しいアプリケーションの種別に対応するために、アプリケーション固有の構成を記述するアプリケーション表３０３および、記述したアプリケーション構成に従って上記性能情報の測定項目（測定項目テンプレート５０１）とリソース割り当て変更ルール（リソース割り当て変更ルールテンプレート５０２）を生成するテンプレートリポジトリ２０４を設けることで、さまざまなアプリケーション種別に対応して、測定項目やリソース割り当て変更ルールを自動的に生成するための枠組みを提供することができ、新規アプリケーション種別に対しても柔軟に対応できる。

以上のような本発明を、企業内のリソース割り当てシステムに適用すれば、企業内システムは、各種申請処理、給与計算などの日常的なバッチジョブを処理するシステムや、各種オンラインシステムによって構成されており、システム規模が大規模なものになっている。従って、これらの業務処理のためのシステムリソースの効率利用は大きな課題となっており、本発明のリソース割り当てシステムによって企業内システムにおける様々なアプリケーション種別のシステムに割り当てるリソースを一元的に管理することが可能になり、コスト削減が可能になる。

あるいは、データセンタのリソース割り当てシステムに適用すれば、複数の企業からのアウトソーシング先であるデータセンタでは、様々な種類のアプリケーションに対応してデータセンタ内のシステムリソースを割り当てなくてはならない。本発明によって、このリソース割り当て作業を自動的に行うことが可能になり、データセンタの運営コストを削減することが可能になる。

なお、上記においては監視対象リソース２０５として、Webコンテナ１０３〜１０５、APコンテナ１０６、１０７、DBサーバ１０８の３つの構成を例示したが、実際にはサーバ計算機、ネットワーク、ストレージなど様々なシステムリソースが含まれるため、特にこれらのリソースに限定するものではない。

図１３〜図２１は第２の実施形態を示す。本第２実施形態では前記第１実施形態の３階層Webアプリケーションシステムに代わって、データベース管理システム(DBMS)およびストレージの2層からなるDBMSストレージ連携アプリケーションシステムに本発明を適用した一例を示し、ストレージ空き容量が一定以下になった場合に、ストレージの構成変更を行うという処理を自動的に行うリソース割り当てシステムの動作について説明する。

監視対象リソースとしては、第２実施形態ではDBMSおよびストレージの2つのみであるが、実際にはサーバ計算機、ストレージ装置（ＳＡＮやＮＡＳを含む）、ネットワークなど様々なシステムリソースが含まれるため、特にこれらのリソースに限定するものではない。

図１３は、計算機ネットワークのシステム構成を示す。

図１３の管理サーバ１０１は、前記第１実施形態と同様に、リソース割り当てシステムが稼動しているサーバ計算機である。管理サーバ１０１上では性能測定エンジン２０１、リソース管理エンジン２０２、構成管理エンジン２０３、およびテンプレートリポジトリ２０４が稼動している。

図１３では、前記２０１〜２０４の各コンポーネントが同一の管理サーバ上で稼動している例を示しているが、複数の管理サーバ上で稼動していてもよく、それぞれのエンジンが複数あり、それらがネットワーク連携して動作していてもよい。

DBサーバ１０９〜１１０、およびストレージ管理プログラム１１１はネットワーク１０２を介して管理サーバ１０１と接続されている。ストレージ管理プログラム１１１は物理ストレージ装置を仮想化した仮想ストレージ１１２をDBサーバ１０９〜１１０に対して提供している。DBアプリケーション機能を実現するネットワーク接続は、ネットワーク１０２と同一であってもよいし、別々であってもよいが、実施形態では同一のネットワーク１０２を共有するものとする。ネットワーク１０２は、企業内のローカルエリアネットワークのような小規模のものでもよいし、インターネットのような大規模のものでもよい。

性能測定エンジン２０１は、前記第１実施形態と同様に、図１６に示す性能測定項目表３０９を保持し、性能測定制御部４０１を含んでいる。性能測定項目表３０９は管理対象システムに関する性能情報の測定項目一覧が保存されており、性能測定制御部４０１は前記性能測定項目表３０９に従って、性能測定を行う。実際の性能測定処理は性能測定エンジン２０１自身が行っても良いし、別の性能測定プログラムが行っても良い。実施形態では、仮想ストレージ１１２に関する性能測定は性能測定エンジンがストレージ管理プログラム１１１に問い合わせることとする。

リソース管理エンジン２０２は、図１７に示すリソース割り当て変更ルール表３１０を保持し、リソース割り当て制御部４０２を含んでいる。リソース割り当て変更ルール表３１０には、性能情報の測定結果にしたがってリソース割り当てを変更するリソース割り当て変更ルールが保持されており、リソース管理制御部４０２によって当該ルールが実行・処理される。本第２実施形態では、仮想ストレージ１１２に関する割り当て変更処理は、ストレージ管理プログラム１１１を制御することで行う。

構成管理エンジン２０３は、図１８（Ａ）〜（Ｃ）のアプリケーション表３１１、リソース表３１２、およびアプリケーションとリソースの間の割り当て情報を含む割り当て表３１３の３つの表を保持している。アプリケーション表３１１はアプリケーションの構成情報を、構成要素の階層構造の形で保持している。リソース表３１２はシステムリソースのリソースIDとリソース名およびその属性（ストレージ容量など）との関連を保持している。割り当て表３１３はどのリソースがどのアプリケーションに割り当てられているかを示す表であり、リソースIDとアプリケーションIDおよびリソースの割り当て割合（割り当て率）が保持されている。

また、テンプレートリポジトリ２０４には、DBMSストレージ連携アプリケーション用の性能測定項目テンプレート５０３およびリソース割り当てテンプレート５０４が格納されている。テンプレートリポジトリ２０４の内容を図１４に示す。テンプレートリポジトリ２０４は前記性能測定エンジン２０１、リソース管理エンジン２０２で利用する性能測定項目リスト（性能測定項目テンプレート５０３）とリソース割り当て変更ルールのテンプレート情報（テンプレート５０４）の組を格納しておくエンジンであり、アプリケーションの種別ごとに１組のテンプレートをあらかじめ格納しておく。本第２実施形態ではDBMSストレージ連携アプリケーションを想定しているため、DBMSストレージ連携アプリケーション用のテンプレートが格納されている必要がある。このテンプレートはアプリケーションの作成者または管理者が、新規種別のアプリケーションを稼動しようとするときに作成する。

次に、初期状態割り当て状態における、各表の内容を説明する。

図１５は初期状態のリソースのアプリケーションへの割り当て状態を示す説明図であり、DBMSストレージ連携アプリケーション６０５、DBアプリケーション６０６、仮想ストレージアプリケーション６０７によって階層的に構成されている。このアプリケーション構成情報は図１８（Ａ）のアプリケーション表３１１に含まれており、アプリケーション表３１１のそれぞれの列にはアプリケーションのIDとアプリケーション名および、そのアプリケーションの親となるアプリケーションのIDが含まれている。図１５に示すようにリソース割り当て情報８０３によって、DBアプリケーション６０６にはDBサーバ１０９〜１１０、ストレージアプリケーション６０７にはストレージ管理プログラム１１１経由で仮想ストレージ１１２が割り当てられている。

システムに存在する全てのリソースは図１８（Ｂ）のリソース表３１２に記述されており、リソース表３１２にはリソースのIDとリソース名が含まれている。リソースの割り当て情報８０３の内容は図１８（Ｃ）の割り当て表３１３に記憶されており、それぞれの列がリソースのIDとアプリケーションのIDを含んでおり、割り当てられているリソースとアプリケーションの関係を示している。

初期状態では、図１４の各テンプレート５０３、５０４と図１８の構成情報に従って図１６の性能測定項目表３０９と図１７のリソース割り当て変更ルール表３１０が作成されている。

次に前記第１実施形態の図２に従って、性能情報に基づいてリソース割り当て変更を行う処理の流れを説明する。

まず、性能測定エンジン２０１はテンプレートリポジトリ２０４に対して、性能測定項目テンプレート要求７０１を送信する。その結果としてテンプレートリポジトリは性能測定エンジンに性能測定項目テンプレート応答７０２によって性能測定項目テンプレート５０３を返す。次に性能測定エンジン２０１は、現在の構成情報を取得する構成情報要求７０３を構成管理エンジンに対して送信する。その結果、構成管理エンジン２０３は要求された構成情報すなわちアプリケーション表３１１、リソース表３１２、及び割り当て表３１３を性能測定エンジン２０１に構成情報応答７０４によって返す。性能測定エンジン２０１内の性能測定制御部４０１は、前記受け取った性能測定項目テンプレート５０３と、構成情報に従って、具体的な性能測定項目表３０９を作成する。

性能測定項目テンプレート５０３にはアプリケーションの構成情報に対応した性能測定項目が記述されているため、性能測定制御部４０１は、これを割り当てられているリソースに対応する性能測定項目に変換する。次に、性能測定エンジン２０１は、監視対象リソース上で稼動している性能測定プログラムに前記作成した性能測定項目の測定を指示するメッセージ７０５を送信し、性能測定結果７０６を受信する。性能測定エンジン２０１は受信した性能測定結果７０６をリソース管理エンジン２０２に転送する。次に、リソース管理エンジン２０２は、テンプレートリポジトリ２０４に対して、リソース割り当て変更ルールテンプレート要求７０８を送信し、その結果、リソース割り当て変更ルールテンプレート応答７０９によって、リソース割り当て変更ルールテンプレート５０４を受け取る。リソース割り当て変更ルールテンプレート５０４は、測定した性能情報に従ってリソース割り当てを変更するためのルールを記述しておき、それぞれのルールを具体的リソースに対応したルールに変換する。

次に、リソース管理エンジン２０２は、構成情報要求７１０を構成管理エンジン２０３に送信する。その結果、構成管理エンジン２０３は要求された構成情報すなわちアプリケーション表３１１、リソース表３１２、及び割り当て表３１３を構成情報応答７１１によってリソース管理エンジン２０２に返す。リソース管理エンジン２０２内のリソース割り当て制御部４０２は、取得した構成情報と前記取得したリソース割り当て変更ルールテンプレート５０４に従って、リソース割り当て変更ルール表３１０を生成する。

ここで、本第２実施形態では、図１９のように、仮想ストレージ１１１の空き容量が５００ＭＢとなって、リソース割り当て変更ルールテンプレート５０４の閾値である１ＧＢを下回った性能測定結果を得たと想定するため、図１７のリソース割り当て変更ルールのうち、ルールIDが１のルールが実行されることになる。

従って、リソース割り当て制御部４０２は、構成管理エンジン２０３に対して割り当て変更７１２としてストレージ管理プログラム１１１を制御し、仮想ストレージ１１２の論理ボリュームサイズを追加する処理を要求し、構成管理エンジン２０３はこれを実行する（７１３）。

図２０は割り当てを変更した後のリソースのアプリケーションへの割り当て状態を示す説明図を示している。リソース割り当て情報８０４によって、新規に仮想ストレージ１１２の論理ボリュームサイズの関連づけが更新される。構成管理エンジン２０３内の構成情報は図２１のようになり、リソース割り当て情報８０４は図２１（Ｃ）の割り当て表３１４で表される。割り当て表３１４における最終行が、割り当て率が変更された部分を示し、リソースID＝３の仮想ストレージ１１１に対して、アプリケーションID＝３の仮想ストレージアプリケーション６０７が６０％の記憶領域を割り当てたことを示している。

以上のような手順を繰り返し行うことで、性能情報項目テンプレート５０３およびリソース割り当て変更ルールテンプレート５０４に記述された内容に従って、システムのボトルネックを検知して、リソース割り当て変更を自動的に行うことで、サービスレベルを満足しながら常に安定的にアプリケーションを稼動させることができるのである。

図２２は、第３の実施形態を示し、前記第１実施形態のテンプレートリポジトリ２０４が、抽象度の高いサービスレベル目標を実現するような、測定項目およびリソース割り当て変更ルールのテンプレートを生成するもので、その他の構成は前記第１実施形態と同様である。

例えば、アプリケーションシステムのトータルレスポンスタイムがサービスレベル目標として指定されていた場合、より具体的なサービスレベル目標の形に分解しなければならない。すなわち、システムのどの部分にボトルネックがあるかということを解析するルールが必要である。

したがって、前記第１実施形態の３階層Webアプリケーション６０１では、Webコンテナ、APコンテナ、DBサーバの全てのパスを通るリクエストのレスポンスが一定時間以下で帰ってくるというサービスレベル目標があった場合、それぞれの構成要素に対応するルールを生成するというメタテンプレート５０５を用意しておく。

図２２のメタテンプレート５０５のルールをアプリケーションの構成情報（例えば、図７の割り当て表３０５）にしたがって分解して、例えば図３に示した性能測定項目テンプレート５０１およびリソース割り当て変更ルールテンプレート５０２を得る。

例えば、メタテンプレート５０５には、サービスレベル目標として、３階層Webアプリケーション６０１のシステム全体的なレスポンスタイムが３秒未満に設定されていたとする。テンプレートリポジトリ２０４は、図７（Ａ）に示すアプリケーションの階層構造から、３つのアプリケーションであることから、各アプリケーションのレスポンスタイムが１秒未満となるように、サービスレベル目標を配分する。

次に、テンプレートリポジトリ２０４は、図７（Ｂ）のリソース表３０４と図７（Ｃ）の割り当て表３０５からリソースの割り当て変更が可能なコンポーネント（コンテナ）として、WebコンテナとAPコンテナを選択する。ここでは、DBサーバ１０８は一つしかないのでリソースの割り当て変更が不能と判定する。

上記のように、選択したリソースの割り当て変更対象について、サービスレベル目標に基づいて測定項目を決定する。すなわち、サービスレベル目標がレスポンスタイムで定義されているので、測定項目としてレスポンスタイムを選択し、図２２に示すように、測定項目ID＝１にWebコンテナ、ID＝２にAPコンテナを設定した性能測定項目テンプレート５０１を生成する。

次に、測定項目IDの生成に伴って、リソース割り当て変更ルールテンプレート５０２にルールIDを生成し、３つのアプリケーションへ均等に分配したレスポンスタイム＜１秒を、各ルールID閾値として設定し、さらに、リソース割り当て変更の内容として、測定項目IDに設定したコンテナの種類を追加するようにルールを定義する。

これらの生成されたテンプレートを用いて上述した図２の流れに従って本発明で提案するリソース割り当てシステムを稼動させることで図２２の内容のようなサービスレベル目標を達成するように、測定した性能に基づいてリソースの割り当て変更を行うことができる。

このように、メタテンプレート５０５に設定したサービスレベル目標から管理対象のリソース群の構成要素に応じてリソースの割り当て変更の対象と、割り当て変更を行う条件を抽出して性能測定項目テンプレート５０１とリソース割り当て変更ルールテンプレート５０２を分析して生成することで、高レベルのサービスレベル目標を、より物理リソースに対応した具体的なサービスレベル目標の形に変換することが可能となって、高度なシステム管理の自動化をさらに推進することができる。

つまり、抽象度の高いサービスレベル目標を、抽象度の低いサービスレベル目標に分解するための枠組み（メタテンプレート５０５）を導入することで、高レベルなサービスレベル目標に対する汎用的な枠組みを提供することができるのである。

なお、上記第３実施形態においては、サービスレベル目標をレスポンスタイムが３秒未満として、各リソース（Webコンテナ、APコンテナ、DBサーバ）のレスポンスタイムへ均等に配分したが、サービスレベル目標を達成可能な範囲で、各リソースの性能に応じてレスポンスタイムを不均一に設定しても良い。

以上のように、本発明によれば、企業内システムにおけるリソース割り当てシステムや管理サーバ、データセンタにおけるリソース割り当てシステムまたは管理サーバに適用することができる。

第１の実施形態を示すシステムの全体構成図。 リソース割り当てシステムの動作手順の一例を示すシーケンス図。 性能測定項目テンプレートと、リソース割り当て変更ルールテンプレートの内容を示す説明図。 初期割り当て状態のアプリケーションおよびリソースの構成情報を示す説明図。 初期割り当て時の性能測定項目表を示す説明図。 初期割り当て時のリソース割り当て変更ルール表を示す説明図。 初期割り当て時の構成管理エンジンにおける構成情報を示し、（Ａ）はアプリケーション表、（Ｂ）はリソース表、（Ｃ）は割り当て表の内容をそれぞれ示す説明図。 性能測定結果一覧を示す説明図。 リソース割り当て変更後のアプリケーションおよびリソースの構成情報を示す説明図。 リソース割り当て変更後の性能測定項目表の内容を示す説明図。 リソース割り当て変更後のリソース割り当て変更ルール表の内容を示す説明図。 リソース割り当て変更後の構成管理エンジンにおける構成情報を示し、（Ａ）はアプリケーション表、（Ｂ）はリソース表、（Ｃ）は割り当て表の内容をそれぞれ示す説明図。 第２の実施形態を示し、システムの全体構成図。 同じく第２の実施形態の性能測定項目テンプレートと、リソース割り当て変更ルールテンプレートの内容を示す説明図。 同じく第２の実施形態の初期割り当て状態のアプリケーションおよびリソースの構成情報を示す説明図。 同じく第２の実施形態の初期割り当て時の性能測定項目表を示す説明図。 同じく第２の実施形態の初期割り当て時のリソース割り当て変更ルール表を示す説明図。 同じく第２の実施形態の初期割り当て時の構成管理エンジンにおける構成情報を示し、（Ａ）はアプリケーション表、（Ｂ）はリソース表、（Ｃ）は割り当て表の内容をそれぞれ示す説明図。 同じく第２の実施形態の性能測定結果一覧を示す説明図。 同じく第２の実施形態のリソース割り当て変更後のアプリケーションおよびリソースの構成情報を示す説明図。 同じく第２の実施形態のリソース割り当て変更後の構成管理エンジンにおける構成情報を示し、（Ａ）はアプリケーション表、（Ｂ）はリソース表、（Ｃ）は割り当て表の内容をそれぞれ示す説明図。 第３の実施形態を示し、テンプレートリポジトリのメタテンプレート、性能測定項目テンプレート及びリソース割り当て変更ルールテンプレートの内容を示す説明図。

符号の説明

１０１ 管理サーバ
１０３〜１０５ Webコンテナ
１０６〜１０７ APコンテナ
１０８〜１１０ DBサーバ
１１１ ストレージ管理プログラム
１１２ 仮想ストレージ
２０１ 性能測定エンジン
２０２ リソース管理エンジン
２０３ 構成管理エンジン
２０４ テンプレートリポジトリ
２０５ 管理対象リソース群
３０１，３０６，３０９ 性能測定項目表
３０２，３０７，３１０ リソース割り当て変更ルール表
３０３，３１１ アプリケーション表
３０４，３１２ リソース表
３０５，３０８，３１３，３１４ 割り当て表
４０１ 性能測定制御部
４０２ リソース割り当て制御部
５０１，５０３ 性能測定項目テンプレート
５０２，５０４ リソース割り当て変更ルールテンプレート
６０１ ３階層Webアプリケーション
６０２ Webアプリケーション
６０３ APアプリケーション
６０４，６０６ DBアプリケーション
６０５ DBMSストレージ連携アプリケーション
６０７ 仮想ストレージアプリケーション

Claims (17)

1. サーバ、ネットワーク、ストレージを含むリソースをアプリケーションに割り当てるリソース割り当てシステムであって、
   サーバ、ネットワーク、ストレージを含むリソースの構成情報と、これらのリソース上で稼動するアプリケーションの構成要素からなる構成情報と、前記アプリケーションへ割り当てられたリソースの割り当て情報とを保持する構成管理手段と、
   前記リソースの構成情報とアプリケーションの構成情報及び割り当て情報から、前記リソースに関する性能情報の測定項目を生成する測定項目生成手段と、
   前記生成した性能情報の測定項目を測定する性能測定手段と、
   前記性能情報の測定結果に基づいて前記アプリケーションの構成要素毎にリソースの割り当て情報を変更する割り当て変更手段と、
   を備えたことを特徴とするリソース割り当てシステム。
2. 前記測定項目生成手段は、前記生成した測定項目に基づいてリソースの割り当て変更ルールを生成する変更ルール生成手段を有し、
   前記割り当て変更手段は、前記生成したリソースの割り当て変更ルールと、前記リソースの構成情報とアプリケーションの構成情報及び割り当て情報に基づいてリソースの割り当て変更を行うことを特徴とする請求項１に記載のリソース割り当てシステム。
3. 前記割り当て変更手段は、前記アプリケーションの構成情報と、前記性能情報の測定項目とリソースの割り当て変更ルールから、リソースごとの詳細な変更ルールを生成する詳細変更ルール生成手段を有することを特徴とする請求項２に記載のリソース割り当てシステム。
4. 前記測定項目生成手段は、予めアプリケーション毎に設定された第１のテンプレートに基づいて前記性能情報の測定項目を生成することを特徴とする請求項１に記載のリソース割り当てシステム。
5. 前記測定項目生成手段は、予めアプリケーション毎に設定された第２のテンプレートに基づいて前記リソースの割り当て変更ルールを生成することを特徴とする請求項２に記載のリソース割り当てシステム。
6. 前記測定項目生成手段は、前記リソース全体の性能を指示するサービスレベル目標を記憶する手段を有し、
   前記アプリケーションの構成要素を示す構成情報と、アプリケーションの構成要素に割り当て可能なリソースの構成情報と、前記割り当て情報から前記サービスレベル目標に基づいて前記性能情報の測定項目とリソースの割り当て変更ルールを生成することを特徴とする請求項２に記載のリソース割り当てシステム。
7. 前記測定項目生成手段は、リソース全体の性能を指示するサービスレベル目標に基づいて、前記性能情報の測定項目を生成することを特徴とする請求項１に記載のリソース割り当てシステム。
8. サーバ、ネットワーク、ストレージを含むリソースをアプリケーションに割り当てるリソース割り当て方法であって、
   サーバ、ネットワーク、ストレージを含むリソースの構成情報と、前記リソース上で稼動するアプリケーションの構成要素からなる構成情報と、前記アプリケーションへ割り当てられたリソースの割り当て情報とを取得する手順と、
   前記リソースの構成情報とアプリケーションの構成情報及び割り当て情報から、前記リソースに関する性能情報の測定項目を生成する手順と、
   前記生成した性能情報の測定項目を測定する手順と、
   前記性能情報の測定結果に基づいて前記アプリケーションの構成要素毎にリソースの割り当て情報を変更する手順と、
   を含むことを特徴とするリソース割り当て方法。
9. 前記生成した測定項目に基づいてリソースの割り当て変更ルールを生成する手順を含み、
   前記生成したリソースの割り当て変更ルールと、前記リソースの構成情報とアプリケーションの構成情報及び割り当て情報に基づいてリソースの割り当て変更を行うことを特徴とする請求項８に記載のリソース割り当て方法。
10. 前記アプリケーションの構成情報と、前記性能情報の測定項目とリソースの割り当て変更ルールから、リソースごとの詳細な変更ルールを生成する手順を含み、この詳細な変更ルールに基づいて前記リソース割り当て変更を行うことを特徴とする請求項９に記載のリソース割り当て方法。
11. 予めアプリケーション毎に設定された第１のテンプレートに基づいて前記性能情報の測定項目を生成する手順を含むことを特徴とする請求項８に記載のリソース割り当て方法。
12. 予めアプリケーション毎に設定された第２のテンプレートに基づいて前記リソースの割り当て変更ルールを生成する手順を含むことを特徴とする請求項９に記載のリソース割り当て方法。
13. リソース全体の性能を指示するサービスレベル目標を設定する手順を含み、
    前記アプリケーションの構成要素を示す構成情報と、アプリケーションの構成要素に割り当て可能なリソースの構成情報と、前記割り当て情報から前記サービスレベル目標に応じて前記性能情報の測定項目とリソースの割り当て変更ルールを生成することを特徴とする請求項９に記載のリソース割り当て方法。
14. 前記性能情報の測定項目を生成する手順は、リソース全体の性能を指示するサービスレベル目標に基づいて、前記性能情報の測定項目を生成することを特徴とする請求項８に記載のリソース割り当て方法。
15. サーバ、ネットワーク、ストレージを含むリソースをアプリケーションに割り当てるプログラムであって、
    サーバ、ネットワーク、ストレージを含むリソースの構成情報と、これらのリソース上で稼動するアプリケーションの構成要素からなる構成情報と、前記アプリケーションへ割り当てられたリソースの割り当て情報を取得する手段と、
    前記リソースの構成情報とアプリケーションの構成情報及び割り当て情報から、前記リソースに関する性能情報の測定項目を生成する手段と、
    前記生成した性能情報の測定項目を測定する手段と、
    前記性能情報の測定結果に基づいて前記アプリケーションの構成要素毎にリソースの割り当て情報を変更する手段と、
    をコンピュータに機能させることを特徴とするプログラム。
16. 前記生成した測定項目に基づいてリソースの割り当て変更ルールを生成する手段を有し、
    前記生成したリソースの割り当て変更ルールと、前記リソースの構成情報とアプリケーションの構成情報及び割り当て情報に基づいてリソースの割り当て変更を行うことを特徴とする請求項１４に記載のプログラム。
17. 前記測定項目を生成する手段は、リソース全体の性能を指示するサービスレベル目標に基づいて、前記性能情報の測定項目を生成することを特徴とする請求項１５に記載のプログラム。

Images