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

Description

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

計算機システムを管理する場合、例えば特許文献１に示されるように、システム内で検知した複数の障害もしくはその兆候の中から、原因となる事象（イベント）を検出することが行われている。より具体的に、特許文献１では、管理ソフトウェアを用いて、管理下機器における性能値の閾値超過をイベント化し、イベントDBに情報を蓄積する。

また、この管理ソフトウェアは、管理下機器において発生した複数の障害イベントの因果関係を解析するための解析エンジンを持っている。この解析エンジンは、管理下機器のインベントリ情報を持つ構成DBにアクセスして、I/O経路上のパス上にある機器内構成要素を認識し、ホスト上の論理ボリュームの性能に影響を与えうる構成要素を「トポロジ」と呼ばれる一グループとして認識する。そして、解析エンジンは、イベントが発生すると各トポロジに対し、事前に定められた条件文と解析結果からなる解析ルールを適用して展開ルールを構築する。この展開ルールには、他装置における性能低下の原因である原因イベントと、それによって引き起こされている関連イベント群が含まれる。具体的には、ルールのTHEN部に障害の原因として記載されているイベントが原因イベント、IF部に記載されているイベントのうち原因イベント以外のものが関連イベントである。

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

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

しかしながら、このような従来の障害解析機能においては、障害が短い期間に頻発すると、保存される障害解析結果の数が多くなってしまい、管理者としてはどれが本当に対処すべき障害なのか判断できないことがある。このため、監視対象の機器における障害を解消するまでに要する時間が長くなってしまい、事態をより深刻にしてしまうことがある。

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

上記課題を解決するために、本発明では、障害原因解析処理の後に、得られた原因候補を影響範囲ごとに分類する。原因候補が関連する障害イベントによって分類してグループ化し、それらを区別してGUI表示する。より具体的には、まず障害原因解析の結果として原因候補群を推論したとき、導出根拠となる機器異常状態が同一である原因候補群を分類する。そして同一の機器異常状態によって導出された原因候補群を、同一の障害を解決するための原因候補の集合であるとみなし、それらを分類してGUI表示する。

即ち、本発明によれば、管理システムが、ノード装置の処理性能を示す処理性能値を取得し、当該取得した処理性能値から前記ノード装置に障害が発生したことを検知する。そして、管理システムが、検知した障害を、ノード装置で発生し得る１つ以上の条件イベントの組み合わせと条件イベントの組み合わせの障害原因とされる結論イベントとの関係を示す解析ルールに適用し、ノード装置における障害の発生の可能性を示す情報である確信度を算出する。さらに、管理システムは、複数の障害原因とされる結論イベントの１つを起点原因候補として選択し、起点原因候補に関係する条件イベントを抽出する。また、管理システムは、抽出された条件イベントに関係する結論イベントであって、起点原因候補の結論イベントとは異なる１つ又は複数の障害原因とされる結論イベントを関連原因候補として選択し、起点原因候補の結論イベントと前記関連原因候補の結論イベントを、他の結論イベントとは別個に分類処理する。その分類された結論イベントは、表示画面にGUI表示される。

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

本発明によれば、障害解析結果を管理者（ユーザ）に提示する際、推論した障害原因候補を、それによって解決される障害にかかわる障害イベントによって分類して表示することにより、管理者が解析結果の対応優先度を容易に判断でき、解析結果確認と障害対応に要する負荷を軽減することができる。

計算機システムの物理構成例を示す図である。 ホストコンピュータの詳細な構成例を示す図である。 ストレージ装置の詳細な構成例を示す図である。 管理サーバの詳細な構成例を示す図である。 管理サーバが有する装置性能管理表の構成例を示す図である。 管理サーバが有するボリュームトポロジ管理表の構成例を示す図である。 管理サーバが有するイベント管理表の構成例を示す図である。 管理サーバが有する汎用ルールの構成例（１）を示す図である。 管理サーバが有する汎用ルールの構成例（２）を示す図である。 管理サーバが有する展開ルールの構成例（１）を示す図である。 管理サーバが有する展開ルールの構成例（２）を示す図である。 管理サーバが有する展開ルールの構成例（３）を示す図である。 管理サーバが有する展開ルールの構成例（４）を示す図である。 管理サーバが有する展開ルールの構成例（５）を示す図である。 管理サーバが有する展開ルールの構成例（６）を示す図である。 管理サーバが有する展開ルールの構成例（７）を示す図である。 管理サーバが有する展開ルールの構成例（８）を示す図である。 管理サーバが有する解析結果管理表の構成例を示す図である。 管理サーバが実施する性能情報取得処理の概要を説明するためのフローチャートである。 管理サーバが実施する障害解析処理を説明するためのフローチャートである。 管理サーバが実施する原因候補分類処理を説明するためのフローチャートである。 第１の実施形態において、管理サーバが表示する障害解析結果画面の構成例を示す図である。 第２の実施形態において、管理者が分類された原因候補を選択した際の管理サーバの処理を説明するためのフローチャートである。 第２の実施形態に置いて、管理サーバが実施する原因候補再分類処理を説明するためのフローチャートである。 第２の実施形態において、管理サーバが表示する障害解析結果画面の構成例を示す図である。

本発明の実施形態は、ITシステム障害解消のための障害原因解析に関するものである。前述のように、従来技術でも障害原因候補を管理者に提示して障害に対処可能なようにしている。ところが、複数の障害原因によって多数の原因候補が発生した場合、実際に発生しているどの障害原因にどの原因候補が関連するのかを把握しないと、効率的に障害対応を行うことができない。例えば、確信度に基づき、上位数候補に対して障害対応を実施したとしても、それらの候補は実際には同じ装置に発生した障害に起因する障害原因の候補かもしれない。また、他の装置にも障害が発生していて、それに起因する障害原因候補が低い優先度で提示されていたのならば、上位数候補分と同じレベルでその候補についても対応すべきである。しかし、障害原因解析を行うソフトウェアには、複数の障害原因によって多数の原因候補が発生した場合に、それらを原因候補の影響する範囲に応じてグループ化する方法がない。このため管理者は、どの原因候補に優先的に対応すべきか、判断することが困難である。つまり、従来の障害解析結果にはどの障害原因候補が関連しているかを示す情報がないため、管理者が優先的に対策を行うべき解析結果を参照するまでの時間が長くなり、結果的に障害の解消までに要する時間が長くなってしまう。

