JP7167078B2 - 分散ストレージシステム及び記憶制御方法 - Google Patents

Description

本発明は、概して、分散ストレージシステムの記憶制御に関する。

近年、汎用サーバでストレージシステムを構築するＳｏｆｔｗａｒｅ－Ｄｅｆｉｎｅｄ Ｓｔｏｒａｇｅ（ＳＤＳ）が主流となってきている。またＳＤＳの一形態として、汎用サーバ上にアプリケーションとストレージ制御ソフトとを同梱するＨｙｐｅｒ Ｃｏｎｖｅｒｇｅｄ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ（ＨＣＩ）が広く認知されるようになってきている。以下、ＳＤＳの一形態としてＨＣＩが採用されているストレージシステムを、「ＳＤＳ／ＨＣＩシステム」と言う。

一方、データ読み出しが高速なフラッシュデバイスを有効活用する技術として、ネットワーク経由で高速にデータ通信を行うプロトコルであるＮｏｎ Ｖｏｌａｔｉｌｅ Ｍｅｍｏｒｙ Ｅｘｐｒｅｓｓ ｏｖｅｒ Ｆａｂｒｉｃ（ＮＶＭｅ－ｏＦ）技術が広がりつつある。当該プロトコルを使うことで、ネットワークを介したフラッシュデバイスでも高速にデータ通信を行うことが可能になる。このような背景から、ネットワーク上にフラッシュデバイスを集約することを目的としたＦａｂｒｉｃ－ａｔｔａｃｈｅｄ Ｂｕｎｃｈ ｏｆ Ｆｌａｓｈ（ＦＢＯＦ）というドライブボックス型製品も市場に現れつつある。

ＳＤＳ／ＨＣＩシステムでは、サーバ障害時のデータロストを防止するため、複数サーバが協力して冗長データを作成し、各サーバに搭載されたＤｉｒｅｃｔ－ａｔｔａｃｈｅｄ Ｓｔｏｒａｇｅ（ＤＡＳ）に冗長データを格納することでデータ保護を行う。データ保護方法には、ストレージシステムで長らく利用されてきたＲｅｄｕｎｄａｎｔ Ａｒｒａｙ ｏｆ Ｉｎｄｅｐｅｎｄｅｎｔ （ｏｒ Ｉｎｅｘｐｅｎｓｉｖｅ） Ｄｉｓｋｓ（ＲＡＩＤ）だけではなくＥｒａｓｕｒｅ Ｃｏｄｉｎｇ（ＥＣ）も用いられる。特許文献１では、データ書き込み時に別サーバにネットワーク転送されるデータ量を小さくするＥＣ方法が開示されている。また、特許文献１では、ドライブ障害時に効率よくデータ復旧する目的で、同一サーバ内のＤＡＳ間で行うデータ保護と、複数サーバのＤＡＳ間で行うデータ保護とを併用する技術が開示されている。

ＳＤＳ／ＨＣＩシステムでは、サーバ障害時に、障害サーバのデータを別サーバに復旧してアクセス可能にする技術が一般的である。特許文献２では、サーバ障害の他、サーバのボトルネックの解消などを目的とし、アプリと当該アプリが利用するデータとを、データコピーによって別サーバに移動する技術が開示されている。

WO2016/052665 WO2018/29820

一般的な分散ストレージシステムでは、ストレージ性能資源（例えば、Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ（ＣＰＵ））と、ストレージ容量資源（例えば、ドライブ）とが同一サーバに同梱されているため、ストレージ性能とストレージ容量とを独立にスケールすることができない。このため、性能要件及び容量要件によっては、ストレージ性能資源又はストレージ容量資源を余分に搭載しなければならず、資源が無駄に必要となり、結果として、システムコスト増につながる。また、負荷分散等を目的として、サーバ間でアプリを移動する場合に、アプリが利用するデータも移動する必要があり、ネットワークの負荷が高くなり、サーバ間のアプリ移動に時間がかかる。

分散ストレージシステムが、複数の物理記憶デバイスを含んだ１つ又は複数のストレージユニットと、当該１つ又は複数のストレージユニットに通信ネットワークを介して接続された複数の計算機とで構成される。複数の計算機のうちの２つ以上の計算機の各々が、それぞれ、ストレージ制御プログラムを実行する。２つ以上のストレージ制御プログラムが、複数の物理記憶デバイスが提供する複数の記憶領域および当該複数の記憶領域に関するメタデータを共有する。２つ以上のストレージ制御プログラムの各々は、当該ストレージ制御プログラムが提供する論理ユニットにおけるライト先領域を指定したライト要求を、当該論理ユニットを認識するアプリケーションから受け、当該ライト要求に付随するデータを、メタデータを基に冗長化し、当該冗長化されたデータである１つ以上の冗長化データセットを、当該ライト先領域の基になっている２つ以上の物理記憶デバイスが提供する１つ以上の記憶領域（例えば、後述の１つ以上の冗長構成領域）に書き込む。ストレージ制御プログラムに障害が発生した場合、メタデータを共有する他のストレージ制御プログラムが、記憶領域に格納されたデータにアクセスする。物理記憶デバイスに障害が発生した場合、障害の発生していない他の物理記憶デバイスに記憶された冗長化させたデータを用いて、ストレージ制御プログラムが、当該障害の発生した物理記憶デバイスのデータを復元する。

本発明によると、分散ストレージシステムにおいて、計算機間のデータ転送無しにデータを冗長化すること、言い換えれば、ネットワーク効率よくデータ保護を行うことができる。

本発明の一実施形態における分散ストレージシステムの概要を示す図である。 一比較例における分散ストレージシステムの概要を示す図である。 本発明の一実施形態におけるドライブ障害修復の概要を示す図である。 本発明の一実施形態におけるサーバ障害修復の概要を示す図である。 本発明の一実施形態におけるサーバ、管理サーバ及びドライブボックスのハード構成例を示す図である。 本発明の一実施形態における分散ストレージシステムの区分の一例を示す図である。 本発明の一実施形態におけるドメイングループ管理テーブルの構成例を示す図である。 本発明の一実施形態におけるドライブ領域管理の一例を示す図である。 本発明の一実施形態におけるチャンクグループ管理テーブルの構成例を示すである。 本発明の一実施形態におけるページマッピングテーブルの構成例を示す図である。 本発明の一実施形態における空きページ管理テーブルの構成例を示す図である。 本発明の一実施形態におけるテーブル配置の一例を示す図である。 本発明の一実施形態におけるリード処理の流れの一例を示す図である。 本発明の一実施形態におけるライト処理の流れの一例を示す図である。 本発明の一実施形態におけるドライブ増設処理の流れの一例を示す図である。 本発明の一実施形態におけるドライブ障害修復処理の流れの一例を示す図である。 本発明の一実施形態におけるサーバ障害修復処理の流れの一例を示す図である。 本発明の一実施形態におけるサーバ増設処理の流れの一例を示す図である。 本発明の一実施形態におけるオーナーサーバ移動処理の流れの一例を示す図である。

以下の説明では、「通信インターフェース装置」は、１つ以上の通信インターフェースデバイスでよい。１つ以上の通信インターフェースデバイスは、１つ以上の同種の通信インターフェースデバイス（例えば１つ以上のＮｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄｓ（ＮＩＣｓ））であってもよいし２つ以上の異種の通信インターフェースデバイス（例えばＮＩＣとＨｏｓｔ Ｂｕｓ Ａｄａｐｔｅｒ（ＨＢＡ））であってもよい。

また、以下の説明では、「メモリ」は、１つ以上の記憶デバイスの一例である１つ以上のメモリデバイスであり、典型的には主記憶デバイスでよい。メモリにおける少なくとも１つのメモリデバイスは、揮発性メモリデバイスであってもよいし不揮発性メモリデバイスであってもよい。

また、以下の説明では、「ストレージユニット」は、１つ以上の物理記憶デバイスを含んだユニットの一例である。物理記憶デバイスは、永続記憶デバイスでよい。永続記憶デバイスは、典型的には、不揮発性の記憶デバイス（例えば補助記憶デバイス）でよく、具体的には、例えば、Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ（ＨＤＤ）、Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ（ＳＳＤ）、Ｎｏｎ－Ｖｏｌａｔｉｌｅ Ｍｅｍｏｒｙ Ｅｘｐｒｅｓｓ（ＮＶＭｅ）ドライブ、又は、Ｓｔｏｒａｇｅ Ｃｌａｓｓ Ｍｅｍｏｒｙ（ＳＣＭ）でよい。以下の説明では、「ドライブボックス」が、ストレージユニットの一例であり、「ドライブ」が、物理記憶デバイスの一例である。

