JP5214502B2 - ストレージ装置を管理する計算機及び方法 - Google Patents

Description

本発明は、ストレージ装置の管理に関する。

論理ボリュームの一例として、特許文献１に開示されているような仮想ボリュームがある。仮想ボリュームは、複数のアドレス範囲を有している。或るアドレス範囲がライト先となる場合、そのアドレス範囲に、プールから物理領域（物理的な記憶領域）が割り当てられ、割り当てられた物理領域に、ライト対象のデータがライトされる。これにより、仮想ボリュームの実記憶容量が、動的に拡張される。割当て済み物理領域の或るアドレス範囲に対する割当てが解除されれば、その物理領域は未使用の物理領域となる。

プールの使用容量（割当て済みの物理領域の総記憶容量）の単位時間当りの変化量は、仮想ボリュームへのアクセスの傾向によって動的に異なる。このため、プールには、或る程度の余分な記憶容量が確保される。

しかし、アクセス傾向によっては、プールの使用容量があまり増加せず、それ故、プールのために確保されている記憶容量に無駄な記憶容量があることになってしまう。

例えば特許文献２には、以下の技術、すなわち、ボリュームの作成要求に応じて、プールの使用容量の増加傾向を把握し、或る時点で無駄と判断された記憶容量を、作成するボリュームの容量として用いる技術が開示されている。

特開２００３−１５９１５号公報 特開２００７−２４１５９３号公報

余剰の記憶容量分の物理領域をプールから削除することで、無駄に確保されている記憶容量を減らすことができる。しかし、そうすることが、ストレージ装置に対する入出力の観点で好ましく無いことが生じ得る。

このような課題は、仮想ボリュームに対するデータを格納するプールに限らず、他種のプール（例えば、コピー元のボリュームの差分情報やジャーナル情報を格納するプール）についても同様に生じ得る。

本発明の目的は、ストレージ装置に対する入出力を好適に維持しつつストレージ装置の構成変更を行えるよう支援することにある。

ストレージ装置に接続された管理計算機内の記憶資源が、プール管理情報を記憶する。プール管理情報は、プールについてのプール用途を表すプール用途情報と、プール用途についての条件を表す用途条件情報とを含む。プールは、ＲＡＩＤ（Redundant Array of Independent (or Inexpensive) Disks）グループに基づく実ボリュームを１つ以上有する。管理計算機内のプロセッサが、
以下の（Ａ）乃至（Ｄ）の処理、
（Ａ）プールについてのプール使用状況を基に余剰の記憶容量を算出する；
（Ｂ）上記プール管理情報を基に、そのプールについてのプール用途と、そのプール用途についての条件とを特定する；
（Ｃ）算出された余剰の記憶容量以下の記憶領域をプールから削除しても上記特定された条件を満たすか否かを判定する；
（Ｄ）上記（Ｃ）での判定の結果が肯定的の場合に、余剰の記憶容量以下の容量を未使用容量と定義する；
を実行する。

プロセッサは、例えば、ストレージ装置の未使用容量を表す情報を含んだ記憶容量レポートを出力する。その未使用容量は、例えば、ＲＡＩＤグループについての未使用容量と、上記（Ｄ）で未使用容量と定義された容量（余剰の記憶容量以下の容量）との合計（又はそれに基づく容量）である。

ここで、「ＲＡＩＤグループについての未使用容量」とは、論理ボリュームが定義されていない記憶領域の容量である。つまり、ＲＡＩＤグループに基づく記憶空間の全部又は一部を論理ボリュームとして定義することができるが、その記憶空間のうち論理ボリュームとして定義されていない記憶空間部分が、ＲＡＩＤグループについての未使用の部分であり、その記憶空間部分の容量が、ＲＡＩＤグループについての未使用容量である。

一方、プールについての未使用容量とは、プールが有する複数の物理領域のうち仮想ボリュームに割り当てられていない一以上の物理領域の総量である。プール使用状況から、プールについての未使用容量が把握され、その未使用容量を基に、余剰の記憶容量を算出する。

図１は、本発明の第一の実施形態に係る計算機システムの構成を示す。 図２は、ストレージ１０００の構成を示す。 図３は、管理計算機１２００の構成を示す。 図４は、ＲＡＩＤグループテーブル４０００を示す。 図５は、プール容量テーブル５０００を示す。 図６は、仮想ボリュームテーブル６０００を示す。 図７は、プール割当テーブル７０００を示す。 図８は、プールボリュームテーブル８０００を示す。 図９は、仮想ボリューム割当テーブル９０００を示す。 図１０は、ストレージ識別テーブル１００００を示す。 図１１は、プール設定テーブル１１０００を示す。 図１２は、プール容量増加判定テーブル１２０００を示す。 図１３は、プール用途テーブル１３０００を示す。 図１４は、プール設定画面１４０００を示す。 図１５は、容量レポート出力指示画面１５０００を示す。 図１６は、本発明の第一の実施形態に係る容量レポート画面１６０００を示す。 図１７は、プール作成処理のフローチャートである。 図１８は、容量レポート表示処理のフローチャートである。 図１９は、本発明の第二の実施形態に係る容量レポート画面２６０００を示す。

以下、図面を参照して、本発明の幾つかの実施形態を説明する。なお、以下の説明において、コンピュータプログラムが行う処理は、実際には、そのコンピュータプログラムを実行するプロセッサが行うことになる。

図１は、本発明の第一の実施形態に係る計算機システムの構成を示す。

複数（又は一つ）のホスト計算機（以下、ホスト）１１００と、複数（又は一つ）のストレージ装置（以下、ストレージ）１０００とが、データネットワーク１３００を介して接続される。各ストレージ１０００は、データネットワーク１３００を介して、ホスト１１００から入出力要求（Ｉ／Ｏ要求）を受け付ける。Ｉ／Ｏ要求は、例えば、ストレージ装置１０００が管理する論理ボリュームを指定したライト要求又はリード要求である。各ストレージ１０００にとっての外部装置は、ホスト１１００に代えて、外部のストレージ１０００であっても良い。

ホスト１１００からストレージ１０００へのアクセスは、例えば、ブロックレベルのアクセスである。このため、データネットワーク１３００は、通常、ＦＣ（Fibre Channel）ネットワークが考えられる。しかし、それに限らず、データネットワーク１３００は、ｉＳＣＳＩなどを通す、ＴＣＰ／ＩＰのネットワークであってもよい。あるいは、ホスト１１００の中にストレージ１０００が含まれてもよい。すなわち、データネットワーク１３００がホスト１１００の内部バスとなり、ホスト１１００がストレージ１０００の機能を実現してもよい。このケースとしては、例えば、ＮＡＳ（Network Attached Storage）が考えられる。

管理計算機１２００と各ストレージ１０００とが、管理ネットワーク１４００を介して接続される。管理計算機１２００は、管理ネットワーク１４００を介して、ストレージ１０００が管理する情報（例えば後述のストレージ構成情報１０４２（図２参照））をストレージ１０００から取得する。なお、ストレージ１０００が、自発的に（例えば管理計算機１２００から何ら要求を受けることなく）、管理情報を管理計算機１２００に送信しても良い。

管理ネットワーク１４００は、管理情報が取得できれば、どのような種類のネットワークであっても良い。管理ネットワーク１４００に各ホスト１１００が接続されていても良く、この場合、管理計算機１２００は各ホスト１１００と通信しても良い。また、管理計算機１２００及びホスト１１００が接続される第一の管理ネットワークと、管理計算機１２００及びストレージ１０００が接続される第二の管理ネットワークとが、別々のネットワークであってもよい。例えば、第一の管理ネットワークがＴＣＰ／ＩＰネットワークで、第二のネットワークがＦＣネットワークであっても良い。

図２は、ストレージ１０００の構成を示す。

ストレージ１０００は、下記の要素：
データネットワーク１３００に接続され、ホスト１１００からＩ／Ｏ要求を受け付けるインターフェイス装置（入出力Ｉ／Ｆ）１０１０；
管理ネットワーク１４００に接続され、管理計算機１２００から種々の要求を受け付けるインターフェイス装置（管理Ｉ／Ｆ）１０１１；
ストレージ１０００の動作を制御するコントローラ（例えば、マイクロプロセッサ、又は、マイクロプロセッサを備えた回路基板）１０２０；
コントローラ１０２０に接続されており、ストレージ１０００の性能向上のために利用される（例えば、論理ボリュームに読み書きされるデータを一時的に記憶する）キャッシュメモリ（以下、キャッシュ）１０３０；
コントローラ１０２０に接続されているメモリ１０４０；
コントローラ１０２０に接続されている複数（又は一つ）のＲＡＩＤグループ１０８０；
を備える。

ＲＡＩＤグループ１０８０は、所定のＲＡＩＤレベルでデータを記憶する、二以上のハードディスク１０７０で構成されたグループである。ハードディスク１０７０に代えて、他種のストレージ媒体、例えば、フラッシュメモリが採用されてもよい。

