JP2015156225A - 複数の監視対象デバイスを有する計算機システムの管理を行う管理システム - Google Patents

Abstract

【課題】障害発生時に回復プラン実行後に予想されるリスクを把握して、適切な回復プランを選択する。【解決手段】汎用ルールテーブル１１９２０及び構成情報テーブル１１８１０に基づいて、複数の展開ルールテーブル１１９５０を生成する。複数の監視対象デバイスのいずれかに関するイベントが発生した場合、生成した複数の展開ルールに基づいて、発生したイベントを条件イベントとして原因解析を行い、結論イベントを特定し、汎用プランテーブル１１９３０に基づいて、１以上の展開プランテーブル１１９６０を生成する。展開プラン情報に基づいて、結論イベント、生成した展開プラン及び展開プランに対応する予測情報を表示する。【選択図】図２

Description

本発明は、例えば、ホストコンピュータ、ネットワークスイッチ、及びストレージ装置等の監視対象装置を含む計算機システムを管理する技術に関する。

計算機システムの管理において、Event Correlation（イベントコリレーション）技術等のイベントベースでの障害原因を特定する技術を用いることで、計算機システムの管理者は、計算機システムにおいて発生した障害の原因を検出することが可能となっている（特許文献１参照）。

また、管理下にある機器において発生した複数の障害イベントの因果関係を解析するための解析エンジンが、事前に定められた条件文と結論文とからなる汎用ルールを、管理下にある機器に関するイベント、例えば、性能値が所定の閾値を超過することのイベントに適用することで、性能低下の原因となる結論イベントと、それによって引き起こされている条件イベント群とを含む展開ルールを生成し、生成した展開ルールに基づいて障害の特定を行う技術が存在する（特許文献２参照）。

近年の計算機システムには、原因解析によって特定された原因に対する復旧方法として実施可能な有用な方法が数多く存在しており、例えば、システムリソース(仮想マシン、データ)の配置にあたり、適切なデータ移動を行うことによって障害からの復旧を行うという方法等が存在する。データ移動技術として、例えば、物理的なホスト計算機の上で複数の仮想的なホスト計算機（すなわち仮想マシンのことであり、以下「ＶＭ」と呼ぶ）を動作させている環境において、ＶＭの性能を示す情報やリソースの利用情報に従って、ＶＭの動作環境を或る物理的なホスト計算機から別の物理的なホスト計算機に引き継がせる技術（第１のＶＭ移動）や、或る記憶領域に格納されているＶＭを別の記憶領域へ移動させる技術（第２のＶＭ移動）が知られている。ここで、ＶＭは記憶領域に格納されるデータの一種であり、ＶＭ移動（第１のＶＭ移動及び第２のＶＭ移動）は記憶領域間のデータ移動の一種である。また、ストレージ装置のデータ記憶領域（ボリューム）間でのデータ移動技術（ボリュームマイグレーション）が知られている（特許文献３参照）。

米国特許第７１０７１８５号明細書 特開２０１０−８６１１５号公報 米国特許第６１０８７４８号明細書

特許文献１のようなEvent Correlation技術により特定された障害に対応する場合、管理者が具体的にどのような方法を実施して障害回復を行えばよいかがわからず、障害から回復するまでにコストがかかる。

また、Event Correlation技術により特定された障害に対応するため、障害原因そのものの回復を行うプランや、障害原因により影響を受ける業務の再開を最優先にするプラン等、様々なプランを実施し得るケースが存在し得る。例えば、ストレージポートの性能障害による業務の応答性能低下の場合、障害の発生したポートを利用しないよう、業務を別のサーバに移行するプラン（例えばＶＭ移動に関するプラン）や、ポートを交換するプラン等がある。

障害原因そのものの回復を行わないプランを実施した対処の場合、プラン実行後にも障害原因に起因するリスクが残り続ける可能性があるものの、管理者は、計算機システム内のどこにどのような問題が残るかわからない。そのため、管理者は、リスクの残る可能性がある場合に、障害原因そのものの回復を行わないプラン（例えば、業務の再開を最優先にするプラン）を意図せず選択することがあり得る。

複数の監視対象デバイスを有する計算機システムの管理を行う。管理システムの記憶デバイスは、複数の監視対象デバイスのいずれかに関する１以上の条件イベントと、１以上の条件イベントが発生した場合に原因となる、複数の監視対象デバイスのいずれかに関する結論イベントとの対応関係を示し、条件イベント及び結論イベントに関係する監視対象デバイスを当該監視対象デバイスの種別で表した汎用ルールと、汎用ルールと汎用ルールの結論イベントが原因である場合に取り得る回復策である１以上の汎用プランとの対応関係を示す汎用プラン情報、汎用ルールと汎用プランとの組み合わせごとに、当該汎用プランが実施された場合に未解決のまま残される、当該汎用ルールの条件イベントを示す未解決情報と、複数の監視対象デバイス間の接続関係を示す構成情報とを記憶する。管理システムの制御デバイスは、汎用ルール及び構成情報に基づいて、条件イベント及び結論イベントに関係する監視対象デバイスの種別を特定の監視対象デバイスを示すデータで表した複数の展開ルールを生成し、複数の監視対象デバイスのいずれかに関するイベントが発生した場合、生成した複数の展開ルールに基づいて、発生したイベントを条件イベントとして原因解析を行い、前記発生したイベントの原因の候補となる第１の結論イベントを特定し、汎用プラン情報に基づいて、第１の結論イベントが原因である場合に実施し得る回復策であって、第１の結論イベントを含む展開ルールの基となる汎用ルールに対応する汎用プランを計算機システムの実構成を考慮して展開した回復策である１以上の展開プランを生成し、生成した１以上の展開プランのそれぞれについて、未解決情報に基づいて当該展開プランが実施された場合に未解決のまま残される未解決イベントを特定し、特定した未解決イベントに基づいて当該展開プランが実施された後も問題が残り続ける監視対象デバイスであるリスク箇所を特定し、第１の結論イベント、生成した１以上の展開プラン、及び特定したリスク箇所を示すデータを表示する。

図１は、実施例１に係る計算機システムの一例の構成図である。 図２は、実施例１に係る管理サーバの一例の構成図である。 図３は、実施例１に係るストレージ装置の一例の構成図である。 図４は、実施例１に係る物理サーバの一例の構成図である。 図５は、実施例１に係る構成情報テーブルの一例の構成図である。 図６は、実施例１に係る性能情報テーブルの一例の構成図である。 図７は、実施例１に係るイベント管理テーブルの一例の構成図である。 図８は、実施例１に係る汎用ルールテーブルの一例の構成図である。 図９は、実施例１に係る汎用プランテーブルの一例の構成図である。 図１０は、実施例１に係るルール・プラン対応テーブルの一例の構成図である。 図１１は、実施例１に係る展開ルールテーブルの一例の構成図である。 図１２Ａは、実施例１に係る展開プランテーブルの第１の構成図である。 図１２Ｂは、実施例１に係る展開プランテーブルの第２の構成図である。 図１３は、実施例１に係る解析結果管理テーブルの一例の構成図である。 図１４は、実施例１に係るイベント解析処理のフローチャートである。 図１５は、実施例１に係るルール展開処理のフローチャートである。 図１６は、実施例１に係るプラン生成処理のフローチャートである。 図１７は、実施例１に係るプラン実行後リスク抽出処理のフローチャートである。 図１８は、実施例１に係るプラン提示処理のフローチャートである。 図１９は、実施例１に係る効果・リスク提示処理のフローチャートである。 図２０は、実施例１に係るプラン提示画面の一例の構成図である。 図２１は、実施例１に係るプラン詳細画面の一例の構成図である。 図２２は、実施例２に係る管理サーバの一例の構成図である。 図２３は、実施例２に係る物理サーバの一例の構成図である。 図２４は、実施例２に係る物理サーバの一例の論理的な構成図である。 図２５は、実施例２に係るスイッチの一例の構成図である。 図２６は、実施例２に係る構成情報テーブルの一例の構成図である。 図２７は、実施例２に係るＶＭ構成管理テーブルの一例の構成図である。 図２８は、実施例２に係る性能情報テーブルの一例の構成図である。 図２９は、実施例２に係るイベント管理テーブルの一例の構成図である。 図３０Ａは、実施例２に係る汎用ルールテーブルの第１の構成図である。 図３０Ｂは、実施例２に係る汎用ルールテーブルの第２の構成図である。 図３１は、実施例２に係るルール・プラン対応テーブルの一例の構成図である。 図３２Ａは、実施例２に係る展開ルールテーブルの第１の構成図である。 図３２Ｂは、実施例２に係る展開ルールテーブルの第２の構成図である。 図３３Ａは、実施例２に係る展開プランテーブルの第１の構成図である。 図３３Ｂは、実施例２に係る展開プランテーブルの第２の構成図である。 図３３Ｃは、実施例２に係る展開プランテーブルの第３の構成図である。 図３４は、実施例２に係る解析結果管理テーブルの一例の構成図である。 図３５は、実施例２に係るプラン提示処理のフローチャートである。 図３６は、実施例２に係るプラン提示画面の一例の構成図である。 図３７は、実施例３に係る管理サーバの一例の構成図である。 図３８は、実施例３に係る汎用プランテーブルの一例の構成図である。 図３９は、実施例３に係るルール・プラン対応テーブルの一例の構成図である。 図４０Ａは、実施例３に係る展開プランテーブルの第１の構成図である。 図４０Ｂは、実施例３に係る展開プランテーブルの第２の構成図である。 図４１は、実施例３に係る保守情報管理テーブルの一例の構成図である。 図４２は、実施例３に係る効果・リスク提示処理のフローチャートである。 図４３は、実施例３に係るプラン詳細画面の一例の構成図である。

幾つかの実施例を、図面を参照して説明する。なお、以下に説明する実施例は特許請求の範囲にかかる発明を限定するものではなく、また実施例の中で説明されている諸要素及びその組み合わせの全てが発明の解決手段に必須であるとは限らない。これらの図面において、複数の図を通じて同一の符号は同一の構成要素を示している。なお、以後の説明では「ａａａテーブル」等の表現にて本発明の情報を説明するが、これら情報はテーブル等のデータ構造以外で表現されていてもよい。そのため、データ構造に依存しないことを示すために「ａａａテーブル」等について「ａａａ情報」と呼ぶことがある。さらに、各情報の内容を説明する際に、「識別情報」、「識別子」、「名称」、「ＩＤ」という表現を用いるが、これらについてはお互いに置換が可能である。

以後の説明では「プログラム」を主語として説明を行う場合があるが、プログラムはプロセッサによって実行されることで定められた処理をメモリ及び通信ポート（通信デバイス、管理Ｉ／Ｆ、データＩ／Ｆ）を用いながら行うため、プロセッサを主語とした説明としてもよい。また、プログラムを主語として開示された処理は管理サーバ等の計算機、情報処理装置が行う処理としてもよい。また、プログラムの一部または全ては専用ハードウェアによって実現されてもよい。また、各種プログラムはプログラム配布サーバや、計算機が読み取り可能な記憶メディアによって各計算機にインストールされてもよい。

以後、計算機システムを管理し、本発明の表示用情報を表示する一つ以上の計算機の集合を管理システムと呼ぶことがある。管理サーバが表示用情報を表示する場合は管理サーバが管理システムである、また、管理サーバと表示用計算機との組み合わせも管理システムである。また、管理処理の高速化や高信頼化のために複数の計算機で管理サーバと同等の処理を実現してもよく、この場合は当該複数の計算機（表示を表示用計算機が行う場合は表示用計算機も含め）が管理システムである。

まず、実施例１に係る計算機システムについて説明する。

図１は、実施例１に係る計算機システムの一例の構成図である。

本実施例に係る計算機システムは、１台以上の管理サーバ１００００（図１では管理サーバＡ）、１台以上のストレージ装置２００００（図１ではストレージ装置Ａ）、及び１台以上の物理サーバ３００００（図１では物理サーバＡ）を備える。物理サーバ３００００及びストレージ装置２００００は、ＳＡＮ（Storage Area Network）４００００（具体的にはファイバチャネル）を介して互いに接続される。管理サーバ１００００、ストレージ装置２００００、及び物理サーバ３００００は、管理用ネットワーク５００００を介して互いに接続される。

管理サーバ１００００は、プラン生成プログラム１１１００、プラン実行後リスク抽出プログラム１１２００、プラン提示プログラム１１３００、構成性能情報リポジトリ１１８００、及びルール・プラン情報リポジトリ１１９００をメモリ１１０００（図２参照）に格納する。管理サーバ１００００は、管理用ネットワーク５００００を介して、ストレージ装置２００００、物理サーバ３００００上で動作するプログラムと通信できる。

ストレージ装置２００００には、１以上の論理ボリューム２２１００が作成される。論理ボリューム２２１００は、例えば物理サーバ３００００に提供される。図１に示す例では、ストレージ装置Ａは、物理サーバＡに対して、論理ボリューム２２１００を提供する。

物理サーバ３００００は、ストレージ装置２００００から提供された論理ボリューム２２１００を用いて、各種業務を実行する。図１に示す例では、物理サーバＡとストレージ装置Ａとは、ＳＡＮ４００００を介して互いに接続される。

図１に示す例では、管理サーバ１００００が、プラン生成プログラム１１１００、プラン実行後リスク抽出プログラム１１２００、プラン提示プログラム１１３００等のプログラムを格納しているが、これに限定されない。例えば、ストレージ装置２００００または物理サーバ３００００が、各種プログラムを格納してもよく、また、各装置間に設置されているスイッチ（図示しない）等の他の装置が、各種プログラムを格納してもよい。また、ストレージ装置２００００と物理サーバ３００００との間の接続は、ファイバチャネルを介して直接接続されるものに限定されず、１台以上のファイバチャネルスイッチ等のネットワーク機器を介して接続されてもよい。また、ストレージ装置２００００と物理サーバ３００００との間の接続は、データ通信用のネットワークであればよく、例えば、ＩＰ（Internet Protocol）ネットワークでもよい。

図２は、実施例１に係る管理サーバの一例の構成図である。

管理サーバ１００００は、メモリ１１０００、記憶デバイス１２０００、入力デバイス１３０００、出力デバイス１４０００、プロセッサ１５０００、及び通信デバイス１６０００を備え、これらは内部バス等の通信路１７０００を介して互いに接続される。

メモリ１１０００は、プラン生成プログラム１１１００、プラン実行後リスク抽出プログラム１１２００、プラン提示プログラム１１３００、イベント解析処理プログラム１１４００、ルール展開プログラム１１５００、構成設定管理プログラム１１６００、性能情報収集プログラム１１７００、構成性能情報リポジトリ１１８００、及びルール・プラン情報リポジトリ１１９００を格納する。

構成性能情報リポジトリ１１８００には、構成情報テーブル１１８１０及び性能情報テーブル１１８２０が格納される。ルール・プラン情報リポジトリ１１９００には、イベント管理テーブル１１９１０、１以上の汎用ルールテーブル１１９２０、汎用プランテーブル１１９３０、ルール・プラン対応テーブル１１９４０、１以上の展開ルールテーブル１１９５０、１以上の展開プランテーブル１１９６０、及び解析結果管理テーブル１１９７０が格納される。

構成情報テーブル１１８１０は、物理サーバ３００００から、物理サーバ３００００が使用している論理ボリューム２２１００を構成する物理ディスクまでのＩ／Ｏ（入出力）経路上に存在する装置及びデバイスを示す情報、すなわち、Ｉ／Ｏ経路に基づく装置及びデバイスの接続関係を示す情報（以下「構成情報」という）を管理する。

性能情報テーブル１１８２０は、ＳＡＮ４００００に接続された監視対象の各装置、及び監視対象の装置内の各デバイス（監視対象デバイス）についての性能情報を管理する。

イベント管理テーブル１１９１０は、計算機システム内のどのデバイスのどのようなメトリックに関して、いつイベントが発生したかを示す情報を管理する。

汎用ルールテーブル１１９２０は、計算機システム内で発生し得る１つ以上の条件イベントとその１以上の条件イベントに対する障害の原因とされる結論イベントとの対応関係を示す汎用ルールを管理する。

汎用プランテーブル１１９３０は、障害に対する、計算機システム内で実施し得る回復プランを示す情報を管理する。

ルール・プラン対応テーブル１１９４０は、汎用ルールと、当該汎用ルール対応する回復策、すなわち、当該汎用ルールの結論イベントが原因である場合に実施し得る回復策を表す汎用プランとの対応関係を表す情報（汎用プラン情報）、及び、各汎用プラン実行後に、汎用ルールにおける障害イベントのうちどの障害イベントが未解決のまま残るかを表す情報（未解決情報）を管理する。

展開ルールテーブル１１９５０は、汎用ルールテーブル１１９２０の情報を、構成情報テーブル１１８１０の情報に基づいて具体化した情報（展開ルール）を格納する。

展開プランテーブル１１９６０は、汎用プランテーブル１１９３０の情報を、構成情報テーブル１１８１０及び性能情報テーブル１１８２０の情報に基づいて具体化した情報（展開プラン）を格納する。

解析結果管理テーブル１１９７０は、障害の原因と判断されたイベントの発生した装置及びデバイスと、その原因と判断された障害イベントに関する情報を格納する。

