JP2005032249A - フェンシングおよびフェンシング解除による、複製情報の権限の細分制御 - Google Patents

Abstract

【課題】 どのコンテンツが優先され複製されるかを制御するための方法およびシステムを提供すること。
【解決手段】 複製物セットは、リソースのセットからなる。各リソースは、リソースデータおよびリソースメタデータに関連する。ファイルベースのシステムの場合、リソースデータはファイルコンテンツおよび属性を含み、リソースメタデータは、複製中に同期を交渉するのに関係する追加の属性を含む。「フェンス値（ｆｅｎｃｅ ｖａｌｕｅ）」と呼ばれる特別なフィールドが、各リソースに関連するメタデータに追加される。同期中、最初にフェンス値が比較される。最大のフェンス値を有するリソースは、制御側コンテンツであって複製されるコンテンツを含む。フェンス値が等しい場合（および特定の値よりも大きい場合）は、制御側リソースは他のメタデータに基づいて決定される。
【選択図】 図８

Description

本発明は一般にコンピューティングデバイスに関し、より詳細には、リソース複製システムに関する。

日和見的でマルチマスタの複製システムでは、所与の複製物セットに関与している任意のマシン上の複製されたコンテンツに対して、自由な変更が可能である。潜在的に競合するこれらの変更は、複製システムの制御下で、競合する変更のどれが他よりも優先されるかをあらゆる競合状況について定義する競合解決基準を使用して調停される。過去、使用されてきた主要な競合解決基準は、物理的または論理的な変更時刻であり、一番最近の変更が他のすべての変更よりも優先されてきた。

しかし、同時に発生する更新のどれが他よりも優先され、反対にどの更新が優先権を譲るべきかを制御するための方法が他にもあればよいと、ユーザまたはアプリケーションが望む場合は多い。どのコンテンツが優先され複製されるかを制御するためのフレキシブルな方法およびシステムが必要とされている。

簡単に言えば、本発明は、どのコンテンツが優先され複製されるかを制御するための方法およびシステムを提供する。複製物セットは、リソースのセットからなる。各リソースは、リソースデータおよびリソースメタデータに関連する。リソースデータは、ファイルの場合はファイルコンテンツおよび属性を含み、リソースメタデータは、複製中に同期を交渉するのに関係する追加の属性を含む。「フェンス値（ｆｅｎｃｅ ｖａｌｕｅ）」と呼ばれる特別なフィールドが、各リソースに関連するメタデータに追加される。同期中、フェンス値が比較される。最大のフェンス値を有するリソースは、制御側コンテンツであって複製されるコンテンツを含む。フェンス値が等しい場合（および特定の値よりも大きい場合）は、制御側リソースは他のメタデータに基づいて決定される。

フェンス値は、コンテンツのローカル変更から独立している。すなわち、コンテンツのローカル変更は、他のメタデータ（例えばタイムスタンプ、クロック値、その他）に影響を与えることはあるが、特に指示がない限りフェンス値には影響を与えない。

本発明の一態様では、リソースは、リソースがフェンシング解除されている（ｕｎｆｅｎｃｅｄ）ことを示すフェンス値を有することができる。リソースがフェンシング解除されている場合、このことは、このリソースをそれが記憶されているマシンから送信すべきではないことを示す。争っているリソースが同期のために受け取られたとき、フェンシング解除されているリソースは、フェンシングされている（ｆｅｎｃｅｄ）リソースに負ける（そして同期中に置換される）。

本発明の別の態様では、勝ったリソースを有するマシン上のリソースと、負けたコンテンツを有するマシン上のリソースとの差分だけが送信される。例えば、リソースコンテンツを送信せずにリソースメタデータを送信することができる。別の例では、同期中にリソースコンテンツの差分を送信することができる。

その他の利点は、以下の詳細な説明を図面とともに読めば明らかになるであろう。

（例示的な動作環境）
図１に、本発明を実施するのに適したコンピューティングシステム環境１００の例を示す。コンピューティングシステム環境１００は、適したコンピューティング環境の一例にすぎず、本発明の使用または機能の範囲についてどんな制限も意味しない。またコンピューティング環境１００は、この例示的な動作環境１００に示すコンポーネントのいずれか１つまたは組合せに関してどんな依存や要件を有するものとも解釈すべきではない。

本発明は、その他多くの汎用または専用コンピューティングシステム環境または構成でも動作する。本発明で使用するのに適すると考えられる周知のコンピューティングシステム、環境、および／または構成の例には、限定しないがパーソナルコンピュータ、サーバコンピュータ、ハンドヘルドデバイスまたはラップトップデバイス、マルチプロセッサシステム、マイクロコントローラベースのシステム、セットトップボックス、プログラム可能な民生用電子機器、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータや、これらのシステムまたはデバイスのいずれかを含む分散コンピューティング環境などが含まれる。

