JP2022503583A - 分散コンピューティング環境で分散調整エンジンを非破壊的にアップグレードする方法、装置およびシステム - Google Patents

Abstract

複数のサーバノードでクライアントアプリケーションの一貫性を維持するコンピュータ実装方法および分散システムが、第１バージョンおよび第２バージョンの分散調整エンジン（ＤＣｏｎＥ）を提供することを含んでいてよい。第１バージョンのＤＣｏｎＥは、提案を受け取り、それについて合意に達し、クライアントアプリケーションが合意済みの提案を実行してそれに応じてそのそれぞれの状態を更新する順序を指定する第１の順序の合意を生成してよい。次に、第１バージョンのＤＣｏｎＥでバージョン変更提案を処理してよく、次いで第１バージョンのＤＣｏｎＥは、それ以上合意に達するのを停止してよい。次に、第２バージョンのＤＣｏｎＥが提案について合意に達することを引き継ぎ、合意済みのバージョン変更提案から始まる第２の順序の合意を生成してよい。合意済みのバージョン変更提案の後に第１バージョンのＤＣｏｎＥから受け取った合意済みの提案を、第２バージョンのＤＣｏｎＥに送り返して、第２バージョンのＤＣｏｎＥがそれについて合意に達することができるようにしてよい。

Description

本明細書に開示する実施形態の分野は、分散システムを含む。特に、実施形態は、提案を受け入れ、アプリケーションによって消費される対応する順序付けされた合意を生成するためにワイドエリアネットワーク（ＷＡＮ）を介した分散調整エンジンのインスタンスを使用する分散システム（および同システムによって可能になる機能）に及ぶ。ただし、分散調整エンジンは、分散調整エンジンが合意を生成しているアプリケーションを途絶したり、提案および合意の流れを中断したりすることなく、時折アップグレードしなければならない。

１つの実施形態に従って構成したシステムのブロック図である。

１つの実施形態による提案の図である。

１つの実施形態による、フォーマットされ、かつ／または入力キューに格納されたクライアント提案の図である。

１つの実施形態による、フォーマットされ、かつ／または出力キューに格納された合意済みの提案（例えば合意）を示す図である。

１つの実施形態による分散システムを示し、そのような分散システムでクライアントアプリケーションの一貫性を維持するコンピュータ実装方法の様々な態様を示すブロック図である。

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

本明細書に図示し説明した実施形態を実施し得るコンピューティングデバイスのブロック図である。

定義
分散システム：分散システムは、別々のプロセスの集合を含んでおり、プロセスは、空間的に離れていてよく、メッセージまたはイベントの交換を通して互いに通信してよい。

複製状態マシン：複製状態マシンの手法とは、サーバを複製してクライアントとサーバレプリカとの相互作用を調整することによってフォールトトレラントサービスを実装する方法である。状態マシンの状態は学習者全員で同じように進展するため、これらの状態マシンは「複製」される。単一サーバのレプリカを分散システムの別々のプロセッサで実行し、プロトコルを使用してクライアントとこれらのレプリカとの相互作用を調整する。複製状態マシンの１つの例および実装形態が、その状態を決定論的な方法で消費する決定論的な状態マシンである。

合意：合意とは、提案者が生成して学習者に配信された潜在的な複数の提案イベントのうちの選択された１つである。

合意のグローバルシーケンス：１つの実施形態によれば、クライアント提案は、少なくとも大多数の承認者に送信され、合意され、合意のグローバルシーケンスに配信される。合意のグローバルシーケンスを受け取るサーバノードおよびクライアントアプリケーションは、次に、基礎となるトランザクションを合意のグローバルシーケンスが指定した順序で実行し、それに応じて状態を更新してよく、それによってすべてのクライアントアプリケーションが同じ順序で更新されるのを確実にする。

分散合意／調整エンジン（ＤＣｏｎＥ）：１つの実施形態では、パクソスコンセンサスプロトコルの新規の生産グレードの実装を通じて、順序付けされた合意トランザクションのグローバルシーケンスを生成するために合意または調整エンジンを必要とする。例示的なＤＣｏｎＥが、同一出願人による、同時係属中である２００８年２月１３日出願の米国特許出願第１２／０６９，９８６号に記載されており、同文献の全容を参照して本願に援用する。ＤＣｏｎＥは、フォールトトレラントであり、継続的に使用できる決定論的な複製状態マシンである。ＤＣｏｎＥは、提案者が生成したイベントを収集し、それを編成して承認者の助けを借りて順序付けしたグローバルシーケンスにして、それをそのシーケンスで学習者に配信することによって動作する。学習者は、配信されたイベントの順序付けされたシーケンスを扱ってビジネスロジックを実装する（例えばトランザクションを実装する）。ＤＣｏｎＥは、合意済みの提案の同じ順序のグローバルシーケンスで、それぞれのトランザクション提案イベントを少なくとも一回各学習者ノードに配信することを保証する。

非ブロッキング：本明細書では、「非ブロッキング」という用語は、一連の処理を完全または部分的に可能にしておくと同時にその一連の処理に変化を加える能力を指す。

提案者：１つの実施形態によれば、提案者は、トランザクション（アプリケーション、データセットなどの状態を変化させるための提案）を提示するように構成されそれを可能にするプロセスである。

承認者：１つの実施形態によれば、承認者は、提案者が出す提案の順序を決定することに加担するように構成されているプロセスである。１つの実施形態によれば、ある提案が合意のグローバルシーケンスで特定の場所を取ることを大多数の承認者が決定した場合のみ、それが合意となる（例えば合意済みの提案）。承認者は、１つの実施形態によれば、合意の順序の決定だけに加担するように構成されてよく、合意の基本的内容を推論しない／関心を持たない（本明細書に記載したように、合意の値はＤＣｏｎＥには不透明である）。承認者は、アプリケーションに無関係のエンティティとして構成されてよい。

学習者：１つの実施形態によれば、学習者は、提案者と承認者との間でなされた合意を学習し、その出力提案シーケンスを通じて、合意を決定論的な順序でアプリケーションに適用する。１つの実施形態では、複製状態マシンごとに一連の合意を永続的に記録できる永続ストアと同じように、合意のＩＤが提供される。各々の提案は、特定のメンバーシップの各学習者に少なくとも一回配信されることが保証されている。
分散調整エンジン（ＤＣｏｎＥ）

１つの実施形態によれば、ＤＣｏｎＥは、高性能のエンタープライズ版パクソスアルゴリズムを実装する。パクソスアルゴリズムでは、複製状態マシンが分散システムの各ノードとともにインストールされる。次に複製状態マシンは、各ノードでのトランザクション順序を同じにする（同時である必要はない）トランザクション管理を交換する協調的手法を配信するためのピアとして機能する。パクソスアルゴリズムを実装しているサーバノードで複製された状態マシンは、３つの役割：（１）提案者；（２）承認者；および（３）学習者のいずれか１つを満たすことができる。パクソスアルゴリズムには次の３つの段階があり、コンセンサスに達するプロセスで繰り返されてよい。（１）ノードを調整者または提案者として選出する。（２）トランザクションの提案をピアにブロードキャストし、次にピアは、提案を受け入れるか拒否する学習者の役割を引き受ける。そして（３）承認。大多数のノードが提案者を認めてその提案を承認すると、コンセンサスに達することができる。調整者の役割を引き受けた複製状態マシンは、次にコミットメッセージをブロードキャストしてすべてのピアにトランザクションを続行するよう通知する。

同じ提案に対して複数のノードが調整者として機能しようとするシナリオを避けるため、パクソスは、連続する調整者のノードに順序を割り当て、提案番号に関して合意される値を選択する際に各調整者の選択を制限する。これをサポートするために、各ノードは、ノードが確認した最も直近に合意した提案のシーケンス番号の形跡を維持する。ノードが提案を出すとき、ノードは、認識している最後の値よりも高い値を持つ提案のシーケンス番号を生成し、それを他のノードにブロードキャストする。他のノードの大多数が、それよりも高いシーケンス番号を確認していないことを示す応答をした場合、ノードは、提案の調整者または先導者として機能することを許可される。その時点で、他の調整者は、現在の提案に関してコンセンサスに達するまで続行できない。提案者のシーケンス番号は、同時に調整者になろうとする他のノードに使用されることはなく、それ以降の提案はすべて、それ以降のトランザクションについてコンセンサスに達するためにはそれよりも高いシーケンス番号を使用しなければならない。
ＤＣｏｎＥとのコンセンサスの達成

分散されたトランザクション処理に対するＤＣｏｎＥの手法を理解するために、以下に、アクティブ－アクティブ構成の複製能力をサポートする各ＤＣｏｎＥのインスタンスの中核構成要素、すなわち提案マネージャ、ローカルシーケンサ、合意マネージャ、およびグローバルシーケンサについて詳述する。任意のノードのクライアントで処理するために分散システムに提案が送信されると、ＤＣｏｎＥのローカルインスタンスの提案マネージャ構成要素は、トランザクションに対する提案を生成し、この提案はトランザクションデータを含む。このようなトランザクションデータは、少なくともクライアントのＩＤおよび提案された変更を含んでいてよい。次にＤＣｏｎＥインスタンスは、その提案にローカルシーケンス番号（ＬＳＮ）を割り当てる。ＬＳＮは、その場所にある他のすべてのトランザクションと比較してトランザクションが送信された順序を反映している。ＬＳＮは、連続番号である必要はなく、単に一意である必要がある。次にローカルシーケンサは、割り当てられたローカルシーケンス番号の付いた提案をその提案ログに保存する。以下に説明する合意プロセス中にＤＣｏｎＥのローカルインスタンスが提案をピアに送信できるようになる前にネットワークまたはサーバの停止が起きた場合、回復後にその提案を再送信する。