ＲＡＩＤグループ１０８０の記憶空間を基に作成された論理ボリュームが、実ボリューム１０５０である。実ボリューム１０５０は、ホスト１１００に提供されることのない論理ボリュームであるプールボリューム１０２２とされることもできるし、ホスト１１００に提供される論理ボリュームである通常の論理ボリュームとされることもできる。なお、ＲＡＩＤグループ１０８０は外部のストレージ１０００に備えられていて、その外部のストレージ１０００のＲＡＩＤグループ１０８０を基に、図２に示されるストレージ１０００が実ボリューム１０５０（例えばプールボリューム又は通常の論理ボリューム）を備えても良い。

ストレージ１０００では、プール１０６０が管理される。プール１０６０は、１又は複数のプールボリューム１０２２を有する。各プールボリューム１０２２は、複数の物理領域で構成されている。それ故、プール１０６０は、多数の物理領域を有する。それぞれの物理領域は、例えば全て同一のサイズである。

また、ストレージ１０００では、仮想ボリューム１０５１が管理される。仮想ボリューム１０５１は、ホスト１１００に提供される論理ボリューム（つまり、通常の論理ボリューム）の一種であり、ＲＡＩＤグループ１０８０に基づかない論理ボリュームである。仮想ボリューム１０５１は、複数のアドレス範囲（別の言い方をすれば仮想領域）を有する。各アドレス範囲に、プールにおけるいずれかの物理領域が割り当てられる。

メモリ１０４０は、ストレージ構成プログラム１０４１と、ストレージ構成情報１０４２とを記憶する。ストレージ構成プログラム１０４１は、コントローラ１０２０によって実行される。ストレージ構成情報１０４２は、ストレージ構成プログラム１０４１から参照される情報であり、ストレージ１０００の構成に関する管理情報である。なお、この情報１０４２は、管理計算機１２００のメモリ１２３０（図３参照）で管理されてもよい。

ストレージ構成プログラム１０４１は、ストレージ１０００の構成について管理するプログラムであり、下記の機能：
実ボリューム１０５０、仮想ボリューム１０５１、プールボリューム１０５２及びプール１０６０を作成する機能；
仮想ボリューム１０５１にプール１０６０内の物理領域を割り当てる機能；
実ボリューム１０５０や仮想ボリューム１０５１を入出力Ｉ／Ｆ１０１０経由でホスト１１００に提供する機能；
実ボリューム１０５０や仮想ボリューム１０５１間でのデータ移行を行なう機能；
などを有する。

前述した実ボリューム１０５０及びプールボリューム１０５２は、ＲＡＩＤグループ１８０に基づくことに代えて、ハードディスク１０７０それ自体に基づく論理ボリュームであっても良い。

図３は、管理計算機１２００の構成を示す。

管理計算機１２００は、入出力装置１２１０と、ＣＰＵ（Central Processing Unit）１２２０と、メモリ１２３０と、管理Ｉ／Ｆ１２６０とを有する。

管理Ｉ／Ｆ１２６０は、管理ネットワーク１４００に接続されるインターフェイス装置である。管理計算機１２００は、管理Ｉ／Ｆ１２６０を介して、ストレージ１０００（及びホスト１１００）と通信する。

入出力装置１２１０は、入力装置（例えば、キーボード、ポインティングデバイス或いはマイク）と、出力装置（例えば、ディスプレイ装置、プリンタ、或いはスピーカ）とを有する。

メモリ１２３０は、仮想ボリュームを設定するための仮想ボリューム設定プログラム１２３１と、プールを設定するためのプール設定プログラム１２３２と、通常ボリュームを設定するための通常ボリューム設定プログラム１２３３と、容量レポートを出力するための容量レポートプログラム１２３４と、プール管理情報１２３５とを記憶する。これらのコンピュータプログラム１２３１〜１２３４は、それぞれ、ＣＰＵ１２２０によって実行される。プール管理情報１２３５は、プール１０６０に関する管理情報である。

ところで、ストレージ１０００が有するストレージ構成情報１０４２は、下記テーブル：
図４に示すＲＡＩＤグループテーブル４０００；
図５に示すプール容量テーブル５０００；
図６に示す仮想ボリュームテーブル６０００；
図７に示すプール割当テーブル７０００；
図８に示すプールボリュームテーブル８０００；
図９に示す仮想ボリューム割当テーブル９０００；
図１０に示すストレージ識別テーブル１００００；
を有する。以下、これらのテーブルについて説明する。なお、以下の説明では、特に記載が無い限り、記憶容量の単位は「バイト」である。例えば、テーブルに或る記憶容量として「１０Ｇ」と記載されていれば、その記憶容量は１０Ｇバイト（ギガバイト）である。

図４は、ＲＡＩＤグループテーブル４０００を示す。

ＲＡＩＤグループテーブル４０００は、ＲＡＩＤグループ毎に、下記の情報要素：
ＲＡＩＤグループの識別子であるＲＡＩＤグループＩＤ４０１０；
ＲＡＩＤグループの記憶容量（以下、「全体容量」と言う）を示す全体容量４０２０；
ＲＡＩＤグループの全体容量のうちの使用容量を示す使用容量４０３０；
ＲＡＩＤグループの全体容量のうちの未使用容量を示す未使用容量４０４０；
ＲＡＩＤグループを構成するハードディスク１０７０の種別を示すディスク種別４０５０；
ＲＡＩＤ構成のタイプ（ＲＡＩＤレベル）を示すＲＡＩＤタイプ４０６０；
ＲＡＩＤグループを構成するハードディスク１０７０の数を示すディスク数４０７０；
を有する。

ここで、ＲＡＩＤグループの使用容量とは、ＲＡＩＤグループに基づく記憶空間のうち論理ボリュームに使用されている記憶空間部分の容量である。一方、ＲＡＩＤグループの未使用容量とは、ＲＡＩＤグループに基づく記憶空間のうち論理ボリュームに使用されていない記憶空間部分の容量である（言い換えれば、全体容量から使用容量を減算することで得られる記憶容量である）。

図５は、プール容量テーブル５０００を示す。

プール容量テーブル５０００は、プール毎に、下記の情報要素：
プール１０６０の識別子であるプールＩＤ５０１０；
プール１０６０の記憶容量（全体容量）を示す全体容量５０２０；
プール１０６０から仮想ボリューム１０５１に割り当てられた物理領域の総記憶容量を示す割当容量５０３０；
割当容量の閾値を示す閾値５０４０；
を有する。

閾値５０４０は、仮想容量（仮想ボリュームの記憶容量）に対する割当容量の割合であり、例えば百分率で表される。仮想容量に対する割当容量の割合が、閾値５０４０を超ええることが、プールの全体容量を増やすかどうかの判断材料となる。ストレージ１０００は、仮想容量に対する割当容量の割合が閾値５０４０を超えた場合に、仮想ボリューム１０５１に物理領域を割り当てないという制御を行っても良い。閾値５０４０は、ユーザから設定されてもよいし、プールの全体容量に応じてストレージ構成プログラム１０４１から自動的に設定されてもよい。また、閾値５０４０は、百分率に代えて記憶容量で表現されても良い。

図６は、仮想ボリュームテーブル６０００を示す。

仮想ボリュームテーブル６０００は、仮想ボリューム毎に、下記の情報要素：
仮想ボリューム１０５１の識別子である仮想ボリュームＩＤ６０１０；
仮想ボリューム１０５１に対応付けられたプール（仮想ボリューム１０５１に割り当てられる物理領域の提供元のプール）１０６０の識別子を示すプールＩＤ６０２０；
仮想ボリューム１０５１の記憶容量（仮想容量）であってホスト１１００に認識される記憶容量を示す仮想容量６０３０；
仮想ボリューム１０５１に割当て済みの物理領域の総記憶容量を示す実割当容量６０４０；
を有する。

前述したとおり、ホスト１１００からの仮想ボリューム１０５１に対するライト要求に応じて、仮想ボリューム１０５１の実割当容量が増えていくことになる。ホスト１１００に仮想ボリューム１０５１を認識させるために、各仮想ボリューム１０５１に対して、ＬＵＮ（論理ユニット番号）と、ＳＣＳＩのポートＩＤといった情報を利用することができる。この場合、ＬＵＮやポートＩＤが仮想ボリュームテーブル６０００に登録されていてもよい。

仮想ボリューム１０５１の設定においては、仮想ボリューム設定プログラム１２３１が、プールＩＤ及び仮想容量を、設定のパラメータとしてストレージ１０００に指定する。ストレージ構成プログラム１０４２が、指定された仮想容量を有し指定されたプールＩＤから識別されるプールが対応付けられた仮想ボリュームを設定する。プールＩＤ及び仮想容量（パラメータ）は、ユーザが指定し設定することに代えて、ストレージ１０００で自動的に設定しても良い。

