JP6270827B2 - データ・マイグレーションのための方法、システム、およびコンピュータ・プログラム - Google Patents

Description

本発明は、概して、コンピュータに関し、より詳細には、コンピューティング・ストレージ環境で記憶性能を高めるための方法、システム、およびコンピュータ・プログラムに関する。

コンピュータおよびコンピュータ・システムは、今日の社会のさまざまな場所で見受けられる。コンピューティング環境およびネットワークは、家庭、職場、学校、政府機関、およびその他の場所で見受けられる可能性がある。コンピューティング環境は、ユーザに示されるローカルのインターフェースから遠隔にある場合が多い１つまたは複数のストレージ環境にデータを記憶することがますます増えている。

これらのコンピューティング・ストレージ環境は、協調して働くことが多いディスク・ドライブなどの多くのストレージ・デバイスを使用して大量のデータを記憶し、取り出し、更新し、そして、それらのデータは、それらのデータを要求または送信するホスト・コンピュータに与えられる可能性がある。場合によっては、いくつかのデータ・ストレージ・サブシステムが、単一のデータ・ストレージ・システムとして集合的に管理される。これらのサブシステムは、いくつかの処理ユニットまたは処理ユニットのクラスタを組み合わせるホスト「シスプレックス（ｓｙｓｐｌｅｘ）」（システム・コンプレックス）構成によって管理される可能性がある。このように、さまざまな種類のストレージ・デバイスを含むことが多いマルチ・ティア／マルチ・システム・コンピューティング環境が、大量のデータを組織化し、処理するために使用される可能性がある。

データ・マイグレーションの必要性は、さまざまな理由により生じるすべてのデータ・センターにおける現実的な必要性である。そのようなデータ・マイグレーションは、アプリケーションに対して透過的（つまり、付随するダウンタイムがアプリケーションに対して０）でなければならない。今日、データ・マイグレーションは、ホストまたはストレージ・コントローラにインストールされたストレージ仮想化ソフトウェアによって提供される機能である。しかしながら、本手法では、アプリケーションは、ストレージ・コントローラによって調整されるデータ・マイグレーションについて、データのどの部分が新しい記憶位置にマイグレーションされなければならないかの制御を実施することができない。ホストに基づくマイグレーション・ソリューションは、データのどの部分がマイグレーションされなければならないかの制御をアプリケーションに許すための包括的なインターフェースを提供しない。また、ホストに基づくマイグレーション・ソリューションは、データ・マイグレーションを成し遂げるためにデータをホストに移動し、またデータをホストから移動しなければならないという欠点も持つ。この制御は、論理装置名（ＬＵＮ：Ｌｏｇｉｃａｌ Ｕｎｉｔ Ｎａｍｅ）全体、またはより包括的には通常のストレージ・ユニットよりも、ずっと細かいレベルでのデータ・マイグレーションを必要とする可能性があるデータベースなどのアプリケーションにとって有益である。その代わりに、さらに説明されるように、多くの場合、データ・マイグレーションの決定が、アプリケーションの知識なしに行われる。このことは、元来鋭いピークを持つ重い作業負荷が今日のストレージ・コントローラ内で利用可能な標準的な監視メカニズムによって検出され得ないために、そのようなデータの移動のためのピーク性能の必要性が既になくなった可能性がある後にマイグレーションが調整される状況を生じ得る。したがって、アプリケーションの要求に応じて、ストレージの細かな部分がストレージ・コントローラによってマイグレーションされ得るメカニズムに対する必要性が存在する。

したがって、以上のことを考慮して、コンピューティング環境でプロセッサによって論理装置名（ＬＵＮ）よりも細かいデータ・マイグレーションを実行するためのさまざまな実施形態が提供される。一実施形態においては、単なる例として、そのようなＬＵＮよりも細かいデータ・マイグレーションのための方法が開示される。指定されたサイズのデータをＬＵＮの裏側の物理的なストレージから新しい物理的な位置にマイグレーションするためにストレージ・コントローラと所有するアプリケーションとの間のインターフェースとして使用するためのソース・コードに基づく仕様が実装される。

上述の例示的な実施形態に加えて、さまざまなシステムおよびコンピュータ・プログラムの実施形態が提供され、関連する利点を提供する。

本発明の利点が容易に理解されるために、上で簡潔に説明された本発明のより詳細な説明が、添付の図面において図示される特定の実施形態を参照することによってなされる。これらの図面が本発明の典型的な実施形態を示すに過ぎず、したがって、本発明の範囲を限定すると見なされるべきでないことを理解した上で、本発明が、添付の図面を用いてさらに具体的かつ詳細に示され、説明される。

本発明の態様を実装し得る例示的なマルチ・ティア・データ・ストレージ・コンピューティング環境を示すブロック図である。 ＬＵＮよりも細かいレベルのデータ・マイグレーションを実行するための従来の方法のブロック図である。 本発明の態様が実施され得るＬＵＮよりも細かいレベルのデータ・マイグレーションを実行するための例示的な方法のブロック図である。 やはり本発明の態様が実施され得るＬＵＮに関する仮想・物理マッピング（ｖｉｒｔｕａｌ−ｔｏ−ｐｈｙｓｉｃａｌ ｍａｐｐｉｎｇ）を変更するための例示的な方法の第１のステップのブロック図である。 ここでもやはり本発明の態様が実施され得る、図４に既に示された仮想・物理マッピングを変更するための例示的な方法の第２のステップのブロック図である。 ＬＵＮよりも細かいレベルのデータ・マイグレーションを実行するための例示的な方法の流れ図である。 ＬＵＮよりも細かいレベルのデータ・マイグレーションを実行するためのさらなる例示的な方法の流れ図である。 ＬＵＮよりも細かいレベルのデータ・マイグレーションを実行するためのさらなる例示的な方法の流れ図である。 ＬＵＮよりも細かいレベルのデータ・マイグレーションを実行するためのさらなる例示的な方法の流れ図である。 ＬＵＮよりも細かいレベルのデータ・マイグレーションを実行するためのさらなる例示的な方法の流れ図である。 ＬＵＮよりも細かいレベルのデータ・マイグレーションを実行するためのさらなる例示的な方法の流れ図である。

上述のように、データ・マイグレーションの必要性は、さまざまな理由により生じるすべてのデータ・センターにおける現実的な必要性である。そのような場合の例は、（ａ）アクティブに使用されるストレージ・アレイのリースの満了による、データを１つのストレージ・アレイから別のストレージ・アレイに移動する必要性、（ｂ）使用頻度の比較的低いデータを比較的下層のティアのストレージにマイグレーションする必要性、および（ｃ）組織の成長による必要性を満たすための高性能および大容量のストレージ・アレイへのアップグレードを含む。データ・マイグレーションは、所有するアプリケーションに対して透過的でなければならず、付随するダウンタイムは、所有するアプリケーションに対して０でなければならない。