また、以下の説明では、「プロセッサ」は、１つ以上のプロセッサデバイスでよい。少なくとも１つのプロセッサデバイスは、典型的には、Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ（ＣＰＵ）のようなマイクロプロセッサデバイスでよいが、Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ（ＧＰＵ）のような他種のプロセッサデバイスでもよい。少なくとも１つのプロセッサデバイスは、シングルコアでもよいしマルチコアでもよい。少なくとも１つのプロセッサデバイスは、プロセッサコアでもよい。少なくとも１つのプロセッサデバイスは、処理の一部又は全部を行うハードウェア記述言語によりゲートアレイの集合体である回路（例えば、Ｆｉｅｌｄ－Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ（ＦＰＧＡ）、Ｃｏｍｐｌｅｘ Ｐｒｏｇｒａｍｍａｂｌｅ Ｌｏｇｉｃ Ｄｅｖｉｃｅ（ＣＰＬＤ）、又は、Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ（ＡＳＩＣ））といった広義のプロセッサデバイスでもよい。

また、以下の説明では、「ｘｘｘテーブル」といった表現にて、入力に対して出力が得られる情報を説明することがあるが、当該情報は、どのような構造のデータでもよいし（例えば、構造化データでもよいし非構造化データでもよいし）、入力に対する出力を発生するニューラルネットワーク、遺伝的アルゴリズムやランダムフォレストに代表されるような学習モデルでもよい。従って、「ｘｘｘテーブル」を「ｘｘｘ情報」と言うことができる。また、以下の説明において、各テーブルの構成は一例であり、１つのテーブルは、２つ以上のテーブルに分割されてもよいし、２つ以上のテーブルの全部又は一部が１つのテーブルであってもよい。

また、以下の説明では、「プログラム」を主語として処理を説明する場合があるが、プログラムは、プロセッサによって実行されることで、定められた処理を、適宜にメモリ及び／又は通信インターフェース装置等を用いながら行うため、処理の主語が、プロセッサ（或いは、そのプロセッサを有するコントローラのようなデバイス）とされてもよい。プログラムは、プログラムソースから計算機のような装置にインストールされてもよい。プログラムソースは、例えば、プログラム配布サーバ又は計算機が読み取り可能な（例えば非一時的な）記録媒体であってもよい。また、以下の説明において、２つ以上のプログラムが１つのプログラムとして実現されてもよいし、１つのプログラムが２つ以上のプログラムとして実現されてもよい。

また、以下の説明では、同種の要素を区別しないで説明する場合には、参照符号のうちの共通符号（又は参照符号）を使用し、同種の要素を区別する場合は、参照符号（又は当該要素の識別子）を使用することがある。

図１は、本発明の一実施形態における分散ストレージシステムの概要を示す図である。

本実施形態における分散ストレージシステムは、汎用のネットワーク１０４に接続されたＦＢＯＦ等のドライブボックス１０６にＳＤＳやＨＣＩのＤＡＳを集約する「ドライブ分離型分散ストレージ構成」を有するストレージシステムである。ドライブボックス１０６にデータを集約することで、ストレージ性能とストレージ容量とを独立にスケールさせることが可能である。

当該構成では、各サーバ１０１がドライブボックス１０６に搭載されるドライブに直接アクセス可能であり、各ドライブがサーバ１０１間で共有される。このため、各サーバ１０１が、自身の担当データ（当該サーバ１０１が書き込んだデータ）に対し、別サーバ１０１と協力することなく、個別にデータ保護を行うことができる。さらに、サーバ１０１間が、チャンクグループ（それぞれがドライブボックス内ドライブ領域である２つ以上のチャンクで構成されたグループ（詳細は後述））ごとのデータ保護方法（例えば、ＲＡＩＤ構成やデータ配置パタン（データ及びパリティの配置パタン））に関するメタデータを共有する。これにより、サーバ１０１間で担当データの担当を変更する場合に、担当データと当該担当データの格納先のチャンクグループとを対応付ける情報を変更先サーバ１０１にコピーすることで、ネットワーク１０４介してのデータコピー無くデータ保護を継続することができる。

本実施形態では、分散ストレージシステムを構成する複数のサーバ１０１のうちの１つが代表サーバ１０１であり、代表サーバ１０１が、ドライブ増設時に、増設ドライブの各チャンクに関するＲＡＩＤ構成やデータ配置パタンを決定し、当該メタデータをサーバ１０１間で共有し、少なくとも１つのチャンクグループ（例えば、１つ以上の新たなチャンクグループ及び１つ以上の既存のチャンクグループのうちの少なくとも１つ）に、増設ドライブの少なくともチャンクを含める。各サーバ１０１は、チャンクグループにデータを書き込む時、データとチャンクグループの関連付けを行い、上述のメタデータに基づいて、別サーバ１０１と協力することなく、個別にデータ保護を行う。

サーバ１０１間で担当データの担当を変更する場合は、移動元サーバ１０１（担当データを担当していたサーバ１０１）が所有する、担当データとチャンクグループとの関連付けを表す情報を、移動先サーバ１０１（担当データを担当することになるサーバ１０１）にコピーする。以後、移動先サーバ１０１は、担当データのチャンクグループを表すメタデータに基づいて、サーバ１０１間で協力することなく、個別にデータ保護を行う。

本実施形態の分散ストレージシステムは、ネットワーク１０４に接続された複数のサーバ１０１（例えば、１０１Ａ～１０１Ｅ）と、同ネットワーク１０４に接続された複数のドライブボックス１０６（例えば、１０６Ａ～１０６Ｃ）と、同ネットワーク１０４に接続された管理サーバ１０５とで構成される。本実施形態の分散ストレージシステムは、ＳＤＳ／ＨＣＩシステムの一例でよい。各サーバ１０１には、単一のストレージ制御プログラム１０３と複数（又は単一）のアプリ１０２とが共存して動作する。但し、分散ストレージシステムにおける全てのサーバ１０１が、アプリ１０２及びストレージ制御プログラム１０３の両方を備えている必要は無く、一部のサーバ１０１が、アプリ１０２及びストレージ制御プログラム１０３の一方を備えていなくてもよい。アプリ１０２が存在するがストレージ制御プログラム１０３が存在しないサーバ１０１や、ストレージ制御プログラム１０３が存在するがアプリ１０２が存在しないサーバ１０１が存在した場合でも、本実施形態の分散ストレージシステムとして有効である。「アプリ」は、アプリケーションプログラムの略である。「ストレージ制御プログラム」は、ストレージ制御ソフトウェアと呼ばれてもよい。「サーバ１０１」は、ノードサーバ１０１の略でもよい。複数の汎用の計算機の各々が所定のソフトウェアを実行することにより、当該複数の計算機がＳｏｆｔｗａｒｅ－Ｄｅｆｉｎｅｄ ａｎｙｔｈｉｎｇ（ＳＤｘ）として構築されてもよい。ＳＤｘとしては、例えば、Ｓｏｆｔｗａｒｅ－Ｄｅｆｉｎｅｄ Ｓｔｏｒａｇｅ（ＳＤＳ）又はＳｏｆｔｗａｒｅ－Ｄｅｆｉｎｅｄ ＤａｔａＣｅｎｔｅｒ（ＳＤＤＣ）が採用されてよい。サーバ１０１が、計算機の一例である。ドライブボックス１０６が、ストレージユニットの一例である。

アプリ１０２の実行基盤としては、仮想マシンやコンテナが考えられるが、アプリ１０２の実行基盤は、仮想マシンやコンテナに依らない。

アプリ１０２から書き込まれるデータは、ストレージ制御プログラム１０３を介して、ネットワーク１０４に接続されたドライブボックス１０６Ａ～１０６Ｃのいずれかに格納される。ネットワーク１０４には、Ｅｔｈｅｒｎｅｔ、Ｆｉｂｒｅ Ｃｈｕｎｎｅｌ等の汎用的なネットワーク技術を用いることができる。ネットワーク１０４は、サーバ１０１とドライブボックス１０６とを直接接続してもよいし、１つ以上のスイッチを介して接続してもよい。通信プロトコルには、ｉＳＣＳＩ（Ｉｎｔｅｒｎｅｔ ＳＣＳＩ）やＮＶＭｅ－ｏＦ等の汎用技術を用いることが可能である。

各サーバ１０１のストレージ制御プログラム１０３は、互いに協調動作してすることで、複数サーバ１０１を束ねた分散ストレージシステムを構成する。このため、あるサーバ１０１に障害が発生した時は、別サーバ１０１のストレージ制御プログラム１０３が処理を代替し、Ｉ／Ｏを継続することが可能である。各ストレージ制御プログラム１０３は、データ保護機能や、スナップショット等のストレージ機能を有することができる。

管理サーバ１０５が、管理プログラム５１を有する。管理プログラム５１は、管理ソフトウェアと呼ばれてもよい。管理プログラム５１は、例えば、チャンクグループの構成を表す情報を上述のメタデータに含める。管理プログラム５１が行う処理は、後に説明する。

図２は、一比較例における分散ストレージシステムの概要を示す図である。

一比較例における分散ストレージシステムによれば、複数のサーバ１１の各々が、アプリ１２とストレージ制御プログラム１３との他に、Ｄｉｒｅｃｔ－ａｔｔａｃｈｅｄ Ｓｔｏｒａｇｅ（ＤＡＳ）、例えば、複数のドライブ３を有する。サーバ障害時にデータロスト防止のため、各サーバ１１が、別サーバ１１と協力して、データ保護を行う。データ保護のために、サーバ１１間でネットワーク１４を介したデータ転送が生じる。例えば、サーバ１１が、当該サーバ１１内のドライブ３にデータを書き込み、当該データの複製を、別サーバ１１にネットワーク１４を介して転送し、別サーバ１１が、当該別サーバ１１内のドライブ３に、当該データ複製を書き込む。

