JPWO2017109931A1 - 計算機システム - Google Patents

Abstract

ストレージシステムは複数の記憶デバイスが提供する論理記憶領域を用いて、１以上の論理デバイスを有するＲＡＩＤグループを定義しており、論理デバイスはプールに所属させて管理する。ホストから仮想ボリューム上に対するデータライト要求を受け付けると、ストレージシステムはプール内の未使用の論理記憶領域を仮想ボリュームに割り当て、割り当てた論理記憶領域を有する記憶デバイスに対してデータを書き込む。データの書き込み要求を受け付けた記憶デバイスはデータを圧縮した後物理領域に格納し、圧縮データの格納された物理領域を前記論理記憶領域に対応付けて管理する。
計算機システムは、プールに所属する前記物理領域の物理使用量が所定の閾値を超過したとき、プールに所属する物理領域の量を増加させ、プールに所属する論理記憶領域の論理使用量が所定の閾値を超過したとき、プールに所属する前記論理記憶領域の量を増加させる。

Description

本発明は、計算機システムに関する。

ストレージシステムは、データを格納する複数の記憶デバイスと、記憶デバイスを制御するストレージコントローラとを有しており、ホスト計算機に大容量のデータ格納空間を提供することを目的としている。

ストレージシステムには、低コストで大量のデータを保存することが求められる。この要求を満たすための技術として、たとえば特許文献１に開示されているＴｈｉｎ Ｐｒｏｖｉｓｉｏｎｉｎｇという技術が知られている。Ｔｈｉｎ Ｐｒｏｖｉｓｉｏｎｉｎｇ技術を採用したストレージシステムは、仮想的なボリューム（仮想ボリューム）をホスト計算機に対して提供する。初期状態では仮想ボリュームの記憶空間には記憶領域が割り当てられていない。ストレージシステムはホスト計算機からライト要求を受け付けると、ライト要求を受け付けた領域に対して記憶領域を割り当てていく。仮想ボリュームの合計サイズは、ストレージシステムに搭載されている記憶領域の総量よりも大きくてもよい。Ｔｈｉｎ Ｐｒｏｖｉｓｉｏｎｉｎｇ技術では、仮想ボリュームのサイズに相当する記憶領域を、必ずしも最初から用意しておく必要がないため、記憶領域の節約が可能である。

またＴｈｉｎ Ｐｒｏｖｉｓｉｏｎｉｎｇ技術を採用するストレージシステムは、仮想ボリュームに割り当てるべき記憶領域を、プールに格納して管理する。しかし、プールに属する記憶領域が全て仮想ボリュームに割り当てられてしまうと、ストレージシステムはホストからの未割り当て領域に対するライト要求を受け付けることができなくなる。特許文献１に開示の技術では、ストレージシステムはプールの空き容量を監視することで、このようなことが起きないようにしている。プール全体の使用量（仮想ボリュームに割り当てられた記憶領域の量）が閾値を超えた場合、ストレージシステムはプールに新たな記憶領域を追加する。

低コスト化のための別の技術として、圧縮技術がある。たとえば特許文献２には、圧縮機能を有する記憶デバイス（フラッシュパッケージ）を搭載するストレージシステムについて開示されている。このストレージシステムでは、ホスト計算機からのライトデータを圧縮してフラッシュパッケージに格納する。圧縮により、フラッシュパッケージに格納されるデータのサイズは縮小されるため、フラッシュパッケージがストレージシステムに提供する記憶容量（見かけ上の記憶容量）は、フラッシュパッケージが有する記憶媒体（フラッシュメモリチップ）の合計サイズより大きくてもよい。

米国特許８５１６２１５号明細書 米国特許８８６２８０５号明細書

圧縮機能を有する記憶デバイスを、仮想ボリュームに割り当てるべき記憶領域として用いると、Ｔｈｉｎ Ｐｒｏｖｉｓｉｏｎｉｎｇ技術、圧縮技術をそれぞれ単独で用いる場合よりも、記憶領域をより効率的に使用することができる。ただしデータを圧縮する場合、データ内容に依存して圧縮率が変動する。圧縮率が悪い場合、プールに未使用の記憶領域が存在しているにもかかわらず、記憶デバイスが有する記憶媒体の領域が不足しており、データを格納できないという事態も発生し得る。特許文献１に開示の技術のように、単にプールの使用量を監視しているだけでは、このような事態を回避することはできない。

本発明の一観点に係る計算機システムは、物理領域を有する複数の記憶デバイスとプロセッサとを有し、ホストに対して仮想ボリュームを提供するストレージシステムと、このストレージシステムの管理を行う管理サーバを有する。ストレージシステムは複数の記憶デバイスが提供する論理記憶領域を用いて、１以上の論理デバイスを有するＲＡＩＤグループを定義しており、論理デバイスはプールに所属させて管理する。ホストから仮想ボリュームに対するデータライト要求を受け付けると、ストレージシステムはプール内の未使用の論理記憶領域を仮想ボリュームに割り当て、割り当てた論理記憶領域を有する記憶デバイスに対してデータの書き込みを行う。記憶デバイスはデータの書き込み要求を受け付けると圧縮データを生成し、圧縮データを物理領域に格納し、圧縮データの格納された物理領域を前記論理記憶領域に対応付けて管理するように構成されている。

そして本発明の一観点に係る計算機システムは、プールに所属する前記物理領域の物理使用量が所定の閾値を超過したとき、プールに所属する物理領域の量を増加させ、プールに所属する論理記憶領域の論理使用量が所定の閾値を超過したとき、プールに所属する前記論理記憶領域の量を増加させる。

本発明の一観点に係るストレージシステムによれば、圧縮機能を有する記憶デバイスを用いた場合でもプールの容量を適切に管理することができる。

本発明の一実施形態に係る計算機システムの構成例である。 圧縮対応ドライブの構成例である。 ストレージシステムが扱う記憶領域の説明図である。 圧縮対応ドライブ、ドライブ、外部ストレージと、仮想ボリュームの関係を表した概念図である。 ＲＡＩＤグループの構成例を表した図である。 ストレージシステムで用いる主な管理情報を表す図である。 ダイナミックマッピングテーブルの構成例である。 論理物理アドレス変換テーブル（ＬＰ変換テーブル）の構成例である。 圧縮ＲＧ容量情報管理テーブルの構成例である。 プール容量管理画面の例である。 ホストライト処理プログラムのフローチャートである。 デステージ処理プログラムのフローチャートである。 圧縮ＲＧ監視プログラムのフローチャートである。 枯渇回避再配置処理プログラムのフローチャートである。 ページ再配置処理プログラムのフローチャートである。 プール容量管理プログラムのフローチャートである。 プール容量拡張自動化プログラムのフローチャートである。 プール実使用量閾値超過時の、プール容量拡張自動化プログラムが未使用ＬＤＥＶを選択する際の選択基準の説明図である。 プール論理使用量閾値超過時の、プール容量拡張自動化プログラムが未使用ＬＤＥＶを選択する際の選択基準の説明図である。 プールＶＯＬ構成最適化プログラムのフローチャートである。 プールＶＯＬ構成最適化プログラム実行時の管理画面の例である。 プールＶＯＬ構成最適化プログラム実行時の管理画面の例である。 プール容量拡張プログラムのフローチャートである。 プール容量縮小プログラムのフローチャートである。

以下、本発明の実施例について、図面を用いて説明する。なお、以下に説明する実施例は特許請求の範囲に係る発明を限定するものではなく、また実施例の中で説明されている諸要素及びその組み合わせの全てが発明の解決手段に必須であるとは限らない。

また、本明細書では、プログラムが何らかの処理を実行する、という表現（プログラムが動作主体となる表現）が用いられることがある。プログラムはプロセッサで実行されることによって、プログラムに記述された処理を計算機（以下で説明するストレージシステムや管理サーバ）に行わせるものであるから、プログラムを動作主体とする記載は必ずしも正確な表現ではない。ただし説明が冗長になることを避けるため、本明細書では、「プログラム」を主語にして、処理の内容を説明することがある。また、各種プログラムはプログラム配布サーバや、計算機が読み取り可能な記憶メディアによって、プログラムを使用するユーザに提供され、プログラムを実行する計算機にインストールされてもよい。計算機が読み取り可能な記憶メディアとは、非一時的なコンピュータ可読媒体で、例えば、ＩＣカード、ＳＤカード、ＤＶＤ等の不揮発性記憶媒体である。また、プログラムの一部または全てが専用ハードウェアによって実現されてもよい。

実施例の説明に入る前に、実施例で用いられる各種用語について説明する。

以下の実施例では、「圧縮」とは、ＬＺＷアルゴリズム等の可逆圧縮アルゴリズムを用いて、データの意味を保ったままデータサイズを縮小する処理のことを意味する。実施例に係る計算機システムでは、ストレージシステムに搭載される記憶デバイスが、ホストから書き込まれるデータの圧縮を行うことがある。ストレージシステムで圧縮処理が行われたことによりサイズの縮小されたデータのことを、「圧縮データ」と呼び、ストレージシステムで圧縮処理が施されていないデータの事を「非圧縮データ」または「伸張データ」と呼ぶ。また可逆圧縮アルゴリズムを用いて、圧縮データを元のデータサイズに戻す処理のことを、「伸張」と呼ぶ。

また以下の実施例では、データ圧縮によるデータサイズの縮小効率の指標として、「圧縮率」を用いる。本明細書における圧縮率は、以下の計算式により定義されるものである。
圧縮率＝圧縮データのサイズ÷非圧縮データのサイズ

記憶領域の「更新」とは、記憶領域に格納されているデータの内容を新しい内容に書き換える（上書きする）ことを意味する。ある記憶領域が更新される前に、その記憶領域に格納されていたデータは、「更新前データ」と呼ばれる。一方その記憶領域に新たに書き込まれるデータのことは、「更新データ」または「更新後データ」と呼ばれる。

「ボリューム」とは、ストレージシステムや記憶デバイス等のターゲットデバイスが、ホスト計算機等のイニシエータに提供する記憶空間のことを意味する。また、本明細書において「ブロック」とは、ボリューム上の領域を意味する語として用いられる。ブロックは、イニシエータがボリュームにアクセスする時の最小アクセス単位と等しい、固定サイズ（一例として５１２バイト）の領域である。

イニシエータがボリューム上の各ブロックにアクセスする際には、各ブロックにアサインされているアドレスを指定することでアクセスする。このアドレスは、「Ｌｏｇｉｃａｌ Ｂｌｏｃｋ Ａｄｄｒｅｓｓ（ＬＢＡ）」と呼ばれる。以下の実施例では、ｎ番のＬＢＡ（ｎは非負の整数値とする）がアサインされたブロックのことを、“ＬＢＡ＃ｎ”と表記する。また、以下の実施例では特に、ストレージシステムがホストに提供するボリューム（仮想ボリューム）のブロックにアサインされているＬＢＡのことを、「ホストＬＢＡ」と呼ぶことがある。

（１）システム構成
以下、図面を用いて実施例の説明を行う。図１は、実施例に係る計算機システム１００の構成例を示している。計算機システム１００は、ホスト計算機１０１（以下、「ホスト１０１」と略記する）、管理サーバ１０２、ストレージシステム１０４を有する。ホスト１０１、管理サーバ１０２、ストレージシステム１０４は、ネットワーク１０３で互いに接続される。ネットワーク１０３は一例として、ファイバチャネルを用いて形成されるＳＡＮ（Ｓｔｏｒａｇｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）である。

ホスト１０１はストレージシステム１０４が提供する仮想ボリュームを使用する計算機である。ホスト１０１は仮想ボリュームに対して、リードコマンドやライトコマンドを発行することで、仮想ボリュームに格納されたデータにアクセスする。

管理サーバ１０２は、ストレージシステム１０４の管理を行うための計算機で、パーソナルコンピュータ等の汎用のコンピュータと同様に、プロセッサとメモリを有する。本実施例では、管理とは具体的には、ストレージシステム１０４の状態を参照する、あるいはストレージシステム１０４の構成の変更等の処理を意味する。管理サーバ１０２では、ストレージシステム１０４の管理を行うための管理プログラムが実行される。また管理サーバ１０２は、キーボードやディスプレイ等の入出力デバイスを有し、ストレージシステム１０４の状態等の情報を、ディスプレイ等に出力（表示）することもできる。

ストレージシステム１０４は、ホスト１０１に対して１以上のボリューム（仮想ボリューム）を提供する装置である。ストレージシステム１０４は、ポート１０６、保守インタフェース１０７（図中では「保守Ｉ／Ｆ」と表記されている）、ポート１０８、マイクロプロセッサパッケージボード１０９（１０９Ａ、１０９Ｂ）、キャッシュメモリ１１０、共有メモリ１１１、圧縮対応ドライブ１１３、ドライブ１１４を有する。また、これらの各要素は、バス１１２によって相互接続されている。これらの構成物のうち、ポート１０６、保守Ｉ／Ｆ１０７、ポート１０８、マイクロプロセッサパッケージボード１０９、キャッシュメモリ１１０、共有メモリ１１１、バス１１２の集合を、ストレージコントローラと呼ぶこともある。

圧縮対応ドライブ１１３、ドライブ１１４は、ホスト１０１からのライトデータを記憶するための不揮発性記憶媒体を有する記憶デバイスである。記憶媒体としては、たとえば磁気ディスクや、フラッシュメモリ等の不揮発性半導体メモリを用いることができる。圧縮対応ドライブ１１３、ドライブ１１４は、一例として、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）あるいはＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）である。ただし本実施例では、フラッシュメモリを記憶媒体として用いる圧縮対応ドライブ１１３の例について説明する。

圧縮対応ドライブ１１３とドライブ１１４の違いは、圧縮対応ドライブ１１３は、ライトデータを圧縮して自身の記憶媒体に格納する機能（圧縮機能）を有するが、ドライブ１１４は圧縮機能を持たない点にある。なお、以下では、圧縮対応ドライブ１１３、ドライブ１１４を区別せずに表現する場合、「記憶デバイス」と呼ぶ。

ポート１０６は、ストレージシステム１０４がホスト１０１等のイニシエータと通信するために用いられる、インタフェースデバイスである。ホスト１０１が仮想ボリュームにアクセスするために発行するコマンド（リードコマンド、ライトコマンド等）は、ポート１０６に到来する。またストレージシステム１０４がホスト１０１に応答等の情報を返送する時には、ポート１０６から情報を返却する。

保守Ｉ／Ｆ１０７は、ストレージシステム１０４が管理サーバ１０２と通信するためのインタフェースデバイスである。管理サーバ１０２からのコマンドは保守Ｉ／Ｆ１０７に到来する。そしてストレージシステム１０４が管理サーバ１０２に応答等の情報を返却する時には、保守Ｉ／Ｆ１０７から情報を返却する。

図１では、ポート１０６と保守Ｉ／Ｆ１０７がいずれもネットワーク１０３に接続された構成が示されているが、これ以外の構成もあり得る。ポート１０６が接続されるネットワークと、保守Ｉ／Ｆ１０７が接続されるネットワークが、異なるネットワークであってもよい。

ポート１０８は、ストレージシステム１０４が外部ストレージ１０５等のターゲットデバイスと通信するためのインタフェースデバイスである。外部ストレージ１０５は、ドライブ１１４等の記憶デバイスでもよいし、またはストレージシステム１０４のように複数の記憶デバイスを有する大容量の記憶装置でもよい。ポート１０８に外部ストレージ１０５が接続されると、ストレージシステム１０４は外部ストレージ１０５が提供する記憶領域を、ドライブ１１４が提供する記憶領域と同様のものとして使用することができる。

マイクロプロセッサパッケージボード（以下、“ＭＰＢ”と表記する）１０９は、プロセッサ１１９とローカルメモリ１１８を有するパッケージボードである。プロセッサ１１９はストレージシステム１０４の各種制御を行うためのプログラムを実行するデバイスである。ローカルメモリ１１８は、プロセッサ１１９が実行するプログラムや、プロセッサ１１９が使用する情報を一時的に保存するために用いられる。図１では、ストレージシステム１０４が２つのＭＰＢ１０９（ＭＰＢ１０９Ａ及び１０９Ｂ）を有する構成が示されているが、ＭＰＢ１０９の数は２以外でもよい。ストレージシステム１０４にＭＰＢ１０９が１つだけ搭載されている構成でも良いし、或いは３以上のＭＰＢ１０９が搭載されていてもよい。

