JP2008276279A - 装置性能管理方法、装置性能管理システム、および管理プログラム - Google Patents

Abstract

【課題】将来アプリケーションに性能問題を引き起こす可能性が高い装置を検出することができる装置性能管理方法を提供する。
【解決手段】装置、該装置を抽象化した論理的存在である論理ユニット、およびアプリケーションの構成情報、ならびに、装置、論理ユニット、およびアプリケーションの間に成り立つ性能の依存関係の構成情報を収集する構成情報収集処理Ｓ２３３と、装置、論理ユニット、およびアプリケーションの性能情報を収集する性能情報収集処理Ｓ２３１と、装置の性能情報と、装置と性能の依存関係がある論理ユニットの性能情報の時間変化値に対して所定期間について相関分析し、相関分析により得られた相関係数が所定の閾値以上のとき、装置が飽和兆候ありと検出する飽和兆候検出処理Ｓ２３６と、飽和兆候ありとされた装置の飽和兆候関連情報を、性能を管理する管理クライアントに告知する飽和兆候情報出力処理Ｓ２３８とを含んで実行する。
【選択図】図２

Description

本発明は、将来アプリケーションに性能問題を引き起こす可能性が高い装置、または、現在アプリケーションに性能問題を引き起こしている可能性が高い装置を検出することができる装置性能管理方法、装置性能管理システム、および管理プログラムに関する。

将来アプリケーションに性能問題を引き起こす可能性が高い装置、または現在アプリケーションに性能問題を引き起こしている可能性が高い装置を検出することを、以下、性能飽和兆候の検出という。

従来、コンピュータシステムの性能管理方法として、以下の２種類の方法が行われてきた。性能管理方法１は、あるアプリケーションにおいて性能問題が起こった場合に、当該アプリケーションの実行に関わる装置群の性能を調査し、アプリケーションの性能問題を引き起こした装置を特定する、性能ボトルネックを分析するリアクティブな方法である。

性能管理方法２は、アプリケーションの性能問題が起きる前に、性能問題が起きる可能性があることを検出するための、アプリケーションの性能飽和兆候の検出をするプロアクティブな方法である。

前記性能管理方法１および性能管理方法２は、いずれも、性能管理対象の装置が膨大に存在する場合、コンピュータプログラムなどによる支援がなければ、装置管理者に大きな負担になる。そこで、それぞれの支援方法が行われてきている。

前記性能管理方法１の支援方法Ａは、性能問題が起きたアプリケーションの性能情報と、当該アプリケーションと性能の依存関係がある装置群の各々との間で性能情報との相関を調べ、当該装置群の中からボトルネックとして確からしい装置を推定する。

前記性能管理方法２の支援方法Ｂは、アプリケーションまたは装置の性能情報に対して閾値情報を設定しておき、定期的に観測した性能情報と当該閾値情報を比較し、ルールに基づいてアラート（警告あるいは告知）をあげて支援する（例えば、特許文献１参照）。
特開２００１−１９５２８５号公報

前記支援方法Ａは、性能問題が起きたアプリケーションがわかっている場合に、当該アプリケーションと性能の依存関係がある装置群の中から、当該性能問題の原因として確からしい装置を推定するための支援方法であり、アプリケーションに性能問題が起きたことが未発覚の場合には使えない。

また、前記支援方法Ｂによる閾値を用いた支援方法では、そもそも適切な閾値を決定することが困難という理由がある。具体的には、装置の性能情報として、装置の使用率、スループット、レスポンスタイムなどがあるが、装置の管理者にとって、これらの値がどの程度まで達した場合に装置が飽和兆候を示すかを詳しく知ることは困難である。

前記性能管理方法２は、コンピュータシステムの性能増強プラン検討やリソース配置の最適化などを、アプリケーションの性能問題が起きる前に行うためことを目的とするが、アプリケーションの性能問題が起きる前のプロアクティブなアプリケーションの性能飽和兆候の検出に関して十分に出来ていない問題がある。

本発明は、前記の課題を解決するための発明であって、将来アプリケーションに性能問題を引き起こす可能性が高い装置、または、現在アプリケーションに性能問題を引き起こしている可能性が高い装置を検出することができる装置性能管理方法、装置性能管理システム、および管理プログラムを提供することを目的とする。

本発明による装置性能管理方法は、１つ以上の装置および該装置と性能の依存関係がある１つ以上のアプリケーションを備えるシステムにおける装置性能を管理する管理サーバ（例えば、性能管理サーバ１５１）が、装置の構成情報およびアプリケーションの構成情報、ならびに、装置およびアプリケーションの間に成り立つ性能の依存関係の構成情報を収集する構成情報収集処理（例えば、構成情報収集処理Ｓ２３３）と、装置の性能情報およびアプリケーションの性能情報を収集する性能情報収集処理（例えば、性能情報収集処理Ｓ２３１）と、構成情報と性能情報とに基づいて装置の飽和兆候を検出する飽和兆候検出処理（例えば、飽和兆候検出処理Ｓ２３６）と、を含んで実行することを特徴とする。

本発明による装置性能管理方法は、１つ以上の装置および該装置と性能の依存関係がある１つ以上のアプリケーションを備えるシステムにおける装置性能を管理する管理サーバが、装置の構成情報、該装置を抽象化した論理的存在である論理ユニットの構成情報、およびアプリケーションの構成情報、ならびに、装置、論理ユニット、およびアプリケーションの間に成り立つ性能の依存関係の構成情報を収集する構成情報収集処理と、装置の性能情報、論理ユニットの性能情報、およびアプリケーションの性能情報を収集する性能情報収集処理と、構成情報と性能情報とに基づいて装置の飽和兆候を検出する飽和兆候検出処理と、を含んで実行することを特徴とする。

飽和兆候検出処理は、装置の性能情報と、アプリケーションの性能情報の時間変化値に対して所定期間について相関分析し、相関分析により得られた相関係数が所定の閾値以上のとき、装置が飽和兆候ありと検出することが好ましい。

また、飽和兆候検出処理は、装置の性能情報と、装置と性能の依存関係がある論理ユニットの性能情報の時間変化値に対して所定期間について相関分析し、相関分析により得られた相関係数が所定の閾値以上のとき、装置が飽和兆候ありと検出することが好ましい。

本発明によれば、将来アプリケーションに性能問題を引き起こす可能性が高い装置、または、現在アプリケーションに性能問題を引き起こしている可能性が高い装置を検出することができる。

以下、本発明の実施形態について図面を参照して詳細に説明する。

初めに本発明の概要を説明する。本発明の装置性能管理方法では、飽和兆候検出対象とする装置の使用率の時系列な測定値と、当該装置と性能の依存関係がある１つまたは複数のアプリケーションが当該装置から受けるサービスレベルの時系列な測定値、の２つを入力とし、両者の時間変化に伴う変化値列同士の相関係数を計算する。当該相関係数を装置の飽和度とみなし、相関係数が閾値を超えた場合に、当該装置は、アプリケーションに性能問題を引き起こす兆候がある、またはアプリケーションに性能問題を引き起こしているとみなす。

装置の使用率が上昇し、装置毎に特有な値まで達した後に、当該装置を利用するアプリケーションのサービスレベルは急激に劣化する。この時、装置の使用率の変化値とアプリケーションが当該装置から受けるサービスレベルの変化値の間には高い相関がある。本発明では、前記使用率の変化値とサービスレベルの変化値の間にある相関関係を利用して、装置の飽和兆候を検出する。本発明の装置性能管理方法では、装置の使用率に対する閾値を設定するのではなく、相関係数に対する閾値を用いる。

より具体的には、以下のステップＳ１〜ステップＳ５に従い、装置の飽和兆候検出を行う。検出した装置の性能飽和兆候を、画面やログなどにより、表示または出力してもよい。いくつかのステップには、後で詳しく説明するように、バリエーションが考えられる。

ステップＳ１： 定期的もしくは要求に応じて、性能管理ソフトウェアが監視する対象の系から、装置、装置を抽象化した論理的存在、アプリケーション、の一覧を検出し、構成情報の一部として保存する。

ステップＳ２： 定期的もしくは要求に応じて、装置、装置を抽象化した論理的存在、アプリケーションの間に成り立つ性能の依存関係を検出し、構成情報の残りとして保存する。性能の依存関係とは、アプリケーションが発行するＩ／Ｏ命令を処理する一連の装置およびソフトウェアがある場合に、それらの間の関係を意味する。

ステップＳ３： 定期的もしくは要求に応じて、装置、装置を抽象化した論理的存在、アプリケーションから性能情報を収集し保存する。

ステップＳ４： 前記ステップＳ１で検出した装置一覧の中から、飽和兆候を検出したい装置群を決定する。

ステップＳ５： 前記ステップＳ４で、飽和兆候検出の対象と決定した装置群の各々について、当該装置と性能の依存関係があるアプリケーション群を、前記ステップＳ２で検出・保存した構成情報を用いて絞込み、当該装置と当該アプリケーション群との間で、性能情報の時間変化の相関係数を、前記ステップＳ３で保存した性能情報を用いて計算する。相関係数が閾値を超えた装置があれば、当該装置は飽和兆候を示したと判定する。アプリケーションの性能情報の代替として、当該装置と性能の依存関係がある装置を抽象化した論理的存在の性能情報を用いてもよい。この場合、当該論理的存在は、装置をアプリケーションが使用する際のインタフェースであり、装置の使用者とみなすことができる。

《実施形態１》
図１は、本発明の全体構成を示すブロック図である。ホスト、ストレージ装置およびその間のストレージエリアネットワークを基盤にした業務システムを構成するハードウェアには、業務クライアント１０１〜１０３、ローカルエリアネットワーク（ＬＡＮ）１０４、ホストサーバ１１１，１１２、ストレージエリアネットワーク（ＳＡＮ）のＳＡＮスイッチ１２１，１２２、ストレージサブシステム１３１，１３２があり、同じくソフトウェアには、アプリケーション１１５や、オペレーティングシステム（ＯＳ）１１３、ファイルシステム１１４がある。

業務クライアント１０１〜１０３は、業務システムのユーザインタフェース機能を提供するパソコンや、ワークステーション、シンクライアント端末などの装置であり、ＬＡＮ１０４を経由してホストサーバ１１１や１１２にて稼動するアプリケーション１１５などと通信する。

アプリケーション１１５は、業務システムの業務論理機能を提供するソフトウェアであり、業務クライアント１０１〜１０３からの処理要求に応答し、必要に応じてファイルシステム１１４に対しデータの参照・更新を要求する。

ファイルシステム１１４は、データの管理処理を提供するソフトウェアであり、アプリケーション１１５からの要求に応答し、ＯＳ１１３を介してストレージサブシステム１３１と１３２に格納されたデータの操作・管理に関する処理を行う。アプリケーション１１５、ファイルシステム１１４、ＯＳ１１３の実行には、ホストサーバ内のＣＰＵ（Central Processing Unit）１１６、メモリ１１７が必要である。

ファイルシステム１１４からストレージサブシステム１３１，１３２にあるデータへのアクセスは、ＯＳ１１３、ホストバスアダプタ１１８，１１９、ＳＡＮスイッチのホスト側ポート１２３，１２４、ＳＡＮスイッチ１２１，１２２、ＳＡＮスイッチのストレージ側ポート１２５と１２６、ストレージサブシステムのポート１３３，１３４を経由して行なわれる。

ホストサーバ、ストレージエリアネットワーク、ストレージサブシステムおよびアプリケーションの性能管理のためのシステムを構成するハードウェアには、情報収集サーバ１４１、性能管理サーバ１５１、性能管理クライアント１６１があり、同じくソフトウェアには、アプリケーション監視エージェント１７１、ホスト監視エージェント１７２、ファブリック監視エージェント１７３、ストレージサブシステム監視エージェント１７４、装置性能管理ソフト１８１がある。なお、装置性能管理ソフトとは、装置性能管理ソフトウェアの略である。

性能管理クライアント１６１は、装置性能管理ソフト１８１のユーザインタフェース機能を提供する装置であり、ＬＡＮ１０４を経由して性能管理サーバ１５１の装置性能管理ソフト１８１と通信する。

装置性能管理ソフト１８１は、装置の性能情報の収集と分析に関する処理を提供するソフトウェアであり、ネットワークを構成するさまざまなハードウェアやソフトウェアから性能情報を取得する。

以下では、装置性能管理ソフト１８１がハードウェアやソフトウェアの性能情報取得のため、それぞれ専用の監視エージェントソフトウェアを利用する方法を説明する。エージェントの構成や配置にはいろいろな方法があり得るが、本実施形態の形態でもって本発明の実施方法を制限するものではない。また、エージェントを介さず、装置性能管理ソフト１８１が直接、監視対象の装置やソフトウェアと通信する形態もありうるが、このような形態にも本発明は適用可能である。

装置性能管理ソフト１８１のソフトウェアの場合は、性能管理サーバ１５１のＣＰＵが、それぞれの監視エージェントのソフトウェアの場合は、情報収集サーバ１４１およびホストサーバ１１１，１１２のＣＰＵが、それぞれ実行することで実現する。