本発明は、プログラムモジュールなど、コンピュータによって実行されるコンピュータ実行可能命令の一般的なコンテキストで述べることができる。一般にプログラムモジュールは、特定のタスクを実施するか特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。本発明は分散コンピューティング環境で実施することもでき、その場合、タスクは通信ネットワークを介してリンクされたリモート処理デバイスによって実施される。分散コンピューティング環境では、プログラムモジュールおよびその他のデータは、メモリ記憶デバイスを含めたローカルとリモートの両方のコンピュータ記憶媒体に位置することができる。

図１を参照すると、本発明を実施するための例示的なシステムは、コンピュータシステム１１０の形の汎用コンピューティングデバイスを含む。コンピュータ１１０のコンポーネントには、限定しないが処理ユニット１２０と、システムメモリ１３０と、システムメモリを含めた様々なシステムコンポーネントを処理ユニット１２０に結合するシステムバス１２１とを含めることができる。システムバス１２１は、様々なバスアーキテクチャのいずれかを用いた、メモリバスまたはメモリコントローラ、周辺バス、ローカルバスを含めて、いくつかのタイプのバス構造のいずれかとすることができる。限定ではなく例として、このようなアーキテクチャには、ＩＳＡ（Ｉｎｄｕｓｔｒｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＭＣＡ（Ｍｉｃｒｏ Ｃｈａｎｎｅｌ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＥＩＳＡ（Ｅｎｈａｎｃｅｄ ＩＳＡ）バス、ＶＥＳＡ（Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃｓ Ｓｔａｎｄａｒｄｓ Ａｓｓｏｃｉａｔｉｏｎ）ローカルバス、ＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ）バス（メザニンバスとも呼ばれる）が含まれる。

コンピュータ１１０は通常、様々なコンピュータ可読媒体を備える。コンピュータ可読媒体は、コンピュータ１１０からアクセスできる任意の利用可能な媒体とすることができ、揮発性と不揮発性の媒体、取外し可能と取外し不可能の媒体の両方が含まれる。限定ではなく例として、コンピュータ可読媒体には、コンピュータ記憶媒体および通信媒体を含めることができる。コンピュータ記憶媒体には、コンピュータ可読命令、データ構造、プログラムモジュール、またはその他のデータなどの情報を記憶するための任意の方法または技術で実現された、揮発性と不揮発性、取外し可能と取外し不可能の両方の媒体が含まれる。コンピュータ記憶媒体には、限定しないがＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたはその他のメモリ技術、ＣＤ−ＲＯＭ、ディジタル多用途ディスク（ＤＶＤ）またはその他の光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置またはその他の磁気記憶デバイスが含まれ、あるいは、所望の情報を記憶するのに使用できコンピュータ１１０からアクセスできるその他の任意の媒体が含まれる。通信媒体は通常、搬送波やその他のトランスポート機構などの変調されたデータ信号中に、コンピュータ可読命令、データ構造、プログラムモジュール、またはその他のデータを組み入れたものであり、任意の情報送達媒体が含まれる。「変調されたデータ信号」という語は、情報が信号中に符号化される形で１つまたは複数の特性が設定または変更された信号を意味する。限定ではなく例として、通信媒体には、配線式ネットワークや直接配線式接続などの配線式媒体と、音響、無線周波、赤外線、その他の無線媒体などの無線媒体とが含まれる。以上の任意の組合せもコンピュータ可読媒体の範囲に含めるべきである。

システムメモリ１３０は、読取り専用メモリ（ＲＯＭ）１３１やランダムアクセスメモリ（ＲＡＭ）１３２など、揮発性および／または不揮発性メモリの形のコンピュータ記憶媒体を含む。ＲＯＭ１３１には通常、起動中などにコンピュータ１１０内の要素間で情報を転送するのを助ける基本ルーチンを含むＢＩＯＳ（ｂａｓｉｃ ｉｎｐｕｔ／ｏｕｔｐｕｔ ｓｙｓｔｅｍ）１３３が記憶されている。ＲＡＭ１３２は通常、処理ユニット１２０がすぐにアクセス可能な、かつ／または処理ユニット１２０が現在作用している、データおよび／またはプログラムモジュールを含む。限定ではなく例として、図１には、オペレーティングシステム１３４、アプリケーションプログラム１３６、その他のプログラムモジュール１３７、プログラムデータ１３８を示す。

コンピュータ１１０は、その他の取外し可能／取外し不可能、揮発性／不揮発性コンピュータ記憶媒体を備えることもできる。例にすぎないが図１には、取外し不可能かつ不揮発性の磁気媒体に対して読み書きするハードディスクドライブ１４１と、取外し可能かつ不揮発性の磁気ディスク１５２に対して読み書きする磁気ディスクドライブ１５１と、ＣＤ ＲＯＭやその他の光媒体など取外し可能かつ不揮発性の光ディスク１５６に対して読み書きする光ディスクドライブ１５５を示す。この例示的な動作環境で使用できるその他の取外し可能／取外し不可能、揮発性／不揮発性コンピュータ記憶媒体には、限定しないが磁気テープカセット、フラッシュメモリカード、ディジタル多用途ディスク、ディジタルビデオテープ、固体ＲＡＭ、固体ＲＯＭなどが含まれる。ハードディスクドライブ１４１は通常、インタフェース１４０などの不揮発性メモリインタフェースを介してシステムバス１２１に接続され、磁気ディスクドライブ１５１および光ディスクドライブ１５５は通常、インタフェース１５０などの取外し可能メモリインタフェースでシステムバス１２１に接続される。

