(57)【要約】様々な実施形態は、高度にスケーラブルなファイル複製システムを実施する複製エンティティの概念について紹介したものである。一実施形態では、複製エンティティは、スケーラブル複製サービスの形態で存在している。少なくともいくつかの実施形態では、複製サービスは、加入者などの個人のファイルが安全な常時オン位置に自動的に複製されるよう、その個人が自身の個々の機械を同期させるために使用することができる「ドライブ・イン・ザ・スカイ」機能を提供している。別法または追加として、加入者などの個人は、その個人が自身の機械から遠くに離れている場合、ウェブベースインタフェースを介して自身のファイルにアクセスすることも可能である。【選択図】図６
2009525534.tif 000002
【特許請求の範囲】
【請求項１】
ファイルを複製し、
ファイルデータをスケーラブル・バイナリ・ラージ・オブジェクト（ｂｌｏｂ）記憶（７１６）に記憶し、かつ、
ファイルメタデータをスケーラブルメタデータ記憶（７１４）に記憶する
ように構成された複製エンティティ（７０６）を備えたシステム。
【請求項２】
前記複製エンティティが、複製メタデータと前記スケーラブルメタデータ記憶内のファイルメタデータとを併合するように構成された、請求項１に記載のシステム。
【請求項３】
前記複製エンティティが、前記ｂｌｏｂ記憶に対する更新に応答し、ファイルメタデータおよび複製メタデータの両方をまとめて処理するように構成された、請求項２に記載のシステム。
【請求項４】
前記複製エンティティが、ウェブインタフェースを介して少なくともいくつかの更新を受け取るように構成された、請求項３に記載のシステム。
【請求項５】
前記複製エンティティがサービスを備えた、請求項１に記載のシステム。
【請求項６】
前記複製エンティティが１つまたは複数のハブを備えた、請求項１に記載のシステム。
【請求項７】
前記複製エンティティが状態ベース複製エンティティとして構成された、請求項１に記載のシステム。
【請求項８】
前記ｂｌｏｂ記憶がフル・ファイル・システム・セマンティクスを必要としない、請求項１に記載のシステム。
【請求項９】
それぞれ、状態ベースファイル複製を提供するように構成されたファイル複製エンジン（７０６）と結合している１つまたは複数の複製フロントエンドと、
フル・ファイル・システム・セマンティクスを必要としない方法でファイルデータを記憶するための少なくとも１つのスケーラブルファイル記憶（７１６）と、
関連するファイルメタデータを記憶するための少なくとも１つのスケーラブルメタデータ記憶（７１４）と
を備えたシステム。
【請求項１０】
前記少なくとも１つのスケーラブルメタデータ記憶が、前記ファイルメタデータと結合している複製メタデータを記憶する、請求項９に記載のシステム。
【請求項１１】
１つまたは複数のアクセスノードをさらに備え、その各々が、前記複製メタデータおよび関連するファイルメタデータの両方をまとめて処理するように構成された、請求項１０に記載のシステム。
【請求項１２】
前記システムがサービスとして具体化された、請求項９に記載のシステム。
【請求項１３】
複製クライアントが、ファイルシステム上を走っている他の複製クライアントを使用して複製する場合に利用されることになる同じ複製プロトコルを使用している複製サービスと共に双方向複製に関係することができる、請求項１２に記載のシステム。
【請求項１４】
複製クライアントを複製フロントエンドの特定のインスタンスに導くための１つまたは複数の複製グループ・リダイレクション・サービスをさらに備えた、請求項９に記載のシステム。
【請求項１５】
１つまたは複数のサーバをさらに備え、その各々が、１つまたは複数のウェブクライアントと通信し、かつ、前記１つまたは複数のウェブクライアントのためのＨＴＭＬファイルシステムビューを提供するように構成されたプレゼンテーションレイヤのホストをしている、請求項９に記載のシステム。
【請求項１６】
１つまたは複数のスケーラブル・ファイル・サービス・アクセス・ノードをさらに備え、そのうちの少なくともいくつかが、ファイルをステージ化されたファイルフォーマットに整列させ、かつ、ステージ化されたファイルの整列を解除するように構成された、請求項９に記載のシステム。
【請求項１７】
ステージ化されたファイルを複製エンティティ（７０６）を使用して受け取るステップと、
前記ステージ化されたファイルの書込みリクエストを記憶アクセスノード（７１２）に送るステップと、
前記ステージ化されたファイルをスケーラブル・バイナリ・ラージ・オブジェクト（ｂｌｏｂ）記憶（７１６）に送るステップと、
前記ステージ化されたファイルのためのロケータトークンを前記ｂｌｏｂ記憶（７１６）から受け取るステップと、
複製メタデータ、前記ステージ化されたファイルのためのファイル・システム・メタデータおよび前記ロケータトークンを書き込むためのメタデータ書込みリクエストを前記記憶アクセスノード（７１２）に送るステップと、
前記メタデータ書込みリクエストをスケーラブルメタデータ記憶（７１４）に送るステップと、
前記スケーラブルメタデータ記憶（７１４）上で前記メタデータ書込みリクエストを実行するステップと
を含むコンピュータ実施方法。
【請求項１８】
ステージ化されたファイルを受け取る前記ステップの前に、複製クライアントから通信および前記通信に対する応答を受け取るステップと、ファイルを複製するための複製エンジンを備えた複製フロントエンドの特定のインスタンスに前記複製クライアントを導くステップとをさらに含む、請求項１７に記載の方法。
【請求項１９】
ファイルを１つまたは複数のウェブクライアントから前記複製エンティティへアップロードするステップをさらに含む、請求項１７に記載の方法。
【請求項２０】
ファイルを前記複製エンティティから１つまたは複数のウェブクライアントへダウンロードするステップをさらに含む、請求項１７に記載の方法。
【発明の詳細な説明】
【背景技術】
【０００１】
マルチマスタファイル複製システムは、多年にわたり、状態ベース複製または事象ベース複製などの様々な手法を使用して構築されている。通常、これらのシステムは、１つのノードに対するファイルまたはディレクトリになされた変更が他のノードに伝播するよう、複数の計算デバイス（ノード）間のファイルシステムの一部を同期させる。
【発明の開示】
【発明が解決しようとする課題】
【０００２】
複製が生じる計算デバイスは、その計算デバイスを走らせることができないか、あるいはその計算デバイスをインターネットから切り離すことができないかのいずれかの理由により、多数回にわたって、永久にアクセスすることができないコンピュータであろうとする傾向を示す。したがって、これらの環境下では、通常、ユーザがユーザの計算デバイスにアクセスする場合、ユーザがアクセスすることができるのは、ユーザの複製されたファイルのみである。したがって、頻繁に旅行するユーザは、ユーザのファイルにアクセスするのに大きな困難を経験することになる。
【課題を解決するための手段】
【０００３】
様々な実施形態によって、高度にスケーラブルなファイル複製システムを実施する複製エンティティの概念について紹介する。一実施形態では、複製エンティティは、スケーラブル複製サービスの形態で存在している。少なくともいくつかの実施形態では、複製サービスは、加入者などの個人のファイルが安全な常時オン位置に自動的に複製されるよう、その個人が自身の個々の機械を同期させるために使用することができる「ドライブ・イン・ザ・スカイ」機能を提供している。別法または追加として、加入者などの個人は、その個人が自身の機械から遠くに離れている場合、ウェブベースインタフェースを介して自身のファイルにアクセスすることも可能である。
【発明を実施するための最良の形態】
【０００４】
概要
以下で説明する様々な実施形態は、高度にスケーラブルなファイル複製システムを実施する複製エンティティの概念について紹介したものである。複製エンティティは、サービスまたは１つまたは複数の複製ハブなどの適切な任意の形態で存在することができる。
【０００５】
本明細書の中で使用されている実施形態では、複製エンティティは、スケーラブル複製サービスの形態で存在している。少なくともいくつかの実施形態では、複製サービスは、加入者などの個人のファイルが安全な常時オン位置に自動的に複製されるよう、その個人が自身の個々の機械を同期させるために使用することができる「ドライブ・イン・ザ・スカイ」機能を提供している。別法または追加として、加入者などの個人は、その個人が自身の機械から遠くに離れている場合、ウェブベースインタフェースを介して自身のファイルにアクセスすることも可能である。
【０００６】
本発明による実施形態は、極めて多数の加入者に対するスケーリング複製サービスに関連する問題に対処している。たとえば、数十または数百ペタバイト（ＰＢ）の記憶容量に及ぶ単純なスケーリングファイルシステムは、当業者には理解されるように、相当なコスト、スケーラビリティ、管理および信頼性に関わる課題を抱えている。スケーラビリティ、管理および信頼性の点で理想的な特性を提供する記憶を構築することは可能であるが、通常、それらは、そのスケールでこのようなセマンティクスを提供することに関連する複雑性のため、フル・ファイル・システム・セマンティクスを有していない。また、ファイルシステム複製システムは、通常、複製メタデータの一部をサイド上に維持している。このメタデータは、ファイルシステム更新経路とは別に更新されるため、メタデータと実際のファイルシステムの内容との同期が取れていないことがある（実際に同期が取れていないことがしばしばである）。このような場合、反復子は、通常、ファイルシステム全体を再走査し、メタデータの信頼すべきコピーを再構築しなければならない。スケーラブルサービスにおいては、再走査（とりわけ再走査が比較的頻繁に生じる場合）は、場合によっては極めて厄介な操作である。
【０００７】
したがって、以下で説明する実施形態のうちの少なくともいくつかでは、ファイルシステムをサービスに使用しない設計によって、これらおよび他の問題に対処している。実際、この設計は、フル・ファイル・システム・セマンティクスを提供しない、スケーラブルで、自己管理型であり、かつ、信頼性の高いバイナリ・ラージ・オブジェクト（ｂｌｏｂ）記憶（以下では、「スケーラブルファイル記憶」とも呼ばれている）の使用に基づいている。たとえば、フル・ファイル・システム・セマンティクスを提供しない、ということは、場合によっては、階層ファイルネーム空間、論理ファイル名、ファイル更新操作、ファイル切捨てまたは拡張、スパースファイル、ファイルロッキングあるいはファイルシステム変更ジャーナルのうちの１つまたは複数をサポートしないことを意味している。「スカイ」ノードが複数の加入者ノードのうちの１つからファイルを受け取る場合、そのファイルは、実際のファイルデータとメタデータの両方を含んだバイナリ・ラージ・オブジェクト（ｂｌｏｂ）として受け取られる。しかしながら、そのｂｌｏｂをアンパックし、かつ、アンパックしたｂｌｏｂをファイルシステムに記憶する代わりに、スカイノードは、ｂｌｏｂを単純にスケーラブルｂｌｏｂ記憶に記憶している。
【０００８】
また、少なくともいくつかの実施形態では、複製メタデータは、スケーラブルファイル記憶メタデータと併合され、あるいはスケーラブルファイル記憶メタデータと共に記憶される。したがって、ｂｌｏｂ記憶の更新（複数の加入者機械のうちの１つを使用した複製に端を発するものであれ、あるいはウェブインタフェースを介してなされる変更によるものであれ）は、すべて、ｂｌｏｂ記憶メタデータおよび複製メタデータの両方を同時に処理することができる。したがって複製メタデータとｂｌｏｂ記憶の間の同期の問題が軽減され、延いては再走査の必要性が除去される。
【０００９】
スケーラブルファイル複製についての以下の説明に対するいくつかのコンテキストを提供するために、次のオン状態ベース複製について考察する。本発明による実施形態は、状態ベース複製のコンテキストの中で説明されているが、本明細書において説明されている技法は、事象ベース反復子などの他のタイプの反復子にも適用することができることを認識し、かつ、理解されたい。
【００１０】
状態ベース複製
ファイル反復子を使用して、複数の機械（計算デバイス）すなわち「ノード」間のファイルシステムの内容が同期化される。複数のノードのうちの１つのファイルシステムに対して実行された修正は、すべて、他のノードに伝播することになる。反復子は、複数のノードの同じファイルに対する矛盾する更新、等々などのあらゆる可能競合条件を取り扱うように設計されている。ノードファイルシステムは、ＮＴＦＳ、ＦＡＴ、ＸＦＳ、等々などの通常のノードファイルシステムのうちの任意のノードファイルシステムであってもよい。
【００１１】
図１は、一括して１００で示されている典型的な状態ベース複製システムを構築しているコンポーネントの高レベルの概要を提供したものである。図１では、上流側のノード１０２および下流側のノード１０４の２つのノードが存在している。これらのノードは、一方向同期で上流側１０２から下流側１０４へ係合している。双方向同期を達成するために、ノード１０２および１０４に上流側の役割と下流側の役割の両方を同時に発揮させることも可能である。
【００１２】
ファイルシステム修正事象は、個々のノード上で局部的に処理され、そのノードの複製メタデータ・データベース１０６に蓄積される。ＮＴＦＳの場合、ファイルシステム修正事象は、あらゆるファイル作成、消去および修正を記録しているファイルシステムの変更ジャーナル１０８から読み出すことができる。他のファイルシステムは、異なる通知機構を有することができる。ノードデータベースのＩＤテーブル１１０は、複製されたファイル毎の複製メタデータおよびディレクトリを記録している。２つのノード間で同期させる必要のあるファイルを有効に決定し、また、矛盾を識別し、かつ、解決してファイルを移動させるためには、実際のファイルシステムデータ以外にこのメタデータが必要である。
【００１３】
この実施例では、上流側のノード１０２は複製された内容を提供し、また、下流側のノード１０４は複製された内容を受け取っている。νν−アップ矢印およびνν−ダウン矢印は、ノード間の通信を表しており、たとえば、上流側のノード１０２から下流側のノード１０４へ最少量の更新を確実に流すことができるように設計されるバージョンベクトルの交換などを表している。スペース矢印および更新矢印は、バージョンベクトルの交換に引き続いて、下流側のノード１０２が上流側のノード１０４から受け取る更新の数を制御することができるクレジットシステムを表している。
【００１４】
下流側のノード１０４は、当業者には理解されるように、合致するコンポーネント１１２を使用して更新を処理し、かつ、ファイルに対する更新の性質に応じて、ファイルをダウンロードするかあるいは消去するか決定している。ファイルをダウンロードすることをノード１０４が決定すると、ノード１０４は、上流側のノード１０２からファイルの内容を受け取り、受け取ったファイルの内容をステージング領域１１４に置く。ファイルは、ゲットプロトコルおよびプットプロトコルを使用してノード間で交換される。
【００１５】
この図の他のコンポーネントは、ファイルシステムインタフェース（ＦＳ）およびＦＳ上に存在しているメタデータを含んだデータベース１０６からなっている。また、データベースには、すべての複製ノードに対して包括的な識別子が含まれている。
【００１６】
次に、ＩＤテーブル１１０に関して、直ぐ下の表１に示されている、ＩＤテーブル１１０に記憶されている主複製メタデータの概要について説明する。
【００１７】
【表１】
2009525534.tif 000003
最初の２つの欄（ＵｉｄＭａｃｈｉｎｅおよびＵｉｄＶｅｒｓｉｏｎ）は、資源の固有の包括的識別子を与えている。この固有の包括的識別子は、資源が更新されても変化することはなく、その資源の寿命が尽きるまで不変である。
【００１８】
一方、包括的バージョンシーケンス番号（すなわちＧｖｓｎＭａｃｈｉｎｅおよびＧｖｓｎＶｅｒｓｉｏｎ）は、所与の資源が更新されると必ず変化する。ＧｖｓｎＭａｃｈｉｎｅ欄は、その変化をもたらしたパートナーを識別しており、また、ＧｖｓｎＶｅｒｓｉｏｎ欄は、その変化のタイムスタンプを識別している。
【００１９】
ＰａｒｅｎｔＭａｃｈｉｎｅ欄およびＰａｒｅｎｔＶｅｒｓｉｏｎ欄は、親ディレクトリの固有識別子を識別している。とりわけ、ファイルはファイルシステムの中で複製されるため、オブジェクトが複製された先祖関係が存在している。親欄は、ファイルが存在しているディレクトリを識別するために使用される欄である。
【００２０】
Ｃｌｏｃｋ欄は、資源の更新時間を提供しており、更新の矛盾を解決するために使用される。とりわけ、並行する２つの更新が存在している場合、それらの更新は、通常、異なるクロックを有することになり、それらを使用して矛盾が解決される。
【００２１】
また、ＣｒｅａｔｅＴｉｍｅ欄は、ディレクトリの矛盾を解決するために使用される。固定資源の作成時間は不変である。
【００２２】
Ｎａｍｅ欄は、ファイルシステムに出現する際の資源の名称である。これは、完全に修飾された名称ではなく、むしろ親に対する名称である。
【００２３】
ノードは、図１に示すように、互いに周期的に同期が取られ、その時点でそれらはそれらのデータベース１０６を比較し、送る必要のある情報を決定する。このデータベース比較操作はｖｖｊｏｉｎと呼ばれている。状態ベース反復子は、当業者には理解されるように、同期化を実行するためのｖｖｊｏｉｎを有効に実行する能力に依存している。
【００２４】
同期の中核は、２つのパートナー間、つまり上流側のノードと下流側のノードの間のハンドシェークからなっている。当業者には理解されるように、同期は、必ず上流側のノードから下流側のノードに向かって生じる。双方向同期の場合、２つのハンドシェークが必要である。これらの２つのパートナーは、それらの個々のＩＤテーブルに反映されている、それらのファイルのすべてのＧＶＳＮのサマリーであるバージョンベクトルを交換することによってハンドシェークを開始する。上流側のノードは、その下流側のパートナーから受け取ったバージョンベクトルに基づいて、その下流側のパートナーが未だ見ていない情報（つまりファイル）を上流側のノードが有していることを決定する。上流側のノードは、次に、更新（つまり下流側が未だ見ていないファイルに関する情報）の送りを開始し、また、下流側のノードは、これらの更新に基づいて内容をダウンロードする。
【００２５】
図１に示すように、上流側のノードおよび下流側のノードは、ステージング領域１１４を使用してダウンロードおよびアップロードを実行している。この領域は、アップロードまたはダウンロードされる１つまたは複数のファイルの整列されたバージョンを保持するために使用される個別のディレクトリである。このステージング領域は、当業者には理解されるように、下流側の複製セット中の違反、部分ダウンロードおよびオフバンド複製の共有を処理するために使用される。
【００２６】
図２は、ステージング領域１１４の使用を含む、１つのファイルＦを複製するプロセスを示したものである。図２では、下流側のノード１０４は、１で、上流側のノード１０２にリクエストＧｅｔ（Ｆ）を送り、ファイルＦを転送する準備をしている。２で、上流側のノード１０２は、ファイルＦのデータおよびメタデータをバイナリ・ラージ・オブジェクト（ｂｌｏｂ）Ｓｔａｇｅｄ（Ｆ）の中に整列させ（つまり「ステージ」し）、このｂｌｏｂをステージング領域１１４に記憶する。ＮＴＦＳファイルの場合、Ｓｔａｇｅｄ（Ｆ）には、ファイルＦの主データストリーム、あらゆる交代用データストリーム、ならびにファイル作成時間およびアクセス制御リスト（ＡＣＬ）などの複製されたメタデータが含まれている。最後に修正された時間などのＮＴＦＳメタデータの一部は、必ずしも複製する必要はなく、したがってＳｔａｇｅｄ（Ｆ）には含まれていない。上流側のノードは、次に、３で、Ｓｔａｇｅｄ（Ｆ）を応答Ｐｕｔ（Ｓｔａｇｅｄ（Ｆ））を介して下流側のノード１０４に送る。また、同じく３で、下流側のノード１０４は、Ｓｔａｇｅｄ（Ｆ）をそのステージング領域１１４に記憶する。最後に、４で、下流側のノード１１４は、Ｓｔａｇｅｄ（Ｆ）の整列を解除し、複製されたファイルＦの独自のコピーを作成し、同期化されたディレクトリの独自のコピーの中にインストールする。
【００２７】
図３は、Ｓｔａｇｅｄ（Ｆ）のコンポーネントをより詳細に示したものである。ファイルＦの圧縮整列表現ＣＭ（Ｆ）に加えて、これらのコンポーネントは、他のメタデータを含むことができる。たとえば、ファイルＦを差動転送するために使用されるシグネチャ（すなわち遠隔差動圧縮つまりＲＤＣシグネチャ）、ならびにファイルの圧縮バージョンの中を有効に探索するために使用されるジャンプテーブルで追加メタデータを構築することができる。この他のメタデータは、Ｓｔａｇｅｄ（Ｆ）を表すＮＴＦＳファイルの交代用スパースストリームの中に記憶することができる。
【００２８】
ノードは、遠隔資源のためのメタデータを受け取ると、その資源およびその特定のバージョンに関連するファイル内容が許容されるかどうかを決定しなければならない。詳細には、ファイルは、次のフィルタを通過しなければならない。
【００２９】
１．親ＵＩＤに対応するディレクトリが存在しない場合、ファイル内容をファイルシステムに受け入れることはできない。同様に、親ＵＩＤに対応するメタデータが、親ディレクトリが消去され、墓石として知られていることを示している場合、消去された親をそのメタデータをピアからダウンロードすることによって蘇生させることができない限り、そのファイル内容を受け取ることはできない。
【００３０】
２．ＵＩＤが異なり、かつ、同じ名称の同じ親の下でファイルまたはディレクトリがファイルシステム上に存在している場合、矛盾するファイルを別の名称に変えるか、あるいは複数の資源のうちの１つを完全に消去しない限り、そのファイル内容をファイルシステムに受け入れることはできない。
【００３１】
３．あるノードに対する現行のファイルシステム状態と比較した場合に、親によって強いられる先祖関係によってサイクルが導入される場合、現行のＮＴＦＳファイルシステムセマンティクスによって有向非周期グラフ構造階層が強いられるため、そのファイル内容を受け取ることはできない。
【００３２】
上記の試験に合格する更新であっても、その更新が局所で記憶されているファイルバージョンに無関係に構築された更新である、という意味では依然として矛盾している場合がある。本著作の協力者が同じ文書を同時に２つの異なるノードに対して編集する場合、このシナリオは共通である。しかしながら、両方のバージョンをファイルシステム上にインストールすることができるため、更新の矛盾がファイルシステムのいかなる制約にも違反することはない。
【００３３】
以上、ファイルの複製について説明したが、次に、スケーラブルファイル記憶について説明する。
【００３４】
スケーラブルファイル記憶
スケーラブルファイル記憶システムは、多年にわたり、ネーム空間分割（たとえばＡＦＳ、ＤＦＳ）、メタデータおよびｂｌｏｂ非干渉化（たとえばＧｏｏｇｌｅのＧＦＳ）および集合ファイルシステム（たとえばＳｉｓｔｉｎａのＧＦＳ）を始めとする様々な手法を使用して構築されている。本明細書において説明されている技法および手法は、メタデータおよびｂｌｏｂを非干渉化するスケーラブルファイル記憶に適用されているが、本明細書において説明されている技法は、他のタイプのスケーラブルファイル記憶に適用することも可能である。
【００３５】
図４は、ファイル・システム・メタデータおよびｂｌｏｂ記憶を非干渉化する、一括して５００で示されているスケーラブルファイル記憶を構築しているシステムのコンポーネントの高レベルの概要を提供したものである。この実施例では、システム５００は、１つまたは複数のアクセスノード５０２、１つまたは複数のメタデータノード５０４、および１つまたは複数のｂｌｏｂ記憶ノード５０６を備えている。
【００３６】
スケーラブル・ファイル・システム・メタデータは、メタデータを記憶し、かつ、指標付けするために最適化された１つまたは複数のノード５０４上に記憶されている。メタデータは、可用性および信頼性のために複製される。ＳＱＬデータベースは、メタデータ記憶として広く使用されている。
【００３７】
ファイルのためのデータストリームは、当業者には理解されるように、通常、ｂｌｏｂを記憶するために最適化された１つまたは複数のノード５０６上に記憶されている。スケーラブルｂｌｏｂ記憶は、通常、従来のファイルシステムと比較すると、提供する記憶セマンティクスが少なく、提供しているのは、通常、オブジェクトプット操作、オブジェクトゲット操作およびオブジェクト消去操作のみである。ｂｌｏｂ記憶に書き込まれたオブジェクトは、可用性および信頼性のために複製される。
【００３８】
クライアントは、遠隔ＨＴＴＰおよびＳＯＡＰ  ＡＰＩをアクセスノード５０２上に呼び出すことによってスケーラブル・ファイル・システムの操作を実行する。アクセスノード５０２は、以下でより詳細に説明するように、ファイルのデータストリームのｂｌｏｂ記憶ノード５０６への記憶を実行し、また、データストリームに関連するメタデータのメタデータノード５０４への記憶を実行するように設計された記憶論理を備えている。
【００３９】
図５は、図４に示すシステムに１つのファイルＦを記憶するプロセスを示したものである。丸で囲まれた数字は、個々のファイル記憶ステップを示している。
【００４０】
記憶クライアントは、最初に、１で、アクセスノード５０２にＦの書込みリクエストを送る。アクセスノード５０２は、２で、プット操作を使用してスケーラブルｂｌｏｂ記憶５０６にＦのデータストリーム（Ｆｄ）を送る。３で、スケーラブルｂｌｏｂ記憶５０６のうちの少なくとも１つのノード上にＦｄが記憶される。Ｆｄは、ＮＴＦＳファイルとして、あるいはいくつかのｂｌｏｂが集まってグループをなしている幾分かより大きいファイルの中のチャンクとして記憶させることができる。Ｆｄは、４で、プットの永続性を保障するために、プット操作が完了する前にｂｌｏｂ記憶５０６の中に複製することができる。
【００４１】
ｂｌｏｂ記憶５０６は、５で、ＦｄのためのロケータトークンをＬｔ（Ｆｄ）に戻す。このロケータトークンは、後で、Ｆｄの内容を探し出し、検索するためのｂｌｏｂ記憶のゲット操作に対する引き数として使用することができる。
【００４２】
アクセスノード５０２は、６で、ファイル・システム・メタデータＦｍとＦのためのロケータトークンの両方を記憶するためのメタデータ書込みリクエストをメタデータ記憶５０４に送る。次に、７で、ＦｍおよびＬｔ（Ｆｄ）がメタデータ記憶５０４に記憶される。８で、ＳＱＬ複製を使用して、その永続性を保障するためにこの情報を複製することができる。
【００４３】
ファイルＦを検索するためには、上記プロセスが逆の順序で実施される。つまり、アクセスノード５０２によって最初にロケータトークンがメタデータ記憶５０４から検索され、次に、そのロケータトークンを使用してｂｌｏｂ記憶５０６内の適切なｂｌｏｂの位置が突き止められる。
【００４４】
関連するファイルシステムを備えたノードに対するファイル複製サービスは、上で説明した条件１、２および３をチェックしなければならないことになる。しかしながら、ファイルシステムのないプロキシに対する複製サービスは、プロキシがオブジェクトを記憶しているのはファイルシステム制約を必要としないオブジェクト記憶のみであるため、これらの条件を考慮する必要はない。したがって、改良されたスケーラビリティおよび遅延矛盾解決法が提供される。
【００４５】
例示的実施例−Ｓｋｙ  Ｄｒｉｖｅアーキテクチャ
図６は、一実施形態による例示的Ｓｋｙ  Ｄｒｉｖｅアーキテクチャを一括して７００で示したものである。この実施形態では、アーキテクチャは、状態ベース複製システムとスケーラブルファイル記憶を組み合わせることにより、ファイル複製およびウェブベースアクセスのためのスケーラブルサービスを提供している。このアーキテクチャは、適切な任意のハードウェア、ソフトウェア、ファームウェアまたはそれらの組合せと共に実施することができる。一実施形態では、アーキテクチャの様々なコンポーネントは、コンピュータ可読媒体上に存在しているコンピュータ実行可能命令の形態のソフトウェアの中で実施されている。
【００４６】
この特定の実施形態では、このアーキテクチャ７００には、限定ではなく例として、ダッシュ線で輪郭が描かれている消費者側コンポーネントおよびサービス側コンポーネントが含まれている。
【００４７】
消費者側コンポーネントには、１つまたは複数の複製クライアント７０２および１つまたは複数のウェブクライアント７０４が含まれている。サービス側コンポーネントには、複製エンジンを個々に備えた１つまたは複数の複製フロントエンド７０６、１つまたは複数の複製グループ・リダイレクション・サービス７０８、プレゼンテーションレイヤを備えた１つまたは複数のウェブサービス７１０、１つまたは複数の記憶アクセスノード７１２、１つまたは複数のメタデータノード７１４および１つまたは複数のｂｌｏｂ記憶ノード７１６が含まれている。一実施形態によれば、記憶アクセスノードには、以下でより詳細に説明する複製ビジネス論理および記憶論理と共に、上で言及したＨＴＴＰおよびＳＯＡＰ  ＡＰＩが含まれている。
【００４８】
この実施形態では、スケーラブル・ファイル・システムのメタデータノードに記憶されているファイル・システム・メタデータは、表１に記載されている反復子のメタデータを使用して増補される。一体化されたメタデータに対する更新は、スケーラブル・ファイル・サービスのためにアクセスノード７１２の中を走っている複製ビジネス論理によって実施され、したがって両方のメタデータ片をまとめて処理することができる。ファイルのためのデータストリームは、図３で説明したように、それらのステージ化されたフォーマットでスケーラブルｂｌｏｂ記憶７１６に記憶される。これは、消費者複製クライアントを使用した複製プロセスを最適化するために実施される。
【００４９】
消費者複製クライアント７０２は、複製フロントエンド７０６のホストである状態ベース複製エンジンのインスタンスを使用して状態ベース複製を実行する。消費者の複製クライアントは、通常のファイルシステムの一番上を走っている他の消費者ベース反復子を使用して複製する場合に利用される同じ複製プロトコルを使用している複製サービスと共に双方向複製に関係しており、したがって、従来のファイルシステムを使用した複製と機能的に等価であるｂｌｏｂ記憶によって支持された複製サービスを使用して複製している。
【００５０】
消費者は、複製グループ・リダイレクション・サービス７０８を介して複製フロントエンド７０６の特定のインスタンスに導かれ、したがって、一組のファイルのすべての複製が、その一組のファイルに対する複製を積極的に実行する消費者の数に無関係に、状態ベース複製エンジンの単一インスタンス上で実行されることを保証している。更新矛盾の数を少なくするために、ファイルセットと複製エンジンの特定のインスタンスの間の類似性を利用して、複製フロントエンド７０６に対する更新のメモリ内固定および順序付けすることができる。通常、所与のセットのファイルを複製する消費者の数は少数であり、つまり数百を超えることはない。
【００５１】
ウェブベースクライアント７０４は、ファイルシステムをＨＴＭＬで表現するウェブサーバ７１０のホストであるプレゼンテーションレイヤと通信している。プレゼンテーションレイヤは、ウェブベースクライアント７０４からのＨＴＴＰリクエストを翻訳し、翻訳したこれらのリクエストをスケーラブル・ファイル・サービス・アクセス・ノード７１２に送る。スケーラブル・ファイル・サービス・アクセス・ノード７１２に埋め込まれている複製ビジネス論理は、ウェブアップロードの結果としてファイルを書き込んでいる間（つまりＨＴＴＰ  ＰＵＴリクエストの間）、ファイルをステージ化されたファイルフォーマットに整列させ（たとえば図３で説明したように）、また、ウェブダウンロードによってもたらされる読出しリクエストの間（つまりＨＴＴＰ  ＧＥＴリクエストの間）、ステージ化されたファイルの整列を解除する。
【００５２】
一実施形態による、消費者複製クライアントからスカイ・ドライブ・アーキテクチャにファイルを複製するための制御の流れを一括して７００で示した図７について考察する。丸で囲まれた数字は、複製プロセスの様々なステップを示している。
【００５３】
この実施例では、複製クライアント７０２は、１で、複製グループ・リダイレクション・サービス７０８とコンタクトし、ファイルＦを複製するために使用する複製フロントエンドを決定している。複製クライアント７０２は、次に、２で、ファイルＦを整列させ、Ｓｔａｇｅｄ（Ｆ）で示されているステージ化されたファイルを作成する。ステージ化されたファイルを作成することができる方法の一実施例については、図３および４に関連して上で説明した通りである。クライアントは、次に、３で、Ｓｔａｇｅｄ（Ｆ）を適切な複製フロントエンド７０６に送る。複製フロントエンドは、４で、Ｓｔａｇｅｄ（Ｆ）の書込みリクエストを記憶アクセスノード７１２に送る。記憶アクセスノード７１２は、次に、５で、Ｓｔａｇｅｄ（Ｆ）をスケーラブルｂｌｏｂ記憶７１６に送る。６で、プット操作を要求することにより、少なくとも１つのｂｌｏｂ記憶ノード７１６上にＳｔａｇｅｄ（Ｆ）が記憶される。Ｓｔａｇｅｄ（Ｆ）は、７で、プットの永続性を保障するために、プットリクエストが完了する前にｂｌｏｂ記憶の中に複製することができる。
【００５４】
ｂｌｏｂ記憶は、８で、Ｓｔａｇｅｄ（Ｆ）のためのロケータトークンをＬｔ（Ｓｔａｇｅｄ（Ｆ））に戻す。複製フロントエンド７０６は、次に、９で、メタデータ書込みリクエストを記憶アクセスノード７１２に送り、複製メタデータ（図２のＩＤ＿Ｔａｂｌｅデータ）、Ｆのためのファイル・システム・メタデータＦｍ、およびＳｔａｇｅｄ（Ｆ）のためのロケータトークンＬｔ（Ｆｄ）が書き込まれる。記憶アクセスノード７１２は、１０で、書込みリクエストをメタデータ記憶７１４に送る。１１で、少なくとも１つのメタデータノードに対する書込みが実施される。１２で、ＳＱＬ複製を使用して、メタデータノード不良の存在を処理する永続性を保障することができる。
【００５５】
一実施態様では、消費者複製クライアント７０２は、ステップ３の間、ファイルＦ全体をアップロードすることができる。他の実施態様では、消費者複製クライアント７０２からスケーラブルｂｌｏｂ記憶７１６へファイルＦを流し出すことができ、したがってパイプライン操作としてステップ３から５を実行することができる。ステップ３から５を実行している間に、それらに限定されないが、ネットワーク断路、複製クライアント不良またはサービス内における不良を始めとするエラーが発生すると、複製フロントエンド７０６は、後で消費者複製クライアントを使用したＳｔａｇｅｄ（Ｆ）の転送を再開するために必要な情報を記憶するべく試行することができる。この情報には、クライアントの識別および複製プロセスの再開に必要な他のあらゆるファイルバージョン情報を始めとする、ｂｌｏｂ記憶７１６へのＳｔａｇｅｄ（Ｆ）の部分転送バージョンの記憶、およびメタデータ記憶７１４へのＳｔａｇｅｄ（Ｆ）の部分転送バージョンに関するメタデータの記憶が含まれている。
【００５６】
次に、一実施形態による、ウェブクライアント７０４からスカイ・ドライブ・アーキテクチャへファイルをアップロードするための制御の流れを示した図８について考察する。丸で囲まれた数字は、複製プロセスの様々なステップを示している。
【００５７】
この実施例では、ウェブクライアント７０４は、１で、ファイルＦをウェブサーバ７１０にアップロードしている。ウェブサーバ７１０は、それに応答して、２で、ファイルＦを記憶アクセスノード７１２に書き込む。記憶アクセスノード７１２上の複製ビジネス論理は、３で、Ｆのステージ化されたバージョンであるＳｔａｇｅｄ（Ｆ）を作成する。このＳｔａｇｅｄ（Ｆ）には、図３に関連して上で説明した方法と同様の方法で生成ＩＤ  Ｔａｂｌｅ情報が含まれている。記憶アクセスノード７１２は、次に、４で、Ｓｔａｇｅｄ（Ｆ）をスケーラブルｂｌｏｂ記憶７１６に送る。５で、少なくとも１つのｂｌｏｂ記憶ノード７１６上にＳｔａｇｅｄ（Ｆ）が記憶される。Ｓｔａｇｅｄ（Ｆ）は、６で、プットの永続性を保障するために、プットリクエストが完了する前にｂｌｏｂ記憶７１６の中に複製することができる。ｂｌｏｂ記憶７１６は、次に、７で、Ｓｔａｇｅｄ（Ｆ）のためのロケータトークンをＬｔ（Ｓｔａｇｅｄ（Ｆ））に戻す。
【００５８】
記憶アクセスノード７１２内の複製論理レイヤは、８で、Ｆのためのファイル・システム・メタデータＦｍ、複製メタデータ（図２のＩＤ＿Ｔａｂｌｅデータ）、およびＳｔａｇｅｄ（Ｆ）のためのロケータトークンＬｔ（Ｓｔａｇｅｄ（Ｆ））を含んだメタデータ記憶７１４にメタデータ更新リクエストを送る。９で、少なくとも１つのメタデータノード７１４に対する書込みが実施される。１０で、ＳＱＬ複製を使用して、メタデータノード不良の存在を処理する永続性を保障することができる。
【００５９】
他のウェブクライアントまたは消費者複製クライアントによってなされた更新間の処理上の矛盾のために、ステップ８のメタデータ更新がうまくいかなかった場合、記憶アクセスノード内の複製論理レイヤは、メタデータの更新を再試行する。
【００６０】
一実施態様では、ウェブクライアント７０４は、ステップ１の間、ファイルＦ全体をアップロードすることができる。他の実施態様では、ウェブクライアント７０４からスケーラブルｂｌｏｂ記憶７１６へファイルＦを流し出すことができ、したがってパイプライン操作としてステップ１から５を実行することができる。
【００６１】
次に、一実施形態による、スカイ・ドライブ・アーキテクチャからウェブクライアントへファイルをダウンロードするための制御の流れを示した図９について考察する。丸で囲まれた数字は、ダウンロードプロセスの様々なステップを示している。
【００６２】
この実施例では、ウェブクライアント７０４は、１で、ウェブサーバ７１０にファイルＦをリクエストしている。ウェブサーバ７１０は、２で、記憶アクセスノード７１２からファイルＦを読み出すようリクエストする。記憶アクセスノード７１２上の記憶論理は、３で、メタデータ記憶７１４を使用して、Ｌｔ（Ｓｔａｇｅｄ（Ｆ））を得るためにファイルＦの探索を実行する。メタデータ記憶７１４は、４で、ＦをＬｔ（Ｓｔａｇｅｄ（Ｆ））にマップするために、Ｆのためのメタデータ（Ｆｍ、Ｌｔ（Ｓｔａｇｅｄ（Ｆ））、ＩＤテーブルデータ）をＳＱＬデータベースから読み出す。メタデータ記憶７１４は、５で、Ｌｔ（Ｓｔａｇｅｄ（Ｆ））を記憶アクセスノード７１２に戻す。記憶アクセスノード７１２上の記憶論理は、６で、ｂｌｏｂ記憶７１６からのＳｔａｇｅｄ（Ｆ）のために、Ｌｔ（Ｓｔａｇｅｄ（Ｆ））を使用し、かつ、ゲットリクエストを発行する。ｂｌｏｂ記憶７１６は、７で、記憶からＳｔａｇｅｄ（Ｆ）を読み出し、８で、Ｓｔａｇｅｄ（Ｆ）を記憶アクセスノード７１２に戻す。
【００６３】
記憶アクセスノード７１２上の複製ビジネス論理は、９で、Ｓｔａｇｅｄ（Ｆ）の整列を解除し、したがってＦが生成される。記憶アクセスノード７１２は、次に、１０で、ファイルＦをウェブサーバ７１０に戻し、ウェブサーバ７１０は、今度は、１１で、戻されたファイルＦをウェブクライアント７０４に戻す。
【００６４】
図９および１０の代替実施態様では、ウェブクライアント７０４は、Ｓｔａｇｅｄ（Ｆ）の整列および整列解除を実行するために、ＡｃｔｉｖｅＸ制御として具体化することができるようなビジネス論理を走らせている。したがって記憶アクセスノード７１２上でＳｔａｇｅｄ（Ｆ）を整列させ、また、整列を解除する必要性が軽減され、延いては、エンドツーエンドでＳｔａｇｅｄ（Ｆ）を読み出し、かつ、書き込むためのシステムが可能になり、記憶アクセスノード７１２上での資源消費が減少する。
【００６５】
拡張
上で指摘したように、上で説明した機能は、複製ハブの形態の複製エンティティを使用して実施することができる。つまり、１つまたは複数の常時オン複製ハブを有効に利用することにより、蓄積転送複製を提供することができ、また、典型的な複製クライアントより広いネットワーク帯域幅を提供することができる。このようなハブは、通常、典型的な複製ノードより極めて高いネットワーク連結性で商用データセンタに有効に利用することができる。複製ハブは、ファイルシステムがなく、したがってファイルのためのデータストリームのみの複製を提供する複製ハブであっても、あるいは上記アーキテクチャの節で説明したように、すべてのファイル・システム・メタデータを複製する複製ハブであってもよい。
【００６６】
結論
上で説明した様々な実施形態は、高度にスケーラブルなファイル複製システムを実施する複製エンティティを提供している。少なくともいくつかの実施形態では、複製サービスは、加入者などの個人のファイルが安全な常時オン位置に自動的に複製されるよう、その個人が自身の個々の機械を同期させるために使用することができる「ドライブ・イン・ザ・スカイ」機能を提供している。別法または追加として、加入者などの個人は、その個人が自身の機械から遠くに離れている場合、ウェブベースインタフェースを介して自身のファイルにアクセスすることも可能である。本発明による実施形態は、極めて多数の加入者に対するスケーリング複製サービスに関連する少なくともいくつかの問題に対処し、かつ、解決している。少なくともいくつかの実施形態では、上で説明したように、スケーラブルで、自己管理型であり、かつ、信頼性の高いバイナリ・ラージ・オブジェクト（ｂｌｏｂ）記憶によってこれらの問題に対処している。また、少なくともいくつかの実施形態では、複製メタデータは、スケーラブル記憶メタデータと併合される。したがって、ｂｌｏｂ記憶の更新（複数の加入者機械のうちの１つを使用した複製に端を発するものであれ、あるいはウェブインタフェースを介してなされる変更によるものであれ）は、すべて、ｂｌｏｂ記憶メタデータおよび複製メタデータの両方を同時に処理することができる。したがって複製メタデータとｂｌｏｂ記憶の間の同期の問題が軽減され、延いては再走査の必要性が除去される。
【００６７】
以上、本発明について、構造的特徴および／または方法論的ステップに特化された言語で説明したが、特許請求の範囲で定義されている本発明は、上で説明した特定の特徴またはステップに必ずしも限定されないことを理解されたい。そうではなく、これらの特定の特徴およびステップは、特許請求されている本発明を実施している好ましい形態として開示されている。
【図面の簡単な説明】
【００６８】
【図１】典型的な状態ベース複製システムを構築しているコンポーネントの高レベルの概要を示す図である。
【図２】ステージング領域の使用を含む、１つのファイルＦを複製するプロセスを示す図である。
【図３】ステージ化されたファイルのコンポーネントをより詳細に示す図である。
【図４】ファイル・システム・メタデータおよびｂｌｏｂ記憶を非干渉化するスケーラブルファイル記憶を構築しているシステムのコンポーネントの高レベルの概要を示す図である。
【図５】図４に示すシステムに１つのファイルＦを記憶するプロセスを示す図である。
【図６】一実施形態による例示的アーキテクチャを示す図である。
【図７】一実施形態による、消費者複製クライアントから図６に示すアーキテクチャにファイルを複製するための制御の流れを示す図である。
【図８】一実施形態による、ウェブクライアントから図６に示すアーキテクチャへファイルをアップロードするための制御の流れを示す図である。
【図９】一実施形態による、図６に示すアーキテクチャからウェブクライアントへファイルをダウンロードするための制御の流れを示す図である。
【図１】
2009525534.tif 000004
【図２】
2009525534.tif 000005
【図３】
2009525534.tif 000006
【図４】
2009525534.tif 000007
【図５】
2009525534.tif 000008
【図６】
2009525534.tif 000009
【図７】
2009525534.tif 000010
【図８】
2009525534.tif 000011
【図９】
2009525534.tif 000012
【国際調査報告】
2009525534.tif 000013
2009525534.tif 000014