JP5670598B2 - コンピュータプログラムおよび管理計算機 - Google Patents

Description

本発明は、コンピュータプログラムおよび管理計算機に関する。

特許文献１には、計算機システムの管理対象コンポーネントで発生した問題の原因を決定する管理サーバが開示されている。特許文献１の管理プログラムは、管理対象装置における各種障害をイベント化し、イベントデータベースに情報を蓄積する。

また、この管理プログラムは、管理対象装置において発生した複数の障害イベントの因果関係を解析するための解析エンジンを持っている。解析エンジンは、管理対象装置のインベントリ情報を持つ構成データベースにアクセスして、Ｉ／Ｏ（Input/Output）系路上のパス上にある管理対象装置内のコンポーネントを、「トポロジ」と呼ばれる一グループとして認識する。

そして、この解析エンジンは前記トポロジに対し、事前に定められた条件文と解析結果とからなる障害伝播モデル（ＩＦ−ＴＨＥＮ形式ルール）を適用して、因果律行列を構築する。因果律行列には、他装置における障害の原因である原因イベントと、それによって引き起こされている関連イベント群が含まれる。障害伝播モデルのＴＨＥＮ部に障害の根本原因として記載されているイベントが原因イベントであり、ＩＦ部に記載されているイベントのうち原因イベント以外のものが関連イベントである。

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

特許文献１に記載の従来技術では、管理対象の全ての装置及び全てのイベント伝播モデルに基づいて、イベント発生前に因果律を作成する。そのため、従来技術では、大規模又は多数の因果律が必要となる複雑な計算機システムを解析する場合は、因果律を格納するためのルールメモリのサイズが大きくなる。従って、従来技術では、管理計算機の記憶資源（例えば、メモリまたは二次記憶装置）を大量に消費する。

本発明は、上記の問題に鑑みてなされたもので、記憶資源を効率的に使用することができ、かつ、比較的速やかに原因を解析できるようにしたコンピュータプログラムおよび管理計算機を提供することにある。

本発明の一つの観点に係るコンピュータプログラムは、コンピュータを、複数の管理対象装置を含む計算機システムを管理するための管理計算機として機能させるためのコンピュータプログラムであって、所定の情報を記憶する記憶資源を利用することができ、所定の情報には、（１）複数の管理対象装置又は複数の管理対象装置が含む複数のコンポーネントである、複数の管理オブジェクトに関して、複数の管理オブジェクト同士の関係を示すトポロジと、（２）第１種別の管理オブジェクトで発生する所定種別の第１イベントが原因となって、第２種別の管理オブジェクトで他の所定種別の第２イベントが発生する、ことを示すイベント伝播モデルと、（３）一つ以上の因果律を含む因果律情報と、が含まれており、因果律は、第１種別を有する第１管理オブジェクトで発生する所定種別の第１イベントが原因となって、第２種別を有する第２管理オブジェクトで他の所定種別の第２イベントが発生すること、を示しており、（Ａ）所定の管理オブジェクトで発生した問題に関するイベントを検知し、（Ｂ）検知イベントが複数存在する場合に、それら複数のイベントのイベント重要度を判断し、（Ｃ）（Ｂ）で判断したイベント重要度の高いイベントから順に、トポロジとイベント伝播モデルとに基づいて所定の因果律を因果律情報に生成するためのオンデマンド展開を実行し、（Ｄ）所定の因果律に対し、検知イベントが発生済みであることを記録し、（Ｅ）所定の因果律を用いて、検知イベントを解析する、コンピュータプログラムである。

実施形態の概要を説明した模式図である。 計算機システムの物理構成例を示す図である。 ホストコンピュータの構成例を示す図である。 ストレージ装置の構成例を示す図である。 管理サーバの構成例を示す図である。 管理プログラムの論理的構成例を示した図である。 ＩＰスイッチの構成例を示す図である。 ホストコンピュータの有する論理ボリューム管理表の構成例を示す。 論理ボリューム管理表の他の例を示す。 論理ボリューム管理表のさらに他の例を示す。 ストレージ装置が含むボリューム管理表の構成例を示す図である。 ストレージ装置が含むｉＳＣＳＩターゲット管理表の構成例を示す。 ストレージ装置が含むＩ／Ｏポート管理表の構成例を示す図である。 ストレージ装置が含むＲＡＩＤグループ管理表の構成例を示す図である。 管理サーバが含むイベント管理表の構成例を示す図である。 管理サーバが含むイベント管理表の他の例を示す。 管理サーバが含むイベント伝播モデルの構成例を示す図である。 イベント伝播モデルの他の例を示す。 管理サーバが含むルールメモリの構成例を示す図である。 ルールメモリの他の例を示す。 ルールメモリのさらに他の例を示す。 ルールメモリの別の例を示す。 ルールメモリのさらに別の例を示す。 管理サーバが含むトポロジ生成方式の構成例を示す図である。 管理サーバが含むトポロジ生成方式の他の例を示す。 管理サーバが含む展開対象イベント伝播モデル管理表の構成例を示す。 管理サーバが含むイベント重要度管理表の構成例を示す図である。 管理サーバが実行する装置情報取得処理のフローチャートである。 管理サーバが実行するイベント確認処理のフローチャートである。 管理サーバが実行するイベント伝播モデルオンデマンド展開処理のフローチャートである。 実施例２において管理サーバが実行するイベント伝播モデルオンデマンド展開処理のフローチャートである。 図２２Ａに続くフローチャートである。 実施例３において管理サーバが含む関連機器数管理表の構成例を示す。 実施例３において管理サーバが実行するイベント伝播モデルオンデマンド展開処理のフローチャートである。 計算機システムの物理構成例を示す図である。 管理サーバが含むイベント管理表の構成例を示す図である。

以下、図面を参照して、実施例を説明する。なお、以後の説明では「ａａａテーブル」、「ａａａリスト」、「ａａａＤＢ」、「ａａａキュー」、「ａａａ行列」等の表現にて実施例の情報を説明するが、これら情報はテーブル、リスト、ＤＢ、キュー、行列、等のデータ構造以外で表現されていてもよい。そのため、データ構造に依存しないことを示すために「ａａａテーブル」、「ａａａリスト」、「ａａａＤＢ」、「ａａａキュー」、「ａａａリポジトリ」、「ａａａ行列」等について「ａａａ情報」と呼ぶことがある。さらに、各情報の内容を説明する際に、「識別情報」、「識別子」、「名」、「名前」、「ＩＤ」という表現を用いるが、これらについてはお互いに置換が可能である。さらに、データ内容を示すために「情報」という表現を用いているが、他の表現形式であってもよい。なお、実施例の説明において「リポジトリ」という用語を用いるが、「情報」と同じ意味である。

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

本実施形態の管理計算機は、計算機システムのトポロジと、イベント伝播モデルと、一つ以上の因果律を含む因果律情報とを、メモリ等の記憶領域に格納する。管理計算機がイベントを解析又は検知したことを契機として、管理計算機は、トポロジとイベント伝播モデルとに基づいて因果律を作成する。

管理計算機が複数のイベントを同時に検知した場合、イベントの重要度の高い順に因果律を作成する。作成された因果律は、因果律情報の一部として保存される。実施形態では、ルールメモリが因果律情報の一例である。

本実施形態では、イベントの検出時または解析時に、そのイベントの解析に必要な範囲内で、因果律を作成して記憶する。従って、因果律情報のサイズを必要最小限に止めることができ、記憶資源を効率的に使用することができる。さらに、本実施形態によれば、多数の障害イベントを同時に解析する場合、重要度の高いイベント（障害）について迅速に解析結果を得ることができる。

図１は、本実施形態の概要を示した図である。管理サーバ３００００は、計算機システム内の複数の管理対象装置を管理するための計算機である。図中、管理対象装置を装置と略記している。

管理対象装置の種別としては例えば、ホストコンピュータ（サーバ）、ＩＰスイッチまたはルータ等のネットワーク装置、ＮＡＳ（Network Attached Storage）またはストレージ装置等がある。

本実施形態では、管理対象装置が含むデバイス等の論理的又は物理的な構成物をコンポーネントと呼ぶ。コンポーネントの例としては通信ポート、マイクロプロセッサ、記憶資源、記憶デバイス、コンピュータプログラム、仮想マシン、論理ボリュームおよびＲＡＩＤグループ（ストレージ装置内部で定義される）等がある。なお、管理対象装置とコンポーネントを区別せずに扱う場合は、管理オブジェクトと呼ぶ。

管理サーバ３００００は、これら管理対象装置から装置情報を取得し、取得した装置情報に基づいて、管理対象装置の管理情報を表示する。装置情報には、例えば、管理対象装置の構成を示す構成情報と、管理対象装置で発生した障害情報と、管理対象装置の性能情報などを含めることができる。管理対象装置の管理情報には、例えば、管理対象装置の構成情報、障害発生の有無を示す情報、性能値を示す情報などが含まれる。

なお、いくつかの管理対象装置は、何かしらのネットワークサービス（例えば、ｉＳＣＳＩ、ファイル共有サービス、ＤＮＳ、その他Ｗｅｂサービス）のサーバである。他のいくつかの管理対象装置はクライアントとして、これらサーバが提供するネットワークサービスを利用する。

この場合、サーバである管理対象装置（サーバ装置と呼ぶことがある）でサービス提供に関係する問題（例えば管理オブジェクトの障害または性能障害等）が発生すると、当該サービスを利用しているクライアント管理対象装置（クライアント装置と呼ぶことがある）においても管理オブジェクトに関する問題が発生する。

なお、以後の説明では、管理オブジェクトで発生した問題を管理サーバで示す情報を、イベントと呼ぶ。また、「イベントの検知」とは「問題の発生を検知し、イベント情報を作成すること」を意味する。なお、「イベントの発生」とは、「問題の発生」と同じ意味である。

管理サーバ３００００は、ある管理対象装置で発生した問題の原因が他の管理対象装置で発生した問題であることを解析し、その解析結果を表示することができる。そのために管理サーバ３００００は以下の情報を格納しており、それらの情報を解析に用いる。

（情報１）構成情報

構成情報は、管理対象装置の構成を示す情報を格納する。管理対象装置の構成は、インベントリとも呼ばれる。構成情報には、管理対象装置が含むコンポーネントと、コンポーネント同士の対応関係のような管理オブジェクト間の対応関係とが含まれる。

構成情報には、クライアント装置に関して、ネットワークサービスを受けるためのサーバ装置（またはサーバ装置のコンポーネント）の識別情報が含まれる。例えば、後述するｉＳＣＳＩプロトコルによるＬＵ（Logical Unit）提供がネットワークサービスである場合を説明する。この場合、識別情報としてｉＳＣＳＩターゲット名とＬＵＮ（Logical Unit Number）を指定する。クライアント装置は、その識別情報に基づいて、ストレージ装置が提供するＬＵにアクセスする。ネットワークサービスがＷｅｂサービスである場合は、識別情報としてＷｅｂサーバのＵＲＬ（Uniform Resource Locator）を指定する。クライアント装置は、ＵＲＬに基づいてＷｅｂページにアクセスする。

構成情報には、サーバ装置に関して、アクセス元となるクライアント装置に関する識別情報を含む場合もある。このような管理対象装置内又は複数の管理対象装置に跨る、複数の管理オブジェクト間の関係を、トポロジと呼ぶ。

（情報２）イベント伝播モデルの情報

イベント伝搬モデルの情報（以後、単にイベント伝播モデルと呼ぶ）には、一つ以上の観測種別ペアと一つ以上の原因種別ペアとが含まれる。詳細は以下の通りである。

（２Ａ）原因種別ペア

原因種別ペアとは、管理オブジェクトの種別（管理オブジェクト原因種別と呼ぶことがある）と、イベントの種別（イベント原因種別）とのペアである。イベント原因種別は、管理オブジェクト原因種別で定められる種別の管理オブジェクトで発生する可能性のあるイベントの種別である。

（２Ｂ）観測種別ペア

観測種別ペアとは、管理オブジェクトの種別（管理オブジェクト観測種別と呼ぶことがある）と、イベントの種別（イベント観測種別）とのペアである。イベント観測種別は、管理オブジェクト観測種別で定められる種別の管理オブジェクトで発生する可能性のあるイベントの種別である。観測種別ペアは、原因種別ペアの種別で定められるイベントが発生した場合に、合わせて発生するイベントの種別を示す。

なお、あるイベント伝播モデルに含まれる観測種別ペアのイベントを全て検知した場合に、対応する原因種別ペアのイベント発生が原因であるほうがより好ましいが、必須ではない。

管理サーバ３００００による解析処理は、より具体的には、イベント伝播モデルとトポロジとに基づいて、因果律を因果律情報に作成する。管理サーバ３００００の解析処理は、因果律情報を用いてイベントを解析する。

