JP2009259005A

JP2009259005A - リソース監視方法および装置

Info

Publication number: JP2009259005A
Application number: JP2008107392A
Authority: JP
Inventors: Shuhei Sakai; 周平境
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2008-04-17
Filing date: 2008-04-17
Publication date: 2009-11-05

Abstract

【課題】本発明の目的は、監視対象となる計算機上で発生する様々な要因によるリソース不足を問題が顕在化する前に検知すること、およびリソース不足が予想される場合に適切な対処を自動的に行うことにある。
【解決手段】本発明では、監視対象コンピュータ上で発生する事象をイベントとして通知する機能を持ち、受信したイベントを契機として、リソース使用情報の取得を行い、取得した情報を蓄積および解析する機能を持ち、上記解析結果から、イベント発生後のリソース使用量を予測する手段と、予測したリソース消費量が予め設定した閾値または計算機上の空きリソースを越えるようであれば、追加リソースの割り当てや別の計算機に処理を分散するなどのアクションを実行する手段を持つことを特徴とする。
【選択図】図１

Description

本発明は計算機のリソース使用量を監視する技術に関する。

システム構築時に各サービスに対するリソースの見積りを行っても、実際の運用においては、処理の集中や処理データ量などの要因により、リソース不足が発生し、サービスレベルを維持できないなどの問題が発生することがある。

そのため、近年では仮想化技術により動的にリソースを確保することで、刻々と変化する状況に対し、リソース不足の問題を解決する方法が示されている（例えば、特許文献１、特許文献２）。

特開２００５−９９９７３号公報特開２００５−１２８８６６号公報

特許文献１および特許文献２では、リソース使用量予測にユーザーリクエストの内容によりリソース使用量を予測するため、
Ｗｅｂシステムなど特定のシステムを監視する場合には有効であるが、集計業務やバックアップ業務といったユーザ要求を伴わない形態の業務システムを監視することができないという問題があった。

また、システム構成の変更や、実行するアプリケーションの変更が発生した場合、新たに分類テーブルを更新する作業が必要になるという問題があった。

さらには、リソース不足が発生する要因は、ユーザリクエストや業務量の変化のみではなく、ソフトウェア障害やハードウェア障害といった予測不可能な事象やこれらのリカバリー処理が原因となる場合もある。

本発明の目的は、計算機システム上で発生する様々な事象発生後のリソース使用量の変化を予測することで、リソース不足を事前に検知し、適切な対処を自動的に行うことにある。

上記目的を達成するために、本発明では、監視対象コンピュータ上で発生する事象をイベントとして通知する機能を持ち、受信したイベントを契機として、リソース使用情報の取得を行い、取得した情報を事象ごとに自動的に分類して蓄積および解析する機能を持ち、上記解析結果から、イベント発生後のリソース使用量を予測する手段と、予測したリソース消費量が予め設定した閾値または計算機上の空きリソースを越えるようであれば、追加リソースの割り当てや別の計算機に処理を分散するなどのアクションを実行する手段を持つことを特徴とする。

本発明によれば、計算機システム上で発生する様々な事象発生後のリソース使用量を予測することができ、またリソース使用量の予測にはイベントの持つ情報を利用することでより精度の高い予測をすることができ、リソース不足が予想される場合に適切なリソースを割り当てるなどの対処ができるようになる。

図１は、監視システム全体の構成を表す図である。

監視コンピュータ１００と監視対象コンピュータ１３０がＬＡＮなどのネットワーク１２０を介して接続されている。

監視コンピュータ１００と監視対象コンピュータ１３０は、一般的なコンピュータ（計算機）である。

また、監視対象コンピュータ１３０は複数台存在しても良い。

監視コンピュータ１００は、メモリ１０１、ディスク制御装置１０６、ＣＰＵ１０７、通信装置１０８を持っている。

また、ストレージなどの補助記憶装置１１０は、ディスク制御装置１０６により接続されている。

