JP7684856B2 - 分散型ストレージシステム及びボリューム管理方法 - Google Patents

Description

本発明は、プロセッサとメモリとを有しネットワークで互いに接続される複数のノードを備える分散型ストレージシステム、及び分散型ストレージシステムにおけるボリューム管理方法に関する。

ＳＤＳ（Software Defined Storage）やＨＣＩ（Hyper-converged Infrastructure）は、ネットワークで接続された複数のストレージノード（もしくは単にノード）の上でストレージとしての機能を有するストレージ制御ソフトを動作させ、それらが互いに連携して動作する事で、分散型のストレージ機能を提供するシステムである。

このようなシステムでは、ノードが備える複数のストレージデバイスの容量を合わせて、１つの仮想的なストレージプールとして見せる機能を備える。ストレージプールからは複数の論理的な容量をボリュームとして切り出して、ホストに対して論理的なストレージデバイスとして見せることができる。

例えば特許文献１には、ストレージが切り出した複数のボリューム（文献内ではローカルＬＤＥＶ）を束ねて１つの大きなボリューム（文献内ではグローバルＬＤＥＶ）としてホストに見せる技術が開示されている。この技術をＳＤＳに応用することにより、ノードを跨いだボリュームを１つの大きなボリュームとして形成し、ホストに見せる事が可能となる。

特許第４９６３８９２号公報

しかし、特許文献１に記載の技術を用いて複数のノードに跨るスケーラブルなボリュームを形成する場合、各ストレージノード上で動作するストレージ制御ソフトウェアが管理するボリュームの数を増加させると、管理対象の制御情報が増大してストレージ制御ソフトウェアの処理量が増大してしまう。一方、ストレージ制御ソフトウェアが管理するボリュームの全体量を変えずにその数を少なくすると、１つのボリュームのサイズが大きくなり、各ストレージノード間でデータを柔軟に融通することが困難になる、という問題があった。

本発明は以上の点を考慮してなされたもので、１または複数のノードに跨って形成される１つのボリュームに対しても、計算機ノードの追加に応じて、ボリュームの容量及び／または性能をスケールアウトすることが可能な分散型ストレージシステム及びボリューム管理方法を提案しようとするものである。

かかる課題を解決するため本発明においては、プロセッサを有する複数の計算機ノードと、記憶ドライブと、を有して、ボリュームを提供する分散型ストレージシステムであって、前記複数の計算機ノードは、各々がサブボリュームを提供して、そのプロセッサは自計算機ノードのサブボリュームごとに設定を管理し、前記ボリュームは、前記複数の計算機ノードが提供する複数のサブボリュームを用いて構成可能であり、前記サブボリュームは、前記記憶ドライブの物理記憶領域を割り当てて形成される複数の論理記憶領域を含んでおり、前記複数の計算機ノードは、同じ前記ボリュームに属し異なる計算機ノードが提供する前記サブボリューム間で、前記論理記憶領域を移動させることが可能であり、前記複数の計算機ノードの少なくとも何れかの前記プロセッサは、前記ボリュームを形成する前記計算機ノードの増設時、及び前記ボリューム内のリバランスの実行時に、当該ボリュームに含まれる論理記憶領域を、前記サブボリューム間で移行し、前記複数の計算機ノードの少なくとも何れかの前記プロセッサは、前記ボリュームに含まれる論理記憶領域を前記サブボリューム間で移行する際、データ容量の観点に基づいて前記論理記憶領域を移行する第１のリバランス処理、またはデータ入出力処理負荷の観点に基づいて前記論理記憶領域を移行する第２のリバランス処理を実行し、前記第２のリバランス処理において、前記プロセッサは、サブボリュームの負荷情報に基づいて対象のサブボリュームを選択し、選択したサブボリューム内の前記論理記憶領域の負荷情報に基づいて移動させる論理記憶領域を選択する、分散型ストレージシステムが提供される。また、かかる課題を解決するため本発明においては、プロセッサを有する複数の計算機ノードと、記憶ドライブと、を有して、ボリュームを提供する分散型ストレージシステムであって、前記複数の計算機ノードは、各々がサブボリュームを提供して、そのプロセッサは自計算機ノードのサブボリュームごとに設定を管理し、前記ボリュームは、前記複数の計算機ノードが提供する複数のサブボリュームを用いて構成可能であり、前記サブボリュームは、前記記憶ドライブの物理記憶領域を割り当てて形成される複数の論理記憶領域を含んでおり、前記複数の計算機ノードは、同じ前記ボリュームに属し異なる計算機ノードが提供する前記サブボリューム間で、前記論理記憶領域を移動させることが可能であり、前記複数の計算機ノードの少なくとも何れかの前記プロセッサは、前記ボリュームを形成する前記計算機ノードの増設時、及び前記ボリューム内のリバランスの実行時に、当該ボリュームに含まれる論理記憶領域を、前記サブボリューム間で移行し、前記複数の計算機ノードの少なくとも何れかの前記プロセッサは、前記ボリュームに含まれる論理記憶領域を前記サブボリューム間で移行する際、データ容量の観点に基づいて前記論理記憶領域を移行する第１のリバランス処理、またはデータ入出力処理負荷の観点に基づいて前記論理記憶領域を移行する第２のリバランス処理を実行し、前記第１のリバランス処理において、前記プロセッサは、前記記憶ドライブの物理記憶領域が未割り当ての前記論理記憶領域を、当該論理記憶領域の割り当てに関する制御情報を更新することによって、前記サブボリューム間で移行する、分散型ストレージシステムが提供される。

また、かかる課題を解決するため本発明においては、プロセッサを有する複数の計算機ノードと記憶ドライブとを有して、ボリュームを提供する分散型ストレージシステムによるボリューム管理方法であって、前記複数の計算機ノードは、各々がサブボリュームを提供して、そのプロセッサは自計算機ノードのサブボリュームごとに設定を管理し、前記ボリュームは、前記複数の計算機ノードが提供する複数のサブボリュームを用いて構成可能であり、前記サブボリュームは、前記記憶ドライブの物理記憶領域を割り当てて形成される複数の論理記憶領域を含んでおり、前記複数の計算機ノードが、同じ前記ボリュームに属し異なる計算機ノードが提供する前記サブボリューム間で、前記論理記憶領域を移動させることが可能であり、前記複数の計算機ノードの少なくとも何れかの前記プロセッサは、前記ボリュームを形成する前記計算機ノードの増設時、及び前記ボリューム内のリバランスの実行時に、当該ボリュームに含まれる論理記憶領域を、前記サブボリューム間で移行し、前記複数の計算機ノードの少なくとも何れかの前記プロセッサは、前記ボリュームに含まれる論理記憶領域を前記サブボリューム間で移行する際、データ容量の観点に基づいて前記論理記憶領域を移行する第１のリバランス処理、またはデータ入出力処理負荷の観点に基づいて前記論理記憶領域を移行する第２のリバランス処理を実行し、前記第２のリバランス処理において、前記プロセッサは、サブボリュームの負荷情報に基づいて対象のサブボリュームを選択し、選択したサブボリューム内の前記論理記憶領域の負荷情報に基づいて移動させる論理記憶領域を選択する、ボリューム管理方法が提供される。また、かかる課題を解決するため本発明においては、プロセッサを有する複数の計算機ノードと記憶ドライブとを有して、ボリュームを提供する分散型ストレージシステムによるボリューム管理方法であって、前記複数の計算機ノードは、各々がサブボリュームを提供して、そのプロセッサは自計算機ノードのサブボリュームごとに設定を管理し、前記ボリュームは、前記複数の計算機ノードが提供する複数のサブボリュームを用いて構成可能であり、前記サブボリュームは、前記記憶ドライブの物理記憶領域を割り当てて形成される複数の論理記憶領域を含んでおり、前記複数の計算機ノードが、同じ前記ボリュームに属し異なる計算機ノードが提供する前記サブボリューム間で、前記論理記憶領域を移動させることが可能であり、前記複数の計算機ノードの少なくとも何れかの前記プロセッサは、前記ボリュームを形成する前記計算機ノードの増設時、及び前記ボリューム内のリバランスの実行時に、当該ボリュームに含まれる論理記憶領域を、前記サブボリューム間で移行し、前記複数の計算機ノードの少なくとも何れかの前記プロセッサは、前記ボリュームに含まれる論理記憶領域を前記サブボリューム間で移行する際、データ容量の観点に基づいて前記論理記憶領域を移行する第１のリバランス処理、またはデータ入出力処理負荷の観点に基づいて前記論理記憶領域を移行する第２のリバランス処理を実行し、前記第１のリバランス処理において、前記プロセッサは、前記記憶ドライブの物理記憶領域が未割り当ての前記論理記憶領域を、当該論理記憶領域の割り当てに関する制御情報を更新することによって、前記サブボリューム間で移行する、ボリューム管理方法が提供される。

本発明によれば、１または複数のノードに跨って形成される１つのボリュームに対しても、計算機ノードの追加に応じて、ボリュームの容量及び／または性能をスケールアウトすることができる。

本発明の一実施形態に係る分散型ストレージシステム１の構成例を示すブロック図である。 分散型ストレージシステム１を構成する各ノードのソフトウェアスタックの例を示す図である。 ボリューム１００に対するデータ管理領域の関係を説明するための図である。 メモリ１２上に格納されるプログラム及びテーブルの一例を示す図である。 クラスタ構成管理テーブル３１０の構成例を示す図である。 リバランスポリシー管理テーブル３２０の構成例を示す図である。 クラスタプール管理テーブル３３０の構成例を示す図である。 ノードプール管理テーブル４１０の構成例を示す図である。 データ領域管理テーブル４２０の構成例を示す図である。 ホストパス管理テーブル４３０の構成例を示す図である。 ＨＷモニタ情報管理テーブル４４０の構成例を示す図である。 データ領域モニタ情報管理テーブル４５０の構成例を示す図である。 ボリューム作成処理の処理手順例を示すフローチャートである。 ライトＩＯ処理の処理手順例を示すフローチャートである。 リードＩＯ処理の処理手順例を示すフローチャートである。 リバランス処理の処理手順例を示すフローチャートである。 容量リバランス処理の処理手順例を示すフローチャートである。 負荷リバランス処理の処理手順例を示すフローチャートである。 ノード増減設処理の処理手順例を示すフローチャートである。 分散ノード数変更処理の処理手順例を示すフローチャートである。 ボリュームサイズ変更処理の処理手順例を示すフローチャートである。

以下、本発明の一実施形態について、図面を参照して説明する。なお、以下に説明する実施形態は、特許請求の範囲にかかる発明を限定するものではなく、また実施形態の中で説明されている特徴の組み合わせの全てが発明の解決手段に必須であるとは限らない。以下の説明では、「テーブル」、「リスト」、「キュー」等の表現にて各種情報を説明する事があるが、各種情報は、これら以外のデータ構造で表現されていてもよい。データ構造に依存しないことを示すために「ＸＸテーブル」、「ＸＸリスト」等を「ＸＸ情報」と呼ぶことがある。各情報の内容を説明する際に、「識別情報」、「識別子」、「名」、「ＩＤ」、「番号」等の表現を用いるが、これらについては互いに置換が可能である。

本実施形態では、分散型ストレージシステムを開示する。まず、この分散型ストレージシステムについて基本的な説明を行う。

分散型ストレージシステムは、それぞれがストレージデバイス及びプロセッサ等を含む複数のストレージ用の計算機が互いにネットワークで接続されて構成される。各計算機は、ネットワークの中でノードあるいは計算機ノードとも呼ばれる。分散型ストレージシステムを構成する各計算機は、特にストレージノードとも呼ばれ、コンピュートクラスタを構成する各計算機は、コンピュートノードとも呼ばれる。

分散型ストレージシステムを構成するストレージノードには、ストレージノードを管理及び制御するためのＯＳ（Operating System）がインストールされており、そのＯＳ上にストレージシステムの機能を持ったストレージソフトウェアを動作させることで、分散型ストレージシステムが構成される。ストレージソフトウェアは、ＯＳ上でコンテナの形態で動作させることによっても、分散型ストレージシステムを構成することができる。コンテナとは、１以上のソフトウェア及び構成情報をパッケージ化する仕組みである。また、ストレージノードにＶＭＭ（Virtual Machine Monitor）をインストールし、ＯＳ及びソフトウェアをＶＭ（Virtual Machine）として動作させて、分散型ストレージシステムを構成することもできる。

また、本発明は、ＨＣＩ（Hyper-Converged Infrastructure）と呼ばれるシステムを構成する場合にも、適用可能である。ＨＣＩは、各ノードにインストールされたＯＳもしくはハイパーバイザの上に、ストレージソフトウェアの他、アプリケーション、ミドルウェア、管理ソフト、及びコンテナを動作させることで、１つのノードで複数の処理を実施することを可能にしたシステムである。

分散型ストレージシステムは、複数のストレージノード上のストレージデバイスの容量を仮想化したストレージプール及び論理ボリューム（単にボリュームとも呼ぶ）をホスト（コンピュートノード）に提供する。ホストが何れかのストレージノードに対してＩＯ（Input/Output）を発行すると、分散型ストレージシステムは、ＩＯコマンドが指定するデータを保持するストレージノードにＩＯコマンドを転送することで、データへのアクセスをホストに提供する。この特徴により、分散型ストレージシステムは、ホストからのＩＯコマンドを停止させることなく、各ストレージノード間でボリュームを移動することができる。

分散型ストレージシステムの管理者は、ネットワークを介して管理用コマンドを分散型ストレージに対して発行することで、ボリュームの作成、削除、移動等の処理を実施することができる。また、分散型ストレージシステムは、ネットワークを介して、分散型ストレージシステムが送信する情報を提供することで、分散型ストレージシステムにおけるドライブの使用状況やプロセッサの使用状況等、分散型ストレージシステムの状態を管理者や管理ツールに対して通知することができる。

以下、本実施形態に係る分散型ストレージシステム１について詳しく説明する。

（１）システム構成
図１は、本発明の一実施形態に係る分散型ストレージシステム１の構成例を示すブロック図である。図１に示すように、分散型ストレージシステム１は、複数のストレージノード１０（または、ノードと称する）をネットワーク２０Ａによって互いに接続して構成される。各ストレージノード１０のハードウェア構成は特に限定されないが、例えば図１に示したストレージノード１０Ａのように、ＣＰＵ（Central Processing Unit）１１、メモリ１２、ネットワークインタフェース１３、ドライブインタフェース１４、ドライブ１５、及び内部ネットワーク１６等を有する。例えばストレージノード１０Ａは、ネットワークインタフェース１３Ａを介してネットワーク２０Ａに接続し、他のストレージノード１０Ｂ、１０Ｃと通信する。なお、本実施形態の説明において、分散型ストレージシステム１の内部構成として「ノード」と表記する場合、特段の断りがない限り、当該「ノード」は「ストレージノード１０」であると解してよい。