重ねて、上述のように、今日のデータ・マイグレーションは、Ｌｉｎｕｘ（Ｒ）互換環境のためのＬｏｇｉｃａｌ Ｖｏｌｕｍｅ Ｍａｎａｇｅｒ（ＬＶＭ）およびＶｅｒｉｔａｓ（Ｒ）Ｖｏｌｕｍｅ Ｍａｎａｇｅｒなどのホストにインストールされたストレージ仮想化ソフトウェアによって提供され、ストレージ・コントローラ（例えば、ＩＢＭ（Ｒ）Ｓｙｓｔｅｍ Ｓｔｏｒａｇｅ ＤＳ８００またはＳｔｏｒｗｉｚｅ（Ｒ）Ｖ７０００）およびネットワーク・ストレージ・バーチャライザ（例えば、ＩＢＭ（Ｒ）ＳＡＮ Ｖｏｌｕｍｅ Ｃｏｎｔｒｏｌｌｅｒ（ＳＶＣ））によって容易にされる機能である。一例においては、サイズ１ＴＢのＬＵＮに関するデータをマイグレーションする必要性が存在する場合、ＬＵＮ全体が、現在使用中である１ＴＢのバックエンド・ストレージからサイズ１ＴＢの新しいストレージにマイグレーションされる。したがって、本手法においては、特定のＬＵＮに記憶されたデータ全体が、新しい位置にマイグレーションされる。

しかしながら、本手法では、データのどの部分が新しい記憶位置にマイグレーションされなければならないかの制御を実施することができない。これは、ＬＵＮ全体よりもずっと細かいレベルでデータをマイグレーションする必要がある可能性があるデータベースなどのアプリケーションにとって有用である。以下の例を考える。所有するアプリケーション、この場合、データベース（すなわち、Ｏｒａｃｌｅ（Ｒ））が、所与のテーブルのデータがもはや頻繁にアクセスされないので、単一のテーブル（またはレコード）のみを現在のストレージから新しい記憶位置にマイグレーションすることを望む。アプリケーションによって制御されるＬＵＮのこの種の部分的なデータ・マイグレーションは、ストレージ・バーチャライザによって提供される従来のマイグレーション方法では不可能である。

ＬＵＮよりも細かいレベルでデータをマイグレーションすることが可能である場合、通常、ストレージ・コントローラのレベルでデータ・アクセス・パターンを監視し、分析することによって、そのようなマイグレーションに取りかかる決定が行われる。ストレージ・コントローラはデータの意味（ｓｅｍａｎｔｉｃｓ）の知識を持たないので、例えば、ピーク性能の必要性が既になくなったときにマイグレーションがトリガされ得る可能性がある。どのデータがいつマイグレーションされなければならないかに関する最も早い決定を行うことができる適用可能なレイヤは、当該データを生成するアプリケーションである。したがって、アプリケーションの認識およびアプリケーションに基づく意思決定の問題は、既存のソリューションによって対処されないままになっている。

いくつかの従来の技術は、ＬＵＮよりも細かいレベルのデータ・マイグレーションの課題に対処しようと試みる。第１に、（ストレージ・アレイとしても知られる）ストレージ・コントローラが、アプリケーションに対して透過的にデータをＬＵＮに関連する物理的なストレージから別の物理的なストレージにマイグレーションする限られた能力を提供する。しかし、そのようなマイグレーションはＬＵＮ全体に対して行われ、したがって、アプリケーションが特定のＬＵＮに記憶したデータの一部だけのマイグレーションを必要とする状況にプロセスが適さないものとなる。加えて、ストレージ・コントローラは、通常、同じベンダーに関連するデバイスの間でのみデータ・マイグレーションを可能にし、それによって、ベンダーの固定化を促進し、費用が高くなるかまたはその他の点でリソースを大量に消費するようになりがちである。

第２に、ホストで実行されるストレージ仮想化ソフトウェアが、ディスク・アレイのベンダーにまたがる範囲に及ぶ可能性があるデータ・マイグレーションのユース・ケース（ｕｓｅ ｃａｓｅ）を提供し、したがって、ベンダーの固定化を促進しない。しかし、従来の仮想化ソフトウェアは、ＬＵＮ全体のデータを１つの物理的なストレージから別の物理的なストレージにマイグレーションする。これは、従来の仮想化ソフトウェアが、ＬＵＮよりも細かいレベルでデータをマイグレーションすることを必要とするソフトウェアに関して課題を突きつけることを意味する。

第３に、独自仕様のボリューム管理および（例えば、データベース・ファイルのための）ファイル・システム・ソフトウェアが、異なる物理的なストレージにまたがるＬＵＮよりも細かいベルのデータの移動を可能にする。しかし、そのようなデータ・マイグレーションは、同時に使用される物理的なストレージからホストにデータが読み出されることを必要とし、ホストから、データが、新しいストレージに書き込まれる。このプロセスは、データ・マイグレーションのためのストレージ・ネットワークの帯域幅とホストの中央演算処理装置（ＣＰＵ）の帯域幅との両方を消費し、そのことは、ネットワークまたはサーバあるいはその両方の性能を低下させる。加えて、そのような独自仕様のソフトウェアは、特定のベンダーに基づく実装に対してベンダーに固有である。

上述の技術とは対照的に、例示される実施形態のメカニズムは、ストレージ仮想化ソフトウェアによって公開されたアプリケーション・プログラム・インターフェース（ＡＰＩ）が、ＬＵＮよりも細かいレベルでの現在の物理的なストレージから新しい位置へのデータ・マイグレーションをアプリケーションがトリガすることを可能にする技術を示す。これらのメカニズムを使用することによって、アプリケーションは、仮想ディスク上のデータのチャンクの開始ＬＢＡ（論理ブロック・アドレス）およびサイズと、データがマイグレーションされなければならない物理的なストレージを特定するマイグレーション先の物理的なストレージの記述とを指定することを許される。このＡＰＩ呼び出しを受信すると、ストレージ仮想ソフトウェアは、データを、そのデータの現在の記憶位置から指定されたマイグレーション先の記憶位置にアプリケーションから透過的にマイグレーションする。動作が完了すると、ストレージの仮想ディスク・マップ（ｖｉｒｔｕａｌ ｄｉｓｋ ｍａｐ）が、データの新しい位置を指すようにアトミックに修正される。古い物理的なデータ記憶位置は、解放される。このＡＰＩは、新しいＳＣＳＩコマンドの形態で明示されるか、またはＸＣＯＰＹのような既存のＳＣＳＩコマンドを使用する可能性がある。ＡＰＩのその他のアウト・オブ・バンド（ｏｕｔ−ｏｆ−ｂａｎｄ）の明示も、あり得る。

例示される実施形態のメカニズムは、以下のことを含むいくつかの利点をもたらす。第１に、ストレージ仮想化ソフトウェアによって公開されたＬＵＮよりも細かいレベルのマイグレーションＡＰＩが、アプリケーションがＬＵＮ内のデータの一部を１つの物理的なストレージから別の物理的なストレージにマイグレーションすることを可能にすることができる。これは、アプリケーションが、そのアプリケーションの必要性に応じて個々のレコード、テーブル、またはテーブル空間を新しい物理的なストレージにマイグレーションすることを可能にする。結果として、アクセスされる頻度が比較的低いテーブル／レコードが、比較的安価なストレージを消費する比較的下層のティアのストレージに移動される可能性があり、またはアクセスされる頻度が非常に高いデータが、比較的高いＩＯＰの要件を満たすことができる比較的上層のティアのストレージに移動される可能性がある。

第２に、さまざまな独自仕様のボリューム・コントローラなどのストレージ・エリア・ネットワーク（ＳＡＮ）内のストレージ・バーチャライザによって公開されたＬＵＮよりも細かいレベルのマイグレーションＡＰＩが、データ全体をホストに読み出し、次にデータを新しいストレージに書き込む必要なしにデータを１つの物理的なストレージから別の物理的なストレージにマイグレーションすることを可能にする。これは、ストレージ・ネットワークの帯域幅を節約し、データ・マイグレーションを調整するためにホストＣＰＵサイクルを使用することを防止する。