メモリ１０１上に、イベント受信部１０２、リソース使用量予測部１０３、稼動データ取得部１０４、アクション指示部１０５が展開されている。

また、データとして、補助記憶装置１０９上に、イベント分類テーブル１１０、リソース監視設定テーブル１１１、リソース管理テーブル１１２、アクション定義ＤＢ１１３をそれぞれ持つ。

これらのデータは、メモリ上に持っても良い。

監視対象コンピュータ１３０は、メモリ１３１、ＣＰＵ１３６、通信装置１３７を持ち、メモリ１３１上に業務や各種アプリケーションのプログラム１３２、イベント送信部１３３、稼動データ収集部１３４、アクション実行部１３５が展開されている。

プログラム１３２は複数並列に実行することができ、プログラム１３２に埋め込まれたコードからイベント送信部１３３の機能により、監視コンピュータ１００にプログラムで発生した事象や、プログラムが監視プログラムの場合は、監視対象となる機器やプログラムで発生した事象をイベントとして発行することができる。

イベントとして送信される情報の例を図２に示す。

イベントとして送信される情報には、事象が発生したコンピュータを識別するために発生コンピュータ２０１を持つ。また、イベントには、計算機上で発生した事象を一意に識別するための情報として、イベントＩＤ２０２を持つ。

その他にメッセージ２０３や複数の属性２０４を持ってもよい。

イベント受信部１０２の処理フローを図３に示す。

監視対象コンピュータで発生した事象は、イベント送信部１３３からイベントとして送信され、管理サーバ１００のイベント受信部１０２で受信する（Ｓ１０１）。

受信したイベントの発生コンピュータ２０１およびイベントＩＤ２０２から、イベント分類テーブル１１０を検索する（Ｓ１０２）。

イベント分類テーブル１１０を図４に示す。

イベント分類テーブル１１０は、イベントを分類する条件として分類条件４０１、分類条件を一意に識別するためのＩＤとしてグループＩＤ４０２で構成されている。

分類条件４０１は、発生コンピュータ４０３、イベントＩＤ４０４などの複数の条件を持ってよい。また、条件として使用する項目にはメッセージや属性などを追加してもよい。

イベント分類テーブルの分類条件４０１を検索し、一致する分類条件のグループＩＤが取得できた場合（Ｓ１０３：Ｙｅｓ）は、リソース使用量予測部１０３を呼び出す（Ｓ１０４）。

一致する分類条件が無かった場合（Ｓ１０３：Ｎｏ）は、新たにグループＩＤを設定し、受信したイベントに含まれる情報をイベント分類テーブルに設定し（Ｓ１０５）、リソース使用量予測部１０３を呼び出す（Ｓ１０４）。

図５にリソース使用量予測部を示す。

リソース使用量予測部１０３は、リソース使用量予測処理５０１、リソース使用量監視処理５０２、リソース使用量予測値登録処理５０３からなる。これらの処理は、必ずしもリソース使用量予測部内にある必要は無く、それぞれ独立していてもよい。

図６にリソース使用量予測部１０３の処理フローを示す。

リソース使用量予測部１０３は、順にリソース使用量予測処理５０１（Ｓ２０１）、リソース使用量監視処理５０２（Ｓ２０２）、リソース使用量予測値登録処理５０３（Ｓ２０３）を呼び出す。

リソース使用量予測処理５０２（Ｓ２０１）の処理フローを図７に示す。

イベントの情報に含まれる発生コンピュータ２０２に対し、稼動データ取得部１０４からリソース情報収集指示を出す（Ｓ３０１）。

収集するリソースおよび収集間隔などの設定情報は、リソース監視設定テーブル１１１に予め設定しておく。

リソース監視設定テーブル１１１を図８に示す。

リソース監視設定テーブル１１１は、管理対象コンピュータ８０１、収集するリソース８０２、閾値８０３、収集間隔８０４、収集完了条件８０５、リソース使用量が閾値を超えたときに実行するアクションを示すアクションＩＤ８０６を持つ。

