特許 6364083 コンセンサスノードを用いた分散ファイルシステム

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

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

(11)【特許番号】6364083

(24)【登録日】2018年7月6日

(45)【発行日】2018年7月25日

(54)【発明の名称】コンセンサスノードを用いた分散ファイルシステム

(51)【国際特許分類】

   G06F 12/00 20060101AFI20180712BHJP

【ＦＩ】

   G06F12/00 545B

   G06F12/00 533J

【請求項の数】49

【全頁数】27

(21)【出願番号】特願2016-537893(P2016-537893)

(86)(22)【出願日】2014年8月29日

(65)【公表番号】特表2016-530636(P2016-530636A)

(43)【公表日】2016年9月29日

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

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

(87)【国際公開日】20150305

【審査請求日】2017年8月16日

(31)【優先権主張番号】14/013,948

(32)【優先日】2013年8月29日

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

(73)【特許権者】

【識別番号】515154894

【氏名又は名称】ワンディスコ，インク．

(74)【代理人】

【識別番号】100115738

【弁理士】

【氏名又は名称】鷲頭 光宏

(74)【代理人】

【識別番号】100121681

【弁理士】

【氏名又は名称】緒方 和文

(74)【代理人】

【識別番号】100130982

【弁理士】

【氏名又は名称】黒瀬 泰之

(72)【発明者】

【氏名】シュヴァチェコ コンスタンチン ブイ

(72)【発明者】

【氏名】サンダー ジェーガネ

(72)【発明者】

【氏名】パーキン マイケル

(72)【発明者】

【氏名】アーラット イエツール

【審査官】 宮司 卓佳

(56)【参考文献】

【文献】 特開２００８−２３４５６８（ＪＰ，Ａ）

【文献】 特開平１０−１８７５２４（ＪＰ，Ａ）

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

【文献】 米国特許第０６０１４６８６（ＵＳ，Ａ）

【文献】 特開平１０−０７８９４４（ＪＰ，Ａ）

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

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

Ｇ０６Ｆ １２／００

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

【請求項1】

分散ファイルシステムを実行するように構成された複数のコンピュータ装置を備えるノードのクラスタであって、
複数のデータノードと、
少なくとも２つのネームノードと、
前記少なくとも２つのネームノードのそれぞれと結合された調整エンジンとを備え、
前記複数のデータノードはそれぞれ、クライアントファイルのデータブロックを格納するように構成され、
前記少なくとも２つのネームノードはそれぞれ、前記複数のデータノードに結合され、前記クラスタのネームスペースの状態を格納するように構成され、かつ、他のネームノードが他のクライアントからの他の要求に応じるのと同時にクライアントからの要求に応答するように構成され、
前記調整エンジンは、前記ネームスペースの前記状態の変更についての前記ネームノードからの提案を受信し、それに応じて、前記少なくとも２つのネームノードによる前記ネームスペースの状態変更の順序を特定する順序付けられた一組の合意を生成するよう構成され、
前記少なくとも２つのネームノードは、前記順序付けられた一組の合意を前記調整エンジンから受信するまでの間、前記ネームスペースの状態に変更を加えることを遅らせるよう構成される
ノードのクラスタ。

【請求項2】

前記少なくとも２つのネームノードはそれぞれ、クライアントが前記データノード内の前記データブロックを複製すること及び削除することの少なくとも一方に対する要求を発行したことに応じて、提案を生成するように構成される
請求項１に記載のノードのクラスタ。

【請求項3】

前記調整エンジンは、一意的なグローバルシーケンス番号を前記一組の合意のそれぞれに割り当てるようにさらに構成され、
前記グローバルシーケンス番号は、前記少なくとも２つのネームノードが前記ネームスペースの前記状態に対して変更を適用する順序を特定する
請求項１に記載のクラスタ。

【請求項4】

前記ネームノードは、前記ネームスペースの前記状態に対し、前記受信された合意の前記グローバルシーケンス番号によって特定される前記順序で前記変更を適用するようにさらに構成される
請求項３に記載のクラスタ。

【請求項5】

前記少なくとも２つのネームノードのそれぞれに結合されたローカル記憶装置をさらに備え、
前記ローカル記憶装置は、前記ネームスペースのイメージと、格納された前記イメージに対する更新を特定するエントリとを格納するように構成される
請求項１に記載のクラスタ。

【請求項6】

前記クラスタ内において、１つの前記ネームノードだけが、前記複数のデータノードに格納されたデータブロックを複製及び削除できるように構成される
請求項１に記載のクラスタ。

【請求項7】

データブロックを複製及び削除できるように構成された前記ネームノードは、ブロック複製器ハートビートメッセージを周期的に発行するようにさらに構成される
請求項６に記載のクラスタ。

【請求項8】

データブロックを複製及び削除できるように構成された前記ネームノードが前記ブロック複製器ハートビートの周期的な発行に失敗することは、データブロックを複製及び削除できるように単独で構成されるべき新たなネームノードを選定するための選定プロセスを開始させる
請求項７に記載のクラスタ。

【請求項9】

前記選定プロセスは、前記少なくとも２つのネームノードのいずれかによって開始されるように構成される
請求項８に記載のクラスタ。

【請求項10】

前記少なくとも２つのネームノードのそれぞれは、データブロックが前記複数のデータノードにおいて生成され及び格納されることを可能とするように構成される
請求項１に記載のクラスタ。

【請求項11】

前記少なくとも２つのネームノードのそれぞれは、前記複数のデータノードのうちの１つに格納されたデータブロックが、前記複数のデータノードのうちの所定の他の１つ又は複数に複製されることを可能とするように構成される
請求項１に記載のクラスタ。

【請求項12】

前記複数のデータノードのうちの少なくとも１つは、データブロックの受信に応じて、前記少なくとも２つのネームノードのうちの１つによって識別される前記複数のデータノードうちの別の１つに対して前記データブロックを送信するように構成される
請求項１１に記載のクラスタ。

【請求項13】

前記複数のデータノードのそれぞれは、当該データノードの現在の状態を示すハートビートメッセージを、前記少なくとも２つのネームノードに対して周期的に発行するように構成される
請求項１に記載のクラスタ。

【請求項14】

前記少なくとも２つのネームノードは、前記周期的なハートビートがタイムリーに受信されなかったデータノードについて、障害を起こしたとみなすようにさらに構成される
請求項１３に記載のクラスタ。

【請求項15】

前記少なくとも２つのネームノードのうちの１つは、障害を起こしたデータノードに格納されるデータブロックが、前記複数のデータノードのうちの選択された別の１つに複製される原因となるようにさらに構成される
請求項１に記載のクラスタ。

【請求項16】

前記少なくとも２つのネームノードのそれぞれは、データブロックに対し、ブロック識別子のより大きな範囲の一部分である部分範囲から一意的なブロック識別子を割り当てるように構成され、
前記部分範囲は、前記少なくとも２つのネームノードのうちの他の複数がそこから前記ブロック識別子を割り当てる、前記ブロック識別子の前記より大きな範囲のそれぞれ他の一部分である複数の部分範囲とは別の範囲である
請求項１に記載のクラスタ。

【請求項17】

通信タイムアウトをさらに備え、
前記通信タイムアウトは、もしクライアント要求を受信したネームノードが前記通信タイムアウトの満了時に前記クライアント要求に応答しなかった場合、前記クライアント要求が前記少なくとも２つのネームノードのうちの別のネームノードに対してなされるように構成される
請求項１に記載のクラスタ。

【請求項18】

前記クラスタ内の前記少なくとも２つのネームノードのすべては、同時にクライアント要求を積極的にサポートするように構成される
請求項１に記載のクラスタ。

【請求項19】

前記少なくとも２つのネームノードのうちの１つが障害を起こしたことに応じて、障害を起こした前記ネームノードに対してそれまでに生成されたクライアント要求が、前記少なくとも２つのネームノードの他の１つに対して生成される
請求項１に記載のクラスタ。

【請求項20】

前記クライアントは、前記少なくとも２つのネームノードの前記他の１つに対してクライアント要求を行う前に、前記他の１つが自身のネームスペースを更新するまで待機するように構成される
請求項１９に記載のクラスタ。

【請求項21】

前記ネームノードのそれぞれは、古くなった読み出しを防止するため、選択されたファイル名パターンを満足すると判定されたファイルの読み出し要求が受信されたときに前記調整エンジンに対して調整された読み出し提案を提出し、前記調整された読み出し提案に対応する合意が受信された場合にのみ前記ファイルが読み出されることを可能とするよう構成される
請求項１に記載のクラスタ。

【請求項22】

新しいネームノードが前記クラスタ内にもたらされることを可能とするようにさらに構成され、
前記新しいネームノードは、前記ネームスペースの以前のイメージを備えるチェックポイントをロードすること、及び、前記調整エンジンから自身のネームスペースに対する合意を受け入れることの少なくとも一方によって、自身のネームスペースの状態を更新するように構成される
請求項１に記載のクラスタ。

【請求項23】

前記ネームスペースの前記状態を変更するための前記提案は、前記複数のデータノードのうちの少なくとも１つにおけるデータブロックの複製、削除、付加のうちの少なくとも１つを含む
請求項１に記載のクラスタ。

【請求項24】

クライアントファイルのデータブロックを格納するように構成された複数のデータノードを備える分散ファイルシステムを実行するコンピュータ実行方法であって、
少なくとも２つのネームノードを複数のデータノードに結合することを備え、
前記少なくとも２つのネームノードのそれぞれは、クラスタのネームスペースの状態を格納するように構成され、かつ、前記少なくとも２つのネームノードのうちの他の一つが他のクライアントからの他の要求に応じるのと同時にクライアントからの要求に応答するように構成され、
前記コンピュータ実行方法はさらに、
前記ネームスペースの前記状態の変更についての提案を前記ネームノードから受信すること、及び、
前記提案を受信したことに応じて、前記少なくとも２つのネームノードによる前記ネームスペースの状態変更の順序を特定する順序付けられた一組の合意を生成し、それによって、前記少なくとも２つのネームノードが、前記順序付けられた一組の合意を受信するまでの間、前記ネームスペースの状態に変更を加えることを遅らせること
を備えるコンピュータ実行方法。

【請求項25】

前記少なくとも２つのネームノードが、前記データノードにおけるデータブロックの複製及び削除の少なくとも一方についての要求をクライアントが発行したことに応じて前記提案を生成すること
をさらに備える請求項２４に記載のコンピュータ実行方法。

【請求項26】

前記順序付けられた一組の合意の各合意に対して一意的なグローバルシーケンス番号を割り当てることをさらに備え、
前記グローバルシーケンス番号は、前記少なくとも２つのネームノードが前記ネームスペースの前記状態に対して変更を適用する順序を特定する
請求項２４に記載のコンピュータ実行方法。

【請求項27】

前記少なくとも２つのネームノードが、前記受信された合意の前記グローバルシーケンス番号によって特定される順序で、前記ネームスペースの前記状態に変更を適用すること
をさらに備える請求項２６に記載のコンピュータ実行方法。

【請求項28】

前記ネームスペースのイメージと、前記ネームスペースに対する更新を特定するエントリとを、前記少なくとも２つのネームノードのそれぞれに結合されたローカル記憶装置に格納すること
をさらに備える請求項２４に記載のコンピュータ実行方法。

