JP4516306B2 - ストレージネットワークの性能情報を収集する方法 - Google Patents

Description

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

ネットワークを経由して複数のホストサーバから統合化されたストレージ装置にアクセスする構成をとるストレージネットワークは、大規模化が進むストレージの利用効率を高め管理コストを削減するためのデータセンタ用アーキテクチャとして広く普及しつつある。

性能管理ソフトウェアでは、性能監視対象となるハードウェア装置やソフトウェアごとにネットワーク内に配置したエージェントと、ネットワーク全体の性能情報を一元管理する管理ソフトからなる構成をとって上記要求に応えている。各エージェントはそれぞれの監視対象と直接通信して性能情報を取得し、一方、管理ソフトは、エージェント群が取得した性能情報を収集・蓄積し、ストレージネットワーク管理者等からの要求に応じて性能情報を提供するものもある。

ストレージネットワークではなく計算機ネットワークの例ではあるが、上記と同様の構成をとってネットワーク環境内の複数のサーバ装置の性能を監視する方法ならびにシステムを開示したものに特許文献１がある。

米国特許第６，５０５，２４８号

ストレージネットワークを基盤にしたストレージ統合の普及とともに、大規模化したネットワークの構成要素の数が膨大となりその相互関係も複雑化する傾向にある。

このようなストレージネットワーク環境で業務システムの性能監視やチューニングを行なうには、ネットワークを構成するさまざまなハードウェア装置ならびにソフトウェアに関する性能情報を包括的に収集して、その相互間の関係や時間的な推移を把握することが必要になる。

分散した性能情報の収集を自動化する技術は、そうしたストレージネットワークの性能管理を行なう上で不可欠のものとなっているが、ネットワークの大規模化がさらに進行した場合、ネットワークの全構成要素について性能情報を網羅的に自動収集することには、記憶容量や、計算性能、通信性能等の処理能力上、大きな困難が見込まれる。

大規模なストレージネットワーク環境で業務システムの性能監視やチューニングを行なうには、ネットワークを構成するさまざまなハードウェア装置ならびにソフトウェアに関する性能情報を包括的に収集して、その相互間の関係や時間的な推移を把握することが必要になる。

計算処理装置と外部記憶装置が直結されたサーバ単位に各業務システムが独立していた従来のアーキテクチャと異なり、ストレージネットワーク環境ではネットワーク装置やストレージ装置等の共用部分で業務システム間に性能上の干渉が生じる可能性があるためである。

一方、従来技術には、利用者の手操作による設定変更によって、ネットワーク構成要素ごとに性能情報の収集のオン・オフを切り替えられるものもある。この機能を利用すれば、収集すべき性能情報の量を制限することは可能になるが、そのためには、どの要素に注目し、どの要素を度外視してよいか、事前に区別できなければならない。

しかし、これは、性能負荷の傾向が異なるさまざまな業務がストレージネットワークで統合され、膨大な数の構成要素が互いに複雑な性能上の影響を及ぼし合う関係にあるとき、極めて困難な作業となる。また、利用者の手操作が介在するので、重要な情報取得のタイミングを逸したり、問題発生の検出が後手に回ったりする畏れがあった。

本発明の目的は、以上述べた問題を解決するストレージネットワーク性能情報の収集方式を提供することにある。

上記目的を達成するため、本発明の１つまたは複数の計算機装置と、１つまたは複数の外部記憶装置と、該計算機装置が該外部記憶装置との間で入出力データを通信するための１つまたは複数のネットワーク装置とからなるストレージネットワークにおいて、該装置ならびに該装置で稼動するソフトウェアに関する性能情報を収集する方式であって、収集した性能情報をもとに、情報収集の対象範囲もしくは程度を必要に応じて調整する。

また、本発明における計算機と、記憶装置と、前記計算機が前記記憶装置との間で入出力データを通信するためのネットワーク装置を含むストレージネットワークにおける性能情報を収集する方法であって、少なくとも前記計算機、前記記憶装置、前記ネットワーク装置のいずれか１つから性能情報を収集し、前記収集した性能情報と設定された性能情報収集に関する条件に基づいて、性能情報を収集する対象範囲もしくは性能情報を収集する頻度を変更することを特徴とする。

本発明によれば、ストレージネットワークの性能監視やチューニングに必要な情報の収集方法を、ユーザが指定したパラメータに応じて制御することが可能になる。また、情報の収集量や情報を収集する対象を必要に応じて調節することが可能になる。

これにより、より大規模なストレージネットワークの性能監視を自動化することやオーバーヘッドを軽減することも可能となる。

以下、本発明の実施例を図面により詳細に説明する。

図１は、本発明の一実施例のシステム構成図である。ストレージネットワークを基盤にした業務システムを構成するハードウェアには、業務クライアント２０１〜２０４や、ローカルエリアネットワーク（ＬＡＮ）２０５、ホストサーバ２０９〜２１１、ストレージエリアネットワーク（ＳＡＮ）スイッチ２２５〜２２７、ストレージサブシステム２３４、ネットワークアタッチドストレージ（ＮＡＳ）２０８がある。また、ソフトウェアには、業務ソフト２１２、データベース（ＤＢ）管理ソフト２１４、オペレーティングシステム（ＯＳ）２１６がある。尚、ストレージサブシステムとは、ハードディスク等の複数の記憶媒体と、これらをＲＡＩＤ（Redundant Array of Independent Disks）方式等に従って制御するコントローラを含む記憶装置である。

業務クライアント２０１〜２０４は、業務システムのユーザインタフェース機能を提供するパソコンや、ワークステーション、シンクライアント（Thin Client）端末等の装置であり、ＬＡＮ２０５を経由してホストサーバ２０９〜２１１の業務ソフト２１２等と通信する。尚、業務クライアント２０１〜２０４は、データの送受信の機能を有する携帯端末等でもよいし、その他のものでもよい。

業務ソフト２１２は、業務システムの業務論理機能を提供するソフトウェアであり、業務クライアント２０１〜２０４からの処理要求に応答し、必要に応じてＤＢ管理ソフト２１４にデータの参照・更新を要求する。ＤＢ管理ソフト２１４は、業務システムのデータ管理機能を提供するソフトウェアであり、業務ソフト２１２からの要求に応答し、ストレージサブシステム２３４やＮＡＳ２０８に格納されたデータの定義・操作・管理に関する処理を行なう。

業務ソフト２１２と、同ソフトが利用するＤＢ管理ソフト２１４は、同一のホストサーバで稼動される場合もあるし、それぞれ別の専用のホストサーバで稼動される場合もある。ＤＢ管理ソフト２１４からストレージサブシステム２３４のデータへのアクセスは、ＯＳ２１６、ホストバスアダプタ（Host Bus Adapter）のポート２１８〜２２０、ＳＡＮスイッチのホスト側ポート２２１〜２２３、ＳＡＮスイッチ２２５〜２２７、ＳＡＮスイッチのストレージ側ポート２２８〜２３０、ストレージサブシステムのポート２３１〜２３３を経由して行なわれる。一方、ＤＢ管理ソフト２１４からＮＡＳ２０８のデータへのアクセスは、ＯＳ２１６とＬＡＮ２０５を経由する。

ストレージネットワークと業務システムの性能管理のためのシステムを構成するハードウェアには、性能管理クライアント１２９や、性能管理サーバ２４０、性能情報収集サーバ２０６、２３５、２３７がある。また、ソフトウェアには、ストレージネットワーク性能管理ソフト１０９や、業務ソフト性能情報収集エージェント２１３、ＤＢ性能情報収集エージェント２１５、ホスト性能情報収集エージェント２１７、サブシステム性能情報収集エージェント２３８、ＮＡＳ性能情報収集エージェント２０７、ＳＡＮスイッチ性能情報収集エージェント２３６がある。

性能管理クライアント１２９は、ストレージネットワーク性能管理ソフト１０９のユーザインタフェース機能を提供する装置であり、ＬＡＮ２０５を経由して性能管理サーバ２４０のストレージネットワーク性能管理ソフト１０９と通信する。例えば、性能管理クライアント１２９として汎用パソコンを使用し、当該パソコン上で稼動するＷｅｂブラウザソフトを具体的なユーザインタフェースとする構成をとることが典型例として考えられる。この場合、性能管理サーバ２４０として用いるコンピュータ上ではＷｅｂサーバソフトを稼動させ、ストレージネットワーク管理ソフト１０９が収集した性能情報やチューニングに必要なデータは、このＷｅｂサーバソフトを経由しＨＴＴＰ（Hyper Text Transfer Protocol）プロトコルでＷｅｂブラウザに送られ画面に表示される。

ストレージネットワーク性能管理ソフト１０９は、ストレージネットワークの性能情報の収集と分析に関する機能を提供するソフトウェアであり、ネットワークを構成するさまざまなハードウェアやソフトウェアから性能情報を取得するため、それぞれ専用の性能情報収集エージェントソフトウェアを利用する。エージェントの構成や配置にはいろいろな方法があり得るため、以下ではその一例を説明する。尚、本実施例においては、一例として専用のエージェント（プログラム）を用いるものを示すが、その他の方法でもよい。

ストレージネットワーク性能管理ソフト１０９は、性能管理クライアント１２９で稼動するプログラム等からユーザが入力した情報の受信や、性能情報の分析結果の提供等を行なう。また、ストレージネットワーク性能管理ソフト１０９は、他のプログラム（各種エージェント等）へ性能情報を収集するための指示や各種コマンド等を送信する。また、ストレージネットワーク性能管理ソフト１０９は、構成情報の管理や性能情報の収集状態の管理や性能分析等も行なう。これらの詳細については、図２で説明する。

業務ソフト性能情報収集エージェント２１３とＤＢ性能情報収集エージェント２１５は、それぞれ業務ソフト２１２とＤＢ管理ソフト２１４に関する性能情報を取得するためのプログラムである。ホスト性能情報収集エージェント２１７は、ホストサーバ２０９や、ＯＳ２１６、ホストバスアダプタのポート２１８〜２２０に関する性能情報を取得する。サブシステム性能情報収集エージェント２３８は、ホストバスアダプタのポート２３９やＳＡＮスイッチを経由して、ストレージサブシステム２３４ならびにそのポート２３１〜２３３に関する性能情報を取得する。

ＮＡＳ性能情報収集エージェント２０７は、ＬＡＮ２０５を経由して、ＮＡＳ２０８に関する性能情報を取得する。ＳＡＮスイッチ性能情報収集エージェント２３６も、同じくＬＡＮ２０５を経由して、ＳＡＮスイッチ２２５〜２２７ならびにそのポート２２１〜２２３、２２８〜２３０に関する性能情報を取得する。サブシステム性能情報収集エージェント２３８と、ＮＡＳ性能情報収集エージェント２０７やＳＡＮスイッチ性能情報収集エージェント２３６は、それぞれ専用の性能情報収集サーバで稼動してもよいし、同一のサーバで稼動してもよく、いずれの場合も、ストレージネットワーク性能管理ソフト１０９とはＬＡＮ２０５を経由して通信する。

図２は、本発明の一実施例のブロック図である。ストレージネットワーク構成装置・ソフト１０１〜１０５は、ストレージネットワーク内で性能監視の対象となるハードウェアやソフトウェアである。図２のストレージネットワーク構成装置・ソフト１０１〜１０５は、図１のホストサーバ２０９〜２１１や、ホストバスアダプタのポート２１８〜２２０、業務ソフト２１２、ＤＢ管理ソフト２１４、ＯＳ２１６、ストレージサブシステム２３４ならびにそのポート２３１〜２３３、ＮＡＳ２０８、ＳＡＮスイッチ２２５〜２２７ならびにそのポート２２１〜２２４、２２８〜２３０等のうちのいずれかに当たる。

図２の性能情報収集エージェント１０６〜１０８は、ストレージネットワーク構成装置・ソフト１０１〜１０５から性能情報を取得するソフトウェアである。性能情報収集エージェント１０６〜１０８は、図１の業務ソフト性能情報収集エージェント２１３や、ＤＢ性能情報収集エージェント２１５、ホスト性能情報収集エージェント２１７、サブシステム性能情報収集エージェント２３８、ＮＡＳ性能情報収集エージェント２０７、ＳＡＮスイッチ性能情報収集エージェント２３６等のうちのいずれかに当たる。

ストレージネットワークの性能情報の収集と監視は以下のように行なわれる。性能情報収集エージェント１０６の性能情報収集部１２３は、各エージェントが有するスケジューリング設定に従い定期的にタイマーによって起動されるか、ストレージネットワーク性能管理ソフト１０９の要求で起動される。性能情報収集部１２３は、起動した後、性能情報収集状態テーブル１２０を参照して、自エージェントが担当するストレージネットワーク構成装置・ソフトの性能項目について収集の可否、頻度、最終日時等の収集状態を調べる。