そこで、本発明の実施形態では、より信頼度が高く優先的に対処すべき原因候補を提示するための機能を提供する。

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

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

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

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

また本明細書で記載する実施形態においては、管理対象とするシステムの規模については言及しない。しかし、システムが大規模になればなるほど、同時多発的に障害が複数個所で発生する可能性が高くなる。そのため、大規模システムを対象に本発明を適用した場合には、本発明の効果をより享受できる。

（１）第１の実施形態
第１の実施形態は、管理ソフトウェア（例えば、管理サーバに含まれる）による障害原因候補表示処理に関するものである。

＜システム構成＞
図１は、本発明による計算機システムの物理的構成を示す図である。当該計算機システム１は、ストレージ装置２００００と、ホストコンピュータ１００００と、管理サーバ３００００と、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要求を指す）を受信し、受信したアクセス要求に応じて記憶デバイスへの読み書きを行うストレージコントローラと、記憶領域を提供する前述の記憶デバイスを含めば、図３及び上記説明以外の構成でもよく、例えば、ストレージコントローラと記憶領域を提供する記憶デバイスが別な筐体に格納されていてもよい。即ち、図３の例では管理メモリ２３０００とコントローラ２５０００及び２５１１０とが別個の存在として設けられているが、それらが一体となったストレージコントローラとして構成しても良い。また、本明細書ではストレージコントローラと記憶デバイスが同じ筐体に存在する場合または別な筐体を含む表現として、ストレージ装置をストレージシステムと呼び変えても良い。

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

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

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

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

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

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

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

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

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

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

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

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

例えば、図６の第１行目（１つ目のエントリ）からは、ストレージ装置SYS1のボリュームVOL1を、LU1で示される論理ユニットとしてホストコンピュータに提供し、 CTL1で示されるストレージ側のコントローラを介してホストコンピュータHOST1と接続し、ホスト上で論理ボリューム（/var）として認識されていることが分かる。

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

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

例えば、図７の第１行目（１つ目のエントリ）からは、管理サーバ３００００が、ストレージ装置SYS1の、CTL1で示されるコントローラにおけるプロセッサ稼働率の閾値異常を検知し、そのイベントIDはＥＶ１であることが分かる。

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

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

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

例えば、図８Ａからは、汎用ルールIDがRule1で示される汎用ルールが、観測事象としてホストコンピュータ上の論理ボリュームのレスポンスタイムの閾値異常（関連イベント）と、ストレージ装置におけるコントローラの稼働率（プロセッサ使用率）の閾値異常（原因イベント）と、ストレージ装置におけるLUの単位時間のI/O量の閾値異常 (関連イベント)を検知したとき、ストレージ装置のコントローラの稼働率（プロセッサ使用率）のボトルネックが障害の原因であると結論付けられるということが分かる。

なお、展開ルールを生成する際にはボリュームトポロジ管理表からトポロジ情報を取得する。また、観測事象に含まれるイベントとして、ある条件が正常であることを定義してもよい。図８Ｂに示す汎用ルールの例では、ストレージ装置のコントローラのプロセッサ使用率や、ストレージ装置におけるLUの単位時間のI/O量が正常であることを観測事象として定義している。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

次に、イベント解析処理モジュール３２５００は、展開ルールリポジトリ３３５００内の各展開ルールに対し、ステップ６２０２０からステップ６２０４０の処理を繰り返す（ステップ６２０２０）。イベント解析処理モジュール３２５００は、まず、展開ルールに記載された条件部に対応する各イベントについて、過去一定期間の発生件数を算出する（ステップ６２０３０）。

続いて、イベント解析処理モジュール３２５００は、原因候補分類処理（図１３）を実行する（ステップ６２０５０）。そして、イベント解析処理モジュール３２５００は、ステップ６２０３０の処理において集計したイベント発生数が、条件部に記載された全イベントにおいて一定の比率を超過したか否か判断し、超過している場合には GUI表示処理モジュール３２４００に対し、障害原因になるイベントを、条件文中のイベント発生割合と共に、ステップ６２０５０で行った分類に基づいて表示するよう指示する（ステップ６２０６０）。その後イベント管理表３３３００を参照して、ステップ６２０１０で取得したイベントについて解析済フラグ３３３７０をYesに設定する（ステップ６２０７０）。

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

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

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

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

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

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

以上が、イベント解析処理モジュール３２５００が実施する障害原因解析処理である。上述したように、特許文献１による障害解析機能では、複数の障害が短い期間に頻発すると、保存される障害解析結果の数が多くなる。しかし、複数の障害に対して多数の原因候補を推論した場合に、実際に発生しているどの障害にどの原因候補が関連するのかを提示する方法がない。特に多量の障害イベントが発生して多数の障害原因候補が推論された場合は、どの障害原因候補に対応すればどの箇所で発生している障害を直ぐに解決することができるのか、管理者が類推困難であり、管理者が優先的に対策を行うべき解析結果を参照するまでの時間が長くなる。その結果、障害の解消までに要する時間が長くなるという課題が存在する。

そこで、本発明による実施形態では、多数の解析結果を分類して表示できるようにするために、原因候補分類処理を新たに提供する。

＜原因候補分類処理の内容＞
従来技術における課題を解決するため、本発明の第１の実施形態では管理サーバ３００００における原因候補分類処理が追加されている。以下、当該原因候補分類処理の動作の詳細について説明する。

原因候補分類処理は、起点となる原因候補（例えば、確信度の一番高い原因候補）に含まれるイベントを基準とし、そのイベントを含む他の原因候補があれば、それは同じ障害原因に対する原因候補であると推測して分類（グルーピング）する処理である。関連する原因候補をグループとしてまとめているので、優先的に対処すべき候補を知ることが出来るようになる。

図１３は、第１の実施形態における、管理サーバ３００００のイベント解析処理モジュール３２５００が実施する原因候補分類処理（ステップ６３０５０）の詳細を説明するためのフローチャートである。