以上に論じ図１に示した各ドライブおよびそれらに関連するコンピュータ記憶媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、その他のデータの記憶域をコンピュータ１１０に提供する。例えば図１には、ハードディスクドライブ１４１がオペレーティングシステム１４４、アプリケーションプログラム１４５、その他のプログラムモジュール１４６、プログラムデータ１４７を記憶しているのが示されている。これらのコンポーネントは、オペレーティングシステム１３４、アプリケーションプログラム１３６、その他のプログラムモジュール１３７、プログラムデータ１３８と同じものとすることもでき、異なるものとすることもできることに留意されたい。ここでは、オペレーティングシステム１４４、アプリケーションプログラム１４５、その他のプログラムモジュール１４６、プログラムデータ１４７が少なくとも異なるコピーであることを示すために、異なる番号を付けてある。ユーザは、キーボード１６２、マウスやトラックボールやタッチパッドと一般に呼ばれるポインティングデバイス１６１などの入力デバイスを介して、コンピュータ１１０にコマンドおよび情報を入力することができる。その他の入力デバイス（図示せず）には、マイクロホン、ジョイスティック、ゲームパッド、衛星受信アンテナ、スキャナや、ハンドヘルドＰＣおよびその他の筆記タブレットのタッチセンシティブスクリーンなどを含めることができる。これらおよびその他の入力デバイスは、システムバスに結合されたユーザ入力インタフェース１６０を介して処理ユニット１２０に接続されることが多いが、パラレルポート、ゲームポート、ユニバーサルシリアルバス（ＵＳＢ）など、その他のインタフェースおよびバス構造で接続されてもよい。モニタ１９１または他のタイプの表示デバイスもまた、ビデオインタフェース１９０などのインタフェースを介してシステムバス１２１に接続される。モニタに加えて、コンピュータは通常、スピーカ１９５やプリンタ１９６など、その他の周辺出力デバイスも備えることができ、これらは出力周辺インタフェース１９４を介して接続することができる。

コンピュータ１１０は、リモートコンピュータ１８０など１つまたは複数のリモートコンピュータへの論理接続を用いて、ネットワーク化された環境で動作することができる。リモートコンピュータ１８０は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、またはその他の一般的なネットワークノードとすることができ、図１にはメモリ記憶デバイス１８１しか示していないが、通常はパーソナルコンピュータ１１０に関して上述した要素の多くまたはすべてを備える。図１に示す論理接続は、ローカルエリアネットワーク（ＬＡＮ）１７１およびワイドエリアネットワーク（ＷＡＮ）１７３を含むが、その他のネットワークを含むこともできる。このようなネットワーキング環境は、オフィス、企業全体のコンピュータネットワーク、イントラネット、インターネットでよくみられるものである。

コンピュータ１１０は、ＬＡＮネットワーキング環境で使用されるときは、ネットワークインタフェースまたはアダプタ１７０を介してＬＡＮ１７１に接続される。ＷＡＮネットワーキング環境で使用されるときは通常、インターネットなどのＷＡＮ１７３を介した通信を確立するためのモデム１７２またはその他の手段を備える。モデム１７２は内蔵でも外付けでもよく、ユーザ入力インタフェース１６０またはその他の適切な機構を介してシステムバス１２１に接続することができる。ネットワーク化された環境では、コンピュータ１１０に関して示したプログラムモジュールまたはその一部をリモートのメモリ記憶デバイスに記憶することができる。限定ではなく例として、図１には、リモートアプリケーションプログラム１８５がメモリデバイス１８１上にあるものとして示す。図示のネットワーク接続は例示的なものであり、コンピュータ間に通信リンクを確立する他の手段を使用することもできることは理解されるであろう。

（リソース複製による更新制御）
図２は、本発明の様々な態様による、リソースを複製する２つのマシンを含むリソース複製システムを表すブロック図である。マシン２０１と２０２は両方とも、リソースＡを複製し、これを同時に、コンテンツｘを有する状態からコンテンツｙ、ｕ、またはｚを有する状態に更新する。コンテンツｘ、ｙ、ｕ、ｚは、例えばリソースＡの異なるバージョンシーケンス番号およびクロックに対応するものとすることができる。

用語「マシン」は、単に物理マシンだけに限定しない。そうではなく、単一の物理マシンが複数の仮想マシンを含む場合もある。本明細書では、あるマシンから別のマシンへの複製は、同じ複製物セットの１つまたは複数のメンバを、ある仮想または物理マシンから別の仮想または物理マシンに複製することを意味する。単一の物理マシンが、同じ複製物セットの複数のメンバを含む場合もある。したがって、複製物セットのメンバを複製することは、同じ複製物セットの複数のメンバを含む単一の物理マシンのメンバ同士を同期させることを含む場合がある。