キャッシュメモリ１１０は、仮想ボリューム（記憶デバイス）に対するライトデータ、または仮想ボリューム（記憶デバイス）から読み出されたデータ（リードデータ）を一時的に記憶するために用いられる。キャッシュメモリ１１０には、ＤＲＡＭ、ＳＲＡＭ等の揮発性記憶媒体が用いられるが、別の実施形態として、キャッシュメモリ１１０に不揮発性メモリが用いられてもよい。また、キャッシュメモリ１１０に揮発性記憶媒体が用いられる場合、ストレージシステム１０４にバッテリ等の補助電源を搭載し、停電時に補助電源を用いてキャッシュメモリ１１０の記憶内容を維持できるように構成されていてもよい。

共有メモリ１１１は、ＭＰＢ１０９（のプロセッサ１１９）が使用する管理情報を格納するための記憶領域である。キャッシュメモリ１１０と同様、共有メモリ１１１には、ＤＲＡＭ、ＳＲＡＭ等の揮発性記憶媒体が用いられるが、不揮発性メモリが用いられてもよい。またキャッシュメモリ１１０と共有メモリ１１１は、ローカルメモリ１１８と異なり、任意のＭＰＢ１０９（たとえばＭＰＢ１０９ＡとＭＰＢ１０９Ｂ）のプロセッサ１１９からアクセス可能な記憶領域である。

続いて図２を用いて、圧縮対応ドライブ１１３の構成を説明する。圧縮対応ドライブ１１３は、コントローラ２１０と、ホスト１０１からのライトデータを記憶するための記憶媒体であるフラッシュメモリ２８０を有する。コントローラ２１０は、ドライブＩ／Ｆ２１１、プロセッサ２１３、メモリ２１４、フラッシュＩ／Ｆ２１５、圧縮伸張回路２１６を有し、これらは内部ネットワーク２１２を介して相互接続されている。

ドライブＩ／Ｆ２１１は、ストレージシステム１０４と通信するためのインタフェースデバイスである。一方フラッシュＩ／Ｆ２１５は、コントローラ２１０がフラッシュメモリ２８０と通信するためのインタフェースデバイスである。

プロセッサ２１３は、圧縮対応ドライブ１１３の制御を行うためのプログラムを実行する。メモリ２１４は、プロセッサ２１３が実行するプログラムや、プロセッサ２１３が使用する制御情報等を格納するためのものである。本実施例では、以下で説明する圧縮対応ドライブ１１３が行う処理（記憶領域の管理、ストレージシステム１０４からのアクセス要求の処理等）は、プロセッサ２１３がプログラムを実行することにより行われる。

圧縮伸張回路２１６は、データの圧縮または伸張を行うデバイスである。圧縮伸張回路２１６は、ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）等のハードウェアで実装される．ただし、圧縮伸張回路２１６をＣＰＵとメモリで構成してもよい。その場合、ＣＰＵでデータ圧縮（または伸張）を行うためのプログラムが実行されることで、データの圧縮または伸張が行われる。あるいは、プロセッサ２１３でデータ圧縮（または伸張）を行うためのプログラムを実行させることで、プロセッサ２１３にデータの圧縮または伸張を行わせるようにしてもよい。この場合、コントローラ２１０に圧縮伸張回路２１６は不要になる。

（２）記憶領域の管理
続いて、本実施例に係るストレージシステム１０４が扱う記憶領域について説明する。まず、記憶デバイス（とくに圧縮対応ドライブ１１３）がストレージシステム１０４に提供するボリュームについて、図３を用いて説明する。

圧縮対応ドライブ１１３は、イニシエータに対して１つのボリューム（記憶空間）を提供する。本実施例の場合、圧縮対応ドライブ１１３はストレージシステム１０４に接続されるため、圧縮対応ドライブ１１３に対するイニシエータは、ストレージシステム１０４（のプロセッサ１１９）である。圧縮対応ドライブ１１３が提供するボリュームのサイズは、圧縮対応ドライブ１１３の有する記憶媒体（フラッシュメモリ２８０）の総記憶容量よりも大きくてもよい。

本実施例では、圧縮対応ドライブ１１３がイニシエータに提供するボリュームのことを、「（圧縮対応ドライブ１１３の）論理アドレス空間」（図３における、論理アドレス空間４００）と呼ぶ。また、論理アドレス空間４００のサイズは、「（圧縮対応ドライブ１１３の）論理容量」と呼ばれる。一方圧縮対応ドライブ１１３は、圧縮対応ドライブ１１３が有する全てのフラッシュメモリ２８０が有する記憶領域で構成される記憶空間も管理している。この記憶空間のことを、物理アドレス空間（図３における、物理アドレス空間４５０）と呼ぶ。また物理アドレス空間上の領域のことを「物理領域」と呼ぶ。物理アドレス空間のサイズは、圧縮対応ドライブ１１３の有するフラッシュメモリ２８０の総記憶容量に等しい。また、物理アドレス空間のサイズのことを、「（圧縮対応ドライブ１１３の）実容量」と呼ぶ。言い換えると、実容量とは、データを格納可能な物理領域の合計サイズといえる。

先にも述べたが、圧縮対応ドライブ１１３は、圧縮伸張回路２１６を用いてイニシエータからのライトデータを圧縮し、圧縮されたライトデータ（圧縮データ）を物理領域に格納する。本実施例では一例として、圧縮対応ドライブ１１３は、論理アドレス空間４００を４ＫＢごとの部分領域に区分し、この部分領域ごとに圧縮を行う。本実施例では、この論理アドレス空間４００上の４ＫＢの部分領域は「セグメント」と呼ばれる。たとえばストレージシステム１０４が、圧縮対応ドライブ１１３の論理アドレス空間４００の先頭から８ＫＢの領域に対してデータライトを行うと、圧縮対応ドライブ１１３はまず論理アドレス空間４００の先頭のセグメント４０１（ＬＢＡ＃０からＬＢＡ＃７までの領域）に対して書き込まれたデータを圧縮する。続いて圧縮対応ドライブ１１３は、論理アドレス空間４００の先頭から２番目に位置するセグメント４０２（ＬＢＡ＃８からＬＢＡ＃１５までの領域）に対して書き込まれたデータを圧縮する。

圧縮後のデータは、物理領域に格納される。本実施例において、コントローラ２１０は物理領域（物理アドレス空間４５０）を５１２Ｂごとの部分領域に区分し、この部分領域を圧縮データに割り当てる。ここで「割り当てる」とは、コントローラ２１０が、ストレージシステム１０４からライト要求を受け付けた論理アドレス空間４００上のセグメントのアドレスと、このセグメントに対して書き込まれたライトデータの圧縮データが格納された部分領域のアドレス（及びこの物理領域のサイズ）との対応関係（マッピング）を、マッピングテーブル等を用いて管理することである。本実施例では、この物理アドレス空間４５０上の部分領域は「コードワード」と呼ばれる。図３においては、ＣＷ４３１〜４３５で表される。たとえばセグメント４０１に対する圧縮データはＣＷ４３１が割り当てられる。セグメント４０２に対する圧縮データはＣＷ４３２、ＣＷ４３３、ＣＷ４３４の３つが割り当てられる。マッピングテーブルで管理される物理領域のサイズは、セグメントに対して書き込まれたライトデータの圧縮データに対して割り当てたコードワードのサイズの総和に等しい。

コントローラ２１０がストレージシステム１０４から、論理アドレス空間４００上のアドレスを指定したリード要求を受け付けると、このマッピングテーブルを参照することで、リード要求で指定された領域（セグメント）にマッピングされている、物理領域のアドレスを特定する。そしてコントローラ２１０は、特定されたアドレスに対応する物理領域から圧縮データを読み出し、圧縮伸張回路２１６を用いて読み出した圧縮データを伸張する。そしてコントローラ２１０は伸張されたデータをストレージシステム１０４に返却する。

なお、セグメントのアドレス（論理アドレス空間４００上のアドレス）と、物理領域のアドレス（物理アドレス空間４５０上アドレス）とのマッピングは、必ずしも静的ではなく、動的なマッピングである。コントローラ２１０はセグメントに対する更新要求及び更新データを受け付けると、更新データの圧縮後のデータは、更新前データの書き込まれている物理領域とは別の物理領域に格納される。そのため、セグメントに対する更新が発生するたびに、マッピングテーブルの内容は変更される。更新前データの書き込まれている物理領域は、後で消去処理が行われることにより、新たなデータを書き込み可能な状態にされる。これは、従来からあるフラッシュメモリストレージで行われる処理と同様である。

圧縮後のデータのサイズは、データ内容に依存して変わり得る。本実施例では、圧縮伸張回路２１６が４ＫＢ（１セグメント分）のデータを圧縮した時、圧縮後のデータサイズは最小で５１２バイト（圧縮前に比べてデータサイズが１／８になる場合）、最大で４ＫＢ（圧縮前とデータサイズが変わらない場合）になるという前提で説明する。圧縮後のデータサイズが小さいほど、圧縮率が良い。

最も圧縮率が良い場合、つまり圧縮によりすべてのデータのサイズが、圧縮前の１／８になる場合、圧縮対応ドライブ１１３には実容量の８倍のデータを格納できる。本実施例では、圧縮対応ドライブ１１３の論理容量は、圧縮率が最も良い場合にあわせて定められている。つまり圧縮対応ドライブ１１３の論理容量は、実容量の８倍という関係にある。

圧縮対応ドライブ１１３と同様、ドライブ１１４もストレージシステム１０４に１つのボリュームを提供する。ただしドライブ１１４はデータの圧縮を行わないので、ボリュームのサイズは、ドライブ１１４が有する記憶媒体の容量と同じという関係にある。つまりドライブ１１４の論理容量と実容量は等しい。

続いて、ストレージシステム１０４がホスト１０１に提供する仮想ボリュームについて説明する。図４は、圧縮対応ドライブ１１３、ドライブ１１４、外部ストレージ１０５と、仮想ボリュームの関係を表した概念図である。

ストレージシステム１０４はホスト１０１に、Ｔｈｉｎ Ｐｒｏｖｉｓｉｏｎｉｎｇ技術により形成されるボリューム（以下、「仮想ボリューム」と呼ぶ）を提供する。よく知られているように、仮想ボリュームは、その初期状態（仮想ボリュームが定義された直後）では、仮想ボリューム上の各ブロックには記憶領域が対応付けられていない。ホスト１０１が仮想ボリューム上のブロックに対してデータライト要求（ライトコマンド）を発行した時点で、ストレージシステム１０４はそのブロックに記憶領域を割り当てる。

仮想ボリューム上のブロックには、圧縮対応ドライブ１１３、ドライブ１１４、または外部ストレージ１０５がストレージシステム１０４に提供するボリューム上の領域が動的に割り当てられる。以下では、圧縮対応ドライブ１１３、ドライブ１１４、または外部ストレージ１０５がストレージシステム１０４に提供するボリューム上の領域のことを、「論理記憶領域」と呼ぶ。

ストレージシステム１０４は論理記憶領域のうち、仮想ボリュームに割り当てて良い領域を管理するために、「プール」と呼ばれる管理単位を定義する。ストレージシステム１０４は仮想ボリューム上領域に論理記憶領域の割り当てを行う際、プールに属している論理記憶領域の中から、未使用の論理記憶領域（まだどの仮想ボリュームにも割り当てられていない論理記憶領域）を割り当てる。論理記憶領域をプールに所属させる処理は、ユーザが管理サーバ１０２を用いて行う。

またストレージシステム１０４はＲＡＩＤ技術を用いて、複数の記憶デバイスのボリュームから１つの記憶空間を形成する。本実施例では、ＲＡＩＤ技術を用いて形成される記憶空間、あるいはこの記憶空間を構成する記憶デバイスの集合のことを、「ＲＡＩＤグループ」と呼ぶ。よく知られているように、ＲＡＩＤグループには、ホスト１０１からのライトデータに加えて、ライトデータを用いて生成される冗長データ（パリティ）も格納される。

なお、本実施例に係るストレージシステム１０４では、１つのＲＡＩＤグループに属する記憶デバイスは、全て同じ種類のものに制限されている。たとえばＲＡＩＤグループ内に、圧縮対応ドライブ１１３とドライブ１１４が混在してはならない。以下では、圧縮対応ドライブ１１３のみで構成されるＲＡＩＤグループのことを、「圧縮ＲＧ」と呼ぶ。

図５に、ＲＡＩＤグループの一例を示す。図５において、ボリューム（１１３−０）〜ボリューム（１１３−３）は、記憶デバイス（たとえば圧縮対応ドライブ１１３）がストレージシステム１０４に提供しているボリュームを表す。図５では４つのボリューム（（１１３−０）〜（１１３−３））によってＲＡＩＤグループ１１５が形成されている例が示されている。

ストレージシステム１０４は、各ボリューム（（１１３−０）〜（１１３−３））を、ストライプブロック（図５では３０１−０〜３０１−３）と呼ばれる、所定サイズ（たとえば６４ＫＢ）の領域に分割して管理する。図５で、ストライプブロックのうち、「Ｐ」と記載されているストライプブロックは、冗長データ（パリティ）の格納されるストライプブロックであり、これを「パリティストライプ」と呼ぶ。一方、数字（０、１等）が記載されているストライプブロックは、ホスト１０１から書き込まれるデータ（冗長データではないデータ）が格納されるストライプブロックである。このストライプブロックのことは、「データストライプ」と呼ばれる。

パリティストライプには、ストレージシステム１０４が複数のデータストライプを用いて生成した冗長データが格納される。以下、パリティストライプと、当該パリティストライプに格納される冗長データを生成するために用いられるデータストライプのセット（たとえば図５中の要素３０５）のことを、「ストライプライン」と呼ぶ。

またストレージシステム１０４は、ＲＡＩＤグループの記憶領域をプールに所属させる時、ＲＡＩＤグループを１以上の部分領域に分割し、この部分領域をプールに所属させる。この部分領域のことを、本実施例では「論理デバイス」または「ＬＤＥＶ」と呼ぶ。図５において、要素３００がＬＤＥＶである。ＬＤＥＶのサイズは任意である。ただし本実施例では図５に示されているように、ＬＤＥＶ３００は複数のストライプラインから構成されるものとする。そのためＬＤＥＶ３００のサイズは、ストライプラインのサイズの整数倍である。

ＬＤＥＶを定義する処理は、ユーザが管理サーバ１０２を用いてストレージシステム１０４に指示を行うことで実施される。ＲＡＩＤグループ内には、任意の数のＬＤＥＶを定義可能である。またＬＤＥＶを定義する契機はいつでも良く、初期状態（ストレージシステム１０４の導入時など）の時点では、ユーザはＲＡＩＤグループ内に１つだけＬＤＥＶを定義しておき、その後プールに記憶領域を追加する必要が出た時点で、ユーザはＲＡＩＤグループ内の未使用領域（ＬＤＥＶとして定義されていない領域）に新たにＬＤＥＶを定義することもできる。

プールには、複数のＬＤＥＶを所属させることができる。以下では、プールに所属した状態にあるＬＤＥＶのことを、「プールＶＯＬ」と呼ぶ。また、１つのプールに所属する各ＬＤＥＶは、それぞれ異なるＲＡＩＤグループに含まれているＬＤＥＶでよい。たとえば圧縮対応ドライブ１１３から構成されるＲＡＩＤグループに含まれているＬＤＥＶと、ドライブ１１４から構成されるＲＡＩＤグループに含まれているＬＤＥＶが、１つのプールに所属していてもよい。

また、ストレージシステム１０４はプールを複数定義することができる。ただしプールにＬＤＥＶを所属させる際、圧縮対応ドライブ１１３から構成される１つのＲＡＩＤグループに定義される複数のＬＤＥＶは、必ず同じプールに所属しなければならない。この制約が設けられている理由は、圧縮対応ドライブ１１３で構成されたＲＡＩＤグループに定義されるＬＤＥＶにデータを格納する場合、各ＬＤＥＶに格納可能な最大データ量を明確に定められないためである。

たとえば、コントローラ２１０が圧縮対応ドライブ１１３の物理アドレス空間４５０の２倍の論理アドレス空間４００をストレージシステム１０４に提供している場合、この圧縮対応ドライブ１１３を用いて構成されるＲＡＩＤグループ１１５の論理容量（ＲＡＩＤグループ１１５に属する圧縮対応ドライブ１１３の論理容量の合計）は、実容量（ＲＡＩＤグループ１１５に属する圧縮対応ドライブ１１３の実容量の合計）の２倍である。仮にこのＲＡＩＤグループ１１５の実容量をＶ（ＴＢ）とすると、このＲＡＩＤグループ１１５の論理容量は２Ｖ（ＴＢ）である。

