処理中

しばらくお待ちください...

設定

設定

出願の表示

1. WO2013125037 - コンピュータプログラムおよび管理計算機

Document

明 細 書

発明の名称 コンピュータプログラムおよび管理計算機

技術分野

0001  

背景技術

0002   0003   0004  

先行技術文献

特許文献

0005  

発明の概要

発明が解決しようとする課題

0006   0007  

課題を解決するための手段

0008  

図面の簡単な説明

0009  

発明を実施するための形態

0010   0011   0012   0013   0014   0015   0016   0017   0018   0019   0020   0021   0022   0023   0024   0025   0026   0027   0028   0029   0030   0031   0032   0033   0034   0035   0036   0037   0038   0039   0040   0041   0042   0043   0044   0045   0046   0047   0048   0049   0050   0051   0052   0053   0054   0055   0056   0057  

実施例 1

0058   0059   0060   0061   0062   0063   0064   0065   0066   0067   0068   0069   0070   0071   0072   0073   0074   0075   0076   0077   0078   0079   0080   0081   0082   0083   0084   0085   0086   0087   0088   0089   0090   0091   0092   0093   0094   0095   0096   0097   0098   0099   0100   0101   0102   0103   0104   0105   0106   0107   0108   0109   0110   0111   0112   0113   0114   0115   0116   0117   0118   0119   0120   0121   0122   0123   0124   0125   0126   0127   0128   0129   0130   0131   0132   0133   0134   0135   0136   0137   0138   0139   0140   0141   0142   0143   0144   0145   0146   0147   0148   0149   0150   0151   0152   0153   0154   0155   0156   0157   0158   0159   0160   0161   0162   0163   0164   0165   0166   0167   0168   0169   0170   0171   0172   0173   0174   0175   0176   0177   0178   0179   0180   0181   0182   0183   0184   0185   0186   0187   0188   0189   0190   0191   0192   0193   0194   0195   0196   0197   0198   0199   0200   0201   0202   0203   0204  

実施例 2

0205   0206   0207   0208   0209   0210   0211   0212   0213   0214   0215   0216   0217   0218   0219   0220   0221   0222   0223   0224   0225   0226   0227   0228   0229   0230   0231   0232   0233   0234   0235   0236   0237   0238   0239   0240   0241   0242   0243  

実施例 3

0244   0245   0246   0247   0248   0249   0250   0251   0252   0253   0254   0255   0256   0257   0258   0259   0260   0261   0262   0263   0264   0265   0266   0267   0268   0269   0270   0271   0272   0273   0274   0275   0276   0277   0278   0279   0280   0281  

符号の説明

0282  

請求の範囲

1   2   3   4   5   6   7   8   9   10   11   12   13   14  

図面

1   2   3   4   5   6   7   8A   8B   8C   9   10   11   12   13A   13B   14A   14B   15A   15B   15C   15D   15E   16A   16B   17   18   19   20   21   22A   22B   23   24   25   26  

明 細 書

発明の名称 : コンピュータプログラムおよび管理計算機

技術分野

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

背景技術

[0002]
 特許文献1には、計算機システムの管理対象コンポーネントで発生した問題の原因を決定する管理サーバが開示されている。特許文献1の管理プログラムは、管理対象装置における各種障害をイベント化し、イベントデータベースに情報を蓄積する。
[0003]
 また、この管理プログラムは、管理対象装置において発生した複数の障害イベントの因果関係を解析するための解析エンジンを持っている。解析エンジンは、管理対象装置のインベントリ情報を持つ構成データベースにアクセスして、I/O(Input/Output)系路上のパス上にある管理対象装置内のコンポーネントを、「トポロジ」と呼ばれる一グループとして認識する。
[0004]
 そして、この解析エンジンは前記トポロジに対し、事前に定められた条件文と解析結果とからなる障害伝播モデル(IF-THEN形式ルール)を適用して、因果律行列を構築する。因果律行列には、他装置における障害の原因である原因イベントと、それによって引き起こされている関連イベント群が含まれる。障害伝播モデルのTHEN部に障害の根本原因として記載されているイベントが原因イベントであり、IF部に記載されているイベントのうち原因イベント以外のものが関連イベントである。

先行技術文献

特許文献

[0005]
特許文献1 : 米国特許7107185号公報

発明の概要

発明が解決しようとする課題

[0006]
 特許文献1に記載の従来技術では、管理対象の全ての装置及び全てのイベント伝播モデルに基づいて、イベント発生前に因果律を作成する。そのため、従来技術では、大規模又は多数の因果律が必要となる複雑な計算機システムを解析する場合は、因果律を格納するためのルールメモリのサイズが大きくなる。従って、従来技術では、管理計算機の記憶資源(例えば、メモリまたは二次記憶装置)を大量に消費する。
[0007]
 本発明は、上記の問題に鑑みてなされたもので、記憶資源を効率的に使用することができ、かつ、比較的速やかに原因を解析できるようにしたコンピュータプログラムおよび管理計算機を提供することにある。

課題を解決するための手段

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

図面の簡単な説明

[0009]
[図1] 実施形態の概要を説明した模式図である。
[図2] 計算機システムの物理構成例を示す図である。
[図3] ホストコンピュータの構成例を示す図である。
[図4] ストレージ装置の構成例を示す図である。
[図5] 管理サーバの構成例を示す図である。
[図6] 管理プログラムの論理的構成例を示した図である。
[図7] IPスイッチの構成例を示す図である。
[図8A] ホストコンピュータの有する論理ボリューム管理表の構成例を示す。
[図8B] 論理ボリューム管理表の他の例を示す。
[図8C] 論理ボリューム管理表のさらに他の例を示す。
[図9] ストレージ装置が含むボリューム管理表の構成例を示す図である。
[図10] ストレージ装置が含むiSCSIターゲット管理表の構成例を示す。
[図11] ストレージ装置が含むI/Oポート管理表の構成例を示す図である。
[図12] ストレージ装置が含むRAIDグループ管理表の構成例を示す図である。
[図13A] 管理サーバが含むイベント管理表の構成例を示す図である。
[図13B] 管理サーバが含むイベント管理表の他の例を示す。
[図14A] 管理サーバが含むイベント伝播モデルの構成例を示す図である。
[図14B] イベント伝播モデルの他の例を示す。
[図15A] 管理サーバが含むルールメモリの構成例を示す図である。
[図15B] ルールメモリの他の例を示す。
[図15C] ルールメモリのさらに他の例を示す。
[図15D] ルールメモリの別の例を示す。
[図15E] ルールメモリのさらに別の例を示す。
[図16A] 管理サーバが含むトポロジ生成方式の構成例を示す図である。
[図16B] 管理サーバが含むトポロジ生成方式の他の例を示す。
[図17] 管理サーバが含む展開対象イベント伝播モデル管理表の構成例を示す。
[図18] 管理サーバが含むイベント重要度管理表の構成例を示す図である。
[図19] 管理サーバが実行する装置情報取得処理のフローチャートである。
[図20] 管理サーバが実行するイベント確認処理のフローチャートである。
[図21] 管理サーバが実行するイベント伝播モデルオンデマンド展開処理のフローチャートである。
[図22A] 実施例2において管理サーバが実行するイベント伝播モデルオンデマンド展開処理のフローチャートである。
[図22B] 図22Aに続くフローチャートである。
[図23] 実施例3において管理サーバが含む関連機器数管理表の構成例を示す。
[図24] 実施例3において管理サーバが実行するイベント伝播モデルオンデマンド展開処理のフローチャートである。
[図25] 計算機システムの物理構成例を示す図である。
[図26] 管理サーバが含むイベント管理表の構成例を示す図である。

発明を実施するための形態

[0010]
 以下、図面を参照して、実施例を説明する。なお、以後の説明では「aaaテーブル」、「aaaリスト」、「aaaDB」、「aaaキュー」、「aaa行列」等の表現にて実施例の情報を説明するが、これら情報はテーブル、リスト、DB、キュー、行列、等のデータ構造以外で表現されていてもよい。そのため、データ構造に依存しないことを示すために「aaaテーブル」、「aaaリスト」、「aaaDB」、「aaaキュー」、「aaaリポジトリ」、「aaa行列」等について「aaa情報」と呼ぶことがある。さらに、各情報の内容を説明する際に、「識別情報」、「識別子」、「名」、「名前」、「ID」という表現を用いるが、これらについてはお互いに置換が可能である。さらに、データ内容を示すために「情報」という表現を用いているが、他の表現形式であってもよい。なお、実施例の説明において「リポジトリ」という用語を用いるが、「情報」と同じ意味である。
[0011]
 以後の説明では「プログラム」を主語として説明を行う場合があるが、プログラムはプロセッサによって実行されることで定められた処理をメモリ及び通信ポート(通信制御装置)を用いながら行うため、プロセッサを主語とした説明としてもよい。また、プログラムを主語として開示された処理は管理サーバ又はストレージシステム等の計算機、情報処理装置が行う処理としてもよい。また、プログラムの一部または全ては専用ハードウェアによって実現されてもよい。また、各種プログラムはプログラム配布サーバや記憶メディアによって各計算機にインストールされてもよい。
[0012]
 本実施形態の管理計算機は、計算機システムのトポロジと、イベント伝播モデルと、一つ以上の因果律を含む因果律情報とを、メモリ等の記憶領域に格納する。管理計算機がイベントを解析又は検知したことを契機として、管理計算機は、トポロジとイベント伝播モデルとに基づいて因果律を作成する。
[0013]
 管理計算機が複数のイベントを同時に検知した場合、イベントの重要度の高い順に因果律を作成する。作成された因果律は、因果律情報の一部として保存される。実施形態では、ルールメモリが因果律情報の一例である。
[0014]
 本実施形態では、イベントの検出時または解析時に、そのイベントの解析に必要な範囲内で、因果律を作成して記憶する。従って、因果律情報のサイズを必要最小限に止めることができ、記憶資源を効率的に使用することができる。さらに、本実施形態によれば、多数の障害イベントを同時に解析する場合、重要度の高いイベント(障害)について迅速に解析結果を得ることができる。
[0015]
 図1は、本実施形態の概要を示した図である。管理サーバ30000は、計算機システム内の複数の管理対象装置を管理するための計算機である。図中、管理対象装置を装置と略記している。
[0016]
 管理対象装置の種別としては例えば、ホストコンピュータ(サーバ)、IPスイッチまたはルータ等のネットワーク装置、NAS(Network Attached Storage)またはストレージ装置等がある。
[0017]
 本実施形態では、管理対象装置が含むデバイス等の論理的又は物理的な構成物をコンポーネントと呼ぶ。コンポーネントの例としては通信ポート、マイクロプロセッサ、記憶資源、記憶デバイス、コンピュータプログラム、仮想マシン、論理ボリュームおよびRAIDグループ(ストレージ装置内部で定義される)等がある。なお、管理対象装置とコンポーネントを区別せずに扱う場合は、管理オブジェクトと呼ぶ。
[0018]
 管理サーバ30000は、これら管理対象装置から装置情報を取得し、取得した装置情報に基づいて、管理対象装置の管理情報を表示する。装置情報には、例えば、管理対象装置の構成を示す構成情報と、管理対象装置で発生した障害情報と、管理対象装置の性能情報などを含めることができる。管理対象装置の管理情報には、例えば、管理対象装置の構成情報、障害発生の有無を示す情報、性能値を示す情報などが含まれる。
[0019]
 なお、いくつかの管理対象装置は、何かしらのネットワークサービス(例えば、iSCSI、ファイル共有サービス、DNS、その他Webサービス)のサーバである。他のいくつかの管理対象装置はクライアントとして、これらサーバが提供するネットワークサービスを利用する。
