JP5419819B2 - 計算機システムの管理方法、及び管理システム - Google Patents

Description

本発明は、計算機システムの管理方法及び管理システムに関し、例えば、計算機システムを構成するホストコンピュータ、ネットワークスイッチおよびストレージシステムの障害を管理する技術に関する。

計算機システムを管理する場合、例えば特許文献１に示されるように、システム内で検知した複数の障害もしくはその兆候の中から、原因となる事象（イベント）を検出することが行われている。より具体的に、特許文献１では、管理ソフトウェアを用いて、管理下機器における性能値の閾値超過をイベント化し、イベントＤＢに情報を蓄積する。また、この管理ソフトウェアトは、管理下機器において発生した複数の障害イベントの因果関係を解析するための解析エンジンを持っている。この解析エンジンは、管理下機器のインベントリ情報を持つ構成ＤＢにアクセスして、Ｉ／Ｏ系路上のパス上にある機器内構成要素を認識し、ホスト上の論理ボリュームの性能に影響を与えうる構成要素を「トポロジ」と呼ばれる一グループとして認識する。そして、解析エンジンは、イベントが発生すると各トポロジに対し、事前に定められた条件文と解析結果からなる解析ルールを適用して展開ルールを構築する。この展開ルールには、他装置における性能低下の原因である原因イベントと、それによって引き起こされている関連イベント群が含まれる。具体的には、ルールのＴＨＥＮ部に障害の根本原因として記載されているイベントが原因イベント、ＩＦ部に記載されているイベントのうち原因イベント以外のものが関連イベントである。

米国特許７１０７１８５号公報

特許文献１による障害解析機能では、管理対象機器から受信するイベントの組み合わせと、障害の原因候補をＩＦ−ＴＨＥＮ形式のルールとして記述しておく。障害解析機能は、ルールのＩＦ部に記載されたイベントの発生割合を計算することで、ＴＨＥＮ部に記載された障害原因候補の確信度を算出する。算出した確信度と障害原因候補は、ユーザの求めに応じてＧＵＩ表示される。

しかしながら、このような従来の障害解析機能においては、障害が短い期間に頻発すると、保存される障害解析結果の数が多くなってしまい、管理者としてはどれが本当に対処すべき障害なのか判断できないことがある。つまり、従来の障害解析結果には対策実行優先度に関する情報がないため、管理者が本来対策を行うべき解析結果を参照するまでの時間が長くなり、結果的に障害の解消までに要する時間が長くなってしまう。

本発明はこのような状況に鑑みてなされたものであり、監視対象の機器における障害を解消させるために要する時間を短くすることができる障害解析機能を提供するものである。

上記課題を解決するために、本発明では、障害原因解析処理の後に、異常状態にあった機器のステータス正常化を検知したとき、障害解析結果のうち、その導出根拠となった機器異常状態が解消したものについて他の解析結果と区別してGUIに表示する。障害解析結果が複数の障害イベントにより導出された場合は、全ての障害イベントの正常化を確認した時点で、他の障害解析結果とは区別してGUIに表示する。

また、本発明では、管理対象機器において業務に支障をきたす事態となっていないにもかかわらず発生し、発生後すぐに正常化する障害イベントを受信した場合、異常状態にあった機器のステータス正常化を検知し、その導出根拠となった機器異常状態が全て解消した時点で障害原因候補を確信度と共に障害解析結果として保存する。また、障害解析結果について他の解析結果と区別してGUIに表示する。

即ち、本発明では、管理サーバにおいて、ノード装置の処理性能を示す処理性能値を取得し、当該取得した処理性能値からノード装置の状態を検知し、検知した状態を、ノード装置で発生し得る１つ以上の条件イベントの組み合わせと条件イベントの組み合わせの根本原因とされる結論イベントとの関係を示す解析ルールに適用する。そして、ノード装置における障害の発生の可能性を示す情報である確信度を算出し、確信度からノード装置に障害が発生したか否か判断する。また、管理サーバにおいて、障害が発生したと判断されたノード装置について、確信度の情報は変更せずに、状態が異常のままのノード装置の障害解析結果である未解決障害解析結果と状態が異常から正常に変化したノード装置の障害解析結果である解決済障害解析結果とを表示画面に表示する。解析結果を表示する場合には、未解決障害解析結果と解決済障害解析結果とを区別して表示画面に表示したり、未解決障害解析結果及び解決済障害結果に対して、処理優先度を併せて表示画面に表示するようにしても良い。

さらなる本発明の特徴は、以下本発明を実施するための形態および添付図面によって明らかになるものである。

本発明によれば、障害解析結果を管理者（ユーザ）に提示する際、受信した障害の正常化を反映して表示することにより、管理者が解析結果の対応優先度を容易に判断でき、解析結果確認に要する負荷を軽減することができる。

計算機システムの物理構成例を示す図である。 ホストコンピュータの詳細な構成例を示す図である。 ストレージ装置の詳細な構成例を示す図である。 管理サーバの詳細な構成例を示す図である。 管理サーバが有する装置性能管理表の構成例を示す図である。 管理サーバが有するボリュームトポロジ管理表の構成例を示す図である。 管理サーバが有するイベント管理表の構成例を示す図である。 管理サーバが有する汎用ルールの構成例（１）を示す図である。 管理サーバが有する汎用ルールの構成例（２）を示す図である。 管理サーバが有する展開ルールの構成例（１）を示す図である。 管理サーバが有する展開ルールの構成例（２）を示す図である。 管理サーバが有する展開ルールの構成例（３）を示す図である。 管理サーバが有する展開ルールの構成例（４）を示す図である。 管理サーバが有する解析結果管理表の構成例を示す図である。 管理サーバが実施する性能情報取得処理の概要を説明するためのフローチャートである。 管理サーバが実施する障害解析処理を説明示するためのフローチャートである。 管理サーバが有するイベント種別管理表の構成例を示す図である。 管理サーバが有する性能メトリック管理表の構成例を示す図である。 第１の実施形態において、管理サーバが実行する解決済みイベント反映処理を説明するためのフローチャートである。 第１の実施形態において、管理サーバが表示する障害解析結果画面の構成例を示す図である。 第２の実施形態において、管理サーバが実行する瞬間障害イベント反映処理を説明するためのフローチャートである。 第２の実実施形態において、管理サーバが表示する障害解析結果画面の構成例を示す図である。 実施例３において管理サーバが具備する解析結果管理表の構成例を示す図である。 第３の実施形態において、管理サーバが実行する障害解析結果の対処優先度設定処理を説明するためのフローチャートである。 第３の実施形態において、管理サーバが表示する障害解析結果画面の構成例を示す図である。

本発明の実施形態は、障害の解消を加味した障害根本原因解析に関するものである。
以下、添付図面を参照して本発明の実施形態について説明する。ただし、本実施形態は本発明を実現するための一例に過ぎず、本発明の技術的範囲を限定するものではないことに注意すべきである。また、各図において共通の構成については同一の参照番号が付されている。

なお、本明細書では「ａａａ表」という表現によって本発明で用いられる情報について説明しているが、「ａａａテーブル」、「ａａａリスト」、「ａａａＤＢ」、「ａａａキュー」等の表現や、テーブル、リスト、ＤＢ、キュー、等のデータ構造以外で表現されていてもよい。このため、本発明で用いられる情報が、データ構造に依存しないことを示すために、「ａａａテーブル」、「ａａａリスト」、「ａａａＤＢ」、「ａａａキュー」等について「ａａａ情報」と呼ぶことがある。

また、各情報の内容を説明する際に、「識別情報」、「識別子」、「名」、「名前」、「ＩＤ」という表現を用いるが、これらについてはお互いに置換が可能である。

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

（１）第１の実施形態
第１の実施形態は、管理ソフトウェア（例えば、管理サーバに含まれる）による解決済みイベント反映処理に関するものである。

＜システム構成＞
図１は、本発明による計算機システムの物理的構成を示す図である。当該計算機システムは、ストレージ装置２００００と、ホストコンピュータ１００００と、管理サーバ３００００と、WEBブラウザ起動サーバ３５０００と、IPスイッチ４００００と、を有し、それらが、ネットワーク４５０００によって接続される構成となっている。

ホストコンピュータ１００００乃至１００１０は、例えば、それらに接続された、図示しないクライアントコンピュータからファイルのI/O要求を受信し、それに基づいてストレージ装置２００００乃至２００１０へのアクセスを実現する。また、管理サーバ（管理計算機）３００００は、当該計算機システム全体の運用を管理するものである。