次に、ＤＣｏｎＥの合意マネージャが合意番号を決定し、合意番号は、ローカルＤＣｏｎＥインスタンスが他のノードのピアに送信するという提案に対して提案されたグローバルシーケンス番号（ＧＳＮ）を表している。パクソスに従えば、合意番号は単に、全ノードに承認された最後の提案のＧＳＮの増分である。次にこの合意番号を使用して、全ノードにわたる提案順序に関してコンセンサスを取得し、単一コピー等価を維持するようにする。次に、合意番号の付いた提案は、合意ログに書き込まれてよい。各々のＤＣｏｎＥインスタンスの合意ログまたは複製された台帳は、少なくとも完了した合意をすべて含み、完了した合意が生じたサーバノードとは無関係である。ネットワークが停止した場合、合意ログは、ノードが分散システム内の他のノードへの接続を失う前にどこで中断したかを示し、それをＤＣｏｎＥの自動回復プロセスで役立てる。

次に、ローカルＤＣｏｎＥインスタンスの合意マネージャによって合意プロトコルを開始してよく、提案は、そのピアに送信されてよい。ＤＣｏｎＥインスタンスのピアのクォーラムが提案について合意に達すると、グローバルトランザクションの順序がその時点で達成されているため、合意番号は全ノードにわたるＧＳＮとして使用される。クォーラムの概念により、全ノードが使用可能になるか合意することを必要とせずに、ＤＣｏｎＥが合意に達することが可能になる。クォーラムの概念は、ＤＣｏｎＥのパフォーマンスおよびそのフォールトトレランスに重要な要素である。

合意が競合する提案に先取りされた場合、合意マネージャは、新たな合意番号を用いて合意に達するよう繰り返し試みる。合意が再試行されるたびに、合意ログに新たな合意番号のエントリが作成される。クォーラムによって合意に達すると、ローカルアプリケーションノードは、合意された提案をそのグローバルシーケンスにエンキューする。その時点でローカルＤＣｏｎＥインスタンスは、トランザクションを合意されたグローバルシーケンス番号の順序でそれぞれのロックスケジューラに渡して処理する。提案を発信したＤＣｏｎＥインスタンスは、トランザクションの実行を完了するために他のノードを待つことはないことに注意することが重要である。ＤＣｏｎＥインスタンスは、合意に達するのを待って、ユーザがＷＡＮを介してＬＡＮ速度のパフォーマンスを経験できるようにするだけである。
ローカルシーケンスの維持

ＤＣｏｎＥは、パフォーマンスの理由から同時の合意をサポートするため、クォーラムが順不同で合意に達する可能性がある。つまり、別のノードで事前に送信されたがまだ合意されていない提案の後に送信された提案について合意に達する可能性がある。

ＤＣｏｎＥは、複数のサーバノードから提案を受け取り、その提案を一意のグローバル順序に照合し、他の１つひとつのサーバノードにアクセスできるようにすることを想起されたい。ＤＣｏｎＥ上に構築されたアプリケーションのことも検討されたい。場合によっては、特定のサーバノードでは、先着順または先入れ先出し（ＦＩＦＯ）を実装し、到着時間に基づいて提案を処理し、提案が同じ順序で出力されることを確実にすることが望ましいことがある。この種の順序付けは、例えば公平性ポリシーまたは因果的順序付けの制約によって命令されてよく、この制約は、１つの実施形態によれば、複数のサーバノードが発行した提案をすべて取得してそのすべてに関してコンセンサスに達することによって満たされる２つの要件である。いかなる後処理も決定論的な方法で実行される。ＤＣｏｎＥから生じる出力は、ＤＣｏｎＥのプロパティであるサーバノード全体で同一であるため、後処理工程から生じる出力は、全サーバノードで同一の合意シーケンスになり、そのためサーバノードは、アプリケーション全体で一貫性を維持するためにＧＳＮで命令された順序で消費される。

以下は、提案の送信のローカルシーケンスを維持しつつＤＣｏｎＥがグローバルトランザクションの順序を決定することを可能にする１つの実施形態を示している。サーバノードが最初の２つの提案をＤＣｏｎＥに送信し、提案マネージャがそれぞれの提案にＬＳＮ１およびＬＳＮ２を割り当てると仮定する。さらに、ＧＳＮが１から２５である合計２５の提案が合意されていて、他のサーバノードから介入の提案が送信されていないと仮定する。さらに、クォーラムはＬＳＮ１に関して合意に達する前にＬＳＮ２に関して合意に達したと仮定する。ローカルシーケンスがアプリケーションにとって重要ではなかった場合、ＬＳＮ２は合意番号およびＧＳＮ２６を有し、ＬＳＮ１は合意番号およびＧＳＮ２７を有することになる。すると提案は、どのサーバノードでもその順序で書き込まれる。提案が生じた場所に関係なくローカルシーケンスをすべてのノードで維持するようにすることが要件である場合、１つの実施形態では、ＬＳＮと、合意番号（この場合、ＧＳＮになる場合とならない場合がある）と、提案者のＩＤ（提案が生じたＤＣｏｎＥインスタンスに対してグローバルに一意の識別子を表わす）との組み合わせを使用して、ローカルシーケンスの順序を維持するグローバルシーケンスを作成する。実際に、グローバルシーケンスは、提案者のＩＤ内にローカルシーケンスの順序で分類され、以下に考察する各サーバノードのロックスケジューラに渡される。
ロックスケジューラ

ＤＣｏｎＥが合意済みの提案を各々のサーバノードで動作しているアプリケーションに渡す、各サーバノードのロックスケジューラ。ロックスケジューラは、分散型ロックマネージャではなくデータベーススケジューラのように機能する。「ロックスケジューラ」という用語は、同時制御のためにアプリケーションによって指定されたロックに依存しているために、競合していない多数のトランザクションを平行して処理できるということに由来している。ロックスケジューラは、グローバルな順序には依存しない。ロックスケジューラがトランザクションを各サイトの基本アプリケーションに送信する順序は、そのサーバノードのそれぞれのＤＣｏｎＥインスタンスから渡されるグローバルにシーケンスされたイベント（ＧＳＮキュー）のローカルキューによって決まる。これによって、各サーバノードの完全にローカルなロックスケジューラは、グローバル状態の知識が一切なくとも単一コピー等価を達成できる。１つの実施形態では、基本アプリケーションとのインターフェースとなるのはロックスケジューラであり、直接ＤＣｏｎＥとのインターフェースになるのではない。
パフォーマンスおよびスケーラビリティの達成

ＤＣｏｎＥは、パクソスアルゴリズムの機能を大幅に拡大し、それによって大規模に強化したパフォーマンスが可能になる。このように拡大した機能として、クォーラム、同時合意処理、バックオフと衝突回避、動的グループ進化、分散型ガベージコレクション、識別するために提案および弱い保留に対して際立った公正なラウンド番号などがあるが、いくつかの領域はそのような拡張機能に含まれる。
クォーラム

ＤＣｏｎＥで用いられるクォーラムの概念により、クライアントの分散およびサーバノード全体の活動に基づいてパフォーマンスを最適にし、ネットワークおよびサーバが停止する影響を最少にすることが可能になる。使用可能なクォーラム構成オプションとして、多数決、シングルトンおよび全会一致がある。分散システムは、多数決のクォーラムによって達成されるコンセンサスで動作するように構成されてよいが、シングルトンおよび全会一致のコンセンサスも可能である。多数決のクォーラムでは、大多数のサーバノードが提案に応答することが求められる。ＤＣｏｎＥは、分散システムに偶数のサーバノードがある場合にタイブレーカーとして機能できる際立ったノードの概念もサポートする。シングルトンのクォーラムでは、１つのノードのみが提案に応答する必要がある。この構成でシングルトンクォーラムになるように選択されたサーバノードは、クライアント数および取引アクティビティのレベルが最大であるサーバノードであってよい。利点は、トランザクション量が最も多いサーバノードで合意プロセス中にワイドエリアネットワーク（ＷＡＮ）トラフィックが発生しないことである。合意は、クォーラムノードのローカルＤＣｏｎＥインスタンスによって完全に処理される。他のサーバノードは、シングルトンクォーラムノードから合意を得るために提案を送信するが、通常は高速のパフォーマンスを実現する。なぜなら、他のサーバノードは、提案をそれぞれのローカルロックスケジューラに渡す前に、指定されたシングルトンサーバノードが提案に合意することを要求するだけで、提案の実行を完了するわけではないからである。全会一致クォーラムは、全サーバノードが応答することを要求し、本質的には最も効率の低い構成であり、ＷＡＮトラフィックを最も多く発生させる構成である。

ＤＣｏｎＥは、太陽追尾モデルに基づいて、ある領域から別の領域へのクォーラムの回転もサポートする。これにより、グローバルに分散されたシステムの各サイトでの通常の労働時間に基づいてパフォーマンスを最適化できる。また、クォーラムの手法は、ＤＣｏｎＥの自動回復特性と組み合わせて機能し、分散システムでのネットワーク停止およびサーバクラッシュの影響を最少にする。
同時合意

パクソスアルゴリズムでは、一度に１つの提案しか合意に達することができない。これは、トランザクション量が多い環境ではパフォーマンスの低下に明らかな影響がある。ＤＣｏｎＥでは、提案ごとにサーバノードのすべてまたは１つのクォーラムが合意に達するのを待つのではなく、複数の提案者からの複数の提案を同時に進行させることが可能である。
バックオフおよび衝突回避

ＤＣｏｎＥは、ピアによる提案者のプリエンプションが繰り返されるのを回避するためにバックオフ機構を提供する。従来の複製状態マシンでは、プリエンプトされた提案者は、合意番号がプリエンプタの合意番号よりも高い新たなラウンドを直ちに開始できる。この手法では、合意プロトコルが長期にわたってスラッシングし、パフォーマンスが著しく低下するおそれがある。ＤＣｏｎＥでは、ラウンドがプリエンプトされると、提案を開始したＤＣｏｎＥインスタンスは、バックオフの遅延期間を計算する。次に提案者は、この期間待機してから次のラウンドを開始する。ＤＣｏｎＥは、非スイッチドイーサネットのＣａｒｒｉｅｒ Ｓｅｎｓｅ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ／Ｃｏｌｌｉｓｉｏｎ Ｄｅｔｅｃｔｉｏｎ（搬送波感知多重アクセス／衝突回避方式）（ＣＳＭＡ／ＣＤ）プロトコルに類似した手法を用いる。
自動バックアップおよび回復