ネットワーク構成要素の個々の性能項目で性能監視の候補となるものをメトリックと呼ぶ。たとえば、メトリックの一例として、CPU使用率、メモリ使用量、記憶装置に対するI/O回数やI/Oビジー率、転送レート、スループット、データベース管理ソフトのバッファヒット率や挿入・更新・削除レコード数、Webサーバのレスポンスの時間、ファイルシステムやディスクの空き容量や利用率、入出力データ量、利用時刻など、ネットワークインタフェースのエラー回数、バッファのオーバーフローおよびフレームのエラーなどがある。

性能情報収集部１２３は、性能情報の収集状態を調べた結果に基づいて、収集すべきメトリックを測定できるストレージネットワーク構成装置・ソフトの性能情報取得部１２２に対し測定値の送信を要求する。この要求に応えて性能情報取得部１２２から返信されたメトリック値は、性能情報収集部１２３によってメトリック値テーブル１２４に格納される。

ストレージネットワーク性能管理ソフト１０９の性能情報収集部１２６も同様に、スケジューリング設定に従い定期的に起動する。性能情報収集部１２６は、起動した後、ネットワーク中の全メトリックに関する収集状態を性能情報収集状態テーブル１２１から検索し、収集すべきメトリック値の送信を、該当する性能情報収集エージェント１０６の性能情報応答部１２５に対して要求する。メトリック値の送信の要求を受けた性能情報応答部１２５は、要求されたメトリック値をメトリック値テーブル１２４から検索し、性能情報収集部１２６に返信する。性能情報応答部１２５から返信されたメトリック値は、性能情報収集部１２６によってメトリック値テーブル１２７に格納される。

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

ストレージネットワークの構成要素で、ひとまとまりのメトリック値を取得する単位となるものをリソースと呼ぶ。リソースとリソース間の関連については、具体例を図３で説明する。また、性能分析表示部１２８が、性能管理クライアント１２９に表示する画面の具体例を図４と図５で説明する。性能情報収集部１２３ならびに性能情報収集部１２６の処理手順の詳細は図３４で説明する。

リソース間の関連情報の収集は、上記性能情報の場合と同様、以下のように行なわれる。性能情報収集エージェント１０６の構成情報収集部１１１は、スケジューリング設定で定期的に起動されるか、ストレージネットワーク性能管理ソフト１０９の要求で起動される。構成情報収集部１１１は、起動した後、自エージェントが担当するストレージネットワーク構成装置・ソフトの構成情報取得部１１０に対しリソース間関連情報の送信を要求し、要求した情報を受信し、受信した情報をリソース間関連情報記憶部１１２に格納する。尚、各種デバイスからの情報の取得は、iSNS（Internet Storage Name Server）を利用してもよい。また、デバイスの状態の取得には、ESI（Entity Status Inquiry）を利用してもよいし、その他の方法でストレージネットワーク構成機器の情報を取得してもよい。

ストレージネットワーク性能管理ソフト１０９の構成情報収集部１１４は、スケジューリング設定で定期的に起動される。構成情報収集部１１４は、起動した後、ネットワークのすべての性能情報収集エージェントの構成情報応答部１１３（または、構成情報収集部１１４と通信可能なエージェントに含まれる構成情報応答部１１３）に対し、各エージェントで収集したリソース間関連情報の送信を要求する。構成情報収集部１１４は、要求した情報がリソース間関連情報記憶部１１２から検索されて返信されると、返信された情報をリソース間関連情報記憶部１１５に格納する。

性能情報の収集方法の変更は以下のように行なわれる。ストレージネットワーク性能管理ソフト１０９の収集状態変更部１１７は、スケジューリングで設定されたタイミングに応じた定期的な割込みやメトリック値テーブル１２７の更新を契機に起動される。収集状態変更部１１７は、起動した後、収集状態変更情報記憶部１１８と、リソース間関連情報記憶部１１５と、メトリック値テーブル１２７を参照して収集方法の変更方法を決定し、その決定に従って、性能情報収集状態テーブル１２１を更新するとともに、性能情報収集エージェント１０６の収集状態変更部１１６に性能情報収集状態テーブル１２０の更新を要求する。

ストレージネットワーク性能管理ソフト１０９の変更規則設定部１１９は、性能管理クライアント１２９からの要求に応答し、性能情報の収集方法を修正するため収集状態変更情報記憶部１１８の内容を更新する。変更規則設定部１１９が性能管理クライアント１２９に表示する画面の具体例を図６と図７で説明する。ストレージネットワーク性能管理ソフト１０９の収集状態変更部１１７の処理手順の詳細は図３５で説明する。

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

図３のストレージネットワークのハードウェアは、サーバＡ（３０１）とサーバＢ（３０２）という２つのホストサーバと、スイッチＡ（３３１）、スイッチＢ（３３８）、スイッチＣ（３４５）、スイッチＤ（３５２）という４つのＳＡＮスイッチ、サブシステムＡ（３５９）という１つのストレージサブシステムで構成される。

サーバＡでは、ＤＢ管理ソフトとサーバのハードならびにＯＳの性能情報を取得するため、それぞれＤＢ性能情報収集エージェントとホスト性能情報収集エージェントが稼動しているものとする。表Ａ（３０３）、表Ｂ（３０４）、表Ｃ（３０６）と、索引Ａ（３０５）、索引Ｂ（３０７）、表領域Ａ（３１１）〜表領域Ｃ（３１３）は、ＤＢ管理ソフトによって管理され、ＤＢ性能情報収集エージェントの情報取得対象となるリソースの一例である。いいかえると、表と索引と表領域は、データベースの性能評価をする際に関連し合うものとして、グループとして扱う。

表は、リレーショナルＤＢ管理ソフトでの表現形式に従ったデータそのものであり、索引は、表の検索を高速化するためのデータである。表領域は、ＤＢ管理ソフトにおいて表や索引を格納する領域を表わす論理的な単位である。

例えば、図３の表Ａならびに表Ｂと表領域Ａを結ぶ線は、表Ａならびに表Ｂが表領域Ａに格納される関係を表わしている。この関係はまた、業務ソフトが表Ａや表Ｂを参照したり更新したりした場合の負荷が、表領域Ａのリードやライトの負荷につながるという性能上の依存関係にもなっている。つまり、ＤＢ管理ソフトが、表に対して参照・更新の操作を行なうことに伴い、表領域にもアクセスする必要が生じる。この場合、表に対する参照等の操作による入出力操作が増えると、表に対する入出力操作に伴い表領域に対する入出力操作が増えるため、表領域に対しても入出力に伴う負荷が増えることとなる。

ファイルＡ（３１５）〜ファイルＧ（３２１）と、ボリュームＡ（３２５）〜ボリュームＣ（３２７）、ポートＡ（３２９）は、ホスト性能情報収集エージェントが情報取得の対象とするリソースの一例である。ファイルは、ＯＳがデータの入出力サービスを提供する単位であり、ボリュームは、ファイルを外部記憶装置に格納する領域としてＯＳで管理されるものである。表と表領域の間の依存関係と同様、表領域の格納先としてファイルが割り当てられ、ファイルの格納先としてボリュームが割り当てられるため、これらリソース間には性能の依存関係がある。図３の例では、表領域ＡはファイルＡ〜Ｃに格納され、ファイルＡ〜ＣはボリュームＡに格納されるため、表領域ＡとファイルＡ〜Ｃの間と、ファイルＡ〜ＣとボリュームＡの間には性能の依存関係がある。

サーバＢでも、ＤＢ性能情報収集エージェントとホスト性能情報収集エージェントが稼動しているものとする。サーバＢのＤＢ性能情報収集エージェントが情報取得対象とするリソースには、表Ｄ（３０８）と、表Ｅ（３０９）、索引Ｃ（３１０）、表領域Ｄ（３１４）があり、サーバＢのホスト性能情報収集エージェントが情報取得対象とするリソースには、ファイルＨ（３２２）、ファイルI（３２３）、ファイルＪ（３２４）と、ボリュームＤ（３２８）、ポートＢ（３３０）がある。

スイッチＡ〜スイッチＤの性能情報を取得するためＳＡＮスイッチ性能情報収集エージェントが稼動しているものとする。このエージェントが情報取得対象とするリソースには、ポートＣ（３３２）、ポートＤ（３３３）、ポートＥ（３３４）と、スイッチＡのその他ポート（３３５〜３３７）、ポートＦ（３３９）、ポートＧ（３４０）、スイッチＢのその他ポート（３４１〜３４４）、ポートＨ（３４６）、ポートＩ（３４７）、スイッチＣのその他ポート（３４８〜３５１）、ポートＪ（３５３）、ポートＫ（３５４）、ポートＬ（３５５）、ポートＭ（３５６）、スイッチＤのその他ポート（３５７、３５８）がある。

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

パリティグループは、ストレージサブシステムの機能によって複数の物理的なハードディスクドライブを論理的に１つの高速かつ高信頼のディスクドライブに見せたものである。また、論理ボリュームは、同じくストレージサブシステムの機能によって１つのパリティグループを切り分け、ホストサーバの用途に合ったサイズの論理的なディスクドライブに見せたものである。

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

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

図４は、表形式による性能情報の表示画面の一例を示す図である。この画面は性能分析表示部１２８によって性能管理クライアント１２９に表示される。表示内容は、複数のボリューム（４０２）についてある同一時点（４０１）における「毎秒ＩＯ回数」（４０３）と「転送速度」（４０４）というメトリックの値を比較するためのものである。

図５は、グラフ形式による性能情報の表示画面の一例を示す図である。この画面も性能分析表示部１２８によって性能管理クライアント１２９に表示される。グラフの横軸（５０３）と縦軸（５０２）は、それぞれ時刻とメトリック「転送速度」（５０１）の値である。図５の表示内容は、複数のボリューム（５０４）の転送速度の時間的な推移の関係を比較するためのものである。

尚、図４および図５で示した表示内容は一例であり、複数のボリュームの性能を比較する表示方法以外にも様々な表示方法がある。たとえば、クライアントコンピュータから、あるリソースを表示することを指定した場合、指定したリソースに含まれる複数のメトリックを比較できるように表示してもよい。また、リソースごとに、同じ型式の機器のメトリック情報をまとめて表示してもよいし、同種の機器ごとの平均値を表示してもよい。また、あるネットワーク機器の識別子を指定した場合に、指定したネットワーク機器が含まれるリソースや指定されたリソースと関連するリソースのメトリック値を関連付けて表示してもよい。

たとえば、予め、ボリュームＡ、論理ボリュームＡ、ポートＡ、ポートＣ、ポートＤ、ポートＨ、ポートＩ、ポートＮのこれらの要素が、ひとまとまりのリソースとして定義された情報が格納されている場合を想定する。ストレージネットワーク性能管理ソフトが、クライアントコンピュータから論理ボリュームＡを指定する指示を受け付け、予めリソースとして定義された情報に受付けた情報が含まれるか否かを判定する。そして、ストレージネットワーク性能管理ソフトが、受付けた論理ボリュームＡを含む情報がある場合は論理ボリュームＡが含まれるリソース情報に基づいて、ボリュームＡ、論理ボリュームＡ、ポートＡ、ポートＣ、ポートＤ、ポートＨ、ポートＩ、ポートＮのこれら要素の性能情報を表示する。この場合において、複数のポートを同じ座標軸のグラフとして表示し、ボリュームＡと論理ボリュームＡとを他のグラフとして表示してもよい。また、これらの性能情報を表示する際に、図３のようにサーバとスイッチとストレージとの対応関係を図示し、各要素を図示したアイコンに性能情報を付加して表示してもよい。

図６は、性能情報収集状態のデフォルト設定画面の一例を示す図である。この画面は変更規則設定部１１９によって性能管理クライアント１２９に表示され、利用者がストレージネットワーク内の全リソースのメトリックについてデフォルトの収集レベルを指定するために使用する。図６の画面は、クライアントコンピュータにおいてブラウザ等を利用して画面に表示してもよいし、その他の方法で表示してもよい。

メトリックの収集レベルは、収集の程度や頻度を表わすパラメータであり、例えば、ＯＦＦ（収集しない）や、ＨＯＵＲ（毎時１回収集）、ＭＩＮＵＴＥ（毎分１回収集）、ＳＥＣＯＮＤ（毎秒１回収集）等を使用することができる。尚、これらは情報を収集する時間の間隔の一例であり、ストレージの構成やネットワークシステムの変更があった場合に情報を収集してもよい。

画面中の６０１の表示欄には、ストレージネットワーク内のリソースがその種別や所属をもとに木構造で分類表示される。尚、画面にリソースツリーを表示する際に、ストレージ機器、ＤＢ管理ソフト、ホストサーバ等の要素ごとに、表示させる座標位置を予め定めておき、定められた座標位置に従って表示してもよい。

