JP2020060983A - ストレージシステム及びストレージ制御方法 - Google Patents

Abstract

【課題】マルチノードストレージシステムでは、一つのノードが提供できる容量には上限があり、且つ、各ノードが提供できる容量はグローバルプールの容量より小さい。一つのノードが提供可能な容量を超える容量のボリュームが当該ノードから作成され、当該ノードが提供可能な容量を超える量のデータが書き込まれると、ライトエラーが発生する。このようなライトエラーの発生頻度を低減する。【解決手段】グローバルプールは、ノード群を構成する複数のストレージノードが有する複数のローカルプールに基づく。いずれのストレージノードについても、当該ストレージノードから作成されるボリュームの使用済み容量が当該ストレージノードにおけるローカルプールの空き容量以下であるという容量関係を維持すること、が行われる。ボリュームを作成するストレージノードは、ノード群を管理するストレージ管理部により選択される。【選択図】図２０

Description

本発明は、概して、ストレージシステム及びその制御方法に関する。

大量のデータを扱うコンピュータシステムでは、アプリケーションを実行するホスト計算機とは別に設けられた大容量のストレージシステムを用いてデータを管理する。ストレージシステムは、一台以上の物理ドライブ（ハードディスクドライブなど）を搭載し、ホスト計算機から書き込まれるデータを保存する装置である。

近年、複数のストレージノードを束ねて一つのストレージシステムを構築するマルチノード構成のストレージシステム（以下、マルチノードストレージシステム）がある。ノードを追加することで容量や性能を増やすことができる特徴から当該ストレージシステムはスケールアウトストレージシステムと呼ばれることもある。また、マルチノードを構成する各ノードにストレージソフトウェアをインストールして利用する場合、各ノードがソフトウェアデファインドのストレージノードとなり全体としてマルチノードストレージシステムがソフトウェアデファインドのストレージシステムとして構築されることもある。

マルチノードストレージシステムには、例えば、特許文献１に開示の技術を適用することができる。

US2014/0025924A1

マルチノードストレージシステムに下記の第一及び第二の技術を適用することが考えられる。

第一の技術は、グローバルプールの管理技術である。グローバルプールは、複数のノードに跨った論理的な記憶領域である。グローバルプールの容量は、複数のノードがそれぞれ有する複数の容量の合計値とされる。第一の技術によれば、ユーザが個別のノードを意識することなくストレージシステムを利用することができる。

第二の技術は、ホストが認識する記憶領域としてのボリューム内のデータを一つのノード内に格納する技術である。第二の技術によれば、ボリュームからデータを読み出す場合にノード間の通信が不要となり、結果として、高い読出し性能を実現できる。なお、データ保護のため、データの複製やパリティデータは別のノードに格納されてよい。

以上のような第一及び第二の技術が適用されたマルチノードストレージシステムでは、一つのノードが提供できる容量には上限があり、且つ、各ノードが提供可能な容量はグローバルプールの容量より小さい。一つのノードが提供可能な容量を超える容量のボリュームが当該ノードから作成され、当該ノードが提供可能な容量を超える量のデータが書き込まれると、ライトエラーが発生する。

グローバルプールは、ノード群を構成する複数のストレージノードが有する複数のローカルプールに基づく。いずれのストレージノードについても、当該ストレージノードから作成されるボリュームの使用済み容量が当該ストレージノードにおけるローカルプールの空き容量以下であるという容量関係を維持すること、が行われる。ボリュームを作成するストレージノードは、ノード群を管理するストレージ管理部により選択される。

マルチノードストレージシステムにおいてライトエラーの発生頻度を低減することが可能となる。

本発明の一実施例に係るコンピュータシステムの構成を示す図である。 ストレージノードの構成を示す図である。 管理ノードの構成を示す図である。 データ保護と容量割当てを説明する図である。 物理チャンクテーブルの一例を示す図である。 論理チャンクテーブルの一例を示す図である。 ローカルプールテーブルの一例を示す図である。 ストレージ制御部テーブルの一例を示す図である。 グローバルプールテーブルの一例を示す図である。 一比較例で生じ得る課題を説明する図である。 ストレージノードのメモリに格納されるプログラムとテーブルの一例を示す図である。 管理ノードのメモリに格納されるプログラムとテーブルの一例を示す図である。 最大ボリューム容量取得プログラムとローカル空き容量報告プログラムの処理の一例を示す図である。 ローカル履歴テーブルの一例を示す図である。 容量情報取得プログラムの処理の一例を示す図である。 ボリューム作成ノード決定プログラム（１）とボリューム作成プログラムの処理の一例を示す図である。 チャンク作成プログラムの処理の一例を示す図である。 不足モニタリングプログラム（１）の処理の一例を示す図である。 不足モニタリングプログラム（２）とチャンク貸出プログラムとチャンク受取プログラムの処理の一例を示す図である。 チャンク交換プログラムの処理の一例を示す図である。 チャンク結合プログラムの処理の一例を示す図である。 本発明の一実施例の概要を示す図である。 ボリューム作成ノード決定プログラム（２）に処理の一例を示す図である。 結合ボリュームテーブルの一例を示す図である。 ライトプログラムの処理の一例を示す図である。

以下の説明では、「インタフェース部」は、一つ以上のインタフェースでよい。当該一つ以上のインタフェースは、一つ以上の同種の通信インタフェースデバイス（例えば一つ以上のＮＩＣ（Network Interface Card））であってもよいし二つ以上の異種の通信インタフェースデバイス（例えばＮＩＣとＨＢＡ（Host Bus Adapter））であってもよい。

また、以下の説明では、「メモリ部」は、一つ以上のメモリであり、典型的には主記憶デバイスでよい。

また、以下の説明では、「記憶デバイス部」は、一つ以上の記憶デバイスであり、典型的には補助記憶デバイスでよい。「記憶デバイス」は、記憶デバイスの一例であり、特に、物理的な記憶デバイスを意味し、典型的には、不揮発性の記憶デバイスである。

また、以下の説明では、「記憶部」は、メモリ部と記憶デバイス部の少なくとも一部とのうちの少なくとも一つ（典型的には少なくともメモリ部）である。

また、以下の説明では、「プロセッサ部」は、一つ以上のプロセッサである。少なくとも一つのプロセッサは、典型的には、ＣＰＵ（Central Processing Unit）のようなマイクロプロセッサであるが、ＧＰＵ（Graphics Processing Unit）のような他種のプロセッサでもよい。少なくとも一つのプロセッサは、シングルコアでもよいしマルチコアでもよい。少なくとも一つのプロセッサは、処理の一部又は全部を行うハードウェア回路（例えばＦＰＧＡ（Field-Programmable Gate Array）又はＡＳＩＣ（Application Specific Integrated Circuit））といった広義のプロセッサでもよい。

また、以下の説明では、「ｘｘｘテーブル」といった表現にて、入力に対して出力が得られる情報を説明することがあるが、この種の情報は、どのような構造のデータでもよいし、入力に対する出力を発生するニューラルネットワークのような学習モデルでもよい。従って、「ｘｘｘテーブル」を「ｘｘｘ情報」と言うことができる。また、以下の説明において、各テーブルの構成は一例であり、一つのテーブルは、二つ以上のテーブルに分割されてもよいし、二つ以上のテーブルの全部又は一部が一つのテーブルであってもよい。

また、以下の説明では、「ｋｋｋ部」（インタフェース部、記憶部及びプロセッサ部を除く）の表現にて機能を説明することがあるが、機能は、一つ以上のコンピュータプログラムがプロセッサ部によって実行されることで実現されてもよいし、一つ以上のハードウェア回路（例えばＦＰＧＡ又はＡＳＩＣ）によって実現されてもよい。プログラムがプロセッサ部によって実行されることで機能が実現される場合、定められた処理が、適宜に記憶部及び／又はインタフェース部等を用いながら行われるため、機能はプロセッサ部の少なくとも一部とされてもよい。機能（又はプログラム）を主語として説明された処理は、プロセッサ部あるいはそのプロセッサ部を有する装置が行う処理としてもよい。プログラムは、プログラムソースからインストールされてもよい。プログラムソースは、例えば、プログラム配布コンピュータ又はコンピュータが読み取り可能な記録媒体（例えば非一時的な記録媒体）であってもよい。各機能の説明は一例であり、複数の機能が一つの機能にまとめられたり、一つの機能が複数の機能に分割されたりしてもよい。

また、以下の説明では、「ストレージシステム」は、それぞれが記憶デバイス部を有する複数のストレージノードを備えたマルチノード構成のノード群（例えば分散システム）を含む。各ストレージノードは、一つ以上のＲＡＩＤ（Redundant Array of Independent (or Inexpensive) Disks）グループを備えたストレージ装置でもよいが、典型的には、汎用のコンピュータである。一つ以上のコンピュータの各々が所定のソフトウェアを実行することにより、当該一つ以上のコンピュータがＳＤｘ（Software-Defined anything）として構築されてもよい。ＳＤｘとしては、例えば、ＳＤＳ（Software Defined Storage）又はＳＤＤＣ（Software-defined Datacenter）を採用することができる。例えば、ストレージ機能を有するソフトウェアが一つ以上の汎用のコンピュータの各々で実行されることにより、ＳＤＳとしてのストレージシステムが構築されてもよい。また、少なくとも一つのコンピュータが、ホストコンピュータとしての一つ以上の仮想的なコンピュータと、ストレージシステムの記憶制御システム（典型的には、Ｉ／Ｏ要求に応答してデータを記憶デバイス部に対して入出力する装置）としての仮想的なコンピュータとが実行されてもよい。

また、以下の説明では、同種の要素を区別しないで説明する場合には、参照符号を使用し、同種の要素を区別して説明する場合には、要素の識別番号を使用することがある。例えば、ストレージノードを特に区別しないで説明する場合には、「ストレージノード２００」と記載し、個々のストレージノードを区別して説明する場合には、「ストレージノード０」、「ストレージノード１」のように記載することがある。

以下、一実施例を説明する。

図２０は、実施例の概要を示す図である。

ストレージシステム１６０が、ノード群１６５を有する。ノード群１６５は、複数のストレージノード２００で構成される。ストレージノードを単に「ノード」と呼ぶことがある。複数のストレージノード２００の各々が、当該ストレージノード２００内の記憶デバイス部に基づくローカルプール２６３を有する。複数のストレージノード２００は、複数のローカルプール２６３に基づく論理的な記憶領域であるグローバルプール２８０を提供する。

各ストレージノード２００は、ストレージシステム１６０の上位システム８２０に提供されたボリューム２６２に格納されるデータを当該ストレージノード２００におけるローカルプール２６３に格納する。上位システム８２０は、アプリケーションプログラム又はそれを実行するホストシステムのようなシステムであり、ボリューム２６２を指定したＩ／Ｏ（Input/Output）要求を発行するシステムである。

ストレージノード２００から作成されるボリューム２６２の使用済み容量が当該ストレージノード２００におけるローカルプール２６３の空き容量以下であるという容量関係を維持することが行われる。これにより、ライトエラーの発生頻度を下げることが可能である。

本実施例では、具体的には、作成されるボリューム２６２の容量を制限することで上記の容量関係を維持する維持方式Ａと、ローカルプール２６３の空き容量を動的に変えることで上記の容量関係を維持する維持方式Ｂとのうちのいずれかが、ノード群１６５を管理するストレージ管理部８１０により実施される。維持方式ＡおよびＢのいずれについても、ストレージ管理部８１０が、ボリュームを作成するノード２００を選択する。ストレージ管理部８１０は、ストレージノード２００と後述の管理ノード３００とのうち少なくとも一つにより実現される。具体的には、例えば、ストレージシステム１６０は、ノード群１６５それ自体でもよいし、ノード群１６５の他に、ストレージ管理部８１０の少なくとも一部のような要素を含んでもよい。維持方式Ａ及びＢの一方が無くてもよい。ストレージ管理部８１０は、後述の図１０Ａに例示のプログラム、図１０Ｂに例示のプログラム、図１０Ａ及び図１０Ｂのいずれにも例示されていないプログラム、のうちの少なくとも一部を基に実現されてよい。

以下、本実施例を詳細に説明する。

図１は、本実施例に係るコンピュータシステムの構成を示す図である。

コンピュータシステムは、ストレージシステム１６０を含む。コンピュータシステムは、ストレージシステム１６０を管理する管理ノード３００を更に含んでもよい。ストレージシステム１６０、管理ノード３００及びホスト１００が、ネットワーク４００に接続される。

ホスト１００は、上位システム８２０の一例であり、アプリケーションプログラムを実行するためのコンピュータである。ホスト１００は、物理的なコンピュータでもよいし、仮想マシン（Virtual Machine）でもよいし、コンテナなどでもよい。図示していないが、ホスト１００は、ストレージシステム１６０と接続するためのＩ／Ｆ（インタフェースデバイス）、ＣＰＵ、メモリなどを搭載しアプリケーションを実行する。メモリはアプリケーションのプログラムを記録する。ＣＰＵは、アプリケーションのプログラムを実行する。Ｉ／Ｆはストレージノード２００との間の通信を仲介する。

ストレージシステム１６０は、ノード群１６５を含む。ノード群１６５は、複数のストレージノード２００から構成される。ストレージノード２００は、典型的には汎用のコンピュータである。ホスト１００同様に、ストレージノード２００は、物理的なコンピュータでもよいし、仮想マシン（Virtual Machine）でもよいし、コンテナでもよいし、クラウド上で動作する仮想マシンなどにソフトウェアをインストールすることで構築されるソフトウェアデファインドのストレージノードでもよい。

図１は、ホスト１００とストレージノード２００を別のコンピュータとして記載しているが、物理的に同じコンピュータ上でストレージのソフトウェアとアプリケーションのソフトウェアが動作してもよい。

管理ノード３００は、ストレージシステム１６０を管理するソフトウェアが実行されるノードである。

図１の例では、管理ノード３００とストレージノード２００は異なるノードとして記載しているが、一つのノードがストレージノード２００と管理ノード３００を兼ねてもよい。すなわち、一つのノードが、後述するデータを保存するための処理を実行し、加えて、ストレージシステム、ストレージノードを管理するための管理ソフトウェアを実行してもよい。

図２Ａは、ストレージノード２００の構成を示す図である。