この例では、管理対象コンピュータごとに収集するリソースやしきい値を設定しているが、全てのコンピュータに対して同じ条件を設定してもよい。

また、しきい値は、リソースの最大値（最大量）であってもよい。

この場合、稼動データ収集部１３４を通じて、リソース最大値を得ることもできる。

リソース使用量予測部では、イベントを受信時に検索したイベント分類テーブル１１０のグループＩＤ４０２から、対応するグループＩＤのリソース使用量増分予測値をリソース管理テーブル１１２から取得する（Ｓ１０２）。

リソース管理テーブル１１２を図９に示す。

リソース管理テーブルは、イベント分類テーブルのグループＩＤ４０２と対応付けたグループＩＤ９０１、リソース使用量増分予測値９０２を持つ。リソース使用量増分予測値９０２には、収集するリソースを持つ。例では、ＣＰＵ使用率９０３およびメモリ使用量９０４を持つ。

リソース管理テーブル１１２に一致するグループＩＤ９０１が存在しない場合は、新たにデータを追加し、処理を終了する（Ｓ３０３：Ｎｏ）。データの初期値には０を設定する。

リソース管理テーブル１１２からリソース使用量予測データを取得できた場合（Ｓ３０３：Ｙｅｓ）は、管理対象コンピュータの現在のリソース使用量にリソース使用量予測データの値を加算し、その結果がリソース監視設定テーブル１１１のしきい値８０３を超えていないか判断する。

しきい値を超えていない場合（Ｓ３０５：Ｙｅｓ）は、処理を終了する。

しきい値を超えた場合（Ｓ３０５：Ｎｏ）は、リソース監視設定テーブル１１１のアクションＩＤ８０６に指定されたＩＤを、アクション定義テーブル１１４のアクションＩＤと照合し、合致したアクションを実行し、処理を終了する。

アクション定義テーブルを図１０に示す。

アクション定義テーブル１１３には、アクションＩＤ１００１とアクションの実行コマンド１００２、コマンドを実行するときに渡す実行引数１００３が定義されている。

実行時に渡す引数には、変数を使用することができ、変数に不足するリソース量などを設定することで、不足分のリソースを動的に割り当てることができる。

リソース使用量監視処理５０３（Ｓ２０２）の処理フローを図１１に示す。

該当するリソース監視設定テーブル１１１の情報を取得し、収集するリソース４０２と収集間隔４０４を基に定期的に発生コンピュータ３０２のリソース情報を収集する（Ｓ４０１）。管理対象コンピュータのリソース使用量情報は、稼動データ取得部１０４により稼動データ収集部１３４を通じて行われる。

ここで、取得したリソース使用量が予め設定した閾値８０３を超えていないか確認し、閾値を超えた場合（Ｓ４０２：Ｎｏ）は、アクションを実行する（Ｓ４０４）ように設定してもよい。閾値を超えていない場合は、Ｓ４０３に進む（Ｓ４０２：Ｙｅｓ）。

次の処理（Ｓ４０３）では収集完了条件の確認を行う。収集完了条件８０５を満たした場合（Ｓ４０３：Ｙｅｓ）は、取得したデータをリソース使用量履歴テーブル１１２に更新し（Ｓ４０５）、処理を終了する。

リソース使用量履歴テーブル１１２を図１２に示す。

リソース使用量履歴テーブルは、グループＩＤごとに存在し、属性１２０２およびリソース使用量増分１２０３を記録する。属性が複数ある場合は、属性１（１２０３）、属性２（１２０４）のように複数定義できる。また、リソース使用量増分１２０３についても、収集するリソースごとにＣＰＵ使用率１２０５、メモリ使用量１２０６のように複数定義してよい。

リソース使用量予測値登録処理５０４（Ｓ２０３）の処理フローを図１３に示す。

リソース使用量予測値登録処理では、リソース使用量履歴テーブル１１２を参照し、存在する属性値の数だけ、繰り返し処理を行う。まず初期値としてｎ＝０を設定する（Ｓ５０１）。次に、ｎに１を加算する（Ｓ５０２）。