この木構造の接点又は接点のラベルを、ユーザがマウスポインタ等を用いて選択する。尚、接点のラベルとは、設定に対応するリソース名又はリソース分類グループの名称を指す。たとえば、「表領域Ａ」や「表領域Ｂ」や「ＤＢ Ａ」は、リソース名である。また、「表領域」や「ＤＢ管理ソフト」は、リソースを分類したグループの名称である。
つまり、リソース名「表領域Ａ」「表領域Ｂ」等に対するグループ名は「表領域」である。

前述のユーザからの選択に応じて、６０２の表示欄に、選択されたリソース（６０３）と、そのメトリック（６０４）、デフォルトの収集レベル（６０５）の一覧表が表示される。

図６の例では、図３のサーバＡで稼動するＤＢ管理ソフトの表領域が選択されて、表領域Ａ〜Ｃの全メトリックについてデフォルトの収集レベルが表示されている。６０５の欄の表示内容を変更することによって、デフォルトの情報収集の設定を変えることができる。この画面で設定した内容を格納する性能情報収集状態デフォルト設定テーブルの詳細は図３２で説明する。

図７は、性能情報収集状態の変更規則設定画面の一例を示す図である。この画面も、変更規則設定部１１９によって性能管理クライアント１２９に表示される。変更規則設定画面は、利用者がメトリック値の収集方法を指定する変更規則を入力するために使用する。図６の場合と同様、表示欄７０１の木構造の接点を選択すると、該当するリソース（７０３）とメトリック（７０４）に対して定義された変更規則の識別番号（７０５）の一覧表が表示欄７０２に表示される。また、この一覧表の中で選択された変更規則の内容は表示欄７２３に表示される。図７の例では、表示欄７０１で表領域Ａが選択され、表示欄７０２に表領域Ａに関して定義された変更規則の一覧が表示されている。表示欄７２３には、表示欄７０２で選択状態になっている番号１１の規則の内容が表示されている。

変更規則の表示欄７２３は、変更規則番号の表示欄７０６と、変更条件の指定欄７０７、変更対象の指定欄７１６、変更方法の指定欄７２０を含む。変更条件の指定欄７０７はさらに、リソース（７０８）と、そのメトリック（７０９）、本規則を適用する契機となるメトリックの値の状態（７１０）をそれぞれ指定する欄を含む。

メトリック値の状態の指定欄７１０には、値の水準や変化の傾向を表わすために使用する選択肢のリストが表示される。その選択肢には例えば以下のようなものがある。

・メトリックの値が、パラメータで指定された基準値を上回る（７１１）
・メトリックの値が、１時間前の値に対しパラメータで指定された以上の割合で増加する（７１２）
・メトリックの値が、前日の同時刻の値に対しパラメータで指定された以上の割合で増加する（７１３）
・メトリックの値が、第１のパラメータで指定された時間についての直近の平均値に対し第２のパラメータで指定された以上の割合で増加する（７１４）
・パラメータで指定された点数ごとにメトリックの値の移動平均をとったとき、現在の移動平均の値が前回の移動平均の値を上回る（７１５）。（たとえば、1時の時点、２時の時点、３時の時点で性能情報を取得し、前記取得した性能情報の値を足して３で割った値を３時の時点での移動平均の値とする。そして、３時の時点、４時の時点、５時の時点で性能情報を取得し、前記取得した性能情報の値から平均値を求め、５時の時点での移動平均の値とする。そして、これらの移動平均の値を比較し、差分を求める。また、メトリックの値によっては、性能情報を取得する間隔を微小な時刻にしてもよい。また、変化が少ない値であれば、数ヶ月ごとを単位として移動平均の値を取得して判定してもよい）。

図７の例では、リソースの指定欄７０８とメトリックの指定欄７０９で、それぞれ表領域Ａと毎秒ＩＯ回数が選択され、メトリック値状態の指定欄７１０では選択肢７１１が選択されそのパラメータとして８００が入力されている。以上の設定は「表領域Ａの毎秒ＩＯ回数の値が８００を上回る」という変更条件を意味する。

変更対象の指定欄７１６は、リソース（７１７）と、そのリソースを起点とした関連リソース（７１８）、メトリック（７１９）をそれぞれ指定する欄からなる。変更規則が適用されると、７１７と７１８で指定されたリソースについて、７１９で指定されたメトリックの収集方法が変更される。関連リソースの指定欄７１８には、規則の適用対象となるリソースを表わすために使用する選択肢のリストが表示される。その選択肢には例えば以下のようなものがある。

・７１７で指定されたリソースのみ
・７１７で指定されたリソースを起点としてリソース間の性能の依存関係を上流側に（性能の負荷をかける側に）辿った経路上の全リソース
・７１７で指定されたリソースを起点としてリソース間の性能の依存関係を下流側に（性能の負荷がかけられる側に）辿った経路上の全リソース
・７１７で指定されたリソースを起点としてリソース間の性能の依存関係を上流側と下流側に辿った経路上の全リソース
・７１７で指定されたリソースを起点としてリソース間の性能の依存関係を上流側と下流側に辿った経路上の全リソース、ならびに、その経路上のリソースの各々を新たな起点として性能の依存関係を上流側と下流側に辿った経路上の全リソース。

ここで、性能の負荷をかける側とは、ＤＢ管理ソフト等のストレージサブシステムを利用するソフトウェアが稼動しているコンピュータが接続されている側を意味する。また、性能の負荷がかけられる側とは、ストレージサブシステム側を意味する。

尚、上述した規則の適用対象となるリソース間の関係は一例であり、その他のものでもよい。たとえば、予めストレージ装置とサーバ間のパスの情報（ストレージポート番号、ＷＷＮ（World-Wide Name）、スイッチのポート番号、ホストのポート番号、ホスト名、ＩＰアドレスなど）を格納しておき、パスの情報に基づいて、リソース間に依存関係があるか否かを判定してもよい。

また、リソースの依存関係を判定する場合に、経路に含まれる機器のうちアプリケーションプログラムが実行されるコンピュータに接続する方向を上流とし、ストレージ機器が接続されている方向を下流として判断してもよい。たとえば、図３に示すような構成において、表Ａ３０３からパリティグループＡに至る経路は複数あるが、「表Ａ−表領域Ａ−ファイルＢ−ボリュームＡ−ポートＡ−ポートＣ−ポートＤ−ポートＨ−ポートＩ−ポートＮ−論理ボリュームＡ−パリティグループＡ」という経路を例にあげて説明する。このような経路において、ボリュームＡの上流は「表Ａ−表領域Ａ−ファイルＢ−ボリュームＡ」となる。ボリュームＡの下流は「ボリュームＡ−ポートＡ−ポートＣ−ポートＤ−ポートＨ−ポートＩ−ポートＮ−論理ボリュームＡ−パリティグループＡ」となる。ここでは、１つの経路を例として説明したが、同様な方法を用いて複数の経路において上下流の判定を行なって規則の適用対象となるリソースを指定してもよい。

また、これ以外のものをリソースの依存関係として設定してもよい。このように、あるリソースを単独で指定するだけでなく、リソースと依存関係のあるものも指定できるようにすることによって、個々リソースに対して設定を行なう手間を省くことができる。

尚、リソース間の依存関係の具体例については、図８、図１１、図１４、図１７、図２０、図２３などで説明する。

図７の例では、リソースの指定欄７１７で表領域Ａが選択され、関連リソースの指定欄７１８では経路の上下流のリソースを含む選択肢が選択されている。メトリックの指定欄７１９で指定されているアステリスクマーク（＊）は該当するリソースがもつすべてのメトリックを意味する。従って、図７の設定は「表領域Ａとその上下流のリソースについて、各々がもつすべてのメトリックの収集方法を変更する」ということを意味する。

尚、メトリックの指定欄７１９は、上述したように全てのメトリックを指定してもよいし、ユーザが「アクセス頻度、ポートI/O回数」などのように複数の項目を指定してもよい。また、関連リソースの指定欄７１８で指定された項目に応じて、ユーザが指定可能なメトリックを選別し、選別したメトリックをメニューとして画面に表示してもよい。

変更方法の指定欄７２０は、収集レベル（７２１）と自動復帰の可否（７２２）を指定する欄を含む。収集レベルの指定欄７２１には、規則の適用時に使用するメトリック値収集方法の選択肢のリストが表示される。その選択肢には例えば以下のようなものがある。

・メトリック値を収集しない（ＯＦＦ）
・メトリック値を毎時１回収集する（ＨＯＵＲ）
・メトリック値を毎分１回収集する（ＭＩＮＵＴＥ）
・メトリック値を毎秒１回収集する（ＳＥＣＯＮＤ）。

尚、上述したメトリック情報の収集のタイミングは一例であり、その他の選択肢があってもよい。たとえば、指定されたリソースや指定されたメトリックに応じて、情報の収集のタイミングを変更してもよい。
また、上述した性能情報を収集する時間の間隔の選択肢や性能情報の収集の要否を選択する選択肢以外にも、たとえば０．３秒毎に１回情報を収集するというような選択肢を設けてもよい。

自動復帰の可否の指定欄７２２には、規則の適用条件が解消されたとき、適用時の変更の効果をどうするかについての選択肢のリストが表示される。その選択肢には以下がある。

・条件が解消しても効果を維持する（片方向）
・条件が解消したら効果を無効にする（双方向）。

ここで、片方向とは、性能情報の収集の頻度が低い状態から高い状態に変化することはあっても、性能情報の収集の頻度が高い状態から低い状態に変化することはない場合を意味する。つまり、情報収集を行なう時間の間隔を狭くした後で、変更規則の適用条件が解消されても、情報収集を行なう時間間隔を広くすることがないことを片方向と言う。

また、性能情報を収集する頻度が低い状態から高い状態にも、高い状態から低い状態にも、どちらにも変化する場合を双方向と言う。双方向を選択した場合には、変更規則の適用条件が解除された場合には、情報収集の頻度を元のレベルへ戻す。つまり、対象となるリソースから情報収集を行なう時間の間隔を、変更規則を適用前の情報収集の時間間隔と同じ時間間隔となるように、時間間隔を広くする場合もあるし、時間間隔を狭くする場合もある。

ここでは一例として、性能情報を取得する時間間隔等について記載したが、その他の要件について双方向と片方向の概念を適用してもよい。

双方向を選択しても、同じメトリックに対し収集レベルの異なる複数の変更規則が適用される場合があるので、条件が解消すれば必ず適用前の収集レベルに戻る訳ではない。言い換えると、複数の変更規則が適用されている場合に、変更規則１つのみについて規則の適用が解除されたとしても、その他の変更規則については適用されたままの状態が続く場合がある。

また、最終的な収集方法は、効果が有効な変更規則の中で収集レベルが最も高いものに決まる。尚、収集レベルの指定欄７２１で指定された収集レベルの中で、情報を採取する間隔が短いものは収集レベルが高いと判定する。

図７の７０７と７１６、７２０の各指定欄の設定例を総合すると番号１１の変更規則は「表領域Ａの毎秒ＩＯ回数の値が８００を上回ったなら、表領域Ａとその上下流のリソースについて、各々がもつすべてのメトリックを毎分１回収集するよう変更する（ただし、現在の収集レベルがそれより低い場合）。また、その条件が解消されたら、表領域Ａとその上下流のリソースについて、各々がもつすべてのメトリックの収集レベルを元に戻す（ただし、より高い収集レベルの変更規則が有効であればそのレベルにする）。」ことを意味する。

図７の画面で定義した変更規則の内容を格納する収集状態変更規則テーブルの詳細は図３１で説明する。

図８は、サーバＡのＤＢ性能情報収集エージェントが使用するリソース間関連情報記憶部のテーブル構成ならびにテーブル構造の一例を示す図である。図２の１０６を、図３のサーバＡのＤＢ性能情報収集エージェントであるとすると、そのリソース間関連情報記憶部１１２は、ＤＢオブジェクト・表領域間関連テーブル８０１と表領域・ファイル間関連テーブル８０４で構成される。図８の各テーブルの内容は、図３の例に対応する値を格納した状態で示している。

図８で示すＤＢオブジェクト・表領域間関連テーブル８０１は、図３で説明した表リソースや索引リソースと、表領域リソースとの間の性能の依存関係を記録するためのものであり、ＤＢオブジェクト識別子格納欄８０２と表領域識別子格納欄８０３からなる。テーブルの各行は、表または索引と表領域の間の依存関係の１つに対応する。ＤＢオブジェクト識別子格納欄８０２には、表または索引を識別する名称もしくはコード等（以下、識別子と呼ぶ）を格納する。表領域識別子格納欄８０３には、欄８０２で指定された表または索引と依存関係をもつ表領域の識別子を格納する。図８では例えば、テーブルの第１行目の内容として表Ａと表領域Ａの依存関係が記録されている。

