JP2010049634A - ストレージシステム及びストレージシステムにおけるデータ移行方法 - Google Patents

Abstract

【課題】データマイグレーションにおいて、何らかの理由により移行先ボリュームが利用できない場合であっても、移行先要件に基づいて他のボリュームを移行先として利用することである。
【解決手段】本発明は、ホストコンピュータに対してデータストレージサービスを提供するストレージサブシステムと、これを管理する管理装置とを備えるストレージシステムである。管理装置は、予め定められたタスクに従って、移行元ボリューム上のデータを移行先ボリュームに移行するように、ストレージサブシステムのコントローラに指示する。管理装置は、移行先ボリュームが何らかの理由により利用できず、データ移行が正常終了しなかった場合に、必須及び任意要件を含む移行先要件に従って、代替ボリュームを検索し、当該代替ボリュームへのデータ移行を指示する。
【選択図】図１

Description

本発明は、ストレージシステム及びストレージシステムにおけるデータ移行方法に関し、特に、論理ボリューム間のデータマイグレーション技術に関する。

コンピュータシステムにおけるデータ処理量の増大に伴い、データを格納するストレージ装置（ストレージサブシステム）は大容量化している。このため、複数のホストコンピュータとストレージ装置とをネットワークで接続し、柔軟かつ効率的なシステム管理を可能にするＳＡＮ（Storage Area Network）やＮＡＳ（Network Attached Storage）といった技術が広く採用されている。

近年では、ストレージ装置の運用コストの低減が強く望まれている。データのライフサイクル管理は、運用コストの低減を図るための１つの解決法である。データのライフサイクル管理では、データの新しさや利用頻度等に応じて適切なストレージ装置にデータが再配置されるように、データを管理する。このようなデータのライフサイクル管理を実現する技術として、ストレージ装置内のあるボリューム上のデータを他のボリュームに移行するデータマイグレーションが知られている。

典型的なデータマイグレーションにおいては、ストレージ装置は、移行元のボリューム上のデータを移行先のボリュームにコピーした後、移行元のボリューム上のデータを削除し、ホストコンピュータからのアクセス先を移行先のボリュームに切り替える。データ移行中に、ホストコンピュータから移行元のボリュームに対して書き込み要求があった場合には、ストレージ装置は、キャッシュメモリに書き込み要求に従うデータを更新データとして保持しておき、後で当該更新データを移行先のボリュームに反映させることで、ボリューム間の整合性を維持している。

下記特許文献１は、移動必須条件に従って、あるボリュームを他のボリュームに再配置する技術を開示する。具体的には、特許文献１のストレージシステムは、第１のストレージ階層に属する第１のボリュームを第２のストレージ階層に再配置するに際して、第１のボリュームの移動先となる移動必須条件を満たす第２のボリュームが第２のストレージ階層に存在しない場合に、第３のストレージ階層に属するボリュームの中で移動必須条件を満たす第３のボリュームを第２のストレージ階層に仮割り当てし、第１のボリュームを第３のボリュームに再配置する。
特開２００７−２７９８４５号公報

上記特許文献１は、移動必須条件を満たすボリュームが移動先のストレージ階層に存在しない場合、移動必須条件を満たす他のストレージ階層のボリュームを当該移動先のストレージ階層に仮割り当てすることで、当該仮割り当てしたボリュームを移動先のボリュームとして利用することができる。

しかしながら、仮割り当てされたボリュームが必ずしもユーザ（システム管理者）が意図した要件を満たしていない場合には、再度、データマイグレーションを行わなければならなかった。また、要件自体がシステム管理者の意図をきめ細かく反映していないと、再マイグレーションの要否を判断することができず、従って、必要な再マイグレーションがなされず、本来、不要な再マイグレーションがなされてしまうという不都合があった。

そこで、本発明は、データマイグレーションにおいて、何らかの理由により移行先ボリュームが利用できない場合であっても、移行先要件に基づいて他のボリュームを移行先として利用することができるストレージシステムを提供することを目的とする。

また、本発明は、システム管理者の意図に即した移行先要件を用いることで、必要な再マイグレーションが確実に行われる一方、不要な再マイグレーションを抑制することができるストレージシステムを提供することを目的とする。

上記課題を解決する本発明は、データの移行先である論理ボリュームが何らかの理由により利用できない場合に、所定の移行先要件に基づいて他のボリュームを新たな移行先のボリュームに選択することを特徴とする。

即ち、ある観点に従う本発明は、ホストコンピュータに対してデータストレージサービスを提供する少なくとも１つのストレージサブシステムと、前記少なくとも１つのストレージサブシステムを管理する管理装置と、を備えるストレージシステムである。前記少なくとも１つのストレージサブシステムは、複数の論理ボリュームを形成した複数のハードディスクドライブを含むディスクアレイと、前記ホストコンピュータからのアクセス要求に基づいて、前記ディスクアレイに対するアクセスを制御するコントローラとを備え、前記管理装置は、前記複数の論理ボリュームの一つである第１の論理ボリュームから前記複数の論理ボリュームの一つである第２の論理ボリュームへのデータの移行を定義した第１のタスクを登録した移行タスク情報と、前記第１のタスクについての少なくとも１つの移行先要件を登録した移行先要件情報とを備える。

そして、前記管理装置は、前記移行タスク情報に登録された前記第１のタスクに従って、前記第１の論理ボリュームを有する前記少なくとも１つのストレージサブシステムのコントローラに対して、前記第１のタスクの実行を指示し、前記コントローラによる前記第１のタスクの実行が正常に終了しなかったと判断した場合に、前記移行先要件情報に基づいて、前記第２の論理ボリュームを代替する第３の論理ボリュームを特定し、前記第１の論理ボリュームから前記第３の論理ボリュームへのデータの移行を定義した第２のタスクを前記移行タスク情報に登録し、前記移行タスク情報に登録された前記第２のタスクに従って、前記第１の論理ボリュームを有する前記少なくとも１つのストレージサブシステムのコントローラに対して、前記第２のタスクの実行を指示する。

また、別の観点に従う本発明は、ホストコンピュータに対してデータストレージサービスを提供する少なくとも１つのストレージサブシステムと、前記少なくとも１つのストレージサブシステムを管理する管理装置とを備えるストレージシステムにおけるデータ移行方法である。当該データ移行方法は、前記管理装置が、第１の論理ボリュームから第２の論理ボリュームへのデータの移行を定義した第１のタスクを登録した移行タスク情報を保持するステップと、前記管理装置が、前記第１のタスクについての少なくとも１つの移行先要件を登録した移行先要件情報を保持するステップと、前記管理装置が、前記移行タスク情報に登録された前記第１のタスクに従って、前記第１の論理ボリュームを有する前記少なくとも１つのストレージサブシステムのコントローラに対して、前記第１のタスクの実行を指示するステップと、前記管理装置が、前記コントローラによる前記第１のタスクの実行が正常に終了しなかったと判断した場合に、前記移行先要件情報に基づいて、前記第２の論理ボリュームを代替する第３の論理ボリュームを特定ステップと、前記管理装置が、前記第１の論理ボリュームから前記第３の論理ボリュームへのデータの移行を定義した第２のタスクを前記移行タスク情報に登録するステップと、前記管理装置が、前記移行タスク情報に登録された前記第２のタスクに従って、前記第１の論理ボリュームを有する前記少なくとも１つのストレージサブシステムのコントローラに対して、前記第２のタスクの実行を指示するステップと、を含む。

本発明によれば、データマイグレーションにおいて、何らかの理由により移行先ボリュームが利用できない場合であっても、移行先要件に基づいて他のボリュームを移行先として利用することができるようになる。また、移行先要件は必須要件及び任意要件を含んでいるため、従って、必要な再マイグレーションが確実に行われる一方、不要な再マイグレーションを抑制することができるようになる。

本発明の他の技術的特徴及び利点は、添付した図面を参照して説明される以下の実施形態のより明らかにされる。

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

［第１の実施形態］
図１は、本発明の一実施形態に係るコンピュータシステムの構成を示すブロックダイアグラムである。同図に示すように、コンピュータシステム１は、ＳＡＮ（Storage Area Network）のようなネットワーク２Ａを介して接続された１以上のホストコンピュータ３と、１以上のストレージサブシステム４とを含んで構成されている。コンピュータシステム１はまた、管理装置５を含む。管理装置５は、ＬＡＮ（Local Area Network）のような管理用ネットワーク２Ｂを介して、ホストコンピュータ３及びストレージサブシステム４に接続されている。ホストコンピュータ３からみれば、ストレージサブシステム４と管理装置５とは、ストレージシステム１０を形成している。

ホストコンピュータ３は、内部バスを介して相互に接続された、プロセッサと、メインメモリと、通信インターフェースと、ローカル入出力装置等のハードウェア資源を備えるとともに、デバイスドライバやオペレーティングシステム（ＯＳ）、アプリケーションプログラム等のソフトウェア資源を備える（図示せず）。これによって、ホストコンピュータ３は、プロセッサの制御の下、各種のアプリケーションプログラムを実行して、ハードウェア資源との協働作用により、ストレージサブシステム４にアクセスしながら、所望の処理を遂行する。

ストレージサブシステム４は、データストレージサービスをホストコンピュータ３に提供するストレージ装置である。ストレージサブシステム１は、典型的には、データを記憶するハードディスクドライブ等の大容量記憶媒体を含むディスクドライブ４１と、これを制御するコントローラ４２とから構成される。

管理装置５は、システム管理者がストレージサブシステム４全体を管理するための端末装置であり、典型的には、管理プログラムを実装した汎用コンピュータで構成される。

システム管理者は、管理装置４によって提供されるユーザインターフェースを介して、コントローラ４２に指示を与え、これによって、ストレージサブシステム４のシステム構成情報を取得、参照し、また、システム構成情報を設定・変更したりすることができる。例えば、システム管理者は、管理装置４を操作して、ハードディスクドライブの増減設に応じて、論理ボリュームを設定し、また、ＲＡＩＤ構成を設定することができる。本実施形態では、システム管理者は、管理装置４を操作して、移行タスク及び移行先要件を設定することができる。