アプリケーション監視エージェント１７１は、アプリケーション１１５に関する構成情報と性能劣化を検出するためのものである。ホスト監視エージェント１７２は、ホストサーバ１１１、ファイルシステム１１４、ＯＳ１１３、ＣＰＵ１１６、メモリ１１７、ホストバスアダプタのポート１１８，１１９に関する構成情報と性能情報を取得する。ストレージサブシステム監視エージェント１７４は、ホストバスアダプタのポート１４２、ＳＡＮスイッチのポート１２７、ＳＡＮスイッチ１２１，１２２を経由して、ストレージサブシステム１３１と１３２に関する構成情報と性能情報を取得する。当該情報の中には、ポート１３３と１３４に関する情報が含まれる。

ファブリック監視エージェント１７３は、ホストバスアダプタのポート１４２、ＳＡＮスイッチのポート１２７を経由して、ＳＡＮスイッチ１２１，１２２が構成するファブリックの構成情報と性能情報を取得する。当該情報には、ポート１２３〜１２６に関する情報が含まれる。

本実施形態では、ストレージサブシステム監視エージェント１７４は、ストレージエリアネットワーク経由で装置の情報を取得しているが、ストレージサブシステム１３１，１３２のいずれかがＬＡＮ１０４に接続されている場合、ＬＡＮ１０４経由で当該ストレージサブシステムの情報を取得してもよい。同様に、ファブリック監視エージェント１７３も、監視対象のストレージサブシステム１３１，１３２から情報を取得するために、ＬＡＮ１０４を経由して通信してもよい。

また、本実施形態では、ファブリック監視エージェント１７３とストレージサブシステム監視エージェント１７４は、専用の情報収集サーバ１４１上で稼動しているが、どの計算機上で稼働してもよい。アプリケーション監視エージェント１７１およびホスト監視エージェント１７２についても同様で、本実施形態では、ホストサーバ１１１上で稼働しているが、他の計算機上で稼働し、通信を用いてアプリケーションの性能情報を取得してもよい。

図２は、本発明の各処理および各情報を示すブロック図である。図２に示すように、各処理および各情報を備えるハードウェア・ソフトウェアには、装置２０１〜２０３、アプリケーション２１１〜２１３、監視エージェント２２１〜２２３、装置性能管理ソフト１８１、性能管理クライアント１６１がある。

装置２０１〜２０３は、装置群が構成するネットワーク内で性能監視の対象となるハードウェアであり、図１に記載の例では、ホストサーバ１１１，１１２、ストレージサブシステム１３１，１３２、ＳＡＮスイッチ１２１，１２２のうちのいずれかに該当する。

アプリケーション２１１〜２１３は、性能管理対象の装置を利用するソフトウェアであり、図１の例では、アプリケーション１１５に当たる。

監視エージェント２２１〜２２３は、ネットワークを構成する装置２０１〜２０３、または、当該装置を利用して処理を行うアプリケーション２１１〜２１３から性能情報と構成情報を取得するソフトウェアであり、図１の例では、アプリケーション監視エージェント１７１、ホスト監視エージェント１７２、ファブリック監視エージェント１７３、ストレージサブシステム監視エージェント１７４のうちのいずれかに該当する。

装置２０１〜２０３上のソフトウェアは、性能情報取得処理Ｓ２０４と、構成情報取得処理Ｓ２０５とを備える。アプリケーション２１１〜２１３の各々は、構成情報取得処理Ｓ２１５を備え、ログ２１４にアプリケーションの性能を出力する。装置上のソフトウェアまたはアプリケーションを監視する監視エージェントは、性能情報収集処理Ｓ２２４、性能情報２２５、性能情報応答処理Ｓ２２６、構成情報収集処理Ｓ２２７、構成情報２２８、構成情報応答処理Ｓ２２９を備える。

装置性能管理ソフト１８１は、性能情報収集処理Ｓ２３１、性能情報２３２、構成情報収集処理Ｓ２３３、構成情報２３４、飽和兆候検出対象装置設定処理Ｓ２３５、飽和兆候検出処理Ｓ２３６、飽和兆候情報２３７、飽和兆候情報出力処理Ｓ２３８を備える。

ネットワークを構成する装置の中には、当該装置を構成するさらに小さな単位の装置が存在する。また、装置を抽象化する論理的存在が生成されることがある。以下では、装置を抽象化する論理的存在のことを論理ユニットという。装置、論理ユニット、装置上で稼動するアプリケーションの間には、性能の依存関係が成り立つ。

監視エージェント２２１〜２２３および装置性能管理ソフト１８１から構成されるシステムが、装置、論理ユニット、アプリケーションの性能情報と構成情報を収集し、装置の飽和兆候を検出する処理を、図３５〜図３８を用いて概説する。

図３５は、構成情報および性能情報を取得、保存する監視エージェントの処理を示すフローチャートである。監視エージェント２２１〜２２３は、構成情報の収集を行う。具体的には、構成情報収集処理Ｓ２２７が、装置、論理ユニット、アプリケーションの構成情報を収集し、構成情報２２８に保存し（ステップＳ３５０１）、次のステップに進む。監視エージェント２２１〜２２３は、性能情報の収集を行う。具体的には、性能情報収集処理Ｓ２２４が、装置、論理ユニット、アプリケーションの性能情報を収集し、性能情報２２５に保存し（ステップＳ３５０２）、所定の時刻までスリープ（ステップＳ３５０３）する。このサイクルを繰り返すことで、定期的に情報を収集することができる。

図３６は、監視エージェントの構成情報収集処理の詳細を示すフローチャートである。監視エージェント２２１〜２２３の構成情報収集処理Ｓ２２７（ステップＳ３５０１）は、まず、装置の構成情報取得処理Ｓ２０５またはアプリケーションの構成情報取得処理２１５に問い合わせ、装置または論理ユニットまたはアプリケーションの一覧情報を取得し（ステップＳ３６０１）、取得した一覧情報を、構成情報２２８内に保存する（ステップＳ３６０２）。次に、監視エージェント２２１〜２２３の構成情報収集処理Ｓ２２７は、装置の構成情報取得処理Ｓ２０５またはアプリケーションの構成情報取得処理Ｓ２１５に問い合わせ、装置、論理ユニット、アプリケーション間に成り立つ性能の依存関係情報を取得し（ステップＳ３６０３）、取得した性能の依存関係情報を、構成情報２２８内に保存する（ステップＳ３６０４）。

図３７は、監視エージェントの性能情報収集処理の詳細を示すフローチャートの例である。監視エージェント２２１〜２２３の性能情報収集処理Ｓ２２４（ステップＳ３５０２）は、まず、装置の性能情報取得処理２０４に問い合わせるか、または、アプリケーションのログ２１４を通信で取得し、解析することで、装置、論理ユニット、アプリケーションの各々の時系列な性能情報を取得する（ステップＳ３７０１）。次に、取得した性能情報を、監視エージェントの性能情報２２５に保存する（ステップＳ３７０２）。

構成情報のうち、装置、論理ユニット、アプリケーション間の性能の依存関係情報については、監視エージェントが保持する内容を後記する。装置、論理ユニット、アプリケーションの一覧情報、および、各装置、論理ユニット、アプリケーションの性能情報については、装置性能管理ソフト１８１が監視エージェントから収集した結果の情報を後記する。

図３８は、装置性能管理ソフトの飽和兆候検出処理の主処理を示すフローチャートである。図３８において、装置性能管理ソフト１８１が、監視エージェント２２１〜２２３が保存した構成情報と性能情報を利用して、装置の飽和兆候を検出するまでの主処理を示す。監視エージェント２２１〜２２３から構成情報を取得した後に装置性能管理ソフト１８１が備える記憶領域に保存する（ステップＳ３８０１，Ｓ３８０２）。具体的には、装置性能管理ソフト１８１の構成情報収集処理Ｓ２３３は、監視エージェントの構成情報応答処理Ｓ２２９に対し各監視エージェントが収集した構成情報の送信を要求し、要求した情報が監視エージェントの構成情報２２８から検索されて返信されると、装置性能管理ソフト１８１が備える構成情報２３４に、装置、論理ユニット、アプリ−ケーションの一覧情報を格納する（ステップＳ３８０１）。同様に、装置、論理ユニット、アプリ−ケーション間に成り立つ性能の依存関係情報を格納する（ステップＳ３８０２）。

次に、監視エージェント２２１〜２２３から性能情報を取得し、装置性能管理ソフト１８１が備える記憶領域に保存する（ステップＳ３８０３）。具体的には、装置性能管理ソフト１８１の性能情報収集処理Ｓ２３１は、監視エージェントの性能情報応答処理Ｓ２２６に対し各監視エージェントが収集した性能情報の送信を要求し、要求した情報が監視エージェントの性能情報２２５から検索されて返信されると、装置性能管理ソフト１８１が備える性能情報２３２に、装置、論理ユニット、アプリ−ケーションの各々の時系列の性能情報を格納する。装置性能管理ソフト１８１の飽和兆候検出処理Ｓ２３６は、構成情報２３４に保存した装置一覧情報を検索し、全装置の中から、飽和調和検出を行う対象である装置群を選択する（ステップＳ３８０４）。装置を飽和兆候検出の対象として設定する処理は、後述する飽和兆候検出対象装置設定処理Ｓ２３５である。ステップＳ３８０４にて飽和調和検出を行う対象として選択した装置について、性能情報２３２に基づいて飽和兆候の有無を検出し、検出した飽和兆候情報を飽和兆候情報２３７に保存する（ステップＳ３８０５）。そして、所定の時刻までスリープする（ステップＳ３８０６）。ステップＳ３８０１〜ステップＳ３８０６のサイクルを繰り返すことで、定期的に装置の飽和兆候を検出することができる。

前記した装置性能管理ソフト１８１のフローチャートでは、定期的な処理を行う場合について説明したが、装置性能管理ソフト１８１を用いる装置管理者から入力を受けることで、当該処理を実行してもよい。

図３８のフローチャートには記載しなかった装置性能管理ソフト１８１の処理に、飽和兆候検出対象装置設定処理Ｓ２３５と、飽和兆候情報出力処理Ｓ２３８がある。飽和兆候検出対象装置設定処理Ｓ２３５は、構成情報２３４に格納した装置一覧情報を更新し、飽和兆候検出対象とする装置にフラグを設定する処理である。

また、飽和兆候情報出力処理Ｓ２３８は、前記飽和兆候検出処理Ｓ２３６の演算結果を、性能管理クライアント１６１経由で管理者へ通知するために出力する処理である。飽和兆候検出対象装置設定処理Ｓ２３５と、飽和兆候情報出力処理Ｓ２３８は、装置性能管理ソフト１８１を用いる装置管理者から入力を受けることで実行されてよい。

図３は、装置・論理ユニット・装置上で稼動するアプリケーション間に成り立つ性能の依存関係の例を示す説明図である。ここでは、各構成品の符号をかっこ書きとして、各構成品の名称と符号を明確にしている。図３に示すネットワークの構成例では、ハードウェアとして、ホストサーバＡ（３０１）とホストサーバＢ（３０２）という２つのホストサーバと、ＳＡＮスイッチＡ（３２１）とＳＡＮスイッチＢ（３２２）という２つのＳＡＮスイッチからなるファブリックと、ストレージサブシステムＡ（３３１）という１つのストレージサブシステムがある。

ホストサーバＡ（３０１）では、アプリケーションＡ（３０３）とアプリケーションＢ（３０４）が稼働している。ホストサーバＡ（３０１）には、ＣＰＵ−Ａ（３０６）とメモリＡ（３０７）があり、また、ファイルシステムＡ（３１０）〜ファイルシステムＣ（３１２）とボリュームＡ（３１４）〜ボリュームＣ（３１６）を備える。ボリュームＡ（３１４）は、後に説明するＬＵ―Ａ（３３５）に対しＩ/Ｏ命令を発行できるようにマウントした仮想ディスクである。ボリュームＢ（３１５）とボリュームＣ（３１６）についても同様で、それぞれ、ＬＵ―Ｂ（３３６）とＬＵ―Ｃ（３３７）をマウントした仮想ディスクである。ホストサーバＡは、ホストバスアダプタ（３１８）を１つ備え、以下、番号（３１８）をポートＡという。

ホストサーバＢ（３０２）では、ホストサーバＡと同様に、アプリケーションＣ（３０５）が稼働している。ホストサーバＢ（３０２）には、ＣＰＵ−Ｂ（３０８）とメモリＢ（３０９）があり、また、ファイルシステムＤ（３１３）とボリュームＤ（３１７）を備える。ホストサーバＢは、ホストバスアダプタ（３１９）を１つ備え、以下、番号（３１９）をポートＢという。

ＳＡＮスイッチＡ（３２１）は、スイッチポート（３２３）〜（３２５）を備える。ＳＡＮスイッチＡ（３２１）が備えるポートのうち、以下、番号（３２３）をポートＣ、番号（３２４）をポートＤ、番号（３２５）をポートＥという。

ＳＡＮスイッチＢ（３２２）についても同様で、ＳＡＮスイッチＢ（３２２）は、ポート（３２６）〜（３２９）を備える。番号（３２６），（３２７），（３２８），（３２９）のポートをそれぞれ、以下、ポートＦ、ポートＧ、ポートＨ、ポートＩという。

