JP3706531B2

JP3706531B2 - 分散コンピュータ・システム内のプロセッサを再構成する方法

Info

Publication number: JP3706531B2
Application number: JP2000257264A
Authority: JP
Inventors: ケニス・シー・ブリスキー; マルコス・エヌ・ノヴァクス
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1999-08-31
Filing date: 2000-08-28
Publication date: 2005-10-12
Anticipated expiration: 2020-08-28
Also published as: JP2001109726A; KR100387700B1; KR20010050140A; US6490693B1

Description

【０００１】
【発明の属する技術分野】
本発明は、分散コンピューティング・システムに関し、具体的には、分散コンピューティング・システム内のプロセッサのクォーラム・グループの動的再構成と、動的再構成中に使用不能であったグループの１つまたは複数のプロセッサの回復手順に関する。
【０００２】
【関連する出願】
本特許出願には、以下の特許出願の内容に関する内容が含まれる。以下の特許出願は、本特許出願と同一の譲受人に譲渡され、本特許出願と同一の日付（１９９９年８月３１日）に出願された。下記の特許出願は、本明細書に関連する。
米国特許出願第０９／３８７１８５号明細書（出願人整理番号第ＰＯ９−９９−１３１号）
米国特許出願第０９／３８６５４９号明細書（出願人整理番号第ＰＯ９−９９−１３２号）
米国特許出願第０９／３８７１８８号明細書（出願人整理番号第ＰＯ９−９９−１３３号）
【０００３】
【従来の技術】
分散コンピューティング・システムでは、複数の処理要素が使用される。これらの処理要素は、ネットワーク内で互いにリンクされた個々のプロセッサ、または調整された環境で並列に動作する複数のソフトウェア・インスタンスとすることができる。前者の場合、プロセッサは、ネットワーク・プロトコルをサポートするネットワークを介して互いに通信する。このプロトコルは、ハードウェア構成要素とソフトウェア構成要素の組合せを使用することによって実施することができる。処理要素は、通常は、共通のインターフェースを介してメッセージまたはパケットを送受することによって互いに通信する。分散コンピューティング・システムの１種が、処理要素が記憶域を共用しない、非共用分散システムである。そのようなシステム内では、要素は、分散システムの状態について合意するためにメッセージを交換しなければならない。
【０００４】
したがって、非共用分散処理システム内では、メッセージ交換プロトコルが必要である。たとえば、メッセージ交換プロトコルでは、分散処理システム内のデータベースの現在の状態の問題を解決しようとする。具体的に言うと、プロトコルでは、どの処理要素が最新版のデータベースを有するかを定義する必要がある。というのは、処理要素が異なる版のデータベースを作成する可能性があるからである。周知の通り、高可用性システムでは、システムが処理の実行を継続している間に、１つまたは複数の処理要素が、使用不能になることが許容される。したがって、データベースは、高可用性分散処理ステム内では、１つまたは複数の処理要素が使用不能（たとえばオフ・ライン）の間に変更される可能性がある。前に使用不能であった処理要素が使用可能になった時に、更新された版のデータベースを、その処理要素に供給しなければならない。
【０００５】
従来の非共用分散処理システムは、クォーラム駆動回復に参加する処理要素のグループが静的でなければならないという制限を有する。すなわち、サーバ・グループが定義された後には、動的にすなわち、データベースが走行しており１つまたは複数のメンバが潜在的に使用不能である間に、メンバを追加または削除することができない。従来の非共用分散処理システムで再構成変更を行う唯一の方法は、再定義動作を使用することであるが、この再定義動作は、システムの全サーバでの構成ファイルの変更を必要とし、したがって、再構成変更のためにすべてのサーバが現在使用可能であることを必要とする。
【０００６】
【発明が解決しようとする課題】
上記にもかかわらず、データベース・サーバなどの高可用性分散処理システムの場合には、サーバのグループの全サーバが使用可能であることを必要とせずに、サーバの追加または削除を可能にすることが望ましいと考えられる。
【０００７】
【課題を解決するための手段】
本明細書で提供する分散サーバ回復手順（ＤＳＲＰ）は、サーバ・グループの構成のこの変更を可能にするために、現在定義されているサーバの過半数（クォーラム）が変更の進行のために使用可能であることだけを必要とする。たとえば、いくつかのサーバを、それがダウンしている間に構成解除（グループから排除）することができ、他のサーバを追加することができる。１つまたは複数のサーバが使用不能である間にサーバを追加または削除する処理を、本明細書ではプロセッサのクォーラム・グループの「動的再構成」と呼称する。やはり、分散サーバの回復のための従来の手順は、静的構成環境を必要とする。
【０００８】
要約すると、本明細書では、一態様で、高可用性分散コンピューティング・システム内のプロセッサを再構成するクォーラム・ベースの方法を提供する。この方法は、プロセッサのクォーラム・グループ内のクォーラムの存在を識別するステップと、前記プロセッサのクォーラム・グループの少なくとも１つのプロセッサが使用不能である間に前記プロセッサのクォーラム・グループを動的に再構成するステップとを含み、前記動的再構成が、前記少なくとも１つのプロセッサの使用不能性にもかかわらず、前記プロセッサのクォーラム・グループの前記クォーラムのプロセッサの存在と共に進行する。
【００１０】
言い直すと、本明細書で提供するのは、グループの１つまたは複数のプロセッサが使用不能であるにもかかわらず、プロセッサのクォーラム・グループを動的に再構成する再構成機能ならびに、１つまたは複数の以前には使用不能であったプロセッサが使用可能になった時にグループのプロセッサによって実施される回復手順である。１つまたは複数のプロセッサが使用不能である間にプロセッサのグループを動的に再構成できるようにすることによって、システム管理者は、１つまたは複数のプロセッサが使用不能になった場合であっても、クォーラム個のプロセッサが残っているならば、クリティカルなシステムが維持されることを保証できる。したがって、本明細書の記載の動的再構成機能および回復手順は、高可用性分散コンピューティング環境でのより高い柔軟性をもたらす。本明細書に記載の回復手順などのクォーラム・ベースの動作と共に使用するための、緩和されたクォーラムの計算も提示する。
【００１１】
【発明の実施の形態】
本発明によって解決される問題は、データベース・サーバなどの分散高可用性処理システムの動的再構成および回復の問題である。そのようなシステムの高可用性特性によって、そのようなシステムは、サーバ・グループのいくつかの対等サブシステムが使用可能でない時でも、機能することができる。本明細書ではデータベース・サーバに関して一実施形態で説明するが、当業者は、本明細書に記載の概念が、複数の処理要素を有する分散処理システムのプロセッサのどのグループにも適用可能であることを理解するであろう。本発明の文脈では、プロセッサは、個々のプロセッサまたはソフトウェアで実施される処理インスタンスを含む処理要素を意味する。本明細書で論ずるデータベース・サーバは、プロセッサのグループの１例としてのみ提示される。
【００１２】
本明細書で仮定されるシステムの高可用性特性のゆえに、いくつかのプロセッサが、分散データベースに対する更新を取り逃がす可能性があり、再び使用可能になった時に回復手順を受ける必要が生じる。通常、回復手順には、「インカーネーション番号」とも呼ばれる、データベースのバージョン番号の検査が含まれる。回復は、本発明によれば、サーバ・サブシステムの構成自体が変更されている、すなわち、そのシステムが、「動的再構成」を受けている可能性があるという事実によって複雑になる。本明細書で提示される分散サーバ回復手順（ＤＳＲＰ）は、そのような場合の回復の問題を解決し、したがって、この動的再構成の進行を可能にする。
【００１３】
この開示の用語「構成」は、具体的には、分散システムのメンバのリストを指す。典型的な分散システムは、ネットワーク内に存在する使用可能なプロセッサのプールからプロセッサを選択し、それらを一緒にグループ化することによって構成される。通常、ネットワーク内のプロセッサの数は、所与の分散システム内の数よりはるかに多い。その１例が、同一のネットワーク内で相互接続される複数のコンピュータ（プロセッサ）を有する大学キャンパスである。ネットワーク内に存在するプロセッサのサブセットを、「分散システム」にグループ化することが望ましいことがしばしばである。分散システムは、さまざまな形で協力し、それらの間でタスクを分散することができる計算機の組として定義される。たとえば、ネットワークに１００台のプロセッサがある場合、それらを一緒に組み合わせることによって、任意の数の分散システムを構成することができる。たとえば、それぞれ１０プロセッサの１０個のシステム、またはそれぞれ５プロセッサの２０個のシステム、または他の組合せを作成することができる。この「構成」の重要な態様が、どのプロセッサが特定のグループの一部であるかのリストである。このリストによって、同一のグループに参加するメンバの組が定義され、この決定は、グループの他のメンバからの要求の受入れまたは拒絶を正しく行うために必要である。グループのメンバは、所与のどの時点でも、このリストが一貫性があることに合意しなければならない。すなわち、分散システムのすべてのノード（プロセッサ）が、このリストの正確に同一のコピーを有することが必要である。
【００１４】
この開示で提示される特定の技術は、プロセッサのグループのメンバが、それが有するリストが正確であるかどうか、または、グループの別のメンバから更新されたリストを得る必要があるかどうかを検証できるようにする方法である。本発明は、生成されるリストのそれぞれに特定の「インカーネーション番号」を付加することによってこの目的を達成する。このインカーネーション番号は、プロセッサ・グループのメンバのリストに対する変更が、少なくとも現在のグループのメンバの「クォーラム（過半数）」に対して行われることを保証することによって維持される。リストの変更が発生するのは、分散システムのユーザが、グループにプロセッサを追加または削除することによって構成を変更する時である。リストが、メンバ・プロセッサの追加または削除によって変更される時には、インカーネーション番号が増分される。
【００１５】
分散システムのユーザが、構成の変更を要求する時には、その変更は、次のように行うことができる。要求を受け取ったグループのメンバが、その要求のコピーを他のすべてのメンバに送り、それ自体の構成変更を行う。変更の動作には、リスト内で変更を行うことと、インカーネーション番号の更新が含まれる。その後、そのメンバは、グループの他のメンバの応答を待つ。クォーラム個のメンバが成功メッセージで応答する場合には、元の要求を受け取ったメンバは、構成変更を要求したユーザに肯定のコードを返す。そうでない場合には、エラーが返される（図１０参照）。エラーが返された場合には、分散システムのユーザは、システムを再定義しなければならず（上で説明したように）、したがって、動的回復は不可能である。しかし、戻りコードが成功である場合には、再構成が成功したことが保証され、リストは、クォーラム個のノードで一貫性を有することが保証される。
【００１６】
通常の分散システムは、構成の変更のすべてが、システム内のすべてのノードに対して行われることを必要とする。本発明は、変更をクォーラム個のノードだけに対して行うことを必要とすることによって、構成変更の要件を緩和する。これによって、メンバ・ノードが再構成動作のために使用可能でない場合であっても、分散システムの構成を変更することが可能になる。
【００１７】
回復のシナリオでは、処理要素が、システムの最新の状態、たとえばデータベースの最新版を突きとめるために、インカーネーション番号を交換する。システム・データに対する変更（およびインカーネーション番号の増分）は、クォーラム個（過半数）のレジストリ・プロセッサが使用可能である時に限って許可され、従来のクォーラム・アルゴリズム（すなわち、静的グループ構成）は、単純なアルゴリズムである。従来は、過半数のサーバが使用可能であることと、最も高いインカーネーション番号を有するサーバが、データベースの最も最近に更新された版を有すると保証されることで十分である。しかし、このアルゴリズムは、クォーラム駆動回復に参加するグループが静的でなければならないという制約を有する。すなわち、サーバ・グループを定義した後には、メンバを動的に追加または削除することができない。やはり、動的とは、本明細書では、データベースが走行中であり、潜在的に使用不能なグループのメンバが１つまたは複数存在することを意味するように定義されている。従来の形で再構成変更を行う唯一の方法は、再定義動作を使用することであるが、これは、すべてのサーバの構成ファイルに対する変更を必要とし、したがって、再構成変更のためにすべてのサーバが使用可能であることを必要とする。
【００１８】
高可用性コンピューティング・システムの場合、本出願人は、すべてのメンバが使用可能であることを必要とせずに、グループへのプロセッサの追加および削除を可能にすることが望ましいと考える。図１ないし５に、グループの１つまたは複数のメンバが使用不能である場合のクォーラム・グループへの変更を扱うことの困難さを説明するのに役立つ、全体的に符号１０で示される分散処理システムのさまざまな状態を示す。図１では、分散処理システム１０に、３つのサーバが含まれる。この図が、サーバ・グループの初期構成を表すと仮定する。このグループは、グループ・インカーネーションが１であり、サーバ１、サーバ２、およびサーバ３と名付けられた３つのサーバがグループに存在するように構成されたばかりである。このグループには３つのメンバが存在するので、グループ・クォーラムは、３の過半数の２である。
【００１９】
本発明のＤＳＲＰによって解決される問題を示すために、サーバ１が使用不能になり、たとえば電源を切断されたと仮定する。残りの２つのサーバは、稼動状態のままであり、したがって、グループは、まだ変更を可能にするクォーラムを有する。さらに、管理者が、サーバ１がダウンしたことに気付き、将来の障害に対する保護のために新しいサーバを定義することを所望すると仮定する。管理者は、ここでは、サーバ４、サーバ５、およびサーバ６という番号の３つの追加のサーバを定義すると仮定する。サーバ１は、その時点で電源を切断されているので、その内部状態は変更されない。この分散システムの新しい状態を、図２に示す。グループ・インカーネーション２という符号を付けられたこの新しい状態では、各アクティブ・サーバすなわち、サーバ２、サーバ３、サーバ４、サーバ５、およびサーバ６のメンバ・リストに、サーバ１が含まれ、６台のサーバの過半数は４であるから、グループ・クォーラムは４になる。
【００２０】
ここで、システム管理者が、サーバ１を定義解除することを決定したと仮定する。定義解除動作も、メンバシップ変更であり、したがって、グループ・インカーネーションが３に増分され、図３に示された状態がもたらされる。サーバ１を定義解除することによって、グループのクォーラムは３（５の過半数）になり、これによって、このシステムは、２つの障害に耐え、なおかつクォーラムを維持することが可能になる。図４および５を、サーバ・メンバがダウンしている時にＤＳＲＰが構成変更に対処するさまを示すために提示する。図４では、サーバ２およびサーバ３が使用不能になり、新しいサーバ７が定義されたと仮定する。その結果の状態を、図４に示す。
【００２１】
図４からわかるように、グループ・クォーラムは、現在は４（６の過半数）である。この時点でグループ内の走行中のメンバは正確に４つであり、したがって、このグループはまだクォーラムを有する。次に、管理者が、メンバのサーバ２およびサーバ３を定義解除し、サーバの総数を４に減らしたと仮定する。この場合、グループ・クォーラムは３になる。このシステムは、やはりメンバの１つの障害に耐えることができる。結果の状態（グループ・インカーネーション５）を図５に示す。この最終状態の例は、下で説明するＤＳＲＰアルゴリズムの追跡の開始点である。
【００２２】
図５の状態に到達するために行われた「動的」構成変更は、いくつかのサーバがダウンしている間に行われたので、このシステムの状態は矛盾している。ダウンしていたサーバが、ここで電源を投入されたと仮定する。図５から、サーバ１が最も古い状態を有することは明らかである。サーバ１のグループ・メンバシップには、グループの現在の数値が全く含まれないことに留意されたい。本明細書で提示するＤＳＲＰの目的は、サーバ１が、現在のグループのメンバを発見でき、したがって、それらの１つから最新の構成を読み取る（または受け取る）ことができるようにする探索手順を提供することである。この探索は、終了条件がＴＲＵＥと評価されるか、現在のグループのアクティブ・メンバから探索停止メッセージを受け取るまで行われなければならない。終了条件は、探索を行うサーバが、同一のインカーネーション番号に同意するクォーラム個のメンバを発見した時に、探索が完了したことを表す。図９に関して提示するように、探索終了条件は、いくつかの場合に緩和（クォーラム−１）することができる。
【００２３】
動的再構成を可能にする回復手順によって解決される主要な課題は、古くなったサーバの回復手順である。サーバは、潜在的に、もはやサーバ・グループのメンバの正確なリストを有しなくなるほどの長期間にわたってダウンしていた可能性がある。複数のメンバが、もやはメンバとして定義されていない場合がありえる。また、問題のサーバが、使用不能になった後に他の稼動し続けているメンバによって定義解除されている場合もありえる。本明細書で提示する分散サーバ回復手順は、そのような古くなったサーバが、データベースの最新のコピーにアクセスでき、それ自体を更新できるようにする分散通信プロトコルである。
【００２４】
ＤＳＲＰアルゴリズムは、サーバ・グループの状態の持続記憶に基づく。この状態は、インカーネーション番号と、このインカーネーション番号「に投票した」すなわち、それを増分するコミット処理に参加したメンバのリストからなる。ＤＳＲＰアルゴリズムを、具体的な例を用いて下で説明する。図５に示された例では、回復の前のサーバ・グループの状態のスナップショットが示されている。この状態は、すべてのメンバで一貫しているわけではない。というのは、メンバの一部（小さいインカーネーション番号を持つメンバ）が、更新を失ってきたからである。
【００２５】
ここで、データベースの最新のコピーをとり出すためにＤＳＲＰアルゴリズムによって行われるステップを追跡することができる。上のシナリオでは、サーバ１がもはやデータベース・サーバでなくなっているが、サーバ１は、データへのアクセスに必要な他のクリティカルなアプリケーションをホストする可能性があることに留意されたい。ここで追跡するステップは、サーバ１から始まる、図６ないし９に示された本発明のＤＳＲＰアルゴリズムの実施形態に従うものである。しかし、全体的な障害の場合（たとえば、上のシナリオでクラスタがリブートされた場合）には、ＤＳＲＰアルゴリズムは、現在の状態からそれがサーバであることが示される（この情報が古いものである可能性はあるが）すべてのノードで走行することに留意されたい。
【００２６】
サーバ１から始まるステップは、次の通りである。１）サーバ１が、その持続状態を読み取る。その後、サーバ１は、現行サーバ・メンバ・リストの対等サーバに連絡し、インカーネーション番号を取り出そうとする。サーバ１は、サーバ２がより大きいインカーネーション番号（３）を有することに気付き、したがって、サーバ１のサーバ・メンバ・リストが古いことを知る。その後、サーバ１は、サーバ２からサーバ・リストを取り出し、新しい探索にそれを使用する。２）前のステップで取り出したリストを使用して、サーバ１は、新しいリストのメンバに関して同一のプロトコルを実行する。サーバ１は、サーバ３に連絡することから始める。サーバ１は、サーバ３がサーバ２と同一のインカーネーション番号（３）を有することに気付く。この時点で、サーバ１は、同一のインカーネーションを有する２つのサーバ（サーバ２およびサーバ３の両方がインカーネーション３である）について知る。しかし、インカーネーション３に関連するクォーラムは３であるから、サーバ１は、探索を終了するためにはこのレベルのサーバをもう１つ見つける必要がある。３）サーバ１は、今度はサーバ４に連絡し、その状態を取り出す。サーバ１は、悪いニュースを知る。すなわち、サーバ４は、より高いインカーネーション番号（５）であり、したがって、サーバ１は、サーバ２およびサーバ３も古いことを知る。サーバ１は、サーバ４から取り出した状態を使用して探索を継続する。４）サーバ１は、ここで、新たに取り出したメンバ・リスト内の次の未訪問のサーバ（サーバ５）に連絡する。サーバ１は、サーバ５もインカーネーション５であることに気付く。この時点で、サーバ１は、２つのサーバがインカーネーション５であることを知っているが、インカーネーション５に関連するクォーラムは３（４の過半数）であり、したがって、サーバ１はもう１つの確認を必要とする。
【００２７】
一実施形態では、本明細書で提示されるＤＳＲＰアルゴリズムによって、いくつかの場合にクォーラム要件の緩和が可能になる。この場合、たとえば、サーバ１は、同一のインカーネーションを有し、４個のグループの一部である２つのサーバ（サーバ４およびサーバ５）を知っている。この知識は、探索を終了するのに十分である。というのは、残りの２つのメンバ（サーバ６およびサーバ７）が、データベースでの変更には厳密なクォーラム（４の過半数すなわち３）が必要なので、より高いインカーネーション番号を有することができないからである。したがって、サーバ６およびサーバ７が、グループ内の少なくとも１つの他のサーバ（サーバ４またはサーバ５）の参加なしで構成変更を行うことは不可能であったはずである。サーバ４およびサーバ５の状態が既知なので、サーバ１は、データベースの最新のインカーネーションが５であると仮定しても安全であり、探索を終了する。サーバ１のクライアント・アプリケーションは、サーバ４またはサーバ５のいずれかからの最も最近に更新されたデータベースのコピーにアクセスすることができる。
【００２８】
図６ないし９に、本発明の原理に従って実施される動的サーバ回復手順（ＤＳＲＰ）アルゴリズムの流れ図実施形態を示す。具体的に言うと、図６は、各サーバが対等サブシステム（すなわち、プロセッサのクォーラム・グループ内の他のプロセッサ）からのメッセージを継続的に聴取する、動的サーバ回復手順を示す図である。プロセッサは、その状態を更新する時に、受け取るメッセージのそれぞれについて図７および８のprocess_message_procedure（メッセージ処理プロシージャ）を実行する。process_message_procedureは、クォーラム番号変数とインカーネーション変数を、探索を終了させるのに適当な状態に設定し、サーバのクォーラムに関する探索に使用される現行プロセッサ・リストも変更する。各反復の終りに、プロセッサは、現行探索リストの対等サブシステムに、最新のインカーネーション番号と現行探索リスト自体を送る。図９は、本発明の原理に従って「緩和された」クォーラム数を判定する処理の一実施形態を示す図である。
【００２９】
図６からわかるように、ＤＳＲＰ処理は、プロセッサのクォーラム・グループ内のプロセッサの始動または再始動（１００）から開始される。my_incarnation（インカーネーション）およびcurrent_search_list（現行探索リスト）を含む変数を初期設定する（１１０）。その後、クォーラムが達成されたかどうかに関する質問を行う（１２０）。そうでない場合には、この手順（サーバのグループの再始動されたサーバのそれぞれで実施される）は、メッセージを別のグループ・メンバから受け取ったかどうかを判定する（１３０）。そうでない場合には、そのサーバは、その現行サーバ・リストおよびインカーネーション番号を含むメッセージを、グループ内の他のサーバのそれぞれに送る（１４０）。その後、処理は、クォーラムが達成されたかどうかの質問（１２０）に戻る。
【００３０】
メッセージがそのサーバで受け取られている場合には、サーバは、下で説明する、図７および８のprocess_message_procedureを実行する（１５０）。process_message_procedureルーチンは、ＴＲＵＥまたはＦＡＬＳＥのいずれかの値を返す。したがって、ＤＳＲＰは、process_message_procedureがＴＲＵＥの値を返したかどうかを判定する（１６０）。そうでない場合には、動的サーバ回復手順が続行し（１７０）、ループ・バックして、サーバに、その現行探索リストの対等サブシステムのそれぞれに、その現行サーバ・リストとインカーネーション番号を送らせる（１４０）。process_message_returnの値がＴＲＵＥである場合には、この処理は、サーバの現行探索リストのすべての対等サブシステムにStopSearch（探索停止）メッセージを送り（１８０）、これによって処理を完了する（１９０）。
【００３１】
動的サーバ回復手順の始めに戻って、クォーラムが存在する（たとえば、プロセッサのクォーラム・グループの１つまたは複数のアクティブ・メンバから探索停止メッセージを受け取った）場合（１２０）、回復手順は完了する（１９０）。
【００３２】
図７および図８のprocess_message_procedureは、以下のフィールドを含むメッセージ・データ型を使用する。
主ＩＰアドレス：送出元の連絡アドレス
バックアップＩＰアドレス：第１のアドレスの障害時に使用するバックアップ連絡アドレス
incarnation：送出元が発見した最新のインカーネーション番号
server_list：送出元が発見した最新の探索リスト
【００３３】
メッセージのフィールドは、流れ図では、「．」演算子を使用して示される。たとえば、msg.incarnationは、メッセージのincarnationフィールドを指す。
【００３４】
process_message_procedureでは、サーバが受け取った、最も高いインカーネーションを有するメッセージのカウントが保存される。このルーチンは、このカウントを「緩和された」クォーラム要件と比較するが、「緩和された」クォーラム要件は、一実施形態では図９のcalculate_quorumプロシージャから計算される。図７および８のプロシージャは、クォーラム要件が達成されたと判定した時に、ＤＳＲＰタスクを終了するのに適当な値をセットする。そうでない場合には、このルーチンは、カウンタおよび探索リストを更新し、探索を続ける。
【００３５】
図７および８を参照すると、本発明の原理によるprocess_message_procedureの一実施形態は、受け取ったメッセージを読み取ることによって開始され（２００）、その後、メッセージのstop_search（探索停止）フィールドがＴＲＵＥであるかどうかを判定する（２１０）。そうである場合には、メッセージの送出元に連絡して、たとえば送出元のデータベースのコピーを用いて、データベースを更新し、送出元のインカーネーション番号を用いてインカーネーション番号を更新する（２２０）。その後、ＴＲＵＥのprocess_message_return値を、図６の動的サーバ回復手順に返す（２３０）。
【００３６】
メッセージのstop_searchフィールドが真でないと仮定すると、このプロシージャは、msg.incarnationをmy_incarnationと比較する（２４０）。この比較は、３つの可能な結果を有する。第１に、msg.incarnationとmy_incarnationが等しい場合（２５０）、counter（カウンタ）の値を増分し、クォーラム数を計算する（２６０）。「緩和された」クォーラム数を計算するための実施形態の１つを、図９に示す（下で説明する）。クォーラムを決定した後に、counterの値がクォーラム値以上であるかどうかを判定する（２７０）。そうである場合には、動的サーバ回復プロセスにＴＲＵＥの値を返す（２８０）。そうでない場合には、ＦＡＬＳＥの値を返し（２９０）、処理が完了する。
【００３７】
メッセージ・ヘッダのインカーネーション値（msg.incarnation）が、サーバのインカーネーション値より大きい場合（３１０）、サーバの現行探索リストを、メッセージと共に受け取った探索リストに置換し、counterに１をセットし、サーバのインカーネーション値を、メッセージと共に受け取ったインカーネーション番号を用いて更新する（３２０）。その後、counter値がクォーラム数以上であるかどうかを問合せ（２７０）、上で説明したように処理が進行する。受け取ったインカーネーション番号がサーバのインカーネーション番号未満の場合（３３０）、メッセージ送出元をサーバのインアクティブ・サーバ・リストに追加し、メッセージ送出元をアクティブ・サーバ・リストから削除し、たとえば図９のプロシージャを使用して、クォーラムの値を計算する（２４０）。クォーラム数を計算した後に、処理がリターンして、counter値がクォーラム数より大きいかどうかを判定し（２７０）、上で説明したように進行する。
【００３８】
過半数を使用することの代替案として、クォーラムを、図９に示されているように計算することができる。このプロシージャでは、現在の探索リストでクォーラムを達成するのに十分な応答を受け取ったかどうかを判定するために必要な、応答の最少数を計算する。集合Ｓには、現行探索リストで定義されているすべてのレジストリ・サーバが含まれる。集合Ｉには、より低いインカーネーション番号を応答し、したがって、探索から排除されるサーバが含まれる。集合Ｎは、Ｓ−Ｉとして定義され、Ｓに関するＩの補集合である。これは、応答が受け取られなかったメンバまたは現行のインカーネーション番号を応答したメンバを識別する集合である。条件｛Ｓ−Ｉ＞ｑ｝がＴＲＵＥの場合、クォーラム要件から１を減算することが可能であり、クォーラム要件は、集合Ｎの過半数として与えられる。演算子maj<>は、オペランドを２で割り、小数部を捨て、結果に１を足すことによって計算される。
【００３９】
図９を参照すると、「緩和された」クォーラムを計算するためのプロシージャの１つは、変数Ｓ、Ｉ、Ｎ、およびｑをセットすること（４１０）によって開始される（４００）（やはり、本明細書で使用される変数Ｓは、クォーラム・グループ内で定義されているサーバの数を表し、Ｉは、グループ内のインアクティブ・サーバの数を表し、Ｎは、グループ内のアクティブ・サーバの数を表し、ｑは、定義されているサーバの数の過半数である）。その後、定義されているサーバの数からインアクティブ・サーバの数を引き、１を引いた値が、定義されているサーバの数の過半数であるかどうかを判定する（４２０）。そうである場合には、変数「Ｕ」に１をセットし（４３０）、そうでない場合には、この値に０をセットする（４４０）。process_message_procedureに返されるクォーラム数Ｑは、アクティブ・サーバの数の過半数から変数Ｕを引いた値に等しい。当業者は、上に要約したクォーラム計算を、他のクォーラム・ベースのシステム計算と組み合わせて使用することができることを理解するであろう。さらに、本明細書で提示する動的サーバ回復手順は、図９の「緩和された」過半数ではなく、従来のクォーラム「過半」数を使用することができる。
【００４２】
本明細書で示した流れ図は、例として提供される。これらの図面または本明細書に記載のステップ（または動作）に対する、本発明の主旨から逸脱しない変形形態がありえる。たとえば、いくつかの場合に、ステップを異なる順序で実行することができ、ステップを追加、削除または変更することができる。これらの変形形態のすべてが、請求項に記載の本発明の一部を構成するとみなされる。
【図面の簡単な説明】
【図１】３サーバ・システムのグループ・クォーラムが２であることを示す、最初の状態（本明細書ではインカーネーション１と呼称する）の３サーバ分散処理システムを示す図である。
【図２】サーバ２およびサーバ３と、新しいサーバ４、サーバ５およびサーバ６を含み、サーバ１が使用不能である、新しいグループ・インカーネーション２の、図１の分散処理システムを示す図である。
【図３】サーバ１がクォーラム計算のために定義解除され、これによって新しいグループ・クォーラムが３になる、新しいグループ・インカーネーション３の、図２の分散処理システムを示す図である。
【図４】サーバ２およびサーバ３が使用不能になり、新しいサーバ７がシステムに追加された、新しいグループ・インカーネーション４の、図３の分散処理システムを示す図である。
【図５】サーバ２およびサーバ３が定義解除され、グループ・クォーラムが３に改訂された、新しいグループ・インカーネーション５の、図４の分散処理システムを示す図である。
【図６】本発明の原理による、動的サーバ回復手順の一実施形態の流れ図である。
【図７】本発明の原理による、process_message_procedureの一実施形態の流れ図である。
【図８】本発明の原理による、process_message_procedureの一実施形態の流れ図である。
【図９】本発明の原理による、クォーラムを計算する手順の一実施形態の流れ図である。
【図１０】本発明の原理による、プロセッサのグループの構成を変更する手順の一実施形態の流れ図である。
【符号の説明】
１０分散処理システム