WEBブラウザ起動サーバ３５０００は、ネットワーク４５０００を介して、管理サーバ３００００のGUI表示処理モジュール３２４００と通信し、WEBブラウザ上に各種情報を表示する。ユーザはWEBブラウザ起動サーバ上のWEBブラウザに表示された情報を参照することで、計算機システム内の装置を管理する。ただし、管理サーバ３００００と、WEBブラウザ起動サーバ３５０００は１台のサーバから構成されていてもよい。

＜ホストコンピュータの内部構成＞
図２は、本発明によるホストコンピュータ１００００の詳細な内部構成例を示す図である。ホストコンピュータ１００００は、ネットワーク４５０００に接続するためのポート１１０００と、プロセッサ１２０００と、メモリ１３０００と、を有し（ディスク装置を構成として含んでも良い）、これらは内部バス等の回路を介して相互に接続される構成となっている。

メモリ１３０００には、業務アプリケーション１３１００と、オペレーティングシステム１３２００が格納されている。

業務アプリケーション１３１００は、オペレーティングシステム１３２００から提供された記憶領域を使用し、当該記憶領域に対しデータ入出力（以下、I/Oと表記）を行う。

オペレーティングシステム１３２００は、ネットワーク４５０００を介してホストコンピュータ１００００に接続されたストレージ装置２００００乃至２００１０上の論理ボリュームを記憶領域として業務アプリケーション１３１００に認識させるための処理を実行する。

ポート１１０００は、ストレージ装置２００００とiSCSIにより通信を行うためのI/Oポートと、管理サーバ３００００がホストコンピュータ１００００乃至１００１０内の管理情報を取得するための管理ポートを含む単一のポートとして図２で表現されているが、iSCSIにより通信を行うためのI/Oポートと管理ポートに分かれていてもよい。

＜ストレージ装置の内部構成＞
図３は、本発明によるストレージ装置２００００の詳細な内部構成例を示す図である。ストレージ装置２００１０も同様の構成を有している。

ストレージ装置２００００は、ネットワーク４５０００を介してホストコンピュータ１００００に接続するためのI/Oポート２１０００及び２１０１０と、ネットワーク４５０００を介して管理サーバ３００００に接続するための管理ポート２１１００と、各種管理情報を格納するための管理メモリ２３０００と、データを格納するためのRAIDグループ２４０００乃至２４０１０と、データや管理メモリ内の管理情報を制御するためのコントローラ２５０００及び２５０１０と、を有し、これらが内部バス等の回路を介して相互に接続される構成となっている。なお、RAIDグループ２４０００乃至２４０１０の接続とは、より正確にはRAIDグループ２４０００乃至２４０１０を構成する記憶デバイスが他の構成物と接続されていることを指す。

管理メモリ２３０００には、ストレージ装置の管理プログラム２３１００が格納される。管理プログラム２３１００は管理ポート２１１００を経由して管理サーバ３００００と通信し、管理サーバ３００００に対しストレージ装置２００００の構成情報を提供する。

RAIDグループ２４０００乃至２４０１０は、それぞれ、１つまたは複数の磁気ディスク２４２００、２４２１０、２４２２０、及び２４２３０によって構成されている。複数の磁気ディスクによって構成されている場合、それらの磁気ディスクはRAID構成を組んでいてもよい。また、RAIDグループ２４０００乃至２４０１０は、論理的に複数のボリューム２４１００乃至２４１１０に分割されている。

なお、論理ボリューム２４１００及び２４１１０は、１つ以上の磁気ディスクの記憶領域を用いて構成されるのであれば、RAID構成を組まなくてもよい。さらに、論理ボリュームに対応する記憶領域を提供するのであれば、磁気ディスクの代わりとしてフラッシュメモリなど他の記憶媒体を用いた記憶デバイスでも良いものとする。

コントローラ２５０００及び２５０１０は、その内部に、ストレージ装置２００００内の制御を行うプロセッサや、ホストコンピュータ１００００との間でやりとりするデータを一時的に記憶するキャッシュメモリを持っている。そして、それぞれのコントローラは、I/OポートとRAIDグループの間に介在し、両者の間でデータの受け渡しを行う。

なお、ストレージ装置２００００は、何れかのホストコンピュータに対して論理ボリュームを提供し、アクセス要求(I/O要求を指す）を受信し、受信したアクセス要求に応じて記憶デバイスへの読み書きを行うストレージコントローラと、記憶領域を提供する前述の記憶デバイスを含めば、図３及び上記説明以外の構成でもよく、例えば、ストレージコントローラと記憶領域を提供する記憶デバイスが別な筐体に格納されていてもよい。即ち、図３の例では管理メモリ２３０００とコントローラ２５０００及び２５１１０とが別個の存在として設けられているが、それらが一体となったストレージコントローラとして構成しても良い。また、本明細書ではストレージコントローラと記憶デバイスが同じ筐体に存在する場合または別な筐体を含む表現として、ストレージ装置をストレージシステムと呼び変えても良い。

＜管理サーバの内部構成＞
図４は、本発明による管理サーバ３００００の詳細な内部構成例を示す図である。管理サーバ３００００は、ネットワーク４５０００に接続するための管理ポート３１０００と、プロセッサ３１１００と、キャッシュメモリ等のメモリ３２０００と、ＨＤＤ等の二次記憶装置（二次記憶領域）３３０００と、後述する処理結果を出力するためのディスプレイ装置等の出力デバイス３１２００と、ストレージ管理者が指示を入力するためのキーボード等の入力デバイス３１３００とを有し、これらが内部バス等の回路を介して相互に接続される構成となっている。

メモリ３２０００には、プログラム制御モジュール３２１００と、構成管理情報取得モジュール３２２００と、装置性能取得モジュール３２３００と、GUI表示処理モジュール３２４００と、イベント解析処理モジュール３２５００と、ルール展開モジュール３２６００と、が格納されている。なお、図４においては、各モジュールは、メモリ３２０００のソフトウェアモジュールとして提供されているが、ハードウェアモジュールとして提供されるものであっても良い。また、各モジュールが行う処理が一つ以上のプログラムコードとして提供されても良く、モジュール間の明確な境界が存在しなくても良い。モジュールは、プログラムと読み替えても良い。

二次記憶領域３３０００には、装置性能管理表３３１００と、ボリュームトポロジ管理表３３２００と、イベント管理表３３３００と、汎用ルールリポジトリ３３４００と、展開ルールリポジトリ３３５００と、解析結果管理表３３６００と、イベント種別管理表３３７００と、性能メトリック管理表３３８００と、が格納されている。なお、二次記憶領域３３０００は、半導体メモリまたは磁気ディスクのいずれか、もしくは半導体メモリおよび磁気ディスク両方から構成される。

GUI表示処理モジュール３３４００は、入力デバイス３１３００を介した管理者からの要求に応じ、取得した構成管理情報を、出力デバイス３１２００を介して表示する。なお、入力デバイスと出力デバイスは別々なデバイスでもよく、一つ以上のまとまったデバイスでもよい。

なお、管理サーバ（管理計算機）３００００は、例えば、入力デバイス３１３００としてキーボードとポインタデバイス等、出力デバイス３１２００としてディスプレイやプリンタ等とを有しているが、これ以外の装置であってもよい。また、入出力デバイスの代替としてシリアルインターフェースやイーサーネットインターフェースを用い、当該インターフェースにディスプレイ又はキーボード又はポインタデバイスを有する表示用計算機を接続し、表示用情報を表示用計算機に送信したり、入力用情報を表示用計算機から受信することで、表示用計算機で表示を行ったり、入力を受け付けることで入出力デバイスでの入力及び表示を代替してもよい。

本明細書では、計算機システム（情報処理システム）１を管理し、表示用情報を表示する一つ以上の計算機の集合を管理システムと呼ぶことがある。管理サーバ３００００が表示用情報を表示する場合は、管理サーバ３００００が管理システムであり、また、管理サーバ３００００と表示用計算機（例えば図１のWEBブラウザ起動サーバ３５０００)の組み合わせも管理システムである。また、管理処理の高速化や高信頼化のために複数の計算機で管理サーバと同等の処理を実現してもよく、この場合は当該複数の計算機（表示を表示用計算機が行う場合は表示用計算機も含め）が管理システムである。

