JP2006107126A

JP2006107126A - ストレージネットワーク性能情報の収集・保存方法及び計算機システム並びにプログラム

Info

Publication number: JP2006107126A
Application number: JP2004292849A
Authority: JP
Inventors: Hiroyuki Ochi; 啓之越智; Hideo Ohata; 秀雄大畑; Akira Takeda; 景武田
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2004-10-05
Filing date: 2004-10-05
Publication date: 2006-04-20
Anticipated expiration: 2024-10-05
Also published as: US7277821B2; US20060085166A1; US7143008B2; JP4560367B2; US20070043537A1

Abstract

【課題】アプリケーションの性能劣化の原因を確実に追究可能にするストレージネットワーク性能情報の収集・保存方法を提供する。
【解決手段】ホストサーバ２０５及びストレージ装置２２４を含むストレージネットワーク２の構成要素から収集・保存した性能情報を、アプリケーション２４０の性能劣化の調査に用いられる可能性の有無を自動的に判別し、この判別結果に応じて重要度を決定する。そして、重要度が高い性能情報の保存期間を長く設定し、重要度の低い性能情報の保存期間を短く設定する。そして、性能情報毎に設定された保存期間が過ぎると、該当する性能情報を削除する。
【選択図】図１

Description

本発明は、ストレージネットワークを構成するハードウェア装置ならびに同装置で稼動するソフトウェアに関する性能情報を収集し、保存する方法に係り、特にネットワークが大規模となり性能情報の収集対象となる構成要素の数が膨大になる場合に好適なストレージネットワーク性能情報の収集・保存方法に関する。

ネットワークを経由して複数のホストサーバから統合化されたストレージ装置にアクセスする構成をとるストレージネットワーク（ＳＡＮ）は、大規模化が進むストレージの利用効率を高め管理コストを削減するためのデータセンタ用アーキテクチャとして広く普及しつつある。このようなストレージネットワーク環境（以下、ＳＡＮ環境）で業務システムの性能監視やチューニングを行うには、ネットワークを構成するさまざまなハードウェア装置ならびにソフトウェアに関する性能情報を包括的に収集して、その相互間の関係や時間的な推移を把握することが必要になる。

計算機と外部記憶装置が直結されたサーバ単位で各業務システムが独立していた従来のアーキテクチャと異なり、ＳＡＮ環境ではネットワーク装置やストレージ装置等を複数の計算機で共有する。ＳＡＮの共用部分では各計算機で実行される業務システム間で性能上の干渉が生じる可能性がある。このため性能情報を包括的に収集して、計算機、ネットワーク装置、ストレージ装置の相互間の関係や時間的な性能の推移を把握する。

ＳＡＮを対象にした従来の性能管理ソフトウェアでは、性能監視対象となるハードウェア装置やソフトウェアごとにネットワーク内に配置したエージェントと、ネットワーク全体の性能情報を一元管理する管理ソフト（ストレージ管理ソフトウェア）からなる構成をとって上記要求に応えている。

各エージェントはそれぞれの監視対象と直接通信して性能情報を取得し、一方、管理ソフトウェアは、各エージェントが取得した性能情報を収集・保存し、ストレージネットワーク管理者等からの要求に応じて性能情報を提供する。

ＳＡＮを基盤にしたストレージ統合の普及とともに、大規模化したネットワークの構成要素（リソース）の数が膨大となり、その相互関係も複雑化する傾向にある。このリソースの増大と複雑化に伴い、ストレージ管理ソフトが保存対象とする性能情報も膨大になる。しかし、ストレージ装置の限られた記憶容量内で、効果的に性能情報を保存するため、次のような方法が採られている。

方法１：一度収集した性能情報を、ストレージ管理者が指定した一定期間のみ保存し、一定期間が過ぎると削除する方法。

方法２：保存容量の上限値を決め、上限値を超える都度、過去の性能情報から削除する方法。

方法３：収集した粒度の細かい性能情報を、より粒度の荒い値に時系列方向に集約し、粒度の荒い性能情報ほど長期間保存する方法。例えば、毎分の性能情報を６０回取得した後、それらの値の平均値といった統計情報を計算し、毎時の性能情報を得る。毎分の性能情報に比べ粒度の荒い毎時の性能情報を長期間保存する。なお、粒度とは、単位時間当たりの性能情報のサンプル数を示し、単位時間当たりのサンプル数が多ければ粒度は細かくなり、単位時間当たりのサンプル数が少なければ粒度は荒くなる。

上記方法３を、ネットワークのトラフィックデータに対して適用した例として、特許文献１が知られている。
米国特許第５２３１５９３号

ＳＡＮに対するＩ／Ｏ実行を行うアプリケーションに性能劣化が発生した場合、ＳＡＮの管理者は、性能劣化の原因を調査する必要がある。性能劣化原因の調査は、ストレージ管理ソフトウェアが保存している性能情報のうち、アプリケーションが性能劣化を起こした時刻前後に、アプリケーションの発行するＩ／Ｏ命令の実行に関わった装置の性能情報を閲覧することで行う。性能劣化の原因調査には、粒度の細かい性能情報が必要とされる。

しかしながら、アプリケーションに性能劣化が起きてから、性能劣化が発覚し、ＳＡＮ管理者が性能劣化原因の調査を開始するまでに、数日のブランクがあることがある。このような場合には、上記した方法１〜３を用いても、調査開始時には粒度の細かい性能情報が消去されていることがあり、性能劣化原因を追究できない、という問題があった。

そこで、本発明は、アプリケーションの性能劣化の原因を確実に追究可能にするストレージネットワーク性能情報の収集・保存方法を提供することを目的とする。

本発明は、計算機及びストレージ装置を含むストレージネットワークの構成要素から収集・保存した性能情報を、アプリケーションの性能劣化の調査に用いられる可能性の有無を自動的に判別し、この判別結果に応じて重要度を決定する。そして、重要度が高い性能情報の保存期間を長く設定し、重要度の低い性能情報の保存期間を短く設定する。そして、性能情報毎に設定された保存期間が過ぎると、該当する性能情報を削除する。

したがって、本発明は、ストレージネットワークに対しＩ／Ｏ実行を行うアプリケーションで性能劣化が発生した場合、性能劣化の原因調査に必要となる性能情報を自動的に絞込み、この絞込結果に限定して所定の時間保存することが可能となり、性能情報を格納するためのデータ記憶容量の増大を抑制しながら、性能劣化の原因追及に必要な性能情報についてのみ長期に渡って保存でき、性能劣化の調査が可能となる。

以下、本発明の一実施形態を添付図面に基づいて説明する。

図１は、本発明を適用するシステム構成図である。ローカルエリアネットワーク（ＬＡＮ）２０４には、ホストサーバ２０５〜２０７と業務クライアント２０１〜２０３が接続される。各業務クライアント２０１〜２０３は、ホストサーバ２０５〜２０７上で実行されるアプリケーション２４０のサービス（業務の提供）を受ける。

各ホストサーバ２０５〜２０７は、ストレージネットワーク（ＳＡＮ）２を介してストレージサブシステム２２４〜２２６に接続され、データなどの読み書きを行う。ＳＡＮ２は、例えば、ファイバーチャネル等で構成されており、複数のＳＡＮスイッチ３２０〜３２３がホストサーバ２０５〜２０７とストレージサブシステム２２４〜２２６に接続される。なお、ＬＡＮ２０４には、図示しないＳＡＮ管理用のサーバが接続され、各ＳＡＮスイッチ３２０〜３２３の設定を行う。このため、ＬＡＮ２０４はＳＡＮスイッチ３２０〜３２３にも接続される。

ＬＡＮ２０４には、ＳＡＮ２とストレージサブシステム２２４〜２２６の性能情報を収集する性能情報収集サーバ２３０と、性能情報収集サーバ２３０及び後述するようにホストサーバの各監視エージェントが収集した性能情報を管理する性能管理サーバ２３４と、性能管理サーバ２３４を操作するための性能管理クライアント１４４も接続される。

性能情報収集サーバ２３０は、ＳＡＮ２とストレージサブシステム２２４〜２２６の性能を監視するため、ＳＡＮスイッチ３２０〜３２３にも接続される。また、性能管理サーバ２３４は、ＬＡＮ２０４だけではなく、ＳＡＮ２のＳＡＮスイッチ３２０〜３２３のいずれかと接続するポートを有し、ストレージサブシステム２２４〜２２６へアクセス可能としてもよい。

次に、ＳＡＮ２を介して接続されたホストサーバ２０５〜２０７とストレージサブシステム２２４〜２２６を監視して、性能情報を監視、収集する性能管理システムの概要について説明する。

図１において、ホストサーバ２０５〜２０７では、それぞれＯＳ２０９、ファイルシステム２０８及びアプリケーション２４０が稼動し、さらにホストサーバ２０５〜２０７を監視して性能情報を収集するホスト監視エージェント２１０と、各アプリケーション２４０を監視して性能情報を収集するアプリケーション監視エージェント２４１が稼動する。

ホスト監視エージェント２１０は、各ホストサーバ２０５〜２０７上でそれぞれ実行されて、各ホストサーバ２０５〜２０７を監視して性能情報を収集する。ホスト監視エージェント２１０は、収集した性能情報をストレージサブシステム２２４〜２２６の予め設定された領域に格納する。そして、ホスト監視エージェント２１０は、性能管理サーバ２３４との間で通信を行って、後述するように取得した性能情報を、性能管理サーバ２３４のＳＡＮ性能管理ソフトウェア１０７に提供する。

ここで、ホスト監視エージェント２１０が監視する対象としては、例えば、ホストサーバ２０５〜２０７のファイルシステム２０８のＩ／Ｏ回数、各ホストサーバ２０５〜２０７に割り当てられたボリュームのＩ／Ｏ回数、ホストサーバ２０５〜２０７に設けたＳＡＮ２と通信するポートのＩ／Ｏ回数などを性能の監視対象とし、これら監視対象の性能情報を収集し、ストレージシステムの所定の領域に格納する。

アプリケーション監視エージェント２４１は、各ホストサーバ２０５〜２０７上のアプリケーション２４０をそれぞれ監視して性能情報を収集するもので、各ホストサーバ２０５〜２０７上のアプリケーション２４０毎に実行される。

アプリケーション監視エージェント２４１は、収集した性能情報をストレージサブシステム２２４〜２２６の予め設定された領域に格納する。そして、ホスト監視エージェント２１０は、性能管理サーバ２３４との間で通信を行って、ＳＡＮ性能管理ソフトウェア２３４に取得した性能情報を提供する。

ここで、アプリケーション監視エージェント２４１が監視する対象としては、例えば、各アプリケーション２４０のレスポンスタイム（ターンアラウンドタイム）であり、各業務クライアント２０１〜２０３からの要求を受信してからこの要求に応答するまでのレスポンスタイムを監視する。

さらに、アプリケーション監視エージェント２４１は、後述するように、レスポンスタイムが予め設定した値よりも悪化した場合には、アプリケーション２４０の性能劣化を判定し、性能が劣化した期間を検出する。そして、アプリケーション監視エージェント２４１は、アプリケーション２４０の性能が劣化した期間を、ストレージサブシステム２２４〜２２６の予め設定された領域に格納する。そして、アプリケーション監視エージェント２４１は、性能管理サーバ２３４との間で通信を行って、格納した性能情報を提供する。

性能情報収集サーバ２３０では、ＳＡＮ２のＳＡＮスイッチ３２０〜３２３を監視して性能情報を収集するＳＡＮスイッチ監視エージェント２３１と、ストレージサブシステム２２４〜２２６を監視して性能情報を収集するストレージサブシステム監視エージェント２３２が稼動する。

ＳＡＮスイッチ監視エージェント２３１は、各ＳＡＮスイッチ３２０〜３２３をそれぞれ監視して性能情報を収集するものである。

ＳＡＮスイッチ監視エージェント２３１は、収集した性能情報をストレージサブシステム２２４〜２２６の予め設定された領域に格納する。そして、ＳＡＮスイッチ監視エージェント２３１は、性能管理サーバ２３４との間で通信を行って、取得した性能情報をＳＡＮ性能管理ソフトウェア１０７に提供する。

ここで、ＳＡＮスイッチ監視エージェント２３１が監視する対象としては、例えば、各ＳＡＮスイッチ３２０〜３２３の単位時間あたりのＩ／Ｏ回数であり、この監視対象の性能情報を収集し、ストレージシステムの所定の領域に格納する。

ストレージサブシステム監視エージェント２３２は、各ストレージサブシステム２２４〜２２６をそれぞれ監視して性能情報を収集するものである。

ストレージサブシステム監視エージェント２３２は、収集した性能情報をストレージサブシステム２２４〜２２６の予め設定された領域に格納する。そして、ストレージサブシステム監視エージェント２３２は、性能管理サーバ２３４との間で通信を行って、収集した性能情報をＳＡＮ性能管理ソフトウェア１０７に提供する。

ここで、ストレージサブシステム監視エージェント２３２が監視する対象としては、例えば、各ストレージサブシステムの単位時間あたりのＩ／Ｏ回数であり、より具体的には、後述するように、各ストレージサブシステムのポートの単位時間あたりのＩ／Ｏ回数、各ボリューム（論理ボリューム）の単位時間あたりのＩ／Ｏ回数、ＲＡＩＤグループ毎の単位時間あたりのＩ／Ｏ回数等から構成される。

そして、性能管理サーバ２３４上では、上記各エージェントが収集した性能情報を管理するストレージネットワーク（ＳＡＮ）性能管理ソフトウェア１０７が実行される。

ＳＡＮ性能管理ソフトウェア１０７は、後述する図４１のように、アプリケーション監視エージェント２４１が性能の悪化を検出した場合には、該当するアプリケーション２４０の性能が劣化した期間について、このアプリケーション２４０に関連するＳＡＮ２上のリソースの性能情報について、保存期間を重要データとして延長する。

