JP2023099186A

JP2023099186A - 複数の故障ドメインに及ぶストレージシステム

Info

Publication number: JP2023099186A
Application number: JP2023076567A
Authority: JP
Inventors: ダヤン，マオールベン; Ben Dayan Maor; パルモン，オムリ; Palmon Omri; ズビベル，リラン; Zvibel Liran; アルディッティ，カナエル; Arditti Kanael
Original assignee: Weka Io Ltd
Current assignee: Weka Io Ltd
Priority date: 2018-06-12
Filing date: 2023-05-08
Publication date: 2023-07-11
Also published as: EP3807767A2; CN112262372A; US11693738B2; JP2021533440A; JP7277485B2; US20190377638A1; US20230273859A1; WO2019239210A2; US11422893B2; US20210200638A1; US20220342756A1; US10942807B2; WO2019239210A3; EP3807767A4

Abstract

【課題】複数の故障ドメインに及ぶストレージシステムを構築するための方法およびシステム提供する。【解決手段】分散型ファイルシステムにおいて、複数の故障ドメインが、ネットワークを介して互いに通信連結され、複数の故障ドメインのそれぞれが、１つまたは複数のストレージデバイスに連結される。耐障害性ストライプの２つ以上のブロックが各故障ドメイン内に置かれるように、耐障害性ストライプが、複数のストレージデバイスにわたって分散される。【選択図】図１

Description

優先権の主張
[0001]本出願は、２０１８年６月１２日に出願の「ＳｔｏｒａｇｅＳｙｓｔｅｍＳｐａｎｎｉｎｇＭｕｌｔｉｐｌｅＦａｉｌｕｒｅＤｏｍａｉｎｓ」と題する米国仮特許出願第６２／６８３，８４１号、および、２０１９年２月１４日に出願の「ＳｔｏｒａｇｅＳｙｓｔｅｍＳｐａｎｎｉｎｇＭｕｌｔｉｐｌｅＦａｉｌｕｒｅＤｏｍａｉｎｓ」と題する米国特許出願第１６／２７５，７３７号の優先権を主張する。

[0002]データストレージへの従来のアプローチの限界および短所は、図面を参照しながら本開示の以降で示される本方法およびシステムのいくつかの態様と、このようなアプローチとの比較を通じて、当業者には明らかになるであろう。

参照による組込み
[0003]「ＤｉｓｔｒｉｂｕｔｅｄＥｒａｓｕｒｅＣｏｄｅｄＶｉｒｔｕａｌＦｉｌｅｓｙｓｔｅｍ」と題する米国特許出願第１５／２４３，５１９号が、本明細書によって全体として参照により本明細書に組み込まれる。

[0004]特許請求の範囲でより完全に示されるように、図の少なくとも１つによって実質的に示されるような、および／または、図の少なくとも１つに関連して説明されるような、分散型ファイルシステムにおける複数の故障ドメインに及ぶストレージシステムを構築するための方法およびシステムが提供される。

本開示の態様による分散型ファイルシステムの様々な実例の構成を示す図である。本開示の態様による分散型ファイルシステムノードの実例の構成を示す図である。本開示の実例の実装形態による分散型ファイルシステムの別の表現を示す図である。本開示の実例の実装形態による分散型ファイルシステムの別の表現を示す図である。本開示の実例の実装形態による分散型ファイルシステムを生成するための実例の方法を示す流れ図である。２つの分散型耐障害性（ｆａｉｌｕｒｅｒｅｓｉｌｉｅｎｔ）アドレス空間が複数のソリッドステートストレージディスク上に常駐する実例の実装形態を示す図である。本開示の実例の実装形態による仮想ファイルシステムの不揮発性メモリに記憶されたデータを保護するために使用することができる前方誤り訂正方式を示す図である。

[0012]従来、ファイルシステムは、メタデータ構造（例えば、ディレクトリ、ファイル、属性、ファイル内容）に対して集中型制御を使用する。ローカルファイルシステムが単一のサーバからアクセス可能であり、このサーバが故障した場合、さらなる保護がない場合、ファイルシステムのデータは失われる可能性がある。保護を追加するために、いくつかのファイルシステムは（例えば、ネットワークアプライアンス（ＮｅｔＡｐｐ）によって提供されるように）、能動的－受動的手法でコントローラの１つまたは複数のペアを使用して、２つ以上のコンピュータにまたがるメタデータを複製してきた。他の解決策は、（例えば、ＩＢＭＧＰＦＳ、ＤｅｌｌＥＭＣＩｓｉｌｏｎ、Ｌｕｓｔｒｅ、等によって提供されるような）クラスタ方式で複数のメタデータサーバを使用してきた。それでも、従来のクラスタ型システムにおけるメタデータサーバの数は少数に限定されるので、このようなシステムは、規模を変更することができない。

[0013]本開示におけるシステムは、小さいクラスタに適用可能であり、数千ものノードまで規模を変更することもできる。例えば、ソリッドステートドライブ（ＳＳＤ：ｓｏｌｉｄ－ｓｔａｔｅｄｒｉｖｅ）の形で入手できるフラッシュメモリといった、不揮発性メモリ（ＮＶＭ：ｎｏｎ－ｖｏｌａｔｉｌｅｍｅｍｏｒｙ）に関して実施形態の例が論じられる。ＮＶＭは、４ｋＢのブロックおよび１２８ＭＢのチャンクに分割されてもよい。大きさ（ｅｘｔｅｎｔ）は、例えば、高速アクセスのためのＲＡＭといった、揮発性メモリに記憶することができ、ＮＶＭストレージによってバックアップも行われる。大きさは、例えば、ブロックに記憶されたデータのうちの１ＭＢに対して２５６個のポインタといった、ブロックに対するポインタを記憶することができる。他の実施形態では、より大きいまたは小さいメモリ分割が使用されてもよい。本開示におけるメタデータの機能は、多くのサーバにわたって効果的に拡散されてもよい。例えば、ファイルシステムの名前空間の特定の部分に大きい負荷が向けられる「ホットスポット」の場合、この負荷は、複数のノードにわたって分散されることが可能である。

[0014]図１は、本開示の態様による分散型ファイルシステムの様々な実例の構成を示す。ローカルエリアネットワーク（ＬＡＮ）１０２が図１に示され、（ｊ≧１のとき、１からＪまでの整数でインデックスをつけられた）１つまたは複数のノード１２０を備え、任意選択として、（断続線によって示された）（Ｍ≧１のとき、１からＭまでの整数でインデックスをつけられた）１つもしくは複数の専用ストレージノード１０６、（Ｎ≧１のとき、１からＮまでの整数でインデックスをつけられた）１つもしくは複数の計算ノード１０４、および／または、リモートネットワーク１１８にＬＡＮ１０２を接続するエッジルータを備える。リモートネットワーク１１８は、任意選択として、（Ｋ≧１のとき、１からＫまでの整数でインデックスをつけられた）１つもしくは複数のストレージサービス１１４、および／または（Ｌ≧１のとき、１からＬまでの整数でインデックスをつけられた）１つもしくは複数の専用ストレージノード１１５を備える。

[0015]各ノード１２０_ｊ（ｊは整数であり、ここで、１≦ｊ≦Ｊである）は、ネットワーク型コンピューティングデバイス（例えば、サーバ、パーソナルコンピュータ、または同様のもの）であり、デバイス１０４_ｎのオペレーティングシステム上で直接的に、および／または、デバイス１０４_ｎで動く１つもしくは複数の仮想マシンにおいて、プロセス（例えば、クライアントプロセス）を動かすための回路機器を備える。

[0016]計算ノード１０４は、ネットワーク型デバイスであり、仮想バックエンドなしで仮想フロントエンドを動かすことができる。計算ノード１０４は、単一ルート入出力仮想化（ＳＲ－ＩＯＶ：ｓｉｎｇｌｅｒｏｏｔｉｎｐｕｔ／ｏｕｔｐｕｔｖｉｒｔｕａｌｉｚａｔｉｏｎ）をネットワークインターフェースカード（ＮＩＣ：ｎｅｔｗｏｒｋｉｎｔｅｒｆａｃｅｃａｒｄ）に取り入れること、および、全てのプロセッサコアを使い尽くすことによって、仮想フロントエンドを動かすことができる。代替として、計算ノード１０４は、Ｌｉｎｕｘ（登録商標、以下同様。）カーネルのネットワーキングスタックを通じたネットワーク形成を迂回させること（ｒｏｕｔｉｎｇ）、および、カーネルのプロセススケジューリングを使用することによって仮想フロントエンドを動かすことができ、したがって、全コアを要求しない。これは、ユーザが全てのコアをファイルシステムにアロケートしたくない場合、または、ネットワーキングハードウェアがファイルシステム要件と互換性がない場合に有用である。

