WO2016052665A1

WO2016052665A1 - 分散型ストレージシステム

Info

Publication number: WO2016052665A1
Application number: PCT/JP2015/077853
Authority: WO
Inventors: 弘明圷; 俊二川村; 浩太安永; 貴大山本; 篤志河村
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2014-09-30
Filing date: 2015-09-30
Publication date: 2016-04-07
Anticipated expiration: 2017-03-30
Also published as: US11036585B2; JP2021089764A; JP2020144913A; GB2545290A; CN111258500B; US20180011764A1; DE112015000710T8; JP7374939B2; US20160371145A1; US20180357127A1; JP6815378B2; US10185624B2; US20210271551A1; JP7077359B2; US11487619B2; US10496479B2; US20200081781A1; CN111190552B; DE112015000710T5; JP6752149B2

Abstract

　分散型ストレージシステムにおいて、少なくとも３以上のノードを含む第１ノードグループが予め定義されている。第１ノードグループのノードそれぞれは、その管理しているストレージデバイスに格納するデータを、第１ノードグループに属する他ノードに送信する。第１ノードは、第１ノードグループの２以上の他ノードから受信したデータの組み合わせを使用して冗長コードを生成し、上記生成した冗長コードを、上記冗長コードを生成したデータを格納するストレージデバイスとは異なるストレージデバイスに格納する。第１のノードが生成する冗長コードのうち、少なくとも二つの冗長コードのデータ組み合わせは、構成するデータの論理アドレスの組み合わせが異なる、分散型ストレージシステム。

Description

分散型ストレージシステム

参照による取り込み

　本出願は、２０１４年９月３０日に出願された国際出願であるＰＣＴ／ＪＰ２０１４／０７６１０５の優先権を主張し、その内容を参照することにより、本出願に取り込む。

　本発明は、分散型ストレージシステムに関する。

　ＩＴ投資額が横ばいになる一方で、データ量の増大化が進んでいる。ストレージのコスト低減がますます重要となってきている。例えば、分散型ストレージシステムの一つとして、多数の汎用サーバをネットワークにより接続しストレージプールを生成する、ＳｅｒｖｅｒＳＡＮ型ストレージシステムが、将来に普及すると見られている。特に、大規模なビッグデータ分析等のためにサーバノードに高速なＳＳＤを搭載し高性能な分析を狙うシステムにおいて、ＳｅｒｖｅｒＳＡＮ型ストレージシステムは、有効なソリューションであると考えられる。

　本技術分野の背景技術として、米国特許７５４６３４２号（特許文献１）がある。この公報には、「Ｗｅｂサイトに関連付けられる各ファイルの相対的重要度を計算する。この相対的重要度を用い、サーバ・アレイ、ピア・ツー・ピア・ネットワークなどの、コンピュータ・クラスタ内の複数デバイスに分配されるコンテンツの複数の部分集合を計算する。この部分集合は、１つまたは複数のファイルの一部分を含むパケットにイレージャ・コーディング方式を使用して作成された符号化メッセージを含むことができる。ファイル取得時、一定数のはっきりと識別可能な符号化メッセージがこの方式に基づいてデバイスから取得される。ファイルはこのメッセージを使用して再作成される。複数デバイスのコンテンツ保持により、Ｗｅｂサイトは、著しく高速に取得され、どのコンピューティング・デバイスも大量の記憶域または帯域幅を必要とせずに、信頼性が向上する。」と記載されている（要約参照）。

米国特許７５４６３４２号

　従来のＳｅｒｖｅｒＳＡＮ型ストレージシステムは、サーバノードそれぞれに直結されたローカルストレージデバイスを最終格納場所として使用し、ライトデータ及びその冗長データを複数サーバノードに分散させることでデータを保護する。具体的には、ホストからのライトデータを複数データブロックに分割し、分割したデータブロックからＥｒａｓｕｒｅ　Ｃｏｄｅにより冗長コードを生成し、複数サーバノードに分割したデータブロックと冗長コードとを均等分散させる。

　このように、従来のＳｅｒｖｅｒＳＡＮ型ストレージシステムは、ホストから受信したライトデータを、複数サーバノードに分散させる。従って、アプリケーションプログラムが、ＳｅｒｖｅｒＳＡＮ型ストレージからデータを読み出すとき、データブロックがサーバノード間のネットワーク上を転送される。よってネットワークのスループットがボトルネックとなって、データへのアクセスレイテンシがネットワークを介さない場合よりも増加する場合がある。

　本発明の代表的な一例は、分散型ストレージシステムであって、ネットワークを介して通信する複数のノードと、前記分散型ストレージシステムは更に複数のストレージデバイスと、を含み、少なくとも３以上のノードを含む第１ノードグループが予め定義されており、前記第１ノードグループのノードそれぞれは、その管理しているストレージデバイスに格納するデータを、前記第１ノードグループに属する他ノードに送信し、前記第１ノードグループの第１ノードは、前記第１ノードグループの２以上の他ノードから受信したデータの組み合わせを使用して冗長コードを生成し、前記第１のノードは、前記生成した冗長コードを、前記冗長コードを生成したデータを格納するストレージデバイスとは異なるストレージデバイスに格納し、前記第１のノードが生成する冗長コードのうち、少なくとも二つの冗長コードのデータ組み合わせは、構成するデータの論理アドレスの組み合わせが異なる。

　本発明の一態様によれば、ストレージシステムにおいて、高容量効率と高信頼性の並立を図ることができる。

分散型ストレージシステムのライト処理の概要を示す。分散型ストレージシステムにおける複数保護レイヤのマッピングイメージ例を示す。分散型ストレージシステムのシステム構成例を示す。分散型ストレージシステムの制御のための情報を示す。仮想ボリューム管理テーブルの構成例を示す。プールボリューム管理テーブルの構成例を示す。ドライブ管理テーブルの構成例を示す。ドライブ状態管理テーブルの構成例を示す。ノード状態管理テーブルの構成例を示す。サイト状態管理テーブルの構成例を示す。ページマッピングテーブルの構成例を示す。ページ負荷頻度テーブルの構成例を示す。ページ負荷分布テーブルの構成例を示す。静的マッピングテーブルの構成例を示す。ジオ静的マッピングテーブルの構成例を示す。コンシステントハッシングテーブルの構成例を示す。ログ構造化マッピングテーブルの構成例を示す。ローカル領域制御テーブル２１４の構成例を示す。キャッシュ情報の例を示す。サイト保護レイヤのマッピングイメージを示す。分散型ストレージシステムにおける、ノードの状態遷移を示す。分散型ストレージシステムにおける、サイトの状態遷移を示す。分散型ストレージシステムの一つノードにおける、仮想プロビジョニングレイヤの論理構成例を示す。分散型ストレージシステムにおける複数ノードのページマッピングの例を示す。分散型ストレージシステムのリード処理のフローチャートを示す。同期ライト処理のフローチャートを示す。非同期ライト処理のフローチャートを示す。デステージ処理のフローチャートを示す。容量枯渇管理の処理のフローチャートを示す。容量枯渇管理の処理の概念を示す。退避リビルド処理のフローチャートを示す。データリシンク処理のフローチャートを示す。再配置及びリバランス処理のフローチャートを示す。再配置における自己閾値の決定方法の一例を示す。再配置における自己閾値の決定方法の一例を示す。構成変更処理のフローチャートを示す。ノードを追加した場合のストライプタイプの追加及びストライプの再配置一例を示す。コマンドラインの管理Ｉ／Ｆの一例を示す。分散型ストレージシステムのＧＵＩの管理Ｉ／Ｆの例を示す。分散型ストレージシステムのハードウェア構成例を示す。実施形態２において、冗長化のためのノード間の転送を効率化する方法を示す。実施形態２において、図２９を参照して説明した冗長化のためのノード間の転送を効率化する方法における、データ復元方法を示す。実施形態３において、分散型ストレージシステムのハードウェア構成例を示す。実施形態３の概要を示す。実施形態３において、ストレージシステムの制御のためにドライブで管理するテーブル構造を示す。実施形態３において、計算機ノードとフラッシュドライブとの間の通信インタフェースを示している。実施形態３において、計算機ノードがＤドライブから最新データを読み込む処理のフローチャートを示す。実施形態３において、旧データのリード処理を示している。実施形態３において、計算機ノードがＤドライブへデータを書き込む処理のフローチャートを示す。実施形態３において、同期ライト処理において各ドライブへデータのライト処理を並行に実施した場合の処理フローを示している。実施形態３において、ガベージコレクション処理のフローチャートを示す。実施形態４において、分散型ストレージシステムのハードウェア構成例を示す。実施形態４の概要を示す。実施形態４において、計算機ノードとドライブとの間の通信インタフェースを示している。実施形態４での同期ライト処理のフローチャートを示している。実施形態４での非同期ライト処理のフローチャートを示している。実施形態４でのガベージコレクション処理のフローチャートを示している。

　本発明の実施形態について、図面を参照して説明する。尚、以下に説明する実施形態は特許請求の範囲にかかる発明を限定するものではなく、また実施形態の中で説明されている特徴の組み合わせの全てが発明の解決手段に必須であるとは限らない。

　以下の説明では、「テーブル」、「リスト」、「キュー」等の表現にて各種情報を説明することがあるが、各種情報は、これら以外のデータ構造で表現されていても良い。データ構造に依存しないことを示すために「ＸＸテーブル」、「ＸＸリスト」等を「ＸＸ情報」と呼ぶことがある。各情報の内容を説明する際に、「識別情報」、「識別子」、「名」、「ＩＤ」、「番号」等の表現を用いるが、これらについてはお互いに置換が可能である。

＜実施形態１＞
概要
　本実施形態は、分散型ストレージシステムを開示する。分散型ストレージシステムは、それぞれがストレージデバイスを含む複数の計算機ノードをネットワークにより接続して構成される。分散型ストレージシステムは、複数の計算機ノードのストレージデバイスによってストレージプールを実現する仮想的なストレージシステムを実現する。

　一例の分散型ストレージシステムにおいて、計算機ノードは、ホストからのライトデータを自系のストレージデバイスに格納し、さらに、計算機ノード障害時のデータ保護のために、当該ライトデータを他の計算機ノードに転送する。ここで、当該他の計算機ノードを転送先計算機ノードと呼ぶ。

　転送先計算機ノードは、複数の異なる計算機ノードから転送されたライトデータから、冗長コードを生成する。転送先計算機ノードは、生成された冗長コードを自系のストレージデバイスに格納する。

　このように、なるべくデータをライト要求を受けたノード内に配置することで、読み出し時のノード間通信を不要とし、高速な読み出しを可能とする。一方で、計算機ノード間の冗長コードをライト要求を受けたノードとは異なるノードにて生成することで、小オーバヘッドでのデータ保護を実現する。特に、信頼性の低い多数のノードにて分散型ストレージシステムを構築する場合には、読み出し性能を維持しつつも冗長性を担保する本願構成は有効である。

　また、特に分析系のアプリケーションを本発明による分散型ストレージシステムで動作させる場合、各計算機ノードは、分析対象データを自ノードの記憶領域にまとまって格納できているケースが多い。これにより、データ分析のためのロード時間が削減され、ビジネスアジリティが向上し、ストレージコストが低減される。

　一例において、分散型ストレージシステムは仮想ボリュームをホストに提供する。分散型ストレージシステムは、ライトアクセスがあった仮想ページに対して、プールボリュームから論理ページを割り当てる。プールボリュームは論理ボリュームであり、プールボリュームの論理記憶領域に対して、ストレージデバイスの物理記憶領域が割り当てられている。

　計算機ノードは、分散型ストレージシステムのネットワーク帯域と、ホストからの仮想ページ毎の当該計算機ノードへのアクセス頻度に基づき、自系のストレージデバイスから論理ページを割り当てる仮想ページを選択する。例えば、計算機ノードは、分散型ストレージシステムのネットワーク帯域に基づき閾値を決定し、当該閾値よりアクセス頻度が高い論理ページを自系のストレージデバイスに配置する。これにより、ネットワークボトルネックを回避しつつ、高速にページアクセス可能なページ配置を実現できる。

　一例において、計算機ノードは、仮想ページのロケーションをアプリケーションプログラムやユーザが指定するためのインタフェースを有する。仮想ページは、例えば、仮想ボリュームの論理アドレスで指定される。仮想ページのロケーションは、当該仮想ページのデータが格納される計算機ノードで示される。仮想ページのロケーションを指定するインタフェースを設けることで、仮想ページ提供先に最適化したページ配置を実施することができる。

　本実施形態において、分散型ネットワークシステムは、上記複数構成例の全てを同時に含むことができ、また、一部の構成のみを含んでいてもよい。

用語の説明
　本開示において、ストレージデバイスは、１台のＨＤＤやＳＳＤ等の１台のストレージドライブ及び複数台のストレージドライブを含むＲＡＩＤ装置、及び複数のＲＡＩＤ装置を含む。ストライプ又はストライプデータは、データ保護のための冗長コードの生成の元となるデータユニットである。ストライプを、冗長コードと差別化するためにユーザデータと呼ぶことがある。ストライプは、計算機ノード内のストレージデバイスに格納されると共に、他の計算機ノードにおける冗長コードの生成において使用される。

　ストライプタイプは、冗長コードを生成するストライプのクラスである。ストライプが属するストライプタイプは、例えば、当該ストライプの論理アドレスと当該ストライプを格納する計算機ノードとによって決定される。ストライプタイプの識別子であるストライプタイプ番号は、対応する計算機ノードのグループを示す。一つのストライプは、異なる保護レイヤそれぞれのストライプタイプに属することができる。ホストは、ストレージシステムにアクセスする計算機、当該計算機で動作するプロセッサ又は当該プロセッサが実行するプログラムである。

　図１は、本実施形態の一例に係る分散型ストレージシステムのライト処理の概要を示す。計算機ノード１０１Ａ、１０１Ｂ及び１０１Ｃは同一計算機ドメイン（以下においてドメインとも呼ぶ）に含まれる。以下説明する例において、ドメインはサイトと対応づけられているとする。計算機ノード１０１Ｄ、計算機ノード１０１Ｅは、他の計算機ノードとは異なるサイトに配置されている。計算機ノード１０１Ａ～１０１Ｅは、ネットワークを介して通信する。以下において、計算機ノードを、単にノードとも呼ぶ。

　ノード１０１Ａ～１０１Ｅの各計算機ノードは、キャッシュ１８１及びストレージドライブ１１３を含む。ノード１０１Ａ～１０１Ｅの各ノードは、ボリューム１３０３を提供する。

　ノード１０１Ａは、ホストから受信したライトデータＤＡＴＡ１（１５０１Ａ）を自系のキャッシュ１８１に格納し、さらに、自系のストレージドライブ１１３に格納する。ライトデータＤＡＴＡ１はストライプである。

　ノード１０１Ａは、ライトデータＤＡＴＡ１からノード冗長コードＰを生成し、自系のストレージドライブ１１３に格納する。ノード冗長コードは、自系のストレージデバイスに格納されるデータユニットから生成される冗長コードであり、符号Ｐで示される。ノード１０１Ａは、自系のキャッシュ１８１内のライトデータＤＡＴＡ１を、他のノード１０１Ｂのキャッシュ１８１に転送する。

　ノード１０１Ｃは、外部装置から受信したライトデータＤＡＴＡ２（１５０１Ｂ）を自系のキャッシュ１８１に格納し、さらに、自系のストレージドライブ１１３に格納する。ライトデータＤＡＴＡ２はストライプである。ノード１０１Ｃは、ライトデータＤＡＴＡ２からノード内冗長コードＰを生成し、自系のストレージドライブ１１３に格納する。ノード１０１Ｃは、自系のキャッシュ１８１内のライトデータＤＡＴＡ２を、他のノード１０１Ｂのキャッシュ１８１に転送する。

　ノード１０１Ｂは、ノード障害時のデータ保護のために、自系のキャッシュ１８１に格納されているデータＤＡＴＡ１、ＤＡＴＡ２から、サイト冗長コードＱ（１５０２Ｂ）を生成し、自系のストレージドライブ１１３に格納する。サイト冗長コードは、サイト内におけるノード間冗長コードであり、符号Ｑで示される。サイト冗長コードＱは、ノード冗長コードＰとは異なる保護レイヤに属する。

　ノード１０１Ｅは、ホストから受信したライトデータＤＡＴＡ３（１５０１Ｃ）を自系のキャッシュ１８１に格納し、さらに、自系のストレージドライブ１１３に格納する。ライトデータＤＡＴＡ３はストライプである。ノード１０１Ｅは、ライトデータＤＡＴＡ３からノード冗長コードＰを生成し、自系のストレージドライブ１１３に格納する。

　ノード１０１Ａは、自系のキャッシュ１８１内のライトデータＤＡＴＡ１を、他のノード１０１Ｄのキャッシュ１８１に転送する。ノード１０１Ｅは、自系のキャッシュ１８１内のライトデータＤＡＴＡ３を、他のノード１０１Ｄのキャッシュ１８１に転送する。

　ノード１０１Ｄは、ノード障害時のデータ保護のために、自系のキャッシュ１８１に格納されているデータＤＡＴＡ１、ＤＡＴＡ３から、ジオ冗長コードＲ（１５０２Ｃ）を生成し、自系のストレージドライブ１１３に格納する。ジオ冗長コードは、異なるサイトのノード間の冗長コードであり、符号Ｒで示される。ジオ冗長コードＲは、ノード冗長コードＰ及びサイト冗長コードＱと異なる保護レイヤに属する。

　図２は、分散型ストレージシステムにおける複数保護レイヤのマッピングイメージ例を示す。図２は、同一サイトのノード間で冗長化しつつ、サイト間で冗長化を実施するイメージを示している。例えば、データセンタ内のノード間で第１の冗長化が図られ、さらに、別の拠点間との冗長化も図ることで多重のレイヤでデータを保護して、システムの信頼性を向上させることができる。図２において、一部要素のみが符号で示されており、同一種類の要素の符号は一部省略されている。図２において、四角柱はノードを表し、破線矩形はサイト（ドメイン）を表し、ノード内の矩形はストライプ又はストライプのアドレス（データ位置）を表す。図２は、４つのサイト１０２を示し、各サイトにおいて４つのノードが配置されている。図２は、複数ストライプから生成される冗長コードを示していない。

　ストライプ１０３における数字（Ｘ＿Ｙ）は、当該ストライプ１０３が属するストライプタイプの識別子を示す。Ｘはサイト内のノード間ストライプタイプ（サイトストライプタイプ）の識別子であり、Ｙはサイト間のストライプタイプ（ジオストライプタイプ）の識別子である。

　一つのストライプ１０３は、一つのサイトストライプタイプ及び一つのジオストライプタイプに属する。例えば、ノード１０１Ａ１が格納するストライプ１＿Ａは、サイトストライプタイプ１００１及びジオストライプタイプ１００２に属している。

　サイトストライプタイプ１００１に属するストライプは、ノード１０１Ａ１のストライプ１＿Ａ、ノード１０１Ａ２のストライプ１＿Ｄ、ノード１０１Ａ３のストライプ１＿Ｃである。これらストライプを保持していない同一サイト内のノード１０１Ａ４は、これらストライプの冗長コードを生成し、保持する。

　ジオストライプタイプ１００２に属するストライプは、ノード１０１Ａ１のストライプ１＿Ａ、ノード１０１Ｂ１のストライプ１＿Ａ、ノード１０１Ｃ２のストライプ２＿Ａである。これらノードと異なるサイトのノード１０１Ｄ４は、これらストライプの冗長コードを生成し、保持する。

　上記構成において、複数ノードが、それぞれ、受信し、保持するストライプ（データユニット）を一つの転送先ノードに転送し、当該転送先ノードが転送されたデータユニットから冗長コードを生成し保持する。ストライプと冗長コードが異なるノードに格納されており、ノード障害に対するデータ保護を実現する。

　ホスト命令を受信したノードは、サイト冗長コード又はジオ冗長コードを生成するために旧データを読み出すことなく、受信したライトデータを他ノードに送信する。したがって、ライト命令に対するレスポンス性能が向上する。また、冗長コード生成のためのストライプ移動はキャッシュ間でなされ、ドライブ１１３が介在しないため、ドライブ１１３がフラッシュ媒体を使用する場合、ライト量低減により寿命を向上できる。

　ノードは、ホストから受信したストライプを分割することなく自系のストレージデバイスに格納するため、リードにおけるレスポンスタイム及びネットワークトラヒックを低減する。また、冗長コードの転送が不要であり、ネットワークトラヒックを低減する。

　さらに、上記構成は、一つのストライプが複数の保護レイヤに属するため、システムの障害耐性を高めることができる。なお、分散型ストレージシステムは、サイト内又はサイト間のノード間冗長コードのみを生成する単一保護レイヤで構成されていてもよい。

　図３は、分散型ストレージシステムのシステム構成例を示す。ノード１０１は、例えば一般的なサーバ計算機の構成を有している。ノード１０１のハードウェア構成は特に限定されない。ノード１０１は、ネットワーク１０３を介して他のノード１０１とポート１０６を通じて接続する。ネットワーク１０３は、例えばＩｎｆｉｎｉＢａｎｄや、イーサネットなどにより構成される。

　複数のノード１０１は、ドメイン１０２を形成する。ドメイン１０２は、例えば地理的な地域と対応させてもよいし、仮想的又は物理的なネットワーク１０３のトポロジと対応させてもよい。ネットワーク１０４は、複数のドメイン１０２を接続する。以下において、ドメインは地理的な離れたサイトに対応づけられているとする。

　ノード１０１の内部構成は、内部ネットワーク１１２を介してポート１０６、プロセッサパッケージ１１１、ディスクドライブ（以下においてドライブとも呼ぶ）１１３を接続する。プロセッサパッケージ１１１は、メモリ１１８、プロセッサ１１９を含む。

　メモリ１１８は、プロセッサ１１９がリードやライト命令を処理し、またストレージの機能を実行する上で、必要な制御用の情報を格納し、またストレージのキャッシュデータを格納する。また、メモリ１１８は、例えばプロセッサ１１９により実行するプログラムを格納する。メモリ１１８は、揮発性のＤＲＡＭであってもよいし、不揮発のＳＣＭ（Ｓｔｏｒａｇｅ　Ｃｌａｓｓ　Ｍｅｍｏｒｙ）などを用いてもよい。

　ドライブ１１３は、例えば、ＦＣ（Ｆｉｂｒｅ　Ｃｈａｎｎｅｌ）、ＳＡＳ（Ｓｅｒｉａｌ　Ａｔｔａｃｈｅｄ　ＳＣＳＩ）、ＳＡＴＡ（Ｓｅｒｉａｌ　Ａｄｖａｎｃｅｄ　Ｔｅｃｈｎｏｌｏｇｙ　Ａｔｔａｃｈｍｅｎｔ）などのインタフェースを持つハードディスクドライブや、ＳＳＤ（Ｓｏｌｉｄ　Ｓｔａｔｅ　Ｄｒｉｖｅ）などにより構成する。

　ＮＡＮＤ、ＰＲＡＭ、ＲｅＲＡＭなどのＳＣＭを用いてもよいし、揮発性のメモリを用いてもよい。揮発性メモリを使用する場合、バッテリによってストレージデバイスを不揮発化してもよい。

　前述したさまざまな種類のドライブは、性能が異なる。例えば、ＨＤＤと比較し、ＳＳＤのスループット性能が高い。ノード１０１は、複数の種類のドライブ１１３を含む。本例のノード１０１は、異なる種類のドライブ１１３を近い性能を持つドライブ群に分類して、階層１１５、１１６を形成する。

　階層間の関係は、階層の性能により定義される。性能は、アクセス性能や耐障害性能を含む。以下に説明する例において、Ｔｉｅｒ１からＴｉｅｒ２、Ｔｉｅｒ３の順で、階層のアクセス性能が低下する。また、以下に説明する例において、各階層におけるドライブ群のそれぞれが、ＲＡＩＤを構成する。なお、図３が例示する階層数は２であるが、階層数は設計に依存する。また、高アクセス性能の階層をキャッシュとして使用してもよい。ドライブ、ＲＡＩＤ、階層及びそれらの集合は、それぞれストレージデバイスである。

　図４は、分散型ストレージシステムの制御のための情報を示す。メモリ１１８は、図４に示す情報に加え、ストレージ機能を実現するストレージプログラム、ＯＳ、インタフェースプログラムを含む、各種プログラムを格納する。メモリ１１８は、さらに、業務を実行するアプリケーションプログラムを格納することがある。

　保護レイヤ情報２０１は、データ保護に関する情報である。仮想化プロビジョニング情報２０２は、仮想ボリュームのプロビジョニングに関する情報である。キャッシュ情報２０４は、キャッシュ１８１に関する情報である。構成情報２０３は、分散型ストレージシステムの構成に関する情報である。

　保護レイヤ情報２０１は、保護レイヤ番号１、番号２、番号３それぞれの、静的マッピングテーブル２１０、２１１、２１２を含む。保護レイヤ情報２０１は、さらに、ログ構造化マッピングテーブル２１３と、ローカル領域制御テーブル２１４とを含む。

　仮想化プロビジョニング情報２０２は、ページマッピングテーブル２１５と、ページ負荷頻度テーブル２１６と、ページ負荷分布テーブル２１７を含む。構成情報２０３は、仮想ボリューム管理テーブル２１８とプールボリューム管理テーブル２１９と、ドライブ管理テーブル２２０とを含む。構成情報２０３は、さらに、ドライブ状態管理テーブル２２１と、ノード状態管理テーブル２２２と、サイト状態管理テーブル２２３とを含む。

