(57)【特許請求の範囲】
【請求項１】
管理プログラムを格納した記憶資源と、
前記管理プログラムを実行するプロセッサと、
を含む、複数の管理対象計算機を管理する管理計算機であって、
前記記憶資源は、
（１）前記複数の管理対象計算機又は前記複数の管理対象計算機が含む複数のコンポーネントである複数の管理オブジェクトに関し、前記複数の管理オブジェクト同士の関係を示すトポロジと、
（２）イベント種別及びイベントが発生する管理オブジェクトの種別によって定義される、イベントと当該イベント発生原因となる原因イベントとの組の情報を含むイベント伝播モデルと、
（３）一つ以上の因果律を含む因果律情報と、
を格納し、
前記因果律とは、種別が種別１である第１の管理オブジェクトで発生する、種別が種別Ａである第１のイベントが原因で、種別が種別２である第２の管理オブジェクトで種別が種別Ｂである第２のイベントが発生すること、を示し、
前記管理プログラムは、前記プロセッサに、
（Ａ）所定の管理オブジェクトで発生した問題に関するイベントを検知させ、
（Ｂ）前記検知イベントの解析に用いる第１の因果律が前記因果律情報に生成済みか判断させ、
（Ｃ）（Ｂ）で未生成と判断した場合、前記トポロジと前記イベント伝播モデルに基づいて前記第１の因果律を前記因果律情報に生成するオンデマンド展開をさせ、
（Ｄ）前記第１の因果律を用いて、前記検知イベントを解析させ、
（Ｉ）（Ａ）で検知したイベントが構成変更である場合、前記第１の因果律を削除させる、
ことを特徴とした管理計算機。
【請求項２】
請求項１記載の管理計算機であって、
前記管理プログラムは、前記プロセッサに、前記第１の因果律が削除された後、前記検知イベントのうち、構成変更でなく、かつ、イベントの有効期間が満了していないイベントに関してオンデマンド展開をさせる、
ことを特徴とした管理計算機。
【請求項３】
複数の管理対象計算機を管理する記憶資源を含む管理計算機によるイベント解析方法であって、
前記記憶資源に、
（１）前記複数の管理対象計算機又は前記複数の管理対象計算機が含む複数のコンポーネントである複数の管理オブジェクトに関し、前記複数の管理オブジェクト同士の関係を示すトポロジと、
（２）イベント種別及びイベントが発生する管理オブジェクトの種別によって定義される、イベントと当該イベント発生原因となる原因イベントとの組の情報を含むイベント伝播モデルと、
（３）一つ以上の因果律を含む因果律情報と、
を格納し、
前記因果律とは、種別が種別１である第１の管理オブジェクトで発生する、種別が種別Ａである第１のイベントが原因で、種別が種別２である第２の管理オブジェクトで種別が種別Ｂである第２のイベントが発生すること、を示し、
（Ａ）所定の管理オブジェクトで発生した問題に関するイベントを検知し、
（Ｂ）前記検知イベントの解析に用いる第１の因果律が前記因果律情報に生成済みか判断し、
（Ｃ）（Ｂ）で未生成と判断した場合、前記トポロジと前記イベント伝播モデルに基づいて前記第１の因果律を前記因果律情報に生成するオンデマンド展開し、
（Ｄ）前記第１の因果律を用いて、前記検知イベントを解析し、
（Ｉ）（Ａ）で検知したイベントが構成変更である場合、前記第１の因果律を削除する、
ことを特徴とした方法。
【請求項４】
請求項３記載の方法であって、
前記第１の因果律が削除された後、前記検知イベントのうち、構成変更でなく、かつ、イベントの有効期間が満了していないイベントに関してオンデマンド展開をする、
ことを特徴とした方法。
【請求項５】
複数の管理対象計算機と、
前記複数の管理対象計算機を管理し、記憶資源を有する管理計算機と、
を有する計算機システムであって、
前記記憶資源は、
（１）前記複数の管理対象計算機又は前記複数の管理対象計算機が含む複数のコンポーネントである複数の管理オブジェクトに関し、前記複数の管理オブジェクト同士の関係を示すトポロジと、
（２）イベント種別及びイベントが発生する管理オブジェクトの種別によって定義される、イベントと当該イベント発生原因となる原因イベントとの組の情報を含むイベント伝播モデルと、
（３）一つ以上の因果律を含む因果律情報と、
を格納し、
前記因果律とは、種別が種別１である第１の管理オブジェクトで発生する、種別が種別Ａである第１のイベントが原因で、種別が種別２である第２の管理オブジェクトで種別が種別Ｂである第２のイベントが発生すること、を示し、
前記管理計算機は、
（Ａ）所定の管理オブジェクトで発生した問題に関するイベントを検知し、
（Ｂ）前記検知イベントの解析に用いる第１の因果律が前記因果律情報に生成済みか判断し、
（Ｃ）（Ｂ）で未生成と判断した場合、前記トポロジと前記イベント伝播モデルに基づいて前記第１の因果律を前記因果律情報に生成するオンデマンド展開し、
（Ｄ）前記第１の因果律を用いて、前記検知イベントを解析し、
（Ｉ）（Ａ）で検知したイベントが構成変更である場合、前記第１の因果律を削除する、
ことを特徴とした計算機システム。
【請求項６】
請求項５記載の計算機システムであって、
前記管理計算機は、前記第１の因果律が削除された後、前記検知イベントのうち、構成変更でなく、かつ、イベントの有効期間が満了していないイベントに関してオンデマンド展開をする、
ことを特徴とした計算機システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、計算機システム管理するプログラムに関する。
【背景技術】
【０００２】
特許文献１には、計算機システムの管理対象コンポーネントで発生した問題の原因を決定する管理サーバが開示されている。より具体的には特許文献１の管理プログラムは、管理対象装置における各種障害をイベント化し、イベントＤＢに情報を蓄積する。また、この管理プログラムは、管理対象装置において発生した複数の障害イベントの因果関係を解析するための解析エンジンを持っている。
【０００３】
解析エンジンは、管理対象装置のインベントリ情報を持つ構成ＤＢにアクセスして、Ｉ／Ｏ系路上のパス上にある管理対象装置内のコンポーネントを１グループとして認識する。なお、管理対象装置内又は管理対象装置に跨る複数の当該装置または装置内のコンポーネント間の関係をトポロジと呼ぶ。そして、この解析エンジンは前記トポロジに対し、事前に定められた条件文と解析結果からなる障害伝播モデル（ＩＦ−ＴＨＥＮ形式ルール）を適用して因果律行列を構築する。
【０００４】
因果律行列には、他装置における障害の原因である原因イベントと、それによって引き起こされている関連イベント群が含まれる。具体的には、障害伝播モデルのＴＨＥＮ部に障害の根本原因として記載されているイベントが原因イベント、ＩＦ部に記載されているイベントのうち原因イベント以外のものが関連イベントである。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】米国特許７１０７１８５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
特許文献１公開の技術では、管理対象の全ての装置及び全ての障害伝播モデルに基づいて、イベント解析前に因果律行列を作成する。そのため、大規模又は多数の障害伝播モデルが必要な複雑な計算機システムを解析する際の因果律行列のサイズが大きくなり、管理計算機の記憶資源（例えば、メモリ又は／及び二次記憶装置）を大量に消費していた。
【課題を解決するための手段】
【０００７】
以上の課題を解決するため、計算機システムを管理する管理計算機は、記憶資源にトポロジと、イベント伝播モデルと、一つ以上の因果律を含む因果律情報と、を格納し、管理計算機がイベントを解析又は検知した契機で、解析対象イベントに対応する所定の因果律が作成済みか否か判断し、未作成の場合はトポロジとイベント伝播モデルとに基づいて前記所定の因果律を作成する。なお、因果律情報の一例が上記因果律行列である。
【発明の効果】
【０００８】
上記手段によれば、より少ない管理計算機の記憶資源でより大規模又は多数の障害伝播モデルが必要な複雑な計算機システムを解析することができる。
【図面の簡単な説明】
【０００９】
【図１】計算機システムの物理構成例を示す図である。
【図２】ホストコンピュータの詳細な構成例を示す図である。
【図３】ストレージ装置の詳細な構成例を示す図である。
【図４】管理サーバの詳細な構成例を示す図である。
【図５】ＩＰスイッチの詳細な構成例を示す図である。
【図６Ａ】ホストコンピュータが含む論理ボリューム管理表の構成例を示す図である。
【図６Ｂ】ホストコンピュータが含む論理ボリューム管理表の構成例を示す図である。
【図６Ｃ】ホストコンピュータが含む論理ボリューム管理表の構成例を示す図である。
【図７】ストレージ装置が含むボリューム管理表の構成例を示す図である。
【図８Ａ】ストレージ装置が含むｉＳＣＳＩターゲット管理表の構成例を示す図である。
【図８Ｂ】ストレージ装置が含むｉＳＣＳＩターゲット管理表の構成例を示す図である。
【図９】ストレージ装置が含むＩ／Ｏポート管理表の構成例を示す図である。
【図１０】ストレージ装置が含むＲＡＩＤグループ管理表の構成例を示す図である。
【図１１】ストレージ装置が含むディスク管理表の構成例を示す図である。
【図１２】管理サーバが含むイベント管理表の構成例を示す図である。
【図１３Ａ】管理サーバが含むイベント伝播モデルの構成例を示す図である。
【図１３Ｂ】管理サーバが含むイベント伝播モデルの構成例を示す図である。
【図１４Ａ】管理サーバが含む因果律行列の構成例を示す図である。
【図１４Ｂ】管理サーバが含む因果律行列の構成例を示す図である。
【図１４Ｃ】管理サーバが含む因果律行列の構成例を示す図である。
【図１４Ｄ】管理サーバが含む因果律行列の構成例を示す図である。
【図１４Ｅ】管理サーバが含む因果律行列の構成例を示す図である。
【図１５Ａ】管理サーバが含むトポロジ生成方式の構成例を示す図である。
【図１５Ｂ】管理サーバが含むトポロジ生成方式の構成例を示す図である。
【図１６】管理サーバが実行する装置情報取得処理の全体フロー例を示すフローチャートである。
【図１７】管理プログラムの論理的構成例を示した図である。
【図１８】管理サーバが含む展開対象イベント伝播モデル管理表の構成例を示す図である。
【図１９】管理サーバが実行するイベント確認処理の全体フロー例を示すフローチャートである。
【図２０】管理サーバが実行するイベント伝播モデルオンデマンド展開処理の全体フロー例を示すフローチャートである。
【図２１】管理サーバが実行するイベント伝播モデル再展開処理の全体フロー例を示すフローチャートである。
【図２２】管理サーバが含む展開済イベント管理表の構成例を示す図である。
【図２３】管理サーバが含む展開済起点コンポーネント管理表の構成例を示す図である。
【図２４Ａ】実施例２において管理サーバが実行するイベント伝播モデルオンデマンド展開処理の全体フロー例を示すフローチャートである。
【図２４Ｂ】実施例２において管理サーバが実行するイベント伝播モデルオンデマンド展開処理の全体フロー例を示すフローチャートである。
【図２５】実施例３において管理サーバが含むイベント伝播モデル管理表の構成例を示す図である。
【図２６】実施例３において管理サーバが実行するイベント伝播モデルオンデマンド展開処理の全体フロー例を示すフローチャートである。
【図２７】実施例の概要を説明した模式図である。
【図２８】実施例３において管理サーバが実行するイベント伝播モデル再展開処理の全体フロー例を示すフローチャートである。
【図２９】計算機システムの別な物理構成例を示す図である。
【発明を実施するための形態】
【００１０】
以下、図面を参照して、実施例を説明する。なお、以後の説明では「ａａａテーブル」、「ａａａリスト」、「ａａａＤＢ」、「ａａａキュー」、「ａａａ行列」等の表現にて実施例の情報を説明するが、これら情報は必ずしもテーブル、リスト、ＤＢ、キュー、行列、等のデータ構造以外で表現されていてもよい。そのため、データ構造に依存しないことを示すために「ａａａテーブル」、「ａａａリスト」、「ａａａＤＢ」、「ａａａキュー」、「ａａａリポジトリ」、「ａａａ行列」等について「ａａａ情報」と呼ぶことがある。さらに、各情報の内容を説明する際に、「識別情報」、「識別子」、「名」、「名前」、「ＩＤ」という表現を用いるが、これらについてはお互いに置換が可能である。さらに、データ内容を示すために「情報」という表現を用いているが、他の表現形式であってもよい。なお、実施例の説明において「リポジトリ」という用語を用いるが、「情報」と同じ意味である。
【００１１】
以後の説明では「プログラム」を主語として説明を行う場合があるが、プログラムはプロセッサによって実行されることで定められた処理をメモリ及び通信ポート（通信制御装置）を用いながら行うため、プロセッサを主語とした説明としてもよい。また、プログラムを主語として開示された処理は管理サーバ又はストレージシステム等の計算機、情報処理装置が行う処理としてもよい。また、プログラムの一部または全ては専用ハードウェアによって実現されてもよい。また、各種プログラムはプログラム配布サーバ（各種プログラムのインストールイメージを記憶する記憶資源と、配布処理を実施するＣＰＵとから構成）や記憶メディアによって各計算機にインストールされてもよい。
【００１２】
図２７は実施例１の概要を示した図である。管理サーバ３００００は、複数の管理対象装置１００００を管理する計算機である。管理対象装置の種別としては例えば、ホストコンピュータ、ＩＰスイッチやルータ等のネットワーク装置、あるいはＮＡＳやストレージ装置等がある。なお、管理対象装置が含むデバイス等の論理的又は物理的な構成物をコンポーネントと呼ぶ。コンポーネントの例としてはポート、プロセッサ、記憶資源、記憶デバイス、プログラム、仮想マシン、ストレージ装置内部で定義される論理ボリューム、ＲＡＩＤグループ等がある。なお、管理対象装置とコンポーネントを区別せずに扱う場合は管理オブジェクトと呼ぶ。
【００１３】
管理サーバ３００００は、これら管理対象装置の構成情報、障害又は性能を示す情報等の装置情報を取得し、取得した装置情報に基づいて、管理対象装置の管理情報（例えば構成情報、障害発生の有無、性能値等）を表示する。
【００１４】
なお、いくつかの管理対象装置は何かしらのネットワークサービス（例えば、ｉＳＣＳＩやファイル共有サービス、ＤＮＳ、その他Ｗｅｂサービス）のサーバであり、又他のいくつかの管理対象装置はクライアントとしてこれらサーバが提供するネットワークサービスを利用する。この場合、サーバである管理対象装置（サーバ）でサービス提供に関係する問題（例えば管理オブジェクトの障害や性能障害等）が発生すると当該サービスを利用しているクライアント管理対象装置（クライアント装置と呼ぶことがある）でも管理オブジェクトに関する問題が発生する。
【００１５】
なお、以後の説明では管理オブジェクトで発生した問題を管理サーバで示す情報をイベントと呼ぶ。また、「イベントの検知」とは「問題の発生を検知し、イベント情報を作成すること」を意味する。なお、「イベントの発生」は「問題の発生」と同じ意味である。
【００１６】
管理サーバ３００００は、ある管理対象装置で発生した問題の原因が別な管理対象装置で発生した問題であることを解析し、表示することができる。そのために管理サーバ３００００は以下の情報を格納し、解析に用いる。
【００１７】
＊  構成情報。管理対象装置の構成（インベントリとも呼ばれる）を示す情報を格納する。なお、構成情報には管理対象装置が含むコンポーネントや、コンポーネント同士の対応関係といった管理オブジェクト間の対応関係が含まれる。また、構成情報には、クライアント装置に関して、ネットワークサービスを受けるためのサーバ装置（またはサーバ装置のコンポーネント）の識別情報が含まれる。例えば、後述するｉＳＣＳＩプロトコルによるボリューム提供がネットワークサービスであれば、識別情報としてｉＳＣＳＩターゲット名とＬＵＮを指定し、ストレージ装置が提供するボリュームにアクセスする。その他、Ｗｅｂであれば、識別情報としてＷｅｂサーバの名前を含むＵＲＬを指定し、Ｗｅｂページにアクセスする。
【００１８】
なお、構成情報にはサーバ装置に関して、アクセス元となるクライアント装置に関する識別情報を含む場合もある。このような管理対象装置内又は複数の管理対象装置に跨る複数の管理オブジェクト間の関係をトポロジと呼ぶ。
【００１９】
＊  一つ以上のイベント伝播モデルの情報（以後、単にイベント伝播モデルと呼ぶ）。本情報は、一つ以上の観測種別ペアと原因種別ペアが含まれる。より詳細としては以下である。
【００２０】
原因種別ペア：管理オブジェクトの種別（管理オブジェクト原因種別と呼ぶことがある）と、イベントの種別（イベント原因種別）のペアである。イベント原因種別は、管理オブジェクト原因種別で定められる種別の管理オブジェクトで発生する可能性のあるイベントの種別である。
【００２１】
観測種別ペア：管理オブジェクトの種別（管理オブジェクト観測種別と呼ぶことがある）と、イベントの種別（イベント観測種別）のペアである。イベント観測種別は、管理オブジェクト観測種別で定められる種別の管理オブジェクトで発生する可能性のあるイベントの種別である。観測種別ペアは、原因種別ペアで定められるイベントが発生した場合に、合わせて発生するイベントの種別を示す。
【００２２】
なお、あるイベント伝播モデルに含まれる観測種別ペアのイベントを全て検知した場合に、対応する原因種別ペアのイベント発生が原因であるほうがより好ましいが、必須ではない。
【００２３】
管理サーバ３００００による解析処理は、より具体的にはイベント伝播モデルとトポロジに基づいて因果律を因果律情報に作成し、その上でイベントの解析を行う。なお、因果律とは、第１の管理オブジェクトで第１のイベントが発生した場合は、第２の管理オブジェクトで発生した第２のイベントが発生することを示す情報である。なお、第１のイベントが原因であると断定できる条件が、第１のイベントに関連した全ての第２イベントを検知すること、であるほうが望ましい。ただしこれは必須ではない。因果律情報は上記内容を示すことが出来れば、因果律行列の形式であってもよく、又は関係を示すポインタ情報を駆使して第１のイベントと第２のイベントとの関係を示したデータ構造であってもよい。
【００２４】
管理サーバ３００００は、オンデマンドで因果律を作成する。つまり、管理サーバ３００００は検知したが未解析である所定のイベントに対応する因果律が因果律情報に作成済みか否か判断し、未作成の場合は所定のイベントが関係するトポロジと、所定のイベントが関係するイベント伝播モデルと、を用いて因果律を作成し、そして所定のイベントの解析を行う。
【００２５】
イベント解析の例としては以下が考えられる。
【００２６】
＊  検知したあるイベント１の原因となるイベント２を特定する。この特定処理は因果律情報を参照することで可能である。なお、管理サーバ（または後述する管理システム）は自身の表示デバイスにイベント１の情報と共に、イベント２が原因で当該イベントが発生した旨のメッセージを表示してもよい。
【００２７】
＊  検知したあるイベント３を原因として発生する（またはする可能性がある）イベント４を求める。この特定処理は因果律情報を参照することで可能である。なお、管理サーバ（または後述する管理システム）は自身の表示デバイスに、イベント４がイベント３の発生が原因で発生する（またはする可能性がある）旨のメッセージを表示してもよい。
【００２８】
管理サーバ３００００は、イベントを検知した後に、検知イベントと関係する所定の因果律が因果律情報に作成済みか判断し、作成されていない場合は（１）検知イベントを観測種別ペア又は原因種別ペアに含むイベント伝播モデルと、（２）検知イベントが発生したコンポーネントと関係するトポロジと、に基づいて所定の因果律を因果律情報に作成する（後ほどの説明では因果律を展開するとも言う）。なお、このようなイベント検知を契機とした因果律の展開をオンデマンド展開と呼ぶ。オンデマンド展開によって大規模な計算機システムや複雑な計算機システムを対象にしたイベント解析でも因果律情報のサイズをより少なくできる。
【００２９】
管理サーバ３００００が管理対象装置の構成変更、追加、又は削除を検知した場合、いずれかのトポロジが更新、追加、又は削除される場合がある。管理サーバ３００００は更新又は削除されたトポロジに基づいて作成された因果律を因果律情報から削除する。その後、更新されたトポロジに関連する因果律についてはオンデマンド展開で作成される。なお、追加されたトポロジについては前述のオンデマンド展開で因果律を作成する。
【００３０】
解析開始から長時間経過すると、様々な管理オブジェクトから様々な種別のイベントを検知する傾向にある。この場合、因果律情報のサイズがオンデマンド展開によって大きくなる。そのため、管理サーバ３００００は、イベントに有効期間を与え、有効期間を過ぎたイベントは解析対象から外し、そして有効期間を過ぎたイベントに関係する因果律を因果律情報から削除してもよい。このようにすることで因果律情報のサイズを少なくすることが出来る。
【００３１】
図２７の例では、コンポーネント１（種別ａ）で発生するイベントＡ１（種別Ａ）の原因がコンポーネント２（種別ｂ）で発生するイベントＢ２（種別Ｂ）であるイベントコリレーション１が作成済みの状況で、コンポーネント３（種別ａ）でイベントＡ３（種別Ａ）を実際に検知した場合の概要を示している。なお、イベントコリレーション１は過去にイベントＡ１を検知したときを契機に、トポロジ１とイベント伝播モデル１に基づいて過去にオンデマンド作成したものである。この状況では、コンポーネント３（種別ａ）で発生するイベントＡ３（種別Ａ）の原因がコンポーネント２（種別ｂ）で発生するイベントＢ２（種別Ｂ）であるイベントコリレーション２を、トポロジ２とイベント伝播モデル１に基づいてオンデマンドに作成する。
【００３２】
なお、上記因果律の削除契機としては例えば以下があるが、他の契機であってもよい。
【００３３】
＊  管理プログラムが管理対象装置の構成変更を検知したとき。
【００３４】
＊  所定のインターバルに基づいた繰り返し処理として、削除を実行。
【００３５】
なお、オンデマンド展開はイベント解析時に因果律を作成するため、解析時の負荷が増大する。そのため、特定のイベント伝播モデル、又は特定の管理オブジェクトについては事前に因果律を展開してもよい。なお、事前に因果律を展開する場合を事前展開と呼ぶ。事前の例としては例えば、（１）管理プログラムが起動し、イベントを検知する前、又は（２）管理プログラムが管理対象装置の構成変更を検知し、その後最初のイベントを検知する前、が考えられる。ただし、事前とはイベント検知より前であれば他のタイミングでもよい。事前展開対象とするイベント伝播モデル又は管理オブジェクトの特定方法としては、（１）これらの識別子を事前にユーザに設定してもらう方法、（２）管理オブジェクトの種別を条件として特定する、又は（３）イベント伝播モデルに含まれる管理オブジェクトの種別又はイベント種別を条件として特定する、といった例が考えられるが他の方法でもよい。
【００３６】
因果律作成済み判断又は因果律展開の際、イベント伝播モデルの個々をアクセスしてイベントとの関係性を判断しているとモデル数に比例して時間がかかる。そのため、管理サーバ３００００は、管理オブジェクトの種別とそこで発生するイベントの種別のペアから、当該ペアを原因種別ペア又は観測種別ペアに含むイベント伝播モデルのＩＤを特定可能なデータ構造を事前に作成し、判断に参照してもよい。
【００３７】
以上が本実施例の概要である。以後の記載では以下の場合を例示するが、本発明はこれに限定されないことはいうまでもない。
【００３８】
＊  ネットワークサービス：ｉＳＣＳＩプロトコルによるストレージアクセス。クライアント装置がホストコンピュータで、サーバ装置がストレージ装置。
【００３９】
＊  因果律情報：因果律行列。
【００４０】
＊  管理対象装置：  ホストコンピュータ、ＩＰスイッチ、ストレージ装置。
【００４１】
＊  管理オブジェクト：コンポーネント。
【００４２】
＊  コンポーネント：ｉＳＣＳＩターゲット、ボリューム、ＲＡＩＤグループ、ディスク、ホストコンピュータのドライブ名。
【００４３】
＊  因果律の削除契機：  構成変更の検知。
【実施例１】
【００４４】
図１から図５は計算機システムの構成および計算機システムに接続される装置の構成を示し、図６から図１５は各装置に具備される管理情報を示す。
【００４５】
図１は、計算機システムの物理的構成を示す図である。当該計算機システムは、ストレージ装置２００００と、ホストコンピュータ１００００と、管理サーバ３００００と、ＷＥＢブラウザ起動サーバ３５０００と、ＩＰスイッチ４００００と、を有し、それらが、ネットワーク４５０００によって接続される構成となっている。
【００４６】
ホストコンピュータ１００００乃至１００１０は、例えば、それらに接続された、図示しないクライアントコンピュータからファイルのＩ／Ｏ要求を受信し、それに基づいてストレージ装置２００００乃至２００１０へのアクセスを実現する。また、管理サーバ（管理計算機）３００００は、当該計算機システム全体の運用を管理するものである。
【００４７】
ＷＥＢブラウザ起動サーバ３５０００は、ネットワーク４５０００を介して、管理サーバ３００００のＧＵＩ表示処理モジュール３２３００と通信し、ＷＥＢブラウザ上に各種情報を表示する計算機である。ユーザはＷＥＢブラウザ起動サーバ上のＷＥＢブラウザに表示された情報を参照することで、計算機システム内の装置を管理する。ただし、管理サーバ３００００と、ＷＥＢブラウザ起動サーバ３５０００は１台のサーバから構成されていてもよい。
【００４８】
また、図２９に示すように計算機システム上に管理サーバ３００００が複数台存在し、ストレージ装置２００００、ホストコンピュータ１００００、管理サーバ３００００といった管理対象装置を分担して管理してもよい。
【００４９】
図２は、実施例によるホストコンピュータ１００００の詳細な内部構成例を示す図である。ホストコンピュータ１００００は、ネットワーク４５０００に接続するためのポート１１０００と、プロセッサ１２０００と、メモリ１３０００（ディスク装置を含んでも良い）と、を有し、これらは内部バス等の回路を介して相互に接続される構成となっている。
【００５０】
メモリ１３０００には、業務アプリケーション１３１００と、オペレーティングシステム１３２００と、論理ボリューム管理表１３３００と、が格納される。
【００５１】
業務アプリケーション１３１００は、オペレーティングシステム１３２００から提供された記憶領域を使用し、当該記憶領域に対しデータ入出力（以下、Ｉ／Ｏと表記）を行う。
【００５２】
オペレーティングシステム１３２００は、ネットワーク４５０００を介してホストコンピュータ１００００に接続されたストレージ装置２００００乃至２００１０上の論理ボリュームを記憶領域として業務アプリケーション１３１００に認識させるための処理を実行する。
【００５３】
ポート１１０００は、ストレージ装置２００００とｉＳＣＳＩにより通信を行うためのＩ／Ｏポートと、管理サーバ３００００がホストコンピュータ内の管理情報を取得するための管理ポートを含む単一のポートとして図２で表現されているが、ｉＳＣＳＩにより通信を行うためのＩ／Ｏポートと管理ポートに分かれていてもよい。
【００５４】
図３は、実施例によるストレージ装置２００００の詳細な内部構成例を示す図である。ストレージ装置２００１０も同様の構成を有している。
【００５５】
ストレージ装置２００００は、ネットワーク４５０００を介してホストコンピュータ１００００に接続するためのＩ／Ｏポート２１０００及び２１０１０と、ネットワーク４５０００を介して管理サーバ３００００に接続するための管理ポート２１１００と、各種管理情報を格納するための管理メモリ２３０００と、データを格納するためのＲＡＩＤグループ２４０００乃至２４０１０と、データや管理メモリ内の管理情報を制御するためのコントローラ２５０００及び２５０１０と、を有し、これらが内部バス等の回路を介して相互に接続される構成となっている。なお、ＲＡＩＤグループ２４０００乃至２４０１０の接続とは、より正確にはＲＡＩＤグループ２４０００乃至２４０１０を構成する記憶デバイスが他の構成物と接続されていることを指す。
【００５６】
管理メモリ２３０００には、ストレージ装置の管理プログラム２３１００と、ボリューム管理表２３２００と、ｉＳＣＳＩターゲット管理表２３３００と、Ｉ／Ｏポート管理表２３４００と、ＲＡＩＤグループ管理表２３５００と、ディスク管理表２３６００と、が格納される。管理プログラムは管理ポート２１１００を経由して管理サーバ３００００と通信し、管理サーバに対しストレージ装置２００００の構成情報を提供する。
【００５７】
ＲＡＩＤグループ２４０００乃至２４０１０は、それぞれ、１つまたは複数の磁気ディスク２４２００、２４２１０、２４２２０、及び２４２３０によって構成されている。複数の磁気ディスクによって構成されている場合、それらの磁気ディスクはＲＡＩＤ構成を組んでいてもよい。また、ＲＡＩＤグループ２４０００乃至２４０１０は、論理的に複数のボリューム２４１００乃至２４１１０に分割されている。
【００５８】
なお、論理ボリューム２４１００及び２４１１０は、１つ以上の磁気ディスクの記憶領域を用いて構成されるのであれば、ＲＡＩＤ構成を編成しなくてもよい。さらに、論理ボリュームに対応する記憶領域を提供するのであれば、磁気ディスクの代わりとしてフラッシュメモリなど他の記憶媒体を用いた記憶デバイスでも良いものとする。
【００５９】
コントローラ２５０００及び２５０１０は、その内部に、ストレージ装置２００００内の制御を行うプロセッサや、ホストコンピュータ１００００との間でやりとりするデータを一時的に記憶するキャッシュメモリを持っている。そして、それぞれのコントローラは、Ｉ／ＯポートとＲＡＩＤグループの間に介在し、両者の間でデータの受け渡しを行う。
【００６０】
なお、ストレージ装置２００００は、何れかのホストコンピュータに対して論理ボリュームを提供し、アクセス要求（Ｉ／Ｏ要求を指す）を受信し、受信したアクセス要求に応じて記憶デバイスへの読み書きを行うストレージコントローラと、記憶領域を提供する前述の記憶デバイスを含めば、図３及び上記説明以外の構成でもよく、例えば、ストレージコントローラと記憶領域を提供する記憶デバイスが別な筐体に格納されていてもよい。即ち、図３の例では管理メモリ２３０００と、コントローラ２５０００及び２５１１０と、がストレージコントローラであってもよい。また、本明細書ではストレージコントローラと記憶デバイスが同じ筐体に存在する場合または別な筐体を含む表現として、ストレージ装置をストレージシステムと呼び変えても良い。
【００６１】
図４及び図１７は、実施例による管理サーバ３００００の詳細な内部構成例を示す図である。管理サーバ３００００は、ネットワーク４５０００に接続するための管理ポート３１０００と、プロセッサ３１１００と、記憶資源３３０００と、後述する処理結果を出力するためのディスプレイ装置等の出力デバイス３１２００と、ストレージ管理者が指示を入力するためのキーボード等の入力デバイス３１３００とを有し、これらが内部バス等の回路を介して相互に接続される構成となっている。なお、記憶資源３３０００は、半導体メモリ又は記憶デバイス、又はこれらを混在させた記憶資源である。
【００６２】
記憶資源３３０００には管理プログラム３２０００が格納される。図１７のように管理プログラム３２０００は、プログラム制御モジュール３２１００と、装置情報取得モジュール３２２００と、ＧＵＩ表示処理モジュール３２３００と、イベント解析処理モジュール３２４００と、イベント伝播モデル展開モジュール３２５００と、を含む。なお、各モジュールは、メモリ３２０００のプログラムモジュールとして提供されているが、ハードウェアモジュールとして提供されるものであっても良い。また、管理プログラム３２０００は各モジュールの処理を実現できるのであれば、モジュールによって構成されなくてもよい。言い方を変えれば、以下の説明における各モジュールについての説明は管理プログラム３２０００に関する説明と置き換えてもよいということである。
【００６３】
記憶資源３３０００はさらに、イベント管理表３３１００と、イベント伝播モデルリポジトリ３３２００と、因果律行列３３３００と、トポロジ生成方式リポジトリ３３４００と、構成ＤＢ３３５００と、展開対象イベント伝播モデル管理表３３６００と、展開済イベント管理表３３７００と、展開済起点コンポーネント管理表３３８００と、イベント伝播モデル管理表３３９００と、が格納されている。構成ＤＢ３３５００には構成情報が格納される。
【００６４】
構成情報の例としては、装置情報取得モジュール３２２００が管理対象の各ホストコンピュータから収集してきた論理ボリューム管理表１３３００の各項目と、管理対象の各ストレージから収集してきたボリューム管理表２３２００の各項目と、ｉＳＣＳＩターゲット管理表２３３００各項目と、Ｉ／Ｏポート管理表２３４００各項目と、ＲＡＩＤグループ管理表２３５００各項目と、ディスク管理表２３６００各項目である。なお、構成ＤＢには管理対象装置の全ての表、または表中の全ての項目を格納しなくてもよい。また、構成ＤＢが格納する各項目のデータ表現形式・データ構造は、管理対象装置と同じでなくてもよい。また、管理プログラム３２０００が管理対象装置からこれら各項目を受信する場合、管理対象装置のデータ構造やデータ表現形式で受信してもよい。
【００６５】
装置情報取得モジュール３２２００は、管理下の管理対象装置に定期的又は繰り返しアクセスし、管理対象装置内の各コンポーネントの状態を取得する。イベント解析処理モジュール３２４００は、因果律行列３３３００を参照し、装置情報取得モジュール３２２００が取得した管理対象装置の異常状態の根本原因を解析する。
【００６６】
ＧＵＩ表示処理モジュール３２３００は、入力デバイス３１３００を介した管理者からの要求に応じ、取得した構成管理情報を、出力デバイス３１２００を介して表示する。なお、入力デバイスと出力デバイスは別々なデバイスでもよく、一つ以上のまとまったデバイスでもよい。
【００６７】
なお、管理サーバ（管理計算機）は、例えば、入出力デバイスとして、ディスプレイとキーボードとポインタデバイス等を有しているが、これ以外の装置であってもよい。また、入出力デバイスの代替としてシリアルインターフェースやイーサーネットインターフェースを用い、当該インターフェースにディスプレイ又はキーボード又はポインタデバイスを有する表示用計算機（例えば、ＷＥＢブラウザ起動サーバ３５０００）を接続し、表示用情報を表示用計算機に送信したり、入力用情報を表示用計算機から受信することで、表示用計算機で表示を行ったり、入力を受け付けることで入出力デバイスでの入力及び表示を代替してもよい。
【００６８】
本明細書では、計算機システム（情報処理システム）を管理し、表示用情報を表示する一つ以上の計算機の集合を管理システムと呼ぶことがある。管理サーバが表示用情報を表示する場合は、管理サーバが管理システムであり、また、管理サーバと表示用計算機（例えば図１のＷＥＢブラウザ起動サーバ３５０００）の組み合わせも管理システムである。また、管理処理の高速化や高信頼化のために複数の計算機で管理サーバと同等の処理を実現してもよく、この場合は当該複数の計算機（表示を表示用計算機が行う場合は表示用計算機も含め）が管理システムである。
【００６９】
図５にＩＰスイッチ４００００の詳細な構成を示す。ＩＰスイッチ４００００は、プロセッサ４１０００と、各種管理情報を保持するためのメモリ４２０００と、ネットワーク４５０００、４５０１０を介してホストコンピュータ１００００に接続するためのＩ／Ｏポート４３０００、４３０１０と、ネットワーク４５０００に接続するための管理ポート４４０００を有し、これらは内部バス等の回路を介して相互に接続される。
なお、メモリ４２０００は、半導体メモリの代わりとしてその一部もしくは全部が磁気ディスクなど他の記憶媒体であっても良いものとする。
【００７０】
図６Ａ、Ｂ及びＣは、ホストコンピュータ１００００の具備する論理ボリューム管理表１３３００の構成例を示す図である。
【００７１】
論理ボリューム管理表１３３００は、ホストコンピュータ内で各論理ボリュームの識別子となるドライブ名を登録するフィールド１３３１０と、論理ボリュームの実体が存在するストレージ装置との通信の際に用いるホストコンピュータ上のＩ／Ｏポート１１０００の識別子となるｉＳＣＳＩイニシエータ名を登録するフィールド１３３２０と、論理ボリュームの実体が存在するストレージ装置との通信の際に用いるストレージ装置上のＩ／Ｏポート２１０００の識別子となる接続先ｉＳＣＳＩターゲットを登録するフィールド１３３３０と、ストレージ装置において論理ボリュームの識別子となるＬＵＮ  ＩＤを登録するフィールド１３３４０と、を構成項目として含んでいる。
【００７２】
図６Ａには、ホストコンピュータの具備する論理ボリューム管理表の具体的な値の一例を示している。つまり、ホストコンピュータ上で（Ｅ：）というドライブ名で示される論理ボリュームは、ｃｏｍ．ｈｉｔａｃｈｉ．ｓｖ１というｉＳＣＳＩイニシエータ名で示されるホストコンピュータ上のポートと、ｃｏｍ．ｈｉｔａｃｈｉ．ｓｔｏ１というｉＳＣＳＩターゲット名で示されるストレージ装置上のポートを介してストレージ装置と接続しており、０というＬＵＮ  ＩＤをストレージ装置上で持つ。
【００７３】
図７は、ストレージ装置２００００の具備するボリューム管理表２３２００を示す図である。
【００７４】
ボリューム管理表２３２００は、ストレージ装置内で各ボリュームの識別子となるボリュームＩＤを登録するフィールド２３２１０と、各ボリュームの容量を登録するフィールド２３２２０と、各ボリュームが所属するＲＡＩＤグループの識別子となるＲＡＩＤグループＩＤを登録するフィールド２３２３０と、各ボリュームが所属するｉＳＣＳＩターゲットの識別子となるターゲットＩＤを登録するフィールド２３２４０と、各ボリュームのｉＳＣＳＩターゲット内での識別子となるＬＵＮ  ＩＤを登録するフィールド２３２５０と、を構成項目として含んでいる。
図７には、ストレージ装置の具備するボリューム管理表の具体的な値の一例を示している。つまり、ストレージ装置上のボリュームＶＯＬ１は２０ＧＢの記憶領域を持ち、ＲＧ１というＲＡＩＤグループＩＤで示されるＲＡＩＤグループに属し、ＴＧ１というｉＳＣＳＩターゲットＩＤで示されるｉＳＣＳＩターゲットに属し、０というＬＵＮ  ＩＤを持つ。
【００７５】
図８Ａ及び図８Ｂは、ストレージ装置２００００の具備するｉＳＣＳＩターゲット管理表２３３００を示す図である。
【００７６】
ｉＳＣＳＩターゲット管理表２３３００は、ストレージ装置内でｉＳＣＳＩターゲットの識別子となるターゲットＩＤを登録するフィールド２３３１０と、各ｉＳＣＳＩターゲットが持つｉＳＣＳＩターゲット名を登録するフィールド２３３２０と、各ｉＳＣＳＩターゲットに属するボリュームに対しアクセスが許可されたホストコンピュータ上のポートの識別子となるｉＳＣＳＩイニシエータ名を登録するフィールド２３３３０と、を構成項目として含んでいる。
【００７７】
図８Ａには、ストレージ装置の具備するｉＳＣＳＩターゲット管理表の具体的な値の一例を示している。つまり、ストレージ装置上のｉＳＣＳＩターゲットＨＧ１は、ｃｏｍ．ｈｉｔａｃｈｉ．ｓｔｏ１でというｉＳＣＳＩターゲット名を持ち、ｉＳＣＳＩイニシエータ名がｃｏｍ．ｈｉｔａｃｈｉ．ｓｖ１もしくはｃｏｍ．ｈｉｔａｃｈｉ．ｓｖ１１であるホストコンピュータ上のポートからのアクセスを許可している。
【００７８】
図９は、ストレージ装置２００００の具備するＩ／Ｏポート管理表２３４００の構成を示す図である。
【００７９】
Ｉ／Ｏポート管理表２３４００は、ストレージ装置内で各ポートの識別子となるポートＩＤを登録するフィールド２３４１０と、ポートのネットワーク４５０００上での識別子となるＭＡＣアドレスを登録するためのフィールド２３４２０と、を構成項目として含んでいる。
【００８０】
図９には、ストレージ装置の具備するＩ／Ｏポート管理表の具体的な値の一例を示している。つまり、ストレージ装置上のポートＰＯＲＴ１は、ＴＧ１，ＴＧ２というｉＳＣＳＩターゲットＩＤで示されるｉＳＣＳＩターゲットによって使用されている。
【００８１】
図１０は、ストレージ装置２００００の具備するＲＡＩＤグループ管理表２３５００の構成を示す図である。
【００８２】
ＲＡＩＤグループ管理表２３５００は、ストレージ装置内で各ＲＡＩＤグループの識別子となるＲＡＩＤグループＩＤを登録するフィールド２３５１０と、ＲＡＩＤグループのＲＡＩＤレベルを登録するフィールド２３５２０と、各ＲＡＩＤグループの容量を登録するフィールド２３５４０から構成されている。
【００８３】
図１０には、ストレージ装置の具備するＲＡＩＤグループ管理表の具体的な値の一例を示している。つまり、ストレージ装置上のＲＡＩＤグループＲＧ１は、ＲＡＩＤレベルがＲＡＩＤ１で容量は１００ＧＢである。
【００８４】
図１１は、ストレージ装置２００００の具備するディスク管理表２３６００の構成を示す図である。
【００８５】
ディスク管理表２３６００は、ストレージ装置内で各ディスクの識別子となるディスクＩＤを登録するフィールド２３６１０と、ディスクのディスク種別を登録するフィールド２３６２０と、から構成されている。
【００８６】
図１１には、ストレージ装置の具備するディスク管理表の具体的な値の一例を示している。つまり、ストレージ装置上のディスクＤＩＳＫ１は、ディスク種別がＦＣディスクである。
【００８７】
図１２は、管理サーバ３００００が有するイベント管理表３３１００の構成例を示す図である。
【００８８】
イベント管理表３３１００は、イベント自身の識別子となるイベントＩＤを登録するフィールド３３１１０と、取得した構成情報の変化といったイベントの発生した装置の識別子となる装置ＩＤを登録するフィールド３３１２０と、イベントの発生した装置内の部位の識別子を登録するフィールド３３１３０と、発生したイベントの種別を登録するフィールド３３１４０と、イベントが後述するイベント伝播モデル展開モジュール３２５００によって処理済みかどうかを登録するフィールド３３１５０と、イベントが発生した日時を登録するフィールド３３１６０と、イベントが後述するイベント伝播モデル展開モジュール３２５００による処理の対象（又は管理プログラムによる原因解析対象）となる期間を登録するフィールド３３１７０と、を構成項目として含んでいる。
【００８９】
例えば、図１２の第１行目（１つ目のエントリ）からは、管理サーバ３００００が、ホストコンピュータＨＯＳＴ１の、（Ｅ：）で示される論理ボリュームにおける状態異常を検知し、そのイベントＩＤはＥＶ１であることが分かる。
【００９０】
図１３Ａ及び図１３Ｂは、管理サーバ３００００が有するイベント伝播モデルリポジトリ３３２００内のイベント伝播モデルの構成例を示す図である。障害解析において根本原因を特定するためのイベント伝播モデルは、ある障害の結果発生することが予想されるイベントの組み合わせと、その根本原因を"ＩＦ−ＴＨＥＮ"形式で記載するものとなっている。なお、イベント伝播モデルは図１３Ａ及び図１３Ｂに挙げられたものに限られず、さらに多くのルールがあっても構わない。当然ながら、イベント伝播モデルリポジトリ３３２００には複数のイベント伝播モデルを含んでも良い。
【００９１】
イベント伝播モデルは、イベント伝播モデルの識別子となるモデルＩＤを登録するフィールド３３２１０と、"ＩＦ−ＴＨＥＮ"形式で記載したイベント伝播モデルのＩＦ部に相当する観測イベント種別を登録するフィールド３３２２０と、"ＩＦ−ＴＨＥＮ"形式で記載したイベント伝播モデルのＴＨＥＮ部に相当する原因イベント種別を登録するためのフィールド３３２３０と、を構成項目として含んでいる。結論部のステータスが正常になれば、条件部の問題も解決しているという関係にあるものである。
【００９２】
図１３Ａには、管理サーバが有するイベント伝播モデルの具体的な値の一例を示している。つまり、モデルＩＤがＲｕｌｅ１で示されるイベント伝播モデルにおいては、観測イベント種別としてホストコンピュータ上の論理ボリュームの状態異常と、ストレージ装置上のボリュームの状態異常を検知したとき、ストレージ装置のボリュームの故障が原因と結論付ける。
【００９３】
なお、図１３Ｂに示すように、観測イベントとして「ストレージ装置のボリュームの故障」という、他のイベント伝播モデルにおいて結論として位置づけられているイベント種別を持っていてもよい。
【００９４】
図１４Ａ乃至Ｅは、管理サーバ３００００の具備する因果律行列３３３００の構成を示す図である。
【００９５】
因果律行列３３３００は、以下の情報を含む。
【００９６】
＊  展開の際使用したイベント伝播モデルリポジトリ３３２００の識別子となるイベント伝播モデルＩＤを登録するフィールド３３３１０。
【００９７】
＊  管理サーバの装置情報取得モジュール３２２００が検知するイベントを特定する情報（図中では管理オブジェクトの識別子（つまり装置ＩＤとコンポーネントＩＤ）とイベントの種別）を登録するフィールド３３３２０。
【００９８】
＊  前記イベントを検知した際、イベント解析処理モジュール３２４００が障害の原因として結論付ける原因イベントを登録するための情報（図中では管理オブジェクトの識別子（つまり装置ＩＤとコンポーネントＩＤ）とイベントの種別）を登録するフィールド３３３３０。
【００９９】
＊  イベント伝播モデルリポジトリ３３２００に"ＩＦ−ＴＨＥＮ"形式で記載したイベント伝播モデルに基づき、どのイベントを受信した際何を根本原因と位置づけるかという対応関係（つまり因果律）を登録するためのフィールド３３３４０。
【０１００】
図１４Ａには、管理サーバの具備する因果律行列の具体的な値の一例を示している。つまり、ストレージ装置ＳＹＳ１のボリューム（ＶＯＬ１）の状態異常と、ホストＨＯＳＴ１の論理ボリューム（Ｅ：）の状態異常というイベントを装置情報取得モジュールが検知したとき、イベント解析処理モジュールは、ストレージ装置ＳＹＳ１のボリューム（ＶＯＬ１）の故障が根本原因であると結論付ける。
【０１０１】
なお、因果律行列は後述するように因果律の追加、削除をより効率的に行うため、動的に行列のサイズを変更できるデータ構造であってもよい。例えば、所定の行数又は列数毎にサブ行列化して、それらをポインタやインデックスで関係付けて仮想的な行列を見せる等が考えられる。また、因果律行列は記憶資源の連続領域を用いて行列構造を生成してもよい。
【０１０２】
図１５Ａ及び図１５Ｂは、管理サーバ３００００が有するトポロジ生成方式リポジトリ３３４００内のトポロジ生成方式情報（省略してトポロジ生成方式と呼ぶことがある）の構成例を示す図である。
【０１０３】
トポロジ生成方式は、前記管理サーバが管理対象装置から取得した構成情報に基づき、監視対象となる複数の装置間での接続関係（トポロジ）を生成するための手段を定義した情報である。トポロジ生成方式は、トポロジの識別子となるトポロジＩＤを登録するフィールド３３４１０と、トポロジを生成する際の起点となる管理対象装置内のコンポーネント種別を登録するフィールド３３４２０と、トポロジを生成する際の終点となるコンポーネント種別を登録するフィールド３３４３０と、前記起点コンポーネント−終点コンポーネント間のトポロジ生成の際に経由する必要のあるコンポーネント種別を登録するフィールド３３４４０と、前記起点コンポーネント−終点コンポーネント間のトポロジ生成方法を登録するフィールド３３４５０と、を構成項目として含んでいる。
【０１０４】
図１５Ａ及び図１５Ｂには、管理サーバの具備するトポロジ生成方式の具体的な値の一例を示している。つまり、ストレージ装置のボリュームを起点とし、ホストコンピュータの論理ボリュームを終点とするトポロジは、論理ボリュームのｉＳＣＳＩイニシエータ名が、ｉＳＣＳＩターゲットの接続許可ｉＳＣＳＩイニシエータと等しく、かつボリューム内のｉＳＣＳＩターゲットＩＤが、ｉＳＣＳＩターゲット内のＩＤと等しい組み合わせを検索することにより取得可能である。
【０１０５】
図１６に、管理サーバ３００００の装置情報取得モジュール３２２００が実施する装置情報取得処理のフローチャートを示す。
【０１０６】
プログラム制御モジュール３２１００は、プログラムの起動時、もしくは前回の装置情報取得処理から一定時間経過するたびに、装置情報取得モジュール３２２００に対し、装置情報取得処理を実行するよう指示する。なお、当該実行指示を繰り返し出す場合は厳密に一定期間毎である必要は無く、繰り返しさえしていればよい。また。装置から取得する情報には装置の構成情報、状態情報、性能情報が含まれるが、これらの情報をそれぞれ異なるタイミングで取得してもよい。
【０１０７】
装置情報取得モジュール３２２００は、一つ以上の管理対象装置の各々に対し、以下の一連の処理を繰り返す（ステップ６１０１０）。
【０１０８】
装置情報取得モジュール３２２００は、管理対象装置に対して装置の構成情報、状態情報、又は性能情報を送信するよう指示する（ステップ６１０２０）。
【０１０９】
装置からの応答があれば（ステップ６１０３０）、装置情報取得モジュール３２２００は、取得した構成情報を構成ＤＢ３３５００に格納された過去の構成情報と比較する（ステップ６１０４０）。なお、装置から指示に対する応答がなかった場合、装置情報取得処理を終了する。
【０１１０】
取得した構成管理情報を構成ＤＢに格納された過去の構成情報と比較した結果、異なる項目が見つかった場合（ステップ６１０５０）、装置情報取得モジュール３２２００は、差分のあった項目をイベント化し、イベント管理表３３１００を更新する（ステップ６１０６０）。
【０１１１】
次に、装置情報取得モジュール３２２００は、状態情報、性能情報を取得した際に検知した状態異常および性能異常をイベント化し、イベント管理表３３１００を更新する（ステップ６１０７０）。その上で、装置情報取得モジュール３２２００は、取得した構成情報を構成ＤＢ３３５００に格納する（ステップ６１０８０）。
【０１１２】
以上が、装置情報取得モジュール３２２００が実施する構成管理情報取得処理である。なお、因果律の展開又は削除を行うモジュールへの構成変更の通知（又はモジュールの実行開始）は、必ずしもイベントを通じて行う必要はない。また、状態情報に基づいたイベント化とは、コンポーネントの状態が正常以外の状態に変化したときに変化先の状態に対応したイベント（情報）を生成することが一例である。また、性能情報に基づいたイベント化とは、所定の評価基準（閾値等）によって正常ではない性能値となった場合にイベント（情報）を生成することが一例である。
【０１１３】
次に、管理サーバ３００００が具備する展開対象イベント伝播モデル管理表３３６００を図１８に、管理サーバ３００００が実行する処理方式を図１９、図２０及び図２１に示す。
【０１１４】
図１８は、管理サーバ３００００の具備する展開対象イベント伝播モデル管理表３３６００の構成例を示す図である。
【０１１５】
展開対象イベント伝播モデル管理表３３６００は、取得した構成変更イベントの発生した装置の種別を登録するフィールド３３６１０と、前記イベントの発生した装置内のコンポーネントの種別を登録するフィールド３３６２０と、前記イベントの種別を登録するフィールド３３６３０と、イベントが後述するイベント解析処理モジュール３２５００によって処理される際、どのイベント伝播モデルが展開対象となるかを登録するフィールド３３６４０と、を構成項目として含んでいる。
【０１１６】
図１８には、管理サーバの具備する展開対象イベント伝播モデル管理表の具体的な値の一例を示している。つまり、ホストコンピュータにおける論理ボリュームの状態異常というイベントが発生した場合、Ｒｕｌｅ１を再展開する必要がある。
【０１１７】
図１９に、管理サーバ３００００のイベント解析処理モジュール３２４００が実施する、イベント確認処理のフローチャートを示す。なお、管理サーバ３００００の装置情報取得モジュール３２２００は、図１６に示す装置情報取得処理を管理対象装置に対して実施した後、イベント解析処理モジュール３２４００に対し、イベント確認処理を行なうよう指示する。
【０１１８】
イベント解析処理モジュール３２４００は、イベント管理表３３１００を参照し、イベント管理表に定義された構成変更イベントに対し、ループ内の処理を繰り返す（ステップ６４０１０）。イベント解析処理モジュール３２４００は、イベント管理表に定義されたイベントの処理済みフラグがＮｏであるかどうかを確認する（ステップ６４０２０）。イベントの処理済みフラグがＮｏである、すなわち未処理イベントである場合、ステップ６４０３０乃至６４０６０の処理を行う。
【０１１９】
イベント解析処理モジュール３２４００は、イベント管理表に定義されたイベントの処理済みフラグをＹｅｓに変更する（ステップ６４０３０）。次にイベント解析処理モジュール３２４００は、イベント管理表に定義されたイベントが構成変更イベントかどうかを確認する（ステップ６４０４０）。イベント管理表に定義されたイベントが構成変更イベントである場合、図２１に示すイベント伝播モデル再展開処理を実行する。
【０１２０】
次にイベント解析処理モジュール３２４００は、イベント管理表に定義されたイベントが状態異常、または性能異常イベント（構成変更イベント以外）かどうかを確認する（ステップ６４０５０）。イベント管理表に定義されたイベントが状態異常、もしくは性能異常イベント（構成変更イベント以外）である場合、イベント伝播モデル展開モジュール３２５００に対し、当該イベントを指定して図２０に示すイベント伝播モデルオンデマンド展開処理を実行するよう指示する。
【０１２１】
イベント伝播モデルオンデマンド展開処理が終了すると、イベント解析処理モジュール３２４００は、イベント管理表のイベント有効期間を設定する（ステップ６４０６０）。イベント有効期間は、イベントの発生した時刻に、予め定められた一定の時間を加えて算出される。ただしイベント有効期間は他の式で算出されてもよい。
【０１２２】
以上が、イベント解析処理モジュール３２４００が実施するイベント確認処理である。
なお、イベント管理表に複数の状態異常、もしくは性能異常イベントが存在する場合、同時に複数のイベントについてイベント伝播モデルオンデマンド展開処理を実行するようイベント伝播モデル展開モジュールに指示してもよい。
【０１２３】
図２０に、管理サーバ３００００のイベント伝播モデル展開モジュール３２５００が実施するイベント伝播モデルオンデマンド展開処理のフローチャートを示す。
【０１２４】
イベント伝播モデル展開モジュール３２５００は、展開対象イベント伝播モデル管理表３３６００を参照し、処理起動時に指定されたイベント（つまり、未処理であったイベントの一つ）に対応したイベント伝播モデルの一覧を取得する（ステップ６５０１０）。
【０１２５】
次に、イベント伝播モデル展開モジュール３２５００は、前記取得したイベント伝播モデルに対し、ステップ６５０３０乃至６５０９０の処理を繰り返す（ステップ６５０２０）。なお、展開対象イベント伝播モデル管理表３３６００にイベントが登録されていない場合は、以下の処理を行わずにイベント伝播モデルオンデマンド展開処理を終了する。
【０１２６】
イベント伝播モデル展開モジュール３２５００は、トポロジ生成方式リポジトリ３３４００を参照し、イベント伝播モデルに対応したトポロジ生成方式をトポロジ生成方式リポジトリ３３４００より取得する（ステップ６５０３０）。該当するトポロジ生成方式がトポロジ生成方式リポジトリにない場合は、以下の処理を行わない。
【０１２７】
該当するトポロジ生成方式がトポロジ生成方式リポジトリにあれば（ステップ６５０４０）、イベント伝播モデル展開モジュール３２５００は、取得したトポロジ生成方式を元に構成ＤＢ３３５００からトポロジを取得する（ステップ６５０５０）。イベント伝播モデル展開モジュール３２５００は、取得したトポロジに基づいてイベント伝播モデルを展開し（ステップ６５０６０）、展開結果が因果律行列３３３００に既にあるかどうかを確認する（ステップ６５０７０）。展開結果が因果律行列３３３００に既にある場合、以下の処理は行わない。
【０１２８】
展開結果が因果律行列に存在しない場合、イベント伝播モデル展開モジュール３２５００は、因果律行列３３３００の列として追加する（ステップ６５０８０）。次に、イベント伝播モデル展開モジュール３２５００は、展開結果の結論イベントと、処理起動時に指定されたイベント以外の条件イベントについて、図２０に示すイベント伝播モデルオンデマンド展開処理を実施する（ステップ６５０９０）。
【０１２９】
以上が、イベント伝播モデル展開モジュール３２５００が実施するイベント伝播モデルオンデマンド展開処理である。なお、構成ＤＢ以外の情報にトポロジを別途格納している場合はそのような情報を参照して上記処理を行っても良い。
【０１３０】
図２１に、管理サーバ３００００のイベント伝播モデル展開モジュール３２５００が実施するイベント伝播モデル再展開処理のフローチャートを示す。
【０１３１】
イベント伝播モデル展開モジュール３２５００は、因果律行列３３３００を全て削除する（ステップ６６０１０）。次に、イベント種別が構成変更であるイベントについて、イベント処理済みフラグをＹｅｓに変更する（ステップ６６０２０）。
【０１３２】
次に、イベント伝播モデル展開モジュール３２５００は、イベント管理表３３１００を参照し、イベント管理表の未処理イベントに対し、ループ内の処理を繰り返す（ステップ６６０３０）。
【０１３３】
イベント伝播モデル展開モジュール３２５００は、該当するイベントの種別は状態異常、もしくは性能異常（つまり構成変更以外）かどうかを確認する（ステップ６６０４０）。次に、該当するイベントのイベント有効期間が満了しているかどうかを確認する（ステップ６６０５０）。満了していない場合、当該イベントを指定してイベント伝播モデルオンデマンド展開処理６５０００を実施する（ステップ６６０６０）。
【０１３４】
以上が、イベント伝播モデル展開モジュール３２５００が実施するイベント伝播モデル再展開処理である。なお、本フローでは一度全ての因果律を削除し、有効期間内のイベントについて再度因果律を作成しているが、ステップ６６０１０で構成変更に関係した因果律だけ削除してもよい。
【０１３５】
以下に、図６乃至１３の情報の内容に対応する計算機システムを例として、実施例１の処理がどのように因果律行列を作成するかを示す。なお、処理開始当初のｉＳＣＳＩターゲット管理表は図８Ａに示すとおりであるものとする。
【０１３６】
プログラム制御モジュールは、管理者からの指示もしくはタイマーによるスケジュール設定によって応じて、装置情報取得モジュールに対し、装置情報取得処理を実行するよう指示する。装置情報取得モジュールは、管理対象装置に順にログインし、装置に対し装置の構成情報、状態情報、性能情報を送信するよう指示する。
【０１３７】
上記の処理が終了した後、装置情報取得モジュールは、取得した状態情報、性能情報を参照し、イベント管理表を更新する。ここでは、図１２のイベント管理表の１行目に示す通り、ホストコンピュータＨＯＳＴ１の、（Ｅ：）で示される論理ボリュームにおける状態異常を検知したケースを想定する。
【０１３８】
イベント解析処理モジュールは、上記イベントが未処理イベントであることを確認すると、イベント伝播モデル展開モジュールに対し、展開対象イベント伝播モデル管理表を参照して当該イベントを指定してイベント伝播モデルオンデマンド展開処理を実行するよう指示する。
【０１３９】
イベント伝播モデル展開モジュールは、イベントに対応したイベント伝播モデルの一覧を取得する。例えば、図１８に示す展開対象イベント伝播モデル管理表を参照すると、ホストコンピュータにおける論理ボリュームの状態異常というイベントが発生した場合、Ｒｕｌｅ１を展開する必要があることが分かる。
【０１４０】
図１３Ａに示すイベント伝播モデルＲｕｌｅ１は、観測イベントとして"ホストコンピュータの論理ボリュームの状態異常"と、"ストレージ装置のボリュームの状態異常"が定義されている。図１５Ａに示すトポロジ生成方式を参照すると、ストレージ装置のＩ／Ｏポートを起点とし、ホストコンピュータの論理ボリュームを終点とするトポロジ生成方式ＴＰ１が定義されている。そこで、このトポロジ生成方式を利用してトポロジを取得する。
【０１４１】
図７の示すボリューム管理表（に相当する管理サーバが格納した構成ＤＢ内の項目）を参照し、ストレージ装置ＳＹＳ１のボリュームＶＯＬ１に着目すると、そのターゲットＩＤはＴＧ１となっている。次に、図８Ａに示すｉＳＣＳＩターゲット管理表（に相当する管理サーバが格納した構成ＤＢ内の項目）を参照し、ｉＳＣＳＩターゲットＩＤがＴＧ１となっているものを探し、その接続許可ｉＳＣＳＩイニシエータ名を見ると"ｃｏｍ．ｈｉｔａｃｈｉ．ｓｖ１"もしくは"ｃｏｍ．ｈｉｔａｃｈｉ．ｓｖ１１"となっている。
【０１４２】
次に、図６Ａに示すＩ／Ｏポート管理表（に相当する管理サーバが格納した構成ＤＢ内の項目）を参照し、ｉＳＣＳＩイニシエータ名が"ｃｏｍ．ｈｉｔａｃｈｉ．ｓｖ１"もしくは"ｃｏｍ．ｈｉｔａｃｈｉ．ｓｖ１１"となっている論理ボリュームを検索する。その結果検索されたホストコンピュータＨＯＳＴ１の論理ボリューム（Ｅ：）と（Ｆ：）のうち、ＬＵＮＩＤがストレージ装置ＳＹＳ１のボリュームＶＯＬ１のＬＵＮＩＤと等しいものを探す。以上の結果、ホストコンピュータの論理ボリュームとストレージ装置のボリュームを含むトポロジの一つとして、ホストコンピュータＨＯＳＴ１の論理ボリューム（Ｅ：）と、ストレージ装置ＳＹＳ１のボリュームＶＯＬ１の組み合わせが存在する。
【０１４３】
そこで、観測イベントとして"ホストコンピュータＨＯＳＴ１の論理ボリューム（Ｅ：）の状態異常"と、"ストレージ装置ＳＹＳ１のボリュームＶＯＬ１の状態異常"を検知した際、根本原因として"ストレージ装置ＳＹＳ１のボリュームＶＯＬ１の故障"を結論付けるパターンが展開結果（つまり展開すべき因果律）となる。この展開結果が因果律行列に存在しない場合、展開結果を因果律行列の列として追加する。
【０１４４】
上記の処理が終了した後、展開結果の結論イベントと、入力イベント以外の条件イベントについて、図２０に示すイベント伝播モデルオンデマンド展開処理を実施する。上記の展開結果の場合、"ストレージ装置ＳＹＳ１のボリュームＶＯＬ１の故障"というイベントについて、図１８に示す展開対象イベント伝播モデル管理表を参照すると、Ｒｕｌｅ２を再展開する必要があることが分かる。そこで、"ストレージ装置ＳＹＳ１のボリュームＶＯＬ１の故障"というイベントを起点として、Ｒｕｌｅ２について再度展開を行う。
【０１４５】
以上の処理により、イベント伝播モデルＲｕｌｅ１およびＲｕｌｅ２に関する因果律行列が作成され、それぞれ図１４Ｃおよび図１４Ｄの状態となる。
【０１４６】
一方、装置情報取得モジュールは、構成ＤＢに格納された過去の構成情報と、管理対象装置より取得した構成情報を参照し、イベント管理表を更新する。ここでは、図１２のイベント管理表の２行目に示す通り、ストレージ装置ＳＹＳ１の、ＴＧ１で示されるｉＳＣＳＩターゲットにおける接続許可ｉＳＣＳＩイニシエータの変更を検知したケースを想定する。なお、変更後のｉＳＣＳＩターゲット管理表を図８Ｂに示す。
【０１４７】
次に、イベント解析処理モジュールは、イベント管理表に定義されたイベントの処理済みフラグをＹｅｓに変更する。次にイベント解析処理モジュールは、イベント管理表に定義されたイベントが構成変更イベントかどうかを確認する。イベント管理表に定義されたイベントが構成変更イベントである場合、イベント伝播モデル再展開処理を実行する。
【０１４８】
イベント伝播モデル展開モジュールは、因果律行列を全て削除し、イベント種別が構成変更であるイベントについて、イベント処理済みフラグをＹｅｓに変更する。次に、イベント伝播モデル展開モジュールは、イベント管理表を参照し、イベントの種別が状態異常、性能異常であり、かつイベント有効期間が満了していないイベントについて、イベント伝播モデルオンデマンド展開処理を実施する。
【０１４９】
例えば、図１２のイベント管理表の１行目には、"ホストコンピュータＨＯＳＴ１の、（Ｅ：）で示される論理ボリュームにおける状態異常"というイベントが定義されており、イベント処理済みフラグをＹｅｓで、イベント有効期間は"２０１０−０１−０１  １５：３０：００"と定義されている。そこで、イベント伝播モデル展開モジュールは、上記イベントを起点にイベント伝播モデルオンデマンド展開を行う。すなわち、イベント伝播モデルＲｕｌｅ１を展開し、因果律行列に追加する。展開の方法は、イベント伝播モデルオンデマンド展開処理の説明にて述べた方法と同じである。
【０１５０】
以上の処理により、イベント伝播モデルＲｕｌｅ１に関する因果律行列が更新され、図１４Ｃから図１４Ｅの状態となる。
【実施例２】
【０１５１】
実施例２では、管理プログラムのイベント伝播モデル展開モジュール３２５００が実施する、別なイベント伝播モデルオンデマンド展開処理について説明する。
【０１５２】
実施例１においては、同時に複数のイベントについてイベント伝播モデルオンデマンド展開処理を実行するようイベント伝播モデル展開モジュールに指示する。ＩＴシステムにおいては、１つの障害が多数の装置に波及し、同時に多数の異常イベントが管理プログラムによって検知される。しかし、同じ根本原因を持つ異常イベントについて、イベント伝播モデルオンデマンド展開処理を並列に処理すると、同じトポロジを複数同時に構成ＤＢより取得することとなり、処理上の無駄が多く処理時間が長くなる。
【０１５３】
上記の課題を解決するため、実施例２では管理サーバ３００００におけるイベント伝播モデルオンデマンド展開処理を変更する。変更後の管理サーバ３００００が具備する展開済イベント管理表３３７００を図２２に、展開済起点コンポーネント管理表３３８００を図２３に、管理サーバ３００００が実行する処理を図２４Ａ及び図２４Ｂに示す。なお、その他は実施例１と同様である。
【０１５４】
図２２は、実施例２において管理サーバ３００００の記憶資源に格納された展開済イベント管理表３３７００の構成例を示す図である。
【０１５５】
展開済イベント管理表３３７００は、展開済イベントの発生した装置の識別子となる装置ＩＤを登録するフィールド３３７１０と、イベントの発生した装置内の部位の識別子を登録するフィールド３３７２０と、前記イベントの種別を登録するフィールド３３７３０と、前記イベントを契機とした展開処理の進行状況を登録するフィールド３３７４０と、を構成項目として含んでいる。
【０１５６】
図２２には、管理サーバの具備する展開済イベント管理表の具体的な値の一例を示している。つまり、ホストコンピュータＨＯＳＴ１における論理ボリューム（Ｅ：）の状態異常というイベントを契機とした展開処理は既に完了していることを示している。
【０１５７】
図２３は、実施例２において管理サーバ３００００の記憶資源に格納された展開済起点コンポーネント管理表３３８００の構成例を示す図である。
【０１５８】
展開済起点コンポーネント管理表３３８００は、展開済起点コンポーネントの存在する装置の識別子となる装置ＩＤを登録するフィールド３３８１０と、起点コンポーネントの識別子を登録するフィールド３３８２０と、前記コンポーネントを起点に展開を行ったイベント伝播モデルのＩＤを登録するフィールド３３８３０と、前記イベントを契機とした展開処理の進行状況を登録するフィールド３３８４０と、を構成項目として含んでいる。
【０１５９】
図２３には、管理サーバの具備する展開済起点コンポーネント管理表の具体的な値の一例を示している。つまり、ストレージ装置ＳＹＳ１におけるボリュームＶＯＬ１というコンポーネントを起点としたＲｕｌｅ１の展開処理は既に完了していることを示している。
【０１６０】
本実施例において管理サーバ３００００が実行するイベント伝播モデルオンデマンド展開処理の処理方式を図２４Ａ及び図２４Ｂに示す。なお、管理サーバ３００００が実行するその他の処理は、実施例１と変わらない。
【０１６１】
図２４Ａ及び図２４Ｂに、実施例２における、管理サーバ３００００のイベント伝播モデル展開モジュール３２５００が実施するイベント伝播モデルオンデマンド展開処理のフローチャートを示す。先ずは図２４Ａの処理から説明を始める。
【０１６２】
イベント伝播モデル展開モジュール３２５００は、展開済イベント管理表３３７００を参照し、処理起動時に指定されたイベントが存在するかどうか検索する（ステップ６７０１０）。イベントが存在し、そのステータスが「展開済」の場合は、何もせず処理を終了する。イベントが存在し、そのステータスが「展開中」の場合は、一定時間待機した後に処理を再試行する。展開済イベント管理表３３７００にイベントが存在しない場合は、以下に示す処理を実施する（ステップ６７０２０）。
【０１６３】
イベント伝播モデル展開モジュール３２５００は、展開済イベント管理表３３７００にイベントを追加し、イベントのステータスを「展開中」に変更する（ステップ６７０３０）。次に、展開対象イベント伝播モデル管理表３３６００を参照し、発生したイベントに対応したイベント伝播モデルの一覧を取得する（ステップ６７０４０）。
【０１６４】
次に、イベント伝播モデル展開モジュール３２５００は、前記取得したイベント伝播モデルに対し、図２４Ｂに記載のステップ６７０６０乃至ステップ６７１４０の処理を繰り返す（ステップ６７０５０）。なお、展開対象イベント伝播モデル管理表３３６００にイベントが登録されていない場合は、以下の処理を行わずにイベント伝播モデルオンデマンド展開処理を終了する。
【０１６５】
以下、図２４Ｂの説明である。
【０１６６】
イベント伝播モデル展開モジュール３２５００は、トポロジ生成方式リポジトリ３３４００を参照し、イベント伝播モデルに対応したトポロジ生成方式をトポロジ生成方式リポジトリ３３４００より取得する（ステップ６７０６０）。該当するトポロジ生成方式がトポロジ生成方式リポジトリ３３４００にない場合は、以下の処理を行わない。
【０１６７】
該当するトポロジ生成方式がトポロジ生成方式リポジトリにあれば（ステップ６７０７０）、イベント伝播モデル展開モジュール３２５００は、取得したトポロジ生成方式を元に、イベントの発生したコンポーネントに対応する起点コンポーネント取得する（ステップ６７０８０）。
【０１６８】
次に、イベント伝播モデル展開モジュール３２５００は、展開済起点コンポーネント管理表３３８００を参照し、起点コンポーネントが存在するかどうか検索する（ステップ６７０１０）。起点コンポーネントが存在し、そのステータスが「展開済」の場合は、何もせず処理を終了する。起点コンポーネントが存在し、そのステータスが「展開中」の場合は、一定時間待機した後に処理を再試行する。展開済起点コンポーネント管理表３３８００に起点コンポーネントが存在しない場合は、以下に示す処理を実施する（ステップ６７０９０）。
【０１６９】
イベント伝播モデル展開モジュール３２５００は、展開済起点コンポーネント管理表３３８００に起点コンポーネントを追加し、起点コンポーネントのステータスを「展開中」に変更する（ステップ６７１００）。
【０１７０】
イベント伝播モデル展開モジュール３２５００は、取得した生成方式リポジトリを元に構成ＤＢ３３５００からトポロジを取得し、取得したトポロジに基づいてイベント伝播モデルを展開する（ステップ６７１１０）。そして展開結果を、因果律行列３３３００の列として追加する（ステップ６７１２０）。次に、展開済起点コンポーネント管理表３３８００を参照し、起点コンポーネントのステータスを「展開済」に変更する（ステップ６７１３０）。
【０１７１】
次に、展開結果の結論イベントと、処理起動時に指定されたイベント以外の条件イベントについて、ルールオンデマンド展開処理を繰り返し実施する（ステップ６７１４０）。
【０１７２】
ここまでが図２４Ｂの説明である。再び図２４Ａに戻り説明する。
イベント伝播モデルに対する処理が終了した時点で、展開済イベント管理表３３７００を参照し、発生したイベントのステータスを「展開済」に変更する（ステップ６７１５０）。
【０１７３】
以下に、図６乃至１３の情報の内容に対応する計算機システムを例として、実施例２の処理がどのように因果律行列を作成するかを示す。
【０１７４】
プログラム制御モジュールは、管理者からの指示もしくはタイマーによるスケジュール設定によって応じて、装置情報取得モジュールに対し、装置情報取得処理を実行するよう指示する。装置情報取得モジュールは、管理対象装置に順にログインし、管理対象装置に対し装置の構成情報、状態情報、性能情報を送信するよう指示する。
【０１７５】
上記の処理が終了した後、装置情報取得モジュールは、取得した状態情報、性能情報を参照し、イベント管理表を更新する。ここでは、図１２のイベント管理表の４行目に示す通り、ストレージ装置ＳＹＳ１の、ＤＩＳＫ１で示されるディスクにおける状態異常を検知したケースを想定する。
【０１７６】
イベント解析処理モジュールは、展開対象イベント伝播モデル管理表を参照し、上記イベントが未処理イベントであることを確認すると、イベント伝播モデル展開モジュールに対し、当該イベントを指定してイベント伝播モデルオンデマンド展開処理を実行するよう指示する。
【０１７７】
イベント伝播モデル展開モジュールは、展開済イベント管理表を参照し、処理起動時に指定されたイベントが存在するかどうか検索する。展開済イベント管理表にイベントが存在しない場合、展開済イベント管理表にイベントを追加し、イベントのステータスを「展開中」に変更する。
【０１７８】
次にイベント伝播モデル展開モジュールは、イベントに対応したイベント伝播モデルの一覧を取得する。例えば、図１８に示す展開対象イベント伝播モデル管理表を参照すると、ストレージ装置におけるディスクの状態異常というイベントが発生した場合、Ｒｕｌｅ２を展開する必要があることが分かる。
【０１７９】
図１３Ｂに示すイベント伝播モデルＲｕｌｅ２は、観測イベントとして"ストレージ装置のボリュームの故障"、"ストレージ装置のＲＡＩＤグループの状態異常"、"ストレージ装置のディスクの状態異常"が定義されている。図１５Ｂに示すトポロジ生成方式を参照すると、ストレージ装置のＲＡＩＤグループを起点とし、ストレージ装置のボリュームとストレージ装置のディスクを終点とするトポロジ生成方式ＴＰ２が定義されている。そこで、このトポロジ生成方式を利用してトポロジを取得する。
【０１８０】
図１０に示すＲＡＩＤグループ管理表（に相当する構成ＤＢの項目）を参照し、ストレージ装置ＳＹＳ１のディスクＤＩＳＫ１に着目すると、それに対応するＲＡＩＤグループはＲＧ１となっている。よって、ストレージ装置ＳＹＳ１のディスクＤＩＳＫ１に対応する起点となるストレージ装置のＲＡＩＤグループはＲＧ１であることが分かる。次に、図２４に示す展開済起点コンポーネント管理表を参照し、ストレージ装置ＳＹＳ１のＲＡＩＤグループＲＧ１が登録されているかどうかを検索し、登録されていなければステータスを「展開中」として新たに登録する。
【０１８１】
次に、図７に示すボリューム管理表（に相当する構成ＤＢの項目）を参照し、ＲＡＩＤグループＩＤがＲＧ１となっているボリュームを検索する。その結果検索されたストレージ装置ＳＹＳ１のボリュームＶＯＬ１とＶＯＬ２が存在することが分かる。以上の結果、ストレージ装置のボリュームとＲＡＩＤグループとディスクを含むトポロジとして、ストレージ装置ＳＹＳ１のディスクＤＩＳＫ１と、ＲＡＩＤグループＲＧ１と、ボリュームＶＯＬ１の組み合わせが存在する。
【０１８２】
そこで、観測イベントとして"ストレージ装置ＳＹＳ１のディスクＤＩＳＫ１の状態異常"と、"ストレージ装置ＳＹＳ１のＲＡＩＤグループＲＧ１の状態異常"と、"ストレージ装置ＳＹＳ１のボリュームＶＯＬ１の故障"を検知した際、根本原因として"ストレージ装置ＳＹＳ１のディスクＤＩＳＫ１の故障"を結論付けるパターンが展開結果となる。この展開結果を因果律行列の列として追加する。
【０１８３】
上記の処理が終了した後、展開結果の結論イベントと、入力イベント以外の条件イベントについて、ルールオンデマンド展開処理実施する。上記の展開結果の場合、"ストレージ装置ＳＹＳ１のボリュームＶＯＬ１の故障"というイベントについて、図１８に示す展開対象イベント伝播モデル管理表を参照すると、Ｒｕｌｅ１を再展開する必要があることが分かる。そこで、Ｒｕｌｅ１について再度展開を行う。
【０１８４】
以上の処理により、イベント伝播モデルＲｕｌｅ１およびＲｕｌｅ２に関する因果律行列が作成され、それぞれ図１４Ｃおよび図１４Ｄの状態となる。
【０１８５】
この後、管理プログラムが"ストレージ装置ＳＹＳ１のディスクＤＩＳＫ１における状態異常"というイベントを再度検知し、イベント解析処理モジュールからイベント伝播モデル展開モジュールに対し、当該イベントを指定してイベント伝播モデルオンデマンド展開処理を実行するよう指示した場合、イベント伝播モデル展開モジュールは展開済イベント管理表を参照し、処理起動時に指定されたイベントが存在するかどうかを検索する。展開済イベント管理表にイベントが存在し、イベントのステータスは「展開済」であるため、以降の処理を行わずにイベント伝播モデルオンデマンド展開処理を終了する。
【０１８６】
あるいは、管理プログラムが"ストレージ装置ＳＹＳ１のディスクＤＩＳＫ２における状態異常"というイベントを検知し、イベント解析処理モジュールからイベント伝播モデル展開モジュールに対し、当該イベントを指定してイベント伝播モデルオンデマンド展開処理を実行するよう指示した場合、イベント伝播モデル展開モジュールは展開済イベント管理表を参照し、処理起動時に指定されたイベントが存在するかどうかを検索する。展開済イベント管理表にイベントが存在しないため、イベント伝播モデル展開モジュールは展開対象イベント伝播モデル管理表を参照し、イベント伝播モデルＲｕｌｅ２を展開する必要があると判断する。
【０１８７】
図１３Ｂに示すイベント伝播モデルＲｕｌｅ２は、観測イベントとして"ストレージ装置のボリュームの故障"、"ストレージ装置のＲＡＩＤグループの状態異常"、"ストレージ装置のディスクの状態異常"が定義されている。図１５Ｂに示すトポロジ生成方式を参照すると、ストレージ装置のＲＡＩＤグループを起点とし、ストレージ装置のボリュームとストレージ装置のディスクを終点とするトポロジ生成方式ＴＰ２が定義されている。そこで、このトポロジ生成方式を利用してトポロジを取得する。
【０１８８】
図１０に示すＲＡＩＤグループ管理表（に相当する構成ＤＢの項目）を参照し、ストレージ装置ＳＹＳ１のディスクＤＩＳＫ２に着目すると、それに対応するＲＡＩＤグループはＲＧ１となっている。よって、ストレージ装置ＳＹＳ１のディスクＤＩＳＫ２に対応する起点となるストレージ装置のＲＡＩＤグループはＲＧ１であることが分かる。次に、図２３に示す展開済起点コンポーネント管理表を参照すると、ストレージ装置ＳＹＳ１のＲＡＩＤグループＲＧ１が存在し、起点コンポーネントのステータスは「展開済」であるため、以降の処理を行わずにイベント伝播モデルオンデマンド展開処理を終了する。
【０１８９】
なお、図２９に示すように、計算機システム上に管理サーバ３００００が複数台存在し、ストレージ装置２００００、ホストコンピュータ１００００、管理サーバ３００００といった管理対象装置を分担して管理している場合、管理サーバ３００００のイベント伝播モデル展開モジュール３２５００は、展開済イベント管理表３３７００に処理起動時に指定されたイベントが存在しない場合は、他の管理サーバ上の展開済イベント管理表を参照し、当該イベントが存在するかどうかを検索する。当該イベントが存在する場合、その管理サーバ上の因果律行列３３３００から、当該イベントに関連する行および列を収集し、自身の因果律行列にコピーする。
【０１９０】
以上が、本実施例におけるイベント伝播モデルオンデマンド展開処理である。
【０１９１】
以上本実施例によれば、管理プログラムは、イベント伝播モデルを展開する前に、検知したイベントおよび展開しようとするイベント伝播モデルに対応する結論コンポーネントを検索し、各結論コンポーネントのうち既にルール展開を完了したもの、あるいは展開中であるものについて記録することにより、同じイベント伝播モデルから同じ因果律行列を繰り返し生成することを抑止する。
【０１９２】
その結果として、大規模システムを対象とし、オンデマンド展開方式を採用する解析エンジンにおいて、同じ障害原因を持つ多数の障害を同時に受信した場合においても、イベント伝播モデルに基づく因果律行列の展開作業を効率化でき、管理サーバにかかる処理負荷を軽減しつつ適切に因果律行列の展開処理を実行できる。
【実施例３】
【０１９３】
実施例３では、管理プログラムのイベント伝播モデル展開モジュール３２５００が実施する、イベント伝播モデル展開処理について説明する。
【０１９４】
実施例１においては、管理プログラムが装置から異常イベントを受信してからイベント伝播モデルオンデマンド展開処理を実行し、それが終了した後に障害解析を実施する。従って、イベントを受信してから障害解析を開始するまでの時間が、従来の事前展開方式に比べて長いという課題が存在する。一方、例えばストレージ内の物理的なコンポーネント（ポート、ディスクなど）にのみ関するイベント伝播モデルの場合、展開する際に取得するトポロジが変化する頻度は非常に低いため、従来の事前展開方式を採用しても構成変更により再展開を強いられる可能性は非常に低く、イベント受信後に障害解析をより迅速に開始するには、事前展開方式を採用する方が望ましい。
【０１９５】
このような課題を解決するため、実施例３では管理サーバ３００００におけるイベント伝播モデルオンデマンド展開処理およびイベント伝播モデル再展開処理を変更する。実施例３の管理サーバ３００００が具備するイベント伝播モデル管理表３３９００を図２５に、管理サーバ３００００が実行する処理フローを図２６乃至図２８に示す。なお、管理サーバ３００００のその他の情報及びフローは実施例１又は２と同じである。
【０１９６】
図２５は、実施例３において管理サーバ３００００の具備するイベント伝播モデル管理表３３９００の構成例を示す図である。
【０１９７】
イベント伝播モデル管理表３３９００は、イベント伝播モデルの識別子となるイベント伝播モデルＩＤを登録するフィールド３３９１０と、前記イベント伝播モデルの展開に用いる方式を登録するフィールド３３９２０と、を構成項目として含んでいる。
【０１９８】
図２５には、管理サーバの具備するイベント伝播モデル管理表の具体的な値の一例を示している。つまり、イベント伝播モデルＩＤがＲｕｌｅ１で示されるイベント伝播モデルについては、事前展開方式によって展開することを示している。
【０１９９】
本実施例において管理サーバ３００００が実行するイベント伝播モデルオンデマンド展開処理の処理方式を図２６に示す。なお、管理サーバ３００００が実行するその他の処理は、実施例１と変わらない。
【０２００】
図２６に、実施例３における、管理サーバ３００００のイベント伝播モデル展開モジュール３２５００が実施するイベント伝播モデルオンデマンド展開処理のフローチャートを示す。実施例１の図２０で説明したフローと異なる点はステップ６５０２１及びステップ６５０２２が追加されたことである。以下、追加された部分のみ説明する。
【０２０１】
イベント伝播モデル展開モジュール３２５００はイベント伝播モデル管理表３３９００を参照し、イベント伝播モデルの展開方式を取得する（ステップ６５０２１）。展開方式が「オンデマンド展開」であった場合（ステップ６５０２２）、ステップ６５０３０を実行する。
【０２０２】
図２８に、実施例３における、管理サーバ３００００のイベント伝播モデル展開モジュール３２５００が実施するイベント伝播モデル展開処理のフローチャートを示す。なお、処理は実施例１で説明した図２１の処理のステップ６６０２０とステップ６６０３０との間で実行される。
【０２０３】
イベント伝播モデル展開モジュール３２５００は、イベント伝播モデルリポジトリ３３２００に定義された全てのイベント伝播モデルに対し、ステップ６３０２２乃至６３０６０の処理を繰り返す（ステップ６３０２０）。
【０２０４】
イベント伝播モデル展開モジュール３２５００は、イベント伝播モデル管理表３３９００を参照し、イベント伝播モデルの展開方式を取得する（ステップ６３０２１）。展開方式が「事前展開」であった場合（ステップ６３０２２）、以下の処理を実行する。
【０２０５】
イベント伝播モデル展開モジュール３２５００は、トポロジ生成方式リポジトリ３３４００を参照し、イベント伝播モデルに対応したトポロジ生成方式をトポロジ生成方式リポジトリ３３４００より取得する（ステップ６３０３０）。
【０２０６】
該当するトポロジ生成方式がトポロジ生成方式リポジトリにあれば（ステップ６３０４０）、イベント伝播モデル展開モジュール３２５００は、取得したトポロジ生成方式を元に構成ＤＢ３３５００からトポロジを取得し（ステップ６３０５０）、取得したトポロジを用いてイベント伝播モデルを展開し、因果律行列３３３００に追加する（ステップ６３０６０）。
【０２０７】
以上が、イベント伝播モデル展開モジュール３２５００が実施するイベント伝播モデル展開処理である。
【０２０８】
なお、本実施例ではイベント伝播モデル毎にオンデマンド展開方式と事前展開方式のどちらを用いるかを定義していたが、例えば管理対象装置ごとに前記の定義をしても構わない。即ち、障害発生後即座に根本原因を求めたい重要な装置については事前展開方式を、その他の装置についてはオンデマンド展開方式を採用するというように使い分けることができる。
【０２０９】
以上本実施例によれば、管理プログラムのイベント伝播モデル管理表に登録されたポリシーに基づき、個々のイベント伝播モデルについて、実施例１で述べたオンデマンド展開方式と、事前展開方式のどちらを用いるかを選択することができる。結果として、イベント伝播モデルの性質や、解析作業のリアルタイム性をどの程度求めるかによって両方式を使い分けることができる。
【０２１０】
特許請求の範囲に記載したもののほか、本発明の観点の代表的なものとして、次のものが挙げられる。
１．管理プログラムを格納した記憶資源と、
前記管理プログラムを実行するプロセッサと、
を含む、複数の管理対象計算機を管理する管理計算機であって、
前記記憶資源は、
（１）前記複数の管理対象計算機又は前記複数の管理計算機が含む複数のコンポーネントである複数の管理オブジェクトに関し、前記複数の管理オブジェクト同士の関係を示すトポロジと、
（２）イベント種別及びイベントが発生する管理オブジェクトの種別によって定義される、イベントと当該イベント発生原因となる原因イベントとの組の情報を含むイベント伝播モデルと、
（３）一つ以上の因果律を含む因果律情報と、
を格納し、
前記因果律とは、種別が種別１である第１の管理オブジェクトで発生する、種別が種別Ａである第１のイベントが原因で、種別が種別２である第２の管理オブジェクトで種別が種別Ｂである第２のイベントが発生すること、を示し、
前記管理プログラムは、前記プロセッサに、
（Ａ）所定の管理オブジェクトで発生した問題に関するイベントを検知させ、
（Ｂ）前記検知イベントの解析に用いる第１の因果律が前記因果律情報に生成済みか判断させ、
（Ｃ）（Ｂ）で未生成と判断した場合、前記トポロジと前記イベント伝播モデルに基づいて前記第１の因果律を前記因果律情報に生成するオンデマンド展開をさせ、
（Ｄ）前記第１の因果律を用いて、前記検知イベントを解析させる、
ことを特徴とした管理計算機。
２．上記１．記載の管理計算機であって、
前記管理プログラムは、前記プロセッサに、
前記検知イベント以外の、解析した前記第１の因果律に含まれるイベントの解析に用いる第２の因果律が、前記因果律情報に生成済みか判断させ、未生成と判断した場合、前記第２の因果律に関してオンデマンド展開をさせる、
ことを特徴とした管理計算機。
３．上記１．または２．に記載の管理計算機であって、
前記記憶資源は、
（４）前記イベント伝播モデルに対応する因果律の作成を事前に実行するか否かを示す、イベント伝播モデル管理情報、
を格納し、
前記管理計算機がイベントを検知する前に、前記管理プログラムは、前記プロセッサに、
（Ｅ）前記イベント伝播モデル管理情報に基づいて、前記因果律を事前に作成するか否か判断させる、
ことを特徴とした管理計算機。
４．上記１．乃至３．のいずれか１つに記載の管理計算機であって、
前記記憶資源は、
（５）前記管理オブジェクトに対応する因果律の作成を事前に実行するか否かを示す事前展開可否情報、
を格納し、
前記管理計算機がイベントを検知する前に、前記管理プログラムは、前記プロセッサに、
（Ｆ）前記事前展開可否情報に基づいて、前記所定の管理オブジェクトに対応する前記因果律を事前に作成させるか否か判断させる、
ことを特徴とした管理計算機。
５．上記１．乃至４．のいずれか１つに記載の管理計算機であって、
前記記憶資源は、
（６）前記検知イベントに関する解析有効期間、
を格納し、
前記解析有効期間後に、前記管理プログラムは、前記プロセッサに、
（Ｇ）前記検知イベントに対応する前記第１の因果律を前記因果律情報から削除させる、
ことを特徴とした管理計算機。
６．上記１．乃至５．のいずれか１つに記載の管理計算機であって、
前記管理プログラムは、前記プロセッサに、
（Ｈ）前記第１の因果律が示す原因イベントと同じ原因を持つ他の因果律のオンデマンド展開を、前記第１の因果律に関するオンデマンド展開中は抑止させる、
ことを特徴とした管理計算機。
７．複数の管理対象計算機を管理する記憶資源を含む管理計算機によるイベント解析方法であって、
前記記憶資源に、
（１）前記複数の管理対象計算機又は前記複数の管理計算機が含む複数のコンポーネントである複数の管理オブジェクトに関し、前記複数の管理オブジェクト同士の関係を示すトポロジと、
（２）イベント種別及びイベントが発生する管理オブジェクトの種別によって定義される、イベントと当該イベント発生原因となる原因イベントとの組の情報を含むイベント伝播モデルと、
（３）一つ以上の因果律を含む因果律情報と、
を格納し、
前記因果律とは、種別が種別１である第１の管理オブジェクトで発生する、種別が種別Ａである第１のイベントが原因で、種別が種別２である第２の管理オブジェクトで種別が種別Ｂである第２のイベントが発生すること、を示し、
（Ａ）所定の管理オブジェクトで発生した問題に関するイベントを検知し、
（Ｂ）前記検知イベントの解析に用いる第１の因果律が前記因果律情報に生成済みか判断し、
（Ｃ）（Ｂ）で未生成と判断した場合、前記トポロジと前記イベント伝播モデルに基づいて前記第１の因果律を前記因果律情報に生成するオンデマンド展開し、
（Ｄ）前記第１の因果律を用いて、前記検知イベントを解析する、
ことを特徴とした方法。
８．上記７．記載のイベント解析方法であって、
前記検知イベント以外の、解析した前記第１の因果律に含まれるイベントの解析に用いる第２の因果律が、前記因果律情報に生成済みか判断し、未生成と判断した場合、前記第２の因果律に関してオンデマンド展開する、
ことを特徴とした方法。
９．上記７．または８．に記載のイベント解析方法であって、
前記記憶資源に、
（４）前記イベント伝播モデルに対応する因果律の作成を事前に実行するか否かを示す、イベント伝播モデル管理情報、
を格納し、
（Ｅ）前記管理計算機がイベントを検知する前に、前記イベント伝播モデル管理情報に基づいて、前記因果律を事前に作成させるか否か判断する、
ことを特徴とした方法。
１０．上記７．乃至９．のいずれか１つに記載のイベント解析方法であって、
前記記憶資源に、
（５）前記管理オブジェクトに対応する因果律の作成を事前に実行するか否かを示す事前展開可否情報、
を格納し、
（Ｆ）前記管理計算機がイベントを検知する前に、前記事前展開可否情報に基づいて、前記所定の管理オブジェクトに対応する前記因果律を事前に作成させるか否か判断する、
ことを特徴とした方法。
１１．上記７．乃至１０．のいずれか１つに記載のイベント解析方法であって、
前記記憶資源に、
（６）前記検知イベントに関する解析有効期間、
を格納し、
（Ｇ）前記解析有効期間後に、前記検知イベントに対応する前記第１の因果律を前記因果律情報から削除する、
ことを特徴とした方法。
１２．上記７．乃至１１．のいずれか１つに記載のイベント解析方法であって、
（Ｈ）前記第１の因果律が示す原因イベントと同じ原因を持つ他の因果律のオンデマンド展開を、前記第１の因果律に関するオンデマンド展開中は抑止する、
ことを特徴とした方法。
１３．複数の管理対象計算機と、
前記複数の管理対象計算機を管理し、記憶資源を有する管理計算機と、
を有する計算機システムであって、
前記記憶資源は、
（１）前記複数の管理対象計算機又は前記複数の管理計算機が含む複数のコンポーネントである複数の管理オブジェクトに関し、前記複数の管理オブジェクト同士の関係を示すトポロジと、
（２）イベント種別及びイベントが発生する管理オブジェクトの種別によって定義される、イベントと当該イベント発生原因となる原因イベントとの組の情報を含むイベント伝播モデルと、
（３）一つ以上の因果律を含む因果律情報と、
を格納し、
前記因果律とは、種別が種別１である第１の管理オブジェクトで発生する、種別が種別Ａである第１のイベントが原因で、種別が種別２である第２の管理オブジェクトで種別が種別Ｂである第２のイベントが発生すること、を示し、
前記管理計算機は、
（Ａ）所定の管理オブジェクトで発生した問題に関するイベントを検知し、
（Ｂ）前記検知イベントの解析に用いる第１の因果律が前記因果律情報に生成済みか判断し、
（Ｃ）（Ｂ）で未生成と判断した場合、前記トポロジと前記イベント伝播モデルに基づいて前記第１の因果律を前記因果律情報に生成するオンデマンド展開し、
（Ｄ）前記第１の因果律を用いて、前記検知イベントを解析する、
ことを特徴とした計算機システム。
１４．上記１３．記載の計算機システムであって、
前記管理計算機は、
前記検知イベント以外の、解析した前記第１の因果律に含まれるイベントの解析に用いる第２の因果律が、前記因果律情報に生成済みか判断し、未生成と判断した場合、前記第２の因果律に関してオンデマンド展開する、
ことを特徴とした計算機システム。
１５．上記１３．または１４．に記載の計算機システムであって、
前記記憶資源は、
（４）前記イベント伝播モデルに対応する因果律の作成を事前に実行するか否かを示す、イベント伝播モデル管理情報、
を格納し、
前記管理計算機がイベントを検知する前に、前記管理計算機は、
（Ｅ）前記イベント伝播モデル管理情報に基づいて、前記因果律を事前に作成するか否か判断する、
ことを特徴とした計算機システム。
１６．上記１３．乃至１５．のいずれか１つに記載の計算機システムであって、
前記記憶資源は、
（５）前記管理オブジェクトに対応する因果律の作成を事前に実行するか否かを示す事前展開可否情報、
を格納し、
前記管理計算機がイベントを検知する前に、前記管理計算機は、
（Ｆ）前記事前展開可否情報に基づいて、前記所定の管理オブジェクトに対応する前記因果律を事前に作成させるか否か判断する、
ことを特徴とした計算機システム。
１７．上記１３．乃至１６．のいずれか１つに記載の計算機システムであって、
前記記憶資源は、
（６）前記検知イベントに関する解析有効期間、
を格納し、
前記解析有効期間後に、前記管理計算機は、
（Ｇ）前記検知イベントに対応する前記第１の因果律を前記因果律情報から削除する、
ことを特徴とした計算機システム。
１８．上記１３．乃至１７．のいずれか１つに記載の計算機システムであって、
前記管理計算機は、
（Ｈ）前記第１の因果律が示す原因イベントと同じ原因を持つ他の因果律のオンデマンド展開を、前記第１の因果律に関するオンデマンド展開中は抑止する、
ことを特徴とした計算機システム。
【符号の説明】
【０２１１】
１００００：サーバ、２００００：ストレージ装置、３００００：管理サーバ、４００００：IPスイッチ、４５０００：ネットワーク
【図１】
0005938495.tif 000002
【図２】
0005938495.tif 000003
【図３】
0005938495.tif 000004
【図４】
0005938495.tif 000005
【図５】
0005938495.tif 000006
【図６Ａ】
0005938495.tif 000007
【図６Ｂ】
0005938495.tif 000008
【図６Ｃ】
0005938495.tif 000009
【図７】
0005938495.tif 000010
【図８Ａ】
0005938495.tif 000011
【図８Ｂ】
0005938495.tif 000012
【図９】
0005938495.tif 000013
【図１０】
0005938495.tif 000014
【図１１】
0005938495.tif 000015
【図１２】
0005938495.tif 000016
【図１３Ａ】
0005938495.tif 000017
【図１３Ｂ】
0005938495.tif 000018
【図１４Ａ】
0005938495.tif 000019
【図１４Ｂ】
0005938495.tif 000020
【図１４Ｃ】
0005938495.tif 000021
【図１４Ｄ】
0005938495.tif 000022
【図１４Ｅ】
0005938495.tif 000023
【図１５Ａ】
0005938495.tif 000024
【図１５Ｂ】
0005938495.tif 000025
【図１６】
0005938495.tif 000026
【図１７】
0005938495.tif 000027
【図１８】
0005938495.tif 000028
【図１９】
0005938495.tif 000029
【図２０】
0005938495.tif 000030
【図２１】
0005938495.tif 000031
【図２２】
0005938495.tif 000032
【図２３】
0005938495.tif 000033
【図２４Ａ】
0005938495.tif 000034
【図２４Ｂ】
0005938495.tif 000035
【図２５】
0005938495.tif 000036
【図２６】
0005938495.tif 000037
【図２７】
0005938495.tif 000038
【図２８】
0005938495.tif 000039
【図２９】
0005938495.tif 000040