そして、このＲＡＩＤグループを二等分することで２つのＬＤＥＶ（仮にＬＤＥＶ１、ＬＤＥＶ２とする）を定義し、プール１にＬＤＥＶ１、プール２にＬＤＥＶ２を所属させる例を想定する。Ｖ（ＴＢ）の量のデータがＬＤＥＶ１に書き込まれた場合、かつそのデータが圧縮によってサイズが全く減少しなかった場合、ＲＡＩＤグループの実容量（つまりＶ（ＴＢ）の物理領域）はすべて使用されることになる。

その状態で、コントローラ２１０がプール２に属するＬＤＥＶ２にデータを格納しようとしても、ＬＤＥＶ２には全くデータを書き込んでいないにもかかわらず、ＲＡＩＤグループ内に使用可能な物理領域が存在しなくなっているため、データを書き込むことが出来ない。結果、ユーザのプール容量の管理を難しくさせる。この問題を防ぐ為、圧縮対応ドライブ１１３から構成される１つのＲＡＩＤグループに定義された複数のＬＤＥＶは必ず同じプールに所属させるようにしている。

本制限から、あるＲＡＩＤグループ（仮に“ＲＡＩＤグループＡ”と呼ぶ）に含まれるＬＤＥＶがあるプール（仮に“プール＃１”と呼ぶ）に所属している場合、ＲＡＩＤグループＡのことを「プール＃１に属するＲＡＩＤグループ」と呼ぶこともある。そしてこの場合、ＲＡＩＤグループＡ内の各ＬＤＥＶは、プール＃１に属しているか、あるいはいずれのプールにも属していない状態にあることを意味する。

一方で、ドライブ１１４から構成される１つのＲＡＩＤグループに定義された複数のＬＤＥＶは、複数のプールに所属していても良い。ドライブ１１４ではデータ圧縮が行われないため、ドライブ１１４から構成されるＬＤＥＶに格納可能なデータの量が変動することがないからである。

ストレージシステム１０４は、プールに属する論理記憶領域を仮想ボリュームに割り当てる時、ページと呼ばれる所定サイズの領域毎に割り当てる。本実施例では、ページはＬＤＥＶ内の部分領域で、１または複数のストライプラインから構成されるものとする。

またストレージシステム１０４は仮想ボリュームを仮想ページという領域に分割して管理している。ストレージシステム１０４はホスト１０１から仮想ページに対するライト要求を受領すると、プール内の未使用ページをその仮想ページに割り当てる。なお、本明細書において、「未使用ページ」とは、いずれの仮想ページにも割り当てられていないページを意味する。逆に仮想ページにマッピングされているページのことを「使用中ページ」と呼ぶ。仮想ページと、仮想ページに割り当てられたページとの関係（マッピング）は、後述するダイナミックマッピングテーブルに格納されて管理される。図４の５０２Ａ〜５０２Ｅはプール内のページが割り当てられた仮想ページ、５０４Ａ〜５０４Ｆは「使用中ページ」を表している。

プールが複数存在する場合、各仮想ボリュームはいずれか１つのプールに属する。ストレージシステム１０４が仮想ボリュームの仮想ページにページを割り当てる際、その仮想ボリュームの属するプール内の未使用ページを割り当てる。なお、ページにはＲＡＩＤ技術により生成されたパリティが含まれているが、仮想ページにページを割り当てる際、パリティは割り当てられない。そのため仮想ページのサイズは、ページのサイズから、ページに含まれているパリティストライプのサイズを除いたものになる。

ここまで、仮想ボリューム、ＲＡＩＤグループ、プール、論理デバイス等の概念を説明してきたが、仮想ボリューム、ＲＡＩＤグループ、プール、論理デバイスを定義して管理する処理、また仮想ボリュームをホスト１０１に提供する（ホスト１０１が仮想ボリュームを認識できるようにし、ホスト１０１からの仮想ボリュームに対するアクセス要求を受け付け可能な状態にする）処理は、プロセッサ１１９で実行されるプログラムによって行われる。ただし別の実施形態として、プログラムに代えて、これらの処理を実行する専用のハードウェアをストレージシステム１０４に設けてもよい。

（３）ストレージシステムの管理情報
続いて、本実施例に係るストレージシステム１０４で用いる主な管理情報の内容を説明する。ただしその前に、管理情報の内容を理解するうえで必要になる用語の定義を説明する。

上では、記憶デバイス（特に圧縮対応ドライブ１１３）の論理容量と実容量について説明したが、本実施例では論理容量と実容量以外に、実使用量、論理使用量という概念も用いられる。また記憶デバイス以外に、プール、ＲＡＩＤグループにも、論理容量、実容量、実使用量、論理使用量が定義される。

圧縮対応ドライブ１１３の論理使用量と実使用量について説明する。圧縮対応ドライブ１１３の論理アドレス空間のうち、イニシエータから書き込みが行われた領域の合計サイズのことを、圧縮対応ドライブ１１３の論理使用量と呼ぶ。また、イニシエータから書き込みが行われた論理アドレス空間上のセグメントにマッピングされている、コードワードの合計サイズのことを、圧縮対応ドライブ１１３の実使用量と呼ぶ。なお、ドライブ１１４の論理使用量の定義は、圧縮対応ドライブ１１３の論理使用量と同じである。またドライブ１１４の実使用量は、ドライブ１１４の論理使用量と等しい。

圧縮対応ドライブ１１３は、イニシエータからの要求があると、圧縮対応ドライブ１１３の実容量、実使用量をイニシエータに通知する機能を有する。また圧縮対応ドライブ１１３は、イニシエータからの要求があると、論理アドレス空間４００上の各セグメントにマッピングされている物理領域のサイズを通知する機能も有する。各セグメントにマッピングされている物理領域のサイズは、圧縮データのサイズである。この機能により、イニシエータ（ストレージシステム１０４）は、各セグメントに対して書き込んだデータの圧縮後のサイズを知ることができる。

ＲＡＩＤグループの論理容量及び実容量は以下のように定義される。ＲＡＩＤグループは複数の記憶デバイスから構成される。ＲＡＩＤグループを構成する記憶デバイスの論理容量の合計が、ＲＡＩＤグループの論理容量として定義される。一方ＲＡＩＤグループを構成する記憶デバイスの実容量の合計（つまり記憶デバイスが有する物理領域の合計サイズ）が、ＲＡＩＤグループの実容量として定義される。なお、本実施例において、ＲＡＩＤグループの論理容量及び実容量には、パリティストライプのサイズも含まれる。ただし別の実施形態として、ＲＡＩＤグループの論理容量及び実容量に、パリティストライプのサイズを含めないようにしてもよい。

またＲＡＩＤグループの論理使用量及び実使用量、とくに圧縮対応ドライブ１１３から構成されるＲＡＩＤグループの論理使用量及び実使用量は以下のように定義される。ＲＡＩＤグループ上のページのうち、仮想ページにマッピングされているページ（使用中ページ）の合計サイズが、ＲＡＩＤグループの論理使用量として定義される。またＲＡＩＤグループ上の使用中ページに対してマッピングされている、圧縮対応ドライブ１１３の物理領域の合計サイズのことを、ＲＡＩＤグループの実使用量と呼ぶ。

ドライブ１１４から構成されるＲＡＩＤグループの論理使用量の定義は、圧縮対応ドライブ１１３から構成されるＲＡＩＤグループの論理使用量の定義と同じである。またドライブ１１４から構成されるＲＡＩＤグループの実使用量は、論理使用量と等しい。

なお、本実施例ではＲＡＩＤグループの論理使用量には、パリティストライプのサイズも含まれているものとする。ただし別の実施形態として、パリティストライプのサイズを含まないサイズを論理使用量と定義してもよい。またＲＡＩＤグループの実使用量も同様に、パリティストライプの圧縮データが格納された物理領域のサイズを含んでいる。ただし別の実施形態として、パリティストライプの圧縮データが格納された物理領域のサイズは実使用量に含まれないという定義が採用されてもよい。

ＬＤＥＶの論理容量及び論理使用量の定義は、ＲＡＩＤグループの論理容量及び論理使用量の定義と同様である。具体的には、ＬＤＥＶに含まれるページの合計容量が、ＬＤＥＶの論理容量であり、またＬＤＥＶに含まれるページのうち、使用中ページの合計サイズがＬＤＥＶの論理使用量である。

またプールの論理容量、実容量、論理使用量及び実使用量は以下のように定義される。プールに属しているＬＤＥＶ（プールＶＯＬ）の論理容量の合計が、プールの論理容量である。言い換えれば、プールＶＯＬに含まれるページの合計容量が、プールの論理容量である。

またプールの実容量は、他の実容量の定義と同様、プールに属する（プールで使用可能な）物理領域の合計サイズであるが、以下の手順で計算される値として定義される。ｎ個（ｎは１以上の整数）のＲＡＩＤグループが所属するプールを例にとって説明する。以下ではこのプールに属する各ＲＡＩＤグループを、ＲＧ＃１，ＲＧ＃２，．．．，ＲＧ＃ｎと表記する。またＲＧ＃ｉの実容量をＲ_ｉと表記する（ｉは、１≦ｉ≦ｎを満たす整数である）。また、ＲＧ＃ｉが有するプールＶＯＬの論理容量の総和をＶ_ｉと表記する。このとき、このプールの実容量Ｐは以下の式（１）で定義される。

なお、式（１）中の表記“Ｍｉｎ（Ａ，Ｂ）”は、Ａ，Ｂのうち小さい方の値を意味する。

つまり、プールに属するＲＡＩＤグループ毎に、ＲＡＩＤグループの実容量とプールＶＯＬの論理容量の合計の最小値を求め、このＲＡＩＤグループ毎に求められた値の和を求めることで、プールの実容量が算出される。プールに属するＲＡＩＤグループが１つの場合、プールＶＯＬの論理容量の合計がＲＡＩＤグループの実容量より小さい場合には、プールＶＯＬの論理容量の合計がプールの実容量である。そしてプールＶＯＬの論理容量の合計がＲＡＩＤグループの実容量より大きい場合には、ＲＡＩＤグループの実容量がプールの実容量になる。

なお、プールＶＯＬが、圧縮機能を持たないドライブ１１４から構成される場合も、圧縮対応ドライブ１１３から構成される場合も、プールの実容量Ｐの計算方法は上の式（１）に従って求められる。ただし、圧縮機能を持たないドライブ１１４から構成されるＲＡＩＤグループでは、常にＲ_ｉ≧Ｖ_ｉの関係が成り立つ。そのため、仮に圧縮機能を持たないドライブ１１４から構成されるＬＤＥＶしか所属していないプールがあった場合、そのプールの実容量は、プールＶＯＬの論理容量の総和を算出する事で求められる。

プールの論理使用量は、プール内ページのうち使用中のページの合計である。またプールの実使用量は、プール内の全ての使用中ページにマッピングされている、圧縮対応ドライブ１１３の物理領域の合計サイズである。

ＲＡＩＤグループの論理容量等と同様、プールの論理容量、実容量、論理使用量及び実使用量には、パリティストライプのサイズも含まれる。ただし別の実施形態として、パリティストライプのサイズを含めないサイズを、プールの論理容量、実容量、論理使用量または実使用量とする定義が採用されてもよい。

続いて、本実施例に係るストレージシステム１０４で用いる主な管理情報の内容を説明する。図６に示されているように、ストレージシステム１０４は共有メモリ１１１に、ダイナミックマッピングテーブル７０１、論理物理アドレス変換テーブル７０２、圧縮ＲＧ容量情報管理テーブル７０３、プール管理テーブル６００を有する。

図７にダイナミックマッピングテーブル７０１の例を示す。ダイナミックマッピングテーブル７０１は、ストレージシステム１０４が有する仮想ページの情報を管理するためのテーブルである。ダイナミックマッピングテーブル７０１の各行（レコード）には、仮想ページの属性情報が格納されている。各仮想ページは、プール番号（７０１−１）、仮想ボリューム番号（７０１−２）、仮想ページ番号（仮想ページ＃と表記されることもある）（７０１−３）、ホストＬＢＡ（７０１−４）、プールボリューム番号（７０１−５）、ページ＃（７０１−６）の属性情報を有する。

仮想ボリューム番号（７０１−２）は、仮想ページの属する仮想ボリュームの識別番号で、仮想ページ＃（７０１−３）は仮想ページの識別番号である。またホストＬＢＡ（７０１−４）は、仮想ページの先頭ブロックのホストＬＢＡである。プール番号（７０１−１）は仮想ページの属するプールの識別番号を表す。そして、プールボリューム番号（７０１−５）とページ＃（７０１−６）の組は、仮想ページにマッピングされているページの属性情報である。仮想ページにページがマッピングされていないとき、プールボリューム番号（７０１−５）とページ＃（７０１−６）には無効値（ＮＵＬＬ）が格納されている。ストレージシステム１０４はホスト１０１から仮想ページに対するライト要求を受け付け、仮想ページにマッピングされるべきページを選択すると、選択されたページのページ番号及びそのページの属する論理デバイスの識別子（プールボリューム番号）をそれぞれ、ページ＃（７０１−６）とプールボリューム番号（７０１−５）に記録する。

図８に、論理物理アドレス変換テーブル７０２の例を示す。論理物理アドレス変換テーブル７０２は、ページの属性情報を管理するテーブルである。このテーブルの各レコードには、ストレージシステム１０４が管理するページに対応付けられたＲＡＩＤグループ及び記憶デバイスの情報が格納される。論理物理アドレス変換テーブル７０２は、プールごとに設けられるテーブルである。そのためストレージシステム１０４にプールがｎ個設けられる場合、ｎ個の論理物理アドレス変換テーブル７０２がストレージシステム１０４内に定義される。また論理物理アドレス変換テーブル７０２は、ＬＰ変換テーブル７０２とも呼ばれる。

論理物理アドレス変換テーブル７０２の各レコードは、プールボリューム番号（７０２−１）及びページ＃（７０２−２）で特定されるページが、ＲＧ番号（７０２−３）で特定されるＲＡＩＤグループに属していることを表している。またドライブ番号（７０２−４）には、ページが所属するＲＡＩＤグループを構成している全記憶デバイスの識別番号が格納される。開始アドレス（７０２−５）は、ページ内先頭位置に対応する、記憶デバイスのアドレスを表している。

本実施例に係るストレージシステム１０４では、ユーザが管理サーバ１０２から指示をすることでプールにＬＤＥＶが追加される。あるいはストレージシステム１０４がプールの状態に応じてＬＤＥＶを追加することがある。プールにＬＤＥＶが追加されることが決定されると、ストレージシステム１０４は論理物理アドレス変換テーブル７０２に、追加対象のＬＤＥＶに含まれる全ページの情報を登録する。逆にプールからＬＤＥＶが削除される場合、ストレージシステム１０４は論理物理アドレス変換テーブル７０２から、削除対象のＬＤＥＶに含まれる全ページの情報を削除する。この処理の詳細は後述する。

次に図９を用いて、圧縮ＲＧ容量情報管理テーブル７０３の例を説明する。圧縮ＲＧ容量情報管理テーブル７０３は、圧縮対応ドライブ１１３から構成されるＲＡＩＤグループ（圧縮ＲＧ）の情報を管理するためのテーブルである。また圧縮ＲＧ容量情報管理テーブル７０３には、圧縮ＲＧのうち、プールに記憶領域を提供している圧縮ＲＧの情報のみが格納される。

圧縮ＲＧ容量情報管理テーブル７０３の各レコードには、プールに記憶領域を提供している圧縮ＲＧの属性情報が格納される。ＲＧ番号７０３−１は圧縮ＲＧの識別番号であり、プールＶＯＬ容量総和７０３−２は、圧縮ＲＧ内のＬＤＥＶのうち、プールに所属しているＬＤＥＶ(プールＶＯＬ)の論理容量の合計値である。

プール内実容量７０３−３は、圧縮ＲＧの実容量、あるいは圧縮ＲＧ内ＬＤＥＶのうちプールに属しているＬＤＥＶの論理容量の合計値のうち、いずれか小さい方の値が格納される。

実使用量７０３−４は、圧縮ＲＧの実使用量である。再配置要求ビット７０３−５は、後述する再配置処理が必要であることを表す情報である。再配置要求ビット７０３−５には、後述する圧縮ＲＧ監視プログラム８０３が情報を格納する。再配置処理が必要な圧縮ＲＧがある場合、その圧縮ＲＧの再配置要求ビット７０３−５には“１”が格納され、そうでない圧縮ＲＧの再配置要求ビット７０３−５は“０”が格納される。再配置要求ビット７０３−５の初期値は“０”である。なお、再配置要求ビット７０３−５に“１”が格納された状態を、再配置要求ビット７０３−５が“ＯＮ”状態であるともいう。逆に再配置要求ビット７０３−５に“０”が格納された状態を、再配置要求ビット７０３−５が“ＯＦＦ”状態であるともいう。