[0020]
 この場合、サーバである管理対象装置(サーバ装置と呼ぶことがある)でサービス提供に関係する問題(例えば管理オブジェクトの障害または性能障害等)が発生すると、当該サービスを利用しているクライアント管理対象装置(クライアント装置と呼ぶことがある)においても管理オブジェクトに関する問題が発生する。
[0021]
 なお、以後の説明では、管理オブジェクトで発生した問題を管理サーバで示す情報を、イベントと呼ぶ。また、「イベントの検知」とは「問題の発生を検知し、イベント情報を作成すること」を意味する。なお、「イベントの発生」とは、「問題の発生」と同じ意味である。
[0022]
 管理サーバ30000は、ある管理対象装置で発生した問題の原因が他の管理対象装置で発生した問題であることを解析し、その解析結果を表示することができる。そのために管理サーバ30000は以下の情報を格納しており、それらの情報を解析に用いる。
[0023]
 (情報1)構成情報
[0024]
 構成情報は、管理対象装置の構成を示す情報を格納する。管理対象装置の構成は、インベントリとも呼ばれる。構成情報には、管理対象装置が含むコンポーネントと、コンポーネント同士の対応関係のような管理オブジェクト間の対応関係とが含まれる。
[0025]
 構成情報には、クライアント装置に関して、ネットワークサービスを受けるためのサーバ装置(またはサーバ装置のコンポーネント)の識別情報が含まれる。例えば、後述するiSCSIプロトコルによるLU(Logical Unit)提供がネットワークサービスである場合を説明する。この場合、識別情報としてiSCSIターゲット名とLUN(Logical Unit Number)を指定する。クライアント装置は、その識別情報に基づいて、ストレージ装置が提供するLUにアクセスする。ネットワークサービスがWebサービスである場合は、識別情報としてWebサーバのURL(Uniform Resource Locator)を指定する。クライアント装置は、URLに基づいてWebページにアクセスする。
[0026]
 構成情報には、サーバ装置に関して、アクセス元となるクライアント装置に関する識別情報を含む場合もある。このような管理対象装置内又は複数の管理対象装置に跨る、複数の管理オブジェクト間の関係を、トポロジと呼ぶ。
[0027]
 (情報2)イベント伝播モデルの情報
[0028]
 イベント伝搬モデルの情報(以後、単にイベント伝播モデルと呼ぶ)には、一つ以上の観測種別ペアと一つ以上の原因種別ペアとが含まれる。詳細は以下の通りである。
[0029]
 (2A)原因種別ペア
[0030]
 原因種別ペアとは、管理オブジェクトの種別(管理オブジェクト原因種別と呼ぶことがある)と、イベントの種別(イベント原因種別)とのペアである。イベント原因種別は、管理オブジェクト原因種別で定められる種別の管理オブジェクトで発生する可能性のあるイベントの種別である。
[0031]
 (2B)観測種別ペア
[0032]
 観測種別ペアとは、管理オブジェクトの種別(管理オブジェクト観測種別と呼ぶことがある)と、イベントの種別(イベント観測種別)とのペアである。イベント観測種別は、管理オブジェクト観測種別で定められる種別の管理オブジェクトで発生する可能性のあるイベントの種別である。観測種別ペアは、原因種別ペアの種別で定められるイベントが発生した場合に、合わせて発生するイベントの種別を示す。
[0033]
 なお、あるイベント伝播モデルに含まれる観測種別ペアのイベントを全て検知した場合に、対応する原因種別ペアのイベント発生が原因であるほうがより好ましいが、必須ではない。
[0034]
 管理サーバ30000による解析処理は、より具体的には、イベント伝播モデルとトポロジとに基づいて、因果律を因果律情報に作成する。管理サーバ30000の解析処理は、因果律情報を用いてイベントを解析する。
[0035]
 因果律とは、第1の管理オブジェクトで第1のイベントが発生した場合は、第2の管理オブジェクトで第2のイベントが発生することを示す情報である。第1のイベントが原因であると断定できる条件は、第1のイベントに関連した全ての第2イベントを検知すること、であるほうが望ましい。ただしこれは必須ではない。因果律情報は上記内容を示すことが出来れば、因果律行列の形式であってもよい。または、因果律情報は、関係を示すポインタ情報を駆使して第1のイベントと第2のイベントとの関係を示したデータ構造であってもよい。
[0036]
 管理サーバ30000は、オンデマンドでイベントコリレーション情報を作成する。つまり、管理サーバ30000は、その存在を検知したが未解析の所定イベントに対応するイベントコリレーション情報がイベントリポジトリに作成済みか否か判断する。管理サーバ30000は、イベントコリレーション情報を未作成の場合、所定イベントが関係するトポロジと、所定イベントが関係するイベント伝播モデルとを用いて、イベントコリレーション情報を作成し、所定イベントを解析する。
[0037]
 イベント解析の例としては以下が考えられる。
[0038]
 (解析例1) イベント解析例1では、検知した或るイベント1の原因となるイベント2を特定する。この特定処理は、因果律情報を参照することで可能である。管理サーバ(または後述する管理システム)は、自身の表示デバイスにイベント1の情報と共に、イベント2が原因で当該イベント1が発生した旨のメッセージを表示してもよい。
[0039]
 (解析例2) イベント解析例2では、検知した或るイベント3を原因として発生する(または発生する可能性がある)イベント4を求める。この特定処理は、因果律情報を参照することで可能である。管理サーバ(または管理システム)は、自身の表示デバイスに、イベント3の発生が原因となってイベント4が発生する(または発生する可能性がある)旨のメッセージを表示してもよい。
[0040]
 管理サーバ30000は、イベントを検知した後に、(1)その検知イベントを観測種別ペアまたは原因種別ペアに含むイベント伝播モデルと、(2)その検知イベントが発生したコンポーネントと関係するトポロジと、に基づいて、所定の因果律を因果律情報に作成する。所定の因果律を因果律情報に作成することを、後述の説明では、因果律を展開するとも言う。
[0041]
 なお、このようなイベント検知を契機として因果律を展開することを、オンデマンド展開と呼ぶ。オンデマンド展開によって、大規模な計算機システムまたは複雑な計算機システムを対象にしたイベント解析でも因果律情報のサイズをより少なくできる。
[0042]
 管理サーバ30000が複数のイベントを検知した際は、イベントに付与された重要度の高いイベントから順に、因果律の展開処理を行う。その結果、管理サーバ30000の管理する計算機システムが大規模化したり、または、管理サーバ30000が単位時間当たりに検知する障害の数が増大したりしても、重要度の高い障害の解析が遅れることを抑制できる。
[0043]
 イベントの重要度を定義する指標としては、以下の例が挙げられる。(指標例1)管理オブジェクトの種別ごとにまたはイベントの種別ごとに事前に付与された重要度、(指標例2)障害の発生した機器の重要度または障害の発生した業務の重要度、(指標例3)性能障害の場合、閾値またはベースラインからの計測値の逸脱度。
[0044]
 イベントの重要度を定義する指標として、上記の例などが考えられるが、上記の例以外の他の指標を用いてもよい。また、イベントの展開処理を行う順序を決定する際、イベントを検知した時刻を考慮してもよいし、考慮しなくてもよい。
[0045]
 次に、管理サーバ30000は、検知イベントを含む因果律情報を参照し、因果律情報内に定義された観測種別ペアのうち幾つが実際に発生しているかを調査する。さらに、管理サーバ30000は、実際に発生したイベントが定義された観測種別ペアに占める割合を「確信度」として算出する(確信度=実際に発生したイベントの数/定義された観測種別ペアの数)。確信度は、因果律情報内に定義された原因種別ペアの確からしさを示す指標とすることができる。
[0046]
 解析開始から長時間経過すると、様々な管理オブジェクトから様々な種別のイベントを検知する傾向にある。そのため、管理サーバ30000は、イベントに有効期間を与え、有効期間を過ぎたイベントは解析対象から外してもよい。このようにすることで、時系列の大きく離れたイベント同士を解析対象とすることによる、解析結果へのノイズの発生を軽減することができる。
[0047]
 図1の下側に示すように、コンポーネント1(種別a)で発生するイベントA1(種別A)の原因が、コンポーネント2(種別b)で発生するイベントB2(種別B)であることを示す、イベントコリレーション1が作成済みである。図1は、このイベントコリレーション1が作成済みの状況下において、コンポーネント3(種別a)でのイベントA3(種別A)を実際に検知した場合の概要を示している。
[0048]
 なお、イベントコリレーション1は、過去にイベントA1を検知したときを契機に、トポロジ1とイベント伝播モデル1とに基づいて、いわゆるオンデマンドで作成したものである。ルールメモリに空き容量がある限り、かつ管理対象オブジェクトの構成に変化がない限り、過去に作成されたイベントコリレーションは保存される。
[0049]
 イベントコリレーション1が作成済みの状況下においてコンポーネント3(種別a)でイベントA3(種別A)が検出されると、管理サーバ30000は、トポロジ2とイベント伝播モデル1とに基づいてイベントコリレーション2を作成する。イベントコリレーション2は、イベントA3(種別A)の原因はコンポーネント2(種別b)で発生するイベントB2(種別B)であることを示す。
[0050]
 因果律を作成済みであるか判断する場合または因果律を展開する場合、イベント伝播モデルの個々にアクセスして、イベント伝播モデルとイベントとの関係性を判断したとすると、イベント伝播モデル数に比例して処理時間が長くなる。そのため、管理サーバ30000は、管理オブジェクトの種別とそこで発生するイベントの種別のペアとから、当該ペアを原因種別ペアまたは観測種別ペアに含むイベント伝播モデルのIDを特定可能なデータ構造を事前に作成してもよい。管理サーバ30000は、因果律を作成済みであるか判断する場合または因果律を展開する場合に、そのデータ構造を参照してもよい。これにより、処理時間を短縮できる。
[0051]
 以上が本実施例の概要である。以後の記載では、以下の場合を例示する。本発明は以下の例に限定されない。
[0052]
 * ネットワークサービス:ネットワークサービスとしては、iSCSIプロトコルによるストレージアクセスを例に挙げる。この場合、クライアント装置がホストコンピュータとなり、サーバ装置がストレージ装置となる。
[0053]
 * イベントコリレーション情報:イベントコリレーション情報の例としてルールメモリを挙げる。
[0054]
 * 管理対象装置: 管理対象装置の例として、ホストコンピュータ、IPスイッチ、ストレージ装置を挙げる。
[0055]
 * 管理オブジェクト:管理オブジェクトの例として、コンポーネントを挙げる。
[0056]
 * コンポーネント:コンポーネントの例として、iSCSIターゲット、ボリューム、RAIDグループ、ディスク、ホストコンピュータのドライブ名を挙げる。
[0057]
 * イベント重要度の定義指標:イベント重要度を定義するための指標として、管理オブジェクトの種別、または、イベント種別ごとに事前に付与された重要度を例に挙げて説明する。
実施例 1
[0058]
 図2から図7は、計算機システムの構成と、計算機システムに接続される装置の構成とを示す。図8から図18は、各装置に具備される管理情報を示す。
[0059]
 図2は、計算機システムの物理的構成を示す図である。計算機システムは、ストレージ装置20000,20010と、ホストコンピュータ10000,10010と、管理サーバ30000と、WEBブラウザ起動サーバ35000と、IPスイッチ40000,40010とを有し、それらが、ネットワーク45000によって接続されている。
[0060]
 ホストコンピュータ10000乃至10010は、例えば、それらに接続された、図示しないクライアントコンピュータからファイルのI/O要求を受信し、それに基づいてストレージ装置20000乃至20010にアクセスする。管理サーバ(管理計算機)30000は、計算機システム全体の運用を管理するものである。