なお、図１には図示を省略しているが、分散型ストレージシステム１を構成する複数のストレージノード１０を接続するネットワーク２０Ａは、同階層または階層の異なる複数のネットワーク２０が接続して構成されてもよい。そしてこれら複数のネットワーク２０Ａの間の地理的な距離は限定されない。また、図１では、分散型ストレージシステム１を構成するストレージノード１０の一例としてストレージノード１０Ａ～１０Ｃを示したが、本実施形態に係る分散型ストレージシステム１は、任意の数のストレージノード１０を備える構成であってよい。したがって、例えば、ストレージノード１０Ａ～１０Ｃが接続するネットワーク２０が、地理的に十分に離れた場所で構成された別のネットワーク２０に接続され、この別のネットワーク２０にストレージノード１０Ｄやストレージノード１０Ｅが接続されているとすれば、災害対策として、ストレージノード１０Ａ～１０Ｃのデータをストレージノード１０Ｄ、１０Ｅにも格納することが可能である。

ホストコンピュータ３０Ａ，３０Ｂは、ネットワーク２０Ｂを介して分散型ストレージシステムにアクセスする。本実施例では、ストレージノード１０同士の通信用と、ホストコンピュータ３０との通信用にそれぞれネットワーク２０を構築する形態をとっているが、同一のネットワークとする事も可能である。また、図１では、分散型ストレージシステム１を構成するノードをすべてストレージノード１０としているが、本実施形態で分散型ストレージシステム１を構成可能なノードは、ストレージノードに限定されるものではなく、例えば、コンピューティングの機能を同じノード上で動作させるＨＣＩノード等であってもよい。

図２は、分散型ストレージシステム１を構成する各ノードのソフトウェアスタックの例を示す図である。図２に示すように、１のストレージノード１０では、ハードウェアを制御するためのハイパーバイザ２１が動作しており、その上には、１つ以上のゲストＯＳ２２（個別にはゲストＯＳ２２Ａ，２２Ｂ）が動作している。各ゲストＯＳ２２の上には、ストレージ制御ソフト２３または管理ソフト２４を動作させることが可能である。ハイパーバイザ２１の上には、コンピューティングソフトを動作させることも可能であり、その場合は、ＨＣＩとしてシステムを構成する事も可能である。

なお、ストレージ制御ソフト２３及び管理ソフト２４は、必ずしもすべてのストレージノード１０で動作させる必要はない。また、管理ソフト２４は、ストレージノードとは異なるサーバの上で動作させることも可能である。

図３は、ボリューム１００に対するデータ管理領域の関係を説明するための図である。図３では、分散型ストレージシステム１で形成されるボリューム１００（個別にはボリューム１００Ａ，１００Ｂ）について、各ボリューム１００の分散型ストレージシステム１におけるデータ管理領域の関係例が示されている。

ボリューム１００は、分散型ストレージシステム１がホストコンピュータ３０に見せるデータ管理領域である。サブボリューム１１０は、各ストレージノード１０においてストレージ制御ソフト２３が管理するデータ管理領域であり、ボリューム１００は、１以上のサブボリューム１１０に対応付けられる。

ストレージ制御ソフト２３は、サブボリューム１１０ごとに管理情報を保持している。１のストレージノード１０においてストレージ制御ソフト２３が管理するサブボリューム１１０の数が増加すると、作成、更新、または削除などの操作時間が増大するため、各ストレージノード１０が作成するサブボリューム１１０の数は少ないことが望ましい。しかしながら、各ストレージノード１０のサブボリューム１１０の数が少ない場合は、以下に説明するようにボリュームのスケールアウト処理が問題になる。

ボリュームのスケールアウト処理とは、分散型ストレージシステム１に新たにストレージノード１０を増設した際に、増設したストレージノード１０に、ボリューム１００のデータの一部を移行することで、ＩＯ処理による負荷をオフロードすることである。このとき、各ストレージノード１０に属するサブボリューム１１０の数が少ない場合、すなわち１つのサブボリューム１１０あたりの容量が大きい場合は、移行自体の負荷が大きかったり、容量が大きいことで移行先のリソースを圧迫することになったりして、増設したストレージノード１０に対してデータの一部を柔軟に移行することができないという問題が想定される。

上記のようなボリュームのスケールアウト処理における問題を解決するために、本実施形態に係る分散型ストレージシステム１では、スライス１２０の概念を導入する。

スライス１２０は、ボリュームに記憶されるデータの管理サイズ（例えば１バイト）よりも大きく、サブボリューム１１０のサイズ（例えば、後述する図９の場合、最小で３２ＴＢ）より小さい、固定サイズのデータ領域であり、後述する図９のデータ領域管理テーブル４２０のスライス管理テーブル４２３を参照すると、１００ＧＢのサイズとされる。図３に示したように、ボリューム１００は、スライス１２０の単位で各サブボリューム１１０にマッピングされる。すなわち、サブボリューム１１０の実質的な容量は、各サブボリューム１１０に割り当てられたスライス１２０の合計値（以後、合計スライスサイズとも称する）によって定義され、言い換えれば、ボリューム１００の容量と同じサイズである。具体的には例えば、図３の場合、ストレージノード１０Ｂ～１０Ｃに跨って形成されるボリューム１００Ｂは、「１２」～「２３」の１２個のスライス１２０に相当する容量を有する。ストレージノード１０Ｂ～１０Ｃには、ボリューム１００Ｂと同じサイズのサブボリューム１１０Ｂ～１１０Ｄが１つずつ形成され、各サブボリューム１１０Ｂ～１１０Ｄは、１２個のスライス１２０に細分化される。そして、ボリューム１００の論理領域は、各サブボリューム１１０Ｂ～１１０Ｄのスライス１２０を部分的に割り当てて（例えば４個ずつスライス１２０を割り当てて）構成される。

また、スライス１２０のサブボリューム１１０へのマッピングは、ボリューム１００とサブボリューム１１０を定義した際に、例えばストレージ制御ソフト２３によって、静的に決定される。すなわち、ＩＯのたびにスライス１２０のマッピング処理が実行されるわけではない。したがって、動的なマッピングに比べて、スライス１２０は、高速なアクセスが可能となる。

分散型ストレージシステム１は、このようなスライス１２０の概念を導入することで、ストレージノード１０を増設した場合、増設したストレージノード１０上のサブボリューム１１０に対して１以上のスライス１２０を移行することにより、各ストレージノード１０に作成するサブボリューム１１０の数を少なくしたまま（原則として１つ）、柔軟なスケールアウト処理を実現することができる。

このとき、サブボリューム１１０のサイズをボリューム１００と同じサイズにしておくことで、ボリューム１００にかかるすべてのスライス１２０を１つのサブボリュームに移動させることにも対応可能となり、スライス１２０の移行に対してサブボリューム１１０のサイズを変更する必要がなくなるため、スライス１２０を各サブボリューム１１０の間で柔軟に移動することが可能となる。このような方式の場合でも、いわゆるシンプロビジョニングと呼ばれる既知の技術を用いることで、サブボリューム１１０のサイズは、サブボリューム１１０に論理的な空間を定義するだけであるため、物理容量を不要に消費することはない。

スライス１２０のサイズの決め方としては、例えば、想定されるサブボリューム１１０の数から計算されるデータ領域管理テーブルのサイズが、各ストレージノード１０が搭載するメモリ１２のサイズに収まるようにする、等の方法をとることができる。

そして、スライス１２０は、物理的なデータ領域であるページ１３０に細分化される。シンプロビジョニングの技術では、あるデータ領域に初めて書き込みがされた場合に、論理的なデータ領域に対して物理的なデータ領域が動的に割り当てられる。このときに割り当てる単位が「ページ」である。

図３には、１つのストレージノード１０Ａで形成されるボリューム１００Ａと、複数のストレージノード１０Ｂ，１０Ｃ，１０Ｄに跨って形成されるボリューム１００Ｂとが示されている。ボリューム１００Ａは、１のサブボリューム１１０Ａに対応付けられ、ボリューム１００Ｂは、サブボリューム１１０Ｂ，１１０Ｃ，１１０Ｄに対応付けられている。

ボリューム１００Ａのように、１つのボリューム１００に属する全てのスライス１２０が１つのサブボリューム１１０にのみマッピングされるボリュームを、ローカライズドボリュームと呼ぶ。また、ボリューム１００Ｂのように、１つのボリューム１００に属するスライス１２０が複数のボリューム１００にマッピングされるボリュームを、スケーラブルボリュームと呼ぶ。

ローカライズドボリュームの利点は、１つのノードだけでＩＯ処理が実行されるため、ＣＰＵ処理時間が比較的短く、またノードを跨いだデータの転送が起きないため、レイテンシを短くできることである。スケーラブルボリュームの利点は、１つのボリュームのＩＯ処理を複数のノードで実行するため、ボリュームのスループットがスケールすることである。

図４は、メモリ１２上に格納されるプログラム及びテーブルの一例を示す図である。各テーブルの詳細は後述するため、ここでは概要を説明する。

図４に示すように、ストレージノード１０のメモリ１２上には、ストレージ制御プログラム２００、クラスタ内制御情報テーブル３００、及びノード内制御情報テーブル４００が記憶されている。

ストレージ制御プログラム２００は、各ストレージノード１０で動作し、ストレージノード１０ごとに同一のストレージ機能を提供する。ストレージ制御プログラム２００には、リードライト処理プログラム２１０、ボリューム管理プログラム２２０、クラスタ管理プログラム２３０、及びリバランス処理プログラム２４０が含まれる。

リードライト処理プログラム２１０は、ホストコンピュータ３０が発行したリード／ライトコマンドに対応する処理を実行するプログラムである。例えば、ＳＣＳＩ（Small Computer System Interface）のようなプロトコルに従い、ホストコンピュータ３０が分散型ストレージシステム１のデータにアクセスする場合に、リードライト処理プログラム２１０は、そのプロトコルに従ったデータのリードまたはライトを提供する。

ボリューム管理プログラム２２０は、ストレージ管理者が指示するボリューム管理コマンド（例えば、ボリューム作成、ボリューム削除、ボリューム設定変更など）に応じて動作するプログラムである。

クラスタ管理プログラム２３０は、ストレージ管理者が指示するクラスタ管理コマンド（例えば、クラスタ作成、ノード増設／減設、クラスタのポリシー設定変更など）に応じて動作するプログラムである。

リバランス処理プログラム２４０は、リバランス処理を実行するプログラムである。リバランス処理とは、あるストレージノード１０でシステム負荷やデータ容量の使用量が閾値を超えた場合に、データを適切な別のノードに移行する処理である。

但し、リバランス処理の実行の基準とされる上記閾値の決定方法は、特に限定されない。具体的には例えば、ストレージノード１０におけるリソース利用率について、８０％のような絶対値を閾値に設定することや、リソース利用率の全ノードの平均値に対して２０％以上大きいなどの相対値を閾値に設定することなど、複数の設定方法が考えられる。なお、ストレージノード１０におけるリソース利用率には、ＣＰＵ使用率またはネットワーク帯域使用率などの負荷に関する利用率だけでなく、ドライブの容量使用率なども含めることができる。

なお、上記の説明では、ストレージ制御プログラム２００は、各ストレージノード１０に保持されるとしたが、分散型ストレージシステム１において全体的な処理が必要な場合には、マスタノードの概念を利用してもよい。一般に、マスタノードは、複数のノード（ストレージノード１０）のうちから適当に指定され、マスタノードが利用不可になった場合は、別ノードがマスタノードに代替して全体的な処理を行う。これらの技術は広く知られた既存技術であるため、詳細な説明は省略する。

クラスタ内制御情報テーブル３００は、分散型ストレージシステム１のクラスタの構成や設定に関する制御情報を管理するテーブルであり、各ストレージノード１０の間で共有される。つまり、どのストレージノード１０で動作するストレージ制御プログラム２００がアクセスしても同じ情報が参照できるように、各ストレージノード１０におけるクラスタ内制御情報テーブル３００は情報の一貫性が保たれている。クラスタ内制御情報テーブル３００には、クラスタ構成管理テーブル３１０、リバランスポリシー管理テーブル３２０、及びクラスタプール管理テーブル３３０が含まれる。

クラスタ構成管理テーブル３１０は、分散型ストレージシステム１を構成するストレージノード１０の一覧、及びストレージノード１０が備えるハードウェア構成などを管理するテーブルである。

リバランスポリシー管理テーブル３２０は、分散型ストレージシステム１におけるリバランスポリシーの設定を管理するテーブルである。リバランスポリシーとは、リバランス処理において、ユーザの運用ポリシーを反映するために用意される設定である。

クラスタプール管理テーブル３３０は、クラスタ全体において容量を管理するための管理用テーブルであって、各ストレージプールにおける容量の状況を示す。

ノード内制御情報テーブル４００は、各ストレージノード１０の制御情報を管理するテーブルである。ノード内制御情報テーブル４００には、ノードプール管理テーブル４１０、データ領域管理テーブル４２０、ホストパス管理テーブル４３０、ＨＷモニタ情報管理テーブル４４０、及びデータ領域モニタ情報管理テーブル４５０が含まれる。

ノードプール管理テーブル４１０は、各ストレージノード１０の容量を管理するテーブルで、クラスタプール管理テーブル３３０がストレージプールごとの容量の状況を示すのに対して、本テーブルはストレージノード１０ごとの容量の状況を示す。

データ領域管理テーブル４２０は、ボリューム１００、サブボリューム１１０、スライス１２０、及びページ１３０などの各データ領域を管理するテーブルであって、各データ領域のＩＤやサイズなどの情報を管理する他、データ領域同士の関係性も管理する。

ホストパス管理テーブル４３０は、ホストコンピュータ３０と各ストレージノード１０との間に張られるパスの情報を管理するテーブルである。

ＨＷモニタ情報管理テーブル４４０は、各ストレージノード１０に搭載されたＨＷ（ハードウェア）の負荷状況を示す。

データ領域モニタ情報管理テーブル４５０は、サブボリューム１１０及びスライス１２０のデータ領域ごとの負荷状況を示す。

（２）データ構造
（２－１）クラスタ内制御情報テーブル３００
図５は、クラスタ構成管理テーブル３１０の構成例を示す図である。クラスタ構成管理テーブル３１０は、クラスタ内制御情報テーブル３００に属し、ストレージノード１０間で共有される情報を管理するテーブルである。

