JP4643395B2

JP4643395B2 - ストレージシステム及びデータの移動方法

Info

Publication number: JP4643395B2
Application number: JP2005245386A
Authority: JP
Inventors: 亨高橋; 達人青島; 伸夫紅山; 沢希黒田; 朋之加地; 哲也丸山
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2004-08-30
Filing date: 2005-08-26
Publication date: 2011-03-02
Anticipated expiration: 2025-08-26
Also published as: JP2006099748A

Description

本発明は、ストレージシステム及びデータ再配置制御装置に関する。

ストレージシステムは、例えば、ディスクアレイサブシステム等として呼ばれるストレージ装置を少なくとも一つ以上備えて構成される。このストレージ装置は、例えば、ハードディスクドライブや半導体メモリドライブ等のディスクドライブをアレイ状に配設し、RAID（Redundant Array of Independent Inexpensive Disks）に基づく記憶領域を提供する。ホストコンピュータ（以下、「ホスト」）は、ストレージ装置により提供される論理的な記憶領域にアクセスし、データの読み書きを行う。

ところで、例えば、企業や地方自治体、教育機関、金融機関、官公庁等の組織で管理されるデータ量は年々増加する一方であり、データ量の増加に伴ってストレージ装置の追加や置換が行われる。このようなデータ量の増大とストレージシステムの構成の複雑化に伴って、メール管理ソフトウェアやデータベース管理ソフトウェア等の各種アプリケーションプログラムのデータを、そのデータの価値に応じた適切な位置に配置し、ストレージシステムの利用効率を改善することが提案されている（特許文献１〜５）。
特開２００３−３４５５２２号公報特開２００１−３３７７９０号公報特開２００１−６７１８７号公報特開２００１−２４９８５３号公報特開２００４−７０４０３号公報

上記の各特許文献では、ディスクの性能情報や利用情報に基づいて、一方のボリュームに記憶されているデータを他のボリュームにコピーさせ、データを再配置する技術が開示されている。

しかし、これらの文献に記載の技術では、各ボリューム単位に個別にデータを再配置する必要があり、ユーザが自由に定義した階層間でボリュームを移動させることができず、使い勝手が低い。また、前記各文献に記載の技術では、各ボリューム単位のデータ再配置を行うため、関連する一群のボリュームを一括して再配置させるのが難しい。さらに、前記各文献に記載の技術では、データの再配置のみに注目しており、再配置後の処理については何ら考慮されておらず、この点においても使い勝手が低い。

そこで、本発明の一つの目的は、複数のストレージ装置に分散されたデータをより簡単に再配置することができるストレージシステム及びデータ再配置制御装置を提供することにある。
本発明の一つの目的は、相互に関連する複数のボリュームにそれぞれ記憶されたデータを一括して再配置することにより、使い勝手を高めたストレージシステム及びデータ再配置制御装置を提供することにある。
本発明の一つの目的は、データ再配置後に必要な処理を自動的に実行させることにより、使い勝手を高めたストレージシステム及びデータ再配置制御装置を提供することにある。本発明のさらなる目的は、後述する実施形態の記載から明らかになるであろう。

上記課題を解決すべく、本発明のストレージシステムは、それぞれ少なくとも一つ以上のボリュームを有する複数のストレージ装置と、各ストレージ装置の有するボリュームを仮想的に一元管理する仮想化部と、各ボリュームの属性情報を管理するボリューム属性情報を記憶する記憶部と、予め設定された複数のポリシーとボリューム属性情報とに基づいてそれぞれ生成される複数のストレージ階層間で、指定された移動元ボリュームを指定されたストレージ階層に再配置させる再配置部と、を備える。

ここで、ポリシーは、ユーザが任意に設定可能であり、同一のボリュームが異なるストレージ階層に所属することもあり得る。また、ストレージ階層は、各ストレージ装置単位で、あるいは複数のストレージ装置にまたがって設定可能である。

例えば、各ポリシーをそれぞれ識別するためのポリシー識別情報と、該各ポリシー識別情報毎にそれぞれ対応付けられた階層構成条件とを含むストレージ階層管理情報を備え、各階層構成条件を満たすボリューム群によって、各ポリシーに応じたストレージ階層をそれぞれ生成することができる。そして、階層構成条件には、RAIDレベル、ドライブの種別、記憶容量、ストレージ装置の種別、使用状態のうち少なくともいずれか一つを含めることができる。

即ち、例えば、高性能なディスクから構成される高性能階層、低コストなディスクから構成される低コスト階層等のように、ストレージ階層は、ユーザの定義するポリシーに従って生成される。各ストレージ階層に属する一つまたは複数のボリュームは、同一のストレージ装置内に存在する場合もあるし、それぞれ異なるストレージ装置内に存在する場合もある。

各階層を定義づけるポリシーは、ユーザにより設定可能な階層構成条件によって決定される。例えば、高性能階層を定義する場合、ユーザは、高性能なディスクや高性能なストレージ装置を選択するための条件を階層構成条件として設定すればよい。また、例えば、低コスト階層を定義する場合、ユーザは、安価なディスクを選択するための条件を、階層構成条件として設定すればよい。これら各階層構成条件を満たすボリュームにより、そのストレージ階層が構成される。

あるストレージ階層に属するボリュームのデータを再配置する場合は、移動元のボリュームと移動先のストレージ階層とをそれぞれ指定すればよい。これにより、指定された移動元ボリュームのデータは、指定された移動先ストレージ階層に属するボリュームに移される。

再配置部は、複数のボリュームからなるグループ単位で、例えば、相互に関連した複数のボリュームからなるグループ単位で、指定された移動元ボリュームを再配置させることもできる。相互に関連した複数のボリュームとしては、例えば、同一のアプリケーションプログラムにより使用されるデータを記憶するボリューム群、同一のファイルシステムを構成するデータを記憶するボリューム群等を挙げることができる。なお、データ同士の関連性が乏しい場合であっても、グループ化することができる。

再配置部は、指定された移動元ボリュームを移動先のストレージ階層に移動させた後で、この移動されたボリュームに対して、移動先のストレージ階層に予め対応付けられている所定の処理を実行することもできる。所定の処理としては、例えば、リードオンリー等のようなアクセス属性の設定や、ボリュームの二重化等を挙げることができる。

再配置部は、指定された移動元ボリュームの記憶内容をコピー可能な移動先候補ボリュームを選択する移動先候補選択部と、この移動先候補選択部により選択された移動先候補ボリュームをユーザに提示する提示部とを備え、移動先候補選択部は、ボリューム属性情報を参照することにより、移動元ボリュームの有する各属性のうち予め設定された必須属性が一致するボリュームを移動先候補ボリュームとして選択することができる。

ボリューム属性情報は、静的属性と動的属性とを含んで構成可能であり、静的属性に含まれる所定の属性を前記必須属性として設定可能である。必須属性には、少なくともボリュームの記憶容量を含めることができる。

このように、再配置部は、移動元ボリュームの必須属性に一致するボリュームを、移動先候補ボリュームとして選択する。移動先候補選択部は、必須属性の一致する移動先候補ボリュームが複数存在する場合に、必須属性以外の他の属性の一致具合に基づいて、移動先候補ボリュームを一つだけ選択することができる。必須属性以外の属性としては、例えば、RAIDレベル、ディスク種別、ストレージ装置の機種等を挙げることができる。つまり、必須属性が一致するボリュームが複数抽出された場合は、これら各ボリュームのうち最も移動元ボリュームに近い構成を有するボリュームが移動先候補ボリュームとして選択される。

そして、再配置部は、移動先候補選択部により選択された移動先候補ボリュームを変更するための変更部を更に備えることができる。この変更部は、必須属性は一致するが選択されなかった移動先候補ボリュームの中から、移動先候補ボリュームを選択させることができる。

例えば、移動先候補ボリュームが特定のRAIDグループに集中したり、ランダムアクセスされるデータとシーケンシャルアクセスされるデータのように使用態様が異なるデータ群が同一のRAIDグループに存在しないように、変更部は、いったん選択された移動先候補ボリュームを変更させることができる。変更部は、ユーザからの指示に基づいて、移動先候補ボリュームの変更を行うことができる。

本発明の他の観点に従うデータ再配置制御装置は、複数のストレージ装置に分散して配置される複数のボリュームのデータ再配置を制御する。そして、各ボリュームは、仮想化部によって仮想的に一元管理されており、記憶部と制御部とを備えている。（Ａ）記憶部には、（ａ１）少なくとも各ボリュームの識別情報、RAIDレベル、ドライブの種別、記憶容量、使用状態を含むボリュームの属性情報と、（ａ２）ユーザにより定義可能な複数のポリシーをそれぞれ識別するためのポリシー識別情報と、これら各ポリシー識別情報毎にそれぞれ対応付けられた階層構成条件とを含むストレージ階層管理情報と、をそれぞれ記憶することができる。（Ｂ）制御部は、ストレージ階層管理情報とボリューム属性情報とに基づいてそれぞれ生成される複数のストレージ階層間で、指定された移動元ボリュームを指定されたストレージ階層に再配置させる再配置部を備えることができる。

また、本発明に従う別のデータ再配置制御装置は、複数のストレージ装置がそれぞれ有するボリュームを一元管理し、前記各ボリュームに記憶されたデータの再配置を制御する装置であって、各ストレージ装置の有するボリュームを仮想的に一元管理する仮想化部と、各ボリュームの属性情報を管理するボリューム属性情報を記憶する記憶部と、予め設定された複数のポリシーとボリューム属性情報とに基づいてそれぞれ生成される複数のストレージ階層間で、指定された移動元ボリュームを指定されたストレージ階層に再配置させる再配置部と、を備える。

本発明は、例えば、以下のようなデータ再配置方法として捉えることもできる。即ち、複数のストレージ装置に分散された複数のボリュームに記憶されているデータを同一または異なるストレージ装置内のボリュームに再配置する方法であって、各ストレージ装置の有するボリュームは仮想的に一元管理されており、各ボリュームの属性情報をボリューム属性情報として管理し、複数のポリシーをそれぞれ予め設定し、これら複数のポリシーとボリューム属性情報とに基づいて複数のストレージ階層を生成し、移動元ボリューム及び移動先ストレージ階層をそれぞれ設定し、各ストレージ階層間で、指定された移動元ボリュームを指定されたストレージ階層に再配置させる。

本発明の手段、機能、ステップの少なくとも一部は、マイクロコンピュータにより読み込まれて実行されるコンピュータプログラムとして構成できる場合がある。このようなコンピュータプログラムは、例えば、ハードディスクや光ディスク等のような記憶媒体に固定して流通させることができる。または、インターネット等のような通信ネットワークを介して、コンピュータプログラムを供給することもできる。

以下、図面に基づき、本発明の実施の形態を説明する。図１は、本実施形態の全体概念を模式的に示す説明図である。以下に述べるように、本実施形態のストレージシステムは、複数のストレージ装置Ａ〜Ｄを備えている。

各ストレージ装置Ａ〜Ｄの有するボリュームは、仮想的に一元管理されており、ホスト（図２参照）は、複数のストレージ装置Ａ〜Ｄを全体として一つの仮想的なストレージ装置として認識する。