第３に、ＬＵＮよりも細かいレベルのマイグレーションが、ユース・ケースに応じて特定のＬＵＮ上のデータのどの部分がその他の物理的なストレージにマイグレーションされなければならないかを決定するための制御能力をアプリケーションに与える。アプリケーションは、そのアプリケーションのデータに関連する意味について完全な知識を有するので、いつどのデータを移動すべきかに関する最も早く最良の決定を行う可能性が高い。

第４に、ストレージ・コントローラによって行われるＬＵＮよりも細かいマイグレーションが、さまざまなベンダーのアプリケーションのためになる。ホストで実行されるその他のアプリケーションは、そのようなＡＰＩからやはり利益を得る可能性がある。最後に、ストレージ仮想化ソフトウェアによって行われるＬＵＮよりも細かいレベルのマイグレーションによって、アプリケーションが、データが置かれるストレージの性能およびコストに基づいて、異なる種類のストレージにデータを記憶する現在の必要性に即座に反応する能力を高めることができる。ストレージ仮想化ソフトウェアが「ホットスポット（ｈｏｔｓｐｏｔ）」マイグレーションについての決定を行うためにデータ・アクセス・パターンを監視する必要がある場合、マイグレーションの恩恵は、遅延の後に（おそらくはより高い性能の必要性がなくなった時点で）のみ感じられる可能性がある。

以下の説明において、本明細書の一部をなし、本発明のいくつかの実施形態を示す添付の図面に対する参照がなされる。本発明の範囲を逸脱することなく、その他の実施形態が利用される可能性があり、構造および動作の変更が行われる可能性があることが理解される。図１は、本発明の態様が実装され得るコンピューティング・ストレージ環境を示す。複数のホスト・システム２ａ、２ｂ．．．２ｎが、ストレージ・ボリューム２８、３０、および３２へのアクセスを管理するストレージ・コントローラ６を通じて１つまたは複数のストレージ・ボリューム２８、３０、および３２に入力／出力（Ｉ／Ｏ）要求を送信する。特定の実装において、ストレージ・ボリュームは、Ｊｕｓｔ ａ Ｂｕｎｃｈ ｏｆ ｄｉｓｋｓ（ＪＢＯＤ）として編成された複数のハード・ディスク・ドライブ、ＲＡＩＤアレイ、直接アクセス記憶装置（ＤＡＳＤ）、ＳＳＤ、テープ・デバイスなどから物理的に構成される可能性がある。

（多くの場合、複雑な関係で物理的に構成される可能性がある）いくつかの物理的または論理的ボリュームを示す代わりに、いくつかの仮想ボリューム２２、２４、および２６がホスト・システム２ａ、２ｂ．．．２ｎに示される。ホスト・システム２ａ、２ｂ．．．２ｎは、プロトコル・スタックのさまざまなレイヤでＴＣＰ／ＩＰ、ファイバ・チャネル、イーサネット（Ｒ）などの複数の通信プロトコルを使用してインターネット、ストレージ・エリア・ネットワーク（ＳＡＮ）、イントラネット、ローカル・エリア・ネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡＮ）などのネットワーク８を介してストレージ・コントローラ６と通信することができる。

ストレージ・コントローラ６は、ストレージ・コントローラの動作を行うためのコード１２を実行するプロセッサ１０を含む。ストレージ・コントローラ６は、キャッシュ・システム１４と、バッテリーのバックアップを受けるメモリ・デバイスなどの不揮発性ストレージ・ユニット１６とをさらに含む。ストレージ・コントローラ６は、仮想ストレージ・ボリューム２２、２４、および２６（ならびにそれによってボリューム２８、３０、および３２）に書き込むべきホスト２ａ、２ｂ．．．２ｎから受信されたデータ更新と、ホスト２ａ、２ｂ．．．２ｎに返すべきボリューム２８、３０、および３２から読み出されたデータとをキャッシュ１４に記憶する。高速書き込み（Ｆａｓｔ Ｗｒｉｔｅ）モードで動作するときは、ホスト２ａ、２ｂ．．．２ｎから受信されたデータ更新が、キャッシュ１４とＮＶＳ１６との両方にコピーされる。更新がキャッシュ１４とＮＶＳ１６との両方にコピーされた後、終了ステータスが、データ更新を送信するホスト２ａ、２ｂ．．．２ｎに返される。

ストレージ・コントローラ６は、ストレージ・コントローラ６とホスト２ａ、２ｂ．．．２ｎで動作している所有するアプリケーションとの間のインターフェースとして使用するためのソース・コードに基づく仕様も含む。示された実施形態において、この仕様／インターフェースは、アプリケーション・プログラミング・インターフェース（ＡＰＩ）１７として表される。ＡＰＩ１７は、さらに説明されるように、ストレージ・コントローラ６によってホスト２ａ、２ｂ．．．２ｎと、特に、ホスト２ａ、２ｂ．．．２ｎで動作している所有するアプリケーションとに示される。さらに、ストレージ・コントローラ６は、やはりさらに説明されるように、例示される実施形態の目的を達成するためにＡＰＩ１７と連携して動作し得るストレージ仮想化エンジン１８も含む。

キャッシュ・システム１４は、仮想ディスク・マップ１５、または略して「ストレージ・マップ」１５を含む。キャッシュ・システム１４は、ホスト２ａ、２ｂ．．．２ｎまたは同様のデバイスからの書き込みデータを受け入れ、次いで、書き込みデータはキャッシュ・メモリに置かれる。一実施形態において、ストレージ・マップ１５は、物理的なボリューム２８、３０、および３２を仮想ボリューム２２、２４、２６などに結びつけるためのデータの物理・仮想マッピング（ｐｈｙｓｉｃａｌ−ｔｏ−ｖｉｒｔｕａｌ ｍａｐｐｉｎｇ）を含む。

図１は、当業者が理解するであろうように、既に示されたストレージ・コントローラ６などのいくつかの相互に関連する構成要素を有するより大きなマルチ・システム／マルチ・クラスタ・ストレージ環境の一部を示す可能性がある。既に示されたように、仮想ボリューム２２、２４、および２６はホスト・システム２ａ、２ｂ．．．２ｎを介してユーザに示されるが、基礎をなす物理的な構成は多くのあり得る形態をとる可能性がある。例えば、ＳＳＤ、ＳＡＴＡ、ＨＤＤ、テープなどのさまざまな部類のいくつかの相互に関連するストレージ・デバイスが、特定の構成に応じてストレージ・ボリューム２８、３０、および３２を構成する可能性がある。

プロセッサ１０などのストレージ環境のさまざまな構成要素が、本発明および特許請求される主題の態様を実装するように適合され得る。例えば、ストレージ仮想化エンジン１８は、仮想ディスク・マップ１５と併せて仮想化機能を提供するなど、さらに説明されることになるさまざまな機能を実行するためにプロセッサ１０と連携して動作することができる。同様に、ＡＰＩも、プロセッサ１０、またはストレージ環境で動作しているその他の構成要素と連携して動作することができる。当業者は、その他のさまざまなデータ処理およびメモリ構成要素がこれらの態様を実現するように実装される可能性があり、ストレージ・コントローラ６またはその他の場所で動作する可能性があることを理解するであろう。