イベント解析処理モジュール３２５００は、解析結果管理表３３６００より、一定期間（例えば、一回のポーリング期間）において確信度が最も高い原因候補を選択する(ステップ６３０１０)。そして、選択した原因候補のエントリについて、解析結果管理表３３６００の分類起点フラグフィールド３３６９０に、Yesを登録する。イベント解析処理モジュール３２５００は、選択した候補に含まれる受信イベントIDを、解析結果管理表３３６００より取得する(ステップ６３０２０)。そしてイベント解析処理モジュール３２５００は、取得した受信イベントIDのうち、いずれか一つ以上の同一受信イベントIDを含む原因候補を、解析結果管理表３３６００より取得する(ステップ６３０３０)。原因候補の取得後、イベント解析処理モジュール３２５００は、解析結果管理表３３６００のグループIDを登録するフィールド３３６８０より利用されているグループIDのリストを取得し、重複しないグループIDを作成し、ステップ６３０１０で選択した原因候補およびステップ６３０３０で取得した原因候補のエントリに関して、フィールド３３６８０の内容を作成したグループIDに更新する (ステップ６３０４０)。

次に、イベント解析処理モジュール３２５００は、解析結果管理表３３６００より、フィールド３３６８０にグループIDが記載されていないエントリが存在するかどうかチェックする。そのようなエントリが存在した場合 (ステップ６３０５０でNoの場合)、そのようなエントリのうち、確信度が最も高い原因候補を選択し (ステップ６３０６０)、解析結果管理表３３６００の選択した原因候補のエントリについて、分類起点フラグフィールド３３６９０に、Yesを登録する。そして、選択した候補に対して、ステップ６３０２０以降の処理を再度行う。

解析結果管理表３３６００のフィールド３３６８０を参照し、全てのエントリにグループIDが記載されていた場合(ステップ６３０５０でYesの場合)、イベント解析処理モジュール３２５００は、解析結果管理表３３６００の受信イベントIDフィールド３３６６０から、全ての受信イベントIDを取得する。次に解析結果管理表３３６００の分類起点フラグフィールド３３６９０にYesが記載されているエントリを取得し、全ての受信イベントIDが取得したエントリに含まれているかどうかをチェックする。

エントリに含まれていない一つないし一つ以上の受信IDが存在する場合(ステップ６３０７０でNoの場合)、イベント解析処理モジュール３２５００は、それらの受信IDを含む原因候補を含む原因候補エントリのうち、確信度が最も高い原因候補を選択し(ステップ６３０８０)、解析結果管理表３３６００の選択した原因候補のエントリについて、分類起点フラグフィールド３３６９０に、Yesを登録する。そして、選択した候補に対して、ステップ６３０２０以降の処理を再度行う。

解析結果管理表３３６００の分類起点フラグフィールド３３６９０にYesが記載されているエントリが取得され、全ての受信イベントIDが取得したエントリに含まれていた場合(ステップ６３０７０でYesの場合)、原因候補分類処理は終了する。
以上が、イベント解析処理モジュール３２５００が実施する原因候補分類処理である。

以下に、原因候補分類処理の具体例について説明する。なお、処理開始当初の解析結果管理表は図１０、展開ルールは図９、イベント管理表は図７に示す通りのものであるとする。そして、図１２のステップ６２０５０の直前までは、処理が終了しているものとする。

イベント解析処理モジュール３２５００は、解析結果管理表３３６００より、確信度が最も高いエントリとして、解析結果管理表の第１段目（１つ目のエントリ）から、SYS1の装置の、CTL1の障害原因候補エントリを選択する。つぎに、この候補に含まれる障害イベントである、EV1、EV3、EV6を抽出する。そして、これらの障害イベントを含む他の障害原因候補として、2段目のエントリ(SYS1/CTL2)と5段目のエントリ(IPSW1)を選択する。そして、これら3つのエントリをグループ化し、グループIDとしてGR1を生成してこれらのエントリの解析結果管理表のグループID登録用のフィールド３３６８０に生成したグループIDを登録する。さらに1段目のエントリを、分類を行う際の基準として扱ったので、1段目のエントリの分類起点フラグ３３６９０にはYesを、残りの2エントリの分類起点フラグ３３６９０にはNoを記録する。

解析結果管理表にはまだグループ化されていない残りのエントリ(3段目、4段目)が存在するため、それらについてここまでの作業を繰り返す。まず、確信度の高いエントリとして、3段目のエントリ(SYS1/CTL3)を選択する。そしてこの候補に含まれる障害イベントである EV2、EV4、EV8を抽出する。これらの障害イベントを含む他の障害原因候補として、5段目のエントリ(IPSW1)を選択する。そして、これら2つのエントリをグループ化し、グループIDとしてGR2を生成してこれらのエントリの解析結果管理表のグループID登録用のフィールド３３６８０に生成したグループIDを登録する。なお、5段目のエントリには既にグループIDが登録されているが、複数のグループに所属していることを示すため、追加して登録する。このために、グループID登録用のフィールド３３６８０は、複数のIDを登録できるような構造にする。さらに3段目のエントリを、分類を行う際の基準として扱ったので、3段目のエントリの分類起点フラグ３３６９０にはYesを記録する。

さらに解析結果管理表にはまだグループ化されていない残りのエントリ(4段目)が存在する。このエントリについても同様の作業を繰り返す。そしてこの候補に含まれる障害イベントであるEV5、EV9を抽出する。これらの障害イベントを含む他の障害原因候補として、5段目のエントリ(IPSW1) を選択する。そして、これら2つのエントリをグループ化し、グループIDとしてGR3を生成してこれらのエントリの解析結果管理表のグループID登録用のフィールド３３６８０に生成したグループIDを登録する。なお、5段目のエントリには既にグループIDが登録されているため、追加して登録する。さらに4段目のエントリを、分類を行う際の基準として扱ったので、4段目のエントリの分類起点フラグ３３６９０にはYesを記録する。
ここまでの処理により、解析結果管理表のすべてのエントリはグループ化された。

