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

Description

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

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

特許文献１に開示される発明では、この自律型コンピューティングにおいて管理する対象となる環境、即ち自律型コンピューティング環境を構成するコンピュータシステム上で或るイベントが発生すると、そのイベントに予め紐付けされたポリシーを満たすような処理が自律的に行われていた。

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

しかしながら、特許文献１に開示される発明は、例えば、自律型コンピューティング環境を構成するコンピュータシステム内の或るサーバのＣＰＵ利用率が上昇し、閾値を超えると、ノードの追加等のポリシーを満たす処理が自律的に行われるだけであった。

ノードの追加等のコンピュータシステムの構成変更は、決められた期限までに完了することが求められるとともに或る程度の時間を要する。従って、その期限に構成変更を完了するためには構成変更に要する時間を考慮すべきであるが、従来、この点については全く考慮されていない。

また、特許文献１に開示される発明においては、１カ月や１週間先等、比較的先の未来までのコンピュータシステムの構成変更のスケジュールを決定することが自律的に行うことができない。このような長期的なスケジューリングを行う際には、実際にコンピュータシステムが必要とする構成変更を的確に把握し、適切に構成変更のスケジュールを組む必要があるが、この点についても考慮されたものではない。

そこで、本発明の目的は、適切な構成変更のスケジューリングを行うことを可能とすることにある。

本発明の他の目的は、実現可能なスケジューリング結果を得ることを可能とすることにある。

更に本発明の他の目的は、構成変更に要する時間を考慮した最適なタイミングでコンピュータシステムの構成変更のスケジューリングを可能とすることにある。

本発明の情報処理装置は、少なくとも一つのコンピュータから構成されるコンピュータシステムと通信回線を介して接続される情報処理装置であって、前記コンピュータシステムの状態を示す監視データを取得し、前記監視データを取得した時点或いは前記監視データを分析した時点を示す時点情報と、前記監視データを取得した場所を示す場所情報と、前記監視データ或いは前記分析して得られた前記コンピュータシステムの状態を示す情報とを含むイベント情報を生成するイベント情報生成手段と、前記イベント情報及び前記コンピュータシステムの運用指針を示すポリシー情報に基づいて、前記ポリシー情報に従った前記コンピュータシステムの構成を示す構成情報と、前記時点情報を基準に算出された、前記構成情報に示される構成に前記コンピュータシステムを変更すべき期限を示す期限情報とを含む構成変更要求情報を生成する要求情報生成手段と、前記要求情報生成手段により生成される各構成変更要求情報について、前記要求情報生成手段により同一の構成変更要求情報が過去に生成された回数を示す信頼度情報を記録する第１の記録媒体と、前記第１の記録媒体において記録される前記信頼度情報が閾値以上の前記構成変更要求情報を選択し、選択した前記構成変更要求情報夫々に含まれる前記期限情報及び前記構成情報を用いて、前記構成変更要求情報夫々に含まれる前記期限情報に示される期限までに、当該構成変更要求情報に含まれる前記構成情報に示される構成に前記コンピュータシステムの構成を確定させることを決定する第１のスケジューリング手段と、前記第１のスケジューリング手段により決定されたコンピュータシステムの構成情報を日時情報に沿って時系列に示した構成変更履歴情報を記録した第２の記録媒体と、前記信頼度情報が前記閾値以上の前記構成変更要求情報毎に、前記構成変更要求情報に含まれる前記構成情報に示される構成に前記コンピュータシステムを変更する際に要する期間を、前記第２の記録媒体に記録される前記構成変更履歴情報に基づいて算出する変更期間算出手段と、前記変更期間算出手段によって算出された前記コンピュータシステムを変更する際に要する期間が重複し合う前記構成変更要求情報が存在する場合、該当する前記構成変更要求情報のうちの何れか一つの構成変更要求情報に示される構成情報を、前記該当する構成変更要求情報のうちの他の構成変更要求情報の構成情報へと変更する第２のスケジューリング手段とを有することを特徴とする。
本発明の情報処理方法は、少なくとも一つのコンピュータから構成されるコンピュータシステムと通信回線を介して接続される情報処理装置による情報処理方法であって、前記コンピュータシステムの状態を示す監視データを取得し、前記監視データを取得した時点或いは前記監視データを分析した時点を示す時点情報と、前記監視データを取得した場所を示す場所情報と、前記監視データ或いは前記分析して得られた前記コンピュータシステムの状態を示す情報とを含むイベント情報を生成するイベント情報生成ステップと、前記イベント情報及び前記コンピュータシステムの運用指針を示すポリシー情報に基づいて、前記ポリシー情報に従った前記コンピュータシステムの構成を示す構成情報と、前記時点情報を基準に算出された、前記構成情報に示される構成に前記コンピュータシステムを変更すべき期限を示す期限情報とを含む構成変更要求情報を生成する要求情報生成ステップと、前記要求情報生成ステップにより生成される各構成変更要求情報について、前記要求情報生成ステップにより同一の構成変更要求情報が過去に生成された回数を示す信頼度情報を記録する記録媒体において記録される前記信頼度情報が閾値以上の前記構成変更要求情報を選択し、選択した前記構成変更要求情報夫々に含まれる前記期限情報及び前記構成情報を用いて、前記構成変更要求情報夫々に含まれる前記期限情報に示される期限までに、当該構成変更要求情報に含まれる前記構成情報に示される構成に前記コンピュータシステムの構成を確定させることを決定する第１のスケジューリングステップと、前記信頼度情報が前記閾値以上の前記構成変更要求情報毎に、前記構成変更要求情報に含まれる前記構成情報に示される構成に前記コンピュータシステムを変更する際に要する期間を、前記第１のスケジューリングステップにより決定されたコンピュータシステムの構成情報を日時情報に沿って時系列に示した構成変更履歴情報を記録する記録媒体において記録される前記構成変更履歴情報に基づいて算出する変更期間算出ステップと、前記変更期間算出ステップによって算出された前記コンピュータシステムを変更する際に要する期間が重複し合う前記構成変更要求情報が存在する場合、該当する前記構成変更要求情報のうちの何れか一つの構成変更要求情報に示される構成情報を、前記該当する構成変更要求情報のうちの他の構成変更要求情報の構成情報へと変更する第２のスケジューリングステップとを含むことを特徴とする。
本発明のプログラムは、少なくとも一つのコンピュータから構成されるコンピュータシステムと通信回線を介して接続される情報処理装置による情報処理方法をコンピュータに実行させるためのプログラムであって、前記コンピュータシステムの状態を示す監視データを取得し、前記監視データを取得した時点或いは前記監視データを分析した時点を示す時点情報と、前記監視データを取得した場所を示す場所情報と、前記監視データ或いは前記分析して得られた前記コンピュータシステムの状態を示す情報とを含むイベント情報を生成するイベント情報生成ステップと、前記イベント情報及び前記コンピュータシステムの運用指針を示すポリシー情報に基づいて、前記ポリシー情報に従った前記コンピュータシステムの構成を示す構成情報と、前記時点情報を基準に算出された、前記構成情報に示される構成に前記コンピュータシステムを変更すべき期限を示す期限情報とを含む構成変更要求情報を生成する要求情報生成ステップと、前記要求情報生成ステップにより生成される各構成変更要求情報について、前記要求情報生成ステップにより同一の構成変更要求情報が過去に生成された回数を示す信頼度情報を記録する記録媒体において記録される前記信頼度情報が閾値以上の前記構成変更要求情報を選択し、選択した前記構成変更要求情報夫々に含まれる前記期限情報及び前記構成情報を用いて、前記構成変更要求情報夫々に含まれる前記期限情報に示される期限までに、当該構成変更要求情報に含まれる前記構成情報に示される構成に前記コンピュータシステムの構成を確定させることを決定する第１のスケジューリングステップと、前記信頼度情報が前記閾値以上の前記構成変更要求情報毎に、前記構成変更要求情報に含まれる前記構成情報に示される構成に前記コンピュータシステムを変更する際に要する期間を、前記第１のスケジューリングステップにより決定されたコンピュータシステムの構成情報を日時情報に沿って時系列に示した構成変更履歴情報を記録する記録媒体において記録される前記構成変更履歴情報に基づいて算出する変更期間算出ステップと、前記変更期間算出ステップによって算出された前記コンピュータシステムを変更する際に要する期間が重複し合う前記構成変更要求情報が存在する場合、該当する前記構成変更要求情報のうちの何れか一つの構成変更要求情報に示される構成情報を、前記該当する構成変更要求情報のうちの他の構成変更要求情報の構成情報へと変更する第２のスケジューリングステップとをコンピュータに実行させることを特徴とする。

