JP2011198262A - 計算機システムにおけるシステム管理方法、及び管理システム - Google Patents

Abstract

【課題】システムを構成する各装置の構成部品に対して適切な閾値の設定を可能にする。
【解決手段】管理ソフトウェアを用いて、管理対象機器に対し事前に性能監視のための閾値を設定し、性能取得値が閾値を超過した場合は性能障害イベントとして感知する。また、管理ソフトウェアは、管理機器における性能障害イベント相互間の因果関係を示す相関解析ルールを持つ。管理ソフトはイベントを検知した場合に障害原因解析処理を実施し、受信した複数のイベントの中から障害原因装置と、その障害により影響を受けた装置（影響装置）を特定する。
【選択図】図１

Description

本発明は、計算機システムにおけるシステム管理方法、及び管理システムに関し、例えば、ホストコンピュータ、ネットワークスイッチ、ストレージを含むシステムを管理するための技術に関するものである。

計算機システムを管理するソフトウェアにおいて、例えば特許文献１に示されるように、検知した複数の障害もしくはその兆候の中から、原因となる事象を検出することが行われている。より具体的には特許文献１の管理ソフトは、管理下機器における性能値の閾値超過をイベント化し、イベントDBに情報を蓄積する。また、この管理ソフトは、管理下機器において発生した複数の障害イベントの因果関係を解析するための解析エンジンを持っている。解析エンジンは、管理下機器のインベントリ情報を持つ構成DBにアクセスして、I/O系路上のパス上にある機器内構成要素を認識し、ホスト上の論理ボリュームの性能に影響を与えうる構成要素を「トポロジ」と呼ばれる一グループとして認識する。そして、この解析エンジンは、イベントが発生すると各トポロジに対し、事前に定められた条件文と解析結果からなる解析ルールを適用して展開ルールを構築する。展開ルールには、他装置における性能低下の原因である原因イベントと、それによって引き起こされている関連イベント群が含まれる。具体的には、ルールのTHEN部に障害の根本原因として記載されているイベントが原因イベント、IF部に記載されているイベントのうち原因イベント以外のものが関連イベントである。

一方で、性能障害を管理する技術としては特許文献２及び特許文献３の技術がある。
特許文献２は、所定のアプリケーションが実装された上位装置と、アプリケーションが使用する記憶領域を提供するストレージ装置と、上位装置及びストレージ装置間においてデータを通信するホストサーバと、を有する記憶システムを管理する技術を開示する。この特許文献２においては、あるストレージ装置内の記憶領域を参照しているホストコンピュータ群を、ストレージ装置とホストコンピュータ間のマッピング情報から検索して検出し、そのホストコンピュータ群の性能データのみに絞り込んだI/O競合のレポートを作成してシステム管理者に提示することで、ストレージ装置内のリソース上でI/Oの競合を引き起こしているホストコンピュータ群や性能のボトルネックとなっている部品の特定を容易にしている。

特許文献３は、所定のアプリケーションが実装された上位装置と、アプリケーションが使用する記憶領域を提供するストレージ装置と、上位装置及びストレージ装置間においてデータを通信するホストサーバと、を有する記憶システムを管理する技術を開示する。この特許文献３においては、ホストサーバ及びストレージ装置間のデータ経路上に存在する各性能情報収集対象の現在の性能値を収集し、アプリケーションについて予め設定された目標性能値と、アプリケーションの現在の性能値とに基づいて、性能問題の発生の有無を判定する。そして、各性能情報収集対象の現在の性能値と、性能問題発生の有無の判定結果とに基づいて、各性能情報収集対象の性能値の閾値を設定している。

米国特許７１０７１８５号公報 特開２００５−６２９４１号公報 特開２００７−３２８３９６号公報

特許文献２においては、システム性能管理ソフトにおける性能監視のための閾値を付与する際、必ずしも部品本来の性能を加味していない。部品本来の性能を考慮せずに閾値を設定すると、性能障害が発生してしないにも拘わらず警告が生成される、もしくは逆に性能障害が発生しても警告が生成されないといった事態が発生し、管理者を混乱させる可能性がある。このような事態を防ぐための対策としては、ユーザが管理対象機器固有の性能に即した閾値を算出し付与すればよい。

しかしながら、ユーザにとって、業務ホスト上論理ボリュームといったFront Endに位置する構成要素の性能要求は見積もりやすいが、Back Endに位置するストレージ・スイッチ等の性能要件の見積もりを行うことは難しい。

特許文献３においては、ホストサーバ及びストレージ装置間のデータ経路上に存在する各性能情報収集対象の現在の性能値を収集し、アプリケーションについて予め設定された目標性能値と、アプリケーションの現在の性能値とに基づいて、性能問題の発生の有無を判定し、各性能情報収集対象の現在の性能値と、性能問題発生の有無の判定結果とに基づいて、各性能情報収集対象の性能値の閾値を設定する技術について述べられている。

しかし、特許文献２及び３に開示の閾値に基づく性能障害管理技術は、特許文献１に開示されるようなルールに基いた原因事象を特定する管理ソフトウェアに適用する事が容易にできない。

本発明はこのような状況に鑑みてなされたものであり、システムを構成する各装置の構成部品に対して適切な閾値の設定を可能にする技術を提供するものである。

上記課題を解決するために、本発明では、管理ソフトウェアを用いて、管理対象機器に対し事前に性能監視のための閾値を設定し、性能取得値が閾値を超過した場合は性能障害イベントとして感知する。また、管理ソフトウェアは、管理機器における性能障害イベント相互間の因果関係を示す相関解析ルールを持つ。管理ソフトはイベントを検知した場合に障害原因解析処理を実施し、受信した複数のイベントの中から障害原因装置と、その障害により影響を受けた装置（影響装置）を特定する。

また、本発明におけるシステム管理ソフトウェアは、閾値を部品の性能キャパシティに合致したものとするための閾値再計算機能を持つ。閾値再計算機能は、上記障害原因解析において影響装置の特定がなされなかった場合、その障害原因装置と類推される機器の閾値をより厳しくする方向で補正する。また、閾値再計算機能は、上記障害原因解析において障害要因装置の特定がなされなかった場合、その障害原因装置と類推される機器の閾値を緩和する方向で補正する。

さらなる本発明の特徴は、以下本発明を実施するための形態および添付図面によって明らかになるものである。

本発明によれば、システム管理ソフトウェア管理下の機器に対し付与した性能管理のための閾値が、機器本来の性能キャパシティに合致したものとなり、結果として管理ソフトが管理者に対し、正確に性能障害警告を行うことができる。

本発明における計算機システムの物理的概略構成例を示す図である。 本発明におけるホストコンピュータの詳細な構成例を示す図である。 本発明におけるストレージ装置の詳細な構成例を示す図である。 本発明における管理サーバの詳細な構成例を示す図である。 本発明において、例えばホストコンピュータ１が有する論理ボリューム管理表の構成例を示す図である。 本発明において、例えばホストコンピュータ２が有する論理ボリューム管理表の構成例を示す図である。 本発明において、例えばホストコンピュータ３が有する論理ボリューム管理表の構成例を示す図である。 本発明において、例えばホストコンピュータ１が有するiSCSIイニシエータ管理表の構成例を示す図である。 本発明において、例えばホストコンピュータ２が有するiSCSIイニシエータ管理表の構成例を示す図である。 本発明において、例えばホストコンピュータ３が有するiSCSIイニシエータ管理表の構成例を示す図である。 本発明においてストレージ装置が有するボリューム管理表の構成例を示す図である。 本発明においてストレージ装置が有するiSCSIターゲット管理表の構成例を示す図である。 本発明においてストレージ装置が有するI/Oポート管理表の構成例を示す図である。 本発明においてストレージが有するコントローラ管理表の構成例を示す図である。 本発明において管理サーバが有する装置性能管理表の構成例を示す図である。 本発明において管理サーバが有するボリュームトポロジ管理表の構成例を示す図である。 本発明において管理サーバが有するイベント管理表の構成例を示す図である。 本発明において管理サーバが有する汎用ルールの構成例（１）を示す図である。 本発明において管理サーバが有する汎用ルールの構成例（２）を示す図である。 本発明において管理サーバが有する展開ルールの構成例（１）を示す図である。 本発明において管理サーバが有する展開ルールの構成例（２）を示す図である。 本発明において管理サーバが有する展開ルールの構成例（３）を示す図である。 本発明において管理サーバが有する展開ルールの構成例（４）を示す図である。 管理サーバが実行する通常の性能情報取得処理の全体を説明するためのフローチャートである。 管理サーバが実行する通常の障害解析処理の全体を説明するためのフローチャートである。 本発明において管理サーバが有する解析結果管理表の構成例を示す図である。 本発明において管理サーバが有する閾値補正優先度管理表の構成例を示す図である。 本発明において管理サーバが有する閾値補正割合管理表の構成例を示す図である。 本発明の第１の実施形態において、管理サーバが実行する、改良された障害解析処理の全体を説明するためのフローチャートである。 第１の実施形態において、管理サーバが実行する閾値緩和処理の全体を説明するためのフローチャートである。 管理サーバが表示する閾値修正画面の構成例を示す図である。 本発明の第１の実施形態において、管理サーバが実行する閾値厳格化処理の全体を説明するためのフローチャートである。 本発明による第２の実施形態において、管理サーバが実行する測定値ベース閾値による閾値再設定処理の全体を説明するためのフローチャート（１）である 本発明による第２の実施形態において、管理サーバが実行する測定値ベース閾値による閾値再設定処理の全体を説明するためのフローチャート（２）である 本発明の第３の実施形態において、管理サーバが有する解析結果管理表の構成例を示す図である。 第３の実施形態において、管理サーバが実行する解析結果管理表構築処理の全体を説明するためのフローチャートである

以下、添付図面を参照して本発明の実施形態について説明する。ただし、本実施形態は本発明を実現するための一例に過ぎず、本発明の技術的範囲を限定するものではないことに注意すべきである。また、各図において共通の構成については同一の参照番号が付されている。

なお、本明細書では「ａａａ表」という表現によって本発明で用いられる情報について説明しているが、「ａａａテーブル」、「ａａａリスト」、「ａａａＤＢ」、「ａａａキュー」等の表現や、テーブル、リスト、ＤＢ、キュー、等のデータ構造以外で表現されていてもよい。このため、本発明で用いられる情報が、データ構造に依存しないことを示すために、「ａａａテーブル」、「ａａａリスト」、「ａａａＤＢ」、「ａａａキュー」等について「ａａａ情報」と呼ぶことがある。

また、各情報の内容を説明する際に、「識別情報」、「識別子」、「名」、「名前」、「ＩＤ」という表現を用いるが、これらについてはお互いに置換が可能である。

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

（１）第１の実施形態
第１の実施形態は、管理ソフトウェアによる閾値緩和処理及び閾値厳格化処理に関するものである。

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

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

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

＜ホストコンピュータの内部構成＞
図２は、本発明によるホストコンピュータ１００００の詳細な内部構成例を示す図である。ホストコンピュータ１００００は、ネットワーク４５０００に接続するためのポート１１０００と、プロセッサ１２０００と、メモリ１３０００（ディスク装置を含んでも良い）と、を有し、これらは内部バス等の回路を介して相互に接続される構成となっている。

メモリ１３０００には、業務アプリケーション１３１００と、オペレーティングシステム１３２００と、論理ボリューム管理表１３３００と、iSCSIイニシエータ管理表１３４００が格納されている。