図２は、本発明の第１の実施形態に係るストレージサブシステム４の構成を説明するためのブロックダイアグラムである。

上述したように、ストレージサブシステム４は、データを記憶するハードディスクドライブ等の大容量記憶媒体を含むディスクアレイ４１と、これを制御するコントローラ４２とから構成される。ディスクアレイ４１とコントローラ４２とは、ディスクチャネルを介して接続される。図示はしていないが、典型的には、コントローラ４２は、二重化構成されている。

ディスクアレイ４１は、例えば複数のハードディスクドライブ及び当該複数のハードディスクドライブのそれぞれを駆動を制御する制御回路を含む１つ以上のドライブユニットから構成される。ハードディスクドライブには、例えば、ＦＣ（Fibre Channel）ドライブやＳＡＴＡ（Serial ATA）ドライブ等が採用される。ただし、ハードディスクドライブに代えて、フラッシュメモリ等のソリッドステート装置（ＳＳＤ）が用いられてもよい。

ハードディスクドライブは、典型的には、所定のＲＡＩＤレベルに基づいてＲＡＩＤグループを構成し、ＲＡＩＤ制御の下、Ｉ／Ｏアクセスされる。ＲＡＩＤ制御は、例えば、コントローラ４２に実装された既知のＲＡＩＤコントローラ乃至はＲＡＩＤエンジン（図示せず）により行われる。同一のＲＡＩＤグループに属するハードディスクドライブは、１つの論理デバイス（仮想デバイス）として扱われる。仮想デバイス上には、１つ以上の論理ユニット（ＬＵ）乃至は論理ボリューム（ＶＯＬ）（以下、「ボリューム」という。）が形成される。つまり、ボリュームは、物理デバイスである１つ又は複数のハードディスクドライブによって構成される論理的な記憶領域である。

コントローラ４２は、ストレージサブシステム３全体を制御するシステムコンポーネントであり、その主たる役割は、ホストコンピュータ３からのＩ／Ｏアクセス要求（Ｉ／Ｏコマンド）に基づいて、ディスクアレイ４１の特定のハードディスクドライブに対するＩ／Ｏ制御を行うことである。また、本実施形態では、コントローラ４２は、管理装置５の指示の下、データ（ボリューム）の移行処理を実行する機能を有する。

同図を参照して、コントローラ４２は、ホストインターフェース（ホストＩ／Ｆ）４２１、データコントローラ４２２、ドライブインターフェース（ドライブＩ／Ｆ）４２３、プロセッサ４２４、メモリユニット４２５、ＬＡＮインターフェース４２６を含む。

ホストインターフェース４２１は、ネットワーク２Ａを介してホストコンピュータ３を接続するためのインターフェースであり、ホストコンピュータ３との間の所定のプロトコルに従ったデータ通信を制御する。ホストインターフェース４２１は、ホストコンピュータ３からの例えば書き込み要求（書き込みコマンド）を受信すると、データコントローラ４２２を介して、メモリユニット４２５に当該書き込みコマンド及びこれに従うデータを書き込む。

データコントローラ４２２は、コントローラ４２内のコンポーネント間のインターフェースであり、コンポーネント間のデータの送受を制御するチップセットである。データコントローラ４２は、図示しないＤＭＡを含んでいる。

ドライブインターフェース４２３は、ディスクアレイ４１を接続するためのインターフェースであり、ホストコンピュータ３からのＩ／Ｏコマンドに基づくプロセッサ４２４の制御の下、ディスクアレイ４１との間で所定のプロトコルに従ったデータ通信を制御する。

プロセッサ４２４は、メモリユニット４２５上にロードされた各種の制御プログラムを実行して、コントローラ４２（すなわちストレージサブシステム１）全体の動作を司る。例えば、プロセッサ４２４は、メモリユニット４２５を周期的にチェックし、メモリユニット４２５上にホストコンピュータ３からのＩ／Ｏコマンドに従うデータを見つけると、ディスクアダプタ４２３を制御して、ディスクアレイ４１に対してアクセスする。

メモリユニット４２５は、プロセッサ４２４のメインメモリとして機能するとともに、チャネルアダプタ４２１及びドライブインターフェース４２３のキャッシュメモリとして機能する。メモリユニット４２５は、例えば、ＤＲＡＭ等の揮発性メモリで構成され、あるいは、フラッシュメモリ等の不揮発性メモリで構成される。メモリユニット１２５は、各種の制御プログラムとともに、ストレージサブシステム１自体のシステム構成情報を記憶する。システム構成情報は、ストレージサブシステム１の稼働に必要な情報であり、例えば、論理ボリューム構成情報やＲＡＩＤ構成情報等を含む。同図に示す例では、メモリユニット４２５は、Ｉ／Ｏ処理プログラム及び移行処理プログラムを保持するとともに、移行指示内容テーブル３００をシステム構成情報の一部として保持している。移行処理プログラムは、あるボリュームから他のボリュームにデータを移行するための制御プログラムである。移行処理プログラムは、データマイグレーションに伴い、ホストコンピュータ３によるＩ／Ｏアクセスが移行先のボリュームに向くように、制御する。

ＬＡＮインターフェース１２６は、管理用ネットワーク２Ｂを介して管理装置４を接続するためのインターフェース回路である。ＬＡＮインターフェースは、例えば、ＴＣＰ／ＩＰ及びイーサネット（登録商標）に従ったネットワークボードを採用することができる。

図３は、本発明の第１の実施形態に係るストレージサブシステム４における移行指示内容テーブル３００の一例を示す図である。

同図に示すように、移行指示内容テーブル３００は、指示内容ＩＤ３０１、移行元装置ＩＤ３０２、移行元ＬＵＮ３０３、移行先装置ＩＤ３０４、移行先ＬＵＮ３０５の各欄を含む。指示内容ＩＤ３０１は、管理装置５から与えられる移行タスクの実行指示を一意に識別するための識別子である。移行元装置ＩＤ３０２は、移行元のボリュームを有するストレージサブシステム４を一意に識別するための識別子であり、移行元ＬＵＮ３０３は、当該移行元のボリュームを一意に識別するための識別子である。つまり、移行元のボリュームは、移行元装置ＩＤ３０２及び移行元ＬＵＮ３０３の組み合わせで特定される。移行先装置ＩＤ３０４は、移行先のボリュームを有するストレージサブシステム４を一意に識別するための識別子であり、移行先ＬＵＮ３０４は、当該移行元のボリュームを一意に識別するための識別子である。つまり、移行元のボリュームは、移行先装置ＩＤ３０４及び移行先ＬＵＮ３０５の組み合わせで特定される。

図４は、本発明の第１の実施形態に係る管理装置５の構成を説明するためのブロックダイアグラムである。

上述したように、管理装置５は、汎用のコンピュータであり、従って、ＣＰＵ５１と、メモリ５２と、Ｉ／Ｏ装置５３と、通信インターフェース（通信Ｉ／Ｆ）５４等のハードウェア資源と、ＯＳ及び管理プログラム等のソフトウェア資源を備える。

ＣＰＵ５１は、メモリ５２に格納された各種の管理プログラムを実行して、システム管理者にシステム管理ツールを提供する。同図に示す例では、メモリ５２は、ストレージ管理プログラム及び移行指示プログラムを保持するとともに、ボリューム管理テーブル５００、移行タスクテーブル６００、移行先要件テーブル７００、及びテスク実行条件テーブル８００を保持している。ストレージ管理プログラムは、ストレージサブシステム４を管理するためのプログラムである。また、移行指示プログラムは、ストレージサブシステム４のコントローラ４２に対してボリューム上のデータの移行を指示するプログラムである。管理装置５による移行指示に従って、ストレージサブシステム４のコントローラ４２は、移行処理プログラムを実行し、データマイグレーション処理を実現する。

Ｉ／Ｏ装置５３は、システム管理者にユーザインターフェース環境を提供するための、例えばキーボード、ポインティングデバイス及びディスプレイ等からなる。

通信Ｉ／Ｆ５４は、外部の装置、即ち、ホストコンピュータ３及びストレージサブシステム４との間の通信を制御するためのインターフェースとして機能する。

同図では、管理装置５は、管理用ネットワーク２Ｂを介してストレージ装置１の外側に設けられているが、この構成に限らず、ストレージサブシステム１の内部に設けられるようにしてもかまわない。あるいは、管理装置５と同等の機能を含むように、コントローラ１２が構成されてもよい。

図５は、本発明の第１の実施形態に係る管理装置５におけるボリューム管理テーブル５００の一例を示す図である。同図に示すように、ボリューム管理テーブル５００は、装置ＩＤ５０１、ＬＵＮ５０２１、コントローラＩＤ５０３、ディスクＩＤ５０４、ボリューム属性５０５、及び状態５０６の各欄を含む。

装置ＩＤ５０１は、ボリュームを提供するストレージサブシステム４を一意に識別するための識別子である。ＬＵＮ５０２１は、当該ストレージサブシステム４内のボリュームを一意に識別するための論理ユニット番号である。コントローラＩＤ５０３は、当該ボリュームを制御するコントローラを一意に識別するための識別子である。ディスクＩＤ５０４は、当該ボリュームを構成するハードディスクドライブを識別するための識別子である。従って、当該ボリュームが複数のハードディスクドライブによって構成されている場合には、複数のディスクＩＤが登録される。ボリューム属性５０５は、当該ボリュームが有する属性である。本例では、容量、ＲＡＩＤレベル、及びディスク種別が定義されているが、これらに限定されない。例えば、ボリュームに対する省電力制御に関わる情報や、ボリュームに対するＩ／Ｏアクセスの制御に関わる情報もまた、ボリューム属性５０５として定義されうる。また、ボリュームを構成するハードディスクドライブのコスト（例えばビット単価）やボリュームを有するストレージサブシステム４自体のコスト、ボリュームのＩ／Ｏアクセス性能も、同様に、ボリューム属性５０５として定義されうる。さらに、ボリュームのセキュリティ堅牢性や、ボリュームが属している構成上のグループ情報（例えば、パリティグループ等）、ボリュームが属している管理上のグループ情報（例えば、管理権限グループ等）、移行先ボリュームが属している利用上のグループ情報（例えば、ボリュームを利用するホストコンピュータ３のグループ等）も定義されうる。状態５０６は、ストレージサブシステム４の稼働状態であり、「正常」又は「異常」で示される。