本発明においては、コンピュータシステムの構成を変更するための要求情報が生成されると、その要求情報に対応する要求情報の履歴が管理されている場合にその信頼度を更新し、所定の条件を満たす信頼度の要求情報の履歴に基づいて更新変更処理のスケジューリングを行うように構成している。従って、本発明によれば、同じ要求情報が数回生成された場合に信頼性がある要求情報の履歴として扱い、その信頼性のある要求情報の履歴に基づいてスケジューリングを行うことができるため、適切な構成変更のスケジューリングを行うことが可能となる。

また本発明においては、各要求情報の履歴に対応して計画された構成変更に要する期間が重複しないようにスケジューリング結果を修正するようにしているため、実現可能なスケジューリング結果を得ることが可能となる。併せて、リソースの割り当てタイミングが調整されることによって、リソースの利用の効率化が可能となる。

また本発明においては、コンピュータシステムの構成変更に要する時間を判定し、その判定結果に基づいてコンピュータシステムの構成変更処理のスケジューリングを行うように構成している。従って、本発明によれば、構成変更に要する時間を考慮した最適なタイミングでコンピュータシステムの構成変更のスケジューリングが可能となる。

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

図１は、本発明の実施形態に係る自律型コンピューティング装置の機能的な構成を示すブロック図である。本発明の実施形態に係る自律型コンピューティング装置は、長期的なスケジューリング処理と短期的なスケジューリング処理を行うことが可能である。長期的なスケジューリング処理とは、１カ月や１週間先等、比較的先の未来までのコンピュータシステムの構成変更のスケジュールを決定するための処理であり、短期的なスケジューリング処理は、負荷が急増した場合等、比較的近未来のコンピュータシステムの構成変更のスケジュールを決定するための処理である。ここでは先ず、長期的なスケジューリング処理を行う場合について説明を行い、次に短期的なスケジューリング処理を行う場合について説明する。

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

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

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

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

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

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

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

判断部１０４は、分析部１０３或いはモニタリング結果データベース１０２からイベント情報を取得すると、ポリシー管理データベース１０５から当該イベント情報に該当する現在の構成情報及びポリシーを取得し、自律型コンピューティング環境の構成変更の要求情報である構成変更要求を生成し、スケジュール部１０８に出力する。

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

スケジュール部１０８は、判断部１０４から構成変更要求を入力される度に、その構成変更要求と同じ内容の構成変更要求の履歴が存在するか否かを判定し、存在すれば、当該構成変更要求の履歴について信頼度の値を加算していき、信頼度が閾値以上である構成変更要求に対してスケジューリング処理を行う。なお、構成変更要求の履歴の詳細については後述する。

プロビジョニング装置１０７は、スケジュール部１０８によるスケジューリング結果に従って、自律型コンピューティング環境に対するプロビジョニング処理を実行する。

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

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

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

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

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

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

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

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

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

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

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

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

続いて、スケジュール部１０８は、判断部１０４より出力される構成変更要求に基づいて、理想的なスケジューリング処理を行う（ステップＳ３０５）。次に、スケジュール部１０８は、ステップＳ３０５の処理により生成される理想的なスケジュールに基づいて、実現可能なスケジューリング処理を行う（ステップＳ３０６）。ステップＳ３０５、Ｓ３０６の理想的なスケジューリング処理、実現可能なスケジューリング処理の詳細については、後述する。

続いて、プロビジョニング装置１０７は、ステップＳ３０６により生成される実現可能なスケジュールに従って、構成変更処理を自律型コンピューティング環境に対して実行する（ステップＳ３０７）。

図６は、本実施形態において監視対象とする自律型コンピューティング環境の一例を示す図である。ここでは、サーバ類１００１であるＷｅｂサーバ１〜４、ＡＰサーバ１及びＤＢサーバ１〜２、並びに、ストレージ類１００２であるＤＢが、互いにネットワークを装置類１０３である通信回線を介して接続されるコンピュータシステムを例に挙げている。なお、図６におけるＡＰサーバ２〜５は上記通信回線に同様に接続されているが、稼働していない状態にあり、必要に応じてコンピュータシステムに追加される予備のサーバであることを示している。また、これら予備のＡＰサーバ２〜５は、ＡＰサーバとして追加されるだけではなく、他のサービスを提供するサーバ、例えばＷｅｂサーバやＤＢサーバ等、必要に応じた追加がなされる。

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

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

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

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

判断部１０４は、図８に示すイベント情報を取得した場合、図９示すポリシーのほか、当該自律型コンピューティング環境に該当する図７に示す現在の構成情報をポリシー管理データベース１０５から取得する。

図１０は、判断部１０４によって生成される構成変更要求の構成を概念的に示す図である。図１０に示すように、構成変更要求には、対象、期限及び内容が含まれる。対象は、当該構成変更要求により構成変更を要求する対象を示す。期限は、後述する内容に示される台数の構成に変更する期限である。内容は、その対象について要求する構成変更の内容である。なお、図１０では説明のために概念的に示しているが、実際には、コンピュータが理解できるようプログラミング言語で表現されている。なお、構成変更要求に関する他の図においても同様である。

判断部１０４は、分析部１０３或いはモニタリング結果データベース１０２からイベント情報を取得すると、ポリシー管理データベース１０５から当該イベント情報に該当するポリシー及び現在の構成情報を取得し、自律型コンピューティング環境の構成変更の要求情報である構成変更要求を生成する。具体的には、判断部１０４は、モニタリング結果データベース１０２或いは分析部１０３から取得したイベント情報に含まれる「発生場所」から構成変更要求の「対象」を生成する。

また、判断部１０４は、イベント情報に含まれる「内容」に対応する「ルール」を含むポリシーをポリシー管理データベース１０５から検索し、検索された当該ポリシーの「ルール」に基づいて、構成変更要求の「内容」を生成する。例えば、イベント情報１の「内容」にある"１台当りのＣＰＵ利用率が１日後に６０％を越える"という情報に対応するルール"ＣＰＵ利用率が６０％を超える場合"を含んだポリシー１の「ルール」に基づいて、構成変更要求の「内容」を"ＡＰサーバ２台構成"として生成する。同様に、イベント情報に含まれる「内容」から、構成変更要求の「期限」を生成する。例えば、イベント情報１の「内容」にある"１日後"という情報から、イベント情報１が取得された日時、即ち2007/04/01 13:00から１日後に当る2007/04/02 13:00が構成変更要求の「期限」として生成される。

図４は、図３のステップＳ３０５の理想的なスケジューリング処理の詳細を示すフローチャートである。

図４において、先ずスケジュール部１０８は、判断部１０４が生成した構成変更要求を取得する（ステップＳ４０１）。続いて、スケジュール部１０８は、当該構成変更要求の対象、期限及び内容と一致する構成変更要求履歴を構成変更要求履歴テーブルから検索する（ステップＳ４０２）。なお、構成変更要求履歴テーブルは、ＲＡＭ２０２等記録媒体内に格納される情報である。

図１１は、長期間のスケジューリング処理により生成される構成変更要求履歴テーブルの構成の一例を概念的に示す図である。図１１に示すように、構成変更要求履歴テーブルは、判断部１０４から入力される構成変更要求の履歴（構成変更要求履歴）を各レコードとして登録する。構成変更要求履歴は、ジョブＩＤと、構成変更要求の対象と、期限及び内容と、信頼度とを含む。ジョブＩＤは、構成変更要求に応じて実行されるプロビジョニング処理であるジョブを一意に識別するためのＩＤである。構成変更要求の対象、期限及び内容の各情報は既に説明した該当する構成変更要求に係る情報である。信頼度は、該当する構成変更要求履歴によるジョブを実行するかしないかをその値によって判定するための情報である。

続いて、スケジュール部１０８は、構成変更要求履歴テーブル内に、ステップＳ４０１で入力した構成変更要求の各要素と一致する内容を含む構成変更要求履歴が存在するか否か判定する（ステップＳ４０３）。入力した構成変更要求の各要素と一致する内容を含む構成変更要求履歴が存在する場合、処理はステップＳ４０５に移行する。一方、入力した構成変更要求の各要素と一致する内容を含む構成変更要求履歴が存在しない場合、処理はステップＳ４０４に移行する。