因果律とは、第１の管理オブジェクトで第１のイベントが発生した場合は、第２の管理オブジェクトで第２のイベントが発生することを示す情報である。第１のイベントが原因であると断定できる条件は、第１のイベントに関連した全ての第２イベントを検知すること、であるほうが望ましい。ただしこれは必須ではない。因果律情報は上記内容を示すことが出来れば、因果律行列の形式であってもよい。または、因果律情報は、関係を示すポインタ情報を駆使して第１のイベントと第２のイベントとの関係を示したデータ構造であってもよい。

管理サーバ３００００は、オンデマンドでイベントコリレーション情報を作成する。つまり、管理サーバ３００００は、その存在を検知したが未解析の所定イベントに対応するイベントコリレーション情報がイベントリポジトリに作成済みか否か判断する。管理サーバ３００００は、イベントコリレーション情報を未作成の場合、所定イベントが関係するトポロジと、所定イベントが関係するイベント伝播モデルとを用いて、イベントコリレーション情報を作成し、所定イベントを解析する。

イベント解析の例としては以下が考えられる。

（解析例１） イベント解析例１では、検知した或るイベント１の原因となるイベント２を特定する。この特定処理は、因果律情報を参照することで可能である。管理サーバ（または後述する管理システム）は、自身の表示デバイスにイベント１の情報と共に、イベント２が原因で当該イベント１が発生した旨のメッセージを表示してもよい。

（解析例２） イベント解析例２では、検知した或るイベント３を原因として発生する（または発生する可能性がある）イベント４を求める。この特定処理は、因果律情報を参照することで可能である。管理サーバ（または管理システム）は、自身の表示デバイスに、イベント３の発生が原因となってイベント４が発生する（または発生する可能性がある）旨のメッセージを表示してもよい。

管理サーバ３００００は、イベントを検知した後に、（１）その検知イベントを観測種別ペアまたは原因種別ペアに含むイベント伝播モデルと、（２）その検知イベントが発生したコンポーネントと関係するトポロジと、に基づいて、所定の因果律を因果律情報に作成する。所定の因果律を因果律情報に作成することを、後述の説明では、因果律を展開するとも言う。

なお、このようなイベント検知を契機として因果律を展開することを、オンデマンド展開と呼ぶ。オンデマンド展開によって、大規模な計算機システムまたは複雑な計算機システムを対象にしたイベント解析でも因果律情報のサイズをより少なくできる。

管理サーバ３００００が複数のイベントを検知した際は、イベントに付与された重要度の高いイベントから順に、因果律の展開処理を行う。その結果、管理サーバ３００００の管理する計算機システムが大規模化したり、または、管理サーバ３００００が単位時間当たりに検知する障害の数が増大したりしても、重要度の高い障害の解析が遅れることを抑制できる。

イベントの重要度を定義する指標としては、以下の例が挙げられる。（指標例１）管理オブジェクトの種別ごとにまたはイベントの種別ごとに事前に付与された重要度、（指標例２）障害の発生した機器の重要度または障害の発生した業務の重要度、（指標例３）性能障害の場合、閾値またはベースラインからの計測値の逸脱度。

イベントの重要度を定義する指標として、上記の例などが考えられるが、上記の例以外の他の指標を用いてもよい。また、イベントの展開処理を行う順序を決定する際、イベントを検知した時刻を考慮してもよいし、考慮しなくてもよい。

次に、管理サーバ３００００は、検知イベントを含む因果律情報を参照し、因果律情報内に定義された観測種別ペアのうち幾つが実際に発生しているかを調査する。さらに、管理サーバ３００００は、実際に発生したイベントが定義された観測種別ペアに占める割合を「確信度」として算出する（確信度＝実際に発生したイベントの数／定義された観測種別ペアの数）。確信度は、因果律情報内に定義された原因種別ペアの確からしさを示す指標とすることができる。

解析開始から長時間経過すると、様々な管理オブジェクトから様々な種別のイベントを検知する傾向にある。そのため、管理サーバ３００００は、イベントに有効期間を与え、有効期間を過ぎたイベントは解析対象から外してもよい。このようにすることで、時系列の大きく離れたイベント同士を解析対象とすることによる、解析結果へのノイズの発生を軽減することができる。

図１の下側に示すように、コンポーネント１（種別ａ）で発生するイベントＡ１（種別Ａ）の原因が、コンポーネント２（種別ｂ）で発生するイベントＢ２（種別Ｂ）であることを示す、イベントコリレーション１が作成済みである。図１は、このイベントコリレーション１が作成済みの状況下において、コンポーネント３（種別ａ）でのイベントＡ３（種別Ａ）を実際に検知した場合の概要を示している。

なお、イベントコリレーション１は、過去にイベントＡ１を検知したときを契機に、トポロジ１とイベント伝播モデル１とに基づいて、いわゆるオンデマンドで作成したものである。ルールメモリに空き容量がある限り、かつ管理対象オブジェクトの構成に変化がない限り、過去に作成されたイベントコリレーションは保存される。

イベントコリレーション１が作成済みの状況下においてコンポーネント３（種別ａ）でイベントＡ３（種別Ａ）が検出されると、管理サーバ３００００は、トポロジ２とイベント伝播モデル１とに基づいてイベントコリレーション２を作成する。イベントコリレーション２は、イベントＡ３（種別Ａ）の原因はコンポーネント２（種別ｂ）で発生するイベントＢ２（種別Ｂ）であることを示す。

因果律を作成済みであるか判断する場合または因果律を展開する場合、イベント伝播モデルの個々にアクセスして、イベント伝播モデルとイベントとの関係性を判断したとすると、イベント伝播モデル数に比例して処理時間が長くなる。そのため、管理サーバ３００００は、管理オブジェクトの種別とそこで発生するイベントの種別のペアとから、当該ペアを原因種別ペアまたは観測種別ペアに含むイベント伝播モデルのＩＤを特定可能なデータ構造を事前に作成してもよい。管理サーバ３００００は、因果律を作成済みであるか判断する場合または因果律を展開する場合に、そのデータ構造を参照してもよい。これにより、処理時間を短縮できる。

以上が本実施例の概要である。以後の記載では、以下の場合を例示する。本発明は以下の例に限定されない。

＊ ネットワークサービス：ネットワークサービスとしては、ｉＳＣＳＩプロトコルによるストレージアクセスを例に挙げる。この場合、クライアント装置がホストコンピュータとなり、サーバ装置がストレージ装置となる。

＊ イベントコリレーション情報：イベントコリレーション情報の例としてルールメモリを挙げる。

＊ 管理対象装置： 管理対象装置の例として、ホストコンピュータ、ＩＰスイッチ、ストレージ装置を挙げる。

＊ 管理オブジェクト：管理オブジェクトの例として、コンポーネントを挙げる。

＊ コンポーネント：コンポーネントの例として、ｉＳＣＳＩターゲット、ボリューム、ＲＡＩＤグループ、ディスク、ホストコンピュータのドライブ名を挙げる。

＊ イベント重要度の定義指標：イベント重要度を定義するための指標として、管理オブジェクトの種別、または、イベント種別ごとに事前に付与された重要度を例に挙げて説明する。

図２から図７は、計算機システムの構成と、計算機システムに接続される装置の構成とを示す。図８から図１８は、各装置に具備される管理情報を示す。

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

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

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

図３は、ホストコンピュータ１００００の詳細な内部構成例を示す図である。ホストコンピュータ１００１０も同様の構成を有する。ホストコンピュータ１００００は、ネットワーク４５０００に接続するための通信ポート１１０００と、プロセッサ１２０００と、メモリ１３０００と、を有し、これらは内部バス等の回路を介して相互に接続される構成となっている。

メモリ１３０００は、ディスク装置などを含む構成でもよい。メモリ１３０００には、業務アプリケーションプログラム１３１００と、オペレーティングシステム１３２００と、論理ボリューム管理表１３３００と、が格納される。

業務アプリケーション１３１００は、オペレーティングシステム１３２００から提供された記憶領域を使用し、その記憶領域に対してデータを入出力させる。以下、データ入出力のことをＩ／Ｏと表記する場合がある。

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

ポート１１０００は、Ｉ／Ｏポートと管理ポートを含む単一のポートであるかのように、図３で示されている。Ｉ／Ｏポートとは、ストレージ装置２００００とｉＳＣＳＩにより通信を行うためのポートである。管理ポートとは、管理サーバ３００００がホストコンピュータ内の管理情報を取得するためのポートである。Ｉ／Ｏポートと管理ポートとがそれぞれ別々に設けられる構成でもよい。

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

ストレージ装置２００００は、複数のＩ／Ｏポート２１０００，２１０１０と、一つの管理ポート２１１００と、管理メモリ２３０００と、ＲＡＩＤグループ２４０００，２４０１０と、記憶デバイス２４２００，２４２１０，２４２２０，２４２３０と、論理ボリューム２４１００，２４１１０と、コントローラ２５０００，２５０１０と備える。それらのうち物理的構成（Ｉ／Ｏポート、管理ポート、管理メモリ、コントローラ、記憶デバイス）は、内部バス等の回路を介して相互に接続されている。

Ｉ／Ｏポート２１０００は、ネットワーク４５０１０を介してホストコンピュータ１００００、１００１０に接続するためのポートである。同様に、Ｉ／Ｏポート２１０１０は、ネットワーク４５０２０を介してホストコンピュータ１００００，１００１０に接続するための回路である。管理ポート２１１００は、ネットワーク４５０００を介して管理サーバ３００００に接続するためのポートである。ネットワーク４５０１０，４５０２０は、ネットワーク４５０００の一部である。

管理メモリ２３０００は、後述のように、各種管理情報を格納する。ＲＡＩＤグループ２４０００，２４０１０は、データを格納する。コントローラ２５０００，２５０１０は、データと管理メモリ内の管理情報とを制御する。

管理メモリ２３０００には、ストレージ装置２００００を管理するプログラム２３１００と、ボリューム管理表２３２００と、ｉＳＣＳＩターゲット管理表２３３００と、Ｉ／Ｏポート管理表２３４００と、ＲＡＩＤグループ管理表２３５００と、ディスク管理表２３６００とが格納される。管理プログラム２３１００は、管理ポート２１１００を経由して管理サーバ３００００と通信し、管理サーバ３００００にストレージ装置２００００の構成情報を提供する。

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

論理ボリューム２４１００及び２４１１０は、１つ以上の記憶デバイスの記憶領域を用いて構成することができる。論理ボリューム２４１００，２４１１０は、必ずしもＲＡＩＤ構成を備える必要はない。

記憶デバイス２４２００−２４２３０は、例えば、ハードディスクデバイス、半導体メモリデバイス、光ディスクデバイス、光磁気ディスクデバイス等のデータを読み書き可能な種々の記憶デバイスとして構成可能である。

記憶デバイス２４２００−２４２３０がハードディスクデバイスである場合、例えば、ＦＣ（Fibre Channel）ディスク、ＳＣＳＩ（Small Computer System Interface）ディスク、ＳＡＴＡディスク、ＡＴＡ（AT Attachment）ディスク、ＳＡＳ（Serial Attached SCSI）ディスク等のように構成することができる。

記憶デバイス２４２００−２４２３０は、例えば、フラッシュメモリ、ＦｅＲＡＭ（Ferroelectric Random Access Memory）、ＭＲＡＭ（MagnetoresistiveRandom Access Memory）、相変化メモリ（Ovonic Unified Memory）、ＲＲＡＭ（登録商標：Resistance RAM）等の種々の記憶デバイスとして構成してもよい。さらに、フラッシュメモリデバイスとして構成される記憶デバイスと、ハードディスクデバイスとして構成される記憶デバイスとが混在する構成でもよい。

コントローラ２５０００及び２５０１０は、ストレージ装置２００００内の制御を行うプロセッサと、ホストコンピュータ１００００，１００１０との間でやりとりするデータを一時的に記憶するキャッシュメモリとを備える（いずれも不図示）。そして、それぞれのコントローラ２５０００，２５０１０は、Ｉ／Ｏポート２１０００，２１０１０とＲＡＩＤグループ２４０００，２４０１０との間に介在しており、各Ｉ／Ｏポートと各ＲＡＩＤグループとの間でのデータ受け渡しを制御する。

ストレージ装置２００００は、上記の構成以外の構成であってもよい。ストレージ装置は、ホストコンピュータに論理ボリュームを提供し、ホストコンピュータから受信したアクセス要求（Ｉ／Ｏ要求）に応じて記憶デバイスに読み書きできる構成を備えていれば、どのような構成であってもよい。例えば、ストレージコントローラと記憶デバイスとをそれぞれ別々の筐体に格納する構成でもよい。

