JP4914173B2 - 再配置システムおよび再配置方法 - Google Patents

Description

本発明は、シン・プロビジョニングにより構築された仮想ボリュームを、プール枯渇に対する安全性を確保しつつ再配置することができる再配置システムおよび再配置方法に関する。

企業等の組織で管理されるデータは、ディスクアレイサブシステム等として呼ばれるストレージ装置に格納されるのが一般的である。このストレージ装置は、ハードディスクドライブ等の記憶装置を複数備えてＲＡＩＤ（Redundant Array of Inexpensive Disks）を構成し、その上にボリュームと呼ばれる論理的な記憶領域を構築する。ホストコンピュータ（以下、「ホスト」という。）は、このボリュームを介して記憶装置にアクセスし、データの読み書きを行う。

ところで、近年、企業等の組織で管理されるデータの量は年々増加する一方であり、ストレージ装置の有効利用が重要課題となっている。この課題を解決するために、ストレージ階層管理やシン・プロビジョニングといった従来技術があり、シン・プロビジョニングは、ストレージ装置の容量利用効率を向上するための技術となっている。

特許文献１には、ボリュームをその特性に応じて階層と呼ばれるグループに分類し、データをその価値に応じた特性を有するボリュームに適宜配置することでストレージの有効利用を図る、ストレージ階層管理の方法が開示されている。

シン・プロビジョニングによらない通常のボリューム（以下、「通常ボリューム」という。）においては、ボリューム作成時にボリュームの全容量に相当する領域が記憶装置上に確保される。一方、シン・プロビジョニングでは、複数の通常ボリュームをプールし、その上に仮想的なボリューム（以下、「仮想ボリューム」という。）を構築する。そして、その仮想ボリュームをホストに公開し、実際にデータが書き込まれたデータブロックに対してだけ、物理的な記憶領域をプール内の通常ボリュームから確保し割り当てる。

そのため、メリットとしては、大きな容量の仮想ボリュームを作成しても、実際にホストから使用される分だけの通常ボリュームを用意しておけばよく、ストレージ装置の容量利用効率が向上する。デメリットとしては、プール内の通常ボリューム上の空き領域が枯渇すると、そのプール上に構築された仮想ボリュームすべてに対して、それ以上データを書き込むことができなくなる。そのため、ユーザ（ストレージ装置の管理者）は、プールの使用量の増加を見積もり、運用中にプールが枯渇することがないように、プールへの通常ボリュームの追加といった維持管理作業を随時行う必要がある。

シン・プロビジョニングと階層管理を組み合わせて用いることで、ストレージの有効利用がより促進されると考えられる。すなわち、プールをその特性ごとに階層に分類し、異なる階層に属する複数のプール間で仮想ボリュームを再配置することで、ユーザはシン・プロビジョニングと階層管理の両方の利点を享受することができると期待される。
特開２００６−９９７４８号公報

前記従来技術には次のような問題があり、シン・プロビジョニングの上で適用した場合、ユーザのストレージ有効利用を十分支援できるとは言いがたい。

第１の問題は、プール枯渇の危険性が増すということである。仮想ボリュームをプール間で再配置することで各プールの使用量の傾向が大きく変化するため、再配置後のプールの使用量増加を見積もるのが難しくなるためである。最悪の場合、再配置を実行した結果、移動先のプールの枯渇までの期間（以下、「残運用期間」という。）が短くなってしまい、ユーザが対処を講じるのが間に合わなくなる可能性がある。

第２の問題は、プールの空き領域を調整する手段として再配置を利用することが難しいということである。例えば、ユーザが枯渇しそうなプールを発見し、そのプール上に構築された仮想ボリュームを別のプールに移動することにより枯渇時期を延ばそうとしても、どの仮想ボリュームをどのプールに再配置するのが最も効果的かを判断するのは難しい。

本発明は、前記の課題を解決するための発明であって、シン・プロビジョニングにより構築された仮想ボリュームを、プール枯渇に対する安全性を確保しつつ再配置することができる再配置システムおよび再配置方法を提供することを目的とする。

前記目的を達成するため、複数のプールを備え、ひとつ以上の通常ボリュームからなるプール上に構築されたひとつ以上の仮想ボリュームを有し、ひとつ以上の仮想ボリュームへの書き込み操作に応じて、プールを構成するひとつ以上の通常ボリュームから記憶領域を割り当てるストレージと、仮想ボリュームを管理する管理サーバとを備える仮想ボリュームの再配置システムであって、管理サーバは、プールを階層に分類する複数の条件からなる階層定義を記憶するとともに、階層定義の条件には、階層における使用量増加の傾向を、階層間の相対比率で表した値である使用量増加バイアスを記憶する記憶部と、記憶部の使用量増加バイアスを含む条件を考慮してプールの枯渇までの期間を予測する予測部と、予測部の予測結果に基づいて移動先候補となるプールを選択する選択部と、選択部で選択された移動先候補のひとつのプールに仮想ボリュームを再配置させる再配置部とを備えたことを特徴とする。このような構成によれば、仮想ボリュームの再配置前後のプール枯渇までの期間を予測し、予測結果に基づいて仮想ボリュームの再配置動作を制御することができる。

本発明によれば、シン・プロビジョニングにより構築された仮想ボリュームを、プール枯渇の安全性を確保しつつ再配置することができる。

以下、本発明の実施形態について図面を参照して説明する。
図１は、本発明の再配置システムの構成を示す図である。ストレージ装置１１０は、ＤＫＣ（ディスクコントローラ）１１１、複数の通常ボリューム１１２を備える。各通常ボリューム１１２は、ＤＫＣ１１１上で一意な識別子（以下、「通常ボリュームＩＤ」という。）によって識別される。通常ボリューム１１２に対応する記憶装置は、ストレージ装置１１０に内蔵された記憶装置であってもよいし、ストレージ装置１１０に接続された他のストレージ装置に内蔵された記憶装置のような、ストレージ装置１１０の外部に存在する記憶装置であってもよい。

プール１１３は、ＤＫＣ１１１によってシン・プロビジョニングのプールとして認識される通常ボリューム１１２の集合である。プール１１３は、ＤＫＣ１１１に対して複数存在することができ、各プールは、一意な識別子（以下、「プールＩＤ」という。）によって識別される。

仮想ボリューム１１４は、ＤＫＣ１１１によってプール１１３の上に構築されたシン・プロビジョニングの仮想ボリュームである。仮想ボリューム１１４は、ひとつのプール１１３に対して複数存在することができ、各仮想ボリューム１１４はＤＫＣ１１１上で一意な識別子（以下、「仮想ボリュームＩＤ」という。）によって識別される。仮想ボリューム１１４は、ＤＫＣ１１１にネットワーク１３１を介して接続されたホスト１３２から、ボリュームとしてアクセス可能である。ネットワーク１３１は、例えばＳＡＮ（Storage Area Network）を用いて構成することができる。

管理サーバ１００は、再配置制御部１０１と、再配置制御部１０１からアクセス可能なデータベース１０２と、データベース１０２を管理するデータベース管理部１０３を備えるサーバコンピュータである。管理クライアント１２０は、ブラウザ１２１を備えるクライアントコンピュータである。管理サーバ１００、管理クライアント１２０、およびＤＫＣ１１１は、ネットワーク１３０を介して互いに接続されている。ネットワーク１３０は、例えばＬＡＮ（Local Area Network）を用いて構成することができる。

再配置制御部１０１は、データベース管理部１０３を介してデータベース１０２にアクセスするとともに、ブラウザ１２１およびＤＫＣ１１１と通信しながら、再配置にかかわる各種の処理を実行するモジュールである。

ＤＫＣ１１１は、プール１１３および仮想ボリューム１１４に関する各種の情報（プール１１３および仮想ボリューム１１４の一覧、プール１１３と仮想ボリューム１１４の間の関連、例えば、プール１１３および仮想ボリューム１１４の容量や実使用量といった属性情報等）を管理しており、管理サーバ１００に対して、それらの情報を渡すインタフェースを備えている。また、ＤＫＣ１１１は、管理サーバ１００からの要求に従って、指定された仮想ボリューム１１４を指定された別のプール１１３に再配置するためのインタフェースを備えている。また、ＤＫＣ１１１は、管理サーバ１００からの要求に従って、指定された仮想ボリューム１１４を、未使用の別の通常ボリューム１１２に再配置するためのインタフェースを備えている。

図２は、図１で列挙した各装置のハードウェア構成を示す図である。管理サーバ１００は、バスを介して互いに接続された、ＣＰＵ（Central Processing Unit）２２００、メモリ２２０１、ハードディスク等の外部記憶装置２２０２、ＮＩＣ（Nerwork Interface Card）２２０３を備える。メモリ２２０１上には再配置制御部１０１およびデータベース管理部１０３がプログラムとして格納され、ＣＰＵ２２００によって実行される。データベース１０２は外部記憶装置２２０２上に格納される。ＮＩＣ２２０３はネットワーク１３０に接続され、ストレージ装置１１０および管理クライアント１２０との通信を受け持つ。

ストレージ装置１１０は、バスを介して互いに接続された、ＣＰＵ２２１０、メモリ２２１１、ハードディスク等の記憶装置を多数配列したディスクアレイ２２１２、ＮＩＣ２２１３、ＣＨＡ（Channel Adapter）２２１４を備える。メモリ２２１１上にはＤＫＣ１１１がプログラムとして格納され、ＣＰＵ２２１０によって実行される。ＤＫＣ１１１が実行されることにより、ディスクアレイ２２１２上の記憶領域がボリュームとしてＣＨＡ２２１４およびネットワーク１３１を介して接続されたホスト１３２に対して提供される。ＮＩＣ２２１３は、ネットワーク１３０に接続され、管理サーバ１００との通信を受け持つ。

管理クライアント１２０は、バスを介して互いに接続された、ＣＰＵ２２２０、メモリ２２２１、ＮＩＣ２２２３を備える。メモリ２２２１上にはブラウザ１２１がプログラムとして格納され、ＣＰＵ２２２０によって実行される。ＮＩＣ２２２３は、ネットワーク１３０を介して、管理サーバ１００と各種データやコマンドを交換する。１３１と１３２については説明を省略する。

《実施形態１》
図３は、実施形態１の再配置制御部の構成を示す図である。再配置制御部１０１は、再配置実行処理Ｓ２００、再配置実行後の移動先プールの残運用期間予測処理Ｓ２０１、残運用期間予測処理Ｓ２０２、使用量予測関数更新処理Ｓ２０３から構成される。内容の詳細は後記する。

図４は、実施形態１のデータベースの構成を示す図である。データベース１０２は、仮想ボリュームテーブル２１０、プールテーブル２１１、仮想ボリューム使用量予測関数テーブル２１２、仮想ボリューム使用量履歴テーブル２１３から構成される。

次に、データベース１０２上の各テーブルの構成について説明する。
図５は、図４のデータベース上の各テーブルの構成を示す図である。仮想ボリュームテーブル２１０は、図５（ａ）に示すように、ＤＫＣ１１１から取得された各仮想ボリューム１１４の属性情報を格納する仮想ボリュームレコード３００の集合から構成される。各レコードは、少なくとも、レコードが表す仮想ボリューム１１４を一意に識別する数値である仮想ボリュームＩＤが格納される仮想ボリュームＩＤフィールド３０１、該仮想ボリュームが所属するプールを一意に識別する数値であるプールＩＤを表すプールＩＤフィールド３０２、該仮想ボリュームの仮想的な容量をメガバイト単位の値で表す仮想容量フィールド３０３、該仮想ボリュームに実際に割り当てられた物理的な記憶領域の合計サイズをメガバイト単位の値で表す実使用量フィールド３０４を有する。仮想ボリュームテーブル２１０の内容と、実際の仮想ボリューム１１４の属性情報とは、ＤＫＣ１１１から一定時間毎に情報を取得する等の既知の方法により同期を取っておく。なお、仮想ボリュームレコード３００と後記する仮想ボリューム使用量予測関数レコード３２０とは一対一の数量関係にある。