ステップＳ４０４において、スケジュール部１０８は、入力した構成変更要求の各要素を含む構成変更要求履歴を構成変更要求履歴テーブルに新規に登録する。ステップＳ４０５では、スケジュール部１０８は、入力した構成変更要求の各要素と一致する内容を含む構成変更要求履歴内の信頼度の値を加算する。

例えば、図１１に示す構成変更要求履歴テーブルが既に生成されており、図１０に示す構成変更要求が判断部１０４からスケジュール部１０８に入力された場合、構成変更要求履歴テーブルの最上段のレコードに登録されるジョブ１の構成変更要求履歴が当該構成変更要求の各要素と一致する内容を含んでいる。このような場合、スケジュール部１０８は、当該構成変更要求履歴の信頼度を加算する。ここでは、加算する値として５を想定している。また、信頼度の初期値は５０としており、ステップＳ４０４において新規に構成変更要求履歴が登録された時点では、当該構成変更要求履歴の信頼度には５０が登録される。以降、この構成変更要求履歴内の構成変更要求の各要素と一致する構成変更要求が入力される度に、当該構成変更要求履歴の信頼度を５ずつ加算していく。なお、初期値及び信頼度で用いた具体的数値に関しては、この数値に限らないことは言うまでも無い。

続いて、スケジュール部１０８は、信頼度が閾値８０以上の構成変更要求履歴を使用して理想的なスケジューリング処理を行う（ステップＳ４０６）。このスケジューリング処理を図１１の例を用いて具体的に説明する。

図１２は、図１１に示す構成変更要求履歴テーブルを用いて理想的なスケジューリングを行った結果を示す図である。図１１に示す構成変更要求履歴テーブル内には信頼度が８０以上の構成変更要求履歴として、ジョブ１〜５、７、８の７つ構成変更要求履歴が存在する。

スケジュール部１０８は、上記７つの構成変更要求履歴を用いてスケジューリング処理を行う。即ち、ジョブ１の構成変更要求履歴には、期限として「2007/4/2 13:00」、内容として「ＡＰサーバ２台構成」が登録されている。図１２中、ジョブ１の矢印が示す位置がジョブ１の期限「2007/4/2 13:00」であり、この期限までにジョブ１によってＡＰサーバが２台構成に確定される状態にあることを示している。同じく、ジョブ２の矢印が示す位置がジョブ２の期限「2007/4/3 13:00」であり、この期限までにジョブ２によってＡＰサーバが３台構成に確定される状態にあることを示している。ジョブ６を除くジョブ３〜ジョブ８についても同様のことが示されている。以上が、信頼性の高い構成変更要求に基づいた、将来のシステム環境における理想的なスケジューリング処理の一例である。

図５−１及び図５−２は、図３のステップＳ３０６の実現可能なスケジューリング処理の詳細を示すフローチャートである。

図５−１において、先ずスケジュール部１０８は、対象となるジョブと、当該ジョブの直前のジョブとを理想的なスケジューリング結果から検索する（ステップＳ５０１）。本実施形態では、未来のジョブから順次処理の対象としていく。図１２に示す例では、ジョブ８が最も未来のジョブとなる。従って、ステップＳ５０１においては、ジョブ８が最初に対象のジョブとして検索されるとともに、その直前のジョブであるジョブ７が検索されることになる。

続いて、スケジュール部１０８は、当該ジョブによる構成変更に要する時間と当該ジョブの直前のジョブによる構成変更に要する時間とを算出する（ステップＳ５０２）。

図５−３及び図５−４は、図５−1のステップＳ５０２の構成変更に要する時間の算出方法の詳細を示すフローチャートである。

図５−３において、先ずスケジュール部１０８は、ジョブ８の直前のジョブ７完了時におけるコンピュータシステムの構成を特定する。具体的には、ジョブ８直前の時間と一致する日時情報におけるシステム構成を未来の構成情報から検索し、これに基づいて、ジョブ８直前のジョブ７完了時におけるシステムの構成を特定する。当該未来の構成情報について図示を省略するが、ジョブ７完了時においては、Ｗｅｂサーバ１〜４、ＡＰサーバ１〜４及びＤＢサーバ１〜２から構成されるコンピュータシステムが稼働し、これを構成変更の対象とする。従って、スケジュール部１０８は、Ｗｅｂサーバ１〜４、ＡＰサーバ１〜４及びＤＢサーバ１〜２で構成されるコンピュータシステムと同じ構成である時期をイベント情報蓄積データベース１０９内の構成変更履歴から探索する（ステップＳ５１１）。

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

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

図１５において、各同じ日時について、Ｗｅｂサーバ１〜４、ＡＰサーバ１〜５及びＤＢサーバ１〜２の１１のサーバに関するレコードが存在する。例えば、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にＡＰサーバ４が除外され、ＡＰサーバが３台となる履歴が登録されているため、スケジュール部１０８は、図１５の構成変更履歴を参照した場合、構成変更履歴内に当該ジョブ８の構成変更要求履歴の「内容」と同じ構成変更の記録が存在すると判定する。

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

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

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

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

続いてスケジュール部１０８は、ジョブ７の直前のジョブ５完了時におけるコンピュータシステムの構成を特定する。具体的には、ジョブ７直前の時間と一致する日時情報におけるシステム構成を未来の構成情報から検索し、これに基づいて、ジョブ７直前のジョブ５完了時におけるシステムの構成を特定する。当該未来の構成情報について図示を省略するが、ジョブ５完了時においては、Ｗｅｂサーバ１〜４、ＡＰサーバ１〜５及びＤＢサーバ１〜２から構成されるコンピュータシステムが稼働し、これを構成変更の対象とする。従って、スケジュール部１０８は、Ｗｅｂサーバ１〜４、ＡＰサーバ１〜５及びＤＢサーバ１〜２で構成されるコンピュータシステムと同じ構成である時期をイベント情報蓄積データベース１０９内の構成変更履歴から探索する（ステップＳ５１９）。

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

図１６は、イベント情報蓄積データベース１０９内の構成変更履歴の他の例を概念的に示す図である。図１６に示すように、2007/2/17 16:00には、Ｗｅｂサーバ１〜４の役割として「Web」が登録され、ＡＰサーバ１〜５の役割として「AP」が登録され、ＤＢサーバ１〜２の役割として「DB」が登録される。これは、２００７年２月１７日１６時において、Ｗｅｂサーバ１〜４、ＡＰサーバ１〜５及びＤＢサーバ１〜２から構成されるコンピュータシステムが稼働していることを示している。

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

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

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

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

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

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

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

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

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

再び図５−1の説明に戻る。スケジュール部１０８は、対象のジョブ（最初はジョブ８）の構成変更期間と直前のジョブの構成変更期間とが重複するか否かを判定する（ステップＳ５０３）。当該ジョブの構成変更期間は、当該ジョブがその直前のジョブ完了時より台数が増加するジョブであれば、当該ジョブの期限より当該ジョブの構成変更に要する時間分遡った時点から、当該ジョブの期限までの期間となる。一方、当該ジョブがその直前のジョブ完了時より台数が減少するジョブであれば、当該ジョブの構成変更期間は、当該ジョブの期限から、当該ジョブの期限より当該ジョブの構成変更に要する時間分経過した時点までの期間となる。また、直前のジョブの構成変更期間は、直前のジョブがその直前（当該ジョブの２つ前）のジョブ完了時より台数が増加するジョブであれば、直前のジョブの期限より直前のジョブの構成変更に要する時間分遡った時点から、直前のジョブの期限までの期間となる。一方、直前のジョブが当該ジョブの２つ前のジョブ完了時より台数が減少するジョブであれば、直前のジョブの構成変更期間は、直前のジョブの期限から、直前のジョブより直前のジョブの構成変更に要する時間分経過した時点までの期間となる。

例えば、ジョブ７の期限が「2007/4/7 13:00」であり、ジョブ８の期限が「2007/4/7 13:30」である場合、ジョブ７の構成変更期間が２０分、ジョブ８の構成変更期間が４０分であるため、ジョブ７の構成変更期間とジョブ８の構成変更期間とは重複することになる。このような場合、スケジュール部１０８は、当該ジョブの構成変更期間とその直前のジョブの構成変更期間とが重複すると判定する。

当該ジョブの構成変更期間と直前のジョブの構成変更期間とが重複すると判定される場合、処理はステップＳ５０４に移行する。一方、これらの期間が重複しないと判定される場合、処理は図５−２のステップＳ５１０に移行する。

