JPWO2013076795A1 - ストレージ装置の管理装置及び管理方法 - Google Patents

Abstract

記憶領域を有効に利用し、ユーザの使い勝手を高める。
管理装置は、ホストコンピュータによる各論理的記憶領域へのアクセス負荷と、配置先の記憶階層における各論理的記憶領域の配置状態とに基づいて、各論理的記憶領域の再配置先を決定する。複数のモニタリングモードのうちのいずれか一つを選択するためのモニタリングモード選択部は、各論理的記憶領域が配置先の記憶階層に配置されている時間に関する配置時間情報に基づいて、複数のモニタリングモードのうち所定のモニタリングモードを選択する。

Description

本発明は、ストレージ装置の管理装置及び管理方法に関する。

より効率的なストレージ管理のために、階層化されたストレージをページ単位で利用する技術が知られている（特許文献１）。その従来技術では、論理的プール内に複数の記憶階層を定義し、個々の論理ボリュームの性能に基づいてそれらの論理ボリュームを複数階層のうちのいずれかの階層に割り当てる。

ストレージ装置は、仮想的な論理ボリュームを作成して、ホストコンピュータに割り当てる。ホストコンピュータは、仮想的論理ボリュームを構成する論理的記憶領域（論理ページとも呼ぶ）にライトアクセスまたはリードアクセスする。ライトアクセス対象の論理ページに初めてアクセスした場合、その論理ページに、プール内の実記憶領域（物理ページとも呼ぶ）が対応付けられる。ホストコンピュータからのライトデータは、その物理ページに書き込まれる。

仮想的論理ボリュームからデータを読み出す場合、論理ページと物理ページとの対応関係に基づいて、リード対象データを格納する物理ページが特定される。ストレージ装置は、その特定された物理ページからリード対象データを読み出して、ホストコンピュータに送信する。

論理ページと物理ページとの対応付けは、論理ページへのＩ／Ｏ（Input/Output）量に応じて定期的に変更される。この対応付けの変更を、ページ再配置と呼ぶ。ストレージ装置は、各論理ページに対するホストコンピュータからのＩ／Ｏをモニタリングして、各論理ページ毎のＩ／Ｏの負荷を記憶する。プール内の記憶階層毎に、予めＩ／Ｏ負荷の閾値が定義されている。ストレージ装置は、或る論理ページのＩ／Ｏ負荷が現在の配置先の記憶階層の閾値を超えた場合、その論理ページのデータを他の記憶階層の物理ページに対応付ける。一般的に、論理ページのＩ／Ｏ負荷が大きくなるほど、その論理ページのデータは、より高性能の記憶階層内の物理ページに記憶される。論理ページのＩ／Ｏ負荷が小さくなるほど、その論理ページのデータは、より低性能の記憶階層内の物理ページに記憶される。

特開２００７−０６６２５９号公報

従来のページ単位の階層管理技術では、予め定まったモニタリング期間内のＩ／Ｏ数をカウントするため、仮想的論理ボリュームの使用状況に合わせてページ再配置を行うのは難しい。例えば、一方のアプリケーションプログラム（以下、アプリケーション）が使用する一方の仮想的論理ボリュームと、他方のアプリケーションが使用する他方の仮想的論理ボリュームとが、共通のプールを利用して作成されている場合を説明する。

一方のアプリケーションは、Ｉ／Ｏ数の大きい状態が比較的長い時間にわたって継続すると仮定する。この場合、一方のアプリケーションにより使用される、一方の仮想的論理ボリュームの論理ページのデータは、たとえ一時的にＩ／Ｏ数が低下した場合でも、低性能の記憶階層に移動させるべきではない。一方のアプリケーションが再び多量にアクセスする場合に、応答性能が低下するためである。そのような仮想的論理ボリュームは、結局、元の高性能の記憶階層に再配置されることになり、低性能な記憶階層への一時的な移動は無駄になる。

他方のアプリケーションは、Ｉ／Ｏ数の大きい状態の継続する時間が比較的短いと仮定する。この場合、他方のアプリケーションにより使用される、他方の仮想的論理ボリュームの論理ページのデータは、Ｉ／Ｏ数の低下に応じて低性能の記憶階層に配置させる方が望ましい。なぜなら、Ｉ／Ｏ数の低下したページを高性能な階層に長時間滞留させておくことは、Ｉ／Ｏ数のより高い他のページが高性能の階層に移動することを阻むことになるためである。

仮想的論理ボリューム毎にモニタリング方法を手動で設定するのでは、管理上の手間がかかり、管理コストが増大する。

本発明は、上記の課題に鑑みてなされたもので、その目的は、使い勝手を向上できるようにしたストレージ装置の管理装置及び管理方法を提供することにある。本発明の他の目的は、ストレージ装置の有する記憶領域をより効率的に使用することができ、かつ、管理上の使い勝手を改善できるようにした、ストレージ装置の管理装置及び管理方法を提供することにある。

上記課題を解決すべく、本発明に従うストレージ装置の管理装置は、ストレージ装置を管理する管理装置であって、ストレージ装置は、ホストコンピュータに提供するための仮想的論理ボリュームと、それぞれ性能の異なる複数の記憶階層を有するプールとを備え、かつ、仮想的論理ボリュームを構成する複数の論理的記憶領域を、複数の記憶階層のうち指示された所定の記憶階層内の記憶領域に対応付けることで、所定の記憶階層に配置させるようになっており、ホストコンピュータによる各論理的記憶領域へのアクセス負荷と、配置先の記憶階層における各論理的記憶領域の配置状態とに基づいて、各論理的記憶領域の再配置先を決定する。

ストレージ装置から所定の情報を収集するための情報収集部と、所定の情報に基づいて、論理的記憶領域毎にアクセス負荷を評価するためのアクセス負荷評価部と、各論理的記憶領域が配置先の記憶階層に配置されている時間に関する配置時間情報を、配置状態として算出する配置時間情報算出部と、アクセス負荷および配置時間情報とに基づいて、各論理的記憶領域が各記憶階層のうちのいずれに配置されるべきかを論理的記憶領域毎に決定して、ストレージ装置に指示する再配置指示部と、を備えてもよい。

予め用意されている複数のモニタリングモードのうちのいずれか一つを選択するためのモニタリングモード選択部を備え、アクセス負荷評価部は、複数のモニタリングモードのうち選択されたモニタリングモードに基づいて、各論理的記憶領域のアクセス負荷を評価してもよい。

モニタリングモード選択部は、配置時間情報に基づいて、複数のモニタリングモードのうち所定のモニタリングモードを選択することもできる。

配置時間情報算出部は、各論理的記憶領域が複数の記憶階層のうち最も高性能の記憶階層に配置されている時間と所定の配置基準期間との比率を、配置時間情報として算出し、モニタリングモード選択部は、配置時間情報の値と、複数のモニタリングモードの中から所定のモニタリングモードを選択するために予め設定されるモニタリングモード選択用基準値とを比較することで、複数のモニタリングモードの中から所定のモニタリングモードを選択することもできる。

上述した本発明の特徴は、明示された以外に種々組合せることができる。さらに、本発明は、コンピュータプログラムとして把握することもできる。コンピュータプログラムは、通信媒体または記録媒体を介して、コンピュータにインストールされる。

ストレージ装置の管理装置を含む計算機システムの構成例を示す。 ホストコンピュータのハードウェア構成例を示す。 ストレージ装置のハードウェア構成例を示す。 仮想的論理ボリュームとプール及び論理ボリュームの関係を示す説明図。 ストレージ装置が具備する物理ページ管理表の例を示す。 ストレージ装置が具備するディスク管理表の例を示す。 ストレージ装置が具備する階層管理表の例を示す。 ストレージ装置が具備するプール階層管理表の例を示す。 ストレージ装置が具備する論理ページ管理表の例を示す。 ストレージ装置が具備する物理ページと論理ページの対応関係を管理する表の例を示す。 管理サーバのハードウェア構成例を示す。 管理サーバが具備するアプリケーション管理表の例を示す。 管理サーバが具備する、論理ページの実際の負荷データ（負荷実データ）の履歴を管理する表の例を示す。 管理サーバが具備する、論理ページの負荷を評価したデータ（評価データ）の履歴を管理する表の例を示す。 管理サーバが具備する、モニタリング方式を定義する表の例を示す。 管理サーバが具備する、プールの階層を管理する表の例を示す。 管理サーバが具備する、論理ページの階層滞留率の履歴を管理する表の例を示す。 管理サーバが具備する、階層滞留率の計算に使用するためのモニタリング期間管理表の例を示す。 管理サーバが具備する、階層滞留率の基準値を管理する表の例を示す。 管理サーバが具備する、論理ページのモニタリング方式の履歴を管理する表の例を示す。 管理サーバが具備する、仮想ボリュームをモニタリングするために選択されれたモニタリング方式の履歴を管理する表の例を示す。 ストレージ装置の有するモジュール及び表と、管理サーバの有するモジュール及び表との関連を示す説明図。 図２２に続く説明図。 ストレージ装置が実施する、プール階層データを提供する処理のフローチャート。 ストレージ装置が実施する、論理ページの実際の特性データ（特性実データ）を提供する処理のフローチャート。 ストレージ装置が実施する、論理ページの再配置を実行する処理のフローチャート。 管理サーバが実施する、ストレージ管理処理のフローチャート。 管理サーバが実施する、プールの階層データを収集する処理のフローチャート。 管理サーバが実施する、論理ページの負荷実データを収集する処理のフローチャート。 管理サーバが実施する、論理ページの性能を評価する処理を示すフローチャート。 管理サーバが実施する、Ｉ／Ｏ特性の評価値を算出するための処理を示すフローチャート。 管理サーバが実施する、次のページ再配置処理で配置されるべき記憶階層（次期階層）を選択するための処理を示すフローチャート。 管理サーバが実施する、論理ページの階層滞留率を計算する処理のフローチャート。 管理サーバが実施する、論理ページのモニタリング方式を選択する処理のフローチャート。 管理サーバが実施する、次期で使用されるモニタリング方式の候補を選択する処理のフローチャート。 管理サーバが実施する、モニタリング方式を切り替えるための基準値を取得する処理のフローチャート。 管理サーバが実施する、次期のモニタリング方式を選択する処理のフローチャート。 管理サーバが実施する、論理ページの再配置を指示する処理を示すフローチャート。 第２実施例に係る管理サーバの構成例を示す。 管理サーバが有するモジュールと表の関連を示す説明図。 管理サーバが表示する、モニタリング方式の設定画面の例を示す。 管理サーバが具備する、階層滞留率の基準値を管理する表の例を示す。 管理サーバが実施する、論理ページのモニタリング方式を変更する処理のフローチャート。 管理サーバが実施する、階層滞留率の基準値を変更する処理を示すフローチャート。 管理サーバが実施する、階層滞留率の基準値を更新する処理を示すフローチャート。 第３実施例に係る管理サーバの構成例を示す。 管理サーバが有するモジュール及び表のうち、アプリケーショングループを管理する構成に関わるモジュール及び表の関係を示す説明図。 管理サーバが表示する、アプリケーショングループの一覧画面の例。 管理サーバが表示する、アプリケーショングループの作成画面の例。 管理サーバが表示する、アプリケーショングループの編集画面の例。 管理サーバが表示する、モニタリング方式の設定画面の例。 管理サーバが具備する、階層滞留率の基準値をアプリケーショングループ単位で管理するための表の例を示す。 管理サーバが具備する、アプリケーショングループ管理表の例。 管理サーバが実施する、アプリケーショングループを追加する処理のフローチャート。 管理サーバが実施する、アプリケーショングループを削除する処理のフローチャート。 管理サーバが実施する、アプリケーショングループを編集する処理のフローチャート。 管理サーバが実施する、論理ページのモニタリング方式をアプリケーショングループ単位で変更する処理のフローチャート。 管理サーバが実施する、階層滞留率の基準値をアプリケーショングループ単位で変更する処理のフローチャート。

以下、図面に基づいて、本発明の実施の形態を説明する。本実施形態では、後述のように、仮想的論理ボリュームの実際の使用状況に応じて、ページ再配置に使用するためのモニタリング方式を自動的に選択する。

なお、以下の説明では、「ｘｘｘテーブル」の表現にて各種情報を説明することがあるが、各種情報は、テーブル以外のデータ構造で表現されていても良い。データ構造に依存しないことを示すために「ｘｘｘテーブル」を「ｘｘｘ情報」と呼ぶことができる。

以後の説明では、「プログラム」を主語として処理を説明する場合がある。プログラムは、プロセッサ（例えばＣＰＵ（Central Processing Unit））によって実行されることで、定められた処理を、メモリ等の記憶資源及び通信ポート等の通信インタフェース装置を適宜用いながら実行する。従って、処理の主語は、プロセッサでも良い。プロセッサは、ＣＰＵの他に専用ハードウェアを有していても良い。コンピュータプログラムは、プログラムソースから計算機にインストールされても良い。プログラムソースは、例えば、プログラム配布サーバ又は記憶メディアであっても良い。

例えば、プールボリューム等の各要素は、識別子（ＩＤ）、番号、名前等で識別可能である。

以下、図を用いて、本発明の一実施例を説明する。本発明が以下に述べる実施例に制限されることは無く、本発明の思想に合致するあらゆる応用例が本発明の技術的範囲に含まれる。また、特に限定しない限り、各構成要素は複数でも単数でも構わない。

