JP7238111B2 - 分散型ファイルシステムのための暗号化 - Google Patents

分散型ファイルシステムのための暗号化 Download PDF

Info

Publication number
JP7238111B2
JP7238111B2 JP2021517925A JP2021517925A JP7238111B2 JP 7238111 B2 JP7238111 B2 JP 7238111B2 JP 2021517925 A JP2021517925 A JP 2021517925A JP 2021517925 A JP2021517925 A JP 2021517925A JP 7238111 B2 JP7238111 B2 JP 7238111B2
Authority
JP
Japan
Prior art keywords
key
file
data
cluster
file system
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2021517925A
Other languages
English (en)
Other versions
JP2021527286A (ja
Inventor
ダヤン，マオール ベン
パルモン，オムリ
ズビベル，リラン
アルディッティ，カナエル
ペレグ，オリ
Original Assignee
ウェカ．アイオー リミテッド
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by ウェカ．アイオー リミテッド filed Critical ウェカ．アイオー リミテッド
Publication of JP2021527286A publication Critical patent/JP2021527286A/ja
Priority to JP2023031014A priority Critical patent/JP2023071843A/ja
Application granted granted Critical
Publication of JP7238111B2 publication Critical patent/JP7238111B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/08—Error detection or correction by redundancy in data representation, e.g. by using checking codes
    • G06F11/10—Adding special bits or symbols to the coded information, e.g. parity check, casting out 9's or 11's
    • G06F11/1076—Parity data used in redundant arrays of independent storages, e.g. in RAID systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/18—File system types
    • G06F16/182—Distributed file systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/602—Providing cryptographic facilities or services
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/065—Encryption by serially and continuously modifying data stream elements, e.g. stream cipher systems, RC4, SEAL or A5/3
    • H04L9/0656—Pseudorandom key sequence combined element-for-element with data sequence, e.g. one-time-pad [OTP] or Vernam's cipher
    • H04L9/0662—Pseudorandom key sequence combined element-for-element with data sequence, e.g. one-time-pad [OTP] or Vernam's cipher with particular pseudorandom sequence generator
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H04L9/0841—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/088—Usage controlling of secret information, e.g. techniques for restricting cryptographic keys to pre-authorized uses, different access levels, validity of crypto-period, different key- or password length, or different strong and weak cryptographic algorithms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0891—Revocation or update of secret information, e.g. encryption key update or rekeying
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1448—Management of the data involved in backup or backup restore
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2041—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant with more than one idle spare processing component
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2048—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant where the redundant components share neither address space nor persistent storage
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/2097—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements maintaining the standby controller/processing unit updated
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/815—Virtual
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/84—Using snapshots, i.e. a logical point-in-time copy of the data

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Databases & Information Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • Software Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Computing Systems (AREA)
  • Quality & Reliability (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Storage Device Security (AREA)

Description

優先権の主張
[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]各バケットは、バケットを動かすことができる計算ノードのグループを有することができる。例えば、５つのＶＦＳノードは、１つのバケットを動かすことができる。それでも、グループ内のノードのただ１つが、任意の与えられた瞬間におけるコントローラ／リーダである。さらに、２つのバケットは、十分大きいクラスタのために同じグループを共有しない。クラスタ内に５つまたは６つのノードしかない場合、ほとんどのバケットは、バックエンドを共有することができる。適度に大きいクラスタには、多くの別個のノードグループがある。例えば、２６個のノードで、
Figure 0007238111000001
 より多くの可能な５ノードグループ（すなわち、ペンタグループ）がある。
[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]図９は、本開示の実例の実装形態による仮想ファイルシステムの不揮発性メモリに記憶されたデータを保護するために使用されることが可能な前方誤り訂正方式を示す。ＤＦＲＡＳのブロックストライプ９３０１～９３０４のストレージブロック９０２１，１～９０２７，７が示される。図９の保護方式では、各ストライプの５つのブロックが、データディジットのストレージのためのものであり、各ストライプの２つのブロックが、保護ディジットのデータストレージのためのものである（すなわち、Ｍ＝５かつＫ＝２である）。図９では、以下の方程式（１）～（９）を使用して、保護ディジットが計算される。
Figure 0007238111000002
[0089]したがって、図９における４つのストライプ９３０１～９３０４は、マルチストライプ（この場合、４つのストライプ）ＦＥＣ保護ドメインの一部であり、ブロックストライプ９３０１～９３０４のいずれかにおける任意の２つ以下のブロックの喪失は、上記の方程式（１）～（９）の様々な組合せを使用することによって回復されることが可能である。比較として、単一のストライプ保護ドメインの例は、Ｄ１１、Ｄ２２、Ｄ３３、Ｄ４４、Ｄ５４がＰ１によってのみ保護され、Ｄ１１、Ｄ２２、Ｄ３３、Ｄ４４、Ｄ５４、およびＰ１が、ストライプ９３０１に全て書き込まれる場合である（９３０１は、単一のストライプＦＥＣ保護ドメインである）。
[0090]本開示の実例の実装形態によれば、複数のコンピューティングデバイスは、ネットワークを介して互いに通信連結され、複数のコンピューティングデバイスのそれぞれは、複数のストレージデバイスの１つまたは複数を備える。複数の耐障害性アドレス空間は、複数の耐障害性アドレス空間のそれぞれが複数のストレージデバイスに及ぶように、複数のストレージデバイスにわたって分散される。複数の耐障害性アドレス空間のうちのそれぞれの１つは、複数のストライプ（例えば、図８および図９におけるような複数の９３０）に編成される。複数のストライプのそれぞれの１つまたは複数のストライプは、複数の前方誤り訂正（ＦＥＣ）保護ドメイン（例えば、図８などにおけるマルチストライプＦＥＣドメイン）のうちのそれぞれの１つの一部である。複数のストライプのそれぞれは、複数のストレージブロック（例えば、複数の９１２）を含むことができる。複数のストライプのうちの特定の１つの各ブロックは、複数のストレージデバイスのうちの異なる１つに常駐することができる。複数のストレージブロックの第１の部分（例えば、図９のストライプ９３０１の９０２１，２～９０２１，６からなる５つの量）は、データディジットの記憶のためのものであってもよく、複数のストレージブロックの第２の部分（例えば、図９のストライプ９３０１の９０２１，１および９０２１，７の２つの量）は、データディジットに少なくとも部分的に基づいて計算された保護ディジットの記憶のためのものであってもよい。
[0091]複数のコンピューティングデバイスは、複数のストライプにランクをつけるように動作可能であってもよい。ランクは、複数の耐障害性アドレス空間のうちの１つへの次のコミット動作のために、複数のストライプのどれを使用するべきかを選択するために使用されてもよい。ランクは、保護されたおよび／または保護されていないストレージブロックが、どれだけ複数のストライプのそれぞれにあるかに基づくことができる。複数のストライプのうちの任意の特定の１つについて、ランクは、複数のストライプのうちの特定の１つを有する複数のストレージデバイス上に記憶されたビットマップに基づくことができる。ランクは、データを現在記憶しているどれだけのブロックが、複数のストライプのそれぞれにあるかに基づくことができる。ランクは、複数のストライプのそれぞれにコミットするための、読込みおよび書込みのオーバヘッドに基づくことができる。耐障害性アドレス空間のそれぞれは、複数のコンピューティングデバイスのうちのただ１つによって、いつでも所有されてよく、複数の耐障害性アドレス空間のうちのそれぞれの１つは、その所有者によってのみ、読込みおよび書込みが行われてもよい。コンピューティングデバイスのそれぞれは、耐障害性アドレス空間の複数を所有することができる。複数のストレージデバイスは、複数の故障ドメインに編成されてもよい。複数のストライプのうちのそれぞれの１つが、複数の故障ドメインに及んでもよい。耐障害性アドレス空間のそれぞれは、複数の故障ドメインの全てに及んでもよく、これにより、複数の故障ドメインのうちの任意の特定の１つの故障時に、喪失データを再現するための作業負荷が、複数の故障ドメインの他のそれぞれの間に分散される。複数のストライプは、複数の故障ドメインのうちの２つの同時故障の場合、複数の故障ドメインの故障した２つに常駐する複数のストライプのうちの任意の特定の１つの２つのブロックの機会が、複数の故障ドメインの故障した２つに常駐する複数のストライプのうちの任意の特定の１つのただ１つのブロックの機会より指数関数的に小さくなるように、複数の故障ドメインにわたって分散されてもよい。
[0092]複数のコンピューティングデバイスは、２つの故障ブロックを有する複数のストライプのいずれかを最初に再現し、次に、ただ１つの故障ブロックを有する複数のストライプのいずれかを再現するように動作可能であってもよい。複数のコンピューティングデバイスは、ただ１つの故障ブロックを有する複数のストライプの再現の比率より（例えば、より大きい割合の再現専用のＣＰＵクロックサイクル、より大きい割合の再現専用のネットワーク伝送機会、および／または同様のものによる）高い比率で、２つの故障ブロックを有する複数のストライプの再現を実施するように動作可能であってもよい。複数のコンピューティングデバイスは、故障ドメインの１つまたは複数の故障の場合、複数のストライプのうちの同じ１つの他のブロックがどれだけ失われたかに基づいて、任意の特定の喪失ブロックが再現される比率を決定するように動作可能であってもよい。複数の故障ドメインの１つまたは複数は、複数のストレージデバイスを含む。複数のＦＥＣ保護ドメインのそれぞれは、複数のストライプのうちの複数のストライプに及んでもよい。
[0093]複数のストライプは、複数のグループ（例えば、図８におけるようなチャンクストライプ９２０１～９２０Ｓ）に編成されてもよく、ここで、複数のグループのそれぞれは、複数のストライプの１つまたは複数を含み、複数のコンピューティングデバイスは、グループのそれぞれについて、グループの複数のストライプの１つまたは複数にランクをつけるように動作可能である。複数のコンピューティングデバイスは、グループの複数のストライプの１つまたは複数が、決定された尺度をもはや満たさなくなるまで、複数のグループのうちの選択された１つへの連続コミット動作を実施すること、および、複数のグループのうちの選択された１つが、決定された尺度をもはや満たさなくなると、複数のグループのうちの異なる１つを選択することを行うように動作可能であってもよい。尺度は、新しいデータが書き込まれるのに、どれだけのブロックが利用可能であるかに基づくことができる。
[0094]一定の実装形態を参照しつつ、本方法および／またはシステムが説明されてきたが、本方法および／またはシステムの範囲から逸脱することなく、様々な変更が行われてもよく、同等物が代用されてもよいということが当業者によって理解されよう。さらに、本開示の範囲から逸脱することなく、本開示の教示に、特定の状況または材料を適合させるために、多くの修正が行われてもよい。したがって、本方法および／またはシステムが、開示された特定の実装形態に限定されるのではなく、本方法および／またはシステムが、添付の特許請求の範囲に入る全ての実装形態を含むことになるということを意図するものである。
[0095]本明細書で利用されるように、用語「回路」および「回路機器」は、物理的な電子構成要素（すなわちハードウェア）、ならびに、ハードウェアを構成するか、ハードウェアによって実行されるか、またはそうでなければ、ハードウェアと関連付けられる可能性のある任意のソフトウェアおよび／またはファームウェア（「コード」）を指す。本明細書で使用されるように、例えば、特定のプロセッサおよびメモリは、コードの第１の１つまたは複数のラインを実行するときの第１の「回路機器」を備えることができ、コードの第２の１つまたは複数のラインを実行するときの第２の「回路機器」を備えることができる。本明細書で利用されるように、「および／または」は、リスト内の項目の任意の１つまたは複数が「および／または」によって結合されることを意味する。例として、「ｘおよび／またはｙ」は、３要素のセット｛（ｘ），（ｙ），（ｘ，ｙ）｝のうちのいずれかの要素を意味する。言い換えれば、「ｘおよび／またはｙ」は、「ｘおよびｙの１つまたは両方」を意味する。別の例として、「ｘ、ｙ、および／またはｚ」は、７要素のセット｛（ｘ），（ｙ），（ｚ），（ｘ，ｙ），（ｘ，ｚ），（ｙ，ｚ），（ｘ，ｙ，ｚ）｝のうちのいずれかの要素を意味する。言い換えれば、「ｘ、ｙ、および／またはｚ」は、「ｘ、ｙ、およびｚの１つまたは複数」を意味する。本明細書で利用されるように、用語「例示的な」は、非限定的な例、事例、または例証として機能することを意味する。本明細書で利用されるように、用語「例えば（ｅ．ｇ．，）」および「例えば（ｆｏｒ ｅｘａｍｐｌｅ）」は、１つまたは複数の非限定的な例、事例、または例証のリストを設定する。本明細書で利用されるように、回路機器は、（例えば、ユーザ構成可能設定、工場での調整（ｆａｃｔｏｒｙ ｔｒｉｍ）、等によって）機能の実施が無効にされるか、有効にされないかに関わらず、機能を実施するのに必要なハードウェアおよびコードを（いずれかが必要な場合）回路機器が備えるときはいつでも、機能を実施するように「動作可能」である。

Claims (18)

  1. フロントエンドおよびバックエンドを備えるコンピューティングデバイスであって、前記フロントエンドが、データがシステムに入るときに前記データを暗号化するように動作可能であり、前記バックエンドが、複数のバケットを備える、コンピューティングデバイスと、
    複数のストレージデバイスであって、
    前記複数のバケットの各バケットが、複数のストレージブロックを備える障害保護されたストライプを構築するように動作可能であり、
    障害保護されたストライプの各ストレージブロックが、前記複数のストレージデバイスの異なるストレージデバイス内にあり、
    前記暗号化されたデータが、１つまたは複数の障害保護されたストライプ内のファイルに記憶される、
    複数のストレージデバイスと
    を備え、
    前記コンピューティングデバイスが、複数のコンピューティングデバイスのクラスタ内にあり、
    前記複数のコンピューティングデバイスの前記クラスタに前記コンピューティングデバイスが加わったときに、前記コンピューティングデバイスが、前記クラスタのリーダに長期鍵を登録する、システム。
  2. 前記フロントエンドが、データが前記システムを離れるときに前記データを復号するように動作可能である、請求項１に記載のシステム。
  3. 前記フロントエンドが、ファイル鍵に従って前記データを暗号化する、請求項１に記載のシステム。
  4. 前記ファイル鍵が、前記ファイルがコピーされたときにローテーションされる、請求項３に記載のシステム。
  5. 前記バックエンドにおいて前記複数のバケットによって構築された全ての障害保護されたストライプが、ファイルシステム鍵と関連付けられた共通のファイルシステム内にある、請求項３に記載のシステム。
  6. 前記ファイル鍵が、前記ファイルシステム鍵で暗号化される、請求項５に記載のシステム。
  7. 前記ファイル鍵が、前記ファイルシステム鍵がローテーションされたときに再暗号化される、請求項５に記載のシステム。
  8. 前記複数のコンピューティングデバイスの前記クラスタが、クラスタ鍵と関連付けられており、前記ファイルシステム鍵が、前記クラスタ鍵により暗号化される、請求項５から７のいずれか１項に記載のシステム。
  9. 前記データの転送の前に、セッション鍵が、前記長期鍵で署名された一過性鍵ペアを使用して交渉される、請求項１に記載のシステム。
  10. コンピューティングデバイス上のファイルシステムへの書込みアクセスのためにデータファイルを開くステップであって、
    前記コンピューティングデバイスが、フロントエンド、バックエンド、および複数のストレージデバイスを備え
    前記バックエンドが、複数のバケットを備え、
    前記複数のバケットの各バケットが、複数のストレージブロックを備える障害保護されたストライプを構築するように動作可能であり、
    障害保護されたストライプ内の前記複数のストレージブロックの各ストレージブロックが、前記複数のストレージデバイスの異なるストレージデバイス内にある、
    ステップと、
    前記フロントエンドがデータを暗号化するステップと、
    前記複数のバケットのうちの１つまたは複数のバケットによって構築された１つまたは複数の障害保護されたストライプ内の前記データファイルに前記暗号化されたデータを書き込むステップと、
    前記データファイルを閉じるステップと
    を含み、
    前記コンピューティングデバイスが、複数のコンピューティングデバイスのクラスタ内にあり、
    前記複数のコンピューティングデバイスの前記クラスタに前記コンピューティングデバイスが加わったときに、前記クラスタのリーダに前記コンピューティングデバイスの長期鍵を登録するステップを含む、前記コンピューティングデバイスのプロセッサにより実行される方法。
  11. 前記フロントエンドが、データが読み込まれたときに前記データを復号するように動作可能である、請求項１０に記載の方法。
  12. ファイル鍵に従って、前記フロントエンドが前記データを暗号化し、
    前記方法が、前記データファイルが閉じられた後、メモリから前記ファイル鍵を消去するステップを含む
    請求項１０に記載の方法。
  13. 前記データファイルをコピーすることによって前記ファイル鍵をローテーションするステップを含む、請求項１２に記載の方法。
  14. 前記バックエンドにおいて前記複数のバケットによって構築された全ての障害保護されたストライプが、ファイルシステム鍵と関連付けられた共通のファイルシステム内にある、請求項１２に記載の方法。
  15. 前記ファイル鍵が保存されることになる場合、前記ファイル鍵は前記フロントエンドによって前記ファイルシステム鍵で暗号化される、請求項１４に記載の方法。
  16. 前記ファイルシステム鍵がローテーションされたときに前記フロントエンドが前記ファイル鍵を再暗号化するステップを含む、請求項１４に記載の方法。
  17. 前記複数のコンピューティングデバイスの前記クラスタが、クラスタ鍵と関連付けられており、前記ファイルシステム鍵が、前記クラスタ鍵により暗号化される、請求項１４から１６のいずれか１項に記載の方法。
  18. 前記長期鍵で署名された一過性鍵ペアを使用してセッション鍵を交渉するステップと、
    前記フロントエンドが前記セッション鍵を使用して前記データを暗号化するステップと、
    前記セッション鍵で暗号化された前記データを前記コンピューティングデバイスに転送するステップと
    を含む、請求項１０に記載の方法。
JP2021517925A 2018-06-08 2019-06-04 分散型ファイルシステムのための暗号化 Active JP7238111B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2023031014A JP2023071843A (ja) 2018-06-08 2023-03-01 分散型ファイルシステムのための暗号化

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201862682198P 2018-06-08 2018-06-08
US62/682,198 2018-06-08
US16/274,541 2019-02-13
US16/274,541 US11042661B2 (en) 2018-06-08 2019-02-13 Encryption for a distributed filesystem
PCT/IB2019/000686 WO2019234501A2 (en) 2018-06-08 2019-06-04 Encryption for a distributed filesystem

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2023031014A Division JP2023071843A (ja) 2018-06-08 2023-03-01 分散型ファイルシステムのための暗号化

Publications (2)

Publication Number Publication Date
JP2021527286A JP2021527286A (ja) 2021-10-11
JP7238111B2 true JP7238111B2 (ja) 2023-03-13

Family

ID=68765123

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2021517925A Active JP7238111B2 (ja) 2018-06-08 2019-06-04 分散型ファイルシステムのための暗号化
JP2023031014A Pending JP2023071843A (ja) 2018-06-08 2023-03-01 分散型ファイルシステムのための暗号化

Family Applications After (1)

Application Number Title Priority Date Filing Date
JP2023031014A Pending JP2023071843A (ja) 2018-06-08 2023-03-01 分散型ファイルシステムのための暗号化

Country Status (5)

Country Link
US (3) US11042661B2 (ja)
EP (1) EP3814945A4 (ja)
JP (2) JP7238111B2 (ja)
CN (1) CN112243508A (ja)
WO (1) WO2019234501A2 (ja)

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11042661B2 (en) * 2018-06-08 2021-06-22 Weka.IO Ltd. Encryption for a distributed filesystem
US11409696B2 (en) 2019-11-01 2022-08-09 EMC IP Holding Company LLC Methods and systems for utilizing a unified namespace
US11392464B2 (en) 2019-11-01 2022-07-19 EMC IP Holding Company LLC Methods and systems for mirroring and failover of nodes
US11741056B2 (en) 2019-11-01 2023-08-29 EMC IP Holding Company LLC Methods and systems for allocating free space in a sparse file system
US11604610B2 (en) * 2021-04-29 2023-03-14 EMC IP Holding Company LLC Methods and systems for storing data in a distributed system using offload components
US11740822B2 (en) 2021-04-29 2023-08-29 EMC IP Holding Company LLC Methods and systems for error detection and correction in a distributed storage system
US11892983B2 (en) 2021-04-29 2024-02-06 EMC IP Holding Company LLC Methods and systems for seamless tiering in a distributed storage system
US11567704B2 (en) 2021-04-29 2023-01-31 EMC IP Holding Company LLC Method and systems for storing data in a storage pool using memory semantics with applications interacting with emulated block devices
US20220350933A1 (en) * 2021-04-29 2022-11-03 EMC IP Holding Company LLC Methods and systems for securing data in a distributed storage system
US11669259B2 (en) 2021-04-29 2023-06-06 EMC IP Holding Company LLC Methods and systems for methods and systems for in-line deduplication in a distributed storage system
US11579976B2 (en) 2021-04-29 2023-02-14 EMC IP Holding Company LLC Methods and systems parallel raid rebuild in a distributed storage system
CN113742289B (zh) * 2021-09-02 2023-10-31 中金金融认证中心有限公司 一种用于文件系统的装置及对文件系统进行操作的方法
US11677633B2 (en) 2021-10-27 2023-06-13 EMC IP Holding Company LLC Methods and systems for distributing topology information to client nodes
US11762682B2 (en) 2021-10-27 2023-09-19 EMC IP Holding Company LLC Methods and systems for storing data in a distributed system using offload components with advanced data services
US11922071B2 (en) 2021-10-27 2024-03-05 EMC IP Holding Company LLC Methods and systems for storing data in a distributed system using offload components and a GPU module

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008077366A (ja) 2006-09-21 2008-04-03 Hitachi Ltd 記憶制御装置及び記憶制御装置の暗号化機能制御方法
JP2014529238A (ja) 2011-08-25 2014-10-30 ネットアップ，インコーポレイテッド 安全なマルチキャストクラスタ内通信を提供するためのシステムおよび方法
JP2016057811A (ja) 2014-09-09 2016-04-21 株式会社 日立産業制御ソリューションズ 蓄積配信サーバ及び蓄積配信システム

Family Cites Families (66)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH09179768A (ja) * 1995-12-21 1997-07-11 Olympus Optical Co Ltd ファイル暗号化システム及びファイル復号化システム
US6487636B1 (en) 2000-04-24 2002-11-26 Hewlett-Packard Co. Method and apparatus for mapping data in a heterogeneous disk array storage system
US7200747B2 (en) * 2001-10-31 2007-04-03 Hewlett-Packard Development Company, L.P. System for ensuring data privacy and user differentiation in a distributed file system
US7681072B1 (en) 2004-08-13 2010-03-16 Panasas, Inc. Systems and methods for facilitating file reconstruction and restoration in data storage systems where a RAID-X format is implemented at a file level within a plurality of storage devices
EP1825412A1 (en) * 2004-10-25 2007-08-29 Rick L. Orsini Secure data parser method and system
US7447839B2 (en) 2005-09-13 2008-11-04 Yahoo! Inc. System for a distributed column chunk data store
US7793146B1 (en) 2007-08-07 2010-09-07 Panasas, Inc. Methods for storing data in a data storage system where a RAID-X format or formats are implemented at a file level
US8645749B2 (en) 2009-02-04 2014-02-04 Micron Technology, Inc. Systems and methods for storing and recovering controller data in non-volatile memory devices
US8458287B2 (en) 2009-07-31 2013-06-04 Microsoft Corporation Erasure coded storage aggregation in data centers
US9537650B2 (en) * 2009-12-15 2017-01-03 Microsoft Technology Licensing, Llc Verifiable trust for data through wrapper composition
US9135471B2 (en) * 2010-03-10 2015-09-15 Dell Products L.P. System and method for encryption and decryption of data
US8601600B1 (en) * 2010-05-18 2013-12-03 Google Inc. Storing encrypted objects
US9058291B2 (en) * 2011-02-28 2015-06-16 International Business Machines Corporation Multiple erasure correcting codes for storage arrays
US8433979B2 (en) * 2011-02-28 2013-04-30 International Business Machines Corporation Nested multiple erasure correcting codes for storage arrays
US8650435B2 (en) * 2011-06-08 2014-02-11 Dell Products L.P. Enhanced storage device replacement system and method
US9178698B1 (en) * 2011-12-21 2015-11-03 Google Inc. Dynamic key management
US8874995B2 (en) * 2012-02-02 2014-10-28 International Business Machines Corporation Partial-maximum distance separable (PMDS) erasure correcting codes for storage arrays
US8719594B2 (en) * 2012-02-15 2014-05-06 Unisys Corporation Storage availability using cryptographic splitting
US9209973B2 (en) * 2012-11-20 2015-12-08 Google Inc. Delegate authorization in cloud-based storage system
US9608813B1 (en) * 2013-06-13 2017-03-28 Amazon Technologies, Inc. Key rotation techniques
US9705674B2 (en) * 2013-02-12 2017-07-11 Amazon Technologies, Inc. Federated key management
US9953317B2 (en) * 2013-03-13 2018-04-24 Shopkeep.Com, Inc. Method and system for secure key rotation
US9098445B2 (en) * 2013-03-14 2015-08-04 Apple Inc. Selection of redundant storage configuration based on available memory space
US9600675B2 (en) * 2014-02-23 2017-03-21 Aitheras, Llc Secure file transfer systems and methods
US9087012B1 (en) 2014-06-04 2015-07-21 Pure Storage, Inc. Disaster recovery at high reliability in a storage cluster
US9582363B2 (en) 2014-06-09 2017-02-28 International Business Machines Corporation Failure domain based storage system data stripe layout
CN104601579A (zh) * 2015-01-20 2015-05-06 成都市酷岳科技有限公司 一种保障信息安全的计算机系统及其方法
US9921910B2 (en) 2015-02-19 2018-03-20 Netapp, Inc. Virtual chunk service based data recovery in a distributed data storage system
US9807077B2 (en) * 2015-03-10 2017-10-31 Polyverse Corporation Systems and methods for containerized data security
US9916458B2 (en) * 2015-03-31 2018-03-13 EMC IP Holding Company LLC Secure cloud-based storage of data shared across file system objects and clients
US20170004131A1 (en) * 2015-07-01 2017-01-05 Weka.IO LTD Virtual File System Supporting Multi-Tiered Storage
EP3320456A4 (en) * 2015-07-08 2018-07-18 Cloud Crowding Corp. System and method for secure transmission of signals from a camera
US9448887B1 (en) * 2015-08-22 2016-09-20 Weka.IO Ltd. Distributed erasure coded virtual file system
US9766816B2 (en) * 2015-09-25 2017-09-19 Seagate Technology Llc Compression sampling in tiered storage
US9699244B2 (en) * 2015-11-11 2017-07-04 Weka.IO Ltd. Load balanced network file accesses
US11455097B2 (en) * 2016-01-28 2022-09-27 Weka.IO Ltd. Resource monitoring in a distributed storage system
US10460119B2 (en) * 2016-02-26 2019-10-29 Intuit Inc. IDPS access-controlled and encrypted file system design
MX2018011241A (es) * 2016-03-15 2018-11-22 Datomia Res Labs Ou Administracion y seguridad de datos del sistema de almacenamiento distribuido.
US10326744B1 (en) * 2016-03-21 2019-06-18 EMC IP Holding Company LLC Security layer for containers in multi-tenant environments
US10397189B1 (en) * 2016-09-27 2019-08-27 Amazon Technologies, Inc. Peered virtual private network endpoint nodes
CN106815528B (zh) * 2016-12-07 2019-10-29 重庆软云科技有限公司 一种文件管理方法及装置、存储设备
US10453547B2 (en) * 2017-06-16 2019-10-22 Seagate Technologies Llc Monitoring a memory for retirement
US10659225B2 (en) * 2017-06-30 2020-05-19 Microsoft Technology Licensing, Llc Encrypting existing live unencrypted data using age-based garbage collection
US10545921B2 (en) * 2017-08-07 2020-01-28 Weka.IO Ltd. Metadata control in a load-balanced distributed storage system
US20190095296A1 (en) * 2017-09-27 2019-03-28 Hewlett Packard Enterprise Development Lp Reading or Reconstructing Requested Data from RAID Volume
US10394490B2 (en) * 2017-10-23 2019-08-27 Weka.IO Ltd. Flash registry with write leveling
US11385980B2 (en) * 2017-11-13 2022-07-12 Weka.IO Ltd. Methods and systems for rapid failure recovery for a distributed storage system
US11782875B2 (en) * 2017-11-13 2023-10-10 Weka.IO Ltd. Directory structure for a distributed storage system
US11561860B2 (en) * 2017-11-13 2023-01-24 Weka.IO Ltd. Methods and systems for power failure resistance for a distributed storage system
US11061622B2 (en) * 2017-11-13 2021-07-13 Weka.IO Ltd. Tiering data strategy for a distributed storage system
US11262912B2 (en) * 2017-11-13 2022-03-01 Weka.IO Ltd. File operations in a distributed storage system
US10936405B2 (en) * 2017-11-13 2021-03-02 Weka.IO Ltd. Efficient networking for a distributed storage system
US11301433B2 (en) * 2017-11-13 2022-04-12 Weka.IO Ltd. Metadata journal in a distributed storage system
US11216210B2 (en) * 2017-11-13 2022-01-04 Weka.IO Ltd. Flash registry with on-disk hashing
US11042661B2 (en) 2018-06-08 2021-06-22 Weka.IO Ltd. Encryption for a distributed filesystem
US10942807B2 (en) * 2018-06-12 2021-03-09 Weka.IO Ltd. Storage system spanning multiple failure domains
US11074668B2 (en) * 2018-06-19 2021-07-27 Weka.IO Ltd. GPU based server in a distributed file system
US11169746B2 (en) * 2018-06-19 2021-11-09 Weka.IO LTD Expanding a distributed storage system
US10976966B2 (en) * 2018-06-29 2021-04-13 Weka.IO Ltd. Implementing coherency and page cache support in a distributed way for files
US11169961B2 (en) * 2018-06-29 2021-11-09 Weka.IO Ltd. Data migration in a distributive file system
US11093444B2 (en) * 2018-07-02 2021-08-17 Weka.IO Ltd. Access redirection in a distributive file system
US11455275B2 (en) * 2018-07-18 2022-09-27 Weka.IO Ltd. Storing a point in time coherently for a distributed storage system
US11163723B2 (en) * 2018-07-19 2021-11-02 Weka.IO Ltd. Pushing a point in time to a backend object storage for a distributed storage system
US11023178B2 (en) * 2018-07-24 2021-06-01 Weka, Io Ltd Implementing coherency and page cache support for a storage system spread across multiple data centers
US11340823B2 (en) * 2018-08-20 2022-05-24 Weka.IO Ltd. Authenticated stateless mount string for a distributed file system
US11175986B1 (en) * 2020-07-01 2021-11-16 International Business Machines Corporation Storage systems implementing offset erasure code stripes

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008077366A (ja) 2006-09-21 2008-04-03 Hitachi Ltd 記憶制御装置及び記憶制御装置の暗号化機能制御方法
JP2014529238A (ja) 2011-08-25 2014-10-30 ネットアップ，インコーポレイテッド 安全なマルチキャストクラスタ内通信を提供するためのシステムおよび方法
JP2016057811A (ja) 2014-09-09 2016-04-21 株式会社 日立産業制御ソリューションズ 蓄積配信サーバ及び蓄積配信システム

Also Published As

Publication number Publication date
JP2023071843A (ja) 2023-05-23
US11914736B2 (en) 2024-02-27
US20230033729A1 (en) 2023-02-02
US11042661B2 (en) 2021-06-22
WO2019234501A3 (en) 2020-05-07
EP3814945A4 (en) 2022-03-09
CN112243508A (zh) 2021-01-19
WO2019234501A2 (en) 2019-12-12
US20190377892A1 (en) 2019-12-12
US11507681B2 (en) 2022-11-22
EP3814945A2 (en) 2021-05-05
US20210294907A1 (en) 2021-09-23
JP2021527286A (ja) 2021-10-11

Similar Documents

Publication Publication Date Title
JP7238111B2 (ja) 分散型ファイルシステムのための暗号化
US20190188079A1 (en) Durable block storage in data center access nodes with inline erasure coding
US11086525B2 (en) Resilient external memory
US10089009B2 (en) Method for layered storage of enterprise data
US11693581B2 (en) Authenticated stateless mount string for a distributed file system
US11262912B2 (en) File operations in a distributed storage system
CN115867884A (zh) 提供数据管理即服务
US11579992B2 (en) Methods and systems for rapid failure recovery for a distributed storage system
CN112262407A (zh) 分布式文件系统中基于gpu的服务器
US11422893B2 (en) Storage system spanning multiple failure domains
US11994944B2 (en) Efficient networking for a distributed storage system
CN112292661A (zh) 扩展分布式存储系统
WO2012074354A1 (en) System architecture with cluster file for virtualization hosting environment
Zilber TPT-RAID: a High Performance Box-Fault Tolerant Storage System

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20211125

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20221026

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20221028

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20230119

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20230130

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20230301

R150 Certificate of patent or registration of utility model

Ref document number: 7238111

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150