特許 5671615 マップリデュース即時分散ファイルシステム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5671615

(24)【登録日】2014年12月26日

(45)【発行日】2015年2月18日

(54)【発明の名称】マップリデュース即時分散ファイルシステム

(51)【国際特許分類】

   G06F 12/00 20060101AFI20150129BHJP

【ＦＩ】

   G06F12/00 545A

   G06F12/00 520A

   G06F12/00 531M

【請求項の数】20

【全頁数】28

(21)【出願番号】特願2013-516634(P2013-516634)

(86)(22)【出願日】2011年6月17日

(65)【公表番号】特表2013-541057(P2013-541057A)

(43)【公表日】2013年11月7日

(86)【国際出願番号】US2011040936

(87)【国際公開番号】WO2011160054

(87)【国際公開日】20111222

【審査請求日】2013年2月19日

(31)【優先権主張番号】61/356,582

(32)【優先日】2010年6月19日

(33)【優先権主張国】US

(31)【優先権主張番号】13/162,439

(32)【優先日】2011年6月16日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】512328256

【氏名又は名称】マップアール テクノロジーズ インコーポレイテッド

(74)【代理人】

【識別番号】100092048

【弁理士】

【氏名又は名称】沢田 雅男

(74)【代理人】

【識別番号】100095407

【弁理士】

【氏名又は名称】木村 満

(74)【代理人】

【識別番号】100109449

【弁理士】

【氏名又は名称】毛受 隆典

(74)【代理人】

【識別番号】100132883

【弁理士】

【氏名又は名称】森川 泰司

(74)【代理人】

【識別番号】100123618

【弁理士】

【氏名又は名称】雨宮 康仁

(74)【代理人】

【識別番号】100148633

【弁理士】

【氏名又は名称】桜田 圭

(74)【代理人】

【識別番号】100147924

【弁理士】

【氏名又は名称】美恵 英樹

(72)【発明者】

【氏名】スリバス、マンダヤン シー

(72)【発明者】

【氏名】ラビンドラ、ピンディクラ

(72)【発明者】

【氏名】サラディ、ウッパルリ ビジャヤ

(72)【発明者】

【氏名】パンデ、アーヴィンド アルン

(72)【発明者】

【氏名】サナパラ、チャンドラ ガル キラン バブ

(72)【発明者】

【氏名】レニュ、ロヒト ヴィジャヤ

(72)【発明者】

【氏名】ベランキ、ビベカナンド

(72)【発明者】

【氏名】カバチェリ、サティヤ

(72)【発明者】

【氏名】ハドケ、アミット アショケ

【審査官】 原 秀人

(56)【参考文献】

【文献】 特開２０１０−０９２２２２（ＪＰ，Ａ）

【文献】 ユーレッシュ・ヴァハリア，最前線ＵＮＩＸのカーネル，株式会社ピアソン・エデュケーション，２０００年 ５月１５日，第１版，p. 371-374, 378-382, 411-415

【文献】 トム・ホワイト，Ｈａｄｏｏｐ，株式会社オライリー・ジャパン，２０１０年 ２月１５日，第１版，p. 43-47

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ １２／００

(57)【特許請求の範囲】

【請求項1】

各コンテナが、ファイルとディレクトリメタデータとファイルコンテンツデータを格納している複数のコンテナであって、
ファイルコンテンツデータへの参照が、コンテナのメタデータとデータが格納されているノードのサブセットに格納されていて、かつ
コンテナのデータとメタデータが、トポロジー的なソートにより更新順序を読取ることが可能となるように配置されている、
複数のコンテナと、
当該複数のコンテナのそれぞれがどこに配置されているかについての情報を維持するように構成されたコンテナ位置データベース（ＣＬＤＢ）と、
各クラスタノードが１つ以上の記憶プールを含み、各記憶プールがゼロ個以上のコンテナを含む、複数のクラスタノードと、
前記コンテナ内で、１つ以上のディスクブロック内にある１つ以上のデータ構造を構成するための複数のｉノードと、を含み、
同じ記憶プール内にある２つ以上のコンテナが、同じディスクブロック内にあるデータ構造を参照するように構成可能である、
マップリデュース互換可能な分散ファイルシステム。

【請求項2】

前記コンテナが、各複製チェーンに関するマスタとして指定された１つのコンテナと共に他のクラスタノードに複製される、請求項１に記載の分散ファイルシステム。

【請求項3】

前記ＣＬＤＢが複数の余分なサーバによって維持され、ＣＬＤＢ内のデータ自体が、よく知られているコンテナ内のｉノードとして記憶されている、請求項１に記載の分散ファイルシステム。

【請求項4】

ＣＬＤＢノードが、前記コンテナのすべてに関する情報を少なくとも含むデータベースを維持するように構成され、前記コンテナのすべてに関する前記情報が、
コンテナの複製を有するノード、および
各コンテナに関する複製チェーンの順番である、
請求項３に記載の分散ファイルシステム。

【請求項5】

前記ＣＬＤＢが、各コンテナに関するすべてのトランザクションを制御するマスタノードに該コンテナを割り当てる、
前記ＣＬＤＢが、複製を保持するノードのチェーンを指定する、
前記複製の１つが故障するかマスタＣＬＤＢノードから分離された場合、それは複製チェーンから取り除かれる、
マスタが故障するか分離された場合、新しいマスタが指定される、
複製チェーンから取り除かれた後で復帰した任意のノードは、ノードが復帰したときにチェーンがまだ別の複製チェーンを必要とする場合には、複製チェーンの最後に再挿入される、
第１の所定の期間内にノードが復帰した場合、問題となっているコンテナを複製する新しいノードが指定されることはなく、チェーンはなお複製チェーンを必要とする、
第２の、より長い所定の期間内にノードが故障した場合、ＣＬＤＢはチェーン内に位置を占める他のノードを指定することができる、
のいずれかに従うポリシー制約に前記ＣＬＤＢが合致するように、コンテナ内のデータの複製としてノードを割り当てるように前記ＣＬＤＢが構成される、請求項１に記載の分散ファイルシステム。

【請求項6】

コンテナマスタがトランザクション的に複製チェーンの更新を制御するように構成される、請求項５に記載の分散ファイルシステム。

【請求項7】

すべてのｉノードデータ構造および間接データＢ木が、トランザクションを失ったコンテナ複製の更新を容易にするバージョン番号を有する、請求項１に記載の分散ファイルシステム。

【請求項8】

データが分散ファイルシステム内の、ディスク全体、フラッシュメモリシステム、それらのいずれかのパーティション、および従来のファイルシステムに記憶された個々のファイル、のいずれかを表すブロック装置を含む複数のブロックアドレス可能なデータ記憶装置上に記憶され、
各データ記憶装置が、比較的小さい、固定サイズのブロックのデータのランダムな読み書きをサポートする、
請求項１に記載の分散ファイルシステム。

【請求項9】

前記各記憶プールが、
前記記憶プール内のいくつかのよく知られた位置に複製されるスーパーブロック内にそれぞれが記憶された、複数のビットマップ空間、複数のログ空間、およびコンテナディスクオフセットへのＣＩＤのマップを含み、
前記ビットマップ空間は、前記記憶プールに関する複数のブロック割り当てビットマップへのポインタを含み、
前記ログ空間は、前記記憶プールに関するトランザクションログを記憶するために用いられる前記記憶プールの部分へのポインタを含み、
ディスクオフセットへのコンテナＩＤ（ＣＩＤ）の前記マップは、前記記憶プール内のディスクオフセットを発見するようにコンテナＩＤを検索する機構を含む、
請求項１に記載の分散ファイルシステム。

【請求項10】

各ＦＩＤが特定のコンテナ内のｉノードを参照し、各ＦＩＤがコンテナＩＤ、ｉノード番号、およびｉノードが異なる目的で再使用されてもＦＩＤのコンテンツを一意的にするように選ばれた整数を含む、複数のファイル識別子（ＦＩＤ）をさらに含む、
請求項１に記載の分散ファイルシステム。

【請求項11】

複数のコンテナのそれぞれがどこに配置されているかについての情報を維持するように構成されたコンテナ位置データベース（ＣＬＤＢ）と、
各クラスタノードが１つ以上の記憶プールを含み、各記憶プールがゼロ個以上のコンテナを含む、複数のクラスタノードと、
前記コンテナ内で、１つ以上のディスクブロック内にある１つ以上のデータ構造を構成するための複数のｉノードと、を含み、
同じ記憶プール内にある２つ以上のコンテナが、同じディスクブロック内にあるデータ構造を参照するように構成可能である、
マップリデュース互換可能な分散ファイルシステムであって、
各ｉノードが、
所有者、許可、親ＦＩＤ、オブジェクトのタイプ、およびサイズを含む各オブジェクトの種々の特徴を記述する属性を含むコンポジットデータ構造をさらに含み、
オブジェクトのタイプはローカルファイル、チャンクファイル、ディレクトリ、キー値記憶、シンボリックリンク、またはボリュームマウントポイントのいずれかを含み、
前記ｉノードはさらに、オブジェクト内のデータのバイトの最初の組を含むディスクブロックへのポインタを含み、
前記ポインタのそれぞれは、前記ポインタと共に記憶された関連するコピーオンライトビットを含み、
前記ｉノードはさらに、間接的なデータへの参照を含み、該参照は、ローカルファイルの場合には、Ｂ＋木に関するコピーオンライトビットと共にオブジェクトデータを含む該Ｂ＋木へのポインタを含むことができ、チャンクファイルの場合には、ファイルのコンテンツを含む他のコンテナ内のローカルファイルを参照するＦＩＤを含むＦＩＤマップと呼ばれるローカルファイルへのポインタを含み、
前記ｉノードはｉノードから参照される任意の構造に関する最新のバージョン番号のキャッシュをさらに含み、
前記バージョン番号は複製およびミラーリングにおいて用いられるように構成される、
マップリデュース互換可能な分散ファイルシステム。

【請求項12】

前記チャンクファイルが、多くのコンテナ内に記憶されたチャンクからなるファイルを含み、各チャンクはローカルファイルおよび、これらのローカルファイルへの参照の列へとつながるチャンクファイルｉノードからの参照として表される、請求項１１に記載の分散ファイルシステム。

【請求項13】

前記シンボリックリンクが、ファイルの名前を含み任意の分散ファイルシステムオブジェクトを指示可能なローカルファイルとして記憶される、請求項１１に記載の分散ファイルシステム。

【請求項14】

ボリュームマウントが、マウントされるボリュームの名前を含むローカルファイルとして記憶される、請求項１１に記載の分散ファイルシステム。

【請求項15】

