JP2010066828A - 情報処理装置、情報処理方法及びプログラム - Google Patents

Abstract

【課題】 適切なコンピュータシステムの運用を図る。
【解決手段】 判断部１０４は、コンピュータシステムの状態を示すイベント情報と、コンピュータシステムの運用指針を示すポリシー情報とに基づいて、コンピュータシステムの構成を変更するための要求情報を生成する。スケジュール部１０８は、生成される要求情報に応じたコンピュータシステムの構成変更処理のスケジューリングを行う。シミュレーション部１１０は、生成されたスケジュールをシミュレーションする。判断部１０４は、シミュレーション結果によって新たに得られるイベント情報がポリシーを満たしているか否かを判定し、ポリシーを満たしていないと判定された場合、新たに得られるイベント情報とポリシーとに基づいて、コンピュータシステムの構成を変更するための要求情報を新たに生成する。
【選択図】 図１

Description

本発明は、対象となるコンピュータシステムを自律的に管理する自律型コンピューティングに適用可能な技術に関するものである。

従来、人間によるコンピュータシステムの管理の負荷を軽減するためにコンピュータが自ら管理する仕組み、所謂自律型コンピューティングが知られている。自律型コンピューティングでは、コンピュータシステムに障害が発生すると、所定の運用指針（以下、ポリシーと称す）に基づいて、自律的な自己の障害を修復することができる。

更に、システムの状態は様々な要素が複雑に絡んでいるので、或るサイトに向けて作成されたポリシーの妥当性を検証することは、人手による机上のチェックでは不可能であり、一方、本番システムでチェックすることはコスト面等で厳しいものがあった。これに対し、特許文献１においては、自律管理向けポリシーシミュレータというものを提供している。

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

特許文献１に開示される技術は、シミュレーションを行い、フィードバックされたシミュレーション結果がポリシーを満たさなかった場合、当該ポリシーを抽出し、人間がポリシーエディタを用いてポリシーを修正するための技術である。そのため、人間がポリシーをチューニングし続ける必要がある（特許文献１段落［００２６］）。また特許文献１のポリシーは、各システムの構成やそれらの変更、そのスケジュール等、複雑な要素が絡んで影響を受け易いものであり、それらの影響を細かに考慮したポリシーにチューニングしても、すぐに無用のチューニングになってしまう。従って、様々な影響を細かく設定した完璧なポリシーを作成することで、自律的にシステム運用管理を行おうとすることは、現実的に困難である。

そこで、本発明の目的は、コンピュータシステムの構成変更のシミュレーション結果がコンピュータシステムの運用指針であるポリシーを違反する場合、当該ポリシーを満たすような構成の変更要求を自律的に生成することにより、人手によらず適切なコンピュータシステムの運用を図ることにある。

本発明の情報処理装置は、サービスを提供する少なくとも一つのコンピュータから構成されるコンピュータシステムと通信回線を介して接続された情報処理装置であって、前記コンピュータシステムの状態を示すイベント情報と、前記サービスを提供する前記コンピュータシステムの運用指針を示すポリシー情報とに基づいて、前記コンピュータシステムの構成を変更するための要求情報を生成する要求情報生成手段と、前記要求情報生成手段により生成される要求情報に応じた前記コンピュータシステムの構成変更処理のスケジューリングを行うスケジューリング手段と、前記スケジューリング手段によって生成されたスケジュールをシミュレーションするシミュレーション手段と、前記シミュレーション手段によるシミュレーション結果によって新たに得られるイベント情報が前記ポリシーを満たしているか否かを判定する判定手段とを有し、前記要求情報生成手段は、前記判定手段によって前記新たに得られるイベント情報が前記ポリシーを満たしていないと判定された場合、前記新たに得られるイベント情報と前記ポリシーとに基づいて、前記コンピュータシステムの構成を変更するための要求情報を新たに生成することを特徴とする。
本発明の情報処理方法は、サービスを提供する少なくとも一つのコンピュータから構成されるコンピュータシステムと通信回線を介して接続された情報処理装置による情報処理方法であって、前記コンピュータシステムの状態を示すイベント情報と、前記サービスを提供する前記コンピュータシステムの運用指針を示すポリシー情報とに基づいて、前記コンピュータシステムの構成を変更するための要求情報を生成する要求情報生成ステップと、前記要求情報生成ステップにより生成される要求情報に応じた前記コンピュータシステムの構成変更処理のスケジューリングを行うスケジューリングステップと、前記スケジューリングステップによって生成されたスケジュールをシミュレーションするシミュレーションステップと、前記シミュレーションステップによるシミュレーション結果によって新たに得られるイベント情報が前記ポリシーを満たしているか否かを判定する判定ステップとを含み、前記要求情報生成ステップは、前記判定ステップによって前記新たに得られるイベント情報が前記ポリシーを満たしていないと判定された場合、前記新たに得られるイベント情報と前記ポリシーとに基づいて、前記コンピュータシステムの構成を変更するための要求情報を新たに生成することを特徴とする。
本発明のプログラムは、サービスを提供する少なくとも一つのコンピュータから構成されるコンピュータシステムと通信回線を介して接続された情報処理装置による情報処理方法をコンピュータに実行させるためのプログラムであって、前記コンピュータシステムの状態を示すイベント情報と、前記サービスを提供する前記コンピュータシステムの運用指針を示すポリシー情報とに基づいて、前記コンピュータシステムの構成を変更するための要求情報を生成する要求情報生成ステップと、前記要求情報生成ステップにより生成される要求情報に応じた前記コンピュータシステムの構成変更処理のスケジューリングを行うスケジューリングステップと、前記スケジューリングステップによって生成されたスケジュールをシミュレーションするシミュレーションステップと、前記シミュレーションステップによるシミュレーション結果によって新たに得られるイベント情報が前記ポリシーを満たしているか否かを判定する判定ステップとをコンピュータに実行させ、前記要求情報生成ステップは、前記判定ステップによって前記新たに得られるイベント情報が前記ポリシーを満たしていないと判定された場合、前記新たに得られるイベント情報と前記ポリシーとに基づいて、前記コンピュータシステムの構成を変更するための要求情報を新たに生成することを特徴とする。