ストレージサブシステムＡ３３１は、物理ディスク（３５０）〜（３５７）を備える。物理ディスク（３５０）〜（３５３）によりＲＡＩＤ構成された仮想ディスクがＲＡＩＤグループＡ（３４８）で、物理ディスク（３５４）〜（３５７）によるＲＡＩＤ構成された仮想ディスクがＲＡＩＤグループＢ（３４９）である。ＲＡＩＤグループＡ（３４８）を、上位のサーバが使いやすい大きさにスライスした結果が論理ボリュームＡ（３４４）と論理ボリュームＢ（３４５）である。同様に、ＲＡＩＤグループＢ（３４９）をスライスした結果が論理ボリュームＣ（３４６）と論理ボリュームＤ（３４７）である。論理ボリュームＡ（３４４）をポートＪ（３３２）経由でサーバからアクセス可能になるよう公開した存在がＬＵ−Ａ（３３５）であり、同様に、論理ボリュームＢ（３４５）、論理ボリュームＣ（３４６）、論理ボリュームＤ（３４７）を公開した存在が、ＬＵ−Ｂ（３３６）、ＬＵ−Ｃ（３３７）、ＬＵ−Ｄ（３３８）である。

ストレージサブシステムＡ（３３１）内のチャネルコントローラＡ（３３９）は、ポートＪ（３３２）とキャッシュＡ（３４１）間のデータのやり取りを制御するＣＰＵである。同様に、チャネルコントローラＢ（３４０）は、ポートＫ（３３３）およびポートＬ（３３４）とキャッシュＡ（３４１）間のデータのやり取りを制御するＣＰＵである。また、ディスクコントローラＡ（３４２）は、ＲＡＩＤグループＡ（３４８）とキャッシュＡ（３４１）間のデータのやり取りを制御するＣＰＵである。同様に、ディスクコントローラＢ（３４３）は、ＲＡＩＤグループＢ（３４９）とキャッシュＡ（３４１）間のデータのやり取りを制御するＣＰＵである。

図３にて、装置は、ホストサーバＡ（３０１）、ＣＰＵ−Ａ（３０６）、メモリＡ（３０７）、ポートＡ（３１８）、ホストサーバＢ（３０２）、ＣＰＵ−Ｂ（３０８）、メモリＢ（３０９）、ポートＢ（３１９）、ＳＡＮスイッチＡ（３２１）、ポートＣ（３２３）〜Ｅ（３２５）、ＳＡＮスイッチＢ（３２２）、ポートＦ（３２６）〜ポートＩ（３２９）、ストレージサブシステムＡ（３３１）、ポートＪ（３３２）〜ポートＬ（３３４）、チャネルコントローラＡ（３３９）およびＢ（３４０）、キャッシュＡ（３４１）、ディスクコントローラＡ（３４２）およびＢ（３４３）、ＲＡＩＤグループＡ（３４８）およびＢ（３４９）、物理ディスク群（３５０〜３５１）である。図３にて、アプリケーションは、アプリケーションＡ（３０３）〜アプリケーションＣ（３０５）である。図３にて、論理ユニットは、ファイルシステムＡ（３１０）〜ファイルシステムＤ（３１３）、ボリュームＡ（３１４）〜ボリュームＤ（３１７）、ＬＵ−Ａ（３３５）〜ＬＵ−Ｄ（３３８）、論理ボリュームＡ（３４４）〜論理ボリュームＤ（３４７）である。

図３において、装置、論理ユニット、アプリケーション間に引かれた太線は、性能の依存関係を表わす。図３の例では、アプリケーションＡ（３０３）は、ファイルシステムＡ（３１０）とファイルシステムＢ（３１１）に対しＩ/Ｏ（Input/Output）処理を行う。この場合、アプリケーションＡ（３０３）は、ファイルシステムＡ（３１０）とファイルシステムＢ（３１１）に対しＩ/Ｏ上の負荷をかけることとなり、アプリケーションＡ（３０３）は、ファイルシステムＡ（３１０）とファイルシステムＢ（３１１）に性能上の負荷に関する依存関係があることとなる。ファイルシステムＡ（３１０）とボリュームＡを結ぶ線は、ファイルシステムＡがボリュームＡ上に配置される関係を表わしているが、この関係は、また、アプリケーションがファイルシステムＡに対して操作を行った場合に、ボリュームＡへ操作がつながるため、性能上の負荷について依存関係があることを表わしている。ボリュームＡ〜ボリュームＣとポートＡの間の線も同様に、性能の依存関係がある。

ボリュームＡ（３１４）は、ストレージサブシステムＡ（３３１）内のＬＵ−Ａ（３３５）をホストサーバＡ（３０１）上にマウントしたものであるため、アプリケーションＡ（３０３）がＩ／Ｏ命令を発行すると、ＬＵ−Ａ（３３５）に対するアクセスをストレージサブシステムＡ（３３１）が処理することになる。そこで、ＬＵ−Ａ（３３５）を、ストレージサブシステムＡ（３３１）内におけるアプリケーションＡ（３０３）の代替的存在であり、ストレージサブシステムＡ（３３１）内の装置を利用するコンシューマの１つと考えることができる。ストレージサブシステムＡ（３３１）内の装置のうち、ＬＵ−Ａ（３３５）と関わりがあるものには、チャネルコントローラＡ（３３９）、キャッシュＡ（３４１）、ディスクコントローラＡ（３４２）、ＲＡＩＤグループＡ（３４８）、物理ディスク群（３５０〜３５３）があり、それらは、ＬＵ−Ａ（３３５）と性能の依存関係がある。

ホストサーバ内のボリュームと、同ボリュームのマウント元であるストレージサブシステム内のＬＵの対が決まると、この両者の間でやり取りされる入出力データの転送経路として、ホストバスアダプタのポート、ＳＡＮスイッチのポート群、ストレージサブシステムのポートが決まる。ホストサーバのボリュームにかかる入出力の負荷は経路上のポートに対する通信の負荷となるため、ホストサーバ内のボリュームと、経路上のポートの間には性能の依存関係がある。図３の例では、ボリュームＡ（３１４）の対になるＬＵはＬＵ−Ａ（３３５）であり、ボリュームＡ（３１４）とＬＵ―Ａ（３３５）間の経路上のポートである、ポートＡ（３１８）、ポートＣ（３２３）、ポートＤ（３２４）、ポートＪ（３３２）は、ボリュームＡ（３１４）と性能の依存関係がある。

図４〜図９を参照して監視エージェントの構成情報の内容を説明する。
図４は、各監視エージェントの構成情報に含まれるテーブルを示す説明図である。図４に示すように、各監視エージェント１７１〜１７４は、当該エージェントが監視する装置・論理ユニット・アプリケーションの一覧情報を格納するテーブルと、装置・論理ユニット・アプリケーション間の依存関係情報を格納するテーブルを、構成情報２２８に備える。

図４に示す例では、アプリケーション監視エージェント１７１は、監視対象アプリケーションの一覧情報をアプリケーション一覧テーブル４０２に格納するとともに、当該アプリケーションがどのファイルシステムを利用するかを示す情報をアプリケーション・ファイルシステム間関連テーブル４０１に格納する。

同様に、ホスト監視エージェント１７２は、監視対象のファイルシステム、ボリューム、ホストポートの一覧情報を、それぞれファイルシステム一覧テーブル４１３、ボリューム一覧テーブル４１４、ホストポート一覧テーブル４１５に格納するとともに、各監視対象間に成り立つ性能の依存関係情報を、ファイルシステム・ボリューム間関連テーブル４１１、ボリューム・ＬＵ・ホストポート間関連テーブル４１２に格納する。

同様に、ファブリック監視エージェント１７３は、監視対象のＳＡＮスイッチポートの一覧情報を、ＳＡＮスイッチポート一覧テーブル４２２に格納するとともに、ホスト側ポートからストレージポートまでの通信経路上のポート群をホスト・ストレージポート間通信経路テーブル４２１に格納する。

同様に、ストレージサブシステム監視エージェント１７４は、監視対象のストレージポート、ＬＵ、チャネルコントローラ、キャッシュ、ディスクコントローラ、論理ボリューム、ＲＡＩＤグループの各種類に関する一覧情報を、種類毎の一覧テーブル４３２〜４３８に格納する。また、ＬＵおよび当該ＬＵと性能の依存関係があるストレージサブシステム構成要素に成り立つ性能の依存関係情報を、ＬＵ・ストレージサブシステム内要素間関連テーブル４３１に格納する。

図５は、アプリケーション・ファイルシステム間関連テーブルの構造を示す説明図である。図５に示すテーブルは、アプリケーション監視エージェント１７１が備える構成情報２２８に格納される、アプリケーション・ファイルシステム間関連テーブル４０１（図４参照）の構造の一例を示している。アプリケーション・ファイルシステム間関連テーブル４０１は、アプリケーションとファイルシステムとの間の性能の依存関係を記録するためのものであり、アプリケーションの識別情報を格納するアプリケーション欄５０１、ファイルシステムの識別情報を格納するファイルシステム欄５０２を有する。テーブルの各行は、依存関係があるアプリケーションとファイルシステムの組に対応する。具体的には、図３で示した性能の依存関係の例において、ホストサーバＡ（３０１）上で稼働するアプリケーションＡ（３０３）は、ファイルシステムＡ（３１０）およびファイルシステムＢ（３１１）に、性能の依存関係があることがわかる。

図６は、ファイルシステム・ボリューム間関連テーブルの構造を示す説明図である。図６に示すテーブルは、ホスト監視エージェント１７２が備える構成情報２２８に格納される、ファイルシステム・ボリューム間関連テーブル４１１（図４参照）の構造の一例を示している。ファイルシステム・ボリューム間関連テーブル４１１は、アプリケーションとファイルシステムとの間の性能の依存関係を記録するためのものであり、ファイルシステムの識別情報を格納するファイルシステム欄６０１、ボリュームの識別情報を格納するボリューム欄６０２からなる。テーブルの各行は、依存関係があるファイルシステムとボリュームの組に対応する。具体的には、図３で示した性能の依存関係の例において、ホストサーバＡ（３０１）上の稼動するファイルシステムＡ（３１０），Ｂ（３１１），Ｃ（３１２）は、それぞれボリュームＡ（３１４），Ｂ（３１５），Ｃ（３１６）と性能の依存関係があることがわかる。

図７は、ボリューム・ＬＵ・ホストポート間関連テーブルの構造を示す説明図である。図７に示すテーブルは、ホスト監視エージェント１７２が備える構成情報２２８に格納される、ボリューム・ＬＵ・ホストポート間関連テーブル４１２（図４参照）の構造の一例を示している。ボリューム・ＬＵ・ホストポート間関連テーブル４１２は、ホスト内のボリュームとストレージサブシステム内のＬＵ間の対応関係およびアクセスに用いるホストポートとの対応関係を記録するためのものであり、ボリュームの識別情報を格納するボリューム欄７０１、ＬＵの識別情報を格納するＬＵ欄７０２、ＬＵを保持するストレージサブシステムの識別情報を格納するＬＵ保持ストレージサブシステム欄７０３、アクセスに用いるホストポートの識別情報を格納するホストポート欄７０４からなる。テーブルの各行は、依存関係があるボリューム・ＬＵ・ポートの組に対応する。具体的には、図３で示した性能の依存関係の例において、ホストサーバＡ（３０１）は、ＬＵ−Ａ（３３５）、ＬＵ保持するストレージサブシステム（３３１）、ポートＡ（３１８）と、性能の依存関係があることがわかる。

図８は、ホストポート・ストレージポート間通信経路テーブルの構造を示す説明図である。図８のテーブルは、ファブリック監視エージェント１７３が備える構成情報２２８に格納される、ホストポート・ストレージポート間通信経路テーブル４２１（図４参照）の構造の一例を示している。ホストポート・ストレージポート間通信経路テーブル４２１は、ホスト内のボリュームとストレージサブシステム内のＬＵとの転送経路情報を記録するものであり、ホストポートの識別情報を格納するホストポート欄８０１、ストレージポートの識別情報を格納するストレージポート欄８０２、当該ホストポートから当該ストレージポートまでの経路を示すＳＡＮスイッチ内ポート識別情報のリストを格納する通信経路欄８０３からなる。テーブルの各行は、依存関係があるホストポート、ＳＡＮスイッチポート、ストレージポートの組に対応する。具体的には、図３で示した性能の依存関係の例において、ポートＡ（３１８）は、ポートＣ（３２３）およびポートＤ（３２４）を経由してポートＪ（３３２）に接続されていることがわかる。