前記分散ファイルシステムが読み書きアクセスファイルシステムとして構成され、ランダムな更新および読み込みが、クラスタ内の任意のノードから、および／または、クラスタ内の他の装置への自由なアクセスを有する任意の装置から起こる、請求項１に記載の分散ファイルシステム。

【請求項16】

前記分散型ファイルシステムがステートレスなアクセスのために構成される、請求項１に記載の分散ファイルシステム。

【請求項17】

少なくとも１つのＮＦＳゲートウェイをさらに含み、
前記分散型ファイルシステムがＮＦＳネットワークプロトコルを介してのアクセスのために構成される、
請求項１６に記載の分散ファイルシステム。

【請求項18】

複数のＮＦＳゲートウェイと、
調整サーバによって前記ＮＦＳゲートウェイが、どの前記ＮＦＳゲートウェイがどのＩＰアドレスをホスティングするかを協調的に決定する、前記調整サーバと、
をさらに含む、請求項１７に記載の分散ファイルシステム。

【請求項19】

すべてのＮＦＳサーバが分散ファイルシステム内のすべてのファイルにアクセス可能な、請求項１８に記載の分散ファイルシステム。

【請求項20】

分散ファイルシステムを介してアクセスされるすべてのファイル名が、共通のプレフィックスで始まり、その後にクラスタ名および前記クラスタ内のファイル名が続き、
前記ＮＦＳゲートウェイは、各アクセス可能なクラスタに対応するバーチャルファイルを、前記共通のプレフィックスに関連づけられたトップレベルバーチャルディレクトリに表示させるように構成される、
請求項１８に記載の分散ファイルシステム。

【発明の詳細な説明】

【技術分野】

【0001】

本出願は、２０１１年６月１６日に出願された米国特許出願第１３／１６２４３９号および２０１０年６月１９日に出願された米国特許仮出願第６１／３５６５８２号の優先権を主張し、それらの出願は参照により全体が本明細書に組み込まれる。

【0002】

本発明はコンピュータファイルシステムに関する。より詳細には、本発明はマップリデュース即時分散ファイルシステムに関する。

【背景技術】

【0003】

マップリデューススタイルのプログラムを用いた分散クラスタコンピューティングはＪｅｆｆｒｅｙ ＤｅａｎおよびＳａｎｊａｙ Ｇｈｅｍａｗａｔによって広められた。非特許文献１を参照のこと。このスタイルにおいて、計算はマップフェーズ、シャッフルフェーズ、およびリデュースフェーズに分解される。図１はこの形の計算の簡易化された概略図を示す。入力１０１は入力スプリットと呼ばれるピースに分割される。各入力スプリットは入力の隣接する領域である。各入力スプリットの各レコードは、本明細書ではｆ_１として示されるマップ機能１０２のインスタンスに独立して通される。このマップ機能は単一のレコードを入力として受け入れ、ゼロ個以上の出力レコードを生成するように定められており、各出力レコードがキーおよび値を有する。マップ機能からの出力レコードは、同一のキーを有するすべての値が一緒にまとめられるようにレコードを再配置するシャッフル１０３に通される。リデュース機能１０４のインスタンスは、本明細書ではｆ_２として示される。リデュース機能は２つの引数をとると定義されており、第１の引数はキー値であり第２の引数は値のリストである。ｆ_２の出力は出力ファイル１０５に記憶されたゼロ個以上のレコードからなる。

【0004】

このスタイルの計算は十分な普遍性を提供し、大規模なデータを処理するために非常に役立つ。同時に、十分に単純な動作を有し、高度な故障耐性を可能にする。しかしながら、マップリデュースプログラムは、従来のファイルシステムと共にサポートすることが困難であるという厳しい負荷をファイルシステムに課す。

【0005】

Ｇｏｏｇｌｅにおけるオリジナルのマップリデュース実装（特許文献１を参照）は、ＧＦＳと呼ばれるライトワンスファイルシステムを伴っていた。次いで、Ａｐａｃｈｅ Ｈａｄｏｏｐプロジェクトが、Ｈａｄｏｏｐとして知られるＧｏｏｇｌｅのマップリデュースの大まかなクローンを構築した。ＧＦＳと同じ役割を果たすＨａｄｏｏｐ分散ファイルシステム（ＨＤＦＳ）として知られるファイルシステムが、Ｈａｄｏｏｐに関連づけられている。

【0006】

ＧＦＳとＨＤＦＳの両方が、ＲＡＩＤなどの従来のエラー訂正方法を超えた信頼性の高い機構としていくつかの機械にわたって複製を導入するライトワンスファイルシステムである。両方のシステムのライトワンスの動作は、複製を実装するためのストラテジーを比較的単純なものとする。複製はまた、マップフェーズのタスクが、読まれているデータのコピーの近くに配置されることを可能にし、ディスクアクセスがネットワークアクセスよりも概してかなり速いことにより、実質的なパフォーマンス強化を与える。

【0007】

シャッフルによって課せられるファイル生成負荷をサポートすることが困難であるため、ＧｏｏｇｌｅのマップリデュースおよびＨａｄｏｏｐのどちらも、シャッフルフェーズの最中に大規模なローカルファイルシステムを使用する。例えば、１００００マップスプリットおよび１０００リデューサの大規模な計算は１０００万の出力パーティションを生成する。シャッフルの最も単純な実装は、分散ファイルシステムを用いて、これらのパーティションのそれぞれを別々のファイルに記憶しがちである。そのような手法はシャッフル動作をほとんど些細なものにするが、数秒間にこの数百万のファイルをクラスタが生成可能であることを必要とする。不幸にも、ＨＤＦＳのファイル生成速度は多くとも毎秒１０００ファイルに限られ、ＧＦＳもまたこの点で制限される。ＨＤＦＳとＧＦＳの両方において中央メタデータサーバがメタデータを扱い、ロケーションルックアップをブロックするために、これらの制限が発生する。ファイルメタデータはとても変わりやすいため、中央メタデータおよびロケーションサーバを用いるための実装の選択がファイルシステムのライトワンス特性によって求められている。

【0008】

ローカルファイルシステムは複合プロセスによって数万のファイルに同時にアクセスすることをサポートできないため、ローカルファイルとしてシャッフルパーティションを記憶することもまた、ＨａｄｏｏｐとＧＦＳのいずれにおいても実現可能ではない。ローカルファイルシステムによって課せられた制限により、バグのない状態にすることが非情に困難で、ユーザが動作を調節することが困難な、複雑なシャッフルの実装につながった。

【0009】

Ｈａｄｏｏｐなどのシステムもまた、多数の中小のサイズのファイルがシステム内に記憶されている場合、性能の深刻な低下に悩む。ファイルのライトワンス特性と、大きなファイルへの要望と、受信のわずかな時間内にデータを一体化する必要性は、しばしば、短い時間でデータを記録してファイルを繰り返し連結させて大きなファイルを形成する応用へとつながる。小さいファイルの連結および安全な削除の管理は、時間を消費し大量のリソースを無駄にする。ＴｗｉｔｔｅｒやＦａｃｅｂｏｏｋなどの企業におけるクラスタ容量の半分くらいはこのようなファイルの連結に費やされているとの見積もりがある。

【0010】

分散ファイルシステムの歴史は長く、様々であるが、マップリデュース即時分散ファイルシステムのキーになる設計ポイントに関しては、少ない数のシステムを使って最高水準を示すことができる。これらのシステムのいずれも、相互作用的整合性、読み／書きアクセス、大きな集合帯域幅、およびファイル生成速度に関するマップリデュースクラスタの完全なサポートの要求を満たさない。より重要には、これらのシステムにおいてこれらの要求の１つ以上を満たすために個別に使用される方法が、ほかの要求を満たすことを不可能にする。このことは、これらのシステム由来の方法を単純にまとめることによってすべての要求を満たすことが不可能であることを意味する。

【0011】

上記のように、ＧＦＳおよびＨＤＦＳはライトワンス、複製ベースのファイルシステムを提供する。複製の使用は広帯域を提供するが、読み／書き環境における相互作用的整合を困難にする。このことはこれらシステムのライトワンス設計の動機づけとなり、ライトワンスの性質は中央メタデータサーバの使用を強いる。中央メタデータサーバは、これに対して、ファイル生成速度の要求を満たすことをほとんど不可能にする。したがって、帯域幅の要求を満たすためにＧＦＳおよびＨＤＦＳに用いられた機構は、新しい技術なしに読み／書きおよびファイル生成の要求を満たすことを本質的に不可能にする。加えて、ＨＤＦＳとＧＦＳの双方とも、これらが管理できる合計のファイル数が厳しく限られている。

【0012】

ＧＰＦＳはＨａｄｏｏｐにおいて限定された形で用いられている、ＩＢＭから広められたファイルシステム形式である。非特許文献２を参照。ＧＦＰＳは、単一のノードを各ファイルまたはファイル領域に対するマスタとして特定可能にする分散ロックマネージャを用いることによってコヒーレントな読み／書き能力を提供する。ＧＦＰＳは集中型メタデータ記憶なしに比較的大きなファイルの記憶をサポートすることができるが、ロックマネージャ上でのスループットは非常に限られているため、このロッキングスキームは高いファイル生成速度をサポートすることができない。出版された文献（非特許文献３を参照）に基づいて、１０００個のコンピュータのクラスタ内での１秒に１０００万のファイルの生成には、２０００以上のロックマネージャサーバを必要とするであろう。現実的なクラスタのファイル生成動作は毎秒１０万ファイルより相当少ない数に限られる。

【0013】

ＧＰＦＳにおいて、複製はミラーリングを介した災害回復スキームの一部としてのみサポートされる。ファーストクラスの複製の欠如は総計の読み込み帯域を限定する。加えて、ミラーリングスキームはデータの喪失を回避するために所定の動作を必要とし、それはクラスタをはるかに故障しやすくする。

【0014】

ｐＮＦＳ（非特許文献４を参照）は多くのＮＦＳ実装サーバおよび集中メタデータサーバを用いたパラレルなＮＦＳ実装である。ｐＮＦＳはトランザクションの更新サポートを欠き、コヒーレントな読み／書き動作に複製を提供しない。集中メタデータサーバの使用は最大ファイル生成速度を厳しく制限する。ＮＦＳサーバにおいてトランザクション的に安全な複製をサポートするために容易な方法はないため、オブジェクト記憶のための独立ＮＦＳサーバのファーム（ｆａｒｍ）の使用は、チャンクファイルの複製をも困難にする。ノード障害許容度もまたｐＮＦＳの難しい問題であると思われる。

【0015】