【請求項29】

前記クラスタ内で１つのネームノードだけを、前記複数のデータノードに格納されたデータブロックを複製又は削除できるように構成するステップをさらに備える
請求項２４に記載のコンピュータ実行方法。

【請求項30】

ブロック複製器ハートビートメッセージを周期的に発行するよう、データブロックを複製及び削除できるように構成された前記ネームノードを構成すること
をさらに備える請求項２９に記載のコンピュータ実行方法。

【請求項31】

データブロックを複製及び削除できるように構成された前記ネームノードが前記ブロック複製器ハートビートの周期的な発行に失敗したことに応じて、データブロックを複製及び削除できるように単独で構成されるべき新たなネームノードを選定するための選定プロセスを開始すること
をさらに備える請求項３０に記載のコンピュータ実行方法。

【請求項32】

前記選定プロセスは、前記少なくとも２つのネームノードのいずれかによって開始されるように構成される
請求項３１に記載の方法。

【請求項33】

データブロックが前記複数のデータノードにおいて生成され及び格納されることを可能とするように前記少なくとも２つのネームノードのそれぞれを構成すること
をさらに備える請求項２４に記載のコンピュータ実行方法。

【請求項34】

前記複数のデータノードのうちの１つに格納されたデータブロックが、前記複数のデータノードのうちの所定の他の１つ又は複数に複製されることを可能とするように、前記少なくとも２つのネームノードのそれぞれを構成すること
をさらに備える請求項２４に記載のコンピュータ実行方法。

【請求項35】

データブロックの受信に応じて、前記少なくとも２つのネームノードのうちの１つによって識別される前記複数のデータノードうちの別の１つに対して前記データブロックを送信するように、前記複数のデータノードのうちの少なくとも１つを構成すること
をさらに備える請求項３４に記載のコンピュータ実行方法。

【請求項36】

前記データノードの現在の状態を示すハートビートメッセージを、前記少なくとも２つのネームノードに周期的に発行するように、前記複数のデータノードのそれぞれを構成すること
をさらに備える請求項２４に記載のコンピュータ実行方法。

【請求項37】

前記周期的なハートビートがタイムリーに受信されなかったデータノードについて、障害を起こしたとみなすように、前記少なくとも２つのネームノードを構成すること
をさらに備える請求項３６に記載のコンピュータ実行方法。

【請求項38】

障害を起こしたデータノードに格納されるデータブロックが、前記複数のデータノードのうちの選択された別の１つに複製されることを可能するように前記少なくとも２つのネームノードのうちの１つだけを構成すること
をさらに備える請求項２４に記載のコンピュータ実行方法。

【請求項39】

データブロックに対し、ブロック識別子のより大きな範囲の一部分である部分範囲から一意的なブロック識別子を割り当てるよう前記少なくとも２つのネームノードのそれぞれ構成することをさらに備え、
前記部分範囲は、前記少なくとも２つのネームノードのうちの他の複数がそこから前記ブロック識別子を割り当てる、前記ブロック識別子の前記より大きな範囲のそれぞれ他の一部分である複数の部分範囲とは別の範囲である
請求項２４に記載のコンピュータ実行方法。

【請求項40】

通信タイムアウトを設定することをさらにに備え、
前記通信タイムアウトは、もしクライアント要求を受信したネームノードが前記通信タイムアウトの満了時に前記クライアント要求に応答しなかった場合、前記クライアント要求が前記少なくとも２つのネームノードのうちの別のネームノードに対してなされるように構成される
請求項２４に記載のコンピュータ実行方法。

【請求項41】

前記クラスタ内の前記少なくとも２つのネームノードのすべてが、同時にクライアント要求を積極的にサポートすることを可能とすること
をさらに備える請求項２４に記載のコンピュータ実行方法。

【請求項42】

前記少なくとも２つのネームノードのうちの１つが障害を起こしたことに応じて、障害を起こした前記ネームノードに対してそれまでに生成されたクライアント要求を、前記少なくとも２つのネームノードの他の１つに対して生成する
請求項２４に記載のコンピュータ実行方法。

【請求項43】

前記少なくとも２つのネームノードの前記他の１つに対してクライアント要求を行う前に、前記他の１つが自身のネームスペースを更新するまで待機する
請求項４２に記載のコンピュータ実行方法。

【請求項44】

前記ネームノードのそれぞれが、古くなった読み出しを防止するため、選択されたファイル名パターンを満足すると判定されたファイルの読み出し要求が受信されたときに調整エンジンに対して調整された読み出し提案を提出し、前記調整された読み出し提案に対応する合意が受信された場合にのみ前記ファイルが読み出されることを可能とすること
をさらに備える請求項２４に記載のコンピュータ実行方法。

【請求項45】

新しいネームノードが前記クラスタ内にもたらされることを可能とすることをさらに備え、
前記新しいネームノードは、前記ネームスペースの以前のイメージを備えるチェックポイントをロードすること、及び、調整エンジンから自身のネームスペースに対する合意を受け入れることの少なくとも一方によって、自身のネームスペースの状態を更新するように構成される
請求項２４に記載のコンピュータ実行方法。

【請求項46】

コンピュータ装置によって実行されたときに前記コンピュータ装置に分散ファイルシステムを実行させる一連の命令を表すデータを格納する非一時的なマシン可読媒体であって、
前記一連の命令は、少なくとも２つのネームノードを複数のデータノードに結合することを前記コンピュータ装置に実行させ、
前記少なくとも２つのネームノードのそれぞれは、クラスタのネームスペースの状態を格納するように構成され、かつ、前記少なくとも２つのネームノードのうちの他の一つが他のクライアントからの他の要求に応じるのと同時にクライアントからの要求に応答するように構成され、
前記一連の命令はさらに、
前記複数のデータノードのうちの少なくとも１つにおいてデータブロックの置換、削除、及び追加の少なくとも１つを行うことによる前記ネームスペースの前記状態の変更についての提案を前記ネームノードから受信すること、及び、
前記提案を受信したことに応じて、前記少なくとも２つのネームノードによる前記ネームスペースの状態変更の順序を特定する順序付けられた一組の合意を生成し、それによって、前記少なくとも２つのネームノードが、前記順序付けられた一組の合意を受信するまでの間、前記ネームスペースの状態に変更を加えることを遅らせること
を前記コンピュータ装置に実行させる
非一時的なマシン可読媒体。

【請求項47】

分散ファイルシステムの一部分として構成されるコンピュータ装置であって、
複数のデータノードに結合された第１のネームノードと、
前記第１のネームノードに結合された調整エンジンとを備え、
前記複数のデータノードのそれぞれは、クライアントファイルのデータブロックを格納するように構成され、
前記第１のネームノードは、コンピューティングノードのクラスタのネームスペースの状態を格納するように構成され、
前記第１のネームノードは、前記複数のデータノードに結合され、かつ前記ネームスペースの前記状態を格納するように構成される第２のネームノードに結合されるように構成され、
前記第１のネームノードは、前記第２のネームノードが他のクライアントからの他の要求に応じるのと同時にクライアントからの要求に応答するよう構成され、
前記調整エンジンは、前記ネームスペースの前記状態の変更についての前記第１のネームノードからの提案を受信し、かつ、それに応じて、前記第１及び第２のネームノードによる前記ネームスペースの状態変更の順序を特定する順序付けられた一組の合意を生成するよう構成される
コンピュータ装置。

【請求項48】

前記第１のネームノードは、前記調整エンジンから前記順序付けられた一組の合意を受信するまでの間、前記ネームスペースの状態に変更を加えることを遅らせるように構成される
請求項４７に記載のコンピュータ装置。

【請求項49】

前記ネームスペースの前記状態の変更についての前記提案は、前記複数のデータノードのうちの少なくとも１つにおいてデータブロックの置換、削除、及び追加の少なくとも１つを行うことを含む
請求項４７に記載のコンピュータ装置。

【発明の詳細な説明】

【背景技術】

【0001】

ハドゥープ（Ｈａｄｏｏｐ）分散ファイルシステム（ＨＤＦＳ）のネームスペースは、ファイル及びディレクトリの階層である。ファイル及びディレクトリは、Ｉノードによりネームノード上に表される。Ｉノードレコードは、許可、修正、アクセス時間、ネームスペース、及びディスクスペース割り当てなどを属性とする。ファイルコンテンツは、大きなデータブロック（通常１２８ＭＢ）に分割され、かつファイルの各データブロックは、複数のデータノード（通常３つ）で独立に複製される。ネームノードは、ＨＤＦＳのメタデータサービスであり、これは、ネームスペース動作を担っている。ネームノードは、ネームスペース・ツリー、及び、データノードに対するブロックのマッピングを維持する。すなわち、ネームノードは、ハドゥープクラスタ内でデータの場所を追跡し、かつハドゥープクラスタへのクライアントアクセスを調整する。従来、各クラスタは、単一のネームノードを有する。クラスタは、１クラスタ当たり、何千ものデータノード、及び何万ものＨＤＦＳクライアントを有することが可能であるが、その理由は、各データノードが、複数のアプリケーションタスクを同時に実行するかもしれないからである。ネームシステムのメタデータを定義するＩノード及びデータブロックのリストは、イメージと呼ばれる。ネームノードは、ネームスペース・イメージ全体をＲＡＭに保管する。イメージの持続的なレコードは、ネームノードの局所的な本来のファイルシステムに、チェックポイントとして格納される。ここでチェックポイントには、それが作られて以来、実施されたネームスペースに対する更新を表すジャーナルが加えられる。

【0002】

分散システムは、ノードと呼ばれる色々な構成要素から成る。システムの一貫性を維持するために、ノード間に分散した様々なイベントを調整することが必要となるかもしれない。すべてのノードが一貫して学習しなければならない特別なイベントを調整するための最も簡単な方法は、指定された単一のマスターを選択し、かつマスター上にそのイベントを記録することであり、その結果として、他のノードは、マスターからイベントを学習してもよい。簡単ではあるが、このアプローチは信頼性に欠ける。その理由は、単一のマスターの障害がシステム全体の進行を停止するからである。この認識において、かつ図１に示すように、従来のＨＤＦＳ実行は、通常動作の間にアクセスされるアクティブ・ネームノード１０２と、スタンバイ・ネームノード１０４と呼ばれるバックアップとを使用する。ここでスタンバイ・ネームノード１０４は、アクティブ・ネームノード１０２の障害の場合におけるフェイルオーバーとして使用される。

【先行技術文献】

【非特許文献】

【0003】

【非特許文献1】Ｌａｍｐｏｒｔ，Ｌ．、「Ｔｈｅ Ｐａｒｔ Ｔｉｍｅ Ｐａｄｉａｍｅｎｔ，ＡＣＭ Ｔｒａｎｓａｃｔｉｏｎｓ ｏｎ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍｓ １６，２」、１９９８年５月、ｐ．１３３−１６９