複製システムは通常、各リソースと共に、関係する２つのデータセット、すなわちリソースデータおよびリソースメタデータを維持することになる。ファイルシステム中の名前付きファイルに基づくデータ記憶域を含む複製システムでは、リソースデータは、ファイルコンテンツ、ならびに、ファイルコンテンツに関連してファイルシステムに記憶された任意のファイル属性を含むことができる。ファイル属性は、アクセス制御リスト（ＡＣＬ）、作成／修正時刻、および、ファイルに関連するその他のデータを含むことができる。ファイルシステム中の名前付きファイルに基づくデータ記憶域を含まない複製システム（例えばリソースがデータベースにまたはオブジェクトベースのデータ記憶域に記憶される複製システム）では、そのデータ記憶域にとって適切なリソースデータが記憶される。この文書全体を通して、例示のためにファイルシステム中のファイルに基づく複製システムをしばしば使用するが、本発明の趣旨または範囲を逸脱することなく、コンテンツを記憶できる任意のデータ記憶域を使用することができることを理解されたい。

リソースメタデータは、複製中に同期を交渉するのに関係する追加の属性のセットを含む。各リソースにつき、リソースメタデータは、グローバル一意識別子（ＧＵＩＤ）、リソースが削除されたかどうか、バージョンシーケンス番号、加えて変更の出所、変更が行われた時を反映するためのクロック値、その他のフィールドを含むことができる。その他のフィールドは、リソースデータの値を要約したものであってリソースコンテンツについての署名を含む場合もあるダイジェストなどである。ダイジェストは、例えば複製同期中にデータ転送をバイパスするためのクイック比較に使用することができる。宛先マシン上のリソースがソースマシン上のコンテンツと同期している場合（例えばダイジェストで示されるように）は、リソースデータ自体は送信せずにリソースメタデータだけを送信することによって、ネットワークオーバーヘッドを最小限に抑えることができる。リソースメタデータの送信は、ソースマシン上に含まれるメタデータを宛先マシンがその後続の複製動作で反映することができるように行われる。これにより、宛先マシンは、例えば後続の複製動作でソースマシンになることができる。リソースメタデータは、本発明の趣旨または範囲を逸脱することなく、リソースデータと共にまたは別々に記憶することができる。

一般に、ワイドエリア分散システムでは、クロック同期を非常に細分性の高いレベルで想定することは実現可能ではない。このため、複製システムは、大域的なクロックを使用して同時の更新および作成の勝者を決定することはできない。レプリケータは通常、配信されたコンテンツのメタデータにスタンプされた論理分散クロックを使用する。論理クロックは、変更時刻の物理ローカルクロックによって上書きされるのとは異なり、コンテンツが更新されるときにインクリメントされる。したがって、論理クロックは因果関係を考慮し、同じコンテンツの更新には、増加していくクロック値がスタンプされる。例えば、図２のクロック値Ａ：ｘを「４」とする。この場合、複製システムは、Ａ：ｙおよびＡ：ｚに関連するクロック値が４よりも大きくなるようにする。これらのクロック値の間の関係は任意である。これらの値は独立して割り当てられるので（例えばマシン２０１はＡ：ｙのクロック値を割り当て、マシン２０２はＡ：ｚのクロック値を割り当てる）、同一である場合もそうでない場合もある。

通常の複製同期では、クロック値を使用して、最後に書いた者勝ち（ｌａｓｔ−ｗｒｉｔｅｒ−ｗｉｎｓ）の競合解決戦略に基づいて競合の勝者を決定することができる。最大のクロック値を有するデータが、より小さいクロック値を有する複製データよりも最近のデータを示すことができる。論理クロックは因果関係を維持するので、最後に書いた者勝ちの戦略は、因果関係と整合する。

本発明の一態様によれば、リソースメタデータは「フェンス値」と呼ばれる数値フィールドで増強される。フェンス値は、各リソースまたはその一部に割り当てることができる。フェンス値は、以下に定義する規則のセットに従って、競合解決中に他のメタデータと共に使用される。

本発明の一実施形態では、規則によれば、フェンス値が０と１のどちらかに初期化される。０の値は、リソースを（複製機構を介して）別のマシンに送信すべきではなく、また別のマシンから見える状態にもすべきではないことを示す。１の値は、リソースを複製して他のマシンから見える状態にすることができることを示す。０のフェンス値を有するリソースはスレーブリソースと考えることができ、１のフェンス値を有するリソースはマスタリソースと考えることができる。

２つのマシン間での複製動作中に、一方のマシン（例えばマシン２０１）上のリソース（例えばリソースＡ）が他方のマシン（例えばマシン２０２）上の同じリソースよりも大きいフェンス値を有する場合、フェンス値が大きい方のリソースが、フェンス値が小さい方のリソースを有するマシンに複製される。言い換えれば、他にどんなリソースメタデータがあるかにかかわらず、フェンス値が大きい方のリソースが勝つ（そして複製される）。