[0017]図２は、本開示の態様によるノードの実例の構成を示す。ノードは、フロントエンド２０２およびドライバ２０８、メモリコントローラ２０４、バックエンド２０６、ならびにＳＳＤエージェント２１４を備える。フロントエンド２０２は、仮想フロントエンドであってもよく、メモリコントローラ２０４は、仮想メモリコントローラであってもよく、バックエンド２０６は、仮想バックエンドであってもよく、ドライバ２０８は、仮想ドライバであってもよい。本開示で使用されるように、仮想ファイルシステム（ＶＦＳ：ｖｉｒｔｕａｌｆｉｌｅｓｙｓｔｅｍ）プロセスは、フロントエンド２０２、メモリコントローラ２０４、バックエンド２０６、およびＳＳＤエージェント２１４の１つまたは複数を実装するプロセスである。したがって、１つの実例の実装形態では、ノードのリソース（例えば、プロセスリソースおよびメモリリソース）は、クライアントプロセスとＶＦＳプロセスの間で共有されてもよい。ＶＦＳのプロセスは、クライアントアプリケーションの性能への影響を最小化するために、比較的少量のリソースを要求するように構成されてもよい。フロントエンド２０２、メモリコントローラ２０４、ならびに／または、バックエンド２０６および／もしくはＳＳＤエージェント２１４は、ホスト２０１のプロセッサ上で、またはネットワークアダプタ２１８のプロセッサ上で動くことができる。マルチコアプロセッサについて、異なるＶＦＳプロセスが、異なるコア上で動くことができ、サービスの異なるサブセットを動かすことができる。クライアントプロセス２１２の観点から、仮想ファイルシステムとのインターフェースは、ＶＦＳプロセスが動いている特定の物理マシンから独立している。クライアントプロセスは、ドライバ２０８およびフロントエンド２０２の役割を果たすために、ドライバ２０８およびフロントエンド２０２が存在することしか必要としない。

[0018]ノードは、オペレーティングシステム上で直接的に動く単一のテナントサーバ（例えば、ベアメタル）として、または、ベアメタルサーバ内の仮想マシン（ＶＭ：ｖｉｒｔｕａｌｍａｃｈｉｎｅ）および／もしくはコンテナ（例えば、Ｌｉｎｕｘコンテナ（ＬＸＣ：Ｌｉｎｕｘｃｏｎｔａｉｎｅｒ））として実装することができる。ＶＦＳは、ＶＭ環境としてＬＸＣコンテナ内で動くことができる。したがって、ＶＭの内部では、動くことができるものだけがＶＦＳを備えるＬＸＣコンテナである。代表的なベアメタル環境には、ユーザ空間アプリケーションがあり、ＶＦＳがＬＸＣコンテナ内で動く。他のコンテナ型アプリケーションをサーバが動かしている場合、ＶＦＳは、コンテナ導入環境（例えばＤｏｃｋｅｒ）の管理範囲外のＬＸＣコンテナの内部で動くことができる。

[0019]ノードは、オペレーティングシステムおよび／または仮想マシンモニタ（ＶＭＭ：ｖｉｒｔｕａｌｍａｃｈｉｎｅｍｏｎｉｔｏｒ）（例えば、ハイパーバイザ）によってサービスされてもよい。ＶＭＭは、ホスト２０１上でノードを作り出し、動かすために使用されてもよい。複数のコアが、ＶＦＳを動かしている単一のＬＸＣコンテナの内部に常駐することができ、ＶＦＳは、単一のＬｉｎｕｘカーネルを使用して、単一のホスト２０１上で動くことができる。したがって、単一のホスト２０１は、複数のフロントエンド２０２、複数のメモリコントローラ２０４、複数のバックエンド２０６、および／または、１つもしくは複数のドライバ２０８を備えることができる。ドライバ２０８は、ＬＸＣコンテナの範囲外のカーネル空間で動くことができる。

[0020]ユーザ空間２２２でネットワーキングスタック２１０を動かすために、ＳＲ－ＩＯＶＰＣＩｅ仮想機能が使用されてもよい。ＳＲ－ＩＯＶは、ＰＣＩＥｘｐｒｅｓｓの分離を可能にし、その結果、単一の物理的なＰＣＩＥｘｐｒｅｓｓが仮想環境で共有されることが可能になり、単一の物理サーバマシン上の異なる仮想構成要素に、異なる仮
想機能が提供されることが可能になる。Ｉ／Ｏスタック２１０は、ＶＦＳノードが標準的なＴＣＰ／ＩＰスタック２２０をバイパスし、ネットワークアダプタ２１８と直接的に通信することを可能にする。ＶＦＳドライバ２０８へのロックレス・キューを通じて、ポータブルオペレーティングシステムインターフェースフォーＵＮＩＸ（登録商標）（ＰＯＳＩＸ）のＶＦＳ機能が提供されてもよい。また、ＳＲ－ＩＯＶまたは完全なＰＣＩｅ物理機能アドレスが、ユーザ空間２２２で不揮発性メモリエクスプレス（ＮＶＭｅ：ｎｏｎ－ｖｏｌａｔｉｌｅｍｅｍｏｒｙｅｘｐｒｅｓｓ）ドライバ２１４を動かすために使用されてもよく、したがって、ＬｉｎｕｘＩＯスタックを完全にバイパスする。ＮＶＭｅは、ＰＣＩＥｘｐｒｅｓｓ（ＰＣＩｅ）バスを介して取り付けられた不揮発性ストレージ媒体２１６にアクセスために使用されてもよい。不揮発性ストレージ媒体２２０は、例えば、ソリッドステートドライブ（ＳＳＤ）の形で入手できるフラッシュメモリ、または、ＳＳＤもしくはメモリモジュール（ＤＩＭＭ）の形で入手できる可能性があるストレージクラスメモリ（ＳＣＭ）であってもよい。他の例は、３Ｄ－ＸＰｏｉｎｔなどのストレージクラスメモリ技術を含むことができる。

[0021]ＳＳＤは、ＳＳＤエージェント２１４およびネットワーキング２１０と、物理的なＳＳＤ２１６を連結することによって、ネットワーク型デバイスとして実装されてもよい。代替として、ＳＳＤは、ＮＶＭｅ－ｏＦ（ＮＶＭｅｏｖｅｒＦａｂｒｉｃｓ）などの、ネットワークプロトコルを使用することによって、ネットワーク接続型ＮＶＭｅＳＳＤ２２２または２２４として実装されてもよい。ＮＶＭｅ－ｏＦは、冗長なネットワークリンクを使用して、ＮＶＭｅデバイスへのアクセスを可能にすることができ、このことにより、より高いレベルまたは回復力をもたらす。ネットワークアダプタ２２６、２２８、２３０および２３２は、ＮＶＭｅＳＳＤ２２２および２２４を、サーバを使用しないネットワーク型ＮＶＭｅ－ｏＦデバイスに変換するために、ＮＶＭｅＳＳＤ２２２および２２４への接続のためのハードウェアアクセラレーションを備えることができる。ＮＶＭｅＳＳＤｓ２２２および２２４は、それぞれ、２つの物理ポートを備えることができ、データ全てが、これらのポートのいずれかを通じてアクセスされる可能性がある。

[0022]各クライアントプロセス／アプリケーション２１２は、オペレーティングシステム上で直接動くことができるか、または、オペレーティングシステムおよび／もしくはハイパーバイザによってサービスされた仮想マシンおよび／もしくはコンテナ内で動くことができる。クライアントプロセス２１２は、その基本機能の実施中に、ストレージからデータを読み込むこと、および／または、ストレージにデータを書き込むことができる。それでも、クライアントプロセス２１２の基本機能は、ストレージ関連のものではない（すなわち、プロセスは、そのデータが確実に記憶され、必要なときに検索可能であることにしか関心がなく、どこで、いつ、またはどのようにデータが記憶されるかには関心がない）。このようなプロセスを生じる実例のアプリケーションは、ｅメールサーバ、ウェブサーバ、オフィス生産性アプリケーション、顧客関係管理（ＣＲＭ）、アニメーテッドビデオレンダリング、ゲノミクス計算、チップデザイン、ソフトウェアビルド、およびエンタープライズリソースプラニング（ＥＲＰ）を含む。