各ストレージ装置Ａ〜Ｄは、それぞれボリュームＡ１〜Ａ４，Ｂ１〜Ｂ４，Ｃ１〜Ｃ４，Ｄ１〜Ｄ４を備えている。これら各ボリュームは、例えば、ハードディスクドライブや半導体メモリドライブあるいは光ディスクドライブ等の物理的な記憶ドライブにより提供される物理的な記憶領域上に設定される論理的な記憶領域である。

ここで、各ストレージ装置Ａ〜Ｄは、それぞれ同一種類のドライブを備えることもできるし、あるいは、それぞれ異なる種類のドライブを混在させることもできる。従って、同一のストレージ装置内に位置するボリュームであっても、性能や価格等のボリューム属性がそれぞれ異なる場合がある。

ユーザは、ストレージシステムの有する各ボリュームを、複数のストレージ階層１〜３として任意にグループ化することができる。例えば、ある一つのストレージ階層１は、高信頼性階層として定義可能である。高信頼性階層は、例えば、ファイバチャネルディスク（ＦＣディスク）等の高信頼性ドライブをRAID１で構成してなるボリューム群により構成される。また、他の一つのストレージ階層２は、例えば、低コスト階層として定義可能である。低コスト層は、例えば、SATA（Serial AT Attachment）ディスク等の安価なドライブをRAID５で構成してなるボリューム群により構成される。さらに、別の一つのストレージ階層３は、例えば、アーカイブ階層として定義可能である。アーカイブ階層は、例えば、所定容量未満の安価なディスク上に設定されるボリューム群から構成することができる。

図１に示すように、各ストレージ階層１〜３は、各ストレージ装置Ａ〜Ｄを跨って仮想的に構成される。つまり、ユーザは、例えば、高信頼性階層、低コスト階層、高速応答性階層、アーカイブ階層等のように、ビジネス上の使用基準（ポリシー）に基づいて、ストレージシステムを構成する複数のボリュームを、所望のストレージ階層として自由に定義することができる。ポリシーは、ストレージシステムの構成とは独立して設定可能であるため、各ストレージ階層を構成する条件によっては、一部のボリュームが複数のストレージ階層に属する場合もあるし、あるいは、他の一部のボリュームがいずれのストレージ階層にも属さない場合も生じうる。

各ストレージ階層１〜３には、データ再配置対象となるボリューム群をそれぞれ設けることができる。一つの例として、ストレージ階層１に、二つのボリュームＶ１，Ｖ２からなるマイグレーショングループを示す。これら各ボリュームＶ１，Ｖ２は、例えば、同一のアプリケーションプログラムにより使用されるデータ群または同一のファイルシステムを構成するデータ群を記憶する等のように、互いに関連するボリュームである。

データの価値は、例えば時間の経過と共に低下していく。価値の高いデータは、高信頼性階層に置かれ、アプリケーションプログラムにより頻繁に利用される。時間の経過と共に価値が低下したデータは、他のストレージ階層に移動させるのが好ましい。高信頼性階層の記憶資源には限りがあるからである。

そこで、ユーザは、互いに関連する複数のボリュームＶ１，Ｖ２に記憶されているデータの再配置を検討し、例えば、ストレージ階層１からストレージ階層３（ここでは、アーカイブ階層）への移動を決定する。ユーザは、移動元ボリュームＶ１，Ｖ２の再配置を一括して指定し、ストレージ階層３への移動を指示する。

これにより、移動先のストレージ階層３では、マイグレーショングループを構成する各ボリュームＶ１，Ｖ２のデータをそれぞれ記憶可能なボリュームを選択し、これら選択されたボリュームにデータをコピーする。コピー完了後に、移動元ボリュームＶ１，Ｖ２のデータは削除することができ、空きボリュームとして再利用される。

ここで、各ストレージ階層１〜３には、各ストレージ階層１〜３のポリシーに応じて、それぞれ予め所定のアクションを対応づけることができる。ここで、アクションとは、そのストレージ階層内で実行される所定の情報処理、データ操作を意味する。例えば、高信頼性階層として定義されるストレージ階層１には、再配置されたデータの複製を生成する処理が予め対応づけられている。また、例えば、低コスト階層として定義されるストレージ階層２には、何のアクションも対応づけないようにすることもできる。さらに、例えば、アーカイブ階層として定義されるストレージ階層３には、再配置されたデータの複製を生成する処理と、リードオンリーのアクセス属性を設定する処理との複数の処理をアクションとして対応づけておくことができる。

マイグレーショングループを構成する各ボリュームＶ１，Ｖ２のデータが、ストレージ階層３に属するボリュームにコピーされると、ストレージ階層３に対応づけられている所定のアクションが自動的に実行される。ストレージ階層３に再配置されたデータは、その複製が生成されると共に、リードオンリーに設定され、改変が禁止される。

ここで、各ボリュームＶ１，Ｖ２のデータを再配置する場合、そのデータをコピー可能なボリュームが、移動先のストレージ階層内で選択される。各ボリュームは、それぞれ属性情報を有している。ボリューム属性情報としては、例えば、各ボリュームを識別するための識別情報、RAIDレベル、ディスク種別、記憶容量、使用中か否かを示す使用状態、所属するストレージ装置の機種等を挙げることができる。

これらのボリューム属性の全てが、移動元ボリューム（Ｖ１，Ｖ２）と、移動先候補のボリュームとの間で一致している必要はなく、一部の必須的な属性のみが一致していれば足りる。必須属性としては、例えば、記憶容量を挙げることができる。即ち、移動元ボリュームの記憶容量と同一またはそれ以上の記憶容量を有するボリュームを、移動先ボリュームとして選択することができる。

必須属性の一致するボリュームが必要数以上に検出された場合は、必須属性以外の他の属性の一致度を考慮し、より移動元ボリュームに近い属性を備えるボリュームを、移動先ボリュームとして選択することができる。一つの例として、ボリューム属性を必須属性とそれ以外の属性との二種類に大別したが、これに限らず、例えば、必須属性と、準必須属性と、その他の属性等のように、三種類以上の属性に分類し、各種類の属性に重みをつけて、ボリューム間の一致度を求める構成でもよい。一例として、ボリューム容量およびエミュレーションタイプを必須属性、それ以外の属性（RAIDレベル、ディスク種別等）をその他の属性（非必須属性）とすることができる。あるいは、エミュレーションタイプを必須属性、ボリューム容量を準必須属性、それ以外の属性を非必須属性とする構成でもよい。ボリューム容量を準必須属性とした場合、移動元ボリュームと移動先ボリュームの容量は必ずしも一致しなくともよいが、移動先ボリュームは移動元ボリュームと同一またはそれ以上の容量を持っていなければならない。また、ボリューム属性のうち使用状態はこれらの分類に含まれない例外的な属性であって、移動先ボリュームの使用状態は常に「空き」でなければならない。

図２は、ストレージシステムの全体構成を概略的に示すブロック図である。このストレージシステムは、それぞれ後述するように、例えば、複数のホスト１０Ａ，１０Ｂ（特に区別しない場合は「ホスト１０」）と、ボリューム仮想化装置２０と、複数のストレージ装置３０，４０と、管理クライアント５０と、ストレージ管理サーバ６０とを含んで構成することができ、これらは、LAN（Local Area Network）等の通信ネットワークＣＮ１を介して相互に接続されている。

各ホスト１０Ａ，１０Ｂは、例えば、サーバ、パーソナルコンピュータ、ワークステーション、メインフレーム、携帯情報端末等のようなコンピュータシステムとして実現することができる。そして、例えば、複数のオープン系ホストと複数のメインフレーム系ホストとを、同一のストレージシステムに混在させることができる。

各ホスト１０Ａ，１０Ｂは、例えば、アプリケーションプログラム（図中では「App」と略記）１１Ａ，１１Ｂ（特に区別しない場合は「アプリケーションプログラム１１」）と、HBA（Host Bus Adapter）１２Ａ，１２Ｂ（特に区別しない場合は「HBA１２」）とを備えることができる。これらアプリケーションプログラム１１及びHBA１２は、一つのホスト１０について、それぞれ複数設けることができる。

アプリケーションプログラム１１Ａ，１１Ｂとしては、例えば、電子メール管理プログラム、データベース管理プログラム、ファイルシステム等を挙げることができる。アプリケーションプログラム１１Ａ，１１Ｂは、図外の複数のクライアント端末と別の通信ネットワークを介して接続されることができ、各クライアント端末からの要求に応じて情報処理サービスを提供することができる。

HBA１２は、ストレージシステムとの間でデータの送受信を担当するもので、通信ネットワークＣＮ２を介して、ボリューム仮想化装置２０に接続されている。ここで、通信ネットワークＣＮ２としては、例えば、LAN、SAN（Storage Area Network）、インターネット、専用回線等を挙げることができる。オープン系ホストの場合は、例えば、TCP/IP（Transmission Control Protocol/Internet Protocol）、FCP（Fibre Channel Protocol ）、iSCSI（internet Small Computer System Interface）等のプロトコルに基づいて、データ転送が行われる。メインフレーム系ホストの場合は、例えば、FICON（Fibre Connection：登録商標）、ESCON（Enterprise System Connection：登録商標）、ACONARC（Advanced Connection Architecture：登録商標）、FIBARC（Fibre Connection Architecture：登録商標）等の通信プロトコルに従ってデータ転送が行われる。

このほか、各ホスト１０Ａ，１０Ｂには、それぞれパス制御プログラム等の管理プログラム（不図示）を搭載してもよい。このような管理プログラムは、例えば、複数のHBA１２間で負荷を分散させたり、障害発生時にはパスを切り替える等の処理を行う。

ボリューム仮想化装置（以下「仮想化装置」とも呼ぶ）２０は、ストレージシステム内に存在するボリューム３３０，４３０等を仮想化し、一つの仮想的なストレージ装置に見せかけるものである。図３（ａ）に示すように、例えば、仮想化装置２０は、各ホスト１０に対して、識別情報LID００１〜LID００４で示す複数の論理ボリューム（LDEV）を提供する。これらの各論理ボリュームは、識別情報PID０１〜PID０４で示す別の論理ボリュームにそれぞれ対応づけられている。識別情報PIDを有する論理ボリュームが実際にデータを格納する実ボリュームであり、ホスト１０が直接認識可能な論理ボリュームは、仮想ボリュームである。

仮想ボリュームと実ボリュームとのマッピングを制御することにより、ホスト１０に対して透過的に、データの移動を行うことができる。例えば、図３（ｂ）に示すように、実ボリューム（PID０１）に記憶されているデータを、別の実ボリューム（PID０２）に移動させる場合は、これら実ボリューム間でデータをコピーした後、実ボリュームと仮想ボリュームとのマッピングを設定し直せばよい。あるいは、仮想ボリューム（LID００１）と仮想ボリューム（LID００２）との間で、識別情報を交換することにより、ホスト１０に意識されることなく、データ格納先のデバイスを変更することもできる。

このように、仮想化装置２０は、ストレージシステム上に存在する多種多様な実ボリュームを仮想化して一元的に管理し、ホスト１０に提供する。仮想化装置２０は、後述のように、ストレージ装置内に設けることもできるし、あるいは、高機能なインテリジェント型スイッチに設けることもできる。さらに、後述のように、仮想化装置２０とストレージ管理サーバ６０とを同一のコンピュータ上に設けることもできる。