プールテーブル２１１は、図５（ｂ）に示すように、各プール１１３の属性情報を格納するプールレコード３１０の集合から構成される。各レコードは、少なくとも、レコードが表すプール１１３を一意に識別する数値であるプールＩＤが格納されるプールＩＤフィールド３１１、該プール全体の容量をメガバイト単位の値で表す容量フィールド３１２、該プールの実使用量をメガバイト単位の値で表す実使用量フィールド３１３、該プール上の仮想ボリューム１１４にプール１１３上の物理的な記憶領域を割り当てる際の単位データサイズをキロバイト単位の値で表すページサイズフィールド３１４、プール１１３を構成するディスクのＲＡＩＤ構成種別（例えばＲＡＩＤ０、ＲＡＩＤ１、ＲＡＩＤ５等）を表すＲＡＩＤ種別フィールド３１５、プールを構成するディスクの性能種別（例えばＳＡＴＡ、ＳＣＳＩ、ＦＣ）を表す性能種別フィールド３１６を有する。プールテーブル２１１の内容と、実際のプール１１３の属性情報とは、ＤＫＣ１１１から一定時間毎に情報を取得する等の既知の方法により同期を取っておく。なお、ＳＡＴＡとは、Serial Advanced Technology Attachmentの略である。ＳＣＳＩとは、Small Computer System Interfaceの略である。ＦＣとは、Fibre Channelの略である。

仮想ボリューム使用量予測関数テーブル２１２は、図５（ｃ）に示すように、各仮想ボリューム１１４の実使用量の予測値を算出するための一次予測関数の係数を格納する、仮想ボリューム使用量予測関数レコード３２０の集合から構成される。各レコードは、少なくとも、レコードが表す予測関数によって実使用量が予測される仮想ボリューム１１４の仮想ボリュームＩＤを格納する仮想ボリュームＩＤフィールド３２１、一日あたりの仮想ボリューム１１４の実使用量増加量の見積もり値をメガバイト単位の値で格納する一次係数フィールド３２２を有する。仮想ボリュームＩＤフィールド３２１によって表される仮想ボリューム１１４の将来のある時点における実使用量の予測値は、該仮想ボリュームの現在の実使用量に対し、予測する時点の現在からの経過日数に一次係数フィールド３２２の値を掛けたものを加えることによって求められる。例えば、仮想ボリュームＩＤが００００である仮想ボリューム１１４について、現在の実使用量が７５０ＭＢ、一時係数が５０ＭＢ／日とすると、該仮想ボリュームの３日後の実使用量の予測値は、７５０＋５０×３＝９００ＭＢと求められる。なお、仮想ボリュームレコード３００と仮想ボリューム使用量予測関数レコード３２０とは一対一の関係にある。

仮想ボリューム使用量履歴テーブル２１３は、図５（ｄ）に示すように、各仮想ボリューム１１４の一定時間ごと、例えば一時間ごとの実使用量を格納する仮想ボリューム使用量履歴レコード３３０の集合から構成される。各レコードは、少なくとも、該レコードが実使用量を表す仮想ボリューム１１４の仮想ボリュームＩＤを格納する仮想ボリュームＩＤフィールド３３１、実使用量が取得された日付と時刻を表す時刻フィールド３３２、該仮想ボリュームの該時刻における実使用量をメガバイト単位の値で表す実使用量フィールド３３３を有する。

次に、ユーザがある仮想ボリュームをあるプールに再配置することを指示し、指定した仮想ボリュームを再配置する方法について、図６、図７、図８、図９、図１０を用いて説明する。

図６は、実施形態１の再配置指示画面を示す図である。図６を用いて、ユーザがある仮想ボリュームを移動先であるプールに再配置することを指示し、再配置実行処理Ｓ２００（図３、図７参照）を呼び出すための操作方法について説明する。再配置指示画面４ｓ０１はブラウザ１２１上に表示される画面である。再配置指示画面４ｓ０１は、ツリー領域４ｓ０２、プール情報領域４ｓ０３、仮想ボリューム情報領域４ｓ０４を含む。ツリー領域４ｓ０２は、プールを表すノードと仮想ボリュームを表すノードがツリー状に表示される。図６は、２個のプールがノード４ｓ１０とノード４ｓ１１によって表され、ノード４ｓ１０が表すプールに所属する仮想ボリュームがノード４ｓ２０とノード４ｓ２１によって表され、ノード４ｓ１１が表すプールに所属する仮想ボリュームがノード４ｓ２２によって表される様子を示している。ノード４ｓ１０とノード４ｓ１１に対応するプールのプールＩＤはそれぞれ００と０１であり、ノード４ｓ２０、ノード４ｓ２１、ノード４ｓ２２に対応する仮想ボリュームの仮想ボリュームＩＤはそれぞれ００００、０００１、０００２である。

ユーザは、ツリー領域４ｓ０２上で、マウスを用いてノードをクリックすることにより、プールと仮想ボリュームをそれぞれひとつ選択状態にすることができる。選択状態のノードは画面上でハイライト表示され、且つそれらのノードが表すプールおよび仮想ボリュームの属性情報がプール情報領域４ｓ０３および仮想ボリューム情報領域４ｓ０４にそれぞれ表示される。図６はノード４ｓ１０とノード４ｓ２０が選択されている様子を示している。

さらに、ユーザは、ツリー領域４ｓ０２上で、マウスを用いて仮想ボリュームを表すノードを、プールを表すノード上にドラッグアンドドロップすることにより、再配置の実行を指示することができる。例えば、ノード４ｓ２０をノード４ｓ１１の上にドラッグアンドドロップすることにより、仮想ボリュームＩＤが００００である仮想ボリュームをプールＩＤが０１であるプールに再配置することを指示することができる。このように、ユーザが図６の再配置指示画面４ｓ０１により再配置指示を出すと、図７に示す再配置実行処理Ｓ２００が実行される。

図７は、再配置実行処理の処理内容を示すフローチャートである。再配置実行処理Ｓ２００は、移動する仮想ボリュームＩＤと、移動先プールＩＤとをパラメタとして受け取り、仮想ボリュームの再配置を実行する。再配置実行処理Ｓ２００は、ユーザがブラウザ１２１を介して、前述した操作方法により、ある仮想ボリュームをあるプールに再配置することを指示することにより呼び出される。再配置実行処理Ｓ２００は、ＣＰＵ２２００により実行される。

ステップＳ４０１では、再配置実行後の移動先プールの残運用期間予測処理Ｓ２０１を、移動する仮想ボリュームＩＤと、移動先プールＩＤとを渡して呼び出す。ステップＳ４０２では、ステップＳ４０１の戻り値として得られた予測残運用期間が、最低残運用期間閾値より小さいか否かを判定する。最低残運用期間閾値は、再配置後のプールに最低限確保すべき枯渇までの期間を表す閾値であり、システムが定める固定値でもよいし、ユーザから与えられたパラメタやデータベース１０２上の値から計算によって求まる値を用いてもよい。判定結果が真の場合は（ステップＳ４０２，Ｙｅｓ）、ステップＳ４０５へ、判定結果が偽の場合は（ステップＳ４０２，Ｎｏ）、ステップＳ４０３へ進む。

ステップＳ４０３では、ＤＫＣ１１１に対して、移動する仮想ボリュームＩＤと移動先プールＩＤとを指定して、仮想ボリュームを別のプールに再配置することを指示する。これにより、ＤＫＣ１１１は、指定された仮想ボリュームに対応付けられた物理的な記憶領域を、指定された移動先プール内の通常ボリューム上に再配置する。ステップＳ４０４では、移動した仮想ボリュームの最新の属性情報をＤＫＣ１１１から取得し、移動した仮想ボリュームに対応する仮想ボリュームレコード３００（図５（ａ）参照）を更新する。これにより、プールＩＤフィールド３０２が再配置後のプールＩＤに更新される。その後一連の処理を終了する。ステップＳ４０５では、呼び出し側にエラーを返して一連の処理を終了する。なお、ステップＳ４０１における再配置実行後の移動先プールの残運用期間予測処理Ｓ２０１は、図８を用いて説明する。

図８は、再配置実行後の移動先プールの残運用期間予測処理を示すフローチャートである。再配置実行後の移動先プールの残運用期間予測処理Ｓ２０１は、移動する仮想ボリュームＩＤと、移動先プールＩＤを受け取り、移動する仮想ボリュームを移動先プールに再配置した場合を想定して、移動先プールの残運用期間を予測する。再配置実行後の移動先プールの残運用期間予測処理Ｓ２０１は、ＣＰＵ２２００により実行される。

ステップＳ５０１では、移動する仮想ボリュームＩＤに対応する仮想ボリュームレコード３００を検索し、そのレコードのプールＩＤフィールド３０２の値を保存したのち、プールＩＤフィールドを移動先プールＩＤに書き換える。ステップＳ５０２では、残運用期間予測処理Ｓ２０２を、移動先プールＩＤを渡して呼び出す。ステップＳ５０３では、ステップＳ５０１で書き換えたプールＩＤフィールド３０２の値を保存しておいた値に戻す。ステップＳ５０４では、ステップＳ５０２の結果を戻り値として返し、一連の処理を終了する。なお、ステップＳ５０２における残運用期間予測処理Ｓ２０２は、図９を用いて説明する。

図９は、残運用期間予測処理を示すフローチャートである。残運用期間予測処理Ｓ２０２は、プールＩＤを受け取り、そのプールの残運用期間を予測する。残運用期間予測処理Ｓ２０２は、ＣＰＵ２２００により実行される。

ステップＳ６０１では、指定されたプールに所属する仮想ボリュームに関するすべてのレコードを仮想ボリュームテーブル２１０（図５（ａ）参照）から検索し、それらのレコードの仮想容量フィールド３０３の値を合計する。ステップＳ６０２では、指定されたプールに対応するプールレコード３１０の容量フィールド３１２（図５（ｂ）参照）からプール容量を取得し、プール容量から容量マージンを差し引いたものが、ステップＳ６０１で求められた仮想容量合計を上回っているか否かを判定する。ここで、容量マージンは、プールを運用可能とみなす最低限の空き容量であり、固定値を用いてもよいし、ユーザから与えられたパラメタやデータベース上の値から計算により求まる値を用いてもよいが、本実施形態ではプールの容量の１０％とする。判定結果が真の場合は（ステップＳ６０２，Ｙｅｓ）、ステップＳ６０６に進み、判定結果が偽の場合は（ステップＳ６０２，Ｎｏ）、ステップＳ６０３に進む。

ステップＳ６０３では、指定されたプールに所属する仮想ボリュームに関するすべてのレコードを仮想ボリューム使用量予測関数テーブル２１２（図５（ｃ）参照）から検索し、それらのレコードの一次係数フィールド３２２の値を合計する。同様に、指定されたプールに所属する仮想ボリュームに関するすべてのレコードを仮想ボリュームテーブル２１０（図５（ａ）参照）から検索し、それらのレコードの実使用量フィールド３０４の値を合計する。例えば、図５に例示されるように、プールＩＤが００であるプールに仮想ボリュームＩＤが００００および０００１である仮想ボリュームが所属していたとすると、該プールに関する実使用量合計および一次係数合計はそれぞれ１２５０ＭＢ（７５０ＭＢと５００ＭＢの加算）、５６ＭＢ／日（５０ＭＢ／日と６ＭＢ／日の加算）となる。