本発明によれば、コンピュータシステムの構成変更のシミュレーション結果がコンピュータシステムの運用指針であるポリシーを違反する場合、当該ポリシーを満たすような構成の変更要求を自律的に生成することにより、適切なコンピュータシステムの運用を図ることが可能となる。

以下、本発明を適用した好適な実施形態を、添付図面を参照しながら詳細に説明する。

図１は、本発明の実施形態に係る自律型コンピューティング装置の機能的な構成を示すブロック図である。図１に示すように、本実施形態に係る自律型コンピューティング装置１００は、サーバ類１００１、ストレージ類１００２及びネットワーク（Ｎ／Ｗ）装置類１００３から構成される自律型コンピューティング環境であるコンピュータシステムとＬＡＮ(Local Area Network)等の通信回線で接続され、この通信回線を介して各装置の状態を監視することが可能である。なお、自律型コンピューティング環境とは、本実施形態における自律型コンピューティングの技術を適用する環境である。

上述したサーバ類１００１とは、Ｗｅｂサーバ、ＡＰサーバ及びＤＢサーバ等の各種サーバのことであり、ストレージ類１００２とは、ＤＢ等の情報を記録可能な装置類である。ネットワーク装置類１００３とは、サーバ類１００１及びストレージ類１００２の各装置間を接続するＬＡＮ等の通信ネットワークである。

モニタリング装置１０１は、サーバ類１００１、ストレージ類１００２及びネットワーク装置類１００３の各ノードから監視データを適宜取得する。以下に、モニタリング内容の例を示す。サーバ類１００１からは、監視データとしてＣＰＵ利用率を示すデータ及びメモリ使用量を示すデータ、ネットワーク流量やディスクアクセス回数等のリソース使用状況データ、各サーバの処理履歴を示すログデータ等を取得する。また、モニタリング装置１０１は、監視データとしてストレージ類１００２からディスク使用量やディスクキャッシュヒット率等のデータを取得する。更に、モニタリング装置１０１は、ネットワーク装置類１００３から監視データとして、それらの通信回線の流量や通信エラーの有無を示すログデータを取得する。また、モニタリング装置１０１は、各ノードに障害が発生したときには、障害発生を監視データとして取得する。

モニタリング装置１０１は、取得した監視データに基づいて自律型コンピューティング環境の状態を示すイベント情報を生成し、モニタリング結果データベース１０２に蓄積する。

また、モニタリング装置１０１は、自律型コンピューティング環境の構成を適宜監視し、その結果を構成情報として生成し、ポリシー管理データベース１０５に蓄積する。

ポリシー管理データベース１０５は、上述した構成情報のほかにポリシーを格納する。ポリシーとは、本自律型コンピューティング環境の運用に関する指針を示すデータである。

分析部１０３は、モニタリング結果データベース１０２に格納されたイベント情報を取得し、過去からの自律型コンピューティング環境の状態変化の推移履歴を示すイベント情報を生成したり、取得するイベント情報の値の変化と過去のイベント情報の値の変化履歴とを照合して、自律型コンピューティング環境の将来の状態変化の予測内容を示すイベント情報を生成する。

判断部１０４は、分析部１０３或いはモニタリング結果データベース１０２からイベント情報を取得すると、ポリシー管理データベース１０５から当該イベント情報に該当する現在の構成情報及びポリシーを取得し、自律型コンピューティング環境の構成変更の要求情報である構成変更要求を生成し、スケジュール部１０８に出力する。また、後述するシミュレーション部１１０によって生成される新たなイベント情報が、取得したポリシーを満たさない場合、新たなイベント情報と当該ポリシーとに基づいて構成変更要求を再度生成する。

イベント情報蓄積データベース１０９は、ポリシー管理データベース１０５に蓄積される構成情報を逐次取得していき、構成情報の履歴を管理する。

スケジュール部１０８は、自律型コンピューティング環境であるコンピュータシステムの構成変更に要する時間を考慮して、期限までに構成変更処理が完了するように構成変更のスケジューリングを行う。

シミュレーション部１１０は、スケジュール部１０８によるスケジューリング結果をシミュレーションし、当該スケジューリング結果について新たなイベント情報を出力する。また、シミュレータは、方式は問わないが、将来のある時刻におけるシステムの構成やリソースの負荷情報等の過渡現象を考慮してリソース使用率、アプリケーションの応答時間、システムの処理量を計算し、過渡状態を含めたシステムの挙動のシミュレーションを実現する。

プロビジョニング装置１０７は、上記新たなイベント情報がポリシーを満たす場合、そのときのスケジュール部１０８によるスケジューリング結果に従って、自律型コンピューティング環境に対するプロビジョニング処理を実行する。