図８で示す表領域・ファイル間関連テーブル８０４は、表領域リソースとファイルリソースとの間の性能の依存関係を記録するためのものであり、表領域識別子格納欄８０５とファイル識別子格納欄８０６からなる。テーブルの各行は、表領域とファイルの間の依存関係の１つに対応する。表領域識別子格納欄８０５には、表領域の識別子を格納し、ファイル識別子格納欄８０６には、欄８０５で指定された表領域と依存関係をもつファイルの識別子を格納する。図８では例えば、テーブルの第１行目の内容として表領域ＡとファイルＡの依存関係が記録されている。

図９は、図３のサーバＡのＤＢ性能情報収集エージェントが使用する性能情報収集状態テーブルの構造の一例を示す図である。性能情報収集状態テーブル９０１は、リソース識別子格納欄９０２と、メトリック識別子格納欄９０３、収集レベル格納欄９０４、最終収集日時格納欄９０５を含む。テーブルの各行は、あるリソースのあるメトリックについての収集状態を表わす。リソース識別子格納欄９０２とメトリック識別子格納欄９０３には、それぞれリソースとメトリックの識別子を格納する。

収集レベル格納欄９０４には、欄９０２で指定されたリソースの、欄９０３で指定されたメトリックの現在の収集レベルを格納する。最終収集日時格納欄９０５には、欄９０２がＯＦＦ以外の場合、欄９０２と欄９０３で指定されたリソースのメトリックについて、その値の最終の収集日時を格納する。一方、欄９０２がＯＦＦの場合、欄９０２と欄９０３で指定されたリソースのメトリックについて、収集レベルがＯＦＦの状態のままで経過した最近の日時を格納する。図の例では、テーブルの第１行目に、表Ａの挿入レコード数の値が現在未収集であり、その状態が２００３年7月３１日１５時まで続いたことが記録されている。また、最後から３番目の行には、表領域Ｃの転送速度の値が現在毎時１回収集されており、その最終最終収集日時が２００３年7月３１日１５時であったことが記録されている。

図１０は、図３のサーバＡのＤＢ性能情報収集エージェントが使用するメトリック値テーブルの構造の一例を示す図である。メトリック値テーブル１００１は、日時格納欄１００２と、リソース識別子格納欄１００３、メトリック識別子格納欄１００４、メトリック値格納欄１００５からなる。テーブルの各行は、ある日時にあるリソースのあるメトリックについて収集した値を表わす。日時格納欄１００２には、メトリック値を収集した日時を格納する。リソース識別子格納欄１００３とメトリック識別子格納欄１００４には、それぞれ収集対象となったリソースとメトリックの識別子を格納する。メトリック値格納欄１００５には、収集したメトリックの値を格納する。

図１０の例では、テーブルの第１行目に、２００３年7月３１日１３時に、表領域Ａの毎秒ＩＯ回数の値として１６５．３を収集したことが記録されている。尚、性能情報収集エージェントが、ストレージネットワーク構成装置・ソフトから収集したメトリック値の解析処理を行う処理部を有しており、メトリック値の合計値や移動平均値を求め、各性能情報収集エージェントが保持するメトリック値テーブルへ格納してもよい。また、性能情報収集エージェントが、外部のプログラムを利用してメトリック値の集計等の処理を行ってもよい。

図１１と、図１４、図１７、図２０、図２３は、それぞれ図３のサーバＡのホスト性能情報収集エージェントと、図３のサーバＢのＤＢ性能情報収集エージェント、図３のサーバＢのホスト性能情報収集エージェント、ＳＡＮスイッチ性能情報収集エージェント、サブシステム性能情報収集エージェントが使用するリソース間関連情報記憶部のテーブル構成ならびにテーブル構造の一例を示す図である。

図１１は、図３のサーバＡのホスト性能情報収集エージェントが使用するリソース間関連情報記憶部で用いる情報の例である。サーバＡのホスト性能情報収集エージェントが使用するリソース間関連情報記憶部は、ファイル・ボリューム間関連テーブル１１０１とボリューム・論理ボリューム・ポート間関連テーブル１１０４を含む。

図１７は、図３のサーバＢのホスト性能情報収集エージェントが使用するリソース間関連情報記憶部で用いる情報の例である。サーバＢのホスト性能情報収集エージェントが使用するリソース間関連情報記憶部は、ファイル・ボリューム間関連テーブル１７０１とボリューム・論理ボリューム・ポート間関連テーブル１７０４を含む。

サーバＢのＤＢ性能情報収集エージェントが使用するリソース間関連情報記憶部は、図８のサーバＡのＤＢ性能情報収集エージェントと同様に、図１４のＤＢオブジェクト・表領域間関連テーブル１４０１と表領域・ファイル間関連テーブル１４０４を含む。

ＳＡＮスイッチ性能情報収集エージェントが使用するリソース間関連情報記憶部は、図２０のポート間通信経路テーブル２００１の情報を利用する。また、サブシステム性能情報収集エージェントが使用するリソース間関連情報記憶部は、図２３の論理ボリューム・パリティグループ間関連テーブル２３０１を含む。図１１、図１４、図１７、図２０、図２３の各テーブルの内容は、図３の例に対応する値を格納した状態で示している。

ファイル・ボリューム間関連テーブル（１１０１、１７０１）は、ファイルリソースとボリュームリソースとの間の性能の依存関係を記録するためのものであり、ファイル識別子格納欄（１１０２、１７０２）とボリューム識別子格納欄（１１０３、１７０３）を含む。テーブルの各行は、ファイルとボリュームの間の依存関係の１つに対応する。ファイル識別子格納欄（１１０２、１７０２）には、ファイルの識別子を格納し、ボリューム識別子格納欄（１１０３、１７０３）には、ファイル識別子格納欄で指定されたファイルと依存関係をもつボリュームの識別子を格納する。例えば、図１１ではテーブル１１０１の第１行目の内容としてファイルＡとボリュームＡの依存関係が、図１７ではテーブル１７０１の第１行目の内容としてファイルＨとボリュームＤの依存関係が記録されている。

ボリューム・論理ボリューム・ポート間関連テーブル（１１０４、１７０４）は、ボリュームと論理ボリュームの間の依存関係、さらに、両者と、両者をつなぐ入出力経路上のホストバスアダプタ側ならびにストレージサブシステム側のポートの間の依存関係を記録するためのものであり、ボリューム識別子格納欄（１１０５、１７０５）と、論理ボリューム識別子格納欄（１１０６、１７０６）、ホスト側ポート識別子格納欄（１１０７、１７０７）、ストレージ側ポート識別子格納欄（１１０８、１７０８）を含む。

ボリューム識別子格納欄（１１０５、１７０５）には、ボリュームの識別子を格納し、論理ボリューム識別子格納欄（１１０６、１７０６）には、ボリューム識別子格納欄で指定されたボリュームと依存関係をもつ論理ボリュームの識別子を格納する。ホスト側ポート識別子格納欄（１１０７、１７０７）には、対応するボリュームと論理ボリュームをつなぐ入出力経路上のホストバスアダプタ側ポートの識別子を格納し、ストレージ側ポート識別子格納欄（１１０８、１７０８）には、同様のストレージサブシステム側ポートの識別子を格納する。

例えば、図１１ではテーブル１１０４の第１行目の内容としてボリュームＡと、論理ボリュームＡ，ポートＡ、ポートＮの依存関係が、図１７ではテーブル１７０４の第１行目の内容としてボリュームＤと、論理ボリュームＤ、ポートＢ、ポートＰの依存関係が記録されている。

尚、性能の依存関係を示す情報には、コンピュータからストレージへアクセスするための経路上のリソースやメトリック情報に関する情報を含んでもよいし、ストレージ装置に関する情報を含んでもよいし、データベース管理ソフトが管理する表の情報やファイルシステムが管理するファイルの情報を含んでもよいし、これらを対応づけた情報を含んでもよいし、その他のものを含む情報であってもよい。

また、依存関係を示す情報を記憶装置へ格納する場合に、ストレージネットワーク性能管理ソフトが保持する経路情報やストレージやコンピュータに関する情報を、クライアントプログラム（ブラウザ）等を用いて画面に表示し、ユーザがクライアントプログラムへ入力したリソース間・メトリック間の依存関係の指示を受信し、当該指示に基づいて依存関係を示す情報を記憶装置へ格納してもよい。また、ユーザが、リソース間関連情報記憶部へ、予め依存関係を示す情報を格納しておいてもよいし、その他の方法でもよい。

図１４のサーバＢのＤＢオブジェクト・表領域間関連テーブル１４０１は、ＤＢオブジェクト識別子格納欄１４０２と表領域識別子格納欄１４０３を含む。同じくサーバＢの表領域・ファイル間関連テーブル１４０４は表領域識別子格納欄１４０５とファイル識別子格納欄１４０６を含み、各格納欄の内容も同様である。図１４の例では、テーブル１４０１の第１行目に表Ｄと表領域Ｄの依存関係が、テーブル１４０４の第１行目に表領域ＤとファイルＨの依存関係が記録されている。

図２０のポート間通信経路テーブル２００１は、ホストバスアダプタ側ならびにストレージサブシステム側のポートと、両者間の入出力経路上にあるＳＡＮスイッチのポートの間の依存関係を記録するためのものである。ポート間通信経路テーブル２００１は、ホスト側ポート識別子格納欄２００２と、ストレージ側ポート識別子格納欄２００３、スイッチポート識別子リスト格納欄２００４を含む。

ホスト側ポート識別子格納欄２００２には、ホストバスアダプタのポートの識別子を格納し、ストレージ側ポート識別子格納欄２００３には、ストレージサブシステムのポートの識別子を格納する。スイッチポート識別子リスト格納欄２００４には、欄２００２のポートと欄２００３のポートをつなぐ経路上にあるＳＡＮスイッチポートの識別子の列を格納する。図２０の例では、テーブルの第１行目にポートＡならびにポートＮと、その間のポート系列｛ポートＣ、ポートＤ、ポートＨ、ポートＩ｝の依存関係が記録されている。

尚、図２０のスイッチポート識別子リスト格納欄２００４には、サーバ（DBMSやアプリケーションプログラム等が稼動するコンピュータ）方向へ接続するスイッチのポートの識別子が左、ストレージ装置方向へ接続するスイッチのポートが右になるようポートの識別子が並んでいる。このようなポートの対応関係を用いて、図７の関連リソースの指定欄７１８で「パス上流」「パス下流」「パス上下流」のいずれかを指定された場合に、ポート識別子列の左側を「パスの上流」と判定し、ポート識別子の列の右側を「パスの下流」と判定してもよい。

たとえば、ユーザが図７の画面を用いて「スイッチＡ」をリソース７１７として指定し「パス下流を含む」を関連リソースの指定欄７１８で指定した場合を例として説明する。スイッチポート識別子リスト格納欄２００４に｛ポートＣ、ポートＤ、ポートＨ、ポートＩ｝という情報がある場合には、スイッチＡのポートであるポートＣとポートＤのうち、ストレージ装置側のポートであるポートＤ及びポートＤの右側に並んでいるリソースが、スイッチＡから下流にあると判定する。つまり、ポートＤ、ポートＨ、ポートＩが、パス下流に含まれるリソースである。

図２３の論理ボリューム・パリティグループ間関連テーブル２３０１は、論理ボリュームリソースとパリティグループリソースとの間の依存関係を記録するためのものである。論理ボリューム・パリティグループ間関連テーブル２３０１は、論理ボリューム識別子格納欄２３０２とパリティグループ識別子格納欄２３０３を含む。テーブルの各行は、ボリュームとパリティグループの間の依存関係の１つに対応する。論理ボリューム識別子格納欄２３０２には、論理ボリュームの識別子を格納し、パリティグループ識別子格納欄２３０３には、欄２３０２で指定された論理ボリュームと依存関係をもつパリティグループの識別子を格納する。図２３の例では、テーブルの第１行目に論理ボリュームＡとパリティグループＡの依存関係が記録されている。

図１２は、サーバＡのホスト性能情報収集エージェントが使用する性能情報収集状態テーブルの一例を示す図である。
図１５は、サーバＢのＤＢ性能情報収集エージェントが使用する性能情報収集状態テーブルの一例を示す図である。
図１８は、サーバＢのホスト性能情報収集エージェントが使用する性能情報収集状態テーブルの一例を示す図である。
図２１は、ＳＡＮスイッチ性能情報収集エージェントが使用する性能情報収集状態テーブルの一例を示す図である。
図２４は、サブシステム性能情報収集エージェントが使用する性能情報収集状態テーブルの一例を示す図である。