【非特許文献2】Ｂｅｒｎｓｔｅｉｎ等、「Ｃｏｎｃｕｒｒｅｎｃｙ Ｃｏｎｔｒｏｌ ＆ Ｒｅｃｏｖｅｒｙ ｉｎ Ｄａｔａｂａｓｅ Ｓｙｓｔｅｍｓ」、Ａｄｄｉｓｏｎ Ｗｅｓｌｅｙ、１９８７年、６，７，８章

【発明の概要】

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

【0004】

図１に示すように、従来のＨＤＦＳクラスタは、以下のように動作する。ネームスペースに対する更新が要求される場合、例えば、ファイル又はディレクトリを作成するために、ＨＤＦＳクライアントが遠隔手続き呼出し（ＲＰＣ）を発行するような場合、アクティブ・ネームノード１０２は、図１に示すように、
１．クライアントからの要求（例えばＲＰＣ）を受信する。
２．更新をそのメモリ状態に直ちに適用する。
３．更新を、ジャーナルトランザクションとして、（１つ以上のハードドライブを備えるネットワーク接続記憶装置（ＮＡＳ）のような）共用の持続性記憶装置１０６に書き込み、かつ成功通知をクライアントに返信する。
スタンバイ・ネームノード１０４は、アクティブ・ネームノード１０２との整合性を維持するために、それ自身の状態を今、更新しなければならない。その目的に向けて、スタンバイ・ネームノード１０４は、
４．ジャーナルトランザクションをトランザクションジャーナル１０６から読み出し、かつ、
５、それ自身の状態を更新する。

【0005】

これは、しかしながら、準最適なソリューションであると思われる。例えば、この方式では、トランザクションジャーナル１０６自身が単一障害点となる。確かに、トランザクションジャーナル１０６が破損すると、スタンバイ・ネームノード１０４は、アクティブ・ネームノード１０２と同じ状態をもはや仮定できなくなり、かつアクティブ・ネームノードからスタンバイ・ネームノードへのフェイルオーバーももはや可能でなくなる。

【0006】

その上、１クラスタ当たりにただ１つのアクティブ・ネームノードをサポートするハドゥープソリューションにおいては、上述したように、スタンバイサーバは通常、ネットワーク接続記憶装置（ＮＡＳ）を介して同期状態に維持される。もしアクティブ・ネームノードが障害を起こし、かつスタンバイが引き継がなければならない場合、もしアクティブ・ネームノードに書かれた変更がＮＡＳに未だ書かれていなければ、データ損失の可能性がある。フェイルオーバーの間の管理者エラーは、更なるデータ損失につながり得る。その上、もしネットワーク障害が起こるとして、その障害では、アクティブサーバはスタンバイサーバと通信できないが、しかしクラスタにおける他のマシンと通信でき、かつ、スタンバイサーバが、アクティブサーバが死んでいると誤って仮定し、かつアクティブな役割を引き継ぐ場合、「分離脳」として知られる異常なネットワーク状態が起こり得る。この状態では、２つのノードが、自身らがアクティブ・ネームノードであると信じており、この状態は、データ破損につながり得る。

【図面の簡単な説明】

【0007】

【図1】従来のＨＤＦＳ実行の図である。

【図2】一実施形態による、分散ファイルシステム、及びコンセンサス・ネームノードを更新する態様の図である。

【図3】一実施形態による、分散ファイルシステムにおけるブロック複製及び生成の方法の態様を示す図である。

【図4】一実施形態による、フロック複製の更なる態様を示す図である。

【図5】一実施形態による、ブロック複製の更なる態様を示す図である。

【図6】一実施形態による１つの方法を示す図であり、この方法では、ブロック識別子は、コンセンサス・ネームノードにわたって一意的であるとしてもよい。

【図7】一実施形態による、分散ファイルシステムを実行するコンピュータ実行方法のフローチャートであり、この分散ファイルシステムは、クライアントファイルのデータブロックを格納するように構成された複数のデータノードを備える。

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

【0008】

プロポーザ（会員に提案をするプロセス）、アクセプタ（提案が会員によって合意されるべきかどうかに関して投票するプロセス）及びラーナー（形成された合意を学習する会員におけるプロセス）の役割は、例えば、Ｌａｍｐｏｒｔ，Ｌ．による「Ｔｈｅ Ｐａｒｔ Ｔｉｍｅ Ｐａｄｉａｍｅｎｔ，ＡＣＭ Ｔｒａｎｓａｃｔｉｏｎｓ ｏｎ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍｓ １６，２（Ｍａｙ １９９８）１３３−１６９」の中で説明されるＰａｘｏｓアルゴリズムの実行において定義される。この文献は、その全体が本明細書に組み込まれる。一実施形態によれば、アクセプタと呼ばれる複数のノードは、イベントを格納するように構成され得る。イベントは、所定数のアクセプタに対する提案として提出され得る。内部プロトコルを使用して、アクセプタは、その後、一連のグローバルなイベント内のイベントの順序について合意してもよい。いったん合意に達すると、アクセプタは、システムにおけるすべてのラーナーに対して一貫した順序で、ラーナーにイベントを学習させる。従って、（図２において２０８で示されるような）調整エンジンは、プロトコルと共に、一組のアクセプタを備える。このことは、アクセプタが、複数のプロポーザによってエンジンに提出されたイベントの順序について合意することを可能にする。一実施形態によれば、信頼性、利用可能性、及び拡張性を達成するため、複数の同時にアクティブであるネームノードが、ネームスペースの状態を複数のノード上に複製することによって設けられ得る。その場合、ネームスペースが複製されるノードの状態は、そのようなノード間で一貫したままであることが要求される。

【0009】

ネームノード間のこの一貫性は、調整エンジンによって保証され得る。ここで調整エンジンは、ネームスペースの更新に対する提案を受け入れ、その提案を一連のグローバルな更新に流し込むように構成されてもよく、かつその時にのみ、ネームノードが、合意に際しての順序で、更新を学習すると共に、それら個々の状態に適用することを可能とするように構成されてもよい。ここで、「一貫性」とは、一回コピー等価性を意味し、これについては、Ａｄｄｉｓｏｎ Ｗｅｓｌｅｙによって１９８７年に発行されたＢｅｒｎｓｔｅｉｎ等による「Ｃｏｎｃｕｒｒｅｎｃｙ Ｃｏｎｔｒｏｌ ＆ Ｒｅｃｏｖｅｒｙ ｉｎ Ｄａｔａｂａｓｅ Ｓｙｓｔｅｍｓ」の６，７，８章に詳細が述べられている。この文献は、これにより、その全体が本明細書に組み込まれる。ネームノードは、同じ状態からスタートし、かつ同じ決定論的な更新を同じ決定論的な順序で適用するので、ネームノードそれぞれの状態は一貫しており、かつ一貫したままである。

【0010】

一実施形態によれば、それ故に、ネームスペースは、複数のネームノード上に複製され得るが、それは以下の条件が前提である。
ａ）各ノードは、そのネームスペース・レプリカを修正することが許される。かつ、
ｂ）１つのネームスペース・レプリカに対する更新は、複数のノードにわたってネームスペース・レプリカが互いに一貫した状態で維持されるよう、他のノード上のネームスペース・レプリカに伝搬されなければならない。

【0011】

一実施形態は、それ故に、利用可能性に影響を与える、最も問題がある単一障害点、すなわち単一のネームノードを除去する。従来では、もし単一のネームノードが利用できなくなると、ハドゥープクラスタがダウンし、アクセスを回復するために（以前のアクティブ・ネームノードからスタンバイ・ネームノードへの切り替えのような）複雑なフェイルオーバー手続きが必要となる。この潜在的な単一障害点に対処するために、一実施形態は、複数のアクティブなネームノード・サーバ（ここでは、コンセンサスノード又はＣノードのように様々に表される）が、それぞれが連続的に同期化され、かつ、マップレデュース（ＭａｐＲｅｄｕｃｅ）を用いるバッチアプリケーションやＨＢａｓｅを用いる実時間アプリケーションに対するアクセスを含むクライアントアクセスを同時に提供する仲間として作動することを可能にする。一実施形態によれば、ネームノード・サーバが障害を起こすか、又は、メンテナンス又はユーザによる他の任意の理由のためにオフラインになっている場合、仲間である他のアクティブなネームノード・サーバは常に利用可能であり、このことは、ＨＤＦＳメタデータに対する読み出しアクセス及び書き込みアクセスに中断がないことを意味する。このサーバがオンラインに復帰するとすぐに、そのネームノードは自動的に回復し、その間に起こったかもしれないネームスペースに対する任意の新しい変更を通知され、かつクラスタ上の他のすべてのネームノードのネームスペースと一致させるために、そのネームスペースを同期化する。それは、他のノードが変更を学習したときと同じ決定論的な順序で変更を学習するので、他のレプリカと一貫することになる。

【0012】

図２は、一実施形態による分散ファイルシステム及び、コンセンサスノードを更新する態様の図である。一実施形態によれば、クラスタは、単一のアクティブ・ネームノード及びスタンバイ・ネームノードではなく、複数個（好ましくは奇数個。例えば、３，５，７，・・・）の、調整エンジン２０８によって調整されるネームノードを備える。上で注意したように、本明細書では、調整されたネームノードをコンセンサスノードと呼び、以下ではこれをＣノードと呼ぶ。図２に示すように、一実施形態は、それぞれ調整エンジン２０８に結合された３つのＣノード２０２，２０４，２０６を備えることができる。一実施形態によれば、調整エンジン２０８は、各ノードにおいて、ネットワーク上で互いに調和するエージェントとして構成されてもよい。しかしながら、参照及び描写を容易にするため、図２及び図４では、調整エンジン２０８は別個で単一の実体であるとして図示している。一実施形態によれば、ネームノード２０２，２０４，２０６のあるインスタンス上で開始されたネームスペースに対する更新は、調整エンジン２０８によって、首尾一貫した方法で他のインスタンスへ伝達される。このような方法により、クライアントは、ネームノードのすべてのインスタンスにわたる一貫したネームスペースにアクセスする。本明細書で開示された複製方法は、ＨＤＦＳのような分散ファイルシステムに対し高い可用性を有するアクティブ−アクティブ・モデルを提供する。このモデルでは、ネームノードの複数のインスタンスの間でメタデータ要求（読み出し又は書き込み）の負荷バランスが取られ得る。

【0013】

調整エンジン２０８は、ネームスペースに対する更新のグローバルな順序を決定するように構成され得る。ネームスペースのすべてのインスタンスは同じ状態で始まり、かつ、すべてのノードは同じ決定論的な順序での更新を適用されるので（しかし、実施形態によれば必ずしも同時にではない）、ネームスペースの複数のインスタンスは、複数のノードにわたって一貫した状態で保たれることになる（又は、一貫した状態となる）。

【0014】