図２は、自律型コンピューティング装置１００のハードウェア構成を示すブロック図である。ＣＰＵ２０１は、システムバスに接続される各デバイスやコントローラを統括的に制御する。ＲＯＭ２０３又はＨＤ２０７には、ＣＰＵ２０１の制御プログラムであるＢＩＯＳ（Basic Input/Output System）やオペレーティングシステムプログラムや、自律型コンピューティング装置１００が実行する例えば図３乃至図５に示す処理のプログラム等が記録されている。

なお、図２の例では、ハードディスク（ＨＤ）２０７は、自律型コンピューティング装置１００の内部に配置された構成としているが、他の実施形態としてＨＤ２０７に相当する構成が自律型コンピューティング装置１００の外部に配置された構成としてもよい。本実施形態に係る例えば図３乃至図５に示す処理を行うためのプログラムは、フレキシブルディスク（ＦＤ）２０６やＣＲ−ＲＯＭ等、コンピュータ読み取り可能な記録媒体に記録され、それらの記録媒体から供給される構成としてもよいし、インターネット等の通信媒体を介して供給される構成としてもよい。

ＲＡＭ２０２は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。ＣＰＵ２０１は、処理の実行に際して必要なプログラム等をＲＡＭ２０２にロードして、プログラムを実行することで各種動作を実現するものである。

ディスクコントローラ２０５は、ＨＤ２０７やＦＤ２０６等の外部メモリへのアクセスを制御する。通信ＩＦコントローラ２０４は、インターネットやＬＡＮと接続し、例えばＴＣＰ／ＩＰによって外部との通信を制御するものである。

ディスプレイコントローラ２０８は、ディスプレイ２０９における画像表示を制御する。

ＫＢ（キーボード）コントローラ２１０は、キーボード（ＫＢ）２１１からの操作入力を受け付け、ＣＰＵ２０１に対して送信する。なお、図示していないが、キーボード２１１の他に、マウス等のポインティングデバイスもユーザの操作手段として本実施形態に係る自律型コンピューティング装置に適用可能である。

また、図１のモニタリング装置１０１、分析部１０３、判断部１０４、スケジュール部１０８、シミュレーション部１１０及びプロビジョニング装置１０７は、例えばＨＤ２０７内に記録され、必要に応じてＲＡＭ２０２にロードされるプログラム及びそれを実行するＣＰＵ２０１に相当する構成である。

図１のポリシー管理データベース１０５、モニタリング結果データベース１０２及びイベント情報蓄積データベース１０９は、例えばＨＤ２０７内の一部記憶領域に相当する構成である。なお、ポリシー管理データベース１０５、モニタリング結果データベース１０２は、本自律型コンピューティング装置１００の外部に備えた構成としてもよい。

図３乃至図５−２は、本実施形態に係る自律型コンピューティング装置１００の動作の流れを示すフローチャートである。

先ず、図３において、先ずモニタリング装置１００は、自律型コンピューティング環境の各ノードから監視データを取得し、取得した監視データからリソース状態変化等に関するイベント情報を生成する（ステップＳ３０１）。

続いて、モニタリング装置１０１は、生成したイベント情報をモニタリング結果データベース１０２に蓄積する（ステップＳ３０２）。

続いて、分析部１０３は、モニタリング結果データベース１０２からイベント情報を取得し、取得したイベント情報に基づいて過去からの自律型コンピューティングの状態変化の推移履歴を示すイベント情報を生成したり、取得したイベント情報の値の変化と過去の監視データの値の変化履歴とを照合して、自律型コンピューティング環境の将来の状態変化の予測内容を示すイベント情報を生成する（ステップＳ３０３）。将来の状態変化の予測には、過去から現在にかけてのイベント情報の経時変化に対して、各種分析手法を適用することで行う。例えば、現在のＣＰＵ利用率が４０％で、過去から現在にかけて、ＣＰＵ利用率が３０分に１０％ずつ上昇しているとき、線形予測を用いて未来のＣＰＵ利用率を算出し、現在から４時間後にはＣＰＵ利用率が閾値８０％を超えると予測する。イベントの種類や変化の度合い等により、線形近似以外の手法を活用することも当然可能である。

続いて、判断部１０４は、分析部１０３或いはモニタリング結果データベース１０２より出力されたイベント情報に該当するポリシー及び現在の構成情報をポリシー管理データベース１０５から取得する。そして、判断部１０４は、イベント情報、ポリシー及び現在の構成情報に基づいて構成変更要求を生成する（ステップＳ３０４）。この構成変更要求の生成処理の詳細は後述する。

続いて、スケジュール部１０８は、判断部１０４より出力される構成変更要求に基づいて、スケジューリング処理を行う（ステップＳ３０５）。

続いて、図４において、シミュレーション部１１０は、スケジュール部１０８から出力されたスケジュールをシミュレーションし、シミュレーション結果として新たなイベント情報を出力する（ステップＳ３０６）。

続いて、判断部１０４は、シミュレーション部１１０から出力されたイベント情報がポリシーを満たしているか否かを判定する（ステップＳ３０７）。イベント情報がポリシーを満たしていない場合、判断部１０４は、ポリシーを満たすように新たに構成変更要求を生成する（ステップＳ３０８）。

続いて、スケジュール部１０８は、新たに生成された構成変更要求を基にスケジューリング処理を行う（ステップＳ３０９）。そして、処理はステップＳ３０６に戻り、シミュレーション部１１０は、ここで出力されたスケジュールについてシミュレーションを行う。上述したステップＳ３０６〜Ｓ３０９の処理は、ステップＳ３０７においてシミュレーション結果がポリシーを満たすと判定されるまで繰り返し実行される。