Claims

ネットワークを介して相互接続される使用可能なプロセッサのプールから、所定のタスクを分散処理するためのプロセッサのグループを構成する少なくとも３つのプロセッサが前記グループの初期構成時点に選択され、前記初期構成時点に選択されるプロセッサおよび前記初期構成時点の後に前記プールから前記グループに追加されるプロセッサの各々には、当該各プロセッサが使用可能な時点における前記グループ内のプロセッサを識別するためのメンバ・リストと、前記プールからの前記グループへのプロセッサの追加または前記グループからのプロセッサの削除が行われるごとに一意に更新されるインカーネーション番号とがそれぞれ持続的に格納され、前記メンバ・リストおよび前記インカーネーション番号の組み合わせによって前記グループの現在の構成状態が表されるようにした分散コンピューティング・システム内のプロセッサを再構成する、クォーラム・ベースの方法であって、
（ａ１）前記初期構成時点の後に、前記分散コンピューティング・システムのユーザが前記グループの構成の変更を要求する場合は、当該要求を受け取った前記グループ内の特定のプロセッサが、当該要求のコピーを自己のメンバ・リストによって識別される前記グループ内の他のすべてのプロセッサに送るステップと、
（ａ２）前記グループ内の各プロセッサが、前記要求に基づいて、自己のメンバ・リストおよび自己のインカーネーション番号をそれぞれ更新するステップと、
（ａ３）前記グループ内の前記特定のプロセッサが、前記グループ内の他のすべてのプロセッサからそれぞれのメンバ・リストおよびインカーネーション番号の更新が成功したことを表す成功メッセージを待ち、受け取った当該成功メッセージに基づいて、自己のメンバ・リストによって識別される前記グループ内のプロセッサのうち過半数以上のプロセッサがそれぞれのメンバ・リストおよびインカーネーション番号の更新に成功したと判定する場合は、前記ユーザに肯定のコードを返すステップとを含み、
前記グループ内の少なくとも１つのプロセッサが使用不能である間に、前記グループを動的に再構成するようにしたことを特徴とする方法。
前記少なくとも１つのプロセッサが使用可能になった後に回復処理を実行するステップをさらに含み、
前記回復処理が、
（ｂ１）前記使用可能になった少なくとも１つのプロセッサにおいて、自己のメンバ・リストおよび自己のインカーネーション番号を読み取るとともに、自己のメンバ・リストによって識別される前記グループ内の少なくとも１つの他のプロセッサへ、そのメンバ・リストおよびインカーネーション番号を要求する探索要求メッセージを送るステップと、
（ｂ２）前記使用可能になった少なくとも１つのプロセッサにおいて、前記少なくとも１つの他のプロセッサから受け取ったインカーネーション番号を自己のインカーネーション番号と比較し、前記少なくとも１つの他のプロセッサからのインカーネーション番号が自己のインカーネーション番号よりも大きいと判定する場合は、自己のメンバ・リストおよび自己のインカーネーション番号を前記少なくとも１つの他のプロセッサから受け取ったメンバ・リストおよびインカーネーション番号を用いてそれぞれ更新し、前記使用可能になった少なくとも１つのプロセッサが前記少なくとも１つの他のプロセッサから受け取った最も高いインカーネーション番号の個数を計数するカウントを初期設定するとともに、自己の現行メンバ・リストを用いて前記ステップ（ｂ１）を実施するステップと、
（ｂ３）前記使用可能になった少なくとも１つのプロセッサにおいて、前記少なくとも１つの他のプロセッサからのインカーネーション番号が自己のインカーネーション番号と等しいと判定する場合は、前記カウントを増分するとともに、当該増分済みのカウントが自己の現行メンバ・リストによって識別される前記グループ内のプロセッサの数の過半数以上でなければ、自己の現行メンバ・リストを用いて前記ステップ（ｂ１）を実施するステップと、
（ｂ４）前記使用可能になった少なくとも１つのプロセッサにおいて、前記カウントが自己の現行メンバ・リストによって識別される前記グループ内のプロセッサの数の過半数以上であると判定する場合は、自己の現行メンバ・リストによって識別される前記グループ内のすべての他のプロセッサへ探索停止メッセージを送るステップを含む、請求項１に記載の方法。
前記動的再構成が、前記プールからの前記グループへのプロセッサの追加または前記グループからのプロセッサの削除のいずれかを含む、請求項１に記載の方法。
前記分散コンピューティング・システムが、非共用分散コンピューティング・システムである、請求項１に記載の方法。