一実施形態によれば、図２に示すように、複数のＣノードレプリカ２０２，２０４，２０６に対する一貫した更新は次のように実行され得る。（１）で示すように、ネームスペースの更新要求を、あるクライアントからＣノードの１つ（この場合、Ｃノード２０２）が受信する。そのようなネームスペース更新は、図２ではＲＰＣ３として識別されるＲＰＣを備える。同様に、この例では、Ｃノード２０４はＲＰＣ１を受信し、Ｃノード２０６はＲＰＣ２を受信する。これらのＲＰＣは、例えば、データブロックをファイルに付加し、ファイルを作成し、又はディレクトリを作成するための要求を備える。一実施形態によれば、Ｃノード２０２が、ＲＰＣ３内に埋め込まれたイベント（例えば、読み出す、書き込む、削除する、など）により自身の状態を直ちに更新し、Ｃノード２０４が、受信したＲＰＣ１内に埋め込まれたイベントにより自身の状態を直ちに更新し、Ｃノード２０６が、受信したＲＰＣ２内に埋め込まれたイベントにより自身の状態を直ちに更新し、かつ、その後、更新されたネームスペースをＣノード２０２，２０４，２０６の他の１つに伝達する、という処理ではなく、各Ｃノードでのネームスペース・レプリカに対するこれらの別個の更新が調整エンジン２０８に提案として渡され、調整エンジン２０８はその後、対応する合意をＣノード２０２，２０４，２０６に発行する、という処理が行われる。実際のところ、一実施形態によれば、Ｃノード２０２，２０４，２０６によって格納されたネームスペース・レプリカが一貫した形で保たれる仕組みは、調整エンジン２０８に対して提案を発行し、かつ調整エンジン２０８から合意を受信することによるものである。すなわち、図２に示すように、Ｃノード２０２は、ＲＰＣ３の受信に応答して、（２）で示すように提案Ｐｒｏｐ３を調整エンジン２０８に発行してもよい。同様に、Ｃノード２０４は、ＲＰＣ１の受信に応答して、（２）に示すように提案Ｐｒｏｐ１を調整エンジン２０８に発行してもよく、かつＣノード２０６は、ＲＰＣ２の受信に応答して、これもまた（２）に示すように提案Ｐｒｏｐ２を調整エンジン２０８に発行してもよい。一実施形態によれば、調整エンジン２０８はその後、（３）に示すように自身が受信した提案に順序付けを行い、（４）に示すように、順序付けた合意（この場合、ＡＧＲ３，ＡＧＲ１，ＡＧＲ２として順序付けされる）をＣノード２０２，２０４，２０６にフィードバックする。Ｃノード２０２，２０４，２０６は、順序付けられた一連の合意ＡＧＲ３、ＡＧＲ１，ＡＧＲ２を受信すると、これらの合意を、その決定論的順序でそれぞれのメモリ状態に適用し、その結果、ネームスペース・レプリカはＣノード２０２，２０４，２０６にわたって一貫した形で維持される。この方法では、Ｃノード２０２，２０４，２０６の状態は、（５）に示すように、一貫性を喪失することなく非同期で更新され得る。これらの更新はその後、（必ずしも必要ではないが）ジャーナルトランザクションとして、それぞれのローカル持続性記憶装置２１０，２１２，２１４に保存され得る。ここで、ローカル持続性記憶装置２１０，２１２，２１４は、（２１０，２１２，２１４で破線によって示されるように必ずしも必要ではないが）Ｃノード２０２，２０４，２０６に結合されていてもよいし、Ｃノード２０２，２０４，２０６にアクセス可能であってもよい。その後、更新の成功をクライアントに知らせる通知がＣノード２０２，２０４，２０６のクライアントに返され得る。

【0015】

このように、一実施形態によれば、Ｃノード２０２，２０４，２０６はクライアント要求を自身のそれぞれの状態に直接的に適用することをせず、順序付けのために、それらを提案として調整エンジン２０８に向けてリダイレクトする。Ｃノードに対する更新はその後、順序付けられた一組の合意として調整エンジン２０８から発行される。これは、クライアントがＣノード２０２，２０４，２０６の１つから変更を要求する場合にＣノード２０２，２０４，２０６のすべてが更新されること、及び、その更新がクラスタ内のすべてのＣノードに、透明性及び一貫性を持って適用されることを保証する。

【0016】

例えば、もしクライアントがＣノード２０２を介してディレクトリを作成し、その後、作成したばかりのディレクトリをＣノード２０４を介してリストに挙げようとする場合、Ｃノード２０４は、「ファイルが見つからない」例外を返すかもしれない。同様に、クライアントは、構築中であるファイルの最後のデータブロックについて、異なるバイト数で読み出すことになるかもしれない。何故なら、異なるデータノード上にある同じブロックのレプリカは、図３に関して以下で述べるように、そのデータがあるデータノードから他のデータノードに伝送中である間、異なる長さを有するからである。これは、「古くなった読み出し(stale read)」問題として知られる。

【0017】

それ故に、調整エンジン２０８の重要な役割は、一実施形態によれば、すべてのＣノードからのネームスペース状態修正提案を処理し、それらをグローバルに順序付けられた一連の合意に変換することである。Ｃノードはその後、その順序付けられたシーケンスからの合意を、更新として自身の状態に適用してもよい。一実施形態によれば、合意はグローバルシーケンス番号（ＧＳＮ）に従って順序付けられ得る。このグローバルシーケンス番号（ＧＳＮ）は、一意的な単調に増加する数として構成され得る。別の方法では、ＧＳＮは当業者が理解できるように構成され得る。ＧＳＮはその後、ネームスペースの状態を更新し、かつそのネームスペース状態を複数のＣノードにわたって一貫した状態に保つことに関して、様々なＣノードの進行状態を比較するために使用され得る。例えば、もしＣノード２０２がＧＳＮ１と番号付けされた合意を処理したばかりであり、このＧＳＮ１がＣノード２０４によって処理されたばかりのＧＳＮ２よりも小さければ、Ｃノード２０２はＣノード２０４よりも早期のネームスペース状態を有する。

【0018】

一実施形態によれば、各動作に関して、クライアントは、自身が現在接続しているＣノード上で処理された最新のＧＳＮについて学習する。その後、もしクライアントが別のＣノードに切り替える場合、一実施形態によればクライアントは、データ・アクセス・コマンドを備えるＲＰＣを発行する前に、クライアントが知っている最後のＧＳＮ（すなわち、クライアントが、以前にアクセスしていたＣノードから受信したＧＳＮ）に新しいＣノードが追いつくまで、(必要であれば)最初は待つべきである。これによって、古くなった読み出しの問題は、回避されるであろう。

【0019】

一実施形態によれば、ネームスペースの状態を更新する動作だけが、調整エンジン２０８によって調整される必要がある。すなわち、読み出し要求はネームスぺースの状態を変えないものであることから、ほとんどの（しかし、以下で説明される一実施形態によれば、すべてではない）読み出し要求については、クライアントが接続している任意のＣノードによって直接的に取り扱われることとしてよい。注意するべきことであるが、一実施形態によれば、調整エンジン２０８は、すべてのＣノード２０２，２０４，２０６が任意の与えられた瞬間に同じ状態を有することを保証するものではない。どちらかと言えば調整エンジン２０８は、すべてのＣノード２０２，２０４，２０６が、あらゆる更新について他のすべてのＣノードと同じ順序で最終的に学習し、クライアントがその情報を見ることが可能になる、ということを保証する。この方法では、調整エンジン２０８は、Ｃノード２０２，２０４，２０６のすべてに同じように供給されることになるグローバルに順序付けられた一連のイベントを生成するように構成される。

【0020】

一実施形態によれば、ローカル持続性記憶装置２１０，２１２，２１４に対するジャーナル更新が実行され得る。しかしながら、Ｃノード２０２，２０４，２０６の一貫性はそのようなジャーナル更新に依存するものではなく、各持続性記憶装置（もし存在すれば）は、一実施形態によれば、１つのＣノードに対してローカルであり、複数のＣノードにわたって共有されるものではない。同様に、Ｃノード２０２，２０４，２０６にわたってネームスペース状態の一貫性を維持することは、メモリやプロセッサリソースのような他のリソースを共有することに依存しない。

【0021】

いくつかの実施形態によれば、（マスターの、或いは区別された）優先的なＣノードは存在しない。実際、もし１つ以上のＣノードサーバが障害を起こすか、又はメンテナンス（或いはその他の任意の理由）のためにオフラインになった場合であっても、他のアクティブなＣノードサーバは、アクセスにおいていかなる中断もなく、クライアントに奉仕するために常に利用可能となっている。一実施形態によれば、サーバは、オンラインに復帰するとすぐに、以下で説明するように自動的に他のＣノードサーバと再同期化する。そのような同期化は、Ｃノードがダウンした時又はオフラインになった時以降に調整エンジン２０８によって発行されたすべての合意の学習を含み得る。すべてのＣノードがアクティブであり、常に同期が維持され又は同期化されているときには、スプリットブレイン状態及びデータ損失の両方が除去されており、それによって、連続的なホットバックアップがデフォルトで提供される。フェイルオーバー及びリカバリの両方が直ちにかつ自動的に行われ、そのことは、手動介入の必要性及び管理者エラーのリスクをさらに除去する。加えて、Ｃノード２０２，２０４，２０６のどれも、受動的なスタンバイ・ネームノードとして構成されることはない。実際、一実施形態によれば、クラスタ内のすべてのＣノードサーバは、同時的なクライアント要求をサポートするように構成される。その結果としてこのことは、クラスタが、負荷の増大によるパフォーマンスの犠牲を伴わず、追加のＣノードサーバをサポートするように拡張されることを可能にする。一実施形態によれば、受動的なスタンバイサーバは存在せず、アクティブなネームノード・サーバがひとつだけであることによる脆弱性及びボトルネックは完全に除去される。その上、複数のＣノード２０２，２０４，２０６にわたってクライアント要求を分散させることは、本来的に、すべての利用可能なＣノードに処理負荷及びトラヒックを分散させる。すべてのクライアント要求が単一のネームノードによって取り扱われるアクティブ／スタンバイ・ネームノード・パラダイムではなく、Ｃノード２０２，２０４，２０６にわたるアクティブな負荷バランシングが実行されてもよい。

【0022】

図３は、一実施形態による、分散ファイルシステムにおけるブロックの複製及び生成の方法の態様を示す図である。図３の３５０は、ＨＤＦＳに格納されるべきファイルを示す。一実施形態によれば、記憶域の単位をブロックと名付けてもよく、ブロックサイズはかなり大きくてもよい。例えば、ブロックサイズは１２８ＭＢ分の物理的ストレージであってもよい。他のブロックサイズも容易に実装され得る。ファイル３５０は、１２８ＭＢのデータブロックを複数備えるものとして、図３に示されている。ブロックサイズは、１２８ＭＢである必要はない。一実施形態によれば、ファイルの各データブロックは、複数のデータノード上に複製され得る（すなわち、等しく格納され得る）。そのようなデータノードは３０２，３０４，３０６に示されており、例えばＣノード２０２のような１つ以上のＣノードに結合するように構成される。一実施形態によれば、各データノードは、クラスタ上の各Ｃノードと通信するように構成され得る。ファイルのデータブロックは、例えば５つ又は７つのデータノードのような、より多くのデータノード上に格納され得る。複数のデータノード上に各データブロックを格納することは、冗長性を通して信頼性を提供する。

【0023】