図１は、計算機システムの全体構成を示す。計算機システムは、少なくとも一つのホストコンピュータ（以下、ホスト）１０と、少なくとも一つのストレージ装置２０と、一つの管理サーバ３０とを含む。

ホスト１０とストレージ装置２０とは、例えば、ＩＰ−ＳＡＮ（Internet Protocol_SAN）またはＦＣ−ＳＡＮ（Fibre Channel-Storage Area Network）のような通信ネットワークＣＮ１を介して、双方向通信可能に接続される。管理サーバ３０とストレージ装置２０は、例えば、ＬＡＮ（Local Area Network）のような、管理用の通信ネットワークＣＮ２を介して、双方向通信可能に接続される。なお、例えば、ｉＳＣＳＩ（internet Small Computer System Interface）を用いる場合、通信ネットワークＣＮ１及びＣＮ２を、一つのＬＡＮとして構成してもよい。

図２を参照して、ホスト１０の構成を説明する。ホスト１０は、例えば、マイクロプロセッサ（ＣＰＵ）１１０と、メモリ１２０と、通信ポート１３０とを備える。ＣＰＵ１１０は、メモリ１２０に格納されたアプリケーションＰ１０を読み込んで実行する。メモリ１２０には、種々のアプリケーションＰ１０を格納することができる。ホスト１０は、いわゆるオープン系のサーバコンピュータとして構成してもよいし、メーンフレームマシンのように構成してもよい。

図３を参照して、ストレージ装置２０の構成を説明する。ストレージ装置２０は、例えば、マイクロプロセッサ２１０と、メモリ２２０と、複数の記憶装置２３０と、通信ポート２５１、２５２を備える。一方の通信ポート２５１は、ＳＡＮネットワークＣＮ１に接続するためのものである。他方の通信ポート２５２は、管理用ネットワークＣＮ２に接続するためのものである。

記憶装置２３０は、例えば、ハードディスクドライブ、半導体メモリドライブ、フラッシュメモリデバイス、光ディスクドライブ等のデータを読み書き可能な種々のデバイスを利用可能である。ハードディスクドライブを用いる場合、例えば、ＦＣ（Fibre Channel）ディスク、ＳＣＳＩ（Small Computer System Interface）ディスク、ＳＡＴＡディスク、ＡＴＡ（AT Attachment）ディスク、ＳＡＳ（Serial Attached SCSI）ディスク等を用いることができる。

また、例えば、フラッシュメモリ、ＦｅＲＡＭ（Ferroelectric Random Access Memory）、ＭＲＡＭ（MagnetoresistiveRandom Access Memory）、相変化メモリ（Ovonic Unified Memory）、ＲＲＡＭ（Resistance RAM：登録商標）等の種々の記憶装置を用いることもできる。さらに、例えば、フラッシュメモリデバイスとハードディスクドライブのように、種類の異なる記憶装置を混在させる構成でもよい。

複数の記憶装置２３０から一つのパリティグループを形成し、各記憶装置２３０の有する物理的記憶領域を一つの冗長記憶領域としてまとめることもできる。その冗長化された記憶領域を用いて、一つまたは複数の論理ボリューム２４０が作成される。一つの記憶装置２３０の有する記憶領域を用いて、一つまたは複数の論理ボリューム２４０を作成することもできる。なお、ストレージ装置２０がホスト１０に提供する仮想ボリューム２７０等の構成については、図４で後述する。

メモリ２２０は、ストレージ制御プログラムＰ２０と、各種の管理表Ｔ２０、Ｔ２１、Ｔ２２、Ｔ２３、Ｔ２４、Ｔ２５とを格納する。ストレージ制御プログラムＰ２０は、複数のプログラムモジュールＰ２１、Ｐ２２、Ｐ２３、Ｐ２４及びＰ２５を備える。各プログラムモジュールＰ２１〜Ｐ２５の動作については、後述する。各管理表Ｔ２０〜Ｔ２５の構成も後述する。なお、管理表Ｔ２０〜Ｔ２５は、メモリ２２０に代えて、ハードディスクドライブ等の補助記憶装置に記憶させてもよい。

図４を参照して、仮想ボリューム２７０と、プール２６０と、論理ボリューム２４０との関係を説明する。

プール２５０は、論理的に構成されるもので、それぞれ性能の異なる複数の記憶階層２６１Ａ、２６１Ｂ、２６１Ｃを備える。第１記憶階層２６１Ａは、最も性能の高い階層である。第１記憶階層２６１Ａには、例えば、フラッシュメモリデバイス（ＳＳＤ：Solid State Drive）の有する物理的記憶領域を用いて作成された論理ボリューム２４０が登録される。第２の記憶階層２６１Ｂは、中性能の階層である。第２の記憶階層２６１Ｂには、例えば、ＳＡＳの有する物理的記憶領域を用いて作成された論理ボリューム２４０が登録される。第３記憶階層２６１Ｃは、最も性能の低い階層である。第３記憶階層２６１Ｃには、例えば、ＳＡＴＡの有する物理的記憶領域を用いて作成された論理ボリューム２４０が登録される。

仮想的論理ボリュームとしての仮想ボリューム２７０は、ストレージ装置２０内に複数設けることができる。仮想ボリューム２７０は仮想的な存在であり、データを実際に格納するのはプール２５０を構成する各論理ボリューム２４０である。

仮想ボリューム２７０の有する論理的な記憶領域は、複数の論理ページ２７１から構成される。ホスト１０からのライトアクセスに応じて、論理ページ２７１に物理ページ２４１が対応付けられる。記憶装置２３０の有する物理的記憶領域は、複数の物理ページ（またはセグメント）２４１により区切られている。論理ページ２７１に物理ページ２４１が割り当てられることで、その論理ページ２７１にデータを書き込むことができる。

物理ページ２４１と論理ページ２７１との対応関係は、後述の物理ページ−論理ページ対応管理表Ｔ２５で管理される。物理ページ２４１と論理ページ２７１との対応関係は、後述する処理により、所定周期で見直される。

次に、各管理表について説明する。以下に述べる各表の構成は一例に過ぎず、図示した構成とは異なる構成でもよい。例えば、各表は、図示された項目以外の項目を含んでもよいし、図示された複数の項目のうちの一部の項目が除去されてもよい。さらに、図示された表を、複数の表に分割してもよいし、図示された複数の表を一つの表にまとめる構成でもよい。

図５は、ストレージ装置２０が具備する物理ページ管理表Ｔ２０を示す。物理ページ管理表Ｔ２０は、物理ページを管理するための表であり、例えば、ディスク識別子Ｃ２００と、物理ページ識別子Ｃ２０１とを対応付けて管理する。なお、図中、識別子をＩＤと略記する。本実施例では、記憶装置２３０を、便宜上ディスクと表現している。

ディスク識別子Ｃ２００は、各記憶装置２３０を識別するための情報である。物理ページ識別子Ｃ２０１は、各物理ページ２４１を識別するための情報である。この表Ｔ２０を用いることで、どの記憶装置２３０にどの物理ページ２４１が存在するかを調べることができる。

図６は、ストレージ装置２０の有するディスク管理表Ｔ２１を示す。ディスク管理表Ｔ２１は、ストレージ装置２０の有する各記憶装置２３０を管理する表である。ディスク管理表Ｔ２１は、例えば、ディスク識別子Ｃ２１０と、ディスク種別Ｃ２１１と、ＲＡＩＤ（Redundant Arrays of Inexpensive Disks）レベルＣ２１２を対応付けて管理する。

ディスク識別子Ｃ２１０は、図５で述べたディスク識別子Ｃ２００と同様に、各記憶装置２３０を識別するための情報である。ディスク種別Ｃ２１１は、各記憶装置２３０の種類（例えば、ＳＳＤ、ＳＡＳ、ＳＡＴＡ等）を示す。ＲＡＩＤレベルＣ２１２は、ＲＡＩＤ構成のレベルを示す。ＲＡＩＤレベルとしては、例えば、ＲＡＩＤ１、ＲＡＩＤ５、ＲＡＩＤ６等がある。

図７は、ストレージ装置２０の有する階層管理表を示す。階層管理表Ｔ２２は、プール２６０を構成する各記憶階層２６１Ａ〜２６１Ｃを管理するための表である。以下、記憶階層を階層と略記する場合がある。また、特に区別しない場合、各階層２６１Ａ〜２６１Ｃを、階層２６１と呼ぶことがある。

階層管理表Ｔ２２は、例えば、階層識別子Ｃ２２０と、ディスク識別子Ｃ２２１とを対応付けて管理する。階層識別子Ｃ２２０は、各階層２６１を識別する情報である。ディスク識別子Ｃ２２１は、各階層２６１に登録される記憶装置２３０の識別子である。階層管理表Ｔ２２を用いることで、どの階層２６１にどの記憶装置２３０が登録されているかを調べることができる。

図８は、ストレージ装置２０の有するプール階層管理表Ｔ２３を示す。プール階層管理表Ｔ２３は、プール２６０の階層構成を管理する表である。

プール階層管理表Ｔ２３は、例えば、プール識別子Ｃ２３０と、階層識別子Ｃ２３１と、特性Ｃ２３２と、性能順位Ｃ２３３と、許容Ｉ／Ｏ数Ｃ２３４とを対応付けて管理している。

プール識別子Ｃ２３０は、ストレージ装置２０の有する各プール２６０を識別するための情報である。階層識別子Ｃ２３１は、プール２６０に含まれる各階層２６１を識別するための情報である。特性Ｃ２３２は、階層２６１の性能特性を示す。特性Ｃ２３２は、例えば、ディスク種別とＲＡＩＤレベルとで記述することができる。ディスク種別及びＲＡＩＤレベルという属性に限らず、他の属性で特性Ｃ２３２を定義してもよい。性能順位Ｃ２３３は、階層２６１の順位を示す。順位の数字が小さいほど、高性能な階層である。性能順位Ｃ２３３は、許容Ｉ／Ｏ数Ｃ２３４に含まれる下限値及び上限値から計算することができる。

許容Ｉ／Ｏ数Ｃ２３４は、階層２６１が許容するＩ／Ｏ数の上限値及び下限値を示す情報である。階層２６１に属する或る論理ページ２７１のデータへのＩ／Ｏ数が、その階層２６１の許容する上限値を超えた場合、その論理ページ２７１は、一般的には、より上位の階層に再配置されるべきである。逆に、階層２６１に属する他の論理ページ２７１のデータへのＩ／Ｏ数が、その階層２６１の許容する下限値を下回った場合、その論理ページ２７１は、一般的には、より下位の階層に再配置されるべきである。階層毎に予め定義されているＩ／Ｏ数の範囲内で、論理ページ２７１のデータが階層間を移動する。なお、本実施例では、後述のように、仮想ボリューム２７０の使用状況に応じて、論理ページ２７１の再配置先が決定される。

図９は、ストレージ装置２０が有する論理ページ管理表Ｔ２４を示す。論理ページ管理表Ｔ２４は、仮想ボリューム２７０を構成する各論理ページ２７１を管理するための表である。

論理ページ管理表Ｔ２４は、例えば、プール識別子Ｃ２４０と、仮想ボリューム識別子Ｃ２４１と、論理ページ識別子Ｃ２４２と、Ｉ／Ｏ数Ｃ２４３と、階層識別子Ｃ２４４とを対応付けて管理する。

プール識別子Ｃ２４０は、プール２６０を識別するための情報である。仮想ボリューム識別子Ｃ２４１は、仮想ボリューム２７０を識別するための情報である。論理ページ識別子Ｃ２４２は、仮想ボリューム２７０を構成する各論理ページ２７１を識別するための情報である。Ｉ／Ｏ数Ｃ２４３は、各論理ページ２７１に対するＩ／Ｏ数である。階層識別子Ｃ２４４は、論理ページ２７１の配置先の階層を特定する情報である。

図１０は、ストレージ装置２０が有する、物理ページ−論理ページ対応管理表Ｔ２５を示す。物理ページ−論理ページ対応管理表Ｔ２５は、物理ページ２４１と論理ページ２７１の対応関係を管理する。この表Ｔ２５は、物理ページ識別子Ｃ２５０と、論理ページ識別子Ｃ２５１を対応付けて管理する。

図１１は、管理サーバ３０の構成を示す。管理サーバ３０は、例えば、マイクロプロセッサ３１０と、メモリ３２０と、管理用通信ネットワークＣＮ２に接続するための通信ポート３３０とを備える。メモリ３２０には、ストレージ管理プログラムＰ３０と、複数の表Ｔ３０〜Ｔ３９とが格納されている。

ストレージ管理プログラムＰ３０は、ストレージ装置２０を管理するためのコンピュータプログラムである。ストレージ管理プログラムＰ３０は、後述する複数のプログラムモジュールＰ３１〜Ｐ３６を備える。

図１２は、管理サーバ３０が具備するアプリケーション管理表Ｔ３０を示す。アプリケーション管理表Ｔ３０は、ホスト１０上で稼働する各種のアプリケーションＰ１０を管理する表である。

アプリケーション管理表Ｔ３０は、例えば、アプリケーション識別子Ｃ３００と、仮想ボリューム識別子Ｃ３０１とを対応付けて管理する。アプリケーション識別子Ｃ３００は、アプリケーションＰ１０を識別する情報である。仮想ボリューム識別子Ｃ３０１は、アプリケーションＰ１０が使用する仮想ボリューム２７０を識別する情報である。アプリケーション管理表Ｔ３０は、ユーザが設定することができる。ストレージ装置２０から取得する構成情報と、ホスト１０から取得する構成情報とに基づいて、管理サーバ３０がアプリケーション管理表Ｔ３０を自動的に作成することもできる。なお、ユーザとは、例えば、計算機システムを管理する管理者である。