なお、性能の劣化に関与しないリソースの性能情報については、通常データとして所定の保存期間を設定する。

そして、通常の保存期間と重要データの保存期間が経過した性能情報について削除を行う。

つまり、本性能管理システムでは、ＳＡＮ２上の障害や設定の不具合などを、アプリケーション２４０の性能情報（レスポンスタイム）から判定し、後述するように性能劣化が生じたアプリケーション２４０が利用するＩ／Ｏパス（経路情報）に係わるＳＡＮ２上のリソースの性能情報を、重要データとして通常よりも長い保存期間に設定し、後に障害等の追究が可能とする。

一方、アプリケーション２４０の性能劣化に関連しないＳＡＮ２上のリソースの性能情報については、重要データに比して期間の短い通常の保存期間まで保存し、通常の保存期間が経過した後に削除する。

これにより、性能情報を格納する記憶領域が膨大になるのを防ぎながらも、アプリケーション２４０に性能の劣化が生じてから、通常データの保存期間が過ぎた後であっても、アプリケーション２４０のＩ／Ｏパスに関連するリソースについては、粒度の細かい性能情報が保存されているので、アプリケーション２４０の性能劣化の原因を追究することが可能となるのである。

図２は、上記図１に示した性能管理システムの機能の概要を示す説明図である。この図２において、ストレージネットワーク構成装置・ソフトは、上記図１に示した、ＳＡＮ２、ストレージサブシステム２２４〜２２６、ホストサーバ２０５〜２０７のハードウェア及びＯＳ、ファイルシステム等のＳＡＮ２に関連するリソースを示す。

また、装置管理エージェント２０は、上記図１のＳＡＮスイッチ監視エージェント２３１、ストレージサブシステム監視エージェント２３２、ホスト監視エージェント２１０の総称であり、ＳＡＮ２上のリソースのそれぞれを監視して性能情報を収集し格納するものである。

各ストレージネットワーク構成装置・ソフトは、ＳＡＮ２上の各リソースの性能情報を取得する性能情報取得機能１０８と、各リソースの構成情報を取得する構成情報取得機能１１４を持つ。

各装置監視エージェント２０は、ＳＡＮ２上のリソースの性能情報を収集する性能情報収集機能１０９と、収集した性能情報をメトリクス値に変換するメトリクス値テーブル１１０と、ＳＡＮ性能管理ソフトウェア１０７に対して性能情報（メトリクス値）の通知等を行う性能情報応答機能１１１、ＳＡＮ２上のリソースから構成情報を取得する構成情報収集機能１１５、ＳＡＮ２上のリソースをアプリケーション２４０のＩ／Ｏパスに基づいて、リソース間の関連を記憶するリソース間関連情報記憶部１１６、取得した構成情報をＳＡＮ性能管理ソフトウェア１０７に応答する構成情報応答機能１１７を持つ。

ホストサーバ２０５〜２０７で実行される各アプリケーション２４０は、各アプリケーション２４０が利用するＳＡＮ２上のリソースを取得する構成情報取得機能１２６を持ち、各アプリケーション２４０の性能（例えば、レスポンスタイム）をログ１３０に出力する。

アプリケーション監視エージェント２４１は、アプリケーション２４０が利用するＳＡＮ２上のリソースの構成情報を収集する構成情報収集機能１２７、アプリケーション２４０が利用するＳＡＮ２上のリソースの関連を保存するリソース間関連情報記憶部１２８、上記構成情報が取得した構成情報をＳＡＮ性能管理ソフトウェア１０７に応答する構成情報応答機能１２９、ログ１３０を読み込んでアプリケーション２４０の劣化を検出するアプリケーション性能劣化期間検出機能１３１、アプリケーション２４０の劣化の判定を行うための情報を示すアプリケーション性能劣化期間決定ルール１３２、上記劣化が検出された期間を性能劣化として記憶するアプリケーション性能劣化期間テーブル１３４と、アプリケーション性能劣化期間テーブル１３４の情報をＳＡＮ性能管理ソフトウェア１０７に応答するアプリケーション性能劣化情報応答機能１３５を持つ。

ＳＡＮ性能管理ソフト１０７は、各装置監視エージェント２０からＳＡＮ２上のリソースの性能情報を収集する性能情報収集機能１１２と、性能情報として収集したメトリクス値を格納するメトリクス値テーブル１１９と、ＳＡＮ２上のリソースの構成情報を収集する構成情報収集機能１１８と、ＳＡＮ２上のリソースの関係を記憶するリソース間関連情報記憶部１１９と、アプリケーション監視エージェント２４１から性能劣化に関する情報を収集するアプリケーション性能劣化情報収集機能１３６と、アプリケーション毎に性能劣化期間を保存するアプリケーション性能劣化期間テーブル１３７と、通常データと重要データの識別を行ってアプリケーションの性能劣化に関する性能情報の保存期間を延長する削除非対象リソース算出機能１３８及び削除データ制御テーブル１３９と、保存期間を過ぎたメトリクス値（性能情報）をストレージサブシステム２２４〜２２６の所定の領域から削除するメトリクス削除機能１４０と、ＳＡＮ２上のリソース毎にメトリクス値の保存期間を設定するメトリクス保存期間テーブル１４１と、アプリケーション２４０の劣化を判定するための目標値を設定するアプリケーション目標性能設定機能１３３と、性能情報と収集したメトリクス値の保存期間を設定するメトリクス保存期間設定機能１４２と、ＳＡＮ２上のリソースのメトリクス値から性能を分析する性能分析表示機能１４３を持つ。

アプリケーション監視エージェント２４１は、各ホストサーバ２０５〜２０７上で実行され、各ホストサーバのアプリケーション２４０の性能劣化を検出するソフトウェアである。アプリケーション監視エージェント２４１は、アプリケーションおよびアプリケーションが利用するファイルシステムとの対応関係も検出する。

ＳＡＮ２の性能情報の収集と監視は以下のように行なわれる。装置監視エージェント２１の性能情報収集機能１０９は、予め設定したスケジューリング設定に従い定期的にタイマーによって起動されるか、ＳＡＮ性能管理ソフトウェア１０７の要求で起動されると、自エージェントが担当するストレージネットワーク構成装置・ソフト２１が持つ性能情報取得機能１０８に対し、メトリクスの測定値の送信を要求する。ストレージネットワーク構成要素（リソース）の個々の性能情報で、性能監視の候補となるものをメトリクスと呼ぶ。そして、このメトリクスは収集した性能情報を示し、例えば、種類の異なる各性能情報を相互に比較可能とするため、性能情報を変換したものである。

上記装置監視エージェント２０からの要求に応えて、ＳＡＮ２上のリソースの性能情報取得機能１０８から返信されたメトリック値は、装置監視エージェント２０の性能情報収集機能１０９によってメトリクス値テーブル１１０に格納される。

ＳＡＮ性能管理ソフトウェア１０７の性能情報収集機能１１２も同様に、予め設定したスケジューリング設定に従い定期的に起動され、装置監視エージェント２０の性能情報応答機能１１１に対してメトリクス値の送信を要求する。この要求を受けた装置監視エージェント２０は、性能情報応答機能１１１から要求されたメトリクス値をメトリクス値テーブル１１０から検索し、ＳＡＮ性能管理ソフトウェア１０７の性能情報収集機能１１２に返信する。ＳＡＮ性能管理ソフトウェア１０７は、装置監視エージェント２０の性能情報応答機能１１１から返信されたメトリクス値を、性能情報収集機能１１２によってメトリクス値テーブル１１３に格納する。

ＳＡＮ２の構成要素で、ひとまとまりのメトリクス値を取得する単位となるものをリソースと呼ぶ。リソースとリソース間の関連については、後述の図３で説明する。また、ＳＡＮ性能管理ソフトウェア１０７の性能分析表示機能１４３が性能管理クライアント１４４に表示する画面の具体例を図９で説明する。

リソース間の関連情報の収集は、上記性能情報の場合と同様、以下のように行なわれる。

装置監視エージェント２０の構成情報収集機能１１５は、予め設定されたスケジューリング設定で定期的に起動されるか、ＳＡＮ性能管理ソフトウェア１０７の要求で起動され、自エージェント２０が担当するストレージネットワーク構成装置・ソフト２１の構成情報取得機能１１４に対しリソース間関連情報の送信を要求し、要求した情報が返信されるとリソース間の構成情報に基づくリソース間の関連情報をリソース間関連情報記憶部１１６に格納する。

ＳＡＮ性能管理ソフトウェア１０７の構成情報収集機能１１８は、予め設定したスケジューリング設定で定期的に起動され、監視エージェント２０の構成情報応答機能１１７に対し各エージェント２０が収集したリソース間関連情報の送信を要求し、要求した情報が各装置監視エージェント２０のリソース間関連情報記憶部１１６から検索されて返信されると、この情報をリソース間関連情報記憶部１１９に格納する。

リソース間の関連情報の収集は、アプリケーション監視エージェント２４１に対しても同様に行う。アプリケーション監視エージェント２４１の構成情報収集機能１２７は、予め設定されたスケジューリング設定で定期的に起動されるか、ＳＡＮ性能管理ソフトウェア１０７の要求に基づいて起動され、自エージェント２４１が担当するアプリケーション２４０の構成情報取得機能１２６に対しリソース間関連情報の送信を要求し、要求した情報がＳＡＮ性能管理ソフトウェア１０７に返信されると、ＳＡＮ性能管理ソフトウェア１０７はリソース間関連情報記憶部１２８に格納する。

ＳＡＮ性能管理ソフトウェア１０７の構成情報収集機能１１８は、アプリケーション監視エージェント２４１の構成情報応答機能１２９に対しても、各エージェント２４１が収集したリソース間関連情報の送信を要求する。アプリケーション監視エージェント２４１では、要求した情報がＳＡＮ性能管理ソフトウェア１０７から返信されると、これらの情報をリソース間関連情報記憶部１２８から検索されて返信されるとリソース間関連情報記憶部１１９に格納する。

ＳＡＮ性能管理ソフトウェア１０７の性能分析表示機能１４３は、性能管理クライアント１４４からの要求に応答し、メトリクス値テーブル１１３中のメトリック値を検索して返信する。性能管理クライアント１４４からの性能分析の要求に応えるため、性能分析表示機能１４３はネットワーク構成要素間の関係を利用する場合があるが、これに関する情報はリソース間関連情報記憶部１１９から検索される。

アプリケーション監視エージェント２４１によるアプリケーション２４０の性能劣化期間の検出および格納は以下のように行われる。

アプリケーション監視エージェント２４１のアプリケーション性能劣化期間検出機能１３１は、予め設定したスケジューリング設定で定期的に起動されるか、ＳＡＮ性能管理ソフトウェア１０７のアプリケーション性能劣化情報収集機能１３６の要求で起動され、自エージェント２４１が担当するアプリケーション２４０のログ１３０を収集する。

アプリケーション２４０は、性能劣化検出に必要な情報をログに書き込む。アプリケーション監視エージェント２４１のアプリケーション性能劣化期間検出機能１２７は、ログ１３０を読み込んで解析し、アプリケーション性能劣化期間決定ルール１３２に基づいて、アプリケーション１２８の性能劣化期間を検出し、アプリケーション性能劣化期間テーブル１３４に書き込む。アプリケーション性能劣化期間決定ルール１３２は、ストレージネットワーク管理ソフト１０７のアプリケーション目標性能設定機能１３３によって設定される。アプリケーション目標性能設定機能１３３は、性能管理クライアント１４４から操作される。ＳＡＮ性能管理ソフトウェア１０７のアプリケーション性能劣化情報収集機能１３６は、予め設定されたスケジューリング設定で定期的に起動され、監視エージェント２０のアプリケーション性能劣化情報応答機能１２９に対し各エージェントが検出したアプリケーション性能劣化期間の送信を要求し、要求した情報がアプリケーション性能劣化期間テーブル１３４から検索されて返信されると、アプリケーション性能劣化期間テーブル１３７に格納する。

ＳＡＮ性能管理ソフトウェア１０７のアプリケーション目標性能設定機能１３３の詳細は、図３５を用いて詳しく説明する。アプリケーション性能劣化期間検出機能１３１の詳細は、図３７を用いて詳しく説明する。

ＳＡＮ性能管理ソフトウェア１０７が収集したメトリクスの削除は以下のように行われる。

はじめに、ＳＡＮ性能管理ソフトウェア１０７の削除非対象リソース算出機能１３８は、アプリケーション性能劣化期間テーブル１３７を参照し、アプリケーションの性能劣化期間を得る。その後、リソース間関連記憶部１１９を参照し、該アプリケーション２４０の性能劣化期間中に、該アプリケーションと関連のあったリソースを検出する。そして、検出したリソースの結果を、削除データ制御テーブル１３９に格納する。

次に、ＳＡＮ性能管理ソフトウェア１０７のメトリクス削除機能１４０は、削除データ制御テーブル１３９に基づき、メトリクス値テーブル１１３に格納されたメトリクスを削除する。削除の際、メトリクス保存期間テーブル１４１を参照し、メトリクス保存期間を得る。メトリクス保存期間テーブル１４１の値はメトリクス保存期間設定機能１４２により設定される。メトリクス保存期間設定機能１４２は、性能管理クライアント１４４から操作される。

削除非対象リソース算出機能１３８の詳細は、図３８、図３９、図４０を用いて詳しく説明する。メトリクス削除機能１４０の詳細は、図４１、図４２を用いて詳しく説明する。

図３は、リソースならびにリソース間の性能に関する依存関係の具体例を示すソフトウェア及びハードウェアの説明図である。ストレージネットワークを構成する具体的なハードウェア装置やソフトウェアごとにさまざまな種類のリソースがある。個々のストレージネットワーク中のリソースは互いに性能上の影響を及ぼし合う関係にある。