一方、本実施形態における分散ストレージシステム（図１参照）によれば、データ保護のためにサーバ１０１間で保護対象のデータをネットワーク１４を介して転送する必要が無い。また、ストレージ制御プログラム１０６に障害が発生した場合、メタデータを共有する他のストレージ制御プログラム１０６が、チャンクに格納されたデータにアクセスしてよい。ドライブに障害が発生した場合、障害の発生していない他のドライブに記憶された冗長化させたデータを用いて、ストレージ制御プログラム１０６が、障害の発生したドライブのデータを復元してよい。

図３は、本発明の一実施形態におけるドライブ障害修復の概要を示す図である。

図３（及び、後述の図４）には、サーバ１０１Ａ及び１０１Ｂとドライブボックス１０６Ａが代表的に示されている。ドライブボックス１０６Ａが、複数のドライブ２０４Ａ（例えば、２０４Ａａ～２０４Ａｆ）を含んでいる。

ドライブボックス１０６Ａを基に、複数のチャンクグループが提供される。チャンクグループは、２つ以上のチャンクから構成されたグループである。同一のチャンクグループを構成する２つ以上のチャンクは、異なる２つ以上のドライブ２０４Ａがそれぞれ提供する２つ以上のドライブ領域である。本実施形態において、１つのチャンクは、１つのドライブ２０４Ａが提供し、異なる２つ以上のドライブ２０４Ａに跨らない。図３が示す例によれば、ドライブ２０４Ａａが、チャンクＣａを提供し、ドライブ２０４Ａｂが、チャンクＣｂを提供し、ドライブ２０４Ａｄが、チャンクＣｄを提供し、ドライブ２０４Ａｆが、チャンクＣｆを提供する。それらのチャンクＣａ、Ｃｂ、Ｃｄ及びＣｆが、１つのチャンクグループを構成する。なお、図３が示す例によれば、１つのチャンクグループは１つのドライブボックス１０６Ａから提供されるが、少なくとも１つのチャンクグループが、異なる２つ以上のドライブボックス１０６に跨ってもよい。

サーバ１０１Ａが、図示しないＬｏｇｉｃａｌ Ｕｎｉｔ（ＬＵ）を提供するストレージ制御プログラム１０３Ａと、当該ＬＵに対してデータを書き込むアプリ１０２Ａとを有する。サーバ１０１Ｂが、ストレージ制御プログラム１０３Ｂ及びアプリ１０２Ｂを有する。

ストレージ制御プログラム１０３Ａが、メタデータ１７０Ａを参照する。ストレージ制御プログラム１０３Ｂが、メタデータ１７０Ｂを参照する。メタデータ１７０Ａとメタデータ１７０Ｂは、同期する。すなわち、メタデータ１７０Ａ及び１７０Ｂの一方のメタデータが更新された場合、更新が他方のメタデータに反映される。つまり、メタデータ１７０Ａ及び１７０Ｂは、同一内容に維持される。このようにして、ストレージ制御プログラム１０３Ａ及び１０３Ｂが、メタデータ１７０を共有する。なお、メタデータ１７０Ａ及び１７０Ｂが、それぞれサーバ１０１Ａ及び１０１Ｂに存在してもよいし、サーバ１０１Ａ及び１０１Ｂのいずれもがアクセス可能な共有領域にメタデータ１７０が存在してもよい。

メタデータ１７０Ａ及び１７０Ｂは、各チャンクグループについて、チャンクグループの構成とデータ保護方法（データ冗長化方式の一例）とを表す。例えば、ストレージ制御プログラム１０３Ａは、自身が提供するＬＵを指定したライト要求をアプリ１０２Ａから受けた場合、メタデータ１７０Ａを参照することで、チャンクグループがチャンクＣａ、Ｃｂ、Ｃｄ及びＣｆから構成されていること、及び、当該チャンクグループのデータ保護方法は、ＲＡＩＤレベル５（３Ｄ＋１Ｐ）であることを特定する。このため、ストレージ制御プログラム１０３Ａは、当該ライト要求に付随するデータを、ＲＡＩＤレベル５（３Ｄ＋１Ｐ）に従い冗長化し、冗長化されたデータである冗長化データセットを、当該チャンクグループに書き込む。「冗長化データセット」は、複数のデータ要素で構成されている。データ要素は、アプリ１０２からのデータの少なくとも一部である「ユーザデータ要素」と、２つ以上のユーザデータ要素を基に生成された「パリティ」とのいずれかでよい。データ保護方法が、ＲＡＩＤレベル５（３Ｄ＋１Ｐ）であるため、冗長化データセットは、３つのユーザデータ要素と１つのパリティから構成されている。例えば、３つのユーザデータ要素が、３つのチャンクＣａ、Ｃｂ及びＣｄにそれぞれ書き込まれ、１つのパリティが、１つのチャンクＣｆに書き込まれる。

その後、いずれかのドライブ２０４Ａ、例えば、ドライブ２０４Ａａに障害が生じたとする。この場合、ドライブ２０４Ａａに格納されており１つ又は複数の冗長化データセットがそれぞれ有する１つ又は複数のデータ要素の各々について、当該データ要素を書き込んだストレージ制御プログラム１０３が、次の処理を行う。例えば、チャンクＣａにユーザデータ要素を書き込んだストレージ制御プログラム１０３Ａが、メタデータ１７０Ａを基に、当該ユーザデータ要素を、当該ユーザデータ要素を含む冗長化データセットのうち当該ユーザデータ要素以外のユーザデータ要素及びパリティから復元し、当該復元したユーザデータ要素を、当該冗長化データセットを格納するドライブ２０４Ａａ、２０４Ａｂ、２０４Ａｄ及び２０４Ａｆ以外のドライブに書き込む。具体的には、例えば、以下のうちのいずれかが行われてよい。
・図３には示されないが、ストレージ制御プログラム１０３Ａが、当該復元したユーザデータ要素を含む冗長化データセットを、障害ドライブ２０４Ａａ以外の２つ以上のドライブ２０４に基づくチャンクグループに書き込む。このケースでは、チャンクグループの再構成は不要である。
・図３が示す通り、ストレージ制御プログラム１０３Ａが、当該復元したユーザデータ要素を、ドライブ２０４Ａｃ（ドライブ２０４Ａａ、２０４Ａｂ、２０４Ａｄ及び２０４Ａｆ以外のドライブの一例）のチャンクＣｃに書き込む。そして、ストレージ制御プログラム１０３Ａは、当該ユーザデータ要素を含んだ冗長化データセットを保持するチャンクグループの構成を変更する、具体的には、当該チャンクグループのうち、チャンクＣａをチャンクＣｃに差し替える。このように、このケースでは、チャンクグループの再構成は必要である。

なお、図３において、「チャンクＣｃ」は、ドライブ２０４Ａｃが提供する２つ以上のチャンクのうちの１つのチャンクの一例である。「ドライブ２０４Ａｃ」は、ドライブ２０４Ａａ、ドライブ２０４Ａｂ、２０４Ａｄ及び２０４Ａｆ以外のいずれかのドライブ２０４Ａの一例である。「ドライブ２０４Ａａ」は、障害が生じたドライブ２０４の一例である。ドライブ２０４Ａｂ、２０４Ａｄ及び２０４Ａｆの各々が、当該冗長化データセットのデータ要素を格納したドライブの一例である。

図４は、本発明の一実施形態におけるサーバ障害修復の概要を示す図である。

ストレージ制御プログラム１０３Ａ（２つ以上のストレージ制御プログラム１０３の各々の一例）が、自身が提供したＬＵについて、ページマッピングテーブル（マッピングデータの一例）を管理している。ページマッピングテーブルは、ＬＵ領域とページとの対応関係を表すテーブルである。「ＬＵ領域」とは、ＬＵにおける一部の記憶領域である。「ページ」とは、チャンクグループの一部（又は全部）としての記憶領域であり、チャンクグループを構成する２つ以上のチャンクの各々の一部（又は全部）を構成要素とした記憶領域である。例えば、本実施形態では、ＬＵが新規作成された場合に、ストレージ制御プログラム１０３は、ＬＵ全域分の数の空きのページ（いずれのＬＵ領域にも未だ割り当てられていない割当て可能な状態のページ）を特定し、当該ＬＵに空ページを割り当てる。ストレージ制御プログラム１０３Ａは、当該ＬＵ領域に当該ページが割り当てられたことをページマッピングテーブルに登録する。ストレージ制御プログラム１０３は、ライト先のＬＵ領域に割り当てられているページを含んだチャンクグループに、ライト要求に付随するデータの冗長化データセットを書き込む。