図５に示すように、クラスタ構成管理テーブル３１０は、内部的にサイト構成管理テーブル３１１、ノード構成管理テーブル３１２、ドライブ構成管理テーブル３１３、及びＣＰＵ構成管理テーブル３１４を備える。

サイトとは、例えば、データセンターや、サーバラックの位置など、ユーザが定義した場所を示す概念である。分散型ストレージシステム１では、サイト構成管理テーブル３１１によってサイトの状態を管理することにより、複数のサイトに配置されたストレージノード１０で構成されたクラスタを定義することが可能である。

サイト構成管理テーブル３１１は、分散型ストレージシステム１のクラスタに含まれるサイトとその状態を管理する。サイト構成管理テーブル３１１は、サイトＩＤ３１１１、状態３１１２、及びノードＩＤリスト３１１３のフィールドを有して構成される。

サイトＩＤ３１１１フィールドは、サイトを識別する識別子（サイトＩＤ）を管理する。状態３１１２フィールドは、各サイトの状態を管理する。具体的には、状態３１１２フィールドの値が「Ｎｏｒｍａｌ」である場合は、対象サイトが正常状態にあることを表し、「Ｗａｒｎｉｎｇ」である場合は、対象サイト内のコンポーネントで部分的に障害が発生するなどして冗長度が低下している状態、言い換えると「部分的な障害状態」であることを表す。

ノードＩＤリスト３１１３フィールドは、各サイトに含まれるストレージノード１０のＩＤを管理する。ノードＩＤリスト３１１３フィールドにおける各ＩＤは、後述するノード構成管理テーブル３１２のノードＩＤ３１２１フィールドのレコードに対応する。

ノード構成管理テーブル３１２は、各ストレージノード１０の状態、及び各ストレージノード１０に搭載されるドライブ１５やＣＰＵ１１などのリソースＩＤを管理する。ノード構成管理テーブル３１２は、ノードＩＤ３１２１、状態３１２２、ドライブＩＤリスト３１２３、及びＣＰＵ ＩＤリスト３１２４のフィールドを有して構成される。

ノードＩＤ３１２１フィールドは、ノードを識別する識別子（ノードＩＤ）を管理する。状態３１２２フィールドは、各ノードの状態を管理する。具体的には、状態３１２２フィールドの値が「Ｎｏｒｍａｌ」である場合は、対象ノードが「正常状態」にあることを表し、「Ｆａｉｌｕｒｅ」である場合は、故障などによって対象ノードが「停止状態」にあることを表す。

ドライブＩＤリスト３１２３フィールドは、各ストレージノード１０に搭載されたドライブ１５を識別する識別子（ドライブＩＤ）を管理する。ドライブＩＤリスト３１２３フィールドにおける各ＩＤは、後述するドライブ構成管理テーブル３１３のドライブＩＤ３１３１フィールドのレコードに対応する。

ＣＰＵ ＩＤリスト３１２４フィールドは、各ストレージノード１０に搭載されたＣＰＵ１１を識別する識別子（ＣＰＵ ＩＤ）を管理する。ＣＰＵ ＩＤリスト３１２４フィールドにおける各ＩＤは、後述するＣＰＵ構成管理テーブル３１４のＣＰＵ ＩＤ３１４１フィールドのレコードに対応する。

ドライブ構成管理テーブル３１３は、ノード構成管理テーブル３１２で管理されるノードごとに、当該ノードが備えるドライブ１５の構成を管理するテーブルであって、ドライブＩＤ３１３１、状態３１３２、及びサイズ３１３３のフィールドを有して構成される。

ドライブＩＤ３１３１フィールドは、ドライブ１５を識別するドライブＩＤを管理する。状態３１３２フィールドは、ドライブ１５の状態を管理する。サイズ３１３３フィールドは、ドライブ１５の容量（サイズ）を管理する。

ＣＰＵ構成管理テーブル３１４は、ノード構成管理テーブル３１２で管理されるノードごとに、当該ノードが備えるＣＰＵ１１の構成を管理するテーブルであって、ＣＰＵ ＩＤ３１４１、状態３１４２、周波数３１４３、及び物理コア数３１４４のフィールドを有して構成される。

ＣＰＵ ＩＤ３１４１フィールドは、ＣＰＵ１１を識別するＣＰＵ ＩＤを管理する。状態３１４２フィールドは、ＣＰＵ１１の状態を管理する。周波数３１４３フィールドは、ＣＰＵ１１のクロック周波数を管理する。物理コア数３１４４フィールドは、ＣＰＵ１１の物理コア数を管理する。

なお、図５では、ドライブ１５の構成管理テーブルとしてドライブ構成管理テーブル３１３を、ＣＰＵ１１の構成管理テーブルとしてＣＰＵ構成管理テーブル３１４を示したが、実際のクラスタ構成管理テーブル３１０には、メモリ１２やネットワークカードなどのリソースを管理する構成管理テーブルも含まれてよい。

図６は、リバランスポリシー管理テーブル３２０の構成例を示す図である。リバランスポリシー管理テーブル３２０は、クラスタ内制御情報テーブル３００に属し、ストレージノード１０間で共有される情報を管理するテーブルである。

リバランスポリシーとは、リバランス処理におけるユーザの運用に関する方針を反映することを目的として設定される項目である。図６には、例として、複数のポリシーを示しているが、これらは必要十分なものではなく、この他のポリシーを設定してもよいし、一部のポリシーがなくてもよい。

例えば、特定の用途のボリューム１００では、前述したように、いずれかのストレージノード１０のパラメタ（ＣＰＵ使用率、ネットワーク帯域使用率、ドライブ容量使用率など）が閾値を超えた際に、リバランス処理が実施される。その際、リバランス処理プログラム２４０は、リバランスポリシーに従って、当該ストレージノード１０に属するボリューム１００、サブボリューム１１０、及びスライス１２０をそれぞれ選択し、さらに移行先のノードを選択した後に、スライス１２０の移行を実行する。

リバランスポリシー管理テーブル３２０は、ポリシー３２０１及び設定３２０２のフィールドを有して構成される。ポリシー３２０１フィールドは、リバランス処理に適用されるポリシーを管理する。設定３２０２フィールドは、各ポリシーの設定内容を管理する。図６の場合、ポリシー３２０１フィールドには、「優先ボリュームポリシー」、「優先サブボリュームポリシー（容量）」、「優先サブボリュームポリシー（負荷）」、「スライス選択ポリシー」、及び「移行先ノード選択ポリシー」の５種類のポリシーが記載されている。

優先ボリュームポリシーとは、リバランス処理を実行する際に、どのようなボリューム１００を優先的に選択するかのポリシーである。例えば、スケーラブルボリューム（ボリューム１００Ｂ）を優先的に選択する場合は、「優先ボリュームポリシー」の設定３２０２から「１．スケーラブルボリュームを優先」が設定される。

優先サブボリュームポリシー（容量）とは、選択されたボリューム１００を構成するサブボリューム１１０の中で、データ容量の観点からどのようなサブボリューム１１０を優先的に選択するかのポリシーである。例えば、容量使用率の高いサブボリューム１１０を優先的に解決したい場合は、「優先サブボリュームポリシー（容量）」の設定３２０２から「１．容量使用率の高いサブボリュームを優先」が設定される。

優先サブボリュームポリシー（負荷）とは、選択されたボリューム１００を構成するサブボリューム１１０の中で、システム負荷の観点からどのようなサブボリューム１１０を優先的に選択するかのポリシーである。例えば、負荷の高いサブボリューム１１０を優先的に解決したい場合は、「優先サブボリュームポリシー（負荷）」の設定３２０２から「１．高負荷のサブボリュームを優先」が設定される。

スライス選択ポリシーとは、リバランス処理を実行する際、選択されたサブボリューム１１０において、どのスライス１２０を優先的に選択するかのポリシーである。例えば、最も負荷の高いスライス１２０を優先的に選択して移行したい場合は、「スライス選択ポリシー」の設定３２０２から「１．高負荷スライスを優先」が設定される。

移行先ノード選択ポリシーとは、選択されたスライス１２０を移行する先のノードをどのように選択するかのポリシーである。例えば、「１．閾値超過したパラメタが最も小さいノードを優先」を設定しているときに、ストレージノード１０のドライブ容量使用率が閾値を超えたことを契機としてリバランス処理が実行される場合には、ドライブ容量使用率が最も小さいノードが移行先として選択されることになる。

図７は、クラスタプール管理テーブル３３０の構成例を示す図である。クラスタプール管理テーブル３３０は、クラスタ内制御情報テーブル３００に属し、ストレージノード１０間で共有される情報を管理するテーブルである。

クラスタプール管理テーブル３３０は、クラスタ全体での容量を管理するためのテーブルであり、各ストレージプールの容量状況を示す。

プールには、ノードプールとストレージプールとがある。ノードプールが、各ストレージノード１０が備えるドライブ容量を合計した容量を持つプールであるのに対し、ストレージプールは、複数のノードプールを合計した容量を持つプールである。ストレージノード１０の数が大量な場合、ノードごとの容量管理を行うと運用が煩雑になる。そこで本実施形態に係る分散型ストレージシステム１では、ストレージプールという上位の概念を導入することにより、全体的な運用を単純にすることを可能にする。

クラスタプール管理テーブル３３０は、ストレージプールＩＤ３３０１、全容量３３０２、使用容量３３０３、及びノードＩＤリスト３３０４のフィールドを有して構成される。ストレージプールＩＤ３３０１フィールドは、ストレージプールを識別する識別子（ストレージプールＩＤ）を管理する。全容量３３０２フィールドは、ストレージプールにおける全容量を管理し、使用容量３３０３フィールドは、ストレージプールで使用中の使用容量を管理する。また、ノードＩＤリスト３３０４フィールドは、ストレージプールを共有するストレージノード１０のノードＩＤを管理する。

なお、図７のクラスタプール管理テーブル３３０に記載された値は、図３に示した分散型ストレージシステム１の構成に対応するものではない。一方、図５、図６、図８～図１２に例示した各テーブルの値は、概ね、図３に示した分散型ストレージシステム１の構成に対応するようにしている。

（２－２）ノード内制御情報テーブル４００
図８は、ノードプール管理テーブル４１０の構成例を示す図である。ノードプール管理テーブル４１０は、ノード内制御情報テーブル４００に属し、各ストレージノード１０内でのみ管理される情報を管理するテーブルである。

ノードプール管理テーブル４１０は、各ノードプールの容量状況を示す。図７に示したクラスタプール管理テーブル３３０の説明で前述したように、ノードプールとは、ストレージノード１０ごとのドライブ容量を合計した容量を持つプールである。

ノードプール管理テーブル４１０は、ノードプールＩＤ４１０１、ノードＩＤ４１０２、全容量４１０３、及び使用容量４１０４のフィールドを有して構成される。ノードプールＩＤ４１０１フィールドは、ノードプールを識別する識別子（ノードプールＩＤ）を管理する。ノードＩＤ４１０２フィールドは、ノードプールを共有するストレージノード１０のノードＩＤを管理する。全容量４１０３フィールドは、ノードプールの全容量を管理し、使用容量４１０４フィールドは、ノードプールで使用中の使用容量を管理する。

図９は、データ領域管理テーブル４２０の構成例を示す図である。データ領域管理テーブル４２０は、ノード内制御情報テーブル４００に属し、各ストレージノード１０内でのみ管理される情報を管理するテーブルである。

図９に示すように、データ領域管理テーブル４２０は、内部的に、ボリューム管理テーブル４２１、サブボリューム管理テーブル４２２、スライス管理テーブル４２３、及びページ管理テーブル４２４を備える。

ボリューム管理テーブル４２１は、分散型ストレージシステム１に形成されるボリューム１００の構成情報を管理するテーブルであり、ボリュームＩＤ４２１１、属性４２１２、サイズ４２１３、及び分散ノード数４２１４のフィールドを有して構成される。

ボリュームＩＤ４２１１フィールドは、ボリューム１００を識別する識別子（ボリュームＩＤ）を管理する。属性４２１２フィールドは、ボリューム１００の属性（ローカライズドボリュームであるか、スケーラブルボリュームであるか）を管理する。サイズ４２１３フィールドは、ボリューム１００の容量（サイズ）を管理する。分散ノード数４２１４フィールドは、ボリューム１００の分散数、すなわち、１つのボリューム１００がいくつのノード上のサブボリューム１１０から構成されるかを示す値、を管理する。属性４２１２フィールドの値が「ローカライズド」である場合、分散数は「１」となり、属性４２１２フィールドの値が「スケーラブル」である場合、クラスタが備えるノード数やユーザの設定などから分散数が定まる。

サブボリューム管理テーブル４２２は、ボリューム１００に属する各サブボリューム１１０の構成情報を管理するテーブルであり、サブボリュームＩＤ４２２１、サイズ４２２２、ボリュームＩＤ４２２３、ノードＩＤ４２２４、及びサブボリューム管理情報テーブルＩＤ４２２５のフィールドを有して構成される。

サブボリュームＩＤ４２２１フィールドは、サブボリューム１１０を識別する識別子（サブボリュームＩＤ）を管理する。サイズ４２２２フィールドは、サブボリューム１１０の容量（サイズ）を管理する。ボリュームＩＤ４２２３フィールドは、サブボリューム１１０が属するボリューム１００のボリュームＩＤを管理する。ノードＩＤ４２２４フィールドは、サブボリューム１１０が形成されるストレージノード１０のノードＩＤを管理する。サブボリューム管理情報テーブルＩＤ４２２５フィールドは、サブボリューム１１０を管理するための制御情報を格納するサブボリューム管理情報テーブルの識別子を管理する。なお、サブボリューム管理情報テーブルは、ストレージ制御ソフト２３が実装する機能の適用有無や上記機能に関する設定情報を管理するテーブルであるが、ストレージ制御ソフト２３の実装形態によってその内容が異なるため、図示による説明を省略する。サブボリューム１１０内のスライス１２０に対しては、サブボリューム１１０に従って機能の適用有無や上記機能に関する設定情報が設定される。

スライス管理テーブル４２３は、サブボリューム１１０に割り当てられたスライス１２０の構成情報を管理するテーブルであり、スライスＩＤ４２３１、サイズ４２３２、ページ割当済サイズ４２３３、ページ割当ビットマップ４２３４、サブボリュームＩＤ４２３５、サブボリュームＬＢＡ４２３６、ボリュームＩＤ４２３７、及びボリュームＬＢＡ４２３８のフィールドを有して構成される。