図４の例では、例えば、ストレージコントローラを、管理メモリ２３０００と、コントローラ２５０００及び２５１１０等とから構成してもよい。本明細書では、ストレージコントローラと記憶デバイスとが同一筐体に存在する場合、または別々の筐体に存在する場合の両方の場合を含む表現として、ストレージ装置をストレージシステムと呼び変えても良い。

図５及び図６は、管理サーバ３００００の詳細な内部構成例を示す図である。管理サーバ３００００は、例えば、管理ポート３１０００と、プロセッサ３１１００と、記憶資源３３０００と、出力デバイス３４０００と、入力デバイス３４１００とを有し、これらが内部バス等の回路を介して相互に接続されている。

管理ポート３１０００は、ネットワーク４５０００を介して管理対象装置であるホストコンピュータとストレージ装置およびスイッチに接続される。記憶資源３３０００は、半導体メモリ装置および／または補助記憶装置から構成してもよい。

出力デバイス３４０００は、後述する処理結果を出力するための装置である。出力デバイス３４０００は、例えば、ディスプレイ装置、プリンタ装置、音声合成装置のように構成できる。入力デバイス３４１００は、ストレージ管理者がストレージ装置に指示を入力するための装置である。入力デバイス３４１００は、例えば、キーボードスイッチ、タッチパネル、音声入力装置のように構成できる。

記憶資源３３０００には、管理プログラム３２０００が格納される。図６に示すように管理プログラム３２０００は、プログラム制御モジュール３２１００と、装置情報取得モジュール３２２００と、ＧＵＩ表示処理モジュール３２３００と、イベント解析処理モジュール３２４００と、イベント伝播モデル展開モジュール３２５００と、を含む。

各モジュールは、メモリ３２０００に格納されるプログラムモジュールとして提供されているが、ハードウェアモジュールとして提供されてもよい。管理プログラム３２０００は、各モジュールの処理を実現できるのであれば、モジュールによって構成されなくてもよい。言い方を変えれば、以下の説明における各モジュールについての説明は、管理プログラム３２０００に関する説明と置き換えてもよいということである。

図５に戻る。記憶資源３３０００にはさらに、イベント管理表３３１００と、イベント伝播モデルリポジトリ３３２００と、ルールメモリ３３３００と、トポロジ生成方式リポジトリ３３４００と、構成ＤＢ３３５００と、展開対象イベント伝播モデル管理表３３６００と、イベント重要度管理表３３７００と、関連装置数管理表３３８００と、が格納されている。構成ＤＢ３３５００には、構成情報が格納される。

構成情報は、装置情報取得モジュール３２２００によって、各管理対象装置から収集される。構成情報には、例えば、管理対象の各ホストコンピュータから収集された論理ボリューム管理表１３３００の各項目と、管理対象の各ストレージから収集されたボリューム管理表２３２００の各項目と、ｉＳＣＳＩターゲット管理表２３３００各項目と、Ｉ／Ｏポート管理表２３４００各項目と、ＲＡＩＤグループ管理表２３５００各項目とが含まれている。

構成ＤＢ３３５００には、管理対象装置の有する全ての表、または表中の全ての項目を格納しなくてもよい。その都度必要に応じて、管理サーバ３００００が管理対象装置から情報を取得する構成でもよい。

構成ＤＢ３３５００が格納する各項目のデータ表現形式またはデータ構造は、管理対象装置と同一である必要はない。管理プログラム３２０００が管理対象装置からこれら各項目を受信する場合、管理対象装置で使用するデータ構造またはデータ表現形式のままで受信してもよい。

装置情報取得モジュール３２２００は、管理対象装置に定期的または不定期に繰り返しアクセスして、管理対象装置の構成情報と、管理対象装置内の各コンポーネントの状態とを取得する。イベント解析処理モジュール３２４００は、ルールメモリ３３３００を参照して、管理対象装置で生じた異常状態の根本原因を解析する。管理対象装置で発生した異常状態に関する情報は、装置情報取得モジュール３２２００により取得される。

ＧＵＩ表示処理モジュール３２３００は、入力デバイス３４１００を介した管理者からの要求に応じて、構成管理情報などを出力デバイス３４０００に表示する。入力デバイス３４１００と出力デバイス３４０００とはそれぞれ別々なデバイスとして構成されてもよいし、または、タブレット型端末のように一つのまとまったデバイスとして構成されてもよい。

なお、管理サーバ（管理計算機）は、例えば、入出力デバイスとして、ディスプレイとキーボードとポインタデバイス等を有しているが、これ以外の装置であってもよい。入出力デバイスの代替としてシリアルインターフェースやイーサーネットインターフェース（イーサネットは登録商標）を用い、それらインターフェースに表示用計算機を接続する構成でもよい。

表示用計算機は、例えばＷＥＢブラウザ起動サーバ３５０００として構成され、ディスプレイ装置、およびキーボードまたはポインタデバイスを有する。管理サーバは、表示用情報を表示用計算機に送信して表示させたり、入力用情報を表示用計算機から受信して受け付けたりすることができる。つまり、管理サーバ３００００の外部にマンマシンインターフェース機能を有する表示用計算機を設ける構成の場合、出力デバイス３４０００および入力デバイス３４１００を省略することができる。

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

図７にＩＰスイッチ４００００の詳細な構成を示す。ＩＰスイッチ４００１０も同様の構成を有する。ＩＰスイッチ４００００は、プロセッサ４１０００と、各種管理情報を保持するためのメモリ４２０００と、Ｉ／Ｏポート４３０００，４３０１０と、管理ポート４４０００とを有し、これらは内部バス等の回路を介して相互に接続される。Ｉ／Ｏポート４３０００はネットワーク４５０１０に接続され、Ｉ／Ｏポート４３０１０はネットワーク４５０２０に接続され、管理ポート４４０００はネットワーク４５０００に接続されている。

メモリ４２０００は、その全部を半導体メモリから構成してもよいし、ハードディスク装置のような他の記憶デバイスを含んで構成してもよい。

図８Ａ、８Ｂ及び８Ｃは、ホストコンピュータ１００００の具備する論理ボリューム管理表１３３００の構成例を示す図である。

論理ボリューム管理表１３３００は、論理ボリュームを管理するための表であり、フィールド１３３１０，１３３２０，１３３３０，１３３４０を備える。フィールド１３３１０には、ホストコンピュータ内で各論理ボリュームを識別するための識別子（ドライブ名）を登録する。フィールド１３３２０には、ｉＳＣＳＩイニシエータ名を登録する。ｉＳＣＳＩイニシエータ名は、論理ボリュームの実体が存在するストレージ装置との通信の際に用いる、ホストコンピュータ上のＩ／Ｏポート１１０００の識別子である。

フィールド１３３３０には、接続先のｉＳＣＳＩターゲットを登録する。ｉＳＣＳＩターゲットは、論理ボリュームの実体が存在するストレージ装置との通信の際に用いる、ストレージ装置上のＩ／Ｏポート２１０００の識別子である。フィールド１３３４０には、ストレージ装置において論理ボリュームの識別子となるＬＵＮ ＩＤを登録する。

図８Ａには、ホストコンピュータの具備する論理ボリューム管理表１３３００の具体的な値の一例を示している。

つまり、ホストコンピュータ上で（Ｅ：）というドライブ名で示される論理ボリュームは、”ｃｏｍ．ｈｉｔａｃｈｉ．ｓｖ１”というｉＳＣＳＩイニシエータ名で示されるホストコンピュータ上のポートと、”ｃｏｍ．ｈｉｔａｃｈｉ．ｓｔｏ１”というｉＳＣＳＩターゲット名で示されるストレージ装置上のポートとを介してストレージ装置と接続しており、”０”というＬＵＮ ＩＤをストレージ装置上で持つ。

図９は、ストレージ装置２００００の具備するボリューム管理表２３２００を示す図である。

ボリューム管理表２３２００は、フィールド２３２１０，２３２２０，２３２３０，２３２４０，２３２５０を備える。フィールド２３２１０には、ストレージ装置内で各論理ボリュームの識別子となるボリュームＩＤを登録する。フィールド２３２２０には、各論理ボリュームの容量を登録する。フィールド２３２３０には、各論理ボリュームが所属するＲＡＩＤグループの識別子であるＲＡＩＤグループＩＤを登録する。

フィールド２３２４０には、各論理ボリュームが所属するｉＳＣＳＩターゲットの識別子であるターゲットＩＤを登録する。フィールド２３２５０には、各論理ボリュームのｉＳＣＳＩターゲット内での識別子であるＬＵＮ ＩＤを登録する。

図９には、ストレージ装置の具備するボリューム管理表２３２００の具体的な値の一例を示している。つまり、ストレージ装置上のボリューム”ＶＯＬ１”は、”２０ＧＢ”の記憶領域を持ち、”ＲＧ１”というＲＡＩＤグループＩＤで示されるＲＡＩＤグループに属し、”ＴＧ１”というｉＳＣＳＩターゲットＩＤで示されるｉＳＣＳＩターゲットに属し、”０”というＬＵＮ ＩＤを持つ。

図１０は、ストレージ装置２００００の具備するｉＳＣＳＩターゲット管理表２３３００を示す図である。

ｉＳＣＳＩターゲット管理表２３３００は、フィールド２３３１０，２３３２０，２３３３０を備える。フィールド２３３１０には、ストレージ装置内でｉＳＣＳＩターゲットの識別子となるターゲットＩＤを登録する。フィールド２３３２０には、各ｉＳＣＳＩターゲットが持つｉＳＣＳＩターゲット名を登録する。フィールド２３３３０には、各ｉＳＣＳＩターゲットに属するボリュームに対してアクセスが許可された、ホストコンピュータ上のポートの識別子であるｉＳＣＳＩイニシエータ名を登録する。

図１０には、ストレージ装置の具備するｉＳＣＳＩターゲット管理表２３３００の具体的な値の一例を示している。つまり、ストレージ装置上のｉＳＣＳＩターゲット”ＨＧ１”は、”ｃｏｍ．ｈｉｔａｃｈｉ．ｓｔｏ１”でというｉＳＣＳＩターゲット名を持ち、ｉＳＣＳＩイニシエータ名が”ｃｏｍ．ｈｉｔａｃｈｉ．ｓｖ１”であるホストコンピュータ上のポートからのアクセスを許可している。

図１１は、ストレージ装置２００００の具備するＩ／Ｏポート管理表２３４００の構成を示す図である。

Ｉ／Ｏポート管理表２３４００は、ストレージ装置の各ポートの識別子であるポートＩＤを登録するフィールド２３４１０と、各ポートのネットワーク４５０００上での識別子であるＭＡＣアドレスを登録するためのフィールド２３４２０と、を構成項目として含んでいる。

図１１には、ストレージ装置の具備するＩ／Ｏポート管理表２３４００の具体的な値の一例を示している。つまり、ストレージ装置上のポート”ＰＯＲＴ１”は、”ＴＧ１，ＴＧ２”というｉＳＣＳＩターゲットＩＤで示されるｉＳＣＳＩターゲットによって使用されている。

図１２は、ストレージ装置２００００の具備するＲＡＩＤグループ管理表２３５００の構成を示す図である。

ＲＡＩＤグループ管理表２３５００は、フィールド２３５１０，２３５２０，２３５３０を備えている。フィールド２３５１０には、ストレージ装置内の各ＲＡＩＤグループの識別子であるＲＡＩＤグループＩＤを登録する。フィールド２３５２０には、ＲＡＩＤグループのＲＡＩＤレベルを登録する。フィールド２３５３０には、各ＲＡＩＤグループの容量を登録する。

図１２には、ストレージ装置の具備するＲＡＩＤグループ管理表２３５００の具体的な値の一例を示している。つまり、ストレージ装置上のＲＡＩＤグループ”ＲＧ１”は、ＲＡＩＤレベルが”ＲＡＩＤ１”であり、容量は”１００ＧＢ”である。

図１３Ａ及び１３Ｂは、管理サーバ３００００が有するイベント管理表３３１００の構成例を示す図である。

イベント管理表３３１００は、フィールド３３１１０，３３１２０，３３１３０，３３１４０，３３１５０，３３１６０，３３１７０を備える。フィールド３３１１０には、イベントの識別子であるイベントＩＤを登録する。フィールド３３１２０には、構成情報の変化といったイベントの発生した装置の識別子である装置ＩＤを登録する。フィールド３３１３０には、イベントの発生した装置内のコンポーネントの識別子を登録する。フィールド３３１４０には、発生したイベントの種別を登録する。

フィールド３３１５０には、発生したイベントの重要度を登録する。フィールド３３１６０には、後述するイベント伝播モデル展開モジュール３２５００によってイベントが処理済みかどうかを登録する。フィールド３３１７０には、イベントが発生した日時を登録する。