これらエージェントが使用する性能情報収集状態テーブル（１２０１、１５０１、１８０１、２１０１、２４０１）の構造は、図９の場合と同様、リソース識別子格納欄（１２０２、１５０２、１８０２、２１０２、２４０２）と、メトリック識別子格納欄（１２０３、１５０３、１８０３、２１０３、２４０３）、収集レベル格納欄（１２０４、１５０４、１８０４、２１０４、２４０４）、最終収集日時格納欄（１２０５、１５０５、１８０５、２１０５、２４０５）を含む。各格納欄の内容は、各エージェントが格納する。各欄に格納する情報の説明は図９と同様である。
図１３は、サーバＡのホスト性能情報収集エージェントが使用するメトリック値テーブルの一例を示す図である。
図１６は、サーバＢのＤＢ性能情報収集エージェントが使用するメトリック値テーブルの一例を示す図である。
図１９は、サーバＢのホスト性能情報収集エージェントが使用するメトリック値テーブルの一例を示す図である。
図２２は、ＳＡＮスイッチ性能情報収集エージェントが使用するメトリック値テーブルの一例を示す図である。
図２５は、サブシステム性能情報収集エージェントが使用するメトリック値テーブルの一例を示す図である。

これらエージェントが使用するメトリック値テーブル（１３０１、１６０１、１９０１、２２０１、２５０１）の構造は、図１０の場合と同様、日時格納欄（１３０２、１６０２、１９０２、２２０２、２５０２）と、リソース識別子格納欄（１３０３、１６０３、１９０３、２２０３、２５０３）、メトリック識別子格納欄（１３０４、１６０４、１９０４、２２０４、２５０４）、メトリック値格納欄（１３０５、１６０５、１９０５、２２０５、２５０５）を含む。各欄の内容は、各エージェントが格納する。各欄に格納する情報の説明は図１０と同様である。

図２１の例で、ＳＡＮスイッチ性能情報収集エージェントが使用する性能情報収集状態テーブル２１０１の収集レベル格納欄２１０４の値がすべてＯＦＦであるため、図２２のメトリック値テーブル２２０１は空となっている。

図２６〜図２８は、ストレージネットワーク性能管理ソフト１０９が使用するリソース間関連情報記憶部１１５のテーブル構成ならびにテーブル構造の一例を示す図である。

リソース間関連情報記憶部１１５は、ＤＢオブジェクト・表領域間関連テーブル２６０１と、表領域・ファイル間関連テーブル２６０４、ファイル・ボリューム間関連テーブル２７０１、ボリューム・論理ボリューム・ポート対応テーブル２８０１、論理ボリューム・パリティグループ間関連テーブル２７０４からなる。これらテーブルの内容は、構成情報収集部１１４を使って、ストレージネットワーク内のすべての性能情報収集エージェントから各々が持つリソース間関連テーブル（８０１、８０４、１１０１、１１０４、１４０１、１４０４、１７０１、１７０４、２００１、２３０１）の内容を集めて作成される。

図２６のＤＢオブジェクト・表領域間関連テーブル２６０１は、テーブル８０１やテーブル１４０１と同様、ＤＢオブジェクト識別子格納欄２６０２と表領域識別子格納欄２６０３を含む。また、各欄に格納する情報の説明もテーブル８０１等と同様である。

ストレージネットワーク性能管理ソフト１０９に含まれる構成情報収集部１１４が、テーブル８０１とテーブル１４０１の情報を収集し、テーブル８０１とテーブル１４０１のすべての行を合わせたものが、テーブル２６０１の行となる。

図２６の表領域・ファイル間関連テーブル２６０４は、テーブル８０４やテーブル１４０４と同様、表領域識別子格納欄２６０５とファイル識別子格納欄２６０６を含む。また、各欄に格納する情報の説明もテーブル８０４等と同様である。

ストレージネットワーク性能管理ソフト１０９に含まれる構成情報収集部１１４が、テーブル８０４とテーブル１４０４の情報を収集し、テーブル８０４とテーブル１４０４のすべての行を合わせたものが、テーブル２６０４の行となる。

図２７のファイル・ボリューム間関連テーブル２７０１は、テーブル１１０１やテーブル１７０１と同様、ファイル識別子格納欄２７０２とボリューム識別子格納欄２７０３を含む。また、各欄に格納する情報の説明も同様である。

ストレージネットワーク性能管理ソフト１０９に含まれる構成情報収集部１１４が、テーブル１１０１とテーブル１７０１の情報を収集し、テーブル１１０１とテーブル１７０１のすべての行を合わせたものが、テーブル２７０１の行となる。

図２８のボリューム・論理ボリューム・ポート対応テーブル２８０１は、テーブル１１０４や、テーブル１７０４、テーブル２００１と同様、ボリューム識別子格納欄２８０２と、論理ボリューム識別子格納欄２８０３、ホスト側ポート識別子格納欄２８０４、ストレージ側ポート識別子格納欄２８０５、スイッチポート識別子リスト識別子格納欄２８０６を含む。また、各欄に格納する情報の説明もテーブル１１０４等と同様である。

ストレージネットワーク性能管理ソフト１０９に含まれる構成情報収集部１１４が、テーブル１１０４とテーブル１７０４、テーブル２００１の情報を収集し、テーブル１１０４とテーブル１７０４のすべての行を合わせ、ホスト側ポートとストレージ側ポートをキーにしてテーブル２００１と結合したものが、テーブル２８０１となる。

図２７の論理ボリューム・パリティグループ間関連テーブル２７０４は、テーブル２３０１と同様、論理ボリューム識別子格納欄２７０５とパリティグループ識別子格納欄２７０６を含む。また、各欄に格納する情報の説明もテーブル２３０１等と同様である。

ストレージネットワーク性能管理ソフト１０９に含まれる構成情報収集部１１４が、テーブル２３０１の情報を収集し格納する。テーブル２７０４の行は、テーブル２３０１の行と一致する。

尚、図３の例では、ストレージサブシステムが１台（サブシステムＡ）だけ、それを監視するエージェントも１つだけの構成例としたため、テーブル２７０４とテーブル２３０１が一致するが、これ以外の場合もある。たとえば、サブシステムが複数台であり、エージェントも複数である場合は、複数のテーブルの行を１つのテーブルに集めることになるので、テーブルの内容は一致しない。

図２９は、ストレージネットワーク性能管理ソフト１０９が使用する性能情報収集状態テーブル１２１の構造の一例を示す図である。このテーブルの内容の各該当部分が、収集状態変更部１１７によって、ネットワーク内のそれぞれのエージェントに配布され、当該エージェントが性能情報収集状態テーブル（９０１、１２０１、１５０１、１８０１、２１０１、２４０１）に情報を格納する。

図２９の性能情報収集状態テーブル１２１は、テーブル９０１等と同様、リソース識別子格納欄２９０１と、メトリック識別子格納欄２９０２、収集レベル格納欄２９０３、最終収集日時格納欄２９０４を含む。また、各欄に格納する情報の説明もテーブル９０１等と同様である。最終収集日時格納欄の内容を除けば、テーブル９０１と、テーブル１２０１、テーブル１５０１、テーブル１８０１、テーブル２１０１、テーブル２４０１のすべての行を合わせたものが、テーブル１２１の行となる。

これらテーブルの最終収集日時格納欄は、該当するエージェントやストレージネットワーク性能管理ソフト１０９によって個々に利用されるので、対応する行であってもその値は必ずしも一致しない。

図３０は、ストレージネットワーク性能管理ソフト１０９が使用するメトリック値テーブル１２７の構造の一例を示す図である。このテーブルの内容は、ストレージネットワーク性能管理ソフト１０９が性能情報収集部１２６を使って、ストレージネットワーク内のすべての性能情報収集エージェントから各々が持つメトリック値テーブル（１００１、１３０１、１６０１、１９０１、２２０１、２５０１）の内容を集めて作成される。メトリック値テーブル１２７は、テーブル１００１等と同様、日時格納欄３００１と、リソース識別子格納欄３００２、メトリック識別子格納欄３００３、メトリック値格納欄３００４を含む。また、各欄に格納する情報の説明もテーブル１００１等と同様である。性能情報収集部１２６が、テーブル１００１と、テーブル１３０１、テーブル１６０１、テーブル１９０１、テーブル２２０１、テーブル２５０１の情報を収集し、収集した情報のすべての行を合わせたものが、テーブル１２７の行となる。

図３１〜図３３は、ストレージネットワーク性能管理ソフトが使用する収集状態変更情報記憶部１１８のテーブル構成ならびにテーブル構造の一例を示す図である。収集状態変更情報記憶部１１８は、収集状態変更規則テーブル３１０１と、性能情報収集状態デフォルト設定テーブル３２０１、変更規則活性化状態テーブル３３０１からなる。

図３１は、収集状態変更規則テーブルの構造の一例を示す図である。収集状態変更規則テーブル３１０１は、図７で説明した変更規則設定画面を使って利用者が定義した変更規則の内容を記録するためのものである。収集状態変更規則テーブル３１０１は、変更条件リソース格納欄３１０２と、変更条件メトリック格納欄３１０３、変更規則番号格納欄３１０４、変更条件コード格納欄３１０５、変更条件パラメータリスト格納欄３１０６、変更対象リソース格納欄３１０７、変更対象拡張コード格納欄３１０８、変更対象メトリック格納欄３１０９、変更後収集レベル格納欄３１１０、変更方向コード格納欄３１１１を含む。

収集状態変更規則テーブル３１０１の各行は、１つの変更規則に対応する。変更条件リソース格納欄３１０２と変更条件メトリック格納欄３１０３には、それぞれ欄７０８で指定されたリソースの識別子と、欄７０９で指定されたメトリックの識別子を格納する。変更規則番号格納欄３１０４には、新しい規則が定義されるたびに割り当てられ、欄７０６に表示される番号を格納する。変更条件コード格納欄３１０５には、メトリック値の状態の指定欄７１０で選ばれた選択肢を識別するコードを格納する。図３１の例の場合は、変更条件コード格納欄３１０５に、コード「１」が格納されている。メトリック値の状態の指定欄７１０で表示された条件７１１〜７１５に、それぞれコードを割り当て、図７の画面から指定された条件に対応づけられたコードを格納する。この例では図７の７１１の条件に対してコード「１」が対応づけられている。ユーザが、条件７１１を指定したことに伴い、収集状態変更規則テーブル３１０１の変更条件コード格納欄３１０５にコード「１」が格納される。

変更条件パラメータリスト格納欄３１０６には、欄７１０で選ばれる選択肢に対して与えられたパラメータのリストを格納する。変更対象リソース格納欄３１０７には、欄７１７で指定されたリソースの識別子を格納する。変更対象拡張コード格納欄３１０８には、関連リソースの指定欄７１８で選ばれた選択肢を識別するコードを格納する。尚、図７の関連リソースの指定欄７１８には、一例として５つの条件「単独」〜「隣接パス上下流を含む」を表示している。それぞれの条件に対してコード「１」〜「５」を割り当てている。この例においては、ユーザが関連リソースの指定欄７１８で「パス上下流を含む」を選択した場合を示しているので、変更対象拡張コード格納欄３１０８に、選択した条件に対応するコード「４」が格納される。

変更対象メトリック格納欄３１０９には、欄７１９で指定されたメトリックの識別子かアステリスクマークを格納する。変更後収集レベル格納欄３１１０には、欄７２１で指定された収集レベルの識別コードを格納する。変更方向コード格納欄３１１１には、欄７２２で選ばれた選択肢を識別するコードを格納する。図３１では例えば、テーブルの第１行目に図７の画面に例示した変更規則が記録されている。図７の例においては、自動復帰の可否の指定欄７２２に、「片方向」「双方向」の２つの条件が表示されている。これらの条件に対して、それぞれコード「１」「２」を割り当てている。図７の例においては、ユーザが「双方向」の条件を指定したので、変更対象メトリック格納欄３１０９に、条件に対応するコード「２」が格納される。尚、ここでは一例として、条件とコードとを対応づけたが、これ以外のものを対応づけて情報の管理をしてもよい。

図３２は、性能情報収集状態デフォルト設定テーブルの構造の一例を示す図である。性能情報収集状態デフォルト設定テーブル３２０１は、図６で説明した画面を使って利用者が指定したデフォルトの収集レベルを記録するためのものである。性能情報収集状態デフォルト設定テーブル３２０１は、リソース格納欄３２０２と、メトリック格納欄３２０３、デフォルト収集レベル格納欄３２０４からなる。テーブルの各行にリソースごとメトリックごとのデフォルト収集レベルを登録するが、テーブルのサイズを減らすため、収集レベルがＯＦＦの場合は登録を省略する。リソース格納欄３２０２とメトリック格納欄３２０３には、それぞれ欄６０３で指定されたリソースの識別子と、欄６０４で指定されたメトリックの識別子を格納する。図３２では例えば、テーブルの第１行目に、図６に例示した表示欄６０２の一覧表の第１行目で設定した内容が記録されている。