スライスＩＤ４２３１フィールドは、各スライス１２０を識別する識別子（スライスＩＤ）を管理する。サイズ４２３２フィールドは、スライス１２０の容量（サイズ）を管理する。

ページ割当済サイズ４２３３フィールドは、スライス１２０でページ１３０が既に割り当たっているサイズを管理する。ページ割当ビットマップ４２３４フィールドは、スライス１２０で割り当たっているページ１３０を示すビットマップを管理する。ビットマップは具体的には、割り当て済みのページを「１」で示し、未割り当てのページを「０」で示す。

サブボリュームＩＤ４２３５フィールドは、スライス１２０が属するサブボリューム１１０のサブボリュームＩＤを管理する。サブボリュームＬＢＡ４２３６フィールドは、スライス１２０が属するサブボリューム１１０における当該スライス１２０の位置を示すＬＢＡ（Logical Block Address）を管理する。ボリュームＩＤ４２３７フィールドは、スライス１２０が属するボリューム１００のボリュームＩＤを管理する。ボリュームＬＢＡ４２３８フィールドは、スライス１２０が属するボリューム１００における当該スライス１２０の位置を示すＬＢＡを管理する。

ページ管理テーブル４２４は、スライス１２０に対応する物理的なデータ領域であるページ１３０の構成情報を管理するテーブルであり、ページＩＤ４２４１、サイズ４２４２、スライスＩＤ４２４３、サブボリュームＩＤ４２４４、及びサブボリュームＬＢＡ４２４５のフィールドを有して構成される。

ページＩＤ４２４１フィールドは、各ページ１３０を識別する識別子（ページＩＤ）を管理する。サイズ４２４２フィールドは、ページ１３０の容量（サイズ）を管理する。

スライスＩＤ４２４３フィールドは、ページ１３０に対応するスライス１２０のスライスＩＤを管理する。本実施形態では、一例として、１つのページ１３０の物理的容量と１つのスライス１２０の論理的容量とを同じサイズとすることにより、スライス１２０にページ１３０を割り当てるとき、対応関係を有するスライス１２０とページ１３０とを１対１で管理することができる。

サブボリュームＩＤ４２４４フィールドは、ページ１３０が割り当てられたサブボリューム１１０のサブボリュームＩＤを管理する。サブボリュームＬＢＡ４２４５フィールドは、ページ１３０が割り当てられたサブボリューム１１０における当該スライス１２０の位置を示すＬＢＡを管理する。

図１０は、ホストパス管理テーブル４３０の構成例を示す図である。ホストパス管理テーブル４３０は、ノード内制御情報テーブル４００に属し、各ストレージノード内でのみ管理される情報を管理するテーブルである。

ホストパス管理テーブル４３０は、ホストパスを管理するテーブルであり、ホストパスＩＤ４３０１、サブボリュームＩＤ４３０２、イニシエータＩＤ４３０３、ＡＬＵＡ設定４３０４、及び接続ノードＩＤ４３０５のフィールドを有して構成される。ホストパスとは、ホストコンピュータ３０上のイニシエータから各ストレージノード１０に属するサブボリューム１１０との間で論理的に定義される経路である。

ホストパスＩＤ４３０１フィールドは、ホストパスを識別する識別子（ホストパスＩＤ）を管理する。サブボリュームＩＤ４３０２フィールドは、ホストパスの端点となるサブボリューム１１０のサブボリュームＩＤを管理する。イニシエータＩＤ４３０３フィールドは、ホストパスの端点となるイニシエータを識別する識別子（イニシエータＩＤ）を管理する。

ＡＬＵＡ設定４３０４フィールドは、ホストパスにおけるＡＬＵＡ（Asymmetric Logical Unit Access）の設定を管理する。ＡＵＬＡの設定とは、各イニシエータからサブボリューム１１０に対するホストパスのうち優先的に使用されるパスの設定である。例えば、ボリューム１００Ａのように、１つのサブボリューム１１０に全てのスライス１２０がマッピングされているローカライズドボリュームに対しては、当該サブボリューム１１０に対するホストパスのみを「Ｏｐｔｉｍｉｚｅ（最適化）」に設定することで、ストレージノード１０の間での転送を抑止することができ、ストレージの性能向上につながる。

接続ノードＩＤ４３０５フィールドは、ホストパスが接続されるストレージノード１０のノードＩＤを管理する。

図１１は、ＨＷモニタ情報管理テーブル４４０の構成例を示す図である。ＨＷモニタ情報管理テーブル４４０は、ノード内制御情報テーブル４００に属し、各ストレージノード１０内でのみ管理される情報を管理するテーブルである。

ＨＷモニタ情報管理テーブル４４０は、各ストレージノード１０に搭載されるハードウェアのモニタ情報を、後述する内部テーブルに格納する。分散型ストレージシステム１は、このようなＨＷモニタ情報管理テーブル４４０で管理するモニタ情報に基づいて、ストレージノード１０に搭載された各ＨＷの負荷を監視することができ、当該監視において負荷の閾値超過を検出することで、適切なタイミングでリバランス処理を実行することができる。なお、ＨＷモニタ情報管理テーブル４４０が備える内部テーブルの情報は、クラスタ管理プログラム２３０のモニタ機能によって定期的に更新される。更新時、各テーブルには、モニタ機能が参照した瞬間の値を格納するとしてもよいし、一定期間の平均値や中央値を格納するなどとしてもよい。

図１１に示すように、ＨＷモニタ情報管理テーブル４４０は、内部的に、ＣＰＵモニタ情報管理テーブル４４１、ドライブモニタ情報管理テーブル４４２、ネットワークモニタ情報管理テーブル４４３、及びホストパスモニタ情報管理テーブル４４４を備える。

ＣＰＵモニタ情報管理テーブル４４１は、ストレージノード１０が備えるＣＰＵ１１のモニタ情報を管理するためのテーブルであり、ＣＰＵ ＩＤ４４１１、及び使用率４４１２のフィールドを有して構成される。

ＣＰＵ ＩＤ４４１１フィールドは、各ＣＰＵ１１を識別する識別子（ＣＰＵ ＩＤ）を管理する。使用率４４１２フィールドは、各ＣＰＵ１１のＣＰＵ使用率を管理する。

ドライブモニタ情報管理テーブル４４２は、ストレージノード１０が備えるドライブ１５のモニタ情報を管理するためのテーブルであり、ドライブＩＤ４４２１、リードＩＯＰＳ４４２２、ライトＩＯＰＳ４４２３、リード転送量４４２４、ライト転送量４４２５、及び使用率４４２６のフィールドを有して構成される。

ドライブＩＤ４４２１フィールドは、各ストレージノード１０に搭載されたドライブ１５を識別する識別子（ドライブＩＤ）を管理する。リードＩＯＰＳ４４２２フィールドは、リードＩＯ処理時のドライブ１５におけるＩＯＰＳ（Input/Output Per Second）を管理する。ライトＩＯＰＳ４４２３フィールドは、ライトＩＯ処理時のドライブ１５におけるＩＯＰＳを管理する。リード転送量４４２４フィールドは、リードＩＯ処理時のドライブ１５におけるデータ転送速度（リード転送量）を管理する。ライト転送量４４２５フィールドは、ライトＩＯ処理時のドライブ１５におけるデータ転速度（ライト転送量）を管理する。使用率４４２６フィールドは、ドライブ１５の容量使用率を管理する。

ネットワークモニタ情報管理テーブル４４３は、ネットワークＩ／Ｆ１３Ａ及びネットワーク２０Ａを介してストレージノード１０の間で通信される転送量（本例では、転送速度によって転送量を表している）のモニタ情報を管理するためのテーブルである。ネットワークモニタ情報管理テーブル４４３は、ネットワークＩ／Ｆ ＩＤ４４３１、送信転送量４４３２、受信転送量４４３３、及び最大転送量４４３４のフィールドを有して構成される。

ネットワークＩ／Ｆ ＩＤ４４３１フィールドは、各ネットワークＩ／Ｆ１３Ａを識別する識別子（ネットワークＩ／Ｆ ＩＤ）を管理する。送信転送量４４３２フィールドは、ネットワークＩ／Ｆ１３Ａを経由するストレージノード１０間の通信におけるデータ送信時の転送速度（送信転送量）を管理する。受信転送量４４３３フィールドは、ネットワークＩ／Ｆ１３Ａを経由するストレージノード１０間の通信におけるデータ受信時の転送速度（受信転送量）を管理する。最大転送量４４３４フィールドは、ネットワークＩ／Ｆ１３Ａを経由する通信における転送速度の最高速度（最大転送量）を管理する。

ホストパスモニタ情報管理テーブル４４４は、各サブボリューム１１０とホストコンピュータ３０に属するイニシエータとの間に張られるホストパス上で通信される転送量のモニタ情報を管理するためのテーブルである。ホストパスモニタ情報管理テーブル４４４は、ホストパスＩＤ４４４１、リードＩＯＰＳ４４４２、ライトＩＯＰＳ４４４３、リード転送量４４４４、及びライト転送量４４４５のフィールドを有して構成される。

ホストパスＩＤ４４４１フィールドは、ホストパスを識別するホストパスＩＤを管理する。ホストパスＩＤフィールドにおける各ＩＤは、ホストパス管理テーブル４３０のホストパスＩＤ４３０１フィールドのレコードに対応する。リードＩＯＰＳ４４４２フィールドは、リードＩＯ処理時のホストパスにおけるＩＯＰＳを管理する。ライトＩＯＰＳ４４４３フィールドは、ライトＩＯ処理のホストパスにおけるＩＯＰＳを管理する。リード転送量４４４４フィールドは、リードＩＯ処理時のホストパスにおけるデータ転送速度（リード転送量）を管理する。ライト転送量４４４５フィールドは、ライトＩＯ処理時のホストパスにおけるデータ転送速度（ライト転送量）を管理する。

図１２は、データ領域モニタ情報管理テーブル４５０の構成例を示す図である。データ領域モニタ情報管理テーブル４５０は、ノード内制御情報テーブル４００に属し、各ストレージノード１０内でのみ管理される情報を管理するテーブルである。

データ領域モニタ情報管理テーブル４５０は、サブボリューム１１０及びスライス１２０といったデータ領域ごとの負荷情報を管理するテーブルであって、図１２に示すように、内部的に、サブボリュームモニタ情報管理テーブル４５１、及びスライスモニタ情報管理テーブル４５２を備える。

データ領域モニタ情報管理テーブル４５０がデータ領域ごとの負荷情報を管理することにより、分散型ストレージシステム１は、リバランス処理の際に、高負荷なデータ領域や低負荷なデータ領域など、ユーザのリバランスポリシーに応じて適切なデータ領域を選択することができる。なお、データ領域モニタ情報管理テーブル４５０は、例えばストレージ制御ソフト２３が提供するコンポーネントによって明示的に更新される。

サブボリュームモニタ情報管理テーブル４５１は、サブボリューム１１０ごとのＩＯ処理による負荷を管理するテーブルであって、サブボリュームＩＤ４５１１、リードＩＯＰＳ４５１２、ライトＩＯＰＳ４５１３、リード転送量４５１４、及びライト転送量４５１５のフィールドを有して構成される。

サブボリュームＩＤ４５１１フィールドは、サブボリューム１１０を識別するサブボリュームＩＤを管理する。リードＩＯＰＳ４５１２フィールドは、リードＩＯ処理時のサブボリューム１１０におけるＩＯＰＳを管理する。ライトＩＯＰＳ４５１３フィールドは、ライトＩＯ処理時のサブボリューム１１０におけるＩＯＰＳを管理する。リード転送量４５１４フィールドは、リードＩＯ処理時のサブボリューム１１０におけるデータ転送速度（リード転送量）を管理する。ライト転送量４５１５フィールドは、ライトＩＯ処理時のサブボリューム１１０におけるデータ転送速度（ライト転送量）を管理する。

スライスモニタ情報管理テーブル４５２は、スライス１２０の負荷情報を管理するテーブルであって、スライスＩＤ４５２１、リードＩＯＰＳ４５２２、ライトＩＯＰＳ４５２３、リード転送量４５２４、及びライト転送量４５２５のフィールドを有して構成される。

スライスＩＤ４５２１フィールドは、スライス１２０を識別するスライスＩＤを管理する。リードＩＯＰＳ４５２２フィールドは、リードＩＯ処理時のスライス１２０におけるＩＯＰＳを管理する。ライトＩＯＰＳ４５２３フィールドは、ライトＩＯ処理時のスライス１２０におけるＩＯＰＳを管理する。リード転送量４５２４フィールドは、リードＩＯ処理時のスライス１２０におけるデータ転送速度（リード転送量）を管理する。ライト転送量４５２５フィールドは、ライトＩＯ処理時のスライス１２０におけるデータ転送速度（ライト転送量）を管理する。

（３）処理
以下では、本実施形態に係る分散型ストレージシステム１において実行される、データ処理またはデータ領域管理処理として、ボリューム作成処理、ライトＩＯ処理、リードＩＯ処理、リバランス処理、ノード増減設処理、及びボリュームサイズ変更処理について、その処理手順例を詳しく説明する。各処理の説明では、必要に応じて、図１～図１２を参照しながら説明した構成及びテーブル等のデータを用いる。

（３－１）ボリューム作成処理
図１３は、ボリューム作成処理の処理手順例を示すフローチャートである。ボリューム作成処理は、ボリューム管理プログラム２２０が実行する処理の１つである。

ユーザ（分散型ストレージシステム１の管理者）は、不図示の管理コンソールを操作するなどにより、例えばＨＴＴＰなどのデータ転送のプロトコルを介して、分散型ストレージシステム１にコマンドを送信して、ボリューム１００の作成を指示することができる。このとき、コマンドを受け取った分散型ストレージシステム１では、管理コンソールで指定されたノード（あるいは、マスタノードの役割を持つストレージノード１０）の制御部（不図示）が、ＨＴＴＰ等によって指示されたコマンドを解釈し、ボリューム管理プログラム２２０によるボリューム作成処理を呼び出す。

図１３によればまず、ボリューム管理プログラム２２０は、ユーザから作成を指定されたボリューム１００の属性がスケーラブルボリュームであるか否かを判定する（ステップＳ１０１）。スケーラブルボリュームの作成が指定された場合は（ステップＳ１０１のＹＥＳ）、ステップＳ１０２に進み、スケーラブルボリュームの作成が指定されていない、すなわち、ローカライズドボリュームの作成が指定された場合は（ステップＳ１０１のＮＯ）、ステップＳ１０８に進む。