例えば、図１３Ａの第１行目（１つ目のエントリ）に着目すると、管理サーバ３００００が、ストレージ装置”ＳＹＳ１”の、”ＤＩＳＫ１”で示されるディスクにおける状態異常を検知したことと、その状態異常のイベントの重要度は”１”であり、そのイベントＩＤは”ＥＶ１”であることとが、分かる。

図１４Ａ及び１４Ｂは、管理サーバ３００００が有するイベント伝播モデルリポジトリ３３２００内のイベント伝播モデルの構成例を示す図である。障害解析において根本原因を特定するために使用されるイベント伝播モデルは、ある障害の結果発生することが予想されるイベントの組み合わせと、その障害の根本原因とを、”ＩＦ−ＴＨＥＮ”形式で記載している。

イベント伝播モデルは、図１４Ａ及び図１４Ｂに挙げられたものに限られず、さらに多くのルールがあっても構わない。イベント伝播モデルリポジトリ３３２００には、複数のイベント伝播モデルを含んでも良い。

イベント伝播モデルは、イベント伝播モデルの識別子となるイベント伝播モデルＩＤを登録するフィールド３３２１０と、”ＩＦ−ＴＨＥＮ”形式で記載したイベント伝播モデルのＩＦ部に相当する観測イベント種別を登録するフィールド３３２２０と、”ＩＦ−ＴＨＥＮ”形式で記載したイベント伝播モデルのＴＨＥＮ部に相当する原因イベント種別を登録するためのフィールド３３２３０と、を構成項目として含んでいる。結論部のステータスが正常になれば、条件部の問題も解決しているという関係にある。

図１４Ａには、管理サーバ３００００が有するイベント伝播モデルの具体的な値の一例を示している。つまり、イベント伝播モデルＩＤが”Ｒｕｌｅ１”で示されるイベント伝播モデルにおいては、観測イベント種別として”ホストコンピュータ上の論理ボリュームの状態異常”と、”ストレージ装置上のボリュームの状態異常”とを検知した場合に、”ストレージ装置のボリュームの故障が原因である”と結論付ける。

図１５Ａ乃至１５Ｅは、管理サーバ３００００の具備するルールメモリ３３３００の構成を示す図である。以下で述べる因果律とは、”ＩＦ−ＴＨＥＮ”形式で記載されたイベント伝播モデルに基づいて作成した、どのイベントを受信した際に何を根本原因であると結論づけるかという対応関係を表す情報である。

ルールメモリ３３３００は、以下の情報を含む。

＊ 管理サーバの装置情報取得モジュール３２２００が検知するイベントを特定するイベント特定情報（図中では管理オブジェクトの識別子（つまり装置ＩＤとコンポーネントＩＤ）とイベントの種別）と、前記イベント特定情報に合致するイベントを実際に受信した日時を登録するフィールド３３３１０。なお、前記イベント受信日時が未登録の場合、当該イベントは未受信であるものと、みなされる。

＊ 前記フィールド３３３１０に記載のイベントが、因果律において否定条件であるか否かを登録するフィールド３３３２０。

＊ 前記フィールド３３３１０に記載のイベントを検知した際、イベント解析処理モジュール３２４００が障害の原因として結論付ける原因イベントを登録するための情報（図中では管理オブジェクトの識別子（つまり装置ＩＤとコンポーネントＩＤ）とイベントの種別）と、前記原因イベントを含む因果律のＩＤと、前記因果律の展開の際使用したイベント伝播モデルのＩＤと、を登録するフィールド３３３３０。

上記フィールド３３３１０とフィールド３３３２０の間、およびフィールド３３３２０とフィールド３３３３０の間には相互に接続関係があり、一方のフィールドと関連する他方のフィールドを呼び出すことができる。

図１５Ａには、管理サーバ３００００の具備するルールメモリ３３３００の具体的な値の一例を示している。つまり、ストレージ装置”ＳＹＳ１”のボリューム”ＶＯＬ１”の状態異常と、ホスト”ＨＯＳＴ１”の論理ボリューム（Ｅ：）の状態異常というイベントを装置情報取得モジュール３２２００が検知したとき、イベント解析処理モジュール３２４００は、ストレージ装置”ＳＹＳ１”のボリューム”ＶＯＬ１”の故障が根本原因であると結論付ける。

ルールメモリ３３３００は、行列構造であってもよい。因果律の追加および削除をより効率的に行うために、ルールメモリ３３３００は、動的に行列のサイズを変更可能なデータ構造でもよい。例えば、所定の行数または列数毎にサブ行列化して、それらをポインタまたはインデックスで関係付けることで、仮想的な行列を見せることができる。

図１６Ａ及び１６Ｂは、管理サーバ３００００が有するトポロジ生成方式リポジトリ３３４００内のトポロジ生成方式情報（省略してトポロジ生成方式と呼ぶことがある）の構成例を示す図である。

トポロジ生成方式は、管理サーバ３００００が管理対象装置から取得した構成情報に基づき、監視対象となる複数の装置間での接続関係（トポロジ）を生成するための手段を定義した情報である。

トポロジ生成方式は、トポロジの識別子となるトポロジＩＤを登録するフィールド３３４１０と、トポロジを生成する際の起点となる管理対象装置内のコンポーネント種別を登録するフィールド３３４２０と、トポロジを生成する際の終点となるコンポーネント種別を登録するフィールド３３４３０と、前記起点コンポーネント−終点コンポーネント間のトポロジ生成の際に経由する必要のあるコンポーネント種別を登録するフィールド３３４４０と、前記起点コンポーネント−終点コンポーネント間のトポロジ生成方法を登録するフィールド３３４５０と、を構成項目として含んでいる。

図１６Ａには、管理サーバ３００００の具備するトポロジ生成方式の具体的な値の一例を示している。つまり、ストレージ装置内のボリュームを起点とし、ホストコンピュータ内の論理ボリュームを終点とするトポロジは、論理ボリュームのｉＳＣＳＩイニシエータ名が、ｉＳＣＳＩターゲットの接続許可ｉＳＣＳＩイニシエータと等しく、かつボリューム内のｉＳＣＳＩターゲットＩＤが、ｉＳＣＳＩターゲット内のＩＤと等しい、組み合わせを検索することにより取得可能である。

図１７は、管理サーバ３００００の具備する展開対象イベント伝播モデル管理表３３６００の構成例を示す図である。

展開対象イベント伝播モデル管理表３３６００は、障害イベントの発生した装置の種別を登録するフィールド３３６１０と、前記イベントの発生した装置内のコンポーネントの種別を登録するフィールド３３６２０と、前記イベントの種別を登録するフィールド３３６３０と、イベントが後述するイベント解析処理モジュール３２５００によって処理される際に、どのイベント伝播モデルが展開対象となるかを登録するフィールド３３６４０と、を構成項目として含んでいる。

図１７には、管理サーバ３００００の具備する展開対象イベント伝播モデル管理表の具体的な値の一例を示している。つまり、”ホストコンピュータにおける論理ボリュームの状態異常”というイベントが発生した場合、”Ｒｕｌｅ１”というＩＤで示されるイベント伝播モデルを再展開する必要がある。

図１８は、管理サーバ３００００の具備するイベント重要度管理表３３７００の構成例を示す図である。

イベント重要度管理表３３７００は、障害イベントの発生した装置の種別を登録するフィールド３３７１０と、前記イベントの発生した装置内のコンポーネントの種別を登録するフィールド３３７２０と、前記イベントの種別を登録するフィールド３３７３０と、イベントの重要度を表すパラメータを登録するフィールド３３７４０と、を構成項目として含んでいる。

図１８には、管理サーバ３００００の具備する展開対象イベント伝播モデル管理表の具体的な値の一例を示している。つまり、”ホストコンピュータにおける論理ボリュームの状態異常”というイベントが発生した場合、その重要度は”５”である。

管理サーバ３００００が実行する処理方式を図１９、図２０及び図２１に示す。

図１９に、管理サーバ３００００の装置情報取得モジュール３２２００が実施する装置情報取得処理のフローチャートを示す。

プログラム制御モジュール３２１００は、前回の装置情報取得処理から一定時間経過するたびに、装置情報取得モジュール３２２００に対し、装置情報取得処理を実行するよう指示する。なお、その実行指示は厳密に一定期間毎に出される必要は無く、繰り返し出されていればよい。装置から取得する情報には、装置の状態情報または性能情報が含まれるが、これらの情報をそれぞれ異なるタイミングで取得してもよい。

装置情報取得モジュール３２２００は、一つ以上の管理対象装置の各々に対し、以下の一連の処理を繰り返す（ステップ６１０１０）。

装置情報取得モジュール３２２００は、管理対象装置に対して、装置の状態情報および性能情報を送信するよう指示する（ステップ６１０２０）。

装置からの応答があれば（ステップ６１０３０：ＹＥＳ）、装置情報取得モジュール３２２００は、装置から受信した情報を構成ＤＢ３３５００に格納する（ステップ６１０４０）。なお、装置から指示に対する応答がなかった場合（ステップ６１０３０：ＮＯ）、構成情報取得処理を終了する。

装置情報取得モジュール３２２００は、イベント重要度管理表３３７００を参照して、検知した状態異常および性能異常の重要度を決定する（ステップ６１０５０）。装置情報取得モジュール３２２００は、検知した状態異常および性能異常をイベント化し、イベント管理表３３１００を更新する（ステップ６１０６０）。

以上が、装置情報取得モジュール３２２００が実施する、構成管理情報を取得する処理である。

なお、状態情報に基づいたイベント化とは、例えば、コンポーネントの状態が正常以外の状態に変化したときに、変化先の状態に対応したイベント（情報）を生成すること、である。性能情報に基づいたイベント化とは、例えば、所定の評価基準（閾値等）に照らして正常ではないと判定される性能値となった場合に、イベント（情報）を生成すること、である。

図２０に、管理サーバ３００００のイベント解析処理モジュール３２４００が実施する、イベント確認処理のフローチャートを示す。管理サーバ３００００の装置情報取得モジュール３２２００は、図１９に示す装置情報取得処理を管理対象装置に対して実施した後、イベント解析処理モジュール３２４００に対して、イベント確認処理を行なうよう指示する。

装置情報取得モジュール３２２００は、全ての管理対象装置に対する装置情報の取得処理が完了した後でイベント確認処理の実行を指示してもよいし、一つの管理対象装置に対する装置情報の取得処理が完了次第、イベント確認処理の実行を指示してもよい。

イベント解析処理モジュール３２４００は、イベント管理表３３１００を参照し、イベント管理表３３１００に定義されたイベントに対し、イベントが全て”処理済”になるまで、ループ内の処理を繰り返す（ステップ６２０１０）。

イベント解析処理モジュール３２４００は、未処理イベント、即ちイベント管理表３３１００に定義されたイベントの処理済みフラグが”Ｎｏ”であるイベントのうち、最も重要度の高いイベントを選択する（ステップ６２０２０）。

最も重要度の高いイベントが複数存在する場合（ステップ６２０３０：ＹＥＳ）、イベント解析処理モジュール３２４００は、ステップ６２０４０の処理を行う。１つしか存在しない場合（ステップ６２０３０：ＮＯ）、イベント解析処理モジュール３２４００は、ステップ６２０５０の処理を行う。

イベント解析処理モジュール３２４００は、ステップ６２０２０にて選択した最も優先度の高い複数イベントの中から、最も発生時刻の古いイベントを一つ選択する（ステップ６２０４０）。

イベント解析処理モジュール３２４００は、選択したイベントの処理済みフラグを”Ｙｅｓ”に変更する（ステップ６２０５０）。

イベント解析処理モジュール３２４００は、イベント伝播モデル展開モジュール３２５００に対し、当該イベントを指定して、図２１に示すイベント伝播モデルオンデマンド展開処理を実行するよう指示する。

イベント解析処理モジュール３２４００は、ルールメモリ３３３００にイベント発生時刻を書き込み、関連する結論イベントの確信度を再計算する（ステップ６２０７０）。

以上が、イベント解析処理モジュール３２４００が実施する、イベントを確認する処理である。

イベント管理表３３１００に複数のイベントが存在する場合、同時に複数のイベントについてイベント伝播モデルオンデマンド展開処理を実行するようイベント伝播モデル展開モジュールに指示してもよい。

図２１に、管理サーバ３００００のイベント伝播モデル展開モジュール３２５００が実施するイベント伝播モデルオンデマンド展開処理のフローチャートを示す。

イベント伝播モデル展開モジュール３２５００は、展開対象イベント伝播モデル管理表３３６００を参照し、処理起動時に指定されたイベント（つまり、未処理イベントの一つ）に対応したイベント伝播モデルの一覧を取得する（ステップ６３０１０）。

