JP4690765B2 - ストレージ管理システム、ストレージ管理サーバ、データ再配置制御方法およびデータ再配置制御プログラム - Google Patents

Description

本発明は、ストレージ管理システムに関し、特に、ストレージ管理システムにより管理される記憶領域間でのデータの再配置を制御する技術に関する。

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

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

また、特許文献２には、あらかじめ、システム内のすべてのディスク装置を性能の観点からクラス分けし、かつ、各クラス間の性能順位を定義した上で、ディスク装置使用率の高い記憶領域内のデータを、より高性能なクラスに再配置することにより性能改善する方法について提案されている。その中で、再配置先として選択された高性能クラスに未使用領域が見つからなかった場合には、その高性能クラスからの低性能クラスへのデータの再配置を、高性能クラスへの再配置に先立って行うことにより、再配置に十分な未使用領域を確保するデータ再配置制御技術が開示されている。
特開２００１−６７１８７号公報（段落００３１〜００３５、図４、図５、図６） 特開２００３−１４０８３６号公報（段落００４６〜００５２、図３、図４）

前記の各特許文献には、ディスクの性能情報や利用情報に基づいて、一方のボリュームに記憶されているデータを他のボリュームにコピーさせ、データを再配置する技術が開示されている。
しかしながら、特許文献１に記載の技術では、各ボリューム単位に個別にデータを再配置する必要があり、また、ユーザが自由に定義したクラス間でボリュームを移動させることができず、使い勝手が悪い。また、特許文献２に記載の技術では、再配置先として選択されたクラスに十分な空き領域が残っていない場合には、そのクラスに分類されている領域のうち、ディスク装置使用率の低いものを、無条件に、より低性能なクラスに再配置する（以下、このような、より低性能なクラスへの再配置に限らず、再配置に必要な空き領域確保のための再配置を「追い出し」という）ことにより空き領域を確保するようにしている。このような、追い出し対象および追い出し先クラスの選択の仕方については、データの利用者からの指定ができなかったため、追い出し対象に選択されたデータの追い出し先として選択されたクラスが、そのデータの利用者が当初想定していたデータ配置先とは一致しなくなる可能性がある。

そこで、本発明の目的は、データの再配置先として選択されたクラスに十分な空き領域がなく、そのクラスに配置済みのデータを他のクラスに追い出す場合に、配置済みデータの利用者からの要求を含めて考慮して、追い出し対象および追い出し先クラスを選択する手段を提供することにある。さらに、本発明の目的は、より簡単な操作で、複数のストレージ装置に分散されたデータを再配置する手段を提供することにある。

前記課題を解決する本発明は、
少なくとも、
データを記憶するボリュームをそれぞれ１以上有する複数のストレージ装置と、
前記複数のストレージ装置の有するボリュームを仮想的に一元管理するボリューム仮想化装置と、
前記ストレージ装置内のボリューム間、または、前記複数のストレージ装置間のボリューム間におけるデータの再配置を管理するストレージ管理サーバと、
が接続されて構成されるストレージ管理システムであって、
前記ストレージ管理サーバが、
前記ボリュームそれぞれの属性を示すボリューム属性を管理するボリューム属性情報、前記ボリュームを前記ボリューム属性に関してクラス分けするための条件であるクラス分けポリシー、および、データの配置に関するユーザからの要求を管理するデータ配置ポリシーを含んで記憶する記憶部と、
予め前記ボリューム属性情報および前記クラス分けポリシーから前記ボリュームをクラス分けし、再配置対象データについての前記ユーザに指定されたクラスまたは前記データ配置ポリシーを満たすクラスに分類される再配置先ボリュームに、前記再配置対象データを再配置する制御部と、を備え、
前記制御部は、前記再配置対象データを再配置する処理として、
前記再配置対象データにおける前記再配置先ボリュームから空きのあるボリュームの数を取得し、
前記空きのあるボリュームの数が１つ以上のときには、その空きのあるボリュームに、前記再配置対象データを再配置し、
前記空きのあるボリュームの数が０のときには、前記ボリューム仮想化装置が管理するボリューム内の配置済みのデータから、その配置済みのデータについての再配置先ボリュームが配置済みのボリューム以外にも存在するデータを追い出し候補データとして選択し、前記追い出し候補データを新たな再配置対象データとして再配置することを特徴とする。
なお、ボリューム仮想化装置を設けない構成としてもよい。また、本発明は、ストレージ管理サーバ、データ再配置制御方法およびデータ再配置制御プログラムを含む。

本発明によれば、データの再配置先として指定されたクラスの空き領域不足に影響されないデータの再配置が可能となり、さらに、より簡単な操作で、複数のストレージ装置に分散されたデータを再配置することが可能となる。また、データの利用者からの要求に沿わないデータの再配置の抑止が可能となる。また、ある条件によっては、データの再配置を契機として、その再配置先として指定されたクラスに配置済みのデータの配置先が見直されるため、本来の再配置対象データ以外のデータに関する配置の最適化も可能となる。

以下、本発明を実施するための最良の形態について図面を参照して詳細に説明する。

≪システムの概念≫
図１は、本発明の実施の形態の全体概念を模式的に示す図である。以下に述べるように、本実施の形態のストレージ管理システムは、複数のストレージ装置を備えている。各ストレージ装置の有するボリュームは、仮想的に一元管理されている。ホスト（図２参照）は、複数のストレージ装置を全体として一つの仮想的なストレージ装置として認識する。

各ストレージ装置は、それぞれ１つ以上のボリュームを備えている。これら各ボリュームは、例えば、ハードディスクドライブや半導体メモリドライブ、光ディスクドライブなどの物理的な記憶ドライブにより提供される物理的な記憶領域上に設定される論理的な記憶領域である。
ここで、各ストレージ装置は、それぞれ同一種類のドライブを備えることもできるし、または、それぞれ異なる種類のドライブを混在させることもできる。従って、同一のストレージ装置内に位置するボリュームであっても、性能や価格などのボリューム属性がそれぞれ異なる場合がある。

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

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