ステップＳ５０４において、スケジュール部１０８は、当該ジョブの２つ前のジョブによる変更後の台数から、当該ジョブの直前のジョブによる変更後の台数が増加し、且つ当該ジョブの直前のジョブによる変更後の台数から当該ジョブによる変更後の台数が増加しているか否かをＳ３０５で処理した理想的なスケジューリング結果から判定する。

２つ前のジョブによる変更後の台数から直前のジョブによる変更後の台数が増加し、且つ直前のジョブによる変更後の台数から当該ジョブによる変更後の台数が増加している場合には、処理はステップＳ５０５に移行する。一方、そうでない場合には、処理はステップＳ５０５を実行することなく図５−２のステップＳ５０６に移行する。

ステップＳ５０５において、スケジュール部１０８は、当該ジョブの直前のジョブによる変更後の台数を当該ジョブによる変更後の台数まで増やすようにＳ３０５で処理した理想的なスケジュール結果を修正する。そして、処理はステップＳ５０６に移行する。

ステップＳ５０６においては、スケジュール部１０８は、当該ジョブの２つ前のジョブによる変更後の台数から当該ジョブの直前のジョブによる変更後の台数が減少し、且つ当該ジョブの直前のジョブによる変更後の台数から当該ジョブによる変更後の台数が増加しているか否かを判定する。２つ前のジョブによる変更後の台数から直前のジョブによる変更後の台数が減少し、且つ直前のジョブによる変更後の台数から当該ジョブによる変更後の台数が増加している場合、処理はステップＳ５０７に移行する。一方、そうでない場合には、処理はステップＳ５０７を実行することなくステップＳ５０８に移行する。

ステップＳ５０７において、スケジュール部１０８は、当該ジョブの直前のジョブによる変更後の台数を、当該ジョブの２つ前のジョブの変更後の台数まで増やすように理想的なスケジュール結果を修正する。そして、処理はステップＳ５０８に移行する。

ステップＳ５０８においては、スケジュール部１０８は、当該ジョブの２つ前のジョブによる変更後の台数から当該ジョブの直前のジョブによる変更後の台数が減少し、且つ当該ジョブの直前のジョブによる変更後の台数から当該ジョブによる変更後の台数が減少したか否かを判定する。２つ前のジョブによる変更後の台数から直前のジョブによる変更後の台数が減少し、且つ直前のジョブによる変更後の台数から当該ジョブによる変更後の台数が減少した場合、処理はステップＳ５０９に移行する。一方、そうでない場合、処理はステップＳ５０９を実行することなく処理はステップＳ５１０に移行する。

ステップＳ５０９において、スケジュール部１０８は、当該ジョブによる変更後の台数を、当該ジョブの直前のジョブによる変更後の台数まで増やすようにＳ３０５で処理した理想的なスケジューリング結果を修正する。そして、処理はステップＳ５１０に移行する。

ステップＳ５１０においては、スケジュール部１０８は、対象となるジョブ全てについて処理を行ったか否かを判定する。ここでいう対象となるジョブ全てとは、本処理においては、当該ジョブの２つ前のジョブまでをステップＳ５０４等の処理に使用するため、Ｓ３０５で処理した理想的なスケジューリング結果における最も未来のジョブから最も過去から２つ前のジョブまでとなる。図１２の例では、ジョブ８から始まってジョブ３まで上述した処理が繰り返されることになる。

ここで、図１３及び図１４を用いて、実現可能なスケジューリング処理について具体的に説明する。図１３は、Ｓ３０５で処理した理想的なスケジューリング結果と各ジョブの構成変更期間を示す図である。図１４は、実現可能なスケジューリング結果を示す図である。

図１３において、１３０１はジョブ２の構成変更期間、１３０２はジョブ３の構成変更期間、１３０３はジョブ４の構成変更期間、１３０４はジョブ５の構成変更期間、１３０５はジョブ７の構成変更期間、１３０６はジョブ８の構成変更期間を示している。

図１３において、ジョブ２の構成変更期間１３０１とジョブ３の構成変更期間とが重複し、ジョブ４の構成変更期間１３０３とジョブ５の構成変更期間１３０４とが重複し、ジョブ７の構成変更期間１３０５とジョブ８の構成変更期間とが重複している場合を例示している。この場合、ステップＳ５０３において構成変更期間が重複すると判定されるときの当該ジョブは、ジョブ８、ジョブ５、ジョブ３となる。

ジョブ８を対象にした場合、２つ前のジョブ５による変更後の台数から直前のジョブ７による変更後の台数が減少し、且つ直前のジョブ７による変更後の台数から当該ジョブ８による変更後の台数が減少している。従って、スケジュール部１０８は、当該ジョブ８による変更後の台数を、当該ジョブ９の直前のジョブ７による変更後の台数まで増やすように修正する。

ジョブ５を対象とした場合、２つ前のジョブ３による変更後の台数から直前のジョブ４による変更後の台数が減少し、直前のジョブ４による変更後の台数から当該ジョブ５による変更後の台数が増加している。従って、スケジュール部１０８は、直前のジョブ４による変更後の台数を、２つ前のジョブ３による変更後の台数まで増やすように修正する。

ジョブ３を対象とした場合、２つ前のジョブ１による変更後の台数から直前のジョブ２による変更後の台数が増加し、直前のジョブ２による変更後の台数から当該ジョブ３による変更後の台数が増加している。従って、スケジュール部１０８は、直前のジョブ２による変更後の台数を当該ジョブ３による変更後の台数まで増やすように修正する。

以上のように、構成変更期間が重複するジョブが存在する場合、該当するジョブのうちの何れか一つのジョブの台数に他のジョブの台数を変更するようにＳ３０５で処理した理想的なスケジューリング結果を修正することにより、図１４に示すような実現可能なスケジューリング結果となる。図１４に示すように、実現可能なスケジューリング結果においては、ジョブ２の構成変更期間１４０１、ジョブ５の構成変更期間１４０２及びジョブ７の構成変更期間１４０３だけを設ければよい。従って、従来は、ジョブ間の衝突によって構成変更要求が混在しスケジューリングが不明確であったが、上述のようなスケジューリング処理によって、最小限の構成変更、且つ、ジョブ間における構成変更期間の重複がなくなり、実現可能なスケジュールとなる。

また、ジョブ２の期限（ジョブ２の矢印の位置）からジョブ２の構成変更期間１４０１だけ遡った時点に構成変更を開始するようにスケジュール部１０８がスケジューリングすることにより、プロビジョニング装置１０７は構成変更期間を考慮した適切なタイミングで構成変更を開始することが可能となる。ジョブ５についても同様である。

図１７は、長期的なスケジューリング処理における複数のサービスＡ〜Ｄの残りのノード数を管理するためのリソースプール管理テーブルの構成を概念的に示す図である。本図におけるリソースプールＡ〜Ｄは夫々、サービスＡ〜ＤにおけるＡＰサーバの残り数である。なお、リソースプール管理テーブルは、例えばＲＡＭ２０２等の記録媒体内に格納される情報である。

リソースプール管理テーブルは、長期的なスケジューリング処理における実現可能なスケジューリング処理により確定した各サービスＡ〜Ｄのジョブのスケジュールと、各サービスＡ〜Ｄのコンピュータシステムの構成情報とによって更新されるテーブルである。

例えば、サービスＡについて参照すると、実現可能なスケジューリング処理によって４月６日にジョブ２３が予定され、ここで３台のＡＰサーバを追加稼働させることが計画されている。４月５日以前には、サービスＡにおけるＡＰサーバの残り数は１０台であったため、４月６日以降は７台と記録されている。

スケジュール部１０８が、受信した構成変更要求を参照し、構成変更要求の"内容"に関する情報（例：ジョブ２３の"３台のＡＰサーバを追加稼働"）に基づいて、構成変更要求の"期限"（４月６日）におけるリソースプール管理テーブルのリソースプールＡに関する情報を更新する（４月６日以降は７台と記録する）処理を行う。

サービスＢについては、実現可能なスケジューリング処理によって４月２日にジョブ２１が予定され、ここで５台のＡＰサーバを追加稼働させることが計画されている。４月１日以前には、サービスＢにおけるＡＰサーバの残り数は１０台であったため、４月２日以降は５台と記録されている。処理については、サービスＡと同様である。