ステップＳ３０７において、新たに生成されたイベント情報がポリシーを満たすと判定された場合、プロビジョニング装置１０７は、スケジューリング部１０８によって最終的に生成された実現可能なスケジュールに従って、構成変更処理を自律型コンピューティング環境に対して実行する（ステップＳ３１１）。

図６は、本実施形態において監視対象とする自律型コンピューティング環境の一例を示す図である。ここでは、サーバ類１００１であるＷｅｂサーバ１、ＡＰサーバ１及びＤＢサーバ１〜２、並びに、ストレージ類１００２であるＤＢが、互いにネットワーク装置１０３である通信回線を介して接続されるコンピュータシステムを例に挙げている。なお、図６におけるＡＰサーバ２〜５は、上記通信回線に同様に接続されているが、稼働していない状態にあり、必要に応じてコンピュータシステムに追加される予備のサーバであることを示している。また、これら予備のＡＰサーバ２〜５は、ＡＰサーバとして追加されるだけではなく、他のサービスを提供するサーバ、例えばＷｅｂサーバやＤＢサーバ等、必要に応じた追加がなされる。また図６において、説明の便宜上サーバ等のハードウェア・リソースを図示したが、ハードウェアだけでなく、ネットワークの設定、ミドルウェアや開発環境などのプラットフォーム一式についても、自律型コンピューティング環境において同様に扱えることは言うまでもない。

図７は、図６に示す自律型コンピューティング環境を監視対象とした場合の構成情報を示す図である。図７に示すように、構成情報には、例えば、日時情報、各サーバ（ノード）の名称、サービス名、役割、スペック及びステータスが含まれる。日時情報には、構成情報がモニタリング装置１０１によって生成された日時を示す。サービス名は、該当するコンピュータシステムのサービス名を示す。役割は、コンピュータシステム内におけるサーバの役割を示す。ステータスは、サーバが動作中の状態にあるか否かを示す。なお、上述の構成情報は本実施形態を行うに当たっての一例である。例えば、該当サーバが動作しているか否かをステータスで管理する代わりに、サーバやサービス、役割、スペック等の項目を空白で管理することで、該当サーバが稼働していない状態にあることを管理しても当然よい。

図８は、判断部１０４が取得するイベント情報の構成の一例を概念的に示す図である。従って、実際にはコンピュータが理解できるようにプログラミング言語で表現されている。なお、イベント情報の構成に関する他の図においても同様である。図８においては、２つのイベント情報を例示している。イベント情報には、日時情報、発生場所、内容が含まれる。日時情報は、監視データがモニタリング装置１０１によって取得された日時を示す情報、或いは、分析部１０３によってイベント情報が生成された日時を示す情報である。発生場所は、監視データの取得場所を示す情報である。内容は、監視データに基づいて解析されたイベント情報の内容を示す情報である。ここでは、イベント情報１の内容として、「２．５時間後に（ＡＰサーバ）１台当たりのＣＰＵ利用率が７０％」となることが示されている。イベント情報１は、モニタリング装置１０１によって生成され、判断部１０４によって取得されたものである。

図９は、図８に示すイベント情報に該当するポリシーの構成の一例を概念的に示す図である。ここでは、イベント情報１の発生場所のサービスＡ及びＡＰサーバに関係するポリシーが選択され、そのなかで、最適なＣＰＵ利用率の基準を示すポリシー１が選択される。

ポリシーには、適用箇所、ルールが含まれる。適用箇所は、当該ポリシーを適用する箇所を示す情報である。ルールは、当該ポリシーの適用箇所であるルールを示す情報である。図９に示すように、ポリシー１の適用箇所は、サービスＡを提供するコンピュータシステムのＡＰサーバであることが示されている。また、ポリシー１のルールとしては、「１台当たりのＣＰＵ利用率を４０％程度に抑える」ことが示されている。なお、図９では説明のためにルールを文書的に表現しているが、実際にはコンピュータプログラミング言語でよく使われるｉｆ／ｔｈｅｎ形式等で記載し、コンピュータがルールを判断できるようにする。なお、ポリシーの構成に関する他の図においても同様である。

次に、図３のステップＳ３０４における判断部１０４における構成変更要求の生成方法について詳細に説明する。先ず、判断部１０４が現在の構成情報を取得し、上述の処理の通りポリシーを選択する。次に、判断部１０４は、取得した現在の構成情報とポリシーを、図１０に示すサービスＡの稼働にＡＰサーバ全体として要する負荷量を算出する式に適用させ、サービスＡの稼働にＡＰサーバ全体として要する負荷量を算出する。具体的には、図１１を用いて後述する。また、この例では、負荷量として、ＡＰサーバのＣＰＵ性能比及びＣＰＵ利用率を使用しているが、サービスＡへのアクセス量など他の値を利用してもよい。ＣＰＵ性能比とは、ＣＰＵの性能を表す指標であり、クロック周波数、ベンチマーク試験の結果等の値を利用して算出する。

次に、図１１を用いて、サービスＡの稼働にＡＰサーバ全体として要する負荷量の算出処理を具体的に説明する。例えば、判断部１０４は、取得した現在の構成情報から、サービスＡを提供しているＡＰサーバが１台構成であることを把握する。また、判断部１０４は、図８に示すイベント情報１を取得すると、２．５時間後のＡＰサーバ１台当たりのＣＰＵ利用率が７０％であることを把握する。従って、図１１に示すように、ＡＰサーバ１台分の、ＣＰＵ性能比×ＣＰＵ利用率の合計を算出する。ここでは、ＡＰサーバのＣＰＵ性能比が１である場合を例示しているが、これに限らないことは勿論である。