図２に戻る。各ストレージ装置３０，４０は、それぞれ論理ボリューム（実ボリューム）３３０，４３０を備えており、SAN等の通信ネットワークＣＮ３を介して、仮想化装置２０にそれぞれ接続されている。各ストレージ装置３０，４０は、ホスト１０からの要求に応じて、ボリュームへのデータ読み書きを行う。ストレージ装置の構成例は、さらに後述する。

管理クライアント５０は、例えば、パーソナルコンピュータやワークステーション、携帯情報端末等のコンピュータシステムとして構成されており、ウェブヴラウザ５１を備えている。ユーザは、ウェブヴラウザ５１を操作してストレージ管理サーバ６０にログインすることにより、例えば、ストレージシステムに対して各種の指示を与えたり、ストレージシステム内の各種情報を取得することができる。

ストレージ管理サーバ６０は、ストレージシステムのボリューム再配置等を管理するコンピュータシステムである。ストレージ管理サーバ６０の構成例は、さらに後述するが、例えば、データ再配置管理部６３２と、ボリュームデータベース（図中「ＤＢ」）６４０とを備えることができる。

図４は、ストレージシステムのハードウェア構成を概略的に示すブロック図であり、仮想化装置２０をストレージ装置として構成した場合を示す。

以下、本実施例では、仮想化装置２０を、第３ストレージ装置２０とも呼ぶ。第３ストレージ装置２０は、それぞれ後述するように、例えば、複数のチャネルアダプタ（以下「CHA」）２１０と、複数のディスクアダプタ（以下「DKA」）２２０と、キャッシュメモリ２３０と、共有メモリ２４０と、接続制御部２５０，２６０と、記憶部２７０と、SVP２８０とを備えて構成することができる。

CHA２１０は、ホスト１０や外部の第１ストレージ装置３０及び第２ストレージ装置４０との間のデータ授受を制御するもので、例えば、CPUやメモリ、入出力回路等を備えたマイクロコンピュータシステムとして構成可能である。各CHA２１０は、それぞれ複数の通信ポート２１１を備えることができ、各通信ポート２１１毎にそれぞれ個別にデータ授受を行うことができる。各CHA２１０は、それぞれ一種類の通信プロトコルに対応しており、ホスト１０の種類に応じて用意される。但し、各CHA２１０がそれぞれ複数種類の通信プロトコルに対応する構成としてもよい。

DKA２２０は、記憶部２７０との間のデータ授受を制御する。DKA２２０は、CHA２１０と同様に、例えば、CPUやメモリ等を備えたマイクロコンピュータシステムとして構成することができる。各DKA２２０は、例えば、ホスト１０から指定された論理ブロックアドレス（LBA）を物理ディスクのアドレスに変換等することにより、各ディスクドライブ２７１にアクセスし、データの読出しまたはデータの書込みを行う。なお、CHA２１０の機能とDKA２２０の機能とを一つまたは複数のコントローラ内に集約する構成としてもよい。

キャッシュメモリ２３０は、ホスト１０から書き込まれたライトデータや、ホスト１０に読み出されたリードデータを記憶するものである。キャッシュメモリ２３０は、例えば、揮発または不揮発のメモリから構成可能である。キャッシュメモリ２３０が揮発性メモリを含んで構成される場合、図示せぬバッテリ電源等によりメモリバックアップを行うことが好ましい。なお、図示は省略するが、キャッシュメモリ２３０は、リードキャッシュ領域とライトキャッシュ領域との２つの領域から構成することができ、ライトキャッシュ領域に格納されたデータは、多重記憶することができる。つまり、同一のデータがディスクドライブ２７１にも存在するリードデータは、仮に失われたとしても再びディスクドライブ２７１から読み出せば足りるので、多重化の必要はない。これに対し、ライトデータは、ストレージ装置２０内においては、キャッシュメモリ２３０にのみ存在するため、多重化記憶させるのが信頼性の点で好ましい。もっとも、キャッシュデータを多重化して記憶させるか否かは、仕様による。

共有メモリ（あるいは制御メモリとも呼ばれる）２４０は、例えば、不揮発メモリから構成可能であるが、揮発メモリから構成してもよい。共有メモリ２４０には、例えば、マッピングテーブルＴ１のように、制御情報や管理情報等が記憶される。これらの制御情報等の情報は、複数のメモリ２４０により多重管理することができる。マッピングテーブルＴ１の構成例については、後述する。

ここで、共有メモリ２４０及びキャッシュメモリ２３０は、それぞれ別々のメモリパッケージとして構成することもできるし、同一のメモリパッケージ内にキャッシュメモリ２３０及び共有メモリ２４０を設けてもよい。また、メモリの一部をキャッシュ領域として使用し、他の一部を制御領域として使用することもできる。つまり、共有メモリとキャッシュメモリとは、同一のメモリとして構成することもできる。

第１の接続制御部（スイッチ部）２５０は、各CHA２１０と、各DKA２２０と、キャッシュメモリ２３０と、共有メモリ２４０とをそれぞれ相互に接続するものである。これにより、全てのCHA２１０，DKA２２０は、キャッシュメモリ２３０及び共有メモリ２４０にそれぞれ個別にアクセス可能である。接続制御部２５０は、例えば、超高速クロスバスイッチ等として構成することができる。第２の接続制御部２６０は、各DKA２２０と記憶部２７０とをそれぞれ接続するためのものである。

記憶部２７０は、多数のディスクドライブ２７１を備えて構成される。記憶部２７０は、各CHA２１０及び各DKA２２０等のコントローラ部分と共に同一の筐体内に設けることもできるし、コントローラ部分とは別の筐体内に設けることもできる。

記憶部２７０には、複数のディスクドライブ２７１を設けることができる。ディスクドライブ２７１としては、例えば、ＦＣディスク（ファイバチャネルディスク）、SCSI（Small Computer System Interface）ディスク、SATA（Serial AT Attachment）ディスク等を用いることができる。また、記憶部２７０は、同一種類のディスクドライブから構成される必要はなく、複数種類のディスクドライブを混在させることもできる。

ここで、一般的には、ＦＣディスク、SCSIディスク、SATAディスクの順番で、性能が低下する。例えば、アクセス頻度の多いデータ（価値の高いデータ等）は、高性能なＦＣディスクに記憶し、アクセス頻度の低いデータ（価値の低いデータ等）は、低性能なSATAディスクに記憶させる等のように、データの利用態様に応じて、ディスクドライブの種類を使い分けることができる。各ディスクドライブ２７１の提供する物理的な記憶領域上には、複数の論理的な記憶領域を階層化して設けることができる。記憶領域の構成については、さらに後述する。

SVP（Service Processor）２８０は、LAN等の内部ネットワークＣＮ１１を介して、各CHA２１０及び各DKA２２０とそれぞれ接続されている。図中では、SVP２８０とCHA２１０とだけを接続しているが、SVP２８０は、各DKA２２０にもそれぞれ接続することができる。SVP２８０は、ストレージ装置２０内の各種状態を収集し、そのままで又は加工して、ストレージ管理サーバ６０に提供する。

ボリューム仮想化を実現する第３ストレージ装置２０は、ホスト１０からのデータ入出力要求を処理する窓口であり、第１ストレージ装置３０及び第２ストレージ装置４０と通信ネットワークＣＮ３を介して、それぞれ接続されている。なお、図中では、ストレージ装置２０に二つのストレージ装置３０，４０を接続する状態を示すが、これに限らず、ストレージ装置２０に一つのストレージ装置を接続してもよく、あるいは、ストレージ装置２０に三つ以上のストレージ装置を接続してもよい。

第１ストレージ装置３０は、例えば、コントローラ３１０と、第３ストレージ装置２０と接続するための通信ポート３１１と、ディスクドライブ３２０とを備えて構成することができる。コントローラ３１０は、上述したCHA２１０及びDKA２２０の機能を実現するもので、第３ストレージ装置２０及びディスクドライブ３２０とのデータ授受をそれぞれ制御する。

第１ストレージ装置３０は、第３ストレージ装置２０と同一または実質的に同一の構成を備えてもよいし、第３ストレージ装置２０と異なる構成でもよい。第１ストレージ装置３０は、第３ストレージ装置２０との間で所定の通信プロトコル（例えば、FCやiSCSI等）に従ったデータ通信を行うことができ、ディスクドライブ３２０等の記憶ドライブ（記憶用デバイス）を備えていればよい。後述のように、第１ストレージ装置３０の有する論理ボリュームは、第３ストレージ装置２０の所定階層にマッピングされており、第３ストレージ装置２０の内部ボリュームであるかのように使用される。

なお、本実施例では、物理的な記憶ドライブとして、ハードディスクを例示するが、本発明はこれに限定されない。記憶ドライブとしては、ハードディスク以外に、例えば、半導体メモリドライブ、磁気テープドライブ、光ディスクドライブ、光磁気ディスクドライブ等を用いることができる場合もある。

第２ストレージ装置４０は、第１ストレージ装置３０と同様に、例えば、コントローラ４１０と、ディスクドライブ４２０と、ポート４１１とを備えて構成可能である。第２ストレージ装置４０は、第１ストレージ装置３０と同一の構成を備えてもよいし、異なる構成であってもよい。

図５は、ストレージシステムの論理的な記憶構造に着目した構成説明図である。先に第３ストレージ装置２０の構成から先に説明する。第３ストレージ装置２０の記憶構造は、例えば、物理的記憶階層と論理的記憶階層とに大別することができる。物理的記憶階層は、物理的なディスクであるPDEV（Physical Device）２７１により構成される。PDEVは、ディスクドライブに該当する。

論理的記憶階層は、複数の（例えば２種類の）階層から構成することができる。一つの論理的階層は、VDEV（Virtual Device）２７２から構成可能である。他の一つの論理的階層は、LDEV（Logical Device）２７３から構成することができる。

VDEV２７２は、例えば、４個１組（３Ｄ＋１Ｐ）、８個１組（７Ｄ＋１Ｐ）等のような所定数のPDEV２７１をグループ化して構成することができる。グループに属する各PDEV２７１がそれぞれ提供する記憶領域が集合して一つのRAID記憶領域が形成される。このRAID記憶領域がVDEV２７２となる。

ここで、全てのVDEV２７２がPDEV２７１上に直接設けられるわけではなく、一部のVDEV２７２は、仮想的な中間デバイスとして生成可能である。このような仮想的なVDEV２７２は、外部のストレージ装置３０，４０が有するＬＵ（Logical Unit）をマッピングするための受け皿となる。

LDEV２７３は、VDEV２７２上に、少なくとも一つ以上設けることができる。LDEV２７３は、VDEV２７２を固定長で分割することにより構成することができる。ホスト１０がオープン系ホストの場合、LDEV２７３がＬＵ２７４にマッピングされることにより、ホスト１０は、LDEV２７３を一つの物理的なディスクボリュームとして認識する。オープン系のホスト１０は、LUN（Logical Unit Number ）や論理ブロックアドレスを指定することにより、所望のLDEV２７３にアクセスする。

ＬＵ２７４は、SCSIの論理ユニットとして認識可能なデバイスである。各ＬＵ２７４は、ポート２１１Ａを介してホスト１０に接続される。各ＬＵ２７４には、少なくとも一つ以上のLDEV２７３をそれぞれ関連付けることができる。一つのＬＵ２７４に複数のLDEV２７３を関連付けることにより、ＬＵサイズを仮想的に拡張することもできる。