ステップＳ１０２では、ボリューム管理プログラム２２０は、解釈したコマンドの内容に基づいて、作成するスケーラブルボリュームのサイズ及び分散ノード数を取得する。但し、分散ノード数は、コマンドによって指定される方式でもよいし、クラスタのポリシーで一意に決定される方式でもよい。後者の方式では例えば、クラスタに属するノード数、ホストコンピュータ３０とストレージノード１０との間に定義できる最大ホストパス数などに基づいて、分散ノード数を一意に決定することができる。

次に、ボリューム管理プログラム２２０は、ノードプール管理テーブル４１０を参照し、各ストレージノード１０に属するノードプールの空き容量を取得する（ステップＳ１０３）。

次に、ボリューム管理プログラム２２０は、サブボリューム１１０を作成するノード（ストレージノード１０）と、当該ノードに割り当てる合計スライスサイズとを決定する（ステップＳ１０４）。

ここで、ステップＳ１０４の処理を補足して説明する。

図３を参照しながら前述したように、サブボリューム１１０に割り当てられるスライス１２０の合計サイズ（合計スライスサイズ）は、各サブボリューム１１０における実質的な容量を意味する。そこで、ステップＳ１０４においてボリューム管理プログラム２２０は、ボリューム１００の形成においてストレージノード１０の間の偏りをなくすため、できるだけ均等になるように、各ストレージノード１０に割り当てる合計スライスサイズを決定する。具体的には例えば、サイズが８０ＴＢで分散ノード数が８のスケーラブルボリュームを作成する場合には、１つのノードに割り当てられる合計スライスサイズは、１０ＴＢずつとなることが望ましい。

前述のように望ましい合計スライスサイズを決定すると、次に、ボリューム管理プログラム２２０は、作成するストレージノード１０を決定する。前述した具体例を用いると、ボリューム管理プログラム２２０は、ステップＳ１０２で取得したノードプールの空き容量に基づいて、１０ＴＢ以上の空き容量を有するストレージノード１０を優先的に、サブボリューム１１０を作成するノードとして選択する。

但し、サブボリューム１１０を作成するノードの決定において、一部のノードプールの空き容量が望ましい容量（具体例では１０ＴＢ）に満たない場合には、ボリューム管理プログラム２２０は、不足する分の容量を他のノードで均等に分配する。例えば、前述した具体例のように８つのノードに跨って合計８０ＴＢのスケーラブルボリュームを作成するときに、３ＴＢしか空き容量がないノードにサブボリューム１１０を作成する必要がある場合には、不足する７ＴＢを他のノードで均等に分配することにより、１１ＴＢを割り当てる７つのノードと、３ＴＢを割り当てる１つのノードとを決定することができる。

なお、上記の補足説明では、各ストレージノード１０に割り当てる合計スライスサイズを決定してから、サブボリューム１１０を作成するストレージノード１０を決定したが、ステップＳ１０４では、これらの処理の実行順序を入れ替えてもよい。また、上記の補足説明では、容量の観点からできるだけ均等な分配を行う方法を説明したが、負荷の観点から均等な分配を行うようにしてもよいし、容量及び負荷をともに考慮して均等な分配を行うようにしてもよい。

ステップＳ１０４の終了後、あるいは、後述するステップＳ１１０の終了後、ボリューム管理プログラム２２０は、ステップＳ１０５またはステップＳ１１０で決定した各ストレージノード１０に対して、サブボリューム１１０を定義する（ステップＳ１０５）。このとき、図３を参照して説明したように、サブボリューム１１０のサイズは、ボリューム１００と同じサイズで論理的な空間を定義する。

次に、ボリューム管理プログラム２２０は、ステップＳ１０５で作成したサブボリューム１１０に対して割り当てるスライス１２０のアドレスを決定する（ステップＳ１０６）。アドレスは機械的に割り当てられると考えてよい。

そして、ボリューム管理プログラム２２０は、ステップＳ１０６までの処理で決定された、ボリューム１００、サブボリューム１１０、及びスライス１２０の情報を、データ領域管理テーブル４２０に反映して更新し（ステップＳ１０７）、ボリューム作成処理を終了する。

一方、ボリューム作成指示のコマンドにおいてローカライズドボリュームの作成が指定された場合は、ステップＳ１０１でＮＯと判定され、ステップＳ１０８の処理が行われる。ステップＳ１０８では、ボリューム管理プログラム２２０は、解釈したコマンドの内容に基づいて、作成するローカライズドボリュームのサイズを取得する。ローカライズドボリュームの場合は、分散ノード数は１に固定される。

次に、ボリューム管理プログラム２２０は、ステップＳ１０３と同様にして、ノードプール管理テーブル４１０を参照し、各ストレージノード１０に属するノードプールの空き容量を取得する（ステップＳ１０９）。

次に、ボリューム管理プログラム２２０は、ステップＳ１０４におけるノードの決定と同様な方法で、サブボリューム１１０を作成する１つのノードを決定する（ステップＳ１１０）。なお、ローカライズドボリュームを作成する際は、サブボリューム１１０の作成数も１つに固定されるため、合計スライスサイズを決定する処理は不要となる。

ステップＳ１１０の処理後は、ステップＳ１０５に進み、上述したステップＳ１０５～Ｓ１０７の処理を行う。すなわち、ボリューム管理プログラム２２０は、ステップＳ１１０で決定したストレージノード１０にサブボリューム１１０を作成し（ステップＳ１０５）、サブボリューム１１０に割り当てるスライスのアドレスを決定し（ステップＳ１０６）、諸情報をデータ領域管理テーブル４２０に反映し（ステップＳ１０７）、ボリューム作成処理を終了する。

以上のようにボリューム作成処理が実行されることにより、ボリューム管理プログラム２２０は、スケーラブルボリュームまたはローカライズドボリュームの属性を問わず、ユーザ（管理者）による指示に応じて、ストレージノード１０の間の偏りを抑えながら、ボリューム１００を作成することができる。

（３－２）ライトＩＯ処理
図１４は、ライトＩＯ処理の処理手順例を示すフローチャートである。ライトＩＯ処理は、リードライト処理プログラム２１０が実行する処理の１つである。リードライト処理プログラム２１０によるライトＩＯ処理は、ホストコンピュータ３０から発行されたＳＣＳＩのライトコマンドを処理するために呼び出される。ＳＣＳＩのライトコマンドは、任意のデータをボリューム１００の所望のアドレス（ＬＢＡ）に書き込もうとする際に、ホストコンピュータ３０から発行されるコマンドであって、分散型ストレージシステム１のノード（例えば、マスタノードの役割を有するストレージノード１０）に送信される。

図１４によればまず、リードライト処理プログラム２１０は、受信したライトコマンドを解析することで、アクセス対象のボリューム１００のＩＤ及びＬＢＡと、アクセス長とを特定し、特定した情報を用いてデータ領域管理テーブル４２０のスライス管理テーブル４２３を参照することにより、アクセス対象のボリューム１００及びそのＬＢＡに該当するスライス１２０を特定する（ステップＳ２０１）。図９の説明で前述したように、スライス管理テーブル４２３において、ボリュームＩＤ４２３７フィールドは、スライス１２０が属するボリューム１００のボリュームＩＤを管理し、ボリュームＬＢＡ４２３８フィールドは、スライス１２０が属するボリューム１００における当該スライス１２０の位置を示すＬＢＡを管理している。

なお、ステップＳ２０１では、アクセス対象のＬＢＡやアクセス長によっては、複数のスライス１２０がアクセス対象に該当する場合があり得る。その場合でも、リードライト処理プログラム２１０は、ステップＳ２０２以降の処理を順次実行する。

ステップＳ２０２では、リードライト処理プログラム２１０は、サブボリューム管理テーブル４２２及びスライス管理テーブル４２３を参照して、ステップＳ２０１で特定したアクセス対象のスライスが自ノードにあるか否かを判定する。自ノードとは、当該ステップの処理を実行しているリードライト処理プログラム２１０がメモリ１２に格納されているストレージノード１０を意味する。アクセス対象のスライスが自ノードにある場合は（ステップＳ２０２のＹＥＳ）、ステップＳ２０４に進み、アクセス対象のスライスが自ノードにない場合は（ステップＳ２０２のＮＯ）、ステップＳ２０３に進む。

ステップＳ２０３では、リードライト処理プログラム２１０は、アクセス対象のスライス１２０が存在するストレージノード１０に、ライトコマンドを転送する。その後、当該コマンドを受け取ったストレージノード１０において、リードライト処理プログラム２１０によるライトＩＯ処理が呼び出され、図１４のフローチャートに沿って、ステップＳ２０１から処理が実行される。

ステップＳ２０４では、リードライト処理プログラム２１０は、自ノードに格納されたページ管理テーブル４２４を参照し、アクセス対象のスライス１２０に対応するページ１３０を特定する。

次に、リードライト処理プログラム２１０は、ステップＳ２０４におけるページ１３０の特定において、アクセス対象のデータ領域に、既にページ１３０が割り当っているか否かを判定する（ステップＳ２０５）。アクセス対象のデータ領域にページ１３０が割り当て済みの場合は（ステップＳ２０５のＹＥＳ）、ステップＳ２０７に進み、アクセス対象のデータ領域にページ１３０が未割り当ての場合は（ステップＳ２０５のＮＯ）、ステップＳ２０６に進む。

ステップＳ２０６では、リードライト処理プログラム２１０は、アクセス対象のデータ領域に、新規にページ１３０を割り当てる。前述したように、ページ１３０の割り当てには、シンプロビジョニングの技術を用いることができ、あるデータ領域に初めて書き込みがなされた場合に、論理的なデータ領域（スライス１２０）に対して物理的なデータ領域（ページ１３０）が動的に割り当てられる。すなわち、リードライト処理プログラム２１０は、アクセス対象のスライス１２０にある論理的なアドレス空間に対して、ドライブ１５の物理的なアドレスを割り当てる。その後、ステップＳ２０７に進む。

ステップＳ２０７では、リードライト処理プログラム２１０は、ライトコマンドによって発行されたデータをドライブ１５におけるアクセス対象のデータ領域（すなわち、ページ１３０）に書き込む。

そして、リードライト処理プログラム２１０は、ステップＳ２０７におけるドライブ１５へのデータの書き込み完了を確認後に、ホストコンピュータ３０にライト結果を応答する処理を実行し（ステップＳ２０８）、ライトＩＯ処理を終了する。

なお、ステップＳ２０３の処理によってライトコマンドが別のストレージノード１０から転送されて、転送先のストレージノード１０で図１４の処理が実行されてステップＳ２０８に至った場合は、転送先のリードライト処理プログラム２１０は、転送元のストレージノード１０にライト結果の応答を送信し、転送元のストレージノード１０を経由してホストコンピュータ３０に応答を返す。

以上のようにライトＩＯ処理が実行されることにより、アクセス対象のスライス１２０を有するストレージノード１０のリードライト処理プログラム２１０は、ライトコマンドに応じて、自ノードのドライブ１５（詳細には、アクセス対象のスライス１２０に対応して割り当てられたページ１３０）に、データを書き込むことができる。

（３－３）リードＩＯ処理
図１５は、リードＩＯ処理の処理手順例を示すフローチャートである。リードＩＯ処理は、リードライト処理プログラム２１０が実行する処理の１つである。リードライト処理プログラム２１０によるリードＩＯ処理は、ホストコンピュータ３０から発行されたＳＣＳＩのリードコマンドを処理するために呼び出される。ＳＣＳＩのリードコマンドは、ボリューム１００の任意のアドレス（ＬＢＡ）に格納された所望のデータを読み出そうとする際に、ホストコンピュータ３０から発行されるコマンドであって、分散型ストレージシステム１のノード（例えば、マスタノードの役割を有するストレージノード１０）に送信される。

図１５によればまず、リードライト処理プログラム２１０は、図１４に示したライトＩＯ処理のステップＳ２０１～Ｓ２０４と同様の処理を行う（ステップＳ３０１～Ｓ３０４）。

すなわち、ステップＳ３０１において、リードライト処理プログラム２１０は、受信したリードコマンドを解析して、アクセス対象のボリューム１００のＩＤ及びＬＢＡと、アクセス長とを特定し、特定した情報を用いて、アクセス対象に該当するスライス１２０を特定する。そして、ステップＳ３０２では、リードライト処理プログラム２１０は、アクセス対象のスライス１２０が自ノードにあるか否かを判定する。アクセス対象のスライス１２０が自ノードにない場合は、ステップＳ３０３において、該当するノードにリードコマンドを転送し、転送先のノードでリードＩＯ処理が呼び出されて以降の処理が行われる。一方、アクセス対象のスライス１２０が自ノードにある場合は、ページ管理テーブル４２４を参照し、アクセス対象のスライス１２０に対応するページ１３０を特定する。

ステップＳ３０４の処理後、リードライト処理プログラム２１０は、ステップＳ３０４で特定したページ１３０にアクセスし、アクセス対象のデータ領域に格納されているデータをドライブ１５から読み出す（ステップＳ３０５）。なお、図示は省略するが、アクセス対象のデータ領域にページ１３０が未割り当てである場合は、リードライト処理プログラム２１０は、リード結果として「０」のデータを返す。

そして、リードライト処理プログラム２１０は、ステップＳ３０５におけるドライブ１５からのデータの読み出し完了を確認後に、ホストコンピュータ３０にリード結果を応答する処理を実行し（ステップＳ３０６）、リードＩＯ処理を終了する。

なお、ステップＳ３０３の処理によってリードコマンドが別のストレージノード１０から転送されて、転送先のストレージノード１０で図１５の処理が実行されてステップＳ３０６に至った場合は、転送先のリードライト処理プログラム２１０は、転送元のストレージノード１０にリード結果の応答を送信し、転送元のストレージノード１０を経由してホストコンピュータ３０に応答を返す。

以上のようにリードＩＯ処理が実行されることにより、アクセス対象のスライス１２０を有するストレージノード１０のリードライト処理プログラム２１０は、リードコマンドに応じて、自ノードのドライブ１５（詳細には、アクセス対象のスライス１２０に対応するページ１３０）から、データを読み出し、応答することができる。

（３－４）リバランス処理
図１６は、リバランス処理の処理手順例を示すフローチャートである。リバランス処理は、リバランス処理プログラム２４０が実行する処理の１つである。いずれかのストレージノード１０で負荷や容量が所定の閾値を超えたことが検出されたときに、リバランス処理プログラム２４０によるリバランス処理が呼び出される。

分散型ストレージシステム１では、例えば、マスタノードのリバランス処理プログラム２４０が、周期的に各ノードのリバランス処理プログラム２４０に閾値の超過をチェックさせる。そして、何れかのノードで閾値の超過が検出された場合に、マスタノードのリバランス処理プログラム２４０が主導して、図１６の処理を行う。