なお、図６に示したテーブル５０００には、プールＰ１が対応付けられた仮想ボリュームに関する情報しか記載されていないが、実際にはプールＰ２に対応付けられた仮想ボリュームやプールＰ３に対応付けられた仮想ボリュームに関する情報も登録されることになる。

図７は、プール割当テーブル７０００を示す。

プール割当テーブル７０００は、プール毎に、下記の情報要素：
プール１０６０の識別子を示すプールＩＤ７０１０；
プール１０６０が有するプールボリューム１０５２の識別子を示すプールボリュームＩＤ７０２０；
物理領域であるチャンクの識別子を示すチャンクＩＤ７０３０；
そのチャンクが占めるＬＢＡ（Logical Block Address）の範囲を表す割当ＬＢＡ７０４０；
そのチャンクが割り当てられているか否かの状況を示す割当状態７０５０；
を有する。

割当状態７０５０の値としては、例えば、割当て済みを意味する「割当」と、未割当てを意味する「未割当」とがある。値が「割当」の場合、割当先の仮想ボリュームのＩＤも、その値に含まれる。例えば、このテーブル７０００によれば、チャンクＩＤ「Ｃ１１」のチャンクは、プールＰ１内のプールボリュームＶ１００の先頭から０ＧＢ目のアドレスを基点とし先頭から２ＧＢ目のアドレスを終点とする２Ｇバイトの物理領域であり、仮想ボリュームＶ１に割当済みであることがわかる。

プールについての全体容量５０２０は、そのプールが有するチャンクの総記憶容量であり、プールについての割当容量５０３０は、そのプール１０６０からの割当て済みのチャンクの総記憶容量である。

なお、このテーブル７０００には、プールＰ１の一部のチャンクのみ記載されているが、実際には、全てのプールの全てのチャンクについても同様に管理される。

図８は、プールボリュームテーブル８０００を示す。

プールボリュームテーブル８０００は、プールボリューム毎に、下記の情報要素：
プールボリュームの１０５２識別子を示すプールボリュームＩＤ８０１０；
プールボリューム１０５２の基になっているＲＡＩＤグループ１０８０の識別子を示すＲＡＩＤグループＩＤ８０２０；
プールボリューム１０５２の容量を示す容量８０３０；
プールボリューム１０５２から仮想ボリュームに割当て済みのチャンクの総記憶容量を示す割当容量８０４０；
を有する。

図９は、仮想ボリューム割当テーブル９０００を示す。

仮想ボリューム割当テーブル９０００は、仮想ボリューム毎に、下記の情報要素：
仮想ボリューム１０５１の識別子を示す仮想ボリュームＩＤ９０１０；
仮想ボリューム１０５１に対応付けられているプール１０６０の識別子を示すプールＩＤ９０２０；
割当てられているチャンクの識別子を示すチャンクＩＤ９０３０；
仮想ボリューム１０５１が有する複数のアドレス範囲のうちチャンクが割り当てられているアドレス範囲を示す割当ＬＢＡ９０４０；
を有する。

このテーブル９０００によれば、仮想ボリュームＶ２が有する複数のアドレス範囲のうちの、先頭から２Ｇバイト目のアドレスを基点とし先頭から４ＧＢ目のアドレスを終点とする２Ｇバイトのアドレス範囲に、チャンクＣ１３が割り当てられている。

なお、このテーブル９０００には、仮想ボリュームＶ１及びＶ２の一部のアドレス範囲についてのみ情報が記載されているが、他のアドレス範囲についても同様に管理される。

ここで、本実施形態において実行される仮想ボリュームへのホストからのＩ／Ｏ処理について説明する。

最初に、仮想ボリューム１０５１に対するライト要求を受信したストレージ１０００が実行する処理について説明する。

仮想ボリューム１０５１に対してライト要求がまだ一度も実行されていない場合、その仮想ボリューム１０５１には、チャンクが全く割り当てられていない。ただし、何らかの理由によって、仮想ボリューム１０５１の一部のアドレス範囲に最初からチャンクが割り当てられていてもよい。

コントローラ１０２０は、仮想ボリューム１０５１のアドレス範囲を指定したライト要求を受信する。コントローラ１０２０は、指定されたアドレス範囲に、チャンクが割り当てられているか否かを確認する。チャンクが割り当てられている場合、コントローラ１０２０は、割り当てられたチャンクにライト対象のデータを格納する。

一方、指定されたアドレス範囲にチャンクが割り当てられていない場合、コントローラ１０２０は、指定されたアドレス範囲に、仮想ボリューム１０５１のいずれのアドレス範囲にも割り当てられていないチャンク（未割当てのチャンク）を割り当て、そのチャンクにデータを格納する。さらに、コントローラ１０２０は、その新たな割り当てを基にストレージ構成情報（プールテーブル８０００等）を更新する。

次に、仮想ボリューム１０５１に対するリード要求を受信したストレージ１０００が実行する処理について説明する。

コントローラ１０２０は、仮想ボリューム１０５１のアドレス範囲を指定したリード要求を受信する。コントローラ１０２０は、指定されたアドレス範囲に、プール１０６０のチャンクが割り当てられているか否かを確認する。チャンクが割り当てられている場合、コントローラ１０２０は、割り当てられたチャンクからデータを読み出し、ホスト１１００に返す。

一方、指定されたアドレス範囲にチャンクが割り当てられていない場合、コントローラ１０２０は、指定されたアドレス範囲のデータ量に相当する所定のデータ（例えば「０」）をホスト１１００に返す。

図１０は、ストレージ識別テーブル１００００を示す。

ストレージ識別テーブル１００００は、ストレージ１０００の識別子となるストレージＩＤ１００１０と、管理計算機１２００が管理ネットワーク１４００を介してストレージ１０００にアクセスするために利用する情報であるＩＰアドレス１００２０とを有する。複数のＩＰアドレス１００２０が登録されていてもよい。

以上が、ストレージ構成情報１０４２についての説明である。

次に、管理計算機１２００が有するプール管理情報１２３５を説明する。

プール管理情報１２３５は、下記テーブル：
図１１に示すプール設定テーブル１１０００；
図１２に示すプール容量増加判定テーブル１２０００；
図１３に示すプール用途テーブル１３０００；
を有する。以下、これらのテーブルについて説明する。

図１１は、プール設定テーブル１１０００を示す。このテーブル１１０００は、管理計算機１２００に事前に設定されていても良いし、ユーザが適宜に設定したり変更したりしても良い。

プール設定テーブル１１０００は、プール用途毎に、下記の情報要素：
プールの用途を示すプール用途１１０１０；
プール用途に関する条件を示す詳細１１０２０；
１つのプールボリュームのサイズを示す一ボリュームサイズ１１０３０；
プールの全体容量に対する使用容量の割合の閾値を示す閾値１１０４０；
を有する。

プール用途１１０１０の値としては、Ｉ／Ｏ性能（仮想ボリュームに対するＩ／Ｏの性能）が高いことをビットコスト（ビットあたりのコスト）が低いことよりも優先することを意味する「性能重視」と、ビットコストが低いことをＩ／Ｏ性能が高いことよりも優先することを意味する「コスト重視」と、複数種類のプールボリュームが混在することを意味する「階層構成重視」とがある。

プール用途についての条件は、プールの基になっているＲＡＩＤグループが一つであるか複数であるか、及び／又は、プールボリュームの種類に基づいている。具体的には、例えば、このテーブル１１０００によれば、下記の（１）〜（３）の定義：
（１）プール用途「性能重視」に対応したプールは、複数のプールボリュームが別々のＲＡＩＤグループに基づいていて、全てのプールボリュームがＦＣ（Fibre Channel）プールボリュームであり、各ＦＣプールボリュームが５０Ｇバイトであること；
（２）プール用途「コスト重視」に対応したプールは、複数のプールボリュームが単一のＲＡＩＤグループに基づいていて、全てのプールボリュームがＳＡＴＡ（Serial ATA（Advanced Technology Attachment））プールボリュームであり、各ＳＡＴＡプールボリュームが５０Ｇバイトであること；
（３）プール用途「階層構成重視」に対応したプールは、ＦＣプールボリュームとＳＡＴＡプールボリュームとが混在していること；
が設定されている。ここで、「ＦＣプールボリューム」とは、ＦＣのハードディスクで構成されたＲＡＩＤグループに基づく論理ボリュームである。「ＳＡＴＡプールボリューム」とは、ＳＡＴＡのハードディスクで構成されたＲＡＩＤグループに基づく論理ボリュームである。なお、ハードディスクの種類は、ＦＣやＳＡＴＡ等のインターフェイスの違いで異なっていることに代えて又は加えて、メーカ、ストレージ媒体などの他種の観点から異なっていても良い。

図１２は、プール容量増加判定テーブル１２０００を示す。