図２に示すように、クライアントはメッセージ（例えば、ＲＰＣ)をＣノード２０２に送信するが、このメッセージは、ファイルを作成し、ファイルに１ブロック分のデータを書き込むというクライアントの意図を示す。一実施形態によれば、Ｃノード２０２はその後、この新たに作成されるファイルのデータブロックが複製される複数のデータノード（この代表的な実装では３つ）３０２，３０４，３０６を選択し、それをクライアントに通知する。一実施形態によれば、クライアントはその後、３つのデータノード３０２，３０４，３０６のうちの選択された１つに対し、データのストリーム配信（又は送信）を開始する。そのようなストリーム配信は、各データブロックの小さなチャンクを、選択されたデータノード（例えば、データノード３０２）に連続的に送信することによって実行され得る。例えばクライアントは、ファイルの最初のデータブロックがデータノード３０２に成功裏に送信され終わるまで、ファイルの最初のデータブロックの６４ＫＢのチャンクのシリアルなストリームをデータノード３０２に対し送信することとしてもよい。クライアントと選択されたデータノード３０２との間のハンドシェークは、各データブロックが、選択されたデータノード３０２によって成功裏に受信されかつ格納されることを保証し得る。１つ目のデータノード３０２に送信されたデータチャンクはまた、クライアントのファイルのデータブロックが送信されるべき２つ目のデータノード３０４のインディケーションを備え得る。一実施形態によれば、クライアントが、ファイルのデータブロックのレプリカを受信するようにＣノード２０２によって選択された３つの（又はそれ以上の）データノードに対してファイルのデータブロックを直接送信する代わりに、そのブロックのデータチャンクを受信したばかりである第１データノード３０２がその後、ファイルのデータブロックを受信する３つのデータノードのうちの次のもの（例えば、データノード３０４）に対し、受信したデータチャンクを自身で送信することとしてもよい。同様に、データノード３０４がデータノード３０２によって自身に送信されたデータチャンクを成功裏に受信した後、データノード３０４は、クライアントのファイルの構成データブロックのレプリカを受信するようにＣノード２０２によって選択された３つのデータノードの最後のデータノードに対し、受信したデータチャンクを送信することとしてもよい。この方法では、Ｃノードによって選択された第１のデータノードがＣノードによって選択された第２のデータノードに対してデータチャンクを転送し、その第２のデータノードが、ファイルのデータブロックのレプリカを受信するようにＣノードによって選択された第３のデータノードに対し、受信したデータチャンクを転送する（もし３つより多いデータノードがファイルのブロックを受信することになっている場合、同様に続く）、というデータチャンクのパイプラインが形成される。

【0024】

一実施形態によれば、クライアントのファイルの構成データブロックの受信者として選択したデータノードが実際にデータブロックを成功裏に受信しかつ格納したと、Ｃノードが決め込んでかかることはない。代わりに、一実施形態によれば、データノード３０２，３０４，３０６は、いったんクライアントファイルの１つ以上のデータブロックを所有すると、図３に示すように、クライアントによって直接又は別のデータノードによって自身らに送られたデータブロックのレプリカを今や格納していることを、Ｃノード２０２に報告することができる。データノードの少なくとも幾つかは（かつ、一実施形態によれば各々は）、そのメッセージを発行しているデータノードが依然としてアクティブであり、かつ、良好な健康状態にあること（すなわち、クライントからのデータアクセス要求に対してサービスを提供することが可能であること）をＣノードに通知するために構成され得る「ハートビート」メッセージをＣノードに対し周期的に発行してもよい。データノードは、一実施形態によれば、クライアントファイルの１つ以上のデータブロックを成功裏に受信し格納したことを、別のメッセージとしてＣノードに報告することとしてもよい。図３に描かれた代表的な状況では、データノード３０２，３０４，３０６は、自身らが、Ｃノード２０２への、クライアントファイルの１つ以上のデータブロックを成功裏に受信し格納したことを、Ｃノード２０２に報告してもよい。

【0025】

データノードは、障害を起こし得る。その障害が、データノードとＣノードの間の通信チャンネルにおける中断、ファイルサーバの障害、又は、下層の物理的記憶装置の障害（若しくは他の任意の障害）のいずれによって引き起こされたものであったとしても、そのような障害は、少なくとも障害が起こったデータノードからはデータブロックが利用できない可能性がある、ということを意味する。図４に示した例では、データノード３０６が障害を起こしている。一実施形態によれば、Ｃノード２０２，２０４，２０６は、データノード３０６のこの変更された状態を直ちには知らされないかもしれない。代わりに、上述したハートビートメッセージの仕組みが、各データノードの現在に近い（最後にハートビートがあった時点での）状態をＣノードに持続的に知らせるための有益な利点として使用され得る。すなわち、一実施形態によれば、Ｃノードは、所定期間内にハートビートメッセージを受信することに失敗したことを、データノードにおけるハートビート送信の失敗と解釈する。所定期間は、例えば、任意の単一のデータノードからのハートビートメッセージ間のインターバルの期待値よりも大きな期間に設定され得る。

【0026】

図４の例では、データノード３０６は、自身の最後のハートビートから所定の時間インターバルの間にハートビートメッセージ（図３における「ＨＢ」）を送信することに失敗しており、それ故、障害を起こしており、そこに格納されたデータブロックは、少なくとも当分の間、アクセス不能であるとみなされる。このことは、データノード３０２及び３０４だけが様々なファイルのデータブロックを格納することを意味する。一実施形態によれば、Ｃノードは、現在アクティブであり、一実施形態によれば、新しいデータブロックを受け入れ、及び／又は、データアクセス要求にサービスを提供する準備ができているデータノードのリストを保管してもよい。そのようなリストは、「アクティブ」リストと名付けられ得る。図４におけるデータノード３０６のように、データノードから期待されるハートビートメッセージを受信することに失敗したことに応じて、Ｃノードは、そのデータノードは障害を起こしたとみなし、その障害を起こしたデータノードをアクティブリストから除去することができる。一実施形態によれば、アクティブリストは、ブロックを作成することについてのクライアントからの要求を受信したＣノードが、生成予定のファイルのデータブロックが格納されることになる（例えば）３つのデータノードを選択するためのリストであってよい。データノード３０６は障害を起こしているためアクティブリストから除去される可能性があり、そのような除去は、少なくともＣノードの視点から、あらゆる目的においてそのデータノードを実効的に存在せず利用できないものとする。

【0027】

データノード３０６の障害によりクライアントファイルのデータブロックが複製不足の状態（例えば、所定数のデータノードより少ない数のデータノードに格納されている状態）となると、Ｃノード２０２は、一実施形態によれば、３つのデータノードの全数がそのファイルの構成データブロックのレプリカを格納することを保証するため、クライアントファイルのデータブロックが複製され得る新しいデータノードを選択することができる。一実施形態によれば、Ｃノード２０２はアクティブリストを調べ、そのリストから、クライアントファイルのデータブロックが複製される新しいデータノードを選択することにより、クライアントファイルのデータブロックのレプリカを格納するデータノードの全数を３つ（又は４つ、５つなど、そのファイルに割り当てられた複製係数に依存する）にまで戻すこととしてもよい。図４に示した例では、Ｃノード２０２は、複製不足状態を解消するため、データブロックのレプリカが格納されるデータノードとしてデータノード４０２を選択している。一実施形態によれば、Ｃノード２０２はまた、所有するレプリカを選択したデータノード４０２に送信するデータノード３０４を選択することができる。選択されたデータノード３０４はその後、図４において４０６で示すように、新しく選択されたデータノード４０２に対し、ブロックレプリカのデータチャンクのストリーム配信、又は、ブロックレプリカの送信を開始することができる。新しく選択されたデータノード４０２はブロックレプリカを受信し、Ｃノードに報告すべき時が来たときには、新しく受信したブロックのレプリカを今や格納していることを報告してもよい。Ｃノードは、この変更を反映させるためにネームスペースを変更してもよい。一実施形態によれば、受信するデータノードは、Ｃノード２０２によってランダムに選択されてもよい。他の実施形態によれば、そのような選択は所定の選択基準に従って行われる、こととしてもよい。

【0028】

一実施形態によれば、Ｃノード２０２，２０４，２０６の各々は、データノード３０２，３０４，３０６，４０２、及び、ハートビートを周期的に受信している他のすべての（潜在的には何千の）データノードの各々を「意識して」いる。データノードの障害が発生すると、ブロックが複製不足でないことを保証するため、１つ以上のＣノードが、あるデータノードを送信データノードとして、かつ、別のデータノードをブロックレプリカの受信者として選択することを決定する。このことは、障害を起こしたデータノードによってそれまでに格納されていたデータブロックを格納するために、複数のＣノードが複数の代替データノードを選択するという結果を生じ得る。そのような並列的な動作は、ブロックが過剰複製されるという結果を生じ得る（例えば、この実例として、意図された３、４、５・・より多く複製される）。そのような過剰複製は、図５に示すように、以前に障害を起こした又はアクセス不能となっていたデータノードがオンラインに復帰するときにも発生し得る。図５では、以前に障害を起こした又はアクセス不能となっていたデータノード３０６が再び運転中となり、Ｃノード２０２，２０４，２０６に対してアクセス可能となった、という状態が仮定されている。この状態では、クライアントのファイルのブロックが４つのデータノード、すなわち、元のノード３０２、３０４、新しく付加されたデータノード４０２、及び動作しておらずかつアクセス可能なデータノード３０６の中に存在している。クライアントのファイルのデータブロックは、それ故、過剰に複製されている。データノード３のオンライン復帰状態が（データノード３０６からハートビートを受信することにより）すべてのＣノード２０２，２０４，２０６に知られるところになると、１つ以上のＣノード２０２，２０４，２０６が、クライアントファイルのブロックのレプリカを削除すべきデータノードを独自に選択する可能性が想像される。このような独自の選択は、クライアントファイルのブロックレプリカが過剰複製の状態から複製不足の状態になることの原因となり、最悪のケースでは、すべてのデータノードから削除されてしまう原因となり得る。

【0029】

そのようなことが起こるのを防止するために、一実施形態によれば、ブロック複製任務を、単一の選択された又は選定されたＣノード、すなわちブロック複製器Ｃノードのために、任意の与えられた時点で確保してもよい。そのようなブロック複製任務は、一実施形態によれば、ブロック複製（すなわち、データノード間で複製されるべきブロックを指示すること）及びブロック削除を調整することを含むことができる。ブロック生成機能は、一実施形態によれば、データ損失又は過剰複製という上記のような本来的なリスクを引き起こすことはなく、それ故に、クラスタの各Ｃノードに付与され得る。したがって、一実施形態によれば、すべてのＣノードは、ブロック管理任務を実行するように構成され得る。しかしながら、そのようなブロック管理任務は、一実施形態によれば、単一の選択されたＣノードのために確保されるブロック複製及び削除任務と、クラスタの各Ｃノードに付与され得るブロック生成任務とに分割されることができる。これは図５に示される。この図の中で、Ｃノード２０２はブロック複製器機能４１０を有して構成される唯一のＣノードとして選択されており、これによってＣノード２０２だけが、データブロックを複製し、及び／又は、データノードからデータブロックを削除することができるようになっている。対照的に、図５に示すように、Ｃノード２０２，２０４，２０６はそれぞれブロック生成器機能４０８，４１２，４１４を実行するように構成されることができ、このことは、Ｃノード２０２，２０４，２０６のそれぞれが、ブロックを生成し、又は、（ハートビートによる）報告のあるデータノードのうちの選択したものに新しいデータブロックを格納することを可能にする。