ストレージノード２００は、通信ポート２５０、ＣＰＵ２３０、メモリ２２０、記憶デバイス２１０から構成される。これらのうちの少なくとも一つの資源は、ストレージノード２００に一つ以上搭載され得る。一つ以上の記憶デバイス２１０が記憶デバイス部２４９である。

通信ポート２５０は、インタフェース部の一例であり、ネットワーク４００を介してホスト１００や管理ノード３００と接続され、ホスト１００や管理ノード３００との通信を仲介する。図の例では、一つの通信ポート２５０をホスト１００向けの通信と管理ノード３００向けの通信で共有しているが、それぞれの通信に異なる通信ポートが設けられてもよい。

メモリ２２０は、メモリ部の一例であり、ストレージノードで使用される制御情報、ストレージノードが実行するプログラム、ホストがアクセスするデータのキャッシュを格納する。これ以外のデータをメモリ２２０は格納してもよい。メモリ２２０は、ＤＲＡＭ（Dynamic Random Access Memory）で構成されることが一般的であるが、それ以外の記憶メディアで構成されてもよい。例えば、ＭＲＡＭ（Magnetoresistive Random Access Memory）、ＲｅＲＡＭ（Resistive Random Access Memory）、ＰＣＭ（Phase-Change Memory）、又は、ＮＡＮＤ型のフラッシュメモリでよい。

ＣＰＵ２３０は、プロセッサ部の一例であり、メモリ２２０に格納された各種プログラムを実行することにより各種処理を実行する。また、ＣＰＵ２３０は、メモリ２２０に格納されている各種情報を用いて各種処理を実行する。

記憶デバイス２１０は、物理的に記憶領域を有する装置である。例えば、記憶デバイス２１０は、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）、ＤＶＤ（Digital Versatile Disc）、及び、ＳＣＭ（Storage Class Memory）のいずれでもよい。記憶デバイス２１０へアクセスするためのＩ／Ｆとして、例えばＳＡＳ（Serial Attached SCSI）、ＮＶＭｅ（Ｎｏn-Volatile Memory Express）などがあるが、それ以外のＩ／Ｆが採用されてもよい。複数の記憶デバイス２１０は、同種の記憶デバイスでもよいし異種の記憶デバイスでもよい。一般に、マルチノード構成のストレージシステムでは、ノードの障害に備え、別のノードにデータの複製を格納することなどでデータを保護することが可能である。ノード内で一つ以上の記憶デバイスをパリティグループという単位でまとめて、ＲＡＩＤ（Redundant Arrays of Independent Disks）のような高信頼化技術を使用してもよい。ＣＰＵ２３０、メモリ２２０、通信ポート２５０及び記憶デバイス２１０は、内部ネットワーク２４０を介して相互に接続されている。図２Ａの構成は、ストレージノード２００の構成の一例であり、本発明は図の構成に限定されない。なお、図２Ａに限らず、本発明は、他の図が示す構成や処理に限定されない。

図２Ｂは、管理ノード３００の構成を示す図である。

管理ノード３００は、ＣＰＵ３３０、メモリ３２０、記憶デバイス３１０、入出力デバイス３６０及び保守ポート３５０を有する。ＣＰＵ３３０、メモリ３２０、記憶デバイス３１０、入出力デバイス３６０及び保守ポート３５０は、内部ネットワーク３４０を介して相互に接続されている。

メモリ３２０及び記憶デバイス３１０が記憶部の一例である。メモリ３２０及び記憶デバイス３１０のうちの少なくともメモリ３２０は、管理ソフトウェア（管理用のソフトウェア）を記憶する。ＣＰＵ３３０は、管理ソフトウェアを実行して管理処理を実行する。管理ソフトウェアは、例えば、図１０Ｂに例示のプログラム２３３〜２３７を含んでよい。入出力デバイス３６０は、例えば、マウス、キーボード、ディスプレイ等により構成され、管理を行うオペレータによる各種指示入力を受け付けるとともに、各種情報をディスプレイに表示させる。保守ポート３５０は、ストレージノード２００との間の通信を仲介する。

図３は、ストレージノード２００内でのデータ保護及び容量割り当てを説明する図である。

複数のストレージノード２００は、一つ以上の制御部クラスタを有する。各制御部クラスタは、状態がアクティブであるストレージ制御部（以下、アクティブ制御部）２６０Ａと、それぞれ状態がスタンバイである一つ以上のストレージ制御部（以下、スタンバイ制御部）２６０Ｓとで構成される。アクティブ制御部２６０Ａは、ボリューム２６２を提供する。アクティブ制御部２６０Ａは、当該ボリューム２６２を指定したＩ／Ｏ要求を受け付けた場合、当該ボリューム２６２に対するＩ／Ｏ、具体的には、当該ボリューム２６２に関連付けられたローカルプール２６３に対するＩ／Ｏを行う。アクティブ制御部２６０Ａが停止した場合、当該アクティブ制御部２６０Ａに代わっていずれかのスタンバイ制御部２６０Ｓがアクティブとなるフェイルオーバーが行われる。

また、複数のストレージノード２００の各々は、データ保護部２７０を有する。データ保護部２７０が、データ保護（本実施例では、データを自身のストレージノード２００に格納することに加えて、データを複製し複製されたデータを別のストレージノード２００に格納すること）を行う。

最初にデータ保護について説明する。

マルチノード構成のストレージシステムは、ノード障害を想定しストレージノード２００間でのデータ保護を行う。データ保護の方法として、例えば、別のストレージノード２００に複製データを保存する方法や、別のノードのデータとパリティを生成する方法などが考えられる。図３の例では、各ストレージノード２００は、データの複製を別のノードに保存する。ノード間のデータ保護に加えて、ノード内でＲＡＩＤ等の方法を用いた更なるデータ保護が行われてもよい。ノード内でＲＡＩＤ等の方法を用いる場合、記憶デバイス２１０の一台が障害でノード間でのデータ復旧が不要となる。

図の例では、論理チャンク２６４と物理チャンク２１１を用いてデータをストレージノード２００間で複製する方法が採用されている。「物理チャンク」とは、ストレージノード２００内の記憶デバイス部２４９を一つ以上に分割して作成した小領域である。「論理チャンク」とは、一つ以上の物理チャンクが関連付けられた論理的な記憶領域である。論理チャンクはローカルプール２６３に関連付けられる。ホスト１００からの書き込みデータは論理チャンク２６４に書き込まれる。図の例では、データ保護としてミラーリングが採用されているため、一つの論理チャンク２６４に二つの物理チャンク２１１が関連付けられる。データ保護部２７０は、論理チャンク２６４に書き込まれたデータを、当該論理チャンク２６４に関連付けられた二つの物理チャンク２１１に書き込む。結果として、データの複製（データ保護）が実現される。図３の例では、ストレージノード０内の或る物理チャンクとストレージノード１内の或る物理チャンクからストレージノード０内の或る論理チャンクが作成されている。ストレージノード０内の論理チャンク２６４について、ストレージノード０内の物理チャンク２１１に書き込まれたデータと、ストレージノード１内の物理チャンク２１１に書き込まれたデータのうち、後者のデータが、複製データである。

次に、ローカルプール２６３とボリューム２６２について説明する。

ローカルプール２６３は、一つ以上の論理チャンク２６４から成る論理的な記憶領域である。ボリューム２６２は、ホスト１００が認識する論理的な記憶領域である。アクティブ制御部２６０Ａは、ホスト１００が認識する記憶領域であるボリュームに対するライト要求をホスト１００から受け付けると、ローカルプール２６３から所定サイズの領域（例えば、論理チャンク２６４、又は、論理チャンク２６４よりも大きい又は小さい領域）をボリューム２６２に割り当て、当該領域にライト対象のデータを格納する。当該領域に格納されたデータは、データ保護部２７０が、当該領域が属する論理チャンク２６４と当該論理チャンク２６４に関連付いた物理チャンク２１１との対応関係に従い、当該データを、ストレージノード０内の物理チャンク２１１とストレージノード１内の物理チャンク２１１に書き込む。アクティブ制御部２６０Ａはローカルプール２６３とボリューム２６２の管理を行う。論理チャンク２６４と物理チャンク２１１との対応関係は、データ保護の方式（例えば、パリティが不要なデータ保護であるのかパリティを必要とするデータ保護であるのか）に依存する。

ストレージノード０の障害時に、ストレージノード１が処理を引き継ぐため、ストレージノード１も、論理チャンク２６４に関する情報、ローカルプール２６３に関する情報、ボリューム２６２に関する情報を有する。ストレージノード０が障害となった場合、スタンバイ制御部０がアクティブ制御部０の処理を引き継ぐ（フェイルオーバー）。一つのアクティブ制御部２６０Ａに対して複数個のスタンバイ制御部２６０Ｓが設定されてもよい。なお、ストレージ制御部０をアクティブ制御部とアクティブ制御部の組み合わせとしても、本発明は適用可能である。その場合、ストレージノード２００間の排他機能や一貫性管理機能などが必要となる。

一つのストレージノード２００に複数のストレージ制御部２６０があってもよい。図３の例では、ストレージ制御部０とストレージ制御部２がストレージノード０に配置されている。異なる複数の制御部クラスタについて、複数のアクティブ制御部２６０Ａはリソース消費の集中を避けるために複数のストレージノード２００に分散されていてもよい。また、異なる複数の制御部クラスタについて、複数のスタンバイ制御部２６０Ｓは複数のストレージノード２００に分散されていてもよいし、一部のストレージノード２００に集約されていてもよい。

上述した物理チャンク２１１、論理チャンク２６４、ローカルプール２６３及びアクティブ／スタンバイ構成を制御するために使用される制御情報（制御テーブル）を説明する。

図４は、物理チャンクテーブルの一例を示す図である。

物理チャンクテーブル２３１は、物理チャンク２１１に関する情報の一例である。物理チャンクテーブル２３１は、物理チャンク２１１毎にレコードを有する。各レコードは、物理チャンク番号４０１、記憶デバイス番号４０２、デバイス内オフセット４０３及びサイズ４０４といった情報を格納する。以下、一つの物理チャンク２１１を例に取る（図４の説明において「対象物理チャンク」）。

物理チャンク番号４０１は、対象物理チャンクを識別するための番号を示す。物理チャンク２１１は、ストレージノード２００内の資源であり、物理チャンク番号４０１は、ストレージノード２００内で非重複の番号である。記憶デバイス番号４０２は、対象物理チャンクが属する記憶デバイス２１０を識別するための番号である。デバイス内オフセット４０３は、対象物理チャンクの先頭が対応する記憶デバイスのアドレスを示す。最後に、サイズ４０４は、対象物理チャンクのサイズを示す。

図４の例では、物理チャンク番号０の物理チャンク先頭アドレスが、記憶デバイス番号０のアドレス0x0000であり、物理チャンクサイズが１００ＧＢである。

図５は、論理チャンクテーブルの一例を示す図である。

論理チャンクテーブル２３２は、論理チャンク２６４に関する情報の一例である。論理チャンクテーブル２３２は、論理チャンク２６４毎にレコードを有する。各レコードは、論理チャンク番号５０１、ノード番号（マスタ）５０２、物理チャンク番号（マスタ）５０３、ノード番号（ミラー）５０４、物理チャンク番号（ミラー）５０５、サイズ５０６、及び、ストレージ制御部番号５０７といった情報を格納する。以下、一つの論理チャンク２６４を例に取る（図５の説明において「対象論理チャンク」）。

論理チャンク番号５０１は、対象論理チャンクを識別するための番号である。論理チャンク２６４は、ストレージノード２００内の資源であり、論理チャンク番号５０１は、ストレージノード２００内で非重複の番号である。他のノードに容量を融通する場合などは、ストレージノード番号と組み合わせることで、ストレージシステム１６０内で対象論理チャンクを識別することが可能となる。

ノード番号（マスタ）５０２は、対象論理チャンクに関連付けられた二つの物理チャンク２１１のうちマスタの物理チャンク２１１を有するストレージノード（典型的には、対象論理チャンクを有するストレージノード自身）を識別するための番号である。物理チャンク番号（マスタ）５０３は、対象論理チャンクに関連付けられた上記マスタの物理チャンク２１１を識別するための番号である。ノード番号（ミラー）５０４は、対象論理チャンクに関連付けられた二つの物理チャンク２１１のうちミラーの物理チャンク２１１を有するストレージノード（典型的には、対象論理チャンクを有するストレージノードとは別のストレージノード）を識別するための番号である。物理チャンク番号（ミラー）５０５は、対象論理チャンクに関連付けられた二つの物理チャンク２１１のうち上記ミラーの物理チャンク２１１（障害に備えて複製されている（ミラーされている）データが格納される物理チャンク）を識別するための番号である。情報５０２〜５０５を参照することで、対象論理チャンクに関連付けられている二つの物理チャンクを識別することが可能となる。

サイズ５０６は、対象論理チャンクのサイズを示す。ストレージ制御部番号５０７は、対象論理チャンクを使用する（対象論理チャンクが割り当てられた）ストレージ制御部２６０の識別番号を示す。各レコードは、ストレージ制御部番号５０７に加えて、ローカルプール番号を格納してもよい。例えば、一つのストレージ制御部２６０が複数のローカルプール２６３を管理する場合、ローカルプール番号が必要となる。

図５の例では、論理チャンク０が、ストレージノード０の物理チャンク０とストレージノード１の物理チャンク０に対応しており、ストレージ制御部０に割り当てられている。

図５の例は、データを複製する場合の論理チャンクテーブルの一例を示している。ノード間でＲＡＩＤやErasure Codingを適用する場合、複数の物理チャンクをグルーピングし、グルーピングした複数の物理チャンクから複数の論理チャンクを作成してもよい。その場合、図５にはグルーピングされた物理チャンクの情報が格納される。

図６は、ローカルプールテーブルの一例を示す図である。

ローカルプールテーブル２２８は、一つ以上の論理チャンク２６４の容量を容量プールとするため、論理チャンク２６４との対応や、容量の割り当て先ボリューム２６２、割り当て状況などを管理する。ローカルプールテーブル２２８は、ボリューム２６２への割当ての単位領域であるページ毎にレコードを有する。各レコードは、ローカルプール番号６０１、容量６０２、使用済み容量６０３、論理チャンク番号６０４、ページ番号６０５、ページ割当状況６０６、及び、割当先ボリューム番号６０７といった情報を格納する。以下、一つのページを例に取る（図６の説明において「対象ページ」）。