図３３は、変更規則活性化状態テーブルの構造の一例を示す図である。メトリックの収集レベルの変更には一般に複数の変更規則が関わる。同じメトリックを対象範囲に含む複数の変更規則が適用条件を満たす場合、その規則の中で最も高い収集レベルに設定する必要がある。また規則の適用条件が解消された場合、自動復帰の指定が双方向であれば、効果が有効な残る規則の中で最も高い収集レベルに戻し、双方向でなければ、現状の収集レベルのままにしておく必要がある。

変更規則活性化状態テーブル３３０１は、以上の処理を実現するため有効な状態にある変更規則とその規則がメトリックに対して指定する収集レベルを記録するためのものである。変更規則活性化状態テーブル３３０１は、変更規則番号格納欄３３０２と、リソース格納欄３３０３、メトリック格納欄３３０４、収集レベル格納欄３３０５を含む情報である。

変更規則番号格納欄３３０２には、現在適用条件を満足している変更規則、あるいは、過去条件を満足し、かつ、自動復帰の指定が片方向である変更規則の番号を格納する。

ここで、上述の変更規則番号格納欄３３０２へ格納する内容について詳述する。変更規則には、自動復帰の指定が双方向のものと片方向のものがある。自動復帰の指定が双方向の規則は、双方向の規則を適用する時点で、適用条件を満足するか否かを判定し、判定結果に応じて変更規則が有効か否かが決まる。従って、双方向の規則については、適用条件が満足すれば変更規則活性化状態テーブルに登録し、満足しなくなれば同テーブルから削除することによって、有効な規則がテーブルに保持されていることになる。

一方、自動復帰の指定が片方向の規則は、一度適用条件を満足するとそれ以後、条件が解除された後も変更規則が有効になる。「双方向」「片方向」の「方向」は収集頻度を変化させる方向のことである。つまり、頻度が低い状態から高い状態に変化することはあっても逆はない場合を片方向と言い、低い状態から高い状態にも、高い状態から低い状態にも、どちらにも変化する場合を双方向と言う。従って、片方向の変更規則については、適用条件が満足した時点で変更規則活性化状態テーブルに登録し、それ以後はテーブルに登録した状態にしておくことによって、有効な変更規則がテーブルに保持されることになる。その結果、「変更規則番号格納欄３３０２には、現在適用条件を満足している変更規則、あるいは、過去条件を満足し、かつ、自動復帰の指定が片方向である変更規則の番号を格納する」ことになる。

リソース格納欄３３０３と、メトリック格納欄３３０４、収集レベル格納欄３３０５には、それぞれ欄３３０２の規則の適用対象であるリソースと、メトリックの識別子、規則適用時に使用する収集レベルを格納する。

図３４は、性能情報収集エージェントならびにストレージネットワーク性能管理ソフトの性能情報収集処理の手順を示すフローチャートである。この処理手順は、スケジューリング設定に従って定期的にタイマーで起動されるか、性能情報収集エージェント１０６においてはさらに、ストレージネットワーク性能管理ソフト１０９から要求されると開始する。

以下ではまず、性能情報収集エージェントの場合について手順を説明する。

まず、ステップ３４０１で、エージェントが稼動しているサーバが提供する機能を利用して、現在の日時を取得し、ステップ３４０２に進む。

ステップ３４０２では、性能情報収集状態テーブル（１２０、９０１、１２０１、１５０１、１８０１、２１０１、２４０１）の登録行のうち、今回本手順を開始して以来、未処理のものを取得し、ステップ３４０３に進む。

ステップ３４０３で、登録行がすべて処理済みと判定されれば、本手順を終了する。未処理の登録行があれば、ステップ３４０４に進む。
上述の内容を言い換えると、性能情報収集エージェント１０６の性能情報収集部１２３は、起動した後、性能情報収集状態テーブル１２０等を参照する。そして、自エージェントが担当するストレージネットワーク構成装置・ソフトの性能項目について収集の可否、頻度、最終日時等の収集状態を調べる。そして、情報収集が行なわれていない場合は、未処理と判定し、情報収集が行われている場合は処理済みと判定する。

ここで、上述した内容をさらに補足する。性能情報収集状態テーブル１２０等の各1行は、自エージェントが担当するストレージネットワーク構成装置・ソフトの性能項目の1つに、それぞれ対応する。

ステップ３４０２、３４０３、３４０４、３４１０もしくは３４１１を経て、再び３４０２に戻る繰返しループは、性能情報収集状態テーブル１２０等の各1行につき1回ループする。そして、その行に対応する性能項目が収集対象であれば（収集レベルがＨＯＵＲか、ＭＩＮＵＴＥ、ＳＥＣＯＮＤであれば）データを収集し、収集対象でなければ（収集レベルがＯＦＦであれば）データは収集せず最終日時のみ更新する。

ステップ３４０３において、繰返しループを抜けるための終了判定処理（ステップ３４０３から、ステップ３４０４へ進むか、又は、「終了」へ進むかの判定）は、性能情報収集状態テーブル１２０等のすべての行についての処理が終了したか否かの判定処理である。言い換えると、自エージェントが担当するストレージネットワーク構成装置・ソフトのすべての性能項目についてのデータ処理（収集対象であればデータを収集し、収集対象でなければ最終日時を更新する処理）が終わったか否かの判定である。

ステップ３４０４では、性能情報収集状態テーブルから取得した登録行の収集レベル格納欄（９０４、１２０４、１５０４、１８０４、２１０４、２４０４）の値を調べる。この収集レベルがＨＯＵＲ（毎時１回収集）であればステップ３４０５に進み、ＭＩＮＵＴＥ（毎分１回収集）であればステップ３４０６に、ＳＥＣＯＮＤ（毎秒１回収集）であればステップ３４０７に、ＯＦＦ（収集しない）であればステップ３４１０に進む。

ステップ３４０５では、ステップ３４０２で取得した登録行のリソース識別子格納欄（９０２、１２０２、１５０２、１８０２、２１０２、２４０２）と、メトリック識別子格納欄（９０３、１２０３、１５０３、１８０３、２１０３、２４０３）、最終収集日時格納欄（９０５、１２０５、１５０５、１８０５、２１０５、２４０５）の値を調べる。その最終収集日時からステップ３４０１で取得した現在の日時までの期間に属する１時間ごとのそのメトリックの値を、そのリソースを有するストレージネットワーク構成装置・ソフトの性能情報取得部１２２に要求し、ステップ３４０８に進む。

ステップ３４０６では、ステップ３４０５とほぼ同様で、同上期間に属する１分ごとのメトリックの値を要求して、ステップ３４０８に進む。

ステップ３４０７でも、ステップ３４０５とほぼ同様で、同上期間に属する１秒ごとのメトリックの値を要求して、ステップ３４０８に進む。

ステップ３４０８では、要求したメトリックの値を性能情報取得部１２２から受信し、ステップ３４０９に進む。

ステップ３４０９では、受信したメトリック値をメトリック値テーブル（１２４、１００１、１３０１、１６０１、１９０１、２２０１、２５０１）に追加して、ステップ３４１１に進む。

ステップ３４１１では、ステップ３４０８で受信したメトリック値が持つ日時の中で最新の日時を、ステップ３４０２で取得した登録行の最終収集日時格納欄（９０５、１２０５、１５０５、１８０５、２１０５、２４０５）に格納し、ステップ３４０２に戻る。

ステップ３４１０では、ステップ３４０１に取得した現在の日時を、ステップ３４０２で取得した登録行の最終収集日時格納欄（９０５、１２０５、１５０５、１８０５、２１０５、２４０５）に格納し、ステップ３４０２に戻る。

次に、図３４におけるストレージネットワーク性能管理ソフトの場合について手順を説明する。ストレージネットワーク性能管理ソフト１０９の性能情報収集部１２６は、予め定められたスケジューリング設定に従い、定期的に起動される。

まず、ステップ３４０１で、ストレージネットワーク性能管理ソフトが稼動しているサーバが提供する機能を利用して、現在の日時を取得し、ステップ３４０２に進む。

ステップ３４０２では、性能情報収集状態テーブル１２１の登録行のうち、今回本手順を開始して以来、未処理のものを取得する。
つまり、ステップ３４０２において、性能情報収集部１２６は、性能情報収集状態テーブル１２１からメトリックに関する収集状態を検索し、収集していないもの（未処理のもの）を取得する。そして、ステップ３４０３に進む。

ステップ３４０３で、登録行がすべて処理済みと判定されれば、本手順を終了する。未処理の登録行があれば、ステップ３４０４に進む。

ここで、上述した内容を補足説明する。性能情報収集状態テーブル１２１の各1行は、ストレージネットワーク性能管理ソフト１０９の配下にあるいずれかのエージェントが担当するストレージネットワーク構成装置・ソフトの性能項目の1つに対応する。

ステップ３４０２、３４０３、３４０４、３４１０もしくは３４１１を経て、再び３４０２に戻る繰返しループは、性能情報収集状態テーブル１２１の各1行につき1回ループする。そして、その行に対応する性能項目が収集対象であれば（収集レベルが、ＨＯＵＲ、ＭＩＮＵＴＥ、ＳＥＣＯＮＤのいずれかであれば）データをエージェントから収集し、収集対象でなければ（収集レベルがＯＦＦであれば）データは収集せず、最終日時のみ更新する。

ステップ３４０３で、繰返しループを抜けるか否かの判定（ステップ３４０４へ進むか、終了するかの判定）は、性能情報収集状態テーブル１２１のすべての行についての処理である。言い換えると、すべてのエージェントが担当するすべての性能項目についての処理（収集対象であればデータを収集し、収集対象でなければ最終日時を更新する処理）が終わったことを判定し、判定結果に応じて次のステップへ進む。

ステップ３４０４では、性能情報収集状態テーブル１２１から取得した登録行の収集レベル格納欄２９０３の値を調べる。この収集レベルがＨＯＵＲ（毎時１回収集）であればステップ３４０５に進み、ＭＩＮＵＴＥ（毎分１回収集）であればステップ３４０６に、ＳＥＣＯＮＤ（毎秒１回収集）であればステップ３４０７に、ＯＦＦ（収集しない）であればステップ３４１０に進む。

ステップ３４０５では、ステップ３４０２で取得した登録行のリソース識別子格納欄２９０１と、メトリック識別子格納欄２９０２、最終収集日時格納欄２９０４の値を調べる。その最終収集日時からステップ３４０１で取得した現在の日時までの期間に属する１時間ごとのそのメトリックの値を、そのリソースの情報を収集している性能情報収集エージェントの性能情報応答部１２５に要求し、ステップ３４０８に進む。

つまり、収集すべきメトリック値の送信を、該当する性能情報収集エージェント１０６の性能情報応答部１２５に対して要求する。

ステップ３４０６では、ステップ３４０５とほぼ同様で、同上期間に属する１分ごとのメトリックの値を要求して、ステップ３４０８に進む。

ステップ３４０７でも、ステップ３４０５とほぼ同様で、同上期間に属する１秒ごとのメトリックの値を要求して、ステップ３４０８に進む。

ステップ３４０８では、要求したメトリックの値を性能情報応答部１２５から受信し、ステップ３４０９に進む。

ステップ３４０９では、受信したメトリック値をメトリック値テーブル１２７に追加して、ステップ３４１１に進む。

ステップ３４１１では、ステップ３４０８で受信したメトリック値が持つ日時の中で最新の日時を、ステップ３４０２で取得した登録行の最終収集日時格納欄２９０４に格納し、ステップ３４０２に戻る。

ステップ３４１０では、ステップ３４０１に取得した現在の日時を、ステップ３４０２で取得した登録行の最終収集日時格納欄２９０４に格納し、ステップ３４０２に戻る。

図３５は、ストレージネットワーク性能管理ソフトの収集状態変更処理の手順を示すフローチャートである。この処理手順は、スケジューリング設定に従って定期的にタイマーで起動されるか、メトリック値テーブル１２７の更新を契機に開始する。

まず、ステップ３５０１で、収集状態変更規則テーブル３１０１の登録行のうち、今回本手順を開始して以来、未処理のものを取得し、ステップ３５０２に進む。

ステップ３５０２で、登録行がすべて処理済みと判定されれば、本手順を終了する。未処理の登録行があれば、ステップ３５０３に進む。