記憶デバイス１２０００は、情報を格納するＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）等である。入力デバイス１３０００は、管理者が管理サーバ１００００に指示を入力するためのデバイス、例えばキーボード等である。出力デバイス１４０００は、管理サーバ１００００が実行した処理結果、例えばプラン提示プログラム１１３００の実行結果等を出力するデバイス、例えばディスプレイ等である。プロセッサ１５０００は、メモリ１１０００上に展開されているプログラムを実行する。通信デバイス１６０００は、管理用ネットワーク５００００に接続するためのデバイスである。

図２に示す例では、各種プログラム及びテーブルは、メモリ１１０００に格納されているが、記憶デバイス１２０００または他の記憶媒体（図示しない）に格納されていてもよい。この場合、プロセッサ１５０００は、プログラム実行時にメモリ１１０００上に対象のプログラムを読み出し、読み出したプログラムを実行する。また、ストレージ装置２００００のメモリ２１０００（図３参照）または物理サーバ３００００のメモリ３１０００（図４参照）に、前述のプログラム及びテーブルが格納され、ストレージ装置２００００または物理サーバ３００００が、格納されたプログラムを実行してもよい。また、他の物理サーバ３００００またはスイッチ（図示しない）等の他の装置が、前述のプログラム及びテーブルを格納し、格納したプログラムを実行してもよい。

図３は、実施例１に係るストレージ装置の一例の構成図である。

ストレージ装置２００００は、メモリ２１０００、論理ボリューム提供部２２０００、ディスクＩ／Ｆコントローラ２３０００、管理Ｉ／Ｆ２４０００、プロセッサ２５０００、及びデータＩ／Ｆ２６０００を備え、これらは内部バス等の通信路２７０００を介して接続される。

メモリ２１０００は、ディスクキャッシュ２１１００を有する。また、メモリ２１０００は、構成性能情報収集プログラム２１２００を格納する。ディスクキャッシュ２１１００は、情報を一時格納するための記憶領域である。構成性能情報収集プログラム２１２００は、ストレージ装置２００００の管理情報及び性能情報等を管理サーバ１００００との間で送受信するためのプログラムである。

論理ボリューム提供部２２０００は、１以上の物理ディスク（図示しない）の記憶領域によって構成されるディスクプール２２２００を備え、ディスクプール２２２００の記憶領域を論理的に分割し、当該論理的に分割された記憶領域を論理ボリューム２２１００として提供する。これによって、当該ストレージ装置２００００外の装置からの論理ボリューム２２１００に対するアクセスを可能としている。なお、ディスクプール２２２００にはディスクプール番号が付され、論理ボリューム２２１００には論理ボリューム番号が付される。これによって、ストレージ装置２００００は、ディスクプール２２２００及び論理ボリューム２２１００をそれぞれ一意に識別することができる。

図３に示す例では、２つのディスクプール２２２００（ＰＯＯＬ１及びＰＯＯＬ２）がそれぞれ論理的に分割され、４つの論理ボリューム２２１００（ＬＶ１、ＬＶ２、ＬＶ３、及びＬＶ４）がストレージ装置２００００外の装置（例えば、物理サーバ３００００）に提供される。ディスクＩ／Ｆコントローラ２３０００は、論理ボリューム提供部２２０００に接続するためのインタフェースデバイスである。管理Ｉ／Ｆ２４０００は、管理用ネットワーク５００００に接続するためのインタフェースデバイスである。プロセッサ２５０００は、メモリ２１０００上に展開されたプログラムを実行する。データＩ／Ｆ２６０００は、ＳＡＮ４００００に接続するためのインタフェースデバイスである。なお、ディスクＩ／Ｆ制御部２３０００、管理Ｉ／Ｆ２４０００、及びデータＩ／Ｆ２６０００は、複数個あってもよい。

図３に示す例では、ストレージ装置２００００は、データＩ／Ｆ（Ｐ１）及びデータＩ／Ｆ（Ｐ２）の２つのデータＩ／Ｆ２６０００を備える。図３に示す例では、構成性能情報収集プログラム２１２００は、メモリ２１０００に格納されているが、他の記憶装置（図示しない）または他の記憶媒体（図示しない）に格納されていてもよい。この場合、プロセッサ２５０００は、処理実行時にメモリ２１０００上に構成性能情報収集プログラム２１２００を読み出し、読み出した構成性能情報収集プログラム２１２００を実行する。

また、管理サーバ１００００のメモリ１１０００に構成性能情報収集プログラム２１２００が格納され、管理サーバ１００００が、格納されたプログラム２１２００を実行してもよい。また、他のストレージ装置２００００が、構成性能情報収集プログラム２１２００を格納し、格納したプログラム２１２００を実行してもよい。また、論理ボリューム提供部２２０００は、１つの物理ディスク２２２００の全記憶領域を１つの論理ボリューム２２１００として作成してもよい。また、論理ボリューム提供部２２０００は、物理ディスク２２２００以外の記憶媒体、例えばフラッシュメモリ等の記憶領域により論理ボリューム２２１００を作成してもよい。

図４は、実施例１に係る物理サーバの一例の構成図である。

物理サーバ３００００は、メモリ３１０００、データＩ／Ｆ３２０００、プロセッサ３３０００、及び管理Ｉ／Ｆ３４０００を備え、これらは内部バス等の通信路３５０００を介して互いに接続される。

メモリ３１０００は、構成性能情報収集プログラム３１１００、業務プログラム３１２００、及びボリューム管理プログラム３１３００を格納する。

構成性能情報収集プログラム３１１００は、物理サーバ３００００の管理情報、性能情報等を管理サーバ１００００との間で送受信するためのプログラムである。業務プログラム３１２００は、物理サーバ３００００が実行する業務を実現するためのプログラムであり、例えば、ＤＢＭＳ（Data Base Management System）やファイルシステム等である。ボリューム管理プログラム３１３００は、ストレージ装置２００００によって提供される論理ボリューム２２１００を物理サーバ３００００に割り当てるためのプログラムである。物理サーバ３００００は、ボリューム管理プログラム３１３００によって割り当てられた論理ボリューム２２１００を用いて業務を実行する。

データＩ／Ｆ３２０００は、ＳＡＮ４００００に接続するためのインタフェースデバイスである。プロセッサ３３０００は、メモリ３１０００上に展開されたプログラムを実行する。管理Ｉ／Ｆ３４０００は、管理用ネットワーク５００００に接続するためのインタフェースデバイスである。

なお、データＩ／Ｆ３２０００及び管理Ｉ／Ｆ３４０００は、複数個あってもよい。図４に示す例では、各種プログラムは、メモリ３１０００に格納されているが、他の記憶装置（図示しない）に格納されていてもよい。この場合、プロセッサ３３０００は、処理実行時にメモリ３１０００上に対象のプログラムを読み出し、読み出したプログラムを実行する。

図５は、実施例１に係る構成情報テーブルの一例の構成図である。

構成情報テーブル１１８１０には、論理ボリューム２２１００に物理サーバ３００００がアクセスする場合に経由するＩ／Ｏ経路であって、物理サーバ３００００から当該物理サーバ３００００に提供された論理ボリューム２２１００を構成する物理ディスクまでのＩ／Ｏ経路に関する情報が格納される。構成設定管理プログラム１１６００が実行されることによって、構成情報テーブル１１８１０にエントリが追加される。

構成情報テーブル１１８１０は、物理サーバ１１８１１、ドライブ１１８１２、サーバデータＩ／Ｆ１１８１３、ストレージ１１８１４、ストレージデータＩ／Ｆ１１８１５、論理ボリューム１１８１６、及びディスクプール１１８１７のフィールドを含む。物理サーバ１１８１１には、物理サーバ３００００を一意に識別するための識別子が格納される。ドライブ１１８１２には、物理サーバ３００００上のボリュームのマウントポイントを一意に識別するための識別子が格納される。サーバデータＩ／Ｆ１１８１３には、物理サーバ３００００が、論理ボリューム１１８１６の識別子によって示される論理ボリューム２２１００にアクセスする際に利用される物理サーバ３００００のデータＩ／Ｆ３２０００（以下「サーバデータＩ／Ｆ」という場合がある）を一意に識別するための識別子が格納される。ストレージ１１８１４には、物理サーバ３００００のアクセス先となるストレージ装置２００００を一意に識別するための識別子が格納される。ストレージデータＩ／Ｆ１１８１５には、物理サーバ３００００が、論理ボリューム１１８１６の識別子によって示される論理ボリューム２２１００にアクセスする際に利用されるストレージ装置２００００のデータＩ／Ｆ２６０００（以下「ストレージデータＩ／Ｆ」という場合がある）を一意に識別するための識別子が格納される。論理ボリューム１１８１６には、論理ボリューム２２１００を一意に識別するための識別子が格納される。ディスクプール１１８１７には、論理ボリューム１１８１６の識別子によって示される論理ボリューム２２１００が作成されているディスクプール２２２００を一意に識別するための識別子が格納される。

例えば、図５の上から１つ目のエントリは、ストレージＡ（ストレージ装置Ａ）のディスクプール「ＰＯＯＬ１」から生成された論理ボリューム「ＬＶ１」が、ストレージデータＩ／Ｆ「Ｐ１」、及びサーバデータＩ／Ｆ「Ｓ１」を経由して物理サーバＡと接続され、物理サーバＡ上で論理ボリューム「／ｏｐｔ」として認識されていることを示す。

ここで、本実施例に係る構成情報テーブル１１８１０は、アクセス経路上に存在する装置及びデバイスとして、物理サーバ３００００、サーバデータＩ／Ｆ、ストレージ装置２００００、ストレージデータＩ／Ｆ、論理ボリューム２２１００、及びディスクプール２２２００の情報を含んでいるが、これに限定されない。例えば、構成情報テーブル１１８１０は、スイッチ、スイッチのデータＩ／Ｆ等の情報を含んでもよく、また、業務サーバ３００００上の業務プログラム（ＤＢＭＳ等）の情報あるいはＶＭ情報、ＶＭのスナップショットを保存するスナップショットボリュームや、クローンを保存するクローンボリューム等を関連付けて格納してもよい。また、構成情報テーブル１１８１０は、構成管理操作の履歴情報を保持していてもよく、Ｓｙｓｌｏg（シスログ）サーバ等と連携して、システム動作を表す詳細なログ情報を保持していてもよい。

図６は、実施例１に係る性能情報テーブルの一例の構成図である。

性能情報テーブル１１８２０には、計算機システムを構成する装置または装置内のデバイスに関する性能情報、例えば、各ストレージ装置２００００における論理ボリューム２２１００、ディスクプール２２２００等に関する性能情報が格納される。性能情報収集プログラム１１７００が実行されることによって、性能情報テーブル１１８２０にエントリが追加される。

性能情報テーブル１１８２０は、装置ＩＤ１１８２１、デバイスＩＤ１１８２２、メトリック１１８２３、機器ＯＳ１１８２４、性能値１１８２５、アラート実行閾値１１８２６、閾値種別１１８２７、及びＳｔａｔｕｓ１１８２８のフィールドを含む。

装置ＩＤ１１８２１には、装置を一意に特定する識別子（装置ＩＤ）が格納される。デバイスＩＤ１１８２２には、性能情報の取得対象となるデバイスを一意に識別するための識別子（デバイスＩＤ）が格納される。メトリック１１８２３には、ＣＰＵ使用率、記憶装置に対する単位時間（例えば、１秒）あたりのＩ／Ｏ回数（ＩＯＰＳ）、リクエストに対するレスポンスの時間等の、性能情報の種類を示す情報が格納される。機器ＯＳ１１８２４には、装置ＩＤ１１８２１の装置ＩＤに対応する装置上で動作するＯＳ（Operating System）の種別を示すデータが格納される。性能値１１８２５には、デバイスＩＤ１１８２２によって示されたデバイスの、メトリック１１８２３によって示された種類の性能情報の値が、デバイスを含む装置から取得されて格納される。アラート実行閾値１１８２６には、管理対象の性能値の正常範囲の上限もしくは下限等の閾値（以下「アラート実行閾値」という）が、ユーザから指定されて格納される。閾値種別１１８２７には、アラート実行閾値が正常値の上限であるのか下限であるのかを示すデータが格納される。Ｓｔａｔｕｓ１１８２８には、性能値１１８２５が正常値であるか異常値であるかを示すデータが格納される。

ここで、図６に示す性能情報テーブル１８２０では、任意の１つの装置の任意の１つのデバイスの任意の１つのメトリックについて、性能値は１つだけ対応しているが、性能情報テーブル１１８２０の各情報を性能情報収集プログラム１１７００が構成性能情報収集プログラム２１２００、３１１００と通信して、各装置が保持する情報を取得した時刻を示す値と共に格納するようにし、取得した時刻に対応する複数の時点の性能値を履歴情報として保持してもよい。

デバイスＩＤ１１８２２のデバイスＩＤによって示される、性能情報の取得対象のデバイスとして、ストレージデータＩ／Ｆ、論理ボリューム２２１００、ディスクプール２２２００、物理サーバ３００００が認識するマウントポイントをあげたが、これらに限定されず、サーバデータＩ／Ｆや物理ディスク、スイッチやスイッチのポート等でもよい。

また、メトリックの一例として、ＣＰＵ使用率、ＩＯＰＳ、リクエストに対するレスポンスの時間等を示したが、Ｉ／Ｏビジー率、転送レート、スループット、データベース管理ソフトのバッファヒット率や挿入・更新・削除レコード数、Ｗｅｂサーバのレスポンスの時間、ファイルシステムやディスクの空き容量や利用率、入出力データ量、利用時刻等、ネットワークインタフェースのエラー回数、バッファのオーバーフロー、及びフレームのエラー等の他の性能指標が用いられてもよい。

また、アラート実行閾値１１８２６に格納するアラート実行閾値として、ユーザによって指定された閾値ではなく、例えば、性能情報の履歴情報の平均値等を利用したベースライン値との差分値等のアラートを通知する契機となりうる値が採用されてもよい。

図７は、実施例１に係るイベント管理テーブルの一例の構成図である。

イベント解析処理プログラム１１４００は、性能情報テーブル１１８２０に登録された性能値とアラート実行閾値とを比較し、性能値がアラート実行閾値を超えていたら、対応するイベントを示すエントリを作成し、作成したエントリをイベント管理テーブル１１９１０に登録する。なお、イベント解析処理プログラム１１４００は、システム内の各種装置からイベントの発生を示すイベントメッセージを受信し、受信したイベントメッセージに対応するイベントを示すエントリをイベント管理テーブル１１９１０に登録するようにしてもよい。イベント管理テーブル１１９１０は、ルール展開処理（図１５参照）において適宜参照される。

イベント管理テーブル１１９１０は、イベントＩＤ１１９１１、装置ＩＤ１１９１２、装置部位ＩＤ１１９１３、メトリック１１９１４、機器ＯＳ１１９１５、ステータス１１９１６、解析済みフラグ１１９１７、及び発生日時１１９１８のフィールドを含む。イベントＩＤ１１９１１には、イベント自身の識別子であるイベントＩＤが格納される。装置ＩＤ１１９１２には、イベントが発生した装置の識別子である装置ＩＤが格納される。装置部位ＩＤ１１９１３には、イベントが発生したデバイスの識別子が格納される。メトリック１１９１４には、閾値異常が検知されたメトリックの名称が格納される。機器ＯＳ１１９１５には、閾値異常が検知された装置のＯＳの種別を示すデータが格納される。ステータス１１９１６には、イベントが発生したデバイスのイベント発生時の状態を示すデータが格納される。解析済みフラグ１１９１７には、イベントがルール展開プログラム１１５００によって解析済みかどうかを示すデータが格納される。発生日時１１９１８には、イベントが発生した日時を示すデータが格納される。

例えば、図７の上から１つ目のエントリは、管理サーバ１００００が、ストレージ装置ＡのデータＩ／Ｆ「Ｐ２」におけるプロセッサ稼働率の閾値異常を２０１２年６月３０日の１５時００分００秒に検知し、そのイベントＩＤが「ＥＶ１」であり、このイベントがルール展開プログラム１１５０００によって解析されていないことを示している。

図８は、実施例１に係る汎用ルールテーブルの一例の構成図である。

ルール・プラン情報リポジトリ１１９００には、１以上の汎用ルールテーブル１１９２０が格納される。本実施例では、１つの汎用ルールテーブル１１９２０によって、１つの汎用ルールが規定される。汎用ルール（後述の展開ルールも同様）は、計算機システムを構成するノード装置で発生し得る１つ以上の条件イベントの組み合わせと、その１つ以上の条件イベントの組み合わせに対して障害の原因とされる結論イベントとの関係を示すデータである。一般的に、障害解析において原因を特定するためのイベント伝播モデルは、ある障害の結果が発生することが予想されるイベントの組み合わせと、その原因とが“ＩＦ−ＴＨＥＮ”形式で記載される。なお、汎用ルールは図８に挙げられたものに限られず、さらに多くのルールがあっても構わない。

汎用ルールテーブル１１９２０は、条件部１１９２１、結論部１１９２２、汎用ルールＩＤ１１９２３、及び適用トポロジ１１９２４のフィールドを含む。