＜装置性能管理表の構成＞
図５は、管理サーバ３００００が有する装置性能管理表３３１００の構成例を示す図である。

装置性能管理表３３１００は、管理対象となる機器の識別子となる装置IDを登録するフィールド３３１１０と、管理対象機器内部のデバイスの識別子であるデバイスIDを登録するフィールド３３１２０と、管理対象デバイスの性能情報のメトリック名称を格納するフィールド３３１３０と、閾値異常（「閾値に基づいて異常であると判断されたもの」の意味である）を検知した機器のOS種別を登録するフィールド３３１４０と、管理対象デバイスの性能値を該当装置から取得して格納するフィールド３３１５０と、管理対象デバイスの性能値の正常範囲の上限もしくは下限である閾値（アラート実行閾値）を、ユーザからの入力を受けて格納するフィールド３３１６０と、閾値が正常値の上限であるのか下限であるのかを登録するためのフィールド３３１７０と、性能値が正常値であるか異常値であるかを登録するためのフィールド３３１８０と、を構成項目として含んでいる。

例えば、図５の第１行目（１つ目のエントリ）からは、ストレージ装置SYS1内のコントローラCTL1におけるプロセッサの稼働率が現時点で４０％（３３１５０参照）であり、CTL1の稼働率が２０％を超えた場合（３３１６０参照）に管理サーバ３００００はコントローラCTL1が過負荷であると判断するが、当該具体例では本性能値が異常値であると判断されている（３３１８０参照）ことが分かる。

なお、ここでは管理サーバ３００００が管理するデバイスの性能値として単位時間当たりのI/O量や動作率を例として挙げたが、管理サーバ３００００が管理する性能値はこれ以外でも良い。

＜ボリュームトポロジ管理表の構成＞
図６は、管理サーバ３００００の有するボリュームトポロジ管理表３２２００の構成例を示す図である。

ボリュームトポロジ管理表３３２００は、ストレージ装置の識別子となる装置IDを登録するフィールド３３２１０と、ストレージ装置が有するボリュームの識別子となるボリュームIDを登録するフィールド３３２２０と、ボリュームがホストコンピュータ１００００と通信する際使用するポートの識別子となるポートIDを登録するフィールド３３２３０と、ポートとボリュームとの通信の際に使用するコントローラのIDを登録するフィールド３２３４０と、ボリュームが接続するホストコンピュータ１００００の識別子を登録するフィールド３３２５０と、ボリュームが実体となるホストコンピュータ１００００の論理ボリュームのドライブ名を登録するフィールド３３２６０と、を構成項目として含んでいる。

例えば、図６の第１行目（１つ目のエントリ）からは、ストレージ装置SYS1のボリュームVOL1が、PORT1で示されるストレージ側のポートおよびCTL1で示されるコントローラを介してホストコンピュータHOST1と接続し、ホスト上で論理ボリューム（E:）として認識されていることが分かる。

＜イベント管理表の構成＞
図７は、管理サーバ３００００が有するイベント管理表３３３００の構成例を示す図である。このイベント管理表３３３００は、後述する障害原因解析処理、解決済みイベント反映処理、において適宜参照されるものである。

イベント管理表３３３００は、イベント自身の識別子となるイベントIDを登録するフィールド３３３１０と、取得した性能値に閾値異常といったイベントの発生した機器の識別子となる装置IDを登録するフィールド３３３２０と、イベントの発生した機器内の部位の識別子を登録するフィールド３３３３０と、閾値異常を検知したメトリックの名称を登録するフィールド３３３４０と、閾値異常が検知された機器のOS種別を登録するフィールド３３３５０と、機器内の部位のイベント発生時の状態を登録するフィールド３３３６０と、イベントが後述するイベント解析処理モジュール３２５００によって解析済みかどうかを登録するフィールド３３３７０と、イベントが発生した日時を登録するフィールド３３３８０と、を構成項目として含んでいる。

例えば、図７の第１行目（１つ目のエントリ）からは、管理サーバ３００００が、ストレージ装置SYS1の、CTL1で示されるコントローラにおけるプロセッサ稼働率の閾値異常を検知し、そのイベントＩＤはＥＶ１であることが分かる。なお、異常状態が正常に変化した場合もイベントとして登録されるようにしても良い。

＜汎用ルールの構成＞
図８Ａ及びＢは、管理サーバ３００００が有する汎用ルールリポジトリ３３４００内の汎用ルールの構成例を示す図である。汎用ルール（後述の展開ルールも同様）は、計算機システムを構成するノード装置で発生し得る１つ以上の条件イベントの組み合わせと条件イベントの組み合わせの根本原因とされる結論イベントとの関係を示すものである。

一般的に、障害解析において根本原因を特定するためのイベント伝播モデルは、ある障害の結果発生することが予想されるイベントの組み合わせと、その根本原因を”IF-THEN”形式で記載するものとなっている。なお、汎用ルールは図８Ａ及びＢに挙げられたものに限られず、さらに多くのルールがあっても構わない。

汎用ルールは、汎用ルールの識別子となる汎用ルールIDを登録するフィールド３３４３０と、”IF-THEN”形式で記載した汎用ルールのIF部に相当する観測事象を登録するフィールド３３４１０と、”IF-THEN”形式で記載した汎用ルールのTHEN部に相当する原因事象を登録するためのフィールド３３４２０と、汎用ルールを実システムに展開し、展開ルールを生成する際に取得するトポロジを登録するためのフィールド３３４４０と、を構成項目として含んでいる。条件部３３４１０のイベントが検知されたら結論部３３４２０のイベントが根本原因であり、結論部３３４２０のステータスが正常になれば、条件部３３４１０の問題も解決しているという関係にあるものである。図８Ａ及びＢの例では、条件部３３４１０には２つのイベントが記述されているが、イベント数に制限はない。

例えば、図８Ａからは、汎用ルールIDがRule1で示される汎用ルールが、観測事象としてホストコンピュータ上の論理ボリュームのレスポンスタイムの閾値異常（関連イベント）と、ストレージ装置におけるコントローラのプロセッサ使用率の閾値異常（原因イベント）を検知したとき、ストレージ装置のコントローラのプロセッサ使用率の閾値異常が原因と結論付けるということが分かる。また、展開ルールを生成する際にはボリュームトポロジ管理表からトポロジ情報を取得する。

なお、観測事象に含まれるイベントとして、ある条件が正常であることを定義してもよい。図８Ｂに示す汎用ルールの例では、ストレージ装置のコントローラのプロセッサ使用率が正常であることを観測事象として定義している。

＜展開ルールの構成＞
図９Ａ乃至Ｄは、管理サーバ３００００が有する展開ルールリポジトリ３３５００内の展開ルールの構成例を示す図である。これらの展開ルールは、汎用ルール（図８Ａ及びＢ）にボリュームトポロジ管理表（図７）の各エントリの項目を挿入することによって生成される。

展開ルールは、展開ルールの識別子となる展開ルールIDを登録するフィールド３３５３０と、展開ルールの基となった汎用ルールの識別子となる汎用ルールIDを登録するためのフィールド３３５４０と、”IF-THEN”形式で記載した展開ルールのIF部に相当する観測事象を登録するフィールド３３５１０と、”IF-THEN”形式で記載した展開ルールのTHEN部に相当する原因事象を登録するためのフィールド３３５２０と、を構成項目として含んでいる。

例えば、図９Ａの展開ルールは、汎用ルールIDがRule1における装置種別及び装置部位種別に、図７の第１エントリのコントローラ名３２２４０とホストID３２２５０と、接続先ドライブ名３２２６０を挿入することによって生成される。そして、図９Ａからは、展開ルールIDがExRule1-1で示される展開ルールが、汎用ルールIDがRule1で示される汎用ルールを基に展開され、観測事象としてホストコンピュータ上の論理ボリュームのレスポンスタイムの閾値異常と、ストレージ装置におけるコントローラのプロセッサ稼働率の閾値異常を検知したとき、ストレージ装置のコントローラのプロセッサ使用率の閾値異常が原因と結論付けられることが分かる。

＜解析結果管理表の構成＞
図１０は、管理サーバ３００００の有する解析結果管理表３３６００の構成例を示す図である。