図６は、本発明の第１の実施形態に係る管理装置５における移行タスクテーブル６００の一例を示す図である。同図に示すように、移行タスクテーブル６００は、移行タスクＩＤ６０１、移行元装置ＩＤ６０２、移行元ＬＵＮ６０３、移行先要件ＩＤ６０４、移行先装置ＩＤ６０５、移行先ＬＵＮ６０６、及びタスク実行日時６０７の各欄を含む。

移行タスクＩＤ６０１は、移行タスクを一意に識別するための番号である。移行元装置ＩＤ６０２は、移行元のボリュームを有するストレージサブシステム４を一意に識別するための識別子である。移行元ＬＵＮ６０３は、当該移行元ボリュームを一意に識別する論理ユニット番号である。移行先要件ＩＤ６０４は、当該移行先ボリュームに対して定義された移行先要件を一意に識別するための識別子である。移行先要件は、移行先要件テーブル７００で定義される。移行先装置ＩＤ６０５は、移行先のボリュームを有するストレージサブシステム４を一意に識別するための識別子である。移行先ＬＵＮ６０６は、当該移行先ボリュームを一意に識別するための論理ユニット番号である。タスク実行日時６０７は、当該移行タスクを実行する日時である。

なお、移行タスクＩＤ６０１「３」で示される移行タスクについて、移行先ボリュームがまだ決定していないため、移行先装置ＩＤ６０５および移行先ＬＵＮ６０６の値をＮＵＬＬである。移行先ボリュームを決定する処理シーケンスについては後述する。

図７は、本発明の第１の実施形態に係る管理装置５における移行先要件テーブル７００の一例を示す図である。同図に示すように、移行先要件テーブル７００は、移行先要件ＩＤ７０１、移行先要件７０２、必須フラグ７０３、及び移行完了日時７０４の各欄を含む。

移行先要件ＩＤ７０１は、移行先ボリュームごとに設定された移行先要件を識別する識別子であり、移行タスクテーブル６００の移行先要件ＩＤ６０４に関連付けられている。移行先要件７０２は、移行先ボリュームが満たすべき要件であって、ユーザ（システム管理者）によって予め設定される。必須フラグ７０３は、移行先要件７０２が必須要件か又は任意要件かを示すフラグである。移行完了日時７０４は、データマイグレーションが完了しなければならない日時である。

また本実施形態では、移行先要件７０２として、ボリュームの容量に対する要件と、ボリュームのＲＡＩＤレベルに対する要件と、ボリュームのディスク種別に対する要件とが定義されている。移行先要件７０２はこれらに限定することはなく、ボリュームの性質や特徴に基づいて他の要件が定義されうる。さらに、本実施形態では、必須フラグ７０３に代えて、移行先要件７０２の優先度を用いても良い。

図８は、本発明の第１の実施形態に係る管理装置５におけるタスク実行条件テーブル８００の一例を示す図である。タスク実行条件テーブル８００は、ボリューム間のマイグレーション後に再マイグレーションを実行するための条件を定義したテーブルである。同図に示すように、タスク実行条件テーブル８００は、条件ＩＤ８０１、移行タスクＩＤ８０２、実行条件８０３、及びタスク実行期限８０４の各欄を含む。

条件ＩＤ８０１は、移行タスクを実行するための条件を一意に識別する識別子である。移行タスクＩＤ８０２は、移行タスクを一意に識別する識別子である。実行条件８０３は、移行タスクを実行するための条件である。実行条件８０３は、例えば、ハードディスクドライブに発生した障害の回復を条件に定義することができる。タスク実行期限８０４は、移行タスクの有効期限である。

図９は、本発明の第１の実施形態に係る管理装置５による移行タスク設定処理を説明するための図である。移行タスク設定処理は、マイグレーション処理に先だって、移行タスク及びその移行先要件を設定するための処理である。移行タスク設定処理は、管理装置５がストレージ管理プログラムを実行することにより、実現される。

同図を参照して、ストレージ管理プログラムの実行により、管理装置５は、ストレージサブシステム４のシステム構成情報を取得し（ＳＴＥＰ９０１）、当該取得したシステム構成情報に従って、ボリューム管理テーブル５００を更新する（ＳＴＥＰ９０２）。管理装置５は、次に、ユーザインターフェースを介して、移行タスク入力画面をシステム管理者に提示して、移行タスクを受け付け、さらに、移行先要件入力画面を提示して、移行先要件を受け付ける（ＳＴＥＰ９０３）。管理装置５は、当該受け付けた移行タスク及び移行先要件に基づいて、移行タスクテーブル６００及び移行先要件テーブル７００をそれぞれ更新する。

図１０は、本発明の第１の実施形態に係る管理装置５のユーザインターフェース上に表示された移行タスク入力画面の一例を示している。同図に示すように、システム管理者は、移行元の装置ＩＤをプルダウンメニューで選択する。移行元装置ＩＤのプルダウンメニューには、ストレージ管理プログラムによって管理される装置（ストレージサブシステム４）のＩＤ一覧が表示される。また、システム管理者がプルダウンメニューから選択したストレージサブシステム４内のボリュームのリストが、移行先ボリュームのＬＵＮのリストとして表示される。

システム管理者は、移行元ボリュームのＬＵＮを例えばラジオボタンで選択する。同様にして、移行先装置ＩＤと移行先ボリュームのＬＵＮとを選択する。さらに、システム管理者は、タスクを実行する日時として、年月日をプルダウンメニューから選択し、時刻をテキストボックスに入力する。システム管理者が、「ＯＫ」ボタンを選択すると、管理装置５は、入力された内容を受け付け、移行タスクテーブル６００に反映させる。

なお、同図は、移行タスクの入力方法の一例を示しており、これに限るものではない。例えばコマンドラインプログラムやファイル、スクリプトプログラムを用いた入力方法等であってもよい。

図１１は、本発明の第１の実施形態に係る管理装置５のユーザインターフェース上に表示された移行先要件入力画面を示している。同図に示すように、システム管理者は、移行先要件として、「ボリューム属性」および「条件」をプルダウンメニューから選択する。また、システム管理者は、「要件」をテキストボックスに入力する。システム管理者は、入力した要件を必須要件として扱いたい場合には、「必須」のチェックボックスにチェックを入力する。「要件」を２つ以上設定したい場合には、システム管理者は、「要件追加」ボタンを選択する。「要件追加」ボタンが選択されると、移行先要件入力画面には、ボリューム属性および条件を選択するためのプルダウンメニューと、要件を入力するためのテキストボックスと、要件が必須か否かを入力するためのチェックボックスと、が追加表示される。さらに、システム管理者は、タスクの移行完了日時として「年月日」をプルダウンメニューから選択し、「時刻」をテキストボックスに入力する。システム管理者が、「ＯＫ」ボタンを選択すると、管理装置５は、入力された内容を受け付け、移行先要件テーブルに反映させる。

なお、同図は、移行先要件の入力方法の一例を示しており、これに限るものではない。例えばコマンドラインプログラムやファイル、スクリプトプログラムを用いた入力方法等であってもよい。また、管理装置５は、システム管理者からの移行先要件の変更を、任意のタイミングで受け付けてもよい。

図１２、図１９、及び図２１は、本発明の第１の実施形態に係る管理装置５による移行タスク管理処理を説明するための図である。移行タスク管理処理は、管理装置５が移行指示プログラムを実行することにより、実現される。

同図に示すように、管理装置５は、移行タスクテーブル６００を参照して、現在日時がタスク実行日時に到達している移行タスクを検索し、特定する（ＳＴＥＰ１２０１）。該当する移行タスクが存在する場合（ＳＴＥＰ１２０１のＹｅｓ）、管理装置５は、ストレージサブシステム４に対して移行タスク（マイグレーション処理）の実行を指示する（ＳＴＥＰ１２０４）。具体的には、管理装置５は、移行タスクテーブル６００における該当するエントリの移行元装置ＩＤ６０２で示されるストレージサブシステム４に対して、移行元ＬＵＮ６０３で示されるボリューム上のデータを、移行先装置ＩＤ６０５で示されるストレージサブシステム４内の移行先ＬＵＮ６０６で示されるボリュームに移行するように指示する。

図１３は、本発明の第１の実施形態に係るストレージサブシステム４のコントローラ４２によるマイグレーション処理を説明するためのフローチャートである。マイグレーション処理は、コントローラ４２が移行処理プログラムを実行することにより、実現される。

コントローラ４２は、管理装置５からの移行指示を受信すると（ＳＴＥＰ１３０１）、当該移行指示に従って、移行指示内容テーブル３００を更新する（ＳＴＥＰ１３０２）。移行指示を受けたストレージサブシステム４は、移行指示内容テーブル３００に従って、データのマイグレーション処理を行う（ＳＴＥＰ１３０３）。

即ち、コントローラ４２は、移行指示内容テーブル３００を参照し、移行元装置ＩＤ３０２及び移行元ＬＵＮ３０３で特定されるボリューム上のデータを移行先装置ＩＤ３０４及び移行先ＬＵＮ３０５で特定されるボリュームに移行する。データ移行に際しては、コピー機能が用いられてよい。また、データ移行中に、ホストコンピュータ３から移行元ボリュームに対してデータの書き込みが行われる場合であっても、データ移行完了時点で、例えばミラーリングにより、当該データが移行先ボリュームに移行していればよい。