図１３は、管理サーバ３０が有する、論理ページの負荷実データの履歴を管理するための表Ｔ３１を示す。以下、論理ページの負荷実データ履歴管理表を、負荷実データ管理表と略記する。同様に、「論理ページ」という言葉を、表の名称から省いて表示する場合がある。

負荷実データ履歴表Ｔ３１は、各論理ページ２７１のＩ／Ｏ数と各論理ページ２７１の配置先の階層とを、各モニタリング期間ごとに記憶する。負荷実データ履歴管理表Ｔ３１は、例えば、アプリケーション識別子Ｃ３１０と、プール識別子Ｃ３１１と、仮想ボリューム識別子Ｃ３１２と、論理ページ識別子Ｃ３１３と、モニタリング期間Ｃ３１４と、Ｉ／Ｏ数Ｃ３１５と、階層識別子Ｃ３１６とを対応付けて管理する。

アプリケーション識別子Ｃ３１０は、アプリケーションＰ１０を識別するための情報である。プール識別子Ｃ３１１は、プール２６０を識別する情報である。仮想ボリューム識別子Ｃ３１２は、仮想ボリューム２７０を識別する情報である。論理ページ識別子Ｃ３１３は、各論理ページ２７１を識別する情報である。

モニタリング期間Ｃ３１４は、論理ページ２７１へのＩ／Ｏ数を監視する期間であり、本実施例では、例えば、１時間毎にＩ／Ｏ数を集計している。Ｉ／Ｏ数Ｃ３１５は、モニタリング期間内に論理ページ２７１に向けて発行されたＩ／Ｏ数の合計値である。階層識別子Ｃ３１６は、論理ページ２７１の配置先の階層を特定する情報である。

負荷実データ履歴表Ｔ３１を用いることにより、各論理ページ２７１のモニタリング期間毎のＩ／Ｏ数の変化と、各論理ページ２７１が配置された階層２６１の変遷とを、調べることができる。

論理ページの負荷実データを収集するためのモジュールＰ３２が、ストレージ装置２０内の論理ページ管理表Ｔ２４からモニタリング期間毎に収集したデータを時系列で記録することで、負荷実データ履歴表Ｔ３１が作成される。

図１４は、論理ページの負荷を評価したデータの履歴を管理する表Ｔ３２を示す。以下、負荷評価データ履歴表Ｔ３１と呼ぶ。負荷評価データ履歴表Ｔ３２は、例えば、アプリケーション識別子Ｃ３２０と、プール識別子Ｃ３２１と、仮想ボリューム識別子Ｃ３２２と、論理ページ識別子Ｃ３２３と、評価対象モニタリング期間Ｃ３２４と、Ｉ／Ｏ数評価値Ｃ３２５と、次期階層識別子Ｃ３２６とを対応付けて管理する。

アプリケーション識別子Ｃ３２０は、アプリケーションＰ１０を識別するための情報である。プール識別子Ｃ３２１は、プール２６０を識別する情報である。仮想ボリューム識別子Ｃ３２２は、仮想ボリューム２７０を識別する情報である。論理ページ識別子Ｃ３２３は、各論理ページ２７１を識別する情報である。

評価対象モニタリング期間Ｃ３２４は、論理ページの負荷を評価するために使用されたモニタリング期間である。Ｉ／Ｏ数評価値Ｃ３２５は、各評価対象モニタリング期間Ｃ３２４毎に、各論理ページ２７１のＩ／Ｏ数を評価した値を記憶する。Ｉ／Ｏ数評価値Ｃ３２５は、単一期間モードに従って算出されたＩ／Ｏ数と、複数期間平均モードに従って算出されたＩ／Ｏ数とを、評価値としてそれぞれ記憶する。単一期間モード及び複数期間平均モードについては、後述する。なお、図中では、単一期間モードを単一モードと、複数期間平均モードを複数モードと、それぞれ略記する場合がある。

次期階層識別子Ｃ３２６は、次のページ再配置処理で論理ページ２７１が配置されるべき階層を示す。次期階層識別子Ｃ３２６は、単一期間モードに従う場合の配置先階層と、複数期間平均モードに従う場合の配置先階層とを、それぞれ記憶する。

本実施例では、単一期間モード及び複数期間平均モードのそれぞれについて、Ｉ／Ｏ数の評価値及び次期の配置先階層とを算出して記憶する。これにより、後述する設定画面Ｇ１０に、両方のモードでの算出結果をユーザに提示することができ、ユーザの判断を助けることができる。

単一期間モードと複数期間平均モードを説明する。本実施例では、論理ページ２７１へのＩ／Ｏをモニタリングするための方法（モニタリング方式）として、単一期間モードと、複数期間平均モードの２つを用いる。

「第１モニタリングモード」の例である単一期間モードとは、最新の一つのモニタリング期間に着目して、論理ページの負荷を評価する方法である。単一期間モードでは、最新の単一のモニタリング期間におけるＩ／Ｏ数のみを監視し、そのＩ／Ｏ数に基づいて負荷を評価する。単一期間モードにおけるモニタリング期間（第１モニタリング期間）は、一つの単位時間分の期間である。本実施例では、単位時間を１時間に設定するため、単一期間モードのモニタリング期間は、最新の１時間となる。

「第２モニタリングモード」の例である複数期間平均モードとは、最新の連続する複数のモニタリング期間のＩ／Ｏ数を監視し、そのＩ／Ｏ数の平均に基づいて負荷を評価する方法である。複数期間平均モードのモニタリング期間（第２モニタリング期間）は、本実施例では、例えば３時間に設定される。複数期間平均モードでは、３時間分のＩ／Ｏ数の平均値を、論理ページ２７１の負荷として評価する。

単一期間モードは、比較的短期間におけるＩ／Ｏ数の細かな変動の影響を反映しやすいという特徴がある。逆に、複数期間平均モードは、短期間のＩ／Ｏ数の細かな変動に左右されにくいという特徴がある。

例えば、Ｉ／Ｏ数の大きい状態が比較的長い時間にわたって継続するアプリケーション（Ａ）により使用される仮想ボリューム２７０の論理ページ２７１を、単一期間モードでモニタリングする場合を検討する。この場合、Ｉ／Ｏ数の大きい期間中における応答性能を安定させるのが難しい。たとえ一時的にせよＩ／Ｏ数が低下すると、低性能の階層２６１Ｃ（または２６１Ｂ）に移動されるためである。

Ｉ／Ｏ数の大きい状態の継続する時間が比較的短いアプリケーション（Ｂ）により使用される仮想ボリューム２７０の論理ページ２７１を、複数期間平均モードでモニタリングする場合を検討する。この場合、使用頻度の少ない論理ページ２７１であるにもかかわらず、その論理ページ２７１は、高性能な階層２６１に長時間滞在することになる。その分だけ、他の論理ページ２７１が高性能な階層２６１Ａに昇格する可能性が低下する。従って、ストレージ装置２０全体としての応答性能が低下する。

プール２６０毎にモニタリング方式を設定することも可能である。異なるＩ／Ｏ特性を有するアプリケーション（Ａ）、（Ｂ）により使用される仮想ボリューム２７０が、共通のプール２６０に存在する場合を検討する。モニタリング方式を単一期間モードに設定すると、アプリケーション（Ａ）に使用される仮想ボリューム２７０は、応答性能が不安定になる可能性がある。逆に、プール２６０のモニタリング方式を複数期間平均モードに設定すると、高性能な階層２６１Ａが無駄に使用されるおそれがある。

そこで、本実施例では、単一期間モードと複数期間平均モードとの複数のモニタリング方式を用意し、各仮想ボリューム２７０のＩ／Ｏ特性に適した方のモニタリング方式を自動的に選択できるようにしている。

図１５は、管理サーバ３０が具備するモニタリング方式定義表Ｔ３３を示す。この定義表Ｔ３３は、管理サーバ３０が利用可能なモニタリング方式を定義している。定義表Ｔ３３は、例えば、モニタリング方式識別子Ｃ３３０と、Ｉ／Ｏ負荷評価関数Ｃ３３１と、モニタリング期間数Ｃ３３２と、基準値未満の場合のモニタリング方式識別子Ｃ３３３と、基準値以上の場合のモニタリング方式識別子Ｃ３３４とを備える。

モニタリング方式識別子Ｃ３３０は、単一期間モードと複数期間平均モードとを区別するための情報である。Ｉ／Ｏ負荷評価関数Ｃ３３１とは、Ｉ／Ｏ負荷を評価するための関数を定義する情報であり、具体的には、コンピュータプログラム中の関数へのポインタである。モニタリング期間数Ｃ３３２とは、Ｉ／Ｏ数をモニタリングする期間を示す。

基準値未満の場合のモニタリング方式識別子Ｃ３３３とは、階層滞留率が階層滞留率基準値よりも小さい場合に、選択されるモニタリング方式である。これに対し、基準値以上の場合のモニタリング方式識別子Ｃ３３４とは、階層滞留率が階層滞留率基準値以上の場合に、選択されるモニタリング方式である。選択されたモニタリング方式は、次のモニタリング期間において、使用される。

階層滞留率とは、所定の配置基準時間に対する、論理ページが現在の階層に滞留している時間の割合である。本実施例では、一例として、配置基準時間を３時間に設定するが、この値は変更可能である。或る論理ページ２７１が或る階層２６１に２時間留まった場合、階層滞留率は約６７％となる。配置基準時間を、「階層滞留率を計算するためのモニタリング期間」と呼ぶことがある。

階層滞留率が階層滞留率基準値に満たない場合は、次期のモニタリング方式として単一期間モードが選択される。階層滞留率が階層滞留率基準値以上の場合、次期のモニタリング方式として複数期間平均モードが選択される。ストレージ管理プログラムＰ３０は、予め設定された階層滞留率基準値と階層滞留率とを比較することで、仮想ボリューム２７０に適用するモニタリング方式を、仮想ボリューム毎に決定する。

図１６は、管理サーバ３０が有するプール階層管理表Ｔ３４を示す。プール階層管理表Ｔ３４は、プール２６０の階層２６１を管理する。プール階層データ収集モジュールＰ３１は、ストレージ装置２０内のプール階層管理表Ｔ２３から情報を収集し、プール階層管理表Ｔ３４を作成する。ストレージ装置２０のプール階層管理表Ｔ２３と、管理サーバ３０のプール階層管理表Ｔ３４とは同一内容である。項目Ｃ３４０〜Ｃ３４４は、図８の項目Ｃ２３０〜Ｃ２３４に対応するため、重複した説明を省略する。プール階層管理表Ｔ３４を管理サーバ３０に配置する構成に代えて、ストレージ管理プログラムＰ３０は、必要に応じて、ストレージ装置２０のプール階層管理表Ｔ２３からエントリを直接取得する構成でもよい。

図１７は、管理サーバ３０が有する、論理ページ毎の階層滞留率の履歴を管理する表Ｔ３５である。階層滞留率管理表Ｔ３５は、例えば、論理ページ識別子Ｃ３５０と、評価対象モニタリング期間Ｃ３５１と、階層滞留率Ｃ３５２とを対応付けて管理する。

論理ページ識別子Ｃ３５０は、各論理ページ２７１を識別する情報である。評価対象モニタリング期間Ｃ３５１は、階層滞留率の算出対象となった期間を示す。階層滞留率Ｃ３５２は、各モニタリング方式（単一期間モード、複数期間平均モード）毎に算出された階層滞留率を記憶する。階層滞留率は、論理ページ階層滞留率計算モジュールＰ３４によって、モニタリング方式ごとに計算される。

図１８は、管理サーバ３０が有する、階層滞留率を計算するためのモニタリング期間を管理する表Ｔ３６である。

階層滞留率を計算するためのモニタリング期間とは、上述の配置基準時間であり、階層滞留率を計算する際に、計算の入力とする過去の履歴の範囲（最新のエントリからどれくらい前まで遡るか）を規定する値である。

本実施例では、階層滞留率を計算するためのモニタリング期間として、単位時間の個数で表現する。これに代えて、開始時刻と終了時刻を特定する構成でもよい。階層滞留率を計算するためのモニタリング期間の値は、ユーザが変更することもできるし、ストレージ管理プログラムＰ３０が所定の基準に従って自動的に調整することもできる。

図１９は、管理サーバ３０が有する、階層滞留率の基準値を管理するための表Ｔ３７を示す。階層滞留率の基準値は、「モニタリングモード選択用基準値」に対応する。フローチャートの説明では、階層滞留率の基準値を、モニタリング方式を切り替えるための切替基準値と呼ぶ。

論理ページモニタリング方式選択モジュールＰ３５は、論理ページ毎の階層滞留率と基準値の大小関係を判定することで、論理ページ毎にモニタリング方式を選択する。

本実施例では、単一期間モード及び複数期間平均モードの２つのモニタリング方式を使用するため、基準値は１つでよい。３つ以上のモニタリング方式の中から一つのモニタリング方式を選択する構成の場合は、モニタリング方式の総数から１を減じた数だけ、基準値を用意する。