解析結果管理表３３６００は、障害原因解析処理において根本原因と判断されたイベントの発生した機器の識別子となる装置IDを登録するフィールド３３６１０と、イベントの発生した機器内の部位の識別子を登録するフィールド３３６２０と、閾値異常を検知したメトリックの名称を登録するフィールド３３６３０と、イベントを根本原因と判断した根拠となる展開ルールのIDを登録するフィールド３３６４０と、展開ルールにおいて条件部に記載されたイベントの発生割合を登録するフィールド３３６５０と、展開ルールにおいて条件部に記載されたイベントのうち、実際に受信したイベントのＩＤを登録するフィールド３３６６０と、該解析結果が解決済みであるかどうかを登録するフィールド３３６７０と、受信したイベント発生からイベント正常化までの時間を登録するフィールド３３６８０と、該解析結果が瞬間障害によるものであるかどうかを登録するフィールド３３６９０と、イベント発生に伴う障害解析処理を開始した日時を登録するフィールド３３６９５と、を構成項目として含んでいる。

例えば、図１０の第１段目（１つ目のエントリ）からは、展開ルールExRule1-1に基づき、管理サーバ３００００がストレージ装置SYS1の、CTL1で示されるコントローラにおけるプロセッサ稼働率の閾値異常を根本原因として判断し、その根拠としてイベントIDがEV1およびEV3で示されるイベントを受信し、すなわち条件イベントの発生割合が2/2であることが分かる。

＜その他の管理表の構成等について＞
イベント種別管理表３３７００と、性能メトリック管理表３３８００に関する説明は、後述する。

＜構成管理情報の取得処理及び、ボリュームトポロジ管理表の更新処理＞
プログラム制御モジュール３２１００は、例えばポーリング処理によって、情報取得モジュール３２２００に対し、計算機システム１内のストレージ装置２００００、ホストコンピュータ１００００およびIPスイッチ４００００から、構成管理情報を定期的に取得するよう指示する。

構成管理情報取得モジュール３２２００は、ストレージ装置２００００およびホストコンピュータ１００００およびIPスイッチ４００００から構成管理情報を取得するとともに、ボリュームトポロジ管理表３３２００を更新する。

＜一般的な装置性能情報取得処理及びイベント解析処理＞
図１１は、管理サーバ３００００の装置性能取得モジュール３２３００が実行する通常の装置性能情報取得処理を説明するためのフローチャートである。プログラム制御モジュール３２１００は、プログラムの起動時、もしくは前回の装置性能情報取得処理から一定時間経過するたびに、装置性能取得モジュール３２３００に対し、装置性能情報取得処理を実行するよう指示する。なお、当該実行指示を繰り返し出す場合は厳密に一定期間毎である必要は無く、繰り返しさえしていればよい。

装置性能情報取得モジュール３２３００は、監視対象の各装置に対し、以下の一連の処理を繰り返す。

装置性能情報取得モジュール３２３００は、まず、監視対象の各装置に対し、構成管理情報を送信するよう指示する（ステップ６１０１０）。

装置性能情報取得モジュール３２３００は、監視対象装置からの応答があったか否か判断し（ステップ６１０２０）、装置から装置性能情報の応答があれば（ステップ６１０２０でＹｅｓの場合）、取得した装置性能情報を装置性能管理表３３１００に格納する（ステップ６１０３０）。装置から構成管理情報の応答がなかった場合（ステップ６１０２０でＮｏの場合）、構成管理情報取得処理は終了する。

次に、装置性能取得モジュール３２３００は、装置性能管理表３３１００に格納された装置性能情報を参照し、各性能値に対してステップ６１０５０からステップ６１０７０の処理を繰り返す（ステップ６１０４０）。装置性能取得モジュール３２３００は、性能値が閾値を超過しているかを確認し、装置性能管理表３３１００に登録された状態を更新する（ステップ６１０５０）。そして、装置性能取得モジュール３２３００は、状態が正常から閾値異常に、或いは閾値異常から正常に変化したか否か判断し（ステップ６１０６０）、状態が変化した場合（ステップ６１０６０でＹｅｓの場合）、イベント管理表３３３００にイベントを登録する（ステップ６１０７０）。状態が変化していない場合（ステップ６１０６０でＮｏの場合）、全ての性能値に対する状態確認処理が終わっていなければ、処理はステップ６１０５０に戻る。

全ての性能値に対する上記の処理が終了した後、装置性能取得モジュール３２３００は、一連の処理で新規に追加したイベントがあるか否か判断し（ステップ６１０８０）、追加イベントがあれば（例えば、処理中に新たな異常が発生したような場合）、イベント解析処理モジュール３２５００に対し、図１２に示す障害原因解析処理を行なうよう指示する（ステップ６１０９０）。
以上が、装置性能取得モジュール３２３００が実施する装置性能情報取得処理である。

＜障害解析処理（ステップ６１０９０）の詳細＞
図１２は、管理サーバ３００００のイベント解析処理モジュール３２５００が実行する通常の障害原因解析処理（図１１のステップ６１０９０）の詳細を説明するためのフローチャートである。

イベント解析処理モジュール３２５００は、イベント管理表３３３００より、解析済フラグがYesになっていないイベントを取得する（ステップ６２０１０）。

次に、イベント解析処理モジュール３２５００は、展開ルールリポジトリ３３５００内の各展開ルールに対し、ステップ６２０３０からステップ６２０５０の処理を繰り返す（ステップ６２０２０）。イベント解析処理モジュール３２５００は、まず、展開ルールに記載された条件部に対応する各イベントについて、過去一定期間の発生件数を算出する（ステップ６２０３０）。そして、イベント解析処理モジュール３２５００は、ステップ６２０３０の処理において集計したイベント発生数が、条件部に記載された全イベントにおいて一定の比率を超過したか否か判断する（ステップ６２０４０）。超過していると判断した場合には（ステップ６２０４０でＹｅｓの場合）、イベント解析処理モジュール３２５００は、GUI表示処理モジュール３２４００に対し、根本原因なるイベントを、条件文中のイベント発生割合と共に表示するよう指示し（ステップ６２０５０）、処理を終了させる。

続いて、イベント解析処理モジュール３２５００は、解決済反映処理（図１５）を実行し（ステップ６２０６０）、その後、イベント管理表３３３００を参照して、ステップ６２０１０で取得したイベントについて解析済フラグ３３３７０をYesに設定する（ステップ６２０７０）。

最後に、イベント解析処理モジュール３２５００は、展開ルールリポジトリ内の各展開ルールのうち、確信度が０でないものを解析結果管理表３３６００に書き出す（ステップ６２０８０）。

例えば、図９Ａに示す展開ルールExRule1-1には、条件部に”ホストコンピュータHOST1における論理ボリューム（E:）のレスポンスタイムの閾値異常”と、”ストレージ装置SYS1におけるコントローラCTL1の稼働率の閾値異常”が定義されている。

そして、図７に示すイベント管理表３３３００に、”ストレージ装置SYS1におけるコントローラCTL1の稼働率の閾値異常”（発生日時：2010-01-01 15:00:00）が登録されると、イベント解析処理モジュール３２５００は、一定時間待機した後にイベント管理表３３３００を参照し、過去一定期間に発生したイベントを取得する。

次に、イベント解析処理モジュール３２５００は、展開ルールリポジトリ３３４００の展開ルールExRule1-1に記載された条件部に対応する各イベントについて、過去一定期間の発生件数を算出する。その結果、”ホストコンピュータHOST1における論理ボリューム（E:）のレスポンスタイムの閾値異常”（関連イベント）も過去一定期間に発生していることから、展開ルールExRule1-1に記載された条件部に対応する各イベント（原因イベントと関連イベント）の過去一定期間の発生数が、条件部に記載された全イベントにおいて占める割合は2/2となる。

以上のようにして算出された割合が一定値を超過した場合、イベント解析処理モジュール３２５００は、GUI表示処理モジュール３２４００に対し、根本原因となるイベントを、条件文中のイベント発生割合と共に表示するよう指示する。ここでいう一定値を例えば80%とした場合、当該具体例では、展開ルールExRule1-1の条件部の各イベントの過去一定期間の発生割合が2/2、すなわち100%であるので、解析結果がGUIに表示されることになる。

上記の処理を、展開ルールリポジトリ３３５００に定義された全ての展開ルールに対し実行することになる。

以上が、イベント解析処理モジュール３２５００が実施する障害原因解析処理である。
ところで、上述の障害原因解析処理においては、障害が短い期間に頻発すると、保存される障害解析結果の数が多くなる。しかしながら、障害解析結果には対策実行優先度に関する情報がないため、管理者が本来対策を行うべき解析結果を参照するまでの時間が長くなり、結果的に障害の解消までに要する時間が長くなるという課題が存在する。