ステップＳ６０４では、ステップＳ６０３で求めた一次係数合計と実使用量合計を用いて、（実使用量合計＋一次係数合計×ｔ）＝（プール容量−容量マージン）を満たすｔを求める。例えば、図５に例示されるように、プールＩＤが００であるプールに仮想ボリュームＩＤが００００および０００１である仮想ボリュームが所属していたとすると、該プールに関するｔは、（１２５０＋５６×ｔ）＝（１００００−（１００００×０．１０））を満たすｔを計算し１３８．４と求められる。すなわち、このプールは今後およそ１３８日の間安全に運用できると予測される。ステップＳ６０５では、ステップＳ６０４で求められたｔを予測結果として返す。ステップＳ６０６では、プールが枯渇することはないため、無限大を予測結果として返す。

次に、仮想ボリューム使用量予測関数テーブル２１２（図５（ｃ）参照）の一次係数フィールド３２２の決定方法について説明する。ひとつの方法は、ユーザから与えられたパラメタを使用することである。ユーザが仮想ボリュームごとに単位時間あたりの実使用量増加量を見積もり、一次係数フィールド３２２に格納する。もうひとつの方法は、実使用量の履歴から自動的に計算する使用量予測関数更新処理Ｓ２０３を備えることである。図１０を用いて使用量予測関数更新処理Ｓ２０３について詳細に説明する。

図１０は、使用量予測関数更新処理を示すフローチャートである。使用量予測関数更新処理Ｓ２０３は、一定時間ごと、例えば毎時０分に起動され、その時点での仮想ボリュームの実使用量に基づいて仮想ボリューム使用量履歴テーブル２１３（図５（ｄ）参照）を更新し、さらに仮想ボリューム使用量予測関数テーブル２１２（図５（ｃ）参照）を更新する。使用量予測関数更新処理Ｓ２０３は、ＣＰＵ２２００により実行される。

ステップＳ７０１では、仮想ボリューム使用量履歴テーブル２１３（図５（ｄ）参照）から、時刻フィールド３３２と現在時刻との差がある基準値より大きい、すなわち古いレコードをすべて削除する。基準値としては、固定値を使用してもよいし、ユーザから与えられたパラメタやデータベース１０２上の値から計算によって求まる値を用いてもよい。ステップＳ７０２では、仮想ボリュームテーブル２１０上に記録されている全仮想ボリュームに対して、ステップＳ７０３〜Ｓ７０７を繰り返す。

ステップＳ７０３では、ＤＫＣ１１１から該仮想ボリュームの実使用量を取得する。ステップＳ７０４では、仮想ボリューム使用量履歴テーブル２１３に新たなレコードを追加し、該仮想ボリュームのＩＤ，現在時刻、ステップＳ７０３で取得した実使用量を、該レコードの仮想ボリュームＩＤフィールド３３１、時刻フィールド３３２、実使用量フィールド３３３にそれぞれ格納する。ステップＳ７０５では、仮想ボリューム使用量履歴テーブル２１３から、該仮想ボリュームに関連する仮想ボリューム使用量履歴レコード３３０をすべて検索し、該レコードの時刻フィールド３３２と実使用量フィールド３３３の値の組（ｘ，ｙ）をすべて取得する。ステップＳ７０６では、ステップＳ７０５で取得した（ｘ，ｙ）の組に対して、一次近似関数ｙ＝ａｘ＋ｂの係数を最小二乗法により求める。ステップＳ７０７では、該仮想ボリュームに対応する仮想ボリューム使用量予測関数レコード３２０の一次係数フィールド３２２に、ステップＳ７０６で求められた一次近似関数の一次係数ａを書き込む。

なお、本実施形態では、予測関数として、仮想ボリュームの使用量履歴から最小二乗法で求められる一次関数を用いているが、これは本発明の予測関数の形および予測関数の決定方法を限定するものではない。一般的な多項式や指数関数といった異なる形の予測関数を用いたり、異なる予測関数決定方法を適用したりしてもよい。

また、本実施形態は、単一の仮想ボリュームを再配置可能なシステムとして構成されているが、これを複数の仮想ボリュームをまとめて再配置可能なシステムに拡張することは容易に可能である。

以上述べたように、本実施形態は、上述のように構成されるため、以下の効果を奏する。本実施形態では、再配置前後のプールの残運用期間を予測し、予測結果に基づいて仮想ボリュームの再配置を制御する。そのため、ユーザ自身がプールの残運用期間に注意を払うことなく、仮想ボリューム再配置によってストレージ資源を安全且つ有効に活用することが可能となる。

本実施形態では、移動先プールの残運用期間の予測に基づいて再配置の可否を判断する。そのため、ユーザ自身がプールの残運用期間に注意を払って再配置を行ってよいかどうかを判断する必要がない。

本実施形態では、再配置後のプールの残運用期間の予測値が、最低限確保すべき期間を表す閾値以上である場合にのみ再配置を許可する。そのため、ユーザが再配置によりプールの残運用期間を小さくしすぎてしまうことを防ぐことができる。

本実施形態では、ユーザから与えられたパラメタに基づいて決定される予測関数を用いて、再配置前後のプールの残運用期間を予測する。そのため、ユーザは仮想ボリュームごとの見積もりを前もって設定しておくだけで、プールの残運用期間を考慮した再配置を実行することができる。

本実施形態では、仮想ボリュームの実使用量の履歴に基づいて決定される予測関数を用いて、再配置前後のプールの残運用期間を予測する。そのため、ユーザが自分で見積もりを行うことなく、プールの残運用期間を考慮した再配置を実行することができる。

本実施形態では、仮想ボリュームの実使用量が仮想容量を超えないという性質を考慮して、再配置前後のプールの残運用期間を予測する。そのため、シン・プロビジョニングの仮想ボリュームの性質を効果的に利用して再配置を実行することができる。

《実施形態２》
本発明の実施形態２を説明する。実施形態２は、実施形態１の変形にあたる。本実施形態の特徴は、プールを階層に分類し、さらにプールの残運用期間を考慮しつつ、仮想ボリュームを指定された階層に再配置することを可能とした点にある。

図１１は、実施形態２の再配置制御部の構成を示す図である。図３に記載の同一構成品については、同一番号を付しており、説明は省略する。再配置制御部１０１は、追加のモジュールとして、階層指定再配置実行処理Ｓ８００と、移動先プール選択処理Ｓ８０１を備える。なお、図１１に示すように、追加モジュールは、容易に判別できるように符号を四角で囲っている。以下の実施形態においても同様である。

図１２は、実施形態２のデータベースの構成を示す図である。図４および図５に記載の同一構成品については、同一番号を付しており、説明は省略する。データベース１０２は、追加のテーブルとして、階層テーブル２１４を備える。仮想ボリュームテーブル２１０は、追加のフィールドとして、最後に該仮想ボリュームを再配置した際の移動先階層の階層ＩＤを格納する最終移動階層フィールド３０５を備える。プールテーブル２１１は、追加のフィールドとして、階層条件評価時に用いる残運用期間の予測値（以下、「予測残運用期間」という。）を一時的に格納する予測残運用期間フィールド３１７を備える。

階層テーブル２１４は、プールを階層に分類するためにユーザが定める階層定義を格納するテーブルであり、階層レコード３４０の集合から構成される。階層レコード３４０は、少なくとも、階層を一意に識別する名称である階層ＩＤを格納する階層ＩＤフィールド３４１、該階層に属するプールを選択する条件である階層条件を表す条件式フィールド３４２を有する。条件式フィールド３４２には、階層条件をプールレコード３１０のフィールドに対する条件式として記述する。例えば、「ＲＡＩＤ種別＝ＲＡＩＤ５ ａｎｄ 予測残運用期間＞＝７日」といった条件式を記述することで、ＲＡＩＤ種別フィールド３１５がＲＡＩＤ５且つ予測残運用期間フィールド３１７が７日以上であるプールを選択する階層条件を記述することができる。

次に、ユーザがある仮想ボリュームをある階層に再配置することを指示し、指定した仮想ボリュームを再配置する方法について、図１３、図１４、図１５、図１６を用いて説明する。

図１３は、実施形態２の階層指定再配置指示画面を示す図である。図１３を用いて、ユーザがある仮想ボリュームをある階層に再配置することを指示し、階層指定再配置実行処理Ｓ８００（図１１参照）を呼び出すための操作方法について説明する。階層指定再配置指示画面９ｓ０１は、ツリー領域４ｓ０２、プール情報領域４ｓ０３、仮想ボリューム情報領域４ｓ０４、階層指示領域９ｓ０２を含む。ここで、ツリー領域４ｓ０２、プール情報領域４ｓ０３、仮想ボリューム情報領域４ｓ０４は、実施形態１（図６参照）で説明したものと同一である。階層指示領域９ｓ０２には、階層テーブル２１４上に登録されている各階層に対応する矩形が階層ＩＤとともに一覧表示される。図１３には、階層ＩＤが「高速」および「低速」である階層に対応する矩形９ｓ２０および矩形９ｓ２１が、それぞれ表示されている様子を表している。

ユーザは、ツリー領域４ｓ０２上の仮想ボリュームを表すノードを、階層指示領域９ｓ０２上のいずれかの矩形の上にマウスを用いてドラッグアンドドロップすることにより、ある仮想ボリュームをある階層に再配置することを指示することができる。例えば、ノード４ｓ２０を矩形９ｓ２０の上にドラッグアンドドロップすることにより、仮想ボリュームＩＤが００００である仮想ボリュームを階層ＩＤが「高速」である階層に再配置することを指示することができる。このように、ユーザが図１３の階層指定再配置指示画面９ｓ０１により再配置指示を出すと、図１４に示す階層指定再配置実行処理Ｓ８００が実行される。

図１４は、階層指定再配置実行処理を示すフローチャートである。階層指定再配置実行処理Ｓ８００は、ユーザがブラウザ１２１を介して、ある仮想ボリュームをある移動先階層に再配置することを指示することにより呼び出される。階層指定再配置実行処理Ｓ８００は、移動する仮想ボリュームＩＤと、移動先階層ＩＤとをパラメタとして受け取る。階層指定再配置実行処理Ｓ８００は、ＣＰＵ２２００により実行される。

ステップＳ９ａ０１では、移動する仮想ボリュームＩＤと移動先階層ＩＤとを渡して、移動先プール選択処理Ｓ８０１（図１６参照）を呼び出す。ステップＳ９ａ０２では、ステップＳ９ａ０１で得られたプールＩＤ一覧を用いて、それらのプールの属性情報と選択ボタンとを各行に含む移動先候補プール一覧表（図１５参照）を作成して、ブラウザ１２１を介して、ユーザに提示し、ユーザがいずれかの選択ボタンを押すのを待つ。各行に含まれるプールの属性情報には、少なくとも各プールのＩＤと、移動後の予測残運用期間とが含まれる。一覧表の先頭行の選択ボタンをデフォルトボタンとして設定する。

図１５は、移動先候補プール一覧表の具体的な表示例を示す図である。移動先候補プール一覧表９ｔ０５は、プールＩＤカラム９ｔ５１、予測残運用期間カラム９ｔ５２、選択ボタンカラム９ｔ５３を含む。行９ｔ５４は、プールＩＤが００であるプールが１番目の移動先候補であり、再配置実行後の予測残運用期間が１００日であることを示している。行９ｔ５５は、プールＩＤが０８であるプールが２番目の移動先候補であり、再配置実行後の予測算運用期間が７０日であることを示している。ユーザは、選択ボタンカラム９ｔ５３上にある任意の選択ボタンを押すことにより、移動先プールを選択する。１番目の行である行９ｔ５４上の選択ボタンは、前記のとおりデフォルトボタンとして選択されており、ユーザは例えばＥｎｔｅｒキーを押す等の動作により、１番目の移動先候補であるプールを選択することもできる。