CMD（Command Device）２７５は、ホスト１０上で稼働するプログラムとストレージ装置のコントローラ（CHA２１０，DKA２２０）との間で、コマンドやステータスを受け渡すために使用される専用のＬＵである。ホスト１０からのコマンドは、CMD２７５に書き込まれる。ストレージ装置のコントローラは、CMD２７５に書き込まれたコマンドに応じた処理を実行し、その実行結果をステータスとしてCMD２７５に書き込む。ホスト１０は、CMD２７５に書き込まれたステータスを読出して確認し、次に実行すべき処理内容をCMD２７５に書き込む。このようにして、ホスト１０は、CMD２７５を介して、ストレージ装置に各種の指示を与えることができる。

第３ストレージ装置２０の外部接続用のイニシエータポート（External Port）２１１Ｂには、通信ネットワークＣＮ３を介して、第１ストレージ装置３０，第２ストレージ装置４０がそれぞれ接続されている。第１ストレージ装置３０は、複数のPDEV３２０と、PDEV３２０の提供する記憶領域上に設定されたLDEV３３０とを備えている。そして、各LDEV３３０は、ＬＵ３４０に関連付けられている。同様に、第２ストレージ装置４０は、複数のPDEV４２０と、LDEV４３０とを備え、LDEV４３０はＬＵ４４０に関連付けられている。

第１ストレージ装置３０の有するLDEV３３０は、ＬＵ３４０を介して、第３ストレージ装置２０のVDEV２７２（「VDEV２」）にマッピングされている。第２ストレージ装置４０の有するLDEV４３０は、ＬＵ４４０を介して、第３ストレージ装置のVDEV２７２（「VDEV３」）にマッピングされている。

このように、第１，第２ストレージ装置３０，４０の有する実ボリューム（LDEV）を、第３ストレージ装置２０の所定の論理階層にマッピングすることにより、第３ストレージ装置２０は、外部に存在するボリューム３３０，４３０をあたかも自己の有するボリュームであるかのようにホスト１０に対して見せかけることができる。なお、第３ストレージ装置２０の外部に存在するボリュームを第３ストレージ装置３０に取り込む方法としては、上記の例に限らない。

次に、図６は、ストレージ管理サーバ６０のハードウェア構成の概略を示すブロック図である。ストレージ管理サーバ６０は、例えば、通信部６１０と、制御部６２０と、メモリ６３０と、ボリュームデータベース６４０とを備えて構成可能である。

通信部６１０は、通信ネットワークＣＮ１を介してデータ通信を行う。制御部６２０は、ストレージ管理サーバ６０の全体制御を行う。メモリ６３０には、例えば、ウェブサーバプログラム６３１と、データ再配置管理プログラム６３２と、データベース管理システム６３３とが格納されている。

ボリュームデータベース６４０には、例えば、ボリューム属性管理テーブルＴ２と、ストレージ階層管理テーブルＴ３と、対応ホスト管理テーブルＴ４と、マイグレーショングループ管理テーブルＴ５と、アクション管理テーブルＴ６とが記憶されている。これら各テーブルの構成例は、さらに後述する。

ウェブサーバプログラム６３１は、制御部６２０に読み込まれて実行されることにより、ストレージ管理サーバ６０上にウェブサーバ機能を実現させる。データ再配置管理プログラム６３２は、制御部６２０に読み込まれることにより、ストレージ管理サーバ６０上にデータ再配置管理部を実現する。データベース管理システム６３３は、ボリュームデータベース６４０を管理する。なお、これらのウェブサーバ機能、データ再配置管理機能、データベース管理機能は、それぞれ並行して実行することができる。

図７は、マッピングテーブルＴ１の構成を示す説明図である。マッピングテーブルＴ１は、第１ストレージ装置３０，第２ストレージ装置４０がそれぞれ有するボリュームを、第３ストレージ装置２０にマッピングさせるために使用される。マッピングテーブルＴ１は、第３ストレージ装置２０の共有メモリ２４０に記憶させることができる。

マッピングテーブルＴ１は、例えば、LUNと、LDEV番号、LDEVの最大スロット数（容量）と、VDEV番号と、VDEVの最大スロット数（容量）と、デバイス種別と、パス情報とを対応づけることにより、構成することができる。パス情報は、第３ストレージ装置２０内部の記憶領域（PDEV２７１）へのパスを示す内部パス情報と、第１ストレージ装置３０または第２ストレージ装置４０の有するボリュームへのパスを示す外部パス情報とに大別することができる。外部パス情報には、例えば、WWN（World Wide Name）とLUNとを含めることができる。

図８は、ボリューム属性管理テーブルＴ２の一例を示す。ボリューム属性管理テーブルＴ２は、ストレージシステムに分散する各ボリュームの属性情報を管理するためのものである。

ボリューム属性管理テーブルＴ２は、例えば、各仮想ボリューム毎に、その仮想ボリュームを特定する論理ＩＤと、その仮想ボリュームに対応づけられる実ボリュームの物理ＩＤと、RAIDレベルと、エミュレーションタイプと、ディスク種別と、記憶容量と、使用状態と、ストレージ装置の機種とを対応づけることにより、構成することができる。

ここで、RAIDレベルとは、例えば、RAID０，RAID１，RAID５等のRAID構成を示す情報である。エミュレーションタイプとは、そのボリュームの構造を示す情報であり、例えば、オープン系ホストに提供されるボリュームと、メインフレーム系ホストに提供されるボリュームとでは、エミュレーションタイプが相違する。使用状態とは、そのボリュームが使用されているか否かを示す情報である。機種とは、そのボリュームの存在するストレージ装置の機種を示す情報である。
また、論理ＩＤとは、前記ボリューム仮想化装置２０がホスト１０に対して提供する論理ボリュームのＩＤであり、物理ＩＤとは、各論理ボリュームに対応する実ボリュームの所在を示すＩＤである。物理ＩＤは、実ボリュームを格納しているストレージ装置の装置番号と、該装置内におけるボリューム番号から構成される。

図９は、ストレージ階層管理テーブルＴ３の一例を示す。ストレージ階層管理テーブルＴ３は、例えば、ストレージ階層番号と、ストレージ階層名称と、そのストレージ階層を定義づける条件式と、自動的に実行させるアクションとを対応づけることにより、構成することができる。アクションは、必須の設定項目ではなく、アクションを対応づけずにストレージ階層を定義することもできる。

ストレージ階層名称には、ユーザ（システム管理者等）が所望の名称を設定することができる。例えば、ストレージ階層名称として、高信頼階層、低コスト階層、高速応答階層、アーカイブ階層等の名称を用いることもできる。条件式には、そのストレージ階層に所属すべきボリュームを抽出するための検索条件が設定される。検索条件は、そのストレージ階層のポリシーに応じて、ユーザにより設定される。

検索条件により、例えば、所定種類のディスクを所定のRAIDレベルで構成したボリュームを検出したり（「RAIDレベル＝RAID１ and ディスク種別＝ＦＣ」）、所定のストレージ装置に存在するボリュームを検出することができる（「機種＝ＳＳ１」）。例えば、高信頼階層（＃１）では、高い信頼性を有するＦＣディスクによりRAID１で冗長化したボリュームが選択される。これにより、高信頼階層を、信頼性の高いボリュームのみから構成することができる。低コスト階層（＃２）では、安価なSATAディスクをRAID５で冗長化したボリュームが選択される。これにより、低コスト階層を、比較的小容量の安価なボリュームのみから構成可能である。高速応答階層（＃３）では、高速応答が可能な機種に存在するディスクをストライピング（RAID０）したボリュームが選択される。これにより、高速応答階層を、Ｉ／Ｏ処理が速く、パリティ演算等の処理を必要としないボリュームのみから構成できる。アーカイブ階層（＃４）では、安価なSATAディスクから構成され、かつ、所定容量未満の容量を有するボリュームが選択される。これにより、アーカイブ階層を、低コストのボリュームから構成することができる。

図９に示すように、ストレージ階層管理テーブルＴ３に設定された条件式に基づいて、ボリューム属性管理テーブルＴ２を検索することにより、各ストレージ階層に所属すべきボリューム群が検出される。ここで、ストレージ階層とボリューム群とは、明示的に直接関連付けられるのではなく、条件式を介して間接的に関連付けられている点に留意すべきである。これにより、ストレージシステムの物理構成が種々変化した場合でも、容易に対応することができる。

図１０は、対応ホスト管理テーブルＴ４の一例を示す説明図である。対応ホスト管理テーブルＴ４は、例えば、仮想ボリュームを識別する論理ＩＤと、その仮想ボリュームにアクセスするホストを特定するための情報（例えば、ドメイン名）と、その仮想ボリュームを利用するアプリケーションプログラムの名称とを対応づけることにより、構成することができる。

図１１は、マイグレーショングループ管理テーブルＴ５の一例を示す説明図である。マイグレーショングループとは、データを再配置する場合の単位であり、本実施例では、相互に関連する複数のボリュームからマイグレーショングループを構成し、グループ単位で一括してデータを再配置できるようにしている。図１０に示した対応ホスト管理テーブルＴ４を検索することにより、相互に関連するボリューム群を抽出することができる。

マイグレーショングループ管理テーブルＴ５は、例えば、グループ番号と、グループ名称と、そのグループに属するボリュームを特定する論理ＩＤと、そのグループが現在所属するストレージ階層の名称とを対応づけることができる。マイグレーショングループの名称は、ユーザが自由に設定することができる。このように、各マイグレーショングループは、例えば、同一のアプリケーションプログラムにより使用されるデータ群を記憶するボリューム、または、同一のファイルシステムを構成するデータ群を記憶するボリュームを、グループ化することによって構成可能である。なお、例えば、マイグレーショングループを新たに設定した直後等のように、データ再配置を行っていない状態では、そのグループの属するストレージ階層名称は設定されない場合がある。

図１２は、アクション管理テーブルＴ６の一例を示す説明図である。アクション管理テーブルＴ６は、ストレージ階層に予め設定されている所定の情報処理、データ操作の具体的内容を定義するものである。アクション管理テーブルＴ６は、例えば、アクションを識別するためのＩＤと、そのアクションの名称と、そのアクションで実行されるべきスクリプト（プログラム）とを対応づけることにより、構成することができる。従って、ストレージ階層管理テーブルＴ３にアクションＩＤが予め設定されている場合、そのアクションＩＤを検索キーとしてアクション管理テーブルＴ６を検索することにより、必要なアクションを実行することができる。

例えば、高信頼階層では、アクションＩＤ「Ａ１」が設定されている。アクションＩＤ「Ａ１」は、ミラーリングを行うもので、ボリュームの複製を生成するスクリプトが関連付けられている。従って、あるマイグレーショングループが高信頼階層に再配置された場合、ボリューム群の複製が生成される。また、アーカイブ階層では、アクションＩＤ「Ａ３」が設定されている。アクションＩＤ「Ａ３」は、データのアーカイブ処理を行うもので、アーカイブ処理に必要な複数のスクリプトが関連付けられている。一つのスクリプトは、アクセス属性をリードオンリーに設定するものであり、他の一つのスクリプトは、ボリューム群の複製を行うものである。なお、アクション管理テーブルＴ６中のＩＤ「Ａ２」は、一度だけの書込みを許可するもので、いわゆるWORM（Write Once Read Meny）として知られている。このアクションＩＤには、アクセス属性をリードオンリーに設定するスクリプトが関連付けられている。