なお、複数期間平均モードには種々の変形例があり得る。本実施例では、最も単純な例として、相加平均による複数期間平均モードを定義する。これに代えて、加重平均による複数期間平均モードを採用してもよい。さらに、加重の度合いを変えたり、モニタリング期間数を変えたりすることで、より多くの種類の複数期間平均モードを利用可能である。それら複数の変形例も、本発明の範囲に含まれる。

本実施例では、階層滞留率の基準値を７０％に設定する場合を例に挙げて説明する。基準値は７０％以外の他の値に設定してもよい。ユーザが基準値を設定してもよいし、ストレージ管理プログラムＰ３０が所定の基準に基づいて自動的に基準値を設定する構成でもよい。本実施例では、仮想ボリューム毎にモニタリング方式を設定するため、階層滞留率の基準値も仮想ボリューム毎に保持される。

図２０は、管理サーバ３０が有する、論理ページのモニタリング方式の履歴を管理する表Ｔ３８である。

モニタリング方式履歴管理表Ｔ３８は、例えば、論理ページ識別子Ｃ３８０と、評価対象モニタリング期間Ｃ３８１と、次期候補モニタリング方式識別子Ｃ３８２を対応付けて管理する。

次期候補モニタリング方式識別子Ｃ３８２は、次のモニタリング期間で使用される予定のモニタリング方式の候補を特定する。次期モニタリング方式候補は、論理ページモニタリング方式選択モジュールＰ３５によって選択される。

図２１は、管理サーバ３０が有する、仮想ボリューム毎に選択されるモニタリング方式の履歴を管理する表Ｔ３９である。本実施例では、各論理ページ毎にモニタリング方式の候補を算出し、そのうち最も多い候補を、仮想ボリューム全体に適用されるモニタリング方式として選択する。

そのために、モニタリング方式履歴表Ｔ３９は、仮想ボリューム識別子Ｃ３９０と、評価対象モニタリング期間Ｃ３９１と、次期モニタリング方式識別子Ｃ３９２とを対応付けて管理する。

なお、いわゆる多数決で次のモニタリング期間に適用されるモニタリング方式を選択する構成に代えて、仮想ボリューム内のいずれか一つでもモニタリング方式が変更された場合は、その変更されたモニタリング方式を選択する構成でもよい。

例えば、仮想ボリューム２７０に単一期間モードが適用されている場合において、その仮想ボリューム２７０を構成する各論理ページ２７１のうち、いずれか一つでも複数期間平均モードに変化したときを考える。この場合、次のモニタリング期間において、その仮想ボリュームには、複数期間平均モードが適用される。
一つの仮想ボリューム２７０を構成する各論理ページ２７１のうち、特定の論理ページについてのＩ／Ｏ負荷が先行して変化する場合が考えられる。その場合は、いち早くＩ／Ｏ負荷が変化した論理ページに合わせて、仮想ボリューム全体に適用されるモニタリング方式を変更する。これにより、Ｉ／Ｏ特性の変化に速やかに追従できる。

なお、本実施例では、仮想ボリューム単位でモニタリング方式を選択する場合を説明するが、後述する他の実施例のように、アプリケーション単位でモニタリング方式を選択してもよい。または、論理ページ毎にモニタリング方式を選択してもよい。本実施例では、論理ページ毎にモニタリング方式を算出するが、それは仮想ボリューム全体に適用するモニタリング方式の候補を抽出するためである。本実施例では、仮想ボリューム毎にモニタリング方式が一つ選択される。これに代えて、上述のように、同一の仮想ボリューム内の各論理ページ毎に、各論理ページのＩ／Ｏ負荷に応じて、それぞれ異なるモニタリング方式を適用してもよい。

図２２、図２３は、プログラムモジュールと表の関係を示す説明図である。図２２は、主に管理サーバ３０について示しており、図２３は、主にストレージ装置２０について示している。図中の点線矢印は、参照を示す。図中の実線矢印は、更新を示す。図中の一点鎖線矢印は、要求の送信を示す。

例えば、プール階層データ収集モジュールＰ３１は、ストレージ装置２０のプール階層データ提供モジュールＰ２３に情報の送信を要求し、プール階層データ提供モジュールＰ２３から情報を取得する。プール階層データ収集モジュールＰ３１は、取得した情報をプール階層管理表Ｔ３４に記憶させる。

本実施例では、管理サーバ３０上のストレージ管理プログラムＰ３０は、選択されたモニタリング期間に従って、ストレージ装置２０から定期的に所定の情報を収集し、以下の処理を実行する。各処理の詳細は後述するが、先に概要を説明する。

まず、ストレージ管理プログラムＰ３０は、論理ページのＩ／Ｏ数と、滞留する階層の情報とを、論理ページの負荷実データとして取得する。

ストレージ管理プログラムＰ３０は、負荷実データに基づいて、各モニタリング方式毎に、Ｉ／Ｏ数の評価値と、再配置先として適当な階層の組とを計算する。これらＩ／Ｏ数の評価値及び再配置先の階層との組を、論理ページの負荷評価データと呼ぶ。

ストレージ管理プログラムＰ３０は、論理ページ負荷評価データに基づいて、各モニタリング方式毎に、階層滞留率を算出する。階層滞留率とは、所定の配置基準時間に対する、論理ページが現在の階層に滞留している時間の割合である。配置基準時間は、ユーザが変更することもできる。本実施例では、例えば、配置基準時間を３時間に設定する。以下の説明では、配置基準時間を、「階層滞留率を計算するためのモニタリング期間」と呼ぶことがある。

ストレージ管理プログラムＰ３０は、予め設定された階層滞留率基準値と階層滞留率とを比較することで、仮想ボリューム２７０に適用するモニタリング方式を、仮想ボリューム毎に選択する。最後に、ストレージ管理プログラムＰ３０は、選択したモニタリング方式に基づいて、論理ページ２７１の再配置先の階層を決定する。Ｉ／Ｏ数のモニタリングと論理ページの再配置とは、並行的に実行される。

本実施例では、以上の処理を実施することで、各仮想ボリューム２７０に適用されるモニタリング方式を、階層滞留率に従って自動的に選択する。これにより、各仮想ボリューム２７０の使用のされ方（Ｉ／Ｏ特性）に応じて、単一期間モードまたは複数期間平均モードのいずれか一つを選択できる。この結果、Ｉ／Ｏ特性に応じて、各論理ページ２７１を最適な階層２６１に配置することができる。

モニタリング方式の選択は、論理ページの再配置先階層の決定について大きな影響を与える。従って、モニタリング方式は、論理ページのＩ／Ｏ特性に基づいて選択されることが望ましい。その一方、階層滞留率は、論理ページのＩ／Ｏ特性の一側面である、Ｉ／Ｏ負荷の大きい期間の長さの傾向、を数値化したものである。そこで、モニタリング方式と階層滞留率とを組み合わせることで、Ｉ／Ｏ特性に応じた論理ページの最適配置が可能になる。

ところで、階層滞留率の計算処理は、ページ再配置先の階層の決定を介して、フィードバックループを構成する。その結果、一度選択されたモニタリング方式の持つＩ／Ｏ負荷評価の特性は、長期にわたって継続することがある。複数のモニタリング期間について履歴情報に基づいて計算を行う複数期間平均モードでは、この傾向が特に顕著である。

階層滞留率は、モニタリング方式の選択に利用される。選択されたモニタリング方式を用いて算出された負荷評価データは、論理ページの再配置先の階層を選択するために利用される。再配置先の階層は、次回の処理実行時の階層滞留率の計算に利用される。そして、その計算結果がモニタリング方式の選択に利用される。

そこで、本実施例では、Ｉ／Ｏ数および再配置先の階層の実データと、それぞれのモニタリング方式を適用した場合に算出される各評価値（Ｉ／Ｏ数評価値、移動先候補の階層、階層滞留率）の履歴データとを記憶する。これにより、本実施例では、実データと評価値の乖離を防ぎ、Ｉ／Ｏ数の変化に追従した、適切なモニタリング方式を速やかに選択できるようにしている。

図２４は、ストレージ装置２０のプール階層データ提供モジュールＰ２３による処理を示すフローチャートである。

プール階層データ提供モジュールＰ２３は、管理サーバ３０上のプール階層データ収集モジュールＰ３１からの取得要求を受信すると（Ｓ１０）、ストレージ装置２０の有するプール階層管理表Ｔ２３に記憶された情報を取得する（Ｓ１１）。プール階層データ提供モジュールＰ２３は、取得した情報を、プール階層データ収集モジュールＰ３１に送信する（Ｓ１２）。

図２５は、ストレージ装置２０の論理ページ負荷実データ提供モジュールＰ２１の処理を示すフローチャートである。

負荷実データ提供モジュールＰ２１は、管理サーバ３０上の論理ページ負荷実データ収集モジュールＰ３２からの取得要求を受信すると（Ｓ２０）、ストレージ装置２０の論理ページ管理表Ｔ２４の情報を取得する（Ｓ２１）。

負荷実データ提供モジュールＰ２１は、取得した情報を負荷実データ収集モジュールＰ３２に送信する（Ｓ２２）。最後に、負荷実データ提供モジュールＰ２１は、論理ページ管理表Ｔ２４のＩ／Ｏ数Ｃ２４３の値を全て０に設定する（Ｓ２３）。

図２６は、ストレージ装置２０の論理ページ再配置実行モジュールＰ２２の処理を示すフローチャートである。

再配置実行モジュールＰ２２は、管理サーバ３０上の論理ページ再配置指示モジュールＰ３６からの再配置要求を受信する（Ｓ３０）。その再配置要求は、論理ページ識別子と再配置先の階層の識別子との対応関係を示すマップとして構成される。

再配置実行モジュールＰ２２は、論理ページ管理表Ｔ２４から、現在の、論理ページと階層との対応関係を取得して、以下のように再配置を実施する（Ｓ３１）。まず、再配置実行モジュールＰ２２は、現在の対応関係とマップに示された対応関係とが一致するか否か判定する。

一致の場合、再配置実行モジュールＰ２２は、対象の論理ページの再配置は不要であると判定する。不一致の場合、再配置実行モジュールＰ２２は、対象の論理ページの再配置が必要であると判定する。

再配置が必要であると判定した場合、再配置実行モジュールＰ２２は、プール階層管理表Ｔ２３と、階層管理表Ｔ２２と、物理ページ管理表Ｔ２０と、物理ページ−論理ページ対応管理表Ｔ２５とを参照して、再配置先の階層内の空き物理ページを検索する。再配置実行モジュールＰ２２は、対象の論理ページに対応する物理ページに格納されたデータを、検索した空き物理ページにコピーする。最後に、再配置実行モジュールＰ２２は、物理−論理ページ対応管理表Ｔ２５の、物理ページと論理ページとの対応関係を書き換える（Ｓ３１）。

図２７は、管理サーバ３０のストレージ管理プログラムＰ３０の処理を示すフローチャートである。本実施例では、一例として、論理ページの再配置先を決定する処理を毎正時に実行する（Ｓ４０）。

ストレージ管理プログラムＰ３０は、まず最初に、プール階層データ収集モジュールＰ３１を実行する（Ｓ４１）。続いて、ストレージ管理プログラムＰ３０は、論理ページ負荷実データ収集モジュールＰ３２を実行し（Ｓ４２）、論理ページ負荷評価モジュールＰ３３を実行する（Ｓ４３）。

さらに、ストレージ管理プログラムＰ３０は、論理ページ階層滞留率計算モジュールＰ３４を実行し（Ｓ４４）、論理ページモニタリング方式選択モジュールＰ３５を実行する（Ｓ４５）。最後に、ストレージ管理プログラムＰ３０は、論理ページ再配置指示モジュールＰ３６を実行する（Ｓ４６）。

図２８は、管理サーバ３０のプール階層データ収集モジュールＰ３１の処理を示すフローチャートである。プール階層データ収集モジュールＰ３１は、ストレージ装置２０のプール階層データ提供モジュールＰ２３に対して、取得要求を送信する（Ｓ５０）。

プール階層データ収集モジュールＰ３１は、プール階層データ提供モジュールＰ２３から情報を取得する（Ｓ５１）。プール階層データ収集モジュールＰ３１は、管理サーバ３０のプール階層管理表Ｔ３４を初期化し（Ｓ５２）、プール階層データ提供モジュールＰ２３から取得した情報をプール階層管理表Ｔ３４に記憶させる（Ｓ５３）。

図２９は、管理サーバ３０の論理ページ負荷実データ収集モジュールＰ３２の処理を示すフローチャートである。

負荷実データ収集モジュールＰ３２は、現在時刻を取得し（Ｓ６０）、ストレージ装置２０の論理ページ負荷実データ提供モジュールＰ２１に取得要求を送信し（Ｓ６１）、負荷実データ提供モジュールＰ２１から情報を取得する（Ｓ６２）。

負荷実データ収集モジュールＰ３２は、取得した全てのエントリについて、ステップＳ６４及びステップＳ６５を実行する（Ｓ６３）。

負荷実データ収集モジュールＰ３２は、取得されたエントリの仮想ボリューム識別子Ｃ２４１に対応するアプリケーション識別子を、アプリケーション管理表Ｔ３０から取得する（Ｓ６４）。

負荷実データ収集モジュールＰ３２は、論理ページ負荷実データ履歴表Ｔ３１に、ストレージ装置２０から取得したエントリの情報と、アプリケーション識別子と、現在時刻から定まるモニタリング期間とを追加する（Ｓ６５）。