図１４に戻り、ステップＳ９ａ０３では、移動する仮想ボリュームＩＤとステップＳ９ａ０２で選択されたプールのプールＩＤとを渡して再配置実行処理Ｓ２００（図７参照）を呼び出し、仮想ボリュームを選択されたプールに移動する。ステップＳ９ａ０４では、移動した仮想ボリュームに対応する仮想ボリュームレコード３００の最終移動階層フィールド３０５に、移動先階層の値（階層ＩＤ）を書き込む。なお、別の実施形態として、ステップＳ９ａ０２でユーザにプールを選択させる代わりに、ステップＳ９ａ０１で得られたプールＩＤ一覧のうち先頭のものを自動的に選択するようにしてもよい。

図１６は、移動先プール選択処理を示すフローチャートである。移動先プール選択処理Ｓ８０１は、移動する仮想ボリュームＩＤと移動先階層ＩＤとを受け取り、存在する全プールに対して、移動する仮想ボリュームを該プールに移動した場合の予測残運用期間を計算したのち、移動先階層の階層条件に適合するプールを抽出し、それらのプールＩＤ一覧を、再配置後の予測残運用期間の平準度が高くなる順番にソートして返す。なお、移動する仮想ボリュームＩＤとして無効な値を受け取った場合には、現状の予測残運用期間を各プールについて計算したのち、移動先階層条件に適合するプールのＩＤ一覧を、再配置後の予測残運用期間の平準度が高くなる順番にソートして返す。移動先プール選択処理Ｓ８０１は、ＣＰＵ２２００により実行される。

ステップＳ９０１では、プールテーブル２１１（図１２参照）上に存在するすべてのプールに対して、ステップＳ９０２〜Ｓ９０５を繰り返す。ステップＳ９０２では、移動する仮想ボリュームＩＤが有効か否かを判定する。有効な場合は（ステップＳ９０２，Ｙｅｓ）、ステップＳ９０３に、無効な場合は（ステップＳ９０２，Ｎｏ）、ステップＳ９０４に進む。ステップＳ９０３では、移動する仮想ボリュームＩＤと該プールのプールＩＤとを渡して再配置実行後の移動先プールの残運用期間予測処理Ｓ２０１（図８参照）を呼び出す。ステップＳ９０４では、該プールのプールＩＤを渡して残運用期間予測処理Ｓ２０２（図９参照）を呼び出す。

ステップＳ９０５では、該プールに対応するプールレコード３１０の予測残運用期間フィールド３１７（図１２参照）に、直前のステップで得られた予測残運用期間を書き込む。ステップＳ９０６では、移動先階層に対応する階層レコード３４０の条件式フィールド３４２に格納された条件式に従ってプールテーブル２１１（図１２参照）を検索し、条件に適合するプールを抽出する。ステップＳ９０７では、直前のステップで抽出されたプールのＩＤ一覧を、再配置後の予測残運用期間の平準度が高くなる順に、すなわちプールレコード３１０の予測残運用期間フィールド３１７の値が大きい順にソートして返す。

本実施形態は、以下のような効果を奏する。
本実施形態は、プールを階層に分類するための階層定義を持ち、各階層の階層条件にはプールの残運用期間に関する条件を含めることができ、さらにこの階層条件の評価は再配置後のプールの予測残運用期間に基づいて行われるように構成されている。そのため、ユーザは階層条件によってプールの残運用期間を保障することができ、且つ再配置後の正確な予測に基づいて階層に適合するプールを選択することが可能となる。

本実施形態は、同一階層に複数の移動先候補プールが存在した場合に、予測残運用期間の平準度が高くなるような移動先候補プールをより好適な移動先プールとして選択するよう構成されている。そのため、ユーザは、画面上で好適な順にソートされた移動先候補プール一覧から移動先を選択するだけで、あるいは自動的に、プール枯渇に対する安全性が可能な限り高くなるような階層管理を実行することが可能となる。

《実施形態３》
本発明の実施形態３について説明する。実施形態３は、実施形態２の変形にあたる。本実施形態の特徴は、同一階層内のプールの残運用期間を平準化するために、同一階層内で仮想ボリュームを再配置する再配置プランを決定することにある。

図１７は、実施形態３の再配置制御部およびデータベースの構成を示す図である。図１１および図１２に記載の同一構成品については、同一番号を付しており、説明は省略する。再配置制御部１０１は、階層指定再配置実行処理Ｓ８００（図１１参照）を削除し、追加のモジュールとして、階層内平準化処理Ｓ１０００と、階層内平準化プラン選択処理Ｓ１００１を備える。データベース１０２は、実施形態２と同一である。

図１８は、階層内平準化処理を示すフローチャートである。階層内平準化処理Ｓ１０００は、ユーザがブラウザ１２１を介して、ある階層の平準化を指示することによって呼び出される。または何らかの契機で自動的に起動されてもよい。階層内平準化処理Ｓ１０００は、平準化対象の階層ＩＤをパラメタとして受け取る。階層内平準化処理Ｓ１０００は、ＣＰＵ２２００により実行される。

ステップＳ１１ａ０１では、平準化対象の階層ＩＤを渡して、階層内平準化プラン選択処理Ｓ１００１（図２０参照）を呼び出す。ステップＳ１１ａ０２では、ステップＳ１１ａ０１の結果として、仮想ボリュームＩＤと移動先プールＩＤの組からなる有効な平準化プランが返されたか否かを判定する。有効な平準化プランが返された場合は（ステップＳ１１ａ０２，Ｙｅｓ）、ステップＳ１１ａ０３に進み、平準化プランなしが返された場合は（ステップＳ１１ａ０２，Ｎｏ）、ステップＳ１１ａ０５に進む。

ステップＳ１１ａ０３では、図１９に示すように、平準化プラン確認画面１１ｓ０１をユーザに提示する。

図１９は、平準化プラン確認画面の具体的な表示例を示す図である。平準化プラン確認画面１１ｓ０１は、移動する仮想ボリュームＩＤが表示される領域１１ｓ０２、移動元プールのプールＩＤ、該プールの再配置前後の予測残運用期間がそれぞれ表示される領域１１ｓ１１、領域１１ｓ１２、領域１１ｓ１３を含み、且つ移動先プールのプールＩＤ、該プールの再配置前後の予測残運用期間がそれぞれ表示される領域１１ｓ２１、領域１１ｓ２２、領域１１ｓ２３を含む。また、平準化プラン確認画面１１ｓ０１は、ＯＫボタン１１ｓ３１とキャンセルボタン１１ｓ３２を含み、且つユーザに表示の意味を説明するための各種のラベルを含む。ユーザがＯＫボタン１１ｓ３１を押した場合にはステップＳ１１ａ０４に進み、キャンセルボタン１１ｓ３２を押した場合にはその時点で処理を終了する。

図１８に戻り、ステップＳ１１ａ０４では、再配置実行処理Ｓ２００（図７参照）を呼び出して、ステップＳ１１ａ０１で返された再配置プランによって指定される仮想ボリュームを移動先プールに移動し、一連の処理を終了する。ステップＳ１１ａ０５では、有効な平準化プランが存在しない、すなわち既に平準度が最も高い状態であることをユーザに示し、一連の処理を終了する。なお、ステップＳ１１ａ０１における平準化対象の階層内平準化プラン選択処理Ｓ１００１について図２０を用いて説明する。

図２０は、階層内平準化プラン選択処理を示すフローチャートである。階層内平準化プラン選択処理Ｓ１００１は、指定された階層内で仮想ボリュームを再配置することによって、階層内の複数プールの予測残運用期間が現在より平準化されるような再配置プラン（以下、「平準化プラン」という。）を返す。そのような再配置プランが存在しない場合は、再配置プランなしを返す。階層内平準化プラン選択処理Ｓ１００１は、パラメタとして、平準化対象の階層ＩＤを受け取る。

ステップＳ１１０１では、移動先プール選択処理Ｓ８０１（図１６参照）を無効な仮想ボリュームＩＤと平準化対象の階層ＩＤを渡して呼び出し、抽出されたプール一覧を平準化対象プールとする。ステップＳ１１０２では、仮想ボリュームテーブル２１０（図１２、図１７参照）を検索し、平準化対象プールに所属する全仮想ボリュームを抽出し、移動候補仮想ボリュームとする。

ステップＳ１１０３では、移動する仮想ボリュームと移動先プールの組からなる可能な再配置プランすべてについて、ステップＳ１１０４〜１１０６を繰り返す。可能な再配置プランは、移動候補仮想ボリュームのうちいずれかを移動する仮想ボリュームとし、平準化対象プールのうち移動する仮想ボリュームの所属プールを除いたいずれかを移動先プールとすることにより、得ることができる。ステップＳ１１０４では、移動する仮想ボリュームに対応する仮想ボリュームレコード３００のプールＩＤフィールド３０２（図１２参照）の値を保存し、移動先プールのプールＩＤに書き換える。ステップＳ１１０５では、平準化対象プールそれぞれに対して残運用期間予測処理Ｓ２０２（図９参照）を呼び出し予測残運用期間を求め、それらの分散を求める。ステップＳ１１０６では、ステップＳ１１０４で書き換えたプールＩＤフィールド３０２の値を元に戻す。

ステップＳ１１０７では、ステップＳ１１０５と同じ処理を行って現状の分散を求め、それがステップＳ１１０５で求められた分散のうち最小のものより大きいか否かを判定する。判定結果が真であれば（ステップＳ１１０７，Ｙｅｓ）、ステップＳ１１０８へ進み、判定結果が偽であれば（ステップＳ１１０７，Ｎｏ）、ステップＳ１１０９に進む。ステップＳ１１０８では、分散が最小となった再配置プランを平準化プランとして返す。ステップＳ１１０９では、平準化プランなしを返す。

例えば、ある階層に、容量１００００ＭＢのプールＡと容量２００００ＭＢのプールＢとが存在し、プールＡには２個、プールＢには１個の仮想ボリュームが存在したとする。さらに、すべての仮想ボリュームの実使用量およびその増加率が同一であり、実使用量は５００ＭＢ、その増加率は５０ＭＢ／日だったとする。この階層に対して階層内平準化処理Ｓ１０００（図１８）を実行すると、プールＡ上の仮想ボリュームのうち１つをプールＢに再配置する再配置プランが選択され、図１９に示す内容の平準化プラン確認画面が表示されることになる。

なお、平準化プランの選択にはここで示した以外の任意の最適化アルゴリズムを用いることができる。また、本実施形態では再配置プランは単一の仮想ボリュームの移動のみが含まれるが、複数の仮想ボリュームの移動を含むように拡張することは容易である。

以上のように、本実施形態は、同一階層内でプールの残運用期間を平準化するために有効な再配置プラン（移動する仮想ボリュームと移動先プールの組）を決定するよう構成されている。そのため、ユーザは、プール枯渇に対する安全性を増すために再配置を実行することが簡単にできるようになる。

《実施形態４》
本発明の実施形態４を説明する。実施形態４は、実施形態２の変形にあたる。本実施形態の特徴は、階層間で仮想ボリュームを再配置する際に、階層の特性差に基づいて、再配置前後の使用量増加傾向の変化を予測し、再配置後の残運用期間の予測に補正を加える点にある。

図２１は、実施形態４の再配置制御部の構成を示す図である。図１１に記載の同一構成品については、同一番号を付しており、説明は省略する。再配置制御部１０１は、追加モジュールとして、バイアス補正付き再配置実行後の移動先プールの残運用期間予測処理Ｓ１２００と、予測用情報バイアス補正処理Ｓ１２０１を備える。また、実施形態２における階層指定再配置実行処理Ｓ８００および移動先プール選択処理Ｓ８０１の変形である階層指定再配置実行処理Ｓ８００ａおよび移動先プール選択処理Ｓ８０１ａを備える。