２つのマシン上にすでにあるが異なるリソースを複製する際は、できるだけ少ないデータを伝搬してリソースを同期させることを試みる機構を利用することができる。例えば、リソースに関連するすべてのデータを送信する代わりに、この複製機構は、送信側マシン上にあるリソース中のどのデータが受信側マシン上にあるリソース中のデータと異なるかを決定し、１つまたは複数の差分またはデルタを送信して、受信側マシン上のリソースを更新することができる。

複製動作中に、フェンス値が同じであり０よりも大きい場合は、どちらのリソースが勝つか（そして複製されるか）は、各リソースに関連する他のリソースメタデータによって決まる。言い換えれば、フェンス値が同じのときは、複製は、複製に関連する通常の規則に従って進められる。

したがってフェンス値は、競合解決において優先されるので、競合解決プロセスに対する細粒度の制御をもたらす。すなわち、２つのリソースのメタデータを比較したとき、フェンス値が大きい方のリソースが優先される。論理クロックなど他の属性は、フェンスが等しいときだけ比較される。

フェンス値は、論理クロックと同様のプロパティを有するものとすることができ、一実装形態では、インクリメントされるか０にリセットされることができるだけである。例えばフェンス値は、ユーザまたはプロセスが複製システムにインクリメントするよう指示したときに、インクリメントすることができる。これは、「リソースをフェンシングする」または単に「フェンシング」と言われることがある。フェンス値のインクリメントは、リソースデータの更新から独立している。フェンスインクリメントは、複製によって見える状態になる（例えばメタデータ中で送信される）。フェンシングは頻繁に行われる動作ではないので、ウォールクロック時間の整数表現を用いて、フェンスを最大値（現在のフェンス値＋１）および（現在のウォールクロック時間）にインクリメントすることができる。

フェンス値は、ユーザまたはプロセスが複製システムにリセットするよう指示したときに、０にリセットすることができる。これは、「リソースをフェンシング解除する」または単に「フェンシング解除」と言われることがある。フェンシング解除された（すなわちそのフェンス値が０にリセットされた）スレーブモードのリソースは、それらのリソースを保持するマシンの外部にある他のどんなマシンへも複製されないものとすることができる。これにより、スレーブモードのリソースは外部から見えなくなる。したがって、フェンス値のリセットは複製によって見えるようにはならない。

フェンシングおよびフェンシング解除を除いては、フェンス値は複製中に一定のままである。具体的には、正のフェンス値は、リソースデータが更新されたときでも論理クロックが変化したときでも変化しない。０の値のフェンス値もまた、スレーブマシンでのコンテンツ更新時でも変化しないはずである。

１つのマシン上でリソースをフェンシングすることにより、複製物セットの他のメンバに対する同時のリソース更新に関係なく、このリソースが複製されるようにすることができることが理解されるであろう。また、リソースをフェンシング解除することにより、複製された他のどんなリソースも、ローカルの（フェンシング解除された）リソースよりも優先されるようにすることができ、フェンシング解除されたこのリソースは外部に複製されないようになることが理解されるであろう。

フェンスは、選択されたリソースをフェンシングする複製システムアプリケーションプログラミングインタフェース（ＡＰＩ）を介して、既存のリソースに対して設定することができる。さらに、フェンスは、特定のパラメータ（リソース名や属性など）に合致するリソースが複製システムから見えるようになったときにこれらのリソースをフェンシングするＡＰＩを公開することによって、将来のリソースに対して設定することもできる。将来のフェンシングおよびフェンシング解除の制御はまた、スティッキネス（ｓｔｉｃｋｉｎｅｓｓ）を指定することによって提供することもでき、フェンシング／フェンシング解除されたディレクトリの下にあるリソースなど間接的に関係するリソースを生成する場合、親に対して設定されたポリシーセットに基づくフェンシング値を継承することができる。

フェンシング解除はまた、複製パートナーのマスタ挙動またはスレーブ挙動を制御するための細分性のある方法も提供する。選択されたリソースに対して効果的にフェンスを設定することにより、マシンは、そのバージョンのコンテンツのマスタになる（コンテンツが最初に更新されるまで）。選択されたリソースをフェンシング解除することにより、マシンは、選択されたリソースに関連するコンテンツについてスレーブとして挙動する。

フェンシングおよびフェンシング解除は、バックアップ復元、帯域外複製、より新しいバージョンのレプリケータへのアップグレード、管理者制御の提供を含めて、いくつかの領域で使用することができることは理解されるであろう。

スレーブ上でローカルに更新されるリソースの場合、フェンシング解除された（例えばフェンス値０の）リソースを含むマシンは、フェンシング解除されたリソースフェンス値を、フェンシングされたリソース値（例えば１）に変更することを選択することができる。これは例えば、更新を見えるようにするために行うことができる。

図３は、本発明の様々な態様による、２つのマシンがその両方に含むリソースを一致させようとしているシステムを表すブロック図である。図３では、各マシンはそれ自体のバージョンのリソースを有し、リソースは同じ名前または識別子を有する。調停の最後に、複製されたリソースがｘとｙのどちらかのコンテンツを有するようにすることが目標である。図３に示すシステムでは、マシン３０１のコンテンツｘが、マシン３０２のコンテンツｙに勝つ。これは例えば、マシン３０１上にあるリソースＡのフェンス値の方が高い場合に、または他のリソースメタデータの比較によって生じる場合がある。