図１６のステップＳ４０１において、リバランス処理プログラム２４０は、ノードプール管理テーブル４１０及びＨＷモニタ情報管理テーブル４４０を参照して、閾値を超過したパラメタが、容量であるか否かを判定する（ステップＳ４０１）。すなわち、リバランス処理プログラム２４０は、ノードプール管理テーブル４１０のパラメタが閾値超過している場合は容量が閾値を超過していると判断でき、ＨＷモニタ情報管理テーブル４４０のいずれかのリソースが閾値超過している場合は負荷が閾値を超過していると判断できる。

そして、容量が閾値を超過したと判定した場合（ステップＳ４０１のＹＥＳ）、リバランス処理プログラム２４０は、容量の観点からボリューム１００のデータをノード間で再分配する「容量リバランス処理」を呼び出して実行し（ステップＳ４０２）、その完了後にリバランス処理を終了する。一方、負荷が閾値を超過したと判定した場合（ステップＳ４０１のＮＯ）、リバランス処理プログラム２４０は、負荷の観点からボリューム１００のデータをノード間で再分配する「負荷リバランス処理」を呼び出して実行し（ステップＳ４０３）、その完了後にリバランス処理を終了する。

図１７は、容量リバランス処理の処理手順例を示すフローチャートである。容量リバランス処理は、図１６のステップＳ４０２に相当する処理であって、リバランス処理プログラム２４０が実行する処理の１つである。前述したように、容量リバランス処理は、容量のパラメタが閾値を超過した場合に、リバランス処理から呼び出される。

図１７によればまず、リバランス処理プログラム２４０は、容量の閾値超過が起きているストレージノード１０を特定する（ステップＳ４１１）。具体的には、ステップＳ４１１においてリバランス処理プログラム２４０は、ノードプール管理テーブル４１０を参照し、使用容量４１０４フィールドの値を全容量４１０３フィールドの値で割ることによって、プールノードごとの容量使用率を計算する。そして、計算した容量使用率が閾値を超えているノードプールのＩＤを特定し（ノードプールＩＤ４１０１フィールド）、該当するレコードのノードＩＤ４１０２フィールドの値（ノードＩＤ）を確認することで、容量の閾値超過が起きているストレージノード１０を特定する。

次に、リバランス処理プログラム２４０は、ステップＳ４１１で特定したストレージノード１０に属するボリューム１００のうちから、リバランスポリシー管理テーブル３２０の「優先ボリュームポリシー」の設定に従って、１つのボリューム１００を選択する（ステップＳ４１２）。

次に、リバランス処理プログラム２４０は、ステップＳ４１２で選択したボリューム１００がスケーラブルボリュームであるか否かを判定する（ステップＳ４１３）。スケーラブルボリュームである場合は（ステップＳ４１３のＹＥＳ）、ステップＳ４１４に進み、スケーラブルボリュームではない、すなわちローカライズドボリュームである場合は（ステップＳ４１３のＮＯ）、ステップＳ４１７に進む。

ステップＳ４１２で選択したボリューム１００がスケーラブルボリュームである場合に実行されるステップＳ４１４では、リバランス処理プログラム２４０は、ステップＳ４１２で選択したボリューム１００に属するサブボリューム１１０のうちから、リバランスポリシー管理テーブル３２０の「優先サブボリュームポリシー（容量）」の設定に従って、１つのサブボリューム１１０を選択する。

次いで、リバランス処理プログラム２４０は、ステップＳ４１４で選択したサブボリューム１１０に割り当てられたスライス１２０のうち、ページ１３０が未割り当てのスライス１２０を別のノード（ストレージノード１０）に移行する（ステップＳ４１５）。ステップＳ４１５において、ページ１３０が未割り当てのスライス１２０は、スライス管理テーブル４２３のページ割当済サイズ４２３３フィールドに基づいて判定することができ、リバランス処理プログラム２４０は、該当する全てのスライス１２０を、選択中のボリューム１００を共有する別のストレージノード１０においてなるべく均等な数になるように、移行する。

ここで、ステップＳ４１５において上記の処理を行う理由を詳しく説明する。ページ１３０が未割り当てのスライス１２０によって管理される領域には、データがまだ格納されていないため、当該スライス１２０を別のストレージノード１０に移行する際は、データの転送は不要で、スライス１２０の割り当てに関する制御情報のみを更新（書き換え）すればよい。そのため、スライス１２０の移行によるオーバヘッドが小さい。加えて、ページ１３０が未割り当てのスライス１２０を予め別のストレージノード１０に移行しておくことで、容量が閾値を超えたストレージノード１０に対して、将来の新規ライトが行われる確率を低減することができる。

ステップＳ４１５の処理後、リバランス処理プログラム２４０は、ステップＳ４１４で選択したサブボリューム１１０に属し、かつページ１３０が割り当て済みのスライス１２０のうちから、リバランスポリシー管理テーブル３２０の「スライス選択ポリシー」に従って選択されるスライス１２０を、リバランスポリシー管理テーブル３２０の「移行先ノード選択ポリシー」の設定に従って選択されるストレージノード１０（移行先ノード）に移行する（ステップＳ４１６）。

ステップＳ４１６の処理によって、スライス１２０に割り当てられたデータの少なくとも一部が、別のストレージノード１０に移行され、この結果、移行元のストレージノード１０におけるノードプールの使用容量を低減することができる。なお、ステップＳ４１６の処理は、移行元のストレージノード１０（言い換えれば、ステップＳ４１１で選択されたストレージノード１０）におけるノードプールの使用容量が閾値を下回るまで、繰り返し実行され、その完了後に、ステップＳ４１８に進む。

一方、ステップＳ４１２で選択したボリューム１００がローカライズドボリュームである場合、当該ボリューム１００に属するスライス１２０は１つのサブボリューム１１０にマッピングされるため、ノード間でスライス１２０の配置を変更することはできない。

そこで、ステップＳ４１３のＮＯを経て移行するステップＳ４１７では、リバランス処理プログラム２４０は、サブボリューム１１０の単位で、サブボリューム１１０及びボリューム１００を移行先ノードに移行する。

具体的には、ステップＳ４１７において、リバランス処理プログラム２４０は、ステップＳ４１２で選択したボリューム１００に属するサブボリューム１１０のうちから、リバランスポリシー管理テーブル３２０の「優先サブボリュームポリシー」の設定に従って、移行させるサブボリューム１１０を選択し、当該サブボリューム１１０を、リバランスポリシー管理テーブル３２０の「移行先ノード選択ポリシー」の設定に従って選択されるストレージノード１０（移行先ノード）に移行する。ステップＳ４１７の完了後は、ステップＳ４１８に進む。

そしてステップＳ４１８では、リバランス処理プログラム２４０は、容量が閾値を超過している他のストレージノード１０が存在しないかを判定し、該当する他のストレージノード１０が存在しない場合は（ステップＳ４１８のＹＥＳ）、容量リバランス処理を終了する。

一方、ステップＳ４１８において容量が閾値を超過している他のストレージノード１０が存在する場合は（ステップＳ４１８のＮＯ）、ステップＳ４１１に戻り、リバランス処理プログラム２４０は、上述した処理を繰り返す。但し、この繰り返しの処理においては、既に移行する対象のスライス１２０がないサブボリューム１１０やボリューム１００は、リバランスポリシーに従った選択の対象から除外し、リバランスポリシーで次に優先されるサブボリューム１１０やボリューム１００が選択されるものとする。

以上のように容量リバランス処理が実行されることにより、リバランス処理プログラム２４０は、容量が閾値を超過しているノードのデータを別ノードに移行して、容量の閾値超過を解消することができる。

なお、図６に示したリバランスポリシー管理テーブル３２０では、「スライス選択ポリシー」の設定として、「１．高負荷スライスを優先」と「２．低負荷スライスを優先」とが用意されていたが、何れが設定されるかは、ユーザによる指定またはシステムによる選択によって、任意に決定されてよい。具体的には、一般的な容量リバランス処理では、「２．低負荷スライスを優先」が設定されることが好ましい。但し、リバランス処理において、容量リバランス処理と後述する負荷リバランス処理と組み合わせて実行する場合には、「１．高負荷スライスを優先」が設定されることが好ましいこともある。

図１８は、負荷リバランス処理の処理手順例を示すフローチャートである。負荷リバランス処理は、図１６のステップＳ４０３に相当する処理であって、リバランス処理プログラム２４０が実行する処理の１つである。前述したように、負荷リバランス処理は、負荷のパラメタが閾値を超過した場合に、リバランス処理から呼び出される。

図１８によればまず、リバランス処理プログラム２４０は、負荷の閾値超過が起きているストレージノード１０を特定する（ステップＳ４２１）。具体的には、ステップＳ４２１においてリバランス処理プログラム２４０は、各ストレージノード１０においてＨＷモニタ情報管理テーブル４４０が備える各テーブルを参照し、閾値を超過しているストレージノード１０及びＨＷを特定する。

次に、リバランス処理プログラム２４０は、ステップＳ４２１で特定したストレージノード１０に属するボリューム１００のサブボリューム１１０のうちから、リバランスポリシー管理テーブル３２０の「優先サブボリュームポリシー（負荷）」の設定に従って、１つのサブボリューム１１０を選択する（ステップＳ４２２）。

なお、「優先サブボリュームポリシー（負荷）」の設定に従ってサブボリューム１１０の選択する際は、各サブボリュームの負荷状況を判断する必要があるが、これはサブボリュームモニタ情報管理テーブル４５１を参照することによって可能である。具体的には例えば、「優先サブボリュームポリシー（負荷）」の設定内容が「１．高負荷のサブボリュームを優先」であった場合は、サブボリュームモニタ情報管理テーブル４５１が管理する各サブボリューム１１０の情報を参照し、負荷が最も大きいサブボリューム１１０を選択すればよい。

次に、リバランス処理プログラム２４０は、ステップＳ４２２で選択したサブボリューム１１０が属するボリューム１００がスケーラブルボリュームであるか否かを判定する（ステップＳ４２３）。スケーラブルボリュームである場合は（ステップＳ４２３のＹＥＳ）、ステップＳ４２４に進み、スケーラブルボリュームではない、すなわちローカライズドボリュームである場合は（ステップＳ４２３のＮＯ）、ステップＳ４２６に進む。

ステップＳ４２２で選択したサブボリューム１１０が属するボリューム１００がスケーラブルボリュームである場合に実行されるステップＳ４２４では、リバランス処理プログラム２４０は、上記サブボリューム１１０に属するスライス１２０のうちから、リバランスポリシー管理テーブル３２０の「スライス選択ポリシー」の設定に従って、スライス１２０を選択する。

なお、「スライス選択ポリシー」の設定に従ってサブボリューム１１０の選択する際は、各スライスの負荷状況を判断する必要があるが、これはスライスモニタ情報管理テーブル４５２を参照することによって可能である。具体的には例えば、「スライス選択ポリシー」の設定内容が「１．高負荷スライスを優先」であった場合は、スライスモニタ情報管理テーブル４５２が管理する各スライス１２０の情報を参照し、負荷が最も大きいスライス１２０を選択すればよい。

次いで、リバランス処理プログラム２４０は、ステップＳ４２４で選択したスライス１２０を移行先ノードに移行する（ステップＳ４２５）。このとき、移行先のストレージノード１０は、リバランスポリシー管理テーブル３２０の「移行先ノード選択ポリシー」の設定に従って選択される。具体的には例えば、「移行先ノード選択ポリシー」の設定内容が「１．閾値超過したパラメタが最も小さいノードを優先」であり、ステップＳ４２１で特定したストレージノード１０におけるＣＰＵモニタ情報管理テーブル４４１が管理するＣＰＵ１１の負荷が閾値を超えている場合には、別のストレージノード１０のうちで最もＣＰＵ１１の負荷が小さいストレージノード１０が、移行先ノードとして選択される。ステップＳ４２５の処理後は、ステップＳ４２７に進む。

一方、ステップＳ４２２で選択したサブボリューム１１０が属するボリューム１００がローカライズドボリュームである場合に実行されるステップＳ４２６では、リバランス処理プログラム２４０は、上記サブボリューム１１０及び上記ボリューム１００を移行先ノードに移行する。このとき、移行先のストレージノード１０は、ステップＳ４２５と同様に、リバランスポリシー管理テーブル３２０の「移行先ノード選択ポリシー」の設定に従って選択される。ステップＳ４２６の処理後は、ステップＳ４２７に進む。

そしてステップＳ４２７では、リバランス処理プログラム２４０は、負荷が閾値を超過している他のストレージノード１０が存在しないかを判定し、該当する他のストレージノード１０が存在しない場合は（ステップＳ４２７のＹＥＳ）、負荷リバランス処理を終了する。

一方、ステップＳ４２７において負荷が閾値を超過している他のストレージノード１０が存在する場合は（ステップＳ４２７のＮＯ）、ステップＳ４２１に戻り、リバランス処理プログラム２４０は、上述した処理を繰り返す。但し、この繰り返しの処理においては、既に移行する対象のスライス１２０がないサブボリューム１１０やボリューム１００は、リバランスポリシーに従った選択の対象から除外し、リバランスポリシーで次に優先されるサブボリューム１１０やボリューム１００が選択されるものとする。

以上のように負荷リバランス処理が実行されることにより、リバランス処理プログラム２４０は、負荷が閾値を超過しているノードのデータを別ノードに移行して、負荷の閾値超過を解消することができる。

なお、図６に示したリバランスポリシー管理テーブル３２０では、「スライス選択ポリシー」の設定として、「１．高負荷スライスを優先」と「２．低負荷スライスを優先」とが用意されていたが、何れが設定されるかは、ユーザによる指定またはシステムによる選択によって、任意に決定されてよい。

具体的には、負荷リバランス処理において、「１．高負荷スライスを優先」が設定される場合には、高負荷のスライス１２０から優先して別ノードに移行できることから、移行の際にコスト（システム性能への負荷）は掛かるものの、閾値超過の状態を早期に分散させることができる。一方、負荷リバランス処理において、「２．低負荷スライスを優先」が設定される場合には、低負荷のスライス１２０から優先して別ノードに移行できることから、リバランス全体に要する移行時間は掛かるものの、移行時のシステム性能の低下を抑える効果に期待できる。すなわち、「スライス選択ポリシー」における上記２つの設定による効果はトレードオフの関係にあり、システムの運用スタイルやユーザの要望に応じて設定されることが好ましい。

（３－５）ノード増減設処理
図１９は、ノード増減設処理の処理手順例を示すフローチャートである。ノード増減設処理は、クラスタにノードを追加またはクラスタからノードを削除する処理であって、クラスタ管理プログラム２３０が実行する処理の１つである。