図３において、ホストサーバＡは図１のホストサーバ２０５であり、ホストサーバＢは図１のホストサーバ２０６であり、これらホストサーバＡ、Ｂは、ＳＡＮ２を構成するＳＡＮスイッチ３２０〜３２３を経由してストレージサブシステムＡ（図１のストレージサブシステム２２４）にアクセスする例を示す。

ホストサーバＡのＳＡＮ２側にはポートＡ（３１８）が設けられ、ＳＡＮスイッチ３２０のポートＣ（３２５）、ポートＤ（３２６）、ＳＡＮスイッチ３２２のポートＨ（３３２）、ポートＩ（３３４）を介して、ストレージサブシステムＡのポートＮ（３４１）に接続される。また、ポートＡは、ＳＡＮスイッチのポートＣ（３２５）、ポートＥ（３２７）からＳＡＮスイッチ３２３のポートＪ（３３６）、ポートＬ（３３８）を経由してストレージサブシステムＡのポートＯ（３４２）に接続される。

ホストサーバＢのＳＡＮ２側にはポートＢ（３１９）が設けられ、ＳＡＮスイッチ３２１のポートＦ（３２９）、ポートＧ（３３１）、ＳＡＮスイッチ３２３のポートＫ（３３７）、ポートＭ（３３９）を介して、ストレージサブシステムＡのポートＰ（３４３）に接続される。なお、図中ＳＡＮスイッチ３２０〜３２３のうち、ホストサーバＡ、Ｂ側に配置されたポートをホスト側ポートとし、ストレージサブシステム２２４側に配置されたポートをストレージ側ポートとする。

ホストサーバＡ（２０５）では、アプリケーションＡ（２４０ａ）とアプリケーションＢ（２４０ｂ）が稼働している。また、ホストサーバＡ（２０５）は、ファイルシステムＡ（２０８ａ）〜ファイルシステムＦ（２０８ｆ）とボリュームＡ（３１４）〜ボリュームＣ（３１６）を有する。

ボリュームＡ（３１４）は、後に説明するストレージサブシステムＡの論理ボリュームＡ（３４４）に対しＩ/Ｏ命令を発行できるようにホストサーバＡのＯＳにマウントした仮想ディスクである。ボリュームＢ（３１５）とボリュームＣ（３１６）についても同様で、それぞれ、ストレージサブシステムＡの論理ボリュームＢ（３４５）と論理ボリュームＣ（３４６）をホストサーバＡにマウントした仮想ディスクである。

ホストサーバＢ（２０６）では、ホストサーバＡと同様に、アプリケーションＣ（２４０ｃ）が稼働しており、ホストサーバＢ（２０６）は、ファイルシステムＧ（２０８ｇ）、ファイルシステムＨ（２０８ｈ）とボリュームＤ（３１７）を持つ。

ＳＡＮスイッチＡ（３２０）はポート（３２４）〜（３２７）を備える。ＳＡＮスイッチＡが持つポートのうち、番号（３２５）をポートＣ、番号（３２６）をポートＤ、番号（３２７）をポートＥと呼ぶこととする。

ＳＡＮスイッチＢ（３２１）〜ＳＡＮスイッチＤ（３２３）についても同様で、ＳＡＮスイッチＢはポート（３２８）〜（３３１）を、ＳＡＮスイッチＣはポート（３３２）〜（３３５）を、ＳＡＮスイッチＤはポート（３３６）〜（３３９）を持つ。番号（３２９、３３１、３３２、３３４、３３６、３３７、３３８、３３９）のポートをそれぞれ、ポートＦ、ポートＧ、ポートＨ、ポートＩ、ポートＪ、ポートＫ、ポートＬ、ポートＭと呼ぶこととする。

ストレージサブシステムＡは、物理ディスク３５０〜３５７を有する。物理ディスク３５０〜３５３をＲＡＩＤ構成した仮想ディスクが、ＲＡＩＤグループＡ（３４８）で、物理ディスク（３５４）〜（３５７）によるＲＡＩＤ構成された仮想ディスクがＲＡＩＤグループＢ（３４９）である。ＲＡＩＤグループＡ（３４８）を、上位のサーバが使いやすい大きさにスライスし、スライスされた結果が論理ボリュームＡ（３４４）と論理ボリュームＢ（３４５）である。同様に、ＲＡＩＤグループＢ（３４９）をスライスした結果が論理ボリュームＣ（３４６）と論理ボリュームＤ（３４７）である。

サーバＡでは、アプリケーションの性能劣化検出および構成情報監視のためのアプリケーション監視エージェント２４１と、ホストサーバＡのハードならびにＯＳの性能情報を取得するためのホスト監視エージェント２１０が上記図１と同様に稼動しているものとする。ファイルシステムＡ（３０４）〜ファイルシステムＦ（３０９）と、ボリュームＡ（３１２）〜ボリュームＣ（３１４）、ポートＡ（３１６）は、ホストサーバＡ（２０５）で稼働するホスト監視エージェント２１０が、性能情報取得の対象とするリソースの一例である。ファイルシステムＡ〜Ｈは、各ホストサーバＡ、ＢのＯＳ２０９がデータの入出力管理を行う一つの単位であり、各ボリュームＡ〜Ｄは、ファイルシステム上に作成されるファイルをマウントした外部記憶装置に格納する領域としてＯＳ２０９で管理されるものである。

図３において、リソース間に引かれた線は、性能の依存関係を表わす。図３の例では、アプリケーションＡ（２４０ａ）はファイルシステムＡ（２０８ａ）〜ファイルシステムＤ（２０８ｄ）に対しＩ/Ｏ処理を行う。この場合、アプリケーションＡ（２４０ａ）は、ファイルシステムＡ（２０８ａ）〜ファイルシステムＤ（２０８ｄ）に対しＩ/Ｏ上の負荷をかけることとなり、アプリケーションＡ（２４０ａ）は、ファイルシステムＡ（２０８ａ）〜ファイルシステムＤ（２０８ｄ）に性能上の負荷について依存関係があることとなる。なお、性能の依存関係とは、アプリケーション２４０が発行するＩ／Ｏ命令を処理する一連の装置およびソフトウェアがある場合に、これらの一連の装置およびソフトウェアの接続関係をいう。

図３において、ファイルシステムＡ及びファイルシステムＢとボリュームＡを結ぶ線は、ファイルシステムＡ、ＢがボリュームＡ上に配置される関係を表わしているが、この関係はまた、アプリケーション２４０ａがファイルシステムＡやファイルシステムＢに対して操作を行った場合に、ボリュームＡへ操作がつながるため、性能上の負荷について依存関係があることも表わしている。ボリュームＡ〜ボリュームＣとホストサーバＡポートＡの間の線も同様に、性能の依存関係がある。

ホストサーバＢでは、同様にアプリケーション監視エージェント２４１とホスト監視エージェント２１０が稼動しているものとする。ホストサーバＢのホスト監視エージェント２１０が性能情報取得対象とするリソースには、ファイルシステムＧ（２０８ｇ）〜ファイルシステムＨ（２０８ｈ）と、ボリュームＤ（３１５）、ポートＢ（３１７）がある。

ＳＡＮスイッチＡ〜ＳＡＮスイッチＤの性能情報を取得するため性能収集ソフトウェア。ＳＡＮスイッチ管理エージェント２３１が稼動しているものとする。このＳＡＮスイッチ管理エージェント２３１が性能情報の取得対象とするリソースには、ＳＡＮスイッチＡのポート（３２２、３２３、３２６、３２７）、スイッチＢのポート（３２４、３２５、３２８、３２９）、スイッチＣのポート（３２２、３２３、３２６、３２７）、スイッチＤのポート（３２４、３２５、３２８、３２９）がある。

ストレージサブシステムＡでは、ストレージサブシステムＡの性能情報を取得するためストレージサブシステム管理エージェント２３２が稼動しているものとする。このストレージサブシステム管理エージェント２３０が情報取得対象とするリソースには、ポートＮ（３４１）〜ポートＰ（３４３）と、論理ボリュームＡ（３４４）〜論理ボリュームＤ（３４７）、ＲＡＩＤグループＡ（３４８）、ＲＡＩＤグループＢ（３４９）、物理ディスク（３５０〜３５７）がある。

各論理ボリュームは予めＲＡＩＤグループに割り当てられ、また、ＲＡＩＤグループは物理ディスクに割り当てられるため、これらリソース間には性能の依存関係がある。また、ホストサーバＡ、Ｂのボリュームと、同ボリュームが割り当てられるストレージサブシステムの論理ボリュームの対が決まると、この両者の間でやり取りされる入出力データの転送経路として、ホストバスアダプタ（ホストサーバＡ、Ｂ）のポート（ＡまたはＢ）から、ＳＡＮスイッチの各ポートを経て、ストレージサブシステムのポートまでが決まる。従って、ホストサーバＡ、Ｂのボリュームにかかる入出力の負荷は経路上のポートに対する通信の負荷となるため、ボリュームおよび論理ボリュームの対と、経路上のポートの間には性能の依存関係がある。

図３の例では、ホストサーバＡのボリュームＡは論理ボリュームＡに割り当てられ、論理ボリュームＡはＲＡＩＤグループＡに割り当てられ、ＲＡＩＤグループＡは物理ディスク３５０〜３５７に割り当てられ、ボリュームＡと論理ボリュームＡの対にポートＡからポートＣ、ポートＤ、ポートＨ、ポートＩ、ポートＮまでの経路が対応し、これらリソース間に性能の依存関係がある。

アプリケーション２４０ａ〜２４０ｃに近い側のリソースを性能の依存関係の上流と呼び、物理ディスクに近い側のリソースを性能の依存関係の下流と呼ぶこととする。図３の例では、アプリケーションＡはファイルシステムＡに対して上流にあたり、ファイルシステムＡはボリュームＡに対して上流にあたる。

図４（Ａ）のテーブルは、装置監視エージェント２１（ホスト監視エージェント２１０、ＳＡＮスイッチ監視エージェント２３１、ストレージサブシステム監視エージェント２３２の各々）が持つメトリクス値テーブル１１０の構造の一例を示す図である。

メトリクス値テーブル１１０は、リソース識別子格納欄４１１とメトリクス識別子格納欄４１２とメトリクス値格納欄４１３と、Ｔ１格納欄４１４と、Ｔ２格納欄４１５からなる。

リソース識別子格納欄４１１には、装置監視エージェント２０が収集対象とするリソースの識別子が格納され、メトリクス識別子格納欄４１２には、収集するメトリクスの種別を示す識別子が格納される。装置監視エージェント２０がメトリクス値格納欄４１３に保存するメトリクス値は、Ｔ１格納欄４１４で指定された時刻を開始時刻とし、Ｔ２格納欄４１５で指定された時刻を終了時刻とする期間内に、リソース識別子格納欄４１１で指定されたリソースから取得した、メトリクス識別子格納欄４１２で指定されたメトリクスの値が装置監視エージェント２０により設定される。

装置監視エージェント２０が監視するメトリクス種別には、レスポンスタイム、スループット、リソース使用量、リソース使用率の４カテゴリがあり、毎秒Ｉ／Ｏ回数は、スループットの一例である。本実施例では、毎秒Ｉ／Ｏ回数をメトリクス識別子としてあげているが、装置やソフトウェアの性能を表わす他のメトリクス識別子に対する本実施例の適用を制限するものではない。

図４（Ｂ）のテーブルは、本実施形態における装置監視エージェント２０の一例である、ホストサーバＡ（２０５）を監視するホスト監視エージェントＡ（図１の２１０）が持つメトリクス値テーブル４０１の内容を示している。

メトリクス値テーブル４０１は、ホスト監視エージェントＡが、該ホスト監視エージェントの監視対象であるファイルシステムＡや、ボリュームＡ、ポートＡ等から１時間おきにメトリクスを収集・保存していることを示している。

メトリクス値テーブル４０１の第１行目には、２０００年１月１１日１０時から２０００年１月１１日１１時の間に、ファイルシステムＡから収集した毎秒Ｉ／Ｏ回数の値が１，２１４．５であったことが記録されている。

図５、図６、図７に示すメトリクス値テーブル５０１、６０１、７０１は、ホスト監視エージェントＡが持つメトリクス値テーブル４０１と同様に、ホストサーバＢ（２０６）のホスト監視エージェントＢが持つメトリクス値テーブル、ストレージ監視エージェント２３２が持つメトリクス値テーブル、ＳＡＮスイッチ監視エージェント２３１が持つメトリクス値テーブルをそれそれ示している。各装置監視エージェント２０が持つメトリクス値テーブルの構造は全て共通であり、リソースの種別を格納するリソース識別子格納欄（５０２、６０２、７０２）、メトリクスの種別を示す値を格納するメトリクス識別子格納欄（５０３、６０３、７０３）、性能情報に応じたメトリクス値を格納するメトリクス値格納欄（５０４、６０４、７０４）、開始日時を格納するＴ１格納欄（５０５、６０５、７０５）、終了日時を格納するＴ２格納欄（５０６、６０６、７０６）からなる。各格納欄の内容も同様である。

図８は、ＳＡＮ性能管理ソフトウェア１０７が使用するメトリクス値テーブル１１３の構造の一例を示す図である。このテーブルの内容は、性能情報収集機能１１２を使って、すべての装置監視エージェント２０から各々が持つメトリクス値テーブルの内容を集めて作成される。メトリクス値テーブル１１３は、メトリクス値テーブル１１０と共通の構造を持っており、リソース識別子格納欄（８０１）、メトリクス識別子格納欄（８０２）、メトリクス値格納欄（８０３）、Ｔ１格納欄（８０４）、Ｔ２格納欄（８０５）からなる。ＳＡＮ性能管理ソフトウェア１０７が使用するメトリクス値テーブル１１３が格納する情報は、性能情報収集機能１１２による収集の時間遅れの期間を除けば、全ての装置監視エージェントが持つアプリケーション・ファイルシステム間関連テーブルの全ての行を合わせたものと一致する。具体的には、メトリクス値テーブル４０１、５０１、６０１、７０１の全行をマージしたものとなる。