プール容量増加判定テーブル１２０００は、下記の情報要素：
プールの使用容量の増加傾向（以下、容量増加傾向）が低いかどうかの判定（以下、容量増加判定）の方法を示す容量増加判定１２０１０；
プールの余剰の記憶容量を算出する方法を示すプール削減可能容量１２０２０；
容量増加判定の対象となるための条件（具体的には、作成されてからどれだけの期間を経過したプールが容量増加判定の対象となるか）を示す対象期日１２０３０；
を有する。

図１２に示すテーブル１２０００の例によれば、容量増加判定の方法として、１か月で増加量が平均３％以上であることが基準となり、この増加量がない場合は、容量増加傾向が低いと判定されることになる。プールの容量増加傾向が低いと判定された場合、そのプールの余剰の記憶容量が算出されることになる。また、対象期日１２０３０は、「作成後６か月以上」であることを示している。より具体的な値を言えば、或るプールの容量が１Ｔバイト（テラバイト）であり、そのプールが作成されてから６か月で、そのプールの使用容量の増加量が１２０Ｇである場合、平均増加量は１か月で２０Ｇであり、２０Ｇは、増加分としては２％であることがわかる。この場合には、プールの使用容量の増加量が少ない、つまり、容量増加傾向が低いと判定されることになる。

図１３は、プール用途テーブル１３０００を示す。

プール用途テーブル１３０００は、プール毎に、下記の情報要素：
プールを有するストレージ１０００の識別子であるストレージＩＤ１３０１０；
プールの識別子であるプールＩＤ１３０２０；
プールの用途を示すプール用途１３０３０；
プールの作成日時を示す作成日時１３０４０；
を有する。

ストレージＩＤ１３０１０は、管理計算機１２００が認識しているストレージ１０００のＩＤであっても良い。この場合、プールがないストレージ１０００に関しては、プールＩＤ１３０２０、用途１３０３０及び作成日時１３０４０には無効値（例えば「−」（ハイフン））を登録し、プールがないストレージ１０００を認識しているという管理がされてもよい。また、ストレージ１０００にアクセスするためのＩＰアドレスなどの情報が必要な場合は、このテーブル１３０００に追加するか、別のテーブルで管理されてよい。ストレージＩＤ１３０１０はＩＰアドレスの場合は、このテーブル１３０００にＩＰアドレス用のカラムを追加する必要は無い。

図１４は、プール設定画面１４０００を示す。

この画面１４０００は、プール設定プログラム１２３２によってディスプレイ装置（入出力装置１２１０の一部）に表示される。この画面１４０００は、ユーザがプールを設定するための画面である。

この画面１４０００は、プールの全体容量を設定するための欄１４１００と、プール用途を設定するための欄１４１１０と、各用途を持つプールの数を設定するための欄１４１２０とを有する。また、この画面１４０００は、プール用途を追加したい場合に押されるボタン１４２００と、各欄に設定された条件をプール管理情報１２３５に適用するためのボタン１４３００と、この画面の設定をキャンセルする場合のボタン１４４００とを有する。

図１５は、容量レポート出力指示画面１５０００を示す。

この画面１５０００は、容量レポートプログラム１２３４によってディスプレイ装置に表示される。この画面１５０００は、ストレージ１０００の記憶容量に関するレポート（以下、容量レポート）の出力の指示をユーザが行なうための画面である。

この画面１５０００は、容量レポートの項目が表示される欄１５１００と、チェックボックスを有する欄１５１１０とを有する。ユーザは、所望の項目に対応したチェックボックスにチェックマークを入力する。なお、項目「ストレージ」は、ストレージ単位で記憶容量がレポートされることを意味し、項目「ＲＡＩＤグループ」は、ＲＡＩＤグループ単位で記憶容量がレポートされることを意味する。容量レポートの項目として、ストレージ及び／又はＲＡＩＤグループに代えて又は加えて、ストレージＩＤ及び／又はＲＡＩＤグループＩＤがあっても良い。つまり、全てのストレージや全てのＲＡＩＤグループについての容量レポートではなく、ユーザ所望のストレージ又はＲＡＩＤグループについての容量レポートがされても良い。

また、この画面１５０００は、各欄に設定された条件を管理計算機１２００に適用するためのボタン１５３００と、設定をキャンセルするためのボタン１５４００とを有する。

図１６は、容量レポート画面１６０００を示す。

この画面１６０００は、容量レポートプログラム１２３４によってディスプレイ装置に表示される。この画面１６０００は、図１５で選択された各項目についての容量レポートを表示する画面である。

例えば、図１５の画面１５０００で項目「ストレージ」が選択された場合は、ストレージ容量レポート１６１００が表示され、項目「ＲＡＩＤグループ」を選択された場合は、ＲＡＩＤグループ容量レポート１６２００が表示される。そして、項目「ストレージ」と「ＲＡＩＤグループ」の両方が選択された場合は、ストレージ容量レポート１６１００とＲＡＩＤグループ容量レポート１６２００との両方が表示されることになる。

ストレージ容量レポート１６１００は、管理計算機１２００がアクセス可能なストレージ毎に、下記の情報要素：
ストレージの識別子であるストレージＩＤ１６１１０；
ストレージの全体容量を示す全体容量１６１２０；
ストレージで既に論理ボリュームとして定義されている容量を示す使用容量１６１３０；
ストレージで次に使用容量として使用可能な容量を示す未使用容量１６１４０；
を有する。

ＲＡＩＤグループ容量レポート１６２００は、ＲＡＩＤグループ毎に、下記の情報要素：
ストレージの識別子であるストレージＩＤ１６２１０；
ＲＡＩＤグループの識別子を表示するＲＡＩＤグループＩＤ１６２２０；
ＲＡＩＤグループの全体容量を示す全体容量１６２３０；
ＲＡＩＤグループですでに論理ボリュームとして定義されている容量を示す使用容量１６２４０；
ＲＡＩＤグループで次に使用容量として使用可能な容量を示す未使用容量１６２５０；
を有する。

この画面１６０００から、複数のストレージ（及び複数のＲＡＩＤグループ）の未使用容量を一元的に把握することができる。例えば、ユーザは、この画面１６０００に表示されている容量レポートを、ボリューム（例えば、プールボリューム、或いは、アーカイブ等で容量増加を特に考えない通常ボリューム）の作成のための情報として利用することができる。また、各時点で取得された容量レポートを履歴として保存しておくことで、未使用容量（及び使用容量）の傾向を把握し、種々のことに役立てることが期待できる。

図１７は、プール作成処理のフローチャートである。

プール設定プログラム１２３２は、プール設定要求を、プール設定画面１４０００（図１４参照）を介してユーザから受ける（ステップ１７０００）。その画面１４０００に限らず、コマンドラインやファイルなどの他の形式で受けても良い。

次に、プール設定プログラム１２３２は、その画面１４０００で設定されたプール用途に応じたプールを設定できるか否かを判定する（ステップ１７０１０）。ステップ１７０１０での判定の結果が肯定的であれば、ステップ１７０２０が行われ、ステップ１７０１０での判定の結果が否定的であれば、ステップ１７０３０が行われる。

この判定は、プール設定画面１４０００に入力された情報と、プール設定テーブル１１０００（図１１参照）とを基に行われる。

例えば、図１４の例によれば、二つのプールの設定要求があり、第一のプールは、プール用途が「性能重視」で、全体容量が「１００Ｇ」のプールである。この場合、図１１の例に従えば、「性能重視」の場合、「複数のＲＡＩＤグループに分散／ＦＣ」とあり、また一つのプールボリュームのサイズは「５０Ｇ」であることがわかる。よって、第一のプールは、図１４の例で示した容量が１００Ｇであるので、ＦＣのハードディスクで構成された２つのＲＡＩＤグループで各５０Ｇのボリュームで構成すべきことがわかる。

そして、対象となるＲＡＩＤグループがあるか調べることになる。図４のＲＡＩＤグループテーブル４０００の例によれば、ＲＡＩＤグループＲＧ１及びＲＧ２のそれぞれについて、ハードディスクがＦＣで、未使用容量（２００Ｇ、１５０Ｇ）が５０Ｇ以上なので、各５０Ｇ分のボリュームの作成が可能であることがわかる。よって、要求された第一のプールの設定が可能であることがわかる。よって、第一のプールについては、ステップ１７０２０が行われることになる。

一方、図１４の例において、二つのプールのうちの第二のプールは、プール用途が「コスト重視」であり、全体容量が「１００Ｇ」のプールであることがわかる。この場合、図１１の例によれば、コスト重視の場合、「ＲＡＩＤグループに集中／ＳＡＴＡ」とあり、また、一プールボリュームのサイズは「５０Ｇ」であることがわかる。よって、第二のプールは、図１４の例によれば、指定された全体容量が「１００Ｇ」であるので、ＳＡＴＡのハードディスクで構成された一つのＲＡＩＤグループに基づく２つの５０Ｇのボリュームで構成すべきことがわかる。