いずれかのサーバ１０１、例えば、サーバ１０１Ａに障害が生じたとする。この場合、サーバ１０１Ａにおけるストレージ制御プログラム１０３Ａが提供した１つ以上のＬＵの各々について、当該ＬＵの復旧先のサーバ１０１として選択されたサーバ１０１Ｂにおけるストレージ制御プログラム１０３Ｂが、当該ＬＵについてのページマッピングテーブル（例えば、ストレージ制御プログラム１０３Ａから受信したページマッピングテーブル）を基に、当該ＬＵを復旧し、復旧したＬＵをアプリ１０２Ｂに提供する。ストレージ制御プログラム１０３Ｂが、当該ページマッピングテーブルを参照することで、復旧したＬＵのＬＵ領域に割り当てられているページから、１つ以上の冗長化データセットに従うデータを読み出すことができる。別の言い方をすれば、ストレージ制御プログラム１０３Ａが提供した１つ以上のＬＵの各々について、当該ＬＵのオーナーサーバ（当該ＬＵへのＩ／Ｏを担当するサーバ）がサーバ１０１Ａからサーバ１０１Ｂに変わっても、ネットワーク１０４を介したデータ移動無しに、サーバ１０１Ｂは、当該ＬＵのデータにアクセスすることができる。

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

図５は、本実施形態におけるサーバ１０１、管理サーバ１０５及びドライブボックス１０６のハード構成例を示す図である。

サーバ１０１は、メモリ２０２と、ネットワークＩ／Ｆ２０３（通信インターフェース装置の一例）と、それらに接続されたプロセッサ２０１とを有する。メモリ２０２、ネットワークＩ／Ｆ２０３及びプロセッサ２０１のうちの少なくとも１つが多重化（例えば二重化）されていてもよい。メモリ２０２が、アプリ１０２及びストレージ制御プログラム１０３を格納し、プロセッサ２０１が、アプリ１０２及びストレージ制御プログラム１０３を実行する。

管理サーバ１０５も、同様に、メモリ２２２と、ネットワークＩ／Ｆ２２３（通信インターフェース装置の一例）と、それらに接続されたプロセッサ２２１とを有する。メモリ２２２、ネットワークＩ／Ｆ２２３及びプロセッサ２２１のうちの少なくとも１つが多重化（例えば二重化）されていてもよい。メモリ２２２が、管理プログラム５１を格納し、プロセッサ２２１が、管理プログラム５１を実行する。

ドライブボックス１０６は、メモリ２１２と、ネットワークＩ／Ｆ２１３と、ドライブＩ／Ｆ２１４と、それらに接続されたプロセッサ２１１とを有する。ネットワークＩ／Ｆ２１３及びドライブＩ／Ｆ２１４が、通信インターフェース装置の一例である。ドライブＩ／Ｆ２１４に、複数のドライブ２０４が接続される。サーバ１０１と、管理サーバ１０５と、ドライブボックス１０６とは、ネットワークＩ／Ｆ２０３、２２３及び２２１経由でネットワーク１０４に接続され、互いに通信が可能である。ドライブ２０４は、Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ（ＨＤＤ）やＳｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ（ＳＳＤ）といった汎用的なドライブでよい。当然ながら、本発明はドライブの種類やフォームファクタに依存せず、他の種類のドライブが用いられてもよい。

図６は、本実施形態における分散ストレージシステムの区分の一例を示す図である。

分散ストレージシステムが、複数のドメイン３０１に区分されてよい。すなわち、サーバ１０１やドライブボックス１０６が、「ドメイン」と呼ばれる単位で管理されてよい。本構成において、アプリ１０２がＬＵに書き込むデータは、ストレージ制御プログラム１０３を介して、アプリ１０２が動作するサーバ１０１と同じドメイン３０１に属するいずれかのドライブボックス１０６に格納される。例えば、ドメイン３０１（＃０００）に属するサーバ１０１（＃０００）及び１０１（＃００１）において発生したライト対象のデータは、サブネットワーク５４Ａをドライブボックス１０６（＃０００）及び１０６（＃００１）の一方又は両方に格納され、ドメイン３０１（＃００１）に属するサーバ１０１（＃００２）及び１０１（＃００３）において発生したライト対象のデータは、ドライブボックス１０６（＃００２）に格納される。このようにドメインを用いて分散ストレージシステムを構成することで、ドライブボックス１０６やドライブ２０４に障害が発生した場合の、サーバ性能影響をドメイン３０１間で分離することが可能となる。

例えば、図６が示す例によれば、ネットワーク１０４は、サブネットワーク５４Ａ及び５４Ｂ（複数のサブ通信ネットワークの一例）を含む。ドメイン３０１（＃０００）（複数のドメインの各々の一例）は、当該ドメイン３０１（＃０００）に対応したサブネットワーク５４Ａに接続されたサーバ１０１（＃０００）及び１０１（＃００１）とドライブボックス１０６（＃０００）及び１０６（＃００１）とを含み、サブネットワーク５４Ａに別のサブネットワーク５４Ｂを介して接続されたサーバ１０１（＃００２）及び１０１（＃００３）とドライブボックス１０６（＃００２）とを含まない。これにより、サブネットワーク５４Ａ及び５４Ｂ間が切断されても、ドメイン３０１（＃０００）及び３０１（＃００１）の各々の範囲で、ドライブボックス１０６に書き込まれたデータの読み出しを維持することができる。

図７は、ドメイン管理テーブル４００の構成例を示す図である。

ドメイン管理テーブル４００は、ドメイン３０１毎にドメイン３０１を構成するサーバ群とドライブボックス群とを管理するためのテーブルである。ドメイン管理テーブル４００は、ドメイン３０１毎にレコードを有する。各レコードが、ドメイン＃４０１、サーバ＃４０２、及び、ドライブボックス＃４０３といった情報を保持する。１つのドメイン３０１を例に取る（図７の説明において「対象ドメイン３０１」）。

ドメイン＃４０１は、対象ドメイン３０１の識別子を表す。サーバ＃４０２は、対象ドメインに属するサーバ１０１の識別子を表す。ドライブボックス＃４０３は、対象ドメインに属するドライブボックス１０６の識別子を表す。

図８は、本実施形態におけるドライブ領域管理の一例を示す図である。

本実施形態では、ドライブボックス１０６に搭載された複数のドライブ２０４を「チャンク」５０１と呼ぶ複数の固定サイズ領域に分割して管理する。本実施形態では、異なる複数のドライブに属する複数のチャンクを組み合わせた記憶領域であるチャンクグループが、ＲＡＩＤ構成を有する。当該チャンクグループのＲＡＩＤ構成に従うＲＡＩＤレベル（データ冗長度やデータ配置パタン）に従い、冗長化データセットを構成する複数のデータ要素が、当該チャンクグループに書き込まれる。当該チャンクグループのＲＡＩＤ構成に従い、一般的なＲＡＩＤ／ＥＣ技術を用いてデータ保護が行われる。本実施形態の説明において、記憶領域に関する用語の定義は、下記の通りである。
・「チャンク」は、１つのドライブ２０４が提供する記憶領域全体の一部である。１つのドライブ２０４が、複数のチャンクを提供する。
・「チャンクグループ」は、異なる２つ以上のドライブ２０４がそれぞれ提供する異なる２つ以上のチャンクから構成された記憶領域である。１つのチャンクグループを提供する「異なる２つ以上のドライブ２０４」は、１つのドライブボックス１０６に閉じていてもよいし、２つ以上のドライブボックス１０６に跨っていてもよい。
・「ページ」は、チャンクグループを構成する２つ以上のチャンクの各々の一部から構成される記憶領域である。ページが、チャンクグループそれ自体でもよいが、本実施形態では、複数のページから１つのチャンクグループが構成されている。
・「ストリップ」は、１つのドライブ２０４が提供する記憶領全体の一部である。１つストリップは、１つのデータ要素（ユーザデータ要素又はパリティ）を格納する。ストリップは、１つのドライブ２０４が提供する最小単位の記憶領域でよい。すなわち、複数のストリップから１つのチャンクが構成されていてもよい。
・「ストライプ」は、異なる２つ以上のドライブ２０４が提供する異なる２つ以上のストリップ（例えば同一論理アドレスの２つ以上のストリップ）から構成された記憶領域である。１つのストライプに、１つの冗長化データセットが書き込まれてよい。すなわち、１つのストライプを構成する２つ以上のストリップに、１つの冗長化データセットを構成する２つ以上のデータ要素がそれぞれ書き込まれてよい。ストライプは、ページの全体又は一部でよい。また、ストライプは、チャンクグループの全体又は一部であってよい。本実施形態では、１つのチャンクグループが、複数のページから構成されていて、１つのページが、複数のストライプから構成されていてよい。チャンクグループを構成する複数のストライプは、当該チャンクグループのＲＡＩＤ構成と同一のＲＡＩＤ構成を持っていてよい。
・「冗長構成領域」は、ストライプ、ページ及びチャンクグループのいずれかの一例でよい。
・「ドライブ領域」は、デバイス領域の一例でよく、具体的には、例えば、ストリップ及びチャンクのいずれかの一例でよい。

図９は、チャンクグループ管理テーブル６００の構成例を示す図である。