図９は、グラフ形式による性能情報の表示画面の一例を示す図であり、ＳＡＮ性能管理ソフトウェア１０７のメトリクス値テーブル１１３が持つ情報に基づいて、メトリクス値の時間的な推移を表示する。本画面は、ＳＡＮ性能管理ソフトウェア１０７の性能分析表示機能１４３によって性能管理クライアント１４４に表示される。グラフの横軸（９０４）と縦軸（９０５）はそれぞれ時刻とメトリクス「毎秒Ｉ／Ｏ回数」（９０２）の値であり、表示内容は、複数のリソース（９０３）のメトリクス値の時間的な推移を示している。

図１０は、アプリケーション監視エージェント２４１が持つリソース間関連情報記憶部１２８にはアプリケーション・ファイルシステム間関連テーブル１００１が含まれることを示している。リソース間関連情報記憶部１２８は、リソース間の性能情報の依存関係を記憶する１つまたは複数のテーブルを格納するための記憶部である。アプリケーション・ファイルシステム間関連テーブル１００１については図１４にて詳しく説明する。

図１１は、図１０と同様に、装置監視エージェントの一つであるホスト監視エージェント２１０が持つリソース間関連情報記憶部１１６にはファイルシステム・ボリューム間関連テーブル１１０１と、ボリューム・論理ボリューム・ＲＡＩＤグループ・ポート間関連テーブル１１０２が含まれることを示している。ファイルシステム・ボリューム間関連テーブル１１０１については図１８を用いて詳しく説明する。また、ストレージサブシステムに関連するボリューム・論理ボリューム・ＲＡＩＤグループ・ポート間関連テーブル１１０２については図２１を用いて詳しく説明する。

図１２は、図１０と同様に、装置監視エージェント２０の一つであるＳＡＮスイッチ監視エージェント２３１が持つリソース間関連情報記憶部１１６にはポート間通信経路テーブル１２０１が含まれることを示している。ポート間通信経路テーブル１２０１については図２４を用いて詳しく説明する。

図１３は、ＳＡＮ性能管理ソフトウェア１０７が持つリソース間関連情報記憶部１１９にはアプリケーション・ファイルシステム間関連テーブル１３０１とファイルシステム・ボリューム間関連テーブル１３０２と、ボリューム・論理ボリューム・ＲＡＩＤグループ・ポート間関連テーブル１３０３とポート間通信経路テーブル１３０４が含まれることを示している。ＳＡＮ性能管理ソフトウェア１０７が持つリソース間関連情報記憶部１１９は、全ての装置監視エージェント２０が収集したリソース間関連情報を収集し、蓄えるための記憶部であり、リソース間関連情報記憶部１１９に含まれるテーブルの内容は、各監視エージェントが持つリソース間関連情報記憶部が持つ、対応したテーブル内の行の合計となる。なお、アプリケーション・ファイルシステム間関連テーブル１３０１については図１７を用いて詳しく説明する。

ファイルシステム・ボリューム間関連テーブル１３０２については図２０を用いて詳しく説明する。ボリューム・論理ボリューム・ＲＡＩＤグループ・ポート間関連テーブル１３０３については図２３を用いて詳しく説明する。ポート間通信経路テーブル１３０４については図２５を用いて詳しく説明する。

図１４（Ａ）のテーブルは、アプリケーション監視エージェント２４１の各々が持つリソース間関連情報記憶部１２８に格納され、アプリケーション・ファイルシステム間関連テーブル１００１の構造の一例を示す図である。

アプリケーション・ファイルシステム間関連テーブル１００１は、図３で説明したアプリケーションとファイルシステムとの間の性能の依存関係を記録するためのものであり、アプリケーションの識別子を格納するアプリケーション識別子格納欄１４１１、ファイルシステムの識別子を格納するファイルシステム識別子格納欄１４１２、有効期間の開始日時を格納する有効期間開始時刻格納欄１４１３、有効期間の終了日時を格納する有効期間終了時刻格納欄１４１４からなる。テーブルの各行は、依存関係があったアプリケーションとファイルシステムの組と、その組に依存関係があった期間１つに対応する。

アプリケーション監視エージェント２４１および装置監視エージェント２０が持つ構成情報収集機能は、予め設定したスケジューリング設定に従い定期的にタイマーによって起動されるか、ＳＡＮ性能管理ソフトウェア１０７の要求で起動されると、監視対象のアプリケーション２４０および装置が持つ構成情報取得機能に対し、該アプリケーションおよび装置に関する性能の依存関係の送信を要求する。例えば、図３に示すホストサーバＡのアプリケーションＡが監視対象であれば、アプリケーションＡが利用するファイルシステム一覧の送信を要求する。アプリケーションＡから受信した性能の依存関係が、前回の収集時に得た関係と変化していなければ、アプリケーション監視エージェント２４１は、有効期間終了時刻を現在時刻で更新する。前回の収集時から性能の依存関係が変化していれば、新たな性能の依存関係を意味する行を追加する。追加する行の有効期間開始時刻は前回の収集時刻とし、有効期間終了時刻は今回の収集時刻とする。初回の収集時の場合、「前回の収集時刻」が存在しないため、その場合は、追加する行の有効期間開始時刻を過去の任意の時刻としてよい。

図１４（Ｂ）のテーブルは、本実施例におけるアプリケーション監視エージェントの一例である、ホストサーバＡ（２０５）上で稼働するアプリケーションＡ（２４０ａ）を監視するアプリケーション監視エージェントＡ（２４１）が持つリソース間関連情報記憶部に格納される、アプリケーション・ファイルシステム間関連テーブル１４０１の内容を示している。アプリケーション・ファイルシステム間関連テーブル１４０１は、テーブル１００１と共通の構造をしており、アプリケーション識別子格納欄１４０２、ファイルシステム識別子格納欄１４０３、有効期間開始時刻格納欄１４０４、有効期間終了時刻格納欄１４０５からなる。アプリケーション・ファイルシステム間関連テーブル１４０１の第１行目には、２０００年１月０１日００：００〜２０００年１月１４日１３：００の間に、アプリケーションＡがファイルシステムＡと性能の依存関係があったことが記録されている。

図１５と図１６に示したアプリケーション・ファイルシステム間関連テーブル１５０１、１６０２は、テーブル１４０１と同様に、ホストサーバＡ（２０５）上で稼働するアプリケーションＢ（２４０ｂ）を監視するアプリケーション監視エージェントＢと、ホストサーバＢ（２０６）上で稼働するアプリケーションＣ（２４０ｃ）を監視するアプリケーション監視エージェントＣが各々持つリソース間関連情報記憶部１２８に格納される、アプリケーション・ファイルシステム間関連テーブルの例である。

このテーブル１５０１、１６０１の構造は、アプリケーション・ファイルシステム間関連テーブル１４０１と同様にアプリケーション識別子格納欄（１５０２、１６０２）、ファイルシステム識別子格納欄（１５０３、１６０３）、有効期間開始時刻格納欄（１５０４、１６０４）、有効期間終了時刻格納欄（１５０５、１６０５）からなる。各格納欄の内容も同様である。

図１７のアプリケーション・ファイルシステム間関連テーブル１３０１は、ＳＡＮ性能管理ソフトウェア１０７が持つリソース間関連情報記憶部１１９が格納するアプリケーション・ファイルシステム間関連テーブルの構造の一例であり、全てのアプリケーション監視エージェントから収集したアプリケーション・ファイルシステム間の依存関係を格納する。該テーブル１３０１の構造は、アプリケーション・ファイルシステム間関連テーブル１４０１と同様にアプリケーション識別子格納欄１７０１、ファイルシステム識別子格納欄１７０２、有効期間開始時刻格納欄１７０３、有効期間終了時刻格納欄１７０４からなる。該テーブル１３０１が格納する情報は、構成情報収集機能１１８による収集の時間遅れの期間を除けば、全アプリケーション監視エージェントが持つアプリケーション・ファイルシステム間関連テーブルの全行をマージしたものと一致する。具体的には、アプリケーション・ファイルシステム間関連テーブル１４０１、１５０１、１６０１の全行をマージしたものとなる。

図１８（Ａ）のテーブルは、ホスト監視エージェント２１０が持つリソース間関連情報記憶部に格納される、ファイルシステム・ボリューム間関連テーブル１１０１の構造の一例である。ファイルシステム・ボリューム間関連テーブル１１０１は、図３で説明したファイルシステムとボリュームとの間の性能の依存関係を記録するためのものであり、ファイルシステム識別子格納欄１８１１とボリューム識別子格納欄１８１２、有効期間開始時刻格納欄１８１３、有効期間終了時刻格納欄１８１４からなる。テーブルの各行は、依存関係があったファイルシステムとボリュームの組と、その組に依存関係があった期間１つに対応する。ホスト監視エージェントが持つファイルシステム・ボリューム間関連テーブルの更新方法は、図１４で説明した方法と同様である。

図１８（Ｂ）のテーブルは、本実施例におけるホスト監視エージェント２１０の一例である、ホストサーバＡ（２０５）を監視するホスト監視エージェントＡが持つリソース間関連情報記憶部に格納される、ファイルシステム・ボリューム間関連テーブル１８０１の内容を示している。ファイルシステム・ボリューム間関連テーブル１８０１は、テーブル１１０１と共通の構造をしており、ファイルシステム識別子格納欄１８０２とボリューム識別子格納欄１８０３、有効期間開始時刻格納欄１８０４、有効期間終了時刻格納欄１８０５からなる。ファイルシステム・ボリューム間関連テーブル１８０１の第１行目には、２０００年１月０１日００：００〜２０００年１月１４日１３：００の間に、ファイルシステムＡがボリュームＡと性能の依存関係があったことが記録されている。

図１９は、テーブル１８０１と同様に、ホストサーバＢ（２０６）を監視するホスト監視エージェントＢが持つリソース間関連情報記憶部に格納される、ファイルシステム・ボリューム間関連テーブル１９０１の例である。ファイルシステム・ボリューム間関連テーブル１９０１の構造は、テーブル１８０１と同様に、ファイルシステム識別子格納欄１９０２、ボリューム識別子格納欄１９０３、有効期間開始時刻格納欄１９０４、有効期間終了時刻格納欄１９０５からなる。各格納欄の内容も同様である。

図２０は、ＳＡＮ性能管理ソフトウェア１０７が持つリソース間関連情報記憶部１１９が格納するファイルシステム・ボリューム間関連テーブル１３０２の例であり、全てのホスト監視エージェントから収集したファイルシステム・ボリューム間の依存関係を格納する。ファイルシステム・ボリューム間関連テーブル１３０２の構造は、テーブル１８０１と共通の構造をしており、ファイルシステム識別子格納欄２００１、ボリューム識別子格納欄２００２、有効期間開始時刻格納欄２００３、有効期間終了時刻格納欄２００４からなる。

ファイルシステム・ボリューム間関連テーブル１３０２が格納する情報は、構成情報収集機能１１８による収集の時間遅れの期間を除けば、全ホスト管理エージェントが持つファイルシステム・ボリューム間関連テーブルの全行をマージしたものと一致する。具体的には、ファイルシステム・ボリューム間関連テーブル１８０１、１９０１の全行をマージしたものとなる。

図２１（Ａ）のテーブルは、ホスト監視エージェント２１０が持つリソース間関連情報記憶部に格納される、ボリューム・論理ボリューム・ＲＡＩＤグループ・ポート間関連テーブル１１０２の構造の一例である。

ボリューム・論理ボリューム・ＲＡＩＤグループ・ポート間関連テーブル１１０２は、図３で説明したボリューム・論理ボリューム・ＲＡＩＤグループ・ホスト側ポート・ストレージ側ポート間の性能の依存関係を記録するためのものであり、ボリュームの識別子を格納するボリューム識別子格納欄２１１１、論理ボリュームの識別子を格納する論理ボリューム識別子格納欄２１１２、所属するＲＡＩＤグループを格納するＲＡＩＤグループ識別子格納欄２１１３、ＳＡＮスイッチのホスト側ポートを格納するホスト側ポート識別子格納欄２１１４、ＳＡＮスイッチのストレージ側のポートを格納するストレージ側ポート識別子格納欄２１１５、有効期間開始時刻格納欄２１１６、有効期間終了時刻格納欄２１１７からなる。テーブルの各行は、依存関係があったボリューム・論理ボリューム・ＲＡＩＤグループ・ポートの組と、その組に依存関係があった期間１つに対応する。ホスト監視エージェントが持つボリューム・論理ボリューム・ＲＡＩＤグループ・ポート間関連テーブルの更新方法は、図１４で説明した方法と同様である。

図２１（Ｂ）のテーブルは、本実施例におけるホスト監視エージェントの一例である、ホストサーバＡ（２０５）を監視するホスト監視エージェントＡが持つリソース間関連情報記憶部に格納される、ボリューム・論理ボリューム・ＲＡＩＤグループ・ポート間関連テーブル２１０１の内容を示している。ボリューム・論理ボリューム・ＲＡＩＤグループ・ポート間関連テーブル２１０１は、テーブル１１０２と共通の構造をしており、ボリューム識別子格納欄２１０２、論理ボリューム識別子格納欄２１０３、ＲＡＩＤグループ識別子格納欄２１０４、ホスト側ポート識別子格納欄２１０５、ストレージ側ポート識別子格納欄２１０６、有効期間開始時刻格納欄２１０７、有効期間終了時刻格納欄２１０８からなる。ボリューム・論理ボリューム・ＲＡＩＤグループ・ポート間関連テーブル２１０１の第１行目には、２０００年１月０１日００：００〜２０００年１月１４日１３：００の間に、ボリュームＡが論理ボリュームＡ、ＲＡＩＤグループＡ、ポートＡ、ポートＮと性能の依存関係があったことが記録されている。