サービスＣについては、実現可能なスケジューリング処理によって４月４日にジョブ２２が予定され、ここで８台のＡＰサーバを追加稼働させることが計画されている。４月３日以前には、サービスＣにおけるＡＰサーバの残り数は１０台であったため、４月４日以降には２台と記録されている。処理については、サービスＡと同様である。

サービスＤについては、実現可能なスケジューリング処理によって４月７日にジョブ２４が予定され、ここで２台のＡＰサーバを追加稼働させることが計画されている。４月６日以前には、サービスＤにおけるＡＰサーバの残り数は１０台であったため、４月７日以前には８台と記録されている。処理については、サービスＡと同様である。

なお、信頼度の設定方法には、手動と予測分析とがある。手動の信頼度の設定方法とは、手動はユーザの操作によってジョブと信頼度の双方が設定される、又は、手動によってジョブが設定されることに伴い所定の値の信頼度が自動的に設定されることを意味する。何れのケースで信頼度が設定された場合も、ユーザの手動操作によって設定されたジョブは必ず実行するものとして、信頼度は閾値８０より高い数値（例えば、９５）が設定される。なお、手動によってジョブが設定されるのは、例えば１週間後に停電が予定されており、その際にはコンピュータシステムの稼働を停止させるようにする等、必ず実行する必要があるジョブを設定するケースが挙げられる。予測分析は、上述した図４のステップＳ４０３の判定処理とその判定結果に基づくステップＳ４０５の数値の加算処理によって信頼度が更新されるものである。

このようにリソースプール管理テーブル上においてＡＰサーバ等のノードの残り数を管理することによって、どのサービスのコンピュータシステムで補充可能なＡＰサーバが残り少なくなるのかを判定することができる。判定の方法としては、所定の閾値（例えば、２台）とＡＰサーバの残り数とを比較し、ＡＰサーバの残り数が閾値以下となった場合に補充可能なＡＰサーバの数が少ないと判定することが挙げられる。補充可能なＡＰサーバの数が少ないと判定された場合、ＡＰサーバが不足すること及びそのタイミングを警告する情報をディスプレイ２０９に表示させる。このようにすることで、ユーザは事前にどのサービスにおいていつノード（リソース）が不足するのかを把握することが可能となる。従って、上述の処理によって生成された理想的且つ実現可能なスケジュールを実行するに当って、リソースプール管理テーブルを参照することによって、リソース割当を調整することによるリソース利用の効率化を図ることができる。

また、スケジュール部１０８は、上記のように或るサービスのコンピュータシステムにおいてノードが不足すると判定された場合、他のサービスのコンピュータシステムの予備のノードからその不足分を補充することもできる。その際に、スケジュール部１０８は、ＳＬＡ（Service Level Agreement）を用いて不足分を補充する先のサービスを決定する。

ＳＬＡの具体例を図２８に示す。図２８に示すように、ＳＬＡとは、サービス提供者（プロバイダ）とサービス委託者（顧客）との間で取決めた提供するサービスの内容と範囲（「サービスの適用範囲と説明」、「サービス時間」、「サポートの詳細」）、品質に対する要求（達成）水準（「可用性と信頼性の指標」、「応答時間と修復時間」）やそれが達成できなかった場合のルール（「構成変更の優先度」）等に関する規定である。本実施形態では、ＳＬＡをデータとしてポリシー管理データベース１０５に保持しておき、上述したように或るサービスのコンピュータシステムにおいてノードが不足すると判定された場合、スケジュール部１０８がこれを取得し、どのサービスからノードを補充するかをＳＬＡに基づいて決定する。例えば、サービスＣが顧客向けのサービスであり、サービスＡが社内向けのサービスであり、サービスＡよりサービスＣの方が優先度が高いといった規定内容のＳＬＡが記述されたデータがポリシー管理データベース１０５に登録されている場合には、スケジュール部１０８は、その記述内容を参照して、ノード不足が発生する予定のサービスＣのコンピュータシステムにサービスＡのノードを追加稼働させるようにスケジューリングを行う。なお、ＳＬＡには、各サービスに対する優先度だけではなく、他のサービスへのノードの追加を許可する、しないを示すフラグを記述してもよい。この場合、サービス間の優先度の比較とフラグとを考慮したノード追加を含むスケジューリングが行われる。

以下に、ＳＬＡを用いた実施形態について述べる。図２３は、本例における未来（2007/4/17 15:00）の構成情報の構成を概念的に示す図である。図２３に示すように、サービスＡを提供するコンピュータシステムは、Ｗｅｂサーバ１、ＡＰサーバ１、ＡＰサーバ２及びＤＢサーバ１により構成される。サービスＢを提供するコンピュータシステムは、Ｗｅｂサーバ２、ＡＰサーバ３、ＡＰサーバ４及びＤＢサーバ２により構成される。なお、ＡＰサーバ５は、サービスＡを提供するコンピュータシステム、サービスＢを提供するコンピュータシステムの何れとしても動作しておらず、いわば予備のＡＰサーバとして管理されている。

図２４は、自律型コンピューティング装置１００が上述したサービスＡ、サービスＢを提供する２つのコンピュータシステムを監視対象とした場合に、判断部１０４がモニタリング結果データベース１０２及び分析部１０３から取得するイベント情報の一例を示す図である。

図２４においては、４つのイベント情報を例示している。ここでは、イベント情報５〜イベント情報８の日時情報は全て2007/4/17 12:00である。これはイベント情報５〜８の全てが同じ日時に生成されたことを示している。また、イベント情報５、６において発生場所としてサービスＡを提供するコンピュータシステムのＡＰサーバであることが示されている。即ち、イベント情報５、６において示される内容がサービスＡを提供するコンピュータシステムのＡＰサーバであることを意味している。また、イベント情報７、８において発生場所としてサービスＢを提供するコンピュータシステムのＡＰサーバであることが示されている。即ち、イベント情報７、８において示される内容がサービスＢを提供するコンピュータシステムのＡＰサーバであることを意味している。イベント情報５の内容としては、「ＡＰサーバ１、２のＣＰＵ利用率が３時間後に６０％を越える」ことが示されている。また、イベント情報６の内容としては、「ＡＰサーバ１、２のネットワーク（Ｎ／Ｗ）流用が減少傾向」であることが示されている。また、イベント情報７の内容としては、「ＡＰサーバ３、４のＣＰＵ利用率が３時間後に６０％を越える」ことが示されている。また、イベント情報８の内容としては、「ＡＰサーバ３、４のネットワーク（Ｎ／Ｗ）流用が減少傾向」であることが示されている。

図２５は、図２４に示すイベント情報に該当するポリシーの構成を概念的に示す図である。ここでは、イベント情報５〜６の発生場所のサービスＡ及びＡＰサーバに関係するポリシーが選択され、そのなかで、最適なＣＰＵ利用率の基準を示すポリシー３と、ＣＰＵ利用率が６０％を越えるときに適用されるポリシー４とが選択されるとともに、イベント情報７〜８の発生場所のサービスＢ及びＡＰサーバに関係するポリシーが選択され、そのなかで、最適なＣＰＵ利用率の基準を示すポリシー５と、ＣＰＵ利用率が６０％を越えるときに適用されるポリシー６とが選択される。

図２５に示すように、ポリシー３、４の適用箇所は、サービスＡを提供するコンピュータシステムのＡＰサーバであることが示されている。また、ポリシー３のルールとしては、「１台当たりのＣＰＵ利用率は４０％に抑える」ことが示されている。ポリシー４のルールとしては、「１台当たりのＣＰＵ利用率が６０％を越える場合、３台構成とする」ことが示されている。ポリシー５のルールとしては、「１台当たりのＣＰＵ利用率は４０％程度に抑える」ことが示されている。ポリシー６のルールとしては、「１台当たりのＣＰＵ利用率が６０％を越える場合、３台構成とする」ことが示されている。

判断部１０４は、図２４に示すイベント情報を取得した場合、図２５に示すポリシーのほか、当該自律型コンピューティング環境に該当する図２３に示す現在の構成情報をポリシー管理データベース１０５から取得する。

図２６は、判断部１０４によって生成される構成変更要求の構成を概念的に示す図である。図２６に示す構成変更要求３は、判断部１０４が図２５に示すポリシー４に基づいて生成する構成変更要求であり、ポリシー４内の「３台構成にする」を内容として含んだものとなっている。また、図２６に示す構成変更要求４は、判断部１０４が図２５に示すポリシー６に基づいて生成する構成変更要求であり、ポリシー６内の「３台構成にする」を内容として含んだものとなっている。