[0061]
 WEB(WWW)ブラウザ起動サーバ35000は、ネットワーク45000を介して管理サーバ30000のGUI(Graphical User Interface)表示処理モジュール32300(図6)と通信し、WEBブラウザ上に各種情報を表示する計算機である。ユーザは、WEBブラウザ起動サーバ35000上のWEBブラウザに表示された情報を参照することで、計算機システム内の装置を管理する。ただし、管理サーバ30000と、WEBブラウザ起動サーバ35000は1台のサーバから構成されていてもよい。
[0062]
 図3は、ホストコンピュータ10000の詳細な内部構成例を示す図である。ホストコンピュータ10010も同様の構成を有する。ホストコンピュータ10000は、ネットワーク45000に接続するための通信ポート11000と、プロセッサ12000と、メモリ13000と、を有し、これらは内部バス等の回路を介して相互に接続される構成となっている。
[0063]
 メモリ13000は、ディスク装置などを含む構成でもよい。メモリ13000には、業務アプリケーションプログラム13100と、オペレーティングシステム13200と、論理ボリューム管理表13300と、が格納される。
[0064]
 業務アプリケーション13100は、オペレーティングシステム13200から提供された記憶領域を使用し、その記憶領域に対してデータを入出力させる。以下、データ入出力のことをI/Oと表記する場合がある。
[0065]
 オペレーティングシステム13200は、ネットワーク45000を介してホストコンピュータ10000に接続されたストレージ装置20000乃至20010上の論理ボリュームを、記憶領域として業務アプリケーション13100に認識させるための処理を実行する。以下、論理ボリュームをボリュームと略記する場合がある。
[0066]
 ポート11000は、I/Oポートと管理ポートを含む単一のポートであるかのように、図3で示されている。I/Oポートとは、ストレージ装置20000とiSCSIにより通信を行うためのポートである。管理ポートとは、管理サーバ30000がホストコンピュータ内の管理情報を取得するためのポートである。I/Oポートと管理ポートとがそれぞれ別々に設けられる構成でもよい。
[0067]
 図4は、ストレージ装置20000の詳細な内部構成例を示す図である。ストレージ装置20010も同様の構成を有している。
[0068]
 ストレージ装置20000は、複数のI/Oポート21000,21010と、一つの管理ポート21100と、管理メモリ23000と、RAIDグループ24000,24010と、記憶デバイス24200,24210,24220,24230と、論理ボリューム24100,24110と、コントローラ25000,25010と備える。それらのうち物理的構成(I/Oポート、管理ポート、管理メモリ、コントローラ、記憶デバイス)は、内部バス等の回路を介して相互に接続されている。
[0069]
 I/Oポート21000は、ネットワーク45010を介してホストコンピュータ10000、10010に接続するためのポートである。同様に、I/Oポート21010は、ネットワーク45020を介してホストコンピュータ10000,10010に接続するための回路である。管理ポート21100は、ネットワーク45000を介して管理サーバ30000に接続するためのポートである。ネットワーク45010,45020は、ネットワーク45000の一部である。
[0070]
 管理メモリ23000は、後述のように、各種管理情報を格納する。RAIDグループ24000,24010は、データを格納する。コントローラ25000,25010は、データと管理メモリ内の管理情報とを制御する。
[0071]
 管理メモリ23000には、ストレージ装置20000を管理するプログラム23100と、ボリューム管理表23200と、iSCSIターゲット管理表23300と、I/Oポート管理表23400と、RAIDグループ管理表23500と、ディスク管理表23600とが格納される。管理プログラム23100は、管理ポート21100を経由して管理サーバ30000と通信し、管理サーバ30000にストレージ装置20000の構成情報を提供する。
[0072]
 RAIDグループ24000乃至24010は、それぞれ、1つまたは複数の記憶デバイス24200、24210、24220、及び24230によって構成されている。複数の記憶デバイスによって構成されている場合、それらの記憶デバイスはRAID構成を組んでいてもよい。また、RAIDグループ24000乃至24010は、論理的に複数のボリューム24100乃至24110に分割されている。
[0073]
 論理ボリューム24100及び24110は、1つ以上の記憶デバイスの記憶領域を用いて構成することができる。論理ボリューム24100,24110は、必ずしもRAID構成を備える必要はない。
[0074]
 記憶デバイス24200-24230は、例えば、ハードディスクデバイス、半導体メモリデバイス、光ディスクデバイス、光磁気ディスクデバイス等のデータを読み書き可能な種々の記憶デバイスとして構成可能である。
[0075]
 記憶デバイス24200-24230がハードディスクデバイスである場合、例えば、FC(Fibre Channel)ディスク、SCSI(Small Computer System Interface)ディスク、SATAディスク、ATA(AT Attachment)ディスク、SAS(Serial Attached SCSI)ディスク等のように構成することができる。
[0076]
 記憶デバイス24200-24230は、例えば、フラッシュメモリ、FeRAM(Ferroelectric Random Access Memory)、MRAM(MagnetoresistiveRandom Access Memory)、相変化メモリ(Ovonic Unified Memory)、RRAM(登録商標:Resistance RAM)等の種々の記憶デバイスとして構成してもよい。さらに、フラッシュメモリデバイスとして構成される記憶デバイスと、ハードディスクデバイスとして構成される記憶デバイスとが混在する構成でもよい。
[0077]
 コントローラ25000及び25010は、ストレージ装置20000内の制御を行うプロセッサと、ホストコンピュータ10000,10010との間でやりとりするデータを一時的に記憶するキャッシュメモリとを備える(いずれも不図示)。そして、それぞれのコントローラ25000,25010は、I/Oポート21000,21010とRAIDグループ24000,24010との間に介在しており、各I/Oポートと各RAIDグループとの間でのデータ受け渡しを制御する。
[0078]
 ストレージ装置20000は、上記の構成以外の構成であってもよい。ストレージ装置は、ホストコンピュータに論理ボリュームを提供し、ホストコンピュータから受信したアクセス要求(I/O要求)に応じて記憶デバイスに読み書きできる構成を備えていれば、どのような構成であってもよい。例えば、ストレージコントローラと記憶デバイスとをそれぞれ別々の筐体に格納する構成でもよい。
[0079]
 図4の例では、例えば、ストレージコントローラを、管理メモリ23000と、コントローラ25000及び25110等とから構成してもよい。本明細書では、ストレージコントローラと記憶デバイスとが同一筐体に存在する場合、または別々の筐体に存在する場合の両方の場合を含む表現として、ストレージ装置をストレージシステムと呼び変えても良い。
[0080]
 図5及び図6は、管理サーバ30000の詳細な内部構成例を示す図である。管理サーバ30000は、例えば、管理ポート31000と、プロセッサ31100と、記憶資源33000と、出力デバイス34000と、入力デバイス34100とを有し、これらが内部バス等の回路を介して相互に接続されている。
[0081]
 管理ポート31000は、ネットワーク45000を介して管理対象装置であるホストコンピュータとストレージ装置およびスイッチに接続される。記憶資源33000は、半導体メモリ装置および/または補助記憶装置から構成してもよい。
[0082]
 出力デバイス34000は、後述する処理結果を出力するための装置である。出力デバイス34000は、例えば、ディスプレイ装置、プリンタ装置、音声合成装置のように構成できる。入力デバイス34100は、ストレージ管理者がストレージ装置に指示を入力するための装置である。入力デバイス34100は、例えば、キーボードスイッチ、タッチパネル、音声入力装置のように構成できる。
[0083]
 記憶資源33000には、管理プログラム32000が格納される。図6に示すように管理プログラム32000は、プログラム制御モジュール32100と、装置情報取得モジュール32200と、GUI表示処理モジュール32300と、イベント解析処理モジュール32400と、イベント伝播モデル展開モジュール32500と、を含む。
[0084]
 各モジュールは、メモリ32000に格納されるプログラムモジュールとして提供されているが、ハードウェアモジュールとして提供されてもよい。管理プログラム32000は、各モジュールの処理を実現できるのであれば、モジュールによって構成されなくてもよい。言い方を変えれば、以下の説明における各モジュールについての説明は、管理プログラム32000に関する説明と置き換えてもよいということである。
[0085]
 図5に戻る。記憶資源33000にはさらに、イベント管理表33100と、イベント伝播モデルリポジトリ33200と、ルールメモリ33300と、トポロジ生成方式リポジトリ33400と、構成DB33500と、展開対象イベント伝播モデル管理表33600と、イベント重要度管理表33700と、関連装置数管理表33800と、が格納されている。構成DB33500には、構成情報が格納される。
[0086]
 構成情報は、装置情報取得モジュール32200によって、各管理対象装置から収集される。構成情報には、例えば、管理対象の各ホストコンピュータから収集された論理ボリューム管理表13300の各項目と、管理対象の各ストレージから収集されたボリューム管理表23200の各項目と、iSCSIターゲット管理表23300各項目と、I/Oポート管理表23400各項目と、RAIDグループ管理表23500各項目とが含まれている。
[0087]
 構成DB33500には、管理対象装置の有する全ての表、または表中の全ての項目を格納しなくてもよい。その都度必要に応じて、管理サーバ30000が管理対象装置から情報を取得する構成でもよい。
[0088]
 構成DB33500が格納する各項目のデータ表現形式またはデータ構造は、管理対象装置と同一である必要はない。管理プログラム32000が管理対象装置からこれら各項目を受信する場合、管理対象装置で使用するデータ構造またはデータ表現形式のままで受信してもよい。
[0089]
 装置情報取得モジュール32200は、管理対象装置に定期的または不定期に繰り返しアクセスして、管理対象装置の構成情報と、管理対象装置内の各コンポーネントの状態とを取得する。イベント解析処理モジュール32400は、ルールメモリ33300を参照して、管理対象装置で生じた異常状態の根本原因を解析する。管理対象装置で発生した異常状態に関する情報は、装置情報取得モジュール32200により取得される。
[0090]
 GUI表示処理モジュール32300は、入力デバイス34100を介した管理者からの要求に応じて、構成管理情報などを出力デバイス34000に表示する。入力デバイス34100と出力デバイス34000とはそれぞれ別々なデバイスとして構成されてもよいし、または、タブレット型端末のように一つのまとまったデバイスとして構成されてもよい。
[0091]
 なお、管理サーバ(管理計算機)は、例えば、入出力デバイスとして、ディスプレイとキーボードとポインタデバイス等を有しているが、これ以外の装置であってもよい。入出力デバイスの代替としてシリアルインターフェースやイーサーネットインターフェース(イーサネットは登録商標)を用い、それらインターフェースに表示用計算機を接続する構成でもよい。
[0092]
 表示用計算機は、例えばWEBブラウザ起動サーバ35000として構成され、ディスプレイ装置、およびキーボードまたはポインタデバイスを有する。管理サーバは、表示用情報を表示用計算機に送信して表示させたり、入力用情報を表示用計算機から受信して受け付けたりすることができる。つまり、管理サーバ30000の外部にマンマシンインターフェース機能を有する表示用計算機を設ける構成の場合、出力デバイス34000および入力デバイス34100を省略することができる。
[0093]
 本明細書では、計算機システム(情報処理システム)を管理し、表示用情報を表示する一つ以上の計算機の集合を管理システムと呼ぶことがある。管理サーバが表示用情報を表示する場合は、管理サーバが管理システムである。管理サーバと表示用計算機(例えば図2のWEBブラウザ起動サーバ35000)の組み合わせも管理システムである。管理処理の高速化および高信頼化のために、複数の計算機で管理サーバと同等の処理を実現してもよい。この場合は、それら複数の計算機(表示を表示用計算機が行う場合は表示用計算機も含め)が管理システムである。
[0094]
 図7にIPスイッチ40000の詳細な構成を示す。IPスイッチ40010も同様の構成を有する。IPスイッチ40000は、プロセッサ41000と、各種管理情報を保持するためのメモリ42000と、I/Oポート43000,43010と、管理ポート44000とを有し、これらは内部バス等の回路を介して相互に接続される。I/Oポート43000はネットワーク45010に接続され、I/Oポート43010はネットワーク45020に接続され、管理ポート44000はネットワーク45000に接続されている。