次に、このような処理によって算出した、サービスＡの稼働にかかるＡＰサーバ全体の負荷量と選択したポリシーとに基づいて、サービスＡの稼働において、ポリシーを満たすために必要とされるＡＰサーバ構成を算出する。具体的には、２．５時間後の負荷量（７０％）を、判断部１０４が取得した図９に示すポリシーの「（ＡＰサーバ）１台当たりのＣＰＵ利用率を４０％程度に抑える」の４０％で割る。判断部１０４がこの処理を行うことによって、ポリシーを満たしてサービスＡを稼働するのに必要なＡＰサーバ台数が算出される。なお、割り切れない場合には、繰り上げた値を必要なＡＰサーバ台数とする。

図１２は、判断部１０４による必要なＡＰサーバ台数の算出方法を示す図である。図１２に示すように、必要なＡＰサーバ台数は、サービスＡを提供する際に要されるＡＰサーバ全体の負荷量をポリシーに示される１台当たりのＣＰＵ利用率４０％で除算して、２．５時間後に必要なＡＰサーバ台数は２台と算出される。

図１３は、判断部１０４が上述の処理を行ったことによって生成した構成変更要求を示す概念図の一例である。図１３の構成変更要求１には、「2008/4/4 2:30までにサービスＡのＡＰサーバを２台構成にする」といったように、予測される２．５時間後の負荷量に応じて、図９に示すポリシーを満たしてサービスＡを提供するのに必要なＡＰサーバ台数が記述された構成変更要求１が生成される。

図１４は、スケジュール部１０８が上記構成変更要求１に基づいて出力するスケジュールを示す概念図の一例である。以下では、図３のステップＳ３０５の具体例を説明する。ここでは、2008/4/4 2:00までにＡＰサーバ台数を１台とし（構成変更ｃ）、2008/4/4 4:00までにＡＰサーバ台数を４台にする（構成変更ｂ）ことが既にスケジューリングされているものとする。図１４においては、構成変更に要する時間を考慮して、構成変更ｃ、ｂを夫々上記期限までに完了させるために、それらの期限から３０分前に構成変更を開始させることがスケジュールとして示されている。このようなスケジューリングには、該当する構成変更（ジョブ）に要する時間が用いられる。即ち、構成変更の期限から構成変更に要する時間だけ遡った時間に構成変更が開始されるようにスケジューリングされる。このようにすることで、確実に期限までに構成変更を完了させることができる適切なスケジューリングが行えるようになる。なお、構成変更に要する時間を決定するための処理は、図５のフローチャートを用いて詳細に説明する。

この状態でスケジュール部１０８が上記構成変更要求１を入力すると、2008/4/4 2:30までにＡＰサーバ台数を２台にする（構成変更ａ）ために、その構成変更に要する時間を考慮して、図１４に示すように、期限（2008/4/4 2:30）から３０分前の2008/4/4 2:00に構成変更ａを開始させることをスケジューリングする。

図１５は、図１４に示すスケジュールに対するシミュレーション結果を示す図である。以下では、図４のステップＳ３０６の具体例について説明する。シミュレーション部１１０は、サービスＡの３０分置きの応答時間と当該サービスＡのＡＰサーバの３０分置きのＣＰＵ利用率とについてシミュレーション結果として新たなイベント情報を出力する。図１５の例では、図１４に示すスケジュール通りにシステムの構成変更を行った場合、2008/4/4 1:30には、ＡＰサーバのＣＰＵ利用率が３０％、サービスＡの応答時間が２秒となり、2008/4/4 2:00には、ＡＰサーバのＣＰＵ利用率が２０％、サービスＡの応答時間が２秒となり、2008/4/4 2:30には、ＡＰサーバのＣＰＵ利用率が２０％、サービスＡの応答時間が２秒となり、2008/4/4 3:00には、ＡＰサーバのＣＰＵ利用率が５０％、サービスＡの応答時間が１０秒となることが、シミュレーション結果として出力されたことを示している。また、図１５（シミュレーション結果）と図８（イベント情報）は、いずれも「何時の時点において、どこで、どのような状態にあるか」を示したものであり、従って両者は同義である。

図１５に示すシミュレーション結果においては、2008/4/4 3:00におけるＡＰサーバのＣＰＵ利用率が５０％であるため、図９に示すポリシーを満たさない。従って、図４のステップＳ３０７では、ポリシーを満たさないと判定されることになる。図１５に示すシミュレーション結果の2008/4/4 3:00におけるＡＰサーバは２台構成であり、ＡＰサーバ１台当たりのＣＰＵ利用率は５０％である。従って、判断部１０４は、図１６に示すように、ＡＰサーバ２台分の、ＣＰＵ性能比×ＣＰＵ利用率の合計を算出する。

次に、このような処理によって算出した、サービスＡの稼働にかかるＡＰサーバ全体の負荷量と選択したポリシーとに基づいて、サービスＡの稼働において、ポリシーを満たすために必要とされるＡＰサーバの台数を算出する。具体的には、2008/4/4 3:00でのサービスＡを提供する際に要されるＡＰサーバ全体の負荷量（１００％）を、判断部１０４が取得した図９に示すポリシーの「（ＡＰサーバ）１台当たりのＣＰＵ利用率を４０％程度に抑える」の４０％で割る。判断部１０４がこの処理を行うことによって、ポリシーを満たしてサービスＡを稼働するのに必要なＡＰサーバ台数が再度算出される。