本発明の一実施形態において、ストレージ・コントローラ６は、ホスト２ａ、２ｂ．．．２ｎで動作しているアプリケーションから透過的に、指定されたサイズのデータをＬＵＮの裏側の物理的なストレージ（例えば、２８、３０、３２）から新しい物理的な位置にマイグレーションするためのＡＰＩ１７を提供する。このＡＰＩ１７は、特定のデータだけを、そのデータを記憶するために使用されるＬＵＮを邪魔せずに１つの物理的な位置から別の物理的な位置にマイグレーションするためにデータベース（Ｏｒａｃｌｅ（Ｒ）またはＤＢ２）のようなアプリケーションによって呼び出される可能性がある。

所有するアプリケーションによる使用のために提供される一部の例示的なＡＰＩは、以下を含む。
migrate(sourceLUN #, startLBA, size, targetstorage pool)

このＡＰＩによって、ストレージ仮想化ソフトウェアは、マイグレーションされたデータが置かれなければならないマイグレーション先の位置を選択する。マイグレーション先のストレージ・プールの選択はアプリケーションによってなされ、マイグレーション先のストレージ・プール上のデータの位置がストレージ仮想化ソフトウェアに残される。
migrate(sourceLUN #, startLBA, size,targetLUN #, targetLBA)

このＡＰＩを使用して、アプリケーションは、データがマイグレーションされなければならないマイグレーション先のＬＵＮおよび厳密な位置を制御する。したがって、データをマイグレーションしながらアプリケーションによって完全な制御が実施される。
migrate(sourceLUN #, startLBA, targetstorage pool id) migrate(sourceLUN #, startLBA, targetLUN #, targetLBA)

ＡＰＩ呼び出しの上記の明示で、各ＡＰＩ呼び出しに関してマイグレーションされるストレージのサイズは決まっており、つまり、実装に応じて例えば１２８ｋまたは２５６ｋである。呼び出し元は、必要とされるサイズのデータをマイグレーションするためにＡＰＩを複数回呼び出さなければならない。
migrate(sourceLUN #, startLBA, size,targetLUN #, targetLBA, time)

上記ＡＰＩ呼び出しでは、アプリケーションは、マイグレーション元のＬＵＮからマイグレーション先のＬＵＮへのデータ・マイグレーションを要求するだけでなく、マイグレーション動作が実行されなければならない時間を示す。実装の困難を緩和するために、一実施形態においては、開始ＬＢＡおよびマイグレーション先ＬＢＡならびにサイズ・パラメータが、特定のアラインメント（例えば、１ＧＢのエクステント）に制限される可能性があることに留意されたい。注：実装の困難を緩和するために、開始ＬＢＡおよびマイグレーション先ＬＢＡならびにサイズ・パラメータを特定のアラインメント、例えば、ＤＳ８０００の１ＧＢのエクステントに制限する必要がある可能性がある。

上述のデータの移動のためのいくつかの例示的なユース・ケースが、以下で与えられる。第１の例においては、所有するアプリケーションが、特定のレコードまたはデータベース・テーブルを、所与のＬＵＮ上の現在位置から、電力の消費がより少なく、リソースの消費がより少ないより下層のティアのストレージにマイグレーションすることを望む。これは、比較的古い（あまりアクセスされない）データを長期保存のためによりコスト対効果の高いストレージに移動する必要性によってトリガされる可能性がある。例えば、この動作は、データを、すべてのファイバ・チャネル（ＦＣ）ディスクを１５ｋ ＲＰＭで動作させるコストの高いストレージ・アレイから、ＳＡＴＡディスクをずっと低いＲＰＭで動作させるよりコストのかからないストレージ・アレイにマイグレーションする。そのような場合、データ・マイグレーションＡＰＩは、システム・ボリューム・コントローラ（ＳＶＣ）などのＳＡＮ内のストレージ仮想化要素の影響を受け、アプリケーションのマイグレーション要求に影響を与える。

第２の例においては、所有するアプリケーションが、所与のレコードが頻繁にアクセスされることを発見する。したがって、アプリケーションは、この領域を性能のより高いストレージのティア（例えば、ソリッド・ステート・ドライブ（ＳＳＤ）ティアまたは１５ｋ ＲＰＭドライブ・プール）にマイグレーションすることを望む。この種のユース・ケースは、ストレージ・コントローラ内でアプリケーションに制御された「ホットスポット」マイグレーションを容易にすることができる。

ここで、上で検討されたデータ・マイグレーションＡＰＩは、そのような目的のために有用であるが、データベース・アプリケーションなどの特定の種類のアプリケーションに限定されないことに留意されたい。当業者は、ＡＰＩが、メール・サーバまたはその他の仮想化アプリケーションなどの、データをマイグレーションする必要性のある任意の所有するアプリケーションに適用できる可能性があることを理解するであろう。

上述のＡＰＩのさまざまな実施形態は、特定の用途に適したさまざまな方法で実装され得る。例えば、ＡＰＩは、小型コンピュータ・システム・インターフェース（ＳＣＳＩ：ｓｍａｌｌ ｃｏｍｐｕｔｅｒ ｓｙｓｔｅｍｓ ｉｎｔｅｒｆａｃｅ）を介して所有するアプリケーションにインラインで提供される可能性がある。別の例において、ＡＰＩは、インターネット・プロトコル（ＩＰ）を介して所有するアプリケーションにアウト・オブ・バンドで提供される可能性がある。当業者は、示されたＡＰＩの異なる実装が特定の状況に対して必要に応じて使用される可能性があることを理解するであろう。

一実施形態においては、上述のデータ・マイグレーションＡＰＩの機能をサポートするストレージ・コントローラで、１組の例示的なステップが、マイグレーション要求を満足するために行われ得る。

第１に、データ・マイグレーションＡＰＩをサポートするストレージ・コントローラが、ストレージ・コントローラによってサポートされるストレージ・プールのリストを、それらのストレージ・プールの性能、冗長性、および電力消費の特徴とともに公開する。この情報は、例えば、モード・センス（Ｍｏｄｅ Ｓｅｎｓｅ）小型コンピュータ・システム・インターフェース（ＳＣＳＩ）コマンドを介して利用できるようにされ、データ・マイグレーションのためのマイグレーション先のストレージ・プールを選択するためにストレージ・コントローラによって使用され得る。

第２に、所与のｓｔａｒｔＬＢＡ＝ＳＬＢＡ１およびｓｉｚｅ＝ＳＺ１から始まるデータが、（例えば、高性能でコストの高い１５ｋ ＲＰＭドライブからなる）そのデータの現在の位置から（例えば、コストがより低く、エネルギー効率のよい７．２ｋ ＲＰＭドライブからなる）異なるストレージ・プールにマイグレーションされることを要求する上述のＳＣＳＩコマンド（または別の実施形態においては、例えば、マイグレーションＡＰＩの呼び出しのモードに応じたアウト・オブ・バンド・コマンド）が、ストレージ仮想化ソフトウェアによって受信される。

第３に、ストレージ仮想化ソフトウェアが、次いで、マイグレーション先のストレージ・プールでこの選択されたデータ・チャンクに「最も適する場所（ｂｅｓｔ ｆｉｔ）」を決定する。そして、ストレージ仮想化ソフトウェアは、バックグラウンドで（アプリケーションから透過的に）データを現在の位置からマイグレーション先の位置にコピーする。

第４に、仮想ディスク・マップが、次いで、ＬＵＮのその部分だけが今やよりコストの低いストレージにあるように、自動的に、新しい物理的な位置を指すようにされる。この動作中に、すべてのその他のマイグレーションの動作と同様に、データは、一貫性があり、最新であるように保たれる。

第５に、新しい物理的な記憶位置を反映するようにマップが自動的に変更されると、マイグレーション動作がコミットされる。ＡＰＩがマイグレーション先の物理的なディスクとデータを置くべき場所とを指定する場合、ストレージ・コントローラは、ストレージ・コントローラが指定されたマイグレーション先のプール上の新しいマイグレーション先の位置を選択する代わりに、アプリケーションによって指定された新しい位置にデータをマイグレーションすることは、覚えておく価値がある。

ここで図２に目を向けると、従来のデータ・マイグレーション・メカニズム２００のブロック図が示されている。それぞれのデータ・パス、コマンド・パス、およびコマンド応答パスが、示された矢印および対応する凡例によって、アプリケーション・レベルで示される。第１のステップとして、所有するアプリケーション／ユーティリティが、（ここではＦＣ １５ｋ ＲＰＭドライブとして示される）物理的なディスク１から（ここではよりコストの安いシリアル接続ＳＣＳＩ（ＳＡＳ） ７ｋ ＲＰＭドライブとして示される）物理的なディスク２にデータをマイグレーションするためのコマンドを物理的なディスク１に送信する。次に、コマンドの応答が、物理的なディスク１（つまり、物理的なディスク１を担当するストレージ・コントローラ）からユーティリティ／所有するアプリケーションに返される。示されるように、それから、データが、ホストに引き出され、次いで、物理的なディスク２上の新しい位置に書き戻される。この場合は、実行するためにストレージ帯域幅およびサーバ・リソースを消費する。

図２とは対照的に、以下の図３〜４は、本発明による例示的な実施形態を示す。例えば、以下の図３においては、上述のように実行されたＡＰＩを使用するスマートなＬＵＮよりも細かいレベルのデータ・マイグレーションのためのメカニズムが示される。

図３〜４は、例えば、ＡＰＩがどのように実行されるかと、ストレージ帯域幅およびサーバの能力を消費する、データをディスクからホストに引き出し、その後、データをマイグレーション先の位置に書き込む、既に図２に示されたメカニズムなどの従来のメカニズムによって提供されるデータ・マイグレーション・メカニズムと比較した利点とを示す。対照的に、以下の図３においては、メカニズム３００が、本発明の態様が組み込まれ得る、ＬＵＮよりも細かいデータ・マイグレーションのための例示的な方法を示す。特に図３を参照すると、一実施形態において、マイグレーションＡＰＩの呼び出しは、ホストのローカルのアプリケーションによって実行されるが、データ・マイグレーションの動作は、ストレージ・コントローラによって実行される。（その他のアプリケーションを含む）その他の独自仕様の従来のデータ・マイグレーション・メカニズムがどのデータをいつマイグレーションすべきかを決定する一方、マイグレーション動作は、ホストを関与させずにストレージ・バーチャライザによって実行される。

図３は、示される実施形態において、ＬＵＮよりも細かいデータ・マイグレーションが本発明にしたがってどのように実行されるかを示す。ＡＰＩを使用し、示される例示的なコマンドを使用して、データベース・アプリケーションは、ＬＵＮよりも細かいレベルのデータを（この場合はＦＣ １５ｋドライブとして示される）物理的なディスク１から（示された実施形態では示されたストレージ・プール内に構成されたＳＡＳ ７ｋ ＲＰＭドライブからなる）示されたＰＨＹディスク１、２、および３のストレージ・プールＰ１内の第２の物理的な位置にマイグレーションするための例示的なコマンドを送信する。コマンドは、ホスト（およびそれによってデータベース・アプリケーション）に返される。データベース・アプリケーションがどのデータをいつマイグレーションするべきかに関する決定を行う一方、マイグレーション動作自体はホストの関与なしにストレージ・バーチャライザ（例えば、ストレージ仮想化エンジン１８、図１）によって実行される。したがって、示されるように、データは、アプリケーションの代わりに（ＳＶＣなどの）バーチャライザがアプリケーションに対する負担となるオーバーヘッドなしにマイグレーションを実行することを可能にすることによってインテリジェントにマイグレーションされる。そのとき、データは、データ・パスによって示されるように、物理的なディスク１からストレージ・プールＰ１にマイグレーションされる。

ここで以下の図４および５に目を向けると、選択されたＬＵＮに関する仮想・物理マッピングに適用される例示的な動作のブロック図が、上述のＡＰＩによって容易にされるデータ・マイグレーション・メカニズムに応じて示される。これらの図の物理的なディスクは、実際には、基礎をなすストレージ・コントローラによって示される仮想ボリューム（例えば、ＲＡＩＤ５ボリューム）である可能性があることに留意されたい。一実施形態において、示された仮想・物理マッピングは、仮想ディスク・マップ１５（図１）として実装される可能性がある。しかし、当業者が理解するであろうように、そのようなマッピングのさまざまな実装は、特定のアプリケーションに適するように行われる可能性がある。

最初に図４に目を向けると、第１のステップ４００Ａにおいて、（ここに示された０からｎまでアドレスを振られた）初期ＬＵＮアドレス範囲マップが、示されるように物理的なディスク１のアドレス範囲に対応すると特定される。第２のステップ４００Ｂにおいて、図５に示されるように、マイグレーション先のストレージ・プールへのデータのチャンクのマイグレーション動作が完了した後、マイグレーションされたデータのチャンクに対応する物理的なディスク２内のマイグレーション先のストレージ・プールを指すように構成される範囲ｘ〜ｙを有する新しいＬＵＮアドレス範囲マップが生成される。範囲０〜ｘおよびｙ〜ｎは、示されるように、物理的なディスク１を指すように維持される。

以下の図６は、本発明の態様が実施され得る、コンピューティング・ストレージ環境においてＬＵＮよりも細かいレベルのデータ・マイグレーションを実行するための例示的な方法６００の流れ図である。方法６００は、指定されたＬＵＮよりも細かいレベルのサイズのデータをＬＵＮの裏側の物理的なストレージから新しい物理的な位置にマイグレーションするためにストレージ・コントローラと所有するアプリケーションとの間のインターフェースとして使用するためのソース・コードに基づく仕様を実装する（ステップ６０４）ことによって始まる（ステップ６０２）。それから、方法６００は終了する（ステップ６０６）。

以下の図７は、ここでもやはり本発明のさまざまな態様が実施され得る、マイグレーション元の記憶位置からマイグレーション先の記憶位置へのＬＵＮよりも細かいレベルのデータ・マイグレーションを実行するためのさらなる例示的な方法７００の流れ図である。方法７００は、仮想ディスク上のデータのチャンクの開始ＬＢＡおよびサイズと、マイグレーション先の物理的なストレージの記述とを指定する（ステップ７０４）ことによって始まる（ステップ７０２）。次いで、ソース・コードに基づく仕様（例えば、ＡＰＩ）が、ストレージ・コントローラによってサポートされるストレージ・プールのリストを、基礎をなすストレージ（例えば、ＳＡＳドライブ）のサイズ、利用可能な空間、物理的な特徴などの少なくとも１つのストレージの特徴とともに公開する（ステップ７０６）。

ステップ７０６から得られた情報に少なくとも部分的に基づいて、方法７００は、開始ＬＢＡからのデータおよび指定されたサイズのデータのチャンクが公開されたストレージ・プールのリストのうちのマイグレーション先のストレージ・プールにマイグレーションされることを要求する（例えば、ホストからの）呼び出しをインターフェースを介して受信することによって継続する（ステップ７０８）。次いで、ストレージ・コントローラまたは同様のストレージ・デバイスが、マイグレーション先のストレージ・プール内でデータのチャンクに「最も適する場所」を決定することができる（ステップ７１０）。例えば、データのチャンクは、１つの物理的なボリューム上に連続的に記憶される可能性があり、または状況が許し得るときには、やはりストレージ・コントローラまたはその他の管理デバイスの裁量で複数のボリュームに分けられる可能性がある。

次のステップとして、マイグレーション動作は、指定されたデータのチャンクがアプリケーションに対するオーバーヘッドを含まずにバックグラウンド・プロセスとしてマイグレーション先のストレージ・プールにマイグレーションされるときに始まる（つまり、プロセスは、所有するアプリケーションに対して透過的に行われる）（ステップ７１２）。マイグレーション動作が完了した後、仮想ディスク・マップが、マイグレーション先のストレージ・プール上の新しい物理的な位置を指すようにされる（ステップ７１４）。仮想ディスク・マップに変更が行われると、マイグレーション動作がコミットされる（ステップ７１６）。それから、方法７００は終了する（ステップ７１８）。

以下の図８は、本発明の別の実施形態による、マイグレーション元の記憶位置からマイグレーション先の記憶位置へのＬＵＮよりも細かいレベルのデータ・マイグレーションを実行するためのさらなる例示的な方法８００を示す。方法８００は、新しいストレージ・プールにマイグレーションされるべきデータのマイグレーション・サイズを指定する（ステップ８０４）ことによって始まる（ステップ８０２）。次に、マイグレーションされるべきデータ・チャンクのサイズが、指定される（ステップ８０６）。合計マイグレーション・サイズが、複数の既に指定されたデータ・チャンクのサイズの倍数を切り上げたものとして指定される（ステップ８０８）。

次に、方法８００は、合計マイグレーション・サイズが０以上であるかどうかを問い合わせるステップ８１０に移る。０以上でない場合、方法８００は終了する（ステップ８２６）。あるいは、方法８００は、マイグレーション動作がデータ・チャンクのサイズずつ実行されるステップ８１２に移る。マイグレーション動作８１２は、開始ＬＢＡからのデータおよび指定されたサイズのデータのチャンクがマイグレーションされることを要求する呼び出しをＡＰＩを介して受信すること（ステップ８１４）、データ・チャンクに最も適する場所を決定すること（ステップ８１６）、バックグラウンド・プロセスとしてマイグレーション先のストレージ・プールにデータ・チャンクをマイグレーションすること（ステップ８１８）、仮想ディスク・マップが新しい物理的な記憶位置を指すようにすること（ステップ８２０）、ならびにマイグレーション動作をコミットすること（ステップ８２２）などの、図７に既に示されたステップの少なくとも一部と同様の機能を含む。

方法８００がマイグレーション動作８１２の実行を始めるとき、合計マイグレーション・サイズが、マイグレーションされているデータ・チャンクの分だけ減らされる（ステップ８２４）。方法８００は、合計マイグレーション・サイズが０以上であるかどうかを再び問い合わせるためにステップ８１０に戻る。ここで、答えが肯定的である場合、方法８００は終了し（ステップ８２６）、そうでない場合、ステップ８１２に戻って、データ・チャンクのサイズずつ再び行われるさらなるマイグレーション動作を実行する。

ここで以下の図９に目を向けると、マイグレーション元の記憶位置からマイグレーション先の記憶位置へのＬＵＮよりも細かいレベルのデータ・マイグレーションを実行するためのさらなる例示的な方法９００が示される。方法９００は、マイグレーション元のＬＵＮ、開始ＬＢＡ、合計マイグレーション・サイズ、マイグレーション先のＬＵＮ、およびマイグレーションされるべきデータ・チャンクのサイズを指定する（ステップ９０４）ことによって始まる（ステップ９０２）。次に、方法９００は、マイグレーション動作が実行されるべき時間を指定する（ステップ９０６）。以下のステップ９０８において、指定された時間が来た場合、以下でさらに説明されるようにマイグレーション動作９１０が実行される。あるいは、指定された時間が来ていない場合（やはりステップ９０８）、方法９００は、待機し（ステップ９１２）、ステップ９０８に戻って、再び問い合わせし直す。

ステップ９１０において、マイグレーション動作は、所有するアプリケーションに対して透過的なバックグラウンド・プロセスとしてマイグレーション先のストレージ・プールにデータをマイグレーションすること（ステップ９１４）、仮想ディスク・マップがマイグレーション先のストレージ・プール上の新しい物理的な位置を指すようにすること（ステップ９１６）、およびマイグレーション動作をコミットすること（ステップ９１８）を含む、図７および８に既に示されたのと同様の機能を実行する。それから、方法は終了する（ステップ９２０）。

以下の図１０は、マイグレーション元の記憶位置からマイグレーション先の記憶位置へのＬＵＮよりも細かいレベルのデータ・マイグレーションを実行するためのさらなる例示的な方法１０００を示す。方法１０００は、仮想ディスク上のデータのチャンクの開始ＬＢＡおよびサイズと、マイグレーション先の物理的なストレージの記述とを指定する（ステップ１００４）ことによって始まる（ステップ１００２）。次いで、ソース・コードに基づく仕様（例えば、ＡＰＩ）が、ストレージ・コントローラによってサポートされるストレージ・プールのリストを、基礎をなすストレージ（例えば、ＳＡＳドライブ）のサイズ、利用可能な空間、物理的な特徴などの少なくとも１つのストレージの特徴とともに公開する（ステップ１００６）。

ステップ１００６から得られた情報に少なくとも部分的に基づいて、方法１０００は、開始ＬＢＡからのデータおよび指定されたサイズのデータのチャンクが指定された時間に公開されたストレージ・プールのリストのうちのマイグレーション先のストレージ・プールにマイグレーションされることを要求する（例えば、ホストからの）呼び出しをインターフェースを介して受信することによって継続する（ステップ１００８）。次いで、ストレージ・コントローラまたは同様のストレージ・デバイスが、マイグレーション先のストレージ・プール内でデータのチャンクに「最も適する場所」を決定することができる（ステップ１０１０）。例えば、データのチャンクは、１つの物理的なボリューム上に連続的に記憶される可能性があり、または状況が許し得るときには、やはりストレージ・コントローラまたはその他の管理デバイスの裁量で複数のボリュームに分けられる可能性がある。

次のステップとして、マイグレーション動作は、指定された時間に、指定されたデータのチャンクがアプリケーションに対するオーバーヘッドを含まずにバックグラウンド・プロセスとしてマイグレーション先のストレージ・プールにマイグレーションされるときに始まる（つまり、プロセスは、所有するアプリケーションに対して透過的に行われる）（ステップ１０１２）。マイグレーション動作が完了した後、仮想ディスク・マップが、マイグレーション先のストレージ・プール上の新しい物理的な位置を指すようにされる（ステップ１０１４）。仮想ディスク・マップに変更が行われると、マイグレーション動作がコミットされる（ステップ１０１６）。それから、方法１０００は終了する（ステップ１０１８）。

以下の図１１は、マイグレーション元の記憶位置からマイグレーション先の記憶位置へのＬＵＮよりも細かいレベルのデータ・マイグレーションを実行するためのさらなる例示的な方法１１００を示す。方法１１００は、仮想ディスク上のデータのチャンクの開始ＬＢＡおよびサイズと、マイグレーション先の物理的なストレージの記述とを指定する（ステップ１１０４）ことによって始まる（ステップ１１０２）。次いで、ソース・コードに基づく仕様（例えば、ＡＰＩ）が、ストレージ・コントローラによってサポートされるストレージ・プールのリストを、基礎をなすストレージ（例えば、ＳＡＳドライブ）のサイズ、利用可能な空間、物理的な特徴などの少なくとも１つのストレージの特徴とともに公開する（ステップ１１０６）。

ステップ１１０６から得られた情報に少なくとも部分的に基づいて、方法１１００は、開始ＬＢＡからのデータおよび指定されたサイズのデータのチャンクが呼び出しの受信と同時に（すなわち、直ちに）公開されたストレージ・プールのリストのうちのマイグレーション先のストレージ・プールにマイグレーションされることを要求する（例えば、ホストからの）呼び出しをインターフェースを介して受信することによって継続する（ステップ１１０８）。次いで、ストレージ・コントローラまたは同様のストレージ・デバイスが、マイグレーション先のストレージ・プール内でデータのチャンクに「最も適する場所」を決定することができる（ステップ１１１０）。例えば、データのチャンクは、１つの物理的なボリューム上に連続的に記憶される可能性があり、または状況が許し得るときには、やはりストレージ・コントローラまたはその他の管理デバイスの裁量で複数のボリュームに分けられる可能性がある。

次のステップとして、マイグレーション動作は、指定された時間に、指定されたデータのチャンクがアプリケーションに対するオーバーヘッドを含まずにバックグラウンド・プロセスとしてマイグレーション先のストレージ・プールにマイグレーションされるときに始まる（つまり、プロセスは、所有するアプリケーションに対して透過的に行われる）（ステップ１１１２）。マイグレーション動作が完了した後、仮想ディスク・マップが、マイグレーション先のストレージ・プール上の新しい物理的な位置を指すようにされる（ステップ１１１４）。仮想ディスク・マップに変更が行われると、マイグレーション動作がコミットされる（ステップ１１１６）。それから、方法１１００は終了する（ステップ１１１８）。

当業者に理解されるであろうように、本発明の態様は、システム、方法、またはコンピュータ・プログラムとして具現化され得る。したがって、本発明の態様は、すべてハードウェアの実施形態、すべてソフトウェアの実施形態（ファームウェア、常駐ソフトウェア、マイクロコードなどを含む）、またはソフトウェアの態様とハードウェアの態様とを組み合わせる実施形態の形態をとる可能性があり、これらはすべて、概して本明細書において「回路」、「モジュール」、「プロセス」、もしくは「システム」と呼ばれることがある。さらに、本発明の態様は、コンピュータ可読プログラム・コードを具現化する１つまたは複数のコンピュータ可読媒体で具現化されたコンピュータ・プログラムの形態をとる可能性がある。

１つまたは複数のコンピュータ可読媒体の任意の組み合わせが、利用される可能性がある。コンピュータ可読媒体は、コンピュータ可読信号媒体またはコンピュータ可読ストレージ媒体である可能性がある。コンピュータ可読ストレージ媒体は、例えば、電子、磁気、光、電磁、赤外線、もしくは半導体のシステム、装置、またはデバイス、あるいはこれらの任意の好適な組み合わせである可能性があるがこれらに限定されない。コンピュータ可読ストレージ媒体のより詳細な例（非網羅的なリスト）は、以下、すなわち、１つもしくは複数の配線を有する電気的な接続、ポータブル・コンピュータ・ディスケット、ハード・ディスク、ランダム・アクセス・メモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、消去可能プログラマブル読み出し専用メモリ（ＥＰＲＯＭもしくはフラッシュ・メモリ）、光ファイバ、ポータブル・コンパクト・ディスク読み出し専用メモリ（ＣＤ−ＲＯＭ）、光ストレージ・デバイス、磁気ストレージ・デバイス、またはこれらの任意の好適な組み合わせを含むであろう。本明細書の文脈において、コンピュータ可読ストレージ媒体は、命令実行システム、装置、もしくはデバイスによって、または命令実行システム、装置、もしくはデバイスに関連して使用するためのプログラムを含むまたは記憶することができる任意の有形の媒体である可能性がある。

コンピュータ可読媒体上に具現化されるプログラム・コードは、無線、有線、光ファイバ・ケーブル、ＲＦなど、またはこれらの任意の好適な組み合わせを含むがこれらに限定されない任意の適切な媒体を用いて送信される可能性がある。本発明の態様の動作を実行するためのコンピュータ・プログラム・コードは、Ｊａｖａ（Ｒ）、Ｓｍａｌｌｔａｌｋ（Ｒ）、Ｃ＋＋などのオブジェクト指向プログラミング言語と、「Ｃ」プログラミング言語または同様のプログラミング言語などの従来の手続き型プログラミング言語とを含む１つまたは複数のプログラミング言語の任意の組み合わせで記述され得る。プログラム・コードは、すべてユーザのコンピュータ上で、ユーザのコンピュータ上で部分的に、またはすべて遠隔のコンピュータもしくはサーバ上で実行され得る。最後の場合では、遠隔のコンピュータが、ローカル・エリア・ネットワーク（ＬＡＮ）もしくは広域ネットワーク（ＷＡＮ）を含む任意の種類のネットワークを介してユーザのコンピュータに接続され得るか、または外部コンピュータへの接続が（例えば、インターネット・サービス・プロバイダを使用してインターネットを介して）行われ得る。

本発明の態様が、本発明の実施形態による方法、装置（システム）、およびコンピュータ・プログラムの流れ図またはブロック図あるいはその両方を参照して以下で説明される。流れ図またはブロック図あるいはその両方の各ブロック、および流れ図またはブロック図あるいはその両方のブロックの組み合わせは、コンピュータ・プログラム命令によって実装され得ることが理解されるであろう。これらのコンピュータ・プログラム命令は、コンピュータまたはその他のプログラム可能なデータ処理装置のプロセッサによって実行される命令が、流れ図もしくはブロック図またはその両方の１つのブロックあるいは複数のブロックで規定された機能／動作を実施するための手段をもたらすように、多目的コンピュータ、専用コンピュータ、または機械を生産するためのその他のプログラム可能なデータ処理装置のプロセッサに与えられてマシンを生成する可能性がある。

これらのコンピュータ・プログラム命令は、コンピュータ可読媒体に記憶された命令が、流れ図もしくはブロック図またはその両方の１つのブロックあるいは複数のブロックで規定された機能／動作を実施する命令を含む製品をもたらすように、コンピュータ、その他のプログラム可能なデータ処理装置、またはその他のデバイスを特定の方法で機能させることができるコンピュータ可読媒体に記憶される可能性もある。コンピュータ・プログラム命令は、コンピュータまたはその他のプログラム可能な装置で実行される命令が、流れ図もしくはブロック図またはその両方の１つのブロックあるいは複数のブロックで規定された機能／動作を実施するためのプロセスを提供するように、コンピュータで実施されるプロセスを生成するために一連の動作のステップがコンピュータ、その他のプログラム可能な装置、またはその他のデバイスで実行されるようにするために、コンピュータ、その他のプログラム可能なデータ処理装置、またはその他のデバイスにロードされる可能性もある。

上述の図面の流れ図およびブロック図は、本発明のさまざまな実施形態によるシステム、方法、およびコンピュータ・プログラムのあり得る実装のアーキテクチャ、機能、および動作を示す。これに関連して、流れ図またはブロック図の各ブロックは、（１つまたは複数の）規定された論理的な機能を実装するための１つまたは複数の実行可能命令を含むモジュール、セグメント、またはコードの一部を表す可能性がある。一部の代替的な実装においては、ブロックで示された機能が、図面に示された順序とは異なる順序で行われる可能性があることにも留意されたい。例えば、関連する機能に応じて、連続で示された２つのブロックが、実際には実質的に同時に実行される可能性があり、またはそれらのブロックが、時には逆順に実行されることもあり得る。ブロック図または流れ図あるいはその両方の各ブロックと、ブロック図または流れ図あるいはその両方のブロックの組み合わせとは、規定された機能もしくは動作を実行する専用のハードウェアに基づくシステム、または専用のハードウェアとコンピュータ命令との組み合わせによって実装され得ることも認められるであろう。

本発明の１つまたは複数の実施形態が詳細に示されたが、当業者は、それらの実施形態に対する変更および改変が、添付の特許請求の範囲に記載の本発明の範囲を逸脱することなくなされ得ることを理解するであろう。

Claims (10)

1. コンピューティング環境におけるプロセッサによる論理装置名（ＬＵＮ）よりも細かいデータ・マイグレーションのための方法であって、
   ホスト・ベースのマイグレーションにおいて、ホスト上の所有するアプリケーションに関連して指定されたサイズのデータを前記ＬＵＮの裏側の物理的なストレージからターゲット・ストレージ・プールの新しい物理的な位置にマイグレーションするためにストレージ・コントローラと所有するアプリケーションとの間の 前記ストレージ・コントローラに含まれるストレージ仮想化ソフトウェアにより実行されるソース・コードに基づくインターフェース（ＡＰＩ）であって、
   前記データは、前記所有するアプリケーションにより記述されるアクセス頻度および前記ターゲット論理装置名（LUN）の秒当たりのハードウエア入出力操作（IOｓ）にも基づいて、前記ストレージ仮想化ソフトウェアより直接マイグレーションされ、
   前記データは、前記所有するアプリケーションのトリガーにより前記APIに基づいて、前記ストレージ仮想化ソフトウェアが前記所有するアプリケーションが常駐する前記ホストを経由せずマイグレーションを実行することを特徴とする、前記インターフェース（ＡＰＩ）を実装するステップと、
   連続的に１つの物理ボリューム上に前記データのチャンクを記憶するか、複数の物理ボリュームに跨って分離して保管するか、のいずれかにより、前記ターゲット・ストレージ・プール上に前記データのチャンクに最も適する場所を決定するステップとを含む、方法。
2. 前記指定されたサイズのデータをマイグレーションすることが、仮想ディスク上の前記データのチャンクの開始論理ブロック・アドレス（ＬＢＡ）およびサイズと、前記新しい物理的な位置を特定するマイグレーション先の物理的なストレージの記述とを指定することを含む、請求項１に記載の方法。
3. 前記ストレージ・コントローラによってサポートされるストレージ・プールのリストを、前記ストレージ・プールの前記リストのうちの少なくとも１つに関連する少なくとも１つのストレージの特徴とともに公開するステップをさらに含む、請求項２に記載の方法。
4. 前記開始ＬＢＡからのデータおよび指定されたサイズの前記データの前記チャンクがストレージ・プールの公開されたリストのうちのマイグレーション先のストレージ・プールにマイグレーションされることを要求する呼び出しを前記インターフェースを介して受信するステップをさらに含む、請求項３に記載の方法。
5. 前記マイグレーション先のストレージ・プール上の前記データの前記チャンクに最も適する場所を決定するステップをさらに含む、請求項４に記載の方法。
6. マイグレーション動作として、前記所有するアプリケーションに対して透過的なバックグラウンド・プロセスとして前記マイグレーション先のストレージ・プールに前記データの前記チャンクをマイグレーションするステップをさらに含む、請求項５に記載の方法。
7. 仮想ディスク・マップが前記マイグレーション先のストレージ・プール上の前記新しい物理的な位置を指すようにするステップをさらに含む、請求項６に記載の方法。
8. 前記仮想ディスク・マップが前記新しい物理的な位置を指すようにするステップを完了した後に、前記マイグレーション動作をコミットするステップをさらに含む、請求項７に記載の方法。
9. コンピューティング環境における論理装置名（ＬＵＮ）よりも細かいデータ・マイグレーションのためのシステムであって、
   前記コンピューティング環境で動作可能なプロセッサと、
   ホスト・ベースのマイグレーションにおいて、ホスト上の所有するアプリケーションに関連して指定されたサイズのデータを前記ＬＵＮの裏側の物理的なストレージからターゲット・ストレージ・プールの新しい物理的な位置にマイグレーションするためにストレージ・コントローラと所有するアプリケーションとの間の 前記ストレージ・コントローラに含まれるストレージ仮想化ソフトウェアにより実行されるソース・コードに基づくインターフェース（ＡＰＩ）であって、
   前記データは、前記所有するアプリケーションにより記述されるアクセス頻度および前記ターゲット論理装置名（LUN）の秒当たりのハードウエア入出力操作（IOｓ）にも基づいて、前記ストレージ仮想化ソフトウェアより直接マイグレーションされ、
   前記データは、前記所有するアプリケーションのトリガーにより前記APIに基づいて、前記ストレージ仮想化ソフトウェアが前記所有するアプリケーションが常駐する前記ホストを経由せずマイグレーションを実行することを特徴とする、前記インターフェース（ＡＰＩ）を実装し、
   連続的に１つの物理ボリューム上に前記データのチャンクを記憶するか、複数の物理ボリュームに跨って分離して保管するか、のいずれかにより、前記ターゲット・ストレージ・プール上に前記データのチャンクに最も適する場所を決定する、
   ことを前記プロセッサに実行させる前記ストレージ仮想化プログラムと、を含むシステム。
10. コンピューティング環境におけるプロセッサによる論理装置名（ＬＵＮ）よりも細かいデータ・マイグレーションのためのコンピュータ・プログラムであって、
    ホスト・ベースのマイグレーションにおいて、ホスト上の所有するアプリケーションに関連して指定されたサイズのデータを前記ＬＵＮの裏側の物理的なストレージからターゲット・ストレージ・プールの新しい物理的な位置にマイグレーションするためにストレージ・コントローラと所有するアプリケーションとの間の 前記ストレージ・コントローラに含まれるストレージ仮想化ソフトウェアにより実行されるソース・コードに基づくインターフェース（ＡＰＩ）であって、
    前記データは、前記所有するアプリケーションにより記述されるアクセス頻度および前記ターゲット論理装置名（LUN）の秒当たりのハードウエア入出力操作（IOｓ）にも基づいて、前記ストレージ仮想化ソフトウェアより直接マイグレーションされ、
    前記データは、前記所有するアプリケーションのトリガーにより前記APIに基づいて、前記ストレージ仮想化ソフトウェアが前記所有するアプリケーションが常駐する前記ホストを経由せずマイグレーションを実行することを特徴とする、前記インターフェース（ＡＰＩ）を実装し、
    連続的に１つの物理ボリューム上に前記データのチャンクを記憶するか、複数の物理ボリュームに跨って分離して保管するか、のいずれかにより、前記ターゲット・ストレージ・プール上に前記データのチャンクに最も適する場所を決定する、ことを前記プロセッサに実行させる、コンピュータ・プログラム。

Images