[0095]
 メモリ42000は、その全部を半導体メモリから構成してもよいし、ハードディスク装置のような他の記憶デバイスを含んで構成してもよい。
[0096]
 図8A、8B及び8Cは、ホストコンピュータ10000の具備する論理ボリューム管理表13300の構成例を示す図である。
[0097]
 論理ボリューム管理表13300は、論理ボリュームを管理するための表であり、フィールド13310,13320,13330,13340を備える。フィールド13310には、ホストコンピュータ内で各論理ボリュームを識別するための識別子(ドライブ名)を登録する。フィールド13320には、iSCSIイニシエータ名を登録する。iSCSIイニシエータ名は、論理ボリュームの実体が存在するストレージ装置との通信の際に用いる、ホストコンピュータ上のI/Oポート11000の識別子である。
[0098]
 フィールド13330には、接続先のiSCSIターゲットを登録する。iSCSIターゲットは、論理ボリュームの実体が存在するストレージ装置との通信の際に用いる、ストレージ装置上のI/Oポート21000の識別子である。フィールド13340には、ストレージ装置において論理ボリュームの識別子となるLUN IDを登録する。
[0099]
 図8Aには、ホストコンピュータの具備する論理ボリューム管理表13300の具体的な値の一例を示している。
[0100]
 つまり、ホストコンピュータ上で(E:)というドライブ名で示される論理ボリュームは、”com.hitachi.sv1”というiSCSIイニシエータ名で示されるホストコンピュータ上のポートと、”com.hitachi.sto1”というiSCSIターゲット名で示されるストレージ装置上のポートとを介してストレージ装置と接続しており、”0”というLUN IDをストレージ装置上で持つ。
[0101]
 図9は、ストレージ装置20000の具備するボリューム管理表23200を示す図である。
[0102]
 ボリューム管理表23200は、フィールド23210,23220,23230,23240,23250を備える。フィールド23210には、ストレージ装置内で各論理ボリュームの識別子となるボリュームIDを登録する。フィールド23220には、各論理ボリュームの容量を登録する。フィールド23230には、各論理ボリュームが所属するRAIDグループの識別子であるRAIDグループIDを登録する。
[0103]
 フィールド23240には、各論理ボリュームが所属するiSCSIターゲットの識別子であるターゲットIDを登録する。フィールド23250には、各論理ボリュームのiSCSIターゲット内での識別子であるLUN IDを登録する。
[0104]
 図9には、ストレージ装置の具備するボリューム管理表23200の具体的な値の一例を示している。つまり、ストレージ装置上のボリューム”VOL1”は、”20GB”の記憶領域を持ち、”RG1”というRAIDグループIDで示されるRAIDグループに属し、”TG1”というiSCSIターゲットIDで示されるiSCSIターゲットに属し、”0”というLUN IDを持つ。
[0105]
 図10は、ストレージ装置20000の具備するiSCSIターゲット管理表23300を示す図である。
[0106]
 iSCSIターゲット管理表23300は、フィールド23310,23320,23330を備える。フィールド23310には、ストレージ装置内でiSCSIターゲットの識別子となるターゲットIDを登録する。フィールド23320には、各iSCSIターゲットが持つiSCSIターゲット名を登録する。フィールド23330には、各iSCSIターゲットに属するボリュームに対してアクセスが許可された、ホストコンピュータ上のポートの識別子であるiSCSIイニシエータ名を登録する。
[0107]
 図10には、ストレージ装置の具備するiSCSIターゲット管理表23300の具体的な値の一例を示している。つまり、ストレージ装置上のiSCSIターゲット”HG1”は、”com.hitachi.sto1”でというiSCSIターゲット名を持ち、iSCSIイニシエータ名が”com.hitachi.sv1”であるホストコンピュータ上のポートからのアクセスを許可している。
[0108]
 図11は、ストレージ装置20000の具備するI/Oポート管理表23400の構成を示す図である。
[0109]
 I/Oポート管理表23400は、ストレージ装置の各ポートの識別子であるポートIDを登録するフィールド23410と、各ポートのネットワーク45000上での識別子であるMACアドレスを登録するためのフィールド23420と、を構成項目として含んでいる。
[0110]
 図11には、ストレージ装置の具備するI/Oポート管理表23400の具体的な値の一例を示している。つまり、ストレージ装置上のポート”PORT1”は、”TG1,TG2”というiSCSIターゲットIDで示されるiSCSIターゲットによって使用されている。
[0111]
 図12は、ストレージ装置20000の具備するRAIDグループ管理表23500の構成を示す図である。
[0112]
 RAIDグループ管理表23500は、フィールド23510,23520,23530を備えている。フィールド23510には、ストレージ装置内の各RAIDグループの識別子であるRAIDグループIDを登録する。フィールド23520には、RAIDグループのRAIDレベルを登録する。フィールド23530には、各RAIDグループの容量を登録する。
[0113]
 図12には、ストレージ装置の具備するRAIDグループ管理表23500の具体的な値の一例を示している。つまり、ストレージ装置上のRAIDグループ”RG1”は、RAIDレベルが”RAID1”であり、容量は”100GB”である。
[0114]
 図13A及び13Bは、管理サーバ30000が有するイベント管理表33100の構成例を示す図である。
[0115]
 イベント管理表33100は、フィールド33110,33120,33130,33140,33150,33160,33170を備える。フィールド33110には、イベントの識別子であるイベントIDを登録する。フィールド33120には、構成情報の変化といったイベントの発生した装置の識別子である装置IDを登録する。フィールド33130には、イベントの発生した装置内のコンポーネントの識別子を登録する。フィールド33140には、発生したイベントの種別を登録する。
[0116]
 フィールド33150には、発生したイベントの重要度を登録する。フィールド33160には、後述するイベント伝播モデル展開モジュール32500によってイベントが処理済みかどうかを登録する。フィールド33170には、イベントが発生した日時を登録する。
[0117]
 例えば、図13Aの第1行目(1つ目のエントリ)に着目すると、管理サーバ30000が、ストレージ装置”SYS1”の、”DISK1”で示されるディスクにおける状態異常を検知したことと、その状態異常のイベントの重要度は”1”であり、そのイベントIDは”EV1”であることとが、分かる。
[0118]
 図14A及び14Bは、管理サーバ30000が有するイベント伝播モデルリポジトリ33200内のイベント伝播モデルの構成例を示す図である。障害解析において根本原因を特定するために使用されるイベント伝播モデルは、ある障害の結果発生することが予想されるイベントの組み合わせと、その障害の根本原因とを、”IF-THEN”形式で記載している。
[0119]
 イベント伝播モデルは、図14A及び図14Bに挙げられたものに限られず、さらに多くのルールがあっても構わない。イベント伝播モデルリポジトリ33200には、複数のイベント伝播モデルを含んでも良い。
[0120]
 イベント伝播モデルは、イベント伝播モデルの識別子となるイベント伝播モデルIDを登録するフィールド33210と、”IF-THEN”形式で記載したイベント伝播モデルのIF部に相当する観測イベント種別を登録するフィールド33220と、”IF-THEN”形式で記載したイベント伝播モデルのTHEN部に相当する原因イベント種別を登録するためのフィールド33230と、を構成項目として含んでいる。結論部のステータスが正常になれば、条件部の問題も解決しているという関係にある。
[0121]
 図14Aには、管理サーバ30000が有するイベント伝播モデルの具体的な値の一例を示している。つまり、イベント伝播モデルIDが”Rule1”で示されるイベント伝播モデルにおいては、観測イベント種別として”ホストコンピュータ上の論理ボリュームの状態異常”と、”ストレージ装置上のボリュームの状態異常”とを検知した場合に、”ストレージ装置のボリュームの故障が原因である”と結論付ける。
[0122]
 図15A乃至15Eは、管理サーバ30000の具備するルールメモリ33300の構成を示す図である。以下で述べる因果律とは、”IF-THEN”形式で記載されたイベント伝播モデルに基づいて作成した、どのイベントを受信した際に何を根本原因であると結論づけるかという対応関係を表す情報である。
[0123]
 ルールメモリ33300は、以下の情報を含む。
[0124]
 * 管理サーバの装置情報取得モジュール32200が検知するイベントを特定するイベント特定情報(図中では管理オブジェクトの識別子(つまり装置IDとコンポーネントID)とイベントの種別)と、前記イベント特定情報に合致するイベントを実際に受信した日時を登録するフィールド33310。なお、前記イベント受信日時が未登録の場合、当該イベントは未受信であるものと、みなされる。
[0125]
 * 前記フィールド33310に記載のイベントが、因果律において否定条件であるか否かを登録するフィールド33320。
[0126]
 * 前記フィールド33310に記載のイベントを検知した際、イベント解析処理モジュール32400が障害の原因として結論付ける原因イベントを登録するための情報(図中では管理オブジェクトの識別子(つまり装置IDとコンポーネントID)とイベントの種別)と、前記原因イベントを含む因果律のIDと、前記因果律の展開の際使用したイベント伝播モデルのIDと、を登録するフィールド33330。
[0127]
 上記フィールド33310とフィールド33320の間、およびフィールド33320とフィールド33330の間には相互に接続関係があり、一方のフィールドと関連する他方のフィールドを呼び出すことができる。
[0128]
 図15Aには、管理サーバ30000の具備するルールメモリ33300の具体的な値の一例を示している。つまり、ストレージ装置”SYS1”のボリューム”VOL1”の状態異常と、ホスト”HOST1”の論理ボリューム(E:)の状態異常というイベントを装置情報取得モジュール32200が検知したとき、イベント解析処理モジュール32400は、ストレージ装置”SYS1”のボリューム”VOL1”の故障が根本原因であると結論付ける。
[0129]
 ルールメモリ33300は、行列構造であってもよい。因果律の追加および削除をより効率的に行うために、ルールメモリ33300は、動的に行列のサイズを変更可能なデータ構造でもよい。例えば、所定の行数または列数毎にサブ行列化して、それらをポインタまたはインデックスで関係付けることで、仮想的な行列を見せることができる。
[0130]
 図16A及び16Bは、管理サーバ30000が有するトポロジ生成方式リポジトリ33400内のトポロジ生成方式情報(省略してトポロジ生成方式と呼ぶことがある)の構成例を示す図である。
[0131]
 トポロジ生成方式は、管理サーバ30000が管理対象装置から取得した構成情報に基づき、監視対象となる複数の装置間での接続関係(トポロジ)を生成するための手段を定義した情報である。
[0132]
 トポロジ生成方式は、トポロジの識別子となるトポロジIDを登録するフィールド33410と、トポロジを生成する際の起点となる管理対象装置内のコンポーネント種別を登録するフィールド33420と、トポロジを生成する際の終点となるコンポーネント種別を登録するフィールド33430と、前記起点コンポーネント-終点コンポーネント間のトポロジ生成の際に経由する必要のあるコンポーネント種別を登録するフィールド33440と、前記起点コンポーネント-終点コンポーネント間のトポロジ生成方法を登録するフィールド33450と、を構成項目として含んでいる。
[0133]
 図16Aには、管理サーバ30000の具備するトポロジ生成方式の具体的な値の一例を示している。つまり、ストレージ装置内のボリュームを起点とし、ホストコンピュータ内の論理ボリュームを終点とするトポロジは、論理ボリュームのiSCSIイニシエータ名が、iSCSIターゲットの接続許可iSCSIイニシエータと等しく、かつボリューム内のiSCSIターゲットIDが、iSCSIターゲット内のIDと等しい、組み合わせを検索することにより取得可能である。
