"計算機システムを管理する方法であって、前記計算機システムは、複数のノード装置と、前記複数のノード装置を管理するための管理装置とを含んでおり、前記管理装置は、少なくとも一つの所定の解析ルールと、前記管理装置が検知しうるイベントと前記所定の解析ルールとの対応関係を管理する対象イベント管理情報とを保持しており、前記所定の解析ルールは、障害の発生原因となる原因イベントと、前記原因イベントにより引き起こされる障害を示す関連イベントとの関係を定義しており、前記管理装置は、前記各ノード装置の構成変化をイベントとして検知した場合、そのイベントが前記対象イベント管理情報に登録されているか否かを判定し、検知された前記イベントが前記対象イベント管理情報に登録されている場合に、所定の処理を実行する、計算機システムの管理方法。前記管理装置は、前記複数のノード装置から構成情報を取得し、前記所定の処理は、検知された前記イベントと前記対象イベント管理情報に基づいて処理すべき前記解析ルールを特定し、特定された前記解析ルールを前記構成情報に適用して、障害解析のための情報を生成する処理である、請求項1に記載の計算機システムの管理方法。前記管理装置は、前記所定の解析ルールの内容に基づいて、前記対象イベント管理情報を作成して保持する、請求項2に記載の計算機システムの管理方法。前記管理装置は、前記各ノード装置間の接続関係を示すトポロジを生成するためのトポロジ生成方法を複数記憶するトポロジ生成情報を保持しており、前記所定の解析ルールに対応する所定のトポロジ生成方法を前記トポロジ生成情報から取得し、取得された前記所定のトポロジ生成方法に規定されているノード装置を、イベントの発生元として前記対象イベント管理情報に登録することにより、前記対象イベント管理情報を作成して保持する、請求項3に記載の計算機システムの管理方法。前記管理装置は、所定のタイミングで、前記対象イベント管理情報を作成して保持するようになっており、前記所定のタイミングとは、前記管理装置が初めて起動した場合、または、新しい前記所定の解析ルールが追加された場合、または、既存の前記所定の解析ルールが削除または変更された場合、の少なくともいずれか一つの場合である、請求項4に記載の計算機システムの管理方法。前記各ノード装置のいずれかにおいて障害が検出された場合、前記障害解析のための情報に基づいて、検出された前記障害の原因を推定する、請求項5に記載の計算機システムの管理方法。複数のノード装置を含む計算機システムを管理するための管理装置であって、マイクロプロセッサと、前記マイクロプロセッサにより実行される所定のコンピュータプログラム及び所定の情報を記憶する記憶装置と、前記マイクロプロセッサが前記各ノード装置と通信するための通信ポートを備え、前記記憶装置には、少なくとも一つの所定の解析ルールと、前記管理装置が検知しうるイベントと前記所定の解析ルールとの対応関係を管理する対象イベント管理情報とが格納されており、前記所定の解析ルールは、障害の発生原因となる原因イベントと、前記原因イベントにより引き起こされる障害を示す関連イベントとの関係を定義しており、前記マイクロプロセッサは、前記所定のコンピュータプログラムを実行することで、前記各ノード装置を監視し、前記各ノード装置の構成変化をイベントとして検知した場合、そのイベントが前記対象イベント管理情報に登録されているか否かを判定し、検知された前記イベントが前記対象イベント管理情報に登録されている場合に、所定の処理を実行する、計算機システムの管理装置。前記記憶装置には、前記複数のノード装置から取得した構成情報が格納され、前記所定の処理は、検知された前記イベントと前記対象イベント管理情報に基づいて処理すべき前記解析ルールを特定し、特定された前記解析ルールを前記構成情報に適用して、障害解析のための情報を生成する処理である、請求項7に記載の計算機システムの管理装置。前記マイクロプロセッサは、前記所定の解析ルールの内容に基づいて、前記対象イベント管理情報を作成して保持する、請求項8に記載の計算機システムの管理装置。前記記憶装置には、さらに、前記各ノード装置間の接続関係を示すトポロジを生成するためのトポロジ生成方法を複数記憶するトポロジ生成情報が格納されており、前記マイクロプロセッサは、前記所定の解析ルールに対応する所定のトポロジ生成方法を前記トポロジ生成情報から取得し、取得された前記所定のトポロジ生成方法に規定されているノード装置を、イベントの発生元として前記対象イベント管理情報に登録することにより、前記対象イベント管理情報を作成して保持する、請求項9に記載の計算機システムの管理装置。前記マイクロプロセッサは、所定のタイミングで、前記対象イベント管理情報を作成して保持するようになっており、前記所定のタイミングとは、前記管理装置が初めて起動した場合、または、新しい前記所定の解析ルールが追加された場合、または、既存の前記所定の解析ルールが削除または変更された場合、の少なくともいずれか一つの場合である、請求項10に記載の計算機システムの管理装置。計算機システム内の或る装置において障害が発生すると、その障害が原因となり、障害の発生した装置に接続された他の一つまたは複数の装置でも別の障害が発生する。この結果、計算機システム内で複数の障害が発見される。ホストコンピュータ、ネットワーク装置、ストレージ装置のような種々のノード装置を管理する管理ソフトウェアは、障害解析機能を有する。管理ソフトウェアは、解析機能を用いて、複数の障害のうち根本原因となる障害を管理者に提示する。障害解析機能を実現するための障害解析エンジンは、障害解析ノウハウに基づき定義された複数のイベント伝播モデルを持つ。管理ソフトウェアは、ノード装置の構成情報から装置間のトポロジを取得し、そのトポロジにイベント伝播モデルを当てはめる。管理ソフトウェアは、装置で生じた障害イベントと、その障害の根本原因となるイベントとの対応関係を表す、因果律行列を出力する。障害解析エンジンは、因果律行列を記憶領域に保持し、障害解析に利用する。計算機システムは、種々の理由で、新たなノード装置が追加されたり、既存のノード装置が取り外されたり、ノード装置の設定が変更されたりする。このように、計算機システムの構成は変化する。管理ソフトウェアは、保持している構成情報の変更を検知する度に、因果律行列を破棄する。管理ソフトウェアは、最新のトポロジに基づいてイベント伝播モデルを展開し、最新の構成に対応する因果律行列を新たに作成する。以後、計算機システムの構成が変化する度に、イベント伝播モデルの展開処理が実行される。しかし、管理ソフトウェアが検知する構成変更の中には、イベント伝播モデルを再展開する必要のない構成変更も含まれていると考えられる。従来技術では、イベント伝播モデルの再展開が不要な構成変更であっても、イベント伝播モデルを再展開しているため、管理ソフトウェアの処理負荷が増大する。例えば、大規模なデータセンタ等のような計算機システムでは、ノード装置の数が多いため、修理又は点検、増設または減設のために、比較的頻繁に構成が変化する。本発明は、上記の問題に鑑みてなされたもので、管理のための処理負荷を軽減できるようにした計算機システムの管理方法及び管理装置を提供することにある。本発明の一つの観点に係る計算機システムを管理する方法では、計算機システムは、複数のノード装置と、複数のノード装置を管理するための管理装置とを含んでいる。管理装置は、少なくとも一つの所定の解析ルールと、前記管理装置が検知しうるイベントと前記所定の解析ルールとの対応関係を管理する対象イベント管理情報とを保持している。所定の解析ルールは、障害の発生原因となる原因イベントと、原因イベントにより引き起こされる障害を示す関連イベントとの関係を定義している。管理装置は、各ノード装置の構成変化をイベントとして検知した場合、そのイベントが対象イベント管理情報に登録されているか否かを判定し、検知されたイベントが対象イベント管理情報に登録されている場合に、所定の処理を実行するようになっている。管理装置は、複数のノード装置から構成情報を取得し、所定の処理は、検知されたイベントと対象イベント管理情報に基づいて処理すべき解析ルールを特定し、特定された解析ルールを構成情報に適用して、障害解析のための情報を生成する処理であってもよい。例えば、計算機システムの具体的な構成に所定の解析ルールを当てはめて、障害を解析するための具体的な情報例えば後述の因果律行列を生成してもよい。管理装置は、所定の解析ルールの内容に基づいて、対象イベント管理情報を作成して保持してもよい。管理装置は、各ノード装置間の接続関係を示すトポロジを生成するためのトポロジ生成方法を複数記憶するトポロジ生成情報を保持しており、所定の解析ルールに対応する所定のトポロジ生成方法をトポロジ生成情報から取得し、取得された所定のトポロジ生成方法に規定されているノード装置を、イベントの発生元として対象イベント管理情報に登録することにより、対象イベント管理情報を作成して保持してもよい。管理装置は、所定のタイミングで、対象イベント管理情報を作成して保持するようになっており、所定のタイミングとは、管理装置が初めて起動した場合、または、新しい所定の解析ルールが追加された場合、または、既存の所定の解析ルールが削除または変更された場合、の少なくともいずれか一つの場合であってもよい。各ノード装置のいずれかにおいて障害が検出された場合、障害解析のための情報に基づいて、検出された障害の原因を推定してもよい。本発明は、計算機システムの管理方法、計算機システムを管理するためのコンピュータプログラムとして捉えることもできる。以下、添付図面を参照して本発明の実施形態について説明する。ただし、本実施形態は本発明を実現するための一例に過ぎず、本発明の技術的範囲を限定するものではないことに注意すべきである。本実施形態では、構成変更イベントが発生する毎に、再展開が必要なイベント伝播モデルを特定し、再展開が必要なイベント伝播モデルについてのみ展開を行なう。展開要否の判断には、展開対象イベント管理表を用いる。展開対象イベント管理表は、例えば、構成変更イベントのうち再展開処理が必要なイベントの種別と、再展開すべきイベント伝播モデルとを対応付けて定義する。本実施形態によれば、イベント伝播モデルの再展開処理が必要な構成変更イベントについてのみ、イベント伝播モデル再展開処理を実施できる。従って、システムを管理する処理の負荷を軽減できる。さらに、本実施形態では、管理者がイベント伝播モデルを追加もしくは削除した場合、展開対象イベント管理表の内容は自動的に更新される。なお、本明細書では、実施形態において使用される情報を、aaa表という表現で説明しているが、これに限らず、例えば、aaaリスト、aaaデータベース、aaaキュー等の他の表現を用いてもよい。本実施形態で用いられる情報が、データ構造に依存しないことを示すために、aaa情報と呼ぶこともある。本実施形態で使用される情報の内容を説明する際に、識別情報、識別子、名、名前、IDという表現を用いることがあるが、これらは互いに置換が可能である。さらに、本実施形態の処理動作の説明では、コンピュータプログラムまたはモジュールを動作主体主語として説明することがある。プログラムまたはモジュールは、マイクロプロセッサによって実行される。プログラムまたはモジュールは、定められた処理を、メモリ及び通信ポート通信制御装置を用いながら実行する。従って、プロセッサを動作主体主語として読み替えても良い。プログラムまたはモジュールを主語として開示された処理は、管理サーバ等の計算機等が行う処理として読み替えてもよい。さらに、コンピュータプログラムの一部または全ては、専用ハードウェアによって実現されてもよい。コンピュータプログラムは、プログラム配布サーバまたは記憶メディアによって計算機にインストールされてもよい。図1~図5は、計算機システムの全体構成および計算機システムに接続される各装置の構成を示す。図6~図14は、各装置の備える管理用の情報を示す。図1は、計算機システムの物理的構成を示す図である。計算機システムは、例えば、ホストコンピュータ10と、ストレージ装置20と、管理サーバ30と、IPスイッチ40と、ウェブサーバ50と、を有する。各装置10,20,30,40,50は、通信ネットワーク60によって通信可能に接続されている。ホストコンピュータ101,102は、例えば、図示しないクライアントコンピュータからファイルのIO要求を受信し、そのIO要求に基づいてストレージ装置201,202にアクセスする。管理サーバ管理計算機30は、計算機システム全体の運用を管理する。なお、特に区別する必要がない場合、ホストコンピュータ101,102をホストコンピュータ10と呼び、ストレージ装置201,202をストレージ装置20と呼ぶ。ウェブサーバ50は、通信ネットワーク60を介して、管理サーバ30のGUIGraphicalUserInterface表示処理モジュールP33と通信し、WEBブラウザに各種情報を表示させる。ユーザは、ウェブサーバ50のWEBブラウザに表示された情報を参照することで、計算機システム内の各装置10,20,40を管理する。なお、ウェブサーバ50に代えて、携帯電話または携帯情報端末のような携帯型の計算機を用いて、管理サーバ30の提供する情報を参照したり、管理サーバ30に指示を与えたりする構成でもよい。管理サーバ30とウェブサーバ50とを一つのサーバに設ける構成でもよい。さらに、ホストコンピュータ10に、管理サーバ30の機能およびウェブサーバ50の機能のうち少なくともいずれか一方の機能を設ける構成でもよい。図2は、ホストコンピュータ10の内部構成例を示す。ホストコンピュータ10は、例えば、通信ポート100と、プロセッサ図中CPU110と、メモリ120と、を備える。これら100,110,120は、内部バス等を介して接続される。通信ポート以下、ポート100は、通信ネットワーク60を介して通信するための回路である。プロセッサ110は、メモリ120に記憶された各種コンピュータプログラムを読み込んで実行する。メモリ120には、例えば、アプリケーションプログラムP11と、オペレーティングシステムP10と、論理ボリューム管理表T10と、が格納される。メモリ120には、例えば、フラッシュメモリデバイスまたはハードディスクドライブのような記憶装置を含めてもよい。アプリケーションプログラムP11は、オペレーティングシステムP10から提供された記憶領域を使用して、その記憶領域にデータを入出力する。アプリケーションプログラムアプリケーションと略記する場合もあるP10は、例えば、顧客管理プログラム、売上げ管理プログラム、動画像配信プログラムなどのように構成され、図外のクライアントコンピュータにサービスを提供する。オペレーティングシステムP10は、ホストコンピュータ10に接続されたストレージ装置20の論理ボリューム232図3参照を記憶領域として、アプリケーションプログラムP11に認識させる。図2では、IOポートと管理ポートの両方を含むポート100として表現しているが、IOポートと管理ポートとを別々に設ける構成でもよい。IOポートとは、ストレージ装置20とiSCSIにより通信を行うための通信ポートである。管理ポートとは、管理サーバ30がホストコンピュータ10内の管理情報を取得するための通信ポートである。図3は、ストレージ装置20の内部構成例を示す。ストレージ装置20は、例えば、IOポート2001,2002と、管理ポート201と、コントローラ2101,2102と、管理メモリ220と、記憶装置230とを備える。これら200,201,210,220,230は、内部バス等で接続される。IOポート2001,2002は、通信ネットワーク60を介してホストコンピュータ10に接続するための通信ポートである。区別しない場合、IOポート200と呼ぶ。管理ポート201は、通信ネットワーク60を介して管理サーバ30に接続するための通信ポートである。コントローラ2101,2102は、ストレージ装置20の動作を制御するための装置である。区別しない場合、コントローラ2101,2102をコントローラ210と呼ぶ。各コントローラ210は、その内部に、ストレージ装置20の動作を制御するためのプロセッサと、ホストコンピュータ10との間で送受信するデータを一時的に記憶するキャッシュメモリとを備える。各コントローラ210は、IOポート200とRAIDグループ231の間に介在し、両者の間でデータを受け渡す。コントローラ210は冗長構成を備えており、いずれか一方のコントローラが停止した場合でも、他方のコントローラがストレージ装置20の制御を受け継ぐことができる。RAIDグループ231は、1つまたは複数の記憶装置230を含む。複数の記憶装置230のそれぞれ有する物理的記憶領域をRAID構成として、RAIDグループ231を生成することもできる。RAIDグループ231には、論理的な記憶領域である、論理ボリューム232を一つ以上設けることができる。論理ボリューム232は、1つの記憶装置230の持つ物理的記憶領域に基づいて生成することもできる。この場合、その物理的記憶領域は、RAID構成である必要はない。記憶装置230としては、例えば、ハードディスクデバイス、半導体メモリデバイス、光ディスクデバイス、光磁気ディスクデバイス等のデータを読み書き可能な種々の記憶装置を利用可能である。記憶装置230としてハードディスクデバイスを用いる場合、例えば、FCFibreChannelディスク、SCSISmallComputerSystemInterfaceディスク、SATAディスク、ATAATAttachmentディスク、SASSerialAttachedSCSIディスク等を用いることができる。また、例えば、フラッシュメモリ、FeRAMFerroelectricRandomAccessMemory、MRAMMagnetoresistiveRandomAccessMemory、相変化メモリOvonicUnifiedMemory、RRAMResistanceRAM等の種々の記憶装置を用いることもできる。さらに、例えば、フラッシュメモリデバイスとハードディスクデバイスのように、種類の異なる記憶装置を混在させる構成でもよい。管理メモリ220には、例えば、ストレージ装置を管理する管理プログラムP20と、ボリューム管理表T20と、iSCSIターゲット管理表T21と、IOポート管理表T22と、RAIDグループ管理表T23と、が格納される。各管理表T20,T21,T22,T23の詳細は後述する。管理プログラムP20は、管理ポート201を経由して管理サーバ30と通信し、管理サーバ30にストレージ装置20の構成情報を提供する。なお、ストレージ装置20は、図3に示す構成に限らない。ストレージ装置20は、ストレージコントローラと、記憶装置を備えていればよい。ストレージコントローラは、例えば、ホストコンピュータ10に論理ボリュームを提供する機能と、ホストコンピュータ10からのアクセス要求IO要求に基づいてデータを読み書きする機能と、データを一時的に記憶する機能を備えていればよい。ストレージコントローラと記憶装置とは同一筐体に設けられている必要はなく、それぞれ別々の筐体に設けられてもよい。なお、ストレージ装置20をストレージシステムと呼び変えてもよい。図4は、管理サーバ30の内部構成例を示す。管理サーバ30は、例えば、管理ポート300と、プロセッサ310と、メモリ320と、二次記憶領域330と、出力装置340と、入力装置350とを有し、これら300-350が内部バス等の回路を介して相互に接続されている。管理ポート300は、通信ネットワーク60を介して管理サーバ30と通信する回路である。プロセッサ310は、後述する各ソフトウェアモジュールP30-P35を読み込んで実行する。出力装置340は、例えば、ディスプレイ、プリンタ、スピーカー等から構成される。出力装置340は、後述の処理結果を出力する。入力装置350は、例えば、キーボード、マウス、タッチパネル、マイクロフォン等から構成される。管理者ストレージ管理者は、入力装置350を介して、管理サーバ30に指示を与える。メモリ320には、例えば、プログラム制御モジュールP30と、構成情報取得モジュールP31と、状態取得モジュールP32と、GUI表示処理モジュールP33と、イベント解析処理モジュールP34と、イベント伝播モデル展開モジュールP35と、が格納されている。各モジュールの詳細は後述する。図中では、便宜上、モジュールの名称を一部省略して表示することがある。例えば、イベント解析処理モジュールP34は、図中では、イベント解析モジュールとして表示されている。なお、図4では、各モジュールは、メモリ320に記憶されるソフトウェアモジュールとして提供されているが、これに代えて、各モジュールをハードウェアモジュールとして生成してもよい。さらに、各モジュールの行う処理が一つ以上のプログラムコードとして提供されても良い。さらに、モジュール間の明確な境界が存在しなくても良い。二次記憶領域330には、例えば、イベント管理表T30と、イベント伝播モデルリポジトリT31と、因果律行列T32と、トポロジ生成方式リポジトリT33と、展開対象イベント管理表T34と、展開対象イベント伝播モデル管理表T35と、構成データベースT36と、が格納されている。説明の便宜上、イベント伝播モデルに符号T31を付したり、トポロジ生成方式に符号T33を付したりする場合がある。構成データベースT36には、構成情報取得モジュールP31が収集した各構成情報が記憶される。構成情報には、ホストコンピュータ10から取得される情報と、ストレージ装置20から取得される情報とがある。ホストコンピュータ10から取得される情報には、論理ボリューム管理表T10がある。ストレージ装置20から取得される情報には、ボリューム管理表T20と、iSCSIターゲット管理表T21と、IOポート管理表T22と、RAIDグループ管理表T23がある。二次記憶領域330は、例えば、フラッシュメモリデバイスまたはハードディスクドライブのいずれか一つまたは両方から構成することができる。二次記憶領域330に代えて、各管理表T30-T36をメモリ320に記憶させてもよい。二次記憶領域330に記憶されている管理表T30-T36の一部をメモリ320に記憶させてもよい。状態取得モジュールP32は、管理対象の各ノード装置ホストコンピュータ10,ストレージ装置20に定期的にアクセスし、各ノード装置内の各コンポーネントの状態を取得する。イベント解析処理モジュールP34は、因果律行列T32を参照し、状態取得モジュールP32が取得したノード装置の異常状態の、根本原因を解析する。GUI表示処理モジュールT33は、入力装置350を介した管理者からの要求に応じ、各ノード装置から取得した構成情報を、出力装置340を介して表示する。入力装置350と出力装置340とは別々な装置でもよいし、または、一つ以上のまとまった装置として構成されてもよい。なお、管理サーバ30は、1つのコンピュータから構成してもよいし、複数のコンピュータから構成してもよい。さらに、出力装置340及び入力装置350の代わりに、管理サーバ30に表示用計算機を接続してもよい。表示用計算機は、入力装置及び出力装置を備える。管理者は、表示用計算機を介して、管理サーバ30から情報を取得したり、管理サーバ30に指示を与えたりすることができる。表示用計算機と管理サーバ30とは、例えば、無線または有線で接続される。表示用計算機は、パーソナルコンピュータ、携帯電話、携帯情報端末として構成できる。本明細書では、計算機システム情報処理システムを管理し、表示用情報を表示する一つ以上の計算機の集合を管理システムと呼ぶことがある。管理サーバが表示用情報を表示する場合は、管理サーバが管理システムである。管理サーバと表示用計算機例えばウェブサーバ50の組み合わせも、管理システムである。管理処理の高速化または高信頼化のために複数の計算機で、管理サーバと同等の処理を実現してもよい。この場合は、それら複数の計算機表示を表示用計算機が行う場合は表示用計算機も含めてが、管理システムである。図5は、IPスイッチ40の構成を示す。IPスイッチ40は、例えば、プロセッサ410と、メモリ420と、IOポート4001,4002と、管理ポート401とを備え、これら410,420,400,401は、内部バス等を介して相互に接続されている。メモリ420には、例えば、制御プログラム及び各種管理情報いずれも不図示が格納される。プロセッサ410は、制御プログラムを実行して、IPスイッチ40の動作を制御する。IOポート4001,4002は、通信ネットワーク60を介してホストコンピュータ10に接続される。管理ポート401は、通信ネットワーク60を介して、管理サーバ30に接続される。図6A、図6B及び図6Cは、論理ボリューム管理表T10の構成例を示す。論理ボリューム管理表T10は、ホストコンピュータ10の使用する論理ボリュームを管理するための情報である。論理ボリューム管理表T10は、例えば、ドライブ名C100と、iSCSIイニシエータ名C101と、接続先iSCSIターゲットC102と、LUNIDC103の各フィールドを対応付けて管理する。ドライブ名C100は、ホストコンピュータ10内で各論理ボリューム232の識別子となるドライブ名を登録するためのフィールドである。iSCSIイニシエータ名C101は、iSCSIイニシエータ名を登録するフィールドである。iSCSIイニシエータは、論理ボリューム232の実体が存在するストレージ装置20との通信に用いられる、ホストコンピュータ10のIOポート100の識別子である。接続先iSCSIターゲットC102は、論理ボリューム232の実体が存在するストレージ装置20との通信に用いる、ストレージ装置20のIOポート200の識別子である。LUNIDC103は、ストレージ装置において論理ボリューム232の識別子となるLUNLogicalUnitNumberIDを登録するフィールドである。図6Aは、論理ボリューム管理表T10の具体的な値の一例を示す。図6Aの第1行目には、ホストコンピュータ上でEというドライブ名で示される論理ボリュームが記載されている。その論理ボリュームEは、comabcsv1というiSCSIイニシエータ名で示されるホストコンピュータ上のポート100と、comabcsto1というiSCSIターゲット名で示されるストレージ装置上のポート200とを介して、ストレージ装置20と接続されている。その論理ボリュームEには、0というLUNIDがストレージ装置上で与えられている。図7A及び図7Bは、ボリューム管理表T20を示す図である。ボリューム管理表T20は、ストレージ装置20内の各論理ボリューム232を管理する。ボリューム管理表T20は、例えば、ボリュームIDC200と、容量C201と、RAIDグループIDC202と、ターゲットIDC203と、LUNIDC204の各フィールドを対応付けて管理する。ボリュームIDC200は、ストレージ装置20の各論理ボリューム232の識別子である。容量C201は、各ボリューム232の容量である。RAIDグループIDC202は、各ボリューム232の属するRAIDグループ231の識別子である。ターゲットIDC203は、各ボリューム232の属するiSCSIターゲットの識別子である。LUNIDC204は、各ボリューム232のiSCSIターゲット内における識別子である。図7Aには、ボリューム管理表T20の具体的な値の一例が示されている。例えば、第1行目に着目すると、ボリューム232VOL1は、20GBの記憶領域を持ち、RAIDグループ231RG1に属する。さらに、そのボリューム232VOL1は、iSCSIターゲットIDTG1で特定されるiSCSIターゲットに属し、LUNID0を持つ。図8A及び図8Bは、iSCSIターゲット管理表T21を示す。iSCSIターゲット管理表T21は、ストレージ装置20内のiSCSIターゲットを管理する。iSCSIターゲット管理表T21は、例えば、ターゲットIDC210と、iSCSIターゲット名C211と、接続許可iSCSIイニシエータC212の各フィールドを対応付けて管理する。ターゲットIDC210は、iSCSIターゲットの識別子である。iSCSIターゲット名C211は、各iSCSIターゲットが持つiSCSIターゲット名である。接続許可iSCSIイニシエータC212は、iSCSIターゲットに接続が許可されたiSCSIイニシエータの名称である。つまり、フィールドC212には、iSCSIターゲットに属する論理ボリューム232に対してアクセスが許可された、ホストコンピュータ10のポート100の識別子となるiSCSIイニシエータ名が登録されている。図8Aには、iSCSIターゲット管理表T21の具体的な値の一例が示されている。第1行目に着目すると、ストレージ装置20のiSCSIターゲットHG1は、comabcsto1というiSCSIターゲット名を持つ。さらに、そのiSCSIターゲットHG1は、iSCSIイニシエータ名がcomabcsv1もしくはcomabcsv11である、ホストコンピュータ10のポート100からのアクセスを許可している。図9は、IOポート管理表T22の構成を示す。IOポート管理表T22は、ストレージ装置20のIOポート200を管理する。IOポート管理表T22は、例えば、ポートIDC220と、ターゲットIDC221との各フィールドを対応付けて管理する。ポートIDC220は、ストレージ装置20の各ポート200の識別子である。ターゲットIDC221は、ポート200の通信ネットワーク60上での識別子となるMACアドレスである。図9には、IOポート管理表の具体的な値の一例が示されている。第1行目に着目すると、ストレージ装置20のポート200PORT1は、TG1TG2というiSCSIターゲットIDで特定されるiSCSIターゲットによって、使用されている。図10は、RAIDグループ管理表T23の構成を示す。RAIDグループ管理表T23は、ストレージ装置20内の各RAIDグループ231を管理する。RAIDグループ管理表T23は、例えば、RAIDグループIDC230と、RAIDレベルC231と、容量C232の各フィールドを対応付けて管理する。RAIDグループIDC230は、各RAIDグループ231のストレージ装置内での識別子である。RAIDレベルC231は、RAIDグループ231のRAIDレベルである。RAIDレベルとしては、例えば、RAID1,RAID2,RAID3,RAID4,RAID5,RAID6などが知られている。容量C232は、RAIDグループ231の容量である。図10には、RAIDグループ管理表T23の具体的な値の一例が示されている。第1行目に着目すると、RAIDグループ231RG1は、RAIDレベルがRAID1であり、かつ、容量は100GBである。図11は、イベント管理表T30の構成例を示す図である。イベント管理表T30は、管理サーバ30の管理下にある各装置で発生したイベントを管理する。イベント管理表T30は、例えば、イベントIDC300と、装置IDC301と、部位IDC302と、パラメータC303と、状態C304と、処理済みフラグC305と、日時C306の各フィールドを対応付けて管理する。イベントIDC300は、イベントの識別子である。イベントの発生は、後述の通り、構成情報の変化に基づいて判断される。装置IDC301は、イベントの発生した装置機器の識別子である。部位IDC302は、装置内の、イベントの発生した部位を特定する識別子である。パラメータC303は、構成情報の変化を検知したパラメータの名称である。状態C304は、構成情報の変化の種別を示す。状態の種別としては、例えば、変更、追加、削除がある。処理済みフラグC305は、イベントが後述するイベント伝播モデル展開モジュールP35によって処理済みかどうかを示す。日時C306は、イベントが発生した日時である。例えば、第1行目1つ目のエントリに着目する。そこには、管理サーバ30が、ストレージ装置20SYS1のiSCSIターゲットTG1に接続可能なiSCSIイニシエータの変更をイベントEV1として検知したことが記録されている。図12A及び図12Bは、イベント伝播モデルリポジトリT31内のイベント伝播モデルの構成例を示す。イベント伝播モデルは、所定の解析ルールの一例である。一般的に、障害解析において根本原因を特定するためのイベント伝播モデルは、ある障害原因の結果発生することが予想されるイベントの組み合わせと、その根本原因とをIFTHEN形式で記載する。本実施形態では、便宜上、図12A及び図12Bに示すように、2つのイベント伝播モデルを説明する。その2つに限らず、更に多くのイベント伝播モデルルールが用意されてもよい。イベント伝播モデルは、例えば、モデルIDC310と、観測事象C311と、原因C312の各フィールドを対応付けて管理する。モデルIDC310は、イベント伝播モデルの識別子である。観測事象C311は、ある原因の結果として観測される、複数の関連したイベントを示す。観測事象は、IFTHEN形式で記載したイベント伝播モデルのIF部に相当する。原因C312は、観測事象のうち原因となる事象である。原因事象原因イベントは、IFTHEN形式で記載したイベント伝播モデルのTHEN部に相当する。結論部である原因C312のイベントが正常になれば、条件部である観測事象C311の状態も正常に戻るという関係にある。図12Aには、イベント伝播モデルの具体的な値の一例が示されている。或るイベント伝播モデルRule1では、ホストコンピュータ10上の論理ボリュームのERRORと、ストレージ装置20におけるIOポート200のERRORとを検知したとき、ストレージ装置20のIOポート200の故障が原因であると結論付ける。図13A、図13B、図13C、及び図13Dは、因果律行列T32の構成を示す。因果律行列T32は、計算機システムの各装置で生じる障害イベントの具体的な因果関係を規定する。因果律行列T32は、例えば、イベント伝播モデルIDC320と、観測事象C321と、原因事象C322と、因果関係C323の各フィールドを対応付けて管理する。イベント伝播モデルIDC320は、展開処理に使用したイベント伝播モデルの識別子である。観測事象C321には、管理サーバ30の状態取得モジュールP32が管理対象の各装置から受信しうるイベント障害イベントが登録される。原因事象C322には、障害イベントを受信した際に、イベント解析処理部P34が障害原因として結論付ける原因事象が登録される。因果関係C323には、どのイベントが受信された場合に、どのイベントを根本原因であると判断するかという対応関係が登録される。図13Aには、因果律行列T32の具体的な値の一例が示されている。例えば、ストレージ装置20SYS1のボリュームVOL1のERRORと、ホスト10HOST1の論理ボリュームEのERRORという2つのイベントが検知されると、ストレージ装置20SYS1のボリュームVOL1の故障が根本原因であると判断される。図14は、トポロジ生成方式リポジトリT33内のトポロジ生成方式の構成例を示す。トポロジ生成方式とは、管理対象の各装置から取得した構成情報に基づいて、管理対象の各装置間での接続関係トポロジを生成する方法を定義したものである。トポロジ生成方式は、例えば、トポロジIDC330と、起点コンポーネントC331と、終点コンポーネントC332と、経由コンポーネントC333と、トポロジ生成条件C334の各フィールドを対応付けて管理する。トポロジIDC330は、トポロジの識別子である。起点コンポーネントC331は、トポロジの起点となる、ノード装置内のコンポーネント種別である。終点コンポーネントC332は、トポロジの終点となる、ノード装置内のコンポーネント種別である。経由コンポーネントC333は、起点コンポーネントから終点コンポーネントまでの間のトポロジ生成の際に経由する、ノード装置内のコンポーネント種別である。トポロジ生成条件C334は、起点コンポーネントから終点コンポーネントまでの間のトポロジを生成する方法である。図14Aには、トポロジ生成方式T33の具体的な値の一例が示されている。図14Aには、ホストコンピュータ10の論理ボリュームを起点とし、ストレージ装置20のIOポート200を終点とし、かつ、ストレージ装置20のiSCSIターゲットを経由するトポロジが記載されている。そのトポロジは、論理ボリュームのiSCSIイニシエータ名がiSCSIターゲットの接続許可iSCSIイニシエータと等しく、かつ、IOポート200内のiSCSIターゲットIDがiSCSIターゲット内のIDと等しい組み合わせを検索することにより、取得可能である。図22のフローチャートを参照して、構成情報を取得する処理を説明する。構成情報取得処理は、管理サーバ30の構成情報取得モジュールP31により実施される。以下、ステップをSと略記することがある。プログラム制御モジュールP30は、所定のタイミングで、構成情報取得モジュールP31に対して構成情報取得処理の実行を指示する。所定のタイミングとしては、例えば、プログラム制御モジュールP30の起動時、または、前回の構成情報取得処理から一定時間経過後などを挙げることができる。なお、厳密に一定期間毎に指示が出される必要は無く、構成情報取得処理が繰り返し実行されていればよい。構成情報取得モジュールP31は、管理対象の各装置に対し、以下のS61-S66を繰り返すS60。まず最初に、構成情報取得モジュールP31は、管理対象の装置に対し、構成情報を送信するよう指示するS61。構成情報取得モジュールP31は、管理対象装置からの応答があったか否かを判定するS62。管理対象装置から構成情報が応答された場合S62:YES、構成情報取得モジュールP31は、取得した構成情報と構成データベースT36に格納された過去の構成情報とを比較するS63。管理対象装置から構成情報の応答がなかった場合S62:NO、構成情報取得処理を終了する。構成情報取得モジュールP31は、取得した構成情報と構成データベースT36に格納された過去の構成情報とに差分があるか否かを判定するS64。つまり、現在の構成情報と過去の構成情報とが異なるか否か判定する。現在の構成情報と過去の構成情報との間に差分がある場合S64:YES、構成情報取得モジュールP31は、差分のあった箇所をイベント化し、イベント管理表T30に登録するS65。イベント化するとは、差分の発生した構成をイベントとして取り扱うという意味である。構成情報取得モジュールP31は、S62で取得した構成情報現在の構成情報を、構成データベースT36に格納するS66。管理対象の全ての装置について上記の処理S61-S66が終了した後、構成情報取得モジュールP31は、イベント伝播モデルの再展開をすべきか否かを確認するための処理を実行させるS67。以上が、情報取得モジュールP31が実施する構成情報取得処理である。図15を参照して、本実施形態の特徴を備えない再展開要否確認処理を、本実施形態との相違を明らかにするために説明する。すなわち、図15のフローチャートは、比較例である。再展開要否確認処理とは、イベント伝播モデルを展開して因果律行列を作成し直すか否か判断するための処理である。図15に示す比較例の場合、イベント管理表T30に、未処理のイベントがあるか否かが判定されるS10。未処理イベントがある場合S10:YES、その未処理イベントの処理済みフラグC305の値はYESに変更されるS11。その後、図16に示すイベント伝播モデルを再展開する処理が実行されるS12。このように、本実施形態の特徴を備えない比較例においては、計算機システムの構成が変更されるたびに、一律に、イベント伝播モデルを再展開する処理が実行される。従って、管理サーバ30の処理負荷が増大する。図16のフローチャートを参照して、本実施形態の特徴を備えないイベント伝播モデル再展開処理を説明する。つまり、図16のフローチャートは、比較例である。最初に、因果律行列は全て削除されるS20。次に、イベント伝播モデルリポジトリに定義された全てのイベント伝播モデルに対し、以下の一連の処理S23-S24を繰り返すS21。イベント伝播モデルに対応したトポロジ生成方式がトポロジ生成方式リポジトリから取得されるS22。対応するトポロジ生成方式が取得できるとS23:YES、そのトポロジ生成方式に基づいて構成データベースからトポロジが取得されるS24。さらに、その取得されたトポロジにイベント伝播モデルを展開して、因果律行列に追加するS24。例えば、図12Aに示すイベント伝播モデルRule1は、観測事象としてホストコンピュータの論理ボリュームのERRORと、ストレージ装置のIOポートのERRORとが定義されている。図14Aに示すトポロジ生成方式を参照する。図14Aには、ホストコンピュータの論理ボリュームを起点コンポーネントとし、ストレージ装置のIOポートを終点コンポーネントとする、トポロジ生成方式TP1が定義されている。そこで、このトポロジ生成方式TP1を利用して、トポロジを取得する。図6Aに示す論理ボリューム管理表T10を参照し、ホストコンピュータ10HOST1の論理ボリュームEに着目する。論理ボリュームEのiSCSIイニシエータ名はcomabcsv1となっている。次に、図8に示すiSCSIターゲット管理表T21を参照し、接続先iSCSIイニシエータ名がcomabcsv1となっているiSCSIターゲットTG1を検索する。図9に示すIOポート管理表T22を参照し、iSCSIターゲットIDがTG1となっているIOポート200PORT1を検索する。以上の処理を行った結果、ホストコンピュータの論理ボリュームとストレージ装置のIOポートを含むトポロジの一つとして、ホストコンピュータ10HOST1の論理ボリュームEと、ストレージ装置20SYS1のIOポート200PORT1の組み合わせが検出される。そこで、新たな因果律行列が作成される。その因果律行列は、観測事象としてホストコンピュータ10HOST1の論理ボリュームEのERRORとストレージ装置20SYS1のIOポート200PORT1のERRORとが検知された場合、ストレージ装置20SYS1のIOポート200PORT1の故障が原因であるとする。上記の処理S22-S24を、論理ボリューム管理表T10に定義された、ホストコンピュータ10の論理ボリューム全てを起点コンポーネントとして実行する。以上が、比較例としてのイベント伝播モデル再展開処理である。このように、比較例では、管理対象装置の構成変化を検知する度に、イベント伝播モデルを再展開する。従って、大規模なデータセンタ等のように、管理サーバ30が管理する装置が多い場合、多数の構成変化が発生し、さらに、管理対象装置を管理するためのデータ量も増大する。この結果、イベント伝播モデルを再展開する処理が比較的頻繁に実行され、管理サーバ30に生じる処理負荷が増大する。そこで、本実施形態では、再展開要否確認処理とイベント伝播モデル再展開処理を、独自の思想に基づいて改善する。本実施形態に特有の展開対象イベント管理表T34を図17に示す。さらに、本実施形態に特有の展開対象イベント伝播モデル管理表T35を図18に示す。さらに、本実施形態による管理サーバ30の動作を図19及び図20に示す。展開対象イベント管理表T34は、管理者が手動で定義してもよいし、後述する第2実施例に示す方法により自動的に生成してもよい。図17は、対象イベント管理情報の一例としての展開対象イベント管理表T34の構成例を示す。展開対象イベント管理表T34は、イベント伝播モデルを展開する必要のあるイベントを管理する。展開対象イベント管理表T34は、例えば、機器種別C340と、コンポーネント種別C341と、パラメータC342と、イベント種別C343と、イベント伝播モデルIDC344の各フィールドを対応付けて管理する。機器種別C340は、構成変化イベントの発生した装置の種別である。コンポーネント種別C341は、構成変化イベントの発生した装置内のコンポーネントの種別である。パラメータC342は、構成情報の変化が検知されたパラメータの名称である。イベント種別C343は、構成情報の変化の種別である。構成情報の変化には、例えば、追加、削除、変更がある。それらの構成変化追加、削除、変更に係るイベントを、ここでは構成変化イベントと呼ぶ。イベント伝播モデルIDC344は、構成変化イベントに適用すべきイベント伝播モデルの識別子である。図17には、展開対象イベント管理表T34の具体的な値の一例が示されている。例えば、ストレージ装置のiSCSIターゲットへの接続が許可されたiSCSIイニシエータの値が変更にされた場合、その構成変化イベントについて、イベント伝播モデルRule1が再展開される。展開対象イベント管理表T34に記載されていないイベントが発生した場合、イベント伝播モデルの再展開は行われない。図18は、展開対象イベント伝播モデル管理表T35の構成例を示す。展開対象イベント管理表T35は、展開対象となるイベント伝播モデルを定義する。展開対象イベント伝播モデル管理表T35は、どのイベント伝播モデルが展開対象となるかを登録するフィールドを持つ。図18には、具体的な一例が示されている。或る一つのイベント伝播モデルRule1と他の一つのイベント伝播モデルRule2とが再展開の対象になっている。図19に、構成情報取得モジュールP31が実施する、再展開要否確認処理のフローチャートを示す。構成情報取得モジュールP31は、イベント管理表T30を参照し、未処理イベントがあるかどうかを確認するS30。未処理イベントとは、構成変化を示すイベントであって、処理済みフラグC305にNOと設定されているイベントである。未処理イベントがある場合S30:YES、構成情報取得モジュールP31は、その未処理イベントについて、ループ内の処理S32-S34を繰り返すS31。構成情報取得モジュールP31は、未処理イベントと同種のイベントが展開対象イベント管理表T34に登録されているかどうかを確認するS32。展開対象イベント管理表T34に未処理イベントと同種のイベントが存在する場合S32:YES、構成情報取得モジュールP31は、展開対象イベント管理表T34に定義された展開が必要なルールを、展開対象イベント伝播モデル管理表T35に登録するS33。最後に、構成情報取得モジュールP31は、未処理イベントの処理済みフラグC305をYESに変更するS34。以上の処理が終了した後、構成情報取得モジュールP31は、イベント伝播モデル展開モジュールP35に対して、図20に示すイベント伝播モデル再展開処理を行なうよう指示する。以上が、本実施形態による再展開要否確認処理である。本実施形態では、構成変化を示すイベントのうち展開対象イベント管理表T34に登録されているイベントについてのみ、イベント伝播モデル再展開処理の対象とする。従って、管理サーバ30の負担を軽減できる。図20に、イベント伝播モデル展開モジュールP35が実施するイベント伝播モデル再展開処理のフローチャートを示す。イベント伝播モデル展開モジュールP35は、展開対象イベント伝播モデル管理表T35に定義された全てのイベント伝播モデルに対し、以下の一連の処理S41-S44を繰り返すS40。なお、展開対象イベント伝播モデル管理表T35にIDが一つも登録されていない場合は、以下の処理S41-S44を行わずに、本処理を終了する。以下、処理対象のイベント伝播モデルを対象イベント伝播モデルと称する。イベント伝播モデル展開モジュールP35は、対象イベント伝播モデルのIDを持つ因果律行列T32を全て削除するS41。イベント伝播モデル展開モジュールP35は、トポロジ生成方式リポジトリT33を参照し、対象イベント伝播モデルに対応したトポロジ生成方式を、トポロジ生成方式リポジトリT33から取得するS42。対応するトポロジ生成方式がある場合S43:YES、イベント伝播展開モジュールP35は、そのトポロジ生成方式に基づいて構成データベースT36からトポロジを取得する。イベント伝播展開モジュールP35は、そのトポロジにイベント伝播モデルを適用し、因果律行列T32の列として追加するS44。イベント伝播展開モジュールP35は、展開対象イベント伝播モデル管理表T35に定義された全てのイベント伝播モデルに対して上記処理S41-S44が終了した後、展開対象イベント伝播モデル管理表T35に定義されたIDを全て削除するS45。以上が、イベント伝播モデル再展開処理である。以下、構成情報取得処理の具体例を示す。処理開始当初の、イベント伝播モデルT31Rule1に関する因果律行列T32は図13Aに、イベント伝播モデルT31Rule2に関する因果律行列T32は図13Cに、RAIDグループ管理表T23は図10に、iSCSIターゲット管理表T21は図8Aに、それぞれ示す通りであるものとする。プログラム制御モジュールP30は、管理者からの指示もしくはタイマーによるスケジュール設定に応じて、構成情報取得モジュールP31に対し、構成情報取得処理を実行するよう指示する。構成情報取得モジュールP35は、管理下の各装置に順番にログインし、装置の種別に応じた構成情報を送信するよう指示する。上記の処理が終了した後、構成情報取得モジュールP35は、構成データベースT36に格納された過去の構成情報と、管理対象の各装置から取得した現在の構成情報とを比較し、イベント管理表T30を更新する。ここでは、図11のイベント管理表T30の1行目に示す通り、ストレージ装置20SYS1のiSCSIターゲットTG1に接続を許可されたiSCSIイニシエータが変更されたケースを想定する。なお、変更後のiSCSIターゲット管理表T21を図8Bに示す。構成情報取得モジュールP31は、イベント管理表T30に定義されたイベントに対して、以下の処理を行う。まず最初に、構成情報取得モジュールP31は、展開対象イベント管理表T34を参照し、イベント管理表T30に登録されたイベントと同種のイベントが定義されているかどうかを確認する。ここでいう同種とは、装置種別、装置内のコンポーネント種別、パラメータの名称、状態変化の種別の全てが等しいことを表す。展開対象イベント管理表T34に同種イベントが存在する場合、構成情報取得モジュールP31は、展開対象イベント管理表T34のイベント伝播モデルIDC344に定義されたルールイベント伝播モデルを、展開対象イベント伝播モデル管理表T35に登録する。例えば、図17に示す展開対象イベント管理表T34には、再展開が必要なイベントの種別の一つとして、ストレージ装置のiSCSIターゲットに接続が許可されたiSCSIイニシエータの変更が定義されている。構成情報取得モジュールP31は、そのイベント種別に対応するイベント伝播モデルのIDRule1を、展開対象イベント伝播モデル管理表T35に登録する。上記の処理が終了した後、構成情報取得モジュールP31は、イベント伝播モデル展開モジュールP35に対し、イベント伝播モデル再展開処理を行なうよう指示する。イベント伝播モデル展開モジュールP35は、展開対象イベント伝播モデル管理表T35を参照し、展開対象イベント伝播モデル管理表T35に登録されたRule1について、再展開処理を行う。すなわち、イベント伝播モデル展開モジュールP35は、イベント伝播モデルIDがRule1となっている列を、因果律行列T32から削除する。次に、イベント伝播展開モジュールP35は、イベント伝播モデルRule1を展開し、因果律行列T32に追加する。展開の方法は、図20で述べた方法と同じである。以上の処理により、イベント伝播モデルRule1に関する因果律行列T32が更新され、図13Aに示す状態から図13Bに示す状態に変化する。次に、図11のイベント管理表T30の2行目に示す通り、ストレージ装置20SYS1の、ボリューム232VOL1の属するRAIDグループ231のIDが変更されたケースを想定する。変更後のボリューム管理表T20を図7Bに示す。イベント管理表T30に定義された構成変化に係るイベントに対して、以下の処理が実行される。展開対象イベント管理表T34が参照され、イベント管理表T30に定義されたイベントと同種のイベントが管理表T34に定義されているか否か確認される。展開対象イベント管理表T34に同種イベントが定義されている場合、展開対象イベント管理表T34のイベント伝播モデルIDC344に定義されたイベント伝播モデルルールは、展開対象イベント伝播モデル管理表T35に登録される。例えば、図17に示す展開対象イベント管理表T34には、再展開が必要なイベントの種別として、ストレージ装置のボリュームに関するRAIDグループIDの変更が定義されている。構成情報取得モジュールP31は、そのイベント種別に対応するイベント伝播モデルIDであるRule2を、展開対象イベント伝播モデル管理表T35に登録する。上記の処理が終了した後、構成情報取得モジュールP31は、イベント伝播モデル展開モジュールP35に対し、イベント伝播モデル再展開処理を行なうよう指示する。イベント伝播モデル展開モジュールP35は、展開対象イベント伝播モデル管理表T35を参照し、展開対象イベント伝播モデル管理表T35に登録されたRule2について、再展開処理を行う。すなわち、イベント伝播モデルIDがRule2となっている列は、因果律行列T32から削除される。次に、イベント伝播モデルRule2が展開され、因果律行列T32に追加される。展開の方法は、図20で述べた方法と同じである。以上の処理により、イベント伝播モデルRule2に関する因果律行列T32が更新され、図13Cに示す状態から図13Dに示す状態に変化する。ところで、図11のイベント管理表T30の3行目に示す通り、ストレージ装置20SYS1のボリューム232VOL5の容量が変更されたケースを想定する。容量変更イベントと同種のイベントは、展開対象イベント管理表T34に定義されていない。従って、構成情報取得モジュールP31は、イベント伝播モデル展開モジュールP35に対して、イベント伝播モデル再展開処理を指示しない。そのため、因果律行列T32は更新されない。本実施形態によれば、管理対象の装置に関する構成変更イベントが検知された場合に、構成変更イベント毎に再展開が必要なイベント伝播モデルを特定し、再展開が必要なイベント伝播モデルについてのみ展開を行なう。従って、本実施形態では、無駄な再展開処理を抑制して、管理サーバ30の処理負荷を軽減することができる。図21及び図23を参照して第2実施例を説明する。本実施例は、第1実施例の変形例に該当する。従って、第1実施例との相違を中心に説明する。本実施形態では、イベント伝播モデル展開モジュールP35が実施する、展開対象イベント管理表生成処理方法について説明する。図21のフローチャートに示すように、本実施形態では、イベント伝播モデル展開モジュールP35は、展開対象イベント管理表T34を自動的に生成する。以下、便宜上、展開モジュールP35と呼ぶことがある。展開対象イベント管理表T34を生成する処理は、所定のタイミングで実行できる。所定のタイミングとしては、例えば、管理サーバ30が初めて起動した場合、イベント伝播モデルリポジトリT31に新しいイベント伝播モデルが追加された場合、イベント伝播モデルリポジトリT31のイベント伝播モデルの一部が削除された場合などを挙げることができる。展開モジュールP35は、イベント伝播モデルリポジトリT31に定義された全てのイベント伝播モデルに対し、以下の一連の処理S51-S53を繰り返すS50。展開モジュールP35は、トポロジ生成方式リポジトリT33を参照し、イベント伝播モデルリポジトリT31を生成するためのトポロジ生成方式を取得するS51。展開モジュールP35は、トポロジ生成方式のうち、起点コンポーネント、終点コンポーネント、および経由コンポーネントに記載されたコンポーネントを全て抽出するS52。さらに、展開モジュールP35は、抽出した各コンポーネントとイベント伝播モデルIDとを、展開対象イベント伝播モデル管理表T34に追加するS52。その場合、展開モジュールP35は、イベント種別を追加、削除に設定し、かつ、パラメータは指定しない。次に、展開モジュールP35は、トポロジ生成条件に記載されたコンポーネントおよびパラメータを全て抽出するS53。さらに、展開モジュールP35は、それら各コンピュータ及び各パラメータを、イベント伝播モデルIDと一緒に、展開対象イベント伝播モデル管理表T34に追加するS53。その場合、展開モジュールP35は、イベント種別を変更に設定する。展開対象イベント管理表生成処理の具体例を以下に示す。展開モジュールP35は、イベント伝播モデルリポジトリT31に定義されたイベント伝播モデルについて、トポロジ生成方式リポジトリT33から、イベント伝播モデルの生成に利用するトポロジ生成方式を取得する。展開モジュールP35は、トポロジ生成方式のうち、起点コンポーネント、終点コンポーネント、および経由コンポーネントに記載されたコンポーネントを全て抽出し、展開対象イベント伝播モデル管理表T35に追加する。例えば、図12Aに示すように、イベント伝播モデルRule1は、ホストコンピュータ10の論理ボリュームと、ストレージ装置20のIOポートとから構成される。従って、そのイベント伝播モデルRule1についてのトポロジを取得するために、図14Aに示すトポロジ生成方式TP1が用いられる。トポロジ生成方式TP1において、起点コンポーネントはホストコンピュータ10の論理ボリュームであり、終点コンポーネントはストレージ装置20のIOポートであり、経由コンポーネントはストレージ装置20のiSCSIターゲットである。従って、図17に示すように、それぞれのコンポーネントを展開対象イベント管理表T34に追加する。その際、イベント種別C343の値には、追加、削除が設定される。適用ルールIDイベント伝播モデルIDC344の値には、Rule1が設定される。展開モジュールP35は、トポロジ生成方式のトポロジ生成条件C334に記載されたコンポーネントおよびパラメータを全て抽出し、展開対象イベント伝播モデル管理表T34に追加する。トポロジ生成方式TP1のトポロジ生成条件C334に記載されたコンポーネントおよびパラメータは、論理ボリュームのiSCSIイニシエータ名と、iSCSIターゲットに接続を許可されたiSCSIイニシエータと、IOポート200のiSCSIターゲットIDと、iSCSIターゲットのIDである。従って、展開モジュールP35は、それらを展開対象イベント管理表T34に追加する。その際、イベント種別C343は変更に設定され、適用ルールIDイベント伝播モデルIDC344はRule1に設定される。以上の処理により、展開対象イベント管理表T34が生成されて、図17に示す状態となる。本実施形態も第1実施形態と同様の効果を奏する。さらに、本実施形態では、イベント伝播モデルリポジトリT31に登録されたイベント伝播モデルに基づいて、展開対象イベント管理表T34を生成することができる。本実施形態では、例えば、管理者がイベント伝播モデルを追加もしくは削除した場合、展開対象イベント管理表T34を自動的に更新することができる。従って、管理サーバ30にかかる処理負荷を軽減しつつ、適切に因果律行列を生成できる。さらに、展開対象イベント管理表T34を自動的に生成できるため、管理者の手間を省くことができる。図23は、本実施形態の処理及び管理情報の関係を模式的に示す全体概念図である。管理サーバ30は、展開対象イベント管理表生成処理図21において、イベント伝播モデルT31とトポロジ生成方式T33とを参照し、展開対象イベント管理表T34を生成する。展開対象イベント管理表T34は、図17で説明した通り、構成変更の結果であるイベントと、イベントが発生した場合に再展開すべきイベント伝播モデルとの対応関係を管理する。一方、管理サーバ30は、再展開要否確認処理図19において、イベント管理表T30を参照し、未処理イベントの有無を確認する。管理サーバ30は、未処理イベントがある場合、展開対象イベント管理表T34を参照して、その未処理イベントについて再展開が必要なイベント伝播モデルを特定する。管理サーバ30は、特定されたイベント伝播モデルについてのみ、イベント伝播モデル再展開処理を実行する。なお、第1実施形態及び第2実施形態は、以下のように、コンピュータプログラムとして表現することもできる。コンピュータを、複数のノード装置を含む計算機システムを管理するための管理装置として機能させるためのコンピュータプログラムであって、前記コンピュータの備える記憶装置に、少なくとも一つの所定の解析ルールと、前記管理装置が検知しうるイベントと前記所定の解析ルールとの対応関係を管理する対象イベント管理情報とを格納し、前記所定の解析ルールは、障害の発生原因となる原因イベントと、前記原因イベントにより引き起こされる障害を示す関連イベントとの関係を定義しており、前記各ノード装置を監視する機能と、前記各ノード装置の構成変化をイベントとして検知した場合、そのイベントが前記対象イベント管理情報に登録されているか否かを判定する機能と、検知された前記イベントが前記対象イベント管理情報に登録されている場合に、所定の処理を実行させる機能とを、前記コンピュータに実現させるためのコンピュータプログラム。"