(57)【要約】【課題】仮想化環境において生じる障害の原因箇所の特定を容易かつ迅速に行えるようにする。【解決手段】物理サーバ２０と通信可能に管理サーバ１０を接続し、管理サーバ１０に、物理サーバ２０で生じたイベントの履歴である第１のイベント履歴と、仮想サーバ２１２で生じたイベントの履歴である第２のイベント履歴とを蓄積記憶する。管理サーバ１０は、仮想サーバ２１２で動作している業務プロセス２１２２の障害に関するイベントを受信すると、当該イベントを発した仮想サーバ２１２に関するイベント履歴である第１のイベント履歴と、記憶しているテーブルを用いて取得される、上記イベントを発した仮想サーバ２１２を実現している物理サーバ２０に関するイベント履歴である第２のイベント履歴とを、蓄積記憶している上記イベント履歴から検索し、その検索結果に基づき障害の原因を特定する。【選択図】図２Ａ
2010086516.tif 000002
【特許請求の範囲】
【請求項１】
物理サーバで動作する仮想化機構によって仮想サーバが実現される仮想化環境において生じる障害の解析方法であって、
前記物理サーバと通信可能に接続される管理サーバが、
前記仮想サーバと当該仮想サーバが実現されている前記物理サーバとの対応が登録されたマッピングテーブルを記憶し、
前記物理サーバで生じたイベントの履歴である第１のイベント履歴と、前記仮想サーバで生じたイベントの履歴である第２のイベント履歴とを蓄積記憶し、
前記仮想サーバで動作している業務プロセスの障害に関する前記イベントを受信すると、当該イベントを発した仮想サーバに関する前記第１のイベント履歴と、前記マッピングテーブルから取得される、前記イベントを発した前記仮想サーバを実現している前記物理サーバに関する前記第２のイベント履歴とを、前記蓄積記憶している前記イベント履歴から検索し、その検索結果に基づき障害の原因を特定すること
を特徴とする障害の解析方法。
【請求項２】
請求項１に記載の障害の解析方法であって、
前記管理サーバが、
前記第１のイベント履歴の検索に用いる第１の検索条件と第１の障害箇所とを対応づけた仮想サーバイベント解析ポリシーテーブル、及び前記第２のイベント履歴の検索に用いる第２の検索条件と第２の障害箇所とを対応づけた物理サーバイベント解析ポリシーテーブルを記憶し、
蓄積記憶している前記イベント履歴から、前記仮想サーバイベント解析ポリシーテーブルに登録されている前記第１の検索条件に該当する前記第１のイベント履歴を検索し、その結果、該当する前記第１のイベント履歴を検索することができない場合には、障害の原因が前記業務プロセスにあると特定し、
前記蓄積記憶しているイベント履歴から、前記仮想サーバイベント解析ポリシーテーブルに登録されている前記第１の検索条件に該当する前記第１のイベント履歴を検索するとともに、前記物理サーバイベント解析ポリシーテーブルに登録されている前記第２の検索条件に該当する前記第２のイベント履歴を検索し、その結果、該当する前記第１のイベント履歴を検索することができたが、前記第２のイベント履歴を検索することができなかった場合には、障害の原因が前記仮想サーバにあると特定し、
前記蓄積記憶しているイベント履歴から、前記仮想サーバイベント解析ポリシーテーブルに登録されている前記第１の検索条件に該当する前記第１のイベント履歴を検索するとともに、前記物理サーバイベント解析ポリシーテーブルに登録されている前記第２の検索条件に該当する前記第２のイベント履歴を検索し、その結果、該当する前記第１のイベント履歴及び前記第２のイベント履歴を検索することができ、かつ、検索された前記第１のイベント履歴の検索に用いた前記第１の検索条件に対応づけられている前記第１の障害箇所と検索された前記第２のイベント履歴の検索に用いた前記第２の検索条件に対応づけられている前記第２の障害箇所とが一致しない場合には障害の原因が前記仮想サーバにあると特定し、一致する場合には障害の原因が前記物理サーバにあると特定すること
を特徴とする障害の解析方法。
【請求項３】
請求項１に記載の障害の解析方法であって、
前記管理サーバは、
特定した前記障害の原因と、当該特定に至る過程で該当する前記第１のイベント履歴を検索することができた前記第１の検索条件又は前記第２のイベント履歴を検索することができた前記第２の検索条件とを対応づけて記載した解析結果を出力し、
前記解析結果の変更要求を受け付けて、受け付けた前記変更要求に基づき前記仮想サーバイベント解析ポリシーテーブルにおいて前記第１の検索条件に対応づけられている前記第１の障害箇所、又は物理サーバイベント解析ポリシーテーブルにおいて前記第２の検索条件に対応づけられている前記第２の障害箇所を変更すること
を特徴とする障害の解析方法。
【請求項４】
請求項１に記載の障害の解析方法であって、
前記管理サーバは、前記蓄積記憶している前記イベント履歴のうち、前記業務プロセスについての前記イベント履歴の障害が発生した日時を起点とする所定期間内に発生したイベントについての前記イベント履歴のみを対象として前記検索を行うこと
を特徴とする障害の解析方法。
【請求項５】
請求項１に記載の障害の解析方法であって、
前記管理サーバは、前記仮想化環境において前記仮想サーバの移動が行われた直近の日時を記憶し、
前記管理サーバは、前記蓄積記憶している前記イベント履歴のうち、障害が発生した前記業務プロセスが動作している前記仮想サーバの移動が行われた日時を起点とする所定期間内に発生したイベントについての前記イベント履歴のみを対象として、前記検索を行うこと
を特徴とする障害の解析方法。
【請求項６】
物理サーバで動作する仮想化機構によって仮想サーバが実現される仮想化環境において生じる障害の解析に用いられ、前記物理サーバと通信可能に接続される管理サーバであって、
前記仮想サーバと当該仮想サーバが実現されている前記物理サーバとの対応が登録されたマッピングテーブルを記憶するマッピングテーブル管理部と、
前記物理サーバで生じたイベントの履歴である第１のイベント履歴と、前記仮想サーバで生じたイベントの履歴である第２のイベント履歴とを蓄積記憶するイベント履歴管理部と、
前記仮想サーバで動作している業務プロセスの障害に関する前記イベントを受信すると、前記第１のイベント履歴と、前記マッピングテーブルから取得される、前記イベントを発した仮想サーバを実現している前記物理サーバに関する前記第２のイベント履歴とを、前記蓄積記憶している前記イベント履歴から検索し、その検索結果に基づき前記障害の原因を特定する障害解析部と
を含むことを特徴とする管理サーバ。
【請求項７】
請求項６に記載の管理サーバであって、
前記第１のイベント履歴の検索に用いる第１の検索条件と第１の障害箇所とを対応づけた仮想サーバイベント解析ポリシーテーブル、及び前記第２のイベント履歴の検索に用いる第２の検索条件と第２の障害箇所とを対応づけた物理サーバイベント解析ポリシーテーブルを記憶するポリシーテーブル管理部を有し、
前記障害解析部が、
蓄積記憶している前記イベント履歴から、前記仮想サーバイベント解析ポリシーテーブルに登録されている前記第１の検索条件に該当する前記第１のイベント履歴を検索し、その結果、該当する前記第１のイベント履歴を検索することができない場合には、障害の原因が前記業務プロセスにあると特定し、
前記蓄積記憶しているイベント履歴から、前記仮想サーバイベント解析ポリシーテーブルに登録されている前記第１の検索条件に該当する前記第１のイベント履歴を検索するとともに、前記物理サーバイベント解析ポリシーテーブルに登録されている前記第２の検索条件に該当する前記第２のイベント履歴を検索し、その結果、該当する前記第１のイベント履歴を検索することができたが、前記第２のイベント履歴を検索することができなかった場合には、障害の原因が前記仮想サーバにあると特定し、
前記蓄積記憶しているイベント履歴から、前記仮想サーバイベント解析ポリシーテーブルに登録されている前記第１の検索条件に該当する前記第１のイベント履歴を検索するとともに、前記物理サーバイベント解析ポリシーテーブルに登録されている前記第２の検索条件に該当する前記第２のイベント履歴を検索し、その結果、該当する前記第１のイベント履歴及び前記第２のイベント履歴を検索することができ、かつ、検索された前記第１のイベント履歴の検索に用いた前記第１の検索条件に対応づけられている前記第１の障害箇所と検索された前記第２のイベント履歴の検索に用いた前記第２の検索条件に対応づけられている前記第２の障害箇所とが一致しない場合には障害の原因が前記仮想サーバにあると特定し、一致する場合には障害の原因が前記物理サーバにあると特定すること
を特徴とする管理サーバ。
【請求項８】
物理サーバで動作する仮想化機構によって仮想サーバが実現される仮想化環境において生じる障害の解析に用いられ、前記物理サーバと通信可能に接続される管理サーバに、
前記仮想サーバと当該仮想サーバが実現されている前記物理サーバとの対応が登録されたマッピングテーブルを参照する機能と、
前記物理サーバで生じたイベントの履歴である第１のイベント履歴と、前記仮想サーバで生じたイベントの履歴である第２のイベント履歴とを蓄積記憶する機能と、
前記仮想サーバで動作している業務プロセスの障害に関する前記イベントを受信すると、前記第１のイベント履歴と、前記マッピングテーブルから取得される、前記イベントを発した仮想サーバを実現している前記物理サーバに関する前記第２のイベント履歴とを、前記蓄積記憶している前記イベント履歴から検索し、その検索結果に基づき前記障害の原因を特定する機能と
を実現するためのプログラム。
【請求項９】
請求項１に記載の障害の解析方法であって、
前記管理サーバが、
前記障害の原因が前記物理サーバのハードウエア障害であると判断した場合に、
前記管理サーバの管理対象である前記仮想サーバの夫々の空きリソース量を求め、
求めた前記空きリソース量と前記仮想サーバである障害仮想サーバで実行されているソフトウエアが使用するリソース量とを比較して、前記障害仮想サーバで実行されているソフトウエアを移動させることが可能な他の前記仮想サーバが存在するか否かを判断し、移動させることが可能であると判断した場合に、前記ソフトウエアを、前記他の仮想サーバに移動させる
ことを特徴とする障害の解析方法。
【請求項１０】
請求項９に記載の障害の解析方法であって、
前記管理サーバは、
前記判断において障害仮想サーバで実行されているソフトウエアを移動させることが可能な他の前記仮想サーバが存在しないと判断した場合に、
前記管理サーバの管理対象である前記物理サーバの空きリソース量から、新規に仮想サーバを作成可能か否か判断し、
作成可能と判断した場合は新規に仮想サーバを作成し、前記ソフトウエアを新規に作成した前記仮想サーバに移動させる
ことを特徴とする障害の解析方法。
【請求項１１】
請求項１に記載の障害の解析方法であって、
前記管理サーバが、
前記仮想サーバの夫々で実行される前記業務プロセスの実行履歴、及び前記業務プロセスを実現するソフトウエアの更新履歴を管理し、
前記障害の原因が前記物理サーバのハードウエア障害でないと判断した場合に、
前記実行履歴及び前記更新履歴に基づき、前記障害仮想サーバの業務プロセスについて、前記ソフトウエアの更新が行われた後に正常終了している実行履歴が存在するか否かを判断し、
そのような実行履歴が存在しない場合は前記ソフトウエアのバージョンをロールバックして再起動する
ことを特徴とする障害の解析方法。
【請求項１２】
請求項１１に記載の障害の解析方法であって、
前記管理サーバは、
前記ソフトウエアの更新が行われた後に正常終了している実行履歴が存在するか否かの前記判断において、そのような実行履歴が存在する場合には、前記業務プロセスに対応するアプリケーションを実現するのに必要なリソース量と前記管理サーバの管理対象である前記仮想サーバの空きリソース量とを比較して、前記アプリケーションを移動させることが可能な他の前記仮想サーバが存在するか否かを判断し、存在する場合には、前記アプリケーションを前記他の仮想サーバに移動させる
ことを特徴とする障害の解析方法。
【請求項１３】
請求項１に記載の障害の解析方法であって、
前記管理サーバが、
前記仮想サーバで実行される前記業務プロセスの実行履歴を管理し、
前記障害の発生時点の後に前記業務プロセスについて正常終了した前記実行履歴が存在するか否かを判断し、
前記正常終了した実行履歴が存在しない場合に、前記障害の原因がリソース不足であるか否かを判断し、
リソース不足が原因である場合、前記業務プロセスに対応するアプリケーションを実現するのに必要なリソース量と前記管理サーバの管理対象である前記仮想サーバの空きリソース量とを比較して、前記アプリケーションを移動させることが可能な他の前記仮想サーバが存在するか否かを判断し、存在する場合に、前記アプリケーションを前記他の仮想サーバに移動させる
ことを特徴とする障害の解析方法。
【請求項１４】
請求項１３に記載の障害の解析方法であって、
前記管理サーバは、
前記障害の発生時点における前記業務プロセスの実行多重度と前記業務プロセスの正常実行時における実行多重度とを比較することにより前記障害の原因がリソース不足であるか否かを判断する
ことを特徴とする障害の解析方法。
【請求項１５】
請求項６に記載の管理サーバであって、
前記障害の原因が前記物理サーバのハードウエア障害であると判断した場合に、
前記管理サーバの管理対象である前記仮想サーバの夫々の空きリソース量を求め、
求めた前記空きリソース量と前記仮想サーバである障害仮想サーバで実行されているソフトウエアが使用するリソース量とを比較して、前記障害仮想サーバで実行されているソフトウエアを移動させることが可能な他の前記仮想サーバが存在するか否かを判断し、移動させることが可能と判断した場合に、前記ソフトウエアを、前記他の仮想サーバに移動させ
前記判断において障害仮想サーバで実行されているソフトウエアを移動させることが可能な他の前記仮想サーバが存在しないと判断した場合に、
前記管理サーバの管理対象である前記物理サーバの空きリソース量から、新規に仮想サーバを作成可能か否か判断し、
作成可能と判断した場合は新規に仮想サーバを作成し、前記ソフトウエアを新規に作成した前記仮想サーバに移動させ、
前記仮想サーバの夫々で実行される前記業務プロセスの実行履歴、及び前記業務プロセスを実現するソフトウエアの更新履歴を管理し、
前記障害の原因が前記物理サーバのハードウエア障害でないと判断した場合に、
前記実行履歴及び前記更新履歴に基づき、前記障害仮想サーバの業務プロセスについて、前記ソフトウエアの更新が行われた後に正常終了している実行履歴が存在するか否かを判断し、
そのような実行履歴が存在しない場合は前記ソフトウエアのバージョンをロールバックして再起動し、
前記ソフトウエアの更新が行われた後に正常終了している実行履歴が存在するか否かの前記判断において、そのような実行履歴が存在する場合には、前記業務プロセスに対応するアプリケーションを実現するのに必要なリソース量と前記管理サーバの管理対象である前記仮想サーバの空きリソース量とを比較して、前記アプリケーションを移動させることが可能な他の前記仮想サーバが存在するか否かを判断し、存在する場合には、前記アプリケーションを前記他の仮想サーバに移動させ、
前記仮想サーバで実行される前記業務プロセスの実行履歴を管理し、
前記障害の発生時点の後に前記業務プロセスについて正常終了した前記実行履歴が存在するか否かを判断し、
前記正常終了した実行履歴が存在しない場合に、前記障害の原因がリソース不足であるか否かを判断し、
リソース不足が原因である場合、前記業務プロセスに対応するアプリケーションを実現するのに必要なリソース量と前記管理サーバの管理対象である前記仮想サーバの空きリソース量とを比較して、前記アプリケーションを移動させることが可能な他の前記仮想サーバが存在するか否かを判断し、存在する場合に、前記アプリケーションを前記他の仮想サーバに移動させ、
前記障害の発生時点における前記業務プロセスの実行多重度と前記業務プロセスの正常実行時における実行多重度とを比較することにより前記障害の原因がリソース不足であるか否かを判断する
ことを特徴とする管理サーバ。
【請求項１６】
請求項８に記載のプログラムであって、前記管理サーバに、さらに、
前記障害の原因が前記物理サーバのハードウエア障害であると判断した場合に、
前記管理サーバの管理対象である前記仮想サーバの夫々の空きリソース量を求め、
求めた前記空きリソース量と前記仮想サーバである障害仮想サーバで実行されているソフトウエアが使用するリソース量とを比較して、前記障害仮想サーバで実行されているソフトウエアを移動させることが可能な他の前記仮想サーバが存在するか否かを判断し、移動させることが可能であると判断した場合に、前記ソフトウエアを、前記他の仮想サーバに移動させる機能、
前記判断において障害仮想サーバで実行されているソフトウエアを移動させることが可能な他の前記仮想サーバが存在しないと判断した場合に、
前記管理サーバの管理対象である前記物理サーバの空きリソース量から、新規に仮想サーバを作成可能か否か判断し、
作成可能と判断した場合は新規に仮想サーバを作成し、前記ソフトウエアを新規に作成した前記仮想サーバに移動させる機能、
前記仮想サーバの夫々で実行される前記業務プロセスの実行履歴、及び前記業務プロセスを実現するソフトウエアの更新履歴を管理し、
前記障害の原因が前記物理サーバのハードウエア障害でないと判断した場合に、
前記実行履歴及び前記更新履歴に基づき、前記障害仮想サーバの業務プロセスについて、前記ソフトウエアの更新が行われた後に正常終了している実行履歴が存在するか否かを判断し、
そのような実行履歴が存在しない場合は前記ソフトウエアのバージョンをロールバックして再起動する機能、
前記ソフトウエアの更新が行われた後に正常終了している実行履歴が存在するか否かの前記判断において、そのような実行履歴が存在する場合には、前記業務プロセスに対応するアプリケーションを実現するのに必要なリソース量と前記管理サーバの管理対象である前記仮想サーバの空きリソース量とを比較して、前記アプリケーションを移動させることが可能な他の前記仮想サーバが存在するか否かを判断し、存在する場合には、前記アプリケーションを前記他の仮想サーバに移動させる機能、
前記仮想サーバで実行される前記業務プロセスの実行履歴を管理し、
前記障害の発生時点の後に前記業務プロセスについて正常終了した前記実行履歴が存在するか否かを判断し、
前記正常終了した実行履歴が存在しない場合に、前記障害の原因がリソース不足であるか否かを判断し、
リソース不足が原因である場合、前記業務プロセスに対応するアプリケーションを実現するのに必要なリソース量と前記管理サーバの管理対象である前記仮想サーバの空きリソース量とを比較して、前記アプリケーションを移動させることが可能な他の前記仮想サーバが存在するか否かを判断し、存在する場合に、前記アプリケーションを前記他の仮想サーバに移動させる機能、及び、
前記障害の発生時点における前記業務プロセスの実行多重度と前記業務プロセスの正常実行時における実行多重度とを比較することにより前記障害の原因がリソース不足であるか否かを判断する機能
を実現するためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、物理サーバで動作する仮想化機構によって仮想サーバが実現される仮想化環境において生じる障害の解析方法、管理サーバ、及びプログラムに関し、とくに仮想化環境における障害の原因箇所の特定を容易かつ迅速に行う技術に関する。
【背景技術】
【０００２】
昨今、情報処理システムの性能向上に伴うハードウエア資源の有効活用や負荷分散、可用性の確保等を目的として、いわゆる仮想化技術が注目されている。情報処理システムにおける障害対応においては、業務への影響を防ぐべく、迅速かつ確実な対応が求められる。しかしながら上記仮想化技術が適用された環境では、障害の発生箇所を特定することが必ずしも容易ではない。
【０００３】
例えば、仮想サーバで動作する業務プロセスから障害が報告された場合には、障害の原因が業務プロセスにあるのか、仮想サーバにあるのか、又は物理サーバにあるのかを特定するために、業務プロセス、仮想サーバ、及び物理サーバの夫々に蓄積されているログ情報を分析し、その分析結果に基づいて障害箇所を特定する必要があり、多大な労力が必要になる。
【０００４】
障害の原因を特定する技術として、例えば、特許文献１には、仮想サーバ環境において、仮想サーバに何らかの障害が発生した場合にシステム管理者が仮想サーバのログを迅速に参照できるようにするために、仮想サーバが他の物理サーバに移動する毎に、その移動履歴を生成／記録し、一元管理することが記載されている。また特許文献２には、仮想計算機システムの配下における障害情報の処理において、異常な周辺機器の早期確認、早期対処を実現すべく、仮想計算機システムの稼働中に周辺装置に障害が発生すると、ゲスト仮想計算機の配下にあるオペレーティングシステムが検出したロギング情報やホストシステムが検出したロギング情報を、各ゲスト仮想計算機の配下にある異常通報システムが分析／分類し、実機番号で保守センタに自動通知することが記載されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００７−３２３２４４号公報
【特許文献２】特開平４−２５７０３５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
上記特許文献１及び特許文献２に記載されている技術は、いずれもログ情報の解析を保守員等の人手によって行うことを前提としており、仮想化環境における障害発生時における解析に必要な労力が必ずしも軽減されるわけではない。即ちこれらの技術によっては障害原因の特定やその対処を必ずしも容易かつ迅速に行えるわけではない。
【０００７】
この発明はこのような背景に鑑みてなされたもので、仮想化環境における障害の原因箇所の特定を容易かつ迅速に行うことを可能とする仮想化環境における障害の解析方法及び管理サーバを提供することを目的とする。
【課題を解決するための手段】
【０００８】
上記目的を達成するための本発明のうちの一つは、
物理サーバで動作する仮想化機構によって仮想サーバが実現される仮想化環境において生じる障害の解析方法であって、
前記物理サーバと通信可能に接続される管理サーバが、
前記仮想サーバと当該仮想サーバが実現されている前記物理サーバとの対応が登録されたマッピングテーブルを記憶し、
前記物理サーバで生じたイベントの履歴である第１のイベント履歴と、前記仮想サーバで生じたイベントの履歴である第２のイベント履歴とを蓄積記憶し、
前記仮想サーバで動作している業務プロセスの障害に関する前記イベントを受信すると、当該イベントを発した仮想サーバに関する前記第１のイベント履歴と、前記マッピングテーブルから取得される、前記イベントを発した前記仮想サーバを実現している前記物理サーバに関する前記第２のイベント履歴とを、前記蓄積記憶している前記イベント履歴から検索し、その検索結果に基づき障害の原因を特定することとする。
その他、本願が開示する課題、およびその解決手段は、発明を実施するための最良の形態の欄、及び図面により明らかにされる。
【発明の効果】
【０００９】
本発明によれば、仮想化環境における障害の原因箇所の特定を容易かつ迅速に行うことができる。
【図面の簡単な説明】
【００１０】
【図１Ａ】仮想化システム１を実現するために用いられるハードウエア環境を示す図である。
【図１Ｂ】管理サーバ１０又は物理サーバ２０として用いられるコンピュータの一例である。
【図２Ａ】管理サーバ１０の機能及び管理サーバ１０において管理されるデータを示す図である。
【図２Ｂ】物理サーバ２０の機能及び物理サーバ２０において管理されるデータを示す図である。
【図３Ａ】イベント履歴テーブル１２１の一例である。
【図３Ｂ】稼働サーバマッピングテーブル１２２の一例である。
【図３Ｃ】仮想サーバイベント解析ポリシーテーブル１２４の一例である。
【図３Ｄ】物理サーバイベント解析ポリシーテーブル１２５の一例である。
【図３Ｅ】解析履歴テーブル１２３の一例である。
【図３Ｆ】対処テーブル１２６の一例である。
【図３Ｇ】アプリケーション管理テーブル１２７の一例である。
【図３Ｈ】ＳＬＡ定義テーブル１２８の一例である。
【図３Ｉ】リソース管理テーブル１２９の一例である。
【図３Ｊ】依存関係管理テーブル１３０の一例である。
【図３Ｋ】サーバ管理テーブル１３１の一例である。
【図３Ｌ】パッチ管理テーブル１３２の一例である。
【図４Ａ】障害監視部１１０によって行われる処理を説明するフローチャートである。
【図４Ｂ】解析処理（Ｓ４１３）の詳細を説明するフローチャートである。
【図５】対処実行部１１８が備える主な機能を示す図である。
【図６】障害対処処理Ｓ４１５の全体的な流れを説明するフローチャートである。
【図７】仮想サーバ移動処理Ｓ６２１を説明するフローチャートである。
【図８】ロールバック処理Ｓ６４３を説明するフローチャートである。
【図９】アプリケーション移動処理Ｓ６４４を説明するフローチャートである。
【発明を実施するための形態】
【００１１】
図１Ａに実施形態として説明する仮想化システムを実現するために用いられるハードウエア環境を示している。同図に示すように、このハードウエア環境は、管理サーバ１０と、通信ネットワーク５を介して管理サーバ１０と通信可能に接続し管理サーバ１０によって監視される一台以上の物理サーバ２０と、物理サーバ２０がアクセス可能な記憶装置３０とを含んで構成されている。
【００１２】
管理サーバ１０と物理サーバ２０とを結ぶ通信ネットワーク５は、例えばＬＡＮ（Local Area Network）である。物理サーバ２０及び記憶装置３０は、例えばＬＡＮやＳＡＮ（Storage Area Network）を介して通信可能に接続される。記憶装置３０は、例えばディスクアレイ装置やＮＡＳ（Network Attached Storage）である。
【００１３】
管理サーバ１０又は物理サーバ２０は、例えばパーソナルコンピュータ、ブレードサーバに装着されたブレード、ワークステーション、メインフレーム等のコンピュータ（情報処理装置）である。図１Ｂに管理サーバ１０又は物理サーバ２０として用いられるコンピュータの一例を示す。同図に示すコンピュータ１００は、中央処理装置１０１（例えばＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit））、主記憶装置１０２（例えばＲＡＭ（Random Access Memory）やＲＯＭ（Read Only Memory））、補助記憶装置１０３（例えばハードディスク）、ユーザの操作入力を受け付ける入力装置１０４（例えばキーボードやマウス）、出力装置１０５（例えば液晶モニタ）、通信ネットワーク５を介して他の装置との間の通信を実現する通信インタフェース１０６（例えばＮＩＣ（Network Interface Card））を備えている。
【００１４】
＜管理サーバ１０＞
図２Ａに管理サーバ１０において実現される機能、及び管理サーバ１０によって管理されるデータを示す。尚、同図における各機能は、管理サーバ１０の中央処理装置１０１が主記憶装置１０２又は補助記憶装置１０３に格納されているプログラムを読み出して実行することにより、もしくは管理サーバ１０のハードウエア自体の機能によって実現される。
【００１５】
同図に示すように、管理サーバ１０では、物理サーバ２０において発生した障害の原因を特定する機能（以下、障害監視部１１０と称する。）を実現するためのプログラムが実行されている。障害監視部１１０は、イベント履歴管理部１１１、マッピングテーブル管理部１１２、ユーザインタフェース部１１３、障害解析部１１４、ポリシーテーブル管理部１１５、解析履歴テーブル管理部１１６、対処テーブル管理部１１７、及び対処実行部１１８を備える。また管理サーバ１０は、イベント履歴テーブル１２１、稼働サーバマッピングテーブル１２２、解析履歴テーブル１２３、仮想サーバイベント解析ポリシーテーブル１２４、物理サーバイベント解析ポリシーテーブル１２５、対処テーブル１２６、アプリケーション管理テーブル１２７、ＳＬＡ定義テーブル１２８、リソース管理テーブル１２９、依存関係管理テーブル１３０、サーバ管理テーブル１３１、及びパッチ管理テーブル１３２を管理している。
【００１６】
図２Ａに示した機能のうち、イベント履歴管理部１１１は、物理イベント通知部２１３から送信されてくる情報に基づく物理サーバ２０に関するイベントの履歴（第１のイベント履歴）をイベント履歴テーブル１２１に登録する。またイベント履歴管理部１１１は、仮想イベント通知部２１２３から送信されてくる情報に基づく仮想サーバ２１２に関するイベントの履歴（第２のイベント履歴）をイベント履歴テーブル１２１に登録する。
【００１７】
図３Ａにイベント履歴テーブル１２１の一例を示す。同図における各レコードは、夫々、物理サーバ２０又は仮想サーバ２１２において発生した１つのイベントについてのイベント履歴である。各イベント履歴は、イベントが発生したサーバ（物理サーバ２０又は仮想サーバ２１２）を特定する情報が設定されるサーバ名３１１、イベントが発生した日時が設定される発生日時３１２、イベントが発生したプロセスを特定する情報が設定されるプロセス名３１３、エラーメッセージ等が設定されるメッセージ３１４、及び発生したイベントの種別（エラー（Error）、警告（Warning）、一般情報（Information））を示す情報が設定されるイベント種別３１５の各項目を有する。
【００１８】
尚、同図において、サーバ名３１１に先頭が「ｐ」で始まる名称が設定されているイベント履歴は、物理サーバ２０の物理イベント通知部２１３から送られてきたイベント履歴である。またサーバ名３１１に先頭が「ｖ」で始まる名称が設定されているイベント履歴は、仮想イベント通知部２１２３から送られてきたイベント履歴である。
【００１９】
このように、図３Ａのイベント履歴テーブル１２１には、物理イベント通知部２１３から通知されるイベント履歴と、仮想イベント通知部２１２３から通知されるイベント履歴の双方が含まれているが、これらは別のテーブルで管理されていても構わない。
【００２０】
図２Ａにおけるマッピングテーブル管理部１１２は、稼働サーバマッピングテーブル１２２を管理する。マッピングテーブル管理部１１２は、仮想化機構２１１に対して能動的又は受動的に稼働サーバマッピングテーブル１２２に登録すべき情報を取得し、取得した情報を稼働サーバマッピングテーブル１２２に反映する。
【００２１】
図３Ｂに稼働サーバマッピングテーブル１２２の一例を示す。稼働サーバマッピングテーブル１２２には、業務プロセス２１２２を特定する情報が設定されるプロセス名３２１、業務プロセス２１２２が実行されている仮想サーバ２１２を特定する情報が設定される仮想サーバ名３２２、仮想サーバ２１２を実現している物理サーバ２０を特定する情報が設定される物理サーバ名３２３、及び仮想サーバ２１２が稼働を開始した日時が設定される仮想サーバ稼働開始日時３２４が対応づけて登録されている。尚、稼働サーバマッピングテーブル１２２の内容は、例えば仮想サーバ２１２の移動（後述）があった際に更新される。
【００２２】
図２Ａのユーザインタフェース部１１３は、プログラムの起動や終了を指示する操作入力等、ユーザが入力装置１０４に対して行った操作入力を受け付ける。
【００２３】
図２Ａの障害解析部１１４は、業務プロセス２１２２に何らかの障害が発生するとイベント履歴テーブル１２１に登録されているイベント履歴を解析し、その解析結果を解析履歴テーブル１２３に登録する。
【００２４】
図２Ａにおけるポリシーテーブル管理部１１５は、仮想サーバイベント解析ポリシーテーブル１２４及び物理サーバイベント解析ポリシーテーブル１２５を管理する。これらのテーブルには、障害解析部１１４が障害の解析に際しイベント履歴テーブル１２１を検索する際に用いる検索条件（第１の検索条件、第２の検索条件）が登録されている。
【００２５】
図３Ｃに仮想サーバイベント解析ポリシーテーブル１２４の一例を示す。同図に示すように、仮想サーバイベント解析ポリシーテーブル１２４には、イベント履歴をイベント履歴テーブル１２１から検索する際の検索条件３３１、及び検索条件による検索結果に応じて設定される情報である原因箇所３３２を含んだ一つ以上のレコードが登録されている。ここで同図の１行目のレコードの検索条件３３１の内容は、イベント履歴テーブル１２１から、その仮想サーバ名３１１に特定のサーバ名（＄仮想サーバ＄）が設定され、かつ、メッセージ３１４に「connect error」（通信エラーを意味する。）という文字列を含むイベント履歴を検索するというものである。また２行目のレコードの検索条件３３１の内容は、イベント履歴テーブル１２１から、その仮想サーバ名３１１に特定のサーバ名（＄仮想サーバ＄）が設定され、かつ、プロセス名３１３に「aa」が設定され、かつ、メッセージ３１４に「エラー」という文字列を含むイベント履歴を検索するというものである。また３行目のレコードの検索条件３３１の内容は、イベント履歴テーブル１２１から、その仮想サーバ名３１１に特定のサーバ名（＄仮想サーバ＄）が設定され、かつ、プロセス名３１３に「bb」が設定され、かつ、メッセージ３１４に「fault」という文字列を含むイベント履歴を検索するというものである。また４行目のレコードの検索条件３３１の内容は、イベント履歴テーブル１２１から、その仮想サーバ名３１１に特定のサーバ名（＄仮想サーバ＄）が設定され、かつ、イベント種別３１５に「Error」が設定されているかもしくはメッセージ３１４に「エラー」という文字列を含むイベント履歴を検索するというものである。
【００２６】
図３Ｄは物理サーバイベント解析ポリシーテーブル１２５の一例である。このテーブルには、イベント履歴テーブル１２１からイベント履歴を検索する際の検索条件３４１、検索条件による検索結果に応じて設定される情報である原因箇所３４２、及びエラーレベルが設定されるエラーレベル３４３を含んだ一つ以上のレコードが登録されている。ここで同図の１行目のレコードの検索条件３４１の内容は、イベント履歴テーブル１２１から、その物理サーバ名３１１に特定のサーバ名（＄物理サーバ＄）が設定され、かつ、プロセス名３１３に「bb」が設定され、かつ、イベント種別３１５に「Error」という文字列を含むイベント履歴を検索するというものである。また２行目のレコードの検索条件３４１の内容は、イベント履歴テーブル１２１から、その物理サーバ名３１１に特定のサーバ名（＄物理サーバ＄）が設定され、かつ、プロセス名３１３に「aa」が設定され、かつ、メッセージ３１４に「error」という文字列を含むイベント履歴を検索するというものである。また３行目のレコードの検索条件３４１の内容は、イベント履歴テーブル１２１から、その物理サーバ名３１１に特定のサーバ名（＄物理サーバ＄）が設定され、かつ、メッセージ３１４に「memory fault」という文字列を含むイベント履歴を検索するというものである。また４行目のレコードの検索条件３４１の内容は、イベント履歴テーブル１２１から、その物理サーバ名３１１に特定のサーバ名（＄物理サーバ＄）が設定され、かつ、プロセス名３１３に「ee」が設定されているイベント履歴を検索するというものである。また５行目のレコードの検索条件３４１の内容は、イベント履歴テーブル１２１から、その物理サーバ名３１１に特定のサーバ名（＄物理サーバ＄）が設定され、かつ、プロセス名３１３に「bb」が設定され、かつ、メッセージ３１４に「warning」という文字列を含むイベント履歴を検索するというものである。また６行目のレコードの検索条件３４１の内容は、イベント履歴テーブル１２１に特定の物理サーバ名（＄物理サーバ＄）が一つも含まれていなかった場合に「真」とするというものである。
【００２７】
図２Ａに示した解析履歴テーブル管理部１１６は、ユーザインタフェース部１１３から受け付けたユーザの操作入力に従い解析履歴テーブル１２３の内容を管理する。図３Ｅは解析履歴テーブル１２３の一例である。解析履歴テーブル１２３の各レコードは、障害解析部１１４がイベント履歴テーブル１２１から検索した仮想サーバに関する情報が記載される仮想サーバイベント３５１、障害解析部１１４がイベント履歴テーブル１２１から検索した物理サーバに関する情報が記載される物理サーバイベント３５２、及び仮想サーバイベント３５１又は物理サーバイベント３５２の内容に応じてその内容が設定される解析結果３５３の各項目が含まれる。
【００２８】
図２Ａに示した対処テーブル管理部１１７は、ユーザインタフェース部１１３から受け付けたユーザの操作入力に従って対処テーブル１２６の内容を管理する。図３Ｆは対処テーブル１２６の一例である。同図に示すように、対処テーブル１２６の各レコードは、エラーレベルが設定されるエラーレベル３６１、及びエラーレベル３６１に対応して設定された、障害に対する対処の内容が記述される対処３６２を含む複数のレコードからなる。
【００２９】
図２Ａにおける対処実行部１１８は、障害解析部１１４において解析された障害内容に応じた処理を実行する。尚、アプリケーション管理テーブル１２７、ＳＬＡ定義テーブル１２８、リソース管理テーブル１２９、依存関係管理テーブル１３０、サーバ管理テーブル１３１、及びパッチ管理テーブル１３２の詳細については後述する。
【００３０】
＜物理サーバ２０＞
図２Ｂに物理サーバ２０において実現される機能、及び物理サーバ２０によって管理されるデータを示している。尚、同図における各機能は、物理サーバ２０の中央処理装置１０１が主記憶装置１０２又は補助記憶装置１０３に格納されているプログラムを読み出して実行することにより、もしくは物理サーバ２０のハードウエア自体の機能によって実現される。
【００３１】
同図に示すように、物理サーバ２０は、仮想化機構２１１、仮想化機構２１１によって実現される一つ以上の仮想サーバ２１２、及び物理イベント通知部２１３を備える。また各仮想サーバ２１２ではオペレーティングシステム２１２１が動作し、オペレーティングシステム２１２１の制御下で業務プロセス２１２２及び仮想イベント通知部２１２３が実現されている。
【００３２】
同図に示す仮想化機構２１１は、物理サーバ２０によって提供されるリソースを仮想化（Virtualization）し、物理サーバ２０によって提供される物理資源（リソース）を、エンドユーザやアプリケーション、オペレーティングシステム等に対し、一つ以上の論理的な資源に見せかける機能を実現する。同図に示す複数の仮想サーバ２１２は、夫々が仮想化機構２１１によって実現される論理的な資源（仮想的なコンピュータ）であって、互いに他の仮想サーバから独立して動作することができる。
【００３３】
尚、仮想サーバ２１２は、物理サーバ２０の物理資源（ハードウエア）をベースとして動作するオペレーティングシステム（ホストＯＳ）でハードウエアのエミュレーション環境を実現し、その環境下で仮想サーバ２１２のオペレーティングシステム２１２１（ゲストＯＳ）を動作させる、いわゆるホストＯＳ方式によって実現してもよいし、ホストＯＳを介在せずに物理資源に直接エミュレーション環境を設け、その環境下でゲストＯＳを動作させる、いわゆる仮想マシンモニタ方式によって実現するようにしてもよい。また物理資源のエミュレート方式としては、物理資源を完全にエミュレートする完全仮想化方式を選択してもよいし、一部の物理資源のみをエミュレートする準仮想化方式を選択してもよい。
【００３４】
各仮想サーバ２１２に対応するメモリイメージ（仮想サーバイメージ）は、記憶装置３０に格納されている。仮想サーバ２１２を移動（仮想サーバ２１２と物理サーバ２０との対応関係の変更）する場合には、仮想サーバイメージを該当の物理サーバ２０に割当てられている記憶装置３０の記憶領域に展開することによって行うことができる。尚、上記移動は、例えば仮想化機構２１１の機能によって、もしくは管理サーバ１０からの指示に応じて行われる。
【００３５】
各仮想サーバ２１２ではオペレーティングシステム２１２１が動作し、業務プロセス２１２２や仮想イベント通知部２１２３は、オペレーティングシステム２１２１において動作する。  
各仮想サーバ２１２において動作する仮想イベント通知部２１２３は、各仮想サーバ２１２でイベントが発生すると、これに対応したイベント履歴を、通信ネットワーク５を介して管理サーバ１０に通知する。
【００３６】
各物理サーバ２０で動作する物理イベント通知部２１３は、物理サーバ２０において発生したイベントに対応するイベント履歴を、通信ネットワーク５を介して管理サーバ１０に通知する。また物理イベント通知部２１３は、管理サーバ１０の対処実行部１１８から通信ネットワーク５を介して送られてくる（発生した障害に対する）対処処理の実行指示を受け付け、受け付けた実行指示に対応する対処処理を実行する。
【００３７】
＜処理説明＞
障害監視部１１０によって行われる処理を図４Ａに示すフローチャートとともに説明する。尚、以下の説明において、符号の前に付した「Ｓ」の文字はステップを意味する。
【００３８】
障害監視部１１０は、ユーザインタフェース部１１３がユーザから終了操作を受け付けたか否かをリアルタイムに監視する（Ｓ４１１）。ユーザから終了操作を受け付けた場合は（Ｓ４１１：ＹＥＳ）処理を終了する。終了操作を受け付けない場合は（Ｓ４１１：ＮＯ）Ｓ４１２に進む。
【００３９】
Ｓ４１２において、障害監視部１１０は、仮想サーバ２１２の業務プロセス２１２２における障害発生の有無を判断する。例えば仮想イベント通知部２１２３から業務プロセス２１２２の障害（エラー）に関する新たなイベント履歴を受信した場合に障害が発生したと判断する。また業務プロセス２１２２のエラーに関するイベント履歴がイベント履歴テーブル１２１に新たに登録された場合に障害が発生したと判断する。障害が発生したと判断した場合には（Ｓ４１２：ＹＥＳ）Ｓ４１３に進み、障害が発生していない場合は（Ｓ４１２：ＮＯ）Ｓ４１１に戻る。
【００４０】
Ｓ４１３において、障害解析部１１４は、障害の原因を特定するとともに発生した障害にエラーレベルを付与する処理（以下、解析処理と称する）を行う。図４Ｂに解析処理（Ｓ４１３）の詳細を示している。まず障害解析部１１４は、障害が発生している業務プロセス２１２２が実行されている仮想サーバ２１２に関するイベント履歴を、イベント履歴テーブル１２１から検索する（Ｓ４１３１）。ここでの検索は仮想サーバイベント解析ポリシーテーブル１２４に登録されている検索条件３３１(第１の検索条件）を用いて行われる。即ち上記検索は、障害発生と判断した契機となったイベント履歴に記述されている仮想サーバ名（例えば「vserver1」）を図３Ｃに示した検索条件３３１に記述されている変数「＄仮想サーバ＄」に設定することにより行われる。
【００４１】
尚、上記検索はＳ４１２において障害が発生したと判断する契機となったイベント履歴に記述されている、仮想サーバ２１２のサーバ名（仮想サーバ名）をキーとして行ってもよい。
【００４２】
例えばイベント履歴テーブル１２１の内容が図３Ａに示す内容であり、キーとなる仮想サーバ名が「vserver1」である場合には、同図の２行目及び５行目のイベント履歴が検索される。またキーとなる物理サーバ名が「pserver1」である場合には、これに対応する仮想サーバ名「vserver1」を稼働サーバマッピングテーブル１２２から取得し、取得した仮想サーバ名「vserver1」をキーとして２行目及び５行目のイベント履歴が検索される。尚、障害発生と判断した契機となったイベント履歴は検索対象から除外されるものとする。
【００４３】
ここでイベント履歴テーブル１２１に長期間分のイベント履歴が管理されている場合（例えばイベント履歴の削除周期が長い場合）には、障害発生と判断した契機となったイベント履歴のイベントの発生日時３１２を起点とする所定期間内（例えばイベント発生日時３１２の前後所定期間内）に発生したイベントのイベント履歴のみを検索対象とするようにしてもよい。また（障害発生と判断した契機となったイベント履歴から取得される）仮想サーバ名３２２や物理サーバ名３２３をキーとして稼働サーバマッピングテーブル１２２から取得できる仮想サーバ稼働開始日時３２４に設定されている日時を起点とする所定期間内（例えば仮想サーバ稼働開始日時３２４に設定されている日時からイベントの発生日時３１２に設定されている日時までの間）に発生したイベントのイベント履歴のみを検索対象とするようにしてもよい。このように、障害発生時の近傍のみに検索対象を絞ることで、解析の精度を向上することができる。
【００４４】
Ｓ４１３２では、障害解析部１１４はＳ４１３１の検索において仮想サーバ２１２に関するイベント履歴を一つ以上検索することができたか否かを判断する（Ｓ４１３２）。検索することができなかった場合は（Ｓ４１３２：ＮＯ）Ｓ４１３３に進み、検索することができた場合は（Ｓ４１３２：ＹＥＳ）Ｓ４１３４に進む。
【００４５】
Ｓ４１３３では、障害解析部１１４は、Ｓ４１２において障害発生と判断したイベント履歴の内容を、解析履歴テーブル１２３の仮想サーバイベント３５１として登録し、これに対応する解析結果３５３の原因箇所３５３１に「業務プロセス」を、またエラーレベル３５３２に「１」を登録する。その後は図４ＡのＳ４１４に進む。つまり障害解析部１１４は、Ｓ４１３１において仮想サーバ２１２のイベント履歴を検索することができなかったことをもって、障害の原因が業務プロセス２１２２にあると判断する。
【００４６】
Ｓ４１３４では、障害解析部１１４は、障害が発生している業務プロセス２１２２が実行されている物理サーバ２０に関するイベント履歴をイベント履歴テーブル１２１から検索する。
【００４７】
尚、上記イベント履歴が仮想サーバ２１２の仮想イベント通知部２１２３から通知されたものである場合には、当該イベント履歴に記述されているサーバ名（仮想サーバ名）に対応する物理サーバ名を稼働サーバマッピングテーブル１２２から取得し、取得したその物理サーバ名をキーとしてイベント履歴をイベント履歴テーブル１２１から検索する。例えば、イベント履歴テーブル１２１の内容が図３Ａに示す内容であり(同図では障害発生と判断した契機となったイベント履歴は省略している。）、キーとなる物理サーバ名が「pserver1」である場合には、１行目のイベント履歴が検索される。またキーとなるサーバ名が仮想サーバ「vserver1」である場合には、これに対応する物理サーバ名「pserver1」を稼働サーバマッピングテーブル１２２から取得し、取得した物理サーバ名「pserver1」をキーとして１行目のイベント履歴が検索される。
【００４８】
尚、サーバ名をキーとするのではなく、物理サーバイベント解析ポリシーテーブル１２５に登録されている検索条件（第２の検索条件）によって物理サーバ２０に関するイベント履歴を検索するようにしてもよい。この場合には、障害発生と判断した契機となったイベント履歴に記述されている物理サーバ名（例えば「pserver1」）を図３Ｄに示した検索条件に記述されている変数「＄物理サーバ＄」に設定して検索を行う。
【００４９】
前述と同様、イベント履歴テーブル１２１に長期間分のイベント履歴が管理されている場合（例えばイベント履歴の削除周期が長い場合）には、障害発生と判断した契機となったイベント履歴のイベントの発生日時３１２を起点とする所定期間内（例えばイベント発生日時３１２の前後所定期間内）に発生したイベントのイベント履歴のみを検索対象とするようにしてもよい。また（障害発生と判断した契機となったイベント履歴から取得される）仮想サーバ名３２２や物理サーバ名３２３をキーとして稼働サーバマッピングテーブル１２２から取得できる仮想サーバ稼働開始日時３２４に設定されている日時を起点とする所定期間内（例えば仮想サーバ稼働開始日時３２４に設定されている日時からイベントの発生日時３１２に設定されている日時までの間）に発生したイベントのイベント履歴のみを検索対象とするようにしてもよい。
【００５０】
Ｓ４１３５では、障害解析部１１４は、Ｓ４１３４の検索において物理サーバ２０に関するイベント履歴を一つ以上検索することができたか否かを判断する（Ｓ４１３５）。検索することができなかった場合は（Ｓ４１３５：ＮＯ）、Ｓ４１３６に進み、検索することができた場合は（Ｓ４１３５：ＹＥＳ）、Ｓ４１４７に進む。
【００５１】
Ｓ４１３６において、障害解析部１１４は、Ｓ４１２において障害発生と判断したイベント履歴の内容を、解析履歴テーブル１２３の物理サーバイベント３５２として登録し、これに対応する解析結果３５３の原因箇所３５３１に「仮想サーバ」を、エラーレベル３５３２に「２」を登録する。その後は図４ＡのＳ４１４に進む。つまり障害解析部１１４は、Ｓ４１３１において仮想サーバ２１２のイベント履歴を検索することはできたが、Ｓ４１３４において物理サーバ２０のイベント履歴を検索することができなかったので、障害の原因が仮想サーバ２１２にあると判断する。
【００５２】
Ｓ４１３７では、障害解析部１１４は、Ｓ４１３１において（第１の検索条件により）検索された仮想サーバ２１２のイベント履歴に対応する障害の原因箇所（第１の障害箇所）と、Ｓ４１３４において（第２の検索条件により）検索された物理サーバ２０のイベント履歴に対応する障害の原因箇所（第２の障害箇所）とが一致するか否かを判断する。ここで検索条件として仮想サーバイベント解析ポリシーテーブル１２４又は物理サーバイベント解析ポリシーテーブル１２５に登録されている検索条件を用いた場合には、イベント履歴に対応する上記障害の原因箇所は、仮想サーバイベント解析ポリシーテーブル１２４又は物理サーバイベント解析ポリシーテーブル１２５において、検索されたイベント履歴を検索した際に用いた検索条件に対応づけられている原因箇所３３２，３４２である。またイベント履歴に記述されている、仮想サーバ名や物理サーバ名をキーとしてイベント履歴を検索した場合、障害解析部１１４は、検索されたイベント履歴に記述されているメッセージ３１４やイベント種別３１５等に基づき、障害の原因箇所を特定する。原因箇所が一致する場合は（Ｓ４１３７：ＹＥＳ）Ｓ４１３８に進み、原因箇所が一致しない場合は（Ｓ４１３７：ＮＯ）Ｓ４１３６に進む。つまり障害解析部１１４は、Ｓ４１３１において仮想サーバ２１２のイベント履歴を、またＳ４１３４において物理サーバ２０のイベント履歴を検索することができたが、各イベント履歴の原因箇所が一致しなかったので、障害の原因が仮想サーバ２１２にあると判断する。
【００５３】
Ｓ４１３８では、障害解析部１１４は、Ｓ４１２において障害発生と判断したイベント履歴の内容を、解析履歴テーブル１２３の仮想サーバイベント３５１及び物理サーバイベント３５２として登録し、これらに対応する解析結果３５３の原因箇所３５３１に「物理サーバ」を、エラーレベル３５３２に「３」を登録する。その後は図４ＡのＳ４１４に進む。つまり障害解析部１１４は、Ｓ４１３１において仮想サーバ２１２のイベント履歴を検索することができ、Ｓ４１３４において物理サーバ２０のイベント履歴を検索することができ、しかもＳ４１３７の判断において各イベント履歴の原因箇所が一致したので、障害の原因が物理サーバ２０にある可能性が高いと判断する。
【００５４】
以上に説明した障害解析処理Ｓ４１３によれば、障害の原因が業務プロセス２１２２にあるのか、仮想サーバ２１２にあるのか、もしくは物理サーバ２０にあるのかを高い精度で容易かつ迅速に特定することができる。またリアルタイムに内容が更新されるイベント履歴テーブル１２１の内容に基づいて解析がなされるので障害が発生してから短期間に障害の原因を特定することができる。従って、緊急性を要する障害に対して有効に対応することができる。
【００５５】
図４ＡのＳ４１４では、ユーザインタフェース部１１３が、解析履歴テーブル１２３の内容を管理サーバ１０の出力装置１０５に出力する。ユーザインタフェース部１１３は、出力される解析履歴テーブル１２３の内容のうち解析結果３５３の編集環境を提供する。解析履歴テーブル管理部１１６は、編集された解析結果３５３の内容を解析履歴テーブル１２３に反映する。また解析履歴テーブル管理部１１６は、解析履歴テーブル１２３の編集内容を、仮想サーバイベント解析ポリシーテーブル１２４、又は物理サーバイベント解析ポリシーテーブル１２５に反映する。これにより仮想サーバイベント解析ポリシーテーブル１２４における検索条件３３１と原因箇所３３２の対応精度、又は物理サーバイベント解析ポリシーテーブル１２５における検索条件３４１、原因箇所３４２、及びエラーレベル３４３の対応精度が向上し、障害原因の解析精度を向上することができる。
【００５６】
＝障害対処＝
図４ＡのＳ４１５では、対処実行部１１８が、障害の原因に応じた処理（以下、障害対処処理Ｓ４１５と称する。）を行う。対処実行部１１８は、障害対処処理Ｓ４１５に際し、図２Ａに示したアプリケーション管理テーブル１２７、ＳＬＡ定義テーブル１２８、リソース管理テーブル１２９、依存関係管理テーブル１３０、サーバ管理テーブル１３１、及びパッチ管理テーブル１３２を用いる。まずこれらのテーブルの内容について説明する。
【００５７】
図３Ｇは上記テーブルのうちアプリケーション管理テーブル１２７の一例である。アプリケーション管理テーブル１２７には、仮想サーバ２１２において実行されるアプリケーションに関する情報が管理される。同図に示すように、アプリケーション管理テーブル１２７は、アプリケーション名が設定されるＡＰ名１２７１、ＡＰ名１２７１によって設定されているアプリケーションに対応するプロセスの名称が設定されるプロセス名１２７２、プロセス名１２７２に設定されているプロセス名１２７２に対応するプロセスの識別子が設定されるプロセスＩＤ１２７３、ＡＰ名１２７１に設定されているアプリケーションが動作している仮想サーバ２１２の名称が設定される仮想サーバ名１２７４、及び仮想サーバ名１２７４に設定されている仮想サーバ２１２のＳＬＡ（Service Level Agreement）の名称が設定される関連ＳＬＡ１２７５、の各項目を含む一つ以上のレコードで構成されている。
【００５８】
図３ＨはＳＬＡ定義テーブル１２８の一例である。ＳＬＡ定義テーブル１２８には個々のＳＬＡに関する情報が管理される。同図に示すように、ＳＬＡ定義テーブル１２８は、ＳＬＡの名称が設定されるＳＬＡ名１２８１、及びＳＬＡ名１２８１に設定されているＳＬＡの内容が設定されるＳＬＡ内容１２８２、の各項目を含む一つ以上のレコードで構成されている。
【００５９】
図３Ｉはリソース管理テーブル１２９の一例である。リソース管理テーブル１２９には、仮想サーバ２１２で実行されるソフトウエアが使用するリソースの量が管理される。同図に示すように、リソース管理テーブル１２９は、ソフトウエアの名称が設定されるＡＰ名１２９１、ＡＰ名１２９１に設定されているソフトウエアのプロセスの名称が設定されるプロセス名１２９２、プロセス名１２９２に設定されているプロセスが使用するメモリの容量が設定される使用メモリ量１２９３、及びプロセス名１２９２に設定されているプロセスが使用するディスクの容量が設定される使用ディスク量１２９４、の各項目を含む一つ以上のレコードで構成されている。
【００６０】
図３Ｊは依存関係管理テーブル１３０の一例である。依存関係管理テーブル１３０には、仮想サーバ２１２で動作する（インストールされている）、アプリケーション、ミドルウエア、ドライバ、オペレーティングシステム（ＯＳ）などのソフトウエアの種類間の依存関係（レイヤー構成）が管理される。同図に示すように、依存関係管理テーブル１３０は、仮想サーバ２１２の名称が設定される仮想サーバ名１３０１、及び仮想サーバ名１３０１に設定されている仮想サーバ名に対応する仮想サーバ２１２における依存関係が設定される構成情報１３０２、の各項目を含む一つ以上のレコードで構成されている。また同図に示すように、構成情報１３０２は、アプリケーション１３０２１、ミドルウエア１３０２２、ドライバ１３０２３、及びオペレーティングシステム１３０２４などのソフトウエアの種類間の依存関係を示す、階層化されたサブレコードを含む。
【００６１】
図３Ｋはサーバ管理テーブル１３１の一例である。サーバ管理テーブル１３１には、物理サーバ２０又は仮想サーバ２１２が保有している(提供可能な）リソースが管理される。同図に示すように、サーバ管理テーブル１３１は、物理サーバ２０及び仮想サーバ２１２の名称が設定されるサーバ名１３１１、サーバ名１３１１に設定されているサーバ名に対応する物理サーバ２０又は仮想サーバ２１２が保有しているプロセッサ（中央処理装置１０１）に関する情報（例えば、プロセッサの形式、種類（Ｘｅｏｎ（登録商標））、動作クロックや内部キャッシュ等の処理性能）が設定されるＣＰＵ１３１２、サーバ名１３１１に設定されているサーバ名に対応する物理サーバ２０又は仮想サーバ２１２が保有しているメモリ（主記憶装置１０２）に関する情報（容量、応答速度等）が設定されるメモリ１３１３、サーバ名１３１１に設定されているサーバ名に対応する物理サーバ２０又は仮想サーバ２１２が保有しているハードディスクドライブ（補助記憶装置１０３）に関する情報（容量、応答速度等）が設定されるＨＤＤ１３１４、及び物理サーバ２０又は仮想サーバ２１２が保有しているその他のリソースに関する情報１３１５、の各項目を含む一つ以上のレコードで構成されている。
【００６２】
図３Ｌはパッチ管理テーブル１３２の一例である。パッチ管理テーブル１３２には、仮想サーバ２１２にインストールされているソフトウエアのバージョンに関する情報が管理される。同図に示すように、パッチ管理テーブル１３２は、ソフトウエアの名称が設定されるソフトウエア名１３２１、ソフトウエア名１３２１が示すソフトウエアがインストールされている仮想サーバの名称を示す仮想サーバ名１３２２、ソフトウエア名１３２１が示すソフトウエアが更新された日付を示す更新日時１３２５、現在のバージョン（更新後のバージョン）の一つ前のバージョンが設定される更新前バージョン１３２３、更新後のバージョンが設定される更新後バージョン１３２４、の各項目を含む一つ以上のレコードで構成されている。
【００６３】
＜対処実行部＞
図５に図２Ａに示した対処実行部１１８が備える主な機能を示している。同図に示すように、対処実行部１１８は、障害対処処理Ｓ４１５に関する主な機能として、仮想サーバ２１２で実行されているソフトウエアを仮想サーバ２１２単位で他の仮想サーバに移動させる仮想サーバ移動処理部１１８１、仮想サーバ２１２で実行されているソフトウエアをアプリケーション単位で移動させるアプリケーション移動処理部１１８２、仮想サーバ２１２にインストールされているソフトウエアのバージョンをロールバックする（バージョン更新前の状態に戻す）ロールバック処理部１１８３、及び障害の原因がリソース不足であるか否かを判定するリソース不足判定部１１８４を備える。
【００６４】
＜障害対処処理＞
図６は障害対処処理Ｓ４１５の全体的な流れを説明するフローチャートである。以下、同図とともに障害対処処理Ｓ４１５について説明する。尚、以下の説明において、障害が発生している仮想サーバ２１２のことを障害仮想サーバ２１２と称し、障害仮想サーバ２１２を実現している物理サーバ２０のことを障害物理サーバ２０と称する。また障害仮想サーバ２１２において実行されている業務プロセス２１２２のことを障害業務プロセス２１２２と称する。障害仮想サーバ２１２と障害物理サーバ２０の対応は稼働サーバマッピングテーブル１２２から取得することができる。
【００６５】
まず対処実行部１１８は、解析履歴テーブル１２３（図３Ｅ）を参照し、障害仮想サーバ２１２に生じている障害の原因が、その障害仮想サーバ２１２を実現している障害物理サーバ２０のハードウエア障害であるか否かを判断する（Ｓ６１１）。ハードウエア障害である場合の例として、物理サーバ２０が備えるハードディスクドライブ１７１のディスクアクセスエラーがある。
【００６６】
対処実行部１１８は、障害の原因が障害物理サーバ２０のハードウエア障害である場合（Ｓ６１１：ＹＥＳ）、障害仮想サーバ２１２を障害物理サーバ２０から他の物理サーバ２０に移動させる処理（障害仮想サーバ２１２を実現する物理サーバ２０を変更する処理。以下、仮想サーバ移動処理Ｓ６２１と称する。）を行う。一方、障害の原因が障害物理サーバ２０のハードウエア障害でないと判断した場合には（Ｓ６１１：ＮＯ）、Ｓ６３１に進む。
【００６７】
＜仮想サーバ移動処理＞
図７は、仮想サーバ移動処理Ｓ６２１を説明するフローチャートである。仮想サーバ移動処理Ｓ６２１では、障害仮想サーバ２１２で実行されているソフトウエアを他の仮想サーバ２１２に移動させる（障害仮想サーバ２１２を実現している物理サーバ２０を変更する。）。以下、同図とともに仮想サーバ移動処理Ｓ６２１について説明する。
【００６８】
まず対処実行部１１８は、管理サーバ１０の管理対象である各仮想サーバ２１２で動作しているソフトウエアを依存関係管理テーブル１３０から取得し、リソース管理テーブル１２９から、各ソフトウエアが使用するリソース量を取得し、取得したリソース量を合計して各仮想サーバ２１２が使用するリソース量を求める（Ｓ７１１）。
【００６９】
次に対処実行部１１８は、サーバ管理テーブル１３１から、各仮想サーバ２１２が保有しているリソース量を取得し、これとＳ７１１で求めた管理対象である各仮想サーバ２１２が使用するリソース量から、各仮想サーバ２１２の空きリソース量を求める（Ｓ７１２）。
【００７０】
そして対処実行部１１８は、障害仮想サーバ２１２が使用するリソース量と、各仮想サーバ２１２の空きリソース量を比較することにより、障害仮想サーバ２１２を移動させることが可能な他の仮想サーバ２１２を検索する（Ｓ７１３）。移動先の仮想サーバ２１２が存在すれば（Ｓ７１３：ＹＥＳ）、対処実行部１１８は、障害仮想サーバ２１２のソフトウエアをその仮想サーバ２１２に移動させる（Ｓ７１４）。尚、移動先候補の仮想サーバ２１２が複数存在する場合には、例えばそのうちリソース量に最も余裕のある仮想サーバ２１２を選択する。一方、移動させることが可能な仮想サーバ２１２が存在しない場合には（Ｓ７１３：ＮＯ）、Ｓ７２１に進む。
【００７１】
Ｓ７２１では、対処実行部１１８は、仮想サーバ２１２を新規に作成可能か否か判断する（Ｓ７２１）。この判断は、例えばサーバ管理テーブル１３１やリソース管理テーブル１２９から取得できる、管理サーバ１０の管理対象である各物理サーバ２０が保有しているリソース量や各物理サーバ２０の空きリソース量に基づき判断する。
【００７２】
仮想サーバ２１２を新規に作成可能であれば（Ｓ７２１：ＹＥＳ）、仮想サーバ２１２を新規に作成し（Ｓ７２２）、障害仮想サーバ２１２のソフトウエアをその仮想サーバ２１２に移動させる（Ｓ７１４）。一方、そのような物理サーバ２０が存在しない場合には（Ｓ７２１：ＮＯ）、出力装置１０５にメッセージを表示するなどして障害仮想サーバ２１２を移動できない旨をユーザに通知する（Ｓ７２３）。
【００７３】
以上のように、管理サーバ１０は、障害の原因が物理サーバ２０のハードウエア障害であると判断すると、管理サーバ１０の管理対象である仮想サーバ２１２の夫々の空きリソース量を求め、求めた空きリソース量と障害仮想サーバ２１２で実行されているソフトウエアが使用するリソース量とを比較して、障害仮想サーバ２１２で実行されているソフトウエアを移動させることが可能な他の仮想サーバ２１２が存在するか否かを判断し、移動させることが可能な場合は、ソフトウエアを仮想サーバ２１２単位で他の仮想サーバ２１２に移動させる。
【００７４】
このように、以上の仕組みによれば、障害の原因が物理サーバ２０である場合は他の障害仮想サーバ２１２以外の仮想サーバ２１２にソフトウエアが自動的に移動させるので、障害発生時にスムーズに障害仮想サーバ２１２が行っていた処理を復旧させることができる。また空きリソースを有する他の仮想サーバ２１２（物理サーバ２０）を探して移動先とするので、仮想化システムが保有するリソースを有効に利用することができる。
【００７５】
また空きリソースを有する仮想サーバ２１２が見つからない場合には、新たな仮想サーバ２１２を作成可能か否か判断し、可能な場合は仮想サーバ２１２を新規に作成してそこに障害仮想サーバ２１２のソフトウエアを移動させるので、障害からの自動復旧をより確実に行うことができる。
【００７６】
再び図６に戻って説明を続ける。図６のＳ６１１において、障害の原因が障害物理サーバ２０のハードウエア障害でないと判断した場合（Ｓ６１１：ＮＯ）、対処実行部１１８は、イベント履歴テーブル１２１（図３Ａ）に、障害業務プロセス２１２２と同じ業務プロセス２１２２（プロセス名３１３が同じ業務プロセス２１２２）の履歴のうち、処理が正常終了している履歴（例えば、イベント種別３１５に「Information」が設定されている履歴）が存在するか否かを判断する（Ｓ６３１）。正常終了している履歴が存在する場合には（Ｓ６３１：ＹＥＳ）、Ｓ６４１に進む。一方、正常終了している履歴が存在しない場合には（Ｓ６３１：ＮＯ）、Ｓ６５１に進む。
【００７７】
Ｓ６４１では、対処実行部１１８は、パッチ管理テーブル１３２（図３Ｌ）に、その更新日時１３２５が、Ｓ６３１で検索された正常終了している履歴の発生日時３１２の後である、障害仮想サーバ２１２の更新履歴（以下、バージョン更新履歴と称する。）が存在するか否かを判断する。そのようなバージョン更新履歴が存在すれば（Ｓ６４１：ＹＥＳ）、Ｓ６４２に進み、存在しなければ（Ｓ６４１：ＮＯ）、Ｓ６５１に進む。
【００７８】
Ｓ６４２では、対処実行部１１８は、障害仮想サーバ２１２以外の仮想サーバ２１２において、障害業務プロセス２１２２と同じ業務プロセス２１２２の履歴のうち、Ｓ６３１で検索された正常終了している履歴の発生日時３１２の後に行われたバージョン更新履歴の後に正常終了している履歴（例えばイベント種別３１５に「Information」が設定されている履歴）が存在するか否かを判断する（Ｓ６４２）。そのような履歴が存在しない場合には（Ｓ６４１：ＮＯ）、Ｓ６４３に進んでバージョンを元に戻す処理（バージョンダウン処理。以下、ロールバック処理Ｓ６４３と称する。）を行う。即ち、この場合は最近行われたバージョン更新が原因で障害が発生したと推定されるので、対処実行部１１８は、バージョンを元に戻すための処理を行う。
【００７９】
図８はロールバック処理Ｓ６４３を説明するフローチャートである。まず対処実行部１１８は、依存関係管理テーブル１３０（図３Ｊ）から、障害業務プロセス２１２２が実現しているアプリケーションと依存関係のあるソフトウエア（図３Ｊの依存関係管理テーブル１３０では、ミドルウエア、ドライバ、オペレーティングシステム（ＯＳ））を取得する（Ｓ８１１）。
【００８０】
次に対処実行部１１８は、パッチ管理テーブル１３２（図３Ｌ）から、Ｓ８１１で取得した各ソフトウエアの障害発生時より前のバージョン（更新前バージョン６６３）を取得する（Ｓ８１２）。そして対処実行部１１８は、各ソフトウエアのバージョンを取得した更新前バージョン６３３にロールバックする（Ｓ８１３）。
【００８１】
一方、Ｓ６４２において、そのような履歴が存在する場合には（Ｓ６４２：ＹＥＳ）、Ｓ６４４に進み、対処実行部１１８は、障害仮想サーバ２１２で動作しているアプリケーションを他の仮想サーバ２１２に移動させる処理（以下、アプリケーション移動処理Ｓ６４４と称する。）を行う。即ち、この場合は最近行われたバージョン更新は必ずしも障害の原因ではないと推定されるので、ロールバックは行わないが、対処実行部１１８はアプリケーションを他の仮想サーバ２１２に移動させる。
【００８２】
図９はアプリケーション移動処理Ｓ６４４を説明するフローチャートである。まず対処実行部１１８は、依存関係管理テーブル１３０（図３Ｊ）から、障害業務プロセス２１２２が実現しているアプリケーションと依存関係のあるソフトウエア（図３Ｊの依存関係管理テーブル１３０では、ミドルウエア、ドライバ、オペレーティングシステム（ＯＳ））を取得する（Ｓ９１１）。尚、障害業務プロセス２１２２が実現しているアプリケーションは、障害業務プロセス２１２２のプロセス名３１３をキーとしてアプリケーション管理テーブル１２７を検索することにより特定する。
【００８３】
次にＳ９１１で取得した依存関係、アプリケーション管理テーブル１２７、依存関係管理テーブル１３０（図３Ｊ）、及びＳＬＡ定義テーブル１２８に基づき、アプリケーションの移動先となりうる仮想サーバ２１２の候補を検索する（Ｓ９１２）。
【００８４】
例えば障害業務プロセス２１２２のプロセス名が「ａａ」である場合、図３Ｇに示したアプリケーション管理テーブル１２７では、アプリケーション（ＡＰ０１）を移動することになる。この場合、図３Ｊの依存関係管理テーブル１３０では、アプリケーション（ＡＰ０１）は、ミドルウエア（ミドルウエア１）、ドライバ（ドライバ１）、及びオペレーティングシステム（ＯＳ１）という環境で動作するので、移動先の仮想サーバ２１２もそのような環境を備えている必要がある。またアプリケーション（ＡＰ０１）の関連ＳＬＡ１２７５には「ｓｌａ００１，ｓｌａ００３」が設定されているので、移動先の仮想サーバ２１２のミドルウエアもこれらのＳＬＡを満たしている必要がある。
【００８５】
次に対処実行部１１８は、Ｓ９１１で取得した各ソフトウエアが使用するリソース量をリソース管理テーブル１２９から取得する（Ｓ９１３）。
【００８６】
次に対処実行部１１８は、Ｓ９１２で検索した候補の仮想サーバ２１２の空きリソース量を、サーバ管理テーブル１３１から求める（Ｓ９１４）。尚、空きリソース量は例えば図７のＳ７１１で説明したのと同様の方法で取得する。
【００８７】
次に対処実行部１１８は、Ｓ９１３で取得した、Ｓ９１１で取得した各ソフトウエアが使用するリソース量と、Ｓ９１４で求めた、候補の仮想サーバ２１２の空きリソース量とを比較し、アプリケーションを移動させることが可能な仮想サーバ２１２が存在するか否かを判断する（Ｓ９１５）。
【００８８】
移動させることが可能な仮想サーバ２１２が存在する場合には（Ｓ９１５：ＹＥＳ）、障害仮想サーバ２１２のアプリケーションを移動させることが可能と判断した仮想サーバ２１２に移動する（Ｓ９１６）。移動させることが可能な仮想サーバ２１２が存在しない場合には（Ｓ９１５：ＮＯ）、障害仮想サーバ２１２のアプリケーションを移動することができない旨を、出力装置１０５を介してユーザに通知する（Ｓ９１７）。
【００８９】
以上のように、対処実行部１１８は、障害の原因が物理サーバ２０のハードウエア障害でないと判断した場合には、障害業務プロセス２１２２の実行履歴、及び障害業務プロセス２１２２を実現しているソフトウエアの更新履歴に基づき、当該ソフトウエアの更新が行われた後に障害業務プロセス２１２２が正常終了している実行履歴が存在するか否かを判断し、そのような実行履歴が存在しない場合は、ソフトウエアのバージョンをロールバックする。このように、本実施形態の管理サーバ１０は、障害の原因をより正確に特定して適切な対処を行うので、障害からの復旧を確実に行うことができる。
【００９０】
一方、正常終了している実行履歴が存在する場合には、障害業務プロセス２１２２（アプリケーション）を他の仮想サーバ２１２に移動させる。このように、本実施形態の管理サーバ１０は、障害の原因をより正確に特定してアプリケーション単位で移動を行うので、障害からの復旧を迅速かつ確実に行うことができる。
【００９１】
図６のＳ６５１について説明する。Ｓ６５１では、対処実行部１１８は、障害の原因がリソース不足であるか否かを判断する。リソース不足が原因であれば（Ｓ６５１：ＹＥＳ）、Ｓ６４４に進む。リソース不足が原因でなければ（Ｓ６５１：ＮＯ）、Ｓ６８１に進む。
【００９２】
ここでリソース不足が原因か否かの判断は、例えばリソース管理テーブル１２９及び依存関係管理テーブル１３０から、障害業務プロセス２１２２が使用するリソース量を求め、求めたリソース量と、例えばＳ７１１で説明した方法により求まる、障害物理サーバ２０の空きのリソース量とを比較することにより行う。
【００９３】
また正常終了した後に障害業務プロセス２１２２の更新履歴が存在しない場合には（Ｓ６４１：ＮＯ）、例えば次のようにしてリソース不足か否かを判断する。まず対処実行部１１８は、障害発生時点における障害仮想サーバ２１２での業務プロセス２１２２の実行多重度を取得する。一方、対処実行部１１８は、上記正常終了時における業務プロセス２１２２の実行多重度をイベント履歴テーブル１２１から取得する。そして対処実行部１１８は、例えば障害発生時の実行多重度が正常終了時の実行多重度よりも大であればリソース不足であると判断し、障害発生時の実行多重度が正常終了時の実行多重度以下であればリソース不足でないと判断する。
【００９４】
このように、対処実行部１１８は、リソース不足が障害の原因か否かを判断し、リソース不足が原因であると判断した場合には（Ｓ６５１：ＹＥＳ）、障害業務プロセス２１２２（アプリケーション）を他の仮想サーバ２１２に移動させる。このように、本実施形態の管理サーバ１０は、リソース不足が障害の原因であることを迅速に判断してアプリケーション単位で移動を行うので、障害からの復旧を迅速かつ確実に行うことができる。また対処実行部１１８は、リソース不足か否かの判断を、状況（（Ｓ６３１：ＮＯ）の場合か、（Ｓ６５１：ＮＯ）の場合か）に応じて最適な方法で行うので、障害からの復旧を迅速かつ確実に行うことができる。
【００９５】
図６のＳ６６１では、対処実行部１１８は、障害業務プロセス２１２２を再実行する。Ｓ６６２では、対処実行部１１８は、再実行の結果が正常終了か否かを判断する。正常終了であれば（Ｓ６６２：ＹＥＳ）、処理が終了する。正常終了でなければ（Ｓ６６２：ＮＯ）、対処実行部１１８は、対処が正常に終了しなかった旨を、出力装置１０５を介してユーザに通知する（Ｓ６８１）。尚、この通知に際し、例えば障害対処処理Ｓ４１５において行われた処理の経過情報（ログ情報）をユーザに通知するようにしてもよい。
【００９６】
尚、以上の実施形態の説明は本発明の理解を容易にするためのものであり、本発明を限定するものではない。本発明はその趣旨を逸脱することなく、変更、改良され得ると共に本発明にはその等価物が含まれることは勿論である。例えば、障害の原因に応じて設定されるエラーレベルは必ずしも以上に説明したものに限定される訳ではなく、ユーザがエラーレベルを任意に設定できるようにしてもよい。
【符号の説明】
【００９７】
１０  管理サーバ
２０  物理サーバ
３０  記憶装置
１００  コンピュータ
１１１  イベント履歴管理部
１１２  マッピングテーブル管理部
１１３  ユーザインタフェース部
１１４  障害解析部
１１５  ポリシーテーブル管理部
１１６  解析履歴テーブル管理部
１１７  対処テーブル管理部
１１８  対処実行部
１２１  イベント履歴テーブル
１２２  稼働サーバマッピングテーブル
１２３  解析履歴テーブル
１２４  仮想サーバイベント解析ポリシーテーブル
１２５  物理サーバイベント解析ポリシーテーブル
１２６  対処テーブル
１２７  アプリケーション管理テーブル
１２８  ＳＬＡ定義テーブル
１２９  リソース管理テーブル
１３０  依存関係管理テーブル
１３１  サーバ管理テーブル
１３２  パッチ管理テーブル
２１１  仮想化機構
２１２  仮想サーバ
２１２１  オペレーティングシステム
２１２２  業務プロセス
２１２３  仮想イベント通知部
２１３  物理イベント通知部
【図１Ａ】
2010086516.tif 000003
【図１Ｂ】
2010086516.tif 000004
【図２Ａ】
2010086516.tif 000005
【図２Ｂ】
2010086516.tif 000006
【図３Ａ】
2010086516.tif 000007
【図３Ｂ】
2010086516.tif 000008
【図３Ｃ】
2010086516.tif 000009
【図３Ｄ】
2010086516.tif 000010
【図３Ｅ】
2010086516.tif 000011
【図３Ｆ】
2010086516.tif 000012
【図３Ｇ】
2010086516.tif 000013
【図３Ｈ】
2010086516.tif 000014
【図３Ｉ】
2010086516.tif 000015
【図３Ｊ】
2010086516.tif 000016
【図３Ｋ】
2010086516.tif 000017
【図３Ｌ】
2010086516.tif 000018
【図４Ａ】
2010086516.tif 000019
【図４Ｂ】
2010086516.tif 000020
【図５】
2010086516.tif 000021
【図６】
2010086516.tif 000022
【図７】
2010086516.tif 000023
【図８】
2010086516.tif 000024
【図９】
2010086516.tif 000025