ＤＣｏｎＥのアクティブ－アクティブ構成の複製能力は、１つひとつのサーバノードを他の１つひとつのサーバノードのミラーに変えることによって、デフォルトで継続的なホットバックアップを提供する。これは、ネットワークまたはサーバの障害が原因でサーバノードが遅れた場合にＷＡＮまたはＬＡＮを介した自動回復を行うために活用される。手動での介入は必要ない。分散システムのサーバノードがピアとの接触を失ってもクライアントがその場所で引き続き利用できる場合、それらのクライアントは引き続き分散システムへの読み取りアクセス権を有するが、合意プロセスは続行できないため、提案を開始することはできない。これによって、サーバノードがピアと同期しなくなるためにすべてのサーバノードに対して単一コピー等価という要件に反することになるスプリットブレインシナリオが生じるのを防止する。ただし、クォーラムがまだ利用可能であれば、引き続き残りのサーバノードで提案を送信できる。これによって、分散システムでのネットワークの停止およびサーバの障害の影響が最少になる。障害が発生したサーバノードがオンラインに戻ると直ちに、そのＤＣｏｎＥインスタンスは、オフライン中にピアによって合意されたすべての提案に自動的に追いつく。これは合意ログを用いることで達成されてよい。合意ログは、停止が起こる前にサーバノードで最後に合意された提案を含んでいる。回復プロセスが始まると、サーバノードのＤＣｏｎＥインスタンスは、ピアからの合意ログに記録された最後のトランザクションの後の合意をすべて要求する。さらに、合意プロセスを完了しなかった提案ログに残っているどのような提案も、追いつきが完了するとローカルＤＣｏｎＥインスタンスによって自動的に再送信される。これはつまり、分散システムのサーバノード全体で何らかの提案に関して合意に達する前または後に停止が起こるかどうかに関係なく、データが失われることはないということである。

さらに、ＤＣｏｎＥの自動回復能力により、ディスクミラーリングソリューションの必要性がなくなる。ディスクミラーリングソリューションは、ＷＡＮではなくＬＡＮ上でのみ機能し、回復を達成するために管理者の介入を必要とする。その結果、これらのソリューションは、人的エラーによるダウンタイムの延長およびデータ損失のリスクをもたらす可能性がある。最後に、ＤＣｏｎＥの自動回復特性により、ユーザーアクセスを途絶することなく、メンテナンスのためにサーバをオフラインにすることも可能になる。なぜなら、クライアントは、オフラインのときに別のサイトのサーバノードにリダイレクトできるからである。これにより、グローバルに分散した環境で２４時間常時動作することが可能になる。

図１は、１つの実施形態による分散調整エンジン（ＤＣｏｎＥ）を使用する分散システムの図である。１つの実施形態によれば、（好ましくは奇数の）複数（例えば３、５、７…）のサーバノードが、単一のＤＣｏｎＥ１０８またはＤＣｏｎＥ１０８の別個のインスタンスによってコンピュータネットワーク上に用意され、調整されてよい。単なる例示を目的として、図１には３つのサーバノード１０２、１０４、１０６を示しており、それぞれがＤＣｏｎＥ１０８のインスタンスに結合されている。実際、ＤＣｏｎＥ１０８は、各ノードまたはノードのクラスタ（互いにかなり離れていてよい）でエージェントまたはインスタンスとして構成されてよく、エージェントまたはインスタンスは、ＬＡＮなどのネットワークまたはインターネットなどのＷＡＮを介して互いに調整し合う。１つの実施形態によれば、サーバノード１０２、１０４または１０６のうちの１つで開始されたＤＣｏｎＥインスタンス１０８によって生じた合意は、ＤＣｏｎＥ１０８によって一貫した方法で他のサーバノードに伝搬される。このようにして、顧客のアプリケーションは、分散システムに結合された全サーバノードに対して分散かつ／または複製される、一貫して順序付けされた合意に頼ることができる。本明細書に開示する複製方法は、分散システムに対して可用性が高いアクティブ－アクティブ構成モデルを提供し、分散システムを構成するサーバノード間での負荷分散を可能にするものである。

ＤＣｏｎＥ１０８は、合意（例えば、取引所または市場で発生するトランザクションをすべて記録する分散型台帳の更新、バージョン管理されたソフトウェアプロジェクトの変更、および／または任意の分散データベースまたはクライアントアプリケーションの変更）のグローバル順序を決定するように構成されてよい。複製状態マシンまたはクライアントアプリケーションはすべて同じ状態で開始し、サーバノードはすべて同じ決定論的順序で更新を適用するようになるため（ただし、実施形態によれば、必ずしも同時でなくてもよい）、複製状態マシンまたはクライアントアプリケーションの状態は、ノード全体で一貫性を維持する（または一貫性を保つようになる）。

１つの実施形態によれば、また図１に示したように、複数のサーバノード１０２、１０４、１０６に対する合意の一貫性は、以下のように達成されてよい。（１）に示したように、サーバノードのうちの１つ（この場合はサーバノード１０２）は、クライアントの要求または提案を顧客から受け取る。それは例えば、名前スペース、アプリケーションの状態を変更する提案、最終的に分散型台帳を更新させることになる指定量の商品またはサービスを売買する要求、データベースを変更する提案、あるいはファイルにデータブロックを追加したり、ファイルを作成したり、ディレクトリを作成したりする提案である。図２に示したように、１つの実施形態によれば、クライアントの要求または提案２００は、タプルとして形成されてよく、かつそのような各タプルは、２０２で示したように、クライアントから提供される一意の要求識別子と、提案がアプリケーション提案（アプリケーションの状態を変更する提案）かＤＣｏｎＥ制御提案（ＤＣｏｎＥが内部で使用する提案）かを判断する提案の種類２０４と、一意のクライアント識別子２０６と、提案の要求２０８を形成するバイト列とを含んでいてよく、バイト列はクライアント提案２００のペイロードを形成する。図２の２０８に示したクライアント提案のペイロードは、ＤＣｏｎＥ１０８には不透明であってよい。したがって、ＤＣｏｎＥ制御提案は、クライアントアプリケーションではなくＤＣｏｎＥの処理対象となる。ＤＣｏｎＥ制御提案の一例が、共同所有権の米国特許第９，３３２，０６９号に記載されている、ＤＣｏｎＥがそのメンバーシップを変更するための提案であり、同文献の全容を本願に援用する。

ここで図１およびこの図で展開されている例に戻ると、サーバノード１０４は提案１を受け取り、サーバノード１０６は提案２を受け取る。１つの実施形態によれば、サーバノード１０２が、提案３内にカプセル化されたイベント（例えば読み取り、書き込み、削除など）でアプリケーションの状態を直ちに更新し、サーバノード１０４が、受け取った提案１内にカプセル化されたイベントでアプリケーションの状態を直ちに更新し、サーバノード１０６が、提案２内にカプセル化された（１つまたは複数の）イベントでアプリケーション、名前スペースなどの状態を直ちに更新し、その後、そのような更新をサーバノード１０２、１０４、１０６のアプリケーションの他の状態に伝搬し、これらの別々のクライアント要求が、永続化された共有キュー（例えばリレーショナルデータベース）からＤＣｏｎＥ１０８へ提案として渡され、大多数の承認者ノードがそれについて合意に達した後に（合意は、使用されている何らかのコンセンサスプロトコルによって達したコンセンサス）、ＤＣｏｎＥ１０８がそれらの提案を順序付けた合意のリストとしてサーバノード１０２、１０４、１０６に送り返す。これは本明細書に記載の通りである。

これは、図１に示したように、提案３（例えばクライアント要求３）を受け取ったことへの応答であり、サーバノード１０２は、（２）に示したように提案Ｐｒｏｐ３をＤＣｏｎＥ１０８に出してよい。同じように、提案１（例えばクライアント要求１）を受け取ったことに応答して、サーバノード１０４は、（２）に示したように提案Ｐｒｏｐ１をＤＣｏｎＥ１０８に出してよく、提案２（例えばクライアント要求２）を受け取ったことに応答して、サーバノード１０６は、同じく（２）に示したように提案Ｐｒｏｐ２をＤＣｏｎＥ１０８に出してよい。１つの実施形態によれば、ＤＣｏｎＥ１０８はその後、大多数の承認者ノードのコンセンサスを通じて合意を得て、合意済みの提案をシリアル化し、（３）に示したように受け取った提案を順序付けし、（４）に示したように、グローバルに順序付けした（この場合、ＡＧＲ３の次がＡＧＲ１、その次がＡＧＲ２という順序の）合意の永続化された出力キューとして合意されているそれらの提案を、サーバノード１０２、１０４、１０６で稼働しているアプリケーションに同様にフィードバックする。サーバノード１０２、１０４および１０６のクライアントアプリケーションは、順序付けされた合意のシーケンスＡＧＲ３、ＡＧＲ１およびＡＧＲ２を受け取ると、これらの合意をその決定論的な順序で実装し、それに応じてそのそれぞれの状態を更新して、各々がサーバノード１０２、１０４、１０６全体で一貫性を維持する（かつ／または一貫性を保つ）ようにする。このようにして、アプリケーションの状態は、（５）で示唆したように、一貫性を損なうことなく非同期で更新されてよい。次に、これらの更新は、サーバノード１０２、１０４、１０６に結合していてよい、またはアクセス可能であってよい（ただし、１１０、１１２および１１４に破線で示したように必須ではない）それぞれのローカル永続ストレージ１１０、１１２、１１４に日々のトランザクションとして保存されてよい（ただし必須ではない）。次に、必要に応じて、クライアント要求を送信したクライアントに通知を返してよい。