図２２は、テーブル２１０１と同様に、ホストサーバＢ（２０６）を監視するホスト監視エージェントが持つボリューム・論理ボリューム・ＲＡＩＤグループ・ポート間関連テーブル２２０１の例である。テーブル２２０１の構造は、テーブル２１０１と同様に、ボリューム識別子格納欄２２０２、論理ボリューム識別子格納欄２２０３、ＲＡＩＤグループ識別子格納欄２２０４、ホスト側ポート識別子格納欄２２０５、ストレージ側ポート識別子格納欄２２０６５、有効期間開始時刻格納欄２２０７、有効期間終了時刻格納欄２２０８からなる。各格納欄の内容も同様である。

図２３は、ＳＡＮ性能管理ソフトウェア１０７が持つリソース間関連情報記憶部１１９が格納するボリューム・論理ボリューム・ＲＡＩＤグループ・ポート間関連テーブル１３０３の例であり、全てのホスト監視エージェントから収集したボリューム・論理ボリューム・ＲＡＩＤグループ・ホスト側ポート・ストレージ側ポート間の依存関係を格納する。図２３に示すテーブルの構造は、テーブル２１０１と同様に、ボリューム識別子格納欄２３０１、論理ボリューム識別子格納欄２３０２、ＲＡＩＤグループ識別子格納欄２３０３、ホスト側ポート識別子格納欄２３０４、ストレージ側ポート識別子格納欄２３０５、有効期間開始時刻格納欄２２０８ａ、有効期間終了時刻格納欄２３０７からなる。

図２３に示したテーブルが格納する情報は、構成情報収集機能１１８による収集の時間遅れの期間を除けば、全ホスト監視エージェントが持つボリューム・論理ボリューム・ＲＡＩＤグループ・ポート間関連テーブルの全行をマージしたものと一致する。具体的には、ボリューム・論理ボリューム・ＲＡＩＤグループ・ポート間関連テーブル２１０１、２２０１の全行をマージしたものとなる。

図２４（Ａ）のテーブルは、ストレージネットワーク上のＳＡＮスイッチ（３２０〜３２３）を監視するＳＡＮスイッチ監視エージェント２３１が持つリソース間関連情報記憶部１１６に格納される、ポート間通信経路テーブル１２０１の例である。ポート間通信経路テーブル１２０１は、図３で説明したホスト側ポートからストレージ側ポートまでの経路上にあるポート間の性能の依存関係を記録するためのものであり、ＳＡＮスイッチのホスト側ポートの識別子を格納するホスト側ポート識別子格納欄２４１１、同じくストレージ側ポートの識別子を格納するストレージ側ポート識別子格納欄２４１２、ＳＡＮ２内の通信経路上のポートの識別子を複数格納する通信経路上ポート群識別子格納欄２４１３、有効期間の開始日時を格納する有効期間開始時刻格納欄２４１４、有効期間の終了日時を格納する有効期間終了時刻格納欄２４１５からなる。

テーブルの各行は、依存関係があったホスト側ポート・ストレージ側ポート・ホスト側ポートとストレージ側ポートが指定された場合の通信経路上のポート群・左記全ポートの間に依存関係があった期間１つに対応する。ＳＡＮスイッチ監視エージェント２３１が持つポート間通信経路テーブルの更新方法は、上記図１４で説明した方法と同様である。

図２４（Ｂ）のテーブルは、本実施例におけるＳＡＮスイッチ監視エージェント２３１の一例が持つリソース間関連情報記憶部１１６に格納される、ポート間通信経路テーブル２４０１の内容を示している。ポート間通信経路テーブル２４０１は、テーブル１２０１と共通の構造をしており、ホスト側ポート識別子格納欄２４０２、ストレージ側ポート識別子格納欄２４０３、通信経路上ポート群識別子格納欄２４０４、有効期間開始時刻格納欄２４０５、有効期間終了時刻格納欄２４０６からなる。ボリューム・論理ボリューム・ＲＡＩＤグループ・ポート間関連テーブル２４０１の第１行目には、２０００年１月０１日００：００〜２０００年１月１４日１３：００の間に、ポートＡ、ポートＣ、ポートＤ、ポートＨ、ポートＩ、ポートＮの間に性能の依存関係があったことが記録されている。

図２５は、ＳＡＮ性能管理ソフトウェア１０７が持つリソース間関連情報記憶部１１９が格納するポート間通信経路テーブル１３０４の例であり、全てのＳＡＮスイッチ監視エージェント２３１から収集したホスト側ポートからストレージ側ポートまでの経路上にあるポート間の性能の依存関係を格納する。図２５に示すテーブルの構造は、テーブル２４０１と同様に、ホスト側ポート識別子格納欄２５０１、ストレージ側ポート識別子格納欄２５０２、通信経路上ポート群識別子格納欄２５０３、有効期間開始時刻格納欄２５０４、有効期間終了時刻格納欄２５０５からなる。

図２５に示したテーブルが格納する内容は、構成情報収集機能１１８による収集の時間遅れの期間を除けば、全ＳＡＮスイッチ監視エージェント２３１が持つポート間通信経路テーブルの全ての行を合わせたものと一致する。本実施例では、単一のＳＡＮスイッチ監視エージェント２３１が全ＳＡＮスイッチを監視する構成をとっているため、ポート間通信経路テーブル１３０４の内容は、テーブル２４０１と等しくなる。

図２６は、アプリケーションの性能劣化判定ルールを設定するための画面の一例であり、アプリケーション目標性能設定機能１３３により性能管理クライアント１４４に表示される。当画面はアプリケーション選択領域２６０１と目標性能入力領域２６０２、設定ボタン２６０３からなる。ユーザは、アプリケーション選択領域２６０２からアプリケーションを選択し、目標性能入力領域２６０３にて目標ターンアラウンドタイム（レスポンスタイム）を入力し、設定ボタン２６０３を押下（あるいはクリック）する。設定ボタンが押下されると、アプリケーション目標性能設定機能１３３は、選択されたアプリケーションを監視するアプリケーション監視エージェント２４１が持つアプリケーション性能劣化期間決定ルール１３２を更新する。

図２７のアプリケーション性能劣化期間決定ルール１３２は、アプリケーション性能劣化期間決定ルールを格納するテーブルの構造の一例である。アプリケーション性能劣化決定ルール１３２は、アプリケーションの識別子を格納するアプリケーション識別子格納欄２７１１と、アプリケーションの目標応答時間である目標ターンアラウンド時間を格納する目標ターンアラウンドタイム格納欄２７１２からなる。アプリケーション識別子格納欄２７１１にはユーザが選択したアプリケーションの識別子が格納され、目標ターンアラウンドタイム格納欄２７１２にはユーザが入力した目標ターンアラウンドタイムが格納される。

図２７のアプリケーション性能劣化期間決定ルール２７０１は、本実施例におけるアプリケーション監視エージェントの一例である、ホストサーバＡ（２０５）上で稼働するアプリケーションＡ（２４０ａ）を監視する、アプリケーション監視エージェントＡが持つアプリケーション性能劣化期間決定ルールの内容を示している。アプリケーション性能劣化期間決定ルール２７０１、テーブル１３２と共通の構造をしており、アプリケーション識別子格納欄２７０２と、目標ターンアラウンドタイム格納欄２７０３からなる。アプリケーション性能劣化期間決定ルール２７０１には、アプリケーションＡ（２４０ａ）の目標ターンアラウンドタイムとして１８００秒が指定されたことが記録されている。

図２８、図２９に示すアプリケーション性能劣化期間決定ルール２８０１、２９０１は、アプリケーションＢを監視するアプリケーション監視エージェントＢが持つアプリケーション性能劣化期間決定ルールとアプリケーションＣを監視するアプリケーション監視エージェントＣが持つアプリケーション性能劣化期間決定ルールの例である。

アプリケーション性能劣化期間決定ルール２８０１、２９０１は、テーブル２７０１と共通の構造を持ち、アプリケーション識別子格納欄（２８０１、２９０１）と、目標ターンアラウンドタイム格納欄（２８０２、２９０２）からなる。各格納欄の内容も同様である。

図３０（Ａ）のテーブルは、アプリケーション監視エージェントが持つアプリケーション性能劣化期間テーブル１３４の構造の一例であり、アプリケーション監視エージェント２４１が、監視対象のアプリケーション２４０の性能劣化期間を検出し、格納した結果を示している。図３０（Ａ）はアプリケーションの識別子を格納するアプリケーション識別子格納欄３０１１、性能劣化の開始日時を格納する性能劣化開始時刻格納欄３０１２、性能劣化の終了日時を格納する性能劣化性能劣化終了時刻格納欄３０１３からなる。

アプリケーション監視エージェント２４１が持つアプリケーション性能劣化期間検出機能１３１は、上記したアプリケーション性能劣化期間決定ルール１３２と、アプリケーションが出力するログ１３０を参照し、自らが監視するアプリケーションの性能劣化期間を検出する。

ここで、アプリケーション監視エージェント２４１で行われる性能劣化期間検出のフローチャートを図３７を用いて詳しく説明する。本実施形態では、アプリケーションの性能劣化を検出するために、アプリケーションが出力するログの情報を用いているが、その他の方法にも、アプリケーションと通信を行い、アプリケーションから性能劣化検出に必要な情報を受け取る方法や、アプリケーション自身が性能劣化を判定し、性能劣化期間テーブルに書き込む方法等もある。本実施例は、それらの方法を制限するものではない。

図３０（Ｂ）のテーブルは、アプリケーションＡ（２４０ａ）を監視するアプリケーション監視エージェントＡが持つアプリケーション性能劣化期間テーブル３００１を示している。アプリケーション性能劣化期間テーブル３００１は、テーブル１３４と共通の構造を持ち、アプリケーション識別子格納欄３００２、性能劣化開始時刻格納欄３００３、性能劣化終了時刻３００４からなる。アプリケーション性能劣化期間テーブル３００１の一行目には、アプリケーションＡが２０００年０１月１１日１０：３０〜２０００年０１月１１日１１：１０の間に、性能劣化を起こしたことが示されている。

図３１、図３２は、テーブル３００１と同様に、アプリケーションＢ（２４０ｂ）、アプリケーションＣ（２４０ｃ）を監視するアプリケーション監視エージェントＢ、Ｃが持つアプリケーション性能劣化期間テーブル３１０１、３２０１を示している。図３１、図３２の構造はテーブル１３４と共通で、アプリケーション識別子格納欄（３１０２、３２０２）、性能劣化開始時刻格納欄（３１０３、３２０３）、性能劣化終了時刻格納欄（３１０４、３２０４）からなる。各格納欄の内容も同様である。

図３３は、ＳＡＮ性能管理ソフトウェア１０７が持つアプリケーション性能劣化期間テーブル１３７の例であり、アプリケーション監視エージェントＡ、Ｂから収集したアプリケーション性能劣化期間を格納する。図３３に示すテーブルの構造はテーブル１３４と同様で、アプリケーション識別子格納欄（３３０１）、性能劣化開始時刻格納欄（３３０２）、性能劣化終了時刻格納欄（３３０３）からなる。図３３に示したテーブルが格納する内容は、アプリケーション性能劣化情報収集機能による収集の時間遅れの期間を除けば、全アプリケーション監視エージェントが持つアプリケーション性能劣化期間テーブルの全行をマージしたものと一致する。具体的には、アプリケーション性能劣化期間テーブル３１０１、３２０１、３３０１の全行をマージしたものとなる。

図３４は、ＳＡＮ性能管理ソフトウェア１０７が持つ削除データ制御テーブル１３９の一例を示している。削除データ制御テーブル１３９は、アプリケーション２４０の性能劣化の開始日時を格納する性能劣化開始時刻格納欄３４０１、同じく性能劣化の終了日時を格納する性能劣化終了時刻格納欄３４０２、アプリケーション２４０に関連するリソースの識別子を格納する性能依存リソース格納欄３４０３から構成される。当テーブルの一行は、性能劣化開始時刻格納欄３４０１と性能劣化終了時刻格納欄３４０２で決定される性能劣化期間内に、性能劣化を起こしたアプリケーションが、性能依存リソース格納欄３４０３で決定されるリソースと性能上の依存関係があったことを表わす。ＳＡＮ性能管理ソフトウェア１０７が持つ削除非対象リソース算出機能１３８が、削除データ制御テーブル１３９を更新する。削除データ制御テーブル１３９の更新方法は、図３８、３９に示すフローチャートを用いて詳しく説明する。

図３４に示す削除データ制御テーブル１３９の例では、ＳＡＮ性能管理ソフトウェア１０７が持つリソース間関連情報記憶部１１９内の４つのテーブル｛アプリケーション・ファイルシステム間関連テーブル１３０１、ファイルシステム・ボリューム間関連テーブル１３０２、ボリューム・論理ボリューム・ＲＡＩＤグループ・ポート間関連テーブル１３０３、ポート間通信経路テーブル１３０４｝と、アプリケーション劣化期間テーブル１３７とを入力として、削除非対象リソース算出機能１３８が処理を行い、削除データ制御テーブルを作成した例である。ただし、図３４に示す削除データ制御テーブル１３９の例では、アプリケーションＡの性能劣化期間についての情報のみ掲載している。アプリケーションＢおよびアプリケーションＣについて、処理を行わないわけではない。

図３５はメトリクスの保存期間を設定するための画面の一例であり、メトリクス保存期間設定機能１４２により性能管理クライアント１４４に送信され、性能管理クライアント１４４の表示装置上に表示される。当画面は、通常データ保存期間入力領域３５０１と、重要データ保存期間入力領域３５０２と、設定ボタン３５０３からなる。重要データとは、性能劣化が起きたアプリケーションの性能劣化期間中に依存関係があったリソースから収集したメトリクスを意味する。通常データは、重要データに該当しないメトリクスである。ユーザが通常データ保存期間入力領域３５０１と、重要データ保存期間入力領域３５０２にそれぞれ保存期間を入力し設定ボタン３５０３を押下すると、メトリクス保存期間設定機能１４２は、メトリクス保存期間設定テーブル１４１に通常データ保存期間と重要データ保存期間を格納する。