[0134]
 図17は、管理サーバ30000の具備する展開対象イベント伝播モデル管理表33600の構成例を示す図である。
[0135]
 展開対象イベント伝播モデル管理表33600は、障害イベントの発生した装置の種別を登録するフィールド33610と、前記イベントの発生した装置内のコンポーネントの種別を登録するフィールド33620と、前記イベントの種別を登録するフィールド33630と、イベントが後述するイベント解析処理モジュール32500によって処理される際に、どのイベント伝播モデルが展開対象となるかを登録するフィールド33640と、を構成項目として含んでいる。
[0136]
 図17には、管理サーバ30000の具備する展開対象イベント伝播モデル管理表の具体的な値の一例を示している。つまり、”ホストコンピュータにおける論理ボリュームの状態異常”というイベントが発生した場合、”Rule1”というIDで示されるイベント伝播モデルを再展開する必要がある。
[0137]
 図18は、管理サーバ30000の具備するイベント重要度管理表33700の構成例を示す図である。
[0138]
 イベント重要度管理表33700は、障害イベントの発生した装置の種別を登録するフィールド33710と、前記イベントの発生した装置内のコンポーネントの種別を登録するフィールド33720と、前記イベントの種別を登録するフィールド33730と、イベントの重要度を表すパラメータを登録するフィールド33740と、を構成項目として含んでいる。
[0139]
 図18には、管理サーバ30000の具備する展開対象イベント伝播モデル管理表の具体的な値の一例を示している。つまり、”ホストコンピュータにおける論理ボリュームの状態異常”というイベントが発生した場合、その重要度は”5”である。
[0140]
 管理サーバ30000が実行する処理方式を図19、図20及び図21に示す。
[0141]
 図19に、管理サーバ30000の装置情報取得モジュール32200が実施する装置情報取得処理のフローチャートを示す。
[0142]
 プログラム制御モジュール32100は、前回の装置情報取得処理から一定時間経過するたびに、装置情報取得モジュール32200に対し、装置情報取得処理を実行するよう指示する。なお、その実行指示は厳密に一定期間毎に出される必要は無く、繰り返し出されていればよい。装置から取得する情報には、装置の状態情報または性能情報が含まれるが、これらの情報をそれぞれ異なるタイミングで取得してもよい。
[0143]
 装置情報取得モジュール32200は、一つ以上の管理対象装置の各々に対し、以下の一連の処理を繰り返す(ステップ61010)。
[0144]
 装置情報取得モジュール32200は、管理対象装置に対して、装置の状態情報および性能情報を送信するよう指示する(ステップ61020)。
[0145]
 装置からの応答があれば(ステップ61030:YES)、装置情報取得モジュール32200は、装置から受信した情報を構成DB33500に格納する(ステップ61040)。なお、装置から指示に対する応答がなかった場合(ステップ61030:NO)、構成情報取得処理を終了する。
[0146]
 装置情報取得モジュール32200は、イベント重要度管理表33700を参照して、検知した状態異常および性能異常の重要度を決定する(ステップ61050)。装置情報取得モジュール32200は、検知した状態異常および性能異常をイベント化し、イベント管理表33100を更新する(ステップ61060)。
[0147]
 以上が、装置情報取得モジュール32200が実施する、構成管理情報を取得する処理である。
[0148]
 なお、状態情報に基づいたイベント化とは、例えば、コンポーネントの状態が正常以外の状態に変化したときに、変化先の状態に対応したイベント(情報)を生成すること、である。性能情報に基づいたイベント化とは、例えば、所定の評価基準(閾値等)に照らして正常ではないと判定される性能値となった場合に、イベント(情報)を生成すること、である。
[0149]
 図20に、管理サーバ30000のイベント解析処理モジュール32400が実施する、イベント確認処理のフローチャートを示す。管理サーバ30000の装置情報取得モジュール32200は、図19に示す装置情報取得処理を管理対象装置に対して実施した後、イベント解析処理モジュール32400に対して、イベント確認処理を行なうよう指示する。
[0150]
 装置情報取得モジュール32200は、全ての管理対象装置に対する装置情報の取得処理が完了した後でイベント確認処理の実行を指示してもよいし、一つの管理対象装置に対する装置情報の取得処理が完了次第、イベント確認処理の実行を指示してもよい。
[0151]
 イベント解析処理モジュール32400は、イベント管理表33100を参照し、イベント管理表33100に定義されたイベントに対し、イベントが全て”処理済”になるまで、ループ内の処理を繰り返す(ステップ62010)。
[0152]
 イベント解析処理モジュール32400は、未処理イベント、即ちイベント管理表33100に定義されたイベントの処理済みフラグが”No”であるイベントのうち、最も重要度の高いイベントを選択する(ステップ62020)。
[0153]
 最も重要度の高いイベントが複数存在する場合(ステップ62030:YES)、イベント解析処理モジュール32400は、ステップ62040の処理を行う。1つしか存在しない場合(ステップ62030:NO)、イベント解析処理モジュール32400は、ステップ62050の処理を行う。
[0154]
 イベント解析処理モジュール32400は、ステップ62020にて選択した最も優先度の高い複数イベントの中から、最も発生時刻の古いイベントを一つ選択する(ステップ62040)。
[0155]
 イベント解析処理モジュール32400は、選択したイベントの処理済みフラグを”Yes”に変更する(ステップ62050)。
[0156]
 イベント解析処理モジュール32400は、イベント伝播モデル展開モジュール32500に対し、当該イベントを指定して、図21に示すイベント伝播モデルオンデマンド展開処理を実行するよう指示する。
[0157]
 イベント解析処理モジュール32400は、ルールメモリ33300にイベント発生時刻を書き込み、関連する結論イベントの確信度を再計算する(ステップ62070)。
[0158]
 以上が、イベント解析処理モジュール32400が実施する、イベントを確認する処理である。
[0159]
 イベント管理表33100に複数のイベントが存在する場合、同時に複数のイベントについてイベント伝播モデルオンデマンド展開処理を実行するようイベント伝播モデル展開モジュールに指示してもよい。
[0160]
 図21に、管理サーバ30000のイベント伝播モデル展開モジュール32500が実施するイベント伝播モデルオンデマンド展開処理のフローチャートを示す。
[0161]
 イベント伝播モデル展開モジュール32500は、展開対象イベント伝播モデル管理表33600を参照し、処理起動時に指定されたイベント(つまり、未処理イベントの一つ)に対応したイベント伝播モデルの一覧を取得する(ステップ63010)。
[0162]
 イベント伝播モデル展開モジュール32500は、前記取得したイベント伝播モデルに対し、ステップ63030乃至63090の処理を繰り返す(ステップ63020)。展開対象イベント伝播モデル管理表33600にイベントが登録されていない場合は、以下の処理を行わずに、イベント伝播モデルオンデマンド展開処理を終了する。
[0163]
 イベント伝播モデル展開モジュール32500は、トポロジ生成方式リポジトリ33400を参照し、イベント伝播モデルに対応したトポロジ生成方式をトポロジ生成方式リポジトリ33400より取得する(ステップ63030)。該当するトポロジ生成方式がトポロジ生成方式リポジトリにない場合(ステップ63040:NO)、以下の処理を行わない。
[0164]
 該当するトポロジ生成方式がトポロジ生成方式リポジトリにあれば(ステップ63040:YES)、イベント伝播モデル展開モジュール32500は、取得したトポロジ生成方式を元に構成DB33500からトポロジを取得する(ステップ63050)。つまり、イベント伝播モデル展開モジュール32500は、イベントの発生したコンポーネントを含む組み合わせ(トポロジ)を取得する。
[0165]
 イベント伝播モデル展開モジュール32500は、取得したトポロジに基づいてイベント伝播モデルを展開し(ステップ63060)、その展開結果がルールメモリ33300に登録済みであるか確認する(ステップ63070)。展開結果がルールメモリ33300に登録済みの場合(ステップ63070:YES)、以下の処理は行わない。
[0166]
 展開結果がルールメモリ33300に存在しない場合(ステップ63070:NO)、イベント伝播モデル展開モジュール32500は、その展開結果をルールメモリ33300の列として追加する(ステップ63080)。
[0167]
 イベント伝播モデル展開モジュール32500は、展開結果の結論イベントと、処理起動時に指定されたイベント以外の条件イベントとについて、イベント伝播モデルオンデマンド展開処理を繰り返し実施する(ステップ63090)。
[0168]
 以上が、イベント伝播モデル展開モジュール32500が実施する、イベント伝播モデルをオンデマンドで展開する処理である。構成DB 33500以外の他の情報にトポロジを別途格納している場合は、前記他の情報を参照して上記処理を行っても良い。
[0169]
 以下に、図2乃至図18に示す情報内容に対応する計算機システムを例として、どのようにルールメモリを構築し、どのように確信度を算出するかを説明する。
[0170]
 プログラム制御モジュール32100は、管理者からの指示もしくはタイマーによるスケジュール設定に応じて、装置情報取得モジュール32200に対し、装置情報取得処理を実行するよう指示する。装置情報取得モジュール32200は、管理対象装置に順番にログインし、ログインした装置に対して装置の構成情報と状態情報と性能情報とを送信するよう指示する。
[0171]
 上記の処理が終了した後、装置情報取得モジュール32200は、取得した状態情報および性能情報を参照し、イベント管理表33100を更新する。ここでは、図13Aのイベント管理表33100の1行目から4行目に示す通り、”EV1”から”EV4”までのイベントを検知したケースを想定する。
[0172]
 イベント解析処理モジュール32400は、イベント管理表33100内の未処理イベント、即ちイベント管理表33100に定義されたイベントの処理済みフラグが”No”であるイベントのうち、最も重要度の高いイベントを選択する。ここでは”EV4”で示されるイベントの重要度が”5”と最も高いため、”EV4”を選択する。
[0173]
 イベント解析処理モジュール32400は、イベント伝播モデル展開モジュール32500に対し、当該イベント”EV4”を指定して、イベント伝播モデルオンデマンド展開処理を実行するよう指示する。
[0174]
 イベント伝播モデル展開モジュール32500は、展開対象イベント伝播モデル管理表33600を参照して、イベント”EV4”に対応したイベント伝播モデルの一覧を取得する。例えば、図17に示す展開対象イベント伝播モデル管理表33600を参照すると、”ホストコンピュータにおける論理ボリュームの状態異常”というイベントが発生した場合、”Rule1”を展開する必要があることが分かる。
[0175]
 図14Aに示すイベント伝播モデル”Rule1”は、観測イベントとして”ホストコンピュータの論理ボリュームの状態異常”と、”ストレージ装置のボリュームの状態異常”とが定義されている。図16Aに示すトポロジ生成方式を参照すると、ストレージ装置のボリュームを起点とし、ホストコンピュータの論理ボリュームを終点とするトポロジ生成方式”TP1”が定義されている。そこで、このトポロジ生成方式を利用して、トポロジを取得する。
[0176]
 展開モジュール32500は、図9に示すボリューム管理表23200(正確にはボリューム管理表23200に相当する、管理サーバ30000が格納した構成DB 3500内の項目)を参照し、ストレージ装置”SYS1”のボリューム”VOL1”に着目すると、そのターゲットIDは”TG1”となっている。
[0177]
 次に、展開モジュール32500は、図8に示すiSCSIターゲット管理表13300(正確にはiSCSIターゲット管理表13300に相当する、管理サーバ30000が格納した構成DB 33500内の項目)を参照し、iSCSIターゲットIDが”TG1”となっているものを探す。iSCSIターゲットIDが”TG1”であるエントリの接続許可iSCSIイニシエータ名を見ると”com.hitachi.sv1”となっている。
[0178]
 展開モジュール32500は、図8Aに示すiSCSIターゲット管理表13300(iSCSIターゲット管理表13300に相当する、管理サーバ30000が格納した構成DB 33500内の項目)を参照し、iSCSIイニシエータ名が”com.hitachi.sv1”となっている論理ボリュームを検索する。