イベント伝播モデル展開モジュール３２５００は、前記取得したイベント伝播モデルに対し、ステップ６３０３０乃至６３０９０の処理を繰り返す（ステップ６３０２０）。展開対象イベント伝播モデル管理表３３６００にイベントが登録されていない場合は、以下の処理を行わずに、イベント伝播モデルオンデマンド展開処理を終了する。

イベント伝播モデル展開モジュール３２５００は、トポロジ生成方式リポジトリ３３４００を参照し、イベント伝播モデルに対応したトポロジ生成方式をトポロジ生成方式リポジトリ３３４００より取得する（ステップ６３０３０）。該当するトポロジ生成方式がトポロジ生成方式リポジトリにない場合（ステップ６３０４０：ＮＯ）、以下の処理を行わない。

該当するトポロジ生成方式がトポロジ生成方式リポジトリにあれば（ステップ６３０４０：ＹＥＳ）、イベント伝播モデル展開モジュール３２５００は、取得したトポロジ生成方式を元に構成ＤＢ３３５００からトポロジを取得する（ステップ６３０５０）。つまり、イベント伝播モデル展開モジュール３２５００は、イベントの発生したコンポーネントを含む組み合わせ（トポロジ）を取得する。

イベント伝播モデル展開モジュール３２５００は、取得したトポロジに基づいてイベント伝播モデルを展開し（ステップ６３０６０）、その展開結果がルールメモリ３３３００に登録済みであるか確認する（ステップ６３０７０）。展開結果がルールメモリ３３３００に登録済みの場合（ステップ６３０７０：ＹＥＳ）、以下の処理は行わない。

展開結果がルールメモリ３３３００に存在しない場合（ステップ６３０７０：ＮＯ）、イベント伝播モデル展開モジュール３２５００は、その展開結果をルールメモリ３３３００の列として追加する（ステップ６３０８０）。

イベント伝播モデル展開モジュール３２５００は、展開結果の結論イベントと、処理起動時に指定されたイベント以外の条件イベントとについて、イベント伝播モデルオンデマンド展開処理を繰り返し実施する（ステップ６３０９０）。

以上が、イベント伝播モデル展開モジュール３２５００が実施する、イベント伝播モデルをオンデマンドで展開する処理である。構成ＤＢ ３３５００以外の他の情報にトポロジを別途格納している場合は、前記他の情報を参照して上記処理を行っても良い。

以下に、図２乃至図１８に示す情報内容に対応する計算機システムを例として、どのようにルールメモリを構築し、どのように確信度を算出するかを説明する。

プログラム制御モジュール３２１００は、管理者からの指示もしくはタイマーによるスケジュール設定に応じて、装置情報取得モジュール３２２００に対し、装置情報取得処理を実行するよう指示する。装置情報取得モジュール３２２００は、管理対象装置に順番にログインし、ログインした装置に対して装置の構成情報と状態情報と性能情報とを送信するよう指示する。

上記の処理が終了した後、装置情報取得モジュール３２２００は、取得した状態情報および性能情報を参照し、イベント管理表３３１００を更新する。ここでは、図１３Ａのイベント管理表３３１００の１行目から４行目に示す通り、”ＥＶ１”から”ＥＶ４”までのイベントを検知したケースを想定する。

イベント解析処理モジュール３２４００は、イベント管理表３３１００内の未処理イベント、即ちイベント管理表３３１００に定義されたイベントの処理済みフラグが”Ｎｏ”であるイベントのうち、最も重要度の高いイベントを選択する。ここでは”ＥＶ４”で示されるイベントの重要度が”５”と最も高いため、”ＥＶ４”を選択する。

イベント解析処理モジュール３２４００は、イベント伝播モデル展開モジュール３２５００に対し、当該イベント”ＥＶ４”を指定して、イベント伝播モデルオンデマンド展開処理を実行するよう指示する。

イベント伝播モデル展開モジュール３２５００は、展開対象イベント伝播モデル管理表３３６００を参照して、イベント”ＥＶ４”に対応したイベント伝播モデルの一覧を取得する。例えば、図１７に示す展開対象イベント伝播モデル管理表３３６００を参照すると、”ホストコンピュータにおける論理ボリュームの状態異常”というイベントが発生した場合、”Ｒｕｌｅ１”を展開する必要があることが分かる。

図１４Ａに示すイベント伝播モデル”Ｒｕｌｅ１”は、観測イベントとして”ホストコンピュータの論理ボリュームの状態異常”と、”ストレージ装置のボリュームの状態異常”とが定義されている。図１６Ａに示すトポロジ生成方式を参照すると、ストレージ装置のボリュームを起点とし、ホストコンピュータの論理ボリュームを終点とするトポロジ生成方式”ＴＰ１”が定義されている。そこで、このトポロジ生成方式を利用して、トポロジを取得する。

展開モジュール３２５００は、図９に示すボリューム管理表２３２００（正確にはボリューム管理表２３２００に相当する、管理サーバ３００００が格納した構成ＤＢ ３５００内の項目）を参照し、ストレージ装置”ＳＹＳ１”のボリューム”ＶＯＬ１”に着目すると、そのターゲットＩＤは”ＴＧ１”となっている。

次に、展開モジュール３２５００は、図８に示すｉＳＣＳＩターゲット管理表１３３００（正確にはｉＳＣＳＩターゲット管理表１３３００に相当する、管理サーバ３００００が格納した構成ＤＢ ３３５００内の項目）を参照し、ｉＳＣＳＩターゲットＩＤが”ＴＧ１”となっているものを探す。ｉＳＣＳＩターゲットＩＤが”ＴＧ１”であるエントリの接続許可ｉＳＣＳＩイニシエータ名を見ると”ｃｏｍ．ｈｉｔａｃｈｉ．ｓｖ１”となっている。

展開モジュール３２５００は、図８Ａに示すｉＳＣＳＩターゲット管理表１３３００（ｉＳＣＳＩターゲット管理表１３３００に相当する、管理サーバ３００００が格納した構成ＤＢ ３３５００内の項目）を参照し、ｉＳＣＳＩイニシエータ名が”ｃｏｍ．ｈｉｔａｃｈｉ．ｓｖ１”となっている論理ボリュームを検索する。

展開モジュール３２５００は、検索されたホストコンピュータ”ＨＯＳＴ１”の論理ボリューム（Ｅ：）が、ＬＵＮ ＩＤがストレージ装置”ＳＹＳ１”のボリューム”ＶＯＬ１”のＬＵＮ ＩＤと等しいかどうかを確認する。

以上の結果、ホストコンピュータの論理ボリュームとストレージ装置のボリュームを含むトポロジの一つとして、ホストコンピュータ”ＨＯＳＴ１”の論理ボリューム（Ｅ：）と、ストレージ装置”ＳＹＳ１”のボリューム”ＶＯＬ１”の組み合わせが有る。

そこで、観測イベントとして”ホストコンピュータＨＯＳＴ１の論理ボリューム（Ｅ：）の状態異常”と、”ストレージ装置ＳＹＳ１のボリュームＶＯＬ１の状態異常”を検知した際、根本原因として”ストレージ装置ＳＹＳ１のボリュームＶＯＬ１の故障”を結論付けるパターンが展開結果（つまり展開すべき因果律）となる。この展開結果がルールメモリに存在しない場合、展開結果をルールメモリに追加する。

以上の処理により、イベント伝播モデルＲｕｌｅ１に関する因果律がルールメモリに追加され、図１５Ａの状態となる。

次にイベント解析処理モジュールは、ルールメモリにイベント発生時刻を書き込み、関連する結論イベントの確信度を再計算する。すなわち、ルールメモリにおいて”ホストコンピュータＨＯＳＴ１の論理ボリューム（Ｅ：）の状態異常”という観測イベントを発見し、ＥＶ４の発生時刻である”2010-01-01 15:00:30”を書き込む。次に、この観測イベントと関連する因果律を見つける。図１５Ａにおいては、ＥｘＲｕｌｅ１というＩＤで示される因果律が見つかる。この因果律に関連する観測イベントとして”ホストコンピュータＨＯＳＴ１の論理ボリューム（Ｅ：）の状態異常”と、”ストレージ装置ＳＹＳ１のボリュームＶＯＬ１の状態異常”の２つがあり、前者のみイベントを検知済みであることから、因果律ＥｘＲｕｌｅ１の確信度は５０％となる。この確信度を、根本原因である”ストレージ装置ＳＹＳ１のボリュームＶＯＬ１の故障”の確信度として書き込む。

以上の処理により、イベントＥＶ４の発生時刻がルールメモリに追加され、図１５Ｂの状態となる。

次にイベント解析処理モジュール３２４００は、イベント管理表３３１００内の未処理イベントに対する処理を順次実行し、イベントＥＶ２に対する処理に着手する。イベント解析処理モジュール３２４００は、イベント伝播モデル展開モジュール３２５００に対し、当該イベントを指定してイベント伝播モデルオンデマンド展開処理を実行するよう指示する。

イベント伝播モデル展開モジュール３２５００は、展開対象イベント伝播モデル管理表３３６００を参照して、イベントに対応したイベント伝播モデルの一覧を取得する。例えば、図１７に示す展開対象イベント伝播モデル管理表３３６００を参照すると、”ストレージ装置におけるボリュームの状態異常”というイベントが発生した場合、”Ｒｕｌｅ１”を展開する必要があることが分かる。

図１４Ａに示すイベント伝播モデルＲｕｌｅ１は、観測イベントとして”ホストコンピュータの論理ボリュームの状態異常”と、”ストレージ装置のボリュームの状態異常”が定義されている。図１６Ａに示すトポロジ生成方式を参照すると、ストレージ装置のＩ／Ｏポートを起点とし、ホストコンピュータの論理ボリュームを終点とするトポロジ生成方式ＴＰ１が定義されている。そこで、このトポロジ生成方式ＴＰ１を利用してトポロジを取得する。

その結果、ホストコンピュータの論理ボリュームとストレージ装置のボリュームを含むトポロジの一つとして、ホストコンピュータＨＯＳＴ１の論理ボリューム（Ｅ：）と、ストレージ装置ＳＹＳ１のボリュームＶＯＬ１との組み合わせが存在する。

そこで、観測イベントとして”ホストコンピュータＨＯＳＴ１の論理ボリューム（Ｅ：）の状態異常”と、”ストレージ装置ＳＹＳ１のボリュームＶＯＬ１の状態異常”とを検知した際、その根本原因を”ストレージ装置ＳＹＳ１のボリュームＶＯＬ１の故障”であると結論付けるパターンが展開結果（つまり展開すべき因果律）となる。この展開結果はルールメモリ３３３００に既に存在するため、その展開結果をルールメモリ３３３００に追加せずにイベント伝播モデルオンデマンド展開処理を終了する。

イベント解析処理モジュール３２４００は、ルールメモリ３３３００にイベント発生時刻を書き込み、関連する結論イベントの確信度を再計算する。すなわち、ルールメモリ３３３００において”ストレージ装置ＳＹＳ１のボリュームＶＯＬ１の状態異常”という観測イベントを発見し、そこにイベントＥＶ２の発生時刻である”2010-01-01 15:00:10”を書き込む。

次に、イベント解析処理モジュール３２４００は、この観測イベントと関連する因果律を見つける。図１５Ｂにおいては、”ＥｘＲｕｌｅ１”というＩＤで示される因果律が見つかる。この因果律に関連する観測イベントとして”ホストコンピュータＨＯＳＴ１の論理ボリューム（Ｅ：）の状態異常”と、”ストレージ装置ＳＹＳ１のボリュームＶＯＬ１の状態異常”との２つが有る。それら２つイベントを検知済みであるから、因果律ＥｘＲｕｌｅ１の確信度は１００％となる。イベント解析処理モジュール３２４００は、この確信度（１００％）を、根本原因である”ストレージ装置ＳＹＳ１のボリュームＶＯＬ１の故障”の確信度として書き込む。

以上の処理により、イベントＥＶ２の発生時刻がルールメモリに追加され、図１５Ｃの状態となる。

このように構成される本実施例の効果を説明する。図２５は、計算機システムの物理構成例を示す図である。当該計算機システムは、ストレージ装置２００００と、ホストコンピュータ１００００と、管理サーバ３００００と、ＷＥＢブラウザ起動サーバ３５０００と、ＩＰスイッチ４００００と、を有し、それらが、ネットワーク４５０００によって接続される構成となっている。

以下の説明では、ホストコンピュータ１００００乃至１００１０は１００台のホストコンピュータからなっており、その装置ＩＤはＨＯＳＴ１乃至ＨＯＳＴ１００であるものとする。ＨＯＳＴ１乃至ＨＯＳＴ１００は、それぞれストレージ装置２００００に接続されているとする。ストレージ装置２００００の装置ＩＤはＳＹＳ１とする。また、ＨＯＳＴ１乃至ＨＯＳＴ１００は、ストレージ装置ＳＹＳ１内のＲＡＩＤグループＲＧ１上にあるボリュームにアクセスしているものとする。