図３６は、メトリクス保存期間設定テーブル１４１の一例であり、通常データおよび重要データの保存期間を格納する。メトリクス保存期間設定テーブル１４１は、保存期間種類格納欄３６０１と保存期間（時間）格納欄３６０２からなり、通常データ保存期間の値３６０３と、重要データ保存期間の値３６０４を格納する。

図３７は、アプリケーション監視エージェント２４１が持つアプリケーション性能劣化期間検出機能１３１のフローチャートである。該フローチャートは、初期化処理（３７０１）とループ処理（３７０２〜３７０７）からなる。以下、該フローチャートについて説明する。

まず、ステップ３７０１で、アプリケーション性能劣化期間決定ルール１３２からアプリケーションの目標ターンアラウンドタイムを取得して変数「ＴＡ」の値とし、ステップ３７０２に進む。

ステップ３７０２では、ログ１３０から未処理の処理開始時刻と処理終了時刻の組を取得し、取得した組それぞれについてループ処理を開始する。ループ内処理の開始ステップであるステップ３７０３に進む。

ステップ３７０３では、処理開始時刻を変数「Ｔ１」の値とし、ステップ３４０４に進む。

ステップ３７０４では、処理終了時刻を変数「Ｔ２」の値とし、ステップ３４０５に進む。

ステップ３７０５では、処理終了時刻をＴ２―Ｔ１とＴＡとを比較する。Ｔ２−Ｔ１がＴＡより大きければ、性能劣化が起きたと判定し、ステップ３７０６に進む。Ｔ２−Ｔ１がＴＡ以下であれば、性能劣化が起きていないと判定し、ステップ３７０７に進む。

ステップ３７０６では、性能劣化検出対象のアプリケーション識別子、ステップ３７０３で決定したＴ１、ステップ３７０４で決定したＴ２からなる組をアプリケーション性能劣化期間テーブル１３４に追加する。の性能に追加する。性能劣化検出対象のアプリケーション識別子は列３０１１に、Ｔ１は列３０１２に、Ｔ２は列３０１３にそれぞれ格納する。格納後、ステップ３４０７に進む。

ステップ３７０７では、ループ処理対象の行がある限り、ステップ３７０２に戻る。

上記処理により、アプリケーション監視エージェント２４１はアプリケーション性能劣化期間テーブル１３４を作成する。

図３８は、ＳＡＮ性能管理ソフトウェア１０７で実行される削除非対象リソース算出機能１３８のフローチャートである。該フローチャートは、性能劣化を起こしたアプリケーションを起点とし、ＲＡＩＤグループを終点とするＩ／Ｏ命令が処理される経路（Ｉ／Ｏパス）上のリソース群を、性能が劣化したアプリケーションと性能の依存関係にあったリソースとして検出する処理を示す。

以下では、アプリケーションから物理ディスクまでのＩ／Ｏ命令が処理される経路をＩ／Ｏパスと呼ぶこととする。また、Ｉ／Ｏパスにおいてアプリケーションに近い側を上流と呼び、物理ディスクに近い側を下流と呼ぶこととする。図３８のフローチャートは、初期化処理（３８０１）とループ処理（３８０２〜３８０５）からなる。以下、該フローチャートについて説明する。

始めに、ステップ３８０１では、削除データ制御テーブル１３９の内容をクリアする初期化を実施する。クリア後、ステップ３８０２に進む。

ステップ３８０２では、アプリケーション性能劣化期間テーブル１３７を参照し、該アプリケーション性能劣化期間テーブル１３７内の各行についてループ処理を開始する。ループ内処理の開始ステップであるステップ３８０３に進む。

ステップ３８０３では、性能劣化を起こしたアプリケーションと性能劣化期間中に性能の依存関係のあったリソースを検出するため、性能劣化を起こしたアプリケーションを起点とするＩ／Ｏパスを検出する。

Ｉ／Ｏパス検出のため、図３９で詳しく説明するＩ／Ｏパス算出サブルーチン３９０１を呼び出す。該Ｉ／Ｏパス算出サブルーチンを呼び出し、該Ｉ／Ｏパスを検出し、ステップ３８０４に進む。

ステップ３８０４では、ステップ３８０３で検出したＩ／Ｏパス上の各リソースを、性能劣化開始期間と性能劣化終了時刻の組とともに、重複を除いて削除データ制御テーブル１３９に格納する。格納後、ステップ３８０５に進む。

ステップ３８０５では、アプリケーション性能劣化期間テーブル１３７に処理対象の行がある限り、ステップ３８０２に戻る。

上記処理により、性能劣化を起こしたアプリケーション２４０を起点とする全Ｉ／Ｏパス上の収集対象要素を、アプリケーション２４０と性能の依存関係のあった収集要素対象とする。

図３９は、アプリケーション識別子と性能劣化期間を受け取り、性能劣化期間中に、該アプリケーション識別子で指定されたアプリケーションを起点とするＩ／Ｏパスを算出する、Ｉ／Ｏパス算出サブルーチン３９０１である。以下、ＳＡＮ性能管理ソフトウェア１０７で実行されるＩ／Ｏパス算出サブルーチン３９０１について説明する。

まず、始めのステップ３９０２では、Ｉ／Ｏパス算出対象のアプリケーション識別子を受け取り、識別子をＡＰへ代入する。演算後、ステップ３９０３に進む。

ステップ３９０３では、Ｉ／Ｏパス算出対象の性能劣化期間を受け取り、ステップ３９０４に進む。

ステップ３９０４では、アプリケーション・ファイルシステム間関連テーブル１３０１を走査し、ステップ３９０２で決定したＡＰと、ステップ３９０３で決定した性能劣化期間中に、性能の依存関係があったファイルシステムを検出する。

具体的には、アプリケーション・ファイルシステム間関連テーブル１３０１の全行から、アプリケーション識別子格納欄１７０１の値がＡＰと等しく、かつ、有効期間開始時刻１７０３と有効期間終了時刻１７０４で決定される期間が、性能劣化期間の少なくとも一部を含む行を絞込み、絞込みで残った全行のファイルシステム識別子格納欄１７０２で指定されたファイルシステムを検出する。検出したファイルシステムをＦ１〜Ｆiとする。演算後、ステップ３９０５に進む。

ステップ３９０５では、ステップ３９０４で検出したファイルシステムの数だけ、リソースリストを作成する。各リソースリストは、一本のＩ／Ｏパスを表わす。各リソースリストの第一要素に、検出したファイルシステムを追加する。演算後、ステップ３９０６に進む。

ステップ３９０６では、ファイルシステム・ボリューム間関連テーブル１３０２を走査し、アプリケーション２４０の性能劣化期間中に、ステップ３９０４で検出したファイルシステムＦ１〜Ｆｉのいずれかと性能の依存関係があったボリュームを検出し、リソースリストに追加する。具体的には、ファイルシステム・ボリューム間関連テーブル１３０２の全行から、ファイルシステム識別子格納欄２００１の値がＦ１〜Ｆｉのいずれかと等しく、かつ、有効期間開始時刻２００３と有効期間終了時刻２００４で決定される期間が、性能劣化期間の少なくとも一部を含む行を絞込み、絞込みで残った全行のボリューム識別子格納欄２００２で指定されたボリュームを検出する。検出したボリュームをＶ１〜Ｖｊとする。検出後、ステップ３９０７に進む。

ステップ３９０７では、ステップ３９０６で検出したボリュームを、該ボリュームと対応するファイルシステムをリストの第一要素として持つリソースリストに追加する。追加後、ステップ３９０８に進む。

ステップ３９０８では、ボリューム・論理ボリューム・ＲＡＩＤグループ・ポート間関連テーブル１３０３を走査し、性能劣化期間中に、ステップ３９０６で検出したボリュームＶ１〜Ｖｊのいずれかと性能の依存関係があった論理ボリューム・ＲＡＩＤグループ・ホスト側ポート・ストレージ側ポートの組を検出し、リソースリストに追加する。具体的には、ボリューム・論理ボリューム・ＲＡＩＤグループ・ポート間関連テーブル１３０３の全行から、ボリューム識別子格納欄２３０１の値がＶ１〜Ｖｊのいずれかと等しく、かつ、有効期間開始時刻２２０８ａと有効期間終了時刻２３０７で決定される期間が、性能劣化期間の少なくとも一部を含む行を絞込み、絞込みで残った全行論理ボリューム識別子格納欄２３０２で指定された論理ボリューム、ＲＡＩＤグループ識別子格納欄２３０３で指定されたボリューム、ホスト側ポート格納欄２３０４で指定されたホスト側ポート、ストレージ側ポート格納欄２３０５で指定されたストレージ側ポート格納欄を検出する。検出した情報が持つ、ホスト側ポートとストレージ側ポートの各組をＰ１〜Ｐｋとする。検出後、ステップ３９０９に進む。

ステップ３９０９では、ステップ３９０８で検出した論理ボリューム・ＲＡＩＤグループ・ホスト側ポート・ストレージ側ポートの組を、該組と対応する論理ボリュームをリストの第二要素として持つリソースリストに追加する。追加後、ステップ３９１０に進む。

ステップ３９１０では、ポート間通信経路テーブル１３０４を走査し、性能劣化期間中に、ステップ３９０８で検出したホスト側ポートとストレージ側ポートの組Ｐ１〜Ｐｋいずれかと性能の依存関係があった通信経路を検出し、リソースリストに追加する。具体的には、ポート間通信経路テーブル１３０４の全行から、ホスト側ポート識別子格納欄２５０１で指定されたホスト側ポートとストレージ側ポート識別子格納欄２５０２で指定されたストレージ側ポートの組が、Ｐ１〜Ｐｋのいずれかと等しく、かつ、有効期間開始時刻２５０４と有効期間終了時刻２５０５で決定される期間が、性能劣化期間の少なくとも一部を含む行を絞込み、絞込みで残った全行の通信経路上ポート群識別子格納欄２５０３で指定されたポート群を検出する。検出後、ステップ３９１１に進む。

ステップ３９１１では、ステップ３９１０で検出した通信経路上ポート群を、該ポート群と対応するホスト側ポートとストレージ側ポートを要素に含むリソースリストに追加する。ここで、該ポート群を、ホスト側ポートとストレージ側ポートの間に追加する。追加後、ステップ３９１２に進む。

ステップ３９１２では、全てのリソースリストを返却する。

本実施形態では、Ｉ／Ｏパス算出サブルーチン３９０１が作成するリソースリストの要素順序を、Ｉ／Ｏパスの上流から下流に向かうようにした。しかしながら、下流から上流に向かうようにもでき、本実施例はそのような場合を制限するものではない。また、本実施例では、Ｉ／Ｏパスを、アプリケーションが用いるファイルシステムを第一要素とするリソースリストによって実現しているが、さまざまな実現手法がある。本実施形態は、そのような場合を制限するものではない。

図４０は、ＳＡＮ性能管理ソフトウェア１０７が持つ削除非対象リソース算出機能１３８の他の例を示すフローチャートである。該フローチャートは、性能劣化を起こしたアプリケーションを起点とし、ＲＡＩＤグループを終点とするＩ／Ｏパス上のリソース群を検出し、検出した各リソースをＩ／Ｏパスの構成リソースとする全Ｉ／Ｏパスを検出し、検出したＩ／Ｏパスを上流および下流に辿ることで得たリソースを性能劣化アプリケーションと性能の依存関係にあったリソースに含める処理である。該フローチャートは、初期化処理（４００１）とメインループ処理（４００２〜４０１１）からなる。メインループ処理の内部には、２つのループ（４００４〜４００６）と（４００７〜４００９）がある。以下、該フローチャートについて説明する。

始めに、ステップ４００１では、削除データ制御テーブル１３９の内容をクリアする。クリア後、ステップ４００２に進む。

ステップ４００２では、アプリケーション性能劣化期間テーブル１３７を参照し、該アプリケーション性能劣化期間テーブル１３７内の各行についてループ処理を開始する。以下では、当該行が持つ性能劣化アプリケーション識別子格納欄３３０１の値を性能劣化アプリケーションとし、性能劣化開始時刻３３０２および性能劣化終了時刻３３０３からなる期間を性能劣化期間とする。ループ内処理の開始ステップであるステップ４００３に進む。

ステップ４００３では、性能劣化を起こしたアプリケーションと性能劣化期間中に性能の依存関係のあったリソースを検出するため、性能劣化を起こしたアプリケーションを起点とするＩ／Ｏパスを検出する。Ｉ／Ｏパス検出のため、Ｉ／Ｏパス算出サブルーチン３９０１を呼び出す。該Ｉ／Ｏパス算出サブルーチンを呼び出し、該Ｉ／Ｏパスを検出し、ステップ４００４に進む。

ステップ４００４は、全てのアプリケーションについて、Ｉ／Ｏパスを検出するためのループ処理の開始ステップである。ステップ４００４では、アプリケーション・ファイルシステム間関連テーブル１３０１のアプリケーション識別子格納欄から、重複を除いた全てのアプリケーション識別子を取得し、取得した全アプリケーション識別子についてループ処理を開始する。アプリケーション識別子を取得すると、ループ内の次のステップである。ステップ４００５に進む。

ステップ４００５では、ステップ４００４でループ対象としたアプリケーションと性能劣化期間中に性能の依存関係のあったリソースを検出するため、性能劣化を起こしたアプリケーションを起点とするＩ／Ｏパスを検出する。Ｉ／Ｏパス検出のため、Ｉ／Ｏパス算出サブルーチン３９０１を呼び出す。該Ｉ／Ｏパス算出サブルーチンを呼び出し、該Ｉ／Ｏパスを検出し、ステップ４００６に進む。