　上述した情報の全部又は一部のコピーは、ドライブ１１３に同期又は非同期に保存されてもよい。ノード１０１は、例えばプール毎に上記情報を保持してもよい。一つのプールは、１又は複数論理ボリュームで構成される。この論理ボリュームをプールボリュームとも呼ぶ。一つのプールは、１又は複数階層で構成される。以下に説明する例では、プールは３階層で構成される、つまり、３階層のプールボリュームで構成される。プールボリュームの実体は、ドライブ１１３の記憶領域である。プールボリュームは他のノード１０１のドライブの記憶領域が割り当てられることも可能である。

　以下において、ノード１０１が保持する情報を示すテーブルの構成例を説明する。各テーブルにおいて、一部のエントリのみが示されている。各テーブルにおいて、空白のセルは、データの記載が省略されたセルである。テーブルのセルにおいて、「０ｘ」は、１６進数の数字を示す。ドライブ番号はノード内で一意であり、ノード番号はサイト内で一意である。サイト番号はシステム内で一意である。

　図５Ａ～図５Ｆは、構成情報２０３に含まれる情報を示すテーブルの構成例を示す。図５Ａ～図５Ｃは、異なる記憶リソース種別の管理情報を示す。図５Ａは、仮想ボリューム管理テーブル２１８の構成例を示す。仮想ボリューム管理テーブル２１８は、仮想ボリュームの情報を示す。

　本例において、仮想ボリューム管理テーブル２１８は、当該情報２１８を保持するノード１０１が提供する仮想ボリュームの情報示す。ノード１０１は、提供する仮想ボリュームへのアクセスを受け付ける。仮想ボリューム管理テーブル２１８は、障害発生にそなえ、自ノードがオーナではない仮想ボリュームの情報を保持してもよい。

　仮想ボリューム管理テーブル２１８は、各仮想ボリュームのサイズ（容量）、各仮想ボリュームを提供するノード（オーナノード）のノード番号のリストを含む。さらに、保護レイヤそれぞれの冗長コードの生成及び書き込みが、ライトデータの自系のストレージデバイスへの書き込みと同期か非同期かを示す情報を含む。仮想ボリュームのサイズは、割り当てられている論理ページの総量ではなく、仮想ボリュームの仮想容量（最大容量）を示す。同期／非同期の情報は、保護レイヤ毎に与えられる。

　図５Ｂは、プールボリューム管理テーブル２１９の構成例を示す。プールボリューム管理テーブル２１９は、プールボリュームの情報を示す。本例において、プールボリューム管理テーブル２１９は、当該情報２１９を保持するノード１０１及び当該ノード１０１が属する他ノード１０１が提供するプールボリュームの情報示す。プールボリューム管理テーブル２１９は、各プールボリュームのサイズ（容量）、各プールボリュームを提供するノードのノード番号の情報を含む。

　図５Ｃは、ドライブ管理テーブル２２０の構成例を示す。ドライブ管理テーブル２２０は、各プールボリュームに割り当てられるドライブを示す。本例において、ドライブ管理テーブル２２０は、当該情報２２０を保持するノード１０１が含む自系のドライブ１１３の情報示す。

　ドライブ管理テーブル２２０は、プールボリューム毎に、ドライブの種類（ＳＳＤやＮＬ－ＳＡＳドライブなど）、ストライピングしているドライブ番号の組（ＲＡＩＤを構成するドライブ番号の組）、ドライブのサイズ（容量）の情報を持つ。ストライピングを実施しない場合、プールボリュームに対して一つのドライブのみが割り当てられる。なお、一つのドライブの異なる領域は、異なるプールボリュームに割り当てられ得る。

　図５Ｄ～図５Ｆは、ノード１０１のそれぞれが保持する、分散型ストレージシステムにおける障害管理情報を示す。

　図５Ｄは、ドライブ状態管理テーブル２２１の構成例を示す。ドライブ状態管理テーブル２２１は、ノード１０１内の自系のドライブ１１３それぞれの状態及びエラーカウントを示す。

　図５Ｅは、ノード状態管理テーブル２２１の構成例を示す。ノード状態管理テーブル２２１は、自系サイト１０２における他ノード１０１それぞれの状態及びエラーカウントを示す。ノード１０１の自系サイト１０ｃは、当該ノード１０１が属するサイト１０２である。ノード１０１は、他ノード１０１との通信においてエラーを検出すると、エラーカウントをインクリメントする。

　図５Ｆは、サイト状態管理テーブル２２３の構成例を示す。サイト状態管理テーブル２２２は、サイト毎の状態及びエラーカウントを示す。本例において、ノード１０１は他サイト１０２の代表ノードとのみ通信できるとする。そのため、代表ノード１０１のエラーは、当該サイトのエラーを意味する。

　ノード１０１のプロセッサ１１９は、自系のドライブ１１３又は他ノード１０１との通信においてエラーを検出すると、保持する管理情報２２１～２２３においてエラーカウントをインクリメントする。

　いずれかのハードウェアリソース（ドライブ、ノード又はサイト）におけるエラーカウントが第１閾値に達すると、プロセッサ１１９は、当該リソースの状態を正常状態から警告状態に変化させる。さらに、エラーカウントが第１閾値に達すると、プロセッサ１１９は、当該リソースの状態を警告状態から閉塞状態に変化させる。警告状態と閉塞状態は、異常状態である。

　各ノード１０１は、いずれかのハードウェアリソースの異常状態を検出すると、当該情報を他のノード１０１に通知する。具体的には、ノード１０１は、所属サイト１０２内の全ノード１０１及び他サイト１０２の代表ノード１０１に通知する。代表ノード１０１は、所属サイト１０２内の他のノードに当該情報を通知する。これにより、異常状態ハードウェアリソースの情報をノード間で共有できる。異常状態ドライブの情報はノード間で共有されなくてもよい。

　ノード１０１は、エラーカウントの情報を共有してもよい。例えば、各ノード１０１は、他ノード又は他サイトとの通信エラーを検出すると、自系の管理情報を更新すると共に、当該更新情報を他ノード１０１にブロードキャストする。ノード１０１は、自ノードのエラーカウントに加え、他ノード１０１によるエラーカウントに基づき、異常状態の判定を行ってもよい。

　ノード１０１が他サイト１０２の各ノード１０１と通信する構成において、ノード１０１は、他のサイト１０２のノード１０１との通信エラーをカウントしてもよい。サイトエラーカウントは、例えば、当該サイト１０２における全ノード１０１のエラーカウントに総計である。

　図６Ａ～図６Ｃは、仮想化プロビジョニング情報２０２に含まれる情報を示す。図６Ａは、ページマッピングテーブル２１５の構成例を示す。ページマッピングテーブル２１５は、仮想ボリュームの仮想ページとプールボリュームの論理ページとの対応関係を保持する。

　本例において、ページマッピングテーブル２１５は、当該情報２１５を保持するノード１０１が提供する仮想ボリュームの情報を保持している。仮想ページは、後述する自系のプールボリューム１３０３Ｃを介して又は直接に、他ノード１０１のプールボリューム１３０３Ｂの論理ページに割り当てられることがある。ページマッピングテーブル２１５は、仮想ページと、自系プールボリューム１３０３Ｃ又は他ノード１０１のプールボリューム１３０３Ｂとの関係を示す。

　ページマッピングテーブル２１５は、仮想ボリュームの仮想ページの先頭ＬＢＡ（Ｌｏｇｉｃａｌ　Ｂｌｏｃｋ　Ａｄｄｒｅｓｓ）とアドレス範囲と、仮想ページの先頭ＬＢＡに対応するプールボリュームの論理ページの先頭ＬＢＡと、を保持する。

　図６Ｂは、ページ負荷頻度テーブル２１６の構成例を示す。ページ負荷頻度テーブル２１６は、仮想ページ毎のＩ／Ｏ頻度（アクセス頻度）の履歴を保持する。具体的には、仮想ボリュームの仮想ページの先頭ＬＢＡ及びアドレス範囲と、当該領域に対するアクセス頻度と、を保持する。

　ページ負荷頻度テーブル２１６は、プールボリュームからユーザデータ（ライトデータ）を格納する論理ページが割り当てられている仮想ページの情報を保持する。したがって、ページ負荷頻度テーブル２１６は、仮想ページに割り当てられている論理ページのアクセス頻度も示す。ページ負荷頻度テーブル２１６は、当該テーブル２１６を保持するノード１０１が提供する仮想ボリュームの情報を保持する。また、ページ負荷頻度テーブル２１６は、当該テーブル２１６を保持するノードが自ノード及び他ノードから受けたアクセスの情報を保持する。

　アクセス頻度の情報は、アクセス元のノード毎に取得、管理されてもよく、リードアクセスとライトアクセスとに分けて取得、管理されてもよい。ノード１０１は、シーケンシャルとランダムアクセスを分離してアクセス頻度の情報を取得、管理してもよいし、複数の計測周期で、アクセス頻度の情報を取得、管理してもよい。

　図６Ｃは、ページ負荷分布テーブル２１７の構成例を示す。ページ負荷分布テーブル２１７は、仮想ページ毎のアクセス頻度を複数レベルに分割し、レベル毎のページ量を示す。つまり、ページ負荷分布テーブル２１７は、アクセス頻度（Ｉ／Ｏ頻度）に対するページ量の分布を示す。ページ負荷分布テーブル２１７は、ページ負荷分布の履歴を示す。

　ノード１０１は、複数の保護レイヤそれぞれのページ負荷分布テーブル２１７を保持する。例えば、ページ負荷分布テーブル２１７は、ノード内でのページ毎のアクセス頻度の情報の他、サイト内の全ノードにおけるページ毎のアクセス頻度の情報、複数サイトに跨るシステム内の全ノードにおけるページ毎のアクセス頻度の情報を保持してもよい。ノード１０１は、自ノード及び他のノードから取得したページ負荷頻度テーブル２１６から、ページ負荷分布テーブル２１７を生成できる。

　例えば、複数ノード１０１が一つの仮想ボリュームを提供する場合、複数ノード１０１それぞれが、同一仮想ページに対するアクセスを受信する。したがって、仮想ボリュームのオーナノード全てにおける一つの仮想ページへのアクセスの総計が、当該仮想ページへの全アクセスを示す。

　ページ負荷分布テーブル２１７は、ページ負荷頻度テーブル２１６と比較して情報量が少なく、基本的にノード１０１の記憶容量（論理ページ量）に依存しない。したがって、ページ負荷分布テーブル２１７は、多数のノード１０１間で共有することができる。さらに、複数ノード１０１でのアクセス頻度レベル毎のページ数を加算することで、サイト全体又はシステム全体のページ負荷分布情報など、複数ノード１０１に跨るページ負荷分布を生成することができる。アクセス元のノード１０１毎にページ負荷分布テーブル２１７を作成してもよい。

　ページ負荷頻度テーブル２１６は、高アクセス頻度（高負荷）のページの上位リスト（例えばＬｏｓｓｙ　Ｃｏｕｎｔ　Ｍｅｔｈｏｄを使用）と、ノード又はノード群の記憶領域を所定区間数で分割して得られる分割区域毎のアクセス頻度（ページ負荷）のリストとの、２種類のリストで構成するのが効率的である。高負荷ページの上位リストのみでは、ＯＬＴＰデータベースによく見られるランダム負荷が広い場合に、上位リストが飽和し、リストに含めるべきページが含まれない場合がある。

　一方で、記憶領域の分割区域毎のページ負荷のリストのみでは、特定のページの負荷が非常に高く、メモリ制約により区域数が少ない場合、区域の幅が広すぎてページ負荷が平滑化されてしまい、ページ毎の負荷の特徴が失われてしまう場合がある。したがって、上記２種類のリストを共に持つのが効率的である。

　ノード１０１は、所定周期（例えば、１週間）毎の履歴テーブル２１６、２１７を持ってもよい。本例は、ブロックストレージにおけるマッピングテーブル（ＬＢＡで管理）について記載しているが、一般的に知られたファイルストレージ（例えばＮＦＳ／ＣＩＦＳ：Ｎｅｔｗｏｒｋ　Ｆｉｌｅ　Ｓｙｓｔｅｍ／Ｃｏｍｍｏｎ　Ｉｎｔｅｒｎｅｔ　ＦｉｌｅＳｙｓｔｅｍ）やオブジェクトストレージ（例えばＲＥＳＴ：Ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ　Ｓｔａｔｅ　Ｔｒａｎｓｆｅｒ）においても、ノード１０１は、同様な情報を保持することできる。

　ファイルストレージにおいて、管理情報は、ファイルとページを対応させてもよいし、ファイルを分割した小領域をページと対応させてもよい。また、オブジェクトストレージにおいて、管理情報は、オブジェクトとページ対応させてもよいし、オブジェクトを分割した小領域をページと対応させてもよい。

　図７Ａ～７Ｃは、データ保護レイヤ情報２０１における、静的マッピングテーブルの例を示す。保護レイヤ番号１はノード１０１内の保護レイヤであり、各ノード１０１が、自ノードのノード静的マッピングテーブル２１０を保持している。ノード静的マッピングテーブル２１０の図は省略した。図７Ａ～７Ｃのテーブルは、例えば、サイト番号０のサイトに属しノード番号０のノード１０１に、保持される。

　図７Ａは、保護レイヤ番号２（サイト）の静的マッピングテーブル２１１の構成例を示す。サイト静的マッピングテーブル２１１は、サイト１０２内のノード１０１間で共有される情報である。サイト静的マッピングテーブル２１１は、サイトストライプタイプ番号毎に、対応するストライプ（ユーザデータ／ライトデータ）を格納するデータノードのノード番号と、ストライプから生成される冗長コードを格納する冗長コードノードのノード番号の関係を保持する。

　サイトストライプタイプ番号は、サイト内のストライプタイプの識別情報である。ストライプタイプは、ストライプのクラスであり、ストライプタイプ内の複数ストライプから１又は複数冗長コードが生成される。ストライプは、予め定められたサイズのデータユニットである。

　各ストライプが属するストライプタイプの決定方法及び冗長コードの生成方法は後述する。ストライプタイプ番号は、ストライプタイプに含まれるユーザデータ及び冗長コードを格納するノード１０１のグループも示す。

　サイトストライプに属する異なるデータノードからの複数ストライプから、冗長コードが生成される。図７Ａの例において、二つの冗長コードが生成され、それぞれ異なるノード１０１に格納される。冗長コードの数は設計に依存する。複数冗長コードは、例えば、Ｅｒａｓｕｒｅ　Ｃｏｄｉｎｇにより生成される。サイト静的マッピングテーブル２１１は、メモリ上の制約やセキュリティ上の制約がなければ、サイト間で共有されてもよい。

　本例において、一つのストライプは、単一のサイトストライプタイプに属する。図７Ａに例示するように、一つのノードが格納するストライプは、異なるストライプタイプに属し得る。例えば、図７Ａの例において、ノード０ｘ００が格納するあるストライプはサイトストライプタイプ０ｘ００００に属し、他のストライプはサイトストライプタイプ０ｘ０００１に属する。

　図７Ｂ、図７Ｃは、保護レイヤ番号３（ジオ）の静的マッピングテーブル２１２に含まれる、ジオ静的マッピングテーブル２１２Ａ及びコンシステントハッシングテーブル２１２Ｂの構成例を示す。ジオ静的マッピングテーブル２１２Ａは、基本的にサイト静的マッピングテーブル２１１と同様の構成を有する。ジオ静的マッピングテーブル２１２Ａは、サイト間で共有される。

　ジオ静的マッピングテーブル２１２Ａは、ジオストライプタイプ番号毎に、対応するストライプが配置されるデータサイトのサイト番号と、冗長コードが配置される冗長コードサイトのサイト番号の関係を保持する。データサイトそれぞれの一つのノード１０１がストライプを格納する。また、冗長コードサイトそれぞれの一つのノード１０１が、冗長コードを格納する。

　コンシステントハッシングテーブル２１２Ｂは、冗長コードサイト内で冗長コードを格納するノード１０１を特定するための情報を示す。サイト１０２それぞれが、固有のコンシステントハッシングテーブル２１２Ｂを保持する。コンシステントハッシングテーブル２１２Ｂの情報は、サイト毎に異なる。

　コンシステントハッシングテーブル２１２Ｂは、当該冗長コードサイト内のノード１０１のノード番号と、ノード１０１が冗長コード（１）を格納する場合のハッシュ値と、ノード１０１が冗長コード（２）を格納する場合のハッシュ値と、の関係を示す。ハッシュ値は、他のサイト１０２からストライプと共に転送される転送元に関する情報に基づき算出される。算出されたハッシュ値に対応づけられているノード１０１に当該ストライプは転送され、当該転送先ノード１０１が冗長コードを生成、格納する。

　図７Ａ～７Ｃを参照して説明した静的マッピングテーブルは、ノード／サイト障害時に、スペア領域にユーザデータ（ストライプ）及び冗長コードの格納先を変更する場合に、変更される。さらに、ノードやサイトの増設／減設時に変更される。

　ノード１０１は、故障したノード／サイトの情報から一意に静的マッピングテーブルを変更できるように、同一の計算論理を共有してもよい。これにより、ノード１０１は、保持する静的マッピングテーブルを変更した後、当該静的マッピングテーブルをマルチキャスト送信する必要がなくなり、ネットワークの負荷を低減できる。

　静的マッピングテーブルによりストライプタイプに属するノードを予め定義することで、データ回復の点から適切な冗長構成を実現することができる。一つノードのデータを異なるストライプタイプの含めると共に、一つノードが属するストライプタイプ数を規定することで、ノード閉塞時のデータ回復可能性を高めることができる。なお、サイト静的マッピングテーブル２１１の使用方法は、図１１を参照して後述される。

　図８は、データ保護レイヤ情報２０１におけるログ構造化マッピングテーブル２１３の構成例を示す。図８において、矢印はポインタを表す。ログ構造化マッピングテーブル２１３は、データマッピングテーブル７０１、ジオ／サイト／ノードコードマッピングテーブル７０２、及び逆マッピングテーブル７０３を含む。

　データマッピングテーブル７０１は、当該テーブル７０１を保持するノード１０１が格自系のストレージデバイス（ドライブ１１３）に格納しているユーザデータ（ストライプ）を管理する。ノード１０１は、ストライプのプールボリュームの格納アドレス（論理アドレス）から、当該ストライプを格納するドライブ１１３（物理ストレージデバイス）の格納アドレス（物理アドレス）を知ることができる。

　データマッピングテーブル７０１は、プールボリュームにおけるユーザデータ（ストライプ）の格納アドレス（論理アドレス）と、ドライブ１１３の物理記憶領域における格納アドレス（物理アドレス）とを対応づける。

　ストライプのプールボリュームの格納アドレスは、プールボリュームのＬＤＥＶ番号、ストライプのストライプ番号で指定され、さらに、ストライプ内の各ブロックがＬＢＡのオフセットで指定される。ストライプサイズは一定である。ストライプ番号は、例えば、ｆｌｏｏｒ（ＬＢＡ／ストライプ長）により算出される。物理記憶領域の格納アドレスは、ドライブ番号、ＬＢＡ、及びデータ長で指定される。

　図８の例において、一つのストライプが二つの物理領域（ブロック）に分かれて格納されている。データマッピングテーブル７０１は、ＬＤＥＶ番号０、ストライプ番号０、ストライプ内ＬＢＡオフセット０のデータは、ドライブ番号０ｘ４３、ＬＢＡ０ｘ０００３、データ長８の領域に格納されていることを示す。さらに、ＬＤＥＶ番号０、ストライプ番号０、ストライプ内ＬＢＡオフセット１のデータは、ドライブ番号０ｘ４２、ＬＢＡ０ｘ０００７、データ長８の領域に格納されていることを示す。

　物理記憶領域は、さらに、格納しているデータの状態を示す情報を格納する。状態情報は、データが対応する冗長コードノードにコピー済（転送済）であるか否かを示す。後述するように、ライトデータ（ストライプ）は、Ｓｙｎｃ／Ａｓｙｎｃの設定に従って、ライトデータ（ストライプ）のホストライト処理と同期又は非同期に、冗長コード生成のために冗長コードノードに転送される。

　冗長コードマッピングテーブル７０２は、当該テーブル７０１を保持するノード１０１が自系のストレージデバイス（ドライブ１１３）に格納している冗長コードを管理する。管理される冗長コードは、サイト間冗長コード（ジオ冗長コードＲ）、サイト内冗長コード（サイト冗長コードＱ）及びノード内冗長コード（ノード冗長コードＱ）を含む。ノード１０１は、ストライプを格納するプールボリュームの論理アドレスから、当該ストライプの冗長コードの物理アドレスを知ることができる。

　冗長コードマッピングテーブル７０２は、冗長コードの生成に使用されたストライプのプールボリュームの論理アドレスと、ドライブ１１３（自系のストレージデバイス）の物理記憶領域の物理アドレスとを対応づける。冗長コードは、複数のストライプを元にした演算（例えばｘｏｒ）で生成される。したがって、冗長コードの物理アドレスに対して、複数のストライプの論理アドレスが関連付けられる。

　図８は、二つのストライプから一つの冗長コードを生成する例を示す。図８の例において、冗長コードマッピングテーブル７０２は、一つのジオ冗長コードの物理アドレスと、当該ジオ冗長コードの生成に使用された二つのストライプの論理アドレスとの関係を示す。ストライプの論理アドレスは、サイト、ノード、プールボリュームの識別子及びボリューム内アドレスで示される。ジオ冗長コードは、物理記憶領域において、二つのアドレス領域（ブロック）に分かれて格納されている。

　例えば、サイト番号４、ノード番号３、ＬＤＥＶ番号７、ストライプ番号８のストライプにおけるＬＢＡオフセット０のブロックと、サイト番号６、ノード番号５、ＬＤＥＶ番号４、ストライプ番号１３のストライプにおけるＬＢＡオフセット０のブロックから生成されたジオ冗長コードのブロックは、ドライブ番号０ｘ４０、ＬＢＡ０ｘ００２０、データ長８の領域に格納されている。

　本例の分散型ストレージシステムは、ログ構造化方式でデータを格納する。ログ構造化方式は、論理アドレスのデータが新たなデータで更新される場合に、物理アドレスのデータを新たなデータ更新することなく、新たなデータを新たな物理アドレスに追記する。不要なデータは、適宜消去される。ログ構造化方式により、ノード冗長コードＰの更新のための読み出しが不要であり、ドライブ１１３へのライト処理の時間を短縮できる。分散型ストレージシステムは、ログ構造化方式を実装しなくてもよい。

　したがって、論理アドレスのデータとして、旧データと新データとが物理記憶領域に格納され得る。ログ構造化マッピングテーブル２１３は、論理アドレスと最新データの物理アドレスとの関係の他、論理アドレスと旧データの物理アドレスとの関係の情報、データの世代管理情報を保持する。複数ストライプから生成される冗長コードの世代管理の情報は、冗長コード生成に使用された各ストライプの世代情報を示す。

　また、データマッピングテーブル７０１や冗長コードマッピングテーブル７０２に、データ保障コード（ライトシーケンス番号、ＣＲＣ等）を付加してもよい。本情報を付加することで、本マッピングテーブルの情報をアドレス変換時に１回参照するだけで、データの整合性をチェックできる。

　逆マッピングテーブル７０３は、上記テーブル７０１、７０２の逆変換テーブルである。つまり、逆マッピングテーブルは、物理領域のアドレスからプールボリュームのアドレスへの変換のために参照される。逆マッピングテーブル７０３は、物理領域においてデータを格納するアドレス領域７３１のそれぞれに対応する論理アドレスを示すテーブル７３２を含む。

　テーブル７３２のそれぞれは、データのタイプ（ストライプ／ジオコード／サイトコード／ノードコード）、インデックス数（リファレンスの個数）、更新日時、リファレンス（対応するプールボリューム領域、サイト番号、ノード番号など）を含む。

　例えば、図８は、一例として、ジオ冗長コードを格納する物理アドレスに対応する論理アドレスの情報を示す。本例は、図８における冗長コードマッピングテーブル７０２の例と一致している。データタイプはジオ冗長コードであり、インデックス数は２である。これは、ジオ冗長コードの生成に二つのストライプが使用されていることを示す。

　リファレンスは、ジオ冗長コードの生成に使用されたストライプの格納先論理アドレスを示す。論理アドレスは、サイト番号、ノード番号、ＬＤＥＶ番号及びストライプ番号及びオフセットで示されている。

　上述のように、冗長コードの元となるストライプそれぞれの転送元アドレスと冗長コードの物理アドレスとを関連付けて管理することで、様々なストライプ組み合わせの冗長コードを適切に管理することができる。

　ドライブ１１３が不揮発媒体を含む場合、ノードは、ユーザデータのドライブライト時に同期して逆マッピングテーブル７０３に更新情報を追記してもよい。これにより、不測の電源消失時のデータ復旧を可能とする。ノード１０１は、メモリ１１８に格納し、ユーザデータのドライブライトとは非同期に、ドライブ１１３内の逆マッピングテーブル７０３を更新してもよい。不測の電源消失時のデータ復旧を可能とするために、逆マッピングテーブル７０３は、ライトシーケンス番号を保持してもよい。逆マッピングテーブル７０３は、最新データの情報に加え旧データの情報も保持してもよい。

　図９は、ローカル領域制御テーブル２１４の構成例を示す。図９において、矢印はポインタを表す。ローカル領域制御テーブル２１４は、有効リスト８０１Ａ、無効リスト８０１Ｂ、フリーリスト８０１Ｃ、ローカル領域量テーブル８０２を含む。ローカル領域制御テーブル２１４は、ノード１０１内にあるドライブ１１３の領域を管理する。リスト８０１Ａ～８０１内の矢印はポインタである。リスト８０１Ａ～８０１において、各領域はドライブ番号及びドライブ内のＬＢＡで示される。