[0179]
 展開モジュール32500は、検索されたホストコンピュータ”HOST1”の論理ボリューム(E:)が、LUN IDがストレージ装置”SYS1”のボリューム”VOL1”のLUN IDと等しいかどうかを確認する。
[0180]
 以上の結果、ホストコンピュータの論理ボリュームとストレージ装置のボリュームを含むトポロジの一つとして、ホストコンピュータ”HOST1”の論理ボリューム(E:)と、ストレージ装置”SYS1”のボリューム”VOL1”の組み合わせが有る。
[0181]
 そこで、観測イベントとして”ホストコンピュータHOST1の論理ボリューム(E:)の状態異常”と、”ストレージ装置SYS1のボリュームVOL1の状態異常”を検知した際、根本原因として”ストレージ装置SYS1のボリュームVOL1の故障”を結論付けるパターンが展開結果(つまり展開すべき因果律)となる。この展開結果がルールメモリに存在しない場合、展開結果をルールメモリに追加する。
[0182]
 以上の処理により、イベント伝播モデルRule1に関する因果律がルールメモリに追加され、図15Aの状態となる。
[0183]
 次にイベント解析処理モジュールは、ルールメモリにイベント発生時刻を書き込み、関連する結論イベントの確信度を再計算する。すなわち、ルールメモリにおいて”ホストコンピュータHOST1の論理ボリューム(E:)の状態異常”という観測イベントを発見し、EV4の発生時刻である”2010-01-01 15:00:30”を書き込む。次に、この観測イベントと関連する因果律を見つける。図15Aにおいては、ExRule1というIDで示される因果律が見つかる。この因果律に関連する観測イベントとして”ホストコンピュータHOST1の論理ボリューム(E:)の状態異常”と、”ストレージ装置SYS1のボリュームVOL1の状態異常”の2つがあり、前者のみイベントを検知済みであることから、因果律ExRule1の確信度は50%となる。この確信度を、根本原因である”ストレージ装置SYS1のボリュームVOL1の故障”の確信度として書き込む。
[0184]
 以上の処理により、イベントEV4の発生時刻がルールメモリに追加され、図15Bの状態となる。
[0185]
 次にイベント解析処理モジュール32400は、イベント管理表33100内の未処理イベントに対する処理を順次実行し、イベントEV2に対する処理に着手する。イベント解析処理モジュール32400は、イベント伝播モデル展開モジュール32500に対し、当該イベントを指定してイベント伝播モデルオンデマンド展開処理を実行するよう指示する。
[0186]
 イベント伝播モデル展開モジュール32500は、展開対象イベント伝播モデル管理表33600を参照して、イベントに対応したイベント伝播モデルの一覧を取得する。例えば、図17に示す展開対象イベント伝播モデル管理表33600を参照すると、”ストレージ装置におけるボリュームの状態異常”というイベントが発生した場合、”Rule1”を展開する必要があることが分かる。
[0187]
 図14Aに示すイベント伝播モデルRule1は、観測イベントとして”ホストコンピュータの論理ボリュームの状態異常”と、”ストレージ装置のボリュームの状態異常”が定義されている。図16Aに示すトポロジ生成方式を参照すると、ストレージ装置のI/Oポートを起点とし、ホストコンピュータの論理ボリュームを終点とするトポロジ生成方式TP1が定義されている。そこで、このトポロジ生成方式TP1を利用してトポロジを取得する。
[0188]
 その結果、ホストコンピュータの論理ボリュームとストレージ装置のボリュームを含むトポロジの一つとして、ホストコンピュータHOST1の論理ボリューム(E:)と、ストレージ装置SYS1のボリュームVOL1との組み合わせが存在する。
[0189]
 そこで、観測イベントとして”ホストコンピュータHOST1の論理ボリューム(E:)の状態異常”と、”ストレージ装置SYS1のボリュームVOL1の状態異常”とを検知した際、その根本原因を”ストレージ装置SYS1のボリュームVOL1の故障”であると結論付けるパターンが展開結果(つまり展開すべき因果律)となる。この展開結果はルールメモリ33300に既に存在するため、その展開結果をルールメモリ33300に追加せずにイベント伝播モデルオンデマンド展開処理を終了する。
[0190]
 イベント解析処理モジュール32400は、ルールメモリ33300にイベント発生時刻を書き込み、関連する結論イベントの確信度を再計算する。すなわち、ルールメモリ33300において”ストレージ装置SYS1のボリュームVOL1の状態異常”という観測イベントを発見し、そこにイベントEV2の発生時刻である”2010-01-01 15:00:10”を書き込む。
[0191]
 次に、イベント解析処理モジュール32400は、この観測イベントと関連する因果律を見つける。図15Bにおいては、”ExRule1”というIDで示される因果律が見つかる。この因果律に関連する観測イベントとして”ホストコンピュータHOST1の論理ボリューム(E:)の状態異常”と、”ストレージ装置SYS1のボリュームVOL1の状態異常”との2つが有る。それら2つイベントを検知済みであるから、因果律ExRule1の確信度は100%となる。イベント解析処理モジュール32400は、この確信度(100%)を、根本原因である”ストレージ装置SYS1のボリュームVOL1の故障”の確信度として書き込む。
[0192]
 以上の処理により、イベントEV2の発生時刻がルールメモリに追加され、図15Cの状態となる。
[0193]
 このように構成される本実施例の効果を説明する。図25は、計算機システムの物理構成例を示す図である。当該計算機システムは、ストレージ装置20000と、ホストコンピュータ10000と、管理サーバ30000と、WEBブラウザ起動サーバ35000と、IPスイッチ40000と、を有し、それらが、ネットワーク45000によって接続される構成となっている。
[0194]
 以下の説明では、ホストコンピュータ10000乃至10010は100台のホストコンピュータからなっており、その装置IDはHOST1乃至HOST100であるものとする。HOST1乃至HOST100は、それぞれストレージ装置20000に接続されているとする。ストレージ装置20000の装置IDはSYS1とする。また、HOST1乃至HOST100は、ストレージ装置SYS1内のRAIDグループRG1上にあるボリュームにアクセスしているものとする。
[0195]
 一方、ホストコンピュータ10020の装置IDはHOST101であるとする。HOST101はストレージ装置20010に接続されているものとする。ストレージ装置20010の装置IDはSYS2とする。HOST101は、ストレージ装置SYS2内のRAIDグループRG1上にあるボリュームにアクセスしているものとする。HOST101は、計算機システム内の他の装置に比べて業務上の重要度が高く、従ってHOST101で発生したイベントのイベント重要度は他の機器で発生するイベントに比べて高いものとする。
[0196]
 以下、図25に示す計算機システムにおいて、ストレージ装置SYS1内のRAIDグループRG1の障害の直後に、ストレージ装置SYS2内のRAIDグループRG1の障害が発生し、さらにHOST1乃至HOST100での論理ボリューム障害に引き続き、HOST101での論理ボリューム障害が発生した場合について述べる。
[0197]
 図26は、一連の障害が発生した直後のイベント管理表33100を示す。ストレージ装置SYS1内のRAIDグループRG1の障害によってイベントEV1が、HOST1乃至HOST100での論理ボリューム障害によりイベントEV2乃至EV101が、ストレージ装置SYS2内のRAIDグループRG1の障害によりイベントEV102が、HOST101での論理ボリューム障害によりイベントEV103が、それぞれ引き起こされている。
[0198]
 HOST101は、計算機システム内の他の装置に比べて業務上の重要度が高いため、イベントEV103のイベント重要度は”5”になっており、その他のイベントのイベント重要度は”1”になっている。
[0199]
 本実施例で述べた構成を採用しない場合を先に説明する。この場合、イベント重要度の高いイベントであっても、イベント管理表33100に先に格納されたイベント重要度の低いイベントの方が先に処理される。イベント重要度の高いイベントについての解析は、後回しにされる。
[0200]
 つまり、イベント重要度の高いイベントEV103に対応する、イベント伝播モデルオンデマンド展開処理および確信度計算処理は、イベント重要度の低いイベントEV1乃至EV102に対応するイベント伝播モデルオンデマンド展開処理および確信度計算処理の後で、実施される。
[0201]
 1イベント当たりのイベント伝播モデルオンデマンド展開処理および確信度計算処理に要する時間が一定時間Tであると仮定すると、イベントEV103に対応する解析結果が出力されるまでには「T×103」の時間を要する。従って、イベント重要度の高いイベントであるにもかかわらず、そのイベントの解析結果が管理者に通知されるまでに長い時間を要する。
[0202]
 これに対し、本実施例では、イベント重要度の高いイベントから先に解析するため、例えば業務上の影響の大きいイベントを直ちに解析してその結果を管理者に通知することができる。
[0203]
 すなわち、本実施例では、イベント重要度の高いイベントEV103に対応するイベント伝播モデルオンデマンド展開処理および確信度計算処理を、全てのイベントのうち最初に実施する。従って、本実施例では、イベントEV103に対応する解析結果が出力されるまでの所要時間を「T×1」と大幅に短縮することができる。
[0204]
 本実施例では、イベント発生前に全ての因果律を事前に作成するのではなく、イベント発生時に必要な範囲内で因果律を作成するため、ルールメモリ33300のサイズを小さくすることができる。しかし、管理対象装置の数などによっても相違するが、比較的大規模な計算機システムでは、イベント伝播モデルをオンデマンドで展開する処理に、予想以上の時間を必要とする。この新たな知見に基づいて、本実施例では、イベント管理表33100に格納された順番でイベントを処理するのではなく、イベント重要度の高いイベントから先に処理する。これにより、本実施例では、早急に警告すべきイベントから先に解析して、その解析結果を管理者に通知することができる。従って、信頼性および使い勝手を向上できる。
実施例 2
[0205]
 実施例2を説明する。本実施例を含む以下の各実施例は実施例1の変形例に該当するため、実施例1との相違を中心に説明する。
[0206]
 実施例2では、管理プログラム32000のイベント伝播モデル展開モジュール32500が実施する、別なイベント伝播モデルオンデマンド展開処理について説明する。
[0207]
 実施例1においては、複数のイベントについてイベント伝播モデルオンデマンド展開処理を実行する場合、イベントの重要度の高い順に展開するようイベント伝播モデル展開モジュール32500に指示する。
[0208]
 ところで、情報処理システム(計算機システム)においては、1つの障害が多数の装置に波及するため、同時に多数の異常イベントが管理プログラム32000によって検知される。それらのイベントが全て同じ重要度であるとは限らない。しかし、同じ根本原因を持つ異常イベントについて、イベント重要度の順にイベント伝播モデルオンデマンド展開処理を並列に処理したとすると、重要度の低いイベントの処理開始が遅れるため、確信度に反映されるまでの時間が長くなる。
[0209]
 例えば、3つのイベントのうち1つのイベントのイベント重要度が低い場合、そのイベント重要度の低いイベントについてイベント伝播モデルの展開処理が完了するまでの間、根本原因の確信度は、2/3に止まる。イベント重要度の低いイベントについての展開処理が完了すると、確信度は3/3に上昇する。
[0210]
 上記の課題を解決するため、実施例2では、管理サーバ30000におけるイベント解析処理を変更する。変更後の管理サーバ30000が実行する処理を、図22A及び22Bに示す。なお、管理サーバ30000が実行するその他の処理は、実施例1と変わらないため、説明を省略する。
[0211]
 図22A及び22Bに、実施例2における、管理サーバ30000のイベント解析処理モジュール32400が実施する、イベント確認処理のフローチャートを示す。なお、管理サーバ30000の装置情報取得モジュール32200は、図19に示す装置情報取得処理を管理対象装置に対して実施した後、イベント解析処理モジュール32400に対し、イベント確認処理を行なうよう指示する。