そして、対象となるＲＡＩＤグループがあるか調べることになる。図４のＲＡＩＤグループテーブル４０００の例によれば、ＲＡＩＤグループＲＧ３を構成するハードディスクがＳＡＴＡで、また、未使用容量（１５０Ｇ）が１００Ｇ以上なので、２つの５０Ｇのボリュームを作成可能であることがわかる。よって、図１４のコスト重視のプールの設定要求は対応できることがわかる。よって、第二のプールについても、ステップ１７０２０が行われることになる。

また、例えば、図１４において、「コスト重視」に対応したプールの全体容量が「１Ｔ」の場合には、上記のような判定処理をプール設定プログラム１２３２が行うことにより、ＳＡＴＡのＲＡＩＤグループＲＧ３からは１Ｔの容量を確保できないことがわかる。未使用容量が１５０Ｇと１Ｔに足りないからである。この場合には、「コスト重視」及び「１Ｔ」に対応したプールについては、ステップ１７０３０が行われることになる。

ステップ１７０２０では、プール設定プログラム１２３２は、作成されたボリュームでプールを作成する。具体的には、例えば、プール設定プログラム１２３２は、ＲＡＩＤグループから必要分のボリュームを作成し、そしてそのボリュームで構成されたプールを作成する。より具体的には、例えば、ステップ１７０１０の例に従えば、「性能重視」に対応した第一のプールについて、ＲＡＩＤグループＲＧ１及びＲＧ２からそれぞれ５０Ｇのボリュームを作成し、プールのＩＤを生成し、そのプールＩＤをプールに割り振り、そして、このプールに、上記作成した２つの５０Ｇのボリュームを登録することで、第一のプールを作成することになる。通常ボリューム設定プログラム１２３３が通常ボリュームの作成指示をストレージ１０００に行なうことで、２つの５０Ｇのボリュームがそれぞれ作成される。

これにより、プールの作成が完了となる。

一方、ステップ１７０２３では、プール設定プログラム１２３２は、エラー表示を行なう。ステップ１７０１０の例に従えば、図１４の「コスト重視」のプールについて全体容量「１Ｔ」が指定された場合には、未使用容量が１Ｔ未満のため、このステップ１７０２３が行われることになる。この場合、プール設定プログラム１２３２は、プールを作成できないという結果と共に、エラーの原因（例えば、未使用容量が不足していること）も表示することができる。

図１８は、容量レポート表示処理のフローチャートである。

容量レポートプログラム１２３４は、図１５に示した画面１５０００を介して、容量レポートの表示要求をユーザから受ける（ステップ１８０００）。その画面１５０００に限らず、コマンドラインやファイルなどの他の形式で受けても良い。

容量レポートプログラム１２３４は、容量増加判定の対象となるプール（以下、判定対象プール）があるか否かを判定する（ステップ１８０１０）。この判定の結果が肯定的であれば、ステップ１８０２０が行われ、この判定の結果が否定的であれば、ステップ１８０２０以降が行われることなくステップ１８０５０が行われる。

ここでは、図１２のテーブル１２０００における対象期日１２０３０と、図１３のテーブル１３０００における作成日時１３０４０とを基に、判定対象プールの有無が判定される。

図１２及び図１３の例に従えば、対象期日１２０３０は「作成後６ヶ月以上」であるため、容量レポートプログラム１２３４は、プールＰ１〜Ｐ４のうちプールＰ１、Ｐ２及びＰ３が判定対象プールであることを検出する。このため、ステップ１８０２０が行われる。

容量レポートプログラム１２３４は、余剰の記憶容量を有する判定対象プールがあるか否かを判定する（ステップ１８０２０）。この判定の結果が肯定的であれば、ステップ１８０３０が行われ、この判定の結果が否定的であれば、ステップ１８０３０以降が行われることなくステップ１８０５０が行われる。

ここでは、判定対象プールについて、図１２のテーブル１２０００における容量増加判定１２０１０と、図５のテーブル５０００における全体容量５０２０及び割当容量５０３０とを基に、余剰の記憶容量を有する判定対象プールがあるか否かが判定される。

図１２及び図５の例に従えば、容量増加判定１２０１０は「１ヶ月増分３％」となっているので、プールの全体容量５０２０が「１００Ｇ」であれば、１００Ｇの３％である３Ｇの増加量があると定義されている。言い換えると、７か月であれば２１Ｇ、８か月であれば２４Ｇ、９か月であれば２７Ｇの増加量があることになる。プールの使用容量の増加量が、それらの増加量未満であれば、余剰の記憶容量が判定対象プールにある判定される。判定対象プールＰ１、Ｐ２及びＰ３のうち、余剰の記憶容量があるプールは、割当容量が２１Ｇ（７か月）よりも少ないプールＰ１と、割当容量が２４Ｇ（８か月）よりも少ないプールＰ２となり、割当容量が２７Ｇ（９か月）以上であるプールＰ３は、余剰の記憶容量が無いプールである。余剰の記憶容量あるプールＰ１及びＰ２については、ステップ１８０３０が行われ、余剰の記憶容量が無いプールＰ３については、ステップ１８０３０は行われない。

また、ステップ１８０２０の処理において、閾値５０４０を越える割当容量となっている判定対象プールについては、余剰の記憶容量が無いプールと判定されて良い。

容量レポートプログラム１２３４は、余剰の記憶容量があると判定された判定対象プールについて、プール用途を満たしつつプールボリュームが削除可能なプールがあるか否かを判定する（ステップ１８０３０）。この判定の結果が肯定的であれば、ステップ１８０４０が行われ、この判定の結果が否定的であれば、ステップ１８０４０以降が行われることなくステップ１８０５０が行われる。

ここでは、図１１のテーブル１１０００と、図１２のテーブル１２０００と、図１３のテーブル１３０００と、図８のテーブル８０００とに基づいて、プール用途を満たしつつプールボリュームが削除可能なプールがあるか否かが判定される。

図１１、図１３、図８の例に従えば、プールＰ１は、図１３から「性能重視」であることがわかる。そして、「性能重視」のプールは、図１１から、複数のＲＡＩＤグループに分散する条件がある。また、図８から、プールＰ１は、別々のＲＡＩＤグループに基づく２つのプールボリュームで構成されていることがわかる。

よって、プールＰ１の場合、どちらか一方のプールボリュームを削除すると、プールボリュームは１つになってしまい、「性能重視」に対応した条件を満たせない。このため、プールＰ１については、プール用途を満たしつつプールボリュームが削除可能なプールではないと判定される。

一方、図１１、図１３、図８の例に従えば、プールＰ２は「コスト重視」であることがわかる。そして、「コスト重視」のプールは、図１１から、ＲＡＩＤグループに集中する条件がある。また、図８から、プールＰ２は、１つのＲＡＩＤグループに基づく２つのプールボリュームで構成されていることがわかる。

よって、プールＰ２の場合、どちらか一方のプールボリュームを削除しても、一つのＲＡＩＤグループであることは変わらないので、「コスト重視」に対応した条件を満たせることがわかる。

そして、プール用途についての条件が満たされると判断した場合には、容量レポートプログラム１２３４は、プール削減可能容量１２０２０が示す方法で、余剰の記憶容量を算出する。プールＰ２の場合には、全体容量「１００Ｇ」及び割当容量「２０Ｇ」であるので、プール削減可能容量１２０２０で示す式を計算することにより、余剰の記憶容量「５６Ｇ」が算出される。プールＰ２は、５０Ｇの２つのボリュームで構成されているため、１つのボリュームを削除しても、余剰の記憶容量「５６Ｇ」を超えない。このため、容量レポートプログラム１２３４は、プールＰ２から１つのボリュームを削除しても良いと判断する。

また、仮に、プールＰ１が３つのプールボリュームを有し、それら３つのプールボリュームのうちの２つが、ＲＡＩＤグループＲＧ１に基づくプールボリュームであり（１つのボリュームの容量は５０Ｇ）、残りの１つが、ＲＡＩＤグループＲＧ２に基づくプールボリューム（１つのボリュームの容量は５０Ｇ）であり、プールの割当容量が変わらなければ（すなわち２０Ｇであれば）、プールＰ２と同じく、プールＰ１から１つのプールボリュームを削減することが可能である。１つのプールボリュームをプールＰ１から削除しても、プール用途「性能重視」についての条件は満たされているし、そのプールボリュームの容量は余剰の記憶容量以下だからである。

ステップ１８０４０で、容量レポートプログラム１２３４は、プールから削除可能なボリューム容量（つまり、算出された余剰の記憶容量以下の容量）を、未使用容量として定義する。

上記の例に従えば、プールＰ２から１つのプールボリュームを削除可能なことがわかる。図８の例に従えば、プールＰ２が２つの５０ＧのプールボリュームＶ１０２及びＶ１０４で構成されており、そのうちの１つを削除可能なプールボリュームとして扱うことが可能である。そして、このボリュームは、ＲＡＩＤグループＲＧ３に基づくボリュームであることがわかる。