　有効リスト８０１Ａは、有効領域のリストである。有効領域は、最新のユーザデータ又は最新の冗長データを格納する領域である。図９の例において、ドライブ番号０のドライブ１１３において、ＬＢＡ０、４、５のブロックは、それぞれ、有効データを格納している。

　無効リスト８０１Ｂは、無効領域のリストである。無効領域は、古いユーザデータ又は古い冗長コードを格納する領域である。古く、無効な冗長コードは、当該冗長コードの生成に使用されている全ストライプが無効である冗長コードである。図９の例において、ドライブ番号０のドライブ１１３において、ＬＢＡ１、３、７のブロックは、それぞれ、無効データを格納している。フリーリスト８０１Ｃは、未使用領域のリストである。

　ローカル領域量テーブル８０２は、各ストライプタイプ、ノード冗長コード、サイト冗長コード、ジオ冗長コード、スペア領域の目標使用量、実際使用量、有効領域の量を管理する。ノード１０１は、階層毎にローカル領域量テーブル８０２を保持する。ローカル領域量テーブル８０２の各エントリは、全階層の総量を示してもよい。ストライプタイプ及び冗長コードそれぞれの量を個別に管理することで、各種データのための量を適切に制御できる。プロセッサ１１９は、ホストＩ／Ｏと同期又は非同期に、ローカル領域制御テーブル２１４を更新する。

　例えば、ローカル領域量テーブル８０２は、自ノード１０１が所属するストライプタイプのエントリのみを保持する。ローカル領域量テーブル８０２は、他ノード１０１から転送されたデータの使用量を管理するため、自ノード１０１が属さないストライプタイプのデータのためのエントリを含んでもよい。

　図１０は、キャッシュ情報２０４の例を示す。ノード１０１は、それぞれ、固有のキャッシュ情報２０４を保持する。キャッシュ情報２０４は、データダーティキュー９００、コードダーティキュー９０１、クリーンキュー９０２、フリーキュー９０３、中間ダーティキュー９０４を含む。ダーティキュー９００、９０１、９０４は、ドライブ１１３に未反映なキャッシュ１８１上のデータを示す。

　キューにおけるセルはエントリを示し、エントリの情報は、キャッシュビットマップテーブル９０５内の情報に対応し、キャッシュビットマップテーブル９０５から選択された情報を格納する。キュー内の矢印は、エントリ間をつなぐポインタを表す。黒丸は始点である。

　データダーティキュー９００は、自系のドライブ１１３に格納されるホストからのライトデータ（ストライプ）を示す。ライトデータは、いずれかのサイトストライプタイプに属する。データダーティキュー９００は、当該ノード１０１がデータノードとして属するサイトストライプタイプ毎のキューを含む。

　コードダーティキュー９０１は、ドライブ１１３に未反映なキャッシュ１８１上の、冗長コード生成ためのストライプを指す。当該ストライプ及び当該ストライプから生成される冗長コードは、ダーティデータである。

　コードダーティキュー９０１は、冗長コード生成のために他ノードから受信したストライプのためのキューを含む。ノード１０１は、複数保護レイヤに属するため、異なる保護レイヤのストライプタイプのキューが用意される。図１０の例においては、サイトストライプタイプ及びジオストライプタイプのキューが示されている。ストライプタイプとデータ位置（ノード）との組毎のダーティキューが使用される。

　各キューは、対応ストライプタイプに属し、対応ノードの物理領域に格納されるデータのリストを示す。「ＳＩＴＥ　ＳＴＲＩＰＥＴＹＰＥ＃０、０」のキューは、サイトストライプタイプ番号０のサイトストライプに属し、ノード番号０のノードに格納されるデータのためのキューである。

　中間ダーティキュー９０４は、ドライブ１１３に未反映なキャッシュ１８１上の中間コードを指す。中間コードは、新ストライプと旧ストライプから生成されるデータである。例えば、新ストライプと旧ストライプのｘｏｒである。中間コードは、新ストライプと旧ストライプの差分データであり、ノード１０１は、中間コードを使用してドライブ１１３に格納されている旧ストライプの冗長コードを、新ストライプの冗長コードに更新することができる。中間コードの使用方法の詳細は後述する。

　中間ダーティキュー９０４の構成は、ダーティキュー９０１における冗長コード用のキューと同様である。つまり、本例において、ストライプタイプとデータ位置（ノード）との組毎のキューが使用される。ノード１０１は、複数保護レイヤに属するため、異なる保護レイヤのストライプタイプのキューが用意される。図１０の例においては、サイトストライプタイプとジオストライプタイプのキューが示されている。

　クリーンキュー９０２は、ドライブ１１３に反映済みのキャッシュ１８１上のデータを指す。フリーキュー９０３は、使用されていないキャッシュ１８１の領域を指す。

　キャッシュビットマップテーブル９０５は、データの論理アドレス、キャッシュアドレス（メモリ上の位置）、サイズと、ダーティビットマップ、及びステージングビットマップを含む。例えば、一つのエントリは、キャッシュ１８１内の所定サイズの一スロットの情報を示す。

　論理アドレスは、図８を参照して説明したストライプの論理アドレスが対応する。他ノード１０１から転送されたストライプの論理アドレスは、例えば、サイト番号、ノード番号、ＬＤＥＶ番号、及びＬＢＡ、オフセットを含む。ダーティビットマップは、その領域のどの部分がダーティ状態かを示す。ステージングビットマップは、当該領域のどの部分がキャッシュ１８１上にステージング済みかを示す。たとえば、１ビットはドライブ１１３の１ブロックに対応する。

　図１１は、サイト保護レイヤ（レイヤ番号２）のマッピングイメージを示す。基本的に、ノード保護レイヤ（レイヤ番号１）及びジオ保護レイヤ（レイヤ番号３）のマッピングイメージも同様である。以下において、ストライプタイプのサイクル数はｃ、冗長コード数（パリティ数）はｐ、ストライプ数（データ数）はｄと表される。

　図１１の例において、サイクル数は５、冗長コード数は１、ストライプ数は３である。具体的には、一つのサイトストライプタイプにおいて、最大三つのストライプから一つの冗長コードが生成され、サイトストライプタイプ内のノードに格納される。後述するように、冗長コードは、３以下のいずれかの数のストライプから生成される。複数冗長コードが生成される場合、異なる冗長コードノードに分散格納される。

　表６２１は、ストライプタイプのデータノードと冗長コードノードとを示す。列はそれぞれ、ノード番号０～８のノードに対応する。ノード番号０～８のノードの物理記憶領域を示す円柱６２２のそれぞれの容量は、円柱の高さで示されている。

　表６２１において、セル内の数字はストライプタイプ番号を示す。Ｄ領域内のセルは、データノードが属するストライプタイプ番号を示す。Ｑ領域内のセルは、冗長コードノードが属するストライプタイプ番号を示す。

　Ｓ領域のセルは、スペアノードが属するストライプタイプ番号及び格納するデータ種別（ストライプ／冗長コード）を示す。スペアノードは、ノードにおいて障害が発生した場合に、当該ノードのデータを一時的に格納するノードである。これにより、ノード障害時に、冗長度が回復される。

　ライトデータのストライプタイプ番号は、当該ライトデータのストライプ番号及び当該ライトデータを受信し、格納するノードのノード番号により決定される。具体的には、ノード１０１は、（ライトデータの論理アドレス値÷ストライプサイズ）によりストライプ番号を決定する。本例において、論理アドレスは、プールボリューム内の論理アドレスである。仮想ボリューム内の論理アドレスを使用してもよい。さらに、ノード１０１は、（ストライプ番号ｍｏｄｃ）により、当該ライトデータの行番号を算出する。

　ノード１０１は、レイヤ番号２のサイト静的マッピングテーブル２１１を参照して、自装置のノード番号と算出した行番号から、ストライプタイプ番号を決定する。例えば、ノード１０１は、サイト静的マッピングテーブル２１１において、データノードとして自ノード番号を含むエントリを選択し、行番号が示す順番のエントリのサイトストライプタイプ番号を、当該ライトデータのサイトストライプタイプ番号と決定する。

　さらに、ノード１０１は、レイヤ番号２のサイト静的マッピングテーブル２１１を参照して、ストライプが属するライトストライプタイプの冗長コードノードを決定する。この点は、後述するライト処理の説明において改めて説明する。

　図１１において、例えば、ノード番号０、５、７のノードにおける行番号０のストライプは、ストライプタイプ番号０のストライプタイプに属する。ノード番号１、３、８のノードにおける行番号４のストライプは、ストライプタイプ番号１３のストライプタイプに属する。

　さらに、ストライプタイプ番号０のストライプタイプに属する冗長コードノードのノード番号は１であり、ストライプタイプ番号１３のストライプタイプに属する冗長コードノードのノード番号は４である。いくつかのノードは、複数のストライプタイプの冗長コードを格納する。

　図１１の例において、Ｄ領域におけるストライプの分散は均等である。ノードの記憶容量によって、ストライプタイプのデータノード数を変化させてもよい。また、ノードの総数が少ない場合や端数が発生する場合に、一部のストライプタイプの冗長コード数を減らしてもよい。異なるストライプタイプは異なるアルゴリズムにより冗長化を行ってよい。

　ストライプタイプ内の冗長コードノードは、当該ストライプタイプのデータノードと異なるノードから選択される。冗長コードノードには、データノードからのデータライトが集中する。したがって、冗長コードができるだけ均等に配置されるように、冗長コードノードが選択される。これにより、ノード１０１の寿命が平準化される。ドライブ１１３がＳＳＤである場合に特に有効である。ノード間において寿命が偏った場合には、平準化するように冗長コードＱの配置を変更してもよい。

　スペアノードは、ノード障害が発生したときに、冗長度を回復するための一時的な格納先である。冗長コードを格納するスペアノードは、同一ストライプタイプのデータノードとは異なるノードから選択される。図１０の例において、ノード番号６のノードにおいて障害が発生している。ストライプ又は冗長コードのストライプタイプ番号に対応づけられたスペアノードが、対応するストライプ又は冗長コードを一時的に格納する。

　例えば、ノード番号０のノードは、ノード番号６のノードが格納していたストライプタイプ番号２のストライプを格納する。ノード番号７のノードは、ノード番号６のノードが格納していたストライプタイプ番号３の冗長コードＱを格納する。データの回復は、当該データを格納するノード又は異なるノードが実行する。スペアノードに格納されるデータ（ストライプ及び冗長コード）は、ノード回復時やノード増設時に、スペアノードから一つのノードに戻される。

　上記例において、ストライプタイプは、プールボリュームのＬＤＥＶ番号に依存せず、プールボリューム内のアドレスにより決定される。異なるプールボリュームの同一ボリューム内アドレスのデータは、同一のストライプタイプの属する。一つのプールボリュームのアドレス領域は、複数のストライプタイプに分類される。後述するように、冗長コードノードは、ストライプのボリューム内アドレスに依存することなく、同一ストライプタイプ内のストライプから、任意数の任意のストライプを選択し、選択したストライプから冗長コードを生成する。

　図１２Ａは、分散型ストレージシステムにおける、ノード１０１の状態遷移を示す。図１２Ｂは、分散型ストレージシステムにおける、サイト１０２の状態遷移を示す。基本的に、各保護レイヤにおいて、状態遷移は同様である。

　通常状態は、初期状態及び動作中の通常状態を示す。状態は、ドライブ障害が発生した場合にリビルド中状態に移行する。ノード１０１は、リビルド中に、コレクションリード・ライトにより、アプリケーションのＩ／Ｏを受け付けることができる。

　閉塞状態において、ノード１０１はダウンしており、Ｉ／Ｏを実行できない。しかし、ドライブ１１３は故障していない場合がある。その場合、閉塞を起こしたノード１０１に閉塞発生後に新規にライトされたデータのみを反映するデータリシンクにより、データを復旧し、閉塞状態を通常状態に変化させることができる。

　図１３は、分散型ストレージシステムの一つノード１０１における、仮想プロビジョニングレイヤの論理構成例を示す。仮想ボリューム１３０１Ａ、１３０１Ｂは、ホスト（同一ノード又は他ノード）ら認識される仮想的な記憶領域であり、ホストからリード又はライト命令が発行される際に対象となるボリュームである。

　プール１３０６は、１以上のプールボリュームにより構成される。図１３の例においては、プール１３０６は、プールボリューム１３０３Ａ～１３０３Ｆを含む。プール１３０６は、他ノードのプールボリュームを含んでもよい。プールボリューム１３０３Ａ～１３０３Ｆは、ドライブ１１３の記憶領域によって構成される。具体的には、プロセッサ１１９は、プールボリュームの論理アドレスと、ドライブ１１３の物理アドレスの対応関係を管理することにより、論理的なプールボリュームを構成する。詳細については後述する。

　ストレージ管理者は、入出力デバイスを介したプロセッサ１１９への指示により、プール１３０６上に、複数の仮想ボリュームを作成することができる。プロセッサ１１９は、仮想ボリュームにおいてライト命令が発行された記憶領域にのみ、プール１３０６から実記憶領域を割り当てる。

　図１３の例において、仮想ボリューム１３０１Ａは仮想ページ１３０２Ａ、１３０２Ｂ、１３０２Ｃを含み、それぞれに、論理ページ１３０４Ａ、１３０４Ｅ、１３０４Ｃが割り当てられている。仮想ボリューム１３０１Ｂは仮想ページ１３０２Ｄ、１３０２Ｅを含み、それぞれに、論理ページ１３０４Ｄ、１３０４Ｆが割り当てられている。

　論理ページは動的に仮想ページに割り当てられる。例えば、仮想ボリューム１３０１Ａの仮想ページ１３０２Ａに、初めてライト命令が発行された際に、プロセッサ１１９は、プールボリューム１３０３Ａの未使用の領域（論理ページ１３０４Ａ）と対応づける（対応づけ１３０５Ａ）。次回の同ページへのリード／ライト命令に対しても、プロセッサ１１９は、対応づけ１３０５Ａに基づき、プールボリューム１３０３Ａの論理ページ１３０４Ａに対するＩ／Ｏ処理を実行する。

　上記動作により、ノード１０１が、あたかも仮想ボリュームに対してＩ／Ｏ処理（アクセス処理）を実行しているように、ホストに見せることができる。仮想ボリュームを用いて、使用する領域にのみプールボリュームの領域を割り当てることにより、限られた記憶領域を効率的に使用できる。プロセッサ１１９は、仮想ページに割り当てられている論理ページの全データが消去されると、当該仮想ページと論理ページの対応づけを解消し、当該論理ページを未使用ページとして管理する。これにより、限られた記憶領域をより効率的に使用できる。

　プール１３０６は、複数の階層１１５、１１６、１１７からなる。本例において、プール１３０６は、ＳＳＤ階層１１５（ＴＩＥＲ１）、ＳＡＳ階層１１６（ＴＩＥＲ２）、ＳＡＴＡ階層１１７（ＴＩＥＲ３）の３階層を持つ。ＳＳＤ階層１１５の性能が最も高く、ＳＡＴＡ階層１１７の性能が最も低い。プールボリュームは、階層１１５、１１６、１１７に分類され、プールボリュームいずれかの階層に属する。プールボリューム１３０３Ａは階層１１５に属し、プールボリューム１３０３Ｂ、１３０３Ｃは階層１１６に属し、プールボリューム１３０３Ｄ、１３０３Ｅは、階層１１７に属する。

　各仮想ページは、ホストからのＩ／Ｏ処理の特性を有する。例えば、Ｉ／Ｏ頻度（アクセス頻度）が高い仮想ページと低い仮想ページが存在する。これをアクセスローカリティと呼ぶ。Ｉ／Ｏ頻度が高い仮想ページを上位階層に配置する、つまり、Ｉ／Ｏ頻度が高い仮想ページを上位階層の論理ページに割り当てる。これにより、システム全体の性能を向上ができる。なお、仮想ページがいずれかの階層の論理ページに割り当てられているとき、当該仮想ページは階層に割り当てられている又はプールボリュームに割り当てられている、とも表現される。

　例えば、１００ＩＯＰＳを処理できるＳＳＤ階層１１５と、１０ＩＯＰＳ処理できるＳＡＳ階層１１６がプール１３０６に存在し、２０ＩＯＰＳの特性を持つ仮想ページ１３０２Ａと、５０ＩＯＰＳの特性を持つ仮想ページ１３０２Ｃがあるとする。ページ１３０２ＡがＳＳＤ階層１１５に割り当てられ、ページ１３０２ＣがＳＡＳ階層１１６に割り当てられているとする。ＳＡＳ階層１１６は最大で１０ＩＯＰＳの性能しか発揮できないため、ノード１０１は、全体として１０＋２０＝３０ＩＯＰＳの性能しか発揮できない。この状態をネック状態と呼ぶ。

　仮想ページ１３０２Ｃの割り当てを、ＳＡＳ階層１１６から、ＳＳＤ階層１１５へプロモーションすることができれば、ノード１０１は、全体として５０＋２０＝７０ＩＯＰＳの性能を発揮できる。以上のように、Ｉ／Ｏ頻度が高い仮想ページを上位階層に割り当てることで、システム全体の性能を向上することができる。

　上記プロモーションは、論理ページ１３０４Ｃのデータを未使用の論理ページ１３０４Ｂにコピーし、仮想ページ１３０２Ｃと論理ページ１３０４Ｃとの対応づけ（１３０５Ｃ）を、仮想ページ１３０２Ｃと論理ページ１３０４Ｂとの対応づけ（１３０５Ｂ）に変更する。ページのデモーションも、同様に実行可能である。

　グラフ２７１は、ページのＩ／Ｏ頻度（Ｉ／Ｏ負荷）の分布を表す。プロセッサ１１９は、ページ負荷分布テーブル２１７から、当該グラフ２７１を示す負荷分布データを作成することができる。分布ライン１３０９は、Ｉ／Ｏ頻度の多い順番にページを並べたときの、各ページのＩ／Ｏ数を表す線である。つまり、Ｉ／Ｏ数の多いページが左側に、Ｉ／Ｏ頻度が少ないページが右側に位置する。階層割り当て閾値１３０８Ａ、１３０８Ｂは、どのＩ／Ｏ頻度のページをどの階層に割り当てるかを決める閾値である。

　前述した通り、Ｉ／Ｏ頻度が高いページを上位階層に割り当てることで、システム全体の性能を向上することができる。したがって、Ｉ／Ｏ頻度の高い順番で上位階層から仮想ページを割り当てられる。ストレージシステムを起動した後、ページ負荷分布２７１を未作成の段階時、階層割り当て閾値１３０８Ａ、１３０８Ｂの初期値は、例えば０でもよい。

　例えば、プロセッサ１１９は、階層割り当て閾値１３０８Ａと分布ライン１３０９の交点から、最もＩ／Ｏ頻度が高いページ範囲１３１０Ａに属するページを、ＳＳＤ階層１１５に割り当てる。プロセッサ１１９は、階層割り当て閾値１３０８Ａと分布ライン１３０９の交点から階層割り当て閾値１３０８Ｂと分布ライン１３０９の交点までの範囲２１０Ｂに属するページを、ＳＡＳ階層１１６に割り当てる。プロセッサ１１９は、階層割り当て閾値１３０８Ｂと分布ライン１３０９の交点から最小のＩ／Ｏ頻度のページまでは、ＳＡＴＡ階層１１７に割り当てる。

　ストレージ管理者は、階層割り当て閾値１３０８Ａ、１３０８Ｂの値を指定してもよいし、プロセッサ１１９は、階層割り当て閾値１３０８Ａ、１３０８Ｂの値を計算してもよい。例えば、プロセッサ１１９は、仮想ページのＩ／Ｏ頻度分布、階層の容量、及び当該階層のドライブ性能に基づき、当該階層を定義する階層割り当て閾値を決定してもよい。階層のドライブ性能は、例えば、当該階層における単位時間当たりのＩＯデータ量により予め定義されている。

　図１４は、分散型ストレージシステムにおける複数ノードのページマッピングの例を示す。図１４において、分散型ストレージシステムは、仮想ボリューム１３０１Ａ～１３０１Ｃを提供する。ノード１０１Ａは仮想ボリューム１３０１Ａを提供する。ノード１０１Ｂは、仮想ボリューム１３０１Ａ、１３０１Ｂを提供する。ノード１０１Ｎは、仮想ボリューム１３０１Ｃを提供する。

　ノード１０１（ノード１０１Ａ～１０１Ｎの任意ノード）は、二種類のボリュームを保持し得る。一つは、自系のドライブ１１３の記憶領域からなるプールボリューム１３０３Ａである。プールボリューム１３０３Ａが格納するデータは、自系のドライブ１１３に配置される。

　他の一つは、他のノード１０１のプールボリューム１３０３Ｂをストレートマッピングするボリューム１３０３Ｃである。ボリューム１３０３Ｃは、プールボリュームとして管理される。ノード１０１は、プールボリューム１３０３Ｃを介して、他系のプールボリューム１３０３ＢのＩ／Ｏ処理を行うことができる。

　この機能は、ストレージ外部接続機能として知られている。ノード１０１は、ボリューム１３０３Ｃのアクセス先アドレスを、他系のプールボリューム１３０３Ｂのアドレスに変換して、当該他系のノード１０１にコマンドを送信する。ノード１０１は、自系のプールボリューム１３０３Ｃと他系のプールボリューム１３０３Ｂとの間の不図示のアドレスマッピングテーブルを保持する。

　プロセッサ１１９は、自系でのホストアクセス量が多い仮想ページを、Ｏｗｎのプールボリューム１３０３Ａにマッピングし、他系でのホストアクセス量が多い仮想ページを、当該他系のプールボリューム１３０３Ｂにマッピングする。これにより、ホストへレスポンスタイムを短縮する。他系のプールボリューム１３０３Ｂに割り当てられた仮想ページのデータは、他系のドライブ１１３に格納される。

　各ノード１０１は、ネットワーク性能及び各階層の自系のドライブ性能に基づき、マッピングする他系のプールボリュームの数や、他系のプールボリュームに割り当てる仮想ページを選択し、ネットワークがボトルネックとならないように論理ページを配置する。この配置の詳細は図２３、２４Ａ、２４Ｂを参照して後述する。

　分散型ストレージシステムは、システム全体で記憶容量を管理し、各ノード１０１のプールボリュームの数を、仮想ボリュームのページ使用容量に応じて増減させてもよい。ノード１０１は、プールボリューム１３０３Ａを、仮想ボリュームとしてストレートマッピングによって使用してもよい。これにより、マッピングテーブルのメモリ使用量を削減でき、性能及び可用性を高めることができる。

　図１５は、分散型ストレージシステムのリード処理のフローチャートを示す。プロセッサ１１９は、受信したリード命令の指定アドレスに対して、アクセス先仮想ページがプールボリュームに未割り当てか否かを、ページマッピングテーブル２１５を参照して判定する（Ｓ５０１）。指定アドレスは、例えば、仮想ボリューム番号及び論理アドレスで指定される。ＬＢＡは、開始ＬＢＡ及びブロック長で表わされる。

　仮想ページが未割り当ての場合（Ｓ５０１：Ｙ）、プロセッサ１１９は、排他が必要か否か判定する（Ｓ５０６）。プロセッサ１１９は、仮想ボリューム管理テーブル２１８を参照し、仮想ボリュームのオーナノードが自ノードのみの場合に排他不要と判定する。

　排他が必要の場合（Ｓ５０６：Ｙ）は、プロセッサ１１９は、排他を取得して（Ｓ５０７）、再度、仮想ページがプールボリュームに未割り当てか否かを判定する（Ｓ５０８）。排他方法の一例において、プロセッサ１１９は、リードアドレスから一意に決まる代表ノードをハッシュ関数を使用して特定し、代表ノードに調停を依頼し、代表ノードが調停を行う。

　仮想ページが割り当て済みの場合（Ｓ５０８：Ｎ）、プロセッサ１１９は、排他を解除し（Ｓ５１２）、ステップＳ５０２に進む。仮想ページが論理ページに未割り当てである場合（Ｓ５０８：Ｙ）、プロセッサ１１９は、ゼロデータを返し（Ｓ５０９）、ステップＳ５０６の判定と同様に排他要否を判定する（Ｓ５１０）。排他が必要である場合（Ｓ５１０：Ｙ）には、排他がすでに取得されているため、プロセッサ１１９は、排他を解放する（Ｓ５１１）。

　ステップＳ５０１において仮想ページが割り当て済みであり（Ｓ５０１：Ｎ）、且つ仮想ページがプールボリュームに割り当てられている場合（Ｓ５０２：Ｙ）、プロセッサ１１９は、自系のキャッシュ領域を確保し、当該プールボリュームからデータをリードして、当該リードデータ返す（Ｓ５０４）。プロセッサ１１９は、プールボリューム管理テーブル２１９及び不図示の外部接続管理情報を参照して、仮想ページが自系のプールボリュームに割り当てられているか否か判定する。

　仮想ページが自系のプールボリューム１３０３Ｃを介して他ノード１０１のプールボリューム１３０３Ｂに割り当てられる場合、当該仮想ページは他系のプールボリュームに割り当てられていると判定される。

　キャッシュ領域の確保において、プロセッサ１１９は、キャッシュ情報２０４を参照して、対象論理アドレスに対応付けられているキャッシュ領域を特定する。対応するキャッシュ領域が存在しない場合、プロセッサ１１９は、フリーキュー９０３から新たな領域を確保する。フリーキュー９０３が空の場合、プロセッサ１１９は、クリーンキュー９０２から新たな領域を確保する。クリーンキュー９０２が空の場合、プロセッサ１１９は、ダーティキュー９００、９０１又は９０４内の領域をデステージしてフリー領域に変化させる。