ローカルプール番号６０１は、対象ページを含んだローカルプール２６３を識別するための番号を示す。ストレージ制御部２６０が複数のローカルプール２６３を管理する場合などに、ローカルプール番号６０１を用いてローカルプール２６３を識別することができる。

容量６０２は、対象ページを含んだローカルプール２６３の容量を示す。使用済み容量６０３は、対象ページを含んだローカルプール２６３の容量のうち、既に使用されている容量を示す。容量６０２は、論理チャンクサイズと論理チャンク数との積でよい。使用済み容量６０３は、ページ割当状況“済”の数とページサイズとの積でよい。

論理チャンク番号６０４は、対象ページを含んだ論理チャンク２６４（ローカルプールに登録されている論理チャンク２６４）の番号を示す。一つ以上の論理チャンク２６４がローカルプール２６３に登録される。論理チャンク２６４が一つもローカルプール２６３に登録されてない場合、ローカルプール２６３が未定義である。

「ページ」は、論理チャンク２６４を更に小さな領域に分割した領域であり、ボリュームへ記憶領域の割り当て単位である。割り当て単位を論理チャンクとする場合、ページは不要となる。その場合、ページ番号６０５及びページ割当状況６０６は不要となり、論理チャンクの割当状況（割当て済か否か)を示す情報が必要となる。ページ番号６０５は、対象ページを識別するための番号を示す。ページ割当状況６０６は、対象ページが割り当て済みであるか否かを示す。割当先ボリューム番号６０７は、対象ページが割り当てられているボリューム２６２の番号を示す。対象ページの割当状況が未割り当ての場合、対象ページについて割当先ボリューム番号６０７としては何も格納されないでよい（図６の例では、“−”）。

ローカルプールテーブル２２８は、ストレージ制御部２６０毎に存在するものとする。ローカルプールテーブル２２８の各レコードはストレージ制御部番号を有してもよい。

また、図示しないが、ボリューム２６２に関する情報の一例として、いずれのボリューム２６２のいずれのアドレスにいずれのページが割り当てられているかを示すボリュームテーブルが、各ストレージノード２００に存在してもよい。アクティブ制御部２６０Ａは、当該ボリュームテーブルを参照したり更新したりすることができる。アクティブ制御部２６０Ａは、当該ボリュームテーブルを参照することで、ボリューム２６２のＩ／Ｏ先のアドレスに割り当てられているページを特定できる。

図７は、ストレージ制御部テーブルの一例を示す図である。

ストレージ制御部テーブル２４３は、ストレージ制御部２６０の配置を管理する。ストレージ制御部テーブル２４３は、ストレージ制御部２６０毎にレコードを有する。各レコードは、ストレージ制御部番号７０１、アクティブノード番号７０２、及びスタンバイノード番号７０３といった情報を格納する。以下、一つのストレージ制御部２６０を例に取る（図７の説明において「対象ストレージ制御部」）。

ストレージ制御部番号７０１は、対象ストレージ制御部を識別するための識別番号を示す。アクティブのストレージ制御部にもスタンバイのストレージ制御部にも同一の識別番号が割り当てられる。アクティブノード番号７０２は、対象ストレージ制御部としてのアクティブ制御部が配置されるストレージノード２００の番号を示す。スタンバイノード番号７０３は、対象ストレージ制御部としてのスタンバイ制御部が配置されるストレージノード２００の番号を示す。

図７の例では、ストレージノード０にアクティブ状態であるストレージ制御部０が配置され、ストレージノード１にスタンバイ状態であるストレージ制御部０が配置されている。

次に、マルチノード構成におけるグローバルプールについて説明する。

図８は、グローバルプールテーブルの一例を示す図である。

グローバルプールテーブル２３８は、グローバルプール２８０に属するローカルプール２６３に関する情報を管理する。グローバルプールテーブル２３８は、ローカルプール２６３毎にレコードを有する。各レコードは、グローバルプール番号８０１、容量８０２、使用済み容量８０３、ストレージ制御部番号８０４、及びローカルプール番号８０５といった情報を格納する。以下、一つのローカルプール２６３を例に取る（図８の説明において「対象ローカルプール」）。

グローバルプール番号８０１は、対象ローカルプールを含むグローバルプールを識別するための番号を示す。容量８０２は、対象ローカルプールを含むグローバルプールの容量を示す。使用済み容量８０２は、当該グローバルプールの容量のうち、既に使用されている容量を示す。ストレージ制御部番号８０４とローカルプール番号８０５は、対象ローカルプールを識別するための番号を示す。

この様に、各ストレージノード２００は、グローバルプール２８０に属するローカルプール２６３を識別するためにローカルプール２６３をグローバルプール２８０と対応付けて管理する。

図９は、一比較例で生じ得る課題を説明する概念図である。

課題が発生するパターンとして、例えばケース（１）からケース（４）があり得る。ケース（１）から（４）は一例でありこの他の構成でも課題は発生し得る。

＜ケース（１）＞

本例は、各ストレージノード２０の内部容量２１が１５０ＴＢ、ローカルプール容量が１００ＴＢ、グローバルプール容量が２００ＴＢであり、グローバルプールの空き容量が２００ＴＢの状態である。また、「内部容量」とは、ローカルプール２３に提供可能な容量（例えば、ストレージノード２０が内蔵する記憶デバイスの容量からローカルプール２３に提供不可能な容量（例えば、他のノードのミラーデータを格納する容量や、ノード障害時に冗長化を再構築するための予備領域の容量）を除いた容量）である。ストレージシステムの利用者（例えばホスト１００）は、空き容量２００ＴＢを認識するため、最大２００ＴＢのボリュームの作成指示を出す可能性がある。本例では、１５０ＴＢのボリューム２２の作成指示を受け、ストレージノード０に１５０ＴＢのボリューム２２が作成される。ホストから１５０ＴＢのデータをボリューム２２にライトするライト要求が受け付けられても、ローカルプール容量が１００ＴＢしかないため、全てのデータを格納することはできない。よって、そのようなライト要求の処理ではライトエラーが発生する。

ローカルプール容量が内部容量２１を下回る理由を説明する。ローカルプール２３の容量はローカルプールテーブルに登録可能な論理チャンク数と、論理チャンクのサイズとによって決まる。ストレージノード２０に大容量の記憶デバイス部が搭載されているとしても、実際には全ての容量をローカルプールに登録することができない場合がある。

以上のように、本例では、ローカルプール容量を超えた容量のボリュームが作成されることが、ライトエラーが発生する原因となり得る。

＜ケース（２）＞

本例は、各ストレージノード２０の内部容量２１が１５０ＴＢ、ローカルプール容量が１００ＴＢ、グローバルプール容量が２００ＴＢであり、ローカルプール２３の半分である５０ＴＢが使用済みである。このため、ローカルプール２３の空き容量は５０ＴＢ、内部容量２１の空き容量は１００ＴＢとなる。つまり、ローカルプール２３に記載している“５０ＴＢ”と内部容量２１に記載している“１００ＴＢ”はそれぞれ空き容量を示している。

グローバルプール容量は２００ＴＢで、グローバルプール２８の空き容量は１００ＴＢの状態である。グローバルプール２８の空き容量である１００ＴＢを認識する利用者から、７０ＴＢのボリュームの作成指示を受け、ストレージノード０に７０ＴＢのボリューム２２が作成される。ホストから７０ＴＢのデータをボリューム２２にライトするライト要求が受け付けられても、ローカルプール２３の空き容量が５０ＴＢしかないため、全てのデータを格納することができない。よって、そのようなライト要求の処理ではライトエラーが発生する。

以上のように、本例では、ローカルプール容量は超えていないがローカルプールの空き容量を超えた容量のボリュームが作成されることが、ライトエラーが発生する原因となり得る。

＜ケース（３）＞

本例は、ストレージノード２０の内部容量２１が５０ＴＢ、ローカルプール容量が５０ＴＢ、グローバルプール容量が１００ＴＢであり、グローバルプール２８の空き容量が１００ＴＢの状態である。グローバルプール２８の空き容量である１００ＴＢを認識する利用者から、７０ＴＢのボリュームの作成指示を受け、ストレージノード０に７０ＴＢのボリューム２２が作成される。ホストから７０ＴＢのデータをボリューム２２にライトするライト要求が受け付けられても、内部容量２１が５０ＴＢしかないため、全てのデータを格納することはできない。よって、そのようなライト要求の処理ではライトエラーが発生する。

本例では、内部容量２１を超えた容量のボリュームが作成されることが、ライトエラーが発生する原因となり得る。

＜ケース（４）＞

本例は、各ストレージノード２０の内部容量２１が５０ＴＢ、ローカルプール容量が５０ＴＢ、グローバルプール容量が１００ＴＢであり、ローカルプール２３の半分である２５ＴＢが使用済みである。このため、ローカルプール２３の空き容量は２５ＴＢ、内部容量２１の空き容量は２５ＴＢとなる。グローバルプール容量は１００ＴＢで、グローバルプール２８の空き容量は５０ＴＢの状態である。グローバルプール２８の空き容量である５０ＴＢを認識する利用者から、５０ＴＢのボリュームの作成指示を受け、ストレージノード０に５０ＴＢのボリューム２２が作成される。ホストから５０ＴＢのデータをボリューム２２にライトするライト要求が受け付けられても、内部容量２１の空き容量が２５ＴＢしかないため、全てのデータを格納することはできない。よって、そのようなライト要求の処理ではライトエラーが発生する。

以上のように、本例では、内部容量２１の空き容量を超えた容量のボリュームが作成されることが、ライトエラーが発生する原因となり得る。

上述したように、各ストレージノード２０が提供できる容量はグローバルプール２８の容量よりも小さくなる可能性が高い。このため、グローバルプール２８の容量を認識してボリューム２２を作成する場合、ライトエラーが発生する可能性がある。

本実施例では、ケース（１）〜ケース（４）のようなパターンで発生する課題を解決することができる。以下、本実施例を更に説明する。

図１０Ａは、ストレージノード２００のメモリ２２０に格納されている制御情報とプログラムを示している。

ローカル空き容量報告プログラム２２１、ボリューム作成プログラム２２２、チャンク作成プログラム２２３、チャンク貸出プログラム２２４、チャンク受取プログラム２２５、チャンク交換プログラム２２６、チャンク結合プログラム２２７及びライトプログラム２４５がメモリ２２０に格納される。これらのプログラムが行う処理は後述する。

また、ローカルプールテーブル２２８、ボリュームテーブル２２９、論理チャンクテーブル２３２、物理チャンクテーブル２３１、及び結合ボリュームテーブル２４６がメモリ２２０に格納される。ローカルプールテーブル２２８は、図６を参照して説明した通りである。ボリュームテーブル２２９は、図示はされていないが上述の通りであるし、或いは後述の通りであってもよい。論理チャンクテーブル２３２は、図５を参照して説明した通りである。物理チャンクテーブル２３１は、図４を参照して説明した通りである。結合ボリュームテーブル２４６は、後に図２２を参照して説明する通りである。

図１０Ｂは、管理ノード３００のメモリ３２０に格納されている制御情報とプログラムを示している。

最大ボリューム容量取得プログラム２３３、容量情報取得プログラム２３４、ボリューム作成ノード決定プログラム（１）２３５、不足モニタリングプログラム（１）２３６、不足モニタリングプログラム（２）２３７、及びボリューム作成ノード決定プログラム（２）２４４がメモリ３２０に格納される。これらのプログラムが行う処理は後述する。

また、グローバルプールテーブル２３８、ローカル履歴テーブル２３９、ボリューム管理テーブル２４２、及びストレージ制御部テーブル２４３がメモリ３２０に格納される。グローバルプールテーブル２３８は、図８を参照して説明した通りである。ローカル履歴テーブル２３９及びボリューム管理テーブル２４２については後述する。ストレージ制御部テーブル２４３は、図７を参照して説明した通りである。

図１０Ａ及び図１０Ｂに示したプログラム及びテーブルは一例である。実際には、これら以外のプログラムやテーブルも格納される。図１０Ａに例示した一つ以上のプログラムと図１０Ａに例示されていない一つ以上のプログラムとのうちの少なくとも一つのプログラムに基づき図３に示したストレージ制御部２６０やデータ保護部２７０が実現される。

ボリュームテーブル２２９とボリューム管理テーブル２４２の詳細説明は省略する。ボリュームテーブル２２９は、ボリューム番号、サイズ、ボリューム内アドレスとページの対応関係などを管理する。ボリューム管理テーブル２４２は、ボリューム番号、サイズ、ボリュームが配置されるストレージ制御部番号などを管理する。ボリューム管理テーブル２４２は、ボリュームテーブル２２９と同様に、ボリューム内アドレスとページの関係も管理してもよい。その場合、ボリュームテーブル２２９の更新内容がボリューム管理テーブル２４２に反映される。

図１０Ａ及び図１０Ｂの例では、電源障害などに備え、テーブルやプログラムはメモリ２２０及び２３０に格納されるが、上述したテーブル及びプログラムの少なくとも一部が記憶デバイス部に格納されてもよい。記憶デバイス部に格納されたテーブルやプログラムがメモリにキャッシュされてもよい。テーブルやプログラムが記憶デバイス部とメモリの両方に格納されてもよい。

管理ノード３００がローカルプールテーブル２２８、物理チャンクテーブル２３１、及び論理チャンクテーブル２３２といったテーブルのバックアップを格納してもよい。当該バックアップは、ストレージノード２００のメモリ障害時など、制御情報のみが失われた場合のデータ回復に利用され得る。

ローカルプールテーブル２２８、ボリュームテーブル２２９、及び論理チャンクテーブル２３２といったテーブルはアクティブ制御部２６０Ａとスタンバイ制御部２６０Ｓで複製される。これは、アクティブ制御部２６０Ａが配置されるストレージノード２００の障害などにより、処理を引き継ぐスタンバイ制御部２６０Ｓが処理を継続するためである。後述する説明において、上記テーブルを更新では、ノード間通信が行われアクティブ制御部２６０Ａとスタンバイ制御部２６０Ｓの両方のテーブルが更新されるものとする。物理チャンクテーブル２３１は、ストレージノード２００の物理的な資源を管理するため、複製する必要はない。