そこで、本発明による実施形態では、解析結果を処理優先度と共に表示できるようにするために、解決済みイベント反映処理を新たに提供する。

＜解決済みイベント反映処理の内容＞
そこで、従来技術における課題を解決するため、本発明の第１の実施形態では管理サーバ３００００における解決済みイベント反映処理が追加されている。以下、当該解決済みイベント処理に必要な情報及び動作の詳細について説明する。

＜イベント種別管理表の構成＞
図１３は、管理サーバ３００００の具備するイベント種別管理表３３７００の構成例を示す図である。イベント種別管理表３３７００は、管理サーバの管理する機器の種別を登録するフィールド３３７１０と、前記機器のうち、性能情報の取得の対象となる機器内の部位を登録するフィールド３３７２０と、前記機器より取得するメトリックの名称を登録するフィールド３３７３０と、前記メトリックについて検知しうるステータス（イベントの種別）を登録するフィールド３３７４０と、前記ステータスが、異常状態の正常化を意味するものであるかを登録するフィールド３３７５０と、を構成項目として含んでいる。

例えば、図１３では、サーバ（ホストコンピュータ）のドライブのレスポンスタイムに関するステータスのうち、「閾値超過」「不明」という種別のステータスは異常状態の正常化を意味しないが、「正常」という種別のステータスは異常状態の正常化を意味することを示している。

＜性能メトリック管理表の構成＞
図１４は、管理サーバ３００００の具備する性能メトリック管理表３３８００の構成例を示す図である。性能メトリック管理表３３８００は、管理サーバの管理する機器の種別を登録するフィールド３３８１０と、前記機器のうち、性能情報の取得の対象となる機器内の部位を登録するフィールド３３８２０と、前記機器より取得するメトリックの名称を登録するフィールド３３８３０と、前記機器の取りうるOS種別を登録するフィールド３３８４０と、前記メトリックの値の算出方法を登録するフィールド３３８５０と、を構成項目として含んでいる。

図１４には、管理サーバ３００００が有する性能メトリックの具体的な値の一例が示されている。つまり、管理サーバ３００００はサーバ（ホストコンピュータ１００００）のドライブのレスポンスタイムを監視しており、その際、OSがWindows（登録商標）であるホストコンピュータ１００００については積算値と、Linuxである管理サーバ３００００については瞬間値を取得していることを示している。ここでいう「瞬間値」とは、性能値を管理対象機器において算出する際、ごく短い計測期間（例えば、アクセスした時点の性能値）における瞬間的な値を性能値として算出しているケースが挙げられる。一方、「積算値」とは、ある程度長い計測期間における平均的な値を性能値として算出する(例えば、5分間の計測時間で、性能値を積算し、それを平均する)しているケースが挙げられる。

図１４において、取得値種別３３８５０が「積算値」となっているデバイス種別及びメトリックについては、積算値を演算して障害解析処理を行うことを意味している。

＜本発明における解決済みイベント反映処理（ステップ６２０６０）の詳細＞
図１５は、第１の実施形態における、管理サーバ３００００のイベント解析処理モジュール３２５００が実施する解決済みイベント反映処理（ステップ６２０６０）を説明するためのフローチャートである。なお、本処理は、図１２に示されるように、障害原因解析処理のステップ６２０７０の直前に行われる。

イベント解析処理モジュール３２５００は、イベント管理表３３３００より、解析済フラグがYesになっていないイベントを取得する(ステップ６３０１０)。イベント解析処理モジュール３２５００は取得した全イベントに対し、以下の処理を繰り返す(ステップ６３０２０)。

イベント解析処理モジュール３２５００は、イベント種別管理表３３７００を確認し、イベントが問題解決を意味するもの（正常化されたイベント）かどうかを確認する(ステップ６３０３０)。つまり、メトリック（稼働率、レスポンスタイム、I/O量等）を絞り込み、絞り込まれたメトリックに対応するステータス（図７の３３３６０参照）が「正常」となっているか確認する。イベントが解決済みを表さない場合（ステップ６３０３０でＮｏの場合）、処理は次のイベントの処理に移る。解決済みを表すイベントの場合（ステップ６３０３０でＹｅｓの場合）、以下の処理が実行される。

イベント解析処理モジュール３２５００は、イベント管理表３３３００を確認し、前記解決済みイベントと対になる異常イベントのIDを取得する(ステップ６３０４０)。

次にイベント解析処理モジュール３２５００は、解析結果管理表３３６００を参照し、解析結果管理表に定義された各解析結果について、以下の一連の処理を繰り返す(ステップ６３０５０)。

イベント解析処理モジュール３２５００は、前記解決済みイベントと対となる異常イベントについて、解決済みフラグをYesに変更する(ステップ６３０６０)。そして、イベント解析処理モジュール３２５００は、イベント管理表３３３００を確認し、障害発生から障害解決までに要した時間を算出して、障害期間として解析結果管理表３３６００（図１０）に記録する(ステップ６３０７０)。

以上が、イベント解析処理モジュール３２５００が実施する解決済みイベント反映処理である。

以下に、解決済みイベント反映処理の具体例について説明する。なお、処理開始当初の解析結果管理表は図１０、イベント種別管理表は図１３、展開ルールExRule1-1は図９Ａに示す通りのものであるとする。

図７に示すイベント管理表に、”ストレージ装置SYS1におけるコントローラCTL1の稼働率の正常ステータス”（発生日時：2010-01-01 15:05:00）が登録されると、イベント解析処理モジュール３２５００はイベント管理表を参照し、過去一定期間に発生したイベントを取得する。

次に、イベント解析処理モジュール３２５００は、上記イベントについて、イベント種別管理表３３７００を確認し、イベントが問題解決を意味するものかどうかを確認する。イベント種別管理表３３７００を確認すると、「ストレージ装置のコントローラの稼働率の正常ステータス」は、イベントが解決済みであることを表すステータスであることが分かる。

また、イベント解析処理モジュール３２５００は、イベント管理表３３３００を確認し、前記解決済みイベントと対になる異常イベントのIDを取得する。イベント管理表３３３００を参照すると、”ストレージ装置SYS1におけるコントローラCTL1の稼働率の正常ステータス”（発生日時：2010-01-01 15:05:00）の直前に、”ストレージ装置SYS1におけるコントローラCTL1の稼働率の閾値異常”（発生日時：2010-01-01 15:00:00）が発生しており、これが対になる異常イベントと分かる。また、そのイベントIDは”EV1”であると分かる。

次に、イベント解析処理モジュール３２５００は解析結果管理表３３６００を参照し、解析結果管理表３３６００に定義された解析結果に含まれるイベントのうち、イベントIDが”EV1”で示されるイベントについて、解決済みフラグをYesに変更する。また、障害発生から障害解決までに要した時間を障害期間として記録する。受信イベントEV1は発生から5分で解決しており、これを障害期間として登録する。

続いて、イベント管理表３３３００に、”ホストコンピュータHOST1におけるドライブ(E:)のレスポンスタイムの正常ステータス”（発生日時：2010-01-01 15:10:00）が登録されると、イベント解析処理モジュール３２５００はこれと対になるイベントEV3についても解決済みフラグをYesに変更する。また、障害発生から障害解決までに要した時間を障害期間として解析結果管理表３３６００に記録する。当該具体例では、受信イベントEV3は発生から10分で解決しており、これが障害期間として解析結果管理表３３６００に記録される。

＜障害解析結果表示画面の構成＞
図１６は、管理サーバ３００００がユーザ（管理者）に対して表示する、障害解析結果表示画面の表示例７１０００を示す図である。

障害解析結果表示画面７１０００では、解析結果管理表に定義された解析結果のうち、受信したイベントが全て解決した解析結果を区別して表示し、障害期間を合わせて表示する（テーブル７１０２０）。１つの解析結果に複数の受信イベントを含む場合は、各イベントの解決時間のうち最も長いものを表示する。

受信したイベントが全て解決していない解析結果は、別のテーブルに表示される（テーブル７１０１０）。