一方、ホストコンピュータ１００２０の装置ＩＤはＨＯＳＴ１０１であるとする。ＨＯＳＴ１０１はストレージ装置２００１０に接続されているものとする。ストレージ装置２００１０の装置ＩＤはＳＹＳ２とする。ＨＯＳＴ１０１は、ストレージ装置ＳＹＳ２内のＲＡＩＤグループＲＧ１上にあるボリュームにアクセスしているものとする。ＨＯＳＴ１０１は、計算機システム内の他の装置に比べて業務上の重要度が高く、従ってＨＯＳＴ１０１で発生したイベントのイベント重要度は他の機器で発生するイベントに比べて高いものとする。

以下、図２５に示す計算機システムにおいて、ストレージ装置ＳＹＳ１内のＲＡＩＤグループＲＧ１の障害の直後に、ストレージ装置ＳＹＳ２内のＲＡＩＤグループＲＧ１の障害が発生し、さらにＨＯＳＴ１乃至ＨＯＳＴ１００での論理ボリューム障害に引き続き、ＨＯＳＴ１０１での論理ボリューム障害が発生した場合について述べる。

図２６は、一連の障害が発生した直後のイベント管理表３３１００を示す。ストレージ装置ＳＹＳ１内のＲＡＩＤグループＲＧ１の障害によってイベントＥＶ１が、ＨＯＳＴ１乃至ＨＯＳＴ１００での論理ボリューム障害によりイベントＥＶ２乃至ＥＶ１０１が、ストレージ装置ＳＹＳ２内のＲＡＩＤグループＲＧ１の障害によりイベントＥＶ１０２が、ＨＯＳＴ１０１での論理ボリューム障害によりイベントＥＶ１０３が、それぞれ引き起こされている。

ＨＯＳＴ１０１は、計算機システム内の他の装置に比べて業務上の重要度が高いため、イベントＥＶ１０３のイベント重要度は”５”になっており、その他のイベントのイベント重要度は”１”になっている。

本実施例で述べた構成を採用しない場合を先に説明する。この場合、イベント重要度の高いイベントであっても、イベント管理表３３１００に先に格納されたイベント重要度の低いイベントの方が先に処理される。イベント重要度の高いイベントについての解析は、後回しにされる。

つまり、イベント重要度の高いイベントＥＶ１０３に対応する、イベント伝播モデルオンデマンド展開処理および確信度計算処理は、イベント重要度の低いイベントＥＶ１乃至ＥＶ１０２に対応するイベント伝播モデルオンデマンド展開処理および確信度計算処理の後で、実施される。

１イベント当たりのイベント伝播モデルオンデマンド展開処理および確信度計算処理に要する時間が一定時間Ｔであると仮定すると、イベントＥＶ１０３に対応する解析結果が出力されるまでには「Ｔ×１０３」の時間を要する。従って、イベント重要度の高いイベントであるにもかかわらず、そのイベントの解析結果が管理者に通知されるまでに長い時間を要する。

これに対し、本実施例では、イベント重要度の高いイベントから先に解析するため、例えば業務上の影響の大きいイベントを直ちに解析してその結果を管理者に通知することができる。

すなわち、本実施例では、イベント重要度の高いイベントＥＶ１０３に対応するイベント伝播モデルオンデマンド展開処理および確信度計算処理を、全てのイベントのうち最初に実施する。従って、本実施例では、イベントＥＶ１０３に対応する解析結果が出力されるまでの所要時間を「Ｔ×１」と大幅に短縮することができる。

本実施例では、イベント発生前に全ての因果律を事前に作成するのではなく、イベント発生時に必要な範囲内で因果律を作成するため、ルールメモリ３３３００のサイズを小さくすることができる。しかし、管理対象装置の数などによっても相違するが、比較的大規模な計算機システムでは、イベント伝播モデルをオンデマンドで展開する処理に、予想以上の時間を必要とする。この新たな知見に基づいて、本実施例では、イベント管理表３３１００に格納された順番でイベントを処理するのではなく、イベント重要度の高いイベントから先に処理する。これにより、本実施例では、早急に警告すべきイベントから先に解析して、その解析結果を管理者に通知することができる。従って、信頼性および使い勝手を向上できる。

実施例２を説明する。本実施例を含む以下の各実施例は実施例１の変形例に該当するため、実施例１との相違を中心に説明する。

実施例２では、管理プログラム３２０００のイベント伝播モデル展開モジュール３２５００が実施する、別なイベント伝播モデルオンデマンド展開処理について説明する。

実施例１においては、複数のイベントについてイベント伝播モデルオンデマンド展開処理を実行する場合、イベントの重要度の高い順に展開するようイベント伝播モデル展開モジュール３２５００に指示する。

ところで、情報処理システム（計算機システム）においては、１つの障害が多数の装置に波及するため、同時に多数の異常イベントが管理プログラム３２０００によって検知される。それらのイベントが全て同じ重要度であるとは限らない。しかし、同じ根本原因を持つ異常イベントについて、イベント重要度の順にイベント伝播モデルオンデマンド展開処理を並列に処理したとすると、重要度の低いイベントの処理開始が遅れるため、確信度に反映されるまでの時間が長くなる。

例えば、３つのイベントのうち１つのイベントのイベント重要度が低い場合、そのイベント重要度の低いイベントについてイベント伝播モデルの展開処理が完了するまでの間、根本原因の確信度は、２／３に止まる。イベント重要度の低いイベントについての展開処理が完了すると、確信度は３／３に上昇する。

上記の課題を解決するため、実施例２では、管理サーバ３００００におけるイベント解析処理を変更する。変更後の管理サーバ３００００が実行する処理を、図２２Ａ及び２２Ｂに示す。なお、管理サーバ３００００が実行するその他の処理は、実施例１と変わらないため、説明を省略する。

図２２Ａ及び２２Ｂに、実施例２における、管理サーバ３００００のイベント解析処理モジュール３２４００が実施する、イベント確認処理のフローチャートを示す。なお、管理サーバ３００００の装置情報取得モジュール３２２００は、図１９に示す装置情報取得処理を管理対象装置に対して実施した後、イベント解析処理モジュール３２４００に対し、イベント確認処理を行なうよう指示する。

イベント解析処理モジュール３２４００は、イベント管理表３３１００を参照し、イベント管理表３３１００に定義されたイベントに対し、イベントが全て「処理済」になるまで、ループ内の処理を繰り返す（ステップ６４０１０）。

イベント解析処理モジュール３２４００は、未処理イベント、即ちイベント管理表３３１００に定義されたイベントの処理済みフラグが”Ｎｏ”であるイベントのうち、最も重要度の高いイベントを選択する（ステップ６４０２０）。前記処理によって選択されたイベントが複数存在する場合（ステップ６４０３０：ＹＥＳ）、イベント解析処理モジュール３２４００は、ステップ６４０４０の処理を行う。１つしか存在しない場合（ステップ６４０３０：ＮＯ）、ステップ６４０５０の処理を行う。

イベント解析処理モジュール３２４００は、ステップ６２０２０にて選択したイベントのうち、最も発生時刻の古いイベントを１つ選択する（ステップ６４０４０）。

イベント解析処理モジュール３２４００は、選択したイベントの処理済みフラグを”Ｙｅｓ”に変更する（ステップ６４０５０）。

イベント解析処理モジュール３２４００は、イベント伝播モデル展開モジュール３２５００に対し、当該イベントを指定して図２１に示すイベント伝播モデルオンデマンド展開処理を実行するよう指示する（ステップ６４０６０）。

イベント解析処理モジュール３２４００は、ルールメモリ３３３００にイベント発生時刻を書き込み、関連する結論イベントを全て取得する（ステップ６４０７０）。

図２２Ｂに移る。イベント解析処理モジュール３２４００は、関連する結論イベント毎に、ループ内の処理を繰り返す（ステップ６４０８０）。

イベント解析処理モジュール３２４００は、結論イベントと関連する観測イベントのうち、未受信のイベントを取得する（ステップ６４０９０）。イベント解析処理モジュール３２４００は、取得した未受信の観測イベント毎に、ループ内の処理を繰り返す（ステップ６４１００）。

イベント解析処理モジュール３２４００は、イベント管理表３３１００を参照し、管理オブジェクトの種別とイベントの種別が同一で、かつ未処理のイベントが無いかどうかを確認する（ステップ６４１１０）。該当するイベントが存在する場合（ステップ６４１２０：ＹＥＳ）、イベント解析処理モジュール３２４００は、ルールメモリ３３３００上の当該観測イベントにイベント発生時刻を書き込む（ステップ６４１３０）。

以上の処理を、ステップ６４０９０で取得した未受信の観測イベントに対して実施した後、イベント解析処理モジュール３２４００は、前記結論イベントの確信度を再計算する（ステップ６４１４０）。

以上が、実施例２のイベント解析処理モジュール３２４００が実施するイベント確認処理である。

イベント管理表３３１００に複数のイベントが存在する場合、同時に複数のイベントについてイベント伝播モデルオンデマンド展開処理を実行するよう、イベント伝播モデル展開モジュール３２５００に指示してもよい。

以下に、図６乃至図１８の情報の内容に対応する計算機システムを例として、実施例２の処理がどのようにルールメモリ３３３００を構築して確信度を算出するかを示す。

プログラム制御モジュール３２１００は、管理者からの指示もしくはタイマーによるスケジュール設定によって、装置情報取得モジュール３２２００に対し、装置情報取得処理を実行するよう指示する。装置情報取得モジュール３２２００は、管理対象装置に順番にログインし、ログインした装置に対して、装置の構成情報と状態情報および性能情報を送信するよう指示する。

上記の処理が終了した後、装置情報取得モジュール３２２００は、取得した状態情報および性能情報を参照し、イベント管理表３３１００を更新する。ここでは、図１３Ａのイベント管理表３３１００の１行目から４行目に示す通り、イベントＥＶ１からイベントＥＶ４までのイベントを検知したケースを想定する。

イベント解析処理モジュール３２４００は、イベント管理表３３１００内の未処理イベント、即ちイベント管理表３３１００に定義されたイベントの処理済みフラグが”Ｎｏ”であるイベントのうち、最も重要度の高いイベントを選択する。ここでは”ＥＶ４”で示されるイベントの重要度が”５”と最も高いため、イベント解析処理モジュール３２４００は、イベントＥＶ４を選択する。

イベント解析処理モジュール３２４００は、イベント伝播モデル展開モジュール３２５００に対し、当該イベントを指定してイベント伝播モデルオンデマンド展開処理を実行するよう指示する。

イベント伝播モデル展開モジュール３２５００は、展開対象イベント伝播モデル管理表３３６００を参照して、イベントに対応したイベント伝播モデルの一覧を取得する。例えば、図１７に示す展開対象イベント伝播モデル管理表３３６００を参照すると、”ホストコンピュータにおける論理ボリュームの状態異常”というイベントが発生した場合、イベント伝播モデル”Ｒｕｌｅ１”を展開する必要があることが分かる。

図１４Ａに示すイベント伝播モデルＲｕｌｅ１は、観測イベントとして”ホストコンピュータの論理ボリュームの状態異常”と、”ストレージ装置のボリュームの状態異常”とが定義されている。図１６Ａに示すトポロジ生成方式を参照すると、ストレージ装置のボリュームを起点とし、ホストコンピュータの論理ボリュームを終点とするトポロジ生成方式ＴＰ１が定義されている。そこで、このトポロジ生成方式ＴＰ１を利用して、トポロジを取得する。

その結果、ホストコンピュータの論理ボリュームとストレージ装置のボリュームを含むトポロジの一つとして、ホストコンピュータＨＯＳＴ１の論理ボリューム（Ｅ：）と、ストレージ装置ＳＹＳ１のボリュームＶＯＬ１の組み合わせが存在する。

そこで、観測イベントとして”ホストコンピュータＨＯＳＴ１の論理ボリューム（Ｅ：）の状態異常”と、”ストレージ装置ＳＹＳ１のボリュームＶＯＬ１の状態異常”とを検知した際、その根本原因を”ストレージ装置ＳＹＳ１のボリュームＶＯＬ１の故障”であると結論付けるパターンが、展開結果（つまり展開すべき因果律）となる。この展開結果がルールメモリ３３３００に存在しない場合、その展開結果はルールメモリ３３３００に追加される。

以上の処理により、イベント伝播モデルＲｕｌｅ１に関する因果律がルールメモリ３３３００に追加され、図１５Ａの状態となる。