図１３は、データ再配置の全体動作を簡略化して示す説明図である。データ再配置を行う場合、ユーザは、管理クライアント５０を介してストレージ管理サーバ６０にログインし、再配置させるマイグレーショングループ及び配置先のストレージ階層をそれぞれ指定する（Ｓ１）。

ストレージ管理サーバ６０は、指定されたマイグレーショングループを構成する各ボリュームのそれぞれについて、移動先候補のボリュームを選択する（Ｓ２）。詳細はさらに後述するが、移動先候補ボリュームを選択する処理では、移動先として指定されたストレージ階層に所属する全ボリュームのうち、移動元ボリュームのデータをコピー可能なボリュームが一つ選択される。

ストレージ管理サーバ６０による移動先候補ボリュームの選択結果は、例えば、ボリューム対応表Ｔ７のような形態で、ユーザに提示される（Ｓ３）。ボリューム対応表Ｔ７は、例えば、移動元ボリュームの論理ＩＤと、移動先ボリュームの論理ＩＤとを対応づけることにより、構成することができる。

ユーザは、ストレージ管理サーバ６０から提示された再配置案（ボリューム対応表Ｔ７）を、ウェブヴラウザ５１により確認する。ストレージ管理サーバ６０からの提案をそのまま承認する場合は、所定のタイミングを見計らって再配置が実行される（Ｓ５）。ストレージ管理サーバ６０からの提案を修正する場合は、ウェブヴラウザ５１を介して、移動先ボリュームの論理ＩＤを変更する（Ｓ４）。

図１４は、移動先候補ボリュームを選択する処理を示すフローチャートである。この処理は、例えば、ユーザが、再配置対象のマイグレーショングループ及び再配置先（移動先）のストレージ階層を明示的に指定することにより、開始される。

ストレージ管理サーバ６０（データ再配置管理プログラム６３２）は、移動元ボリュームの全てについて、移動先候補ボリュームを選択済か否かを判定する（Ｓ１１）。ここでは、「NO」と判定されて、Ｓ１２に移る。そして、ストレージ管理サーバ６０は、ボリューム属性管理テーブルＴ２を参照することにより、移動先として指定されたストレージ階層に所属するボリューム群から、使用状態が「空き」であり、かつ、移動元ボリュームと必須属性の一致するボリュームを抽出する（Ｓ１２）。

必須属性とは、ボリューム間のデータコピーを行うために必要な属性を意味し、一つでも必須属性が一致しない場合は、データコピーが不能である。本実施例では、必須属性として、例えば、記憶容量とエミュレーションタイプとを挙げることができる。即ち、本実施例では、移動元ボリュームと移動先ボリュームとは、最低限その記憶容量及びエミュレーションタイプが一致していなければならない。

次に、ストレージ管理サーバ６０は、必須属性が一致する空きボリュームとして検出されたボリュームの数を判定する（Ｓ１３）。必須属性の一致する空きボリュームが一つだけ検出された場合は、そのボリュームを移動先候補ボリュームとして選択する（Ｓ１４）。必須属性の一致する空きボリュームが全く発見されなかった場合、データ再配置を行うことはできないので、エラー処理を行い、ユーザに通知する（Ｓ１６）。

必須属性の一致する空きボリュームが複数検出された場合、ストレージ管理サーバ６０は、必須属性以外の他の属性（非必須属性）の一致度が最も高いボリュームを、移動先候補ボリュームとして選択する（Ｓ１５）。例えば、RAIDレベル、ディスク種別、ストレージ装置の機種等のような他の属性項目がより多く一致するボリュームを、移動先候補ボリュームとして選択する。なお、非必須属性の各項目間に優劣を付けて、一致度を算出するようにしてもよい。また、非必須属性の一致度が等しいボリュームが複数存在する場合は、例えば、論理ＩＤの小さいボリュームを選択することができる。

上記の処理は、移動対象のマイグレーショングループを構成する全てのボリュームについて、それぞれ実行される。そして、全ての移動元ボリュームについて、それぞれに対応する移動先候補ボリュームが選択された場合（S11：YES）、ストレージ管理サーバ６０は、ボリューム対応表Ｔ７を生成してユーザに提示する（Ｓ１７）。

ユーザは、ストレージ管理サーバ６０から提示されたボリューム対応表Ｔ７を確認し、承認するか修正するかを決定する。ユーザの承認が得られた場合（S18：YES）、本処理は終了する。ユーザが変更を希望する場合（S18：NO）、ユーザは、ウェブヴラウザ５１を介して、移動先候補ボリュームを手動で再設定する（Ｓ１９）。そして、ユーザにより修正が完了すると、本処理は終了する。

図１５は、再配置実行処理の概要を示すフローチャートである。ストレージ管理サーバ６０（データ再配置管理プログラム６３２）は、ストレージ階層管理テーブルＴ３を参照することにより、移動先として指定されたストレージ階層に対応づけられているアクションを検出する（Ｓ２１）。

次に、ストレージ管理サーバ６０は、全ての移動元ボリュームについて再配置が完了したか否かを判定する（Ｓ２２）。最初の処理では「NO」と判定されて次のステップＳ２３に移る。そして、移動元ボリュームに記憶されているデータを、その移動元ボリュームに対応する移動先ボリュームにコピーし（Ｓ２３）、移動元ボリュームから移動先ボリュームにアクセスパスを切り換える（Ｓ２４）。このパスの切り替えは、図３（ｂ）で示したパスの切り替え同様の処理を行うものである。これにより、ホスト１０は、データ再配置を意識することなく、そのままの設定で所望のデータにアクセスすることができる。

ストレージ管理サーバ６０は、移動元ボリュームから移動先ボリュームへのデータ移行が正常に完了したか否かを判定し（Ｓ２５）、データ移行が正常に完了しなかった場合（S25：NO）、エラー処理を行って本処理を終了する。

データ移行が正常に終了した場合（S25：YES）、移動先のストレージ階層に対応づけられているアクションが存在するか否かをチェックする（Ｓ２７）。移動先のストレージ階層にアクションが設定されている場合（S27：YES）、ストレージ管理サーバ６０は、アクション管理テーブルＴ６を参照し、所定のスクリプトを実行し（Ｓ２８）、Ｓ２２に戻る。移動先のストレージ階層にアクションが設定されていない場合（S27：NO）、何もせずにＳ２２に戻る。

このように、移動対象のマイグレーショングループに属する全てのボリュームについて、それぞれの記憶するデータが移動先ボリュームにコピーされ、アクセスパスが切り換えられる。そして、全ての移動元ボリュームについてデータ移行が完了すると（S22：YES）、本処理は終了する。

図１６は、ボリューム対応表Ｔ７の具体例を示す説明図である。ストレージ管理サーバ６０による移動先候補ボリュームの選定結果は、例えば、図１６に示すように、移動元ボリューム及び移動先ボリュームを上下２段に配置することにより、表示可能である。移動元ボリューム及び移動先ボリュームのそれぞれについて、例えば、その論理ＩＤ、その所属するRAIDグループ番号、RAIDレベル、エミュレーションタイプ、記憶容量等の属性を併せて表示することができる。

ユーザは、図１６の画面を確認することにより、データ再配置を実行させるか否かを判断することができる。移動先ボリュームを個別に変更する場合、ユーザは、モディファイボタンＢ１を操作する。このボタンＢ１を操作すると、図１７に示す個別修正画面に遷移する。

図１７に示す修正画面では、その上部に、移動元ボリューム（ソースボリューム）の論理ＩＤと、移動元ボリュームのエミュレーションタイプ及び記憶容量とを表示させることができる。

画面の中央部には、現在選択されている移動先ボリュームの論理ＩＤやRAIDグループ、RAIDレベル、物理ＩＤ、所属するストレージ装置の番号、実ボリュームの物理ＩＤ等を表示させることができる。

画面の下部には、指定された階層の中で移動元ボリュームと必須属性が一致する全ての候補ボリュームの一覧を表示させることができる。ユーザは、画面下部のボリューム一覧に表示されているボリュームの中からいずれか一つのボリュームを選択することができる。例えば、ストレージ管理サーバ６０による初期選択結果が、特定のRAIDグループに属するボリュームに集中していたり、あるいは、シーケンシャルアクセスされるデータとランダムアクセスされるデータとが同一のRAIDグループに配置されていたりするような場合、そのRAIDグループの応答性が低下する。従って、ユーザは、特定のRAIDグループにデータが集中しないように、移動先候補ボリュームを個別に修正することができる。

本実施例は、上述のように構成されるため、以下の効果を奏する。本実施例では、予め設定された複数のポリシーとボリューム属性情報とに基づいてそれぞれ生成される複数のストレージ階層間で、指定された移動元ボリュームを指定されたストレージ階層に再配置させる構成を採用した。従って、ユーザは、希望のポリシーで自由にストレージ階層を定義し、ストレージ階層間でボリュームを再配置させることができ、ストレージシステムの使い勝手が向上する。特に、複数のストレージ装置が混在する複雑なストレージシステムにおいて、ユーザは、各ボリュームの特性等を詳しく考慮することなく、自己の設定したポリシーに従い、直感的な操作でデータを再配置することができる。

本実施例では、複数のボリュームからなるグループ単位で、データを再配置することができる。従って、上記のストレージ階層間でデータ再配置が可能な構成と相俟って、より一層ユーザの使い勝手を向上させることができる。

本実施例では、移動先のストレージ階層に予め所定のアクションを対応づけることができ、データ再配置の完了後に所定のアクションを実行させることができる。これにより、データ再配置に伴う付加的なサービスを自動的に実行することができ、ユーザの操作忘れ等を防止して、使い勝手を改善することができる。

本実施例では、必須属性の一致を前提条件とし、必須属性以外の属性の一致度が高いボリュームを移動先候補ボリュームとして選択する。従って、データ再配置に適切なボリュームを選択することができる。

図１８に基づいて本発明の第２実施例を説明する。本実施例を含む以下の実施例は、第１実施例の変形例に相当する。本実施例の特徴は、第１実施例で述べたボリューム仮想化装置２０とストレージ管理サーバ６０とを、一つのボリューム仮想化装置７０に集約した点にある。

本実施例のボリューム仮想化装置７０は、例えば、ボリューム仮想化部７１と、データ再配置部７２と、ボリュームデータベース７３とを備える。ボリューム仮想化部７１は、第１実施例のボリューム仮想化装置２０と同様の機能を実現する。データ再配置部７２は、第１実施例におけるストレージ管理サーバ６０のデータ再配置管理プログラム６３２と同様の機能を実現する。ボリュームデータベース７３は、第１実施例のボリュームデータベース６４０と同様の各種テーブルを記憶する。

図１９に基づいて、本発明の第３実施例を説明する。本実施例の特徴は、ボリューム属性管理テーブルＴ２に、動的な属性を追加し、動的な属性を考慮してストレージ階層を定義可能とした点にある。

