(57)【特許請求の範囲】
【請求項１】
計算機からアクセスされる複数の論理記憶領域を有するストレージ装置を管理する管理装置は、
前記計算機が前記複数の論理記憶領域へ均等にアクセスするという設定を判定し、前記均等にアクセスするという設定であると判定した場合、前記複数の論理記憶領域それぞれのアクセス数を取得し、前記取得した複数のアクセス数を比較することにより、問題のある論理記憶領域の存在を判定する監視モジュールと、
前記問題のある論理記憶領域が存在すると判定された場合、前記問題のある論理記憶領域に割り当てられた前記ストレージ装置の構成情報を取得し、前記取得した構成情報に基づき、前記ストレージ装置内の各構成のいずれがボトルネックであるかを特定する解析モジュールと、
前記特定されたボトルネックとなる構成を経由するアクセス経路を変更する対策案を作成する作成モジュールと、
前記作成した対策案を出力する出力モジュールとを有し、
前記作成モジュールは、
ある論理記憶領域に割り当てられた第１のポートがボトルネックであると特定された場合、前記ストレージ装置の前記計算機へ接続するポートに予め設定された第１の基準値未満の第２のポートが存在するかを判定し、前記第２のポートが存在すると判定した場合、前記第２のポートは前記均等にアクセスするという設定であると判定された複数の論理記憶領域に割り当てられているかを判定し、
前記第２のポートは、前記均等にアクセスするという設定であると判定された複数の論理記憶領域に割り当てられていないと判定した場合、前記第１のポートを前記第２のポートへ変更する対策案を作成し、
前記第２のポートは、前記均等に発行する設定と判定された複数の論理記憶領域に割り当てられていると判定した場合、前記第１のポートを前記第２のポートへ変更した場合の第１の予測値を算出し、前記算出した第１の予測値に応じて前記第１のポートを前記第２のポートへ変更する対策案を作成すること
を特徴とする管理装置。
【請求項２】
前記監視モジュールは、
前記均等に発行する設定と判定した場合、前記複数の論理記憶領域それぞれのアクセス数を取得し、前記複数の論理記憶領域それぞれにおける前記取得したアクセス数の任意期間の平均値を算出し、前記算出した複数の平均値の平均値と標準偏差を算出し、前記算出した複数の平均値の平均値から前記算出した標準偏差の予め設定された第２の基準値に収まらない論理記憶領域を、問題のある論理記憶領域とすること
を特徴とする請求項１に記載の管理装置。
【請求項３】
前記解析モジュールは、
前記ストレージ装置の前記計算機へ接続するポートの中の前記問題のある論理記憶領域に割り当てられた第１のポートのアクセス数を取得し、前記取得した第１のポートのアクセス数が予め設定された第３の基準値を超えるか判定し、前記第３の基準値を超えると判定した場合、前記第１のポートをボトルネックであると特定し、
前記ストレージ装置のプロセッサの中の前記問題のある論理記憶領域に割り当てられた第１のプロセッサの使用率を取得し、前記取得した第１のプロセッサの使用率が予め設定された第４の基準値を超えるか判定し、前記第４の基準値を超えると判定した場合、前記第１のプロセッサをボトルネックであると特定し、
前記ストレージ装置のキャッシュの中の前記問題のある論理記憶領域に割り当てられた第１のキャッシュのヒット率を取得し、前記取得した第１のキャッシュのヒット率が予め設定された第５の基準値の範囲外かを判定し、前記第５の基準値の範囲外であると判定した場合、前記第１のキャッシュをボトルネックであると特定すること
を特徴とする請求項２に記載の管理装置。
【請求項４】
前記作成モジュールは、
前記第１のプロセッサがボトルネックであると特定された場合、前記ストレージ装置のプロセッサに予め設定された第６の基準値未満の第２のプロセッサが存在するかを判定し、前記第２のプロセッサが存在すると判定した場合、前記第２のプロセッサは前記均等にアクセスするという設定であると判定された複数の論理記憶領域に割り当てられているかを判定し、
前記第２のプロセッサは、前記均等にアクセスするという設定であると判定された複数の論理記憶領域に割り当てられていないと判定した場合、前記第１のプロセッサを前記第２のプロセッサへ変更する対策案を作成し、
前記第２のプロセッサは、前記均等に発行する設定と判定された複数の論理記憶領域に割り当てられていると判定した場合、前記第１のプロセッサを前記第２のプロセッサへ変更した場合の第２の予測値を算出し、前記算出した第２の予測値に応じて前記第１のプロセッサを前記第２のプロセッサへ変更する対策案を作成すること
を特徴とする請求項３に記載の管理装置。
【請求項５】
前記作成モジュールは、
前記第１のポートと前記第１のプロセッサと前記第１のキャッシュのいずれもボトルネックでない場合、前記均等にアクセスするという設定であると判定された複数の論理記憶領域へ論理記憶領域を追加する対策案を作成すること
を特徴とする請求項４に記載の管理装置。
【請求項６】
ＣＰＵを有し、計算機からアクセスされる複数の論理記憶領域を有するストレージ装置を管理する、管理計算機の管理方法は、
前記ＣＰＵが、
前記計算機が前記複数の論理記憶領域へ均等にアクセスするという設定を判定し、
前記均等にアクセスするという設定であると判定した場合、
前記複数の論理記憶領域それぞれのアクセス数を取得し、
前記取得した複数のアクセス数を比較することにより、問題のある論理記憶領域の存在を判定し、
前記問題のある論理記憶領域が存在すると判定された場合、
前記問題のある論理記憶領域に割り当てられた前記ストレージ装置の構成情報を取得し、
前記取得した構成情報に基づき、前記ストレージ装置内の各構成のいずれがボトルネックであるかを特定し、
前記ＣＰＵが、
ある論理記憶領域に割り当てられた第１のポートがボトルネックであると特定された場合、前記ストレージ装置の前記計算機へ接続するポートに予め設定された第１の基準値未満の第２のポートが存在するかを判定し、
前記第２のポートが存在すると判定した場合、前記第２のポートは前記均等に発行する設定と判定された複数の論理記憶領域に割り当てられているかを判定し、
前記第２のポートは、前記均等にアクセスするという設定であると判定された複数の論理記憶領域に割り当てられていないと判定した場合、前記第１のポートを前記第２のポートへ変更する対策案を作成し、
前記第２のポートは、前記均等にアクセスするという設定であると判定された複数の論理記憶領域に割り当てられていると判定した場合、前記第１のポートを前記第２のポートへ変更した場合の第１の予測値を算出し、前記算出した第１の予測値に応じて前記第１のポートを前記第２のポートへ変更する対策案を作成し、前記作成した対策案を出力すること
を特徴とする管理方法。
【請求項７】
前記ＣＰＵが、
前記均等にアクセスするという設定であると判定した場合、前記複数の論理記憶領域それぞれのアクセス数を取得し、
前記複数の論理記憶領域それぞれにおける前記取得したアクセス数の任意期間の平均値を算出し、前記算出した複数の平均値の平均値と標準偏差を算出し、
前記算出した複数の平均値の平均値から前記算出した標準偏差の予め設定された第２の基準値に収まらない論理記憶領域を、問題のある論理記憶領域とすること
を特徴とする請求項６に記載の管理方法。
【請求項８】
前記ＣＰＵが、
前記ストレージ装置の前記計算機へ接続するポートの中の前記問題のある論理記憶領域に割り当てられた第１のポートのアクセス数を取得し、
前記取得した第１のポートのアクセス数が予め設定された第３の基準値を超えるか判定し、
前記第３の基準値を超えると判定した場合、前記第１のポートをボトルネックであると特定し、
前記ストレージ装置のプロセッサの中の前記問題のある論理記憶領域に割り当てられた第１のプロセッサの使用率を取得し、
前記取得した第１のプロセッサの使用率が予め設定された第４の基準値を超えるか判定し、前記第４の基準値を超えると判定した場合、前記第１のプロセッサをボトルネックであると特定し、
前記ストレージ装置のキャッシュの中の前記問題のある論理記憶領域に割り当てられた第１のキャッシュのヒット率を取得し、
前記取得した第１のキャッシュのヒット率が予め設定された第５の基準値の範囲外かを判定し、前記第５の基準値の範囲外であると判定した場合、前記第１のキャッシュをボトルネックであると特定すること
を特徴とする請求項７に記載の管理方法。
【請求項９】
前記ＣＰＵが、
前記第１のプロセッサがボトルネックであると特定された場合、前記ストレージ装置のプロセッサに予め設定された第６の基準値未満の第２のプロセッサが存在するかを判定し、
前記第２のプロセッサが存在すると判定した場合、
前記第２のプロセッサは前記均等にアクセスするという設定であると判定された複数の論理記憶領域に割り当てられているかを判定し、
前記第２のプロセッサは、前記均等にアクセスするという設定であると判定された複数の論理記憶領域に割り当てられていないと判定した場合、前記第１のプロセッサを前記第２のプロセッサへ変更する対策案を作成し、
前記第２のプロセッサは、前記均等にアクセスするという設定であると判定された複数の論理記憶領域に割り当てられていると判定した場合、前記第１のプロセッサを前記第２のプロセッサへ変更した場合の第２の予測値を算出し、前記算出した第２の予測値に応じて前記第１のプロセッサを前記第２のプロセッサへ変更する対策案を作成すること
を特徴とする請求項８に記載の管理方法。
【請求項１０】
前記ＣＰＵが、
前記第１のポートと前記第１のプロセッサと前記第１のキャッシュのいずれもボトルネックでない場合、前記均等にアクセスするという設定であると判定された複数の論理記憶領域へ論理記憶領域を追加する対策案を作成すること
を特徴とする請求項９に記載の管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は管理装置および管理方法に関するものである。
【背景技術】
【０００２】
データベース管理システムやアプリケーションサーバなどにおいて実行されるミドルウェアやアプリケーションプログラムには、データを安全かつ高速にアクセスできるようにストレージ装置のデータ配置を管理するものがある。例えば、複数の記憶デバイスへデータを分散配置し、IO（Input/Output：例えば読み書き命令あるいはアクセス）を均等に分散することにより、複数の記憶デバイスの並列実行度を上げて高速化するものもある。【０００３】
一方ストレージ装置でも、記憶デバイスを論理化してアプリケーションプログラムに認識させ、データへのアクセス頻度によって性能の異なる記憶デバイスに配置する階層管理など、同様に高速性を高めるためのデータ管理を行っている。【０００４】
特許文献１にはアプリケーションプログラムの重要度と使用時間帯に従ってストレージ装置とアプリケーションサーバ間のIOパスの割り当てを行う技術が示されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特許第４６８６３０５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
特許文献１に示された技術を用いれば、アプリケーションプログラムに応じたIOパスを割り当てることができる。しかしながら、アプリケーションプログラムの均等に分散するIOに対し、記憶デバイスを論理化するストレージ装置が均等に処理することを保証するものではない。ストレージ装置内にボトルネックが発生すると、均等に分散されたIOの一部が遅れるだけではなく、均等に分散したIOに基づく処理はその一部の遅れの影響により全体として遅れが生じてしまう。【０００７】
また、アプリケーション側の管理者にとってストレージ装置内のどの部分がボトルネックとなり、均等に処理できないかを判断することは難しく、その判断には多大な労力が必要となる。【０００８】
そこで、本発明は、ストレージ装置の一部のボトルネックによる性能問題が発生した場合、管理者へそのボトルネックの対策案を提示することを目的とする。
【課題を解決するための手段】
【０００９】
本発明に係る代表的な管理装置は、計算機からアクセスされる複数の論理記憶領域を有するストレージ装置を管理する管理装置は、前記計算機が前記複数の論理記憶領域へ均等にアクセスするという設定を判定し、前記均等にアクセスするという設定であると判定した場合、前記複数の論理記憶領域それぞれのアクセス数を取得し、前記取得した複数のアクセス数を比較することにより、問題のある論理記憶領域の存在を判定する監視モジュールと、前記問題のある論理記憶領域が存在すると判定された場合、前記問題のある論理記憶領域に割り当てられた前記ストレージ装置の構成情報を取得し、前記取得した構成情報に基づき、前記ストレージ装置内の各構成のいずれがボトルネックであるかを特定する解析モジュールと、前記特定されたボトルネックとなる構成を経由するアクセス経路を変更する対策案を作成する作成モジュールと、前記作成した対策案を出力する出力モジュールとを有することを特徴とする。
【発明の効果】
【００１０】
本発明によれば、ストレージ装置の一部のボトルネックによる性能問題が発生しても、管理者へそのボトルネックの対策案を提示することができる。
【図面の簡単な説明】
【００１１】
【図１】システムの構成の例を示す図である。
【図２】管理サーバの構成の例を示す図である。
【図３】ストレージ装置の構成の例を示す図である。
【図４】管理サーバの処理モジュールの構成の例を示す図である。
【図５】処理全体の例を示すフローチャート図である。
【図６】IO監視処理の例を示すフローチャート図である。
【図７】ボトルネック解析処理の例を示すフローチャート図である。
【図８】ポートボトルネックの対策案作成処理の例を示すフローチャート図である。
【図９】プロセッサボトルネックの対策案作成処理の例を示すフローチャート図である。
【図１０】追加ボリューム切り出し案作成処理の例を示すフローチャート図である。
【図１１】AP構成情報管理テーブルの例を示す図である。
【図１２】ストレージ構成情報管理テーブルの例を示す図である。
【図１３Ａ】ボリュームに関するストレージ性能情報管理テーブルの例を示す図である。
【図１３Ｂ】プロセッサに関するストレージ性能情報管理テーブルの例を示す図である。
【図１３Ｃ】ポートに関するストレージ性能情報管理テーブルの例を示す図である。
【図１３Ｄ】キャッシュに関するストレージ性能情報管理テーブルの例を示す図である。
【図１４】対策案提示のGUI画面の例を示す図である。
【図１５】ボリューム移行案作成処理の例を示すフローチャート図である。
【図１６】AP性能情報管理テーブルの例を示す図である。
【発明を実施するための形態】
【実施例１】
【００１２】
図１はシステムの構成の例を示す図である。この例のシステムは、ストレージ装置１０３を管理する管理サーバ１０１と、アプリケーションプログラム１０６を実行するアプリケーションサーバ１０２、アプリケーションプログラム１０６のデータを保存するストレージ装置１０３から構成される。アプリケーションサーバ１０２とストレージ装置１０３との間はIP（Internet Protocol）またはファイバーチャネルなどのストレージエリアネットワーク（SAN）１０４で接続される。またアプリケーションサーバ１０２およびストレージ装置１０３は管理用ネットワーク１０５により管理サーバ１０１と接続される。【００１３】
ストレージ装置１０３は、複数の物理的な記憶デバイス１１２をRAID（Redundant Arrays of Inexpensive Disks）によりまとめて管理し、パリティグループ１１１を構成する。パリティグループ１１１の中では複数の物理的な記憶デバイス１１２をまたぐように記憶領域が論理化された論理ユニット１１３が設定される。論理ユニット１１３は論理デバイスなどと呼ばれることもある。論理ユニット１１３はアプリケーションサーバ１０２から読み書き時に指定されるひとまとまりの記憶領域であり、アプリケーションプログラム１０６からは論理ボリューム（以下、単にボリュームと呼ぶ）１０８として認識される。【００１４】
なお、図１の例において、論理ユニット（＃１）の＃１などは複数の論理ユニット１１３を個別に識別するためのID（識別子）であり、論理ユニット１１３以外のものの表記も同じである。また、この例ではボリューム１０８と論理ユニット１１３とは１対１に対応するため、論理ユニット１１３の代わりにボリューム１０８と表現することもある。【００１５】
ストレージ装置１０３は、アプリケーションサーバ１０２からの読み書きを可能にするため、ストレージエリアネットワーク１０４と接続してアプリケーションサーバ１０２と通信するポート１０９を備え、パーティショングループ１１１や論理ユニット１１３を管理し、ポート１０９による通信を記憶デバイス１１２への読み書きに変換するMPB（Micro Processor Blade）１１０を備える。MPB１１０には複数のマイクロプロセッサが搭載される。ストレージ装置１０３の構成については後でさらに説明する。【００１６】
アプリケーションサーバ１０２は一般的なサーバすなわちコンピュータであり、アプリケーションプログラム１０６を実行する。アプリケーションプログラム１０６は、記憶域グループ１０７として一つ以上のボリューム１０８をグループとして管理する。記憶域グループ１０７は例えば同じような特性（性能）のボリューム１０８により構成される。このため、アプリケーションプログラム１０６は、アプリケーション処理においてデータに要求される性能などに応じて、各記憶域グループ１０７を使い分けることができる。なお、アプリケーションプログラム１０６は、ミドルウェアであってもよく、データベースのプログラムであってもよい。【００１７】
アプリケーションプログラム１０６は、その実行中にストレージ装置１０３へのデータの読み書きが発生すると、記憶域グループ１０７を介してボリューム１０８へアクセスする。ボリューム１０８は論理ボリュームであって実体がないため、アプリケーションサーバ１０２はボリューム１０８へのアクセスを、ストレージエリアネットワーク１０４経由のストレージ装置１０３へのアクセスとする。このアクセスをストレージ装置１０３はポート１０９で受け、MPB１１０が実体である記憶デバイス１１２により構成されるパリティグループ１１１内の論理ユニット１１３へのアクセスに変換する。このアクセスのパスを図１では点線の矢印で示す。【００１８】
多数のボリューム１０８が存在する場合、各ボリューム１０８へ物理的なポート１０９やMPB１１０をそれぞれ割り当てるには多量のハードウェアリソースが必要となるため、図１にも示すように、１個のポート１０９や１個のMPB１１０が複数のボリューム１０８に割り当てられてもよい。図１の例では、ポート１０９の＃２は２個のボリューム１０８が割り当てられ、MPB１１０の＃１は２個の論理ユニット１１３が割り当てられる。これらの割り当ては各部の負荷（性能）に影響を与える。【００１９】
ストレージエリアネットワーク１０４がアプリケーションプログラム１０６の読み書きするデータを通信するためのものであるのに対し、管理用ネットワーク１０５は管理用の情報を通信するためのものである。管理サーバ１０１は管理用ネットワーク１０５を介してアプリケーションサーバ１０２やストレージ装置１０３から性能情報などを受信し、アプリケーションサーバ１０２やストレージ装置１０３へ情報を設定する。【００２０】
図２は管理サーバ１０１の構成の例を示す図である。管理サーバ１０１のハードウェアは、１個以上のCPU（中央処理装置）２０１、メモリ２０２、ハードディスクなどの二次記憶装置２０３、キーボード、マウスからの入力とディスプレイへの出力情報を制御する入出力I/F（インタフェース）２０４、ネットワークに接続するネットワークI/F２０５から構成される。アプリケーションサーバ１０２のハードウェア構成も同様である。【００２１】
管理サーバ１０１のメモリ２０２上にはストレージ管理プログラム２０６がロードされ、CPU２０１により実行される。また二次記憶装置２０３にはストレージ管理プログラム２０６が使用する管理テーブル２０７のデータが保存される。アプリケーションサーバ１０２ではアプリケーションプログラム１０６がメモリ上にロードされ、CPUにより実行される。なお、各サーバは物理マシンでなく仮想マシンとして実装されてもよい。【００２２】
図３はストレージ装置１０３のハードウェア構成の例を示す図である。コントローラ３０１は、フロントエンド側にアプリケーションサーバ１０２などのホスト計算機との接続インタフェースであるホストI/F３０２、バックエンド側に記憶メディアとの接続インタフェースであるメディアI/F３０３、一つ以上のプロセッサ３０４、キャッシュメモリ３０５から構成され、それぞれが内部ネットワークで相互接続される。【００２３】
記憶メディアとしてはハードディスクなどの記憶デバイス１１２が接続される。プロセッサ３０４は複数の同種の記憶メディア（記憶デバイス１１２）の組で構成された論理記憶領域（パリティグループ１１１）を設定する。各パリティグループ１１１は異なる特性を備えてもよい。特性とは例えば、記憶デバイス１１２の記憶素子の違いやインタフェースの違い、RAIDレベルの違いであり、これらの違いにより性能が異なる。このため、設定されたパリティグループ１１１はその特性とともに管理され、性能レベルとして例えば高・中・低の３段階を設けて管理される。【００２４】
ホストI/F３０２はポート１０９を備える。ストレージ装置１０３は１個以上のホストI/F３０２を備えてよく、１個のホストI/F３０２は１個以上のポート１０９を備えてもよい。プロセッサ３０４はMPB１１０を構成するものであり、ストレージ装置１０３は１個以上のMPB１１０を備えてよく、１個のMPB１１０は１個以上のプロセッサ３０４を備えてもよい。【００２５】
図４は管理サーバ１０１の処理モジュールの構成の例を示す図である。APサーバ（アプリケーションサーバ）１０２から構成情報と性能情報を収集するAPサーバ情報収集部４０１、ストレージ装置１０３の構成情報と性能情報を収集するストレージ情報収集部４０２、ディスクIO数やIO応答時間などのIO性能を監視するIO性能監視部４０７、IO性能に問題がある場合に解析を行うボトルネック解析部４０８、ボトルネックに対する対策案を作成する対策案作成部４０９、性能問題とその対策に関する情報を出力する対策情報出力部４１０とUI（ユーザインタフェース）４１１から構成される。【００２６】
これら各部（各モジュール）はCPU２０１がストレージ管理プログラム２０６を実行することにより実現されてもよい。例えば、ストレージ管理プログラム２０６の中のAPサーバ情報収集の部分（プログラムモジュール）をCPU２０１が実行している状態において、CPU２０１とメモリ２０２はAPサーバ情報収集部４０１（ハードウェアモジュール）と見なされてよい。このため、以下での各部を主語とする説明は、CPU２０１を主語とする説明に置き換えてもよい。【００２７】
また、収集した構成情報、性能情報をそれぞれ管理するテーブルとして、AP構成情報管理テーブル４０３、AP性能情報監視テーブル４０４、ストレージ構成情報管理テーブル４０５、ストレージ性能情報管理テーブル４０６を、管理サーバ１０１は保持する。これらのテーブルは二次記憶装置２０３の管理テーブル２０７に含まれてもよい。【００２８】
図５は処理全体の例を示すフローチャート図である。APサーバ情報収集部４０１とストレージ情報収集部４０２のそれぞれは、アプリケーションサーバ１０２とストレージ装置１０３の構成情報と性能情報を定期的に収集する（S501）。構成情報と性能情報の収集間隔は異なる。APサーバ情報収集部４０１とストレージ情報収集部４０２により、構成情報は定期的な収集と構成変更時の不定期な収集が行われるのに対し、性能情報は分間隔で収集が行われる。【００２９】
ここで収集される性能情報は、アプリケーションサーバ１０２側ではストレージ装置１０３の読み書きを行う回数、読み書き量、応答時間であり、ストレージ装置１０３側ではボリューム１０８（論理ユニット１１３）への読み書きについて回数、データ量、応答時間である。【００３０】
次に収集する性能情報について、IO性能監視部４０７はボリューム１０８毎のIO数に偏りがないかを監視する（S502）。ボトルネック解析部４０８は、監視の結果から問題の有無を判定し（S503）、問題がある場合はボトルネック解析を行う（S504）。ストレージ内にボトルネックがある場合、対策案作成部４０９はボトルネックを解消する対策案を作成する（S505）。そして、問題情報出力部４１０とUI４１１が出力する（S506）。対策が実施された場合、問題が改善されたかどうかは収集（S501）や監視（S502）に戻って確認されてもよい。【００３１】
図６はボリューム１０８ごとのIO監視処理の例を示すフローチャート図である。この処理は、図５に示したステップS502に相当する。IO性能監視部４０７は、アプリケーションサーバ１０２において記憶域グループ１０７で管理され、かつ均等配置が設定されているかを判定する（S601）。この判定の結果が設定されていないと判定された場合は、ステップS602以降の処理を実施しない。なお、記憶域グループ１０７による管理は図１１を用いて後で説明するAP構成情報管理テーブル４０３に設定されており、均等配置は予めアプリケーション管理者などにより設定されてもよい。また、均等配置は、アプリケーションプログラム１０６の出力する情報あるいはアプリケーションプログラム１０６が何であるかを識別する情報に基づき設定されていてもよい。【００３２】
ステップS601の判定の結果が設定されていると判定された場合、IO性能監視部４０７は、AP構成情報管理テーブル４０３から記憶域グループ１０７を構成するボリューム情報を取得する（S602）。IO性能監視部４０７は、記憶域グループ１０７が複数のボリューム１０８から構成されているかを判定し（S603）、複数のボリューム１０８で構成されている場合、ストレージ性能情報管理テーブル４０６から各ボリューム１０８の性能を取得し、各ボリューム１０８の性能の任意期間の平均値を比較する（S604）。【００３３】
ここでは、性能値としてIO数と応答時間がそれぞれ比較される。管理サーバ１０１は収集した１回以上の性能値の履歴データから各ボリューム１０８の任意期間の平均値以外に、中央値、最頻値を算出してもよい。これらの中のいずれの値を使用するかは、システムとして事前に設定されるか、アプリケーション管理者により適宜設定される。【００３４】
例として、IO数の場合を説明する。比較条件として、IO数が他よりも多いボリューム１０８、またはIO数が他よりも少ないボリューム１０８があるかをIO性能監視部４０７は判定する（S605）。中央値を使用する設定において、各ボリューム１０８のIO数の中央値が算出され、中央値からのはずれ度合いが基準値以上の場合、条件に一致するものと判定される。ここで基準値は、予めシステムとして設定されるか、アプリケーション管理者により設定される。【００３５】
例えば、３つのボリューム１０８を記憶領域グループとしている場合、１秒当たりのIO数がボリューム#1：100/秒、ボリューム#2：200/秒、ボリューム#3：210/秒であり、他も含めた中央値の200/秒からのはずれ度合いの基準が10％と設定されている場合、ボリューム#１の100/秒は他より少なく、問題ありと判定される。いずれか設定された条件に一致する場合、条件の一致したボリューム１０８は問題調査要となり、処理は終了する（S606）。【００３６】
比較条件として、平均値を使用する場合、IO性能監視部４０７は標準偏差を算出して、標準偏差が基準値以下で、平均値プラスまたはマイナス標準偏差の内に収まらないボリューム１０８がある場合、条件に一致するものと判定してもよい。また、分散を用いて同様に判定してもよい。ここでの基準値も予め設定される。【００３７】
応答時間の場合も同様で、定期的に取得したボリューム１０８毎の応答時間から任意期間の平均値を算出する。ボリューム１０８毎の応答時間の平均値を比較して、一部のボリューム１０８の応答時間が他よりも遅いボリューム１０８があるかを判別する。応答時間については、はずれ度合いの基準や標準偏差の基準について、基準値外であっても時間が短い場合は問題なしとする。基準値外で応答時間が長い場合のみ、問題ありと判断し、問題調査要とする（S606）。【００３８】
図７はストレージ装置１０３内のボトルネック解析処理の例を示すフローチャート図である。この処理は、図５に示したステップS504に相当する。ステップS502、S503で問題ありと判定されたボリューム１０８について、ボトルネック解析部４０８はストレージ構成情報管理テーブル４０５から関連する構成情報を読み出す（S701）。また、関連するポート１０９の性能、プロセッサ３０４の性能、キャッシュメモリ３０５の性能をストレージ性能情報管理テーブル４０６から読み出す。【００３９】
ボトルネック解析部４０８は、読み出した各性能値を基準値と比較して超過があるかを判定する。各性能値と基準値の比較としては、一定期間に収集した一つ以上の測定値（性能値）をそれぞれ基準値と比較し、一定回数以上基準値超過である場合を超過と判定してもよいし、測定値の代表値として平均値や中央値を算出して基準値と比較するなどしてもよい。【００４０】
フローチャートでは、ポート１０９の通信量またはIO数が基準値を超過しているかを判定し（S702）、超過している場合はポート１０９がボトルネックと特定して処理を終了する（S705）。次にプロセッサ３０４の使用率が基準値を超過しているかを判定し（S703）、超過している場合はプロセッサ３０４がボトルネックと特定して処理を終了する（S706）。【００４１】
さらにキャッシュヒット率または書き込み待機率が基準値範囲外かを判定し（S704）、基準値外の場合はキャッシュメモリ３０５がボトルネックと特定して処理を終了する（S707）。いずれの基準値違反もない場合、ボトルネック解析部４０８はボトルネックなしとして処理を終了する（S708）。基準値との比較処理のステップS702からステップS704は、図７に示した順番とは別の順番で行ってもよい。【００４２】
図８〜１０は対策案作成処理の例を示すフローチャートである。ボトルネックとしていずれかの箇所が特定された場合、ここではボトルネックとなっている使用中の部位を、別の部位に変更する案を作成する。図７に示した処理で特定されたボトルネックの種別毎にフローチャートを示して説明する。【００４３】
図８はポート１０９がボトルネックの場合の対策案作成処理の例を示すフローチャートである。ボトルネックとなっているポート１０９の代替ポートを探すため、対策案作成部４０９は、まずストレージ性能情報管理テーブル４０６のポート管理情報を参照して、一定期間の通信量およびIO数が基準値未満のポート１０９があるかを判定する（S801）。ここでの基準値はボトルネック解析に使用した基準値と同じでもよいし、それよりも厳しい(低い)基準値としてもよい。【００４４】
基準値未満のポート１０９がある場合、AP構成情報管理テーブル４０３を参照して、基準値未満のポート１０９は、ボトルネックとなるポート１０９を使用する問題ボリュームが含まれる記憶域グループ１０７の他のボリューム１０８が使用するポート１０９であるかを判定する（S802）。これは同じ記憶域グループ１０７のボリューム１０８が使用するポート１０９を代替ポートとした場合、代替ポートを既に使用しているボリューム１０８に影響を与え、記憶域グループ１０７としての性能に影響する可能性があるためである。【００４５】
基準値未満のポート１０９は、同じ記憶域グループ１０７のボリューム１０８が使用していないポート１０９であった場合、問題ボリュームへのアクセスに使用するポート１０９を、ボトルネックとなっていたポート１０９から基準値未満のポート１０９へ変更する記述を対策案として作成する（S805）。ここでの記述とは出力用文字列やスクリプトなどの各種言語で記述するものとする。【００４６】
基準値未満であり候補となるポート１０９が複数ある場合、対策案作成部４０９は、それぞれを対策案とし、現状の通信量およびIO数の低いポート１０９の優先度を高くするよう対策案に優先度を付与してもよい。さらに現在のポート１０９の通信量とIO量から変更した場合の予測値を算出し、その算出した予測値が基準値未満になるかを確認してもよい。予測値が基準値を超過する場合は、予測値が基準値を超過するポート１０９を対策案から削除してもよい。【００４７】
ステップS802で同じ記憶域グループ１０７の他のボリューム１０８が使用中のポート１０９であった場合、対策案作成部４０９は、再度基準値未満のポート１０９を検索する（図示せず）。同じ記憶域グループ１０７の他のボリューム１０８が使用中のポート１０９しか基準値未満のポート１０９がない場合、代替ポートに切替えても通信量が超過しないかを確認する。そのため、対策案作成部４０９は、ストレージ性能情報管理テーブル４０６を参照して、ボトルネックとなっているポート１０９を使用する問題ボリュームのIO量を読み出す（S803）。【００４８】
代替ポートの一定期間の平均通信量を算出し、算出した平均通信量とステップS803で読み出したIO量を合算する。合算量が基準値未満かを判定し（S804）、ステップS804の判定結果が基準値未満の場合は、基準値未満のポート１０９へ変更する記述を対策案として作成する（S805）。ステップS804で基準値未満となるポート１０９がない場合、対策案作成部４０９は、「対策なし」で処理を終了する（S806）。またステップS801で該当するポート１０９がない場合は、いずれのポート１０９も負荷が高いということであり、「対策なし」で終了する（S806）。【００４９】
図９はプロセッサ３０４がボトルネックの場合の対策案作成処理の例を示すフローチャートである。ポート１０９がボトルネックとなった場合と同様に、対策案作成部４０９は、性能情報を参照してプロセッサ３０４の割当変更案を作成する。まずストレージ性能情報管理テーブル４０６のプロセッサ管理情報を参照して、一定期間の使用率が基準値未満のプロセッサ３０４があるかを判定する（S901）。【００５０】
基準値未満のプロセッサ３０４がある場合、対策案作成部４０９は、AP構成情報管理テーブル４０３を参照して、基準値未満のプロセッサ３０４が、ボトルネックとなるプロセッサ３０４に割り当てられたボリューム１０８が含まれる記憶域グループ１０７の他のボリューム１０８が割り当てられているプロセッサ３０４かを確認する（S902）。割り当てられていない場合、ボリューム１０８の割当をボトルネックとなるプロセッサ３０４から基準値未満のプロセッサ３０４へ、変更する記述を対策案として作成する（S905）。【００５１】
基準値未満であり候補となるプロセッサ３０４が複数ある場合、対策案作成部４０９は、現使用率が低いプロセッサ３０４から対策案の優先度を高くしてもよい。さらに現使用率に変更で追加されるボリューム１０８のプロセッサ使用率を合わせた予測値を算出し、算出した予測値が基準値未満になるかどうかを確認してもよい。予測値が基準値を超過する場合は、予測値が基準値を超過するプロセッサ３０４を対策案から削除してもよい。【００５２】
ステップS902で同じ記憶域グループ１０７の他のボリューム１０８が割り当てられているプロセッサ３０４であった場合、対策案作成部４０９は、再度基準値未満のプロセッサ３０４を検索する（図示せず）。同じ記憶域グループ１０７の他のボリューム１０８に割り当てられたプロセッサ３０４のみの場合、そのプロセッサ３０４へ割当変更してもプロセッサ３０４の使用率が超過しないかを確認する。対策案作成部４０９は、ストレージ性能情報管理テーブル４０６を参照して、ボトルネックとなっているプロセッサ３０４に割り当てられた問題ボリュームのプロセッサ使用率を読み出す（S903）。【００５３】
基準値未満となっている変更先候補のプロセッサ３０４の一定期間の平均使用率を算出し、算出した平均使用率とステップS903で読み出した使用率を合算する。この場合、プロセッサ３０４の性能は変更前と変更先候補で同じであることを前提としている。合算量が基準値未満かを判定し（S904）、ステップS904の判定結果が基準値未満の場合は、変更先候補のプロセッサ３０４へ割当を変更する記述を対策案として作成する（S905）。【００５４】
ステップS904で基準値未満となるプロセッサ３０４がない場合、対策案作成部４０９は「対策なし」で処理を終了する（S906）。またポート１０９の場合と同様、ステップS901で該当するがない場合は、いずれのプロセッサ３０４も負荷が高いということであり、「対策なし」で処理を終了する（S906）。【００５５】
ボリューム１０８の使用するキャッシュメモリ３０５の書き込み待ち率が高く、ボトルネックになっている場合、対策案は、キャッシュパーティション毎の書き込み待ち率を参照し、待ち率の低い、基準値以下のパーティションに、問題ボリュームを切り出しているパリティグループ１１１を移動する対策案を提示する。【００５６】
次に図７に示したボトルネック解析フローにおいて、ボトルネックがなしと判定した場合の処理について説明する。記憶域グループ１０７内のボリューム１０８のIO数や応答時間の性能が均等でない場合であって、ボトルネックが特定できなかった場合は、さらに負荷を分散し均等になるよう図るため、ボリューム１０８の追加を対策案として提示する。【００５７】
図１０は追加ボリュームの切り出し案作成処理の例を示すフローチャートである。追加する容量は、ストレージ構成情報管理テーブル４０５を参照して、問題ボリュームと同容量とする。さらに必要な性能を特定するため、ストレージ性能情報管理テーブル４０６で管理されるボリューム１０８のアクセス傾向情報を使用できるように、対策案作成部４０９は問題ボリュームのアクセス傾向情報を読み出す（S1001）。【００５８】
ボリューム１０８のアクセス傾向は、ランダムアクセスまたはシーケンシャルアクセスか、読み出し（In）または書き込み（Out）が多いのかで分類される。ストレージ情報収集部４０２において、各アクセス傾向別のIO数をストレージ装置１０３から収集し、収集期間における頻度を比較することで最も頻度の高いパターンを記録する。【００５９】
アクセス傾向に従って、ボリューム１０８は必要な性能を高・中・低の三段階の必要性能レベルで管理される。例えばランダムIOが多い場合は高性能、シーケンシャルリードが多い場合は中性能、シーケンシャルライトが多い場合は低性能とする。これらは管理サーバ１０１がデフォルト設定してもよいし、アプリケーション管理者が設定してもよい。【００６０】
対策案作成部４０９は、ステップS1001で読み出したアクセス傾向が一致する条件を必要性能レベルとして識別する（S1002）。問題ボリュームが切り出されているパリティグループ１１１が必要性能レベルと一致または必要性能レベルより高いかを確認する（S1003）。一致または高いと判定された場合は、問題ボリュームと同じ性能のパリティグループ１１１からの切り出しを対策案として作成する（S1004）。【００６１】
ここで同性能のパリティグループ１１１が一つの場合には、問題ボリュームと同じパリティグループ１１１から追加ボリュームを切り出す案とするが、同性能のパリティグループが複数ある場合には、パリティグループ１１１に負荷が集中しないように、問題ボリュームとは別のパリティグループ１１１から追加ボリュームに切り出す案としてもよい。ステップS1003で必要性能よりも低いと判定された場合、対策案作成部４０９は、管理サーバ１０１が管理しているパリティグループ１１１から、必要性能レベルを持つパリティグループ１１１を抽出し、抽出したパリティグループ１１１からの切り出しを対策案として作成する（S1005）。【００６２】
なお、問題ボリュームの属する記憶域グループ１０７の全データを、必要性能レベルのパリティグループ１１１のボリューム１０８に移動することを対策案として加えてもよい。また対策案には、バックアップ情報を追加してもよい。アプリケーションがバックアップ機能を持っている場合、AP構成情報管理テーブル４０３にバックアップ先情報を登録され、管理されるバックアップ先情報に応じて、追加容量と同じ容量、性能のボリューム１０８をバックアップ先でも追加要とするよう、バックアップ先パス、容量、性能レベルを含む対策案を作成してもよい。さらにボリューム１０８追加後にデータの再配置を実施する場合、過去の性能履歴からIO数の少ない時間帯を抽出し、抽出した時間帯での再配置を対策案に加えてもよい。【００６３】
図１１はAP構成情報管理テーブル４０３の例を示す図である。ここではアプリケーションプログラム１０６がデータを保管する論理的な記憶領域としてテーブルスペースという単位で管理しており、テーブルスペースを記憶域グループ１０７に割り当てている例で説明する。AP構成情報管理テーブル４０３は、テーブルスペースIDフィールド１１０１、記憶域グループIDフィールド１１０２、容量フィールド１１０３、ボリュームIDフィールド１１０４、バックアップ先フィールド１１０５、要求性能フィールド１１０６から構成される。【００６４】
テーブルスペース名フィールド１１０１は例として示したものであり、アプリケーションプログラム１０６の種別によって異なる。バックアップ先フィールド１１０５は、既に説明したように、アプリケーションにバックアップ機能があり、管理している場合に登録する。容量フィールド１１０３とボリュームIDフィールド１１０４は各記憶域グループ１０７を構成する記憶装置としての構成である。なお、要求性能フィールド１１０６については別の実施例で説明する。【００６５】
図１２はストレージ構成情報管理テーブル４０５の例を示す図である。ボリューム１０８（論理ユニット１１３）を一意に識別するボリュームIDフィールド１２０１、ボリューム１０８の容量が登録されるボリューム容量フィールド１２０２、ボリューム１０８が割り当てられているプロセッサ３０４の識別子を登録するプロセッサIDフィールド１２０３、アプリケーションサーバ１０２からボリューム１０８へのアクセスに使用されるホストI/F３０２のポート１０９を識別するポートIDフィールド１２０４、ボリューム１０８が切り出されているパリティグループ１１１を識別するパリティグループIDフィールド１２０５、パリティグループ１１１単位に割り当てられているキャッシュパーティションを識別するキャッシュIDフィールド１２０６から構成される。【００６６】
ストレージ装置１０３において、複数のプロセッサ３０４が１枚のブレードに搭載され、ブレード単位にボリューム１０８へ割当てられている場合、プロセッサIDフィールド１２０３にはプロセッサブレード（MPB１１０）を識別するIDが登録される。以降では単体のプロセッサ３０４かプロセッサブレード（MPB１１０）かを特に区別して説明しない限り、いずれの構成であってもよい。【００６７】
図１３Ａから図１３Ｄはストレージ性能情報管理テーブル４０６の例を示す図である。ストレージ装置１０３に関する性能情報は、予め設定された所定時間毎で定期的にストレージ装置１０３から取得され、取得時刻とともに時系列で記録されて管理される。図１３Ａから図１３Ｄでは１つの時刻での値の例を示し、複数の時刻での値の図示を省略する。性能情報として、図１３Ａに示すボリューム１０８毎の性能、図１３Ｂに示すプロセッサ３０４毎の性能、図１３Ｃに示すポート１０９毎の性能、図１３Ｄに示すキャッシュパーティション毎の性能がある。【００６８】
図１３Ａに示すボリューム１０８毎の性能情報は、ボリュームIDフィールド１３０１、平均IO数フィールド１３０２、平均IO量フィールド１３０３、平均応答時間フィールド１３０４、プロセッサ使用率フィールド１３０５、アクセス傾向フィールド１３０６から構成される。平均IO数には、読み取りIO数および書き込みIO数の総数の所定時間当たりの平均値を記録する。平均応答時間も同様に、読み取りおよび書き込みにかかった全処理時間の所定時間当たりの平均値を記録する。平均アクセス傾向フィールド３０６は、本実施例では使用せず、別の実施例で使用するため、別の実施例で説明する。【００６９】
図１３Ｂに示すプロセッサ３０４毎の性能情報は、プロセッサIDフィールド１３１１と使用率フィールド１３１２から構成される。図１３Ｃに示すポート１０９毎の性能情報は、ポートIDフィールド１３２１と通信量フィールド１３２２、IO数フィールド１３２３から構成される。図１３Ｄに示すキャッシュパーティション毎の性能情報は、キャッシュIDフィールド１３３１と書き込み待ち率フィールド１３３２から構成される。【００７０】
図１４は対策案提示のGUI画面の例を示す図である。アプリケーション管理者が使用する性能監視画面を示している。UI４１１は、性能情報として、上段１４０１にはテーブルスペース毎の性能グラフを出力し、中段１４０２には障害情報を出力し、下段１４０３には原因の可能性のあるディスクIOについての情報を出力する。問題情報出力部４１０は対策案として作成された文字列を中断１４０２の障害情報欄に出力される。【００７１】
UI４１１は、実行ボタン１４０４を出力し、アプリケーション管理者により実行ボタン１４０４が押されることで、対策案として作成されたスクリプトが実行されてもよい。UI４１１の出力により、アプリケーション管理者はアプリケーションの応答時間が悪化している問題状態と、関連するストレージ装置１０３側の状況と対策を把握できる。なお、対策案作成部４０９の作成した記述を単に出力してもよい。【００７２】
以上で説明したように、複数のボリューム１０８に対してデータの均等配置による負荷分散を行っているアプリケーションシステムにおいて、負荷分散のバランスの監視とバランスが不均等になっている問題発生時に、ストレージ装置１０３内での対策案が提示可能となる。【００７３】
また対策案の画面出力とは別に、ストレージ設定自動実行ツールを持つシステムの場合、対策案のスクリプトをストレージ設定自動実行ツールに入力することで、ストレージ装置１０３内で自動的に対策案に従った変更を実行してもよい。これにより、アプリケーション管理者の作業負荷を軽減できる。
【実施例２】
【００７４】
実施例１ではパリティグループ１１１により提供される論理ボリュームを使用する例を説明したが、実施例２では、ストレージ装置における仮想化技術の一つであるシン・プロビジョニングによる仮想ボリュームで提供される論理ボリュームを使用する例を説明する。ストレージ装置１０３では記憶容量が仮想化された仮想ボリュームを、論理ボリュームとして提供する。アプリケーションプログラム１０６が新たな領域へライトアクセスすることに併せて、仮想ボリュームに対して実の記憶領域を持つプールから、記憶領域を順次割り当てていく。【００７５】
プールはメディアの種類やディスクの回転数といった性能・特性別に複数のプールボリュームから構成される。このため、管理する情報として、実施例１の図１２で示したストレージ構成情報管理テーブル４０５に、プールIDフィールドとプール性能情報フィールドが追加される。プール性能情報は、必要性能レベルと同じく、高・中・低の３段階で管理され、アプリケーションプログラム１０６が使用する記憶域グループ１０７は、同性能のプールを使用するボリューム１０８で構成される。実施例１と同様に管理サーバ１０１はボリューム（論理ボリューム）１０８の応答時間やIO数が均等にバランスされているかどうかを監視する。【００７６】
管理サーバは、不均等を検出した場合、ストレージ装置１０３から提供されるボリューム１０８が仮想ボリュームであっても、ボリューム１０８に関する構成情報（ポート、プロセッサ、キャッシュ割当）と性能情報を管理し、ストレージ装置１０３内のボトルネック解析を行って、対策案を提示する。図１０を用いて説明したボリューム１０８の追加の場合は、アクセス傾向から必要な性能レベルを判断して、実施例１とは異なり、プール性能が条件を満たすプールからボリューム１０８を切り出す対策案とする。【００７７】
さらに、ストレージ装置１０３がシン・プロビジョニングに加え、保存されたデータに対するアクセス頻度によって、性能の異なるプールボリュームにデータを移動する階層管理を行ってもよい。このような管理では、アプリケーションプログラム１０６から複数のボリューム１０８に均等にデータを配置しても、データによってそれぞれの異なる階層に移動されることになる。追加のストレージ構成情報として、ボリューム１０８の階層別割合を管理する。ボリューム１０８を構成する階層の割合を同等にしている場合、本実施例における処理は同様となる。【００７８】
階層の割合が同等でない場合、ボリューム１０８間で応答時間のばらつきが大きくなる可能性がある。そのため、負荷バランスを監視するステップにおいては、応答時間のばらつきのはずれ度合いの基準値を、幅を広くもたせるよう適切に設定して監視を実施する。また応答時間の遅いボリューム１０８については、高性能階層の割合を増やすようの変更する対策案を作成する。【００７９】
以上で説明したように、シン・プロビジョニングによる仮想ボリュームを使用するシステムであっても、対策案を提示することが可能になる。
【実施例３】
【００８０】
実施例１ではストレージ装置１０３の性能を監視する例を説明したが、実施例３ではアプリケーションサーバ１０２側の性能を監視して、アプリケーションサーバ１０２からみた応答時間に遅延の問題があった場合に、複数ボリューム１０８へのアクセスの負荷を解析する例を説明する。すなわち実施例１との違いは、監視と問題検知をアプリケーションベースで行う点である。【００８１】
管理サーバ１０１は図５を用いて説明した実施例１のステップS502の前に、アプリケーションサーバ１０２からストレージ装置１０３へのIOの応答時間を収集する。そして、収集した応答時間が、閾値やベースラインといった基準値違反となっていないかを判定するステップが、ステップS502の前に追加される。応答時間が違反したと判定された場合に管理サーバ１０１はステップS502の処理を行う。負荷分散のバランスが不均等になっていたとしても、アプリケーションサーバ１０２への応答に問題がない場合は対策を行う必要がないため、アプリケーション管理者の負担を軽減できる。【００８２】
さらに、応答遅延に問題発生し、図５を用いて説明したステップS506の後、監視に戻ってステップS501から実行する場合、処理ステップS502の前で、管理サーバ１０１はアプリケーションサーバ１０２での応答時間を収集する。収集した応答時間が回復していると判定されれば、負荷分散のバランスが改善したかどうかの確認すなわちステップS502以降の処理は不要である。応答時間が回復していないと判定された場合、管理サーバ１０１はS502以降の処理を繰り返し実行する。【００８３】
またステップS502の前の応答時間を収集する処理の次に、アプリケーションサーバ１０２から収集する応答時間と、ストレージ装置１０３から取得する応答時間を比較するステップを追加してもよい。この２種類の応答時間の差が予め設定された基準値より大きい場合、アプリケーションサーバ１０２とストレージ装置１０３との間のストレージエリアネットワーク１０４に問題があると判定することも可能になる。これにより、負荷分散のバランスが不均等になっていたとしても、アプリケーションサーバ１０２への応答遅延がストレージエリアネットワーク１０４の問題であることが分かるため、ストレージ装置１０３内の対策を行う必要がなく、アプリケーション管理者の負担を軽減できる。
【実施例４】
【００８４】
図７を用いて説明したボトルネック解析処理において、ポート１０９、プロセッサ３０４、キャッシュメモリ３０５でボトルネックが特定できなかった場合、実施例１ではボリューム１０８を追加する例を説明したが、実施例４ではボリューム１０８を追加するのではなく、ボリューム１０８の配置されているパリティグループ１１１がボトルネックであると判定し、ボリューム１０８を他パリティグループ１１１に移行する対策案を作成する例を説明する。記憶域グループ１０７内のボリューム１０８毎の性能が均等でなく、問題となるボリューム１０８がある場合、問題となるボリューム１０８を他のパリティグループ１１１に移行する。【００８５】
図１５はボリューム１０８の移行案作成処理の例を示すフローチャートである。対策案作成部４０９は、図１０を用いて説明したフローチャートの代わりに図１５に示すフローチャートに従って処理してもよい。対策案作成部４０９は、まずパリティグループ１１１の残容量が、問題となるボリューム１０８の使用容量よりも多いパリティグループ１１１を検索する（S1501）。残容量の多いパリティグループ１１１があると判定された場合、追加ボリューム切り出し処理と同様に、必要な性能を特定するため、ストレージ性能情報管理テーブル４０６で管理するボリューム１０８のアクセス傾向情報を使用する。【００８６】
このため、対策案作成部４０９は、問題となるボリューム１０８のアクセス傾向情報を読み出す（S1502）。読み出したアクセス傾向が一致する条件を必要性能レベルとして、高、中、低のいずれかを識別する（S1503）。ステップS1501で抽出した残容量の多いパリティグループ１１１が必要性能レベルと一致または必要性能レベルより高いかを判定する（S1504）。この判定の結果が必要性能レベル未満の場合は、ステップS1501へ戻り他のパリティグループ１１１を抽出して繰り返す。【００８７】
ステップS1501の判定結果として残容量の多いパリティグループ１１１がないと判定された場合、対策案作成部４０９は対策なしとする（S1508）。なお、ステップS1508を実行する場合、図１０を用いて説明した追加ボリュームの切り出し案作成処理を実行してもよいし、残容量を多くするためにパリティグループ１１１の容量を物理的に増設する案を作成してもよい。【００８８】
ステップS1504において必要性能レベルのパリティグループ１１１があると判定された場合、対策案作成部４０９は、問題となるボリューム１０８と同じ記憶域グループ１０７の他のボリューム１０８が使用しているパリティグループ１１１であるかを判定する（S1505）。この判定の結果が使用していないと判定された場合は、問題となるボリューム１０８を、ステップS1504で必要性能レベルであると判定されたパリティグループ１１１へ移行する対策案を作成する（S1507）。【００８９】
ステップS1505において他のボリューム１０８も使用していると判定された場合、対策案作成部４０９は、使用していると判定された他のボリューム１０８の一定期間のIO性能を取得し、取得したIO性能が基準値を満たすかを判定する（S1506）。この判定の結果が満たすと判定した場合は、問題となるボリューム１０８を移行する対策案を作成する（S1507）。ここでの基準値は性能が問題ないことを判定するための値であり、単位時間当たりのIO数や応答時間について事前に設定された値である。【００９０】
ステップS1506において基準値を満たさないと判定された場合は、問題となるボリューム１０８を移行した際に、他のボリューム１０８の性能に影響があるため移行先としない。このようにステップS1506の条件を満たすパリティグループ１１１がない場合、対策案作成部４０９は対策なしとする（S1508）。【００９１】
以上で説明したように、問題となるボリューム１０８を他のパリティグループ１１１へ移行する対策案を作成できる。
【実施例５】
【００９２】
実施例３ではアプリケーションサーバ１０２としての性能を監視する例を説明したが、実施例５ではアプリケーションサーバ１０２の中のアプリケーションプログラム１０６が管理する記憶域グループ１０７のアクセス性能が必要な性能を満たしているかを監視する例を説明する。図５を用いて既に説明したようにステップS502において、管理サーバ１０１は記憶域グループ１０７の各ボリューム１０８の負荷のバランスが均等になっているかを監視するが、さらに条件を加えて、記憶域グループ１０７のアクセス性能が要求を満たしていない場合に、ステップS502で負荷のバランスが均等かを判定する。【００９３】
図１１に示すようにAP構成情報管理テーブル４０３は要求性能フィールド１１０６を含み、アプリケーションプログラム１０６の管理単位である記憶域グループ１０７（図１１の例ではテーブルスペース）に対し、要求されるディスクアクセス性能値を記憶して管理する。この要求性能の指標として、図１１の例では単位時間当たりのIO数としているが、応答時間や単位時間当たりのIO量でもよい。この指標の要求性能値はアプリケーション管理者によって予め設定される。【００９４】
図１６はアプリケーションのディスクアクセス性能情報を管理するAP性能情報管理テーブル４０４の例を示す図である。AP性能情報管理テーブル４０４は、アプリケーションプログラム１０６のディスクアクセス性能情報を管理するためのものであり、性能情報が定期的にアプリケーションサーバ１０２から取得され、単位期間の性能値を取得時刻とともに時系列に記録されて管理される。【００９５】
図１６では１つの時刻における値の例を示し、複数の時刻での値の図示を省略する。AP性能情報管理テーブル４０４は、テーブルスペースIDフィールド１６０１の値（ID）に対し、性能情報として、平均IO数フィールド１６０２、平均IO量フィールド１６０３、平均応答時間フィールド１６０４から構成される。【００９６】
管理サーバ１０１は、図５を用いて説明したステップS502の前に、AP構成情報管理テーブル４０３の要求性能フィールド１１０６から要求性能値を取得し、AP性能情報管理テーブル４０４から平均IO数フィールド１６０２から性能値を取得し、取得した性能値が取得した要求性能値以上であるかを判定する。この判定の結果が要求性能値以上すなわち要求性能値を満たしていると判定された場合は、ステップS501へ戻り監視を継続する。また、この判定の結果が要求性能値未満すなわち要求性能値を満たしていないと判定された場合、管理サーバ１０１はステップS502の処理に移る。【００９７】
以上で説明したように、アプリケーションプログラム１０６に対して必要なディスクアクセス性能を提供することが可能となる。
【符号の説明】
【００９８】
１０１：管理サーバ、１０２：アプリケーションサーバ、１０３：ストレージ装置、１０６：アプリケーションプログラム、１０７：記憶域グループ、１０８：ボリューム、１０９：ポート、１１０：MPB、１１１：パリティグループ
【図１】
0006462116.tif 000002
【図２】
0006462116.tif 000003
【図３】
0006462116.tif 000004
【図４】
0006462116.tif 000005
【図５】
0006462116.tif 000006
【図６】
0006462116.tif 000007
【図７】
0006462116.tif 000008
【図８】
0006462116.tif 000009
【図９】
0006462116.tif 000010
【図１０】
0006462116.tif 000011
【図１１】
0006462116.tif 000012
【図１２】
0006462116.tif 000013
【図１３Ａ】
0006462116.tif 000014
【図１３Ｂ】
0006462116.tif 000015
【図１３Ｃ】
0006462116.tif 000016
【図１３Ｄ】
0006462116.tif 000017
【図１４】
0006462116.tif 000018
【図１５】
0006462116.tif 000019
【図１６】
0006462116.tif 000020