次に、グループ化の際に参照されなかった障害イベントを抽出する。解析結果管理表３３６００の受信イベントIDフィールド３３６６０に含まれる全てのイベントIDのうち、分類起点フラグ３３６９０にYesが記録されているエントリに含まれないものとして、EV7を抽出する。EV7を含む原因候補として、2段目のエントリ(SYS1/CTL2)と5段目のエントリ(IPSW1)が存在する。このうち確信度の高い2段目のエントリ(SYS1/CTL2)を起点に、同様のグループ化を行うと、これら2つのエントリと、1段目のエントリ(SYS1/CTL1)を新たにグループ化できる。なお、ここでこれらのエントリは全てグループGR1に含まれる。GR1に着目して障害対応を行うことを考えると、GR1の起点となった1段目のエントリを解決するためにSYS1/CTL1の障害に対応しても、2段目のエントリに含まれるEV7については解決できない可能性がある。本実施形態では、各グループの一つのエントリについて対処すれば全ての障害を修復できるよう、2段目のエントリ(SYS1/CTL2)を起点にしたグループも、GR1とは別に生成する。そしてグループIDとしてGR4を生成してこれらのエントリの解析結果管理表のグループID登録用のフィールド３３６８０に生成したグループIDを登録する。なお、各エントリには既にグループIDが登録されているため、追加して登録する。さらに2段目のエントリを、分類を行う際の基準として扱ったので、2段目のエントリの分類起点フラグ３３６９０にはYesを記録する。

これにより、解析結果管理表３３６００の受信イベントIDフィールド３３６６０に含まれる全てのイベントIDのうち、分類起点フラグ３３６９０にYesが記録されているエントリに含まれないものが無くなったため、原因候補分類処理を終了する。

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

障害解析結果表示画面７１０００では、解析結果管理表に定義された解析結果をグループIDが一致するものをまとめて表示する。その際に、複数のグループに分類されているエントリは、複数のグループに重複して表示する。また、各グループにおいてグループ化の際に起点とした原因候補を、そのグループの最上位に表示する。そしてそれ以外の候補は、確信度の高い順に表示している。

なお、本実施形態では同一画面に全ての原因候補のグループを表示しているが、グループごとに分割して表示されれば良いので、グループごとに別画面で表示し、タブ等で切り替えられるように実施してもよい。

以上の障害解析結果表示によれば、例えば、管理者は、管理サーバ３００００の画面に表示された各原因候補グループの最上位の候補から対処していけば効率よく障害原因を取り除ける可能性が高いことを知ることができる。

＜変形例＞
上述の分類処理の結果生成されたグループの数が多すぎると、却ってグループ化することにより障害結果の確認が困難になる場合がある。そこで、分類処理で生成されたグループ数が所定数以上の場合（グループ数については管理者が設定可能）、分類結果を自動的にまとめるようにしても良い。その際の処理は、例えば、まず、ある分類結果のグループに含まれる条件イベントのうちの一定割合以上が別の分類結果のグループに含まれるか否かを判断する。そして、一定割合異常の条件イベントが別の分類結果のグループに含まれる場合には、それらのグループに含まれる原因候補を１つのグループにまとめて、グループ化する。このようにするのは、あるグループの条件イベントの一定以上の割合が別のグループにも含まれる場合には、双方のグループに含まれる障害イベントが同じ装置に発生した障害に起因して発生している可能性が高く、同一のグループとして扱っても問題がない可能性が高いからである。

＜原因候補分類処理の効果＞
以上、第１の実施形態によれば、管理サーバ３００００の管理ソフトウェアは、図１２に示す障害原因解析処理の後、推論した障害原因候補を、それによって解決される障害にかかわる障害イベントによって分類して表示する。第１の実施形態による分類法と、その結果の表示形式では、各グループの上位の１つのエントリについて対処すれば全ての障害を修復できるよう、分類することができる。従来、原因候補分類処理を行わない場合は、推論した障害原因候補として、図１０に示すリストの内容をそのまま表示している。原因候補分類処理を行うことによって、管理者がどの原因候補に優先的に対応すべきか容易に判断でき、解析結果確認と障害対応に要する負荷を軽減することができる。

そして、図１４のようにグループに分類して各原因候補を表示することにより、管理者としては優先度の高い原因候補（優先的に対処すべき候補）をバランスよく検証することができ、よって障害対応の時間を短縮することができるようになる。

（２）第２の実施形態
第２の実施形態は、第１の実施形態により管理者に原因候補を提示した後、管理者が実施した障害対応手順に基づき、原因候補分類処理を再度実施するものである。システム構成や各装置の構成は第１の実施形態と同じであるので、説明は省略する。以降、第２の実施形態の説明では、第１の実施形態によって図１４のように障害解析結果を画面表示した後で、管理者の操作に基づいて行う処理を記載する。

＜原因候補対処時の処理＞
図１５は、第２の実施形態において、管理者が障害解析結果を利用して障害対応を行う時の処理を説明するためのフローチャートである。管理者は、例えば、障害解析結果表示画面７１０００から、原因候補を選択して障害対応を行ったことを検知する(ステップ６４０１０)と、イベント解析モジュール３２５００は、管理者が選択した候補の対応済フラグをYesに変更する(ステップ６４０２０)。第１の実施形態では、各グループの上位の一つのエントリについて対処すれば全ての障害を修復できるように分類した。したがって、障害対応時に最初に選択された候補がいずれかのグループの最上位の候補であれば、分類が管理者の意図や実際の構成状況に合致するように行われていることになる。逆にいずれのグループの最上位でもない候補を最初に選択した場合は、分類が適切に行われていなかったことになる。そのため、最初に管理者に選択された候補がいずれのグループの最上位でもなかった場合、イベント解析モジュール３２５００は、原因候補再分類処理を行う(ステップ６４０３０〜６４０４０)。つまり、最上位以外の候補が選択されたということは、管理者が自身の経験等に基づいて１回目の分類結果を信用していないことを示しており、このような事態に対応して再分類を行い、管理者がより効率よく原因候補に対処できるようにしている。