なお、削除するボリュームをどれにするかによって、負荷に差が出ることがある。例えば、割当容量が少ないプールボリュームの方が、割当容量が多いプールボリュームよりも、ボリューム削除に要する処理にかかる時間が短くて済むと考えられる。なぜなら、削除されるプールボリューム内の割当て済みのチャンクに記憶されているデータを、削除されないプールボリュームにコピーするにあたり、コピーするデータの量が少ないからである。この場合、容量レポートプログラム１２３４は、割当容量の少ないボリュームを優先的に削除する。

容量レポートプログラム１２３４は、容量レポート画面１６０００（図１６参照）を表示する（ステップ１８０５０）。容量レポートは、例えば、ステップ１８０１０〜１８０４０での処理の結果に基づくレポートである。

容量レポート画面１６０００に表示される未使用容量１６１４０及び１６２５０は、ＲＡＩＤグループについての未使用容量４０４０に、ステップ１８０４０で定義された未使用容量が加算された容量に基づいている。従って、容量レポート画面１６０００に表示される使用容量１６１３０及び１６２４０は、ＲＡＩＤグループについての使用容量４０３０に、ステップ１８０４０で定義された未使用容量が減算された容量に基づいている。

上記の例に従えば、ストレージ１のＲＡＩＤグループにおいて、ＲＡＩＤグループＲＧ１及びＲＧ２は、それぞれ、削除対象のプールボリュームをもたないので、未使用容量は変更がない。ただし、ＲＡＩＤグループＲＧ３については、１つの５０Ｇのプールボリュームが削除対象となる（つまり削除容量が「５０Ｇ」である）。このため、容量レポート画面１６０００には、ＲＡＩＤグループＲＧ３については、未使用容量４０４０が示す「１５０Ｇ」に削除容量「５０Ｇ」が加算された値「２００Ｇ」が、未使用容量１６２５０として表示されることになる。また、使用容量１６２４０としては、ＲＡＩＤグループＲＧ３の使用容量４０３０が示す「１５０Ｇ」から削除容量「５０Ｇ」が減算された値「１００Ｇ」が表示されることになる。

以上の実施形態によれば、プールの余剰の記憶容量だけでなく、複数のストレージ１０００の複数のＲＡＩＤグループについての未使用容量が把握される。そして、余剰の記憶容量以下の容量が未使用容量と定義され、その定義された未使用容量が反映された、ストレージ全体の未使用容量（ＲＡＩＤグループの未使用容量から特定される容量）や、ＲＡＩＤグループの未使用容量が、複数のストレージ（及び複数のＲＡＩＤグループ）について表示される。

なお、本実施形態は、仮想ボリュームに対するデータを格納するプールに代えて又は加えて、他種のプール（例えば、コピー元のボリュームの差分情報やジャーナル情報を格納するプール）が採用されても良い。すなわち、ボリュームの差分情報を格納するプールや、ボリュームのジャーナル情報を格納するプールも、１以上の実ボリュームの集合によって実現される。このため、本実施形態をそれらのプールに適用することが可能である。

また、プール削減可能容量１２０２０で定義される算出方法は、他の方法、例えば、
容量増加傾向を把握し；
或る期間（例えば６ヵ月後）の増加量を予測し；
その増加量以外を余剰の記憶容量とする；
方法が採用されても良い。例えば、プールの容量が１Ｔ、レポート時点の割当容量が２００Ｇ、容量増加傾向は１ヶ月当り２０Ｇとなっている場合、１年後には、２４０Ｇの増加が予測される。このため、１年後には、２００＋２４０＝４４０Ｇの割当容量と予測される。よって、この時点の未使用容量５６０Ｇ（１Ｔ−４４０Ｇ）が、余剰の記憶容量とされても良い。実際には、プール設定テーブル１１０００の一ボリュームサイズ１１０３０が５０Ｇであることから、５０の倍数である５５０Ｇが削減できる容量とされる。

また、プール設定テーブル１１０００の一ボリュームサイズ１１０３０の設定が「５０Ｇ以下」であるなど、図１１の例の固定値ではなく可変である場合には、プールボリュームの入れ替えによる対応が考慮されても良い。

また、例えば、図１８の例から、ステップ１８０３０では、プールＰ１は、「性能重視」のため、プールボリュームの削除が可能と判定されなかった。しかし、「性能重視」の構成でなければ、余剰の記憶容量「５６Ｇ」を削減でき、プールＰ１としては４４Ｇの全体容量があればよいと判定される。よって、例えば、ＣＰＵ１２２０は、
ＲＡＩＤグループＲＧ１を基に２２Ｇのボリューム（Ｖ１０００）を作成し、ＲＡＩＤグループＲＧ２に基づいて２２Ｇのボリューム(Ｖ２０００)を作成し、それらを一旦プールＰ１に設定する；
プールＰ１を構成していたボリュームＶ１００、Ｖ１０１を削除する；
削除するボリュームＶ１００及びＶ１０１内の割当て済みチャンクに記憶されているデータを、ボリュームＶ１０００及びＶ２０００にコピーする；
を行う。それにより、プールの用途を満たしつつ、プールＰ１のプールボリュームを再構成することで、容量削減可能であることを判定する。この場合には、ステップ１８０４０で、ＲＡＩＤグループＲＧ１に２８Ｇの未使用容量、ＲＡＩＤグループＲＧ２に２８Ｇの未使用容量ができるものと判定され、ステップ１８０５０で、容量レポート表示がされることになる。

ただし、入れ替えのためのボリュームの容量を確保しなければならないので、入れ替えのためのボリュームの容量を確保できるか判定する必要がある。確保ができなければ、図１８に示した処理が行われても良い。

また、上記プールボリュームの入れ替えにより対応したが、それに代えて、同様の効果が、プール間のデータ移行で得られることが期待できる。

具体的には、例えば、図１４のプール設定画面１４０００を介して、用途が「性能重視」、容量が「４４Ｇ」、個数が「１」というプール設定が行われたとする。そして、ここで作成されたプールをＰ１００とする。そして、プール設定プログラム１２３２は、プールＰ１に対応付けられた仮想ボリューム（図６の例によれば、仮想ボリュームＶ１及びＶ２で、それぞれが仮想容量「１Ｔ」である）の仮想容量と同じ仮想ボリュームを、プールＰ１００に対応付ける（この場合、仮想容量１Ｔの仮想ボリュームが２つ設定される）。そして、プール設定プログラム１２３２は、プールＰ１に関連づいた仮想ボリュームとプールＰ１００に関連づいた仮想ボリュームとの間でデータ移行を行なう。そして、移行元のプールＰ１が削除される。

また、プールボリュームの入れ替え、プール間のデータ移行は、ホスト側の用途が変わった場合にも対応可能である。例えば、第一の用途（例えば「性能重視」の用途）から第二の用途（例えば「コスト重視」の用途）にホストによる使用の用途が変わった場合に、プール内のプールボリュームを第一の用途のプールボリュームと第二の用途のプールボリュームとを入れ替える、又は、第一の用途のプールから第二の用途のプールへデータ移行することで、ホスト側のアクセス方には影響なく構成変更が可能となる。

また、管理計算機１２００は、容量レポートを表示することなく、未使用容量（ＲＡＩＤグループの未使用容量に、余剰の記憶容量以下の容量が反映された容量）を基に、ボリュームを削除する、或いは、ボリュームを作成しても良い。

以下、本発明の第二の実施形態を説明する。その際、第一の実施形態との相違点を主に説明し、第一の実施形態との説明は省略或いは省略化する。

図１９は、容量レポート画面２６０００を示す。

この画面２６０００は、図１６に示した画面１６０００の拡張である。具体的には、ストレージ容量レポート１６１００が、「プールから削除する容量」１９０００を有し、ＲＡＩＤグループ容量レポート１６２００が、「プールから削除する容量」１９１００を有する。

「プールから削除する容量」は、図１８で示した削除可能なプールボリュームの容量のことである。つまり、未使用容量１６１４０又は１６２５０のうちの、削除可能なプールボリュームの容量である。

図１８の例に従えば、プールから削除する容量１９０００が５０Ｇとなり、ストレージＩＤ１のストレージには、全ＲＡＩＤグループの未使用容量は、６００Ｇから５０Ｇを引いた５５０Ｇであることを示している。

また、図１８の例に従えば、プールから削除する容量１９１００が５０Ｇなので、ＲＧ３のＲＡＩＤグループの未使用容量は、２５０Ｇから５０Ｇを引いた２００Ｇであることを示している。

またプールボリュームの入れ替え、プール間のデータ移行についても、それぞれの処理によって、削除できる容量を、この容量レポートで示しても良い。

図１８の例に従えば、プールボリュームの入れ替え、プール間のデータ移行、ともにＲＧ１では、５６Ｇ削減可能であることを示しているので、容量レポートが、「プールボリュームの入れ替えで削除する容量」、及び／又は、「プール間のデータ移行で削除する容量」を有する。これらのケースでは、ボリュームが新規に作成される等の再構成が行われるため、「プールボリュームの入れ替えで削除する容量」、及び／又は、「プール間のデータ移行で削除する容量」は、算出された余剰の記憶容量と同じ容量で良い。