業務アプリケーション１３１００は、オペレーティングシステム１３２００から提供された記憶領域を使用し、当該記憶領域に対しデータ入出力（以下、I/Oと表記）を行う。

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

ポート１１０００は、ストレージ装置２００００とiSCSIにより通信を行うためのI/Oポートと、管理サーバ３００００がホストコンピュータ内の管理情報を取得するための管理ポートを含む単一のポートとして図２で表現されているが、iSCSIにより通信を行うためのI/Oポートと管理ポートに分かれていてもよい。

なお、論理ボリューム管理表１３３００及びiSCSIイニシエータ管理表１３４００については後述する（図５及び６参照）。

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

ストレージ装置２００００は、ネットワーク４５０００を介してホストコンピュータ１００００に接続するためのI/Oポート２１０００及び２１０１０と、ネットワーク４５０００を介して管理サーバ３００００に接続するための管理ポート２１１００と、各種管理情報を格納するための管理メモリ２３０００と、データを格納するためのRAIDグループ２４０００乃至２４０１０と、データや管理メモリ内の管理情報を制御するためのコントローラ２５０００及び２５０１０と、を有し、これらが内部バス等の回路を介して相互に接続される構成となっている。なお、RAIDグループ２４０００乃至２４０１０の接続とは、より正確にはRAIDグループ２４０００乃至２４０１０を構成する記憶デバイスが他の構成物と接続されていることを指す。

管理メモリ２３０００には、ストレージ装置の管理プログラム２３１００と、ボリューム管理表２３２００と、iSCSIターゲット管理表２３３００と、ボリューム管理表２３４００と、コントローラ管理表２３５００が格納される。

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

なお、論理ボリューム２４１００及び２４１１０は、１つ以上の磁気ディスクの記憶領域を用いて構成されるのであれば、RAID構成を組まなくてもよい。さらに、論理ボリュームに対応する記憶領域を提供するのであれば、磁気ディスクの代わりとしてフラッシュメモリなど他の記憶媒体を用いた記憶デバイスでも良いものとする。

コントローラ２５０００及び２５０１０は、その内部に、ストレージ装置２００００内の制御を行うプロセッサや、ホストコンピュータ１００００との間でやりとりするデータを一時的に記憶するキャッシュメモリを持っている。そして、それぞれのコントローラは、I/OポートとRAIDグループの間に介在し、両者の間でデータの受け渡しを行う。

