"複数の記憶ドライブとコントローラを有する一つのストレージ装置と、ストレージ管理サーバと、から構成される計算機システムであって、前記コントローラは、前記複数の記憶ドライブにより提供される記憶領域を論理記憶領域とする複数のボリュームを管理し、前記ストレージ管理サーバは、A複数のボリュームのなかから再配置元となるボリュームの指定を受信し、B再配置先の条件を受信し、C前記再配置元ボリュームを除いた複数のボリュームから、前記再配置先の条件を満たす候補ボリュームを抽出し、D検索の結果、前記再配置先の条件を満たす候補ボリュームを抽出できた場合は、前記再配置元ボリュームを前記候補ボリュームに再配置する支持を前記一つ以上のストレージ装置に送信し、E検索の結果、前記再配置先の条件を満たす候補ボリュームを抽出できなかった場合は、E1前記再配置先の条件を満たす複数の記憶ドライブを、前記複数の記憶ドライブから抽出し、E2前記抽出した複数の記憶ドライブの空き記憶江領域を論理記憶領域とするボリュームを前記一つ以上のストレージ装置に作成させ、前記再配置元ボリュームを前記作成させたボリュームに再配置する指示を前記一つ以上のストレージ装置に送信する、ことを特徴とした計算機システム。請求項1記載の計算機システムであって、前記ストレージ管理サーバは、前記再配置の終了後に前記再配置元のボリュームを削除する、ことを特徴とした計算機システム。請求項2記載の計算機システムであって、前記再配置先の条件は、記憶ドライブの種別に関する条件を含む、ことを特徴とした計算機システム。請求項2記載の計算機システムであって、前記複数の記憶ドライブは複数のRAIDグループを構成し、前記記憶ドライブの記憶領域とは、前記RAIDグループの記憶領域であり、前記再配置先の条件は、前記RAIDグループのRAIDレベルに関する条件を含む、ことを特徴とした計算機システム。請求項1記載の計算機システムであって、前記ストレージ管理サーバは、前記候補ボリュームの識別子を前記再配置元ボリュームの再配置候補として表示させる、ことを特徴とした計算機システム。請求項5記載の計算機システムであって、前記ストレージ管理サーバは、前記ボリューム作成に失敗した場合はボリューム再配置を行なうことができないことを通知する、ことを特徴とした計算機システム。複数の記憶ドライブとコントローラを有する一つのストレージ装置と、ストレージ管理サーバと、から構成される計算機システムのストレージ管理サーバのプログラムであって、前記コントローラは、前記複数の記憶ドライブにより提供される記憶領域を論理記憶領域とする複数のボリュームを管理し、前記ストレージ管理サーバのプログラムは、A複数のボリュームのなかから再配置元となるボリュームの指定を受信し、B再配置先の条件を受信し、C前記再配置元ボリュームを除いた複数のボリュームから、前記再配置先の条件を満たす候補ボリュームを抽出し、D検索の結果、前記再配置先の条件を満たす候補ボリュームを抽出できた場合は、前記再配置元ボリュームを前記候補ボリュームに再配置する支持を前記一つ以上のストレージ装置に送信し、E検索の結果、前記再配置先の条件を満たす候補ボリュームを抽出できなかった場合は、E1前記再配置先の条件を満たす複数の記憶ドライブを、前記複数の記憶ドライブから抽出し、E2前記抽出した複数の記憶ドライブの空き記憶江領域を論理記憶領域とするボリュームを前記一つ以上のストレージ装置に作成させ、前記再配置元ボリュームを前記作成させたボリュームに再配置する指示を前記一つ以上のストレージ装置に送信する、ことを特徴としたストレージ管理サーバのプログラム。請求項7記載のストレージ管理サーバのプログラムであって、前記ストレージ管理サーバは、前記再配置の終了後に前記再配置元のボリュームを削除する、ことを特徴としたストレージ管理サーバのプログラム。請求項8記載のストレージ管理サーバのプログラムであって、前記再配置先の条件は、記憶ドライブの種別に関する条件を含む、ことを特徴としたストレージ管理サーバのプログラム。請求項8記載のストレージ管理サーバのプログラムであって、前記複数の記憶ドライブは複数のRAIDグループを構成し、前記記憶ドライブの記憶領域とは、前記RAIDグループの記憶領域であり、前記再配置先の条件は、前記RAIDグループのRAIDレベルに関する条件を含む、ことを特徴としたストレージ管理サーバのプログラム。請求項7記載のストレージ管理サーバのプログラムであって、前記ストレージ管理サーバは、前記候補ボリュームの識別子を前記再配置元ボリュームの再配置候補として表示させる、ことを特徴としたストレージ管理サーバのプログラム。請求項11記載のストレージ管理サーバのプログラムであって、前記ストレージ管理サーバは、前記ボリューム作成に失敗した場合はボリューム再配置を行なうことができないことを通知する、ことを特徴としたストレージ管理サーバのプログラム。複数の記憶ドライブとコントローラを有する一つのストレージ装置と、ストレージ管理サーバと、から構成される計算機システムのストレージ管理サーバであって、前記コントローラは、前記複数の記憶ドライブにより提供される記憶領域を論理記憶領域とする複数のボリュームを管理し、前記ストレージ管理サーバは、A複数のボリュームのなかから再配置元となるボリュームの指定を受信し、B再配置先の条件を受信し、C前記再配置元ボリュームを除いた複数のボリュームから、前記再配置先の条件を満たす候補ボリュームを抽出し、D検索の結果、前記再配置先の条件を満たす候補ボリュームを抽出できた場合は、前記再配置元ボリュームを前記候補ボリュームに再配置する支持を前記一つ以上のストレージ装置に送信し、E検索の結果、前記再配置先の条件を満たす候補ボリュームを抽出できなかった場合は、E1前記再配置先の条件を満たす複数の記憶ドライブを、前記複数の記憶ドライブから抽出し、E2前記抽出した複数の記憶ドライブの空き記憶江領域を論理記憶領域とするボリュームを前記一つ以上のストレージ装置に作成させ、前記再配置元ボリュームを前記作成させたボリュームに再配置する指示を前記一つ以上のストレージ装置に送信する、ことを特徴としたストレージ管理サーバ装置。請求項13記載のストレージ管理サーバ装置であって、前記ストレージ管理サーバは、前記再配置の終了後に前記再配置元のボリュームを削除する、ことを特徴としたストレージ管理サーバ装置。請求項14記載のストレージ管理サーバ装置であって、前記再配置先の条件は、記憶ドライブの種別に関する条件を含む、ことを特徴としたストレージ管理サーバ装置。請求項14記載のストレージ管理サーバ装置であって、前記複数の記憶ドライブは複数のRAIDグループを構成し、前記記憶ドライブの記憶領域とは、前記RAIDグループの記憶領域であり、前記再配置先の条件は、前記RAIDグループのRAIDレベルに関する条件を含む、ことを特徴としたストレージ管理サーバ装置。請求項13記載のストレージ管理サーバ装置であって、前記ストレージ管理サーバは、前記候補ボリュームの識別子を前記再配置元ボリュームの再配置候補として表示させる、ことを特徴としたストレージ管理サーバ装置。請求項17記載のストレージ管理サーバ装置であって、前記ストレージ管理サーバは、前記ボリューム作成に失敗した場合はボリューム再配置を行なうことができないことを通知する、ことを特徴としたストレージ管理サーバ装置。複数の記憶ドライブとコントローラを有する一つのストレージ装置と、ストレージ管理サーバと、から構成される計算機システムのデータ再配置制御方法であって、前記コントローラは、前記複数の記憶ドライブにより提供される記憶領域を論理記憶領域とする複数のボリュームを管理し、前記ストレージ管理サーバは、A複数のボリュームのなかから再配置元となるボリュームの指定を受信し、B再配置先の条件を受信し、C前記再配置元ボリュームを除いた複数のボリュームから、前記再配置先の条件を満たす候補ボリュームを抽出し、D検索の結果、前記再配置先の条件を満たす候補ボリュームを抽出できた場合は、前記再配置元ボリュームを前記候補ボリュームに再配置する支持を前記一つ以上のストレージ装置に送信し、E検索の結果、前記再配置先の条件を満たす候補ボリュームを抽出できなかった場合は、E1前記再配置先の条件を満たす複数の記憶ドライブを、前記複数の記憶ドライブから抽出し、E2前記抽出した複数の記憶ドライブの空き記憶江領域を論理記憶領域とするボリュームを前記一つ以上のストレージ装置に作成させ、前記再配置元ボリュームを前記作成させたボリュームに再配置する指示を前記一つ以上のストレージ装置に送信する、ことを特徴とした計算機システムのデータ再配置制御方法。請求項19記載の計算機システムのデータ再配置制御方法であって、前記ストレージ管理サーバは、前記再配置の終了後に前記再配置元のボリュームを削除する、ことを特徴とした計算機システムのデータ再配置制御方法。請求項20記載の計算機システムのデータ再配置制御方法であって、前記再配置先の条件は、記憶ドライブの種別に関する条件を含む、ことを特徴とした計算機システムのデータ再配置制御方法。請求項20記載の計算機システムのデータ再配置制御方法であって、前記複数の記憶ドライブは複数のRAIDグループを構成し、前記記憶ドライブの記憶領域とは、前記RAIDグループの記憶領域であり、前記再配置先の条件は、前記RAIDグループのRAIDレベルに関する条件を含む、ことを特徴とした計算機システムのデータ再配置制御方法。請求項19記載の計算機システムのデータ再配置制御方法であって、前記ストレージ管理サーバは、前記候補ボリュームの識別子を前記再配置元ボリュームの再配置候補として表示させる、ことを特徴とした計算機システムのデータ再配置制御方法。請求項23記載の計算機システムのデータ再配置制御方法であって、前記ストレージ管理サーバは、前記ボリューム作成に失敗した場合はボリューム再配置を行なうことができないことを通知する、ことを特徴とした計算機システムのデータ再配置制御方法。上記の各特許文献では、ディスクの性能情報や利用情報に基づいて、一方のボリュームに記憶されているデータを他のボリュームにコピーさせ、データを再配置する技術が開示されている。しかし、これらの文献に記載の技術では、各ボリューム単位に個別にデータを再配置する必要があり、ユーザが自由に定義した階層間でボリュームを移動させることができず、使い勝手が低い。また、前記各文献に記載の技術では、各ボリューム単位のデータ再配置を行うため、関連する一群のボリュームを一括して再配置させるのが難しい。さらに、前記各文献に記載の技術では、データの再配置のみに注目しており、再配置後の処理については何ら考慮されておらず、この点においても使い勝手が低い。そこで、本発明の一つの目的は、複数のストレージ装置に分散されたデータをより簡単に再配置することができるストレージシステム及びデータ再配置制御装置を提供することにある。本発明の一つの目的は、相互に関連する複数のボリュームにそれぞれ記憶されたデータを一括して再配置することにより、使い勝手を高めたストレージシステム及びデータ再配置制御装置を提供することにある。本発明の一つの目的は、データ再配置後に必要な処理を自動的に実行させることにより、使い勝手を高めたストレージシステム及びデータ再配置制御装置を提供することにある。本発明のさらなる目的は、後述する実施形態の記載から明らかになるであろう。上記課題を解決すべく、本発明のストレージシステムは、それぞれ少なくとも一つ以上のボリュームを有する複数のストレージ装置と、各ストレージ装置の有するボリュームを仮想的に一元管理する仮想化部と、各ボリュームの属性情報を管理するボリューム属性情報を記憶する記憶部と、予め設定された複数のポリシーとボリューム属性情報とに基づいてそれぞれ生成される複数のストレージ階層間で、指定された移動元ボリュームを指定されたストレージ階層に再配置させる再配置部と、を備える。ここで、ポリシーは、ユーザが任意に設定可能であり、同一のボリュームが異なるストレージ階層に所属することもあり得る。また、ストレージ階層は、各ストレージ装置単位で、あるいは複数のストレージ装置にまたがって設定可能である。例えば、各ポリシーをそれぞれ識別するためのポリシー識別情報と、該各ポリシー識別情報毎にそれぞれ対応付けられた階層構成条件とを含むストレージ階層管理情報を備え、各階層構成条件を満たすボリューム群によって、各ポリシーに応じたストレージ階層をそれぞれ生成することができる。そして、階層構成条件には、RAIDレベル、ドライブの種別、記憶容量、ストレージ装置の種別、使用状態のうち少なくともいずれか一つを含めることができる。即ち、例えば、高性能なディスクから構成される高性能階層、低コストなディスクから構成される低コスト階層等のように、ストレージ階層は、ユーザの定義するポリシーに従って生成される。各ストレージ階層に属する一つまたは複数のボリュームは、同一のストレージ装置内に存在する場合もあるし、それぞれ異なるストレージ装置内に存在する場合もある。各階層を定義づけるポリシーは、ユーザにより設定可能な階層構成条件によって決定される。例えば、高性能階層を定義する場合、ユーザは、高性能なディスクや高性能なストレージ装置を選択するための条件を階層構成条件として設定すればよい。また、例えば、低コスト階層を定義する場合、ユーザは、安価なディスクを選択するための条件を、階層構成条件として設定すればよい。これら各階層構成条件を満たすボリュームにより、そのストレージ階層が構成される。あるストレージ階層に属するボリュームのデータを再配置する場合は、移動元のボリュームと移動先のストレージ階層とをそれぞれ指定すればよい。これにより、指定された移動元ボリュームのデータは、指定された移動先ストレージ階層に属するボリュームに移される。再配置部は、複数のボリュームからなるグループ単位で、例えば、相互に関連した複数のボリュームからなるグループ単位で、指定された移動元ボリュームを再配置させることもできる。相互に関連した複数のボリュームとしては、例えば、同一のアプリケーションプログラムにより使用されるデータを記憶するボリューム群、同一のファイルシステムを構成するデータを記憶するボリューム群等を挙げることができる。なお、データ同士の関連性が乏しい場合であっても、グループ化することができる。再配置部は、指定された移動元ボリュームを移動先のストレージ階層に移動させた後で、この移動されたボリュームに対して、移動先のストレージ階層に予め対応付けられている所定の処理を実行することもできる。所定の処理としては、例えば、リードオンリー等のようなアクセス属性の設定や、ボリュームの二重化等を挙げることができる。再配置部は、指定された移動元ボリュームの記憶内容をコピー可能な移動先候補ボリュームを選択する移動先候補選択部と、この移動先候補選択部により選択された移動先候補ボリュームをユーザに提示する提示部とを備え、移動先候補選択部は、ボリューム属性情報を参照することにより、移動元ボリュームの有する各属性のうち予め設定された必須属性が一致するボリュームを移動先候補ボリュームとして選択することができる。ボリューム属性情報は、静的属性と動的属性とを含んで構成可能であり、静的属性に含まれる所定の属性を前記必須属性として設定可能である。必須属性には、少なくともボリュームの記憶容量を含めることができる。このように、再配置部は、移動元ボリュームの必須属性に一致するボリュームを、移動先候補ボリュームとして選択する。移動先候補選択部は、必須属性の一致する移動先候補ボリュームが複数存在する場合に、必須属性以外の他の属性の一致具合に基づいて、移動先候補ボリュームを一つだけ選択することができる。必須属性以外の属性としては、例えば、RAIDレベル、ディスク種別、ストレージ装置の機種等を挙げることができる。つまり、必須属性が一致するボリュームが複数抽出された場合は、これら各ボリュームのうち最も移動元ボリュームに近い構成を有するボリュームが移動先候補ボリュームとして選択される。そして、再配置部は、移動先候補選択部により選択された移動先候補ボリュームを変更するための変更部を更に備えることができる。この変更部は、必須属性は一致するが選択されなかった移動先候補ボリュームの中から、移動先候補ボリュームを選択させることができる。例えば、移動先候補ボリュームが特定のRAIDグループに集中したり、ランダムアクセスされるデータとシーケンシャルアクセスされるデータのように使用態様が異なるデータ群が同一のRAIDグループに存在しないように、変更部は、いったん選択された移動先候補ボリュームを変更させることができる。変更部は、ユーザからの指示に基づいて、移動先候補ボリュームの変更を行うことができる。本発明の他の観点に従うデータ再配置制御装置は、複数のストレージ装置に分散して配置される複数のボリュームのデータ再配置を制御する。そして、各ボリュームは、仮想化部によって仮想的に一元管理されており、記憶部と制御部とを備えている。A記憶部には、a1少なくとも各ボリュームの識別情報、RAIDレベル、ドライブの種別、記憶容量、使用状態を含むボリュームの属性情報と、a2ユーザにより定義可能な複数のポリシーをそれぞれ識別するためのポリシー識別情報と、これら各ポリシー識別情報毎にそれぞれ対応付けられた階層構成条件とを含むストレージ階層管理情報と、をそれぞれ記憶することができる。B制御部は、ストレージ階層管理情報とボリューム属性情報とに基づいてそれぞれ生成される複数のストレージ階層間で、指定された移動元ボリュームを指定されたストレージ階層に再配置させる再配置部を備えることができる。また、本発明に従う別のデータ再配置制御装置は、複数のストレージ装置がそれぞれ有するボリュームを一元管理し、前記各ボリュームに記憶されたデータの再配置を制御する装置であって、各ストレージ装置の有するボリュームを仮想的に一元管理する仮想化部と、各ボリュームの属性情報を管理するボリューム属性情報を記憶する記憶部と、予め設定された複数のポリシーとボリューム属性情報とに基づいてそれぞれ生成される複数のストレージ階層間で、指定された移動元ボリュームを指定されたストレージ階層に再配置させる再配置部と、を備える。本発明は、例えば、以下のようなデータ再配置方法として捉えることもできる。即ち、複数のストレージ装置に分散された複数のボリュームに記憶されているデータを同一または異なるストレージ装置内のボリュームに再配置する方法であって、各ストレージ装置の有するボリュームは仮想的に一元管理されており、各ボリュームの属性情報をボリューム属性情報として管理し、複数のポリシーをそれぞれ予め設定し、これら複数のポリシーとボリューム属性情報とに基づいて複数のストレージ階層を生成し、移動元ボリューム及び移動先ストレージ階層をそれぞれ設定し、各ストレージ階層間で、指定された移動元ボリュームを指定されたストレージ階層に再配置させる。本発明の手段、機能、ステップの少なくとも一部は、マイクロコンピュータにより読み込まれて実行されるコンピュータプログラムとして構成できる場合がある。このようなコンピュータプログラムは、例えば、ハードディスクや光ディスク等のような記憶媒体に固定して流通させることができる。または、インターネット等のような通信ネットワークを介して、コンピュータプログラムを供給することもできる。以下、図面に基づき、本発明の実施の形態を説明する。図1は、本実施形態の全体概念を模式的に示す説明図である。以下に述べるように、本実施形態のストレージシステムは、複数のストレージ装置A~Dを備えている。各ストレージ装置A~Dの有するボリュームは、仮想的に一元管理されており、ホスト図2参照は、複数のストレージ装置A~Dを全体として一つの仮想的なストレージ装置として認識する。各ストレージ装置A~Dは、それぞれボリュームA1~A4,B1~B4,C1~C4,D1~D4を備えている。これら各ボリュームは、例えば、ハードディスクドライブや半導体メモリドライブあるいは光ディスクドライブ等の物理的な記憶ドライブにより提供される物理的な記憶領域上に設定される論理的な記憶領域である。ここで、各ストレージ装置A~Dは、それぞれ同一種類のドライブを備えることもできるし、あるいは、それぞれ異なる種類のドライブを混在させることもできる。従って、同一のストレージ装置内に位置するボリュームであっても、性能や価格等のボリューム属性がそれぞれ異なる場合がある。ユーザは、ストレージシステムの有する各ボリュームを、複数のストレージ階層1~3として任意にグループ化することができる。例えば、ある一つのストレージ階層1は、高信頼性階層として定義可能である。高信頼性階層は、例えば、ファイバチャネルディスクFCディスク等の高信頼性ドライブをRAID1で構成してなるボリューム群により構成される。また、他の一つのストレージ階層2は、例えば、低コスト階層として定義可能である。低コスト層は、例えば、SATASerialATAttachmentディスク等の安価なドライブをRAID5で構成してなるボリューム群により構成される。さらに、別の一つのストレージ階層3は、例えば、アーカイブ階層として定義可能である。アーカイブ階層は、例えば、所定容量未満の安価なディスク上に設定されるボリューム群から構成することができる。図1に示すように、各ストレージ階層1~3は、各ストレージ装置A~Dを跨って仮想的に構成される。つまり、ユーザは、例えば、高信頼性階層、低コスト階層、高速応答性階層、アーカイブ階層等のように、ビジネス上の使用基準ポリシーに基づいて、ストレージシステムを構成する複数のボリュームを、所望のストレージ階層として自由に定義することができる。ポリシーは、ストレージシステムの構成とは独立して設定可能であるため、各ストレージ階層を構成する条件によっては、一部のボリュームが複数のストレージ階層に属する場合もあるし、あるいは、他の一部のボリュームがいずれのストレージ階層にも属さない場合も生じうる。各ストレージ階層1~3には、データ再配置対象となるボリューム群をそれぞれ設けることができる。一つの例として、ストレージ階層1に、二つのボリュームV1,V2からなるマイグレーショングループを示す。これら各ボリュームV1,V2は、例えば、同一のアプリケーションプログラムにより使用されるデータ群または同一のファイルシステムを構成するデータ群を記憶する等のように、互いに関連するボリュームである。データの価値は、例えば時間の経過と共に低下していく。価値の高いデータは、高信頼性階層に置かれ、アプリケーションプログラムにより頻繁に利用される。時間の経過と共に価値が低下したデータは、他のストレージ階層に移動させるのが好ましい。高信頼性階層の記憶資源には限りがあるからである。そこで、ユーザは、互いに関連する複数のボリュームV1,V2に記憶されているデータの再配置を検討し、例えば、ストレージ階層1からストレージ階層3ここでは、アーカイブ階層への移動を決定する。ユーザは、移動元ボリュームV1,V2の再配置を一括して指定し、ストレージ階層3への移動を指示する。これにより、移動先のストレージ階層3では、マイグレーショングループを構成する各ボリュームV1,V2のデータをそれぞれ記憶可能なボリュームを選択し、これら選択されたボリュームにデータをコピーする。コピー完了後に、移動元ボリュームV1,V2のデータは削除することができ、空きボリュームとして再利用される。ここで、各ストレージ階層1~3には、各ストレージ階層1~3のポリシーに応じて、それぞれ予め所定のアクションを対応づけることができる。ここで、アクションとは、そのストレージ階層内で実行される所定の情報処理、データ操作を意味する。例えば、高信頼性階層として定義されるストレージ階層1には、再配置されたデータの複製を生成する処理が予め対応づけられている。また、例えば、低コスト階層として定義されるストレージ階層2には、何のアクションも対応づけないようにすることもできる。さらに、例えば、アーカイブ階層として定義されるストレージ階層3には、再配置されたデータの複製を生成する処理と、リードオンリーのアクセス属性を設定する処理との複数の処理をアクションとして対応づけておくことができる。マイグレーショングループを構成する各ボリュームV1,V2のデータが、ストレージ階層3に属するボリュームにコピーされると、ストレージ階層3に対応づけられている所定のアクションが自動的に実行される。ストレージ階層3に再配置されたデータは、その複製が生成されると共に、リードオンリーに設定され、改変が禁止される。ここで、各ボリュームV1,V2のデータを再配置する場合、そのデータをコピー可能なボリュームが、移動先のストレージ階層内で選択される。各ボリュームは、それぞれ属性情報を有している。ボリューム属性情報としては、例えば、各ボリュームを識別するための識別情報、RAIDレベル、ディスク種別、記憶容量、使用中か否かを示す使用状態、所属するストレージ装置の機種等を挙げることができる。これらのボリューム属性の全てが、移動元ボリュームV1,V2と、移動先候補のボリュームとの間で一致している必要はなく、一部の必須的な属性のみが一致していれば足りる。必須属性としては、例えば、記憶容量を挙げることができる。即ち、移動元ボリュームの記憶容量と同一またはそれ以上の記憶容量を有するボリュームを、移動先ボリュームとして選択することができる。必須属性の一致するボリュームが必要数以上に検出された場合は、必須属性以外の他の属性の一致度を考慮し、より移動元ボリュームに近い属性を備えるボリュームを、移動先ボリュームとして選択することができる。一つの例として、ボリューム属性を必須属性とそれ以外の属性との二種類に大別したが、これに限らず、例えば、必須属性と、準必須属性と、その他の属性等のように、三種類以上の属性に分類し、各種類の属性に重みをつけて、ボリューム間の一致度を求める構成でもよい。一例として、ボリューム容量およびエミュレーションタイプを必須属性、それ以外の属性RAIDレベル、ディスク種別等をその他の属性非必須属性とすることができる。あるいは、エミュレーションタイプを必須属性、ボリューム容量を準必須属性、それ以外の属性を非必須属性とする構成でもよい。ボリューム容量を準必須属性とした場合、移動元ボリュームと移動先ボリュームの容量は必ずしも一致しなくともよいが、移動先ボリュームは移動元ボリュームと同一またはそれ以上の容量を持っていなければならない。また、ボリューム属性のうち使用状態はこれらの分類に含まれない例外的な属性であって、移動先ボリュームの使用状態は常に空きでなければならない。図2は、ストレージシステムの全体構成を概略的に示すブロック図である。このストレージシステムは、それぞれ後述するように、例えば、複数のホスト10A,10B特に区別しない場合はホスト10と、ボリューム仮想化装置20と、複数のストレージ装置30,40と、管理クライアント50と、ストレージ管理サーバ60とを含んで構成することができ、これらは、LANLocalAreaNetwork等の通信ネットワークCN1を介して相互に接続されている。各ホスト10A,10Bは、例えば、サーバ、パーソナルコンピュータ、ワークステーション、メインフレーム、携帯情報端末等のようなコンピュータシステムとして実現することができる。そして、例えば、複数のオープン系ホストと複数のメインフレーム系ホストとを、同一のストレージシステムに混在させることができる。各ホスト10A,10Bは、例えば、アプリケーションプログラム図中ではAppと略記11A,11B特に区別しない場合はアプリケーションプログラム11と、HBAHostBusAdapter12A,12B特に区別しない場合はHBA12とを備えることができる。これらアプリケーションプログラム11及びHBA12は、一つのホスト10について、それぞれ複数設けることができる。アプリケーションプログラム11A,11Bとしては、例えば、電子メール管理プログラム、データベース管理プログラム、ファイルシステム等を挙げることができる。アプリケーションプログラム11A,11Bは、図外の複数のクライアント端末と別の通信ネットワークを介して接続されることができ、各クライアント端末からの要求に応じて情報処理サービスを提供することができる。HBA12は、ストレージシステムとの間でデータの送受信を担当するもので、通信ネットワークCN2を介して、ボリューム仮想化装置20に接続されている。ここで、通信ネットワークCN2としては、例えば、LAN、SANStorageAreaNetwork、インターネット、専用回線等を挙げることができる。オープン系ホストの場合は、例えば、TCPIPTransmissionControlProtocolInternetProtocol、FCPFibreChannelProtocol、iSCSIinternetSmallComputerSystemInterface等のプロトコルに基づいて、データ転送が行われる。メインフレーム系ホストの場合は、例えば、FICONFibreConnection:登録商標、ESCONEnterpriseSystemConnection:登録商標、ACONARCAdvancedConnectionArchitecture:登録商標、FIBARCFibreConnectionArchitecture:登録商標等の通信プロトコルに従ってデータ転送が行われる。このほか、各ホスト10A,10Bには、それぞれパス制御プログラム等の管理プログラム不図示を搭載してもよい。このような管理プログラムは、例えば、複数のHBA12間で負荷を分散させたり、障害発生時にはパスを切り替える等の処理を行う。ボリューム仮想化装置以下仮想化装置とも呼ぶ20は、ストレージシステム内に存在するボリューム330,430等を仮想化し、一つの仮想的なストレージ装置に見せかけるものである。図3aに示すように、例えば、仮想化装置20は、各ホスト10に対して、識別情報LID001~LID004で示す複数の論理ボリュームLDEVを提供する。これらの各論理ボリュームは、識別情報PID01~PID04で示す別の論理ボリュームにそれぞれ対応づけられている。識別情報PIDを有する論理ボリュームが実際にデータを格納する実ボリュームであり、ホスト10が直接認識可能な論理ボリュームは、仮想ボリュームである。仮想ボリュームと実ボリュームとのマッピングを制御することにより、ホスト10に対して透過的に、データの移動を行うことができる。例えば、図3bに示すように、実ボリュームPID01に記憶されているデータを、別の実ボリュームPID02に移動させる場合は、これら実ボリューム間でデータをコピーした後、実ボリュームと仮想ボリュームとのマッピングを設定し直せばよい。あるいは、仮想ボリュームLID001と仮想ボリュームLID002との間で、識別情報を交換することにより、ホスト10に意識されることなく、データ格納先のデバイスを変更することもできる。このように、仮想化装置20は、ストレージシステム上に存在する多種多様な実ボリュームを仮想化して一元的に管理し、ホスト10に提供する。仮想化装置20は、後述のように、ストレージ装置内に設けることもできるし、あるいは、高機能なインテリジェント型スイッチに設けることもできる。さらに、後述のように、仮想化装置20とストレージ管理サーバ60とを同一のコンピュータ上に設けることもできる。図2に戻る。各ストレージ装置30,40は、それぞれ論理ボリューム実ボリューム330,430を備えており、SAN等の通信ネットワークCN3を介して、仮想化装置20にそれぞれ接続されている。各ストレージ装置30,40は、ホスト10からの要求に応じて、ボリュームへのデータ読み書きを行う。ストレージ装置の構成例は、さらに後述する。管理クライアント50は、例えば、パーソナルコンピュータやワークステーション、携帯情報端末等のコンピュータシステムとして構成されており、ウェブヴラウザ51を備えている。ユーザは、ウェブヴラウザ51を操作してストレージ管理サーバ60にログインすることにより、例えば、ストレージシステムに対して各種の指示を与えたり、ストレージシステム内の各種情報を取得することができる。ストレージ管理サーバ60は、ストレージシステムのボリューム再配置等を管理するコンピュータシステムである。ストレージ管理サーバ60の構成例は、さらに後述するが、例えば、データ再配置管理部632と、ボリュームデータベース図中DB640とを備えることができる。図4は、ストレージシステムのハードウェア構成を概略的に示すブロック図であり、仮想化装置20をストレージ装置として構成した場合を示す。以下、本実施例では、仮想化装置20を、第3ストレージ装置20とも呼ぶ。第3ストレージ装置20は、それぞれ後述するように、例えば、複数のチャネルアダプタ以下CHA210と、複数のディスクアダプタ以下DKA220と、キャッシュメモリ230と、共有メモリ240と、接続制御部250,260と、記憶部270と、SVP280とを備えて構成することができる。CHA210は、ホスト10や外部の第1ストレージ装置30及び第2ストレージ装置40との間のデータ授受を制御するもので、例えば、CPUやメモリ、入出力回路等を備えたマイクロコンピュータシステムとして構成可能である。各CHA210は、それぞれ複数の通信ポート211を備えることができ、各通信ポート211毎にそれぞれ個別にデータ授受を行うことができる。各CHA210は、それぞれ一種類の通信プロトコルに対応しており、ホスト10の種類に応じて用意される。但し、各CHA210がそれぞれ複数種類の通信プロトコルに対応する構成としてもよい。DKA220は、記憶部270との間のデータ授受を制御する。DKA220は、CHA210と同様に、例えば、CPUやメモリ等を備えたマイクロコンピュータシステムとして構成することができる。各DKA220は、例えば、ホスト10から指定された論理ブロックアドレスLBAを物理ディスクのアドレスに変換等することにより、各ディスクドライブ271にアクセスし、データの読出しまたはデータの書込みを行う。なお、CHA210の機能とDKA220の機能とを一つまたは複数のコントローラ内に集約する構成としてもよい。キャッシュメモリ230は、ホスト10から書き込まれたライトデータや、ホスト10に読み出されたリードデータを記憶するものである。キャッシュメモリ230は、例えば、揮発または不揮発のメモリから構成可能である。キャッシュメモリ230が揮発性メモリを含んで構成される場合、図示せぬバッテリ電源等によりメモリバックアップを行うことが好ましい。なお、図示は省略するが、キャッシュメモリ230は、リードキャッシュ領域とライトキャッシュ領域との2つの領域から構成することができ、ライトキャッシュ領域に格納されたデータは、多重記憶することができる。つまり、同一のデータがディスクドライブ271にも存在するリードデータは、仮に失われたとしても再びディスクドライブ271から読み出せば足りるので、多重化の必要はない。これに対し、ライトデータは、ストレージ装置20内においては、キャッシュメモリ230にのみ存在するため、多重化記憶させるのが信頼性の点で好ましい。もっとも、キャッシュデータを多重化して記憶させるか否かは、仕様による。共有メモリあるいは制御メモリとも呼ばれる240は、例えば、不揮発メモリから構成可能であるが、揮発メモリから構成してもよい。共有メモリ240には、例えば、マッピングテーブルT1のように、制御情報や管理情報等が記憶される。これらの制御情報等の情報は、複数のメモリ240により多重管理することができる。マッピングテーブルT1の構成例については、後述する。ここで、共有メモリ240及びキャッシュメモリ230は、それぞれ別々のメモリパッケージとして構成することもできるし、同一のメモリパッケージ内にキャッシュメモリ230及び共有メモリ240を設けてもよい。また、メモリの一部をキャッシュ領域として使用し、他の一部を制御領域として使用することもできる。つまり、共有メモリとキャッシュメモリとは、同一のメモリとして構成することもできる。第1の接続制御部スイッチ部250は、各CHA210と、各DKA220と、キャッシュメモリ230と、共有メモリ240とをそれぞれ相互に接続するものである。これにより、全てのCHA210,DKA220は、キャッシュメモリ230及び共有メモリ240にそれぞれ個別にアクセス可能である。接続制御部250は、例えば、超高速クロスバスイッチ等として構成することができる。第2の接続制御部260は、各DKA220と記憶部270とをそれぞれ接続するためのものである。記憶部270は、多数のディスクドライブ271を備えて構成される。記憶部270は、各CHA210及び各DKA220等のコントローラ部分と共に同一の筐体内に設けることもできるし、コントローラ部分とは別の筐体内に設けることもできる。記憶部270には、複数のディスクドライブ271を設けることができる。ディスクドライブ271としては、例えば、FCディスクファイバチャネルディスク、SCSISmallComputerSystemInterfaceディスク、SATASerialATAttachmentディスク等を用いることができる。また、記憶部270は、同一種類のディスクドライブから構成される必要はなく、複数種類のディスクドライブを混在させることもできる。ここで、一般的には、FCディスク、SCSIディスク、SATAディスクの順番で、性能が低下する。例えば、アクセス頻度の多いデータ価値の高いデータ等は、高性能なFCディスクに記憶し、アクセス頻度の低いデータ価値の低いデータ等は、低性能なSATAディスクに記憶させる等のように、データの利用態様に応じて、ディスクドライブの種類を使い分けることができる。各ディスクドライブ271の提供する物理的な記憶領域上には、複数の論理的な記憶領域を階層化して設けることができる。記憶領域の構成については、さらに後述する。SVPServiceProcessor280は、LAN等の内部ネットワークCN11を介して、各CHA210及び各DKA220とそれぞれ接続されている。図中では、SVP280とCHA210とだけを接続しているが、SVP280は、各DKA220にもそれぞれ接続することができる。SVP280は、ストレージ装置20内の各種状態を収集し、そのままで又は加工して、ストレージ管理サーバ60に提供する。ボリューム仮想化を実現する第3ストレージ装置20は、ホスト10からのデータ入出力要求を処理する窓口であり、第1ストレージ装置30及び第2ストレージ装置40と通信ネットワークCN3を介して、それぞれ接続されている。なお、図中では、ストレージ装置20に二つのストレージ装置30,40を接続する状態を示すが、これに限らず、ストレージ装置20に一つのストレージ装置を接続してもよく、あるいは、ストレージ装置20に三つ以上のストレージ装置を接続してもよい。第1ストレージ装置30は、例えば、コントローラ310と、第3ストレージ装置20と接続するための通信ポート311と、ディスクドライブ320とを備えて構成することができる。コントローラ310は、上述したCHA210及びDKA220の機能を実現するもので、第3ストレージ装置20及びディスクドライブ320とのデータ授受をそれぞれ制御する。第1ストレージ装置30は、第3ストレージ装置20と同一または実質的に同一の構成を備えてもよいし、第3ストレージ装置20と異なる構成でもよい。第1ストレージ装置30は、第3ストレージ装置20との間で所定の通信プロトコル例えば、FCやiSCSI等に従ったデータ通信を行うことができ、ディスクドライブ320等の記憶ドライブ記憶用デバイスを備えていればよい。後述のように、第1ストレージ装置30の有する論理ボリュームは、第3ストレージ装置20の所定階層にマッピングされており、第3ストレージ装置20の内部ボリュームであるかのように使用される。なお、本実施例では、物理的な記憶ドライブとして、ハードディスクを例示するが、本発明はこれに限定されない。記憶ドライブとしては、ハードディスク以外に、例えば、半導体メモリドライブ、磁気テープドライブ、光ディスクドライブ、光磁気ディスクドライブ等を用いることができる場合もある。第2ストレージ装置40は、第1ストレージ装置30と同様に、例えば、コントローラ410と、ディスクドライブ420と、ポート411とを備えて構成可能である。第2ストレージ装置40は、第1ストレージ装置30と同一の構成を備えてもよいし、異なる構成であってもよい。図5は、ストレージシステムの論理的な記憶構造に着目した構成説明図である。先に第3ストレージ装置20の構成から先に説明する。第3ストレージ装置20の記憶構造は、例えば、物理的記憶階層と論理的記憶階層とに大別することができる。物理的記憶階層は、物理的なディスクであるPDEVPhysicalDevice271により構成される。PDEVは、ディスクドライブに該当する。論理的記憶階層は、複数の例えば2種類の階層から構成することができる。一つの論理的階層は、VDEVVirtualDevice272から構成可能である。他の一つの論理的階層は、LDEVLogicalDevice273から構成することができる。VDEV272は、例えば、4個1組3D1P、8個1組7D1P等のような所定数のPDEV271をグループ化して構成することができる。グループに属する各PDEV271がそれぞれ提供する記憶領域が集合して一つのRAID記憶領域が形成される。このRAID記憶領域がVDEV272となる。ここで、全てのVDEV272がPDEV271上に直接設けられるわけではなく、一部のVDEV272は、仮想的な中間デバイスとして生成可能である。このような仮想的なVDEV272は、外部のストレージ装置30,40が有するLULogicalUnitをマッピングするための受け皿となる。LDEV273は、VDEV272上に、少なくとも一つ以上設けることができる。LDEV273は、VDEV272を固定長で分割することにより構成することができる。ホスト10がオープン系ホストの場合、LDEV273がLU274にマッピングされることにより、ホスト10は、LDEV273を一つの物理的なディスクボリュームとして認識する。オープン系のホスト10は、LUNLogicalUnitNumberや論理ブロックアドレスを指定することにより、所望のLDEV273にアクセスする。LU274は、SCSIの論理ユニットとして認識可能なデバイスである。各LU274は、ポート211Aを介してホスト10に接続される。各LU274には、少なくとも一つ以上のLDEV273をそれぞれ関連付けることができる。一つのLU274に複数のLDEV273を関連付けることにより、LUサイズを仮想的に拡張することもできる。CMDCommandDevice275は、ホスト10上で稼働するプログラムとストレージ装置のコントローラCHA210,DKA220との間で、コマンドやステータスを受け渡すために使用される専用のLUである。ホスト10からのコマンドは、CMD275に書き込まれる。ストレージ装置のコントローラは、CMD275に書き込まれたコマンドに応じた処理を実行し、その実行結果をステータスとしてCMD275に書き込む。ホスト10は、CMD275に書き込まれたステータスを読出して確認し、次に実行すべき処理内容をCMD275に書き込む。このようにして、ホスト10は、CMD275を介して、ストレージ装置に各種の指示を与えることができる。第3ストレージ装置20の外部接続用のイニシエータポートExternalPort211Bには、通信ネットワークCN3を介して、第1ストレージ装置30,第2ストレージ装置40がそれぞれ接続されている。第1ストレージ装置30は、複数のPDEV320と、PDEV320の提供する記憶領域上に設定されたLDEV330とを備えている。そして、各LDEV330は、LU340に関連付けられている。同様に、第2ストレージ装置40は、複数のPDEV420と、LDEV430とを備え、LDEV430はLU440に関連付けられている。第1ストレージ装置30の有するLDEV330は、LU340を介して、第3ストレージ装置20のVDEV272VDEV2にマッピングされている。第2ストレージ装置40の有するLDEV430は、LU440を介して、第3ストレージ装置のVDEV272VDEV3にマッピングされている。このように、第1,第2ストレージ装置30,40の有する実ボリュームLDEVを、第3ストレージ装置20の所定の論理階層にマッピングすることにより、第3ストレージ装置20は、外部に存在するボリューム330,430をあたかも自己の有するボリュームであるかのようにホスト10に対して見せかけることができる。なお、第3ストレージ装置20の外部に存在するボリュームを第3ストレージ装置30に取り込む方法としては、上記の例に限らない。次に、図6は、ストレージ管理サーバ60のハードウェア構成の概略を示すブロック図である。ストレージ管理サーバ60は、例えば、通信部610と、制御部620と、メモリ630と、ボリュームデータベース640とを備えて構成可能である。通信部610は、通信ネットワークCN1を介してデータ通信を行う。制御部620は、ストレージ管理サーバ60の全体制御を行う。メモリ630には、例えば、ウェブサーバプログラム631と、データ再配置管理プログラム632と、データベース管理システム633とが格納されている。ボリュームデータベース640には、例えば、ボリューム属性管理テーブルT2と、ストレージ階層管理テーブルT3と、対応ホスト管理テーブルT4と、マイグレーショングループ管理テーブルT5と、アクション管理テーブルT6とが記憶されている。これら各テーブルの構成例は、さらに後述する。ウェブサーバプログラム631は、制御部620に読み込まれて実行されることにより、ストレージ管理サーバ60上にウェブサーバ機能を実現させる。データ再配置管理プログラム632は、制御部620に読み込まれることにより、ストレージ管理サーバ60上にデータ再配置管理部を実現する。データベース管理システム633は、ボリュームデータベース640を管理する。なお、これらのウェブサーバ機能、データ再配置管理機能、データベース管理機能は、それぞれ並行して実行することができる。図7は、マッピングテーブルT1の構成を示す説明図である。マッピングテーブルT1は、第1ストレージ装置30,第2ストレージ装置40がそれぞれ有するボリュームを、第3ストレージ装置20にマッピングさせるために使用される。マッピングテーブルT1は、第3ストレージ装置20の共有メモリ240に記憶させることができる。マッピングテーブルT1は、例えば、LUNと、LDEV番号、LDEVの最大スロット数容量と、VDEV番号と、VDEVの最大スロット数容量と、デバイス種別と、パス情報とを対応づけることにより、構成することができる。パス情報は、第3ストレージ装置20内部の記憶領域PDEV271へのパスを示す内部パス情報と、第1ストレージ装置30または第2ストレージ装置40の有するボリュームへのパスを示す外部パス情報とに大別することができる。外部パス情報には、例えば、WWNWorldWideNameとLUNとを含めることができる。図8は、ボリューム属性管理テーブルT2の一例を示す。ボリューム属性管理テーブルT2は、ストレージシステムに分散する各ボリュームの属性情報を管理するためのものである。ボリューム属性管理テーブルT2は、例えば、各仮想ボリューム毎に、その仮想ボリュームを特定する論理IDと、その仮想ボリュームに対応づけられる実ボリュームの物理IDと、RAIDレベルと、エミュレーションタイプと、ディスク種別と、記憶容量と、使用状態と、ストレージ装置の機種とを対応づけることにより、構成することができる。ここで、RAIDレベルとは、例えば、RAID0,RAID1,RAID5等のRAID構成を示す情報である。エミュレーションタイプとは、そのボリュームの構造を示す情報であり、例えば、オープン系ホストに提供されるボリュームと、メインフレーム系ホストに提供されるボリュームとでは、エミュレーションタイプが相違する。使用状態とは、そのボリュームが使用されているか否かを示す情報である。機種とは、そのボリュームの存在するストレージ装置の機種を示す情報である。また、論理IDとは、前記ボリューム仮想化装置20がホスト10に対して提供する論理ボリュームのIDであり、物理IDとは、各論理ボリュームに対応する実ボリュームの所在を示すIDである。物理IDは、実ボリュームを格納しているストレージ装置の装置番号と、該装置内におけるボリューム番号から構成される。図9は、ストレージ階層管理テーブルT3の一例を示す。ストレージ階層管理テーブルT3は、例えば、ストレージ階層番号と、ストレージ階層名称と、そのストレージ階層を定義づける条件式と、自動的に実行させるアクションとを対応づけることにより、構成することができる。アクションは、必須の設定項目ではなく、アクションを対応づけずにストレージ階層を定義することもできる。ストレージ階層名称には、ユーザシステム管理者等が所望の名称を設定することができる。例えば、ストレージ階層名称として、高信頼階層、低コスト階層、高速応答階層、アーカイブ階層等の名称を用いることもできる。条件式には、そのストレージ階層に所属すべきボリュームを抽出するための検索条件が設定される。検索条件は、そのストレージ階層のポリシーに応じて、ユーザにより設定される。検索条件により、例えば、所定種類のディスクを所定のRAIDレベルで構成したボリュームを検出したりRAIDレベル=RAID1andディスク種別=FC、所定のストレージ装置に存在するボリュームを検出することができる機種=SS1。例えば、高信頼階層1では、高い信頼性を有するFCディスクによりRAID1で冗長化したボリュームが選択される。これにより、高信頼階層を、信頼性の高いボリュームのみから構成することができる。低コスト階層2では、安価なSATAディスクをRAID5で冗長化したボリュームが選択される。これにより、低コスト階層を、比較的小容量の安価なボリュームのみから構成可能である。高速応答階層3では、高速応答が可能な機種に存在するディスクをストライピングRAID0したボリュームが選択される。これにより、高速応答階層を、I/O処理が速く、パリティ演算等の処理を必要としないボリュームのみから構成できる。アーカイブ階層4では、安価なSATAディスクから構成され、かつ、所定容量未満の容量を有するボリュームが選択される。これにより、アーカイブ階層を、低コストのボリュームから構成することができる。図9に示すように、ストレージ階層管理テーブルT3に設定された条件式に基づいて、ボリューム属性管理テーブルT2を検索することにより、各ストレージ階層に所属すべきリューム群が検出される。ここで、ストレージ階層とボリューム群とは、明示的に直接関連付けられるのではなく、条件式を介して間接的に関連付けられている点に留意すべきである。これにより、ストレージシステムの物理構成が種々変化した場合でも、容易に対応することができる。図10は、対応ホスト管理テーブルT4の一例を示す説明図である。対応ホスト管理テーブルT4は、例えば、仮想ボリュームを識別する論理IDと、その仮想ボリュームにアクセスするホストを特定するための情報例えば、ドメイン名と、その仮想ボリュームを利用するアプリケーションプログラムの名称とを対応づけることにより、構成することができる。図11は、マイグレーショングループ管理テーブルT5の一例を示す説明図である。マイグレーショングループとは、データを再配置する場合の単位であり、本実施例では、相互に関連する複数のボリュームからマイグレーショングループを構成し、グループ単位で一括してデータを再配置できるようにしている。図10に示した対応ホスト管理テーブルT4を検索することにより、相互に関連するボリューム群を抽出することができる。マイグレーショングループ管理テーブルT5は、例えば、グループ番号と、グループ名称と、そのグループに属するボリュームを特定する論理IDと、そのグループが現在所属するストレージ階層の名称とを対応づけることができる。マイグレーショングループの名称は、ユーザが自由に設定することができる。このように、各マイグレーショングループは、例えば、同一のアプリケーションプログラムにより使用されるデータ群を記憶するボリューム、または、同一のファイルシステムを構成するデータ群を記憶するボリュームを、グループ化することによって構成可能である。なお、例えば、マイグレーショングループを新たに設定した直後等のように、データ再配置を行っていない状態では、そのグループの属するストレージ階層名称は設定されない場合がある。図12は、アクション管理テーブルT6の一例を示す説明図である。アクション管理テーブルT6は、ストレージ階層に予め設定されている所定の情報処理、データ操作の具体的内容を定義するものである。アクション管理テーブルT6は、例えば、アクションを識別するためのIDと、そのアクションの名称と、そのアクションで実行されるべきスクリプトプログラムとを対応づけることにより、構成することができる。従って、ストレージ階層管理テーブルT3にアクションIDが予め設定されている場合、そのアクションIDを検索キーとしてアクション管理テーブルT6を検索することにより、必要なアクションを実行することができる。例えば、高信頼階層では、アクションIDA1が設定されている。アクションIDA1は、ミラーリングを行うもので、ボリュームの複製を生成するスクリプトが関連付けられている。従って、あるマイグレーショングループが高信頼階層に再配置された場合、ボリューム群の複製が生成される。また、アーカイブ階層では、アクションIDA3が設定されている。アクションIDA3は、データのアーカイブ処理を行うもので、アーカイブ処理に必要な複数のスクリプトが関連付けられている。一つのスクリプトは、アクセス属性をリードオンリーに設定するものであり、他の一つのスクリプトは、ボリューム群の複製を行うものである。なお、アクション管理テーブルT6中のIDA2は、一度だけの書込みを許可するもので、いわゆるWORMWriteOnceReadMenyとして知られている。このアクションIDには、アクセス属性をリードオンリーに設定するスクリプトが関連付けられている。図13は、データ再配置の全体動作を簡略化して示す説明図である。データ再配置を行う場合、ユーザは、管理クライアント50を介してストレージ管理サーバ60にログインし、再配置させるマイグレーショングループ及び配置先のストレージ階層をそれぞれ指定するS1。ストレージ管理サーバ60は、指定されたマイグレーショングループを構成する各ボリュームのそれぞれについて、移動先候補のボリュームを選択するS2。詳細はさらに後述するが、移動先候補ボリュームを選択する処理では、移動先として指定されたストレージ階層に所属する全ボリュームのうち、移動元ボリュームのデータをコピー可能なボリュームが一つ選択される。ストレージ管理サーバ60による移動先候補ボリュームの選択結果は、例えば、ボリューム対応表T7のような形態で、ユーザに提示されるS3。ボリューム対応表T7は、例えば、移動元ボリュームの論理IDと、移動先ボリュームの論理IDとを対応づけることにより、構成することができる。ユーザは、ストレージ管理サーバ60から提示された再配置案ボリューム対応表T7を、ウェブヴラウザ51により確認する。ストレージ管理サーバ60からの提案をそのまま承認する場合は、所定のタイミングを見計らって再配置が実行されるS5。ストレージ管理サーバ60からの提案を修正する場合は、ウェブヴラウザ51を介して、移動先ボリュームの論理IDを変更するS4。図14は、移動先候補ボリュームを選択する処理を示すフローチャートである。この処理は、例えば、ユーザが、再配置対象のマイグレーショングループ及び再配置先移動先のストレージ階層を明示的に指定することにより、開始される。ストレージ管理サーバ60データ再配置管理プログラム632は、移動元ボリュームの全てについて、移動先候補ボリュームを選択済か否かを判定するS11。ここでは、NOと判定されて、S12に移る。そして、ストレージ管理サーバ60は、ボリューム属性管理テーブルT2を参照することにより、移動先として指定されたストレージ階層に所属するボリューム群から、使用状態が空きであり、かつ、移動元ボリュームと必須属性の一致するボリュームを抽出するS12。必須属性とは、ボリューム間のデータコピーを行うために必要な属性を意味し、一つでも必須属性が一致しない場合は、データコピーが不能である。本実施例では、必須属性として、例えば、記憶容量とエミュレーションタイプとを挙げることができる。即ち、本実施例では、移動元ボリュームと移動先ボリュームとは、最低限その記憶容量及びエミュレーションタイプが一致していなければならない。次に、ストレージ管理サーバ60は、必須属性が一致する空きボリュームとして検出されたボリュームの数を判定するS13。必須属性の一致する空きボリュームが一つだけ検出された場合は、そのボリュームを移動先候補ボリュームとして選択するS14。必須属性の一致する空きボリュームが全く発見されなかった場合、データ再配置を行うことはできないので、エラー処理を行い、ユーザに通知するS16。必須属性の一致する空きボリュームが複数検出された場合、ストレージ管理サーバ60は、必須属性以外の他の属性非必須属性の一致度が最も高いボリュームを、移動先候補ボリュームとして選択するS15。例えば、RAIDレベル、ディスク種別、ストレージ装置の機種等のような他の属性項目がより多く一致するボリュームを、移動先候補ボリュームとして選択する。なお、非必須属性の各項目間に優劣を付けて、一致度を算出するようにしてもよい。また、非必須属性の一致度が等しいボリュームが複数存在する場合は、例えば、論理IDの小さいボリュームを選択することができる。上記の処理は、移動対象のマイグレーショングループを構成する全てのボリュームについて、それぞれ実行される。そして、全ての移動元ボリュームについて、それぞれに対応する移動先候補ボリュームが選択された場合S11:YES、ストレージ管理サーバ60は、ボリューム対応表T7を生成してユーザに提示するS17。ユーザは、ストレージ管理サーバ60から提示されたボリューム対応表T7を確認し、承認するか修正するかを決定する。ユーザの承認が得られた場合S18:YES、本処理は終了する。ユーザが変更を希望する場合S18:NO、ユーザは、ウェブヴラウザ51を介して、移動先候補ボリュームを手動で再設定するS19。そして、ユーザにより修正が完了すると、本処理は終了する。図15は、再配置実行処理の概要を示すフローチャートである。ストレージ管理サーバ60データ再配置管理プログラム632は、ストレージ階層管理テーブルT3を参照することにより、移動先として指定されたストレージ階層に対応づけられているアクションを検出するS21。次に、ストレージ管理サーバ60は、全ての移動元ボリュームについて再配置が完了したか否かを判定するS22。最初の処理ではNOと判定されて次のステップS23に移る。そして、移動元ボリュームに記憶されているデータを、その移動元ボリュームに対応する移動先ボリュームにコピーしS23、移動元ボリュームから移動先ボリュームにアクセスパスを切り換えるS24。このパスの切り替えは、図3bで示したパスの切り替え同様の処理を行うものである。これにより、ホスト10は、データ再配置を意識することなく、そのままの設定で所望のデータにアクセスすることができる。ストレージ管理サーバ60は、移動元ボリュームから移動先ボリュームへのデータ移行が正常に完了したか否かを判定しS25、データ移行が正常に完了しなかった場合S25:NO、エラー処理を行って本処理を終了する。データ移行が正常に終了した場合S25:YES、移動先のストレージ階層に対応づけられているアクションが存在するか否かをチェックするS27。移動先のストレージ階層にアクションが設定されている場合S27:YES、ストレージ管理サーバ60は、アクション管理テーブルT6を参照し、所定のスクリプトを実行しS28、S22に戻る。移動先のストレージ階層にアクションが設定されていない場合S27:NO、何もせずにS22に戻る。このように、移動対象のマイグレーショングループに属する全てのボリュームについて、それぞれの記憶するデータが移動先ボリュームにコピーされ、アクセスパスが切り換えられる。そして、全ての移動元ボリュームについてデータ移行が完了するとS22:YES、本処理は終了する。図16は、ボリューム対応表T7の具体例を示す説明図である。ストレージ管理サーバ60による移動先候補ボリュームの選定結果は、例えば、図16に示すように、移動元ボリューム及び移動先ボリュームを上下2段に配置することにより、表示可能である。移動元ボリューム及び移動先ボリュームのそれぞれについて、例えば、その論理ID、その所属するRAIDグループ番号、RAIDレベル、エミュレーションタイプ、記憶容量等の属性を併せて表示することができる。ユーザは、図16の画面を確認することにより、データ再配置を実行させるか否かを判断することができる。移動先ボリュームを個別に変更する場合、ユーザは、モディファイボタンB1を操作する。このボタンB1を操作すると、図17に示す個別修正画面に遷移する。図17に示す修正画面では、その上部に、移動元ボリュームソースボリュームの論理IDと、移動元ボリュームのエミュレーションタイプ及び記憶容量とを表示させることができる。画面の中央部には、現在選択されている移動先ボリュームの論理IDやRAIDグループ、RAIDレベル、物理ID、所属するストレージ装置の番号、実ボリュームの物理ID等を表示させることができる。画面の下部には、指定された階層の中で移動元ボリュームと必須属性が一致する全ての候補ボリュームの一覧を表示させることができる。ユーザは、画面下部のボリューム一覧に表示されているボリュームの中からいずれか一つのボリュームを選択することができる。例えば、ストレージ管理サーバ60による初期選択結果が、特定のRAIDグループに属するボリュームに集中していたり、あるいは、シーケンシャルアクセスされるデータとランダムアクセスされるデータとが同一のRAIDグループに配置されていたりするような場合、そのRAIDグループの応答性が低下する。従って、ユーザは、特定のRAIDグループにデータが集中しないように、移動先候補ボリュームを個別に修正することができる。本実施例は、上述のように構成されるため、以下の効果を奏する。本実施例では、予め設定された複数のポリシーとボリューム属性情報とに基づいてそれぞれ生成される複数のストレージ階層間で、指定された移動元ボリュームを指定されたストレージ階層に再配置させる構成を採用した。従って、ユーザは、希望のポリシーで自由にストレージ階層を定義し、ストレージ階層間でボリュームを再配置させることができ、ストレージシステムの使い勝手が向上する。特に、複数のストレージ装置が混在する複雑なストレージシステムにおいて、ユーザは、各ボリュームの特性等を詳しく考慮することなく、自己の設定したポリシーに従い、直感的な操作でデータを再配置することができる。本実施例では、複数のボリュームからなるグループ単位で、データを再配置することができる。従って、上記のストレージ階層間でデータ再配置が可能な構成と相俟って、より一層ユーザの使い勝手を向上させることができる。本実施例では、移動先のストレージ階層に予め所定のアクションを対応づけることができ、データ再配置の完了後に所定のアクションを実行させることができる。これにより、データ再配置に伴う付加的なサービスを自動的に実行することができ、ユーザの操作忘れ等を防止して、使い勝手を改善することができる。本実施例では、必須属性の一致を前提条件とし、必須属性以外の属性の一致度が高いボリュームを移動先候補ボリュームとして選択する。従って、データ再配置に適切なボリュームを選択することができる。図18に基づいて本発明の第2実施例を説明する。本実施例を含む以下の実施例は、第1実施例の変形例に相当する。本実施例の特徴は、第1実施例で述べたボリューム仮想化装置20とストレージ管理サーバ60とを、一つのボリューム仮想化装置70に集約した点にある。本実施例のボリューム仮想化装置70は、例えば、ボリューム仮想化部71と、データ再配置部72と、ボリュームデータベース73とを備える。ボリューム仮想化部71は、第1実施例のボリューム仮想化装置20と同様の機能を実現する。データ再配置部72は、第1実施例におけるストレージ管理サーバ60のデータ再配置管理プログラム632と同様の機能を実現する。ボリュームデータベース73は、第1実施例のボリュームデータベース640と同様の各種テーブルを記憶する。図19に基づいて、本発明の第3実施例を説明する。本実施例の特徴は、ボリューム属性管理テーブルT2に、動的な属性を追加し、動的な属性を考慮してストレージ階層を定義可能とした点にある。本実施例のボリューム属性管理テーブルT2には、その右端に示すように、データ入出力の応答時間IO応答時間も管理されている。このIO応答時間は、例えば、定期的または不定期に、ストレージ管理サーバ60が各ストレージ装置20,30,40から収集して更新することができる。なお、図19中では、紙面の都合上、ストレージ装置の機種に代えてIO応答時間を表示しているが、ストレージ装置の機種もボリューム属性の一つとして管理することができる。ここで、IO応答時間は、テストIOを発行し、このIOの発行から応答までの時間を計測したものである。またこのIO応答時間は、図9に示す条件式に含めることができる。このように、本実施例では、RAIDレベルや記憶容量等の静的な属性に加えて、動的な属性も併せて管理するため、静的な属性と動的な属性の両方を考慮して、ストレージ階層を定義することができる。例えば、より高速な応答を求めるストレージ階層では、高速なディスクFCディスク上に設定され、最新のIO応答時間が最も短いストレージ装置に存在するボリュームから構成することができる。図20,図21に基づいて、本発明の第4実施例を説明する。本実施例の特徴は、ストレージシステムの構成変更ストレージ装置の廃棄に応じて、その構成変更に係るストレージ装置に記憶されているデータを、空いている適切なボリュームに自動的に再配置させる点にある。図20は、本実施例に係るストレージシステムの全体概要を示す説明図である。このストレージシステムでは、第1実施例の構成に加えて、第4ストレージ装置80が新たに追加されている。第4ストレージ装置80は、例えば、ストレージ装置30,40のように構成することができる。なお、第4ストレージ装置80は、説明の便宜上追加されるもので、本発明の構成に必須の要素ではない。本発明は、複数のストレージ装置を備えていれば足りる。本実施例では、一例として、第1ストレージ装置30を廃棄する場合を説明する。例えば、第1ストレージ装置30の耐用期限が切れたような場合に、第1ストレージ装置30は、廃棄が予定される。廃棄予定のストレージ装置30に記憶されているデータ群を、他のストレージ装置40,80あるいは、第3ストレージ装置としてのボリューム仮想化装置20。以下同様に移行させる場合を、図21の説明図に基づいて説明する。図21に示すように、ユーザは、まず条件式を与え、ボリューム属性管理テーブルT2を検索させることにより、廃棄対象のストレージ装置30上にある使用中状態のボリューム群を検出させ、これらのボリュームからなるマイグレーショングループをユーザが定義する。図21において、廃棄対象のストレージ装置30には、装置番号1が設定されているものとする。図中では、廃棄対象のストレージ装置30に存在する使用中状態のボリュームに、退避データボリュームというマイグレーショングループ名称を与えている。次に、装置番号が廃棄対象ストレージ装置の装置番号と異なる装置番号≠1という条件によってストレージ階層を定義する。図中では、廃棄対象のストレージ装置30以外の他のストレージ装置40,80により構成されるストレージ階層に、移行先階層というストレージ階層名称を与えている。そして、ユーザは、移行先階層のストレージ階層を移動先として、前記マイグレーショングループ退避データボリュームの再配置を指示する。以下、第1実施例で述べたと同様に、データ再配置管理プログラム632は、移動元として指定されたマイグレーショングループ退避データボリューム中に含まれる個々のボリュームについて、移動先として指定されたストレージ階層移行先階層から適切なボリュームをそれぞれ選択し、ユーザに提示する。上述のように、ボリューム属性の使用状態が空きで、かつ、必須属性が一致するボリューム、または、使用状態が空きで、かつ、必須属性が一致し、さらに非必須属性の一致度も高いボリュームが、適切な移行先候補ボリュームとして選択され、ユーザに提示される。そして、ユーザが、データ再配置管理プログラム632によって提案されたボリュームの対応付けを承認すれば、再配置処理が実行され、廃棄対象ストレージ装置30上にある全てのデータは、他のストレージ装置40,80中の適切なボリュームに再配置される。また、ストレージ装置の入換えを行う場合や、性能バランスを配慮して既存データの一部を新規に導入したストレージ装置に移行する場合には、装置番号=新規に導入したストレージ装置の装置番号という条件でストレージ階層新規追加階層を定義し、このストレージ階層を移動先に指定してデータ再配置を行えばよい。このように、本実施例からも明らかなように、本発明では、ストレージシステムの構成やポリシーに応じて、ユーザがストレージ階層を自在に定義することができ、関連するボリュームをマイグレーショングループとして一括指定し、グループ単位でデータ再配置を行うことができる。なお、本発明は、上述した実施の形態に限定されない。当業者であれば、本発明の範囲内で、種々の追加や変更等を行うことができる。例えば、マイグレーショングループは、必ずしも相互に関連するボリュームから構成する必要はなく、任意のボリュームを移動対象としてグループ化することもできる。また、第1ストレージ装置の階層、第2ストレージ装置の階層、第1ストレージ装置及び第2ストレージ装置の階層等のように、ストレージ装置を単位としてストレージ階層を設定することもできる。図22、図23、図24に基いて、本発明の第5実施例を説明する。本実施例の特徴は、配置先として指定されたストレージ階層中に、あるボリュームの移動先として適切な空きボリュームがない場合に、移動先となる条件を満たしたボリュームを自動的に作成し、作成したボリュームを移動先候補としてボリュームの再配置を行う点にある。図22は、本実施例における、移動先候補ボリュームを選択する処理を示すフローチャートである。図22中の多くのステップは、第1実施例の図14で示した移動先候補選択処理におけるステップと共通である。しかし、ストレージ管理サーバ60が、必須属性が一致する空きボリュームとして検出されたボリュームの数を判定するステップS13を実行した結果、そのような空きボリュームが全く発見されなかった場合の処理が異なる。この場合、本実施例では、ボリューム作成処理S31を行い、再配置先のストレージ階層に属しており、かつ移動元ボリュームと必須属性が一致するボリュームの作成を試みる。次に、ストレージ管理サーバ60は、必須属性が一致するボリュームの作成が成功したかどうかを判定しS32、成功した場合、作成したボリュームを移動先候補ボリュームとして選択するS33。また、作成したボリュームをボリューム属性管理テーブルT2に登録するS34。作成できなかった場合、データ再配置を行うことはできないので、エラー処理を行い、ユーザに通知するS16。図23は、図22におけるボリューム作成処理S31の詳細を示すフローチャートである。図23に示すボリューム作成処理では、ストレージ管理サーバ60は、まずボリューム仮想化装置20およびボリューム仮想化装置20に接続されたストレージ装置群の中から、1台のストレージ装置を選択するS41。次に、選択したストレージ装置が、作成すべきボリュームに関するストレージ装置要件を満たすかどうかを判定するS42。ここで、ストレージ装置要件とは、配置先として指定されたストレージ階層を定義する諸条件のうち、ストレージ装置の機種名、装置番号等、ストレージ装置の持つ属性に関わる条件もしあればを指す。選択したストレージ装置がストレージ装置要件を満たす場合、ストレージ管理サーバ60は、選択したストレージ装置内にあるすべてのVDEVのうち、VDEV要件を満たすものの集合Sを求めるS43。次に、集合Sの中から1個のVDEVを選択するS44。ここで、VDEV要件とは、配置先として指定されたストレージ階層を定義する諸条件のうち、ディスク種別、RAIDレベル等、VDEVの持つ属性に関わる条件もしあれば、および、移動元ボリュームのエミュレーションタイプを指す。次に、ストレージ管理サーバ60は、選択したVDEV内にある未割当ての空き容量が、移動元ボリュームの容量Q1と同等以上の大きさであるかどうかを判定するS45。空き容量が移動元ボリュームの容量と同等以上である場合、そのVDEV内部に移動元ボリュームと同一の容量を持つボリュームLDEVを新たに作成しS46、呼び出し元に対してボリューム作成の成功を報告する。ステップS45において、選択したVDEV内部に移動元ボリュームの容量と同等以上の空き容量がないと判定された場合、そのVDEV内部に移動先候補となるボリュームを作成することはできないので、ストレージ管理サーバ60は、集合S内に未調査の他のVDEVがないかどうかを判定するS47。他にもVDEVがある場合、次のVDEVを選択しS48、ステップS44に戻る。集合S内にもはや未調査のVDEVがない場合、および、ステップS42において、選択したストレージ装置はストレージ装置要件を満たさないと判定された場合には、そのストレージ装置内部に移動先候補となるボリュームを作成することはできないので、ストレージ管理サーバ60は、他に未調査のストレージ装置がないかどうかを判定するS49。他にもストレージ装置がある場合、次のストレージ装置を選択しS50、ステップS42に戻る。もはや未調査のストレージ装置がない場合には、呼び出し元に対してボリューム作成の失敗を報告する。このように、本実施例では、データ再配置の指示時点で存在していた空きボリューム群の中から移動先として適切なボリュームを選択するだけでなく、適切な空きボリュームが存在しなかった場合、未割当てのストレージ容量の中から移動先として適切なボリュームを作成することができるので、より柔軟なデータ再配置処理が可能となる。なお、再配置処理の終了後、移動前のデータを保持していた移動元ボリュームは、ボリューム管理テーブルにおける使用状態を空きに変更して再利用可能な状態に戻してもよく、ボリューム自体を削除してストレージ装置の空き容量の一部に戻す構成としてもよい。図24は、図22におけるボリューム作成処理S31の他の例を示すフローチャートである。これは、移動先のボリュームLDEVを複数のVDEVの空き領域から作成することを可能にしたものである。図24に示すボリューム作成処理では、ストレージ管理サーバ60は、まずボリューム仮想化装置20およびボリューム仮想化装置20に接続されたストレージ装置群の中から、1台のストレージ装置を選択するS41。次に、選択したストレージ装置が、作成すべきボリュームに関するストレージ装置要件を満たすかどうかを判定するS42。ここで、ストレージ装置要件とは、配置先として指定されたストレージ階層を定義する諸条件のうち、ストレージ装置の機種名、装置番号等、ストレージ装置の持つ属性に関わる条件もしあればを指す。選択したストレージ装置がストレージ装置要件を満たす場合、ストレージ管理サーバ60は、選択したストレージ装置内にあるすべてのVDEVのうち、VDEV要件を満たすものの集合Sを求めるS43。次に、集合Sの中から1個のVDEVを選択するS44。ここで、VDEV要件とは、配置先として指定されたストレージ階層を定義する諸条件のうち、ディスク種別、RAIDレベル等、VDEVの持つ属性に関わる条件もしあれば、および、移動元ボリュームのエミュレーションタイプを指す。次に、ストレージ管理サーバ60は、選択したVDEV内にある未割当ての空き容量が、移動元ボリュームの容量Q1と同等以上の大きさであるかどうかを判定するS45。空き容量が移動元ボリュームの容量と同等以上である場合、そのVDEV内部に移動元ボリュームと同一の容量を持つボリュームLDEVを新たに作成しS46、呼び出し元に対してボリューム作成の成功を報告する。ステップS45で、移動元ボリュームの容量と同等以上の空き容量がない場合、そのVDEV内部の空き容量Q2を確保しS81、移動元ボリュームの容量Q1と確保した空き容量Q2の差分容量Q3を求めるS82。この時点では、まだ移動元ボリュームと同等以上の容量が確保されていないので、ストレージ管理サーバ60は、集合S内に他のVDEVがあるかどうかを判定しS83、あれば次にそのVDEVを選択して、そのVDEV内にある未割当の空き容量が、差分容量Q3と同等以上の大きさであるかどうかを判断するS84。空き容量が差分容量Q3と同等以上の大きさである場合、そのVDEV内の空き容量と、これまでのVDEVから確保してきた空き容量を用いて移動元ボリュームと同一の容量を持つボリュームLDEVを新たに作成しS85、呼び出し元に対してボリューム作成の成功を報告する。一方、ステップS84でVDEVの空き容量が差分容量Q3と同等以上でない場合、当該VDEVの空き容量Q2を確保しS86、残りの差分容量Q3を求めS87、ステップS83へ戻る。ステップS83で、集合S内に他のVDEVがない場合、そのストレージ装置内では必要な空き容量を確保できないので、ストレージ管理サーバ60は、これまでに確保した空き容量を解放した後S88、他に未調査のストレージ装置がないかどうかを判定するS49。ステップS42において、選択したストレージ装置はストレージ装置要件を満たさないと判定された場合にも、同様にステップS49に移る。ステップS49において、他にもストレージ装置がある場合、次のストレージ装置を選択しS50、ステップS42に戻る。もはや未調査のストレージ装置がない場合には、呼び出し元に対してボリューム作成の失敗を報告する。このように一つのVDEVから移動元のボリュームの容量を確保できない場合、空き容量を有する複数のVDEVから移動先候補となるボリュームLDEVを生成する。なお、図23、図24のステップ41に、ストレージ装置を選択するようにしているが、ボリューム仮想化装置が、接続されているストレージ装置内のすべてのVDEVを一括管理することにより、ステップ41のストレージ装置の選択を省略し、ボリューム仮想化装置によって管理されたVDEVを順に選択する構成としても良い。図25、図26、図27、図28、図29、図30に基いて、本発明の第6実施例を説明する。本実施例の特徴は、再配置先として指定されたストレージ階層に対応付けられたアクション中にレプリカの作成が含まれている場合に、再配置先を含む任意のストレージ階層をレプリカ作成先として指定できる点にある。図25は、本実施例における、ストレージ階層とアクションとの対応付けを示す図である。本実施例では、スクリプト中でレプリカの作成を指示する場合、レプリカの作成先となるストレージ階層を、その名称によって明示的に指定する。図25に示すとおり、レプリカの作成先となるストレージ階層は、再配置先として指定されたストレージ階層自身と同一でもよく、また異なっていてもよい。図26は、本実施例におけるボリューム属性管理テーブルT2の構成を示す図である。本実施例のボリューム属性管理テーブルでは、ボリュームの使用状態は使用中空きの2状態ではなく、ソースレプリカリザーブ空きの4状態をとる。また、新たな属性としてペアが追加されている。使用状態ソースは、そのボリュームがホストから参照されるユーザデータを保持していることを示す。使用状態レプリカは、そのボリュームがユーザデータの複製であるレプリカを保持していることを示す。使用状態リザーブは、そのボリュームが将来レプリカとして使うために予約されていることを示す。使用状態空きは、そのボリュームが以上の3状態のいずれでもなく、データの移動先やコピー先として新たに割当て可能であることを示す。ボリュームの使用状態がソースレプリカリザーブのいずれかである場合、そのボリュームの属性ペアは値を持つことができる。ボリュームの使用状態がソースで、かつそのボリュームがレプリカを持っている場合、属性ペアの値は、対となるレプリカボリュームの論理IDを示す。ただし、そのボリュームがレプリカを持たない場合、属性ペアの値は空となる。ボリュームの使用状態がレプリカの場合、属性ペアの値は、対となるソースボリュームの論理IDとなる。ボリュームの使用状態がリザーブの場合、属性ペアには、そのボリュームと将来対となるソースボリュームの論理IDが設定される。図27は、本実施例におけるデータ再配置処理の概略を示すフローチャートである。本実施例のデータ再配置処理では、マイグレーショングループの所定階層への再配置をユーザが指示しS1、移動先候補選択処理S2、ボリューム対応表の提示S3、移動先候補の修正S4を行った後、再配置実行処理S5を行う前に、レプリカボリュームリザーブ処理S6を実行する。図28は、レプリカボリュームリザーブ処理S6の処理内容を示すフローチャートである。本実施例のレプリカボリュームリザーブ処理において、ストレージ管理サーバ60は、まずストレージ階層管理テーブルT3およびアクション管理テーブルT6を参照し、再配置先として指定されたストレージ階層に対応付けられたアクションを得るS61。次に、取得したアクション中で、レプリカ作成が指示されているかどうかを判定するS62。レプリカ作成が指示されていない場合、または再配置先ストレージ階層にアクションが対応付けられていない場合は、レプリカボリュームのリザーブは不要であるため、処理を終了する。アクション中でレプリカ作成が指示されている場合、ストレージ管理サーバ60は、移動元の全ボリュームについて既にレプリカボリュームがリザーブ済みであるかどうかを判定するS63。最初はリザーブ済みではないため次のステップに進み、1個の移動元ボリュームに対応して1個のレプリカボリュームを選択するS64。ここで、レプリカボリュームとして選択できるのは、レプリカ作成先として指定されたストレージ階層に属しており、使用状態が空きで、移動先候補として選択されておらず、必須属性が移動元ボリュームと一致するボリュームである。次に、ストレージ管理サーバ60は、そのようなボリュームが選択できたかどうかを判定するS65。選択できなかった場合、レプリカ作成に必要なボリュームが確保できなかったことになるため、エラー処理を行いS67、ユーザに通知する。なお、ここで図22のS31からS34の処理を実行してレプリカ作成に必要なボリュームを作成するようにしてもよい。選択できた場合には、そのボリュームをリザーブしS66、ステップS63に戻り、移動元の全ボリュームについてレプリカボリュームのリザーブが済むまで同様の処理を繰り返す。ここで、あるボリュームをリザーブするとは、ボリューム属性管理テーブルT2において、そのボリュームの使用状態をリザーブに変更し、かつそのボリュームの属性ペアに、対応する移動元ボリュームの論理IDを設定することである。図29は、本実施例における、アクションスクリプト実行処理の詳細を示すフローチャートである。この処理は、図15に示す再配置実行処理のステップS28に相当し、1個の移動元ボリュームの記憶内容を対応する移動先ボリュームにコピーし、そのアクセスパス論理IDを切り替えた後に、移動先ボリュームを対象として、再配置先ストレージ階層に対応付けられたアクションを実行する処理である。図29に示すアクションスクリプト実行処理において、ストレージ管理サーバ60は、まず対象となる移動先ボリュームに関して、未実行のアクションがあるかどうかを判定するS71。未実行のアクションがある場合、1個の未実行アクションを取り出しS72、その種別を判別するS73。アクション種別がレプリカ作成であった場合、ストレージ管理サーバ60は、ボリューム管理テーブルT2を参照して、移動先ボリュームに対応してリザーブされているリザーブボリュームを取得するS74。ここで、移動先ボリュームに対応してリザーブされているリザーブボリュームとは、属性ペアの値として移動先ボリュームの論理IDを保持しているボリュームのことである。次に、ストレージ管理サーバ60は、ボリューム仮想化装置20に対して、移動先ボリュームをプライマリ、リザーブボリュームをセカンダリとするペア関係を設定するS75。同時に、ボリューム属性管理テーブルT2上において、移動先ボリュームの属性ペアに対応するリザーブボリュームの論理IDを設定し、またリザーブボリュームの使用状態をレプリカに変更する。次に、ストレージ管理サーバ60は、ボリューム仮想化装置20に対して、ステップS75でペア関係を設定したボリューム間の同期化を指示するS76。これにより、移動先ボリュームプライマリからリザーブボリュームセカンダリへデータのコピーが行われ、両者の内容は同一となる。また、これ以降、プライマリボリュームの内容が書き換えられると、書き換えられた部分のデータがセカンダリボリュームにコピーされ、両者の内容は常に同一に保たれる。以上の処理を行った後、ストレージ管理サーバ60は、ステップS71に戻って再び未実行アクションの有無を判定する。また、ステップS73においてアクション種別がレプリカ作成以外と判定された場合、アクション種別に対応した所定の処理を実行しS77、同じくステップS71に戻る。ステップS71において、もはや未実行のアクションはないと判断されると、ストレージ管理サーバ60はアクションスクリプト実行処理を終了する。図30は、本実施例のデータ再配置処理の過程の各段階における、ボリューム属性管理テーブルT2の状態の一例を示す図である。図30は初期状態を示しており、必須属性容量およびエミュレーションタイプが一致する3個のボリュームが登録されている。このうち、論理ID001のボリュームはユーザデータを保持しており、論理ID006および007のボリュームは空き状態である。この状態で、論理ID001のボリュームを移動元、論理ID006のボリュームを移動先とし、かつレプリカ作成を伴うデータ再配置が指示されたものとする。図30は、レプリカボリュームリザーブ処理S6において、論理ID007のボリュームがレプリカ用のリザーブボリュームとして選択された状態を示している。ボリューム007の使用状態はリザーブとなり、その属性ペアには移動元ボリュームの論理IDである001が設定される。図30は、データ再配置処理終了後の状態を示している。移動元ボリュームから移動先ボリュームにデータがコピーされた後、両者のアクセスパス論理IDの入れ替えが行われ、この時点では移動先ボリュームの論理IDが001となっている。論理ID007のボリュームはそのレプリカを保持しており、ソースとレプリカの両ボリュームは互いに属性ペアで参照しあっている。このように、本実施例では、ストレージ階層に対応付けられたアクションの中で、任意のストレージ階層をレプリカ作成先として指定しておき、データの再配置処理が行われた場合に、再配置処理の一環として、他のストレージ階層または再配置先と同一のストレージ階層内に、移動したデータのレプリカを自動的に作成することができる。これにより、例えば高信頼階層の定義の一部として低コスト階層へのレプリカ作成を記述するなど、柔軟で有用性の高いストレージ階層定義が可能となる。"