本実施例では、ストレージノード２００から作成されるボリューム２６２の使用済み容量が当該ストレージノード２００におけるローカルプール２６３の空き容量以下であるという容量関係が維持される。このような容量関係の維持の方式として、上述したように、作成されるボリューム２６２の容量を制限することで上記の容量関係を維持する維持方式Ａと、ローカルプール２６３の空き容量を動的に変えることで上記の容量関係を維持する維持方式Ｂとがある。維持方式Ａ及びＢのうちの少なくとも一つを採用することができる。

以下、各維持方式を説明する。

＜維持方式Ａ＞

維持方式Ａの概要の一例は、以下の通りである。

すなわち、ストレージ管理部８１０は、グローバルプール２８０を構成する複数のローカルプール２６３がそれぞれ有する複数の空き容量のうちの最大の空き容量を提供する。これにより、当該最大の空き容量を受けた側（例えば利用者）は、作成可能なボリュームの最大容量を知ることができる。以って、作成されるボリューム２６２の容量を当該ボリューム２６２が作成されるストレージノード２００におけるローカルプール２６３の空き容量以下に維持することが期待される。例えば、ストレージ管理部８１０は、グローバルプール２８０を構成する複数のローカルプール２６３の空き容量を複数のストレージノード２００からそれぞれ収集し、収集された複数の空き容量のうちの最大の空き容量を特定し、特定された最大の空き容量を提供する（例えばホスト１００に提供する）。

なお、最大の空き容量が提供された後に要求された容量のボリュームの作成先のストレージノード２００は、要求された容量以上の空き容量を有するストレージノード２００のうちのいずれか（例えば、上記要求された容量に最も近い空き容量を有するストレージノード）でよい。これにより、ライトエラーが発生することを回避できる。例えば、ストレージ管理部８１０は、上記複数の空き容量のうち、上記要求された容量以上のいずれかの空き容量を特定し、当該空き容量を有するストレージノードを、上記要求された容量のボリューム２６２の作成先として選択してよい。

また、上記要求された容量が上記作成先のストレージノードの空き容量を超える場合（例えば、作成先として選択された後にデータがローカルプール２６３に書き込まれたが故に空き容量が上記要求された容量未満になった場合）、上記作成先のストレージノードからボリューム作成要求に対するエラーが返ってよい。これにより、作成されるボリューム２６２の容量が当該ボリューム２６２の作成先のストレージノード２００におけるローカルプール２６３の空き容量以下であることを維持することができる。なお、これは、上記最大の空き容量を超える容量のボリュームの作成が指示された場合にも有効である。

また、上記最大の空き容量は、作成可能なボリュームの容量の最大値、及び、グローバルプール２８０の空き容量、のうちの少なくとも一つとして提供される。これにより、要求可能なボリューム容量を、上記最大の空き容量以下に制限することができる。

以下、維持方式Ａを詳細に説明する。

図１１は、最大ボリューム容量取得プログラム２３３とローカル空き容量報告プログラム２２１の処理の一例を示す図である。

この処理は、最大容量取得指示（作成可能なボリュームの最大容量を取得するための指示）を利用者や上位管理ソフトウェアといった指示元から最大ボリューム容量が受領すると開始する。この処理では、ストレージノード２００の状態から作成可能な最大容量が計算され、当該最大用容量が指示元に報告される。例えば、ＣＬＩ（Command Line Interface）、ＧＵＩ（Graphical User Interface）、ＲＥＳＴ ＡＰＩ（Representational State Transfer Application programming interface）などを介して当該指示が受領される。

最大ボリューム容量取得プログラム２３３は、当該指示を受領すると、グローバルプール２８０に属する複数のローカルプール２６３を、グローバルプールテーブル２３８を参照することにより特定する（Ｓ１００）。Ｓ１００では、各ローカルプール２６３に対応したストレージ制御部番号８０４及びローカルプール番号８０５が特定される。

最大ボリューム容量取得プログラム２３３は、特定した複数のローカルプール２６３がそれぞれ配置される複数のストレージノード２００に対し、容量情報取得指示（空き容量を示す情報を取得する指示）を発行し応答を待つ（Ｓ１０１）。容量情報取得指示は、例えば、特定されたローカルプール２６３の番号を含む（つまり、いずれのローカルプール２６３の空き容量が取得対象であるかが指定される）。

容量情報取得指示を受領したストレージノード２００のローカル空き容量報告プログラム２２１は、当該指示に応答して、ローカルプールテーブル２２８から当該指示で指定されているローカルプール２６３の容量６０２及び使用済み容量６０３（空き容量＝容量６０２−使用済み容量６０３）を特定し、特定した容量６０２及び使用済み容量６０３（又は空き容量）を示す容量情報を指示元へ報告し（Ｓ１０２）、処理を終了する（Ｓ１０３）。

ローカル空き容量報告プログラム２２１からの報告を受領した最大ボリューム容量取得プログラム２３３は、Ｓ１００で特定した各ローカルプール２６３の容量情報をローカル履歴テーブル２３９に格納する（Ｓ１０４）。次に、最大ボリューム容量取得プログラム２３３は、Ｓ１００で特定した複数のローカルプール２６３の空き容量のうちの最大値を計算（特定）し（Ｓ１０５）、上記最大容量取得指示の指示元に、当該最大値を、作成可能なボリュームの最大容量として報告し（Ｓ１０６）、処理を終了する（Ｓ１０７）。

上記の説明では、空き容量を、容量６０２−使用済み容量６０３によって計算した。これを、仕様上の最大ローカルプール容量−使用済み容量６０３によって計算してもよい。例えば、ローカルプール２６３に一つ１００ＧＢの論理チャンクを１０００個登録可能な場合、仕様上の最大ローカルプール容量は１００ＴＢとなる。仕様上の最大ローカルプール容量は、当該ローカルプール２６３があるストレージノード２００への記憶デバイス２１０の増設により実現できる容量である。また、両方の計算結果を利用者に提供してもよい。記憶デバイス２１０の増設を想定しない利用者は、容量６０２−使用済み容量６０３によって計算された値を参考にボリューム作成を実施できる。記憶デバイス２１０の増設を想定しない利用者は、仕様上の最大ローカルプール容量−使用済み容量６０３によって計算された値を参考にボリューム作成を実施できる。

この様に、各ノード２００の空き容量の最大値を、作成可能なボリュームの最大容量とすることで、ライトエラーを発生させるような容量のボリュームの作成を回避することができる。ライトエラーを回避するために、図１４に示す処理も行われる。

上記の計算結果（報告される最大容量）は、図９を例に取れば、ケース（１）の場合１００ＴＢ、ケース（２）の場合５０ＴＢ、ケース（３）の場合５０ＴＢ、ケース（４）の場合２５ＴＢとなる。いずれのケースにおいてもライトエラーが発生することはない。

最大ボリューム容量取得プログラム２３３は、グローバルプール２８０に属する全てのローカルプール２６３がそれぞれ配置される全てのノード２００と通信する。

図１１の例では、最大容量取得指示を受領して管理ノード３００が各ストレージノード２００と通信を行っているが、最大ボリューム容量取得プログラム２３３は、ローカル履歴テーブル２３９を参照することで、各ストレージノード２００と通信することなく、指示元に作成可能なボリュームの最大容量を報告してもよい。具体的には、例えば、ステップＳ１００からＳ１０４が予め定期的に実行され、ローカル履歴テーブル２３９にローカルプールの容量情報が格納される。最大容量取得指示が受領された時、ステップＳ１０５からＳ１０７のみが実行される（つまり、各ストレージノード２００との通信は不要である）。この様にすることで、容量情報取得操作の応答時間を短くすることができる。

Ｓ１０５では、最大ボリューム容量取得プログラム２３３は、ローカル履歴テーブル２３９から取得した容量及び使用済み容量を用いて、最大の空き容量を計算する。上述の説明では、ローカルプール２６３の容量情報が履歴として管理されるが、最新の容量情報のみが保持されてもよい。

図１２は、ローカル履歴テーブル２３９の一例を示す図である。

ローカル履歴テーブル２３９は、グローバルプール２８０に属する各ローカルプールの容量情報を管理する。ローカル履歴テーブル２３９は、ローカルプール２６３毎にレコードを有する。各レコードは、時刻１２０１、ストレージ制御部番号１２０２、ローカルプール番号１２０３、容量１２０４、使用済み容量１２０５、登録済みチャンク数１２０６、ボリューム合計容量１２０７、及び内部容量１２０８といった情報を格納する。以下、一つのローカルプール２６３を例に取る（図１２の説明において「対象ローカルプール」）。

時刻１２０１は、対象ローカルプールの容量情報が収集された時刻を示す。

ストレージ制御部番号１２０２及びローカルプール番号１２０３は、対象ローカルプールが割り当てられたストレージ制御部２６０の番号と、対象ローカルプール２６３の番号とをそれぞれ示す。ストレージ制御部番号１２０２及びローカルプール番号１２０３は、Ｓ１００で特定されたストレージ制御部番号８０４及びローカルプール番号８０５と同じである。

情報１２０４〜１２０８は、上述の容量情報に含まれる情報でよい。具体的には、容量１２０４は、対象ローカルプールの容量６０２に相当する。使用済み容量１２０５は、対象ローカルプールの使用済み容量６０３に相当する。登録済みチャンク数１２０６は、対象ローカルプールに登録済みのチャンク数を示す。ボリューム合計容量１２０７は、対象ローカルプールに関連付けられている全ボリューム２６２の合計容量を示す。内部容量１２０８は、対象ローカルプール２６３を有するストレージノードの内部容量を示す。情報１２０４〜１２０８は、ステップＳ１０２で報告され、ステップＳ１０４でローカル履歴テーブル２３９に格納される。維持方式Ａが採用されている場合、時刻１２０１、ストレージ制御部番号１２０２、ローカルプール番号１２０３、容量１２０４及び使用済み容量１２０５が使用される。維持方式Ｂが採用されている場合、その他の情報１２０６〜１２０８が使用される。なお、内部容量１２０８があれば、ローカルプールの容量又は空き容量よりも大きな容量を作成可能なボリュームの容量として報告されても、内部容量が枯渇しないような制御が行われることで（例えば、内部容量の空き容量がゼロになる前に記憶デバイスを追加するといった措置が取られることで）、ライトエラーが発生する可能性を低減することが期待できる。

図１１では、利用者や上位管理ソフトウェアが作成可能なボリュームの最大容量が取得する。しかし、上位管理ソフトウェアとの間のインタフェースとして、作成可能なボリュームの最大容量を取得するインタフェースが存在しない場合があり得る。この様な場合は、上記最大容量が、グローバルプール２８０の空き容量として返されてよい。

図１３は、容量情報取得プログラム２３４の処理の一例を示す図である。容量情報取得プログラム２３４は、グローバルプール２８０の容量情報を取得するためのプログラムである。

容量情報取得プログラム２３４は、グローバルプール２８０の容量情報取得の指示を受領するとステップＳ１００からＳ１０４と同じ処理を実行することで、グローバルプール２８０に属する各ローカルプールの情報を各ストレージノード２００から取得する（Ｓ２００）。なお、最大ボリューム容量取得プログラム２３３と同様に、ローカル履歴テーブル２３９を参照することで各ストレージノード２００との通信が回避されてもよい。

次に、容量情報取得プログラム２３４は、グローバルプール２８０に属する複数のローカルプールの空き容量のうちの最大値を計算し（Ｓ２０１）、グローバルプール２８０の使用済み容量８０３（図８参照）を、容量８０２から最大値（Ｓ２０１の計算結果）を減じた値に更新する（Ｓ２０２）。

最後に、容量情報取得プログラム２３４は、グローバルプール２８０の容量、空き容量、使用済み容量を含んだ容量情報を指示元に報告し（Ｓ２０３）、処理を終了する（Ｓ２０４）。

この様にすることで、図１１で報告した作成可能なボリュームの最大容量をグローバルプールの空き容量として報告することができる。これによりライトエラーを発生させるような容量のボリュームが作成されることを回避することができる。

図１１及び図１３を参照して、ライトエラーを発生させる可能性がある容量のボリュームが作成されることを回避する処理を説明した。図１１で報告されるボリューム容量、図１３で報告される空きプール容量より小さい容量のボリュームを作成した場合でも、空き容量が少ないストレージノードがボリュームの作成先である場合、ライトエラーが発生してしまう可能性がある。

図１４は、ボリューム作成ノード決定プログラム（１）２３５とボリューム作成プログラム２２２の処理の一例を示す図である。ボリューム作成ノード決定プログラム（１）２３５は、作成可能なボリュームの容量に基づき、ライトエラーが起こらないよう、ボリュームの作成先とするストレージ制御部（ストレージノード２００）を決定する。ボリューム作成プログラム２２２は、指定されたボリュームを作成するプログラムである。

ボリューム作成ノード決定プログラム（１）２３５は、ボリューム作成要求を例えば利用者からＧＵＩ、ＣＬＩ、または、ＡＰＩ経由で受領し（Ｓ３００）、ステップＳ１００からＳ１０４と同じ処理を実行する（Ｓ３０１）。ローカル履歴テーブル２３９を参照することでステップＳ３０１の実行が回避されてもよい。

次に、ボリューム作成ノード決定プログラム（１）２３５は、指定されたボリューム容量以上の空き容量を有するローカルプール２６３をリストアップし（Ｓ３０２）、該当するローカルプール２６３が存在するか否かを判断する（Ｓ３０３）。もし、該当するローカルプール２６３が存在しない場合（Ｓ３０３：Ｎｏ）、作成可能容量を超えた容量が指定されていることをボリューム作成ノード決定プログラム（１）２３５がボリューム作成要求の送信元（例えば依頼者）に報告し（Ｓ３１３）、処理を終了する（Ｓ３１２）。本プログラムの一例では、作成可能容量を超えた容量が指定された場合、エラーを報告したが、ボリューム作成を実施してもよい。図１１及び図１２の処理で、作成可能なボリュームの最大容量を利用者に報告済みである。このため、その容量を超過したボリュームの作成指示を行った場合、ライト不可を許容したと考えることができる。また、ストレージノード２００への記憶デバイス２１０の増設を行う利用者も存在するためである。