【0030】

各データノードは、一実施形態によれば、クラスタ内のすべてのＣノードに対し、すべての伝達情報を送信するように構成してもよい。すなわち、アクティブかつ動作中のデータノードは、ハートビート、ブロックレポート、及び、受信又は削除されたレプリカについてのメッセージなどを、クラスタの各Ｃノードに独立に送信するように構成され得る。

【0031】

ＨＤＦＳの現在の実装では、データノードは、単一のアクティブ・ネームノードを認識するに過ぎない。これが意味するのは、データノードは、アクティブでないネームノードから来る任意のデータノード・コマンドを無視するであろう、ということである。慣習的には、もしアクティブでないネームノードがアクティブなネームノードになったと主張し、かつより高い送信ＩＤ（ｔｘＩｄ）によりその状態を確認したとしたら、データノードは、フェイルオーバー処理を実施して新しいアクティブ・ネームノードに切り替えると共に、新たなアクティブ・ネームノードのからデータノード・コマンドをただ受け入れることとなるであろう。

【0032】

実施形態によれば、この動作方法をＣノードクラスタに適応させるために、ブロック複製器任務(すなわち、現在のブロック複製器)を有するＣノードだけが、その状態をアクティブであるとして、データノードに報告する。これは、ブロック複製器だけが、ブロックレプリカを複製し又は削除することをデータノードに命令する能力を有することを保証する。

【0033】

アプリケーションは、ＨＤＦＳクライアントを介してＨＤＦＳにアクセスする。慣習的には、ＨＤＦＳクライアントは、ファイルメタデータを求めて１つのアクティブ・ネームノードにコンタクトし、その後、そのデータノードから直接データを入手するであろう。実際、現在のＨＤＦＳの実装では、クライアントは常に１つのアクティブ・ネームノードと対話する。もし高可用性（ＨＡ）が可能であれば、アクティブなネームノードは、スタンバイノードにフェイルオーバーすることができる。それが起こる場合、ＨＤＦＳクライアントは、万一別のフェイルオーバーが起こるまでの間、新たにアクティブとなったネームノード（以前は、スタンバイノード）と通信を行う。フェイルオーバーは、異なる実装を有することのできるプラグ接続可能なインターフェース（例えば、ＦａｉｌｏｖｅｒＰｒｏｘｙＰｒｏｖｉｄｅｒ）によって扱われる。

【0034】

しかしながら、実施形態によれば、Ｃノードはすべて常時アクティブであり、クライアントに対してネームスペース情報を提供するために等しく使用され得る。一実施形態によれば、ＨＤＦＳクライアントは、例えばＣノードプロキシと呼ばれるプロキシインターフェースを介して、Ｃノードと通信するように構成され得る。一実施形態によれば、Ｃノードプロキシは、Ｃノードをランダムに選択し、このランダムに選択されたＣノードに対してクライアントのＲＰＣ要求を送信するために通信ソケットを開くように構成され得る。クライアントはその後、通信タイムアウト又は障害が起こるまで、このＣノードに対してのみＲＰＣ要求を送信する。通信タイムアウトは、設定可能であってよい。通信タイムアウトの期限が切れると、クライアントは別の（例えば、Ｃノードプロキシによってランダムに選択された）Ｃノードに切り替え、通信ソケットをこの新しいＣノードに開き、この新しいランダムに選択されたＣノードだけにクライアントのＲＰＣ要求を送信することができる。負荷バランスをとる目的のために、例えば、この通信タイムアウトは低い値に設定され得る。実際、クライアントがＲＰＣ要求を送信しているＣノードがビジー状態にある場合、応答遅延が通信タイムアウトの低い値よりも大きくなり、それによって、クライアントがＣノードプロキシを介して通信相手のＣノードを切り替えるトリガが引かれ得る。

【0035】

確かに、ＨＤＦＳクライアントによるＣノードのランダムな選択は、複数のクライアントが複製されたＣノードと通信することに関して、負荷バランスをとることを可能にする。Ｃノードプロキシがクライアントの通信相手となるＣノードをランダムに一度選択してしまうと、そのクライアントは、一実施形態によればランダムに選択されたＣノードがタイムアウトになるか又は障害を起こすまで、そのＣノードに「貼り付く」ことになり得る。この同じＣノードへの「貼り付き」は、上で述べた古くなった読み出しの機会をフェイルオーバーのケースのみに減少させる。Ｃノードプロキシは、Ｃノードが再起動し、まだサービスの準備が完全でない（例えば、Ｃノードが、ダウンしていた時間の間に見逃したかもしれない合意を学習している）ときに発生し得るもののようなセーフモードにあるＣノードを選択しないように構成され得る。

【0036】

上で議論した古くなった読み出しの問題について、一例を通じてさらに説明する。例えば、もしクライアントが、Ｃノード１を介してディレクトリを作成し、その後、作成されたばかりのディレクトリを同じ又は別のクライアントがＣノード２を介してリストに挙げようとする場合、Ｃノード２は、その学習プロセスが遅れており、ディレクトリを作成するための合意を未だ受信しておらず又は処理していないために、ファイルが見つからない例外(file not found exception)を返すかもしれない。同様に、クライアントは、構築中であるファイルの最後のブロックを様々なバイト数で読み出すかもしれない。何故なら、異なるデータノード上の同じブロックのレプリカは、そのデータが遷移状態にある間、異なる長さを持ち得るからである。

【0037】

古くなった読み出し問題は、次の２つの場合に顕在化する。
１．ひとつのクライアントが、（例えば、障害、故意の中断により、又は負荷バランス目的のために）より古いネームスペース状態を有する新たなＣノードに切り替える。
２．あるクライアントが、他のクライアントによる参照のために必要であるネームスペースを修正してしまう。

【0038】

一実施形態によれば、第１の場合は、プロキシインターフェースがＣノードプロキシに、それが接続されているＣノードのＧＳＮを意識させることによって回避され得る。ＨＤＦＳクライアントは、それぞれの動作によって、Ｃノード上のＧＳＮについて学習する。クライアントが別のＣノード（例えば、Ｃノードの障害、タイムアウト、又は、理由は何であれそのＣノードの計画的なシャットダウンのために）に切り替える場合、クライアントは、Ｃノードプロキシを通じて、既に参照したものよりも小さくないＧＳＮを有するＣノードを選ぶか、又は、クライアントが以前のＣノードから受信した最新のＧＳＮに新しいＣノードが追いつくまで待つべきである。

【0039】

第２の場合は、マップリデュース(MapReduce)ジョブがスタートする場合に起こる。この場合、マップリデュースクライアントは、ｊｏｂ．ｘｍｌのようなジョブ構成ファイルをＨＤＦＳの中に配置する。このジョブ構成ファイルは、その後、クラスタ上で実行されるすべてのタスクによって読み出される。もし幾つかのタスクがそのジョブ構成ファイルについて未だ学習していないＣノードにつながる場合、そのタスクは失敗するであろう。従来、そのような制約はクライアント間の外部調整を要求する。しかしながら、一実施形態によれば、クライアント間の調整は調整された読み出しによって置き換えられる。

【0040】

一実施形態によれば、調整された読み出しは修正動作と同じ方法で実施され得る。すなわち、Ｃノードは、ファイルを読み出すために提案を提出し、対応する合意が調整エンジン２０８から返されたときに、そのファイルを実際に読み出す。従って、一実施形態によれば、読み出し合意は、ネームスペース修正合意と同じグローバルなシーケンスで実行されることができ、それによって、調整された読み出しが決して古いもの(stale)にならないことが保証される。一実施形態によれば、調整された読み出しは、すべての読み出しに対して使用される必要はない。そうすることは、調整エンジン２０８の計算負荷を不必要に増加させ、かつクラスタの読み出し性能を低迷させるかもしれないからである。従って、一実施形態によれば、ｊｏｂ．ｘｍｌのような選択されたファイルだけを、調整された読み出しの対象としてもよい。それ故、一実施形態によれば、例えば構成パラメータとして、一組のファイル名パターンが定義され得る。そのようなパターンは、クラスタのＣノードによって認識され得る。そのようなファイル名パターンが定義される場合、Ｃノードは、読み出し対象のファイル名とファイル名パターンとを照合し、その結果が肯定であれば、そのファイルに対して調整された読み出しを実施する。

【0041】

もし対象が特定のＣノード上で１つのクライアントによって一度アクセスされたのであれば、後に続くクライアントにとって、調整された読み出しによってその対象にアクセスする必要はなくなる。一実施形態によれば、ファイルは、特定のＲＰＣ呼び出しを通じてアクセスされたものとして識別され得る。この方法では、もしそのような呼び出しを実行するＣノードが、そのファイルがそのように識別されなかったことに気づいたとすると、そのＣノードは、調整された読み出しを実施するため、調整エンジン２０８に対して提案を提出し、対応する合意が受信されるのを待機することとしてもよい。この読み出し合意はすべてのＣノードに到着し、すべてのＣノードは、それらのファイルレプリカをそのようにアクセスされたものとして識別する。識別されたファイルにアクセスするための後に続くすべてのクライアント呼び出しは、一実施形態によれば、調整して読み出される必要はない。それ故、クラスタ内に３つのＣノードを有する場合の最悪のケースで、１ファイル当たりの調整された読み出しはわずかに３回以下となり、それによって読み出し性能が高く保たれる。

【0042】

Ｃノードはまた、障害を起こすかもしれないし、メンテナンスのために故意にダウンさせられるかもしれない。もし障害を起こしたＣノードがまた、ブロック複製器任務を授けられているただ１つのＣノードである（すなわち、そのＣノードがブロック複製器として選定されている）場合、クラスタは、データブロックを複製又は削除する能力を持たない状態のままでもよい。一実施形態によれば、それ故に、４１０に示すようなブロック複製器機能を有するＣノードは、４１６に示すように、調整エンジン２０８に対して周期的なブロック複製器ハートビート（ＢＲ ＨＢ）をも送信するように構成され得る。調整エンジン２０８がブロック複製器任務４１０を含むように選択されたＣノードから周期的なＢＲ−ＨＢ４１６を受信している限り、そのＣノードは、そのようなブロック複製任務の実行を継続してもよい。しかしながら、調整エンジン２０８がブロック複製器４１０として選択されたＣノードから１つ以上のＢＲ ＨＢをタイムリーに受信することに失敗すると、ブロック複製任務は、クラスタ内の複数のＣノードのうちの別の１つに割り当てられることになる。すると、そのように選択されたＣノードはその後、周期的なＢＲ ＨＢ（それらは、データノードによって発行されたハートビートＨＢとは区別される）を調整エンジン２０８に対して発行するようになり、調整エンジン２０８が１つ以上のＢＲ ＨＢの受信に失敗し、それに応じてＣノードの選択プロセスが再度行われるまでの間、その役割を継続する。

【0043】