次に、スケジュール部１０８は、判断部１０４によって生成された構成変更要求に基づいてスケジュール情報の生成を行うが、判断部１０４から受信した構成変更要求の期限に関する情報を参照し、当該期限におけるシステム構成をポリシー管理データベースに格納された未来（2007/4/17 15:00）の構成情報を参照し、空いているＡＰサーバはＡＰサーバ５の１台であることを把握することができるため、サービスＡとサービスＢとの双方をＡＰサーバ３台とするためには予備のＡＰサーバが１台足りないと把握できる。本来、サービスＡとサービスＢとの双方のＡＰサーバを３台とするスケジュール情報を生成すべきであるが、このようにＡＰサーバが不足している場合には、スケジュール部１０８は、ポリシー管理データベース１０５からＳＬＡを取得し、取得したＳＬＡに基づいてスケジュール情報を生成する。なお、上述の通り、リソースプール管理テーブルは構成情報に基づいて作成されものであり、従って、リソースプール管理テーブルを参照して、空いているサーバ（リソース）を把握してもよいことは言うまでもない。

例えば、図２８に示すＳＬＡが取得された場合、当該ＳＬＡにはサービスＢよりサービスＡを優先させること（サービスＡ＞サービスＢ）が記述されているので、スケジュール部１０８は、図２７に示すようなスケジュール情報を生成する。図２７は、ＳＬＡを使用して生成されるスケジュール情報の構成を概念的に示す図である。

図２７に示すようにスケジュール情報には、構成変更の対象としてサービスＡを提供するコンピュータシステムのＡＰサーバ、構成変更の内容としてＡＰサーバを３台とすることが示されている。

このように、上述した例のＳＬＡを使用して生成されるスケジュール情報は、構成変更要求３のみに基づくものであり、構成変更要求４に基づいては生成されない。

実行部１０６は、構成変更要求３に基づくスケジュール情報から、サービスＡを提供するコンピュータシステムに対してＡＰサーバを３台とする構成変更命令を生成する。プロビジョニング装置１０７は、当該構成変更命令に基づいて、サービスＡを提供するコンピュータシステムのＡＰサーバを３台とするプロビジョニング処理を実行する。

このように、本実施形態においては、複数のサービスを提供するコンピュータシステムを対象とし、このコンピュータシステムに追加するノードが不足している場合、ＳＬＡに基づいて何れのサービスを提供しているコンピュータシステムにノードを追加するのかを決定することができる。また、ＳＬＡは図２８の構成に限る必要はなく、各サービスの優先度を表現する構成であればよい。例えば、各サービスに対する優先度については、サービスＡ＝３、サービスＢ＝２、サービスＣ＝１のように優先度を数値として扱った構成にしてもよい。

以上のように、本実施形態においては、構成変更要求が生成されると、その構成変更要求に対応する構成変更要求履歴が管理されているか場合にその信頼度を更新し、閾値以上の信頼度の構成変更要求履歴のみを用いてスケジューリングを行うように構成している。従って、同じ構成変更要求が数回生成された場合に、対応する構成変更要求履歴が信頼性があるものとして扱い、その信頼性のある構成変更要求履歴を用いてスケジューリングを行うことができるため、適切な構成変更のスケジューリングを行うことが可能となる。また、既存のスケジュールに変更をきたすようなイベントが突発的に発生した場合であっても、この突発的に発生したイベントに基づいた構成変更要求やスケジュールを新たに生成し、かつ当該信頼度の値を最も高く設定する。一方既存のスケジュールに対応した構成変更要求履歴が管理している信頼度の値は加算されなくなる為、新たなイベントが発生した場合であっても、動的にスケジュールを変更でき、適切な構成変更のスケジューリングを行うことが可能となる。

また本実施形態においては、各構成変更要求履歴に対応して計画された構成変更の期間が重複しないように理想的なスケジューリング結果を修正するようにしているため、実現可能なスケジューリング結果を得ることが可能となる。

また本実施形態においては、コンピュータシステムの構成変更に要する時間を判定し、その判定結果に基づいてコンピュータシステムの構成変更処理のスケジューリングを行うように構成している。従って、構成変更に要する時間を考慮した最適なタイミングでコンピュータシステムの構成変更のスケジューリングが可能となる。

次に、比較的短いサイクルで対応せねばならないイベントが発生し、それに対応してその当日にジョブのスケジューリングを行う等、短期間のスケジューリングを行う場合について説明する。

短期間のスケジューリングと長期間のスケジューリングとの違いは、短期間のスケジューリングでは、図４のステップＳ４０２、Ｓ４０３、Ｓ４０５及びＳ４０６を実行しない点である。即ち、短期間のスケジューリングにおいて、スケジュール部１０８は、上記のような比較的短いサイクルで対応せねばならないイベントに応じて判断部１０４によって入力される構成変更要求を構成変更要求履歴テーブルに登録し、その全ての登録内容に基づいて上述した同じ手法で理想的なスケジューリング及び実現可能なスケジューリングを行うものであり、長期的なスケジューリングのように、信頼度を増加させたり、閾値以上の信頼度の構成変更要求履歴のみを使用して理想的なスケジューリング及び実現可能なスケジューリングを行うものではない。つまり、短期間のスケジューリングでは、比較的短いサイクルで対応せねばならないイベントに応じて入力される構成変更要求のジョブについては全て実行するように取り扱う。

なお、他の実施形態として、短期間のスケジューリング処理によって構成変更要求が構成変更要求履歴テーブルに登録される際、当該構成変更要求が登録されるレコードにおける信頼度の項目に閾値以上の値を登録してもよい。このようにすると、閾値と信頼度との比較において必ず信頼度は閾値以上と判定され、全構成変更要求は、理想的なスケジューリング処理において反映されることになる。

図１８は、短期間のスケジューリング処理により生成される構成変更要求履歴テーブルの構成の例を示す図である。図１８に示すように本構成変更要求履歴テーブルは、図１１に示す構成変更要求履歴テーブルから信頼度の登録項目が除かれた構成となっている。

図１９は、図１８に示す構成変更要求履歴テーブルを用いて理想的なスケジューリング処理を行った結果を示す図である。スケジュール部１０８は、図１８に示す構成変更要求履歴テーブルに登録されるジョブ４１〜４８の８つの構成変更要求履歴を用いてスケジューリング処理を行う。即ち、ジョブ４１の構成変更要求履歴には、期限として「2007/5/2 13:00」、内容として「ＡＰサーバ２台構成」が登録されている。図１９中、ジョブ４１の矢印が示す位置がジョブ４１の期限「2007/5/2 13:00」であり、この期限までにジョブ４１によってＡＰサーバが２台構成に確定された状態にあることを示している。同じくジョブ４２の矢印が示す位置がジョブ４２の期限「2007/5/2 14:00」であり、この期限までにジョブ４２によってＡＰサーバが３台構成に確定された状態にあることを示している。ジョブ４３〜４８についても同様のことが示されている。以上が、信頼性の高い構成変更要求に基づいた、将来のシステム環境における理想的なスケジューリング処理の一例である。

次に、図２０及び図２１を用いて、図１９に示す理想的なスケジューリング処理の結果に対して実現可能なスケジューリング処理を行った結果について説明する。図２０は、理想的なスケジューリング結果と各ジョブの構成変更期間を示す図である。図２１は、実現可能なスケジューリング結果を示す図である。

図２０において、２００１はジョブ４２の構成変更期間、２００２はジョブ４３の構成変更期間、２００３はジョブ４４の構成変更期間、２００４はジョブ４５の構成変更期間、２００５はジョブ４６の構成変更期間、２００６はジョブ４７の構成変更期間、２００７はジョブ４８の構成変更期間を示している。

図２０においては、ジョブ４２の構成変更期間とジョブ４３の構成変更期間とが重複し、ジョブ４４の構成変更期間とジョブ４５の構成変更期間とが重複し、ジョブ４６の構成変更期間とジョブ４７の構成変更期間とが重複している場合を例示している。この場合、ステップＳ５０３において構成変更期間が重複すると判定されるときの当該ジョブは、ジョブ４７、ジョブ４５、ジョブ４３となる。

ジョブ４７を対象とした場合、２つ前のジョブ４５による変更後の台数から直前のジョブ４６による変更後の台数が減少し、且つ直前のジョブ４６による変更後の台数から当該ジョブ４７による変更後の台数が増加している。従って、スケジュール部１０８は、直前のジョブ４６による変更後の台数を、２つ前のジョブ４５による変更後の台数まで増やすように修正する。