なお、上では、仮想ボリュームと圧縮ＲＧの管理に用いられる管理情報を中心に説明した。仮想ボリュームの形成に用いられる（プールに所属する）論理デバイス及びＲＡＩＤグループは、ＬＰ変換テーブル７０２や圧縮ＲＧ容量情報管理テーブル７０３等によって管理される。しかし、プールに所属していない論理デバイス及びＲＡＩＤグループの構成を管理するための情報（容量やＲＡＩＤグループを構成するために用いられる記憶デバイスの情報等）は、ＬＰ変換テーブル７０２や圧縮ＲＧ容量情報管理テーブル７０３で管理されない。ストレージシステム１０４は上で説明した管理情報以外にも、ＲＡＩＤグループ及び論理デバイスの構成を管理するための情報（構成情報と呼ぶ）を共有メモリ１１１に格納しており、プールに所属していない論理デバイス及びＲＡＩＤグループの構成に関する情報は、この構成情報で管理される。これらの情報は公知のため、ここでの説明は略す。

（４）閾値、及びプールの管理
本実施例に係るストレージシステム１０４では、プールの論理容量、実容量、論理使用量、実使用量を管理している。図１０に管理サーバ１０２のディスプレイに表示されるプール容量管理ＧＵＩ６００’の内容を示す。プール容量管理ＧＵＩ６００’では、プールごとに、状態６０６、論理容量６０７、論理使用量６０８、実容量６０９、実使用量６１０が表示される。また論理容量６０１、実容量６０２はそれぞれ、ストレージシステム１０４が有する全プールの論理容量の合計、実容量の合計を表す。仮想ＶＯＬ容量６０３はストレージシステム１０４内に定義されている全仮想ボリュームの容量（論理容量）の合計である。またプール数６０４は、ストレージシステム１０４が有するプールの総数を表す。

ストレージシステム１０４はプールの論理使用量が所定の閾値（論理使用量閾値）を超過した場合、あるいはプールの実使用量が所定の閾値（実使用量閾値）を超過した場合、管理サーバ１０２に通知（警告）を出す。通知を受領した管理サーバ１０２は、プールの容量を増やす処理を行う。本実施例では、論理使用量閾値及び実使用量閾値は８０％とする。つまり、プールの論理使用量がプールの論理容量の８０％を超過した場合、またはプールの実使用量がプールの実容量の８０％を超過した場合に、ストレージシステム１０４が管理サーバ１０２に警告を出す。

プールの論理使用量がプールの論理容量の８０％を超過した場合、管理サーバ１０２はそのプールの状態６０６に“論理使用量閾値超過”を表示する。またプールの実使用量がプールの実容量の８０％を超過した場合に、管理サーバ１０２はそのプールの状態６０６に“実使用量閾値超過”を表示する。なお、これは一例であり、閾値は８０％以外の値でも良い。また論理使用量閾値と実使用量閾値が、それぞれ異なる値であってもよい。

また本実施例に係るストレージシステム１０４では、プールに属するある圧縮ＲＧの実使用量が所定の閾値を超過した場合、その圧縮ＲＧ内のデータの一部を、プール内の別のＲＡＩＤグループへと移動（再配置）する。この所定の閾値は、プールの使用量（実使用量または論理使用量）の閾値と異なっていても同じでも良い。本実施例ではこの所定の閾値も８０％とするが、この閾値として８０％以外の値が用いられてもよい。

なお、ストレージシステム１０４は、プール容量管理ＧＵＩ６００’に表示される内容のうち、プールＩＤ６０５、状態６０６、論理容量６０７、論理使用量６０８、実容量６０９、実使用量６１０の情報を、プール管理テーブル６００に格納して管理している。

（５）ストレージシステムで実行されるプログラム
続いて、ストレージシステム１０４（のプロセッサ１１９）で実行される各種プログラムの説明を行う。ストレージシステム１０４では少なくとも、ホストライト処理プログラム８０２、圧縮ＲＧ監視プログラム８０３、デステージ処理プログラム８０４、枯渇回避再配置処理プログラム８０５、ページ再配置処理プログラム８０６、プール容量拡張プログラム８０７、プール容量縮小プログラム８０８が実行される。以下ではこれらのプログラムの処理の流れを説明する。

なお、ストレージシステム１０４では、上にあげたプログラム以外のプログラムも実行される。先に述べたように、ストレージシステム１０４（のプロセッサ１１９）は、仮想ボリューム、ＲＡＩＤグループ、プール、論理デバイスを定義してこれらを管理するための管理情報を作成・維持する処理や、仮想ボリュームをホスト１０１に提供する処理を行うためのプログラムを実行する。また、ストレージシステム１０４がホスト１０１から仮想ボリュームに対するリード要求（リードコマンド）を受領した時には、プロセッサ１１９ではリード要求を処理するためのプログラム（ホストリード処理プログラム）が実行される。ただし、これらのプログラムによって行われる処理は公知の処理であるため、本明細書では説明を略す。

まず、ストレージシステム１０４が、ホスト１０１から仮想ボリュームに対するライト要求及びライトデータを受領した時の処理（ライト処理）の流れを、図１１を用いて説明する。ストレージシステム１０４にライト要求が到来すると、ホストライト処理プログラム８０２がプロセッサ１１９で実行される。ホスト１０１が発行するライト要求には、ライトデータの書き込み先仮想ボリュームの識別番号、及びライトデータの書き込み位置の情報（仮想ボリューム上のホストＬＢＡ及びデータ長）が含まれている。

ステップ８０２−１でホストライト処理プログラム８０２は、プール容量管理テーブル６００を参照しライト対象の仮想ボリュームの属するプールの実容量が枯渇しているか判定する。「実容量が枯渇している」とは、実容量と実使用量の差（空き容量）が０になり、プールにライトデータを書き込む領域（物理領域）がなくなった状態を意味する。なお、プールの実容量が枯渇している場合、論理容量が枯渇していることもあるし、論理容量が枯渇していない場合もある。

プールの実容量が枯渇している場合（ステップ８０２−１：Ｙ）、ホストライト処理プログラム８０２はホスト１０１にエラーを報告し（ステップ８０２−１０）、処理を終了する。プールの実容量が枯渇していない場合（ステップ８０２−１：Ｎ）、ホストライト処理プログラム８０２は、ステップ８０２−２を実行する。

ステップ８０２−２でホストライト処理プログラム８０２は、ライト要求に含まれる書き込み先位置の情報から、ライトデータの書き込み先となる仮想ページを特定する（仮想ページ番号を算出する）。

さらにステップ８０２−２では、ホストライト処理プログラム８０２は、ダイナミックマッピングテーブル７０１を参照することで、特定された仮想ページにページが割り当てられているか判定する。ダイナミックマッピングテーブル７０１の仮想ボリューム番号（７０１−２）及び仮想ページ＃（７０１−３）が、特定された仮想ページ番号と等しいレコードのページ＃（７０１−６）に有効な値（ＮＵＬＬでない値）が格納されている場合、特定された仮想ページにページが割り当てられていることを意味する。

特定された仮想ページにページが割り当てられていない場合（ステップ８０２−２：Ｎ）、ホストライト処理プログラム８０２はプール容量管理テーブル６００を参照し、ライト対象の仮想ボリュームの属するプールの論理容量が枯渇しているか判定する（ステップ８０２−３）。「論理容量が枯渇している」とは、論理容量と論理使用量の差（空き容量）が０になり、プールにライトデータを書き込む領域（ページ）がなくなった状態を意味する。プールの論理容量が枯渇している場合（ステップ８０２−３：Ｙ）、ホストライト処理プログラム８０２はホスト１０１にエラーを報告し（ステップ８０２−１０）、処理を終了する。プールの論理容量が枯渇していない場合（ステップ８０２−３：Ｎ）、次にステップ８０２−４が実行される。

ステップ８０２−４でホストライト処理プログラム８０２は、未使用のページを選択し、選択されたページをライト対象仮想ページに割り当てる。ここでは具体的には、ホストライト処理プログラム８０２はＬＰ変換テーブル７０２に記録されているページの情報（プールボリューム番号（７０２−１）、ページ＃（７０２−２）のセット）のうち、ダイナミックマッピングテーブル７０１にまだ登録されていないページの情報を１つ選択する。そしてホストライト処理プログラム８０２は選択されたページの情報を、ダイナミックマッピングテーブル７０１内の、ライト対象仮想ページに対応するレコードに記録する。またページが仮想ページに割り当てられることで、プールの使用量（論理使用量）が変化するので、ホストライト処理プログラム８０２はプール容量管理テーブル６００の内容も更新する。

ステップ８０２−４の実行後、ホストライト処理プログラム８０２はプール容量管理テーブル６００を参照し、ライト対象の仮想ボリュームの属するプールの論理使用量が閾値を超過していないか判定する（ステップ８０２−５）。プールの論理使用量が閾値を超過している場合（ステップ８０２−５：Ｙ）、ホストライト処理プログラム８０２は管理サーバ１０２に、プールの論理使用量が閾値を超過している旨を通知する（ステップ８０２−６）。なお、管理サーバ１０２には、警告と共に、実使用量が閾値を超過しているプールの識別番号も通知される。プールの論理使用量が閾値を超過していない場合（ステップ８０２−５：Ｎ）には、ステップ８０２−６は行われない。

ページの割り当て（ステップ８０２−４）が実行されることで、ライト対象データの格納先記憶デバイス（１または複数）が一意に特定される。ステップ８０２−７では、ホストライト処理プログラム８０２はライト対象データの格納される記憶デバイスから、記憶デバイスの実容量と実使用量を取得し、ライト対象データの格納される記憶デバイスの空き実容量（実容量と実使用量の差）を計算する。ライト対象データが大きく、複数の記憶デバイスに格納される場合、ホストライト処理プログラム８０２はこれら複数の記憶デバイスごとに、空き実容量を算出する。またホストライト処理プログラム８０２は、キャッシュメモリ１１０上の各ダーティデータ（キャッシュメモリ１１０上のデータのうちまだ記憶デバイスにデータ書き込みが行われていないデータ）の書き込み先記憶デバイスを特定し、さらにライト対象データの格納される記憶デバイスごとのダーティデータの量を算出する。

ライト対象データの格納される記憶デバイスの空き実容量が、その記憶デバイスに書き込まれるべきダーティデータ量以下である場合、全てのダーティデータを記憶デバイスに書き込めないことがある。たとえば圧縮によりデータサイズが殆ど変わらなかった場合、このような事態が発生し得る。そのためこの場合（ステップ８０２−７：Ｙ）、ホストライト処理プログラム８０２は、ライト対象データの格納される記憶デバイスの空き実容量が、その記憶デバイスに書き込まれるべきダーティデータ量より大きくなるまで、ライト対象データのストレージシステム１０４（キャッシュメモリ１１０）への格納を行わない。

又、ホストライト処理プログラム８０２はステップ８０２−７の処理において、空き実容量とダーティデータの量を、記憶デバイスごとではなく、ＲＡＩＤグループごとに算出しても良い。

ステップ８０２−７の判定が肯定的である場合、ホストライト処理プログラム８０２は一定時間処理をＳｌｅｅｐする（ステップ８０２−８）。ステップ８０２−７とステップ８０２−８の処理をあわせて流入制限と呼ぶ。ステップ８０２−８で処理を停止している間に、ホストライト処理プログラム８０２とは独立に実行されるデステージ処理プログラム８０４がキャッシュメモリ１１０上のダーティデータを記憶デバイスに格納することがある。そうすると、ダーティデータ量が減るので、ホストライト処理プログラム８０２が再度ステップ８０２−７の判定をした際に、流入制限不要となり、ホスト１０１のライト要求を受け付けることが出来る。

ステップ８０２−９では、ホストライト処理プログラム８０２はホスト１０１にタイムアウトエラーを返却すべき時間に達したか否かを判定する。ステップ８０２−８によるＳｌｅｅｐが複数回発生した結果、ステップ８０２−９の判定が肯定的になった場合、ホストライト処理プログラム８０２はホスト１０１にエラーを報告する（ステップ８０２−１０）。ステップ８０２−９の判定が否定的である場合、ホストライト処理プログラム８０２は再びステップ８０２−７を実行する。

ステップ８０２−７の判定が否定的である場合、つまりライト対象データの格納される記憶デバイスの空き実容量が、その記憶デバイスに書き込まれるべきダーティデータ量より大きいため流入制限不要である場合、ステップ８０２−１１が実行される。ホストライト処理プログラム８０２はステップ８０２−１１で、ライト対象データを格納するためのキャッシュメモリ１１０の領域を確保し、ステップ８０２−１２で、確保されたキャッシュメモリ１１０上の領域に、ライト対象データを格納する。なおステップ８０２−１２では、ホストライト処理プログラム８０２はＲＡＩＤグループのパリティの生成も行う。またステップ８０２−１１では、ホストライト処理プログラム８０２はパリティを格納するためのキャッシュメモリ１１０上領域も確保し、ステップ８０２−１２では生成したパリティをキャッシュメモリ１１０に格納する。

その後ホストライト処理プログラム８０２は、ホスト１０１にライト処理が正常に完了した旨を応答し（ステップ８０２−１３）、処理を終了する。なお、ステップ８０２−７、ステップ８０２−８、ステップ８０２−９が実施されるのは、ライト対象データの格納されるページが圧縮対応ドライブ１１３で構成されている場合のみである。ライト対象データの格納されるページが圧縮対応ドライブ１１３で構成されていない場合には、ステップ８０２−７、ステップ８０２−８、ステップ８０２−９が実施されない。また、上ではステップ８０２−１２でパリティの生成が行われる例を説明したが、別の実施形態として、ステップ８０２−１３の後でパリティの生成が行われてもよい。

本実施例に係るストレージシステム１０４は、キャッシュメモリ１１０をいわゆるライトバックキャッシュとして用いる。そのためキャッシュメモリ１１０に格納されたライト対象データが記憶デバイスに格納されていない時点で、ホスト１０１に応答が返却される（ステップ８０２−１３）。ステップ８０２−１２でキャッシュメモリ１１０に書き込まれたライト対象データは、ホストライト処理プログラム８０２とは独立に実行されるデステージ処理プログラム８０４によって、記憶デバイスに書き込まれる。キャッシュメモリ１１０上のデータを記憶デバイスに書き込む処理のことをデステージ処理と呼ぶ。ストレージシステム１０４では、デステージ処理プログラム８０４が実行されることで、デステージ処理が行われる。プロセッサ１１９は一定周期で（たとえば１０分に１回など）、デステージ処理プログラム８０４を実行する。

図１２を用いて、デステージ処理プログラム８０４によって行われる処理の流れを説明する。デステージ処理プログラム８０４が開始されると、デステージ処理プログラム８０４はキャッシュメモリ１１０上にダーティデータがあるか判定し、ダーティデータがない場合には（ステップ８０４−１：Ｎ）、デステージ処理プログラム８０４は処理を終了する。

ダーティデータがある場合には（ステップ８０４−１：Ｎ）、デステージ処理プログラム８０４は、そのダーティデータの書き込まれる記憶デバイス、およびその記憶デバイス上の書き込み先アドレスを特定する（ステップ８０４−２）。ストレージシステム１０４は、ホスト１０１からのライトデータをキャッシュメモリ１１０に格納する時に、そのライトデータ（ダーティデータ）の書き込み先位置の情報（ホストＬＢＡあるいはページ番号等、データの書き込み先の記憶デバイスを一意に特定可能な情報）もキャッシュメモリ１１０あるいは共有メモリ１１１に格納している。ステップ８０４−２では、この情報を用いて、ダーティデータの書き込み先アドレスを特定する。

そしてデステージ処理プログラム８０４は、算出したアドレスにダーティデータを書き込む（ステップ８０４−３）。ダーティデータが多量にある場合、デステージ処理プログラム８０４は、ステップ８０４−１〜ステップ８０４−３を繰り返し実施し、ダーティデータがなくなった時点で（ステップ８０４−１：Ｎ）、処理を終了する。

（６）圧縮対応ドライブに対する処理
続いて圧縮ＲＧ監視プログラム８０３が実行する処理の流れを、図１３を用いて説明する。圧縮ＲＧ監視プログラム８０３は、プールの実使用量、プールに属するＲＡＩＤグループの実使用量を算出するためのプログラムである。圧縮ＲＧ監視プログラム８０３は定期的に起動される。また圧縮ＲＧ監視プログラム８０３は、ストレージシステム１０４に定義されているプールごとに実行される。以下、特定の１つのプールについて実行される圧縮ＲＧ監視プログラム８０３の処理の流れを説明する。