図２２は、実施形態４のデータベースの構成を示す図である。図１２に記載の同一構成品については、同一番号を付しており、説明は省略する。階層テーブル２１４は、追加のフィールドとして、使用量増加バイアスフィールド３４３を有する。

使用量増加バイアスフィールド３４３は、該階層における使用量増加の傾向を、階層間の相対比率で表した値である。すなわち、頻繁に読み書きされ使用量が増加しやすい用途で用いる階層には大きな値を、逆に書き込みアクセスが少ない用途で用いる階層には小さな値を設定する。使用量増加バイアスフィールド３４３への値の設定は、条件式フィールド３４２と同様にユーザが行ってもよいし、条件式フィールド３４２に性能種別が条件として指定されている場合、その性能に応じて（すなわち高速な性能種別の場合には大きな値を、低速な性能種別の場合には小さな値を）自動的に設定するようにしてもよい。

図２３は、実施形態４の階層指定再配置実行処理を示すフローチャートである。階層指定再配置実行処理Ｓ８００ａは、実施形態２で説明した階層指定再配置実行処理Ｓ８００（図１４参照）に１ステップを追加したものである。すなわち、図２３に示すように、ステップＳ９ａ０３とステップＳ９ａ０４の間にステップＳ１３ａ０１が追加されている。ステップＳ１３ａ０１では、直前のステップで移動した仮想ボリュームＩＤと移動先階層ＩＤをパラメタとして渡し、予測用情報バイアス補正処理Ｓ１２０１（図２６参照）を呼び出す。

図２４は、実施形態４の移動先プール選択処理を示すフローチャートである。移動先プール選択処理Ｓ８０１ａは、実施形態２で説明した移動先プール選択処理Ｓ８０１（図１６参照）の１ステップを置き換えたものである。図２４に示すように、ステップＳ９０３がステップＳ１３ｂ０１で置き換えられている。ステップＳ１３ｂ０１では、バイアス補正付き再配置実行後の移動先プールの残運用期間予測処理Ｓ１２００（図２５参照）を、移動する仮想ボリュームＩＤ、ループ９０１で処理中のプールのプールＩＤ、移動先階層ＩＤを渡して呼び出す。

図２５は、バイアス補正付き再配置実行後の移動先プールの残運用期間予測処理を示すフローチャートである。図２５を用いて、バイアス補正付き再配置実行後の移動先プールの残運用期間予測処理Ｓ１２００の処理内容について、順を追って説明する。バイアス補正付き再配置実行後の移動先プールの残運用期間予測処理Ｓ１２００は、移動する仮想ボリュームＩＤ、移動先プールＩＤ、移動先階層ＩＤをパラメタとして受け取り、階層間の使用量増加バイアスの違いにより補正された移動先プールの予測残運用期間を返す。

ステップＳ１３０１では、再配置実行後の移動先プールの残運用期間予測処理Ｓ２０１（図８参照）を、移動する仮想ボリュームＩＤと移動先プールＩＤを渡して呼び出す。ステップＳ１３０２では、移動元階層と移動先階層の使用量増加バイアスの比を取得する。移動先階層の使用量増加バイアスは、移動先階層に対応する階層レコード３４０の使用量増加バイアスフィールド３４３（図２２参照）の値を取得することで求められる。移動元階層の使用量増加バイアスは、まず移動する仮想ボリュームに対応する仮想ボリュームレコード３００の最終移動階層フィールド３０５（図１２参照）の値（階層ＩＤ）を取得し、次にその階層に対応する階層レコード３４０の使用量増加バイアスフィールド３４３の値を取得することで求められる。使用量増加バイアス比は、移動先階層の使用量増加バイアスを移動元階層の使用量増加バイアスで割ることで求められる。ステップＳ１３０３では、ステップＳ１３０１で得られた予測残運用期間に、ステップＳ１３０２で得られた使用量増加バイアス比を掛け、その結果を戻り値として返す。

図２６は、予測用情報バイアス補正処理を示すフローチャートである。図２６を用いて、予測用情報バイアス補正処理Ｓ１２０１の処理内容について、順を追って説明する。予測用情報バイアス補正処理Ｓ１２０１は、移動する仮想ボリュームＩＤ、移動先階層ＩＤをパラメタとして受け取り、仮想ボリューム使用量予測関数テーブル２１２（図５（ｃ）参照）および仮想ボリューム使用量履歴テーブル２１３（図５（ｄ）参照）の内容を、階層間の使用量増加バイアスの違いに基づいて補正する。

ステップＳ１３１１では、ステップＳ１３０２（図２５参照）と同じ方法により、移動元階層と移動先階層の使用量増加バイアスの比を取得する。ステップＳ１３１２では、移動する仮想ボリュームに対応する仮想ボリューム使用量予測関数レコード３２０（図５（ｃ）参照）の一次係数フィールド３２２を、現在の値にステップＳ１３１１で求められた使用量増加バイアス比を掛けた値で更新する。ステップＳ１３１３では、移動する仮想ボリュームに対応するすべての仮想ボリューム使用量履歴レコード３３０（図５（ｄ）参照）の実使用量フィールド３３３を、現在の値にステップＳ１３１１で求められた使用量増加バイアス比を掛けた値で更新する。

本実施形態では、階層定義に基づいて、仮想ボリュームの再配置に伴う該仮想ボリュームの使用量増加傾向の変化を予測し、再配置後の残運用期間の予測を補正するよう構成されている。そのため、性能が異なる階層間での再配置のように、再配置によって仮想ボリュームの使用量増加傾向が変化する場合にも、その変化を考慮して適切に再配置を行うことが簡単にできる。

《実施形態５》
本発明の第５の実施形態を説明する。実施形態５は、実施形態２の変形にあたる。本実施形態の特徴は、優先度が付けられた複数の移動先候補階層からなるユーザ定義の階層選択ポリシーに基づいて、プールの予測残運用期間を考慮しつつ、複数の階層から移動可能且つ最も好適な移動先階層を選択し、その階層の中から移動先プールを選択する点にある。

本実施形態の他の特徴は、移動先階層選択ポリシーを構成する移動先候補階層の中に、プールにより構成される階層と、プールとして使われていない通常ボリュームにより構成される階層とを混在させることができ、それらの中から容量オーバヘッドを考慮して移動先を選択する点にある。

本実施形態のさらに他の特徴は、各仮想ボリュームについて、前回の移動先階層よりも好適な階層に移動可能か否かを調べ、もし可能ならば該仮想ボリュームの該階層への再配置を行うことにより、データの配置を状況に合わせて最も好適な状態に保つ点にある（以下、このような再配置を「好適化再配置」という。）。

図２７は、実施形態５の再配置制御部の構成を示す図である。図１１に記載の同一構成品については、同一番号を付しており、説明は省略する。再配置制御部１０１は、階層指定再配置実行処理Ｓ８００を削除し、追加のモジュールとして、ポリシー指定再配置実行処理Ｓ１９００、ポリシー指定移動先プール選択処理Ｓ１９０１、好適化再配置処理Ｓ１７００、および好適化再配置プラン選択処理Ｓ１７０１を備える。

図２８は、実施形態５のデータベースの構成を示す図である。図１２に記載の同一構成品については、同一番号を付しており、説明は省略する。データベース１０２は、追加のテーブルとして、ポリシーテーブル２１５、移動状況テーブル２１６、通常ボリュームテーブル２１７を備える。階層テーブル２１４は、追加のフィールドとして、階層種別フィールド３４４（図２９（ａ）参照）を備える。

図２９は、階層テーブル、ポリシーテーブル、移動状況テーブル、および通常ボリュームテーブルの構成を示す図である。図２９（ａ）に示すように、階層テーブル２１４の階層種別フィールド３４４には、階層がプール１１３または通常ボリューム１１２のどちらから構成されるかを示す「プール」または「通常ボリューム」の二値が格納される。前者の場合、条件式フィールド３４２には、実施形態２で説明したように、プール１１３を選択するための条件を、プールレコード３１０に対する条件式として記述する。一方、後者の場合、条件式フィールド３４２には、通常ボリューム１１２を選択するための条件を、通常ボリュームレコード３７０に対する条件式として記述する。これにより、階層テーブル２１４に、プール１１３から構成される階層と通常ボリューム１１２から構成される階層とを混在させることが可能となる。

図２９（ｂ）のポリシーテーブル２１５は、ポリシーに含まれる移動先候補階層に対応するポリシーレコード３５０の集合からなる。ポリシーレコード３５０は、少なくとも、該レコードが構成するポリシーの名称を表すポリシーＩＤフィールド３５１、候補の順位を表す優先度フィールド３５２、移動先階層を表す階層フィールド３５３、容量効率フィールド３５４を含む。優先度フィールド３５２は整数値であり、値が小さいほどその移動先候補階層がユーザにとって好適であり、再配置先として優先的に採用すべきであることを表す。容量効率フィールド３５４は、階層フィールド３５３によって示される階層の階層種別が「通常ボリューム」の場合にのみ意味を持つ値であり、該階層への再配置が許可されるために必要な容量効率（ボリューム容量に対する実使用量の割合）の最小値が格納される。容量効率フィールド３５４の値は、仮想ボリュームから通常ボリュームへの再配置の際に発生する容量オーバヘッドをどれだけ許容するかに基づいて、ユーザが決定する。

図２９（ｃ）の移動状況テーブル２１６は、各仮想ボリュームについて、最後の再配置実行時に適用されたポリシーおよび採用された移動先候補階層の優先度を記録する、移動状況レコード３６０の集合からなる。移動状況レコード３６０は、少なくとも、仮想ボリュームＩＤフィールド３６１、最後の再配置実行時に適用されたポリシーのＩＤを格納する最終適用ポリシーフィールド３６２、最後の再配置実行時に採用された移動先候補階層の優先度を格納する最終適用優先度フィールド３６３からなる。

図２９（ｄ）の通常ボリュームテーブル２１７は、ストレージ装置１１０上の各通常ボリューム１１２の属性情報および使用状態を格納する通常ボリュームレコード３７０の集合から構成される。通常ボリュームレコード３７０は、少なくとも、通常ボリュームのＩＤを格納する通常ボリュームＩＤフィールド３７１、通常ボリュームの属性情報である容量、ＲＡＩＤ種別、性能種別をそれぞれ格納する容量フィールド３７２、ＲＡＩＤ種別フィールド３７３、性能種別フィールド３７４、および通常ボリュームが使用中か否かを「使用中」または「未使用」の二値で表す使用状態フィールド３７５を有する。プールの一部となっている通常ボリュームの使用状態は、常に「使用中」とする。

ここで、ポリシーの意味をよりわかりやすく説明するために、図３０を用いて階層テーブル２１４およびポリシーテーブル２１５の構成例について説明する。

図３０は、階層テーブルおよびポリシーテーブルの構成例を示す図である。図３０（ａ）は、階層テーブル２１４の構成を示し、階層レコード３４０ａは、信頼性の高いＲＡＩＤ種別で構成された高速ディスクから成り、且つ予測残運用期間が１４日以上であるプールを条件とする「高速高信頼」階層を表す。階層レコード３４０ｂは、信頼性中程度のＲＡＩＤ種別で構成された高速なディスクから成り、且つ予測残運用期間が７日以上であるプールを条件とする「高速」階層を表す。階層レコード３４０ｃは、信頼性中程度のＲＡＩＤ種別で構成された低速なディスクから成り、且つ予測残運用期間が７日以上であるプールを条件とする「低速」階層を表す。階層レコード３４０ｄは、信頼性中程度のＲＡＩＤ種別で構成された高速なディスク上の通常ボリュームを条件とする「超高速」階層を表す。ここで、階層レコード３４０ｄが表す階層は通常ボリュームにより構成される階層であるため、プールから構成される他の階層とは異なり、条件式の中に予測残運用期間に関する条件は含まれない。

