以下、図面を参照して、実施例を説明する。なお、以後の説明では「aaaテーブル」、「aaaリスト」、「aaaDB」、「aaaキュー」、「aaa行列」等の表現にて実施例の情報を説明するが、これら情報は必ずしもテーブル、リスト、DB、キュー、行列、等のデータ構造以外で表現されていてもよい。そのため、データ構造に依存しないことを示すために「aaaテーブル」、「aaaリスト」、「aaaDB」、「aaaキュー」、「aaaリポジトリ」、「aaa行列」等について「aaa情報」と呼ぶことがある。さらに、各情報の内容を説明する際に、「識別情報」、「識別子」、「名」、「名前」、「ID」という表現を用いるが、これらについてはお互いに置換が可能である。さらに、データ内容を示すために「情報」という表現を用いているが、他の表現形式であってもよい。なお、実施例の説明において「リポジトリ」という用語を用いるが、「情報」と同じ意味である。
以後の説明では「プログラム」を主語として説明を行う場合があるが、プログラムはプロセッサによって実行されることで定められた処理をメモリ及び通信ポート(通信制御装置)を用いながら行うため、プロセッサを主語とした説明としてもよい。また、プログラムを主語として開示された処理は管理サーバ又はストレージシステム等の計算機、情報処理装置が行う処理としてもよい。また、プログラムの一部または全ては専用ハードウェアによって実現されてもよい。また、各種プログラムはプログラム配布サーバ(各種プログラムのインストールイメージを記憶する記憶資源と、配布処理を実施するCPUとから構成)や記憶メディアによって各計算機にインストールされてもよい。
図27は実施例1の概要を示した図である。管理サーバ30000は、複数の管理対象装置10000を管理する計算機である。管理対象装置の種別としては例えば、ホストコンピュータ、IPスイッチやルータ等のネットワーク装置、あるいはNASやストレージ装置等がある。なお、管理対象装置が含むデバイス等の論理的又は物理的な構成物をコンポーネントと呼ぶ。コンポーネントの例としてはポート、プロセッサ、記憶資源、記憶デバイス、プログラム、仮想マシン、ストレージ装置内部で定義される論理ボリューム、RAIDグループ等がある。なお、管理対象装置とコンポーネントを区別せずに扱う場合は管理オブジェクトと呼ぶ。
管理サーバ30000は、これら管理対象装置の構成情報、障害又は性能を示す情報等の装置情報を取得し、取得した装置情報に基づいて、管理対象装置の管理情報(例えば構成情報、障害発生の有無、性能値等)を表示する。
なお、いくつかの管理対象装置は何かしらのネットワークサービス(例えば、iSCSIやファイル共有サービス、DNS、その他Webサービス)のサーバであり、又他のいくつかの管理対象装置はクライアントとしてこれらサーバが提供するネットワークサービスを利用する。この場合、サーバである管理対象装置(サーバ)でサービス提供に関係する問題(例えば管理オブジェクトの障害や性能障害等)が発生すると当該サービスを利用しているクライアント管理対象装置(クライアント装置と呼ぶことがある)でも管理オブジェクトに関する問題が発生する。
なお、以後の説明では管理オブジェクトで発生した問題を管理サーバで示す情報をイベントと呼ぶ。また、「イベントの検知」とは「問題の発生を検知し、イベント情報を作成すること」を意味する。なお、「イベントの発生」は「問題の発生」と同じ意味である。
管理サーバ30000は、ある管理対象装置で発生した問題の原因が別な管理対象装置で発生した問題であることを解析し、表示することができる。そのために管理サーバ30000は以下の情報を格納し、解析に用いる。
* 構成情報。管理対象装置の構成(インベントリとも呼ばれる)を示す情報を格納する。なお、構成情報には管理対象装置が含むコンポーネントや、コンポーネント同士の対応関係といった管理オブジェクト間の対応関係が含まれる。また、構成情報には、クライアント装置に関して、ネットワークサービスを受けるためのサーバ装置(またはサーバ装置のコンポーネント)の識別情報が含まれる。例えば、後述するiSCSIプロトコルによるボリューム提供がネットワークサービスであれば、識別情報としてiSCSIターゲット名とLUNを指定し、ストレージ装置が提供するボリュームにアクセスする。その他、Webであれば、識別情報としてWebサーバの名前を含むURLを指定し、Webページにアクセスする。
なお、構成情報にはサーバ装置に関して、アクセス元となるクライアント装置に関する識別情報を含む場合もある。このような管理対象装置内又は複数の管理対象装置に跨る複数の管理オブジェクト間の関係をトポロジと呼ぶ。
* 一つ以上のイベント伝播モデルの情報(以後、単にイベント伝播モデルと呼ぶ)。本情報は、一つ以上の観測種別ペアと原因種別ペアが含まれる。より詳細としては以下である。
原因種別ペア:管理オブジェクトの種別(管理オブジェクト原因種別と呼ぶことがある)と、イベントの種別(イベント原因種別)のペアである。イベント原因種別は、管理オブジェクト原因種別で定められる種別の管理オブジェクトで発生する可能性のあるイベントの種別である。
観測種別ペア:管理オブジェクトの種別(管理オブジェクト観測種別と呼ぶことがある)と、イベントの種別(イベント観測種別)のペアである。イベント観測種別は、管理オブジェクト観測種別で定められる種別の管理オブジェクトで発生する可能性のあるイベントの種別である。観測種別ペアは、原因種別ペアで定められるイベントが発生した場合に、合わせて発生するイベントの種別を示す。
なお、あるイベント伝播モデルに含まれる観測種別ペアのイベントを全て検知した場合に、対応する原因種別ペアのイベント発生が原因であるほうがより好ましいが、必須ではない。
管理サーバ30000による解析処理は、より具体的にはイベント伝播モデルとトポロジに基づいて因果律を因果律情報に作成し、その上でイベントの解析を行う。なお、因果律とは、第1の管理オブジェクトで第1のイベントが発生した場合は、第2の管理オブジェクトで発生した第2のイベントが発生することを示す情報である。なお、第1のイベントが原因であると断定できる条件が、第1のイベントに関連した全ての第2イベントを検知すること、であるほうが望ましい。ただしこれは必須ではない。因果律情報は上記内容を示すことが出来れば、因果律行列の形式であってもよく、又は関係を示すポインタ情報を駆使して第1のイベントと第2のイベントとの関係を示したデータ構造であってもよい。
管理サーバ30000は、オンデマンドで因果律を作成する。つまり、管理サーバ30000は検知したが未解析である所定のイベントに対応する因果律が因果律情報に作成済みか否か判断し、未作成の場合は所定のイベントが関係するトポロジと、所定のイベントが関係するイベント伝播モデルと、を用いて因果律を作成し、そして所定のイベントの解析を行う。
イベント解析の例としては以下が考えられる。
* 検知したあるイベント1の原因となるイベント2を特定する。この特定処理は因果律情報を参照することで可能である。なお、管理サーバ(または後述する管理システム)は自身の表示デバイスにイベント1の情報と共に、イベント2が原因で当該イベントが発生した旨のメッセージを表示してもよい。
* 検知したあるイベント3を原因として発生する(またはする可能性がある)イベント4を求める。この特定処理は因果律情報を参照することで可能である。なお、管理サーバ(または後述する管理システム)は自身の表示デバイスに、イベント4がイベント3の発生が原因で発生する(またはする可能性がある)旨のメッセージを表示してもよい。
管理サーバ30000は、イベントを検知した後に、検知イベントと関係する所定の因果律が因果律情報に作成済みか判断し、作成されていない場合は(1)検知イベントを観測種別ペア又は原因種別ペアに含むイベント伝播モデルと、(2)検知イベントが発生したコンポーネントと関係するトポロジと、に基づいて所定の因果律を因果律情報に作成する(後ほどの説明では因果律を展開するとも言う)。なお、このようなイベント検知を契機とした因果律の展開をオンデマンド展開と呼ぶ。オンデマンド展開によって大規模な計算機システムや複雑な計算機システムを対象にしたイベント解析でも因果律情報のサイズをより少なくできる。
管理サーバ30000が管理対象装置の構成変更、追加、又は削除を検知した場合、いずれかのトポロジが更新、追加、又は削除される場合がある。管理サーバ30000は更新又は削除されたトポロジに基づいて作成された因果律を因果律情報から削除する。その後、更新されたトポロジに関連する因果律についてはオンデマンド展開で作成される。なお、追加されたトポロジについては前述のオンデマンド展開で因果律を作成する。
解析開始から長時間経過すると、様々な管理オブジェクトから様々な種別のイベントを検知する傾向にある。この場合、因果律情報のサイズがオンデマンド展開によって大きくなる。そのため、管理サーバ30000は、イベントに有効期間を与え、有効期間を過ぎたイベントは解析対象から外し、そして有効期間を過ぎたイベントに関係する因果律を因果律情報から削除してもよい。このようにすることで因果律情報のサイズを少なくすることが出来る。
図27の例では、コンポーネント1(種別a)で発生するイベントA1(種別A)の原因がコンポーネント2(種別b)で発生するイベントB2(種別B)であるイベントコリレーション1が作成済みの状況で、コンポーネント3(種別a)でイベントA3(種別A)を実際に検知した場合の概要を示している。なお、イベントコリレーション1は過去にイベントA1を検知したときを契機に、トポロジ1とイベント伝播モデル1に基づいて過去にオンデマンド作成したものである。この状況では、コンポーネント3(種別a)で発生するイベントA3(種別A)の原因がコンポーネント2(種別b)で発生するイベントB2(種別B)であるイベントコリレーション2を、トポロジ2とイベント伝播モデル1に基づいてオンデマンドに作成する。
なお、上記因果律の削除契機としては例えば以下があるが、他の契機であってもよい。
* 管理プログラムが管理対象装置の構成変更を検知したとき。
* 所定のインターバルに基づいた繰り返し処理として、削除を実行。
なお、オンデマンド展開はイベント解析時に因果律を作成するため、解析時の負荷が増大する。そのため、特定のイベント伝播モデル、又は特定の管理オブジェクトについては事前に因果律を展開してもよい。なお、事前に因果律を展開する場合を事前展開と呼ぶ。事前の例としては例えば、(1)管理プログラムが起動し、イベントを検知する前、又は(2)管理プログラムが管理対象装置の構成変更を検知し、その後最初のイベントを検知する前、が考えられる。ただし、事前とはイベント検知より前であれば他のタイミングでもよい。事前展開対象とするイベント伝播モデル又は管理オブジェクトの特定方法としては、(1)これらの識別子を事前にユーザに設定してもらう方法、(2)管理オブジェクトの種別を条件として特定する、又は(3)イベント伝播モデルに含まれる管理オブジェクトの種別又はイベント種別を条件として特定する、といった例が考えられるが他の方法でもよい。
因果律作成済み判断又は因果律展開の際、イベント伝播モデルの個々をアクセスしてイベントとの関係性を判断しているとモデル数に比例して時間がかかる。そのため、管理サーバ30000は、管理オブジェクトの種別とそこで発生するイベントの種別のペアから、当該ペアを原因種別ペア又は観測種別ペアに含むイベント伝播モデルのIDを特定可能なデータ構造を事前に作成し、判断に参照してもよい。
以上が本実施例の概要である。以後の記載では以下の場合を例示するが、本発明はこれに限定されないことはいうまでもない。
* ネットワークサービス:iSCSIプロトコルによるストレージアクセス。クライアント装置がホストコンピュータで、サーバ装置がストレージ装置。
* 因果律情報:因果律行列。
* 管理対象装置: ホストコンピュータ、IPスイッチ、ストレージ装置。
* 管理オブジェクト:コンポーネント。
* コンポーネント:iSCSIターゲット、ボリューム、RAIDグループ、ディスク、ホストコンピュータのドライブ名。
* 因果律の削除契機: 構成変更の検知。
図1から図5は計算機システムの構成および計算機システムに接続される装置の構成を示し、図6から図15は各装置に具備される管理情報を示す。
図1は、計算機システムの物理的構成を示す図である。当該計算機システムは、ストレージ装置20000と、ホストコンピュータ10000と、管理サーバ30000と、WEBブラウザ起動サーバ35000と、IPスイッチ40000と、を有し、それらが、ネットワーク45000によって接続される構成となっている。
ホストコンピュータ10000乃至10010は、例えば、それらに接続された、図示しないクライアントコンピュータからファイルのI/O要求を受信し、それに基づいてストレージ装置20000乃至20010へのアクセスを実現する。また、管理サーバ(管理計算機)30000は、当該計算機システム全体の運用を管理するものである。
WEBブラウザ起動サーバ35000は、ネットワーク45000を介して、管理サーバ30000のGUI表示処理モジュール32300と通信し、WEBブラウザ上に各種情報を表示する計算機である。ユーザはWEBブラウザ起動サーバ上のWEBブラウザに表示された情報を参照することで、計算機システム内の装置を管理する。ただし、管理サーバ30000と、WEBブラウザ起動サーバ35000は1台のサーバから構成されていてもよい。
また、図29に示すように計算機システム上に管理サーバ30000が複数台存在し、ストレージ装置20000、ホストコンピュータ10000、管理サーバ30000といった管理対象装置を分担して管理してもよい。
図2は、実施例によるホストコンピュータ10000の詳細な内部構成例を示す図である。ホストコンピュータ10000は、ネットワーク45000に接続するためのポート11000と、プロセッサ12000と、メモリ13000(ディスク装置を含んでも良い)と、を有し、これらは内部バス等の回路を介して相互に接続される構成となっている。
メモリ13000には、業務アプリケーション13100と、オペレーティングシステム13200と、論理ボリューム管理表13300と、が格納される。
業務アプリケーション13100は、オペレーティングシステム13200から提供された記憶領域を使用し、当該記憶領域に対しデータ入出力(以下、I/Oと表記)を行う。
オペレーティングシステム13200は、ネットワーク45000を介してホストコンピュータ10000に接続されたストレージ装置20000乃至20010上の論理ボリュームを記憶領域として業務アプリケーション13100に認識させるための処理を実行する。
ポート11000は、ストレージ装置20000とiSCSIにより通信を行うためのI/Oポートと、管理サーバ30000がホストコンピュータ内の管理情報を取得するための管理ポートを含む単一のポートとして図2で表現されているが、iSCSIにより通信を行うためのI/Oポートと管理ポートに分かれていてもよい。
図3は、実施例によるストレージ装置20000の詳細な内部構成例を示す図である。ストレージ装置20010も同様の構成を有している。
ストレージ装置20000は、ネットワーク45000を介してホストコンピュータ10000に接続するためのI/Oポート21000及び21010と、ネットワーク45000を介して管理サーバ30000に接続するための管理ポート21100と、各種管理情報を格納するための管理メモリ23000と、データを格納するためのRAIDグループ24000乃至24010と、データや管理メモリ内の管理情報を制御するためのコントローラ25000及び25010と、を有し、これらが内部バス等の回路を介して相互に接続される構成となっている。なお、RAIDグループ24000乃至24010の接続とは、より正確にはRAIDグループ24000乃至24010を構成する記憶デバイスが他の構成物と接続されていることを指す。
管理メモリ23000には、ストレージ装置の管理プログラム23100と、ボリューム管理表23200と、iSCSIターゲット管理表23300と、I/Oポート管理表23400と、RAIDグループ管理表23500と、ディスク管理表23600と、が格納される。管理プログラムは管理ポート21100を経由して管理サーバ30000と通信し、管理サーバに対しストレージ装置20000の構成情報を提供する。
RAIDグループ24000乃至24010は、それぞれ、1つまたは複数の磁気ディスク24200、24210、24220、及び24230によって構成されている。複数の磁気ディスクによって構成されている場合、それらの磁気ディスクはRAID構成を組んでいてもよい。また、RAIDグループ24000乃至24010は、論理的に複数のボリューム24100乃至24110に分割されている。
なお、論理ボリューム24100及び24110は、1つ以上の磁気ディスクの記憶領域を用いて構成されるのであれば、RAID構成を編成しなくてもよい。さらに、論理ボリュームに対応する記憶領域を提供するのであれば、磁気ディスクの代わりとしてフラッシュメモリなど他の記憶媒体を用いた記憶デバイスでも良いものとする。
コントローラ25000及び25010は、その内部に、ストレージ装置20000内の制御を行うプロセッサや、ホストコンピュータ10000との間でやりとりするデータを一時的に記憶するキャッシュメモリを持っている。そして、それぞれのコントローラは、I/OポートとRAIDグループの間に介在し、両者の間でデータの受け渡しを行う。
なお、ストレージ装置20000は、何れかのホストコンピュータに対して論理ボリュームを提供し、アクセス要求(I/O要求を指す)を受信し、受信したアクセス要求に応じて記憶デバイスへの読み書きを行うストレージコントローラと、記憶領域を提供する前述の記憶デバイスを含めば、図3及び上記説明以外の構成でもよく、例えば、ストレージコントローラと記憶領域を提供する記憶デバイスが別な筐体に格納されていてもよい。即ち、図3の例では管理メモリ23000と、コントローラ25000及び25110と、がストレージコントローラであってもよい。また、本明細書ではストレージコントローラと記憶デバイスが同じ筐体に存在する場合または別な筐体を含む表現として、ストレージ装置をストレージシステムと呼び変えても良い。
図4及び図17は、実施例による管理サーバ30000の詳細な内部構成例を示す図である。管理サーバ30000は、ネットワーク45000に接続するための管理ポート31000と、プロセッサ31100と、記憶資源33000と、後述する処理結果を出力するためのディスプレイ装置等の出力デバイス31200と、ストレージ管理者が指示を入力するためのキーボード等の入力デバイス31300とを有し、これらが内部バス等の回路を介して相互に接続される構成となっている。なお、記憶資源33000は、半導体メモリ又は記憶デバイス、又はこれらを混在させた記憶資源である。
記憶資源33000には管理プログラム32000が格納される。図17のように管理プログラム32000は、プログラム制御モジュール32100と、装置情報取得モジュール32200と、GUI表示処理モジュール32300と、イベント解析処理モジュール32400と、イベント伝播モデル展開モジュール32500と、を含む。なお、各モジュールは、メモリ32000のプログラムモジュールとして提供されているが、ハードウェアモジュールとして提供されるものであっても良い。また、管理プログラム32000は各モジュールの処理を実現できるのであれば、モジュールによって構成されなくてもよい。言い方を変えれば、以下の説明における各モジュールについての説明は管理プログラム32000に関する説明と置き換えてもよいということである。
記憶資源33000はさらに、イベント管理表33100と、イベント伝播モデルリポジトリ33200と、因果律行列33300と、トポロジ生成方式リポジトリ33400と、構成DB33500と、展開対象イベント伝播モデル管理表33600と、展開済イベント管理表33700と、展開済起点コンポーネント管理表33800と、イベント伝播モデル管理表33900と、が格納されている。構成DB33500には構成情報が格納される。
構成情報の例としては、装置情報取得モジュール32200が管理対象の各ホストコンピュータから収集してきた論理ボリューム管理表13300の各項目と、管理対象の各ストレージから収集してきたボリューム管理表23200の各項目と、iSCSIターゲット管理表23300各項目と、I/Oポート管理表23400各項目と、RAIDグループ管理表23500各項目と、ディスク管理表23600各項目である。なお、構成DBには管理対象装置の全ての表、または表中の全ての項目を格納しなくてもよい。また、構成DBが格納する各項目のデータ表現形式・データ構造は、管理対象装置と同じでなくてもよい。また、管理プログラム32000が管理対象装置からこれら各項目を受信する場合、管理対象装置のデータ構造やデータ表現形式で受信してもよい。
装置情報取得モジュール32200は、管理下の管理対象装置に定期的又は繰り返しアクセスし、管理対象装置内の各コンポーネントの状態を取得する。イベント解析処理モジュール32400は、因果律行列33300を参照し、装置情報取得モジュール32200が取得した管理対象装置の異常状態の根本原因を解析する。
GUI表示処理モジュール32300は、入力デバイス31300を介した管理者からの要求に応じ、取得した構成管理情報を、出力デバイス31200を介して表示する。なお、入力デバイスと出力デバイスは別々なデバイスでもよく、一つ以上のまとまったデバイスでもよい。
なお、管理サーバ(管理計算機)は、例えば、入出力デバイスとして、ディスプレイとキーボードとポインタデバイス等を有しているが、これ以外の装置であってもよい。また、入出力デバイスの代替としてシリアルインターフェースやイーサーネットインターフェースを用い、当該インターフェースにディスプレイ又はキーボード又はポインタデバイスを有する表示用計算機(例えば、WEBブラウザ起動サーバ35000)を接続し、表示用情報を表示用計算機に送信したり、入力用情報を表示用計算機から受信することで、表示用計算機で表示を行ったり、入力を受け付けることで入出力デバイスでの入力及び表示を代替してもよい。
本明細書では、計算機システム(情報処理システム)を管理し、表示用情報を表示する一つ以上の計算機の集合を管理システムと呼ぶことがある。管理サーバが表示用情報を表示する場合は、管理サーバが管理システムであり、また、管理サーバと表示用計算機(例えば図1のWEBブラウザ起動サーバ35000)の組み合わせも管理システムである。また、管理処理の高速化や高信頼化のために複数の計算機で管理サーバと同等の処理を実現してもよく、この場合は当該複数の計算機(表示を表示用計算機が行う場合は表示用計算機も含め)が管理システムである。
図5にIPスイッチ40000の詳細な構成を示す。IPスイッチ40000は、プロセッサ41000と、各種管理情報を保持するためのメモリ42000と、ネットワーク45000、45010を介してホストコンピュータ10000に接続するためのI/Oポート43000、43010と、ネットワーク45000に接続するための管理ポート44000を有し、これらは内部バス等の回路を介して相互に接続される。
なお、メモリ42000は、半導体メモリの代わりとしてその一部もしくは全部が磁気ディスクなど他の記憶媒体であっても良いものとする。
図6A、B及びCは、ホストコンピュータ10000の具備する論理ボリューム管理表13300の構成例を示す図である。
論理ボリューム管理表13300は、ホストコンピュータ内で各論理ボリュームの識別子となるドライブ名を登録するフィールド13310と、論理ボリュームの実体が存在するストレージ装置との通信の際に用いるホストコンピュータ上のI/Oポート11000の識別子となるiSCSIイニシエータ名を登録するフィールド13320と、論理ボリュームの実体が存在するストレージ装置との通信の際に用いるストレージ装置上のI/Oポート21000の識別子となる接続先iSCSIターゲットを登録するフィールド13330と、ストレージ装置において論理ボリュームの識別子となるLUN IDを登録するフィールド13340と、を構成項目として含んでいる。
図6Aには、ホストコンピュータの具備する論理ボリューム管理表の具体的な値の一例を示している。つまり、ホストコンピュータ上で(E:)というドライブ名で示される論理ボリュームは、com.hitachi.sv1というiSCSIイニシエータ名で示されるホストコンピュータ上のポートと、com.hitachi.sto1というiSCSIターゲット名で示されるストレージ装置上のポートを介してストレージ装置と接続しており、0というLUN IDをストレージ装置上で持つ。
図7は、ストレージ装置20000の具備するボリューム管理表23200を示す図である。
ボリューム管理表23200は、ストレージ装置内で各ボリュームの識別子となるボリュームIDを登録するフィールド23210と、各ボリュームの容量を登録するフィールド23220と、各ボリュームが所属するRAIDグループの識別子となるRAIDグループIDを登録するフィールド23230と、各ボリュームが所属するiSCSIターゲットの識別子となるターゲットIDを登録するフィールド23240と、各ボリュームのiSCSIターゲット内での識別子となるLUN IDを登録するフィールド23250と、を構成項目として含んでいる。
図7には、ストレージ装置の具備するボリューム管理表の具体的な値の一例を示している。つまり、ストレージ装置上のボリュームVOL1は20GBの記憶領域を持ち、RG1というRAIDグループIDで示されるRAIDグループに属し、TG1というiSCSIターゲットIDで示されるiSCSIターゲットに属し、0というLUN IDを持つ。
図8A及び図8Bは、ストレージ装置20000の具備するiSCSIターゲット管理表23300を示す図である。
iSCSIターゲット管理表23300は、ストレージ装置内でiSCSIターゲットの識別子となるターゲットIDを登録するフィールド23310と、各iSCSIターゲットが持つiSCSIターゲット名を登録するフィールド23320と、各iSCSIターゲットに属するボリュームに対しアクセスが許可されたホストコンピュータ上のポートの識別子となるiSCSIイニシエータ名を登録するフィールド23330と、を構成項目として含んでいる。
図8Aには、ストレージ装置の具備するiSCSIターゲット管理表の具体的な値の一例を示している。つまり、ストレージ装置上のiSCSIターゲットHG1は、com.hitachi.sto1でというiSCSIターゲット名を持ち、iSCSIイニシエータ名がcom.hitachi.sv1もしくはcom.hitachi.sv11であるホストコンピュータ上のポートからのアクセスを許可している。
図9は、ストレージ装置20000の具備するI/Oポート管理表23400の構成を示す図である。
I/Oポート管理表23400は、ストレージ装置内で各ポートの識別子となるポートIDを登録するフィールド23410と、ポートのネットワーク45000上での識別子となるMACアドレスを登録するためのフィールド23420と、を構成項目として含んでいる。
図9には、ストレージ装置の具備するI/Oポート管理表の具体的な値の一例を示している。つまり、ストレージ装置上のポートPORT1は、TG1,TG2というiSCSIターゲットIDで示されるiSCSIターゲットによって使用されている。
図10は、ストレージ装置20000の具備するRAIDグループ管理表23500の構成を示す図である。
RAIDグループ管理表23500は、ストレージ装置内で各RAIDグループの識別子となるRAIDグループIDを登録するフィールド23510と、RAIDグループのRAIDレベルを登録するフィールド23520と、各RAIDグループの容量を登録するフィールド23540から構成されている。
図10には、ストレージ装置の具備するRAIDグループ管理表の具体的な値の一例を示している。つまり、ストレージ装置上のRAIDグループRG1は、RAIDレベルがRAID1で容量は100GBである。
図11は、ストレージ装置20000の具備するディスク管理表23600の構成を示す図である。
ディスク管理表23600は、ストレージ装置内で各ディスクの識別子となるディスクIDを登録するフィールド23610と、ディスクのディスク種別を登録するフィールド23620と、から構成されている。
図11には、ストレージ装置の具備するディスク管理表の具体的な値の一例を示している。つまり、ストレージ装置上のディスクDISK1は、ディスク種別がFCディスクである。
図12は、管理サーバ30000が有するイベント管理表33100の構成例を示す図である。
イベント管理表33100は、イベント自身の識別子となるイベントIDを登録するフィールド33110と、取得した構成情報の変化といったイベントの発生した装置の識別子となる装置IDを登録するフィールド33120と、イベントの発生した装置内の部位の識別子を登録するフィールド33130と、発生したイベントの種別を登録するフィールド33140と、イベントが後述するイベント伝播モデル展開モジュール32500によって処理済みかどうかを登録するフィールド33150と、イベントが発生した日時を登録するフィールド33160と、イベントが後述するイベント伝播モデル展開モジュール32500による処理の対象(又は管理プログラムによる原因解析対象)となる期間を登録するフィールド33170と、を構成項目として含んでいる。
例えば、図12の第1行目(1つ目のエントリ)からは、管理サーバ30000が、ホストコンピュータHOST1の、(E:)で示される論理ボリュームにおける状態異常を検知し、そのイベントIDはEV1であることが分かる。
図13A及び図13Bは、管理サーバ30000が有するイベント伝播モデルリポジトリ33200内のイベント伝播モデルの構成例を示す図である。障害解析において根本原因を特定するためのイベント伝播モデルは、ある障害の結果発生することが予想されるイベントの組み合わせと、その根本原因を"IF−THEN"形式で記載するものとなっている。なお、イベント伝播モデルは図13A及び図13Bに挙げられたものに限られず、さらに多くのルールがあっても構わない。当然ながら、イベント伝播モデルリポジトリ33200には複数のイベント伝播モデルを含んでも良い。
イベント伝播モデルは、イベント伝播モデルの識別子となるモデルIDを登録するフィールド33210と、"IF−THEN"形式で記載したイベント伝播モデルのIF部に相当する観測イベント種別を登録するフィールド33220と、"IF−THEN"形式で記載したイベント伝播モデルのTHEN部に相当する原因イベント種別を登録するためのフィールド33230と、を構成項目として含んでいる。結論部のステータスが正常になれば、条件部の問題も解決しているという関係にあるものである。
図13Aには、管理サーバが有するイベント伝播モデルの具体的な値の一例を示している。つまり、モデルIDがRule1で示されるイベント伝播モデルにおいては、観測イベント種別としてホストコンピュータ上の論理ボリュームの状態異常と、ストレージ装置上のボリュームの状態異常を検知したとき、ストレージ装置のボリュームの故障が原因と結論付ける。
なお、図13Bに示すように、観測イベントとして「ストレージ装置のボリュームの故障」という、他のイベント伝播モデルにおいて結論として位置づけられているイベント種別を持っていてもよい。
図14A乃至Eは、管理サーバ30000の具備する因果律行列33300の構成を示す図である。
因果律行列33300は、以下の情報を含む。
* 展開の際使用したイベント伝播モデルリポジトリ33200の識別子となるイベント伝播モデルIDを登録するフィールド33310。
* 管理サーバの装置情報取得モジュール32200が検知するイベントを特定する情報(図中では管理オブジェクトの識別子(つまり装置IDとコンポーネントID)とイベントの種別)を登録するフィールド33320。
* 前記イベントを検知した際、イベント解析処理モジュール32400が障害の原因として結論付ける原因イベントを登録するための情報(図中では管理オブジェクトの識別子(つまり装置IDとコンポーネントID)とイベントの種別)を登録するフィールド33330。
* イベント伝播モデルリポジトリ33200に"IF−THEN"形式で記載したイベント伝播モデルに基づき、どのイベントを受信した際何を根本原因と位置づけるかという対応関係(つまり因果律)を登録するためのフィールド33340。
図14Aには、管理サーバの具備する因果律行列の具体的な値の一例を示している。つまり、ストレージ装置SYS1のボリューム(VOL1)の状態異常と、ホストHOST1の論理ボリューム(E:)の状態異常というイベントを装置情報取得モジュールが検知したとき、イベント解析処理モジュールは、ストレージ装置SYS1のボリューム(VOL1)の故障が根本原因であると結論付ける。
なお、因果律行列は後述するように因果律の追加、削除をより効率的に行うため、動的に行列のサイズを変更できるデータ構造であってもよい。例えば、所定の行数又は列数毎にサブ行列化して、それらをポインタやインデックスで関係付けて仮想的な行列を見せる等が考えられる。また、因果律行列は記憶資源の連続領域を用いて行列構造を生成してもよい。
図15A及び図15Bは、管理サーバ30000が有するトポロジ生成方式リポジトリ33400内のトポロジ生成方式情報(省略してトポロジ生成方式と呼ぶことがある)の構成例を示す図である。
トポロジ生成方式は、前記管理サーバが管理対象装置から取得した構成情報に基づき、監視対象となる複数の装置間での接続関係(トポロジ)を生成するための手段を定義した情報である。トポロジ生成方式は、トポロジの識別子となるトポロジIDを登録するフィールド33410と、トポロジを生成する際の起点となる管理対象装置内のコンポーネント種別を登録するフィールド33420と、トポロジを生成する際の終点となるコンポーネント種別を登録するフィールド33430と、前記起点コンポーネント−終点コンポーネント間のトポロジ生成の際に経由する必要のあるコンポーネント種別を登録するフィールド33440と、前記起点コンポーネント−終点コンポーネント間のトポロジ生成方法を登録するフィールド33450と、を構成項目として含んでいる。
図15A及び図15Bには、管理サーバの具備するトポロジ生成方式の具体的な値の一例を示している。つまり、ストレージ装置のボリュームを起点とし、ホストコンピュータの論理ボリュームを終点とするトポロジは、論理ボリュームのiSCSIイニシエータ名が、iSCSIターゲットの接続許可iSCSIイニシエータと等しく、かつボリューム内のiSCSIターゲットIDが、iSCSIターゲット内のIDと等しい組み合わせを検索することにより取得可能である。
図16に、管理サーバ30000の装置情報取得モジュール32200が実施する装置情報取得処理のフローチャートを示す。
プログラム制御モジュール32100は、プログラムの起動時、もしくは前回の装置情報取得処理から一定時間経過するたびに、装置情報取得モジュール32200に対し、装置情報取得処理を実行するよう指示する。なお、当該実行指示を繰り返し出す場合は厳密に一定期間毎である必要は無く、繰り返しさえしていればよい。また。装置から取得する情報には装置の構成情報、状態情報、性能情報が含まれるが、これらの情報をそれぞれ異なるタイミングで取得してもよい。
装置情報取得モジュール32200は、一つ以上の管理対象装置の各々に対し、以下の一連の処理を繰り返す(ステップ61010)。
装置情報取得モジュール32200は、管理対象装置に対して装置の構成情報、状態情報、又は性能情報を送信するよう指示する(ステップ61020)。
装置からの応答があれば(ステップ61030)、装置情報取得モジュール32200は、取得した構成情報を構成DB33500に格納された過去の構成情報と比較する(ステップ61040)。なお、装置から指示に対する応答がなかった場合、装置情報取得処理を終了する。
取得した構成管理情報を構成DBに格納された過去の構成情報と比較した結果、異なる項目が見つかった場合(ステップ61050)、装置情報取得モジュール32200は、差分のあった項目をイベント化し、イベント管理表33100を更新する(ステップ61060)。
次に、装置情報取得モジュール32200は、状態情報、性能情報を取得した際に検知した状態異常および性能異常をイベント化し、イベント管理表33100を更新する(ステップ61070)。その上で、装置情報取得モジュール32200は、取得した構成情報を構成DB33500に格納する(ステップ61080)。
以上が、装置情報取得モジュール32200が実施する構成管理情報取得処理である。なお、因果律の展開又は削除を行うモジュールへの構成変更の通知(又はモジュールの実行開始)は、必ずしもイベントを通じて行う必要はない。また、状態情報に基づいたイベント化とは、コンポーネントの状態が正常以外の状態に変化したときに変化先の状態に対応したイベント(情報)を生成することが一例である。また、性能情報に基づいたイベント化とは、所定の評価基準(閾値等)によって正常ではない性能値となった場合にイベント(情報)を生成することが一例である。
次に、管理サーバ30000が具備する展開対象イベント伝播モデル管理表33600を図18に、管理サーバ30000が実行する処理方式を図19、図20及び図21に示す。
図18は、管理サーバ30000の具備する展開対象イベント伝播モデル管理表33600の構成例を示す図である。
展開対象イベント伝播モデル管理表33600は、取得した構成変更イベントの発生した装置の種別を登録するフィールド33610と、前記イベントの発生した装置内のコンポーネントの種別を登録するフィールド33620と、前記イベントの種別を登録するフィールド33630と、イベントが後述するイベント解析処理モジュール32500によって処理される際、どのイベント伝播モデルが展開対象となるかを登録するフィールド33640と、を構成項目として含んでいる。
図18には、管理サーバの具備する展開対象イベント伝播モデル管理表の具体的な値の一例を示している。つまり、ホストコンピュータにおける論理ボリュームの状態異常というイベントが発生した場合、Rule1を再展開する必要がある。
図19に、管理サーバ30000のイベント解析処理モジュール32400が実施する、イベント確認処理のフローチャートを示す。なお、管理サーバ30000の装置情報取得モジュール32200は、図16に示す装置情報取得処理を管理対象装置に対して実施した後、イベント解析処理モジュール32400に対し、イベント確認処理を行なうよう指示する。
イベント解析処理モジュール32400は、イベント管理表33100を参照し、イベント管理表に定義された構成変更イベントに対し、ループ内の処理を繰り返す(ステップ64010)。イベント解析処理モジュール32400は、イベント管理表に定義されたイベントの処理済みフラグがNoであるかどうかを確認する(ステップ64020)。イベントの処理済みフラグがNoである、すなわち未処理イベントである場合、ステップ64030乃至64060の処理を行う。
イベント解析処理モジュール32400は、イベント管理表に定義されたイベントの処理済みフラグをYesに変更する(ステップ64030)。次にイベント解析処理モジュール32400は、イベント管理表に定義されたイベントが構成変更イベントかどうかを確認する(ステップ64040)。イベント管理表に定義されたイベントが構成変更イベントである場合、図21に示すイベント伝播モデル再展開処理を実行する。
次にイベント解析処理モジュール32400は、イベント管理表に定義されたイベントが状態異常、または性能異常イベント(構成変更イベント以外)かどうかを確認する(ステップ64050)。イベント管理表に定義されたイベントが状態異常、もしくは性能異常イベント(構成変更イベント以外)である場合、イベント伝播モデル展開モジュール32500に対し、当該イベントを指定して図20に示すイベント伝播モデルオンデマンド展開処理を実行するよう指示する。
イベント伝播モデルオンデマンド展開処理が終了すると、イベント解析処理モジュール32400は、イベント管理表のイベント有効期間を設定する(ステップ64060)。イベント有効期間は、イベントの発生した時刻に、予め定められた一定の時間を加えて算出される。ただしイベント有効期間は他の式で算出されてもよい。
以上が、イベント解析処理モジュール32400が実施するイベント確認処理である。
なお、イベント管理表に複数の状態異常、もしくは性能異常イベントが存在する場合、同時に複数のイベントについてイベント伝播モデルオンデマンド展開処理を実行するようイベント伝播モデル展開モジュールに指示してもよい。
図20に、管理サーバ30000のイベント伝播モデル展開モジュール32500が実施するイベント伝播モデルオンデマンド展開処理のフローチャートを示す。
イベント伝播モデル展開モジュール32500は、展開対象イベント伝播モデル管理表33600を参照し、処理起動時に指定されたイベント(つまり、未処理であったイベントの一つ)に対応したイベント伝播モデルの一覧を取得する(ステップ65010)。
次に、イベント伝播モデル展開モジュール32500は、前記取得したイベント伝播モデルに対し、ステップ65030乃至65090の処理を繰り返す(ステップ65020)。なお、展開対象イベント伝播モデル管理表33600にイベントが登録されていない場合は、以下の処理を行わずにイベント伝播モデルオンデマンド展開処理を終了する。
イベント伝播モデル展開モジュール32500は、トポロジ生成方式リポジトリ33400を参照し、イベント伝播モデルに対応したトポロジ生成方式をトポロジ生成方式リポジトリ33400より取得する(ステップ65030)。該当するトポロジ生成方式がトポロジ生成方式リポジトリにない場合は、以下の処理を行わない。
該当するトポロジ生成方式がトポロジ生成方式リポジトリにあれば(ステップ65040)、イベント伝播モデル展開モジュール32500は、取得したトポロジ生成方式を元に構成DB33500からトポロジを取得する(ステップ65050)。イベント伝播モデル展開モジュール32500は、取得したトポロジに基づいてイベント伝播モデルを展開し(ステップ65060)、展開結果が因果律行列33300に既にあるかどうかを確認する(ステップ65070)。展開結果が因果律行列33300に既にある場合、以下の処理は行わない。
展開結果が因果律行列に存在しない場合、イベント伝播モデル展開モジュール32500は、因果律行列33300の列として追加する(ステップ65080)。次に、イベント伝播モデル展開モジュール32500は、展開結果の結論イベントと、処理起動時に指定されたイベント以外の条件イベントについて、図20に示すイベント伝播モデルオンデマンド展開処理を実施する(ステップ65090)。
以上が、イベント伝播モデル展開モジュール32500が実施するイベント伝播モデルオンデマンド展開処理である。なお、構成DB以外の情報にトポロジを別途格納している場合はそのような情報を参照して上記処理を行っても良い。
図21に、管理サーバ30000のイベント伝播モデル展開モジュール32500が実施するイベント伝播モデル再展開処理のフローチャートを示す。
イベント伝播モデル展開モジュール32500は、因果律行列33300を全て削除する(ステップ66010)。次に、イベント種別が構成変更であるイベントについて、イベント処理済みフラグをYesに変更する(ステップ66020)。
次に、イベント伝播モデル展開モジュール32500は、イベント管理表33100を参照し、イベント管理表の未処理イベントに対し、ループ内の処理を繰り返す(ステップ66030)。
イベント伝播モデル展開モジュール32500は、該当するイベントの種別は状態異常、もしくは性能異常(つまり構成変更以外)かどうかを確認する(ステップ66040)。次に、該当するイベントのイベント有効期間が満了しているかどうかを確認する(ステップ66050)。満了していない場合、当該イベントを指定してイベント伝播モデルオンデマンド展開処理65000を実施する(ステップ66060)。
以上が、イベント伝播モデル展開モジュール32500が実施するイベント伝播モデル再展開処理である。なお、本フローでは一度全ての因果律を削除し、有効期間内のイベントについて再度因果律を作成しているが、ステップ66010で構成変更に関係した因果律だけ削除してもよい。
以下に、図6乃至13の情報の内容に対応する計算機システムを例として、実施例1の処理がどのように因果律行列を作成するかを示す。なお、処理開始当初のiSCSIターゲット管理表は図8Aに示すとおりであるものとする。
プログラム制御モジュールは、管理者からの指示もしくはタイマーによるスケジュール設定によって応じて、装置情報取得モジュールに対し、装置情報取得処理を実行するよう指示する。装置情報取得モジュールは、管理対象装置に順にログインし、装置に対し装置の構成情報、状態情報、性能情報を送信するよう指示する。
上記の処理が終了した後、装置情報取得モジュールは、取得した状態情報、性能情報を参照し、イベント管理表を更新する。ここでは、図12のイベント管理表の1行目に示す通り、ホストコンピュータHOST1の、(E:)で示される論理ボリュームにおける状態異常を検知したケースを想定する。
イベント解析処理モジュールは、上記イベントが未処理イベントであることを確認すると、イベント伝播モデル展開モジュールに対し、展開対象イベント伝播モデル管理表を参照して当該イベントを指定してイベント伝播モデルオンデマンド展開処理を実行するよう指示する。
イベント伝播モデル展開モジュールは、イベントに対応したイベント伝播モデルの一覧を取得する。例えば、図18に示す展開対象イベント伝播モデル管理表を参照すると、ホストコンピュータにおける論理ボリュームの状態異常というイベントが発生した場合、Rule1を展開する必要があることが分かる。
図13Aに示すイベント伝播モデルRule1は、観測イベントとして"ホストコンピュータの論理ボリュームの状態異常"と、"ストレージ装置のボリュームの状態異常"が定義されている。図15Aに示すトポロジ生成方式を参照すると、ストレージ装置のI/Oポートを起点とし、ホストコンピュータの論理ボリュームを終点とするトポロジ生成方式TP1が定義されている。そこで、このトポロジ生成方式を利用してトポロジを取得する。
図7の示すボリューム管理表(に相当する管理サーバが格納した構成DB内の項目)を参照し、ストレージ装置SYS1のボリュームVOL1に着目すると、そのターゲットIDはTG1となっている。次に、図8Aに示すiSCSIターゲット管理表(に相当する管理サーバが格納した構成DB内の項目)を参照し、iSCSIターゲットIDがTG1となっているものを探し、その接続許可iSCSIイニシエータ名を見ると"com.hitachi.sv1"もしくは"com.hitachi.sv11"となっている。
次に、図6Aに示すI/Oポート管理表(に相当する管理サーバが格納した構成DB内の項目)を参照し、iSCSIイニシエータ名が"com.hitachi.sv1"もしくは"com.hitachi.sv11"となっている論理ボリュームを検索する。その結果検索されたホストコンピュータHOST1の論理ボリューム(E:)と(F:)のうち、LUNIDがストレージ装置SYS1のボリュームVOL1のLUNIDと等しいものを探す。以上の結果、ホストコンピュータの論理ボリュームとストレージ装置のボリュームを含むトポロジの一つとして、ホストコンピュータHOST1の論理ボリューム(E:)と、ストレージ装置SYS1のボリュームVOL1の組み合わせが存在する。
そこで、観測イベントとして"ホストコンピュータHOST1の論理ボリューム(E:)の状態異常"と、"ストレージ装置SYS1のボリュームVOL1の状態異常"を検知した際、根本原因として"ストレージ装置SYS1のボリュームVOL1の故障"を結論付けるパターンが展開結果(つまり展開すべき因果律)となる。この展開結果が因果律行列に存在しない場合、展開結果を因果律行列の列として追加する。
上記の処理が終了した後、展開結果の結論イベントと、入力イベント以外の条件イベントについて、図20に示すイベント伝播モデルオンデマンド展開処理を実施する。上記の展開結果の場合、"ストレージ装置SYS1のボリュームVOL1の故障"というイベントについて、図18に示す展開対象イベント伝播モデル管理表を参照すると、Rule2を再展開する必要があることが分かる。そこで、"ストレージ装置SYS1のボリュームVOL1の故障"というイベントを起点として、Rule2について再度展開を行う。
以上の処理により、イベント伝播モデルRule1およびRule2に関する因果律行列が作成され、それぞれ図14Cおよび図14Dの状態となる。
一方、装置情報取得モジュールは、構成DBに格納された過去の構成情報と、管理対象装置より取得した構成情報を参照し、イベント管理表を更新する。ここでは、図12のイベント管理表の2行目に示す通り、ストレージ装置SYS1の、TG1で示されるiSCSIターゲットにおける接続許可iSCSIイニシエータの変更を検知したケースを想定する。なお、変更後のiSCSIターゲット管理表を図8Bに示す。
次に、イベント解析処理モジュールは、イベント管理表に定義されたイベントの処理済みフラグをYesに変更する。次にイベント解析処理モジュールは、イベント管理表に定義されたイベントが構成変更イベントかどうかを確認する。イベント管理表に定義されたイベントが構成変更イベントである場合、イベント伝播モデル再展開処理を実行する。
イベント伝播モデル展開モジュールは、因果律行列を全て削除し、イベント種別が構成変更であるイベントについて、イベント処理済みフラグをYesに変更する。次に、イベント伝播モデル展開モジュールは、イベント管理表を参照し、イベントの種別が状態異常、性能異常であり、かつイベント有効期間が満了していないイベントについて、イベント伝播モデルオンデマンド展開処理を実施する。
例えば、図12のイベント管理表の1行目には、"ホストコンピュータHOST1の、(E:)で示される論理ボリュームにおける状態異常"というイベントが定義されており、イベント処理済みフラグをYesで、イベント有効期間は"2010−01−01 15:30:00"と定義されている。そこで、イベント伝播モデル展開モジュールは、上記イベントを起点にイベント伝播モデルオンデマンド展開を行う。すなわち、イベント伝播モデルRule1を展開し、因果律行列に追加する。展開の方法は、イベント伝播モデルオンデマンド展開処理の説明にて述べた方法と同じである。
以上の処理により、イベント伝播モデルRule1に関する因果律行列が更新され、図14Cから図14Eの状態となる。
実施例2では、管理プログラムのイベント伝播モデル展開モジュール32500が実施する、別なイベント伝播モデルオンデマンド展開処理について説明する。
実施例1においては、同時に複数のイベントについてイベント伝播モデルオンデマンド展開処理を実行するようイベント伝播モデル展開モジュールに指示する。ITシステムにおいては、1つの障害が多数の装置に波及し、同時に多数の異常イベントが管理プログラムによって検知される。しかし、同じ根本原因を持つ異常イベントについて、イベント伝播モデルオンデマンド展開処理を並列に処理すると、同じトポロジを複数同時に構成DBより取得することとなり、処理上の無駄が多く処理時間が長くなる。
上記の課題を解決するため、実施例2では管理サーバ30000におけるイベント伝播モデルオンデマンド展開処理を変更する。変更後の管理サーバ30000が具備する展開済イベント管理表33700を図22に、展開済起点コンポーネント管理表33800を図23に、管理サーバ30000が実行する処理を図24A及び図24Bに示す。なお、その他は実施例1と同様である。
図22は、実施例2において管理サーバ30000の記憶資源に格納された展開済イベント管理表33700の構成例を示す図である。
展開済イベント管理表33700は、展開済イベントの発生した装置の識別子となる装置IDを登録するフィールド33710と、イベントの発生した装置内の部位の識別子を登録するフィールド33720と、前記イベントの種別を登録するフィールド33730と、前記イベントを契機とした展開処理の進行状況を登録するフィールド33740と、を構成項目として含んでいる。
図22には、管理サーバの具備する展開済イベント管理表の具体的な値の一例を示している。つまり、ホストコンピュータHOST1における論理ボリューム(E:)の状態異常というイベントを契機とした展開処理は既に完了していることを示している。
図23は、実施例2において管理サーバ30000の記憶資源に格納された展開済起点コンポーネント管理表33800の構成例を示す図である。
展開済起点コンポーネント管理表33800は、展開済起点コンポーネントの存在する装置の識別子となる装置IDを登録するフィールド33810と、起点コンポーネントの識別子を登録するフィールド33820と、前記コンポーネントを起点に展開を行ったイベント伝播モデルのIDを登録するフィールド33830と、前記イベントを契機とした展開処理の進行状況を登録するフィールド33840と、を構成項目として含んでいる。
図23には、管理サーバの具備する展開済起点コンポーネント管理表の具体的な値の一例を示している。つまり、ストレージ装置SYS1におけるボリュームVOL1というコンポーネントを起点としたRule1の展開処理は既に完了していることを示している。
本実施例において管理サーバ30000が実行するイベント伝播モデルオンデマンド展開処理の処理方式を図24A及び図24Bに示す。なお、管理サーバ30000が実行するその他の処理は、実施例1と変わらない。
図24A及び図24Bに、実施例2における、管理サーバ30000のイベント伝播モデル展開モジュール32500が実施するイベント伝播モデルオンデマンド展開処理のフローチャートを示す。先ずは図24Aの処理から説明を始める。
イベント伝播モデル展開モジュール32500は、展開済イベント管理表33700を参照し、処理起動時に指定されたイベントが存在するかどうか検索する(ステップ67010)。イベントが存在し、そのステータスが「展開済」の場合は、何もせず処理を終了する。イベントが存在し、そのステータスが「展開中」の場合は、一定時間待機した後に処理を再試行する。展開済イベント管理表33700にイベントが存在しない場合は、以下に示す処理を実施する(ステップ67020)。
イベント伝播モデル展開モジュール32500は、展開済イベント管理表33700にイベントを追加し、イベントのステータスを「展開中」に変更する(ステップ67030)。次に、展開対象イベント伝播モデル管理表33600を参照し、発生したイベントに対応したイベント伝播モデルの一覧を取得する(ステップ67040)。
次に、イベント伝播モデル展開モジュール32500は、前記取得したイベント伝播モデルに対し、図24Bに記載のステップ67060乃至ステップ67140の処理を繰り返す(ステップ67050)。なお、展開対象イベント伝播モデル管理表33600にイベントが登録されていない場合は、以下の処理を行わずにイベント伝播モデルオンデマンド展開処理を終了する。
以下、図24Bの説明である。
イベント伝播モデル展開モジュール32500は、トポロジ生成方式リポジトリ33400を参照し、イベント伝播モデルに対応したトポロジ生成方式をトポロジ生成方式リポジトリ33400より取得する(ステップ67060)。該当するトポロジ生成方式がトポロジ生成方式リポジトリ33400にない場合は、以下の処理を行わない。
該当するトポロジ生成方式がトポロジ生成方式リポジトリにあれば(ステップ67070)、イベント伝播モデル展開モジュール32500は、取得したトポロジ生成方式を元に、イベントの発生したコンポーネントに対応する起点コンポーネント取得する(ステップ67080)。
次に、イベント伝播モデル展開モジュール32500は、展開済起点コンポーネント管理表33800を参照し、起点コンポーネントが存在するかどうか検索する(ステップ67010)。起点コンポーネントが存在し、そのステータスが「展開済」の場合は、何もせず処理を終了する。起点コンポーネントが存在し、そのステータスが「展開中」の場合は、一定時間待機した後に処理を再試行する。展開済起点コンポーネント管理表33800に起点コンポーネントが存在しない場合は、以下に示す処理を実施する(ステップ67090)。
イベント伝播モデル展開モジュール32500は、展開済起点コンポーネント管理表33800に起点コンポーネントを追加し、起点コンポーネントのステータスを「展開中」に変更する(ステップ67100)。
イベント伝播モデル展開モジュール32500は、取得した生成方式リポジトリを元に構成DB33500からトポロジを取得し、取得したトポロジに基づいてイベント伝播モデルを展開する(ステップ67110)。そして展開結果を、因果律行列33300の列として追加する(ステップ67120)。次に、展開済起点コンポーネント管理表33800を参照し、起点コンポーネントのステータスを「展開済」に変更する(ステップ67130)。
次に、展開結果の結論イベントと、処理起動時に指定されたイベント以外の条件イベントについて、ルールオンデマンド展開処理を繰り返し実施する(ステップ67140)。
ここまでが図24Bの説明である。再び図24Aに戻り説明する。
イベント伝播モデルに対する処理が終了した時点で、展開済イベント管理表33700を参照し、発生したイベントのステータスを「展開済」に変更する(ステップ67150)。
以下に、図6乃至13の情報の内容に対応する計算機システムを例として、実施例2の処理がどのように因果律行列を作成するかを示す。
プログラム制御モジュールは、管理者からの指示もしくはタイマーによるスケジュール設定によって応じて、装置情報取得モジュールに対し、装置情報取得処理を実行するよう指示する。装置情報取得モジュールは、管理対象装置に順にログインし、管理対象装置に対し装置の構成情報、状態情報、性能情報を送信するよう指示する。
上記の処理が終了した後、装置情報取得モジュールは、取得した状態情報、性能情報を参照し、イベント管理表を更新する。ここでは、図12のイベント管理表の4行目に示す通り、ストレージ装置SYS1の、DISK1で示されるディスクにおける状態異常を検知したケースを想定する。
イベント解析処理モジュールは、展開対象イベント伝播モデル管理表を参照し、上記イベントが未処理イベントであることを確認すると、イベント伝播モデル展開モジュールに対し、当該イベントを指定してイベント伝播モデルオンデマンド展開処理を実行するよう指示する。
イベント伝播モデル展開モジュールは、展開済イベント管理表を参照し、処理起動時に指定されたイベントが存在するかどうか検索する。展開済イベント管理表にイベントが存在しない場合、展開済イベント管理表にイベントを追加し、イベントのステータスを「展開中」に変更する。
次にイベント伝播モデル展開モジュールは、イベントに対応したイベント伝播モデルの一覧を取得する。例えば、図18に示す展開対象イベント伝播モデル管理表を参照すると、ストレージ装置におけるディスクの状態異常というイベントが発生した場合、Rule2を展開する必要があることが分かる。
図13Bに示すイベント伝播モデルRule2は、観測イベントとして"ストレージ装置のボリュームの故障"、"ストレージ装置のRAIDグループの状態異常"、"ストレージ装置のディスクの状態異常"が定義されている。図15Bに示すトポロジ生成方式を参照すると、ストレージ装置のRAIDグループを起点とし、ストレージ装置のボリュームとストレージ装置のディスクを終点とするトポロジ生成方式TP2が定義されている。そこで、このトポロジ生成方式を利用してトポロジを取得する。
図10に示すRAIDグループ管理表(に相当する構成DBの項目)を参照し、ストレージ装置SYS1のディスクDISK1に着目すると、それに対応するRAIDグループはRG1となっている。よって、ストレージ装置SYS1のディスクDISK1に対応する起点となるストレージ装置のRAIDグループはRG1であることが分かる。次に、図24に示す展開済起点コンポーネント管理表を参照し、ストレージ装置SYS1のRAIDグループRG1が登録されているかどうかを検索し、登録されていなければステータスを「展開中」として新たに登録する。
次に、図7に示すボリューム管理表(に相当する構成DBの項目)を参照し、RAIDグループIDがRG1となっているボリュームを検索する。その結果検索されたストレージ装置SYS1のボリュームVOL1とVOL2が存在することが分かる。以上の結果、ストレージ装置のボリュームとRAIDグループとディスクを含むトポロジとして、ストレージ装置SYS1のディスクDISK1と、RAIDグループRG1と、ボリュームVOL1の組み合わせが存在する。
そこで、観測イベントとして"ストレージ装置SYS1のディスクDISK1の状態異常"と、"ストレージ装置SYS1のRAIDグループRG1の状態異常"と、"ストレージ装置SYS1のボリュームVOL1の故障"を検知した際、根本原因として"ストレージ装置SYS1のディスクDISK1の故障"を結論付けるパターンが展開結果となる。この展開結果を因果律行列の列として追加する。
上記の処理が終了した後、展開結果の結論イベントと、入力イベント以外の条件イベントについて、ルールオンデマンド展開処理実施する。上記の展開結果の場合、"ストレージ装置SYS1のボリュームVOL1の故障"というイベントについて、図18に示す展開対象イベント伝播モデル管理表を参照すると、Rule1を再展開する必要があることが分かる。そこで、Rule1について再度展開を行う。
以上の処理により、イベント伝播モデルRule1およびRule2に関する因果律行列が作成され、それぞれ図14Cおよび図14Dの状態となる。
この後、管理プログラムが"ストレージ装置SYS1のディスクDISK1における状態異常"というイベントを再度検知し、イベント解析処理モジュールからイベント伝播モデル展開モジュールに対し、当該イベントを指定してイベント伝播モデルオンデマンド展開処理を実行するよう指示した場合、イベント伝播モデル展開モジュールは展開済イベント管理表を参照し、処理起動時に指定されたイベントが存在するかどうかを検索する。展開済イベント管理表にイベントが存在し、イベントのステータスは「展開済」であるため、以降の処理を行わずにイベント伝播モデルオンデマンド展開処理を終了する。
あるいは、管理プログラムが"ストレージ装置SYS1のディスクDISK2における状態異常"というイベントを検知し、イベント解析処理モジュールからイベント伝播モデル展開モジュールに対し、当該イベントを指定してイベント伝播モデルオンデマンド展開処理を実行するよう指示した場合、イベント伝播モデル展開モジュールは展開済イベント管理表を参照し、処理起動時に指定されたイベントが存在するかどうかを検索する。展開済イベント管理表にイベントが存在しないため、イベント伝播モデル展開モジュールは展開対象イベント伝播モデル管理表を参照し、イベント伝播モデルRule2を展開する必要があると判断する。
図13Bに示すイベント伝播モデルRule2は、観測イベントとして"ストレージ装置のボリュームの故障"、"ストレージ装置のRAIDグループの状態異常"、"ストレージ装置のディスクの状態異常"が定義されている。図15Bに示すトポロジ生成方式を参照すると、ストレージ装置のRAIDグループを起点とし、ストレージ装置のボリュームとストレージ装置のディスクを終点とするトポロジ生成方式TP2が定義されている。そこで、このトポロジ生成方式を利用してトポロジを取得する。
図10に示すRAIDグループ管理表(に相当する構成DBの項目)を参照し、ストレージ装置SYS1のディスクDISK2に着目すると、それに対応するRAIDグループはRG1となっている。よって、ストレージ装置SYS1のディスクDISK2に対応する起点となるストレージ装置のRAIDグループはRG1であることが分かる。次に、図23に示す展開済起点コンポーネント管理表を参照すると、ストレージ装置SYS1のRAIDグループRG1が存在し、起点コンポーネントのステータスは「展開済」であるため、以降の処理を行わずにイベント伝播モデルオンデマンド展開処理を終了する。
なお、図29に示すように、計算機システム上に管理サーバ30000が複数台存在し、ストレージ装置20000、ホストコンピュータ10000、管理サーバ30000といった管理対象装置を分担して管理している場合、管理サーバ30000のイベント伝播モデル展開モジュール32500は、展開済イベント管理表33700に処理起動時に指定されたイベントが存在しない場合は、他の管理サーバ上の展開済イベント管理表を参照し、当該イベントが存在するかどうかを検索する。当該イベントが存在する場合、その管理サーバ上の因果律行列33300から、当該イベントに関連する行および列を収集し、自身の因果律行列にコピーする。
以上が、本実施例におけるイベント伝播モデルオンデマンド展開処理である。
以上本実施例によれば、管理プログラムは、イベント伝播モデルを展開する前に、検知したイベントおよび展開しようとするイベント伝播モデルに対応する結論コンポーネントを検索し、各結論コンポーネントのうち既にルール展開を完了したもの、あるいは展開中であるものについて記録することにより、同じイベント伝播モデルから同じ因果律行列を繰り返し生成することを抑止する。
その結果として、大規模システムを対象とし、オンデマンド展開方式を採用する解析エンジンにおいて、同じ障害原因を持つ多数の障害を同時に受信した場合においても、イベント伝播モデルに基づく因果律行列の展開作業を効率化でき、管理サーバにかかる処理負荷を軽減しつつ適切に因果律行列の展開処理を実行できる。
実施例3では、管理プログラムのイベント伝播モデル展開モジュール32500が実施する、イベント伝播モデル展開処理について説明する。
実施例1においては、管理プログラムが装置から異常イベントを受信してからイベント伝播モデルオンデマンド展開処理を実行し、それが終了した後に障害解析を実施する。従って、イベントを受信してから障害解析を開始するまでの時間が、従来の事前展開方式に比べて長いという課題が存在する。一方、例えばストレージ内の物理的なコンポーネント(ポート、ディスクなど)にのみ関するイベント伝播モデルの場合、展開する際に取得するトポロジが変化する頻度は非常に低いため、従来の事前展開方式を採用しても構成変更により再展開を強いられる可能性は非常に低く、イベント受信後に障害解析をより迅速に開始するには、事前展開方式を採用する方が望ましい。
このような課題を解決するため、実施例3では管理サーバ30000におけるイベント伝播モデルオンデマンド展開処理およびイベント伝播モデル再展開処理を変更する。実施例3の管理サーバ30000が具備するイベント伝播モデル管理表33900を図25に、管理サーバ30000が実行する処理フローを図26乃至図28に示す。なお、管理サーバ30000のその他の情報及びフローは実施例1又は2と同じである。
図25は、実施例3において管理サーバ30000の具備するイベント伝播モデル管理表33900の構成例を示す図である。
イベント伝播モデル管理表33900は、イベント伝播モデルの識別子となるイベント伝播モデルIDを登録するフィールド33910と、前記イベント伝播モデルの展開に用いる方式を登録するフィールド33920と、を構成項目として含んでいる。
図25には、管理サーバの具備するイベント伝播モデル管理表の具体的な値の一例を示している。つまり、イベント伝播モデルIDがRule1で示されるイベント伝播モデルについては、事前展開方式によって展開することを示している。
本実施例において管理サーバ30000が実行するイベント伝播モデルオンデマンド展開処理の処理方式を図26に示す。なお、管理サーバ30000が実行するその他の処理は、実施例1と変わらない。
図26に、実施例3における、管理サーバ30000のイベント伝播モデル展開モジュール32500が実施するイベント伝播モデルオンデマンド展開処理のフローチャートを示す。実施例1の図20で説明したフローと異なる点はステップ65021及びステップ65022が追加されたことである。以下、追加された部分のみ説明する。
イベント伝播モデル展開モジュール32500はイベント伝播モデル管理表33900を参照し、イベント伝播モデルの展開方式を取得する(ステップ65021)。展開方式が「オンデマンド展開」であった場合(ステップ65022)、ステップ65030を実行する。
図28に、実施例3における、管理サーバ30000のイベント伝播モデル展開モジュール32500が実施するイベント伝播モデル展開処理のフローチャートを示す。なお、処理は実施例1で説明した図21の処理のステップ66020とステップ66030との間で実行される。
イベント伝播モデル展開モジュール32500は、イベント伝播モデルリポジトリ33200に定義された全てのイベント伝播モデルに対し、ステップ63022乃至63060の処理を繰り返す(ステップ63020)。
イベント伝播モデル展開モジュール32500は、イベント伝播モデル管理表33900を参照し、イベント伝播モデルの展開方式を取得する(ステップ63021)。展開方式が「事前展開」であった場合(ステップ63022)、以下の処理を実行する。
イベント伝播モデル展開モジュール32500は、トポロジ生成方式リポジトリ33400を参照し、イベント伝播モデルに対応したトポロジ生成方式をトポロジ生成方式リポジトリ33400より取得する(ステップ63030)。
該当するトポロジ生成方式がトポロジ生成方式リポジトリにあれば(ステップ63040)、イベント伝播モデル展開モジュール32500は、取得したトポロジ生成方式を元に構成DB33500からトポロジを取得し(ステップ63050)、取得したトポロジを用いてイベント伝播モデルを展開し、因果律行列33300に追加する(ステップ63060)。
以上が、イベント伝播モデル展開モジュール32500が実施するイベント伝播モデル展開処理である。
なお、本実施例ではイベント伝播モデル毎にオンデマンド展開方式と事前展開方式のどちらを用いるかを定義していたが、例えば管理対象装置ごとに前記の定義をしても構わない。即ち、障害発生後即座に根本原因を求めたい重要な装置については事前展開方式を、その他の装置についてはオンデマンド展開方式を採用するというように使い分けることができる。
以上本実施例によれば、管理プログラムのイベント伝播モデル管理表に登録されたポリシーに基づき、個々のイベント伝播モデルについて、実施例1で述べたオンデマンド展開方式と、事前展開方式のどちらを用いるかを選択することができる。結果として、イベント伝播モデルの性質や、解析作業のリアルタイム性をどの程度求めるかによって両方式を使い分けることができる。
特許請求の範囲に記載したもののほか、本発明の観点の代表的なものとして、次のものが挙げられる。
1.管理プログラムを格納した記憶資源と、
前記管理プログラムを実行するプロセッサと、
を含む、複数の管理対象計算機を管理する管理計算機であって、
前記記憶資源は、
(1)前記複数の管理対象計算機又は前記複数の管理計算機が含む複数のコンポーネントである複数の管理オブジェクトに関し、前記複数の管理オブジェクト同士の関係を示すトポロジと、
(2)イベント種別及びイベントが発生する管理オブジェクトの種別によって定義される、イベントと当該イベント発生原因となる原因イベントとの組の情報を含むイベント伝播モデルと、
(3)一つ以上の因果律を含む因果律情報と、
を格納し、
前記因果律とは、種別が種別1である第1の管理オブジェクトで発生する、種別が種別Aである第1のイベントが原因で、種別が種別2である第2の管理オブジェクトで種別が種別Bである第2のイベントが発生すること、を示し、
前記管理プログラムは、前記プロセッサに、
(A)所定の管理オブジェクトで発生した問題に関するイベントを検知させ、
(B)前記検知イベントの解析に用いる第1の因果律が前記因果律情報に生成済みか判断させ、
(C)(B)で未生成と判断した場合、前記トポロジと前記イベント伝播モデルに基づいて前記第1の因果律を前記因果律情報に生成するオンデマンド展開をさせ、
(D)前記第1の因果律を用いて、前記検知イベントを解析させる、
ことを特徴とした管理計算機。
2.上記1.記載の管理計算機であって、
前記管理プログラムは、前記プロセッサに、
前記検知イベント以外の、解析した前記第1の因果律に含まれるイベントの解析に用いる第2の因果律が、前記因果律情報に生成済みか判断させ、未生成と判断した場合、前記第2の因果律に関してオンデマンド展開をさせる、
ことを特徴とした管理計算機。
3.上記1.または2.に記載の管理計算機であって、
前記記憶資源は、
(4)前記イベント伝播モデルに対応する因果律の作成を事前に実行するか否かを示す、イベント伝播モデル管理情報、
を格納し、
前記管理計算機がイベントを検知する前に、前記管理プログラムは、前記プロセッサに、
(E)前記イベント伝播モデル管理情報に基づいて、前記因果律を事前に作成するか否か判断させる、
ことを特徴とした管理計算機。
4.上記1.乃至3.のいずれか1つに記載の管理計算機であって、
前記記憶資源は、
(5)前記管理オブジェクトに対応する因果律の作成を事前に実行するか否かを示す事前展開可否情報、
を格納し、
前記管理計算機がイベントを検知する前に、前記管理プログラムは、前記プロセッサに、
(F)前記事前展開可否情報に基づいて、前記所定の管理オブジェクトに対応する前記因果律を事前に作成させるか否か判断させる、
ことを特徴とした管理計算機。
5.上記1.乃至4.のいずれか1つに記載の管理計算機であって、
前記記憶資源は、
(6)前記検知イベントに関する解析有効期間、
を格納し、
前記解析有効期間後に、前記管理プログラムは、前記プロセッサに、
(G)前記検知イベントに対応する前記第1の因果律を前記因果律情報から削除させる、
ことを特徴とした管理計算機。
6.上記1.乃至5.のいずれか1つに記載の管理計算機であって、
前記管理プログラムは、前記プロセッサに、
(H)前記第1の因果律が示す原因イベントと同じ原因を持つ他の因果律のオンデマンド展開を、前記第1の因果律に関するオンデマンド展開中は抑止させる、
ことを特徴とした管理計算機。
7.複数の管理対象計算機を管理する記憶資源を含む管理計算機によるイベント解析方法であって、
前記記憶資源に、
(1)前記複数の管理対象計算機又は前記複数の管理計算機が含む複数のコンポーネントである複数の管理オブジェクトに関し、前記複数の管理オブジェクト同士の関係を示すトポロジと、
(2)イベント種別及びイベントが発生する管理オブジェクトの種別によって定義される、イベントと当該イベント発生原因となる原因イベントとの組の情報を含むイベント伝播モデルと、
(3)一つ以上の因果律を含む因果律情報と、
を格納し、
前記因果律とは、種別が種別1である第1の管理オブジェクトで発生する、種別が種別Aである第1のイベントが原因で、種別が種別2である第2の管理オブジェクトで種別が種別Bである第2のイベントが発生すること、を示し、
(A)所定の管理オブジェクトで発生した問題に関するイベントを検知し、
(B)前記検知イベントの解析に用いる第1の因果律が前記因果律情報に生成済みか判断し、
(C)(B)で未生成と判断した場合、前記トポロジと前記イベント伝播モデルに基づいて前記第1の因果律を前記因果律情報に生成するオンデマンド展開し、
(D)前記第1の因果律を用いて、前記検知イベントを解析する、
ことを特徴とした方法。
8.上記7.記載のイベント解析方法であって、
前記検知イベント以外の、解析した前記第1の因果律に含まれるイベントの解析に用いる第2の因果律が、前記因果律情報に生成済みか判断し、未生成と判断した場合、前記第2の因果律に関してオンデマンド展開する、
ことを特徴とした方法。
9.上記7.または8.に記載のイベント解析方法であって、
前記記憶資源に、
(4)前記イベント伝播モデルに対応する因果律の作成を事前に実行するか否かを示す、イベント伝播モデル管理情報、
を格納し、
(E)前記管理計算機がイベントを検知する前に、前記イベント伝播モデル管理情報に基づいて、前記因果律を事前に作成させるか否か判断する、
ことを特徴とした方法。
10.上記7.乃至9.のいずれか1つに記載のイベント解析方法であって、
前記記憶資源に、
(5)前記管理オブジェクトに対応する因果律の作成を事前に実行するか否かを示す事前展開可否情報、
を格納し、
(F)前記管理計算機がイベントを検知する前に、前記事前展開可否情報に基づいて、前記所定の管理オブジェクトに対応する前記因果律を事前に作成させるか否か判断する、
ことを特徴とした方法。
11.上記7.乃至10.のいずれか1つに記載のイベント解析方法であって、
前記記憶資源に、
(6)前記検知イベントに関する解析有効期間、
を格納し、
(G)前記解析有効期間後に、前記検知イベントに対応する前記第1の因果律を前記因果律情報から削除する、
ことを特徴とした方法。
12.上記7.乃至11.のいずれか1つに記載のイベント解析方法であって、
(H)前記第1の因果律が示す原因イベントと同じ原因を持つ他の因果律のオンデマンド展開を、前記第1の因果律に関するオンデマンド展開中は抑止する、
ことを特徴とした方法。
13.複数の管理対象計算機と、
前記複数の管理対象計算機を管理し、記憶資源を有する管理計算機と、
を有する計算機システムであって、
前記記憶資源は、
(1)前記複数の管理対象計算機又は前記複数の管理計算機が含む複数のコンポーネントである複数の管理オブジェクトに関し、前記複数の管理オブジェクト同士の関係を示すトポロジと、
(2)イベント種別及びイベントが発生する管理オブジェクトの種別によって定義される、イベントと当該イベント発生原因となる原因イベントとの組の情報を含むイベント伝播モデルと、
(3)一つ以上の因果律を含む因果律情報と、
を格納し、
前記因果律とは、種別が種別1である第1の管理オブジェクトで発生する、種別が種別Aである第1のイベントが原因で、種別が種別2である第2の管理オブジェクトで種別が種別Bである第2のイベントが発生すること、を示し、
前記管理計算機は、
(A)所定の管理オブジェクトで発生した問題に関するイベントを検知し、
(B)前記検知イベントの解析に用いる第1の因果律が前記因果律情報に生成済みか判断し、
(C)(B)で未生成と判断した場合、前記トポロジと前記イベント伝播モデルに基づいて前記第1の因果律を前記因果律情報に生成するオンデマンド展開し、
(D)前記第1の因果律を用いて、前記検知イベントを解析する、
ことを特徴とした計算機システム。
14.上記13.記載の計算機システムであって、
前記管理計算機は、
前記検知イベント以外の、解析した前記第1の因果律に含まれるイベントの解析に用いる第2の因果律が、前記因果律情報に生成済みか判断し、未生成と判断した場合、前記第2の因果律に関してオンデマンド展開する、
ことを特徴とした計算機システム。
15.上記13.または14.に記載の計算機システムであって、
前記記憶資源は、
(4)前記イベント伝播モデルに対応する因果律の作成を事前に実行するか否かを示す、イベント伝播モデル管理情報、
を格納し、
前記管理計算機がイベントを検知する前に、前記管理計算機は、
(E)前記イベント伝播モデル管理情報に基づいて、前記因果律を事前に作成するか否か判断する、
ことを特徴とした計算機システム。
16.上記13.乃至15.のいずれか1つに記載の計算機システムであって、
前記記憶資源は、
(5)前記管理オブジェクトに対応する因果律の作成を事前に実行するか否かを示す事前展開可否情報、
を格納し、
前記管理計算機がイベントを検知する前に、前記管理計算機は、
(F)前記事前展開可否情報に基づいて、前記所定の管理オブジェクトに対応する前記因果律を事前に作成させるか否か判断する、
ことを特徴とした計算機システム。
17.上記13.乃至16.のいずれか1つに記載の計算機システムであって、
前記記憶資源は、
(6)前記検知イベントに関する解析有効期間、
を格納し、
前記解析有効期間後に、前記管理計算機は、
(G)前記検知イベントに対応する前記第1の因果律を前記因果律情報から削除する、
ことを特徴とした計算機システム。
18.上記13.乃至17.のいずれか1つに記載の計算機システムであって、
前記管理計算機は、
(H)前記第1の因果律が示す原因イベントと同じ原因を持つ他の因果律のオンデマンド展開を、前記第1の因果律に関するオンデマンド展開中は抑止する、
ことを特徴とした計算機システム。