ステップ４００６では、ステップ４００５で検出したアプリケーション毎のＩ／Ｏパスを記憶する。記憶し、ステップ４００７に進む。

ステップ４００７では、ループ処理対象のアプリケーションがある限り、ステップ４００４に戻る。なければ、ステップ４００８に進む。

ステップ４００８では、ステップ４００３で得た、性能劣化を起こしたアプリケーションを起点とするＩ／Ｏパス上の全リソースについて、ループ処理を開始する。つまり、性能劣化ループ内の始めのステップであるステップ４００９に移る。

ステップ４００９では、ステップ４００６で記憶した、アプリケーション毎のＩ／Ｏパスについて、ループ処理を開始する。ループ内の始めのステップであるステップ４０１０に移る。

ステップ４０１０では、繰り返し対象のＩ／Ｏパスがステップ４００８で繰り返し対象とするリソースを含むか否かを検出する。具体的には、Ｉ／Ｏパスを意味するリソースリスト内に、ステップ４００８で繰り返し対象とするリソースが含まれるか否かを検出する。検査し、含まれていれば、ステップ４０１１に進む。含まれていなければ、ステップ４０１３に進む。

ステップ４０１１では、ステップ４００８で繰り返し対象とするリソースを起点とし、Ｉ／Ｏパスを上流および下流に辿ることでリソースを検出する。本実施例では、上流および下流の両方に辿るが、上流のみ、あるいは下流のみに辿ることもでき、本実施例は、それらの辿り方を制限するものではない。リソースを検出後、ステップ４０１２に進む。

ステップ４０１２では、検出したリソースを記憶する。記憶後、ステップ４０１３に進む。

ステップ４０１３では、繰り返し処理対象のＩ／Ｏパスがある限り、ステップ４００９に戻る。なければステップ４０１４に進む。

ステップ４０１４では、繰り返し処理対象のリソースがある限り、ステップ４００８に戻る。なければステップ４０１５に進む。

ステップ４０１５では、性能劣化期間・ステップ４００３で検出したＩ／Ｏパス上リソースの組および、性能劣化期間・ステップ４０１２で検出したリソースの組を、重複を除いて削除データ制御テーブル１３９に追加する。追加後、ステップ４０１６に進む。

ステップ４０１６では、アプリケーション性能劣化期間テーブル１３７の未処理の行がある限り、ステップ４００２に戻る。なければ終了する。

すなわち、ステップ４００２〜４００７のループで、性能劣化が生じたアプリケーション２４０に関連するＩ／Ｏパスを検出し、ステップ４００８〜４０１６のループにより検出したＩ／Ｏパスの上流と下流のリソースを検出し、削除データ制御テーブル１３９が作成される。

図４１は、メトリクス削除機能１４０が削除するデータの種類についての説明図である。図４１は、時間軸を表わす矢印４１０１と、時間軸上の３つの点（現在時刻４１０２、通常データ保存期限４１０３、重要データ保存期限４１０４）と、現在時刻から通常データ保存期限までの期間である通常データ保存期間３６０３と、現在時刻４１０２から重要データ保存期限４１０３までの期間である重要データ保存期間３６０４と、各期間内においてメトリクス値に対する処理方法の概念を表わすブロック（４１０５〜４１０７）からなる。

ブロック４１０５〜４１０７が示す通り、メトリクス削除機能１４０は、通常データ保存期間３６０３内は全てのメトリクスを保存する（４１０５）。そして、通常データ保存期間３６０３経過後で重要データ保存期間３６０４内である期間は、重要データに該当するメトリクスのみ保存し、通常データは削除する（４１０６）。そして、重要データ保存期間３６０４が過ぎると、全てのメトリクスを削除する（４１０７）。

図４２は、図４１で説明したメトリクス削除機能１４０の削除方法の一例を示したフローチャートである。該フローチャートは、初期化処理（４２０１〜４２０４）とループ処理（４２０５〜４２１１）からなる。

まず、ステップ４２０１では、現在時刻４１０２を取得する。取得後、４２０２に進む。

ステップ４２０２では、メトリクス保存期間テーブル１４１より通常データ保存期間３６０３と重要データ保存期間３６０４を取得する。取得後、ステップ４２０３に進む。

ステップ４２０３では、現在時刻４１０２から、通常データ保存期間３６０３だけ過去に遡った時刻を、通常データ保存期限４１０３とする。演算後、ステップ４２０４に進む。

ステップ４２０４では、現在時刻４１０２から重要データ保存期間３６０４だけ過去に遡った時刻を、重要データ保存期限４１０４とする。演算後、ステップ４２０５に進む。

ステップ４２０５では、メトリクス保存テーブル１１３が持つ全行についてループ処理を開始する。ループ内処理の開始ステップであるステップ４２０６に進む。以下、ループ内処理（ステップ４２０６〜４２１０）では、ループ処理対象行が持つＴ２の値に応じて削除処理の実行を制御する。Ｔ２の値は、メトリクスを収集・保存した時刻を意味する。

ステップ４２０６では、ループ処理対象行のＴ２の値と通常データ保存期限４１０３とを比較する。Ｔ２の値が通常データ保存期限４１０３以上であった場合、すなわち、メトリクス保存時刻が通常データ保存期間３６０３内であった場合、ステップ４２１１に進む。逆に、Ｔ２の値が通常データ保存期限４１０３より小さかった場合、すなわち、メトリクス保存時刻が通常データ保存期間３６０３を過ぎていた場合、ステップ４２０７に進む。

ステップ４２０７では、ループ処理対象行のＴ２の値と重要データ保存期限４１０４とを比較する。Ｔ２の値が重要データ保存期限４１０４以上であった場合、すなわち、メトリクス保存時刻が重要データ保存期間３６０４内であった場合、ステップ４２０９に進む。逆に、Ｔ２の値が重要データ保存期限４１０４より小さかった場合、すなわち、メトリクス保存時刻が重要データ保存期間３６０４を過ぎていた場合、ステップ４２０８に進む。

ステップ４２０８では、メトリクス削除テーブル１１３から、ループ処理対象行の削除処理を実行する。削除後、ステップ４２１１に進む。

ステップ４２０９では、当該行が重要データであるか否かの判定を行う。該判定処理では、削除データ制御テーブル１３９を利用して、ループ対象行に対し次の２つの検査を実施する。両検査に当てはまれば、ループ対象行を重要データであるとする。

（検査１）当該行のリソース識別子が、削除データ制御テーブル１３９が持つ性能依存リソース識別子格納欄３４０３に存在する。

（検査２）当該行のＴ１〜Ｔ２で指定される範囲の少なくとも一部が、（検査１）で存在を確認した削除データ制御テーブル１３９の行が持つ性能劣化開始時刻格納欄３４０１〜性能劣化終了時刻格納欄３４０２の範囲に含まれる。

上記検査１、検査２を行った結果、ループ処理対象行を重要データと判定した場合は、ステップ４２１１に進む。逆に、重要データでないと判定した場合は、ステップ４２０８へ進む。

ステップ４２１１では、ループ処理対象の行がある限り、ステップ３８０２に戻る。

上記処理により、メトリクス保存期間テーブル１４１より通常データについては、第１の保存期間（７２時間）が経過したものについては削除され、重要データについては第２の保存期間（１０日間）が経過するまで保持される。

したがって、アプリケーション２４０に性能劣化が生じてから１０日間以内であれば、重要データとして保存された性能劣化の起きたアプリケーション２４０が使用するＩ／Ｏパスと、このＩ／Ｏパスの上流及び下流のメトリクス値を参照できる。これにより、アプリケーション２４０の性能劣化の原因を、詳細なメトリクス値（性能情報）に基づいて追究することが可能となるのである。

一方、性能劣化に無関係なＩ／Ｏパスのメトリクス値は、通常の保存期間が経過すると自動的に削除されるため、多数のホストサーバ２０５〜２０７と多数のＳＡＮスイッチ及びストレージサブシステムからなるＳＡＮ２上の膨大な性能情報のうち必要なものだけを保存することができるので、性能情報（メトリクス値）を格納するためのストレージサブシステムの領域が増大するのを抑制できるのである。

なお、上記実施形態においては、ホストサーバ２０５〜２０７にアプリケーション監視エージェント２４１とホスト監視エージェント２１０や、ＳＡＮスイッチ監視エージェント２３１、ストレージサブシステム監視エージェント２３２を備えたが、これらエージェントを介さず、ＳＡＮ性能管理ソフトウェア１０７が直接、監視対象の装置やソフトウェアと通信し、性能情報を取得するようにしてもよい。

また、上記本実施形態ではＳＡＮ２経由で性能情報を取得しているが、ストレージサブシステム２２４〜２２６がＬＡＮ２０４に接続されている場合、ストレージサブシステム監視エージェント２３２は、ＬＡＮ２０４経由でストレージサブシステム２２４〜２２６およびそのポート２２７〜２２９の性能情報を取得してもよい。同様に、ＳＡＮスイッチ監視エージェント２３１も、監視対象のＳＡＮスイッチ２１４〜２１６から性能情報を取得するために、ＬＡＮ２０４を経由して通信してもよい。また、本実施例では、ＳＡＮスイッチ監視エージェント２３１とストレージサブシステム監視エージェント２３２は専用の性能情報収集サーバ２３０上で稼動しているが、どの計算機上で稼働してもよい。アプリケーション監視エージェントおよびホスト監視エージェントについても同様で、本実施例では、ホストサーバ２０５上で稼働しているが、他の計算機上で稼働し、通信を用いてアプリケーションの性能情報を取得しても良い。

なお、上記図４０のステップ４０１１において、Ｉ／Ｏパスの探索を上流に辿り、性能劣化を起こしたアプリケーション２４０を起点とする全Ｉ／Ｏパス上の収集対象要素を検出し、検出した収集対象要素をＩ／Ｏパス上の装置またはソフトウェアとする全アプリケーションを検出する。そして各収集対象要素を起点として、検出した各アプリケーションのＩ／Ｏパスを上流に辿った場合の経路上の収集対象要素を、該アプリケーションと性能の依存関係のあった収集要素対象とすることができる。

また、上記図４０のステップ４０１１において、Ｉ／Ｏパスの探索を下流に辿り、性能劣化を起こしたアプリケーション２４０を起点とする全Ｉ／Ｏパス上の収集対象要素を検出し、検出した該収集対象要素をＩ／Ｏパス上の装置またはソフトウェアとする全アプリケーションを検出する。収集対象要素を起点として、検出した各アプリケーションのＩ／Ｏパスを下流に辿った場合の経路上の収集対象要素を、アプリケーション２４０と性能の依存関係のあった収集要素対象としてもよい。

また、上記実施形態においては、所定の保存期間が経過したメトリクス値をＳＡＮ性能管理ソフトウェア１０７が削除する例を示したが、ＳＡＮ性能管理ソフトウェア１０７が各エージェントに対して、削除するメトリクス値を指示するようにしても良い。