条件部１１９２１には、“ＩＦ−ＴＨＥＮ”形式で記載した汎用ルールのＩＦ部に相当する観測事象、すなわち、１以上の条件イベントのそれぞれを示すデータが格納される。条件部１１９２１は、イベントＩＤ１１９２５、装置種別１１９２６、装置部位種別１１９２７、メトリック１１９２８、及びステータス１１９２９のフィールドを含む。結論部１１９２２には、“ＩＦ−ＴＨＥＮ”形式で記載した汎用ルールのＴＨＥＮ部に相当する原因事象、すなわち、結論イベントを示すデータが格納される。結論部１１９２２は、装置種別１１９２６、装置部位種別１１９２７、メトリック１１９２８、及びステータス１１９２９のフィールドを含む。汎用ルールＩＤ１１９２３には、汎用ルールの識別子である汎用ルールＩＤが格納される。適用トポロジ１１９２４には、汎用ルールを実システムに展開し，展開ルールを生成する際に参照されるトポロジを示すデータが格納される。イベントＩＤ１１９２５には、“ＩＦ−ＴＨＥＮ”形式で記載した汎用ルールのＩＦ部に相当する観測事象に含まれるイベント（条件イベント）を一意に識別する識別子（イベントＩＤ）が格納される。装置種別１１９２６には、条件イベント又は結論イベントが発生する装置の種別を示すデータが格納される。装置部位種別１１９２７には、条件イベント又は結論イベントが発生するデバイスの種別を示すデータが格納される。メトリック１１９２８には、ＣＰＵ使用率、記憶装置に対するＩＯＰＳ、リクエストに対するレスポンスの時間等の、性能情報の種類を示す情報が格納される。ここで、メトリック１１９２８に格納する性能情報としては、性能情報テーブル１１８２０のメトリック１１８２３に格納する性能情報と同様に、他の性能情報を用いてもよい。ステータス１１９２９には、装置内のデバイスのイベント発生時の状態を示すデータが格納される。

条件部１１９２１に記述された１以上の条件イベントが検知された場合、結論部１１９２２に記述された結論イベントが障害の原因と判定される。結論部１１９２２のステータスが正常になれば、すなわち結論イベントに関係する性能値が正常値に戻れば、条件部１１９２１の問題も解決される、すなわち各条件イベントに関係する性能値も正常値に戻ることが期待される。図８の例では、条件部１１９２１には３つのイベントが記述されているが、イベント数に制限はない。

例えば、図８に例示した汎用ルール、すなわち、汎用ルールＩＤが「ＲＵＬＥ１」で示される汎用ルールは、観測事象として、ホストコンピュータ上のドライブのレスポンスタイムの閾値異常と、ストレージ装置２００００における論理ボリューム２２１００の単位時間のＩ／Ｏ量の閾値異常と、ストレージ装置２００００におけるディスクプール２２２００の単位時間のＩ／Ｏ量の閾値異常とを検知したときに、ストレージ装置２００００におけるディスクプール２２２００の単位時間のＩ／Ｏ量の閾値異常が原因であると結論付けられることを示している。なお、観測事象に含まれるイベントとして、ある条件が正常であることを定義してもよい。この汎用ルールに基づいて、展開ルールを生成する際には構成情報テーブル１１８１０からトポロジ情報が取得される。

図９は、実施例１に係る汎用プランテーブルの一例の構成図である。

汎用プランテーブル１１９３０は、計算機システムにおいて実行可能なプランの一覧を示す。汎用プランテーブル１１９３０は、汎用プランＩＤ１１９３１、及びプラン１１９３２のフィールドを含む。汎用プランＩＤ１１９３１には、汎用プランの識別子である汎用プランＩＤが格納される。プラン１１９３２には、計算機システムにおいて実行可能なプランを示す情報が格納される。プランとしては、例えば、ホストのリブート、スイッチの設定変更、ストレージ装置２００００のボリュームマイグレーションやＶＭ移動等がある。なお、プランは図９に挙げられたものに限られない。

図１０は、実施例１に係るルール・プラン対応テーブルの一例の構成図である。

ルール・プラン対応テーブル１１９４０は、汎用ルールと、その汎用ルールを適用して障害の原因を特定した場合に実施可能なプランのリストと、各プランを実行した場合に未解決状態のまま残るイベント（以下「未解決イベント」という）との対応関係を示す。ルール・プラン対応テーブル１１９４０は、汎用ルールＩＤ１１９４１、汎用プランＩＤ１１９４２、及び未解決イベントＩＤ１１９４３のフィールドを含む。汎用ルールＩＤ１１９４１には、汎用ルールの識別子である汎用ルールＩＤが格納される。汎用ルールＩＤ１１９４１に格納される汎用ルールＩＤは、汎用ルールテーブル１１９２０の汎用ルールＩＤ１１９２３に格納される汎用ルールＩＤに対応している。汎用プランＩＤ１１９４２には、汎用プランの識別子である汎用プランＩＤが格納される。汎用プランＩＤ１１９４２に格納される汎用プランＩＤは、汎用プランテーブル１１９３０の汎用プランＩＤ１１９３１に格納される汎用プランＩＤに対応している。未解決イベントＩＤ１１９４３には、各プランを実行した場合に未解決状態のまま残るイベント（未解決イベント）の識別子である未解決イベントＩＤが格納される。未解決イベントＩＤは、汎用ルールテーブル１１９２０のイベントＩＤ１１９２５に格納される条件イベントの識別子（イベントＩＤ）に対応している。未解決イベントＩＤ１１９４３には、例えば、未解決イベントが存在しない場合に「ＮＯＮＥ」が格納され、条件イベントのすべてが未解決イベントとして残る場合に「ＡＬＬ」が格納される。

図１１は、実施例１に係る展開ルールテーブルの一例の構成図である。

ルール・プラン情報リポジトリ１１９００には、１以上の展開ルールテーブル１１９５０が格納される。本実施例では、１つの展開ルールテーブル１１９５０によって、１つの展開ルールが規定される。展開ルールは、汎用ルールを計算機システムの実構成に依存する形式に展開したデータである。図１１に示す展開ルールは、図８に示す汎用ルールにおける装置種別１１９２６及び装置部位種別１１９２７の各値を、構成情報テーブル１１８１０で定義されている特定の装置の識別子（装置ＩＤ）及び特定のデバイスの識別子（デバイスＩＤ）に置き換えることによって生成される。

展開ルールテーブル１１９５０は、条件部１１９５１、結論部１１９５２、展開ルールＩＤ１１９５３、及び展開前汎用ルールＩＤ１１９５４のフィールドを含む。

条件部１１９５１には、“ＩＦ−ＴＨＥＮ”形式で記載した展開ルールのＩＦ部に相当する観測事象、すなわち、１以上の条件イベントのそれぞれを示すデータが格納される。条件部１１９５１は、イベントＩＤ１１９５５、装置ＩＤ１１９５６、装置部位ＩＤ１１９５７、メトリック１１９５８、及びステータス１１９５９のフィールドを含む。結論部１１９５２には、“ＩＦ−ＴＨＥＮ”形式で記載した展開ルールのＴＨＥＮ部に相当する原因事象、すなわち、結論イベントを示すデータが格納される。結論部１１９５２は、装置ＩＤ１１９５６、装置部位ＩＤ１１９５７、メトリック１１９５８、及びステータス１１９５９のフィールドを含む。展開ルールＩＤ１１９５３には、展開ルールの識別子である展開ルールＩＤが格納される。展開前汎用ルールＩＤ１１９５４には、展開ルールの基となった汎用ルールの汎用ルールＩＤが格納される。イベントＩＤ１１９５５には、“ＩＦ−ＴＨＥＮ”形式で記載した展開ルールのＩＦ部に相当する観測事象に含まれる条件イベントを一意に識別する識別子が格納される。装置ＩＤ１１９５６には、条件イベント又は結論イベントの発生する装置のＩＤ（装置ＩＤ）が格納される。装置部位ＩＤ１１９５７には、条件イベント又は結論イベントが発生するデバイスのＩＤ（デバイスＩＤ）が格納される。メトリック１１９５８には、ＣＰＵ使用率、記憶装置に対するＩＯＰＳ、リクエストに対するレスポンスの時間等の、性能情報の種類を示す情報が格納される。なお、メトリック１１９５８として、性能情報テーブル１１８２０のメトリック１１８２３に設定される性能情報と同様に、他の性能情報を用いてもよい。ステータス１１９５９には、装置内のデバイスのイベント発生時の状態を示すデータが格納される。

展開ルールは、計算機システムの実構成（例えば、構成情報テーブル１１８１０が示す接続関係等）を考慮して、条件イベント及び結論イベントに関係する装置の種別及びデバイスの種別を、計算機システムの実構成における特定の装置及び特定のデバイスに具体化することで生成される。

例えば、図１１に例示した展開ルールＩＤが「ＥｘＲｕｌｅ１−１」である展開ルールは、図８に示す汎用ルール「Ｒｕｌｅ１」における装置種別１１９２６及び装置部位種別１１９２７の各値を、構成情報テーブル１１８１０で定義されている特定の装置（物理サーバＡ、ストレージ装置Ａ）の識別子及び特定のデバイス（ドライブ「／ｖａｒ」、論理ボリューム「ＬＶ１」、ディスクプール「ＰＯＯＬ１」）の識別子に置き換えることによって生成される。

図１１の展開ルールテーブル１１９５０が示す展開ルール「ＥｘＲｕｌｅ１−１」から分かるように、展開ルール「ＥｘＲｕｌｅ１−１」は、汎用ルール「Ｒｕｌｅ１」を基に展開され、観測事象として、物理サーバＡの論理ボリューム「／ｖａｒ」におけるレスポンスタイムの閾値異常と、ストレージ装置Ａの論理ボリューム「ＬＶ２」におけるレスポンスタイムの閾値異常と、ストレージ装置Ａのディスクプール「ＰＯＯＬ１」におけるレスポンスタイムの閾値異常とを検知したときに、ストレージ装置Ａのディスクプール「ＰＯＯＬ１」におけるレスポンスタイムのボトルネックが原因と結論付けられることを示している。

図１２Ａは、実施例１に係る展開プランテーブルの第１の構成図である。図１２Ｂは、実施例１に係る展開プランテーブルの第２の構成図である。

ルール・プラン情報リポジトリ１１９００には、１以上の展開プランテーブル１１９６０が格納される。本実施例では、１つの展開プランテーブル１１９６０によって、１以上の展開プランが規定される。展開プランは、汎用プランを計算機システムの実構成に依存する形式に展開した情報である。展開プランテーブル１１９６０は、プラン生成プログラム１１１００によって、汎用プランテーブル１１９３０、展開ルールテーブル１１９５０、構成情報テーブル１１８１０、及び性能情報テーブル１１８２０に基づいて生成される。

展開プランテーブル１１９６０は、プラン詳細１１９６１、汎用プランＩＤ１１９６２、及び展開ルールＩＤ１１９６Ａのフィールドを含む。汎用プランＩＤ１１９６２には、展開プランの基となった汎用プランの汎用プランＩＤが格納される。展開ルールＩＤ１１９６Ａには、展開されたプランが、どの障害原因に対するプランなのかを識別するための情報として、展開プランに対応する展開ルールの展開ルールＩＤが格納される。

プラン詳細１１９６１には、展開された１以上の展開プランのそれぞれについての具体的な処理内容及び展開プラン実行後の状態情報が格納される。プラン詳細１１９６１は、展開プランＩＤ１１９６３、プラン対象１１９６４、及びリスク箇所１１９６９のフィールドを含む。展開プランＩＤ１１９６３には、展開プランの識別子である展開プランＩＤが格納される。リスク箇所１１９６９には、プラン実行後にも潜在的に残されたままになる問題個所（以下「リスク箇所」という）を示すデータが格納される。

プラン対象１１９６４には、例えば、プランに関係する構成要素（デバイス）を示す情報、プラン実行後の情報等が格納される。ここで、プラン実行後の情報には、プランに関係するデバイスに関する、プラン実行後の性能値の予測値が含まれる。プラン実行後の性能値の予測値は、例えば、プラン生成プログラム１１１００が、性能情報テーブル１１８２０を参照して、プラン実行後の状況をシミュレートすることによって算出される。プラン対象１１９６４に含まれるフィールドは、プランの内容によって異なる。

図１２Ａの展開プランテーブル１１９６０によって規定される展開プランは、汎用プラン「Ｐｌａｎ１」に基づく展開プラン、すなわちボリュームマイグレーションに関する展開プランである。ボリュームマイグレーションに関する展開プランの場合、プラン対象１１９６４は、例えば、移動対象ボリューム１１９６５、移動元プール１１９６６、及び移動先プール１１９６７のフィールドを含む。移動対象ボリューム１１９６５は、ボリュームマイグレーションの対象となる論理ボリューム２２１００（以下「移動対象ボリューム」という）の識別子が格納されるボリュームＩＤ１１９６５Ａと、ボリュームマイグレーション実行後の、移動対象ボリュームに対するＩ／Ｏのレスポンスタイムの予測値が格納されるＩ／Ｏ ＲｅｓｐｏｎｓｅＴｉｍｅ予測１１９６５Ｂとを含む。移動元プール１１９６６は、移動対象ボリュームが属するディスクプール２２２００（すなわち、移動元のディスクプール２２２００であり、以下「移動元プール」という）の識別子が格納されるプールＩＤ１１９６６Ａと、ボリュームマイグレーション実行後の、移動元プールに対するＩ／Ｏのレスポンスタイムの予測値が格納されるＩ／Ｏ ＲｅｓｐｏｎｓｅＴｉｍｅ予測１１９６６Ｂとを含む。移動先プール１１９６７は、移動対象ボリュームの移動先となるディスクプール２２２００（以下「移動先プール」という）の識別子が格納されるプールＩＤ１１９６７Ａと、ボリュームマイグレーション実行後の、移動先プールに対するＩ／Ｏのレスポンスタイムの予測値が格納されるＩ／Ｏ ＲｅｓｐｏｎｓｅＴｉｍｅ予測１１９６７Ｂとを含む。

ボリュームＩＤ１１９６５Ａ、プールＩＤ１１９６６Ａ、及びプールＩＤ１１９６７Ａの情報は、プラン生成プログラム１１１００が、構成情報テーブル１１８１０から情報を取得し、格納する。また、各Ｉ／Ｏ ＲｅｓｐｏｎｓｅＴｉｍｅ予測１１９６５Ｂ、１１９６６Ｂ、及び１１９６７Ｂに格納される値の算出方法としては、任意の方法を採用してもよい。例えば、各Ｉ／Ｏ ＲｅｓｐｏｎｓｅＴｉｍｅ予測１１９６５Ｂ、１１９６６Ｂ、及び１１９６７Ｂの値を、例えば、プラン生成プログラム１１１００が、性能情報テーブル１１８２０から、移動対象ボリューム、移動元プール、及び移動先プールの単位時間当たりのＩ／Ｏ量を取得し、移動対象ボリュームの単位時間当たりのＩ／Ｏ量の値を、移動元プールの単位時間当たりのＩ／Ｏ量から減算し、移動先プールの単位時間当たりのＩ／Ｏ量に加算して、ボリュームマイグレーション実行後の移動元プール及び移動先プールのＩ／Ｏ量を予測し、その逆数を取ることで得られる値（Ｉ／Ｏのレスポンスタイム）としてもよい。

図１２Ｂの展開プランテーブル１１９６０によって規定される展開プランは、汎用プラン「Ｐｌａｎ５」に基づく展開プラン、すなわちプールへのディスク追加に関する展開プランである。プールへのディスク追加に関する展開プランの場合、プラン対象１１９６４は、例えば、ディスクの追加先となるディスクプール２２２００（以下「追加対象プール」という）の識別子が格納されるプールＩＤ１１９６８Ａと、追加されるディスクの識別子が格納される追加ディスク１１９６８Ｂと、ディスク追加後の、追加対象プールに対するＩ／Ｏのレスポンスタイムの予測値が格納されるＩ／Ｏ ＲｅｓｐｏｎｓｅＴｉｍｅ予測１１９６８Ｃとのフィールドを含む。

プールＩＤ１１９６８Ａ、及び追加ディスク１１９６８Ｂの情報は、プラン生成プログラム１１１００が、構成情報テーブル１１８１０から情報を取得し、格納する。また、Ｉ／Ｏ ＲｅｓｐｏｎｓｅＴｉｍｅ予測１１９６８Ｃの値（追加対象プールに対するＩ／Ｏのレスポンスタイムの予測値）の算出方法としては、任意の方法を採用してもよい。例えば、プラン生成プログラム１１１００が、追加対象プールの単位時間当たりのＩ／Ｏ量の値、追加対象プールの容量の値、及び追加されるディスクの容量の値を性能情報テーブル１１８２０から取得し、容量値に比例して単位時間当たりのＩ／Ｏ量が分散されるとして、ディスク追加前における追加対象プールのＩ／Ｏのレスポンスタイムに、ディスク追加前の追加対象プールの容量をディスク追加後の追加対象プールの容量で除算した値を乗算することにより、ディスク追加後における追加対象プールのＩ／Ｏのレスポンスタイムを算出してもよい。図１２Ｂの例では、プランの詳細１１９６１の内容として、性能情報が格納されている例を記載したが、プランに関するコスト情報やプランを実行した際における障害によるシステムのダウンタイム時間情報等が格納されてもよい。