データ移行が完了すると、コントローラ４２は、ホストコンピュータ３からのアクセスが移行先ボリュームに向くように、ボリュームに対するアクセス制御情報を更新する。そして、コントローラ４２は、移行タスクの結果を完了応答として管理装置５に通知する（ＳＴＥＰ１３０４）。移行タスクの結果は、例えば、マイグレーション処理が正常終了したか又は異常終了したかのステータスを含んでいる。

図１２に戻り、管理装置５は、ストレージサブシステム４のコントローラ４２から完了応答を受領すると（ＳＴＥＰ１２０３）、当該完了応答に基づいて、移行タスクが正常終了したか否かを判断する（ＳＴＥＰ１２０４）。移行タスクが正常終了したと判断する場合（ＳＴＥＰ１２０４のＹｅｓ）、管理装置５は、当該移行タスク管理処理を終了する。これに対して、移行タスクが異常終了したと判断する場合（ＳＴＥＰ１２０４のＮｏ）、管理装置５は、代替ボリュームを見つけるために、ストレージサブシステム４のシステム構成情報を取得し、当該取得したシステム構成情報に従って、ボリューム管理テーブル５００を更新する（ＳＴＥＰ１２０５）。なお、移行タスクが異常終了する原因としては、例えばストレージサブシステム４内のコンポーネントの障害等が考えられる。ここでは、ディスクアレイ４１におけるハードディスクドライブの１つ（ボリューム管理テーブル５００におけるディスクＩＤ５０４＝５に該当する物理ディスク）に障害が発生したものと仮定する。この場合、ボリューム管理テーブル５００におけるディスクＩＤ５０４＝５に対応するハードディスクドライブが故障していることを認識し、従って、装置ＩＤ５０１＝ＵＳＰ Ｖ．０、ＬＵＮ５０２＝３で示されるボリュームの状態５０６を「異常」に変更する。

管理装置５は、次に、ボリューム管理テーブル５００、移行タスクテーブル６００、及び移行先要件テーブル７００を参照し、異常終了した移行タスクに対して設定された移行先要件を最も多く満たす他のボリュームを検索し、特定する（ＳＴＥＰ１２０６）。本例では、ボリューム管理テーブル５００の状態５０６が「正常」であるボリュームのうち、必須要件を最も多く満たしたボリュームが代替ボリュームとして選択されるものとする。必須要件を最も多く満たすボリュームが複数ある場合には、そのうち、任意要件を最も多く満たすボリュームが選択される。

管理装置５は、ボリューム管理テーブル５００及び移行タスクテーブル２２４を参照し、異常終了した移行タスクの移行先装置ＩＤ６０５及び移行先ＬＵＮ６０６の値を、特定されたボリュームについての装置ＩＤ５０１及びＬＵＮ５０２の値に変更する（ＳＴＥＰ１２０７）。

続いて、管理装置５は、移行タスクテーブル６００を参照し、当該変更した移行タスクの実行を、ストレージサブシステム４に指示する（ＳＴＥＰ１２０８）。これを受けて、ストレージサブシステム４のコントローラ４２は、上述したように、マイグレーション処理を実行し、完了応答を管理装置５に返す。

そして、管理装置５は、コントローラ４２からの完了応答を受け付けて（ＳＴＥＰ１２０９）、移行タスクが正常終了したか否かを判断する（ＳＴＥＰ１２１０）。移行タスクが失敗したと判定される場合には（ＳＴＥＰ１２１０のＮｏ）、管理装置５は、ＳＴＥＰ１２０４の処理に戻る。一方、代替ボリュームに対する移行タスクが正常終了したと判断される場合（ＳＴＥＰ１２１０のＹｅｓ）、管理装置５は、図１９で示されるデータマイグレーション後のフォローアップ処理を行う。

図１４及び図１５は、本発明の第１の実施形態に係る管理装置５によるボリューム検索処理を説明するためのフローチャートであり、図１２のＳＴＥＰ１２０６に示す処理の詳細フローチャートである。

同図に示すように、管理装置５は、ボリューム管理テーブル５００を参照し、まだ検索対象となっていない一のボリュームを選択し、当該選択したボリュームについての情報を取得する（ＳＴＥＰ１４０１）。管理装置５は、選択すべき一のボリュームがないと判断する場合には（ＳＴＥＰ１４０２のＮｏ）、図１５に示すＳＴＥＰ１５０１の処理に進む。

管理装置５は、選択したボリュームの状態５０６が「正常」であるか否かを判断する（ＳＴＥＰ１４０３）。管理装置５は、当該選択したボリュームの状態５０６が「正常」でないと判断する場合には（ＳＴＥＰ１４０３のＮｏ）、必須スコア及び任意スコアにそれぞれ「−１」をセットし（ＳＴＥＰ１４０４）、ＳＴＥＰ１４０１の処理に戻る。ここで、必須スコアとは、ボリュームが移行先要件のうち必須要件を満たしている度合いを示す値であり、任意スコアとは、ボリュームが任意要件を満たしている度合いを示す値である。本例では、値が大きいほど、要件をより満たしていることになる。

一方、当該選択したボリュームの状態５０６が「正常」であると判断する場合には（ＳＴＥＰ１４０３のＹｅｓ）、管理装置５は、移行先要件テーブル７００を参照し、一の移行先要件７０２を選択する（ＳＴＥＰ１４０５）。例えば、選択された移行先要件７０２として、「容量≧１０ＧＢ」が選択される。このように、移行先要件ＩＤ７０１＝要件１のように、複数の移行先要件７０２が定義されている場合には、順次、その移行先要件７０２が選択されることになる。

管理装置５は、選択すべき一の移行先要件７０２がないと判断する場合には（ＳＴＥＰ１４０６のＮｏ）、ＳＴＥＰ１４０１の処理に戻る。

選択すべき一の移行先要件７０２があると判断する場合には（ＳＴＥＰ１４０６のＹｅｓ）、管理装置５は、移行先要件７０２の種別に従う分岐判断を行う（ＳＴＥＰ１４０７）。即ち、移行先要件７０２が「容量」に関わる要件である場合、管理装置５は、容量比較処理を行う（ＳＴＥＰ１４０８−１）。また、移行先要件が「ＲＡＩＤレベル」に関わる要件である場合、管理装置５は、ＲＡＩＤレベル比較処理を行う（ＳＴＥＰ１４０８−２）。さらに、移行先要件が「ディスク種別」に関わる要件である場合、管理装置５は、ディスク種別比較処理を行う（ＳＴＥＰ１４０８−１）。管理装置５は、これらの処理において、ボリュームごとの必須スコア及び任意スコアを計算する。これらの処理については、図１５〜図１７を用いて説明される。管理装置５は、上記いずれかの処理の後、次の移行先要件７０２を選択するため、ＳＴＥＰ１４０５の処理に戻る。

管理装置５は、選択すべきボリュームがなくなった場合（ＳＴＥＰ１４０２のＮｏ）、計算された必須スコアが最も高いボリュームを選択する（図１５のＳＴＥＰ１５０１）。続いて、管理装置５は、該当するボリュームが複数あるか否かを判断する（ＳＴＥＰ１５０２）。管理装置５は、該当するボリュームが複数あると判断する場合（ＳＴＥＰ１５０２のＹｅｓ）、それらの中で計算された任意スコアが最も高いボリュームを選択する（ＳＴＥＰ１５０３）。なお、任意スコアが最も高いボリュームが複数ある場合には、例えば、ボリューム管理テーブルのエントリ順に従ってボリュームが選択される。

なお、本例では、必須スコアおよび任意スコアに従って、最適なボリュームを検索することとしたが、これに限るものではない。

図１６は、図１４のＳＴＥＰ１４０８−１に示した容量比較処理を説明するためのフローチャートである。

同図に示すように、まず、管理装置５は、ボリューム管理テーブル６００における選択されたボリューム（図１４のＳＴＥＰ１４０１参照）の容量と、移行先要件テーブル７００における選択された移行先要件（ＳＴＥＰ１４０５参照）の容量とを比較し（ＳＴＥＰ１６０１）、比較結果に基づいて分岐判断を行う（ＳＴＥＰ１６０２）。

即ち、管理装置５は、移行先要件７０２の容量と選択されたボリュームの容量が等しい場合は、要件満足度に「２」をセットする（ＳＴＥＰ１６０３−１）。また、管理装置５は、管理装置５は、移行先要件７０２の容量よりも選択されたボリュームの容量が大きい場合は、要件満足度に「１」をセットする（ＳＴＥＰ１６０３−２）。さらに、管理装置５は、移行先要件７０２の容量よりも選択されたボリュームの容量が小さい場合は、要件満足度に「０」をセットする（ＳＴＥＰ１６０３−３）。要件満足度とは、選択されたボリュームが移行先要件をどの程度満たしているかを示す値であり、本例では、０〜２の整数で示される。

次に、管理装置５は、移行先要件テーブル７００における該当するエントリの必須フラグ７０３を参照し、選択された移行先要件が必須要件であるか否かを判断する（ＳＴＥＰ１６０４）。管理装置５は、選択された移行先要件が必須要件であると判断する場合には（ＳＴＥＰ１６０４のＹｅｓ）、必須スコアに要件満足度を加算する（ＳＴＥＰ１６０５）。一方、管理装置５は、選択された移行先要件が必須要件でない（つまり任意要件である）と判断する場合には（ＳＴＥＰ１６０４のＮｏ）、任意スコアに要件満足度を加算する（ＳＴＥＰ１６０６）。

図１７は、図１４のＳＴＥＰ１４０８−２に示したＲＡＩＤレベル比較処理を説明するためのフローチャートである。