図４に、本発明の様々な態様による、図２および３のＡ：ｘに使用することのできる例示的ないくらかのリソースデータおよびメタデータを示す。リソースメタデータは、１のフェンス値、クロック値、ＧＵＩＤ、変更を生み出した複製メンバ、ダイジェストを含む。リソースデータは、リソースの名前、データ自体、作成時刻、修正時刻、および、リソースデータのその他の属性を含む。

図５に、図３に示した同期に関係する、本発明の様々な態様により使用することのできる例示的ないくらかのリソースデータおよびメタデータを示す。ｘに関連するリソースのフェンス値（すなわち１０５６６０３３５９）の方が、ｙに関連するリソースのフェンス値（すなわち１）よりも大きいので、マシン５０１上のコンテンツ（例えばｘ）がマシン５０２上のコンテンツ（例えばｙ）に勝ち、したがってマシン５０２に複製されることになる。従来の複製方法では、ｙの更新クロック時刻の方が大きいためｙがｘに勝つことになることに留意されたい。

図６は、本発明の様々な態様による、２つのマシン間でリソースを同期させるために実施することのできる例示的なステップを一般に表すデータフロー図である。プロセスはブロック６０５で開始する。

ブロック６１０で、リソースを伝搬すべきであることを少なくとも１つのフェンス値が示しているかどうかを決定する。フェンス値が両方ともフェンシング解除の状態（例えば０）に設定されている場合もある。この場合はリソースを伝搬すべきではない。フェンス値の１つが、フェンシングされた値（例えば１またはそれ以上）に設定されている場合は、２つのリソースを同期させるために必要ならリソースを伝搬すべきである。

ブロック６１５で、リソースを伝搬すべきである場合、処理はブロック６２０に分岐する。そうでない場合は、処理はブロック６３５に分岐する。ブロック６２０で、フェンス値が等しいかどうかを決定する。等しい場合は、処理はブロック６２５に分岐し、他のメタデータを使用して、リソースをどのように伝搬するかを決定する。ブロック６２７で、リソースまたはその一部（例えばメタデータ、フェンス値、コンテンツの差分など）を、ブロック６２５で決定されたマシンから伝搬する。

ブロック６２０でフェンス値が等しくない場合は、処理はブロック６３０に分岐する。ブロック６３０で、リソースまたはその一部（例えばメタデータ、フェンス値、コンテンツの差分など）を、リソースのフェンス値が高い方のマシンから、リソースのフェンス値が低い方のマシンに伝搬する。ブロック６３５で処理は終了する。

以下は、本発明の態様を用いることのできる例示的ないくつかのシナリオである。

権限のないバックアップ復元：データが破損または紛失したとき、複製されたリソースシステムのメンバを管理するユーザは、メンバを消去して、リソース複製システムを介してメンバに関連するすべてのデータを得ることを求める場合がある。メンバが、メンバをリソース複製システムに接続するリンクの帯域幅に対して相対的に大きいときは、この動作過程は、時間またはコストがかかりすぎることがある。しかし、本発明の一態様を用いると、ユーザはメンバのリソースをバックアップから復元することができる。次いでユーザは、バックアップの中のリソースをフェンシング解除して（例えばフェンス値を０に設定して）、リソース複製システムが古いリソースを更新できるようにすることができる。この場合、復元されたコンテンツはちょうど「コンテンツキャッシュ」として働き、適切なロジックがあれば、レプリケータはこのコンテンツキャッシュを使用して、コンテンツが低速リンクを介して（例えば「ワイヤを介して」）転送されるのを回避することができ、それにより、バックアップ復元に続く最初の同期トラフィックを、更新を必要とするメタデータおよびリソースデータだけに限定されるように維持することができる。同期後、フェンス値０を有する残りのリソースがあれば、それらは削除するか、それらのフェンス値を１に設定して複製可能にすることができる。

帯域外コピー：複製物セットの新しいメンバが、多量のデータを潜在的に含む場合がある。より高速かつ／またはより安価な転送を容易にするために、新しいメンバを、ユーザにとってよりコストの低いチャネルおよび／またはより高速なサービスを有するチャネルを介して送信することができる。例えば、新しいメンバをハードディスクにコピーするか、あるいはＣＤ−ＲＯＭまたはＤＶＤ−ＲＯＭに焼いて、翌日配達で出荷することができる。新しいメンバをリモート位置のシステムにコピーするとき、権限のないバックアップ復元に関して上述したようにこれらをフェンシング解除することができる。新しいメンバのフェンシング解除は、リモート位置にコピーされたコンテンツが他の位置に転送されないようにするために行われる。

権限のあるバックアップ復元：ユーザは、バックアップから復元して、復元されたコンテンツを複製されたリソースシステム中のすべてのシステムに伝搬したいと思う場合がある。こうするには、ユーザは、リソースをシステムに復元し、次いで、伝搬したいと思うリソースをフェンシングすることができる。