そのため、１つの実施形態によれば、サーバノード１０２、１０４、１０６は、クライアントの要求を直接記録するのではなく、コンセンサスを通じた合意、シリアル化および順序付けのためにそれらを提案として再パッケージ化してＤＣｏｎＥ１０８にリダイレクトする。次に、これらのサーバノードに格納されているアプリケーションおよび／またはデータベースの状態の更新は、永続的でグローバルに順序付けされた一連の合意としてＤＣｏｎＥ１０８からＤＣｏｎＥによって出される。これは、クライアント要求が最終的に実装されるときに各サーバノード１０２、１０４、１０６のアプリケーションが更新されることを保証するものであり、それによって更新が、クラスタ内のサーバノードの意図したアプリケーションすべてに明白かつ一貫して適用されるようにする。このようにして、分散システム全体での複数のサーバノードの各々のアプリケーションの状態は、時間を経ても一貫した状態に維持され得る。

したがって、１つの実施形態によれば、ＤＣｏｎＥ１０８の重要な役割が、クライアント要求をサーバノードから受け取った提案として処理し、それを永続的でグローバルに順序付けした合意シーケンスに変換することである。次に、サーバノード（これは地理的にもタイムゾーンでもかなり離れていることがある）は、そのグローバルに順序付けした合意シーケンスから合意の基礎となる変更またはトランザクションを実装し、順序付けされた変更または更新をクライアントのアプリケーションに提供してよい。

図３に示したように、提案がアプリケーション提案であろうと制御提案であろうと、提案タプルをＤＣｏｎＥのバージョン全体で不変のフォーマットで符号化してよい。クライアント提案３００は、ＤＣｏｎＥ１０８への入力キューに格納されているため、ローカルシーケンス番号すなわちＬＳＮ３０２と対になっているクライアント提案２００を含んでいてよい。動作に関して、ＤＣｏｎＥ１０８に送信する提案を作成するとき、サーバノードはその提案にＬＳＮを与えるが、これは単なる整数であってよい。１つの実装形態では、ＬＳＮはサーバノードに対してのみローカルである。通常の動作では、ＤＣｏｎＥ１０８は、入力キューからクライアント提案を１つデキューする処理をし、他の承認者ノードとの合意を達成し、提案にグローバルシーケンス番号（ＧＳＮ）を割り当てる。次にＤＣｏｎＥ１０８は、そのようにグローバルに順序付けされた提案を出力キューと称する共有の永続的な出力キューに出力してよい。１つの実装形態では、グローバルに順序付けした提案を受け取って格納するためにリレーショナルデータベースを使用してよく、提案は、その提案が制御提案であれば、アプリケーションによって消費されるか、ＤＣｏｎＥ自体によって消費されるＤＣｏｎＥから出力される。永続化されグローバルに順序付けされた提案の各々のエントリのフォーマットとして、ＧＳＮおよび提案があってよい。このフォーマットおよび符号化は、ＤＣｏｎＥのバージョン全体で不変であってよい。次にサーバノードのアプリケーションは、合意済みで順序付けされた提案（アプリケーション提案の場合）を、出力キューからＧＳＮの順に指定された順序でデキューし、処理する。ＤＣｏｎＥ１０８は、ＧＳＮに従って合意を実行する番になったときは、どのような制御提案でも処理する。

１つの実施形態によれば、ＧＳＮは、単調に増えていく一意の番号として構成されてよいが、そうでなければ当業者が認識し得るように構成されてよい。ＧＳＮは、アプリケーションの状態を更新する際に様々なサーバノードの進捗を比較し、サーバノード全体でその状態の一貫性を維持するためにも使用してよい。例えば、サーバノード１０２がＧＳＮ１と番号付けされた合意を処理したばかりで、この番号がサーバノード１０４によって処理されたばかりのＧＳＮ２よりも小さい場合、サーバノード１０２のアプリケーションのインスタンスは現在、サーバノード１０４のアプリケーションのインスタンスよりも早い状態にあるということになる。

１つの実装形態によれば、図４に示したように、合意された提案３００のＧＳＮ４０２は、それ自体が、合意が合意に至ったＤＣｏｎＥのバージョン番号４０４と、ＤＣｏｎＥのそのバージョン内でのグローバルシーケンス番号４０６とが、例えば｛バージョン番号、バージョンシーケンス番号｝という形式になっている２つの部分からなるタプルであってよい。アプリケーションは、現在のＤＣｏｎＥバージョン番号と一致する永続化された合意の出力キューからＧＳＮのみをデキューして処理する。これを、バージョン番号を変更するように指示されるまで行い、この指示により、アプリケーションがバージョン番号の異なる（例えば更新された）ＤＣｏｎＥから出された合意を処理し始める。前述したように、ＤＣｏｎＥのバージョン番号が異なる理由の１つは、ＤＣｏｎＥを定期的に更新する必要があるからである。

１つの実施形態によれば、クライアント要求の読み込みには、コンセンサスに達するためのＤＣｏｎＥ１０８を必要とせず、書き込む必要があるだけである。１つの実施形態によれば、ＤＣｏｎＥ１０８は、基礎となるクライアントアプリケーションのインスタンスが全サーバノードで常に同一であることを保証するわけではないことに注意されたい。むしろ、ＤＣｏｎＥ１０８は、サーバノード１０２、１０４、１０６のクライアントアプリケーションが他のすべてのサーバノードと同じ順序で各合意について一貫して学習することを保証する。このようにして、ＤＣｏｎＥ１０８は、合意された提案をグローバルに順序付けしたシーケンスを生成するように構成され、そのシーケンスは、全サーバノード１０２、１０４、１０６に同様に供給されて、シーケンス通りに順序付けされた予測可能な更新をクライアントアプリケーションに対して行う。すると、これによってクライアントアプリケーションの各インスタンスが各サーバノードで同じ順序で実行することによって合意が消費され、その各インスタンスが予測可能で改ざん防止された決定論的な方法で進行することを確実にする。

１つの実施形態によれば、ローカル永続ストレージ１１０、１１２、１１４に格納されているジャーナルの更新が実行されてよい。ただし、サーバノード１０２、１０４、１０６のクライアントアプリケーションの一貫性は、そのようなジャーナルの更新には左右されず、１つの実施形態によれば、各々の永続ストレージ（ある場合）は、サーバノードに対してローカルであり、ネットワークを介して他のサーバノードと共有されない。同じように、サーバノード１０２、１０４、１０６どうしでクライアントアプリケーションの一貫性を維持することは、メモリまたはプロセッサリソースなどの他のリソースを共有することに依存するものではない。

実施形態によれば、分散システムには好適な（主要な、あるいは際立った）サーバノードはない。実際、１つ以上のサーバノードに障害が発生した場合、あるいはメンテナンスのために（または何らかの他の理由で）オフラインになった場合、他のアクティブなサーバノードが使用可能になってクライアント要求（提案）に対応し、アクセスが中断されることはない。１つの実施形態によれば、以前にダウンしていたサーバノードがオンラインに戻るとすぐに、そのサーバノードは自動的に他のサーバノードのサーバと再び同期し得る。そのような同期は、サーバノードがダウンしたかオフラインになった後にＤＣｏｎＥ１０８が出したすべての合意済みの提案を学習することを含んでいてよい。全サーバノードのクライアントアプリケーションが常に維持されるか同期状態になるため、スプリットブレイン状態とデータ損失の両方がなくなり、それによってデフォルトで継続的なホットバックアップを実現する。フェイルオーバーと回復の両方が即時かつ自動であり、それによって手動で介入する必要性および管理者エラーのリスクがさらになくなる。さらに、サーバノード１０２、１０４、１０６のいずれもパッシブまたはスタンバイのサーバノードとして構成されてはいない。実際、１つの実施形態によれば、分散システムのサーバノードのサーバはすべて、分散システムへのアクセスまたは分散システム内のトランザクションに対する同時のクライアント要求をサポートするように構成される。その結果、これによって、仕事量が増すことでパフォーマンスを犠牲にすることなく、分散システムを容易に拡張して追加のサーバノードをサポートすることが可能になる。１つの実施形態によれば、現在の分散システムにはパッシブスタンドバイサーバはなく、単一の主要調整サーバノードの脆弱性およびボトルネックはなくなる。さらに、複数のサーバノード１０２、１０４、１０６（および／または図１に示していない他のサーバノード）にクライアント要求を分散することは、本質的に、利用可能な全サーバノードに処理の負荷およびトラフィックを分散することである。サーバノード１０２、１０４、１０６どうしでのアクティブな負荷分散も実行してよい。

１つの実施形態によれば、単一の提案が、ＤＣｏｎＥへの入力キューとＤＣｏｎＥ内部の永続状態の両方に存在することはできない。実際、提案は、入力キューにあるか、ＤＣｏｎＥによってデキューされ、処理され、ＤＣｏｎＥ内部のデータベースなどの中に内部で永続しているかのいずれかである。したがって、そのような障害から保護するために、入力側では、クライアント提案がＤＣｏｎＥによって２回合意されないように、そしてＤＣｏｎＥの出力側では、合意済みの提案（「合意」とも称する）が２回出力されないように注意される。入力側でこれを達成するために、１つの実施形態によれば、ＤＣｏｎＥが入力キューから提案をデキューして読み取るときに、ＤＣｏｎＥがこの提案に関連するＬＳＮ３０２を以前に見たことがないことを確認するためにチェックを実行してよい。ＤＣｏｎＥがデキューしたばかりの提案のＬＳＮと関連するクライアント提案２００を以前に処理したことがある場合、提案をクライアントキューからＤＣｏｎＥ１０８にデキューし、かつ／または転送する際に障害に発生したと仮定して、その提案は除外される。したがって、１つの実施形態によれば、ＤＣｏｎＥ１０８は、準備ができている各ＬＳＮ３０２１の記録を維持する必要はなく、最後の記録だけを維持する。同じように、ＤＣｏｎＥの出力側での障害から保護するために、ＤＣｏｎＥ１０８は、出力キューに合意を追加する前に、同じＧＳＮを有する出力キューに他の合意がないことをＤＣｏｎＥ１０８が確認するように構成されてよい。実際、同じＧＳＮに関連する他の合意が出力の中にまだ存在していないとＤＣｏｎＥ１０８が判断した後でのみ合意オブジェクトを出力キューに委ね、それによって障害が原因で合意が出力キューに２回以上出力される問題に対処する。そうするために、１つの実施形態によれば、ＤＣｏｎＥの永続化された出力キューは、ＤＣｏｎＥ１０８から出力された最後のＧＳＮの記録を維持する。
アップグレード時のＤＣｏｎＥアプリケーション提案の処理