＜原因候補再分類処理の詳細＞
図１６は、第２の実施形態による原因候補再分類処理（ステップ６４０４０）の詳細を説明するためのフローチャートである。本実施形態の原因候補再分類処理は、第１の実施形態での原因候補分類処理(ステップ６３０１０〜６３０８０)に対して行った処理と同等の分類処理を、対応済フラグがYesに設定されている候補から優先的に実施する。

イベント解析処理モジュール３２５００は、まず、事前処理として全ての候補のグループIDフィールド３３６８０と、分類起点フラグフィールド３３６９０の値を削除する(ステップ６５００５)。

次に、イベント解析処理モジュール３２５００は、解析結果管理表３３６００より、対応済フラグフィールド３３６７０がYesに設定されている候補のうちで、確信度が最も高い原因候補を選択する(ステップ６５０１０)。そして、イベント解析処理モジュール３２５００は、選択した原因候補のエントリについて、解析結果管理表３３６００の分類起点フラグフィールド３３６９０に、Yesを登録する。

イベント解析処理モジュール３２５００は、選択した候補に含まれる受信イベントIDを、解析結果管理表３３６００より取得する(ステップ６５０２０)。そして、イベント解析処理モジュール３２５００は、取得した受信イベントIDのうち、いずれか一つ以上の同一受信イベントIDを含む原因候補を、解析結果管理表３３６００より取得する(ステップ６５０３０)。

原因候補の取得後、イベント解析処理モジュール３２５００は、解析結果管理表３３６００のグループIDを登録するフィールド３３６８０より利用されているグループIDのリストを取得し、重複しないグループIDを作成し、ステップ６５０１０で選択した原因候補およびステップ６５０３０で取得した原因候補のエントリに関して、フィールド３３６８０の内容を作成したグループIDに更新する (ステップ６５０４０)。

続いて、イベント解析処理モジュール３２５００は、解析結果管理表３３６００より、対応済フラグフィールド３３６７０がYesに設定されている候補のうちで、フィールド３３６８０にグループIDが記載されていないエントリが存在するかどうかチェックする。そのようなエントリが存在した場合(ステップ６５０５０でNoの場合)、そのようなエントリのうち、確信度が最も高い原因候補を選択し(ステップ６５０６０)、解析結果管理表３３６００の選択した原因候補のエントリについて、分類起点フラグフィールド３３６９０に、Yesを登録する。そして、選択した候補に対して、ステップ６５０２０以降の処理を再度行う。

対応済みフラグYesの原因候補が全て分類済であると判断された場合（ステップ６５０５０でYesの場合）、イベント解析処理モジュール３２５００は、解析結果管理表３３６００より、フィールド３３６８０にグループIDが記載されていないエントリが存在するかどうかチェックする。そのようなエントリが存在した場合(ステップ６５０７０でNoの場合)、イベント解析処理モジュール３２５００は、そのようなエントリのうち、確信度が最も高い原因候補を選択し(ステップ６５０８０)、解析結果管理表３３６００の選択した原因候補のエントリについて、分類起点フラグフィールド３３６９０に、Yesを登録する。そして、選択した候補に対して、ステップ６５０２０以降の処理を再度行う。

さらに、解析結果管理表３３６００のフィールド３３６８０を参照し、全てのエントリにグループIDが記載されていた場合(ステップ６５０７０でYesの場合)、イベント解析処理モジュール３２５００は、解析結果管理表３３６００の受信イベントIDフィールド３３６６０から、全ての受信イベントIDを取得する。

次に、イベント解析処理モジュール３２５００は、解析結果管理表３３６００の分類起点フラグフィールド３３６９０にYesが記載されているエントリを取得し、全ての受信イベントIDが取得したエントリに含まれているかどうかをチェックする。

エントリに含まれていない１つないし１つ以上の受信IDが存在する場合(ステップ６５０９０でNoの場合)、イベント解析処理モジュール３２５００は、それらの受信IDを含む原因候補を含む原因候補エントリのうち、確信度が最も高い原因候補を選択し(ステップ６５０９５)、解析結果管理表３３６００の選択した原因候補のエントリについて、分類起点フラグフィールド３３６９０に、Yesを登録する。そして、イベント解析処理モジュール３２５００は、選択した候補に対して、ステップ６５０２０以降の処理を再度行う。

イベント解析処理モジュール３２５００は、解析結果管理表３３６００の分類起点フラグフィールド３３６９０にYesが記載されているエントリを取得し、全ての受信イベントIDが取得したエントリに含まれていた場合(ステップ６５０９０でYesの場合)、原因候補再分類処理を終了する。

以上が、イベント解析処理モジュール３２５００が実施する原因候補再分類処理である。なお、図１６では、対処済フラグをYesにしたタイミングと原因候補再分類処理を実行するタイミングとの関係については明記していないが、管理者がいくつかの原因候補について対応し、いくつかの対応済フラグがYesになった後、管理者の指示に従って原因候補再分類処理（図１６）を実行するようにしても良いし、対応済フラグがYesに変更される都度、原因候補再分類処理を実行するようにしても良い。

以下に、原因候補再分類処理の具体例について説明する。なお、第１の実施形態と同様に、処理開始当初の解析結果管理表は図１０、展開ルールは図９、イベント管理表は図７に示す通りのものであるとする。なお、図１５のステップ６４０４０の実行の直前までは処理が終了しているものとする、その過程において、管理者は図１４の結果画面表示で、最初にIPSW1の障害原因を選択しており、図１０の対応済フラグフィールド３３６７０には、5段目のエントリ(IPSW1)の部分にのみYesが記録されているものとする。

イベント解析処理モジュール３２５００は、まず、解析結果管理表３３６００の全ての原因候補のグループIDフィールドと、分類起点フラグフィールドの値を削除する。次に、解析結果管理表３３６００より、対応済フラグがYesの原因候補のうち、確信度が最も高いエントリとして、解析結果管理表の第５段目（5つ目のエントリ）から、IPSW装置の障害原因候補エントリを選択する。

