(57)【特許請求の範囲】
【請求項１】
複数種類の管理オブジェクトを含む計算機システムの管理を行う管理システムであって、
記憶デバイスと、前記記憶デバイスに接続された制御デバイスとを有し、
前記記憶デバイスは、
前記管理オブジェクトの種類のいずれかに関する原因イベントと、前記原因イベントが原因となることの条件となる、前記管理オブジェクトの種類のいずれかに関する１以上の影響イベントとの対応関係を示す１以上のメタルールと、
前記管理オブジェクトの種類のうちの２つの種類間の接続関係を示す関連ごとに、当該関連に関する変更頻度を示す変更頻度情報と
を記憶し、
前記制御デバイスは、
メタルールの原因イベントに関係する管理オブジェクトの種類と、当該メタルールの１以上の影響イベントに関係する管理オブジェクトの種類のそれぞれとの間の接続構成を示す１以上の前記関連の組み合わせである関連グループであって、前記記憶デバイスに記憶されている第１のメタルールに関する第１の関連グループを、前記第１の関連グループを構成する複数の前記関連のそれぞれに関する変更頻度に基づいて、変更頻度が所定値以上の前記関連によって構成される１以上の第２の関連グループと、変更頻度が前記所定値より小さい前記関連によって構成される１以上の第３の関連グループとに分割し、
前記第１のメタルールを、前記１以上の第２の関連グループのそれぞれに対応する１以上の第２のメタルールと、前記１以上の第３の関連グループのそれぞれに対応する１以上の第３のメタルールとに分割する
管理システム。
【請求項２】
前記１以上の第２のメタルール及び前記１以上の第３のメタルールは、当該複数のメタルール全体で、前記第１のメタルールの原因イベントと前記第１のメタルールの１以上の影響イベントとの対応関係を示す
請求項１に記載の管理システム。
【請求項３】
前記記憶デバイスは、
前記計算機システムに含まれる複数の管理オブジェクト及び当該複数の管理オブジェクト間の接続関係を示す構成情報をさらに記憶し、
前記制御デバイスは、
前記１以上の第２のメタルール、前記１以上の第３のメタルール、及び前記構成情報に基づいて、メタルールの原因イベント及び影響イベントに関係する管理オブジェクトの種類を特定の管理オブジェクトを示すデータで表した展開ルールであって、前記１以上の第２のメタルールに対応する１以上の第２の展開ルールと、前記１以上の第３のメタルールに対応する１以上の第３の展開ルールとを生成し、
前記１以上の第２の展開ルール及び前記１以上の第３の展開ルールに基づいて、前記複数の管理オブジェクトのいずれかで発生したイベントの原因解析を行う
請求項２に記載の管理システム。
【請求項４】
前記制御デバイスは、
前記第１のメタルールの影響イベントに対応する第１のイベントが発生した場合に、前記１以上の第２の展開ルール及び前記１以上の第３の展開ルールのうちの前記第１のイベントの原因解析に利用される展開ルールであって前記記憶デバイスに記憶されていない展開ルールを生成し、当該生成した展開ルールを前記記憶デバイスに記憶し、
前記構成情報が変更された場合に、前記記憶デバイスに記憶されている１以上の展開ルールの中から変更後の前記構成情報と矛盾が生じた展開ルールを特定し、当該特定した展開ルールを前記記憶デバイスから削除する
請求項３に記載の管理システム。
【請求項５】
前記制御デバイスは、
前記計算機システムに含まれる複数の管理オブジェクトのうちの第１の管理オブジェクトと第２の管理オブジェクトとの間の接続関係が変更された場合、前記変更頻度情報が示す変更頻度のうちの、前記第１の管理オブジェクトの種類と前記第２の管理オブジェクトの種類との間の接続関係を示す第１の関連に関する変更頻度を更新し、
前記第１の関連に関する更新前の変更頻度が前記所定値よりも小さく、且つ、前記第１の関連に関する更新後の変更頻度が前記所定値以上である場合、前記第１の関連を含む関連グループに対応するメタルールを、前記第１のメタルールとして前記１以上の第２のメタルールと前記１以上の第３のメタルールとに分割する
請求項４に記載の管理システム。
【請求項６】
前記制御デバイスは、
メタルールの原因イベントを示す原因情報と、当該メタルールの１以上の影響イベントを示す影響情報との入力を受け付け、
前記原因情報が示す原因イベントと、前記影響情報が示す１以上の影響イベントとの対応関係を示すメタルールを生成し、当該生成したメタルールを、前記第１のメタルールとして前記１以上の第２のメタルールと前記１以上の第３のメタルールとに分割する
請求項５に記載の管理システム。
【請求項７】
前記制御デバイスは、
前記第１のメタルールを分割する場合において、
前記第１の関連グループに含まれるいずれか複数の前記関連によって示される、２つの管理オブジェクトの種類間を結ぶ経路ごとに、当該経路を、変更頻度が前記所定値以上の前記関連によって構成される１以上の第１の経路と、変更頻度が前記所定値より小さい前記関連によって構成される１以上の第２の経路とに分割し、前記第１の経路を示す１以上の前記関連の組み合わせを前記第２の関連グループの１つとし、前記第２の経路を示す１以上の前記関連の組み合わせを前記第３の関連グループの１つとする
請求項６に記載の管理システム。
【請求項８】
前記制御デバイスは、
前記第１のメタルールを分割する場合において、
前記関連グループを構成する１以上の前記関連に関係する複数の管理オブジェクトの種類の組み合わせである種類群であって、前記１以上の第２の関連グループ及び前記１以上の第３の関連グループのうちの一の対象関連グループに関する対象種類群の中に、前記第１のメタルールの原因イベントに関係する第３の管理オブジェクトの種類が含まれる場合、前記第１のメタルールの原因イベントを、前記対象関連グループに対応する第２のメタルール又は第３のメタルールの原因イベントとし、
前記対象種類群の中に、前記第１のメタルールの影響イベントに関係する管理オブジェクトの種類が含まれる場合、当該影響イベントを、前記対象関連グループに対応する第２のメタルール又は第３のメタルールの影響イベントの１つとし、
前記対象種類群の中に、前記対象関連グループ以外の前記第２の関連グループ又は前記第３の関連グループに関する種類群にも含まれる第４の管理オブジェクトの種類と、前記第３の管理オブジェクトの種類とが含まれる場合、前記第４の管理オブジェクトの種類に関して作成された疑似的なイベントを、前記対象関連グループに対応する第２のメタルール又は第３のメタルールの影響イベントの１つとし、
前記対象種類群の中に１つの前記第４の管理オブジェクトの種類が含まれ、且つ、前記対象種類群の中に前記第３の管理オブジェクトの種類が含まれない場合、前記第４の管理オブジェクトの種類に関して作成された疑似的なイベントを、前記対象関連グループに対応する第２のメタルール又は第３のメタルールの原因イベントとし、
前記対象種類群の中に複数の前記第４の管理オブジェクトの種類が含まれ、且つ、前記対象種類群の中に前記第３の管理オブジェクトの種類が含まれない場合、複数の前記第４の管理オブジェクトの種類のうちの前記第３の管理オブジェクトの種類との間に介在する前記関連の数が最も少ない第５の管理オブジェクトの種類に関して作成された疑似的なイベントを、前記対象関連グループに対応する第２のメタルール又は第３のメタルールの原因イベントとし、前記第５の管理オブジェクトの種類以外の前記第４の管理オブジェクトの種類に関して作成された疑似的なイベントを、前記対象関連グループに対応する第２のメタルール又は第３のメタルールの影響イベントの１つとする、
請求項７に記載の管理システム。
【請求項９】
複数種類の管理オブジェクトを含む計算機システムの管理をコンピュータに実行させる管理プログラムであって、
前記管理オブジェクトの種類のいずれかに関する原因イベントを示す原因情報と、前記原因情報が示す原因イベントが原因となることの条件となる、前記管理オブジェクトの種類のいずれかに関する１以上の影響イベントを示す影響情報との入力を受け付け、
原因イベントと１以上の影響イベントとの対応関係を示すメタルールの原因イベントに関係する管理オブジェクトの種類と、当該メタルールの１以上の影響イベントに関係する管理オブジェクトの種類のそれぞれとの間の接続構成を示す１以上の関連の組み合わせである関連グループであって、前記原因情報が示す原因イベントに関係する管理オブジェクトの種類と、前記影響情報が示す１以上の影響イベントに関係する管理オブジェクトの種類のそれぞれとの間の接続構成を示す第１の関連グループを、前記第１の関連グループを構成する複数の前記関連のそれぞれに関する変更頻度に基づいて、変更頻度が所定値以上の前記関連によって構成される１以上の第２の関連グループと、変更頻度が前記所定値より小さい前記関連によって構成される１以上の第３の関連グループとに分割し、
前記１以上の第２の関連グループのそれぞれに対応する１以上の第２のメタルールと、前記１以上の第３の関連グループのそれぞれに対応する１以上の第３のメタルールとを生成する
管理プログラム。
【請求項１０】
前記１以上の第２のメタルール及び前記１以上の第３のメタルールは、当該複数のメタルール全体で、前記原因情報が示す原因イベントと前記影響情報が示す１以上の影響イベントとの対応関係を示す
請求項９に記載の管理プログラム。
【請求項１１】
前記１以上の第２のメタルール、前記１以上の第３のメタルール、及び前記計算機システムに含まれる複数の管理オブジェクト及び当該複数の管理オブジェクト間の接続関係を示す構成情報に基づいて、メタルールの原因イベント及び影響イベントに関係する管理オブジェクトの種類を特定の管理オブジェクトを示すデータで表した展開ルールであって、前記１以上の第２のメタルールに対応する１以上の第２の展開ルールと、前記１以上の第３のメタルールに対応する１以上の第３の展開ルールとを生成し、
前記１以上の第２の展開ルール及び前記１以上の第３の展開ルールに基づいて、前記複数の管理オブジェクトのいずれかで発生したイベントの原因解析を行う
請求項９に記載の管理プログラム。
【請求項１２】
前記影響情報が示す影響イベントに対応する第１のイベントが発生した場合に、前記１以上の第２の展開ルール及び前記１以上の第３の展開ルールのうちの前記第１のイベントの原因解析に利用される展開ルールであって記憶デバイスに記憶されていない展開ルールを生成し、当該生成した展開ルールを前記記憶デバイスに記憶し、
前記構成情報が変更された場合に、前記記憶デバイスに記憶されている１以上の展開ルールの中から変更後の前記構成情報と矛盾が生じた展開ルールを特定し、当該特定した展開ルールを前記記憶デバイスから削除する
請求項１１に記載の管理プログラム。
【請求項１３】
前記計算機システムに含まれる複数の管理オブジェクトのうちの第１の管理オブジェクトと第２の管理オブジェクトとの間の接続関係が変更された場合、前記変更頻度情報が示す変更頻度のうちの、前記第１の管理オブジェクトの種類と前記第２の管理オブジェクトの種類との間の接続関係を示す第１の関連に関する変更頻度を更新し、
前記第１の関連に関する更新前の変更頻度が前記所定値よりも小さく、且つ、前記第１の関連に関する更新後の変更頻度が前記所定値以上である場合、記憶デバイスに記憶されているメタルールのうちの前記第１の関連を含む関連グループに対応する第１のメタルールについて、前記第１のメタルールに関する関連グループを、前記第１の関連グループとして前記１以上の第２の関連グループと前記１以上の第３の関連グループとに分割し、前記１以上の第２のメタルールと前記１以上の第３のメタルールとを生成することにより、前記第１のメタルールを前記１以上の第２のメタルールと前記１以上の第３のメタルールとに分割する
請求項９に記載の管理プログラム。
【請求項１４】
前記１以上の第２のメタルール及び前記１以上の第３のメタルールを生成する場合において、
前記第１の関連グループに含まれるいずれか複数の前記関連によって示される、２つの管理オブジェクトの種類間を結ぶ経路ごとに、当該経路を、変更頻度が前記所定値以上の前記関連によって構成される１以上の第１の経路と、変更頻度が前記所定値より小さい前記関連によって構成される１以上の第２の経路とに分割し、前記第１の経路を示す１以上の前記関連の組み合わせを前記第２の関連グループの１つとし、前記第２の経路を示す１以上の前記関連の組み合わせを前記第３の関連グループの１つとする
請求項９に記載の管理プログラム。
【請求項１５】
前記１以上の第２のメタルール及び前記１以上の第３のメタルールを生成する場合において、
前記関連グループを構成する１以上の前記関連に関係する複数の管理オブジェクトの種類の組み合わせである種類群であって、前記１以上の第２の関連グループ及び前記１以上の第３の関連グループのうちの一の対象関連グループに関する対象種類群の中に、前記原因情報が示す原因イベントに関係する第３の管理オブジェクトの種類が含まれる場合、前記原因情報が示す原因イベントを、前記対象関連グループに対応する第２のメタルール又は第３のメタルールの原因イベントとし、
前記対象種類群の中に、前記影響情報が示す影響イベントに関係する管理オブジェクトの種類が含まれる場合、当該影響イベントを、前記対象関連グループに対応する第２のメタルール又は第３のメタルールの影響イベントの１つとし、
前記対象種類群の中に、前記対象関連グループ以外の前記第２の関連グループ又は前記第３の関連グループに関する種類群にも含まれる第４の管理オブジェクトの種類と、前記第３の管理オブジェクトの種類とが含まれる場合、前記第４の管理オブジェクトの種類に関して作成された疑似的なイベントを、前記対象関連グループに対応する第２のメタルール又は第３のメタルールの影響イベントの１つとし、
前記対象種類群の中に１つの前記第４の管理オブジェクトの種類が含まれ、且つ、前記対象種類群の中に前記第３の管理オブジェクトの種類が含まれない場合、前記第４の管理オブジェクトの種類に関して作成された疑似的なイベントを、前記対象関連グループに対応する第２のメタルール又は第３のメタルールの原因イベントとし、
前記対象種類群の中に複数の前記第４の管理オブジェクトの種類が含まれ、且つ、前記対象種類群の中に前記第３の管理オブジェクトの種類が含まれない場合、複数の前記第４の管理オブジェクトの種類のうちの前記第３の管理オブジェクトの種類との間に介在する前記関連の数が最も少ない第５の管理オブジェクトの種類に関して作成された疑似的なイベントを、前記対象関連グループに対応する第２のメタルール又は第３のメタルールの原因イベントとし、前記第５の管理オブジェクトの種類以外の前記第４の管理オブジェクトの種類に関して作成された疑似的なイベントを、前記対象関連グループに対応する第２のメタルール又は第３のメタルールの影響イベントの１つとする、
請求項９に記載の管理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、例えば、サーバ、ストレージ、およびネットワーク装置等の管理オブジェクトを含む計算機システムを管理する技術に関する。
【背景技術】
【０００２】
計算機システムを管理する技術として、システム内で検知された複数の障害または障害の兆候に基づいてその障害等の原因を解析する技術が知られている。例えば、特許文献１に開示された障害解析システムは、管理ソフトウェアを用いて、管理対象装置または管理対象装置に含まれるコンポーネントにおいて発生した障害等のイベントに関するデータをイベントＤＢ（データベース）に蓄積する。また、この障害解析システムは、管理対象装置等において発生する複数のイベントの因果関係を解析するための解析エンジンを持っている。この解析エンジンは、管理対象装置等の構成情報が格納されている構成管理ＤＢにアクセスして、或るＩ／Ｏ（入出力）経路上に存在する複数の管理対象装置等間の関係を「トポロジ」と呼ばれる１つのグループとして認識する。そして、解析エンジンは、イベントが発生すると、発生したイベントに関係する管理対象装置等を含むトポロジに、事前に定められた、ＩＦ部およびＴＨＥＮ部を含むメタルールを適用して、障害の原因を解析するための展開ルールを構築する。展開ルールは、根本原因となり得る原因イベントと、原因イベントが発生した場合に引き起こされる１以上の影響イベントとの関係を示す情報である。具体的には、ルールのＴＨＥＮ部に原因イベントが記載され、ルールのＩＦ部に影響イベントが記載される。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】国際公開第２０１０／１２２６０４号パンフレット
【発明の概要】
【発明が解決しようとする課題】
【０００４】
特許文献１に開示された障害解析システムは、あるパターンのトポロジにおいて発生し得る影響イベントの組合せと、そのトポロジのパターンにおいて障害の原因候補となる原因イベントとの対応関係を示すＩＦ−ＴＨＥＮ形式のメタルールを複数用意する。【０００５】
そして、メタルールに適用されるトポロジを構成する管理対象装置群を構成管理ＤＢを参照して特定し、メタルールにトポロジを適用することで、１以上の影響イベントと、その１以上の影響イベントが発生した場合の障害の原因候補となる原因イベントとの対応関係を計算機システムの実構成に依存する形式で示したＩＦ−ＴＨＥＮ形式の展開ルールを生成する。【０００６】
障害解析システムは、展開ルールのＩＦ部に記載された影響イベントの発生率を計算することによって、ＴＨＥＮ部に記載された原因イベントが原因であることの確からしさを示す指標値（以下「確信度」と称する）を算出する。算出した確信度と原因候補は、運用管理者およびルール作成者を含むユーザの求めに応じＧＵＩ（Graphical User Interface）を介して表示される。また、ＩＦ部に記載された影響イベントに関する情報も、原因候補に対する影響範囲として、原因候補に関する情報と合わせて表示される。これにより、ユーザは、計算機システムで発生したイベントがどの障害に起因して発生したものなのかを知ることができる。【０００７】
しかしながら、このような従来の障害解析システムにおいては、障害解析システムがあらかじめ適切なメタルールを保持していないと、ユーザにとって適切な解析結果を表示できない。そこで、不足しているメタルールがある場合、ユーザがメタルールを追加する必要がある。しかし、メタルールを追加する場合には、メタルールの生成とともに、そのメタルールに適用されるトポロジを特定する手段をも生成する必要がある。【０００８】
一方、大規模システムを対象とした障害解析システムでは、展開ルールの生成をイベント発生後にオンデマンドで実施する方が望ましい。なぜなら、大規模システムを対象とした場合、解析に必要なすべての展開ルールを事前に準備しようとすると、展開ルールの構築に要する時間が膨大となるためである。また、展開ルールの生成をオンデマンドで実施する障害解析システムでは、一度作成した展開ルールについては記憶領域上に保持し続け、次に同じイベントが発生した場合に再利用することで、展開ルールの構築に要する時間を短縮することが可能である。【０００９】
しかし、計算機システム内の管理対象装置に構成変更があった場合に、以前に作成した展開ルールをそのまま使い続けると、古い構成情報に基づいた誤った解析結果を出力してしまうとういう問題がある。この問題を解決するためには、管理対象装置において構成変更が検知された場合に、障害解析システムが、変更後の構成と矛盾が生じるようになった展開ルールを特定し、特定した展開ルールを削除する必要がある。削除された展開ルールに対応する、変更後の構成に基づく展開ルールは、その展開ルールに関係するイベントが再び発生した際に生成される。【００１０】
メタルールの中には、展開ルールの構築に必要なトポロジを取得する際、構成管理ＤＢに何度も構成情報の問い合わせを行わなければならないメタルール、例えば、適用されるトポロジの規模が比較的大きいメタルールもある。その場合、メタルールに適用されるトポロジの一部が変化しただけでも、そのトポロジの全体についての問い合わせを再実行する必要がある。従って、例えば、或る管理対象装置における構成変更が頻発しかつその管理対象装置に関するイベントの発生も頻発している場合、そのイベントに関係する展開ルールが何度も再構築されることになるが、その再構築に必要なトポロジを取得する際に、そのトポロジにおける変化のない部分、すなわち上記或る管理対象装置以外の装置に関わる部分についても、何度も構成管理ＤＢへの問い合わせが行われることとなり、結果として展開ルールの構築に要する時間が長くなってしまう。そして、原因解析の際に行われる展開ルールの構築に要する時間が長くなれば、原因解析に要する時間も長くなる。
【課題を解決するための手段】
【００１１】
第１の観点に係る管理システムは、複数種類の管理オブジェクトを含む計算機システムの管理を行う。管理システムの記憶デバイスは、管理オブジェクトの種類のいずれかに関する原因イベントと、原因イベントが原因となることの条件となる、管理オブジェクトの種類のいずれかに関する１以上の影響イベントとの対応関係を示す１以上のメタルールと、管理オブジェクトの種類のうちの２つの種類間の接続関係を示す関連ごとに、当該関連に関する変更頻度を示す変更頻度情報とを記憶する。管理システムの制御デバイスは、メタルールの原因イベントに関係する管理オブジェクトの種類と、当該メタルールの１以上の影響イベントに関係する管理オブジェクトの種類のそれぞれとの間の接続構成を示す１以上の関連の組み合わせである関連グループであって、記憶デバイスに記憶されている第１のメタルールに関する第１の関連グループを、第１の関連グループを構成する複数の関連のそれぞれに関する変更頻度に基づいて、変更頻度が所定値以上の関連によって構成される１以上の第２の関連グループと、変更頻度が所定値より小さい関連によって構成される１以上の第３の関連グループとに分割し、第１のメタルールを、１以上の第２の関連グループのそれぞれに対応する１以上の第２のメタルールと、１以上の第３の関連グループのそれぞれに対応する１以上の第３のメタルールとに分割する。【００１２】
第２の観点に係る管理システムは、複数種類の管理オブジェクトを含む計算機システムの管理を行う。管理システムの記憶デバイスは、管理オブジェクトの種類のうちの２つの種類間の接続関係を示す関連ごとに、当該関連に関する変更頻度を示す変更頻度情報を記憶する。管理システムの制御デバイスは、管理オブジェクトの種類のいずれかに関する原因イベントを示す原因情報と、原因情報が示す原因イベントが原因となることの条件となる、管理オブジェクトの種類のいずれかに関する１以上の影響イベントを示す影響情報との入力を受け付け、原因イベントと１以上の影響イベントとの対応関係を示すメタルールの原因イベントに関係する管理オブジェクトの種類と、当該メタルールの１以上の影響イベントに関係する管理オブジェクトの種類のそれぞれとの間の接続構成を示す１以上の関連の組み合わせである関連グループであって、原因情報が示す原因イベントに関係する管理オブジェクトの種類と、影響情報が示す１以上の影響イベントに関係する管理オブジェクトの種類のそれぞれとの間の接続構成を示す第１の関連グループを、第１の関連グループを構成する複数の関連のそれぞれに関する変更頻度に基づいて、変更頻度が所定値以上の関連によって構成される１以上の第２の関連グループと、変更頻度が所定値より小さい関連によって構成される１以上の第３の関連グループとに分割し、１以上の第２の関連グループのそれぞれに対応する１以上の第２のメタルールと、１以上の第３の関連グループのそれぞれに対応する１以上の第３のメタルールとを生成する。
【発明の効果】
【００１３】
原因解析に要する時間を削減することができる。
【図面の簡単な説明】
【００１４】
【図１Ａ】図１Ａは、実施例１に係る計算機システムの構成、および管理コンピュータの内部構成の一例を示す図である。
【図１Ｂ】図１Ｂは、実施例１に係る計算機システムの構成、並びに、サーバ、ＦＣスイッチ、およびストレージの内部構成の一例を示す図である。
【図２Ａ】図２Ａは、実施例１に係る障害イベントテーブルの一例の構成図である。
【図２Ｂ】図２Ｂは、実施例１に係る変更イベントテーブルの一例の構成図である。
【図３Ａ】図３Ａは、実施例１に係るメタルールの第１の例を示す図である。
【図３Ｂ】図３Ｂは、実施例１に係るメタルールの第２の例を示す図である。
【図３Ｃ】図３Ｃは、実施例１に係るメタルールの第３の例を示す図である。
【図３Ｄ】図３Ｄは、実施例１に係るメタルールの第４の例を示す図である。
【図４】図４は、実施例１に係るサーバテーブルの一例の構成図である。
【図５】図５は、実施例１に係るＦＣスイッチテーブルの一例の構成図である。
【図６】図６は、実施例１に係るストレージテーブルの一例の構成図である。
【図７】図７は、実施例１に係るＨＢＡテーブルの一例の構成図である。
【図８】図８は、実施例１に係るディスクドライブテーブルの一例の構成図である。
【図９】図９は、実施例１に係る論理ボリュームテーブルの一例の構成図である。
【図１０】図１０は、実施例１に係るＲＡＩＤグループテーブルの一例の構成図である。
【図１１】図１１は、実施例１に係るストレージポートテーブルの一例の構成図である。
【図１２】図１２は、実施例１に係るストレージディスクテーブルの一例の構成図である。
【図１３】図１３は、実施例１に係るストレージコントローラテーブルの一例の構成図である。
【図１４】図１４は、実施例１に係る管理オブジェクトの種類間の関連を示す一例のクラス図である。
【図１５】図１５は、実施例１に係る関連テーブルの一例の構成図である。
【図１６Ａ】図１６Ａは、実施例１に係るトポロジ取得方式データの第１の例を示す図である。
【図１６Ｂ】図１６Ｂは、実施例１に係るトポロジ取得方式データの第２の例を示す図である。
【図１６Ｃ】図１６Ｃは、実施例１に係るトポロジ取得方式データの第３の例を示す図である。
【図１６Ｄ】図１６Ｄは、実施例１に係るトポロジ取得方式データの第４の例を示す図である。
【図１６Ｅ】図１６Ｅは、実施例１に係るＳＱＬデータの一例の構成図である。
【図１７Ａ】図１７Ａは、実施例１に係るトポロジデータの第１の例を示す図である。
【図１７Ｂ】図１７Ｂは、実施例１に係るトポロジデータの第２の例を示す図である。
【図１７Ｃ】図１７Ｃは、実施例１に係るトポロジデータの第３の例を示す図である。
【図１８Ａ】図１８Ａは、実施例１に係る展開ルールの第１の例を示す図である。
【図１８Ｂ】図１８Ｂは、実施例１に係る展開ルールの第２の例を示す図である。
【図１８Ｃ】図１８Ｃは、実施例１に係る展開ルールの第３の例を示す図である。
【図１９】図１９は、実施例１に係るイベント情報入力処理の一例のフローチャートである。
【図２０】図２０は、実施例１に係るイベント情報入力画面の一例の構成図である。
【図２１】図２１は、実施例１に係るトポロジ取得方式探索処理の一例のフローチャートである。
【図２２】図２２は、実施例１に係る関連探索処理の一例のフローチャートである。
【図２３】図２３は、実施例１に係るトポロジ取得方式分割処理の一例のフローチャートである。
【図２４】図２４は、実施例１に係るメタルール生成処理の一例のフローチャートである。
【図２５Ａ】図２５Ａは、実施例１に係る障害解析処理の一例の第１フローチャートである。
【図２５Ｂ】図２５Ｂは、実施例１に係る障害解析処理の一例の第２フローチャートである。
【図２６Ａ】図２６Ａは、実施例１に係るルール展開処理の一例の第１フローチャートである。
【図２６Ｂ】図２６Ｂは、実施例１に係るルール展開処理の一例の第２フローチャートである。
【図２７】図２７は、実施例１に係るルール削除処理の一例のフローチャートである。
【図２８】図２８は、実施例２に係る障害解析処理の一例のフローチャートである。
【図２９】図２９は、実施例２に係るメタルール再構築処理の一例のフローチャートである。
【発明を実施するための形態】
【００１５】
幾つかの実施例を、図面を参照して説明する。なお、以下に説明する実施例は特許請求の範囲にかかる発明を限定するものではなく、また実施例の中で説明されている諸要素およびその組み合わせの全てが発明の解決手段に必須であるとは限らない。これらの図面において、複数の図を通じて同一の符号は同一の構成要素を示している。
【００１６】
また、実施例の説明において多くの具体的な事項を開示するが、当業者に明らかなように、本発明を実施するために、これらの具体的な事項の全てが必要とされるものではない。実施例の説明を無用に分かり難くしないよう、公知の構造、材料、回路、処理、およびインターフェースについては詳細に記述せず、および／またはブロック図の形式で示す場合がある。
【００１７】
さらに、以下の説明において、コンピュータ内部の主な動作について、アルゴリズム的記述または記号的表現を用いて説明する。これらのアルゴリズム的記述および記号的表現は、データ処理技術に精通した当業者がコンピュータの動作を他の当業者に最も効果的に伝達するために用いられる手段である。アルゴリズムとは、所望の最終状態または結果に達する一連の定義されたステップである。実施例における各ステップは、有形の結果を実現するための有形の量を物理的に操作することを要求する。
【００１８】
但し、通常は必須ではないが、これらの量は、保存、転送、結合、比較、および他の操作が可能な電気または磁気の信号の形式をなす。原理的に共通に利用できるとの理由で、これらの信号をビット、値、要素、記号、文字、項目、数、命令等と称することが往々にして便利であることが分かっている。しかし、これらの全ておよび同様の項目は、適切な物理量に関連付けられるべきものであり、これら物理量に付けられた便宜的なラベルに過ぎないことに留意すべきである。
【００１９】
特に別途明言しない限り、以下の記述から明らかなように、本明細書の記述を通じて、「処理する」、「計算する」、「算出する」、「判定する」、「表示する」等の用語を用いた説明は、コンピュータシステムまたは当該コンピュータシステムのレジスタおよびメモリ内の物理的（電子的）な量として表現されたデータを操作して、当該コンピュータシステムのメモリまたはレジスタまたは他の情報記憶、伝送または表示装置内の物理量として同様に表現された他のデータに変換する他の情報処理装置の動作および処理を含んでいてよい。
【００２０】
また、管理システムは、１つ以上のコンピュータプログラムにより選択的に起動または再設定される１つ以上の汎用コンピュータを含んでもよい。管理システムを動作させるコンピュータプログラムは、例えば、光ディスク、磁気ディスク、読出専用メモリ、ランダムアクセスメモリ、固体装置（solid-state device）、および、ドライブ等のコンピュータ可読記憶媒体、または電子情報の保存に適している他の任意の媒体に保存できるが、これらに限定されない。
【００２１】
なお、以後の説明では「ａａａテーブル」等の表現にて本発明の情報を説明するが、これら情報はテーブル等のデータ構造以外で表現されていてもよい。そのため、データ構造に依存しないことを示すために「ａａａテーブル」等について「ａａａ情報」と呼ぶことがある。
【００２２】
さらに、各情報の内容を説明する際に、「識別情報」、「識別子」、「名称」、「ＩＤ」という表現を用いるが、これらについては互いに置換が可能である。
【００２３】
以後の説明では「プログラム」を主語として説明を行う場合があるが、プログラムはプロセッサによって実行されることで定められた処理をメモリおよび通信ポート（ネットワークＩ／Ｆ、ＨＢＡ、Ｉ／Ｏポート、ポート）を用いながら行うため、プロセッサを主語とした説明としてもよい。また、プログラムを主語として開示された処理は、管理サーバ等の計算機、情報処理装置が行う処理としてもよい。また、プログラムの一部または全ては、専用ハードウェアによって実現されてもよい。プロセッサ又はプロセッサとそのような専用ハードウェアとを含んだデバイスが「制御デバイス」と呼ばれて良い。また、各種プログラムは、プログラム配布サーバや、計算機が読み取り可能な記憶メディア（computer-readable memory media）によって各計算機にインストールされてもよい。
【００２４】
なお、管理計算機は入出力デバイスを有する。入出力デバイスの例としてはディスプレイとキーボードとポインタデバイスが考えられるが、これ以外のデバイスであってもよい。また、入出力デバイスの代替としてシリアルインターフェースやイーサーネットインターフェースを入出力デバイスとし、当該インターフェースにディスプレイまたはキーボードまたはポインタデバイスを有する表示用計算機を接続し、表示用情報を表示用計算機に送信したり、入力用情報を表示用計算機から受信することで、表示用計算機で表示を行ったり、入力を受け付けることで入出力デバイスでの入力および表示を代替してもよい。
【００２５】
以後、計算機システムを管理し、本発明の表示用情報を表示する１つ以上の計算機の集合を管理システムと呼ぶことがある。管理コンピュータが表示用情報を表示する場合は管理コンピュータが管理システムである、また、管理コンピュータと表示用計算機の組み合わせも管理システムである。また、管理処理の高速化や高信頼化のために複数の計算機で管理コンピュータと同等の処理を実現してもよく、この場合は当該複数の計算機（表示を表示用計算機が行う場合は表示用計算機も含め）が管理システムである。
【００２６】
本明細書に示すアルゴリズムおよびディスプレイは、いかなる特定のコンピュータまたは他の装置にも本質的には関係しない。各種の汎用システムを、本明細書の開示によるプログラムおよびモジュールと共に用いてもよいが、所望の方法のステップを実行するための、より特化した装置を構築した方が便利な場合がある。これら各種のシステムの構造は以下に開示する説明で明らかになる。また、本明細書は、いかなる特定のプログラミング言語も前提としては記述していない。コンピュータを動作させる各種プログラムのプログラミング言語として、様々な種類のプログラミング言語を用いることができる。プログラミング言語の命令は、１つ以上の処理装置、例えば、プロセッサ、コントローラ等によって実行される。
【００２７】
＜実施例の概要＞
【００２８】
以下で説明する幾つかの実施例は、障害解析用ルールの作成における作業工数を削減する効果を有する障害解析用ルール作成支援、および、それらルールに基づいて障害解析を実行する装置、方法、およびコンピュータプログラムに関する。
【００２９】
管理コンピュータは、複数の管理対象装置を管理するコンピュータである。管理対象装置の種類としては、例えば、サーバ、ネットワーク装置、ＮＡＳ（Network Attached Storage）、ストレージ装置等がある。ネットワーク装置には、ＩＰ（Internet Protocol）スイッチ、ルータ、ＦＣ（ファイバチャネル）スイッチ等が含まれる。また、管理対象装置に含まれるデバイス等の論理的または物理的な構成物を「コンポーネント」と称する。コンポーネントの種類としては、例えば、通信ポート、ＣＰＵ（Central Processing Unit）、メモリ、ディスク、プログラム、仮想マシン、ストレージ装置内部で定義される論理ボリューム、ＲＡＩＤ（Redundant Arrays of Inexpensive Disks）グループ等がある。なお、管理対象装置とコンポーネントとを区別せずに扱う場合は「管理オブジェクト」と称する。すなわち、「管理オブジェクト」とは、管理対象装置またはコンポーネントのことである。
【００３０】
管理コンピュータは、管理オブジェクトの構成を示す構成情報、管理オブジェクトで発生したイベントを示す情報（以下「イベント情報」と称する）を管理対象装置から取得する。また、管理コンピュータは、管理オブジェクトの構成の変化（構成変更）についてもイベントとして扱う。以下、管理オブジェクトの構成変更に対応するイベントを「変更イベント」と称し、変更イベントと区別するために、原因解析の対象となる障害や性能の変化等のイベントを「障害イベント」と称する。また、障害イベントを示すイベント情報を「障害イベント情報」と称し、変更イベントを示すイベント情報を「変更イベント情報」と称する。なお、管理コンピュータが、管理対象装置から受信した構成情報に基づいて管理対象装置の構成変更を検知し、対応する変更イベント情報を生成してもよい。
【００３１】
管理コンピュータは、管理オブジェクトにおける障害イベントの発生を検知すると、発生した１以上の障害イベントの組み合せから障害を解析して原因を特定する解析エンジン、および、障害を解析する上で必要となるルールの作成および削除を支援するルール作成エンジンを有する。
【００３２】
解析エンジンは、管理オブジェクトの構成情報が格納されている構成管理ＤＢにアクセスして、Ｉ／Ｏ経路上に存在する複数の管理オブジェクト間の関係を、「トポロジ」と称される１つのグループとして認識する。また、障害が解析される前に予め用意される障害解析用のルールは、メタルールと称され、或るパターンのトポロジに含まれる管理オブジェクトにおいて発生し得る障害イベント（影響イベント）の組合せと、それらの影響イベントが発生した場合に障害の原因候補となる障害イベント（原因イベント）との対応関係が、計算機システムの実構成に依存しない形式で記述される。すなわち、メタルールは、管理オブジェクトの種類のいずれかに関する原因イベントと、原因イベントが原因となることの条件となる、管理オブジェクトの種類のいずれかに関する１以上の影響イベントとの対応関係を示すデータである。解析エンジンは、或る管理オブジェクトにおける障害イベントを検知すると、検知した障害イベントに関連するメタルール、すなわち検知した障害イベントを影響イベントとして含むメタルールをメタルールリポジトリから取得し、障害イベントが発生した管理オブジェクトを含むトポロジの情報を構成管理ＤＢから取得する。そして、解析エンジンは、メタルールに記述された１以上の影響イベントおよび原因イベントと、取得したトポロジの情報とに基づいて、メタルールを計算機システムの実構成に依存する形式に展開した展開ルールを構築する。そして、解析エンジンは、展開ルールを用いて、発生した障害イベントの原因候補を特定し、運用管理者に通知する。
【００３３】
また、解析エンジンは、管理オブジェクトにおける構成変更を変更イベントとして検知した場合、その構成変更により現在の構成と矛盾が生じるようになった展開ルールを特定し、特定した展開ルールを管理コンピュータのメモリから削除する。具体的には、解析エンジンは、構成変更のあった管理オブジェクトを含むトポロジを特定し、そのトポロジを構築時に利用した展開ルールを削除する。
【００３４】
ルール作成エンジンは、メタルールの作成を支援する機能を有する。システム障害に関する知識を有するルール作成者が、原因イベントに関する情報および原因イベントによって連鎖的に引き起こされる影響イベントに関する情報を入力すると、ルール作成エンジンは、管理コンピュータの構成管理ＤＢのデータモデルに基づいて、原因イベントに関係するコンポーネントと影響イベントに関係するコンポーネントとの間のトポロジのパターンを導出する。そして、ルール作成エンジンは、導出されたパターンを持つトポロジを構成管理ＤＢ内の情報に基づいて特定する手段を決定し、入力された原因イベントおよび影響イベントに関するメタルールを生成する。
【００３５】
したがって、ルール作成エンジンは、入力された原因イベントおよび影響イベントに関する情報に基づいてメタルールを生成する際に、メタルールに適用されるトポロジを構成管理ＤＢ内の情報に基づいて特定する手段を示すデータを生成する。このため、ルール作成者は、管理コンピュータの構成管理ＤＢのデータモデルを含めた内部構造を学習することなくメタルールを作成することができ、また、解析エンジンは、生成したメタルールに基づいて、自動的に障害の原因を特定することができる。以下、メタルールに適用されるトポロジを構成管理ＤＢ内の情報に基づいて特定する手段を「トポロジ取得方式」と称し、トポロジ取得方式を示すデータを「トポロジ取得方式データ」と称する。
【００３６】
また、構成情報取得プログラムは、管理オブジェクトにおける構成変更の頻度を、例えば、管理オブジェクトの種類ごと、或いは管理オブジェクトの種類間の関連ごとに統計情報として管理する。ルール作成エンジンは、構成変更の頻度に基づいて、ルール作成者の入力情報に対応するメタルール或いは管理コンピュータに記憶されているメタルールを、意味論的に等しい複数のメタルールに分割する。ここで、「意味論的に等しい」とは、分割後の複数のメタルール全体が示す意味が、分割前のメタルールが示す意味と同等であることをいう。例えば、第１のメタルールが意味論的に等しい２つのメタルール（第２のメタルールおよび第３のメタルール）に分割された場合、第２のメタルールおよび第３のメタルールは、この２つのメタルール全体で、第１のメタルールの原因イベントと第１のメタルールの１以上の影響イベントとの対応関係を示すことになる。ルール作成エンジンは、例えば、構成変更の頻度に基づいて、メタルールを、変更頻度の高い関連を含むメタルールと、変更頻度のそれ程高くない関連を含むメタルールとに分割する。これにより、構成変更に伴う展開ルールの再生成に要する時間を削減できる。
【実施例１】
【００３７】
＜管理コンピュータのハードウェアおよび論理構成＞【００３８】
図１Ａは、実施例１に係る計算機システムの構成、および管理コンピュータの内部構成の一例を示す図である。図１Ｂは、実施例１に係る計算機システムの構成、並びに、サーバ、ＦＣスイッチ、およびストレージの内部構成の一例を示す図である。【００３９】
図１Ａに示すように、本実施例に係る計算機システムは、管理コンピュータ１０１、１つ以上のサーバ１０２（図１の例では、サーバＡおよびサーバＢ）、１つ以上のＦＣスイッチ１０５、１つ以上のストレージ１０４（図１の例では、ストレージＡおよびストレージＢ）、並びに、１つ以上のＩＰスイッチ１０３を有する。【００４０】
管理コンピュータ１０１、サーバ１０２、およびＦＣスイッチ１０５は、ＬＡＮ（ローカルエリアネットワーク）１０６等の通信ネットワークを介して通信可能に接続される。ストレージ１０４は、ＳＡＮ（ストレージエリアネットワーク）１０７等の通信ネットワークを介してサーバ１０２と通信可能に接続される。【００４１】
管理コンピュータ１０１は、ＣＰＵ１１１、メモリ１１２、ハードディスクドライブ（ディスク）１１３等の記憶媒体、入力デバイス１１４、出力デバイス１１７、およびネットワークＩ／Ｆ（インターフェース）１１５を含み、これらのデバイスがシステムバス１１６を介して接続される汎用コンピュータでよい。管理コンピュータ１０１のメモリ１１２は、メタルール生成プログラム１２１、イベント受信プログラム１２２、障害解析プログラム１２３、構成情報取得プログラム１２４、および表示モジュール１２５を記憶する。また、管理コンピュータ１０１のディスク１１３は、イベント情報リポジトリ１３１、構成管理ＤＢ１３２、関連テーブル（ＴＢＬ）１３３、トポロジ取得方式リポジトリ１３４、メタルールリポジトリ１３５、展開ルールリポジトリ１３６、およびトポロジリポジトリ１３７を記憶する。イベント情報リポジトリ１３１には、障害イベントテーブル（図２Ａ参照）と、変更イベントテーブル（図２Ｂ参照）とが格納される。構成管理ＤＢ１３２には、計算機システムに含まれる管理オブジェクトの構成を示すテーブル（以下「構成管理テーブル」と称する）が格納される。トポロジ取得方式リポジトリ１３４には、１以上のトポロジ取得方式データが格納される。メタルールリポジトリ１３５には、１以上のメタルールが格納される。展開ルールリポジトリ１３６には、１以上の展開ルールが格納される。トポロジリポジトリ１３７には、１以上のトポロジデータが格納される。【００４２】
メタルール生成プログラム１２１、イベント受信プログラム１２２、障害解析プログラム１２３、構成情報取得プログラム１２４、および表示モジュール１２５は、ＣＰＵ１１１によって実行される。これらのプログラム１２１〜１２５は、他の計算機の記憶媒体に記憶されてもよい。イベント情報リポジトリ１３１、構成管理データベース１３２、関連テーブル１３３、トポロジ取得方式リポジトリ１３４、メタルールリポジトリ１３５、および展開ルールリポジトリ１３６等のデータは、ディスク１１３以外の記憶媒体に記憶されてもよい。【００４３】
ネットワークＩ／Ｆ１１５は、ＬＡＮ１０６を介して接続されるサーバ１０２、ＩＰスイッチ１０３、ストレージ１０４、およびＦＣスイッチ１０５等の管理対象装置からイベント情報を取得する。出力デバイス１１７は、表示モジュール１２５が生成した情報を出力して運用管理者に提示するために用いられる。入力デバイス１１４は、運用管理者からの入力を受け付けるために用いられる。例えば、入力デバイス１１４としてキーボード、ポインタデバイス等を用いることができ、出力デバイス１１７としてディスプレイ、プリンタ等を用いることができるが、これら以外のデバイスでもよい。また、入力デバイス１１４および出力デバイス１１７の代わりに、シリアルインターフェースやイーサーネットインターフェースを用いてもよい。この場合、当該インターフェースにディスプレイ、キーボード、ポインタデバイス等を有する表示用計算機を接続し、表示用情報を表示用計算機に送信し、入力用情報を表示用計算機から受信することによって、表示用計算機において表示を行い、また、表示用計算機から入力を受け付けることによって、入力デバイス１１４および出力デバイス１１７の機能を代替してもよい。【００４４】
サーバ１０２は、当技術分野で公知であるように、アプリケーション等を実行する装置でよい。図１Ｂに示すように、サーバ１０２は、ＣＰＵ１４６、メモリ１４７、およびネットワークＩ／Ｆ１４４を含む汎用コンピュータでよい。サーバ２は、メモリ以外の記憶デバイス、例えばディスクを含んでもよい。サーバ１０２は、サーバ１０２自身の状態を監視し、特定の状態変化等が検出された場合にＬＡＮ１０６を介して管理コンピュータ１０１にイベント情報を送る監視エージェント１４１を含んでもよい。また、サーバ１０２は、ＳＡＮ１０７に接続するためのＨＢＡ（ホストバスアダプタ）１４２を含む。また、サーバ１０２は、ストレージ１０４の論理ボリューム１６５をマウントすることにより形成された仮想的なボリュームであるＳＣＳＩディスク（以下「ディスクドライブ」と称する）１５１を含む。サーバ１０２は、ディスクドライブ１５１を仮想的にローカルハードディスクのように利用できる。なお、ＳＣＳＩの代わりにまたはこれに加えて、他の通信プロトコルまたはストレージプロトコルが用いられてもよい。【００４５】
ストレージ１０４は、当該技術分野で公知であるように、サーバ１０２上で動作するアプリケーションが使用する記憶領域を提供するため、または他の目的のための装置でよい。ストレージ１０４は、ストレージコントローラ１６１、ＳＡＮ１０７に接続するためのＩ／Ｏポート（以下「ストレージポート」と称する）１６３、ＬＡＮ１０６に接続するためのネットワークＩ／Ｆ１６７、およびＲＡＩＤグループ１６４を有し、これらのデバイスが内部バス等を介して接続されている。なお、本実施例において、ＲＡＩＤグループ１６４が他のデバイスと接続されているとは、ＲＡＩＤグループ１６４を構成するストレージディスク１６２が他のデバイスと接続されていることを意味する。【００４６】
ＲＡＩＤグループ１６４を構成するストレージディスク（ＤＩＳＫ）１６２は、本実施例ではハードディスクドライブであるが、これに代えてまたは加えて、固体記憶媒体（ＳＳＤ）、光記憶媒体等、他の種類の記憶媒体が採用されてもよい。ＲＡＩＤグループ１６４は、１つ以上のストレージディスク１６２で構成されている。なお、ＲＡＩＤグループ１６４が複数のストレージディスク１６２によって構成されている場合、ＲＡＩＤグループ１６４は、ＲＡＩＤ構成を組んでいてもよい。また、ストレージ１０４には、ＲＡＩＤグループ１６４内の記憶領域に基づいて、１以上の論理ボリューム（ＶＯＬＵＭＥ）１６５が形成される。【００４７】
また、ストレージ１０４は、ストレージ１０４自身の状態を監視し、特定の状態変化等が検出された場合にＬＡＮ１０６を介して管理コンピュータ１０１にイベント情報を送る監視エージェント１６６を含んでもよい。なお、ストレージ１０４が監視エージェント１６６を含む代わりに、サーバ１０２の監視エージェント１４１が、ストレージ１０４の状態を監視してもよい。【００４８】
ＦＣスイッチ１０５は、当該技術分野で公知であるように、サーバ１０２とストレージ１０４とを接続するＳＡＮ１０７を構成するための、または他の目的のための装置であってよい。１つ以上のＦＣスイッチ１０５によって構成されたＳＡＮ１０７を介して、ストレージ１０４の論理ボリューム１６５がサーバ１０２に提供される。【００４９】
ＦＣスイッチ１０５は、サーバ１０２またはストレージ１０４から送信されるデータを受信し、かつ、受信したデータを送信するポート１７１を有する。また、ＦＣスイッチ１０５は、ＬＡＮ１０６に接続するためのネットワークインターフェース１７３を含んでいてよい。さらに、ＦＣスイッチ１０５は、ＦＣスイッチ１０５自身の状態を監視し、特定の状態変化等が検出された場合にＬＡＮ１０６を介して管理コンピュータ１０１にイベント情報を送る監視エージェント１７２を含んでもよい。なお、ＦＣスイッチ１０５が監視エージェント１７２を含む代わりに、サーバ１０２の監視エージェント１４１が、ＦＣスイッチ１０５の状態を監視してもよい。【００５０】
なお、本実施例において、管理オブジェクトについての参照符号付きの表記、例えば、サーバ１０２、ＦＣスイッチ１０５、ストレージ１０４、ＨＢＡ１４２、ストレージポート１６３等は、管理オブジェクトそれ自体を意味し、参照符号なしの表記、例えば、サーバ、ＦＣスイッチ、ストレージ、ＨＢＡ、ストレージポート等は、管理オブジェクトの種類を意味しているものとする。【００５１】
＜障害イベントテーブル＞【００５２】
図２Ａは、実施例１に係る障害イベントテーブルの一例の構成図である。【００５３】
障害イベントテーブル１３１Ａには、イベント受信プログラム１２２が管理対象装置の監視エージェント１４１、１６６、１７２から受信した障害イベント情報が格納される。【００５４】
障害イベントテーブル１３１Ａは、イベントＩＤ２０１、装置ＩＤ２０２、コンポーネントＩＤ２０３、イベント種別２０４、発生日時２０５、および処理済みフラグ２０６のフィールドを含む。イベントＩＤ２０１には、障害イベントを一意に識別するための識別情報が格納される。装置ＩＤ２０２には、障害イベントに関係する管理対象装置を一意に識別するための識別情報（装置ＩＤ）が格納される。コンポーネントＩＤ２０３には、障害イベントに関係するコンポーネントを一意に識別するための識別情報（コンポーネントＩＤ）が格納される。イベント種別２０４には、障害イベントの種類を示すデータが格納される。発生日時２０５には、障害イベントが発生した日時（発生日時）を示すデータが格納される。障害イベントの発生日時は、管理コンピュータ１０１が障害イベント情報を受信した日時でもよい。処理済みフラグ２０６には、障害イベントが障害解析処理（図２５Ａおよび図２５Ｂ参照）によって処理されたか否かを示すフラグ、例えば、処理されたことを示す「Ｙｅｓ」または未だ処理されていないことを示す「Ｎｏ」が格納される。なお、障害イベントがコンポーネントに関するイベントではなく管理対象装置に関するイベントである場合、コンポーネントＩＤ２０３には、例えば「ＮＵＬＬ」が格納される。【００５５】
例えば、図２Ａのエントリ２１１は、装置ＩＤが「ＳｔＡ」であるストレージ１０４、すなわちストレージＡ内のストレージディスク「ＤＩＳＫ１」（コンポーネントＩＤが「ＤＩＳＫ１」のストレージディスク１６２のことであり、以下、識別情報を用いて管理オブジェクトを特定する場合に同様の表記をする）において「Diskutilizationerror」（ディスク使用率上昇エラー）の障害イベントが２０１２年７月７日１５時０分０秒に発生したことを示している。【００５６】
＜変更イベントテーブル＞【００５７】
図２Ｂは、実施例１に係る変更イベントテーブルの一例の構成図である。【００５８】
変更イベントテーブル１３１Ｂには、イベント受信プログラム１２２が管理対象装置の監視エージェント１４１、１６６、１７２から受信した変更イベント情報が格納される。【００５９】
変更イベントテーブル１３１Ｂは、イベントＩＤ２５１、装置ＩＤ２５２、コンポーネントＩＤ２５３、エンティティ名２５６、イベント種別２５４、発生日時２５５、および処理済みフラグ２５６のフィールドを含む。イベントＩＤ２５１には、変更イベントを一意に識別するための識別情報が格納される。装置ＩＤ２５２には、変更イベントに関係する管理対象装置の装置ＩＤが格納される。コンポーネントＩＤ２５３には、変更イベントに関係するコンポーネントのコンポーネントＩＤが格納される。エンティティ名２５６には、変更イベントに関係するコンポーネントに関する構成管理テーブルにおいて、変更イベントに対応する構成変更によって値が変更されたフィールドを示すデータ、例えばフィールド名が格納される。イベント種別２５４には、変更イベントの種類を示すデータが格納される。例えば、イベント種別２５４には、管理オブジェクトが追加されたことを示す「ＡＤＤ」、管理オブジェクトが削除されたことを示す「ＤＥＬＥＴＥ」、または管理オブジェクトの構成が変化したことを示す「ＣＨＡＮＧＥ」が格納される。発生日時２５５には、変更イベントの発生日時を示すデータが格納される。変更イベントの発生日時は、管理コンピュータ１０１が変更イベント情報を受信した日時でもよい。処理済みフラグ２５６には、変更イベントが障害解析処理（図２５Ａおよび図２５Ｂ参照）によって処理されたか否かを示すフラグ、例えば、処理されたことを示す「Ｙｅｓ」または未だ処理されていないことを示す「Ｎｏ」が格納される。なお、変更イベントがコンポーネントに関するイベントではなく管理対象装置に関するイベントである場合、コンポーネントＩＤ２５３には、例えば「ＮＵＬＬ」が格納される。【００６０】
例えば、図２Ｂのエントリ２６１は、サーバ「ＳｖＡ」、すなわちサーバＡ内のディスクドライブ「ＤＲＩＶＥ１」に関する変更イベントを示している。そして、このエントリ２６１は、ディスクドライブ１５１に関する構成管理テーブル、すなわちディスクドライブテーブル（図８参照）における、サーバＡのディスクドライブ「ＤＲＩＶＥ１」に関するエントリのＨＢＡ＿ＷＷＮ８０４の値が２０１２年７月７日１６時０分０秒に変更されたことを示している。すなわち、エントリ２６１は、サーバＡのディスクドライブ「ＤＲＩＶＥ１」の接続先のＨＢＡ１４２が変更されたことを示している。【００６１】
なお、障害イベントテーブル１３１Ａおよび変更イベントテーブル１３１Ｂは、同一のテーブルによって構成されていても構わない。【００６２】
＜メタルールリポジトリおよびメタルール＞【００６３】
メタルールは、管理オブジェクトにおいて発生し得る１以上の障害イベント（影響イベント）と、それらの影響イベントが同じ或いは近いタイミングで発生した場合に障害の原因候補となる障害イベント（原因イベント）との対応関係を示す情報であり、影響イベント及び原因イベントに関係する管理オブジェクトを管理オブジェクトの種類で表した情報である。本実施例において、メタルールはＩＦ−ＴＨＥＮ形式で記述されるが、システム障害の原因事象および原因事象によって引き起こされる観測事象が記述されていれば、他の形式でもよい。【００６４】
図３Ａは、実施例１に係るメタルールの第１の例を示す図である。図３Ｂは、実施例１に係るメタルールの第２の例を示す図である。図３Ｃは、実施例１に係るメタルールの第３の例を示す図である。図３Ｄは、実施例１に係るメタルールの第４の例を示す図である。【００６５】
図３Ａに示すように、メタルール３００は、影響イベントを示す１以上の条件要素３１５を含むＩＦ部３１１と、原因イベントを示すＴＨＥＮ部３１２とを含む。【００６６】
メタルール３００は、ＩＦ部３１１の１以上の条件要素３１５がそれぞれ示す１以上の影響イベントが検知された場合に、ＴＨＥＮ部３１２が示す原因イベントが障害の原因となることを示す。したがって、ＴＨＥＮ部３１２のステータスが正常になれば、ＩＦ部３１１の問題も解決することが見込まれる。【００６７】
メタルール３００のＩＦ部３１１の各条件要素３１５は、装置種別、コンポーネント種別、およびイベント種別のフィールドを含む。条件要素３１５の装置種別には、影響イベントに関係する管理対象装置の種類を示すデータ、例えば、「サーバ」、「ストレージ」等が格納される。条件要素３１５のコンポーネント種別には、影響イベントに関係するコンポーネントの種類を示すデータ、例えば、「ディスクドライブ」、「ストレージコントローラ」、「論理ボリューム」、「ストレージディスク」等が格納される。影響イベントがコンポーネントに関するイベントではなく管理対象装置に関するイベントである場合、条件要素３１５のコンポーネント種別には、例えば「ＮＵＬＬ」が格納される。条件要素３１５のイベント種別には、影響イベントの種類を示すデータ、例えば、転送時間性能エラーを示す「AverageSecPerXferError」、Ｉ／Ｏレスポンスタイム上昇エラーを示す「IoResponseTimeError」、ディスク使用率上昇エラーを示す「DiskUtilizationError」等が格納される。【００６８】
メタルール３００のＴＨＥＮ部３１２も、ＩＦ部３１１の各条件要素３１５と同様に、装置種別、コンポーネント種別、およびイベント種別のフィールドを含む。ＴＨＥＮ部３１２の装置種別には、原因イベントに関係する管理対象装置の種類を示すデータが格納される。ＴＨＥＮ部３１２のコンポーネント種別には、原因イベントに関係するコンポーネントの種類を示すデータが格納される。原因イベントがコンポーネントに関するイベントではなく管理対象装置に関するイベントである場合、ＴＨＥＮ部３１２のコンポーネント種別には、例えば「ＮＵＬＬ」が格納される。ＴＨＥＮ部３１２のイベント種別には、原因イベントの種類を示すデータが格納される。【００６９】
また、メタルール３００は、当該メタルール３００を一意に識別するための識別情報（メタルールＩＤ）が格納されるフィールドであるメタルールＩＤ３１３を含む。また、メタルール３００は、当該メタルール３００に関連付けられた１以上のトポロジ取得方式の識別情報（方式ＩＤ）が格納されるフィールドであるトポロジ取得方式ＩＤ３１４を含む。メタルール３００に関連付けられた１以上のトポロジ取得方式に従って生成されたトポロジデータが当該メタルール３００に適用されることで、当該メタルール３００を計算機システムの実構成に依存する形式に展開した展開ルールが生成される。なお、複数のメタルール３００のそれぞれに、同じトポロジ取得方式が関連付けられてもよい。【００７０】
例えば、図３Ａが示すメタルール３００Ａ（メタルールＩＤが「ＭｅｔａＲｕｌｅ１」のメタルール３００）は、観測事象として、サーバのディスクドライブにおける転送時間性能エラーと、ストレージの論理ボリュームにおけるＩＯレスポンスタイム上昇エラーと、ストレージのストレージディスクにおけるディスク使用率上昇エラーとが検知され、ストレージのストレージコントローラにおけるＣＰＵ使用率上昇エラーが検知されない場合、ストレージのストレージディスクにおけるディスク使用率上昇エラーが原因であると結論付けられることを示す。なお、イベント種別に「NOT CpuLoadError」が格納されている条件要素３１５は、ストレージのストレージコントローラにおけるＣＰＵ使用率上昇エラー（「CpuLoadError」）の障害イベントが発生しないことが条件となることを示している。【００７１】
また、メタルール３００Ａについて展開ルールが生成される場合、トポロジ取得方式ＩＤ３１４に格納されている方式ＩＤに対応するトポロジ取得方式データが、トポロジ取得方式リポジトリ１３４から取得される。そして、メタルール３００Ａから展開ルールを生成するのに必要なトポロジデータが、取得されたトポロジ取得方式データ及び構成管理ＤＢ１３２内の情報に基づいて生成される。なお、ＩＦ部３１１に含まれる条件要素３１５として、管理オブジェクトが正常であること、すなわち障害イベントが発生していないことを定義してもよい。また、ＴＨＥＮ部３１２の原因イベントは、新たに定義された障害イベントであってもよく、イベント受信プログラム１２２が受信するイベント情報が示す障害イベントでなくてもよい。【００７２】
なお、一部の影響イベントは、管理オブジェクトで実際に発生する障害イベントではなく、分割前のメタルール３００と分割後の複数のメタルールとが意味論的に等しくなるように分割後の複数のメタルール３００を繋ぎあわせる役割を持つ疑似的な障害イベント（以下「中間イベント」と称する）である。例えば、図３Ｂのメタルール３００Ｂおよび図３Ｄのメタルール３００Ｄにおける「ＭｉｄＥｒｒｏｒ１」の障害イベントは、中間イベントであり、メタルール３００Ｂとメタルール３００Ｄとを繋ぎあわせる役割を持つ。そして、メタルール３００Ｂは「ＭｉｄＥｒｒｏｒ１」の中間イベントを原因イベントとして含み、メタルール３００Ｄは「ＭｉｄＥｒｒｏｒ１」の中間イベントを影響イベントとして含んでいるため、メタルール３００Ｄに対応する展開ルールのイベント受信率を算出する際には、メタルール３００Ｂに対応する展開ルールの各影響イベントがメタルール３００Ｄに対応する展開ルールの影響イベントに含まれるものとして扱われる。【００７３】
＜構成管理ＤＢ＞【００７４】
構成管理ＤＢ１３２は、構成情報取得プログラム１２４が監視エージェント１４１、１６６、１７２等から取得した構成情報に基づいて生成された構成管理テーブルが格納される。構成管理テーブルは、管理オブジェクト間のデータの入出力関係、接続関係、依存関係等を示す情報を含む。トポロジは、これら関連の組み合わせによって表現することができる。【００７５】
本実施例において、構成管理テーブルは、管理オブジェクトの種類ごとに作成される。サーバ、ＦＣスイッチ、ストレージ、およびこれらの管理対象装置が含むコンポーネントの種類のそれぞれに関する構成管理テーブルについて、図４〜図１３を用いて説明する。【００７６】
本実施例において、構成管理テーブルの名称は、当該構成管理テーブルによって構成が示される管理オブジェクトの種類を示し、各テーブルの１つのエントリは、１つの管理オブジェクトを示す。ただし、管理オブジェクトの種類ごとに構成管理テーブルが作成される必要はなく、各エントリに対して、管理オブジェクトの種類を示す情報が格納されてもよい。また、１つの管理オブジェクトの情報が複数のエントリに登録されてもよい。【００７７】
また、本実施例においては、管理オブジェクト間の関連を、各テーブルのフィールドの値を等しくすることによって表現しているが、管理オブジェクトの情報とは別に、関連の情報を記録したテーブルが別に用意されてもよい。【００７８】
なお、図４〜図１３に示された構成管理テーブルは一例であり、全てのフィールドが必須とされるわけではなく、一部のフィールドのみを有する構成としてもよいし、図４〜図１３に示されていない新たなフィールドを有する構成としてもよい。また、構成管理テーブルのデータ表現形式およびデータ構造は、管理対象装置が持つデータの表現形式およびデータ構造と異なってもよい。また、管理コンピュータ１０１が管理対象装置から受信するデータは、管理対象装置のデータ構造およびデータ表現形式のデータでもよい。【００７９】
また、管理オブジェクトの構成が変更されると、その構成変更に対応して構成管理テーブルの内容が更新される。構成管理テーブルの内容が更新される場合、更新前の情報も記録しておき、履歴情報によって過去の構成情報を参照できるようにしてもよい。【００８０】
図４は、実施例１に係るサーバテーブルの一例の構成図である。【００８１】
サーバテーブル４００は、サーバに関する構成管理テーブルである。サーバテーブル４００は、装置ＩＤ４０１、およびホスト名４０２のフィールドを含む。装置ＩＤ４０１には、サーバ１０２に付された装置ＩＤが格納される。ホスト名４０２には、運用管理者がサーバ１０２を一意に識別するための名称（ホスト名）が格納される。【００８２】
図５は、実施例１に係るＦＣスイッチテーブルの一例の構成図である。【００８３】
ＦＣスイッチテーブル５００は、ＦＣスイッチに関する構成管理テーブルである。ＦＣスイッチテーブル５００は、装置ＩＤ５０１、スイッチ名５０２、およびポート数５０３のフィールドを含む。装置ＩＤ５０１には、ＦＣスイッチ１０５に付された装置ＩＤが格納される。スイッチ名５０２には、運用管理者がＦＣスイッチ１０５を一意に識別するための名称（スイッチ名）が格納される。ポート数５０３には、ＦＣスイッチ１０５が持つポート数を示すデータが格納される。【００８４】
図６は、実施例１に係るストレージテーブルの一例の構成図である。【００８５】
ストレージテーブル６００は、ストレージに関する構成管理テーブルである。ストレージテーブル６００は、装置ＩＤ６０１、およびストレージ名６０２のフィールドを含む。装置ＩＤ６０１には、ストレージ１０４に付された装置ＩＤが格納される。ストレージ名６０２には、運用管理者がストレージ１０４を一意に識別するための名称（ストレージ名）が格納される。【００８６】
図７は、実施例１に係るＨＢＡテーブルの一例の構成図である。【００８７】
ＨＢＡテーブル７００は、ＨＢＡに関する構成管理テーブルである。ＨＢＡテーブル７００は、コンポーネントＩＤ７０１、ＷＷＮ７０２、装置ＩＤ７０３、および接続先ターゲットＷＷＮ７０４のフィールドを含む。【００８８】
コンポーネントＩＤ７０１には、ＨＢＡ１４２に付されたコンポーネントＩＤが格納される。ＷＷＮ７０２には、ＨＢＡ１４２に割り当てられたＷＷＮ（World Wide Name）が格納される。装置ＩＤ７０３には、ＨＢＡ１４２を含むサーバ１０２の装置ＩＤが格納される。装置ＩＤ７０３に格納される装置ＩＤは、サーバテーブル４００の装置ＩＤ４０１に格納される装置ＩＤと対応している。接続先ターゲットＷＷＮ７０４には、ＨＢＡ１４２がストレージ１０４の論理ボリューム１６５をマウントするために使用しているストレージポート１６３のＷＷＮが格納される。【００８９】
図８は、実施例１に係るディスクドライブテーブルの一例の構成図である。【００９０】
ディスクドライブテーブルは、ディスクドライブ１５１に関する構成管理テーブルである。ディスクドライブテーブル８００は、コンポーネントＩＤ８０１、ドライブ名８０２、装置ＩＤ８０３、ＨＢＡ＿ＷＷＮ８０４、およびＬＵＮ＿ＩＤ８０６のフィールドを含む。【００９１】
コンポーネントＩＤ８０１には、ディスクドライブ１５１に付されたコンポーネントＩＤが格納される。ドライブ名８０２には、ディスクドライブ１５１の名称が格納される。装置ＩＤ８０３には、ディスクドライブ１５１をマウントしているサーバ１０２の装置ＩＤが格納される。ＨＢＡ＿ＷＷＮ８０４には、ディスクドライブ１５１へのアクセスに使用されるＨＢＡ１４２のＷＷＮが格納される。ＬＵＮ＿ＩＤ８０６には、ディスクドライブ１５１に対応する論理ボリューム１６５のＬＵＮが格納される。ここで、ＬＵＮは、サーバ１０２が論理ボリューム１６５を識別するために利用する識別情報である。【００９２】
図９は、実施例１に係る論理ボリュームテーブルの一例の構成図である。【００９３】
論理ボリュームテーブル９００は、論理ボリュームに関する構成管理テーブルである。論理ボリュームテーブル９００は、コンポーネントＩＤ９０１、ポート番号９０２、ＬＵＮ＿ＩＤ９０３、装置ＩＤ９０４、容量９０５、およびＲＡＩＤグループ番号９０６のフィールドを含む。【００９４】
コンポーネントＩＤ９０１には、論理ボリューム１６５に付されたコンポーネントＩＤが格納される。ポート番号９０２には、論理ボリューム１６５を提供するために利用されるストレージポート１６３のポート番号が格納される。ここで、ポート番号は、ストレージポート１６３をストレージ１０４内で一意に識別するための識別情報である。ＬＵＮ＿ＩＤ９０３には、論理ボリューム１６５のＬＵＮが格納される。装置ＩＤ９０４には、論理ボリューム１６５を形成しているストレージ１０４の装置ＩＤが格納される。容量９０５には、論理ボリューム１６５の記憶領域の容量を示すデータが格納される。ＲＡＩＤグループ番号９０６には、論理ボリューム１６５を形成するための記憶領域を提供しているＲＡＩＤグループ１６４のＲＡＩＤグループ番号が格納される。ここで、ＲＡＩＤグループ番号は、ＲＡＩＤグループ１６４をストレージ１０４内で一意に識別するための識別情報である。【００９５】
図１０は、実施例１に係るＲＡＩＤグループテーブルの一例の構成図である。【００９６】
ＲＡＩＤグループテーブル１０００は、ＲＡＩＤグループに関する構成管理テーブルである。ＲＡＩＤグループテーブル１０００は、コンポーネントＩＤ１００１、ＲＡＩＤグループ番号１００２、装置ＩＤ１００３、容量１００４、およびＲＡＩＤレベル１００５のフィールドを含む。【００９７】
コンポーネントＩＤ１００１には、ＲＡＩＤグループ１６４に付されたコンポーネントＩＤが格納される。ＲＡＩＤグループ番号１００２には、ＲＡＩＤグループ１６４に付されたＲＡＩＤグループ番号が格納される。装置ＩＤ１００３には、ＲＡＩＤグループ１６４を含むストレージ１０４の装置ＩＤが格納される。容量１００４には、ＲＡＩＤグループ１６４の記憶領域の容量を示すデータが格納される。ＲＡＩＤレベル１００５には、ＲＡＩＤグループ１６４のＲＡＩＤレベルを示すデータが格納される。【００９８】
図１１は、実施例１に係るストレージポートテーブルの一例の構成図である。【００９９】
ストレージポートテーブル１１００は、ストレージポートに関する構成管理テーブルである。ストレージポートテーブル１１００は、コンポーネントＩＤ１１０１、ポート番号１１０２、ＷＷＮ１１０３、装置ＩＤ１１０４、アクセス許可ＷＷＮ１１０５、およびコントローラ番号１１０６のフィールドを含む。【０１００】
コンポーネントＩＤ１１０１には、ストレージポート１６３に付されたコンポーネントＩＤが格納される。ポート番号１１０２には、ストレージポート１６３に付されたポート番号が格納される。ＷＷＮ１１０３には、ストレージポート１６３に割り当てられたＷＷＮが格納される。装置ＩＤ１１０４には、ストレージポート１６３を含むストレージ１０４の装置ＩＤが格納される。アクセス許可ＷＷＮ１１０５には、ストレージポート１６３へのアクセスが許可されているＨＢＡ１４２のＷＷＮが格納される。コントローラ番号１１０６には、ストレージポート１６３と接続関係を有するストレージコントローラ１６１のコントローラ番号が格納される。ここで、コントローラ番号は、ストレージコントローラ１６１をストレージ１０４内で一意に識別するための識別情報である。【０１０１】
図１２は、実施例１に係るストレージディスクテーブルの一例の構成図である。【０１０２】
ストレージディスクテーブル１２００は、ストレージディスクに関する構成管理テーブルである。ストレージディスクテーブル１２００は、コンポーネントＩＤ１２０１、ディスク番号１２０２、装置ＩＤ１２０３、およびＲＡＩＤグループ番号１２０４のフィールドを含む。【０１０３】
コンポーネントＩＤ１２０１には、ストレージディスク１６２に付されたコンポーネントＩＤが格納される。ディスク番号１２０２には、ストレージディスク１６２をストレージ１０４内で一意に識別するための識別情報（ディスク番号）が格納される。装置ＩＤ１２０３には、ストレージディスク１６２を含むストレージ１０４の装置ＩＤが格納される。ＲＡＩＤグループ番号１２０４には、ストレージディスク１６２が構成するＲＡＩＤグループ１６４のＲＡＩＤグループ番号が格納される。【０１０４】
図１３は、実施例１に係るストレージコントローラテーブルの一例の構成図である。【０１０５】
ストレージコントローラテーブル１３００は、ストレージコントローラに関する構成管理テーブルである。ストレージコントローラテーブル１３００は、コンポーネントＩＤ１３０１、コントローラ番号１３０２、および装置ＩＤ１３０３のフィールドを含む。【０１０６】
コンポーネントＩＤ１３０１には、ストレージコントローラ１６１に付されたコンポーネントＩＤが格納される。コントローラ番号１３０２には、ストレージコントローラ１６１に付されたコントローラ番号が格納される。装置ＩＤ１３０３には、ストレージコントローラ１６１を含むストレージ１０４の装置ＩＤが格納される。【０１０７】
この他、構成管理ＤＢ１３２には、ＦＣスイッチ１０５のポート１７１に関する構成管理テーブル等、他のコンポーネントに関する構成管理テーブルも含まれるが、ここでは説明を省略する。【０１０８】
図１４は、実施例１に係る管理オブジェクトの種類間の関連を示す一例のクラス図である。【０１０９】
クラス図は、管理オブジェクトの種類間の関連、具体的には、データの入出力関係、接続関係、依存関係等を表現した図である。管理オブジェクトの種類間の関連は、当該関連を有する２つの種類のそれぞれに属する２つの管理オブジェクト同士が当該関連を持ち得ることを示している。例えば、種類がサーバである管理オブジェクト（サーバ１０２）としてサーバａおよびサーバｂが存在し、種類がＨＢＡである管理オブジェクト（ＨＢＡ１４２）としてＨＢＡａおよびＨＢＡｂが存在する場合、サーバがＨＢＡを部品として含むことを示す関連は、ＨＢＡａまたはＨＢＡｂがサーバａまたはサーバｂの部品となり得ることを示している。また、例えば、種類がＨＢＡである管理オブジェクト（ＨＢＡ１４２）としてＨＢＡａおよびＨＢＡｂが存在し、種類がストレージポートである管理オブジェクト（ストレージポート１６３）としてストレージポートａおよびストレージポートｂが存在する場合、ＨＢＡとストレージポートとが接続関係を有することを示す関連は、ＨＢＡａまたはＨＢＡｂとストレージポートａまたはストレージポートｂとが接続関係を有し得ることを示している。なお、本実施例において、２つの管理オブジェクトの種類が接続関係を有する場合、それら２つの管理オブジェクトの種類は、データの入出力関係を有する。【０１１０】
本実施形態において、クラス図における矩形（サーバ１４０１、ＨＢＡ１４０２、ストレージポート１４０６等）は、管理オブジェクトの種類を表す。また、矢印１４０３は、矢印１４０３の始点に接続されている管理オブジェクトの種類が、矢印１４０３の終点に接続されている管理オブジェクトの種類を部品として含むことを示す。また、コネクタ１４０４は、コネクタ１４０４の両端に接続されている２つの管理オブジェクトの種類が互いに接続関係を有することを示す。多重度１４０５は、矢印１４０３またはコネクタ１４０４が示す関連の多重度を示す。例えば、ＨＢＡとストレージポートとが接続関係を有することを示す関連において、当該関連を示すコネクタ１４０４の両端には、０以上を示す多重度１４０５（「０…＊」）が付されている。これは、１つのＨＢＡ１４２に対して複数のストレージポート１６３が接続関係を有し得ること、また、１つのストレージポート１６３に対して複数のＨＢＡ１４２が接続関係を有し得ることを示している。各管理オブジェクトの種類間の関連は、構成管理ＤＢ１３２の構成管理テーブルから導出することができる。【０１１１】
＜関連テーブル＞【０１１２】
図１５は、実施例１に係る関連テーブルの一例の構成図である。【０１１３】
関連テーブル１３３には、管理オブジェクトの種類間の関連に関する情報、すなわち、図１４のクラス図における矢印１４０３およびコネクタ１４０４に関する情報が格納される。関連テーブル１３３は、２つの構成管理テーブル間のフィールドの対応関係を示しており、２つの構成管理テーブルのそれぞれの２つのエントリ間で対応関係があるフィールドの値が等しい場合、その２つのエントリがそれぞれ示す２つの管理オブジェクト同士が関連を有していることを示す。【０１１４】
管理コンピュータ１０１は、関連テーブル１３３を参照することによって、指定した管理オブジェクトと関連を持つ管理オブジェクトの情報を構成管理ＤＢ１３２から取得することができる。関連テーブル１３３の各エントリは、２つの管理オブジェクトの種類間の関連に関する情報を示す。以下、関連テーブル１３３の各エントリによって管理される、２つの管理オブジェクトの種類間の関連を「単位関連」と称する。なお、単位関連は、他の管理オブジェクトの種類を介さない直接的な関連（以下「直接関連」と称する）だけでなく、他の管理オブジェクトの種類を介した間接的な関連、すなわち複数の直接関連の組み合わせによって表現することができる関連（以下「間接関連」と称する）であってもよい。【０１１５】
関連テーブル１３３は、関連ＩＤ１５０１、テーブル名Ｘ１５０２、フィールド名Ｘ１５０３、テーブル名Ｙ１５０４、フィールド名Ｙ１５０５、同時参照関連１５０６、変更頻度１５０７、および変更回数１５０８のフィールドを含む。【０１１６】
関連ＩＤ１５０１には、エントリが示す単位関連を一意に識別するための識別情報（関連ＩＤ）が格納される。テーブル名Ｘ１５０２には、エントリが示す単位関連を持つ２つの管理オブジェクトの種類のうちの一方（以下、図１５の説明において「種類Ｘ」という）を示すデータが格納される。フィールド名Ｘ１５０３は、種類Ｘに関する構成管理テーブルにおける、関連の有無を特定するために参照されるフィールド（以下、図１５の説明において「フィールドＸ」という）のフィールド名が格納される。テーブル名Ｙ１５０４には、エントリが示す単位関連を持つ２つの管理オブジェクトの種類のうちの種類Ｘとは異なる方（以下、図１５の説明において「種類Ｙ」という）を示すデータが格納される。フィールド名Ｙ１５０５には、種類Ｙに関する構成管理テーブルにおける、関連の有無を特定するために参照されるフィールド（以下、図１５の説明において「フィールドＹ」という）のフィールド名が格納される。例えば、種類Ｘに関する構成管理テーブルに登録されている或るエントリＸのフィールドＸの値と、種類Ｙに関する構成管理テーブルに登録されている或るエントリＹのフィールドＹの値とが等しい場合、エントリＸが示す管理オブジェクトとエントリＹが示す管理オブジェクトとは、種類Ｘと種類Ｙとの間の単位関連を持つ。同時参照関連１５０６には、エントリが示す単位関連が間接関連である場合の当該単位関連を構成する複数の単位関連、すなわち、管理オブジェクトの対応関係の有無を調べる際に同時に参照される別の関連の関連ＩＤが格納される。【０１１７】
変更頻度１５０７には、エントリが示す単位関連に関する変更頻度を示すデータが格納される。ここで、種類Ｘと種類Ｙとの間の単位関連に関する変更頻度とは、種類Ｘに属する管理オブジェクトと種類Ｙに属する管理オブジェクトとの間の関連が変更される頻度のことをいう。なお、管理オブジェクト間の関連の変更には、当該関連の関連相手が変更されること、当該関連が生成、削除されることが含まれる。変更頻度１５０７の値は、例えば、変更イベントが検知される度に障害解析プログラム１２３によって更新される。例えば、変更頻度は、以下の式によって計算することができる。ただし、以下の式は一例であり、これに限定されるものではない。【０１１８】
変更頻度＝（単位関連における通算変更回数）／（種類Ｘに属する管理オブジェクトの数および種類Ｙに属する管理オブジェクトの数のうちのいずれか大きい方）／（単位関連における通算変更回数の計測を実施した期間）【０１１９】
ここで、単位関連における通算変更回数は、種類Ｘに属する管理オブジェクトと種類Ｙに属する管理オブジェクトとの間の関連が変更された回数である。変更回数１５０８には、エントリが示す単位関連における通算変更回数が格納される。【０１２０】
例えば、図１５の上から１番目のエントリ１５１１は、ディスクドライブテーブル８００の或るエントリの装置ＩＤ８０３の値と、サーバテーブル４００の或るエントリの装置ＩＤ４０１の値とが等しい場合に、各エントリが示すディスクドライブ１５１とサーバ１０２とが関連している（この場合は、ディスクドライブ１５１がサーバ１０２の構成要素となる）ことを示す。【０１２１】
また、図１５の上から３番目のエントリ１５１３の同時参照関連１５０６には、３つの単位関連の関連ＩＤ（「ＡＳ２」、「ＡＳ１７」、「ＡＳ１０」）が格納されている。すなわち、このエントリ１５１３は、このエントリ１５１３が示す単位関連がこれら３つの単位関連の組み合わせで表現される間接関連であることを示している。また、このエントリ１５１３は、ディスクドライブテーブル８００の或るエントリのＬＵＮ＿ＩＤ８０６の値と、論理ボリュームテーブル９００の或るエントリのＬＵＮ＿ＩＤ９０３の値とが等しい場合に、各エントリが示すディスクドライブ１５１と論理ボリューム１６５とが関連している（この場合は、ディスクドライブ１５１と論理ボリューム１６５とが接続関係を有する）ことを示す。【０１２２】
なお、本実施例では、２つの管理オブジェクトの種類間の関連ごとにエントリを用意したが、２つ以上の関連に関する情報を１つのエントリに格納してもよい。例えば、図１４のクラス図に示すように、論理ボリュームとストレージディスクとは、直接関連しない。しかし、論理ボリュームとストレージディスクとはＲＡＩＤグループを介して関連するので、論理ボリュームとストレージディスクとの間の関連に対応するエントリが、関連テーブル１３３に含まれてもよい。【０１２３】
＜トポロジ取得方式リポジトリおよびトポロジ取得方式＞【０１２４】
トポロジ取得方式データは、メタルール３００に基づいて展開ルールを生成する際に、当該メタルール３００に適用されるトポロジを構成管理ＤＢ１３２内の情報に基づいて特定するための手段を示すデータである。具体的には、トポロジ取得方式データは、メタルール３００の原因イベントに関係する管理オブジェクトの種類と、当該メタルール３００の１以上の影響イベントのうちのいずれかに関係する管理オブジェクトの種類とを結ぶ経路（またはその経路の一部）を、１以上の単位関連
（接続関係の関連）の組み合わせ（以下「経路構成グループ」と称する）で示したデータである。１以上のトポロジ取得方式データの組み合わせによって、すなわち１以上のトポロジ取得方式データがそれぞれ示す１以上の経路構成グループの全構成要素（単位関連）の組み合わせによって、メタルール３００の原因イベントに関係する管理オブジェクトの種類と、当該メタルール３００の１以上の影響イベントに関係する管理オブジェクトの種類のそれぞれとの間の接続構成（以下「ルール内接続構成」と称する）が示される。以下、ルール内接続構成を示す複数の単位関連の組み合わせを「関連グループ」と称する。すなわち、関連グループは、１以上の経路構成グループの集合である。ルール内接続構成は、関連グループに含まれる単位関連に関係する複数の管理オブジェクトの種類に対応する複数のノードと、関連グループに含まれる複数の単位関連に対応する、ノード間を結ぶ複数のリンクとによって表現される。管理コンピュータ１０１は、例えば、関連グループに含まれる単位関連のそれぞれについて当該単位関連を持つ管理オブジェクトを抽出し、ルール内接続構成の各ノードを、抽出した管理オブジェクトに具体化することにより、ルール内接続構成に対応するトポロジ、すなわち当該ルール内接続構成を持つメタルール３００に適用されるトポロジを特定する。【０１２５】
図１６Ａは、実施例１に係るトポロジ取得方式データの第１の例を示す図である。図１６Ｂは、実施例１に係るトポロジ取得方式データの第２の例を示す図である。図１６Ｃは、実施例１に係るトポロジ取得方式データの第３の例を示す図である。図１６Ｄは、実施例１に係るトポロジ取得方式データの第４の例を示す図である。【０１２６】
図１６Ａ〜図１６Ｄに示すように、トポロジ取得方式データ１６００は、方式ＩＤ１６０１、関連１６０２、上位関連１６０３、影響事象側テーブル名１６０４、および原因事象側テーブル名１６０５のフィールドを含む。【０１２７】
方式ＩＤ１６０１には、トポロジ取得方式を一意に識別するための識別情報（方式ＩＤ）が格納される。関連１６０２には、経路構成グループを構成する１以上の単位関連の関連ＩＤが格納される。管理コンピュータ１０１は、例えば、関連１６０２に格納された関連ＩＤが示す単位関連を持つ複数の管理オブジェクトを構成管理ＤＢ１３２内の情報を参照して特定することによって、トポロジデータを生成する。上位関連１６０３には、関連１６０２に格納されたいずれか複数の関連ＩＤによって示される複数の単位関連によって構成される間接関連（以下「上位関連」と称する）の関連ＩＤが格納される。影響事象側テーブル名１６０４には、関連１６０２に格納された関連ＩＤが示す単位関連を持つ２つの管理オブジェクトの種別のうちの、影響事象側にある管理オブジェクトの種別を示すデータが格納される。原因事象側テーブル名１６０５には、関連１６０２に格納された関連ＩＤが示す単位関連を持つ２つの管理オブジェクトの種別のうちの、原因事象側にある管理オブジェクトの種別を示すデータが格納される。【０１２８】
なお、トポロジ取得方式データ１６００は、複数のメタルール３００から参照されてもよい。【０１２９】
例えば、図１６Ａに示すトポロジ取得方式データ１６００Ａは、方式ＩＤが「Ｍｅｔｈｏｄ１」のトポロジ取得方式を示しており、関連ＩＤが「ＡＳ３」、「ＡＳ２」、「ＡＳ１７」、「ＡＳ１０」、「ＡＳ１２」、および「ＡＳ１５」のそれぞれの単位関連を持つ複数の管理オブジェクトを特定することによってトポロジデータを生成できることを示す。【０１３０】
また、例えば、図１６Ｄに示すトポロジ取得方式データ１６００Ｄは、方式ＩＤが「Ｍｅｔｈｏｄ４」のトポロジ取得方式を示しており、関連ＩＤが「ＡＳ１２」および「ＡＳ１５」のそれぞれの単位関連を持つ複数の管理オブジェクトを特定することによってトポロジデータを生成できることを示す。例えば、管理コンピュータ１０１は、トポロジ取得方式データ１６００Ｄがルール内接続構成を示している場合において、計算機システム内に、種類が論理ボリュームである管理オブジェクト（論理ボリューム１６５）として論理ボリュームａが存在し、種類がＲＡＩＤグループである管理オブジェクト（ＲＡＩＤグループ１６４）としてＲＡＩＤグループａが存在し、種類がストレージディスクである管理オブジェクト（ストレージディスク１６２）としてストレージディスクａが存在しており、かつ、論理ボリュームａとＲＡＩＤグループａとが「ＡＳ１２」の関連を有し、ＲＡＩＤグループａとストレージディスクａとが「ＡＳ１５」の関連を有している場合、トポロジ取得方式データ１６００Ｄが示すルール内接続構成に対応するトポロジとして、論理ボリュームａ、ＲＡＩＤグループａ、およびストレージディスクａの組み合わせを特定する。【０１３１】
なお、トポロジ取得方式データ１６００には、関連テーブル１３３の１つ以上のエントリおよび構成管理ＤＢ１３２に基づいてトポロジを特定する処理または操作手順を示すデータ、例えば、プログラムやＳＱＬ等のデータベース問い合わせ言語によって定義されたデータ等の識別情報或いは当該データが格納されている場所を特定するための情報が格納されてもよい。【０１３２】
例えば、構成管理ＤＢ１３２が当該技術分野において公知であるリレーショナルデータベースであり、ＳＱＬによって定義された操作手順に従って所望のデータを取得できる場合、その操作手順を示すＳＱＬデータの識別情報がトポロジ取得方式データ１６００に格納されてもよい。例えば、図１６Ａに示すトポロジ取得方式１６００について、関連ＩＤ１５０１が「ＡＳ３」、「ＡＳ２」、「ＡＳ１７」、「ＡＳ１０」、「ＡＳ１２」、および「ＡＳ１５」の単位関連のそれぞれを示すエントリに登録されている構成管理テーブルのフィールドの対応関係に基づいて、図１６Ｅに示すようなＳＱＬデータ１６５０Ａが生成されてもよい。このＳＱＬデータ１６５０Ａは、ストレージディスクテーブル１２００のコンポーネントＩＤ１２０１を起点としてトポロジを特定するＳＱＬデータである。【０１３３】
なお、ＳＱＬデータは、処理の高速化のための工夫がされるとよい。例えば、構成管理テーブル間の多重度に応じて、ＳＱＬ文のＷＨＥＲＥ句に記述する条件によって取得するエントリを絞り込む順序が変更されてもよい。また、同種の管理オブジェクト（例えば、スイッチ１０３、１０５等）が多段に接続されたトポロジを特定するためのデータに、例えば「ＡＳ８に対応するエントリが示す関連をＮ回繰り返し辿る」という意味を持つ「Ｎ＊ＡＳ８」等の定義が含められてもよい。【０１３４】
＜トポロジリポジトリおよびトポロジ＞【０１３５】
トポロジデータは、或るＩ／Ｏ経路上に存在する複数の管理オブジェクト間の関係を示す情報である。【０１３６】
図１７Ａは、実施例１に係るトポロジデータの第１の例を示す図である。図１７Ｂは、実施例１に係るトポロジデータの第２の例を示す図である。図１７Ｃは、実施例１に係るトポロジデータの第３の例を示す図である。【０１３７】
図１７Ａに示すように、トポロジデータ１７００は、コンポーネント１７１１、トポロジＩＤ１７１２、および関連展開ルールＩＤ１７１３のフィールドを含む。コンポーネント１７１１は、トポロジを構成する複数の管理オブジェクトのそれぞれに対応する複数のトポロジ構成要素１７１４を含む。各トポロジ構成要素１７１４には、当該トポロジ構成要素１７１４に対応する管理オブジェクトに関する情報が格納される。各トポロジ構成要素１７１４は、装置ＩＤ１７０１、およびコンポーネントＩＤ１７０２のフィールドを含む。装置ＩＤ１７０１には、トポロジを構成する管理オブジェクトが管理対象装置である場合は当該管理対象装置の装置ＩＤが格納され、トポロジを構成する管理オブジェクトがコンポーネントである場合は当該コンポーネントを含む管理対象装置の装置ＩＤが格納される。コンポーネントＩＤ１７０２には、トポロジを構成する管理オブジェクトが管理対象装置である場合は例えば「ＮＵＬＬ」が格納され、トポロジを構成する管理オブジェクトがコンポーネントである場合は当該コンポーネントのコンポーネントＩＤが格納される。トポロジデータ１７００は、複数のトポロジ構成要素１７１４によって示される複数の管理オブジェクトが、同じＩ／Ｏ経路上にあることを示す。【０１３８】
また、トポロジＩＤ１７１２には、トポロジを一意に識別するための識別情報（トポロジＩＤ）が格納される。関連展開ルールＩＤ１７１３には、トポロジが適用されることで生成された展開ルールを一意に識別するための識別情報（展開ルールＩＤ）が格納される。【０１３９】
例えば、図１７Ａに示すトポロジデータ１７００Ａ（トポロジＩＤが「Ｔｏｐｏｌｏｇｙ３−１」のトポロジデータ１７００）は、ディスクドライブ「ＤＲＩＶＥ１」とストレージポート「ＳＴＰＯＲＴ１」とが接続関係の関連を有し、ストレージポート「ＳＴＰＯＲＴ１」と論理ボリューム「ＶＯＬ１」とが接続関係の関連を有していること、すなわち、これら３つの管理オブジェクトが同じＩ／Ｏ経路上にあることを示す。また、トポロジデータ１７００Ａの関連展開ルールＩＤ１７１３を参照することにより、トポロジデータ１７００Ａが示すトポロジがメタルール３００に適用されることにより、展開ルールＩＤが「ＥｘｐａｎｄｅｄＲｕｌｅ２−１」の展開ルールが生成されたことがわかる。【０１４０】
＜展開ルールリポジトリおよび展開ルール＞【０１４１】
展開ルールは、メタルール３００を計算機システムの実構成に依存する形式に展開した情報であり、管理オブジェクトのいずれかに関する原因イベントと、原因イベントが原因となることの条件となる、管理オブジェクトのいずれかに関する１以上の影響イベントとの対応関係を示す情報である。管理コンピュータ１０１は、計算機システムの構成を示す情報に基づいてメタルール３００に適用可能なトポロジを特定し、特定したトポロジをメタルール３００に適用することにより、展開ルールを生成する。【０１４２】
本実施例において、展開ルールは、メタルール３００と同様に、ＩＦ−ＴＨＥＮ形式で記述するが、システム障害の原因事象と、原因事象によって引き起こされる観測事象が記述されていれば、他の形式でもよい。【０１４３】
図１８Ａは、実施例１に係る展開ルールの第１の例を示す図である。図１８Ｂは、実施例１に係る展開ルールの第２の例を示す図である。図１８Ｃは、実施例１に係る展開ルールの第３の例を示す図である。【０１４４】
図１８Ａに示すように、展開ルール１８００は、影響イベントを示す１以上の条件要素１８１４を含むＩＦ部１８１１と、原因イベントを示すＴＨＥＮ部１８１２とを含む。【０１４５】
展開ルール１８００は、ＩＦ部１８１１の１以上の条件要素１８１４がそれぞれ示す１以上の影響イベントが検知された場合に、ＴＨＥＮ部１８１２が示す原因イベントが障害の原因となることを示す。したがって、ＴＨＥＮ部１８１２のステータスが正常になれば、ＩＦ部１８１１の問題も解決することが見込まれる。本実施例においては、障害イベントテーブル１３１Ａに登録されたエントリが示す障害イベントを観測事象とし、障害の解析が行われる。【０１４６】
展開ルール１８００のＩＦ部１８１１の各条件要素１８１４は、装置ＩＤ１８０１、コンポーネントＩＤ１８０２、イベント種別１８０３、および受信フラグ１８０４のフィールドを含む。条件要素１８１４の装置ＩＤ１８０１には、影響イベントに関係する管理対象装置の装置ＩＤが格納される。条件要素１８１４のコンポーネントＩＤ１８０２には、影響イベントに関係するコンポーネントのコンポーネントＩＤが格納される。影響イベントがコンポーネントに関するイベントではなく管理対象装置に関するイベントである場合、条件要素１８１４のコンポーネントＩＤ１８０２には、例えば「ＮＵＬＬ」が格納される。条件要素１８１４のイベント種別１８０３には、影響イベントの種類を示すデータが格納される。条件要素１８１４の受信フラグ１８０４には、影響イベントの検知の有無を示すデータが格納される。例えば、条件要素１８１４の受信フラグ１８０４には、影響イベントが検知された場合に「１」が格納され、影響イベントが検知されていない場合に「０」が格納される。また、影響イベントが中間イベントである場合、条件要素１８１４の受信フラグ１８０４には、その中間イベントを原因イベントとする他の１以上の展開ルールのイベント受信率のうちの最も高い値が格納される。なお、条件要素１８１４の受信フラグ１８０４に「１」が格納されてから所定の時間が経過した場合に当該受信フラグ１８０４の値を「０」に戻す等の処理が行われてもよい。【０１４７】
展開ルール１８００のＴＨＥＮ部１８１２も、ＩＦ部１８１１の各条件要素１８１４と同様に、装置ＩＤ１８０１、コンポーネントＩＤ１８０２、イベント種別１８０３、および受信フラグ１８０４のフィールドを含む。ＴＨＥＮ部１８１２の装置ＩＤ１８０１には、原因イベントに関係する管理対象装置の装置ＩＤが格納される。ＴＨＥＮ部１８１２のコンポーネント種別１８０２には、原因イベントに関係するコンポーネントのコンポーネントＩＤが格納される。原因イベントがコンポーネントに関するイベントではなく管理対象装置に関するイベントである場合、ＴＨＥＮ部１８１２のコンポーネントＩＤ１８０２には、例えば「ＮＵＬＬ」が格納される。ＴＨＥＮ部１８１２のイベント種別１８０３には、原因イベントの種類を示すデータが格納される。ＴＨＥＮ部１８１２の受信フラグ１８０４には、展開ルール１８００のイベント受信率、すなわち展開ルール１８００の原因イベントについての確信度を示すデータが格納される。例えば、展開ルール１８００のイベント受信率は、以下の式によって計算される。【０１４８】
イベント受信率＝受信フラグ１７０４に「１」が格納されている影響イベントの数／影響イベントの総数【０１４９】
なお、計算対象の展開ルール１８００に中間イベントを示す条件要素１８１４が含まれている場合は、その中間イベントを原因イベントとする他の１以上の展開ルール１８００のイベント受信率のうちの値の最も高いイベント受信率も考慮されて、計算対象の展開ルール１８００のイベント受信率が計算される。【０１５０】
例えば、図１８Ｃに示す展開ルール１８００Ｃについて、影響イベントの総数は中間イベントにより連結された他の展開ルール１８００も含めて４であり、そのうち受信フラグ１７０４に「１」が格納されている影響イベントの数は他の展開ルール１８００も含めて２であるため、イベント受信率は２／４（５０％）となる。【０１５１】
また、展開ルール１８００は、展開ルール１８００を一意に識別する展開ルールＩＤを格納するフィールド１８１３を含む。【０１５２】
例えば、図１８Ａに示す展開ルール１８００Ａ（展開ルールＩＤが「ＥｘｐａｎｄｅｄＲｕｌｅ２−１」の展開ルール１８００）は、観測事象として、サーバＡのディスクドライブ「ＤＲＩＶＥ１」の転送時間性能エラーと、ストレージＡのストレージポート「ＳＴＰＯＲＴ１」の中間イベント「ＭｉｄＥｒｒｏｒ２」が検知された場合、ストレージＡの論理ボリューム「ＶＯＬ１」の中間イベント「ＭｉｄＥｒｒｏｒ１」が原因であると結論付けられることを示す。なお、ＩＦ部１８１１に含まれる条件要素１８１４として、管理オブジェクトが正常であること、すなわち障害イベントが発生していないことを定義してもよい。なお、中間イベントは、それ自体検知されることはないが、ここでいう中間イベントが検知されるとは、その中間イベントを原因イベントとする展開ルール１８００の１以上の影響イベントが検知されることを意味する。【０１５３】
＜メタルールの生成処理＞【０１５４】
本実施例において、管理コンピュータ１０１は、管理対象システムで実際に発生した障害の原因と、その原因によって引き起こされた各障害イベントとを示す情報の入力をルール作成者から受け付け、入力された情報に基づいてメタルール３００を生成する。ルール作成者が計算機システムにおいて実際に発生した障害の情報を入力することによって、管理コンピュータ１０１は、より正確なメタルール３００を作成できる。さらに、障害解析機能の内部仕様を極力隠蔽して、メタルール３００生成に必要な情報を入力することができる。【０１５５】
例えば、計算機システムで発生した障害に対して、管理コンピュータ１０１が正しい解析結果を出力しなかった場合、メタルール３００が不足していることが分かる。当該障害の対策後に原因が判明した場合、ルール作成者が当該障害とその原因とを示す情報を入力して新しいメタルール３００を生成することにより、管理コンピュータ１０１は、以後同様の障害が発生した場合に障害の原因を正確に特定することができる。【０１５６】
図１９は、実施例１に係るイベント情報入力処理の一例のフローチャートである。【０１５７】
メタルール生成プログラム１２１は、例えば、入力デバイス１１４を介してルール作成者からメタルール３００の生成指示を受け付けた場合にイベント情報入力処理を実行する。メタルール生成プログラム１２１は、イベント情報入力処理において、トポロジ取得方式探索処理（図２１参照）、関連探索処理（図２２参照）、トポロジ取得方式分割処理（図２３参照）、およびメタルール生成処理（図２４参照）を実行する。【０１５８】
ステップＳ１９１１において、メタルール生成プログラム１２１は、表示モジュール１２５に指示を出し、イベント情報入力画面を出力デバイス１１７に表示させる。ここで、図２０を参照して、イベント情報入力画面について説明する。【０１５９】
図２０は、実施例１に係るイベント情報入力画面の一例の構成図である。【０１６０】
イベント情報入力画面２０００は、例えば、図２０に例示するように、原因イベントを示す情報（以下「原因情報」と称する）と、原因情報が示す原因イベントが原因となることの条件となる１以上の影響イベントを示す情報（以下「影響情報」と称する）とをルール作成者に入力させるための領域を有する。この領域は、例えば、影響イベントに関係する管理対象装置の種類、影響イベントに関係するコンポーネントの種類、および影響イベントの種類、並びに、原因イベントに関係する管理対象装置の種類、原因イベントに関係するコンポーネントの種類、および原因イベントの種類を指定可能なリストボックス２００１〜２００６を有する。また、複数の影響イベントを設定する場合、ルール作成者が追加ボタン２００７を押下するごとにリストボックス２００１〜２００３で指定された影響イベントに関する情報が影響情報に追加されるように構成されてもよい。【０１６１】
また、管理対象装置の種類を指定するためのリストボックス２００１、２００４において１つの種類が指定された場合に、指定された種類の管理対象装置に含まれ得るコンポーネントの種類のみが、コンポーネントの種類を指定するためのリストボックス２００２、２００５に表示されるようにしてもよい。また、管理対象装置の種類およびコンポーネントの種類がリストボックス２００１、２００２、２００４、２００５において指定された場合に、指定された管理対象装置の種類およびコンポーネントの種類において発生し得るイベントの種類のみが、イベントの種類を指定するためのリストボックス２００３、２００６に表示されるようにしてもよい。【０１６２】
なお、イベント情報入力画面２０００は、構成情報を表示する画面において、実際に管理されている管理対象装置およびそのコンポーネントを選択することによって、メタルール生成プログラム１２１が自動的に、管理対象装置の種類およびコンポーネントの種類を導出してもよい。【０１６３】
図１９に戻り、ステップＳ１９１２において、メタルール生成プログラム１２１は、ルール作成者によって入力された原因情報および影響情報を受信する。具体的には、図２０のイベント情報入力画面２０００において、ルール作成者が影響イベントおよび原因イベントをリストボックス２００１〜２００６において指定し、確定ボタン２００８を押下すると、メタルール生成プログラム１２１は、指定された影響イベントおよび原因イベントを示す影響情報および原因情報を受信する。なお、影響イベントは、複数選択されてもよい。影響情報は、例えば、影響イベントに関係する管理対象装置の種類を示すデータ、影響イベントに関係するコンポーネントの種類を示すデータ、および影響イベントの種類を示すデータを含む。原因情報は、例えば、原因イベントに関係する管理対象装置の種類を示すデータ、原因イベントに関係するコンポーネントの種類を示すデータ、および原因イベントの種類を示すデータを含む。なお、影響イベントまたは原因イベントが、コンポーネントに関するイベントではなく管理対象装置に関するイベントである場合、影響情報または原因情報は、影響イベントまたは原因イベントに関係するコンポーネントの種類を示すデータを含まなくともよい。【０１６４】
ステップＳ１９１３において、メタルール生成プログラム１２１は、ステップＳ１９１２で受信した原因情報および影響情報を入力として、トポロジ取得方式探索処理を実行し、影響情報が示す１以上の影響イベントと生成された１以上のトポロジ取得方式データ１６００との対応関係を示すデータ（以下「対応関係データ」と称する）を取得する。【０１６５】
ステップＳ１９１４において、メタルール生成プログラム１２１は、ステップＳ１９１２で取得した原因情報および影響情報、並びに、ステップＳ１９１３で取得した対応関係データを入力として、トポロジ取得方式分割処理を実行する。トポロジ取得方式分割処理は、生成したトポロジ取得方式を単位関連に関する変更頻度に基づいて複数のトポロジ取得方式に分割し、分割の結果に合わせて複数のメタルール３００を生成する処理である。なお、ここで生成された複数のメタルール３００は、当該複数のメタルール全体で、原因情報が示す原因イベントと影響情報が示す１以上の影響イベントとの対応関係を示している。【０１６６】
ステップＳ１９１６において、メタルール生成プログラム１２１は、生成したメタルール３００およびトポロジ取得方式を画面に表示してルール作成者に提示し、ステップＳ１９１７において、生成したメタルール３００の登録の指示または破棄の指示をルール作成者から受信する。【０１６７】
ステップＳ１９１８において、メタルール生成プログラム１２１は、ステップＳ１９１６において登録の指示を受信したか否かを判定する。条件を満たす場合、すなわち登録の指示を受信した場合（ステップＳ１９１８：ＹＥＳ）、メタルール生成プログラム１２１は、処理をステップＳ１９１９へ進める。一方、条件を満たさない場合、すなわち破棄の指示を受信した場合（ステップＳ１９１８：ＮＯ）、メタルール生成プログラム１２１は、イベント情報入力処理を終了する。【０１６８】
ステップＳ１９１９において、メタルール生成プログラム１２１は、ステップＳ１９１４で生成したメタルール３００をメタルールリポジトリ１３５に登録する。その後、メタルール生成プログラム１２１は、イベント情報入力処理を終了する。【０１６９】
図２１は、実施例１に係るトポロジ取得方式探索処理の一例のフローチャートである。【０１７０】
メタルール生成プログラム１２１のサブプログラムであるトポロジ取得方式探索プログラムは、トポロジ取得方式探索処理において、関連テーブル１３３を参照して、パラメータとして入力された原因情報が示す原因イベントに関係する管理オブジェクトの種類と、パラメータとして入力された影響情報が示す１以上の影響イベントに関係する管理オブジェクトの種類のそれぞれとの間の接続構成を示す１以上のトポロジ取得方式データ１６００を生成する。具体的には、トポロジ取得方式探索プログラムは。影響情報が示す各影響イベントについて、当該影響イベントに関係する管理オブジェクトの種類を起点として、原因情報が示す原因イベントに関係する管理オブジェクトの種類まで、関連テーブル１３３に登録されている単位関連を辿ることによって、各トポロジ取得方式データ１６００を生成する。【０１７１】
ステップＳ２１１１において、トポロジ取得方式探索プログラムは、原因情報および影響情報をパラメータとして受信する。受信するパラメータは、メタルール生成プログラム１２１が図１９のステップＳ１９１２において受信した原因情報および影響情報である。【０１７２】
ステップＳ２１１２において、トポロジ取得方式探索プログラムは、ステップＳ２１１１で受信した影響情報が示す１以上の影響イベントのそれぞれについて、ステップＳ２１１３およびステップＳ２１１４の処理を繰り返す。【０１７３】
ステップＳ２１１３において、トポロジ取得方式探索プログラムは、原因情報、処理対象の影響イベントに関係する管理オブジェクトの種類を示す情報（以下「影響オブジェクト種類情報」と称する）、および関連ＩＤを記録するリストを入力として、関連探索処理を実行する。処理対象の影響イベントがコンポーネントに関するイベントである場合、影響オブジェクト種類情報は、例えば、処理対象の影響イベントに関係するコンポーネントの種類を示すデータを含む。また、処理対象の影響イベントが管理対象装置に関するイベントである場合、影響オブジェクト種類情報は、例えば、処理対象の影響イベントに関係する管理対象装置の種類を示すデータを含む。関連探索処理において、メタルール生成プログラム１２１のサブプログラムである関連探索プログラムは、関連テーブル１３３に基づいて、処理対象の影響イベントに関係する管理オブジェクトの種類を起点として原因イベントに関係する管理オブジェクトの種類までの関連を辿ることによってトポロジ取得方式データ１６００を生成し、生成したトポロジ取得方式データ１６００、すなわち処理対象の影響イベントについてのトポロジ取得方式データ１６００を探索結果メモリとしてメモリ１１２に記録する。【０１７４】
ステップＳ２１１４において、トポロジ取得方式探索プログラムは、関連探索処理によって生成されたトポロジ取得方式データ１６００と、処理対象の影響イベントを示す情報とを対応付けてメモリ１１２に記録する。【０１７５】
ステップＳ２１１５において、トポロジ取得方式探索プログラムは、ステップＳ２１１１で受信した影響情報が示す１以上の影響イベントのそれぞれについて、ステップＳ２１１６、ステップＳ２１１７、およびステップＳ２１１９の処理を繰り返す。【０１７６】
ステップＳ２１１６において、トポロジ取得方式探索プログラムは、処理対象の影響イベントに対応するトポロジ取得方式データ１６００が示す経路と、処理対象の影響イベント以外の影響イベントに対応するトポロジ取得方式データ１６００が示す経路との間で、経路の重複部分が存在するか否かを判定する。条件を満たさない場合、すなわち経路の重複部分が存在しない場合（ステップＳ２１１６：ＮＯ）、トポロジ取得方式探索プログラムは、処理をステップＳ２１１５に戻す。一方、条件を満たす場合、すなわち経路の重複部分が存在する場合（ステップＳ２１１６：ＹＥＳ）、トポロジ取得方式探索プログラムは、処理をステップＳ２１１７に進める。【０１７７】
ステップＳ２１１７において、トポロジ取得方式探索プログラムは、処理対象の影響イベントに対応するトポロジ取得方式データ１６００（以下「トポロジ取得方式データＡ」と称する）、または、トポロジ取得方式データＡとの間で経路の重複部分が存在するトポロジ取得方式データ１６００（以下「トポロジ取得方式データＢ」と称する）から、経路の重複部分に対応する単位関連に関する情報を削除する。なお、トポロジ取得方式データＡが示す経路が、トポロジ取得方式データＢが示す経路全体を包含している場合、トポロジ取得方式探索プログラムは、トポロジ取得方式データＢをメモリ１１２から削除する。また、トポロジ取得方式データＢが示す経路が、トポロジ取得方式データＡが示す経路全体を包含している場合、トポロジ取得方式探索プログラムは、トポロジ取得方式データＡをメモリ１１２から削除する。【０１７８】
ステップＳ２１１９において、トポロジ取得方式探索プログラムは、トポロジ取得方式データＡが示す経路の一部が、トポロジ取得方式データＢが示す経路の一部と重複している場合、トポロジ取得方式データＡが示す経路に関係する複数の管理オブジェクトの種類のうちの、経路の重複部分と経路の重複しない部分との境目にある管理オブジェクトの種類を、他のトポロジ取得方式データ１６００が示す経路との接点となる管理オブジェクトの種類（以下「接点オブジェクトの種類」）として特定する。そして、トポロジ取得方式探索プログラムは、特定した管理オブジェクトの種類が、トポロジ取得方式データＡおよびトポロジ取得方式データＢのそれぞれが示す経路構成グループについての接点オブジェクトの種類であることを示すデータを含む接点オブジェクト情報を生成し、生成した接点オブジェクト情報をメモリ１１２に記憶する。そして、トポロジ取得方式探索プログラムは、特定した接点オブジェクトの種類に関する中間イベントを作成する。管理コンピュータ１０１は、中間イベントの種類を任意に設定することができるが、過去に作成した中間イベントに関する情報を管理する等して、作成済みの他の中間イベントの種類と重複しないようにする。【０１７９】
ステップＳ２１１８において、トポロジ取得方式探索プログラムは、影響情報が示す１以上の影響イベントと生成された１以上のトポロジ取得方式データ１６００との対応関係を示すデータをトポロジ取得方式探索処理の呼び出し元のプログラムに渡す。その後、トポロジ取得方式探索プログラムは、トポロジ取得方式探索処理を終了する。【０１８０】
図２２は、実施例１に係る関連探索処理の一例のフローチャートである。【０１８１】
関連探索プログラムは、関連探索処理において、関連テーブル１３３に基づいて、受信した影響オブジェクト種類情報が示す管理オブジェクトの種類、すなわち処理対象の影響イベントに関係する管理オブジェクトの種類と、受信した原因情報が示す原因イベントに関係する管理オブジェクトの種類とを結ぶ経路を示す複数の単位関連の組み合わせ（経路構成グループ）を導出し、導出した経路構成グループを示すトポロジ取得方式データ１６００を生成する。【０１８２】
ステップＳ２２１１において、関連探索プログラムは、原因情報、影響オブジェクト種類情報、および関連ＩＤを記録するリストをパラメータとして受信する。【０１８３】
ステップＳ２２１２において、関連探索プログラムは、ステップＳ２２１１で受信した影響オブジェクト種類情報が示す管理オブジェクトの種類（以下「入力オブジェクトの種類」と称する）を示すデータが、テーブル名Ｘ１５０２またはテーブル名Ｙ１５０４に格納されている全てのエントリを、関連テーブル１３３から取得する。【０１８４】
ステップＳ２２１３において、関連探索プログラムは、ステップＳ２２１２で取得した関連テーブル１３３のエントリについて、ステップＳ２２１４〜ステップＳ２２１９の処理を繰り返す。【０１８５】
ステップＳ２２１４において、関連探索プログラムは、処理対象の関連テーブル１３３のエントリ（以下「対象関連エントリ」と称する）の関連ＩＤ１５０１に格納されている関連ＩＤ、すなわち対象関連エントリが示す単位関連の関連ＩＤを、関連ＩＤを記録するリストに追加する。【０１８６】
ステップＳ２２１５において、関連探索プログラムは、対象関連エントリを参照し、対象関連エントリのテーブル名Ｘ１５０２またはテーブル名Ｙ１５０４に格納されている２つの管理オブジェクトの種類のうちの入力オブジェクトの種類とは異なる種類、すなわち入力オブジェクトの種類と関連を有する管理オブジェクトの種類（以下「関連オブジェクトの種類」と称する）を特定する。【０１８７】
ステップＳ２２１６において、関連探索プログラムは、ステップＳ２２１５で特定した関連オブジェクトの種類が、受信した原因情報が示す原因イベントに関係するコンポーネントの種類（以下「原因オブジェクトの種類」と称する）と一致するか否かを判定する。条件を満たす場合、すなわち関連オブジェクトの種類が原因オブジェクトの種類と一致する場合（ステップＳ２２１６：ＹＥＳ）、関連探索プログラムは、処理をステップＳ２２１７に進める。一方、条件を満たさない場合、すなわち関連オブジェクトの種類が原因オブジェクトの種類と一致しない場合（ステップＳ２２１６：ＮＯ）、関連探索プログラムは、処理をステップＳ２２１８に進める。【０１８８】
ステップＳ２２１７において、関連探索プログラムは、関連ＩＤを記録するリストに基づいてトポロジ取得方式データ１６００を生成し、生成したトポロジ取得方式データ１６００を探索結果メモリとしてメモリ１１２に記録する。なお、この時点で、関連ＩＤを記録するリストには、影響オブジェクト種類情報が示す管理オブジェクトの種類、すなわち処理対象の影響イベントに関係する管理オブジェクトの種類と原因オブジェクトの種類とを結ぶ経路を示す１以上の単位関連のそれぞれの関連ＩＤが記録されている。また、ここで生成されたトポロジ取得方式データ１６００は、未だトポロジ取得方式リポジトリ１３４には登録されない仮のデータであり、生成されたトポロジ取得方式データ１６００が示すトポロジ取得方式には、仮の方式ＩＤ（仮方式ＩＤ）が割り当てられる。【０１８９】
ステップＳ２２１８において、関連探索プログラムは、関連探索の打ち切り条件を満たしているか否かを調べる。関連探索の打ち切り条件を満たす場合（ステップＳ２２１８：ＹＥＳ）、関連探索プログラムは、ステップＳ２２１２で取得した関連テーブル１３３のエントリのうちの未だ処理の対象とされていないエントリを処理対象として、ステップＳ２２１４〜ステップＳ２２１９の処理を行う。一方、関連探索の打ち切り条件を満たさない場合（ステップＳ２２１８：ＮＯ）、関連探索プログラムは、処理をステップＳ２２１９に進める。例えば、関連ＩＤを記録するリストの中に同じ関連ＩＤが所定の回数以上記録されていることを、関連探索の打ち切り条件としてもよい。また、トポロジ取得方式探索処理の処理時間を短縮するため、一部のトポロジ取得方式を探索せず、例えば、関連ＩＤを記録するリストに記録された関連ＩＤが一定数以上になった場合に、以後の探索を打ち切ってもよい。【０１９０】
ステップＳ２２１９において、関連探索プログラムは、受信した原因情報、ステップＳ２２１５で特定した関連オブジェクトの種類を示す情報、および関連ＩＤを記録するリストを入力として、関連探索処理を再帰的に実行する。なお、再帰的に実行された関連探索処理では、関連オブジェクトの種類が入力オブジェクトの種類として扱われる。【０１９１】
ステップＳ２２２０において、関連探索プログラムは、生成した１以上のトポロジ取得方式データ１６００のうち、最も探索関連数の少ないトポロジ取得方式データ１６００、すなわちトポロジ取得方式データ１６００が示す経路構成グループに含まれる単位関連の数が最も少ないトポロジ取得方式データ１６００を除くトポロジ取得方式データ１６００をメモリ１１２から削除する。ステップＳ２２２０の処理により、処理対象の影響イベントについてのトポロジ取得方式データ１６００が、１つに絞られる。その後、関連探索プログラムは、関連探索処理を終了する。【０１９２】
以下、トポロジ取得方式探索処理および関連探索処理を具体例を挙げて説明する。【０１９３】
例えば、ステップＳ２１１１において、トポロジ取得方式探索プログラムは、サーバのディスクドライブに関する転送時間性能エラーの影響イベント（イベントＡ）、ストレージの論理ボリュームに関するＩＯレスポンスタイム上昇エラーの影響イベント（イベントＢ）、ストレージのストレージディスクに関するディスク使用率上昇エラーの影響イベント（イベントＤ）、および、ストレージのストレージコントローラに関するＣＰＵ使用率上昇エラーの影響イベント（イベントＣ）の未検知のそれぞれを示す影響情報と、ストレージのストレージディスクに関するディスク使用率上昇エラーの原因イベントを示す原因情報とを受信する。なお、イベントＤは、原因イベントと同じであるため、影響情報が示す影響イベントの中に含まれなくともよい。また、イベントＤは原因イベントと同じであり、イベントＤに関係する管理オブジェクトの種類と原因イベントに関係する管理オブジェクトの種類とを結ぶ経路は存在しないため、イベントＤに対応するトポロジ取得方式データ１６００は生成されない。【０１９４】
ステップＳ２１１２の繰り返し処理で、サーバのディスクドライブに関する転送時間性能エラーのイベントＡが選択された場合、関連探索プログラムは、ステップＳ２２１１において、原因イベントに関係する管理オブジェクトの種類（ストレージディスク）を示すデータを含む原因情報と、処理対象のイベントＡに関係する管理オブジェクトの種類（ディスクドライブ）を示す影響オブジェクト種類情報とを受信する。【０１９５】
この場合、関連探索プログラムは、ステップＳ２２１２において、関連テーブル１３３のエントリ１５１１、エントリ１５１２、およびエントリ１５１３を取得する。関連探索プログラムは、ステップＳ２２１３の繰り返し処理でエントリ１５１３を選択した場合、ステップＳ２２１４において、関連ＩＤを記録するリストにエントリ１５１３が示す単位関連のＩＤである「ＡＳ３」を追加し、ステップＳ２２１５において、関連オブジェクトの種類として論理ボリュームを特定する。関連探索プログラムは、ステップＳ２２１６の判定において、関連オブジェクトの種類（論理ボリューム）が原因オブジェクトの種類（ストレージディスク）と一致しないため、ステップＳ２２１９において、原因情報、関連オブジェクトの種類（論理テーブル）を示す情報、および関連ＩＤを記録するリストを入力して再帰的に関連探索処理を実行する。【０１９６】
関連探索プログラムは、再帰的に実行した関連探索処理のステップＳ２２１３の繰り返し処理において単位関連「ＡＳ１２」（関連ＩＤが「ＡＳ１２」の単位関連のことであり、以下、関連ＩＤを用いて単位関連を特定する場合に同様の表記をする）を示すエントリを選択し、その後再度再帰的に実行した関連探索処理のステップＳ２２１３の繰り返し処理において単位関連「ＡＳ１５」を示すエントリを選択した場合、ステップＳ２２１５において、関連オブジェクトの種類としてストレージディスクを特定する。関連探索プログラムは、ステップＳ２２１６の判定において、関連オブジェクトの種類（ストレージディスク）が原因オブジェクトの種類（ストレージディスク）と一致するため、処理をステップＳ２２１７に進め、関連ＩＤを記録するリストに基づいてトポロジ取得方式データ１６００を生成する。この時点で、関連ＩＤを記録するリストには、３つの関連ＩＤ、すなわち「ＡＳ３」、「ＡＳ１２」および「ＡＳ１５」が記録されている。したがって、関連探索プログラムは、単位関連「ＡＳ１２」、単位関連「ＡＳ１５」、並びに、上位関連である単位関連「ＡＳ３」を構成する単位関連、すなわち、単位関連「ＡＳ２」、単位関連「ＡＳ１７」、および単位関連「ＡＳ１０」のそれぞれに関する情報を含むトポロジ取得方式データ１６００、すなわち、図１６Ａに示すトポロジ取得方式データ１６００Ａを生成する。そして、関連探索プログラムは、生成したトポロジ取得方式データ１６００Ａをメモリ１１２に記録する。トポロジ取得方式探索プログラムは、ステップＳ２１１４において、イベントＡと生成したトポロジ取得方式データ１６００Ａとを対応付ける。【０１９７】
また、ステップＳ２１１２の繰り返し処理で、ストレージの論理ボリュームに関するＩＯレスポンスタイム上昇エラーのイベントＢを選択した場合、関連探索プログラムは、ステップＳ２２１７において、単位関連「ＡＳ１２」および単位関連「ＡＳ１５」のそれぞれに関する情報を含むトポロジ取得方式データ１６００を生成する。ここで、このイベントＢについて生成されたトポロジ取得方式データ１６００は、その示す経路、すなわち論理ボリュームとストレージディスクとを結ぶ経路が、イベントＡに対応付けられているトポロジ取得方式データ１６００Ａが示す経路、すなわちディスクドライブとストレージディスクとを結ぶ経路に包含されるため、ステップＳ２１１７において削除される。トポロジ取得方式探索プログラムは、イベントＡに対応付けられているトポロジ取得方式データ１６００Ａに、さらにイベントＢを対応付ける。【０１９８】
また、ステップＳ２１１２の繰り返し処理で、ストレージのストレージコントローラにおけるＣＰＵ使用率上昇エラーのイベントＣの未検知を選択した場合、関連探索プログラムは、ステップＳ２２１７において、単位関連「ＡＳ１８」、単位関連「ＡＳ１０」、単位関連「ＡＳ１２」、および単位関連「ＡＳ１５」のそれぞれに関する情報を含むトポロジ取得方式データ１６００を生成する。ここで、このイベントＣについて生成されたトポロジ取得方式データ１６００が示す経路、すなわちストレージコントローラとストレージディスクとを結ぶ経路は、イベントＡに対応付けられているトポロジ取得方式データ１６００Ａが示す経路、すなわちディスクドライブとストレージディスクとを結ぶ経路との間で、ストレージポートとストレージディスクとを結ぶ経路部分において重複する。したがって、トポロジ取得方式探索プログラムは、ステップＳ２１１７において、イベントＣについて生成されたトポロジ取得方式データ１６００から、ストレージポートとストレージディスクとを結ぶ経路を示す３つの単位関連、すなわち、単位関連「ＡＳ１０」、単位関連「ＡＳ１２」、および単位関連「ＡＳ１５」のそれぞれに関する情報を削除する。この結果、イベントＣについて生成されたトポロジ取得方式データ１６００は、図１６Ｂに示すトポロジ取得方式データ１６００Ｂとなる。また、トポロジ取得方式探索プログラムは、ステップＳ２１１９において、接点オブジェクトの種類としてストレージポートを特定し、ストレージポートに関する中間イベント、例えば「ＭｉｄＥｒｒｏｒ２」を作成する。トポロジ取得方式探索プログラムは、イベントＣとトポロジ取得方式データ１６００Ａおよびトポロジ取得方式データ１６００Ｂとを対応付ける。【０１９９】
なお、図３Ａが示すメタルール３００Ａは、上記の具体例で示した４つの影響イベント、すなわちイベントＡ、イベントＢ、イベントＣ、およびイベントＤを影響イベントとし、イベントＤを原因イベントとするメタルールに対応している。すなわち、このメタルール３００Ａのルール内接続構成は、イベントＡ、イベントＢ、およびイベントＣのそれぞれに対応付けられた１以上のトポロジ取得方式データ１６００、すなわちトポロジ取得方式データ１６００Ａおよびトポロジ取得方式データ１６００Ｂによって示される。したがって、メタルール３００Ａに適用されるトポロジは、トポロジ取得方式データ１６００Ａおよびトポロジ取得方式データ１６００Ｂに基づいて特定される。【０２００】
なお、本実施例におけるトポロジ取得方式探索処理では、管理コンピュータ１０１は、影響イベントごとに、その影響イベントに関係する管理オブジェクトの種類から原因イベントに関係する管理オブジェクトの種類までの経路を探索し、トポロジ取得方式データ１６００を生成している。例えば、管理コンピュータ１０１は、或る影響イベントに対応する経路を探索している場合において、その探索中の経路が別の影響イベントに対応する経路（既に原因イベントに関係する管理オブジェクトの種類まで結ばれている経路）と繋がった場合に、それ以降の経路の探索を行わない等の処理を行い、処理を高速化してもよい。【０２０１】
また、ステップＳ２２２０において、トポロジ取得方式データ１６００を１つに定める際、最も探索関連数の少ないトポロジ取得方式データ１６００が最終的に残される１つのトポロジ取得方式データ１６００として選択されたが、これ以外の判断基準によって最終的に残されるトポロジ取得方式データ１６００が選択されてもよい。また、ＧＵＩ等のインターフェースを通じてユーザに最終的に残されるトポロジ取得方式データ１６００を選択させてもよい。【０２０２】
図２３は、実施例１に係るトポロジ取得方式分割処理の一例のフローチャートである。【０２０３】
トポロジ分割処理では、単位関連に関する変更頻度に基づいてトポロジ取得方式が分割され、分割の結果に合わせてメタルール３００が生成される。【０２０４】
ステップＳ２３１１において、メタルール生成プログラム１２１のサブプログラムであるトポロジ取得方式分割プログラムは、原因情報、影響情報、および対応関係データをパラメータとして受信する。【０２０５】
ステップＳ２３１２において、トポロジ取得方式分割プログラムは、ステップＳ２３１１で受信した対応関係データが示す１以上のトポロジ取得方式データ１６００のそれぞれについて、ステップＳ２３１３〜ステップＳ２３２０の処理を繰り返す。【０２０６】
ステップＳ２３１３において、トポロジ取得方式分割プログラムは、ステップＳ２３１２で選択した処理対象のトポロジ取得方式データ１６００（以下「対象トポロジ取得方式データ」と称する）が示す経路構成グループに含まれる複数の単位関連のそれぞれについて、対象トポロジ取得方式データが示す経路の一方の端点に関係する単位関連から他方の端点に関係する単位関連までその経路に従って順に選択し、ステップＳ２３１４〜ステップＳ２３１９の処理を繰り返す。なお、選択した単位関連が上位関連を有する場合、トポロジ取得方式分割プログラムは、選択した単位関連の代わりにその上位関連を選択する。【０２０７】
ステップＳ２３１４において、トポロジ取得方式分割プログラムは、関連テーブル１３３を参照し、ステップＳ２３１３で選択した単位関連（以下「対象単位関連」と称する）に関する変更頻度が所定の閾値（以下「分割閾値」と称する）を超過しているかどうかを確認する。【０２０８】
ステップＳ２３１５において、トポロジ取得方式分割プログラムは、対象単位関連に関する変更頻度が分割閾値を超過しており、かつ対象単位関連の直前に選択した単位関連（以下「直前単位関連」と称する）に関する変更頻度が分割閾値を超過していない場合、または、対象単位関連に関する変更頻度が分割閾値を超過しておらず、かつ直前単位関連に関する変更頻度が分割閾値を超過している場合（ステップＳ２３１５：ＹＥＳ）、ステップＳ２３１６〜ステップＳ２３１９の処理を実行する。一方、上記条件に該当しない場合、または対象単位関連が最初に選択された単位関連である場合（ステップＳ２３１５：ＮＯ）、トポロジ取得方式分割プログラムは、ステップＳ２３１６〜ステップＳ２３１９の処理を実行せずに、処理をステップＳ２２１３に進める。【０２０９】
ステップＳ２３１６において、トポロジ取得方式分割プログラムは、対象トポロジ取得方式データが示す経路構成グループを構成する複数の単位関連の組み合わせを、対象単位関連以外の単位関連であってステップＳ２３１３で既に選択された１以上の単位関連の組み合わせ（以下「第１の経路構成グループ」と称する）と、それ以外の１以上の単位関連の組み合わせ（以下「第２の経路構成グループ」と称する）とに分割する。そして、トポロジ取得方式分割プログラムは、対象トポロジ取得方式データを、第１の経路構成グループを構成する１以上の単位関連のそれぞれに関する情報を含むトポロジ取得方式データ１６００と、第２の経路構成グループを構成する１以上の単位関連のそれぞれに関する情報を含むトポロジ取得方式データ１６００とに分割する。なお、分割後のトポロジ取得方式データ１６００が示すトポロジ取得方式には、新しく仮方式ＩＤが割り当てられる。【０２１０】
ステップＳ２３１７において、トポロジ取得方式分割プログラムは、対象単位関連および直前単位関連のいずれにも関係する管理オブジェクトの種類、すなわち分割の境目となる管理オブジェクトの種類を接点オブジェクトの種類として特定する。そして、トポロジ取得方式分割プログラムは、特定した管理オブジェクトの種類が、第１の経路構成グループおよび第２の経路構成グループについての接点オブジェクトの種類であることを示すデータを接点オブジェクト情報に含める。そして、トポロジ取得方式分割プログラムは、特定した接点オブジェクトの種類に関する中間イベントを作成する。管理コンピュータ１０１は、中間イベントの種類を任意に設定することができるが、過去に作成した中間イベントに関する情報を管理する等して、作成済みの他の中間イベントの種類と重複しないようにする。【０２１１】
ステップＳ２３１８において、トポロジ取得方式分割プログラムは、メタルール生成処理を実行し、第１の経路構成グループに対応するトポロジ取得方式データ１６００についてのメタルール３００を生成する。トポロジ取得方式分割プログラムは、メタルール生成処理を実行する際、メタルール生成処理によって生成されるメタルール３００（以下「対象メタルール」と称する）の１以上の影響イベントおよび原因イベントを示す情報と、対象メタルールに関連付けられるトポロジ取得方式データ１６００、ここでは、第１の経路構成グループに対応するトポロジ取得方式データ１６００の仮方式ＩＤとを含む対象メタルール情報を入力する。【０２１２】
例えば、トポロジ取得方式分割プログラムは、第１の経路構成グループを構成する１以上の単位関連に関係する複数の管理オブジェクトの種類の組み合わせ（以下「種類群」と称する）の中に、ステップＳ２３１１で受信した原因情報が示す原因イベントに関係する管理オブジェクトの種類（第３の管理オブジェクトの種類）が含まれる場合、原因情報が示す原因イベントを、対象メタルールの原因イベントとする。また、トポロジ取得方式分割プログラムは、種類群の中に、ステップＳ２３１１で受信した影響情報が示す影響イベントに関係する管理オブジェクトの種類が含まれる場合、当該影響イベントを、対象メタルールの影響イベントの１つとする。【０２１３】
また、例えば、トポロジ取得方式分割プログラムは、種類群の中に、接点オブジェクトの種類（第４の管理オブジェクトの種類）と、原因情報が示す原因イベントに関係する管理オブジェクトの種類とが含まれる場合、接点オブジェクトの種類に関する中間イベントを、対象メタルールの影響イベントの１つとする。また、トポロジ取得方式分割プログラムは、種類群の中に１つの接点オブジェクトの種類が含まれ、かつ、種類群の中に原因情報が示す原因イベントに関係する管理オブジェクトの種類が含まれない場合、接点オブジェクトの種類に関する中間イベントを、対象メタルールの原因イベントとする。また、トポロジ取得方式分割プログラムは、種類群の中に複数の接点オブジェクトの種類が含まれ、かつ、種類群の中に原因情報が示す原因イベントに関係する管理オブジェクトの種類が含まれない場合、複数の接点オブジェクトの種類のうちの、原因情報が示す原因イベントに関係する管理オブジェクトの種類との間に介在する単位関連の数が最も少ない接点オブジェクトの種類（第５の管理オブジェクトの種類）に関する中間イベントを、対象メタルールの原因イベントとし、それ以外の接点オブジェクトの種類に関する中間イベントを、対象メタルールの影響イベントの１つとする。【０２１４】
なお、種類群に含まれる管理オブジェクトの種類が接点オブジェクトの種類であるか否かは、例えば、メモリ１１２に記憶されている接点オブジェクト情報を参照することにより判定される。【０２１５】
ステップＳ２３１９において、トポロジ取得方式分割プログラムは、第２の経路構成グループに対応するトポロジ取得方式データ１６００を対象トポロジ取得方式データとして、ステップＳ２３１３〜ステップＳ２３１９の処理を行う。【０２１６】
対象トポロジ取得方式データが示す経路構成グループに含まれる全ての単位関連に対する処理を終えた後、ステップＳ２３２０において、トポロジ取得方式分割プログラムは、メタルール生成処理を実行し、最後に残った第２の経路構成グループに対応するトポロジ取得方式データ１６００についてのメタルール３００を生成する。ここで生成するメタルール３００の原因イベントおよび影響イベントをどのように決定するかについては、第１の経路構成グループに対応するトポロジ取得方式データ１６００についてのメタルール３００を生成する場合と同様である。【０２１７】
対応関係データが示す１以上のトポロジ取得方式データ１６００のそれぞれに対する処理を終えた後、ステップＳ２３２１において、トポロジ取得方式分割プログラムは、生成したメタルール３００を示す情報を呼び出し元プログラムに渡す。【０２１８】
例えば、ステップＳ２３１１において、トポロジ取得方式分割プログラムは、ストレージのストレージディスクに関するディスク使用率上昇エラーの原因イベントを示す原因情報と、サーバのディスクドライブに関する転送時間性能エラーの影響イベント（イベントＡ）、ストレージの論理ボリュームに関するＩＯレスポンスタイム上昇エラーの影響イベント（イベントＢ）、および、ストレージのストレージコントローラに関するＣＰＵ使用率上昇エラーの影響イベント（イベントＣ）の未検知のそれぞれを示す影響情報とを受信する。また、トポロジ取得方式分割プログラムは、イベントＡ、イベントＢおよびイベントＣと図１６Ａに示すトポロジ取得方式１６００Ａとの対応関係、並びに、イベントＣと図１６Ｂに示すトポロジ取得方式１６００Ｂとの対応関係を示す対応関係データを受信する。【０２１９】
ステップＳ２３１２の繰り返し処理で図１６Ａに示すトポロジ取得方式１６００Ａを選択した場合、トポロジ取得方式分割プログラムは、ステップＳ２３１４において、単位関連「ＡＳ３」、単位関連「ＡＳ１２」、および単位関連「ＡＳ１５」のそれぞれに関する変更頻度を、例えば単位関連「ＡＳ３」から順に確認する。分割閾値が５０だとした場合、単位関連「ＡＳ１２」および単位関連「ＡＳ１５」のそれぞれに関する変更頻度は分割閾値を超えていないが、単位関連「ＡＳ３」に関する変更頻度は分割閾値を超過している（図１５参照）。そのため、トポロジ取得方式分割プログラムは、ステップＳ２３１３において単位関連「ＡＳ１２」を選択した時点で処理をステップＳ２３１６へ進める。【０２２０】
トポロジ取得方式分割プログラムは、ステップＳ２３１６において、単位関連「ＡＳ３」、単位関連「ＡＳ１２」、および単位関連「ＡＳ１５」の組み合わせを、対象単位関連である単位関連「ＡＳ１２」以外の既に選択された単位関連「ＡＳ３」を構成要素とする第１の経路構成グループと、それ以外の単位関連、すなわち単位関連「ＡＳ１２」および単位関連「ＡＳ１５」を構成要素とする第２の経路構成グループとに分割する。そして、トポロジ取得方式分割プログラムは、ステップＳ２３１７において、接点オブジェクトの種類として、単位関連「ＡＳ３」および単位関連「ＡＳ１２」のいずれにも関係する論理ボリュームを特定し、論理ボリュームに関する中間イベント、例えば「ＭｉｄＥｒｒｏｒ１」を作成する。その後、トポロジ取得方式分割プログラムは、ステップＳ２３１８において、第１の経路構成グループに対応するトポロジ取得方式データ１６００、すなわち図１６Ｃに示すトポロジ取得方式データ１６００Ｃについてのメタルール３００を生成する。この結果、例えば、図３Ｂに示すメタルール３００Ｂが生成される。【０２２１】
その後、トポロジ取得方式分割プログラムは、第２の経路構成グループに対応するトポロジ取得方式データ１６００、すなわち図１６Ｄに示すトポロジ取得方式データ１６００Ｄを対象トポロジ取得方式データとして、ステップＳ２３１３〜ステップＳ２３１９の処理を行う。以降の繰り返し処理では、ステップＳ２３１５の判定の結果が肯定となることはないため、トポロジ取得方式データ１６００Ｄが分割されることはない。トポロジ取得方式分割プログラムは、ステップＳ２３２０において、最後に残った第２の経路構成グループに対応するトポロジ取得方式データ１６００、すなわちトポロジ取得方式データ１６００Ｄについてのメタルール３００を生成する。この結果、例えば、図３Ｄに示すメタルール３００Ｄが生成される【０２２２】
また、ステップＳ２３１２の繰り返し処理で図１６Ｂに示すトポロジ取得方式１６００Ｂが選択された場合、トポロジ取得方式１６００Ｂを示す経路構成グループには単位関連が１つしか含まれないため、トポロジ取得方式１６００Ｂが分割されることはない。トポロジ取得方式分割プログラムは、ステップＳ２３２０において、トポロジ取得方式データ１６００Ｂについてのメタルール３００を生成する。この結果、例えば、図３Ｃに示すメタルール３００Ｃが生成される。【０２２３】
最後に、トポロジ取得方式分割プログラムは、生成したメタルール３００Ｂ、メタルール３００Ｃ、およびメタルールＤを示す情報を呼び出し元プログラムに渡す。【０２２４】
なお、本実施例ではトポロジを分割するか否かを判断するために、単位関連に関する変更頻度が分割閾値を超過しているか否かを確認しているが、単位関連ごとの変更頻度の高低をユーザが事前にフラグとして設定しておいてもよい。その場合、例えば、関連テーブル１３３の変更頻度１５０７は、変更頻度の高低を表すフラグとなる。【０２２５】
図２４は、実施例１に係るメタルール生成処理の一例のフローチャートである。【０２２６】
ステップＳ２４１１において、メタルール生成プログラム１２１は、対象メタルールの１以上の影響イベントおよび原因イベントを示す情報と、対象メタルールに関連付けられるトポロジ取得方式データ１６００の仮方式ＩＤとを含む対象メタルール情報をパラメータとして受信する。【０２２７】
ステップＳ２４１２において、メタルール生成プログラム１２１は、対象メタルール情報が示す１以上の影響イベントおよび原因イベントのそれぞれを影響イベントとするＩＦ部３１１を生成する。【０２２８】
ステップＳ２４１３において、メタルール生成プログラム１２１は、対象メタルール情報が示す原因イベントを原因イベントとするＴＨＥＮ部３１２を生成し、ステップＳ２４１２で生成したＩＦ部３１１と組み合わせて対象メタルールを生成する。【０２２９】
ステップＳ２４１４において、メタルール生成プログラム１２１は、対象メタルールにメタルールＩＤを割り当て、割り当てたメタルールＩＤをメタルールＩＤ３１３に設定する。【０２３０】
ステップＳ２４１８において、メタルール生成プログラム１２１は、対象メタルール情報に含まれる１以上の仮方式ＩＤによって示される１以上のトポロジ取得方式データ１６００のそれぞれについて、ステップＳ２４１９〜ステップＳ２４２１の処理を繰り返す。【０２３１】
ステップＳ２４１９において、メタルール生成プログラム１２１は、処理対象のトポロジ取得方式データ１６００がトポロジ取得方式リポジトリ１３４に含まれているか否かを判定する。条件を満たす場合、すなわち処理対象のトポロジ取得方式データ１６００がトポロジ取得方式リポジトリ１３４に含まれている場合（ステップＳ２４１９：ＹＥＳ）、メタルール生成プログラム１２１は、処理をステップＳ２４２２に進める。一方、条件を満たさない場合、すなわち処理対象のトポロジ取得方式データ１６００がトポロジ取得方式リポジトリ１３４に含まれていない場合（ステップＳ２４１９：ＮＯ）、メタルール生成プログラム１２１は、処理をステップＳ２４２０に進める。【０２３２】
ステップＳ２４２０において、メタルール生成プログラム１２１は、処理対象のトポロジ取得方式データ１６００が示すトポロジ取得方式に正式な方式ＩＤを割り当て、処理対象のトポロジ取得方式データ１６００をトポロジ取得方式リポジトリ１３４に登録する。【０２３３】
ステップＳ２４２１において、メタルール生成プログラム１２１は、ステップＳ２４２０において処理対象のトポロジ取得方式データ１６００が示すトポロジ取得方式に割り当てた方式ＩＤを対象メタルールのトポロジ取得方式ＩＤ３１４に格納する。【０２３４】
また、メタルール生成プログラム１２１は、ステップＳ２４１９において処理をステップＳ２４２２に進めた場合、ステップＳ２４２２において、トポロジ取得方式リポジトリ１３４に登録されているトポロジ取得方式データ１６００の中から、処理対象のトポロジ取得方式データ１６００と同一のトポロジ取得方式データ１６００を特定し、特定したトポロジ取得方式データ１６００の方式ＩＤ１６０１に格納されている方式ＩＤを取得する。【０２３５】
ステップＳ２４２３において、メタルール生成プログラム１２１は、ステップＳ２４２２で取得した方式ＩＤを対象メタルールのトポロジ取得方式ＩＤ３１４に格納する。【０２３６】
その後、ステップＳ２４２４において、メタルール生成プログラム１２１は、対象メタルールを示す情報をメタルール生成処理の呼び出し元プログラムに渡す。なお、メタルール生成プログラム１２１は、ステップＳ２４２１またはステップＳ２４２３で格納した複数の方式ＩＤのそれぞれに対応する複数のトポロジ取得方式データ１６００が示す経路の間で、重複する部分が存在する場合、その重複部分がなくなるようにトポロジ取得方式データ１６００を削除または変更してもよい。【０２３７】
例えば、ステップＳ２４１１において、サーバのディスクドライブに関する転送時間性能エラーの影響イベントと、ストレージのストレージポートに関する中間イベント「ＭｉｄＥｒｒｏｒ２」の影響イベントと、ストレージの論理ボリュームに関する中間イベント「ＭｉｄＥｒｒｏｒ１」の原因イベントとを示す対象メタルール情報を受信した場合、メタルール生成プログラム１２１は、図３Ｂに示すメタルール３００Ｂを生成する。【０２３８】
＜障害解析の処理＞【０２３９】
図２５Ａは、実施例１に係る障害解析処理の一例の第１フローチャートである。図２５Ｂは、実施例１に係る障害解析処理の一例の第２フローチャートである。【０２４０】
障害解析プログラム１２３は、例えば、イベント受信プログラム１２２が管理対象装置からイベント情報を受信してイベントテーブル１３１にイベント情報を書き込んだ後に呼び出されることにより、障害解析処理を開始する。【０２４１】
障害解析プログラム１２３は、受信したイベントと、メタルールリポジトリ１３５内のメタルール３００に基づいて、必要な展開ルール１７００を生成し、障害の原因候補とその影響範囲とを運用管理者に提示するために障害解析処理を実行する。また、受信したイベントに基づいて、不要となった展開ルール１７００を展開ルールリポジトリ１３６から削除する。【０２４２】
図２５ＡのステップＳ２５１１において、障害解析プログラム１２３は、未処理の変更イベントを示すエントリを変更イベントテーブル１３１Ｂから取得する。例えば、障害解析プログラム１２３は、変更イベントテーブル１３１Ｂの処理済みフラグ２５６が「Ｎｏ」の変更イベントのうちの発生日時が最も古い変更イベントのエントリを取得する。【０２４３】
ステップＳ２５１２において、障害解析プログラム１２３は、未処理の変更イベントを取得できたかどうか（未処理の変更イベントを示すエントリを取得できたかどうか）を判定する。取得できた場合（ステップＳ２５１２：ＹＥＳ）、障害解析プログラム１２３は、処理をステップＳ２５１３に進める。取得できなかった場合（ステップＳ２５１２：ＮＯ）、障害解析プログラム１２３は、処理を図２５ＢのステップＳ２５１６に進める。【０２４４】
ステップＳ２５１３において、障害解析プログラム１２３は、ステップＳ２５１１で取得した変更イベント（ステップＳ２５１１で取得したエントリが示す変更イベント）を処理済みの変更イベントとして登録する。具体的には、障害解析プログラム１２３は、変更イベントテーブル１３１Ｂの処理済みフラグ２５６を「Ｎｏ」から「Ｙｅｓ」に変更する。【０２４５】
ステップＳ２５１４において、障害解析プログラム１２３は、ステップＳ２５１１で取得した変更イベントの識別情報を入力として、ルール削除処理を実行する。ルール削除処理により、展開ルールリポジトリ１３６に記憶されている１以上の展開ルール１８００の中から、構成変更後の構成管理ＤＢ１３２内の情報と矛盾が生じた展開ルール１８００が特定され、特定された展開ルール１８００が展開ルールリポジトリ１３６から削除される。【０２４６】
ステップＳ２５１５において、障害解析プログラム１２３は、変更イベントテーブル１３１Ｂにおける、ステップＳ２５１１で取得した変更イベントを示すエントリのコンポーネントＩＤ２５３に格納されているコンポーネントＩＤを取得する。そして、障害解析プログラム１２３は、関連テーブル１３３において、取得したコンポーネントＩＤに対応するコンポーネントの種類を示すデータがテーブル名Ｘ１５０２またはテーブル名Ｙ１５０４に格納されているエントリを取得する。そして、障害解析プログラム１２３は、取得したエントリが示す単位関連における通算変更回数および当該単位関連に関する変更頻度を更新する。【０２４７】
なお、ステップＳ２５１５において、変更イベントテーブル１３１Ｂにおける、ステップＳ２５１１で取得した変更イベントを示すエントリのコンポーネントＩＤ２５３に「ＮＵＬＬ」が格納されている場合は、障害解析プログラム１２３は、当該エントリの装置ＩＤ２５２に格納されている装置ＩＤを取得する。そして、障害解析プログラム１２３は、関連テーブル１３３において、取得した装置ＩＤに対応する管理対象装置の種類を示すデータがテーブル名Ｘ１５０２またはテーブル名Ｙ１５０４に格納されているエントリを取得する。そして、障害解析プログラム１２３は、取得したエントリが示す単位関連における通算変更回数および当該単位関連に関する変更頻度を更新する。その後、障害解析プログラム１２３は、障害解析処理を終了する。【０２４８】
図２５ＢのステップＳ２５１６において、障害解析プログラム１２３は、未処理の障害イベントを示すエントリを障害イベントテーブル１３１Ａから取得する。例えば、障害解析プログラム１２３は、障害イベントテーブル１３１Ａの処理済みフラグ２０６が「Ｎｏ」の障害イベントのうちの発生日時が最も古い障害イベントを示すエントリを取得する。【０２４９】
ステップＳ２５１７において、障害解析プログラム１２３は、ステップＳ２５１６で取得した障害イベント（ステップＳ２５１６で取得したエントリが示す障害イベント）を処理済みの障害イベントとして登録する。具体的には、障害解析プログラム１２３は、障害イベントテーブル１３１Ａの処理済みフラグ２０６を「Ｎｏ」から「Ｙｅｓ」に変更する。【０２５０】
ステップＳ２５１９において、障害解析プログラム１２３は、ステップＳ２５１６で取得した障害イベントに関係する管理対象装置の装置ＩＤ、当該障害イベントに関係するコンポーネントのコンポーネントＩＤ、および当該障害イベントの種類を示す情報を入力して、ルール展開処理を実行する。ルール展開処理により、ステップＳ２５１６で取得した障害イベントの原因解析に利用される展開ルール１８００であって展開ルールリポジトリ１３６に記憶されていない展開ルール１８００が生成され、生成された展開ルール１８００が展開ルールリポジトリ１３６に記憶される。【０２５１】
ステップＳ２５２１において、障害解析プログラム１２３は、ステップＳ２５１６で取得した障害イベントを影響イベントとして含む１以上の展開ルール１８００を展開ルールリポジトリ１３６から取得する。【０２５２】
ステップＳ２５２２において、障害解析プログラム１２３は、ステップＳ２５２１で取得した１以上の展開ルールのそれぞれについて、ステップＳ２５２３〜ステップＳ２５２７の処理を繰り返す。【０２５３】
ステップＳ２５２３において、障害解析プログラム１２３は、処理対象の展開ルール１８００にける、ステップＳ２５１６で取得した障害イベントを示す条件要素１８１４の受信フラグ１８０４を「１」に変更する。【０２５４】
ステップＳ２５２４において、障害解析プログラム１２３は、処理対象の展開ルール１８００に中間イベントである影響イベントが含まれている場合、その中間イベントを原因イベントとする展開ルール１８００を展開ルールリポジトリ１３６から取得し、取得した展開ルール１８００のイベント受信率を計算する。【０２５５】
ステップＳ２５２５において、障害解析プログラム１２３は、処理対象の展開ルール１８００のイベント受信率を計算する。処理対象の展開ルール１８００に中間イベントである影響イベントが含まれている場合、障害解析プログラム１２３は、ステップＳ２５２４で計算したイベント受信率をも考慮して、処理対象の展開ルール１８００のイベント受信率を計算する。【０２５６】
ステップＳ２５２６において、障害解析プログラム１２３は、処理対象の展開ルール１８００の原因イベントが中間イベントである場合、その中間イベントを影響イベントとして含む展開ルール１８００を展開ルールリポジトリ１３６から取得し、取得した展開ルール１８００のイベント受信率を計算する。【０２５７】
ステップＳ２５２７において、障害解析プログラム１２３は、処理対象の展開ルール１８００の原因イベントが中間イベントである場合、表示モジュール１２５を起動し、ステップＳ２５２６で取得した展開ルール１８００の原因イベントを原因候補とし、処理対象の展開ルール１８００の影響イベントおよびステップＳ２５２６で取得した展開ルール１８００の影響イベントを原因候補に対する影響範囲とし、さらに、ステップＳ２５２６で算出したイベント受信率を原因候補の確信度とし、それらを解析結果として出力デバイス１１７に表示する。【０２５８】
一方、処理対象の展開ルール１８００の原因イベントが中間イベントでない場合、障害解析プログラム１２３は、表示モジュール１２５を起動し、処理対象の展開ルール１８００の原因イベントを障害の原因候補とし、処理対象の展開ルール１８００の影響イベントを原因候補に対する影響範囲とし、さらに、ステップＳ２５２５で算出したイベント受信率を原因候補の確信度とし、それらを解析結果として出力デバイス１１７に表示する。なお、処理対象の展開ルール１８００に中間イベントである影響イベントが含まれている場合は、その中間イベントを原因イベントとする展開ルール１８００の影響イベントも、原因候補に対する影響範囲に含められる。また、すでに原因イベントが原因候補として出力デバイス１１７に表示されている場合、高い方のイベント受信率が表示されてもよい。その後、障害解析プログラム１２３は、障害解析を終了する。【０２５９】
以上に説明したように、障害解析プログラム１２３が実行する障害解析処理によって、管理コンピュータ１０１は、計算機システムにおいて障害が発生した場合に、障害の原因候補およびその影響範囲を自動的に導出し、運用管理者に提示することができる。【０２６０】
なお、管理コンピュータ１０１は、障害解析処理を高速化するために、ステップＳ２５１９で展開ルール１８００を生成する前に、生成しようとする展開ルール１８００が既に展開ルールリポジトリ１３６内に含まれているか否かが分かるように、展開履歴を作成してもよい。【０２６１】
また、障害解析処理を高速化する公知の技術（例えば、特表２０１１−５１８３５９号公報に開示されるもの）を適用してもよい。また、管理コンピュータ１０１は、障害イベントを受信するごとに展開ルール１８００を生成せずに、障害が発生する前に全ての展開ルール１８００を生成してもよい。【０２６２】
また、図２５Ａおよび図２５Ｂに示す障害解析処理では、管理コンピュータ１０１は、発生した障害イベントを含む展開ルール１８００のみしか作成していないが、ステップＳ２５２１で取得した展開ルール１８００の原因イベントの情報、および当該原因イベントに関連するメタルール３００を入力として、ルール展開処理を起動し、当該原因イベントを含む展開ルール１８００を全て生成し、それらの展開ルール１８００も含めてステップＳ２５２１以降の処理を実行して解析結果を提示してもよい。これにより、ある原因候補に対する影響を受けて発生し得る全ての障害イベントを表示することができる。【０２６３】
図２６Ａは、実施例１に係るルール展開処理の一例の第１フローチャートである。図２６Ｂは、実施例１に係るルール展開処理の一例の第２フローチャートである。【０２６４】
障害解析プログラム１２３のサブプログラムであるルール展開プログラムは、ルール展開処理において、入力された障害イベントに対応するイベントを影響イベントとして含むメタルール３００に、入力された障害イベントに関係する管理オブジェクトを起点とするトポロジを適用して展開ルール１８００を生成する。【０２６５】
ステップＳ２６１１において、ルール展開プログラムは、障害イベントを示す情報、すなわち、当該障害イベントに関係する管理対象装置の装置ＩＤ、当該障害イベントに関係するコンポーネントのコンポーネントＩＤ、および当該障害イベントの種類を示す情報をパラメータとして受信する。【０２６６】
ステップＳ２６１２において、ルール展開プログラムは、ステップＳ２６１１で受信した障害イベント（ステップＳ２６１１で受信した情報によって示される障害イベント）に対応するイベントを影響イベントとして含む１以上のメタルール３００をメタルールリポジトリ１３５から取得する。【０２６７】
例えば、ステップＳ２６１１で障害イベントテーブル１３１Ａのエントリ２１３が示す障害イベントが取得された場合、この障害イベントに関係する管理対象装置の装置ＩＤは「ＳｖＡ」であり、この障害イベントに関係するコンポーネントのコンポーネントＩＤは「ＤＲＩＶＥ１」である。すなわち、この障害イベントに関係する管理対象装置の種類はサーバであり、この障害イベントに関係するコンポーネントの種類はディスクドライブである。また、この障害イベントの種類は「AverageSecPerXferError」である。このため、ルール展開プログラムは、サーバのディスクドライブに関する「AverageSecPerXferError」の障害イベントを影響イベントとして含むメタルール３００、例えば図３Ｂに示すメタルール３００Ｂを取得する。【０２６８】
ステップＳ２６１３において、ルール展開プログラムは、ステップＳ２６１２で取得した１以上のメタルール３００のそれぞれについて、ステップＳ２６１４〜ステップＳ２６２５の処理を繰り返す。【０２６９】
ステップＳ２６１４において、ルール展開プログラムは、処理対象のメタルール３００を基に展開され、かつ、ステップＳ２６１１で受信した障害イベントを影響イベントとして含む展開ルール１８００を展開ルールリポジトリ１３６から取得する。【０２７０】
ステップＳ２６１５において、ルール展開プログラムは、ステップＳ２６１４において該当する展開ルール１８００を取得できたか否かを判定する。条件を満たす場合、すなわち該当する展開ルール１８００を取得できた場合（ステップＳ２６１５：ＹＥＳ）、ルール展開プログラムは、未だ処理対象とされていないメタルール３００について、ステップＳ２６１４〜ステップＳ２６２５の処理を行う。一方、条件を満たさない場合、すなわち該当する展開ルール１８００を取得できなかった場合（ステップＳ２６１５：ＮＯ）、ルール展開プログラムは、処理をステップＳ２６１６に進める。【０２７１】
ステップＳ２６１６において、ルール展開プログラムは、処理対象のメタルール３００のトポロジ取得方式ＩＤ３１４に格納されている方式ＩＤに対応するトポロジ取得方式データ１６００を、トポロジ取得方式リポジトリ１３４から取得する。【０２７２】
ステップＳ２６１７において、ルール展開プログラムは、構成管理ＤＢ１３２から、ステップＳ２６１１で受信した障害イベントの受信日時における構成管理テーブルを抽出する。【０２７３】
ステップＳ２６１８において、ルール展開プログラムは、ステップＳ２６１１で受信した障害イベントに関係する管理対象装置の装置ＩＤまたは当該障害イベントに関係するコンポーネントのコンポーネントＩＤを起点として、ステップＳ２６１６で取得したトポロジ取得方式データ１６００、およびステップＳ２６１７で抽出した構成管理テーブルに基づいて、処理対象のメタルール３００に適用されるトポロジデータ１７００を生成する。【０２７４】
例えば、ルール展開プログラムは、ステップＳ２６１１でディスクドライブ「ＤＲＩＶＥ１」に関する障害イベントを受信した場合、ステップＳ２６１６で図１６Ｃに示すトポロジ取得方式データ１６００Ｃを取得する。そして、ルール展開プログラムは、ステップＳ２６１８で抽出した構成管理テーブルが図４〜図１３に示すテーブルであった場合、例えば、論理ボリューム「ＶＯＬ１」とディスクドライブ「ＤＲＩＶＥ１」とを含むトポロジを示すトポロジデータ１７００を生成する。【０２７５】
図２６ＢのステップＳ２６１９において、ルール展開プログラムは、ステップＳ２６１８で生成した１以上のトポロジデータ１７００のそれぞれに対して、ステップＳ２６２０およびステップＳ２６２１の処理を繰り返す。【０２７６】
ステップＳ２６２０において、ルール展開プログラムは、処理対象のメタルール３００に処理対象のトポロジデータ１７００が示すトポロジを適用することで、処理対象のメタルール３００に対応する展開ルール１８００を生成する。具体的には、ルール展開プログラムは、処理対象のトポロジデータ１７００が示すトポロジを構成する管理オブジェクトの中から、処理対象のメタルール３００の影響イベントに関係する管理オブジェクトの種類に属する管理オブジェクトを抽出し、抽出した管理オブジェクトに関係する当該影響イベントを、生成する展開ルール１８００の影響イベントとする。また、ルール展開プログラムは、処理対象のトポロジデータ１７００が示すトポロジを構成する管理オブジェクトの中から、処理対象のメタルール３００の原因イベントに関係する管理オブジェクトの種類に属する管理オブジェクトを抽出し、抽出した管理オブジェクトに関係する当該原因イベントを、生成する展開ルール１８００の原因イベントとする。【０２７７】
例えば、ルール展開プログラムは、ステップＳ２６１３の繰り返し処理において図３Ｂに示すメタルール３００Ｂを選択し、ステップＳ２６１９の繰り返し処理において論理ボリューム「ＶＯＬ１」とディスクドライブ「ＤＲＩＶＥ１」とを含むトポロジを示すトポロジデータ１７００を選択した場合、メタルール３００Ｂの原因イベントに関係するコンポーネントの種類が論理ボリュームであるため、トポロジデータ１７００が示すトポロジに含まれる管理オブジェクトのうちの論理ボリューム「ＶＯＬ１」を、メタルール３００Ｂの原因イベントに関係する管理オブジェクトの種類に属する管理オブジェクトとして抽出する。そして、ルール展開プログラムは、論理ボリューム「ＶＯＬ１」に関する「ＭｉｄＥｒｒｏｒ１」の障害イベントを、メタルール３００Ａに対応する展開ルール１８００の原因イベントとする。同様に影響イベントに関係する管理オブジェクトも抽出され、メタルール３００Ａに対応する展開ルール１７００が生成される。【０２７８】
ステップＳ２６２１において、ルール展開プログラムは、ステップＳ２６２０において生成した展開ルール１８００を展開ルールリポジトリ１３６に登録する。【０２７９】
ステップＳ２６２２において、ルール展開プログラムは、ステップＳ２６２０において生成した展開ルール１８００に中間イベントが含まれているか否かを判定する。条件を満たさない場合、すなわち生成した展開ルール１８００に中間イベントが含まれていない場合（ステップＳ２６２２：ＮＯ）、ルール展開プログラムは、未だ処理対象とされていないメタルール３００について、ステップＳ２６１４〜ステップＳ２６２５の処理を行う。一方、条件を満たす場合、すなわち生成した展開ルール１８００に中間イベントが含まれている場合（ステップＳ２６２２：ＹＥＳ）、ルール展開プログラムは、処理をステップＳ２６２３に進める。【０２８０】
ステップＳ２６２３において、ルール展開プログラムは、ステップＳ２６２０において生成した展開ルール１８００に含まれている１以上の中間イベントのそれぞれに対して、ステップＳ２６２４の処理を繰り返す。【０２８１】
ステップＳ２６２４において、ルール展開プログラムは、処理対象の中間イベントに関係する管理対象装置の装置ＩＤ、処理対象の中間イベントに関係するコンポーネントのコンポーネントＩＤ、および処理対象の中間イベントの種類を示す情報を入力として、ルール展開処理を再帰的に実行する。【０２８２】
ステップＳ２６１２で取得したメタルール３００のそれぞれについて処理を終えた後、ルール展開プログラムは、ルール展開処理を終了する。【０２８３】
図２７は、実施例１に係るルール削除処理の一例のフローチャートである。【０２８４】
ステップＳ２７１１において、障害解析プログラム１２３のサブプログラムであるルール削除プログラムは、変更イベントの識別情報をパラメータとして受信する。そして、ルール削除プログラムは、変更イベントテーブル１３１Ｂにおいて、受信した識別情報が示す変更イベントを示すエントリを特定し、特定したエントリの装置ＩＤ２５２に格納されている装置ＩＤと、特定したエントリのコンポーネントＩＤ２５３に格納されているコンポーネントＩＤと、特定したエントリのイベント種別２５４に格納されているデータ、すなわち変更イベントの種類を示すデータとを取得する。【０２８５】
ステップＳ２７１２において、ルール削除プログラムは、ステップＳ２７１１において取得したコンポーネントＩＤが「ＮＵＬＬ」であるか否か、すなわち変更イベントに対応する構成変更が装置全体の追加または削除であるか否かを判定する。条件を満たす場合、すなわち構成変更が装置全体の追加または削除である場合（ステップＳ２７１２：ＹＥＳ）、ルール削除プログラムは、処理をステップＳ２７１３に進める。一方、条件を満たさない場合、すなわち構成変更が装置全体の追加または削除でない場合（ステップＳ２７１２：ＮＯ）、ルール削除プログラムは、処理をステップＳ２７１４に進める。【０２８６】
ステップＳ２７１３において、ルール削除プログラムは、展開ルールリポジトリ１３６に記憶されている全ての展開ルール１８００を展開ルールリポジトリ１３６から削除する。なぜなら、変更イベントに対応する構成変更が装置全体の追加もしくは削除である場合、その影響範囲がどの展開ルール１８００にまで及んでいるかを特定するのに多大なコストを要するからである。その後、ルール削除プログラムは、ルール削除処理を終了する。【０２８７】
ステップＳ２７１４において、ルール削除プログラムは、ステップＳ２７１１において取得した変更イベントの種類を示すデータが「ＡＤＤ」であるか否かを判定する。条件を満たす場合、すなわち変更イベントの種類を示すデータが「ＡＤＤ」である場合（ステップＳ２７１４：ＹＥＳ）、ルール削除プログラムは、処理をステップＳ２７１５に進める。一方、条件を満たさない場合、すなわち変更イベントの種類を示すデータが「ＡＤＤ」ではない場合（ステップＳ２７１４：ＮＯ）、ルール削除プログラムは、処理をステップＳ２７１９に進める。【０２８８】
ステップＳ２７１５において、ルール削除プログラムは、ステップＳ２７１１において取得したコンポーネントＩＤを持つコンポーネントと関連のある１以上のコンポーネントを特定する。具体的には、ルール削除プログラムは、まず、構成管理ＤＢ１３２を参照し、取得したコンポーネントＩＤを持つコンポーネントの種類を特定する。次に、ルール削除プログラムは、関連テーブル１３３から、特定したコンポーネントの種類を示すデータがテーブル名Ｘ１５０２またはテーブル名Ｙ１５０４に格納されている全てのエントリを取得する。次に、取得したエントリが示す単位関連に基づいて、取得したコンポーネントＩＤを持つコンポーネントと関連のある全てのコンポーネントを特定する。【０２８９】
ステップＳ２７１６において、ルール削除プログラムは、ステップＳ２７１５において特定したコンポーネントを含むトポロジを示す１以上のトポロジデータ１７００をトポロジリポジトリ１３７から取得する。【０２９０】
ステップＳ２７１７において、ルール削除プログラムは、Ｓ２７１６で取得した１以上のトポロジデータ１７００のそれぞれに対してステップＳ２７１８の繰り返し処理を実行する。【０２９１】
ステップＳ２７１８において、ルール削除プログラムは、処理対象のトポロジデータ１７００の関連展開ルールＩＤ１７１３に格納されている展開ルールＩＤを取得し、取得した展開ルールＩＤを持つ展開ルール１８００を展開ルールリポジトリ１３６から削除する。【０２９２】
Ｓ２７１６で取得したトポロジデータ１７００のそれぞれについて処理を終えた後、ルール削除プログラムは、ルール削除処理を終了する。【０２９３】
ステップＳ２７１９において、ルール削除プログラムは、ステップＳ２７１１において取得したコンポーネントＩＤのコンポーネントを含むトポロジを示す１以上のトポロジデータ１７００をトポロジリポジトリ１３７から取得する。【０２９４】
ステップＳ２７２０において、ルール削除プログラムは、Ｓ２７１９で取得した１以上のトポロジデータ１７００のそれぞれに対してステップＳ２７２１の繰り返し処理を実行する。【０２９５】
ステップＳ２７２１において、ルール削除プログラムは、処理対象のトポロジデータ１７００の関連展開ルールＩＤ１７１３に格納されている展開ルールＩＤを取得し、取得した展開ルールＩＤを持つ展開ルール１８００を展開ルールリポジトリ１３６から削除する。【０２９６】
Ｓ２７１９で取得したトポロジデータ１７００のそれぞれについて処理を終えた後、ルール削除プログラムは、ルール削除処理を終了する。【０２９７】
例えば、ステップＳ２７１１で変更イベントの種類を示すデータとして「ＣＨＡＮＧＥ」を、コンポーネントＩＤとして「ＤＲＩＶＥ１」をそれぞれ取得した場合、ルール削除プログラムは、ステップＳ２７１９において、トポロジリポジトリ１３７から論理ボリューム「ＶＯＬ１」とディスクドライブ「ＤＲＩＶＥ１」とを含むトポロジを示すトポロジデータ１７００を取得する。この取得されたトポロジデータ１７００の関連展開ルールＩＤには、「ＥｘｐａｎｄｅｄＲｕｌｅ２−１」が格納されている。したがって、ルール削除プログラムは、ステップＳ２７２１において、「ＥｘｐａｎｄｅｄＲｕｌｅ２−１」を展開ルールＩＤとする展開ルール１８００を展開ルールリポジトリ１３６から削除する。【０２９８】
メタルール生成処理および障害解析処理が実行されることによって、ルール作成者が指定した原因情報および影響情報から、単位関連に関する変更頻度に基づいて分割された複数のメタルール３００が生成され、生成された分割後のメタルール３００に基づいて、障害の原因解析が行われる。【０２９９】
例えば、ルール作成者が、イベント情報入力処理のステップＳ１９１２において、原因イベントとしてストレージのストレージディスクにおけるディスク使用率上昇エラーの障害イベントを入力し、影響イベントとしてサーバのディスクドライブに関する転送時間性能エラーの障害イベントと、ストレージの論理ボリュームに関するＩＯレスポンスタイム上昇エラーの障害イベントと、ストレージのストレージディスクに関するディスク使用率上昇エラーの障害イベントと、ストレージのストレージコントローラに関するＣＰＵ使用率上昇エラーの障害イベントの非検知とを入力した場合、管理コンピュータ１０１は、図３Ｂ、図３Ｃ、および図３Ｄに示すメタルール３００Ｂ、メタルール３００Ｃ、およびメタルールＤと、図１６Ｂ、図１６Ｃ、および図１６Ｄに示すトポロジ取得方式データ１６００Ｂ、トポロジ取得方式データ１６００Ｃ、およびトポロジ取得方式データ１６００Ｄとを生成する。そして、例えば、計算機システムにおいて、障害イベントテーブル１３１Ａのエントリ２１３が示す障害イベントが発生した場合、管理コンピュータ１０１は、メタルール３００Ｂ、メタルール３００Ｃ、およびメタルール３００Ｄ、並びに、トポロジ取得方式データ１６００Ｂ、トポロジ取得方式データ１６００Ｃ、およびトポロジ取得方式データ１６００Ｄに基づいて、図１８Ａ、図１８Ｂ、図１８Ｃに示す展開ルール１８００Ａ、展開ルール１８００Ｂ、および展開ルール１８００Ｃを生成する。そして、管理コンピュータ１０１は、ストレージＡのストレージディスク「ＤＩＳＫ１」に関するディスク使用率上昇エラーの障害イベントが原因候補であること、サーバＡのディスクドライブ「ＤＲＩＶＥ１」に関する転送時間性能エラーの障害イベントと、ストレージＡの論理ボリューム「ＶＯＬ１」に関するＩＯレスポンスタイム上昇エラーの障害イベントと、ストレージＡのストレージディスク「ＤＩＳＫ１」に関するディスク使用率上昇エラーの障害イベントとを影響範囲に含むこと、および、原因候補についての確信度は５０％であることを示す解析結果を運用管理者に提示する。【０３００】
また、例えば、管理コンピュータ１０１が、図２Ｂに示す変更イベントテーブル１３１Ｂのエントリ２６１が示す変更イベントを受信した場合、上記生成された展開ルール１８００のうち、図１８Ａに示す展開ルール１８００Ａのみが削除される。その後、障害イベントテーブル１３１Ａのエントリ２１３が示す障害イベントが発生した場合は、管理コンピュータ１０１は、展開ルール１８００を全て作成し直すのではなく、図１８Ｂおよび図１８Ｃに示す展開ルール１８００Ｂおよび展開ルール１８００Ｃを再利用することができる。【０３０１】
以上に説明したように、実施例１によれば、ルール作成者が１つの原因イベントと、１つ以上の影響イベントとを指定すると、管理コンピュータ１０１は、各影響イベントに関係する管理オブジェクトの種類を特定し、メタルール３００と、そのメタルール３００に基づいて展開ルール１８００を生成する際に利用されるトポロジ取得方式データ１７００とを自動的に生成する。その際、管理コンピュータ１０１は、ルール作成者の入力情報に基づいて生成したトポロジ取得方式データ１７００を分割し、分割後の複数のトポロジ取得方式データ１７００のそれぞれが示すトポロジ取得方式に対応する複数のメタルール３００（分割後のメタルール３００）を生成する。この分割は、単位関連に関する変更頻度に基づいて行われ、変更頻度の高い単位関連を含むメタルール３００が分離、独立される。すなわち、分割されたメタルール３００の１以上は、構成変更が頻発して変更されやすい単位関連によって構成されるトポロジ取得方式に対応するメタルール３００であり、それ以外のメタルール３００は、頻繁には変更されない単位関連によって構成されるトポロジ取得方式に対応するメタルール３００である。その結果、従来技術では、計算機システムの構成情報が変更された場合、分割前のメタルール３００全体について展開ルール１８００の再生成が行われていたのに対し、本実施例では、構成変更に関係するメタルール３００についてだけ展開ルール１８００を再生成すればよく、構成変更に関係しないメタルール３００については展開ルール１８００の再生成を免れる。これにより、構成変更に伴う展開ルール１８００の再生成に要する時間を削減できる。そして、本実施例では、単位関連に関する変更頻度に基づいて、変更頻度の高い単位関連によって構成されるトポロジ取得方式に対応するメタルール３００と、変更頻度の高くない単位関連によって構成されるトポロジ取得方式に対応するメタルール３００とに分割されるため、後者のメタルール３００については展開ルール１８００の再生成を免れる可能性が高く、再生成に要する時間の削減についてより高い効果を得ることができる。そして、原因解析の際に行われる展開ルール１８００の構築に要する時間が削減されることで、原因解析に要する時間が削減されることも期待できる。また、ルール作成者は、障害解析機能の内部仕様や管理オブジェクトごとの構成変更の頻度を知ることなく、構成変更に伴う展開ルール１８００の再生成を行う可能性が低いメタルール３００を生成することができる。したがって、ルール作成者のメタルール３００作成の際の作業負担を軽減することもできる。【０３０２】
実施例１における分割前のメタルール３００は、物理サーバ上の論理ディスク〜ストレージ上のボリューム〜ストレージの物理コンポーネント（コントローラ、ＲＡＩＤグループ等）からなる。このメタルール３００のうち、論理ディスク〜ボリューム間の関連においては、例えば論理ディスクを利用する仮想サーバの物理サーバ間移行により、構成変更が頻発しうる。一方、ボリューム〜物理コンポーネント間の関連においては、一度生成したボリュームに関しては構成変更がほとんど発生しない。本実施例ではこの点を反映し、変更されやすい単位関連を含むメタルール３００として図３Ｂに示すメタルール３００Ｂが、変更されやすい単位関連を含まないメタルール３００として図３Ｃに示すメタルール３００Ｃおよび図３Ｄに示すメタルール３００Ｄが自動的に生成される。【０３０３】
なお、管理コンピュータ１０１は、メタルールリポジトリ１３５に記憶されている既存のメタルール３００を分割してもよい。管理コンピュータ１０１は、分割対象のメタルール３００に対応するトポロジ取得方式データ１７００を、本実施例で示した方法により、単位関連に関する変更頻度に基づいて複数のトポロジ取得方式データ１７００に分割し、分割後のトポロジ取得方式データ１７００に対応するメタルール３００を生成することにより、既存のメタルール３００を、変更頻度の高い単位関連によって構成されるトポロジ取得方式に対応するメタルール３００と、変更頻度の高くない単位関連によって構成されるトポロジ取得方式に対応するメタルール３００とに分割できる。【０３０４】
また、本実施例では、管理コンピュータ１０１は、ルール作成者の入力情報に基づいて直接分割後のメタルール３００を生成しているが、まず入力情報に対応する分割前のメタルール３００を生成し、その後、分割前のメタルール３００を、複数のメタルール３００に分割するようにしてもよい。
【実施例２】
【０３０５】
実施例１では、ルール作成者がメタルール３００を入力した際、単位関連ごとに管理されている変更頻度に基づいて、入力情報に基づくトポロジ取得方式を分割し、分割後のトポロジ取得方式のそれぞれに対応する複数のメタルール３００、すなわち分割後のメタルール３００を生成する。実施例２では、単位関連ごとに管理されている変更頻度が変化した際に、既存のメタルール３００を意味論的に等しい複数のメタルール３００に分割する。これにより、ルール作成者が入力した際には、構成変更の頻度情報がまだ十分蓄積されていなかった場合でも、その後の構成変更の頻度情報のアップデートに従ってメタルール３００が適切に分割される。【０３０６】
具体的には、障害解析プログラム１２３が変更イベントを受信し、関連テーブル１３３の或る単位関連に関する変更頻度が更新された場合において、その更新後の変更頻度が分割閾値を超過するようになった場合に、管理コンピュータ１０１は、その単位関連を含むトポロジ取得方式に対応するメタルール３００を、更新後の変更頻度に基づいて分割する。【０３０７】
実施例２において、計算機システムの構成、各装置の構成および各プログラムが実行する処理のうち、実施例１と同じものについては説明を省略する。実施例２に係る計算機システムの構成は、実施例１に係る計算機システムの構成（図１Ａおよび図１Ｂ）と実質的に同じである。【０３０８】
＜メタルール再構築処理＞【０３０９】
図２８は、実施例２に係る障害解析処理の一例のフローチャートである。【０３１０】
ステップＳ２８１１において、障害解析プログラム１２３は、未処理の変更イベントを示すエントリを変更イベントテーブル１３１Ｂから取得する。例えば、障害解析プログラム１２３は、変更イベントテーブル１３１Ｂの処理済みフラグ２５６が「Ｎｏ」の変更イベントのうちの発生日時が最も古い変更イベントを示すエントリを取得する。【０３１１】
ステップＳ２８１２において、障害解析プログラム１２３は、未処理の変更イベントを取得できたかどうか（未処理の変更イベントを示すエントリを取得できたかどうか）を判定する。取得できた場合（ステップＳ２８１２：ＹＥＳ）、障害解析プログラム１２３は、処理をステップＳ２８１３に進める。未処理の変更イベントが取得できなかった場合（ステップＳ２８１２：ＮＯ）の処理は、実施例１の障害解析処理のステップＳ２５１６以降の処理（図２５Ｂ）と実質的に同じである。なお、障害解析処理のステップＳ２５１９で実行されるルール展開処理（図２６Ａおよび図２６Ｂ）のステップＳ２６１２において、原因解析に利用される展開ルール１８００の基となるメタルール３００が取得されるが、後述するメタルール再構築処理（図２９参照）において分割されたメタルール３００（分割前のメタルール３００）は、それがメタルールリポジトリ１３５内に残っていたとしても選択されない。すなわち、実施例２において、管理コンピュータ１０１は、分割前のメタルール３００の代わりに分割後のメタルール３００を利用して原因解析を行う。【０３１２】
ステップＳ２８１３において、障害解析プログラム１２３は、ステップＳ２８１１で取得した変更イベント（ステップＳ２８１１で取得したエントリが示す変更イベント）を処理済みの変更イベントとして登録する。具体的には、障害解析プログラム１２３は、変更イベントテーブル１３１Ｂの処理済みフラグ２５６を「Ｎｏ」から「Ｙｅｓ」に変更する。【０３１３】
ステップＳ２８１４において、障害解析プログラム１２３は、ステップＳ２８１１で取得した変更イベントの識別情報を入力として、ルール削除処理を実行する。このルール削除処理は、実施例１に係るルール削除処理（図２７）と実質的に同じである。【０３１４】
ステップＳ２８１５において、障害解析プログラム１２３は、変更イベントテーブル１３１Ｂにおける、ステップＳ２８１１で取得した変更イベントを示すエントリのコンポーネントＩＤ２５３に格納されているコンポーネントＩＤを取得する。そして、障害解析プログラム１２３は、関連テーブル１３３において、取得したコンポーネントＩＤに対応するコンポーネントの種類を示すデータがテーブル名Ｘ１５０２またはテーブル名Ｙ１５０４に格納されているエントリを取得する。そして、障害解析プログラム１２３は、取得したエントリが示す単位関連における通算変更回数および当該単位関連に関する変更頻度を更新する。【０３１５】
なお、ステップＳ２８１５において、変更イベントテーブル１３１Ｂにおける、ステップＳ２８１１で取得した変更イベントを示すエントリのコンポーネントＩＤ２５３に「ＮＵＬＬ」が格納されている場合は、障害解析プログラム１２３は、当該エントリの装置ＩＤ２５２に格納されている装置ＩＤを取得する。そして、障害解析プログラム１２３は、関連テーブル１３３において、取得した装置ＩＤに対応する管理対象装置の種類を示すデータがテーブル名Ｘ１５０２またはテーブル名Ｙ１５０４に格納されているエントリを取得する。そして、障害解析プログラム１２３は、取得したエントリが示す単位関連における通算変更回数および当該単位関連に関する変更頻度を更新する。【０３１６】
ステップＳ２８１６において、障害解析プログラム１２３は、ステップＳ２８１５で更新した単位関連（以下「更新単位関連」と称する）（第１の関連）に関する更新前の変更頻度が分割閾値を超過しておらず、かつ更新単位関連に関する更新後の変更頻度が分割閾値を超過したか否かを判定する。条件を満たす場合、すなわち更新単位関連に関する更新前の変更頻度が分割閾値を超過しておらず、かつ更新単位関連に関する更新後の変更頻度が分割閾値を超過した場合（ステップＳ２８１６：ＹＥＳ）、障害解析プログラム１２３は、処理をステップＳ２８１７へ進める。一方、条件を満たさない場合、すなわち更新単位関連に関する更新前の変更頻度が分割閾値を超過している場合、または更新単位関連に関する更新後の変更頻度が分割閾値を超過していない場合（ステップＳ２８１６：ＮＯ）、障害解析プログラム１２３は、障害解析処理を終了する。【０３１７】
ステップＳ２８１７において、障害解析プログラム１２３は、ステップＳ２８１５で更新した単位関連の関連ＩＤを入力として、メタルール生成プログラム１２１にメタルール再構築処理を実行させる。その後、障害解析プログラム１２３は、障害解析処理を終了する。【０３１８】
図２９は、実施例２に係るメタルール再構築処理の一例のフローチャートである。【０３１９】
ステップＳ２９１１において、メタルール生成プログラム１２１は、メタルール再構築処理の対象となる単位関連の関連ＩＤを受信する。【０３２０】
ステップＳ２９１２において、メタルール生成プログラム１２１は、ステップＳ２９１１において受信した関連ＩＤを持つ単位関連に関する情報を含む１以上のトポロジ取得方式データ１６００をトポロジ取得方法リポジトリ１３４から取得し、取得したトポロジ取得方式データ１６００を展開時に用いる１以上のメタルール３００をメタルールリポジトリ１３５から取得する。【０３２１】
ステップＳ２９１３において、メタルール生成プログラム１２１は、ステップＳ２９１２で取得した１以上のメタルール３００のそれぞれに対して、ステップＳ２９１４〜ステップＳ２９１９の処理を繰り返す。【０３２２】
ステップＳ２９１４において、メタルール生成プログラム１２１は、処理対象のメタルール３００の原因イベントを示す情報を原因情報とし、処理対象のメタルール３００の影響イベントを示す情報を影響情報とし、処理対象のメタルール３００の影響イベントと当該影響イベントに対応するトポロジ取得方式を示すトポロジ取得方式データ１６００との対応関係を示すデータを対応関係データとし、原因情報、影響情報、および対応関係データを入力として、トポロジ取得方式分割処理を実行し、分割後のメタルール３００を示す情報、例えばメタルールＩＤを受信する。このトポロジ取得方式分割処理は、実施例１に係るトポロジ取得方式分割処理（図２３）と実質的に同じである。このトポロジ取得方式分割処理により、処理対象のメタルール３００（既存のメタルール３００）が、単位関連に関する変更頻度に基づいて、処理対象のメタルール３００と意味論的に等しい複数のメタルール３００に分割される。【０３２３】
ステップＳ２９１５において、メタルール生成プログラム１２１は、処理対象のメタルール３００、すなわち分割前のメタルール３００と、ステップＳ２９１４において生成された分割後のメタルール３００と、トポロジ取得方式とを画面に表示してルール作成者に提示し、ステップＳ２９１６において、メタルール３００を分割して再構築することの指示または再構築しないことの指示をルール作成者から受信する。【０３２４】
ステップＳ２９１７において、メタルール生成プログラム１２１は、メタルール３００を分割して再構築することの指示を受信したか否かを判定する。条件を満たす場合、すなわち再構築することの指示を受信した場合（ステップＳ２９１７：ＹＥＳ）、メタルール生成プログラム１２１は、処理をステップＳ２９１８へ進める。一方、条件を満たさない場合、すなわち再構築しないことの指示を受信した場合（ステップＳ２９１７：ＮＯ）、メタルール生成プログラム１２１は、未だ処理されていないメタルール３００についてステップＳ２９１４〜ステップＳ２９１９の処理を行う。【０３２５】
ステップＳ２９１８において、メタルール生成プログラム１２１は、ステップＳ２９１４で生成された分割後のメタルール３００をメタルールリポジトリ１３５に登録する。【０３２６】
ステップＳ２９１２で取得したメタルール３００のそれぞれについてステップＳ２９１４〜ステップＳ２９１９の処理を終えた後、メタルール生成プログラム１２１は、メタルール再構築処理を終了する。【０３２７】
以上に説明したように、実施例２によれば、障害解析プログラム１２３が変更イベントを受信し、関連テーブル１３３の或る単位関連に関する変更頻度が更新された場合において、その更新後の変更頻度が分割閾値を超過するようになった場合、管理コンピュータ１０１は、その単位関連を含むトポロジ取得方式に対応するメタルール３００を、更新後の変更頻度に基づいて分割する。これにより、ルール作成者が入力した際には、構成変更の頻度情報がまだ十分蓄積されていなかった場合でも、その後の構成変更の頻度情報のアップデートに従ってメタルール３００が適切に分割される。【０３２８】
なお、本発明は、以上説明した実施例に限定されるものでなく、その趣旨を逸脱しない範囲で種々変更可能であることはいうまでもない。
【符号の説明】
【０３２９】
１０１：管理コンピュータ、１０２：サーバ、１０３：ＩＰスイッチ、１０４：ストレージ、１０５：ＦＣスイッチ
【図１Ａ】
0005946583.tif 000002
【図１Ｂ】
0005946583.tif 000003
【図２Ａ】
0005946583.tif 000004
【図２Ｂ】
0005946583.tif 000005
【図３Ａ】
0005946583.tif 000006
【図３Ｂ】
0005946583.tif 000007
【図３Ｃ】
0005946583.tif 000008
【図３Ｄ】
0005946583.tif 000009
【図４】
0005946583.tif 000010
【図５】
0005946583.tif 000011
【図６】
0005946583.tif 000012
【図７】
0005946583.tif 000013
【図８】
0005946583.tif 000014
【図９】
0005946583.tif 000015
【図１０】
0005946583.tif 000016
【図１１】
0005946583.tif 000017
【図１２】
0005946583.tif 000018
【図１３】
0005946583.tif 000019
【図１４】
0005946583.tif 000020
【図１５】
0005946583.tif 000021
【図１６Ａ】
0005946583.tif 000022
【図１６Ｂ】
0005946583.tif 000023
【図１６Ｃ】
0005946583.tif 000024
【図１６Ｄ】
0005946583.tif 000025
【図１６Ｅ】
0005946583.tif 000026
【図１７Ａ】
0005946583.tif 000027
【図１７Ｂ】
0005946583.tif 000028
【図１７Ｃ】
0005946583.tif 000029
【図１８Ａ】
0005946583.tif 000030
【図１８Ｂ】
0005946583.tif 000031
【図１８Ｃ】
0005946583.tif 000032
【図１９】
0005946583.tif 000033
【図２０】
0005946583.tif 000034
【図２１】
0005946583.tif 000035
【図２２】
0005946583.tif 000036
【図２３】
0005946583.tif 000037
【図２４】
0005946583.tif 000038
【図２５Ａ】
0005946583.tif 000039
【図２５Ｂ】
0005946583.tif 000040
【図２６Ａ】
0005946583.tif 000041
【図２６Ｂ】
0005946583.tif 000042
【図２７】
0005946583.tif 000043
【図２８】
0005946583.tif 000044
【図２９】
0005946583.tif 000045