　アクセス先仮想ページが他系のプールボリュームに割り当てられている場合（Ｓ５０２：Ｎ）、プロセッサ１１９は、当該他のノード１０１にリード命令を転送する（Ｓ５０５）。プロセッサ１１９は、自系ではリードデータをキャッシュしない。つまり、仮想ページの割り当て先が他ノードであれば、プロセッサ１１９は、リードデータを自系メモリ１１８にキャッシュせず（リードスルー）、他ノード１０１がリードデータをキャッシュする。

　図１６は、同期ライト処理のフローチャートを示す。本処理は、ホスト（例えばアプリケーションプログラム）からライト命令が発行された場合に実行される。本処理は、自系のプールボリュームにライトデータを格納することに加え、サイト冗長コード（ノード間冗長コード）及びジオ冗長コード（サイト間冗長コード）を生成するために、他ノード１０１にライトデータを転送する。

　ライト命令を受けたノード１０１のプロセッサ１１９は、ページが未割り当てかどうかを判定する（Ｓ６０１）。具体的には、プロセッサ１１９は、ページマッピングテーブル２１５を参照し、ライト命令の指定アドレス（仮想ボリューム番号及びＬＢＡ）から、対応するプールボリューム番号とＬＢＡを検索する。プロセッサ１１９は、対応するアドレス情報の有無で、仮想ページが未割り当てか否かを判定する。

　本例のシステムでは、複数のアプリケーションが起動されており、システム内の少なくとも１つのノードがそれぞれのアプリケーションを動作させている。ここで、データの読み出し要求は、そもそも当該データのライト命令を受けたノードに出されることが多いと考えられる。よって本願では、ノードはライト要求を受けた場合にそのライト要求のデータを当該ノードの記憶領域に優先して格納する。これにより、リード要求に対して当該ノードから読み出しできる確率が高まり、読み出し要求に高速に応えることが可能となる。

　但し、ノード１０１に接続されたドライブ１１３の性能がネットワーク１０３の性能に対して低い場合は、多数のノードにデータを分散させたほうが、システムとしてのスループットを向上できる場合がある。以上のことを考慮し、ネットワーク１０３の性能やノード１０１に接続されたドライブ１１３の性能に応じて、割り当て先の記憶領域を、ラウンドロビン等の技法を用いて変更してもよい。また上述の割り当て方針は、性能という指標に基づくだけでなく、ドライブ１１３としてフラッシュを用いた場合には寿命などの指標を用いて、コスト対効果を効率化することも考えられる。

　仮想ページが未割り当ての場合（Ｓ６０１：Ｙ）、プロセッサ１１９は、仮想ページをプールボリュームに割り当てる処理を実行する。プロセッサ１１９は、まずページマッピングテーブル２１５の更新の排他が必要か否か判定する（Ｓ６１１）。排他を取得する理由は、他ノード１０１で同時に仮想ページを割り当てる場合に、仮想ページに対して、複数の異なるプールボリュームの領域が割り当てられることを防ぐためである。

　プロセッサ１１９は、仮想ボリューム管理テーブル２１８を参照し、オーナノードに自ノード以外が含まれている場合は、排他が必要であると判定し、オーナノードが自ノードのみである場合、排他が不要であると判定する。排他が必要と判定した場合（Ｓ６１１：Ｙ）、プロセッサ１１９は、排他を取得する（Ｓ６１２）。排他の取得方法は、図１６で説明したリード処理において示した方法と同様である。

　次に、プロセッサ１１９は、仮想ページが未割り当てか否かを、再度判定する（Ｓ６１３）。これは、ステップＳ６０１で仮想ページが割り当て済みか否かを判定した後、ステップＳ６１２で排他を取得する前に、他ノードによって排他が取得されている可能性があるからである。

　ページが未割り当てである場合（Ｓ６１３：Ｙ）、プロセッサ１１９は、仮想ページを割り当てるプールボリュームを決定する（Ｓ６１４）。プロセッサ１１９は、まず自系のプールボリュームに空きページがあるかどうかをチェックする。

　具体的には、ローカル領域量テーブル８０２の目標量と使用量を参照し、ライトデータのストライプタイプのエントリにおいて、使用量が目標量より少ないかを判定する。使用量が目標量より少ない場合、プロセッサ１１９は、当該仮想ページを自系のプールボリュームに割り当てる。例えば、ノード１０１は不図示のローカル領域階層管理情報を保持し、空きページを含む最上位階層のプールボリュームを選択する。

　空き領域が自系に存在しない場合、プロセッサ１１９は、他系（他ノード）のプールボリュームをローカルにマウントし、その領域にページを割り当てる。プールボリュームを決定すると、プロセッサ１１９は、当該プールボリュームに仮想ページを割り当てる（Ｓ６１５）。具体的には、プロセッサ１１９は、ページマッピングテーブル２１５の対応関係を更新する。

　本ステップにより、ライト要求を受けたノードが既に多くの記憶容量を消費している場合や、ノードのドライブ１１３の性能が不足している場合には、他のノードの記憶領域を利用することによって、ライト要求受けたノードの性能劣化を防止してシステム全体の容量効率と性能維持を図る。

　次に、プロセッサ１１９は、排他が必要か否かを判定する（Ｓ６１６）。この判定は、ステップＳ６１１と同様である。排他が必要な場合（Ｓ６１６：Ｙ）、プロセッサ１１９は、取得済みの排他を解放する（Ｓ６１８）。排他が不要な場合（Ｓ６１６：Ｎ）、プロセッサ１１９は、ステップＳ６０２に進む。

　プロセッサ１１９は、ライト命令の仮想ボリュームにおける論理アドレス（仮想ページ）が、自系プールボリュームに割り当てられているかを、ページマッピングテーブル２１５を参照して判定する（ステップ６０２）。

　自系プールボリュームに割り当てられていない場合（Ｓ６０２：Ｎ）、プロセッサ１１９は、他ノード１０１にライト命令を転送する（Ｓ６０３）。他ノード１０１は、本フローチャートに従ったライト処理を実行する。データコヒーレンシの維持のため、プロセッサ１１９は、自系でライトデータをキャッシュしない。

　仮想ページが自系プールボリュームに割り当てられている場合（Ｓ６０２：Ｙ）、プロセッサ１１９は、保護レイヤ毎のライト処理を開始する（Ｓ６０４～Ｓ６１０）。例えば、分散型ストレージシステムが三つの保護レイヤで構成されているとする。それらは、例えば、ノード保護レイヤ、サイト保護レイヤ、ジオ保護レイヤである。プロセッサ１１９は、３レイヤで計３回処理を繰り返す。なお、本例において、ノード保護レイヤは、同期ライトに設定されている。

　プロセッサ１１９は、当該レイヤが同期ライト対象かどうかを判定する（Ｓ６０４）。具体的には、プロセッサ１１９は、仮想ボリューム管理テーブル２１８において、ライト対象の仮想ボリュームに対応するＳｙｎｃ／Ａｓｙｎｃフィールドを参照して判定する。

　同期ライトの対象ではない場合（Ｓ６０４：Ｎ）、プロセッサ１１９は、ライトデータ（ストライプ）を他ノード１０１に転送することなく、データマッピングテーブル７０１の領域の状態フィールドに”未完了”と記録する。状態フィールドは、各保護レイヤの状態を示す。状態フィールドが”未完了”を示すキャッシュ１８１上のデータは、転送まで維持される。

　プロセッサ１１９は、全ての保護レイヤが完了したかを判定し（Ｓ６０８）、完了していたら本処理を終了する。完了していない場合（Ｓ６０８：Ｎ）、プロセッサ１１９は、次の保護レイヤの処理をステップＳ６０４から繰り返す。同期ライト対象の場合（Ｓ６０４：Ｙ）、プロセッサ１１９は、自系のキャッシュ領域１８１において、キャッシュ確保を実施する（Ｓ６０５）。その方法は、図１５を参照して説明した方法と同様である。

　次に、プロセッサ１１９は、中間コードを転送するか否か判定する（Ｓ６０６）。中間コードは、旧データ（今までの最新データ）と新データ（今回書き込むデータ）の更新差分を表す。例えばＲＡＩＤ５に相当する冗長データの場合、中間コードは、旧データと新データのｘｏｒ値である。その他、Ｅｒａｓｕｒｅ　Ｃｏｄｉｎｇを用いる場合、プロセッサ１１９は、行列の係数を乗算した複数のｘｏｒ結果を生成してもよい。

　中間コード転送の要否の判定基準としていくつかの基準を使用することができる。例えば、プロセッサ１１９は、転送先ノード１０１の冗長コード領域の残量が閾値より少ないとき、中間コード転送要と判定する。これにより、転送先ノードで必要な冗長コードを確実に格納できる。プロセッサ１１９は、転送先ノード１０１のローカル領域量の情報を転送先ノード１０１から取得する。

　プロセッサ１１９は、自系においてキャッシュヒット時のレスポンス低減効果が小さい場合に、中間コードを生成してもよい。例えば、自系において書き込むモードが設定されているとき、自系において所定の低レイテンシドライブが使用されているとき、自系が閾値より高い負荷状態の時、又は、ノード間通信距離が閾値より長いとき、プロセッサ１１９は、中間コードを転送する。

　または、プロセッサ１１９は、ドライブ１１３のライト寿命が十分ある場合に、中間コードを転送する。なお、書き込むモードにおいて、プロセッサ１１９は、ライトデータをキャッシュ１８１からドライブ１１３にデステージした後に、ホストに完了応答を返す。

　中間コード転送要と判定した場合（Ｓ６０６：Ｙ）、プロセッサ１１９は、キャッシュ１８１上のストライプ（ライトデータ）とドライブ１３３から読み出した旧ストライプとから中間コードを生成し（Ｓ６０９）、対象ノード（転送先ノード）のキャッシュ１８１に中間コードを書き込む（Ｓ６１０）。

　プロセッサ１１９は、中間コードの対象ノード（転送先ノード）を以下の方法で特定する。プロセッサ１１９は、下記式により、行番号（図１１におけるＤ領域の縦軸の値）を算出する。行番号の算出方法は、図１１を参照したストライプの行番号の算出方法と同様である。
　　（アドレス値／ストライプサイズ）ｍｏｄｃ

　プロセッサ１１９は、算出した行番号と自ノード番号とから、当該保護レイヤの静的マッピングテーブルを参照して、ストライプタイプ番号（図１１における図中のセル内の数字）を決定する。

　プロセッサ１１９は、当該保護レイヤの静的マッピングテーブルを参照して、ストライプタイプ番号から、転送先ノード１０１を決定する。プロセッサ１１９は、転送先ノード１０１の宛先に、自アドレス情報（サイト番号、ノード番号、ＬＤＥＶ番号、ＬＢＡ、ＴＬ（Ｔｒａｎｓｆｅｒ　Ｌｅｎｇｔｈ））及び中間コードであることを示す識別子と共に、中間コードを転送する。ＬＤＥＶ番号はプールボリュームの識別子である。

　プロセッサ１１９は、例えば、レイヤ番号２の静的マッピングテーブル２１１を参照して、サイト冗長コードＱを最終的に格納する冗長コードノードを、転送先ノードと決定する。

　プロセッサ１１９は、例えば、レイヤ番号３の静的マッピングテーブル２１２Ａを参照して、転送先サイト（ジオ冗長コードＲの格納サイト）を決定する。例えば、サイトの代表ノード１０１が予め設定されており、プロセッサ１１９は、当該代表ノード１０１に上記付随しデータと共に、中間コードを転送する。

　代表ノード１０１は、ハッシュ関数を使用して転送元アドレス情報からハッシュ値を算出する。代表ノード１０１は、コンシステントハッシングテーブル２１２Ｂを参照し、算出したハッシュ値から、転送先ノード１０１を決定する。当該ノード１０１が、ジオ冗長Ｒの最終的な格納ノード（冗長コードノード）である。

　代表ノード１０１を介したデータ転送方法は、２回のデータ転送を必要とする点、代表ノード１０１へのアクセス集中、代表ノード１０１の障害による可用性低下の問題がある。したがって、複数代表ノード１０１を用意してラウンドロビンに転送先代表ノード１０１を選択してもよい。

　プロセッサ１１９は、代表ノード１０１に代わり、直接にジオ冗長コードＲを格納する他サイトノードを決定してもよい。具体的には、転送元ノード１０１は、転送先サイトのコンシステントハッシングテーブル２１２Ｂを予め保持し、プロセッサ１１９は、当該テーブルに従って転送先ノード１０１を決定する。

　各ノード１０１が他サイトのコンシステントハッシングテーブル２１２Ｂを保持する場合、コンシステントハッシングテーブル２１２Ｂのサイト間の同期がオーバヘッドとなる。そのため、分散型ストレージシステムは、排他更新による密な同期をせず、定期的に更新を行ってもよい。その場合、他サイトから中間コードを受信した宛先ノード１０１が、正しい宛先であるかを、自サイトのコンシステントハッシングテーブル２１２Ｂを参照して判定し、転送先が間違っていた場合、正しいノード１０１に受信データを転送してもよい。

　転送先ノード１０１において、中間コードと同一転送元アドレスのダーティデータが存在する場合、転送先ノード１０１のプロセッサ１１９は、中間コードとそのダーティデータのｘｏｒを算出して、キャッシュ１８１上のデータを更新する。転送先ノード１０１のプロセッサ１１９は、当該中間コードに関するキャッシュ情報を、中間ダーティキュー９０４に接続する。転送先ノード１０１は、同一冗長コードの元となる異なる転送元からの中間コードのｘｏｒを算出して、キャッシュ１８１上のデータを更新してもよい。

　ステップＳ６０６において、中間コードを転送しないと判定した場合（Ｓ６０６：Ｎ）、プロセッサ１１９は、対象ノード（転送先）のキャッシュ１８１に、ライトデータを書き込む（Ｓ６０７）。本例は、ライトデータを基本的にアクセスを受けたノードに優先して格納する。上述のように、ライト先とは別の対象ノード（転送先）にデータを転送することで、キャッシュ上で冗長性を担保した状態となる。さらに、別途、ノード間の冗長データを生成することで冗長性を維持したまま冗長コードのためのストレージ容量を削減し、効率化する。

　転送先ノード１０１の決定方法及びデータ転送方法は、ステップＳ６１０における方法と同じである。転送元ノード１０１は、転送先ノードに、転送データの自アドレス情報（サイト番号、ノード番号、ＬＤＥＶ番号、ＬＢＡ、ＴＬ）と通常データであることを示す識別子と共に、ライトデータを転送する。転送先ノード１０１において、プロセッサ１１９は、ライトデータに対応するキャッシュ情報を、対応する冗長コードのダーティキュー９０１に接続する。

　ライト流量の低減を目的とし、自系のプールボリュームではなく、他系のプールボリュームへのライトデータのライトにおいて、従来のＥｒａｓｕｒｅ　Ｃｏｄｉｎｇ方式を採用してもよい。従来のＥｒａｓｕｒｅ　Ｃｏｄｉｎｇ方式は、ライトデータをストライプ分割し、分割したデータで冗長データを生成し、分割データと冗長データを複数のノードに分散して格納する。

　冗長コードにエンコード方式の情報を含めることで、いずれの冗長コード生成方法を使用しているかを判定できるようにしてもよい。従来のＥｒａｓｕｒｅ　Ｃｏｄｉｎｇ方式の適用先は、他系からのリードによってネットワークがボトルネックとならないデータのみに限定してもよい。

　図１７は、非同期ライト処理のフローチャートを示す。本処理は、ホストＩ／Ｏとは非同期に実行され、Ａｓｙｎｃが指定された保護レイヤで、まだ他系に転送されていないデータを転送する。図１７におけるステップＳ７０２～Ｓ７０８は、図１６におけるステップＳ６０５～Ｓ６０８と同様である。ここでは、差分のみを説明する。各ノード１０１において、プロセッサ１１９は、ページマッピングテーブル２１５を参照し、登録されている全仮想ボリュームについて、本処理を実行する。

　プロセッサ１１９は、対象の仮想ページが非同期ライトの対象であるかを判定する（Ｓ７０１）。具体的には、プロセッサ１１９は、データマッピングテーブル７０１において、仮想ページに対応するプールボリューム上の領域の状態をチェックする。当該保護レイヤにおいて、”未完了”の状態であれば、プロセッサ１１９は、非同期ライト対象と判定し（Ｓ７０１：Ｙ）、ステップＳ７０２に進む。

　全ての仮想ページの処理が終了したら（Ｓ７０９：Ｙ）、プロセッサ１１９は、本フローを終了する。プロセッサ１１９は、非同期ライト処理を周期的に実行してもよいし、常時実行してもよい。プロセッサ１１９は、”未完了”状態のページ量に応じて本処理の実行頻度やデータ転送速度を動的に変更してもよい。

　図１８は、デステージ処理のフローチャートを示す。本処理はキャッシュ１８１上にダーティデータ、つまり、ドライブ１１３に未反映のデータが存在する場合に、ホストＩ／Ｏと非同期で実行される。冗長データの生成は、基本的に各ノード内で処理が完結する（ノード内で別の送り主からのデータ同士で冗長データを生成する）ため、冗長データの生成のためのノード間の通信量を低減できる。また、冗長データの送り先は、静的マッピングテーブル２１１によって多数のノード間で分散しているため、デステージ処を効率的に分散処理することが出来る。

　キャッシュ１８１には、２種類のダーティデータが存在する。一つは、自系のドライブ１１３に格納されるライトデータである。他の一つは、冗長データ生成のために他ノード１０１から転送されたデータである。ここで、他ノードから転送されたデータは、中間コードを含む。

　ダーティデータは、データダーティキュー９００、コードダーティキュー９０１及び中間ダーティキュー９０４で管理されている。図１８のフローチャートは、データダーティキュー９００及びコードダーティキュー９０１で管理されているダーティデータのデステージを示す。

　本処理が開始されると、プロセッサ１１９は、データダーティキュー９００及びコードダーティキュー９０１を参照し、対象のダーティデータを見つける。プロセッサ１１９は、対象データが、自系のドライブ１１３に格納するライトデータか否かを判定する（Ｓ８０１）。対象データがデータダーティキュー９００によって示されている場合、対象データはライトデータである。

　対象データがライトデータの場合（Ｓ８０１：Ｙ）、プロセッサ１１９は、当該ライトデータを自系のドライブ１１３に書き込む（Ｓ８０８）。データは、ログ構造化形式で格納される。ライトデータをドライブ１１３にログ構造化形式で格納する際に、プロセッサ１１９は、図８で示すように、プールボリュームにおける論理アドレスとドライブ１１３における物理アドレスとの対応関係及びデータの状態を、データマッピングテーブル７０１に記録する。

　さらに、プロセッサ１１９は、逆マッピングテーブル７０３において、プールボリュームにおける論理アドレスとドライブ１１３における物理アドレスとの対応関係を記録する。ドライブ１１３に空き領域が無い場合、プロセッサ１１９は、図１９を参照して述べる容量枯渇管理処理を実行してからドライブ１１３へのデータのライトを実行してもよい。

　プロセッサ１１９は、全ダーティデータを処理したかどうかを判定する（Ｓ８０６）。全ダーティデータの処理が終了している場合（Ｓ８０６：Ｙ）、プロセッサ１１９は、本フローを終了する。

　対象データがライトデータではない場合、つまり、対象データが冗長コード生成のためのストライプである場合（Ｓ８０１：Ｎ）、プロセッサ１１９は、同一ストライプタイプのダーティデータを見つける（Ｓ８０２）。

　具体的には、プロセッサ１１９は、コードダーティキュー９０１における対象データのキューにおいて、対象データを含む、異なるノード１０１から転送された複数のストライプを取得する。プロセッサ１１９は、ユーザ指定されたデータ保護の方針（ＸＤＹＰ：最大Ｄａｔａ数Ｘに対して冗長データ数Ｙ）に従い、できるだけＸ個のストライプを取得する。データ保護方針のユーザ指定については、図２７を参照して後述する。

　具体的には、プロセッサ１１９は、サイト静的マッピングテーブル２１１又はジオ静的マッピングテーブル２１２Ａが示すデータノードのＩＤ数を超えない範囲で、できるだけ多くのストライプを選択する。これにより、できるだけユーザ指定を満たす冗長化を行う。選択するストライプの転送元ノードは、全て異なる。対象データのキューが、当該ストライプタイプに属する全データノードそれぞれからのストライプを示す場合、プロセッサ１１９は、全データノードからのストライプを選択する。ストライプの選択において、転送元での論理アドレスは問わない。

　このように、冗長コード生成の要素となるストライプの数は固定されておらず、不定である。また、冗長コード生成の要素となるストライプの論理アドレスの組も不定である。これにより、転送されたストライプのみから効率的に冗長コードを生成できる。コードダーティキュー９０１において、同一ストライプタイプの他ノード１０１からのストライプが存在しない場合、プロセッサ１１９は、単一対象データを冗長コードとして、ドライブ１１３に格納してもよい。

　また、同期ライト処理時に、冗長コード生成先のノードにライトデータを転送する場合、その時点では転送元ノードのドライブに、対応するライトデータがデステージされていないタイミングで、新たに同期ライト処理が発生すると、キャッシュ上でライトデータが新しく上書きされ、データの復元ができなくなる可能性がある。

　このため、冗長データ格納先ノードでは、転送元ノードがデステージ完了したデータのみ冗長データの生成に使用しなければならない。この実現のために、転送元ノードがデステージした旨を、冗長データ格納先ノードに通知し、その通知を受け取った場合のみ冗長データ格納先ノードでのデステージ対象としてもよい。また、上記は転送元ノードでのデステージタイミングで冗長データ格納先ノードにデータ転送するようにしてもよい。また、キャッシュ上のデータ更新時に上書きしないように（例えばログバッファ形式で保存）してもよい。

　プロセッサ１１９は、中間ダーティキュー９０４における同一ストライプタイプのキューからダーティデータを見つけてもよい。プロセッサ１１９は、ドライブ１１３に格納されている対応冗長コードと中間コードのｘｏｒを算出して冗長コードを更新する。更新された冗長コードが、対象データの転送元ノード１０１とは異なるノード１０１のストライプのみから生成されている場合、プロセッサ１１９は、対象データと更新冗長コードから新たな冗長コードを生成する。

　プロセッサ１１９は、できるだけ旧データ（旧ストライプ）の比率が大きくなるように、冗長コードを生成するストライプを選択してもよい。プロセッサ１１９は、旧ストライプのみで冗長コードを生成できる場合、そのようにストライプを選択する。冗長コード生成における旧データの比率を大きくすることで、当該冗長コードが無効データとなる時期を早め、冗長コード格納領域の空き容量を効率的に増加させることができる。

　プロセッサ１１９は、選択したストライプから冗長コードを算出し、ドライブ１１３に書き込む（Ｓ８０３）。ドライブ１１３へのライトは、ステップＳ８０８と基本的には同様にログ構造化形式による追記である。これにより、旧データの読み出しを省略し、高速及び効率的な冗長コードの生成及びドライブライト処理を実現する。

　プロセッサ１１９は、データマッピングテーブル７０１ではなく、冗長コードマッピングテーブル７０２に算出した冗長コードの格納先の物理領域とプールボリュームのページの対応関係を記録する。プロセッサ１１９は、さらに、逆マッピングテーブル７０３において、プールボリュームにおける論理アドレスとドライブ１１３における物理アドレスとの対応関係を記録する。冗長コードは複数ストライプから生成されるため、マッピングテーブルは、一つの物理アドレスに対して複数の参照を持つ。

　プロセッサ１１９は、冗長コードをドライブ１１３にライトしたら、転送元ノード１０１に通知する（Ｓ８０５）。転送元ノード１０１は、データマッピングテーブル７０１における対象データの対象レイヤの状態を“完了”に変化させる。状態フィールドは、ノード障害時に当該データを再転送対象とするかどうかを判定するために参照される。全ダーティを処理完了したら（Ｓ８０６：Ｙ）、プロセッサ１１９は、本フローを終了する。

　また、Ｅｒａｓｕｒｅ　Ｃｏｄｉｎｇなど２個以上の冗長コードを持つ符号化を用いる場合、それぞれの冗長コードを生成する複数のノードにおいて、独立に別々のデータの組み合わせで冗長コードを生成すると、データ復元が困難（ＭＤＳ性が失われる、復元のための計算量が増大化する等）となる場合がある。

　そこで、１個目の冗長コードを生成するノードで冗長コードを生成した後、静的マッピングテーブル２１１を参照して２個目以降の冗長コードを生成するノードを特定し、１個目の冗長コードを生成するノードにて冗長コードを生成したデータのアドレスの組を、２個目以降の冗長コードを生成するノードに通知する。

　２個目以降の冗長コードを生成するノードは、通知されたデータのアドレスの組で２個目以降の冗長コードを生成するようにすることで、ＭＤＳ性を保ち、データ復元を可能とすることが出来る。また、その他の方法として、１個目の冗長コードを生成するノードが２個目以降の冗長コードを生成し、冗長コードを対応するノードに転送するようにして、実現する方法も考えられる。

　中間コードのデステージにおいて、プロセッサ１１９は、ドライブ１１３に格納されている旧冗長コードと、中間コードとから新たな冗長コードを生成し、ドライブ１１３における旧冗長コードにオーバー書き込む。オーバーライトのため、マッピングテーブルは変わらない。中間コードによる冗長コードの更新は、旧データのリードを必要とするが、冗長コードノードにおけるローカル領域使用量を低減できる。

　中間ダーティキュー９０４に、一つの冗長コードに対する複数の中間コードが存在する場合、プロセッサ１１９は、全中間コードのｘｏｒを算出して新中間コードを生成、当該新中間コードによって冗長コードを更新する。同一冗長コードに対応する中間コードは、同一論理アドレスの異なる世代のデータ及び異なるノード１０１の中間コードを含む。