図９は、ＬＵ・ストレージサブシステム内要素間関連テーブルの構造を示す説明図である。図９に示すテーブルは、ストレージサブシステム監視エージェント１７４が備える構成情報２２８に格納される、ＬＵ・ストレージサブシステム内要素間関連テーブル４３１（図４参照）の構造の一例を示している。ＬＵ・ストレージサブシステム内要素間関連テーブル４３１は、ストレージサブシステム内のＬＵと当該ストレージサブシステム内の各要素との対応関係を記録するものであり、ＬＵの識別情報を格納するＬＵ欄９０１、ストレージポートの識別情報を格納するストレージポート欄９０２、チャネルコントローラの識別情報を格納するチャネルコントローラ欄９０３、キャッシュの識別情報を格納するキャッシュ欄９０４、ディスクコントローラの識別情報を格納するディスクコントローラ欄９０５、論理ボリュームの識別情報を格納する論理ボリューム欄９０６、ＲＡＩＤグループの識別情報を格納するＲＡＩＤグループ欄９０７からなる。テーブルの各行は、ＬＵと当該ＬＵが依存関係がある各ストレージ装置内要素の組に対応する。具体的には、図３で示した性能の依存関係の例において、ＬＵ−Ａ（３３５）は、ポートＪ（３３２）、チャネルコントローラＡ（３３９）、キャッシュＡ（３４１）、ディスクコントローラＡ（３４２）、論理ボリュームＡ（３４４）、ＲＡＩＤグループＡ（９０７）との対応関係があることがわかる。

図１０は、実施形態１における装置性能管理ソフトの構成情報に含まれるテーブルを示す構成図である。装置性能管理ソフト１８１の構成情報２３４に格納する情報は、図５〜図９にて示した各監視エージェントが収集した情報を纏め上げた情報である。図１０に示すように、構成情報２３４には、監視エージェントを介して取得した装置の一覧情報を格納する装置一覧テーブル１００１、同じくアプリケーションの一覧情報を格納するアプリケーション一覧テーブル１００２、装置と当該装置を利用するアプリケーションの対応関係情報を格納する装置・アプリケーション間関連テーブル１００３を有している。図１０には、装置の飽和兆候検出を行うため、装置とアプリケーションの性能情報の相関分析を行う場合に必要となるテーブルの例を示している。

図１１は、装置一覧テーブルの構造を示す説明図である。図１１に示すテーブルは、装置一覧テーブル１００１（図１０参照）の構造の一例を示している。装置一覧テーブル１００１は、各装置監視エージェントが収集した装置の一覧情報を纏め上げたテーブルであり、装置種別の識別情報を格納する装置種別欄１１０１、装置名の識別情報を格納する装置名欄１１０２、装置がより大きな閉じたハードウェアを構成する要素である場合に、当該装置が所属するハードウェアの識別情報を格納する所属先欄１１０３、装置を飽和兆候検出対象とするか否かを決定する飽和兆候検出対象欄１１０４からなる。飽和兆候検出対象欄１１０４については、図１６にて詳しく説明する。具体的には、図３に示した装置群の一覧情報を装置性能管理ソフト１８１が収集し纏め上げ、例えば、ＣＰＵ−Ａ（３０６）は、ホストサーバＡ（３０１）に属し、飽和兆候検出対象であることがわかる。

図１２は、アプリケーション一覧テーブルの構造を示す説明図である。図１２に示すテーブルは、アプリケーション一覧テーブル１００２（図１０参照）の構造の一例を示している。アプリケーション一覧テーブル１００２は、アプリケーション監視エージェントが収集したアプリケーションの一覧情報を纏め上げたテーブルであり、アプリケーション名の識別情報を格納するアプリケーション欄１２０１、アプリケーションが稼動するサーバの識別情報を格納する所属先欄１２０２、アプリケーションを飽和兆候検出対象とするか否かを決定する飽和兆候検出対象欄１２０３からなる。飽和兆候検出対象欄１２０３については、図１６にて詳しく説明する。具体的には、図３に示したアプリケーション群の一覧情報を装置性能管理ソフト１８１が収集し纏め上げ、例えば、アプリケーションＡ（３０３）は、ホストサーバＡ（３０１）に属し、飽和兆候検出対象であることがわかる。

図１３は、装置・アプリケーション間関連テーブルの構造を示す説明図である。図１３に示すテーブルは、装置・アプリケーション間関連テーブル１００３（図１０参照）の構造の一例を示している。装置・アプリケーション間関連テーブル１００３は、監視エージェントが収集した装置、論理ユニット、アプリケーション間の関連情報を結合し、装置とアプリケーション間に成り立つ性能の依存関係を纏めたテーブルであり、装置種別の識別情報を格納する装置種別欄１３００、装置名の識別情報を格納する装置名欄１３０１、当該装置の所属先ハードウェアの識別情報を格納する所属先欄１３０２、当該装置と性能の依存関係があるアプリケーション名の識別情報を格納するアプリケーション名欄１３０３、当該アプリケーションが稼動するサーバの識別情報を格納する所属先欄１３０４からなる。具体的には、図３に示した性能の依存関係の例において、監視エージェントから収集した情報から、個々の装置とアプリケーションとの関係を計算し、装置・アプリケーション間関連テーブル１００３に格納する。例えば、ＣＰＵ−Ａ（３０６）は、ホストサーバＡ（３０１）に属し、アプリケーションＡ（３０３）は、ホストサーバＡ（３０１）に属し、ＣＰＵ−Ａ（３０６）と、アプリケーションＡ（３０３）は、性能の依存関係にあることがわかる。

個々の装置とアプリケーションとの関係の計算方法の概略を、図３および図４を参照して説明する。ここでは、ＲＡＩＤグループと性能の依存関係があるアプリケーションを見つけ出す方法について示す。

ＲＡＩＤグループと性能の依存関係があるＬＵ群は、ストレージサブシステム監視エージェント１７４が備えるＬＵ・ストレージサブシステム内要素間関連テーブル４３１より解決できる。解決した当該ＬＵ群の各々について、性能の依存関係があるボリューム群は、ホスト監視エージェント１７２が備えるボリューム・ＬＵ・ホストポート間関連テーブル４１２より解決できる。解決した当該ボリューム群の各々について、性能の依存関係があるファイルシステム群は、ホスト監視エージェント１７２が備えるファイルシステム・ボリューム間関連テーブル４１１より解決できる。解決した当該ファイルシステム群の各々について、性能の依存関係があるアプリケーション群は、アプリケーション監視エージェント１７１が備えるアプリケーション・ファイルシステム間関連テーブル４０１より解決できる。このようにして、ＲＡＩＤグループを起点に、当該ＲＡＩＤグループと性能の依存関係があるアプリケーションを解決する（見出す）ことができる。図３において、ＲＡＩＤグループよりアプリケーションに近い側に位置する装置についても、同様に、依存関係があるアプリケーションを解決する（見出す）ことができる。

図１４は、監視エージェントの性能情報および装置性能管理ソフトの性能情報に含まれるテーブルの構造を示す説明図である。監視エージェント２２１〜２２３の性能情報２２５（図２参照）には、性能情報記憶テーブル１４０１があり、当該監視エージェントの監視対象の、時系列な性能情報が格納される。装置性能管理ソフト１８１の性能情報２３２（図２参照）には、性能情報記憶テーブル１４０２があり、装置性能管理ソフト１８１が各監視エージェントから収集した性能情報が格納される。

図１５は、性能情報記憶テーブルの構造を示す説明図である。図１５のテーブルは、装置性能管理ソフト１８１が備える性能情報記憶テーブル１４０２（図１４参照）の構造の一例を示している。性能情報記憶テーブル１４０２は、監視対象のアプリケーションまたは論理ユニットまたは装置の識別情報を格納する監視対象種別を格納する監視対象種別欄１５００、監視対象名の識別情報を格納する監視対象名欄１５０１、当該監視対象が所属または稼動するハードウェアの識別情報を格納する所属先欄１５０２、当該監視対象が備える性能値の種類を識別する情報を格納する性能種別欄１５０３、観測した性能値を格納する性能値欄１５０４、観測した時刻を格納する観測時刻欄１５０５からなる。具体的には、図３で示した装置群、論理ユニット群、アプリケーション群の例において、装置性能管理ソフト１８１が、当該装置、論理ユニット、アプリケーション群の性能情報を収集し格納される。なお、性能情報記憶テーブル１４０１（図１４参照）の構造は、性能情報記憶テーブル１４０２の構造と同様であるので、説明は省略する。

監視エージェント２２１〜２２３および装置性能管理ソフト１８１が収集、格納しうる性能情報には、いくつかの種類がある。例として、アプリケーションの性能情報の種類には、アプリケーションが発行するＩ／Ｏ（Input/Output）命令の量、Ｉ／Ｏバイト量、アプリケーションが当該アプリケーションの使用者／使用プログラムに対して提供するサービスレベルとしてのレスポンスタイムまたはスループット、アプリケーションが装置から受け取るサービスレベルとしてのレスポンスタイムまたはスループットがある。

論理ユニットは、アプリケーションの代替とみなすことができるため、論理ユニットには、当該論理ユニットを使用するアプリケーションが当該論理ユニットを経由して発行したＩ／Ｏ命令の量およびＩ／Ｏバイト量、論理ユニットが装置から受け取るサービスレベルとしてのレスポンスタイムまたはスループットがある。

装置の性能情報の種類には、装置が処理したＩ／Ｏ命令の量、Ｉ／Ｏバイト量、使用率がある。また、キャッシュの場合には、キャッシュヒットレートや、処理命令数に対するキャッシュへの書き込みを遅らせた回数の割合であるライトペンディングレートもある。

図１６は、管理対象装置群の中から飽和兆候検出対象を決定するための画面例と決定された内容に応じての関連テーブル内容を示す説明図である。図１６（ａ）に示す飽和兆候検出対象装置設定画面１６０１は、装置性能管理ソフト１８１の飽和兆候検出対象装置設定処理Ｓ２３５（図２参照）が性能管理クライアント１６１に表示する、管理対象装置群の中から飽和兆候検出対象を設定するための画面例である。当該画面例において、飽和兆候検出対象装置設定処理Ｓ２３５は、装置性能管理ソフト１８１が監視するアプリケーションの一覧を領域１６０３に表示する。管理者は、性能の依存関係がある装置を性能飽和兆候の検出対象としたいアプリケーションを検討し、領域１６０２のチェックボックスを使って選択する。

すると、図１６（ｂ）に示すように、飽和兆候検出対象装置設定処理Ｓ２３５は、アプリケーション一覧テーブル１００２（図１２参照）の飽和兆候検出対象欄１２０３の値を、管理者の選択内容に応じて更新する。

次に、図１６（ｃ）に示すように、飽和兆候検出対象装置設定処理Ｓ２３５は、アプリケーション一覧テーブル１００２の飽和兆候検出対象欄１２０３の値が飽和兆候検出対象であることを意味する値となっているアプリケーションの一覧を取得し、当該アプリケーション群のいずれからも使用されない装置を、装置・アプリケーション間関連テーブル１００３（図１３参照）を使って絞り込み、絞り込まれた装置群について、装置一覧テーブル１００１（図１１参照）の飽和兆候検出対象欄１１０４の値を、飽和兆候検出対象としないように更新する。絞り込まれなかった装置は、飽和兆候検出対象とするように更新する。

図１６に示すように、アプリケーションの視点で飽和兆候検出対象装置を決定する画面を表示してもよいし、装置一覧を表示し、各装置について飽和兆候検出対象装置とするか否かを選択する画面を表示してもよい。その場合は、アプリケーション一覧テーブル１００２の飽和兆候検出対象欄１２０３は必要ない。また、当該機能を持たず、全装置を常に飽和兆候検出対象装置としてもよい。その場合は、装置一覧テーブル１００１の飽和兆候検出対象欄１１０４は必要ない。図１６では、画面による選択方法を示したが、設定ファイルなどによる選択方法を用いてもよい。

次に、飽和兆候検出処理を説明する。
図１７は、実施形態１における装置性能管理ソフトの飽和兆候検出処理を示すフローチャートである。装置性能管理ソフト１８１の飽和兆候検出処理Ｓ２３６（図２参照）のフローチャートは、図３８で示したステップＳ３８０４およびステップＳ３８０５にあたる。以下、当該フローチャートについて、初めに概要を説明した後、主要なステップについて詳細を説明する。なお、装置性能管理ソフト１８１のソフトウェアの処理は、性能管理サーバ１５１（図１参照）のＣＰＵが実行することで実現する。

初めに、ステップＳ１７０１にて、装置とアプリケーションとで性能情報の変化の相関を分析する期間を決定する。期間は、現在時刻から特定の時間だけ遡った時刻までの範囲としてもよいし、管理者が画面や設定ファイルなどで決定した時間範囲としてもよい。

次に、ステップＳ１７０２にて、装置一覧テーブル１００１（図１１参照）から、飽和兆候検出対象とする装置一覧を取得する。装置一覧テーブル１００１の飽和兆候検出対象欄１１０４のように、装置毎に飽和兆候検出対象とするか否かを設定する欄があれば、飽和兆候検出対象と指定された装置を抜き出す処理に相当する。次に、ステップＳ１７０３〜ステップＳ１７１２まで、ステップＳ１７０２にて取得した装置の各々についてループ処理を行う。