＜解決済みイベント反映処理の効果＞
以上、第１の実施形態によれば、管理サーバ３００００の管理ソフトウェアは、図１２に示す障害原因解析処理の後、異常状態にあった機器のステータス正常化を検知したとき、障害解析結果のうち、その導出根拠となった機器異常状態が解消したものについて他の解析結果と区別してGUIに表示する。障害解析結果が複数の障害イベントにより導出された場合は、全ての障害イベントの正常化を確認した時点で、他の障害解析結果とは区別してGUIに表示する。その結果、ユーザが解析結果の対応優先度を容易に判断でき、解析結果確認に要する負荷を軽減できる。

（２）第２の実施形態
第２の実施形態は、管理ソフトウェア（例えば、管理サーバ３００００に含まれる）による瞬間障害イベント反映処理に関するものである。システム構成や各装置の構成は第１の実施形態と同じであるので、説明は省略する。

＜瞬間障害イベント反映処理の詳細＞
本実施形態では、管理サーバ３００００が、瞬間障害イベント反映処理を実行する。なお、管理サーバ３００００が有する構成管理情報は、第１の実施形態と同じである。

図１７は、第２の実施形態における、管理サーバ３００００のイベント解析処理モジュール３２５００が実行する瞬間障害イベント反映処理の詳細を説明するためのフローチャートである。当該瞬間障害イベント反映処理は、図１２の解決済みイベント反映処理（ステップ６２０６０）に代わって実行されるものであり、図１２に示されるように、障害原因解析処理のステップ６２０７０の直前に行われる。

図１７において、まず、イベント解析処理モジュール３２５００は、イベント管理表３３３００より、解析済フラグがYesになっていないイベントを取得する(ステップ６４０１０)。イベント解析処理モジュール３２５００は取得した全イベントに対し、以下の処理を繰り返す(ステップ６４０２０)。

イベント解析処理モジュール３２５００はイベント種別管理表３３７００を確認し、イベントが問題解決を意味するものかどうかを確認する(ステップ６４０３０)。イベントが解決済みを表さない場合は次のイベントの処理に移る。解決済みを表すイベントの場合は、以下の処理を行なう。

つまり、イベント解析処理モジュール３２５００は、イベント管理表３３３００を確認し、前記解決済みイベントと対になる異常イベントのIDを取得する(ステップ６４０４０)。

次に、イベント解析処理モジュール３２５００は、解析結果管理表３３６００を参照し、解析結果管理表に定義された各解析結果について、以下の一連の処理を繰り返す(ステップ６４０５０)。

また、イベント解析処理モジュール３２５００は、前記解決済みイベントと対となる異常イベントについて、解決済みフラグをYesに変更する(ステップ６４０６０)。

そして、イベント解析処理モジュール３２５００は、イベント管理表３３３００を確認し、障害発生から障害解決までに要した時間を算出して、障害期間として解析結果管理表３３６００に記録する(ステップ６４０７０)。

続いて、イベント解析処理モジュール３２５００は、解析結果に含まれる受信イベントが１つで、メトリックが瞬間値で、かつ前記算出した障害期間が、図１１に示す装置性能情報取得処理において装置の性能を取得する間隔と同一もしくは短いかどうかを確認する(ステップ６４０８０)。なお、ステップ６４０８０において解析結果に含まれる受信イベントが１つであるかどうかを確認する理由は、１つの展開ルール（図９参照）中に記載された障害イベント（条件部のイベント）が単独で発生した場合は、その障害イベントは接続された他のITシステムに影響を及ぼさないイベントである可能性が高いためである。つまり、条件部のイベントが１つだけしか発生していない場合には、単に瞬間的に障害が発生しただけである可能性が高いということである。一方、１つの展開ルール中に記載された障害イベントが同時に複数発生した場合、それらの障害イベント間に因果関係があり、対策が必要な障害が発生している可能性が高いからである。なお、ここではイベントが１つしか発生していないか否かで判断しているが、イベント発生割合（確信度）が障害解析結果に用いられる所定閾値未満であるか否かによって判断しても良い。また、ステップ６４０８０において、障害期間が装置の性能を取得する間隔と同一もしくは短いかどうかを確認する理由は、管理サーバが監視対象装置における閾値異常を認識した後、次の性能取得のタイミングで既に閾値異常が解消していた場合、最初に認識した閾値異常は突発的なものであった可能性が高いからである。

ステップ６４０８０で解析結果が前記全ての条件を満たさないと判断された場合は、次の解析結果の処理に移る。一方、ステップ６４０８０で解析結果が全ての条件を満たすと判断された場合は、イベント解析処理モジュール３２５００は、解析結果の瞬間障害フラグをYesに変更する(ステップ６４０９０)。このようにフラグをYesに変更するのは、図１８のように、解析結果を瞬間障害か否かによって区別して表示するためである。

以上が、イベント解析処理モジュール３２５００が実施する瞬間障害イベント反映処理である。

以下に、瞬間障害イベント反映処理の具体例を示す。なお、処理開始当初の解析結果管理表は図１０、イベント種別管理表は図１３、性能メトリック管理表は図１４、展開ルールExRule1-1は図９Ａに示すとおりであるものとする。

図７に示すイベント管理表に、”ストレージ装置SYS1におけるコントローラCTL1の稼働率の正常ステータス”（発生日時：2010-01-01 16:05:00）が登録されると、イベント解析処理モジュール３２５００はイベント管理表３３３００（図７）を参照し、過去一定期間に発生したイベントを取得する。

次に、イベント解析処理モジュール３２５００は、上記イベントについて、イベント種別管理表３３７００を確認し、イベントが問題解決を意味するものかどうかを確認する。イベント種別管理表３３７００を確認すると、「ストレージ装置のコントローラの稼働率の正常ステータス」は、イベントが解決済みであることを表すステータスであることが分かる。

そして、イベント解析処理モジュール３２５００は、イベント管理表３３３００を確認し、上記解決済みイベントと対になる異常イベントのIDを取得する。イベント管理表３３３００を参照すると、”ホストコンピュータHOST1(OS種別：Linux)におけるドライブ(E:)のレスポンスタイムの正常ステータス”（発生日時：2010-01-01 16:05:00）の直前に、” ホストコンピュータHOST1(OS種別：Linux)におけるドライブ(E:)のレスポンスタイムの正常ステータス”（発生日時：2010-01-01 16:00:00）が発生しており、これが対になる異常イベントと分かる。また、そのイベントIDは”EV5”であると分かる。

さらに、イベント解析処理モジュール３２５００は、解析結果管理表３３６００を参照し、解析結果管理表３３６００に定義された解析結果に含まれるイベントのうち、イベントIDが”EV5”で示されるイベントについて、解決済みフラグをYesに変更する。また、障害発生から障害解決までに要した時間を障害期間として記録する。受信イベントEV5は発生から5分で解決しており、これを障害期間として解析結果管理表３３６００に登録する。

続いて、イベント解析処理モジュール３２５００は、上記解析結果に含まれる受信イベントが１つで、メトリックが瞬間値で、かつ障害期間が一定値以下かどうかを確認する。ここでは障害期間が10分未満であれば条件を満たすものとすると、この例での障害期間は5分であるので条件を満たす。また、図１４に示す性能メトリック管理表を参照すると、OS種別がLinuxであるホストコンピュータにおけるドライブのレスポンスタイムは「瞬間値」であることが分かる。そのため上記解析結果は条件を全て満たすため、解析結果管理表３３６００の瞬間障害フラグ３３６９０をYesに変更する。

＜障害解析結果表示画面の構成＞
図１８は、管理サーバ３００００が管理者（ユーザ）に対し表示する、障害解析結果表示画面の表示例７１０００を示す図である。

障害解析結果表示画面７１０００では、解析結果管理表３３６００に定義された解析結果のうち、解析結果の瞬間障害フラグがYesであるものが区別して表示され、また、障害期間が併せて表示される（テーブル７１０３０）。１つの解析結果に複数の受信イベントを含む場合は、各イベントの解決時間のうち最も長いものが表示される。

＜瞬間障害イベント反映処理の効果＞
以上のように、システム管理ソフトウェアは、管理対象機器において業務に支障をきたす事態となっていないにもかかわらず発生し、発生後すぐに正常化する障害イベントを障害解析部が受信した時、異常状態にあった機器のステータス正常化を検知したとき、その導出根拠となった機器異常状態が全て解消した時点で、障害原因候補を確信度と共に障害解析結果として保存する。また、障害解析結果について他の解析結果と区別してGUIに表示する。その結果、ユーザが解析結果の対応優先度を容易に判断でき、解析結果確認に要する負荷を軽減できる。