[0023]クライアントアプリケーション２１２は、ＶＦＳドライバ２０８と通信する、カーネル２２４へのシステムコールを行うことができる。ＶＦＳドライバ２０８は、ＶＦＳフロントエンド２０２のキューに、対応するリクエストを入れる。いくつかのＶＦＳフロントエンドが存在する場合、ドライバは、異なるフロントエンドにアクセスを負荷分散させることができ、確実に、単一のファイル／ディレクトリが同じフロントエンドを介して常にアクセスされるようにする。これは、ファイルまたはディレクトリのＩＤに基づいて、フロントエンドをシャーディングする（ｓｈａｒｄ）ことによって行うことができる。ＶＦＳフロントエンド２０２は、その動作を担当するバケットに基づいて、適切なＶＦＳバックエンドにファイルシステムリクエストをルートするためのインターフェースを提供する。適切なＶＦＳバックエンドは、同じホスト上にあってもよく、または別のホスト上にあってもよい。

[0024]ＶＦＳバックエンド２０６は、いくつかのバケットをホストし、バケットのうちの各１つが、仮想ファイルシステムを別のやり方で管理するためのタスク（例えば、負荷分散、ジャーナリング、メタデータの維持、キャッシング、階層間のデータの移動、古くなったデータの削除、破損したデータの訂正、等）を受け取り、実行するというファイルシステムリクエストをサービスする。

[0025]ＶＦＳＳＳＤエージェント２１４は、それぞれのストレージデバイス２１６との対話を遂行する。これは、例えば、アドレスを翻訳すること、および、（例えば、ＳＡＴＡ、ＳＡＳ、ＰＣＩｅ、または他の適切なバス上の）ストレージデバイスに発行されるコマンドを生成することを含むことができる。したがって、ＶＦＳＳＳＤエージェント２１４は、ストレージデバイス２１６と、仮想ファイルシステムのＶＦＳバックエンド２０６との間の中間体として動作する。ＳＳＤエージェント２１４は、ＮＶＭｅ－ｏＦ（ＮＶＭｅｏｖｅｒＦａｂｒｉｃｓ）などの、標準プロトコルをサポートする標準的なネットワークストレージデバイスと通信することもできる。

[0026]図３は、本開示の実例の実装形態による分散型ファイルシステムの別の表現を示す。図３では、要素３０２は、上記の図２について説明されたものなどの、仮想ファイルシステムを常駐させる様々なノード（計算、ストレージ、および／またはＶＦＳ）の、メモリリソース（例えば、ＤＲＡＭおよび／または他の短期メモリ）、ならびに処理リソース（例えば、ｘ８６プロセッサ、ＡＲＭプロセッサ、ＮＩＣ、ＡＳＩＣ、ＦＰＧＡ、および／または同様のもの）を表す。要素３０８は、仮想ファイルシステムの長期ストレージを提供する１つまたは複数の物理ストレージデバイス２１６を表す。

[0027]図３に示されるように、物理ストレージは、複数の分散型耐障害性アドレス空間（ＤＦＲＡＳ：ｄｉｓｔｒｉｂｕｔｅｄｆａｉｌｕｒｅｒｅｓｉｌｉｅｎｔａｄｄｒｅｓｓｓｐａｃｅ）５１８に編成される。これらのそれぞれは、複数のチャンク３１０を含み、複数のチャンク３１０は、複数のブロック３１２を含む。チャンク３１０へのブロック３１２の編成は、いくつかの実装形態で利便性があるだけであり、全ての実装形態で行われなくてもよい。各ブロック３１２は、コミットされたデータ３１６（これは、様々な状態を呈することができ、下記で論じられる）、および／または、コミットされたデータ３１６を説明または参照するメタデータ３１４を記憶する。

[0028]複数のＤＦＲＡＳへのストレージ３０８の編成は、仮想ファイルシステムのノードの多く（おそらく全て）からの高性能並行コミットを可能にする（例えば、図１の全てのノード１０４_１～１０４_Ｎ、１０６_１～１０６_Ｍ、および１２０_１～１２０_Ｊが、同時コミットを並行に実施することができる）。１つの実例の実装形態では、仮想ファイルシステムのノードのそれぞれは、複数のＤＦＲＡＳのうちのそれぞれの１つまたは複数を所有し、ノードが所有するＤＦＲＡＳへの排他的な読込み／コミットアクセス権を有することができる。

[0029]各バケットは、ＤＦＲＡＳを所有し、したがって、ＤＦＲＡＳに書き込むときに、他のどのノードとも協調する必要はない。各バケットは、多くの異なるＳＳＤ上の多くの異なるチャンクにまたがってストライプを構築することができ、したがって、バケットのＤＦＲＡＳを有する各バケットは、多くのパラメータに現在基づいて、どの「チャンクストライプ」に書き込むべきかを選ぶことができ、このバケットにチャンクがアロケートされると、そうするために必要な協調はない。全てのバケットは、なにも協調する必要なく、全てのＳＳＤに効果的に書き込むことができる。

[0030]各ＤＦＲＡＳが、特定のノード上で動くＤＦＲＡＳの所有者バケットだけに所有され、アクセス可能であることは、（ストレージ３０８への実際の読込み／コミットに対して非同期的に実施されることが可能な、例えば、初期化中、またはノードの故障後の、ＤＦＲＡＳを保持するバケットの（再）割当て中を除いて）ＶＦＳのノードのそれぞれが、他のどのノードとも協調する必要なく、ストレージ３０８の一部を制御することを可能にする。したがって、このような実装形態では、各ノードは、他のノードが何をしているかに関わらず、ノードのバケットのＤＦＲＡＳに対して読込み／コミットを行うことができ、ストレージ３０８への読込みおよびコミットの際に、どのようなコンセンサスにも達する必要はない。さらに、特定のノードの故障の場合には、特定のノードが複数のバケットを所有するということが、他のノードへのノードの作業負荷の、よりインテリジェントかつ効率的な再配分を可能にする（ある程度、全作業負荷を単一のノードに割り当てなければならず、これは、「ホットスポット」作り出す可能性がある）。この点に関して、いくつかの実装形態では、バケットの数は、任意の１つのバケットが、別のノードにかけることになる負荷を比較的小さくすることができるように、システムにおけるノードの数に比べて大きくてもよい。これは、他のノードの能力および容量に応じた、故障したノードの負荷のきめ細かい再配分を可能にする（例えば、能力および容量が大きいノードには、より大きい割合の故障したノードバケットが与えられてもよい）。

[0031]このような動作を可能にするために、ストレージ３０８への読込みおよびコミットが、適切なノードにリダイレクトされることが可能になるように、バケットの現在の所有ノードに各バケットをマッピングするメタデータが維持されてもよい。

[0032]全ファイルシステムのメタデータ空間（例えば、ディレクトリ、ファイル属性、ファイル内の内容範囲、等）が、小さく一様な断片（例えば「シャード（ｓｈａｒｄ）」）に分解される（例えば、細断される、またはシャーディングされる）ことが可能なので、負荷分散は可能である。例えば、３０ｋ個のサーバを有する大きいシステムは、１２８ｋ個または２５６ｋ個のシャードにメタデータ空間を細断することができる。

[0033]それぞれのこのようなメタデータのシャードは、「バケット」内に維持されてもよい。各ＶＦＳノードは、いくつかのバケットにまたがって担当することができる。所与のバックエンド上でバケットがメタデータのシャードをサーブしているとき、バケットは、「アクティブ」であるか、または、このバケットの「リーダ（ｌｅａｄｅｒ）」であるとみなされる。典型的には、ＶＦＳノードよりはるかに多くのバケットがある。例えば、６個のノードを有する小さいシステムは、１２０個のバケットを有することができ、１，０００個のノードを有するより大きいシステムは、８ｋ個のバケットを有することができる。

[0034]各バケットは、ノードが、ノードのバケットに対してペンタグループを形成する典型的には５つのノードといった、ノードの小さいセット上に対してアクティブであってもよい。クラスタ構成は、各バケットへのペンタグループの割当てについて、全ての参加ノードを最新に保つ。