本実施例のボリューム属性管理テーブルＴ２には、その右端に示すように、データ入出力の応答時間（I/O応答時間）も管理されている。このI/O応答時間は、例えば、定期的または不定期に、ストレージ管理サーバ６０が各ストレージ装置２０，３０，４０から収集して更新することができる。なお、図１９中では、紙面の都合上、ストレージ装置の機種に代えてI/O応答時間を表示しているが、ストレージ装置の機種もボリューム属性の一つとして管理することができる。ここで、I/O応答時間は、テストI/Oを発行し、このI/Oの発行から応答までの時間を計測したものである。またこのI/O応答時間は、図９に示す条件式に含めることができる。

このように、本実施例では、RAIDレベルや記憶容量等の静的な属性に加えて、動的な属性も併せて管理するため、静的な属性と動的な属性の両方を考慮して、ストレージ階層を定義することができる。例えば、より高速な応答を求めるストレージ階層では、高速なディスク（ＦＣディスク）上に設定され、最新のI/O応答時間が最も短いストレージ装置に存在するボリュームから構成することができる。

図２０，図２１に基づいて、本発明の第４実施例を説明する。本実施例の特徴は、ストレージシステムの構成変更（ストレージ装置の廃棄）に応じて、その構成変更に係るストレージ装置に記憶されているデータを、空いている適切なボリュームに自動的に再配置させる点にある。

図２０は、本実施例に係るストレージシステムの全体概要を示す説明図である。このストレージシステムでは、第１実施例の構成に加えて、第４ストレージ装置８０が新たに追加されている。第４ストレージ装置８０は、例えば、ストレージ装置３０，４０のように構成することができる。なお、第４ストレージ装置８０は、説明の便宜上追加されるもので、本発明の構成に必須の要素ではない。本発明は、複数のストレージ装置を備えていれば足りる。

本実施例では、一例として、第１ストレージ装置３０を廃棄する場合を説明する。例えば、第１ストレージ装置３０の耐用期限が切れたような場合に、第１ストレージ装置３０は、廃棄が予定される。廃棄予定のストレージ装置３０に記憶されているデータ群を、他のストレージ装置４０，８０（あるいは、第３ストレージ装置としてのボリューム仮想化装置２０。以下同様）に移行させる場合を、図２１の説明図に基づいて説明する。

図２１に示すように、ユーザは、まず条件式を与え、ボリューム属性管理テーブルＴ２を検索させることにより、廃棄対象のストレージ装置３０上にある「使用中」状態のボリューム群を検出させ、これらのボリュームからなるマイグレーショングループをユーザが定義する。図２１において、廃棄対象のストレージ装置３０には、「装置番号１」が設定されているものとする。図中
では、廃棄対象のストレージ装置３０に存在する「使用中」状態のボリュームに、「退避データボリューム」というマイグレーショングループ名称を与えている。

次に、「装置番号が廃棄対象ストレージ装置の装置番号と異なる（装置番号≠１）」という条件によってストレージ階層を定義する。図中では、廃棄対象のストレージ装置３０以外の他のストレージ装置４０，８０により構成されるストレージ階層に、「移行先階層」というストレージ階層名称を与えている。そして、ユーザは、「移行先階層」のストレージ階層を移動先として、前記マイグレーショングループ「退避データボリューム」の再配置を指示する。

以下、第１実施例で述べたと同様に、データ再配置管理プログラム６３２は、移動元として指定されたマイグレーショングループ「退避データボリューム」中に含まれる個々のボリュームについて、移動先として指定されたストレージ階層「移行先階層」から適切なボリュームをそれぞれ選択し、ユーザに提示する。

上述のように、ボリューム属性の「使用状態」が「空き」で、かつ、必須属性が一致するボリューム、または、「使用状態」が「空き」で、かつ、必須属性が一致し、さらに非必須属性の一致度も高いボリュームが、適切な移行先候補ボリュームとして選択され、ユーザに提示される。そして、ユーザが、データ再配置管理プログラム６３２によって提案されたボリュームの対応付けを承認すれば、再配置処理が実行され、廃棄対象ストレージ装置３０上にある全てのデータは、他のストレージ装置４０，８０中の適切なボリュームに再配置される。

また、ストレージ装置の入換えを行う場合や、性能バランスを配慮して既存データの一部を新規に導入したストレージ装置に移行する場合には、「装置番号＝新規に導入したストレージ装置の装置番号」という条件でストレージ階層「新規追加階層」を定義し、このストレージ階層を移動先に指定してデータ再配置を行えばよい。このように、本実施例からも明らかなように、本発明では、ストレージシステムの構成やポリシーに応じて、ユーザがストレージ階層を自在に定義することができ、関連するボリュームをマイグレーショングループとして一括指定し、グループ単位でデータ再配置を行うことができる。

なお、本発明は、上述した実施の形態に限定されない。当業者であれば、本発明の範囲内で、種々の追加や変更等を行うことができる。例えば、マイグレーショングループは、必ずしも相互に関連するボリュームから構成する必要はなく、任意のボリュームを移動対象としてグループ化することもできる。また、第１ストレージ装置の階層、第２ストレージ装置の階層、第１ストレージ装置及び第２ストレージ装置の階層等のように、ストレージ装置を単位としてストレージ階層を設定することもできる。

図２２、図２３、図２４に基いて、本発明の第５実施例を説明する。本実施例の特徴は、配置先として指定されたストレージ階層中に、あるボリュームの移動先として適切な空きボリュームがない場合に、移動先となる条件を満たしたボリュームを自動的に作成し、作成したボリュームを移動先候補としてボリュームの再配置を行う点にある。

図２２は、本実施例における、移動先候補ボリュームを選択する処理を示すフローチャートである。図２２中の多くのステップは、第１実施例の図１４で示した移動先候補選択処理におけるステップと共通である。しかし、ストレージ管理サーバ６０が、必須属性が一致する空きボリュームとして検出されたボリュームの数を判定するステップ（Ｓ１３）を実行した結果、そのような空きボリュームが全く発見されなかった場合の処理が異なる。この場合、本実施例では、ボリューム作成処理（Ｓ３１）を行い、再配置先のストレージ階層に属しており、かつ移動元ボリュームと必須属性が一致するボリュームの作成を試みる。

次に、ストレージ管理サーバ６０は、必須属性が一致するボリュームの作成が成功したかどうかを判定し（Ｓ３２）、成功した場合、作成したボリュームを移動先候補ボリュームとして選択する（Ｓ３３）。また、作成したボリュームをボリューム属性管理テーブルＴ２に登録する（Ｓ３４）。作成できなかった場合、データ再配置を行うことはできないので、エラー処理を行い、ユーザに通知する（Ｓ１６）。

図２３は、図２２におけるボリューム作成処理（Ｓ３１）の詳細を示すフローチャートである。
図２３に示すボリューム作成処理では、ストレージ管理サーバ６０は、まずボリューム仮想化装置２０およびボリューム仮想化装置２０に接続されたストレージ装置群の中から、１台のストレージ装置を選択する（Ｓ４１）。次に、選択したストレージ装置が、作成すべきボリュームに関するストレージ装置要件を満たすかどうかを判定する（Ｓ４２）。

ここで、ストレージ装置要件とは、配置先として指定されたストレージ階層を定義する諸条件のうち、ストレージ装置の機種名、装置番号等、ストレージ装置の持つ属性に関わる条件（もしあれば）を指す。選択したストレージ装置がストレージ装置要件を満たす場合、ストレージ管理サーバ６０は、選択したストレージ装置内にあるすべてのVDEVのうち、VDEV要件を満たすものの集合Ｓを求める（Ｓ４３）。次に、集合Ｓの中から１個のVDEVを選択する（Ｓ４４）。

ここで、VDEV要件とは、配置先として指定されたストレージ階層を定義する諸条件のうち、ディスク種別、RAIDレベル等、VDEVの持つ属性に関わる条件（もしあれば）、および、移動元ボリュームのエミュレーションタイプを指す。

次に、ストレージ管理サーバ６０は、選択したVDEV内にある未割当ての空き容量が、移動元ボリュームの容量（Ｑ１）と同等以上の大きさであるかどうかを判定する（Ｓ４５）。空き容量が移動元ボリュームの容量と同等以上である場合、そのVDEV内部に移動元ボリュームと同一の容量を持つボリューム（LDEV）を新たに作成し（Ｓ４６）、呼び出し元に対してボリューム作成の成功を報告する。

ステップＳ４５において、選択したVDEV内部に移動元ボリュームの容量と同等以上の空き容量がないと判定された場合、そのVDEV内部に移動先候補となるボリュームを作成することはできないので、ストレージ管理サーバ６０は、集合Ｓ内に未調査の他のVDEVがないかどうかを判定する（Ｓ４７）。

他にもVDEVがある場合、次のVDEVを選択し（Ｓ４８）、ステップＳ４４に戻る。集合Ｓ内にもはや未調査のVDEVがない場合、および、ステップＳ４２において、選択したストレージ装置はストレージ装置要件を満たさないと判定された場合には、そのストレージ装置内部に移動先候補となるボリュームを作成することはできないので、ストレージ管理サーバ６０は、他に未調査のストレージ装置がないかどうかを判定する（Ｓ４９）。他にもストレージ装置がある場合、次のストレージ装置を選択し（Ｓ５０）、ステップＳ４２に戻る。もはや未調査のストレージ装置がない場合には、呼び出し元に対してボリューム作成の失敗を報告する。

このように、本実施例では、データ再配置の指示時点で存在していた空きボリューム群の中から移動先として適切なボリュームを選択するだけでなく、適切な空きボリュームが存在しなかった場合、未割当てのストレージ容量の中から移動先として適切なボリュームを作成することができるので、より柔軟なデータ再配置処理が可能となる。

なお、再配置処理の終了後、移動前のデータを保持していた移動元ボリュームは、ボリューム管理テーブルにおける使用状態を「空き」に変更して再利用可能な状態に戻してもよく、ボリューム自体を削除してストレージ装置の空き容量の一部に戻す構成としてもよい。

図２４は、図２２におけるボリューム作成処理（Ｓ３１）の他の例を示すフローチャートである。これは、移動先のボリューム（ＬＤＥＶ）を複数のＶＤＥＶの空き領域から作成することを可能にしたものである。

図２４に示すボリューム作成処理では、ストレージ管理サーバ６０は、まずボリューム仮想化装置２０およびボリューム仮想化装置２０に接続されたストレージ装置群の中から、１台のストレージ装置を選択する（Ｓ４１）。次に、選択したストレージ装置が、作成すべきボリュームに関するストレージ装置要件を満たすかどうかを判定する（Ｓ４２）。

ここで、VDEV要件とは、配置先として指定されたストレージ階層を定義する諸条件のうち、ディスク種別、RAIDレベル等、VDEVの持つ属性に関わる条件（もしあれば）、および、移動元ボリュームのエミュレーションタイプを指す。次に、ストレージ管理サーバ６０は、選択したVDEV内にある未割当ての空き容量が、移動元ボリュームの容量（Ｑ１）と同等以上の大きさであるかどうかを判定する（Ｓ４５）。空き容量が移動元ボリュームの容量と同等以上である場合、そのVDEV内部に移動元ボリュームと同一の容量を持つボリューム（LDEV）を新たに作成し（Ｓ４６）、呼び出し元に対してボリューム作成の成功を報告する。