同図に示すように、まず、管理装置５は、ボリューム管理テーブル６００における選択されたボリューム（図１４のＳＴＥＰ１４０１参照）のＲＡＩＤレベルと、移行先要件テーブル７００における選択された移行先要件７０２（ＳＴＥＰ１４０５参照）のＲＡＩＤレベルとを比較して、ＲＡＩＤレベルの信頼性の優劣を判断し（ＳＴＥＰ１７０１）、その結果に基づいて分岐判断を行う（ＳＴＥＰ１７０２）。ＲＡＩＤレベルの信頼性は、何台までのハードディスクドライブの故障に対してデータ復旧の可能性を保証できるかによって定義される。一般的に、ミラーリングの構成やパリティを持つＲＡＩＤレベルは信頼性が高いと言える。本実施形態では、ＲＡＩＤレベルの信頼性を以下のように定義する。

ＲＡＩＤ１＞ＲＡＩＤ０＋１＝ＲＡＩＤ１＋０＞ＲＡＩＤ６＞ＲＡＩＤ５＞ＲＡＩＤ２＝ＲＡＩＤ３＝ＲＡＩＤ４＞ＲＡＩＤ０＝ＪＢＯＤ（Just a Bunch Of Disks）

管理装置５は、分岐判断の結果、移行先要件７０２のＲＡＩＤレベルの信頼性と選択されたボリュームのＲＡＩＤレベルの信頼性が等しい場合は、要件満足度に「２」をセットする（ＳＴＥＰ１７０３−１）。また、管理装置５は、管理装置５は、移行先要件７０２のＲＡＩＤレベルの信頼性よりも選択されたボリュームのＲＡＩＤレベルの信頼性が高い場合は、要件満足度に「１」をセットする（ＳＴＥＰ１７０３−２）。さらに、管理装置５は、移行先要件７０２のＲＡＩＤレベルの信頼性よりも選択されたボリュームのＲＡＩＤレベルの信頼性が小さい場合は、要件満足度に「０」をセットする（ＳＴＥＰ１７０３−３）。

管理装置５は、次に、移行先要件テーブル７００における該当するエントリの必須フラグ７０３を参照し、選択された移行先要件７０２が必須要件であるか否かを判断する（ＳＴＥＰ１７０４）。管理装置５は、選択された移行先要件７０２が必須要件であると判断する場合には（ＳＴＥＰ１７０４のＹｅｓ）、必須スコアに要件満足度を加算する（ＳＴＥＰ１６０５）。一方、管理装置５は、選択された移行先要件が必須要件でない（つまり任意要件である）と判断する場合には（ＳＴＥＰ１７０４のＮｏ）、任意スコアに要件満足度を加算する（ＳＴＥＰ１７０６）。

図１８は、図１４のＳＴＥＰ１４０８−３に示したディスク種別比較処理を説明するためのフローチャートである。

同図に示すように、まず、管理装置５は、移行先要件テーブル７００における選択された移行先要件（ＳＴＥＰ１４０５参照）のディスク種別を判断する（ＳＴＥＰ１８０１）。即ち、管理装置５は、選択された移行先要件７０２のディスク種別が「ＦＣ」であると判断する場合、続いて、ボリューム管理テーブル５００における選択されたボリューム（図１４のＳＴＥＰ１４０１参照）のディスク種別を判断する（ＳＴＥＰ１８０２）。管理装置５は、選択されたボリュームのディスク種別が「ＦＣ」であると判断する場合には、要件満足度に「２」をセットし（ＳＴＥＰ１８０３）、これに対して、選択されたボリュームのディスク種別が「ＳＡＴＡ」であると判断する場合には、要件満足度に「０」をセットする（ＳＴＥＰ１８０４）。

一方、管理装置５は、選択された移行先要件７０２のディスク種別が「ＳＡＴＡ」であると判断する場合、続いて、ボリューム管理テーブル５００における選択されたボリュームのディスク種別を判断する（ＳＴＥＰ１８０５）。管理装置５は、選択されたボリュームのディスク種別が「ＳＡＴＡ」であると判断する場合には、要件満足度に「２」をセットし（ＳＴＥＰ１８０６）、これに対して、選択されたボリュームのディスク種別が「ＦＣ」であると判断する場合には、要件満足度に「１」をセットする（ＳＴＥＰ１８０７）。

管理装置５は、次に、移行先要件テーブル７００における該当するエントリの必須フラグ７０３を参照し、選択された移行先要件が必須要件であるか否かを判断する（ＳＴＥＰ１８０８）。管理装置５は、選択された移行先要件が必須要件であると判断する場合には（ＳＴＥＰ１８０８のＹｅｓ）、必須スコアに要件満足度を加算する（ＳＴＥＰ１８０９）。一方、管理装置５は、選択された移行先要件が必須要件でない（つまり任意要件である）と判断する場合には（ＳＴＥＰ１８０８のＮｏ）、任意スコアに要件満足度を加算する（ＳＴＥＰ１８１０）。

図１９は、本発明の第１の実施形態に係る管理装置５による移行タスク管理処理を説明するためのフローチャートであり、具体的には、マイグレーション処理後のフォローアップ処理を説明している。フォローアップ処理は、他のボリュームが移行先として新たに選択された結果、既存の移行タスクにおける移行先ボリュームとの競合が発生しているか否かをチェックする。

即ち、管理装置５は、移行先として選択された他のボリューム（代替ボリューム）が移行先要件テーブル７００における任意要件を１つ以上満たしていないかを判断する（ＳＴＥＰ１９０１）。管理装置５は、代替ボリュームが移行先要件テーブル７００における任意要件を１つ以上満たしていないと判断する場合には（ＳＴＥＰ１９０１のＹｅｓ）、図２０に示すように、ユーザインターフェースを介して、代替ボリュームが満たしていない任意要件を列挙した警告画面をシステム管理者に提示する（ＳＴＥＰ１９０２）。本例では、警告画面によって代替ボリュームが満たしていない任意要件をシステム管理者に提示するものとしているが、これに限るものではない。例えば、管理装置５は、代替ボリュームが満たしていない任意要件をログファイルに出力し、システム管理者が、当該ログファイルを参照するものであってもかまわない。

管理装置５は、次に、代替ボリュームが移行先要件テーブル７００の必須要件を全て満たしていたか否かを判断する（ＳＴＥＰ１９０３）。管理装置５は、代替ボリュームが必須要件を全て満たしていないと判断する場合には（ＳＴＥＰ１９０３のＮｏ）、図２１に示す処理に進む。

管理装置５は、代替ボリュームが必須要件を全て満たしていたと判断する場合には（ＳＴＥＰ１９０３のＹｅｓ）、移行タスクテーブル６００を参照し、代替ボリュームを移行先とする他の移行タスク（以下、「競合タスク」という。）を検索し、特定する（ＳＴＥＰ１９０４）。つまり、移行先のボリュームの変更に伴い、移行先のボリュームに競合が生じている移行タスクがあるか否かが検索される。管理装置５は、競合タスクがないと判断する場合には（ＳＴＥＰ１９０５のＮｏ）、データマイグレーション処理を終了する。

一方、競合タスクがあると判断する場合には（ＳＴＥＰ１９０５のＹｅｓ）、移行先要件テーブル７００を参照して、当該競合タスクの移行先要件を満たすボリュームを検索・特定するとともに（ＳＴＥＰ１９０６）、ボリューム管理テーブル５００及び移行タスクテーブル６００を参照して、競合タスクにおけるボリュームの移行先を当該特定されたボリュームに変更する（ＳＴＥＰ１９０７）。

図２１は、本発明の第１の実施形態に係る管理装置５による移行タスク管理処理を説明するためのフローチャートであり、具体的には、競合タスクについての再マイグレーション処理を説明している。

即ち、管理装置５は、ボリューム管理テーブル６００を参照し、ＳＴＥＰ１２０２で実行を指示した移行タスクについての移行先要件のうち、必須要件を全て満たすボリュームを検索し、特定する（ＳＴＥＰ２１０１）。続いて、管理装置５は、ＳＴＥＰ９１０で移行先として使用したボリューム（代替ボリューム）を、当該特定したボリュームに再移行するための移行タスク（再移行タスク）を移行タスクテーブルに登録する（ＳＴＥＰ２１０２）。管理装置５は、さらに、当該登録した移行タスクに対する実行条件及びタスク実行期限をタスク実行条件テーブルに登録する（ＳＴＥＰ２１０３）。例えば、管理装置５は、移行先ボリュームの変更が生じた要因の解消を実行条件とし、予め定められた期限（例えば３日後）をタスク実行期限とする。あるいは、管理装置５は、ユーザインターフェースを介して、実行条件及びタスク実行期限の入力を受け付けてもよい。本例では、ストレージサブシステム４内のハードディスクドライブの障害回復がタスクの実行条件２２５２として登録されている。

次に、管理装置５は、タスク実行条件テーブル８００を参照し、タスク実行条件が満たされているか否かを判断する（ＳＴＥＰ２１０４）。管理装置５は、タスク実行条件が満たされていると判断する場合には（ＳＴＥＰ２１０４のＹｅｓ）、当該新たに登録した移行タスクの実行をストレージサブシステム４に指示する（ＳＴＥＰ２１０５）。これを受けて、ストレージサブシステム４のコントローラ４２は、データマイグレーション処理を実行し、その実行結果を完了応答として管理装置５に返す。管理装置５は、完了応答を受領し（図９のＳＴＥＰ９０５）、移行タスクは正常に終了したか否かを判断する（ＳＴＥＰ９０６）。

一方、タスク実行条件が満たされていないと判断する場合には（ＳＴＥＰ２１０４のＮｏ）、管理装置５は、当該移行タスクのタスク実行期限を経過したか否かを判断する（ＳＴＥＰ２１０６）。管理装置５は、タスク実行期限を経過していないと判断する場合には（ＳＴＥＰ２１０６のＮｏ）、ストレージサブシステム４から最新のシステム構成情報を取得し、ボリューム管理テーブルを更新し（ＳＴＥＰ２１０７）、タスク実行条件が満たされたか否かを判断する（ＳＴＥＰ２１０４）。例えば、ストレージサブシステム４内の物理ディスク（ディスクＩＤ５０４が「５」で示されるハードディスクドライブ）が故障から回復した場合、当該ハードディスクドライブによって構成されるボリュームの状態５０６が「正常」に変更され、従って、タスク実行条件が満たされることになる。