　例えば、旧冗長コードがＡｘｏｒＢであるとする。同一冗長コードに対応する中間コードの例は、中間コードＡｘｏｒＡ‘、中間コードＢｘｏｒＢ‘、中間コードＡ‘ｘｏｒＡ‘‘である。ここで、Ａ‘‘が最新データであり、Ａ‘最古データである。また、データＢが新データであり、データＢ’が旧データである。

　プロセッサ１１９は、冗長コードマッピングテーブル７０２を使用して、中間ダーティキュー９０４から選択した中間コードの冗長コードの物理アドレスを知ることができる。さらに、プロセッサ１１９は、逆マッピングテーブル７０３を使用して、当該冗長コードに対応する中間コードの論理アドレスを特定することができる。

　冗長コード更新の具体例を、以下に示す。以下では、リードソロモン符号を用いたＲＡＩＤ６（ガロア係数：Ａ１～Ａ３）を例に挙げる。

（１）コードダーティキュー９０１
　プロセッサ１１９は、ダーティキュー９０１からＸ１～Ｘ３のダーティデータを選択し、下記の式で、冗長コードＰ１又はＰ２を算出する。
　　Ｐ１＝Ｘ１ｘｏｒＸ２ｘｏｒＸ３
　　Ｐ２＝（Ｘ１＊Ａ１）ｘｏｒ（Ｘ２＊Ａ２）ｘｏｒ（Ｘ３＊Ａ３）
　冗長コードＰ１、Ｐ２は、それぞれ、自系のストレージデバイスの新規領域にライトされる。

（２）中間ダーティキュー９０４
　プロセッサ１１９は、中間ダーティキュー９０４から、自系のドライブ１１３にライト済みの旧冗長データＰ１’又はＰ２’に対応する新らたな中間ダーティデータＭ１、Ｍ２を抽出する。中間ダーティデータの個数は２とは限らない。プロセッサ１１９は、下記の式で新中間コードＭＰ１又はＭＰ２を算出する。
　　ＭＰ１＝Ｍ１ｘｏｒＭ２
　　ＭＰ２＝（Ｍ１＊Ａ１）ｘｏｒ（Ｍ２＊Ａ２）

　プロセッサ１１９は、下記の式で新たな冗長コードＰ１又はＰ２を算出する。
　　Ｐ１＝Ｐ１’ｘｏｒＭＰ１
　　Ｐ２＝Ｐ２’ｘｏｒＭＰ２
　新冗長コードＰ１、Ｐ２は、を旧領域（Ｐ１’、Ｐ２’）にオーバーライトされる。

　上述のように、冗長コードノード１０１は、一つのストライプタイプ内のストライプから動的にストライプを選択し、選択したストライプから冗長コードを生成する。これにより、既存冗長コードを読み出すことなく、転送されたストライプから効率的に冗長コードを生成することができる。

　本例におけるストライプの動的な選択は、選択するストライプの組み合わせ及びストライプ数の少なくとも一方が不定である選択である。上記例は、ストライプ数及びアドレス組み合わせの双方から独立してストライプを選択するが、その一方が固定されていてもよい。ここで、アドレス組み合わせにおけるアドレスは、ノード、ボリューム及びボリューム内アドレスで指定されるアドレスである。

　冗長コードのドライブライトに、ログ構造化方式が適用されてなくてもよい。つまり、ノード１０１は、旧冗長コードと同一アドレス組み合わせから生成した新冗長コードローカル領域に追記することなく、旧冗長コードを新冗長コードに書き換えてもよい。ログ構造化方式が採用されない構成において、既存の全冗長コードと異なるアドレス組み合わせの冗長コードは、ローカル領域に追記される。

　上記例は、予め定義されたストライプタイプ内のストライプのみから冗長コードを生成する。これと異なり、システムは、ストライプタイプを定義することなく、任意のストライプの組み合わせから冗長コードを生成してもよい。

　図１９は、容量枯渇管理の処理のフローチャートを示す。本処理は、ドライブ１１３上のデータ量が設定された目標量を超えている場合に、データの消去を試みる。これにより、必要なデータを限られた領域に格納できる。消去されるデータの種類は、ライトデータ（ストライプ）と冗長コードである。本処理はホストＩ／Ｏとは非同期に実施してもよい。使用量と目標量の関係は、ローカル領域量テーブル８０２に示される。

　なお、図１９のフローチャートは、冗長コード領域及びデータストライプ領域のデータ消去に適用され、スペア領域におけるデータ消去には適用されない。階層毎にローカル領域量テーブル８０２が使用されている場合、階層毎に本処理が実行される。

　プロセッサ１１９は、ローカル領域量テーブル８０２を参照し、選択した対象データタイプの使用量が、目標量を超過しているかどうかをチェックする（Ｓ９０１）。対象データタイプの使用量が超過している場合（Ｓ９０１：Ｙ）、プロセッサ１１９は、対象データタイプが、冗長コードタイプか否か判定する（Ｓ９０２）。

　本例おいて、ローカル領域量テーブル８０２に示されるように、データタイプは、冗長コードタイプ、ライトデータタイプ（ストライプタイプ）及びスペア領域上のデータタイプに分類される。さらに、冗長コードタイプは、ノード冗長コード、サイト冗長コード、ジオ冗長コードの各タイプ分類され、ライトデータタイプは、各サイトストライプタイプに分類される。

　使用量を超過しているデータタイプがいずれかの冗長コードタイプである場合（Ｓ９０２：Ｙ）、プロセッサ１１９は、無効リスト８０１Ｂ及びログ構造化マッピングテーブル２１３を参照して、当該冗長コードタイプの冗長コードを検索する（Ｓ９０７）。無効冗長コードは、算出元の全ストライプが無効の冗長コードである。算出元の全ストライプ算出元の全ストライプが更新済みの旧データであり、当該冗長コードは消去可能である。

　対象冗長コードタイプの無効冗長コードがある場合（Ｓ９０７：Ｙ）、プロセッサ１１９は、その領域を開放する（Ｓ９０８）。領域開放は、冗長コードマッピングテーブル７０２における対象領域の物理アドレスとプールボリュームの論理アドレスの関係を削除し、無効リスト８０１Ｂから対象領域を削除してフリーリスト８０１Ｃに再接続し、ローカル領域量テーブル８０２において対応する冗長コードタイプの領域使用量を削減する。

　対象冗長コードタイプの無効冗長コードがない場合（Ｓ９０７：Ｎ）、プロセッサ１１９は、冗長コードのマージ処理を実行する（Ｓ９０９）。本処理により、冗長コードの使用量を削減できる。

　例えば、冗長コードＰ１＝Ｘ’ｘｏｒＹ’ｘｏｒＺと（’は無効データを表す）、冗長コードＰ２＝ＪｘｏｒＫｘｏｒＬ’が存在し、ＪとＫとＺがそれぞれ別ノードに存在するストライプである場合、プロセッサ１１９は、Ｐ１ｘｏｒＰ２ｘｏｒＸ’ｘｏｒＹ’ｘｏｒＬ’により、新たな冗長コードＰ３＝ＪｘｏｒＫｘｏｒＺを算出ができる。

　プロセッサ１１９はログ構造化マッピングテーブル２１３を参照して、冗長コードを構成するストライプの論理アドレス及び世代情報を取得する。プロセッサ１１９は、Ｘ’、Ｙ’、Ｌ’を、他ノード１０１から取得する。

　プロセッサ１１９は、上記冗長コードＰ１、Ｐ２の領域を開放し、新たな冗長コードＰ３をドライブ１１３に書き込むことで、冗長コードによる使用量を削減できる。冗長コードによる使用量の削減量が大きくなるように、冗長コードを優先的に選んで、実施してもよい。

　マージ処理後、プロセッサ１１９は、対象冗長コードタイプによる使用量が目標量を超過しているかを再チェックする（Ｓ９１０）。使用量が目標量を超過している場合（Ｓ９１０：Ｙ）、プロセッサ１１９は、リバランス処理を実行する（Ｓ９０６）。後述するように、リバランス処理は、プールボリューム間でページ使用量を調整する。例えば、データを他階層のプールボリューム又は他ノード１０１のプールボリューム（他系プールボリューム）に移動する。リバランス実行後、プロセッサ１１９は、ステップＳ９０１に進む。対象冗長コードタイプの使用量が目標量を超過していない場合（Ｓ９１０：Ｎ）、プロセッサ１１９は、ステップＳ９０１に進む。

　対象データタイプが冗長コードタイプではない、つまりいずれかのストライプタイプである場合（Ｓ９０２：Ｎ）、プロセッサ１１９は、対象ストライプタイプにおいて、消去可能なライトデータ（ストライプ）があるかを判定する（Ｓ９０３）。消去可能なストライプは、更新済みの旧ストライプであり、無効ストライプである。プロセッサ１１９は、無効リスト８０１Ｂ及びログ構造化マッピングテーブル２１３を参照して、当該ストライプタイプの無効ストライプを検索する。

　消去可能なストライプがある場合（Ｓ９０３：Ｙ）、プロセッサ１１９は、冗長コードのクリーンアップ処理を実施する（Ｓ９０４）。この処理は、消去しようとしているストライプに対応する冗長コードのクリーンアップを実施する。サイト冗長コード及びジオ冗長コードの双方のクリーンアップが実施される。具体的には、各保護レイヤにおいて、以下のステップが実行される。

　（１）プロセッサ１１９は、消去対象ストライプの冗長コードノード１０１に、消去対象ストライプを含む冗長コードがあるかを問い合わせる。対象ストライプは、例えば、サイト番号、ノード番号、ＬＤＥＶ番号及びＬＢＡにより指定される。

　（２）問い合わせ先冗長コードノード１０１ノードにおいて消去対象ストライプを含む冗長コードがある場合、プロセッサ１１９は、消去対象ストライプを、当該冗長コードノード１０１に送信する。冗長コードが存在しない場合、当該処理は終了する。

　（３）冗長コードノード１０１は、受け取った消去対象ストライプによって現在冗長コードから消去対象ストライプを消去することで、新しい冗長コードを生成する。例えば、冗長コードノード１０１は、消去対象ストライプと旧冗長コードのｘｏｒを計算し、新冗長コードを生成する。冗長コードノード１０１は、ドライブ１１３に格納されている旧冗長コードを、新冗長コードでオーバー書き込む。

　上記ストライプ消去に伴う冗長コードの更新により、冗長コードの生成元ストライプの消去によって、当該冗長コードの他のストライプの冗長度が減少することを防ぐ。

　冗長コードノードが冗長コードを消去する場合、当該冗長コードノードに対応するストライプが最新バージョンであるか問い合わせてもよい。ストライプは、逆マッピングテーブル７０３が示す論理アドレスで指定される。対応ストライプが最新バージョンである場合、冗長コードノードは、当該ストライプの新たな冗長コードを再生成する。

　次に、プロセッサ１１９は、対象領域を開放する（Ｓ９０５）。これはステップＳ９０８と同様である。その後、プロセッサ１１９は、ステップＳ９０１に戻る。

　スペア領域の使用量が目標量を超えている場合、例えば、プロセッサ１１９は、図１９のフローチャートにおけるストライプの消去を行った後、冗長コードの消去を実行し、さらに、リバランスを実行する。ストライプ消去と冗長コード消去順は逆でもよい。いずれかのステップで使用量が目標量以下になった場合、その後のステップは不要である。

　図２０は、容量枯渇管理の処理の概念を示す。本図は、冗長コードのクリーンアップ処理を示している。ノード１０１Ａは、書き込むストライプ７８１を、ノード１０１Ｂに転送する（Ｔ２１２）。ノード１０１Ｃと１０１Ｄも、同様に、ストライプ７８２、７８３をノード１０１Ｂに転送する。転送ストライプ７８１～７８３を、それぞれＺ、Ｄ、Ｊで表している。

　ここで、ノード１０１Ａのドライブ１１３が枯渇した場合、つまり、ノード１０１Ａのドライブ１１３における使用量が閾値を超えた場合、ノード１０１Ａは、古いデータを消去しようとする。古いストライプをＸ’’とする。Ｘ’やＸ’’などは、過去データ（無効データ）を表し、Ｘは現在データを表す。

　過去ストライプのみによって生成された冗長コードは、もはや保持する意味がなく、消去できる。しかし、現在ストライプを含むストライプセットから生成された冗長コードは、消去できない。また、そのような冗長コードがある場合に、その冗長コードの生成に使用した過去ストライプはドライブから消去できない。ストライプを復元不能となってしまうためである。

　したがって、ノードは、過去ストライプを消す前に、そのストライプの冗長コードを格納しているノードに、ストライプを送信し、クリーンアップする。例えば、図２０において、ノード１０１Ｂに、Ｘ’’ｘｏｒＣｘｏｒＨという冗長コードが存在する。ノード１０１Ａは、過去ストライプＸ’’を消去する前に、過去ストライプＸ’’をノード１０１Ｂに送信する（Ｔ２０２）。

　ノード１０１Ｂは、過去ストライプＸ’’と、冗長コードＸ’’ｘｏｒＣｘｏｒＨから、Ｘ’’ｘｏｒＣｘｏｒＨｘｏｒＸ’’によりＣｘｏｒＨを算出する。その後、ノード１０１Ａは、ドライブ１１３の過去ストライプＸ’’を消去する。

　図２１は、退避リビルド処理のフローチャートを示す。本処理は、分散型ストレージシステム内で異常が発生すると、異常に対応すべき各ノード１０１により実行される。各ノード１０１のプロセッサ１１９は、保護レイヤ毎の状態制御テーブル、具体的には、ドライブ状態管理テーブル２２１、ノード状態管理テーブル２２２、サイト状態管理テーブル２２３を参照することで、異常発生を検知できる。上述のように、いずれかのノード１０１が検出した異常についての情報は、システム内で共有される。

　図２１において、ノード１０１は、異常リソース（ドライブ、ノード、サイトなど）が閉塞かどうかを判定する（Ｓ２１１）。リソースの状態には３種類ある。“通常”状態と“閉塞”状態と“警告”状態である。ノード１０１は、保護レイヤ毎の状態管理テーブルを参照することで異常リソースの状態を判定できる。

　図１１を参照して説明したように、ノードやサイト等いずれかのリソースで障害が発生した場合、当該リソースが保持するデータをリビルドするノード（スペアノード）は、予め設定されている。各ノード１０１は、自ノードがスペアノードとなるリソース及びリビルドすべきデータを示す情報を保持しており、プロセッサ１１９は、自ノードが対応するリソースの閉塞状態を検知すると、必要なデータをリビルドする。

　状態管理テーブルにおける状態が“閉塞”の場合、プロセッサ１１９は、異常リソースの状態が閉塞であると判定し（Ｓ２１１：Ｙ）、優先リビルドを実行する（Ｓ２１２）。優先リビルドは、当該保護レイヤにおいて冗長度の低いストライプタイプのデータから順番にリビルドを実行する。

　リビルドは、消失したデータを残っているストライプ及び冗長データから回復する。ノード１０１は、各保護レイヤの静的マッピングテーブル２１０～２１２を参照して、エラーリソースが格納しているデータの消失により冗長度が低下するストライプタイプ及びその冗長度数を知る。

　ノード１０１は、互いに実行する処理及び当該処理の進捗を通知し、他のノード１０１によるより低い冗長度の優先リビルドの完了を待つ。例えば、ノード１０１は、他のノード１０１が冗長度０のストライプタイプのリビルド完了を待って、冗長度１のストライプタイプのリビルドを開始する。これにより、冗長度０のストライプタイプのリビルド時間が、冗長度１のストライプタイプのリビルドにより長時間化することを避けることができる。

　ＭＤＳ（Ｍａｘｉｍｕｍ　Ｄｉｓｔａｎｃｅ　Ｓｅｐａｒａｂｌｅ）性を持つＥｒａｓｕｒｅ　Ｃｏｄｉｎｇ手法を用いると、任意の冗長度個数のデータの消失に対してデータ復旧可能であることが、一般に知られている。

　基本的に、リビルドされたデータを自系のストレージデバイスに保持するスペアノードが、冗長コードとストライプをリードし、当該データをリビルドする。スペアノードが高負荷の場合は、他ノードがデータをリビルドして、スペアノードに転送してもよい。

　また、障害ノードのデータが不要な場合、例えば、仮想ボリュームのオーナがない場合、スペアノードでリビルドすることなく、冗長コードの変更のみ行ってもよい。例えば、スペアノードは、ゼロデータをライトし、冗長コードノードは、旧冗長コードの消失ストライプ以外のストライプとゼロデータによって新たな冗長コードを生成する。

　閉塞リソースにより消失した上位保護レイヤの冗長コードは、再生成される。例えば、あるノードのドライブで障害発生した場合、当該ノード１０１は、当該ノード１０１内のサイト冗長コードとジオ冗長コードを再生成する。当該ノード１０１は、他のノード１０１に、サイト冗長コードとジオ冗長コードそれぞれの生成に必要なストライプを転送することを要求する。ノード１０１は、冗長コードマッピングテーブル７０２及び逆マッピングテーブル７０３からストライプを保持するノードを特定できる。

　ノード内で、サイト冗長コードとジオ冗長コードを冗長化してもよい。冗長化によるオーバヘッド（プロセッサ処理時間、ストレージ容量、フラッシュメディア寿命消費など）が増加するが、ドライブ障害におけるノード間通信が不要となる。また、ノードは、優先リビルドの実行後に、静的マッピングテーブル２１０～２１２における該当ストライプタイプの登録ノードを、スペアノードによって更新する。

　また、旧データ（新データがライトされたデータ）については、そのデータを用いて冗長コードを生成している場合、その冗長コードに対応した複数のデータのうち、新データのみをパリティ格納ノードでダーティ化することで、冗長コードを再生成する必要がある。

　各ノード１０１は、当該保護レイヤの全ストライプタイプの冗長度が回復したかどうかをチェックする（Ｓ２１３）。ノード１０１は、データ回復の完了を互いに通知する。当該保護レイヤにおける全ストライプタイプの冗長度が回復すると、処理は、ステップＳ２１４に進む。すべてのレイヤで処理が完了していない場合（Ｓ２１４：Ｎ）、分散型ストレージシステムは、より上位の保護レイヤについて、ステップＳ２１１から再度実行する。

　すべてのレイヤの処理が完了すると（Ｓ２１４：Ｙ）、分散型ストレージシステムは、仮想ボリュームのオーナの見直しを実施する（Ｓ２１５）。具体的には、あるノード１０１が閉塞になった場合、予め定められた他のノード１０１が、そのノード１０１で持っていた仮想ボリュームを引き継ぐ。

　ステップＳ２１１で閉塞ではないと判定された場合（Ｓ２１１：Ｎ）、つまり状態が“警告”の場合、ノード１０１は、データ退避が必要か否かを判定する（Ｓ２１６）。この要否は、分散型ストレージシステム内でデータ消失が発生するリスクの度合に基づき判定される。

　一般的に、“警告”状態となったドライブは、“正常”のドライブと比較し、故障する確率が高くなることが知られている。しかし、“警告”状態となっても、そのドライブが故障しない場合もある。したがって、ストレージシステムの負荷上昇と退避処理によるデータ消失のリスク回避とのトレードオフとなる。

　例えば、システム冗長度が２の場合に、２個以上のドライブが“警告”状態となった場合、警告状態のストライプが多いストライプタイプのデータから優先して退避すると、退避のための移動データ量を削減でき、効率的である。ここでシステム冗長度は、システム全体で最小の冗長度数である。

　一例において、ノード１０１は、Ｎ個以上のリソースが“警告”状態となった場合に、ステップＳ２１６で退避要であると判定する。Ｎはシステム冗長度に基づき予め設定されている整数である。退避が必要と判定した場合（Ｓ２１６：Ｙ）、ノード１０１は、優先退避を実行する（Ｓ２１７）。

　優先退避は、警告状態となっているリソースに格納されたデータにおいて冗長度の低いデータを、予め定められているスペア領域にコピーする。データの退避先は、リビルドと同様である。退避先のデータ領域（スペア領域）において、ＬＲＵキャッシュのように、警告が発生するたびに退避データが上書きされてもよい。

　上記例は、ストライプタイプの冗長度数に基づいて実行優先度を決定するが、ノード１０１は、ストライプ及び冗長コードの冗長度数に基づいて実行優先度を決定してもよい。ストライプ及び冗長コードは、複数保護レイヤに属し、それらの総冗長度数が当該データの冗長度数である。これにより、リビルド／退避処理の進行と共に、システム冗長度を上げることができる。

　上述のように、ノード（サイト）が閉塞となった場合に、他のノード（サイト）で処理を継続するために、仮想ボリュームのオーナをあらかじめ分配しておく。例えば、サイト内に異なるノード及び他サイトのノードが、それぞれ、同一仮想ボリュームのオーナと設定される。

　リビルドや退避の高速化のために、保護レイヤを跨いで、リビルド処理や退避処理を実行してもよい。例えば、あるドライブが故障してリビルド処理を実行する場合、ノード内でリビルド処理を実行するのに加え、それと同時にノード間の冗長コードを用いてドライブのデータを修復する。これにより、より多くのドライブから同時にデータを読み出すことが出来、リビルドを高速に実行することができる。保護レイヤを跨いで回復するかどうかは、ネットワーク負荷、許容負荷などに応じて、実行の度合いを調整してもよい。

　図２２は、データリシンク処理のフローチャートを示す。本処理は、電断時の復活処理又はコピーバック処理として実行される。コピーバック処理は、リビルド後、リソース交換後のスペア領域のデータから新リソースへのコピー処理である。本処理の実行完了後、リソースの状態は、正常状態となる。

　本処理を実行しているノード１０１のプロセッサ１１９は、実行すべき処理が、復活処理かどうかを判定する（Ｓ２２１）。具体的には、プロセッサ１１９は、自ノードが新しいノードであるか、又は電断などの障害から復旧している状態であるかを判定する。障害から復旧している場合は、プロセッサ１１９は、復活処理であると判定する（Ｓ２２１：Ｙ）。

　より具体的には、プロセッサ１１９は、分散型ストレージシステム内の共有情報として、ＬＡＮコントローラのｍａｃアドレスのようにノード毎に一意に決まる識別子とノード番号の対応テーブルを保持し、当該対応テーブルを参照して、自ノードのストレージシステムへの登録の有無を判定する。

　復活処理である場合（Ｓ２２１：Ｙ）、プロセッサ１１９は、回復が必要な領域を検査する。具体的な回復要の領域を検査する方法は、冗長コードについては、他ノード１０１のデータマッピングテーブル７０１の状態を参照し、未反映状態の冗長コードのストライプを、他ノード１０１から取得する。冗長コードがスペア領域にリビルドされている場合、プロセッサ１１９は、当該冗長コードを取得する。

　ライトデータ（ストライプ）については、他ノード１０１は、障害発生後にライトされた差分をビットマップで管理している。プロセッサ１１９は、その差分のみをスペア領域からコピーバックして回復する。また、プロセッサ１１９は、自系の逆マッピングテーブル７０３を参照して最終の更新時刻を特定し、その最終更新時刻以降にライトされた有効データを他ノード１０１に要求してもよい。このように、プロセッサ１１９は、回復対象のライトデータ（ストライプ）及び冗長コードを決め、領域回復処理を実行する（Ｓ２２５）。

　実行すべき処理が、復活処理ではない場合（Ｓ２２１：Ｎ）、プロセッサ１１９は、コピーバック処理を実行する。プロセッサ１１９は、スペア領域にリビルドされたライトデータ（ストライプ）及び冗長コードをコピーバックする。プロセッサ１１９は、当該処理を保護レイヤ階層毎に実行する。上位のレイヤについては、冗長コードのコピーのみ実行される。すべてのレイヤで処理が完了したら（Ｓ２２７：Ｙ）、本フローは終了する。

　図２３は、再配置処理のフローチャートを示す。本処理は、分散型ストレージシステムのページ配置を最適化する。本処理は、分散型ストレージシステムに新たにリソースを追加する場合、リソースを減設する場合、一部のプールボリュームの容量が枯渇している場合、負荷の変化を見直す一定周期毎、等に、各関連ノード１０１により実行される。

　本処理が開始されると、プロセッサ１１９は、各仮想ページの全Ｉ／Ｏ負荷を示すページ負荷分布テーブル２１７を基に、プールの全体閾値を算出する（Ｓ２３１）。仮想ページの全Ｉ／Ｏ負荷は、当該仮想ページの全オーナノードにおけるホストアクセスによる負荷の総計である。一方、各オーナノードにおける仮想ページへのホストアクセスによるＩ／Ｏ負荷を自系負荷と呼ぶ。仮想ページのＩ／Ｏ負荷は、例えば、Ｉ／Ｏ頻度で表わされる。

　全体閾値は、図１３の説明における、階層割り当て閾値と同様の方法で算出できる。各全体閾値は、階層間の境界ページＩ／Ｏ頻度を示す。プールにおける各階層の容量及びＩ／Ｏ性能は、各階層の全プールボリュームの容量及びＩ／Ｏ性能から決定される。不図示の管理情報によって、プールボリューム階層、容量及びＩ／Ｏ性能は管理される。

　次に、プロセッサ１１９は、各仮想ページの全Ｉ／Ｏ負荷を示すページ負荷分布テーブル２１７及び自ノードの自系負荷を示すページ負荷分布テーブル２１７を基に、各階層における自系閾値を算出する（Ｓ２３２）。自系閾値は、全体閾値により決定された階層内の仮想ページにおいて、自ノードに当該データを配置する仮想ページの境界Ｉ／Ｏ頻度を示す。

　図２４Ａ及び図２４Ｂは、それぞれ、自己閾値の決定方法の例を示す。図２４Ａ及び図２４Ｂのグラフの見方は、図１３におけるグラフ２７１と同様である。縦軸はページのＩ／Ｏ頻度で示されるページＩ／Ｏ負荷を示し、横軸は自系Ｉ／Ｏ負荷の高い順番に並べた仮想ページを示す。