圧縮ＲＧ監視プログラム８０３が起動されると、圧縮ＲＧ監視プログラム８０３はプールに属する圧縮ＲＧのうち、ステップ８０３−４の処理をまだ行っていない圧縮ＲＧがあるか判定する（ステップ８０３−１）。ステップ８０３−４の処理をまだ行っていない圧縮ＲＧがある場合（ステップ８０３−１：Ｙ）、圧縮ＲＧ監視プログラム８０３はステップ８０３−４の処理をまだ行っていない圧縮ＲＧを１つ選択する。

ステップ８０３−２で、圧縮ＲＧ監視プログラム８０３はＬＰ変換テーブル７０２を参照することで、選択された圧縮ＲＧを構成する各圧縮対応ドライブ１１３を特定する。そして圧縮ＲＧ監視プログラム８０３は、特定された記憶デバイスのうち、ステップ８０３−３の処理がまだ行われていない記憶デバイスがあるか判定する。

ステップ８０３−３の処理がまだ行われていない記憶デバイスがある場合（ステップ８０３−２：Ｙ）、圧縮ＲＧ監視プログラム８０３はその圧縮対応ドライブ１１３に容量情報の取得要求を発行することで、各圧縮対応ドライブ１１３から容量情報を取得する（ステップ８０３−３）。圧縮対応ドライブ１１３は、圧縮ＲＧ監視プログラム８０３（が実行されるプロセッサ１１９）から容量情報の取得要求を受領すると、プロセッサ１１９に容量情報を返却する。

圧縮対応ドライブ１１３が返却する容量情報とは、論理アドレス空間４００上のセグメントにマッピングされている、物理領域のサイズ（割り当てたコードワードのサイズの総和）である。圧縮対応ドライブ１１３が容量情報の取得要求を受領すると、セグメントにマッピングされている物理領域のサイズの情報を、論理アドレス空間４００上全セグメントについて返却する（セグメントに物理アドレス空間４５０上領域が割り当てられていない場合、そのセグメントにマッピングされている物理領域のサイズは０ＫＢという情報が返却される）。

圧縮ＲＧ監視プログラム８０３は、圧縮対応ドライブ１１３から返却された容量情報と、ＬＰ変換テーブル７０２、ダイナミックマッピングテーブル７０１を用いて、圧縮ＲＧの実使用量を算出し、圧縮ＲＧ容量情報管理テーブル７０３の内容を更新する（ステップ８０３−４）。プールに属する全ての圧縮ＲＧについて、ステップ８０３−２〜８０３−４の処理が行われると（ステップ８０３−１：Ｎ）、圧縮ＲＧ監視プログラム８０３は、プール管理テーブル６００の実使用量６１０及び実容量６０２の情報を更新する（ステップ８０３−５）。

ステップ８０３−４及びステップ８０３−５で行われる処理、特に実使用量の算出方法を概説する。ステップ８０３−４では、まず圧縮ＲＧ監視プログラム８０３は圧縮ＲＧに含まれるＬＤＥＶのうちプールＶＯＬであるＬＤＥＶを特定する。これはＬＰ変換テーブル７０２に登録されている、プールボリューム番号（７０２−１）とＲＧ番号（７０２−３）の組を参照することで判明する。また圧縮ＲＧ監視プログラム８０３は、特定されたＬＤＥＶ内の各ページが、記憶デバイス上のどの位置（アドレス）に配置されているか特定する。これは各ページについて、ＬＰ変換テーブル７０２のドライブ番号（７０２−４）と開始アドレス（７０２−５）を参照することで判明する。ここで得られた情報とダイナミックマッピングテーブル７０１と、ステップ８０３−３で得られた容量情報とを用いることで、圧縮ＲＧ内の使用中ページにマッピングされている、物理領域の合計サイズ（つまり圧縮ＲＧの実使用量）を得ることができる。

ステップ８０３−５でも、圧縮ＲＧ監視プログラム８０３は上で説明した方法と同様の方法で、プール内の使用中ページにマッピングされている物理領域の合計サイズ（プールの実使用量）を得ることができる。

プールの実使用量及びプールに属する圧縮ＲＧの実使用量の算出後、圧縮ＲＧ監視プログラム８０３はプール実使用量が閾値を超過しているか判定する。閾値を超過している場合（ステップ８０３−６：Ｙ）、圧縮ＲＧ監視プログラム８０３は、プール管理テーブル６００の状態６０６を“実使用量閾値超過”に変更し、また管理サーバ１０２にプールの実使用量が閾値を超過している旨の警告を出す（ステップ８０３−７）。なお、管理サーバ１０２には、警告と共に、実使用量が閾値を超過しているプールの識別番号も通知される。閾値を超過していない場合には（ステップ８０３−６：Ｎ）、ステップ８０３−７は行われない。

続いて圧縮ＲＧ監視プログラム８０３は、プールに属する圧縮ＲＧのうち実使用量が閾値を超過している圧縮ＲＧがあるか判定する。閾値を超過している圧縮ＲＧがある場合（ステップ８０３−８：Ｙ）、圧縮ＲＧ監視プログラム８０３はその圧縮ＲＧの再配置要求ビット（７０３−５）を“１”にし、閾値を超過していない圧縮ＲＧについては（ステップ８０３−８：Ｎ）、圧縮ＲＧ監視プログラム８０３はその圧縮ＲＧの再配置要求ビット（７０３−５）を“０”にし、処理を終了する。

続いて、枯渇回避再配置処理プログラム８０５が実行する処理の流れを、図１４を用いて説明する。枯渇回避再配置処理プログラム８０５は、定期的に起動される。

枯渇回避再配置処理プログラム８０５が起動されると、枯渇回避再配置処理プログラム８０５は圧縮ＲＧ容量情報管理テーブル７０３を参照することで、再配置要求ビット（７０３−５）が“１”の圧縮ＲＧがあるか判定する。再配置要求ビット（７０３−５）が“１”の圧縮ＲＧがない場合（ステップ８０５−１：Ｎ）、枯渇回避再配置処理プログラム８０５は処理を終了する。再配置要求ビット（７０３−５）が“１”の圧縮ＲＧがある場合（ステップ８０５−１：Ｙ）、枯渇回避再配置処理プログラム８０５は再配置要求ビット（７０３−５）が“１”の圧縮ＲＧのページ内データを別のＲＡＩＤグループに移動する処理を行う。以下、再配置要求ビット（７０３−５）が“１”の圧縮ＲＧのことを、「対象ＲＧ」と呼ぶ。

再配置要求ビット（７０３−５）が“１”の圧縮ＲＧがある場合（ステップ８０５−１：Ｙ）、枯渇回避再配置処理プログラム８０５は対象ＲＧの中で１つのページを選択する。選択されるページは、仮想ページにマッピングされているページであれば任意のページで良い。あるいは別の実施形態として、枯渇回避再配置処理プログラム８０５はアクセス頻度の低いページを選択してもよい。圧縮対応ドライブ１１３が高速なフラッシュメモリ等を用いたＳＳＤで、ドライブ１１４がＳＳＤよりも低速なＨＤＤである場合、ユーザは圧縮対応ドライブ１１３で構成されるＲＡＩＤグループに属するページとドライブ１１４で構成されるＲＡＩＤグループに属するページが混在するプール定義することもできる。そのようなプールを階層プールと呼ぶ。階層プールが用いられる場合、ストレージシステム１０４はホスト１０１からのリード／ライト要求の頻度をページごとにカウントした結果を共有メモリ１１１にリード／ライト頻度情報として保持し、リード／ライト頻度に応じてページを移動させるプログラムを実行する。階層プールの中から枯渇回避再配置処理プログラム８０５がページを選択する場合、リード／ライト頻度情報を参照し、圧縮対応ドライブ１１３で構成されるＲＡＩＤグループに属するページの中で、リード／ライト頻度が低いページを選択しても良い。

続いて枯渇回避再配置処理プログラム８０５は、プール内に、ステップ８０５−２で選択されたページ内のデータを移動可能なＲＡＩＤグループが存在するか判定する（ステップ８０５−３）。具体的には枯渇回避再配置処理プログラム８０５は、ダイナミックマッピングテーブル７０１、ＬＰ変換テーブル７０２を参照することで、未使用ページを有するＲＡＩＤグループがあるか判定し、そのようなＲＡＩＤグループがある場合、そのＲＡＩＤグループはデータを移動可能なＲＡＩＤグループと判断する。

データを移動可能なＲＡＩＤグループが存在しない場合（ステップ８０５−３：Ｎ）、枯渇回避再配置処理プログラム８０５は処理を終了する。データを移動可能なＲＡＩＤグループが存在する場合（ステップ８０５−３：Ｙ）、枯渇回避再配置処理プログラム８０５はページ再配置処理プログラム８０６を呼び出して、ステップ８０５−２で選択されたページ内のデータの移動を行う（ステップ８０５−４）。ステップ８０５−４の詳細は後述する。

ステップ８０５−４の後、枯渇回避再配置処理プログラム８０５は対象ＲＧの実使用量を再計算し、圧縮ＲＧ容量情報管理テーブル７０３の内容を更新する。これはたとえば、ステップ８０３−３、ステップ８０３−４と同様の処理を行えば良い。その結果、対象ＲＧの実使用量が閾値を下回っている場合（ステップ８０５−５：Ｎ）、枯渇回避再配置処理プログラム８０５は処理を終了する。対象ＲＧの実使用量が閾値を下回っていない場合（ステップ８０５−５：Ｙ）、枯渇回避再配置処理プログラム８０５はステップ８０５−２から処理を繰り返す。

続いてステップ８０５−４の処理の流れを、図１５を用いて説明する。図１５はページ再配置処理プログラム８０６が実行する処理のフローチャートである。

ページ再配置処理プログラム８０６は最初に、データの移動先ページを選択する（ステップ８０６−１）。具体的にはページ再配置処理プログラム８０６は、ステップ８０５−２で選択されたページが属するプールと同じプールに属しているプールＶＯＬの中から、未使用のページを１つ選択する。ただしここで選択されるページを有するプールＶＯＬは、ステップ８０５−２で選択されたページが属しているＲＡＩＤグループ以外のＲＡＩＤグループに含まれれているものでなければならない。

ステップ８０６−２ではページ再配置処理プログラム８０６は、ステップ８０５−２で選択されたページのデータがキャッシュメモリ１１０に格納されているか判定する。ステップ８０５−２で選択されたページのデータがキャッシュメモリ１１０に格納されていない場合（ステップ８０６−２：Ｎ）、ページ再配置処理プログラム８０６はキャッシュメモリ１１０上に１ページ分の領域を確保し（ステップ８０６−３）、ステップ８０５−２で選択されたページのデータを記憶デバイスから読み出して、確保された領域に格納する（ステップ８０６−４）。

ステップ８０６−４の後、あるいはステップ８０５−２で選択されたページのデータがキャッシュメモリ１１０に格納されていた場合（ステップ８０６−２：Ｙ）、ページ再配置処理プログラム８０６はステップ８０５−２で選択されたページのデータを、ステップ８０６−１で選択したページ（記憶デバイス）に書き込み、ダイナミックマッピングテーブル７０１とＬＰ変換テーブル７０２の更新を行う（ステップ８０６−５）。ステップ８０６−５が終了すると、ページ再配置処理プログラム８０６は処理を終了する。

ステップ８０５−２で選択されたページのマッピング先が、仮想ボリューム番号＝ｎ、仮想ページ番号＝ｍで、ステップ８０６−１で選択したページのページ番号がｋ、またこのページが属する論理デバイス（プールボリューム）の識別番号がｊの場合の例を説明する。この場合ステップ８０６−５では、ダイナミックマッピングテーブル７０１の仮想ボリューム番号（７０１−２）がｎ、仮想ページ＃（７０１−３）がｍの行のプールボリューム番号（７０１−５）にｊを、ページ＃（７０１−６）にｋを格納する処理が行われる。

なお、上では、ステップ８０６−４で読み出されたデータが即座にステップ８０６−５で記憶デバイスに書き込まれる例を説明したが、ステップ８０６−５ではデータを記憶デバイスに書き込まずにキャッシュメモリ１１０に保持したままでも良い。ただしその場合、キャッシュメモリ１１０上に保持されたデータは、後でデステージされる必要がある。そのため、ストレージシステム１０４はキャッシュメモリ１１０上に保持された移動対象のデータを、ダーティデータとして管理しておく必要がある。

（７）管理サーバにおける容量管理
続いて、ストレージシステム１０４から警告を通知された管理サーバ１０２が実施する処理の流れを説明する。管理サーバ１０２では少なくとも、プール容量管理プログラム９０１、プールＶＯＬ構成最適化プログラム９０２、プール容量拡張自動化プログラム９０３が実行される。プール容量管理プログラム９０１は、ストレージシステム１０４から論理使用量または実使用量が閾値を超過した旨の警告（通知）を受領すると、実行される。プールＶＯＬ構成最適化プログラム９０２、プール容量拡張自動化プログラム９０３はそれぞれ、プール容量管理プログラム９０１から呼び出されるプログラムである。図１６は管理サーバ１０２で実行されるプール容量管理プログラム９０１のフローチャートである。

プール容量管理プログラム９０１は、ストレージシステム１０４から論理使用量または実使用量が閾値を超過した旨の警告（通知）を受領すると（ステップ９０１−１）、ステップ９０１−２以降の処理を行う。ステップ９０１−１で受領する警告は、先に説明したステップ８０２−６、ステップ８０３−７がストレージシステム１０４で実行されることで、管理サーバ１０２に通知される。また受領する警告とともに、（実使用量または論理使用量の）閾値を超過しているプールの識別番号も通知されるので、プール容量管理プログラム９０１はステップ９０１−２以降で、通知された識別番号で特定されるプールについて、論理容量または実容量の拡張などの処理を行う。

ステップ９０１−１で受領した警告が、プール実使用量が閾値を超過している旨の警告である場合（ステップ９０１−２：Ｙ）、プール容量管理プログラム９０１はストレージシステム１０４から、ストレージシステム１０４が有する管理情報を取得し、取得した管理情報を基に拡張すべき実容量（以下、「実容量増分」と呼ぶ）を算出する（ステップ９０１−３）。管理情報にはプール管理テーブル６００の他、上で説明した論理物理アドレス変換テーブル７０２、圧縮ＲＧ容量情報管理テーブル７０３、ストレージシステム１０４が有する全ＬＤＥＶ、全ＲＡＩＤグループの構成情報が含まれる。

また、ステップ９０１−３における実容量増分の算出方法の一例は以下の通りである。プール容量管理プログラム９０１は、少なくとも実容量閾値超過状態が解消されるだけの実容量を、実容量増分として算出する。たとえばプール実使用量が閾値を超過している時点におけるプール実容量をＣ、実使用量をＵ、閾値をＴ％、実容量増分をΔＣとする。この場合、プール実使用量が閾値を下回るようにするためには、プール実容量（Ｃ＋ΔＣ）は以下の式（２）を満たすべきである。
［数２］
（Ｃ＋ΔＣ）×Ｔ÷１００＞Ｕ ・・・・（２）

上記の式から、プール容量管理プログラム９０１は、以下の式（３）
［数３］
ΔＣ＞Ｕ×１００÷Ｔ−Ｃ・・・・（３）
を満たすように実容量増分ΔＣを決定する。例えば、Ｃ＝１００、Ｕ＝９０、Ｔ＝８０％とすると、ΔＣ＞１２．５となる。

続いてプール容量管理プログラム９０１はプール容量拡張自動化プログラム９０３を呼び出すことで、ストレージシステム１０４にプール容量の拡張を指示する（ステップ９０１−４）。ステップ９０１−４で行われる処理の詳細は後述する。ステップ９０１−２の判定が否定的だった場合には、ステップ９０１−３、９０１−４は行われない。

ステップ９０１−１で受領した警告が、プール論理使用量が閾値を超過している旨の警告である場合（ステップ９０１−５：Ｙ）、プール容量管理プログラム９０１はストレージシステム１０４から、ストレージシステム１０４が有する管理情報を取得し、拡張すべき論理容量（以下、「論理容量増分」と呼ぶ）を算出する（ステップ９０１−６）。なお、ステップ９０１−６で算出される論理容量増分も、実容量増分の算出方法と同様の考え方で求められる。つまりプール容量管理プログラム９０１は、少なくとも論理容量閾値超過状態が解消されるだけの論理容量を、論理容量増分として算出する。