「プールから削除する容量」、「プールボリュームの入れ替えで削除する容量」及び「プール間のデータ移行で削除する容量」のうちの二以上の情報要素が表示される場合、使用容量及び未使用容量の計算が、どの種の情報要素を用いて表示するか決める必要がある。このため、例えば、使用容量及び未使用容量は、ＲＡＩＤグループについてのみ表示し、実際の未使用容量は、「プールから削除する容量」、「プールボリュームの入れ替えで削除する容量」及び「プール間のデータ移行で削除する容量」のいずれかの情報要素を基に定義された容量で良い。また、未使用容量の欄に「プールから削除する容量」、「プールボリュームの入れ替えで削除する容量」及び「プール間のデータ移行で削除する容量」のいずれの情報要素を適用したかが示されても良い。

また、図１６と図１９のどちらの容量レポート画面を表示するかが、ＧＵＩ（Graphical User Interface）やプロパティファイルなどでユーザが選択できるようにしてもよい。

また「プールから削除する容量」、「プールボリュームの入れ替えで削除する容量」、「プール間のデータ移行で削除する容量」をそれぞれ適用するときに、実際にボリューム容量が必要になった場合に、容量を提供できる時間をレポートに表示しても良い。プールボリュームの削除が１Ｇあたり１分、プールボリュームの入れ替えが１Ｇあたり２分、プール間のデータ移行が１Ｇあたり３分、といった情報を予め測定などして、管理計算機１２００またはストレージ１０００で管理し、レポート提供時に、各欄の付加情報として表示してもよい。

１０００…ストレージ、１１００…ホスト、１２００…管理計算機

Claims (12)

1. 外部装置からアクセスされるストレージ装置に接続された管理計算機であって、
   前記ストレージ装置は、ＲＡＩＤ（Redundant Array of Independent (or Inexpensive) Disks）グループに基づく実ボリュームを１つ以上有するプールを管理しており、
   前記管理計算機が、
   記憶資源と、
   前記記憶資源に接続されているプロセッサと
   を備え、
   前記記憶資源は、プール管理情報を記憶し、
   前記プール管理情報は、前記プールについてのプール用途を表すプール用途情報と、プール用途についての構成条件を表す構成条件情報と、プール用途についての容量条件の情報を表す容量条件情報とを含み、
   前記プロセッサは、以下の（Ａ）及び（Ｂ）の処理、
   （Ａ）前記プール管理情報を基に、前記プールについてのプール用途を特定し、前記プールから記憶領域を削減しても前記特定したプール用途についての構成条件を満たすか否かと、且つ、前記プールについてのプール使用状況を基に余剰の記憶容量を算出し、前記算出された余剰の記憶容量以下の容量の記憶領域を前記プールから削除しても前記特定したプール用途についての容量条件を満たすか否かとを判定する；
   （Ｂ）前記（Ａ）での判定の結果が肯定的の場合に、前記余剰の記憶容量以下の記憶領域の容量を未使用容量と定義する；
   を実行する、
   管理計算機。
2. 複数のストレージ装置があり、
   各ストレージ装置が、少なくとも一つのＲＡＩＤ（Redundant Array of Independent (or Inexpensive) Disks）グループと、少なくとも一つのプールとを管理しており、
   各実ボリュームは、複数のストレージ媒体で構成されているＲＡＩＤグループに基づく論理ボリュームであり、
   各ストレージ装置が、ストレージ構成情報を管理し、
   前記ストレージ構成情報は、前記ＲＡＩＤグループに関するＲＡＩＤ情報と、前記プールに関するプール情報とを含み、
   前記ＲＡＩＤ情報は、どのＲＡＩＤグループがどの種のストレージ媒体で構成されているかを表すＲＡＩＤ構成情報を含み、
   前記プール情報は、どのプールに含まれているどの実ボリュームがどのＲＡＩＤグループに基づいているかを表すプール構成情報と、前記プールの使用状況を表すプール使用状況情報とを含み、
   前記ストレージ装置が、適時に前記プール使用状況情報を更新し、
   前記プール用途情報が、どのストレージ装置で管理されているどのプールがいつ作成されたかを表す情報を含み、
   前記プロセッサが、
   ユーザから記憶容量レポートの要求を受けて、以下の（Ｆ）及び（Ｇ）の処理、
   （Ｆ）前記プール用途情報を基に、作成されてから一定期間が経過したプールがあるか否かを判定する；
   （Ｇ）前記（Ｆ）での判定の結果が肯定的の場合、前記プール用途情報を基に、作成されてから一定期間が経過した各プールについて余剰があるか否かを判定する；
   を実行し、
   プールが作成されてから使用容量が所定のペースよりも低いペースで増加している場合に、そのプールについて、前記（Ｇ）での判定の結果が肯定的となり、
   前記処理（Ｇ）での判定の結果が肯定的の場合に、前記（Ａ）及び（Ｂ）を実行し、前記（Ａ）では、各プールについて、そのプールについての未使用容量を基に、余剰の記憶容量を算出し、
   前記（Ｂ）を終えた後に、以下の（Ｈ）の処理、
   （Ｈ）各ストレージ装置についての未使用容量を表す情報を含んだ記憶容量レポートを出力する；
   を実行し、
   前記記憶容量レポートに表されている、各ストレージ装置についての未使用容量は、ＲＡＩＤグループについての未使用容量と、前記（Ｂ）において未使用容量とみなされた余剰の記憶容量以下の実ボリュームの容量との合計に基づく容量である、
   請求項１記載の管理計算機。
3. 前記ＲＡＩＤ情報は、各ＲＡＩＤグループの使用状況を表すＲＡＩＤ使用状況情報を含み、
   前記ＲＡＩＤ使用状況情報は、各ＲＡＩＤグループについての記憶容量とそのうちの未使用容量とを表す情報を含み、
   前記プール使用状況情報が、各実ボリュームについての記憶容量とそのうちの未使用容量とを表す情報を含み、
   前記ストレージ装置が、前記ＲＡＩＤ使用状況情報及び前記プール使用状況情報を適時に更新し、
   前記プロセッサが、前記（Ｈ）において、各ＲＡＩＤグループについての未使用容量を表す情報も含んだ前記記憶容量レポートを出力し、
   前記記憶容量レポートに表されている、各ＲＡＩＤグループについての未使用容量は、前記ＲＡＩＤ使用状況情報を基に特定される未使用容量と、前記（Ｂ）において未使用容量とみなされた余剰の記憶容量以下の実ボリュームの容量との合計である、
   請求項２記載の管理計算機。
4. 複数のストレージ装置があり、
   各ストレージ装置が、少なくとも一つのＲＡＩＤ（Redundant Array of Independent (or Inexpensive) Disks）グループと、少なくとも一つのプールとを管理しており、
   各実ボリュームは、複数のストレージ媒体で構成されているＲＡＩＤグループに基づく論理ボリュームであり、
   各ストレージ装置が、ストレージ構成情報を管理し、
   前記ストレージ構成情報は、前記ＲＡＩＤグループに関するＲＡＩＤ情報と、前記プールに関するプール情報とを含み、
   前記ＲＡＩＤ情報は、どのＲＡＩＤグループがどの種のストレージ媒体で構成されているかを表すＲＡＩＤ構成情報と、各ＲＡＩＤグループの使用状況を表すＲＡＩＤ使用状況情報とを含み、
   前記ＲＡＩＤ使用状況情報は、各ＲＡＩＤグループについての記憶容量とそのうちの未使用容量とを表す情報を含み、
   前記プール情報は、どのプールに含まれているどの実ボリュームがどのＲＡＩＤグループに基づいているかを表すプール構成情報と、前記プールの使用状況を表すプール使用状況情報とを含み、
   前記プール使用状況情報が、各実ボリュームについての記憶容量とそのうちの未使用容量とを表す情報を含み、
   前記ストレージ装置が、前記ＲＡＩＤ使用状況情報及び前記プール使用状況情報を適時に更新し、
   前記プール用途情報が、どのストレージ装置で管理されているどのプールがいつ作成されたかを表す情報を含み、
   前記プロセッサが、
   ユーザから記憶容量レポートの要求を受けて、以下の（Ｆ）及び（Ｇ）の処理、
   （Ｆ）前記プール用途情報を基に、作成されてから一定期間が経過したプールがあるか否かを判定する；
   （Ｇ）前記（Ｆ）での判定の結果が肯定的の場合、前記プール用途情報を基に、作成されてから一定期間が経過した各プールについて余剰があるか否かを判定する；
   を実行し、
   プールが作成されてから使用容量が所定のペースよりも低いペースで増加している場合に、そのプールについて、前記（Ｇ）での判定の結果が肯定的となり、
   前記処理（Ｇ）での判定の結果が肯定的の場合に、前記（Ａ）及び（Ｂ）を実行し、前記（Ａ）では、各プールについて、そのプールについての未使用容量を基に、余剰の記憶容量を算出し、
   前記（Ｂ）を終えた後に、以下の（Ｈ）の処理、
   （Ｈ）各ＲＡＩＤグループについての未使用容量を表す情報を含んだ記憶容量レポートを出力する；
   を実行し、
   前記記憶容量レポートに表されている、各ＲＡＩＤグループについての未使用容量は、ＲＡＩＤグループについての未使用容量と、前記（Ｂ）において未使用容量とみなされた余剰の記憶容量以下の実ボリュームの容量との合計である、
   請求項１記載の管理計算機。