これにより、管理サーバ３０の論理ページ負荷実データ履歴表Ｔ３１に、ストレージ装置２０の最新モニタリング期間における、論理ページのＩ／Ｏ数と配置先階層の識別子とが追加される。

図３０は、管理サーバ３０の論理ページ負荷評価モジュールＰ３３の処理を示すフローチャートである。

負荷評価モジュールＰ３３モジュールＰ３３は、論理ページ負荷実データ履歴表Ｔ３１から、最新のモニタリング期間の全ての実データエントリを取得する（Ｐ７０）。負荷評価モジュールＰ３３は、全ての実データエントリについて、以下のステップＳ７２〜Ｓ７８を実行する（Ｓ７１）。

負荷評価モジュールＰ３３は、モニタリング方式定義表Ｔ３３から、全ての方式定義エントリを取得する（Ｓ７２）。負荷評価モジュールＰ３３は、全ての方式定義エントリについて、以下のステップＳ７４〜Ｓ７８を実行する（Ｓ７３）。

負荷評価モジュールＰ３３は、Ｉ／Ｏ数の評価値を計算するための処理を実行する（Ｓ７４）。この処理の詳細は、図３１で後述する。負荷評価モジュールＰ３３は、ステップＳ７４から戻り値（Ｉ／Ｏ数評価値）を取得すると（Ｓ７５）、次期の配置先階層を選択するための処理を実行する（Ｓ７６）。この次期階層選択処理については、図３２で後述する。

負荷評価モジュールＰ３３は、ステップＳ７６から戻り値（次期階層ＩＤ）を取得すると（Ｓ７７）、論理ページ負荷評価データ履歴表Ｔ３２に、実データエントリの持つ各属性と、各方式定義エントリのモニタリング方式ＩＤと、Ｉ／Ｏ数評価値と、次期階層識別子とを、新たなエントリとして追加する（Ｓ７８）。

上述の通り、本実施例では、Ｉ／Ｏ数評価値は、管理サーバ３０に登録されている全てのモニタリング方式（単一期間モード、複数期間平均モード）について計算する。

図３１は、図３０中にステップＳ７４で示す、Ｉ／Ｏ数評価値計算処理のフローチャートである。

負荷評価モジュールＰ３３は、論理ページ負荷実データ履歴表Ｔ３１から、モニタリング方式に応じたモニタリング期間数分のＩ／Ｏ数を取得する（Ｓ８０）。負荷評価モジュールＰ３３は、モニタリング方式定義表Ｔ３３に定義されているモニタリング方式の負荷評価関数を呼び出し、論理ページのＩ／Ｏ負荷の評価値を計算する（Ｓ８１）。負荷評価モジュールＰ３３は、計算結果を図３０のフローチャートに返す（Ｓ８２）。

図３２は、図３０中にステップＳ７６で示した、次期階層選択処理のフローチャートである。

負荷評価モジュールＰ３３は、プール階層管理表Ｔ３４から全ての特性エントリを取得する（Ｓ９０）。特性エントリは、性能順位順にソート済みである。

負荷評価モジュールＰ３３は、全ての特性エントリについて、以下のステップＳ９２を実行する（Ｓ９１）。負荷評価モジュールＰ３３は、図３１で算出したＩ／Ｏ数評価値が、許容Ｉ／Ｏ数Ｃ３４４の下限値よりも大きいか判定する（Ｓ９２）。

Ｉ／Ｏ数評価値が下限値よりも大きくないと判定された場合（Ｓ９２：ＮＯ）、負荷評価モジュールＰ３３は、最も性能の低い階層２６１Ｃの階層識別子を、図３０の処理に返す（Ｓ９３）。

Ｉ／Ｏ数評価値が下限値よりも大きいと判定された場合（Ｓ９２：ＹＥＳ）、負荷評価モジュールＰ３３は、現在の階層の識別子を、図３０の処理に返す（Ｓ９４）。なお、本実施例では、各階層の許容Ｉ／Ｏ数Ｃ３４４の下限値を基準として、再配置先の階層を選択する構成であるが、これに代えて、特性エントリを性能の低い順にソートし、許容Ｉ／Ｏ数の上限値を基準に再配置先の階層を選択する構成としてもよい。

図３３は、管理サーバ３０の論理ページ階層滞留率計算モジュールＰ３４の処理を示すフローチャートである。

階層滞留率計算モジュールＰ３４は、論理ページ負荷評価データ履歴表Ｔ３２から、最新のモニタリング期間における、全ての評価データエントリを取得する（Ｓ１００）。階層計算モジュールＰ３４は、全ての評価データエントリについて、以下のステップＳ１０２〜Ｓ１１１を実行する（Ｓ１０１）。

階層滞留率計算モジュールＰ３４は、階層滞留率計算モニタリング期間管理表Ｔ３６から、計算対象となるモニタリング期間の数（対象期間数）を取得する（Ｓ１０２）。階層滞留率計算モジュールＰ３４は、論理ページ負荷評価データ履歴表Ｔ３２から、最新の対象期間数分の、性能評価データの履歴エントリを取得する（Ｓ１０３）。

階層滞留率計算モジュールＰ３４は、各モニタリング方式（単一期間モード、複数期間平均モード）について、以下のステップＳ１０５〜Ｓ１１０を実行する（Ｓ１０４）。階層滞留率計算モジュールＰ３４は、最も高性能の階層に滞留する期間の数をカウントするための最高階層滞留期間数を、０に設定する（Ｓ１０５）。

階層滞留率計算モジュールＰ３４は、全ての評価データの履歴エントリについて、以下のステップＳ１０７〜Ｓ１１１を実行する（Ｓ１０６）。階層滞留率計算モジュールＰ３４は、プール階層管理表Ｔ３４を参照して、評価データの履歴エントリの性能順位を取得する（Ｓ１０７）。

階層滞留率計算モジュールＰ３４は、取得した性能順位が「１」であるかを判定する（Ｓ１０８）。つまり、最も高性能の階層２６１Ａについての履歴エントリであるかが判定される。

性能順位が「１」の場合（Ｓ１０８：ＹＥＳ）、階層滞留率計算モジュールＰ３４は、最高階層滞留期間数の値を１つだけインクリメントする（Ｓ１０９）。性能順位が「１」ではない場合（Ｓ１０８：ＮＯ）、ステップＳ１０９はスキップされて、ステップＳ１１０に移る。

階層滞留率計算モジュールＰ３４は、最高階層滞留期間数を、ステップＳ１０２で取得した対象期間数で割ることで、階層滞留率を算出する（Ｓ１１０）。階層滞留率計算モジュールＰ３４は、算出された階層滞留率を、論理ページ階層滞留率履歴表Ｔ３５に記憶させる（Ｓ１１１）。

階層滞留率は、対象期間の中で、論理ページが最も高性能の階層２６１Ａに割り当てられていた期間の割合である。階層滞留率をｒ、対象期間数をｎ、論理ページが最も高性能の階層に滞留していた期間の数をｐとすると、ｒ＝ｐ／ｎとして求められる。

図３４は、管理サーバ３０の論理ページモニタリング方式選択モジュールＰ３５の処理を示す。

モニタリング方式選択モジュールＰ３５は、最初に、論理ページ毎の、次のモニタリング期間で使用されるモニタリング方式の候補を選択するための処理を実行する（Ｓ１２０）。ステップＳ１２０の詳細は、図３５で後述する。

続いて、モニタリング方式選択モジュールＰ３５は、各論理ページについて選択されたモニタリング方式の候補に基づいて、仮想ボリューム全体に適用するモニタリング方式を選択するための処理を実行する（Ｓ１２１）。ステップＳ１２１の詳細は、図３７で後述する。

図３５は、図３４中にステップＳ１２０で示す処理のフローチャートである。モニタリング方式選択モジュールＰ３５は、論理ページ負荷評価データ履歴表Ｔ３２から、最新のモニタリング期間の全ての評価データエントリを取得する（Ｓ１３０）。モニタリング方式選択モジュールＰ３５は、全ての評価データエントリについて、以下のステップＳ１３２〜Ｓ１４０を実行する（Ｓ１３１）。

モニタリング方式選択モジュールＰ３５は、仮想ボリューム選択モニタリング方式履歴表Ｔ３９から、仮想ボリューム識別子をキーとして、一つのエントリ（選択されたモニタリング方式のエントリ）を取得する（Ｓ１３２）。

モニタリング方式選択モジュールＰ３５は、モニタリング方式定義表Ｔ３３から、ステップＳ１３２で取得したエントリの次期モニタリング方式識別子Ｃ３９２に一致するエントリを取得する（Ｓ１３３）。

モニタリング方式選択モジュールＰ３５は、ステップＳ１３３で取得したエントリから、モニタリング方式識別子Ｃ３３０を取得する（Ｓ１３４）。モニタリング方式選択モジュールＰ３５は、論理ページ階層滞留率履歴表Ｔ３５から、対応する最新の階層滞留率エントリを一つ取得する（Ｓ１３５）。

続いて、モニタリング方式選択モジュールＰ３５は、モニタリング方式を切り替えるための基準値を取得する処理を実行する（Ｓ１３６）。ステップＳ１３６の詳細は、図３６で後述する。

モニタリング方式選択モジュールＰ３５は、ステップＳ１３５で取得した階層滞留率がステップＳ１３６で取得した切替基準値以上であるか判定する（Ｓ１３７）。階層滞留率が切替基準値以上であると判定した場合（Ｓ１３７：ＹＥＳ）、モニタリング方式選択モジュールＰ３５は、モニタリング方式定義表Ｔ３３から、基準値以上の場合のモニタリング方式識別子Ｃ３３４を取得する（Ｓ１３８）。

これに対し、階層滞留率が切替基準値未満であると判定した場合（Ｓ１３７：ＮＯ）、モニタリング方式選択モジュールＰ３５は、モニタリング方式定義表Ｔ３３から、基準値未満の場合のモニタリング方式識別子Ｃ３３３を取得する（Ｓ１３９）。

最後に、モニタリング方式選択モジュールＰ３５は、論理ページモニタリング方式履歴表Ｔ３８に、モニタリング方式履歴エントリの各属性と、次期のモニタリング方式の識別子とを、新たなエントリとして追加する（Ｓ１４０）。

図３６は、図３５中にステップＳ１３６で示す、モニタリング方式を切り替えるための基準値を取得する処理のフローチャートである。

モニタリング方式選択モジュールＰ３５は、階層滞留率基準値管理表Ｔ３７から、評価データエントリの仮想ボリューム識別子をキーとして、切替基準値を選択し（Ｓ１５０）、選択した切替基準値を図３５の処理に返す（Ｓ１５１）。

図３７は、図３４中にステップＳ１２１で示す、次期モニタリング方式処理のフローチャートである。本処理では、図３４のステップＳ１２０で選択された論理ページ毎のモニタリング方式の候補の中から、仮想ボリューム全体に適用されるモニタリング方式（次期モニタリング方式）を一つ決定する。

モニタリング方式選択モジュールＰ３５は、論理ページ負荷評価履歴表Ｔ３２から、最新のモニタリング期間の全ての評価データエントリを取得する（Ｓ１６０）。モニタリング方式選択モジュールＰ３５は、各評価データエントリから、仮想ボリューム識別子の一覧を取得する（Ｓ１６１）。

モニタリング方式選択モジュールＰ３５は、全ての仮想ボリューム識別子について、以下のステップＳ１６３〜Ｓ１６７を実行する（Ｓ１６２）。

モニタリング方式選択モジュールＰ３５は、全ての評価データエントリから、仮想ボリューム識別子をキーとして、論理ページ識別子の一覧を取得する（Ｓ１６３）。モニタリング方式選択モジュールＰ３５は、論理ページモニタリング方式履歴表Ｔ３８から、最新のエントリを取得する（Ｓ１６４）。

モニタリング方式選択モジュールＰ３５は、論理ページ毎に選択された次期のモニタリング方式の候補を、モニタリング方式毎に集計する（Ｓ１６５）。つまり、単一期間モードを選択する論理ページが何個あり、複数期間平均モードを選択する論理ページが何個有るかを、数える。

モニタリング方式選択モジュールＰ３５は、最もエントリ数の多いモニタリング方式を、次のモニタリング期間で使用するモニタリング方式として選択する（Ｓ１６６）。最後に、モニタリング方式選択モジュールＰ３５は、仮想ボリューム選択モニタリング方式履歴表Ｔ３９に、新たなエントリを追加する。そのエントリは、仮想ボリューム識別子Ｃ３９０と、評価対象モニタリング期間Ｃ３９１と、次期モニタリング方式識別子Ｃ３９２とを有する。

なお、ここでは、最もエントリ数の多いモニタリング方式候補を一つ選択する方法を説明したが、他の方法を用いてもよい。例えば、仮想ボリューム２７０を構成する各論理ページ２７１のうち、いずれか一つでも、現在のモニタリング方式とは異なるモニタリング方式が選択された場合は、その変更されたモニタリング方式を仮想ボリューム全体に適用してもよい。例えば、一部の論理ページへのＩ／Ｏ特性が先に変化し、後から、残りの論理ページへのＩ／Ｏ特性が徐々に変化する場合に、そのＩ／Ｏ特性の変化を先取りして、モニタリング方式を切り替えることができる。

さらに、特定の一つまたは複数の論理ページを、モニタリング方式が変更されたか否かを監視する監視対象の論理ページとしてもよい。監視対象の論理ページのモニタリング方式が変化した場合は、仮想ボリューム全体に適用するモニタリング方式を変更する。