図１７は、判断部１０４による必要なサーバ台数の算出方法を示す図である。図１７に示すように、必要なサーバ台数は、サービスＡを提供する際に要されるＡＰサーバ全体の負荷量をポリシーに示される１台当たりのＣＰＵ利用率４０％で除算して、2008/4/4 3:00に必要なＡＰサーバ台数は３台と算出される。

図１８は、判断部１０４が上述の処理を行うことによって生成した構成変更要求を示す図である。ここでは、図４のステップＳ３０８の具体例について説明する。図１８の構成変更要求２には、「2008/4/4 3:00までにサービスＡのＡＰサーバを３台構成にする」といったように、2008/4/4 3:00時点のシミュレーション結果に応じて、図９に示すポリシーを満たしてサービスＡを提供するのに必要なＡＰサーバ台数が記述された構成変更要求２が生成される。

図１９は、スケジュール部１０８が上記構成変更要求２に基づいて出力するスケジュールを示す図である。ここでは、図４ＮステップＳ３０９の具体例について説明する。上述したスケジューリング処理によって、2008/4/4 2:00までにＡＰサーバ台数を１台とし（構成変更ｃ）、2008/4/4 2:30までにＡＰサーバ台数を２台とし（構成変更ａ）、2008/4/4 4:00までにＡＰサーバ台数を４台にする（構成変更ｂ）ことが既にスケジューリングされているものとする。図１９においては、構成変更に要する時間を考慮して、構成変更ｃ、ａ、ｂを夫々上記期限までに完了させるために、それらの期限から３０分前に構成変更を開始させることがスケジュールとして示されている。

この状態でスケジュール部１０８が上記構成変更要求２を入力すると、2008/4/4 3:00までにＡＰサーバ台数を３台にする（構成変更ｄ）ため、その構成変更に要する時間を考慮して、図１９に示すように、期限（2008/4/4 3:00）から３０分前の2008/4/4 2:30に構成変更ｄを開始させることをスケジューリングする。ここでのスケジューリング処理においても、上述したステップＳ３０５と同様に構成変更に要する時間を決定し、決定された構成変更に要する時間を用いてスケジューリングが行われる。また以降の処理については上述の通り、ステップＳ３０６に戻り、シミュレーション部１１０は、ここで出力されたスケジュールについてシミュレーションを行い、シミュレーション結果がポリシーを満たすと判定されるまで、構成変更要求の生成および当該構成変更要求のスケジューリング処理が繰り返し実行される。

以上のように、本実施形態によれば、監視対象のコンピュータシステムの構成変更のスケジューリング結果がポリシーを違反する場合、当該ポリシーを満たすような構成の変更要求を生成することにより、適切なコンピュータシステムの運用を図ることが可能となる。

図５は、構成変更に要する時間の算出方法を示すフローチャートである。ここでは、Ｗｅｂサーバ１〜４、ＡＰサーバ１〜４及びＤＢサーバ１〜２から構成されるコンピュータシステムからＡＰサーバ４を除外する構成変更を例に挙げて説明する。即ち、ここでは、ＡＰサーバを３台構成にする旨の「内容」が記述された構成変更要求が判断部１０４から出力された場合について説明を行う。

図５において、先ずスケジュール部１０８は、Ｗｅｂサーバ１〜４、ＡＰサーバ１〜４及びＤＢサーバ１〜２で構成されるコンピュータシステムと同じ構成である時期をイベント情報蓄積データベース１０９内の構成変更履歴から探索する（ステップＳ５１１）。

続いて、スケジュール部１０８は、Ｗｅｂサーバ１〜４、ＡＰサーバ１〜４及びＤＢサーバ１〜２で構成されるコンピュータシステムと同じ構成である時期が存在したか否かを判定する（ステップＳ５１２）。

図２０は、イベント情報蓄積データベース１０９内の過去の構成変更履歴の一例を概念的に示す図である。図２０に示すように、構成変更履歴は、レコード毎に該当するサーバについて、時刻、当該サーバのサーバ名、当該サーバのサービス名、当該サーバの役割、当該サーバのスペック、当該サーバの状態、プロビジョニング方法及びジョブＩＤを記録している。サーバの状態は、当該サーバが通常（変化なし）の状態であるか、構成変更のための何らかの状態にあるかを示す。プロビジョニング方法は、プロビジョニングを行う際に実行される処理を示す。

図２０において、各同じ日時について、Ｗｅｂサーバ１〜４、ＡＰサーバ１〜５及びＤＢサーバ１〜２の１１のサーバに関するレコードが存在する。例えば、2007/2/16 16:00には、Ｗｅｂサーバ１〜４の役割として「Web」が登録され、ＡＰサーバ１〜４の役割として「AP」が登録され、ＡＰサーバ５の役割として「free」が登録され、ＤＢサーバ１〜２の役割として「DB」が登録される。これは、２００７年２月１６日１６時においてＡＰサーバ５を除く、Ｗｅｂサーバ１〜４、ＡＰサーバ１〜４及びＤＢサーバ１〜２から構成されるコンピュータシステムが稼働していることを示している。