各クラス１〜３には、複数のデータを配置することができ、それぞれのデータは、１つ以上の互いに関連するボリューム群に分割して格納することもできる。例えば、図１のデータ１は、クラス１に属する二つのボリュームＶ１、Ｖ２に格納されているデータを示す。これら各ボリュームＶ１、Ｖ２は、例えば、同一のアプリケーションプログラムにより使用されるデータを記憶するボリューム群や同一のファイルシステムを構成するデータを記憶するボリューム群などのような、互いに関連するボリュームである。

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

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

これにより、移動先のクラス３では、再配置対象データを構成する各ボリュームＶ１、Ｖ２のデータをそれぞれ記憶可能なボリュームを選択し、これら選択されたボリュームにデータをコピーする。コピー完了後に、移動元ボリュームＶ１、Ｖ２のデータは削除することができ、削除した場合には空きボリュームとして再利用される。

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

ボリューム間でのデータコピーを行うためには、ボリューム属性のすべてが、移動元ボリューム(Ｖ１、Ｖ２）と、移動先候補のボリュームとの間で一致している必要はなく、いくつかの属性が一致していれば十分である。一致する必要のある属性（以下「必須属性」という）としては、例えば、記憶容量とエミュレーションタイプとを挙げることができる。すなわち、移動元ボリュームと移動先ボリュームとは、最低限その記憶容量およびエミュレーションタイプが一致していなければ、データコピーが不可能である。ただし、記憶容量に関しては、同一またはそれ以上の記憶容量を有するボリュームであれば、移動先ボリュームとして選択することができる。

必須属性の一致するボリュームが必要数以上に検出された場合は、必須属性以外の他の属性の一致度を考慮し、より移動元ボリュームに近い属性を備えるボリュームを、移動先ボリュームとして選択することができる。一つの例として、ボリューム属性を必須属性とそれ以外の属性との二種類に大別したが、これに限らず、例えば、必須属性と、準必須属性と、その他の属性などのように、三種類以上の属性に分類し、各種類の属性に重みを付けて、ボリューム間の一致度を求める構成でもよい。

必須属性の一致するボリュームが全く検出されなかった場合は、移動先のクラス３に配置済みのデータの中から、追い出し候補データおよびその追い出し先クラスを決定する。そして、それに基づくデータの追い出しを実施することにより、再配置に十分な空き領域を確保することができる。また、追い出しの対象となったデータが、より適切なクラスに再配置されるという効果が発生することもある。これには、例えば、そのデータが当該ボリュームに格納された後に、ボリュームの構成が変更または拡張されてより適切なクラスのボリュームが新たに設定された場合が考えられる。

なお、前記のように各クラスを構成する条件によっては、一部のボリュームが複数のクラスに属する場合がある。換言すれば、複数のクラスの条件に重なる部分が存在する場合がある。例えば、クラス１およびクラス２の条件のいずれも満たすボリュームＸがあるとする。この場合、ボリュームＸのデータＹを別のクラス３のボリュームに移動することができるのは無論である。さらに、クラス１を含まないクラス２の部分、または、クラス２を含まないクラス１の部分に、データＹにとってより適切な配置となるボリュームがあれば、そのボリュームにデータＹを移動してもよい。

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

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

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

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

ＨＢＡ１２は、ストレージ装置とのデータ送受信を担当するもので、通信ネットワークＣＮ２を介して、ボリューム仮想化装置２０に接続されている。ここで、通信ネットワークＣＮ２としては、例えば、ＬＡＮ、ＳＡＮ（Storage Area Network）、インターネット、専用回線などを挙げることができる。オープン系ホストの場合は、例えば、ＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）、ＦＣＰ（Fibre Channel Protocol）、ｉＳＣＳＩ（internet Small Computer System Interface）などのプロトコルに基づいて、データ転送が行われる。メインフレーム系ホストの場合は、例えば、ＦＩＣＯＮ（Fibre Connection：登録商標）、ＥＳＣＯＮ（Enterprise System Connection：登録商標）、ＡＣＯＮＡＲＣ（Advanced Connection Architecture：登録商標）、ＦＩＢＡＲＣ（Fibre Connection Architecture：登録商標）などの通信プロトコルに従ってデータ転送が行われる。

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

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

仮想ボリュームと実ボリュームとのマッピングを制御することにより、ホスト１０に意識させることなく、実ボリューム間のデータ運用を行うことができる。例えば、図３（ｂ）に示すように、データの配置を改善するなどのために、実ボリューム（ＰＩＤ００１）に記憶されているデータを別の実ボリューム（ＰＩＤ００２）に移動させる場合には、これら実ボリューム間でデータをコピーした後、実ボリュームと仮想ボリュームとのマッピングを指定し直す。これによれば、ホスト１０には実ボリューム間のデータの移動を意識させずに済む。また、仮想ボリューム（ＬＩＤ００１）と仮想ボリューム（ＬＩＤ００２）との間で、識別情報（実ボリュームとの対応）を交換することにより、ホスト１０には、あたかも仮想ボリューム間でデータを入れ換えたように見せることができる。

このように、仮想化装置２０は、ストレージ装置上に存在する多種多様な実ボリュームを仮想化して一元的に管理し、ホスト１０に提供する。仮想化装置２０は、後記のように、ストレージ装置内に設けることもできる。さらに、仮想化装置２０とストレージ管理サーバ６０とを同一のコンピュータ上に設けることもできる。仮想化装置２０を設けることによって、ストレージ装置内だけでなく、複数のストレージ装置にわたるボリューム間のデータの移動を行うことができる。なお、仮想化装置２０を設けることなく、実ボリュームをそのままホスト１０に見せるような構成とすることもできる。この場合には、データの移動がストレージ装置内のボリューム間に限られる。

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

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

ストレージ管理サーバ６０は、ボリューム間でのデータの再配置などを管理するコンピュータシステムである。ストレージ管理サーバ６０の構成例は、さらに詳細を後記するが、例えば、データ再配置管理プログラム６３２、ボリュームデータベース６４０を備える。

図４は、ストレージ管理システムのハードウェア構成を概略的に示すブロック図であり、仮想化装置２０をストレージ装置として構成した場合を示す。
以下、本実施の形態では、仮想化装置２０を、第３ストレージ装置２０ともいう。第３ストレージ装置２０は、それぞれ後記するように、例えば、複数のチャネルアダプタ（以下「ＣＨＡ」という）２１０と、複数のディスクアダプタ（以下「ＤＫＡ」という）２２０と、キャッシュメモリ２３０と、共有メモリ２４０と、接続制御部２５０、２６０と、記憶部２７０と、ＳＶＰ（Service Processor）２８０とを含んで構成される。

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

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

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

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

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

接続制御部（スイッチ部）２５０は、各ＣＨＡ２１０と、各ＤＫＡ２２０と、キャッシュメモリ２３０と、共有メモリ２４０とをそれぞれ相互に接続するものである。これにより、すべてのＣＨＡ２１０、ＤＫＡ２２０は、キャッシュメモリ２３０および共有メモリ２４０にそれぞれ個別にアクセス可能となる。接続制御部２５０は、例えば、クロスバ・スイッチなどにより構成される。接続制御部２６０は、各ＤＫＡ２２０と記憶部２７０とをそれぞれ接続するためのものである。接続制御部２６０は、例えば、ファイバチャネルなどにより構成される。

記憶部２７０は、多数のディスクドライブ２７１を備えて構成される。記憶部２７０は、各ＣＨＡ２１０および各ＤＫＡ２２０などのコントローラ部分と共に同一の筐体内に設けることもできるし、コントローラ部分とは別の筐体内に設けることもできる。
記憶部２７０には、複数のディスクドライブ２７１を設けることができる。ディスクドライブ２７１としては、例えば、ＦＣディスク（ファイバチャネルディスク）、ＳＡＴＡ（Serial AT Attachment）ディスクなどを用いることができる。また、記憶部２７０は、同一種類のディスクドライブから構成される必要はなく、複数種類のディスクドライブを混在させることもできる。

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

ＳＶＰ２８０は、ＬＡＮなどの内部ネットワークＣＮ１１を介して、各ＣＨＡ２１０および各ＤＫＡ２２０とそれぞれ接続されている。図４では、ＳＶＰ２８０とＣＨＡ２１０とだけを接続しているが、ＳＶＰ２８０は、各ＤＫＡ２２０にもそれぞれ接続することができる。ＳＶＰ２８０は、ストレージ装置２０内の各種状態を収集し、そのままでまたは加工して、ストレージ管理サーバ６０に提供する。

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

第１ストレージ装置３０は、例えば、コントローラ３１０と、第３ストレージ装置２０と接続するための通信ポート３１１と、ディスクドライブ３２０とを備えて構成される。コントローラ３１０は、前記したＣＨＡ２１０およびＤＫＡ２２０の機能を実現するものであり、第３ストレージ装置２０およびディスクドライブ３２０とのデータ授受をそれぞれ制御する。

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

なお、本実施の形態では、物理的な記憶ドライブとして、ハードディスクドライブを例示するが、本発明はこれに限定されない。記憶ドライブとしては、ハードディスクドライブ以外に、例えば、半導体メモリドライブ、磁気テープドライブ、光ディスクドライブ、光磁気ディスクドライブなどを用いることができる。
第２ストレージ装置４０は、第１ストレージ装置３０と同様に、例えば、コントローラ４１０と、ディスクドライブ４２０と、ポート４１１とを備えて構成される。第２ストレージ装置４０は、第１ストレージ装置３０と同一の構成を備えてもよいし、異なる構成であってもよい。

図５は、ストレージ管理システムの論理的な記憶構造を示す図である。まず、第３ストレージ装置２０の構成を説明する。第３ストレージ装置２０の記憶構造は、物理的記憶階層と論理的記憶階層とに大別することができる。物理的記憶階層は、物理的なディスクであるＰＤＥＶ（Physical Device）２７１により構成される。ＰＤＥＶは、ディスクドライブに該当する。論理的記憶階層は、複数の（例えば２種類の）階層から構成される。一つの論理的階層は、ＶＤＥＶ（Virtual Device）２７２から構成される。他の一つの論理的階層は、ＬＤＥＶ（Logical Device）２７３から構成される。

ＶＤＥＶ２７２は、例えば、４個１組（３Ｄ+１Ｐ：３個のデータドライブと１個のパリティドライブ）、８個１組（７Ｄ＋１Ｐ：７個のデータドライブと１個のパリティドライブ）などのような所定数のＰＤＥＶ２７１をグループ化して構成される。グループに属する各ＰＤＥＶ２７１がそれぞれ提供する記憶領域が集合して一つのＲＡＩＤ記憶領域が形成される。このＲＡＩＤ記憶領域がＶＤＥＶ２７２となる。

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

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

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

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

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

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

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

図６は、ストレージ管理サーバの構成の概略を示すブロック図である。ストレージ管理サーバ６０は、例えば、通信部６１０と、制御部６２０と、メモリ６３０と、ボリュームデータベース６４０とを含んで構成される。

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

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

ボリュームデータベース６４０には、例えば、ボリューム属性管理テーブルＴ２と、クラス管理テーブルＴ３と、対応ホスト管理テーブルＴ４と、配置済みデータ管理テーブルＴ５と、ポリシー変換テーブルＴ６とが記憶されている。これら各テーブルＴ２〜Ｔ６の構成例は、さらに後記する。

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

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

図８は、ボリューム属性管理テーブルの構成を示す図である。ボリューム属性管理テーブルＴ２は、ストレージ管理システム１に分散する各ボリュームの属性情報を管理するためのものである。ボリューム属性管理テーブルＴ２は、例えば、仮想ボリュームごとに、その仮想ボリュームを特定する論理ＩＤと、その仮想ボリュームに対応付けられる実ボリュームの物理ＩＤと、ＲＡＩＤレベルと、エミュレーションタイプと、ディスク種別と、記憶容量と、使用状態と、ストレージ装置の機種とを対応付けることにより、構成される。

ここで、論理ＩＤとは、ボリューム仮想化装置２０がホスト１０に対して提供する論理ボリュームのＩＤである。物理ＩＤとは、各論理ボリュームに対応する実ボリュームの所在を示すＩＤである。物理ＩＤは、実ボリュームを格納しているストレージ装置の装置番号（装置＃）と、該ストレージ装置内におけるボリューム番号（Vol＃）から構成される。

また、ＲＡＩＤレベルとは、例えば、ＲＡＩＤ０、ＲＡＩＤ１、ＲＡＩＤ５などのＲＡＩＤ構成を示す情報である。エミュレーションタイプとは、ホストに見せるボリュームの種別を示す情報であり、例えば、オープン系ホストに提供されるボリュームと、メインフレーム系ホストに提供されるボリュームとでは、エミュレーションタイプが相違する。使用状態とは、そのボリュームが使用されているか否かを示す情報である。機種とは、そのボリュームの存在するストレージ装置の機種を示す情報である。

図９は、クラス管理テーブルの構成を示す図である。クラス管理テーブルＴ３は、例えば、クラス番号と、クラス名称と、そのクラスを定義づける条件式とを対応付けることにより、構成される。

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

検索条件により、所定の種別のディスクを所定のＲＡＩＤレベルで構成したボリュームを検出したり（例えば、「ＲＡＩＤレベル＝ＲＡＩＤ１ and ディスク種別＝ＦＣ」）、所定のストレージ装置に存在するボリュームを検出したりすることができる（例えば、「機種＝ＳＳ１」）。例えば、高信頼性クラス（＃１）では、高い信頼性を有するＦＣディスクによりＲＡＩＤ１で冗長化したボリュームが選択される。これにより、高信頼性クラスを、信頼性の高いボリュームから構成することができる。低コストクラス（＃２）では、安価なＳＡＴＡディスクをＲＡＩＤ５で冗長化したボリュームが選択される。これにより、低コストクラスを、比較的小容量の安価なボリュームから構成可能である。

高速応答クラス（＃３）では、高速応答が可能な機種に存在するディスクをストライピングした（ＲＡＩＤ０構成の）ボリュームが選択される。これにより、高速応答クラスを、Ｉ／Ｏ処理が早く、パリティ演算などの処理を必要としないボリュームから構成できる。アーカイブクラス（＃４）では、安価なＳＡＴＡディスクから構成され、かつ、所定容量未満の容量を有するボリュームが選択される。これにより、アーカイブクラスを、低コストのボリュームから構成することができる。

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

なお、実際にデータ再配置を行う際には、予めボリュームをクラス分けしておいてもよい。そのクラス分けを行うタイミングとしては、ボリューム構成の変更の後、各クラスに関するポリシーの指定の後、データ再配置の前、定期的なタイミングなどが考えられる。

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

図１１は、配置済みデータ管理テーブルの構成を示す図である。本実施の形態では、再配置対象データが１つ以上の互いに関連するボリューム群に分割して格納されるケースも想定し、互いに関連するボリューム群を、データを再配置する際の単位として設定できるようにしている。これにより、相互に関連する複数のボリュームに格納されたデータも一括して再配置できるようにしている。

配置済みデータ管理テーブルＴ５は、クラスに配置されているすべてのデータを管理するためのものであり、例えば、データ番号と、データ名称と、構成ボリュームＩＤと、現クラスと、データ容量と、データ配置ポリシーとを対応付けることにより、構成される。構成ボリュームＩＤは、データの格納先ボリュームを特定する論理ＩＤである。現クラスは、データが現在所属するクラスの名称である。データ容量は、データが格納されるボリュームの容量であり、データが複数のボリュームに格納されている場合には、その複数のボリュームの総容量である。データ配置ポリシーは、データが現クラスに配置された際にユーザにより指定されたポリシーであり、具体的には、データの配置に関するユーザからの要求を管理するものである。

データ名称は、ユーザが自由に設定することができる。また、各データは、例えば、同一のアプリケーションプログラムにより使用されるデータ群を記憶するボリューム、または、同一のファイルシステムを構成するデータ群を記憶するボリュームをグループ化したものとして位置付けることも可能である。

≪システムの処理≫
次に、ストレージ管理システムの処理について説明する。なお、以下の説明においては、適宜図２、図８、図１１、図１８を参照する。

図１２は、データ再配置の全体動作を簡略化して示す図である。以下、適宜図２を参照しながら説明する。データ再配置を行う場合、ユーザは、管理クライアント５０を介してストレージ管理サーバ６０にログインし、再配置させるデータおよび配置先のクラスをそれぞれ指定する（Ｓ１）。ストレージ管理サーバ６０は、その指定されたデータが格納されているボリュームのそれぞれについて移動先候補のボリュームを選択する（Ｓ２）。詳細はさらに後記するが、移動先候補ボリュームを選択する処理では、移動先として指定されたクラスに所属する全ボリュームのうち、移動元ボリュームのデータをコピー可能なボリュームが一つ選択される。

ストレージ管理サーバ６０による移動先候補ボリュームの選択結果は、例えば、ボリューム対応表Ｔ７のような形態でユーザに提示される（Ｓ３）。この例は、再配置の実行のために、他クラスへのボリューム追い出しを要する場合のボリューム対応表を示している。ボリューム対応表Ｔ７は、例えば、移動元ボリュームの論理ＩＤ（移動元ＩＤ）と、候補となる移動先ボリュームの論理ＩＤ（移動先候補ＩＤ）とを対応付けることにより、構成される。ユーザは、ストレージ管理サーバ６０から提示された再配置案（ボリューム対応表Ｔ７）を、ウェブブラウザ５１により確認する。ユーザがストレージ管理サーバ６０からの提案をそのまま承認する場合（ＯＫの場合）は、所定のタイミングに再配置が実行される（Ｓ４）。所定のタイミングには、ユーザが提案を承認したときや、ストレージ装置の稼働率が下がったときなどが考えられるが、ユーザが再配置を実行する時間帯を指定するようにしてもよい。

図１３は、移動先候補ボリュームを選択する処理を示すフローチャートであり、図１２の移動先候補選択処理（Ｓ２）を詳細化したものである。この処理は、例えば、ユーザが、再配置対象のデータおよび再配置先（移動先）のクラスを明示的に指定することにより、開始される（Ｓ２０２）。ここで、移動先のクラスを指定する代わりに、図１７に示す移動先ポリシー入力画面において、移動先に関するポリシー（データ配置ポリシー）を指定してもよい（Ｓ２０２）。その場合、ストレージ管理サーバ６０（データ再配置プログラム６３２）は、指定されたデータ配置ポリシーを最も満たすクラスを検索し、それを移動先クラスとして設定する。また、入力されたデータ配置ポリシーを、一時領域に保持する（Ｓ２０４）。なお、データ配置ポリシーを指定しない場合には、Ｓ２０４の処理をスキップする。

ストレージ管理サーバ６０（データ再配置プログラム６３２）は、移動元ボリュームのすべてについて、移動先候補ボリュームを選択済みか否かを判定する（Ｓ２０６）。ここでは、「ＮＯ」と判定されて、Ｓ２０８に移る。そして、ストレージ管理サーバ６０は、ボリューム属性管理テーブルＴ２（図８）を参照することにより、移動先として指定されたクラスに所属するボリューム群から、使用状況が「空き」であり、かつ、移動元ボリュームと必須属性の一致するボリュームを抽出する（Ｓ２０８）。なお、ボリューム属性管理テーブルＴ２またはその他のテーブルにおいて、予めボリュームをクラス分けしておいてもよい。また、移動先クラスが確定した時点で、Ｓ２０８のボリュームの抽出を行っておいてもよい。

次に、ストレージ管理サーバ６０は、必須属性が一致する空きボリュームとして検出されたボリュームの数を判定する（Ｓ２１０）。必須属性の一致する空きボリュームが一つ検出された場合は（Ｓ２１０の「１」）、そのボリュームを移動先候補ボリュームとして選択する（Ｓ２１２）。

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

必須属性の一致する空きボリュームが全く発見されなかった場合には（Ｓ２１０の「０」）、このままの状態では残りの移動元ボリューム（移動先候補ボリュームの選択されていない移動元ボリューム）が移動できないことを意味するので、移動先として指定されたクラスのボリュームに空きを作るために、そのクラスに配置済みのデータの中から、追い出し候補データを選択する（Ｓ２１６）。詳細はさらに後記するが、移動先として指定されたクラスに配置済みのデータの中から、他のクラスのポリシーにも適合するデータ配置ポリシーを持つものを探し出すことにより、追い出し対象データおよびその追い出し先クラスを決定し、その追い出し対象データの格納先ボリュームを移動先候補として選択できるようにする。さらに、追い出し対象データについての移動先候補のボリュームを選択する（Ｓ２１８）。

Ｓ２０８ないしＳ２１４の処理は、再配置対象データの格納先となっているすべてのボリュームについて、それぞれ実行される。そして、すべての移動元ボリュームについて、それぞれに対応する移動先候補ボリュームが選択された場合（Ｓ２０６：ＹＥＳ）、ストレージ管理サーバ６０は、ボリューム対応表Ｔ７（図１２参照）を生成してユーザに表示する（Ｓ２２０）。このボリューム対応表Ｔ７には、再配置対象データおよび追い出し対象データのそれぞれの格納先となっているすべてのボリュームに関する移動先候補ボリュームが提示される。これが、図１２のボリューム対応表の提示（Ｓ３）である。

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

図１４は、追い出し候補データを選択する処理を示すフローチャートであり、図１３の追い出し候補選択処理（Ｓ２１６）を詳細化したものである。この処理は、図１３の移動先候補ボリュームを選択する処理において、指定された移動先クラスに、必須属性の一致する空きボリュームが全くない場合に行われる。ここでは、データが１以上のボリュームからなるものとして説明する。

ストレージ管理サーバ６０（データ再配置管理プログラム６３２）は、再配置対象データに属するボリュームのうち、移動先候補が選択されていない（未決定である）ボリュームの総数（未割当てボリューム数）およびその総容量（未割当て総容量）を算出する（Ｓ２１６０２）。そして、ストレージ管理サーバ６０は、再配置先クラスに配置済みのすべてのデータについてチェックが完了したか否かを判定する（Ｓ２１６０４）。最初の処理では、「ＮＯ」と判定されて次のステップＳ２１６０６に移る。

まず、追い出し対象となり得るか否かを判断するために、データのボリューム数および総容量が、それぞれ、未割当てボリューム数および未割当て総容量を再配置するのに十分であるか否かをチェックする（Ｓ２１６０６）。そして、ボリューム数および総容量が十分であれば（Ｓ２１６０６：ＹＥＳ）、Ｓ２１６０８に移る。十分でなければ（Ｓ２１６０６：ＮＯ）、Ｓ２１６０４に戻って、次のデータについてチェックを行う。

続いて、チェック中のデータに関するデータ配置ポリシーが条件式の形式で設定されているか否かを判定する（Ｓ２１６０８）。条件式の形式で設定されていない場合（Ｓ２１６０８：ＮＯ）、ポリシー変換テーブル（図１８）を参照しながら、条件式を組み立てる（Ｓ２１６１０）。例えば、図１７（ｂ）の移動先ポリシー入力画面６３２２から信頼性「高」が指定された場合には、図１８（ｂ）のポリシー変換テーブルＴ６２により、「ディスク種別＝ＦＣ and ＲＡＩＤレベル＝ＲＡＩＤ１」という条件式が組み立てられる。条件式の形式で設定されている場合（Ｓ２１６０８：ＹＥＳ）、または、条件式の組み立て（Ｓ２１６１０）が完了した場合、ストレージ管理サーバ６０は、その条件式を満たし、かつ、チェック中のデータの再配置に十分な空きがあるクラスがあるか否かを検索する（Ｓ２１６１２）。条件を満たすクラスが検出できた場合（Ｓ２１６１４：ＹＥＳ）、チェック中のデータを追い出し候補データとし、Ｓ２１６１２で検出できたクラスを追い出し先候補クラスに決定し（Ｓ２１６１６）、処理を終了する。条件を満たすクラスが検出できなかった場合（Ｓ２１６１４：ＮＯ）、Ｓ２１６０４に戻って、次のデータについてチェックを行う。すべてのデータについてチェックしても、条件を満たすクラスが見つからなかった場合には（Ｓ２１６０４：ＹＥＳ）、追い出し不可の設定を行い（Ｓ２１６１８）、処理を終了する。

図１５は、再配置実行処理を示すフローチャートであり、図１２の再配置実行処理（Ｓ４）を詳細化したものである。ストレージ管理サーバ６０（データ再配置管理プログラム６３２）は、再配置対象データの再配置に関して追い出しが発生するか否か（追い出し対象データがあるか否か）を判定する（Ｓ４０２）。追い出しが発生する場合（Ｓ４０２：ＹＥＳ）、追い出し対象データに関する再配置実行処理を実行し（Ｓ４０４）、Ｓ４０６に移る。そして、ストレージ管理サーバ６０は、再配置対象データを構成するすべての移動元ボリュームについて再配置が完了したか否かを判定する（Ｓ４０６）。最初の処理では、「ＮＯ」と判定されて次のステップＳ４０８に移る。そして、移動元ボリュームに記憶されているデータを、その移動元ボリュームに対応する移動先ボリュームにコピーし（Ｓ４０８）、移動元ボリュームから移動先ボリュームにアクセスパスを切り換える（Ｓ４１０）。これにより、ホスト１０は、データ再配置を意識することなく、そのままの設定で所望のデータにアクセスすることができる。

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

このように、再配置対象データおよび追い出し対象データに属するすべてのボリュームについて、それぞれの記憶するデータが移動先ボリュームにコピーされ、アクセスパスが切り換えられる。そして、すべての移動元ボリュームについてデータ再配置が完了すると（Ｓ４０６：ＹＥＳ）、再配置指示の際に指定された移動先に関するポリシー（移動先クラスのポリシーまたはデータ配置ポリシー）を、配置済みデータ管理テーブルＴ５（図１１参照）に格納し（Ｓ４１６）、本処理は終了する。

図１６は、ボリューム対応表の具体例（データ再配置の計画案を提示する画面例）を示す図である。ストレージ管理サーバ６０による移動先候補ボリュームの選定結果（ボリューム対応表Ｔ７）は、図１６に示すように、移動元ボリューム（Source）および移動先候補ボリューム（Target）を上下２段に配置することにより、例えば、管理クライアント５０のウェブブラウザ５１に表示される。移動元ボリュームおよび移動先ボリュームのそれぞれについて、例えば、その論理ＩＤ、その所属するＲＡＩＤグループ番号、ＲＡＩＤレベル、エミュレーションタイプ、記憶容量などの属性を併せて表示することができる。また、移動先候補ボリュームへのデータ移行に関して、配置済みのデータの追い出しを伴う場合には、それも併せて表示する。例えば、追い出しの有無を、「＊」などのマークで示すことも可能である。また、追い出し対象ボリュームについても、その移動先ボリュームを同様に表示可能である。
ユーザは、図１６の画面を確認することにより、データ再配置を実行させるか否かを判断することができる。

図１７は、移動先クラスを指定する代わりに、移動先に関するポリシー（データ配置ポリシー）を指定するための移動先ポリシー入力画面を示す。図１７（a）に示す移動先ポリシー入力画面６３２０は、記憶容量（Capacity）、エミュレーションタイプ（Emulation Type）、ＲＡＩＤレベル（RAID Level）、ドライブの種別（Disk Type）といった個々のボリューム属性を指定させるタイプの画面例である。図１７（ｂ）に示す移動先ポリシー入力画面６３２２は、例えば、ハードウェアに関する知識が豊富でないユーザや、個々のボリューム属性をあまり意識することなく移動先を指定したいユーザ向けに、記憶容量（Capacity）、ＯＳ種別、信頼性、性能といった、運用観点による要求を指定させるタイプの画面例である。移動先ポリシー入力画面６３２２の各データ項目に入力されたデータは、図１８に示すようなポリシー変換テーブルにより、ボリューム属性に置き換えられる。

図１８は、ポリシー変換テーブルの構成例を示す図である。図１８（ａ）は、移動先ポリシー入力画面６３２２に入力されたＯＳ種別に対する要求を、エミュレーションタイプに対応付けるための、ＯＳ種別に関するポリシー変換テーブルＴ６１の構成を示している。各ＯＳ種別に対してエミュレーションタイプ（ＥＭＵ１、ＥＭＵ２）が対応付けられている。図１８（ｂ）は、移動先ポリシー入力画面６３２２に入力された信頼性に対する要求を、ディスク種別およびＲＡＩＤレベルに対応付けるための、信頼性に関するポリシー変換テーブルＴ６２の構成を示している。性能の分類である「高」、「中」および「低」に対してディスク種別（ＦＣ、ＳＡＴＡ）およびＲＡＩＤレベル（ＲＡＩＤ１、ＲＡＩＤ５）が対応付けられている。図１８（ｃ）は、移動先ポリシー入力画面６３２２に入力された性能に対する要求を、ストレージ装置の機種に対応付けるための、性能に関するポリシー変換テーブルＴ６３の構成を示している。性能の分類である「高」、「中」および「低」に対してストレージ装置の機種（ＳＳ１〜ＳＳ８）が対応付けられている。

以上本発明の実施の形態について説明したが、図２に示すハードウェアのそれぞれで実行されるプログラム（データ再配置制御プログラムを含む）をコンピュータによる読み取り可能な記録媒体に記録し、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより、本発明の実施の形態に係るストレージ管理システムが実現されるものとする。なお、それらのプログラムをインターネットなどのネットワーク経由でコンピュータシステムに提供するようにしてもよい。

以上本発明について好適な実施の形態について一例を示したが、本発明は前記実施の形態に限定されず、本発明の趣旨を逸脱しない範囲で適宜変更が可能である。

本発明の実施の形態の全体概念を示す図である。 ストレージ管理システムの全体構成を示すブロック図である。 ストレージ管理システムに分散するボリュームを仮想化して管理する様子を示す図である。 ストレージ管理システムのハードウェア構成を示すブロック図である。 ストレージ管理システムの論理的な記憶構造を示す図である。 ストレージ管理サーバの構成を示すブロック図である。 マッピングテーブルの構成を示す図である。 ボリューム属性管理テーブルの構成を示す図である。 クラス管理テーブルの構成を示す図である。 対応ホスト管理テーブルの構成を示す図である。 配置済みデータ管理テーブルの構成を示す図である。 データ再配置の全体動作を示す図である。 移動先候補選択処理を示すフローチャートである。 追い出し候補選択処理を示すフローチャートである。 再配置実行処理を示すフローチャートである。 データ再配置の計画案を提示する画面例を示す図である。 移動先に関するポリシーを指定するための画面例を示す図であり、（ａ）は個々のボリューム属性を指定させるタイプの画面例であり、（ｂ）は運用観点での要求を指定させるタイプの画面例である。 ポリシー変換テーブルの構成例を示す図であり、（ａ）はＯＳ種別に関するポリシー変換テーブルであり、（ｂ）は信頼性に関するポリシー変換テーブルであり、（ｃ）は性能に関するポリシー変換テーブルである。

符号の説明

１ ストレージ管理システム
２０ ボリューム仮想化装置
３０ 第１ストレージ装置（ストレージ装置）
３３０ 論理ボリューム（ボリューム）
４０ 第２ストレージ装置（ストレージ装置）
４３０ 論理ボリューム（ボリューム）
６０ ストレージ管理サーバ
６２０ 制御部
６４０ ボリュームデータベース（記憶部）
Ｔ２ ボリューム属性管理テーブル（ボリューム属性情報）
Ｔ３ クラス管理テーブル（クラス分けポリシー）
Ｔ５ 配置済みデータ管理テーブル（データ配置ポリシー）

Claims (8)

1. 少なくとも、
   データを記憶するボリュームをそれぞれ１以上有する複数のストレージ装置と、
   前記複数のストレージ装置の有するボリュームを仮想的に一元管理するボリューム仮想化装置と、
   前記ストレージ装置内のボリューム間、または、前記複数のストレージ装置間のボリューム間におけるデータの再配置を管理するストレージ管理サーバと、
   が接続されて構成されるストレージ管理システムであって、
   前記ストレージ管理サーバは、
   前記ボリュームそれぞれの属性を示すボリューム属性を管理するボリューム属性情報、前記ボリュームを前記ボリューム属性に関してクラス分けするための条件であるクラス分けポリシー、および、データの配置に関するユーザからの要求を管理するデータ配置ポリシーを含んで記憶する記憶部と、
   予め前記ボリューム属性情報および前記クラス分けポリシーから前記ボリュームをクラス分けし、再配置対象データについての前記ユーザに指定されたクラスまたは前記データ配置ポリシーを満たすクラスに分類される再配置先ボリュームに、前記再配置対象データを再配置する制御部と、を備え、
   前記制御部は、前記再配置対象データを再配置する処理として、
   前記再配置対象データにおける前記再配置先ボリュームから空きのあるボリュームの数を取得し、
   前記空きのあるボリュームの数が１つ以上のときには、その空きのあるボリュームに、前記再配置対象データを再配置し、
   前記空きのあるボリュームの数が０のときには、前記ボリューム仮想化装置が管理するボリューム内の配置済みのデータから、その配置済みのデータについての再配置先ボリュームが配置済みのボリューム以外にも存在するデータを追い出し候補データとして選択し、前記追い出し候補データを新たな再配置対象データとして再配置することを特徴とする
   ストレージ管理システム。
2. 少なくとも、
   データを記憶するボリュームを１以上有するストレージ装置と、
   前記ストレージ装置内のボリューム間におけるデータの再配置を管理するストレージ管理サーバと、
   が接続されて構成されるストレージ管理システムであって、
   前記ストレージ管理サーバは、
   前記ボリュームそれぞれの属性を示すボリューム属性を管理するボリューム属性情報、前記ボリュームを前記ボリューム属性に関してクラス分けするための条件であるクラス分けポリシー、および、データの配置に関するユーザからの要求を管理するデータ配置ポリシーを含んで記憶する記憶部と、
   予め前記ボリューム属性情報および前記クラス分けポリシーから前記ボリュームをクラス分けし、再配置対象データについての前記ユーザに指定されたクラスまたは前記データ配置ポリシーを満たすクラスに分類される再配置先ボリュームに、前記再配置対象データを再配置する制御部と、を備え、
   前記制御部は、前記再配置対象データを再配置する処理として、
   前記再配置対象データにおける前記再配置先ボリュームから空きのあるボリュームの数を取得し、
   前記空きのあるボリュームの数が１つ以上のときには、その空きのあるボリュームに、前記再配置対象データを再配置し、
   前記空きのあるボリュームの数が０のときには、前記ボリューム仮想化装置が管理するボリューム内の配置済みのデータから、その配置済みのデータについての再配置先ボリュームが配置済みのボリューム以外にも存在するデータを追い出し候補データとして選択し、前記追い出し候補データを新たな再配置対象データとして再配置することを特徴とする
   ストレージ管理システム。
3. 前記記憶部は、前記データ配置ポリシーが運用観点による要求である場合に、そのデータ配置ポリシーを前記ボリューム属性に変換するポリシー変換テーブルを記憶し、
   前記制御部は、前記ポリシー変換テーブルに従って、前記データ配置ポリシーを前記ボリューム属性に変換し、その変換後のボリューム属性から前記クラスを特定する
   ことを特徴とする請求項１または請求項２に記載のストレージ管理システム。
4. データを記憶するボリュームをそれぞれ１以上有する複数のストレージ装置に接続され、前記ストレージ装置内のボリューム間、または、前記ストレージ装置間のボリューム間におけるデータの再配置を管理するストレージ管理サーバであって、
   前記ボリュームそれぞれの属性を示すボリューム属性を管理するボリューム属性情報、前記ボリュームを前記ボリューム属性に関してクラス分けするための条件であるクラス分けポリシー、および、データの配置に関するユーザからの要求を管理するデータ配置ポリシーを含んで記憶する記憶部と、
   予め前記ボリューム属性情報および前記クラス分けポリシーから前記ボリュームをクラス分けし、再配置対象データについての前記ユーザに指定されたクラスまたは前記データ配置ポリシーを満たすクラスに分類される再配置先ボリュームに、前記再配置対象データを再配置する制御部と、を備え、
   前記制御部は、前記再配置対象データを再配置する処理として、
   前記再配置対象データにおける前記再配置先ボリュームから空きのあるボリュームの数を取得し、
   前記空きのあるボリュームの数が１つ以上のときには、その空きのあるボリュームに、前記再配置対象データを再配置し、
   前記空きのあるボリュームの数が０のときには、前記ボリューム仮想化装置が管理するボリューム内の配置済みのデータから、その配置済みのデータについての再配置先ボリュームが配置済みのボリューム以外にも存在するデータを追い出し候補データとして選択し、前記追い出し候補データを新たな再配置対象データとして再配置することを特徴とする
   ストレージ管理サーバ。
5. データを記憶するボリュームを１以上有するストレージ装置に接続され、前記ストレージ装置内のボリューム間におけるデータの再配置を管理するストレージ管理サーバであって、
   前記ボリュームそれぞれの属性を示すボリューム属性を管理するボリューム属性情報、前記ボリュームを前記ボリューム属性に関してクラス分けするための条件であるクラス分けポリシー、および、データの配置に関するユーザからの要求を管理するデータ配置ポリシーを含んで記憶する記憶部と、
   予め前記ボリューム属性情報および前記クラス分けポリシーから前記ボリュームをクラス分けし、再配置対象データについての前記ユーザに指定されたクラスまたは前記データ配置ポリシーを満たすクラスに分類される再配置先ボリュームに、前記再配置対象データを再配置する制御部と、を備え、
   前記制御部は、前記再配置対象データを再配置する処理として、
   前記再配置対象データにおける前記再配置先ボリュームから空きのあるボリュームの数を取得し、
   前記空きのあるボリュームの数が１つ以上のときには、その空きのあるボリュームに、前記再配置対象データを再配置し、
   前記空きのあるボリュームの数が０のときには、前記ボリューム仮想化装置が管理するボリューム内の配置済みのデータから、その配置済みのデータについての再配置先ボリュームが配置済みのボリューム以外にも存在するデータを追い出し候補データとして選択し、前記追い出し候補データを新たな再配置対象データとして再配置することを特徴とする
   ストレージ管理サーバ。
6. 少なくとも、
   データを記憶するボリュームをそれぞれ１以上有する複数のストレージ装置と、
   前記複数のストレージ装置の有するボリュームを仮想的に一元管理するボリューム仮想化装置と、
   前記ストレージ装置内のボリューム間、または、前記複数のストレージ装置間のボリューム間におけるデータの再配置を管理するストレージ管理サーバと、
   が接続されて構成されるストレージ管理システムによるデータ再配置制御方法であって、
   前記ストレージ管理サーバは、
   前記ボリュームそれぞれの属性を示すボリューム属性を管理するボリューム属性情報、前記ボリュームを前記ボリューム属性に関してクラス分けするための条件であるクラス分けポリシー、および、データの配置に関するユーザからの要求を管理するデータ配置ポリシーを含んで記憶する記憶部と、
   予め前記ボリューム属性情報および前記クラス分けポリシーから前記ボリュームをクラス分けし、再配置対象データについての前記ユーザに指定されたクラスまたは前記データ配置ポリシーを満たすクラスに分類される再配置先ボリュームに、前記再配置対象データを再配置する制御部と、を備え、
   前記制御部は、前記再配置対象データを再配置する処理として、
   前記再配置対象データにおける前記再配置先ボリュームから空きのあるボリュームの数を取得し、
   前記空きのあるボリュームの数が１つ以上のときには、その空きのあるボリュームに、前記再配置対象データを再配置し、
   前記空きのあるボリュームの数が０のときには、前記ボリューム仮想化装置が管理するボリューム内の配置済みのデータから、その配置済みのデータについての再配置先ボリュームが配置済みのボリューム以外にも存在するデータを追い出し候補データとして選択し、前記追い出し候補データを新たな再配置対象データとして再配置することを特徴とする
   データ再配置制御方法。
7. 少なくとも、
   データを記憶するボリュームを１以上有するストレージ装置と、
   前記ストレージ装置内のボリューム間におけるデータの再配置を管理するストレージ管理サーバと、
   が接続されて構成されるストレージ管理システムによるデータ再配置制御方法であって、
   前記ストレージ管理サーバは、
   前記ボリュームそれぞれの属性を示すボリューム属性を管理するボリューム属性情報、前記ボリュームを前記ボリューム属性に関してクラス分けするための条件であるクラス分けポリシー、および、データの配置に関するユーザからの要求を管理するデータ配置ポリシーを含んで記憶する記憶部と、
   予め前記ボリューム属性情報および前記クラス分けポリシーから前記ボリュームをクラス分けし、再配置対象データについての前記ユーザに指定されたクラスまたは前記データ配置ポリシーを満たすクラスに分類される再配置先ボリュームに、前記再配置対象データを再配置する制御部と、を備え、
   前記制御部は、前記再配置対象データを再配置する処理として、
   前記再配置対象データにおける前記再配置先ボリュームから空きのあるボリュームの数を取得し、
   前記空きのあるボリュームの数が１つ以上のときには、その空きのあるボリュームに、前記再配置対象データを再配置し、
   前記空きのあるボリュームの数が０のときには、前記ボリューム仮想化装置が管理するボリューム内の配置済みのデータから、その配置済みのデータについての再配置先ボリュームが配置済みのボリューム以外にも存在するデータを追い出し候補データとして選択し、前記追い出し候補データを新たな再配置対象データとして再配置することを特徴とする
   データ再配置制御方法。
8. コンピュータに請求項６または請求項７に記載のデータ再配置制御方法を実行させることを特徴とするデータ再配置制御プログラム。

Images