そしてプール容量管理プログラム９０１はプール容量拡張自動化プログラム９０３を呼び出すことで、ストレージシステム１０４にプールの論理容量の拡張を指示する（ステップ９０１−７）。なお、ステップ９０１−４の実行時及びステップ９０１−７の実行時のいずれも、プール容量拡張自動化プログラム９０３が呼び出される。プール容量拡張自動化プログラム９０３が行う処理の詳細は後述する。またステップ９０１−５の判定が否定的だった場合には、ステップ９０１−６、ステップ９０１−７は行われない。

最後にプール容量管理プログラム９０１は、プールＶＯＬ構成最適化プログラム９０２を呼び出すことで、プールボリュームの最適化を行う（ステップ９０１−８）。ステップ９０１−８が終了すると、プール容量管理プログラム９０１は処理を終了する。プールＶＯＬ構成最適化プログラム９０２で行われる処理の詳細は後述する。

次に、ステップ９０１−４またはステップ９０１−７で実行される処理、つまりプール容量拡張自動化プログラム９０３が行う処理のフローを、図１７を用いて説明する。

プール容量拡張自動化プログラム９０３は、ステップ９０１−３またはステップ９０１−６で求められた増分（実容量増分または論理容量増分）を満たすことができる未使用ＬＤＥＶが存在するか判定する（ステップ９０３−１）。ここでの「未使用ＬＤＥＶ」とは、プールに属しておらず、且つホスト１０１からリード／ライト可能な状態になっていない（ＩＯパスが定義されていない）ＬＤＥＶを意味する。そのためプール容量拡張自動化プログラム９０３は、ストレージシステム１０４から取得した管理情報を参照することで、実容量増分または論理容量増分に相当する量の未使用ＬＤＥＶが存在するか判定する。

まず、実容量増分に相当する量の未使用ＬＤＥＶが存在するか否かの判定方法を説明する。プール容量拡張自動化プログラム９０３は、ステップ９０１−３またはステップ９０１−６でストレージシステム１０４から取得した管理情報を参照することで、未使用ＬＤＥＶの候補を抽出し、それをもとに判定を行う。

ドライブ１１４（つまり圧縮機能を持たない記憶デバイス）から構成されるＲＡＩＤグループに属しているＬＤＥＶをプールに追加する場合、どのＬＤＥＶをプールに追加しても、プールの実容量はＬＤＥＶの論理容量に相当する分だけ増加する。そのため、ドライブ１１４から構成されるＲＡＩＤグループに属している、全ての未使用ＬＤＥＶの論理容量の合計が実容量増分と同じかそれ以上あれば、実容量増分に相当する量の未使用ＬＤＥＶが存在するといえる。

一方、圧縮ＲＧの中から未使用ＬＤＥＶを選択する場合、以下の二条件を満たす圧縮ＲＧから選択されなければならない。
ａ）圧縮ＲＧの有するプールＶＯＬの論理容量の合計と、今回選択される未使用ＬＤＥＶの論理容量の和が、圧縮ＲＧの実容量より小さいこと、
ｂ）圧縮ＲＧの有するプールＶＯＬが、今回処理対象のプール以外のプールに属していないこと

上の条件ａ）に該当しない圧縮ＲＧ、つまり圧縮ＲＧの有するプールＶＯＬの論理容量の合計が、圧縮ＲＧの実容量を超過している圧縮ＲＧから未使用ＬＤＥＶを選択してプールに追加しても、プールの実容量は増加しない（これは先に述べた、プールの実容量の定義から明らかである）。また上の条件ｂ）に該当しない圧縮ＲＧの未使用ＬＤＥＶは、今回処理対象のプールに追加できないという制約がある。そのため、本実施例に係るストレージシステム１０４は、上の条件ａ）及びｂ）を満たす圧縮ＲＧから未使用ＬＤＥＶを選択する。

また、この条件を満たす圧縮ＲＧから選択された未使用ＬＤＥＶをプールに追加した場合、追加された未使用ＬＤＥＶの論理容量の分だけ、プールの実容量は増加する。そのため、上の条件ａ）及びｂ）を満たす圧縮ＲＧの中から選択された未使用ＬＤＥＶの論理容量の合計が実容量増分以上である場合、実容量増分に相当する量の未使用ＬＤＥＶが存在するといえる。

以上の考え方に基づいて、プール容量拡張自動化プログラム９０３はステップ９０３−１の判定を行う。つまりプール容量拡張自動化プログラム９０３は、実容量閾値超過状態の場合は、ドライブ１１４から構成されるＲＡＩＤグループに属している未使用ＬＤＥＶの論理容量の合計と、圧縮ＲＧの中から選択された未使用ＬＤＥＶの論理容量合計の和を算出する。そしてこれが実容量増分（ΔＣ）以上である場合（９０３−１：Ｙ）、プール容量拡張自動化プログラム９０３はステップ９０３−７を実行する。ステップ９０３−１の判定が否定的な場合、プール容量拡張自動化プログラム９０３はステップ９０３−２を実行する。

論理容量増分に相当する未使用ＬＤＥＶが存在するか否かの判定方法は、実容量増分に相当する未使用ＬＤＥＶの存在有無判定よりは易しい。この場合は、プール容量拡張自動化プログラム９０３は、任意の未使用ＬＤＥＶの論理容量の合計が論理容量増分以上であるか判定すればよい。

実容量増分または論理容量増分に相当する量の未使用ＬＤＥＶが存在しなかった場合（ステップ９０３−１：Ｎ）、プール容量拡張自動化プログラム９０３は、ストレージシステム１０４内に新たにＬＤＥＶを定義可能か判定する（ステップ９０３−２）。先に述べたとおり、ＲＡＩＤグループには１以上のＬＤＥＶを定義可能である。またＲＡＩＤグループ内に、ＬＤＥＶとして定義されていない領域が残っていることがある。ステップ９０３−２では、そのような領域が存在するか、かつその領域の合計サイズが、実容量増分または論理容量増分以上存在するか判定される。

新たにＬＤＥＶを定義可能である場合（ステップ９０３−２：Ｙ）、プール容量拡張自動化プログラム９０３は、プール容量を拡張するためにＬＤＥＶを新規に作成することが可能である旨をユーザに通知するとともに、及び新規ＬＤＥＶの作成を許可するかユーザに確認する（ステップ９０３−３）。具体的にはプール容量拡張自動化プログラム９０３は、管理サーバ１０２のディスプレイに、新規ＬＤＥＶの作成を許可するか否かを選択させるＧＵＩ画面を表示する。

ユーザが新規ＬＤＥＶの作成を許可した場合（ステップ９０３−４：Ｙ）、プール容量拡張自動化プログラム９０３は新規ＬＤＥＶを作成する指示をストレージシステム１０４に発行する（ステップ９０３−５）。この指示を受領したストレージシステム１０４は、新規ＬＤＥＶの作成を行う。又、ステップ９０３−３及びステップ９０３−４は無くてもよい。すなわちプール容量拡張自動化プログラム９０３がユーザの許可を得ることなく、自動的に新規ＬＤＥＶを作成する指示を発行（ステップ９０３−５）しても良い。

ステップ９０３−２の判定が否定的だった場合、或いはステップ９０３−４でユーザが新規ＬＤＥＶの作成を許可しなかった場合、プール容量拡張自動化プログラム９０３は、ストレージシステム１０４に記憶デバイスを追加する必要がある旨のメッセージを管理サーバ１０２のディスプレイに出力し（ステップ９０３−６）、処理を終了する。

ステップ９０３−５の処理の後、あるいはステップ９０３−１の判定が肯定的だった場合、ステップ９０３−７が実行される。ステップ９０３−７では、プール容量拡張自動化プログラム９０３は、未使用ＬＤＥＶの中からプールに追加するＬＤＥＶを選択する。ステップ９０３−７でプール容量拡張自動化プログラム９０３が未使用ＬＤＥＶを選択する際の選択基準については後述する。

プール容量拡張自動化プログラム９０３は、プールに追加するＬＤＥＶを選択した後、選択したＬＤＥＶの一覧を管理サーバ１０２の画面に表示する（ステップ９０３−８）。またステップ９０３−８では、プール容量拡張自動化プログラム９０３は選択したＬＤＥＶをプールに追加して良いか、ユーザに確認する。

プール容量拡張自動化プログラム９０３が選択したＬＤＥＶのプールへの追加をユーザが許可した場合（ステップ９０３−９：Ｙ）、プール容量拡張自動化プログラム９０３は選択したＬＤＥＶの情報と、ＬＤＥＶを追加するプールの識別番号をストレージシステム１０４に送信し、ストレージシステム１０４は選択したＬＤＥＶをプールに追加する（ステップ９０３−１０）。プールにＬＤＥＶが追加されることで、プールの容量が変動するので、ストレージシステム１０４では、プールにＬＤＥＶを追加するとともに、プール管理テーブル６００、ＬＰ変換テーブル７０２、圧縮ＲＧ容量情報管理テーブル７０３の更新も行われる。ステップ９０３−１０が実行された時にストレージシステム１０４で行われる処理の詳細は後述する。ステップ９０３−１０の後、プール容量拡張自動化プログラム９０３は終了する。選択したＬＤＥＶのプールへの追加をユーザが許可しなかった場合（ステップ９０３−９：Ｎ）、プール容量拡張自動化プログラム９０３はステップ９０３−１０を実行せずに終了する。また、ステップ９０３−８及びステップ９０３−９は無くてもよい。すなわち、プール容量拡張自動化プログラム９０３はユーザの許可を得ることなくステップ９０３−１０を実行しても良い。

ステップ９０３−７でプール容量拡張自動化プログラム９０３が未使用ＬＤＥＶを選択する際の選択基準について、図１８及び図１９を用いて説明する。図１８には、プールの実容量を拡張する場合（ステップ９０１−４からプール容量拡張自動化プログラム９０３が呼び出された場合）に選択すべきＬＤＥＶの候補（以下、「候補ＬＤＥＶ」と呼ぶ）を選択する時のルール（条件）を、優先度の高い順に並べたテーブルが示されている。一方図１９には、プールの論理容量を拡張する場合（ステップ９０１−７からプール容量拡張自動化プログラム９０３が呼び出された場合）に候補ＬＤＥＶを選択する時のルール（条件）を、優先度の高い順に並べたテーブルが示されている。各カラム（９０３−９−Ａ２、９０３−９−Ｂ２、９０３−９−Ａ３、９０３−９−Ｂ３、９０３−９−Ａ４、９０３−９−Ｂ４）がルール（選択基準）を表している。

プール容量拡張自動化プログラム９０３が用いる各ルールについて説明する。プール容量拡張自動化プログラム９０３は、以下の選択基準を用いる。
（ａ）候補ＬＤＥＶの属するＲＡＩＤグループの属性（カラム９０３−９−Ａ２、９０３−９−Ｂ２）
（ｂ）候補ＬＤＥＶの属するＲＡＩＤグループに含まれる各ＬＤＥＶが所属するプール（カラム９０３−９−Ａ３、９０３−９−Ｂ３）
（ｃ）候補ＬＤＥＶの属するＲＡＩＤグループ内ＬＤＥＶのうち、プールＶＯＬであるＬＤＥＶの合計容量（カラム９０３−９−Ａ４、９０３−９−Ｂ４）

（ａ）の基準に関して、プール容量拡張自動化プログラム９０３は、候補ＬＤＥＶの属するＲＡＩＤグループが、圧縮対応ドライブ１１３から構成されたＲＡＩＤグループに属しているか否かによって、ＬＤＥＶを選択する。図１８（カラム９０３−９−Ａ２）及び図１９（カラム９０３−９−Ｂ２）が示す通り、プール容量拡張自動化プログラム９０３は、圧縮ＲＧに属するＬＤＥＶを優先的に選択する。

（ｂ）の基準に関して、プール容量拡張自動化プログラム９０３は以下のいずれかの条件（条件ｂ−１、ｂ−２）に合致するＬＤＥＶを候補ＬＤＥＶとして選択する。
（ｂ−１）容量拡張対象のプールに既に属しているＬＤＥＶ（プールＶＯＬ）と同一ＲＡＩＤグループに含まれているＬＤＥＶ
（ｂ−２）いずれのプールにも属していないＲＡＩＤグループに含まれるＬＤＥＶ

条件ｂ−１、ｂ−２のいずれにも当てはまらないＬＤＥＶ、たとえば既に他のプールに属するＬＤＥＶを含むＲＡＩＤグループ内のＬＤＥＶは、候補ＬＤＥＶとして選択されない。図１８（カラム９０３−９−Ａ３）及び図１９（カラム９０３−９−Ｂ３）が示す通り、プール容量拡張自動化プログラム９０３は、条件ｂ−１に該当するＬＤＥＶを、条件ｂ−２に該当するＬＤＥＶよりも優先的に、候補ＬＤＥＶとして選択する。

（ｃ）の基準に関しては、実容量を拡張する場合と論理容量を拡張する場合とで、プール容量拡張自動化プログラム９０３が選択する候補ＬＤＥＶは異なる。実容量を拡張する場合、プール容量拡張自動化プログラム９０３はＲＡＩＤグループ（圧縮ＲＧ）のうち、プールＶＯＬとして用いられているＬＤＥＶの合計容量（論理容量）が、ＲＡＩＤグループの実容量未満である圧縮ＲＧの中から、候補ＬＤＥＶを選択する。この条件に合致する圧縮ＲＧの中から候補ＬＤＥＶを選択しないと、プールの実容量を増加させることにならないためである。

一方、論理容量を拡張する場合は、プール容量拡張自動化プログラム９０３は、プールＶＯＬとして用いられているＬＤＥＶの合計容量（論理容量）が、ＲＡＩＤグループの実容量以上のＲＡＩＤグループから、候補ＬＤＥＶを優先的に選択する。論理容量を拡張する必要がある場合（図１６：ステップ９０１−７）は、既に実容量の拡張がなされており（ステップ９０１−４）、実容量の拡張の必要がないからである。

プール容量拡張自動化プログラム９０３は、上で説明した選択基準に従って、未使用ＬＤＥＶを選択する。また、実容量増分（または論理容量増分）以上の容量がプールに追加されなければならないので、複数の未使用ＬＤＥＶが選択されることもある。

次に、ステップ９０１−８で実行される処理、つまりプールＶＯＬ構成最適化プログラム９０２が行う処理のフローを、図２０を用いて説明する。プールＶＯＬ構成最適化プログラム９０２はプール容量管理プログラム９０１から呼び出される時、構成最適化を行う対象のプールのプールＩＤを指定される（引数として渡される）。プールＶＯＬ構成最適化プログラム９０２は指定されたプール（以下、このプールを「対象プール」と呼ぶ）について構成最適化を行う。

最初にプールＶＯＬ構成最適化プログラム９０２は、ストレージシステム１０４から構成情報を取得する（ステップ９０２−１）。ここで取得される構成情報は、ストレージシステム１０４の有するＬＤＥＶの容量（論理容量）、対象プールに属するＲＡＩＤグループの容量（論理容量、実容量、論理使用量、実使用量）の情報である。

続いてプールＶＯＬ構成最適化プログラム９０２は、対象プールに属する圧縮ＲＧのうち、ステップ９０２−３以降の処理が行われていない圧縮ＲＧを１つ選択する（ステップ９０２−２）。以降、図２０の説明の過程において、ここで選択された圧縮ＲＧを「対象ＲＧ」と呼ぶ。

ステップ９０２−３では、プールＶＯＬ構成最適化プログラム９０２はステップ９０２−２で選択された圧縮ＲＧの拡張率と圧縮率の逆数を算出する。ここで算出される拡張率とは、“ＲＡＩＤグループに属するプールＶＯＬの論理容量合計÷ＲＡＩＤグループの実容量”である。また圧縮率の逆数は、“ＲＡＩＤグループの実使用量÷ＲＡＩＤグループの論理使用量”である。なお、以下では圧縮率の逆数のことを“１／圧縮率”と表記することがある。

拡張率と１／圧縮率が等しく、かつ圧縮率が今後も変動しない場合、記憶デバイスの物理アドレス空間と論理アドレス空間が同じ割合で消費される。たとえば記憶デバイスの物理アドレス空間が全て消費された時（物理アドレス空間の全領域にデータが書き込まれた時）、論理アドレス空間も１００％消費された状態になる。そのため、論理容量と実容量の関係が理想的な状態にあるといえ、この場合には対象ＲＧの論理容量または実容量の調整は不要である。よって拡張率と１／圧縮率が等しい場合（ステップ９０２−３：＝）、プールＶＯＬ構成最適化プログラム９０２はステップ９０２−８に進む。