[0212]
 イベント解析処理モジュール32400は、イベント管理表33100を参照し、イベント管理表33100に定義されたイベントに対し、イベントが全て「処理済」になるまで、ループ内の処理を繰り返す(ステップ64010)。
[0213]
 イベント解析処理モジュール32400は、未処理イベント、即ちイベント管理表33100に定義されたイベントの処理済みフラグが”No”であるイベントのうち、最も重要度の高いイベントを選択する(ステップ64020)。前記処理によって選択されたイベントが複数存在する場合(ステップ64030:YES)、イベント解析処理モジュール32400は、ステップ64040の処理を行う。1つしか存在しない場合(ステップ64030:NO)、ステップ64050の処理を行う。
[0214]
 イベント解析処理モジュール32400は、ステップ62020にて選択したイベントのうち、最も発生時刻の古いイベントを1つ選択する(ステップ64040)。
[0215]
 イベント解析処理モジュール32400は、選択したイベントの処理済みフラグを”Yes”に変更する(ステップ64050)。
[0216]
 イベント解析処理モジュール32400は、イベント伝播モデル展開モジュール32500に対し、当該イベントを指定して図21に示すイベント伝播モデルオンデマンド展開処理を実行するよう指示する(ステップ64060)。
[0217]
 イベント解析処理モジュール32400は、ルールメモリ33300にイベント発生時刻を書き込み、関連する結論イベントを全て取得する(ステップ64070)。
[0218]
 図22Bに移る。イベント解析処理モジュール32400は、関連する結論イベント毎に、ループ内の処理を繰り返す(ステップ64080)。
[0219]
 イベント解析処理モジュール32400は、結論イベントと関連する観測イベントのうち、未受信のイベントを取得する(ステップ64090)。イベント解析処理モジュール32400は、取得した未受信の観測イベント毎に、ループ内の処理を繰り返す(ステップ64100)。
[0220]
 イベント解析処理モジュール32400は、イベント管理表33100を参照し、管理オブジェクトの種別とイベントの種別が同一で、かつ未処理のイベントが無いかどうかを確認する(ステップ64110)。該当するイベントが存在する場合(ステップ64120:YES)、イベント解析処理モジュール32400は、ルールメモリ33300上の当該観測イベントにイベント発生時刻を書き込む(ステップ64130)。
[0221]
 以上の処理を、ステップ64090で取得した未受信の観測イベントに対して実施した後、イベント解析処理モジュール32400は、前記結論イベントの確信度を再計算する(ステップ64140)。
[0222]
 以上が、実施例2のイベント解析処理モジュール32400が実施するイベント確認処理である。
[0223]
 イベント管理表33100に複数のイベントが存在する場合、同時に複数のイベントについてイベント伝播モデルオンデマンド展開処理を実行するよう、イベント伝播モデル展開モジュール32500に指示してもよい。
[0224]
 以下に、図6乃至図18の情報の内容に対応する計算機システムを例として、実施例2の処理がどのようにルールメモリ33300を構築して確信度を算出するかを示す。
[0225]
 プログラム制御モジュール32100は、管理者からの指示もしくはタイマーによるスケジュール設定によって、装置情報取得モジュール32200に対し、装置情報取得処理を実行するよう指示する。装置情報取得モジュール32200は、管理対象装置に順番にログインし、ログインした装置に対して、装置の構成情報と状態情報および性能情報を送信するよう指示する。
[0226]
 上記の処理が終了した後、装置情報取得モジュール32200は、取得した状態情報および性能情報を参照し、イベント管理表33100を更新する。ここでは、図13Aのイベント管理表33100の1行目から4行目に示す通り、イベントEV1からイベントEV4までのイベントを検知したケースを想定する。
[0227]
 イベント解析処理モジュール32400は、イベント管理表33100内の未処理イベント、即ちイベント管理表33100に定義されたイベントの処理済みフラグが”No”であるイベントのうち、最も重要度の高いイベントを選択する。ここでは”EV4”で示されるイベントの重要度が”5”と最も高いため、イベント解析処理モジュール32400は、イベントEV4を選択する。
[0228]
 イベント解析処理モジュール32400は、イベント伝播モデル展開モジュール32500に対し、当該イベントを指定してイベント伝播モデルオンデマンド展開処理を実行するよう指示する。
[0229]
 イベント伝播モデル展開モジュール32500は、展開対象イベント伝播モデル管理表33600を参照して、イベントに対応したイベント伝播モデルの一覧を取得する。例えば、図17に示す展開対象イベント伝播モデル管理表33600を参照すると、”ホストコンピュータにおける論理ボリュームの状態異常”というイベントが発生した場合、イベント伝播モデル”Rule1”を展開する必要があることが分かる。
[0230]
 図14Aに示すイベント伝播モデルRule1は、観測イベントとして”ホストコンピュータの論理ボリュームの状態異常”と、”ストレージ装置のボリュームの状態異常”とが定義されている。図16Aに示すトポロジ生成方式を参照すると、ストレージ装置のボリュームを起点とし、ホストコンピュータの論理ボリュームを終点とするトポロジ生成方式TP1が定義されている。そこで、このトポロジ生成方式TP1を利用して、トポロジを取得する。
[0231]
 その結果、ホストコンピュータの論理ボリュームとストレージ装置のボリュームを含むトポロジの一つとして、ホストコンピュータHOST1の論理ボリューム(E:)と、ストレージ装置SYS1のボリュームVOL1の組み合わせが存在する。
[0232]
 そこで、観測イベントとして”ホストコンピュータHOST1の論理ボリューム(E:)の状態異常”と、”ストレージ装置SYS1のボリュームVOL1の状態異常”とを検知した際、その根本原因を”ストレージ装置SYS1のボリュームVOL1の故障”であると結論付けるパターンが、展開結果(つまり展開すべき因果律)となる。この展開結果がルールメモリ33300に存在しない場合、その展開結果はルールメモリ33300に追加される。
[0233]
 以上の処理により、イベント伝播モデルRule1に関する因果律がルールメモリ33300に追加され、図15Aの状態となる。
[0234]
 イベント解析処理モジュール32400は、ルールメモリ33300にイベント発生時刻を書き込む。すなわち、イベント解析処理モジュール32400は、ルールメモリ33300において”ホストコンピュータHOST1の論理ボリューム(E:)の状態異常”という観測イベントを発見し、イベントEV4の発生時刻である”2010-01-01 15:00:30”を書き込む。その結果、ルールメモリ33300は、図15Bの状態となる。
[0235]
 イベント解析処理モジュール32400は、展開した因果律ExRule1の観測イベント毎に、ループ内の処理を繰り返す。
[0236]
 イベント解析処理モジュール32400は、まず観測イベントが未受信であるかどうかを確認する。観測イベントが未受信である場合、イベント管理表33100を参照し、管理オブジェクト種別とイベント種別が同一であり、かつ未処理のイベントが無いかどうかを確認する。
[0237]
 該当するイベントが存在する場合、イベント解析処理モジュール32400は、ルールメモリ33300にイベント発生時刻を書き込む。
[0238]
 因果律ExRule1の”ストレージ装置SYS1のボリュームVOL1の状態異常”という観測イベントは未受信であるが、イベント管理表33100を参照すると”ストレージ装置SYS1のボリュームVOL1の状態異常”というイベントEV2が存在している。従って、イベント解析処理モジュール32400は、EV2の発生時刻である”2010-01-01 15:00:10”をルールメモリ33300の当該観測イベントに書き込む。
[0239]
 イベント解析処理モジュール32400は、前記因果律の確信度を再計算する。すなわち、因果律ExRule1に関連する観測イベントとして”ホストコンピュータHOST1の論理ボリューム(E:)の状態異常”と、”ストレージ装置SYS1のボリュームVOL1の状態異常”との2つがあり、それら2つのイベントを検知済みであることから、因果律ExRule1の確信度は100%となる。イベント解析処理モジュール32400は、この確信度(100%)を、根本原因である”ストレージ装置SYS1のボリュームVOL1の故障”の確信度として書き込む。
[0240]
 以上の処理により、イベントEV2の発生時刻がルールメモリに追加され、図15Cの状態となる。
[0241]
 以上が、実施例2のイベント解析処理モジュール32400が実施するイベント解析処理である。
[0242]
 このように構成される実施例2も実施例1と同様の効果を奏する。さらに、実施例2では、管理プログラム32000は、イベント伝播モデルを展開した際に、展開した因果律情報に含まれる観測イベントのうち、未受信のものをイベントリストから検索して処理し、確信度に反映する。
[0243]
 その結果、実施例2では、大規模システムを対象としてオンデマンド展開方式を採用する場合において、同じ障害原因を持つ多数の障害を同時に受信したとしても、展開が完了した因果律に対する確信度を迅速かつ適切に評価することができる。
実施例 3
[0244]
 実施例3では、管理プログラム32000のイベント伝播モデル展開モジュール32500が実施する、イベント伝播モデル展開処理について説明する。
[0245]
 実施例1では、イベント重要度に応じて、どのイベントから順にイベント伝播モデルオンデマンド展開処理を実行するかを判断していた。しかし、イベント重要度が同じイベントが複数ある場合、展開に時間の掛からないイベントから順に展開処理を実行する方が望ましい。
[0246]
 先述したとおり、イベントには有効期間が設定されており、発生から一定時間が経過したイベントは、解析対象から除外される。従って、イベント発生直後ほど、より多くのイベントの展開処理を行えば、イベントの解析に必要なイベント伝播モデルの展開が完了する前に、そのイベントが解析対象から外れてしまうという事態の発生を抑止できる。しかし、実施例1では、各イベントについての、イベント伝播モデルの展開所要時間を見積もることができない。
[0247]
 このような課題を解決するため、実施例3では、管理サーバ30000におけるイベント解析処理を変更する。実施例3の管理サーバ30000が具備する関連機器数管理表33800を図23に、管理サーバ30000が実行する処理フローを図24に、それぞれ示す。なお、管理サーバ30000のその他の情報及びフローは、実施例1または実施例2と同じである。
[0248]
 図23は、管理サーバ30000の具備する関連装置数管理表33800の構成例を示す図である。
[0249]
 関連装置数管理表33800は、管理サーバ30000が管理する装置の種別を登録するフィールド33810と、前記装置の識別子となる装置IDを登録するフィールド33820と、前記装置と接続関係にある装置の種別を登録するフィールド33830と、前記装置と接続関係にある装置の数を登録するフィールド33840と、を構成項目として含んでいる。
[0250]
 図23には、関連装置数管理表33800の具体的な値の一例を示している。つまり、装置IDが”HOST1”で示されるホストコンピュータは、1つのストレージ装置と接続関係にあることを示している。
[0251]
 本実施例において管理サーバ30000が実行するイベント伝播モデルオンデマンド展開処理の処理方式を図24に示す。なお、管理サーバ30000が実行するその他の処理は、実施例1と変わらない。
[0252]
 図24に、イベント解析処理モジュール32400が実施するイベント解析処理のフローチャートを示す。装置情報取得モジュール32200は、図25に示す装置情報取得処理を管理対象装置に対して実施した後、イベント解析処理モジュール32400に対し、イベント確認処理を行なうよう指示する。装置情報取得モジュール32200がイベント確認処理を行なうよう指示するタイミングは、全ての管理対象装置に対する処理が完了した後でも構わないし、一つの管理対象装置に対する処理が完了次第に随時指示しても構わない。
[0253]
 イベント解析処理モジュール32400は、イベント管理表33100を参照し、イベント管理表33100に定義されたイベントに対し、イベントが全て「処理済」になるまで、ループ内の処理を繰り返す(ステップ65010)。