特例シナリオ：ユーザは、特定のバージョンのリソースセットを複製させて、これを複製物セット中の他のどんな競合コンテンツよりも優先させたいと思う場合がある。これは、リソースセットをフェンシングすることによって行うことができる。

初期同期：初期同期は、帯域外コピーの特別なケースである。複製されたシステムをセットアップまたはアップグレードする際、ユーザは、あるマシンをマスタ（すなわち他のマシンに複製されるコンテンツを含む）として指定し、他のマシンをスレーブ（すなわちマスタからコンテンツを受け取る）として指定する場合がある。こうするには、ユーザは、マスタ上のリソースが初期フェンス値１を有するようにフェンシングし、スレーブ上の既存のリソースをフェンス値０でフェンシング解除することができる。この初期化の後にスレーブ上に存在するようになったリソースは、複製されるように１でフェンシングすることができる。フェンシング解除されたスレーブリソースは複製されないので、このようなリソースがマスタからの名前競合リソースに負けたとき、このリソースに関する追加のメタデータを同期させる必要はない。

図７は、本発明の様々な態様による、権限のないバックアップ復元を行うために実施することのできる例示的なステップを一般に表すデータフロー図である。メンバ中のデータが、削除されるか破損する（ブロック７１０）。管理者は、バックアップから復元する（ブロック７１５）。管理者は、復元したデータにフェンシング解除の印を付ける（ブロック７２０）。ブロック７２５に表すように、同期がとられる。管理者は、残りのリソースを削除するかフェンス値１で印を付け（ブロック７３０）、処理は終了する（ブロック７３５）。

図７は、前述の権限のないバックアップで実施することのできるステップの一例として提供したものである。前述の他の適用例についても、容易にデータフロー図に還元できるほど十分に詳細に述べたことは理解されるであろう。また、本発明の趣旨または範囲を逸脱することなく、図７のステップまたは前述の適用例に対してその他多くの変形を行うことができることも理解されるであろう。

図８は、本発明の様々な態様による、リソース複製システムで動作するように構成されたマシンを表すブロック図である。マシン８０５は、更新機構８１０、リソース８２２、通信機構８４０を備える。

更新機構８１０はフェンス比較器ロジック８１５を備え、このフェンス比較器ロジック８１５は、フェンス値を比較して、リソースをマシン８０５から伝搬すべきかどうか、またリソースを他のマシンから見えるようにもすべきかどうかを決定するのに使用される。フェンス比較器ロジック８１５はまた、フェンシング動作の場合に、あるいはリソースメタデータ８３０の破損または削除とそれに続く再構築の場合（後でさらに詳細に述べる）に、フェンス値をどのように更新すべきかを決定するのにも使用することができる。

他のメタデータの競合解決ロジック８２０は、リソースのフェンス値同士が同等である場合にどのリソースが勝つか（そして伝搬されるべきか）を決定するのに使用されるロジックを含む。他のメタデータの競合解決ロジック８２０が適用される際、更新機構８１０は、リソースメタデータ８３０および／またはリソースデータ８２５中のデータにアクセスして、リソース（またはその一部）を別のマシンに伝搬すべきか、別のマシンから受け取るべきかを決定することができる。

リソース８２２は、リソースデータ８２５およびリソースメタデータ８３０を含む。リソースデータとリソースメタデータとの区別は、図２に関して上述した。これらは同じボックス中に示してあるが、リソースデータ８２５は、リソースメタデータ８３０とは別の記憶域に記憶されてもよい。

通信機構８４０は、更新機構８１０が他のマシン上にある他の更新機構（図示せず）と通信できるようにするものである。これと共に、更新機構は、どのリソースを同期させるべきか、またどのように同期をとることができるかを決定する。通信機構８４０は、図１に関して述べたネットワークインタフェースまたはアダプタ１７０、モデム１７２、あるいは通信を確立するためのその他任意の手段とすることができる。

本発明の趣旨または範囲を逸脱することなく、図８に示すマシンのその他の変形も実施することができることは理解されるであろう。

本発明の一実施形態では、−１、０、１の３つの初期フェンス値がある。−１は、前述の０（すなわちフェンシング解除された値）の役割をし、０は、１以上のフェンス値を有するリソースが他にない限りこのリソースが複製できることを示すことができる。この拡張の有用性の１つは、複製メタデータの紛失に対処することにある。例えば、リソースレプリケータは、メタデータを、リソースデータを記憶するのに使用される記憶域とは別の記憶域に保持する。したがって、メタデータとリソースデータ（すなわちコンテンツ）に、独立して障害が発生する。再構築中、そのメタデータを失ったマシンは、そのリソースがすでに複製されたものか単にローカルに生成された（したがって複製物セット中で他のマシンに知られていない）ものかわからないため、最初にそのリソースを値−１でフェンシングすることができる。フェンス値を−１から１に変更するのが早すぎると、より新しいが切断されているマシンからのコンテンツが上書きされる場合があるので、古くなったコンテンツが再びネットワーク中に導入されるという影響がある可能性がある。一方、フェンスを−１から０に変更すれば、そのようなコンテンツは、古くなっていると他の参加者の誰かが決定できる時点まで、再び導入することができる。正の整数だけが望まれる場合は、前述の各値をずらして０、１、２（または他の何らかの番号付け方式）を代わりに使用してもよいことに留意されたい。

