特許 7009488 データセンタにわたってメタデータおよびデータの整合性を維持するための方法、デバイス、およびシステム

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

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

(11)【特許番号】

(24)【登録日】2022-01-14

(45)【発行日】2022-01-25

(54)【発明の名称】データセンタにわたってメタデータおよびデータの整合性を維持するための方法、デバイス、およびシステム

(51)【国際特許分類】

   G06F 16/182 20190101AFI20220118BHJP

   G06F 16/14 20190101ALI20220118BHJP

   G06F 16/172 20190101ALI20220118BHJP

【ＦＩ】

G06F16/182

G06F16/14

G06F16/172

【請求項の数】 18

(21)【出願番号】P 2019545967

(86)(22)【出願日】2018-03-12

(65)【公表番号】

(43)【公表日】2020-05-21

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

(87)【国際公開番号】W WO2018169886

(87)【国際公開日】2018-09-20

【審査請求日】2021-01-21

(31)【優先権主張番号】15/457,837

(32)【優先日】2017-03-13

(33)【優先権主張国・地域又は機関】US

(73)【特許権者】

【識別番号】515154894

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

(74)【代理人】

【識別番号】100115738

【弁理士】

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

(74)【代理人】

【識別番号】100121681

【弁理士】

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

(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】

前記第２のデータセンタに記憶されるデータに対する前記第１のデータセンタにおける前記第１のデータレプリケーションサーバによって出される全ての要求は、前記第２のデータセンタにおける前記第２のバージョンブリッジサーバによって使用可能にされ、前記第１のデータセンタに記憶されるデータに対する前記第２のデータセンタにおける前記第２のデータレプリケーションサーバによって出される全ての要求は、前記第１のデータセンタにおける前記第１のバージョンブリッジサーバによって使用可能にされる、請求項１５乃至１７のいずれか一項に記載のコンピュータ実施システム。

【発明の詳細な説明】

【技術分野】

【0001】

本明細書に開示された実施形態の分野は、分散ファイルシステムを含む。とりわけ、実施形態は、例えば、インターネットを含むことができる広域ネットワーク（ＷＡＮ）上で分散ファイルシステムにおけるレプリケートファイルフォルダの整合性を維持するための方法、デバイス、およびシステムに関する。

【図面の簡単な説明】

【0002】

【図1】実施形態による、方法、デバイス、およびシステムの実装に適する分散ファイルシステム実装形態の図である。

【0003】

【図2】コンピュータネットワークに結合されるローカルおよびリモートデータセンタの図である。

【0004】

【図3】実施形態による、コンピュータ実施システムおよび方法のコンピュータネットワークおよび態様に結合されるデータセンタを示す図である。

【0005】

【図4】実施形態による、コンピュータ実施システムおよび方法のコンピュータネットワークおよび態様に結合されるデータセンタを示す図である。

【0006】

【図5】実施形態による、コンピュータ実施システムおよび方法のコンピュータネットワークおよび態様に結合されるデータセンタを示す図である。

【0007】

【図6】１つの実施形態によるコンピュータ実施方法のフローチャートである。

【0008】

【図7】１つの実施形態によるコンピュータ実施方法のフローチャートである。

【0009】

【図8】１つの実施形態によるコンピュータ実施方法のフローチャートである。

【0010】

【図9】一実施形態の態様が実践可能であるハードウェアコンピューティングデバイスのブロック図である。

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

【0011】

Ｈａｄｏｏｐ互換ファイルシステム（ＨＣＦＳ）名前空間は、ファイルおよびディレクトリの階層構造である。Ｈａｄｏｏｐは、分散コンピューティング環境におけるかなり大きいデータセットの処理および記憶をサポートするオープンソースのＪａｖａベースのプログラミングフレームワークであり、これはＡｐａｃｈｅ Ｓｏｆｔｗａｒｅ Ｆｏｕｎｄａｔｉｏｎが提供しているＡｐａｃｈｅプロジェクトの一部である。ファイルおよびディレクトリは、ＩｎｏｄｅによってＮａｍｅＮｏｄｅ上に表される。Ｉｎｏｄｅは、許可、修正、およびアクセス時間、名前空間、およびディスク空間割り当てを記録する。ファイルコンテンツは、大きいデータブロック（典型的に１２８ＭＢ）に分割され、ファイルのそれぞれのデータブロックは複数のＤａｔａＮｏｄｅ（典型的には３つ）で独立してレプリケートされる。ＨＣＦＳの１つの実装形態は、Ｈａｄｏｏｐ分散ファイルシステム（ＨＤＦＳ）である。ＮａｍｅＮｏｄｅは、名前空間動作を担うＨＤＦＳのメタデータサービスである。ＮａｍｅＮｏｄｅは、名前空間ツリー、およびＤａｔａＮｏｄｅへのブロックのマッピングを維持する。すなわち、ＮａｍｅＮｏｄｅはＨａｄｏｏｐクラスタ内のデータの場所を追跡し、かつこの場所へクライアントアクセスを調整する。従来、それぞれのクラスタは単一のＮａｍｅＮｏｄｅを有する。クラスタは、それぞれのＤａｔａＮｏｄｅが複数のアプリケーションタスクを同時に実行できるように、クラスタごとに、何千ものＤａｔａＮｏｄｅおよび何万ものＨＤＦＳクライアントを有することができる。Ｉｎｏｄｅ、および名前システムのメタデータを定義するデータブロックのリストは画像と呼ばれる。ＮａｍｅＮｏｄｅはランダムアクセスメモリ（ＲＡＭ）において全名前空間画像を保持する。

【0012】

分散ファイルシステムのノード間のシステム整合性を維持するために、ノード間のさまざまな分散イベントの調整が必要になる場合がある。全てのノードによって一貫して学習されなければならない特定のイベントを調整する最も簡易なやり方は、指定される単一のマスタを選定し、かつそのイベントをマスタ上に記録することで、他のノードがマスタからイベントを知ることができるようにすることである。このアプローチは、簡易であるが、単一のマスタの障害によって全システムの進行がストールするため、信頼性がない。これを認識して、従来のＨＤＦＳ実装形態は、通常動作中にアクセスされるアクティブＮａｍｅＮｏｄｅ、およびアクティブＮａｍｅＮｏｄｅの障害が生じる場合にフェイルオーバーとして使用されるスタンバイＮａｍｅＮｏｄｅと呼ばれるバックアップを使用する。

【0013】

しかしながら、これは次善の解決策であると考えらえる。例えば、この方式では、トランザクションジャーナル（複数可）自体は、単一障害点になる。実際は、トランザクションジャーナル（複数可）の破損時に、スタンバイＮａｍｅＮｏｄｅはもはや、アクティブＮａｍｅＮｏｄｅと同じ状態を想定することができず、アクティブＮａｍｅＮｏｄｅからスタンバイＮａｍｅＮｏｄｅへのフェイルオーバーはもはや可能ではない。

【0014】

さらに、クラスタごとのアクティブＮａｍｅＮｏｄｅを１つのみサポートするＨａｄｏｏｐ解決策において、スタンバイサーバは、上記のように、典型的には、ネットワーク接続ストレージ（ＮＡＳ）デバイスを介して同期して保持される。アクティブＮａｍｅＮｏｄｅが作動しなくなり、スタンバイＮａｍｅＮｏｄｅが引き継がなければならない場合、アクティブＮａｍｅＮｏｄｅに書き込まれた変更がＮＡＳにまだ書き込まれていない場合、データ損失の可能性がある。フェイルオーバー中の管理者のエラーによって、さらなるデータ損失が引き起こされる可能性がある。また、アクティブサーバがスタンバイサーバと通信できないが、クラスタにおける他のマシンと通信できるネットワーク障害が生じ、かつスタンバイサーバが、アクティブサーバが機能しないと誤って想定し、かつアクティブな役割を引き継ぐ場合、「分離脳」として知られる異常なネットワークの状態が生じる可能性があり、この場合、２つのノードは、それらがアクティブＮａｍｅＮｏｄｅであると考え、この状態によってデータ破損が引き起こされる可能性がある。

【0015】

（名前空間の状態をメンバーシップに変更する提案を行う人を処理する）提案部、（名前空間の状態を変更する提案がメンバーシップによって合意されるべきであるかどうかについて投票する人を処理する）受け入れ部、および、（メンバーシップにおいて、行われた合意を知る人を処理する）学習部の役割は、例えば、全体が本明細書に組み込まれている、Ｌａｍｐｏｒｔ、Ｌ．、Ｔｈｅ Ｐａｒｔ－Ｔｉｍｅ Ｐａｒｌｉａｍｅｎｔ、ＡＣＭ Ｔｒａｎｓａｃｔｉｏｎｓ ｏｎ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍｓ １６、２（１９９８年、５月）、１３３－１６９に説明されるＰａｘｏｓアルゴリズムの実装形態に定義されている。１つの実施形態によると、複数のノードは役割のそれぞれを実行するように構成されてよい。調整エンジンによって、複数の学習部は高い可用性を実現するために複数の受け入れ部を活用して複数の提案部によってエンジンに送られるイベントの順序について合意できるようにしてよい。信頼性、可用性、およびスケーラビリティを実現するために、複数の同時のアクティブＮａｍｅＮｏｄｅ（総称してメタデータサーバと考えられてよい）は、名前空間がレプリケートされるノードの状態がこのようなノード間で整合したままにするという要件で、複数のノード上の名前空間の状態をレプリケートすることによって提供されてよい。

【0016】

ＮａｍｅＮｏｄｅ間のこの整合性は、調整エンジンによって保証されてよく、この調整エンジンは、名前空間を更新するための提案を受け入れ、この提案を更新のグローバルシーケンスに合理化し、さらにまた、ＮａｍｅＮｏｄｅが合意済み順序でそれらの個々の状態に対する更新を知りかつ適用することのみできるようにするように構成されてよい。本明細書において、「整合性」は、Ａｄｄｉｓｏｎ Ｗｅｓｌｅｙ、１９８７年、第６、７、および８章によって公開された、Ｂｅｒｎｓｔｅｉｎらによる「Ｃｏｎｃｕｒｒｅｎｃｙ Ｃｏｎｔｒｏｌ ＆ Ｒｅｃｏｖｅｒｙ ｉｎ Ｄａｔａｂａｓｅ Ｓｙｓｔｅｍｓ」に詳述されるような１コピー等価性（Ｏｎｅ－Ｃｏｐｙ Ｅｑｕｉｖａｌｅｎｃｅ）を意味し、この全体が本明細書に組み込まれている。ＮａｍｅＮｏｄｅが同じ状態から開始し、かつ同じ決定論的順序で同じ決定論的更新を適用するため、それらの各状態は整合しておりかつ整合したままである。

【0017】

従って、１つの実施形態によると、名前空間は、
ａ）それぞれのノードがその名前空間レプリカを修正することが可能である、および
ｂ）名前空間レプリカがノードにわたって互いに整合したままであるように、１つの名前空間レプリカに対する更新が他のノード上での名前空間レプリカに伝達されなければならないことを条件として、複数のＮａｍｅＮｏｄｅ（またはより一般的には、メタデータサーバ）上でレプリケートされてよい。

【0018】

図１は、ＷＡＮ環境において特定の有用性を見出す１つの実施形態による分散ファイルシステムの図である。図１はまた、レプリケート状態マシンモデルに基づく分散されたＨＣＦＳ（例えば、ＨＤＦＳなど）についてＷＡＮ上で適用可能なレプリケーション方法の態様も示す。１つの実施形態によると、ＮａｍｅＮｏｄｅは、種々の地理的に分散したデータセンタに位置する。このようなデータセンタは、例えば、種々の大陸に位置することができる。例えば、インターネット、および／または、プライベートもしくは独自のＷＡＮを含む、例えば、ＷＡＮ上のＨＣＦＳクラスタに及ぶ分散ファイルシステムに適用可能である実施形態が本明細書に記載されている。

【0019】

アーキテクチャ概要
図１は、１つの実施形態による、ＷＡＮに及ぶクラスタおよび分散ファイルシステムのコンポーネントのブロック図である。そこに示されるように、１つの実施形態による分散ファイルシステム１０２を起動する（例えば単一の）クラスタは、２つ以上のデータセンタ、すなわち、データセンタＡ（ＤＣＡ）１０４およびデータセンタＢ（ＤＣＢ）１０６を含んでよい。ＤＣＡ１０４およびＤＣＢ１０６は互いに地理的に遠隔であってよい。例えば、ＤＣＡ１０４およびＤＣＢ１０６は単一の国の種々の地域に位置してよく、種々の大陸、種々の時間帯において分散されてよく、完全に独立した配電網から引き込んでよい。ＤＣＡ１０４およびＤＣＢ１０６は、例えば、インターネットならびに／または他のプライベートおよび／もしくは独自のネットワークを含んでよいＷＡＮ１０８を介して互いに緩く結合されてよい。ＤＣＡ１０４およびＤＣＢ１０６はまた、他の専用の高速接続によって結合されてよい。２つのデータセンタ１０４、１０６のみが図１に示されているが、実施形態がより多数のデータセンタを含んでよく、かつ分散ファイルシステム１０２がこのようなデータセンタ全てにわたって拡張することは理解されたい。

【0020】

示されるように、ＤＣＡ１０４は、「ＭＤＳ」として図に示される、複数の（例えば、スタンバイまたはフェイルオーバーとは対照的に）アクティブなメタデータサーバ（であるが、Ｈａｄｏｏｐ ＮａｍｅＮｏｄｅが１つの可能な実装形態である）を含んでよい。このように、ＤＣＡ１０４は、参照番号１１０、１１２、および１１４によって示されるＭＤＳを含んでよく、ＤＣＢ１０６は、参照番号１１６、１１８、および１２０によって示されるＭＤＳを含んでよい。ＭＤＳ１１０、１１２、１１４、１１６、１１８、および１２０のそれぞれは、分散ファイルシステムの名前空間の状態を記憶するように、および単一の名前空間がＭＤＳおよびデータセンタにわたって整合することを維持するように構成されてよい。ＭＤＳ間の調整、およびＭＤＳにわたる単一の名前空間のメンテナンスの態様は、分散調整エンジン（ＣＥ）プロセス１２２によって提供されてよい。図１において、ＣＥプロセス１２２は、ＤＣＡ１０４、ＤＣＢ１０６、およびＷＡＮ１０８に及ぶ別個の論理エンティティであることを示唆するように示される。しかしながら、１つの実施形態によると、上でおよび以下に説明されるＣＥ１２２の機能性は、ＭＤＳ１１０、１１２、１１４、１１６、１１８、および１２０のそれぞれによって遂行されてよい。すなわち、ＭＤＳ１１０、１１２、１１４、１１６、１１８、および１２０のそれぞれは、いくつかある機能の中で特に、ＣＥ１２２の役目の一部または全てを実行するように構成されてよい。

【0021】

ＤＣＡ１０４は、図１では「ＤＮ」として参照される複数のＤａｔａＮｏｄｅ１２４、１２６、１２８、１３０を含んでよい。同様に、ＤＣＢ１０６はまた、図１において「ＤＮ」として参照される複数のＤａｔａＮｏｄｅ１３２、１３４、１３６、１３８を含んでよい。示されるように、ＤａｔａＮｏｄｅ１２４、１２６、１２８、１３０のそれぞれは、ＤＣＡ１０４のＭＤＳ１１０、１１２、および１１４のそれぞれに結合されかつこれと通信するように構成されてよい。さらに示されるように、ＤａｔａＮｏｄｅ１３２、１３４、１３６、１３８のそれぞれは、ＤＣＢ１０６のＭＤＳ１１６、１１８、および１２０のそれぞれに結合されかつこれと通信するように構成されてよい。１つの実施形態によると、ＭＤＳはＤａｔａＮｏｄｅと直接通信しない場合がある。実際は、１つの実施形態によると、ＤａｔａＮｏｄｅはＭＤＳに要求を送るように構成されてよく、これに従って、ＭＤＳは受信した要求に応答してＤａｔａＮｏｄｅにコマンドを出す。従って、ＭＤＳがＤａｔａＮｏｄｅを制御すると考えられる場合があるが、ＤａｔａＮｏｄｅは、１つの実施形態によると、ＭＤＳに要求を送ることでそこからコマンドを受信するように構成されてよい。ＤＣＡ１０４には４つのＤａｔａＮｏｄｅ１２４、１２６、１２８、１３０が示されている。同様に、ＤＣＢ１０６には４つのＤａｔａＮｏｄｅ１３２、１３４、１３６、および１３８が示されている。しかしながら、データセンタ１０４および１０６はそれぞれ、図１に示されるよりもさらに多くの（例えば、何千もの）データノードを含んでよい。

【0022】

３つのＭＤＳ１１０、１１２、１１４はＤＣＡ１０４内に設けられていると示されているが、より多くのＭＤＳがＤＣＡ１０４内に設けられてよい。同様に、３つのＭＤＳ１１６、１１８、１２０がＤＣＢ１０６内に設けられていると示されているが、より多くのＭＤＳがＤＣＢ１０６内に設けられてよい。１つの実施形態によると、データセンタ内のＭＤＳの数は奇数となるように選択されてよい。

【0023】

１つの実施形態によると、図１は、種々の地理的に分離したデータセンタに及ぶ単一の分散ファイルシステムを起動するクラスタを示す。分散ファイルシステムは例えば、ＨＤＦＳの態様を組み込んでよい。ＤａｔａＮｏｄｅのそれぞれは、これら自体のデータセンタ内のＭＤＳとのみ（ＤａｔａＮｏｄｅ－ＮａｍｅＮｏｄｅ間リモートプロシージャコール（ＲＰＣ）プロトコルを通して）通信するように構成されてよい。逆に、データセンタのＭＤＳは、それら自体のデータセンタ内のＤａｔａＮｏｄｅのみを制御するように構成されてよい。すなわち、データセンタ１０４のＤａｔａＮｏｄｅは、１つの実施形態によると、それら自体のデータセンタ１０４のＭＤＳと通信することだけでき、データセンタ１０６のデータノードは、それら自体のデータセンタ１０６のＭＤＳと通信することだけできる。データセンタ１０４、１０６両方のＭＤＳは、名前空間の状態を、調整エンジン１２２を通して整合するように維持するために互いに調整する。１つのデータセンタのデータノードは他のデータセンタ（単数または複数）のデータノードと通信してよい。

【0024】

１つの実施形態によると、ＣＥプロセス１２２は、名前空間の状態への同じ決定論的更新が全てのＭＤＳ上の同じ決定論的順序で適用されることを保証するように構成されてよい。１つの実施形態によると、決定論的順序はグローバルシーケンス番号（ＧＳＮ）によって定義される。従って、ＣＥプロセス１２２の大きな役割は、１つの実施形態によると、全てのＭＤＳからの名前空間の状態を修正あるいは更新し、かつそれらを合意の大域的に順序付けられたシーケンスに変換する提案を処理することである。ＭＤＳはさらにまた、それらの記憶された状態への更新としてのその順序付けられたシーケンスからの合意を順次適用してよい。１つの実施形態によると、ＧＳＮは一意の単調増加数として構成されてよい。しかしながら、ＧＳＮは、その他の場合、当業者が認識できるように構成されてよい。ＧＳＮはさらにまた、名前空間の状態を更新し、かつ名前空間の状態がＭＤＳにわたって整合するように保持する（または、ＭＤＳのそれぞれに記憶された名前空間の状態を、合意の大域的に順序付けられたシーケンスの順次の適用を通して経時的に整合させる）際に種々のＭＤＳの進行を比較するために使用されてよい。例えば、ＭＤＳ１１０が、まさにＭＤＳ１１２によって処理したＧＳＮ２より小さい、ＧＳＮ１と番号付けされた合意をまさに処理した場合、ＭＤＳ１１０はＭＤＳ１１２よりも早い名前空間状態を有する。ＭＤＳ１１０によって記憶された名前空間の状態は、ＭＤＳ１１２が暫定的により大きい番号が付けられた合意を処理していないことを条件として、ＭＤＳ１１０がＧＳＮ２を処理するとすぐにＭＤＳ１１２によって記憶されるものにマッチすることになる。このように、ＣＥプロセス１２２によって生成された合意の（ＧＳＮ機構を通して）順序付けられたセットの順次的な実行を通して、データセンタのそれぞれにおけるＭＤＳのそれぞれに記憶された名前空間の状態は、整合させる、または整合性が維持される。

【0025】

１つの実施形態によると、それぞれの動作によって、クライアントは、クライアントが現在接続されているＭＤＳ上で処理される最新のＧＳＮについて学習する。その後、クライアントが別のＭＤＳに切り換える場合、１つの実施形態によると、最初、新しいＭＤＳが書き込みなどのデータアクセスコマンドを含むＲＰＣを出す前にクライアントが知っている最新のＧＳＮ（すなわち、クライアントが以前にアクセスしたＭＤＳから受信したＭＤＳ）に追い付くまで（必要に応じて）待機するものとする。これによって古くなった読み出し問題が回避されることになる。ＭＤＳが同じ状態から開始するため、更新のこの順序付けられた適用は、同じＧＳＮにおける合意を処理している種々のノード上で取られたそれについてのスナップショットが、データセンタ内でおよびこれにわたる両方で同一であるというレプリカの整合性を含意する。

【0026】

１つの実施形態は、ＣＥプロセス１２２が合意を送達すると瞬時に（または、ネットワークに固有の帯域幅およびレイテンシを考慮してほぼ瞬時に）ＭＤＳ１１０、１１２、１１４、１１６、１１８、１２０間の全てのメタデータを調整する。同様に、全てのファイルシステムデータはまた、クラスタの複数のデータセンタにわたって自動的にレプリケートされる。１つの実施形態は、（例えば、限定はされないが、Ｈａｄｏｏｐ）クラスタにおけるファイルシステム間の、整合する連続的なデータレプリケーションをもたらす。クライアントアプリケーションは、複数のクラスタにわたって基礎を成すストレージを統合する仮想ファイルシステムと相互作用するように構成されてよい。１つのクラスタにおいてファイルに変更が行われる時、それらの変更は他に及ぶクラスタと整合するようにレプリケートされる。１つの実施形態は、Ｈａｄｏｏｐ展開によって、例えば、ＣＤＨ、ＨＤＰ、ＥＭＣ Ｉｓｉｌｏｎ、Ａｍａｚｏｎ Ｓ３／ＥＭＲＦＳ、およびＭａｐＲなどの、Ｈａｄｏｏｐの種々の、さらには非互換のバージョンを起動している（例えば、Ｈａｄｏｏｐ）クラスタ間のＨＣＦＳデータをレプリケートすることが可能になるソフトウェアアプリケーションを含んでよい。また、１つの実装形態によると、Ｈａｄｏｏｐの種々のベンダ分散およびバージョンの間でレプリケートすることが可能である。

【0027】

有利には、実施形態によって、全てのＨａｄｏｏｐアプリケーションと互換性があるＨａｄｏｏｐ、種々のタイプのＨａｄｏｏｐからストレージを統合する単一の仮想名前空間、大域的に分散したストレージ機構、およびアクティブ／アクティブレプリケーション技術を使用して、広範囲に及ぶデータセンタ間でレプリケートされた、単一コピー整合ＨＤＦＳデータを送達するＷＡＮレプリケーションのための仮想ファイルシステムを提供する。

【0028】

１つの実施形態によると、本明細書に説明される機能性の一部または全ては、Ｈａｄｏｏｐスタックにおいてより高いレベルで、例えば、アクティブなＭＤＳおよび調整エンジンから離れてＨａｄｏｏｐクラスタに隣接するサーバ（単数または複数）内で実行されてよい。このように、ＮａｍｅＮｏｄｅレベルで深く機能するのではなく、１つの実施形態は、Ｈａｄｏｏｐファイルシステムに対する代理アプリケーションとして動作するように構成されてよい。

【0029】

実施形態は、必要に応じて追加の処理能力を入手するために、例えば、Ａｍａｚｏｎ Ｗｅｂ Ｓｅｒｖｉｃｅｓ（ＡＷＳ）などのリモートクラウドサービス、オンデマンド計算能力を供給するプラットフォーム、データベースストレージ、コンテンツ配信、および他の機能性にデータを転送することによって、クラウドにおける処理能力を増大させるように構成されてよい。

【0030】

さらに、実施形態は、可能なものをいくつか挙げると、例えば、２つのＨｏｒｔｏｎｗｏｒｋｓクラスタ間といった、ＨｏｒｔｏｎｗｏｒｋｓとＣｌｏｕｄｅｒａとの間、およびＥＭＣのＩｓｉｌｏｎストレージシステムをレプリケートする能力など、種々のＨａｄｏｏｐ分散にわたる同期を可能にする。ＨＢａｓｅサーバによる同期も適応させてよい。Ｈｂａｓｅは、ＧｏｏｇｌｅのＢｉｇＴａｂｌｅの後にモデリングされた、オープンソースの非関係の分散データベースであり、Ｊａｖａで書き込まれる。Ｈｂａｓｅは、Ａｐａｃｈｅ Ｓｏｆｔｗａｒｅ ＦｏｕｎｄａｔｉｏｎのＡｐａｃｈｅ Ｈａｄｏｏｐプロジェクトの一部として開発されたものであり、Ｈａｄｏｏｐに対するＢｉｇＴａｂｌｅのような機能を提供するように、ＨＤＦＳに加えて起動する。

【0031】

１つの実施形態では、図２に示されるように、データレプリケーションサーバ２０４、２０６、２０８のマジョリティクォーラムによって、コンピュータネットワーク２０２上で、合意されるＰａｘｏｓ合意を使用して同期的にメタデータ動作（例えば、ファイルを作成する）をレプリケートする。示されるように、コンピュータネットワーク２０２は、ＷＡＮ（広域ネットワーク）リンクによって接続される世界中の多数の場所に及んでよい。メタデータ動作と関連付けられてよいデータ動作（例えば、ファイルデータを書き込む）は、多くはメタデータ動作の後に調整なしで非同期的にレプリケートされる。すなわち、ファイル作成メタデータ動作と関連付けられた分散ファイルシステムストレージ２１０、２１２、および２１８への書き込みは、複数のデータレプリケーションサーバ２０４、２０６、２０８の間の調整なく、非同期的に実行されてよい。これは、レプリケート元データセンタ（ＤＣＯ）２１４における記憶性能は、悪影響を受けないが、リモートデータセンタ（ＲＤＣ）は、ＲＤＣ２１６における分散ファイルシステムストレージ２１２に対してＤＣＯ２１４における分散ファイルシステムストレージ２１０に書き込まれたデータをレプリケートしているように徹底するためである。しかしながら、これらの非調整データ書き込み動作によってウィンドウが開き、暫定的に、同じファイルオブジェクト上での後続のメタデータ動作によって、このような非調整データコピー動作を行うことができないようにしてよい。例えば、ファイルネームまたはパスは、非調整データ書き込み動作のうちの１つが実行されていた間に変更可能であり、これによって、データ書き込み動作を行うことができないようになる。

【0032】

このような問題の実例には、ＤＣＯ２１４のクライアントが、ファイル、例えば「ｆｏｏ．ｔｍｐ」を作成し、２００ＭＢのデータをファイルに書き込み、これを閉じ、その後、「ｆｏｏ．ｔｍｐ」ファイルを「ｆｏｏ」に名前変更する。ＲＤＣ（複数可）２１６におけるデータレプリケーションサーバ（複数可）は、「ｆｏｏ．ｔｍｐ」についてのファイル作成動作についてのメタデータをとらえることになるが、これが２００ＭＢのデータをコピーしている間、ＤＣＯにおけるデータレプリケーションサーバは、「ｆｏｏ．ｔｍｐをｆｏｏに名前変更する」という合意を実行してよいことで、取り出される場所にはもはや存在しないファイル「ｆｏｏ．ｔｍｐ」から２００ＭＢのデータを取り出しているため、ＲＤＣへの「ｆｏｏ．ｔｍｐ」データのレプリケーションを行うことができなくなる。

【0033】

１つの実装形態は、ファイルのデータが非同期的に取り出されている間にファイルを名前変更する時にＤＣＯ２１４からＲＤＣ２１６へのデータの取り出しを再開する。実際は、ファイルクローズ時に開始されたデータ取り出しは、介在するファイル名前変更動作により行うことができない。これを克服するために、名前変更動作では、ファイルが非整合であるかどうかをとらえるためにチェックし、非整合である場合、取り出すデータのＤＣＯソースとしての名前変更先による取り出しを再開する。

【0034】

別の実施形態では、より有利には、ファイル名前変更、またはデータがレプリケートされるファイルに対するパスへの変更などの動作の後のデータレプリケーションの失敗を防止するためにデータセンタにわたるメタデータ変更を追跡する。本開示は、このような同期メタデータおよび非同期データレプリケーションシステムの実施形態について説明している。

【0035】

設計原理
ビッグデータレプリケーションプラットフォーム上でのその展開に関連して、１つの実施形態は、以下の３つの設計原理を具現化するように構成されてよい。
１．限定ではないが、クライアント、データレプリケーションサーバ、またはバージョンブリッジサーバを含む、以降に説明されるコンピューティングコンポーネントのいずれかにおいて記憶またはキャッシュされるデータはない。実際は、１つの実施形態は、合意済み提案のメタデータ動作をキャッシュすることによって実施されてよく、このような動作と関連付けられるデータはない。
２．リモートデータセンタクライアント（データが元々書き込まれていたＤＣＯ２１４のデータセンタクライアントとは対照的に、データがレプリケートされるＲＤＣ２１６のデータセンタクライアント）は、ＧＳＮの機構を使用して、基礎を成すストレージの時点で整合しているメタデータのビューをとらえることになる。すなわち、クラスタにわたる名前空間、およびレプリケートされたフォルダの状態は、データセンタにわたって同じＧＳＮで同一となる。しかしながら、データは不完全である場合がある。換言すれば、リモートクライアントは、ファイルの存在を（このメタデータが同期的にキャッシュされているため）とらえることができるが、この基礎を成すデータはまだ完全に書き込まれていない場合がある。この挙動は、ビッグデータストレージシステムの単一データセンタインスタンスにおいて一括読み出し部による遅い書き込み部の挙動を再現している。
３．ＲＤＣクライアントは、そのファイルシステムの時点に属していないデータをとらえることはないし、さらに以下で進展するように、ファイルの異なる時点からデータの混合をとらえることもない。

【0036】

開示された実施形態の正確さを検証する
正確さを証明する最も簡易なやり方は、後続のメタデータ動作における同じパスに変更がなされる場合にいずれのデータ取り出し（すなわち、データをＤＣＯからＲＤＣに取り出すこと）を中止させることである。ファイルは非整合とマーキングされ、非整合を補正するための修復が行われる。このチェックは、レプリケーションサービスの最小知識、すなわち、基礎を成すストアのファイルシステム意味論の知識で行われ得る。

【0037】

設計
まさに、直上に列挙された正確さ基準を満たすことが考えられる単純な実装は、多くの中止および修復動作をもたらすことになって、レプリケートされたフォルダを非整合にし、かつ分散システムの効率が低下する。それ故に、本明細書に説明される実施形態は、基礎を成すストレージシステムのファイルシステム意味論に基づく最適化を提供する。

【0038】

１つの実施形態によると、ＤＣＯ２１４またはＲＤＣ２１６のどちらかにおけるデータ取り出し動作の失敗によって、名前マッピングサービスを使用して動作が再開されることになる場合がある。実際は、ＤＣＯ２１４からＲＤＣ２１６へのデータ取り出し動作は、ＤＣＯ２１４における読み出し動作およびＲＤＣ２１６における書き込み動作の両方を必要とする。どちらかを行うことができない場合、本明細書ではＭａｐＦｉｌｅｎａｍｅとも示される名前マッピングサービス、アプリケーションプログラムインターフェース（ＡＰＩ）を使用して再試行される。これらの最適化、および名前マッピングサービスの展開は、１つの実施形態によると、それぞれの合意において行われるファイルシステム動作について記憶されるより詳細な情報を必要とする。

【0039】

１つの実施形態によると、拡張は次の３つの態様、
１．実行合意キャッシュ３０９、３１１における実行合意をキャッシュするための、およびこの実行合意キャッシュ３０９、３１１を使用してＭａｐＦｉｌｅｎａｍｅ ＡＰＩを実装するための、データレプリケーションサーバ２０６、２０８（図２）、３０８、３１０（図３）に対する拡張、
２．名前マッピングサービスＭａｐＦｉｌｅｎａｍｅにＤＣＯ２１４におけるソースファイル名を求めるためのバージョンブリッジサーバ３１２の展開、および
３．名前マッピングサービスにＲＤＣ２１６におけるターゲットファイル名を求めるためのデータレプリケーションサーバ３１０に対する拡張、および名前マッピングサービスにＲＤＣ２１６におけるソースファイル名を求めるためのバージョンブリッジサーバ３１４の対応する展開、を含むことができる。

【0040】

図３は、１つの実施形態による、コンピュータ実施方法およびシステムの態様を示すブロック図である。示されるように、参照番号２１４はＤＣＯを示し、参照番号２１６はＲＤＣを示すが、名称は入れ替えられる可能性がある。ＤＣＯ２１４およびＲＤＣ２１６は、１つまたは複数のコンピュータネットワーク３０２を介して緩く結合されてよく、球体３０１によって示唆されるように、地理的に分離されてよい。ＤＣＯ２１４において、クライアントアプリケーション３０４は、データレプリケーションサーバ３０８にデータアクセスコマンドを出すためにクライアントライブラリを利用してよい。同様に、ＲＤＣ２１６において、クライアントアプリケーション３０６は、データレプリケーションサーバ３１０にデータアクセスコマンドを出すためにクライアントライブラリを利用してよい。データレプリケーションサーバ３０８は、１つの実施形態によると、（実行合意キャッシュ３０９として図３に示される）キャッシュ３０９における、レプリケートされたフォルダの状態を変更するための合意のメタデータ、および合意の関連付けられたＧＮＳをキャッシュし、データレプリケーションサーバ３１０はまた、キャッシュ３１１における、合意のメタデータ、および関連付けられたＧＮＳをキャッシュする。キャッシュ３０９、３１１は、後述されるように、互いに整合するように維持される。１つの実施形態によって、ＤＣＯ２１４におけるバージョンブリッジサーバ３１２、およびＲＤＣ２１６におけるバージョンブリッジサーバ３１４が設けられる。最後に、ＤＣＯ２１４およびＲＤＣ２１６のそれぞれは、３１６、３１８に示されるように、ストレージを含み、このストレージは、実行合意キャッシュ３０９、３１１においてキャッシュされたメタデータに対応するデータを永続的に記憶するように構成される。

【0041】

作成ＧＳＮ
レプリケートされるファイルは、１つの実施形態によると、一意の作成ＧＳＮによって特定されてよい。作成ＧＳＮは、ファイルの作成についての合意に対する割り当ておよび関連付けが同時に行われる一意のＧＳＮである。ちなみに、これによって、実施形態が、ＨＦｌｕｓｈ特徴を有さない、Ｓ３などのストレージシステムと途切れなく相互操作可能であることが徹底される。

【0042】

実行合意キャッシュ
データレプリケーションサーバ３０８は、１つの実施形態によると、実行合意キャッシュ３０９において実行合意をキャッシュするように構成されてよく、データレプリケーションサーバ３１０は、１つの実施形態によると、実行合意キャッシュ３１１において実行合意をキャッシュするように構成されてよい。１つの実施形態によると、データレプリケーションサーバ３０８、３１０は、それぞれ、実行合意キャッシュ３０９、３１１におけるエントリにおいて名前マッピングサービスＭａｐＦｉｌｅｎａｍｅ ＡＰＩを実装するように構成されてよい。合意は順不同で実行可能であるため、データレプリケーションサーバ３０８、３１０は、特定されたＧＳＮより大きいＧＳＮ全てを通して反復しかつサーチする能力によって構成されてよい。

【0043】

続けて図３を参照すると、クライアントアプリケーション３０４は、ファイル作成提案を出すことができ、これに対して、調整エンジンは対応する合意を出すことができる。クライアントアプリケーション３０４はさらにまた、（１）に示されるように、データレプリケーションサーバ３０８にファイル作成動作を出してよい。リモートデータセンタにおけるデータ書き込みの終わりに対する取り出し動作の作成、書き込み、開始からのファイル名、パス、またはデータに対する変更がない時だけでなく、介在する変更が生じる時にも機能する包括的解決策を提供するために、以下の方法が行われてよい。有意には、および１つの実施形態によると、ファイル作成動作と関連付けられたメタデータは、（２）に示されるように、ＤＣＯ２１４における実行合意キャッシュ３０８においてキャッシュされてよく、すぐに（例えば、迅速に）ネットワーク３０２上でＲＤＣ２１６においてデータレプリケーションサーバ３１０と同期させて、データレプリケーションサーバの実行合意キャッシュ３１１を更新することができる。これによって、ファイル作成動作はＲＤＣ２１６に可視になり、データセンタ２１４、２１６にわたるレプリケートされたフォルダの単一ビューが維持される。１つの実施形態によると、それぞれのレプリケートされたフォルダに対して１つの実行合意キャッシュがあってよい。他の実装形態が可能であり、単一の物理キャッシュは、いくつかのレプリケートされたフォルダのメタデータに適応させるために論理的にパーティション分割されてよい。メタデータは、比較的少量のデータから成るため、少なくとも、ＤＣＯ２１４におけるストレージ３１６からＲＤＣ２１６におけるストレージ３１８に対応するファイルデータをレプリケートするために必要とされる時間と比較すると、ＤＣＯ２１４における実行合意キャッシュ３０９からＲＤＣ２１６における実行合意キャッシュ３１１までの高速動作で、有線で送られる。目的は、実行合意キャッシュ３０９、３１１（および存在する場合、その他）にわたって、生成されたＧＳＮを使用してファイル書き込み動作を迅速に調整した後、基礎を成すデータ自体を、調整なく非同期的に（および、比較的遅くなることが多いが）レプリケート可能にすることである。このように、データの書き込み部（本明細書において進展している例では、クライアントアプリケーション３０４）は、ファイルを作成しかつ基礎を成すローカルストレージ３１６に書き込む際に、（例えば、レイテンシまたはネットワーク帯域制限に関して）いずれの大きなペナルティも課さない。

【0044】

（３）に示されるように、ファイル作成動作のメタデータの調整されたレプリケーション後、データレプリケーションサーバ３０８は、特定された完全修飾パスおよびファイル名においてクライアントアプリケーションの代わりにストレージ３１６においてファイルを作成することができる。その情報はさらにまた、クライアントアプリケーション３０４に返されてよく、クライアントアプリケーション３０４はその後、（４）に示されるように、そのファイル名にデータを書き込んでよい（比較的より速いローカルエリアネットワーク（ＬＡＮ）速度である場合がある）。クライアントアプリケーション３０４はさらにまた、データの書き込みが終わった時、（５）に示されるように、ファイルを閉じることができる。

【0045】

ＲＤＣ２１６におけるデータレプリケーションサーバ３１０はここで、作成されたファイル（現時点では、実行合意キャッシュ３１１においてこのメタデータを記憶しているため）「について知っている」ため、ＤＣＯ２１４のバージョンブリッジサーバ３１２にクエリを行う。データレプリケーションサーバ３１０は、バージョンブリッジサーバ３１２に、作成されたファイルと関連付けられた作成ＧＳＮを提供してよく、作成ＧＳＮは、（２）においてＤＣＯのデータレプリケーションサーバ３０８から得られたメタデータの一部を形成する。バージョンブリッジサーバ３１２はその後、ＤＣＯ２１４のデータレプリケーションサーバ３０８に、実行合意キャッシュ３０９におけるエントリにおいて名前マッピングサービスを実行させることができ、さらにまた、実行合意キャッシュ３０９において（作成ＧＳＮの後で）後続のＧＳＮを進んで、ファイルのファイル名、パス、および／またはデータに対するいずれの変更も作成ＧＳＮがこれをＲＤＣのデータレプリケーションサーバ３１０によって提供してから（すなわち、これより大きいＧＳＮで）その後生じたかどうかを判断することができる。ファイルのファイル名、パス、および／またはデータに対するそれらの変更が、暫定的にデータレプリケーションサーバ３１０の実行合意キャッシュ３１１において、調整下で、提案され、合意され、このメタデータがＤＣＯ２１４における実行合意キャッシュ３０９に記憶され、かつレプリケートされていることが考えられることは留意されたい。

【0046】

ＤＣＯ２１４のバージョンブリッジサーバ３１２はさらにまた、いずれの更新済みファイル名、パス、およびデータも、ＲＤＣ２１６におけるデータレプリケーションサーバ３１０に提供することができる。データレプリケーションサーバ３１０はさらにまた、ストレージ３１８において適正なファイル名、パスに対してデータを書き込み可能であり、ひいては得られ得る。当然ながら、ＲＤＣ２１６におけるクライアントアプリケーションは、データのレプリケーション前、中、または後にファイルに対するある状態変更動作を実行していてよい。これらの起こり得る事態のそれぞれは、本明細書において以下に補填される。

【0047】

１つの実装形態によると、以下の情報はデータレプリケーションサーバ３０８、３１０によって実行されるそれぞれの合意に対してキャッシュされてよい。
１．実行合意キャッシュＥｎｔｒｙ．Ｏｐｅｒａｔｉｏｎ。これは、名前変更、削除、切り捨て、アペンド、または修復などのファイル動作の識別である。
２．以下の制約を有する、実行合意キャッシュＥｎｔｒｙ．Ｐａｔｈ１。
ａ．パスはディレクトリまたはファイルの（相対するパスとは対照的に）完全修飾パスとしなければならない。
ｂ．ワイルドカードは許可されない（＊、＄など）
ｃ．名前変更動作の場合、この実行合意キャッシュＥｎｔｒｙ．Ｐａｔｈ１はソースパスである。
３．以下の制約を有する実行合意キャッシュＥｎｔｒｙ．Ｐａｔｈ２。
ａ．ディレクトリまたはファイルの完全修飾宛先パス
ｂ．ワイルドカードは許可されない。
ｃ．名前変更の場合にのみ存在する。
４．実行合意キャッシュＥｎｔｒｙ．ＦｉｌｅＬｅｎｇｔｈ。これは、ファイルのファイル長である。ここで、
ａ．ファイル切り捨て動作の場合、これはファイルが切り捨てられた長さである。
ｂ．アペンドについて、これはアペンドが開始される前のファイルの長さである。

【0048】

実行合意キャッシュにおいてこのようなメタデータ情報をキャッシュすること、および、そのメタデータ情報を同期するようにリモート実行合意キャッシュに伝達することによって、基礎を成すデータを比較的ゆっくりと書き込むことができ、データセンタにわたってそれぞれのＧＳＮにおいてレプリケートされたフォルダの状態を整合するように保持することができる。すなわち、ＧＳＮ１２２でＤＣＯ２１４におけるレプリケートされたフォルダの状態は、ＲＤＣ２１６におけるデータレプリケーションサーバ３１０がレプリケートされたデータフォルダ上のＧＳＮ１２７と関連付けられた合意をその後実行しており、かつＤＣＯ２１４におけるデータレプリケーションサーバ３０８がそのレプリケートされたフォルダ上でＧＳＮ１２７にまだ追い付いていない場合でも、ＲＤＣ２１６においてＧＳＮ１２２におけるレプリケートされたフォルダの状態と同じになる。

【0049】

実行合意キャッシュのガベージコレクション
実行合意キャッシュ３０９、３１１のガベージコレクションを行うことは、このシステムに対する動作上の考慮すべき事項の重要な側面である。これによって、分散ファイルシステムのノードのいずれかによって必要とされる可能性がもはやないメタデータの実行合意キャッシュが取り除かれる。これによって、実行合意キャッシュのサイズを合理的なサイズに保持することが可能になり、さらに、実行合意キャッシュを効率的に存続させ、かつこのような作用が必要とされる場合に再構築することが可能になる。従って、１つの実施形態は、実行合意キャッシュ（単数または複数）のガベージコレクションを行うように構成されてよい。このようなガベージコレクション機能性の１つの実装形態は、最小ＧＳＮを追跡するそれぞれのデータレプリケーションサーバを含んでよく、これに対して、データについてのいずれの要求（例えば、データ取り出し要求）もアクティブである。この情報はさらにまた、クォーラムにおいて全てのデータレプリケーションサーバに分散されてよく、このクォーラムは、特定のレプリケート済みフォルダまたは選択されたレプリケート済みフォルダのＧＳＮを追跡するデータレプリケーションサーバ群を含んでよい。その後、クォーラムにおける任意のアクティブな取り出しの最低ＧＳＮを下回る実行合意キャッシュにおけるエントリはさらにまた、ガベージコレクションが行われてよく、それ自体はもはや必要とされない。１つの実施形態によると、実行合意キャッシュにおけるエントリ数に対する設定可能な限度は、例えば、１０，０００などが課される場合があり、それぞれのエントリはＧＳＮと関連付けられる。実行合意キャッシュ３０９、３１１は、より少ないまたはより多い数の合意を記憶するように構成されてよい。ＥｒｒｏｒＥｘｅｃｕｔｅｄＡｇｒｅｅｍｅｎｔＣａｃｈｅＧａｒｂａｇｅＣｏｌｌｅｃｔｅｄなどのエラーコードは、マップがガベージコレクションを行っているようにＧＳＮに要求する場合、名前マッピングサービスＭａｐＦｉｌｅｎａｍｅ ＡＰＩによって返されてよい。別の実施形態では、データレプリケーションサーバ３０８、３１０は、最低アクティブデータ取り出しＧＳＮを追跡するように構成されてよく、この最低アクティブデータ取り出しＧＳＮを、データセンタにわたって（さらには、レプリケート済みフォルダごとに）全てのデータレプリケーションサーバに分散してよいことで、ガベージコレクションを継続していくように実行することが可能になる。

【0050】

上記のように、実行合意キャッシュは、データレプリケーションサーバ３０８、３１０がそれぞれ、それぞれのレプリケート済みフォルダデータ構造ごとに、複数のキャッシュにアクセスしかつこれを維持することができるように、レプリケート済みフォルダデータ構造ごとに構成されてよい。

【0051】

１つの実施形態によると、選択的レプリケーション正規表現に対する変更など、レプリケート済みデータ構造と関連付けられた管理または動作コマンドは、対応する実行合意キャッシュのフラッシュを生じさせるものとし、これはさらにまた、スクラッチから再構築されてよい。このような再構築は、名前空間変更動作に対する提案が承認されかつ実施される際に行われてよい。

【0052】

名前マッピングサービス
上記のように、名前マッピングサービスＭａｐＦｉｌｅｎａｍｅ ＡＰＩコールは、データレプリケーションサーバ３０８、３１０によって実施されてよい。このＡＰＩの使用には以下が含まれてよい。
１．ＤＣＯ２１４において、バージョンブリッジサーバ３１２は、ファイルを転送する要求を受信する時、この方法を呼び出すように構成されてよい。呼び出された名前マッピングサービスはさらにまた、作成ＧＳＮとして既知であったようにファイルの名前をマッピングすることになり、これは、ファイルの作成と関連付けられるＧＳＮである。ファイルの読み出し中、この読み出しができない場合、バージョンブリッジサーバ３１２は、再び名前マッピングサービスに、ファイルのデータを読み出していた間にファイル名が変更されたかどうかを判断するように求めることになる。
２．ＲＤＣ２１６において、データレプリケーションサーバは、書き込みを開始する前に、また、ローカルファイルへの取り出されたデータの書き込みができない時に、名前マッピングサービスにファイル名をマッピングするように求めることになる。

【0053】

１つの実施形態によると、バージョンブリッジサーバ３１２は上で挙げられた最初の使用時のプロセス以外のものであり、上記の第２の使用時のプロセスにおけるものであるため、名前マッピングサービスは、同じＪａｖａ仮想マシン（ＪＶＭ）内の要求ＡＰＩおよび局所的方法の両方として利用可能であるように構成されてよい。他の実装形態が可能である。

【0054】

名前マッピングサービスＭａｐＦｉｌｅｎａｍｅの入力および出力パラメータ
名前マッピングサービスの入力パラメータは、１つの実装形態によると、以下を含むことができる。
１．作成ＧＳＮ
ａ．これはファイルまたはオブジェクトが作成されたＧＳＮである。
２．Ｐａｔｈ－ｉｎ
ａ．ｐａｔｈ－ｉｎは、リモートデータセンタがデータを要求しているファイルの完全修飾パスである。
ｂ．Ｐａｔｈ－ｉｎはディレクトリとすることができない。

【0055】

名前マッピングサービスの出力パラメータは、１つの実施形態によると、以下を含むことができる。
１．ＲｅｔｕｒｎＶａｌｕｅ
ａ．ＲｅｔｕｒｎＶａｌｕｅは「ＦｉｌｅＥｘｉｓｔｓＵｎｃｈａｎｇｅｄ」であってよく、これはファイルがその作成ＧＳＮから変更されていないことを意味する。
ｂ．ＲｅｔｕｒｎＶａｌｕｅは「ＦｉｌｅＥｘｉｓｔｓＣｈａｎｇｅｄ」であってよく、これは、ファイルが書き込まれてから（その作成ＧＳＮから）変更されていることを意味する。
ｃ．ＲｅｔｕｒｎＶａｌｕｅは「ＦｉｌｅＤｅｌｅｔｅｄ」であってよく、これは、ファイルがもはや存在しないことを意味する。
ｄ．「ＥｒｒｏＥｘｅｃｕｔｅｄ ａｇｒｅｅｍｅｎｔ ｃａｃｈｅＧａｒｂａｇｅＣｏｌｌｅｃｔｅｄ」のＲｅｔｕｒｎＶａｌｕｅは、ファイルが、その後ガベージコレクションが行われた作成ＧＳＮと関連付けられていることを指示している。
ｅ．「ＡｂｏｒｔＰｕｌｌＲｅｐａｉｒＣｏｍｉｎｇＵｐ」のＲｅｔｕｒｎＶａｌｕｅは、修復動作がスケジューリングされているため、このファイルに対するデータ取り出しが中止されるべきであることを指示している。
２．ＮｅｗＰａｔｈ
戻り値が「ＦｉｌｅＥｘｉｓｔｓＵｎｃｈａｎｇｅｄ」である場合、「ＮｅｗＰａｔｈ」のＲｅｔｕｒｎＶａｌｕｅは、現時点で基礎を成すファイルシステムに存在し、かつファイルの作成ＧＳＮから変更されていないため、ファイルのパスである。この出力パラメータは、基礎を成すストレージの現時点のＧＳＮまで作成ＧＳＮからＰａｔｈ－ｉｎへの変更を追跡する。ファイル名への変更、および任意の親ディレクトリコンポーネントへの変更は両方共、このように追跡されかつ報告される。
３．ファイルに対して有効であるデータの長さ
ａ．この出力パラメータは、ファイルの終わりにデータを削除してよい任意の可能な切り捨て動作を考慮している。

【0056】

名前マッピングサービスの動作
１つの実施形態によると、名前マッピングサービスが呼び出される時、後述される機能および動作の１つまたは複数は、実行されてよい。

【0057】

呼び出されると、名前マッピングサービスは、ＡＰＩが呼び出されるファイルと関連付けられた作成ＧＳＮが実行合意キャッシュに記憶された最低ＧＳＮを下回っているかどうかをチェックすることができる。そうであるなら、データレプリケーションサーバが変更に対する実行合意キャッシュをチェックすることができなくなるため、「ＥｒｒｏＥｘｅｃｕｔｅｄ ａｇｒｅｅｍｅｎｔ ｃａｃｈｅＧａｒｂａｇｅＣｏｌｌｅｃｔｅｄ」を返す。

【0058】

実行合意キャッシュに記憶された最大（１つの実施形態では、最高）ＧＳＮに達するまで、名前マッピングサービスが呼び出されたファイルと関連付けられた作成ＧＳＮより大きいＧＳＮによって特定される実行合意キャッシュにおけるエントリ全てを進める。

【0059】

ＥｘｅｃｕｔｅｄＡｇｒｅｅｍｅｎｔＣａｃｈｅＥｎｔｒｙ．Ｐａｔｈ１（実行合意キャッシュでのエントリにおけるファイルに対するパス）が入力パラメータＰａｔｈ－ｉｎに厳密にマッチする場合、行われるステップは基礎を成すファイル動作に左右される。ファイル動作が名前変更である場合、Ｐａｔｈ－ｉｎを、実行合意キャッシュにおける新しいパス「ＥｘｅｃｕｔｅｄＡｇｒｅｅｍｅｎｔＣａｃｈｅＥｎｔｒｙ．Ｐａｔｈ２」と置き換え、かつ実行合意キャッシュにおける残りのエントリを反復し続ける。動作がアペンドまたは切り捨てである場合、呼び出し部に返すためにＥｘｅｃｕｔｅｄＡｇｒｅｅｍｅｎｔＣａｃｈｅＥｎｔｒｙ．ＦｉｌｅＬｅｎｇｔｈを保存し、実行合意キャッシュエントリにおける残りのエントリを反復し続ける。動作が削除である場合、すぐにＦｉｌｅＤｅｌｅｔｅｄを返し、動作が修復である場合、すぐにＡｂｏｒｔＰｕｌｌＲｅｐａｉｒＣｏｍｉｎｇＵｐを返す。

【0060】

ＥｘｅｃｕｔｅｄＡｇｒｅｅｍｅｎｔＣａｃｈｅＥｎｔｒｙ．Ｐａｔｈ１がＰａｔｈ－ｉｎにマッチしない場合、Ｐａｔｈ－ｉｎの親ディレクトリを抽出する。例えば、Ｐａｔｈ－ｉｎが、／ｕｓｅｒ／ｊａｇａｎｅ／ｈｉｖｅ－ｔａｂｌｅｓ／ｗｅｂｌｏｇｓ／ｆｉｌｅＡＢＣである場合、Ｐａｔｈ－ｉｎの親ディレクトリは、／ｕｓｅｒ／ｊａｇａｎｅ／ｈｉｖｅ－ｔａｂｌｅｓ／ｗｅｂｌｏｇｓである。Ｅｘｅｃｕｔｅｄ ａｇｒｅｅｍｅｎｔ ｃａｃｈｅＥｎｔｒｙ．Ｐａｔｈ１がＰａｔｈ－ｉｎの親ディレクトリより長い場合、データレプリケーションサーバは実行合意キャッシュにおいて（名前マッピングサービスが呼び出されたファイルの作成ＧＳＮより大きいＧＳＮを有する）残りのエントリを反復し続けるものとする。

【0061】

ＥｘｅｃｕｔｅｄＡｇｒｅｅｍｅｎｔＣａｃｈｅＥｎｔｒｙ．Ｐａｔｈ１がＰａｔｈ－ｉｎの親ディレクトリより短いまたは等しいと判断される時に下記が行われる。Ｅｘｅｃｕｔｅｄ ａｇｒｅｅｍｅｎｔ ｃａｃｈｅＥｎｔｒｙ．Ｐａｔｈ１がＰａｔｈ－ｉｎ－ｐａｒｅｎｔｄｉｒのあるプレフィックス部分列に等しい場合、これは、Ｐａｔｈ－ｉｎの親ディレクトリコンポーネントのうちの１つが動作していたことを指示している。ＥｘｅｃｕｔｅｄＡｇｒｅｅｍｅｎｔＣａｃｈｅＥｎｔｒｙ．Ｐａｔｈ１がディレクトリでなければならず、この時点でファイルとすることはできないことは留意されたい。動作が名前変更である場合、Ｐａｔｈ－ｉｎ－ｐａｒｅｎｔｄｉｒにおけるプレフィックスは、ＥｘｅｃｕｔｅｄＡｇｒｅｅｍｅｎｔＣａｃｈｅＥｎｔｒｙ．Ｐａｔｈ２と置き換えられ、Ｐａｔｈ－ｉｎは再構成される。上で進展した例を続けると、ＥｘｅｃｕｔｅｄＡｇｒｅｅｍｅｎｔＣａｃｈｅＥｎｔｒｙ．Ｐａｔｈ１が／ｕｓｅｒ／ｊａｇａｎｅ／ｈｉｖｅ－ｔａｂｌｅｓである場合、およびＥｘｅｃｕｔｅｄＡｇｒｅｅｍｅｎｔＣａｃｈｅＥｎｔｒｙ．Ｐａｔｈ２が／ｕｓｅｒ／ｊａｇａｎｅ／ａｒｃｈｉｖｅｄ－ｈｉｖｅ－ｔａｂｌｅｓである場合、Ｐａｔｈ－ｉｎを／ｕｓｅｒ／ｊａｇａｎｅ／ａｒｃｈｉｖｅｄ－ｈｉｖｅ－ｔａｂｌｅｓ／ｗｅｂｌｏｇｓ／ｆｉｌｅＡＢＣと置き換える。その後、実行合意キャッシュエントリの残りを反復し続ける。動作が削除である場合、サブディレクトリ全体は削除されており、ＦｉｌｅＤｅｌｅｔｅｄがすぐに返される。動作が修復である場合、ＡｂｏｒｔＰｕｌｌＲｅｐａｉｒＣｏｍｉｎｇＵｐが返される。ＥｘｅｃｕｔｅｄＡｇｒｅｅｍｅｎｔＣａｃｈｅＥｎｔｒｙ．Ｐａｔｈ１がディレクトリでなければならないため、アペンドおよび切り捨てがこの時点では無効な動作であることは留意されたい。

【0062】

Ｅｘｅｃｕｔｅｄ ａｇｒｅｅｍｅｎｔ ｃａｃｈｅＥｎｔｒｙ．Ｐａｔｈ１が（ルートディレクトリ以外の）Ｐａｔｈ－ｉｎ－ｐａｒｅｎｔｄｉｒの任意のプレフィックス部分列に等しくない場合、実行合意キャッシュエントリの残りを反復し続ける。上記のループの終わりに、Ｐａｔｈ－ｉｎに対していずれもマッチするものがなかった場合、ＦｉｌｅＥｘｉｓｔｓＵｎｃｈａｎｇｅｄを返す。上記のループの終わりに、いくつかの変更に直面した場合、Ｐａｔｈ－ｉｎまたは長さのどちらかに対して、戻り値として新しいパスおよび新しい長さと共にＦｉｌｅＥｘｉｓｔｓＣｈａｎｇｅｄを返す。

【0063】

ＤＣＯにおけるソースファイル名に対する名前マッピングサービスを呼び出すための拡張
データレプリケーションサーバ３０８は、本明細書に示されかつ説明されるように、固有ＧＳＮにおいて行われるファイルシステム動作の詳細をキャッシュするように構成される実行合意キャッシュ３０９を維持するように構成されてよい。この実行合意キャッシュ３０９は、１つの実施形態によると、バージョンブリッジサーバ３１２に名前マッピングサービスを提供して、基礎を成すファイルシステムの現時点の状態への（実行合意キャッシュにおける最高ＧＳＮまで）これまでの固有ＧＳＮにおけるファイル名のマッピングを要求するように構成されてよい。

【0064】

名前変更／削除の合意が、ＤＣＯにおけるデータレプリケーションサーバ３１０からの取り出し要求がＤＣＯ２１４におけるバージョンブリッジサーバ３１２に到達する前、間、または後に、データレプリケーションサーバ３０８によって実行されてよいことに留意されたい。これらの起こり得る事態のそれぞれは、さらには下記に論じられる。
取り出し要求の前のデータレプリケーションによって実行される名前変更／削除の合意
図４は、取り出し要求がＲＤＣから受信される前にソースファイルまたは親パスが名前変更／削除される場合を示すブロック図である。示されるように、（１）は、ＲＤＣ２１６におけるデータレプリケーションサーバ３１０によって出され、かつＤＣＯにおけるバージョンブリッジサーバ３１２に向けられた取り出し要求を指示する。例えば、データレプリケーションサーバ３１０は、データが要求されたファイルのファイル名または親ディレクトリが、その最初の書き込みから変更している場合がある可能性に注意して、作成ＧＳＮ２１において、ファイルＭａｐＦｉｌｅｎａｍｅ ／ｊａｇａｎｅ／ｈｉｖｅ／ｆｏｏ．ｔｍｐの名前マッピングを要求することができる。（２）に示されるように、この取り出し要求を受信したバージョンブリッジサーバ３１２は、最大ＧＳＮがここで（この例において）５０である、実行合意キャッシュ３０９における実行合意に対してデータレプリケーションサーバ３０８によって実行される、名前マッピングサービスを呼び出す。これに応答して、名前マッピングサービスは、ＧＳＮ２１～５０を反復して、ＧＳＮ２１とＧＳＮ５０との間の介在する時間における／ｊａｇａｎｅ／ｈｉｖｅ／ｆｏｏ．ｔｍｐへの可能な変更についてサーチする。名前マッピングサービスは、この例では、／ｊａｇａｎｅ／ｈｉｖｅ／ｆｏｏ．ｔｍｐが実際は、ＧＳＮ２１～ＧＳＮ５０のあるＧＳＮにおいて、／Ｊａｇａｎｅ／ｈｉｖｅ／ｆｏｏに変更されたことを見出す。この情報はさらにまた、バージョンブリッジサーバ３１２に返され、その後、（／ｊａｇａｎｅ／ｈｉｖｅ／ｆｏｏ．ｔｍｐを読み出す代わりに）分散ファイルシステム３１６から／Ｊａｇａｎｅ／ｈｉｖｅ／ｆｏｏを読み出し、リモートストレージ３１８へのこの非同期レプリケーションに対して、新しいファイル名およびここに記憶されたデータを、ＲＤＣにおけるデータレプリケーションサーバ３１０に返す。

【0065】

取り出し要求がバージョンブリッジサーバによってサービス提供されている間にデータレプリケーションサーバによって実行される名前変更／削除の合意
図５は、リモート取り出し要求がバージョンブリッジサーバによってサービス提供されている間にソースファイルまたは親パスが名前変更される／削除される場合を示すブロック図である。バージョンブリッジサーバ３１２がリモート取り出し要求を満たすために基礎を成すストレージ３１６からファイルを読み出している間はいつでも、データレプリケーションサーバは、取り出し要求の対象であるファイル、または取り出し要求の対象であるファイルの親パスを名前変更／削除する別の合意を実行することができる。この場合、ファイル取り出しは、ファイルが名前変更されているもしくは削除されている、またはパスが変更されているのどちらかを理由に、進行中に失敗することになる。１つの実施形態によると、バージョンブリッジサーバ３１２は、ソースファイルの名前／パスをマッピングするために名前マッピングサービスを再び呼び出す。名前マッピングサービスからの戻り値は、ファイルが別の名前で存在するかどうか、またはファイルが削除されたかどうかを指示することになる。

【0066】

図５に示されるように、（１）に示されるように、特定ファイルに対する取り出し要求を、ＲＤＣ２１６のデータレプリケーションサーバ３１０は送ることができ、ＤＣＯ２１４のバージョンブリッジサーバ３１２は受信することができる。この例では、取り出し要求は、作成ＧＳＮ２１におけるファイルＪａｇａｎｅ／ｈｉｖｅ／ｆｏｏ．ｔｍｐに対するものである。（２）に示されるように、ＤＣＯ２１４におけるバージョンブリッジサーバ３１２は、さらにまた、データレプリケーションサーバ３０８に、ＧＳＮ３２までの実行合意を現時点で記憶している、実行合意キャッシュ３０９において実行合意のメタデータを含むキャッシュされたエントリに対する名前マッピングサービスを実行するように求める。名前マッピングサービスは、ｆｏｏ．ｔｍｐがＧＳＮ２１から変更されていない（すなわち、名前変更または削除されていない）ことを指示する、／Ｊａｇａｎｅ／ｈｉｖｅ／ｆｏｏ．ｔｍｐの値を返す。（３）に示されるように、ＤＣＯ２１４におけるバージョンブリッジサーバ３１２はさらにまた、この時、依然同じ／Ｊａｇａｎｅ／ｈｉｖｅ／ｆｏｏ．ｔｍｐであるマッピングされたファイル名を読み出すことによって取り出し要求のサービス提供を始める。

【0067】

（４）に示されるように、取り出し要求がサービス提供されている間に、データレプリケーションサーバ３０８は、／Ｊａｇａｎｅ／ｈｉｖｅ／ｆｏｏ．ｔｍｐを／Ｊａｇａｎｅ／ｈｉｖｅ／ｆｏｏに名前変更する合意を実行する。これによって、取り出し要求は、このファイルが名前変更されており、／Ｊａｇａｎｅ／ｈｉｖｅ／ｆｏｏ．ｔｍｐがもはや存在しない際に、バージョンブリッジサーバ３１２がもはや／Ｊａｇａｎｅ／ｈｉｖｅ／ｆｏｏ．ｔｍｐを読み出し続けることができないため、失敗する。これに応答して、／Ｊａｇａｎｅ／ｈｉｖｅ／ｆｏｏ．ｔｍｐを取り出すための要求をサービス提供しているバージョンブリッジサーバ３１２は、ここで、データレプリケーションサーバ３０８に、この時、ＧＳＮ５０までの合意（恐らくＧＳＮ３２とＧＳＮ５０との間のどこかで生じた「ｆｏｏ．ｔｍｐ」から「ｆｏｏ」への名前変更）を記憶する、実行合意キャッシュ３０９におけるキャッシュされたメタデータに対して／Ｊａｇａｎｅ／ｈｉｖｅ／ｆｏｏ．ｔｍｐに対する名前マッピングサービスを再実行するように求める。名前マッピングサービスはマッピングされた情報／ｊａｇａｎｅ／ｈｉｖｅ／ｆｏｏを返す。バージョンブリッジサーバ３１２は、ここで、マッピングされたファイル／Ｊａｇａｎｅ／ｈｉｖｅ／ｆｏｏを読み出すこと、およびこのファイルをＲＤＣ２１６におけるデータレプリケーションサーバ３１０に提供することによって取り出し要求のサービス提供を続けることができ、これによって、マッピングされたメタデータによってそれ自体の実行合意キャッシュ３１１を更新し、かつＲＤＣ２１６におけるストレージ３１８に取り出されたデータを書き込むことになる。

【0068】

リモートサイトからの取り出し要求後にソースファイルまたは親パスが名前変更／削除される
取り出し要求が完了し、その後にのみ、ファイルまたは親パスが名前変更または削除される場合、ＤＣＯ２１４およびＲＤＣ２１６両方における実行合意キャッシュがいずれの以前のまたは進行中の取り出し要求とも干渉せずに適当に更新されることになるため、何の措置も講じられない。全てのデータセンタは、これらが同期されているため、それらの対応する実行合意キャッシュを通して名前変更／削除を知ることになる。

【0069】

名前マッピングサービスに対象ファイル名を求めるためのリモートデータセンタにおけるデータレプリケーションサーバ
データレプリケーションサーバは、１つの実施形態によると、データ取り出し、かつ取り出されたデータを非同期的にローカルファイルに書き込むように構成される。このプロセスは、データレプリケーションサーバが書き込んでいるローカルファイルが名前変更または削除される場合に失敗して中断される場合がある。これは、メタデータ動作、すなわち、合意が、データが取り出されかつ書き込まれている間に実行され続けるためである。１つの実装形態によると、この起こり得る事態に対処するために、データレプリケーションサーバの名前マッピングサービスを使用して、宛先ファイルを新しく名前変更されたファイルにマッピングする。リモートデータレプリケーションサーバ３１０がデータ取り出しをもたらす合意を実行する時、１つの実施形態によると、データレプリケーションコピーオブジェクトが作成され、このデータレプリケーションコピーオブジェクトはＧＳＮと関連付けられる。このＧＳＮは２つの目的で使用される。
１．ＧＳＮは、データを取り出している間に、リモートデータレプリケーションサーバからＤＣＯ２１４のバージョンブリッジサーバ３１２に渡される。
２．ＧＳＮは、ローカルファイルへの書き込みが失敗する時名前マッピングサービスに対するパラメータとして使用される。

【0070】

名前変更／削除の合意が、データコピーを行っているスレッドの前、間、または後にデータレプリケーションサーバにおける別のスレッドによって非同期的に実行されてよいことは、留意されたい。
事例１：宛先ファイルまたは親パスはデータコピースレッドが取り出されたデータの書き込みを開始できる前に名前変更および／または削除される。
事例２：宛先ファイルまたは親パスはデータコピースレッドが取り出されたデータを書き込んでいる間に名前変更および／または削除される。
事例３：宛先ファイルまたは親パスはデータコピースレッドが取り出されたデータの書き込みを終了した後に名前変更および／または削除される。これは、実行合意キャッシュにおけるメタデータが同期的に更新されかつリモートに伝達されることになるため、関係がない。

【0071】

上記のように、データレプリケーションコピーオブジェクトは、１つの実施形態によると、データの非同期コピーがＲＤＣ２１６において実装される機構である。データレプリケーションコピーオブジェクトは、それ自体の実行スレッドを有し、このスレッドにメタデータ修正と無関係に起動する能力を与える。よって、データレプリケーションコピーオブジェクト実装によって、同期的メタデータ動作および非同期的データ動作が可能になる。

【0072】

１つの実施形態によると、データレプリケーションコピーオブジェクトが作成される時、データが取り出されるファイルの名前、および、そのようにファイルに名前が付けられたＧＳＮ番号が与えられる。これによって、データレプリケーションコピーオブジェクトは２つのことを行うことができる。
１．ＤＣＯ２１４からデータを要求する時、ＲＤＣ２１６のバージョンブリッジサーバは、データが取り出されるファイル名、およびファイルが呼び出されたＧＳＮ両方をもたらす。
２．ＲＤＣ２１６のデータレプリケーションサーバがＤＣＯ２１４の分散ファイルシステムから取り出されたデータをＲＤＣ２１６の分散ファイルシステムに書き込む時、１つの実施形態によると、名前マッピングサービスは、ファイル名が変更されたか否かを判断するために、これらの２つのパラメータ、ＧＳＮおよびＦｉｌｅｎａｍｅで呼び出される。すなわち、ＲＤＣ２１６におけるクライアントアプリケーション３０６が、取り出されたデータが書き込まれる前、または取り出されたファイルデータが書き込まれている間にデータへの変更がなされることが可能である。ファイル名が、ＧＳＮと、基礎を成すファイルシステムの現時点の状態との間で変更されている場合、データレプリケーションサーバ３１０は、ファイルが、ＲＤＣ２１６における実行合意キャッシュ３１１からのメタデータを使用して基礎を成すファイルシステムの現時点の状態において名前が付けられるように該ファイルに書き込まれることになる。

【0073】

それぞれのデータセンタにおける実行合意キャッシュが揮発性ランダムアクセスメモリ（例えば、ダイナミックランダムアクセスメモリ（ＤＲＡＭ））において実装されてよいため、電力不足発生時、または、結合されるデータレプリケーションサーバの障害発生時にそのデータは失われやすい。このような実装形態では、データレプリケーションサーバの障害発生時に、新しく選ばれた書き込み部は、空の実行合意キャッシュから始まることになり、異常に多数のＥｒｒｏＥｘｅｃｕｔｅｄＡｇｒｅｅｍｅｎｔＣａｃｈｅＧａｒｂａｇｅＣｏｌｌｅｃｔｅｄを返す場合がある。しかしながら、１つの実施形態によると、実行合意キャッシュは、例えば、書き込み部の障害／再選択の場合などに必要に応じて、（実行合意キャッシュを不揮発性メモリにおいて存続させた最後の時点で）少なくとも部分的に回復されることが可能になる。不揮発性ストレージは、ストレージ３１６および／または３１８の一部である、またはそれ自体専用の不揮発性メモリである。

【0074】

１つの実施形態によると、ファイル名および／またはパスが変更され、かつ非整合になる時、レプリケートされたフォルダ全体は非整合であり信用できないとマーキングされる場合がある。別の実施形態によると、非整合になったファイル／ファルダは、不揮発性メモリにおいて存続させてよく、これによって、非整合である特定のサブディレクトリのみが本明細書に詳述されるように修復されることが可能である。

【0075】

別の実施形態によると、データを取り出すリモートデータセンタは、レプリケート元データセンタからデータを必ずしも取り出すことを必要とするわけではない。分散ファイルシステムにおけるデータの１コピー等価性の性質の場合は、ＲＤＣ２１６は、別のデータセンタ（すなわち、ＤＣＯ２１４以外）と接触し、かつ他のデータセンタから同じデータを要求する（取り出す）ことができる。これは、負荷分散、帯域幅管理、障害復旧、および新しいデータセンタをオンラインにすることなどを含むさまざまな理由で行われてよい。

【0076】

図６は、１つの実施形態による、分散ファイルシステムにおいてレプリケートされたフォルダの整合性を維持するコンピュータ実施方法のフローチャートである。分散ファイルシステムは、コンピュータネットワーク上で、（少なくとも）１つの第１のデータセンタおよび第２のデータセンタに及んでよい。該方法は、ブロックＢ６１に示されるように、第１のデータセンタにおいて、および第１のデータセンタにおけるアプリケーションクライアントの代わりに、レプリケートされたフォルダにおけるファイル、および合意済み提案と関連付けられたＧＳＮを作成するために合意済み提案を受信することを含んでよい。ブロックＢ６２は、第１のデータセンタ（図３における２１４）における（例えば、図３における３０８で示される）第１のデータレプリケーションサーバに結合された（例えば、図３における３０９で示される）第１の実行合意キャッシュにおいて、作成されるファイルのメタデータ、および合意済み提案と関連付けられたＧＳＮを記憶することを求める。その後、Ｂ６３に示されるように、メタデータおよび関連付けられたＧＳＮは、（図３における参照番号２１６で示される）第２のデータセンタにおける第２のデータレプリケーションサーバ（図３における３１０）に結合される第２の実行合意キャッシュ（図３における３１１）に同期的に記憶されてよい。ファイルはさらにまた、Ｂ６４に示されるように、アプリケーションクライアント（図３における３０４）の代わりに第１のデータセンタにおける第１のデータレプリケーションサーバによってストレージにおいて（例えば、図３におけるストレージ３１６において）作成されてよい。クライアントアプリケーションは、次いで、ブロックＢ６５に見られるように、第１のデータセンタにおけるストレージにおいて作成済みファイルにデータを書き込んでよい。

【0077】

コンピュータ実施方法は、ブロックＢ６６に示されるように、ファイルへの変更に対する提案が合意済みである際に同期されかつ最新であるように実行合意キャッシュを保持することをさらに含んでよい。実際は、ファイルのファイル名、パス、またはデータを変更するために第１のデータセンタにおいて受信された、任意の合意済み提案に対応する、更新されたメタデータおよび関連付けられたＧＳＮは、第１の実行合意キャッシュに記憶されてよく、第２の実行合意キャッシュにおける、更新されたメタデータおよび関連付けられたＧＳＮはまた、第２のデータセンタに同期的に記憶されてよい。同様に、ファイルのファイル名、パス、またはデータを変更するために第２のデータセンタにおいて受信された、任意の合意済み提案に対応する、更新されたメタデータおよび関連付けられたＧＳＮは、第２の実行合意キャッシュに記憶されてよく、更新されたメタデータおよび関連付けられたＧＳＮは、第１の実行合意キャッシュに同期的に記憶されてよい。

【0078】

図７において、ブロックＢ７１は、ファイルのデータに対する第２のデータセンタからの要求（本明細書ではデータ取り出し要求とも称される）を受信することを求める。この要求は、データが要求されるファイルの作成についての合意と関連付けられた少なくとも１つの作成ＧＳＮを含む。ブロックＢ７２は、要求の受信に応答して、データが要求されるファイルの作成ＧＳＮより大きい（例えば、より最近の合意済み提案を代表する）ＧＳＮと関連付けられるファイルの更新されたメタデータに対する第１の実行合意キャッシュにおけるエントリをサーチすることを求める。これによって、取り出し要求が開始されてからなされたファイルへのいずれの変更もキャプチャされることになる。第１の実行合意キャッシュのエントリをサーチした後、ブロックＢ７３は、サーチすることによって更新されたメタデータが見つからなかった場合要求において受信されたメタデータに対応するデータを読み出すこと、および、サーチすることによって更新されたメタデータが見つけられた場合更新されたメタデータに対応するデータを読み出すことを特定する。読み出されたデータはさらにまた、Ｂ７４に示されるように、ファイルのデータに対する第２のデータセンタからの受信された要求に応じて提供されてよい。

【0079】

図８において、第２の実行合意キャッシュにおけるエントリは、Ｂ８１に示されるように、更新されたメタデータと関連付けられたＧＳＮより大きいＧＳＮと関連付けられるファイルのメタデータに対してサーチされてよい。Ｂ８２に示されるように、第２の実行合意キャッシュのエントリをサーチした後、Ｂ８３に示されるように、第２の実行合意キャッシュをサーチすることによって更新されたメタデータが見つからなかった（ファイルへの介在する変更がなされなかった）場合、提供されたデータは第２のデータセンタにおけるストレージに書き込まれてよく、および、第２の実行合意キャッシュにおいて更新されたメタデータを見つけることから明らかなように、Ｂ８４に示されるように、第２の実行合意キャッシュをサーチすることによって更新されたメタデータが見つかった（ファイルへの介在する変更がなされた）場合、第２の実行合意キャッシュにおいて見つけられたメタデータに対応するデータを読み出し、かつ第２のデータセンタにおけるストレージに読み出されたデータを書き込んでよい。

【0080】

１つの実施形態によると、サーチすることは、名前マッピングサービスＡＰＩを実行することによって実施されてよい。第１の実行合意キャッシュおよび第２の実行合意キャッシュの少なくとも一部分は、それぞれ、第１のデータセンタおよび第２のデータセンタにおける不揮発性メモリにおいてジャーナリング（すなわち、存続）されてよい。実行合意キャッシュが再構築される必要がある場合、不揮発性メモリにおけるこのバージョンは検索されてよく、必要に応じてガベージコレクションが行われてよく、現時点の合意のＧＳＮに更新されてよい。別の実施形態によると、実行合意キャッシュは、揮発性メモリにジャーナリングされず、必要に応じて単にスクラッチから再構築される。

【0081】

コンピュータ実施方法の別の実施形態は、第１のデータセンタにおける第１の実行合意キャッシュを提供しかつ第２のデータセンタにおける第２の実行合意キャッシュを提供することと、第１のデータセンタおよび第２のデータセンタに記憶されたファイルへの変更を作成するまたは行うための提案についての合意を受信することと、第１の実行合意キャッシュおよび第２の実行合意キャッシュのうちの１つにおいて受信した合意によって参照されるファイルのメタデータを記憶することと、受信した合意によって参照されるファイルが作成または変更される前に互いに同期する第１の実行合意キャッシュおよび第２の実行合意キャッシュを維持することと、第１の合意キャッシュおよび第２の実行合意キャッシュが同期された後にのみ受信した合意によって参照されるファイルへの変更を作成するまたは行うことと、第１のデータセンタまたは第２のデータセンタに記憶されたファイルのデータに対する要求が第１のデータセンタまたは第２のデータセンタのどちらかにおいて受信されるかどうか、更新されたメタデータに対する第１の実行合意キャッシュおよび第２の実行合意キャッシュのうちの少なくとも１つをチェックし、受信した要求に応答して、更新されたメタデータが見つけられた時に更新されたメタデータに対応するデータを提供することと、を含んでよい。

【0082】

ＧＳＮはそれぞれの合意と関連付けられてよく、それぞれの合意のＧＳＮは、第１の実行合意キャッシュおよび第２の実行合意キャッシュにおけるメタデータと共に記憶されてよい。更新されたメタデータについてチェックすることまたはサーチすることは、更新されたメタデータと関連付けられたＧＳＮを使用してファイルの更新されたメタデータに対して第１の実行合意キャッシュおよび／または第２の実行合意キャッシュにおけるエントリをサーチすることによって実行されてよい。チェックすることまたはサーチすることは、名前マッピングサービスに第１の実行合意キャッシュにおけるエントリを求める第１のデータレプリケーションサーバによって第１のデータセンタにおいて行われてよく、チェックすることまたはサーチすることは、名前マッピングサービスに第２の実行合意キャッシュにおけるエントリを求める第２のデータレプリケーションサーバによって第２のデータセンタにおいて行われてよい。

【0083】

データに対する要求は、第１のデータレプリケーションサーバが、名前マッピングサービスに、要求されたデータに対応する更新されたメタデータに対して第１の実行合意キャッシュをチェックすることを求めるようにするように構成される第１のバージョンブリッジサーバにおいて第１のデータセンタで受信されてよい。同様に、データに対する要求は、第２のデータレプリケーションサーバが、名前マッピングサービスに、要求されたデータに対応する更新されたメタデータに対して第２の実行合意キャッシュをチェックすることを求めるようにするように構成される第２のバージョンブリッジサーバにおいて第２のデータセンタで受信されてよい。データに対する要求をサービス提供することは、第１のバージョンブリッジサーバが、更新されたメタデータが第１の実行合意キャッシュにおいて見つけられた時に更新されたメタデータに対応するデータを検索しかつ提供することによって実行されてよい。同様に、データに対する要求をサービス提供することは、第２のバージョンブリッジサーバが、更新されたメタデータが第２の実行合意キャッシュにおいて見つけられた時に更新されたメタデータに対応するデータを検索しかつ提供することによって実行されてよい。このように、第２のデータセンタに記憶されるデータに対する第１のデータセンタにおける第１のデータレプリケーションサーバによって出される全ての要求は、第２のデータセンタにおける第２のバージョンブリッジサーバによってサービス提供されてよく、第１のデータセンタに記憶されるデータに対する第２のデータセンタにおける第２のデータレプリケーションサーバによって出される全ての要求は、第１のデータセンタにおける第１のバージョンブリッジサーバによってサービス提供されてよい。

【0084】

図９は、コンピューティングデバイス９００のブロック図を示し、この実施形態は実装可能である。コンピューティングデバイス９００は、情報を通信するためのバス９０１または他の通信機構、および情報を処理するためにバス９０１と結合される１つまたは複数のプロセッサ９０２を含んでよい。コンピューティングデバイス９００は、プロセッサ（複数可）９０２によって実行される情報および命令を記憶するためにバス９０１に結合される、ランダムアクセスメモリ（ＲＡＭ）または他の動的記憶デバイス９０４（メインメモリと称される）をさらに含む。メインメモリ９０４はまた、プロセッサ９０２による命令の実行中に一時的な変数または他の中間情報を記憶するために使用されてよい。コンピューティングデバイス９００は、プロセッサ９０２に対する静的情報および命令を記憶するためにバス９０１に結合される、読み出し専用メモリ（ＲＯＭ）および／または他の静的記憶デバイス９０６を含んでもよい。例えば、磁気ディスクまたはフラッシュストレージなどの非一時的な有形データ記憶デバイス９０７は、情報および命令を記憶するためにバス９０１に結合されてよい。非一時的な有形データ記憶デバイスは、プロセッサ９０２によって実行される時、コンピューティングデバイスに、本明細書に説明されかつ示される実施形態の１つまたは複数を実行させる、コンピュータ可読命令を記憶するように構成されてよい。コンピューティングデバイス９００はまた、コンピュータユーザに情報を表示するためにバス９０１を介してディスプレイデバイス９１０に結合されてよい。英数字キーおよび他のキーを含む英数字入力デバイス９２２は、情報およびコマンド選択をプロセッサ（複数可）９０２に通信するためにバス９０１に結合されてよい。別のタイプのユーザ入力デバイスは、方向情報およびコマンド選択をプロセッサ９０２に通信し、かつディスプレイデバイス９１０上のカーソル移動を制御するための、マウス、トラックボール、またはカーソル方向キーなどのカーソル制御９２３である。コンピューティングデバイス９００は、通信デバイス（例えば、モデム、ＮＩＣ）を介してネットワーク９２６に、および分散コンピューティングシステムの１つまたは複数のノードに結合されてよい。

【0085】

実施形態は、コンピュータネットワーク上でデータセンタにわたってメタデータおよびデータの整合性を維持するためのコンピューティングデバイスの使用、および／または複数のこのようなコンピューティングデバイスに関連している。１つの実施形態によると、本明細書に説明される方法およびシステムは、プロセッサ（複数可）９０２がメモリ９０４に含有される命令のシーケンスを実行することに応じて、１つまたは複数のコンピューティングデバイス９００によって提供されてよい。このような命令は、データ記憶デバイス９０７など、別のコンピュータ可読媒体からメモリ９０４内に読み出されてよい。メモリ９０４に含有される命令のシーケンスの実行によって、プロセッサ（複数可）９０２は、ステップを行い、かつ本明細書に説明される機能を有する。代替的な実施形態では、ハードワイヤード回路は、本発明を実装するためにソフトウェア命令の代わりにまたはこれと組み合わせて使用されてよい。よって、本発明は、ハードウェア回路およびソフトウェアの任意の特定の組み合わせに限定されない。実際は、任意の適したコンピューティングデバイスが本明細書に説明される機能性を実装することができることは、当業者には理解されるべきである。コンピューティングデバイスは、所望の機能を実行するために機能する１つまたは複数のマイクロプロセッサを含んでよい。１つの実施形態では、マイクロプロセッサ（単数または複数）によって実行される命令は、マイクロプロセッサ（複数可）に本明細書に説明されるステップを行わせるように動作可能である。命令は、任意のコンピュータ可読媒体に記憶可能である。１つの実施形態では、該命令は、マイクロプロセッサに外付けされる不揮発性半導体メモリ上に記憶されてよい、または、マイクロプロセッサと一体化されてよい。別の実施形態では、命令は、ディスク上に記憶され、かつマイクロプロセッサによる実行前に揮発性半導体メモリに読み込まれてよい。

【0086】

上述されたさまざまな特徴およびプロセスは、互い無関係に使用されてよい、またはさまざまなやり方で組み合わせられてよい。ある特定の例示の実施形態が説明されているが、これらの実施形態は、例としてのみ提示されており、本明細書に開示される発明の範囲を限定することを意図するものではない。よって、前述の説明において、任意の特定の特徴、特性、ステップ、モジュール、またはブロックが必要であるまたは不可欠であることを含意することは意図されていない。実際は、本明細書に説明される新規の方法およびシステムはさまざまな他の形式で具現化可能であり、さらに、本明細書に開示される実施形態の趣旨から逸脱することなく、本明細書に説明される方法およびシステムの形式におけるさまざまな省略、置き換え、および変更がなされてよい。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】