また、図１２では、ボリュームマイグレーションに関する展開プラン及びプールへのディスク追加に関する展開プランの例を記載しているが、汎用プランテーブル１１９３０に含まれるその他の汎用プランの各汎用プランに対応する展開プランも同様に生成される。その他の汎用プランを展開プランに展開する場合においても、プラン生成プログラム１１１００が、例えば、構成情報テーブル１１８１０を参照し、処理実行後の構成情報の候補を列挙し、性能情報テーブル１１８２０を参照し、性能情報、容量情報、コスト情報、ダウンタイム情報等の、プラン実行後の状態情報をシミュレートすることによって、プランに関係するデバイスに関する、プラン実行後の性能値の予測値を計算する。

図１３は、実施例１に係る解析結果管理テーブルの一例の構成図である。

解析結果管理テーブル１１９７０は、原因装置ＩＤ１１９７１、原因部位ＩＤ１１９７２、メトリック１１９７３、確信度１１９７４、展開ルールＩＤ１１９７５、及び受信イベントＩＤ１１９７６のフィールドを含む。原因装置ＩＤ１１９７１には、障害原因解析処理において障害の原因と判断されたイベントに関係する装置の識別子（装置ＩＤ）が格納される。原因部位ＩＤ１１９７２には、障害の原因と判断されたイベントに関係するデバイスの識別子（デバイスＩＤ）が格納される。メトリック１１９７３には、閾値異常を検知した、ＣＰＵ使用率、リクエストに対するレスポンスの時間等の、性能情報の種類を示す情報が格納される。すなわち、メトリック１１９７３には、障害の原因と判断されたイベントに関係する性能情報の種類を示すデータが格納される。確信度１１９７４には、障害の原因と判断されたイベントが根本原因であることの確からしさを示す値（確信度）が格納される。本実施例では、確信度としては、例えば、条件イベントの発生割合となっている。展開ルールＩＤ１１９７５には、イベントを障害の原因と判断した根拠となる展開ルールの展開ルールＩＤが格納される。受信イベントＩＤ１１９７６には、条件イベントのうちの実際に発生したイベントのイベントＩＤが格納される。

例えば、図１３の上から１つ目のエントリは、展開ルール「ＥｘＲｕｌｅ１−１」に基づき、管理サーバ１００００が、ストレージ装置Ａのディスクプール「ＰＯＯＬ１」におけるレスポンスタイムの閾値異常を障害原因として判断したこと、イベントＩＤが「ＥＶ２」、「ＥＶ３」、「ＥＶ５」で示されるイベントが発生したことが判断の根拠とされたこと、及び、確信度すなわち条件イベントの発生割合が３／３であることを示している。このエントリは、例えば、ディスクプール「ＰＯＯＬ１」を構成するディスクの性能が遅くなり、ディスクプール「ＰＯＯＬ１」の性能が劣化し、論理ボリューム「ＬＶ２」の性能も遅くなっていることが想定される場合において、物理サーバＡのドライブ「/ｏｐｔ」や、ストレージ装置Ａの論理ボリューム「ＬＶ１」に対するＩ／Ｏの送受信が無いため、論理ボリューム「ＬＶ１」やドライブ「/ｏｐｔ」からイベントが上がってきていないケースを示している。

次に、管理サーバ１００００が実行する各処理について説明する。まず、管理サーバ１００００が実行する構成情報取得処理を説明する。構成情報取得処理は、管理サーバ１００００のプロセッサ１５０００がメモリ１１０００上に展開された構成設定管理プログラム１１６００を実行することによって実行される。まず、構成設定管理プログラム１１６００は、ＳＡＮ４００００に接続された各装置の情報を収集するプログラム（本実施例では、ストレージ装置２００００の構成性能情報収集プログラム２１２００及び物理サーバ３００００の構成性能情報収集プログラム３１１００）と通信し、各装置が保持する構成情報を取得する。

ここで、管理サーバ１００００は、物理サーバ３００００と、物理サーバ３００００上のドライブと、サーバデータＩ／Ｆと、ストレージ装置２００００と、ストレージデータＩ／Ｆと、物理サーバ３００００がアクセスする論理ボリューム２２１００と、論理ボリューム２２１００が属するディスクプール２２２００との接続関係を、例えば、ＳＣＳＩ（Small Computer System Interface）のＩｎｑｕｉｒｙ（インクアイアリ）コマンドを利用して取得してもよい。また、物理サーバ３００００がストレージ装置２００００にＳＣＳＩのＩｎｑｕｉｒｙコマンド発行することより、物理サーバ３００００がストレージ装置２００００から構成情報を取得してもよい。物理サーバ３００００の構成情報収集プログラム３１１００は、物理サーバ３００００に関する構成情報を、例えばＯＳに依頼する等、どのような方法によって取得してもよい。また、ストレージ装置２００００上の構成情報収集プログラム２１２００は、ストレージ装置２００００に関する構成情報を、例えばメモリ２１０００から取得する等、どのような方法によって取得してもよい。続いて、構成設定管理プログラム１１６００は、取得した構成情報を構成情報テーブル１１８１０に格納し、構成情報取得処理を終了する。

次に、管理サーバ１００００が実行する性能情報収集処理を説明する。性能情報収集処理は、管理サーバ１００００のプロセッサ１５０００が、メモリ１１０００上に展開された性能情報収集プログラム１１７００を実行することによって実行される。まず、性能情報収集プログラム１１７００は、ＳＡＮ４００００に接続された各装置の情報を収集するプログラム（本実施例では、ストレージ装置２００００の構成性能情報収集プログラム２１２００及び物理サーバ３００００の構成性能情報収集プログラム３１１００）と通信し、各装置が保持する性能情報を取得する。

ここで、管理サーバ１００００は、性能情報テーブル１１８２０に登録される各データ、すなわち、装置ＩＤ１１８２１、デバイスＩＤ１１８２２、メトリック１１８２３、機器ＯＳ１１８２４、性能値１１８２５、アラート実行閾値１１８２６、閾値種別１１８２７、及びＳｔａｔｕｓ１１８２８の各データを、例えば、ＳＣＳＩのＩｎｑｕｉｒｙコマンドを利用して取得してもよい。また、物理サーバ３００００がストレージ装置２００００にＳＣＳＩのＩｎｑｕｉｒｙコマンド発行することより、物理サーバ３００００がストレージ装置２００００から性能情報を取得してもよい。物理サーバ３００００の性能情報収集プログラム１１７００は、物理サーバ３００００に関する性能情報を、例えばＯＳに依頼する等、どのような方法によって取得してもよい。また、ストレージ装置２００００上の構成性能情報収集プログラム２１２００は、ストレージ装置２００００に関する性能情報を、例えばメモリ２１０００から取得する等、どのような方法によって取得してもよい。続いて、性能情報収集プログラム１１７００は、取得した性能情報を性能情報テーブル１１８２０に格納し、性能情報収集処理を終了する。

図１４は、実施例１に係るイベント解析処理のフローチャートである。

イベント解析処理は、管理サーバ１００００のプロセッサ１５０００がメモリ１１０００上に展開されたイベント解析処理プログラム１１４００を実行することによって、実行される。

まず、イベント解析処理プログラム１１４００は、性能情報テーブル１１８２０を参照し、各デバイスの性能値及びアラート実行閾値を取得する（ステップ１００１）。次に、イベント解析処理プログラム１１４００は、取得した各性能値に対し、以下のステップ１００２〜ステップ１００４の処理を実施する。

イベント解析処理プログラム１１４００は、処理対象の性能値が、処理対象の性能値に対応するアラート実行閾値を超過しているか否かを確認し、その結果に基づいて、性能情報テーブル１１８２０のＳｔａｔｕｓ１１８２８の値を更新する（ステップ１００２）。具体的には、イベント解析処理プログラム１１４００は、アラート実行閾値を超過している場合は、Ｓｔａｔｕｓ１１８２８に「閾値異常」を格納し、アラート実行閾値を超過していない場合は、Ｓｔａｔｕｓ１１８２８に「正常」を格納する。

次に、イベント解析処理プログラム１１４００は、ステップ１００２の更新前後でＳｔａｔｕｓ１１８２８の値に変更があったか否かを判定し（ステップ１００３）、変更があった場合（ステップ１００３：Ｙｅｓ）は、処理対象の性能値がアラート実行閾値を超過していることを示すイベントに関するエントリを、イベント管理テーブル１１９１０に登録し（ステップ１００４）、次のステップに進む。この際、エントリの発生日時１１９１８には、性能情報収集プログラム１１７００が、処理対象の性能値を収集した日時が格納される。一方、Ｓｔａｔｕｓ１１８２８の値に変更がなかった場合（ステップ１００３：Ｎｏ）は、ステップ１００４を実行せずに次のステップに進む。

すべての性能値に対して処理（ステップ１００２〜１００４）が完了した後、イベント解析処理プログラム１１４００は、イベント管理テーブル１１９１０に新規に登録された、イベントに関するエントリがあるか否かを判定し（ステップ１００５）、新規に登録された、イベントに関するエントリがある場合（ステップ１００５：Ｙｅｓ）は、ルール展開処理（図１５参照）の実行をルール展開プログラム１１５００に指示し（ステップ１００６）、イベント解析処理を終了する。一方、新規に登録された、イベントに関するエントリがない場合（ステップ１００５：Ｎｏ）は、イベント解析処理プログラム１１４００は、イベント解析処理を終了する。

ここで、本実施例では、イベント解析処理プログラム１１４００は、性能収集プログラム１１７００が取得した性能情報を基に、イベント管理テーブル１１９１０へのイベントに関するエントリの登録を実施したが、ＳＮＭＰ（Simple Network Management Protocol）トラップ等の装置からの通知情報を利用して、イベント管理テーブル１１９１０の情報の更新を行ってもよい。

図１５は、実施例１に係るルール展開処理のフローチャートである。

ルール展開処理は、管理サーバ１００００のプロセッサ１５０００がメモリ１１０００上に展開されたルール展開プログラム１１５００を実行することによって、実行される。

まず、ルール展開プログラム１１５００は、イベント管理テーブル１１９１０から、新規に登録されたイベントに関するエントリ（イベントエントリ）を取得し、取得したイベントエントリの解析済みフラグ１１９１７を「Ｙｅｓ」に更新する（ステップ２００１）。次に、ルール展開プログラム１１５００は、ルール・プラン情報リポジトリ１１９００に格納されている１以上の汎用ルールテーブル１１９２０が示す１以上の汎用ルールを取得する（ステップ２００２）。ルール展開プログラム１１５００は、取得した汎用ルールのそれぞれに対し、以下のステップ２００４〜ステップ２０１０の処理を実施する（ステップ２００３）。また、ルール展開プログラム１１５００は、ステップ２００１で取得した各イベントエントリに対し、以下のステップ２００５〜ステップ２０１０の処理を実施する。

ルール展開プログラム１１５００は、処理対象のイベントエントリが示すイベント（処理対象のイベント）が、処理対象の汎用ルールの条件イベントのいずれかとマッチするか否かを判定する（ステップ２００５）。例えば、ルール展開プログラム１１５００は、処理対象のイベントに関係する装置及びデバイスが、条件イベントに関係する装置及びデバイスの種別に対応しており、且つ、処理対象のイベントの種類が、条件イベントの種類と一致する場合に、処理対象のイベントと条件イベントとがマッチすると判定する。

ステップ２００５にて、マッチすると判定されていない場合（ステップ２００５：Ｎｏ）、ルール展開プログラム１１５００は、次のイベントエントリを処理対象として処理（ステップ２００４〜２０１０）を実行する。一方、ステップ２００５にて、マッチすると判定された場合（ステップ２００５：Ｙｅｓ）、ルール展開プログラム１１５００は、処理対象のイベントに関係する装置及びデバイスと、処理対象の汎用ルールに示された関連をもつ装置及びデバイスの識別子を構成情報テーブル１１８１０から取得する（ステップ２００６）。次に、ルール展開プログラム１１５００は、関連を持つ組み合わせ毎に、処理対象の汎用ルールに基づく展開ルールを作成する（ステップ２００７）。

例えば、イベント管理テーブル１１９１０のＥＶ５が処理対象のイベントとされており、汎用ルール「Ｒｕｌｅ１」が処理対象の汎用ルールとされている場合、処理対象のイベントは、汎用ルール「Ｒｕｌｅ１」の条件イベント１（イベントＩＤ１１９２５が「１」の条件イベント）とマッチする。従って、ルール展開プログラム１１５００は、処理対象のイベントの発生箇所である物理サーバＡのドライブ「／ｖａｒ」と、汎用ルール「Ｒｕｌｅ１」に記載の関係を持つ（部位間の接続関係が存在する）装置及びデバイスであるストレージ装置２００００の論理ボリューム２２１００とディスクプール２２２００とを全て列挙する。そして、ルール展開プログラム１１５００は、物理サーバＡのドライブ「／ｖａｒ」と、ストレージ装置２００００の論理ボリューム２２１００と、ストレージ装置２００００のディスクプール２２２００との組み合わせに対応する展開ルールを作成する。

次に、ルール展開プログラム１１５００は、ルール・プラン情報リポジトリ１１９００に、作成した展開ルールと同一の展開ルールを示す展開ルールテーブル１１９５０が既に存在しているか否かを判定する（ステップ２００８）。

同一の展開ルールを示す展開ルールテーブル１１９５０が存在していない場合（ステップ２００８：Ｎｏ）、ルール展開プログラム１１５００は、作成した展開ルールを示す展開ルールテーブル１１９５０をルール・プラン情報リポジトリ１１９００に格納し、解析結果管理テーブル１１９７０に新規エントリを登録する（ステップ２００９）。一方、同一の展開ルールを示す展開ルールテーブル１１９５０が存在している場合（ステップ２００８：Ｙｅｓ）、ルール展開プログラム１１５００は、解析結果管理テーブル１１９７０の受信イベントＩＤ１１９７６に処理対象のイベントのイベントＩＤを追加し、確信度１１９７４の値を変更する（ステップ２０１０）。

汎用ルールにおける全てのエントリに対する処理（ステップ２００５〜２０１０）の完了後は、ルール展開プログラム１１５００は、次の汎用ルールを処理対象として処理（ステップ２００４〜２０１０）を実行する。そして、全ての汎用ルールに対する処理（ステップ２００４〜２０１０）の完了後、ルール展開プログラム１１５００は、解析結果管理テーブル１１９７０に新規に登録されたエントリがあるか否かを判定し（ステップ２０１１）、新規に登録されたエントリがある場合（ステップ２０１１：Ｙｅｓ）は、プラン生成プログラム１１１００に対してプラン生成処理（図１６参照）の実行を指示し（ステップ２０１２）、ルール展開処理を終了する。一方、新規に登録されたエントリがない場合（ステップ２０１１：Ｎｏ）は、ルール展開プログラム１１５００は、ルール展開処理を終了する。

図１６は、実施例１に係るプラン生成処理のフローチャートである。

プラン生成処理は、管理サーバ１００００のプロセッサ１５０００がメモリ１１０００上に展開されたプラン生成プログラム１１１００を実行することによって、実行される。

まず、プラン生成プログラム１１１００は、解析結果管理テーブル１１９７０から、新規に登録された解析結果に関するエントリ（解析結果エントリ）を取得する（ステップ３００１）。プラン生成プログラム１１１００は、取得した解析結果エントリのそれぞれに対して、以下のステップ３００３〜ステップ３００８の処理を実施する（ステップ３００２）。

プラン生成プログラム１１１００は、解析結果管理テーブル１１９７０における処理対象の解析結果エントリの展開ルールＩＤ１１９７５に格納されている展開ルールＩＤを取得する。以下、ここで取得した展開ルールＩＤを持つ展開ルールを「処理対象の展開ルール」と呼ぶ。そして、プラン生成プログラム１１１００は、処理対象の展開ルールを示す展開ルールテーブル１１９５０の展開前汎用ルールＩＤ１１９５４から、処理対象の展開ルールの基となった汎用ルールの汎用ルールＩＤを取得する（ステップ３００３）。

次に、プラン生成プログラム１１１００は、ルール・プラン対応テーブル１１９４０から、ステップ３００３で取得した汎用ルールＩＤに対応する１以上の汎用プランＩＤを取得する。また、プラン生成プログラム１１１００は、ルール・プラン対応テーブル１１９４０から、ステップ３００３で取得した汎用ルールＩＤと、取得した汎用プランＩＤとの組み合わせに対応する未解決イベントＩＤを取得する（ステップ３００４）。