Ｃｅｐｈは結びつけられたメタデータサーバによってオブジェクトの記憶を用いる実験的な分散ファイルシステムである。非特許文献５を参照。Ｃｅｐｈはコヒーレントなチャンクファイルの複製を提供することが不可能であり、したがって帯域幅が制限される。複製は補足部としてＣｅｐｈに追加されるため、故障耐性のあるマップリデュースシステムにおける使用には適さない。メタデータサーバはまた、ファイル生成速度に制限がある。Ｃｅｐｈは単一のメタデータサーバを有するという問題を回避するが、それはなお、秒ごとに達成されうるファイル生成の数に関しては制限がある。

【0016】

ＡＦＳは読み／書き複製に関するサポートを有しない分散ファイル記憶である。非特許文献６を参照。読みのロードのもとで、ＡＦＳはファイルクライアントに近いファイルコンテンツのキャッシュを可能にする。これらのキャッシュは更新が行われたときに取り消される。ファイルサーバと同一のコンピュータ上でアプリケーションを実行させるためのサポートは全くないので、データ局所性はない。いかなるファイルにも１つのみのマスタコピーがあるため、大規模クラスタ内の故障はデータが使用できなくなることを意味する。

【先行技術文献】

【特許文献】

【0017】

【特許文献1】米国特許第７６５０３３１号明細書

【0018】

【非特許文献1】Ｊ．Ｄｅａｎ，Ｓ．Ｇｈｅｍａｗａｔ，ＭａｐＲｅｄｕｃｅ：Ｓｉｍｐｌｉｆｉｅｄ Ｄａｔａ Ｐｒｏｃｅｓｓｉｎｇ ｏｎ Ｌａｒｇｅ Ｃｌｕｓｔｅｒｓ，ＯＳＤＩ’０４：Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ ６ｔｈ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｓｙｍｐｏｓｉｕｍ ｏｎ Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍｓ Ｄｅｓｉｇｎ＆Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ，ＵＳＥＮＩＸ Ａｓｓｏｃｉａｔｉｏｎ（２００４）

【非特許文献2】ｈｔｔｐ：／／ｐｕｂｌｉｂ．ｂｏｕｌｄｅｒ．ｉｂｍ．ｃｏｍ／ｉｎｆｏｃｅｎｔｅｒ／ｃｌｒｅｓｃｔｒ／ｖｘｒｘ／ｉｎｄｅｘ．ｊｓｐ？ｔｏｐｉｃ＝％２Ｆｃｏｍ．ｉｂｍ．ｃｌｕｓｔｅｒ．ｇｐｆｓ３１．ａｄｖａｎｃｅａｄｍ．ｄｏｃ％２Ｆｂｌ１ａｄｖ＿ｇｐｆｓｒｅｐ．ｈｔｍｌ

【非特許文献3】Ｆ．Ｓｃｈｍｕｃｋ，Ｒ．Ｈａｓｋｉｎ，ＧＰＦＳ：Ａ Ｓｈａｒｅｄ−Ｄｉｓｋ Ｆｉｌｅ Ｓｙｓｔｅｍ ｆｏｒ Ｌａｒｇｅ Ｃｏｍｐｕｔｉｎｇ Ｃｌｕｓｔｅｒｓ， Ｕｓｅｎｉｘ ＦＡＳＴ Ｃｏｎｆｅｒｅｎｃｅ ２００２，ｈｔｔｐ：／／ｗｗｗ．ｕｓｅｎｉｘ．ｏｒｇ／ｐｕｂｌｉｃａｔｉｏｎｓ／ｌｉｂｒａｒｙ／ｐｒｏｃｅｅｄｉｎｇｓ／ｆａｓｔ０２／ｓｃｈｍｕｃｋ．ｈｔｍｌ

【非特許文献4】ｈｔｔｐ：／／ｗｗｗ．ｐｎｆｓ．ｃｏｍ／

【非特許文献5】Ｓ．Ｗｅｉｌ，Ｓ．Ｂｒａｎｄｔ，Ｅ．Ｍｉｌｌｅｒ，Ｄ．Ｌｏｎｇ，Ｃ．Ｍａｌｔｚａｈｎ，Ｃｅｐｈ：Ａ Ｓｃａｌａｂｌｅ，Ｈｉｇｈ−Ｐｅｒｆｏｒｍａｎｃｅ Ｄｉｓｔｒｉｂｕｔｅｄ Ｆｉｌｅ Ｓｙｓｔｅｍ，Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ ７ｔｈ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍｓ Ｄｅｓｉｇｎ ａｎｄ Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ，ＯＳＤＩ’０６（２００６年１１月）

【非特許文献6】ｈｔｔｐ：／／ｗｗｗ．ｃｍｕ．ｅｄｕ／ｃｏｒｐｏｒａｔｅ／ｎｅｗｓ／２００７／ｆｅａｔｕｒｅｓ／ａｎｄｒｅｗ／ｗｈａｔ＿ｉｓ＿ａｎｄｒｅｗ．ｓｈｔｍｌ

【発明の概要】

【発明が解決しようとする課題】

【0019】

上記システムのいずれも、マップリデュースシステムによって課せられた必要なファイル生成速度をなおもサポートするトランザクション的な更新およびクラスタワイドなスナップショットを可能にする完全に分散的な複製ファイルシステムを提供することができない。マップリデュースプログラムはそのようなファイルシステムを用いて実行されうるが、マップリデュース計算に関連するロードのいくつかをファイルシステムから外して二次記憶システムに移動させることによってのみ実行されうる。ファイル更新がサポートされる故障耐性はこれらのシステムにおいても、商品レベルの設備における大規模動作を許容するには十分ではない。

【課題を解決するための手段】

【0020】

トランザクション的な読み書き更新動作にチャンクファイルの複製および膨大なファイル生成速度を提供する分散ファイルシステムは、マップリデュース計算クラスタに関して大きな技術的利点を提示する。本明細書で開示されたファイルシステムは、初めてこのことを可能にする多くの技術的革新性を有し、したがって、マップリデュース互換可能な分散ファイルシステムがどのように形成されうるかの例を提供する。このファイルシステムは、それぞれが次のレイヤーが形成される基礎を提供する連続したコンポーネントレイヤーからなる。それらは以下を含む。

【0021】

・記憶プールとも呼ばれるプリミティブ記憶レイヤー。記憶プールは生の（ｒａｗ）ブロック記憶を接合し（ｋｎｉｔ）、コンテナおよびトランザクションログに関する記憶機構を提供する。記憶プールは個々のファイルサーバによって操作される。

【0022】

・データ複製、再配置、およびトランザクション的な更新の基本的原理を提供するコンテナ。

【0023】

・すべてのファイルサーバの中からコンテナを発見することを可能にし、コンテナのコンテンツのトランザクション的な更新を体系化する目的でコンテナの複製の中の優先度を定義する、コンテナ配置データベース。

【0024】

・データの配置の制御、スナップショットおよびミラーの生成の制御、および様々な制御およびポリシー情報の保持を容易にする、ボリューム。

【0025】

・ディレクトリ、コンテナ位置マップ、および圧縮されたファイル内のオフセットマップなどの多くの目的のためにキーをデータに関連づけることを可能にする、キー値記憶。

【図面の簡単な説明】

【0026】

【図1】従来のマップリデュースプロセスの概略をローカルファイルシステム内に含まれるシャッフルと共に示すブロック概略図である。

【図2】シャッフルが分散ファイルシステム内に含まれ、入力および出力が分散ファイルシステム内にあるかないかのいずれかである、本発明によるマップリデュースプロセスの概略を示すブロック概略図である。

【図3】コンテナ位置データベース（ＣＬＤＢ）およびクラスタノードを含む、本発明による分散ファイルシステムの構造を示すブロック概略図である。

【図4】記憶プールが、ディスクパーティション、単一ファイル、またはディスク全体などの、プリミティブな要素からどのように構成されることができるかを示すブロック概略図である。

【図5】本発明による記憶プールの構造を示すブロック概略図である。

【図6】本発明による特定のコンテナ内のｉノード（ｉｎｏｄｅ）を参照するＦＩＤ（ファイル識別子）を示すブロック概略図である。

【図7】本発明によるローカルファイルを表すｉノードの構造を示すブロック概略図である。

【図8】本発明によるチャンクファイルを含むファイル構造を示すブロック概略図である。

【図9】本発明による、コンテンツを示し、コンテナのコンテンツを定義するｉノードファイルの配置を示すブロック概略図である。

【図10】本発明による、コンテナ複製からのクライアント読みデータを示すフロー図である。

【図11】本発明による、ブロックを読み込むことによってサーバがどのようにファイルの領域を読み込むかを示すフロー図である。

【図12】本発明による、サーバがファイルからどのようにブロックを読み込むかを示すフロー図である。

【図13】本発明による、ローカルファイルからサーバがどのようにブロックを読み込むかを示すフロー図である。

【図14】本発明による、チャンクファイルからサーバがどのようにブロックを読み込むかを示すフロー図である。

【図15】回復できないトランザクションを示すフロー図である。

【図16】本発明による、故障による影響を受けないトランザクションを示すフロー図である。

【図17】本発明による、チャンクファイルの参照の構造を示すブロック概略図である。

【図18】本発明による、クラスタに関するＮＦＳゲートウェイの動作を示すブロック概略図である。

【発明を実施するための形態】

【0027】

本明細書で開示された分散ファイルシステムは、トランザクション的な読み書き更新動作にチャンクファイルの複製および膨大なファイル生成速度を提供し、マップリデュース計算クラスタに関して大きな技術的利点を提供する。主題のファイルシステムは、初めてこのことを可能にする多くの技術的革新性を有し、したがって、マップリデュース互換可能な分散ファイルシステムがどのように形成されうるかの例を提供する。

【0028】

図２は、シャッフル２０３が分散ファイルシステム内に含まれ、入力および出力が本発明による分散ファイルシステム内にあるかないかのいずれかである、マップリデュース処理の概略を示すブロック概略図である。このファイルシステムは、それぞれが次のレイヤーが形成される基礎を提供する連続したコンポーネントレイヤーからなる。それらは以下にさらに詳細に記載され、以下のものを含む。

【0029】

・記憶プールとも呼ばれるプリミティブ記憶レイヤー。記憶プールは生の（ｒａｗ）ブロック記憶を接合し（ｋｎｉｔ）、コンテナおよびトランザクションログに関する記憶機構を提供する。記憶プールは個々のファイルサーバによって操作される。

【0030】

・データ複製、再配置、およびトランザクション的な更新の基本的原理を提供するコンテナ。

【0031】

・すべてのファイルサーバの中からコンテナを発見することを可能にし、コンテナのコンテンツのトランザクション的な更新を体系化する目的でコンテナの複製の中の優先度を定義する、コンテナ配置データベース。

