(57)【要約】  フロントエンドおよびバックエンドを備えるコンピューティングデバイスが、複数のストレージデバイスに動作可能なように連結される。バックエンドは、複数のバケットを備える。各バケットは、複数のストレージデバイスの２つ以上に及ぶ障害保護されたストライプを構築するように動作可能である。フロントエンドは、データが複数のストレージデバイスに入ったときにデータを暗号化し、データが複数のストレージデバイスを離れるときにデータを復号するように動作可能である。【選択図】図１
2021527286.tif 000002
【特許請求の範囲】
【請求項１】
フロントエンドおよびバックエンドを備えるコンピューティングデバイスであって、前記フロントエンドが、データが前記システムに入るときに前記データを暗号化するように動作可能であり、前記バックエンドが、複数のバケットを備える、コンピューティングデバイスと、
複数のストレージデバイスであって、
前記複数のバケットの各バケットが、複数のストレージブロックを備える障害保護されたストライプを構築するように動作可能であり、
障害保護されたストライプの各ストレージブロックが、前記複数のストレージデバイスの異なるストレージデバイス内にあり、
前記暗号化されたデータが、１つまたは複数の障害保護されたストライプ内のファイルに記憶される、
複数のストレージデバイスと
を備える、システム。
【請求項２】
フロントエンドが、データが前記システムを離れるときに前記データを復号するように動作可能である、請求項１に記載のシステム。
【請求項３】
前記フロントエンドが、ファイル鍵に従って前記データを暗号化する、請求項１に記載のシステム。
【請求項４】
前記ファイル鍵が、前記ファイルがコピーされたときにローテーションされる、請求項３に記載のシステム。
【請求項５】
前記バックエンドにおいて前記複数のバケットによって構築された全ての障害保護されたストライプが、ファイルシステム鍵と関連付けられる、請求項３に記載のシステム。
【請求項６】
前記ファイル鍵が、前記ファイルシステム鍵で暗号化される、請求項５に記載のシステム。
【請求項７】
前記ファイル鍵が、前記ファイルシステム鍵がローテーションされたときに再暗号化される、請求項５に記載のシステム。
【請求項８】
前記コンピューティングデバイスが、コンピューティングデバイスのクラスタ内にあり、コンピューティングデバイスの前記クラスタが、クラスタ鍵と関連付けられる、請求項１に記載のシステム。
【請求項９】
前記コンピューティングデバイスが、コンピューティングデバイスの前記クラスタに前記コンピューティングデバイスが加わったときに、前記クラスタのリーダに長期鍵を登録する、請求項８に記載のシステム。
【請求項１０】
前記データの転送の前に、セッション鍵が、前記長期鍵で署名された一過性鍵ペアを使用して交渉される、請求項９に記載のシステム。
【請求項１１】
コンピューティングデバイス上のファイルシステムへの書込みアクセスのためにデータファイルを開くステップであって、
前記コンピューティングデバイスが、フロントエンド、バックエンド、および複数のストレージデバイスを備え
前記バックエンドが、複数のバケットを備え、
前記複数のバケットの各バケットが、複数のストレージブロックを備える障害保護されたストライプを構築するように動作可能であり、
障害保護されたストライプ内の前記複数のストレージブロックの各ストレージブロックが、前記複数のストレージデバイスの異なるストレージデバイス内にある、
ステップと、
前記フロントエンドにおいてデータを暗号化するステップと、
前記複数のバケットのうちの１つまたは複数のバケットによって構築された１つまたは複数の障害保護されたストライプ内の前記データファイルに前記暗号化されたデータを書き込むステップと、
前記データファイルを閉じるステップと
を含む、方法。
【請求項１２】
フロントエンドが、データが読み込まれたときに前記データを復号するように動作可能である、請求項１１に記載の方法。
【請求項１３】
前記フロントエンドが、ファイル鍵に従って前記データを暗号化し、
前記方法が、前記データファイルが閉じられた後、メモリから前記ファイル鍵を消去するステップを含む
請求項１１に記載の方法。
【請求項１４】
前記データファイルをコピーすることによって前記ファイル鍵をローテーションするステップを含む、請求項１３に記載の方法。
【請求項１５】
前記バックエンドにおいて前記複数のバケットによって構築された全ての障害保護されたストライプが、ファイルシステム鍵と関連付けられる、請求項１３に記載の方法。
【請求項１６】
前記ファイル鍵が、前記ファイルシステム鍵で暗号化される、請求項１５に記載の方法。
【請求項１７】
前記ファイルシステム鍵がローテーションされたときに前記ファイル鍵を再暗号化するステップを含む、請求項１５に記載の方法。
【請求項１８】
前記コンピューティングデバイスが、コンピューティングデバイスのクラスタ内にあり、コンピューティングデバイスの前記クラスタが、クラスタ鍵と関連付けられる、請求項１１に記載の方法。
【請求項１９】
コンピューティングデバイスの前記クラスタに前記コンピューティングデバイスが加わったときに、前記クラスタのリーダに前記コンピューティングデバイスの長期鍵を登録するステップを含む、請求項１８に記載の方法。
【請求項２０】
前記長期鍵で署名された一過性鍵ペアを使用してセッション鍵を交渉するステップと、
前記セッション鍵を使用して前記データを暗号化するステップと、
前記セッション鍵で暗号化された前記データを前記コンピューティングデバイスに転送するステップと
を含む、請求項１９に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
優先権の主張
[0001]本出願は、２０１８年６月８日に出願の「Ｅｎｃｒｙｐｔｉｏｎ  ｆｏｒ  ａ  Ｄｉｓｔｒｉｂｕｔｅｄ  Ｆｉｌｅｓｙｓｔｅｍ」と題する米国仮特許出願第６２／６８２，１９８号、および２０１９年２月１３日に出願の「Ｅｎｃｒｙｐｔｉｏｎ  ｆｏｒ  ａ  Ｄｉｓｔｒｉｂｕｔｅｄ  Ｆｉｌｅｓｙｓｔｅｍ」と題する米国特許出願第１６／２７４，５４１号の優先権を主張する。
【背景技術】
【０００２】
[0002]データストレージへの従来のアプローチの限界および短所は、図面を参照しながら本開示の以降で示される本方法およびシステムのいくつかの態様と、このようなアプローチとの比較を通じて、当業者には明らかになるであろう。
【０００３】
参照による組込み
[0003]「Ｄｉｓｔｒｉｂｕｔｅｄ  Ｅｒａｓｕｒｅ  Ｃｏｄｅｄ  Ｖｉｒｔｕａｌ  Ｆｉｌｅｓｙｓｔｅｍ」と題する米国特許出願第１５／２４３，５１９号が、本明細書によって全体として参照により本明細書に組み込まれる。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
[0004]特許請求の範囲でより完全に示されるように、図の少なくとも１つによって実質的に示されるような、および／または、図の少なくとも１つに関連して説明されるような、分散型ファイルシステムにおける暗号化のための方法およびシステムが提供される。
【図面の簡単な説明】
【０００５】
【図１】本開示の態様による分散型ファイルシステムの様々な実例の構成を示す図である。
【図２】本開示の態様による分散型ファイルシステムノードの実例の構成を示す図である。
【図３】本開示の実例の実装形態による分散型ファイルシステムの別の表現を示す図である。
【図４】本開示の１つまたは複数の実施形態による暗号化されたファイルシステムにおけるコンピューティングデバイスの例を示す図である。
【図５】本開示の１つまたは複数の実施形態によるコンピューティングデバイスのクラスタの例を示す図である。
【図６】暗号化されたファイルシステムにおけるクライアントから読み込むための実例の方法を示す流れ図である。
【図７】暗号化されたファイルシステムにおけるクライアントに書き込むための実例の方法を示す流れ図である。
【図８】２つの分散型耐障害性（ｆａｉｌｕｒｅ  ｒｅｓｉｌｉｅｎｔ）アドレス空間が複数のソリッドステートストレージディスク上に常駐する実例の実装形態を示す図である。
【図９】本開示の実例の実装形態による仮想ファイルシステムの不揮発性メモリに記憶されたデータを保護するために使用することができる前方誤り訂正方式を示す図である。
【発明を実施するための形態】
【０００６】
[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]各バケットは、バケットを動かすことができる計算ノードのグループを有することができる。例えば、５つのＶＦＳノードは、１つのバケットを動かすことができる。それでも、グループ内のノードのただ１つが、任意の与えられた瞬間におけるコントローラ／リーダである。さらに、２つのバケットは、十分大きいクラスタのために同じグループを共有しない。クラスタ内に５つまたは６つのノードしかない場合、ほとんどのバケットは、バックエンドを共有することができる。適度に大きいクラスタには、多くの別個のノードグループがある。例えば、２６個のノードで、
【数１】
2021527286.tif 000003
より多くの可能な５ノードグループ（すなわち、ペンタグループ）がある。
【００３１】
[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]本明細書で使用されるように、「故障ドメイン」は、構成要素のうちの任意のただ１つの故障（構成要素が電力を喪失すること、反応しなくなること、および／または同様のもの）が、構成要素全ての故障を生じる可能性がある構成要素のグループを指す。例えば、ラックが、単一のトップオブザラックスイッチを有する場合、このスイッチの故障が、このラック上の（例えば、計算、ストレージ、および／またはＶＦＳノードといった）構成要素全てへの接続をダウンさせることになる。したがって、残りのシステムに対して、これは、このラック上の構成要素全てが一緒に故障した場合に等しい。本開示による仮想ファイルシステムは、チャンク９１０より少ない故障ドメインを含むことができる。
【００７５】
[0083]仮想ファイルシステムのノードが、このようなノードあたり１つのストレージデバイス９０６しかないという完全に冗長な方式で接続され、電力供給される１つの実例の実装形態では、故障ドメインは、この単一のストレージデバイス９０６だけになる可能性がある。したがって、１つの実例の実装形態では、各チャンクストライプ９２０ｓは、ストレージデバイス９０６１〜９０６ＤのうちのＮ個のそれぞれに常駐する複数のチャンク９１０ｄ，ｃを含む（したがって、ＤはＮより大きいか、または等しい）。このような実装形態の例が図９に示される。
【００７６】
[0084]図８では、Ｄ＝７、Ｎ＝５、Ｍ＝４、Ｋ＝１であり、ストレージは、２つのＤＦＲＡＳに編成される。これらの数は例証にすぎず、限定することを意図するものではない。第１のＤＦＲＡＳの３つのチャンクストライプ９２０が、例証として任意にコールアウトされる。第１のチャンクストライプ９２０１は、チャンク９１０１，１、９１０２，２、９１０３，３、９１０４，５、および９１０５，６からなり、第２のチャンクストライプ９２０２は、チャンク９１０３，２、９１０４，３、９１０５，３、９１０６，２、および９１０７，３からなり、第３のチャンクストライプ９２０３は、チャンク９１０１，４、９１０２，４、９１０３，５、９１０５，７、および９１０７，５からなる。
【００７７】
[0085]図８の単純な例ではＤ＝７かつＮ＝５であるが、実際の実装形態では、Ｄは、（例えば、１より大きい整数の倍数による、および場合によっては、多くの桁数による）Ｎよりはるかに大きくてもよく、２つの値は、Ｎ個のストレージデバイス９０６の同じセットに（または、より一般には、Ｎ個の故障ドメインの同じセットに）常駐する単一のＤＦＲＡＳの任意の２つのチャンクストライプ９２０の確率が所望の閾値を下回るように選ばれてもよい。このように、任意の単一のストレージデバイス９０６ｄ（または、より一般には、任意の単一の故障ドメイン）の故障は、（ＤおよびＮの選ばれた値、Ｎ個のストレージデバイス９０６のサイズ、ならびに故障ドメインの配置に基づいて決定された所望の統計学的確率で）任意の特定のストライプ９２０ｓの多くても１つのチャンク９１０ｂ，ｃの喪失を生じることになる。さらに、２重の故障により、圧倒的多数のストライプが、多くても１つのチャンク９１０ｂ，ｃを喪失することになり、（ＤおよびＮの値に基づいて決定された）少数のストライプだけが、任意の特定のストライプ９２０ｓから２つのチャンクを喪失することになる（例えば、２つの故障ストライプの数は、１つの故障ストライプの数より指数関数的に小さくなる可能性がある）。
【００７８】
[0086]例えば、各ストレージデバイス９０６ｄが１ＴＢであり、各チャンクが１２８ＭＢである場合、ストレージデバイス９０６ｄの故障により、（ＤおよびＮの選ばれた値、Ｎ個のストレージデバイス９０６のサイズ、ならびに故障ドメインの配置に基づいて決定された所望の統計学的確率で）７８１２（＝１ＴＢ／１２８ＭＢ）個のチャンクストライプ９２０が１つのチャンク９１０を喪失することになる。それぞれのこのような影響を受けたチャンクストライプ９２０ｓについて、喪失チャンク９１０ｄ，ｃは、適切な前方誤り訂正アルゴリズム、およびチャンクストライプ９２０ｓの他のＮ−１個のチャンクを使用して、素早く再現されることが可能である。さらに、影響を受けた７８１２個のチャンクストライプが、ストレージデバイス９０６１〜９０６Ｄの全てにわたって一様に分散されるので、喪失した７８１２個のブロック９１０ｄ，ｃを再現することは、（ＤおよびＮの選ばれた値、Ｎ個のストレージデバイス９０６のサイズ、ならびに故障ドメインの配置に基づいて決定された所望の統計学的確率で）ストレージデバイス９０６１〜９０６Ｄのそれぞれから同じ量のデータを読み込むことを伴うことになる（すなわち、喪失データを再現する負担は、故障からの非常に素早い回復をもたらすように、ストレージデバイス９０６１〜９０６Ｄの全てにわたって一様に分散される）。
【００７９】
[0087]次に、ストレージデバイス９０６１〜９０６Ｄのうちの２つの同時故障（または、より一般には、２つの故障ドメインの同時故障）のケースに移ると、ストレージデバイス９０６１〜９０６Ｄの全てにわたる各ＤＦＲＡＳのチャンクストライプ９２０１〜９２０Ｓの一様な分散により、非常に少数のチャンクストライプ９２０１〜９２０Ｓだけが、これらのＮ個のチャンクのうちの２つを喪失していることになる。仮想ファイルシステムは、チャンクストライプ９２０１〜９２０Ｓとストレージデバイス９０６１〜９０６Ｄとの間のマッピングを示すメタデータに基づいて、このような２つの喪失チャンクストライプを素早く識別するように動作可能であってもよい。このような２つの喪失チャンクストライプが識別されると、仮想ファイルシステムは、１つの喪失チャンクストライプの再現を始める前に、これらの２つの喪失チャンクストライプの再現を優先させることができる。残りのチャンクストライプは、単一の喪失チャンクだけを有することになり、これら（影響を受けたチャンクストライプの大半）について、２つのストレージデバイス９０６ｄの同時故障は、ただ１つのストレージデバイス９０６ｄの故障と同じである。類似の原理は、第３の同時故障などに適用される（３つの故障ブロックを有するチャンクストライプの数は、２つの同時故障シナリオにおける２つの故障ブロックを有する数よりむしろ小さくなる）。１つの実例の実装形態では、チャンクストライプ９２０ｓの再現が実施される比率は、チャンクストライプ９２０ｓ内の喪失の数に基づいて制御されてもよい。これは、例えば、再現のための読込みおよびコミットが実施される比率、再現のためのＦＥＣ計算が実施される比率、再現のためのネットワークメッセージが通信される比率、等を制御することによって達成されてもよい。
【００８０】
[0088]図９は、本開示の実例の実装形態による仮想ファイルシステムの不揮発性メモリに記憶されたデータを保護するために使用されることが可能な前方誤り訂正方式を示す。ＤＦＲＡＳのブロックストライプ９３０１〜９３０４のストレージブロック９０２１，１〜９０２７，７が示される。図９の保護方式では、各ストライプの５つのブロックが、データディジットのストレージのためのものであり、各ストライプの２つのブロックが、保護ディジットのデータストレージのためのものである（すなわち、Ｍ＝５かつＫ＝２である）。図９では、以下の方程式（１）〜（９）を使用して、保護ディジットが計算される。
【数２】
2021527286.tif 000004
【００８１】
[0089]したがって、図９における４つのストライプ９３０１〜９３０４は、マルチストライプ（この場合、４つのストライプ）ＦＥＣ保護ドメインの一部であり、ブロックストライプ９３０１〜９３０４のいずれかにおける任意の２つ以下のブロックの喪失は、上記の方程式（１）〜（９）の様々な組合せを使用することによって回復されることが可能である。比較として、単一のストライプ保護ドメインの例は、Ｄ１１、Ｄ２２、Ｄ３３、Ｄ４４、Ｄ５４がＰ１によってのみ保護され、Ｄ１１、Ｄ２２、Ｄ３３、Ｄ４４、Ｄ５４、およびＰ１が、ストライプ９３０１に全て書き込まれる場合である（９３０１は、単一のストライプＦＥＣ保護ドメインである）。
【００８２】
[0090]本開示の実例の実装形態によれば、複数のコンピューティングデバイスは、ネットワークを介して互いに通信連結され、複数のコンピューティングデバイスのそれぞれは、複数のストレージデバイスの１つまたは複数を備える。複数の耐障害性アドレス空間は、複数の耐障害性アドレス空間のそれぞれが複数のストレージデバイスに及ぶように、複数のストレージデバイスにわたって分散される。複数の耐障害性アドレス空間のうちのそれぞれの１つは、複数のストライプ（例えば、図８および図９におけるような複数の９３０）に編成される。複数のストライプのそれぞれの１つまたは複数のストライプは、複数の前方誤り訂正（ＦＥＣ）保護ドメイン（例えば、図８などにおけるマルチストライプＦＥＣドメイン）のうちのそれぞれの１つの一部である。複数のストライプのそれぞれは、複数のストレージブロック（例えば、複数の９１２）を含むことができる。複数のストライプのうちの特定の１つの各ブロックは、複数のストレージデバイスのうちの異なる１つに常駐することができる。複数のストレージブロックの第１の部分（例えば、図９のストライプ９３０１の９０２１，２〜９０２１，６からなる５つの量）は、データディジットの記憶のためのものであってもよく、複数のストレージブロックの第２の部分（例えば、図９のストライプ９３０１の９０２１，１および９０２１，７の２つの量）は、データディジットに少なくとも部分的に基づいて計算された保護ディジットの記憶のためのものであってもよい。
【００８３】
[0091]複数のコンピューティングデバイスは、複数のストライプにランクをつけるように動作可能であってもよい。ランクは、複数の耐障害性アドレス空間のうちの１つへの次のコミット動作のために、複数のストライプのどれを使用するべきかを選択するために使用されてもよい。ランクは、保護されたおよび／または保護されていないストレージブロックが、どれだけ複数のストライプのそれぞれにあるかに基づくことができる。複数のストライプのうちの任意の特定の１つについて、ランクは、複数のストライプのうちの特定の１つを有する複数のストレージデバイス上に記憶されたビットマップに基づくことができる。ランクは、データを現在記憶しているどれだけのブロックが、複数のストライプのそれぞれにあるかに基づくことができる。ランクは、複数のストライプのそれぞれにコミットするための、読込みおよび書込みのオーバヘッドに基づくことができる。耐障害性アドレス空間のそれぞれは、複数のコンピューティングデバイスのうちのただ１つによって、いつでも所有されてよく、複数の耐障害性アドレス空間のうちのそれぞれの１つは、その所有者によってのみ、読込みおよび書込みが行われてもよい。コンピューティングデバイスのそれぞれは、耐障害性アドレス空間の複数を所有することができる。複数のストレージデバイスは、複数の故障ドメインに編成されてもよい。複数のストライプのうちのそれぞれの１つが、複数の故障ドメインに及んでもよい。耐障害性アドレス空間のそれぞれは、複数の故障ドメインの全てに及んでもよく、これにより、複数の故障ドメインのうちの任意の特定の１つの故障時に、喪失データを再現するための作業負荷が、複数の故障ドメインの他のそれぞれの間に分散される。複数のストライプは、複数の故障ドメインのうちの２つの同時故障の場合、複数の故障ドメインの故障した２つに常駐する複数のストライプのうちの任意の特定の１つの２つのブロックの機会が、複数の故障ドメインの故障した２つに常駐する複数のストライプのうちの任意の特定の１つのただ１つのブロックの機会より指数関数的に小さくなるように、複数の故障ドメインにわたって分散されてもよい。
【００８４】
[0092]複数のコンピューティングデバイスは、２つの故障ブロックを有する複数のストライプのいずれかを最初に再現し、次に、ただ１つの故障ブロックを有する複数のストライプのいずれかを再現するように動作可能であってもよい。複数のコンピューティングデバイスは、ただ１つの故障ブロックを有する複数のストライプの再現の比率より（例えば、より大きい割合の再現専用のＣＰＵクロックサイクル、より大きい割合の再現専用のネットワーク伝送機会、および／または同様のものによる）高い比率で、２つの故障ブロックを有する複数のストライプの再現を実施するように動作可能であってもよい。複数のコンピューティングデバイスは、故障ドメインの１つまたは複数の故障の場合、複数のストライプのうちの同じ１つの他のブロックがどれだけ失われたかに基づいて、任意の特定の喪失ブロックが再現される比率を決定するように動作可能であってもよい。複数の故障ドメインの１つまたは複数は、複数のストレージデバイスを含む。複数のＦＥＣ保護ドメインのそれぞれは、複数のストライプのうちの複数のストライプに及んでもよい。
【００８５】
[0093]複数のストライプは、複数のグループ（例えば、図８におけるようなチャンクストライプ９２０１〜９２０Ｓ）に編成されてもよく、ここで、複数のグループのそれぞれは、複数のストライプの１つまたは複数を含み、複数のコンピューティングデバイスは、グループのそれぞれについて、グループの複数のストライプの１つまたは複数にランクをつけるように動作可能である。複数のコンピューティングデバイスは、グループの複数のストライプの１つまたは複数が、決定された尺度をもはや満たさなくなるまで、複数のグループのうちの選択された１つへの連続コミット動作を実施すること、および、複数のグループのうちの選択された１つが、決定された尺度をもはや満たさなくなると、複数のグループのうちの異なる１つを選択することを行うように動作可能であってもよい。尺度は、新しいデータが書き込まれるのに、どれだけのブロックが利用可能であるかに基づくことができる。
【００８６】
[0094]一定の実装形態を参照しつつ、本方法および／またはシステムが説明されてきたが、本方法および／またはシステムの範囲から逸脱することなく、様々な変更が行われてもよく、同等物が代用されてもよいということが当業者によって理解されよう。さらに、本開示の範囲から逸脱することなく、本開示の教示に、特定の状況または材料を適合させるために、多くの修正が行われてもよい。したがって、本方法および／またはシステムが、開示された特定の実装形態に限定されるのではなく、本方法および／またはシステムが、添付の特許請求の範囲に入る全ての実装形態を含むことになるということを意図するものである。
【００８７】
[0095]本明細書で利用されるように、用語「回路」および「回路機器」は、物理的な電子構成要素（すなわちハードウェア）、ならびに、ハードウェアを構成するか、ハードウェアによって実行されるか、またはそうでなければ、ハードウェアと関連付けられる可能性のある任意のソフトウェアおよび／またはファームウェア（「コード」）を指す。本明細書で使用されるように、例えば、特定のプロセッサおよびメモリは、コードの第１の１つまたは複数のラインを実行するときの第１の「回路機器」を備えることができ、コードの第２の１つまたは複数のラインを実行するときの第２の「回路機器」を備えることができる。本明細書で利用されるように、「および／または」は、リスト内の項目の任意の１つまたは複数が「および／または」によって結合されることを意味する。例として、「ｘおよび／またはｙ」は、３要素のセット｛（ｘ），（ｙ），（ｘ，ｙ）｝のうちのいずれかの要素を意味する。言い換えれば、「ｘおよび／またはｙ」は、「ｘおよびｙの１つまたは両方」を意味する。別の例として、「ｘ、ｙ、および／またはｚ」は、７要素のセット｛（ｘ），（ｙ），（ｚ），（ｘ，ｙ），（ｘ，ｚ），（ｙ，ｚ），（ｘ，ｙ，ｚ）｝のうちのいずれかの要素を意味する。言い換えれば、「ｘ、ｙ、および／またはｚ」は、「ｘ、ｙ、およびｚの１つまたは複数」を意味する。本明細書で利用されるように、用語「例示的な」は、非限定的な例、事例、または例証として機能することを意味する。本明細書で利用されるように、用語「例えば（ｅ．ｇ．，）」および「例えば（ｆｏｒ  ｅｘａｍｐｌｅ）」は、１つまたは複数の非限定的な例、事例、または例証のリストを設定する。本明細書で利用されるように、回路機器は、（例えば、ユーザ構成可能設定、工場での調整（ｆａｃｔｏｒｙ  ｔｒｉｍ）、等によって）機能の実施が無効にされるか、有効にされないかに関わらず、機能を実施するのに必要なハードウェアおよびコードを（いずれかが必要な場合）回路機器が備えるときはいつでも、機能を実施するように「動作可能」である。
【図１】
2021527286.tif 000005
【図２】
2021527286.tif 000006
【図３】
2021527286.tif 000007
【図４】
2021527286.tif 000008
【図５】
2021527286.tif 000009
【図６】
2021527286.tif 000010
【図７】
2021527286.tif 000011
【図８】
2021527286.tif 000012
【図９】
2021527286.tif 000013
【国際調査報告】
2021527286.tif 000014