ジョブ４５を対象とした場合、２つ前のジョブ４３による変更後の台数から直前のジョブ４４による変更後の台数が減少し、且つ直前のジョブ４４による変更後の台数から当該ジョブ４５による変更後の台数が増加している。従って、スケジュール部１０８は、直前のジョブ４４による変更後の台数を、２つ前のジョブ４３による変更後の台数まで増やすように修正する。

ジョブ４３を対象とした場合、２つ前のジョブ４１による変更後の台数から直前のジョブ４２による変更後の台数が増加し、且つ直前のジョブ４２による変更後の台数から当該ジョブ４３による変更後の台数が増加している。従って、スケジュール部１０８は、直前のジョブ４２による変更後の台数を、当該ジョブ４３による変更後の台数まで増やすように修正する。

以上のように理想的なスケジューリング結果を修正することにより、図２１に示すような実現可能なスケジューリング結果となる。図２１に示すように、実現可能なスケジューリング結果においては、ジョブ４２の構成変更期間２１０１、ジョブ４５の構成変更期間２１０２、ジョブ４７の構成変更期間２１０３及びジョブ４８の構成変更期間２１０４だけを設ければよい。従って、従来は、ジョブ間の衝突によって構成変更要求が混在しスケジューリングが不明確であったが、上述のようなスケジューリング処理によって、最小限の構成変更、且つ、ジョブ間における構成変更期間の重複がなくなり、実現可能なスケジュールとなる。

また、ジョブ４２の期限（ジョブ４２の矢印の位置）からジョブ４２の構成変更期間２１０１だけ遡った時点に構成変更を開始するようにスケジュール部１０８でスケジューリングすることにより、プロビジョニング装置１０７は、構成変更期間を考慮した適切なタイミングで構成変更を開始することが可能となる。ジョブ４５についても同様である。

図２２は、短期的なスケジューリング処理における複数のサービスＡ〜Ｄの残りのノード数を管理するためのリソースプール管理テーブルの構成を概念的に示す図である。本リソースプール管理テーブルも例えばＲＡＭ２０２内に格納される情報である。

本リソース管理テーブルは、上述した短期的なスケジューリング処理における実現可能なスケジューリング処理で確定した各サービスＡ〜Ｄのジョブのスケジュールと、各サービスＡ〜Ｄのコンピュータシステムの構成情報とによって更新されるテーブルである。

例えば、サービスＡについて参照すると、実現可能なスケジューリング処理によって２時にジョブ５１が予定され、ここで２台のＡＰサーバを追加稼働させることが計画されている。２時より前には、サービスＡにおけるＡＰサーバの残り数は１０台であったため、２時以降は８台と記録されている。

サービスＢについては、実現可能なスケジューリング処理によって２時３０分にジョブ５２が予定され、ここで５台のＡＰサーバを追加稼働させることが計画されている。２時３０分より前には、サービスＢにおけるＡＰサーバの残り数は１０台であったため、２時３０分以降は５台と記録されている。

サービスＣについては、１時３０分から５時までの間でジョブが設定されていないため、その期間内においては全て１０台と記録されている。

サービスＤについては、実現可能なスケジューリング処理によって４時にジョブ５３が予定され、ここで８台のＡＰサーバを追加稼働させることが計画されている。４時より前には、サービスＤにおけるＡＰサーバの残り数は１０台であったため、４時以降は２台と記録されている。

このように短期的なスケジューリング処理においてもＡＰサーバ等のノードの残り数を管理することによって、長期的なスケジューリング処理と同様、補充可能なＡＰサーバの数が一定値を下回った際に警告を行うことができる。このようにすることで、ユーザは事前にどのサービスにおいていつノード（リソース）が不足するのかを把握することが可能となる。

また、このような短期スケジューリング処理においても、上記のように或るサービスのコンピュータシステムにおいてノードが不足すると判定された場合、他のサービスのコンピュータシステムの予備のノードからその不足分を補充することもできる。その際に、スケジュール部１０８は、上述の長期スケジュールにおける処理と同様に、ＳＬＡ（Service Level Agreement）を用いて不足分を補充する先のサービスを決定する。

以上、本実施形態における長期的なスケジューリング処理と短期的なスケジューリング処理とについて説明した。長期的なスケジューリングにより或る日時についてジョブが設定されているが、短期的なスケジューリングによって当該日時について他のジョブが決定されることもある。このような場合には、長期的なスケジューリング結果より短期的なスケジューリング結果の方が適切なスケジューリング結果と判断し、当該日時については短期的なスケジューリング結果が設定されてもよい。例えば、上述の長期的なスケジューリング処理によって生成したスケジュールを実行する前に、当該スケジュールに変更をきたすような新たなイベントが発生した場合であっても、上述の短期的なスケジューリング処理同様に新たなイベントに基づいた構成変更要求を生成し、それに対応した新たなスケジューリングを行うことによって、イベントが突発的に発生した場合であっても、動的にスケジュールを変更することが可能である。

本発明の実施形態に係る自律型コンピューティング装置の機能的な構成を示すブロック図である。 自律型コンピューティング装置のハードウェア構成を示すブロック図である。 本発明の実施形態に係る自律型コンピューティング装置の動作の流れを示すフローチャートである。 図３のステップＳ３０５の理想的なスケジューリング処理の詳細を示すフローチャートである。 図３のステップＳ３０６の実現可能なスケジューリング処理の詳細を示すフローチャートである。 図３のステップＳ３０６の実現可能なスケジューリング処理の詳細を示すフローチャートである。 図５−１のステップＳ５０２の構成変更に要する時間の算出方法の詳細を示すフローチャートである。 図５−１のステップＳ５０２の構成変更に要する時間の算出方法の詳細を示すフローチャートである。 本発明の実施形態において監視対象とする自律型コンピューティング環境の一例を示す図である。 図６に示す自律型コンピューティング環境を監視対象とした場合の構成情報を示す図である。 判断部が取得するイベント情報の構成を概念的に示す図である。 図８に示すイベント情報に該当するポリシーの構成を概念的に示す図である。 判断部１０４によって生成される構成変更要求の構成を概念的に示す図である。 長期間のスケジューリング処理により生成される構成変更要求履歴テーブルの構成の一例を概念的に示す図である。 図１１に示す構成変更要求履歴テーブルを用いて理想的なスケジューリングを行った結果を示す図である。 理想的なスケジューリング結果と各ジョブの構成変更期間を示す図である。 実現可能なスケジューリング結果を示す図である。 イベント情報蓄積データベース内の構成変更履歴の一例を概念的に示す図である。 イベント情報蓄積データベース内の構成変更履歴の他の例を概念的に示す図である。 長期的なスケジューリング処理における複数のサービスＡ〜Ｄの残りのノード数を管理するためのリソースプール管理テーブルの構成を概念的に示す図である。 短期間のスケジューリング処理により生成される構成変更要求履歴テーブルの構成の例を示す図である。 図１８に示す構成変更要求履歴テーブルを用いて理想的なスケジューリング処理を行った結果を示す図である。 理想的なスケジューリング結果と各ジョブの構成変更期間を示す図である。 実現可能なスケジューリング結果を示す図である。 短期的なスケジューリング処理における複数のサービスＡ〜Ｄの残りのノード数を管理するためのリソースプール管理テーブルの構成を概念的に示す図である。 構成情報の構成を概念的に示す図である。 自律型コンピューティング装置がサービスＡ、サービスＢを提供する２つのコンピュータシステムを監視対象とした場合に、判断部が分析部から取得するイベント情報の一例を示す図である。 図２４に示すイベント情報に該当するポリシーの構成を概念的に示す図である。 判断部によって生成される構成変更要求の構成を概念的に示す図である。 ＳＬＡを使用して生成されるスケジュール情報の構成を概念的に示す図である。 ＳＬＡの具体例を概念的に示す図である。

符号の説明

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

Claims (7)