ノード増減設処理において、クラスタ管理プログラム２３０は、ノード（ストレージノード１０）の追加または削除に合わせて、スケーラブルボリュームの分散ノード数を再計算し、分散ノード数に変更が生じた場合は、スケーラブルボリュームのスライスの割り当てを、変更後の分散ノード数に合わせて変更する。

図１９によればまず、ストレージノード１０が、ノードの増設または減設を指示する増減設指示を受領する（ステップＳ５０１）。ノードの増減設指示は、クラスタの何れのノードで受信してもよく、指示を受信したノードは、クラスタ管理プログラム２３０を実行する構成管理のマスタノードに、受領した指示を転送する。

次に、マスタノードのクラスタ管理プログラム２３０が、後述するステップＳ５０４の分散ノード数変更処理による処理が行われていないスケーラブルボリュームを１つ選択する（ステップＳ５０２）。以降のステップＳ５０３及びステップＳ５０４の処理は、ステップＳ５０２で選択したスケーラブルボリュームについての処理となる。

次に、クラスタ管理プログラム２３０は、分散型ストレージシステム１においてクラスタを構成するノード数に合わせて、スケーラブルボリュームの分散ノード数を再計算する（ステップＳ５０３）。具体的には例えば、クラスタ管理プログラム２３０は、分散ノード数の最大値をボリューム１００に設定しておき、ノードを増設した場合には、ボリューム１００の分散ノード数が当該最大値に到達するまでは、クラスタを構成するノード数と同じ値となるように分散ノード数を決定する。また、ノードを減設した場合には、減設後のノード数と同じ値となるように分散ノード数を決定する。

次に、クラスタ管理プログラム２３０は、ステップＳ５０２で選択したスケーラブルボリュームについてステップＳ５０３で再計算した分散ノード数が再計算前の分散ノード数とは異なる場合に、当該スケーラブルボリュームのスライス１２０の割り当てを、再計算した分散ノード数に合わせて変更する（ステップＳ５０４）。以下では、ステップＳ５０４の処理を「分散ノード数変更処理」と称し、その詳細な処理手順は、図２０を参照しながら後述する。

そして、ステップＳ５０４の処理後、クラスタ管理プログラム２３０は、クラスタ内の全てのスケーラブルボリュームに対して分散ノード数変更処理を完了したか否かを判定する（ステップＳ５０５）。未処理のスケーラブルボリュームが存在する場合には（ステップＳ３０５のＮＯ）、ステップＳ５０２に戻り、処理を繰り返す。一方、未処理のスケーラブルボリュームが存在しない場合は（ステップＳ３０５のＹＥＳ）、ノード増減設処理を終了する。

図２０は、分散ノード数変更処理の処理手順例を示すフローチャートである。前述したように、図２０に示す分散ノード数変更処理は、図１９のステップＳ５０４の処理に相当し、クラスタ管理プログラム２３０によって実行される。なお、図２０に示す分散ノード数変更処理は、後述する図２１のボリュームサイズ変更処理のなかでも呼び出されて実行される。

図２０に示したように、クラスタ管理プログラム２３０は、まず、図１９のステップＳ５０３で再計算した分散ノード数と、再計算前の分散ノード数とを比較し、同値でないか否かを判定する（ステップＳ５１１）。

なお、ステップＳ５１１の時点では、再計算した分散ノード数は、新たな分散ノード数として更新されていないが、説明の便宜上、図２０及びその説明では、再計算した分散ノード数を「変更後」の分散ノード数、再計算前の分散ノード数を「変更前」の分散ノード数と表記することがある。すなわち、ステップＳ５１１では、クラスタ管理プログラム２３０は、変更前と変更後の分散ノード数が同値でないか否かを判定する。

ステップＳ５１１において変更後の分散ノード数が変更前の分散ノード数と同値ではない場合は（ステップＳ５１１のＹＥＳ）、ステップＳ５１２に進む。一方、変更後の分散ノード数が変更前の分散ノード数と同値、すなわち、再計算によって分散ノード数に変化がない場合は（ステップＳ５１１のＮＯ）、スライス１２０の割り当てを変更する必要がないので、分散ノード数変更処理を終了する。

ステップＳ５１２では、クラスタ管理プログラム２３０は、現在処理対象としているスケーラブルボリューム（図１９のステップＳ５０２で選択したスケーラブルボリューム）について、ボリューム管理テーブル４２１の分散ノード数４２１４フィールドの値を、図１９のステップＳ５０３で再計算した分散ノード数で更新する。

次に、クラスタ管理プログラム２３０は、変更後の分散ノード数が変更前の分散ノード数よりも大きいか否かを判定する（ステップＳ５１３）。

ステップＳ５１３において変更後の分散ノード数が変更前の分散ノード数よりも大きい場合（ステップＳ５１３のＹＥＳ）、クラスタ管理プログラム２３０は、以下のステップＳ５１４～Ｓ５１７の処理を行うことにより、処理対象のスケーラブルボリュームのスライス１２０の一部を新たな分散先ノードに移動し、ボリューム１００をスケールアウトする。

まずステップＳ５１４において、クラスタ管理プログラム２３０は、ボリューム領域の分散をスケールアウトするため、新たな分散先となるノードを選択する。新たな分散先のノードは、各ノードの空き容量や負荷状況を加味して選択される。例えば、空き容量が多く、かつ負荷が低いノードが選択される。

次いでステップＳ５１５において、クラスタ管理プログラム２３０は、ステップＳ５１４で選択した新たな分散先ノードに、サブボリューム１１０を作成する。

次いでステップＳ５１６において、クラスタ管理プログラム２３０は、既存のサブボリューム１１０のうちから、ステップＳ５１５で作成したサブボリューム１１０に移動するスライス１２０を選択する。新たなサブボリューム１１０に移動するスライス１２０は、既存の各サブボリューム１１０から均等な数となるように選択されることが好ましい。

そしてステップＳ５１７において、クラスタ管理プログラム２３０は、既存のサブボリューム１１０からステップＳ５１５で作成したサブボリューム１１０へ、ステップＳ５１６で選択したスライス１２０を移動することにより、ボリューム１００をスケールアウトすることができる。

一方、ステップＳ５１３において変更後の分散ノード数が変更前の分散ノード数以下の場合には（ステップＳ５１３のＮＯ）、クラスタ管理プログラム２３０は、以下のステップＳ５１８～Ｓ５２０の処理を行うことにより、処理対象のスケーラブルボリュームに属するサブボリューム１１０のうちから１つのサブボリューム１１０を選択し、当該サブボリューム１１０のスライス１２０を全て既存の分散先ノードに移動し、ボリューム１００をスケールインする。

まずステップＳ５１８において、クラスタ管理プログラム２３０は、ボリューム領域の分散をスケールインするため、サブボリューム１１０の分散先から除外するノード（除外ノード）を選択する。除外ノードは、各ノードの空き容量や負荷状況を加味して選択される。例えば、空き容量が少なく、かつ負荷が高いノードが選択される。

次いでステップＳ５１９において、クラスタ管理プログラム２３０は、ステップＳ５１８で選択した除外ノードのサブボリューム１１０から、残りの分散先ノードにスライス１２０を移動する。このとき、クラスタ管理プログラム２３０は、移動後に、残りの分散先ノードの各サブボリューム１１０に均等な数が割り当たるように、スライス１２０の移動先を選択することが好ましい。

そしてステップＳ５２０において、クラスタ管理プログラム２３０は、ステップＳ５１８で選択した除外ノードにおけるサブボリューム１１０を削除することにより、ボリューム１００をスケールインすることができる。

最後に、上記したステップＳ５１７またはステップＳ５２０の完了した後、クラスタ管理プログラム２３０は、スケールアウト（ステップＳ５１４～Ｓ５１７）またはスケールイン（ステップＳ５１８～Ｓ５２０）の処理によって変更があったボリューム１００、サブボリューム１１０、及びスライス１２０の情報を、データ領域管理テーブル４２０が備える各テーブルに反映して更新し（ステップＳ５２１）、分散ノード数変更処理を終了する。

以上、図１９及び図２０に示した処理が実行されることにより、クラスタ管理プログラム２３０は、分散型ストレージシステム１における計算機ノード（ストレージノード１０）の増設または減設時に、各計算機ノードにおけるサブボリューム１１０の数を１に固定したまま、計算機ノードの設置数に応じて柔軟に、ボリューム１００をスケールアウトまたはスケールインすることができる。

（３－６）ボリュームサイズ変更処理
図２１は、ボリュームサイズ変更処理の処理手順例を示すフローチャートである。ボリュームサイズ変更処理は、指定されたボリューム１００のサイズを変更（拡張または収縮）する処理であって、主にボリューム管理プログラム２２０が実行する。なお、ステップＳ６０９の処理はクラスタ管理プログラム２３０が実行される。

ボリュームサイズ変更処理において、ボリューム管理プログラム２２０は、ボリューム１００のサイズ変更に合わせてスケーラブルボリュームの分散ノード数を再計算し、分散ノード数に変更があった場合は、スケーラブルボリュームのスライス１２０の割り当てを再計算した分散ノード数に合わせて変更する。

図２１によればまず、ボリューム管理プログラム２２０は、ボリューム１００のサイズ変更指示を受領する。ボリューム１００のサイズ変更指示は、クラスタの何れのノードで受信してもよく、指示を受信したノードは、ボリューム管理プログラム２２０を実行する構成管理のマスタノードに、受領した指示を転送する。

次に、マスタノードのボリューム管理プログラム２２０は、ステップＳ６０１で受領したサイズ変更指示においてボリュームサイズが変更前と変更後とで変化しているか否かを判定する（ステップＳ６０２）。ボリュームサイズの変更がない場合は（ステップＳ６０２のＮＯ）、特段の処理が必要ないため、ボリュームサイズ変更処理を終了する。ボリュームサイズに変更がある場合は（ステップＳ６０２のＹＥＳ）、ステップＳ６０３に進む。

ステップＳ６０３では、ボリューム管理プログラム２２０は、サイズ変更指示において変更後のボリュームサイズが変更前よりも大きいか否かを判定する。ボリュームサイズが大きくなる場合は（ステップＳ６０３のＹＥＳ）、ステップＳ６０４～Ｓ６０５の処理を行うことにより、ボリュームサイズを拡張する。一方、ボリュームサイズが小さくなる場合は（ステップＳ６０３のＮＯ）、ステップＳ６０６～Ｓ６０７の処理を行うことにより、ボリュームサイズの収縮を行う。

ステップＳ６０４では、ボリューム管理プログラム２２０は、サイズ変更指示の対象とされたスケーラブルボリュームの各サブボリューム１１０のサイズを拡張する。このとき例えば、各サブボリューム１１０の合計サイズが拡張後のスケーラブルボリュームと同じサイズになるように拡張する。

次のステップＳ６０５では、ボリューム管理プログラム２２０は、ステップＳ６０４で拡張したサブボリューム１１０に対して、拡張したサイズ分だけ新規のスライス１２０を割り当てる。ステップＳ６０５において、ボリューム管理プログラム２２０は、例えば、各サブボリューム１１０に均等な数が割り当るように、割り当てるスライス１２０の数を決定する。具体的には、スライス１２０の割り当て数は、スケーラブルボリュームの拡張サイズを分散ノード数で割ることによって算出できる。ステップＳ６０５の処理後は、ステップＳ６０８に進む。

ステップＳ６０６では、ボリューム管理プログラム２２０は、ボリューム１００のアドレス末尾から、収縮するサイズ分だけスライス１２０を削除する。

次のステップＳ６０７では、ボリューム管理プログラム２２０は、サイズ変更指示の対象とされたスケーラブルボリュームの各サブボリューム１１０のサイズを収縮する。このとき例えば、各サブボリューム１１０の合計サイズが収縮後のスケーラブルボリュームと同じサイズになるように収縮する。ステップＳ６０７の処理後は、ステップＳ６０８に進む。

ステップＳ６０８では、ボリューム管理プログラム２２０は、サイズ変更指示の対象とされたスケーラブルボリュームについて、変更後のボリュームサイズに合わせて分散ノード数を再計算する。例えば、ボリューム１００のサイズ拡張の結果、サブボリューム１１０に割り当てたスライス１２０の合計サイズが、１つのノード単位でサブボリューム１１０に提供可能な容量を超えた場合には、分散ノード数を増やすことで、容量の枯渇が発生しないようにする。また例えば、ボリューム１００のサイズ収縮の結果、サブボリューム１１０から削除したスライス１２０の合計サイズが、１つのノード単位でサブボリューム１１０に提供可能な容量を超えた場合には、分散ノード数を減らすことで、過剰なノード分散を抑制する。

その後、ボリューム管理プログラム２２０は、クラスタ管理プログラム２３０を呼び出し、ステップＳ６０８で再計算した分散ノード数を用いて、前述した分散ノード数変更処理（図２０参照）を実行させることにより、再計算後の分散ノード数に応じたスライス１２０の割り当てを実行する（ステップＳ６０９）。そしてステップＳ６０９の完了後、ボリュームサイズ変更処理を終了する。

以上、図２１に示した処理が実行されることにより、ボリューム管理プログラム２２０及びクラスタ管理プログラム２３０は、ボリューム１００のサイズ変更指示に応じて、スケーラブルボリューム（ボリューム１００）の拡張または収縮を行うとともに、拡張または収縮に伴う構成変更に合わせて分散ノード数を再計算し、再計算後の分散ノード数に応じてスライス１２０の移動を行うことにより、ボリューム１００を形成するノード間で容量及び／または負荷が分散するようにスライス１２０を配置することができる。