ステップＳ１７０４では、当該装置と性能の依存関係があるアプリケーション一覧を、装置・アプリケーション間関連テーブル１００３（図１３参照）を使って絞り込み、取得する。ステップＳ１７０５では、ステップＳ１７０１で決定した期間内の、当該装置の性能情報を、性能情報記憶テーブル１４０２（図１５参照）から取得する。次に、ステップＳ１７０６〜ステップＳ１７０９まで、ステップＳ１７０５にて取得したアプリケーションの各々について、飽和兆候の有無を検出するためのループ処理を行う。

ステップＳ１７０７では、ステップＳ１７０１で決定した期間内の、当該アプリケーションの性能情報を、性能情報記憶テーブル１４０２から取得する。ステップＳ１７０８では、ステップＳ１７０５で取得した当該装置の性能情報と、ステップＳ１７０７で取得した当該アプリケーションの性能情報との間で相関係数Ｒを計測し、｛当該装置の識別情報、当該アプリケーションの識別情報、ステップＳ１７０１で決定した期間情報、相関係数Ｒ｝の組を、装置性能管理ソフト１８１の飽和兆候情報２３７の相関係数演算結果テーブル２００１（図２１参照）に保存する。相関係数演算結果テーブル２００１については、図２１を参照して後述する。ステップＳ１７０９は、アプリケーションに関するループの終了である。

ステップＳ１７１０では、ステップＳ１７０８で保存した、装置とアプリケーションとの間の性能情報の相関係数Ｒを当該装置の飽和度を表す指標として用い、相関係数Ｒが閾値を超えた場合には、装置が飽和兆候を示したと判定する。装置が飽和兆候を示したと判定（検出）した場合には（ステップＳ１７１０，Ｙｅｓ）、ステップＳ１７１１に処理ステップを進める。装置が飽和兆候を示したと判定（検出）しなかった場合には（ステップＳ１７１０，Ｎｏ）、ステップＳ１７１２に処理ステップを進める。

ステップＳ１７１１は、｛飽和兆候を示したと判定した装置の識別情報、ステップＳ１７０１で決定した期間情報｝の組を、装置性能管理ソフト１８１の飽和兆候情報２３７の飽和兆候情報テーブル２００２（図２２参照）に保存する。飽和兆候情報テーブル２００２については、図２２を参照して詳しく後述する。なお、ステップＳ１７１２は、装置に関するループの終了である。

次に、主要なステップについて、詳細を説明する。
ステップＳ１７０５では、装置の性能情報として、装置の使用率を用いるか、使用率以外の性能情報から擬似的に使用率を計算して用いる。使用率を取得できる装置には、ＣＰＵを内包するチャネルコントローラやディスクコントローラ、ホストサーバ上のＣＰＵなどのＣＰＵ系装置と、ＲＡＩＤグループなどのディスク系装置がある。ストレージポート、ホストポート、ＳＡＮスイッチポートなどのポート系装置の場合には、使用率を取得できない場合があるが、その場合には、ポートの単位時間あたり最大転送可能バイト量を分母に、計測した単位時間あたり転送バイト量を分子にし、擬似的に使用率を計算してもよい。また、キャッシュについては、使用率は常に１００％である場合が多く、その場合は性能情報として参考にならないため、使用率の変わりにキャッシュヒットレートまたはライトペンディングレートを用いてもよい。

ステップＳ１７０７では、アプリケーションの性能情報として、アプリケーションが当該アプリケーションの使用者／使用プログラムに対して提供するサービスレベルとしてのレスポンスタイムまたは、アプリケーションが装置から受け取るサービスレベルとしてのレスポンスタイムを使用する。

ステップＳ１７０８では、ステップＳ１７０１で決定した期間における、ステップＳ１７０５で取得した装置の時系列な使用率とステップＳ１７０７で取得したアプリケーションの時系列なレスポンスタイムから、各々の変化値列を計算し、変化値列同士の相関係数を計算する。装置の使用率と、装置からアプリケーションに対するレスポンスタイムの間の関係は、一般に図１８に示すグラフのようになる。

図１８は、装置の使用率と、当該装置を利用するアプリケーションが装置に処理要求を出した場合のレスポンスタイムの間に成り立つ関係を示す説明図である。図１８において、横軸１８０１は装置の使用率を、縦軸１８０２は装置からアプリケーションに対するレスポンスタイムを、曲線１８０３は使用率とレスポンスタイムの間の関係を表す。縦線１８０４は使用率が１００％であることを表し、縦線１８０５は、使用率がある値Ｘ％であることを表す。１８０６に示す範囲、即ち使用率が０％〜Ｘ％の間は、使用率が上昇しても、レスポンスタイムはあまり上昇しない。この場合、使用率変化に対するレスポンスタイム変化の反応は微弱であり、使用率変化とレスポンスタイム変化にはランダム性が生じやすく、相関は低くなりやすい。１８０８に示す範囲、即ち使用率がＸ％〜１００％の間は、使用率が上昇するにつれ、レスポンスタイムも大きく上昇する。この場合、使用率変化に対するレスポンスタイム変化の反応は鋭く、使用率変化とレスポンスタイム変化の相関は大きくなりやすい。

以下、相関係数の計算方法の例をあげる。
図１９は、装置の使用率と、当該装置を利用するアプリケーションが装置に処理要求を出した場合のレスポンスタイムとの間で、変化値の正負による相関分析を行う例を示す説明図である。図１９に示すように、時間経過に伴う使用率とレスポンスタイムの変化量の正負を計算し、その共起割合を利用して、相関係数を計算することができる。

図１９に示すグラフの横軸１９０１は、時間を表す。折れ線１９０２は、レスポンスタイムの時間変化を、折れ線１９０３は、使用率の時間変化を表す。区域１９０４は、時間経過に伴うレスポンスタイムの変化量の正負を表す。同様に区域１９０５は、時間経過に伴う使用率の変化量の正負を表す。区域１９０６は、レスポンスタイムと使用率それぞれの変化量の正負が共起したか否かを表す。全体に対して共起した回数の占める割合を使って、相関係数Ｒとすることができる。例えば、区域１９０６の共起した回数（Ｙｅｓの回数）は７回のうち５回であるので、相関係数Ｒが７１．４％であると算出できる。

正負を使わない方法として、レスポンスタイムと使用率各々の時系列な変化値同士を使って相関係数を測り、相関係数Ｒとすることができる。また、確度を高めるため、時間変化に伴う変化量が特定の閾値よりも低い場合には相関係数の計算に用いないなどの方法も考えられる。

装置がキャッシュの場合、使用率の代わりにキャッシュヒットレートを用いることもできる。キャッシュヒットレートは、使用率とは逆に、０％に近ければ近いほど、アプリケーションへのサービスレベルは低くなる。そこで、キャッシュヒットレートの変化値とサービスレベルの変化値で相関分析を行う場合には、相関係数の正負を逆転し、前記閾値と比較する。

図１７に戻り、ステップＳ１７１０では、１つの装置を複数のアプリケーションが利用する場合に、各アプリケーションとの間で計算した複数の相関係数Ｒが得られる。この場合、アプリケーション毎に重みをつけ、複数の相関係数Ｒの加重平均を行うことで、複数の相関係数をまとめることができる。レスポンスタイムを重視したい特定の１つまたは複数のアプリケーションの重みを高くし、その他のアプリケーションの重みを低く設定することもできる。ステップＳ１７１０では、前記方法で計算した、装置と、装置を使用するアプリケーション（群）との間の性能情報の相関係数を、当該装置に関する飽和度とみなし、該相関係数が閾値を超えた場合には、当該装置は飽和兆候を示したと判定する。当該閾値は、システムに固定としてもよいし、画面や設定ファイルなどで設定可能としてもよい。

図２０は、装置性能管理ソフトの飽和兆候情報に含まれるテーブルを示す構成図である。装置性能管理ソフト１８１の飽和兆候情報２３７には、相関係数演算結果テーブル２００１と飽和兆候情報テーブル２００２がある。

図２１は、実施形態１における相関係数演算結果テーブルの構造を示す説明図である。図２１に示すテーブルは、装置性能管理ソフト１８１が備える相関係数演算結果テーブル２００１（図２０参照）の構造の一例を示している。相関係数演算結果テーブル２００１には、装置、アプリケーション、期間の組毎に計算した性能情報の相関係数を格納する。相関係数演算結果テーブル２００１は、装置種別の識別情報を格納する装置種別欄２１００、装置種別の装置名の識別情報を格納する装置名欄２１０１、当該装置の所属先であるハードウェア識別情報を格納する所属先欄２１０２、アプリケーション名のアプリケーション識別情報を格納するアプリケーション名欄２１０３、当該アプリケーションが稼動するサーバの所属先であるサーバ識別情報を格納する所属先欄２１０４、相関係数の計算に用いた性能情報の期間情報を格納するための、開始時刻情報を格納する開始時刻欄２１０５と終了時刻情報を格納する終了時刻欄２１０６、演算結果の相関係数を格納する相関係数欄２１０７からなる。

具体的には、図３で示した性能の依存関係の例において、ＣＰＵ−Ａ（３０６）とアプリケーションＡ（３０３）の相関係数を、開始時刻２００７年１月２２日１０：００：００から終了時刻２００７年１月２２日１２：００：００までの２時間の相関係数計算期間において計算し、相関係数が０．５３であることがわかる。

図２２は、飽和兆候情報テーブルの構造を示す説明図である。図２２に示すテーブルは、飽和兆候を検知した装置の情報を格納するためのテーブルである飽和兆候情報テーブル２００２（図２０参照）の構造を示している。飽和兆候情報テーブル２００２は、装置種別の識別情報を格納する装置種別欄２２００、装置種別の装置名の識別情報を格納する装置名欄２２０１、当該装置が所属するハードウェア識別情報を格納する所属先欄２２０２、相関係数の計算に用いた期間情報を格納するための、開始時刻情報を格納する開始時刻欄２２０３と終了時刻情報を格納する終了時刻欄２２０４からなる。

具体的には、仮に、相関係数に対する閾値を０．３０とし、当該閾値を超えた場合に装置が飽和兆候を示すと判定すると、図２１に示すテーブルにてディスクコントローラＡに関する相関係数は０．２０であるため、ディスクコントローラＡは飽和兆候を示したと判定されない。判定結果により、図２２に示すテーブルには、ディスクコントローラＡに関する飽和兆候情報は格納されていない。

図２３は、実施形態１における装置性能管理ソフトの飽和兆候情報出力処理が出力する画面例を示す説明図である。装置性能管理ソフト１８１の飽和兆候情報出力処理Ｓ２３８が出力する画面２３０１は、１つの表を含み、当該表は、飽和兆候を検出した装置の識別情報を表示する装置種別列２３０２、当該装置の種別識別情報を表示する装置名列２３０３、当該装置が所属するハードウェアの識別情報を表示する所属先列２３０４、当該装置の使用率を表示する使用率列２３０５、当該装置と性能の依存関係があるアプリケーションの識別情報を表示する装置を使用するアプリケーション名列２３０６、当該アプリケーションが稼動するホストサーバの識別情報を表示するアプリケーション稼動サーバ列２３０７、当該アプリケーションのレスポンスタイムを表示するレスポンスタイム列２３０８、当該装置と当該アプリケーションとの間の性能情報の相関係数を表示する相関係数列２３０９、相関係数計算を行った期間を示す、期間の開始日時情報を表示する開始日時列２３１０と終了日時情報を表示する終了日時列２３１１、相関係数の演算に用いた性能情報の詳細を表示する画面を表示するためのボタンを表示するレポート列２３１２および当該ボタン２３１３からなる。各列２３０２〜２３１３の全てを画面表示することは、必ずしも必要としない。

図２４は、実施形態１における装置性能管理ソフトの飽和兆候情報出力処理を示すフローチャートである。装置性能管理ソフト１８１のソフトウェアの処理は、性能管理サーバ１５１（図１参照）のＣＰＵが実行することで実現する。装置性能管理ソフト１８１の飽和兆候情報出力処理Ｓ２３８は、ステップＳ２４０１にて飽和兆候情報テーブル２００２（図２２参照）をスキャンし、ステップＳ２４０２〜ステップＳ２４１１にて、飽和兆候情報テーブル２００２の各行についてループ処理を行う。

当該ループ処理の中では、まずステップＳ２４０３にて、飽和兆候情報テーブル２００２から検索した｛装置種別欄２２００、装置名欄２２０１、所属先欄２２０２、開始時刻欄２２０３、終了時刻欄２２０４｝の値をキーに性能情報記憶テーブル１４０２（図１５参照）を検索し、性能値欄１５０４より、当該装置の使用率を取得する。

次に、ステップＳ２４０４にて、ステップＳ２４０１〜ステップＳ２４０３で取得した、｛装置種別、装置名、所属先、使用率｝の各値を、図２３の各列２３０２〜２３０５の値として表示する。開始時刻と終了時刻によって表される期間内に複数の時刻の使用率がある場合で、かつ、画面表示範囲の都合により当該期間内の全時刻の使用率を表示できない場合、取得した使用率を一つまたは複数の値に丸め込み、表示してもよい。この時、当該期間における平均値を表示してもよいし、期間の最後の値を表示してもよいし、期間内の最大値を表示してもよい。本実施形態は、表示内容を制限するものではない。