イベント解析処理モジュール３２４００は、ルールメモリ３３３００にイベント発生時刻を書き込む。すなわち、イベント解析処理モジュール３２４００は、ルールメモリ３３３００において”ホストコンピュータＨＯＳＴ１の論理ボリューム（Ｅ：）の状態異常”という観測イベントを発見し、イベントＥＶ４の発生時刻である”2010-01-01 15:00:30”を書き込む。その結果、ルールメモリ３３３００は、図１５Ｂの状態となる。

イベント解析処理モジュール３２４００は、展開した因果律ＥｘＲｕｌｅ１の観測イベント毎に、ループ内の処理を繰り返す。

イベント解析処理モジュール３２４００は、まず観測イベントが未受信であるかどうかを確認する。観測イベントが未受信である場合、イベント管理表３３１００を参照し、管理オブジェクト種別とイベント種別が同一であり、かつ未処理のイベントが無いかどうかを確認する。

該当するイベントが存在する場合、イベント解析処理モジュール３２４００は、ルールメモリ３３３００にイベント発生時刻を書き込む。

因果律ＥｘＲｕｌｅ１の”ストレージ装置ＳＹＳ１のボリュームＶＯＬ１の状態異常”という観測イベントは未受信であるが、イベント管理表３３１００を参照すると”ストレージ装置ＳＹＳ１のボリュームＶＯＬ１の状態異常”というイベントＥＶ２が存在している。従って、イベント解析処理モジュール３２４００は、ＥＶ２の発生時刻である”2010-01-01 15:00:10”をルールメモリ３３３００の当該観測イベントに書き込む。

イベント解析処理モジュール３２４００は、前記因果律の確信度を再計算する。すなわち、因果律ＥｘＲｕｌｅ１に関連する観測イベントとして”ホストコンピュータＨＯＳＴ１の論理ボリューム（Ｅ：）の状態異常”と、”ストレージ装置ＳＹＳ１のボリュームＶＯＬ１の状態異常”との２つがあり、それら２つのイベントを検知済みであることから、因果律ＥｘＲｕｌｅ１の確信度は１００％となる。イベント解析処理モジュール３２４００は、この確信度（１００％）を、根本原因である”ストレージ装置ＳＹＳ１のボリュームＶＯＬ１の故障”の確信度として書き込む。

以上の処理により、イベントＥＶ２の発生時刻がルールメモリに追加され、図１５Ｃの状態となる。

以上が、実施例２のイベント解析処理モジュール３２４００が実施するイベント解析処理である。

このように構成される実施例２も実施例１と同様の効果を奏する。さらに、実施例２では、管理プログラム３２０００は、イベント伝播モデルを展開した際に、展開した因果律情報に含まれる観測イベントのうち、未受信のものをイベントリストから検索して処理し、確信度に反映する。

その結果、実施例２では、大規模システムを対象としてオンデマンド展開方式を採用する場合において、同じ障害原因を持つ多数の障害を同時に受信したとしても、展開が完了した因果律に対する確信度を迅速かつ適切に評価することができる。

実施例３では、管理プログラム３２０００のイベント伝播モデル展開モジュール３２５００が実施する、イベント伝播モデル展開処理について説明する。

実施例１では、イベント重要度に応じて、どのイベントから順にイベント伝播モデルオンデマンド展開処理を実行するかを判断していた。しかし、イベント重要度が同じイベントが複数ある場合、展開に時間の掛からないイベントから順に展開処理を実行する方が望ましい。

先述したとおり、イベントには有効期間が設定されており、発生から一定時間が経過したイベントは、解析対象から除外される。従って、イベント発生直後ほど、より多くのイベントの展開処理を行えば、イベントの解析に必要なイベント伝播モデルの展開が完了する前に、そのイベントが解析対象から外れてしまうという事態の発生を抑止できる。しかし、実施例１では、各イベントについての、イベント伝播モデルの展開所要時間を見積もることができない。

このような課題を解決するため、実施例３では、管理サーバ３００００におけるイベント解析処理を変更する。実施例３の管理サーバ３００００が具備する関連機器数管理表３３８００を図２３に、管理サーバ３００００が実行する処理フローを図２４に、それぞれ示す。なお、管理サーバ３００００のその他の情報及びフローは、実施例１または実施例２と同じである。

図２３は、管理サーバ３００００の具備する関連装置数管理表３３８００の構成例を示す図である。

関連装置数管理表３３８００は、管理サーバ３００００が管理する装置の種別を登録するフィールド３３８１０と、前記装置の識別子となる装置ＩＤを登録するフィールド３３８２０と、前記装置と接続関係にある装置の種別を登録するフィールド３３８３０と、前記装置と接続関係にある装置の数を登録するフィールド３３８４０と、を構成項目として含んでいる。

図２３には、関連装置数管理表３３８００の具体的な値の一例を示している。つまり、装置ＩＤが”ＨＯＳＴ１”で示されるホストコンピュータは、１つのストレージ装置と接続関係にあることを示している。

本実施例において管理サーバ３００００が実行するイベント伝播モデルオンデマンド展開処理の処理方式を図２４に示す。なお、管理サーバ３００００が実行するその他の処理は、実施例１と変わらない。

図２４に、イベント解析処理モジュール３２４００が実施するイベント解析処理のフローチャートを示す。装置情報取得モジュール３２２００は、図２５に示す装置情報取得処理を管理対象装置に対して実施した後、イベント解析処理モジュール３２４００に対し、イベント確認処理を行なうよう指示する。装置情報取得モジュール３２２００がイベント確認処理を行なうよう指示するタイミングは、全ての管理対象装置に対する処理が完了した後でも構わないし、一つの管理対象装置に対する処理が完了次第に随時指示しても構わない。

イベント解析処理モジュール３２４００は、イベント管理表３３１００を参照し、イベント管理表３３１００に定義されたイベントに対し、イベントが全て「処理済」になるまで、ループ内の処理を繰り返す（ステップ６５０１０）。

イベント解析処理モジュール３２４００は、未処理イベント、即ちイベント管理表３３１００に定義されたイベントの処理済みフラグが”Ｎｏ”であるイベントのうち、最も重要度の高いイベントを選択する（ステップ６５０２０）。前記処理によって選択されたイベントが複数存在する場合（ステップ６５０３０：ＹＥＳ）、ステップ６５０４０の処理を行う。１つしか存在しない場合（ステップ６５０３０：ＮＯ）、ステップ６５０７０の処理を行う。

イベント解析処理モジュール３２４００は、展開対象イベント伝播モデル管理表３３６００を参照し、前記イベントに対応したイベント伝播モデルの一覧を取得する（ステップ６５０４０）。イベント解析処理モジュール３２４００は、関連装置数管理表３３８００を参照し、該当するイベント伝播モデルの展開時に構成ＤＢ ３３５００から情報を取得する必要のある関連装置の数を算出する（ステップ６５０５０）。ステップ６５０４０において、イベント伝播モデルが複数取得された場合は、各々のイベント伝播モデルについて関連装置の数を算出し、合算する。取得の結果、イベント解析処理モジュール３２４００は、最も関連装置数の少ないイベントを１つ選択する（ステップ６５０６０）。

イベント解析処理モジュール３２４００は、選択したイベントの処理済みフラグを”Ｙｅｓ”に変更する（ステップ６５０７０）。

イベント解析処理モジュール３２４００は、イベント伝播モデル展開モジュール３２５００に対し、当該イベントを指定して図２１に示すイベント伝播モデルオンデマンド展開処理を実行するよう指示する（ステップ６５０８０）。

最後に、イベント解析処理モジュール３２４００は、ルールメモリ３３３００にイベント発生時刻を書き込み、さらに、関連する結論イベントの確信度を再計算する（ステップ６５０９０）。

以上がイベント解析処理モジュール３２４００によるイベント解析処理である。なお、イベント管理表３３１００に複数のイベントが存在する場合、同時に複数のイベントについてイベント伝播モデルオンデマンド展開処理を実行するようイベント伝播モデル展開モジュール３２５００に指示してもよい。

以下に、図２乃至図１８に示す情報内容に対応する計算機システムを例として、実施例３の処理がどのようにルールメモリを構築して確信度を算出するかを示す。

プログラム制御モジュール３２１００は、管理者からの指示もしくはタイマーによるスケジュール設定によって、装置情報取得モジュール３２２００に対し、装置情報取得処理を実行するよう指示する。装置情報取得モジュール３２２００は、管理対象装置に順にログインし、ログインした装置に対して、装置の構成情報と状態情報と性能情報とを送信するよう指示する。

上記の処理が終了した後、装置情報取得モジュール３２２００は、取得した状態情報および性能情報を参照し、イベント管理表３３１００を更新する。ここでは、図１３Ｂのイベント管理表３３１００の１行目から２行目に示す通り、イベントＥＶ１からイベントＥＶ２までのイベントを検知したケースを想定する。

イベント解析処理モジュール３２４００は、イベント管理表３３１００内の未処理イベント、即ちイベント管理表３３１００に定義されたイベントの処理済みフラグが”Ｎｏ”であるイベントのうち、最も重要度の高いイベントを選択する。ここでは”ＥＶ１”と”ＥＶ２”とで示される２つのイベントの重要度が”５”である。

そこで、イベント解析処理モジュール３２４００は、展開対象イベント伝播モデル管理表を参照し、前記イベントに対応したイベント伝播モデルの一覧を取得する。例えば、図１７に示す展開対象イベント伝播モデル管理表３３６００を参照すると、”ホストコンピュータにおける論理ボリュームの状態異常”というイベントが発生した場合、イベント伝播モデルＲｕｌｅ２を展開する必要があることが分かる。

イベント解析処理モジュール３２４００は、関連装置数管理表３３８００を参照し、イベント伝播モデルＲｕｌｅ２の展開時に構成ＤＢ ３３５００から情報を取得する必要のある関連装置の数を算出する。

イベント伝播モデルＲｕｌｅ２は、ホストコンピュータとストレージ装置との組み合わせからなるルールであるため、双方の装置間の関連装置数を確認する。即ち、イベントＥＶ１に定義されたホストコンピュータＨＯＳＴ１は１つのストレージ装置と、イベントＥＶ２に定義されたストレージ装置ＳＹＳ１は３つのホストコンピュータと、それぞれ関連していることが分かる。取得の結果、イベント解析処理モジュール３２４００は、最も関連装置数の少ないイベントＥＶ１を選択する。

イベント伝播モデル展開モジュール３２５００は、展開対象イベント伝播モデル管理表３３６００から、イベントＥＶ１に対応したイベント伝播モデルの一覧を取得する。例えば、図１７に示す展開対象イベント伝播モデル管理表３３６００を参照すると、”ホストコンピュータにおける論理ボリュームの状態異常”というイベントが発生した場合、イベント伝播モデルＲｕｌｅ２を展開する必要があることが分かる。

図１４Ｂに示すイベント伝播モデルＲｕｌｅ２には、観測イベントとして”ホストコンピュータの論理ボリュームの状態異常”と、”ストレージ装置のＲＡＩＤグループの状態異常”とが定義されている。図１６Ｂに示すトポロジ生成方式を参照すると、ストレージ装置のＲＡＩＤグループを起点とし、ホストコンピュータの論理ボリュームを終点とするトポロジ生成方式ＴＰ２が定義されている。そこで、このトポロジ生成方式ＴＰ２を利用してトポロジを取得する。

その結果、ホストコンピュータの論理ボリュームとストレージ装置のＲＡＩＤグループを含むトポロジの一つとして、ホストコンピュータＨＯＳＴ１の論理ボリューム（Ｅ：）と、ストレージ装置ＳＹＳ１のＲＡＩＤグループＲＧ１の組み合わせが存在する。

従って、観測イベントとして”ホストコンピュータＨＯＳＴ１の論理ボリューム（Ｅ：）の状態異常”と、”ストレージ装置ＳＹＳ１のＲＡＩＤグループＲＧ１の状態異常”とを検知した場合は、その根本原因として”ストレージ装置ＳＹＳ１のＲＡＩＤグループＲＧ１の故障”であると結論付けるパターンが、展開結果（つまり、展開すべき因果律）となる。この展開結果がルールメモリ３３３００に存在しない場合、展開結果をルールメモリ３３３００に追加する。

以上の処理により、イベント伝播モデルＲｕｌｅ２に関する因果律がルールメモリ３３３００に追加され、図１５Ｄの状態となる。

イベント解析処理モジュール３２４００は、ルールメモリ３３３００にイベント発生時刻を書き込み、関連する結論イベントの確信度を再計算する。

イベント解析処理モジュール３２４００は、イベント管理表３３１００内の未処理イベントに対する処理を順次実行し、イベントＥＶ２についての処理に着手する。イベント解析処理モジュール３２４００は、イベント伝播モデル展開モジュール３２５００に対し、当該イベントを指定して、イベント伝播モデルオンデマンド展開処理を実行するよう指示する。