（３）第３の実施形態
第３の実施形態は、管理ソフトウェア（例えば、管理サーバ３００００に含まれる）による障害解析結果の対処優先度設定処理に関するものである。システム構成や各装置の構成は、図１９に示す解析結果管理表３３６００を除いて第１の実施形態と同じであるので、説明は省略する。

＜解析結果管理表の構成＞
図１９は、第３の実施形態による、管理サーバ３００００が有する解析結果管理表３３６００の構成例を示す図である。

解析結果管理表３３６００は、解析結果に対するユーザの処理優先度を登録するフィールド３３６９１を構成項目として含んでいる。その他の構成項目は、図１０に示す解析結果管理表３３６００の構成項目と同じである。

本実施形態では、解析結果に付与された処理優先度が大きいほどユーザによる対処が早急に求められるものとし、最大値は１０、最小値は０とする。また、解析結果が解析結果管理表３３６００に登録された時点では処理優先度は１０に設定されているものとする。

＜解決済みイベント反映処理＞
図２０は、第３の実施形態において、管理サーバ３００００のイベント解析処理モジュール３２５００が実行する障害解析結果の対処優先度設定処理を説明するためのフローチャートである。なお、本処理は、図１２に示される障害原因解析処理のステップ６２０７０の直前に行われ、図１２の解決済みイベント反映処理（ステップ６２０６０）に代わって実行されるものである。

イベント解析処理モジュール３２５００は、イベント管理表３３３００より、解析済フラグがYesになっていないイベントを取得する(ステップ６５０１０)。イベント解析処理モジュール３２５００は取得した全イベントに対し、以下の処理を繰り返す(ステップ６５０２０)。

まず、イベント解析処理モジュール３２５００は、イベント種別管理表３３７００を参照し、処理対象のイベントのステータス３３３６０が問題解決を意味するものかどうかどうかを確認する(ステップ６５０３０)。例えば、イベント管理表３３３００において、コントローラの稼働率が閾値異常のステータスを示している場合には、当該イベントは解決済みでないということになる。そして、イベント解析処理モジュール３２５００は、イベントが解決済みを表さない場合（ステップ６５０３０でＮｏの場合）は次のイベントの処理を移行させ、解決済みを表すイベントの場合（ステップ６５０３０でＹｅｓの場合）は処理をステップ６５０４０に移行する。

イベント解析処理モジュール３２５００は、イベント管理表３３３００を確認し、上記解決済みイベントと対になる異常イベントのIDを取得する(ステップ６５０４０)。

次に、イベント解析処理モジュール３２５００は、解析結果管理表３３６００を参照し、解析結果管理表３３６００に定義された各解析結果について、以下の一連の処理を繰り返す(ステップ６５０５０)。

イベント解析処理モジュール３２５００は、上記解決済みイベントと対となる異常イベントについて、解決済みフラグをYesに変更する(ステップ６５０６０)。

また、イベント解析処理モジュール３２５００は、イベント管理表３３３００を確認し、障害発生から障害解決までに要した時間を算出して、障害期間として解析結果管理表３３６００に記録する(ステップ６５０７０)。

次に、イベント解析処理モジュール３２５００は、解析結果の含まれる障害イベントの解決した数に基づいて対処優先度を算出し、解析結果管理表３３６００に記録する(ステップ６５０８０)。例えば、解析結果の含まれる障害イベント２個のうち１個が解決済みの場合、「１０×(1/2)＝５」と計算して対処優先度は５となる。また、解析結果の含まれる障害イベントの全てが解決済みである場合の処理優先度は０、障害イベントの全てが未解決である場合の処理優先度は１０とする。このように、処理優先度は、条件部の障害イベントの数及び解決済みの障害イベントの数によって、０から１０の値となる。

以上が、イベント解析処理モジュール３２５００が実施する障害解析結果の対処優先度設定処理である。

＜障害解析結果表示画面の構成＞
図２１は、管理サーバ３００００がユーザに対し表示する、障害解析結果表示画面の表示例７１０００を示す図である。

障害解析結果表示画面７１０００では、解析結果管理表に定義された解析結果を、対処優先度とともに表示する（テーブル７１０１０）。

＜障害解析結果の対処優先度設定処理の効果＞
以上、第３の実施形態では、管理者（ユーザ）が解析結果の対処優先度を容易に判断できるための方法の１つとして、障害解析結果表示画面７１０００において、障害解析結果の対処優先度を表示する方法について述べた。その他、ユーザによる解析結果への対処優先度を算出するための基準として、以下の方法が考えられる。
（Ａ）解析結果に基づき根本原因と判断された障害が、ユーザによる対処が困難な障害である場合、他の解析結果より処理優先度が低いものとする。
（Ｂ）解析結果に基づき根本原因と判断された障害が、多重化構成を組んでいる機器において発生した障害である場合、他の解析結果より処理優先度が低いものとする。

以上のように解析結果の対処優先度の表示を行うことにより、ユーザが解析結果の対処優先度を容易に判断でき、解析結果確認作業に要する負荷を軽減できる。なお、この優先度表示は、第１の実施形態の区別表示と組み合わせて実現することが可能である。つまり、第１の実施形態において解決済解析結果と区別表示された未解決解析結果について、優先度を演算し、その優先度情報を併せて表示するようにしても良い。

（４）まとめ
本実施形態では、各ノード装置の性能値から異常状態を検知し、その解析結果（異常状態の確信度を演算）を管理者に提示するが、その異常状態が特別な対処を行わなくても時間経過により正常状態に変化した場合、その確信度の値を変えることなく、正常化したことを意味するフラグを付与して解析結果を管理者に提示するようにしている。これは、確信度が解析結果に対する評価であるため時間経過とともにその評価を変えてはいけないからである。このようにすることにより、解決済解析結果と未解決解析結果とを区別して表示することができ、また、障害対処すべき結果を優先度情報と共に表示することができるようになる。よって、管理者としては、より明確に対処すべき障害を効率よく絞り込みことができるようになる。

また、一時的に障害となっているに過ぎないと考えられる瞬間障害解析結果を他の障害解析結果とは区別して管理者に提示している（例えば、図１８参照）。このようにすることにより、瞬間障害解析結果に示された障害についての対処を後回しにすることができ、管理者にとっては非常に効率的に計算機システムを管理することが可能となる。

なお、本発明は、実施形態の機能を実現するソフトウェアのプログラムコードによっても実現できる。この場合、プログラムコードを記録した記憶媒体をシステム或は装置に提供し、そのシステム或は装置のコンピュータ（又はＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出す。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコード自体、及びそれを記憶した記憶媒体は本発明を構成することになる。このようなプログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどが用いられる。

また、プログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ（オペレーティングシステム）などが実際の処理の一部又は全部を行い、その処理によって前述した実施の形態の機能が実現されるようにしてもよい。さらに、記憶媒体から読み出されたプログラムコードが、コンピュータ上のメモリに書きこまれた後、そのプログラムコードの指示に基づき、コンピュータのＣＰＵなどが実際の処理の一部又は全部を行い、その処理によって前述した実施の形態の機能が実現されるようにしてもよい。

また、実施の形態の機能を実現するソフトウェアのプログラムコードを、ネットワークを介して配信することにより、それをシステム又は装置のハードディスクやメモリ等の記憶手段又はＣＤ−ＲＷ、ＣＤ−Ｒ等の記憶媒体に格納し、使用時にそのシステム又は装置のコンピュータ（又はＣＰＵやＭＰＵ）が当該記憶手段や当該記憶媒体に格納されたプログラムコードを読み出して実行するようにしても良い。

１００００：サーバ
２００００：ストレージ装置
３００００：管理サーバ
３５０００：WEBブラウザ起動サーバ
４００００：IPスイッチ
４５０００：ネットワーク

Claims (14)

1. 監視の対象となるノード装置と、ネットワークを介して前記ノード装置に接続され、前記ノード装置を監視及び管理する管理システムと、を有する計算機システムの管理方法であって、
   前記管理システムが、前記ノード装置の処理性能を示す処理性能値を取得し、当該取得した処理性能値から前記ノード装置の状態をイベントとして検知し、
   前記管理システムが、前記検知した状態を、前記ノード装置で発生し得る１つ以上の条件イベントの組み合わせと前記条件イベントの組み合わせの根本原因とされる結論イベントとの関係を示す解析ルールに適用して前記条件イベントの発生割合を算出することにより、前記ノード装置における障害の発生が前記結論イベントに起因する可能性の程度を示す情報である確信度を算出し、
   前記管理システムが、前記確信度から前記ノード装置に障害が発生したか否か判断し、
   前記管理システムが、前記障害が発生したと判断されたノード装置について、前記確信度の情報は変更せずに、前記状態が異常のままのノード装置の障害解析結果である未解決障害解析結果と前記状態が異常から正常に変化したノード装置の障害解析結果である解決済障害解析結果とを表示画面に表示する、
   ことを特徴とする計算機システムの管理方法。