[0035]各ペンタグループは、それ自体を監視する。例えば、クラスタが１０ｋ個のサーバを有し、各サーバが６個のバケットを有する場合、各サーバは、そのバケットのステータスを維持するために、３０個の異なるサーバと会話する必要しかなくなる（６個のバケットは、６個のペンタグループを有することになるので、６×５＝３０である）。これは、集中型エンティティが全てのノードを監視し、クラスタ全体の状態を保たなければならない場合より、はるかに少ない数である。ペンタグループの使用は、クラスタサイズが大きくなったときでも、より多くの作業をノードが実施しないので、より大きいクラスタで性能の規模を変更することを可能にする。これは、「ダム（ｄｕｍｂ）」モードでは、小さいクラスタが、物理ノードが存在するよりも多くの通信を実際に生成する可能性があるという短所を課す可能性があるが、この短所は、サーバが共有するバケット全てを有する２つのサーバ間で、ただ１つのハートビートを送ることによって克服される（クラスタが大きくなるにつれて、これは、ただ１つのバケットに変化することになるが、小さい５つのサーバクラスタを有している場合、クラスタは、全てのメッセージに全てのバケットを含むだけになり、各サーバは、他の４つと会話するだけになる）。ペンタグループは、Ｒａｆｔコンセンサスアルゴリズムに似たアルゴリズムを使用して、決定する（すなわち、コンセンサスに達する）ことができる。

[0036]各バケットは、バケットを動かすことができる計算ノードのグループを有することができる。例えば、５つのＶＦＳノードは、１つのバケットを動かすことができる。それでも、グループ内のノードのただ１つが、任意の与えられた瞬間におけるコントローラ／リーダである。さらに、２つのバケットは、十分大きいクラスタのために同じグループを共有しない。クラスタ内に５つまたは６つのノードしかない場合、ほとんどのバケットは、バックエンドを共有することができる。適度に大きいクラスタには、多くの別個のノードグループがある。例えば、２６個のノードで、

より多くの可能な５ノードグループ（すなわち、ペンタグループ）がある。

[0037]グループ内の全てのノードは、ノードがこのバケットの実際のアクティブコントローラ（すなわち、リーダ）であることについて、知っており、同意する（すなわち、コンセンサスに達する）。バケットにアクセスするノードは、グループの（例えば、５つの）メンバから、このバケットに対するリーダだった最後のノードを覚えていること（「キャッシュすること」）ができる。ノードが、バケットリーダにアクセスする場合、バケットリーダは、リクエストされた動作を実施する。現在のリーダではないノードにバケットがアクセスする場合、このノードは、アクセスを「リダイレクトする」ようにリーダに指示する。キャッシュされたリーダノードにアクセスするタイムアウトがある場合、接触するノードは、同じペンタグループの異なるノードを試行することができる。クラスタ内のノード全てがクラスタの共通「構成」を共有し、これにより、ノードは、どのサーバが各バケットを動かすことができるかについて知ることができる。

[0038]各バケットは、ファイルシステム上で動いているアプリケーションによってどれだけ激しくバケットが使用されているかを示す負荷値／使用量値を有することができる。例えば、１１個の軽く使用されるバケットを有するサーバノードは、使用されるバケットの数に不均衡がある場合でも、９個の激しく使用されるバケットを有するサーバの前に動かすために、メタデータの別のバケットを受け取ることができる。負荷値は、平均レスポンスレイテンシ、同時に動く動作の数、消費されるメモリ、または他の基準値に従って決定されてもよい。

[0039]再配分は、ＶＦＳノードが故障していないときでも同様に発生させることができる。追跡した負荷基準値に基づいて、１つのノードが、他よりもビジー状態であることをシステムが識別した場合、システムは、あまりビジー状態ではない別のサーバに、システムのバケットのうちの１つを移動させる（すなわち、「フェールオーバー」させる）ことができる。それでも、異なるホストにバケットを実際に移す前に、書込みと読込みをそらすことによって、負荷分散が達成されてもよい。それぞれの書込みは、最終的に、ＤＦＲＡＳによって判定されたノードの異なるグループで終わる可能性があるので、より高い負
荷を有するノードが、データが書き込まれているストライプの中にあるように選択される可能性はない。また、システムは、非常に負荷の高いノードからの読込みをサーブしないように選ぶこともできる。例えば、「劣化モード読込み（ｄｅｇｒａｄｅｄｍｏｄｅｒｅａｄ）」が実施されてもよく、非常に負荷の高いノードにおけるブロックは、同じストライプの他のブロックから再現される。劣化モード読込みは、同じストライプ内の残りのノードによって実施される読込みであり、データは、障害保護を介して再現される。劣化モード読込みは、このノードがダウンしていることを、読込みのイニシエータが仮定することができるので、読込みレイテンシがとても高いときに実施されてもよい。より高い読込みレイテンシを作り出すのに十分、負荷が高い場合、クラスタは、他のノードからこのデータを読み込むこと、および、劣化モード読込みを使用して、必要なデータを再現することに戻ることができる。

[0040]各バケットは、独自の分散型イレイジャコーディングインスタンス（すなわち、ＤＦＲＡＳ５１８）を管理し、他のバケットと連携して、読込みまたは書込み動作を実施する必要がない。異なるバケットに対してそれぞれ、同時に作業する何千もの同時の分散型イレイジャコーディングインスタンスが潜在的に存在する。これは、任意の大きいファイルシステムが、協調される必要がない独立した断片に分割されることを効果的に可能にするので、スケーリング性能の切り離せない部分であり、したがって、スケールに関わらず高性能をもたらす。

[0041]各バケットは、そのシャードに属するファイルシステム動作全体を遂行する。例えば、ディレクトリ構造、ファイル属性、およびファイルデータ範囲は、特定のバケットの管轄区域に属することになる。

[0042]任意のフロントエンドから行われる動作は、どのバケットがこの動作を所有しているかを見つけ出すことによってスタートする。次に、このバケットに対するバックエンドリーダ、およびノードが決定される。この決定は、既知の最新のリーダを試行することによって実施されてもよい。既知の最新のリーダが現在のリーダではない場合、このノードは、どのノードが現在のリーダであるかを知ることができる。既知の最新のリーダが、もはやバケットのペンタグループの一部ではない場合、このバックエンドは、フロントエンドが構成に戻って、バケットのペンタグループのメンバを見つけるべきであることをフロントエンドに知らせることになる。動作の分散は、標準システム内の単一のコンピュータによってではなく、複数のサーバによって、複雑な動作が遂行されることを可能にする。

[0043]クラスタのサイズが小さく（例えば、５）、ペンタグループが使用される場合、同じグループを共有するバケットが存在することになる。クラスタサイズが大きくなると、２つのグループが同一にならないように、バケットが再分散される。

[0044]故障ドメインは、単一の構成要素の故障により、故障する（完全に、または一時的に利用不能になる）可能性のあるストレージデバイスのセットである。単一のサーバの故障がＳＳＤのグループをダウンさせることになる場合、単一のサーバ上のＳＳＤのこのグループは、故障ドメインとみなされてもよい。ラックが単一のネットワークスイッチを有する場合、このラックは、スイッチの故障により、全ラックがアクセス不能になる場合、故障ドメインとみなされる可能性がある。故障ドメインは、設置時に構成されてもよい。また、故障ドメインの構成は、グラフィカルユーザインターフェース（ＧＵＩ）、コマンドラインインターフェース（ＣＬＩ）、またはアプリケーションプログラミングインターフェース（ＡＰＩ）から制御されてもよい。故障ドメインの定義が設定されていない場合、単一のサーバが、故障ドメインとして使用されてもよい。このサーバ上にあるＳＳＤの全てが、データ配置の観点から、大きい単一のＳＳＤとして扱われてもよい。

[0045]図４は、本開示の実例の実装形態による分散型ファイルシステム４００の表現を示す。分散型ファイルシステム４００は、第１の故障ドメイン４０９ａ、第２の故障ドメイン４０９ｂ、および第３の故障ドメイン４０９ｃを備える。

[0046]第１の故障ドメイン４０９ａは、少なくとも１つのサーバ４０１ａ、および少なくとも１つのストレージデバイス４１１ａを備える。サーバ４０１ａは、第１のフロントエンド４０３ａおよび第１のバックエンド４０５ａを備える。第１のバックエンド４０５ａは、少なくとも１つのバケット４０７ａを備える。少なくとも１つのストレージデバイス４１１ａは、複数のソリッドステートデバイスを備えることができる。少なくとも１つのストレージデバイス４１１ａは、例えば、ブロックａ１およびブロックａ２といった、複数のブロックに構成されてもよい。