【0032】

・データの配置の制御、スナップショットおよびミラーの生成の制御、および様々な制御およびポリシー情報の保持を容易にする、ボリューム。

【0033】

・ディレクトリ、コンテナ位置マップ、および圧縮されたファイル内のオフセットマップなどの多くの目的のためのデータにキーを関連づけることを可能にする、キー値記憶。

【0034】

加えて、これらの基本的なコンポーネントの実装を容易にする他のデータ構造がある。これらの追加のデータ構造は、本明細書に開示された分散ファイルシステムの基本的なコンポーネントおよび能力について以下に記載する際に、話題になるので説明する。

【0035】

コンテナ位置データベース
図３は、コンテナ位置データベース（ＣＬＤＢ）３０１およびクラスタノード３０２、３０４を有する分散ファイルシステム２０３の構造を示すブロック概略図である。各クラスタノードは１つ以上の記憶プール３０３、３０５を含む。各記憶プールは０以上のコンテナ３０９、３１２を含んでもよい。データはｉノード、例えば３０６、３０８、３１０、３１１を用いてコンテナ内に構成される。コンテナは各複製チェーンごとに、マスタとして指定された１つのコンテナ、例えばコンテナ３０６によって他のクラスタノードに複製される。ＣＬＤＢは各コンテナがどこに位置するかについての情報を保持する。ＣＬＤＢはいくつかの重複するサーバに保持され、ＣＬＤＢ内のデータ自身が、よく知られているコンテナ内のｉノードとして記憶される。

【0036】

本明細書に記載された分散ファイルシステムにおけるクラスタ内のノードの断片は、コンテナ位置データベース（ＣＬＤＢ）を記憶するように指定される。小さいクラスタにおける故障耐性のためには、少なくとも３つのそのようなノードが指定されるのが通常である。より大きいクラスタに関しては、５つのノードが通常指定される。

【0037】

ＣＬＤＢノードはシステム内のすべてのコンテナに関する少なくとも以下の情報を含むデータベースを維持するように働く。

【0038】

−コンテナの複製を有するノード。

【0039】

−そのコンテナの１つの複製が各ノード上で利用可能であるコンテナのバージョン。

【0040】

−各コンテナの複製チェーンの順序づけ。

【0041】

さらに、ＣＬＤＢノードはそのうち１つをマスタとして働くように指定する。このトランザクション的なマスタは、コンテナ位置データベース自身を保持する特別なコンテナに関する複製チェーンのヘッドとして設定される。コンテナ位置データベースへのすべての更新は、以下に詳細に述べる通常のコンテナ複製機構を用いて調整される。

【0042】

ＣＬＤＢマスタの指定は調整サービスに基づくリーダ選択を用いて行われる。一実施形態では、調整サービスはＡｐａｃｈｅ Ｚｏｏｋｅｅｐｅｒを使用し、それ自身はＰａｘｏｓの簡潔にされた形態を使用し、ノードの故障またはネットワークパーティションの存在を一貫して保証する。Ａｐａｃｈｅ Ｚｏｏｋｅｅｐｅｒは、トランザクションがそのコンポーネントノードの大多数において行われ、その結果として限られた更新頻度でのみ取り扱えばよいことを、確実に保証する。分散ファイルシステムはマスタＣＬＤＢノードを確実に指名するようにＺｏｏｋｅｅｐｅｒのみを用いるため、これは限定ではない。したがって、ＣＬＤＢ自身は大多数よりは少ないコピー（ただ１つのコピーであることさえもある）と共に実行され、最も新しいものをだれが有するかを識別するためには外部の選抜されたプロバイダに頼るしかない。

【0043】

ＣＬＤＢはコンテナが移動する際に、ノードが故障した際に、または周期的なブロックの変更報告の結果としてのみ更新される。この結果は、非常に大きなクラスタに対してさえも、比較的小さい更新頻度をもたらす。コンテナ位置が無期限にキャッシュされうるため、ＣＬＤＢのクエリ頻度はなおさら小さい。期限切れの情報が用いられるといつも、コンテナ位置情報におけるキャッシュの整合性エラーが検出され、明示的なキャッシュ一貫性プロトコルは要求されない。コンテナバージョン情報はノードがクラスタを再結合する場合にのみ要求され、したがって、ファイルサーバがキャッシュする必要があるもののすべては、コンテナの現実の位置である。

【0044】

ＣＬＤＢが非常に低い更新頻度およびクエリ頻度を有することに加えて、ＣＬＤＢ自身が、例えばＨａｄｏｏｐネームノードと比較して、非常に小さい。Ｈａｄｏｏｐネームノードは、対照的に、各ファイルのすべてのブロックに関するブロック位置と同様に、すべてのファイルに関するメタデータおよびブロック数を監視しなければならない。ブロックは一般に２００ＭＢ以下のサイズであるため、Ｈａｄｏｏｐネームノードによって監視されるべきアイテムの総数はかなり大きい。対照的に、本明細書で開示された分散ファイルシステムのコンテナはかなり大きく、平均で１０から３０ＧＢの大きさであるため、位置情報はＨａｄｏｏｐホームノードにおける位置情報よりも１００から１０００倍小さくなる。ＣＬＤＢはさらなる保存へとつながるいかなるファイルメタデータも全く保持しない。さらに、コンテナ位置データが効率的にキャッシュされているため、ＣＬＤＢは任意の可視的な異なる動作を行わずにページングされることができ、メインメモリに常駐する必要がない。

【0045】

これらの要因は、本明細書に記載の分散ファイルシステムを数百万以上のコンテナを保持する規模に成長させることを可能にする。このことは、ファイルの数にかかわらず、数十エクサバイトのデータを保持するクラスタが実用化されることを暗示する。Ａｐａｃｈｅ Ｈａｄｏｏｐは、対照的に、ネームノード全体がメモリに常駐しなければならないことによって数十万のファイルに限られ、全体のサイズは一般的に数ペタバイトに限られる。

【0046】

ファイル生成速度もまた、本明細書に記載の分散ファイルシステムは他のいかなるファイルシステムよりも概して非常に速い。１０個のノードのスモールクラスタ上でさえも、本発明によるファイルシステムは、同じサイズのＨａｄｏｏｐクラスタのほぼ１００倍の速度でファイルを生成可能である。この比率により、クラスタサイズを１０００個のノードに線形に拡大すると、本明細書に記載されたファイルシステムは、同じサイズのＨａｄｏｏｐクラスタよりもほぼ４桁のオーダーで高い速度でファイルを生成可能である。

【0047】

複製およびデータ構造バージョニング
分散ファイルシステムのコンテナは複製の単位である。コンテナ位置データベース（ＣＬＤＢ）は、コンテナ内でデータの複製として動作するようにポリシーの制約を合致させる必要がある程度に多くのノードを割り当てる。複製は、しかしながら、ノードに可能な限り多くの故障が重なってもなお存続しなければならない。このために用いられる１つの戦略は、ＣＬＤＢに、各コンテナに関するすべてのトランザクションを制御するマスタノードにそのコンテナを割り当てさせることである。加えて、ＣＬＤＢは複製を保持するノードのチェーンを指定する。複製の１つが故障するかマスタＣＬＤＢノードから分離された場合、それは複製チェーンから取り除かれる。マスタが故障するか分離された場合、新しいマスタが指定される。複製チェーンから取り外された後に復帰した任意のノードは、ノードが復帰する際にチェーンがなおも別の複製を必要とする場合、複製チェーンの最後に挿入される。ノードがすばやく復帰した場合、問題のコンテナを複製する新しいノードが指定されていることはおそらくないため、チェーンはなおも複製を必要とする。ノードが長時間にわたって故障していた場合、その間に、ＣＬＤＢはチェーン内で代替となる他のノードを指定している可能性が高い。

【0048】

複製チェーンの更新は、トランザクションを制御するコンテナマスタによって、通常はトランザクション的に実行される。これはコンテナのすべての複製が最新のものであることを保証する。そのような更新はマスタ複製をローカルにロックして、他のすべてのレプリカが成功したか失敗したかを報告するまで待つことによって実行されうる。いずれの場合もロックは解除される。ノードが複製チェーンに復帰した場合には、しかしながら、不通だった間に発生したいかなるトランザクションも経験することはない。逆に、それらは、まだカレントであるかなりの量の古いデータを有していそうである。それらのノードは任意の長期間の間不通であったかもしれないため、そしてノードが復帰する保証が全くないため、ノードの復帰までトランザクションログを保持することは実行可能ではない。本明細書記載の分散ファイルシステムにおいて、ファイルシステムデータ自身は、すべてのトランザクションが再生または保持すらもされる必要なしに、コンテナ複製チェーン状態の再構築を可能にする最小セットの更新を見出すように試されうる。

【0049】

すべてのｉノードデータ構造および間接データＢ木は、トランザクションを欠いたコンテナ複製を更新することを容易にするバージョン番号を有する。複製チェーンを最新のものにするように、複製マスタのコンテナｉノードのスナップショットが、更新過程の最中に任意の他の変化を凍結するように生成される。スナップショットの最新のバージョンが、更新される複製チェーンの最新のバージョンと比較される。バージョンが同じ場合は、更新は不要である。更新が必要である場合、スナップショットｉノードの各子（ｃｈｉｌｄ）は、スナップショットに隠れた複製チェーン内にｉノードまたはブロックを発見するように同一の方法で再帰的に試される。ひとたび複製チェーンがマスタスナップショットと共に最新のものにされると、スナップショット複製の過程全体が繰り返され、マスタレプリカ先書きログ（ｗｒｉｔｅ−ａｈｅａｄ ｌｏｇ）が再生されて複製チェーンを完全に最新のものにすることができる。

【0050】

別の選択は、コンテナマスタの更新を一時的に凍結させ、変更されたブロックを新しい複製チェーンにコピーすることである。更新された複製チェーンは、すべてのレプリカの更新が複製プロセスの完了の際に一斉に現れるようなトランザクションのやり方で、利用可能となる。この更新過程もまた、変更されたブロックの現在のバージョンのみがコピーされているため、非常に古いレプリカチェーンの更新をずっと効率的なものにする。

【0051】