実施形態は、分散調整エンジンが更新されているときのＷＡＮを介したそのような分散システムで、合意の一貫性およびクライアントアプリケーションの状態の一貫性を維持する方法、装置およびシステムにも及ぶ。ＤＣｏｎＥエンジンをアップグレードする必要がある場合に、顧客が中断に遭遇してはならず、クライアントアプリケーションの状態は、ＤＣｏｎＥのあるバージョンからＤＣｏｎＥの別のバージョンに切り替える間であっても決定論的で予測可能なように進展し続ける必要がある。そうするために、１つの実施形態では、クライアントが不変プロトコルを使用してＤＣｏｎＥの入力キューおよび出力キューと相互作用することを求め、その際、提案をデキューして処理し、合意を達成し、合意を出力するプロセスは、アップグレードプロセスの過程で継続するように維持される。

本明細書では、図５を参照すると、ＤＣｏｎＥの現在のバージョンは、５０６に示したようにＤＣｏｎＥがｖ１であると仮定されている。動作に関して、前述したように、ＤＣｏｎＥ ｖ１ ５０６のプロセスは、実行中で、合意を行い、ＤＣｏｎＥ入力キュー５０８から読み取り、ＧＳＮの順序の合意をＤＣｏｎＥ出力キュー５１０に出力している。これらの合意は、クライアントアプリケーション５０２によってＧＳＮの順序で処理される。ＤＣｏｎＥ５０６の更新が必要になると、（例えば）図２の５１２に示した別の一連のＤＣｏｎＥプロセスであるＤＣｏｎＥ ｖ２がインスタンス化されて各ノードで開始されてよい。次に、ＤＣｏｎＥ ｖ２のプロセス５１２のそれぞれのインスタンスは、１つの実施形態によれば、５１４に示したようにＤＣｏｎＥの入力キュー５０８に接続されてよい。同じように、ＤＣｏｎＥ ｖ２のプロセス５１２のそれぞれのインスタンスは、５１６に示したようにＤＣｏｎＥの出力キュー５１０にも接続されてよい。最初のうちは、１つの実施形態によれば、ＤＣｏｎＥ ｖ２ ５１２は、入力キューおよび出力キュー５０８、５１０を監視するだけで、クライアント提案を処理することはない。

１つの実施形態によれば、ＤＣｏｎＥ ｖ１ ５０６からＤＣｏｎＥ ｖ２ ５１２への切り替えを希望する場合、本明細書でバージョン変更提案と称する特別な提案を各ノードの入力キュー５０８に追加してよい。バージョン変更提案は、１つの実施形態によれば、ＤＣｏｎＥ ｖ２ ５１２のバージョン番号を含んでいてよい。この段階では、ＤＣｏｎＥ ｖ１ ５０６とＤＣｏｎＥ ｖ２の両方が入力キュー５０８を監視しているが、ＤＣｏｎＥ ｖ１ ５０６のみが提案を処理し、対応する合意をその出力キュー５１０に出力する。バージョン変更提案がＤＣｏｎＥ ｖ１ ５０６に達すると、バージョン変更提案はデキューされ、ＤＣｏｎＥ ｖ１ ５０６による処理へと送信される。１つの実施形態によれば、ＤＣｏｎＥ ｖ１ ５０６によるバージョン変更提案の処理は、ＤＣｏｎＥ ｖ１ ５０６からＤＣｏｎＥ ｖ２ ５１２への切り替えを効果的に指示する。１つの実施形態によれば、このバージョン変更提案は、ＤＣｏｎＥ ｖ１ ５０６でデキューされ処理される最後の提案であり、バージョン変更提案についての合意が出力キュー５１０に出力される。その後、すでに入力キュー５０８および出力キュー５１０に結合しているＤＣｏｎＥ ｖ２ ５１２は、バージョン変更提案に続いて入力キュー５０８のすべての提案を処理する。この時点で、ＤＣｏｎＥ ｖ１ ５０６とＤＣｏｎＥ ｖ２の両方が、合意を取り付けていて、提案を出力キュー５１０に入れている。ただし、ＤＣｏｎＥ ｖ１ ５０６がバージョン変更提案を受け取って処理した後は、合意を取り付けて出力キュー５１０に出力するのはＤＣｏｎＥ ｖ２ ５１２のみになる。１つの実装形態では、ＤＣｏｎＥ ｖ２ ５１２によって処理される最初の合意は、最初の所定のＧＳＮ、例えばＧＳＮゼロ（０）に関連付けられてよい。ただし、当業者が理解し得るとおり、選択した最初の所定のＧＳＮが以前に使用されていないかぎり、他の開始ＧＳＮを使用してよい。

動作に関して、１つの実施形態によれば、入力キュー５０８に送信されたバージョン変更提案は、ＤＣｏｎＥ ｖ１ ５０６によって処理され合意されてよく、また、図４を参照すると、｛ｖ１，Ｘ｝と付したバージョン番号４０４とバージョンシーケンス番号４０６の両方を含むＧＳＮ４０２が割り当てられてよい。１つの実施形態によれば、クライアントアプリケーション５０２は、この｛ｖ１，Ｘ｝の合意を消費するときに、ｖ１のバージョン番号４０４を有する合意の処理を停止するように構成されてよい。つまり、クライアントアプリケーション５０２は、バージョン変更提案に対応する合意を受け取って消費すると、ＤＣｏｎＥ ｖ１ ５０６からさらに他の合意を消費するのを停止するということである。さらに、１つの実施形態によれば、クライアントアプリケーション５０２に提示される、ＤＣｏｎＥ ｖ１ ５０６に由来する出力キュー５１０についての合意で、バージョン変更提案のクライアントアプリケーション５０２に対応する合意のバージョンシーケンス番号よりも大きいＧＳＮ（具体的にはバージョンシーケンス番号４０６）を有するものは、次に、ルーティングされ、入力キュー５０８に送り返され、そこでＤＣｏｎＥ ｖ２ ５１２によって処理される。例えば、クライアントアプリケーション５０２が合意｛ｖ１，Ｘ＋１｝で提示される場合、バージョンシーケンス番号がＸよりも大きいＤＣｏｎＥ ｖ１ ５０６から来る他の合意が、対応する提案としてルーティングされて入力キュー５０８に送り返され、ＤＣｏｎＥ ｖ２ ５１２によってデキューされて合意され、その結果生じる合意はｖ２のバージョン番号である。次に、アプリケーション５０２は、合意｛ｖ２，０｝を探すように切り換えてよく、この場合０は最初の所定のバージョンシーケンス番号４０６である。次に、新しくアップグレードされたＤＣｏｎＥ ｖ２ ５１２は、入力キュー５０８の提案を処理し始めてよく、その間は終始、上記に詳述したＬＳＮチェック機構を使用して、以前に同じ提案をデキューして処理していないことをチェックする。

ｎ個のサーバノードの各々がバージョン変更提案を生成し、そのバージョン変更提案をそれぞれの入力キュー５０８に配置するので、対応する合意はｎ個あることに注意されたい。１つの実施形態によれば、バージョン変更提案に対応する最初の合意を確認した後、アプリケーションはそれ以降、同じバージョン番号の場合は遭遇するバージョン変更の合意を無視し、入力キュー５０８にルーティングし直さずにそのようにする。つまり、そのような合意は再度提案されない。１つの実施形態によれば、バージョンが古く（ここで展開されている例ではｖ１）、ＤＣｏｎＥ ｖ１ ５０６が引き続き入力キュー５０８からの提案を処理しているためにクライアントアプリケーション５０２が提案を再度提案する場合、その提案は、ＤＣｏｎＥ ｖ１ ５０６によってｖ１のバージョン番号で再度合意される。そして、ＤＣｏｎＥ ｖ２のプロセスが引き継いで単独で（ＤＣｏｎＥ ｖ１ ５０６を除く）提案の処理を開始し、対応する合意を生成するまで、再度提案されることはない。
アップグレード時のＤＣｏｎＥ制御提案の処理

１つの実施形態によれば、バージョン変更提案が入力キュー５０８に追加されれば、ＤＣｏｎＥ ｖ１ ５０６を対象とする入力キュー５０８のいずれかのＤＣｏｎＥ制御提案が拒否されるか、新しいバージョンのＤＣｏｎＥ提案つまり、ＤＣｏｎＥ ｖ２ ５１２で動作するように構成されている制御提案に変換されてよい。これが可能になるのは、バージョン変更提案が入力キュー５０８に追加された後、ＤＣｏｎＥの新しい方のバージョン（ＤＣｏｎＥ ｖ２ ５１２）のみが入力キュー５０８から読み取っているからである。１つの実装形態では、ＤＣｏｎＥ ｖ２ ５１２は、蓄積提案を処理するように構成されてもよいし、蓄積提案を拒否するように構成されてもよいし、あるいはＤＣｏｎＥ ｖ１ ５０６で動作するように設計されたのと同じまたはほぼ同じようにＤＣｏｎＥ ｖ２ ５１２で動作するように蓄積提案を書き直してもよい。１つの実施形態によれば、ＤＣｏｎＥ ｖ１ ５０６で消費するように構成された制御提案が、バージョン変更提案が出された後に合意されるように、ｖ１の制御提案（すなわち、ＤＣｏｎＥ ｖ１ ５０６で消費するように構成された制御提案）は、バージョン変更提案よりも前に入力キュー５０８に追加されてよいが、ＤＣｏｎＥ ｖ１ ５０６内の合意プロセスではその制御提案を出力時に再度順序付けてよい。次にｖ１の制御提案は、ＤＣｏｎＥ ｖ２ ５１２で消費して合意するように、再度ルーティングされて入力キュー５０８に送り返されてよい。この場合、ＤＣｏｎＥ ｖ２ ５１２は、そのような制御提案を数々の方法で処理し得る。１つの実施形態によれば、ＤＣｏｎＥ ｖ２ ５１２は、制御提案を拒否し、制御提案が拒否されたことをクライアントに通知してよい。これによってクライアントには、ＤＣｏｎＥ ｖ２ ５１２で消費するために制御提案を除外するか再フォーマットする機会が与えられる。あるいは、ＤＣｏｎＥ ｖ２ ５１２は、蓄積提案の処理方法がわかっていればその蓄積提案を承認してよい。いくつかの実装形態では、ＤＣｏｎＥのいずれかの後のバージョンは、それ以前のＤＣｏｎＥバージョンからのすべてまたは一部の制御提案を処理する能力を有するように構成されてよい。またあるいは、ＤＣｏｎＥの後のバージョンは（この例ではＤＣｏｎＥ ｖ２ ５１２）、ｖ１タイプの制御提案を、意味の上では同等であるｖ２タイプの制御提案に置き換えて合意を達成してよい。
ＤＣｏｎＥの古いバージョンをオフにする