　図２４Ａ、２４Ｂは、それぞれ、一つの階層における全Ｉ／Ｏ負荷ライン２４１及び自系Ｉ／Ｏ負荷ライン２４２を示す。上述のように、各階層に割り当てられる仮想ページは、仮想ページの全Ｉ／Ｏ負荷と全体閾値とで決定される。

　図２４Ａ、２４Ｂは、それぞれ、自ノード１０１がオーナの仮想ページにおいて、一つの仮想に割り当てられる仮想ページのＩ／Ｏ負荷分布を示す。自ノード１０１がオーナの仮想ページは、自系プールボリュームに割り当てられている仮想ページに加え、他系プールボリュームに割り当てられている仮想ページを含み得る。

　図２４Ａ、２４Ｂは、それぞれ、自系閾値２４６を示す。自系閾値２４６よりの高い自系Ｉ／Ｏ負荷の仮想ページは、自系プールボリュームに割り当てられる。現在他系プールボリュームに割り当てられている仮想ページのデータは、自系ドライブ１１３に移動される。

　自系閾値２４６以下の自系Ｉ／Ｏ負荷の仮想ページは、自系プールボリューム又は他系プールボリュームに割り当てられる。具体的には、プロセッサ１１９は、現在他系プールボリュームに割り当てられている仮想ページは、そのまま他系プールボリュームに割り当てられると判定する。プロセッサ１１９は、現在自系プールボリュームに割り当てられている仮想ページは、自系プールボリュームの空き容量に応じて、当該データを他ノード１０１に移動するか（リバランス）否か判定する。詳細は後述する。

　図２４Ａ、２４Ｂは、それぞれ、容量限界２４３、ドライブ性能限界２４４、及び許容ネットワーク限界２４５を示す。プロセッサ１１９は、自系プールボリュームに割り当てる仮想ページがこれら限界値内となるように、自系閾値２４６を決定する。

　本例において、プロセッサ１１９は、容量限界２４３、ドライブ性能限界２４４、及び許容ネットワーク限界２４５の最小値と自系Ｉ／Ｏ負荷ライン２４２との交点のページＩ／Ｏ負荷を、自系閾値２４６と決定する。図２４Ａにおいてドライブ性能限界２４４が最小値であり、図２４Ｂにおいて許容ネットワーク限界２４５が最小値である。

　容量限界２４３は、自系配置可能な容量限界を示す。容量限界２４３は、ノード１０１の自系プールボリューム容量とページサイズから、予め定められた式により決定される。自系プールボリュームに割り当てられる全仮想ページのサイズが、当該自系プールボリューム容量内となるように、ドライブ性能限界２４４が決定される。自系プールボリューム容量は、自系ドライブ１１３から形成されているプールボリュームの容量である。

　ドライブ性能限界２４４は、自系プールボリュームのアクセス性能と全Ｉ／Ｏ負荷ライン２４１とから、予め定められた式により決定される。プールボリュームのアクセス性能は、例えば、単位時間当たりのＩ／Ｏ量で示される。自系プールボリュームに割り当てられる仮想ページの全Ｉ／Ｏ負荷の総和が、当該自系プールボリュームのアクセス性能内となるように、ドライブ性能限界２４４が決定される。図２４Ａにおけるハッチング領域は、自系プールボリュームに割り当てられる仮想ページの全Ｉ／Ｏ負荷の総和を示す。

　一方、図２４Ｂにおいて、ハッチング領域は、他系Ｉ／Ｏ負荷の総和、つまり、（全Ｉ／Ｏ負荷－自系Ｉ／Ｏ負荷）を示す。許容ネットワーク限界２４５は、当該他系Ｉ／Ｏ負荷の総和と自系ネットワーク性能とから予め定められた式により決定される。ネットワーク性能は、例えば、単位時間当たりのＩ／Ｏ量で示される。

　仮想ページを次系プールボリュームに割り当てる場合、ノード１０１は、当該仮想ページの他系アクセスを、ネットワークを介して受信する。したがって、プロセッサ１１９は、他系Ｉ／Ｏ負荷が自系ネットワーク性能内となるように、ネットワーク限界２４５を決定する。

　上述のように、ドライブ性能及びネットワーク性能に基づき自系閾値を決定することで、ホストＩ／Ｏにおけるデータ転送におけるボトルネックの発生を抑制することができる。特にドライブ性能限界２４４を使用することで、他ノードに配置されるデータによるネットワーク上のボトルネック発生を効果的に抑制できる。なお、容量限界２４３は必須であるが、ドライブ性能限界２４４及び許容ネットワーク限界２４５は使用しなくてもよい。

　次に、プロセッサ１１９は、プールにおけるプールボリューム構成を見直す（Ｓ２３３）。プロセッサ１１９は、ステップＳ２３２における自系閾値の決定において、各階層において自系プールボリュームに割りあてる仮想ページ（自系仮想ページ）の総容量及び総Ｉ／Ｏ負荷を算出している。

　プロセッサ１１９は、これらの値と、各階層における自系ドライブ１１３の容量及び性能に基づいて、他系のプールボリューム１３０３Ｂにマッピングするプールボリューム１３０３Ｃの数を決定する。自系仮想ページ総容量又は総Ｉ／Ｏ負荷に対して自系ドライブ１１３の容量又は性能が不足する場合、プロセッサ１１９は、プールボリューム１３０３Ｃの数を増加させる。

　次に、プロセッサ１１９は、自ノード１０１がオーナである仮想ボリュームの仮想ページを順次選択して、以下のステップを繰り返し実行する。

　まず、プロセッサ１１９は、当該仮想ページのデータを他系プールボリュームから自系プールボリュームに移動する必要があるか判定する（Ｓ２３４）。具体的には、プロセッサは、全体閾値から当該仮想ボリュームの階層を決定し、さらに、自系閾値から当該仮想ページを自系プールボリュームに割り当てるか判定する。上述のように、プロセッサ１１９は、自系閾値よりＩ／Ｏ負荷が大きい仮想ページは、自系プールボリュームに割り当てると判定する。プロセッサ１１９は、自系閾値以下のＩ／Ｏ負荷の仮想ページは自系ボリュームに割り当てる必要がない、と判定する。

　当該仮想ページを自系プールボリュームに割り当てると判定され、かつ、当該仮想ページが現在他系プールボリュームに割り当てられている場合、プロセッサ１１９は、当該仮想ページのデータを他系プールボリュームから自系プールボリュームに移動する必要があると判定する。

　当該仮想ページを自系プールボリュームに割り当てる必要がないと判定された場合、又は当該仮想ページが現在自系のプールボリュームに割り当てられている場合、プロセッサ１１９は、当該仮想ページのデータを自系プールボリュームに移動する必要はないと判定する。

　データ移動が必要と判定された場合（Ｓ２３４：Ｙ）、プロセッサ１１９は、当該仮想ページのデータを自系プールボリューム（自系ドライブ１１３）に移動する（Ｓ２３５）。当該移動は、仮想ページの必要な階層移動を含む。

　具体的な手順は、以下のステップを含む。ステップ１は、データを自系のキャッシュ１８１にステージングする。ステップ２は、ページマッピングテーブル２１５の当該仮想ページの対応するプールボリューム領域を自系のプールボリュームに変更する。

　ステップ３は、データを自系プールボリュームにデステージする。ステップ４は、キャッシュ領域を開放する。ステップ５は、元の割り当てられていた他系プールボリュームのページ領域をクリアして（例えば、ゼロデータライト）フリー化する。つまり、当該ステップは、当該領域をローカル領域制御テーブル２１４のフリーリスト８０１Ｃに接続し、ローカル領域量テーブル８０２の使用量と有効量を削減する。

　このように、各ノード１０１が、自己閾値を使用して自系プールボリュームに移動する仮想ページを決定することで、当該仮想ページが複数のノード１０１に所有されている場合に、当該仮想ページのデータを保持する一つのノードが決定される。

　例えば、現在仮想ページのデータを保持しているノード１０１と他ノード１０１のそれぞれが当該仮想ページを自系プールボリュームに割り当てると判定した場合、他ノード１０１にデータは移動される。したがって、仮想ページのデータを保持するノード１０１と異なるノードであって、当該現在仮想ページを自系プールボリュームに割り当てると最後に判定したノード１０１が、当該仮想ページのデータを保持する。

　当該仮想ページのデータを自系プールボリュームに移動する必要はないと判定された場合（Ｓ２３４：Ｎ）、プロセッサ１１９は、階層移動が必要かどうかを判定する（Ｓ２３６）。当該仮想ページは自系プールボリュームに割り当てることが必要であると判定され、現在自系プールボリュームに割り当てらており、さらに、現在の階層が全体閾値から決定された階層と異なる場合、プロセッサ１１９は、階層移動が必要と判定する。

　階層移動が必要と判定された場合（Ｓ２３６：Ｙ）、プロセッサ１１９は、階層移動を実行する（Ｓ２３７）。階層移動の具体的な方法は、ステップＳ２３５と基本的には同様の方法で実現される。

　階層移動が不要と判定された場合（Ｓ２３６：Ｎ）、プロセッサ１１９は、当該仮想ページのリバランスが必要かどうかを判定する（Ｓ２３８）。本例において、仮想ページのリバランスは、当該仮想ページのデータを、現在プールボリュームから他系プールボリュームに移動する。

　プロセッサ１１９は、当該仮想ページは自系プールボリュームに割り当てる必要がなく、かつ、当該仮想ページが現在割り当てられている自系プールボリュームが枯渇していると判定した場合、当該仮想ページを他系プールボリュームに割り当てるリバランスが必要であると判定する。

　プロセッサ１１９は、当該階層のローカル領域量テーブル８０２を参照して、当該仮想ページのエントリの領域が枯渇（不足）しているか判定する。例えば、目標量から有効量を引いた値が閾値未満である場合、当該領域が枯渇していると判定される。

　リバランスが必要と判定された場合（Ｓ２３８：Ｙ）、プロセッサ１１９は、当該仮想ページのデータを、自系プールボリューム（自ノード）から他系プールボリューム（他ノード）に移動する（Ｓ２３９）。リバランスのページ移動の具体的な方法は、ステップＳ２３５と基本的には同様の方法で実現される。

　プロセッサ１１９は、他ノード１０１に問い合わせを行い、又は、他ノードからローカル領域量テーブル８０２の情報を取得して、当該仮想ページのデータを格納する枯渇していない領域を有する他ノード１０１を選択する。

　あるノード１０１が枯渇していない領域を有するか否かの判定は、当該ノード１０１における当該階層のローカル領域量テーブル８０２に基づく。移動先ノード１０１は、例えば、当該仮想ページのオーナノード及び当該仮想ページのストライプタイプに属するノードの中から選択される。

　未処理の仮想ページが残っている場合（Ｓ２４１：Ｎ）、プロセッサ１１９はステップＳ２３４に戻る。全仮想ページの処理が終了すると（Ｓ２４１：Ｙ）、プロセッサ１１９は、本処理を終了する。

　図２５Ａは、構成変更処理のフローチャートを示す。本処理は、分散型ストレージシステムの構成を変更する際に実行される。例えば、分散型ストレージシステムに新たにリソースを追加する場合に、各ノードが実行する。

　本処理が開始されると、プロセッサ１１９は、当該保護レイヤの静的マッピングテーブルを変更する（Ｓ２５１）。例えば、ノードが追加される場合、サイト保護レイヤの各ノード１０１は、ストライプタイプ数を増やし、複数ストライプタイプそれぞれのデータノード及び冗長コードノードを変更する。例えば、一つのノード１０１がストライプタイプの新たなノード構成を決定し、それに従って、各ノード１０１が静的マッピングテーブルを更新する。

　ノード１０１は、現在のマッピングテーブル２１１の一部のストライプタイプに対応したストライプノードの一部を新らたに増設するノードに変更し、前記一部のノードを複数選択して新たなストライプタイプに含める。

　図２５Ｂは、ノードを追加した場合のストライプタイプの追加及びストライプの再配置一例を示す。ノード１０１Ａ～１０１Ｄは既存ノードであり、ノード１０１Ｅが追加ノードである。各ノード内の矩形はストライプのデータ位置（アドレス）を示し、矩形内の数字はストライプタイプ番号を示す。ストライプタイプ１～ストライプタイプ５が既存のストライプタイプであり、ストライプタイプ６が追加ストライプタイプである。

　追加前において、ノード１０１Ｅのストライプアドレスはいずれのストライプタイプにも属しておらず、矩形内は空である。既存ノードの一部であるノード１０１Ａ、１０１Ｃ、１０１Ｄの一部のストライプアドレスの属するストライプタイプが、ストライプタイプ６に変更されている。追加されたノード１０１Ｅのストライプアドレスの一部は、既存ノードにおいて変更されたストライプタイプ２、３、４に割り当てられている。

　このように、一つのストライプタイプのストライプを異なるノードに分散することで、ノード障害に対する耐性を高める。追加されるノードと既存ノード間で、サイト冗長コードＱの使用量ができるだけ均一となるように、冗長コードノードが最決定される。

　上記例ではノード増設を説明したが、ドライブ増設やサイト増設においても、同様に構成変更処理を実行することができる。

　次に、各ノード１０１は、ローカル領域量テーブル８０２における目標量の再計算を実行する（Ｓ２５２）。例えば、図９のローカル領域量テーブル８０２に示すように、目標量の再計算は、各サイトストライプタイプ、各保護レイヤの冗長コード、及びスペア領域の目標容量を決定する。各保護レイヤの冗長コードの目標容量は、例えば、ユーザ指定された（図２７で説明）データ保護の方針（ＸＤＹＰ：最大Ｄａｔａ数Ｘ、冗長コード数Ｙ）に従い、例えば次式から決定される。

　　目標容量
　　＝全体容量×Ｍａｘ（Ｙ÷リソース数、Ｙ÷（Ｘ＋Ｙ））
　　　（但し、リソース数＞Ｙ）

　全体容量は、ノード１０１のローカル領域の全体容量あり、Ｍａｘ（Ａ、Ｂ）はＡ及びＢの内の最大値であり、リソース数は保護レイヤにおけるリソースの数である。ノード保護レイヤにおいてリソース数はノード内のドライブ数であり、サイト保護レイヤにおいてリソース数はサイト内ノード数である。

　例えば、スペア領域の目標量は固定値であり、各サイトストライプタイプの目標量は、全容量の残量の等分である。

　次に、冗長コードのリバランスを実行する（Ｓ２５３）。これは、変更前と変更後の保護レイヤの静的マッピングテーブルの差分に対して、冗長コードの付け替え処理を実行する。具体的には、差分データ（中間コード）を冗長コードノードに送信し、冗長コードノードは中間データにより旧冗長コードを更新する。なお、冗長コードのリバランスを実施する代わりに、以前の保護レイヤの静的マッピングテーブルを記録しておき、冗長コードの対応関係を保持してもよい。

　最後に、プロセッサ１１９は、ページのリバランス、再配置を実行する（Ｓ２５４）。本処理は、新規に追加したノードやドライブに対してページの再配置を実行する。具体的な方法は、図２３を参照して説明した通りである。なお、冗長コード及びスペア領域の設定した目標が達成できない場合に、目標量をフィードバック制御等の知られた手法により徐々に削減してもよい。本構成により、システム全体の性能を考慮しつつ、システムを構成する各ノードに配置すべきデータを制御することが可能となる。

　図２６は、コマンドラインの管理Ｉ／Ｆの一例を示す。同一ノード１０１上で、アプリケーションプログラム２６０１、ＡＰＩ２６０３、及びソフトウェアで実現されるストレージ装置２６０２が動作している。

　アプリケーションプログラム２６０１は、ＡＰＩ２６０３を通じて、ストレージ装置２６０２に対して、自系論理ページに割り当てる仮想ボリューム内の仮想ページを指定する。アプリケーションプログラム２６０１は、例えば、仮想ボリューム番号、ＬＢＡ、データ長により仮想ページを指定する。これにより、ページ単位で指定可能である。

　ストレージ装置２６０２は、指定された仮想ページに割り当てられている論理ページのノードを、ページマッピングテーブル２１５を参照して決定する。指定仮想ページに他ノードのプールボリュームの論理ページが割り当てられ、他ノードのドライブに該当データが格納されている場合、ストレージ装置２６０２は、当該他ノードから該当データを読み出し、自系のプールボリュームの論理ページに指定仮想ページを割り当て、自系のドライブにデータを格納する。また、上述のＡＰＩ２６０３によって指定されたストレージ領域にページが割り当てられていない場合、ライト要求に応じてページの新規割り当てを実施する際に、自系のドライブにデータを格納するようにする。

　本構成により、次に自系でアプリケーションプログラム２６０１が使用する論理ページを自系に事前に配置しておくことができ、アプリケーションに最適なページ配置が実現できる。

　ノード１０１は、ユーザインタフェースを介して、ユーザから、自系論理ページ（自系のストレージデバイス）に割り当てる仮想ボリューム内の仮想ページの指定を受け付けてもよい。上述のように、仮想ページは、仮想ボリュームの識別子及び当該仮想ボリューム内の論理アドレスで示される。さらに、ノード１０１は、仮想ページの他ノードの論理ページへの割り当て指示を受け付けてもよい。

　図２７は、分散型ストレージシステムのＧＵＩの管理Ｉ／Ｆの例を示す。ＧＵＩ２７０１は、本分散型ストレージシステムの各種設定をユーザが実施するためのＩ／Ｆである。ノード１０１は、入出力デバイスを介して、ユーザからの各種設定を受け付ける。

　ＧＵＩ２７０１は、保護レイヤ毎のリソース指定（２７０２Ａ～Ｃ）受け付け、階層的設定を可能としている。例えば、サイト２７０２Ａが指定された場合、ＧＵＩ２７０１は、指定されたサイトの各ノード（２７０２Ｂ）の選択を受け付ける。ノードが指定された場合、ＧＵＩ２７０１は、指定されたノード内のボリューム（２７０２Ｃ）についての設定を受け付ける。

　サイト間、ノード間、ボリュームで共通に設定される項目について説明する。ネットワーク性能は、ネットワーク帯域の情報である。ＡＵＴＯが指定された場合は、各ノード１０１は、ネットワーク帯域を計測した結果から、自動的にネットワーク帯域を決定する。ユーザが指定した場合、各ノードは、ページ配置の決定において、指定されたネットワーク帯域を使用する。

　故障閾値は、リソースへの通信エラー等が発生した場合に、当該リソースを閉塞と判定するエラー回数を示す。テイクオーバは、リソースで障害が発生した場合のテイクオーバ先のリソースを指定する。複数のテイクオーバ先が選択され得る。ユーザがテイクオーバ先を指定しない場合、ストレージシステムが自動的に選んでもよい。

　保護レイヤ毎に指定できる設定として、プロテクションポリシがある。保護レイヤ毎のデータ保護の方針（ＸＤＹＰ：最大Ｄａｔａ数Ｘ、冗長コード数Ｙ）指定できる。ノード数がＸ＋Ｙに満たない場合、リソースのストレージ容量が異なる場合などは、ストレージシステムは、実構成内においてこれらに近い値を使用する。

　仮想ボリューム毎に指定できる設定として、同期・非同期情報がある。仮想ボリューム毎に、保護レイヤ毎に同期でコピーするか、非同期でコピーするかを指定できる。各保護レイヤのコピー無効化が指定可能である。

　例えば、ジオ保護レイヤのコピーを無効とする、という設定がなされる。その場合は、サイト障害時に仮想ボリュームのリビルドが不可となり、サイト障害時のリビルドはスキップされる。以上のように、重要なデータはサイト間で非同期コピーを行い、さらに重要なデータは同期コピーを行う、という運用が可能である。

　キャッシュモードは、“書き込む”及び“ライトバック”が選択できる。書き込むモードは、ライトデータをキャッシュに格納すると同時に、ドライブへの反映を実施したうえで、ホスト（アプリケーションプログラム）にライト完了を通知する。ライトバックモードは、ライトデータをキャッシュに格納すると、ホスト（アプリケーションプログラム）にライト完了を通知する。

　使用ノードの指定により、仮想ボリュームをマウントするノードが設定される。本設定は、仮想ボリューム管理テーブル２１８に反映される。

　図２８は、分散型ストレージシステムのハードウェア構成例を示す。図１が示す構成例の差は、複数ノード１０１間でバックエンドスイッチ２８０１が共有されている点である。バックエンドスイッチ２８０１を介して共有されているドライブ１１３は、バックエンドスイッチ２８０１を共有している各ノード１０１が他ノードを介することなくアクセス可能であり、各ノード１０１が管理するローカルドライブである。このように、一つのドライブ１１３は、バックエンドスイッチ２８０１を介して複数ノード１０１に含まれ得る。

　共有バックエンド構成の場合、共有範囲をドメインと定義し、ドメイン内とドメイン間でデータ保護を多次元化してもよい。また、転送の帯域幅に応じて、帯域幅の比較的に広い区間でドメインを定義してもよい。

＜実施形態２＞
　図２９は、冗長化のためのノード間の転送を効率化する方法を示す。上述した方法では、ノードに対するライト量に対して、冗長度に比例して転送量が増加する。例えば、図１の例において、２ノード障害時にデータを回復するためには、１個のノードから、２個のノードのキャッシュメモリ１８１に対してライトデータが転送される。

　例えば、ノード１０１Ａに書き込まれたライトデータＤＡＴＡ１（１５０１Ａ）は、ノード１０１Ｂとノード１０１Ｄのキャッシュメモリ１８１に転送される。つまり、この例においては、ノードに対するライト量の２倍のネットワーク転送が発生する。以下において、他のノードでの冗長コード生成のための転送量を削減する方法を述べる。

　図２９は、ノード１０１Ａから１０１Ｄまでの４ノードにおいて、２Ｄ２Ｐ冗長構成でデータを保護する例を示している。つまり、本システムは、２ノード障害時に全てのデータを回復できる冗長性を持つ。

　例えば、ノード１０１Ａは、受信したデータ長の長いライトデータを二つのブロック（ｄ１、ｄ２ブロック）２９０１、２９０２に分割し、さらに、ノード内冗長コードとして、二つのパリティ（ｐ、ｑパリティ）２９０３、２９０４を生成する。パリティもデータブロックである。また、データブロックはデータユニットを含む上位語である。ｐパリティ２９０１及びｑパリティ２９０２は、一次的な冗長コード（Ｃｌａｓｓ１　Ｃｏｄｅ）である。次に、ノード１０１Ａは、ライトデータ及びパリティを、ノード１０１Ｂ～１０１Ｄのキャッシュ（バッファ）に分散コピーする。一つ又は複数のデータブロックの組み合わせは、データブロックである。

　本例は、一つのライトデータブロック（ｄ２ブロック）２９０２及び二つのパリティ（ｐ、ｑパリティ）２９０３、２９０４を、３ノード１０１Ｂ～１０１Ｄに、分散コピーする。コピーが完了した時点で、必要な冗長性が得られている（２ノード障害時のデータ回復が可能）ため、同期的なライト処理が完了する。

　同様に、ノード１０１Ｂ～１０１Ｄは、それぞれ、受信したライトデータを二つのブロック（ｄ１、ｄ２ブロック）に分割し、さらに、ｐ、ｑパリティを生成する。ノード１０１Ｂ～１０１Ｄは、それぞれ、一つのライトデータブロック（ｄ２データブロック）及び二つのパリティ（ｐ、ｑパリティ）を、他の三つのノードのキャッシュ（バッファ）に、分散コピーする。各ノードは、他の三つのノードそれぞれからのデータブロック（ライトデータ又はパリティ）をキャッシュに格納する。

　ノード１０１Ａ～１０１Ｄは、それぞれ、非同期的に、他の三つのノードから集約したデータブロック（それぞれライトデータ又はパリティ）から、二次的な冗長コード（ｘ１、ｙ１パリティ）を生成し、ローカルドライブに書き込み、キャッシュを解放する。当該冗長コード（ｘ１、ｙ１パリティ）を、Ｃｌａｓｓ２　Ｃｏｄｅと呼ぶ。Ｃｌａｓｓ２　Ｃｏｄｅは、図１で説明した冗長符号に対応する。

　例えば、ノード１０１Ｃは、ノード１０１Ａからｐパリティ２９０３、ノード１０１Ｂからｐパリティ２９０５、及びノード１０１Ｄからｑパリティ２９０６を受信する。ノード１０１Ｃは、それらから、ｘ１パリティ２９０８及びｙ１パリティ２９０９を生成してローカルドライブに書き込み、キャッシュを解放する。

　また、ノード１０１Ａ～１０１Ｄは、それぞれ、ライトデータ（ｄ１+ｄ２）をローカルドライブに書き込み、キャッシュを解放する。例えば、ノード１０１Ａは、ｄ１ブロック２９０１及びｄ２ブロック２９０２をローカルドライブに書き込み、キャッシュを解放する。

　図１の例は、２ノード障害時にデータ回復を可能とするためには、ライトデータ（ｄ１+ｄ２）を他の２ノードに転送する。これに対して、本例は、ライトデータの一部（ｄ２）と、ライトデータから生成した一次的冗長コード（ｐ、ｑパリティ）を他ノードに転送する。したがって、要求される冗長性を維持しつつ、ノード間のデータ転送を効率化することができる。また、ストライプのデータ（ｄ１+ｄ２）が全てローカルドライブに格納される。

　図２９は、２Ｄ２Ｐ冗長構成の例を示すが、本例の方法は、任意のｍＤｎＰ構成（ｍ、ｎは自然数）に適用できる。ライトデータ（ｍＤ）は、ローカルドライブに格納され、冗長度を１減らした状態（冗長度がｎ－１）のデータが他ノードに転送される。