トランザクション的なスナップショットからなるこの複製は、ほとんどすべてのもっともらしい故障シナリオの下で、そして悪いやり方での極端な故障シナリオの下でさえも、動作が平常に継続することを可能にする。例えば、コンテナに３つの複製チェーンＡ、Ｂ、Ｃがあるとする。Ｃは利用不可能で、その後にＡおよびＢが更新を受信したとする。そのとき、ＡおよびＢの両方が利用不可能となりＣが復帰した場合、望めばシステムはなおも機能することができる。システムはＣが古いことを知っており、Ｃを前の状態に逆行させることが受け入れ可能な場合、Ｃをリードオンリーモードで利用可能にすることができる。Ｃを現在のバージョンに指定することによって、逆行した状態に関与することさえも可能である。Ｃがそのように指定されておらずＡまたはＢがようやく復帰した場合でも、システムはＡおよびＢが最新のものであることを認識することができ、ＣをＡおよびＢと合致するように回復させ、複製チェーンを復旧させて正常の動作を続けることができる。そのような部分的な故障シナリオは従来のトランザクション的システムでは概して可能ではなかった。さらに、少なくとも１つの更新複製チェーンが動いている限り、データは一切失われない。これは、システムの複製の半数以上が利用不可能になると同時にリードオンリーモードになるので所定数の更新を必要とするシステムとは、対照的である。

【0052】

この例において、Ｃなどの期限切れの複製チェーンへの更新を回避するためのいくつかの機構が可能である。１つは、すべてのノードに、該ノードがコンテナ内の最新バージョンと共に有する変更されたコンテナのリストを、定期的にＣＬＤＢへ報告させることである。故障したノードが復帰し、特定のコンテナに関する複製チェーンとのコンタクトを再構築しようとする際に、それは問題のコンテナの位置および最新のバージョンを返すＣＬＤＢにコンタクトする。コンテナが期限切れであり、他のコピーがないためにコンテナの更新が不可能である場合、返すノードはこれを自覚し、リードオンリー基準に基づいてコンテナを提供することが可能である。

【0053】

すべての複製チェーン更新は完全にトランザクション的な方法で実行されるため、本明細書で記載されたシステムはハードマウントな動作を行い、すべての書き込みが成功するか成功までずっとハングすることを保証する。複製チェーン内のノードが書き込みの最中に故障した場合、書き込みは改訂された複製チェーンによって再開される。ひとたび複製チェーン内のすべてのノードが更新を適用した旨を報告すると、書き込みは成功する。書き込みが失敗するのは、更新されているコンテナの複製チェーンのいかなる部分も利用可能ではない場合のみである。実際に、その点において、書き込み中のオブジェクトはファイルシステム内にもはや存在しないのであるからである。更新コンテナの管理の何らかのチェーンが存在する限り、データは失われない。

【0054】

同様に、最小限の数の複製チェーンが任意の更新の進行のために必要である場合、故障が複数となる率はそう高くなく新しい複製チェーンが採用および更新されることがない限り、少なくとも１つのノードがコンテナの最新バージョンと共に動作している管理の連続したチェーンが存在することが保証されうる。利用可能でない複製チェーンの数が最小である期間、更新は抑制され、特定可能な数の故障が最新のバージョンを利用不可能にすることを妨げる。これらの故障シナリオの間、追加の複製チェーンがクラスタの残りから採用され、ウインドウに脆弱性がある時間は新しい複製チェーンにコンテナをコピーするために必要な時間に限定される。典型的なコンテナのサイズにおいて、そして１Ｇｂ／ｓイーサネットデータリンクが利用可能として、この時間は約１分である。１０Ｇｂ／ｓデータリンクでは、この時間は数十秒に限定される。

【0055】

記憶プールおよびファイルサーバ
分散ファイルシステムにおけるデータは最終的にブロックアドレッシング可能なデータ記憶に記憶される。このデータ記憶は、ディスクまたはフラッシュメモリシステム全体またはそれらのいずれかのパーティションを示すブロック装置であってもよい。これらのデータ記憶は、Ｌｉｎｕｘ ｅｘｔ３ファイルシステムなどの、従来のファイルシステム内に記憶された個々のファイルであってもよい。この最も低いレベルにおいては、重要なことのすべては、各データ記憶が比較的小さい、固定されたサイズのブロックのデータをランダムに読み書きすることをサポートすることである。本明細書に記載されたシステムにおいて、これらのブロックは通常は８キロバイトであるが、当業者はその他の理に適ったブロックサイズを選択可能であることを理解するであろう。選択されたサイズは、大きなデータ記憶をより少ないビットでアドレッシングすることを可能にするのに十分大きいが、平均的な予想されるファイルサイズの一部であるほど十分小さい。それらが実際にどのように記憶されているかにかかわらず、最も一般的な使用の場合には、ファイル記憶がハードディスク全体にわたる単一のパーティションを表すブロック装置からなることとなるから、これらのデータ記憶はファイルシステム内でディスクとみなされる。

【0056】

分散ファイルシステム内のディスクは、より高いレベルのブロックアドレッシング可能なオブジェクトを提供するように種々の方法で組み合わせられる。これらの組み合わせとして、連結、ミラーリング、およびストライピングが挙げられる。これらの組み合わせは、コンポジットオブジェクトへの更新およびアクセスがコンポーネントオブジェクトへの更新およびアクセスに変わっている点で異なる。２つのディスクの連結において、第１のコンポーネントディスクのサイズよりも小さいアドレスを有するブロックへのすべての更新およびアクセスは、すべての他の更新およびアクセスが第２のディスクに向けられる間に、第１のディスクにアドレッシングされる。ミラーリングにおいて、更新はすべてのコンポーネントディスクで行われ、アクセスはランダムに選ばれた任意のコンポーネントディスクで行われる。ストライピングにおいて、コンポーネントディスクはディスクの数を法（ｍｏｄｕｌｏ）とした更新またはアクセスのブロックアドレスをとることによって選択され、コンポーネントのために用いられるアドレスはオリジナルのアドレスをコンポーネントディスクの数で割った商をとることによって導出される。任意のそのような組み合わせの結果は、それ自体でディスクと考えられうる。

【0057】

図４は、記憶プールが、ディスクパーティション、単一のファイル、またはディスク全体などのプリミティブ要素からどのように構成されるかを示すブロック概略図である。この場合にはコンポジット連結ディスク４０１が連結ディスク４０２およびストライピングされたディスク４０３の連結からなる。連結されたディスク４０２は単一のディスクパーティション４０４および単一のファイル４０５の連結からなる。ストライピングされたディスク４０３はディスク全体４０６および単一のパーティション４０７を範囲に含むパーティションからなり、場合によってはそれらの中の１つはディスク上にある。コンポジットディスク４０１へのすべての更新およびアクセスは、根底にあるプリミティブなデータ記憶４０４から４０７の１つへの更新またはアクセスへと結局は帰着する。

【0058】

図５は記憶プール５０１の構造を示すブロック概略図である。ビットマップ空間のリスト５０２、ログ空間のリスト５０３、コンテナディスクオフセットへのＣＩＤのマップ５０４が、記憶プールの中のいくつかの周知の位置に複製されるスーパーブロック内に記憶される。ビットマップ空間のリストは、記憶プールに関する複数のブロック割り当てビットマップ５０５、５０６へのポインタを有する。ログ空間のリストは、記憶プールに関するトランザクションログ５０７、５０８を記憶するために用いられる記憶プールの一部へのポインタを含む。ディスクオフセットへのコンテナＩＤ（ＣＩＤ）のマップは、コンテナの仕様５０９、５１０が記憶プール内に見出されるコンテナに対してどこに位置するかを示すポインタ、およびスナップショット５１３のリンクされたリストを形成するコンテナＩＤを有する。

【0059】

したがって、記憶プールはコンポジットまたはプリミティブなディスクとして定義され、それは４つの主要なコンポーネントを有する。

【0060】

他の３つのコンポーネントの開始点へのオフセットを含むスーパーブロック。

【0061】

ディスク内のどのブロックが使用状態にあるかを示すブロック割り当てビットマップ。分散ファイルシステムにおいて、ブロック割り当てビットマップは、ビットマップデータを含む連続的なディスク領域へのポインタのリストとして記憶される。図５において、２つのビットマップ５０５および５０６が示されるが、実際には任意に多くのビットマップが使用される。

【0062】

記憶プールのコンテンツのＡＣＩＤトランザクションを容易にするように使用されるトランザクションログ。分散ファイルシステムにおいて、トランザクションログは、実際のログデータを保持するディスク領域へのポインタのリスト５０３として記憶される。図５において、２つのログ空間５０７および５０８が示される。

【0063】

コンテナＩＤから記憶プール内の各コンテナの仕様へのマッピング５０４を含むコンテナマップ。２つのコンテナ仕様５０９および５１０が図５に示されるが、任意の数のコンテナが記憶プール内に存在してもよい。コンテナ仕様５０９のコンテンツの一部は、コンテナがコピーオンライト５１１としてマークされたかどうか、コンテナがディスク５１２上のどこに実際に位置するか、およびコンテナのスナップショット５１３のリストを示すためのビットを含む。コンテナに関する他のデータも同様に記憶されてよい。

【0064】

記憶プールは他のコンポーネントから記憶プールの詳細を隠すファイルサーバコンポーネントによって管理および変更される。ファイルサーバは、例えばコンテナ位置データベースなどの他のコンポーネントからの、あるいはファイルサーバによって管理されるコンテナへの更新またはアクセスのための要求を特定するクライアントプログラムからのメッセージを受け取る。

【0065】

コンテナ
記憶プール内のバイトよりも高い抽象化レベルにおいて、分散ファイルシステムはコンテナと見なされるオブジェクトを有する。コンテナ内のすべての構造はｉノードとして知られるデータ構造によって記述される。図６は、特定のコンテナにおいてｉノード６０１と呼ばれるＦＩＤ（ファイル識別子）６０６を示すブロック概略図である。ｉノードのすべての形態はある共通の構造を有する。この実施例におけるｉノード６０１は、所有者、許可、親ＦＩＤ、オブジェクトのタイプ、およびサイズを含むオブジェクトの種々の特徴を記述する属性６０２を含むコンポジットデータ構造である。オブジェクトのタイプはローカルファイル、チャンクファイル（ｃｈｕｎｋｅｄ ｆｉｌｅ）、ディレクトリ、キー値記憶、シンボリックリンク、またはボリュームマウントポイント、そしてその他の可能性もありうる。ｉノードはまた、オブジェクト内の最初の６４キロバイトのデータを含む８つのディスクブロックへのポインタ６０３も含む。これらのポインタのそれぞれはポインタ６０３と共に記憶された関連するコピーオンライトビットを有する。ｉノード６０１はまた、間接的なデータへの参照６０４も含む。ローカルファイルの場合には、この参照６０４は、Ｂ＋木に関するコピーオンライトビットと共にオブジェクトデータを含む該Ｂ＋木へのポインタであってもよい。チャンクファイルの場合には、参照６０４はＦＩＤマップと呼ばれるローカルファイルを指してもよく、ＦＩＤマップは、ファイルのコンテンツを含む他のコンテナ内のローカルファイルを参照するＦＩＤを含む。ｉノードのこの実施形態における参照はＢ木またはＦＩＤマップのいずれかを参照することができるが、両方を参照することはない。両方の種類の参照が同時に用いられる他の実施形態が可能である。シンボリックリンクおよびボリュームマウントは、ｉノードの直接のデータブロック内の文字列データとして参照されるファイルまたはボリュームの名前を記憶する。チャンクファイルの内部構造は以下に記載される。ｉノード６０１はまた、ｉノードから参照される任意の構造に関する最新のバージョン番号のキャッシュ６０５も含む。このバージョン番号は複製およびミラーリングにおいて用いられる。ｉノード６０６への参照はＦＩＤと呼ばれ、コンテナＩＤ、ｉノード番号、および、ｉノードが異なる目的のために再使用される場合であってもＦＩＤのコンテンツを一意的にするように選ばれた整数から構成される。