拡張率が１／圧縮率より大きい場合、理想的な状態に比べて、ＲＡＩＤグループの論理容量が過剰に存在すること、つまり物理領域の量が不足気味の状態にあることを意味する。そのような状態にあるＲＡＩＤグループの領域がプールＶＯＬとして使用されると、未使用のページはあるにもかかわらず、未使用の物理領域がないために、プールＶＯＬ（ＲＡＩＤグループ内の記憶領域）にデータを書き込めない状態が発生する。この場合、プールＶＯＬを削減することにより、拡張率と１／圧縮率の差を現状より少なくすることが望ましい（プールからプールＶＯＬを削除することで、削除されたプールＶＯＬの属するＲＡＩＤグループの拡張率が小さくなるからである）。

そのためプールＶＯＬ構成最適化プログラム９０２は、拡張率が１／圧縮率より大きい場合（ステップ９０２−３：＞）、対象プールから対象ＲＧに属するプールＶＯＬを削除することでＲＡＩＤグループの論理容量を削減する。プールＶＯＬ構成最適化プログラム９０２は、対象プールから削減すべきプールＶＯＬの論理容量を算出する（ステップ９０２−４）。ここで算出された論理容量を削減容量と呼ぶ。本実施例では、対象ＲＧに属するプールＶＯＬの論理容量合計と対象ＲＧの実容量／圧縮率の差を、削減容量とする。一例として、拡張率３００％、圧縮率５０％、実容量１０ＴＢのＲＡＩＤグループについて削減容量を求める場合の例を説明する。この場合、このＲＡＩＤグループ内のプールＶＯＬ論理容量合計は３０ＴＢで、ＲＡＩＤグループの実容量／圧縮率は２０ＴＢであるから、削減容量は３０ＴＢ−２０ＴＢ＝１０ＴＢである。

続いてステップ９０２−５では、プールＶＯＬ構成最適化プログラム９０２は、対象ＲＧから、削除対象のプールＶＯＬを選択する。ここでプールＶＯＬ構成最適化プログラム９０２は、選択されるプールＶＯＬの論理容量の合計がステップ９０２−４で算出された削減容量以上になるように、プールＶＯＬを選択する。またプールＶＯＬ構成最適化プログラム９０２が削除対象のプールＶＯＬを選択する際、論理使用量の小さいプールＶＯＬから優先的に選択する。これはプールＶＯＬをプールから削除する際、削除対象プールＶＯＬに格納されたデータを別のプールＶＯＬに移動（退避）させる必要があるからである。

例えば、ＬＤＥＶ１の論理容量が１１ＴＢ、論理使用量が５ＴＢ、ＬＤＥＶ２の論理容量が６ＴＢ、論理使用量が２ＴＢ、ＬＤＥＶ３の論理容量が５ＴＢ、論理使用量が１ＴＢの場合、ＬＤＥＶ１のみ選択しても、ＬＤＥＶ２とＬＤＥＶ３を選択しても、何れでも削減容量１０ＴＢを超えるが、ＬＤＥＶ２とＬＤＥＶ３を選択した方が論理使用量合計が少ない為（ＬＤＥＶ１は５ＴＢ，ＬＤＥＶ２とＬＤＥＶ３は合計で３ＴＢ）、プールに退避するデータ量が少なくなり、後のステップ９０２−１２の実行時間を短くすることが出来る。

一方、拡張率が１／圧縮率より小さい場合、ＲＡＩＤグループの実容量が理想的な状態よりも過剰に存在することを意味する。この場合には、ページを使い切っても、記憶デバイスの物理アドレス空間には未使用の物理領域が残っている状態になり得る。そのためこの時には、プールＶＯＬ構成最適化プログラム９０２は対象ＲＧの未使用ＬＤＥＶをプールに追加することで拡張率を増加させ、拡張率と１／圧縮率の差を今よりも少なくすることを試みる。

そのため拡張率が１／圧縮率より小さい場合（ステップ９０２−３：＜）、プールＶＯＬ構成最適化プログラム９０２は、対象プールに追加すべき論理容量を算出する（ステップ９０２−６）。追加すべき論理容量は、対象ＲＧの実容量／圧縮率と対象ＲＧに属するプールＶＯＬの論理容量合計との差から求められる。例えば拡張率２００％、圧縮率２５％、実容量１０ＴＢのＲＡＩＤグループを例にとって説明する。この場合、このＲＡＩＤグループ内のプールＶＯＬ論理容量合計は２０ＴＢ、実容量／圧縮率は４０ＴＢであるため、追加すべき論理容量は４０ＴＢ−２０ＴＢ＝２０ＴＢである。

続いてステップ９０２−７では、プールＶＯＬ構成最適化プログラム９０２は、対象ＲＧの中から対象プールに追加すべきＬＤＥＶを選択する。ここでプールＶＯＬ構成最適化プログラム９０２は、選択されるＬＤＥＶの論理容量の合計が、ステップ９０２−６で算出された追加すべき論理容量以上になるように、ＬＤＥＶを選択する。

ステップ９０２−５またはステップ９０２−７の終了後、プールＶＯＬ構成最適化プログラム９０２は、対象プールに属する全ての圧縮ＲＧについてステップ９０２−２〜ステップ９０２−７の処理を行ったか判定する。まだステップ９０２−２〜ステップ９０２−７の処理が行われていない圧縮ＲＧが残っている場合には（ステップ９０２−８：Ｎ）、プールＶＯＬ構成最適化プログラム９０２は再びステップ９０２−２から処理を行う。すべての圧縮ＲＧについて処理が行われている場合には（ステップ９０２−８：Ｙ）、ステップ９０２−９以降の処理が行われる。

ステップ９０２−８までの処理が行われた結果、プールから削除すべきプールＶＯＬが選択された場合（ステップ９０２−９：Ｙ）、プールＶＯＬ構成最適化プログラム９０２は、ステップ９０２−５で選択されたＬＤＥＶ（プールＶＯＬ）をプールから削除して良いか、ユーザに確認するための確認画面を管理サーバ１０２のディスプレイに表示する（ステップ９０２−１０）。ここでの表示例を図２１に示す。プールＶＯＬ構成最適化プログラム９０２は確認画面に、選択された削除候補ＬＤＥＶのＩＤ（識別番号）や容量を表示する（Ｂ９０２−１２）。また、図２１（Ｂ９０２−１２）に示されているように、確認画面には削除候補ＬＤＥＶのＲＡＩＤレベルや、使用されている記憶デバイスの種類が表示されてもよい。さらに選択されたＬＤＥＶを削除することの妥当性をユーザが判断できるように、プールＶＯＬ構成最適化プログラム９０２はプールからＬＤＥＶを削除した時の容量の予測値を算出して、確認画面に表示してもよい（Ｂ９０２−１１）。

プールＶＯＬ構成最適化プログラム９０２は、ユーザが確認画面上の“適用”ボタン（Ｂ９０２−１３）を押したことを確認すると（ステップ９０２−１１：Ｙ）、ストレージシステム１０４に削除候補ＬＤＥＶを対象プールから削除するよう指示する（ステップ９０２−１２）。ユーザが“キャンセル”ボタン（Ｂ９０２−１４）を押した場合には、（ステップ９０２−１１：Ｎ）、ステップ９０２−１２はスキップされる。なお、ステップ９０２−１０及びステップ９０２−１１は無くてもよい。つまりプールＶＯＬ構成最適化プログラム９０２はユーザの許可を得ずに、ステップ９０２−１２を実行しても良い。

また、ステップ９０２−８までの処理が行われた結果、プールに追加すべきＬＤＥＶが選択された場合（ステップ９０２−１３：Ｙ）、プールＶＯＬ構成最適化プログラム９０２は、ステップ９０２−７で選択されたＬＤＥＶをプールに追加して良いか、ユーザに確認するための確認画面を、管理サーバ１０２のディスプレイに表示する（ステップ９０２−１４）。ここでの表示例を図２２に示す。プールＶＯＬ構成最適化プログラム９０２は確認画面に、選択された追加候補ＬＤＥＶのＩＤ（識別番号）や容量を表示する（Ｂ９０２−１４）。また図２１と同様に、確認画面に削除候補ＬＤＥＶのＲＡＩＤレベルや、使用されている記憶デバイスの種類が表示されてもよい。

プールＶＯＬ構成最適化プログラム９０２は、ユーザが確認画面上の“適用”ボタンを押したことを確認すると（ステップ９０２−１５：Ｙ）、ストレージシステム１０４に追加候補ＬＤＥＶを対象プールに追加するよう指示する（ステップ９０２−１６）。ステップ９０２−１６の終了後、プールＶＯＬ構成最適化プログラム９０２の処理は終了する。一方ユーザが“キャンセル”ボタンを押した場合には、（ステップ９０２−１５：Ｎ）、プールＶＯＬ構成最適化プログラム９０２の処理は終了する。又、ステップ９０２−１１及びステップ９０２−１２は無くてもよい。プールＶＯＬ構成最適化プログラム９０２がユーザの許可を得ずに、ステップ９０２−１６を実行しても良い。

なお、上ではステップ９０２−３において、拡張率が１／圧縮率と等しい場合にプールＶＯＬ構成最適化プログラム９０２の処理が終了する例が説明された。ただし、拡張率が１／圧縮率と完全に一致するケースは少ないため、１／圧縮率が以下の式（４）
［数４］
（拡張率−α）≦１／圧縮率≦（拡張率＋α）・・・・（４）
を満たす場合（αは固定値で、拡張率よりも充分小さい値）に、プールＶＯＬ構成最適化プログラム９０２が処理を終了するようにしてもよい。

又、ステップ９０２−４において、ＲＡＩＤグループに属するプールＶＯＬ論理容量合計とＲＡＩＤグループの実容量／圧縮率の差を削減容量とすることを説明したが、以下の式（５）
［数５］
ＲＡＩＤグループ内プールＶＯＬ論理容量合計−ＲＡＩＤグループ実容量／（圧縮率＋β）・・・・（５）
で算出される値を削減容量としても良い（なお、βは所定の定数である）。すなわち削減容量を現在の圧縮率よりβだけ大きい圧縮率で算出し、現在の圧縮率から算出される理論値より小さくすることで、圧縮率が変動して物理領域がより多く消費された場合でも、ＲＡＩＤグループまたはプールの論理空き容量（論理容量と論理使用量の差）が足りなくなる事を防ぐことが出来る。

又、ステップ９０２−９において、ＲＡＩＤグループの実容量／圧縮率とＲＡＩＤグループの論理容量との差を、追加すべき論理容量とすることを説明したが、これも以下の式（６）
［数６］
ＲＡＩＤグループ実容量／（圧縮率ーγ）−ＲＡＩＤグループ内プールＶＯＬ論理容量合計・・・・（６）
を用いて算出されるようにしても良い（なお、γは所定の定数である）。すなわち追加すべき論理容量を現在の圧縮率よりγだけ小さい圧縮率で算出し、現在の圧縮率から算出される理論値より大きくすることで、より圧縮され実空き容量が増えた場合でも、ＲＡＩＤグループまたはプールの論理空き容量が足りなくなる事を防ぐことが出来る。

次に、管理サーバ１０２がステップ９０２−１３またはステップ９０３−１０を実行した時にストレージシステム１０４で行われる処理の流れを、図２３を用いて説明する。管理サーバ１０２がステップ９０２−１３またはステップ９０３−１０を実行すると、ストレージシステム１０４ではプール容量拡張プログラム８０７が起動され、プール容量拡張プログラム８０７によってプールへのＬＤＥＶ追加が行われる。またこの時、管理サーバ１０２からは拡張対象プールの識別番号、追加すべきＬＤＥＶの識別番号が通知される。

プール容量拡張プログラム８０７が開始されると、プール容量拡張プログラム８０７はまずＬＰ変換テーブル７０２にレコードの追加を行う（ステップ８０７−１）。もし管理サーバ１０２から通知されたＬＤＥＶ（追加すべきＬＤＥＶ）のサイズが、ｎページ分のサイズだった場合、プール容量拡張プログラム８０７はＬＰ変換テーブル７０２にｎレコード分のエントリを追加する。また各レコードのプールボリューム番号（７０２−１）、ページ＃（７０２−２）、ＲＧ番号（７０２−３）、ドライブ番号（７０２−４）、開始アドレス（７０２−５）に情報を登録する。

もし、プールに追加すべきＬＤＥＶが、圧縮ＲＧに属するＬＤＥＶである場合（ステップ８０７−２：Ｙ）、プール容量拡張プログラム８０７は、圧縮ＲＧ容量情報管理テーブル７０３の内容を更新し（プールＶＯＬ容量総和７０３−２に追加すべきＬＤＥＶの論理容量を加算する。また必要があれば、プール内実容量７０３−３も加算される）、処理を終了する。プールに追加すべきＬＤＥＶが圧縮ＲＧに属するＬＤＥＶでない場合（ステップ８０７−２：Ｎ）は、プール容量拡張プログラム８０７はステップ８０７−３を実行せずに終了する。

次に、管理サーバ１０２がステップ９０２−８を実行した時にストレージシステム１０４で行われる処理の流れを、図２４を用いて説明する。管理サーバ１０２がステップ９０２−８を実行すると、ストレージシステム１０４ではプール容量縮小プログラム８０８が起動され、プール容量縮小プログラム８０８によってＬＤＥＶがプールから削除される。またこの時、管理サーバ１０２からはＬＤＥＶ削除対象プールの識別番号、削除すべきＬＤＥＶの識別番号が通知される。

まずプール容量縮小プログラム８０８は、管理サーバ１０２から通知された削除対象ＬＤＥＶのページが使用中か判定する（ステップ８０８−１）。もし削除対象ＬＤＥＶ内のいずれかのページが、仮想ボリュームの仮想ページに割り当てられている場合、削除対象ＬＤＥＶのページが使用中と判定される。この場合プール容量縮小プログラム８０８は、削除対象ＬＤＥＶ内のページのうち、仮想ボリュームの仮想ページに割り当てられているページをすべて特定する（ステップ８０８−２）。削除対象ＬＤＥＶのページがいずれも未使用の場合（ステップ８０８−１：Ｎ）、次にステップ８０８−６が行われる。

削除対象ＬＤＥＶ内のページが仮想ページに割り当てられている場合、削除対象ＬＤＥＶをプールから削除する前に、仮想ページに割り当てられているページ内のデータを別のプールＶＯＬに移動する必要がある。なお、ここでの「別のプールＶＯＬ」は、削除対象ＬＤＥＶが属するＲＡＩＤグループとは異なるＲＡＩＤグループに属するＬＤＥＶの中から選択される。そのためステップ８０８−３でプール容量縮小プログラム８０８は、削除対象ＬＤＥＶが属するＲＡＩＤグループとは異なるＲＡＩＤグループに属しているプールＶＯＬ（１または複数）を探す。また、ここで見つかったプールＶＯＬに、削除対象ＬＤＥＶのデータを移動可能か判定するために、プール容量縮小プログラム８０８は、見つかったプールＶＯＬ内の未使用ページの合計サイズが、削除対象ＬＤＥＶの使用中ページの合計サイズより大きいか判定する。

ステップ８０８−３の判定が否定的な場合、プール容量縮小プログラム８０８はプールからＬＤＥＶ（プールＶＯＬ）を削除できない旨を管理サーバ１０２に通知して処理を終了する。この通知を受けた管理サーバ１０２は、ディスプレイにプール容量の縮小に失敗した旨を表示する。

ステップ８０８−３の判定が肯定的な場合、プール容量縮小プログラム８０８は削除対象ＬＤＥＶの使用中ページ内のデータを、見つかったプールＶＯＬ内の未使用ページに移動する（ステップ８０８−５）。ステップ８０８−５の処理は、ステップ８０５−４の処理（つまり図１５の処理）と同様なので、ここでの説明は略す。

ステップ８０８−５の後、プール容量縮小プログラム８０８はステップ８０８−６で、削除対象ＬＤＥＶが圧縮ＲＧに属するＬＤＥＶか判定する。削除対象ＬＤＥＶが圧縮ＲＧに属するＬＤＥＶである場合（ステップ８０８−６：Ｙ）、プール容量縮小プログラム８０８は圧縮ＲＧ容量情報管理テーブル７０３を更新する（ステップ８０８−７）。ここでは、プールＶＯＬ容量総和７０３−２から削除対象ＬＤＥＶの論理容量を減算する。また必要があれば、プール内実容量７０３−３も減算される。

最後にプール容量縮小プログラム８０８は、ＬＰ変換テーブル７０２から削除対象のＬＤＥＶに含まれる全ページの情報を削除し（ステップ８０８−８）、処理を終了する。