一方で、該当するローカルプール２６３が存在する場合（Ｓ３０３：Ｙｅｓ）、ボリューム作成ノード決定プログラム（１）２３５は、リストアップされた一つ以上のローカルプール２６３から一つのローカルプールを選択し、選択したローカルプールを有するストレージノード２００にボリューム作成指示を発行する（Ｓ３０４）。リストアップされたどのローカルプール２６３も、指定ボリューム容量以上の空き容量を有するため、どのローカルプール２６３が選択されてもよい。例えば、最も空き容量が大きいローカルプール２６３が選択されてもよいし、ラウンドロビンなどの選択アルゴリズムによりローカルプール２６３が選択されてもよい。ボリューム作成指示では、例えば、選択されたローカルプール２６３の番号が指定される。

ボリューム作成指示を受領したストレージノード２００のボリューム作成プログラム２２２は、指定ボリューム容量が空き容量（ボリューム作成指示から特定されるローカルプール２６３の容量６０２及び使用済み容量６０３から特定される空き容量）以下か否かを判断する（Ｓ３０６）。すなわち、指定ボリューム容量以上の空き容量を有するローカルプール２６３がリストアップされても、当該ローカルプール２６３を有するノード２００のボリューム作成プログラム２２２は、ボリューム作成指示を受けたときに、当該ローカルプール２６３に指定ボリューム容量以上の空き容量があるか否かを判断する。当該ローカルプール２６３がリストアップされてから当該ローカルプール２６３を有するノード２００がボリューム作成指示を受けるまでの間に、当該ローカルプール２６３の使用済み容量が増え、結果として、当該ローカルプール２６３の空き容量が、指定ボリューム容量未満になっている可能性があるからである。指定ボリューム容量が空き容量以下の場合（Ｓ３０６：Ｙｅｓ）、ボリューム作成プログラム２２２は、ボリュームテーブル２２９を更新することで、ボリューム作成を実行し（Ｓ３０７）、完了を報告する（完了応答を返す）（Ｓ３０９）。

指定ボリューム容量が空き容量より大きい場合（Ｓ３０６：Ｎｏ）、ボリューム作成プログラム２２２は、作成可能容量を超えた容量が指定されていることを報告する（失敗応答を返す）（Ｓ３０８）。

ボリューム作成プログラム２２２からの応答を受領したボリューム作成ノード決定プログラム（１）２３５は、ボリューム作成が成功したか否かを判断する（Ｓ３１０）。

ボリューム作成が失敗である場合（Ｓ３１０：Ｎｏ）、ボリューム作成ノード決定プログラム（１）２３５は、作成可能容量を超えた容量が指定されていることをボリューム作成要求の送信元に報告し（Ｓ３１３）、処理を終了する（Ｓ３１２）。指定ボリューム容量以上の空き容量を有する他のローカルプールがある場合、処理がステップＳ３０４に戻り、当該他のローカルプールを有するストレージノード２００にボリューム作成指示が発行されてもよい。

一方、ボリューム作成が成功である場合（Ｓ３１０：Ｙｅｓ）、ボリューム作成ノード決定プログラム（１）２３５は、作成したボリュームに関する情報をボリューム管理テーブル２４２に登録し（Ｓ３１１）、処理を終了する（Ｓ３１２）。

図１１又は図１３に記載した処理と図１４に記載した処理によりストレージノード２００が提供可能な容量を超える容量のボリュームが作成されることによるライトエラーを回避することが可能となる。

図１１又は図１３の処理を行わず、図１４の処理だけでもライトエラーを回避することができる。

＜維持方式Ｂ＞

ストレージ管理部８１０は、該当のストレージノード２００についてチャンク追加を行う。チャンク追加は、当該ストレージノード２００のローカルプール２６３に一つ以上の論理チャンク２６４を追加することである。これにより、当該ローカルプール２６３の空き容量が増えるので、当該ストレージノード２００に作成されるボリュームの容量が当該ローカルプール２６３の空き容量以下であることを維持することができる。なお、各ストレージノード２００では、当該ストレージノード２００が有するローカルプール２６３を構成する論理チャンク２６４の数に上限がある。具体的には、例えば、ローカルプールテーブル２２８において、一つのローカルプール２６３についてレコードの数に上限がある。このため、ローカルプールテーブル２２８の肥大化が抑えられる。

チャンク追加として、第１のチャンク追加が採用されてよい。第１のチャンク追加において、追加される一つ以上の論理チャンク２６４の少なくとも一つは、相対的に大サイズの論理チャンク２６４（例えば、通常のサイズよりも大きなサイズの論理チャンク２６４）である。これにより、制限された論理チャンク数の範囲で、ローカルプール２６３の容量を大きな容量とすることができ、以って、上述の容量関係を維持することができる。

チャンク追加として、第２のチャンク追加が採用されてよい。第２のチャンク追加において、追加される一つ以上の論理チャンクの少なくとも一つは、上記該当のストレージノード２００以外の少なくとも一つのストレージノード２００から融通された論理チャンクである。これにより、該当のストレージノード２００において論理チャンクや内部容量が不足していても、当該ストレージノード２００について上述の容量関係を維持することができる。なお、融通される論理チャンクは、相対的に大サイズの論理チャンクであることが好ましい。制限された論理チャンク数の範囲で、ローカルプール２６３の容量を大きな容量とすることができるからである。しかし、論理チャンク２６４を提供する側のストレージノード２００内の内部容量又はそれの空き容量が容量不足を意味する条件を満たす程に小さい場合、融通される論理チャンクは、通常サイズの論理チャンクでよい。また、内部容量が不足している場合などは、物理チャンクを融通することでも、当該ストレージノード２００について上述の容量関係を維持することができる。

上述したいずれのチャンク追加においても、追加される一つ以上の論理チャンク２６４の各々は、チャンク追加の実行前に作成済みの論理チャンク２６４であってもよい。その場合、チャンク追加を迅速に完了することが期待される。

チャンク追加に代えて又は加えて、上述の容量関係を維持するために、ボリューム移行が行われてよい。具体的には、上述の該当のストレージノード２００が有するローカルプール２６３に関連付いている少なくとも一つのボリューム２６２が、当該ローカルプール２６３の空き容量よりも大きな空き容量を持つローカルプール２６３に移行する。これにより、該当のストレージノード２００内のローカルプール２６３の空き容量が増えるため、上述の容量関係を維持することができる。なお、ボリューム移行は、例えばストレージ管理部８１０により行われる。また、移行元のローカルプール２６３と移行先のローカルプール２６３は、同一のストレージノード２００内にあってもよいし異なる複数のストレージノード２００内にあってもよい。

チャンク追加及びボリューム移行の少なくとも一つに代えて又は加えて、上述の容量関係を維持するために、チャンク結合が行われる。チャンク結合とは、上述の該当のストレージノード２００が有するローカルプール２６３の一部である二つ以上の論理チャンク２６４に代えて、当該二つ以上の論理チャンク２６４の各々よりも大サイズであり当該二つ以上の論理チャンク２６４内のデータを格納した論理チャンク２６４（つまり、当該二つ以上の論理チャンクを結合した一つの論理チャンク２６４）を、当該ローカルプール２６３の構成要素とすることである。これにより、制限された論理チャンク数の範囲で、ローカルプール２６３の容量を大きな容量とすることができ（データの移行に伴い空きとなった論理チャンクがローカルプール２６３から解放されれば登録可能チャンク数（論理チャンク数の上限と登録済みの論理チャンク数との差分（残数））が増えて）、以って、上述の容量関係を維持することができる。なお、チャンク結合は、例えばストレージ管理部８１０により行われる。

チャンク追加、ボリューム移行及びチャンク結合のうちの少なくとも一つが、該当のストレージノード２００についての不足条件が満たされた場合に行われる。不足条件とは、ローカルプール２６３を構成する論理チャンクの数が当該ストレージノード２００についての上限（論理チャンク数の上限）に近いとされた条件、言い換えれば、当該ローカルプール２６３の登録可能チャンク数が不足したと定義された条件である。不足条件が満たされたときにチャンク追加（特に大サイズの論理チャンク２６４の追加）、ボリューム移行及びチャンク結合の少なくとも一つが行われることで、制限された論理チャンク数の範囲で、上述の容量関係を維持することができる。なお、不足条件が満たされた場合に行われるチャンク追加において追加されるチャンクは、相対的に大サイズの論理チャンク２６４であることが好ましいが、不足条件が満たされていない間におけるローカルプール２６３を構成する各論理チャンク２６４のサイズは通常サイズ（相対的に小サイズ）であることが好ましい。或る論理チャンク２６４に対応した或る二つの物理チャンク２１１にＩ／Ｏが集中する、或いは、或る論理チャンク２６４について使用されない領域のサイズが大きいままであるといったことを避けるためである。

第二のチャンク追加及びボリューム移行のうちの少なくとも一つは、不足条件が満たされた場合に限らず、該当のストレージノード２００内の内部容量（ローカルプール２６３の基になる容量）の空き容量が不足しているとされた条件が満たされた場合に行われてよい。このような場合に第二のチャンク追加が行われれば、追加された論理チャンク２６４に関しては、当該論理チャンク２６４にデータが書かれても内部容量の空き容量が消費はされないので、ライトエラーが発生する可能性を低減できる。また、このような場合にボリューム移行が行われれば、内部容量の空き容量が増えるので、ライトエラーが発生する可能性を低減できる。

チャンク追加、ボリューム移行及びチャンク結合のうちの少なくとも一つに代えて又は加えて、容量関係を維持するために、チャンク交換が行われる。チャンク交換とは、該当のストレージノード２００が有するローカルプール２６３の一部である一つ以上の論理チャンク２６４を、当該一つ以上の論理チャンク２６４の各々よりもそれぞれ大サイズであり当該ストレージノード２００以外のいずれかのストレージノード２００が有する一つ以上の論理チャンク２６４と交換することである。これにより、該当のストレージノード２００が有するローカルプール２６３に関し論理チャンク数がその上限に達しても、ローカルプール２６３の空き容量を増やすことができ、以って、上述の容量関係を維持することができる。なお、チャンク交換は、例えばストレージ管理部８１０により行われる。

以下、維持方式Ｂを詳細に説明する。

図１５は、チャンク作成プログラム２２３の処理の一例を示す図である。本プログラム２２３は、チャンク作成時に、ローカルプール２６３へ登録できる論理チャンクの数が上限に達する場合、大きなサイズのチャンクを作成することで、論理チャンク数の上限の範囲でローカルプール容量を大きくする。

チャンク作成プログラム２２３は、チャンク作成指示を受領し（Ｓ４００）、ローカルプールの登録可能チャンク数に関する「不足」があるか否かをチェックする（Ｓ４０１）。

Ｓ４００については、管理ノード３００がチャンク作成指示を送信してもよいし、図示していないがストレージノード２００への記憶デバイス増設プログラムがチャンク作成指示を送信してもよいし、ストレージノード２００が記憶デバイス２１０の増設や既設記憶デバイス２１０のチャンク未作成領域を検出したプログラムがチャンク作成指示を送信してもよい。また、論理チャンク２６４を作成するためノード番号（マスタ）とノード番号（ミラー）が指示元からパラメタとして渡される。

Ｓ４０１については、「不足」は、ローカルプール２６３の登録可能チャンク数が一定数以下、又は、論理チャンク数上限に対する登録可能チャンク数の比率が所定比率以下であること、と定義されてもよい。また、「不足」は、ローカルプール２６３の空き容量が一定以下であることと定義されてもよい。また、「不足」は、ローカルプール２６３に関する作成済みボリュームの合計容量が一定上であり、通常の論理チャンクサイズでは容量が不足であると定義されてもよい。例えば、論理チャンクサイズ１ＧＢであり、１０００個の論理チャンク２６４が登録できる場合、１０００ＧＢ（＝１ＧＢ×１０００）がローカルプール２６３の容量となる。既に、当該ローカルプール２６３に関して合計１５００ＧＢの１以上のボリュームが作成されている場合、不足があると判断できる。上述の定義以外の定義が「不足」でもよい。

上記「不足」がある場合（Ｓ４０１：Ｙｅｓ）、チャンク作成プログラム２２３は、通常サイズより大サイズの物理チャンクを、マスタノード（パラメタとして指定されたノード番号（マスタ）のストレージノード）とミラーノード（パラメタとして指定されたノード番号（ミラー）のストレージノード）の各々から作成する（Ｓ４０２）。結果、マスタの物理チャンクとミラーの物理チャンクが作成される。

一方、上記「不足」がない場合（Ｓ４０１：Ｎｏ）、チャンク作成プログラム２２３は、通常サイズの物理チャンクを、マスタノード及びミラーノードの各々から作成する（Ｓ４０３）。

ステップＳ４０２又はＳ４０３で作成されたマスタの物理チャンクとミラーの物理チャンクに関する情報は、作成される論理チャンクに対応したレコード（論理チャンクテーブル２３２における新しいレコード）に登録される。

通常サイズは固定でもよいが、通常サイズより大きいサイズは固定であってもなくてもよい。後者の場合、例えば、必要なチャンクサイズが計算され、計算されたチャンクサイズが大サイズとされてもよい。具体的には、例えば、１ＧＢのチャンクが９００個作成済み、残りの作成可能チャンク数が１００個、作成済みボリューム容量が１５００ＧＢの状態を考える。その場合、残り１００個のチャンクで少なくとも６００ＧＢの容量を作成する必要があるため、チャンクサイズを６ＧＢとする。なお、利用者や上位システムからチャンクサイズを受け付けるインタフェースをストレージ管理部８１０（例えばノード２００又は３００）が提供してもよい。当該インタフェースを介して、通常サイズと大サイズの両方のチャンクサイズが受け付けられてもよいし、大サイズのみが受け付けられてもよい。チャンクサイズの受け付けに関しては、図１５に例示のチャンク作成に限定されず、他の処理に関しても適用されてもよい。

Ｓ４０２又はＳ４０３に続き、チャンク作成プログラム２２３は、ペア相手ノードの物理チャンク作成済みを確認する（Ｓ４０４）。ペア相手とは、ノード番号（マスタ）で識別されるストレージノードの場合、ノード番号（ミラー）で識別されるストレージノードのことである。

物理チャンク作成及びその確認後、チャンク作成プログラム２２３は、マスタの物理チャンクとミラーの物理チャンクが関連付けられた論理チャンク２６４を作成する（Ｓ４０５）。論理チャンク２６４の作成では、論理チャンクテーブル２３２に、当該論理チャンク２６４に対応した新しいレコードが登録される。