次に、プラン生成プログラム１１１００は、構成情報テーブル１１８１０及び汎用プランテーブル１１９３０を参照し、ステップ３００４で取得した汎用プランＩＤを持つ汎用プランに基づく、処理対象の展開ルールに対応する展開プランを生成し、生成した展開プランを示す展開プランテーブル１１９６０をルール・プラン情報リポジトリ１１９００に格納する（ステップ３００５）。例えば、ボリュームマイグレーションの汎用プランを展開する場合、プラン生成プログラム１１１００は、移動先プールとなり得るディスクプール２２２００の全てを構成情報テーブル１１８１０を参照して特定する。例えば、プラン生成プログラム１１１００は、構成情報テーブル１１８１０に基づいて、移動対象ボリュームにアクセスしていた物理サーバ１００００がアクセスすることができる、移動元プールと異なるディスクプール２２２００を特定し、特定したディスクプール２２２００を移動先プールとする。

続いて、プラン生成プログラム１１１００は、ステップ３００５で生成した各展開プランに対して、ステップ３００７及び３００８の処理を繰り返し実行する（ステップ３００６）。プラン生成プログラム１１１００は、性能情報テーブル１１８２０を参照し、プラン実行後の状況をシミュレートすることによってプラン実行後の性能値の予測値を算出し、シミュレートの結果情報に基づいて処理対象の展開プランを示す展開プランテーブル１１９６０のプラン対象１１９６４の値を更新する（ステップ３００７）。

次に、プラン生成プログラム１１１００は、処理対象の展開プランについてのプラン実行後リスク抽出処理（図１７参照）の実行をプラン実行後リスク抽出プログラム１１２００に指示する（ステップ３００８）。この際、プラン生成プログラム１１１００は、処理対象の展開プランに対応する未解決イベント、すなわち、処理対象の展開ルールの基となった汎用ルールと、処理対象の展開プランの基となった汎用プランと、の組み合わせに対応する未解決イベント、の未解決イベントＩＤをプラン実行後リスク抽出プログラム１１２００に入力する。このプラン実行後リスク抽出処理により、処理対象の展開プランについてのリスク箇所が特定される。

プラン生成プログラム１１１００は、取得した解析結果エントリの全てに対する処理（ステップ３００３〜３００８）の完了後、プラン提示処理プログラム１１３００に対して、プラン提示処理（図１８参照）の実行を指示する（ステップ３００９）。その後、プラン生成プログラム１１１００は、プラン生成処理を終了する。

本実施例では、性能情報、特にＩ／Ｏのレスポンスタイムの予測値を取り上げ、シミュレート方法の一例を示したが、展開プランテーブル１１９６０に格納する値としては、プランの特徴を表す指標となり得る値であれば、性能値以外でもよい。管理サーバ１００００は、例えば、プラン実行にかかるコストの情報やプラン実行にかかる時間等の情報を構成情報テーブル１１８１０または性能情報テーブル１１８２０に格納しておく等して、性能値と同様にシミュレートを行ってもよい。

図１７は、実施例１に係るプラン実行後リスク抽出処理のフローチャートである。

プラン実行後リスク抽出処理は、管理サーバ１００００のプロセッサ１５０００がメモリ１１０００上に展開されたプラン実行後リスク抽出プログラム１１２００を実行することによって、実行される。

まず、プラン実行後リスク抽出プログラム１１２００は、プラン生成プログラム１１１００から受信した未解決イベントＩＤを利用して、解析結果管理テーブル１１９７０における処理対象の解析結果エントリの受信イベントＩＤ１１９７６に登録されている実際に発生した条件イベントの中から、解消できないイベントを抽出する（ステップ４００１）。ここで、解消できないイベントとは、実際に発生した条件イベントのうちの、未解決イベントＩＤが示す条件イベントに対応するイベントのことをいう。

例えば、図１６のステップ３００２において、図１３の解析結果管理テーブル１１９７０における上から１つ目のエントリ（ストレージ装置Ａのディスクプール「ＰＯＯＬ１」が障害原因であるエントリ）が処理対象の解析結果エントリとして選択されており、ステップ３００６において、展開プラン「ＥｘＰｌａｎ１−１」が処理対象の展開プランとして選択されている場合、処理対象の展開ルール、すなわち処理対象の解析結果エントリの展開ルールＩＤ１１９７５が示す展開ルールは、展開ルール「ＥｘＲｕｌｅ１−１」であり、処理対象の展開ルールの基となった汎用ルールは、汎用ルール「Ｒｕｌｅ１」である。従って、処理対象の展開プラン「ＥｘＰｌａｎ１−１」に対応する未解決イベントは、展開プラン「ＥｘＰｌａｎ１−１」の基となった汎用プラン「Ｐｌａｎ１」と汎用ルール「Ｒｕｌｅ１」との組み合わせに対応する未解決イベントであり、図１０のルール・プラン対応テーブル１１９４０から、未解決イベント「３」が取得される。この未解決イベント「３」は、汎用ルール「Ｒｕｌｅ１」の条件イベント３、すなわち、ストレージ装置２００００のディスクプール２２２００におけるレスポンスタイムの閾値異常というイベントを示している。従って、処理対象の解析結果エントリの受信イベントＩＤ１１９７６に登録されているイベント（イベント「ＥＶ２」、イベント「ＥＶ３」、及びイベント「ＥＶ５」）のうち、ストレージ装置２００００のディスクプール２２２００におけるレスポンスタイムの閾値異常というイベントに対応するイベント「ＥＶ３」が、解消できないイベントとして抽出される。

次に、プラン実行後リスク抽出プログラム１１２００は、イベント管理テーブル１１９１０、及び展開ルールテーブル１１９５０を参照し、ステップ４００１で抽出した解消できないイベントの発生箇所（発生元の装置及びデバイス）を特定する（ステップ４００２）。次に、プラン実行後リスク抽出プログラム１１２００は、構成情報テーブル１１８１０を参照し、解消できないイベントの発生個所、及び解消できないイベントの発生個所とＩ／Ｏパス上の関連を持つ箇所（装置及びデバイス）のうちのいずれか１以上をリスク箇所として抽出する（ステップ４００３）。

ステップ４００３においてリスク箇所が抽出された場合（ステップ４００４：Ｙｅｓ）、プラン実行後リスク抽出プログラム１１２００は、展開プランテーブル１１９６９における処理対象の展開プランのリスク箇所１１９６９に、抽出したリスク箇所を示すデータを格納し（ステップ４００５）、プラン実行後リスク抽出処理を終了する。一方、ステップ４００３においてリスク箇所が抽出されなかった場合（ステップ４００４：Ｎｏ）、プラン実行後リスク抽出プログラム１１２００は、プラン実行後リスク抽出処理を終了する。

本実施例では、管理者にとって最も重要である業務側の情報、すなわち、物理サーバＡのボリューム「／ｏｐｔ」の情報のみをリスク箇所として抽出したが（例えば、図１２参照）、構成情報テーブル１１８１０のエントリが示すＩ／Ｏパス上におけるその他の箇所、例えば、サーバデータＩ／Ｆ、ストレージ装置２００００の論理ボリューム等もリスク箇所として抽出してもよい。

図１８は、実施例１に係るプラン提示処理のフローチャートである。

プラン提示処理は、管理サーバ１００００のプロセッサ１５０００がメモリ１１０００上に展開されたプラン提示プログラム１１３００を実行することによって、実行される。

まず、プラン提示プログラム１１３００は、解析結果管理テーブル１１９７０から、障害原因を示す情報、すなわち、原因装置ＩＤ１１９７１、原因部位ＩＤ１１９７２、メトリック１１９７３、及び確信度１１９７４の値を取得する（ステップ５００１）。

次に、プラン提示プログラム１１３００は、解析結果管理テーブル１１９７０の各解析結果エントリに対して、以下のステップ５００２の処理を実施する。ここで、処理対象の解析結果エントリの展開ルールＩＤ１１９７５に格納されている展開ルールＩＤを持つ展開ルールを「処理対象の展開ルール」という。

プラン提示プログラム１１３００は、ルール・プラン情報リポジトリ１１９００から、処理対象の展開ルールに対応する１以上の展開プラン（障害回復における候補となるプラン）を示す１以上の展開プランテーブル１１９６０を取得する（ステップ５００２）。

全ての解析結果エントリに対する処理（ステップ５００２）の完了後、プラン提示プログラム１１３００は、ステップ５００１で取得した障害原因を示す情報及び確信度と、ステップ５００２で取得した展開プランテーブル１１９６０とに基づいて、プラン提示画面（図２０参照）を生成し、生成したプラン提示画面を出力デバイス１４０００に表示させる（ステップ５００３）。その後、プラン提示プログラム１１３００は、プラン提示処理を終了する。

図１９は、実施例１に係る効果・リスク提示処理のフローチャートである。

管理サーバ１００００のプロセッサ１５０００がメモリ１１０００上に展開されたプラン提示プログラム１１３００を実行することによって、プラン提示処理が実行され、プラン提示画面が表示される。

プラン提示プログラム１１３００は、プラン提示画面において、所望の展開プランが選択され、選択された展開プランに対するプラン詳細画面の表示要求の入力を受信すると、効果・リスク提示処理を開始する（ステップ６００１）。

まず、プラン提示プログラム１１３００は、構成情報テーブル１１８１０を参照して、リスク箇所の状態情報、性能情報、及び設定情報を取得する（ステップ６００２）。次に、プラン提示プログラム１１３００は、展開プランテーブル１１９６０、及び解析結果管理テーブル１１９７０を参照して、選択された展開プランに対応する展開ルールに含まれる条件イベントのうちのどのイベントが発生したかを示す情報と、選択された展開プランを実施した場合にどのイベントが解決するかを示す情報とを取得する（ステップ６００３）。次に、プラン提示プログラム１１３００は、選択された展開プランと関連のあるＩ／Ｏパス情報を抽出する（ステップ６００４）。

その後、プラン提示プログラム１１３００は、ステップ６００２〜ステップ６００４で取得した情報に基づいてプラン詳細画面（図２１参照）を生成し、生成したプラン詳細画面を出力デバイス１４０００に表示させる（ステップ６００５）。その後、プラン提示プログラム１１３００は、効果・リスク提示処理を終了する。

図２０は、実施例１に係るプラン提示画面の一例の構成図である。

プラン提示画面９０００は、計算機システムにおいて障害が発生した場合に、管理者がその原因を追究して対策を実施する際に参照する情報、具体的には、障害原因と、障害に対して取り得る対策プランのリストとの対応関係を示す情報を表示するための表示領域９００１と、対策プランの詳細を表示するためのプラン詳細ボタン９００２と、対策プランを実行するためのプラン実行ボタン９００３とを有する。

障害原因と障害に対する対策プランとの対応を表示する表示領域９００１には、障害原因を示す情報として、例えば、障害原因のイベントに関係する装置のＩＤ、障害原因のイベントに関係するデバイスのＩＤ、障害原因のイベントの種別、及び、障害原因についての確信度、すなわち条件イベントの総数に対する実際に発生した条件イベント数の割合が表示される。これらの値は、プラン提示プログラム１１３００が、図１８のステップ５００１において、図１３に示した解析結果管理テーブル１１９７０から取得する。

また、表示領域９００１には、障害に対するプランの情報として、例えば、候補となるプランの内容を示す情報、プラン実行にかかるコスト、プラン実行に要する時間（すなわち、障害が残り続ける時間であり、以下「ダウンタイム」という）、プラン実行後の性能情報、及び、リスク箇所を示す情報が表示される。リスク箇所を示す情報は、例えば、展開プランテーブル１１９６０のリスク箇所１１９６９に格納されているリスク箇所を示すデータ（例えば、リスク箇所の名称）、リスク箇所とされたデバイスを有する装置を示すデータ（例えば、装置の名称）等を含む。

プラン実行にかかるコスト情報については、例えば、管理サーバ１００００は、図９に示した汎用プランテーブル１１９３０において汎用プランごとにどの程度のコストがかかるかを予め保持しておき、その情報に基づいてコストを決定してもよい。例えば、汎用プラン「Ｐｌａｎ８」のストレージポート交換のプランについては、管理サーバ１００００は、ストレージポートの購入にかかる値段と、ストレージポートの交換に対応する保守員の人件費を足し合わせた金額を保持しておき、その金額をコストとして表示してもよい。また、汎用プラン「Ｐｌａｎ１」のボリュームマイグレーションのプランについては、管理サーバ１００００は、データを或る記憶デバイスから別の記憶デバイスに移行する場合にかかるビット単位のコストを保持しておき、移動するボリュームの容量に応じて図２０の「Ｃｏｓｔ（＄）」のフィールドに表示するコストを算出してもよい。

ダウンタイムについては、例えば、ボリュームマイグレーションのプランの場合、管理サーバ１００００は、移動元及び移動先のそれぞれの記憶デバイスのメディア種別とＲＡＩＤレベルとの組み合わせごとに、単位時間（例えば１秒）当たりにどの程度の容量のデータをマイグレーションできるかを示すデータをあらかじめ保持しておき、移動するボリュームの容量に応じて図２０の「Ｄｏｗｎ ｔｉｍｅ」のフィールドに表示するダウンタイムを算出してもよい。ここで、管理サーバ１００００は、実環境における利用状況に応じて、移動にかかる時間が変動することを考慮し、過去の移動履歴情報を利用して、単位時間当たりの移動可能容量を算出し、あらかじめ保持している情報に、あらかじめ保持している情報と履歴情報の平均を取るなどして補正をかけて求めてもよい。ここで、プラン実行にかかるコスト情報、及びダウンタイムについて、求め方の一例を示したが、上記方法に限定されず、他の求め方が採用されてもよい。

プラン実行後の性能情報としては、例えば、図１６に示したプラン生成処理のステップ３００７でシミュレートされ、図１２に示した展開プランテーブル１１９６０のプラン対象１１９６４に格納されたプラン実行後の性能値の予測値、例えば、及びＩ／Ｏ ＲｅｓｐｏｎｓｅＴｉｍｅ予測１１９６５Ｂ、１１９６６Ｂ、１１９６７Ｂ、１１９６８Ｃに格納された値が表示される。図２０の例では、上から１つ目のプラン（ボリュームマイグレーションのプラン）については、移動対象ボリュームに対するＩ／Ｏのレスポンスタイムの予測値が表示され、上から５つ目のプラン（プールへのディスク追加のプラン）については、追加対象プールに対するＩ／Ｏのレスポンスタイムの予測値が表示されているが、これ以外の値、例えば、上から１つ目のプラン（ボリュームマイグレーションのプラン）について、移動元プールや移動先のプールに対するＩ／Ｏのレスポンスタイムの予測値が表示されてもよいし、そのほかの性能値が表示されてもよい。また、複数の性能値の予測値が表示されてもよい。

ここで、候補となるプランの表示順序を、プラン実行にかかるコストが少ないものから順番に並べたり、プラン実行に要する時間の短いものから順番に並べたり、リスク箇所が存在しないものから順番に並べたりする等、プランの特徴に基づいて並べ替えを行えるようにしてもよい。

並べ替えの方法として、例えば、表示領域９００１における「Ｃｏｓｔ（$）」をクリックすることで、コストが少ないものから順番に並べるようにする等、どのような方法によって行われてもよい。

プラン詳細ボタン９００２は、プラン詳細画面（図２１）の表示を指示するためのボタンである。管理者が、入力装置１５０００において表示領域９００１中の所望のプランを選択し、プラン詳細ボタン９００２を押下すると、管理サーバ１００００は、図１９の効果・リスク提示処理の実行を開始し、選択されたプランの詳細情報を表示するためのプラン詳細画面（図２１）を出力装置１４０００に表示する。

プラン実行ボタン９００３は、選択されたプランの実行を指示するためのボタンであり、当該ボタンが押下されると、管理サーバ１００００は、選択されたプランに相当する機能を提供するプログラムに対して、プランの実行指示を出す。プランの実行指示を受けたプログラムは、選択されたプランを実行することとなる。ここで、プランを実行するプログラムは、例えば、管理サーバ１００００のメモリ１１０００内のプログラムであり、例えば、ボリュームマイグレーションプログラムや、ＶＭ移動プログラム等である。

なお、例えば、表示領域９００１において、プラン実行前の性能値及びプラン実行後の性能値の予測値がトレンド情報としてグラフ形式で表示されてもよい。

図２０は、プラン表示画面９０００の一例であり、プラン実行にかかるコスト、プラン実行に要する時間以外のプランの特徴を表す情報、例えば、プランに関係するリソースを利用している業務であってプラン実行時に影響が波及する可能性のある業務の一覧等が、表示領域９００１にあわせて表示されてもよく、他の表示態様が採用されてもよい。

図２１は、実施例１に係るプラン詳細画面の一例の構成図である。

プラン詳細画面９０１０は、計算機システムにおいて障害が発生した場合に、管理者がその原因を追究して対策を実施する際に参照する情報、具体的には、障害に関係する装置及びデバイス間の接続関係等を示す情報を表示する表示領域９０１１と、リスク箇所の詳細情報を表示する表示領域９０１７とを有する。表示領域９０１１は、計算機システム内の物理サーバ３００００の構成を表すサーバ領域９０１２と、スイッチの構成を表すスイッチ領域９０１３と、ストレージ装置２００００の構成を表すストレージ領域９０１４と、プラン提示画面９０００で選択されたプランの実行前の各装置及びデバイス間の接続関係及び設定関係を示す領域９０１５と、選択されたプランの実行後の各装置及びデバイス間の接続関係及び設定関係を示す領域９０１６とを有する。また、リスク箇所の詳細情報を表示する表示領域９０１７は、プラン実行後にもリスクが残り続ける箇所を表すリスク箇所９０１８と、リスク箇所を放置したままにした場合に、当該リスクの発生するタイミングを表すリスク発生タイミング９０１９とを有する。