【0066】

ローカルファイルとは、完全に単一のコンテナ内にバイトを含む分散ファイルシステムにおけるオブジェクトである。ローカルファイルはデータの最初の６４ｋＢに関するディスクブロックへの８つまでの直接参照を有するｉノードによって表される。６４ｋＢよりも長いローカルファイルに関しては、Ｂ木リンクは、クラスタディスクリプタとして知られる値が６４ｋＢデータブロックのＢ木を指示する。Ｂ木に関するキーは、対応するクラスタディスクリプタの始まりに関するバイトオフセットである。それらのバイトオフセットの下位の１６ビットは常にゼロであり、キーは実際には２^１６で割ったバイトオフセットである。

【0067】

図７はローカルファイルを表すｉノードの構成を示すブロック概略図である。ここで、ｉノード７０１は図３のＣＬＤＢ３０１によって指示されたｉノードと同じ、または図６の概略で示されたものと同じ全体的構造を有する。ただし、データポインタのすべてがディスクブロック７０２を指示することと、間接的な値がＢ木７０３を指示し、それがクラスタディスクリプタ７０４を指示することを除く。

【0068】

クラスタディスクリプタ７０４は６４ｋＢまでのデータを記憶する８つまでのディスクブロックへのポインタを含む。クラスタディスクリプタ内のデータを記憶するために必要とされるのと同じ数のディスクブロックのみが用いられる。クラスタディスクリプタが圧縮されたデータを含む場合、オリジナルデータは８ｋＢブロックごとに個別に圧縮され、圧縮された表現（ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）はバイト単位で（ｂｙｔｅ−ｗｉｓｅ）連結される。各連結された８ｋＢブロックの始まりへのオフセットは、２バイト整数の配列として記憶される。単一のチャンクファイルに記憶されるデータは、チャンクファイルに関するｉノードと同じコンテナ内にあるように制限される。

【0069】

チャンクファイルは多くのコンテナに記憶されたチャンクで構成されるファイルである。各チャンクはローカルファイルとして表され、チャンクファイルのｉノードからの参照は、それらのローカルファイルへの参照の配列へとつながる。

【0070】

図８はチャンクファイルを含むファイルの構造を示すブロック概略図である。ここで、チャンクファイルに関するｉノード８０１が示される。このｉノードは、各ファイルレット（ｆｉｌｅｌｅｔ）がどれだけのデータを含むかを特定するチャンクサイズ８０２を含む。ローカルファイルでは、チャンクサイズは０に設定され、チャンクファイルでは、チャンクサイズは６４ｋかそれ以上の任意の所望の値に設定される。直接的なデータポインタは、以前にローカルファイルｉノード８０１に関して見られたような、チャンクファイルｉノードと同じコンテナ内のディスクブロック８０３への参照を有する。ファイルに関する間接的なポインタは、しかしながら、ＦＩＤマップ８０４と呼ばれるＦＩＤの配列を含むローカルファイルを指示し、該ＦＩＤマップの要素はクラスタのどこかのいずれかのコンテナの中にあるチャンクファイルとみなされる。ＦＩＤマップの要素は図６に示されたようなＦＩＤ８０６である。

【0071】

シンボリックリンクはファイルの名前を含むローカルファイルとして記憶される。通常、そのような名前は６４ｋＢ未満の長さであり、したがってｉノードの直接的なブロック内にのみ記憶される。シンボリックリンクは他のファイルシステム内に通常あるリンクを含むディレクトリに対して逆参照されることができる。本明細書の分散システムにおいて、シンボリックリンクは任意のファイルシステムオブジェクトを指示することができる。

【0072】

ボリュームマウントは、マウントされるボリュームの名前を含むローカルファイルとして記憶される。通常は、そのような名前は６４ｋＢ未満の長さであり、したがってｉノードの直接的なブロック内にのみ記憶される。ボリュームマウントはファイルシステムオブジェクトへの参照を解決する（ｒｅｓｏｌｖｅ）際にディレクトリとして処理される。マウントされているボリュームは名前によって検索され、ボリュームのルートディレクトリは、それがボリュームマウントポイントにあるかのように処理される。

【0073】

図９はコンテナのコンテンツを定義するｉノードファイルのコンテンツおよびレイアウトを示すブロック概略図である。ｉノードファイル自身のｉノードは１６個のリザーブされたｉノードの１つである。ｉノードファイルはローカルファイルとして記憶される。コンテナ内のすべてのファイルはコンテナＩＤおよびｉノードナンバによって定義される。ファイルのｉノードナンバは、ファイルに関する２５６バイトのｉノード構造を見出すようにｉノードファイル内でオフセットを計算するように用いられる。ｉノードファイルのビットマップ領域に対応するｉノードナンバは用いられない。ｉノードファイルは５１２キロバイト刻みで拡張される。

【0074】

図１０はコンテナ複製からデータを読み込むクライアントを示すフローチャートである。図１０において、ＦＩＤ＝＜ＣＩＤ，Ｉｎｏｄｅ＃，Ｕｎｉｑｕｉｆｉｅｒ＞、ｏｆｆｓｅｔ、およびｌｅｎｇｔｈが入力される（１０００）。コンテナ位置がキャッシュされているかどうか決定が行われる（１００１）。キャッシュされているのならば、コンテナ複製ノードは抜き取られてリストから取り除かれ（１００３）、要求がデータをホスティングするノードに送られる（１００４、図１１参照）。コンテナが発見されたならば（１００８）、動作は成功する（１００９）。発見されないのならば、利用可能であればより多くの位置がチェックされ（１００７）、そうでないならばコンテナ位置がＣＬＤＢから検索される（１００２）。ＣＬＤＢから検索されたコンテナ位置は受信（ｒｅｃｅｉｐｔ）にキャッシュされる。位置が空ならば（１００５）、エラーであり（１００６）、そうでなければ、コンテナ複製ノードは抜き取られてリストから取り除かれ（１１０３）、処理は上記のように続行する。同様に、コンテナ位置がキャッシュされていないならば（１００１）、コンテナ位置はＣＬＤＢから検索されてキャッシュされる（１００２）。位置が空ならば（１００５）、エラーであり（１００６）、コンテナ複製ノードは抜き取られてリストから取り除かれ（１１０３）、処理は上記のように続行する。

【0075】

図１１はブロックを読み込むことによってサーバがファイルの領域をどのように読み込むかを示すフロー図である。領域内のバイトを含むブロックが読み込まれて、領域内の関心のある部分が結果へとコピーされる。図１１において、ＦＩＤ＝＜ＣＩＤ，Ｉｎｏｄｅ＃，Ｕｎｉｑｕｉｆｉｅｒ＞、ｏｆｆｓｅｔ、およびｌｅｎｇｔｈが入力される（１１００）。オフセットは８ｋの境界で切り捨てられ、ｌｅｎｇｔｈがチェックされて０を超えるかどうか決定される（１１０３）。もし超えないのならば、処理は完了する（１１０３）。そうでなければ、ブロックは現在のオフセットにおいて読み込まれ（１１０４、図１２を参照）、ブロックの一部が結果へとコピーされる（１１０５）。現在のオフセットはこのとき８ｋだけオフセットされており、ｌｅｎｇｔｈは８ｋだけ差し引かれ（１１０６）、処理が繰り返される。

【0076】

図１２はサーバがファイルからどのようにブロックを読み込むかを示すフローチャートである。すべてのファイルはファイルの最初の６４ＫＢへの直接のアクセスを可能にする。後のブロックへのアクセスは別のフロー図で記載される。図１２において、ＦＩＤ＝＜ＣＩＤ，Ｉｎｏｄｅ＃，Ｕｎｉｑｕｉｆｉｅｒ＞、ｏｆｆｓｅｔ、およびｌｅｎｇｔｈが入力される（１２００）。コンテナ位置はそのとき各記憶プールにおいて検索される（１２０１）。コンテナが発見されないならば（１２０２）、エラーであり、コンテナは存在しない（１２０３）。そうでなければ、ｉノードはｉノードファイルから読み込られる（１２０４）。一意性識別子（ｕｎｉｑｕｉｆｉｅｒ）が一致しないならば（１２０５）、エラーでありステイル（ｓｔａｌｅ）ＦＩＤである（１２０６）。そうでなければ、オフセットが検査されて６４ｋＢより小さいかどうか決定される。オフセットが６４ｋＢより小さくないならば、ファイルがローカルファイルかどうか決定が行われる（１２１２）。ローカルファイルならば、ファイルは読み込まれる（１２１３、図１３参照）。そうでなければ、チャンクファイルが読み込まれる（１２１４、図１４参照）。オフセットが６４ｋＢより小さいならば（１２０７）、直接のブロックナンバー［オフセット／８ｋ］から読み込みが行われる（１２０８）。ブロックが発見されたならば（１２０９）、動作は成功してブロックは戻される（１２１１）。そうでなければ、動作は成功したとみなされるが、ゼロで満たされたブロックが戻される（１２１０）。

【0077】

図１３はサーバがローカルファイルからどのようにブロックを読み込むかを示すフローチャートである。最初の６４キロバイトの後のブロックは、正しいブロッククラスタのアドレスを見つけるようにオフセットによってキー付けされた（ｋｅｙｅｄ）Ｂ木内を探すことによって読み込まれる。各ブロッククラスタは８つの個別の８キロバイトブロックからなる。図１３において、ローカルファイルブロックが読み込まれる（１３００）。ｉノードＢ木（１３０１）が［ｏｆｆｓｅｔ／６４ｋ］に等しいキーによって検索され、ブロッククラスタディスクリプタを見つける。クラスタが見つからなければ（１３０２）、動作は成功したものとされ、ゼロで満たされたブロックが戻される（１３０３）。そうでなければ、ブロック番号［ｏｆｆｓｅｔ／６４ｋ］を８で割った余りによって識別されたブロックがブロッククラスタから読み込まれる（１３０４）。ブロックが見つかったならば（１３０５）、操作は成功し、ブロックが戻される（１３０６）。そうでなければ、操作は成功したものとされ、ゼロで満たされたブロックが戻される（１３０７）。