なお、ストレージ装置２００００は、何れかのホストコンピュータに対して論理ボリュームを提供し、アクセス要求(I/O要求を指す）を受信し、受信したアクセス要求に応じて記憶デバイスへの読み書きを行うストレージコントローラと、記憶領域を提供する前述の記憶デバイスを含めば、図３及び上記説明以外の構成でもよく、例えば、ストレージコントローラと記憶領域を提供する記憶デバイスが別な筐体に格納されていてもよい。即ち、図３の例では管理メモリ２３０００と、コントローラ２５０００及び２５１１０と、がストレージコントローラであってもよい。また、本明細書ではストレージコントローラと記憶デバイスが同じ筐体に存在する場合または別な筐体を含む表現として、ストレージ装置をストレージシステムと呼び変えても良い。

＜管理サーバの内部構成＞
図４は、本発明による管理サーバ３００００の詳細な内部構成例を示す図である。管理サーバ３００００は、ネットワーク４５０００に接続するための管理ポート３１０００と、プロセッサ３１１００と、取得情報リポジトリ３２０００と、記憶領域３３０００と、後述する処理結果を出力するためのディスプレイ装置等の出力デバイス３１２００と、ストレージ管理者が指示を入力するためのキーボード等の入力デバイス３１３００とを有し、これらが内部バス等の回路を介して相互に接続される構成となっている。

記憶領域３３０００には、プログラム制御モジュール３３１００と、構成管理情報取得モジュール３３２００と、装置性能取得モジュール３３３００と、GUI表示処理モジュール３３４００と、イベント解析処理モジュール３３５００と、ルール展開モジュール３３６００と、イベント管理表３３７００と、汎用ルールリポジトリ３３８００と、展開ルールリポジトリ３３９００と、解析結果管理表３４０００と、閾値補正優先度管理表３４１００と、閾値補正割合管理表３４２００と、取得情報リポジトリ３２０００と、が格納されている。なお、記憶領域３３０００は、半導体メモリまたは磁気ディスクのいずれか、もしくは半導体メモリおよび磁気ディスク両方から構成される。また、図４においては、各モジュールは、記憶領域３３０００のソフトウェアモジュールとして提供されているが、ハードウェアモジュールとして提供されるものであっても良い。また、各モジュールが行う処理が一つ以上のプログラムコードとして提供されても良く、モジュール間の明確な境界が存在しなくても良い。

取得情報リポジトリ３２０００には、装置性能管理表３２１００と、ボリュームトポロジ管理表３２２００が格納されている。

GUI表示処理モジュール３３４００は、入力デバイス３１３００を介した管理者からの要求に応じ、取得した構成管理情報を、出力デバイス３１２００を介して表示する。なお、入力デバイスと出力デバイスは別々なデバイスでもよく、一つ以上のまとまったデバイスでもよい。

なお、管理サーバ（管理計算機）は、例えば、入出力デバイスとして、ディスプレイとキーボードとポインタデバイス等を有しているが、これ以外の装置であってもよい。また、入出力デバイスの代替としてシリアルインターフェースやイーサーネットインターフェースを用い、当該インターフェースにディスプレイ又はキーボード又はポインタデバイスを有する表示用計算機を接続し、表示用情報を表示用計算機に送信したり、入力用情報を表示用計算機から受信することで、表示用計算機で表示を行ったり、入力を受け付けることで入出力デバイスでの入力及び表示を代替してもよい。

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

＜論理ボリューム管理表の構成＞
図５Ａ乃至Ｃは、ホストコンピュータ１００００が有する論理ボリューム管理表１３３００の構成例を示す図である。図５Ａ乃至Ｃに示されるように、この論理ボリューム管理表１３３００は、例えば、ホストコンピュータが複数ある場合にはホストコンピュータ毎に設けられ、それぞれ管理できるようになっている。

論理ボリューム管理表１３３００は、ホストコンピュータ内で各論理ボリュームの識別子となるドライブ名を登録するフィールド１３３１０と、論理ボリュームの実体が存在するストレージ装置との通信の際に用いるホストコンピュータ上のI/Oポート１１０００の識別子となるiSCSIイニシエータ名を登録するフィールド１３３２０と、論理ボリュームの実体が存在するストレージ装置との通信の際に用いるストレージ装置上のI/Oポート２１０００の識別子となる接続先iSCSIターゲットを登録するフィールド１３３３０と、ストレージ装置において論理ボリュームの識別子となるLUN IDを登録するフィールド１３３４０と、ホストコンピュータの業務アプリケーション１３２００から各論理ボリューム（ドライブ）へのI/Oの際の応答時間であるレスポンスタイム（現時点での瞬時的な値）を格納するためのフィールド１３３５０と、を構成項目として含んでいる。

例えば、図５Ａからは、ホストコンピュータ上で（E:）というドライブ名で示される論理ボリュームが、com.hitachi.sv1というiSCSIイニシエータ名で示されるホストコンピュータ上のポートと、com.hitachi.sto1というiSCSIターゲット名で示されるストレージ装置上のポートを介してストレージ装置と接続しており、０というLUN IDをストレージ装置上で持ち、現時点でのレスポンスタイムが５msecであったということが分かる。

＜iSCSIイニシエータ管理表の構成＞
図６Ａ乃至Ｃは、ホストコンピュータ１００００が有するiSCSIイニシエータ管理表１３４００の構成例を示す図である。iSCSIイニシエータも、ホストコンピュータが複数ある場合には、ホストコンピュータ毎に管理されている。

iSCSIイニシエータ管理表１３４００は、ホストコンピュータ１００００内で各ポート１１０００の識別子となるポートIDを登録するフィールド１３４１０と、ポートのネットワーク４５０００上での識別子となるMACアドレスを登録するためのフィールド１３４２０と、iSCSIイニシエータ名を登録するフィールド１３４３０と、を構成項目として含んでいる。

例えば、図６Ａからは、ホストコンピュータ上のポートLAN1は、11:11:11:11:11:11というMACアドレスを持ち、com.hitachi.sv1というiSCSIイニシエータ名を持っていることが分かる。

＜ボリューム管理表の構成＞
図７は、ストレージ装置２００００が有するボリューム管理表２３２００の構成例を示す。各ストレージ装置が同様のボリューム管理表を有している。

ボリューム管理表２３２００は、ストレージ装置内で各ボリュームの識別子となるボリュームIDを登録するフィールド２３２１０と、各ボリュームの容量を登録するフィールド２３２２０と、各ボリュームが所属するiSCSIターゲットの識別子となるターゲットIDを登録するフィールド２３２３０と、各ボリュームのiSCSIターゲット内での識別子となるLUN IDを登録するフィールド２３２４０と、各ボリュームへのI/Oの際の応答時間であるレスポンスタイムを格納するためのフィールド２３２５０と、を構成項目として含んでいる。

例えば、図７の第１行目（１つ目のエントリ）からは、ストレージ装置２００００上のボリュームVOL1は、20GBの記憶領域を持ち、TG1というiSCSIターゲットIDで示されるiSCSIターゲットに属し、０というLUN IDを持ち、現時点でのレスポンスタイムが５msecであったことが分かる。

＜iSCSIターゲット管理表の構成＞
図８は、ストレージ装置２００００の有するiSCSIターゲット管理表２３３００の構成例を示す図である。iSCSIターゲット管理表２３３００は、ストレージ装置内でiSCSIターゲットの識別子となるターゲットIDを登録するフィールド２３３１０と、各iSCSIターゲットが持つiSCSIターゲット名を登録するフィールド２３３２０と、各iSCSIターゲットに属するボリュームに対しアクセスが許可されたホストコンピュータ上のポートの識別子となるiSCSIイニシエータ名を登録するフィールド２３３３０と、を構成項目として含んでいる。

例えば、図８の第１行目（１つ目のエントリ）からは、ストレージ装置上のiSCSIターゲットTG1は、com.hitachi.sto1というiSCSIターゲット名を持ち、iSCSIイニシエータ名がcom.hitachi.sv1（例えば、ホストコンピュータ１に相当）もしくはcom.hitachi.sv11（例えば、ホストコンピュータ１１に相当）であるホストコンピュータ上のポートからのアクセスを許可していることが分かる。

＜I/Oポート管理表の構成＞
図９は、ストレージ装置２００００が有するI/Oポート管理表２３４００の構成例を示す図である。

I/Oポート管理表２３４００は、ストレージ装置内で各ポートの識別子となるポートIDを登録するフィールド２３４１０と、ポートのネットワーク４５０００上での識別子となるMACアドレスを登録するためのフィールド２３４２０と、ポートを使用するiSCSIターゲットの識別子となるターゲットIDを登録するフィールド２３４３０と、各ポートの単位時間当たりのI/O量を格納するためのフィールド２３４４０と、を構成項目として含んでいる。

例えば、図９の第１行目（１つ目のエントリ）からは、ストレージ装置上のポートPORT1が、22:22:22:22:22:11というMACアドレスを持ち、TG1（VOL1、2に対応）、TG2（VOL3、4に対応）というiSCSIターゲットIDで示されるiSCSIターゲットによって使用されていて、単位時間当たりのI/O量は300IOPSであることが分かる。TG1やTG2にアクセスする場合には、PORT１が用いられる。

＜コントローラ管理表の構成＞
図１０は、ストレージ装置２００００が有するコントローラ管理表２３５００の構成例を示す図である。

コントローラ管理表２３５００は、ストレージ内で各コントローラの識別子となるコントローラIDを登録するフィールド２３５１０と、コントローラと接続するポートの識別子となるポートIDを登録するためのフィールド２３５２０と、コントローラ内のプロセッサの稼働率を登録するためのフィールド２３５３０と、を構成項目として含んでいる。

例えば、図１０の第１行目（１つ目のエントリ）からは、ストレージ上のコントローラCTL1が、ポートPORT1と接続しており、現時点でのプロセッサの稼働率が60％であることが分かる。

＜装置性能管理表の構成＞
図１１は、管理サーバ３００００が有する装置性能管理表３２１００の構成例を示す図である。

装置性能管理表３２１００は、管理対象となる機器の識別子となる装置IDを登録するフィールド３２１１０と、管理対象機器内部のデバイスの識別子であるデバイスIDを登録するフィールド３２１２０と、管理対象デバイスの性能情報のメトリック名称を格納するフィールド３２１３０と、管理対象デバイスの性能値を該当装置から取得して格納するフィールド３２１４０と、管理対象デバイスの性能値の正常範囲の上限もしくは下限である閾値（アラート実行閾値）を、ユーザからの入力を受けて格納するフィールド３２１５０と、閾値（測定値ベース閾値）をイベント解析処理モジュール３３５００からの入力を受けて格納するフィールド３２１６０と、閾値が正常値の上限であるのか下限であるのかを登録するためのフィールド３２１７０と、性能値が正常値であるか異常値であるかを登録するためのフィールド３２１８０と、を構成項目として含んでいる。なお、フィールド３２１６０は、第２の実施形態で用いられる項目であるため、その詳細については後述する。

例えば、図１１の第１行目（１つ目のエントリ）からは、ストレージ装置SYS1内のコントローラCTL1におけるプロセッサの稼働率が現時点で４０％（３２１４０参照）であり、また、CTL1の稼働率が２０％を超えた場合（３２１５０参照）、管理サーバはコントローラCTL1が過負荷であるものと判断するが、当該具体例では本性能値が異常値であると判断されている（３２１８０参照）ことが分かる。

なお、ここでは管理サーバが管理するデバイスの性能値として単位時間当たりのI/O量や動作率を例として挙げたが、管理サーバが管理する性能値はこれ以外でも良い。

＜ボリュームトポロジ管理表の構成＞
図１２は、管理サーバ３００００の有するボリュームトポロジ管理表３２２００の構成例を示す図である。

ボリュームトポロジ管理表３２２００は、ストレージ装置の識別子となる装置IDを登録するフィールド３２２１０と、ストレージ装置が有するボリュームの識別子となるボリュームIDを登録するフィールド３２２２０と、ボリュームがホストコンピュータ１００００と通信する際使用するポートの識別子となるポートIDを登録するフィールド３２２３０と、ポートとボリュームとの通信の際に使用するコントローラのIDを登録するフィールド３２２４０と、ボリュームが接続するホストコンピュータ１００００の識別子を登録するフィールド３２２５０と、ボリュームが実体となるホストコンピュータ１００００の論理ボリュームのドライブ名を登録するフィールド３２２６０と、ホストコンピュータがストレージ装置との接続の際使用するポートの識別子となる当該ホストコンピュータのポートIDを登録するフィールド３２２７０と、を構成項目として含んでいる。

例えば、図１２の第１行目（１つ目のエントリ）からは、ストレージ装置SYS1のボリュームVOL1が、PORT1で示されるストレージ側のポートおよびCTL1で示されるコントローラと、LAN1で示されるホスト側のポートを介してホストコンピュータHOST1と接続し、ホスト上で論理ボリューム（E:）として認識されていることが分かる。

＜イベント管理表の構成＞
図１３は、管理サーバ３００００が有するイベント管理表３３７００の構成例を示す図である。このイベント管理表３３７００は、後述する障害原因解析処理、閾値緩和処理、閾値厳格化処理、閾値再計算処理において適宜参照されるものである。

イベント管理表３３７００は、取得した性能値に閾値異常といったイベントの発生した機器の識別子となる装置IDを登録するフィールド３３７１０と、イベントの発生した機器内の部位の識別子を登録するフィールド３３７２０と、閾値異常を検知したメトリックの名称を登録するフィールド３３７３０と、機器内の部位のイベント発生時の状態を登録するフィールド３３７４０と、イベントが発生した日時を登録するフィールド３３７５０と、を構成項目として含んでいる。

例えば、図１３の第１行目（１つ目のエントリ）からは、管理サーバ３００００が、ストレージ装置SYS1の、CTL1で示されるコントローラにおけるプロセッサ稼働率の閾値異常を検知したことが分かる。なお、異常状態が正常に変化した場合もイベントとして登録されるようにしても良い。

＜汎用ルールの構成＞
図１４Ａ及びＢは、管理サーバ３００００が有する汎用ルールリポジトリ３３８００内の汎用ルールの構成例を示す図である。一般的に、障害解析において根本原因を特定するためのイベント伝播モデルは、ある障害の結果発生することが予想されるイベントの組み合わせと、その根本原因を”IF-THEN”形式で記載するものとなっている。なお、汎用ルールは図１４Ａ及びＢに挙げられたものに限られず、さらに多くのルールがあっても構わない。

汎用ルールは、汎用ルールの識別子となる汎用ルールIDを登録するフィールド３３８３０と、”IF-THEN”形式で記載した汎用ルールのIF部に相当する観測事象を登録するフィールド３３８１０と、”IF-THEN”形式で記載した汎用ルールのTHEN部に相当する原因事象を登録するためのフィールド３３８２０と、汎用ルールを実システムに展開し、展開ルールを生成する際に取得するトポロジを登録するためのフィールド３３８４０と、を構成項目として含んでいる。結論部のステータスが正常になれば、条件部の問題も解決しているという関係にあるものである。

例えば、図１４Ａからは、汎用ルールIDがRule1で示される汎用ルールが、観測事象としてホストコンピュータ上の論理ボリュームのレスポンスタイムの閾値異常（関連イベント）と、ストレージ装置におけるコントローラのプロセッサ使用率の閾値異常（原因イベント）を検知したとき、ストレージ装置のコントローラのプロセッサ使用率の閾値異常が原因と結論付けるということが分かる。また、展開ルールを生成する際にはボリュームトポロジ管理表からトポロジ情報を取得する。

なお、観測事象に含まれるイベントとして、ある条件が正常であることを定義してもよい。図１４Ｂに示す汎用ルールの例では、ストレージ装置のコントローラのプロセッサ使用率が正常であることを観測事象として定義している。

＜展開ルールの構成＞
図１５乃至Ｄは、管理サーバ３００００が有する展開ルールリポジトリ３３９００内の展開ルールの構成例を示す図である。これらの展開ルールは、汎用ルール（図１４Ａ及びＢ）にボリュームトポロジ管理表（図１２）の各エントリの項目を挿入することによって生成される。

展開ルールは、展開ルールの識別子となる展開ルールIDを登録するフィールド３３９３０と、展開ルールの基となった汎用ルールの識別子となる汎用ルールIDを登録するためのフィールド３３９４０と、”IF-THEN”形式で記載した展開ルールのIF部に相当する観測事象を登録するフィールド３３９１０と、”IF-THEN”形式で記載した展開ルールのTHEN部に相当する原因事象を登録するためのフィールド３３９２０と、を構成項目として含んでいる。

例えば、図１５Ａの展開ルールは、汎用ルールIDがRule1における装置種別及び装置部位種別に、図１２の第１エントリのコントローラ名３２２４０とホストID３２２５０と、接続先ドライブ名３２２６０を挿入することによって生成される。そして、図１５Ａからは、展開ルールIDがExRule1-1で示される展開ルールが、汎用ルールIDがRule1で示される汎用ルールを基に展開され、観測事象としてホストコンピュータ上の論理ボリュームのレスポンスタイムの閾値異常と、ストレージ装置におけるコントローラのプロセッサ使用率の閾値異常を検知したとき、ストレージ装置のコントローラのプロセッサ使用率の閾値異常が原因と結論付けられることが分かる。

＜その他の管理表の構成等について＞
解析結果管理表３４０００と、閾値補正優先度管理表３４１００と、閾値補正割合管理表３４２００の構成例については、後述する。

＜構成管理情報の取得処理及び、ボリュームトポロジ管理表の更新処理＞
プログラム制御モジュール３３１００は、情報取得モジュール３３２００に対し、計算機システム内のストレージ装置２００００およびホストコンピュータ１００００およびIPスイッチ４００００から、構成管理情報を定期的に取得するよう指示する。

構成管理情報取得モジュール３３２００は、ストレージ装置２００００およびホストコンピュータ１００００およびIPスイッチ４００００から構成管理情報を取得して、取得情報リポジトリ３２０００に格納するとともに、ボリュームトポロジ管理表３２２００を更新する。

また、ボリュームトポロジ管理表３２２００を更新する処理は次のように実行される。まず、情報取得モジュール３３２００は、取得情報リポジトリ３２０００に格納されたボリューム管理表２３２００を参照し、ボリュームの接続するiSCSIターゲット名と、ボリュームにアクセス可能なiSCSIイニシエータ名を確認する。次に、情報取得モジュール３３２００は、論理ボリューム管理表１３３００を参照し、確認したアクセス可能なiSCSIイニシエータ名と同じイニシエータを使用し、確認したiSCSIターゲット名を持つストレージ側ポートに接続する。そして、情報取得モジュール３３２００は、LUN IDが等しいストレージ内ボリュームとホスト内論理ボリュームの対を発見した場合、相互に接続関係にあるものとしてボリュームトポロジ管理表３２２００に登録する。

＜一般的な装置性能情報取得処理及びイベント解析処理＞
図１６は、管理サーバ３００００の装置性能取得モジュール３３３００が実行する通常の装置性能情報取得処理を説明するためのフローチャートである。プログラム制御モジュール３３１００は、プログラムの起動時、もしくは前回の装置性能情報取得処理から一定時間経過するたびに、装置性能取得モジュール３３３００に対し、装置性能情報取得処理を実行するよう指示する。なお、当該実行指示を繰り返し出す場合は厳密に一定期間毎である必要は無く、繰り返しさえしていればよい。

装置性能情報取得モジュール３３３００は、監視対象の各装置に対し、以下の一連の処理を繰り返す。

装置性能情報取得モジュール３３３００は、まず、監視対象の各装置に対し、構成管理情報を送信するよう指示する（ステップ６１０１０）。

装置性能情報取得モジュールは、監視対象装置からの応答があったか否か判断し（ステップ６１０２０）、装置から装置性能情報の応答があれば（ステップ６１０２０でＹｅｓの場合）、取得した装置性能情報を装置性能管理表３２１００に格納する（ステップ６１０３０）。装置から構成管理情報の応答がなかった場合（ステップ６１０２０でＮｏの場合）、構成管理情報取得処理は終了する。

次に、装置性能取得モジュール３３３００は、装置性能管理表３２１００に格納された装置性能情報を参照し、各性能値に対してステップ６１０５０からステップ６１０７０の処理を繰り返す（ステップ６１０４０）。装置性能取得モジュール３３３００は、性能値が閾値を超過しているかを確認し、装置性能管理表３２１００に登録された状態を更新する（ステップ６１０５０）。そして、装置性能取得モジュール３３３００は、状態が正常から閾値異常に、或いは閾値異常から正常に変化したか否か判断し（ステップ６１０６０）、状態が変化した場合（ステップ６１０６０でＹｅｓの場合）、イベント管理表３３７００にイベントを登録する（ステップ６１０７０）。状態が変化していない場合（ステップ６１０６０でＮｏの場合）、全ての性能値に対する状態確認処理が終わっていなければ、処理はステップ６１０５０に戻る。

全ての性能値に対する上記の処理が終了した後、装置性能取得モジュール３３３００は、一連の処理で新規に追加したイベントがあるか否か判断し（ステップ６１０８０）、追加イベントがあれば（例えば、処理中に新たな以上が発生したような場合）、イベント解析処理モジュール３３５００に対し、図１７に示す障害原因解析処理を行なうよう指示する（ステップ６１０９０）。
以上が、装置性能取得モジュール３３３００が実施する装置性能情報取得処理である。

図１７は、管理サーバ３００００のイベント解析処理モジュール３３５００が実行する通常の障害原因解析処理（図１６のステップ６１０９０）の詳細を説明するためのフローチャートである。

イベント解析処理モジュール３３５００は、最初のイベントより遅れて発生したイベントの受信を待つため一定時間待機した後（ステップ６２０１０）、イベント管理表３３７００より、過去一定期間に発生したイベントを取得する（ステップ６２０２０）。

次に、イベント解析処理モジュール３３５００は、展開ルールリポジトリ３３９００内の各展開ルールに対し、ステップ６２０４０からステップ６２０６０の処理を繰り返す（ステップ６２０３０）。イベント解析処理モジュール３３５００は、まず、展開ルールに記載された条件部に対応する各イベントについて、過去一定期間の発生件数を算出する（ステップ６２０４０）。ただし、最新のイベント発生状況が「正常」であるものについては発生件数としてカウントしない。そして、イベント解析処理モジュール３３５００は、ステップ６２０４０の処理において集計したイベント発生数が、条件部に記載された全イベントにおいて一定の比率を超過したか否か判断する（ステップ６２０５０）。超過していると判断した場合には（ステップ６２０５０でＹｅｓの場合）、イベント解析処理モジュール３３５００は、GUI表示処理モジュール３３４００に対し、根本原因なるイベントを、条件文中のイベント発生割合と共に表示するよう指示し（ステップ６２０６０）、処理を終了させる。

例えば、図１５Ａに示す展開ルールExRule1-1には、条件部に”ホストコンピュータHOST1における論理ボリューム（E:）のレスポンスタイムの閾値異常”と、”ストレージ装置SYS1におけるコントローラCTL1の稼働率の閾値異常”が定義されている。

そして、図１３に示すイベント管理表３３７００に、”ストレージ装置SYS1におけるコントローラCTL1の稼働率の閾値異常”（発生日時：2010-01-01 16:00:00）が登録されると、イベント解析処理モジュール３３５００は、一定時間待機した後にイベント管理表３３７００を参照し、過去一定期間に発生したイベントを取得する。

次に、イベント解析処理モジュール３３５００は、展開ルールリポジトリ３３９００の展開ルールExRule1-1に記載された条件部に対応する各イベントについて、過去一定期間の発生件数を算出する。その結果、”ホストコンピュータHOST1における論理ボリューム（E:）のレスポンスタイムの閾値異常”（関連イベント）は過去一定期間に発生していないことから、展開ルールExRule1-1に記載された条件部に対応する各イベント（原因イベントと関連イベント）の過去一定期間の発生数が、条件部に記載された全イベントにおいて占める割合は1/2（原因イベントは発生したが関連イベントが発生していないので分子が１となっている）となる。

以上のようにして算出された割合が一定値を超過した場合、イベント解析処理モジュール３３５００は、GUI表示処理モジュール３３４００に対し、根本原因となるイベントを、条件文中のイベント発生割合と共に表示するよう指示する。ここでいう一定値を例えば80%とした場合、当該具体例では、展開ルールExRule1-1の条件部の各イベントの過去一定期間の発生割合が1/2、すなわち50%であるので、GUIには表示されないことになる。

上記の処理を、展開ルールリポジトリ３３９００に定義された全ての展開ルールに対し実行することになる。
以上が、イベント解析処理モジュール３３５００が実施する障害原因解析処理である。

しかしながら、上述の障害原因解析処理においては、展開ルール内に定義された、閾値異常イベントの１つを検知するための閾値がその機器本来の性能に対して低すぎた場合には、その機器の性能異常イベントが発生するにもかかわらず、展開ルール内に定義された他の閾値異常イベントが発生しない。逆に、展開ルール内に定義された、閾値異常イベントの１つを検知するための閾値がその機器本来の性能に対して高すぎた場合には、その機器の性能異常イベントが発生しないにもかかわらず、展開ルール内に定義された他の閾値異常イベントが発生してしまう。

従って、一般的なイベント解析処理では、処理展開ルールにおいて意図するとおりに必ずしも条件部に記載されたイベントが発生しないという課題が存在する。

そこで、本発明による実施形態では、より適切に性能異常イベントを適切できるようにするために、改良したイベント解析処理を、閾値緩和処理及び閾値厳格化処理として提供する。

＜閾値緩和処理の内容＞
まず、本発明において新たに導入された解析結果管理表（図１８）、閾値補正優先度管理表（図１９）、及び閾値補正割合管理表（図２０）について説明し、続いて閾値緩和処理及び閾値厳格化処理について説明する。

（ｉ）解析結果管理表の構成
図１８は、管理サーバ３００００の有する解析結果管理表３４０００の構成例を示す図である。

解析結果管理表３４０００は、障害原因解析処理において根本原因と判断されたイベントの発生した機器の識別子となる装置IDを登録するフィールド３４０１０と、イベントの発生した機器内の部位の識別子を登録するフィールド３４０２０と、閾値異常を検知したメトリックの名称を登録するフィールド３４０３０と、イベントを根本原因と判断した根拠となる展開ルールのIDを登録するフィールド３４０４０と、展開ルールにおいて条件部に記載されたイベントのうち、根本原因と判定されたイベントの発生有無を登録するフィールド３４０５０と、根本原因と判定されたイベント以外のイベント（関連イベント）の発生割合を登録するフィールド３４０６０と、イベント発生時の性能値を登録するフィールド３４０７０と、イベント発生に伴う障害解析処理を開始した日時を登録するフィールド３４０８０と、を構成項目として含んでいる。

例えば、図１８の第１段目（１つ目のエントリ）からは、展開ルールExRule1-1に基づき、管理サーバ３００００がストレージ装置SYS1の、CTL1で示されるコントローラにおけるプロセッサ稼働率の閾値異常を根本原因として判断し、その際の他の条件イベント（関連イベント）の発生割合が0/1（つまり、HOST1のドライブEのレスポンスタイム異常は起こっていない）であることが分かる。

（ii）閾値優先度管理表の構成
図１９は、管理サーバ３００００の有する閾値補正優先度管理表３４１００の構成例を示す図である。

閾値補正優先度管理表３４１００は、管理サーバ３００００の管理する機器の種別を登録するフィールド３４１１０と、管理対象の機器のうち性能情報の取得の対象となる機器内の部位を登録するフィールド３４１２０と、管理対象の機器より取得するメトリックの名称を登録するフィールド３４１３０と、メトリックに対する閾値修正の優先度を登録するフィールド３４１４０と、を構成項目として含んでいる。

例えば、図１９からは、管理サーバ３００００は各ストレージ装置における各コントローラのプロセッサ稼働率を監視しており、その際閾値変更優先度は１であることが分かる。

なお、展開ルール内の条件部において一番優先度が高いデバイスについて解析結果管理表（図１８）が作成される。従って、例えば、展開ルールExRule1-1の場合、優先度はディスクドライブEよりもコントローラCTL1の方が高く設定されているので、コントローラCTL１についてのみ解析結果管理表が作成されることになる。

（iii）閾値補正割合管理表の構成
図２０は、管理サーバ３００００が有する閾値補正割合管理表３４２００の構成例を示す図である。閾値補正割合管理表３４２００は、管理サーバの管理する機器の種別を登録するフィールド３４２１０と、前記機器のうち、性能情報の取得の対象となる機器内の部位を登録するフィールド３４２２０と、前記機器より取得するメトリックの名称を登録するフィールド３４２３０と、前記メトリックに対する閾値修正の条件を登録するフィールド３４２４０と、前記メトリックに対する閾値修正処理時に閾値を変更する割合を登録するフィールド３４２５０から構成されている。

例えば、図２０からは、管理サーバ３００００が各ストレージ装置における各コントローラのプロセッサ稼働率を監視しており、その閾値を上昇或いは下降させる際の変更の割合は２％であることが分かる。

（iv）障害原因解析処理について
図２１は、第１の実施形態による、管理サーバ３００００のイベント解析処理モジュール３３５００が実行する障害原因解析処理を説明するためのフローチャートである。

イベント解析処理モジュール３３５００は、最初のイベントより遅れて発生したイベントの受信を待つため一定時間待機した後（ステップ６３００５）、イベント管理表３３７００より、過去一定期間に発生したイベントを取得する（ステップ６３０１０）。

次に、イベント解析処理モジュール３３５００は、展開ルールリポジトリ３３９００内の各展開ルールに対し、ステップ６３０３０からステップ６３０７０の処理を繰り返す（ステップ６３０２０）。

繰り返し処理において、まず、イベント解析処理モジュール３３５００は、条件部に対応する各イベントについて、過去一定期間の発生件数を算出した後（ステップ６３０３０）、展開ルールの条件部の各イベントのステータスが「閾値異常」もしくは「正常」から構成されているか否か判断する（ステップ６３０４０）。他のステータスとして「故障」があり得るが、それはこのステップで除かれることになる。

条件部のイベントが「閾値異常」及び「正常」のみであった場合（ステップ６３０４０でＹｅｓの場合）、イベント解析処理モジュール３３５００は、閾値補正優先度管理表３４１００を参照し、展開ルールに記載された条件部の各イベントのうち、閾値補正優先度の最も高いイベントを選び出す。その上で、補正優先度の最も高いイベントの装置ID、部位ID、メトリック名をそれぞれ解析結果管理表３４０００のフィールド３４０１０、３４０２０、３４０３０に、イベントの発生状況と発生時の性能値をそれぞれフィールド３４０５０、３４０７０に、展開ルールIDおよび解析開始日時をそれぞれフィールド３４０４０、３４０８０に追加する。また、閾値補正優先度の最も高いイベントの他に条件部に定義された各イベントの発生割合を算出して、解析結果管理表３４０００のフィールド３４０６０に追加する（ステップ６３０５０）。ただし、条件部に記載されたイベントのうち、ステータスが「正常」からなるイベントについては算出の対象としない。

次に、イベント解析処理モジュール３３５００は、ステップ６３０３０において集計したイベント発生数が、条件部に記載された全イベントにおいて一定の比率を超過しているか判断し（ステップ６３０６０：図１７のステップ６２０５０と同じ処理）、超過している場合（ステップ６３０６０でＹｅｓの場合）、GUI表示処理モジュール３３４００に対し、根本原因なるイベントを、条件文中のイベント発生割合と共に表示するよう指示する（ステップ６３０７０）。

上記の処理を全展開ルールに対して実行した後、イベント解析処理モジュール３３５００は、後述する閾値緩和処理を実行する（６３０８０）。

（ｖ）閾値緩和処理の詳細
図２２は、管理サーバ３００００のイベント解析処理モジュール３３５００が実行する閾値緩和処理（ステップ６３０８０）の詳細を説明するためのフローチャートである。本処理は、図２１における障害原因解析処理の途中に実行される。ただし、管理者の指示によって当該処理が動作してもよい。

イベント解析処理モジュール３３５００は、解析結果管理表３４０００を参照し、解析結果管理表に定義された各部位の各メトリックについて、ステップ６４０２０からステップ６４０９０の処理を繰り返す（ステップ６４０１０）。

まずイベント解析処理モジュール３３５００は、各部位の各メトリックについて、過去一定期間の解析結果すべてにおいて閾値異常イベントを受信済みかどうか確認し（ステップ６４０２０）、受信していない場合（ステップ６４０２０でＮｏの場合）、処理は次のメトリックについての処理に移行する。イベントを受信している場合（ステップ６４０２０でＹｅｓの場合）、イベント解析処理モジュール３３５００は、解析結果管理表３４０００に定義された閾値補正対象となる各部位の各メトリックについて、条件発生比率の総計を集計する（ステップ６４０３０）。

次に、イベント解析処理モジュール３３５００は、総計した割合が一定値を下回っているかを確認し（ステップ６４０４０）、下回っていない場合（ステップ６４０４０でＮｏの場合）は、処理は次のメトリックについての処理に移行する。値が一定値を下回っている場合（ステップ６４０４０でＹｅｓの場合）は、イベント解析処理モジュール３３５００は、閾値補正割合管理表３４２００を参照し、変更後の閾値を決定する（ステップ６４０５０）。その際、補正種別が「上昇」となっている変更割合を使用する。

次に、イベント解析処理モジュール３３５００は、これまでの処理で算出した閾値をＧＵＩ画面上で表示し、ユーザからの閾値変更の可否についての指示を受付け、閾値変更の有無を確認する（ステップ６４０６０）。

ユーザから閾値変更許可の指示を受けた場合（ステップ６４０７０でＹｅｓの場合）、イベント解析処理モジュール３３５００は、装置性能管理表３２１００の閾値を算出した値に変更する（ステップ６４０８０）。さらに、イベント解析処理モジュール３３５００は、該当するメトリックの解析結果を、解析結果管理表３４０００から削除する（ステップ６４０９０）。なお、ユーザに対して閾値変更の可否を確認せずに処理するようにしても良い。
以上が、イベント解析処理モジュール３３５００が実施する閾値緩和処理である。

続いて、障害原因解析処理および閾値緩和処理の具体例について説明する。なお、処理終了後の解析結果管理表は図１８、閾値補正優先度管理表は図１９、閾値補正割合管理表は図２０、展開ルールExRule1-1は図１５Ａに示す通りのものであるとする。

図１３に示すイベント管理表３３７００に、”ストレージ装置SYS1におけるコントローラCTL1の稼働率の閾値異常”（発生日時：2010-01-01 16:00:00）が登録されると、イベント解析処理モジュール３３５００は、一定時間待機した後にイベント管理表３３７００を参照し、過去一定期間に発生したイベントを取得する。

次に、イベント解析処理モジュール３３５００は、展開ルールExRule1-1に記載された条件部に対応する各イベントについて、閾値補正優先度管理表３４１００を参照し、展開ルールに記載された条件部の各イベントのうち、閾値補正優先度の最も高いイベントを選び出す。展開ルールExRule1-1においては、”ストレージ装置SYS1におけるコントローラCTL1の稼働率”の 閾値補正優先度が最も高い。”ストレージ装置SYS1におけるコントローラCTL1の稼働率”の閾値異常イベントは過去一定期間に発生済みである。一方、条件部に定義されたその他のイベントは”ホストコンピュータHOST1における論理ボリューム（E:）のレスポンスタイムの閾値異常”の１つで、過去一定期間において未発生である。そのため、その他の条件部に定義された各イベントの発生割合は0/1となる。以上の結果を算出解析結果管理表に追加する。

また、イベント解析処理モジュール３３５００は、解析結果管理表３４０００を参照し、”ストレージ装置SYS1におけるコントローラCTL1の稼働率”について、閾値異常イベントを受信済みかどうか確認する。”ストレージ装置SYS1におけるコントローラCTL1の稼働率”の閾値異常イベントは受信済みのため、”ストレージ装置SYS1におけるコントローラCTL1の稼働率”について、条件部に定義された各イベントの発生割合の総計を集計する。総計の結果、割合は0/4となる。

そして、総計した割合が一定値を下回っているため、イベント解析処理モジュール３３５００は、閾値補正優先度管理表３４１００と閾値補正割合管理表３４２００を参照し、変更後の閾値を決定する。閾値補正割合管理表３４２００を参照すると、”ストレージ装置SYS1におけるコントローラCTL1の稼働率”は２％上方に修正するよう定義されているため、新閾値は２０．４％となる。

以上の処理で算出した閾値がＧＵＩ画面上で表示され、ユーザに閾値変更の可否を確認する。ユーザが閾値変更を許可した場合、装置性能管理表の閾値を前記算出した値に変更する。

以上の処理により、”ストレージ装置SYS1におけるコントローラCTL1の稼働率”に関する装置性能管理表の閾値が上方に更新される。

なお、イベント解析処理モジュール３３５００が実施する閾値緩和処理において、イベント解析処理モジュール３３５００は、取得情報リポジトリ３２０００に保持された管理下機器の構成情報を参照し、閾値再設定の対象となっている機器内構成要素と同一の性能特性を持つ部品に対しても、一括して閾値緩和処理を実施してもよい。例えば、ストレージ装置２００００のRAIDグループ２４０００を構成するディスク２４２００乃至２４２１０が同一の機種であって同じ性能特性を持つ場合、ディスク２４２００のあるメトリックに対する閾値再設定と同時に、ディスク２４２１０の同一メトリックに対する閾値再設定を同時に行なってもよい。

＜閾値修正画面の構成＞
図２３は、管理サーバ３００００がユーザに対し表示する、閾値修正画面の表示例を示す図である。

閾値修正画面７１０００では、修正対象となる機器の種別および機器内構成要素の種別、およびメトリックと、変更前後の閾値が表示される（テーブル７１０１０）。そして、ユーザが「変更する」ボタン（ボタン７１０２０）を押下すると、閾値変更が許可される。また、ユーザが「変更しない」ボタン（ボタン７１０３０）を押下した場合は閾値変更を許可しないこととなり、閾値の修正が行われない。

＜閾値緩和処理の効果＞
以上のように、システム管理ソフトウェアが、自身が持つ障害原因解析機能の性能障害解析のための展開ルールにおけるイベントヒット状況に基づき、閾値緩和処理を実行し、機器本来の性能に比して低く設定された閾値を上方に補正する。その結果、管理下の部品に対し付与した閾値が、部品の性能キャパシティに合致したものとなり、結果として管理ソフトが管理者に対し、正確に警告を行うことができる。

＜閾値厳格化処理の詳細＞
図２４は、本発明の第１の実施形態によるイベント解析処理モジュール３３５００が実行する閾値厳格化処理を説明するためのフローチャートである。なお、管理サーバ３００００が有する管理情報は、閾値緩和処理で用いた情報と変わらない。また、本処理は、図２２による閾値緩和処理の実行後に実行される。ただし、管理者の指示によって当該処理が動作してもよい。

イベント解析処理モジュール３３５００は、解析結果管理表３４０００を参照し、解析結果管理表に定義された各部位の各補正対象メトリックについて、ステップ６５０２０からステップ６５０９０の処理を繰り返す（ステップ６５０１０）。

この繰り返し処理において、まずイベント解析処理モジュール３３５００は、各部位の各メトリックについて、過去一定期間の解析結果すべてにおいて閾値異常イベントを未受信かどうか確認する（ステップ６５０２０）。つまり、１つでも受信したイベントがあれば、処理は次のメトリックについての処理に移行する。

未受信でない場合（ステップ６５０２０でＮｏの場合）は、処理は次のメトリックについての処理に移行する。未受信の場合（ステップ６５０２０でＹｅｓの場合）は、イベント解析処理モジュール３３５００は、解析結果管理表３４０００に定義された閾値補正対象となる各部位の各メトリックについて、条件発生比率の総計を集計する（ステップ６５０３０）。次に、イベント解析処理モジュール３３５００は、総計した割合が一定値を超えているかを確認する（ステップ６５０４０）。超えていない場合（ステップ６５０４０でＮｏの場合）は、処理は次のメトリックについての処理に移行する。

値が一定値を超えている場合（ステップ６５０４０でＹｅｓの場合）、イベント解析処理モジュール３３５００は、閾値補正割合管理表３４２００を参照し、変更後の閾値を決定する（ステップ６５０５０）。その際、補正種別が「下降」となっている変更割合を使用する。

次に、イベント解析処理モジュール３３５００は、これまでの処理で算出した閾値をＧＵＩ画面上で表示し、ユーザに閾値変更の可否を確認する（ステップ６５０６０）。

ユーザから閾値変更許可の指示を受けた場合（ステップ６５０７０でＹｅｓの場合）、イベント解析処理モジュール３３５００は、装置性能管理表３２１００の閾値を前記算出した値に変更する（ステップ６５０８０）。ユーザから閾値変更不許可の指示を受けた場合（ステップ６５０７０でＮｏの場合）、処理は次のメトリックについての処理に移行する。なお、ユーザに対して閾値変更の可否を確認せずに処理するようにしても良い。

そして、イベント解析処理モジュール３３５００は、該当するメトリックの解析結果を、解析結果管理表３４０００から削除する（ステップ６５０９０）。
以上が、イベント解析処理モジュール３３５００が実施する閾値厳格化処理である。

続いて、障害原因解析処理および閾値厳格化処理の具体例について説明する。なお、処理終了後の解析結果管理表は図１８、閾値補正優先度管理表は図１９、閾値補正割合管理表は図２０、展開ルールExRule1-4は図１５Ｄに示す通りのものであるとする。

図１３に示すイベント管理表に、” ホストコンピュータHOST3における論理ボリューム（E:）のレスポンスタイムの閾値異常”（発生日時：2010-01-01 16:00:00）が登録されると、イベント解析処理モジュール３３５００は一定時間待機した後にイベント管理表３３７００を参照し、過去一定期間に発生したイベントを取得する。

次に、イベント解析処理モジュール３３５００は、展開ルールリポジトリ３３９００の展開ルールExRule1-4に記載された条件部に対応する各イベントについて、閾値補正優先度管理表３４１００を参照し、展開ルールExRule1-4に記載された条件部の各イベントのうち、閾値補正優先度の最も高いイベントを選び出す。展開ルールExRule1-4においては、”ストレージ装置SYS1におけるコントローラCTL2の稼働率”の閾値補正優先度が最も高い。”ストレージ装置SYS1におけるコントローラCTL2の稼働率”の閾値異常イベントは過去一定期間に未発生である。一方、条件部に定義されたその他のイベント（関連イベント）は”ホストコンピュータHOST3における論理ボリューム（E:）のレスポンスタイムの閾値異常”の１つで、過去一定期間において発生済みである。そのため、その他の条件部に定義された各イベント（関連イベント）の発生割合は1/1となる。以上の結果を解析結果管理表３４０００に追加する。

次に、イベント解析処理モジュール３３５００は、解析結果管理表３４０００を参照し、”ストレージ装置SYS1におけるコントローラCTL2の稼働率”について、閾値異常イベントを未受信かどうか確認する。”ストレージ装置SYS1におけるコントローラCTL2の稼働率”の閾値異常イベントは未受信のため、”ストレージ装置SYS1におけるコントローラCTL2の稼働率”について、条件部に定義された各イベントの発生割合の総計を集計する。総計の結果、割合は2/2となる。

総計した割合が一定値を超えているため、イベント解析処理モジュール３３５００は装置性能管理表３２１００と閾値補正割合管理表３４２００を参照し、変更後の閾値を決定する。閾値補正割合管理表３４２００を参照すると、”ストレージ装置SYS1におけるコントローラCTL2の稼働率”は２％下方に修正するよう定義されているため、新閾値は７８．４％となる。

そして、イベント解析処理モジュール３３５００は、修正した閾値をＧＵＩ画面上で表示し、ユーザに閾値変更の可否を確認する（図２３参照）。ユーザが閾値変更を許可した場合、イベント解析処理モジュール３３５００は、装置性能管理表３２１００の閾値を修正した値に変更する。

以上の処理により、”ストレージ装置SYS1におけるコントローラCTL2の稼働率”に関する装置性能管理表の閾値が下方に更新される。

なお、閾値厳格化処理において、イベント解析処理モジュール３３５００が、取得情報リポジトリ３２０００に保持された管理下機器の構成情報を参照し、閾値再設定の対象となっている機器内構成要素と同一の性能特性を持つ部品に対しても、一括して閾値再設定処理を実行してもよい。例えば、ストレージ装置２００００のRAIDグループ２４０００を構成するディスク２４２００乃至２４２１０が同一の機種であって同じ性能特性を持つ場合、ディスク２４２００のあるメトリックに対する閾値再設定と同時に、ディスク２４２１０の同一メトリックに対する閾値再設定を同時に行なってもよい。

＜閾値厳格化処理の効果＞
以上のように、システム管理ソフトウェアは、自身が持つ障害原因解析機能の性能障害解析のための展開ルールにおけるイベントヒット状況に基づき、閾値厳格化処理を実行し、本来の性能に比して高く設定された閾値を下方に補正する。この結果、管理下の部品に対し付与した閾値が、部品の性能キャパシティに合致したものとなり、結果として管理ソフトが管理者に対し、正確に警告を行うことができる。

（２）第２の実施形態
第２の実施形態は、管理ソフトウェアによる測定値ベース閾値を用いた閾値再計算処理に関するものである。システム構成や各装置の構成は第１の実施形態と同じであるので、説明は省略する。

＜測定値ベース閾値を用いた閾値再計算処理の詳細＞
適切な閾値設定を実現するために、本実施形態では、管理サーバ３００００が、測定値ベース閾値を用いた閾値再計算処理を実行する。なお、管理サーバ３００００が有する管理情報は、第１の実施形態と同じである。

図２５は、第３の実施形態において、管理サーバ３００００のイベント解析処理モジュール３３５００が実行する閾値再計算処理を説明するためのフローチャートである。本処理は、第１の実施形態で述べた図２２における障害原因解析処理における閾値緩和処理に代わって実行される。ただし、管理者の指示によって当該処理が動作してもよい。

イベント解析処理モジュール３３５００は、解析結果管理表３４０００を参照し、解析結果管理表に定義された各部位の各メトリックについて、ステップ６６０２０からステップ６６０９０からステップ６６１９０の一連の処理を繰り返す（ステップ６６０１０）。

この繰り返し処理においては、まず、イベント解析処理モジュール３３５００は、各部位の各メトリックについて、過去一定期間の解析結果の全てにおいて閾値異常イベントを受信したか（解析結果管理表３４０００のイベント受信３４０５０で全てがＹｅｓとなっているか）どうか確認する（ステップ６６０２０）。閾値異常イベントを受信していない場合（ステップ６６０２０でＮｏの場合）、処理はステップ６６１００に移行する。所定部位のメトリックの全てにおいて閾値異常イベントを受信している場合（ステップ６６０２０でＹｅｓの場合）、イベント解析処理モジュール３３５００は、解析結果管理表３４０００に定義された閾値補正対象となる各部位の各メトリックについて、条件発生比率の総計を集計する（ステップ６６０３０）。

次に、イベント解析処理モジュール３３５００は、総計した割合が一定値を下回っているかを確認し（ステップ６６０４０）、下回っていない場合（ステップ６６０４０でＮｏの場合）、処理は次のメトリックについての処理に移行する。

割合が一定値を下回っている場合（ステップ６６０４０でＹｅｓの場合）、イベント解析処理モジュール３３５００は、解析結果管理表３４０００を参照し、当該メトリックにおける過去一定期間の閾値異常イベント発生時の性能値の平均を算出する（ステップ６６０５０）。

次に、イベント解析処理モジュール３３５００は、ステップ６６０５０で算出した閾値（修正値）をＧＵＩ画面上で表示し、ユーザに閾値変更の可否を確認する（ステップ６６０６０）。その際、算出したイベント発生時の性能値の平均を変更後閾値として提示する。

そして、ユーザから閾値変更許可の指示を受けた場合（ステップ６６０７０でＹｅｓ）、イベント解析処理モジュール３３５００は、装置性能管理表３２１００の測定値ベース閾値を算出した値（修正値）に変更する（ステップ６６０８０）。さらに、イベント解析処理モジュール３３５００は、該当するメトリックの解析結果を、解析結果管理表３４０００から削除する（ステップ６６０９０）。

一方、イベント解析処理モジュール３３５００は、各部位の各メトリックについて、過去一定期間の解析結果の全てにおいて閾値異常イベントを未受信かどうか（解析結果管理表３４０００のイベント受信３４０５０で全てがＮｏとなっているか）確認する（ステップ６６１００）。未受信でない場合（ステップ６６１００でＮｏの場合）、処理は次のメトリックについての処理に移行する。

全てにおいて未受信の場合（ステップ６６１００でＹｅｓの場合）、イベント解析処理モジュール３３５００は、解析結果管理表３４０００に定義された閾値補正対象となる各部位の各メトリックについて、条件発生比率の総計を集計する（ステップ６６１１０）。

次に、イベント解析処理モジュール３３５００は、総計した割合が一定値を超えているかを確認する（ステップ６６１２０）。超えていない場合（ステップ６６１２０でＮｏの場合）、処理は次のメトリックについての処理に移行する。

割合が一定値を超えている場合（ステップ６６１２０でＹｅｓの場合）、イベント解析処理モジュール３３５００は、閾値補正割合管理表３４２００を参照し、変更後の閾値を決定する（ステップ６６１３０）。その際、補正種別が「下降」となっている変更割合を使用する。

次に、イベント解析処理モジュール３３５００は、装置性能管理表３２１００を参照し、該当するメトリックの測定値ベース閾値を確認する（ステップ６６１４０）。算出した閾値が測定値ベース閾値を下回っている場合（ステップ６６１４０でＹｅｓの場合）、イベント解析処理モジュール３３５００は、測定値ベース閾値を新閾値として設定する（ステップ６６１５０）。一方、算出した閾値が測定値ベース閾値を下回っていない場合（ステップ６６１４０でＮｏの場合）、イベント解析処理モジュール３３５００は、ステップ６６１３０で算出した閾値を新閾値とし、処理をステップ６６１６０に移行させる。

そして、イベント解析処理モジュール３３５００は、新閾値（測定ベース閾値或いは算出した閾値）をＧＵＩ画面上に表示し、ユーザからの閾値変更可否の指示を受け付ける（ステップ６６１６０）。

ユーザから閾値変更許可の指示を受信した場合（ステップ６６１７０でＹｅｓの場合）、イベント解析処理モジュール３３５００は、装置性能管理表３２１００の閾値を新閾値に変更する（ステップ６６１８０）。ユーザから閾値変更不許可の指示を受信した場合（ステップ６６１７０でＮｏの場合）、処理は次のメトリックについての処理に移行する。

さらに、イベント解析処理モジュール３３５００は、該当するメトリックの解析結果を、解析結果管理表３４０００から削除する（ステップ６６１９０）。

以上が、イベント解析処理モジュール３３５００が実施する測定値ベース閾値を用いた閾値再計算処理である。

続いて、障害原因解析処理および測定値ベース閾値を用いた閾値再計算処理の具体例について説明する。なお、処理終了後の解析結果管理表は図１８、閾値補正優先度管理表は図１９、閾値補正割合管理表は図２０、展開ルールExRule1-1は図１５Ａに示すとおりであるものとする。

まず、図１３に示すイベント管理表に、”ストレージ装置SYS1におけるコントローラCTL1の稼働率の閾値異常”（発生日時：2010-01-01 16:00:00）が登録されると、イベント解析処理モジュール３３５００は一定時間待機した後にイベント管理表を参照し、過去一定期間に発生したイベントを取得する。

次に、イベント解析処理モジュール３３５００は、展開ルールリポジトリ３３９００の展開ルールExRule1-1に記載された条件部に対応する各イベントについて、閾値補正優先度管理表３４１００を参照し、展開ルールExRule1-1に記載された条件部の各イベントのうち、閾値補正優先度の最も高いイベントを選び出す。展開ルールExRule1-1においては、”ストレージ装置SYS1におけるコントローラCTL1の稼働率”の閾値補正優先度が最も高い。”ストレージ装置SYS1におけるコントローラCTL1の稼働率”の閾値異常イベントは、イベント管理表３３７００を見ると、過去一定期間に発生済みである。

一方、条件部に定義されたその他のイベント（関連イベント）は”ホストコンピュータHOST1における論理ボリューム（E:）のレスポンスタイムの閾値異常”の１つで、過去一定期間において未発生である。そのため、その他の条件部に定義された各イベントの発生割合は0/1となる。以上の結果を解析結果管理表３４０００に追加する（図１８の３４０６０参照）。

次に、イベント解析処理モジュール３３５００は、解析結果管理表３４０００を参照し、”ストレージ装置SYS1におけるコントローラCTL1の稼働率”の全てについて、閾値異常イベントを受信済みかどうか確認する。解析結果管理表３４０００を見ると、”ストレージ装置SYS1におけるコントローラCTL1の稼働率”の全てについて閾値異常イベントは受信済みのため、”ストレージ装置SYS1におけるコントローラCTL1の稼働率”について、条件部に定義された各イベントの発生割合の総計を集計する。総計の結果、割合は0/4となる。

そして、総計した割合が一定値を下回っているため、イベント解析処理モジュール３３５００は、解析結果管理表３４０００を参照し、変更後の閾値を決定する。解析結果管理表３４０００を参照すると、”ストレージ装置SYS1におけるコントローラCTL1の稼働率の閾値異常”イベント発生時の性能値は４０％と４５％であるため、それらの平均である４２．５％が新閾値となる。

算出した新しい閾値をＧＵＩ画面上で表示し、ユーザに閾値変更の可否を確認する。ユーザが閾値変更を許可した場合、装置性能管理表の閾値を前記算出した値に変更する。

以降、閾値再計算処理の過程で、ストレージ装置SYS1におけるコントローラCTL1の稼働率の閾値を引き下げる場合、測定値ベース閾値として算出した４２．５％を下回らない範囲で閾値を引き下げる。

以上の処理により、”ストレージ装置SYS1におけるコントローラCTL1の稼働率”に関する装置性能管理表の測定値ベース閾値が設定される。

なお、測定値ベース閾値を用いた閾値再計算処理において、イベント解析処理モジュール３３５００は、取得情報リポジトリ３２０００に保持された管理下機器の構成情報を参照し、閾値再設定の対象となっている機器内構成要素と同一の性能特性を持つ部品に対しても、一括して測定値ベース閾値設定を実施してもよい。例えば、ストレージ装置２００００のRAIDグループ２４０００を構成するディスク２４２００、２４２１０が同一の機種であって同じ性能特性を持つ場合、ディスク２４２００のあるメトリックに対する測定値ベース閾値設定と同時に、ディスク２４２１０の同一メトリックに対する測定値ベース閾値設定を同時に行なってもよい。

＜測定値ベース閾値を用いた閾値再計算処理の効果＞
以上のように、システム管理ソフトウェアは、自身が持つ障害原因解析機能の性能障害解析のための展開ルールにおけるイベントヒット状況に基づき、閾値再計算処理を実行し、機器本来の性能に比して高く、もしくは低く設定された閾値を補正する。この結果、管理下の部品に対し付与した閾値が、部品の性能キャパシティに合致したものとなり、結果として管理ソフトが管理者に対し、正確に警告を行うことができる。

また、測定値ベース閾値を設定することで、閾値再計算処理により閾値が上下し続けることを防止することができる。

（３）第３の実施形態
第３の実施形態は、管理ソフトによる解析結果管理表構築に関するものである。システム構成や各装置の構成は第１の実施形態と同じであるので、説明は省略する。

＜解析結果管理表の構成＞
図２６は、第３の実施形態による、管理サーバ３００００が有する解析結果管理表３４０００の構成例を示す図である。解析結果管理表３４０００は、図１８の解析結果管理表とは異なり、受信時測定値３４０７０を構成項目としては有していないが、さらに、障害原因解析処理において根本原因と判定されたイベント以外のイベントのうち、閾値補正優先度の最も低いイベントのメトリック名を登録するフィールド３４０９０と、イベントの閾値を登録するフィールド３４１００と、を構成項目として含んでいる。その他のフィールドは、図１８に示す構成と同じである。

＜解析結果管理表構築処理の詳細＞
図２７は、第３の実施形態において、管理サーバ３００００のイベント解析処理モジュール３３５００が実行する障害原因解析および解析結果管理表構築処理を説明するためのフローチャートである。

イベント解析処理モジュール３３５００は、最初のイベントより遅れて発生したイベントの受信を待つため一定時間待機した後（ステップ６７０１０）、イベント管理表３３７００（図１３）から、過去一定期間に発生したイベントを取得する（ステップ６７０２０）。そして、イベント解析処理モジュール３３５００は、展開ルールリポジトリ３３９００内の各展開ルールに対し、ステップ６７０４０からステップ６７１２０の一連の処理を繰り返し（ステップ６７０３０）、繰り返し処理終了後に、閾値緩和処理（ステップ６７１３０）を実行する。

繰り返し処理において、まず、イベント解析処理モジュール３３５００は、展開ルールの条件部に対応する各イベントについて、過去一定期間の発生件数を算出した後（ステップ６７０４０）、展開ルールの条件部の各イベントのステータスが「閾値異常」もしくは「正常」のみ（ステータス「故障」を除く趣旨）から構成されているか判断する（ステップ６７０５０）。「閾値異常」もしくは「正常」のみから構成されていると判断された場合（ステップ６７０５０でＹｅｓの場合）、イベント解析処理モジュール３３５００は、展開ルールに記載された展開前の汎用ルールIDと同じ展開前の汎用ルールIDを持つ展開ルールに基づく解析結果であり、かつ解析開始日時が同じである解析結果を選び出す（ステップ６７０６０）。「閾値異常」もしくは「正常」以外にもあると判断された場合（ステップ６７０５０でＮｏの場合）、処理はステップ６７１１０に移行する。

次に、イベント解析処理モジュール３３５００は、該当する解析結果が存在するか否か判断する（ステップ６７０７０）。該当メトリックがないと判断された場合（ステップ６７０７０でＮｏの場合）、処理はステップ６７１００に移行する。

ステップ６７１００では、イベント解析処理モジュール３３５００は、補正優先度の最も高いイベントの装置ID、部位ID、メトリック名を解析結果管理表３４０００のフィールド３４０１０、３４０２０、３４０３０のそれぞれに追加し、イベントの発生状況をフィールド３４０５０に追加し、展開ルールIDおよび解析開始日時をフィールド３４０４０、３４０８０のそれぞれに追加する。また、イベント解析処理モジュール３３５００は、装置性能管理表３２１００を参照し、展開ルールに記載されたイベントのうち、閾値補正優先度の最も低いイベントのメトリック名および閾値を解析結果管理表３４０００のフィールド３４０９０、３４１００のそれぞれに登録する。さらに、イベント解析処理モジュール３３５００は、閾値補正優先度の最も高いイベントの他に条件部に定義された各イベントの発生割合を算出解析結果管理表３４０００のフィールド３４０６０に追加する（ステップ６７１００）。ただし、条件部に記載されたイベントのうち、ステータスが「正常」からなるイベントについては算出の対象としない。

一方、該当する解析結果が存在すると判断された場合（ステップ６７０７０でＹｅｓの場合）、イベント解析処理モジュール３３５００は、閾値補正優先度の最も低いイベントの閾値と、算出解析結果管理表３４０００の基準イベント閾値３４０９０に定義された値を比較し、最も低いイベントの閾値が他のイベントの閾値よりも厳格か否か判断する（ステップ６７０８０）。

閾値補正優先度の最も低いイベントの閾値の方が、基準イベント閾値の値より厳格である場合（ステップ６７０８０でＹｅｓの場合）、イベント解析処理モジュール３３５００は、ステップ６７０６０で検出した解析結果を解析結果管理表３４０００から一旦削除する（ステップ６７０９０）。その上で、イベント解析処理モジュール３３５００は、解析結果管理表３４０００への解析結果の登録を実行する（ステップ６７１００）。

一方、閾値補正優先度の最も低いイベント（若しくは、より優先度の低いイベント）の閾値の方が、基準イベント閾値の値より厳格でない場合（ステップ６７０８０でＮｏの場合）、処理はステップ６７１１０に移行する。

続いて、イベント解析処理モジュール３３５００は、ステップ６７０４０において集計したイベント発生数が、展開ルールの条件部に記載された全イベントにおいて一定の比率を超過したか否か判断する（ステップ６７１１０）。一定の比率を超える場合（ステップ６７１１０でＹｅｓの場合）、イベント解析処理モジュール３３５００はGUI表示処理モジュール３３４００に対し、根本原因なるイベントを、条件文中のイベント発生割合と共に表示するよう指示する（ステップ６７１２０）。一定の比率を超えていない場合（ステップ６７１１０でＮｏの場合）、処理は、次の展開ルールに移行するか、ステップ６７１３０に移行する。

全展開ルールに対して実行した後、イベント解析処理モジュール３３５００は、第１の実施形態で説明した閾値緩和処理を実行する（ステップ６７１３０）。

続いて、解析結果管理表構築処理の具体例について説明する。なお、処理開始当初の解析結果管理表は図２６、装置性能管理表は図１１、閾値補正優先度管理表は図１９、閾値補正割合管理表は図２０、展開ルールExRule1-3は図１５Cに示す通りのものであるとする。

図１３に示すイベント管理表に、”ストレージ装置SYS1におけるコントローラCTL1の稼働率の閾値異常”（発生日時：2010-01-01 16:00:00）が登録されると、イベント解析処理モジュールは一定時間待機した後にイベント管理表を参照し、過去一定期間に発生したイベントを取得する。

次に、イベント解析処理モジュール３３５００は、展開ルールリポジトリ３３９００の展開ルールExRule1-3に記載された展開前の汎用ルールIDを参照し、同じ展開前の汎用ルールIDを持つ展開ルールに基づく解析結果であり、かつ解析開始日時が同じである解析結果を選び出す。図２６における解析結果管理表３４０００では、解析開始日時が2010-01-01 16:05:00であり、展開ルールがExRule1-1およびExRule1-2である解析結果がそれに該当する。

これらの解析結果について、イベント解析処理モジュール３３５００は、基準イベント閾値を参照する。ExRule1-1およびExRule1-2の基準イベント閾値は１０msecである。一方、ExRule1-3において閾値補正優先度の最も低いイベントである”サーバHOST2におけるドライブ（E:）のレスポンスタイム”の閾値は、図１１に示す装置性能管理表によると８msecである。

この場合、閾値補正優先度の最も低いイベントの閾値の方が、基準イベント閾値の値より厳格であるため、イベント解析処理モジュール３３５００は、検出した展開ルールがExRule1-1およびExRule1-2である解析結果を解析結果管理表から削除する。削除することにより、当該結果は、閾値変更検討対象から外れる。

次に、イベント解析処理モジュール３３５００は、展開ルールExRule1-3の条件部に対応する各イベントについて、閾値補正優先度管理表３４１００を参照し、展開ルールに記載された条件部の各イベントのうち、閾値補正優先度の最も高いイベントを選び出す。展開ルールExRule1-3においては、”ストレージ装置SYS1におけるコントローラCTL1の稼働率”の閾値補正優先度が最も高い。”ストレージ装置SYS1におけるコントローラCTL1の稼働率”の閾値異常イベントは過去一定期間に発生済みである。一方、展開ルールの条件部に定義されたその他のイベントは”ホストコンピュータHOST2における論理ボリューム（E:）のレスポンスタイムの閾値異常”の１つで、過去一定期間において未発生である。そのため、その他の条件部に定義された各イベントの発生割合は0/1となる。

また、ExRule1-3において閾値補正優先度の最も低いイベントである”サーバHOST2におけるドライブ（E:）のレスポンスタイム”の閾値は、図１１に示す装置性能管理表３２１００によると８msecである。以上の結果を算出解析結果管理表に追加する。

＜解析結果管理表構築処理の効果＞
以上のように、システム管理ソフトウェアは、自身が持つ障害原因解析機能の性能障害解析のための展開ルールにおけるイベントヒット状況に基づき、閾値再計算処理を実行し、機器本来の性能に比して高く、もしくは低く設定された閾値を補正する。この結果、管理下の部品に対し付与した閾値が、部品の性能キャパシティに合致したものとなり、結果として管理ソフトが管理者に対し、正確に警告を行うことができる。

また、１つの部品と接続する複数の機器において、同一の性能メトリックについてそれぞれ異なる閾値が付与されていた場合、それらの閾値のうち最も厳格な閾値を閾値再計算の際の基準とすることで、閾値再計算処理により閾値が緩和され過ぎることを防止することができる。

特に、本実施形態によれば、閾値優先度が高いデバイスにも拘わらず、当該優先度が低いデバイスよりも閾値が緩く設定されていた場合には厳しく設定された閾値に合わせるようにする。また、閾値優先度が高いデバイスの方が、優先度が低いデバイスよりも厳しい閾値が設定されていた場合には、優先度が低いデバイスに合わせて閾値を緩和しないようにする。このようにすることにより、重要なデバイスについては、閾値をより厳格に管理することができるようになる。

（４）まとめ
本発明では、管理サーバ（プロセッサ）が、ノード装置（ストレージ装置やホストコンピュータ）を監視し、各構成デバイス（コントローラ、I/Oポート、ドライブ）の処理性能を示す処理性能値を取得する。また、管理サーバは、各構成デバイスについて設定された閾値と取得した処理性能値とを比較し、各構成デバイスの性能の異常を検知する。そして、管理サーバは、汎用ルール（図１４）から生成された展開ルール（図１５：ノード装置で発生し得る１つ以上の条件イベント（障害の根本原因に直接関係する原因イベント及び障害が発生する場合に原因イベントと共に発生する関連イベントで構成される）の組み合わせと、条件イベントの組み合わせの根本原因とされる結論イベントとの関係を示すルール）と、検知した各構成デバイスの性能とを照合することにより、閾値修正の必要がある構成デバイスを特定し、その閾値を調整する。より具体的には、展開ルールの原因イベントが発生したとき、或いは未発生のときの関連イベントの発生の有無を確認し、関連イベントの発生率に基づいて閾値修正の必要性を検知する。このようにすることにより、各構成デバイスに設定された性能管理のための閾値を、各構成デバイスの性能キャパシティに合致した適切な値に設定することが可能となる。

また、閾値を調整する場合には、特定された構成デバイスを有するノード装置（コントローラ１を有するストレージ装置１）とは異なる他のノード装置（同じコントローラを有するストレージ装置２）における、特定された構成デバイス（コントローラ１）と同一の構成デバイス（コントローラ２）の閾値についても、調整後の閾値（調整後のコントローラ１の閾値）に変更する。このようにすることにより、同じ構成部品についての閾値を一遍に適切な値に変更することができるので、システムを管理するときの効率が向上する。

なお、閾値の調整方法は、予め決められた変更幅を示す修正ルール（図２０）に従って、調整後の閾値を算出するようにしても良いし、特定された構成デバイスの測定性能値の平均を演算し、当該平均値を調整後の閾値としても良い。

さらに、管理サーバは、構成デバイスの種類に応じて閾値の補正の優先度に関する情報（図１９）を管理するようにする。そして、原因イベントを生じさせる構成デバイスの優先度は、関連イベントを生じさせる構成デバイスの優先度よりも高く設定されている。このとき、管理サーバは、解析結果表（図２６）において、検討対象の構成デバイスについて、原因イベントの発生及び関連イベントの発生の有無と、優先度が低く設定されている構成デバイスの基準閾値を管理する。そして、管理サーバは、優先度が低く設定されている構成デバイスと同一のデバイスを有する他のノード装置の閾値が、基準閾値よりも厳格に設定されているか判断し、他のノード装置の閾値が基準閾値よりも厳格に設定されている場合には、検討対象の構成デバイスを閾値調整の対象から外すように管理する。このようにすることにより、他のデバイスで厳しい閾値が設定されているにも拘わらず、原因イベントが発生したからといって同じデバイスの閾値を緩和してしまうという不都合を回避することが可能となる。

なお、本発明は、実施形態の機能を実現するソフトウェアのプログラムコードによっても実現できる。この場合、プログラムコードを記録した記憶媒体をシステム或は装置に提供し、そのシステム或は装置のコンピュータ（又はＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出す。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコード自体、及びそれを記憶した記憶媒体は本発明を構成することになる。このようなプログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどが用いられる。

また、プログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ（オペレーティングシステム）などが実際の処理の一部又は全部を行い、その処理によって前述した実施の形態の機能が実現されるようにしてもよい。さらに、記憶媒体から読み出されたプログラムコードが、コンピュータ上のメモリに書きこまれた後、そのプログラムコードの指示に基づき、コンピュータのＣＰＵなどが実際の処理の一部又は全部を行い、その処理によって前述した実施の形態の機能が実現されるようにしてもよい。

また、実施の形態の機能を実現するソフトウェアのプログラムコードを、ネットワークを介して配信することにより、それをシステム又は装置のハードディスクやメモリ等の記憶手段又はＣＤ−ＲＷ、ＣＤ−Ｒ等の記憶媒体に格納し、使用時にそのシステム又は装置のコンピュータ（又はＣＰＵやＭＰＵ）が当該記憶手段や当該記憶媒体に格納されたプログラムコードを読み出して実行するようにしても良い。

１００００：サーバ、２００００：ストレージ装置、３００００：管理サーバ、３５０００：WEBブラウザ起動サーバ、４００００：IPスイッチ、４５０００：ネットワーク

Claims (15)

1. 監視対象のノード装置と、ネットワークを介して前記ノード装置と接続され、前記ノード装置を管理する管理システムと、を含む計算機システムにおけるシステム管理方法であって、
   前記管理システムが、前記ノード装置を構成する構成デバイスの処理性能を示す処理性能値を取得し、
   前記管理システムが、前記構成デバイスについて設定された閾値と前記取得した処理性能値との比較に基づいて、前記構成デバイスの性能の異常を検知し、
   前記管理システムが、前記ノード装置で発生し得る１つ以上の条件イベントの組み合わせと、前記条件イベントの組み合わせの根本原因とされる結論イベントとの関係を示す解析ルールと、前記検知した各構成デバイスの性能とを照合することにより、前記閾値修正の必要がある構成デバイスを特定し、
   前記管理システムが、前記特定された構成デバイスの前記閾値を調整し、調整後の閾値を用いて前記ノード装置を管理する、
   ことを特徴とするシステム管理方法。
2. 請求項１において、
   前記閾値を調整する際に、前記管理システムが、前記特定された構成デバイスを有する前記ノード装置とは異なる他のノード装置における、前記特定された構成デバイスと同一の構成デバイスの閾値についても、前記調整後の閾値に変更することを特徴とするシステム管理方法。
3. 請求項２において、
   さらに、前記管理システムが、前記管理サーバの情報を表示するための表示デバイスの表示画面上に前記調整後の閾値を表示することを特徴とするシステム管理方法。
4. 請求項２において、
   前記解析ルールは、前記条件イベントとして、障害の根本原因に直接関係する原因イベント及び前記障害が発生する場合に前記原因イベントと共に発生する関連イベントの組み合わせを有し、
   前記閾値修正の必要がある構成デバイスを特定する際に、前記管理システムが、前記原因イベントが発生状況に応じた前記関連イベントの発生の有無を検知し、前記関連イベントの発生率に基づくことを特徴とするシステム管理方法。
5. 請求項４において、
   前記閾値を調整する際、前記管理システムが、予め決められた変更幅を示す修正ルールに従って、前記調整後の閾値を算出することを特徴とするシステム管理方法。
6. 請求項４において、
   前記閾値を調整する際、前記管理システムが、前記特定された構成デバイスの測定性能値の平均を演算し、当該平均値を前記調整後の閾値とすることを特徴とするシステム管理方法。
7. 請求項２において、
   前記管理サーバは、前記構成デバイスの種類に応じた前記閾値の補正の優先度に関する情報をメモリに有し、
   前記解析ルールは、前記条件イベントとして、障害の根本原因に直接関係する原因イベント及び前記障害が発生する場合に前記原因イベントと共に発生する関連イベントの組み合わせを有しており、
   前記原因イベントを生じさせる構成デバイスの優先度は、前記関連イベントを生じさせる構成デバイスの優先度よりも高く設定されており、
   前記方法は、さらに、
   前記管理システムが、検討対象の前記構成デバイスについて、前記原因イベントの発生及び前記関連イベントの発生の有無と、前記優先度が低く設定されている構成デバイスの基準閾値を管理し、
   前記管理システムが、前記優先度が低く設定されている構成デバイスと同一のデバイスを有する他のノード装置の閾値が、前記基準閾値よりも厳格に設定されているか判断し、
   前記管理システムが、前記他のノード装置の閾値が前記基準閾値よりも厳格に設定されている場合には、前記検討対象の構成デバイスを前記閾値調整の対象から外す、
   ことを特徴とするシステム管理方法。
8. 監視対象のノード装置とネットワークを介して接続され、前記ノード装置を管理する管理システムであって、
   前記ノード装置の各構成デバイスの処理性能を示す処理性能値を取得するプロセッサと、
   前記ノード装置で発生し得る１つ以上の条件イベントの組み合わせと、前記条件イベントの組み合わせの根本原因とされる結論イベントとの関係を示す解析ルールを格納するメモリと、を有し、
   前記プロセッサは、前記取得した処理性能値と、前記各構成デバイスについて設定された閾値と比較に基づいて、前記各構成デバイスの性能の異常を検知し、前記解析ルールと前記検知した各構成デバイスの性能とを照合することにより、前記閾値修正の必要がある構成デバイスを特定すると共に、当該特定された構成デバイスの前記閾値を調整することを特徴とする管理システム。
9. 請求項８において、
   前記プロセッサは、前記特定された構成デバイスを有する前記ノード装置とは異なる他のノード装置における、前記特定された構成デバイスと同一の構成デバイスの閾値についても、前記調整後の閾値に変更することを特徴とする管理システム。
10. 請求項９において、
    前記プロセッサは、表示デバイスの表示画面上に前記調整後の閾値を表示することを特徴とする管理システム。
11. 請求項９において、
    前記メモリは、前記解析ルールの前記条件イベントとして、障害の根本原因に直接関係する原因イベント及び前記障害が発生する場合に前記原因イベントと共に発生する関連イベントの組み合わせを有し、
    前記プロセッサは、前記原因イベントが発生状況に応じた前記関連イベントの発生の有無を検知し、前記関連イベントの発生率に基づいて、前記閾値修正の必要がある構成デバイスを特定することを特徴とする管理システム。
12. 請求項１１において、
    前記プロセッサは、予め決められた変更幅を示す修正ルールに従って前記閾値を調整し、前記調整後の閾値を算出することを特徴とする管理システム。
13. 請求項１１において、
    前記プロセッサは、前記特定された構成デバイスの測定性能値の平均を演算し、当該平均値を前記調整後の閾値とすることを特徴とする管理システム。
14. 請求項９において、
    前記管理システムは、前記構成デバイスの種類に応じた前記閾値の補正の優先度に関する情報をメモリに有し、
    前記メモリは、前記解析ルールの前記条件イベントとして、障害の根本原因に直接関係する原因イベント及び前記障害が発生する場合に前記原因イベントと共に発生する関連イベントの組み合わせを有しており、
    前記原因イベントを生じさせる構成デバイスの優先度は、前記関連イベントを生じさせる構成デバイスの優先度よりも高く設定されており、
    前記プロセッサは、検討対象の前記構成デバイスについて、前記原因イベントの発生及び前記関連イベントの発生の有無と、前記優先度が低く設定されている構成デバイスの基準閾値を管理し、前記優先度が低く設定されている構成デバイスと同一のデバイスを有する他のノード装置の閾値が、前記基準閾値よりも厳格に設定されているか判断し、前記他のノード装置の閾値が前記基準閾値よりも厳格に設定されている場合には、前記検討対象の構成デバイスを前記閾値調整の対象から外すことを特徴とする管理システム。
15. 請求項８において、
    前記ノード装置は、１つ以上のストレージ装置、及び１つ以上のホストコンピュータを含み、
    前記ストレージ装置は、前記構成デバイスとして、コントローラとI/Oポートを含み、
    前記ホストコンピュータは、前記構成デバイスとして、ドライブを含み、
    前記メモリは、前記解析ルールの前記条件イベントとして、障害の根本原因に直接関係する原因イベント及び前記障害が発生する場合に前記原因イベントと共に発生する関連イベントの組み合わせを有し、
    前記プロセッサは、前記原因イベントが発生したときの前記関連イベントの発生の有無を検知し、前記関連イベントの発生率に基づいて、前記閾値修正の必要がある構成デバイスを特定し、予め決められた変更幅を示す修正ルールに従って前記特定された構成デバイスの前記閾値を調整する、或いは、前記特定された構成デバイスの測定性能値の平均を演算し、当該平均値を前記調整後の閾値とし、表示デバイスの表示画面上に前記調整後の閾値を表示すると共に、前記特定された構成デバイスを有する前記ノード装置とは異なる他のノード装置における、前記特定された構成デバイスと同一の構成デバイスの閾値についても、前記調整後の閾値に変更することを特徴とする管理システム。

Images