5. 複数のストレージ装置があり、
   各ストレージ装置が、少なくとも一つのＲＡＩＤ（Redundant Array of Independent (or Inexpensive) Disks）グループと、少なくとも一つのプールとを管理しており、
   各実ボリュームは、複数のストレージ媒体で構成されているＲＡＩＤグループに基づく論理ボリュームであり、
   各ストレージ装置が、ストレージ構成情報を管理し、
   前記ストレージ構成情報は、前記ＲＡＩＤグループに関するＲＡＩＤ情報と、前記プールに関するプール情報とを含み、
   前記ＲＡＩＤ情報は、どのＲＡＩＤグループがどの種のストレージ媒体で構成されているかを表すＲＡＩＤ構成情報と、各ＲＡＩＤグループの使用状況を表すＲＡＩＤ使用状況情報とを含み、
   前記ＲＡＩＤ使用状況情報は、各ＲＡＩＤグループについての記憶容量とそのうちの未使用容量とを表す情報を含み、
   前記プール情報は、どのプールに含まれているどの実ボリュームがどのＲＡＩＤグループに基づいているかを表すプール構成情報と、前記プールの使用状況を表すプール使用状況情報とを含み、
   前記プール使用状況情報が、各実ボリュームについての記憶容量とそのうちの未使用容量とを表す情報を含み、
   前記ストレージ装置が、前記ＲＡＩＤ使用状況情報及び前記プール使用状況情報を適時に更新し、
   前記プール用途情報が、どのストレージ装置で管理されているどのプールがいつ作成されたかを表す情報を含み、
   前記プロセッサが、
   ユーザから記憶容量レポートの要求を受けて、以下の（Ｆ）及び（Ｇ）の処理、
   （Ｆ）前記プール用途情報を基に、作成されてから一定期間が経過したプールがあるか否かを判定する；
   （Ｇ）前記（Ｆ）での判定の結果が肯定的の場合、前記プール用途情報を基に、作成されてから一定期間が経過した各プールについて余剰があるか否かを判定する；
   を実行し、
   プールが作成されてから使用容量が所定のペースよりも低いペースで増加している場合に、そのプールについて、前記（Ｇ）での判定の結果が肯定的となり、
   前記処理（Ｇ）での判定の結果が肯定的の場合に、前記（Ａ）及び（Ｂ）を実行し、前記（Ａ）では、各プールについて、そのプールについての未使用容量を基に、余剰の記憶容量を算出し、前記算出された余剰の記憶容量分の記憶領域を前記プールから削除しても前記特定された条件を満たすか否かを判定し、
   前記（Ｂ）を終えた後に、以下の（Ｈ）の処理、
   （Ｈ）各ＲＡＩＤグループについての未使用容量を表す情報を含んだ記憶容量レポートを出力する；
   を実行し、
   前記プロセッサは、以下の処理、
   ＲＡＩＤグループの未使用容量を基に実ボリュームを作成する；
   作成した実ボリュームに既存の実ボリューム内のデータをコピーする、又は、作成した実ボリュームを有するプールと既存のプールとの間のデータコピーを行う；
   コピー元の実ボリューム又はプールを削除する；
   を行うことで、構成変更を行い、
   前記記憶容量レポートに表されている、各ＲＡＩＤグループについての未使用容量は、ＲＡＩＤグループについての未使用容量と、前記（Ｂ）において未使用容量とみなされた余剰の記憶容量との合計である、
   請求項１記載の管理計算機。
6. 前記プロセッサが、所定のストレージ単位についての未使用容量を表す情報を含んだ記憶容量レポートを出力し、
   前記記憶容量レポートに表されている、各ストレージ単位についての未使用容量は、ＲＡＩＤグループの未使用容量と、前記（Ｂ）において未使用容量とみなされた余剰の記憶容量以下の容量との合計、或いはその合計に基づく容量である、
   請求項１記載の管理計算機。
7. 前記ストレージ単位は、ストレージ装置又はＲＡＩＤグループである、
   請求項６記載の管理計算機。
8. プール用途についての条件は、プールの基になっているＲＡＩＤグループが一つであるか複数であるか、及び／又は、実ボリュームの基になっているＲＡＩＤグループを構成するストレージ媒体の種類に基づいている、
   請求項１記載の管理計算機。
9. プール用途として、下記（ａ）乃至（ｃ）、
   （ａ）異なる複数のＲＡＩＤグループに基づく複数の実ボリュームを有することを条件とする第一のプール用途；
   （ｂ）単一のＲＡＩＤグループに基づく複数の実ボリュームを有することを条件とする第二のプール用途；
   （ｃ）異なる複数のＲＡＩＤグループに基づく複数の実ボリュームを有することを条件とする第三のプール用途；
   のうちの少なくとも二つがあり、
   前記（ａ）及び（ｂ）のプール用途におけるそれぞれのＲＡＩＤグループは、所定種類のストレージ媒体で構成されているＲＡＩＤグループであり、
   前記（ｃ）のプール用途における複数のＲＡＩＤグループには、第一種のストレージ媒体で構成されている第一種のＲＡＩＤグループと、第二種のストレージ媒体で構成されている第二種のＲＡＩＤグループとが含まれている、
   請求項８記載の管理計算機。
10. 前記プロセッサは、以下の処理、
    ＲＡＩＤグループの未使用容量を基に実ボリュームを作成する；
    作成した実ボリュームに既存の実ボリューム内のデータをコピーする、又は、作成した実ボリュームを有するプールと既存のプールとの間のデータコピーを行う；
    コピー元の実ボリューム又はプールを削除する；
    を行うことで、構成変更を行い、
    前記プロセッサが、所定のストレージ単位についての未使用容量を表す情報を含んだ記憶容量レポートを出力し、
    前記記憶容量レポートは、各未使用容量について、第一の削除可能容量及び第二の削除可能容量のうちの少なくとも一つを表す情報を含み、
    前記第一及び第二の削除可能容量は、前記余剰の記憶容量と同じ容量である、
    請求項１記載の管理計算機。
11. 外部装置からアクセスされるストレージ装置と、
    前記ストレージ装置に接続された管理計算機と
    を備え、
    前記ストレージ装置は、ＲＡＩＤグループに基づく実ボリュームを１つ以上有するプールを管理しており、
    前記管理計算機が、
    記憶資源と、
    前記記憶資源に接続されているプロセッサと
    を備え、
    前記記憶資源は、プール管理情報を記憶し、
    前記プール管理情報は、前記プールについてのプール用途を表すプール用途情報と、プール用途についての構成条件を表す構成条件情報と、プール用途についての容量条件の情報を表す容量条件情報とを含み、
    前記プロセッサは、以下の（Ａ）及び（Ｂ）の処理、
    （Ａ）前記プール管理情報を基に、前記プールについてのプール用途を特定し、前記プールから記憶領域を削減しても前記特定したプール用途についての構成条件を満たすか否かと、且つ、前記プールについてのプール使用状況を基に余剰の記憶容量を算出し、前記算出された余剰の記憶容量以下の容量の記憶領域を前記プールから削除しても前記特定したプール用途についての容量条件を満たすか否かを判定する；
    （Ｂ）前記（Ａ）での判定の結果が肯定的の場合に、前記余剰の記憶容量以下の容量を未使用容量と定義する；
    を実行する、
    計算機システム。
12. 外部装置からアクセスされるストレージ装置であって、ＲＡＩＤグループに基づく実ボリュームを１つ以上有するプールを管理しているストレージ装置を管理する方法であって、
    （Ａ）前記プールについてのプール用途を表すプール用途情報と、プール用途についての構成条件を表す構成条件情報と、プール用途についての容量条件の情報を表す容量条件情報とを含んだプール管理情報を基に、前記プールについてのプール用途を特定し、前記プールから記憶領域を削減しても前記特定したプール用途についての構成条件を満たすか否かと、且つ、前記プールについてのプール使用状況を基に余剰の記憶容量を算出し、前記算出された余剰の記憶容量以下の容量の記憶領域を前記プールから削除しても前記特定したプール用途についての容量条件を満たすか否かを判定し；
    （Ｂ）前記（Ａ）での判定の結果が肯定的の場合に、前記余剰の記憶容量以下の容量を未使用容量と定義する；
    管理方法。

Images