【0078】

図１４はサーバがファイルチャンクからどのようにブロックを読み込むかを示すフロー図である。最初の６４キロバイトの後のブロックが、ローカルファイル内に記憶されたＦＩＤテーブルとして知られるＦＩＤの列内からＦＩＤを探すことによって読み込まれる。ＦＩＤテーブル内のＦＩＤのインデックスは、ファイルチャンク内のチャンクのサイズで所望のブロックのオフセットを除算し、その答えより小さく一番近い整数で丸めることによって決定される。ローカルファイルからどのように読み込むかについての詳細は図１３を参照のこと。各チャンクはｃｈｕｎｋ＿ｓｉｚｅのバイト数を有する１つのファイルチャンクを含む。ｃｈｕｎｋ＿ｓｉｚｅパラメータはファイルチャンクのｉノード内で定義される。チャンクからブロックを読み込むことは、ローカルファイルからブロックを読み込むための通常の方法に任せる。図１４において、ファイルチャンクブロックが読み込まれ、ｉノードおよびブロックオフセットが与えられる（１４００）。チャンクＦＩＤは、ｏｆｆｓｅｔ／ｃｈｕｎｋ＿ｓｉｚｅ以下であるかの指標ｆを用いてＦＩＤマップ内で検索される（１４０１、図１３参照）。チャンクが見つからなければ（１４０２）、動作は成功したものとされ、ゼロで満たされたブロックが戻される（１４０３）。そうでなければ、ＦＩＤによって指定されたブロックがオフセットモードのｃｈｕｎｋ＿ｓｉｚｅにおいてローカルファイルから読み込まれ（１４０４、図１４参照）、動作は成功したものとされ、所望のブロックが戻される（１４０５）。

【0079】

分散トランザクション
第一級のマップリデュースシステムは、あるファイルが単なるコンテナよりも大きくなることを要求し、ファイルが単なるコンテナの複製チェーンによって表現されるノードの組よりも多数のノード上に広がることを要求するため、単なるコンテナ複製は分散ファイルシステムにとって不十分である。分散ファイルシステムにおけるファイルチャンクはこの要求を満足するために用いられるが、ファイルチャンク上の非常に細かい（ｆｕｌｌ ａｔｏｍｉｃ）更新または追加のサポートにはマルチコンテナトランザクションが必要である。最も単純な場合には、ファイルチャンクおよびオリジナルのｉノードが協調的に更新されなければならない。より複雑な場合には、オリジナルのｉノードおよび複数のファイルチャンクがともに更新されなければならない。

【0080】

分散マルチノードトランザクションには複数の手法が存在するが、すべての従来のシステムは分散的な設定において深刻な欠陥を有する。例えば、Ｚｏｏｋｅｅｐｅｒはすべてのトランザクションが単純なマスタを介して行われることを要求することによって、マスタを指定する一定数の（ｑｕｏｒｕｍ）クラスタが常にあることを要求することによって、そしてすべての更新は一定数のノードによって受け入れられた２相コミットを用いてコミットすると要求することによって、トランザクションを取り扱う。時間をかけてトランザクション情報を管理する連続したチェーンがあるように、そして最新の情報を有しない一定数が生成されないように、一定数はクラスタ内のコンピュータの半分以上である。この手法は２つの問題を有する。第一に、一定数よりも少ないノードがまだ利用可能である場合に動作が不可能であり、第二に、すべての更新はマスタノードを介して行わなければならず、クラスタの引継ぎを妨害することなく１つ以上のマスタを有することは不可能である。これらのトレードオフはＺｏｏｋｅｅｐｅｒにかなり良い信用を与えているが、利用可能なノードが一定数より少ない場合は更新の受け入れに関してＺｏｏｋｅｅｐｅｒを拡張不可能で脆弱なものにする。

【0081】

従来の分散２相コミットシステムはまた、複数の故障に直面しての信頼できる動作の提供に問題がある。図１５は３つのノード、トランザクションマスタ１５０１と、補助（ｓｕｂｓｉｄｉａｒｙ）ノード１５０２および１５０３の間の相互作用の最中に、回復不可能なトランザクションを示すフロー図である。正確にどのノードがマスタでどのノードが補助であるかはトランザクションごとに変更することができ、補助ノード上で実施された動作は、ここで述べたことの一般性に影響を及ぼすことなく、補助ノード自身を分散トランザクションに関与させることができる。第１のステップは補助ノードへの開始トランザクション１５０４をマスタが送信することである。この時点で、このトランザクションの保護を受けたデータへのすべての変更には、そのデータにロック１５０５を行うことを含む。結局は、マスタはトランザクションへのコミット（またはロールバック）の開始を決め、補助ノードに準備コマンド１５０６を送信する。この例においてはこの時点で、すべての含まれるノードは、トランザクションがコミットに成功するかロールバックされるまで、すべてのロックを保つことを保証しなければならない。このシナリオでは、しかしながら、マスタから送信されたコミット１５０７はノードＡ１５０２に到達するが、ノード故障またはネットワーク分断のためにノードＢ１５０３への到達が阻止される。ノードＢはトランザクションにコミットし、そのトランザクションのログを取り除く。マスタは、しかしながら、現時点で到達していないコミットが完了した旨のＣからの確認を待たねばならない。ここでマスタが故障してノードＣが復帰した場合、ノードＣはマスタからのトランザクションの状態の発見１５０８が不可能であり、トランザクションをコミットするべきかアボートすべきかわからないため不安定な状態にとどまっている。それはトランザクションをアボートすることができず、マスタのみが持っている情報なしにトランザクションにコミットすることもできない。したがって、ノードＣはこのトランザクションに関連するすべてのログおよびロックを、マスタが決して復帰しない場合には永久に、保持しなければならない。

【0082】

図１６は故障によって影響を受けないトランザクションを示すフロー図である。図１６において、マスタノード１６０１は補助ノードＡ１６０２上の参照を、補助ノードＢ１６０３上の新しいデータに書き込むことを意図している。動作の後に、関与するノードの一時的あるいは恒久的な故障または分断にかかわらず、Ａ上の参照とＢ上のデータが存在すべきか、Ａ上の参照とＢ上のデータのいずれも存在すべきでないか、のいずれかである。いくつかの実施例または状況において補助ノードＡまたはＢあるいはその両方は、一般性を失うことなくマスタノードと同じノードである。同様に、複数の補助ノードが、ノードの別の組にあるデータへの参照が存在するノードの組に分割可能である限り、ここに示された概略例は、ここに示されたよりも多くの補助ノードを含んでもよい。一般性を失うことなく、マスタ１６０１、ノードＡ１６０２、およびノードＢ１６０３がそれぞれ単一のノードである場合を記載する。当業者はこの限定的な記載を、より一般的な形態として解釈することができるであろう。

【0083】

このトランザクションが実施される方式は、マスタノード１６０１がデータ１６０４を補助ノードＢ１６０３に最初に書き込むことである。データは補助ノードＢ上のトランザクションログに書き込まれ、トランザクション１６０５は、補助ノードＡ上の参照が後で発見されない場合、書き込みの効果を逆転されるオーファナージ（ｏｒｐｈａｎａｇｅ）に書き込まれる。トランザクションログへの更新およびオーファナージへの更新はアトミックに行われる。補助ノード１６０３はそれから参照１６０６を、マスタノードに新しく書き込まれたデータへ戻す。それからこの参照は、補助ノードＡ１６０２への送信１６０７となる。データがノードＢ上で生成された場合、１６０８においてバックグラウンドスレッドが開始されるか、クリーンアップイベントがスケジューリングされ、オリジナルの書き込みが行われたかなり後の時点で、ノードＢにオーファナージを検査させる。オーファナージのエントリは１６０９においてノードＢにノードＡを検査させるか、またはノードＡの複製の１つに、ノードＢ上に書き込まれたデータへの参照が存在するかどうか確認させる。参照が存在する場合は、動作は起こらない。参照が存在しない場合は、Ｂ上のトランザクション１６０５において生成されたオーファナージのエントリは、データ１６０４のオリジナルの書き込みの効果を反転させる動作を行う。ノードＡ上の参照が生成されない場合は、ノードＢ上の新しいデータはアクセス可能にはならず、したがって効果は、参照およびデータがアトミックに出現するか決して出現しないかとなる。

【0084】

妨害されているトランザクションの不変条件がなければ、故障はこの過程の任意の点で発生しうる。オリジナルの書き込み１６０４および１６０５の前の故障は、マスタノードが新しいデータへの参照を受信することを妨げ、ノードＢ上のデータのいかなる変更にもつながらず、したがっていかなる変更または参照も引き起こさない。書き込み１６０４または１６０５の後で、参照が１６０６に戻る前の故障は、参照がノードＡ上に挿入されることを阻止するが、オーファナージは結局はデータ書き込みを未成（ｕｎｄｏｎｅ）にする。参照を受信した後でノードＡへの送信１６０７の前のマスタノードの故障、または参照が持続する前のノードＡの故障は、バックグラウンドスレッド１６０８によって結局は解決される。バックグラウンドスレッド１６０８がノードＡの複製の１つにおいて参照を発見するので、参照が書き込まれた後のノードＡの故障は処理される。ノードＡおよびすべてのノードＡの複製の故障によってすべての複製が失われた場合、データは消去される。バックグラウンドスレッドが起動される前にノードＢが故障した場合、複製チェーンの他のノードが解決タスクを実行する。

【0085】

この形態のトランザクションが分散ファイルシステムに役立つ理由の１つは、何らかの部分的な更新が該ファイルシステムの状態にユーザから見える変化を起こすことがないように、該ファイルシステムへのすべての分散的な更新が、従属関係に応じてトポロジー的にソートされることができることである。多くの場合において、トランザクションに含まれるノードを、新しいデータへの新しい参照を含むいくつかのノードと、新しいデータを含む他のノードと、からなる二分された組に分割することは、このトポロジー的なソートの要請を自明に満足する。このトポロジー的なソートの基準は、例えば、相関的データベースの更新の一般的な場合には当てはまらない。なぜなら、従属関係が外部の意味的制約に基づいているために、常に明らかであるとは限らないからである。このことは、分散ファイルシステムの分散トランザクションは、ある意味では、従来型の２相コミットよりも弱いことを意味する。その一方で、この新規な形式の分散トランザクションを分散ファイルシステムが用いることを可能にするために必要な動作の組は、より限定されている。