[0047]第２の故障ドメイン４０９ｂは、少なくとも１つのサーバ４０１ｂおよび少なくとも１つのストレージデバイス４１１ｂを備える。サーバ４０１ｂは、第２のフロントエンド４０３ｂおよび第２のバックエンド４０５ｂを備える。第２のバックエンド４０５ｂは、少なくとも１つのバケット４０７ｂを備える。少なくとも１つのストレージデバイス４１１ｂは、複数のソリッドステートデバイスを備えることができる。少なくとも１つのストレージデバイス４１１ｂは、例えば、ブロックｂ１およびブロックｂ２といった、複数のブロックに構成されてもよい。

[0048]第３の故障ドメイン４０９ｃは、少なくとも１つのサーバ４０１ｃおよび少なくとも１つのストレージデバイス４１１ｃを備える。サーバ４０１ｃは、第３のフロントエンド４０３ｃおよび第３のバックエンド４０５ｃを備える。第３のバックエンド４０５ｃは、少なくとも１つのバケット４０７ｃを備える。少なくとも１つのストレージデバイス４１１ｃは、複数のソリッドステートデバイスを備えることができる。少なくとも１つのストレージデバイス４１１ｃは、例えば、ブロックｃ１およびブロックｃ２といった、複数のブロックに構成されてもよい。

[0049]バケット４０７ａ、４０７ｂ、および４０７ｃは、複数のブロックを含む耐障害性ストライプを構築するように動作可能である。例えば、第１のバックエンド４０５ａにおけるバケット４０７ａは、ストライプ４１３を構築することができ、ストライプ４１３は、第１の故障ドメイン４０９ａのブロックａ１およびａ２、第２の第１の故障ドメイン４０９ｂのブロックｂ１およびｂ２、ならびに、第３の故障ドメイン４０９ｃのブロックｃ１およびｃ２を含む。複数のブロックａ１、ａ２、ｂ１、ｂ２、ｃ１、およびｃ２のうちの２つ以上のブロックは、エラー訂正情報を含むように構成される。

[0050]第１の故障ドメイン４０９ａの故障時、ブロックａ１およびａ２は、ブロックｂ１、ｂ２、ｃ１、および／またはｃ２に応じて再生成されてもよい。第２の故障ドメイン４０９ｂの故障時、ブロックｂ１およびｂ２は、ブロックａ１、ａ２、ｃ１、および／またはｃ２に応じて再生成されてもよい。

[0051]第１の故障ドメイン４０９ａおよび第２の故障ドメイン４０９ｂが互いに通信を喪失した場合、第３の故障ドメイン４０９ｃは、第１の故障ドメイン４０９ａと第２の故障ドメイン４０９ｂのどちらが、システムを動かし続けることになるかを判定するように動作可能である。第３の故障ドメイン４０９ｃによって許可が与えられない限り、第１の故障ドメイン４０９ａも第２の故障ドメイン４０９ｂも耐障害性ストライプ４１３を再構築しない。第３の故障ドメイン４０９ｃのブロックｃ１およびｃ２は、ストライプ４１３を再構築する際に使用されるデータを含んでも、含まなくてもよい。

[0052]第１のバックエンド４０５ａにおけるバケット４０５ｃが、耐障害性ストライプ４１３の初期リーダであってもよい。それでも、第１の故障ドメインの故障時には、第２のバックエンド４０５ｂのバケット４０７ｂが、再構築された耐障害性ストライプ４１３のリーダになることができる。再構築された耐障害性ストライプ４１３は、第１の故障ドメイン４０９ａが利用不能である場合、ブロックａ１およびａ２を使用することができない。

[0053]大きい故障ドメインが定義されてもよい。例えば、この故障ドメイン内のサーバ全てにあるＳＳＤの全ては、データ配置およびストライプ構成が考慮されるとき、ＳＳＤの全てが、１つの大きいＳＳＤストレージデバイスであるかのように扱われてもよい。これは、同じ故障ドメイン上の同じストライプに対する２つのデータブロックがなくても、ストライプが他の故障ドメインから常に再構築されることを可能にするので、ファイルシステムが、完全な故障ドメインの故障に耐えることを可能にする。

[0054]より大きい故障ドメインは、ストライプグループの量を減らし、再構築時間を増加させる。再構築プロセスは、他の故障ドメイン内の全ての利用可能なコンピュータから動くことができるので、全てのストライプが、同時に再構築されてもよい。

[0055]最も広いストライプサイズは、故障ドメインの量で限定されてもよい。例えば、１０個の故障ドメインでは、８つのデータブロックが、２つのエラー保護／訂正ブロックで（すなわち、８＋２個のストライプを使用して）保護されることが可能である。同様に、１０個の故障ドメインでは、６つのデータブロックが、４つのエラー保護／訂正ブロックで（すなわち、６＋４個のストライプを使用して）保護されることが可能である。

[0056]また、故障ドメインは、各故障ドメイン内の単一のストライプから、データ配置の最大量を限定することができる。例えば、３つまたは４つのデータセンタを大都市圏に有する組織は、そのデータセンタ全てにまたがってクラスタを動かすことができるので、１つのデータセンタが故障した場合、残りのデータセンタが動作を続けることができる。

[0057]３つのデータセンタでは、ファイルシステムは、５＋４個の方式で保護されることが可能であり、ここで、３つ以下のデータが、同じ故障ドメインにあってもよい。この例では、データセンタが故障した場合でも、再構築するために使用されることが可能な各ストライプからの、少なくとも６つのデータを有する２つの他のデータセンタが依然として存在する。３つのデータセンタのケースは、同じ故障ドメイン内に２つ以下のデータがある４＋２個の保護を使用することもできる。４つのデータセンタでは、例えば、同じ故障ドメイン内に２つ以下のデータがある４＋２個の保護が使用されることが可能である。

[0058]２つのデータセンタは、各データセンタ内に２つ以下のデータピース／ブロックがある２＋２個のデータ保護を使用することができる。それでも、このケースは、どのデータセンタが活動しているかをファイルシステムが判定する必要があり、このことにより、独立して作動をスタートする２つのデータセンタにクラスタが単に分かれる「スプリットブレイン」の状況を防ぐ。「スプリットブレイン」のシナリオを防ぐために、別のインスタンス／サーバが、第３のデータセンタに追加されてもよい。第３のデータセンタは、２つのデータセンタとの通信を監視／制御することができ、第１および第２のデータセンタが互いに通信を喪失した場合、（例えば、第３の故障ドメインにおける）この第３のデータセンタは、サーバのどちらの半分が、システムとして動き続けることができるかを判定すること（ならびに、第１および第２のデータセンタ内のサーバに知らせること）ができる。動作し続ける（およびデータの再構築をスタートする）ための許可を、タイブレーカノード（第３のデータセンタ）がハーフクラスタに与えない限り、ハーフクラスタは、ハーフクラスタ自体で作動することを促進されることはない。

[0059]このような状況の中で再構築するとき、残りの故障ドメインが全てダウンしている限り、ファイルシステムは、アップしている残りの故障ドメインにデータを再構築して、個々のサーバ故障に対する高い回復力を維持することになる。この故障ドメインがオンラインに戻ると、データは、各故障ドメイン上の各ストライプから、データピースの必要な最大量を維持するために、再配布される（もう一度再構築される）ことになる。

[0060]可用性グループは、ともにフェールオーバーし、故障ドメインとみなされるサーバのグループである。可用性グループがアップしているとき、可用性グループは、データにアクセスすることができる。可用性グループがともにダウンしているとき、他のサーバは、システムの定義されたデータセットにまたがるデータに依然としてアクセスすることができる。可用性グループは、データ分散を制御する別の方式である。可用性グループは、互いに保護するサーバおよびファイルシステムのグループ（例えば、大きい名前空間のサブセット）を選ぶ。可用性グループは、例えば、このデータセンタ内の特定の部屋にあってもよい。これらのサーバがアップしている限り、このファイルシステムのための全てのデータが、他のサーバにではなく、これらのサーバに記憶されることになる。その結果、他のサーバが故障しても（例えば、データセンタの他の部屋が電力を喪失しても）、このファイルシステムは、これらのサーバ上で依然として利用可能になる。また、可用性グループは、単一のラック内の全てのサーバとして定義することができる。このラックがアップし、動いている限り、サービスは、クラスタの他のラックから独立したこのラックから動作を続けることができる。