最後に、チャンク作成プログラム２２３は、ローカルプールテーブル２２８へ、作成された論理チャンク２６４に関する情報を登録し（Ｓ４０６）、処理を終了する（Ｓ４０７）。ローカルプールテーブル２２８への論理チャンク登録は、ローカルプールテーブル２２８への論理チャンク番号６０４、ページ番号６０５、ページ割当状況６０６、割当先ボリューム番号６０７の追加と、容量６０２の更新とを含む。

図１５に示した処理に、下記のうちの少なくとも一つが採用されてよい。
・物理チャンク２１１の作成と、論理チャンク２６４の作成が、別々の契機で行われる。
・論理チャンク２６４の作成と、論理チャンク２６４のローカルプール２６３への登録とが、別々の契機で行われる。例えば、ローカルプール２６３の空き容量が不足に近づいたときローカルプール２６３へ論理チャンク２６４が登録されてもよい。その様にすることで、他のストレージノード２００へ論理チャンクや物理チャンクを融通する時に、格納されているデータを他の論理チャンクや物理チャンクへ移動する必要がない。融通の迅速性を向上することができる。

上記の様にすることで、図９を例に取れば、ケース（１）やケース（２）に関して、１００ＴＢ以上の容量のローカルプール２６３を作成可能となり、ライトエラーの発生を回避できる。

図１５の例によれば、大サイズの物理チャンクが作成され、作成された大サイズの物理チャンクが関連付けられた論理チャンクが作成され、結果として、作成された論理チャンクは大サイズの論理チャンクであるが、大サイズの論理チャンクを作成する方法として、別の方法、例えば、通常サイズの複数の物理チャンクが関連付けられた大サイズの論理チャンクを作成する方法もある。具体的には、図５に示した論理チャンクテーブル２３２の一つの論理チャンク番号に１以上のノード番号（マスタ）、複数の物理チャンク番号（マスタ）、１以上のノード番号（ミラー）、物理チャンク番号（マスタ）と同数の物理チャンク番号（ミラー）を対応付ける。例えば、論理チャンク０に、マスタの物理チャンクとして、ノード０の物理チャンク０と物理チャンク１を関連付ける。これにより論理チャンクを修正することなくサイズ２００ＧＢの論理チャンク（通常サイズより大サイズの論理チャンクの一例）を作成することができる。当該別の方法が採用される場合、図１５のステップＳ６０２で、通常サイズの物理チャンクが作成され、ステップＳ６０５で、一つの論理チャンク番号に対応付けられる複数の物理チャンクに関する情報が論理チャンクテーブル２３２に格納されてよい。

図１６は、不足モニタリングプログラム（１）２３６の処理の一例を示す図である。本プログラム２３６は、各ローカルプール２６３の登録可能チャンク数をモニタし、登録可能チャンク数が不足している場合にボリュームを別のノード２００に移行することでチャンク数不足を解消する。

不足モニタリングプログラム（１）２３６は、各ノード２００のローカルプール２６３の容量、使用済み容量、登録済みチャンク数、ボリューム合計容量及び内部容量といった情報を収集し（Ｓ６００）、収集した情報をローカル履歴テーブル２３９に格納する（Ｓ６０１）。

次に、不足モニタリングプログラム（１）２３６は、登録可能チャンク数が不足しているローカルプール２６３（例えば、登録可能な論理チャンク数の上限に対する登録済みチャンク数の割合が一定値を超えているローカルプール２６３）の有無をチェックする（Ｓ６０２）。登録可能チャンク数が不足しているローカルプール２６３が存在しない場合（Ｓ６０２：Ｎｏ）、不足モニタリングプログラム（１）２３６は、内部容量が不足しているローカルプール２６３（例えば、内部容量に対するそれの空き容量の割合が一定値未満のローカルプール２６３）が存在しているか否かをチェックする（Ｓ６０３）。内部容量が不足しているローカルプール２６３が存在しない場合（Ｓ６０３：Ｎｏ）、不足モニタリングプログラム（１）２３６は処理を終了する（Ｓ６０７）。

一方、Ｓ６０２：Ｙｅｓ又はＳ６０３：Ｙｅｓの場合、不足モニタリングプログラム（１）２３６は、容量に空きがあるローカルプール２６３（例えば、容量に対する使用済み容量が一定値未満のローカルプール２６３）が存在するか否かをチェックする（Ｓ６０４）。ステップＳ６０２またはＳ６０３で特定したローカルプール２６３から移動される容量が追加されても、容量に空きがあるローカルプール２６３を検出する。この様にすることで、ボリュームのボリューム移行の頻発を回避できる。

容量に空きがあるローカルプール２６３が存在する場合（Ｓ６０４：Ｙｅｓ）、不足モニタリングプログラム（１）２３６は、移行元ローカルプール２３６（登録可能チャンク数、又は、内部容量が不足しているローカルプール２６３）から移行先ローカルプール２３６（容量に空きがあるローカルプール２６３）にボリュームを移行することの指示であるボリューム移行指示を送信する（Ｓ６０５）。当該指示の送信先は、移行元ローカルプール２３６と移行先ローカルプール２３６の少なくとも一つを有する一つ以上のストレージノード２００の各々でよい。当該指示に応答して、移行元ローカルプール２３６から移行先ローカルプール２３６にボリュームが移行する。移行対象のボリュームの番号が、当該指示のパラメタとして指定されてよい。移行対象のボリュームは、移行元ローカルプール２３６に関して不足の度合に応じて決定されてよい。

一方で、容量に空きがあるローカルプールが存在しない場合（Ｓ６０４：Ｎｏ）、不足モニタリングプログラム（１）２３６は、アラートを例えば管理者又は利用者に報告する（Ｓ６０６）。アラートは、容量枯渇の通知としてのアラートでもよいし、記憶デバイスの追加やボリュームの削除を促すためのアラートでもよい。

最後に、不足モニタリングプログラム（１）２３６は処理を終了する（Ｓ６０７）。

ボリューム移行では、移行元から移行先に移行対象ボリューム内のデータが移行する。ボリューム移行のための機能として、Non-Disruptive Volume Migrationなどの機能が知られており、この様な機能を使用することができる。

上記の様にすることで、図９を例に取れば、ケース（２）やケース（４）に関して、ストレージノード０の使用済み容量を、ストレージノード１に移動することで、ストレージノード０に空き容量を作ることができる。

図１７は、不足モニタリングプログラム（２）２３７、チャンク貸出プログラム２２４、及びチャンク受取プログラム２２５の処理の一例を示す図である。これらプログラムは、各ローカルプール２６３の登録可能チャンク数をモニタし、登録可能チャンク数が不足している場合に他のノードにある大サイズ（又は通常サイズ）の論理チャンクを融通することで容量不足を解消する。

不足モニタリングプログラム（２）２３７は、図１６のステップＳ６００からＳ６０３と同様の処理を実行する（Ｓ７００）。ステップＳ６０２又はステップＳ６０３の結果のいずれかがＹｅｓの場合、ステップＳ７０１からＳ７０９が実行される。

不足モニタリングプログラム（２）２３７は、大サイズの論理チャンクを持つノード２００を特定し（Ｓ７０１）、当該ノード２００に、当該大サイズの論理チャンクの貸し出し指示を送信する（Ｓ７０２）。

論理チャンクの貸し出し指示を受領したストレージノード２００のチャンク貸出プログラム２２４は、論理チャンクを貸し出し、完了を報告する（Ｓ７０３）。最後に、チャンク貸出プログラム２２４は処理を終了する（Ｓ７０４）。論理チャンクの貸し出しでは、論理チャンクテーブル２３２に、論理チャンクが貸し出したことが記録される。具体的には、例えば、論理チャンクテーブル２３２に、貸し出された論理チャンクに対応するレコードに、貸出先ストレージノード番号が格納されるものとする。ステップＳ７０３では、貸し出した論理チャンクに関して、論理チャンクテーブル２３２に格納されている情報が、指示元である管理ノード３００に渡される。貸出先ストレージノード２００は、Ｓ７００において、不足ノード２００（ステップＳ６０２又はステップＳ６０３の結果のいずれかがＹｅｓに該当するノード２００）である。貸し出し指示で、当該不足ノード２００に関する情報（例えばノード番号）がパラメタとして指定されていてよい。

チャンク貸出プログラム２２４から報告を受領した不足モニタリングプログラム（２）２３７は、不足ノード２００にチャンク割り当て指示を送信する（Ｓ７０５）。この指示では、貸し出された論理チャンクに関する情報（貸し出し元のノード２００における論理チャンクテーブル２３２に格納されている情報）がパラメタとして指定される。

チャンク割り当て指示を受領した不足ノード２００のチャンク受取プログラム２２５は、貸し出された論理チャンクに関する情報を、不足ノード２００における論理チャンクテーブル２３２に登録し、完了を報告する（Ｓ７０６）。Ｓ７０６では、チャンク受取プログラム２２５は、空いている論理チャンク番号を確保し、当該論理チャンク番号により識別されるレコードに、パラメタとして渡された情報（ノード番号（マスタ）、物理チャンク番号（マスタ）、ノード番号（ミラー）、物理チャンク番号（ミラー）、サイズ、割当先ストレージ制御部番号）を論理チャンクテーブル２３２に格納する。

最後に、チャンク受取プログラム２２５は、ローカルプール２６３へ、貸し出された論理チャンク２６４を登録し（Ｓ７０７）、処理を終了する（Ｓ７０８）。Ｓ７０７では、Ｓ７０６で論理チャンクテーブル２３２に登録された論理チャンクに関する情報が不足ノード２００におけるローカルプールテーブル２２８に登録される。

チャンク受取プログラム２２５から報告を受領した不足モニタリングプログラム（２）２３７は、処理を終了する（Ｓ７０９）。

図１７の例では、論理チャンク２６４を貸し出す処理を説明したが、物理チャンク２１１が貸し出されてもよい。その場合、物理チャンク２１１を受け取る不足ノード２００は複数の貸し出された物理チャンク２１１を用いて論理チャンク２６４を作成する。物理チャンク２１１の貸し出しに伴い論理チャンクが不足ノード２００に追加されることも、広義には、論理チャンク２６４の貸し出しに含まれてよい。

図１７の例では、貸し出した論理チャンクの管理方法、受け取った論理チャンクの管理方法は一例であり、説明した方法以外の管理方法が採用されてもよい。

上記の様にすることで、図９を例に取れば、ケース（３）やケース（４）に関して、５０ＴＢ以上のローカルプールを作成可能となり、ライトエラーの発生を回避できる。

不足モニタリングプログラム（１）２３６や不足モニタリングプログラム（２）２３７の結果、登録可能チャンク数が不足するローカルプール２６３が存在する場合、以降作成するチャンクのサイズが変更されてもよい。このため、管理ノード３００は、今後作成するチャンクサイズを管理してもよい。新しいノード２００をストレージシステム１６０に追加した場合や、ストレージノード２００に新しい記憶デバイス２１０を追加した場合に、管理ノード３００が管理しているチャンクサイズをチャンク作成プログラム２２３に通知してもよい。

また、貸し出される（融通される）チャンクのサイズは、大サイズに代えて、通常サイズでもよい。例えば、不足ノード２００以外のいずれのノード２００についても、内部容量の空き容量が不足している場合、不足ノード２００以外のいずれかのノード２００から貸し出されるチャンク（論理チャンク２６４又は物理チャンク２１１）のサイズは通常サイズでよい。

図１８は、チャンク交換プログラム２２６の処理の一例である。本プログラム２２６は、ローカルプール２６３に登録済みの論理チャンスの数がその上限に達している場合（ローカルプールテーブル２２８に論理チャンクのレコードを追加できない場合）、登録済みの論理チャンクを減らし、別の大サイズの論理チャンクを登録することで、ローカルプール２６３の容量を増やす。本プログラム２２６は、例えば、図１５のステップＳ４０６や図１７のＳ７０７の代わりに実行される。

チャンク交換プログラム２２６は、ローカルプール２６３に論理チャンク２６４を追加可能か否かを判断する（Ｓ８００）。この判断は、ローカルプールテーブル２２８に登録可能なレコード数がＮ個（Ｎは０以上の整数）であるか否かの判断でよい。この判断以外の判断が採用されてもよい。

ローカルプール２６３に論理チャンク２６４を追加可能な場合（Ｓ８００：Ｙｅｓ）、チャンク交換プログラム２２６は、追加予定の論理チャンク２６４をローカルプール２６３に追加し（Ｓ８０３）、処理を終了する（Ｓ８０４）。

一方、ローカルプール２６３に論理チャンク２６４を追加不能な場合（Ｓ８００：Ｎｏ）、チャンク交換プログラム２２６は、追加予定の論理チャンク２６４より小さい登録済みの論理チャンク２６４があるか否かを判断する（Ｓ８０１）。追加予定の論理チャンク２６４のサイズと、ローカルプール２６３に登録済みの各論理チャンク２６４のサイズは、論理チャンクテーブル２３２から特定される。

追加予定の論理チャンクより小さい登録済みの論理チャンク２６４がない場合（Ｓ８０１：Ｎｏ）、チャンク交換プログラム２２６は処理を終了する（Ｓ８０４）。

追加予定の論理チャンクより小さい登録済みの論理チャンクがある場合（Ｓ８０１：Ｙｅｓ）、チャンク交換プログラム２２６は、当該論理チャンクをローカルプール２６３から減設する（Ｓ８０２）。Ｓ８０２では、チャンク交換プログラム２２６は、当該論理チャンク２６４に格納されているデータを他の論理チャンク２６４へ移動する。具体的には、チャンク交換プログラム２２６は、ローカルプールテーブル２２８を基に、当該論理チャンク２６４のうちの割当済みページを特定する。チャンク交換プログラム２２６は、当該特定されたページに格納されているデータを、他の論理チャンク内のページにコピーする。チャンク交換プログラム２２６は、ボリュームテーブル２２９に格納するページ情報、移行元ページのページ割当状況６０６、及び、移行先ページのページ割当状況６０６を更新する。データのコピー量を少なくするため、減設対象の論理チャンクとして、割当済みページの数が最も少ない論理チャンクが選択されてもよい。

最後に、チャンク交換プログラム２２６は、追加予定の論理チャンクをローカルプールに追加し（Ｓ８０３）、処理を終了する（Ｓ８０４）。