次に、ステップＳ２４０５にて、｛装置種別欄２２００、装置名欄２２０１、所属先欄２２０２、開始時刻欄２２０３、終了時刻欄２２０４｝の値をキーに相関係数演算結果テーブル２００１（図２１参照）を検索し、｛アプリケーション名欄２１０３、所属先欄２１０４、相関係数欄２１０７｝の値の一覧を取得する。

次にステップＳ２４０６〜ステップＳ２４１０まで、取得したアプリケーションに関する一覧情報の各々についてループ処理を行う。当該ループ内のステップＳ２４０７では、｛アプリケーション名欄２１０３、所属先欄２１０４、開始時刻欄２００３、終了時刻欄２００４｝の値をキーに性能情報記憶テーブル１４０２（図１５参照）を検索し、性能値欄１５０４より、当該アプリケーションのレスポンスタイムを取得する。

次にステップＳ２４０８にて、ステップＳ２４０５〜ステップＳ２４０７で取得した、｛アプリケーション名、所属先、レスポンスタイム、相関係数｝およびステップＳ２４０１で決定した｛開始時刻、終了時刻｝の各値を、図２３の各列２３０６〜２３１１の値として表示する。レスポンスタイムも、装置の使用率の場合と同様に、画面表示範囲の都合により当該期間内の全時刻の使用率を表示できない場合、取得した使用率を一つまたは複数の値に丸め込み、表示してもよい。ステップＳ２４０９では、装置およびアプリケーションの組み合わせ毎に相関係数計算に用いた性能情報の詳細情報を表示するボタンを、図２３のレポート列２３１２の要素であるボタン２３１３として表示する。

図２５は、実施形態１における装置性能管理ソフトの飽和兆候情報出力処理が、相関係数を計算する際に用いた性能値の詳細情報を出力する画面例を示す説明図である。装置性能管理ソフト１８１の飽和兆候情報出力処理Ｓ２３８が、相関係数を計算する際に用いた性能値の詳細情報を出力する画面２５０１は、１つのグラフ２５０２を含み、当該グラフの横軸２５０５は時間軸を表し、一方の縦軸２５０３にはアプリケーションのレスポンスタイムを、もう一方の縦軸２５０４には装置の使用率を表す。グラフ２５０２は凡例２５０６を有してもよく、当該凡例では、アプリケーションおよび装置の識別情報と、必要があれば性能情報の種別も表示する。当該グラフの内容は表形式で表してもよい。また、図２５のグラフ２５０２を、図２３の画面２３０１内で表示してもよい。

飽和兆候情報出力処理Ｓ２３８は、さらに、将来アプリケーションに性能問題を引き起こす可能性が高い装置または現在アプリケーションに性能問題を引き起こしている可能性が高い装置として検出した装置の識別情報、当該装置と性能の依存関係がある装置を抽象化した論理的存在の識別情報、当該論理的存在と性能の依存関係があるアプリケーションの識別情報、当該装置または当該論理的存在または当該アプリケーションの性能情報、の可能な組み合わせのいずれかについて、画面、ログのいずれかまたは両方による出力、またはＥ−Ｍａｉｌ、ＳＮＭＰ（Simple Network Management Protocol）、コマンド実行の全てまたはいずれかの方法によりアラートを行ってもよい。

本実施形態では、１つ以上の装置および該装置と性能の依存関係がある１つ以上のアプリケーションを備えるシステムにおける装置性能を管理する性能管理サーバ１５１が、装置性能管理ソフト１８１により、装置およびアプリケーションの構成情報、ならびに、前記装置および前記アプリケーションの間に成り立つ性能の依存関係の構成情報を収集する構成情報収集処理Ｓ２３３と、前記装置および前記アプリケーションの性能情報を収集する性能情報収集処理Ｓ２３１と、前記装置の性能情報と、前記アプリケーションの性能情報の時間変化値に対して所定期間について相関分析し、前記相関分析により得られた相関係数が所定の閾値以上のとき、前記装置が飽和兆候ありと検出する飽和兆候検出処理Ｓ２３６と、前記装置が飽和兆候ありと検出されたとき、飽和兆候ありとされた装置の飽和兆候関連情報を、性能を管理する管理クライアントに告知する飽和兆候情報出力処理Ｓ２３８を含んで実行する。これにより、将来アプリケーションに性能問題を引き起こす可能性が高い装置、または、現在アプリケーションに性能問題を引き起こしている可能性が高い装置を検出することができる。

《実施形態２》
実施形態１では、アプリケーションのレスポンスタイムと装置の使用率の相関分析により、装置の性能飽和兆候を検知した。実施形態２では、アプリケーションのレスポンスタイムがなんらかの理由により取得できない場合などに、アプリケーションのレスポンスタイムの代わりに、装置内に作られる論理ユニット単位に取得したレスポンスタイムを用いて装置の性能飽和兆候を検知する。図２６〜図３２を参照して説明する。

図２６は、実施形態２における装置性能管理ソフトの構成情報に含まれるテーブルを示す構成図である。図２６において、飽和兆候検出を行うため、装置の性能情報と、アプリケーションの代替として論理ユニットの性能情報との間で相関分析を行う場合に構成情報２３４に含まれるテーブルの例を示す。装置性能管理ソフト１８１の構成情報２３４は、図１０に含むテーブルに加えて、論理ユニットの一覧情報を格納する論理ユニット一覧テーブル２６０１、装置と論理ユニット間に成り立つ性能の依存関係情報を格納する装置・論理ユニット間関連テーブル２６０２、同様に論理ユニットとアプリケーション間になりたつ性能の依存関係を格納する論理ユニット・アプリケーション間関連テーブル２６０３を有する。

図２７は、論理ユニット一覧テーブルの構造を示す説明図である。図２７に示すテーブルは、論理ユニット一覧テーブル２６０１（図２６参照）の構造の一例を示している。論理ユニット一覧テーブル２６０１は、装置監視エージェントから論理ユニットに関する一覧情報を抜き出し、纏め上げたテーブルであり、論理ユニット種別の識別情報を格納する論理ユニット種別欄２７０１、論理ユニット名の識別情報を格納する論理ユニット名欄２７０２、当該論理ユニットを保持するハードウェアの識別情報を格納する所属先欄２７０３からなる。

図２８は、装置・論理ユニット間関連テーブルの構造を示す説明図である。図２８に示すテーブルは、前記装置・論理ユニット間関連テーブル２６０２（図２６参照）の構造の一例を示している。装置・論理ユニット間関連テーブル２６０２は、監視エージェントが収集した装置、論理ユニット、アプリケーション間の関連情報をジョインし、装置と論理ユニット間に成り立つ性能の依存関係を纏めたテーブルであり、装置種別の識別情報を格納する装置種別欄２８００、装置種別の装置名の識別情報を格納する装置名欄２８０１、当該装置の所属先ハードウェアの識別情報を格納する所属先欄２８０２、当該装置と性能の依存関係がある論理ユニット種別の識別情報を格納する論理ユニット種別欄２８０３、論理ユニット種別の論理ユニット名の識別情報を格納する論理ユニット名欄２８０４、当該論理ユニットの所属先ハードウェアの識別情報を格納する所属先欄２８０５からなる。

具体的には、図３に示した性能の依存関係の例において、監視エージェントから収集した情報から、個々の装置と論理ユニットとの関係を計算し、装置・論理ユニット間関連テーブル２６０２に格納する。例えば、ポートＡ（３１８）は、ホストサーバＡ（３０１）に属し、ボリュームＡ（３１４）は、ホストサーバＡ（３０１）に属し、ポートＡ（３１８）と、ボリュームＡ（３１４）は、性能の依存関係にあることがわかる。

図１３にて、装置の末端であるＲＡＩＤグループから、当該ＲＡＩＤグループを使用するアプリケーションを解決する方法を示した。当該方法を用いることで、装置と当該装置を使用する論理ユニット間で成り立つ性能の依存関係も、同様に計算できる。

計算結果の論理ユニットと装置間の依存関係の例として｛ＬＵとストレージポート、ＬＵとチャネルコントローラ、ＬＵとキャッシュ、ＬＵとディスクコントローラ、ＬＵとＲＡＩＤグループ、論理ボリュームとストレージポート、論理ボリュームとチャネルコントローラ、論理ボリュームとキャッシュ、論理ボリュームとディスクコントローラ、論理ボリュームとＲＡＩＤグループ、ボリュームとホストポート、ボリュームとＳＡＮスイッチポート、ボリュームとＣＰＵ、ボリュームとメモリ、ボリュームとストレージポート、ボリュームとチャネルコントローラ、ボリュームとキャッシュ、ボリュームとディスクコントローラ、ボリュームとＲＡＩＤグループ、ファイルシステムとＣＰＵ、ファイルシステムとメモリ、ファイルシステムとホストポート、ファイルシステムとＳＡＮスイッチポート、ファイルシステムとストレージポート、ファイルシステムとチャネルコントローラ、ファイルシステムとキャッシュ、ファイルシステムとディスクコントローラ、ファイルシステムとＲＡＩＤグループ｝を含む。

図２９は、論理ユニット・アプリケーション間関連テーブルの構造を示す説明図である。図２９に示すテーブルは、論理ユニット・アプリケーション間関連テーブル２６０３（図２６参照）の構造の一例を示している。論理ユニット・アプリケーション間関連テーブル２６０３は、監視エージェントが収集した装置、論理ユニット、アプリケーション間の関連情報を結合し、論理ユニットとアプリケーション間に成り立つ性能の依存関係を纏めたテーブルであり、論理ユニット種別の識別情報を格納する論理ユニット種別欄２９００、論理ユニット名の識別情報を格納する論理ユニット名欄２９０１、当該論理ユニットの所属先ハードウェアの識別情報を格納する所属先欄２９０２、当該論理ユニットと性能の依存関係があるアプリケーション名の識別情報を格納するアプリケーション名欄２９０３、当該アプリケーションが稼動するサーバの識別情報を格納する所属先欄２９０４からなる。

具体的には、図３に示した性能の依存関係の例において、監視エージェントから収集した情報から、個々の論理ユニットとアプリケーションの関係を計算し、論理ユニット・アプリケーション間関連テーブル２６０３に格納する。なお、図１３にて、装置の末端であるＲＡＩＤグループから、当該ＲＡＩＤグループを使用するアプリケーションを解決する方法を示した。当該方法を用いることで、論理ユニットとアプリケーション間で成り立つ性能の依存関係も、同様に計算できる。

図３０は、実施形態２における装置性能管理ソフトの飽和兆候検出処理を示すフローチャートである。装置性能管理ソフト１８１の飽和兆候検出処理Ｓ２３６Ａのフローチャートは、装置の使用率と、当該装置と性能の依存関係がある論理ユニット毎に計測したレスポンスタイムとの相関分析を行うように修正した処理である。当該フローチャートについて説明する。

初めに、ステップＳ３００１にて、装置と論理ユニット間で性能情報の変化の相関を分析する期間を決定する。期間は、現在時刻から特定の時間だけ遡った時刻までの範囲としてもよいし、管理者が画面や設定ファイルなどで決定した時間範囲としてもよい。

次に、ステップＳ３００２にて、装置一覧テーブル１００１（図１１参照）から、飽和兆候検出対象とする装置一覧を取得する。装置一覧テーブル１００１の飽和兆候検出対象欄１１０４のように、装置毎に飽和兆候検出対象とするか否かを設定可能な欄があれば、飽和兆候検出対象と指定された装置を抜き出す処理に相当する。

次に、ステップＳ３００３〜ステップＳ３０１２まで、ステップＳ３００２にて取得した装置の各々についてループ処理を行う。

ステップＳ３００４では、当該装置と性能の依存関係がある論理ユニット一覧を、装置・論理ユニット間関連テーブル２６０２（図２８参照）を使って絞り込み、取得する。ステップＳ３００５では、ステップＳ３００１で決定した期間内の、当該装置の性能情報を、性能情報記憶テーブル１４０２（図１５参照）から取得する。次に、ステップＳ３００６〜ステップＳ３００９まで、ステップＳ３００５にて取得した論理ユニットの各々についてループ処理を行う。

ステップＳ３００７では、ステップＳ３００１で決定した期間内の、当該論理ユニットの性能情報を、性能情報記憶テーブル１４０２から取得する。ステップＳ３００８では、ステップＳ３００５で取得した当該装置の性能情報と、ステップＳ３００７で取得した当該論理ユニットの性能情報との間で相関係数Ｒを計測し、｛当該装置の識別情報、当該論理ユニットの識別情報、ステップＳ３００１で決定した期間情報、相関係数Ｒ｝の組を、装置性能管理ソフト１８１の飽和兆候情報２３７の相関係数演算結果テーブル２００１（図２１参照）に保存する。ここでは、相関係数演算結果テーブル２００１のアプリケーション名欄２１０３を論理ユニット識別情報格納欄とみなせばよい。同様に、アプリケーションが稼動するホストサーバ識別情報格納欄を、論理ユニットが所属するハードウェア識別情報格納欄とみなせばよい。ステップＳ３００９は、論理ユニットに関するループの終了である。