管理装置５は、タスク実行期限を経過したと判断する場合には（ＳＴＥＰ２１０６のＹｅｓ）、当該登録した移行タスクを移行タスクテーブルから削除するとともに（ＳＴＥＰ２１０８）、タスク実行条件テーブルから削除する（ＳＴＥＰ２１０９）。そして、管理装置５は、図２２に示すように、再マイグレーションが正常に行われなかったことを示す警告画面をシステム管理者に通知する（ＳＴＥＰ２１１０）。本例では、警告画面によって再マイグレーションが正常に行われなかったことをシステム管理者に提示するものとしているが、これに限るものではない。例えば、管理装置５は、再マイグレーションが正常に行われなかったことをログファイルに出力し、システム管理者が、当該ログファイルを参照するものであってもかまわない。

以上のように、データマイグレーションにおいて、移行先ボリュームが何らかの理由により利用不可能な場合であっても、ユーザ（システム管理者）が任意に定めた移行先要件を満たす他のボリュームを代替の移行先ボリュームとして利用することが可能になる。また、代替ボリュームが移行先要件のうち必須要件を全て満たしている場合には、元のボリュームの移行要件に完全に合致していない場合であっても、再マイグレーションが行われない。一方、代替ボリュームが移行先要件のうち必須要件を１つでも満たしていない場合には、必須要件を全て満たすように再マイグレーションが行われる。これにより、不要なマイグレーションを抑制することができるとともに、必要なマイグレーションは確実に行われるようになる。

［第２の実施形態］
図２３は、本発明の第２の実施形態に係るコンピュータシステムの構成を示すブロックダイアグラムである。同図に示すように、本実施形態のコンピュータシステム１は、第１のストレージサブシステム４Ａと、当該第１のストレージサブシステム４Ａの外部接続ストレージ（仮想ストレージ）として機能する第２のストレージサブシステム４Ｂとを含む点で、第１の実施形態と異なっている。

第１のストレージサブシステム４Ａは、仮想化機能によって、ネットワーク２Ａを介して接続された第２のストレージサブシステム４Ｂが提供するボリュームを、あたかも自身が有するボリュームであるかのように、ホストコンピュータ３に提供する。このようなボリュームは、仮想ボリュームと呼ばれる。また、第１のストレージサブシステム４Ａは、ボリュームを構成するハードディスクドライブに対する省電力制御を行う省電力機能を有する。

第２のストレージサブシステム４Ｂは、第１の実施形態で説明したストレージサブシステム４と同一の構成及び機能であっても良いし、本実施形態の第１のストレージサブシステム４Ａと同一の構成及び機能を有していても良い。

図２４は、本発明の第２の実施形態に係るストレージサブシステム４の構成を示すブロックダイアグラムである。同図では、第１のストレージサブシステム４Ａ内に電源制御部４３が明示的に示されている。また、メモリユニット４２５は、Ｉ／Ｏ処理プログラム、移行処理プログラム、仮想化プログラム、及び省電力プログラム並びに移行指示内容テーブル２５００を保持している。第１の実施形態と同様に、コントローラ４２のプロセッサ４２４は、これら各種のプログラムを実行する。

省電力プログラムは、電源制御部４３を制御するプログラムであり、これによって、ディスクアレイ４１全体又は個々のハードディスクドライブ並びにコントローラ４２等の消費電力を制御する。省電力プログラムは、ハードディスクドライブやコントローラ４２に対する消費電力の制御が完了した後、管理装置５に電力供給状態を通知する。

仮想化プログラムは、仮想化機能を実現するためのプログラムである。具体的には、仮想化プログラムは、ネットワーク２Ａを介して接続された第２のストレージサブシステム４Ｂ内のボリュームを第１のストレージサブシステム４Ａ内のボリュームにマッピングすることにより、第２のストレージサブシステム４Ｂのボリュームを第１のストレージサブシステム４Ａのボリュームとしてホストコンピュータ３に提供する。本実施形態は、例えば、特開２００４−５３７０号公報や特開２００５−２５０９２５号公報に開示された仮想化機能を用いることができる。仮想化機能は、ネットワーク２Ａを構成するＦＣスイッチのような機器によって実現されても良い。また、第１のストレージサブシステム４Ａと第２のストレージサブシステム４Ｂとは、１対１の関係であっても良いし、１対多の関係であっても良い。

図２５は、本発明の第２の実施形態に係るストレージサブシステム４における移行指示内容テーブル２５００の一例を示す図である。本実施形態の移行指示内容テーブル２５００は、省電力化実施要否２５０１をさらに含む点で、第１の実施形態の移行指示内容テーブル３００と異なっている。省電力化実施要否２５０１は、省電力モードを実施するか否かを指定するフラグである。省電力化実施要否２５０１が「Ｙｅｓ」である場合、マイグレーション処理が完了した後、省電力プログラムは、移行先ボリュームを構成するハードディスクドライブの電力供給状態を省電力モード（例えばスリープ状態）に変更する。

図２６は、本発明の第２の実施形態に係る管理装置５のメモリ５２の内容の一例を示す図である。同図に示すように、管理装置５のメモリ５２は、省電力指示プログラムをさらに保持する。省電力指示プログラム２２７は、省電力機能を有する（省電力プログラムが実装された）ストレージサブシステム４に対して、省電力モードに設定するように指示するプログラムである。

また、ボリューム管理テーブル２７００及び移行先要件テーブル２８００は、本実施形態に適合するように構成されている。

図２７は、本発明の第２の実施形態に係る管理装置５におけるボリューム管理テーブル２７００の一例を示す図である。同図に示すように、本実施形態のボリューム管理テーブル２７００は、被仮想化装置ＩＤ２７０１及び省電力機能有無２７０２をさらに含む。

被仮想化装置ＩＤ２７０１は、仮想化プログラムによって、仮想ボリュームを提供する第２のストレージサブシステム４Ｂを一意に識別するための識別子である。省電力機能有無２７０２は、第１のストレージサブシステム４Ａ（又は第２のストレージサブシステム４Ｂ）が、ボリュームを構成するハードディスクドライブの電力供給状態をスリープモードに設定したり、ノーマルモードに戻したりする省電力機能を有しているか否かを示す情報である。

図２８は、本発明の第２の実施形態に係る管理装置５における移行先要件テーブル２８００の一例を示す図である。同図に示すように、本実施形態の移行先要件テーブル２８００では、移行先要件７０２に省電力機能に関する要件を含む。本例では、「要件２」について、「ディスク種別＝ＦＣ」に加え、「省電力機能有無＝あり」及び「省電力化実施要否＝要」が設定されている。

次に、本実施形態の管理装置５による処理について説明する。本実施形態では、移行先要件７０２に省電力制御に関わる要件が追加されているため、ボリューム検索処理（図１４及び図１５参照）及びマイグレーション処理後のフォローアップ処理（図１９参照）が第１の実施形態と異なっている。

図２９は、本発明の第２の実施形態に係る管理装置５によるボリューム検索処理を説明するためのフローチャートである。同図に示したボリューム検索処理が上述した図１４と異なる点は、要件種別による分岐判断（ＳＴＥＰ２９０７）の下、省電力機能比較処理（ＳＴＥＰ２９０８−４）が追加されている点である。管理装置は、移行先要件７０２が「省電力機能」に関わる要件である場合、省電力機能比較処理を行う（ＳＴＥＰ２９０８−４）。その他は、上述した図１４に示したボリューム検索処理と同じであるため、説明を省略する。

図３０は、図２９のＳＴＥＰ２９０８−４に示した省電力機能比較処理を説明するためのフローチャートである。

同図に示すように、まず、管理装置５は、移行先要件テーブル２８００における選択された移行先要件７０２の省電力機能の有無を判断する（ＳＴＥＰ３００１）。即ち、管理装置５は、選択された移行先要件７０２の省電力機能有無が「あり」であると判断する場合、続いて、ボリューム管理テーブル５００における選択されたボリュームについての省電力機能の有無を判断する（ＳＴＥＰ３００２）。管理装置５は、選択されたボリュームについての省電力機能が「あり」であると判断する場合には、要件満足度に「２」をセットし（ＳＴＥＰ３００３）、これに対して、選択されたボリュームについての省電力機能が「なし」であると判断する場合には、要件満足度に「０」をセットする（ＳＴＥＰ３００４）。

一方、管理装置５は、選択された移行先要件７０２の省電力機能の有無が「なし」であると判断する場合、続いて、ボリューム管理テーブル５００における選択されたボリュームについての省電力機能の有無を判断する（ＳＴＥＰ３００５）。管理装置５は、選択されたボリュームについての省電力機能の有無が「なし」であると判断する場合には、要件満足度に「２」をセットし（ＳＴＥＰ３００６）、これに対して、選択されたボリュームについての省電力機能の有無が「あり」であると判断する場合には、要件満足度に「１」をセットする（ＳＴＥＰ３００７）。

管理装置５は、次に、移行先要件テーブル７００における該当するエントリの必須フラグ７０３を参照し、選択された移行先要件が必須要件であるか否かを判断する（ＳＴＥＰ３００８）。管理装置５は、選択された移行先要件が必須要件であると判断する場合には（ＳＴＥＰ３００８のＹｅｓ）、必須スコアに要件満足度を加算する（ＳＴＥＰ３００９）。一方、管理装置５は、選択された移行先要件が必須要件でない（つまり任意要件である）と判断する場合には（ＳＴＥＰ３００８のＮｏ）、任意スコアに要件満足度を加算する（ＳＴＥＰ３０１０）。

図３１は、本発明の第２の実施形態に係る管理装置５による移行タスク管理処理を説明するためのフローチャートであり、図１９に示した第１の実施形態におけるマイグレーション処理後のフォローアップ処理に対応する。同図は、ＳＴＥＰ３１０４及びＳＴＥＰ３１０５の処理をさらに含む点で、図１９と異なっている。