ステップＳ４５で、移動元ボリュームの容量と同等以上の空き容量がない場合、そのVDEV内部の空き容量（Ｑ２）を確保し（Ｓ８１）、移動元ボリュームの容量（Ｑ１）と確保した空き容量（Ｑ２）の差分容量（Ｑ３）を求める（Ｓ８２）。この時点では、まだ移動元ボリュームと同等以上の容量が確保されていないので、ストレージ管理サーバ６０は、集合Ｓ内に他のVDEVがあるかどうかを判定し（Ｓ８３）、あれば次にそのVDEVを選択して、そのVDEV内にある未割当の空き容量が、差分容量（Ｑ３）と同等以上の大きさであるかどうかを判断する（Ｓ８４）。空き容量が差分容量（Ｑ３）と同等以上の大きさである場合、そのVDEV内の空き容量と、これまでのVDEVから確保してきた空き容量を用いて移動元ボリュームと同一の容量を持つボリューム（LDEV）を新たに作成し（Ｓ８５）、呼び出し元に対してボリューム作成の成功を報告する。

一方、ステップＳ８４でVDEVの空き容量が差分容量Ｑ３と同等以上でない場合、当該VDEVの空き容量（Ｑ２）を確保し（Ｓ８６）、残りの差分容量（Ｑ３）を求め（Ｓ８７）、ステップＳ８３へ戻る。

ステップＳ８３で、集合Ｓ内に他のVDEVがない場合、そのストレージ装置内では必要な空き容量を確保できないので、ストレージ管理サーバ６０は、これまでに確保した空き容量を解放した後（Ｓ８８）、他に未調査のストレージ装置がないかどうかを判定する（Ｓ４９）。ステップＳ４２において、選択したストレージ装置はストレージ装置要件を満たさないと判定された場合にも、同様にステップＳ４９に移る。ステップＳ４９において、他にもストレージ装置がある場合、次のストレージ装置を選択し（Ｓ５０）、ステップＳ４２に戻る。もはや未調査のストレージ装置がない場合には、呼び出し元に対してボリューム作成の失敗を報告する。

このように一つのVDEVから移動元のボリュームの容量を確保できない場合、空き容量を有する複数のVDEVから移動先候補となるボリューム（LDEV）を生成する。
なお、図２３、図２４のステップ４１に、ストレージ装置を選択するようにしているが、ボリューム仮想化装置が、接続されているストレージ装置内のすべてのVDEVを一括管理することにより、ステップ４１のストレージ装置の選択を省略し、ボリューム仮想化装置によって管理されたVDEVを順に選択する構成としても良い。

図２５、図２６、図２７、図２８、図２９、図３０に基いて、本発明の第６実施例を説明する。本実施例の特徴は、再配置先として指定されたストレージ階層に対応付けられたアクション中にレプリカの作成が含まれている場合に、再配置先を含む任意のストレージ階層をレプリカ作成先として指定できる点にある。

図２５は、本実施例における、ストレージ階層とアクションとの対応付けを示す図である。本実施例では、スクリプト中でレプリカの作成を指示する場合、レプリカの作成先となるストレージ階層を、その名称によって明示的に指定する。図２５に示すとおり、レプリカの作成先となるストレージ階層は、再配置先として指定されたストレージ階層自身と同一でもよく、また異なっていてもよい。

図２６は、本実施例におけるボリューム属性管理テーブルＴ２の構成を示す図である。本実施例のボリューム属性管理テーブルでは、ボリュームの使用状態は「使用中」「空き」の２状態ではなく、「ソース」「レプリカ」「リザーブ」「空き」の４状態をとる。また、新たな属性として「ペア」が追加されている。

使用状態「ソース」は、そのボリュームがホストから参照されるユーザデータを保持していることを示す。使用状態「レプリカ」は、そのボリュームがユーザデータの複製であるレプリカを保持していることを示す。使用状態「リザーブ」は、そのボリュームが将来レプリカとして使うために予約されていることを示す。使用状態「空き」は、そのボリュームが以上の３状態のいずれでもなく、データの移動先やコピー先として新たに割当て可能であることを示す。

ボリュームの使用状態が「ソース」「レプリカ」「リザーブ」のいずれかである場合、そのボリュームの属性「ペア」は値を持つことができる。ボリュームの使用状態が「ソース」で、かつそのボリュームがレプリカを持っている場合、属性「ペア」の値は、対となるレプリカボリュームの論理ＩＤを示す。（ただし、そのボリュームがレプリカを持たない場合、属性「ペア」の値は空となる。）ボリュームの使用状態が「レプリカ」の場合、属性「ペア」の値は、対となるソースボリュームの論理ＩＤとなる。ボリュームの使用状態が「リザーブ」の場合、属性「ペア」には、そのボリュームと将来対となるソースボリュームの論理ＩＤが設定される。

図２７は、本実施例におけるデータ再配置処理の概略を示すフローチャートである。本実施例のデータ再配置処理では、マイグレーショングループの所定階層への再配置をユーザが指示し（Ｓ１）、移動先候補選択処理（Ｓ２）、ボリューム対応表の提示（Ｓ３）、移動先候補の修正（Ｓ４）を行った後、再配置実行処理（Ｓ５）を行う前に、レプリカボリュームリザーブ処理（Ｓ６）を実行する。

図２８は、レプリカボリュームリザーブ処理（Ｓ６）の処理内容を示すフローチャートである。本実施例のレプリカボリュームリザーブ処理において、ストレージ管理サーバ６０は、まずストレージ階層管理テーブルＴ３およびアクション管理テーブルＴ６を参照し、再配置先として指定されたストレージ階層に対応付けられたアクションを得る（Ｓ６１）。

次に、取得したアクション中で、レプリカ作成が指示されているかどうかを判定する（Ｓ６２）。レプリカ作成が指示されていない場合、または再配置先ストレージ階層にアクションが対応付けられていない場合は、レプリカボリュームのリザーブは不要であるため、処理を終了する。

アクション中でレプリカ作成が指示されている場合、ストレージ管理サーバ６０は、移動元の全ボリュームについて既にレプリカボリュームがリザーブ済みであるかどうかを判定する（Ｓ６３）。

最初はリザーブ済みではないため次のステップに進み、１個の移動元ボリュームに対応して１個のレプリカボリュームを選択する（Ｓ６４）。ここで、レプリカボリュームとして選択できるのは、レプリカ作成先として指定されたストレージ階層に属しており、使用状態が「空き」で、移動先候補として選択されておらず、必須属性が移動元ボリュームと一致するボリュームである。

次に、ストレージ管理サーバ６０は、そのようなボリュームが選択できたかどうかを判定する（Ｓ６５）。選択できなかった場合、レプリカ作成に必要なボリュームが確保できなかったことになるため、エラー処理を行い（Ｓ６７）、ユーザに通知する。なお、ここで図２２のＳ３１からＳ３４の処理を実行してレプリカ作成に必要なボリュームを作成するようにしてもよい。

選択できた場合には、そのボリュームをリザーブし（Ｓ６６）、ステップＳ６３に戻り、移動元の全ボリュームについてレプリカボリュームのリザーブが済むまで同様の処理を繰り返す。ここで、あるボリュームをリザーブするとは、ボリューム属性管理テーブルＴ２において、そのボリュームの使用状態を「リザーブ」に変更し、かつそのボリュームの属性「ペア」に、対応する移動元ボリュームの論理IDを設定することである。

図２９は、本実施例における、アクションスクリプト実行処理の詳細を示すフローチャートである。この処理は、図１５に示す再配置実行処理のステップＳ２８に相当し、１個の移動元ボリュームの記憶内容を対応する移動先ボリュームにコピーし、そのアクセスパス（論理ID）を切り替えた後に、移動先ボリュームを対象として、再配置先ストレージ階層に対応付けられたアクションを実行する処理である。

図２９に示すアクションスクリプト実行処理において、ストレージ管理サーバ６０は、まず対象となる移動先ボリュームに関して、未実行のアクションがあるかどうかを判定する（Ｓ７１）。未実行のアクションがある場合、１個の未実行アクションを取り出し（Ｓ７２）、その種別を判別する（Ｓ７３）。

アクション種別がレプリカ作成であった場合、ストレージ管理サーバ６０は、ボリューム管理テーブルＴ２を参照して、移動先ボリュームに対応してリザーブされているリザーブボリュームを取得する（Ｓ７４）。ここで、移動先ボリュームに対応してリザーブされているリザーブボリュームとは、属性「ペア」の値として移動先ボリュームの論理IDを保持しているボリュームのことである。

次に、ストレージ管理サーバ６０は、ボリューム仮想化装置２０に対して、移動先ボリュームをプライマリ、リザーブボリュームをセカンダリとするペア関係を設定する（Ｓ７５）。同時に、ボリューム属性管理テーブルＴ２上において、移動先ボリュームの属性「ペア」に対応するリザーブボリュームの論理IDを設定し、またリザーブボリュームの使用状態を「レプリカ」に変更する。

次に、ストレージ管理サーバ６０は、ボリューム仮想化装置２０に対して、ステップＳ７５でペア関係を設定したボリューム間の同期化を指示する（Ｓ７６）。これにより、移動先ボリューム（プライマリ）からリザーブボリューム（セカンダリ）へデータのコピーが行われ、両者の内容は同一となる。また、これ以降、プライマリボリュームの内容が書き換えられると、書き換えられた部分のデータがセカンダリボリュームにコピーされ、両者の内容は常に同一に保たれる。

以上の処理を行った後、ストレージ管理サーバ６０は、ステップＳ７１に戻って再び未実行アクションの有無を判定する。また、ステップＳ７３においてアクション種別がレプリカ作成以外と判定された場合、アクション種別に対応した所定の処理を実行し（Ｓ７７）、同じくステップＳ７１に戻る。
ステップＳ７１において、もはや未実行のアクションはないと判断されると、ストレージ管理サーバ６０はアクションスクリプト実行処理を終了する。

図３０は、本実施例のデータ再配置処理の過程の各段階における、ボリューム属性管理テーブルＴ２の状態の一例を示す図である。図３０(a)は初期状態を示しており、必須属性（容量およびエミュレーションタイプ）が一致する３個のボリュームが登録されている。このうち、論理ID「001」のボリュームはユーザデータを保持しており、論理ID「006」および「007」のボリュームは空き状態である。この状態で、論理ID「001」のボリュームを移動元、論理ID「006」のボリュームを移動先とし、かつレプリカ作成を伴うデータ再配置が指示されたものとする。

図３０(b)は、レプリカボリュームリザーブ処理（Ｓ６）において、論理ID「007」のボリュームがレプリカ用のリザーブボリュームとして選択された状態を示している。ボリューム「007」の使用状態は「リザーブ」となり、その属性「ペア」には移動元ボリュームの論理IDである「001」が設定される。

図３０(c)は、データ再配置処理終了後の状態を示している。移動元ボリュームから移動先ボリュームにデータがコピーされた後、両者のアクセスパス（論理ID）の入れ替えが行われ、この時点では移動先ボリュームの論理IDが「001」となっている。論理ID「007」のボリュームはそのレプリカを保持しており、ソースとレプリカの両ボリュームは互いに属性「ペア」で参照しあっている。

このように、本実施例では、ストレージ階層に対応付けられたアクションの中で、任意のストレージ階層をレプリカ作成先として指定しておき、データの再配置処理が行われた場合に、再配置処理の一環として、他のストレージ階層（または再配置先と同一のストレージ階層）内に、移動したデータのレプリカを自動的に作成することができる。これにより、例えば高信頼階層の定義の一部として低コスト階層へのレプリカ作成を記述するなど、柔軟で有用性の高いストレージ階層定義が可能となる。