属性ｎが存在する場合（Ｓ５０３：Ｙｅｓ）で属性ｎが数値データの場合（Ｓ５０４）、属性ｎとリソース使用量の相関関係を計算するために近似式を求める（Ｓ５０５）。

近似式は、最小二乗法などを用いて行うことができる。

また、数値データで無い場合は、Ｓ５０２に進み、次の属性ｎ＋１について検証を行う。

次に、求めた近似式と実測値の誤差を計算し、誤差が予め規定した範囲内に収まっている場合は相関関係があるとし（Ｓ５０６：Ｙｅｓ）、求めた近似式をリソース管理テーブル１１３のリソース使用量増分予測値９０２に登録する。登録する式は、例えば「０．３×＄属性２」（＄属性２は変数としての属性２を表す）のように登録する（Ｓ５０７）。登録した値をリソース使用量予測処理のＳ３０２で使用する場合は、属性２の値を代入することにより、リソース使用量予測値を求める。

また、相関関係がない場合はＳ５０２に進み、次の属性ｎ＋１について検証を行う。

すべての属性を検証しても相関関係がなかった場合や、属性が無い場合（Ｓ５０３：Ｎｏ）は、リソース使用量の履歴から最大値をリソース管理テーブル１１３のリソース使用量増分予測値９０２に登録する。登録する値は、最大値ではなく平均値としてもよい。

監視システム全体の構成を表す図。イベントとして送信される情報の一例を表す図。イベント受信部の処理フローを表す図。イベント分類テーブルを表す図。リソース使用量予測部の構成を表す図。リソース使用量予測部の処理フローを表す図。リソース使用量予測処理の処理フローを表す図。リソース監視設定テーブルを表す図。リソース管理テーブルを表す図。アクション定義テーブルを表す図。リソース使用量監視処理の処理フローを表す図。リソース使用量履歴テーブルを表す図。リソース使用量予測値登録処理の処理フローを表す図。

符号の説明

１００…管理コンピュータ、１０１、１３１…メモリ、１０２…イベント受信部、１０３…リソース使用量予測部、１０４…稼動データ取得部、１０５…アクション指示部、１０６…ディスク制御装置、１０７、１３６…ＣＰＵ、１０８…通信装置、１０９、１３７…補助記憶装置、１１０…イベント分類テーブル、１１１…リソース監視設定テーブル、１１２…リソース使用量履歴テーブル、１１３…リソース管理テーブル、１１４…アクション定義テーブル、１２０…ネットワーク、１３０…管理対象コンピュータ、１３２…プログラム、１３３…イベント送信部、１３４…稼動データ収集部、１３５…アクション実行部。

Claims

監視対象コンピュータをイベントにより監視する監視システムにおいて、
イベントを契機として、監視対象コンピュータのリソース使用量を測定する手段と、イベントの持つ情報によりイベントをグループ分けし、グループごとに測定したリソース使用量を蓄積する手段を持つことを特徴とするリソース監視装置。
請求項１のリソース監視システムにおいて、
イベントを受信したときに、イベント受信後に使用するリソース量を予測する手段を持つことを特徴とするリソース監視装置。
請求項２のリソース監視システムにおいて、
監視対象コンピュータのリソース量の最大値および現在のリソース使用状況を取得する手段と、イベントを受信したときに、イベント受信後に使用するリソース量を予測する手段を持ち、予測したリソース使用量が最大値を超えることが予測される場合に、予め定義したアクションを実行する機能を持つリソース監視装置。
請求項３のリソース監視システムにおいて、
アクションとして、不足するリソースの割り当てを行う場合に、予測したリソース量をパラメータとして渡すことで、必要となるリソースを確保することを特徴とするリソース監視装置。
請求項２のリソース監視システムにおいて、予測の際に、イベントの持つ属性情報から、属性情報とリソース使用量の相関関係を計算し、属性情報を加味したリソース使用量予測を行うことを特徴とするリソース監視装置。