本発明の一実施形態を示すシステム構成図である。同じく、本発明の性能管理ソフトウェアの機能ブロック図である。図１の構成図のうち、代表的なホストサーバとＳＡＮスイッチ及びストレージサブシステムの通信状態を示す説明図である。装置監視エージェントおよびストレージネットワーク性能管理ソフトが持つメトリクス値テーブルの構造の一例を示す図と、ホスト監視エージェントＡが持つメトリクス値テーブルの内容の一例を示した図である。ホスト監視エージェントＢが持つメトリクス値テーブルの内容の一例を示した説明図である。ストレージサブシステム監視エージェントが持つメトリクス値テーブルの内容の一例を示した説明図である。ＳＡＮスイッチ監視エージェントが持つメトリクス値テーブルの内容の一例を示した説明図である。ストレージネットワーク性能管理ソフトが持つメトリクス値テーブルの内容の一例を示した説明図である。グラフ形式による性能情報の表示画面の一例を示す説明図である。アプリケーション監視エージェントにおける、リソース間関連情報記憶部のテーブル構成の一例を示す説明図である。ホスト監視エージェントにおける、リソース間関連情報記憶部のテーブル構成の一例を示す説明図である。ＳＡＮスイッチ監視エージェントにおける、リソース間関連情報記憶部のテーブル構成の一例を示す図である。ストレージネットワーク性能管理ソフトウェアにおける、リソース間関連情報記憶部のテーブル構成の一例を示す説明図である。（Ａ）はアプリケーション監視エージェントおよびストレージネットワーク性能管理ソフトが持つアプリケーション・ファイルシステム間関連テーブルの構造の一例を示す説明図、（Ｂ）はアプリケーション監視エージェントＡが持つアプリケーション・ファイルシステム間関連テーブルの内容の一例を示す説明図である。アプリケーション監視エージェントＢが持つアプリケーション・ファイルシステム間関連テーブルの内容の一例を示す説明図である。アプリケーション監視エージェントＣが持つアプリケーション・ファイルシステム間関連テーブルの内容の一例を示す説明図である。ストレージネットワーク性能管理ソフトが持つアプリケーション・ファイルシステム間関連テーブルの内容の一例を示す説明図である。（Ａ）はホスト監視エージェントおよびストレージネットワーク性能管理ソフトが持つファイルシステム・ボリューム間関連テーブルの構造の一例を示す説明図、（Ｂ）はホスト監視エージェントＡが持つファイルシステム・ボリューム間関連テーブルの内容の一例を示す説明図である。ホスト監視エージェントＢが持つファイルシステム・ボリューム間関連テーブルの内容の一例を示す説明図である。ストレージネットワーク性能管理ソフトが持つファイルシステム・ボリューム間関連テーブルの内容の一例を示す説明図である。（Ａ）はホスト監視エージェントおよびストレージネットワーク性能管理ソフトが持つボリューム・論理ボリューム・ＲＡＩＤグループ・ポート間関連テーブルの構造の一例を示す図、（Ｂ）はホスト監視エージェントＡが持つボリューム・論理ボリューム・ＲＡＩＤグループ・ポート間関連テーブルの内容の一例を示す説明図である。ホスト監視エージェントＢが持つボリューム・論理ボリューム・ＲＡＩＤグループ・ポート間関連テーブルの内容の一例を示す説明図である。ストレージネットワーク性能管理ソフトが持つボリューム・論理ボリューム・ＲＡＩＤグループ・ポート間関連テーブルの内容の一例を示す説明図である。（Ａ）はＳＡＮスイッチ監視エージェントおよびストレージネットワーク性能管理ソフトが持つポート間通信経路テーブルの構造の一例を示す図、（Ｂ）ＳＡＮスイッチ監視エージェントが持つポート間通信経路テーブルの内容の一例を示す図である。ストレージネットワーク性能管理ソフトが持つポート間通信経路テーブルの内容の一例を示す説明図である。アプリケーションの目標性能を設定するための画面の一例を示す説明図である。（Ａ）はアプリケーションの目標性能を保存する、アプリケーション性能劣化期間決定ルールテーブルの構成の一例を示す図、（Ｂ）はアプリケーション監視エージェントＡが持つアプリケーション性能劣化期間決定ルールの内容の一例を示す図である。アプリケーション監視エージェントＢが持つアプリケーション性能劣化期間決定ルールの内容の一例を示す説明図である。アプリケーション監視エージェントＣが持つアプリケーション性能劣化期間決定ルールの内容の一例を示す図である。（Ａ）はアプリケーション監視エージェントおよびストレージネットワーク性能管理ソフトが使用するアプリケーション性能劣化期間テーブルの構造の一例を示す説明図、（Ｂ）はアプリケーション監視エージェントＡが持つアプリケーション性能劣化期間テーブルの内容の一例を示す説明図である。アプリケーション監視エージェントＢが持つアプリケーション性能劣化期間テーブルの内容の一例を示す説明図である。アプリケーション監視エージェントＣが持つアプリケーション性能劣化期間テーブルの内容の一例を示す説明図である。ストレージネットワーク性能管理ソフトが持つアプリケーション性能劣化期間テーブルの内容の一例を示す説明図である。ストレージネットワーク性能管理ソフトが持つ、メトリクスの削除を制御するためのテーブルの構造および内容の一例を示す説明図である。メトリクス保存期間設定のための画面の一例を示す説明図である。ストレージネットワーク性能管理ソフトが持つ、メトリクス保存期間を格納するためのテーブルの構造および内容の一例を示す説明図である。アプリケーションの性能劣化期間を決定する処理の一例を示すフローチャートである。性能劣化期間中に、性能劣化を起こしたアプリケーションと性能の依存関係があったリソースを検出し、メトリクスの削除をコントロールするためのテーブルを更新する処理を示したフローチャートの一例である。性能劣化期間中に、性能劣化を起こしたアプリケーションを起点とするＩ／Ｏパス上リソースを検出するためのフローチャートの一例を示す図である。図３８の他の例を示し、性能劣化期間中に、性能劣化を起こしたアプリケーションと性能の依存関係があったリソースを検出し、メトリクスの削除をコントロールするためのテーブルを更新する処理を示したフローチャートの一例である。データ保存期間毎の、保存するメトリクスの種類を表わした説明図である。メトリクスの削除処理の一例を示すフローチャートである。

符号の説明

１０７ＳＡＮ性能管理ソフトウェア
２０５〜２０７ホストサーバ
２１０ホスト監視エージェント
３２０〜３２３ＳＡＮスイッチ
２２４〜２２６ストレージサブシステム
２３０性能情報収集サーバ
２３１ＳＡＮスイッチ監視エージェント
２３２ストレージサブシステム監視エージェント
２３４性能管理サーバ
２４０アプリケーション
２４１アプリケーション監視エージェント

Claims

計算機とストレージ装置との間で入出力データを送受信するネットワーク装置を有するストレージネットワークのリソースについて性能情報を収集し、保存するストレージネットワーク性能情報の収集・保存方法であって、
前記ストレージネットワークとストレージ装置及び計算機のリソースのうち、予め設定した収集対象要素から性能情報を収集し、保存する性能情報収集ステップと、
前記収集対象要素間に成り立つ性能の依存関係を収集し、保存する性能依存関係収集ステップと、
前記計算機で実行されるアプリケーションの性能劣化期間を検出し、当該性能劣化期間を保存するアプリケーション性能劣化期間検出ステップと、
前記検出したアプリケーション性能劣化期間中に、性能劣化を起こしたアプリケーションと性能の依存関係にあった収集対象要素を検出する性能劣化時依存関係検出ステップと、
前記性能劣化時依存関係検出ステップで検出された収集対象要素の性能情報について通常の保存期間よりも延長した第２の保存期間を設定し、前記抽出対象外の性能情報について通常の保存期間を設定するステップと、
前記通常または第２の保存期間が過ぎた性能情報を削除する削除ステップと、
を含むことを特徴とするストレージネットワーク性能情報の収集・保存方法。
前記性能劣化時依存関係検出ステップは、前記収集対象要素間の性能の依存関係に基づいて、前記性能劣化を起こしたアプリケーションを起点として、当該性能劣化が起きた期間中に、当該アプリケーションが性能上の負荷をかけるストレージネットワークの下流側に前記依存関係を辿った経路上の収集対象要素を、当該アプリケーションと性能の依存関係にあった収集対象要素とすることを特徴とする請求項１に記載のストレージネットワーク性能情報の収集・保存方法。
前記性能劣化時依存関係検出ステップは、前記収集対象要素間の性能の依存関係に基づいて、前記性能劣化を起こしたアプリケーションを起点として、当該性能劣化が起きた期間中に、当該アプリケーションが性能上の負荷をかけるストレージネットワークの下流側に前記依存関係を辿った経路上の収集対象要素を検出し、検出された各収集要素から見て性能上の負荷をかける上流側に前記依存関係を辿った経路上の収集要素を、当該アプリケーションと性能の依存関係にあった収集対象要素とすることを特徴とする請求項１に記載のストレージネットワーク性能情報の収集・保存方法。
前記性能劣化時依存関係検出ステップは、前記収集対象要素間の性能の依存関係に基づいて、前記性能劣化を起こしたアプリケーションを起点として、当該性能劣化が起きた期間中に、当該アプリケーションが性能上の負荷をかけるストレージネットワークの下流側に前記依存関係を辿った経路上の収集対象要素を検出し、検出された各収集要素から見て性能上の負荷をかける下流側に前記依存関係を辿った経路上の収集対象要素を、当該アプリケーションと性能の依存関係にあった収集対象要素とすることを特徴とする請求項１に記載のストレージネットワーク性能情報の収集・保存方法。
前記性能劣化時依存関係検出ステップは、前記収集対象要素間の性能の依存関係に基づいて、前記性能劣化を起こしたアプリケーションを起点として、当該性能劣化が起きた期間中に、当該アプリケーションが性能上の負荷をかけるストレージネットワークの下流側に前記依存関係を辿った経路上の収集対象要素を検出し、検出された各収集要素から見て性能上の負荷をかける下流側及び上流側に前記依存関係を辿った経路上の収集対象要素を、当該アプリケーションと性能の依存関係にあった収集対象要素とすることを特徴とする請求項１に記載のストレージネットワーク性能情報の収集・保存方法。
計算機とストレージ装置との間で入出力データを通信するネットワーク装置を有するストレージネットワークのリソースについて性能情報を収集し、保存するプログラムであって、
前記ストレージネットワークとストレージ装置及び計算機のリソースのうち、予め設定した収集対象要素から性能情報を収集し、保存する処理と、
前記収集対象要素間に成り立つ性能の依存関係を収集し、保存する処理と、
前記計算機で実行されるアプリケーションの性能劣化期間を検出し、当該性能劣化期間を保存する処理と、
前記検出したアプリケーション性能劣化期間中に、性能劣化を起こしたアプリケーションと性能の依存関係にあった収集対象要素を検出する性能劣化時依存関係検出処理と、
前記性能劣化時依存関係検出処理で検出された収集対象要素の性能情報について通常の保存期間よりも延長した第２の保存期間を設定し、前記抽出対象外の性能情報について通常の保存期間を設定する処理と、
前記通常または第２の保存期間が過ぎた性能情報を削除する削除処理と、
をコンピュータに機能させることを特徴とするプログラム。
前記性能劣化時依存関係検出処理は、前記収集対象要素間の性能の依存関係に基づいて、前記性能劣化を起こしたアプリケーションを起点として、当該性能劣化が起きた期間中に、当該アプリケーションが性能上の負荷をかけるストレージネットワークの下流側に前記依存関係を辿った経路上の収集対象要素を、当該アプリケーションと性能の依存関係にあった収集対象要素とすることを特徴とする請求項６に記載のプログラム。
前記性能劣化時依存関係検出処理は、前記収集対象要素間の性能の依存関係に基づいて、前記性能劣化を起こしたアプリケーションを起点として、当該性能劣化が起きた期間中に、当該アプリケーションが性能上の負荷をかけるストレージネットワークの下流側に前記依存関係を辿った経路上の収集対象要素を検出し、検出された各収集要素から見て性能上の負荷をかける上流側に前記依存関係を辿った経路上の収集要素を、当当該アプリケーションと性能の依存関係にあった収集対象要素とすることを特徴とする請求項６に記載のプログラム。
前記性能劣化時依存関係検出処理は、前記収集対象要素間の性能の依存関係に基づいて、前記性能劣化を起こしたアプリケーションを起点として、当該性能劣化が起きた期間中に、当該アプリケーションが性能上の負荷をかけるストレージネットワークの下流側に前記依存関係を辿った経路上の収集対象要素を検出し、検出された各収集要素から見て性能上の負荷をかける下流側に前記依存関係を辿った経路上の収集対象要素を、当該アプリケーションと性能の依存関係にあった収集対象要素とすることを特徴とする請求項６に記載のプログラム。
前記性能劣化時依存関係検出処理は、前記収集対象要素間の性能の依存関係に基づいて、前記性能劣化を起こしたアプリケーションを起点として、当該性能劣化が起きた期間中に、当該アプリケーションが性能上の負荷をかけるストレージネットワークの下流側に前記依存関係を辿った経路上の収集対象要素を検出し、検出された各収集要素から見て性能上の負荷をかける下流側及び上流側に前記依存関係を辿った経路上の収集対象要素を、当該アプリケーションと性能の依存関係にあった収集対象要素とすることを特徴とする請求項６に記載のプログラム。
アプリケーションを実行する計算機と、
前記計算機とストレージ装置との間で入出力データを送受信するネットワーク装置を含むストレージネットワークと、を備えた計算機システムにおいて、
前記計算機とストレージ装置及びストレージネットワークのリソースのうち、予め設定した収集対象から性能情報を収集し、この性能情報を予め設定した記憶領域へ格納する性能情報収集部と、
前記収集対象要素間に成り立つ性能の依存関係を前記ストレージネットワークの構成に基づいて収集し、当該収集した性能の依存関係を保存する性能依存関係収集部と、
前記アプリケーションの性能の劣化を検出し、当該アプリケーションの性能劣化期間を保存する劣化検出部と、
前記アプリケーションの性能劣化期間中に、性能劣化を起こしたアプリケーションと性能の依存関係にあった収集対象要素を検出する性能劣化時依存関係検出部と、
前記性能劣化時依存関係検出部で検出された収集対象要素の性能情報について通常の保存期間よりも延長した第２の保存期間を設定し、前記抽出対象外の性能情報について通常の保存期間を設定する保存期間設定部と、
前記通常または第２の保存期間が過ぎた性能情報を検出し、前記記憶領域から削除する削除部と、
を備えたことを特徴とする計算機システム。
前記性能劣化時依存関係検出部は、前記収集対象要素間の性能の依存関係に基づいて、前記性能劣化を起こしたアプリケーションを起点として、当該性能劣化が起きた期間中に、当該アプリケーションが性能上の負荷をかけるストレージネットワークの下流側に前記依存関係を辿った経路上の収集対象要素を、当該アプリケーションと性能の依存関係にあった収集対象要素とすることを特徴とする請求項１１に記載の計算機システム。
前記性能劣化時依存関係検出部は、前記収集対象要素間の性能の依存関係に基づいて、前記性能劣化を起こしたアプリケーションを起点として、当該性能劣化が起きた期間中に、当該アプリケーションが性能上の負荷をかけるストレージネットワークの下流側に前記依存関係を辿った経路上の収集対象要素を検出し、検出された各収集要素から見て性能上の負荷をかける上流側に前記依存関係を辿った経路上の収集対象要素を、当該アプリケーションと性能の依存関係にあった収集対象要素とすることを特徴とする請求項１１に記載の計算機システム。
前記性能劣化時依存関係検出部は、前記収集対象要素間の性能の依存関係に基づいて、前記性能劣化を起こしたアプリケーションを起点として、当該性能劣化が起きた期間中に、当該アプリケーションが性能上の負荷をかけるストレージネットワークの下流側に前記依存関係を辿った経路上の収集対象要素を検出し、検出された各収集要素から見て性能上の負荷をかける下流側に前記依存関係を辿った経路上の収集対象要素を、当該アプリケーションと性能の依存関係にあった収集対象要素とすることを特徴とする請求項１１に記載の計算機システム。
前記性能劣化時依存関係検出部は、前記収集対象要素間の性能の依存関係に基づいて、前記性能劣化を起こしたアプリケーションを起点として、当該性能劣化が起きた期間中に、当該アプリケーションが性能上の負荷をかけるストレージネットワークの下流側に前記依存関係を辿った経路上の収集対象要素を検出し、検出された各収集要素から見て性能上の負荷をかける下流側及び上流側に前記依存関係を辿った経路上の収集対象要素を、当該アプリケーションと性能の依存関係にあった収集対象要素とすることを特徴とする請求項１１に記載の計算機システム。