以上に説明したように、本実施形態に係る分散型ストレージシステム１は、ボリューム１００を構成するサブボリューム１１０の領域を複数のスライス１２０に分割し、スライス単位で複数の計算機ノード（ストレージノード１０）に割り当て、ボリューム１００へのアクセス負荷をモニタリングし、モニタ情報（ＨＷモニタ情報管理テーブル４４０、データ領域モニタ情報管理テーブル４５０）を管理する。また、ボリューム１００を構成するサブボリューム１１０は、１つの計算機ノード当たりに１つとすることにより、各計算機ノード上で動作するストレージ制御ソフトウェア（ストレージ制御プログラム２００）による管理性能の低下を防ぐことができる。詳しく説明すると、各ストレージノード１０において、当該ストレージノード１０上で動作するストレージ制御プログラム２００が管理するサブボリューム１１０の個数が一定（この場合は１）とされることにより、１つの計算機ノードにおけるサブボリューム１１０の個数が増加することによってその制御情報が増大し、ストレージ制御プログラム２００の処理量が増大してしまう、という管理性能の低下を防ぐことができる。さらに、ボリューム１００を構成するサブボリューム１１０のサイズをボリューム１００と同じサイズとすることにより、１つの計算機ノードにおけるサブボリューム１１０のサイズが増加した場合にストレージノード１０間でデータを柔軟に融通することが困難になるといった問題を解消し、柔軟なスケールアウト処理の実現に貢献する。そして、本実施形態に係る分散型ストレージシステム１は、上位モニタ情報において、アクセス負荷が低く、１つの計算機ノードでボリューム１００が要求する性能を提供できる場合には、ボリューム１００を構成するスライス１２０を１つの計算機ノードに集約するように割り当てを制御する（ローカライズドボリューム）。一方、アクセス負荷が高く、１つの計算機ノードでボリューム１００が要求する性能を提供できない場合には、ボリューム１００を構成するスライス１２０を複数の計算機ノードに分散して割り当てるように制御する（スケーラブルボリューム）。また、ホスト（ホストコンピュータ３０）がボリューム１００のデータにアクセスする際は、各計算機ノードがアクセス先のデータを格納するスライス１２０がどの計算機ノードに割り当てられているかを判定することで、アクセス時の負荷が特定の計算機ノードに偏らないようにする。

本実施形態に係る分散型ストレージシステム１は、上記のように構成されることで、アクセス負荷が１つの計算機ノードで充足する場合は、必ずローカルストレージ（ドライブ１５）のデータに対してアクセスできるため、ホストに対して高速に応答することができる。また、アクセス負荷が１つの計算機ノードでは充足しない場合には、複数の計算機ノードでアクセスを処理することで、ホストに対して高いスループット（ＩＯＰＳ：Input/Output Per Second）を提供することができる。また、これらの制御は、ユーザが意識することなく分散型ストレージシステム１が自動で行うため、ユーザは、例えば特許文献１に開示されたストレージシステムと同様の運用負荷で上記の利益を得ることができる。

また、本実施形態に係る分散型ストレージシステム１は、何れかの計算機ノード（ストレージノード１０）においてボリューム１００の容量または負荷に関する所定パラメタが閾値を超えた場合には、容量または負荷の観点に基づくリバランス処理を実行することにより、パラメタが閾値超過したノードのボリュームデータを別ノードに移行して、閾値の超過状態を解消することができる。すなわち、１または複数のノードに跨って形成される１つのボリュームに対して、アクセス負荷に応じて、応答時間及びスループットを自動で好適な状態に変更することができる。

また、本実施形態に係る分散型ストレージシステム１では、計算機ノードの増設または減設が行われる際には、ノード増減設処理を実行することにより、ノード数の変化に応じてボリューム１００の分散ノード数を再計算し、分散先の各ノードのサブボリューム１１０に対して、偏りが生じないようにスライス１２０を割り当てる。かくして、分散型ストレージシステム１は、計算機ノードの追加（または削除）に応じて、ボリュームの容量及び／または性能をスケールアウト（またはスケールイン）することができる。

また、本実施形態に係る分散型ストレージシステムで１は、ボリューム１００のサイズを変更する際に、ボリュームサイズ変更処理を実行することで、変更されるサイズに応じて、ボリューム１００におけるサブボリューム１１０の構成、及びスライス１２０の割り当てを自動的に調整することができる。かくして、ボリューム１００のサイズ変更に応じて、ノード間で容量及び／または負荷を好適に分散させてボリューム１００を形成することができる。

なお、本発明は上記した実施形態に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、実施形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、または、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。

また、図面において制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際にはほとんど全ての構成が相互に接続されていると考えてもよい。

１ 分散型ストレージシステム
１０（１０Ａ～１０Ｄ） ストレージノード
１１ ＣＰＵ
１２ メモリ
１３ ネットワークインタフェース
１４ ドライブインタフェース
１５ ドライブ
１６ 内部ネットワーク
２０（２０Ａ，２０Ｂ） ネットワーク
２１ ハイパーバイザ
２２（２２Ａ，２２Ｂ） ゲストＯＳ
２３ ストレージ制御ソフト
２４ 管理ソフト
３０（３０Ａ，３０Ｂ） ホストコンピュータ
１００（１００Ａ，１００Ｂ） ボリューム
１１０（１１０Ａ～１１０Ｄ） サブボリューム
１２０ スライス
１３０ ページ
２００ ストレージ制御プログラム
２１０ リードライト処理プログラム
２２０ ボリューム管理プログラム
２３０ クラスタ管理プログラム
２４０ リバランス処理プログラム
３００ クラスタ内制御情報テーブル
３１０ クラスタ構成管理テーブル
３１１ サイト構成管理テーブル
３１２ ノード構成管理テーブル
３１３ ドライブ構成管理テーブル
３１４ ＣＰＵ構成管理テーブル
３２０ リバランスポリシー管理テーブル
３３０ クラスタプール管理テーブル
４００ ノード内制御情報テーブル
４１０ ノードプール管理テーブル
４２０ データ領域管理テーブル
４２１ ボリューム管理テーブル
４２２ サブボリューム管理テーブル
４２３ スライス管理テーブル
４２４ ページ管理テーブル
４３０ ホストパス管理テーブル
４４０ ＨＷモニタ情報管理テーブル
４４１ ＣＰＵモニタ情報管理テーブル
４４２ ドライブモニタ情報管理テーブル
４４３ ネットワークモニタ情報管理テーブル
４４４ ホストパスモニタ情報管理テーブル
４５０ データ領域モニタ情報管理テーブル
４５１ サブボリュームモニタ情報管理テーブル
４５２ スライスモニタ情報管理テーブル

Claims (11)

1. プロセッサを有する複数の計算機ノードと、記憶ドライブと、を有して、ボリュームを提供する分散型ストレージシステムであって、
   前記複数の計算機ノードは、各々がサブボリュームを提供して、そのプロセッサは自計算機ノードのサブボリュームごとに設定を管理し、
   前記ボリュームは、前記複数の計算機ノードが提供する複数のサブボリュームを用いて構成可能であり、
   前記サブボリュームは、前記記憶ドライブの物理記憶領域を割り当てて形成される複数の論理記憶領域を含んでおり、
   前記複数の計算機ノードは、同じ前記ボリュームに属し異なる計算機ノードが提供する前記サブボリューム間で、前記論理記憶領域を移動させることが可能であり、
   前記複数の計算機ノードの少なくとも何れかの前記プロセッサは、前記ボリュームを形成する前記計算機ノードの増設時、及び前記ボリューム内のリバランスの実行時に、当該ボリュームに含まれる論理記憶領域を、前記サブボリューム間で移行し、
   前記複数の計算機ノードの少なくとも何れかの前記プロセッサは、前記ボリュームに含まれる論理記憶領域を前記サブボリューム間で移行する際、データ容量の観点に基づいて前記論理記憶領域を移行する第１のリバランス処理、またはデータ入出力処理負荷の観点に基づいて前記論理記憶領域を移行する第２のリバランス処理を実行し、
   前記第２のリバランス処理において、前記プロセッサは、サブボリュームの負荷情報に基づいて対象のサブボリュームを選択し、選択したサブボリューム内の前記論理記憶領域の負荷情報に基づいて移動させる論理記憶領域を選択する
   ことを特徴とする分散型ストレージシステム。
2. 前記ボリュームは、１つの前記計算機ノードにつき１つの前記サブボリュームに割り当てられ、各前記サブボリュームは、前記ボリュームにかかるすべての論理記憶領域を含有できるサイズを有して構成される
   ことを特徴とする請求項１に記載の分散型ストレージシステム。
3. 前記複数の計算機ノードの少なくとも何れかの前記プロセッサは、
   前記ボリュームのサイズ拡張またはサイズ縮小時に、当該ボリュームに含まれる論理記憶領域を前記サブボリューム間で移行する
   ことを特徴とする請求項１に記載の分散型ストレージシステム。
4. 前記複数の計算機ノードの少なくとも何れかの前記プロセッサは、
   前記ボリュームの作成時に、当該ボリュームに含まれる論理記憶領域を、前記サブボリュームにマッピングする
   ことを特徴とする請求項１に記載の分散型ストレージシステム。
5. 前記ボリュームは、前記論理記憶領域の全てが１の前記サブボリュームにマッピングされる形態、及び、前記論理記憶領域が複数の前記サブボリュームに分散してマッピングされる形態、を構成できる
   ことを特徴とする請求項１に記載の分散型ストレージシステム。
6. 前記プロセッサは、
   前記論理記憶領域が管理されるデータ領域に対してデータの書き込みが発生した場合に、当該論理記憶領域が割り当てられた前記サブボリュームを有する前記計算機ノードにおける前記記憶ドライブの物理記憶領域を、細分化した所定単位で、当該論理記憶領域に割り当てる
   ことを特徴とする請求項１に記載の分散型ストレージシステム。
7. 前記第１のリバランス処理において、前記プロセッサは、
   前記記憶ドライブの物理記憶領域が未割り当ての前記論理記憶領域を、当該論理記憶領域の割り当てに関する制御情報を更新することによって、前記サブボリューム間で移行する
   ことを特徴とする請求項１に記載の分散型ストレージシステム。
8. 前記第１のリバランス処理において、前記プロセッサは、
   前記記憶ドライブの物理記憶領域が未割り当ての前記論理記憶領域を前記サブボリューム間で移行した後に、前記記憶ドライブの物理記憶領域を割り当て済みの前記論理記憶領域を前記サブボリューム間で移行する
   ことを特徴とする請求項７に記載の分散型ストレージシステム。
9. プロセッサを有する複数の計算機ノードと、記憶ドライブと、を有して、ボリュームを提供する分散型ストレージシステムであって、
   前記複数の計算機ノードは、各々がサブボリュームを提供して、そのプロセッサは自計算機ノードのサブボリュームごとに設定を管理し、
   前記ボリュームは、前記複数の計算機ノードが提供する複数のサブボリュームを用いて構成可能であり、
   前記サブボリュームは、前記記憶ドライブの物理記憶領域を割り当てて形成される複数の論理記憶領域を含んでおり、
   前記複数の計算機ノードは、同じ前記ボリュームに属し異なる計算機ノードが提供する前記サブボリューム間で、前記論理記憶領域を移動させることが可能であり、
   前記複数の計算機ノードの少なくとも何れかの前記プロセッサは、前記ボリュームを形成する前記計算機ノードの増設時、及び前記ボリューム内のリバランスの実行時に、当該ボリュームに含まれる論理記憶領域を、前記サブボリューム間で移行し、
   前記複数の計算機ノードの少なくとも何れかの前記プロセッサは、前記ボリュームに含まれる論理記憶領域を前記サブボリューム間で移行する際、データ容量の観点に基づいて前記論理記憶領域を移行する第１のリバランス処理、またはデータ入出力処理負荷の観点に基づいて前記論理記憶領域を移行する第２のリバランス処理を実行し、
   前記第１のリバランス処理において、前記プロセッサは、前記記憶ドライブの物理記憶領域が未割り当ての前記論理記憶領域を、当該論理記憶領域の割り当てに関する制御情報を更新することによって、前記サブボリューム間で移行する
   ことを特徴とする分散型ストレージシステム。
10. プロセッサを有する複数の計算機ノードと記憶ドライブとを有して、ボリュームを提供する分散型ストレージシステムによるボリューム管理方法であって、
    前記複数の計算機ノードは、各々がサブボリュームを提供して、そのプロセッサは自計算機ノードのサブボリュームごとに設定を管理し、
    前記ボリュームは、前記複数の計算機ノードが提供する複数のサブボリュームを用いて構成可能であり、
    前記サブボリュームは、前記記憶ドライブの物理記憶領域を割り当てて形成される複数の論理記憶領域を含んでおり、
    前記複数の計算機ノードが、同じ前記ボリュームに属し異なる計算機ノードが提供する前記サブボリューム間で、前記論理記憶領域を移動させることが可能であり、
    前記複数の計算機ノードの少なくとも何れかの前記プロセッサは、前記ボリュームを形成する前記計算機ノードの増設時、及び前記ボリューム内のリバランスの実行時に、当該ボリュームに含まれる論理記憶領域を、前記サブボリューム間で移行し、
    前記複数の計算機ノードの少なくとも何れかの前記プロセッサは、前記ボリュームに含まれる論理記憶領域を前記サブボリューム間で移行する際、データ容量の観点に基づいて前記論理記憶領域を移行する第１のリバランス処理、またはデータ入出力処理負荷の観点に基づいて前記論理記憶領域を移行する第２のリバランス処理を実行し、
    前記第２のリバランス処理において、前記プロセッサは、サブボリュームの負荷情報に基づいて対象のサブボリュームを選択し、選択したサブボリューム内の前記論理記憶領域の負荷情報に基づいて移動させる論理記憶領域を選択する
    ことを特徴とするボリューム管理方法。
11. プロセッサを有する複数の計算機ノードと記憶ドライブとを有して、ボリュームを提供する分散型ストレージシステムによるボリューム管理方法であって、
    前記複数の計算機ノードは、各々がサブボリュームを提供して、そのプロセッサは自計算機ノードのサブボリュームごとに設定を管理し、
    前記ボリュームは、前記複数の計算機ノードが提供する複数のサブボリュームを用いて構成可能であり、
    前記サブボリュームは、前記記憶ドライブの物理記憶領域を割り当てて形成される複数の論理記憶領域を含んでおり、
    前記複数の計算機ノードが、同じ前記ボリュームに属し異なる計算機ノードが提供する前記サブボリューム間で、前記論理記憶領域を移動させることが可能であり、
    前記複数の計算機ノードの少なくとも何れかの前記プロセッサは、前記ボリュームを形成する前記計算機ノードの増設時、及び前記ボリューム内のリバランスの実行時に、当該ボリュームに含まれる論理記憶領域を、前記サブボリューム間で移行し、
    前記複数の計算機ノードの少なくとも何れかの前記プロセッサは、前記ボリュームに含まれる論理記憶領域を前記サブボリューム間で移行する際、データ容量の観点に基づいて前記論理記憶領域を移行する第１のリバランス処理、またはデータ入出力処理負荷の観点に基づいて前記論理記憶領域を移行する第２のリバランス処理を実行し、
    前記第１のリバランス処理において、前記プロセッサは、前記記憶ドライブの物理記憶領域が未割り当ての前記論理記憶領域を、当該論理記憶領域の割り当てに関する制御情報を更新することによって、前記サブボリューム間で移行する
    ことを特徴とするボリューム管理方法。

Images