次に、イベント解析処理モジュール３２５００は、この候補に含まれる障害イベントである、EV6、EV7、EV8、EV9を抽出する。そして、これらの障害イベントを含む他の障害原因候補として、1段目のエントリ(SYS1/CTL1)、2段目のエントリ(SYS1/CTL2)、3段目のエントリ(SYS1/CTL3)、4段目のエントリ(SYS1/CTL4)選択する。そして、これら5つのエントリをグループ化し、グループIDとしてGR1を生成してこれらのエントリの解析結果管理表のグループID登録用のフィールド３３６８０に生成したグループIDを登録する。さらに5段目のエントリを、分類を行う際の基準として扱ったので、5段目のエントリの分類起点フラグ３３６９０にはYesを、残りの4エントリの分類起点フラグ３３６９０にはNoを記録する。
ここまでの処理により、解析結果管理表のすべてのエントリはグループ化された。

続いて、イベント解析処理モジュール３２５００は、グループ化の際に参照されなかった障害イベントを抽出する。解析結果管理表３３６００の受信イベントIDフィールド３３６６０に含まれる全てのイベントIDのうち、分類起点フラグ３３６９０にYesが記録されているエントリに含まれないものとしてEV1、EV2、EV3、EV4、EV5が抽出される。それらを含む原因候補として、1段目のエントリ〜4段目のエントリまでの4エントリが存在する。このうち確信度の高い1段目のエントリを起点に、同様のグループ化を行うと、イベント解析処理モジュール３２５００は、障害イベントEV1、EV3、EV6を含む他の障害原因候補として、2段目のエントリ(SYS1/CTL2)と5段目のエントリ(IPSW1)を選択する。そして、イベント解析処理モジュール３２５００は、これら3つのエントリをグループ化し、グループIDとしてGR2を生成してこれらのエントリの解析結果管理表のグループID登録用のフィールド３３６８０に生成したグループIDを登録する。さらに、イベント解析処理モジュール３２５００は、分類を行う際の基準として1段目のエントリを扱ったので、1段目のエントリの分類起点フラグ３３６９０にはYesを記録する。

イベント解析処理モジュール３２５００は、解析結果管理表３３６００の受信イベントIDフィールド３３６６０に含まれる全てのイベントIDのうち、分類起点フラグ３３６９０にYesが記録されているエントリに含まれないものとしてEV2、EV4、EV5を抽出する。それらを含む原因候補として、3段目のエントリ、4段目のエントリの2エントリが存在する。このうち確信度の高い3段目のエントリを起点に、同様のグループ化を行うと、イベント解析処理モジュール３２５００は、障害イベントEV2、EV4、EV8を含む他の障害原因候補として、5段目のエントリ(IPSW1)を選択する。そして、イベント解析処理モジュール３２５００は、これら2つのエントリをグループ化し、グループIDとしてGR3を生成してこれらのエントリの解析結果管理表のグループID登録用のフィールド３３６８０に生成したグループIDを登録する。さらに、分類を行う際の基準として3段目のエントリを、扱ったので、イベント解析処理モジュール３２５００は、3段目のエントリの分類起点フラグ３３６９０にはYesを記録する。

さらに、イベント解析処理モジュール３２５００は、解析結果管理表３３６００の受信イベントIDフィールド３３６６０に含まれる全てのイベントIDのうち、分類起点フラグ３３６９０にYesが記録されているエントリに含まれないものとしてEV5を抽出する。また、イベント解析処理モジュール３２５００は、それらを含む原因候補として、4段目のエントリを起点に同様のグループ化を行うと、障害イベントEV5、EV9を含む他の障害原因候補として、5段目のエントリ(IPSW1)を選択する。そして、イベント解析処理モジュール３２５００は、これら2つのエントリをグループ化し、グループIDとしてGR4を生成してこれらのエントリの解析結果管理表のグループID登録用のフィールド３３６８０に生成したグループIDを登録する。さらに、イベント解析処理モジュール３２５００は、分類を行う際の基準として4段目のエントリを、扱ったので、4段目のエントリの分類起点フラグ３３６９０にはYesを記録する。

解析結果管理表３３６００の受信イベントIDフィールド３３６６０に含まれる全てのイベントIDのうち、分類起点フラグ３３６９０にYesが記録されているエントリに含まれないものが無くなったため、イベント解析処理モジュール３２５００は、原因候補再分類処理を終了する。

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

第１の実施形態と同様に、障害解析結果表示画面７２０００では、解析結果管理表に定義された解析結果をグループIDが一致するものをまとめて表示する。その際に、複数のグループに分類されているエントリは、複数のグループに重複して表示する。また、各グループにおいてグループ化の際に起点とした原因候補を、そのグループの最上位に表示する。そしてそれ以外の候補は、確信度の高い順に表示している。

なお、第１の実施形態と同様に、本実施形態では同一画面に全ての原因候補のグループを表示しているが、グループごとに分割して表示されれば良いので、グループごとに別画面で表示し、タブ等で切り替えられるように実施してもよい。

＜原因候補再分類処理の効果＞
以上、第２の実施形態によれば、管理サーバ３００００の管理ソフトウェアは、図１５に示すように、第１の実施形態でグループの最上位に表示しなかった障害原因候補を管理者が最初に障害原因として選択した場合に、それを基準に障害原因候補の分類を再度実行する。第１の実施形態（図１４）のように分類された状況で、それぞれのグループの最下位に表示されていたIPSW1を管理者が選択したということは、本発明の管理ソフトウェアが把握していないが管理者が把握している状況としてIPSW1が障害の原因であると管理者に推測させるような外部的な状況が存在するのかもしれない。そのような場合に、管理者の選択に合わせて第２の実施形態のように、動的にグループ化を再構成している。

その結果、まずIPSW1に発生している障害原因に対応した場合に、他にどの障害原因に優先的に対応すべきなのかを分類して表示している。このため、第１の実施形態の提示した結果が仮に管理者の意図と異なっていた場合にも、それに合わせて分類を修正することができ、管理者の障害対応に要する負荷を軽減することができる。