一実施形態によれば、クラスタ内のブロック複製器４１０がただ一つであることを保証するために、ブロック複製器４１０を備えるＣノードは、調整エンジン２０８に対してブロック複製器提案を周期的に提出するように構成され得る。調整エンジン２０８は、ブロック複製器提案の受信を待って、ブロック複製任務を実行するために選択又は選定されたＣノードが、クラスタ内のすべてのＣノードに対してそのブロック複製器としてのミッションを確認させていることを確認することができる。もしＢＲ ＨＢが変更可能な期間内にＣノードによって受信されない場合、他のＣノードは、調整エンジン２０８によって、新しいブロック複製器Ｃノードを選定するプロセスを開始してもよい。

【0044】

実際、一実施形態によれば、ブロック複製器提案は、ブロック複製任務を有するＣノードが、周期的なＢＲ ＨＢを介して、他のＣノードにブロック複製器としての自身のミッションを確認させる１つの方法であるとともに、ＢＲ ＨＢの期限が切れた場合に、新しいブロック複製器の選定を実施するための方法である。一実施形態によれば、ブロック複製器提案は次のものを備える。
・ｂｒＩｄ−−−ブロック複製器であると見なされるＣノードの識別子。
・ｂｒＡｇｅ−−−提案しているＣノードのＧＳＮ。

【0045】

各Ｃノードは、自身が受信した最新のブロック複製器合意と、その合意を受信し時刻とを示す＜ｌａｄｔＢＲＡ，ｌａｓｔＲｅｃｅｉｖｅｄ＞を記憶することができる。

【0046】

例えば、３つのＣノードｃｎ１，ｃｎ２，ｃｎ３が存在し、かつ、ｃｎ１が現在のブロック複製器Ｃノードであると仮定する。Ｃノードｃｎ１は、ＢＲ ＨＢとして、ブロック複製器提案を周期的に提案する。この提案は、それ自身のノード識別子ｃｎ１と、提案時のｃｎ１によって観察される最新のＧＳＮに等しいブロック複製器の新年齢とからなる。調整エンジン２０８は、ブロック複製器提案を受信し、対応する合意を生成し、その合意をすべてのＣノードｃｎ１，ｃｎ２，ｃｎ３に送達する。現在のブロック複製器であるノードｃｎ１は、合意を学習し、ブロック複製作業を開始する。Ｃノードｃｎ２及びｃｎ３は現在のブロック複製器ではなく、したがって、それらは＜ｌａｓｔＢＲＡ，ｌａｓｔＲｅｃｅｉｖｅｄ＞を記憶するのみで、通常の（非複製）動作を継続する。ｌａｓｔＲｅｃｅｉｖｅｄが設定された閾値を超えるとき、ｃｎ２及び／又はｃｎ３は、一実施形態によれば候補としてそれ自身を提案することによって、新しいブロック複製器の選定を開始することができる。

【0047】

一実施形態によれば、ブロック複製器ハートビートＢＲ ＨＢが満了したことをＣノードが一旦検出すると、任意の１つのＣノードによって（或いは、複数のＣノードのうちのいくつかによって同時に）選定プロセスが開始され得る。こうして開始したＣノードは、一実施形態によれば、新しいブロック複製器としてそれ自身を提案することにより、選定プロセスを開始することができる。提案は、ノード識別子と、開始したＣノードがその時までに参照した最新のＧＳＮとを含み得る。提案は調整エンジン２０８に提出してもよく、対応する合意が他のＣノードに到達したときには、他のＣノードは、それに応じてブロック複製器任務に関する自らのミッションを更新する。これが、選定プロセスを始めたＣノードが新しいブロック複製器になるまで道筋である。一実施形態によれば、幾つかのＣノードが選定を同時に始める場合には、最も高いＧＳＮを有する合意を提案したＣノードがブロック複製器になる。従って、ブロック複製器任務を有するＣノードは、選定プロセスの間に何度か変わるかもしれないが、最後には、ただ１つのブロック複製器Ｃノードが存在することとなり、すべてのＣノードはそのＣノードがブロック複製器任務を有することに合意するであろう。一実施形態によれば、障害を起こしたＣノードは、たとえ障害の後、自身がブロック複製器であると思い込みながらオンラインに復帰した場合であっても、いかなるブロックの複製又は削除の決定もしないことが保証される。これは、ブロックの複製又は削除の決定が、ＢＲ ＨＢを処理することの結果としてのみ、なされるからである。すなわち、サービスに復帰した後そのＣノードは、複製の決定をするために、次のブロック複製器ハートビートＢＲ ＨＢを待つであろう。しかし、ハートビート合意は新しいブロック複製器割り当てについての情報を含んでおり、その新しくアクティブになったＣノードは、その情報の受信により自身がもはやブロック複製任務を有していないことを知るであろう。

【0048】

ブロックを生成する資格若しくはブロック生成を可能にする資格を任意のＣノードに与えることは、データノードに格納される各データブロックが、クラスタ全体にわたって一意的に識別可能であることを必要とする。ＨＤＦＳにおいてブロックＩＤを生成する現行の方法は、長いデータブロック識別子（ＩＤ）をランダムに生成し、かつ、その後そのような生成されたデータブロックＩＤが真に一意的であるかどうかをチェックすることである。このアプローチは、複製されたＣノードにとっての問題を孕む。なぜなら、調整エンジンに対して提出されたブロックを生成するためには提案の前に新たなブロックＩＤが生成されていなければならないが、そのＩＤが生成の時点ではフリーであったとしても、対応する合意がＣノードに到達するまでに、そのＩＤが他のブロックに既に割り当てられている可能性があるからである。合意時におけるそのような衝突を調整することは、可能であるとしても、そのプロセスに不必要な複雑さ、トラヒック、及び遅延時間を付加し、かつ、データブロックが成功裏に生成されたことについてのクライアントへの最終的な応答を遅延させる。代わりに、一実施形態によれば、図６に示すように、最小のブロックＩＤ番号（ＭＩＮＬＯＮＧ）から最大のブロックＩＤ番号（ＭＡＸＬＯＮＧ）にわたる大きな範囲が定義され得る。この大きな範囲は、各データブロックＩＤ番号がクラスタ全体にわたって一意的であり、かつ一実施形態によれば、それらの予想される寿命の及ばないことを保証するのに必要となる程度と同程度に大きくなり得る。例えば、ＭＩＮＬＯＮＧからＭＡＸＬＯＮＧまでの範囲は、例えば１０２４ビット以上を含む数であってもよい。その後は、各Ｃノードが一意的なデータブロックＩＤ番号を生成することを保証するために、ＭＩＮＬＯＮＧからＭＡＸＬＯＮＧまでの範囲は、図６において範囲６０２，６０４，６０６で示すように、３つのＣノードブロックＩＤ範囲に論理的に分割され得る。例えば、データブロックＩＤ範囲６０２はＭＩＮＬＯＮＧからＭＩＮＬＯＮＧ＋Ｘビットまで広がり、ブロックＩＤ範囲６０４はＭＩＮＬＯＮＧ＋ＸからＭＩＮＬＯＮＧ＋２Ｘまで広がり、ブロックＩＤ範囲６０６はＭＩＮＬＯＮＧ＋２ＸからＭＡＸＬＯＮＧまで広がる。

【0049】

図７は、一実施形態による、ファイルのデータブロックを格納するように構成された複数のデータノードを備える分散ファイルシステムを実行するコンピュータ実行方法のフローチャートである。ブロックＢ７１に示すように、本方法は、少なくとも３つの（又は他の幾つかのより大きな奇数の）ネームノードを複数のデータノードに結合するステップを備えてもよい。ネームノードの各々は、一実施形態によれば、クラスタのネームスペースの状態を格納するように構成され得る。その後、ブロックＢ７２に示すように、ファイル及びディレクトリを生成又は削除し、並びに、（図３において３０２，３０４，３０６で示すような）複数のデータノードのうちの１以上に格納されるデータブロックを追加することによってネームスペースの状態を変更するために、（図２において２０２，２０４，２０６で示すような）ネームノードからの提案を受信する（例えば、調整エンジン２０８の）ステップが実行され得る。本開示においては、「変更する」には、該当する場合には、新しいデータブロックを付加すること、データブロックを複製すること、又はクライアントファイルのデータブロックを削除することが含まれる。Ｂ７３で示すように、本コンピュータ実行方法は、提案を受信することに応じて、ネームノードがネームスペースの状態を変更する順序を特定する、順序付けられた一組の合意を生成するステップをさらに備えてもよい。一実施形態によれば、それ故に、ネームノードは、順序付けられた一組の合意を（例えば、調整エンジン２０８から）受信するまで、ネームスペースの状態に対して（例えば、クライアントによって要求された）変更を加えることを遅らせる。

【0050】

一実施形態によれば、ある新しいＣノードがオンラインになるとき（現存するＣノードが障害を起こした、又はそうでなければシャットダウンされた、というようなケース）、その新しいＣノードは上述したようにセーフモードで起動され得る。セーフモードにある新しいＣノードはその後、各データノードから、登録と、その新しいＣノードが結合されているデータノードの各々に格納されているデータブロックを識別する初期データブロック・レポートとの受信を開始する。一実施形態によれば、あるＣノードがセーフモードにある場合、そのＣノードは、ネームスペースの状態を修正することについてのクライアントからの要求を受け入れない。すなわち、新しいＣノードは、提案を提出する前に自身がセーフモードにあるかどうかをチェックし、自身が現在セーフモードで動作していると決定した場合には、セーフモード例外を投入する。十分な数のブロックレポートが受信されたとき、一実施形態によれば、新しいＣノードはセーフモードを離れ、クライアントからのデータ修正要求の受け入れを開始することができる。起動の際には、一実施形態によれば、Ｃノードはセーフモードに自動的に入り、ブロックレプリカの十分な数のレポートを一旦受信した後には、セーフモードを自動的かつ非同期的に離れる。自動的にセーフモードから出ることは、一実施形態によれば、調整エンジン２０８によって調整されない。なぜなら、（図２におけるＣノード２０２、２０４及び２０６のような）複数のＣノードは、異なる速度でブロックレポートを処理するかもしれず、それ故、異なる時点でセーフモードを出る閾値に到達するかもしれないからである。対照的に、クラスタ管理者がセーフモードに入るためのコマンドを発行したときには、すべてのＣノードは従うべきである。この理由のために、管理者が発行するセーフモード・コマンドは、一実施形態によれば、調整エンジン２０８を通じて調整され得る。

【0051】

上で注意したように、Ｃノードは障害を起こし、又は、メンテナンスのために意図的にダウンさせられ得る。一実施形態によれば、残りの複製されたＣノードは、調整エンジン２０８が合意を生成するために十分な定員を満たす限り、動作を継続するであろう。もし定員に満たなければ、一実施形態によれば、クラスタは定員が回復するまでフリーズし、ネームスペースに対する変更要求の処理を停止するであろう。

【0052】

以前に障害を起こしたＣノード、又は、故意にオフラインとされたＣノードがオンラインに復帰するとき、このＣノードは自動的に、その状態を他のＣノードに追いつかせるであろう。一実施形態によれば、調整エンジン２０８は、オンラインに復帰したＣノードに対し、オフラインであった間にそのＣノードが見逃したすべての合意を供給してもよい。この期間の間、オンラインに復帰したＣノードは、そのＲＰＣサーバを起動していない。それ故、クライアント及びデータノードはＣノードに接続できない（なぜなら、ＲＰＣはクライアント及びデータノードが通信する方式であるから）。このことによって、バックアップに復帰したＣノードが、要求するクライアントに対し、潜在的に古くなったデータを供給してしまうことが回避される。このプロセスは、オンラインに復帰したＣノードにデータノードが接続する前に発生する。データノード登録及び初期ブロックレポートは、Ｃノードが未だ学習しておらず、報告されたとしても捨てられてしまうであろうブロックをそのレポートが含む可能性があるため、遅らせられなければならない。