ここで、上記の内容を詳述する。収集状態変更規則テーブル３１０１の各1行は、図７の画面を使ってユーザが定義した収集状態の変更規則に、それぞれ対応する。ステップ３５０１、３４０２、３４０３等を経て、再び３５０１に戻る繰返しループは、収集状態変更規則テーブル３１０１の各1行につき1回ループする。そして、収集状態変更規則テーブル３１０１の各1行に対応する変更規則の条件が成立するかどうか等に応じて、性能情報の収集状態を更新または現状維持する。

ステップ３５０２で、繰返しループを抜けて終了へ進むか又はステップ３５０３へ進むかの判定処理は、収集状態変更規則テーブル３１０１に登録されているすべての変更規則（収集状態変更規則テーブル３１０１に含まれるすべての行）について、変更規則の条件を満たすか否かを判定して、どのステップへ進むかを決定する処理である。つまり、判定した結果、すべての行について、性能情報の収集状態を更新する処理が終わっている場合には終了へ進む（ステップ３５０２からＹＥＳへ進む）。また、判定した結果、変更規則についての条件判定と性能情報の収集状態の更新処理が済んでいない行がある場合には、ステップ３５０２からステップ３５０３へ進む。

ステップ３５０３では、まず、ステップ３５０１で取得した登録行の変更条件リソース格納欄３１０２と変更条件メトリック格納欄３１０３の値を調べる。そのリソースとメトリックが、リソース識別子格納欄２９０１とメトリック識別子格納欄２９０２の内容に一致する性能情報収集状態テーブル１２１の行を探し、見つかった行の最終収集日時格納欄２９０４の値を調べる。本手順を前回起動した日時から今回起動した日時までの期間内に、その最終収集日時が含まれるかどうかを判定する。もし含まれていれば、ステップ３５０４に進む。そうでなければ、ステップ３５０１に戻る。

ステップ３５０４では、まず、ステップ３５０１で取得した登録行の変更条件コード格納欄３１０５と、変更条件パラメータリスト格納欄３１０６、変更方向コード格納欄３１１１の値を調べる。その変更条件の成否の判定に必要なメトリック値をメトリック値テーブル１２７から取得し、ステップ３５０５に進む。

ステップ３５０５で、変更条件が成立と判定されれば、ステップ３５０６に進む。変更条件が不成立であり、かつ、変更方向が双方向であれば、ステップ３５０７に進む。変更条件が不成立、かつ、変更方向が片方向であれば、ステップ３５０１に戻る。

ステップ３５０６では、まず、ステップ３５０１で取得した登録行の変更対象リソース格納欄３１０７と変更対象拡張コード格納欄３１０８の値を調べる。リソース間関連情報記憶部１１５のリソース間関連テーブル（２６０１、２６０４、２７０１、２８０１、２７０４等）中の関連を辿ることによって、変更対象拡張コードによって指定される変更対象リソースを調べる。
そして、変更対象リソースのうちの、該当するリソース（３５０６で選択したリソース）の該当するメトリック（３５０１で取得した行の変更対象メトリック格納欄３１０９で指定されるメトリック）に対して、変更規則を適用する処理が、未処理のものを１つ取得し、ステップ３５０８に進む。

尚、上述の「該当するリソース（３５０６で選択したリソース）の該当するメトリック（３５０１で取得した行の変更対象メトリック格納欄３１０９で指定されるメトリック）に対して、変更規則を適用する処理処理」とは、以下に続くステップ３５０８、３５１０、３５１２〜３５２１の処理のことである。

ステップ３５０８で、変更対象リソースがすべて処理済みと判定されれば、ステップ３５０１に戻る。未処理のものがあれば、ステップ３５１０に進む。

ステップ３５１０では、ステップ３５０１で取得した登録行の変更対象メトリック格納欄３１０９の値を調べる。変更対象メトリックのうち未処理のものを１つ取得し、ステップ３５１２に進む。

ステップ３５１２で、変更対象メトリックがすべて処理済みと判定されれば、ステップ３５０６に戻る。未処理のものがあれば、ステップ３５１４に進む。

ステップ３５１４では、ステップ３５０１で取得した登録行の変更規則番号格納欄３１０４と、ステップ３５０６の未処理の変更対象リソース、ステップ３５１０の未処理の変更対象メトリックが、それぞれ変更規則番号格納欄３３０２と、リソース格納欄３３０３、メトリック格納欄３３０４の内容に一致する変更規則活性化状態テーブル３３０１の行を探し、該当行がなければ、ステップ３５１６に進む。該当行があれば、ステップ３５１０に戻る。

ステップ３５１６では、変更規則活性化状態テーブル３３０１に、ステップ３５０１で選んだ未処理の変更規則の番号と収集レベル、ステップ３５０６で選んだ未処理の変更対象リソース、ステップ３５１０で選んだ未処理の変更対象メトリックを登録し、ステップ３５１８に進む。

ステップ３５１８では、ステップ３５１６で新たに登録した収集レベルが、同じリソースとメトリックについて変更規則活性化状態テーブル３３０１に登録済みの収集レベルよりも高いかどうかを判定する。新たに登録した収集レベルの方が高ければ、ステップ３５１９に進む。そうでなければ、ステップ３５１０に戻る。

ステップ３５１９では、ステップ３５０６で選んだ変更対象リソースの情報を収集するエージェントの収集状態変更部１１６に対して、性能情報収集状態テーブル（１２０、９０１、１２０１、１５０１、１８０１、２１０１、２４０１）の該当リソースの該当メトリックの収集レベルを更新するよう要求し、ステップ３５２１に進む。

ステップ３５２１でも同様に、性能情報収集状態テーブル１２１の該当リソースの該当メトリックの収集レベルを更新し、ステップ３５１０に戻る。

ステップ３５０７では、まず、ステップ３５０１で取得した登録行の変更対象リソース格納欄３１０７と変更対象拡張コード格納欄３１０８の値を調べる。リソース間関連情報記憶部１１５のリソース間関連テーブル（２６０１、２６０４、２７０１、２８０１、２７０４等）中の関連を辿ることによって、変更対象拡張コードによって指定される変更対象リソースを調べる。変更対象リソースのうち未処理のものを１つ取得し、ステップ３５０９に進む。

ステップ３５０９では、変更対象リソースがすべて処理済みと判定されれば、ステップ３５０１に戻る。そうでなければ、ステップ３５１１に進む。

ステップ３５１１では、ステップ３５０１で取得した登録行の変更対象メトリック格納欄３１０９の値を調べる。変更対象メトリックのうち未処理のものを１つ取得し、ステップ３５１３に進む。

ステップ３５１３で、変更対象メトリックがすべて処理済みと判定されれば、ステップ３５０７に戻る。未処理のものがあれば、ステップ３５１５に進む。

ステップ３５１５では、ステップ３５０１で取得した登録行の変更規則番号格納欄３１０４と、ステップ３５０７の未処理の変更対象リソース、ステップ３５１１の未処理の変更対象メトリックが、それぞれ変更規則番号格納欄３３０２と、リソース格納欄３３０３、メトリック格納欄３３０４の内容に一致する変更規則活性化状態テーブル３３０１の行を探し、該当行があれば、ステップ３５１７に進む。該当行がなければ、ステップ３５１１に戻る。

ステップ３５１７では、ステップ３５０１で選んだ未処理の変更規則の番号と、ステップ３５０７で選んだ未処理の変更対象リソース、ステップ３５１１で選んだ未処理の変更対象メトリックが一致する変更規則活性化状態テーブル３３０１の行を削除し、ステップ３５２０に進む。

ステップ３５２０では、まず、ステップ３５０７で選んだ変更対象リソースと、ステップ３５１１で選んだ変更対象メトリックが一致する変更規則活性化状態テーブル３３０１の登録行の中で最も高い収集レベルを求める。その変更対象リソースの情報を収集するエージェントの収集状態変更部１１６に対して、性能情報収集状態テーブル（１２０、９０１、１２０１、１５０１、１８０１、２１０１、２４０１）の該当リソースの該当メトリックの収集レベルを、求めたレベルに更新するよう要求し、ステップ３５２２に進む。

ステップ３５２２でも同様に、性能情報収集状態テーブル１２１の該当リソースの該当メトリックの収集レベルを更新し、ステップ３５１１に戻る。

本実施例によれば、監視対象となっているストレージネットワーク構成要素から収集した性能情報をもとに、以後の情報収集の対象範囲もしくは程度を必要に応じて自動調整することが可能となる。より具体的には、以下のステップ２〜５もしくはステップ１〜５に従って性能情報を収集する。

（１）以下のステップ２〜４での方法を具体的に特定する指示（選択肢やパラメータ）をストレージネットワークの利用者から取得する。

（２）既に収集した性能情報をもとに収集方法を変更するタイミングを決める。そのタイミングは、以下のステップ２Ａ〜２Ｃに従って決める。ステップ１から始めた場合は、以下のステップ２Ａ〜２Ｃの中からステップ１で取得した指示に従って決める。
（２Ａ）特定の収集対象要素について得た特定の性能項目の値が過大もしくは過小となる（特定の基準を上回る、もしくは下回る）時点。
（２Ｂ）特定の収集対象要素について得た特定の性能項目の値が過大もしくは過小となる予兆が認められた（値の変化が特定の基準を上回る、もしくは下回る）時点。
（２Ｃ）特定の収集対象要素について得た特定の性能項目の値が過大もしくは過小である状態が解消した（特定の基準を下回る、もしくは上回る）時点、またはその予兆が解消した（値の変化が特定の基準を下回る、もしくは上回る）時点。

（３）前記タイミングにおいて性能情報の収集対象要素の中から収集方法を変更すべきものを選択する。その選択方法は、以下のステップ３Ａ〜３Ｄに従って決める。ステップ１から始めた場合は、以下のステップ３Ａ〜３Ｄの中からステップ１で取得した指示に従って決める。

（３Ａ）ステップ２でタイミング決定の契機となった収集対象要素を起点とし、収集対象要素間に成り立つ性能に関する依存関係を利用して、性能に関する負荷をかける上流側に該依存関係を辿った経路上の収集対象要素を選択する。

（３Ｂ）ステップ２でタイミング決定の契機となった収集対象要素を起点とし、収集対象要素間に成り立つ性能に関する依存関係を利用して、性能に関する負荷がかけられる下流側に該依存関係を辿った経路上の収集対象要素を選択する。

（３Ｃ）ステップ２でタイミング決定の契機となった収集対象要素を起点とし、収集対象要素間に成り立つ性能に関する依存関係を利用して、性能に関する負荷をかける上流側ならびに負荷がかけられる下流側に該依存関係を辿った経路上の収集対象要素を選択する。

（３Ｄ）ステップ２でタイミング決定の契機となった収集対象要素を起点とし、収集対象要素間に成り立つ性能に関する依存関係を利用して、性能に関する負荷をかける上流側と、負荷がかけられる下流側に該依存関係を辿った経路上の収集対象要素、ならびに、該経路上の該収集対象要素の各々を新たな起点として性能に関する前記依存関係を上流側と下流側に辿った経路上の収集対象要素を選択する。

（４）選択した前記収集対象要素に関する性能情報の収集方法の変更方法を決める。その変更方法は以下のいずれかに従う。その変更方法は、以下のステップ４Ａ〜４Ｄに従って決める。ステップ１から始めた場合は、以下のステップ４Ａ〜４Ｄの中からステップ１で取得した指示に従って決める。

（４Ａ）ステップ３で選んだ収集対象要素の特定の性能項目の値で従来未収集であったものを以後収集するよう変更する。

（４Ｂ）ステップ３で選んだ収集対象要素の特定の性能項目の値を収集する頻度を従来よりも高めるよう変更する。

（４Ｃ）ステップ３で選んだ収集対象要素の特定の性能項目の値を収集する頻度を従来よりも低めるよう変更する。

（４Ｄ）ステップ３で選んだ収集対象要素の特定の性能項目の値で従来収集していたものを以後収集しないよう変更する。

（５）決定した前記変更方法に従って性能情報の収集方法を変更する。
ステップ４Ａもしくは４Ｂで決定した方法に従ってステップ５で収集方法が変更されると、従来未収集であった性能項目の値が収集されるよう、もしくは、低い頻度で収集されていたものがより高い頻度で収集されるように自動的に切り替わる。このため、必要があるまで性能情報の収集を遅らせたり頻度を低くすることによって、性能情報の収集量を抑えることができる。

ステップ２Ｂで決定したタイミングでステップ５の収集方法が変更されると、監視の対象である性能情報の時間変化の予兆が捉えられるため、ステップ２Ａのタイミングを使う場合に比べ、情報取得のタイミングを逃がす可能性を減らすことができる。