１つの実施形態によれば、より新しいＤＣｏｎＥバージョンがアップされ、稼動し、入力キュー５０８から合意をデキューし、それを処理し、対応する合意を出力キュー５１０に出すと、それに代えられた古い方のＤＣｏｎＥは、オフにされてもよいし、あるいはさらに他の提案を処理しないように使用不可能にされてよい。ただし、ＤＣｏｎＥの古い方のバージョンのインスタンスは、まだ有効な合意がある場合はオフにしてはならない。それはつまり、まだ合意されていて出力キュー５１０に配置されている提案である。これに対処するため、１つの実施形態によれば、ＤＣｏｎＥ ｖ１ ５０６のすべてのインスタンスが、オフにされる前に有効な合意がもうないことを確認するようチェックされる。そうすることで、未処理の提案が残ることがなくなり、かつ／またはＤＣｏｎＥのアップグレードプロセスで再送信されなくなるようにする。

図６は、１つの実施形態によるコンピュータ実装方法のフローチャートである。さらに詳細には、図６は、複数のサーバノードでクライアントアプリケーションの一貫性を維持するコンピュータ実装方法のフローチャートである。Ｂ６０２に示したように、本方法は、複数のサーバノードの１つ以上に結合している第１バージョンの分散調整エンジン（ＤＣｏｎＥ）を提供することを含んでいてよい。第１バージョンのＤＣｏｎＥでは、Ｂ６０４に示したように、提案を入力キューで受け取って提案について合意に達してよく、第１の順序の合意を複数のサーバノードの１つ以上に結合している出力キューで出力してよい。第１の順序の合意は、本明細書に記載し図示したように、クライアントアプリケーションが第１の順序の合意を構成している合意を実行してそれに応じてそのそれぞれの状態を更新する順序を指定してよい。Ｂ６０６に示したように、バージョン変更提案に関して入力キューを監視してよく、バージョン変更提案について合意に達してよい。次に、バージョン変更提案についての合意を出力キューで出力してよく、第１バージョンのＤＣｏｎＥは、それ以降に入力キューで提案についてそれ以上合意に達するのを停止してよい。

Ｂ６０８に示したように、第２バージョンのＤＣｏｎＥを提供し、複数のサーバノードの１つ以上に結合してよい。Ｂ６０８に示したように、第２バージョンのＤＣｏｎＥでは、バージョン変更提案に対応する合意を出力キューに出力した後、入力キューで提案について合意に達してよく、第２の順序の合意を、バージョン変更提案に対応する合意から始まる出力キューで出力してよい。Ｂ６１０で要求されるように、第２の順序の合意は、合意に達した提案を含んでいてよく、クライアントアプリケーションが第２の順序の合意を構成している合意を実行してそれに応じてそのそれぞれの状態を更新する順序を指定してよい。その後、Ｂ６１２に示したように、バージョン変更提案についての合意を受け取った後に第１バージョンのＤＣｏｎＥから受け取った合意済みの提案を、入力キューを介して第２バージョンのＤＣｏｎＥに送り返して、第２バージョンのＤＣｏｎＥがそれについて合意に達することができるようにしてよい。

さらに他の実施形態によれば、第１バージョンのＤＣｏｎＥは、バージョン変更提案に対応する合意が達成された後に第１バージョンのＤＣｏｎＥが有効な提案について合意（現在進行中の合意）に達し終えた後、オフにされるか、消去されるか、あるいは動作不能にされてよい。第１および第２の順序の合意の各合意は、提案およびグローバルシーケンス番号（ＧＳＮ）を含んでいてよく、グローバルシーケンス番号は、その提案について合意に達したＤＣｏｎＥのバージョン番号およびバージョンシーケンス番号を含んでいてよい。各々のクライアントアプリケーションは、ＧＳＮが所定のバージョン番号と一致するバージョン番号を含んでいる提案のみを実行するように構成されてよい。所定のバージョン番号は、現在のバージョン番号か、あるいはＤＣｏｎＥの更新が実施されたばかりの場合は、更新されたＤＣｏｎＥのバージョン番号であってよい。このようにして、本方法は、所定のバージョン番号を第１バージョンのＤＣｏｎＥから第２バージョンに変更することをさらに含んでいてよい。１つの実施形態では、合意済みの提案を第２バージョンのＤＣｏｎＥに送り返すことは、クライアントアプリケーションのうちの１つによって実行されてよい。１つの実施形態によれば、提案は、クライアントアプリケーションの状態を変更するためのアプリケーション提案、および／または第１または第２バージョンのＤＣｏｎＥを制御するかその構成を変更するように構成されているＤＣｏｎＥ制御提案を含んでいてよい。１つの実施形態では、第２バージョンのＤＣｏｎＥは、ａ）第１バージョンのＤＣｏｎＥを制御するか構成するように構成された制御提案を拒否するか、ｂ）第１バージョンのＤＣｏｎＥを制御するか構成するように構成された制御提案を受け入れ、それについて合意するか、またはｃ）第１バージョンのＤＣｏｎＥを制御するか構成するように構成された制御提案を、第２バージョンのＤＣｏｎＥを制御するか構成するように構成された、意味の上ではほぼ同じである制御提案に入れ替えてよい。

本明細書に図示し、記載したように、１つの実施形態は、複数のサーバノード、第１バージョンのＤＣｏｎＥおよび第２バージョンのＤＣｏｎＥを含む分散システムである。１つの実施形態によれば、複数のサーバノードの各々または選択したものは、クライアントアプリケーションを含んでいてよく、クライアントアプリケーションの状態を変更し、対応する提案を生成するためのクライアント要求を受け取るように構成されてよい。複数のサーバノードの１つ以上に結合している第１バージョンのＤＣｏｎＥは、入力キューの提案を受け取るように構成されてよく、その提案について合意に達し、第１の順序の合意を複数のサーバノードの少なくとも１つに結合している出力キューに出力するようにさらに構成されてよい。第１の順序の合意は、クライアントアプリケーションが第１の順序の合意を構成している合意を実行してそれに応じてそのそれぞれの状態を更新する順序を指定してよい。１つの実施形態によれば、第１バージョンのＤＣｏｎＥは、バージョン変更提案に関する入力キューを監視し、それについて合意に達し、バージョン変更提案についての合意を出力キューに配置し、それ以降は入力キューで提案について合意に達しないようにさらに構成されてよい。第２バージョンのＤＣｏｎＥは、入力キューおよび出力キューに結合されてよく、バージョン変更提案について合意に達した後は、入力キューで提案について合意に達し、かつバージョン変更提案についての合意から始まる出力キューで第２の順序の合意を出力するようにさらに構成されてよい。第２の順序の合意は、合意に達した提案を含んでいてよく、クライアントアプリケーションが第２の順序の合意を構成している合意を実行してそれに応じてそのそれぞれの状態を更新する順序を指定してよい。１つの実施形態によれば、クライアントアプリケーションの１つ以上は、バージョン変更提案に対応する合意を受け取った後に第１バージョンのＤＣｏｎＥから受け取った合意済みの提案を、第２バージョンのＤＣｏｎＥで合意するために入力キューを介して第２バージョンのＤＣｏｎＥに送り返すようにさらに構成される。

またさらに他の実施形態によれば、複数のサーバノードでクライアントアプリケーションの一貫性を維持するコンピュータ実装方法は、第１バージョンのＤＣｏｎＥを提供することと；第１バージョンのＤＣｏｎＥで、提案について合意に達し、クライアントアプリケーションが第１バージョンのＤＣｏｎＥで合意した提案を実行してそれに応じてそのそれぞれの状態を更新する順序を指定する第１の順序の合意を生成することと；第２バージョンのＤＣｏｎＥ提供することと；第１バージョンのＤＣｏｎＥでバージョン変更提案について合意に達することと；バージョン変更提案について合意に達した後、第２バージョンのＤＣｏｎＥで提案について合意に達するのを停止し、クライアントアプリケーションが第２バージョンのＤＣｏｎＥで合意した提案を実行してそれに応じてそのそれぞれの状態を更新する順序を指定する第２の順序の合意を生成することと；バージョン変更提案について合意に達した後に第１バージョンのＤＣｏｎＥから受け取った合意済みの提案を、第２バージョンのＤＣｏｎＥに送り返して、第２バージョンのＤＣｏｎＥがそれについて合意に達することができるようにすることとを含んでいてよい。
物理的ハードウェア