本発明の実施形態の概念を示す説明図である。ストレージシステムの全体概要を示すブロック図である。ストレージシステムに分散するボリュームを仮想化して管理する様子を模試的に示す説明図である。ストレージシステムのハードウェア構成を示すブロック図である。ストレージシステムの記憶構造を示す説明図である。ストレージ管理サーバの構成を示すブロック図である。マッピングテーブルの構成を示す説明図である。ボリューム属性管理テーブルの構成を示す説明図である。ストレージ階層管理テーブルの構成を示す説明図である。対応ホスト管理テーブルの構成を示す説明図である。マイグレーショングループ管理テーブルの構成を示す説明図である。アクション管理テーブルの構成を示す説明図である。データ再配置の全体動作の概要を示す説明図である。移動先候補選択処理を示すフローチャートである。再配置実行処理を示すフローチャートである。データ再配置の計画案を提示する画面例を示す説明図である。提示された計画を修正する画面例を示す説明図である。本発明の第２実施例に係るストレージシステムの全体構成を簡略化して示すブロック図である。本発明の第３実施例に係るストレージシステムで使用されるボリューム属性管理テーブルの構成を示す説明図である。本発明の第４実施例に係るストレージシステムの全体概要を示すブロック図である。マイグレーショングループ管理テーブルとストレージ階層管理テーブルとの関係を模式的に示す説明図である。本発明の第５実施例に係る移動先候補選択処理を示すフローチャートである。本発明の第５実施例に係るボリューム作成処理を示すフローチャートである。本発明の第５実施例に係るボリューム作成処理を示す他のフローチャートである。本発明の第６実施例に係るストレージ階層管理テーブルとアクション管理テーブルとの関係を模式的に示す説明図である。本発明の第６実施例に係るボリューム属性管理テーブルの構成を示す説明図である。本発明の第６実施例に係るデータ再配置処理を示すフローチャートである。本発明の第６実施例に係るレプリカボリュームリザーブ処理を示すフローチャートである。本発明の第６実施例に係るアクションスクリプト実行処理を示すフローチャートである。本発明の第６実施例に係るボリューム属性管理テーブルの状態の変遷の例を模式的に示す図である。

符号の説明

１〜３…ストレージ階層、１０…ホスト、１１…アプリケーションプログラム、１２…ホストバスアダプタ、２０…ストレージ装置（ボリューム仮想化装置）、３０，４０，８０…ストレージ装置、５０…管理クライアント、５１…ウェブヴラウザ、６０…ストレージ管理サーバ、７０…ボリューム仮想化装置、７１…ボリューム仮想化部、７２…データ再配置部、７３…ボリュームデータベース、２１０…チャネルアダプタ、２１１…通信ポート、２２０…ディスクアダプタ、２３０…キャッシュメモリ、２４０…共有メモリ、２５０，２６０…接続制御部、２７０…記憶部、２７１…ディスクドライブ（PDEV）、２７２…仮想デバイス（VDEV）、２７３…論理ボリューム（LDEV）、２７４…ＬＵ、２７５…コマンドデバイス（CMD）、３１０，４１０…コントローラ、３１１，４１１…通信ポート３２０，４２０…ディスクドライブ、３３０，４３０…論理ボリューム、６１０…通信部、６２０…制御部、６３０…メモリ、６３１…ウェブサーバプログラム、６３２…データ再配置管理プログラム（データ再配置管理部）、６３３…データベース管理システム、６４０…ボリュームデータベース、ＣＮ…通信ネットワーク、Ｔ１…マッピングテーブル、Ｔ２…ボリューム属性管理テーブル、Ｔ３…ストレージ階層管理テーブル、Ｔ４…対応ホスト管理テーブル、Ｔ５…マイグレーショングループ管理テーブル、Ｔ６…アクション管理テーブル、Ｔ７…ボリューム対応表

Claims

各々がコントローラと当該コントローラに接続される複数のディスクドライブから構成される物理的なボリュームを有する、複数のストレージ装置と、
前記複数のストレージ装置と接続され、物理的なボリュームと仮想的なボリュームとの間の対応関係を管理し、計算機からの当該仮想的なボリュームへのアクセスを受け付ける仮想化部と、
複数のストレージ階層と各ストレージ階層に属する一以上の仮想的なボリュームとの対応関係を管理する管理部とを有し、
前記仮想的なボリュームは前記計算機からアクセス先として認識されるボリュームであり、
前記仮想化部は一の物理的なボリュームを複数の仮想的なボリュームと対応付けており、
前記管理部は、前記仮想的なボリューム毎に当該仮想的なボリュームの属性情報を管理し、当該仮想的なボリュームの属性情報に基づいて、当該仮想的なボリュームが属するストレージ階層を作成し、
前記管理部は更に、ストレージ階層と所定の処理とを関連付けて管理し、
前記管理部が、各々異なる仮想的なボリュームを示す複数の識別情報から選択された一の移動元となる仮想的なボリュームを示す識別情報と、移動先となるストレージ階層を指定するための情報とを受信すると、
前記管理部の制御によって、指定された前記移動先となるストレージ階層に対応付けられた仮想的なボリュームの中から移動先の仮想的なボリュームが選択され、
前記移動元の仮想的なボリュームのデータが、当該移動元の仮想的なボリュームに対応付けられた物理的なボリューム内の記憶領域から前記移動先の仮想的なボリュームに対応付けられた物理的なボリューム内の記憶領域へコピーされ、
前記仮想化部は、前記移動元の仮想的なボリュームの識別情報を、当該移動元の仮想的なボリュームに代えて前記移動先の仮想的なボリュームに割り当て、
データのコピー後に、前記管理部は前記移動先となるストレージ階層に対応付けられた前記所定の処理を実行することを特徴とするストレージシステム。
請求項１記載のストレージシステムであって、
前記管理部は、複数の仮想的なボリュームから構成されるマイグレーショングループを管理しており、前記管理部が移動元の仮想的なボリュームを指定するための情報として当該マイグレーショングループを指定するための情報を受信した場合に、
前記管理部の制御によって、指定された前記マイグレーショングループに属する複数の仮想的なボリューム各々について、指定された前記移動先となるストレージ階層に対応付けられた仮想的なボリュームの中から移動先の仮想的なボリュームが選択され、
前記マイグレーショングループに属する複数の仮想的なボリューム各々のデータが、当該仮想的なボリュームに対応付けられた物理的なボリューム内の記憶領域から当該各仮想的なボリュームの移動先として選択された移動先の仮想的なボリュームに対応付けられた物理的なボリューム内の記憶領域へコピーされ、
前記仮想化部は、前記マイグレーショングループに属する複数の仮想的なボリューム各々の識別情報を、当該各仮想的なボリュームの移動先として選択された前記移動先の仮想的なボリュームに割り当てることを特徴とするストレージシステム。
請求項２記載のストレージシステムであって、
前記管理部は、複数の仮想的なボリュームの中から相互に所定の関連性のある仮想的なボリュームを複数特定し、特定された複数の仮想的なボリュームを有する前記マイグレーショングループを作成することを特徴とするストレージシステム。
請求項２記載のストレージシステムであって、前記マイグレーショングループには、同じアプリケーションによって使用されるデータを格納している複数の仮想的なボリュームが含まれることを特徴とするストレージシステム。
請求項１記載のストレージシステムであって、前記所定の処理とは、仮想的なボリュームの属性をRead Only属性に変更する処理、若しくは仮想的なボリュームの複製を生成する処理であることを特徴とするストレージシステム。
各々がコントローラと当該コントローラに接続される複数のディスクドライブから構成される物理的なボリュームを有する複数のストレージ装置と、
前記複数のストレージ装置と接続され、物理的なボリュームと仮想的なボリュームとの間の対応関係を管理し、計算機からの当該仮想的なボリュームへのアクセスを受け付ける仮想化部と、
データの移動を管理する管理部とを有するストレージシステムにおけるデータの移動方法であって、
前記仮想的なボリュームは、前記計算機からアクセス先として認識されるボリュームであって、
前記仮想化部は、一の物理的なボリュームを複数の仮想的なボリュームと対応付けており、
前記管理部は、前記仮想的なボリューム毎に当該仮想的なボリュームの属性情報を管理し、当該仮想的なボリュームの属性情報に基づいて、当該仮想的なボリュームが属するストレージ階層を作成し、
前記管理部は更に、ストレージ階層と所定の処理とを関連付けて管理し、
前記管理部が、各々異なる仮想的なボリュームを示す複数の識別情報から選択された一の移動元となる仮想的なボリュームを示す識別情報と、移動先となるストレージ階層を指定するための情報とを受信すると、
前記管理部の制御によって、指定された前記移動先となるストレージ階層に対応付けられた仮想的なボリュームの中から移動先の仮想的なボリュームが選択され、
前記移動元の仮想的なボリュームのデータが、当該移動元の仮想的なボリュームに対応付けられた物理的なボリューム内の記憶領域から前記移動先の仮想的なボリュームに対応付けられた物理的なボリューム内の記憶領域へコピーされ、
前記仮想化部は、前記移動元の仮想的なボリュームの識別情報を、当該移動元の仮想的なボリュームに代えて前記移動先の仮想的なボリュームに割り当て、
データのコピー後に、前記管理部は前記移動先となるストレージ階層に対応付けられた前記所定の処理を実行することを特徴とするデータの移動方法。
請求項６記載のデータの移動方法であって、
前記管理部は、複数の仮想的なボリュームから構成されるマイグレーショングループを管理し、
前記管理部が移動元の仮想的なボリュームを指定するための情報として当該マイグレーショングループを指定するための情報を受信した場合に、
前記管理部の制御によって、指定された前記マイグレーショングループに属する複数の仮想的なボリューム各々について、指定された前記移動先となるストレージ階層に対応付けられた仮想的なボリュームの中から移動先の仮想的なボリュームが選択され、
前記マイグレーショングループに属する複数の仮想的なボリューム各々のデータが、当該仮想的なボリュームに対応付けられた物理的なボリューム内の記憶領域から当該各仮想的なボリュームの移動先として選択された移動先の仮想的なボリュームに対応付けられた物理的なボリューム内の記憶領域にコピーされ、
前記仮想化部は、前記マイグレーショングループに属する複数の仮想的なボリューム各々の識別情報を、当該各仮想的なボリュームの移動先として選択された前記移動先の仮想的なボリュームに割り当てることを特徴とするデータの移動方法。
請求項７記載のデータの移動方法であって、
前記管理部は、複数の仮想的なボリュームの中から相互に所定の関連性のある仮想的なボリュームを複数特定し、特定された複数の仮想的なボリュームを有する前記マイグレーショングループを作成することを特徴とするデータの移動方法。
請求項７記載のデータの移動方法であって、
前記管理部は、同じアプリケーションによって使用されるデータを格納している複数の仮想的なボリュームを用いて前記マイグレーショングループを作成することを特徴とするデータの移動方法。
請求項６記載のデータの移動方法であって、前記所定の処理とは、仮想的なボリュームの属性をRead Only属性に変更する処理、若しくは仮想的なボリュームの複製を生成する処理であることを特徴とするデータの移動方法。