イベント伝播モデル展開モジュール３２５００は、展開対象イベント伝播モデル管理表３３６００を参照して、イベントに対応したイベント伝播モデルの一覧を取得する。例えば、図１７に示す展開対象イベント伝播モデル管理表３３６００を参照すると、”ストレージ装置におけるＲＡＩＤグループの状態異常”というイベントが発生した場合、イベント伝播モデルＲｕｌｅ２を展開する必要があることが分かる。

図１４Ｂに示すイベント伝播モデルＲｕｌｅ２は、観測イベントとして”ホストコンピュータの論理ボリュームの状態異常”と、”ストレージ装置のボリュームの状態異常”とが定義されている。図１６Ｂに示すトポロジ生成方式を参照すると、ストレージ装置のＲＡＩＤグループを起点とし、ホストコンピュータの論理ボリュームを終点とするトポロジ生成方式ＴＰ２が定義されている。そこで、このトポロジ生成方式ＴＰ２を利用してトポロジを取得する。

その結果、ホストコンピュータの論理ボリュームとストレージ装置のボリュームを含むトポロジの一つとして、ホストコンピュータＨＯＳＴ１の論理ボリューム（Ｅ：）と、ホストコンピュータＨＯＳＴ２の論理ボリューム（Ｅ：）と、ホストコンピュータＨＯＳＴ３の論理ボリューム（Ｅ：）と、ストレージ装置ＳＹＳ１のＲＡＩＤグループＲＧ１との組み合わせが存在する。

そこで、観測イベントとして”ホストコンピュータＨＯＳＴ１の論理ボリューム（Ｅ：）の状態異常”と、”ホストコンピュータＨＯＳＴ２の論理ボリューム（Ｅ：）の状態異常”と、”ホストコンピュータＨＯＳＴ３の論理ボリューム（Ｅ：）の状態異常”と、”ストレージ装置ＳＹＳ１のＲＡＩＤグループＲＧ１の状態異常”とを検知した際、その根本原因を”ストレージ装置ＳＹＳ１のＲＡＩＤグループＲＧ１の故障”であると結論付けるパターンが、展開結果（つまり展開すべき因果律）となる。この展開結果は、部分的にしかルールメモリ３３３００に存在しないため、その展開結果はルールメモリ３３３００に追加される。

イベント解析処理モジュール３２４００は、ルールメモリ３３３００にイベント発生時刻を書き込み、関連する結論イベントの確信度を再計算する。

以上の処理により、イベント伝播モデルＲｕｌｅ２に関する因果律がルールメモリ３３３００に追加され、図１５Ｅの状態となる。

このように構成される本実施例も実施例１と同様の効果を奏する。さらに、本実施例によれば、各イベントのイベント伝播モデルの展開に要する時間を見積もるため、所要時間の短いイベントから先に展開することができる。従って、本実施例では、イベント解析に必要なイベント伝播モデルの展開が完了する前に、イベントが解析対象から外れてしまうという事態の発生を抑止できる。これにより、信頼性および使い勝手が向上する。

なお、本実施形態に記載された構成は、以下のように、計算機システムの管理方法として表現することもできる。
「表現１．
複数の管理対象装置を含む計算機システムを管理計算機により管理するための方法であって、
前記管理計算機は、所定の情報を記憶する記憶資源を利用することができ、
前記所定の情報には、
（１）前記複数の管理対象装置又は前記複数の管理対象装置が含む複数のコンポーネントである、複数の管理オブジェクトに関して、前記複数の管理オブジェクト同士の関係を示すトポロジと、
（２）第１種別の管理オブジェクトで発生する所定種別の第１イベントが原因となって、第２種別の管理オブジェクトで他の所定種別の第２イベントが発生する、ことを示すイベント伝播モデルと、
（３）一つ以上の因果律を含む因果律情報と、
が含まれており、
前記因果律は、第１種別を有する第１管理オブジェクトで発生する前記所定種別の第１イベントが原因となって、第２種別を有する第２管理オブジェクトで前記他の所定種別の第２イベントが発生すること、を示しており、
前記管理計算機は、
（Ａ）所定の管理オブジェクトで発生した問題に関するイベントを検知し、
（Ｂ）前記検知イベントが複数存在する場合に、それら複数のイベントのイベント重要度を判断し、
（Ｃ）（Ｂ）で判断したイベント重要度の高いイベントから順に、前記トポロジと前記イベント伝播モデルとに基づいて所定の因果律を前記因果律情報に生成するためのオンデマンド展開を実行し、
（Ｄ）前記所定の因果律に対し、前記検知イベントが発生済みであることを記録し、
（Ｅ）前記所定の因果律を用いて、前記検知イベントを解析する、
計算機システムの管理方法。」

１００００〜１００２０：ホストコンピュータ、２００００〜２００１０：ストレージ装置、３００００：管理サーバ、３２０００：管理プログラム、３３０００：記憶資源、４００００〜４００３０：スイッチ

Claims (14)

1. コンピュータを、複数の管理対象装置を含む計算機システムを管理するための管理計算機として機能させるためのコンピュータプログラムであって、
   所定の情報を記憶する記憶資源を利用することができ、
   前記所定の情報には、
   （１）前記複数の管理対象装置又は前記複数の管理対象装置が含む複数のコンポーネントである、複数の管理オブジェクトに関して、前記複数の管理オブジェクト同士の関係を示すトポロジと、
   （２）第１種別の管理オブジェクトで発生する所定種別の第１イベントが原因となって、第２種別の管理オブジェクトで他の所定種別の第２イベントが発生する、ことを示すイベント伝播モデルと、
   （３）一つ以上の因果律を含む因果律情報と、
   が含まれており、
   前記因果律は、第１種別を有する第１管理オブジェクトで発生する前記所定種別の第１イベントが原因となって、第２種別を有する第２管理オブジェクトで前記他の所定種別の第２イベントが発生すること、を示しており、
   （Ａ）所定の管理オブジェクトで発生した問題に関するイベントを検知し、
   （Ｂ）前記検知イベントが複数存在する場合に、それら複数のイベントのイベント重要度を判断し、
   （Ｃ）（Ｂ）で判断したイベント重要度の高いイベントから順に、前記トポロジと前記イベント伝播モデルとに基づいて所定の因果律を前記因果律情報に生成するためのオンデマンド展開を実行し、
   （Ｄ）前記所定の因果律に対し、前記検知イベントが発生済みであることを記録し、
   （Ｅ）前記所定の因果律を用いて、前記検知イベントを解析する、
   コンピュータプログラム。
   
2. 請求項１記載のコンピュータプログラムであって、
   前記イベント重要度は、所定の指標に基づいて事前に定義されている、
   コンピュータプログラム。
   
3. 請求項２記載のコンピュータプログラムであって、
   前記所定の指標は、
   管理オブジェクトの種別ごとに前記イベント重要度を決定する、または、
   イベントの種別ごとに前記イベント重要度を決定する、または、
   管理オブジェクトについて事前に設定される重要度に応じて前記イベント重要度を決定する、または
   性能障害の場合、閾値またはベースラインからの計測値の逸脱度に応じて前記イベント重要度を決定する、
   のうち少なくともいずれか一つである、
   コンピュータプログラム。
   
4. 請求項３記載のコンピュータプログラムであって、
   前記イベント重要度の等しい複数イベントが有る場合、それら複数イベントのうち発生時刻の最も古いイベントを選択する、
   コンピュータプログラム。
   
5. 請求項４記載のコンピュータプログラムであって、
   前記（Ｅ）による前記検知イベントの解析結果を表示装置に出力させる、
   コンピュータプログラム。
   
6. 請求項５記載のコンピュータプログラムであって、
   前記検知イベントには有効期間が設定されており、
   前記有効期間を過ぎた場合、前記検知イベントは前記（Ｅ）による解析の対象から除外される、
   コンピュータプログラム。
   
7. 請求項６記載のコンピュータプログラムであって、
   前記（Ｅ）による前記検知イベントの解析前に、
   （Ｆ）前記検知イベントのうち前記オンデマンド展開を実行していないイベントであって、かつ、前記所定の因果律に存在する未処理イベントを検出し、
   （Ｇ）前記所定の因果律に対して、前記未処理イベントが発生済みであることを記録する、
   コンピュータプログラム。
   
8. 請求項７記載のコンピュータプログラムであって、
   前記（Ｅ）による前記検知イベントの解析では、前記所定の因果律に定義されているイベントが検出された割合を、前記第１イベントが原因である確からしさを示す確信度として計算する、
   コンピュータプログラム。
   
9. 請求項８記載のコンピュータプログラムであって、
   前記所定の情報には、
   （４）前記第１種別の管理オブジェクトと接続関係にある、前記第２種別の管理オブジェクトの個数を記録した関連機器数管理表、
   が含まれており、
   前記イベント重要度が同一であるイベントが複数存在する場合：
   （Ｈ）前記イベント伝播モデルを展開する際に必要となる、前記複数の管理オブジェクト同士の関係を示すトポロジの数を、前記関連機器数管理表を参照することで見積もり、その見積もり結果に基づいて、前記イベント重要度の等しい複数のイベントのうちいずれのイベントを優先して展開するかを判断する、
   コンピュータプログラム。
   
10. 複数の管理対象装置を含む計算機システムを管理するための管理計算機であって、
    管理プログラムを格納した記憶資源と、
    前記管理プログラムを実行するプロセッサと、
    を含み、
    前記記憶資源には、所定の情報として、
    （１）前記複数の管理対象装置又は前記複数の管理対象装置が含む複数のコンポーネントである、複数の管理オブジェクトに関して、前記複数の管理オブジェクト同士の関係を示すトポロジと、
    （２）第１種別の管理オブジェクトで発生する所定種別の第１イベントが原因となって、第２種別の管理オブジェクトで他の所定種別の第２イベントが発生する、ことを示すイベント伝播モデルと、
    （３）一つ以上の因果律を含む因果律情報と、
    が含まれており、
    前記因果律は、第１種別を有する第１管理オブジェクトで発生する前記所定種別の第１イベントが原因となって、第２種別を有する第２管理オブジェクトで前記他の所定種別の第２イベントが発生すること、を示しており、
    前記管理プログラムは、前記プロセッサに：
    （Ａ）所定の管理オブジェクトで発生した問題に関するイベントを検知させ、
    （Ｂ）前記検知イベントが複数存在する場合に、それら複数のイベントのイベント重要度を判断させ、
    （Ｃ）（Ｂ）で判断したイベント重要度の高いイベントから順に、前記トポロジと前記イベント伝播モデルとに基づいて所定の因果律を前記因果律情報に生成するためのオンデマンド展開を実行させ、
    （Ｄ）前記所定の因果律に対して、前記検知イベントが発生済みであることを記録させ、
    （Ｅ）前記所定の因果律を用いて、前記検知イベントを解析させる、
    管理計算機。
    
11. 請求項１０記載の管理計算機であって、
    前記イベント重要度は、
    管理オブジェクトの種別ごとに決定されるか、または、
    イベントの種別ごとに決定されるか、または、
    管理オブジェクトに対し予め設定される重要度に応じて決定されるか、または、
    性能障害の場合、閾値またはベースラインからの計測値の逸脱度に応じて決定されるか、
    のうち少なくともいずれか一つである、
    管理計算機。
    
12. 請求項１０記載の管理計算機であって、
    前記（Ｅ）による前記検知イベントの解析前に、
    （Ｆ）前記検知イベントのうち前記オンデマンド展開を実行していないイベントであって、かつ、前記所定の因果律に存在する未処理イベントを検出させ、
    （Ｇ）前記所定の因果律に対し、前記未処理イベントが発生済みであることを記録させる、
    管理計算機。
    
13. 請求項１２記載の管理計算機であって、
    前記（Ｅ）による前記検知イベントの解析では、前記所定の因果律に定義されているイベントが検出された割合を、前記第１イベントが原因である確からしさを示す確信度として計算する、
    管理計算機。
    
14. 請求項１０記載の管理計算機であって、
    前記所定の情報には、
    （４）前記第１種別の管理オブジェクトと接続関係にある、前記第２種別の管理オブジェクトの個数を記録した関連機器数管理表、
    が含まれており、
    前記イベント重要度が同一であるイベントが複数存在する場合：
    （Ｈ）前記イベント伝播モデルを展開する際に必要となる、前記複数の管理オブジェクト同士の関係を示すトポロジの数を、前記関連機器数管理表を参照することで見積もり、その見積もり結果に基づいて、前記イベント重要度の等しい複数のイベントのうちいずれのイベントを優先して展開するかを判断させる、
    管理計算機。

Images