図７は、実施形態を実装し得るコンピューティングデバイスのブロック図を示している。図７のコンピューティングデバイスは、バス７０１または情報を通信する他の通信機構、および情報を処理するためにバス７０１に結合している１つ以上のプロセッサ７０２を含んでいてよい。コンピューティングデバイスは、情報および（１つまたは複数の）プロセッサ７０２で実行する命令を記憶するためにバス７０１に結合しているランダムアクセスメモリ（ＲＡＭ）または他の動的記憶装置７０４（メインメモリと称する）をさらに含んでいてよい。メインメモリ（有形で非一時的なもの。本明細書ではこの用語には、信号自体および波形は含まれない）７０４は、プロセッサ７０２が命令を実行している間に一時的な変数または他の中間情報を記憶するためにも使用されてよい。図７のコンピューティングデバイスは、リードオンリーメモリ（ＲＯＭ）および／または静的情報および（１つまたは複数の）プロセッサ７０２向けの命令を記憶するためにバス７０１に結合している他の静的記憶装置７０６も含んでいてよい。磁気ディスクおよび／またはソリッドステートデータ記憶装置などのデータ記憶装置７０７は、情報および命令を記憶するためにバス７０１に結合されてよく、例えば、図１～図６に関して示し開示した機能を実行するよう要求される。コンピューティングデバイスは、コンピュータのユーザに情報を表示するための表示装置７２１にバス７０１を介して結合されてもよい。情報およびコマンド選択を（１つまたは複数の）プロセッサ７０２に通信するために、英数字およびその他のキーを含む英数字入力デバイス７２２をバス７０１に結合してよい。別種類のユーザ入力装置が、カーソル制御装置７２３であり、これは例えば、方向情報およびコマンド選択を（１つまたは複数の）プロセッサ７０２に通信するため、かつディスプレイ７２１上のカーソルの動きを制御するためのマウス、トラックボール、またはカーソル方向キーである。図７のコンピューティングデバイスは、通信インターフェース（例えばモデム、ネットワークインターフェースカードすなわちＮＩＣ）７０８を介してネットワーク７２６に結合されてよい。

図示したように、記憶装置７０７として、磁気ディスク７３０、不揮発性半導体メモリ（ＥＥＰＲＯＭ、フラッシュなど）７３２、７３１に提示したような磁気ディスクと不揮発性半導体メモリの両方を含むハイブリッド型データ記憶装置などの直接アクセスデータ記憶装置があってよい。符号７０４、７０６および７０７は、１つ以上のコンピューティングデバイスによって実行されたときに、分散システムの態様、本明細書に記載し図示した方法を実施する命令のシーケンスを表すデータが記憶されている、有形で非一時的なコンピュータ可読媒体の例である。これらの命令の一部は、クライアントコンピューティングデバイスにローカルで記憶されてよく、これらの命令の残りは、遠隔で記憶（かつ／または実行）され、ネットワーク７２６上で計算するクライアントに通信されてよい。他の実施形態では、これらの命令はすべて、クライアントまたは他のスタンドアローンのコンピューティングデバイスにローカルで記憶されてよく、さらに他の実施形態では、これらの命令はすべて、遠隔で（例えば１つ以上の遠隔サーバで）記憶され、実行され、結果はクライアントコンピューティングデバイスに通信される。さらに別の実施形態では、命令（処理ロジック）は、７２８に示したように、別の形態の有形で非一時的なコンピュータ可読媒体に記憶されてよい。例えば、符号７２８は、光学（または何らかの他の記憶技術の）ディスクとして実装されてよく、このディスクは、記憶されている命令を１つ以上のコンピューティングデバイスにロードするのに適切なデータキャリアを構成してよく、それによって（１つまたは複数の）コンピューティングデバイスを、本明細書に記載し図示した実施形態の１つ以上に対して構成し直す。他の実装形態では、符号７２８は、暗号化したソリッドステートドライブとして具現化されてよい。これ以外の実装形態も可能である。

本発明の実施形態は、分散システムのコンピュータネットワーク上でクライアントアプリケーションの一貫性を維持するためのコンピューティングデバイスの使用に関する。１つの実施形態によれば、本明細書に記載した方法、装置およびシステムは、命令のシーケンスを実行し、メモリ７０４に含まれている本明細書に図示し記載したコンピュータ実装方法の態様を具現化する（１つまたは複数の）プロセッサ７０２に応答して、１つ以上のコンピューティングデバイスによって提供されてよい。そのような命令は、７２８に示したようなデータ記憶装置７０７または別の（光学、磁気などの）データキャリアなどの別のコンピュータ可読媒体からメモリ７０４に読み込まれてよい。メモリ７０４に含まれる命令のシーケンスを実行すると、（１つまたは複数の）プロセッサ７０２は工程を実行し、本明細書に記載した機能を持つ。代替実施形態では、記載した実施形態を実装するために、ハードワイヤード回路をソフトウェア命令の代わり、またはソフトウェア命令と組み合わせて使用してよい。そのため、実施形態は、ハードウェア回路とソフトウェアとの特定の組み合わせに限定されない。実際、任意の適切なコンピュータシステムで本明細書に記載の機能を実行してよいことを当業者は理解すべきである。コンピューティングデバイスは、所望の機能を実行するように動作する１つまたは複数のマイクロプロセッサを含んでいてよい。１つの実施形態では、その１つまたは複数のマイクロプロセッサによって実行される命令は、（１つまたは複数の）マイクロプロセッサが本明細書に記載の工程を実行するように動作する。命令は、どのようなコンピュータ可読媒体に記憶されてもよい。１つの実施形態では、命令は、マイクロプロセッサの外部の不揮発性半導体メモリに記憶されてもよいし、マイクロプロセッサに組み込まれてもよい。別の実施形態では、命令は、ディスクに記憶され、マイクロプロセッサに実行される前に揮発性半導体メモリに読み込まれてよい。

上記の詳細な説明の一部では、ローカル処理ユニット、ローカル処理ユニット用のメモリ記憶装置、表示装置、および入力装置などのコンピュータ構成要素を備えていてよいコンピューティングデバイスによる動作のプロセスおよび記号表現を説明している。さらに、そのようなプロセスおよび動作では、例えばリモートファイルサーバ、コンピュータサーバ、およびメモリ記憶装置を含む異種の分散コンピューティング環境でコンピュータ構成要素を使用してよい。これらの分散したコンピューティング構成要素は、通信ネットワークを介してローカル処理ユニットにアクセス可能であってよい。

コンピュータによって実行されるプロセスおよび動作は、ローカル処理ユニットおよび／またはリモートサーバによるデータビットを操作することと、１つ以上のローカルまたは遠隔のメモリ記憶装置内にあるデータ構造の中のこれらのビットを維持することとを含む。これらのデータ構造は、メモリ記憶装置内に格納されたデータビットの集合に物理的な編成を課し、電磁スペクトル成分を表す。

本明細書に記載し図示したコンピュータ実装のデータ増強方法のようなプロセスを、総じて、所望の結果につながる一連のコンピュータ実行工程であると定義してよい。これらの工程では、一般に、物理的な量を物理的に操作する必要がある。必ずではないが通常この量は、保存、転送、組み合わせ、比較あるいは操作を行うことのできる電気信号、磁気信号、または光信号の形態であってよい。これらの信号をビットまたはバイト（バイナリ論理レベルを有する場合）、ピクセル値、ワーク、値、要素、記号、文字、用語、番号、点、記録、オブジェクト、画像、ファイル、ディレクトリ、サブディレクトリなどと呼ぶことは当業者には慣例である。ただし、これらの用語および同様の用語は、コンピュータの動作に適切な物理量に関連している必要があり、これらの用語は、コンピュータ内およびコンピュータの動作中に存在する物理量に適用される単なる従来のラベルであることに留意すべきである。

コンピュータ内の操作を、追加、比較、移動、位置決め、配置、照明、除去、変更などの用語で呼ぶことが多いことも理解すべきである。本明細書に記載した動作は、コンピュータと相互作用する人間または人工知能エージェントのオペレータまたはユーザによって提供される様々な入力と合わせて実行される機械動作である。本明細書に記載した動作を実行するために使用される機械として、ローカルまたは遠隔の汎用デジタルコンピュータまたはその他の同様のコンピューティングデバイスがある。

また、本明細書に記載のプログラム、プロセス、方法などは、特定のコンピュータまたは装置に関連するものでも限定されるものでもなく、特定の通信ネットワークアーキテクチャに関連するものでも限定されるものでもないことを理解すべきである。むしろ、様々な種類の汎用ハードウェアマシンを、本明細書に記載の教示に従って構築されたプログラムモジュールと共に使用してよい。同じように、リードオンリーメモリなどの不揮発性メモリに格納されているハードワイヤードロジックまたはプログラムを有する特定のネットワークアーキテクチャ内の専用のコンピュータシステムを介して、本明細書に記載の方法の工程を実行するための特別な装置を構築することが有利であることがわかる可能性がある。

特定の例示的な実施形態を説明したが、これらの実施形態は、単なる例として提示したものであり、本明細書に開示した実施形態の範囲を限定する意図はない。そのため、前述の説明には、特定の特徴、特性、工程、モジュール、またはブロックが必要または不可欠であることを示唆する意図であるものは何もない。実際、本明細書に記載の新規の方法およびシステムは、他の様々な形態で具現化されてよい。さらに、本明細書に開示した実施形態の趣旨から逸脱しないかぎり、本明細書に記載の方法およびシステムの形態には様々な省略、置換および変更を加えてよい。

Claims (21)

1. 分散システムであって、
   複数のサーバノードであって、各サーバノードがクライアントアプリケーションを含み、前記クライアントアプリケーションの状態を変更し、対応する提案を生成するためのクライアント要求を受け取るように構成される、複数のサーバノードと；
   第１バージョンの分散調整エンジン（ＤＣｏｎＥ）であって、前記複数のサーバノードの少なくとも１つに結合し、入力キューで提案を受け取るように構成され、前記第１バージョンのＤＣｏｎＥは、前記提案について合意に達し、第１の順序の合意を前記複数のサーバノードの少なくとも１つに結合している出力キューで出力するようにさらに構成され、前記第１の順序の合意は、前記クライアントアプリケーションが前記第１の順序の合意を構成している合意を実行してそれに応じてそのそれぞれの状態を更新する順序を指定し、前記第１バージョンのＤＣｏｎＥは、バージョン変更提案に関して前記入力キューを監視し、それについて合意に達し、前記バージョン変更提案についての合意を前記出力キューに配置し、それ以降は前記入力キューで前記提案についてそれ以上合意に達しないようにさらに構成される、第１バージョンの分散調整エンジン（ＤＣｏｎＥ）と；
   入力キューおよび前記出力キューに結合している第２バージョンのＤＣｏｎＥであって、前記第２バージョンのＤＣｏｎＥは、前記バージョン変更提案について合意に達した後は、前記入力キューの前記提案について合意に達し、かつ前記バージョン変更提案についての合意から始まる前記出力キューで第２の順序の合意を出力するようにさらに構成され、前記第２の順序の合意は、合意に達した提案を含み、前記クライアントアプリケーションが前記第２の順序の合意を構成している合意を実行してそれに応じてそのそれぞれの状態を更新する順序を指定する、第２バージョンのＤＣｏｎＥと
   を有し、
   各クライアントアプリケーションは、前記バージョン変更提案に対応する前記合意を受け取った後に前記第１バージョンのＤＣｏｎＥから受け取った合意済みの提案を、前記入力キューを介して前記第２バージョンのＤＣｏｎＥに送り返すようにさらに構成される、
   分散システム。