ステップＳ３０１０では、ステップＳ３００８で保存した、装置と論理ユニットとの間の性能情報の相関係数Ｒを当該装置の飽和度を表す指標として用い、装置が飽和兆候を示したか否かを判定する。装置が飽和兆候を示したと判定（検出）した場合には（ステップＳ３０１０，Ｙｅｓ）、ステップＳ３０１１に処理ステップを進める。装置が飽和兆候を示したと判定（検出）しなかった場合には（ステップＳ３０１０，Ｎｏ）、ステップＳ３０１２に処理ステップを進める。

ステップＳ３０１１では、｛飽和兆候を示したと判定した装置の識別情報、ステップＳ３００１で決定した期間情報｝の組を、装置性能管理ソフト１８１の飽和兆候情報２３７の飽和兆候情報テーブル２００２（図２２参照）に保存する。ステップＳ３０１２は、装置に関するループの終了である。

図３０に示すフローチャートでも、装置の性能情報として図１７に示すフローチャートの説明と同様に装置の使用率を用いる。また、論理ユニットの性能値として、論理ユニットが装置から受け取るサービスレベルとしてのレスポンスタイムを使用する。装置の使用率と論理ユニットのレスポンスタイム間で行う相関係数の演算方法も、図１７と同様である。１つまたは複数の論理ユニットが装置を利用する場合に、当該装置が飽和したか否かを決定する方法のバリエーションも図１７にて説明した内容と同様である。

図３１は、実施形態２における相関係数演算結果テーブルの構造を示す説明図である。図３１に示す相関係数演算結果テーブル２００１Ａは、装置性能管理ソフト１８１の飽和兆候情報２３７に含まれる相関係数演算結果テーブル２００１（図２１参照）を、アプリケーションの代替として論理ユニットを用いる場合のために修正した例である。相関係数演算結果テーブル２００１Ａは、装置種別の識別情報を格納する装置種別欄３１００、装置名の識別情報を格納する装置名欄３１０１、当該装置の所属先ハードウェアの識別情報を格納する所属先欄３１０２、当該装置と性能の依存関係を有する論理ユニット種別の識別情報を格納する論理ユニット種別欄３１０３、論理ユニット名の識別情報を格納する論理ユニット名欄３１０４、当該論理ユニットの所属先ハードウェアの識別情報を格納する所属先欄３１０５を備え、続いて、期間情報の格納のための開始時刻を格納する開始時刻欄３１０６と終了時刻を格納する終了時刻欄３１０７、相関係数を格納する相関係数欄３１０８を備える。図３０のフローチャートのステップＳ３００８では、図３１で示した構造を備える相関係数演算結果テーブル２００１Ａに、演算した相関係数を格納すればよい。

具体的には、図３で示した性能の依存関係の例において、チャネルコントローラＡ（３３９）とＬＵ−Ａ（３３５）の相関係数を、開始時刻２００７年１月２２日１０：００：００から終了時刻２００７年１月２２日１２：００：００までの２時間の相関係数計算期間において計算し、相関係数が０．５６であることがわかる。

図３２は、実施形態２における装置性能管理ソフトの飽和兆候情報出力処理が出力する画面例を示す説明図である。図３２は図２３と比較して、装置性能管理ソフト１８１の飽和兆候情報出力処理Ｓ２３８が出力する画面例を、アプリケーションの代替に論理ユニットを使って装置の性能飽和兆候を検出する場合に修正した例である。図３２の画面３２０１は、１つの表を含み、当該表は、飽和兆候を検出した装置種別の識別情報の表示する装置種別列３２０２、当該装置名の識別情報の表示する装置名列３２０３、当該装置が所属するハードウェアの識別情報を表示する装置所属列３２０４、当該装置の使用率を表示する使用率列３２０５、当該装置と性能の依存関係がある論理ユニット種別の識別情報を表示する論理ユニット種別列３２０６、当該論理ユニット名の識別情報を表示する論理ユニット名列３２０７、当該論理ユニットが所属するハードウェアの識別情報を表示する論理ユニット所属先列３２０８、当該論理ユニットのレスポンスタイムを表示するレスポンスタイム列３２０９、当該装置と当該論理ユニットとの間の性能情報の相関係数を表示する相関係数列３２１０、相関係数計算を行った期間を示す、期間の開始日時情報を表示する開始日時列３２１１と終了日時情報を表示する終了日時列３２１２、当該論理ユニットを用いるアプリケーション名の識別情報を表示する関連アプリケーション名列３２１３、当該アプリケーションが稼動するホストサーバの識別情報を表示するアプリケーション稼動サーバ列３２１４、相関係数の演算に用いた性能情報の詳細を表示する画面を表示するボタンを表示するレポート列３１１５および当該ボタン３２１６からなる。列３２０２〜列３２１５の全ての列を画面表示することは、必ずしも必要としない。

図３３は、実施形態２における装置性能管理ソフトの飽和兆候情報出力処理を示すフローチャートである。飽和兆候情報出力処理Ｓ２３８Ａは、図３３は図２４と比較して、装置性能管理ソフト１８１の飽和兆候情報出力処理Ｓ２３８のフローチャート例を、アプリケーションの代替として論理ユニットを用いるように修正した例である。飽和兆候情報出力処理Ｓ２３８Ａは、ステップＳ３３０１にて飽和兆候情報テーブル２００２をスキャンし、ステップＳ３３０２〜ステップＳ３３１３にて、飽和兆候情報テーブル２００２の各行についてループ処理を行う。

当該ループ処理の中では、まずステップＳ３３０３にて、飽和兆候情報テーブル２００２（図２２参照）から検索した｛装置種別欄２２００、装置名欄２２０１、所属先欄２２０２、開始時刻欄２２０３、終了時刻欄２２０４｝の値をキーに性能情報記憶テーブル１４０２（図１５参照）を検索し、性能値欄１５０４より、当該装置の使用率を取得する。次に、ステップＳ３３０４にて、ステップＳ３３０１〜ステップＳ３３０３で取得した、｛装置種別、装置名、所属先、使用率｝の各値を、図３２の列３２０２〜３２０５の値として表示する。開始時刻と終了時刻によって表される期間内に複数の時刻の使用率がある場合で、かつ、画面表示範囲の都合により当該期間内の全時刻の使用率を表示できない場合、取得した使用率を一つまたは複数の値に丸め込み、表示してもよい。この時、当該期間における平均値を表示してもよいし、期間の最後の値を表示してもよいし、期間内の最大値を表示してもよい。本実施形態は、表示内容を制限するものではない。

次にステップＳ３３０５にて、｛装置種別欄２２００、装置名欄２２０１、所属先欄２２０２、開始時刻欄２２０３、終了時刻欄２２０４｝の値をキーに、図３１で示した構造の相関係数演算結果テーブル２００１Ａを検索し、｛論理ユニット種別欄３１０３、論理ユニット名欄３１０４、所属先欄３１０５、相関係数欄３１０８｝の値の一覧を取得する。次にステップＳ３３０６〜ステップＳ３３１２まで、取得した論理ユニットに関する一覧情報の各々についてループ処理を行う。

ステップＳ３３０７では、｛論理ユニット種別欄３１０３、論理ユニット名欄３１０４、所属先欄３１０５、開始時刻欄２００３、終了時刻欄２００４｝の値をキーに性能情報記憶テーブル１４０２を検索し、性能値欄１５０４より、当該論理ユニットのレスポンスタイムを取得する。次にステップＳ３３０８にて、ステップＳ３３０４〜ステップＳ３３０７で取得した、｛論理ユニット種別、論理ユニット名、所属先、レスポンスタイム、相関係数｝およびステップＳ３３０１で決定した｛開始時刻、終了時刻｝の各値を、図３２の列３２０６〜３２１２の値として表示する。レスポンスタイムも、装置の使用率の場合と同様に、画面表示範囲の都合により当該期間内の全時刻の使用率を表示できない場合、取得した使用率を一つまたは複数の値に丸め込み、表示してもよい。

次に、ステップＳ３３０９にて、｛論理ユニット種別、論理ユニット名、所属先｝列の値をキーに、論理ユニット・アプリケーション間関連テーブル２６０３を検索し、｛アプリケーション名欄２９０３、アプリケーションが稼動する所属先欄２９０４｝の一覧を取得する。次にステップＳ３３１０にて、ステップＳ３３０９で取得した｛アプリケーション名欄２９０３、アプリケーションが稼動する所属先欄２９０４｝の各組を、図３２の各列３２１３〜３２１４の値として表示する。ステップＳ３３１１では、装置および論理ユニットの組み合わせ毎に相関係数計算に用いた性能情報の詳細情報を表示するボタンを、図３２の列３２１５の要素と３２１６として表示する。

図３４は、実施形態２における装置性能管理ソフトの飽和兆候情報出力処理が、相関係数を計算する際に用いた性能値の詳細情報を出力する画面例を示す説明図である。図３４は図２５と比較して、装置性能管理ソフト１８１の飽和兆候情報出力処理Ｓ２３８が、相関係数を計算する際に用いた性能値の詳細情報を出力する画面例を、アプリケーションの代替として論理ユニットを用いる場合に修正した例である。図３４の画面３４０１は、１つのグラフ３４０２を含み、当該グラフの横軸３４０５は時間軸を表し、一方の縦軸３４０３には論理ユニットのレスポンスタイムを、もう一方の縦軸３４０４には装置の使用率を表す。グラフ３４０２は凡例３４０６を有してもよく、当該凡例では、論理ユニットおよび装置の識別情報と、必要があれば性能情報の種別も表示する。当該グラフの内容は表形式で表してもよい。また、図３４のグラフ３４０２を、図３２の画面３２０１内で表示してもよい。

本実施形態の装置性能管理方法は、１つ以上の装置および該装置と性能の依存関係がある１つ以上のアプリケーションを備えるシステムにおける装置性能を管理する性能管理サーバ１５１が、装置、該装置を抽象化した論理的存在である論理ユニット、およびアプリケーションの構成情報、ならびに、装置、論理ユニット、およびアプリケーションの間に成り立つ性能の依存関係の構成情報を収集する構成情報収集処理Ｓ２３３と、装置、論理ユニット、およびアプリケーションの性能情報を収集する性能情報収集処理Ｓ２３１と、構成情報と性能情報とに基づいて装置の飽和兆候を検出する性能飽和兆候検出ステップＳ２３６と、装置が飽和兆候ありと検出されたとき、飽和兆候ありとされた装置の飽和兆候関連情報を、性能を管理する管理クライアントに告知する飽和兆候情報出力処理Ｓ２３８を含んで実行することを特徴とする。これにより、将来アプリケーションに性能問題を引き起こす可能性が高い装置、または、現在アプリケーションに性能問題を引き起こしている可能性が高い装置を検出することができる。

飽和兆候検出処理Ｓ２３６は、装置の性能情報と、装置と性能の依存関係がある論理ユニットの性能情報の時間変化値に対して所定期間について相関分析し、相関分析により得られた相関係数が所定の閾値以上のとき、装置が飽和兆候ありと検出することが好ましい。

また、飽和兆候検出処理２３６は、装置の性能情報と、アプリケーションの性能情報の時間変化値に対して所定期間について相関分析し、相関分析により得られた相関係数が所定の閾値以上のとき、装置が飽和兆候ありと検出してもよい。

本発明の全体構成を示すブロック図である。 本発明の各処理および各情報を示すブロック図である。 装置・論理ユニット・装置上で稼動するアプリケーション間に成り立つ性能の依存関係の例を示す説明図である。 各監視エージェントの構成情報に含まれるテーブルを示す説明図である。 アプリケーション・ファイルシステム間関連テーブルの構造を示す説明図である。 ファイルシステム・ボリューム間関連テーブルの構造を示す説明図である。 ボリューム・ＬＵ・ホストポート間関連テーブルの構造を示す説明図である。 ホストポート・ストレージポート間通信経路テーブルの構造を示す説明図である。 ＬＵ・ストレージサブシステム内要素間関連テーブルの構造を示す説明図である。 実施形態１における装置性能管理ソフトの構成情報に含まれるテーブルを示す構成図である。 装置一覧テーブルの構造を示す説明図である。 アプリケーション一覧テーブルの構造を示す説明図である。 装置・アプリケーション間関連テーブルの構造を示す説明図である。 監視エージェントの性能情報および装置性能管理ソフトの性能情報に含まれるテーブルの構造を示す説明図である。 性能情報記憶テーブルの構造を示す説明図である。 管理対象装置群の中から飽和兆候検出対象を決定するための画面例と決定された内容に応じての関連テーブル内容を示す説明図である。 実施形態１における装置性能管理ソフトの飽和兆候検出処理を示すフローチャートである。 装置の使用率と、当該装置を利用するアプリケーションが装置に処理要求を出した場合のレスポンスタイムの間に成り立つ関係を示す説明図である。 装置の使用率と、当該装置を利用するアプリケーションが装置に処理要求を出した場合のレスポンスタイムとの間で、変化値の正負による相関分析を行う例を示す説明図である。 装置性能管理ソフトの飽和兆候情報に含まれるテーブルを示す構成図である。 実施形態１における相関係数演算結果テーブルの構造を示す説明図である。 飽和兆候情報テーブルの構造を示す説明図である。 実施形態１における装置性能管理ソフトの飽和兆候情報出力処理が出力する画面例を示す説明図である。 実施形態１における装置性能管理ソフトの飽和兆候情報出力処理を示すフローチャートである。 実施形態１における装置性能管理ソフトの飽和兆候情報出力処理が、相関係数を計算する際に用いた性能値の詳細情報を出力する画面例を示す説明図である。 実施形態２における装置性能管理ソフトの構成情報に含まれるテーブルを示す構成図である。 論理ユニット一覧テーブルの構造を示す説明図である。 装置・論理ユニット間関連テーブルの構造を示す説明図である。 論理ユニット・アプリケーション間関連テーブルの構造を示す説明図である。 実施形態２における装置性能管理ソフトの飽和兆候検出処理を示すフローチャートである。 実施形態２における相関係数演算結果テーブルの構造を示す説明図である。 実施形態２における装置性能管理ソフトの飽和兆候情報出力処理が出力する画面例を示す説明図である。 実施形態２における装置性能管理ソフトの飽和兆候情報出力処理を示すフローチャートである。 実施形態２における装置性能管理ソフトの飽和兆候情報出力処理が、相関係数を計算する際に用いた性能値の詳細情報を出力する画面例を示す説明図である。 構成情報および性能情報を取得、保存する監視エージェントの処理を示すフローチャートである。 監視エージェントの構成情報収集処理の詳細を示すフローチャートである。 監視エージェントの性能情報収集処理の詳細を示すフローチャートの例である。 装置性能管理ソフトの飽和兆候検出処理の主処理を示すフローチャートである。