[0061]図５は、本開示の実例の実装形態による分散型ファイルシステムを生成するための実例の方法を示す流れ図である。ブロック５０１では、複数のデータピースが、第１の故障ドメインによって受け取られる。ブロック５０３では、複数のエラー訂正ピースが、複数のデータピースに応じて生成される。ブロック５０５では、複数のブロックを含む耐障害性ストライプが、第１の故障ドメインの第１のバックエンドによって構築される。耐障害性ストライプは、第１のバックエンド内のバケットによって構築されてもよい。第１のバックエンド内のこのバケットは、別のバケットがリーダに昇格されるまで、耐障害性ストライプのリーダになる。

[0062]複数のブロックの各ブロックは、複数のデータピースのうちの１つのデータピース、または複数のエラー訂正ピースのうちの１つのエラー訂正ピースを含む。ブロック５０７では、耐障害性ストライプの２つ以上のブロックが、第１の故障ドメイン内に置かれ、耐障害性ストライプの２つ以上の他のブロックが、第２の故障ドメイン内に置かれる。

[0063]ブロック５０９では、第１の故障ドメインが故障した場合、第１の故障ドメイン内のブロックが、第２の故障ドメイン内のブロックに応じて再生成される。ブロック５１１では、第２の故障ドメインが故障した場合、第２の故障ドメイン内のブロックが、第１の故障ドメイン内のブロックに応じて再生成される。

[0064]ネットワーククラスタ内に２個の故障ドメインしかない場合、第１および第２の故障ドメインが互いに通信を喪失したことを、別のデバイスが検出することができる。この他のデバイスは、次に、第１の故障ドメインと第２の故障ドメインのどちらが、耐障害性ストライプを再構築することになるかを判定することができる。一定の実施形態では、第３の故障ドメインによって許可が与えられない限り、第１の故障ドメインも第２の故障ドメインも耐障害性ストライプを再構築することができない。

[0065]バケットリーダが、故障しているドメイン内にある場合、別の故障ドメイン内のバケットが、耐障害性ストライプが再構築されたときに、耐障害性ストライプのリーダに
なるように昇格されてもよい。

[0066]図６は、複数のソリッドステートストレージディスク上に２つの分散型耐障害性アドレス空間が常駐する実例の実装形態を示す。

[0067]チャンク９１０_１，１～９１０_Ｄ，Ｃは、複数のチャンクストライプ９２０_１～９２０_Ｓ（Ｓは整数である）に編成されてもよい。１つの実例の実装形態では、各チャンクストライプ９２０_ｓ（ｓは整数であり、ここで、１≦ｓ≦Ｓである）は、前方誤り訂正（例えば、イレイジャコーディング）を使用して別々に保護される。したがって、任意の特定のチャンクストライプ９２０ｓにおけるチャンク９１０_ｄ，ｃの数は、所望のレベルのデータ保護に基づいて決定されてもよい。

[0068]例証のために、各チャンクストライプ９２０_ｓが、Ｎ＝Ｍ＋Ｋ（ここで、Ｎ、Ｍ、およびＫのそれぞれは整数である）個のチャンク９１０_ｄ，ｃを含むと仮定すると、Ｎ個のチャンク９１０_ｄ，ｃのうちのＭ個は、データディジット（典型的には、現在のストレージデバイスのためのバイナリディジットまたは「ビット」）を記憶することができ、Ｎ個のチャンク９１０_ｄ，ｃのうちのＫ個は、保護ディジット（やはり、典型的には、ビット）を記憶することができる。各ストライプ９２０_ｓについて、次に、仮想ファイルシステムは、Ｎ個の異なる故障ドメインからＮ個のチャンク９１０_ｄ，ｃを割り当てることができる。

[0069]本明細書で使用されるように、「故障ドメイン」は、構成要素のうちの任意のただ１つの故障（構成要素が電力を喪失すること、反応しなくなること、および／または同様のもの）が、構成要素全ての故障を生じる可能性がある構成要素のグループを指す。例えば、ラックが、単一のトップオブザラックスイッチを有する場合、このスイッチの故障が、このラック上の（例えば、計算、ストレージ、および／またはＶＦＳノードといった）構成要素全てへの接続をダウンさせることになる。したがって、残りのシステムに対して、これは、このラック上の構成要素全てが一緒に故障した場合に等しい。本開示による仮想ファイルシステムは、チャンク９１０より少ない故障ドメインを含むことができる。

[0070]仮想ファイルシステムのノードが、このようなノードあたり１つのストレージデバイス９０６しかないという完全に冗長な方式で接続され、電力供給される１つの実例の実装形態では、故障ドメインは、この単一のストレージデバイス９０６だけになる可能性がある。したがって、１つの実例の実装形態では、各チャンクストライプ９２０_ｓは、ストレージデバイス９０６_１～９０６_ＤのうちのＮ個のそれぞれに常駐する複数のチャンク９１０_ｄ，ｃを含む（したがって、ＤはＮより大きいか、または等しい）。このような実装形態の例が図９に示される。

[0071]図６では、Ｄ＝７、Ｎ＝５、Ｍ＝４、Ｋ＝１であり、ストレージは、２つのＤＦＲＡＳに編成される。これらの数は例証にすぎず、限定することを意図するものではない。第１のＤＦＲＡＳの３つのチャンクストライプ９２０が、例証として任意にコールアウトされる。第１のチャンクストライプ９２０_１は、チャンク９１０_１，１、９１０_２，２、９１０_３，３、９１０_４，５、および９１０_５，６からなり、第２のチャンクストライプ９２０_２は、チャンク９１０_３，２、９１０_４，３、９１０_５，３、９１０_６，２、および９１０_７，３からなり、第３のチャンクストライプ９２０_３は、チャンク９１０_１，４、９１０_２，４、９１０_３，５、９１０_５，７、および９１０_７，５からなる。

[0072]図６の単純な例ではＤ＝７かつＮ＝５であるが、実際の実装形態では、Ｄは、（例えば、１より大きい整数の倍数による、および場合によっては、多くの桁数による）Ｎよりはるかに大きくてもよく、２つの値は、Ｎ個のストレージデバイス９０６の同じセットに（または、より一般には、Ｎ個の故障ドメインの同じセットに）常駐する単一のＤＦＲＡＳの任意の２つのチャンクストライプ９２０の確率が所望の閾値を下回るように選ばれてもよい。このように、任意の単一のストレージデバイス９０６_ｄ（または、より一般には、任意の単一の故障ドメイン）の故障は、（ＤおよびＮの選ばれた値、Ｎ個のストレージデバイス９０６のサイズ、ならびに故障ドメインの配置に基づいて決定された所望の統計学的確率で）任意の特定のストライプ９２０_ｓの多くても１つのチャンク９１０_ｂ，ｃの喪失を生じることになる。さらに、２重の故障により、圧倒的多数のストライプが、多くても１つのチャンク９１０_ｂ，ｃを喪失することになり、（ＤおよびＮの値に基づいて決定された）少数のストライプだけが、任意の特定のストライプ９２０_ｓから２つのチャンクを喪失することになる（例えば、２つの故障ストライプの数は、１つの故障ストライプの数より指数関数的に小さくなる可能性がある）。

[0073]例えば、各ストレージデバイス９０６_ｄが１ＴＢであり、各チャンクが１２８ＭＢである場合、ストレージデバイス９０６_ｄの故障により、（ＤおよびＮの選ばれた値、Ｎ個のストレージデバイス９０６のサイズ、ならびに故障ドメインの配置に基づいて決定された所望の統計学的確率で）７８１２（＝１ＴＢ／１２８ＭＢ）個のチャンクストライプ９２０が１つのチャンク９１０を喪失することになる。それぞれのこのような影響を受けたチャンクストライプ９２０_ｓについて、喪失チャンク９１０_ｄ，ｃは、適切な前方誤り訂正アルゴリズム、およびチャンクストライプ９２０_ｓの他のＮ－１個のチャンクを使用して、素早く再現されることが可能である。さらに、影響を受けた７８１２個のチャンクストライプが、ストレージデバイス９０６_１～９０６_Ｄの全てにわたって一様に分散されるので、喪失した７８１２個のブロック９１０_ｄ，ｃを再現することは、（ＤおよびＮの選ばれた値、Ｎ個のストレージデバイス９０６のサイズ、ならびに故障ドメインの配置に基づいて決定された所望の統計学的確率で）ストレージデバイス９０６_１～９０６_Ｄのそれぞれから同じ量のデータを読み込むことを伴うことになる（すなわち、喪失データを再現する負担は、故障からの非常に素早い回復をもたらすように、ストレージデバイス９０６_１～９０６_Ｄの全てにわたって一様に分散される）。