図２１に示す例では、表示領域９０１１のサーバ領域９０１２には、物理サーバＡを表す図形９０２０と、ストレージ装置Ａを表す図形９０２１とが表示されている。また、図形９０２０内には、マウントポイントであるドライブ「／ｏｐｔ」及びドライブ「／ｖａｒ」を表す図形が表示され、図形９０２１内には、論理ボリューム「ＬＶ１」及びディスクプール「ＰＯＯＬ１」を表す図形等が表示されている。すなわち、サーバ領域９０１２は、計算機システムの接続関係及び設定関係を表現するための領域となっている。加えて、サーバ領域９０１２には、解析結果管理テーブル１１９１０で管理されている、システム内で発生した障害イベントを示すマーク９０２２が、障害イベントの発生個所、例えば、物理サーバＡのデータＩ／Ｆ「Ｓ２」上に表示されている。また、サーバ領域９０１２には、展開プランテーブル１１９６０で管理されているリスク箇所を示すマーク９０２３が、リスク発生個所、例えば、物理サーバＡのドライブ「／ｏｐｔ」上に表示されている。また、領域９０１１では、物理サーバＡ、ストレージ装置Ａ等の装置及びデバイス同士の接続関係は、それぞれを表す図形同士を接続する実線によって表現されている。

図２１に示す例では、プラン実行前の状況を示す領域９０１５は、物理サーバＡ上のドライブ「／ｏｐｔ」と、ストレージ装置Ａの論理ボリューム「ＬＶ１」と、ディスクプール「ＰＯＯＬ１」とが関連づけられ、物理サーバＡ上のドライブ「／ｖａｒ」と、ストレージ装置Ａの論理ボリューム「ＬＶ２」と、ディスクプール「ＰＯＯＬ１」とが関連づけられ、ストレージ装置Ａの論理ボリューム「ＬＶ３」と、ディスクプール「ＰＯＯＬ２」とが関連づけられていることを示している。また、プラン実行前の状況を示す領域９０１５は、物理サーバＡ上のドライブ「／ｖａｒ」と、物理サーバＡ上のデータＩ／Ｆと、ストレージ装置ＡのデータＩ／Ｆと、ストレージ装置Ａの論理ボリューム「ＬＶ２」と、ストレージ装置Ａのディスクプール「ＰＯＯＬ１」とに障害イベントが発生しており、物理サーバＡ上のドライブ「／ｏｐｔ」にリスクが存在することを示している。

プラン実行後の状況を示す領域９０１６は、ディスクプール「ＰＯＯＬ１」上に存在していた論理ボリューム「ＬＶ２」が、ＰＯＯＬ２上に存在するようになることを示しており、プラン実行後にも、ストレージ装置Ａのディスクプール「ＰＯＯＬ１」に障害イベントが残り続け、物理サーバＡ上のドライブ「／ｏｐｔ」にリスクが残り続けることを示している。

リスク詳細を示す表示領域９０１７には、リスク箇所を示すマーク９０２３のあるデバイスに関する詳細情報が表示される。図２１の例では、表示領域９０１１における物理サーバＡのドライブ「／ｏｐｔ」上にあるリスクの詳細情報が領域９０１７に表示されており、図２１に示す例では、領域９０１７は、リスク箇所が物理サーバＡのドライブ「／ｏｐｔ」であり、リスクが発生する可能性のあるタイミングは、ドライブ「／ｏｐｔ」へのＩ／Ｏが発生した時であることを表している。リスク発生タイミングは、例えば、図１９のステップ６００２において取得された情報に基づいて決定される。例えば、管理サーバ１００００は、性能情報テーブル１１８２０の性能値１１８２５の情報を取得し、物理サーバＡのドライブ「／ｏｐｔ」に関する性能値が０msecであり、Ｉ／Ｏが発生していないことを検出し、Ｉ／Ｏ発生がリスク発生の契機になり得ると判断し、リスク発生タイミング９０１９に、当該情報を格納してもよい。

ここで、表示領域９０１１及び表示領域９０１７をプラン詳細画面９０１０が有するようにしていたが、これに限定されず、例えば、表示領域９０１１のリスク箇所を示すマーク９０２３がクリックされた際に、表示領域９０１７が別画面として新規表示されるようにしてもよい。あるいは、プラン提示画面９０００の表示領域９００１のリスク箇所の情報がクリックされた際に、表示領域９０１７が別画面として新規表示されるようにしてもよい。また、表示領域９０１１の物理サーバ３００００やストレージ装置２００００等の装置またはデバイスを示す図形がクリックされた際に、プラン実行前後の当該装置またはデバイスの性能値が表示されるようにしてもよい。

実施例１によれば、障害原因と障害に対する具体的な回復プランとを関連付けて提示し、各プランの実行によって、障害原因に関連する障害イベントのうち、どれだけのイベントが解消されるかをチェックし、その結果を表示することで、プラン実行後にも潜在的に残されたままとなる問題箇所を、その理由と共にプランの詳細情報として管理者に提示することができる。これにより、管理者は、適切なプランを選択できるようになり、プラン実行後のリスクをプラン選択時に容易に把握することができる。

次に、実施例２について説明する。以下の説明では、実施例１との差異を中心に説明し、同等の構成要素や、同等の機能を持つプログラム、同等の項目を持つテーブルについては、記載を省略する。

図２２は、実施例２に係る管理サーバの一例の構成図である。

管理サーバ１００００は、実施例１と同様の構成要素を備え、メモリ１１０００の構成性能情報リポジトリ１１８００には、さらに、ＶＭ構成管理テーブル１１８３０が格納される。ＶＭ構成管理テーブル１１８３０は、ＶＭと、ＶＭを論理的に生成し稼働させるハイパーバイザ（以下「ＨＶ」とも呼ぶ）との対応関係、及びＶＭの設定情報、例えば、電源状態情報等を管理する。

図２２に示す例では、各種プログラム及びテーブルは、メモリ１１０００に格納されているが、記憶デバイス１２０００または他の記憶媒体（図示しない）に格納されていてもよい。この場合、プロセッサ１５０００は、プログラム実行時にメモリ１１０００上に対象のプログラムを読み出し、読み出したプログラムを実行する。また、ストレージ装置２００００のメモリ２１０００または物理サーバ３００００のメモリ３１０００に、前述のプログラム及び前述のテーブルが格納され、ストレージ装置２００００または物理サーバ３００００が、格納されたプログラムを実行してもよい。また、スイッチ等の他の装置が、前述のプログラム及びテーブルを格納し、格納したプログラムを実行してもよい。

図２３は、実施例２に係る物理サーバの一例の構成図である。

物理サーバ３００００は、実施例１と同様の構成要素を備え、メモリ３１０００には、さらに、ＶＭ管理プログラム３１４００が格納される。ＶＭ管理プログラム３１４００は、ＶＭの構成情報及び性能情報を管理する。また、ＶＭ管理プログラム３１４００は、ＶＭ移動等、ＶＭに関する制御を行う。

図２３に示す例では、各種プログラムは、メモリ３１０００に格納されているが、他の記憶媒体（図示しない）に格納されていてもよい。この場合、プロセッサ３３０００は、処理実行時にメモリ３１０００上に対象のプログラムを読み出し、読み出したプログラムを実行する。

図２４は、実施例２に係る物理サーバの一例の論理的な構成図である。

物理サーバ３００００は、ＶＭ７００００を論理的に生成し、生成したＶＭ７００００を稼働させるＨＶ８００００を有する。ＨＶ８００００は、一度に複数のＶＭ７００００を制御することができる。複数のＶＭ７００００のそれぞれは、スタンドアローンの物理計算機のようにアプリケーションを実行できる。

図２５は、実施例２に係るスイッチの一例の構成図である。

スイッチ６００００は、メモリ６１０００、管理Ｉ／Ｆ６２０００、プロセッサ６３０００、及びスイッチデータＩ／Ｆ６４０００を有し、これらの装置は、内部バス６５０００等の内部バス６５０００を介して接続される。スイッチ６００００は、物理サーバ３００００のデータＩ／Ｆ３２０００からストレージ２００００のデータＩ／Ｆ２６０００への通信経路を選択するための装置である。メモリ６１０００には、構成性能情報収集プログラム６１１００が格納される。構成性能情報収集プログラム６１１００は、スイッチ６００００の管理情報及び性能情報等を管理サーバ１００００との間で送受信するためのプログラムである。

図２６は、実施例２に係る構成情報テーブルの一例の構成図である。

構成情報テーブル１１８１０は、実施例１に係る構成情報テーブル１１８１０の各フィールドに加え、スイッチ情報１１８１８を含む。スイッチ情報１１８１８は、スイッチ６００００の識別子が格納されるスイッチ１１８１８Ａと、スイッチ６００００の入力データＩ／Ｆを示すデータが格納されるスイッチデータＩ／Ｆ ＩＮ１１８１８Ｂと、スイッチ６００００の出力データＩ／Ｆを示すデータが格納されるスイッチデータＩ／Ｆ ＯＵＴ１１８１８Ｃとを含む。また、スイッチ情報１１８１８は、物理サーバ１１８１１、ストレージ１１８１４等のフィールドの間に配置されているが、このフィールドの位置関係は、通信経路上の装置及びデバイスの位置関係を示している。例えば、図２６の上から２つ目のエントリは、物理サーバＡのサーバデータＩ／Ｆ「Ｓ２」と、ストレージ装置ＡのストレージデータＩ／Ｆ「Ｐ２」との間に、スイッチＢとスイッチＣとが存在することを示す。より詳しくは、物理サーバＡのサーバデータＩ／Ｆ「Ｓ２」と、スイッチＢのデータＩ／Ｆ「Ｒ１０」とが接続され、スイッチＢのデータＩ／Ｆ「Ｒ１１」とスイッチＣのデータＩ／Ｆ「Ｒ２０」とが接続され、スイッチＣのデータＩ／Ｆ「Ｒ２１」とストレージ装置ＡのストレージデータＩ／Ｆ「Ｐ２」とが接続されていることを示す。また、情報構成テーブル１１８１０では、ＶＭ７００００の構成情報も物理サーバ３００００の構成情報と同様に格納される。したがって、物理サーバ１１８１１には、ＶＭ７００００を一意に識別するための識別子が格納される。例えば、図２６の上から５つ目のエントリは、ストレージＢのディスクプール「ＰＯＯＬ３」から生成された論理ボリューム「ＬＶ１０」が、ストレージＢのストレージデータＩ／Ｆ「Ｐ３」、スイッチＡのデータＩ／Ｆ「Ｒ２」、「Ｒ１」、及びサーバデータＩ／Ｆ「Ｓ３」を介してＶＭ１に接続され、ＶＭ１上で論理ボリューム「Ｅ：」として認識されていることを示す。

図２７は、実施例２に係るＶＭ構成管理テーブルの一例の構成図である。

構成設定管理プログラム１１６００が実行されることによって、ＶＭ構成管理テーブル１１８３０にエントリが追加される。構成設定管理プログラム１１６００は、仮想サーバ１１８３１、電源状態１１８３２、物理サーバ１１８３３、及びサーバデータＩ／Ｆ１１８３４のフィールドを含む。仮想サーバ１１８３１には、ＶＭ７００００を一意に識別するための識別子が格納される。電源状態１１８３２には、ＶＭ７００００の電源状態を示すデータ、例えば「ＯＮ」、「ＯＦＦ」、または「ＳＵＳＰＥＮＤ」が格納される。物理サーバ１１８３３には、ＶＭ７００００が動作している物理サーバ３００００を一意に識別するための識別子が格納される。サーバデータＩ／Ｆ１１８３４には、物理サーバ３００００のサーバデータＩ／Ｆを一意に識別するための識別子が格納される。

図２８は、実施例２に係る性能情報テーブルの一例の構成図である。

実施例２に係る性能情報テーブル１１８２０の構成は、実施例１に係る性能情報テーブル１１８２０の構成と実質的に同じである。実施例２に係る性能情報テーブル１１８２０には、計算機システムを構成する装置またはデバイスに関する性能情報として、ＶＭ７００００の性能情報、ハイパーバイザ８００００の性能情報、及びスイッチ６００００の性能情報も格納される。ここででは、ＶＭ７００００、及びハイパーバイザ８０００も装置として扱われている。例えば、装置ＩＤ１１８２１には、ＶＭ７００００、ハイパーバイザ８００００、又はスイッチ６００００を一意に識別するための識別子が格納される。 図２９は、実施例２に係るイベント管理テーブルの一例の構成図である。

実施例２に係るイベント管理テーブル１１９１０の構成は、実施例１に係るイベント管理テーブル１１９１０の構成と実質的に同じである。実施例２に係るイベント管理テーブル１１９１０には、計算機システムを構成する装置またはデバイスで発生するイベントに関する情報として、ＶＭ７００００で発生したイベントに関する情報、ハイパーバイザ８００００で発生したイベントに関する情報、及びスイッチ６００００で発生したイベントに関する情報も格納される。

図３０Ａは、実施例２に係る汎用ルールテーブルの第１の構成図である。図３０Ｂは、実施例２に係る汎用ルールテーブルの第２の構成図である。

実施例２に係る汎用ルールテーブル１１９２０の構成は、実施例１に係る汎用ルールテーブル１１９２０の構成と実質的に同じである。実施例２では、ＶＭ７００００に関するイベント、ハイパーバイザ８００００に関するイベント、及びスイッチ６００００に関するイベントについても、汎用ルールの条件部１１９２１及び結論部１１９２２で定義される条件イベントとして採用される。

図３１は、実施例２に係るルール・プラン対応テーブルの一例の構成図である。

実施例２に係るルール・プラン対応テーブル１１９４０の構成は、実施例１に係るルール・プラン対応テーブル１１９４０の構成と実質的に同じである。実施例２では、汎用ルールとして汎用ルール「Ｒｕｌｅ３」及び「Ｒｕｌｅ４」を、汎用プランとして汎用プラン「Ｐｌａｎ１」及び「Ｐｌａｎ６」を取り上げて説明する。

図３２Ａは、実施例２に係る展開ルールテーブルの第１の構成図である。図３２Ｂは、実施例２に係る展開ルールテーブルの第２の構成図である。

実施例２に係る展開ルールテーブル１１９５０の構成は、実施例１に係る展開ルールテーブル１１９５０の構成と実質的に同じである。実施例２では、ＶＭ７００００に関するイベント、ハイパーバイザ８００００に関するイベント、及びスイッチ６００００に関するイベントについても、展開ルールの条件部１１９５１及び結論部１１９５２で定義される条件イベントとして採用される。

図３３Ａは、実施例２に係る展開プランテーブルの第１の構成図である。図３３Ｂは、実施例２に係る展開プランテーブルの第２の構成図である。図３３Ｃは、実施例２に係る展開プランテーブルの第３の構成図である。

実施例２に係る展開プランテーブル１１９６０の構成は、実施例１に係る展開プランテーブル１１９６０の構成と実質的に同じである。実施例１と同様に、プラン対象１１９６４に含まれるフィールドは、プランの内容によって異なる。

図３３Ｂまたは図３３Ｃに示す展開プランは、汎用プラン「Ｐｌａｎ６」に基づく展開プラン、すなわちＶＭ移動に関する展開プランでは、プラン対象１１９６４は、例えば、対象ＶＭ１１９６Ｂ、移動元１１９６Ｃ、及び移動先１１９６Ｄのフィールドを含む。対象ＶＭ１１９６Ｂは、ＶＭ移動の対象となるＶＭ７００００（以下「対象ＶＭ」という）の識別子が格納されるＩＤ１１９６ＢＡと、対象ＶＭの移動後の性能値が格納される性能１１９６ＢＢとのフィールドを含む。移動元１１９６Ｃは、対象ＶＭの移動元のハイパーバイザ８００００（以下「移動元ハイパーバイザ」という）の識別子が格納されるＩＤ１１９６ＣＡと、対象ＶＭが移動された後の移動元ハイパーバイザの性能値が格納される性能１１９６ＣＢとのフィールドを含む。移動先１１９６Ｄは、対象ＶＭの移動先のハイパーバイザ８００００（以下「移動先ハイパーバイザ」という）の識別子が格納されるＩＤ１１９６ＤＡと、対象ＶＭが移動された後の移動先ハイパーバイザの性能値が格納される性能１１９６ＤＢとのフィールドを含む。ＩＤ１１９６ＢＡ、ＩＤ１１９６ＣＡ、ＩＤ１１９６ＤＡに格納される識別子については、プラン生成プログラム１１１００が、構成情報テーブル１１８１０等から取得し、格納する。また、性能１１９６ＢＢ、性能１１９６ＣＢ、性能１１９６ＤＢに格納される性能情報の予測値については、値の算出において、どのような方法が採用されてもよく、例えば、プラン生成プログラム１１１００は、実施例１で示したように、ＩＯＰＳを加算しまたは減算することにより予測値を求めてもよい。ここでは、性能情報の例を記載したが、コスト情報や障害によるシステムのダウンタイム時間情報等が格納されてもよい。また、ここでは移動元、及び移動先として、単一のハイパーバイザ８００００としていたが、リソースを共有する複数のハイパーバイザ８００００の集合や、ハイパーバイザ８００００内のデータストアが、移動元、及び移動先とされてもよい。