図３０（ｂ）は、ポリシーテーブル２１５の構成を示し、ポリシーレコード３５０ａと３５０ｂは、「高速高信頼」階層を最も好ましい候補とし、「高速」階層を次いで好ましい候補とする「信頼性妥協」ポリシーを構成する。このポリシーは、できる限り高速で高信頼な階層を使用したいが、もしその階層に十分な残運用期間を確保できなければ、信頼性の程度の落ちる別の階層を使用してもよい、というユーザの意図を表現したものである。

ポリシーレコード３５０ｃと３５０ｄは、「高速」階層を最も好ましい候補とし、「低速」階層を次いで好ましい候補とする「性能妥協」ポリシーを構成する。このポリシーは、できる限り高速な階層を使用したいが、もしその階層に十分な残運用期間を確保できなければ、性能の落ちる別の階層を使用してもよい、というユーザの意図を表現したものである。

ポリシーレコード３５０ｅ、３５０ｆ、３５０ｇは、「高速」階層を最も好ましい候補とし、「高速信頼性」階層を次いで好ましい候補とし、「超高速」階層を最後に好ましい候補とする「コスト妥協」ポリシーを構成する。このポリシーは、信頼性が中程度のコストパフォーマンスの高い階層を使いたいが、もしその階層に十分な残運用期間を確保できなければ、コストの高い高信頼性階層を使用してもよい、というユーザの意図を表現したものである。さらに、高信頼性階層さえも使用できない場合には、利用率が６０％以上となるのであれば（すなわち移動する仮想ボリュームの仮想容量に対する実使用量の割合が６０％以上であれば）通常ボリュームからなる階層を使用してもよい、というユーザの意図を表現している。

次に、ユーザがある仮想ボリュームをあるポリシーに従って再配置することを指示し、指定した仮想ボリュームを再配置する方法について、図３１、図３２、図３３、図３４、図３５、図３６を用いて説明する。ユーザに指定されたポリシーに従って再配置を行う際に働くモジュールとして、ポリシー指定再配置実行処理Ｓ１９００（図３２参照）、ポリシー指定移動先プール選択処理Ｓ１９０１（図３４参照）がある。さらに、好適化再配置を行う際に働くモジュールとして好適化再配置処理Ｓ１７００（図３５参照）、好適化再配置プラン選択処理Ｓ１７０１（図３６参照）がある。

図３１は、ポリシー指定再配置指示画面を示す図である。図３１を用いて、ユーザがある仮想ボリュームをあるポリシーに従って再配置することを指示し、ポリシー指定再配置実行処理Ｓ１９００を呼び出すための操作方法について説明する。ポリシー指定再配置指示画面２０ｓ０１は、ツリー領域４ｓ０２、プール情報領域４ｓ０３、仮想ボリューム情報領域４ｓ０４、ポリシー指示領域２０ｓ０２を含む。ここで、ツリー領域４ｓ０２、プール情報領域４ｓ０３、仮想ボリューム情報領域４ｓ０４は、実施形態１（図６参照）で説明したものと同一である。ポリシー指示領域２０ｓ０２には、ポリシーテーブル２１５上に登録されている各ポリシーに対応する矩形がポリシーＩＤとともに一覧表示される。図３１には、ポリシーＩＤが「信頼性妥協」「性能妥協」「コスト妥協」であるポリシーに対応する矩形２０ｓ２０、矩形２０ｓ２１、矩形２０ｓ２２がそれぞれ表示されている様子を表している。

ユーザは、ツリー領域４ｓ０２上の仮想ボリュームを表すノードを、ポリシー指示領域２０ｓ０２上のいずれかの矩形の上にマウスを用いてドラッグアンドドロップすることにより、ある仮想ボリュームをあるポリシーに従って再配置することを指示することができる。例えば、ノード４ｓ２０を矩形２０ｓ２０の上にドラッグアンドドロップすることにより、仮想ボリュームＩＤが００００である仮想ボリュームをポリシーＩＤが「信頼性妥協」であるポリシーに従って再配置することを指示することができる。このように、ユーザが図３１のポリシー指定再配置指示画面２０ｓ０１により再配置指示を出すと、図３２に示すように、ポリシー指定再配置実行処理Ｓ１９００が実行される。

図３２は、ポリシー指定再配置実行処理を示すフローチャートである。ポリシー指定再配置実行処理Ｓ１９００は、ユーザがブラウザ１２１を介して、後述する操作方法により、ある仮想ボリュームをあるポリシーに従って再配置することを指示することにより呼び出される。ポリシー指定再配置実行処理Ｓ１９００は、移動する仮想ボリュームＩＤと、ポリシーＩＤとをパラメタとして受け取る。ポリシー指定再配置実行処理Ｓ１９００は、ＣＰＵ２２００により実行される。

ステップＳ２００１では、移動する仮想ボリュームＩＤとポリシーＩＤとを渡して、ポリシー指定移動先プール選択処理Ｓ１９０１（図３４参照）を呼び出す。ステップＳ２００２では、ステップＳ２００１の戻り値の種別を判定する。プールＩＤ一覧の場合（ステップＳ２００２，プールＩＤ一覧）、ステップＳ２００３に進む。通常ボリュームＩＤの場合（ステップＳ２００２，通常ボリュームＩＤ）、ステップＳ２０１０に進む。空の場合（ステップＳ２００２，空）、ステップＳ２０２０に進む。

ステップＳ２００３では、ステップＳ２００１で得られたプールＩＤ一覧を用いて、プールの属性情報と選択ボタンとを各行に含む移動先候補プール一覧表を作成してブラウザ１２１を介して、図３３に示すようにユーザに提示し、ユーザがいずれかの選択ボタンを押すのを待つ。各行に含まれるプールの属性情報は、少なくとも各プールのＩＤと予測残運用期間とを含む。一覧表の先頭行の選択ボタンをデフォルトボタンとして設定する。さらに、一覧表のヘッダとして、ステップＳ２００１で得られた階層ＩＤを含める。

図３３は、移動先候補プール一覧表の具体的な表示例を示す図である。移動先候補プール一覧表２０ｔ０５は、カラムとしてプールＩＤカラム２０ｔ５１、予測残運用期間カラム２０ｔ５２、選択ボタンカラム２０ｔ５３を含み、さらに移動先として選択された階層を表示するヘッダ領域２０ｔ０６を含む。ここに例示されているヘッダ領域２０ｔ０６は、移動先として階層ＩＤが「高速」である階層が選択されたことを示している。行２０ｔ５４は、プールＩＤが００であるプールが１番目の移動先候補であり、再配置実行後の予測残運用期間が１００日であることを示している。行２０ｔ５５は、プールＩＤが０８であるプールが２番目の移動先候補であり、再配置実行後の予測算運用期間が７０日であることを示している。ユーザは、選択ボタンカラム２０ｔ５３上にある任意の選択ボタンを、マウスを用いてクリックすることにより、移動先プールを選択する。１番目の行である行２０ｔ５４上の選択ボタンはデフォルトボタンとして選択されており、ユーザは例えばＥｎｔｅｒキーを押す等の動作により、１番目の移動先候補であるプールを選択することもできる。

図３２に戻り、ステップＳ２００４では、再配置実行処理Ｓ２００（図７参照）を呼び出し、パラメタとして与えられた仮想ボリュームを、ステップＳ２００３で選択されたプールに移動する。ステップＳ２００５では、仮想ボリュームレコードの最終移動階層フィールドを更新する処理として、移動した仮想ボリュームに対応する仮想ボリュームレコード３００の最終移動階層フィールド３０５（図１２参照）に、移動先階層の値（階層ＩＤ）を書き込む。ステップＳ２００６では、移動した仮想ボリュームに対応する移動状況レコード３６０（図２９（ｃ）参照）の最終適用ポリシーフィールド３６２と最終適用優先度フィールド３６３に、今回用いたポリシーＩＤとステップで得られた優先度とをそれぞれ更新し格納する。そして、一連の処理を終了する。

ステップＳ２０１０では、ステップＳ２００１で得られた通常ボリュームＩＤを用いて、通常ボリュームの属性情報と確認ボタンとをブラウザ１２１を介してユーザに提示し、ユーザが確認ボタンを押すのを待つ。ステップＳ２０１１では、ＤＫＣ１１１に指示して、指定された仮想ボリュームをステップＳ２００１で得られた通常ボリュームに再配置する。ステップＳ２０１２では、仮想ボリュームテーブル２１０、仮想ボリューム使用量予測関数テーブル２１２、仮想ボリューム使用量履歴テーブル２１３、移動状況テーブル２１６から、移動した仮想ボリュームに関連するレコードを削除する。そして、一連の処理を終了する。なお、ステップＳ２０２０では、ブラウザ１２１を介してユーザにエラーを表示し、一連の処理を終了する。

なお、別の実施形態として、ステップＳ２００３において、ユーザにプールを選択させる代わりに、ステップＳ２００１で得られたプールＩＤ一覧のうち先頭のものを自動的に選択するようにしてもよい。

図３４は、ポリシー指定移動先プール選択処理を示すフローチャートである。ポリシー指定移動先プール選択処理Ｓ１９０１は、移動する仮想ボリュームＩＤと、移動先選択に使用するポリシーＩＤとを受け取り、ポリシーに従って選択された移動先階層のＩＤおよび優先度を返すとともに、移動先階層種別がプールの場合は移動先候補プールのＩＤ一覧を予測残運用期間が大きいものから順番にソートしたものを、移動先階層種別が通常ボリュームの場合は移動先候補のボリュームＩＤを、それぞれ返す。移動先として適切なプールまたは通常ボリュームが見つからなかった場合には、空を返す。ポリシー指定移動先プール選択処理Ｓ１９０１は、ＣＰＵ２２００により実行される。

ステップＳ２１０１では、指定されたポリシーＩＤに関連するポリシーレコード３５０（図２９（ｂ）参照）をすべて選択し、優先度フィールド３５２が小さい順にステップＳ２１０２〜Ｓ２１０４およびステップＳ２１０９〜Ｓ２１１１を繰り返す。ステップＳ２１０２では、処理中のポリシーレコード３５０の階層フィールド３５３で表される階層の種別を、階層レコード３４０（図２９（ａ）参照）の階層種別フィールド３４４を参照して判定する。階層の種別が「プール」の場合は（ステップＳ２１０２、プール）、ステップＳ２１０３に進み、「通常ボリューム」の場合は（ステップＳ２１０２、通常ボリューム）、ステップＳ２１０９に進む。

ステップＳ２１０３では、移動する仮想ボリュームＩＤと、処理中のポリシーレコード３５０の階層フィールド３５３の値を渡して移動先プール選択処理Ｓ８０１（図１６参照）を呼び出す。ステップＳ２１０４では、選択されたプールＩＤ一覧が空か否かを判定する。判定結果が空の場合は（ステップＳ２１０４，Ｙｅｓ）、繰り返し処理を続行し、判定結果が空でない場合は（ステップＳ２１０４，Ｎｏ）、ステップＳ２１０５に進む。ステップＳ２１０５では、処理中だったポリシーレコード３５０の階層フィールド３５３と優先度フィールド３５２の値、およびステップＳ２１０３で得られたプールＩＤ一覧を返して、一連の処理を終了する。

ステップＳ２１０９では、移動する仮想ボリュームの容量効率（仮想容量に対する実使用量の割合）を求め、その値が処理中のポリシーレコード３５０の容量効率フィールド３５４の値以上か否かを判定する。判定結果が真の場合は（ステップＳ２１０９，Ｙｅｓ）、ステップＳ２１１０に進み、判定結果が偽の場合は（ステップＳ２１０９，Ｎｏ）、繰り返し処理を続行する。