1. 少なくとも一つのコンピュータから構成されるコンピュータシステムと通信回線を介して接続される情報処理装置であって、
   前記コンピュータシステムの状態を示す監視データを取得し、前記監視データを取得した時点或いは前記監視データを分析した時点を示す時点情報と、前記監視データを取得した場所を示す場所情報と、前記監視データ或いは前記分析して得られた前記コンピュータシステムの状態を示す情報とを含むイベント情報を生成するイベント情報生成手段と、
   前記イベント情報及び前記コンピュータシステムの運用指針を示すポリシー情報に基づいて、前記ポリシー情報に従った前記コンピュータシステムの構成を示す構成情報と、前記時点情報を基準に算出された、前記構成情報に示される構成に前記コンピュータシステムを変更すべき期限を示す期限情報とを含む構成変更要求情報を生成する要求情報生成手段と、
   前記要求情報生成手段により生成される各構成変更要求情報について、前記要求情報生成手段により同一の構成変更要求情報が過去に生成された回数を示す信頼度情報を記録する第１の記録媒体と、
   前記第１の記録媒体において記録される前記信頼度情報が閾値以上の前記構成変更要求情報を選択し、選択した前記構成変更要求情報夫々に含まれる前記期限情報及び前記構成情報を用いて、前記構成変更要求情報夫々に含まれる前記期限情報に示される期限までに、当該構成変更要求情報に含まれる前記構成情報に示される構成に前記コンピュータシステムの構成を確定させることを決定する第１のスケジューリング手段と、
   前記第１のスケジューリング手段により決定されたコンピュータシステムの構成情報を日時情報に沿って時系列に示した構成変更履歴情報を記録した第２の記録媒体と、
   前記信頼度情報が前記閾値以上の前記構成変更要求情報毎に、前記構成変更要求情報に含まれる前記構成情報に示される構成に前記コンピュータシステムを変更する際に要する期間を、前記第２の記録媒体に記録される前記構成変更履歴情報に基づいて算出する変更期間算出手段と、
   前記変更期間算出手段によって算出された前記コンピュータシステムを変更する際に要する期間が重複し合う前記構成変更要求情報が存在する場合、該当する前記構成変更要求情報のうちの何れか一つの構成変更要求情報に示される構成情報を、前記該当する構成変更要求情報のうちの他の構成変更要求情報の構成情報へと変更する第２のスケジューリング手段とを有することを特徴とする情報処理装置。
2. 前記変更期間算出手段は、前記構成変更要求情報に含まれる前記構成情報に該当する前記構成変更履歴情報を前記第２の記録媒体から検索し、検索した前記構成変更履歴情報の日時情報に基づいて、前記構成変更要求情報に含まれる前記構成情報に示される構成に前記コンピュータシステムを変更する際に要する期間を算出することを特徴とする請求項１に記載の情報処理装置。
3. 前記第２のスケジューリング手段は、前記構成変更要求情報に含まれる前記期限情報に示される期限から、前記変更期間算出手段により算出された前記コンピュータシステムを変更する際に要する期間分の時間を遡った時点を、前記コンピュータシステムの構成変更の開始時点としてスケジューリングすることを特徴とする請求項１又は２に記載の情報処理装置。
4. 前記第１のスケジューリング手段は、長期的なスケジューリング方法として、前記第１の記録媒体において記録される前記信頼度情報が閾値以上の前記構成変更要求情報に含まれる前記期限情報に示される期限までに、当該構成変更要求情報に含まれる前記構成情報に示される構成に前記コンピュータシステムを変更するよう計画し、短期的なスケジューリング方法として、前記要求情報生成手段により生成される全ての前記構成変更要求情報について、前記構成変更要求情報に含まれる前記構成情報に示される構成に前記コンピュータシステムを変更するよう計画することを特徴とする請求項１乃至３の何れか１項に記載の情報処理装置。
5. 前記第１の記録媒体は、前記イベント情報生成手段により所定のイベント情報が生成された場合、前記所定のイベント情報及び前記ポリシー情報に基づいて生成された前記構成変更要求情報の信頼度情報を最も高く記録することを特徴とする請求項１乃至４の何れか１項に記載の情報処理装置。
6. 少なくとも一つのコンピュータから構成されるコンピュータシステムと通信回線を介して接続される情報処理装置による情報処理方法であって、
   前記コンピュータシステムの状態を示す監視データを取得し、前記監視データを取得した時点或いは前記監視データを分析した時点を示す時点情報と、前記監視データを取得した場所を示す場所情報と、前記監視データ或いは前記分析して得られた前記コンピュータシステムの状態を示す情報とを含むイベント情報を生成するイベント情報生成ステップと、
   前記イベント情報及び前記コンピュータシステムの運用指針を示すポリシー情報に基づいて、前記ポリシー情報に従った前記コンピュータシステムの構成を示す構成情報と、前記時点情報を基準に算出された、前記構成情報に示される構成に前記コンピュータシステムを変更すべき期限を示す期限情報とを含む構成変更要求情報を生成する要求情報生成ステップと、
   前記要求情報生成ステップにより生成される各構成変更要求情報について、前記要求情報生成ステップにより同一の構成変更要求情報が過去に生成された回数を示す信頼度情報を記録する記録媒体において記録される前記信頼度情報が閾値以上の前記構成変更要求情報を選択し、選択した前記構成変更要求情報夫々に含まれる前記期限情報及び前記構成情報を用いて、前記構成変更要求情報夫々に含まれる前記期限情報に示される期限までに、当該構成変更要求情報に含まれる前記構成情報に示される構成に前記コンピュータシステムの構成を確定させることを決定する第１のスケジューリングステップと、
   前記信頼度情報が前記閾値以上の前記構成変更要求情報毎に、前記構成変更要求情報に含まれる前記構成情報に示される構成に前記コンピュータシステムを変更する際に要する期間を、前記第１のスケジューリングステップにより決定されたコンピュータシステムの構成情報を日時情報に沿って時系列に示した構成変更履歴情報を記録する記録媒体において記録される前記構成変更履歴情報に基づいて算出する変更期間算出ステップと、
   前記変更期間算出ステップによって算出された前記コンピュータシステムを変更する際に要する期間が重複し合う前記構成変更要求情報が存在する場合、該当する前記構成変更要求情報のうちの何れか一つの構成変更要求情報に示される構成情報を、前記該当する構成変更要求情報のうちの他の構成変更要求情報の構成情報へと変更する第２のスケジューリングステップとを含むことを特徴とする情報処理方法。
7. 少なくとも一つのコンピュータから構成されるコンピュータシステムと通信回線を介して接続される情報処理装置による情報処理方法をコンピュータに実行させるためのプログラムであって、
   前記コンピュータシステムの状態を示す監視データを取得し、前記監視データを取得した時点或いは前記監視データを分析した時点を示す時点情報と、前記監視データを取得した場所を示す場所情報と、前記監視データ或いは前記分析して得られた前記コンピュータシステムの状態を示す情報とを含むイベント情報を生成するイベント情報生成ステップと、
   前記イベント情報及び前記コンピュータシステムの運用指針を示すポリシー情報に基づいて、前記ポリシー情報に従った前記コンピュータシステムの構成を示す構成情報と、前記時点情報を基準に算出された、前記構成情報に示される構成に前記コンピュータシステムを変更すべき期限を示す期限情報とを含む構成変更要求情報を生成する要求情報生成ステップと、
   前記要求情報生成ステップにより生成される各構成変更要求情報について、前記要求情報生成ステップにより同一の構成変更要求情報が過去に生成された回数を示す信頼度情報を記録する記録媒体において記録される前記信頼度情報が閾値以上の前記構成変更要求情報を選択し、選択した前記構成変更要求情報夫々に含まれる前記期限情報及び前記構成情報を用いて、前記構成変更要求情報夫々に含まれる前記期限情報に示される期限までに、当該構成変更要求情報に含まれる前記構成情報に示される構成に前記コンピュータシステムの構成を確定させることを決定する第１のスケジューリングステップと、
   前記信頼度情報が前記閾値以上の前記構成変更要求情報毎に、前記構成変更要求情報に含まれる前記構成情報に示される構成に前記コンピュータシステムを変更する際に要する期間を、前記第１のスケジューリングステップにより決定されたコンピュータシステムの構成情報を日時情報に沿って時系列に示した構成変更履歴情報を記録する記録媒体において記録される前記構成変更履歴情報に基づいて算出する変更期間算出ステップと、
   前記変更期間算出ステップによって算出された前記コンピュータシステムを変更する際に要する期間が重複し合う前記構成変更要求情報が存在する場合、該当する前記構成変更要求情報のうちの何れか一つの構成変更要求情報に示される構成情報を、前記該当する構成変更要求情報のうちの他の構成変更要求情報の構成情報へと変更する第２のスケジューリングステップとをコンピュータに実行させるためのプログラム。

Images