図３４は、実施例２に係る解析結果管理テーブルの一例の構成図である。

実施例２に係る解析結果管理テーブル１１９７０の構成は、実施例１に係る解析結果管理テーブル１１９７０の構成と実質的に同じである。実施例２では、ＶＭ７００００の識別子、ハイパーバイザ８００００の識別子、スイッチ６００００の識別子、及びそれらのデバイスの識別子についても、原因装置ＩＤ１１９７１、及び原因部位ＩＤ１１９７２に格納され得る。また、ＶＭ７００００に関するイベントの識別子、ハイパーバイザ８００００に関するイベントの識別子、及びスイッチ６００００に関するイベントの識別子についても、受信イベントＩＤ１１９７６に格納され得る。

図３５は、実施例２に係るプラン提示処理のフローチャートである。

プラン提示処理は、管理サーバ１００００のプロセッサ１５０００がメモリ１１０００上に展開されたプラン提示プログラム１１３００を実行することによって、実行される。

まず、プラン提示プログラム１１３００は、解析結果管理テーブル１１９７０から、障害原因を示す情報、すなわち、原因装置ＩＤ１１９７１、原因部位ＩＤ１１９７２、メトリック１１９７３、及び確信度１１９７４の値を取得する（ステップ７００１）。

次に、プラン提示プログラム１１３００は、ルール・プラン情報リポジトリ１１９００に格納されている１以上の展開プランテーブル１１９６０が示す１以上の展開プランのそれぞれに対して、以下のステップ７００２〜７００５の処理を実行する。プラン提示プログラム１１３００は、ルール・プラン情報リポジトリ１１９００に格納されている１以上の展開プランテーブル１１９６０が示す１以上の展開プラン内に、処理対象の展開プランと、展開ルールＩＤ１１９６Ａの値が異なり、すなわち、対応する展開ルールが異なり、且つ、同一の処理内容を持つ展開プラン（以下「第１の集約対象プラン」という）が存在するか否かを判定する（ステップ７００２）。

第１の集約対象プランが存在しない場合（ステップ７００２：Ｎｏ）、プラン提示プログラム１１３００は、処理をステップ７００４に進める。一方、第１の集約対象プランが存在する場合（ステップ７００２：Ｙｅｓ）、プラン提示プログラム１１３００は、展開プランテーブル１１９６０から第１の集約対象プランを削除し、処理対象の展開プランを含む展開プランテーブル１１９６０の展開ルールＩＤ１１９６Ａの値を更新し（ステップ７００３）、処理をステップ７００４に進める。

例えば、図３３Ｂ、図３３Ｃの例では、展開プラン「ＥｘＰｌａｎ６−１」と展開プラン「ＥｘＰｌａｎ６−３」とが、展開プラン「ＥｘＰｌａｎ６−２」と展開プラン「ＥｘＰｌａｎ６−４」とが、それぞれ、対応する展開ルールが異なり、且つ、同一の処理内容を持つ展開プランとなっている。従って、処理対象の展開プランが展開プラン「ＥｘＰｌａｎ６−１」である場合、プラン提示プログラム１１３００は、ステップ７００２において展開プラン「ＥｘＰｌａｎ６−３」を第１の集約対象プランと特定し、ステップ７００３において、展開プラン「ＥｘＰｌａｎ６−３」を展開プランテーブル１１９６０から削除し、展開プラン「ＥｘＰｌａｎ６−１」を含む展開プランテーブル１１９６０の展開ルールＩＤ１１９６Ａの値を、展開ルール「ＥｘＲｕｌｅ３−１」及び展開ルール「ＥｘＲｕｌｅ４−１」であることを示すデータ、例えば「ＥｘＲｕｌｅ３−１、ＥｘＲｕｌｅ４−１」に更新する。また、処理対象の展開プランが展開プラン「ＥｘＰｌａｎ６−２」である場合、プラン提示プログラム１１３００は、ステップ７００２において展開プラン「ＥｘＰｌａｎ６−４」を第１の集約対象プランと特定し、ステップ７００３において、展開プラン「ＥｘＰｌａｎ６−４」を展開プランテーブル１１９６０から削除し、展開プラン「ＥｘＰｌａｎ６−２」を含む展開プランテーブル１１９６０の展開ルールＩＤ１１９６Ａの値を、「ＥｘＲｕｌｅ３−１、ＥｘＲｕｌｅ４−１」に更新する。なお、ここでは、既存の展開プランテーブル１１９６０の展開ルールＩＤ１１９６Ａの値を更新するようにしたが、展開ルールＩＤ１１９６Ａに「ＥｘＲｕｌｅ３、ＥｘＲｕｌｅ４」が格納された新規の展開プランテーブル１１９６０が作成されてもよい。

ステップ７００４では、プラン提示プログラム１１３００は、ルール・プラン情報リポジトリ１１９００に格納されている１以上の展開プランテーブル１１９６０が示す１以上の展開プラン内に、処理対象の展開プランと、汎用プランＩＤ１１９６２が同一であり、すなわち、基となる汎用プランが同一であり、且つ、類似した性能情報を持ち、且つ、同一のリスクを持つ展開プラン（以下「第２の集約対象プラン」という）が存在するか否かを判定する。

第２の集約対象プランが存在しない場合（ステップ７００４：Ｎｏ）、プラン提示プログラム１１３００は、ステップ７００５を実行せずに次の処理へ処理を進める。一方、第２の集約対象プランが存在する場合（ステップ７００４：Ｙｅｓ）、プラン提示プログラム１１３００は、処理対象の展開プラン及び１以上の第２の集約対象プランの中で、プラン実行後の性能値の予測値が最も良い展開プラン（以下「最良プラン」という）を特定する。そして、プラン提示プログラム１１３００は、展開プランテーブル１１９６０から、処理対象の展開プラン及び１以上の第２の集約対象プランのうちの最良プランではない展開プランを削除し、展開プランテーブル１１９６０の展開ルールＩＤ１１９６Ａの値を更新する（ステップ７００５）。

例えば、図３３Ａ及び図３３Ｂの例では、基となる汎用プランが同一であり、且つ、類似した性能情報を持ち、且つ、同一のリスクを持つ展開プランである展開プラン「ＥｘＰｌａｎ１−１」、展開プラン「ＥｘＰｌａｎ１−２」、及び展開プラン「ＥｘＰｌａｎ１−３」のうち、展開プラン「ＥｘＰｌａｎ１−１」が、移動対象ボリュームの性能が最も良くなる最良プランである。従って、最良プラン「ＥｘＰｌａｎ１−１」のみが残され、それ以外の展開プラン「ＥｘＰｌａｎ１−２」、及び展開プラン「ＥｘＰｌａｎ１−３」は削除される。また、基となる汎用プランが同一であり、且つ、類似した性能情報を持ち、且つ、同一のリスクを持つ展開プランである展開プラン「ＥｘＰｌａｎ６−１」、及び展開プラン「ＥｘＰｌａｎ６−２」のうち、展開プラン「ＥｘＰｌａｎ６−１」が、対象ＶＭの性能が最も良くなる最良プランである。従って、最良プラン「ＥｘＰｌａｎ６−１」のみが残され、それ以外の展開プラン「ＥｘＰｌａｎ６−２」は削除される。

ここで、性能情報が類似していると判断する範囲は、例えば、Ｉ／Ｏのレスポンスタイプが±１ｍｓｃ以下の範囲内にあるなど、固定的にあらかじめ設定されていてもよいし、入力デバイス１３０００を通して、管理者によって設定されてもよい。

なお、ステップ７００５において、プラン提示プログラム１１３００は、最良プラン、例えば、Ｉ／Ｏのレスポンスタイムが最も速い等の１つの展開プランのみを残し、それ以外の展開プランを削除することとしたが、プラン実行後の性能値の予測値が良い複数の展開プランを残してもよい。集約後に残される展開プランの個数については、例えば、あらかじめ残す個数が固定的に決められていてもよいし、入力デバイス１３０００を通して、管理者によって設定されてもよい。また、出力画面内に全ての展開プランが表示可能となるように、集約後の展開プランの個数が決定されてもよい。また、本処理の目的は、類似する展開プランが多数表示されることにより、管理者によるプラン選択作業が煩雑になることを避けることである。例えば、展開プランを削除するのではなく、プラン実行後の性能値の良い展開プランのみを表示するようにし、そのほかの展開プランを表示しないようにしておき、所定のボタンがクリックされることで表示または非表示が切り替えられるようにする等の方法が採用されてもよい。

全ての展開プランに対する処理（ステップ７００２〜７００５）の完了後、プラン提示プログラム１１３００は、ステップ７００１で取得した障害原因を示す情報及び確信度と、ルール・プラン情報リポジトリ１１９００に格納されている展開プランテーブル１１９６０とに基づいて、プラン提示画面９０００（図３６参照）を生成し、生成したプラン提示画面９０００を出力デバイス１４０００に表示させる（ステップ７００６）。その後、プラン提示プログラム１１３００は、プラン提示処理を終了する。

図３６は、実施例２に係るプラン提示画面の一例の構成図である。

実施例２に係るプラン提示画面９０００の構成は、実施例１に係るプラン提示画面９０００の構成と実質的に同じである。

実施例２では、プラン生成処理によって、図３３Ａ、図３３Ｂ、及び図３３Ｃに示した展開プランが生成される。具体的には、ボリュームマイグレーションに関する展開プランとして、展開プラン「ＥｘＰｌａｎ１−１」、展開プラン「ＥｘＰｌａｎ１−２」、及び展開プラン「ＥｘＰｌａｎ１−３」が生成され、ＶＭ移動に関する展開プランとして、展開プラン「ＥｘＰｌａｎ６−１」、展開プラン「ＥｘＰｌａｎ６−２」、展開プラン「ＥｘＰｌａｎ６−３」、及び展開プラン「ＥｘＰｌａｎ６−４」が生成される。すなわち、合計７つの展開プランが生成される。図３５に示した実施例２に係るプラン提示処理により、展開プラン「ＥｘＰｌａｎ１−１」、展開プラン「ＥｘＰｌａｎ１−２」、及び展開プラン「ＥｘＰｌａｎ１−３」のうち、移動対象ボリュームの性能が最も良くなるプランである展開プラン「ＥｘＰｌａｎ１−１」のみが残され、展開プラン「ＥｘＰｌａｎ１−２」、及び展開プラン「ＥｘＰｌａｎ１−３」が削除される。また、プラン提示処理により、展開プラン「ＥｘＰｌａｎ６−１」、展開プラン「ＥｘＰｌａｎ６−２」、展開プラン「ＥｘＰｌａｎ６−３」、及び展開プラン「ＥｘＰｌａｎ６−４」のうち、対象ＶＭの性能が最も良くなるプランの一つである展開プラン「ＥｘＰｌａｎ６−１」のみが残され、展開プラン「ＥｘＰｌａｎ６−２」、展開プラン「ＥｘＰｌａｎ６−３」、及び展開プラン「ＥｘＰｌａｎ６−４」が削除される。この例では、障害原因がストレージ装置２００００である汎用ルールに対応する展開プランと、障害原因がスイッチ６００００である汎用ルールに対応する展開プランとを集約できることが示されている。本画面９０００では、本質的には、根本原因の異なる障害に対する対策プランが共通していることを図示できればよく、図３６に示した表示方法に限定されない。

実施例２によれば、障害原因と障害に対する具体的な回復プランとを関連付けて提示し、各プランの実行によって、障害原因に関連する障害イベントのうち、どれだけのイベントが解消されるかをチェックし、その結果を表示することで、プラン実行後にも潜在的に残されたままとなる問題箇所を、その理由と共にプランの詳細情報として管理者に提示することができる。これにより、管理者は、適切なプランを選択できるようになり、プラン実行後のリスクをプラン選択時に把握することができる。また、同等あるいは類似した効果が得られる展開プラン同士を１つにまとめることで、冗長なプランの提示を抑制し、また、障害に対する回復プランが大量に存在する場合に、管理者に対して提示するプランの数を削減することができ、プラン詳細の確認作業やプランの選択作業における管理者のコストを低減することができる。

次に、実施例３について説明する。以下の説明では、実施例１、及び実施例２との差異を中心に説明し、同等の構成要素や、同等の機能を持つプログラム、同等の項目を持つテーブルについては、記載を省略する。

図３７は、実施例３に係る管理サーバの一例の構成図である。

管理サーバ１００００は、実施例２と同様の構成要素を備え、メモリ１１０００には、さらに、保守情報管理プログラム１１１１０が格納される。また、ルール・プラン情報リポジトリ１１９００には、さらに、保守情報管理テーブル１１９８０が格納される。保守情報管理テーブル１１９８０は、装置の新陳代謝等に伴うリプレース、メンテナンス作業等に関する情報を管理する。

図３７に示す例では、各種プログラム及びテーブルは、メモリ１１０００に格納されているが、記憶デバイス１２０００または他の記憶媒体（図示しない）に格納されていてもよい。この場合、プロセッサ１５０００は、プログラム実行時にメモリ１１０００上に対象のプログラムを読み出し、読み出したプログラムを実行する。また、ストレージ装置２００００のメモリまたは物理サーバ３００００のメモリに、前述のプログラム及び前述のテーブルが格納され、ストレージ装置２００００または物理サーバ３００００が、格納されたプログラムを実行してもよい。また、スイッチ６００００等の他の装置が、前述のプログラム及びテーブルを格納し、格納したプログラムを実行してもよい。

図３８は、実施例３に係る汎用プランテーブルの一例の構成図である。

汎用プランテーブル１１９３０は、計算機システムにおいて実施可能なプランの一覧を管理する。汎用プランテーブル１１９３０は、汎用プランＩＤ１１９３１、プラン１１９３２、及び保守対応１１９３３のフィールドを含む。汎用プランＩＤ１１９３１には、汎用プランの識別子である汎用プランＩＤが格納される。プラン１１９３２には、計算機システムにおいて実施可能なプランを示す情報が格納される。保守対応１１９３３には、保守スケジュールと関係があるプランか否かを示す情報が格納される。例えば、汎用プラン「Ｐｌａｎ８」のストレージポート交換や、汎用プラン「Ｐｌａｎ９」のスイッチ交換等、物理的なハードウェアを交換するようなプランが、保守スケジュールと関係があるプランとされる。

図３９は、実施例３に係るルール・プラン対応テーブルの一例の構成図である。

実施例３に係るルール・プラン対応テーブル１１９４０の構成は、実施例１に係るルール・プラン対応テーブル１１９４０の構成と実質的に同じである。実施例３では、汎用ルールとして汎用ルール「Ｒｕｌｅ４」を、汎用プランとして汎用プラン「Ｐｌａｎ６」及び「Ｐｌａｎ９」を取り上げて説明する。

図４０Ａは、実施例３に係る展開プランテーブルの第１の構成図である。図４０Ｂは、実施例３に係る展開プランテーブルの第２の構成図である。

実施例３に係る展開プランテーブル１１９６０の構成は、実施例１に係る展開プランテーブル１１９６０の構成と実質的に同じである。実施例１と同様に、プラン対象１１９６４に含まれるフィールドは、プランの内容によって異なる。

図４０Ｂの汎用プラン「Ｐｌａｎ９」に基づく展開プラン、すなわちスイッチ交換に関する展開プランでは、プラン対象１１９６４は、例えば、交換の対象となるスイッチ６００００（以下「交換対象スイッチ」という）の識別子が格納される交換対象スイッチ１１９６Ｅと、交換にかかるコストを表すデータが格納されるＣｏｓｔ１１９６Ｆとのフィールドを含む。交換対象スイッチの識別子については、プラン生成プログラム１１１００が、構成情報テーブル１１８１０から取得し、格納する。Ｃｏｓｔ１１９６Ｆに格納される値については、プラン生成プログラム１１１００が、保守情報管理テーブル１１９８０から取得し、格納する。ここでは、交換対象の識別情報及びコスト情報のみを格納する例を記載したが、そのほかの情報、例えば、スイッチ６００００の交換にどの程度の時間がかかるかを示す情報等が格納されてもよい。

図４１は、実施例３に係る保守情報管理テーブルの一例の構成図である。

保守情報管理テーブル１１９８０は、管理者がハードウェア交換等の保守操作を行うスケジュール情報を管理する。本テーブル１１９８０は、例えば、管理者が手作業で入力する等して生成される。保守情報管理テーブル１１９８０は、装置１１９８１、装置部位１１９８２、交換理由１１９８３、交換日時１１９８４、影響サービス１１９８５、及びコスト１１９８６のフィールドを含む。装置１１９８１には、保守操作の対象となる装置の装置ＩＤが格納される。装置部位ＩＤ１１９８２には、保守操作の対象となるデバイスの識別子が格納される。交換理由１１９８３には、交換をスケジューリングすることになった理由を示す情報が格納される。交換日時１１９８４には、交換することになっている日時を示す情報が格納される。影響サービス１１９８５には、保守操作の対象となるデバイスを交換することにより影響を受けるサービスの識別子が格納される。コスト１１９８６には、保守操作の対象となるデバイスを交換した際のコストを示す情報が格納される。