（３）まとめ
障害原因解析では、障害原因の推論の後で、管理サーバにおいて推論した障害原因候補それぞれに対して導出過程で解析ルールに適用した障害イベントを取得する。そして個々の原因候補の確信度と、その導出根拠となる障害イベントに基づいて、障害原因候補を分類する。しかし、異なった原因に起因する複数の障害が短い期間に頻発すると、保存される障害解析結果の数が多くなり、どの障害原因候補が実際に発生するどの障害に関して推論されたのか、管理者に判断できないことがある。本発明ではそのような場合に、実際に発生している障害イベントが共通して含まれる原因候補を、同一グループとして分類する。これにより、異なった原因に起因する複数の障害が発生した際にも、確からしい組み合わせで原因候補を分類することができる。

なお、ある１つの原因候補にしか関連していない障害イベントが存在する場合は、障害イベント発生の原因となる障害を解決するためには、その原因候補を利用するほかに手段がない。このような場合には、複数の原因候補が障害イベントに関連していないため、この障害イベントを基準に分類されたグループが存在しない。そのため、すべてのグループの障害原因候補に対応しても、この障害イベントを解決できないことがある。特に、何らかの別の障害イベントによって、この障害イベントを解決できる唯一の原因候補が、たまたまあるグループに分類されていた場合、特定の障害イベントに関して解決できる唯一の原因候補にもかかわらず、グループ内の他の多数の原因候補と同一視され、その結果分類を行ったことによりその障害イベントに関する対応が迅速に行われなくなることも考えられる。それを防止するため、本発明では障害原因候補分類の根拠として利用しなかった障害イベントが存在する場合には、それを解決する原因候補や原因候補群について、さらに別個のグループを作成する。つまり、管理サーバは、起点原因候補を変えて結論イベントの分類処理を繰り返し、全ての障害原因とされる結論イベントを分類した後、起点原因候補として選択された結論イベント以外の結論イベント（例えば、図１０の２段目のエントリ）が起点原因候補として選択された結論イベントに含まれる条件イベント以外の条件イベントである残余条件イベントを含む場合に、この残余条件イベントを含む結論イベントを起点原因候補としてさらに分類処理を実行する。こうすることにより、漏れなく原因候補をグループ化することができ、全ての障害を修復することが可能となる。

さらに、本発明では、管理サーバはこのような分類結果に基づいて、障害解析結果の表示を行う。この際に、それぞれの障害原因候補が他のどの原因候補とグループ化されているのか、管理者が理解できるように表示する。例えば、分類結果に基づきグループごとに別画面に分けて原因候補を表示しても良いし、同一の画面内で候補グループごとに順番を入れ替えた上でそれぞれのグループを認識できるように表示したり、同様に同一の画面内で確信度等のグループとは関係ない順序で原因候補を表示した上で、属するグループを各原因候補エントリに表示したりしても良い。

本実施形態では、各ノード装置の性能値から異常状態を検知し、その解析結果（異常状態の確信度を演算）として障害原因の候補を管理者に提示する。その際に、いくつかの異常状態を示すイベントが、ある特定の異常状態の事象により引き起こされる場合を想定し、確信度の最も高い障害原因と共通した異常状態を含む障害原因の候補を分類する。そして、障害解析結果表示画面では、その分類を管理者が理解できるような方法で、解析結果の表示を行う。より具体的には、本実施形態の計算機システムでは、管理サーバ（管理システム）が、ノード装置の処理性能を示す処理性能値を取得し、当該取得した処理性能値からノード装置に障害が発生したことを検知し、複数の障害原因とされる結論イベントの１つを起点原因候補として選択し、起点原因候補に関係する条件イベントを抽出する。また、管理サーバは、抽出された条件イベントに関係する結論イベントであって、起点原因候補の結論イベントとは異なる１つ又は複数の障害原因とされる結論イベントを関連原因候補として選択し、起点原因候補の結論イベントと前記関連原因候補の結論イベントを、他の結論イベントとは別個に分類処理する。そして、管理サーバは、分類された結論イベントを表示画面に表示する。このようにすることにより、管理者は、解析結果の対応優先度を容易に判断でき、解析結果確認と障害対応に要する負荷を軽減することができる。

また、管理サーバは、起点原因候補及び関連原因候補に対応する結論イベントの分類結果に従って、障害原因とされる結論イベントを分類結果ごとに区別して表示画面に表示する。このようにすることにより、対処すべき解析結果が容易に判断することができると共に、対処済の結果と未対処の結果を区別して管理することが可能となる。

また、管理サーバは、起点原因候補の結論イベントに関係する条件イベントと同一の条件イベントを解析ルールに少なくとも１つ含む関連原因候補の結論イベントを、起点原因候補の結論イベントと同一のグループとして分類する。このようにすることにより、分類の条件が明確になり、起点となる原因候補を対処したときに同時に解決されうる原因候補を同一グループに分類するので、管理者の負担を軽減することができるようになる。

なお、起点原因候補として、確信度が最も高い結論イベントを選択するようにしても良い。これにより、対応優先度が高いと考えられる解析結果を軸として自動的に分類処理することが可能となり、効率的に障害対応をすることができるようになる。