ステップＳ２１１０では、仮想ボリュームと容量が同じで、且つ処理中のポリシーレコード３５０の階層フィールド３５３で表される階層に対応する階層レコード３４０の条件式フィールド３４２に適合する未使用通常ボリュームを、通常ボリュームテーブル２１７から検索（選択）する。ステップＳ２１１１では、ステップＳ２１１０の結果通常ボリュームが見つかったか否かを判定する。見つからなかった場合は（ステップＳ２１１１，Ｙｅｓ）、繰り返し処理を続行し、見つかった場合（ステップＳ２１１１，Ｎｏ）、ステップＳ２１１２に進む。ステップＳ２１１２では、処理中だったポリシーレコード３５０の階層フィールド３５３と優先度フィールド３５２の値、およびステップＳ２１１０で得られた通常ボリュームＩＤを返し、一連の処理を終了する。なお、ステップＳ２１２０では、空を返して、一連の処理を終了する。

図３５は、好適化再配置処理を示すフローチャートである。好適化再配置処理Ｓ１７００は、ユーザがブラウザ１２１を介して好適化再配置を指示することによって呼び出される。または何らかの契機で自動的に起動されてもよい。以下、好適化再配置処理Ｓ１７００の処理内容を、図３５を用いて詳細に説明する。好適化再配置処理Ｓ１７００は、ＣＰＵ２２００により実行される。

ステップＳ１８ａ０１では、好適化再配置プラン選択処理Ｓ１７０１（図３６参照）を呼び出す。ステップＳ１８ａ０２では、ステップＳ１８ａ０１で得られた再配置プラン候補一覧が空か否かを判定する。判定結果が空でない場合は（ステップＳ１８ａ０２，Ｎｏ）、ステップＳ１８ａ０３に、判定結果が空の場合は（ステップＳ１８ａ０２，Ｙｅｓ）、ステップＳ１８ａ０５に進む。

ステップＳ１８ａ０３では、ステップＳ１８ａ０１で得られた再配置プラン候補一覧を用いて、再配置プランの属性値と選択ボタンとを各行に含む再配置プラン候補一覧表を作成してブラウザ１２１を介してユーザに提示し、ユーザがいずれかの選択ボタンを押すのを待つ。各行に含まれる再配置プランの属性は、仮想ボリュームＩＤ、最終適用ポリシーＩＤ，最終移動階層ＩＤ、移動先階層ＩＤを含む。ステップＳ１８ａ０４では、ユーザが選択した再配置プランについて、その仮想ボリュームＩＤと前回適用されたポリシーＩＤとを渡してポリシー指定再配置実行処理Ｓ１９００（図３２参照）を呼び出す。その後、一連の処理を終了する。ステップＳ１８ａ０５では、現時点で好適化再配置はできないことをユーザに提示し、一連の処理を終了する。

なお、別の実施形態として、ステップＳ１８ａ０３において、ユーザが複数の再配置プランを選択できるようにし、ステップＳ１８ａ０４をそれらの再配置プランに対して繰り返し適用してもよい。また、ステップＳ１８ａ０３において、ユーザに再配置プランを選択させる代わりに、再配置プラン候補一覧の一部またはすべてを自動的に実行してもよい。

図３６は、好適化再配置プラン選択処理を示すフローチャートである。図３６を用いて好適化再配置プラン選択処理Ｓ１７０１を詳細に説明する。ステップＳ１８０１では、すべての移動状況レコード３６０に対してステップＳ１８０２〜１８０４を繰り返す。ステップＳ１８０２では、該移動状況レコード３６０上の仮想ボリュームＩＤフィールド３６１と最終適用ポリシーフィールド３６２の値を用いて、ポリシー指定移動先プール選択処理Ｓ１９０１（図３４参照）を呼び出す。

ステップＳ１８０３では、ステップＳ１８０２で得られたプールＩＤ一覧が空でなく、且つステップＳ１８０２で得られた優先度の値が、該移動状況レコード３６０上の最終適用優先度フィールド３６３の値よりも小さいか否かを判定する。判定結果が真の場合は（ステップＳ１８０３，Ｙｅｓ）、ステップＳ１８０４に進み、判定結果が偽の場合は（ステップＳ１８０３，Ｎｏ）、繰り返し処理を続行する。

ステップＳ１８０４では、再配置プラン候補一覧に、仮想ボリュームＩＤ、最終適用ポリシーＩＤ、最終移動階層ＩＤ、移動先階層ＩＤの組からなる再配置プラン候補情報を追加する。仮想ボリュームＩＤとして該移動状況レコード３６０上の仮想ボリュームＩＤフィールド３６１の値を、最終適用ポリシーＩＤとして該移動状況レコード３６０上の最終適用ポリシーフィールド３６２の値を、最終移動階層ＩＤとして仮想ボリュームＩＤに対応する仮想ボリュームレコード３００の最終移動階層フィールド３０５の値を、移動先階層ＩＤの値としてステップＳ１８０２で得られた階層ＩＤを、それぞれ使用する。ステップＳ１８０５では、それまでのステップで作成された再配置プラン候補一覧を返して、一連の処理を終了する。

以上のように、本実施形態は、優先度が付けられた複数の移動先候補階層からなるユーザ定義の階層選択ポリシーに基づいて、プールの予測残運用期間を考慮しつつ、複数の階層から移動可能且つ最も好適な階層を選択するとともに、該階層から最適な移動先プールを選択するよう構成されている。そのため、ユーザは、予測残運用期間を守りつつ、複数の階層の中から柔軟に移動先プールを選択することが簡単にできるようになる。

また、本実施形態は、プールからなる階層と通常ボリュームからなる階層とを混在させて移動先選択ポリシーを構成し、さらに仮想ボリュームを通常ボリュームに再配置した際の容量効率の低下を加味して移動先階層を選択するよう構成されている。したがって、移動先としてプールまたは通常ボリュームのどちらを利用するかを、残運用期間の要件や容量効率低下の要件のバランスをみて適切に判断し、ユーザの再配置作業を効率化することができる。

また、本実施形態は、各仮想ボリュームについて、前回の移動先階層よりも好適な階層に移動可能かどうかを調べ、もし存在すれば該仮想ボリュームの該階層への再配置プラン（好適化再配置プラン）をユーザに提示し、実行する。そのため、ユーザは、状況の変化に応じてより好適な階層に再配置可能な仮想ボリュームを簡単に発見し、再配置を実行することができるようになる。例えば、プールの予測残運用期間が確保できないために一時的に二番目に好適な階層に配置されていた仮想ボリュームを、プールの容量を増やした後に最好適な場所に再配置し直す、といったことが簡単に行えるようになる。

《実施形態６》
本発明の実施形態６を説明する。実施形態６は、実施形態２の変形にあたる。本実施形態の特徴は、同一プールに配置することが好ましくない複数の仮想ボリューム（例えば主系と待機系とで使用している複数の仮想ボリュームや、アクセス負荷分散のためにデータを分散して格納している複数の仮想ボリューム）を、ユーザが同一のプールに誤って配置してしまうことを防ぐように構成されている点にある。そのために、本実施形態は、２つの仮想ボリュームが互いに同一プールに属してはならないことを表す排他制約の複数からなる排他制約定義に基づいて、それらの排他制約を守りつつ移動先プールを決定するように構成されている。

図３７は、実施形態６の再配置制御部の構成を示す図である。図１１に記載の同一構成品については、同一番号を付しており、説明は省略する。再配置制御部１０１は、追加のモジュールとして、排他制約違反プール除去処理Ｓ２３００を備える。また、移動先プール選択処理が一部変更されており後述する。

図３８は、実施形態６のデータベースの構成を示す図である。図１２に記載の同一構成品については、同一番号を付しており、説明は省略する。データベース１０２は、追加のテーブルとして、排他制約テーブル２１８を備える。

排他制約テーブル２１８は、個々の排他制約を表す排他制約レコード３８０の集合から構成される。排他制約レコード３８０は、少なくとも、互いに同一プールに属してはならない２つの仮想ボリュームＩＤを格納する、仮想ボリュームＩＤ１フィールド３８１および仮想ボリュームＩＤ２フィールド３８２を有する。

図３９は、実施形態６の移動先プール選択処理を示すフローチャートである。移動先プール選択処理Ｓ８０１ｂは、実施形態２で説明した移動先プール選択処理Ｓ８０１に１ステップを追加したものである。図３９に示すように、ステップＳ９０６とステップＳ９０７の間にステップＳ２４ａ０１が追加されている。ステップＳ２４ａ０１では、移動する仮想ボリュームＩＤと、直前のステップで抽出されたプールのプールＩＤ一覧とを渡して排他制約違反プール除去処理Ｓ２３００（図４０参照）を呼び出す。

図４０は、排他制約違反プール除去処理を示すフローチャートである。排他制約違反プール除去処理Ｓ２３００は、仮想ボリュームＩＤとプールＩＤ一覧とをパラメタとして受け取り、受け取った仮想ボリュームＩＤで表される仮想ボリュームとの間に排他制約が定義されている仮想ボリュームを含むプールのプールＩＤを、渡されたプールＩＤ一覧から取り除いた結果得られたプールＩＤ一覧を返す。

ステップＳ２４０１では、排他制約テーブル２１８を検索し、受け取った仮想ボリュームＩＤで指定される仮想ボリュームとの間に排他制約が定義されている仮想ボリュームの仮想ボリュームＩＤをすべて抽出する。すなわち、仮想ボリュームＩＤ１フィールドが受け取った仮想ボリュームＩＤに等しい排他制約レコード３８０の仮想ボリュームＩＤ２フィールドの値と、仮想ボリュームＩＤ２フィールドが受け取った仮想ボリュームＩＤに等しい排他制約レコード３８０の仮想ボリュームＩＤ１フィールドの値とをすべて抽出する。例えば、図３８に例示された排他制約テーブル２１８においては、受け取った仮想ボリュームＩＤが００００の場合、抽出結果は０００１となる。また、受け取った仮想ボリュームＩＤが０００１の場合、抽出結果は００００および０００２となる。

ステップＳ２４０２では、ステップＳ２４０１で抽出された仮想ボリュームＩＤに関連する仮想ボリュームレコード３００をすべて検索し、それらのレコードのプールＩＤフィールド３０２の値をすべて取得することにより、前記抽出された各仮想ボリュームＩＤに対応する仮想ボリュームが属するプールのプールＩＤをすべて取得する。ステップＳ２４０３では、パラメタで指定されたプールＩＤ一覧から、ステップＳ２４０２で取得されたプールＩＤをすべて取り除き、その結果得られたプールＩＤ一覧を返す。そして、一連の処理を終了する。

以上のように、本実施形態は、２つの仮想ボリュームが互いに同一プールに属してはならないことを表す排他制約の複数からなる排他制約定義に基づいて、それらの排他制約を守りつつ移動先プールを決定するよう構成されている。そのため、ユーザは、例えば主系と待機系とで使用している複数の仮想ボリュームや、アクセス負荷分散のためにデータを分散して格納している複数の仮想ボリュームといった、同一プールに配置することが好ましくない複数の仮想ボリュームが、必ず異なるプールに配置されるような再配置を実行することが簡単にできるようになる。

本発明は、シン・プロビジョニングにより構築された仮想ボリュームを、プール枯渇に対する安全性を確保しつつ再配置することができる再配置システムおよび再配置方法を提供することができる。さらに、プール枯渇に対する安全性を確保しつつ、階層管理された複数のプール間での最適な仮想ボリューム再配置プランの決定を支援するための再配置システムおよび再配置方法を提供することができる。各実施形態の特徴を下記に示す。

実施形態１においては、仮想ボリュームの再配置前後のプール枯渇までの期間を予測し、予測結果に基づいて仮想ボリュームの再配置動作を制御することができる。