[0074]次に、ストレージデバイス９０６_１～９０６_Ｄのうちの２つの同時故障（または、より一般には、２つの故障ドメインの同時故障）のケースに移ると、ストレージデバイス９０６_１～９０６_Ｄの全てにわたる各ＤＦＲＡＳのチャンクストライプ９２０_１～９２０_Ｓの一様な分散により、非常に少数のチャンクストライプ９２０_１～９２０_Ｓだけが、これらのＮ個のチャンクのうちの２つを喪失していることになる。仮想ファイルシステムは、チャンクストライプ９２０_１～９２０_Ｓとストレージデバイス９０６_１～９０６_Ｄとの間のマッピングを示すメタデータに基づいて、このような２つの喪失チャンクストライプを素早く識別するように動作可能であってもよい。このような２つの喪失チャンクストライプが識別されると、仮想ファイルシステムは、１つの喪失チャンクストライプの再現を始める前に、これらの２つの喪失チャンクストライプの再現を優先させることができる。残りのチャンクストライプは、単一の喪失チャンクだけを有することになり、これら（影響を受けたチャンクストライプの大半）について、２つのストレージデバイス９０６_ｄの同時故障は、ただ１つのストレージデバイス９０６_ｄの故障と同じである。類似の原理は、第３の同時故障などに適用される（３つの故障ブロックを有するチャンクストライプの数は、２つの同時故障シナリオにおける２つの故障ブロックを有する数よりむしろ小さくなる）。１つの実例の実装形態では、チャンクストライプ９２０_ｓの再現が実施される比率は、チャンクストライプ９２０_ｓ内の喪失の数に基づいて制御されてもよい。これは、例えば、再現のための読込みおよびコミットが実施される比率、再現のためのＦＥＣ計算が実施される比率、再現のためのネットワークメッセージが通信される比率、等を制御することによって達成されてもよい。

[0075]図７は、本開示の実例の実装形態による仮想ファイルシステムの不揮発性メモリ
に記憶されたデータを保護するために使用されることが可能な前方誤り訂正方式を示す。ＤＦＲＡＳのブロックストライプ９３０_１～９３０_４のストレージブロック９０２_１，１～９０２_７，７が示される。図７の保護方式では、各ストライプの５つのブロックが、データディジットのストレージのためのものであり、各ストライプの２つのブロックが、保護ディジットのデータストレージのためのものである（すなわち、Ｍ＝５かつＫ＝２である）。図７では、以下の方程式（１）～（９）を使用して、保護ディジットが計算される。

[0076]したがって、図７における４つのストライプ９３０_１～９３０_４は、マルチストライプ（この場合、４つのストライプ）ＦＥＣ保護ドメインの一部であり、ブロックストライプ９３０_１～９３０_４のいずれかにおける任意の２つ以下のブロックの喪失は、上記の方程式（１）～（９）の様々な組合せを使用することによって回復されることが可能である。比較として、単一のストライプ保護ドメインの例は、Ｄ１_１、Ｄ２_２、Ｄ３_３、Ｄ４_４、Ｄ５_４がＰ１によってのみ保護され、Ｄ１_１、Ｄ２_２、Ｄ３_３、Ｄ４_４、Ｄ５_４、およびＰ１が、ストライプ９３０_１に全て書き込まれる場合である（９３０_１は、単一のストライプＦＥＣ保護ドメインである）。

[0077]本開示の実例の実装形態によれば、複数のコンピューティングデバイスは、ネットワークを介して互いに通信連結され、複数のコンピューティングデバイスのそれぞれは、複数のストレージデバイスの１つまたは複数を備える。複数の耐障害性アドレス空間は、複数の耐障害性アドレス空間のそれぞれが複数のストレージデバイスに及ぶように、複数のストレージデバイスにわたって分散される。複数の耐障害性アドレス空間のうちのそれぞれの１つは、複数のストライプ（例えば、図６および図７におけるような複数の９３０）に編成される。複数のストライプのそれぞれの１つまたは複数のストライプは、複数の前方誤り訂正（ＦＥＣ）保護ドメイン（例えば、図６などにおけるマルチストライプＦＥＣドメイン）のうちのそれぞれの１つの一部である。複数のストライプのそれぞれは、複数のストレージブロック（例えば、複数の９１２）を含むことができる。複数のストライプのうちの特定の１つの各ブロックは、複数のストレージデバイスのうちの異なる１つに常駐することができる。複数のストレージブロックの第１の部分（例えば、図７のストライプ９３０_１の９０２_１，２～９０２_１，６からなる５つの量）は、データディジットの記憶のためのものであってもよく、複数のストレージブロックの第２の部分（例えば、図７のストライプ９３０_１の９０２_１，１および９０２_１，７の２つの量）は、データディジットに少なくとも部分的に基づいて計算された保護ディジットの記憶のためのものであってもよい。

[0078]複数のコンピューティングデバイスは、複数のストライプにランクをつけるように動作可能であってもよい。ランクは、複数の耐障害性アドレス空間のうちの１つへの次のコミット動作のために、複数のストライプのどれを使用するべきかを選択するために使用されてもよい。ランクは、保護されたおよび／または保護されていないストレージブロックが、どれだけ複数のストライプのそれぞれにあるかに基づくことができる。複数のストライプのうちの任意の特定の１つについて、ランクは、複数のストライプのうちの特定の１つを有する複数のストレージデバイス上に記憶されたビットマップに基づくことができる。ランクは、データを現在記憶しているどれだけのブロックが、複数のストライプのそれぞれにあるかに基づくことができる。ランクは、複数のストライプのそれぞれにコミットするための、読込みおよび書込みのオーバヘッドに基づくことができる。耐障害性アドレス空間のそれぞれは、複数のコンピューティングデバイスのうちのただ１つによって、いつでも所有されてよく、複数の耐障害性アドレス空間のうちのそれぞれの１つは、その所有者によってのみ、読込みおよび書込みが行われてもよい。コンピューティングデバイスのそれぞれは、耐障害性アドレス空間の複数を所有することができる。複数のストレージデバイスは、複数の故障ドメインに編成されてもよい。複数のストライプのうちのそれぞれの１つが、複数の故障ドメインに及んでもよい。耐障害性アドレス空間のそれぞれは、複数の故障ドメインの全てに及んでもよく、これにより、複数の故障ドメインのうちの任意の特定の１つの故障時に、喪失データを再現するための作業負荷が、複数の故障ドメインの他のそれぞれの間に分散される。複数のストライプは、複数の故障ドメインのうちの２つの同時故障の場合、複数の故障ドメインの故障した２つに常駐する複数のストライプのうちの任意の特定の１つの２つのブロックの機会が、複数の故障ドメインの故障した２つに常駐する複数のストライプのうちの任意の特定の１つのただ１つのブロックの機会より指数関数的に小さくなるように、複数の故障ドメインにわたって分散されてもよい。

[0079]複数のコンピューティングデバイスは、２つの故障ブロックを有する複数のストライプのいずれかを最初に再現し、次に、ただ１つの故障ブロックを有する複数のストライプのいずれかを再現するように動作可能であってもよい。複数のコンピューティングデバイスは、ただ１つの故障ブロックを有する複数のストライプの再現の比率より（例えば、より大きい割合の再現専用のＣＰＵクロックサイクル、より大きい割合の再現専用のネットワーク伝送機会、および／または同様のものによる）高い比率で、２つの故障ブロックを有する複数のストライプの再現を実施するように動作可能であってもよい。複数のコンピューティングデバイスは、故障ドメインの１つまたは複数の故障の場合、複数のストライプのうちの同じ１つの他のブロックがどれだけ失われたかに基づいて、任意の特定の喪失ブロックが再現される比率を決定するように動作可能であってもよい。複数の故障ドメインの１つまたは複数は、複数のストレージデバイスを含む。複数のＦＥＣ保護ドメインのそれぞれは、複数のストライプのうちの複数のストライプに及んでもよい。