図３８は、管理サーバ３０の論理ページ再配置指示モジュールＰ３６の処理を示すフローチャートである。

再配置指示モジュールＰ３６は、空の入力マップを作成する（Ｓ１７０）。入力マップは、ストレージ装置２０にページ再配置を指示するために使用される。

再配置指示モジュールＰ３６は、論理ページ負荷評価データ履歴表Ｔ３２から、最新のモニタリング期間における全ての評価データエントリを取得する（Ｓ１７１）。再配置指示モジュールＰ３６は、全ての評価データエントリについて、以下のステップＳ１７３〜Ｓ１７６を実行する（Ｓ１７２）。

再配置指示モジュールＰ３６は、仮想ボリューム選択モニタリング方式履歴表Ｔ３９から、最新の一つのエントリを取得する（Ｓ１７３）。再配置指示モジュールＰ３６は、そのエントリから、次期モニタリング方式識別子Ｃ３９２を取得する（Ｓ１７４）。

再配置指示モジュールＰ３６は、論理ページ負荷評価データ履歴表Ｔ３２の次期階層識別子Ｃ３２６から、ステップＳ１７４で取得された次期モニタリング方式に対応する階層識別子を取得する（Ｓ１７５）。

再配置指示モジュールＰ３６は、ステップＳ１７０で作成した入力マップに、論理ページ識別子と次期階層識別子との組合せを追加する（Ｓ１７６）。最後に、再配置指示モジュールＰ３６は、ストレージ装置２０内の再配置実行モジュールＰ２２に対し、入力マップと一緒に再配置要求を送信する（Ｓ１７７）。

このように構成される本実施例によれば、仮想ボリューム２７０の使用状況（Ｉ／Ｏ特性）に応じて、適切なモニタリング方式を選択することができる。従って、仮想ボリュームの使用状況に応じて、仮想ボリューム２７０を構成する各論理ページ２７１を最適な階層２６１に配置することができる。この結果、高性能の階層２６１Ａを有効に使用することができ、無駄なページ再配置を抑制でき、応答性能を比較的安定にできる。さらに、モニタリング方式を自動的に変更するため、ユーザの管理作業の手間を軽減でき、使い勝手を向上できる。

図３９〜図４５を参照して第２実施例を説明する。本実施例を含む以下の各実施例は、第１実施例の変形例に相当する。従って、第１実施例との相違点を中心に述べる。本実施例では、ページ再配置に関する設定状況をユーザが確認したり、設定値を手動で変更したりできるようにするためのユーザインターフェースＧ１０（図４１）を提供する。

図３９は、本実施例の管理サーバ３０Ａの構成を示す。本実施例の管理サーバ３０Ａは、第１実施例の管理サーバ３０に比べて、ストレージ管理プログラムＰ３０内に、新たなプログラムモジュールＰ３７、Ｐ３８が追加されている。それら新たなモジュールＰ３７、Ｐ３８の詳細は、図４３、図４４で後述する。それら新たなモジュールＰ３７、Ｐ３８は、ユーザからの指示に応じて、モニタリング方式及び階層滞留率の基準値を変更するためのコンピュータプログラムである。

図４０は、管理サーバ３０Ａが具備する各種モジュールＰ３１〜Ｐ３８と表Ｔ３０〜Ｔ３８の関係を示す。

図４１は、管理サーバ３０Ａが表示する設定画面Ｇ１０を示す。ユーザは、設定画面Ｇ１０を介して、モニタリング方式に関する各種の状況を確認したり、設定値を変更したりすることができる。

設定画面Ｇ１０は、例えば、グラフ表示部ＧＰ１００と、階層遷移表示部ＧＰ１０１と、モニタリング方式変更部ＧＰ１０２と、階層滞留率基準値変更部ＧＰ１０３と、モニタリング期間変更部ＧＰ１０４を備えることができる。

グラフ表示部ＧＰ１００は、Ｉ／Ｏ負荷（単位時間あたりのＩ／Ｏ数）の時間変化をグラフ表示する。グラフの左側の縦軸は、各階層２６１の許容Ｉ／Ｏ数を示す。グラフの右側の縦軸は、階層滞留率を示す。左側の縦軸に示す「７０％」は、階層滞留率の基準値である。

グラフの横軸は、時間経過を示す。一つの例として午前８時から午後４時までの、Ｉ／Ｏ負荷の時間変化が棒グラフで表示される。斜線で示された棒グラフは、Ｉ／Ｏ負荷の実測値を示す。白い棒グラフは、単一期間モードで算出されたＩ／Ｏ負荷を示す。黒い棒グラフは、複数期間平均モードで算出されたＩ／Ｏ負荷を示す。

棒グラフと共に、複数の折れ線グラフも表示される。実線で示す折れ線グラフは、単一期間モードに従う場合の階層滞留率の時間変化を示す。点線で示す折れ線は、複数期間平均モードに従う場合の階層滞留率の時間変化を示す。

グラフからわかるように、複数期間平均モードの場合は、複数の期間のＩ／Ｏ負荷の平均値を使用するため、Ｉ／Ｏ負荷の実測値が一時的に低下した場合でも、階層滞留率に与える影響を少なくできる。これに対し、単一期間モードでは、階層滞留率を、Ｉ／Ｏ負荷の実測値の変化に速やかに追従させることができる。

階層遷移表示部ＧＰ１０１は、仮想ボリューム２７０の各論理ページ２７１のデータが各階層２６１Ａ（ティア１１）、２６１Ｂ（ティア１２）、２６１Ｃ（ティア１３）のいずれかに配置されるかを、各モニタリング方式毎に算出して表示する。階層遷移表示部ＧＰ１０１では、仮想ボリューム単位での配置先階層を表示している。

仮想ボリューム内の各論理ページについてそれぞれの配置先階層を画面に表示することも可能である。しかし、その場合は、ユーザの視認性が低下し、ユーザの状況把握が不便になる。そこで、本実施例では、配置先階層についての情報を集約してユーザに提示する。これにより、ユーザは状況を適切かつ速やかに把握でき、使い勝手が向上する。

配置先階層の情報を集約する方法としては、種々考えることができる。一つの方法は、仮想ボリュームを構成する論理ページの中で多数決を取り、最も多い配置先階層を、その仮想ボリュームを代表する配置先階層として階層遷移表示部ＧＰ１０１に表示させる。他の一つの方法は、方式切替のきっかけとなった論理ページの配置先階層に代表させる。なお、論理ページの配置先階層を色分けし、ヒートマップのように表現する構成も考えられる。その場合、ユーザは、色の分布状況から、仮想ボリューム内の各論理ページがどこに配置されるのかを一見して確認することができる。

実際に選択されているモニタリング方式が何であるかを問わずに、単一期間モードを選択した場合の配置先階層（再配置先階層）と、複数期間平均モードを選択した場合の配置先階層（再配置先階層）との両方を、表示部ＧＰ１０１に表示する。

従って、ユーザは、選択されなかった方のモニタリング方式をもしも選択していた場合に、各論理ページがどの階層に配置されたかを容易に知ることができる。

モニタリング方式変更部ＧＰ１０２は、ユーザがモニタリング方式を手動で変更するためのものである。ユーザは、グラフ表示部ＧＰ１００及び階層遷移表示部ＧＰ１０１を確認することで、現在のモニタリング方式を他のモニタリング方式に手動で変更することができる。

階層滞留率基準値変更部ＧＰ１０３は、階層滞留率の基準値の補正モードを変更したり、ユーザが手動で変更するためのものである。階層滞留率の基準値は、自動的に補正することができる。例えば、各階層２６１の使用状態に応じて、階層滞留率を変更することができる。ユーザは、手動補正を選択すると、階層滞留率の基準値を手動で設定することができる。階層滞留率の基準値を変化させるに際して、ユーザは、グラフ表示部ＧＰ１００及び階層遷移表示部ＧＰ１０１の表示内容を参考にすることができる。

モニタリング方式の手動による変更に応じて、階層滞留率の基準値を自動的に補正することもできる。

モニタリング方式を切り替える基準となる階層滞留率基準値を適切に設定することは、一般的なユーザにとって困難な作業であると考えられる。そこで、本実施例では、モニタリング方式がユーザによって手動で変更された場合に、階層滞留率基準値が適切に設定されていないからであると判定する。

例えば、複数期間平均モードから単一期間モードへ手動で切り替えられた場合、階層滞留率の基準値がユーザの意図する値よりも低いと判定し、基準値を上方修正する。例えば、基準値に１０を加える。これとは逆に、単一期間モードから複数期間平均モードへ手動で切り替えられた場合、基準値がユーザの意図する値よりも高いと判定し、基準値を下方修正する。例えば、基準値から１０を減じる。

モニタリング期間変更部ＧＰ１０４は、図１８に示す階層滞留率計算モニタリング期間管理表Ｔ３６の、階層滞留率を計算するためのモニタリング期間数を、ユーザが手動で変更するためのものである。ユーザが、モニタリング期間変更部ＧＰ１０４に値を入力して設定ボタンを押すと、階層滞留率計算モニタリング期間管理表Ｔ３６の値は、ユーザの指定値で上書きされる。

なお、階層滞留率計算モニタリング期間管理表Ｔ３６の階層滞留率は、複数設定できるように構成してもよい。例えば、図１９に示す階層滞留率基準値管理表Ｔ３７Ａのように、仮想ボリューム単位で、または、アプリケーション単位で、またはその他の単位で、それぞれ階層滞留率を設定できるように構成してもよい。これにより、よりきめ細かい制御を実現できる。

図４２は、管理サーバ３０Ａが有する階層滞留率基準値管理表Ｔ３７Ａを示す。この基準値管理表Ｔ３７Ａは、図１９に示す基準値管理表Ｔ３７に比べて、補正方法Ｃ３７２を新たに備えている。補正方法Ｃ３７２は、階層滞留率の基準値を自動的に補正するか、または手動で補正するかを選択するための情報である。

図４３は、管理サーバ３０Ａの有する論理ページモニタリング方式選択モジュールＰ３７の処理を示すフローチャートである。

モニタリング方式変更モジュールＰ３７は、まず最初に、仮想ボリューム識別子と、新たに指定された新モニタリング方式識別子とを、入力値として受け取る（Ｓ２００）。モニタリング方式変更モジュールＰ３７は、仮想ボリューム選択モニタリング方式履歴表Ｔ３９から、仮想ボリューム識別子をキーとして、最新の一つのエントリ（次期モニタリング方式識別子Ｃ３９２）を取得する（Ｓ２０１）。

モニタリング方式変更モジュールＰ３７は、入力された新モニタリング方式の識別子と、次期モニタリング方式の識別子とが一致するかを判定する（Ｓ２０２）。両方の識別子が一致する場合（Ｓ２０２：ＹＥＳ）、本処理は終了する。

新モニタリング方式識別子と次期モニタリング方式識別子とが不一致の場合（Ｓ２０２：ＮＯ）、モニタリング方式変更モジュールＰ３７は、次期モニタリング方式識別子を旧モニタリング方式識別子とする（Ｓ２０３）。

モニタリング方式変更モジュールＰ３７は、ユーザにより選択された新モニタリング方式識別子により、仮想ボリューム選択モニタリング方式履歴表Ｔ３９からステップＳ２０１で取得したエントリを更新する（Ｓ２０４）。これにより、次のモニタリング期間では、ユーザにより選択されたモニタリング方式に従って、Ｉ／Ｏ負荷が評価される。

モニタリング方式変更モジュールＰ３７は、階層滞留率を自動補正するために、階層滞留率基準値変更モジュールＰ３８に要求を送信する（Ｓ２０５）。モニタリング方式変更モジュールＰ３７は、階層滞留率の基準値を変更する処理を実行する（Ｓ２０６）。

図４４は、管理サーバ３０Ａの有する階層滞留率基準値変更モジュールＰ３８の処理を示す。図４４は、図４３中のステップＳ２０６の詳細を示す。

基準値変更モジュールＰ３８は、仮想ボリューム識別子と、旧モニタリング方式識別子と、新モニタリング方式識別子と、補正方法と、新たな階層滞留率基準値とを、入力として受け取る（Ｓ２１０）。この時点では、新たな階層滞留率基準値の値は、ｎｕｌｌとなっている。

基準値変更モジュールＰ３８は、階層滞留率基準値管理表Ｔ３７Ａから、仮想ボリューム識別子をキーとして、一つの基準値エントリを取得する（Ｓ２１１）。基準値変更モジュールＰ３８は、ステップＳ２１０で入力された補正方法と、ステップＳ２１１で取得したエントリ中の補正方法Ｃ３７２の値が一致するか判定する（Ｓ２１２）。入力された補正方法と現在の補正方法（Ｃ３７２）とが一致する場合（Ｓ２１２：ＮＯ）、ステップＳ２１３をスキップしてステップＳ２１４に移る。

入力された補正方法と現在の補正方法とが不一致の場合（Ｓ２１２：ＹＥＳ）、基準値変更モジュールＰ３８は、エントリ中の補正方法Ｃ３７２を、ステップＳ２１０で入力された補正方法に変更し、階層滞留率基準値管理表Ｔ３７Ａを更新する（Ｓ２１３）。

最後に、基準値変更モジュールＰ３８は、階層滞留率の基準値を更新するための処理を実行する（Ｓ２１４）。