チャンクグループ管理テーブル６００は、各チャンクグループの構成及びデータ保護方法（ＲＡＩＤレベル）を管理するためのテーブルである。チャンクグループ管理テーブル６００が、後述するように、メタデータ１７０の少なくとも一部である。チャンクグループ管理テーブル６００は、チャンクグループ毎にレコードを有する。各レコードは、チャンクグループ＃６０１、データ冗長度６０２、及び、チャンク構成６０３といった情報を保持する。１つのチャンクグループを例に取る（図９の説明において「対象チャンクグループ」）。

チャンクグループ＃６０１は、対象チャンクグループの識別子を表す。データ冗長度６０２は、対象チャンクグループのデータ冗長度（データ保護方法）を表す。チャンク＃６０３は、対象チャンクグループの構成要素としておチャンクの識別子を表す。

図９が示す例によれば、チャンクグループ＃０００は、４つのチャンク（Ｃ１１、Ｃ２１、Ｃ３１、Ｃ４１）から構成されていて、ＲＡＩＤ５（３Ｄ＋１Ｐ）で保護されることがわかる。

このようなチャンクグループ管理テーブル６００がメタデータ１７０の少なくとも一部として複数のサーバ１０１に共有される。このため、いずれのサーバ１０１からいずれのチャンクグループにデータを書き込む場合にも、当該チャンクグループのデータ冗長度に従うデータ保護が可能である。

尚、データ配置パタンに関しては、データ冗長度に応じて決めることが多いため、記載を省略する。

また、本実施形態では、動的に（例えば、ドライブへの書き込み量に応じて、言い換えれば、１つ以上の構成済のチャンクグループの空き容量に応じて）、少なくとも１つのストレージ制御プログラム１０３（例えば、代表サーバ１０１におけるストレージ制御プログラム１０３）が、チャンクグループを新たに構成し、新たに構成されたチャンクグループの情報を、チャンクグループ管理テーブル６００に追加してもよい。これにより、分散ストレージシステムの状況に応じて最適なデータ冗長度のチャンクグループを構成すること、つまり、チャンクグループのデータ冗長度の最適化が期待される。具体的には、例えば、下記が採用されてもよい。
・チャンク管理テーブルが用意されてよい。チャンク管理テーブルは、複数のストレージ制御プログラム１０３が共有してよい。チャンク管理グループは、チャンク毎に、当該チャンクを提供するドライブと、当該ドライブを有するドライブボックスと、チャンクの状態（例えば、いずれのチャンクグループの構成要素となっていない空きの状態であるか否か）を表してよい。
・ストレージ制御プログラム１０３（又は、管理プログラム５１）が、チャンクグループを新たに作成する条件が満たされた場合（例えば、１つ以上の作成済みチャンクグループの空き容量が所定値未満になった場合）、異なる２つ以上のドライブ２０４がそれぞれ提供する異なる２つ以上の空きチャンクから構成されたチャンクグループを新たに作成してよい。ストレージ制御プログラム１０３（又は、管理プログラム５１）は、当該チャンクグループの構成を表す情報をチャンクグループ管理テーブル６００に追記してよい。ストレージ制御プログラム１０３が、新たに作成されたチャンクグループに、ライト対象のデータに従う１つ以上の冗長化データセットを書き込んでよい。これにより、チャンクグループの枯渇を回避しながら、最適なデータ冗長度のチャンクグループを作成することが期待される。
・ストレージ制御プログラム１０３（又は、管理プログラム５１）は、作成するチャンクグループのデータ冗長度（ＲＡＩＤレベル）を、所定のポリシーに従って決定してよい。例えば、ドライブボックスにおける空き容量が所定値以上であれば、ストレージ制御プログラム１０３（又は、管理プログラム５１）は、新たに作成するチャンクグループのデータ冗長度を、ＲＡＩＤ６（３Ｄ＋２Ｐ）としてよい。ドライブボックスにおける空き容量が所定値未満であれば、ストレージ制御プログラム１０３（又は、管理プログラム５１）は、新たに作成するチャンクグループのデータ冗長度を、ドライブボックスにおける空き容量が所定値以上の場合よりも少ないチャンクで実現可能なデータ冗長度（例えば、ＲＡＩＤ５（３Ｄ＋１Ｐ））としてよい。

また、本実施形態では、全ドライブボックス１０６が有する全ドライブ２０４を基に複数のチャンクグループが予め構成されていてもよい。

また、本実施形態では、後述するように、ドライブ増設時にドライブ内全領域のチャンクに関するチャンクグループが構成されてもよい。ドライブ増設は、ドライブ単位で行われてもよいし、ドライブボックス単位で行われてもよい。

図１０は、ページマッピングテーブル７００の構成例を示す図である。

上述したように、本実施形態では、ＬＵ（Ｌｏｇｉｃａｌ Ｕｎｉｔ）と呼ぶ単位でアプリ１０２に書き込み領域が提供される。各チャンクグループの領域は、チャンクグループよりも小さい固定サイズ領域であるページで管理され、ＬＵ領域と対応付けられる。ページマッピングテーブル７００は、ＬＵ領域とページ（チャンクグループの一部領域）との対応関係を管理するためのテーブルである。尚、本実施形態では、ＬＵ作成時、ＬＵの全領域にページが割り当てられるが、Ｔｈｉｎ Ｐｒｏｖｉｓｉｏｎｉｎｇと呼ばれる技術を用いて、動的に、ライト先のＬＵ領域にページが割り当てられても構わない。

ページマッピングテーブル７００は、ＬＵ領域毎にレコードを有する。各レコードが、ＬＵ＃７０１、ＬＵ領域先頭アドレス７０２、チャンクグループ＃７０３、及び、チャンクグループ内オフセット７０４といった情報を保持する。１つのＬＵ領域を例に取る（図１０の説明において「対象ＬＵ領域」）。

ＬＵ＃７０１は、対象ＬＵ領域を含んだＬＵの識別子を表す。ＬＵ領域先頭アドレス７０２は、対象ＬＵ領域の先頭アドレスを表す。チャンクグループ＃７０３は、対象ＬＵ領域に割り当てられたページを含んだチャンクグループの識別子を表す。チャンクグループ内オフセット７０４は、対象領域に割り当てられたページの位置（当該ページを含んだチャンクグループの先頭アドレスから当該ページの先頭アドレスまでの差分）を表す。

図１１は、空きページ管理テーブル７１０の構成例を示す図である。

空きページ管理テーブル７１０は、各サーバ１０１が別サーバ１０１と通信することなく、ＬＵに割り当て可能な空きページを管理するためのテーブルである。空きページ管理テーブル７１０は、空きページ毎にレコードを有する。各レコードが、チャンクグループ＃７１１及びチャンクグループ内オフセット７１２といった情報を保持する。１つの空きページを例に取る（図１１の説明において「対象空きページ」）。

チャンクグループ＃７１１は、対象空きページを含んだチャンクグループの識別子を表す。チャンクグループ内オフセット７１２は、対象空きページの位置（対象空きページを含んだチャンクグループの先頭アドレスから対象空きページの先頭アドレスまでの差分）を表す。

空きページは、代表サーバ１０１（又は管理サーバ１０５）によって、各サーバ１０１に割り当てられ、当該テーブル７１０に、割り当てられた空きページの情報が追加される。また、ＬＵ作成時に作成されたＬＵに割り当てられた空きページのレコードは、当該テーブル７１０から削除される。あるサーバ１０１の空きページが不足する場合は、代表サーバ１０１（又は管理サーバ１０５）によって、新しいチャンクグループが作成され、チャンクグループ内の領域が、新たな空きページとして、当該あるサーバ１０１に追加される。つまり、本実施形態では、サーバ１０１毎に、当該サーバ１０１が保持する空きページ管理テーブル７１０は、当該サーバ１０１がアクセス可能な全ドライブボックス１０６が提供する複数のページのうち、当該サーバ１０１に、当該サーバ１０１において提供されるＬＵに割り当て可能として割り当てられたページに関する情報を保持する。

ＬＵ作成時のページ割当て制御や、空きページ制御のシーケンスの詳細については、記載を省略する。

図１２は、本実施形態におけるテーブル配置の一例を示す図である。

以下、１つのサーバとして、サーバ１０１Ａを例に取り説明する。サーバ１０１Ａについての説明は、他の各サーバ１０１（例えば、サーバ１０１Ｂ）についても適用可能である。

まず、サーバ１０１Ａは、分散ストレージシステムの複数の区分である複数のドメインを表すドメイン管理テーブル４００Ａを保持してよい。

また、サーバ１０１Ａは、自身で稼働中のアプリ１０２が使用するＬＵに関連するページマッピングテーブル７００Ａと、サーバ１０１ＡにＬＵに割り当て可能な空きページとして割り当てられた空きページの情報を保持する空きページ管理テーブル７１０Ａとを所有する。言い換えれば、サーバ１０１Ａは、全サーバ１０１の全ページマッピングテーブルを持たないでよい。全サーバ１０１の全ページマッピングテーブルが全サーバ１０１で共有されると、各サーバ１０１が所有する管理データ量が肥大化し、スケーラビリティに影響を与えるためである。但し、サーバ障害時の管理データ消失に対応するため、ページマッピングテーブル７００Ａは、分散ストレージシステムを構成する一部の別のサーバ１０１にバックアップされてよい。尚、本実施形態において、「管理データ」は、ストレージ制御プログラム１０３が保持するデータであって、ドメイン管理テーブル４００Ａ、ページマッピングテーブル７００Ａ、空きページ管理テーブル７１０Ａ及びメタデータ１７０Ａを含んでよい。メタデータ１７０Ａは、チャンクグループ管理テーブル６００Ａを含んでよい。ページマッピングテーブル７００Ａは、ストレージ制御プログラム１０３Ａが提供する１つ以上のＬＵについての情報を持つが、ＬＵ毎に存在してもよい。