[0080]複数のストライプは、複数のグループ（例えば、図６におけるようなチャンクストライプ９２０_１～９２０_Ｓ）に編成されてもよく、ここで、複数のグループのそれぞれは、複数のストライプの１つまたは複数を含み、複数のコンピューティングデバイスは、グループのそれぞれについて、グループの複数のストライプの１つまたは複数にランクをつけるように動作可能である。複数のコンピューティングデバイスは、グループの複数のストライプの１つまたは複数が、決定された尺度をもはや満たさなくなるまで、複数のグ
ループのうちの選択された１つへの連続コミット動作を実施すること、および、複数のグループのうちの選択された１つが、決定された尺度をもはや満たさなくなると、複数のグループのうちの異なる１つを選択することを行うように動作可能であってもよい。尺度は、新しいデータが書き込まれるのに、どれだけのブロックが利用可能であるかに基づくことができる。

[0081]一定の実装形態を参照しつつ、本方法および／またはシステムが説明されてきたが、本方法および／またはシステムの範囲から逸脱することなく、様々な変更が行われてもよく、同等物が代用されてもよいということが当業者によって理解されよう。さらに、本開示の範囲から逸脱することなく、本開示の教示に、特定の状況または材料を適合させるために、多くの修正が行われてもよい。したがって、本方法および／またはシステムが、開示された特定の実装形態に限定されるのではなく、本方法および／またはシステムが、添付の特許請求の範囲に入る全ての実装形態を含むことになるということを意図するものである。

[0082]本明細書で利用されるように、用語「回路」および「回路機器」は、物理的な電子構成要素（すなわちハードウェア）、ならびに、ハードウェアを構成するか、ハードウェアによって実行されるか、またはそうでなければ、ハードウェアと関連付けられる可能性のある任意のソフトウェアおよび／またはファームウェア（「コード」）を指す。本明細書で使用されるように、例えば、特定のプロセッサおよびメモリは、コードの第１の１つまたは複数のラインを実行するときの第１の「回路機器」を備えることができ、コードの第２の１つまたは複数のラインを実行するときの第２の「回路機器」を備えることができる。本明細書で利用されるように、「および／または」は、リスト内の項目の任意の１つまたは複数が「および／または」によって結合されることを意味する。例として、「ｘおよび／またはｙ」は、３要素のセット｛（ｘ），（ｙ），（ｘ，ｙ）｝のうちのいずれかの要素を意味する。言い換えれば、「ｘおよび／またはｙ」は、「ｘおよびｙの１つまたは両方」を意味する。別の例として、「ｘ、ｙ、および／またはｚ」は、７要素のセット｛（ｘ），（ｙ），（ｚ），（ｘ，ｙ），（ｘ，ｚ），（ｙ，ｚ），（ｘ，ｙ，ｚ）｝のうちのいずれかの要素を意味する。言い換えれば、「ｘ、ｙ、および／またはｚ」は、「ｘ、ｙ、およびｚの１つまたは複数」を意味する。本明細書で利用されるように、用語「例示的な」は、非限定的な例、事例、または例証として機能することを意味する。本明細書で利用されるように、用語「例えば（ｅ．ｇ．，）」および「例えば（ｆｏｒｅｘａｍｐｌｅ）」は、１つまたは複数の非限定的な例、事例、または例証のリストを設定する。本明細書で利用されるように、回路機器は、（例えば、ユーザ構成可能設定、工場での調整（ｆａｃｔｏｒｙｔｒｉｍ）、等によって）機能の実施が無効にされるか、有効にされないかに関わらず、機能を実施するのに必要なハードウェアおよびコードを（いずれかが必要な場合）回路機器が備えるときはいつでも、機能を実施するように「動作可能」である。

Claims

第１のバックエンドおよび第１のストレージデバイスを備える第１の故障ドメインと、
バックエンドおよび第２のストレージデバイスを備える第２の故障ドメインであって、
前記第１のバックエンドが、複数のブロックを含む耐障害性ストライプを構築するように動作可能であり、
前記複数のブロックのうちの２つ以上のブロックが、エラー訂正情報を含み、
前記複数のブロックのうちの２つ以上のブロックが、前記第１のストレージデバイス内に置かれ、
前記複数のブロックのうちの２つ以上のブロックが、前記第２のストレージデバイス内に置かれ、
前記第１の故障ドメインが故障すると、前記第１のストレージデバイス内の前記複数のブロックのうちの前記２つ以上のブロックが、前記第２のストレージデバイス内の前記複数のブロックのうちの前記２つ以上のブロックに応じて再生成され、
前記第２の故障ドメインが故障すると、前記第２のストレージデバイス内の前記複数のブロックのうちの前記２つ以上のブロックが、前記第１のストレージデバイス内の前記複数のブロックのうちの前記２つ以上のブロックに応じて再生成される、
第２の故障ドメインと
を備える、システム。
前記第１の故障ドメインが、複数のソリッドステートドライブを備える、請求項１に記載のシステム。
前記第１の故障ドメインが、１つまたは複数のサーバを備える、請求項１に記載のシステム。
前記第１の故障ドメインが、ラックおよびネットワークスイッチを備える、請求項１に記載のシステム。
前記第１の故障ドメインおよび前記第２の故障ドメインが互いの通信を喪失した場合、第３の故障ドメインが、前記第１の故障ドメインと前記第２の故障ドメインとのどちらが、システムを動かし続けることになるかを判定するように動作可能である、請求項１に記載のシステム。
第３の故障ドメインによって許可が与えられない限り、前記第１の故障ドメインも前記第２の故障ドメインも前記耐障害性ストライプを再構築しない、請求項１に記載のシステム。
前記第１のバックエンドが、前記耐障害性ストライプを最初に構築するバケットを備える、請求項１に記載のシステム。
前記第１のバックエンドが、前記耐障害性ストライプのリーダであるバケットを備える、請求項１に記載のシステム。
前記第２のバックエンドが、前記第１の故障ドメインが故障した場合、前記耐障害性ストライプのリーダになるバケットを備える、請求項１に記載のシステム。
前記第１の故障ドメインが、可用性グループを備える、請求項１に記載のシステム。
第１の故障ドメインによって複数のデータピースを受け取るステップと、
前記複数のデータピースに応じて複数のエラー訂正ピースを生成するステップと、
前記第１の故障ドメインの第１のバックエンドを使用して、複数のブロックを含む耐障害性ストライプを構築するステップであって、前記複数のブロックの各ブロックが、前記複数のデータピースのうちの１つのデータピース、または前記複数のエラー訂正ピースのうちの１つのエラー訂正ピースを含む、ステップと、
前記複数のブロックのうちの第１の２つ以上のブロックを前記第１の故障ドメイン内に置くステップと、
前記複数のブロックのうちの第２の２つ以上のブロックを第２の故障ドメイン内に置くステップと、
前記第１の故障ドメインが故障した場合、前記第２の故障ドメイン内の前記第２の２つ以上のブロックに応じて、前記第１の故障ドメイン内の前記第１の２つ以上のブロックを再生成するステップと、
前記第２の故障ドメインが故障した場合、前記第１の故障ドメイン内の前記第１の２つ以上のブロックに応じて、前記第２の故障ドメイン内の前記第２の２つ以上のブロックを再生成するステップと
を含む、方法。
前記第１の故障ドメインが、複数のストレージデバイスを備える、請求項１１に記載の方法。
前記第１の故障ドメインが、１つまたは複数のサーバを備える、請求項１１に記載の方法。
前記第１の故障ドメインが、ラックおよびネットワークスイッチを備える、請求項１１に記載の方法。
前記第１の故障ドメインおよび前記第２の故障ドメインが互いの通信を喪失した場合、前記第１の故障ドメインと前記第２の故障ドメインとのどちらが、前記耐障害性ストライプを再構築することになるかを判定するステップを含む、請求項１１に記載の方法。
第３の故障ドメインによって許可が与えられない限り、前記第１の故障ドメインも前記第２の故障ドメインも前記耐障害性ストライプを再構築しない、請求項１１に記載の方法。
前記耐障害性ストライプが、前記第１のバックエンド内のバケットによって構築される、請求項１１に記載の方法。
前記第１のバックエンドのバケットが、前記耐障害性ストライプのリーダである、請求項１１に記載の方法。
前記第１の故障ドメインが故障した場合、前記耐障害性ストライプのリーダになるように前記第２の故障ドメインの第２のバックエンドのバケットを昇格させるステップを含む、請求項１１に記載の方法。
前記第１の故障ドメインが、可用性グループを備える、請求項１１に記載の方法。