【0053】

もしＣノードが長い時間オフラインであり、かつかなりの数（これは設定可能な閾値であり得る）の合意を見逃したとすると、Ｃノードが、オフラインであった間に見逃した合意を受信し、見逃した合意の履歴全体を再生するのを待つことは、実際的でなく、又は、実行できないかもしれない。この場合、一実施形態によれば、Ｃノードに、アクティブなＣノードの１つからチェックポイントをダウンロードさせ、初期のネームスペース状態としてそのチェックポイントをロードさせ、その後、そのチェックポイントから始まる複数の合意を調整エンジン２０８から受信させ、さらに、そのチェックポイントが生成されたとき以降に提供された合意の履歴を再生させることがより効率的であり得る。そうするために、オンラインに復帰したＣノードは、チェックポイントを引き出すためのソースとしてアクティブなノードの１つ（「ヘルパー」と呼ぶ）を選択し、選択したヘルパーＣノードに対して、ＲＰＣ呼び出し（例えば、スタートチェックポイント（））を送信することができる。ヘルパーＣノードはその後、調整エンジン２０８に対してスタートチェックポイント提案を発行し、これによって、他のすべてのＣノードがそれぞれのローカルチェックポイントを同じＧＳＮに同期していることを保証する。スタートチェックポイント合意が到着すると、ヘルパーＣノードは、特定のＧＳＮ（例えば、チェックポイントＧＳＮ）まで追いついている明確に識別されたチェックポイントとして、その合意のＧＳＮを覚えておくであろう。このチェックポイントＧＳＮはその後、出現しつつあるＣノードが一旦チェックポイントを実行した場合にそれに従って学習プロセスを開始するための合意を決定する。

【0054】

オンラインに復帰したＣノードによるチェックポイントの実行は、ＨＤＦＳ標準のとおり、イメージ及びジャーナルファイルをアップロードすることによって果たされ得る。追いついた後、Ｃノードは、データノードからブロックレポートの受信を開始することができる。いったんセーフモードがオフになると、新しくオンラインに復帰したＣノードは、完全にクラスタに参加してその通常任務を再開する。

【0055】

一実施形態によれば、新しいＣノードの起動又は既存のＣノードの再起動は、以下の主な段階を含み得る。
１．オンラインに復帰したＣノードが起動し、プロポーザとしてクラスタに加わるが、ラーナーとしての能力は段階３まで沈黙状態とされる。
ａ．Ｃノードは、他のノードに関連するグローバルな履歴内における自身の状態を調査する。
２．設定可能な閾値による判定の結果、もし自身の状態が他のノードに対して実質的に遅れていれば、Ｃノードは、複数のアクティブなヘルパーノードのうちの選択された１つから、より最近のチェックポイントをダウンロードするであろう。選択されたヘルパーノードは、そのチェックポイントの生成時点での履歴の状態に対応するチェックポイントＧＳＮも提供する。
３．チェックポイントがダウンロードされたとき、オンラインに復帰したＣノードは、（もしそれが必要であれば）合意回復提案（ＡＲＰ）と呼ばれる自身の１つ目の提案を調整エンジン２０８に提出し、ラーナーとしての役割を引き受ける。
ａ．オンラインに復帰したＣノードは、チェックポイントＧＳＮ＋１からスタートすることにより、自身がオフラインであった時に見逃した合意の学習を開始できる。
４．オンラインに復帰したＣノードが自身の１つ目のＡＲＰ合意に達したとき、その巻き返しプロセスは完了したとみなされる。新たにオンラインに復帰したＣノードは今や、アクセプタとしての役割を引き受け、完全に機能するクラスタ参加者となり、調整エンジン２０８から更なる合意を受信するとともに、調整エンジン２０８に対して提案を提出することができる。
５．そうするために、新たにオンラインに復帰したＣノードは自身のＲＰＣサーバを初期化し、登録及びブロックレポートのために自身をデータノードに対して利用可能にしてもよい。レポートを処理し、セーフモードを離れた後、そのＣノードは、クラスタの他のＣノードと対等に、クライアント要求の受け入れを開始することができる。

【0056】

上述したように、一実施形態によれば、各Ｃノードは、Ｃノードに結合されるローカル持続性（不揮発性）記憶装置にネームスペースのイメージを格納することができ、それらに対する更新を行う。ここで、ローカル記憶装置（もし存在すれば）はＣノード間で共有されないように構成され得ることに注意すべきである。一実施形態によれば、各Ｃノードは、そのローカル持続性記憶装置内に、最後のネームスペース・イメージ・チェックポイントと、この最後のチェックポイント以後にネームスペースに適用されたトランザクションのジャーナルを構成するローカルな編集ファイルとを含むそれ自身のローカルイメージファイルを維持することができる。一実施形態によれば、クラスタをシャットダウンすることは、ネームスペース進展の様々な瞬間で、複数のＣノードをダウンさせる可能性がある。すなわち、幾つかのＣノードは、調整エンジン２０８から受信される合意によって指定されるすべてのトランザクションを既に適用したかもしれないが、幾つかの遅れているＣノードは、そのようなトランザクションのすべてを未だ適用していないかもしれない。それ故、シャットダウン後には、異なるＣノード上の編集ファイルは等しくない可能性がある。それ故、クラスタが再スタートするとき、遅れているＣノードは、現行状態よりも古い状態でスタートする可能性がある。しかしながら、調整エンジン２０８は、グローバルなシーケンスから、遅れているＣノードに対して見逃したイベントを供給することによって、遅れているＣノードを現行状態に強制的に引き上げるように構成され得る。

【0057】

ここで、上記の処理は、調整エンジン２０８から受信される合意の処理を通じたネームスペース状態の更新に関していくつかのＣノードが他に対して遅れ得る場合の標準的なクラスタ動作と異なるものではない、ということに注意が必要である。そのような遅れているＣノードは、クライアントからのネームスペース修正要求を依然として受け入れ、調整エンジン２０８に対して提案をするかもしれない。結果として生じる提案は、グローバルシーケンス内でそのＣノードが依然として処理しなければならないイベントの後ろに順序付けて配置され、そして、ネームスペースの状態を更新するために順を追って適用されるであろう。この方法では、新しい要求が処理される前に「期待通りの速さで」（すなわち、最新のＧＳＮまで）、遅れているＣノードを回復させることができ、それによって、クラスタの複数のＣノードにわたってネームスペースの状態が一貫性を維持することが可能になる。一実施形態によれば、起動中のＣノードの持続的状態の不一致は、「きれいな」シャットダウン手続きを実施することによって、回避され得る。

【0058】

一実施形態によれば、きれいなシャットダウン手続きは、クラスタがシャットダウンされる前にすべてのＣノードを強制的に共通の状態にするために提供され得る。きれいなシャットダウンを実行することの結果として、複数のＣノードのそれぞれに結合された持続性のローカルメモリ内に格納されているネームスペースのローカルイメージのすべてが同一となり、それらに対する更新を一連の空のトランザクションによって表すことが可能になる。一実施形態によれば、きれいにシャットダウンし、ネームスペースのすべてのローカルイメージを強制的に同一にするため、各Ｃノードは、調整エンジン２０８によってＣノードに送信された合意の残りについての処理が行われている間、クライアントによるネームスペースの修正要求の処理を止めるセーフモード動作に入るように命令され得る。その後は、ネームスペースを保存するための動作を実行することができ、それによって、ネームスペースのローカルチェックポイントを生成し、ジャーナルを空にすることが可能になる。Ｃノードのプロセスを強制終了する前には、すべてのＣノードが（今や複数のＣノードにわたって同一である）ネームスペースの自身での保存を完了し、そのネームスペースのそれぞれのローカルチェックポイントを生成し、それによってすべてのＣノートが同じネームスペースから再スタートできることが保証され得る。その後、Ｃノードプロセスを強制終了することが可能になる。きれいなシャットダウンの後、後に続く任意の起動処理は、Ｃノードがきれいにシャットダウンされなかったケースよりも速く進むであろう。どのＣノードも、編集や見逃した更新を、（シャットダウンの前にすべてが同一状態に置かれているため）調整エンジン２０８から適用する必要がないからである。

【0059】

本開示の一定の実施形態を説明したが、これらの実施形態は例としてのみ提示されたものであり、本開示の範囲を制限することを意図したものではない。実のところ、本明細書で説明した新規なコンピュータ実行方法、装置、及びシステムは、様々な他の形態で具体化され得る。例えば、一実施形態は、コンピュータ装置によって実行されたときに、本明細書に記述ないし示した分散ファイルシステムをそのコンピュータ装置に実行させる複数の命令列を表すデータを格納する有形で非一時的なマシン可読媒体を含む。一例では、上記複数の命令列はダウンロードされることができ、かつその後、例えば（例えば、図７において７０２で示したような）メモリ装置、（固定又は回転媒体の）記憶装置、又は、他のデータキャリア上に格納されることができる。一実施形態によれば、命令は、少なくとも２つのネームノードを複数のデータノードに結合すること（複数のネームノードはそれぞれ、クラスタのネームスペースの状態を格納するように構成されるとともに、他の少なくとも１つのネームノードが別のクライアントからの別の要求に応答すると同時に各々がクライアントからの要求に応答するように構成される）、ネームノードから提案を受信して、複数のデータノードの１つ以上の中に／から／に対して、データブロックを複製し、削除し、及び／又は付加することによってネームスペースの状態を変更すること、並びに、提案の受信に応じて、ネームノードによるネームスペースの状態変更の順序を特定する順序付けられた一連の合意を生成し、それによって、順序付けられた一連の合意をネームノードが受信するまでの間、ネームスペースの状態に変更を加えることを遅らせること、についての命令を含む。さらに、本明細書で説明した方法及びシステムの形態における様々な省略、置換、及び変更が、本開示の趣旨から外れることなくなされ得る。添付した請求項及びそれらの等価物は、本開示の範囲及び精神に含まれながらもそのような形態又は修正を含むように意図されている。例えば当業者は、様々な実施形態において、実際の物理的及び論理的構造が図示したものと異なり得ると認識するであろう。実施形態によっては、上記の例で説明したあるステップは除去されるかもしれず、他のステップが付加されるかもしれない。また、上で開示した特定の実施形態の特徴及び属性は、追加の実施形態を構成するために様々な方法で結合されることができ、それらの実施形態はすべて本開示の範囲内に含まれる。本開示は、一定の好ましい実施形態及びアプリケーションを提供しているが、本明細書で明らかにされた特徴及び利点のすべてを提供しない実施形態を含めて、当業者にとって明白である他の実施形態もまた、本開示の範囲内にある。従って、本開示の範囲は、添付された請求項を参照することによってのみ定義されることが意図される。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】