以降、あるＬＵについて、当該ＬＵのページマッピングテーブル部分を所有するサーバをオーナーサーバと呼ぶ。オーナーサーバは、ＬＵに関するメタデータへ高速アクセスでき、高速なＩ／Ｏを可能である。このため、本実施形態の説明では、当該ＬＵを利用するアプリをオーナーサーバに配置する構成について記載する。但し、アプリをオーナーサーバとは別のサーバに配置し、オーナーサーバにＩ／Ｏを行うことも可能である。

チャンクグループ管理テーブル６００Ａは、ストレージ制御プログラムが稼働しているサーバ１０１間で同期する。このため、全てのサーバ１０１で同一の構成情報（同一の内容）を参照可能である。これにより、アプリとＬＵとをサーバ１０１Ａから別サーバ１０１Ｂに移動する時に、ユーザデータ要素やパリティを再構成する必要（言い換えれば、ネットワーク１０４を介したデータコピーをする必要）が無い。このような再構成（データコピー）が無くても、アプリとＬＵの移動先サーバでもデータ保護を継続することが可能となる。

ストレージ制御プログラム１０３は、ドメイン管理テーブル４００Ａ及びチャンクグループ管理テーブル６００Ａを参照し、データの書き込み先として、同一ドメイン内にある１つ以上のドライブボックス１０６から提供されるチャンクグループを特定してよい。また、ストレージ制御プログラム１０３は、ドメイン管理テーブル４００Ａ及びチャンクグループ管理テーブル６００Ａを参照し、同一ドメイン内にある１つ以上のドライブボックス１０６から提供される２つ以上の空きチャンク（異なる２以上のドライブから提供される２つ以上の空きチャンク）を特定し、当該２つ以上の空きチャンクでチャンクグループを構成し（その際、例えば、当該チャンクグループのデータ冗長度を、分散ストレージシステムの状況に応じて決定し）、当該チャンクグループの情報を、チャンクグループ管理テーブル６００Ａに追加してよい。いずれのチャンクがいずれのドライブボックス１０６のドライブ２０４から提供されているかは、例えば、下記のいずれかにより特定されてよい。
・チャンクグループ管理テーブル６００に、チャンク毎に、当該チャンクを提供するドライブ２０４と当該ドライブ２０４を有するドライブボックス１０６との情報が追加される。
・チャンクの識別子が、当該当該チャンクを提供するドライブ２０４の識別子と当該ドライブ２０４を有するドライブボックス１０６の識別子とを含む。

以下、本実施形態で行われる幾つかの処理を説明する。なお、以下の説明では、アプリ１０２として、アプリ１０２Ａを例に取り、ストレージ制御プログラム１０３として、ストレージ制御プログラム１０３Ａを例に取る。

図１３は、リード処理の流れの一例を示す図である。

ストレージ制御プログラム１０３Ａが、アプリ１０２Ａから、当該アプリ１０２Ａが利用するＬＵ（当該ストレージ制御プログラム１０３Ａが提供したＬＵ）を指定したリード要求を受ける（Ｓ９０１）。ストレージ制御プログラム１０３Ａが、ページマッピングテーブル７００Ａを使って、当該リード要求で指定されたアドレス（例えば、ＬＵ＃とＬＵ領域アドレスとの組）を、ページアドレス（チャンクグループ＃とチャンクグループ内オフセットアドレスとの組）に変換する（Ｓ９０２）。その後、ストレージ制御プログラム１０３Ａが、ページアドレスが属するページの基になっている２つ以上のドライブ２０４から１つ以上の冗長化データセットを読み出し（Ｓ９０３）、読み出した１つ以上の冗長化データセットからリード対象のデータを構築し、リード対象のデータをアプリ１０２Ａに応答する（Ｓ９０４）。

図１４は、ライト処理の流れの一例を示す図である。

ストレージ制御プログラム１０３Ａが、アプリ１０２Ａから、ＬＵを指定したライト要求を受ける（Ｓ１００１）。ストレージ制御プログラム１０３Ａが、ページマッピングテーブル７００Ａを使って、当該ライト要求で指定されたアドレス（例えば、ＬＵ＃とＬＵ領域アドレスとの組）を、ページアドレス（チャンクグループ＃とチャンクグループ内オフセットアドレスとの組）に変換する（Ｓ１００２）。ストレージ制御プログラム１０３Ａは、チャンクグループ管理テーブル６００Ａを使って、ページアドレス中のチャンクグループ＃のデータ冗長度を特定する（Ｓ１００３）。ストレージ制御プログラム１０３Ａが、特定したデータ冗長度に従い、ライト対象のデータを冗長化した１つ以上の冗長化データセットを作成する（Ｓ１００４）。最後に、ストレージ制御プログラム１０３Ａが、作成した１つ以上の冗長化データセットを、Ｓ１００２で得られたページアドレスが属するページの基になっている２つ以上のドライブ２０４に書き込み（Ｓ１００５）、アプリ１０２Ａに、書き込み完了を応答する（Ｓ１００６）。

図１５は、ドライブ増設処理の流れの一例を示す図である。

まず、管理プログラム５１から、代表サーバ１０１Ａのストレージ制御プログラム１０３Ａが、ドライブ増設の指示を受ける（Ｓ１１００）。代表サーバ１０１Ａのストレージ制御プログラム１０３Ａは、増設後のドライブ構成に基づき、チャンクグループを再構成し、チャンクグループ管理テーブル６００Ａを、再構成後の複数のチャンクグループを表す情報に更新する（Ｓ１１０２）。

ストレージ制御プログラム１０３Ａが、全てのサーバ１０１のストレージ制御プログラム１０３にチャンクグループの構成変更を通知する（Ｓ１１０３）。各サーバ１０１のストレージ制御プログラム１０３は、通知内容に応じて、自身のチャンクグループ構成変更を変更する（Ｓ１１０４）。すなわち、Ｓ１１０３及びＳ１１０４により、各サーバ１０１のチャンクグループ管理テーブル６００の内容が、更新後のチャンクグループ管理テーブル６００Ａと同一の内容になる。

尚、Ｓ１１０２のチャンクグループ再構成は、例えば次の通りでよい。すなわち、ストレージ制御プログラム１０３Ａは、増設された全ドライブ２０４の各々のチャンクを定義する。ここで定義された各チャンクを、「増設チャンク」と言う。ストレージ制御プログラム１０３Ａが、複数の増設チャンクを使用してチャンクグループ再構成を行う。チャンクグループ再構成は、チャンクグループを構成するチャンクの数を均一化する（チャンクグループを構成するチャンクを組みなおす）リバランス処理と、増設チャンクを用いて新規チャンクグループを作成する処理とのうちの少なくとも１つを含んでよい。

ドライブ増設に伴いチャンクグループ再構成が行われるので、ドライブが増設されてもチャンクグループの構成を最適な構成に維持することが期待できる。

図１６は、ドライブ障害修復処理の流れの一例を示す図である。

まず、代表サーバ１０１Ａのストレージ制御プログラム１０３Ａがドライブ障害を検知する（Ｓ１２０１）。障害ドライブ（ドライブ障害が生じたドライブ）が提供する各チャンクを、以下、「障害チャンク」と言う。ストレージ制御プログラム１０３Ａが、チャンクグループ管理テーブル６００Ａを参照して、障害チャンク毎に、修復先チャンクを選択する（Ｓ１２０２）。チャンクグループ管理テーブル６００Ａが、いずれのチャンクグループにも属していない空きチャンクの情報（例えば、空きチャンク毎に、空きチャンクの識別子、当該空きチャンクを提供するドライブの識別子、及び、当該ドライブの識別子を含んだ情報）を保持してもよい。各障害チャンクについて、修復先チャンクとして選択されたチャンクは、当該障害チャンクを含むチャンクグループのいずれのチャンクも提供していないドライブ２０４が提供する空きチャンクである。言い換えれば、各障害チャンクについて、当該障害チャンクを含んだチャンクグループにおけるいずれのチャンクも、修復先チャンクとして選択されない。

ストレージ制御プログラム１０３Ａが、全サーバ１０１のストレージ制御プログラム１０３に、障害ドライブの修復を指示する（Ｓ１２０３）。当該指示には、例えば、障害チャンクの一部を含んだページのページアドレスが指定される。

