(57)【要約】【課題】ストレージシステムにおける省電力の効果を向上することのできる技術を提供する。【解決手段】ストレージシステム２０に備えられた複数のディスクドライブ２４１の中の１以上のディスクドライブ２４１を含むＲＡＩＤグループの記憶領域を、所定のデータを格納するために割り当てられる論理ボリュームの割当元として決定する管理計算機１０であって、ボリューム割り当てモジュールＭ１３を実行するＣＰＵ１１は、論理ボリュームの割り当て要求を受け付け、論理ボリュームの割り当て要求を受け付けた場合に、割り当て要求対象の論理ボリュームに対して想定されるアクセス傾向に基づいて、論理ボリュームの割当元とするＲＡＩＤグループを決定する。【選択図】図１
2008269441.tif 000002
【特許請求の範囲】
【請求項１】
ストレージシステムに備えられた複数の記憶媒体の中の１以上の記憶媒体を含む物理領域を、所定のデータを格納するために割り当てられる論理ボリュームの割当元として決定するボリューム割り当て管理装置であって、
前記論理ボリュームの割り当て要求を受け付ける要求受付部と、
前記論理ボリュームの割り当て要求を受け付けた場合に、割り当て要求対象の前記論理ボリュームに対して想定されるアクセス傾向に基づいて、前記論理ボリュームの前記割当元とする前記物理領域を決定する物理領域決定部と
を有するボリューム割り当て管理装置。
【請求項２】
アクセス傾向を特定する情報と、当該アクセス傾向が想定される論理ボリュームの割当元とすべき物理領域の識別情報とを対応付けて記憶する割り当てポリシー記憶部を更に備え、
前記要求受付部は、前記論理ボリュームの割り当て要求として、前記割り当て要求対象の論理ボリュームに対して想定されるアクセス傾向を特定する情報を受け付け、
前記物理領域決定部は、前記要求受付部が受け付けた前記アクセス傾向を特定する情報に対応する前記物理領域の識別情報を取得し、当該識別情報が示す前記物理領域を、前記割り当て要求対象の論理ボリュームの割当元として決定する
請求項１に記載のボリューム割り当て管理装置。
【請求項３】
前記ポリシー記憶部に登録すべき或るアクセス傾向を特定する情報を受け付けるポリシー受付部と、
前記ポリシー記憶部に前記或るアクセス傾向を特定する情報に対応する物理領域の識別領域が対応付けられていない場合に、前記或るアクセス傾向を特定する情報に、当該或るアクセス傾向と類似するアクセス傾向を特定する情報に対応する物理領域の識別領域を対応付けて前記ポリシー記憶部に格納するポリシー格納部と
を更に有する請求項２に記載のボリューム割り当て管理装置。
【請求項４】
前記アクセス傾向は、前記論理ボリュームのアクセス時間についての傾向を含む
請求項１乃至請求項３のいずれか１項に記載のボリューム割り当て管理装置。
【請求項５】
前記アクセス時間についての傾向は、論理ボリュームを使用したバックアップの開始時刻である
請求項４に記載のボリューム割り当て管理装置。
【請求項６】
前記アクセス傾向は、前記論理ボリュームのアクセス頻度の低下時期についての傾向を含む
請求項１乃至請求項３のいずれか１項に記載のボリューム割り当て管理装置。
【請求項７】
アクセス頻度の低下の傾向が同様な論理ボリュームのグループを示すグループ名と、前記グループに属する論理ボリュームのアクセス頻度履歴との対応関係を記憶する頻度履歴記憶部を更に備え、
前記要求受付部は、前記論理ボリュームの割り当て要求として、前記割り当て要求対象の論理ボリュームが属すべきグループのグループ名を受け付け、
前記ボリューム割り当て管理装置は、更に、
前記アクセス頻度履歴に基づいて、受け付けた前記グループ名が示す前記グループに属する前記論理ボリュームのアクセス頻度の第１の低下期間を検出する第１低下期間検出部と、
前記第１の低下期間に基づいて、割り当て要求対象の前記論理ボリュームのアクセス頻度の第１の低下予想時期を決定する第１低下時期決定部とを備え、
前記物理領域決定部は、前記第１の低下予想時期に基づいて、割り当て要求対象の前記論理ボリュームの割当元とする前記物理領域を決定する
請求項１に記載のボリューム割り当て管理装置。
【請求項８】
前記グループ名が示すグループに属する論理ボリュームのアクセス頻度履歴と、当該論理ボリュームを格納する物理領域との対応関係を記憶する物理領域対応記憶部と、
前記アクセス頻度履歴に基づいて、前記頻度履歴記憶部の全てのグループ名が示すグループに属する論理ボリュームのアクセス頻度の第２の低下期間を検出する第２低下期間検出部と、
検出した第２の前記低下期間に基づいて、前記物理領域毎のアクセス頻度の第２の低下予想時期を検出する第２低下時期検出部とを更に有し、
前記物理領域決定部は、割り当て対象の論理ボリュームのアクセス頻度の第１の低下予想時期と、一致又は近似する時期を第２の低下予想時期とする前記物理領域を、割り当て対象の論理ボリュームの割当元として決定する
請求項７に記載のボリューム割り当て管理装置。
【請求項９】
前記グループは、業務を単位とした論理ボリュームのグループである
請求項７又は請求項８に記載のボリューム割り当て管理装置。
【請求項１０】
前記アクセス頻度履歴は、前記物理領域に対する省電力機能が実行されるアクセス頻度であるか否かを示す情報の履歴である
請求項７乃至請求項９のいずれか１項に記載のボリューム割り当て管理装置。
【請求項１１】
前記物理領域は、同一のＲＡＩＤグループを構成する２以上の前記記憶媒体の記憶領域である
請求項１乃至請求項１０のいずれか１項に記載のボリューム割り当て管理装置。
【請求項１２】
決定した前記物理領域に割り当て要求対象の前記論理ボリュームを設定する指示を前記ストレージシステムに送信する割り当て指示送信部を更に備える
請求項１乃至請求項１１のいずれか１項に記載のボリューム割り当て管理装置。
【請求項１３】
前記ストレージシステムは、前記記憶媒体に対するアクセス状況に応じて、当該記憶媒体に対する省電力機能を実行する
請求項１乃至請求項１２のいずれか１項に記載のボリューム割り当て管理装置。
【請求項１４】
ストレージシステムに備えられた複数の記憶媒体の中の１以上の記憶媒体を含む物理領域を、所定のデータを格納するために割り当てられる論理ボリュームの割当元として決定するボリューム割り当て管理装置によるボリューム割り当て管理方法であって、
前記論理ボリュームの割り当て要求を受け付け、
前記論理ボリュームの割り当て要求を受け付けた場合に、割り当て要求対象の前記論理ボリュームに対して想定されるアクセス傾向に基づいて、前記論理ボリュームの前記割当元とする前記物理領域を決定する
ボリューム割り当て管理方法。
【請求項１５】
コンピュータに、ストレージシステムに備えられた複数の記憶媒体の中の１以上の記憶媒体を含む物理領域を、所定のデータを格納するために割り当てられる論理ボリュームの割当元として決定させるボリューム割り当て管理プログラムであって、
前記コンピュータを
前記論理ボリュームの割り当て要求を受け付ける要求受付部と、
前記論理ボリュームの割り当て要求を受け付けた場合に、割り当て要求対象の前記論理ボリュームに対して想定されるアクセス傾向に基づいて、前記論理ボリュームの前記割当元とする前記物理領域を決定する物理領域決定部と
して機能させるボリューム割り当て管理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ストレージシステムに備えられた複数の記憶媒体の中の１以上の記憶媒体を含む物理領域を、所定のデータを格納するために割り当てられる論理ボリュームの割当元として決定するボリューム割り当て管理装置等に関する。
【背景技術】
【０００２】
近年、ストレージシステムの大規模化・高性能化に伴い、ストレージシステムの消費電力が増加している。また、データセンタなどが保持するストレージシステムの数も増大傾向にあり、データセンタ全体としての消費電力も増加している。
【０００３】
このため、従来ストレージシステムに期待されていた高性能・高信頼という側面やストレージ管理コストの削減という側面だけではなく、消費電力の削減を考慮したストレージ運用管理に関しても関心が高まっている。
【０００４】
消費電力の削減を解決する技術としては、ストレージシステム内のディスクに対してホストから一定時間アクセスがない場合などに、管理計算機からストレージシステムのディスクを省電力モードもしくは電源オフに設定し、ディスクにアクセスが生じた場合に電源オフを解除することによって、ストレージシステムの消費電力を低減する技術がある（例えば、特許文献１参照）。
【０００５】
【特許文献１】特開２００５−１５７７１０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
上記した技術によると、ディスクに対して一定時間アクセスがない場合に、ディスクを省電力モードにすることにより、消費電力を低減することができる。
【０００７】
しかしながら、ストレージシステムにおいて、一定時間アクセスがないという状況が発生しない限り、ディスクは省電力モードにならず、省電力の効果が得られない。
【０００８】
このため、例えば、複数のボリュームを利用する際に、ストレージシステムの利用可能な物理領域から無作為にボリュームを割り当ててしまうと、複数のディスクにボリュームの実領域が分散してしまい、その結果、各ディスクにアクセスが生じて、省電力モードになる頻度が低く、省電力の効果が十分に得られないという問題が発生する。
【０００９】
また、運用開始時に同一ディスクに同一業務のボリュームを配置するようにボリュームを割り当てるようにすることで、運用開始から所定の期間が経過すると、ボリュームへのアクセス頻度が低下するので、当該ディスクの省電力機能が動作するようになると考えられる。しかしながら、業務に利用するボリュームを同一ディスクの物理領域を使用して拡張した場合には、最初に利用していたボリュームの物理領域に対するアクセス頻度が低下しても、後から拡張されたボリュームの物理領域に対するアクセス頻度は高いままの状況が生じることにより、運用開始から所定の期間経過しても、ディスクの省電力機能が発揮されない可能性も考えられる。
【００１０】
また、あるディスクが複数の業務データのバックアップに利用されるように構成されている場合には、各業務のバックアップを行う時間によっては、当該ディスクに断続的にアクセスが発生して省電力機能が動作しない可能性がある。
そこで、本発明は、上記課題に鑑みなされたものであり、その目的は、ストレージシステムにおける省電力の効果を向上することのできる技術を提供することにある。
【課題を解決するための手段】
【００１１】
本発明は、上記課題を解決するために、ボリュームのアクセス傾向、例えば、ボリュームにアクセスする時間や、業務におけるボリュームのアクセス頻度の低下傾向等に着目してなされたものであり、アクセス傾向に基づいて論理ボリュームの割当元とする物理領域を決定するようにする。
【００１２】
本発明の第１の観点に従うボリューム割り当て管理装置は、ストレージシステムに備えられた複数の記憶媒体の中の１以上の記憶媒体を含む物理領域を、所定のデータを格納するために割り当てられる論理ボリュームの割当元として決定するボリューム割り当て管理装置であって、前記論理ボリュームの割り当て要求を受け付ける要求受付部と、前記論理ボリュームの割り当て要求を受け付けた場合に、割り当て要求対象の前記論理ボリュームに対して想定されるアクセス傾向に基づいて、前記論理ボリュームの前記割当元とする前記物理領域を決定する物理領域決定部とを有する。
【発明を実施するための最良の形態】
【００１３】
本発明の実施形態について、図面を参照して説明する。なお、以下に説明する実施形態は特許請求の範囲にかかる発明を限定するものではなく、また実施形態の中で説明されている特徴の組み合わせの全てが発明の解決手段に必須であるとは限らない。
（第１実施形態）
（１）第１実施形態に係るシステム構成
図１は、本発明の第１実施形態に係る計算機システムの概略構成を示す図である。
【００１４】
本計算機システムは、ボリューム割り当て管理装置の一例としての管理計算機１０、ストレージシステム２０、業務ホスト計算機３０、および管理クライアント５０を有している。本実施形態では、計算機システムは、管理計算機１０が１台、ストレージシステム２０が２台、業務ホスト計算機３０が１台、管理クライアント５０が１台となっているが、それぞれ１台ないしは複数台であってもよい。管理計算機１０、ストレージシステム２０、業務ホスト計算機３０、および管理クライアント５０は、管理ネットワーク４０（例えば、ＬＡＮ）と接続されている。業務ホスト計算機３０は、データネットワーク４１、例えばＳＡＮ（Storage Area Network）を介してストレージシステム２０に接続されている。ＳＡＮでは、例えば、ファイバチャネル、ｉＳＣＳＩといった通信プロトコルが用いられる。
【００１５】
業務ホスト計算機３０は、データベース管理システム（ＤＢＭＳ）などの業務プログラムやバックアッププログラムなどを実行し、処理結果をストレージシステム２０に対して書き込み、あるいは、ストレージシステム２０に格納されている情報資源を活用する。業務ホスト計算機３０は、ＣＰＵ３１、メモリ３２、フロントエンドＩ／Ｏインタフェース３３、およびリアエンドＩ／Ｏインタフェース３４を備えている。ＣＰＵ３１、メモリ３２、フロントエンドＩ／Ｏインタフェース３３、およびリアエンドＩ／Ｏインタフェース３４は、相互にバス３５を介して接続されている。
【００１６】
管理クライアント５０は、ユーザからの要求に応じて管理計算機１０で動作する後述する管理プログラムＰ１に対して要求を送信する、あるいは、管理プログラムＰ１の実行結果を受信してＧＵＩやＣＬＩを実行してユーザに結果を表示する。なお、管理クライアント５０のハードウエア構成は、管理計算機１０と同様であるので、ここでは説明を省略する。
【００１７】
ストレージシステム２０は、業務ホスト計算機３０に対して記憶領域を提供し、ディスクアレイコントローラ２１、キャッシュ２２、データ用Ｉ／Ｏインタフェース２３、ディスク装置２４、管理用Ｉ／Ｏインタフェース２５、および電源制御装置２６を備えている。ディスクアレイコントローラ２１は、ストレージシステム２０における各種制御処理を実行する制御モジュールであり、ＣＰＵ２１１、メモリ２１２、およびＩ／Ｏポート（図示せず）を備えている。キャッシュ２２は、ディスク装置２４に対して書き込むべきデータ、あるいは、ディスク装置２４から読み出したデータを一時的に格納する。ディスク装置２４は、複数の磁気ハードディスクドライブ（ディスクドライブ：記憶媒体の一例）２４１によってＲＡＩＤ（Redundant Arrays of Inexpensive Disks）構成されるディスクアレイ装置である。ディスク装置２４は、複数のハードディスクドライブ２４１によって１または複数の記憶領域、すなわち論理ユニット（ＬＵ：論理ボリューム）を提供し、あるいは、１つのハードディスクドライブ２４１によって１または複数の論理ユニットを提供する。
電源制御装置２６は、ＣＰＵ２１１の制御に従って、ディスク装置２４への電源の供給を制御する。
【００１８】
メモリ２１２には、ボリューム管理プログラムＰ３と、電源制御プログラムＰ４と、ディスク管理テーブルＴ２１２とが格納される。
【００１９】
図２は、本発明の第１実施形態に係るディスク管理テーブルの一例を示す図である。
【００２０】
ディスク管理テーブルＴ２１２は、ストレージシステム２０が提供するディスク装置２４の状態を管理するためのテーブルであり、ボリューム管理プログラムＰ３、電源制御プログラムＰ４によって利用される。ディスク管理テーブルＴ２１２には、ディスクＩＤフィールドＴ２１２ａと、電源状態フィールドＴ２１２ｂと、最終アクセス時刻フィールドＴ２１２ｃと、ＲＡＩＤグループフィールドＴ２１２ｄと、ＬＵＮフィールドＴ２１２ｅとが含まれる。ディスクＩＤフィールドＴ２１２ａには、ディスク装置２４に格納されるディスクドライブ２４１を特定するためのＩＤ（ディスクＩＤ）が格納される。電源状態フィールドＴ２１２ｂには、ディスクドライブ２４１の電源状態が格納される。電源状態としては、電源が入っていることを示す“ＯＮ”、又は電源が入っていないことを示す“ＯＦＦ”が設定される。最終アクセス時刻フィールドＴ２１２ｃには、ディスクドライブ２４１に対する最終アクセス時刻が格納される。ＲＡＩＤグループフィールドＴ２１２ｄには、ディスクドライブ２４１が属するＲＡＩＤグループ番号が格納される。ＬＵＮフィールドＴ２１２ｅには、ＲＡＩＤグループに属するＬＵ番号が格納される。
【００２１】
図１に戻り、ボリューム管理プログラムＰ３は、管理計算機１０からの要求に従い、ディスク装置２４が提供するＬＵを業務ホスト計算機３０に割り当てたり、あるＬＵのデータをストレージシステム２０が提供する他のＬＵにコピーしたりするなど、ストレージシステム２０が提供する各種機能をＣＰＵ２１１に実行させるためのプログラムである。ＣＰＵ２１１により、ＬＵを割り当てた状態が更新された場合には、ディスク管理テーブルＴ２１２が更新される。例えば、ボリューム管理プログラムＰ３を実行するＣＰＵ２１１は、管理計算機１０からボリューム割り当ての要求を受けると、そのボリュームがＲＡＩＤグループ“Ｒ００１”に含まれるＬＵであってＬＵ番号が“１０１”である場合には、ＲＡＩＤグループ“Ｒ００１”を構成するディスクＩＤ“０”のレコードのＬＵＮフィールドＴ２１２ｅと、ディスクＩＤ“１”のＬＵＮフィールドＴ２１２ｅとのそれぞれに“１０１”を追加する。
【００２２】
電源制御プログラムＰ４は、ストレージシステム２０に対するＩ／Ｏを監視し、Ｉ／Ｏが一定期間発生しないディスクドライブ２４１がある場合に、当該ディスクドライブ２４１の回転停止や電源を落とす等の省電力機能を実行させる等のディスク装置２４の電源を制御する処理をＣＰＵ２１１に実行させるためのプログラムである。例えば、電源制御プログラムＰ４を実行するＣＰＵ２１１は、ディスク装置２４の各ディスクドライブ２４１へのＩ／Ｏを監視しており、各ディスクドライブ２４１において、ディスク管理テーブルＴ２１２の最終アクセス時刻フィールドＴ２１２ｃに格納されている時刻から所定の期間Ｉ／Ｏが発生しない場合には、電源制御装置２６により当該ディスクドライブ２４１の電源を落とさせ、対応するレコードの電源状態フィールドＴ２１２ｂを“ＯＦＦ”に更新する。また、電源制御プログラムＰ４を実行するＣＰＵ２１１は、電源ＯＦＦ状態のディスクドライブに対してＩ／Ｏ要求が発生した場合には、電源制御装置２６によりディスクドライブ２４１を起動し、対応するレコードの電源状態フィールドＴ２１２ｂを“ＯＮ”に更新する。また、電源制御プログラムＰ４を実行するＣＰＵ２１１は、ディスクドライブ２４１が、複数のディスクドライブ２４１によるＲＡＩＤ構成となっている場合には、同一ＲＡＩＤグループに属する他のディスクドライブの電源のＯＮ／ＯＦＦの制御もあわせて行う。なお、ディスクと関連するデバイス、例えば、ＣＰＵや電源ファンなどデバイスも消費電力を制御できる単位となっている場合には、電源制御プログラムＰ４を実行するＣＰＵ２１１は、ディスクと関連するこれらデバイスも合わせて省電力モードに移行するように制御してもよい。
【００２３】
管理計算機１０は、ストレージシステム２０に対する管理、例えば、ストレージシステム２０におけるボリュームの作成、業務ホスト計算機３０へのボリュームの割り当て、ストレージシステム２０内またはストレージシステム２０間のボリュームのレプリケーション（複製）やマイグレーション（移動）を実行する。管理計算機１０は、ＣＰＵ１１、メモリ１２、フロントエンドＩ／Ｏインタフェース１３、およびリアエンドＩ／Ｏインタフェース１４を備えている。ＣＰＵ１１、メモリ１２、フロントエンドＩ／Ｏインタフェース１３、およびリアエンドＩ／Ｏインタフェース１４は、相互にバス１５を介して接続されている。ＣＰＵ１１は、演算処理装置であり、メモリ１２に格納されている各種プログラム、モジュールを実行する。ここで、ＣＰＵ１１がプログラムを実行することにより、要求受付部、物理領域決定部、および割り当て指示送信部が構成される。メモリ１２は、いわゆる内部記憶装置であり、各種プログラムの各種モジュール等を記憶する不揮発性メモリ、および演算処理結果を一時的に格納する揮発性メモリの双方を含む。本実施形態では、メモリ１２は、ストレージ管理プログラムＰ１を記憶する。ここで、メモリ１２がポリシー記憶部に対応する。
【００２４】
図３は、本発明の第１実施形態に係るストレージ管理プログラムの構成を示す図である。
【００２５】
ストレージ管理プログラムＰ１は、ライフサイクル管理モジュールＭ１１、リソースグループ管理モジュールＭ１２、ボリューム割り当てモジュールＭ１３、ストレージ管理モジュールＭ１４、ポリシー記憶部の一例としてのボリューム割り当てポリシーテーブルＴ１１、およびリソースグループ管理テーブルＴ１２を備える。ストレージ管理プログラムＰ１は、ストレージシステム２０上の各種プログラムと連携することによってストレージシステム２０に関する機能を提供する処理をＣＰＵ１１に実行させるためのプログラムである。例えば、ストレージ管理プログラムＰ１を実行するＣＰＵ１１は、ストレージシステム２０が提供するＬＵの構成を管理し、ＬＵの割り当てや属性の変更、ＬＵ間のデータコピーやデータマイグレーションに関する機能を提供する。
【００２６】
ライフサイクル管理モジュールＭ１１は、ライフサイクル定義の管理と、ライフサイクル定義とボリュームを生成する物理領域との関連を管理する処理をＣＰＵ１１に実行させるためのモジュールである。ライフサイクル定義とは、ボリュームに対するアクセス傾向に関する情報の定義であり、例えば、ボリュームに対するアクセスの増加時期や低下時期等のアクセス時間に関する情報の定義がある。より具体的には、例えば、バックアップに用いるボリュームにおいては、毎日０：００にバックアップを開始するという情報の定義がライフサイクル定義に当てはまる。また、業務の種類に応じて、３ヶ月でアクセス頻度が低下すると想定されるデータ用のボリュームや、６ヶ月後にアクセス頻度が低下すると想定されるデータ用のボリュームであれば、３ヶ月でアクセス頻度が低下するという情報や、６ヶ月でアクセス頻度が低下するという情報がライフサイクル定義に当てはまる。これらの定義はボリューム割り当てテーブルＴ１１で管理される。
【００２７】
リソースグループ管理モジュールＭ１２は、管理対象となるストレージシステム２０や業務ホスト計算機３０の構成情報をもとに、ボリュームや業務ホスト計算機３０などのリソースをユーザが任意の単位でグルーピングして管理できるようにするための機能をＣＰＵ１１に実行させるためのモジュールである。例えば、ＬＵＮ“１０１”と“１０２”とを業務Ａのバックアップ用ボリュームとして利用する場合には、これらをグルーピングして業務Ａバックアップボリュームグループとして管理するための機能を提供する。これらのデータはリソースグループ管理テーブルＴ１２に格納される。
【００２８】
ボリューム割り当てモジュールＭ１３は、ユーザからボリューム割り当て要求を受け付けると、リソースグループ管理テーブルＴ１１とボリューム割り当てテーブルＴ１２を参照してボリュームを利用する業務データのアクセス傾向に合致するＲＡＩＤグループ（又は、ディスク）を決定し、そのＲＡＩＤグループからボリュームを割り当てるようにストレージシステム２０に要求する処理をＣＰＵ１１に実行させるためのモジュールである。
【００２９】
ストレージ管理モジュールＭ１４は、ストレージシステム２０が提供する種々の管理機能を管理するためのストレージ管理機能をＣＰＵ１１に実行させるためのモジュールである。ストレージ管理機能には、例えば、ストレージシステム２０やボリュームなどストレージリソースの構成管理、データレプリケーションの制御・監視機能やデータマイグレーション機能等がある。
【００３０】
ボリューム割り当てポリシーテーブルＴ１１は、ライフサイクル定義とライフサイクル定義に対応するボリュームを生成すべき、すなわち割当元とすべき物理領域との関連を管理するためのテーブルである。ここで、物理領域としては、例えば、１のディスクドライブ２４１の記憶領域であってもよく、複数のディスクドライブ２４１により構成されるＲＡＩＤグループの記憶領域であってもよく、或いは、複数のストレージシステム２０の中のいずれかのストレージシステムの記憶領域であってもよく、また、複数の場所（サイト）のそれぞれにおいて、複数のストレージシステム２０を備えている場合には、いずれかのサイトのストレージシステム２０の記憶領域であってもよく、要は、ライフサイクル定義に対応するボリュームを生成するための記憶領域であればよい。
【００３１】
図４は、本発明の第１実施形態に係るボリューム割り当てポリシーテーブルの一例を示す図である。
【００３２】
ボリューム割り当てポリシーテーブルＴ１１は、ライフサイクル名フィールドＴ１１ａと、バックアップ開始時刻フィールドＴ１１ｂと、物理領域フィールドＴ１１ｃとを含む。ライフサイクル名フィールドＴ１１ａには、ライフサイクルを一意に識別するための名称であるライフサイクル名が格納される。バックアップ開始時刻フィールドＴ１１ｂには、バックアップの開始時刻を示すバックアップ開始時刻が格納される。バックアップ開始時刻としては、特定の時刻であってもよいし、８：００−９：００のように時間範囲を持たせたものとしてもよい。この場合、バックアップ開始が８時から９時までの間に行われることを意味する。尚、本実施形態では、バックアップスケジュールに従ったボリューム割り当てを例にしているため、テーブルの属性として、バックアップ開始時刻を用いているが、これに限られず、属性としては、アクセス頻度が時間単位で判断できる情報であればよい。
【００３３】
物理領域フィールドＴ１１ｃには、対応するライフサイクルに従って運用される業務やアプリケーションのボリュームを生成する際の物理領域を示す識別情報が格納される。本実施形態では、物理領域フィールドＴ１１ｃには、ＲＡＩＤグループ番号が格納されているが、これに限られず、省電力機能のＯＮ／ＯＦＦを制御できる物理領域の単位の属性値であればよい。例えば、ディスクＩＤ、ストレージシステムＩＤ、ストレージプールＩＤなどを属性値としてもよい。
【００３４】
図４に示す１番上のレコードは、毎日０時にバックアップを開始する業務のライフサイクルがライフサイクル名“バックアップ00:00”で定義され、このライフサイクルに従うボリュームはＲＡＩＤグループ“Ｒ００１”から割り当てられるべきことを意味している。
【００３５】
リソースグループ管理テーブルＴ１２は、リソースグループの定義とリソースグループに属するストレージリソースとの関連を管理するためのテーブルである。
【００３６】
図５は、本発明の第１実施形態に係るリソースグループ管理テーブルの一例を示す図である。
【００３７】
リソースグループ管理テーブルＴ１２は、グループＩＤフィールドＴ１２ａと、グループ名フィールドＴ１２ｂと、説明フィールドＴ１２ｃと、ライフサイクル名フィールドＴ１２ｄと、ＬＵＮフィールドＴ１２ｅとを含む。グループＩＤフィールドＴ１２ａには、リソースグループをユニークに識別するためのＩＤであるグループＩＤが格納される。ここで、リソースグループとしては、アクセス傾向が同じと想定できるリソース、ここでは、ボリュームをまとめたグループであり、本実施形態では、例えば、同一業務のバックアップに利用するボリュームをまとめたものとなっている。グループ名フィールドＴ１２ｂには、対応するレコードのリソースグループの名称であるグループ名が格納される。説明フィールドＴ１２ｃには、対応するリソースグループの説明が格納される。ライフサイクル名フィールドＴ１２ｄには、対応するリソースグループに含まれるボリュームのライフサイクルを示すライフサイクル名が格納される。当該ライフサイクル名は、ボリューム割り当てポリシーテーブルＴ１１のライフサイクル名フィールドＴ１１ａのライフサイクル名と対応する。ＬＵＮフィールドＴ１２ｅには、対応するリソースグループに所属するボリュームのＬＵ番号（ＬＵＮ）が格納される。このＬＵＮフィールドＴ１２ｅのＬＵＮは、ストレージシステム２０が保持するディスク管理テーブルＴ２１２に対応するＬＵＮが格納されている。
【００３８】
図５に示す１番上のレコードは、グループ名が“業務Ａバックアップ”のリソースグループは、業務Ａのバックアップデータを格納するＬＵＮ“１０１”、“１０２”で構成され、ライフサイクル名が“バックアップ00:00”で定義されるライフサイクル（ボリューム割り当てポリシーテーブルＴ１１で管理）に従って、バックアップが実行されることを意味している。つまり、ＬＵＮ“１０１”、“１０２”は、毎日０時からバックアップ終了までの間、アクセスが発生するボリュームであることを意味している。
【００３９】
（２）第１実施形態に係る動作
次に、第１実施形態に係る動作を説明する。
【００４０】
本実施形態の計算機システムにおいては、各業務ホスト計算機３０に割り当てられているボリュームはコピーペアが組まれており、各ボリュームのバックアップボリューム（セカンダリボリューム）が業務ごとにグルーピングされている。また、各ＲＡＩＤグループには、ライフサイクル定義としてバックアップ開始時刻が関連付けられている。ここで、ある業務ホスト計算機３０に割り当てられているボリュームのバックアップボリュームを新たに割り当てる場合を例に処理概要を説明する。
【００４１】
このような割り当て要求が発生した場合には、管理計算機１０の管理プログラムを実行するＣＰＵ１１が、ボリューム割り当て対象となる業務におけるバックアップ開始時刻と一致するようなバックアップ開始時刻と関連付けられているＲＡＩＤグループからバックアップボリュームを割り当てるように処理を行う。この処理により、同一ＲＡＩＤグループ(又はディスクドライブ)には、バックアップ開始時刻が一致又は近いボリューム、つまり、アクセスが発生する時刻が一致又は近いボリュームが集約されるため、ディスクドライブ２４１が動作する時間が集約されるので、ディスクドライブ２４１の省電力機能が実行されて電源ＯＦＦとなる状態を長く維持することができ、ストレージシステム２０の省電力機能による効果を向上することができる。
【００４２】
図６は、本発明の第１実施形態に係る処理概要を説明する図である。
【００４３】
例えば、図６に示すように業務Ａに利用される業務ホスト計算機３０Ａ、業務Ｂに利用される業務ホスト計算機３０Ｂ、業務Ｃに利用される業務ホスト計算機３０Ｃが一台のストレージシステム２０を共有している構成において、業務ＡにはコピーペアのプライマリボリュームとしてＬＵＮ“００１”と“００２”が、セカンダリボリュームとしてＬＵＮ“１０１”、“１０２”が割り当てられており、ＬＵＮ“１０１”、“１０２”は業務Ａバックアップグループに属している。業務ＢにはコピーペアのプライマリボリュームとしてＬＵＮ“００４”と“００５”が、セカンダリボリュームとしてＬＵＮ“１０４”、“１０５”が割り当てられており、ＬＵＮ“１０４”、“１０５”は業務Ｂバックアップグループに属している。業務Ｃには、コピーペアのプライマリボリュームとしてＬＵＮ“００３”が割り当てられている。
【００４４】
ここで、業務ホスト計算機３０Ｃに、業務ＣのバックアップボリュームＬＵＮ“１０３”を新たに割り当てる場合を例に処理概要を説明する。
【００４５】
業務ＣのバックアップボリュームＬＵＮ“１０３”を新たに割り当てる割り当て要求が発生した場合には、管理計算機１０のストレージ管理プログラムＰ１を実行するＣＰＵ１１が、業務Ｃのバックアップ時刻と同一のバックアップ時刻を持つ業務Ａと同一のＲＡＩＤグループ“Ｒ００１”からボリュームを割り当てるよう処理を行う。これにより、“０：００”にアクセスが発生するディスクをＲＡＩＤグループ“Ｒ００１”に集約させることが可能になる。このため、ディスクドライブ２４１が動作する時刻を集約することができるので、ディスクドライブ２４１において省電力機能が実行されて電源ＯＦＦとなる状態を効果的に長く維持することができ、ボリュームを無作為に割り当てる場合と比較して省電力効果が向上する。
【００４６】
次に、第１実施形態に係る処理を詳細に説明する。
【００４７】
本実施形態の計算機システムにおいては、バックアップスケジュールなど、ボリュームに格納されるデータのライフサイクルを定義するためのボリューム割り当てポリシー作成処理と、各ボリュームを業務ごとにグルーピングしてライフサイクルを設定するためのリソースグループ作成処理と、ストレージ管理プログラムＰ１を実行するＣＰＵ１１が、定義したライフサイクル定義に従って適切な物理領域からボリュームを割り当てるボリューム割り当て処理とが実行される。
【００４８】
図７は、本発明の第１実施形態に係るボリューム割り当てポリシー作成処理を示す図である。
【００４９】
ボリューム割り当てポリシー作成処理では、ユーザが設定したライフサイクル定義に基づいて、当該ライフサイクル定義に対応するＲＡＩＤグループを決定し、ライフサイクル定義とＲＡＩＤグループの情報とをボリューム割り当てポリシーテーブルＴ１１に登録する。以下、具体的な動作を説明する。
【００５０】
管理クライアント５０が、ユーザから、管理計算機１０上のストレージ管理プログラムＰ１に対してのライフサイクル定義機能を呼び出す要求を受け付ける（ステップＳ０００１）と、管理クライアント５０が当該要求を管理計算機１０に送信する。
【００５１】
管理計算機１０では、ストレージ管理プログラムＰ１を実行するＣＰＵ１１が、要求に従ってライフサイクル定義画面を管理クライアント５０に表示させる（ステップＳ０００２）。管理クライアント５０が、ユーザによるライフサイクル定義画面に対する入力によって、ライフサイクル名とバックアップ開始時刻との設定を受け付け（ステップＳ０００３）、受け付けた設定内容を管理計算機１０に送信する。管理計算機１０では、設定内容を受け取って、ストレージ管理プログラムＰ１のライフサイクル管理モジュールＭ１１を実行するＣＰＵ１１が、ボリューム割り当てポリシーテーブルＴ１１のバックアップ開始時刻フィールドＴ１１ｂを参照し、受け付けた設定内容のバックアップ開始時刻と所定の時間内（例えば、１時間以内）のバックアップ開始時刻が設定されているライフサイクル定義であり、かつ、物理領域フィールドＴ１１ｃで示される物理領域が新規ボリュームを割り当てることができる空き領域を有するライフサイクル定義を取得する（ステップＳ０００４）。なお、空き領域を有するか否かは、ストレージシステム２０で管理されている物理領域の空き領域の情報を取得しておくことにより把握することができる。
【００５２】
この結果、ライフサイクル定義を取得できなかった場合（ステップＳ０００５、ＮＯ）は、ＣＰＵ１１は、ユーザが設定したライフサイクル定義と、既存のライフサイクル定義と関連付けられていない新規のＲＡＩＤグループとを関連付けた新たなレコードを作成してボリューム割り当てポリシーテーブルＴ１１に格納する（ステップ：Ｓ０００６）。
【００５３】
一方、ライフサイクル定義を取得できた場合（ステップＳ０００５、ＹＥＳ）は、ＣＰＵ１１は、当該ライフサイクル定義のバックアップ開始時刻を拡張するか、或いは、新たな割り当てポリシーとするかを、管理クライアント５０を介してユーザに問い合わせる（ステップＳ０００７）。管理クライアント５０は、ユーザから拡張しないとの選択を受け付けた場合（ステップＳ０００８・ＮＯ）には、当該結果を管理計算機１０に送信する。次いで、管理計算機１０のＣＰＵ１１が、ユーザが設定したライフサイクル定義と、既存のライフサイクル定義と関連付けられていない新規のＲＡＩＤグループとを関連付けた新たなレコードを作成してボリューム割り当てポリシーテーブルＴ１１に格納する（ステップ：Ｓ０００６）。
【００５４】
一方、管理クライアント５０は、ユーザからバックアップ開始時刻を拡張するとの選択を受け付けた場合（ステップＳ０００８、ＹＥＳ）には、当該結果を管理計算機１０に送信する。次いで、管理計算機１０のＣＰＵ１１が、既存のライフサイクル定義のバックアップ開始時刻を拡張し、ボリューム割り当てポリシーテーブルＴ１１を更新する（ステップＳ０００９）。例えば、既存のライフサイクル定義のバックアップ開始時刻が“８：００”であって、ユーザが設定したバックアップ開始時刻が“９：００”である場合において、ユーザから拡張するとの選択を受け付けた際には、ＣＰＵ１１は、既存のライフサイクル定義のバックアップ開始時刻を“８：００−９：００”のように更新する。ボリューム割り当てポリシーテーブルＴ１１の更新処理が終了するとライフサイクル管理モジュールＭ１１を実行するＣＰＵ１１は、処理結果を管理クライアント５０に通知する。これによって、管理クライアント５０においては、処理結果が表示される（ステップＳ００１０）。以上の処理によって、ボリュームのライフサイクル定義と、物理領域を提供するＲＡＩＤグループとの関連が定義される。
【００５５】
次に、業務単位やボリュームを利用するプログラムごとに、ボリュームをグルーピングするリソースグループ作成処理について詳細に説明する。
【００５６】
図８は、本発明の第１実施形態に係るリソースグループ作成処理を示す図である。
【００５７】
リソースグループ作成処理では、ユーザにより設定されたリソースグループ定義とリソースグループに含まれるデータのライフサイクルとの関連をリソースグループ管理テーブルにＴ１２に登録する。
【００５８】
管理クライアント５０が、ユーザから、管理計算機１０上のストレージ管理プログラムＰ１に対してのリソースグループ管理機能を呼び出す要求を受け付ける（ステップＳ１００１）と、管理クライアント５０が当該要求を管理計算機１０に送信する。管理計算機１０では、ストレージ管理プログラムＰ１のリソースグループ管理モジュールＭ１２を実行するＣＰＵ１１が、ユーザからの要求に従ってリソースグループ管理画面と登録されているライフサイクル一覧とを管理クライアント５０に表示させる（ステップＳ１００２）。なお、ライフサイクル一覧は、ボリューム割り当てポリシーテーブルＴ１１から取得した情報に基づいて表示させることができる。管理クライアント５０が、ユーザによるリソースグループ管理画面に対する入力によって、“グループ名”、“グループの説明”、“ライフサイクル名”のグループの指定を受け付け、（ステップＳ１００３）、受け付けたグループの内容を管理計算機１０に送信する。例えば、業務Ａ用のバックアップデータを格納するボリュームを管理するリソースグループを作成する場合には、グループ名“業務Ａバックアップ”、説明“業務Ａ用のバックアップボリューム”を受け付け、業務Ａのバックアップスケジュールが毎日０：００開始ならば、ライフサイクル定義一覧からバックアップ開始時間が０：００であるライフサイクルである“バックアップ００：００”をライフサイクル名として選択指定を受け付ける。なお、既にボリュームが存在する場合には、対応するボリュームのＬＵＮの指定を受け付けるようにしてもよい。
【００５９】
管理計算機１０では、リソースグループ管理モジュールＭ１２を実行するＣＰＵ１１が、グループの設定内容を受け取って、ユニークなグループＩＤを生成し、リソースグループ管理テーブルＴ１２に、当該グループＩＤと受け取ったグループの設定内容と含む新たなレコードを登録する（Ｓ１００４）。なお、設定内容にＬＵＮが含まれていない場合には、レコードのＬＵＮフィールドＴ１２ｅは、空の状態となる一方、ＬＵＮが含まれている場合には、レコードのＬＵＮフィールドＴ１２ｅには、当該ＬＵＮが格納される。リソースグループ管理テーブルＴ１２への登録が終了すると、リソースグループ管理モジュールＭ１２を実行するＣＰＵ１１は、処理結果を管理クライアント５０に通知する。これによって、管理クライアント５０においては、処理結果が表示される（ステップＳ１００８）。なお、複数のリソースグループを作成する場合には、上記処理が繰り返し実行されることとなる。以上の処理の終了後に、ユーザは、新たなボリュームを割り当てる作業に移ることが可能になる。
【００６０】
次に、業務ホスト計算機のボリュームやコピーペアのボリュームとしてボリュームを割り当てる際に、ボリュームの物理領域を決定するボリューム割り当て処理について説明する。このボリューム割り当て処理は、例えば、ボリュームマイグレーション時において、マイグレーション先のボリュームを割り当てる際に適用することもできる。なお、この場合には、マイグレーション元のボリュームに関連付けられていた業務のライフサイクル定義に応じて、マイグレーション先ボリュームの物理領域を決定するようにすればよい。
【００６１】
図９は、本発明の第１実施形態に係るボリューム割り当て処理を示す図である。
【００６２】
管理クライアント５０が、ユーザから、新たなボリュームを追加するリソースグループの指定と、当該リソースグループにおける新規ボリューム割り当て要求の指定とを受け付ける（ステップＳ１００１）。このとき、管理クライアント５０は、ボリューム割り当てに必要な他の設定情報、例えば、割り当てるＬＵＮ、及びボリュームのサイズの設定も合わせて受け付ける。なお、この際に、ユーザは、ストレージシステム２０の省電力機能が有効になるような物理構成を意識することなくボリュームの割り当ての指定を容易に行うことができる。次いで、管理クライアント５０は、リソースグループの指定や、ボリューム割り当てに必要な他の情報を含むボリューム割り当て要求を管理計算機１０に送信する。
【００６３】
管理計算機１０では、ストレージ管理プログラムＰ１のボリューム割り当てモジュールＭ１３を実行するＣＰＵ１１が、指定されたリソースグループにおいて、リソースグループ管理テーブルＴ１２のライフサイクル名フィールドＴ１２ｃを参照して、当該リソースグループのライフサイクル名を取得し（ステップＳ２００２）、ボリューム割り当てポリシーテーブルＴ１１からライフサイクル名に対応したバックアップ開始時刻とそのライフサイクルに基づくボリュームのデータを格納する物理領域を取得する（ステップＳ２００３）。ボリューム割り当てモジュールＭ１３を実行するＣＰＵ１１は、取得した物理領域に対応するＲＡＩＤグループからユーザが設定した設定情報に従ってボリュームを割り当てるようにストレージシステム２０のボリューム管理プログラムＰ３を実行するＣＰＵ２１１に要求する（ステップＳ２００５）。要求を取得したボリューム管理プログラムＰ３を実行するＣＰＵ２１１は、設定情報に従ってボリュームを割り当て、ディスク管理テーブルＴ２１２を更新する（ステップＳ２００６）。ボリュームの割り当てに成功すると、ボリューム割り当てモジュールＭ１３を実行するＣＰＵ１１は、割り当てられた新規ボリュームのＬＵＮをリソースグループ管理テーブルＴ１２の当該リソースグループに対応するレコードのＬＵＮフィールドＴ１２ｅに追加する（ステップＳ２００７）。以上の処理が終了すると、ボリューム割り当てモジュールＭ１３を実行するＣＰＵ１１は、ボリューム割り当て結果を管理クライアント５０に通知する。これによって、管理クライアント５０においては、ボリューム割り当て結果が表示される（ステップＳ２００８）。
【００６４】
以上の処理によって、アクセス傾向が一致するデータが同一のＲＡＩＤグループに含まれるようにボリュームを割り当てることができるので、ストレージシステム２０が提供するディスク装置２４の省電力機能を効果的に動作させることができるようになる。
【００６５】
次に、本実施形態についての変形例について説明する。
【００６６】
上記実施形態では、ボリューム割り当てポリシーテーブルＴ１１に、バックアップ開始時刻フィールドＴ１１ｂを設け、バックアップ開始時刻が同じバックアップ用ボリュームを同一ＲＡＩＤグループ（又はディスク)に配置するようにしていたが、本発明はこれに限られず、ボリュームを利用するプログラムの利用形態、例えば、“夜間バッチ”のようにアクセス傾向がわかるような場合には、図１０に示すボリューム割り当てポリシーテーブルＴ１３を用いるようにしてもよい。
【００６７】
図１０は、本発明の第１の変形例に係るボリューム割り当てポリシーテーブルの一例を示す図である。
【００６８】
ボリューム割り当てポリシーテーブルＴ１３は、ライフサイクル名フィールドＴ１３ａと、物理領域フィールドＴ１３ｂとを含む。ライフサイクル名フィールドＴ１３ａには、ライフサイクル名として、プログラム名、例えば、夜間バッチ、業務Ａプログラム、ＯＡ，バックアッププログラム等が格納される。物理領域フィールドＴ１１ｃには、対応するライフサイクルに従って運用される業務やアプリケーションのボリュームを生成すべき物理領域を示す識別情報が格納される。
【００６９】
このボリューム割り当てポリシーテーブルＴ１３によると、ライフサイクル名フィールドＴ１３ａに格納されたライフサイクル名からアクセス傾向の違いを把握することができる。例えば、ライフサイクル名が夜間バッチであれば、夜間バッチに関連するボリュームは夜間のアクセスが主であると把握でき、ライフサイクル名がＯＡであれば、ＯＡ用のボリュームは通常勤務時間のアクセスが多いと把握することができる。これによって、利用時間に関するフィールドを備えなくともよく、データ量を低減することができる。
【００７０】
図１０に示すボリューム割り当てポリシーテーブルＴ１３とした場合におけるリソースグループ管理テーブルの一例を説明する。
【００７１】
図１１は、本発明の第１の変形例に係るリソースグループ管理テーブルの一例を示す図である。
【００７２】
リソースグループ管理テーブルＴ１４は、グループＩＤフィールドＴ１４ａと、グループ名フィールドＴ１４ｂと、ライフサイクル名フィールドＴ１４ｃと、ＬＵＮフィールドＴ１４ｄｅとを含む。グループＩＤフィールドＴ１４ａには、グループＩＤが格納される。グループ名フィールドＴ１４ｂには、グループ名として、業務プログラムの種類が格納される。ライフサイクル名フィールドＴ１４ｃには、ライフサイクル名として、プログラム種類名が格納される。ＬＵＮフィールドＴ１４ｄには、対応するリソースグループに所属するボリュームのＬＵＮが格納される。
【００７３】
このようなリソースグループ管理テーブルＴ１４を用意した場合には、ボリュームを割り当て時には、管理クライアント５０は、ユーザから割り当てるボリュームを使用するプログラム種類の指定を受け付けることとなる。この場合には、管理計算機１０のＣＰＵ１１が管理クライアント５０からプログラム種類を受け付け、当該プログラム種類に対応するライフサイクル名をリソースグループ管理テーブルＴ１４から取得し、当該ライフサイクル名に対応する物理領域をボリューム割り当てポリシーテーブルＴ１３から取得し、当該物理領域からボリュームが割り当てられる。
（第２実施形態）
次に、本発明の第２実施形態について説明する。なお、以下、第１実施形態との相違点を主に説明し、第１実施形態との共通点については説明を省略あるいは簡略する。
【００７４】
第２実施形態では、ユーザが業務ごとに適用するライフサイクル定義を事前に設定しておくのではなく、既存のボリュームのアクセス頻度の履歴から適用するライフサイクル定義を特定し、その特定結果に応じて新規ボリュームの物理領域を決定する。本実施形態は、ボリュームに対するアクセス傾向を予め明示的に定義しておくことが難しいケースに有効である。
【００７５】
第２実施形態に係る計算機システムは、図１に示す第１実施形態における計算機システムにおいて、ストレージ管理プログラムＰ１に変えてストレージ管理プログラムＰ５を備えるようにしたものである。
【００７６】
図１２は、本発明の第２実施形態に係るストレージ管理プログラムの構成を示す図である。
【００７７】
ストレージ管理プログラムＰ５は、ライフサイクル管理モジュールＭ５１、リソースグループ管理モジュールＭ５２、ボリューム割り当てモジュールＭ５３、ストレージ管理モジュールＭ５４、ボリューム割り当てポリシーテーブルＴ５１、リソースグループ管理テーブルＴ５２、およびアクセス頻度履歴テーブルＴ５３を備える。ストレージ管理プログラムＰ５は、ストレージシステム２０上の各種プログラムと連携することによってストレージシステム２０に関する機能を提供する処理をＣＰＵ１１に実行させるためのプログラムである。例えば、ストレージ管理プログラムＰ５を実行するＣＰＵ１１は、ストレージシステム２０が提供するＬＵの構成を管理し、ＬＵの割り当てや属性の変更、ＬＵ間のデータコピーやデータマイグレーションに関する機能を提供する。
【００７８】
ライフサイクル管理モジュールＭ５１は、ライフサイクル定義の管理と、ライフサイクル定義とボリュームとの関連を管理する処理をＣＰＵ１１に実行させるためのモジュールである。ライフサイクル定義とは、ボリュームに対するアクセス傾向に関する情報の定義であり、例えば、ボリュームに対するアクセスの低下時期に関する定義がある。より具体的には、例えば、２００６年７月にアクセス低下するとの定義や、２００６年９月にアクセス低下するとの定義等がある。これらの定義はボリューム割り当てテーブルＴ５１で管理される。
【００７９】
リソースグループ管理モジュールＭ５２は、管理対象となるストレージシステム２０や業務ホスト計算機３０の構成情報をもとに、ボリュームや業務ホスト計算機３０などのリソースをユーザが任意の単位でグルーピングして管理できるようにするための機能をＣＰＵ１１に実行させるためのモジュールである。例えば、ＬＵＮ“１０１”と“１０２”とを業務Ａ用のボリュームとして利用する場合には、これらをグルーピングして業務Ａのグループとして管理するための機能を提供する。これらのデータはリソースグループ管理テーブルＴ５２に格納される。
【００８０】
ボリューム割り当てモジュールＭ５３は、ユーザからボリューム割り当て要求を受け付けると、リソースグループ管理テーブルＴ５１とアクセス頻度履歴管理テーブルＴ５３とを参照して、新たなボリュームの属するリソースグループにおけるアクセス頻度低下時期を決定し、ボリューム割り当てテーブルＴ５２を参照して当該アクセス頻度低下時期と同じ或いは近い時期にアクセス頻度が低下するＲＡＩＤグループ（又は、ディスク）を決定し、そのＲＡＩＤグループからボリュームを割り当てるようにストレージシステム２０に要求する。
【００８１】
ストレージ管理モジュールＭ５４は、ストレージシステム２０が提供する種々の管理機能を管理するためのストレージ管理機能をＣＰＵ１１に実行させるためのモジュールである。ストレージ管理機能には、例えば、ストレージシステム２０やボリュームなどストレージリソースの構成管理、データレプリケーションの制御・監視機能やデータマイグレーション機能等がある。本実施形態では、ストレージ管理モジュールＭ５４は、ストレージシステム２０における各ＬＵに対するアクセスの情報を取得し、各ＬＵに対するアクセス頻度の履歴を管理する処理をＣＰＵ１１に実行させる。アクセス頻度の履歴は、アクセス頻度履歴テーブルＴ５３によって管理される。
【００８２】
ボリューム割り当てポリシーテーブルＴ５１は、ライフサイクル定義とライフサイクル定義に対応するボリュームを生成すべき物理領域との関連を管理するためのテーブルである。ここで、物理領域としては、例えば、１のディスクドライブ２４１の記憶領域であってもよく、複数のディスクドライブ２４１により構成されるＲＡＩＤグループの記憶領域であってもよく、或いは、複数のストレージシステム２０の中のいずれかのストレージシステムの記憶領域であってもよく、また、複数の場所（サイト）のそれぞれにおいて、複数のストレージシステム２０を備えている場合には、いずれかのサイトの記憶領域であってもよく、要は、ライフサイクル定義に対応するボリュームを生成するための記憶領域であればよい。
【００８３】
図１３は、本発明の第２実施形態に係るボリューム割り当てポリシーテーブルの一例を示す図である。
【００８４】
ボリューム割り当てポリシーテーブルＴ５１は、ライフサイクル定義フィールドＴ５１ａと、物理領域フィールドＴ５１ｂとを含む。ライフサイクル定義フィールドＴ５１ａには、ボリュームに対するアクセス頻度の低下時期を示すライフサイクル定義が格納される。ライフサイクル定義フィールドＴ５１ａには、例えば、２００６年の７月にアクセスが低下することが予想されるボリュームに対するライフサイクル定義として、“2006/07 アクセス低下”が格納される。例えば、ライフアクセス定義フィールドＴ５１ａには、複数年について、２ヶ月ごとのアクセス頻度低下時期を示すライフサイクル定義が格納されている。物理領域フィールドＴ５１ｂには、対応するライフサイクル定義に適合するボリュームを生成すべき物理領域を示す識別情報が格納される。本実施形態では、物理領域フィールドＴ１１ｃには、ＲＡＩＤグループ番号が格納されているが、省電力機能のＯＮ／ＯＦＦを制御できる物理領域の単位であれば、その他の属性値であってもよい。その他の属性値としては、例えば、ディスクＩＤ、ストレージシステムＩＤ、複数のボリュームを仮想的に一つのボリュームとして扱うためのストレージプールＩＤなどが含まれる。ボリューム割り当てポリシーテーブルＴ５１は、ストレージ管理プログラムＰ５のライフサイクル管理モジュールＭ５１によって更新される。
【００８５】
図１４は、本発明の第２実施形態に係るリソースグループ管理テーブルの一例を示す図である。
【００８６】
リソースグループ管理テーブルＴ５２は、グループＩＤフィールドＴ５２ａと、グループ名フィールドＴ５２ｂと、説明フィールドＴ５２ｃと、ＬＵＮフィールドＴ５２ｄとを含む。グループＩＤフィールドＴ５２ａには、リソースグループをユニークに識別するためのＩＤであるグループＩＤが格納される。ここで、リソースグループとは、アクセス頻度の低下の傾向が同様であると想定されるボリュームのグループである。本実施形態では、業務が同じであれば、同じようなアクセス頻度の低下傾向があると想定されるので、業務を単位としたグループとしている。なお、同じようなアクセス頻度の低下傾向があれば、リソースグループは、業務を単位とするものに限られない。グループ名フィールドＴ５２ｂには、対応するレコードのリソースグループの名称であるグループ名が格納される。説明フィールドＴ５２ｃには、対応するリソースグループの説明が格納される。ＬＵＮフィールドＴ５２ｄには、対応するリソースグループに所属するボリュームのＬＵＮが格納される。リソースグループ管理テーブルＴ５２は、リソースグループ管理モジュールＭ５２によって更新される。
【００８７】
図１５は、本発明の第２実施形態におけるストレージ管理プログラムのアクセス頻度履歴テーブルの一例を示す図である。
【００８８】
アクセス頻度履歴テーブルＴ５３は、ストレージシステム２０が提供する各ＬＵＮに対するアクセス頻度履歴を保持するテーブルである。アクセス頻度履歴テーブルＴ５３は、ストレージ管理モジュールＭ５４を実行するＣＰＵ１１によって実現される性能監視機能によって更新され、データが蓄積される。
【００８９】
アクセス頻度履歴テーブルＴ５３は、複数のＬＵＮに対して、所定の期間ごとのアクセス頻度の情報を格納する。本実施形態では、アクセス頻度の情報としては、実際のアクセス数を格納するのではなく、アクセスの頻度の程度を示す情報を格納するようにしている。具体的には、ストレージシステム２０におけるディスクドライブ２４１の省電力機能が動作する可能性がある程度であるか否かを示す情報を格納しており、例えば、省電力機能が動作しないレベルのアクセス頻度である場合には、“Ｈｉｇｈ”を格納し、省電力機能が動作するレベルまでアクセス頻度が低下している場合には、“Ｌｏｗ“を格納している。なお、対応するボリュームが割り当てられていない場合には、“−”を格納している。例えば、ディスクドライブ２４１の省電力機能を動作する条件、すなわちディスクドライブ２４１の電源を落とす条件として、１時間以上アクセスが発生しないという条件が設定されている場合には、２００６年５月に１日平均２５回以上アクセスがあったボリュームについては、当該ボリュームの“2006/05”のカラムには”Ｈｉｇｈ“が格納される。
【００９０】
次に、第２実施形態に係る動作を説明する。
【００９１】
本実施形態の計算機システムにおいては、各業務ホスト計算機３０に割り当てられているボリュームは、業務ごとにグルーピングされている。また、各ＲＡＩＤグループには、ライフサイクル定義としてアクセス頻度が低下する時期が関連付けられている。
【００９２】
ここで、ある業務ホスト計算機３０に対して新たなボリュームを割り当てる場合を例に処理概要を説明する。割り当て要求が発生した場合には、管理計算機１０のストレージ管理プログラムＰ５を実行するＣＰＵ１１が、当該業務の既存のボリュームのアクセス頻度履歴から、新規割り当てボリュームのアクセス頻度が低下すると予想される時期を決定し、当該時期とアクセス頻度が低下する時期が一致するようなライフサイクル定義と関連付けられているＲＡＩＤグループからボリュームを割り当てるように処理を行う。この処理により、同一ＲＡＩＤグループには、同時期にアクセス頻度が低下するボリュームが集約されるため、所定の時間が経過すると、同一のＲＡＩＤグループに属するディスクドライブ２４１に対するアクセス頻度が低下するので省電力機能が動作して電源ＯＦＦ状態となり、長期的な視点からストレージシステム２０の省電力機能の効率を向上することができる。
【００９３】
図１６は、本発明の第２実施形態に係る処理概要を説明する図である。
【００９４】
業務Ａのボリュームを新たに拡張してＬＵＮ“３０５”を割り当てる場合において、過去のアクセス頻度情報から業務Ａのボリュームは２ヶ月でアクセス頻度が低下することが検出され、また、業務Ｂのボリュームは４ヶ月でアクセス頻度が低下することが検出されると、割り当てる業務Ａのボリュームのアクセス頻度が低下する時期（２ヵ月後）が一致するようなＲＡＩＤグループ、すなわち、２ヶ月前に業務Ｂに割り当てたボリューム“３０４”が属するＲＡＩＤグループ“Ｒ０１３”からボリュームを割り当てるように処理する。このため、２ヶ月後には、業務Ｂのボリューム“３０４”に対するアクセス頻度の低下が発生し、同時に業務Ａの新規ボリューム“３０５”のアクセス頻度も低下すると予想されるため、ＲＡＩＤグループ“Ｒ０１３”の各ディスクにおける省電力効果も期待できる。
【００９５】
次に、第２実施形態に係る処理を詳細に説明する。
【００９６】
本実施形態の計算機システムにおいては、ライフサイクル定義を作成するためのボリューム割り当てポリシー作成処理と、業務毎にグルーピングするためのリソースグループ作成処理と、ストレージ管理プログラムＰ５を実行するＣＰＵ１１が、定義したライフサイクル定義に従って適切な物理領域からボリュームを割り当てるボリューム割り当て処理とが実行される。なお、ボリューム割り当てポリシー作成処理と、リソースグループ作成処理とは、図７および図８に示す第１実施形態の処理と、ボリューム割り当てポリシーテーブルＴ５１およびリソースグループ管理テーブルＴ５２とに格納するデータが異なるが、全体的な流れについては、ほぼ同様であるのでここでは説明を省略する。
【００９７】
次に、新たなボリュームを割り当てる際に、ボリュームの物理領域を決定するボリューム割り当て処理について説明する。このボリューム割り当て処理は、例えば、ボリュームマイグレーション時において、マイグレーション先のボリュームを割り当てる際に適用することもできる。なお、この場合には、マイグレーション元のボリュームに関連付けられていた業務のライフサイクル定義に応じて、マイグレーション先ボリュームの物理領域を決定するようにすればよい。
【００９８】
図１７は、本発明の第２実施形態に係るボリューム割り当て処理を示す図である。
【００９９】
管理クライアント５０が、ユーザから、新たなボリュームを追加するリソースグループ（例えば、業務）の指定と、当該リソースグループにおける新規ボリューム割り当て要求の指定とを受け付ける（ステップＳ４００１）。このとき、管理クライアント５０は、ボリューム割り当てに必要な他の設定情報、例えば、割り当てるＬＵＮ、及びボリュームのサイズの設定も合わせて受け付ける。なお、この際に、ユーザは、ストレージシステム２０の省電力機能が有効になるような物理構成を意識することなくボリュームの割り当ての指定を容易に行うことができる。次いで、管理クライアント５０は、リソースグループの指定や、ボリューム割り当てに必要な他の設定情報を含むボリューム割り当て要求を管理計算機１０に送信する。
【０１００】
管理計算機１０では、ストレージ管理プログラムＰ５のボリューム割り当てモジュールＭ５３を実行するＣＰＵ１１が、アクセス頻度履歴テーブルＴ５３から当該リソースグループ内の各ボリュームのアクセス頻度履歴を取得する（ステップＳ４００３）。
【０１０１】
次いで、ＣＰＵ１１は、このボリュームの中にアクセス頻度が低下したボリューム（図１５において現在に対応するアクセス頻度が“Ｌｏｗ”になっているＬＵＮ）が含まれているか否かを判定する。
【０１０２】
この結果、同一のリソースグループ内にアクセス頻度が低下したボリュームが含まれていない場合（ステップＳ４００５、ＮＯ）には、同一リソースグループ内のボリュームのうち、最近割り当てられたボリュームのアクセス頻度の傾向と一致する又は近似するとみなして、当該ボリュームが属するＲＡＩＤグループからボリュームを作成する（ステップＳ４０１５）。すなわち、当該ＲＡＩＤグループからユーザが設定した設定情報に従ってボリュームを割り当てるようにストレージシステム２０のボリューム管理プログラムＰ３を実行するＣＰＵ２１１に要求する。これによって、要求を取得したボリューム管理プログラムＰ３を実行するＣＰＵ２１１は、設定情報に従ってボリュームを割り当て、ディスク管理テーブルＴ２１２を更新する。ボリュームの割り当てに成功すると、ボリューム割り当てモジュールＭ５３を実行するＣＰＵ１１は、割り当てられた新規ボリュームのＬＵＮをリソースグループ管理テーブルＴ５２の当該リソースグループに対応するレコードのＬＵＮフィールドＴ５２ｄに追加する。
【０１０３】
一方、同一のリソースグループ内にアクセス頻度が低下したボリュームが含まれている場合（ステップＳ４００５、ＹＥＳ）には、ボリューム割り当てモジュールＭ５３を実行するＣＰＵ１１は、アクセス頻度履歴テーブルＴ５３のアクセス頻度履歴に基づいて、リソースグループ内の各既存ボリュームに対して、割り当てからアクセス頻度低下までの期間（時間）を求め、同一のリソースグループの各ボリュームにおける割り当てからアクセス頻度が低下するまでの平均期間を算出し（ステップＳ４００７）、当該平均期間を現在時刻に加えること、新規割り当てボリュームのアクセス頻度が低下する予想時期を求める（ステップ：Ｓ４００９）。次に、ボリューム割り当てモジュールＭ５３を実行するＣＰＵ１１は、ストレージシステム２０に属する各ＲＡＩＤグループにおいて、ボリューム割り当てポリシーテーブルＴ５１からＲＡＩＤグループに関連付けられているライフサイクル定義の一覧からアクセス頻度が低下する時期の一覧を取得する（ステップＳ４０１１）。
【０１０４】
次いで、ボリューム割り当てモジュールＭ５３を実行するＣＰＵ１１は、ステップＳ４００９で求めた業務単位のリソースグループから求めたアクセス頻度の低下予想時期を、ステップＳ４０１１で求めた各ＲＡＩＤグループのアクセス頻度予想低下時期と比較し、最も近い予想低下時期を持つＲＡＩＤグループの物理領域からボリュームを作成する（ステップＳ４０１３）。すなわち、最も近い予想低下時期を持つＲＡＩＤグループから、ユーザが設定した設定情報に従ってボリュームを割り当てるようにストレージシステム２０のボリューム管理プログラムＰ３を実行するＣＰＵ２１１に要求する。これによって、要求を取得したボリューム管理プログラムＰ３を実行するＣＰＵ２１１は、設定情報に従ってボリュームを割り当て、ディスク管理テーブルＴ２１２を更新する。ボリュームの割り当てに成功すると、ボリューム割り当てモジュールＭ５３を実行するＣＰＵ１１は、割り当てられた新規ボリュームのＬＵＮをリソースグループ管理テーブルＴ５２の当該リソースグループに対応するレコードのＬＵＮフィールドＴ５２ｄに追加する。
【０１０５】
ステップＳ４０１３又はステップＳ４０１５の処理が終了すると、ボリューム割り当てモジュールＭ５３を実行するＣＰＵ１１は、ボリューム割り当て結果を管理クライアント５０に通知する。これによって、管理クライアント５０においては、ボリューム割り当て結果が表示される（ステップＳ４０２０）。
【０１０６】
以上の処理によって、アクセス頻度の低下時期が一致すると想定されるボリュームを同一のＲＡＩＤグループから割り当てることができるので、ストレージシステム２０が提供するディスク装置２４の省電力機能を効果的に動作させることができるようになる。
【０１０７】
以上、本実施形態によれば、ある業務やあるアプリケーションにボリュームを割り当てる際に、業務で利用するボリュームのアクセスの傾向やボリュームを利用するアプリケーションのアクセスの傾向に応じて、アクセスの発生する時期やアクセスの低下する時期が一致するようなデータを格納するディスクからボリュームを割り当てることにより、同一ディスクにアクセス傾向の一致するデータが集約され、ストレージ装置が提供する省電力機能を効率よく利用することが可能になる。
【０１０８】
以上、実施形態に基づき本発明に係る計算機、計算機における記憶領域管理方法、計算機システムを説明してきたが、上記した発明の実施の形態は、本発明の理解を容易にするためのものであり、本発明を限定するものではない。本発明は、その趣旨並びに特許請求の範囲を逸脱することなく、変更、改良され得ると共に、本発明にはその等価物が含まれることはもちろんである。
【０１０９】
例えば、上記第１実施形態では、リソースグループとボリューム割り当てポリシーとを対応付けておき、ボリュームの割り当て要求時に、ボリュームが所属するリソースグループを指定することで、リソースグループに対応付けられたボリューム割り当てポリシーに従って物理領域を決定していたが、本発明はこれに限られず、例えば、各ボリュームに直接ライフサイクル定義を対応付けて管理するようにしてもよい。この場合には、ボリュームを割り当てる際に、ボリュームのライフサイクルを設定することとなる。
【０１１０】
また、上記第１実施形態では、ボリュームを割り当てる際に、ユーザからボリュームが属する業務の指定を受け付けるようにしていたが、例えば、ボリュームによるバックアップ開始時刻を受け付けるようにしてもよい。この場合には、図５に示すリソースグループ管理テーブルＴ１２を備えずともよく、また、図９に示すボリューム割り当て処理における、ステップＳ２００２の処理を行う必要がなくなる。
【０１１１】
また、上記第２実施形態では、リソースグループ管理テーブルＴ５２に、ライフサイクル名フィールドを備えないようにしていたが、本発明はこれに限られず、例えば、ライフサイクル名フィールドを備え、そのフィールドにデフォルトで利用するライフサイクル定義名を格納するようにしてもよい。そして、例えば、アクセス頻度履歴テーブルＴ５３に、各グループのアクセス頻度傾向を特定するために十分なアクセス頻度履歴が蓄積されていない等の理由で、グループのライフサイクルを決定できない場合に、当該フィールドに格納されたライフサイクル定義名に対応するライフサイクル定義に基づいて、ボリュームの物理領域を決定するようにしてもよい。
【０１１２】
また、上記第２実施形態では、ボリューム割り当てポリシーテーブルＴ５１を備えるようにしていたが、ボリューム割り当てポリシーテーブルＴ５１を備えないようにしてもよい。この場合には、ＣＰＵ１１が、ＲＡＩＤグループ内の各ボリュームのアクセス頻度履歴から各ＲＡＩＤグループのアクセス頻度の低下予想時期を検出する。具体的には、ＣＰＵ１１が、ＲＡＩＤグループに属する各ボリュームに対して、各ボリュームが所属するリソースグループ内のボリュームにステップＳ４００３、Ｓ４００７と同様の処理を実行し、ＲＡＩＤグループに属する当該ボリュームのアクセス頻度が低下するまでの期間Ｔａを求めた後、当該ボリュームが割り当てられてから期間Ｔａが経過した時期Ｔｂを決定する。このようにして、同一ＲＡＩＤグループ内のすべてのボリュームに対して決定された時期Ｔｂの内で最も遅い時期Ｔｂを、当該ＲＡＩＤグループのアクセス頻度予想低下時期とみなす。そして、ＣＰＵ１１が、複数のＲＡＩＤグループに対してアクセス頻度予想低下時期を検出し、これら検出した時期を用いて、ステップＳ４０１３の処理を実行する。これによって、上記第２実施形態と同様に、アクセス頻度の低下時期が一致すると想定されるボリュームを同一のＲＡＩＤグループから割り当てることができ、ストレージシステム２０が提供するディスク装置２４の省電力機能を効果的に動作させることができる。
【０１１３】
また、上記第１実施形態および第２実施形態において、上記したボリューム割り当て処理において、業務で利用するコピーペアのプライマリボリュームについての割り当てを行った後に、コピーペアのセカンダリボリュームのボリューム割り当て処理を行う場合には、プライマリボリュームの処理のステップで得られた情報を利用して、セカンダリボリュームの割り当て処理を行うようにしてもよい。例えば、図１７に示す処理においては、プライマリボリュームの処理において、ステップＳ４００９で得られたアクセス低下予想時期を記憶してき、このアクセス低下予想時期を利用することにより、セカンダリボリュームに対するボリューム割り当て処理において、ステップＳ４００３〜Ｓ４００９のステップを実行する必要がなく、迅速にボリュームの割当を行うことができる。
【図面の簡単な説明】
【０１１４】
【図１】本発明の第１実施形態に係る計算機システムの概略構成を示す図である。
【図２】本発明の第１実施形態に係るディスク管理テーブルの一例を示す図である。
【図３】本発明の第１実施形態に係るストレージ管理プログラムの構成を示す図である。
【図４】本発明の第１実施形態に係るボリューム割り当てポリシーテーブルの一例を示す図である。
【図５】本発明の第１実施形態に係るリソースグループ管理テーブルの一例を示す図である。
【図６】本発明の第１実施形態に係る処理概要を説明する図である。
【図７】本発明の第１実施形態に係るボリューム割り当てポリシー作成処理を示す図である。
【図８】本発明の第１実施形態に係るリソースグループ作成処理を示す図である。
【図９】本発明の第１実施形態に係るボリューム割り当て処理を示す図である。
【図１０】本発明の第１の変形例に係るボリューム割り当てポリシーテーブルの一例を示す図である。
【図１１】本発明の第１の変形例に係るリソースグループ管理テーブルの一例を示す図である。
【図１２】本発明の第２実施形態に係るストレージ管理プログラムの構成を示す図である。
【図１３】本発明の第２実施形態に係るボリューム割り当てポリシーテーブルの一例を示す図である。
【図１４】本発明の第２実施形態に係るリソースグループ管理テーブルの一例を示す図である。
【図１５】本発明の第２実施形態に係るストレージ管理プログラムのアクセス頻度履歴テーブルの一例を示す図である。
【図１６】本発明の第２実施形態に係る処理概要を説明する図である。
【図１７】本発明の第２実施形態に係るボリューム割り当てに関する処理を示す図である。
【符号の説明】
【０１１５】
１０  管理計算機、１１  ＣＰＵ（中央演算装置）、１２  メモリ、１３  フロントエンドＩ／Ｏインタフェース、１４  リアエンドＩ／Ｏインタフェース、２０  記憶装置システム、２１  ディスクアレイコントローラ、２１１  ＣＰＵ、２１２  メモリ、２２  キャッシュ、２３  Ｉ／Ｏインタフェース、２４  ディスク装置、２４１  ディスクドライブ、２５  Ｉ／Ｏインタフェース、２６  電源制御装置、３０  業務ホスト計算機、３１  ＣＰＵ、３２  メモリ、３３  フロントエンドＩ／Ｏインタフェース、３４  リアエンドＩ／Ｏインタフェース、４０  ネットワーク（ＬＡＮ）、４１  ストレージエリアネットアーク（ＳＡＮ）、５０  管理クライアント、Ｐ１  ストレージ管理プログラム、Ｐ２  業務プログラム、Ｐ３  ボリューム管理プログラム、Ｐ４  電源制御プログラム、Ｐ５  ストレージ管理プログラム、Ｍ１１  ライフサイクル管理モジュール、Ｍ１２  リソースグループ管理モジュール、Ｍ１３  ボリューム割り当てモジュール、Ｍ１４  ストレージ管理モジュール、Ｍ５１  ライフサイクル管理モジュール、Ｍ５２  リソースグループ管理モジュール、Ｍ５３  ボリューム割り当てモジュール、Ｍ５４  ストレージ管理モジュール、Ｔ１１  ボリューム割り当てポリシーテーブル、Ｔ１２  リソースグループ管理テーブル、Ｔ１３  ボリューム割り当てポリシーテーブル、Ｔ１４  リソースグループ管理テーブル、Ｔ５１  ボリューム割り当てポリシーテーブル、Ｔ５２  リソースグループ管理テーブル、Ｔ５３  アクセス頻度履歴テーブル、Ｔ２１２  ディスク管理テーブル。
【図１】
2008269441.tif 000003
【図２】
2008269441.tif 000004
【図３】
2008269441.tif 000005
【図４】
2008269441.tif 000006
【図５】
2008269441.tif 000007
【図６】
2008269441.tif 000008
【図７】
2008269441.tif 000009
【図８】
2008269441.tif 000010
【図９】
2008269441.tif 000011
【図１０】
2008269441.tif 000012
【図１１】
2008269441.tif 000013
【図１２】
2008269441.tif 000014
【図１３】
2008269441.tif 000015
【図１４】
2008269441.tif 000016
【図１５】
2008269441.tif 000017
【図１６】
2008269441.tif 000018
【図１７】
2008269441.tif 000019