以下の本発明の詳細な説明において、開示の一部をなす添付図面を参照するが、これらは本発明を実施できる例示的な実施形態を示すものであって、本発明の範囲を限定するものではない。これらの図面において、複数の図を通じて同一の符号は同一の構成要素を示す。さらに、詳細な説明は各種の例示的な実施形態を提供するが、以下に記述および図示するように、本発明は本明細書に記述および図示する実施形態に限定されるものではなく、当業者には公知または将来公知となる他の実施形態に拡張できる点に注意されたい。
本明細書において「一実施形態」または「本実施形態」または「本実施例」に言及する場合、当該実施形態との関連で記述されている特定の特徴、構造または特性は、本発明の少なくとも一つの実施形態に含まれることを意味しており、本明細書の各所でこれらの語句が出現しても、必ずしも全て同一の実施形態を指している訳ではない。
また、以下の詳細な説明において、本発明が完全に理解されるよう多くの具体的な詳細事項を開示している。しかし、当業者には明らかなように、本発明を実施するために、これらの具体的な詳細事項の全てが必要とされるものではない。他の状況において、本発明を無用に分かり難くしないよう、公知の構造、材料、回路、処理およびインターフェースについては詳細に記述せず、および/またはブロック図の形式で示す場合がある。
さらに、以下に詳細な説明のある部分は、コンピュータ内部の動作のアルゴリズム的記述または記号的表現として示す。これらのアルゴリズム的記述および記号的表現は、データ処理技術に精通した当業者が自身の発明の本質を他の当業者に最も効果的に伝達するために用いる手段である。アルゴリズムとは、所望の最終状態または結果に達する一連の定義されたステップである。本発明において、実行されるステップは、有形の結果を実現するための有形の量を物理的に操作することを要求する。
但し、通常は必須ではないが、これらの量は、保存、転送、結合、比較、および他の操作が可能な電気または磁気の信号の形式をなす。原理的に共通に利用できるとの理由で、これらの信号をビット、値、要素、記号、文字、項目、数、命令等と称することが往々にして便利であることが分かっている。しかし、これらの全ておよび同様の項目は、適切な物理量に関連付けられるべきものであり、これら物理量に付けられた便宜的なラベルに過ぎないことに留意すべきである。
特に別途明言しない限り、以下の記述から明らかなように、本明細書の記述を通じて、「処理する」、「計算する」、「算出する」、「判定する」、「表示する」等の用語を用いた説明は、コンピュータシステムまたは当該コンピュータシステムのレジスタおよびメモリ内の物理的(電子的)な量として表現されたデータを操作して、当該コンピュータシステムのメモリまたはレジスタまたは他の情報記憶、伝送または表示装置内の物理量として同様に表現された他のデータに変換する他の情報処理装置の動作および処理を含んでいてよい。
また、本発明は本明細書における動作を実行する装置に関する。この装置は、必要な目的のために特別に構築されてもよいし、または、一つ以上のコンピュータプログラムにより選択的に起動または再設定される一つ以上の汎用コンピュータを含んでもよい。そのようなコンピュータプログラムは、例えば、光ディスク、磁気ディスク、読出専用メモリ、ランダムアクセスメモリ、固体装置(solid-state device)およびドライブ等のコンピュータ可読記憶媒体、または電子情報の保存に適している他の任意の媒体に保存できるが、これらに限定されない。
なお、以後の説明では「aaaテーブル」、「aaaリスト」、「aaaDB」、「aaaキュー」等の表現にて本発明の情報を説明するが、これら情報は、必ずしもテーブル、リスト、DB、キュー、等のデータ構造以外で表現されていてもよい。そのため、データ構造に依存しないことを示すために「aaaテーブル」、「aaaリスト」、「aaaDB」、「aaaキュー」等について「aaa情報」と呼ぶことがある。
以後の説明では「プログラム」を主語として説明を行う場合があるが、プログラムはプロセッサによって実行されることで定められた処理をメモリおよび通信ポート(通信制御デバイス)を用いながら行うため、プロセッサを主語とした説明としてもよい。また、プログラムを主語として開示された処理は管理サーバ等の計算機、情報処理装置が行う処理としてもよい。また、プログラムの一部または全ては専用ハードウェアによって実現されてもよい。
また、各種プログラムはプログラム配布サーバや、計算機が読み取り可能な記憶メディア(computer-readable memory mediaと翻訳させたいです)によって各計算機にインストールされてもよい。
なお、管理計算機は入出力デバイスを有する。入出力デバイスの例としてはディスプレイとキーボードとポインタデバイスが考えられるが、これ以外のデバイスであってもよい。また、入出力デバイスの代替としてシリアルインターフェースやイーサーネットインターフェースを入出力デバイスとし、当該インターフェースにディスプレイまたはキーボードまたはポインタデバイスを有する表示用計算機を接続し、表示用情報を表示用計算機に送信したり、入力用情報を表示用計算機から受信することで、表示用計算機で表示を行ったり、入力を受け付けることで入出力デバイスでの入力および表示を代替してもよい。
以後、情報処理システムを管理し、本願発明の表示用情報を表示する一つ以上の計算機の集合を管理システムと呼ぶことがある。管理計算機が表示用情報を表示する場合は管理計算機が管理システムである、また、管理計算機と表示用計算機の組み合わせも管理システムである。また、管理処理の高速化や高信頼化のために複数の計算機で管理計算機と同等の処理を実現してもよく、この場合は当該複数の計算機(表示を表示用計算機が行う場合は表示用計算機も含め)が管理システムである。
本明細書に示すアルゴリズムおよびディスプレイは、いかなる特定のコンピュータまたは他の装置にも本質的には関係しない。各種の汎用システムを、本明細書の開示によるプログラムおよびモジュールと共に用いてもよいが、所望の方法のステップを実行するための、より特化した装置を構築した方が便利な場合がある。これら各種のシステムの構造は以下に開示する説明で明らかになる。また、本明細書では、本発明をいかなる特定のプログラミング言語も前提としては記述していない。以下に記述するように、本発明の開示を実行するために各種のプログラミング言語を用いてもよいことが理解されよう。プログラミング言語の命令は、一つ以上の処理装置、例えば中央処理装置(CPU)、プロセッサ、またはコントローラによって実行できる。
例示的な実施形態によれば、管理コンピュータは複数の管理対象装置を管理するコンピュータである。管理対象装置の種別としては、例えば、サーバを含むコンピュータ、IPスイッチ、ルータ、FC(ファイバチャネル)スイッチ等のネットワーク装置、およびNAS、ストレージ装置等がある。なお、管理対象装置が含むデバイス等の論理的または物理的な構成をコンポーネントと称する。コンポーネントの例としてはポート、プロセッサ、記憶資源、記憶デバイス、プログラム、仮想マシン、ストレージ装置内部で定義される論理ボリューム、RAIDグループ等がある。なお、管理対象装置とコンポーネントとを区別せずに扱う場合は管理オブジェクトと称する。
また、管理コンピュータは管理オブジェクトの障害発生を示すイベントを検知すると、そのイベントの組み合せから障害を解析して原因を特定する解析エンジン、および障害を解析するうえで必要となるルールの作成を支援するルール作成エンジンを有する。
解析エンジンは、管理対象装置の構成情報を持つ構成管理DBにアクセスして、I/O(入出力)経路上のパス上にある一つまたは複数の管理対象装置に跨る複数のコンポーネント間の関係を、「トポロジ」と称される一つのグループとして認識する。また、障害が解析される前に予め用意される障害解析用のルールは、メタルールと称され、あるパターンのトポロジにおいて発生し得るイベントの組み合わせと、それらのイベントが発生した場合に障害の原因候補となるイベントとの対応関係が、例えばIF−THEN形式で記述される。解析エンジンは、ある管理オブジェクトにおける障害イベントを検知すると、検知した障害に関連するメタルール、および障害が発生した管理オブジェクトを含むトポロジの情報を構成管理DBから取得し、メタルールに記述されたイベントの組み合わせ、および原因イベントと、当該トポロジから、発生した障害の原因候補を特定し、システムの運用管理者に通知する。
ルール作成エンジンは、メタルールの作成を支援する機能を有する。システム障害に関する知識を有するルール作成者が、ある障害の原因イベントおよび原因イベントによって連鎖的に引き起こされる影響イベントを入力すると、管理コンピュータの構成管理DBのデータモデルに基づいて、原因イベントが発生したコンポーネントと影響イベントが発生したコンポーネントとの間のトポロジのパターンを導出する。そして、導出されたパターンのトポロジを構成管理DBから検索および取得する手段を作成し、入力された原因イベントおよび影響イベントを合わせてメタルールを生成する。
したがって、本発明の例示的な実施形態において、原因イベントおよび影響イベントを入力すると、ルール作成エンジンはメタルールを生成し、メタルールの適用先となるトポロジの情報を構成管理DBから取得する手段も合わせて生成する。このため、ルール作成者は管理コンピュータの構成管理DBのデータモデルを含めた内部構造を学習することなくメタルールを作成することができ、また、解析エンジンは作成されたメタルールに基づいて、自動的に障害の原因を特定することができる。
<管理コンピュータのハードウェアおよび論理構成>
図1Aおよび図1Bは、本発明の第1の実施例の情報システムのハードウェアアーキテクチャおよび論理構成の例を示すブロック図である。
図に示すシステムは、管理コンピュータ101、一つ以上のサーバ(または、他のコンピュータ)102Aおよび102B、一つ以上のFC(ファイバチャネル)スイッチ(または、他のネットワーク装置)105、一つ以上のストレージ104Aおよび104B、および、一つ以上のIPスイッチ(または、他のネットワーク装置)103を有する。
管理コンピュータ101、サーバ102A、102BおよびFCスイッチ105は、LAN(ローカルエリアネットワーク)106等のネットワークを介して通信可能に接続される。ストレージ104A、104Bは、SAN(ストレージエリアネットワーク)107等のネットワークを介してサーバ102A、102Bと通信可能に接続される。
管理コンピュータ101は、CPU111、メモリ112、ハードディスクドライブ(HDD)113等の記憶媒体、入力デバイス114、出力デバイス117、およびネットワークインターフェース(I/F)115を含み、これらのデバイスがシステムバス116を介して接続される汎用コンピュータでよい。管理コンピュータ101の論理モジュールは、メタルール生成プログラム121、イベント受信プログラム122、障害解析プログラム123、構成情報取得プログラム124および表示モジュール125を含む。また、管理コンピュータ101は、データとして、イベントテーブル131、構成管理DB132、関連テーブル133、トポロジ取得方式リポジトリ134、メタルールリポジトリ135および展開ルールリポジトリ136を有する。
メタルール生成プログラム121、イベント受信プログラム122、障害解析プログラム123、構成情報取得プログラム124および表示モジュール125は、メモリ112または他の計算機可読媒体に保存され、CPU111が実行する。以下に記述するイベントテーブル131、構成管理データベース132、関連テーブル133、トポロジ取得方式リポジトリ134、メタルールリポジトリ135および展開ルールリポジトリ136などのデータは、ディスク113または他の適当な計算機可読媒体に保存されていてよい。
ネットワークインターフェース115は、LAN106を介して接続されるサーバ102、IPスイッチ103、ストレージ104およびFCスイッチ105等の、管理対象である動作ノードからイベント情報を取得する。出力デバイス117は、表示モジュール125からの情報を運用管理者に提示するために用いられる。入力デバイス114は、運用管理者の指示を入力するために用いられる。例えば、入力デバイス114としてキーボード、ポインタデバイス等を用いることができ、出力デバイス117としてディスプレイ、プリンタ等を用いることができるが、これら以外の装置でもよい。また、入力デバイス114および出力デバイス117の代わりに、シリアルインターフェースやイーサーネットインターフェースを用いてもよい。この場合、当該インターフェースにディスプレイ、キーボード、ポインタデバイス等を有する表示用計算機を接続し、表示用情報を表示用計算機に送信し、入力用情報を表示用計算機から受信することによって、表示用計算機において表示を行い、また、表示用計算機から入力を受け付けることによって、入力デバイス114および出力デバイス117の機能を代替してもよい。
各サーバ102A、102Bは、当技術分野で公知であるように、アプリケーション等を実行している管理対象ノードでよい。サーバ102Aは、CPU146、メモリ(ストレージを含んでもよい)147、およびネットワークインターフェース144を含む汎用コンピュータでよい。サーバ102Aは、サーバ102Aの状態を監視し、特定の状態変化が検出された場合にLAN106を介して管理コンピュータ101にイベント情報を送る監視エージェント141を含んでもよい。例示する実施例において、各サーバ102Aは、SAN107に接続するためのHBA(ホストバスアダプタ)142を有する。例えば、サーバ102Aは、ディスクドライブ151Aを仮想的にローカルHDDのように利用できる。このディスクドライブ151Aは、HBA142およびストレージ104A、104Bの記憶領域によって実現できる。さらに、代替的な実施例において、SCSIの代わりに、またはこれに加えて、他の通信およびストレージプロトコルを用いてもよい。
なお、サーバ102Aの構成を説明したが、サーバ102Bも同じ構成を有してよい。
ストレージ104A、104Bは、当該技術分野で公知であるように、サーバ102上で動作するアプリケーションが使用する記憶容量を提供するため、または他の目的のための管理対象ノードでよい。ストレージ104Aは、ストレージコントローラ161、SAN107に接続するためのI/Oポート163、LAN106に接続するためのネットワークインターフェース167、およびRAIDグループ164A、164Bを有し、これらのデバイスが内部バス等を介して接続されている。なお、RAIDグループ164の接続とは、より正確にはRAIDグループ164を構成する記憶媒体162A〜162Dが他のデバイスと接続されていることである。
記憶媒体162A〜162Dは、本実施例ではハードディスクドライブでもよいが、固体記憶媒体(SSD)、光記憶媒体等、他の種類の記憶媒体でもよい。RAIDグループ164A、164Bは、それぞれ、一つまたは複数の記憶媒体162A等で構成されている。なお、RAIDグループ164A、164Bが、複数の記憶媒体162A等によって構成されている場合、それらの記憶媒体162A等はRAIDを構成してもよい。また、RAIDグループ164は、論理的に複数のボリューム(LUN)165A等を構成している。
本実施例において、ストレージ104Aは、サーバ102A、102Bに対し、記憶容量として論理ボリュームを提供するように構成される。したがって、例示する実施例において、2台のサーバ102A、102BがFCスイッチ105を介してストレージ104Aに接続されており、ストレージ104Aが各サーバ102A、102Bに論理ボリュームを提供する。また、ストレージ104Aは、ストレージ104Aの状態を監視し、特定の状態変化が検出された場合にLAN106を介して管理コンピュータ101にイベント情報を送る監視エージェント166を含んでもよい。あるいは、サーバ102Aの監視エージェント141が、ストレージ104Aの状態を監視してもよい。
なお、ストレージ104Aの構成を説明したが、ストレージ104Bも同じ構成を有してよい。
FCスイッチ105は、当該技術分野で公知であるように、サーバ102A、102Bおよびストレージ104A、104Bを接続するSAN107を構成するための、または他の目的のための管理対象ノードであってよい。これによって、ストレージ104A、104Bの論理ボリュームを記憶領域としてサーバ102A、102Bに提供される。
FCスイッチ105はサーバ102またはストレージ104から送信されるデータを受信し、かつ、受信したデータを送信するポート171A〜171Dを有する。また、FCスイッチ105は、LAN106に接続するためのネットワークインターフェース173を含んでいてよい。さらに、FCスイッチ105は、FCスイッチ105の状態を監視し、特定の状態変化が検出された場合にLAN106を介して管理コンピュータ101にイベント情報を送る監視エージェント172を含んでもよい。あるいは、サーバ102Aの監視エージェント141が、FCスイッチ105の状態を監視してもよい。
<イベントテーブル>
図2は、本実施例のイベントテーブル131のデータ構造の例を説明する図である。イベントテーブル131は、イベント受信プログラム122が管理対象装置の監視エージェントから受信したイベント情報を格納する。
イベントテーブル131は、五つのフィールド、すなわち、イベントID201、装置ID202、コンポーネントID203、イベント種別204および発生日時205を含む。イベントID201は、各イベント情報を一意に識別するための識別情報である。装置ID202は、管理対象装置を一意に識別するための識別情報である。コンポーネントID203は、管理対象コンポーネントを一意に識別するための識別情報である。イベント種別204は、管理オブジェクトで生起したイベントの種別である。発生日時205は、イベントが生起した時刻である。発生日時は、管理コンピュータ101がイベント情報を受信した時刻でもよい。イベントが、コンポーネントに関するイベントではなく、装置そのものに関するイベントである場合、コンポーネントID203の値は「NULL」でもよい。
例えば、図2のエントリ211は、装置IDがStAであるストレージ104A内のコンポーネントIDがRG1であるRAIDグループ164において「WriteHitPerfError」(書込処理のヒット率性能エラー)が2012年7月7日15時0分0秒に発生したことを意味する。
<メタルールリポジトリおよびメタルール>
メタルールは、あるパターンのトポロジにおいて発生し得るイベントの組み合わせと、それらのイベントが同じタイミングで発生した場合に障害の原因候補となるイベントとの対応関係を示す情報である。本実施例において、メタルールはIF−THEN形式で記述されるが、システム障害の原因事象および原因事象によって引き起こされる観測事象が記述されていれば、他の形式でもよい。
図3は、本実施例のメタルールリポジトリ135に常駐するメタルール300の例を説明する図である。
一般に、メタルールは二つの部分、すなわちIF部311と称される第1の部分と、THEN部312と称される第2の部分とに分けることができる。IF部311は一つ以上の条件要素を含んでもよい。
メタルール300は、IF部311のイベント(条件イベント)が検知された場合、THEN部312のイベント(結論イベント)が障害の原因となることを示す。したがって、THEN部312のステータスが正常になれば、IF部311の問題も解決することが見込まれる。
本実施例においては、図2のイベントテーブル131に格納されるイベント情報を観測事象とし、障害を解析するため、メタルール300のIF部311の各条件要素には「装置種別」、「コンポーネント種別」および「イベント種別」が記述される。すなわち、管理対象装置およびコンポーネントは、管理コンピュータ101において、いくつかの種別に分類されており、IF部311の条件要素は指定した種別の管理オブジェクトにおいて指定したイベント種別の状態が発生することを示す。イベントが、コンポーネントに関するイベントではなく、装置そのものに関するイベントである場合、「コンポーネント種別」の値は「NULL」でもよい。
また、メタルール300は、各メタルールを一意に識別するメタルールID313を含むフィールド313を含む。また、メタルール300は、メタルール300を実際の管理対象システムの構成に適用して、展開ルールを生成する際に、メタルール300を適用するトポロジの情報を取得する手段(トポロジ取得方式)の識別子を格納するためのフィールド314を含む。なお、複数のメタルール300が、同じトポロジ取得方式のIDをフィールド314に格納してもよい。
例えば、図3のメタルール(メタルールID=「MetaRule1」)は、観測事象として「サーバ102Aなど上のディスクドライブ151Aの転送時間性能エラー」と、「ストレージ104A等におけるRAIDグループ164の書込処理のキャッシュヒット率性能低下エラー」とが検知された場合、「ストレージ104A等におけるRAIDグループ164の書込処理の「ヒット率性能低下エラー」が原因であると結論付けられることを示す。
また、メタルールID=「MetaRule1」のメタルールについて展開ルールを生成する場合、トポロジ取得方式IDフィールド314で指定しているトポロジ取得方式をトポロジ取得方式リポジトリ134から取得し、メタルールから展開ルールを生成するのに必要なトポロジ情報を、取得した方式を用いて構成管理DB等から取得する。なお、IF部311に含まれる条件要素として、ある管理オブジェクトが正常であること(障害イベントが発生していないこと)を定義してもよい。また、THEN部312のイベント種別は、新たに定義してもよく、イベント受信プログラム122が受信するイベントのイベント種別でなくてもよい。
<構成管理DB>
構成管理DB132は、構成情報取得プログラム124が監視エージェント等から取得した管理対象装置の構成情報を格納する。構成情報は、管理対象装置およびコンポーネントのI/O(入出力)の関係、接続関係、依存関係などを示す関連情報も含む。すなわち、トポロジはこれら関連の組み合わせによって表現することができる。
図1のサーバ102、FCスイッチ105、ストレージ104について、構成管理DB132が格納する構成情報の例を図4〜図13を用いて説明する。また、図14は、図1に示す各管理オブジェクトの関連を、管理オブジェクトの種別ごとに表現したクラス図である。
本実施例においては、図14のクラス図に合わせ、管理オブジェクトの種別ごとに、構成管理DB132内にテーブルを作る。そのため、各テーブル名は管理オブジェクト種別名を示し、各テーブルの一つのエントリは一つの管理オブジェクトを示す。ただし、管理オブジェクトの種別ごとに構成管理DBのテーブルが構成される必要はなく、各エントリに対して、管理オブジェクトの種別を示す情報が登録されてもよい。また、一つの管理オブジェクトの情報が複数のエントリに登録されてもよい。
また、本実施例においては、管理オブジェクト間の関連を、各テーブルのフィールドの値を等しくすることによって表現しているが、管理オブジェクトの情報とは別に関連の情報を記録したテーブルを別に用意してもよい。
なお、構成管理DB132の一部のテーブルおよび/またはテーブル中の一部の項目のみを格納してもよい。また、構成管理DBが格納する各項目のデータ表現形式およびデータ構造は、管理対象装置が持つデータの表現形式およびデータ構造と異なってもよい。また、管理コンピュータ101が管理対象装置から受信するデータは、管理対象装置のデータ構造およびデータ表現形式でもよい。
また、管理対象装置の構成の変更にしたがって、構成管理DB132のテーブルの情報が更新されてもよい。構成管理DBのテーブルの情報が更新された場合、更新前の情報も記録しておき、履歴情報によって過去の構成情報を参照できるようにしてもよい。
図4は、本実施例の構成管理DB132に含まれるテーブルのうち、管理オブジェクトの種別がサーバである装置の構成情報を示すテーブルを説明する図である。
サーバテーブル400は、二つのフィールド、すなわち、装置ID401およびホスト名402を含む。装置ID401は、管理対象装置を一意に識別するための識別情報である。ホスト名402は、運用管理者がサーバ102を一意に識別するための識別情報である。
特に、図4のサーバテーブル400は、2012年1月1日から2012年12月31日までの管理対象のサーバ102A、102Bの構成情報を示す。構成管理DB132のテーブルは、その情報が更新される毎にその変更日時および変更内容を記録する。または、定期的に各テーブルのスナップショットを取得する等によって、任意の期間の構成情報を示すテーブルを取得してもよい。以降に述べる構成管理DB132の各テーブルは、同様に任意の期間の構成情報を示すテーブルでよい。
図5は、本実施例の構成管理DB132に含まれるテーブルのうち、管理オブジェクトの種別がFCスイッチである装置の構成情報を示すテーブルを説明する図である。
FCスイッチテーブル500は、三つのフィールド、すなわち、装置ID501、スイッチ名502およびポート数503を含む。装置ID501は、管理対象装置を一意に識別するための識別情報である。スイッチ名502は、運用管理者がFCスイッチ105を一意に識別するための名称である。ポート数503は、FCスイッチ105が持つポート数である。
特に、図5のFCスイッチテーブル500は、2012年1月1日から2012年12月31日までの管理対象のFCスイッチ105の構成情報を示す。
図6は、本実施例の構成管理DB132に含まれるテーブルのうち、管理オブジェクトの種別がストレージである装置の構成情報を示すテーブルを説明する図である。
ストレージテーブル600は、二つのフィールド、すなわち、装置ID601およびストレージ名602を含む。装置ID601は、管理対象装置を一意に識別するための識別情報である。ストレージ名602は、運用管理者がストレージ104A等を一意に識別するための名称である。
特に、図6の、ストレージテーブル600は、2012年1月1日から2012年12月31日までの管理対象のストレージ104A、104Bの構成情報を示す。
図7は、本実施例の構成管理DB132に含まれるテーブルのうち、管理オブジェクトの種別がHBAであるコンポーネントの構成情報を示すテーブルを説明する図である。
HBAテーブル700は、四つのフィールド、すなわち、コンポーネントID701、WWN702、装置ID703および接続先ターゲットWWN704を含む。
コンポーネントID701は、管理対象装置のコンポーネントを一意に識別するための識別情報である。WWN702は、HBAに割り当てられたWWN(World Wide Name)である。装置ID703は、HBAが動作しているサーバ102A等の識別情報である。装置ID703に記録される識別情報はサーバテーブル400の装置ID401に格納される値と同じ値を用いる。接続先ターゲットWWN704は、HBA142がストレージ104Aの論理ボリューム165Aなどをマウントするために使用しているストレージ104AのI/Oポート163のWWNである。
特に、図7の、HBAテーブル700は、2012年1月1日から2012年12月31日までのHBA142の構成情報を示す。
図8は、本実施例の構成管理DB132に含まれるテーブルのうち、管理オブジェクトの種別がディスクドライブであるコンポーネントの構成情報を示すテーブルを説明する図である。
ディスクドライブテーブル800は、六つのフィールド、すなわち、コンポーネントID801、ドライブ名802、装置ID803、HBA_WWN804、接続先ターゲットWWN805およびLUN_ID806を含む。
コンポーネントID801は、管理対象装置のコンポーネントを一意に識別するための識別情報である。ドライブ名802は、サーバ102におけるドライブ(SCSIディスク)151Aの名称である。装置ID803は、ドライブ151Aをマウントしているサーバ102Aの識別子である。HBA_WWN804は、ディスクドライブ151Aへのアクセスに使用されるHBA142のWWNである。接続先ターゲットWWN805は、ストレージ104Aなどのドライブの記憶領域を論理ボリューム165Aとして利用するためにアクセスしているストレージ104AなどのI/Oポート163のWWNである。LUN_ID806は、各ストレージ104AなどのI/Oポート163に関連付けられる論理ボリューム165Aなどの識別子である。
特に、図8の、ディスクドライブテーブル800は、2012年1月1日から2012年12月31日までのSCSIディスク151Aなどの構成情報を示す。
図9は、本実施例の構成管理DB132に含まれるテーブルのうち、管理オブジェクトの種別が論理ボリュームであるコンポーネントの構成情報を示すテーブルを説明する図である。
論理ボリュームテーブル900は、六つのフィールド、すなわち、コンポーネントID901、ポートWWN902、LUN_ID903、装置ID904、容量905およびRAIDグループ番号906を含む。
コンポーネントID901は、管理対象装置のコンポーネントを一意に識別するための識別情報である。ポートWWN902は、各論理ボリューム165Aなどの記憶領域を提供するために利用するI/Oポート163のWWNである。LUN_ID903は、I/Oポート163に関連付けられる論理ボリューム165Aなどの識別子である。装置ID904は、論理ボリューム165Aなどが構成されるストレージ104の識別子である。容量905は、論理ボリューム165Aなどの記憶領域の容量である。RAIDグループ番号906は、RAIDグループ164Aなどを各ストレージ104A内で一意に識別する識別情報であり、論理ボリューム165Aなどの記憶領域を提供しているRAIDグループである。
特に、図9の、論理ボリュームテーブル900は、2012年1月1日から2012年12月31日までの論理ボリューム165Aなどの構成情報を示す。
図10は、本実施例の構成管理DB132に含まれるテーブルのうち、管理オブジェクトの種別がRAIDグループであるコンポーネントの構成情報を示すテーブルを説明する図である。
RAIDグループテーブル1000は、五つのフィールド、すなわち、コンポーネントID1001、RAIDグループ番号1002、装置ID1003、容量1004およびRAIDレベル1005を含む。
コンポーネントID1001は、管理対象装置のコンポーネントを一意に識別するための識別情報である。RAIDグループ番号1002は、RAIDグループ164Aなどをストレージ104A内で一意に識別するための識別情報である。装置ID1003は、RAIDグループ164Aなどが含まれるストレージ104Aの識別情報である。容量1004は、RAIDグループ164Aなどの記憶領域の容量である。RAIDレベル1005は、RAIDグループ164AなどのRAIDレベルである。
特に、図10の、RAIDグループテーブル1000は、2012年1月1日から2012年12月31日までのRAIDグループ164Aなどの構成情報を示す。
図11は、本実施例の構成管理DB132に含まれるテーブルのうち、管理オブジェクトの種別がストレージポートであるコンポーネントの構成情報を示すテーブルを説明する図である。
ストレージポートテーブル1100は、五つのフィールド、すなわち、コンポーネントID1101、ポート番号1102、WWN1103、装置ID1104およびアクセス許可WWN1105を含む。
コンポーネントID1101は、管理対象装置のコンポーネントを一意に識別するための識別情報である。ポート番号1102は、ストレージ104AなどでI/Oポート163を一意に識別するための識別情報である。WWN1103は、I/Oポート163に割り当てられたWWNである。装置ID1104は、I/Oポート163を有するストレージ104Aなどの識別情報である。アクセス許可WWN1105は、I/Oポート163へのアクセスが許可されたHBAのWWNである。
特に、図11の、ストレージポートテーブル1100は、2012年1月1日から2012年12月31日までのI/Oポート163の構成情報を示す。
図12は、本実施例の構成管理DB132に含まれるテーブルのうち、管理オブジェクトの種別がストレージディスクであるコンポーネントの構成情報を示すテーブルを説明する図である。
ストレージディスクテーブル1200は、四つのフィールド、すなわち、コンポーネントID1201、ディスク番号1202、装置ID1203およびRAIDグループ番号1204を含む。
コンポーネントID1201は、管理対象装置のコンポーネントを一意に識別するための識別情報である。ディスク番号1202は、ストレージ104Aなどで記憶媒体162Aなどを一意に識別する識別情報である。装置ID1203には、記憶媒体162Aなどを有するストレージ104Aなどの識別情報である。RAIDグループ番号1204は、記憶媒体162Aなどが構成するRAIDグループ164Aなどを各ストレージ104Aなどで一意に識別する識別情報である。
特に、図12の、ストレージディスクテーブル1200は、2012年1月1日から2012年12月31日までの記憶媒体162Aの構成情報を示す。
図13は、本実施例の構成管理DB132に含まれるテーブルのうち、管理オブジェクトの種別がFCスイッチポートであるコンポーネントの構成情報を示すテーブルを説明する図である。
FCスイッチポートテーブル1300は、五つのフィールド、すなわち、コンポーネントID1301、ポート番号1302、WWN1303、装置ID1304および接続先ポートWWN1305を備える。
コンポーネントID1301は、管理対象装置のコンポーネントを一意に識別するための識別情報である。ポート番号1302は、FCスイッチ105内でポート171Aなどを一意に識別する識別情報である。WWN1303は、ポート171Aなどに割り当てられたWWNである。装置ID1304は、ポート171Aなどを有するFCスイッチ105の識別子である。接続先ポートWWN1305は、ポート171Aなどが直接接続されるポートのWWNである。
特に、図13の、FCスイッチポートテーブル1300は、2012年1月1日から2012年12月31日までのFCスイッチのポート171Aの構成情報を示す。
前述したように、図14は、図1に示す各管理オブジェクトのI/O(入出力)の関係、接続関係、依存関係などの関連を、管理オブジェクトの種別ごとに表現したクラス図である。
例えば、図14のサーバ1401や、HBA1402は、それぞれ管理オブジェクトの種別を表す。例えば、矢印1403は、HBA1402がサーバ1401の部品となり得ることを示す。例えば、コネクタ1404は、HBA1402とストレージポート1406との接続関係が生じ得ることを示し、多重度1405は、ストレージポート1406が一つ存在する場合、接続関係が生じ得るHBAは0個、1個、または複数であることを示す。実際の管理オブジェクトに矢印1403およびコネクタ1404が示す関連が生じているかは、構成管理DB132の構成情報から導出することができる。
<関連テーブル>
図15Aおよび図15Bは、本実施例の関連テーブル133のデータ構造の例を説明する図である。本実施例の関連テーブル133は、図15Aに示すエントリの下に、図15Bに示すエントリが続く構造である。
関連テーブル133は、各管理オブジェクト種別間(本実施例では、構成管理DB132のテーブル間)で生じ得る関連の情報、すなわち、図14のクラス図における矢印1403およびコネクタ1404の情報を格納する。関連テーブル133は、構成管理DB132の各テーブルの各フィールドの対応関係を格納しており、対応関係があるフィールドの値が等しい場合、構成管理DB132のテーブルの各エントリの管理オブジェクトは関連があることを示す。
関連テーブル133を参照することによって、指定した管理オブジェクトと関連を持つ管理オブジェクトの情報を構成管理DB132から取得することができる。すなわち、関連テーブル133の各エントリは、構成管理DB132から管理オブジェクト間の関連情報を取得するための関連付けを示す。
関連テーブル133は、五つのフィールド、すなわち、関連ID1501、テーブル名X1502、フィールド名X1503、テーブル名Y1504、フィールド名Y1505を含む。
関連ID1501は、管理オブジェクト種別の対応関係を一意に識別するための識別情報である。テーブル名X1502は、構成管理DB132のテーブル名である。フィールド名X1503は、テーブル名X1502が示すテーブルのフィールド名である。テーブル名Y1504は、テーブル名X1502が示すテーブルと関連を持つテーブル名である。フィールド名Y1505は、テーブル名Y1504が示すテーブルのフィールド名である。フィールド名X1503が示すフィールドと、フィールド名Y1505が示すフィールドとに等しい値が格納されている場合、各エントリが示す管理オブジェクトは関連を持つ。
例えば、図15Aに示す1番目のエントリ1511は、構成管理DB132において、ディスクドライブテーブル800の装置IDフィールド803の値(図8参照)と、サーバテーブル400の装置IDフィールド401の値(図4参照)とが等しいエントリが各テーブルに格納されている場合、それらのエントリが示すディスクドライブ151Aなどとサーバ102Aなどとは関連している(すなわち、ディスクドライブ151Aはサーバ102Aの構成要素である)ことを示す。
また、3番目のエントリ1513は、フィールド1503および1505において、さらにAND演算子を用いている。すなわち、エントリ1513は、構成管理DB132において、ディスクドライブテーブル800の接続先ターゲットWWNフィールド805の値と、論理ボリュームテーブル900のポートWWNフィールド902の値とが等しく、かつ、ディスクドライブテーブル800のLUN_IDフィールド806の値と、論理ボリュームテーブル900のLUN_IDフィールド903の値とが等しいエントリが各テーブルに格納されている場合、それらのエントリが示すディスクドライブ151Aなどと論理ボリューム165Aなどとは関連している(すなわち、論理ボリューム165Aをディスクドライブ151Aの記憶領域として利用している)ことを示す。
なお、本実施例では、構成管理DB132の各テーブルの関連ごとに関連テーブルのエントリを用意したが、二つ以上の関連に関する情報を一つのエントリに格納してもよい。例えば、図14のクラス図に示すように、論理ボリュームテーブルとストレージディスクとは直接関連しない。しかし、論理ボリュームとストレージディスクはが、トポロジとしてRAIDグループを介して関連するので、論理ボリュームテーブルのエントリとストレージディスクテーブルのエントリとの関連を示すエントリが、関連テーブル133に含まれてもよい。
<トポロジ取得方式リポジトリおよびトポロジ取得方式>
トポロジ取得方式は、メタルールを実際に管理対象システムに対して適用して展開ルールを生成する際に、メタルールを適用可能なトポロジを構成管理DB132から検索し、該当するトポロジの情報を取得するための手段を示す情報である。
図16Aから図16Eは、本実施例のトポロジ取得方式リポジトリ134に常駐するトポロジ取得方式の例を説明する図である。
図16Aおよび図16Bに示すように、トポロジ取得方式は、二つのフィールド、すなわち、方式ID1601および方式1602を含む。
方式ID1601は、トポロジ取得方式を一意に識別するための識別情報である。方式1602は、関連テーブル133の一つまたは複数のエントリの識別情報(関連ID)である。方式1602に格納された関連IDを持つ関連テーブル133のエントリを取得し、取得したエントリが示す関連を全て持つ管理オブジェクト群の情報を構成管理DB132から取得することによって、トポロジ情報を取得することができる。
なお、トポロジ取得方式1600は、複数のメタルール300から参照されていてよい。
また、例えば、図16Bに示すトポロジ取得方式1600は、識別情報が「Method2」であり、関連テーブル133において関連ID1501がAS3およびAS10のエントリに登録された構成管理DB132のフィールドの対応関係に基づいて、メタルール300を適用するトポロジの情報を構成管理DB132から取得できることを示す。トポロジ取得方式1600を用いて実際にトポロジ情報を取得する際には、関連テーブル133の関連ID1501が「AS3」のエントリと「AS10」のエントリの情報に基づいて、以下の全ての条件を同時に満たす構成管理DB132のディスクドライブテーブル800と、論理ボリュームテーブル900と、ストレージポートテーブル1100とのエントリの組み合わせを取得する。
(1)ディスクドライブテーブル800の接続先ターゲットWWN805の値と、論理ボリュームテーブル900のポートWWN902の値とが等しく、かつ、ディスクドライブテーブル800のLUN_ID806の値と論理ボリュームテーブル900のLUN_ID903の値とが等しい。
(2)論理ボリュームテーブル900のポートWWN902の値とストレージポートテーブル1100のWWN1103の値が等しい。
方式1602には、関連テーブル133の一つまたは複数のエントリの情報に基づいて導出された、構成管理DB132からトポロジを取得する処理、例えば、プログラムやSQLなどのデータベース問い合わせ言語などが格納されてもよい。
例えば、構成管理DB132が当該技術分野において公知であるリレーショナルデータベースであり、データベース問い合わせ言語SQLによってデータを取得できる場合、図16Aに示すトポロジ取得方式1600に対応して、関連ID1501がAS3、AS12のエントリに登録された構成管理DB132のフィールドの対応関係に基づいて、図16Cに示すSQL1650A、図16Dに示すSQL1651A、図16Eに示すSQL1652Aを生成してもよい。SQL1650Aはディスクドライブテーブルに属するコンポーネントIDを起点としてトポロジ情報を取得するSQLであり、SQL1651AはRAIDグループテーブルに属するコンポーネントIDを起点としてトポロジ情報を取得するSQLであり、SQL1652Aは指定した関連を持つ全てのトポロジの情報を取得するSQLである。
なお、これらのSQLには処理の高速化のための工夫がされるとよい。例えば、構成管理DB132のテーブル間の多重度に応じて、SQL文のWHERE句に記述する条件によって取得するエントリを絞り込む順序を変更してもよい。
また、トポロジ取得方式において、スイッチのようにある装置から別の装置までの間に多段に接続されたトポロジを取得する場合、方式1602に、「N*AS8」など、「AS8(関連ID)に対応するエントリが示す関連をN回繰り返し辿る」という定義を含めてもよい。
<展開ルールリポジトリおよび展開ルール>
展開ルールは、管理対象システムにおいて発生しうるイベントの組み合わせと、それらのイベントが発生した場合の障害の原因候補となるイベントとの対応関係を示す情報である。展開ルールは、管理対象システムの構成情報に基づいて、メタルール300を適用可能なトポロジを管理対象システムの中から検索し、検索されたメタルール300を適用した結果生成されるルールである。
本実施例において、展開ルールは、メタルールと同様に、IF−THEN形式で記述するが、システム障害の原因事象と、原因事象によって引き起こされる観測事象が記述されていれば、他の形式でもよい。
図17Aから図17Cは、本実施例の展開ルールリポジトリ136に格納される展開ルールの例を説明する図である。
一般に、展開ルールも、メタルール300と同様に、二つの部分、すなわちIF部1711と称される第1の部分と、THEN部1712と称される第2の部分とに分けることができる。IF部1711は一つ以上の条件要素を含んでもよい。
展開ルール1700は、IF部1711のイベント(条件イベント)が検知された場合、THEN部1712のイベント(結論イベント)が障害の原因となることを示す。したがって、THEN部1712のステータスが正常になれば、IF部1711の問題も解決することが見込まれる。
本実施例においては、図2のイベントテーブル131に格納されるイベント情報を観測事象とし、障害を解析するため、展開ルール1700のIF部1711の各条件要素には装置ID1701、コンポーネントID1702、イベント種別1703、および受信フラグ1704が記述される。すなわち、IF部1711の条件要素の装置ID1701およびコンポーネントID1702によって指定される管理オブジェクトにおいてイベント種別1703の状態が発生することを示す。また、受信フラグ1704は、実際に条件要素が示すイベントを受信したかの結果である。条件要素が示すイベントを受信した場合は受信フラグ1704に「1」が格納され、条件要素が示すイベントを受信していない場合は受信フラグ1704に「0」が格納される。受信フラグ1704に「1」が格納された後、所定の時間が経過すると値を「0」に戻すなどの処理を行ってもよい。
また、展開ルール1700は、各メタルールを一意に識別する展開ルールIDを格納するフィールド1713を含む。
例えば、図17Aに示す展開ルール「ExpandedRule1−1」は、観測事象として「サーバA(装置ID=SvA)のDドライブ(コンポーネントID=DRIVE1)の転送時間性能エラー」と、「ストレージA(装置ID=StA)におけるRAIDグループ0(コンポーネントID=RG1)の書込処理のヒット率性能エラー」とが検知された場合、「ストレージAにおけるRAIDグループ0の書込処理のヒット率性能エラー」が原因であると結論付けられることを示す。なお、IF部1711に含まれる条件要素として、ある管理オブジェクトが正常であること(障害イベントが発生していないこと)を定義してもよい。
<メタルールの生成処理>
本実施例においては、ルール作成者(システムの運用管理者)が管理対象システムで実際に発生した障害の原因と、その原因によって引き起こされた各管理オブジェクトのイベントを入力し、それらの入力された情報に基づいてメタルールが生成される。ルール作成者が実際に管理しているシステムにおいて実際に発生した障害の情報に基づいて、情報を入力することによって、より正確なルールを作成できる。さらに、障害解析機能の内部仕様を極力隠蔽して、メタルール生成に必要な情報を入力することができる。
例えば、管理対象システムで発生した障害について、障害解析機能が正しい解析結果を出さなかった場合、メタルールが不足していることが分かる。当該障害の対策後に、原因が判明した場合、当該障害の情報に基づいてメタルールの生成に必要な情報を入力し、新しいメタルールを生成することによって、以後、同様の障害が発生した場合に、障害を迅速に解析することができる。
図18Aおよび図18Bは、本実施例の管理コンピュータ101でメタルール生成プログラム121が実行するメタルール生成処理の例のフローチャートである。
メタルール生成プログラム121は、入力デバイス114からのルール作成者の指示によって起動されるように構成されるとよい。また、メタルール生成プログラム121は、管理対象システムで障害が発生し、障害解析プログラム123が障害を解析した後、解析結果が正しくなかったと判断される条件を満たした場合、障害解析プログラム123によって起動され、処理を開始してもよい。
メタルール生成プログラム121は、図18の処理において、さらに図21から図27に示す処理を呼び出して、実行する。
ステップS1811において、メタルール生成プログラム121は、表示モジュール125を起動し、管理対象システムで発生したイベントをイベントテーブル131から取得し、イベント一覧を表示した原因イベント選択画面を出力デバイス117に表示する。
図19は、本実施例の原因イベント選択画面1900の例を説明する図である。
図19に例示するように、例えば、原因イベント選択画面1900は、ルール作成者が入力フォーム1901で期間を入力して検索ボタン1903を操作すると、入力された期間内に発生したイベントをイベントテーブル131から検索し、イベント表示部1904に、その一覧を表示する機能を有してよい。あるいは、図19に例示するように、入力フォーム1902で文字列を入力して検索ボタン1903を操作すると、入力された文字列を含むイベントをイベントテーブル131から検索し、検索されたイベントの一覧をイベント表示部1904に表示する機能を有してよい。あるいは、イベントテーブル131から、最新のイベントを起点として順に古いイベントを辿れてもよい。
ステップS1812において、メタルール生成プログラム121は、ルール作成者が選択したイベントを原因イベントとして受信する。例えば、ルール作成者は、原因イベント選択画面1900(図19)に表示されたイベント一覧の中から、あるシステム障害の原因となる事象を示すイベントを選択し、原因イベント確定ボタン1906を操作すると、メタルール生成プログラム121は、選択されたイベントの情報を受信する。
ステップS1813において、メタルール生成プログラム121は、イベントテーブル131から発生日時フィールド205の値を参照し、S1812で受信したイベントの発生時刻から所定期間内に発生したイベントを取得する。例えば、受信した原因イベントのイベントIDが、イベントテーブル131のイベントID201が「EV1」であり、所定期間が「前後10分以内」である場合、イベントID201がEV2のイベントおよびEV3のイベントをイベントテーブル131から取得する。
ステップS1814において、メタルール生成プログラム121は、ステップS1812で受信した原因イベント、およびステップS1813で取得したイベント群を入力として、トポロジ探索処理を起動し、イベント、トポロジ情報およびトポロジ情報取得方式の組み合わせを取得する。各組み合わせは、ステップS1813で取得した各イベント、原因イベントが発生した管理オブジェクト間のトポロジ情報、および、そのトポロジを取得するための手段(方式)の組み合わせである。
ステップS1815において、メタルール生成プログラム121は、表示モジュール125を起動し、ステップS1814で取得したイベント、トポロジ情報およびトポロジ取得方式の組み合わせのうち、各イベント、トポロジ情報および原因イベントを出力デバイス117に表示する。複数のトポロジの全てまたは一部が重複している場合、一つにまとめて表示してもよい。
このように所定期間内に発生したイベントを表示し、その中からイベントの選択を促すことによって、原因イベントによって引き起こされたイベントを検索する手間を省くことができ、さらに、選択漏れを防ぐことができる。
図20は、ステップS1815で表示する影響イベント選択画面2000の例を説明する図である。
例えば、影響イベント選択画面2000は、ステップS1812またはS1814で取得したイベントの情報、および、取得したイベントが発生した管理オブジェクトの情報を、アイコン2001、2002のように表示する。例えば、アイコン2001は、イベントが「ストレージAのRAIDグループ0の書込処理のヒット率性能エラー」であることを示す。また、アイコン2001は、原因イベントであることを示す表示を有してもよい。
また、コネクタ2003は二つの管理オブジェクト間の関連を示しており、例えば、アイコン2002、アイコン2004およびアイコン2001の間をコネクタ2003で繋ぐことによって、サーバAのDドライブおよびストレージAのRAIDグループ0の間には、「サーバAのDドライブは、ストレージA上の、LUN IDが0の論理ボリュームを記憶容量として利用しており、さらにLUN IDが0の論理ボリュームはRAIDグループ0に生成されている」というトポロジがあることを示すことができる。なお、コネクタ2003には、そのコネクタの意味(例えば、「利用している」「マウントしている」)などを表示してもよい。
また、特定の二つの管理オブジェクトに対して、複数のトポロジが表示されてもよい。例えば、サーバAのDドライブと、ストレージAのRAIDグループ0は、アイコン2002、2007、2006、2004、2001、および、それらの間を繋ぐコネクタで表現されるトポロジも有する。また、影響イベント選択画面2000には、同じメタルールを作らないようにするため、原因イベントに対して既にメタルール300によってルール化されているイベントがある場合は、ルール化されているイベントを表示してもよい。
ここで、メタルール生成プログラム121の処理の説明に戻る。
ステップS1816において、メタルール生成プログラム121は、ルール作成者が選択したイベントを影響イベントとして受信する。影響イベントは、複数選択されてもよい。
例えば、図20の影響イベント選択画面2000に表示されたアイコンの中から、ルール作成者はステップS1812で選択した原因イベントが引き起こしたイベントを選択し、確定ボタン2008を操作する。メタルール生成プログラム121は、選択されたイベントの情報を受信する。
ステップS1817において、メタルール生成プログラム121は、ステップS1814で取得したイベント、トポロジ情報およびトポロジ取得方式の組み合わせの一覧から、ステップS1816で受信した影響イベントに対応するトポロジ情報およびトポロジ取得方式の組み合わせを全て取得する。
ステップS1818において、メタルール生成プログラム121は、ステップS1812で受信した原因イベント、ステップS1816で受信した影響イベント、および、ステップS1817で取得したイベント、トポロジ情報およびトポロジ取得方式の組み合わせを入力として、メタルール候補生成処理を起動し、メタルール300を取得する。
ステップS1819において、メタルール生成プログラム121は、ステップS1818で取得したメタルールを入力として、メタルール検証情報表示処理を起動する。メタルール検証情報表示処理は、生成されたメタルールを用いて、正しい障害解析が可能かを検証するためのヒント情報を表示する処理である。
ステップS1820において、メタルール生成プログラム121は、ルール作成者が入力したメタルールの「生成」または「破棄」の決定を受信する。
ステップS1821において、メタルール生成プログラム121は、ステップS1820の入力が「生成」であるかを調べる。条件を満たす(入力が「生成」である)場合、処理はステップS1822へ進み、条件を満たさない場合、処理は終了する。
ステップS1822において、メタルール生成プログラム121は、ステップS1818で取得したメタルールをメタルールリポジトリ135に登録する。
図21は、本実施例のメタルール生成プログラム121のステップS1814で実行されるトポロジ探索処理の例のフローチャートである。
トポロジ探索処理は、入力された原因イベントが発生した管理オブジェクトから、当該原因イベント以外のイベントが発生した管理オブジェクトまでの関連を、構成管理DB132において探索し、二つの管理オブジェクト間のトポロジを抽出する処理である。また、関連を探索する際に、関連の辿り方を記録することによって、メタルールを適用するトポロジを構成管理DB132から取得する手段(トポロジ取得方式)を生成する。
ステップS2111において、トポロジ探索サブプログラムは、原因イベントおよび当該原因イベント以外のイベントを含む、イベントテーブル131のエントリを、パラメータとして受信する。
ステップS2112において、トポロジ探索サブプログラムは、原因イベント以外のイベントについて、ステップS2113からS2117の処理を繰り返す。
ステップS2113において、トポロジ探索処理は、当該イベントのコンポーネントID203の値(コンポーネントIDがNULLの場合は装置ID202の値)を取得する。
ステップS2114において、トポロジ探索サブプログラムは、ステップS2113で取得した管理オブジェクトID(コンポーネントID203または装置ID202)が登録された構成管理DB132のテーブル名およびエントリを取得する。エントリを取得する構成管理DB132のテーブルは、当該イベントの発生時刻または原因イベントの発生時刻における構成情報を示す構成管理DB132のテーブルでよい。また、以降で呼び出す関連探索処理も含め、構成管理DB132から取得するエントリは、全て当該イベントの発生時刻または原因イベントの発生時刻における構成情報を示す構成管理DB132のテーブル内のエントリでよい。
本実施例においては、管理オブジェクトの種別ごとに構成管理DB132のテーブルを作成している。このため、ステップS2114においてテーブル名を取得しているが、テーブル名ではなく、管理オブジェクトの種別を表す別の識別情報を取得してもよい。
ステップS2115において、トポロジ探索サブプログラムは、トポロジ情報およびトポロジ取得方式を含むリストを生成し、S2113のエントリの管理オブジェクトIDおよび空の関連IDの組を起点として、リストの先頭に記録する。
ステップS2116において、トポロジ探索サブプログラムは、原因イベント、ステップS2114で取得したエントリ、テーブル名、および、ステップS2115で生成した管理オブジェクトIDおよび関連IDの組のリストを入力として、関連探索処理を起動する。関連探索処理は、ステップS2114で取得したエントリを起点とし、関連テーブル133の情報に基づいて、各管理オブジェクトを示すエントリの関連を辿り、トポロジ情報および当該トポロジ情報を取得するためのトポロジ取得方式の組み合わせを生成して、探索結果メモリとして、メモリ112に記録する処理である。
ステップS2117において、トポロジ探索サブプログラムは、メモリ112に格納された探索結果メモリから、トポロジ情報およびトポロジ取得方式の組み合わせを取得し、各組み合わせについて当該イベントの情報を付加し、メモリ112に記録する。なお、探索結果メモリに記録された情報は削除してもよい。
ステップS2118において、トポロジ探索サブプログラムは、ステップS2117で記録した、トポロジ情報、トポロジ取得方式およびイベントの組み合わせを読み出し、呼出元プログラムに返す。
図22Aおよび図22Bは、本実施例のトポロジ探索処理のステップS2116で実行される関連探索処理の例のフローチャートである。
関連探索処理は、構成管理DB132において、一つの管理オブジェクトを起点とし、原因イベントが発生した管理オブジェクトまでの関連を、関連テーブル133の情報に基づいて辿ることによって、起点管理オブジェクトから原因管理オブジェクトまでのトポロジ情報を取得する。また、関連を探索する際に、関連の辿り方を記録することによって、合わせてトポロジ取得方式も生成し、トポロジ情報および当該トポロジ情報を取得するためのトポロジ取得方式の組み合わせを、探索結果メモリとして、メモリ112に記録する処理である。
ある装置で障害イベントが発生した場合、トポロジ上の管理オブジェクトは全て影響を受けるが、管理コンピュータ101が取得できる管理オブジェクトの状態情報および性能情報によっては、トポロジ上の全ての管理オブジェクトのイベントを検知できない場合がある。そのため、ルール作成者が指定する原因管理オブジェクトおよび影響管理オブジェクトは直接関連するとは限らないため、関連探索処理が示すように管理オブジェクト間の関連を辿る必要がある。
なお、本実施例においては、構成管理DB132のエントリをノードとした場合に関連を探索するアルゴリズムは、経路探索アルゴリズムのうち、当該技術分野で公知の深さ優先探索のアルゴリズムを用いることができるが、他のアルゴリズム(例えば、幅優先探索)を用いてもよい。また、一つのノードから探索するのではなく、原因管理オブジェクトおよび影響管理オブジェクトの両方から探索を開始してもよい。
ステップS2211において、関連探索サブプログラムは、原因イベント、構成管理DB132のエントリ、テーブル名、管理オブジェクトIDおよび関連IDの組のリストをパラメータとして受信する。
ステップS2212において、関連探索サブプログラムは、関連テーブル133から、テーブル名X1502またはテーブル名Y1504の値が受信したテーブル名と等しいエントリを全て取得する。
ステップS2213において、関連探索サブプログラムは、ステップS2212において取得した関連テーブル133のエントリについて、ステップS2214からS2221の処理を繰り返す。
ステップS2214において、関連探索サブプログラムは、関連テーブル133の当該エントリに登録された構成管理DB132における管理オブジェクト種別間の対応関係に基づいて、受信した構成管理DB132のエントリと関連する全てのエントリを構成管理DB132から取得する。すなわち、例えば、当該エントリのテーブル名X1502に、受信したテーブル名が格納されている場合、フィールド名X1503に格納されたフィールド名Aを取得し、受信したエントリのフィールド名Aに該当するフィールドに格納された値Bを取得する。そして、当該エントリのテーブル名Y1504に格納されたテーブル名を持つ構成管理DB132のテーブルから、フィールド名Y1505に格納されたフィールド名に該当するフィールドに値Bと等価な値が格納されたエントリ一覧を取得する。
ステップS2215において、関連探索サブプログラムは、ステップS2214で取得した構成管理DB132のエントリについて、ステップS2216からS2221の処理を繰り返す。
ステップS2216において、関連探索サブプログラムは、構成管理DB132の当該エントリのコンポーネントID(装置に関するエントリについては装置ID)と、関連テーブル133の当該エントリの関連ID1501とを組にしたものを探索中のトポロジの最先端管理オブジェクト(最先端ノード)に関する情報として、受信したリストの先頭に追加する。
ステップS2217において、関連探索サブプログラムは、原因イベントのコンポーネントID(コンポーネントIDがNULLである場合は装置ID)と、構成管理DB132の当該エントリのコンポーネントID(または、装置ID)が等しいかを判定する。条件を満たす場合、処理はステップS2218に進む。一方、条件を満たさない場合、処理はステップS2219に進む。
ステップS2218において、関連探索サブプログラムは、管理オブジェクトIDと関連IDとの組のリストから、管理オブジェクトIDのリストをトポロジ情報とし、関連IDのリストをトポロジ取得方式とし、トポロジ情報およびトポロジ取得方式の組み合わせを、探索結果メモリとして、メモリ112に記録する。また、ステップS2115からの繰り返し処理を終了する。
ステップS2219において、関連探索サブプログラムは、関連探索の打ち切り条件を満たしているかを調べる。条件を満たす場合、構成管理DBの次のエントリについてステップS2215からの繰り返し処理を実行する。一方、条件を満たさない場合、処理はステップS2220に進む。
ステップS2219における関連探索の打ち切り条件は、例えば、管理オブジェクトIDと関連IDの組のリストの中に、同じ管理オブジェクトIDが記録されている場合、すなわち、同じ管理オブジェクトに戻ってきた場合を条件としてよい。また、トポロジ探索処理の処理時間を短縮するため、一部のトポロジを探索せず、例えば、管理オブジェクトIDと関連IDの組のリストの要素が一定数以上になった場合、以後の探索を打ち切ってもよい。また、構成管理DB132のデータモデル上、トポロジとしてあり得ないパターンを事前に定義できる場合、それ以上の探索を打ち切る条件としてもよい。例えば、あるサーバ上のコンポーネントから、ストレージ上のコンポーネントを介し、別のサーバ上のコンポーネントまたはスイッチ上のコンポーネントまで辿った場合、それ以上の探索を打ち切る条件を定義できる場合は、それ以上の探索を打ち切る条件としてもよい。
ステップS2220において、関連探索サブプログラムは、構成管理DB132から当該エントリが属するテーブル名を取得する。
ステップS2221において、関連探索サブプログラムは、受信した原因イベント、構成管理DB132の当該エントリ、ステップS2220で取得したテーブル名、管理オブジェクトIDおよび関連IDの組のリストを入力として、関連探索処理を再帰的に呼び出すために、起動する。
トポロジ探索処理および関連探索処理において、トポロジ情報、トポロジ取得方式およびイベントの組み合わせの一覧を取得する具体例を以下に説明する。
例えば、ステップS2111において、原因イベントとして、図2のエントリ211を、それ以外のイベントとして、エントリ212を受信する。ステップS2112の繰り返し処理で、エントリ212を選択した場合、エントリ212のコンポーネントID203からコンポーネントID「DRIVE1」を取得する(ステップS2113)。
次に、コンポーネントID「DRIVE1」が格納されたエントリ811と、エントリ811が格納されたテーブルの名称「ディスクドライブ」とを取得する(ステップS2114)。そして、トポロジ情報とトポロジ取得方式を記録するためのリストを生成し、コンポーネントID「DRIVE1」および空の関連IDを先頭に追加する(ステップS2115)。
次に、エントリ211、エントリ811、テーブル名「ディスクドライブ」、および先頭の要素が「DRIVE1」のリストを入力として、関連探索処理を起動する(ステップS2116)。関連探索処理は、これらの値をパラメータとして受信する(ステップS2211)。
次に、関連テーブル133から、テーブル名X1502およびテーブル名Y1504の各フィールドの値が「ディスクドライブ」となるエントリ1511、1512、1513を取得する(ステップS2212)。ステップS2213の繰り返し処理で、エントリ1513を選択した場合、エントリ811の接続先ターゲットWWN805の値「20:00:00:00:00:00:00:01」と、LUN_ID806の値「0」を取得する。そして、構成管理DBの論理ボリュームテーブル900を参照して、ポートWWN902のフィールドの値が「20:00:00:00:00:00:00:01」であり、かつ、LUN_ID903のフィールドの値が「0」であるエントリ911を取得する(ステップS2214)。
ステップS2214からの繰り返し処理で、エントリ911を選択した場合、エントリ911のコンポーネントID「VOL1」と、エントリ1513の関連ID「AS3」とを組みにして、受信したリストの先頭に追加する(ステップS2216)。したがって、この時点でリストは「VOL1,AS3」−「DRIVE1,empty」の要素と順序を持つ。
次に、ステップS2217において、エントリ911のコンポーネントID「VOL1」と原因イベントのエントリ212のコンポーネントIDは異なるため、処理はステップS2219に進む。ステップS2219において、関連探索打ち切り条件を満たしていない場合はステップS2220に進む。
次に、エントリ911が属するテーブル名「論理ボリューム」を取得する(ステップS2220)。そして、原因イベントのエントリ212、エントリ911、テーブル名「論理ボリューム」、および、リスト「VOL1,AS3」−「DRIVE1,empty」を入力として、関連探索処理を起動する。以降の関連探索処理で、ステップS2213の繰り返し処理においてエントリ1522を選択し、ステップS2215でエントリ1011を選択した場合、ステップS2217において、エントリ1011は原因イベントのコンポーネントID「RG1」を有するため、ステップS2218に進む。
そして、リスト「RG1,AS12」−「VOL1,AS3」−「DRIVE1,empty」から「RG1−VOL1−DRIVE1」というトポロジ情報と、「AS12−AS3」というトポロジ取得方式を生成して、両者を組み合わせ、探索結果メモリとして、メモリ112に記録する。
このようにして、複数のトポロジ情報とトポロジ取得方式との組み合わせが、メモリ112に記録される。トポロジ探索処理のステップS2117に戻り、探索結果メモリから、例えば「RG1−VOL1−DRIVE1」というトポロジ情報と、「AS12−AS3」というトポロジ取得方式の組み合わせを取得した場合、その組み合わせに対してイベントを示すエントリ212を組み合わせてメモリ112に記録する(ステップS2118)。そして、ステップS2117で記録した情報を呼び出し元プログラムに渡す。
なお、本実施例の「トポロジ探索処理」において、イベント毎に、イベントが発生した管理オブジェクトから原因管理オブジェクトまでのトポロジを探索し、トポロジ取得方式を生成している。これに対し、あるイベントに対応するトポロジを探索した際に、探索中に別のイベントの発生管理オブジェクトを辿った場合、途中経路に出現した管理オブジェクトのトポロジ探索処理は省略するなどの処理を行い、処理を高速化してもよい。
図23Aおよび図23Bは、本実施例のメタルール生成プログラム121のステップS1818で実行されるメタルール候補生成処理の例のフローチャートである。
メタルール候補生成処理は、トポロジ探索処理で取得したトポロジ取得方式と、ルール作成者が指定した原因イベント、影響イベントからメタルール300を生成し、新規メタルール候補としてルール作成者に提示する処理である。
ステップS2311において、メタルール候補生成サブプログラムは、原因イベントを示すイベントテーブル131のエントリ、影響イベントを示すイベントテーブル131のエントリ、および、トポロジ探索処理から取得したイベント、トポロジ情報およびトポロジ取得方式の組み合わせの一覧をパラメータとして受信する。
ステップS2312において、メタルール候補生成サブプログラムは、原因イベントのイベント種別204の値、装置ID202に格納された値が属する装置種別、および、コンポーネントID203に格納された値が属するコンポーネント種別を取得する。本実施例においては、構成管理DB132の各テーブルが管理オブジェクト種別毎に作成されているため、各管理オブジェクトIDが属する構成管理DB132のテーブル名を取得する。
ステップS2313において、メタルール候補生成サブプログラムは、影響イベントのイベント種別204の値、および、装置ID202またはコンポーネントID203が属する管理オブジェクト種別(構成管理DB132のテーブル名)を取得する。
ステップS2314において、メタルール候補生成サブプログラムは、ステップS2312、S2313で取得した装置種別、コンポーネント種別およびイベント種別を組み合わせ、メタルールのIF部311を生成する。
ステップS2315において、メタルール候補生成サブプログラムは、ステップS2312で取得した原因イベントの装置種別、コンポーネント種別およびイベント種別を組み合わせ、メタルールのTHEN部312を生成する。そして、ステップS2314で生成したIF部311と、ステップS2315で生成したTHEN部312とを組み合わせてメタルール300を生成する。
ステップS2316において、メタルール候補生成サブプログラムは、ステップS2315で生成したメタルール300のメタルールID313に、メタルールリポジトリ135においてメタルールを一意に識別できる識別子を設定する。
ステップS2317において、メタルール候補生成サブプログラムは、受信したイベント、トポロジ情報およびトポロジ取得方式の組み合わせの一覧から、トポロジ情報とトポロジ取得方式との組み合わせの一覧を抽出する。そして、抽出された一覧を入力とし、トポロジ取得方式選択処理を起動する。トポロジ取得方式選択処理は、入力されたトポロジ取得方式の一覧の中から、メタルールが利用するトポロジ取得方式一覧を取得する処理である。
ステップS2318において、メタルール候補生成サブプログラムは、ステップS2317で取得した全てのトポロジ取得方式について、ステップS2319からS2323の処理を繰り返す。
ステップS2319において、メタルール候補生成サブプログラムは、当該トポロジ取得方式がトポロジ取得方式リポジトリ134に含まれているか否かを判定する。条件を満たす場合、処理はステップS2322に進む。一方、条件を満たさない場合、処理はステップS2320に進む。
ステップS2320において、メタルール候補生成サブプログラムは、当該トポロジ取得方式1600の方式ID1601に、トポロジ取得方式リポジトリ134において一意に識別できる識別子を設定し、トポロジ取得方式1600をトポロジ取得方式リポジトリ134に登録する。
ステップS2321において、メタルール候補生成サブプログラムは、ステップS2320において方式ID1601に設定した識別子をメタルール300のトポロジ取得方式ID314に設定する。
また、ステップS2319において、処理がステップS2322に進んだ場合、ステップS2322において、メタルール候補生成サブプログラムは、トポロジ取得方式リポジトリ134から、当該トポロジ取得方式と等しい方式1600の方式ID1601の値を取得する。
ステップS2323において、メタルール候補生成サブプログラムは、ステップS2322で取得した方式ID1601の値をメタルール300のトポロジ取得方式ID314に設定する。
その後、ステップS2324において、メタルール候補生成サブプログラムは、生成したメタルール300をメタルール候補生成処理の呼び出し元プログラムに渡す。なお、ステップS2321またはS2323で格納した複数のトポロジ取得方式が関連IDのリストの全てまたは一部が一致していた場合、トポロジ取得方式を結合して一つのトポロジ取得方式として作成し、メタルール300のトポロジ取得方式ID314に登録してもよい。
例えば、ステップS2311において、原因イベントとしてイベントテーブル131のエントリ211を取得し、影響イベントとしてエントリ212を取得し、ステップS2317において、図16に示すトポロジ取得方式1600Aを取得した場合、図3に示すメタルール300が生成される。
図24は、本実施例のメタルール候補生成処理のステップS2317で実行されるトポロジ取得方式選択処理の例のフローチャートである。
トポロジ取得方式選択処理では、ルール作成者に各影響イベントに対応するトポロジ情報を提示し、各影響イベントに対応するトポロジ取得方式を一つ選択させることによって、一つまたは複数のトポロジ取得方式の中からメタルール300が利用する方式を絞り込む。
ステップS2411において、トポロジ取得方式選択サブプログラムは、イベント、トポロジ情報およびトポロジ取得方式の組み合わせの一覧をパラメータとして受信する。
ステップS2412において、トポロジ取得方式選択サブプログラムは、表示モジュール125を起動し、受信したイベントとトポロジ情報の組み合わせを出力デバイス117に表示する。
ステップS2413において、トポロジ取得方式選択サブプログラムは、ルール作成者が各影響イベントに対応して選択した一つのトポロジのトポロジ情報を受信する。
ステップS2414において、トポロジ取得方式選択サブプログラムは、ステップS2411で受信したトポロジ情報およびトポロジ取得方式の組み合わせの一覧の中から、ステップS2413で受信したトポロジ情報に対応するトポロジ取得方式を取得し、呼び出し元プログラムに渡す。
図25Aおよび図25Bは、本実施例のメタルール生成プログラム121のステップS1819で実行されるメタルール検証情報表示処理の例のフローチャートである。
メタルール検証情報表示処理は、生成したメタルールを用いて正しい障害解析が可能かを検証するためのヒント情報を表示する処理である。ルール作成者は、表示されたヒント情報に基づいて、メタルール生成プログラム121がステップS1818で生成したメタルール300を、以降、管理対象システムで発生する障害の解析に利用するかを決定する。具体的には、以下の2点を検証用の情報として表示する。
(1)メタルール300を、最新の管理対象システムの構成に適用し、展開ルールを生成して、全てまたは一部の展開ルールを表示する。また、一つのメタルール300に対応して生成される展開ルール数を表示する。これにより、トポロジ取得方式選択処理で選択したトポロジ取得方式に基づいて、実際の管理対象システム構成にメタルール300を適用した場合に、正しい展開ルールが生成されるかの検証や、管理対象システムを構成する装置数に対して展開ルールが多いか、少ないかなどを検証できる。
(2)メタルール300が、過去に発生した障害に対して有効であるかを表示する。すなわち、メタルールのIF部311が示すイベントが同じタイミングに発生した例が過去にあるかを判定し、同じタイミングに発生した例がある場合は、イベントテーブル131の情報に基づいて発生回数を導出し、導出した発生回数を表示する。メタルールのIF部311が示すイベントが同じタイミングに発生した例が過去にある場合、メタルールが有効であることが分かる。
ステップS2511において、メタルール検証情報表示サブプログラムは、メタルール300をパラメータとして受信する。
ステップS2512において、メタルール検証情報表示サブプログラムは、表示モジュール125を起動し、メタルールを出力デバイス117に表示する。
ステップS2513において、メタルール検証情報表示サブプログラムは、メタルール300のトポロジ取得方式ID314が示すトポロジ取得方式1600をトポロジ取得方式リポジトリ134から取得する。
ステップS2514において、メタルール検証情報表示サブプログラムは、最新のシステム構成情報を示す構成管理DB132から、ステップS2513のトポロジ取得方式1600が示すトポロジに該当するトポロジ情報を全て取得する。
ステップS2515において、メタルール検証情報表示サブプログラムは、ステップS2514で取得した全てのトポロジに対して、ステップS2516の処理を繰り返す。
ステップS2516において、メタルール検証情報表示サブプログラムは、当該トポロジ情報内のエントリ一覧の中から、メタルール300のIF部311の条件要素、またはTHEN部312が指定するコンポーネント種別または装置種別に該当するエントリを抽出する。そして、抽出されたエントリおよびメタルール300の情報を組み合わせて展開ルール1700を生成する。
ステップS2517において、メタルール検証情報表示サブプログラムは、ステップS2512で表示したメタルールの情報に加えて、ステップS2516で取得した展開ルールおよび取得した展開ルールの数を表示する。
例えば、ステップS2511において、メタルール300を受信し、最新の構成情報を示す構成管理DB132のテーブルが図4から図13に示すテーブルである場合、ステップS2513で取得するトポロジ取得方式は図16Aに示すトポロジ取得方式1600であり、ステップS2514で取得するトポロジの情報は「エントリ811(DRIVE1),エントリ911(VOL1),エントリ1011(RG1)」「エントリ812(DRIVE2),エントリ913(VOL3),エントリ1013(RG3)」「エントリ914(DRIVE4),エントリ912(VOL2),エントリ1012(RG2)」の三つである。ステップS2516において、これら三つのトポロジ情報およびメタルール300に基づいて、図17Aから図17Cに示す展開ルール1700A、1700B、1700cを生成する。このため、ステップS2517においては、これら三つの展開ルールおよび生成した展開ルールの数「3」を出力デバイス117に表示する。
ステップS2518において、メタルール検証情報表示サブプログラムは、受信したメタルール300のIF部311の全ての条件要素に合致するイベントをイベントテーブル131から検索し、取得する。
検索範囲はイベントテーブル131全てのエントリであってもよいし、特定の期間内に発生したイベントに検索範囲を限定してもよい。その場合、ルール作成者が期間を指定することができる。
例えば、受信したメタルールが図3に示すメタルール300であり、イベントテーブル131が図2に示すテーブルである場合、メタルール300の条件要素は「ストレージ RAIDグループ WriteHitPerfError」と「サーバ ディスクドライブ AverageSecPerXferError」である。このため、これらに合致するイベントは図2のエントリ211とエントリ212となる。
ステップS2519において、メタルール検証情報表示サブプログラムは、ステップS2518で取得した全イベントに対して、ステップS2520からS2526の処理を繰り返す。
ステップS2520において、メタルール検証情報表示サブプログラムは、当該イベントが処理済みかを判定する。条件を満たす場合、次のイベントについてステップS2519からの繰り返し処理を実行する。一方、条件を満たさない場合、処理はステップS2521に進む。
ステップS2521において、メタルール検証情報表示サブプログラムは、メタルール300、当該イベントの発生日時205、装置ID202、コンポーネントID203およびイベント種別204を入力として、ルール展開処理を起動し、展開ルール一覧を取得する。
ステップS2522において、メタルール検証情報表示サブプログラムは、ステップS2521で取得した全ての展開ルールに対し、ステップS2523からステップS2526の処理を繰り返す。
ステップS2523において、メタルール検証情報表示サブプログラムは、イベントテーブル131において、当該展開ルールのIF部1711に記述された全てのイベントが、当該イベントの発生日時から所定の期間内に発生しているかを判定する。条件を満たす場合、処理はステップS2524に進む。一方、条件を満たさない場合、次の展開ルールについてステップS2522からの繰り返し処理を実行する。
ステップS2524において、メタルール検証情報表示サブプログラムは、当該展開ルールおよびステップS2523において展開ルール1700のIF部1711に記述されたイベントに合致したイベント(当該イベントを含む)の組み合わせを、メモリ112に記録する。
例えば、展開ルールが図17Aに示す展開ルール1700であり、イベントが図2のエントリ211であり、「所定の期間」が前後10分以内である場合、図2に示すイベントテーブル131を参照すると、エントリ211の発生から5分後にエントリ212が示すイベントが発生しており、エントリ211およびエントリ212によって、図17Aに示す展開ルール1700のIF部1711に記述されたイベントを全て満たす。このため、ステップS2523における条件を満たすことになる。したがって、ステップS2524において、展開ルール1700、イベントを示すエントリ211およびエントリ212の組み合わせをメモリ112に記録する。
ステップS2525において、メタルール検証情報表示サブプログラムは、ステップS2524において記録されたイベント一覧を全て処理済みイベントとして登録する。
ステップS2526において、メタルール検証情報表示サブプログラムは、ステップS2517の表示に加えて、ステップS2524で記録した展開ルール、イベント一覧(または、それらの組み合わせ)および組み合わせの数を表示する。
したがって、ステップS2526によって過去に生成したメタルール300が適用される障害事例の内容および発生回数をメタルール作成者に提示することができる。また、イベントの履歴と展開ルールとを比較することによって、展開ルールが正しいかを検証することができる。
例えば、図25Aおよび図25Bに示す方法においては、メタルール300が適用される障害事例が少ない場合、メタルール300のIF部に記述された条件要素に余分なものが含まれる可能性があるなどの判断をすることができる。IF部に余分な条件要素が含まれる場合、障害解析時に、後述する「展開ルールのイベント受信率」が100%より低くなり、適切な障害解析結果を提示できない。
なお、図25Aおよび図25Bに示す方法は、イベントテーブルの中からメタルールのIF部が示す障害イベントのみを表示するが、それらの障害イベントの発生時刻から所定の期間内に発生した別の障害イベントも合わせて表示してもよい。これにより、生成したメタルールのIF部に記述された条件要素が不足している可能性があるなどを判断することができる。IF部の条件要素が不足している場合、障害解析時に、後述する「展開ルールのイベント受信率」が本来示すべき値より高くなり、適切な障害解析結果を提示できない。
また、図25Aおよび図25Bに示す方法は、ステップS2521で一度メタルールから展開ルールを生成し、そのIF部の条件要素に合致する障害イベントをイベントテーブルから検索する。これにより、検索対象を、メタルールを適用するトポロジに限定した上で、メタルールに対応する障害事例が発生したことがあるかを提示することができる。
なお、ステップS2514においては、処理の高速化のために、当該トポロジ取得方式で取得できる全てのトポロジ情報に対してメタルールを適用するのではなく、一部のトポロジ情報に対してメタルールを適用してもよい。この場合、ステップS2517において、当該トポロジ取得方式で取得できる全てのトポロジ情報の数に対して、何パーセントのトポロジ情報を抽出したかの概算を表示してもよい。
また、ステップS2526において、ステップS2524で記録した展開ルールとイベント一覧の組み合わせの数だけでなく、展開ルールのTHEN部に記述されたイベントの過去の発生回数に対応して、ステップS2523において、展開ルールのIF部の条件を満たした回数(または割合)を表示してもよい。
図26は、本実施例のメタルール検証情報表示処理のステップS2516、S2521、および、障害解析プログラム127のステップS2814で実行されるルール展開処理の例のフローチャートである。
ルール展開処理は、入力されたメタルールを、入力されたコンポーネントID(または装置ID)が示す管理オブジェクトを起点とするトポロジに適用し、展開ルールを生成する処理である。入力する時刻は、どの時刻の構成管理DB132を利用してトポロジ情報を取得するかを指定する。
ステップS2611において、ルール展開サブプログラムは、メタルール300、日時、コンポーネントID(または装置ID)およびイベント種別をパラメータとして受信する。
ステップS2612において、ルール展開サブプログラムは、メタルール300のトポロジ取得方式ID314で指定する識別子のトポロジ取得方式1600を、トポロジ取得方式リポジトリ134から取得する。
ステップS2613において、ルール展開サブプログラムは、構成管理DB132のテーブルの内、ステップS2611で受信した日時における構成情報を示すテーブルを抽出する。
ステップS2614において、ルール展開サブプログラムは、受信した装置ID、またはコンポーネントIDを起点として、ステップS2612で取得したトポロジ取得方式1600に基づいて、ステップS2613で抽出した構成管理DB132のテーブルからメタルールを適用するトポロジ情報を取得する。
例えば、ステップS2611でコンポーネントID「RG1」を受信し、ステップS2612で図16Aに示すトポロジ取得方式1600を取得する。そして、ステップS2613で抽出した構成管理DB132のテーブルが図4から図13に示すテーブルであった場合、一つのトポロジ「エントリ1011(RG1),エントリ911(VOL1),エントリ811(DRIVE1)」が取得される。
ステップS2615において、ルール展開サブプログラムは、ステップS2614で取得した全てのトポロジ情報に対して、ステップS2616の処理を繰り返す。
ステップS2616において、ルール展開サブプログラムは、当該トポロジ情報内のエントリ一覧の中から、メタルール300のIF部311の条件要素、またはTHEN部312が指定するコンポーネント種別(または装置種別)に該当するエントリを抽出し、抽出されたエントリの情報およびメタルール300の情報を組み合わせて展開ルール1700を生成する。
例えば、ステップS2611で図3のメタルール300を受信し、ステップS2616の繰り返し処理においてトポロジ「エントリ1011(RG1),エントリ911(VOL1),エントリ811(DRIVE1)」が選択された場合、メタルール300のTHEN部312はコンポーネント種別がRAIDグループであるため、トポロジ情報の中からエントリ1011のコンポーネントID「RG1」および装置ID「StA」を取得し、展開ルールのTHEN部1712として「StA RG1 WriteHitPerfError」を生成する。同様にIF部の条件要素も生成し、展開ルール1700Aを生成する。
ステップS2617において、ルール展開サブプログラムは、ステップS2616で生成した展開ルール1700の一覧をルール展開処理の呼び出し元プログラムに渡す。
<障害解析の処理>
図27Aおよび図27Bは、本実施例の管理コンピュータ101において障害解析プログラム123によって実行される障害解析処理の例のフローチャートである。
障害解析プログラム123は、イベント受信プログラム122が管理対象装置からイベントを受信し、イベントテーブル131にイベント情報を書き込んだ後に呼び出されることにより、処理を開始してよい。
障害解析プログラム123は、受信したイベントと、メタルールリポジトリ135内のメタルール300に基づいて、必要な展開ルール1700を生成し、障害原因候補とその影響範囲をシステムの運用管理者に提示すべく障害解析処理を実行する。
ステップS2711において、障害解析プログラム123は、未処理のイベントをイベントテーブル131から取得する。
ステップS2712において、障害解析プログラム123は、ステップS2711で取得したイベントを処理済みのイベントとして登録する。
ステップS2713において、障害解析プログラム123は、ステップS2711で取得したイベントに対応するメタルール300をメタルールリポジトリ135から取得する。
例えば、ステップS2711でエントリ222が示すイベントを取得した場合、装置ID202の値が「SvB」であり、コンポーネントID203の値が「DRIVE4」であり、それぞれの装置種別は「サーバ」であり、コンポーネント種別は「ディスクドライブ」である。このため、メタルールのIF部に「サーバ ディスクドライブ AverageSecPerXferError」の条件要素を持つ図3のメタルール300を取得する。
ステップS2714において、障害解析プログラム123は、ステップS2713で取得した全てのメタルールについて、ステップS2715からS2718の処理を繰り返す。
ステップS2715において、障害解析プログラム123は、当該メタルール、ステップS2711で取得したイベントの発生日時205、装置ID202、コンポーネントID203およびイベント種別204を入力として、ルール展開処理を起動し、展開ルール一覧を取得する。
ステップS2716において、障害解析プログラム123は、ステップS2715において取得した全ての展開ルールについて、ステップS2717からS2718の処理を繰り返す。
ステップS2717において、障害解析プログラム123は、当該展開ルールが既に展開ルールリポジトリ136に含まれているかを判定する。条件を満たす場合、次の展開ルールについてステップS2714からの繰り返し処理を実行する。一方、条件を満たさない場合、処理はステップS2718に進む。
ステップS2718において、障害解析プログラム123は、当該展開ルールを展開ルールリポジトリ136に登録する。
ステップS2719において、障害解析プログラム123は、ステップS2711で取得したイベントをIF部1711の条件要素に含む展開ルール一覧を展開ルールリポジトリ136から取得する。
ステップS2720において、障害解析プログラム123は、ステップS2719で取得した全ての展開ルールについて、ステップS2721からS2723の処理を繰り返す。
ステップS2721において、障害解析プログラム123は、ステップS2711において取得したイベントに該当する当該展開ルールの条件要素の受信フラグ1704を「1」に変更する。
ステップS2722において、障害解析プログラム123は、当該展開ルールのイベント受信率を計算する。各展開ルールのイベント受信率は、以下の式によって計算することができる。
イベント受信率=受信フラグ1704が「1」の条件要素数/条件要素の総数
例えば、図17Aに示す展開ルール1700においては、条件要素の数は二つであり、そのうち受信フラグ1704が「1」の条件要素は一つであるため、イベント受信率は1/2(50%)となる。
ステップS2723において、障害解析プログラム123は、表示モジュール125を起動し、当該展開ルールのTHEN部1712を障害の原因候補とし、IF部の各条件要素を原因候補に対する影響範囲とし、さらに、ステップS2722で算出したイベント受信率を原因候補の確からしさとし、それらを解析結果として出力デバイス117に表示する。
なお、すでにTHEN部1712の障害が原因候補として出力デバイス117に表示されている場合、高い方のイベント受信率を表示してもよい。
以上に説明したように、障害解析プログラム123が実行する処理によって、管理対象システムに障害が発生した場合、障害原因候補およびその影響範囲を自動的に導出し、システム運用管理者に提示することができる。
なお、障害解析プログラム123の処理を高速化するために、ステップS2715で展開ルールを生成する前に、生成しようとする展開ルールが既に展開ルールリポジトリ136内に含まれるかが分かるように、展開履歴を作成してもよい。
また、障害解析処理を高速化する公知の技術(例えば、特表2011−518359号公報に開示されるもの)を適用してもよい。また、イベントを受信するごとに展開ルールを生成せずに、障害が発生する前に全ての展開ルールを生成してもよい。
また、図27Aおよび図27Bに示す障害解析プログラム123が実行する処理では、発生したイベントを含む展開ルールのみしか作成していないが、ステップS2715で取得した展開ルールのTHEN部に記述されたイベントの情報、および当該イベントに関連するメタルールを入力として、ルール展開処理を起動し、THEN部のイベントを含む展開ルールを全て生成し、それらの展開ルールも含めてステップS2720以降の処理を実行して解析結果を提示してもよい。これにより、ある原因候補に対する影響を受けて発生し得る全ての障害イベントを表示することができる。
以上で説明したメタルール生成プログラム121および障害解析プログラム123が実行する処理によって、ルール作成者が指定した原因イベントの情報および影響イベントの情報からメタルールを生成し、生成したメタルールに基づいて、同じパターンのトポロジ上で発生した障害を解析することができる。
例えば、システム運用管理者が、メタルール生成プログラム121の実行するステップS1812において、原因イベントとしてイベントテーブル131のエントリ211(ストレージAのRAIDグループ0の書込処理のヒット率性能エラー)を選択し、ステップS1816において、影響イベントとしてエントリ212(サーバAのDドライブの転送時間性能エラー)を選択し、トポロジ取得方式選択処理が実行するステップS2413において、「DRIVE1,VOL1,RG1」に該当するトポロジを選択した場合、メタルール生成プログラム121は、図3に示すメタルール300および図16Aに示すトポロジ取得方式1600を生成する。そして、例えば、管理対象システムのサーバBにおいて、イベントテーブル131のエントリ222が示すイベントが発生した場合、障害解析プログラム123によって、メタルール300とトポロジ取得方式1600Aから図17Cに示す展開ルール1700が生成され、障害解析結果として「ストレージAのRAIDグループ1の書込処理のヒット率性能エラーが原因である」という解析結果、および、影響範囲は「ストレージAのRAIDグループ1の書込処理のヒット率性能エラー」、「サーバBのDドライブの転送時間性能エラー」であるという解析結果が運用管理者に提示される。
以上に説明したように、本発明の第1の実施例によれば、システム運用管理者が一つの原因イベントを選択し、一つまたは複数の影響イベントを選択すると、各イベントが発生した管理オブジェクトの種別を導出し、メタルール、およびメタルールを他の管理オブジェクトに適用するためのトポロジ取得方式を自動的に生成する。これにより、システム運用管理者は、障害解析機能の内部仕様を知ることなく、実際に管理しているシステムの情報および実際に発生したイベントを指定するだけで、メタルールを生成することができる。
前述した第1の実施例では、ルール作成者が、実際に発生した障害の情報に基づいて必要な情報を入力し、メタルールを生成する。第2の実施例では、実際に障害が発生していなくてもルールを作成できるように、ルール作成者がメタルールを作成するために入力する情報および入力画面が異なる。
また、第1の実施例では、原因管理オブジェクトおよび影響管理オブジェクトの実際のトポロジを探索し、トポロジ取得方式を生成する。その結果、管理対象システムのトポロジが複雑な場合、トポロジ探索処理の演算量が大きくなり、メタルールの生成に時間がかかる可能性がある。第2の実施例では、トポロジ探索処理を高速化するため、トポロジ探索処理のもう一つの方法として、実際の管理オブジェクトの関連を辿ってトポロジ情報を取得するのではなく、関連テーブルに登録された管理オブジェクトがとり得る関連を辿り、管理オブジェクトがとり得るトポロジの情報を取得する。これにより、トポロジ取得方式を生成する。
具体的には、実際に発生した障害のイベントではなく、原因となる管理オブジェクト種別、原因となるイベント種別、影響を受ける管理オブジェクト種別および影響を受けるイベント種別の入力を求める。そして、入力された影響管理オブジェクト種別を起点として、関連テーブル133のテーブル名を辿り、影響管理オブジェクト種別と原因管理オブジェクト種別がとり得るトポロジの情報を取得する。
第2の実施例において、システム構成、各装置の構成および各プログラムが実行する処理のうち、第1の実施例と同じものについては説明を省略する。第2の実施例を説明するための管理対象の例示的なハードウェアアーキテクチャおよび論理構成は、第1の実施例において前述したもの(図1)でよい。また、イベントテーブル131は図2に示す構成例でよく、メタルールリポジトリ135のメタルールは図3に示す構成例でよく、構成管理DB132のテーブルは図4から図13に示す構成例でよく、関連テーブル133は図15に示す構成例でよく、トポロジ取得方式リポジトリ134のトポロジ取得方式は図16に示す構成例でよく、展開ルールリポジトリ136の展開ルールは図17に示す構成例でよい。
また、第2の実施例において、第1の実施例と同様に、トポロジ取得方式選択処理は図24に示す処理と同じでよく、メタルール検証情報表示処理は図25に示す処理と同じでよく、ルール展開処理は図26に示す処理と同じでよく、障害解析プログラム123が実行する処理は図27に示す処理と同じでよい。
<メタルール生成の処理>
図28は、第2の実施例の管理コンピュータ101でメタルール生成プログラム121が実行するメタルール生成処理の例のフローチャートである。
メタルール生成プログラム121は、入力デバイス114からのルール作成者の指示によって起動されるように構成されるとよい。
第2の実施例では、第1の実施例と異なり、実際に障害が発生していなくてもルールを作成できるようにするため、メタルール生成プログラム121では、実際に発生した障害のイベントではなく、原因となる管理オブジェクト種別、原因となる管理イベント種別、影響を受ける管理オブジェクト種別および影響を受けるイベント種別の入力を求め、入力された情報に基づいてメタルールを生成する。
ステップS2811において、メタルール生成プログラム121は、表示モジュール125を起動し、イベント情報入力画面を出力デバイス117に表示する。
図29は、第2の実施例のイベント情報入力画面2900の例を説明する図である。
イベント情報入力画面2900は、例えば、図29に例示するように、影響イベントの装置種別、コンポーネント種別およびイベント種別、原因イベントの装置種別、コンポーネント種別およびイベント種別を、各リストボックス2901〜2906から選択できるとよい。また、原因イベント情報に対して、メタルールの影響イベント情報を複数設定する場合には、追加ボタン2907を操作することによって、影響イベント情報を追加する機能を有するとよい。
また、装置種別のリストボックス2901および2904において一つの装置種別を選択すると、選択した装置種別に含まれるコンポーネントの種別のみを各リストボックス2902および2905に、それぞれ表示する機能を有するとよい。また、装置種別およびコンポーネント種別をリストボックス2901〜2902、2904〜2905から選択すると、リストボックス2903および2906には、選択した装置種別あるいはコンポーネント種別において発生し得るイベント種別のみを、それぞれ表示する機能を有するとよい。
なお、イベント情報入力画面2900は、構成情報を表示する画面において、実際に管理されている管理対象装置およびそのコンポーネントを選択することによって、メタルール生成プログラム121が自動的に、装置およびコンポーネンツの種別を導出してもよい。
ステップS2812において、メタルール生成プログラム121は、ルール作成者が選択した原因イベント情報および影響イベント情報を受信する。具体的には、図29のイベント情報入力画面2900において、ルール作成者が影響イベント情報および原因イベント情報を、それぞれリストボックス2901〜2906で選択し、確定ボタン2908を操作すると、メタルール生成プログラム121は、選択されたイベントの情報を受信する。
ステップS2813において、メタルール生成プログラム121は、ステップS2812で受信した原因イベント情報および影響イベント情報を入力として、トポロジ探索処理を起動し、影響イベント情報およびトポロジ取得方式の組み合わせの一覧を取得する。
ステップS2814において、メタルール生成プログラム121は、ステップS2812で受信した原因イベント情報および影響イベント情報、および、ステップS2813で取得した影響イベント情報およびトポロジ取得方式の組み合わせの一覧を入力として、メタルール候補生成処理を起動し、メタルール300を取得する。
ステップS2815において、メタルール生成プログラム121は、ステップS2814で取得したメタルール300を入力として、メタルール検証情報表示処理を起動する。メタルール検証情報表示処理は、生成したメタルールを用いて正しい障害解析が可能かを検証するためのヒント情報を表示する処理であり、第1の実施例で説明した処理を利用することができる。
ステップS2816において、メタルール生成プログラム121は、ルール作成者が入力したメタルールの生成または破棄の決定を受信する。
ステップS2817において、メタルール生成プログラム121は、ステップS2816の入力が生成かを判定する。条件を満たす場合、処理はステップS2819へ進む。一方、条件を満たさない場合、処理は終了する。
ステップS2819において、メタルール生成プログラム121は、ステップS2814で取得したメタルール300をメタルールリポジトリ135に登録する。
図30は、第2の実施例のメタルール生成プログラム121のステップS2813で実行されるトポロジ探索処理の例のフローチャートである。
第2の実施例のトポロジ探索処理が受信するパラメータは、第1の実施例における入力に装置IDおよびコンポーネントIDと異なり、装置種別およびコンポーネント種別が含まれる。そのため、パラメータとして入力された装置種別およびコンポーネント種別に含まれる装置およびコンポーネントがとり得るトポロジを関連テーブル133に基づいて導出し、メタルールが利用するトポロジ取得方式を取得する。
具体的には、影響イベント情報の管理オブジェクト種別を起点として、原因イベント情報の管理オブジェクト種別まで、関連テーブル133のエントリを辿ることによって、トポロジ取得方式を取得する。
ステップS3011において、トポロジ探索処理は、原因イベント情報と影響イベント情報をパラメータとして受信する。受信するパラメータは、メタルール生成プログラム121のステップS2812において受信した原因イベントおよび影響イベントの管理オブジェクト種別およびイベント種別である。
ステップS3012において、トポロジ探索処理は、ステップS3011で受信した全ての影響イベント情報について、ステップS3013からS3014の処理を繰り返す。
ステップS3013において、トポロジ探索処理は、原因イベント情報、当該影響イベント情報の管理オブジェクト種別(コンポーネント種別、またはコンポーネント種別が指定されていなければ装置種別)、および関連IDを記録するリストを入力として、関連探索処理を起動する。なお、本実施例においては構成管理DB132のテーブル名は管理オブジェクト種別名と等しいため、入力される管理オブジェクト種別は構成管理DB132のテーブル名を示す。関連探索処理は、関連テーブル133の情報に基づいて、入力されたテーブル名を起点とし、原因イベント情報の管理オブジェクト種別が示すテーブル名までの関連を辿り、トポロジ取得方式を生成して、探索結果メモリとしてメモリ112に記録する処理である。
ステップS3014において、トポロジ探索処理は、メモリ112に関連探索処理によって記録された探索結果メモリからトポロジ取得方式一覧を取得し、取得したトポロジ取得方式一覧を当該影響情報と組み合わせてメモリ112に記録する。
ステップS3015において、トポロジ探索処理は、ステップS3014で記録した影響情報およびトポロジ取得方式の組み合わせの一覧をトポロジ探索処理の呼び出し元プログラムに渡す。
図31は、トポロジ探索処理のステップS3013で実行される関連探索処理の例のフローチャートである。
第2の実施例における関連探索処理は、関連テーブル133のエントリに登録されたテーブル名を辿り、受信した影響イベント情報の管理オブジェクト種別(テーブル名)と原因イベント情報の管理オブジェクト種別(テーブル名)がとり得るトポロジを導出し、トポロジ取得方式を生成する処理である。
ステップS3111において、関連探索サブプログラムは、原因イベント情報、テーブル名および関連IDを記録するリストをパラメータとして受信する。
ステップS3112において、関連探索サブプログラムは、ステップS3111で受信したテーブル名とテーブル名X1502またはテーブル名Y1504の値が等しい全てのエントリを関連テーブル133から取得する。
ステップS3113において、関連探索サブプログラムは、ステップS3112で取得した関連テーブル133のエントリについて、ステップS3114からS3119の処理を繰り返す。
ステップS3114において、関連探索サブプログラムは、当該関連テーブルのエントリの関連IDを、関連IDを記録するリストの先頭に追加する。
ステップS3115において、関連探索サブプログラムは、当該関連テーブルのエントリに基づいて、受信したテーブル名と関連するテーブル名を取得する。
ステップS3116において、関連探索サブプログラムは、ステップS3115で取得したテーブル名が、受信した原因イベント情報の管理オブジェクト種別を示すかを判定する。条件を満たす場合、処理はステップS3117に進む。一方、条件を満たさない場合、処理はステップS3118に進む。
ステップS3117において、関連探索サブプログラムは、関連IDを記録したリストからトポロジ取得方式を生成し、探索結果メモリとしてメモリ112に記録する。
ステップS3118において、関連探索サブプログラムは、関連探索の打ち切り条件を満たしているか否かを調べる。条件を満たす場合、次の関連テーブルのエントリについてステップS3113からの繰り返し処理を実行する。一方、条件を満たさない場合、ステップS3119に進む。関連探索の打ち切り条件は、例えば、関連IDのリストの中に、同じ関連IDが所定の回数以上記録されている場合を条件としてもよい。また、トポロジ探索処理の処理時間を短縮するため、一部のトポロジを探索せず、例えば、関連IDのリストの要素が一定数以上になった場合、以後の探索を打ち切ってもよい。
ステップS3119において、関連探索サブプログラムは、受信した原因情報、ステップS3115で取得したテーブル名および関連IDのリストを入力として、関連探索処理を再帰的に起動する。
例えば、トポロジ探索処理が、原因情報として、装置種別「ストレージ」、コンポーネント種別「RAIDグループ」、イベント種別「書込処理のヒット率性能エラー」を入力し、さらに、影響イベント情報のテーブル名として「ディスクドライブ」を、関連探索処理に入力し、関連探索処理がそれらを受信した(ステップS3111)。
この場合、関連テーブル133のエントリ1511、1512、1513(図15A参照)を取得する(ステップS3112)。ステップS3113の繰り返し処理でエントリ1513を選択した場合、関連IDのリストには「AS3」が追加され(ステップS3114)、テーブル名「論理ボリューム」を取得する(ステップS3115)。取得したテーブル名「論理ボリューム」と原因イベント情報のコンポーネント種別「RAIDグループ」とが一致しないため(ステップS3116)、原因イベント情報、テーブル名「論理テーブル」、関連IDのリストを入力として再帰的に関連探索処理を起動する(ステップS3119)。
再帰的に起動した関連探索処理では、ステップS3113の繰り返し処理でエントリ1522が選択され、テーブル名「RAIDグループ」を取得する(ステップ3115)。このため、ステップS3116で処理をステップS3117に進め、要素に「AS3,AS12」を持つ関連IDのリストからトポロジ取得方式を生成し、探索結果メモリとしてメモリ112に記録する。
図32は、第2の実施例のメタルール生成プログラム121のステップS2814で実行されるメタルール候補生成処理の例のフローチャートである。
ステップS3211において、メタルール候補生成サブプログラムは、原因イベント情報、影響イベント情報、影響イベント情報およびトポロジ取得方式の組み合わせの一覧をパラメータとして受信する。
ステップS3212において、メタルール候補生成サブプログラムは、影響イベント情報の装置種別、影響イベント情報のコンポーネント種別、影響イベント情報のイベント種別、原因イベント情報の装置種別、原因イベント情報のコンポーネント種別、および原因イベント情報のイベント種別を組み合わせてメタルールのIF部311を生成する。
ステップS3213において、メタルール候補生成サブプログラムは、原因イベント情報の装置種別、コンポーネント種別およびイベント種別を組み合わせてメタルールのTHEN部312を生成し、ステップS3212で生成したIF部311と組み合わせてメタルール300を生成する。
ステップS3214において、メタルール候補生成サブプログラムは、メタルール300を一意に識別する識別子をメタルールID313に設定する。
ステップS3215において、メタルール候補生成サブプログラムは、受信した影響情報とトポロジ取得方式の組み合わせの一覧を入力として、トポロジ取得方式選択処理を起動し、メタルールを適用するトポロジを取得するためのトポロジ取得方式の一覧を取得する。
ステップS3215から後の処理は、前述した第1の実施例のメタルール候補生成処理(図23B)のステップS2318以後と同じである。
なお、第1の実施例ではトポロジ取得方式選択処理が起動する際に受信するパラメータは、イベント、トポロジ情報およびトポロジ取得方式の組み合わせの一覧であったが、第2の実施例では、トポロジ取得方式選択処理が起動する際に受信するパラメータは、影響イベント情報およびトポロジ取得方式の組み合わせの一覧である。このため、第2の実施例では、入力した各影響イベント情報と取得できるトポロジのパターンを出力デバイス117に表示し、ルール作成者に各影響イベント情報に対応した一つのトポロジのパターンを選択させるとよい。
以上が、本実施例におけるメタルールのメタルール生成プログラム121の処理である。
以上に説明したように、本発明の第2の実施例によれば、実際に障害が発生していない場合でもメタルールを作成することができる。また、構成管理DB132の情報に基づいて原因管理オブジェクトの実際のトポロジおよび影響管理オブジェクトの実際のトポロジを探索することなく、関連テーブル133のエントリのみを辿り、トポロジ取得方式を生成することによって、トポロジ探索処理の計算量を減らすことができる。その結果、メタルール生成の処理およびルール作成者への情報提示の処理を高速化することができる。
前述した第1および第2の実施例では、トポロジ取得方式選択処理において、生成したメタルールに対して適切なトポロジをルール作成者に選択させ、選択されたトポロジに基づいてメタルールと対応付けるトポロジ取得方式を決定する。
しかし、一つのメタルールに対応して多くのトポロジが候補として提示された場合、ルール作成者が適切なトポロジを選択することが困難であり、また、その作業のためのコストが大きくなる。
このため、第3の実施例では、一つのメタルールに対応して複数のトポロジ取得方式が候補となった場合、メタルールが利用すべきトポロジ取得方式の優先度を決定する。これにより、ルール作成者がメタルールに対応して利用するトポロジ取得方式を選択し易くなり、選択作業のコストを削減することができる。
第3の実施例において、システム構成、各装置の構成および各プログラムが実行する処理のうち、第1または第2の実施例と同じものについては説明を省略する。第3の実施例を説明するための管理対象の例示的なハードウェアアーキテクチャおよび論理構成は、第1の実施例において前述したもの(図1)でよい。また、イベントテーブル131は図2に示す構成例でよく、メタルールリポジトリ135のメタルールは図3に示す構成例でよく、構成管理DB132のテーブルは図4から図13に示す構成例でよく、トポロジ取得方式リポジトリ134のトポロジ取得方式は図16に示す構成例でよく、展開ルールリポジトリ136の展開ルールは図17に示す構成例でよい。
また、第3の実施例において、第1の実施例と同様に、メタルール生成プログラム121が実行する処理は図18に示す処理と同じでよく、障害解析プログラム123が実行する処理は図27に示す処理と同じでよい。なお、メタルール生成プログラム121が実行する処理は図28に示す第2の実施例の処理でもよい。
第3の実施例においては、メタルールが利用すべきトポロジ取得方式の優先度を決定するためにトポロジ取得方式選択処理、または関連テーブル133を変更する。本実施例においては、優先度決定のための方法を五つ記述する。したがって、第3の実施例では複数のトポロジ方式選択処理および関連テーブルの例について説明する。
<トポロジ取得方式選択の処理およびトポロジ取得方式優先度決定の処理>
第3の実施例では、一つのメタルールにおいて、1組の原因管理オブジェクトから影響管理オブジェクトまでのトポロジを取得する方式として、複数のトポロジ取得方式が候補となった場合、それらの中からトポロジ取得方式の優先度を決定する。
トポロジ取得方式は、メタルールの適用先を限定するために用いられる。ある装置で障害が発生した場合でも、関連しない装置には影響がない。さらに、限定された特定のトポロジ(例えば、ストレージの論理ボリュームを、サーバのディスクドライブがマウントしているというトポロジ等)上の管理オブジェクトでないと伝播しない障害もある。トポロジ取得方式を用いることによって、障害が伝播し得る特定のトポロジ上の管理オブジェクトの組み合わせに限定して、メタルールを適用する。限定しない場合は、不要な、または誤った展開ルールが生成されることになる。トポロジ取得方式によってメタルールを適用する範囲を限定することによって、運用管理者に不要な原因候補または誤った原因候補を提示することを抑制し、さらには不要な展開ルールの生成を抑制することで管理コンピュータ101の処理負荷を軽減できる。
本実施例では、メタルールをより適切な範囲に適用できるトポロジ取得方式から順にランク付けをして、優先度としてルール作成者に提示する。
以下に、五つの優先度の決定方法を説明する。
なお、本実施例では五つの方法を優先度の決定する方法の例を説明するが、障害解析の特徴に基づいて予め定義された基準を利用してトポロジ取得方式を評価し、優先度を決定する方法であれば、例示する五つの方法に限定されない。
<方法1:関連の多重度を評価基準とした優先度決定方法>
トポロジ取得方式の優先度を決定する第1の方法は、管理オブジェクトの関連の多重度を評価基準とする方法である。具体的には、取得できる影響管理オブジェクトと原因管理オブジェクトの組み合わせが多対多関係となるトポロジ取得方式より、1対多関係となる方式を優先し、1対多関係となる方式より1対1関係となる方式を優先する。
これは、トポロジ取得方式によって取得できる影響管理オブジェクトと原因管理オブジェクトの組み合わせが1対1関係であるということは、1対多または多対多関係より二つの管理オブジェクトの関係が限定されており、障害が伝播するトポロジを示している可能性が高い。
したがって、本実施例の方法1では、関連テーブル133の各エントリの関連の多重度を登録する。この多重度は、各管理オブジェクト種別の関連の多重度を示しており、実際の管理オブジェクトが持つ関連の数とは異なる意味である。そして、1組の影響管理オブジェクトから原因管理オブジェクトまでのトポロジを取得する方式として、複数のトポロジ取得方式が候補となった場合、トポロジ取得方式によって取得される各管理オブジェクト種別の関連に、多対多、1対多、多対1、1対1のいずれが含まれるかを判定して、トポロジ取得方式の優先度を決定する。
なお、本実施例では1対1、1対多、多対多の順で優先度を決定したが、これ以外の基準で多重度を評価し、トポロジ取得方式の優先度を決定してもよい。
図33Aおよび図33Bは、第3の実施例の関連テーブル133のデータ構造の例を説明する図である。本実施例の関連テーブル133は、図33Aに示すエントリの下に、図33Bに示すエントリが続く構造である。
方法1の関連テーブル133は六つのフィールドを持つ。関連ID3301、テーブル名X3302、フィールド名X3303、テーブル名Y3304、フィールド名Y3305は、それぞれ、第1の実施例の関連テーブル(図15A、図15B)の関連ID1501、テーブル名X1502、フィールド名X1503、テーブル名Y1504、フィールド名Y1505と同じである。
多重度3306は、関連テーブル133の各エントリが示す構成管理DB132のテーブル間の関連の多重度である。すなわち、図14に示すクラス図の多重度1405に該当する情報である。多重度3306を構成するフィールド3307およびフィールド3308には「多」、「1」のいずれかが登録される。フィールド3307は、テーブル名Y3304が示すテーブルを起点としたテーブル名X3302が示すテーブルの多重度を登録し、フィールド3308は、テーブル名X3302が示すテーブルを起点としたテーブル名Y3302が示すテーブルの多重度を登録する。
例えば、エントリ3311は、ディスクドライブとサーバとの関連を示しており、フィールド3307には「多」、フィールド3308には「1」が格納されている。この場合、ディスクドライブテーブルのエントリに関連するサーバテーブルのエントリは必ず一つ以下であり、サーバテーブルのエントリに関連するディスクドライブテーブルのエントリは複数になり得ることを示す。つまり、ディスクドライブを起点として関連するサーバは多対1関係、サーバを起点として関連するディスクドライブは1対多関係にあることを示す。
図34Aおよび図34Bは、第3の実施例の第1の方法におけるトポロジ取得方式選択処理の例のフローチャートである。
本実施例では、第1の実施例の方法でトポロジ取得方式選択処理が実行される場合について説明しているため、受信するパラメータは「イベント、トポロジ情報およびトポロジ取得方式の組み合わせの一覧」であるが、第2の実施例の方法でトポロジ取得方式選択処理を実行する場合には、受信するパラメータが「影響イベント情報およびトポロジ取得方式の組み合わせの一覧」でもよい。また、本実施例では優先度を数値で表し、値が小さい程優先度が高いものと定めるが、値が大きいほど優先度が高いものと定めてもよい。また、優先度の表現は数値でなく、順序を表す記述であればよい。
ステップS3411において、トポロジ取得方式選択サブプログラムは、イベント、トポロジ情報およびトポロジ取得方式の組み合わせの一覧をパラメータとして受信する。
ステップS3412において、トポロジ取得方式選択サブプログラムは、受信した全てのトポロジ取得方式について、ステップS3413からS3420の処理を繰り返す。
ステップS3413において、トポロジ取得方式選択サブプログラムは、受信したイベント、トポロジ情報およびトポロジ取得方式の組み合わせの一覧から、当該トポロジ取得方式に対応するイベントを取得し、そのイベントの管理オブジェクト種別を取得する。
ステップS3414において、トポロジ取得方式選択サブプログラムは、当該トポロジ取得方式に登録された関連IDに対応する関連テーブル133のエントリを取得し、ステップS3413で取得した管理オブジェクト種別に該当するテーブル名を起点として、取得した各エントリのテーブル名X3302およびテーブル名Y3304に格納されたテーブル名を辿る。さらに、テーブル名に対応する多重度3306を取得する。
例えば、ステップS3413において、管理オブジェクト種別「ディスクドライブ」を取得し、当該トポロジ取得方式が図16Aに示すトポロジ取得方式1600である場合、関連IDが「AS3」である関連テーブルのエントリのテーブル名X3302「ディスクドライブ」を取得する。また、「ディスクドライブ」に対する「論理ボリューム」の多重度「1対1」を多重度3306から取得する。さらに、関連テーブルの当該エントリのテーブル名Y3304が「論理ボリューム」であるため、トポロジ取得方式1600に含まれ、かつ、テーブル名X3302に「論理ボリューム」が格納されている関連IDが「AS12」のエントリを関連テーブルから取得する。この時、論理ボリュームに対する多重度「多対1」を多重度3306から取得する。したがって、多重度を「1対1」「多対1」の順で取得する。
ステップS3415において、トポロジ取得方式選択サブプログラムは、ステップS3414で取得した多重度に「多対多」が含まれているかを判定する。条件を満たす場合、処理はステップS3417に進む。一方、条件を満たさない場合、処理はステップS3416に進む。
ステップS3416において、トポロジ取得方式選択サブプログラムは、ステップS3414で取得した多重度が「多対1」「1対多」の順に現れたかを判定する。条件を満たす場合、処理はステップS3417に進む。一方、条件を満たさない場合、処理はステップS3418に進む。なお、「多対1」と「1対多」との間に「1対1」または「多対1」があってもよい。
ステップS3417において、トポロジ取得方式選択サブプログラムは、当該トポロジ取得方式の優先度を「3」に設定する。
ステップS3418において、トポロジ取得方式選択サブプログラムは、ステップS3414で取得した多重度に「1対多」が含まれるかを判定する。条件を満たす場合、処理はステップS3419に進む。一方、条件を満たさない場合、処理はステップS3420に進む。
ステップS3419において、トポロジ取得方式選択サブプログラムは、当該トポロジ取得方式の優先度を「2」に設定する。
ステップS3420において、トポロジ取得方式選択サブプログラムは、当該トポロジ取得方式の優先度を「1」に設定する。
ステップS3421において、トポロジ取得方式選択サブプログラムは、表示モジュール125を起動し、各トポロジ取得方式に対応するトポロジ情報、イベントおよび優先度の組み合わせを出力デバイス117に表示する。
ステップS3422において、トポロジ取得方式選択サブプログラムは、ステップS3421の表示情報の中からルール作成者が各イベントに対応して一つ選択したトポロジのトポロジ情報を受信する。
ステップS3423において、トポロジ取得方式選択サブプログラムは、ステップS3422で受信したトポロジ情報に対応するトポロジ取得方式一覧を、トポロジ取得方式選択処理の呼び出し元プログラムに渡す。
以上に説明した方法1は、他の方法のように適用対象が制限されないので、どのような場合でも使いやすい方法である。
<方法2:適用トポロジの集合を評価基準とした優先度決定方法>
トポロジ取得方式の優先度を決定する第2の方法は、適用トポロジの集合を評価基準とする方法である。具体的には、1組の影響管理オブジェクトから原因管理オブジェクトまでのトポロジを取得する方式として、複数のトポロジ取得方式が候補となった場合、各トポロジ取得方式で取得できる全てのトポロジ情報を取得して、各トポロジ取得方式の集合とする。そして、各々のトポロジ情報から抽出できる原因管理オブジェクトと影響管理オブジェクトの組み合わせを比較する要素とし、各集合の包含関係を求め、下位の集合を取得した方式ほど優先度を高くする。
すなわち、あるトポロジ取得方式が取得できるトポロジ情報の集合が、別の方式によって取得できるトポロジ情報の集合に包含されている場合、前者のトポロジ取得方式によって取得できる原因管理オブジェクトと影響管理オブジェクトの組み合わせは、より範囲が限定されている。したがって、メタルールの適用範囲が限定されており、前者の方式で取得するトポロジ情報の方が、障害が伝播するトポロジである可能性が高く、不要な展開ルールが生成される可能性が低くなる。
したがって、本実施例では、1組の影響管理オブジェクトから原因管理オブジェクトまでのトポロジを取得する方式として、複数のトポロジ取得方式が候補となった場合、各トポロジ取得方式によって取得できる全てのトポロジの情報を取得し、それらの集合の包含関係を算出して、最下位の集合を取得した方式から順に優先度を高くつける。
なお、本実施例では取得できるトポロジ情報の集合が下位のものほど優先度を高くしたが、別の基準に基づいて各々のトポロジ取得方式が取得できるトポロジ情報を評価し、トポロジ取得方式の優先度を決定してもよい。
図35は、第3の実施例の第2の方法におけるトポロジ取得方式選択処理の例のフローチャートである。
ステップS3511において、トポロジ取得方式選択サブプログラムは、イベント、トポロジ情報およびトポロジ取得方式の組み合わせの一覧をパラメータとして受信する。
ステップS3512において、トポロジ取得方式選択サブプログラムは、受信した全てのイベントについて、ステップS3513からS3516の処理を繰り返す。
ステップS3513において、トポロジ取得方式選択サブプログラムは、当該イベントに対応するトポロジ取得方式を、受信した組み合わせの一覧から取得する。
ステップS3514において、トポロジ取得方式選択サブプログラムは、各トポロジ取得方式に対応して、取得できる全てのトポロジ情報を構成管理DB132から取得し、トポロジ取得方式ごとにトポロジ情報の集合を構成して、メモリ112に保存する。
ステップS3515において、トポロジ取得方式選択サブプログラムは、ステップS3514で取得したトポロジ情報の各集合の包含関係を算出する。この時、包含関係を算出するために比較する要素は、各々のトポロジ情報から抽出できる原因管理オブジェクトと影響管理オブジェクトとの組み合わせとする。
ステップS3516において、トポロジ取得方式選択サブプログラムは、最下位のトポロジ情報集合を取得したトポロジ取得方式の優先度を「1」とし、下位のトポロジ情報集合を取得した方式から順に優先度を設定する。
ステップS3517において、トポロジ取得方式選択サブプログラムは、表示モジュール125を起動し、各トポロジ取得方式に対応するトポロジ情報、イベントおよび優先度の組み合わせを出力デバイス117に表示する。
ステップS3518において、トポロジ取得方式選択サブプログラムは、ステップS3517の表示情報の中から、ルール作成者が各イベントに対して選択した一つのトポロジのトポロジ情報を受信する。
ステップS3519において、トポロジ取得方式選択サブプログラムは、ステップS3518で受信したトポロジ情報に対応するトポロジ取得方式の一覧を、トポロジ取得方式選択処理の呼び出し元プログラムに渡す。
なお、本実施例では、各トポロジ取得方式が取得できる全てのトポロジ情報を構成管理DB132から取得したが、処理を高速化するために、起点となるいくつかの管理オブジェクトを限定してトポロジ情報を取得することによって、取得するトポロジ情報の範囲を限定してもよい。このため、トポロジ情報の一部を部分的に検証することになり、処理を高速化することができる。
<方法3:レイヤを評価基準とした優先度決定方法>
トポロジ取得方式の優先度を決定する第3の方法は、レイヤを評価基準とする方法である。具体的には、関連テーブル133のエントリが示す関連が、いずれのレイヤの接続関係を表しているかを予め定義しておき、下位レイヤの関連を含むトポロジの情報を取得するトポロジ取得方式の優先度を下げる。
例えば、ネットワーク接続関係を示すトポロジの場合、「二つのサーバが物理的にスイッチを介して接続されている」という下位レイヤの接続関係を表すトポロジより、「二つのサーバ上のアプリケーションがTCP接続をして通信している」という上位レイヤの接続関係を表すトポロジの方が、一方のサーバの障害が他方のサーバに伝播する可能性が高い。
したがって、本実施例の第3の方法では、関連テーブルの各エントリが示す関連のレイヤの情報を登録し、レイヤの上位・下位の関係を定義する。そして、1組の影響管理オブジェクトから原因管理オブジェクトまでのトポロジを取得する方式として、複数のトポロジ取得方式が候補となった場合、各トポロジ取得方式が取得できるトポロジの関連に下位レイヤの関連が含まれている場合、トポロジ取得方式の優先度を下げる。
なお、本実施例では、下位レイヤの関連を含むトポロジ情報を取得するトポロジ取得方式の優先度を高くしたが、別の基準で関連を評価し、トポロジ取得方式を決定してもよい。
図36Aおよび図36Bは、第3の実施例の第3の方法の関連テーブル133のデータ構造の例を説明する図である。本実施例の関連テーブル133は、図36Aに示すエントリの下に、図36Bに示すエントリが続く構造である。
方法3の関連テーブル133は六つのフィールドを持つ。関連ID3601、テーブル名X3602、フィールド名X3603、テーブル名Y3604、フィールド名Y3605は、それぞれ、第1の実施例の関連テーブル(図15A、図15B)の関連ID1501、テーブル名X1502、フィールド名X1503、テーブル名Y1504、フィールド名Y1505と同じである。
レイヤ3606は、関連テーブル133の各エントリが示す構成管理DB132のテーブル間の関連のレイヤの情報である。すなわち、関連テーブル133の各エントリが示す関連がいずれのレイヤの接続関係であるかの情報である。なお、特にレイヤが設定されない関連があってもよい。
本実施例では、一例として、ストレージがサーバに論理ボリュームを提供するネットワークのレイヤを「レイヤA」「レイヤB」「レイヤC」の三つに分類した。「レイヤA」は物理的な接続関係を示す関連に、「レイヤB」はSCSIプロトコルによる通信関係を示す関連に、「レイヤC」は論理ボリュームをマウントする関係を示す関連に定義される。
例えば、エントリ3613は、サーバのディスクドライブとストレージの論理ボリュームの関連は「レイヤC」の接続関係であることを示す。エントリ3612のように一つの装置内で閉じる関連等については、ネットワーク接続関係を表していないため、レイヤ3606に値を格納しなくてよい。
本実施例では、各レイヤは「レイヤC」「レイヤB」「レイヤA」の順で優先度が高く設定される。
なお、関連テーブルのエントリが示す各々の関連に定義されるレイヤは、当該技術分野で公知のOSI参照モデルによって分類されたレイヤでもよい。
トポロジ取得方式選択処理では、受信した各トポロジ取得方式の方式ID1602に格納された全ての関連ID1501に対応する関連テーブル133のエントリを取得し、取得したエントリのレイヤ3606に「レイヤA」が格納されているトポロジ取得方式は優先度を「3」、「レイヤB」が格納されているトポロジ取得方式は優先度を「2」、それ以外は優先度を「1」と設定する。そして、図34Aおよび図34Bに示すトポロジ取得方式選択処理と同様に、ルール作成者に対して、各トポロジ取得方式に対応するトポロジ情報とイベントと優先度を表示することができる。
本実施例においては、関連についてレイヤを設定したが、管理オブジェクト種別についてレイヤを設定し、各トポロジ取得方式が取得できる管理オブジェクトの種別に基づいて優先度を設定してもよい。
以上に説明した方法3は、管理オブジェクトの関連についてレイヤの情報が設定されている場合に好適な方法である。
<方法4:既存のトポロジ取得方式を評価基準とした優先度決定方法>
トポロジ取得方式の優先度を決定する第4の方法は、既存のトポロジ取得方式を評価基準とする方法である。具体的には、1組の影響管理オブジェクトから原因管理オブジェクトまでのトポロジを取得する方式として、複数のトポロジ取得方式が候補となった場合、既にトポロジ取得方式リポジトリ134に格納されている方式と完全に一致する、または部分的に一致するトポロジ取得方式を優先する。
既に利用されているトポロジ取得方式は、他のメタルールにおいて障害が伝播するトポロジを取得する手段として定義されているため、新しく生成するメタルールが示す障害原因が伝播するトポロジとなる可能性が高いからである。
なお、本実施例では既存のトポロジ取得方式と一致する方式の優先度を高くしたが、別の基準によって既存のトポロジ取得方式との関係を評価し、トポロジ取得方式の優先度を決定してもよい。
二つのトポロジ取得方式が完全に一致する、または部分的に一致するとは、トポロジ取得方式1600の方式1602に格納される関連IDが全て等しい、または一部が等しいことでよい。また、一部が等しい場合に関しては、等しい関連IDの比率などで優先度を決定してもよい。
以上に説明した方法4は、他の方法より簡易な方法として有用である。
<方法5:過去のイベントとの関係を評価基準とした優先度決定方法>
トポロジ取得方式の優先度を決定する第5の方法は過去のイベントとの関係を評価基準とする方法である。具体的には、生成しようとしているメタルールに各トポロジ取得方式を対応付けた場合、イベントテーブル131および構成管理DB132に基づいて、当該メタルールを用いて過去のイベントを解析するシミュレーションを行い、メタルールと各トポロジ取得方式から展開ルールを生成した場合に、過去のイベントに対して過不足なく展開ルールを生成できている方式を優先する。
例えば、以下の処理によって、優先度を決定することができる。
当該メタルールのIF部に記述された条件要素が指定するイベントが所定の期間内に発生したイベント群をイベントテーブルから取得する。そして、当該イベント群が発生した各々の管理オブジェクトを起点として、トポロジ取得方式を用いてトポロジ情報を取得し、当該メタルールから展開ルール群を生成する。
当該イベント群の中に、生成した全ての展開ルールのIF部の条件要素が示すイベントに該当しないものがある場合、展開ルールが不足していると判定する。また、展開ルールの条件要素に当該イベント群に含まれないものがある場合、展開ルールが過剰であると判定する。各トポロジ取得方式に以上の処理を実行し、展開ルールの過不足が少ないものから順に優先度をつける。
以上の五つの方法によって、1組の影響管理オブジェクトから原因管理オブジェクトまでのトポロジ情報を取得する方式として、複数のトポロジ取得方式が候補となった場合、決定した各トポロジ取得方式の優先度を、トポロジ取得方式をメタルールに対応付けるかを判定するための情報として、ルール作成者に提示することができる。
例えば、第1の実施例のメタルール生成プログラム121のステップS1812の処理で原因イベントとして「StA RG1 WriteHitPerfError」を受信し、ステップS1816で影響イベントとして「SvA DRIVE1 AverageSecPerXferError」を受信した場合、ステップS1817で、コンポーネント「RG1」と「DRIVE1」と同じトポロジを取得するトポロジ取得方式として、以下の四つを取得できる。
(a)方式1602が「AS3,AS12」のトポロジ取得方式
(b)方式1602が「AS2,AS17,AS10,AS12」のトポロジ取得方式
(c)方式1602が「AS2,AS6,AS10,AS12」のトポロジ取得方式
(d)方式1602が「AS2,AS4,AS8,AS8,AS7,AS10,AS12」のトポロジ取得方式
ただし、図22Bに示す関連探索処理のステップS2219が利用する関連探索条件は、以下とする。
(x)同じ管理オブジェクトを辿る場合
(y)ストレージまたはサーバを辿った後、同じ装置内の別のコンポーネントを辿る場合
(z)ストレージまたはサーバのコンポーネントから別のストレージまたはサーバのコンポーネントを辿った後に、さらに別の装置のコンポーネントを辿る場合
取得した四つのトポロジ取得方式を、第1の方法によってトポロジ取得方式選択処理で優先度を設定する場合、ステップS3414の処理において(a)の方式は、取得した多重度情報が「1対1」「多対1」の順となるため、優先度が「1」に設定される。同様に、(b)の方式は、取得した多重度情報が「多対1」「多対多」「1対多」「多対1」の順となり、「多対多」を含むため、優先度が「3」に設定される。(c)の方式も、取得した多重度情報が「多対1」「多対多」「1対多」「多対1」の順となり、「多対多」を含むため、優先度は「3」が設定される。(d)の方式は、取得した多重度情報が「多対1」「1対1」「多対1」「1対多」「1対1」「1対多」「多対1」の順となり、「多対1」「1対多」の並びを含むため、優先度が「3」に設定される。
図4から図13に示す構成管理DB132から、トポロジ取得方式(a)で取得できるトポロジに基づいて、図3に示すメタルール300から展開ルールを生成すると、図17Aから図17Cに示す三つの展開ルールが生成される。方式(a)は「RAIDグループを分割した論理ボリュームをマウントしているディスクドライブ」というトポロジを取得しており、「RAIDグループの書込処理のヒット率性能エラー」が原因で「ディスクドライブの転送時間性能エラー」を引き起こす関係のRAIDグループおよびディスクドライブのみを抽出し、展開ルールを生成することができる。
また、例えば、トポロジ取得方式(d)を利用してメタルール300から展開ルールを生成した場合、RAIDグループおよびFCスイッチを介してストレージと接続し、外部ボリュームをマウントしているディスクドライブとの全ての組み合わせを取得して、展開ルールを生成する。そのため、図17Aから図17Cに示す展開ルールに加えて、図37Aから図37Fに示す展開ルールも含めた合計9つの展開ルールが生成される。
図37Aから図37Fに示す展開ルールには、実際の管理対象システムにおいて発生し得ないイベントの組み合わせが記述されているため、不要な展開ルールである。また、偶然IF部に記述されたイベントが同時に発生した場合には、誤った原因候補をイベント受信率100%の原因候補として提示し、かつ、誤った障害の影響範囲を提示することになる。したがって、メタルールを適用する範囲として適切なトポロジを取得する方式(a)の優先度を高くし、ルール作成者に提示することができる。このため、発生しているパターンを利用することによって、精度を向上することができる。
なお、本実施例では優先度を決定するための五つの方法を説明したが、これらの一つのみを利用してもよいし、複数を組み合わせて、各方法の優先度をルール作成者に提示してもよい。また、各方法で算出した優先度の値を加算または乗算し、総合的な優先度として表示してもよい。
また、本実施例では、ルール作成者の1回の入力に対応してトポロジ取得方式の優先度を決定し、一つのメタルールを生成したが、一つのメタルールに対応して同じ管理オブジェクト種別およびイベント種別を持つ別のイベントを数回入力してもよい。そして、それら影響イベントおよび原因イベントの全ての組み合わせが表すトポロジのパターンの共通の特徴を抽出して、メタルールに対応付けるトポロジ取得方式の優先度を決定し、優先度の精度を高めてもよい。
また、本実施例では1組の影響管理オブジェクトから原因管理オブジェクトまでのトポロジを取得する一つの方式を決定したが、候補となった複数のトポロジ取得方式の優先度を記録して、発生した障害イベントを優先度の高いものから順に利用してトポロジ情報を取得し、ある方式でトポロジ情報が取得できなかった場合、優先度が次の方式を利用してもよい。
また、本実施例では、各トポロジ取得方式の優先度をルール作成者に提示したが、優先度が最も高い方式をメタルールに対応付ける方式として自動的に決定してもよい。
また、本実施例では、トポロジ探索処理によって原因管理オブジェクトおよび影響管理オブジェクト間でとり得る全てのトポロジの情報と、当該トポロジに対応するトポロジ取得方式を導出して、優先度を決定する。これに対し、探索中のトポロジ情報およびトポロジ取得方式が、既に導出したトポロジ取得方式より優先度が低くなった時点で探索処理を中断してもよい。
以上に説明したように、本発明の第3の実施例によれば、トポロジ取得方式に優先度を設定して、設定された優先度をルール作成者に提示することによって、ルール作成者がメタルールに対応付けるトポロジ取得方式を選択する作業を支援し、作業コストを削減することができる。
以上、本発明を添付の図面を参照して詳細に説明したが、本発明はこのような具体的構成に限定されるものではなく、添付した請求の範囲の趣旨内における様々な変更および同等の構成を含むものである。