指示を受けた各サーバ１０１のストレージ制御プログラム１０３は、ループ（Ａ）に属するＳ１２０４～Ｓ１２０６を行う。Ｓ１２０４～Ｓ１２０６は、当該ストレージ制御プログラム１０３がオーナーであるＬＵに割り当てられているのページのうち、当該指示で指定されているページアドレスが表すページ（すなわち、障害ドライブが基になっているページ）毎に行われる。すなわち、ストレージ制御プログラム１０３は、ページマッピングテーブル７００を参照し、自身がオーナーであるＬＵに割り当てられているのページのうち、当該指示で指定されているページアドレスが表すページを選択する（Ｓ１２０４）。ストレージ制御プログラム１０３は、当該ページアドレスに含まれるチャンクグループ＃に対応したデータ冗長度をチャンクグループ管理テーブル６００から特定し、特定したデータ冗長度を基に、Ｓ１２０４で選択したページからデータを修復する（Ｓ１２０５）。ストレージ制御プログラム１０３が、修復したデータを、修復先チャンクグループのデータ冗長度を基に冗長化し、冗長化したデータ（１つ以上の冗長化データセット）を、修復先チャンクグループのページに書き込む（Ｓ１２０６）。

尚、ここで言う「修復先チャンクグループ」とは、障害ドライブ以外の２つ以上のドライブ２０４に基づくチャンクグループである。図１６が示す例によれば、修復したデータを冗長化したデータが、障害ドライブ以外の２つ以上のドライブに基づく空きのページに書き込まれるので、チャンクグループ再構成を行うこと無しに、ドライブ障害修復が可能である。

なお、上述したように、データ冗長度に基づき修復されたデータ要素（障害チャンク内のデータ要素）が、当該データ要素を含む冗長化データセットが格納されているチャンクグループに含まれていないいずれかのチャンクを修復先チャンクとして書き込まれてもよい。この場合、チャンクグループにおける障害チャンクが修復先チャンクに差し替えられるチャンクグループ再構成が行われてよい。

図１７は、サーバ障害修復処理の流れの一例を示す図である。

代表サーバ１０１Ａのストレージ制御プログラム１０３Ａが、サーバ障害を検知する（Ｓ１３０１）。次に、代表サーバ１０１Ａのストレージ制御プログラム１０３Ａが、障害サーバ（サーバ障害が生じたサーバ）における各ＬＵについて、Ｓ１３０２～Ｓ１３０５を行う。以下、１つのＬＵを例に取る（図１７の説明において「選択ＬＵ」）。なお、選択ＬＵを利用するアプリ１０２は、例えば管理プログラム５１により停止される。

ストレージ制御プログラム１０３Ａが、障害サーバにおけるＬＵの移動先のサーバ、つまり新たなオーナーサーバを決める（Ｓ１３０２）。オーナーサーバの決め方の詳細は省略するが、移動後のＩ／Ｏ負荷が各サーバで均一になるようにオーナーサーバが決められてよい。ストレージ制御プログラム１０３Ａが、選択ＬＵのオーナーサーバに決めたサーバのストレージ制御プログラム１０３に、選択ＬＵの修復を依頼する（Ｓ１３０３）。

修復依頼を受けたストレージ制御プログラム１０３は、いずれかのサーバに格納されている、選択ＬＵに対応したページマッピングテーブル部分のバックアップを、自身のサーバ１０１にコピーする（Ｓ１３０４）。このページマッピングテーブル部分を基に、選択ＬＵが、オーナーサーバにおいて復旧される。つまり、選択ＬＵの復旧先ＬＵに、選択ＬＵに代えて、選択ＬＵに割り当てられているページが割り当てられる。Ｓ１３０４において、ストレージ制御プログラム１０３は、選択ＬＵの情報（例えば、ＬＵ＃）を、自身のサーバ１０１におけるいずれかの空きのＬＵに引き継ぐ又は他の方法により、アプリから選択ＬＵに代えて自身のサーバ１０１におけるＬＵに対するＩ／Ｏを受け付け可能としてもよい。

最後に、管理プログラム５１（又はストレージ制御プログラム１０３Ａ）が、選択ＬＵを利用するアプリ１０２を再開する（Ｓ１３０５）。

このようにして、選択ＬＵに書き込まれたデータをネットワーク１０４を介してサーバ１０１間で転送すること無しに、サーバ障害修復が可能である。尚、新たなオーナーサーバにおいて、選択ＬＵのアプリが再開されてもよい。例えば、障害サーバにおけるアプリ（アクティブ）に対応したアプリ（スタンバイ）が存在するサーバが、オーナーサーバとされて、選択ＬＵを引き継いだオーナーサーバにおいて、当該アプリが再開されてよい。

図１８は、サーバ増設処理の流れの一例を示す図である。

管理プログラム５１が、増設サーバ（増設されたサーバ）に移動する１つ以上のＬＵを選択する（Ｓ１４０１）。各ＬＵについて、Ｓ１４０２～Ｓ１４０５が行われる。以下、１つのＬＵを例に取る（図１８の説明において「選択ＬＵ」）。

管理プログラム５１が、選択ＬＵを利用するアプリを一時停止する（Ｓ１４０２）。これにより、選択ＬＵに対するＩ／Ｏが発生しないようになる。管理プログラム５１が、選択ＬＵの移動元サーバ１０１（現在のオーナーサーバ１０１）のストレージ制御プログラム１０３に、選択ＬＵの移動を依頼する（Ｓ１４０３）。

当該依頼を受けたストレージ制御プログラム１０３が、選択ＬＵに対応したページマッピングテーブル部分を増設サーバ１０１にコピーする（Ｓ１４０４）。このページマッピングテーブル部分を基に、選択ＬＵが、増設サーバにおいて復旧される。つまり、選択ＬＵの復旧先ＬＵに、選択ＬＵに代えて、選択ＬＵに割り当てられているページが割り当てられる。

管理プログラム５１が、選択ＬＵに対応するアプリを再開する（Ｓ１４０５）。

このようにして、選択ＬＵに書き込まれたデータをネットワーク１０４を介してサーバ１０１間で転送すること無しに、サーバ増設処理が可能である。

尚、移動されたＬＵのアプリも、増設サーバに移動されてよい。

また、サーバ増設処理において、Ｓ１４０１において、１つ以上のＬＵに代えて、１つ以上のアプリが選択され、Ｓ１４０２～Ｓ１４０５は、選択されたアプリ毎に行われてよい。すなわち、Ｓ１４０２で、管理プログラム５１が、選択されたアプリを一時停止する。Ｓ１４０３で、管理プログラム５１が、当該アプリが利用する少なくとも１つのＬＵについて、オーナーサーバのストレージ制御プログラム１０３に、当該ＬＵを増設サーバに移動することを依頼する。Ｓ１４０４で、当該ＬＵに対応したページマッピングテーブル部分が増設サーバにコピーされる。Ｓ１４０５で、アプリが再開される。

図１９は、オーナーサーバ移動処理の流れの一例を示す図である。

オーナーサーバ移動処理は、ＬＵと当該ＬＵを利用するアプリとが同一サーバ１０１に無い場合に、当該ＬＵ及び当該アプリの一方を移動することで、当該ＬＵと当該アプリの両方を同一サーバ１０１に配置する処理である。以下、移動対象としてＬＵを例に取る。

管理プログラム５１が、移動対象のＬＵと移動先サーバ（新たなオーナーサーバ）を決める（Ｓ１５０１）。

管理プログラム５１が、移動対象のＬＵを利用するアプリを一時停止する（Ｓ１５０２）。管理プログラム５１が、移動対象のＬＵの現在のオーナーサーバのストレージ制御プログラム１０３に、当該ＬＵの移動を依頼する（Ｓ１５０３）。

当該依頼を受けたストレージ制御プログラム１０３が、当該ＬＵに対応したページマッピングテーブル部分を移動先サーバにコピーする（Ｓ１５０４）。

管理プログラム５１が、移動対象のＬＵを利用するアプリを再開する（Ｓ１５０５）。

このようにして、移動対象ＬＵ（オーナーサーバの変更対象のＬＵ）に書き込まれたデータをネットワーク１０４を介してサーバ１０１間で転送すること無しに、オーナーサーバ移動処理が可能である。

尚、オーナーサーバ移動処理及びサーバ増設処理では、管理プログラム５１が一部処理を実行していたが、管理プログラム５１の代わりに代表サーバ１０１Ａのストレージ制御プログラム１０３が処理を実行してもよい。

以上、本発明の実施形態を説明したが、本発明が上記の実施形態に限定されるものではない。当業者であれば、上記の実施形態の各要素を、本発明の範囲において容易に変更、追加、変換することが可能である。

上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、不揮発性半導体メモリ、ハードディスクドライブ、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の記憶デバイス、又は、ＩＣカード、ＳＤカード、ＤＶＤ等の計算機読み取り可能な非一時的データ記憶媒体に格納することができる。

１０１：サーバ
１０６：ドライブボックス

Claims (11)