【0086】

分散ボリュームスナップショット
分散トランザクションの１つの特に重要な形態は、多数のコンテナにまたがるディレクトリおよびファイルを含むファイルシステムボリュームのスナップショットの生成である。これは従来のファイルシステムでは困難であり、通常は分散アップデートを避けることによって（例えばＡＦＳ）、あるいは集中型ロッキングプロトコルを用いることによって（例えばＧＦＳ）実装される。複製の欠如は、シングルポイントの故障が多く、大きなクラスタにおいて性能が低いシステムをもたらす。集中型ロッキングプロトコルは性能を限定し、特に高速度でのファイル生成に関して限定する。また、性能に深刻な影響を与えることなくアクティブなファイルシステム上で分散スナップショットを作成することを非常に困難にする。ここで開示された分散ファイルシステムにおいて、分散トランザクションおよびコンテナスナップショットは、性能に大きな影響を与えることなく、また、大規模分散データ構造のロッキングを必要とすることなく、分散スナップショットを実装するために用いられる。

【0087】

分散ファイルシステムが分散スナップショットを実装する方法は、ボリュームに関するすべてのデータおよびメタデータを、単一のネームコンテナおよびゼロ個以上のデータコンテナにまとめることである。加えて、システムはデータへのすべてのコンテナ間参照（ｃｒｏｓｓ−ｃｏｎｔａｉｎｅｒ ｒｅｆｅｒｅｎｃｅ）を、データコンテナ内にデータのすべてを保ちながらネームコンテナへと分離する。このシステムは、当業者に知られている標準的な手法を用いて１つ以上のネームコンテナを用いるように一般化することができる。

【0088】

１つのデータコンテナから別のデータコンテナへのすべての参照がネームボリューム内のデータ構造によって仲介され、ボリュームスナップショットは、ネームコンテナのスナップショットを最初に生成し、次にデータコンテナのスナップショットを生成するように進行する。データコンテナに挿入されるデータ構造は、コンテナに名前をつけるデータ構造からデータコンテナへの参照を有するにすぎず、該参照はネームコンテナのスナップショットの前または後に生成されなければならない。参照がネームコンテナのスナップショット内に存在する場合、データはより早い時間に存在していなければならず、したがって、該ネームコンテナのスナップショットの後でとられたいかなるデータコンテナのスナップショットも、参照を未解決のままにさせないデータを有する。どのコンテナがスナップショット内に含まれるかに関する混乱を防止するため、コンテナ位置データベースは、スナップショットの生成の最中には、ボリュームに関する新しいコンテナの追加を阻止してもよい。代替として、ネームコンテナはデータコンテナへの必要な参照を含んでもよく、それは、ひとたびネームコンテナがスナップショットをとられると、スナップショットをとられる必要があるデータコンテナのセットがフリーズすることを意味する。

【0089】

図１７は、ファイルチャンクに関する参照の構造を示すブロック概略図である。図１７において、ファイルチャンクを記述するｉノード１７０２を指示するディレクトリエントリ１７０１の最終状態がある。ファイルチャンクに関するｉノード１７０２はＦＩＤマップ１７０３を参照する。ＦＩＤマップ１７０３は、ファイルデータを実際に含むローカルファイル１７０４への参照を有する。ディレクトリエントリ１７０１およびＦＩＤマップ１７０３はネームコンテナ１７０５内にある。ｉノード１７０２およびローカルファイル１７０４は１つ以上のデータコンテナ１７０６内にある。ネームコンテナスナップショット内のボリュームディレクトリルートまたはほかのサーチルートから推移的にアクセス可能なすべての参照が有効なターゲットを有しなければならない場合、ボリュームスナップショット全体における参照のインテグリティは保証される。

【0090】

分散システムにおける分散トランザクションは参照が持続する前に参照のターゲットが存在することを保証するので、起こりうる最悪のことは、ボリュームルートディレクトリからデータ構造体への直接または間接の参照が全くないために、トランジション的にアクセス不可能なデータ構造をスナップショットが含むことである。図１７において、例えば、ＦＩＤマップ１７０３からローカルファイル１７０４への参照は、ローカルファイル１７０４がすでに存在する場合にのみ存在しうる。ネームコンテナのスナップショットはデータコンテナのスナップショットの前に生成されるため、参照はネームコンテナ内に存在しないか、そうでなければ、参照がネームコンテナのスナップショット内に存在してかつローカルファイルがデータコンテナのスナップショット内に存在する。

【0091】

同様に、ファイルチャンクｉノード１７０２を生成する分散トランザクションは、ＦＩＤマップ１７０３が最初にネームコンテナ内に存在することを保証し、ファイルチャンクｉノードへのディレクトリ参照１７０１を生成するトランザクションは、ファイルチャンクｉノードがすでに存在する場合にのみディレクトリ参照１７０１が存在することを保証する。このことは、ファイルチャンクｉノード１７０２へのディレクトリ参照１７０１が生成される前にＦＩＤマップが存在することを推移的に示す。したがって、ＦＩＤマップ１７０３がネームコンテナのスナップショット内にない場合、ディレクトリ参照１７０１もまたネームコンテナのスナップショット内にはありえず、チャンクファイルｉノード１７０２の存在による、参照のインテグリティに対するいかなる潜在的な妨害も、視野から隠される。

【0092】

当業者は本分散ファイルシステム内のすべての参照チェーンに関して、同様のロジックのチェーンを導き出すことができる。特に、ネームコンテナは多くの娘ネームコンテナを参照することができ、娘ネームコンテナが親ネームコンテナ内に見えるようにされる前に、娘ネームコンテナ内にメタデータが生成されるという同様の制約を伴う。これによって、単一ボリュームの内部の分散ディレクトリは、ネームコンテナの階層化を用いて構築され、該ネームコンテナはトランザクション的にも、分散においてスナップショットをとられている際にも、すべて整合がとれている。

【0093】

ＮＦＳゲートウェイ
分散ファイルシステムは、トークンまたは他の状態に基づく機構をロックする必要なしに、読み書きアクセスを提供する。このことは、ランダムな更新および読み込みが、クラスタ内の任意のノードまたは、クラスタ内のコンピュータへの自由なアクセスを有する任意のコンピュータから起こることを意味する。

【0094】

分散ファイルシステムへのアクセスのステートレスな特性は、ＮＦＳなどのネットワークプロトコルを介した分散ファイルシステムへのアクセスを提供することがかなり容易であることを意味する。図１８は、クラスタに関するＮＦＳゲートウェイの動作を示すブロック概略図である。このシステムにおいて、ＮＦＳクライアント１８０１はランダムに選択されたバーチャルＩＰアドレス１８０２に接続する。各バーチャルＩＰアドレス１８０２はＮＦＳゲートウェイ１８０３の１つによってホスティングされ、バーチャルＩＰアドレスへの接続が、ＮＦＳゲートウェイの１つへの接続を実際に行わせる。ＮＦＳゲートウェイは調整サーバ１８０４を用いて、どのゲートウェイがどのＩＰアドレスをホスティングするのかを協働的に決める。調整サービスはＡｐａｃｈｅ Ｚｏｏｋｅｅｐｅｒなどのシステムを用いる一実施形態において実装される。そのような調整サービスの使用は、単独のゲートウェイへの各バーチャルＩＰアドレスの信頼できる割り当てを可能にし、各ゲートウェイができる限り少ないバーチャルＩＰアドレスにサービスすることを確実にする。ファイルの生成、ファイルメタデータへのアクセス、またはファイル領域の読み込みまたは更新の要請に応じて、ＮＦＳゲートウェイはクラスタ１８０５によってホスティングされた分散ファイルシステムに同様の要請を行う。ＮＦＳゲートウェイはクラスタとは別のコンピュータ上で、またはクラスタの一部であるコンピュータ上でホスティングされることができる。

【0095】

すべてのＮＦＳサーバは分散ファイルシステム内のすべてのファイルにアクセス可能であるため、ＮＦＳゲートウェイは完全にステートレスである。このことは、１つのＮＦＳゲートウェイが故障した場合、そのゲートウェイによって使用されていたバーチャルＩＰアドレスが別のゲートウェイに再割り当て可能であり、動作は無駄なくリトライ可能であることを意味する。故障したゲートウェイの喪失が検出されバーチャルＩＰが再割り当てされる間の遅延以外は、ＮＦＳクライアントは故障の検出さえできない。ＮＦＳゲートウェイ内のロックを別のＮＦＳゲートウェイに転送することが困難か高コストでありうるため、そのような故障寛容性はそのようなロックを維持するシステムを提供することを困難にしうる。

【0096】

そのようなシステムは分散ファイルシステムへの均一なＮＦＳアクセスを提供しうる。分散ファイルシステムとＮＦＳゲートウェイとの組み合わせの結果としていくつかの利点が生じる。１つの利点は、ファイル読み書き帯域幅の総計が、クラスタのサイズによって課せられていた制限を超えてＮＦＳゲートウェイの数に対応可能となることである。ファイルの生成または削除の速度の総計も同様に対応する。

【0097】

別の利点は、クラスタ内のファイルに名前をつける際の慣習に関する。分散ファイルシステムＡＰＩによってアクセスされるすべてのファイル名は、例えば、プレフィックス ／ｍａｐｒ／ から始まり、その後ろに、クラスタ名、スラッシュ、およびそのクラスタ内のファイルの名前が続く。ＮＦＳゲートウェイは、それらに対してアクセス可能なクラスタのすべてに関して知っているので、それらは各アクセス可能なクラスタに対応するバーチャルファイルを、トップレベル ／ｍａｐｒ バーチャルディレクトリに表示させることができる。各ＮＦＳゲートウェイは ／ｍａｐｒ ファイルシステムの下のこれらのバーチャルクラスタディレクトリをエクスポートする。ディレクトリ ／ｍａｐｒ 上のローカルファイルシステム上のＮＦＳファイルシステムがＮＦＳクライアントによってマウントされる場合、ＮＦＳクライアントマシン上でローカルに実行されるプログラムは、クラスタの使用において実行されるＨａｄｏｏｐプログラムと正確に同じパス名を用いることができる。このことは実質的に、従来のシーケンシャルな要素をマップリデュースに基づく要素と組み合わせるプログラムおよびスクリプトを簡易にする。

【0098】

本発明は好ましい実施形態を参照して本明細書に記載されるが、本発明の精神および範囲から逸脱することなく、他の応用例が本明細書に記載されたものと置換可能であることを当業者は容易に理解するであろう。したがって、本発明は以下に記載された特許請求の範囲にのみ制限されるべきである。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】