以上が、実施例に係るストレージシステムの説明である。本実施例に係る計算機システムは、プールの論理使用量に加えて、実使用量も監視する。実使用量が所定の閾値を超過した場合には、プールの実容量を増加させる。さらに論理使用量が所定の閾値を超過している場合には、プールの論理容量を増加させる。これにより、プール内に未使用ページは多く残っているが、記憶デバイスが有する物理領域が不足しているために、ホストからストレージシステムへのデータ書き込みができなくなる事態を防ぐことができる。逆に記憶デバイスが有する物理領域は多く残っているが、プール内の未使用ページが不足しているために、ホストからストレージシステムへのデータ書き込みができなくなる事態も防ぐことができる。

さらに本実施例に係る計算機システムは、ＲＡＩＤグループの拡張率（プールＶＯＬの論理容量合計と実容量の比）と、圧縮率の逆数（論理使用量÷実使用量）が乖離しないように、プールの容量の調節を行う。拡張率と１／圧縮率が等しい場合、プールの論理容量と実容量が同じ割合で消費されるため、プール内の未使用ページと物理領域の一方だけが過剰に不足する事態を防ぐことができる。

以上、本発明の実施例を説明したが、これらは、本発明の説明のための例示であって、本発明の範囲をこれらの実施例にのみ限定する趣旨ではない。すなわち、本発明は、他の種々の形態でも実施する事が可能である。

たとえば上で説明した実施例では、管理サーバ１０２でプール容量拡張自動化プログラム９０３やプールＶＯＬ構成最適化プログラム９０２が実行される。ただし別の実施形態として、プール容量拡張自動化プログラム９０３やプールＶＯＬ構成最適化プログラム９０２によって行われる処理の大半をストレージシステム１０４で実施するような、計算機システムの構成になっていてもよい。たとえば上で説明したプール容量拡張自動化プログラム９０３やプールＶＯＬ構成最適化プログラム９０２の処理のうち、管理サーバ１０２では画面表示やユーザからの情報入力を受け付けるためのプログラムコードだけが実行され、それ以外のプログラムコードはストレージシステム１０４のプロセッサ１１９が実行するようにしてよい。

また、別の実施形態として、ホストライト処理プログラム８０２、圧縮ＲＧ監視プログラム８０３、デステージ処理プログラム８０４、枯渇回避再配置処理プログラム８０５、ページ再配置処理プログラム８０６、プール容量拡張プログラム８０７、プール容量縮小プログラム８０８（以下ではこれらを「プログラム８０２〜８０８」と略記する）は、ストレージシステム１０４ではなく、サーバやパーソナルコンピュータ等の汎用のコンピュータ（以下、これを単に「コンピュータ」と呼ぶ）で実行される構成でもよい。この場合、コンピュータが圧縮対応ドライブ１１３やドライブ１１４を有し、コンピュータが上の実施例で説明した各プログラムを実行することで、外部のホスト１０１等から受け付けたライトデータを圧縮対応ドライブ１１３やドライブ１１４に格納する処理を行う。

又、プール容量管理プログラム９０１、プールＶＯＬ構成最適化プログラム９０２、プール容量拡張自動化プログラム９０３（以下ではこれらを「プログラム９０１〜９０３」と略記する）も、コンピュータで実行されてもよい。なお、プログラム８０２〜８０８と、プログラム９０１〜９０３とは、それぞれ同一のコンピュータで実行される構成であってもよいし、異なるコンピュータで実行される構成であってもよい。プログラム８０２〜８０８と、プログラム９０１〜９０３とが、同一のコンピュータで実行される場合、仮想マシンを形成するハイパーバイザプログラムをコンピュータで実行することで、コンピュータ上に少なくとも、プログラム８０２〜８０８を実行する仮想マシンと、プログラム９０１〜９０３を実行する仮想マシンとを形成するとよい。さらにプログラム８０２〜８０８と、プログラム９０１〜９０３を実行するコンピュータが、上の実施例で説明したホスト１０１のような、仮想ボリュームを使用するプログラムを実行する仮想マシンも生成し、上の実施例で説明した計算機システムが、単一のコンピュータ上で実現される構成であってもよい。

また、上で説明した実施例では、プールに論理デバイス（ＬＤＥＶ）を追加または削除する際に、ユーザに確認する処理が行われる。しかし別の実施形態として、プール容量拡張自動化プログラム９０３やプールＶＯＬ構成最適化プログラム９０２は、ユーザに確認せずに、プールに論理デバイス（ＬＤＥＶ）を追加または削除してもよい。

また、上で説明したストレージシステム１０４では、記憶デバイスからＲＡＩＤグループを作成しているが、ＲＡＩＤのパリティを生成することは、本発明の必須要件ではない。たとえば、いわゆるＲＡＩＤ−０（パリティ等の冗長データを生成しないＤｉｓｋ Ａｒｒａｙ）が用いられてもよい。また、複数の記憶デバイスからＲＡＩＤグループを形成しることも必須ではない。単一の記憶デバイスが提供する記憶領域を分割することで形成される部分領域のそれぞれを論理デバイスとして定義し、この定義された論理デバイスをプールＶＯＬとして用いてもよい。

また、上で説明した実施例に係る計算機システムは、圧縮ＲＧの拡張率と圧縮率を比較し、拡張率と１／圧縮率の差が減少するように、プールＶＯＬの追加または削除を行っている。ただし別の実施形態として、計算機システムが圧縮ＲＧを構成する各記憶デバイスについて拡張率と圧縮率を算出し、各記憶デバイスの拡張率と圧縮率に基づいてプールＶＯＬの追加または削除を行ってもよい。その場合、計算機システムは圧縮ＲＧを構成する記憶デバイスのうち、拡張率と１／圧縮率の差（つまり“拡張率−１／圧縮率”）が最も大きい記憶デバイスを特定し、その記憶デバイスの拡張率と１／圧縮率の差に基づいて、削除または追加するプールＶＯＬの数を決定するとよい。プールの容量を調整する場合、物理領域の量が不足している状態を解消することが、最も優先すべき事項だからである。

１００：計算機システム，１０１：ホスト，１０２：管理サーバ，１０３：ネットワーク，１０４：ストレージシステム，１０５：外部ストレージ，１０６：ポート，１０７：保守Ｉ／Ｆ，１０８：ポート，１０９：マイクロプロセッサパッケージボード（ＭＰＢ），１１０：キャッシュメモリ，１１１：共有メモリ，１１２：バス，１１３：圧縮対応ドライブ，１１４：ドライブ，１１５：ＲＡＩＤグループ，１１８：ローカルメモリ，１１９：プロセッサ，２１０：コントローラ，２１１：ドライブＩ／Ｆ，２１２：内部ネットワーク，２１３：プロセッサ，２１４：メモリ，２１５：フラッシュＩ／Ｆ，２１６：圧縮伸張回路

Claims (15)

1. それぞれが所定量の物理領域を有する複数の記憶デバイスと、プロセッサとを有し、ホストに対して仮想ボリュームを提供するストレージシステムと、
   前記ストレージシステムの管理を行う管理サーバを有する計算機システムにおいて、
   前記プロセッサは、前記複数の記憶デバイスから提供される論理記憶領域を用いて、１以上の論理デバイスを有するＲＡＩＤグループを定義し、
   前記仮想ボリュームに割り当て可能な論理記憶領域を有する前記論理デバイスを、プールに所属させることで管理しており、
   前記プロセッサはまた、前記ホストから前記仮想ボリューム上の仮想ページに対するデータのライト要求を受け付けると、前記プール内の未使用の論理記憶領域を前記仮想ページに割り当て、割り当てた前記論理記憶領域を有する前記記憶デバイスに対して前記データの書き込みを行い、
   前記記憶デバイスは、前記プロセッサから前記論理記憶領域に対する前記データの書き込み要求を受け付けると、前記データを圧縮することで圧縮データを生成し、前記圧縮データを前記物理領域に格納し、前記圧縮データの格納された前記物理領域を前記論理記憶領域に対応付けて管理するよう構成されており、
   前記プロセッサは、前記プールに所属する前記物理領域のうち、前記仮想ボリュームに割り当て済みの論理記憶領域に対応付けられている前記物理領域の量である物理使用量が所定の閾値を超過したとき、前記プールに所属する前記物理領域の量を増加させ、
   前記プロセッサは、前記プールに所属する前記論理記憶領域のうち、前記仮想ボリュームに割り当て済みの論理記憶領域の量である論理使用量が所定の閾値を超過したとき、前記プールに所属する前記論理記憶領域の量を増加させる、
   計算機システム。
2. 前記プロセッサは、前記物理使用量または前記論理使用量が前記所定の閾値を超過した旨を前記管理サーバに通知し、
   前記管理サーバは前記通知を受領したことに応じて、前記プールに追加する前記論理デバイスを決定する、請求項１に記載の計算機システム。
3. 前記計算機システムは、前記物理領域の量を増加させる時、
   前記プールに属する前記論理デバイスを有する前記ＲＡＩＤグループのうち、既に前記プールに属する前記論理デバイスの合計が、前記ＲＡＩＤグループの実容量未満であるＲＡＩＤグループに含まれる前記論理デバイスを前記プールに追加するように構成されており、
   前記ＲＡＩＤグループの実容量は、前記ＲＡＩＤグループに属する前記記憶デバイスが有する前記物理領域の合計である、
   請求項２に記載の計算機システム。
4. 前記計算機システムは、前記論理記憶領域の量を増加させる時、
   前記プールに属する前記論理デバイスを有する前記ＲＡＩＤグループのうち、既に前記プールに属する前記論理デバイスの合計が、前記ＲＡＩＤグループの実容量以上であるＲＡＩＤグループに含まれる前記論理デバイスを優先的に前記プールに追加するように構成されており、
   前記ＲＡＩＤグループの実容量は、前記ＲＡＩＤグループに属する前記記憶デバイスが有する前記物理領域の合計である、
   請求項２に記載の計算機システム。
5. 前記プロセッサは、前記記憶デバイスから前記論理記憶領域に対応付けられている前記物理領域の量を取得することで、前記物理使用量を算出する、
   請求項１に記載の計算機システム。
6. 前記プロセッサは、前記プールに属するＲＡＩＤグループの物理使用量が所定の閾値を超過したとき、前記ＲＡＩＤグループに格納されたデータを、前記プールに属する他のＲＡＩＤグループに移動する、
   請求項１に記載の計算機システム。
7. 前記計算機システムはさらに、
   前記プールに所属する前記論理デバイスを有する前記ＲＡＩＤグループの拡張率と圧縮率に基づいて、前記プールに所属する前記論理デバイスの数を調節するよう構成されており、
   前記拡張率は、前記ＲＡＩＤグループの有する前記論理記憶領域の合計と、前記ＲＡＩＤグループに属する前記記憶デバイスが有する前記物理領域の合計の商であり、
   前記圧縮率は、前記プロセッサが前記ＲＡＩＤグループに書き込んだ前記データの合計で、前記ＲＡＩＤグループに書き込まれた前記データの圧縮後のデータ量の合計を除算することで得られる値である、
   請求項１に記載の計算機システム。
8. 前記計算機システムはさらに、
   前記拡張率が前記圧縮率の逆数より大きい場合、前記拡張率と前記圧縮率の逆数の差が少なくなるように、前記プールから削減すべき前記論理デバイスを決定する、
   請求項７に記載の計算機システム。
9. 前記計算機システムはさらに、
   削減対象の前記論理デバイスが有する前記論理記憶領域が、前記仮想ボリュームに割り当てられている場合、前記仮想ボリュームに割り当てられている前記論理記憶領域のデータを、別の論理デバイスに移動する、
   請求項８に記載の計算機システム。
10. それぞれが所定量の物理領域を有する複数の記憶デバイスと、プロセッサとを有し、ホストに対して仮想ボリュームを提供するストレージシステムの管理を行う管理サーバにおいて、
    前記ストレージシステムは、前記複数の記憶デバイスから提供される論理記憶領域を用いて、１以上の論理デバイスを有するＲＡＩＤグループを定義し、
    前記仮想ボリュームに割り当て可能な論理記憶領域を有する前記論理デバイスを、プールに所属させることで管理しており、
    前記ストレージシステムはまた、前記ホストから前記仮想ボリューム上の仮想ページに対するデータのライト要求を受け付けると、前記プール内の未使用の論理記憶領域を前記仮想ページに割り当て、割り当てた前記論理記憶領域を有する前記記憶デバイスに対して前記データの書き込みを行い、
    前記記憶デバイスは、前記プロセッサから前記論理記憶領域に対する前記データの書き込み要求を受け付けると、前記データを圧縮することで圧縮データを生成し、前記圧縮データを前記物理領域に格納し、前記圧縮データの格納された前記物理領域を前記論理記憶領域に対応付けて管理するよう構成されており、
    前記管理サーバは、前記プールに所属する前記物理領域のうち、前記仮想ボリュームに割り当て済みの論理記憶領域に対応付けられている前記物理領域の量である物理使用量が所定の閾値を超過したとき、または前記プールに所属する前記論理記憶領域のうち、前記仮想ボリュームに割り当て済みの論理記憶領域の量である論理使用量が所定の閾値を超過したとき、前記プールに追加する前記論理デバイスを決定する、
    管理サーバ。
11. 前記管理サーバは、前記物理使用量が所定の閾値を超過した時、
    前記プールに属する前記論理デバイスを有する前記ＲＡＩＤグループのうち、既に前記プールに属する前記論理デバイスの合計が、前記ＲＡＩＤグループの実容量未満であるＲＡＩＤグループに含まれる前記論理デバイスを優先的に、前記プールに追加する論理デバイスと決定するよう構成されており、
    前記ＲＡＩＤグループの実容量は、前記ＲＡＩＤグループに属する前記記憶デバイスが有する前記物理領域の合計である、
    請求項１０に記載の管理サーバ。
12. 前記計算機システムは、前記論理使用量が所定の閾値を超過した時、
    前記プールに属する前記論理デバイスを有する前記ＲＡＩＤグループのうち、既に前記プールに属する前記論理デバイスの合計が、前記ＲＡＩＤグループの実容量以上であるＲＡＩＤグループに含まれる前記論理デバイスを優先的に、前記プールに追加する論理デバイスと決定するよう構成されており、
    前記ＲＡＩＤグループの実容量は、前記ＲＡＩＤグループに属する前記記憶デバイスが有する前記物理領域の合計である、
    請求項１０に記載の管理サーバ。
13. プロセッサと、それぞれが論理記憶領域を前記プロセッサに提供する複数の記憶デバイスと、を有する計算機で実行されるプログラムを記録した記憶媒体であって、
    前記記憶デバイスは所定量の物理領域を有し、前記プロセッサから前記論理記憶領域に対するデータの書き込み要求を受け付けると、前記データを圧縮することで圧縮データを生成し、前記圧縮データを前記物理領域に格納し、前記圧縮データの格納された前記物理領域を前記論理記憶領域に対応付けて管理するよう構成されており、
    前記プログラムはプロセッサに、
    仮想ボリュームを形成する工程と、
    前記複数の記憶デバイスから提供される前記論理記憶領域を用いて、１以上の論理デバイスを有するＲＡＩＤグループを定義する工程と、
    前記仮想ボリュームに割り当て可能な前記論理記憶領域を有する前記論理デバイスを、プールに所属させることで管理する工程と、
    前記プール内の未使用の前記論理記憶領域を、データのライト要求を受け付けた前記仮想ボリューム上の仮想ページに割り当て、割り当てた前記論理記憶領域を有する前記記憶デバイスに対して前記データの書き込みを行う工程と、
    前記プールに所属する前記物理領域のうち、前記仮想ボリュームに割り当て済みの論理記憶領域に対応付けられている前記物理領域の量である物理使用量が所定の閾値を超過したとき、前記プールに所属する前記物理領域の量を増加させる工程と、
    前記プールに所属する前記論理記憶領域のうち、前記仮想ボリュームに割り当て済みの論理記憶領域の量である論理使用量が所定の閾値を超過したとき、前記プールに所属する前記論理記憶領域の量を増加させる工程と、
    を実行させるプログラムである、
    ことを特徴とする、プログラムを記録した記憶媒体。
14. 前記プロセッサに、前記物理使用量または前記論理使用量が前記所定の閾値を超過したことに応じて、前記プールに追加する前記論理デバイスを決定させる、
    ことを特徴とする、請求項１３に記載のプログラムを記録した記憶媒体。
15. 前記物理領域の量を増加させる時、前記プロセッサに、
    前記プールに属する前記論理デバイスを有する前記ＲＡＩＤグループのうち、既に前記プールに属する前記論理デバイスの合計が、前記ＲＡＩＤグループに属する前記記憶デバイスが有する前記物理領域の合計未満であるＲＡＩＤグループに含まれる前記論理デバイスを前記プールに追加させる、
    ことを特徴とする、請求項１４に記載のプログラムを記録した記憶媒体。

Images