1. 複数の物理記憶デバイスを含んだ１つ又は複数のストレージユニットと、
   前記１つ又は複数のストレージユニットに通信ネットワークを介して接続された複数の計算機と
   を有し、
   前記複数の計算機のうちの２つ以上の計算機が、それぞれ、ストレージ制御プログラムを実行し、
   前記２つ以上の計算機の各々が、前記複数の物理記憶デバイスが提供する複数の記憶領域に関するメタデータを有し、前記２つ以上の計算機における２つ以上のストレージ制御プログラムが、前記２つ以上の計算機のうちの一の計算機におけるメタデータの更新があった場合には前記２つ以上の計算機のうちの他の計算機におけるメタデータに当該更新を反映し、
   論理ユニット毎に、当該論理ユニットを構成する記憶領域と、２つ以上の物理記憶デバイスに基づく１つ以上の記憶領域との対応関係を表すデータであるマッピングデータを、当該論理ユニットのＩ／Ｏを担当する計算機であるオーナーサーバが有し、
   前記２つ以上のストレージ制御プログラムの各々は、
   当該ストレージ制御プログラムが提供する論理ユニットにおけるライト先領域を指定したライト要求を、当該論理ユニットを認識するアプリケーションから受け、
   当該ライト要求に付随するデータを、前記メタデータを基に冗長化し、
   当該冗長化されたデータである１つ以上の冗長化データセットを、当該ライト先領域の基になっている２つ以上の物理記憶デバイスが提供する１つ以上の記憶領域に書き込み、
   前記ストレージ制御プログラムに障害が発生した場合、当該障害が発生したストレージ制御プログラムを有する計算機における論理ユニット毎に、
   各計算機の負荷に基づいて、当該論理ユニットの移動先の計算機である新たなオーナーサーバを、それぞれ前記メタデータを有する２つ以上の計算機から選択し、
   当該選択された新たなオーナーサーバに、当該論理ユニットのマッピングデータをコピーし、
   当該論理ユニットについてのマッピングデータを基に、当該論理ユニットを前記新たなオーナーサーバに復旧し、当該復旧された論理ユニットを提供し、
   前記新たなオーナーサーバおけるストレージ制御プログラムが、前記コピーされたマッピングデータ及び前記メタデータを用いて、前記復旧された論理ユニットの記憶領域に格納されたデータにアクセスし、
   前記物理記憶デバイスに障害が発生した場合、障害の発生していない他の物理記憶デバイスに記憶された冗長化させたデータを用いて、前記ストレージ制御プログラムが前記障害の発生した物理記憶デバイスのデータを復元する
   分散ストレージシステム。
2. 前記複数の物理記憶デバイスの各々が、２つ以上の記憶領域である２つ以上のデバイス領域を提供し、
   前記複数の記憶領域は、複数の冗長構成領域であり、
   前記メタデータが、前記複数の冗長構成領域の各々について、当該冗長構成領域の構成とデータ保護方法とを表し、
   前記複数の冗長構成領域の各々は、冗長化データセットが書き込まれる記憶領域であって、前記複数の物理記憶デバイスのうちの２つ以上の物理記憶デバイスがそれぞれ提供するデバイス領域で構成されている記憶領域である、
   請求項１に記載の分散ストレージシステム。
3. １つ又は２つ以上の物理記憶デバイスが１つ以上のストレージユニットに追加されたこと、又は、１つ以上のストレージユニットが追加されたことを検出したストレージ制御プログラムが、
   １つ以上の冗長構成領域の追加と、１つ以上の冗長構成領域の構成の変更とのうちの少なくとも１つである再構成を行い、
   当該再構成後の冗長構成領域の構成を表すデータに前記メタデータを更新する、
   請求項２に記載の分散ストレージシステム。
4. いずれかの物理記憶デバイスに障害が生じた場合、当該障害が生じた物理記憶デバイスに格納されており１つ又は複数の冗長化データセットがそれぞれ有する１つ又は複数のデータ要素の各々について、当該データ要素を書き込んだストレージ制御プログラムが、前記メタデータを基に、当該データ要素を、当該データ要素を含む冗長化データセットのうち当該データ要素以外のデータ要素から復元し、当該復元したデータ要素を、当該冗長化データセットを格納した物理記憶デバイス以外のいずれかの物理記憶デバイスに書き込む、
   請求項１に記載の分散ストレージシステム。
5. 計算機が増設された場合、いずれか既存の計算機におけるストレージ制御プログラムが提供した少なくとも１つの論理ユニットについて、当該増設された計算機におけるストレージ制御プログラムが、
   当該論理ユニットのマッピングデータを当該既存の計算機におけるストレージ制御プログラムから受けて、
   当該マッピングデータを基に、当該論理ユニットを復旧し、
   復旧した論理ユニットを提供する、
   請求項１に記載の分散ストレージシステム。
6. いずれかの計算機におけるストレージ制御プログラムが提供した少なくとも１つの論理ユニットについて、当該計算機とは別の計算機であって当該論理ユニットの提供を受けるアプリケーションを有する計算機である移動先の計算機におけるストレージ制御プログラムが、
   当該論理ユニットのマッピングデータを、当該論理ユニットの移動元の計算機におけるストレージ制御プログラムから受けて、
   当該マッピングデータを基に、当該論理ユニットの移動先としての論理ユニットを構築し、
   当該構築した論理ユニットを、当該アプリケーションに提供する、
   請求項１に記載の分散ストレージシステム。
7. 複数のドメインがあり、
   前記複数のドメインの各々が、１つ以上の計算機と１つ以上のストレージユニットを含み、
   各ストレージ制御プログラムについて、当該ストレージ制御プログラムが生成した冗長化データセットのライト先は、当該ストレージ制御プログラムを含んだドメイン内の２つ以上の物理記憶デバイスである、
   請求項１に記載の分散ストレージシステム。
8. 前記通信ネットワークは、複数のサブ通信ネットワークを含み、
   前記複数のドメインの各々は、
   当該ドメインに対応したサブ通信ネットワークに接続された１つ以上の計算機及び１つ以上のストレージユニットを含み、
   当該ドメインに対応したサブ通信ネットワークに別の１つ以上のサブ通信ネットワークを介して接続された１つ以上の計算機及び１つ以上のストレージユニットを含まない、
   請求項７に記載の分散ストレージシステム。
9. 前記２つ以上のストレージ制御プログラムの少なくとも１つが、
   前記メタデータを基に、いずれの冗長化構成領域の構成要素になっていない２つ以上の空きのデバイス領域を特定し、
   特定した２つ以上の空きのデバイス領域で冗長化構成領域を構成し、
   構成された冗長化構成領域の情報を前記メタデータに追加する、
   請求項１に記載の分散ストレージシステム。
10. 前記２つ以上のストレージ制御プログラムの少なくとも１つが、前記メタデータから、１つ以上の構成済のチャンクグループの空き容量が閾値未満であることが特定された場合に、前記２つ以上の空きのデバイス領域を特定する、
    請求項９に記載の分散ストレージシステム。
11. 分散ストレージシステムを構成する複数の計算機のうちの２つ以上の計算機の各々が、前記複数の計算機に通信ネットワークを介して接続されている１つ又は複数のストレージユニットにおける複数の物理記憶デバイスが提供する複数の記憶領域に関するメタデータを有し、
    論理ユニット毎に、当該論理ユニットを構成する記憶領域と、２つ以上の物理記憶デバイスに基づく１つ以上の記憶領域との対応関係を表すデータであるマッピングデータを、当該論理ユニットのＩ／Ｏを担当する計算機であるオーナーサーバが有し、
    前記２つ以上の計算機における２つ以上のストレージ制御プログラムが、前記２つ以上の計算機のうちの一の計算機におけるメタデータの更新があった場合には前記２つ以上の計算機のうちの他の計算機におけるメタデータに当該更新を反映し、
    論理ユニットにおけるライト先領域を指定したライト要求を、いずれかの計算機に存在し当該論理ユニットを認識するアプリケーションから、当該論理ユニットを提供するストレージ制御プログラムが受けた場合、当該ストレージ制御プログラムが、
    当該ライト要求に付随するデータを、前記メタデータを基に冗長化し、
    当該冗長化されたデータである１つ以上の冗長化データセットを、当該ライト先領域の基になっている２つ以上の物理記憶デバイスが提供する１つ以上の記憶領域に書き込み、
    前記ストレージ制御プログラムに障害が発生した場合、当該障害が発生したストレージ制御プログラムを有する計算機における論理ユニット毎に、
    各計算機の負荷に基づいて、当該論理ユニットの移動先の計算機である新たなオーナーサーバを、それぞれ前記メタデータを有する２つ以上の計算機から選択し、
    当該選択された新たなオーナーサーバに、当該論理ユニットのマッピングデータをコピーし、
    当該論理ユニットについてのマッピングデータを基に、当該論理ユニットを前記新たなオーナーサーバに復旧し、当該復旧された論理ユニットを提供し、
    前記新たなオーナーサーバおけるストレージ制御プログラムが、前記コピーされたマッピングデータ及び前記メタデータを用いて、前記復旧された論理ユニットの記憶領域に格納されたデータにアクセスし、
    前記物理記憶デバイスに障害が発生した場合、障害の発生していない他の物理記憶デバイスに記憶された冗長化させたデータを用いて、前記ストレージ制御プログラムが、前記障害の発生した物理記憶デバイスのデータを復元する、
    記憶制御方法。

Images