図４５は、階層滞留率の基準値を更新するための処理のフローチャートである。本処理は、図４４中のステップＳ２１４の詳細を示す。

基準値変更モジュールＰ３８は、仮想ボリューム識別子と、旧モニタリング方式識別子（現在のモニタリング方式識別子）と、ユーザの選択した新モニタリング方式識別子と、新たな階層滞留率基準値とを、入力として受け取る（Ｓ２２０）。さらに、基準値変更モジュールＰ３８は、階層滞留率基準値管理表Ｔ３７Ａから基準値エントリを取得する（Ｓ２２１）。

基準値変更モジュールＰ３８は、取得した基準値エントリ内の補正方法Ｃ３７２の値が「自動」であるか「補正」であるかを判定する（Ｓ２２２）。

補正方法に自動が設定されている場合（Ｓ２２２：自動）、基準値変更モジュールＰ３８は、旧モニタリング方式が単一期間モードであるか複数期間平均モードであるかを判定する（Ｓ２２３）。

旧モニタリング方式が複数期間平均モードに設定されている場合（Ｓ２２３：複数期間平均モード）、基準値変更モジュールＰ３８は、ユーザにより選択された新モニタリング方式が単一期間モードであるか判定する（Ｓ２２４）。

新モニタリング方式が単一期間モードの場合（Ｓ２２４：ＹＥＳ）、基準値変更モジュールＰ３８は、階層滞留率の基準値から１０を差し引いて、階層滞留率基準値管理表Ｔ３７Ａを更新する（Ｓ２２５）。ユーザの希望するモニタリング方式と現在のモニタリング方式とが異なるため、階層滞留率を切り替えるための基準値を、ユーザの意図する値に近づくよう補正する。

ステップＳ２２２において、基準値エントリの補正方法として「手動」が設定されている場合（Ｓ２２２：手動）、基準値変更モジュールＰ３８は、ステップＳ２２０で受け取った新基準値がｎｕｌｌであるか判定する（Ｓ２２６）。新基準値がｎｕｌｌの場合（Ｓ２２６：ＹＥＳ）、本処理を終了する。手動補正モードであるにもかかわらず、ユーザが数値を入力していないためである。

これに対し、新基準値がｎｕｌｌではない場合（Ｓ２２６：ＮＯ）、基準値変更モジュールＰ３８は、基準値エントリ内の基準値を新基準値で上書きし、階層滞留率基準値管理表Ｔ３７Ａを更新し（Ｓ２２７）、処理を終了する。

ステップＳ２２３において、旧モニタリング方式が単一期間モードに設定されていると判定された場合（Ｓ２２３：単一期間モード）、基準値変更モジュールＰ３８は、新モニタリング方式が複数期間平均モードであるか判定する（Ｓ２２８）。新モニタリング方式が複数期間平均モードではない場合（Ｓ２２８：ＮＯ）、旧モニタリング方式と新モニタリング方式とは共に単一期間モードであるため、処理を終了する。

新モニタリング方式が複数期間平均モードである場合（Ｓ２２８：ＹＥＳ）、基準値変更モジュールＰ３８は、基準値に１０を加えて、階層滞留率基準値管理表Ｔ３７Ａを更新する（Ｓ２２９）。

このように、複数期間平均モードから単一期間モードへ切り替えられた場合は、基準値がユーザの意図する値よりも低いと判断し、基準値を上方修正（＋１０）する。これに対し、単一期間モードから複数期間平均モードへ切り替えられた場合、基準値がユーザの意図する値よりも高いと判断し、基準値を下方修正（−１０）する。

このように構成される本実施例も第１実施例と同様の効果を奏する。さらに、本実施例では、再配置及びモニタリングに関する情報を画面Ｇ１０をユーザに提供する。さらに、本実施例では、ユーザは、設定画面Ｇ１０を用いて、モニタリング方式、階層滞留率基準値、モニタリング期間を変更できるようにしている。従って、ユーザの意図に応じた再配置を行うことができ、使い勝手が向上する。

また、本実施例では、ユーザがモニタリング方式を手動で変更した場合に、その変更に応じて、階層滞留率基準値を自動的補正するため、使い勝手がさらに向上する。

複数のモニタリング方式のうちいずれのモニタリング方式が適しているかは、ユーザは、グラフ表示部ＧＰ１００及び階層遷移表示部ＧＰ１０１の表示内容に基づいて、比較的容易に判断できる。しかし、Ｉ／Ｏ特性及びモニタリング方式に適した階層滞留率基準値を設定するのは、通常のユーザにとって難しい。そこで、本実施例では、ユーザによるモニタリング方式の変更を、階層滞留率基準値に反映させる。

図４６〜図５８を参照して第３実施例を説明する。本実施例では、アプリケーショングループと呼ぶ概念を導入する。アプリケーショングループとは、第２実施例の構成における、複数のアプリケーションＰ１０の集合である。或るアプリケーションは、或る１つのアプリケーショングループの要素となることができるものとする。

本実施例では、後述のように、ユーザは、アプリケーショングループの単位で、Ｉ／Ｏ負荷、配置先の階層、階層滞留率、モニタリング方式の時系列変化を確認したり、モニタリング方式及び階層滞留率基準値等を変更したりできる。

類似するＩ／Ｏ特性を持つ複数のアプリケーションは、同一のアプリケーショングループに所属し、一つのアプリケーショングループとして管理される。アプリケーショングループの導入により、ユーザは、仮想ボリューム単位よりも大きい単位で、ページ再配置の最適化を実現可能である。さらに、管理対象の粒度を大きくすることで、ユーザが管理しなければならない管理対象の個数を削減することができ、この結果、ユーザのストレージ管理作業のコストを低減できる。

なお、本実施例では、どのアプリケーションをどのアプリケーショングループに所属させるかは、ユーザが手動で設定する場合を説明する。これに代えて、どのような種類のアプリケーションをどのアプリケーショングループに所属させるかを定義する所定の基準を予め用意しておき、その基準に従って、アプリケーショングループを自動的に生成する構成でもよい。ユーザは、自動的に生成されたアプリケーショングループを、手動で修正することもできる。

図４６は、本実施例の管理サーバ３０Ｂの構成を示す。本実施例の管理サーバ３０Ｂは、第２実施例で述べた管理サーバ３０Ａに比べて、さらに、新たなプログラムモジュールＰ３９〜Ｐ４３と、新たな表Ｔ４０、Ｔ４１とが追加されている。

図４７は、本実施例の管理サーバ３０Ｂに新たに追加されたモジュールＰ３９〜Ｐ４３と表Ｔ４０、Ｔ４１との関係を示す説明図である。

図４８は、管理サーバ３０Ｂが表示する、アプリケーショングループ一覧画面Ｇ２０を示す。アプリケーショングループ一覧画面Ｇ２０は、例えば、アプリケーショングループ毎に、現在選択されているモニタリング方式の名称と、階層滞留率基準値（図中、モニタリング方式切替基準値）と、選択されている補正方法とを表示する。

アプリケーショングループ一覧画面Ｇ２０には、例えば、確認ボタンと、作成ボタンと、編集ボタンと、削除ボタンを設けることもできる。ユーザが確認ボタンを押すと、アプリケーショングループ一覧画面Ｇ２０は閉じる。

ユーザが作成ボタンを押すと、図４９で述べる作成画面Ｇ３０に移行して、新たなアプリケーショングループを作成できる。ユーザが既存のアプリケーショングループを選択してから編集ボタンを押すと、図５０で述べる編集画面Ｇ４０に移行して、そのアプリケーショングループの内容を編集できる。ユーザが既存のアプリケーショングループを選択してから削除ボタンを押すと、そのアプリケーショングループを削除できる。

図４９は、管理サーバ３０Ｂが表示するアプリケーショングループ作成画面Ｇ３０の例である。アプリケーショングループ作成画面Ｇ３０は、作成するアプリケーショングループを識別するためのアプリケーショングループ識別子を表示する。さらに、アプリケーショングループ作成画面Ｇ３０は、新規アプリケーショングループに所属させるアプリケーションをアプリケーション一覧の中からユーザが選択するためのアプリケーション選択部とを備える。

図５０は、管理サーバ３０Ｂが表示するアプリケーショングループ編集画面Ｇ４０の例を示す。ユーザは、アプリケーショングループ編集画面Ｇ４０を用いることで、編集対象のアプリケーショングループに登録されているアプリケーションを削除したり、新たなアプリケーションを追加したりできる。

図５１は、管理サーバ３０Ｂが表示するモニタリング方式設定画面Ｇ１０Ｂを示す。第２実施例で述べた設定画面Ｇ１０（図４１）との相違は、表示単位が、仮想ボリューム単位からアプリケーショングループ単位に変更された点である。

図５２は、管理サーバ３０Ｂが具備する、アプリケーショングループ単位で階層滞留率の基準値を管理するための表Ｔ４０である。

この階層滞留率基準値管理表Ｔ４０は、例えば、アプリケーショングループ識別子Ｃ４００と、現在のモニタリング方式を示す識別子Ｃ４０１と、モニタリング方式を切り替えるための基準値Ｃ４０２と、補正方法Ｃ４０３とを対応付けて管理する。図５２の表Ｔ４０と図４２の表Ｔ３７Ａとを比べると、仮想ボリューム識別子がアプリケーショングループ識別子に変更されており、さらに、現在のモニタリング方式の識別子が追加されている点で、相違する。

図５３は、管理サーバ３０Ｂが具備するアプリケーショングループ管理表Ｔ４１の例を示す。アプリケーショングループ管理表Ｔ４１は、例えば、アプリケーション識別子Ｃ４１０と、アプリケーショングループ識別子Ｃ４１１を対応付けて管理する。アプリケーショングループとしては、例えば、データベース関係のアプリケーションを集めた「データベース」、ウェブアプリケーションを集めた「ウェブ」、バッチ処理を集めた「バッチ」などがある。

図５４は、管理サーバ３０Ｂが有するアプリケーショングループ追加モジュールＰ３９の処理を示すフローチャートである。アプリケーショングループ追加モジュールＰ３９は、アプリケーショングループ作成画面Ｇ３０において、アプリケーショングループ識別子が入力され、かつ、最低１つのアプリケーションが選択された状態で、完了ボタンが押下されると実行される。

本処理へのその他の入力である、モニタリング方式識別子、階層滞留率基準値、補正方法については、予め設定された初期値が使用される。

アプリケーショングループ追加モジュールＰ３９は、アプリケーショングループ識別子と、モニタリング方式識別子と、階層滞留率の基準値と、補正方法とを入力として受け取る（Ｓ３００）。

アプリケーショングループ追加モジュールＰ３９は、アプリケーショングループ単位の階層滞留率基準値管理表Ｔ４０に、新エントリを追加する（Ｓ３０１）。その新エントリは、ステップＳ３００で受け取った情報を備える。

アプリケーショングループ追加モジュールＰ３９は、アプリケーショングループ管理表Ｔ４１に、アプリケーション識別子とアプリケーショングループ識別子とを対応付けたエントリを追加する（Ｓ３０２）。

図５５は、管理サーバ３０Ｂのアプリケーショングループ削除モジュールＰ４０の処理を示すフローチャートである。アプリケーショングループ一覧画面Ｇ２０において、アプリケーショングループが１つ選択された状態で、削除ボタンが押下されると、本処理が実行される。

アプリケーショングループ削除モジュールＰ４０は、削除対象として選択されたアプリケーショングループ識別子を、入力として受け取る（Ｓ３１０）。アプリケーショングループ削除モジュールＰ４０は、アプリケーショングループ単位の階層滞留率基準値管理表Ｔ４０から、指定されたアプリケーショングループ識別子を有する全てのエントリを削除する（Ｓ３１１）。最後に、アプリケーショングループ削除モジュールＰ４０は、アプリケーショングループ管理表Ｔ４１から、指定されたアプリケーショングループ識別子を有するエントリを全て削除する（Ｓ３１２）。

図５６は、管理サーバ３０Ｂが有するアプリケーショングループ編集モジュールＰ４１の処理を示すフローチャートである。アプリケーショングループ編集画面Ｇ４０において、最低１つのアプリケーションがチェックされた状態で、完了ボタンが押下されると、本処理が実行される。

編集モジュールＰ４１は、アプリケーショングループ識別子と、アプリケーション識別子のリストと、モニタリング方式識別子と、階層滞留率切り替え基準値と、補正方法とを、入力として受け取る（Ｓ３２０）。

編集モジュールＰ４１は、アプリケーショングループ管理表Ｔ４１から、複数のアプリケーションエントリを取得する（Ｓ３２１）。編集モジュールＰ４１は、削除対象のアプリケーション識別子のリストを作成する（Ｓ３２２）。削除対象のアプリケーション識別子とは、ステップＳ３２０で入力されたアプリケーション識別子のリストには含まれていないが、ステップＳ３２１で取得したアプリケーションエントリに含まれている、アプリケーション識別子である。

次に、編集モジュールＰ４１は、追加対象のアプリケーション識別子のリストを作成する（Ｓ３２３）。追加対象のアプリケーション識別子とは、ステップＳ３２０で入力されたアプリケーション識別子のリストに含まれているが、ステップＳ３２１で取得したアプリケーションエントリに含まれていない、アプリケーション識別子である。

編集モジュールＰ４１は、アプリケーショングループ管理表Ｔ４１から、削除対象アプリケーション識別子リストに含まれているアプリケーション識別子を持つエントリを全て削除する（Ｓ３２４）。