実施形態２においては、仮想ボリュームを管理する管理サーバ１００は、プールを階層に分類する複数の条件からなる階層定義を記憶する記憶部（例えば、階層テーブル２１４）と、記憶部の条件を考慮して前記プールの枯渇までの期間を予測する予測部（例えば、残運用期間予測処理Ｓ２０２）と、予測部の予測結果に基づいて移動先候補となるプールを選択する選択部（例えば、移動先プール選択処理Ｓ８０１）と、選択部で選択された移動先候補のひとつのプールに前記仮想ボリュームを再配置させる再配置部（例えば、再配置実行処理Ｓ２００）とを備えたことを特徴とする。このような構成によれば、階層管理されたプール間での仮想ボリューム再配置に際して、プール枯渇に対する安全性を確保しつつ最適な移動先プールを選択するために、あらかじめ設定された条件を用いてプールを階層に分類し、指定された階層から最適な移動先プールを選択し、且つ、設定された条件にはプール枯渇までの期間に関する条件を含むことができ、プール枯渇までの期間に関する条件を予測に基づいて評価することができる。

実施形態３では、プール枯渇が発生する危険がより低い状態に仮想ボリュームを再配置するために、複数プール間の枯渇までの期間を平準化するような仮想ボリューム再配置プランを、予測に基づいて決定することができる。

実施形態４では、アクセス頻度が異なる階層間での仮想ボリューム再配置に際して、枯渇までの期間の予測を正確に行うために、階層間のアクセス頻度特性の差に基づいて予測に補正を加えることができる。

実施形態５では、プール枯渇の危険性等の理由により移動先として本来好適な階層への再配置を回避し、次善策として別の階層への再配置を実行可能とするために、あらかじめ設定された階層選択ポリシーに従って、複数の階層から最も好適な階層を選択し、前記最も好適な階層から移動先プールを選択することができる。

また、実施形態５では、前記次善策に従って再配置を行った後で、データ配置状態をより好適なものとするために、好適でない配置状態の仮想ボリュームをより好適な階層に再配置するための実行可能な再配置プランを決定することができる。

さらに、実施形態５では、プールからなる階層と通常ボリュームからなる階層を混在することを許容し、仮想ボリュームを通常ボリュームに再配置した場合の容量効率の低下を加味して最も好適な移動先階層を選択することができる。

実施形態６では、２つの仮想ボリュームが互いに同一プールに属してはならないことを表す排他制約の複数からなる排他制約定義に基づいて、それらの排他制約を守りつつ移動先プールを決定することができる。

本発明の再配置システムの構成を示す図である。 図１で列挙した各装置のハードウェア構成を示す図である。 実施形態１の再配置制御部の構成を示す図である。 実施形態１のデータベースの構成を示す図である。 図４のデータベース上の各テーブルの構成を示す図である。 実施形態１の再配置指示画面を示す図である。 再配置実行処理を示すフローチャートである。 再配置後の移動先プールの残運用期間予測処理を示すフローチャートである。 残運用期間予測処理を示すフローチャートである。 使用量予測関数更新処理を示すフローチャートである。 実施形態２の再配置制御部の構成を示す図である。 実施形態２のデータベースの構成を示す図である。 実施形態２の階層指定再配置指示画面を示す図である。 階層指定再配置実行処理を示すフローチャートである。 移動先候補プール一覧表の具体的な表示例を示す図である。 移動先プール選択処理を示すフローチャートである。 実施形態３の再配置制御部およびデータベースの構成を示す図である。 階層内平準化処理を示すフローチャートである。 平準化プラン確認画面の具体的な表示例を示す図である。 階層内平準化プラン選択処理を示すフローチャートである。 実施形態４の再配置制御部の構成を示す図である。 実施形態４のデータベースの構成を示す図である。 実施形態４の階層指定再配置実行処理を示すフローチャートである。 実施形態４の移動先プール選択処理を示すフローチャートである。 バイアス補正付き再配置実行後の移動先プールの残運用期間予測処理を示すフローチャートである。 予測用情報バイアス補正処理を示すフローチャートである。 実施形態５の再配置制御部の構成を示す図である。 実施形態５のデータベースの構成を示す図である。 階層テーブル、ポリシーテーブル、移動状況テーブル、および通常ボリュームテーブルの構成を示す図である。 階層テーブルおよびポリシーテーブルの構成例を示す図である。 ポリシー指定再配置指示画面を示す図である。 ポリシー指定再配置実行処理を示すフローチャートである。 移動先候補プール一覧表の具体的な表示例を示す図である。 ポリシー指定移動先プール選択処理を示すフローチャートである。 好適化再配置処理を示すフローチャートである。 好適化再配置プラン選択処理を示すフローチャートである。 実施形態６の再配置制御部の構成を示す図である。 実施形態６のデータベースの構成を示す図である。 実施形態６の移動先プール選択処理を示すフローチャートである。 排他制約違反プール除去処理を示すフローチャートである。

符号の説明

１００ 管理サーバ
１０１ 再配置制御部
１０２ データベース
１０３ データベース管理部
１１０ ストレージ装置
１１１ ＤＫＣ
１１２ 通常ボリューム
１１３ プール
１１４ 仮想ボリューム
１３０，１３１ ネットワーク
１３２ ホスト
２１０ 仮想ボリュームテーブル
２１１ プールテーブル
２１２ 仮想ボリューム使用量予測関数テーブル
２１３ 仮想ボリューム使用量履歴テーブル
２１４ 階層テーブル
２１５ ポリシーテーブル
２１６ 移動状況テーブル
２１７ 通常ボリュームテーブル
２１８ 排他制約テーブル
Ｓ２００ 再配置実行処理
Ｓ２０１ 再配置実行後の移動先プールの残運用期間予測処理
Ｓ２０２ 残運用期間予測処理
Ｓ２０３ 使用量予測関数更新処理
Ｓ８００ 階層指定再配置実行処理
Ｓ８０１ 移動先プール選択処理
Ｓ１０００ 階層内平準化処理
Ｓ１００１ 階層内平準化プラン選択処理
Ｓ１２００ バイアス補正付き再配置実行後の移動先プールの残運用期間予測処理
Ｓ１２０１ 予測用情報バイアス補正処理
Ｓ１７００ 好適化再配置処理
Ｓ１７０１ 好適化再配置プラン選択処理
Ｓ１９００ ポリシー指定再配置実行処理
Ｓ１９０１ ポリシー指定移動先プール選択処理
Ｓ２３００ 排他制約違反プール除去処理

Claims (12)

1. 複数のプールを備え、ひとつ以上の通常ボリュームからなる前記プール上に構築されたひとつ以上の仮想ボリュームを有し、ひとつ以上の前記仮想ボリュームへの書き込み操作に応じて、前記プールを構成するひとつ以上の前記通常ボリュームから記憶領域を割り当てるストレージと、前記仮想ボリュームを管理する管理サーバとを備える仮想ボリュームの再配置システムであって、
   前記管理サーバは、
   前記プールを階層に分類する複数の条件からなる階層定義を記憶するとともに、前記階層定義の条件には、前記階層における使用量増加の傾向を、前記階層間の相対比率で表した値である使用量増加バイアスを記憶する記憶部と、
   前記記憶部の前記使用量増加バイアスを含む条件を考慮して前記プールの枯渇までの期間を予測する予測部と、
   前記予測部の予測結果に基づいて移動先候補となるプールを選択する選択部と、
   前記選択部で選択された移動先候補のひとつのプールに前記仮想ボリュームを再配置させる再配置部とを備えた
   ことを特徴とする再配置システム。
2. 前記選択部は、移動先として指定された階層内に移動先候補プールが複数存在する場合に、複数の前記移動先候補プールの再配置後における枯渇までの期間の予測に基づいて好適な移動先プールを選択する
   ことを特徴とする請求項１に記載の再配置システム。
3. 前記選択部は、前記移動先として指定された階層内のプールの枯渇までの期間の平準度がより高くなる前記移動先候補プールをより好適な移動先プールとして選択する
   ことを特徴とする請求項２に記載の再配置システム。
4. 前記選択部は、指定された階層内で仮想ボリュームを再配置することにより複数の前記移動先候補プールの枯渇までの期間の平準度が向上する再配置プランを決定する
   ことを特徴とする請求項２に記載の再配置システム。
5. 前記予測部は、階層の特性差に基づいて仮想ボリュームの再配置に伴う前記仮想ボリュームの使用量増加傾向の変化を予測し、前記使用量増加傾向の変化の予測に基づいて前記再配置後のプールの枯渇までの期間の予測を補正する
   ことを特徴とする請求項１に記載の再配置システム。
6. 前記記憶部は、あらかじめ設定された複数の階層選択ポリシーを記憶し、
   前記選択部は、再配置する仮想ボリュームについて前記複数の階層選択ポリシーのうちいずれかの階層選択ポリシーに従って再配置する指示を受理した場合、前記指示された階層選択ポリシーに従って、複数の階層から前記再配置するボリュームの移動先として最も好適な階層を選択し、前記最も好適な階層から移動先プールを選択する
   ことを特徴とする請求項１に記載の再配置システム。
7. 前記階層選択ポリシーは、少なくとも移動先候補階層と優先順位の組から構成され、
   前記選択部は、前記移動先候補階層のうち、移動先として選択可能なプールが存在し、且つ前記優先順位が最も高い前記移動先候補階層を前記最も好適な階層として選択する
   ことを特徴とする請求項６に記載の再配置システム。
8. 前記選択部は、前記階層選択ポリシーに従って、現在配置されている階層より好適な階層に再配置可能な仮想ボリュームを選択し、再配置プランを選択する
   ことを特徴とする請求項６に記載の再配置システム。
9. 前記選択部は、仮想ボリュームの中から、前回の再配置時に最も好適な階層として選択された階層の優先順位よりも高い優先順位の階層に再配置可能な前記仮想ボリュームを選択し、前記仮想ボリュームの前記優先順位が高い階層への再配置を再配置プランとして選択する
   ことを特徴とする請求項７に記載の再配置システム。
10. 前記階層定義は、プールを階層に分類する条件と通常ボリュームを階層に分類する条件との混在を許容し、
    前記選択部は、仮想ボリュームから通常ボリュームへの再配置時の容量効率の低下を加味して前記最も好適な階層を選択する
    ことを特徴とする請求項６に記載の再配置システム。
11. 前記記憶部は、互いに同一プールに属してはならない仮想ボリュームの組の定義からなる排他制約を記憶し、
    前記選択部は、前記排他制約により定義された仮想ボリュームの組が同一プールに属しないことを追加の条件として前記条件に適合するプールを選択する
    ことを特徴とする請求項１に記載の再配置システム。
12. 複数のプールを備え、ひとつ以上の通常ボリュームからなる前記プール上に構築されたひとつ以上の仮想ボリュームを有し、ひとつ以上の前記仮想ボリュームへの書き込み操作に応じて、前記プールを構成するひとつ以上の前記通常ボリュームから記憶領域を割り当てるストレージと、前記仮想ボリュームを管理する管理サーバとを備える仮想ボリュームの再配置システムの再配置方法であって、
    前記管理サーバは、記憶部と、予測部と、選択部と、再配置部とを備え、
    前記記憶部には、前記プールを階層に分類する複数の条件からなる階層定義が記憶されており、前記階層定義の条件には、前記階層における使用量増加の傾向を、前記階層間の相対比率で表した値である使用量増加バイアスが記憶されており、
    前記予測部は、前記記憶部の前記使用量増加バイアスを含む条件を考慮して前記プールの枯渇までの期間を予測し、
    前記選択部は、前記予測部の予測結果に基づいて移動先候補となるプールを選択し、
    前記再配置部は、前記選択部で選択された移動先候補のひとつのプールに前記仮想ボリュームを再配置する
    ことを特徴とする再配置方法。

Images