ステップ３Ａで選択した収集対象要素についてステップ４Ａもしくは４Ｂの方法で収集方法が変更されると、性能情報に注目すべき変化のあった要素に負荷をかける上流側の収集対象要素が新たに監視対象に加えられたり、より高い頻度で監視されるようになるので、その変化の原因を追跡調査するのに有効な情報を得ることができる。

ステップ３Ｂで選択した収集対象要素についてステップ４Ａもしくは４Ｂの方法で収集方法が変更されると、性能情報に注目すべき変化のあった要素が負荷をかける下流側の収集対象要素が新たに監視対象に加えられたり、より高い頻度で監視されるようになるので、その変化が及ぼす影響を追跡調査するのに有効な情報を得ることができる。

ステップ３Ｃや３Ｄで選択した収集対象要素についてステップ４Ａもしくは４Ｂの方法で収集方法が変更されると、性能情報に注目すべき変化のあった要素に負荷をかける上流側ならびに負荷がかけられる下流側の収集対象要素や、さらにその上流から下流に沿った経路上のいずれかの要素で接点をもつ他の経路上の要素までが新たに詳しく監視されるようになるので、とくに要素間の性能上の依存関係が複雑な場合に上記変化の原因や影響を追跡調査するのに有効な情報を得ることができる。

ステップ２Ｃで決定したタイミングにステップ４Ｃもしくは４Ｄの方法で収集方法が変更されると、注目すべき状態が解消した要素に関する性能情報の収集頻度を下げるよう、もしくは、収集を止めるように自動的に切り替わるので、必要でない性能情報の収集量を抑えることができる。

ステップ１で取得した指示（選択肢やパラメータ）に従ってステップ２〜４での方法が具体的に決定されるようにした場合は、ストレージネットワーク利用者の必要に合わせて情報収集の自動化をカスタマイズすることが可能になる。

本実施例によれば、ストレージネットワークの性能監視やチューニングに必要な情報のうち、重要な情報はタイミングを逃がさず収集し、不要な情報は収集を抑制することが可能になる。これにより、従来と同程度の処理能力の装置を使ってより大規模なストレージネットワークの性能監視を自動化できる効果がある。また、情報取得の際に監視対象装置等にかかるオーバーヘッドを軽減する効果がある。

本発明の一実施例のブロック図である。 本発明の一実施例のシステム構成図である。 リソースならびにリソース間の性能に関する依存関係の具体例を示す図である。 表形式による性能情報の表示画面の一例を示す図である。 グラフ形式による性能情報の表示画面の一例を示す図である。 性能情報収集状態のデフォルト設定画面の一例を示す図である。 性能情報収集状態の変更規則設定画面の一例を示す図である。 サーバＡのＤＢ性能情報収集エージェントが使用するリソース間関連情報記憶部のテーブル構成ならびにテーブル構造の一例を示す図である。 サーバＡのＤＢ性能情報収集エージェントが使用する性能情報収集状態テーブルの構造の一例を示す図である。 サーバＡのＤＢ性能情報収集エージェントが使用するメトリック値テーブルの構造の一例を示す図である。 サーバＡのホスト性能情報収集エージェントが使用するリソース間関連情報記憶部のテーブル構成ならびにテーブル構造の一例を示す図である。 サーバＡのホスト性能情報収集エージェントが使用する性能情報収集状態テーブルの構造の一例を示す図である。 サーバＡのホスト性能情報収集エージェントが使用するメトリック値テーブルの構造の一例を示す図である。 サーバＢのＤＢ性能情報収集エージェントが使用するリソース間関連情報記憶部のテーブル構成ならびにテーブル構造の一例を示す図である。 サーバＢのＤＢ性能情報収集エージェントが使用する性能情報収集状態テーブルの構造の一例を示す図である。 サーバＢのＤＢ性能情報収集エージェントが使用するメトリック値テーブルの構造の一例を示す図である。 サーバＢのホスト性能情報収集エージェントが使用するリソース間関連情報記憶部のテーブル構成ならびにテーブル構造の一例を示す図である。 サーバＢのホスト性能情報収集エージェントが使用する性能情報収集状態テーブルの構造の一例を示す図である。 サーバＢのホスト性能情報収集エージェントが使用するメトリック値テーブルの構造の一例を示す図である。 ＳＡＮスイッチ性能情報収集エージェントが使用するリソース間関連情報記憶部のテーブル構成ならびにテーブル構造の一例を示す図である。 ＳＡＮスイッチ性能情報収集エージェントが使用する性能情報収集状態テーブルの構造の一例を示す図である。 ＳＡＮスイッチ性能情報収集エージェントが使用するメトリック値テーブルの構造の一例を示す図である。 サブシステム性能情報収集エージェントが使用するリソース間関連情報記憶部のテーブル構成ならびにテーブル構造の一例を示す図である。 サブシステム性能情報収集エージェントが使用する性能情報収集状態テーブルの構造の一例を示す図である。 サブシステム性能情報収集エージェントが使用するメトリック値テーブルの構造の一例を示す図である。 ストレージネットワーク性能管理ソフトが使用するリソース間関連情報記憶部のテーブル構成ならびにテーブル構造の一例を示す図の第１部分である。 ストレージネットワーク性能管理ソフトが使用するリソース間関連情報記憶部のテーブル構成ならびにテーブル構造の一例を示す図の第２部分である。 ストレージネットワーク性能管理ソフトが使用するリソース間関連情報記憶部のテーブル構成ならびにテーブル構造の一例を示す図の第３部分である。 ストレージネットワーク性能管理ソフトが使用する性能情報収集状態テーブルの構造の一例を示す図である。 ストレージネットワーク性能管理ソフトが使用するメトリック値テーブルの構造の一例を示す図である。 収集状態変更規則テーブルの構造の一例を示す図である。 性能情報収集状態デフォルト設定テーブルの構造の一例を示す図である。 変更規則活性化状態テーブルの構造の一例を示す図である。 性能情報収集エージェントならびにストレージネットワーク性能管理ソフトの性能情報収集処理の手順を示すフローチャートである。 ストレージネットワーク性能管理ソフトの収集状態変更処理の手順を示すフローチャートである。

符号の説明

１０１〜１０５…ストレージネットワーク構成装置・ソフト、１０６〜１０８…性能情報収集エージェント、１０９…ストレージネットワーク性能管理ソフト、１１０…構成情報取得部、１１１…構成情報収集部、１１２…リソース間関連情報記憶部、１１３…構成情報応答部、１１４…構成情報収集部、１１５…リソース間関連情報記憶部、１１６…収集状態変更部、１１７…収集状態変更部、１１８…収集状態変更情報記憶部、１１９…変更規則設定部、１２０…性能情報収集状態テーブル、１２１…ストレージネットワーク性能管理ソフトの性能情報収集状態テーブル、１２２…性能情報取得部、１２３…性能情報収集部、１２４…メトリック値テーブル、１２５…性能情報応答部、１２６…性能情報収集部、１２７…ストレージネットワーク性能管理ソフトのメトリック値テーブル、１２８…性能分析表示部、１２９…性能管理クライアント、２０１〜２０４…業務クライアント、２０５…ＬＡＮ、２０６…性能情報収集サーバ、２０７…ＮＡＳ性能情報収集エージェント、２０８…ＮＡＳ、２０９〜２１１…ホストサーバ、２１２…業務ソフト、２１３…業務ソフト性能情報収集エージェント、２１４…ＤＢ管理ソフト、２１５…ＤＢ性能情報収集エージェント、２１６…ＯＳ、２１７…ホスト性能情報収集エージェント、２１８〜２２０…ホストバスアダプタのポート、２２１〜２２４…ＳＡＮスイッチのポート、２２５〜２２７…ＳＡＮスイッチ、２２８〜２３０…ＳＡＮスイッチのポート、２３１〜２３３…ストレージサブシステムのポート、２３４…ストレージサブシステム、２３５…性能情報収集サーバ、２３６…ＳＡＮスイッチ性能情報収集エージェント、２３７…性能情報収集サーバ、２３８…サブシステム性能情報収集エージェント、２３９…ホストバスアダプタのポート、２４０…性能管理サーバ

Claims (2)

1. １つまたは複数の計算機装置と１つまたは複数の外部記憶装置と該計算機装置が該外部記憶装置との間で入出力データを通信するための１つまたは複数のネットワーク装置を含むストレージネットワークシステムにおける該計算機装置又は該外部記憶装置又は該ネットワーク装置に関する性能情報ならびに該計算機装置又は該外部記憶装置又は該ネットワーク装置で稼動するソフトウェアに関する性能情報を、前記ストレージネットワークシステムに接続された管理サーバが収集する方法であって、
   前記ストレージシステムの構成要素であって、監視対象であるそれぞれの構成要素から前記要素間の関連情報を収集するステップと、
   予め収集した性能情報に基づいて、特定の収集対象要素について得た特定の性能項目の値が、予め定められた基準値を上回る又は下回る場合又は前記性能項目の値の変化が予め定められた基準を上回る又は下回る場合は、前記必要性ありと判断することによって、性能情報を収集する時間間隔又は性能情報の収集の要否を変更する必要性を判断するステップと、
   前記必要性を判断するステップにより性能情報を収集する時間間隔又は性能情報の収集の要否を変更する必要が判定された性能情報を収集する対象要素に対しＩ／Ｏ命令を送信もしくは前記対象要素からＩ／Ｏ命令を受信する対象要素を、前記収集した要素間の関連情報に基づいて、性能情報を収集する時間間隔又は性能情報の収集要否を変更すべき対象要素として選択するステップと、
   選択した前記対象要素に関する性能情報を収集する時間間隔又は性能情報の収集の要否を決定するステップと、
   決定した前記性能情報を収集する時間間隔又は性能情報の収集の要否を変更し、前記必要性の判断に従って性能情報の収集頻度を変更するステップを有し、
   前記対象要素を選択するステップは、前記必要性を判断するステップで前記必要性ありと判断した収集対象要素を起点とし、収集対象要素間に成り立つＩ／Ｏ命令の送信および受信の関係を利用して、性能に関する負荷をかける上流側ならびに負荷がかけられる下流側に前記Ｉ／Ｏ命令の送信および受信の関係を辿った経路上の収集対象要素、ならびに、前記経路上の前記収集対象要素の各々を新たな起点として性能に関する前記Ｉ／Ｏ命令の送信および受信の関係を上下流側に辿った経路上の収集対象要素を選択することを特徴とする性能情報を収集する方法。
2. １つまたは複数の計算機装置と、１つまたは複数の外部記憶装置と、該計算機装置が該外部記憶装置との間で入出力データを通信するための１つまたは複数のネットワーク装置を含むストレージネットワークシステムにおける、該計算機装置又は該外部記憶装置又は該ネットワーク装置に関する性能情報ならびに該計算機装置又は該外部記憶装置又は該ネットワーク装置で稼動するソフトウェアに関する性能情報を、前記ストレージネットワークシステムに接続された管理サーバが収集する方法であって、
   前記ストレージシステムの構成要素であって、監視対象であるそれぞれの構成要素から前記要素間の関連情報を収集するステップと、
   予め収集した性能情報と、ユーザからの指示に基づいて、特定の収集対象要素について得た特定の性能項目の値が、予め定められた基準値を上回る又は下回る場合又は前記性能項目の値の変化が予め定められた基準を上回る又は下回る場合は、前記必要性ありと判断することによって、性能情報を収集する時間間隔又は性能情報の収集の要否を変更する必要性を判断するステップと、
   前記収集した要素間の関連情報に基づいて、性能情報を収集する対象要素を、性能情報を収集する時間間隔又は性能情報の収集要否を変更すべき対象要素を選択する際に、予め格納された対象要素間のＩ／Ｏ命令の送信および受信の関係を定義した情報とユーザから指定された性能情報収集対象の範囲に関する情報に基づいて対象要素として選択するステップと、
   選択した前記対象要素に関する性能情報を収集する時間間隔又は性能情報の収集の要否を決定するステップと、
   決定した前記性能情報を収集する時間間隔又は性能情報の収集の要否を変更し、前記必要性の判断に従って性能情報を収集する対象要素と性能情報報を収集する頻度とを変更するステップを有し、
   前記対象要素を選択するステップは、前記必要性を判断するステップで前記必要性ありと判断した収集対象要素を起点とし、収集対象要素間に成り立つＩ／Ｏ命令の送信および受信の関係を利用して、性能に関する負荷をかける上流側ならびに負荷がかけられる下流側に前記Ｉ／Ｏ命令の送信および受信の関係を辿った経路上の収集対象要素、ならびに、前記経路上の前記収集対象要素の各々を新たな起点として性能に関する前記Ｉ／Ｏ命令の送信および受信の関係を上下流側に辿った経路上の収集対象要素を選択することを特徴とする性能情報を収集する方法。

Images