上記の様にすることで、図９を例に取れば、ケース（１）やケース（２）に関して、１００ＴＢ以上のローカルプールを作成可能となり、ライトエラーの発生を回避できる。

図１９は、チャンク結合プログラム２２７の処理の一例である。本プログラム２２７は、ローカルプール２６３の登録済みチャンク数がその上限に達する場合、複数の論理チャンク２６４を結合することで一つの新しい論理チャンク２６４を作成し当該一つの論理チャンク２６４をローカルプール２６３へ登録する。

チャンク結合プログラム２２７は、ローカルプール２６３の登録可能チャンク数が不足しているか否かをチェックする（Ｓ９００）。ローカルプール２６３の登録可能チャンク数が不足していない場合（Ｓ９００：Ｎｏ）、チャンク結合プログラム２２７は処理を終了する（Ｓ９０９）。

ローカルプール２６３の登録可能チャンク数が不足している場合（Ｓ９００：Ｙｅｓ）、チャンク結合プログラム２２７は、ローカルプール２６３から減設する複数の論理チャンク２６４を選択し（Ｓ９０１）、選択した複数の論理チャンク２６４をローカルプール２６３から減設する（Ｓ９０２）。後に行われる物理チャンク結合を容易にするため、物理チャンク２１１が連続する複数の論理チャンク２６４が選択されてもよい。減設処理は、図１８のＳ８０２と同じである。

次に、チャンク結合プログラム２２７は、当該複数の論理チャンク２６４に関連付いた複数の物理チャンク２１１を有する複数のストレージノード２００へチャンク結合指示を送信する（Ｓ９０３）。論理チャンクテーブル２３２を参照することで、チャンク結合指示の送信先となるストレージノード２００（すなわち、減設対象として選択された複数の論理チャンク２６４に関連付いている複数の物理チャンク２１１を有する複数のストレージノード２００の各々）を特定できる。通知を受領したストレージノード２００は、ステップＳ９０４とＳ９０５を実行し、物理チャンク２１１を結合する。図１９の例は、通知を出したストレージノード２００も、減設対象の論理チャンク２６４の少なくとも一つに関連付いた物理チャンク２１１を有しているため、ステップＳ９０４とＳ９０５を実行する。

チャンク結合プログラム２２７は、論理チャンク２６４を削除し（Ｓ９０４）、物理チャンク２１１を結合する（Ｓ９０５）。論理チャンク２６４の削除は、論理チャンクテーブル２３２から減設対象の各論理チャンクのレコードを削除することである。記憶デバイス２１０上のアドレスが連続する複数の物理チャンクの場合、先頭の物理チャンクのサイズ４０４（図４参照）を更新し、後続の物理チャンクの情報を削除することで容易に物理チャンクを結合することができる。例えば、図４の例で、物理チャンク０及び１を結合する場合、チャンク結合プログラム２２７は、物理チャンク０のレコードのサイズ４０４を“２００”に更新し、物理チャンク１のレコードを物理チャンクテーブル２３１から削除する。連続しない複数の物理チャンクも結合することができる。例えば、チャンク結合プログラム２２７は、異なる物理チャンク２１１の各々に同一の物理チャンク番号を付与する（つまり物理チャンク番号を共通とする）ことで結合できる。関連する物理チャンクであることを示すためにレコード間を関連付けるポインタ情報が物理チャンクテーブル２３１に格納されてもよい。例えば、図４の例で、チャンク結合プログラム２２７は、物理チャンク０及び３を結合する場合、物理チャンク３の物理チャンク番号を物理チャンク番号“０”に修正する。物理チャンクにアクセスするときは、チャンク内のオフセットを用いて、物理チャンクテーブル２３１のどのレコードであるかを特定できる。これ以外の方法で結合することも考えられる。

チャンク結合プログラム２２７は、各ストレージノード２００の物理チャンク結合の完了を確認し（Ｓ９０６）、結合した物理チャンクを用いて論理チャンクを作成する（Ｓ９０７）。この処理は、論理チャンクテーブル２３２に、結合した物理チャンクの情報を含むレコードを登録することで実現される。Ｓ９０７で、複数の結合された物理チャンクが関連付けられた一つの論理チャンク２６４が生成される。

最後に、チャンク結合プログラム２２７は、作成した論理チャンク２６４をローカルプール２６３へ登録し（Ｓ９０８）、処理を終了する（Ｓ９０９）。作成した論理チャンク２６４のローカルプール２６３への登録は、ローカルプールテーブル２２８に論理チャンク番号６０４、ページ番号６０５、ページ割当状況６０６、及び割当先ボリューム番号６０７を格納することで実現される。

上記の様にすることで、図９を例に取れば、ケース（１）やケース（２）に関して、１００ＴＢ以上のローカルプールを作成可能となり、ライトエラーの発生を回避できる。

図１５と同様に、大サイズの物理チャンクを作成するのではなく大サイズの論理チャンクを作成することでも同様の効果を得ることができる。ステップＳ９０５において、チャンク結合プログラム２２７は、一つの論理チャンク番号に対して複数の物理チャンクを対応付ける情報を論理チャンクテーブル２３２に格納する。

維持方式Ａおよび維持方式Ｂを併用することができる。

図９のケース（２）やケース（４）において、維持方式Ａは、作成可能なボリュームの最大容量を５０ＴＢ（ケース（２）の場合）または２５ＴＢ（ケース（４）の場合）に制限する。維持方式Ｂで示した容量の融通やボリューム移行を用いることで、作成可能なボリュームの最大容量を、１００ＴＢ（ケース（２）の場合）または５０ＴＢ（ケース（４）の場合）に増やすことができる。作成可能なボリュームの最大容量の増加を指示するＡＰＩ、ＣＬＩやＧＵＩを設けることができる。当該指示を受領し容量の融通やボリューム移行などの維持方式Ｂが実行される。作成可能なボリュームの最大容量がどの容量まで増やせるかをＧＵＩやＣＬＩで提供してもよい。

図９を参照して説明した比較例によれば、グローバルプール２８としては空き容量があるがローカルプール２３の空きが不足し、故に、ライト不可が発生し得る。各ローカルプール２６３の容量が小さい時にグローバルプール２８０の容量も小さく見せることができれば、ライト不可の発生頻度を下げることができる。なぜならば、グローバルプール２８０の容量が小さい場合、ドライブ追加といった対策を促すことができるためである。これは、ドライブ追加によりローカルプール２６３の空き容量が増加するため、維持方式Ｂの一種である。

各ローカルプール２６３の容量が小さい時にグローバルプール２８０の容量も小さく見せるために、各ローカルプール２６３の使用率（ローカルプール２６３の使用済み容量÷ローカルプール２６３の総容量）を平準化することが考えられる。平準化により、各ローカルプール２６３の使用率とグローバルプール２８０の使用率の乖離が小さくなる。ローカルプール２６３の使用率が小さいとき、ユーザが参照するグローバルプール２８０の使用率も小さくなる。

ボリューム作成ノード選択により各ローカルプール２６３の使用率を平準化できる。図２１は、ボリューム作成ノード決定プログラム（２）に処理の一例を示す。

ボリューム作成ノード決定プログラム（２）は、各ローカルプール２６３の使用率を取得し（Ｓ１０００）、取得された各使用率と、作成されるボリュームの容量とに基づき、ボリューム作成後の使用率の変動を計算する（Ｓ１００１）。次に、ボリューム作成ノード決定プログラム（２）は、各ローカルプール２６３の使用率のバラツキが最も小さくなるローカルプール２６３を選択し（Ｓ１００２）、選択したローカルプール２６３でのボリューム作成を指示する（Ｓ１００３）。選択されたローカルプール２６３は、例えば、ローカルプール２６３毎に当該ローカルプール２６３からボリュームが作成されたと仮定した場合に得られるバラツキ（使用率のバラツキ）が、最も小さいローカルプール２６３である。最後に、ボリューム作成ノード決定プログラム（２）は、ボリューム作成完了報告を受領し（Ｓ１００４）、処理を終了する（Ｓ１００５）。この処理は、ローカルプール２６３の容量が異なるため、最も使用済み容量の小さいローカルプール２６３や最も空き容量の大きいローカルプール２６３にボリュームを作成する単純な方法とは異なる。

ステップＳ１００１の計算について、作成するボリュームの容量と同じ容量がローカルプール２６３から消費されることを想定してもよい（以下の説明では、ローカルプール２６３の容量を適宜「物理容量」と言うことがある）。また、実際にボリュームサイズに対して書き込みが発生する領域の比率を考慮してローカルプール２６３から消費される物理容量を計算してもよい。書き込みが発生する領域の比率は、ノード群１６５の使用実績から計算された比率でもよいし、一般的に知られている比率でもよい。また、ローカルプール２６３の現在の使用済み容量に、作成するボリュームによりローカルプール２６３から消費される物理容量を加算することで、ボリューム作成後のローカルプー２６３ルの使用率を計算することができる。

例えば、ボリューム容量の５０％の物理容量が消費されていることがノード群１６５の使用実績から判断されたと仮定する。１００ＧＢのボリュームを作成する場合、１００ＧＢの５０％である５０ＧＢの物理容量の消費が予測される。ローカルプール容量が１０００ＧＢで既に５００ＧＢ使用済みの場合、当該ボリュームの作成により使用済み容量が５５０ＧＢとなり、使用率は５５％となることが予測できる。消費される物理容量は、サーバからの書き込みだけでなく、データの圧縮や重複排除の効果を考慮して計算されてもよい。

ローカルプール２６３に作成直後のボリュームが多数存在する場合、ローカルプール２６３の現在の使用済み容量は大きく伸びる可能性がある。その場合、ボリューム作成後の使用率を正しく計算することは難しい。

例えば、ローカルプール容量が１０００ＧＢで既に５００ＧＢ使用済みの状況を想定する。作成済みの１００ＧＢのボリュームで、消費される物理容量が１０ＧＢのボリュームがある場合、当該ボリュームは、今後４０ＧＢの物理容量を消費する可能性が高い。

これを避けるため、各ローカルプール２６３について、想定消費物理容量が管理されてもよい。ボリューム作成時、当該ボリュームについて想定される消費物理容量が、当該ボリュームが作成されるローカルプール２６３の想定消費物理容量に加算される。各ローカルプール２６３についての想定消費物理容量を、ステップＳ１００１の計算において使用することができる。

ドライブ追加の様な対策を促す変形例として、最も使用率の高いローカルプール２６３の容量をグローバルプール２８０の容量としてユーザに提供することが採用されてもよい。また、グローバルプール２８０の使用率に加えて、最も使用率の高いローカルプール２６３の使用率もユーザに提供されてもよい。これらの使用率の提供と、上述したボリューム作成ノードの選択との両方が採用されてもよい。ロールプール２６３の使用率は、ローカルプールの空き容量率であってもよい。その場合、最も使用率の高いローカルプールは２６３の代わりに、最も空き容量率の小さいローカルプール２６３の空き容量率をユーザに提供することができる。なお、各ローカルプール２６３について、使用率は、ローカルプール２６３の容量に対する使用済み容量の割合でよく、空き容量率は、１から使用率を引いた値、言い換えれば、ローカルプール２６３の容量に対する空き容量の割合でよい。

維持方式として、チャンクの容量融通およびボリューム移行について述べた。ローカルプール２６３から作成した複数のボリューム２６２を統合し、結合したボリューム（以下、「結合ボリューム」と呼ぶ）をホストに提供する構成を考える。この構成において、結合前のボリューム２６２をストレージノード間で融通や移行する方式が考えられる。例えば、三つの１００ＧＢのボリューム２６２を結合することで３００ＧＢの結合ボリュームが作成される。ホスト１００は、３００ＧＢの結合ボリュームを認識し、以後、当該結合ボリュームにアクセスすることができる。結合ボリュームを構成する二つ以上のボリュームは、一つのノード２００にあってもよいし二つ以上のノード２００にあってもよい。

ボリューム移行に対する利点を述べる。前述したボリューム移行の場合、ボリューム容量が一定でないため移行できないケースがある。例えば、５００ＧＢのボリューム２６２を移行するとき、あるストレージノード２００に２００ＧＢの空き容量があり、別のストレージノード２００に３００ＧＢの空き容量があっても、ボリューム２６２を移行することができない。これに対して、２００ＧＢのボリュームと３００ＧＢのボリュームとで構成された５００ＧＢの結合ボリュームがあれば、５００ＧＢのボリューム２６２を移行することができる。更に、結合ボリュームを構成するボリューム２６２が固定サイズ、または、サイズが小さい場合など、空き容量があるストレージノード２００への移行は更に容易になる。

容量融通に対する利点を述べる。物理チャンクや論理チャンクを融通する場合、融通されたチャンクは、複数のページに分割され複数のボリュームに割り当てられる。すなわち、一つのチャンクには複数のボリューム２６２のデータが格納される。ボリューム２６２の削除などによりストレージノード２００の空き容量が増加しても、融通された容量は他のボリュームのデータを格納している。このため、融通したチャンクを戻すことが難しい。戻すとは融通の解除のことである。当該チャンクからデータを追い出すなどの処理が発生してしまう。これに対して、結合ボリュームが削除された場合、当該結合ボリュームを構成するボリューム２６２が他のストレージノード２００の容量であった場合、削除に伴い返却することが容易にできる。

図２２は、結合ボリュームテーブル２４６の一例を示す図である。

結合ボリュームテーブル２４６は、結合ボリュームに関する情報の一例である。結合ボリュームテーブル２４６は、結合ボリュームの構成要素としてのボリューム毎にレコードを有する。各レコードは、結合ボリューム番号２２０１、結合ボリューム容量２２０２、ノード番号２２０３、ボリューム番号２２０４及びボリューム容量２２０５といった情報を格納する。以下、一つのボリュームを例に取る（図２２の説明において「対象ボリューム」）。

結合ボリューム番号２２０１は、対象ボリュームを構成要素として有する結合ボリュームを識別するための番号（ストレージシステム１６０内でユニークな番号）を示す。結合ボリューム番号２２０１は、結合ボリュームそれ自体の番号とその他の情報（例えばノード番号）を含むことで、ストレージシステム１６０内でユニークな番号とされてもよい。結合ボリューム容量２２０２は、対象ボリュームを構成要素として有する結合ボリュームの容量を示す。ノード番号２２０３は、対象ボリュームを有するノード２００の番号を示す。ボリューム番号２２０４は、対象ボリュームの番号を示す。ボリューム容量は、対象ボリュームの容量を示す。ストレージノード２００が複数のローカルプール２６３を有する場合に備えて、各レコードがローカルプール番号を格納してもよい。