即ち、管理装置５は、移行先として選択された他のボリューム（代替ボリューム）が移行先要件テーブル７００における任意要件を１つ以上満たしていないかを判断する（ＳＴＥＰ３１０１）。管理装置５は、代替ボリュームが移行先要件テーブル７００における任意要件を１つ以上満たしていないと判断する場合には（ＳＴＥＰ３１０１のＹｅｓ）、ユーザインターフェースを介して、代替ボリュームが満たしていない任意要件を列挙した警告画面をシステム管理者に提示する（ＳＴＥＰ３１０２）。

管理装置５は、次に、代替ボリュームが移行先要件テーブル７００の必須要件を全て満たしていたか否かを判断する（ＳＴＥＰ３１０３）。管理装置５は、代替ボリュームが必須要件を全て満たしていないと判断する場合には（ＳＴＥＰ３１０３のＮｏ）、第１の実施形態と同様、図２１に示す処理に進む。

管理装置５は、代替ボリュームが必須要件を全て満たしていたと判断する場合には（ＳＴＥＰ３１０３のＹｅｓ）、指示内容テーブル２５００を参照し、移行元ボリュームについての省電力化実施要否２５０１が「要」であるか否かを判断する（ＳＴＥＰ３１０４）。管理装置５は、省電力化実施要否２５０１が「要」であると判断する場合には（ＳＴＥＰ３１０４のＹｅｓ）、移行元ボリュームを有するストレージサブシステム４に対して、当該移行元ボリュームを構成するハードディスクドライブを省電力モードに切り替えるように指示する（ＳＴＥＰ３１０５）。これを受けて、ストレージサブシステム４のコントローラ４２は、電源制御部４３の制御の下、当該移行元ボリュームを構成するハードディスクドライブを省電力モードに切り替える。省電力モードの対象は、ハードディスクドライブに限られない。例えば、当該ボリュームが、第２のストレージサブシステム４Ｂが有する全ハードディスクドライブによって構成されている場合、第２のストレージサブシステム４Ｂ全体を省電力モードに切り替えることが可能である。また、第２のストレージサブシステム４Ｂ全体を省電力モードに切り替えるのではなく、コントローラ４２のみを省電力モードに切り替えるようにしても良い。

続いて、管理装置５は、代替ボリュームを移行先とする競合タスクを検索、特定し、競合タスクがある場合には、競合タスクの移行先要件を満たすさらに他のボリュームを検索、特定し、競合タスクの移行先ボリュームを当該特定されたボリュームに変更する（ＳＴＥＰ３１０６〜ＳＴＥＰ３１０９）。これらの処理は、図１９に示した対応する処理と同じである。

このように、本実施形態では、代替ボリュームに移行元ボリューム上のデータを移行した後、当該代替ボリュームが必須要件を全て満たしている場合には、さらなるマイグレーションが必要とされないので、当該移行元ボリュームを構成するハードウェア資源を省電力モードに設定することができ、従って、消費電力を低く抑えることができるようになる。

［第３の実施形態］
本実施形態は、代替ボリュームを移行先とする競合タスクが存在する場合に、当該代替ボリューム上のデータをさらに他のボリュームに移行することで移行タスクの競合を回避することを特徴とする。

図３２は、本発明の第３の実施形態に係る管理装置５による移行タスク管理処理を説明するためのフローチャートである。同図は、競合タスクを検索する処理以降の処理（ＳＴＥＰ３２０５〜ＳＴＥＰ３２０９）が、図１９と異なっている。

即ち、管理装置５は、移行先として選択された他のボリューム（代替ボリューム）が移行先要件テーブル７００における任意要件を１つ以上満たしていないかを判断する（ＳＴＥＰ３２０１）。管理装置５は、代替ボリュームが移行先要件テーブル７００における任意要件を１つ以上満たしていないと判断する場合には（ＳＴＥＰ３２０１のＹｅｓ）、ユーザインターフェースを介して、代替ボリュームが満たしていない任意要件を列挙した警告画面をシステム管理者に提示する（ＳＴＥＰ３２０２）。

管理装置５は、次に、代替ボリュームが移行先要件テーブル７００の必須要件を全て満たしていたか否かを判断する（ＳＴＥＰ３２０３）。管理装置５は、代替ボリュームが必須要件を全て満たしていないと判断する場合には（ＳＴＥＰ３２０３のＮｏ）、図２１に示す処理に進む。

管理装置５は、代替ボリュームが必須要件を全て満たしていたと判断する場合には（ＳＴＥＰ３２０３のＹｅｓ）、移行タスクテーブル６００を参照し、代替ボリュームを移行先とする他の移行タスク（以下、「競合タスク」という。）を検索し、特定する（ＳＴＥＰ３２０４）。つまり、移行先のボリュームの変更に伴い、移行先のボリュームに競合が生じている移行タスクがあるか否かが検索される。管理装置５は、競合タスクがないと判断する場合には（ＳＴＥＰ３２０５のＮｏ）、データマイグレーション処理を終了する。

一方、競合タスクがあると判断する場合には（ＳＴＥＰ３２０５のＹｅｓ）、さらに、移行タスクテーブル６００を参照して、当該競合タスクのタスク実行日時６０７と現在日時とが所定の時間間隔あるか否かを判断する（ＳＴＥＰ３２０６）。所定の時間間隔は、システム管理者が任意に設定でき、実用上、十分に離れていることが望ましい。所定の時間間隔として、例えば、５時間や１日といった基準が設定される。あるいは、管理装置５は、過去のマイグレーション処理におけるボリュームの容量とマイグレーション処理に要した時間との関係を履歴として保持しておき、当該履歴に基づいてマイグレーション処理に要する時間を予測し、当該予測時間を基準に判断してもよい。

管理装置５は、所定の時間間隔がないと判断する場合には（ＳＴＥＰ３２０６のＮｏ）、移行先要件テーブル７００を参照して、当該競合タスクの移行先要件を満たすボリュームを検索、特定するとともに（ＳＴＥＰ３２０７）、ボリューム管理テーブル５００及び移行タスクテーブル６００を参照して、競合タスクにおけるボリュームの移行先を当該特定されたボリュームに変更する（ＳＴＥＰ３２０８）。

これに対して、所定の時間間隔があると判断する場合には（ＳＴＥＰ３２０６のＮｏ）、管理装置５は、当該代替ボリュームを他のボリュームに移行するための移行タスクを移行タスクテーブル６００に登録するとともに、その際の移行先要件を移行先要件テーブル７００に登録する。具体的には、管理装置５は、代替ボリュームを有するストレージサブシステムの装置ＩＤ及び当該代替ボリュームのＬＵＮを、移行タスクテーブル６００の移行元装置ＩＤ６０２及び移行元ＬＵＮ６０３に登録するとともに（ＳＴＥＰ３２０９）、当該代替ボリュームを検索する際に利用した移行先要件の識別子を移行先要件ＩＤ６０４に登録する（ＳＴＥＰ３２１０）。この場合、移行先装置ＩＤ６０５及び移行先ＬＵＮ６０６には、移行先ボリュームが未定であることを示す情報（例えば、ハイフン（“−”）が登録される。

そして、管理装置５は、ボリューム管理テーブル５００及び移行先要件テーブル７００を参照し、当該移行タスクの移行先要件を満たすボリュームを検索、特定する（ＳＴＥＰ３２１１）。管理装置５は、ＳＴＥＰ３２１１の処理後、図２１に示す処理に進む。

このように、本実施形態は、代替ボリュームを移行先とする競合タスクが存在する場合に、当該代替ボリューム上のデータをさらに他のボリュームに移行することで移行タスクの競合を回避することできるようになる。特に、本実施形態は、当該競合タスクの実行日時まで時間的余裕がある場合に、当該代替ボリューム上のデータをさらに他のボリュームに移行し、時間的余裕がない場合には、競合タスクの移行先ボリューム上のデータを代替ボリュームに移行しているので、柔軟かつ効率的なマイグレーション処理を行うことができるようになる。

［その他の実施形態］
上記実施形態は、本発明を説明するための例示であり、本発明を上記実施形態にのみ限定する趣旨ではない。本発明は、その要旨を逸脱しない限り、さまざまな形態で実施することができる。例えば、上記実施形態では、各種プログラムの処理をシーケンシャルに説明したが、特にこれにこだわるものではない。従って、処理結果に矛盾が生じない限り、処理の順序を入れ替えまたは並行動作するように構成しても良い。

また、本明細書において、各種の情報をテーブル形式で説明したが、これにこだわるものではない。各種の情報は、データの集合体を含み、テーブル以外のデータ構造を有していても良い。

本発明は、データマイグレーション技術を用いたストレージサブシステムに広く適用することができる。