また、2007/2/16 16:10には、Ｗｅｂサーバ１〜４の役割として「Web」が登録され、ＡＰサーバ１〜３の役割として「AP」が登録され、ＡＰサーバ４〜５の役割として「free」が登録され、ＤＢサーバ１〜２の役割として「DB」が登録される。これは、２００７年２月１６日１６時１０分においてＡＰサーバ４がＷｅｂサーバ１〜４、ＡＰサーバ１〜４及びＤＢサーバ１〜２で稼働していたコンピュータシステムから除外される構成変更が開始されたことを示している。そして、2007/2/16 16:20においてＡＰサーバ４の状態が「構成変更中」であり、2007/2/16 16:30においてＡＰサーバ４の状態が「構成変更完了」であることから、ＡＰサーバ４の除外のための構成変更は、2007/2/16 16:10から2007/2/16 16:30までの２０分要したことを示している。

図２０の例では、Ｗｅｂサーバ１〜４、ＡＰサーバ１〜４及びＤＢサーバ１〜２の構成のコンピュータシステムで稼働していた時期が2007/2/16 16:00に存在する。従って、スケジュール部１０８は、図２０に示す構成変更履歴を参照した場合、ステップＳ５１２において、Ｗｅｂサーバ１〜４、ＡＰサーバ１〜４及びＤＢサーバ１〜２で構成されるコンピュータシステムと同じ構成である時期が存在すると判定し、処理はステップＳ５１３に移行する。一方、構成変更履歴にＷｅｂサーバ１〜４、ＡＰサーバ１〜４及びＤＢサーバ１〜２と同じ構成である時期が存在しない場合、処理はステップＳ５１５に移行する。

ステップＳ５１３では、スケジュール部１０８は、同じ構成である時期が存在すると判定された構成変更履歴内の各サーバから構成されるコンピュータシステムについて、当該ジョブ８の構成変更要求の「内容」と同じ構成変更の記録を検索する。

続いて、スケジュール部１０８は、同じ構成である時期が存在すると判定された構成変更履歴内の各サーバから構成されるコンピュータシステムについて、当該ジョブの構成変更要求の「内容（ＡＰサーバ３台構成）」と同じ構成変更の記録が存在するか否かを判定する（ステップＳ５１４）。構成変更要求の「内容（ＡＰサーバ３台構成）」と同じ構成変更の記録が存在すると判定された場合、処理はステップＳ５１６に移行する。一方、構成変更要求の「内容（ＡＰサーバ３台構成）」と同じ構成変更の記録が存在しないと判定された場合、処理はステップＳ５１５に移行する。

図２０の例では、2007/2/16 16:10にＡＰサーバ４が除外され、ＡＰサーバが３台となる履歴が登録されているため、スケジュール部１０８は、図２０の構成変更履歴を参照した場合、構成変更履歴内に当該ジョブの構成変更要求の「内容」と同じ構成変更の記録が存在すると判定する。

ステップＳ５１６では、スケジュール部１０８は、構成変更履歴内に上記「内容」と同じ構成変更の記録が複数存在するか否かを判定する。複数存在すると判定された場合、処理はステップＳ５１８に移行し、複数存在しない（一つしか存在しない）と判定された場合、処理はステップＳ５１７に移行する。

ステップＳ５１８では、スケジュール部１０８は、複数存在する構成変更の記録から判定される構成変更に要する時間のうち、最も長い時間を「構成変更に要する時間」として採用する。なお、ステップＳ５１８の他の処理例として、複数判定される構成変更に要する時間の平均値を採用したり、複数判定される構成変更に要する時間の９０％Ｔｉｌｅ値を採用してもよい。

一方、ステップＳ５１５では、スケジュール部１０８は、「構成変更に要する時間」として初期値を採用する。即ち、スケジュール部１０８は、ステップＳ５１２において、Ｗｅｂサーバ１〜４、ＡＰサーバ１〜４及びＤＢサーバ１〜２で構成されるコンピュータシステムと同じ構成である時期が存在しないと判定された場合や、ステップＳ５１４において、当該ジョブの構成変更要求の「内容」と同じ構成変更の記録が存在しないと判定された場合、「構成変更に要する時間」として初期値（例えば、３０分）を採用する。

また、ステップＳ５１７では、スケジュール部１０８は、構成変更の記録から判定される構成変更に要する時間を「構成変更に要する時間」として採用する。図２０の例では、構成変更履歴内に当該ジョブの構成変更要求の「内容」と同じ構成変更の記録が一つしか存在しないため、ステップＳ５１７が実行されることになる。つまり、当該ジョブ８に対いては２０分が「構成変更に要する時間」として採用されることになる。なお、「構成変更に要する時間」の求め方において、上述の処理は一例に過ぎない。例えば、構成変更要求前後のシステム構成と当該構成変更要求に要した時間をユニークに管理する等、過去に行った構成変更において要した時間を把握できる処理であればよいことは言うまでも無い。

また、本発明を実施するにあたってイベント情報は、標準的なフォーマットの一つであるＣＢＥ（Common Base Event）データに変換されていてもよいことは言うまでもない。