図２２の例では、結合ボリューム０は、ノード００内のボリューム０と、ノード０１内のボリューム１およびボリューム２とから構成されている。各ボリュームの容量が１００ＧＢであり、故に、結合ボリュームの容量は３００ＧＢである。

図２３は、ライトプログラム２４５の一例を示す図である。

結合ボリュームを構成するボリューム２６２が他のストレージノード２００に配置されている場合、ボリューム２６２を有するストレージノード２００へライト要求を転送する。また、結合ボリュームを構成するボリューム２６２が他のストレージノード２００に移行中であった場合、コピー状態に合わせたライト処理を実行する。ライトプログラム２４５は、結合ボリュームへのライト要求を受領し（Ｓ１１００）、書き込み対象ボリューム２６２が自ノードにあるか否かを判断する（Ｓ１１０１）。ステップＳ１１０１では、ライトプログラム２４５は、ライト要求のライトアドレスが、結合ボリュームを構成するどのボリューム２６２のどのアドレスに対応するかを計算する。そして、ライトプログラム２４５は、書き込み対象となるボリューム２６２を有するストレージノード２００を特定する。これらの処理は結合ボリュームテーブル２４６を参照することで実現される。

書き込み対象ボリューム２６２が自ノードに無い場合（Ｓ１１０１：Ｎｏ）、ライトプログラム２４５は、ボリューム２６２を有する他のストレージノード２００へライト要求を転送し（Ｓ１１０２）、当該ライト要求の結果を受領しホスト１００へ報告する（Ｓ１１０７）。

書き込み対象ボリューム２６２が自ノードにある場合（Ｓ１１０１：Ｙｅｓ）、ライトプログラム２４５は、書き込み対象ボリューム２６２が移行コピー中であるか否かを判断する（Ｓ１１０３）。移行コピー中でない場合（Ｓ１１０３：Ｎｏ）、ライトプログラム２４５は、ライト対象ボリューム２６２へライト処理を実行し（Ｓ１１０４）、ホスト１００へ結果を報告する（Ｓ１１０７）。一方、移行コピー中であった場合（Ｓ１１０３：Ｙｅｓ）、ライトプログラム２４５は、ライト対象アドレスがコピーポインタ（現在コピーが完了しているアドレスを示すポインタ）以下か否かを判断する（Ｓ１１０５）。コピーポインタは、移行コピーが進むほどに大きい。

ライト対象アドレスがコピーポインタより大きい場合（Ｓ１１０５：Ｎｏ）、ライトプログラム２４５は、ライト対象ボリューム２６２へのライト処理を実行する（Ｓ１１０４）。ライト対象アドレスがコピーポインタ以下の場合（Ｓ１１０５：Ｎｏ）、ライトプログラム２４５はコピー元およびコピー先の両方にライト処理を実行する。これは、コピー処理が終わっているため、コピー元、およびコピー先を同一とするためである。最後に、ライトプログラム２４５は、ホスト１００に結果を報告する（Ｓ１１０７）。

コピー処理は、結合ボリュームを構成するボリューム２６２を他のストレージノード２００へ移行する処理である。コピー処理により、ストレージノード２００の空き容量を増やすことができる。図１６で述べたボリューム移行は、ホストが認識するボリューム２６２を移行したが、ここで述べる移行は結合ボリュームを構成するボリューム２６２を移行する。

コピー処理の処理内容について説明する。コピー処理は、容量の不足を検出するプログラム、例えば、不足モニタリングプログラム（１）２３６または不足モニタリングプログラム（２）から起動される。この時、移行元（コピー元）となるボリューム２６２の番号と、移行先（コピー先）とされるストレージノードの番号と、移行先とされるローカルプールの番号とが指定されるものとする。最初に、移行先のストレージノード２００における移行先のローカルプールに移行先ボリューム２６２が作成される。コピー処理を起動するプログラムが移行先ボリュームを作成してもよい。コピー処理では、コピーポインタが終端アドレスを指すまで、コピーポインタが指すアドレスが属する領域について移行元ボリュームからデータをリードしリードしたデータを移行先ボリュームへライトすることと、それに伴いコピーポインタを進めることが繰り返される。コピーポインタが指すアドレスが属する領域は、例えば、１ＭＢなどのコピーの処理単位のことである。ボリューム全体のコピーが終了した後、結合ボリュームテーブル２４６が更新される。具体的には、ノード番号２２０３及びボリューム番号２２０４が、移行先ボリュームのノード番号及びボリューム番号に更新される。

リード処理は、リード対象となるボリュームが自ストレージノード２００の場合は、自ストレージノード２００のボリューム２６２に対してリード処理を実行する。また、リード対象となるボリューム２６２が他ストレージノード２００の場合は、他ストレージノード２００へリード要求を転送することで実現される。図２３のステップＳ１１００、Ｓ１１０１、Ｓ１１０２、Ｓ１１０４、Ｓ１１０７に相当する処理ステップから構成される。なお、ステップ内の“ライト”を“リード”と読み替える。

利用者に提供する容量情報として、例えば、下記のうちの一つ以上の情報要素を含んだ情報、
・グローバルプール容量（ローカルプール容量の合計）、
・仕様上のグローバルプール容量（仕様上の最大ローカルプール容量とローカルプール数との積）、
・グローバルプールの使用済み容量、
・グローバルプールの空き容量、
・作成可能なボリュームの最大容量（ローカルプール容量からローカルプールの使用済み容量を引いた容量に基づき計算された容量）、
・作成可能なボリュームの最大容量（仕様上の最大ローカルプール容量からローカルプールの使用済み容量を引いた容量に基づき計算された容量）、
・作成可能なボリュームの最大容量の拡張可能容量、
・各ローカルプールの使用率のうち最大の使用率、
・各ローカルプールの空き容量率のうち最小の空き容量率、
がある。「作成可能なボリュームの最大容量の拡張可能容量」とは、ボリューム移行や容量の融通により、作成可能なボリュームの最大容量に加算可能な容量である。これらの情報要素を含んだ容量情報は、ＡＰＩ、ＣＬＩおよびＧＵＩ等のインターフェース経由で利用者に提供することができる。ローカルプールの空き容量は、ローカルプール容量からローカルプール使用済み容量を引いた容量、又は、仕様上の最大ローカルプール容量からローカルプール使用済み容量を引いた容量に基づく。

作成可能なボリュームの最大容量は、プロセッサ資源の利用率を向上するために利用することができる。例えば、１００ＧＢの容量を持つストレージノード２００が３台あると仮定する。この時、図１７や図２２で述べた容量の融通や結合ボリュームを用いることで、一つのストレージノードが２００ＧＢのボリューム２６２を作成し、ホスト１００に提供することができる。しかし、ホスト１００のＩ／Ｏ発行先（Ｉ／Ｏ要求の発行先）となるストレージノードはボリューム２６２を提供するストレージノード２００のみとなり、他のストレージノード２００のプロセッサ資源を有効活用できない。作成可能なボリュームの最大容量として１００ＧＢを利用者に提供することにより、１００ＧＢのボリューム２６２を３つ作成し、各ストレージノード２００に配置することが可能となる。その場合、ホスト１００のＩ／Ｏ発行先は全ストレージノード２００となり、プロセッサ資源の利用率を上げることができる。

本発明の実施例を適用するか否かをシステム単位などに設定させてもよい。その実現のため、設定するためのインタフェースを設ける。本発明の実施例を適用することが設定されている場合、本実施例に係るボリューム作成処理やボリューム容量取得プログラムなどが行われる。システム単位でなくグローバルプール単位、ローカルプール単位などその他の単位が設定単位とされてもよい。これにより、利用者が、大サイズボリューム（ストレージシステム１６０から回答された容量を超えた容量のボリューム）の作成の抑止、又は、ライトエラーの発生のどちらかを選択することができる。維持方式Ｂに関し、大サイズチャンクの作成を実施するか否かを設定するためのインタフェースが設けられてもよい。

Thin ProvisioningボリュームとThick Provisioningボリュームで動作が変えられてもよい。Thin Provisioningボリュームが使われる場合、将来的なデータ量の予測が難しい場合など、Thin Provisioningを用いて大サイズのボリュームを作成したい場合がある。その場合、維持方式Ａのように作成可能容量の制約を許容できない場合がある。このため、Thick Provisioningボリュームを作成する場合のみ維持方式Ａを採用することが考えられる。Thick ProvisioningにはThin ProvisioningのFull Allocation指定も含めてもよい。Thin ProvisioningとThick Provisioningの動作をユーザが指定するインタフェースを設けてもよい。

以上、本発明の一実施例を説明したが、本発明は、この実施例に限定されるものでなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。

１６０：ストレージシステム

Claims (15)

1. 一つ以上の記憶デバイスである記憶デバイス部をそれぞれが有する複数のストレージノードで構成されたノード群を備え、
   前記複数のストレージノードの各々は、当該ストレージノードの記憶デバイス部に基づく論理的な記憶領域であるローカルプールを有し、
   前記ノード群は、前記複数のストレージノードが有する複数のローカルプールに基づく論理的な記憶領域であるグローバルプールを提供し、
   前記複数のストレージノードの各々は、当該ストレージノードが提供するボリュームに格納されるデータを当該ストレージノードにおけるローカルプールに格納し、
   いずれのストレージノードについても、当該ストレージノードから作成されるボリュームの使用済み容量が当該ストレージノードにおけるローカルプールの空き容量以下であるという容量関係を維持すること、が行われ、
   ボリュームを作成するストレージノードは、前記ノード群を管理するストレージ管理部により選択される、
   ストレージシステム。
2. 前記ローカルプールの空き容量は、ローカルプール容量からローカルプール使用済み容量を引いた容量、又は、仕様上の最大ローカルプール容量からローカルプール使用済み容量を引いた容量に基づく、
   請求項１に記載のストレージシステム。
3. 前記容量関係を維持することは、前記複数のローカルプールがそれぞれ有する複数の空き容量のうちの最大の空き容量を提供することである、
   請求項１に記載のストレージシステム。
4. 前記最大の空き容量が提供された後に要求された容量のボリュームの作成先のストレージノードは、前記要求された容量以上の空き容量を有するストレージノードのうちのいずれかである、
   請求項３に記載のストレージシステム。
5. 前記要求された容量が前記作成先のストレージノードの空き容量を超える場合、前記作成先のストレージノードからエラーが返る、
   請求項４に記載のストレージシステム。
6. 前記最大の空き容量は、作成可能なボリュームの容量の最大値、及び、前記グローバルプールの空き容量、のうちの少なくとも一つとして提供される、
   請求項３に記載のストレージシステム。
7. 前記複数のローカルプールの各々は、当該ローカルプールを有するストレージノードにおける一つ又は複数の論理チャンクで構成されており、
   前記容量関係を維持することは、あるローカルプールに、一つ以上の論理チャンクを追加することである、
   請求項１に記載のストレージシステム。
8. 前記追加される一つ以上の論理チャンクの少なくとも一つは、前記あるローカルプールを有するストレージノード以外の少なくとも一つのストレージノードから融通された容量に基づく論理チャンクである、
   請求項７に記載のストレージシステム。
9. 前記容量関係を維持することは、あるローカルプールに関連付いている少なくとも一つのボリュームを、当該ローカルプールの空き容量よりも大きな空き容量を持つローカルプールに移行することである、
   請求項１に記載のストレージシステム。
10. 前記容量関係を維持することは、結合ボリュームを作成して前記結合ボリュームを提供することであり、
    前記結合ボリュームは、二つ以上のボリュームが結合されたボリュームであり、かつ、前記ボリュームの容量以上の容量をもつ、
    請求項１に記載のストレージシステム。
11. 前記複数のストレージノードの各々では、当該ストレージノードが有するローカルプールを構成する論理チャンクの数に上限があり、
    前記容量関係を維持することは、あるローカルプールの一部である二つ以上の論理チャンクに代えて、当該二つ以上の論理チャンクの各々よりも大サイズであり当該二つ以上の論理チャンク内のデータを格納した論理チャンクを、当該ローカルプールの構成要素とすることである、
    請求項１に記載のストレージシステム。
12. 前記容量関係を維持することは、前記あるローカルプールを有するストレージノードにおいて提供される容量であり前記あるローカルプールの基になる容量である内部容量について空き容量が不足しているとされた条件が満たされた場合に行われる、
    請求項８又は９に記載のストレージシステム。
13. 前記容量関係を維持することは、前記複数のローカルプールにそれぞれ対応した複数の使用率のうちの最大の使用率、または、前記複数のローカルプールにそれぞれ対応した複数の空き容量率のうちの最小の空き容量率を提供することであり、
    各ローカルプールについて、使用率は、当該ローカルプールの容量に対する使用済み容量の割合であり、
    前記各ローカルプールについて、空き容量率は、当該ローカルプールの容量に対する空き容量の割合である、
    請求項１に記載のストレージシステム。
14. 前記ストレージ管理部により選択されるストレージノードは、前記複数のローカルプールにそれぞれ対応した複数の使用率のバラツキが最も小さいストレージノードであり、
    各ストレージノードについて、前記複数の使用率の各々は、当該ストレージノードが選択されたと仮定した場合に推定される使用率であり、
    各ローカルプールについて、使用率は、当該ローカルプールの容量に対する使用済み容量の割合である、
    請求項１に記載のストレージシステム。
15. ノード群を構成する複数のストレージノードのあるストレージノードにおけるローカルプールの空き容量を特定し、
    前記複数のストレージノードの各々が、一つ以上の記憶デバイスでありローカルプールの基になる記憶デバイス部を有し、
    前記ノード群は、前記複数のストレージノードがそれぞれ有する複数のローカルプールに基づく論理的な記憶領域であるグローバルプールを提供し、
    前記複数のストレージノードの各々は、当該ストレージノードが提供するボリュームに格納されるデータを当該ストレージノードにおけるローカルプールに格納し、
    ボリュームを作成するストレージノードは、前記ノード群を管理するストレージ管理部により選択され、
    前記あるストレージノードから作成されるボリュームの使用済み容量が前記特定された空き容量以下であるという容量関係を維持する、
    記憶制御方法。