本発明の第１の実施形態に係るコンピュータシステムの構成を示すブロックダイアグラムである。 本発明の第１の実施形態に係るストレージサブシステムの構成を説明するためのブロックダイアグラムである。 本発明の第１の実施形態に係るストレージサブシステムにおける移行指示内容テーブルの一例を示す図である。 本発明の第１の実施形態に係る管理装置の構成を説明するためのブロックダイアグラムである。 本発明の第１の実施形態に係る管理装置におけるボリューム管理テーブルの一例を示す図である。 本発明の第１の実施形態に係る管理装置における移行タスクテーブルの一例を示す図である。 本発明の第１の実施形態に係る管理装置における移行先要件テーブルの一例を示す図である。 本発明の第１の実施形態に係る管理装置におけるタスク実行条件テーブル８００の一例を示す図である。 本発明の第１の実施形態に係る管理装置による移行タスク設定処理を説明するための図である。 本発明の第１の実施形態に係る管理装置のユーザインターフェース上に表示された移行タスク入力画面の一例を示す図である。 本発明の第１の実施形態に係る管理装置のユーザインターフェース上に表示された移行先要件入力画面を示す図である。 本発明の第１の実施形態に係る管理装置による移行タスク管理処理を説明するための図である。 本発明の第１の実施形態に係るストレージサブシステムのコントローラによるマイグレーション処理を説明するためのフローチャートである。 本発明の第１の実施形態に係る管理装置によるボリューム検索処理を説明するためのフローチャートである。 本発明の第１の実施形態に係る管理装置によるボリューム検索処理を説明するためのフローチャートである。 図１４のＳＴＥＰ１４０８−１で示される容量比較処理を説明するためのフローチャートである。 図１４のＳＴＥＰ１４０８−２で示されるＲＡＩＤレベル比較処理を説明するためのフローチャートである。 図１４のＳＴＥＰ１４０８−３に示されるディスク種別比較処理を説明するためのフローチャートである。 本発明の第１の実施形態に係る管理装置による移行タスク管理処理を説明するための図である。 本発明の第１の実施形態に係る管理装置のユーザインターフェース上に表示された警告画面の一例を示す図である。 本発明の第１の実施形態に係る管理装置による移行タスク管理処理を説明するための図である。 本発明の第１の実施形態に係る管理装置のユーザインターフェース上に表示された警告画面の一例を示す図である。 本発明の第２の実施形態に係るコンピュータシステムの構成を示すブロックダイアグラムである。 本発明の第２の実施形態に係るストレージサブシステムの構成を示すブロックダイアグラムである。 本発明の第２の実施形態に係るストレージサブシステムにおける移行指示内容テーブルの一例を示す図である。 本発明の第２の実施形態に係る管理装置のメモリの内容の一例を示す図である。 本発明の第２の実施形態に係る管理装置におけるボリューム管理テーブルの一例を示す図である。 本発明の第２の実施形態に係る管理装置における移行先要件テーブルの一例を示す図である。 本発明の第２の実施形態に係る管理装置によるボリューム検索処理を説明するためのフローチャートである。 図２９のＳＴＥＰ２９０８−４示される省電力機能比較処理を説明するためのフローチャートである。 本発明の第２の実施形態に係る管理装置による移行タスク管理処理を説明するためのフローチャートである。 本発明の第３の実施形態に係る管理装置による移行タスク管理処理を説明するためのフローチャートである。

符号の説明

１…コンピュータシステム
２…ネットワーク
３…ホストコンピュータ
４…ストレージサブシステム
４１…ディスクアレイ
４２…コントローラ
５…管理装置

Claims (14)

1. ホストコンピュータに対してデータストレージサービスを提供する少なくとも１つのストレージサブシステムと、
   前記少なくとも１つのストレージサブシステムを管理する管理装置と、を備えるストレージシステムであって、
   前記少なくとも１つのストレージサブシステムは、
   複数の論理ボリュームを形成した複数のハードディスクドライブを含むディスクアレイと、
   前記ホストコンピュータからのアクセス要求に基づいて、前記ディスクアレイに対するアクセスを制御するコントローラと、を備え、
   前記管理装置は、
   前記複数の論理ボリュームの一つである第１の論理ボリュームから前記複数の論理ボリュームの一つである第２の論理ボリュームへのデータの移行を定義した第１のタスクを登録した移行タスク情報と、
   前記第１のタスクについての少なくとも１つの移行先要件を登録した移行先要件情報と、を備え、
   前記管理装置は、前記移行タスク情報に登録された前記第１のタスクに従って、前記第１の論理ボリュームを有する前記少なくとも１つのストレージサブシステムのコントローラに対して、前記第１のタスクの実行を指示し、
   前記管理装置は、
   前記コントローラによる前記第１のタスクの実行が正常に終了しなかったと判断した場合に、前記移行先要件情報に基づいて、前記第２の論理ボリュームを代替する第３の論理ボリュームを前記複数の論理ボリュームから選択し、
   前記第１の論理ボリュームから前記第３の論理ボリュームへのデータの移行を定義した第２のタスクを前記移行タスク情報に登録し、
   前記移行タスク情報に登録された前記第２のタスクに従って、前記第１の論理ボリュームを有する前記少なくとも１つのストレージサブシステムのコントローラに対して、前記第２のタスクの実行を指示する、
   ことを特徴とするストレージシステム。
2. 前記少なくとも１つの移行先要件は、必須要件及び任意要件のいずれかであることを特徴とする請求項１記載のストレージシステム。
3. 前記管理装置は、前記第３の論理ボリュームが前記移行先要件情報に登録された任意要件のうち少なくとも１つの任意要件を満たしていないと判断する場合に、前記満たしていないと判断された任意要件をシステム管理者に提示するように構成されたことを特徴とする請求項２記載のストレージシステム。
4. 前記管理装置は、
   前記複数の論理ボリュームの一つである第４の論理ボリュームから前記複数の論理ボリュームの一つである第３の論理ボリュームへのデータの移行を定義した第３のタスクを前記移行タスク情報に格納し、
   前記第３の論理ボリュームが前記移行先要件情報に登録された必須要件を全て満たしていると判断する場合に、前記移行タスク情報に基づいて、前記第３のタスクを競合タスクとして特定し、
   前記競合タスクについての移行先要件を満たす第５の論理ボリュームを前記複数の論理ボリュームから選択し、
   前記競合タスクにおけるデータの移行先を前記特定した第５の論理ボリュームに変更する、
   ことを特徴とする請求項２記載のストレージシステム。
5. 前記管理装置は、
   前記第３の論理ボリュームが前記移行先要件情報に登録された必須要件のうち少なくとも１つの必須要件を全て満たしていないと判断する場合に、前記第１のタスクについての前記必須要件を全て満たす第６の論理ボリュームを前記複数の論理ボリュームから選択し、前記第３の論理ボリュームから前記第６の論理ボリュームへのデータの移行を定義した第４のタスクを前記移行タスク情報に登録する
   ことを特徴とする請求項２記載のストレージシステム。
6. 前記管理装置は、
   前記移行タスク情報に登録されたタスクのうち特定のタスクについての実行条件を定義したタスク実行条件情報を備え、
   前記第３のタスクについての実行条件を前記タスク実行条件情報に登録する、
   ことを特徴とする請求項５記載のストレージシステム。
7. 前記管理装置は、
   前記実行条件が満たされた場合に、前記第３の論理ボリュームを有する前記少なくとも１つのストレージサブシステムのコントローラに対して、前記第３のタスクの実行を指示する、
   ことを特徴とする請求項６記載のストレージシステム。
8. 前記タスク実行条件情報は、前記特定のタスクについての実行期限を含み、
   前記管理装置は、前記実行期限が経過するまで、前記実行条件が満たされたか否かを判断する、
   ことを特徴とする請求項７記載のストレージシステム。
9. 前記管理装置は、前記実行期限が経過するまでに、前記実行条件が満たされなかったと判断する場合に、前記第３の実行タスクが実行できなかった旨をシステム管理者に提示する、ことを特徴とする請求項８記載のストレージシステム。
10. 前記移行先要件は、論理ボリュームの属性に基づいて定義され、
    前記管理装置は、前記移行先要件と前記複数の論理ボリュームのそれぞれの属性とに基づいてスコアを算出し、前記算出したスコアが最も高い論理ボリュームを前記第３の論理ボリュームとして特定する、
    ことを特徴とする請求項２記載のストレージシステム。
11. 前記管理装置は、
    前記第３の論理ボリュームが前記移行先要件テーブルに登録された必須要件を全て満たしていると判断する場合に、前記移行タスク情報に基づいて、前記第３の論理ボリュームへのデータの移行を定義したタスクを競合タスクとして特定し、
    前記競合タスクについての移行先要件を満たす第４の論理ボリュームを前記複数の論理ボリュームから選択し、
    前記第３の論理ボリュームから前記特定した第４の論理ボリュームへのデータの移行を定義するタスクを前記移行タスクテーブルに登録する、
    ことを特徴とする請求項２記載のストレージシステム。
12. 前記ストレージシステムは、
    第１のストレージサブシステムと、
    ネットワークを介して前記第１のストレージサブシステムに接続された第２のストレージサブシステムと、を備え、
    前記第１のストレージサブシステムは、
    前記第２のストレージサブシステムの論理ボリュームにマッピングされた前記第１の論理ボリュームを有する、
    ことを特徴とする請求項１記載のストレージシステム。
13. 前記第１のストレージサブシステムは、前記ハードディスクドライブに対する電源供給を制御する電源制御部を備え、
    前記管理装置は、
    前記第１のタスク又は前記第２のタスクの実行後、前記第１の論理ボリュームを構成するハードディスクドライブが省電力モードになるように、前記電源制御部を制御する、
    ことを特徴とする請求項１２記載のストレージシステム。
14. ホストコンピュータに対してデータストレージサービスを提供する少なくとも１つのストレージサブシステムと、前記少なくとも１つのストレージサブシステムを管理する管理装置とを備えるストレージシステムにおけるデータ移行方法であって、
    前記管理装置が、第１の論理ボリュームから第２の論理ボリュームへのデータの移行を定義した第１のタスクを登録した移行タスク情報を保持するステップと、
    前記管理装置が、前記第１のタスクについての少なくとも１つの移行先要件を登録した移行先要件情報を保持するステップと、
    前記管理装置が、前記移行タスク情報に登録された前記第１のタスクに従って、前記第１の論理ボリュームを有する前記少なくとも１つのストレージサブシステムのコントローラに対して、前記第１のタスクの実行を指示するステップと、
    前記管理装置が、前記コントローラによる前記第１のタスクの実行が正常に終了しなかったと判断した場合に、前記移行先要件情報に基づいて、前記第２の論理ボリュームを代替する第３の論理ボリュームを特定するステップと、
    前記管理装置が、前記第１の論理ボリュームから前記第３の論理ボリュームへのデータの移行を定義した第２のタスクを前記移行タスク情報に登録するステップと、
    前記管理装置が、前記移行タスク情報に登録された前記第２のタスクに従って、前記第１の論理ボリュームを有する前記少なくとも１つのストレージサブシステムのコントローラに対して、前記第２のタスクの実行を指示するステップと、
    を含むことを特徴とするデータ移行方法。

Images