2. 請求項１において、
   前記管理システムは、前記未解決障害解析結果と前記解決済障害解析結果とを区別して前記表示画面に表示することを特徴とする計算機システムの管理方法。
3. 請求項１又は２において、さらに、
   前記管理システムが、前記未解決障害解析結果及び前記解決済障害解析結果に対して、処理優先度を併せて前記表示画面に表示することを特徴とする計算機システムの管理方法。
4. 請求項３において、
   前記管理システムは、前記未解決障害解析結果において、前記条件イベントのいくつが解決済であるかに基づいて、前記処理優先度を算出することを特徴とする計算機システムの管理方法。
5. 請求項１乃至４の何れか１項において、さらに、
   前記管理システムが、前記解決済障害解析結果について、前記状態が異常から正常に変化するまでの時間を示す障害期間を算出し、当該障害期間を併せて前記表示画面に表示することを特徴とする計算機システムの管理方法。
6. 請求項５において、
   前記管理システムは、前記障害期間を算出する際に、前記確信度が所定値未満であるか判断し、さらに、前記ノード装置の前記処理性能値の種類を確認し、当該処理性能値の種類が瞬間的に得られた瞬間値であるか、或いは所定期間の性能値を積算して得られた積算値であるかを判断し、かつ、前記障害期間が所定値以下であるかを判断し、前記確信度が所定値未満で、前記処理性能値の種類が前記瞬間値で、かつ前記障害期間が所定値以下の前記解決済障害解析結果を、他の解決済障害解析結果及び前記未解決障害解析結果と区別して前記表示画面に表示することを特徴とする計算機システムの管理方法。
7. 請求項１乃至６の何れか１項において、
   前記ノード装置は、複数のホスト計算機と複数のストレージ装置を含み、
   前記管理システムは、前記ノード装置の構成デバイス毎に前記ノード装置の前記処理性能値を管理し、
   前記管理システムは、前記ノード装置の構成デバイスの処理性能を示す構成デバイス性能値を取得し、当該取得した構成デバイス性能値から前記ノード装置の前記構成デバイスの状態を検知し、
   前記管理システムは、前記検知した構成デバイスの状態を前記解析ルールに適用し、前記確信度を算出して、当該確信度が所定値以上の場合に前記ノード装置に障害が発生したと判断し、
   前記管理システムは、前記未解決障害解析結果と前記解決済障害解析結果とを区別して前記表示画面に表示すると共に、前記未解決障害解析結果及び前記解決済障害解析結果に対して、前記条件イベントのいくつが解決済であるかに基づいて算出した処理優先度を併せて前記表示画面に表示し、
   前記管理システムは、さらに、前記解決済障害解析結果について、前記状態が異常から正常に変化するまでの時間を示す障害期間を算出し、当該障害期間を併せて前記表示画面に表示すると共に、前記障害期間を算出する際に、前記確信度が所定値未満であるか判断し、さらに、前記ノード装置の前記処理性能値の種類を確認し、当該処理性能値の種類が瞬間的に得られた瞬間値であるか、或いは所定期間の性能値を積算して得られた積算値であるかを判断し、かつ、前記障害期間が所定値以下であるかを判断し、前記確信度が所定値未満で、前記処理性能値の種類が前記瞬間値で、かつ前記障害期間が所定値以下の前記解決済障害解析結果を、他の解決済障害解析結果及び前記未解決障害解析結果と区別して前記表示画面に表示する、
   ことを特徴とする計算機システムの管理方法。
8. 監視対象のノード装置とネットワークを介して接続され、前記ノード装置を管理する管理システムであって、
   前記ノード装置の処理性能を示す処理性能値を取得し、当該取得した処理性能値から前記ノード装置の状態をイベントとして検知するプロセッサと、
   前記ノード装置で発生し得る１つ以上の条件イベントの組み合わせと前記条件イベントの組み合わせの根本原因とされる結論イベントとの関係を示す解析ルールを格納するメモリと、を有し、
   前記プロセッサは、
   前記検知した状態を前記解析ルールに適用して前記条件イベントの発生割合を算出することにより、前記ノード装置における障害の発生が前記結論イベントに起因する可能性の程度を示す情報である確信度を算出し、
   前記確信度から前記ノード装置に障害が発生したか否か判断し、
   前記障害が発生したと判断されたノード装置について、前記確信度の情報は変更せずに、前記状態が異常のままのノード装置の障害解析結果である未解決障害解析結果と前記状態が異常から正常に変化したノード装置の障害解析結果である解決済障害解析結果とを表示画面に表示する、
   ことを特徴とする管理システム。
9. 請求項８において、
   前記プロセッサは、前記未解決障害解析結果と前記解決済障害解析結果とを区別して前記表示画面に表示することを特徴とする管理システム。
10. 請求項８又は９において、
    前記プロセッサは、前記未解決障害解析結果及び前記解決済障害解析結果に対して、処理優先度を併せて前記表示画面に表示することを特徴とする管理システム。
11. 請求項１０において、
    前記プロセッサは、前記未解決障害解析結果において、前記条件イベントのいくつが解決済であるかに基づいて、前記処理優先度を算出することを特徴とする管理システム。
12. 請求項８乃至１１の何れか１項において、
    前記プロセッサは、前記解決済障害解析結果について、前記状態が異常から正常に変化するまでの時間を示す障害期間を算出し、当該障害期間を併せて前記表示画面に表示することを特徴とする管理システム。
13. 請求項１２において、
    前記プロセッサは、前記障害期間を算出する際に、前記確信度が所定値未満であるか判断し、さらに、前記ノード装置の前記処理性能値の種類を確認し、当該処理性能値の種類が瞬間的に得られた瞬間値であるか、或いは所定期間の性能値を積算して得られた積算値であるかを判断し、かつ、前記障害期間が所定値以下であるかを判断し、前記確信度が所定値未満で、前記処理性能値の種類が前記瞬間値で、かつ前記障害期間が所定値以下の前記解決済障害解析結果を、他の解決済障害解析結果及び前記未解決障害解析結果と区別して前記表示画面に表示することを特徴とする管理システム。
14. 請求項８乃至１３の何れか１項において、
    前記ノード装置は、複数のホスト計算機と複数のストレージ装置を含み、
    前記プロセッサは、
    前記ノード装置の構成デバイス毎に前記ノード装置の前記処理性能値を管理し、
    前記ノード装置の構成デバイスの処理性能を示す構成デバイス性能値を取得し、当該取得した構成デバイス性能値から前記ノード装置の前記構成デバイスの状態を検知し、
    前記検知した構成デバイスの状態を前記解析ルールに適用し、前記確信度を算出して、当該確信度が所定値以上の場合に前記ノード装置に障害が発生したと判断し、
    前記未解決障害解析結果と前記解決済障害解析結果とを区別して前記表示画面に表示すると共に、前記未解決障害解析結果及び前記解決済障害解析結果に対して、前記条件イベントのいくつが解決済であるかに基づいて算出した処理優先度を併せて前記表示画面に表示し、
    さらに、前記解決済障害解析結果について、前記状態が異常から正常に変化するまでの時間を示す障害期間を算出し、当該障害期間を併せて前記表示画面に表示すると共に、前記障害期間を算出する際に、前記確信度が所定値未満であるか判断し、さらに、前記ノード装置の前記処理性能値の種類を確認し、当該処理性能値の種類が瞬間的に得られた瞬間値であるか、或いは所定期間の性能値を積算して得られた積算値であるかを判断し、かつ、前記障害期間が所定値以下であるかを判断し、前記確信度が所定値未満で、前記処理性能値の種類が前記瞬間値で、かつ前記障害期間が所定値以下の前記解決済障害解析結果
    を、他の解決済障害解析結果及び前記未解決障害解析結果と区別して前記表示画面に表示する、ことを特徴とする管理システム。

Images