　例えば、３Ｄ２Ｐ構成（ｄ１、ｄ２、ｄ３、ｐ、ｑ）において、ライトデータ（ｄ１＋ｄ２＋ｄ３）はローカルドライブに格納され、データブロックｄ２、ｄ３、ｐ、ｑが異なるノードにそれぞれ転送される。転送されるデータブロックの組はこれに限定されず、例えば、データブロックｄ１、ｄ２、ｄ３、ｐが他ノードに転送されてもよい。

　本例の方法と、実施形態１で述べた、一つのストライプタイプ内のストライプから動的にストライプを選択し、選択したストライプから冗長コードを生成し、それらについての情報をメタデータ（例えばログ構造化マッピングテーブル２１３）として格納する方法とを組み合わせることにより、リードモディファイライト及びネットワークの転送量を低減でき、ライト処理の高性能を実現できる。また、本例の方法は、本例前で述べた複数の保護レイヤを有するシステムに適用できる。

　また、受信したライトデータのデータ長が短い場合（例えばランダムライト）は、冗長化のためのデータ転送は、ネットワークの帯域への影響が小さい。そのため、データ長が閾値より大きい場合（シーケンシャルライト）のみ、本例の冗長化処理を実行してもよい。データ長が閾値以下の場合、例えば、図１に示す方法が適用される。

　これにより、プロセッサ処理とネットワーク帯域の利用率を向上できる。この場合、システムは、メタデータ（例えばログ構造化マッピングテーブル２１３）に、Ｃｌａｓｓ２　Ｃｏｄｅの生成方法を適用しているか否かを示す情報を付加し、当該情報に従ってデータの処理を切り替えてもよい。また、Ｃｌａｓｓ１　ｃｏｄｅを、ノード内パリティとしてローカルドライブに書き込み、パリティ生成の処理を効率化してもよい。

　図３０は、図２９を参照して説明した冗長化のためのノード間の転送を効率化する方法における、データ復元方法を示す。図３０は、ノード１０１Ａ及び１０１Ｂが故障し、ライトデータを復元する例を示す。

　ノード１０１Ｃ及び１０１Ｄは、それぞれＣｌａｓｓ２　ｃｏｄｅから、Ｃｌａｓｓ１　ｃｏｄｅを復元し、さらに、Ｃｌａｓｓ１　ｃｏｄｅからノード１０１Ａ及び１０１Ｂのユーザデータを復元する。

　具体的には、ノード１０１Ｃは、ノード１０１Ｄから取得したノード１０１Ｄのｑパリティと、ローカルのｘ１、ｙ１パリティとから、ノード１０１Ａ及び１０１Ｂのｐパリティを復元する。ノード１０１Ｄは、ノード１０１Ｄのユーザデータ（ローカルユーザデータ）からノード１０１Ｄのｑパリティ（ローカルにパリティを保存していれば、それで代用してもよい）を生成する。

　ノード１０１Ｄは、ノード１０１Ｃから取得したノード１０１Ｃのｑパリティと、ローカルのｘ１、ｙ１パリティとから、ノード１０１Ａ及び１０１Ｂのｑパリティを復元する。ノード１０１Ｃは、ノード１０１Ｃのライトデータからノード１０１Ｃのｑパリティを生成する。

　さらに、ノード１０１Ｃは、ノード１０１Ｄから取得したノード１０１Ａのｑパリティと、復元したノード１０１Ａのｐパリティと、から、ノード１０１Ａのユーザデータｄ１、ｄ２を復元する。ノード１０１Ｄは、ノード１０１Ｃから取得したノード１０１Ｂのｐパリティと、復元したノード１０１Ｂのｑパリティと、から、ノード１０１Ｂのユーザデータｄ１、ｄ２を復元する。以上のように、２段階の復元処理により、ライトデータを回復することができる。

＜実施形態３＞
（ログ構造（ドライブ）＋パリティ生成（ドライブ）オフロード方式）
　図３１は、分散型ストレージシステムのハードウェア構成例を示す。図３が示す構成例との主な差は、ネットワーク１０４により接続された計算機ノード１０１のバックエンドポートが、仮想的又は物理的なネットワーク１０３を介して複数のフラッシュドライブ３１０５に接続されている点である。一つのサイトには、１又は複数の計算機ノード１０１が設置されている。

　計算機ノード１０１は、他の計算器ノードを介することなく、ネットワーク１０３を介してフラッシュドライブ３１０５それぞれと通信可能であり、ローカルドライブとして使用できる。一つのフラッシュドライブ３１０５は、一つの計算機ノード１０１とのみ通信する。

　バックエンドネットワーク１０３は、複数の計算機ノード１０１を相互接続してもよく、バックエンドネットワーク１０３が接続された計算機ノード１０１間は、バックエンドネットワーク１０３を使用して通信する。バックエンドネットワーク１０３で接続されていないノード間の通信は、例えば、外部ネットワーク１０４を使用する。

　ストレージドライブの一例であるフラッシュドライブ３１０５は、計算機ノード１０１と接続するためのＩ／Ｆ３１０１、データを一時的に格納するバッファメモリ３１０２、フラッシュドライブ３１０５を制御する内部プロセッサ３１０３、及びデータを格納する複数のフラッシュメモリ３１０４を含んで構成される。

（概要）
　図３２は、本例の概要を示す。本例は、パリティ生成処理、及びログ構造化形式でのデータ格納処理をフラッシュドライブで実施する。これにより、計算機ノードは、冗長コードの生成及びログ構造化形式を意識することなく、ライト処理を実施できるため、ライト処理の時間を短縮できる。

　計算機ノード１０１は、例えば、実施形態１において説明した静的マッピングテーブル（例えばサイト静的マッピングテーブル２１１）を使用して、ライトデータと冗長コードそれぞれを格納するドライブを決定する。実施形態１の計算機ノードに代えて、ドライブが決定される。例えば、図３２に示す２台のＤドライブ３２１９、Ｐ１ドライブ３２２０及びＰ２ドライブ３２２１が、一つのストライプタイプのデータドライブ及び冗長コードドライブに対応する。

　例えば、計算機ノード１０１は、ホストからのライトデータのアクセス先（例えば、ボリューム識別子及びボリューム内アドレス）に基づき静的マッピングテーブルのエントリを選択し、当該エントリが示す複数ドライブを、ライトデータ及び冗長コードを格納するドライブと決定する。サイト間保護レイヤが存在する場合、計算機ノード１０１は、他サイトの計算器ノード１０１にライトデータを転送する。ホストプログラムは、例えば、計算機ノード１０１内で実行されている。

　例えば、計算機ノード１０１は、ライトデータのドライブへのライト時、ライトデータを格納する一つのドライブ（Ｄドライブ）３２１９と、メインパリティを格納する一つのドライブ（Ｐ１ドライブ）３２２０へデータをライト（二重書き）する。このとき、計算機ノード１０１は、Ｄドライブ３２１９に対して、通常のライトコマンド（Ｄ＿ＷＲＩＴＥ）による書き込みを行い（３２１０）、Ｄドライブ３２１９のデータバッファ３２０２を介して、データを媒体（ＬＢＡ領域）３２０４へ書き込む。

　計算機ノード１０１は、Ｐ１ドライブ３２２０に対してパリティライトコマンド（Ｐ＿ＷＲＩＴＥ）を発行し、Ｄドライブ３２１９に格納したデータの格納先情報とセットでデータを書き込む（３２１１）。パリティ生成バッファ３２０３へデータを書き込んだ後、Ｐ１ドライブ３２２０は、ドライブ内部でＰ１パリティ３２０７を生成し、媒体３２０４へＰ１パリティ３２０７を書き込む。

　Ｐ１ドライブ３２２０は、実施形態１のストライプタイプの冗長コード生成について説明したように、パリティ生成バッファ３２０３に書き込まれたデータブロックを動的に組合せ、Ｐ１パリティ３２２７を生成する。Ｐ１ドライブ３２２０は、Ｐ１パリティ３２０７を生成したデータの格納先の情報をメタデータ３２０９として、メタデータ格納域３２０５へ書き込む。

　例えば、パリティ数が２である場合、計算機ノード１０１は、Ｄドライブ３２１９とＰ１ドライブ３２２０に加え、２つ目以降のパリティであるサブパリティ（Ｐ２パリティ）を格納するドライブ（Ｐ２ドライブ）３２２１へ、データをライト（三重書き）する。Ｐ２ドライブ３２２１は、Ｐ１ドライブ３２２０と同様に、データをパリティ生成バッファ３２０３へ格納し、パリティ生成バッファ３２０３に書き込まれたデータブロックを動的に組合せ、Ｐ２パリティ３２２７を生成する。

　Ｐ２パリティを生成する際、Ｐ１ドライブ３２２０とＰ２ドライブ３２２１で生成するパリティのデータブロック組合せは同一である必要がある。Ｐ１ドライブ３２２０がＰ１パリティを生成後、Ｐ１ドライブ３２２０は、Ｐ１パリティを生成したデータブロックの組合せを、計算機ノード１０１を介して（Ｐ＿ＧＥＴ、Ｐ＿ＰＵＳＨ）、Ｐ２ドライブ３２２１へ通知する（３２１５）。その後、Ｐ２ドライブ３２２１は、通知されたデータブロックの組合せでＰ２パリティを生成する。

　計算機ノード１０１は、最新データのリード時、通常のリードコマンド（Ｄ＿ＲＥＡＤ）でＤドライブ３２１９から最新データ３２０６を読み込む（３２１２）。また、計算機ノード１０１は、旧データ３２０８を読み込むリードコマンド（ＯＬＤ＿Ｄ＿ＲＥＡＤ）により、Ｄドライブ３２１９から旧データ３２０８を読み込む（３２１３）。

　計算機ノード１０１は、ログ構造化形式で書き込むための領域を確保するため、ドライブ３２１９～３２２１の使用量（空き容量）を監視し、必要に応じてガベージコレクション処理を実施する。計算機ノード１０１の容量管理ジョブ３２０１は、ライト完了後又は定期的にドライブ使用量（空き容量）を取得するコマンド（ＳＴＡＴ＿ＧＥＴ）を発行し、ドライブ使用量（ドライブ空き容量）を監視し、検出する（３２１４）。使用量が閾値より大きく（空き容量が閾値より小さく）、ドライブ空き容量の枯渇を検知した場合、計算機ノード１０１は、ガベージコレクション処理を実施する。

　ガベージコレクション処理は、Ｐ２ドライブ３２２１へ削除対象パリティを探索するコマンド（ＳＥＡＲＣＨ）を発行し（３２１８）、ドライブ３２２１から削除対象パリティの格納先情報と削除対象パリティを構成するデータの情報を取得する。次に、パリティ構成データ情報からパリティを構成するデータが最新データか否かを判定し、最新データを、Ｐ１ドライブ３２２０へ転送し、再ダーティ化する。パリティ構成データ情報は、パリティの生成で使用されたデータブロックそれぞれの情報を示す。パリティを構成する全ての最新データを再ダーティ化した後、パリティを削除、旧データを無効化するコマンド（ＩＮＶＡＬＩＤ）を発行し（３２１７）、旧データを削除する。

（ドライブ内のデータ管理構造）
　図３３は、ストレージシステムの制御のためにドライブ３１０５で管理するテーブル構造を示す。フラッシュメモリ３１０４は、ログ構造に関する情報である論物変換表３３０１、ログ変換表３３０２、データ保護に関する情報であるパリティーデータ変換表３３０７、データーパリティ変換表３３０８、及びアドレス識別子フリーキュー３３０９を格納する。

　論物変換表３３０１は、ドライブ３１０５が計算機ノード１０１に提供する論理アドレス３３０２と、物理記憶領域に格納されたデータの物理アドレス３３０３との、対応関係を示す。

　ログ変換表３３０４は、データを一意に識別するためのアドレス識別子３３０５と、論物変換情報を格納しているログ情報３３０６との、対応関係を示す。ドライブ３１０５は、データが書き込まれる度に、更新した論物変換情報をログ情報として、アドレス識別子を付与し、管理する。他ドライブが保持するパリティを構成するデータの情報は、アドレス識別子で保持する。

　これにより、ドライブ３１０５が行うガベージコレクション処理やウェアレベリング処理により、自ドライブに格納するデータの物理アドレスが変更されても、他ドライブへ変更後の物理アドレスを通知しなくてよいため、ドライブ間の通信オーバヘッドを削減できる。

　パリティ－データ変換表３３０７は、自ドライブのパリティを格納している物理記憶領域のアドレス（ＬＢＡ、データ長）と、パリティを生成した他ドライブのデータの物理記憶領域のアドレス（ドライブ番号、ＬＢＡ、データ長、アドレス識別子）との、対応関係を示す。

　パリティは、複数のデータを元にした演算で生成するため、一個のパリティに対して、複数の他ドライブ上のデータ格納先の論理アドレスが対応する。また、ログストラクチャ形式でデータを格納するため、論理アドレスのデータは、旧データのアドレスも含みうる。このため、パリティを生成したデータの格納先を一意に判別できるように、アドレス識別子が同時に格納される。

　データ－パリティ変換表３３０８は、上述したパリティーデータ変換表の逆変換表である。他ドライブのデータを格納している物理記憶領域のアドレス（ＬＢＡ、ドライブ番号）と、自ドライブのパリティを格納している物理記憶領域のアドレスとの、対応関係を示す。

　他ドライブに障害が発生し、データを復旧する必要がある場合、ドライブ３１０５は、データ－パリティ変換表３３０８により、他ドライブ上のデータの復旧に必要なパリティを格納している物理記憶領域のアドレスを特定する。また、パリティ－データ変換表３３０７により、データの復旧に必要な他ドライブのデータを格納している物理記憶領域のアドレスを特定することができる。

　アドレス識別子フリーキュー３３０９は、後述するライト処理を並列に実行する際に使用されるキューであり、未使用のアドレス識別子を格納している。計算機ノード１０１は、データを書き込むとき、アドレス識別子フリーキュー３３０９の先頭からアドレス識別子を取得（デキュー）し、アドレス識別子とともにドライブ３１０５へデータのライト処理を発行する。

　ドライブ３１０５は、ログ変換表３３０４へログ情報を指定されたアドレス識別子で格納する。また、計算機ノード１０１は、旧データがｉｎｖａｌｉｄａｔｅされる契機で、ｉｎｖａｌｉｄａｔｅされたアドレス識別子を、アドレス識別子フリーキュー３３０９の末尾へ登録（エンキュー）する。

（Ｉ／Ｆ一覧）
　図３４は、計算機ノード１０１とフラッシュドライブ３１０５との間の通信インタフェースを示している。Ｄ＿ＷＲＩＴＥコマンド３４０１は、Ｄドライブ３２１９のドライブ番号、ＬＢＡ、データ転送長を引数とし、Ｄドライブ３２１９へ書き込みを行う。その後、ログ構造のメタデータであるアドレス識別子を出力する。

　アドレス識別子は、ドライブに格納されたデータに対応付けられた不変な識別子である。具体的には、アドレス識別子は、ドライブ内の論理アドレスと物理アドレスとのマッピング情報に付与する、ドライブ内で一意な識別子である。

　Ｐ＿ＷＲＩＴＥコマンド３４０２は、パリティを格納するＰ１ドライブ３２２０又はＰ２ドライブ３２２１のドライブ番号、データ転送長、データ格納情報を引数とし、ドライブへ書き込みを行う。データ格納情報は、Ｄドライブのドライブ番号、ＬＢＡ、アドレス識別子からなる。

　Ｄ＿ＲＥＡＤコマンド３４０３は、ドライブ番号、ＬＢＡ、データ転送長を引数とし、Ｄドライブ３２１９から最新データを読み出す。ＯＬＤ＿Ｄ＿ＲＥＡＤコマンド３４０４は、ドライブ番号、アドレス識別子、データ転送長を引数とし、Ｄドライブ３２１９から旧データを読み出すコマンドである。

　Ｐ＿ＧＥＴコマンド３４０５は、Ｄドライブのドライブ番号を引数とし、引数で指定したＰ１ドライブ３２２０から非同期デステージ処理で生成されたパリティで、Ｐ２ドライブ３２２１への未通知のパリティ構成データ情報を出力する。パリティ構成データ情報は、パリティの生成で使用されたデータブロックそれぞれのＤドライブのドライブ番号、ＬＢＡ、アドレス識別子からなる。

　Ｐ＿ＰＵＳＨコマンド３４０６は、Ｐ１ドライブ３２２０のドライブ番号と、パリティ構成データ情報を引数とし、Ｐ２ドライブ３２２１へパリティ構成データ情報を通知する。パリティ構成データ情報は、Ｄドライブのドライブ番号、ＬＢＡ、アドレス識別子からなる。

　ＳＴＡＴ＿ＧＥＴコマンド３４０７は、ドライブ番号を引数として、引数で指定されたドライブの使用量の情報を出力する。ＳＴＡＴ＿ＧＥＴコマンド３４０７は、ドライブの容量枯渇監視に使用される。ＩＮＶＡＬＩＤコマンド３４０８は、ガベージコレクション処理時、Ｄドライブ３２１９のドライブ番号、アドレス識別子を引数とし、不要となった旧データを無効化する。

　ＳＥＡＲＣＨコマンド３４０９は、ガベージコレクション処理時、Ｐ１ドライブ３２２０へ削除対象パリティの探索を依頼し、探索結果として、削除対象パリティの情報と、削除対象パリティのパリティ構成データ情報を出力する。削除対象パリティ情報は、Ｐ１ドライブ３２２０のドライブ番号とＬＢＡからなり、削除対象パリティ構成データ情報は、Ｄドライブのドライブ番号、ＬＢＡ、アドレス識別子、及び最新データか否かの情報からなる。

　以上のコマンドにより、計算機ノード１０１とドライブ３１０５間で通信を行い、処理を実現する。

（リード処理）
　（最新データのリード）
　図３５は、計算機ノード１０１がＤドライブ３２１９から最新データを読み込む処理のフローチャートを示す。本処理は、ホストからリード命令を受領した場合に実行される（Ｓ３５０１）。

　まず、ホストからリード命令を受領した計算機ノード１０１のプロセッサ１１９は、キャッシュ上にデータが存在するかどうか確認する（Ｓ３５０２）。キャッシュ上にデータが存在する場合（Ｓ３５０２：Ｙ）、プロセッサ１１９は、ホストへキャッシュ上のデータを返却する（Ｓ３５１０）。

　キャッシュ上にデータが存在しない場合（Ｓ３５０２：Ｎ）、プロセッサ１１９は、キャッシュを確保（Ｓ３５０３）した後、Ｄドライブ３２１９へＤ＿ＲＥＡＤコマンドを発行する（Ｓ３５０４）。

　Ｄドライブ３２１９は、Ｄ＿ＲＥＡＤコマンドを受領すると（Ｓ３５０５）、論物変換表３３０１を参照してデータを格納している物理アドレスを取得する（Ｓ３５０６）。次に、Ｄドライブ３２１９は、フラッシュメモリ（媒体）３１０４からデータをリードし（Ｓ３５０７）、計算機ノード１０１へ結果を返却する（Ｓ３５０８）。計算機ノード１０１は、Ｄドライブ３２１９からＤ＿ＲＥＡＤの結果を受け取ると（Ｓ３５０９）、結果をホストへ返却する（Ｓ３５１０）。

　（旧データのリード）
　図３６は、旧データのリード処理を示している。旧データのリード処理では、まず計算機ノード１０１は、ＯＬＤ_Ｄ_ＲＥＡＤコマンドをＤドライブ３２１９へ発行する（Ｓ３６０１）。Ｄドライブ３２１９は、ＯＬＤ＿Ｄ＿ＲＥＡＤコマンドを受領すると（Ｓ３６０２）、指定されたアドレス識別子に対応する旧データを格納している物理アドレスを、ログ変換表３３０４から取得する（Ｓ３６０３）。

　次に、Ｄドライブ３２１９は、フラッシュメモリ（媒体）３１０４から旧データをリードし（Ｓ３６０４）、計算機ノード１０１へ結果を返却する（Ｓ３６０５）。計算機ノード１０１は、Ｄドライブ３２１９からＯＬＤ_Ｄ_ＲＥＡＤの結果を受け取る（Ｓ３６０６）。

（ライト処理）
　図３７は、計算機ノード１０１がＤドライブ３２１９へデータを書き込む処理のフローチャートを示す。ライト処理は、二つの処理を含む。一の処理は、ホストへライト結果を返却するまでの同期ライト処理である。もう一つの処理は、ドライブ内のパリティ生成バッファに蓄積されたデータからパリティを生成し、媒体へ格納する非同期ライト処理である。

　まず、同期ライト処理について説明する。本処理は、ホストからライト命令を受領した場合に実行する。本処理は、Ｄドライブ３２１９へライトデータを格納し、且つパリティを生成するドライブ（Ｐ１ドライブ３２２０とＰ２ドライブ３２２１）へ、アドレス識別子とセットでデータを書き込む。

　計算機ノード１０１のプロセッサ１１９は、ホストからライト命令を受領すると（Ｓ３７０１）、Ｄドライブ３２１９へＤ＿ＷＲＩＴＥコマンドを発行する（Ｓ３７０２）。Ｄ＿ＷＲＩＴＥコマンドは、ライトデータを含む。Ｄドライブ３２１９は、Ｄ＿ＷＲＩＴＥコマンドを受け取ると（Ｓ３７０３）、フラッシュメモリ（媒体）３１０４へ、ライトデータをログ構造形式でライトし（Ｓ３７０４）、さらに、Ｄドライブ３２１９は、メタデータ（論物変換表３３０１とログ変換表３３０４）を更新する（Ｓ３７０５）。Ｄドライブ３２１９は、データ格納先のアドレス識別子を計算機ノード１０１へ返却する（Ｓ３７０６）。

　計算機ノード１０１は、Ｄドライブ３２１９からＤ＿ＷＲＩＴＥの結果を受け取ると（Ｓ３７０７）、Ｄドライブ３２１９へのデータ格納情報とセットで、Ｐ１ドライブ３２２０へＰ＿ＷＲＩＴＥコマンドを発行する（Ｓ３７０８）。

　Ｐ１ドライブ３２２０は、Ｐ＿ＷＲＩＴＥコマンドを受け取ると（Ｓ３７０９）、ドライブのパリティ生成バッファ３２０３へライトデータを格納し（Ｓ３７１０）、計算機ノード１０１へ結果を返却する（Ｓ３７１１）。

　計算機ノード１０１は、Ｐ１ドライブ３２２０からＰ＿ＷＲＩＴＥコマンドの結果を受け取ると（Ｓ３７１２）、Ｄドライブ３２１９へのデータ格納情報とセットで、Ｐ２ドライブ３２２１へＰ＿ＷＲＩＴＥコマンドを発行する（Ｓ３７１３）。

　Ｐ２ドライブ３２２１は、Ｐ＿ＷＲＩＴＥコマンドを受け取ると（Ｓ３７１４）、パリティ生成バッファ３２０３へライトデータをライトし（Ｓ３７１５）、計算機ノード１０１へ結果を返却する（Ｓ３７１６）。計算機ノード１０１は、Ｐ２ドライブ３２２１からＰ＿ＷＲＩＴＥコマンドの結果を受け取ると（Ｓ３７１７）、ホストへ結果を返却する（Ｓ３７１８）。

　上述の同期ライト処理を繰り返し実行した結果、Ｐ１ドライブ３２２０のパリティ生成バッファ３２０３内に所定数のデータが蓄積する、又は、所定時間が経過すると、Ｐ１ドライブ３２２０は、内部で非同期ライト処理を実施する（Ｓ３７１９）。

　まず、Ｐ１ドライブ３２２０は、パリティ生成バッファ３２０３に蓄積されたデータから動的にデータブロックを選択して、Ｐ１パリティを生成する（Ｓ３７２０）。次に、メタデータ（パリティ－データ変換表３３０７及びデーターパリティ変換表３３０８）を更新し（Ｓ３７２１）、Ｐ１パリティをフラッシュメモリ（媒体）３１０４へ書き込む（Ｓ３７２２）。

　次に、計算機ノード１０１は、Ｐ＿ＧＥＴコマンドにより、Ｐ１パリティのパリティ構成データ情報を、Ｐ１ドライブ３２２０から取得する（Ｓ３７２３、Ｓ３７２４）。計算機ノード１０１は、Ｐ１ドライブ３２２０より取得したパリティ構成データ情報を、Ｐ２ドライブ３２２１へＰ＿ＰＵＳＨコマンドにより通知する（Ｓ３７２５）。

　Ｐ２ドライブ３２２１は、計算機ノード１０１からＰ＿ＰＵＳＨコマンドを受信すると、受信したパリティ構成データ情報に基づきＰ２パリティを生成し（Ｓ３７２６）、メタデータ（Ｐ２パリティのパリティ－データ変換表３３０７及びデータ－パリティ変換表３３０８）を更新し（Ｓ３７２７）、Ｐ２パリティをフラッシュメモリ（媒体）３１０４へ書き込む（Ｓ３７２８）。

　図３８は、同期ライト処理において各ドライブへデータのライト処理を並行に実施した場合の処理フローを示している。図３７との差は、計算機ノード１０１がドライブ３２１９～３２２１へ、使用するアドレス識別子を指定することで、Ｄドライブ３２１９の応答を待たずに、パリティを生成するドライブ３２２０、３２２１へライトコマンドを発行している点である。

　また、Ｄドライブ３２１９へのライトは、Ｄ＿ＷＲＩＴＥコマンド３４０１ではなく、アドレス識別子を指定し書き込むためのＤ＿ＷＲＩＴＥ２コマンド３８０５を使用する。Ｄ＿ＷＲＩＴＥ２コマンド３８０５は、Ｄドライブ３２１９のドライブ番号、ＬＢＡ、データ転送長、アドレス識別子を引数とし、Ｄドライブ３２１９へ書き込みを行うためのコマンドである。