図４２は、実施例３に係る効果・リスク提示処理のフローチャートである。

ステップ８００１〜ステップ８００４の処理は、実施例１に係る効果・リスク提示処理におけるステップＳ６００１〜ステップ６００４の処理と同様の処理のため、説明を省略する。

ステップ８００５において、プラン提示プログラム１１３００は、汎用プランテーブル１１９３０の保守対応１１９３３の情報、及び、保守情報テーブル１１９８０を参照し、保守スケジュールに関する情報を取得する。

その後、プラン提示プログラム１１３００は、ステップ８００２〜ステップ８００５で取得した情報に基づいてプラン詳細画面９０１０（図４３参照）を生成し、生成したプラン詳細画面９０１０を出力デバイス１４０００に表示させる（ステップ８００６）。その後、プラン提示プログラム１１３００は、効果・リスク提示処理を終了する。

図４３は、実施例３に係るプラン詳細画面の一例の構成図である。

実施例３に係るプラン詳細画面９０１０の構成は、実施例１に係るプラン詳細画面９０１０の構成と実質的に同じである。

図４３に示す例では、プラン実行前の状況を示す領域９０１５は、ＶＭ１のドライブ「Ｅ：」と、スイッチＡと、ストレージＢのデータＩ／Ｆ「Ｐ３」と、ストレージＢの論理ボリューム「ＬＶ１０」と、ディスクプール「ＰＯＯＬ３」とが関連づけられ、ＶＭ２のドライブ「Ｆ：」と、スイッチＡと、ストレージＢの論理ボリューム「ＬＶ１１」と、ディスクプール「ＰＯＯＬ３」とが関連づけられ、ＶＭ３のドライブ「Ｄ：」と、スイッチＢと、ストレージＢの論理ボリュームＬＶ「１２」と、ディスクプール「ＰＯＯＬ４」とが関連づけられていることを示している。また、プラン実行前の状況を示す領域９０１５は、ＶＭ２のドライブ「Ｆ：」と、スイッチＡのデータＩ／Ｆと、ストレージＢのデータＩ／Ｆとに障害イベントが発生しており、ＶＭ１のドライブ「Ｅ：」にリスクが存在することを示している。

プラン実行後の状況を示す領域９０１６は、物理サーバＢのハイパーバイザ８００００上で動作していたＶＭ２が、物理サーバＣ上のハイパーバイザ８００００上で動作するようになることを示しており、プラン実行後には、ＶＭ２のドライブ「Ｆ：」と、スイッチＢと、ストレージＢのデータＩ／Ｆと、ストレージＢの論理ボリューム「ＬＶ１１」と、ディスクプール「ＰＯＯＬ３」とが関連づけられるようになり、スイッチＡのデータＩ／Ｆと、ストレージＢのデータＩ／Ｆとに障害イベントが残り続け、ＶＭ１にリスクが残り続けることを示している。

実施例３では、リスク詳細を示す表示領域９０１７には、リスク箇所がＶＭ１のドライブ「Ｅ：」であり、リスクが発生する可能性のあるタイミングは、ドライブ「Ｅ：」の電源がＯＮになるタイミングであることを表している。リスク発生タイミングは、例えば、図４２のステップ８００２において取得された情報に基づいて決定される。例えば、管理サーバ１００００が、ＶＭ構成管理テーブル１１８３０の電源状態１１８３２の情報を取得し、ＶＭ１の電源状態がＯＦＦ状態であることを検出し、ＶＭの電源ＯＮに伴い、業務が再開されることがリスク発生の契機になり得ると判断し、リスク発生タイミング９０１９に、当該情報を格納してもよい。

保守スケジュールを示す表示領域９０２２は、例えば、保守作業における交換対象の装置またはデバイスの識別子が表示される領域９０２３と、交換理由が表示される領域９０２４と、交換日時が表示される領域９０２５とのフィールドを含む。保守スケジュールを示す表示領域９０２２に表示される交換対象は、例えば、障害イベントの発生した装置またはデバイスに限定され、これらの情報は、図４２の効果・リスク提示処理におけるステップ８００５の処理で取得される。表示領域９０２２には、図４１の保守情報管理テーブル１１９８０に示した情報、例えばコストの情報等があわせて表示されてもよい。保守スケジュールに関する情報を参照した管理者は、例えば、障害の発生個所の装置またはデバイスの保守による交換日時を確認し、障害に対する対処も兼ね、予定を早めてスイッチの交換を行ったり、あるいは、スイッチの交換が近いため、一時対策として多少のリスクは残るもののＶＭ移動によるプランを選択したりすることが可能となる。

実施例３では、表示領域９０１１と表示領域９０１７と表示領域９０２２とが同一画面に表示されているが、これに限定されず、例えば、表示領域９０１１の保守スケジュールに設定されている装置またはデバイス、例えばスイッチＡを示す図形がクリックされた際に、表示領域９０２２が別画面として新規に表示されるようにしてもよい。あるいは、プラン提示画面９０００の表示領域９００１に表示されたプランがクリックされた際に、表示領域９０２２が別画面として新規に表示されるようにしてもよい。また、表示領域９０１１の物理サーバ３００００やストレージ装置２００００等の装置またはデバイスを示す図形がクリックされた際に、プラン実行前後の当該装置またはデバイスの性能値が表示されるようにしてもよい。

実施例３によれば、障害原因と障害に対する具体的な回復プランとを関連付けて提示し、各プランの実行によって、障害原因に関連する障害イベントのうち、どれだけのイベントが解消されるかをチェックし、その結果を表示することで、プラン実行後にも潜在的に残されたままとなる問題箇所を、その理由と共にプランの詳細情報として管理者に提示することができる。これにより、管理者は、適切なプランを選択できるようになり、プラン実行後のリスクをプラン選択時に把握できる。また、保守スケジュールと関連付けることのできるプランの場合に、プラン詳細画面９０１０において保守スケジュールをあわせて確認できるようにし、管理者が影響の重要性を把握し易くすることで、プラン選択におけるコストを削減することができる。

なお、本発明は、以上説明した実施例に限定されるものでなく、その趣旨を逸脱しない範囲で種々変更可能であることはいうまでもない。

１００００：管理サーバ、２００００：ストレージ装置、３００００：物理サーバ

Claims (15)

1. 複数の監視対象デバイスを有する計算機システムの管理を行う管理システムであって、
   記憶デバイスと、
   前記記憶デバイスに接続された制御デバイスと
   を有し、
   前記記憶デバイスは、
   前記複数の監視対象デバイスのいずれかに関する１以上の条件イベントと、前記１以上の条件イベントが発生した場合に原因となる、前記複数の監視対象デバイスのいずれかに関する結論イベントとの対応関係を示し、前記条件イベント及び前記結論イベントに関係する監視対象デバイスを当該監視対象デバイスの種別で表した汎用ルールと、
   前記汎用ルールと、前記汎用ルールの結論イベントが原因である場合に実施し得る回復策である１以上の汎用プランとの対応関係を示す汎用プラン情報と、
   前記汎用ルールと前記汎用プランとの組み合わせごとに、当該汎用プランが実施された場合に未解決のまま残される、当該汎用ルールの条件イベントを示す未解決情報と、
   前記複数の監視対象デバイス間の接続関係を示す構成情報と
   を記憶し、
   前記制御デバイスは、
   前記汎用ルール及び前記構成情報に基づいて、前記条件イベント及び前記結論イベントに関係する監視対象デバイスの種別を特定の監視対象デバイスを示すデータで表した複数の展開ルールを生成し、
   前記複数の監視対象デバイスのいずれかに関するイベントが発生した場合、前記生成した複数の展開ルールに基づいて、前記発生したイベントを条件イベントとして原因解析を行い、前記発生したイベントの原因の候補となる第１の結論イベントを特定し、
   前記汎用プラン情報に基づいて、前記第１の結論イベントが原因である場合に実施し得る回復策であって、前記第１の結論イベントを含む展開ルールの基となる汎用ルールに対応する汎用プランを前記計算機システムの実構成を考慮して展開した回復策である１以上の展開プランを生成し、
   前記生成した１以上の展開プランのそれぞれについて、前記未解決情報に基づいて当該展開プランが実施された場合に未解決のまま残される未解決イベントを特定し、特定した前記未解決イベントに基づいて当該展開プランが実施された後も問題が残り続ける監視対象デバイスであるリスク箇所を特定し、
   前記第１の結論イベント、前記生成した１以上の展開プラン、及び前記特定したリスク箇所を示すデータを表示する
   管理システム。
2. 前記制御デバイスは、
   前記生成した１以上の展開プランのそれぞれについて、当該展開プランの基となる汎用プランと、前記第１の結論イベントを含む第１の展開ルールの基となる汎用ルールとの組み合わせに対応する未解決のまま残される条件イベントを特定し、
   当該特定した条件イベントに対応する前記第１の展開ルールの条件イベントを、前記未解決イベントとして特定し、
   当該特定した未解決イベントに関係する監視対象デバイス、及び当該特定した未解決イベントに関係する監視対象デバイスと接続関係を有する監視対象デバイスのうちのいずれか１以上の監視対象デバイスを前記リスク箇所として特定する
   請求項１記載の管理システム。
3. 前記制御デバイスは、
   前記第１の結論イベントを含む第１の展開ルールの基となる汎用ルールに対応する汎用プランがボリュームマイグレーションである場合、前記第１の展開ルールの条件イベント及び結論イベントのいずれかに関係する、ボリュームである監視対象デバイスを移動元ボリュームとし、前記移動元ボリュームと接続関係を有する、ボリュームである監視対象デバイスを移動先ボリュームとする、ボリュームマイグレーションに関する第１の展開プランを生成し、
   前記第１の展開プランについて、前記移動元ボリューム及び前記移動先ボリュームに対するＩ／Ｏのレスポンスタイムに基づいて、前記第１の展開プランの実施後の、前記移動元ボリューム及び前記移動先ボリュームに対するＩ／Ｏのレスポンスタイムの予測値を計算し、
   前記Ｉ／Ｏのレスポンスタイムの予測値を表示する
   請求項２記載の管理システム。
4. 前記制御デバイスは、
   前記第１の結論イベントを含む第１の展開ルールの基となる汎用ルールに対応する汎用プランがプールへのディスクの追加である場合、前記第１の展開ルールの条件イベント及び結論イベントのいずれかに関係する、プールである監視対象デバイスをディスクの追加対象のプールとする、プールへのディスクの追加に関する第１の展開プランを生成し、
   前記第１の展開プランについて、前記追加対象のプールに対するＩ／Ｏのレスポンスタイム、及び前記追加対象のプールのディスク追加前後の容量比に基づいて、前記第１の展開プランの実施後の、前記追加対象のプールに対するＩ／Ｏのレスポンスタイムの予測値を計算し、
   前記Ｉ／Ｏのレスポンスタイムの予測値を表示する
   請求項３記載の管理システム。
5. 前記制御デバイスは、
   前記生成した１以上の展開プランのそれぞれについて、当該展開プランに関係する監視対象デバイスに関する性能値に基づいて、当該展開プランに関係する監視対象デバイスに関する、当該展開プランの実施後の性能値の予測値を計算し、
   前記性能値の予測値をさらに表示する
   請求項４記載の管理システム。
6. 前記制御デバイスは、
   前記生成した１以上の展開プランのうちの同一又は類似する複数の展開プランを１つの展開プランに集約し、
   前記集約した展開プランを示すデータを表示する
   請求項５記載の管理システム。
7. 前記記憶デバイスは、
   前記複数の監視対象デバイスのいずれかに対して行われる保守操作のスケジュールを示す保守スケジュール情報
   をさらに記憶し、
   前記制御デバイスは、
   前記展開プランに関係する監視対象デバイスに対して行われる保守操作のスケジュールを示すデータをさらに表示する
   請求項６記載の管理システム。
8. 前記記憶デバイスは、
   前記１以上の汎用プランのそれぞれについて、当該汎用プランを実施するために要するコストを示すコスト情報
   をさらに記憶し、
   前記制御デバイスは、
   前記生成した１以上の展開プランのそれぞれについて、当該展開プランの基となる汎用プランを実施するために要するコストに基づいて、当該展開プランを実施するために要するコストを計算し、
   前記計算したコストをさらに表示する
   請求項７記載の管理システム。
9. 複数の監視対象デバイスを有する計算機システムの管理を行う管理方法であって、
   前記複数の監視対象デバイスのいずれかに関する１以上の条件イベントと、前記１以上の条件イベントが発生した場合に原因となる、前記複数の監視対象デバイスのいずれかに関する結論イベントとの対応関係を示し、前記条件イベント及び前記結論イベントに関係する監視対象デバイスを当該監視対象デバイスの種別で表した汎用ルール、及び、前記複数の監視対象デバイス間の接続関係を示す構成情報に基づいて、前記条件イベント及び前記結論イベントに関係する監視対象デバイスを特定の監視対象デバイスを示すデータで表した複数の展開ルールを生成し、
   前記複数の監視対象デバイスのいずれかに関するイベントが発生した場合、前記生成した展開ルールに基づいて前記発生したイベントを条件イベントとして原因解析を行い、前記発生したイベントの原因の候補となる第１の結論イベントを特定し、
   前記汎用ルールと、前記汎用ルールの結論イベントが原因である場合に実施し得る回復策である１以上の汎用プランとの対応関係を示す汎用プラン情報に基づいて、前記第１の結論イベントが原因である場合に実施し得る回復策であって、前記第１の結論イベントを含む展開ルールの基となる汎用ルールに対応する汎用プランを前記計算機システムの実構成を考慮して展開した回復策である１以上の展開プランを生成し、
   前記生成した１以上の展開プランのそれぞれについて、汎用ルールと汎用プランとの組み合わせごとに、当該汎用プランが実施された場合に未解決のまま残される、当該汎用ルールの条件イベントを示す前記未解決情報に基づいて、当該展開プランが実施された場合に未解決のまま残される未解決イベントを特定し、特定した未解決イベントに基づいて、当該展開プランが実施された後も問題が残り続ける監視対象デバイスであるリスク箇所を特定し、
   前記第１の結論イベント、前記生成した１以上の展開プラン、及び前記特定したリスク箇所を示すデータを表示する
   ことをコンピュータに実行させるためのコンピュータプログラム。
10. 前記生成した１以上の展開プランのそれぞれについて、当該展開プランの基となる汎用プランと、前記第１の結論イベントを含む第１の展開ルールの基となる汎用ルールとの組み合わせに対応する未解決のまま残される条件イベントを特定し、当該特定した条件イベントに対応する前記第１の展開ルールの条件イベントを、前記未解決イベントとして特定し、当該特定した未解決イベントに関係する監視対象デバイス、及び当該特定した未解決イベントに関係する監視対象デバイスと接続関係を有する監視対象デバイスのうちのいずれか１以上の監視対象デバイスを前記リスク箇所として特定する
    請求項９記載のコンピュータプログラム。
11. 前記第１の結論イベントを含む第１の展開ルールの基となる汎用ルールに対応する汎用プランがボリュームマイグレーションである場合、前記第１の展開ルールの条件イベント及び結論イベントのいずれかに関係する、ボリュームである監視対象デバイスを移動元ボリュームとし、前記移動元ボリュームと接続関係を有する、ボリュームである監視対象デバイスを移動先ボリュームとする、ボリュームマイグレーションに関する第１の展開プランを生成し、
    前記第１の展開プランについて、前記移動元ボリューム及び前記移動先ボリュームに対するＩ／Ｏのレスポンスタイムに基づいて、前記第１の展開プランの実施後の、前記移動元ボリューム及び前記移動先ボリュームに対するＩ／Ｏのレスポンスタイムの予測値を計算し、
    前記Ｉ／Ｏのレスポンスタイムの予測値を表示する
    請求項１０記載のコンピュータプログラム。
12. 前記生成した１以上の展開プランのそれぞれについて、当該展開プランに関係する監視対象デバイスに関する性能値に基づいて、当該展開プランに関係する監視対象デバイスに関する、当該展開プランの実施後の性能値の予測値を計算し、
    前記性能値の予測値をさらに表示する
    請求項９記載のコンピュータプログラム。
13. 前記生成した１以上の展開プランのうちの同一又は類似する複数の展開プランを１つの展開プランに集約し、
    前記集約した展開プランを示すデータを表示する
    請求項９記載のコンピュータプログラム。
14. 前記複数の監視対象デバイスのいずれかに対して行われる保守操作のスケジュールを示す保守スケジュール情報に基づいて、前記展開プランに関係する監視対象デバイスに対して行われる保守操作のスケジュールを示すデータをさらに表示する
    請求項９記載のコンピュータプログラム。
15. 前記１以上の汎用プランのそれぞれについて、当該汎用プランを実施するために要するコストを示すコスト情報に基づいて、前記生成した１以上の展開プランのそれぞれについて、当該展開プランを実施するために要するコストを計算し、
    前記計算したコストをさらに表示する
    請求項９記載のコンピュータプログラム。
    
    

Images