編集モジュールＰ４１は、追加対象アプリケーション識別子リストに基づいて、アプリケーショングループ管理表Ｔ４１に、エントリを追加する（Ｓ３２５）。

図５７のフローチャートは、管理サーバ３０Ｂの有する、アプリケーショングループ単位で論理ページのモニタリング方式を変更するモジュールＰ４２の処理を示す。モニタリング方式設定画面Ｇ１０Ｂにおいて、モニタリング方式変更の設定ボタンが押下された場合に、本処理が実行される。

モニタリング方式変更モジュールＰ４２は、アプリケーショングループ識別子と新モニタリング方式識別子を入力として受け取り（Ｓ３３０）、さらに、アプリケーショングループ管理表Ｔ４１から、複数のアプリケーションエントリを取得する（Ｓ３３１）。モニタリング方式変更モジュールＰ４２は、全てのアプリケーションエントリについて、以下のステップＳ３３３〜Ｓ３３５を実行する（Ｓ３３２）。

モニタリング方式変更モジュールＰ４２は、アプリケーション管理表Ｔ４１から、アプリケーションエントリのアプリケーション識別子をキーに、複数の仮想ボリュームエントリを取得する（Ｓ３３３）。モニタリング方式変更モジュールＰ４２は、全ての仮想ボリュームエントリについて、以下のステップＳ３３５を実行する（Ｓ３３４）。

モニタリング方式変更モジュールＰ４２は、仮想ボリューム識別子と新モニタリング方式識別子を入力として、論理ページモニタリング方式選択モジュールＰ３５を呼び出す（Ｓ３３５）。

モニタリング方式変更モジュールＰ４２は、アプリケーショングループ単位の階層滞留率基準値管理表Ｔ４０のモニタリング方式識別子Ｃ４０１を、新モニタリング方式識別子で上書きする（Ｓ３３６）。

図５８のフローチャートは、管理サーバ３０Ｂの有する、アプリケーショングループ単位で階層滞留率の基準値を変更するためのモジュールＰ４３の処理を示す。本処理は、モニタリング方式設定画面Ｇ１０Ｂにおいて、階層滞留率の基準値を変更するための設定ボタンが押下された場合に実行される。

基準値変更モジュールＰ４３は、アプリケーショングループ識別子と、旧モニタリング方式識別子と、新モニタリング方式識別子と、補正方法と、新階層滞留率基準値とを、入力として受け取る（Ｓ３４０）。

基準値変更モジュールＰ４３は、アプリケーショングループ管理表Ｔ４１から、複数のアプリケーションエントリを取得し（Ｓ３４１）、全てのアプリケーションエントリについて以下のステップＳ３４３〜Ｓ３４５を実行する（Ｓ３４２）。

基準値変更モジュールＰ４３は、アプリケーション管理表Ｔ４１から、複数の仮想ボリュームエントリを取得し（Ｓ３４３）、全ての仮想ボリュームエントリについて以下のステップＳ３４５を実行する（Ｓ３４４）。

基準値変更モジュールＰ４３は、仮想ボリュームエントリの仮想ボリューム識別子と、旧モニタリング方式識別子と、新モニタリング方式識別子と、補正方法と、新階層滞留率基準値とを入力として、上述した階層滞留率基準値変更モジュールＰ３８を呼び出す（Ｓ３４５）。

基準値変更モジュールＰ４３は、アプリケーショングループ単位の階層滞留率基準値管理表Ｔ４０を更新する（Ｓ３４６）。基準値変更モジュールＰ４３は、現在のモニタリング方式識別子Ｃ４０１と、モニタリング方式切替基準値Ｃ４０２と、補正方法Ｃ４０３とを、ステップＳ３４０で入力された新モニタリング方式識別子、補正方法、新階層滞留率基準値でそれぞれ上書きする。

このように構成される本実施例も第２実施例と同様の効果を奏する。さらに、本実施例では、アプリケーショングループ単位でモニタリング方式等を設定するため、より一層、ユーザの使い勝手を高めることができる。

なお、本発明は、上述の実施形態に限定されず、その要旨を逸脱しない範囲で種々変更可能である。
例えば、実施形態では、図４１，図５１に示すモニタリング期間変更部ＧＰ１０４は、図１８の階層滞留率計算モニタリング期間管理表Ｔ３６の値をユーザが手動で書き換えるためのものであるとして説明した。これに代えて、モニタリング期間変更部ＧＰ１０４を、図１５のモニタリング方式定義表Ｔ３３のモニタリング期間数Ｃ３３２の値を書き換えるためのものとして使用する構成でもよい。モニタリング方式毎のＩ／Ｏ評価値を算出するための期間をユーザが手動で変更することで、配置先階層の決定に直接的な影響を及ぼすことができる。

例えば、本発明は以下のようにコンピュータプログラムの発明として表現できる。
「ストレージ装置をコンピュータを用いて管理するためのコンピュータプログラムであって、
前記ストレージ装置は、ホストコンピュータに提供するための仮想的論理ボリュームと、それぞれ性能の異なる複数の記憶階層を有するプールとを備え、かつ、前記仮想的論理ボリュームを構成する複数の論理的記憶領域を、前記複数の記憶階層のうち指示された所定の記憶階層内の記憶領域に対応付けることで、前記所定の記憶階層に配置させるようになっており、
前記コンピュータに、
前記ストレージ装置から所定の情報を収集する情報収集ステップと、
前記所定の情報に基づいて、前記論理的記憶領域毎に前記アクセス負荷を評価するアクセス負荷評価ステップと、
前記各論理的記憶領域が配置先の記憶階層に配置されている時間に関する配置時間情報を算出する配置時間情報算出ステップと、
前記アクセス負荷および前記配置時間情報とに基づいて、前記各論理的記憶領域が前記各記憶階層のうちのいずれに配置されるべきかを示す再配置先を前記論理的記憶領域毎に決定する再配置指示ステップと、
をそれぞれ実行させるコンピュータプログラム。」

１０：ホストコンピュータ、２０：ストレージ装置、３０、３０Ａ、３０Ｂ：管理サーバ、Ｐ３０：ストレージ管理プログラム

Claims (15)

1. ストレージ装置を管理する管理装置であって、
   前記ストレージ装置は、ホストコンピュータに提供するための仮想的論理ボリュームと、それぞれ性能の異なる複数の記憶階層を有するプールとを備え、かつ、前記仮想的論理ボリュームを構成する複数の論理的記憶領域を、前記複数の記憶階層のうち指示された所定の記憶階層内の記憶領域に対応付けることで、前記所定の記憶階層に配置させるようになっており、
   前記ホストコンピュータによる前記各論理的記憶領域へのアクセス負荷と、配置先の記憶階層における前記各論理的記憶領域の配置状態とに基づいて、前記各論理的記憶領域の再配置先を決定する、
   ストレージ装置の管理装置。
   
2. 前記ストレージ装置から所定の情報を収集するための情報収集部と、
   前記所定の情報に基づいて、前記論理的記憶領域毎に前記アクセス負荷を評価するためのアクセス負荷評価部と、
   前記各論理的記憶領域が配置先の記憶階層に配置されている時間に関する配置時間情報を、前記配置状態として算出する配置時間情報算出部と、
   前記アクセス負荷および前記配置時間情報とに基づいて、前記各論理的記憶領域が前記各記憶階層のうちのいずれに配置されるべきかを前記論理的記憶領域毎に決定して、前記ストレージ装置に指示する再配置指示部と、
   を備える、
   請求項１に記載のストレージ装置の管理装置。
   
3. 予め用意されている複数のモニタリングモードのうちのいずれか一つを選択するためのモニタリングモード選択部を備え、
   前記アクセス負荷評価部は、前記複数のモニタリングモードのうち選択されたモニタリングモードに基づいて、前記各論理的記憶領域のアクセス負荷を評価する、
   請求項２に記載のストレージ装置の管理装置。
   
4. 前記モニタリングモード選択部は、前記配置時間情報に基づいて、前記複数のモニタリングモードのうち所定のモニタリングモードを選択する、
   請求項３に記載のストレージ装置の管理装置。
   
5. 前記配置時間情報算出部は、前記各論理的記憶領域が前記複数の記憶階層のうち最も高性能の記憶階層に配置されている時間と所定の配置基準期間との比率を、前記配置時間情報として算出し、
   前記モニタリングモード選択部は、前記配置時間情報の値と、前記複数のモニタリングモードの中から前記所定のモニタリングモードを選択するために予め設定されるモニタリングモード選択用基準値とを比較することで、前記複数のモニタリングモードの中から前記所定のモニタリングモードを選択する、
   請求項４に記載のストレージ装置の管理装置。
   
6. 前記モニタリングモード選択部は、前記論理的記憶領域毎に、前記複数のモニタリングモードの中からモニタリングモード候補をそれぞれ選択し、選択された前記各モニタリングモード候補のうち、最も多いモニタリングモードを前記所定のモニタリングモードとして選択する、
   請求項５に記載のストレージ装置の管理装置。
   
7. 前記モニタリングモード選択部は、前記論理的記憶領域毎に、前記複数のモニタリングモードの中からモニタリングモード候補をそれぞれ選択し、選択された前記各モニタリングモード候補のうち、いずれか一つでも、現在選択されているモニタリングモードとは異なる他のモニタリングモードが候補として選択された場合は、前記他のモニタリングモードを前記所定のモニタリングモードとして選択する、
   請求項５に記載のストレージ装置の管理装置。
   
8. 前記ストレージ装置は、前記仮想的論理ボリュームを複数備えており、
   前記モニタリングモード選択部は、前記仮想的論理ボリューム毎に、前記所定のモニタリングモードを選択する、
   請求項４に記載のストレージ装置の管理装置。
   
9. 前記ホストコンピュータは、前記仮想的論理ボリュームを使用するアプリケーションプログラムを備えており、
   前記モニタリングモード選択部は、アプリケーションプログラムの種類に応じて、前記複数のモニタリングモードの中から前記所定のモニタリングモードを選択する、
   請求項３に記載のストレージ装置の管理装置。
   
10. 前記モニタリングモード選択部は、手動選択モードと自動選択モードを備えており、
    前記自動選択モードが設定されている場合、前記モニタリングモード選択部は、前記配置時間情報に基づいて、前記複数のモニタリングモードのうち所定のモニタリングモードを選択し、
    前記手動選択モードが設定されている場合、前記モニタリングモード選択部は、前記複数のモニタリングモードのうち、ユーザにより選択されたモニタリングモードを前記所定のモニタリングモードとして選択する、
    請求項５に記載のストレージ装置の管理装置。
    
11. 前記手動選択モードが設定されている場合に、前記モニタリングモードの中から前記所定のモニタリングモードを選択するための手動選択部を含む設定画面を生成してユーザに提示し、
    前記設定画面には、前記複数のモニタリングモードのそれぞれにおける、前記アクセス負荷と前記配置時間情報と前記各論理的記憶領域の再配置先とが表示される、
    請求項１０に記載のストレージ装置の管理装置。
    
12. 前記所定の配置基準期間を変更するための第１変更部と、前記モニタリングモード選択用基準値を変更するための第２変更部とが、前記設定画面にさらに含まれている、
    請求項１１に記載のストレージ装置の管理装置。
    
13. 前記複数のモニタリングモードの中には、第１モニタリングモードと、第２モニタリングモードとが含まれており、
    前記第２モニタリングモードの第２モニタリング期間は、前記第１モニタリングモードの第１モニタリング期間よりも長くなるように予め設定されており、
    前記アクセス負荷評価部は、
    前記第１モニタリング期間または前記第２モニタリング期間のうち、選択された方のモニタリング期間内に前記ホストコンピュータから前記仮想的論理ボリュームに発行されたアクセス要求の数に基づいて、前記アクセス負荷を評価する、
    請求項１に記載のストレージ装置の管理装置。
    
14. ストレージ装置を管理用コンピュータで管理するための管理方法であって、
    前記ストレージ装置は、ホストコンピュータに提供するための仮想的論理ボリュームと、それぞれ性能の異なる複数の記憶階層を有するプールとを備え、かつ、前記仮想的論理ボリュームを構成する複数の論理的記憶領域を、前記複数の記憶階層のうち指示された所定の記憶階層内の記憶領域に対応付けることで、前記所定の記憶階層に配置させるようになっており、
    前記ストレージ装置から所定の情報を収集する情報収集ステップと、
    前記所定の情報に基づいて、前記論理的記憶領域毎に前記アクセス負荷を評価するアクセス負荷評価ステップと、
    前記各論理的記憶領域が配置先の記憶階層に配置されている時間に関する配置時間情報を算出する配置時間情報算出ステップと、
    前記アクセス負荷および前記配置時間情報とに基づいて、前記各論理的記憶領域が前記各記憶階層のうちのいずれに配置されるべきかを示す再配置先を前記論理的記憶領域毎に決定する再配置指示ステップと、
    をそれぞれ実行するストレージ装置の管理方法。
    
15. 予め用意されている複数のモニタリングモードのうちのいずれか一つを選択するためのモニタリングモード選択ステップを、前記配置時間情報算出ステップの前に設け、
    前記モニタリングモード選択ステップは、前記配置時間情報に基づいて、前記複数のモニタリングモードのうち所定のモニタリングモードを選択する、
    請求項１４に記載のストレージ装置の管理方法。

Images