　計算機ノード１０１は、ホストからライト命令を受領すると（Ｓ３７０１）、アドレス識別子フリーキュー３３０９の先頭からアドレス識別子を取得し（Ｓ３８０１）、アドレス識別子フリーキュー３３０９の先頭ポインタを更新する（Ｓ３８０２）。次に、計算機ノード１０１は、取得したアドレス識別子を引数とし、Ｄドライブ３２１９へＤ＿ＷＲＩＴＥ２コマンドを発行する（Ｓ３８０３）。

　計算機ノード１０１は、Ｐ１ドライブ３２２０とＰ２ドライブ３２２１へ、取得したアドレス識別子をデータ格納情報に指定し、Ｐ＿ＷＲＩＴＥコマンドを発行する（Ｓ３７０８、Ｓ３７１３）。

　Ｄドライブ３２１９は、指定されたアドレス識別子を使用し、ログ変換表３３０４へログ情報を格納する。Ｐ１ドライブ３２２０、及びＰ２ドライブ３２２１は、図３７と同様に各々処理を実行した後、計算機ノード１０１へ結果を返却する（Ｓ３７０３～Ｓ３７０６、Ｓ３７０９～Ｓ３７１１、Ｓ３７１４～Ｓ３７１６）。

　計算機ノード１０１は、全ドライブ３２１９～３２２１から結果を受信するまで、待機する（Ｓ３８０４）。全ドライブ３２１９～３２２１から結果を受信すると、計算機ノード１０１は、ホストへ結果を返却する（Ｓ３７１８）。

　Ｐ１ドライブ３２２０とＰ２ドライブ３２２１は、図３７のＳ３７１９～Ｓ３７２８で説明した処理と同様に、非同期でパリティを生成し、フラッシュメモリ（媒体）３１０４へ格納する。以上のように、各ドライブで並行してライト処理を行うことで、ホストへの応答時間を短縮できる。

（ガベージコレクション処理）
　図３９は、ガベージコレクション処理のフローチャートを示す。本処理は、ドライブに格納されたデータ量が予め設定された目標容量（閾値）を超えた場合に、不要なデータを消去する。これにより、必要なデータを限られた領域に格納できる。消去されるデータの種類は、ライトデータとパリティである。本処理は、ホストＩ／Ｏと同期して実行されてもよいし、ホストＩ／Ｏと非同期で実行されてもよい。

　計算機ノード１０１は、Ｄドライブ３２１９の使用量が目標量を超過しているかどうかをチェックする（Ｓ３９０１）。具体的には、計算機ノード１０１は、容量管理ジョブ３２０１の監視結果から、使用量がターゲット容量を超えているかどうかにより判定する。なお、容量管理ジョブ３２０１の監視結果は、ローカル領域量テーブル８０２により管理されてもよい。

　ドライブ使用量が目標容量を超えている場合（Ｓ３９０１：Ｙ）、計算機ノード１０１は、ガベージコレクション処理を開始する。ガベージコレクション処理では、計算機ノード１０１は、容量枯渇を検出したＤドライブ３２１９のデータから生成されたＰ１パリティを格納するＰ１ドライブ３２２０に対して、削除対象Ｐ１パリティを探索するＳＥＲＣＨコマンドを発行する。

　Ｐ１ドライブ３２２０は、ＳＥＲＣＨコマンドを受信すると、パリティ－データ変換表３３０７を参照し、引数で指定されたドライブ番号をパリティ構成データ情報として持つＰ１パリティを探索する。対象Ｐ１パリティを見つけると、Ｐ１ドライブ３２２０は、次にデータ－パリティ変換表３３０８を参照し、探索結果のデータが旧データかどうか確認する。

　確認の結果、データが旧データであった場合、Ｐ１ドライブ３２２０は、当該Ｐ１パリティを削除対象パリティと判定する。次に、Ｐ１ドライブ３２２０は、当該Ｐ１パリティを構成する全データの新旧を、データ－パリティ変換表３３０８を参照して確認し、計算機ノード１０１へ、結果（削除対象パリティと削除対象パリティ構成データ情報）を返却する（Ｓ３９０２）。

　次に、計算機ノード１０１は、返却された削除対象パリティ構成データ情報から、Ｐ１パリティを構成する各データの新旧情報を確認し、削除対象Ｐ１パリティが即時削除可能か判定する（Ｓ３９０３）。Ｐ１パリティを構成するデータが全て旧データである場合（Ｓ３９０３：Ｙ）、計算機ノード１０１は、当該Ｐ１パリティを削除し（Ｓ３９０６）、さらに、当該Ｐ１パリティを構成するデータを、ＩＮＶＡＬＩＤコマンドによりデータ格納先のＤドライブ３２１９から削除する（Ｓ３９０７）。

　ライト処理の並列化を行っている場合、計算機ノード１０１は、ＩＮＶＡＬＩＤコマンドの結果を受信すると、アドレス識別子フリーキュー３３０９の末尾にＩＮＶＡＬＩＤしたアドレス識別子を登録（エンキュー）する。また、計算機ノード１０１は、Ｐ２ドライブ３２２１に対しても、同一データの組合せで構成されるＰ２パリティを削除することを指示する。

　次に、Ｐ１パリティを構成するデータに最新データが含まれる場合（Ｓ３９０３：Ｎ）、計算機ノード１０１は、Ｄ＿ＲＥＡＤコマンドによって最新データをＤドライブ３２１９からリードし、Ｐ＿ＷＲＩＴＥコマンドにより、Ｐ１ドライブ３２２０とＰ２ドライブ３２２１へデータ格納情報とセットで書き込む（Ｓ３９０５、Ｓ３９０８）。

　ライト後、計算機ノード１０１は、Ｐ１ドライブ３２２０とＰ２ドライブ３２２１から旧Ｐ１パリティ、旧Ｐ２パリティを削除し（Ｓ３９０６、Ｓ３９０９）、またＩＮＶＡＬＩＤコマンドによりＤドライブ３２１９から旧データを削除する（Ｓ３９０７）。以上の処理を繰り返し、パリティとデータの削除を行う。

　また、Ｐ１ドライブ３２２０は、図３７で説明した非同期ライト処理により、新Ｐ１パリティを生成し、メタデータを更新し、新Ｐ１パリティをフラッシュメモリ（媒体）３１０４へ格納する。Ｐ２ドライブ３２２１も同様に非同期ライト処理により、新Ｐ２パリティを生成し、メタデータを更新し、新Ｐ２パリティをフラッシュメモリ（媒体）３１０４へ格納する。

＜実施形態４＞
（ログ構造（ドライブ）＋パリティ生成（コントローラ）オフロード方式）
　図４０は、分散型ストレージシステムのハードウェア構成例を示す。実施形態３との差は、計算機ノード１０１内部に、パリティ生成処理部を実装している点である。パリティ生成処理部は、ハードウェア又はソフトウェアで実装できる。ストレージシステムは、複数の計算機ノード１０１を含んで構成されており、各計算機ノード１０１は、内部に、パリティを生成する機能を持つ、パリティ生成処理部４００６を含む。

　また、各計算機ノード１０１は、フロントエンドネットワーク４００２により、ホスト計算機４００１へ接続されており、計算機ノード１０１間は、内部ネットワーク４００３で接続され、計算機ノード１０１とドライブ３１０５は、バックエンドネットワーク４００４で接続されている。複数の計算機ノード１０１が、一つのドライブ３１０５にアクセスできる。

（概要）
　図４１は、本例の概要を示す。実施形態３との差は、パリティ生成処理を計算機ノードが実施するため、Ｐ１ドライブ３２２０とＰ２ドライブ３２２１は、Ｉ／Ｏ非同期でパリティを生成する必要がない点である。このため、パリティ数が２以上の場合、Ｐ１パリティのパリティ構成データ情報をＰ２ドライブ３２２１へ通知する必要がなく、計算機ノード１０１とドライブ３２１９～３２２１の処理負荷を削減でき、ライト処理時間を短縮できる。

　具体的には、ライト処理は、ホストから受け取ったデータを計算機ノード１０１内のパリティ生成バッファ４１０１へ格納し、パリティ生成バッファ４１０１からパリティ生成処理部４００６へパリティ生成処理を依頼する（４１０１）。次に、パリティ生成処理部４００６はパリティを生成し、生成したパリティを、パリティを格納するドライブへ書き込む（４１０２）。

　また、ガベージコレクション処理での、実施形態３との差は、削除対象パリティを構成するデータに最新データが含まれる場合、最新データをＤドライブ３２１９から読み出した後、パリティ生成処理部４００６へデータを転送し、新パリティを生成する点である。リード処理は、実施形態３と同様である。

（Ｉ／Ｆ一覧）
　図４２は、計算機ノード１０１とドライブ３２１９～３２２１との間の通信インタフェースを示している。実施形態３におけるＰ＿ＷＲＩＴＥコマンド３４０２の代わりに、Ｐ＿ＷＲＩＴＥ２コマンド４２０１がある。

　Ｐ＿ＷＲＩＴＥ２コマンド４２０１は、ドライブ番号、ＬＢＡ、データ転送長、パリティ構成データ情報の配列を引数とし、パリティをドライブに書き込む。パリティ構成データ情報は、ドライブ番号、ＬＢＡ、アドレス識別子からなる。つまり、Ｐ＿ＷＲＩＴＥ２コマンド４２０１は、複数のデータ格納先を、パリティ構成データ情報として、パリティと共にドライブへ書き込む。

（ライト処理）
　（同期ライト処理）
　本例のライト処理は、実施形態３と同様に、同期ライト処理と非同期ライト処理とを含む。図４３は、本例での同期ライト処理のフローチャートを示している。まず、ホストからライト命令を受領すると（Ｓ４３０１）、計算機ノード１０１は、Ｄドライブ３２１９へＤ＿ＷＲＩＴＥコマンドを発行する（Ｓ４３０２）。

　Ｄドライブ３２１９は、Ｄ＿ＷＲＩＴＥコマンドを受領すると（Ｓ４３０３）、データをフラッシュメモリ（媒体）３１０４にライトし（Ｓ４３０４）、メタデータ（論物変換表３３０１とログ変換表３３０４）を更新し（Ｓ４３０５）、計算機ノード１０１へ結果（アドレス識別子）を返却する（Ｓ４３０６）。

　次に、計算機ノード１０１は、Ｄドライブ３２１９から結果を受領すると（Ｓ４３０７）、データを、計算機ノード１０１内にあるパリティ生成バッファ４１０１へ格納し（Ｓ４３０８）、ホストへ結果を返す（Ｓ４３０９）。

　なお、同期ライト処理は、図３８で説明したようにアドレス識別子フリーキュー３３０９とＤ＿ＷＲＩＴＥ２コマンド３８０５を使用することで、Ｄドライブ３２１９へのデータの書き込みと、パリティ生成バッファへ４１０１のデータの格納を並列に実行してもよい。

　（非同期ライト処理）
　図４４は、本例での非同期ライト処理のフローチャートを示している。同期ライト処理を繰り返し実行した結果、パリティ生成バッファ４１０１内に所定数のデータが蓄積する、又は、所定時間が経過すると、計算機ノード１０１は、非同期ライト処理を実施する（Ｓ４４０１）。

　計算機ノード１０１のメイン処理部４４０５は、パリティ生成バッファ４１０１に蓄積されたデータからパリティ生成対象のデータを、パリティ生成処理部４００６へ転送する（Ｓ４４０２）。メイン処理部４４０５は、例えば、プログラムに従って動作するプロセッサ１１９により実現される。パリティ生成処理部４００６は、データを受信すると（Ｓ４４０３）、受信したデータをその内部バッファへ格納する（Ｓ４４０４）。

　次に、パリティ生成処理部４００６は、受信したデータで、Ｐ１パリティとＰ２パリティを生成し（Ｓ４４０５）、生成したパリティをメイン処理部４４０５へ転送する（Ｓ４４０６）。

　メイン処理部４４０５は、パリティ生成処理部４００６から、Ｐ１パリティとＰ２パリティを受信すると（Ｓ４４０７）、Ｐ＿ＷＲＩＴＥコマンドにより、パリティを構成するデータ情報とともにＰ１ドライブ３２２０とＰ２ドライブ３２２１へ書き込む（Ｓ４４０８）。

　Ｐ１ドライブ３２２０は、Ｐ＿ＷＲＩＴＥコマンドを受信すると（Ｓ４４０９）、フラッシュメモリ（媒体）３１０４へパリティを書き込み（Ｓ４４１０）、メタデータ（パリティ－データ変換表３３０７とデータ－パリティ変換表３３０８）を更新し（Ｓ４４１１）、結果を計算機ノード１０１へ返却する（Ｓ４４１２）。

　一方、Ｐ２ドライブ３２２１も、Ｐ１ドライブ３２２０と同様の処理を行い、計算機ノード１０１へ結果を返却する（Ｓ４４１３～Ｓ４４１６）。メイン処理部４４０５は、Ｐ１ドライブ３２２０とＰ２ドライブ３２２１から結果を受領すると、処理を終了する（Ｓ４４１７）。

（ガベージコレクション処理）
　図４５は、本実施形態のガベージコレクション処理のフローチャートを示している。ステップＳ４２０１～Ｓ４２０４、Ｓ４２０７は、ステップＳ３９０１～Ｓ３９０４、Ｓ３９０７に対応する。

　実施形態３との主な差は、削除対象パリティを構成するデータのうち最新データを、計算機ノード１０１のパリティ生成バッファ４１０１へ格納する点である（Ｓ４５０１）。これにより、実施形態３のようにドライブへデータを再度書き込む必要がなく、ガベージコレクションの処理性能を向上できる。また、ステップＳ４５０１、Ｓ４２０６は、Ｐ１パリティ格納ドライブ及びＰ２パリティ格納ドライブに対して実行される。

　パリティ生成バッファ４１０１内に所定数のデータが蓄積する、又は所定時間が経過すると、計算機ノード１０１は、図４４で説明した非同期ライト処理を実施し、新パリティを生成した後、パリティをドライブへ書き込む。

　以上の例は、冗長コードとデータのアドレッシングの対応関係を各ノードにおいて管理する。他の例において、２種類の仮想的な空間を用意して、その仮想的な空間の対応関係を動的に変えることで、データ保護技術を実施してもよい。具体的には、システムは、上位論理装置に提供する第１の仮想空間と、物理記憶領域上の冗長コードとデータの記憶アドレスと静的に対応づけられた第２の仮想空間と、を準備する。システムは、第１の仮想空間と第２の仮想空間とを動的に対応付けることで、複数ノードからのデータより冗長コードデータ生成を可能とする。

　この場合、システムは、ストライプタイプを構成する複数ノード間で、書き込み先ポインタなどを共有する。書き込み先ポインタは、複数ノード間で第２の仮想空間に対してログ形式でインクリメンタルに追記していく想定で、その書き込みの現在位置を表すポインタである。

　さらに、システムは、当該書き込み先ポインタが一致するように、つまり、複数ノードからの各データとそれらに対応する冗長コードからなる複数のデータが第２の仮想空間上の所定の領域に対応づけられて書きこまれるように、第１の仮想空間と第２の仮想空間との間の対応づけを制御する。

　本開示のデータ保護技術及びデータ配置技術は、キャッシュ上の複数の異なるノードから転送されたデータユニット（データブロック）の組から、冗長コードを動的に生成する。つまり、コードダーティキュー９０１で管理されるデータのうち、同じストライプタイプデータを任意に選択する（図１８のＳ８０２）結果、一つのノードが生成するノード間冗長コード組み合わせを構成するデータブロックの論理アドレスは一つの組み合わせに固定されず、２以上の組み合わせを許容することになる。

　一方で、本開示においては図８に示すように各データブロックとその転送元アドレスとを関連づけて管理することで、動的な論理アドレスの組み合わせでの冗長コード生成を許容する。更に、冗長コード生成のために用いられるデータの数も特定の値に限定されず、動的に変更されうる。以上の構成により、小オーバヘッドのデータ保護を実現しつつ、ネットワークボトルネックを回避し、高速にローカルアクセスが可能なデータ配置を実現する。また、ドライブがＳＳＤの場合は、ライト量を削減でき、長寿命化を実現できる。

　本開示のデータ保護技術及びデータ配置技術により、ローカルリードに適したデータ配置とデータ保護の両立を可能とし、ネットワークによるボトルネックを回避できる。さらに、ローカルストレージデバイスに格納するデータの管理情報は自系内で保持可能であるので、仮想ボリュームとプールボリュームの情報を少数ノードの共有に閉じることができ、共有する情報を低減する。これにより、ノード数に依存しない高いスケーラビリティを実現できる。また、高いスケーラビリティにより、システム構築にかかるネットワークのコストを低減することができる。

　なお、分散型ストレージシステムにおける上記複数機能は、独立に実装することができる。例えば、冗長コードの生成機能、再配置機能、及びページ配置ノードの指定を受け付ける機能のうちの一つのみが分散型ストレージシステムに実装しなくてもよい。ノード構成は、上記計算機構成に限定されない。上記ノード保護レイヤは省略されてもよい。さらに、サイト保護レイヤ又はサイト保護レイヤの一方のみが実装されてもよい。

　なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、図３に示すドライブ１１３は計算機ノード１０１の筐体内に存在する必要はなく、各プロセッサが自系のストレージデバイスであって、管理対象であると認識していれば良い。上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明したすべての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

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

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

　請求範囲に記載されている構成に加え、本開示の特徴の概要を以下に記載する。
（１）
　ストレージシステムは、１以上の計算機と、複数のストレージドライブと、を含み、
　前記１以上の計算機は、ライトデータブロックを格納するデータドライブ及び前記ライトデータブロックの冗長コードを格納する第１冗長コードドライブを決定し、
　前記１以上の計算機は、前記ライトデータブロックを前記データドライブ及び前記第１冗長コードドライブにそれぞれ送信し、
　前記データドライブは、前記ライトデータブロックを記憶媒体に格納し、
　前記第１冗長コードドライブは、前記１以上の計算機から受信した複数のライトデータブロックを使用して冗長コードを生成し、記憶媒体に格納する。
（２）
　前記第１冗長コードドライブは、
　受信したライトデータブロックそれぞれのライト先に基づいて、前記受信したライトデータブロックそれぞれが属するストライプタイプを決定し、
　同一ストライプタイプに含まれる複数のライトデータブロックから冗長コードを生成する。
（３）
　前記第１冗長コードドライブは、
　前記１以上の計算機から、前記ライトデータブロックの格納先情報をさらに受信し、
　前記冗長コードの格納先と前記ライトデータブロックの格納先との関係を管理する。
（４）
　前記１以上の計算機は、前記ライトデータブロックを、前記ライトデータブロックの格納先情報と共に、第２冗長コードドライブにさらに送信し、
　前記第２冗長コードドライブは、前記第１冗長コードドライブにおいて冗長コードの生成で使用されたデータブロックの情報を示す構成情報を取得し、前記構成情報に従って選択したデータブロックを使用して冗長コードを生成する。
（５）
　ストレージシステムは、計算機と、複数のストレージドライブと、を含み、
　前記計算機は、ライトデータブロックを格納するデータドライブ及び前記ライトデータブロックの冗長コードを格納する冗長コードドライブを決定し、
　前記計算機は、前記ライトデータブロックを前記データドライブに送信し、
　前記データドライブは、前記ライトデータブロックを記憶媒体に格納し、
　前記計算機は、前記ライトデータを使用して冗長コードを生成し、
　前記計算機は、前記冗長コードと、前記冗長コードの生成で使用されたデータブロックの情報を示す構成情報と、を前記冗長コードドライブに送信し、
　前記冗長コードドライブは、前記冗長コードを記憶媒体に格納し、
　前記冗長コードドライブは、前記冗長コードの格納先と前記ライトデータブロックの格納先との関係を管理する。

Claims

　分散型ストレージシステムであって、
　ネットワークを介して通信する複数のノードと、
　前記分散型ストレージシステムは更に複数のストレージデバイスと、を含み、
　少なくとも３以上のノードを含む第１ノードグループが予め定義されており、
　前記第１ノードグループのノードそれぞれは、その管理しているストレージデバイスに格納するデータを、前記第１ノードグループに属する他ノードに送信し、
　前記第１ノードグループの第１ノードは、前記第１ノードグループの２以上の他ノードから、データを受信し、
　前記第１ノードは、前記２以上の他ノードから受信したデータの組み合わせを使用して冗長コードを生成し、
　前記第１ノードは、前記生成した冗長コードを、前記冗長コードを生成したデータを格納するストレージデバイスとは異なるストレージデバイスに格納し、
　前記第１ノードが生成する冗長コードのうち、少なくとも二つの冗長コードのデータ組み合わせは、構成するデータの論理アドレスの組み合わせが異なる、分散型ストレージシステム。
　請求項１に記載の分散型ストレージシステムであって、
　前記第１ノードグループのノードそれぞれは、前記管理しているストレージデバイスに格納するデータから、ノード内冗長コードを生成する、分散型ストレージシステム。
　請求項１に記載の分散型ストレージシステムであって、
　前記第１ノードは、
　キャッシュを含み、
　前記２以上の他ノードから受信したデータを前記キャッシュに一時的に格納し、
　前記キャッシュに一時的に格納した前記データからデータを選択し、
　前記選択したデータから一つの冗長コードを生成する、分散型ストレージシステム。
　請求項１に記載の分散型ストレージシステムであって、
　前記第１ノードは、前記冗長コードそれぞれと、前記冗長コードそれぞれの生成に使用したデータの送信元ノードそれぞれにおける論理アドレス情報とを、関連付けて管理する、分散型ストレージシステム。
　請求項１に記載の分散型ストレージシステムであって、
　前記冗長コードそれぞれを生成するデータの数は不定である、分散型ストレージシステム。
　請求項１に記載の分散型ストレージシステムであって、
　前記複数のノードにおいて、少なくとも３以上のノードを含む第２ノードグループ及び第３ノードグループが予め定義されており、
　前記第２ノードグループに属する第２ノードは、
　前記第１ノードグループに属するノード及び前記第３ノードグループに属するノードから受信したデータを使用して第２レベル冗長コードを生成し、
　前記第２レベル冗長コードを、前記第２ノードが管理するストレージデバイスに格納する、分散型ストレージシステム。
　請求項１に記載の分散型ストレージシステムであって、
　前記第１ノードは、前記冗長コードを格納する領域が閾値に達した後、
　前記領域に格納されている第１冗長コードと第２冗長コードを選択し、
　前記第１冗長コードと前記第２冗長コードをマージして、異なるノードのみから送信されたデータの第３冗長コードを生成し、
　前記第１冗長コードと前記第２冗長コードとを消去して前記第３冗長コードを前記領域に格納する、分散型ストレージシステム。
　請求項１に記載の分散型ストレージシステムであって、
　前記第１ノードに第１データを送信した前記第１ノードグループに属する第２ノードは、前記第１データを前記第２ノードが管理するストレージでバイスから消去する前に、前記第１データを前記第１ノードに送信し、
　前記第１ノードは、前記第１データを使用して、前記第１データを使用して生成した第１冗長コードを更新する、分散型ストレージシステム。
　請求項１に記載の分散型ストレージシステムであって、
　前記第１ノードグループに属し、前記第１ノードに第１データを送信した第２ノードは、
　前記第１データの更新データと、前記第１データとを使用して、中間データを生成し、前記中間データを前記第１ノードに送信し、
　前記第１ノードは、前記中間データを使用して前記第１データを使用して生成した冗長コードを更新する、分散型ストレージシステム。
　請求項２に記載の分散型ストレージシステムであって、
　前記第１ノードは、
　前記管理しているストレージデバイスに格納するデータを分割して、ノード内冗長コードを生成し、
　前記分割したデータの少なくとも一部、及び、前記ノード内冗長コードを、前記第１ノードグループの他ノードに送信し、
　前記第１ノードが生成する冗長コードに使用されるデータの組み合わせは、他のノードから送信されたノード内冗長コードを含む、分散型ストレージシステム。
　請求項１に記載の分散型ストレージシステムであって、
　前記第１ノードグループに属する複数のノードが格納するデータを使用して冗長コードを生成するノードは、前記第１ノードグループにおいて分散されている、分散型ストレージシステム。
　ネットワークを介して通信する複数ノードを含む分散型ストレージシステムにおける一つのノードにおいて実行されるデータ制御方法であって、
　前記分散型ストレージシステムは更に複数のストレージデバイスを含み、
　少なくとも３以上のノードを含む第１ノードグループが予め定義されており、
　前記データ制御方法は、
　管理するストレージデバイスに格納するデータを、前記第１ノードグループに属する他ノードに送信し、
　前記第１ノードグループに属する２以上の他ノードから受信したデータの組み合わせを使用して冗長コードを生成し、
　前記生成した冗長コードを、前記冗長コードを生成したデータを格納するストレージデバイスとは異なるストレージデバイスに、格納する、ことを含み、
　生成する冗長コードのうち、少なくとも二つの冗長コードを生成するデータ組み合わせは、構成するデータの論理アドレスの組み合わせが異なる、方法。
　請求項１２に記載の方法であって、
　前記管理しているストレージデバイスに格納するデータから、ノード内冗長コードを生成することをさらに含む、方法。
　請求項１２に記載の方法であって、
　前記２以上の他ノードから受信したデータをキャッシュに一時的に格納し、
　前記キャッシュに一時的に格納した前記データからデータを選択し、
　前記選択したデータから一つの冗長コードを生成する、方法。
　請求項１２に記載の方法であって、
　前記冗長コードそれぞれと、前記冗長コードそれぞれの生成に使用したデータの送信元ノードそれぞれにおける論理アドレス情報とを、関連付けて管理する、方法。