[0254]
 イベント解析処理モジュール32400は、未処理イベント、即ちイベント管理表33100に定義されたイベントの処理済みフラグが”No”であるイベントのうち、最も重要度の高いイベントを選択する(ステップ65020)。前記処理によって選択されたイベントが複数存在する場合(ステップ65030:YES)、ステップ65040の処理を行う。1つしか存在しない場合(ステップ65030:NO)、ステップ65070の処理を行う。
[0255]
 イベント解析処理モジュール32400は、展開対象イベント伝播モデル管理表33600を参照し、前記イベントに対応したイベント伝播モデルの一覧を取得する(ステップ65040)。イベント解析処理モジュール32400は、関連装置数管理表33800を参照し、該当するイベント伝播モデルの展開時に構成DB 33500から情報を取得する必要のある関連装置の数を算出する(ステップ65050)。ステップ65040において、イベント伝播モデルが複数取得された場合は、各々のイベント伝播モデルについて関連装置の数を算出し、合算する。取得の結果、イベント解析処理モジュール32400は、最も関連装置数の少ないイベントを1つ選択する(ステップ65060)。
[0256]
 イベント解析処理モジュール32400は、選択したイベントの処理済みフラグを”Yes”に変更する(ステップ65070)。
[0257]
 イベント解析処理モジュール32400は、イベント伝播モデル展開モジュール32500に対し、当該イベントを指定して図21に示すイベント伝播モデルオンデマンド展開処理を実行するよう指示する(ステップ65080)。
[0258]
 最後に、イベント解析処理モジュール32400は、ルールメモリ33300にイベント発生時刻を書き込み、さらに、関連する結論イベントの確信度を再計算する(ステップ65090)。
[0259]
 以上がイベント解析処理モジュール32400によるイベント解析処理である。なお、イベント管理表33100に複数のイベントが存在する場合、同時に複数のイベントについてイベント伝播モデルオンデマンド展開処理を実行するようイベント伝播モデル展開モジュール32500に指示してもよい。
[0260]
 以下に、図2乃至図18に示す情報内容に対応する計算機システムを例として、実施例3の処理がどのようにルールメモリを構築して確信度を算出するかを示す。
[0261]
 プログラム制御モジュール32100は、管理者からの指示もしくはタイマーによるスケジュール設定によって、装置情報取得モジュール32200に対し、装置情報取得処理を実行するよう指示する。装置情報取得モジュール32200は、管理対象装置に順にログインし、ログインした装置に対して、装置の構成情報と状態情報と性能情報とを送信するよう指示する。
[0262]
 上記の処理が終了した後、装置情報取得モジュール32200は、取得した状態情報および性能情報を参照し、イベント管理表33100を更新する。ここでは、図13Bのイベント管理表33100の1行目から2行目に示す通り、イベントEV1からイベントEV2までのイベントを検知したケースを想定する。
[0263]
 イベント解析処理モジュール32400は、イベント管理表33100内の未処理イベント、即ちイベント管理表33100に定義されたイベントの処理済みフラグが”No”であるイベントのうち、最も重要度の高いイベントを選択する。ここでは”EV1”と”EV2”とで示される2つのイベントの重要度が”5”である。
[0264]
 そこで、イベント解析処理モジュール32400は、展開対象イベント伝播モデル管理表を参照し、前記イベントに対応したイベント伝播モデルの一覧を取得する。例えば、図17に示す展開対象イベント伝播モデル管理表33600を参照すると、”ホストコンピュータにおける論理ボリュームの状態異常”というイベントが発生した場合、イベント伝播モデルRule2を展開する必要があることが分かる。
[0265]
 イベント解析処理モジュール32400は、関連装置数管理表33800を参照し、イベント伝播モデルRule2の展開時に構成DB 33500から情報を取得する必要のある関連装置の数を算出する。
[0266]
 イベント伝播モデルRule2は、ホストコンピュータとストレージ装置との組み合わせからなるルールであるため、双方の装置間の関連装置数を確認する。即ち、イベントEV1に定義されたホストコンピュータHOST1は1つのストレージ装置と、イベントEV2に定義されたストレージ装置SYS1は3つのホストコンピュータと、それぞれ関連していることが分かる。取得の結果、イベント解析処理モジュール32400は、最も関連装置数の少ないイベントEV1を選択する。
[0267]
 イベント伝播モデル展開モジュール32500は、展開対象イベント伝播モデル管理表33600から、イベントEV1に対応したイベント伝播モデルの一覧を取得する。例えば、図17に示す展開対象イベント伝播モデル管理表33600を参照すると、”ホストコンピュータにおける論理ボリュームの状態異常”というイベントが発生した場合、イベント伝播モデルRule2を展開する必要があることが分かる。
[0268]
 図14Bに示すイベント伝播モデルRule2には、観測イベントとして”ホストコンピュータの論理ボリュームの状態異常”と、”ストレージ装置のRAIDグループの状態異常”とが定義されている。図16Bに示すトポロジ生成方式を参照すると、ストレージ装置のRAIDグループを起点とし、ホストコンピュータの論理ボリュームを終点とするトポロジ生成方式TP2が定義されている。そこで、このトポロジ生成方式TP2を利用してトポロジを取得する。
[0269]
 その結果、ホストコンピュータの論理ボリュームとストレージ装置のRAIDグループを含むトポロジの一つとして、ホストコンピュータHOST1の論理ボリューム(E:)と、ストレージ装置SYS1のRAIDグループRG1の組み合わせが存在する。
[0270]
 従って、観測イベントとして”ホストコンピュータHOST1の論理ボリューム(E:)の状態異常”と、”ストレージ装置SYS1のRAIDグループRG1の状態異常”とを検知した場合は、その根本原因として”ストレージ装置SYS1のRAIDグループRG1の故障”であると結論付けるパターンが、展開結果(つまり、展開すべき因果律)となる。この展開結果がルールメモリ33300に存在しない場合、展開結果をルールメモリ33300に追加する。
[0271]
 以上の処理により、イベント伝播モデルRule2に関する因果律がルールメモリ33300に追加され、図15Dの状態となる。
[0272]
 イベント解析処理モジュール32400は、ルールメモリ33300にイベント発生時刻を書き込み、関連する結論イベントの確信度を再計算する。
[0273]
 イベント解析処理モジュール32400は、イベント管理表33100内の未処理イベントに対する処理を順次実行し、イベントEV2についての処理に着手する。イベント解析処理モジュール32400は、イベント伝播モデル展開モジュール32500に対し、当該イベントを指定して、イベント伝播モデルオンデマンド展開処理を実行するよう指示する。
[0274]
 イベント伝播モデル展開モジュール32500は、展開対象イベント伝播モデル管理表33600を参照して、イベントに対応したイベント伝播モデルの一覧を取得する。例えば、図17に示す展開対象イベント伝播モデル管理表33600を参照すると、”ストレージ装置におけるRAIDグループの状態異常”というイベントが発生した場合、イベント伝播モデルRule2を展開する必要があることが分かる。
[0275]
 図14Bに示すイベント伝播モデルRule2は、観測イベントとして”ホストコンピュータの論理ボリュームの状態異常”と、”ストレージ装置のボリュームの状態異常”とが定義されている。図16Bに示すトポロジ生成方式を参照すると、ストレージ装置のRAIDグループを起点とし、ホストコンピュータの論理ボリュームを終点とするトポロジ生成方式TP2が定義されている。そこで、このトポロジ生成方式TP2を利用してトポロジを取得する。
[0276]
 その結果、ホストコンピュータの論理ボリュームとストレージ装置のボリュームを含むトポロジの一つとして、ホストコンピュータHOST1の論理ボリューム(E:)と、ホストコンピュータHOST2の論理ボリューム(E:)と、ホストコンピュータHOST3の論理ボリューム(E:)と、ストレージ装置SYS1のRAIDグループRG1との組み合わせが存在する。
[0277]
 そこで、観測イベントとして”ホストコンピュータHOST1の論理ボリューム(E:)の状態異常”と、”ホストコンピュータHOST2の論理ボリューム(E:)の状態異常”と、”ホストコンピュータHOST3の論理ボリューム(E:)の状態異常”と、”ストレージ装置SYS1のRAIDグループRG1の状態異常”とを検知した際、その根本原因を”ストレージ装置SYS1のRAIDグループRG1の故障”であると結論付けるパターンが、展開結果(つまり展開すべき因果律)となる。この展開結果は、部分的にしかルールメモリ33300に存在しないため、その展開結果はルールメモリ33300に追加される。
[0278]
 イベント解析処理モジュール32400は、ルールメモリ33300にイベント発生時刻を書き込み、関連する結論イベントの確信度を再計算する。
[0279]
 以上の処理により、イベント伝播モデルRule2に関する因果律がルールメモリ33300に追加され、図15Eの状態となる。
[0280]
 このように構成される本実施例も実施例1と同様の効果を奏する。さらに、本実施例によれば、各イベントのイベント伝播モデルの展開に要する時間を見積もるため、所要時間の短いイベントから先に展開することができる。従って、本実施例では、イベント解析に必要なイベント伝播モデルの展開が完了する前に、イベントが解析対象から外れてしまうという事態の発生を抑止できる。これにより、信頼性および使い勝手が向上する。
[0281]
 なお、本実施形態に記載された構成は、以下のように、計算機システムの管理方法として表現することもできる。
「表現1.
 複数の管理対象装置を含む計算機システムを管理計算機により管理するための方法であって、
 前記管理計算機は、所定の情報を記憶する記憶資源を利用することができ、
  前記所定の情報には、
   (1)前記複数の管理対象装置又は前記複数の管理対象装置が含む複数のコンポーネントである、複数の管理オブジェクトに関して、前記複数の管理オブジェクト同士の関係を示すトポロジと、
   (2)第1種別の管理オブジェクトで発生する所定種別の第1イベントが原因となって、第2種別の管理オブジェクトで他の所定種別の第2イベントが発生する、ことを示すイベント伝播モデルと、
   (3)一つ以上の因果律を含む因果律情報と、
  が含まれており、
  前記因果律は、第1種別を有する第1管理オブジェクトで発生する前記所定種別の第1イベントが原因となって、第2種別を有する第2管理オブジェクトで前記他の所定種別の第2イベントが発生すること、を示しており、
 前記管理計算機は、
 (A)所定の管理オブジェクトで発生した問題に関するイベントを検知し、
 (B)前記検知イベントが複数存在する場合に、それら複数のイベントのイベント重要度を判断し、
 (C)(B)で判断したイベント重要度の高いイベントから順に、前記トポロジと前記イベント伝播モデルとに基づいて所定の因果律を前記因果律情報に生成するためのオンデマンド展開を実行し、
 (D)前記所定の因果律に対し、前記検知イベントが発生済みであることを記録し、
 (E)前記所定の因果律を用いて、前記検知イベントを解析する、
計算機システムの管理方法。」

符号の説明

[0282]
 10000~10020:ホストコンピュータ、20000~20010:ストレージ装置、30000:管理サーバ、32000:管理プログラム、33000:記憶資源、40000~40030:スイッチ

請求の範囲

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

図面

[ 図 1]

[ 図 2]

[ 図 3]

[ 図 4]

[ 図 5]

[ 図 6]

[ 図 7]

[ 図 8A]

[ 図 8B]

[ 図 8C]

[ 図 9]

[ 図 10]

[ 図 11]

[ 図 12]

[ 図 13A]

[ 図 13B]

[ 図 14A]

[ 図 14B]

[ 図 15A]

[ 図 15B]

[ 図 15C]

[ 図 15D]

[ 図 15E]

[ 図 16A]

[ 図 16B]

[ 図 17]

[ 図 18]

[ 図 19]

[ 図 20]

[ 図 21]

[ 図 22A]

[ 図 22B]

[ 図 23]

[ 図 24]

[ 図 25]

[ 図 26]