符号の説明

１０１，１０２，１０３ 業務クライアント
１１１，１１２ ホストサーバ
１１３ ＯＳ
１１４ ファイルシステム
１１５ アプリケーション
１１６ ＣＰＵ
１１７ メモリ
１１８，１１９，１４２ ホストポート
１２１，１２２ ＳＡＮスイッチ
１２３，１２４，１２５，１２６ ＳＡＮスイッチポート
１３１，１３２ ストレージサブシステム
１３３，１３４ ストレージサブシステムポート
１４１ 情報収集サーバ
１５１ 性能管理サーバ
１６１ 性能管理クライアント
１７１ アプリケーション監視エージェント
１７２ ホスト監視エージェント
１７３ ファブリック監視エージェント
１７４ ストレージサブシステム監視エージェント
１８１ 装置性能管理ソフト
２０１，２０２，２０３ 装置
２１１，２１２，２１３ アプリケーション
２１４ ログ
２２１，２２２，２２３ 監視エージェント
２２５，２３２ 性能情報
２２８，２３４ 構成情報
２３７ 飽和兆候情報
Ｓ２０４ 性能情報取得処理
Ｓ２０５ 構成情報取得処理
Ｓ２１５ 構成情報取得処理
Ｓ２２４ 性能情報収集処理
Ｓ２２６ 性能情報応答処理
Ｓ２２７ 構成情報収集処理
Ｓ２２９ 構成情報応答処理
Ｓ２３１ 性能情報収集処理
Ｓ２３３ 構成情報収集処理
Ｓ２３５ 飽和兆候検出対象装置設定処理
Ｓ２３６ 飽和兆候検出処理
Ｓ２３８ 飽和兆候情報出力処理

Claims (20)

1. １つ以上の装置および該装置と性能の依存関係がある１つ以上のアプリケーションを備えるシステムにおける装置性能を管理する装置性能管理方法であって、
   前記装置を管理する管理サーバが、
   前記装置の構成情報および前記アプリケーションの構成情報、ならびに、前記装置および前記アプリケーションの間に成り立つ性能の依存関係の構成情報を収集する構成情報収集処理と、
   前記装置の性能情報および前記アプリケーションの性能情報を収集する性能情報収集処理と、
   前記構成情報と前記性能情報とに基づいて前記装置の飽和兆候を検出する飽和兆候検出処理と、を含んで実行する
   ことを特徴とする装置性能管理方法。
2. １つ以上の装置および該装置と性能の依存関係がある１つ以上のアプリケーションを備えるシステムにおける装置性能を管理する装置性能管理方法であって、
   前記装置を管理する管理サーバが、
   前記装置の構成情報、該装置を抽象化した論理的存在である論理ユニットの構成情報および前記アプリケーションの構成情報、ならびに、前記装置、前記論理ユニットおよび前記アプリケーションの間に成り立つ性能の依存関係の構成情報を収集する構成情報収集処理と、
   前記装置の性能情報、前記論理ユニットの性能情報および前記アプリケーションの性能情報を収集する性能情報収集処理と、
   前記構成情報と前記性能情報とに基づいて前記装置の飽和兆候を検出する飽和兆候検出処理と、を含んで実行する
   ことを特徴とする装置性能管理方法。
3. 前記飽和兆候検出処理は、前記装置の性能情報と、前記アプリケーションの性能情報の時間変化値に対して所定期間について相関分析し、前記相関分析により得られた相関係数が所定の閾値以上のとき、前記装置が飽和兆候ありと検出する
   ことを特徴とする請求項１または請求項２に記載の装置性能管理方法。
4. 前記飽和兆候検出処理は、１つの前記装置を複数の前記アプリケーションが利用する際に、前記アプリケーション毎に前記装置の性能情報と各前記アプリケーションの性能情報の時間変化値に対して所定期間について相関分析により得られた複数の相関係数を、前記アプリケーション毎の重みに基づいて複数の前記相関係数の加重平均をする
   ことを特徴とする請求項１または請求項２に記載の装置性能管理方法。
5. 前記飽和兆候検出処理は、前記装置の性能情報と、前記装置と性能の依存関係がある前記論理ユニットの性能情報の時間変化値に対して所定期間について相関分析し、前記相関分析により得られた相関係数が所定の閾値以上のとき、前記装置が飽和兆候ありと検出する
   ことを特徴とする請求項２に記載の装置性能管理方法。
6. 前記論理ユニットは、サーバ内のファイルシステム、ストレージシステム内のロジカルユニット、ストレージシステム内の論理ボリュームの少なくともいずれかを含む
   ことを特徴とする請求項２に記載の装置性能管理方法。
7. 前記管理サーバが、前記構成情報を選択したアプリケーションで検索し、前記選択された１つ以上のアプリケーションと性能の依存関係にある装置を、前記飽和兆候検出処理の処理対象の装置として決定する処理対象装置決定処理、を含んで実行する
   ことを特徴とする請求項１または請求項２に記載の装置性能管理方法。
8. 前記管理サーバは、さらに、
   前記飽和兆候検出処理で、前記装置が飽和兆候ありと検出されたとき、飽和兆候ありとされた装置の飽和兆候に関連する飽和兆候情報を、性能を管理する管理クライアントに告知する飽和兆候情報出力処理を含んで実行する
   ことを特徴とする請求項１または請求項２に記載の装置性能管理方法。
9. 前記告知の方法は、画面、ログの少なくともいずれかの出力による方法、または、電子メール、ＳＮＭＰ（Simple Network Management Protocol）、コマンド実行の少なくともいずれかにより警告する方法である
   ことを特徴とする請求項８に記載の装置性能管理方法。
10. １つ以上の装置および該装置と性能の依存関係がある１つ以上のアプリケーションを備えるシステムにおける装置性能を管理する装置性能管理システムであって、
    前記装置の構成情報および前記アプリケーションの構成情報、ならびに、前記装置および前記アプリケーションの間に成り立つ性能の依存関係の構成情報を収集する構成情報収集手段と、
    前記装置の性能情報および前記アプリケーションの性能情報を収集する性能情報収集手段と、
    前記構成情報と前記性能情報とに基づいて前記装置の飽和兆候を検出する性能飽和兆候検出手段と、を有する
    ことを特徴とする装置性能管理システム。
11. １つ以上の装置および該装置と性能の依存関係がある１つ以上のアプリケーションを備えるシステムにおける装置性能を管理する装置性能管理システムであって、
    前記装置の構成情報、該装置を抽象化した論理的存在である論理ユニットの構成情報および前記アプリケーションの構成情報、ならびに、前記装置、前記論理ユニットおよび前記アプリケーションの間に成り立つ性能の依存関係の構成情報を収集する構成情報収集手段と、
    前記装置の性能情報、前記論理ユニットの性能情報および前記アプリケーションの性能情報を収集する性能情報収集手段と、
    前記構成情報と前記性能情報とに基づいて前記装置の飽和兆候を検出する性能飽和兆候検出手段と、を有する
    ことを特徴とする装置性能管理システム。
12. 前記性能飽和兆候検出手段は、前記装置の性能情報と、前記アプリケーションの性能情報の時間変化値に対して所定期間について相関分析し、前記相関分析により得られた相関係数が所定の閾値以上のとき、前記装置が飽和兆候ありと検出する
    ことを特徴とする請求項１０または請求項１１に記載の装置性能管理システム。
13. 前記性能飽和兆候検出手段は、１つの前記装置を複数の前記アプリケーションが利用する際に、前記アプリケーション毎に前記装置の性能情報と各前記アプリケーションの性能情報の時間変化値に対して所定期間について相関分析により得られた複数の相関係数を、前記アプリケーション毎の重みに基づいて複数の前記相関係数の加重平均をする
    ことを特徴とする請求項１０または請求項１１に記載の装置性能管理システム。
14. 前記性能飽和兆候検出手段は、前記装置の性能情報と、前記装置と性能の依存関係がある前記論理ユニットの性能情報の時間変化値に対して所定期間について相関分析し、前記相関分析により得られた相関係数が所定の閾値以上のとき、前記装置が飽和兆候ありと検出する
    ことを特徴とする請求項１１に記載の装置性能管理システム。
15. 前記論理ユニットは、サーバ内のファイルシステム、ストレージシステム内のロジカルユニット、ストレージシステム内の論理ボリュームの少なくともいずれかを含む
    ことを特徴とする請求項１１に記載の装置性能管理システム。
16. 前記構成情報を選択したアプリケーションで検索し、前記選択された１つ以上のアプリケーションと性能の依存関係にある装置を、前記性能飽和兆候検出手段の処理対象の装置として決定する処理対象装置決定手段、を有する
    ことを特徴とする請求項１０または請求項１１に記載の装置性能管理システム。
17. 前記装置性能管理システムは、さらに、
    前記性能飽和兆候検出手段で、前記装置が飽和兆候ありと検出されたとき、飽和兆候ありとされた装置の飽和兆候に関連する飽和兆候情報を、性能を管理する管理クライアントに告知する飽和兆候情報出力手段を有する
    ことを特徴とする請求項１０または請求項１１に記載の装置性能管理システム。
18. 前記飽和兆候情報出力手段は、画面、ログの少なくともいずれかの出力、または、電子メール、ＳＮＭＰ（Simple Network Management Protocol）、コマンド実行の少なくともいずれかにより警告する
    ことを特徴とする請求項１７に記載の装置性能管理システム。
19. １つ以上の装置および該装置と性能の依存関係がある１つ以上のアプリケーションを備えるシステムにおける装置性能を管理する管理プログラムであって、
    コンピュータに、
    前記装置の構成情報および前記アプリケーションの構成情報、ならびに、前記装置および前記アプリケーションの間に成り立つ性能の依存関係の構成情報を収集する構成情報収集処理と、
    前記装置の性能情報および前記アプリケーションの性能情報を収集する性能情報収集処理と、
    前記構成情報を選択したアプリケーションで検索し、前記選択された１つ以上のアプリケーションと性能の依存関係にある装置を、処理対象の装置として決定する処理対象装置決定処理と、
    前記処理対象の装置の性能情報と、前記アプリケーションの性能情報の時間変化値に対して所定期間について相関分析し、前記相関分析により得られた相関係数が所定の閾値以上のとき、前記装置が飽和兆候ありと検出する飽和兆候検出処理とを
    実行させるための管理プログラム。
20. １つ以上の装置および該装置と性能の依存関係がある１つ以上のアプリケーションを備えるシステムにおける装置性能を管理する管理プログラムであって、
    コンピュータに、
    前記装置の構成情報、該装置を抽象化した論理的存在である論理ユニットの構成情報および前記アプリケーションの構成情報、ならびに、前記装置、前記論理ユニットおよび前記アプリケーションの間に成り立つ性能の依存関係の構成情報を収集する構成情報収集処理と、
    前記装置の性能情報、前記論理ユニットの性能情報および前記アプリケーションの性能情報を収集する性能情報収集処理と、
    前記構成情報を選択したアプリケーションで検索し、前記選択された１つ以上のアプリケーションと性能の依存関係にある装置を、処理対象の装置として決定する処理対象装置決定処理と、
    前記処理対象の装置の性能情報と、前記装置と性能の依存関係がある前記論理ユニットの性能情報の時間変化値に対して所定期間について相関分析し、前記相関分析により得られた相関係数が所定の閾値以上のとき、前記装置が飽和兆候ありと検出する飽和兆候検出処理と、
    飽和兆候ありとされた装置の飽和兆候に関連する飽和兆候情報を、性能を管理する管理クライアントに告知する飽和兆候情報出力処理とを
    実行させるための管理プログラム。

Images