本発明の別の実施形態では、可能な初期フェンス値として−８および０を使用する。機能的には、フェンス値−８は０に取って代わり（すなわちフェンシング解除された値であり）、０は１に取って代わる（すなわちリソースを複製すべきであることを示す）。さらに、その他の負のフェンス値（例えば−１、−２、−３、．．．−ｎ）を使用して、複製できるリソースを示すこともできる。このようなフェンス値は、より大きい値でフェンシングされたリソースに負けることになる。この一般化の有用性には、新鮮なリソースが利用可能であることの方が復元中の帯域幅使用よりも重要である場合のシナリオが含まれる。マシンにはそれぞれ、最初のリソースに対して使用される異なるフェンス値（例えば−１、−２、．．．、−ｎ）を割り当てることができる。この順序付けでは、フェンス−１を使用するリーダーマシンが優先されるが、すべてのマシンからの競合しないコンテンツはすぐに利用可能である。

この表現の別の適用例には、メタデータの破損または紛失に応答してマシンが回復するたびに、またはそのメタデータを再構築するたびに、フェンス値をデクリメントすることが含まれる。この適用例のヒューリスティックな価値の１つは、マシンがそのメタデータを再構築するたびに、マシン上に記憶されたリソースデータはだんだん信頼性が低くなっていく、かつ／または古くなっていく可能性が高いことである。この機構を介した場合、そのメタデータを再構築する頻度がより低いマシン上のコンテンツは、より信頼性が高いと考えられ、そのメタデータを再構築する頻度がより高いマシン上のコンテンツにフェンス値によって勝つ。

前述のフェンス値は、任意の様々な物理フェンス値で実現することのできる論理フェンス値であることは理解されるであろう。例えば、本発明の趣旨または範囲を逸脱することなく、フェンス値は、符号なし整数、浮動小数点数、ビット値、またはその他任意のタイプの番号付け方式として物理的に表すことができる。

以上の詳細な説明からわかるように、情報複製に対して細分性のある制御を行うための改良された方法およびシステムが提供される。本発明は様々な修正および代替構造が可能だが、そのいくつかの例示的な実施形態について図面に示し、以上に詳細に述べた。ただし、開示した特定の形に本発明を限定する意図はなく、反対に、本発明の趣旨および範囲に含まれるすべての修正、代替構造、均等物をカバーするものとすることを理解されたい。

本発明を組み込むことのできるコンピュータシステムを表すブロック図である。 本発明の様々な態様による、リソースを複製する２つのマシンを含むリソース複製システムを表すブロック図である。 本発明の様々な態様による、２つのマシンがその両方に含むリソースを一致させようとしているシステムを表すブロック図である。 本発明の様々な態様による、図２および３のマシンに使用することのできる例示的ないくらかのリソースデータおよびメタデータを示す図である。 本発明の様々な態様により使用することのできる例示的ないくらかのリソースデータおよびメタデータを示す図である。 本発明の様々な態様による、２つのマシン間でリソースを同期させるために実施することのできる例示的なステップを一般に表すデータフロー図である。 本発明の様々な態様による、権限のないバックアップを行うために実施することのできる例示的なステップを一般に表すデータフロー図である。 本発明の様々な態様による、リソース複製システムで動作するように構成された例示的なマシンを表すブロック図である。

符号の説明

１２０ 処理ユニット
１２１ システムバス
１３０ システムメモリ
１３４ オペレーティングシステム
１３５ ファイルシステム
１３６ アプリケーションプログラム
１３７ その他のプログラムモジュール
１３８ プログラムデータ
１４０ 取外し不可能な不揮発性メモリインタフェース
１４４ オペレーティングシステム
１４５ アプリケーションプログラム
１４６ その他のプログラムモジュール
１４７ プログラムデータ
１５０ 取外し可能な不揮発性メモリインタフェース
１６０ ユーザ入力インタフェース
１６１ マウス
１６２ キーボード
１６３ マイク
１６４ タブレット
１７０ ネットワークインタフェース
１７１ ローカルエリアネットワーク
１７２ モデム
１７３ ワイドエリアネットワーク
１８０ リモートコンピュータ
１８５ リモートアプリケーションプログラム
１９０ ビデオインタフェース
１９１ モニタ
１９４ 出力周辺インタフェース
１９５ スピーカ
１９６ プリンタ

Claims (33)

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. 前記第１のリソースセットの前記フェンス値は、他のマシン上の対応するリソースよりも優先されるように印が付けられ、したがって、前記対応するリソースは前記第１のリソースセットから更新されることを特徴とする請求項３１に記載のシステム。
    
    

Images