本発明の実施形態に係る自律型コンピューティング装置の機能的な構成を示すブロック図である。 自律型コンピューティング装置のハードウェア構成を示すブロック図である。 本発明の実施形態に係る自律型コンピューティング装置の動作の流れを示すフローチャートである。 本発明の実施形態に係る自律型コンピューティング装置の動作の流れを示すフローチャートである。 本発明の実施形態に係る自律型コンピューティング装置の動作の流れを示すフローチャートである。 本発明の実施形態において監視対象とする自律型コンピューティング環境の一例を示す図である。 図６に示す自律型コンピューティング環境を監視対象とした場合の構成情報を示す図である。 判断部が取得するイベント情報の構成の一例を概念的に示す図である。 図８に示すイベント情報に該当するポリシーの構成の一例を概念的に示す図である。 サービスＡの稼働にＡＰサーバ全体として要する負荷量を算出する式を示す図である。 サービスＡの稼働にＡＰサーバ全体として要する負荷量の算出処理を具体的に説明するための図である。 判断部による必要なサーバ台数の算出方法を示す図である。 判断部が生成する構成変更要求１の一例を示す図である。 スケジュール部が構成変更要求１に基づいて出力するスケジュールを示す概念図である。 図１４に示すスケジュールに対するシミュレーション結果を示す図である。 サービスＡの稼働にＡＰサーバ全体として要する負荷量の算出処理を具体的に説明するための図である。 判断部による必要なサーバ台数の算出方法を示す図である。 判断部が生成する構成変更要求２の一例を示す図である。 スケジュール部が構成変更要求２に基づいて出力するスケジュールを示す図である。 イベント情報蓄積データベース内の過去の構成変更履歴の一例を概念的に示す図である。

符号の説明

１００ 自律型コンピューティング装置
１０１ モニタリング装置
１０２ モニタリング結果データベース
１０３ 分析部
１０４ 判断部
１０５ ポリシー管理データベース
１０７ プロビジョニング装置
１０８ スケジュール部
１０９ イベント情報蓄積データベース
１１０ シミュレーション部
１００１ サーバ類
１００２ ストレージ類
１００３ ネットワーク装置類

Claims (5)

1. サービスを提供する少なくとも一つのコンピュータから構成されるコンピュータシステムと通信回線を介して接続された情報処理装置であって、
   前記コンピュータシステムの状態を示すイベント情報と、前記サービスを提供する前記コンピュータシステムの運用指針を示すポリシー情報とに基づいて、前記コンピュータシステムの構成を変更するための要求情報を生成する要求情報生成手段と、
   前記要求情報生成手段により生成される要求情報に応じた前記コンピュータシステムの構成変更処理のスケジューリングを行うスケジューリング手段と、
   前記スケジューリング手段によって生成されたスケジュールをシミュレーションするシミュレーション手段と、
   前記シミュレーション手段によるシミュレーション結果によって新たに得られるイベント情報が前記ポリシーを満たしているか否かを判定する判定手段とを有し、
   前記要求情報生成手段は、前記判定手段によって前記新たに得られるイベント情報が前記ポリシーを満たしていないと判定された場合、前記新たに得られるイベント情報と前記ポリシーとに基づいて、前記コンピュータシステムの構成を変更するための要求情報を新たに生成することを特徴とする情報処理装置。
2. 前記スケジューリング手段は、前記要求情報生成手段により生成される要求情報に応じた前記コンピュータシステムの構成変更処理を期限までに実行できるようにスケジューリングすることを特徴とする請求項１に記載の情報処理装置。
3. 前記要求情報生成手段により生成される要求情報に応じた前記コンピュータシステムの構成変更処理に要する時間を決定する決定手段を更に有し、
   前記スケジューリング手段は、前記決定手段により判定された時間を用いて前記コンピュータシステムの構成変更処理をスケジューリングすることを特徴とする請求項２に記載に情報処理装置。
4. サービスを提供する少なくとも一つのコンピュータから構成されるコンピュータシステムと通信回線を介して接続された情報処理装置による情報処理方法であって、
   前記コンピュータシステムの状態を示すイベント情報と、前記サービスを提供する前記コンピュータシステムの運用指針を示すポリシー情報とに基づいて、前記コンピュータシステムの構成を変更するための要求情報を生成する要求情報生成ステップと、
   前記要求情報生成ステップにより生成される要求情報に応じた前記コンピュータシステムの構成変更処理のスケジューリングを行うスケジューリングステップと、
   前記スケジューリングステップによって生成されたスケジュールをシミュレーションするシミュレーションステップと、
   前記シミュレーションステップによるシミュレーション結果によって新たに得られるイベント情報が前記ポリシーを満たしているか否かを判定する判定ステップとを含み、
   前記要求情報生成ステップは、前記判定ステップによって前記新たに得られるイベント情報が前記ポリシーを満たしていないと判定された場合、前記新たに得られるイベント情報と前記ポリシーとに基づいて、前記コンピュータシステムの構成を変更するための要求情報を新たに生成することを特徴とする情報処理方法。
5. サービスを提供する少なくとも一つのコンピュータから構成されるコンピュータシステムと通信回線を介して接続された情報処理装置による情報処理方法をコンピュータに実行させるためのプログラムであって、
   前記コンピュータシステムの状態を示すイベント情報と、前記サービスを提供する前記コンピュータシステムの運用指針を示すポリシー情報とに基づいて、前記コンピュータシステムの構成を変更するための要求情報を生成する要求情報生成ステップと、
   前記要求情報生成ステップにより生成される要求情報に応じた前記コンピュータシステムの構成変更処理のスケジューリングを行うスケジューリングステップと、
   前記スケジューリングステップによって生成されたスケジュールをシミュレーションするシミュレーションステップと、
   前記シミュレーションステップによるシミュレーション結果によって新たに得られるイベント情報が前記ポリシーを満たしているか否かを判定する判定ステップとをコンピュータに実行させ、
   前記要求情報生成ステップは、前記判定ステップによって前記新たに得られるイベント情報が前記ポリシーを満たしていないと判定された場合、前記新たに得られるイベント情報と前記ポリシーとに基づいて、前記コンピュータシステムの構成を変更するための要求情報を新たに生成することを特徴とするプログラム。

Images