2. 前記第１バージョンのＤＣｏｎＥは、前記複数のサーバノードの各々に対して前記第１バージョンのＤＣｏｎＥのインスタンスを有し、前記第２バージョンのＤＣｏｎＥは、前記複数のサーバノードの各々に対して前記第２バージョンのＤＣｏｎＥのインスタンスを有する、請求項１に記載の分散システム。
3. 前記第１バージョンおよび第２バージョンのＤＣｏｎＥは、コンピュータネットワークを介して前記複数のサーバノードに結合される、請求項１に記載の分散システム。
4. 前記第１バージョンのＤＣｏｎＥは、前記バージョン変更提案に対応する前記合意が達成された後に前記第１バージョンのＤＣｏｎＥが有効な提案についての合意に達し終えた後、オフにされる、請求項１に記載の分散システム。
5. 前記第１の順序の合意および第２の順序の合意の各合意は、
   提案と；
   前記提案について合意に達した前記ＤＣｏｎＥのバージョン番号およびバージョンシーケンス番号を含む、グローバルシーケンス番号（ＧＳＮ）と
   を含む、請求項１に記載の分散システム。
6. 各々の前記クライアントアプリケーションは、ＧＳＮが所定のバージョン番号と一致するバージョン番号を含んでいる提案のみを実行するように構成される、請求項５に記載の分散システム。
7. 前記所定のバージョン番号は、前記第１バージョンのＤＣｏｎＥと前記第２バージョンのＤＣｏｎＥから選択される、請求項６に記載の分散システム。
8. 前記提案は、前記クライアントアプリケーションの状態を変更するためのアプリケーション提案の少なくとも１つ、および前記第１または第２バージョンのＤＣｏｎＥを制御するかその構成を変更するように構成されているＤＣｏｎＥ制御提案を含む、請求項１に記載の分散システム。
9. 前記第２バージョンのＤＣｏｎＥは、
   前記第１バージョンのＤＣｏｎＥを制御するか構成するように構成された制御提案を拒否すること；
   前記第１バージョンのＤＣｏｎＥを制御するか構成するように構成された制御提案を受け入れ、それについて合意に達すること；および
   前記第１バージョンのＤＣｏｎＥを制御するか構成するように構成された制御提案を、前記第２バージョンのＤＣｏｎＥを制御するか構成するように構成された、意味の上ではほぼ同じである制御提案に入れ替えること
   のうちの１つを行うようにさらに構成される、請求項８に記載の分散システム。
10. 複数のサーバノードのクライアントアプリケーションの一貫性を維持するコンピュータ実装方法であって、
    前記複数のサーバノードの少なくとも１つに結合している第１バージョンの分散調整エンジン（ＤＣｏｎＥ）を提供し、前記第１バージョンのＤＣｏｎＥでは：
    入力キューで提案を受け取り、前記提案について合意に達し、前記複数のサーバノードの前記少なくとも１つに結合している出力キューで第１の順序の合意を出力し、前記第１の順序の合意は、前記クライアントアプリケーションが前記第１の順序の合意を構成している合意を実行してそれに応じてそのそれぞれの状態を更新する順序を指定し、；かつ
    バージョン変更提案に関して前記入力キューを監視し、前記バージョン変更提案について合意に達し、前記バージョン変更提案についての合意を前記出力キューで出力し、それ以降に前記入力キューで前記提案についてそれ以上合意に達成するのを停止し；
    前記複数のサーバノードの少なくとも１つに結合している第２バージョンのＤＣｏｎＥを提供し、前記第２バージョンのＤＣｏｎＥでは：
    前記バージョン変更提案に対応する合意を前記出力キューに出力した後、前記入力キューで前記提案について合意に達し、前記バージョン変更提案に対応する合意から始まる前記出力キューで第２の順序の合意を出力し、前記第２の順序の合意は、合意に達した提案を含み、前記クライアントアプリケーションが前記第２の順序の合意を構成している合意を実行してそれに応じてそのそれぞれの状態を更新する順序を指定し、
    前記バージョン変更提案についての合意を受け取った後に前記第１バージョンのＤＣｏｎＥから受け取った合意済みの提案を、前記入力キューを介して前記第２バージョンのＤＣｏｎＥに送り返して、前記第２バージョンのＤＣｏｎＥがそれについて合意に達することができるようにする
    ことを含む、コンピュータ実装方法。
11. 前記バージョン変更提案に対応する前記合意が達成された後に前記第１バージョンのＤＣｏｎＥが有効な提案について合意に達し終えた後、前記第１バージョンのＤＣｏｎＥをオフにすることをさらに含む、請求項１０に記載のコンピュータ実装方法。
12. 前記第１の順序の合意および第２の順序の合意の各合意は、
    提案と；
    前記提案について合意に達した前記ＤＣｏｎＥのバージョン番号およびバージョンシーケンス番号を含む、グローバルシーケンス番号（ＧＳＮ）と
    を含む、請求項１０に記載のコンピュータ実装方法。
13. 各々の前記クライアントアプリケーションを、ＧＳＮが所定のバージョン番号と一致するバージョン番号を含んでいる提案のみを実行するように構成することをさらに含む、請求項１２に記載のコンピュータ実装方法。
14. 前記所定のバージョン番号を、前記第１バージョンのＤＣｏｎＥから前記第２バージョンのＤＣｏｎＥに変更することをさらに含む、請求項１３に記載のコンピュータ実装方法。
15. 合意済みの提案を前記第２バージョンのＤＣｏｎＥに送り返すことは、前記クライアントアプリケーションのうちの１つによって実行される、請求項１０に記載のコンピュータ実装方法。
16. 前記提案は、前記クライアントアプリケーションの状態を変更するためのアプリケーション提案の少なくとも１つと、前記第１または第２バージョンのＤＣｏｎＥを制御するかその構成を変更するように構成されているＤＣｏｎＥ制御提案を含む、請求項１０に記載のコンピュータ実装方法。
17. 前記第２バージョンのＤＣｏｎＥが、
    前記第１バージョンのＤＣｏｎＥを制御するか構成するように構成された制御提案を拒否すること；
    前記第１バージョンのＤＣｏｎＥを制御するか構成するように構成された制御提案を受け入れ、それについて合意に達すること；および
    前記第１バージョンのＤＣｏｎＥを制御するか構成するように構成された制御提案を、前記第２バージョンのＤＣｏｎＥを制御するか構成するように構成された、意味の上ではほぼ同じである制御提案に入れ替えること
    のうちの１つを行うことをさらに含む、請求項１６に記載のコンピュータ実装方法。
18. 複数のサーバノードでクライアントアプリケーションの一貫性を維持するコンピュータ実装方法であって、
    第１バージョンの分散調整エンジン（ＤＣｏｎＥ）を提供することと；
    前記第１バージョンのＤＣｏｎＥで、提案について合意に達し、前記クライアントアプリケーションが前記第１バージョンのＤＣｏｎＥで合意した提案を実行してそれに応じてそのそれぞれの状態を更新する順序を指定する第１の順序の合意を生成することと；
    第２バージョンのＤＣｏｎＥを提供することと；
    前記第１バージョンのＤＣｏｎＥでバージョン変更提案について合意に達することと；
    前記バージョン変更提案について合意に達した後、前記第２バージョンのＤＣｏｎＥで提案について合意に達するのを停止し、前記クライアントアプリケーションが前記第２バージョンのＤＣｏｎＥで合意した前記提案を実行してそれに応じてそのそれぞれの状態を更新する順序を指定する第２の順序の合意を生成することと；
    前記バージョン変更提案について合意に達した後に前記第１バージョンのＤＣｏｎＥから受け取った合意済みの提案を、前記第２バージョンのＤＣｏｎＥに送り返して、前記第２バージョンのＤＣｏｎＥがそれについて合意に達することができるようにすることと
    を含む、コンピュータ実装方法。
19. 前記バージョン変更提案に対応する前記合意が達成された後に前記第１バージョンのＤＣｏｎＥが有効な提案について合意に達し終えた後、前記第１バージョンのＤＣｏｎＥをオフにすることをさらに含む、請求項１８に記載のコンピュータ実装方法。
20. 前記提案は、前記クライアントアプリケーションの状態を変更するためのアプリケーション提案の少なくとも１つと、前記第１または第２バージョンのＤＣｏｎＥを制御するかその構成を変更するように構成されているＤＣｏｎＥ制御提案を含む、請求項１８に記載のコンピュータ実装方法。
21. 前記第２バージョンのＤＣｏｎＥが、
    前記第１バージョンのＤＣｏｎＥを制御するか構成するように構成された制御提案を拒否すること；
    前記第１バージョンのＤＣｏｎＥを制御するか構成するように構成された制御提案を受け入れ、それについて合意に達すること；および
    前記第１バージョンのＤＣｏｎＥを制御するか構成するように構成された制御提案を、前記第２バージョンのＤＣｏｎＥを制御するか構成するように構成された、意味の上ではほぼ同じである制御提案に入れ替えること
    のうちの１つを行うことをさらに含む、請求項２０に記載のコンピュータ実装方法。

Images