また、障害解析を行う管理サーバは、管理対象を取り巻く外部的な状況を必ずしも完全に把握できるとは限らない。したがって、本実施形態での分類結果により提示される障害原因と、実際に管理者が障害原因と考えている事象が異なる可能性があることを否定できない。そのため、優先度（確信度）の低い原因候補を管理者が選択し、障害復旧を行った場合に、管理者の選択に合わせて、動的にグループ化を再構成するようにしている(第２の実施形態参照）。即ち、管理サーバは、複数の分類グループを含む前記分類結果において、障害対応時にどの分類グループに含まれる前記結論イベントが管理者によって選択されたかについての情報に基づいて、再度分類処理を実行するか決定する。つまり、障害対応時に選択された結論イベントを起点原因候補として分類処理を再度実行する。このように動的に分類処理を再度実行することにより、管理者は経験に基づいた障害対処を実行することができ、効率的に計算機システムを管理することができるようになる。

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

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

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

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

Claims (13)

1. 監視の対象となるノード装置と、ネットワークを介して前記ノード装置に接続され、前記ノード装置を監視及び管理する管理システムと、を有する計算機システムの管理方法であって、
   前記管理システムが、前記ノード装置の処理性能を示す処理性能値を取得し、当該取得した処理性能値から前記ノード装置に障害が発生したことを検知し、
   前記管理システムが、前記検知した障害により得られたイベントを、前記ノード装置で発生し得る１つ以上の条件イベントの組み合わせと前記条件イベントの組み合わせの障害原因とされる結論イベントとの関係を示す解析ルールに適用し、前記発生した障害が前記ノード装置における前記結論イベントの発生に起因する可能性の程度を示す情報である確信度を算出し、
   前記管理システムが、複数の障害原因とされる結論イベントの１つを起点原因候補として選択し、前記起点原因候補に関係する前記条件イベントを抽出し、
   前記管理システムが、抽出された前記条件イベントに関係する結論イベントであって、前記起点原因候補の結論イベントとは異なり、前記障害原因とされる１つ又は複数の結論イベントを関連原因候補として選択し、
   前記管理システムが、前記起点原因候補の結論イベントと前記関連原因候補の結論イベントを、他の結論イベントとは別個に分類処理し、
   前記管理システムが、前記分類された結論イベントを表示画面に表示する、
   ことを特徴とする計算機システムの管理方法。
2. 請求項１において、
   前記管理システムは、前記起点原因候補及び前記関連原因候補に対応する結論イベントの分類結果に従って、前記障害原因とされる結論イベントを分類結果ごとに区別して前記表示画面に表示することを特徴とする計算機システムの管理方法。
3. 請求項１又は２において、
   前記管理システムは、前記起点原因候補の結論イベントに関係する前記条件イベントと同一の条件イベントを前記解析ルールに少なくとも１つ含む前記関連原因候補の結論イベントを、前記起点原因候補の結論イベントと同一のグループとして分類することを特徴とする計算機システムの管理方法。
4. 請求項１乃至３の何れか１項において、
   前記管理システムは、前記確信度が最も高い前記結論イベントを前記起点原因候補として選択し、当該起点原因候補の結論イベントに関係する前記条件イベントによって前記関連原因候補の結論イベントを分類することを特徴とする計算機システムの管理方法。
5. 請求項１乃至４の何れか１項において、
   前記管理システムは、前記複数の障害の原因とされる結論イベントにおいて前記起点原因候補を変えて結論イベントの分類処理を繰り返し、全ての前記障害の原因とされる結論イベントを分類した後、前記起点原因候補として選択された結論イベント以外の結論イベントが前記起点原因候補として選択された結論イベントに含まれる前記条件イベント以外の条件イベントである残余条件イベントを含むか否か判断し、前記残余条件イベントを含む結論イベントを前記起点原因候補としてさらに分類処理を実行することを特徴とする計算機システムの管理方法。
6. 請求項２において、
   前記管理システムは、複数の分類グループを含む前記分類結果において、障害対応時にどの分類グループに含まれる前記結論イベントが管理者によって選択されたかについての情報に基づいて、再度分類処理を実行するか決定することを特徴とする計算機システムの管理方法。
7. 請求項６において、
   前記管理システムは、前記障害対応時に選択された前記結論イベントを前記起点原因候補として前記分類処理を再度実行することを特徴とする計算機システムの管理方法。
8. 監視対象のノード装置とネットワークを介して接続され、前記ノード装置を管理する管理システムであって、
   前記ノード装置の処理性能を示す処理性能値を取得し、当該取得した処理性能値から前記ノード装置の障害を検知するプロセッサと、
   前記ノード装置で発生し得る１つ以上の条件イベントの組み合わせと前記条件イベントの組み合わせの障害原因とされる結論イベントとの関係を示す解析ルールを格納するメモリと、を有し、
   前記プロセッサは、
   前記検知した障害により得られたイベントを前記解析ルールに適用し、前記発生した障害が前記ノード装置における前記結論イベントの発生に起因する可能性の程度を示す情報である確信度を算出し、
   複数の障害原因とされる結論イベントの１つを起点原因候補として選択し、前記起点原因候補に関係する前記条件イベントを抽出し、
   抽出された前記条件イベントに関係する結論イベントであって、前記起点原因候補の結論イベントとは異なり、前記障害原因とされる１つ又は複数の結論イベントを関連原因候補として選択し、
   前記起点原因候補の結論イベントと前記関連原因候補の結論イベントを、他の結論イベントとは別個に分類処理し、
   前記分類された結論イベントを表示画面に表示する、
   ことを特徴とする管理システム。
9. 請求項８において、
   前記プロセッサは、前記起点原因候補及び前記関連原因候補に対応する結論イベントの分類結果に従って、前記障害原因とされる結論イベントを分類結果ごとに区別して前記表示画面に表示することを特徴とする管理システム。
10. 請求項８又は９において、
    前記プロセッサは、前記起点原因候補の結論イベントに関係する前記条件イベントと同一の条件イベントを前記解析ルールに少なくとも１つ含む前記関連原因候補の結論イベントを、前記起点原因候補の結論イベントと同一のグループとして分類することを特徴とする管理システム。
11. 請求項８乃至１０の何れか１項において、
    前記プロセッサは、前記確信度が最も高い前記結論イベントを前記起点原因候補として選択し、当該起点原因候補の結論イベントに関係する前記条件イベントによって前記関連原因候補の結論イベントを分類することを特徴とする管理システム。
12. 請求項８乃至１１の何れか１項において、
    前記プロセッサは、前記複数の障害の原因とされる結論イベントにおいて前記起点原因候補を変えて結論イベントの分類処理を繰り返し、全ての前記障害の原因とされる結論イベントを分類した後、前記起点原因候補として選択された結論イベント以外の結論イベントが前記起点原因候補として選択された結論イベントに含まれる前記条件イベント以外の条件イベントである残余条件イベントを含むか否か判断し、前記残余条件イベントを含む結論イベントを前記起点原因候補としてさらに分類処理を実行することを特徴とする管理システム。
13. 請求項９において、
    前記プロセッサは、複数の分類グループを含む前記分類結果において、障害対応時にどの分類グループに含まれる前記結論イベントが管理者によって選択されたかについての情報に基づいて、再度分類処理を実行するか決定し、前記分類処理を再度実行すると決定した場合には、前記障害対応時に選択された前記結論イベントを前記起点原因候補として前記分類処理を再度実行することを特徴とする管理システム。

Images