JPH1040226A - 分散コンピューティング環境におけるグループ・リーダ回復の方法 - Google Patents

Abstract

(57)【要約】 【課題】 分散コンピューティング環境においてグルー
プ・リーダ回復を行う方法を提供する。 【解決手段】 分散コンピューティング環境内で実行さ
れるプロセッサ・グループの現行リーダに障害が発生し
た場合、新しいリーダが選択される。新しいグループ・
リーダは、プロセッサ・グループのプロセッサの加入順
に順序づけられたメンバシップ・リストから選択され
る。選択されたリーダはメンバシップ・リスト上で、障
害が発生したグループ・リーダの後にある次のプロセッ
サである。具体的には、メンバシップ・リスト上の次の
アクティブ・プロセッサである。新しいグループ・リー
ダが選択された後、プロセッサ・グループに新しいグル
ープ・リーダが通知される。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、一般には分散コン
ピューティング環境に関し、具体的には分散コンピュー
ティング環境内で実行されるプロセッサのグループのリ
ーダの障害から回復する機構に係わる。

【０００２】

【従来の技術】典型的なコンピューティング・システム
には、いくつかのプロセッサが定義された事前定義済み
構成がある。アクティブ・プロセッサは処理するアプリ
ケーションを受け取り、システム構成に従ってアプリケ
ーションを実行する。

【０００３】

【発明が解決しようとする課題】しかし、プロセッサ
が、プロセッサのグループによって関連性のあるプロセ
スが実行されるプロセッサ・グループのメンバになれる
ようにする機構が必要である。すなわち、アクションを
グループ単位で行うことができるようにする機構が必要
である。さらに、各プロセッサ・グループにリーダを設
け、グループ・リーダを使用してその特定のグループの
イベントの管理と調整を行う機構が存在する必要があ
る。特に、現行グループ・リーダに障害が発生した場合
に新しいグループ・リーダを決定するために使用するこ
とができる機構の存在が必要である。

【０００４】

【課題を解決するための手段】分散コンピューティング
環境におけるプロセッサ・グループのグループ・リーダ
の障害の回復機構を設けることによって、従来技術の欠
点が克服され、追加の利点が得られる。プロセッサ・グ
ループにプロセッサが加入した順に順序づけられたメン
バシップ・リストから新しいグループ・リーダを選択す
る。新しいグループ・リーダは、メンバシップ・リスト
内で、障害が発生したグループ・リーダの後の次のプロ
セッサである。

【０００５】本発明の一実施例では、プロセッサ・グル
ープには新しいグループ・リーダが通知される。本発明
の他の実施例では、新しいグループ・リーダはネーム・
サーバから入手され、ネーム・サーバはメンバシップ・
リストから新しいグループ・リーダを選択する。

【０００６】本発明のグループ・リーダ回復機構は、現
行グループ・リーダに障害が発生した場合に新しいグル
ープ・リーダを決定する柔軟性のある技法を備える。こ
の技法によって、グループのメンバは新しいグループ・
リーダを知ることができ、グループの制御と管理をその
グループ・リーダに依存することができる。

【０００７】本発明の技法によってその他の特徴および
利点も得られる。本明細書では本発明の他の実施例およ
び実施形態についても詳述し、特許請求の範囲の一部と
見なされる。

【０００８】

【発明の実施の形態】一実施例では、可用性の高いマル
チコンピュータ・アプリケーションを実現するために、
本発明の技法を分散コンピューティング環境で使用す
る。可用性の高いアプリケーションは、障害発生後に実
行を継続することができる。すなわち、そのアプリケー
ションはフォールトトレラントであり、ユーザ・データ
の保全性が確保される。

【０００９】可用性の高いシステムでは、分散コンピュ
ーティング環境内の処理ノードで稼働しているサブシス
テム（たとえばプロセス・グループ）に加えられる変更
の調整、管理、および監視を行えることが重要である。
本発明の原理によると、前記の機能を実施する機構が設
けられる。このような機構の一例を本明細書では「グル
ープ・サービス」と呼ぶ。

【００１０】「グループ・サービス」は、分散コンピュ
ーティング環境の１つまたは複数のプロセッサ上で稼働
しているサブシステムに加えられる変更の調整、管理、
および監視を行う機能を提供する、システム規模のフォ
ールトトレラントな可用性の高いサービスである。グル
ープ・サービスは、本発明の技法により、フォールトト
レラント・サブシステムの設計および実施のためと、複
数システムの整合性のある回復を実現するための、統合
されたフレームワークを提供する。グループ・サービス
は、少数の中核概念に基づく単純なプログラミング・モ
デルを提供する。本発明の原理によると、これらの概念
には、各プロセス・グループと共にアプリケーション固
有の情報を維持する、クラスタ規模のプロセス・グルー
プ・メンバシップおよび同期サービスが含まれる。

【００１１】前述のように、一実施例では、本発明の機
構は「グループ・サービス」機構に含まれる。しかし、
本発明の機構は他の様々な機構内で、または様々な機構
と共に使用することができ、したがって「グループ・サ
ービス」は一例に過ぎない。本発明の技法を組み込むた
めの「グループ・サービス」という用語の使用は、便宜
のために過ぎない。

【００１２】一実施形態では、本発明の機構は図１に示
す一例のような分散コンピューティング環境に組み込ん
で使用される。一実施例では、分散コンピューティング
環境１００は、たとえば、複数のＬＡＮゲート１０４を
介して互いに結合された複数のフレーム１０２を含む。
フレーム１０２とＬＡＮゲート１０４について以下に詳
述する。

【００１３】一実施例では、分散コンピューティング環
境１００は、各フレームが複数の処理ノード１０６を備
える８個のフレームを含む。一例では、各フレームは１
６個の処理ノード（プロセッサとも呼ぶ）を含む。各処
理ノードは、たとえば、ＵＮＩＸベースのオペレーティ
ング・システムであるＡＩＸを実行するＲＩＳＣ／６０
００コンピュータである。フレーム内の各処理ノード
は、たとえば内部ＬＡＮ接続を介してフレームの他の処
理ノードに結合されている。さらに、各フレームはＬＡ
Ｎゲート１０４を介して他のフレームに結合されてい
る。

【００１４】たとえば、各ＬＡＮゲート１０４には、Ｒ
ＩＳＣ／６０００コンピュータ、ＬＡＮへの任意のコン
ピュータ・ネットワーク接続、またはネットワーク・ル
ータが含まれる。しかし、これらは例に過ぎない。当業
者なら、他のタイプのＬＡＮゲートがあり、フレームを
互いに結合するために他の機構も使用することができる
ことがわかるであろう。

【００１５】上記に加えて、図１の分散コンピューティ
ング環境も一例に過ぎない。８個より多い数または少な
い数のフレームや、１フレーム当たり１６個より多い数
または少ない数のノードを備えることも可能である。さ
らに、処理ノードはＡＩＸをを稼働させるＲＩＳＣ／６
０００コンピュータでなくてもよい。処理ノードのうち
の一部または全部が異なるタイプのコンピュータや異な
るオペレーティング・システムを備えることもできる。
これらの変形形態はすべて本願発明の一部と見なす。

【００１６】一実施形態では、本発明の機構を組み込ん
だ「グループ・サービス」サブシステムは、分散コンピ
ューティング環境１００の複数の処理ノードにわたって
分散している。具体的には、一実施例では処理ノード１
０６のうちの１つまたは複数のノード内に「グループ・
サービス」デーモン２００（図２）を配置する。この
「グループ・サービス」デーモンをまとめて「グループ
・サービス」と呼ぶ。

【００１７】グループ・サービスは、たとえばプロセス
・グループの複数のプロセス間の通信と同期化を容易に
し、たとえば分散回復同期機構の提供など多様な状況で
使用することができる。「グループ・サービス」の機能
を使用したいプロセス２０２（図２）は「グループ・サ
ービス」デーモン２００に結合される。具体的には、そ
のプロセスは、「グループ・サービス」に付随するコー
ド（たとえばライブラリ・コード）のうちの少なくとも
一部をプロセス自体のコードにリンクさせることによっ
て「グループ・サービス」に結合される。本発明の原理
によると、このリンクによってプロセスは、以下に詳述
するように本発明の機構を使用することができる。

【００１８】一実施形態では、プロセスはアプリケーシ
ョン・プログラミング・インタフェース２０４を介して
本発明の機構を使用する。具体的には、アプリケーショ
ン・プログラミング・インタフェースは、一例では「グ
ループ・サービス」に含まれている本発明の機構を使用
するためのインタフェースを、プロセスに提供する。一
実施例では、「グループ・サービス」２００は内部層３
０２（図３）と外部層３０４を含み、それぞれの層につ
いて以下に詳述する。

【００１９】本発明の原理によると、内部層３０２は限
定された１組の機能を外部層３０４に提供する。内部層
の限定された１組の機能を使用して、より豊富で広範囲
の１組の機能を構築することができ、それを外部層で実
施し、アプリケーション・プログラミング・インタフェ
ースを介してプロセスにエクスポートする。「グループ
・サービス」の内部層（メタグループ層とも呼ぶ）は
「グループ・サービス」デーモンに関係し、デーモンに
結合されたプロセス（すなわちクライアント・プロセ
ス）には関係しない。すなわち、内部層はデーモンを含
むプロセッサに労力を集中させる。一実施例では、１つ
の処理ノード上には１つの「グループ・サービス」デー
モンしかない。しかし、分散コンピュータ環境内の処理
ノードのうちのサブセットまたは全部が「グループ・サ
ービス」デーモンを含むことができる。

【００２０】「グループ・サービス」の内部層は、プロ
セッサ・グループごとに機能を実行する。ネットワーク
内には複数のプロセッサ・グループが存在することがで
きる。各プロセッサ・グループ（メタグループとも呼
ぶ）は、その上で実行される「グループ・サービス」を
持つ１つまたは複数のプロセッサを含む。特定のグルー
プのプロセッサは、関連性のあるプロセスを実行すると
いう点で関連している。（一実施例では、関連性のある
プロセスは共通の機能を実現する。）たとえば、図４を
参照すると、処理ノード１と処理ノード２のそれぞれが
プロセスＸを実行しているため、プロセッサ・グループ
Ｘ（４００）はこの２つのノードを含むが、処理ノード
３は含まない。したがって、処理ノード１および２はプ
ロセッサ・グループＸのメンバである。処理ノードは任
意の数のプロセッサ・グループのメンバとなることもい
ずれのプロセッサ・グループのメンバにもならないこと
もでき、プロセッサ・グループは１つまたは複数のメン
バを共通して持つことができる。

【００２１】プロセッサ・グループのメンバになるため
には、プロセッサはそのグループのメンバとなるように
要求する必要がある。本発明の原理によると、特定のグ
ループに関連するプロセス（たとえばプロセスＸ）が対
応するプロセス・グループ（たとえばプロセス・グルー
プＸ）に加わることを要求し、プロセッサがその対応す
るプロセス・グループを認識していない場合に、プロセ
ッサはその特定のプロセッサ・グループ（たとえばプロ
セッサ・グループＸ）のメンバとなるように要求する。
特定のプロセス・グループに加入する要求を扱うプロセ
ッサ上のグループ・サービス・デーモンは、そのプロセ
ス・グループを認識していないため、対応するプロセッ
サ・グループのメンバではないことを把握する。したが
って、プロセッサはメンバになるように要求し、それに
よってプロセスがそのプロセス・グループのメンバにな
ることができるようにする。（プロセッサ・グループの
メンバになる１つの技法については以下で詳述する。）

【００２２】内部層３０２（図３）は、プロセッサ・グ
ループごとにいくつかの機能を実行する。これらの機能
には、たとえばグループ・リーダの維持、挿入、マルチ
キャスト、離脱、および障害などが含まれ、それぞれに
ついては以下で詳述する。

【００２３】本発明の原理によると、ネットワークの各
プロセッサについてグループ・リーダを選択する。一実
施例では、グループ・リーダは特定のグループへの加入
を要求する最初のプロセッサである。本明細書で述べる
ように、グループ・リーダはそのグループ・リーダのプ
ロセッサ・グループに関連づけられた活動を制御する役
割を果たす。たとえば、処理ノードであるノード２（図
４）がプロセッサ・グループへの加入を要求する最初の
ノードである場合、処理ノード２がグループ・リーダで
あり、プロセッサ・グループＸの活動を管理する役割を
果たす。処理ノード２は複数のプロセッサ・グループの
グループ・リーダとなることができる。

【００２４】たとえばプロセッサがグループからの離脱
を要求したり、プロセッサが障害を起こしたり、プロセ
ッサ上のグループ・サービス・デーモンに障害が発生し
たりした場合など、何らかの理由でグループ・リーダが
プロセッサ・グループから外される場合、グループ・リ
ーダの回復が行われる。具体的には、ステップ５００ａ
「新しいグループ・リーダを選択する」（図５）で、新
しいグループ・リーダが選択される。

【００２５】一実施例では、新しいグループ・リーダを
選択するために、グループに加入したプロセッサ順に順
序づけられたプロセッサ・グループのメンバシップ・リ
ストがグループの１つまたは複数のプロセッサによって
走査され、リスト内の次のプロセッサを探し出す（ステ
ップ５０２「メンバシップ・リスト内の次のメンバを入
手する」）。その後、リストから入手したプロセッサに
ついてアクティブかどうかを判断する（照会５０４「メ
ンバはアクティブか」）。一実施例では、これは分散コ
ンピューティング環境の処理ノードにわたって分散され
た他のサブシステムが判断する。このサブシステムは少
なくともメンバシップ・リスト内のノードに信号を送
り、特定のノードから応答がなければ、そのノードが非
アクティブであるとみなす。

【００２６】選択されたプロセッサがアクティブでない
場合、再びアクティブ・メンバが見つかるまでメンバシ
ップ・リストが走査される。リストからアクティブ・プ
ロセッサを入手すると、そのプロセッサがそのプロセッ
サ・グループの新しいグループ・リーダになる（ステッ
プ５０６「選択されたメンバが新しいグループ・リーダ
である」）。

【００２７】たとえば、３つの処理ノードが以下の順序
でプロセッサ・グループＸに加入しているものとする。 プロセッサ２、プロセッサ１、およびプロセッサ３ したがって、プロセッサ２が最初のグループ・リーダで
ある（図７参照）。しばらくしてプロセッサ２がプロセ
ッサ・グループＸから離脱し、したがって新しいグルー
プ・リーダが必要になる。プロセッサ・グループＸのメ
ンバシップ・リストによると、プロセッサ１が次のグル
ープ・リーダである。しかし、プロセッサ１が非アクテ
ィブの場合は、プロセッサ３が新しいグループ・リーダ
に選ばれることになる（図８参照）。

【００２８】本発明の原理によると、一実施例ではメン
バシップ・リストはプロセッサ・グループの各処理ノー
ドのメモリに記憶される。したがって、上記の例では、
プロセッサ１、プロセッサ２、およびプロセッサ３はす
べてメンバシップ・リストのコピーを保持することにな
る。具体的には、グループに加入しようとする各プロセ
ッサは現行グループ・リーダからメンバシップ・リスト
のコピーを受け取る。他の実施例では、グループに加入
しようとする各プロセッサは現行グループ・リーダ以外
のグループの別のメンバからメンバシップ・リストを受
け取る。

【００２９】図５に戻って参照すると、本発明の一実施
例では、新しいグループ・リーダが選択されると、その
新しいグループ・リーダは新しいグループ・サーバであ
ることをネーム・サーバに通知する（ステップ５０８
「ネーム・サーバに通知する」）。一例では、ネーム・
サーバ７００（図９）はネーム・サーバとして指定され
た分散コンピューティング環境内の処理ノードの１つで
ある。ネーム・サーバは、たとえばネットワークのすべ
てのプロセッサ・グループのリストやすべてのプロセッ
サ・グループのグループ・リーダのリストを含む特定の
情報を記憶する中央記憶場所の役割を果たす。この情報
は、ネーム・サーバ処理ノードのメモリに記憶される。
ネーム・サーバは、プロセッサ・グループ内の処理ノー
ドでもプロセッサ・グループとは独立した処理ノードで
もよい。

【００３０】一実施例では、ネーム・サーバ７００に
は、新しいグループ・リーダのグループ・サービス・デ
ーモンからネーム・サーバに送られるメッセージによっ
てグループ・リーダの変更が通知される。その後、ネー
ム・サーバはたとえばアトミック・マルチキャストを使
用してグループの他のプロセッサに新しいグループ・リ
ーダを通知する（ステップ５１０「グループの他のメン
バに通知する」（図５））。（マルチキャストはブロー
ドキャストと類似した機能であるが、マルチキャストで
はメッセージはシステムのすべてのプロセッサに送られ
るのではなく、選択されたグループに宛てて送られる。
一実施例では、マルチキャストは、メッセージと宛先と
して意図された受信先のリストとを受け取り、たとえば
ユーザ・データグラム・プロトコル（ＵＤＰ）または伝
送制御プロトコル（ＴＣＰ）を使用して、意図された各
受信先に２点間メッセージ送信を行うソフトウェアを設
けることによって行うことができる。他の実施例では、
メッセージと意図された受信先のリストは、イーサネッ
トなどの基礎ハードウェア通信機構に渡され、その基礎
ハードウェア通信機構がマルチキャスト機能を提供する
ことになる。）

【００３１】本発明の他の実施例では、新しいグループ
・リーダ以外のグループのメンバが、ネーム・サーバに
新しいグループ・リーダの識別情報を通知する。他の実
施例では、プロセッサ・グループ内の各プロセッサがメ
ンバシップ・リストを持っており、新しいグループ・リ
ーダを自分で判断しているため、グループのプロセッサ
に対して新しいグループ・リーダは明示的には通知され
ない。

【００３２】本発明の他の実施例では、新しいグループ
・リーダが必要な場合、ネーム・サーバに新しいグルー
プ・リーダの識別情報を求める要求がネーム・サーバに
対して送られる（ステップ５００ｂ「ネーム・サーバに
新しいグループ・リーダを要求する」（図６））。この
実施例では、ネーム・サーバにもメンバシップ・リスが
あり、ネーム・サーバは上述と同じステップをたどって
新しいグループ・リーダを判断する（ステップ５０２、
５０４、および５０６）。新しいグループ・リーダが判
断されると、ネーム・サーバはプロセッサ・グループの
他のプロセッサに新しいグループ・リーダを通知する
（ステップ５１０「グループの他のメンバに通知す
る」）。

【００３３】内部層またはメタグループ層によって実施
されるグループ・リーダ維持機能に加えて、挿入機能も
実施される。挿入機能は、グループ・サービス・デーモ
ン（すなわちグループ・サービス・デーモンを実行する
プロセッサ）が特定のプロセッサ・グループに加わりた
い場合に使用される。前述のように、プロセッサは、プ
ロセッサで実行されているプロセスがプロセス・グルー
プに加わりたい場合で、プロセッサがそのプロセス・グ
ループを認識していない場合に、特定のプロセッサ・グ
ループに加わることを要求する。

【００３４】他の実施例では、プロセッサ・グループの
メンバになるために、グループに加入したいプロセッサ
はまずそのプロセッサ・グループのグループ・リーダが
どれであるかを判断する（ステップ８００「グループ・
リーダを判断する」（図１０））。一実施例では、ネー
ム・サーバ７００にプロセッサ・グループの名前を送
り、ネーム・サーバにそのグループのグループ・リーダ
の識別情報を要求することによってグループ・リーダが
判断される。

【００３５】要求側プロセッサが（グループに対する最
初の要求であるため）グループ・リーダであるとネーム
・サーバが応答した場合（照会８０１）、その要求側プ
ロセッサがプロセッサ・グループを形成する（ステップ
８０３「グループを形成する」）。具体的には、その特
定のプロセッサ・グループのメンバシップ・リストを作
成し、そのリストには要求側プロセッサが入れられる。

【００３６】プロセッサがグループ・リーダでない場合
は、ネーム・サーバからその識別情報を入手したグルー
プ・リーダにメッセージを使用して挿入要求を送る（ス
テップ８０２「グループ・リーダに挿入要求を送
る」）。グループ・リーダは要求側プロセッサをプロセ
ッサ・グループに加える（ステップ８０４「グループ・
リーダがプロセッサをプロセッサ・グループに挿入す
る」）。具体的には、一実施例では、グループ・リーダ
のグループ・サービス・デーモンがそのメンバシップ・
リストを更新し、マルチキャストを使用してプロセッサ
・グループの他の各グループ・サービス・デーモンに、
そのプロセッサにあるメンバシップ・リストに加入プロ
セッサを追加することを通知する。具体的には、一例と
して、グループ・リーダは他のデーモンにマルチキャス
トを使用して更新を通知し、デーモンはその更新に対し
て肯定応答し、次にグループ・リーダがもう一度マルチ
キャストを使用して変更のコミットを送出する。（他の
実施例では、この通知はアトミック・マルチキャストを
使用して行うことができる。）一実施例では、メンバシ
ップ・リストはグループへの加入順に維持されるため、
加入プロセッサはリストの終わりに追加される。

【００３７】本発明の原理によると、プロセッサ・グル
ープのメンバであるプロセッサはグループを離脱するこ
とを要求することができる。挿入要求と同様に、離脱要
求もたとえばメッセージを使用してグループ・リーダに
転送される（ステップ９００「グループ・リーダに離脱
要求を送る」（図１１））。その後、グループ・リーダ
は、たとえばそのメンバシップ・リストからそのプロセ
ッサを削除し、プロセッサ・グループのすべてのメンバ
にそのそれぞれのメンバシップ・リストからもそのプロ
セッサを除去することを通知することによって、そのプ
ロセッサをグループから除去する（ステップ９０２「グ
ループ・リーダがプロセッサをグループから削除す
る」）。さらに、離脱するプロセッサがグループ・リー
ダである場合、前述のようにグループ・リーダ回復が行
われる。

【００３８】以上に加えて、プロセッサが障害を起こし
た場合、またはプロセッサ上で実行されているグループ
・サービス・デーモンが障害を起こした場合、そのプロ
セッサはプロセッサ・グループから除去される。一実施
例では、グループ・サービス・デーモンが障害を起こし
た場合、プロセッサが障害を起こしたとみなされる。一
実施例では、障害を起こしたプロセッサは、プロセッサ
障害を検出する、分散コンピューティング環境内で稼働
しているサブシステムによって検出される。障害がある
場合、一実施例では、そのプロセッサはグループ・リー
ダによって除去される。具体的には、グループ・リーダ
はそのメンバシップ・リストからそのプロセッサを削除
し、前述のように、他のメンバ・プロセッサにそれを行
うことを通知する。

【００３９】グループ・サービスの内部層によって実施
されるもう一つの機能として、マルチキャスト機能があ
る。本発明の原理によると、プロセッサ・グループのメ
ンバはグループの他のメンバにメッセージをマルチキャ
ストすることができる。このマルチキャストには、片方
向マルチキャストのほか、肯定応答マルチキャストを含
めることができる。

【００４０】一実施例では、グループの１つのメンバか
らグループの他のメンバにメッセージをマルチキャスト
するために、メッセージ送信メンバがグループのグルー
プ・リーダにメッセージを送り、グループ・リーダがそ
のメッセージを他のメンバにマルチキャストする。

【００４１】本発明の原理によると、メッセージを送信
する前に、グループ・リーダはメッセージに順序番号を
割り当てる。割り当てられた順序番号は数字順に維持さ
れる。したがって、プロセッサ・グループのメンバ（す
なわちグループ・サービス）が順序が乱れた順序番号を
持つメッセージを受け取った場合、そのメンバはメッセ
ージを逸したことがわかる。たとえば、処理ノードがメ
ッセージ４３と４５を受け取った場合、そのノードはメ
ッセージ４４を逸したことになる。

【００４２】本発明の原理によると、プロセッサ・グル
ープ内のすべてのノードが同じメッセージを受け取って
いるため、処理ノードは逸したメッセージをプロセッサ
・グループ内のいずれかの処理ノードから取り出すこと
ができる。しかし、一実施例では、情報を逸した処理ノ
ードはそれをグループ・リーダに要求する。しかし、メ
ッセージを逸したのがグループ・リーダである場合、グ
ループ・リーダはそれをプロセッサ・グループ内の他の
いずれかの処理ノードに要求することができる。これが
可能なのは、プロセッサ・グループのすべての処理ノー
ドにわたって重要データが回復可能な方式で複製される
ためである。本発明によると、回復に必要なデータを持
続記憶装置に記憶する必要はない。本発明の技法によっ
て、回復データを記憶するための持続安定ハードウェア
・ベース記憶装置が不要になる。

【００４３】たとえば、グループ・リーダが障害を起こ
した場合、前述のように新しいグループ・リーダが選択
される。グループ・リーダは、グループの処理ノードと
通信することによってすべてのメッセージを確実に入手
するようにする。一実施例では、グループ・リーダがす
べてのメッセージを入手していることを確認すると、グ
ループの他のすべての処理ノードもそれらのメッセージ
を確実に入手するようにする。したがって、本発明の技
法によって、障害を起こした処理ノード、障害を起こし
たプロセス、またはリンクを、安定記憶装置を必要とせ
ずに回復することができる。

【００４４】本発明の原理によると、各プロセッサ・グ
ループはメッセージのそのグループ自体の順序づけられ
たセットを維持する。したがって、１つのプロセッサ・
グループのメッセージが他のプロセッサ・グループのメ
ッセージと重なったり衝突したりすることはない。プロ
セッサ・グループは、その順序づけられたメッセージと
共に、互いに独立している。したがって、１つのプロセ
ッサ・グループが４３、４４、および４５というメッセ
ージの順序づけられたセットを受け取ることができると
同時に、他のプロセッサ・グループは１、２、３という
メッセージの独立して順序づけられたセットを受け取る
ことができる。これによって、ネットワークのすべての
プロセッサ間で全対全通信を行う必要がなくなる。

【００４５】本発明の一実施例では、各処理ノードはメ
ッセージを他のノードに供給する場合やグループ・リー
ダになる場合に備えて、受信するメッセージを一定時間
保持する。メッセージはグループのすべてのプロセッサ
がそのメッセージを受信するまで保管される。メッセー
ジをすべてのプロセッサが受信すると、そのメッセージ
は廃棄することができる。

【００４６】一実施例では、すべてのノードがメッセー
ジを受信したことを処理ノードに通知するのはグループ
・リーダである。具体的には、一実施例では、処理ノー
ドはグループ・リーダにメッセージを送るときにそのノ
ードが最後に見たメッセージ（すなわち正しい順序の最
後のメッセージ）の識別標識を組み込む。グループ・リ
ーダはこの情報を収集し、処理ノードにメッセージを送
るときに、メッセージにすべてのノードが見た最後のメ
ッセージの順序番号を組み込む。その後、処理ノードは
閲覧済みの標識が付けられたメッセージを削除すること
ができる。

【００４７】本発明の原理によると、マルチキャスト・
ストリームを特定の時点で休止させてすべてのプロセッ
サ・グループ・メンバがすべてのメッセージを受信済み
になるようにする。たとえば、一定期間マルチキャスト
がなかったときや、ある数のＮｏＡｃｋＲｅｑｕｉｒｅ
ｄ（すなわち肯定応答不要）マルチキャストが送られた
後に、ストリームを休止させる。一実施例では、マルチ
キャスト・ストリームを休止させる場合、グループ・リ
ーダがＳＹＮＣマルチキャストを送出し、それに対して
すべてのプロセッサ・グループ・メンバが肯定応答す
る。プロセッサ・グループ・メンバはそのようなメッセ
ージを受け取ると、そのＳＹＮＣメッセージの順序番号
に基づいて、すべてのメッセージを受け取っていること
（または受け取る必要があること）を知る。メンバがい
ずれかのメッセージを逸した場合は、メッセージを入手
してから肯定応答する。グループ・リーダはこのマルチ
キャストに対する肯定応答をすべて受け取ると、すべて
のプロセッサ・グループ・メンバがすべてのメッセージ
を受け取ったことを知り、したがってマルチキャスト・
ストリームが同期化され休止される。

【００４８】本発明の他の実施例では、特定のＳＹＮＣ
マルチキャストは不要である。その代わり、以下の技法
のいずれか１つを使用してマルチキャスト・ストリーム
を休止させることができる。一例として、肯定応答を必
要とするマルチキャストをグループ・リーダからプロセ
ッサに送ることができる。プロセッサは、肯定応答を必
要とするマルチキャストを受け取ると、グループ・リー
ダに肯定応答を送る。肯定応答には、肯定応答するマル
チキャストの順序番号が含まれている。プロセッサはこ
の順序番号を使用して、逸したメッセージがないかどう
かを判断する。逸したメッセージがある場合、プロセッ
サはたとえば、グループ・リーダにその逸したメッセー
ジを要求する。グループ・リーダがＡＣＫを必要とする
メッセージをグループのすべてのプロセッサに送り、肯
定応答をすべて受け取ると、グループ・リーダはストリ
ームが休止されていることを把握する。非グループ・リ
ーダ・プロセッサはグループ・リーダに依存してすべて
のメッセージを遅滞なく確実に受信するので、マルチキ
ャストを逸していることがないようにするためにグルー
プ・リーダに対する定期的な肯定応答やＰＩＮＧを行う
必要がない。

【００４９】他の実施例として、ＮｏＡｃｋＲｅｑｕｉ
ｒｅｄマルチキャストを使用する状況で、グループ・リ
ーダはＮｏＡｃｋＲｅｑｕｉｒｅｄマルチキャストの１
つをＡｃｋＲｅｑｕｉｒｅｄマルチキャストに変えるこ
とができ、したがってそれを前述のようにｓｙｎｃとし
て使用する。したがって、明示的なＳＹＮＣメッセージ
は不要である。

【００５０】上記に加えて、他の実施例では、非グルー
プ・リーダ・プロセッサがグループ・リーダのアクショ
ンを先取りすることができ、それによってＮｏＡｃｋＲ
ｅｑｕｉｒｅｄメッセージの数が窓サイズに達した場合
（すなわち、一実施例ではたとえば５など所定の数に達
した場合）、または最大遊休時間に達した場合、非グル
ープ・リーダ・プロセッサはグループ・リーダにＡＣＫ
を送ることができる。ＡＣＫによって、各プロセッサが
受信した最高順序番号のマルチキャストがグループ・リ
ーダに供給される。すべての非グループ・リーダ・プロ
セッサがこれを行った場合、グループ・リーダはＮｏＡ
ｃｋＲｅｑｕｉｒｅｄマルチキャストをＡｃｋＲｅｑｕ
ｉｒｅｄマルチキャストに変える必要はない。したがっ
て、グループはすべての肯定応答を待つことによって停
滞させられることがない。

【００５１】本発明の上記の機能のサポートは、グルー
プ・サービス（すなわちプロセス）のユーザには透過で
ある。この機能を実施するためのプロセスによる明示的
アクションは不要である。さらに、このサポートはグル
ープ・サービスの内部層でも外部層でも使用可能であ
る。

【００５２】図３に戻って参照すると、外部層３０４
は、ユーザ（すなわちクライアント・プロセス）にとっ
てわかりやすいアプリケーション・プログラミング・イ
ンタフェースのより豊富な機構のセットを実現する。

【００５３】一実施例では、これらの機構にはアトミッ
ク・マルチキャスト、２フェーズ・コミット、バリヤ同
期、プロセス・グループ・メンバシップ、プロセッサ・
グループ・メンバシップ、およびプロセス・グループ状
態値が含まれ、それぞれについては以下で説明する。こ
れらの機構およびその他の機構は、本発明の原理に従っ
て、アプリケーション・プログラミング・インタフェー
スによって、わかりやすい単一の統一フレームワークに
統一される。具体的には、（他の機構に加えて）通信機
構と同期機構が単一のプロトコルに統一されている。

【００５４】本発明の原理によると、この単一の統一フ
レームワークは、本明細書で説明するようにプロセス・
グループのメンバに提供される。プロセス・グループ
は、分散コンピューティング環境の１つまたは複数の処
理ノード上で実行される１つまたは複数の関連性のある
プロセスを含む。たとえば、図１２を参照すると、プロ
セス・グループＸ（１０００）は、プロセッサ１上で実
行されるプロセスＸとプロセッサ２上で実行される２つ
のプロセスＸを含む。プロセスが特定のプロセス・グル
ープのメンバになる方式について、以下で詳述する。

【００５５】プロセス・グループは、提供者と加入者を
含む少なくとも２つのタイプのメンバを有することがで
きる。提供者は投票権などの特定の特権を持つメンバ・
プロセスであり、加入者にはそのような特権はない。加
入者は単にプロセス・グループの進行状況を監視するこ
とができるに過ぎず、グループに関与することはできな
い。たとえば、加入者はグループのメンバシップとグル
ープの状態値を監視することができるが、投票すること
はできない。他の実施例では、異なる権利を持つ他のタ
イプのメンバを設けることができる。

【００５６】本発明の原理によると、以下で図１３を参
照しながら説明するようにアプリケーション・プログラ
ミング・インタフェースを実現する。

【００５７】図１３を参照すると、一実施例では、最初
にプロセス・グループの提供者がグループにプロトコル
を提案する（この実施例では加入者はプロトコルを提案
することはできない）（ステップ１１００「プロセス・
グループのメンバがグループにプロトコルを提案す
る」）。具体的には、一実施例ではプロトコルを提案す
るＡＰＩ呼出しを行う。一実施例では、プロトコルはプ
ロセスによって、そのプロセスを実行するプロセッサ上
のグループ・サービス・デーモンの外部層に渡される。
次に、そのグループ・サービス・デーモンはそのプロト
コルをメッセージを使用してグループのグループ・リー
ダに渡す。グループ・リーダはマルチキャストを使用し
て、関連性のあるプロセッサ・グループのすべてのプロ
セッサにそのプロトコルを通知する。（デーモンの内部
層がこのマルチキャストを管理している。）次にそれら
のプロセッサが外部層を介してプロセス・グループの適
切なメンバに、提案されたプロトコルを通知する（ステ
ップ１１０２「プロセス・グループ・メンバにプロトコ
ルを通知する」）。

【００５８】同時に複数の提供者がプロトコルを提案し
た場合、稼働させるプロトコルをグループ・リーダが以
下のようにして選択する。一実施例では、プロトコルは
障害のためのプロトコルが最初、加入プロトコルが２番
目、他のすべてのプロトコル（たとえば後述する離脱、
追放、更新状態値の要求およびグループ・メッセージの
供給）が先着順というように優先順位がつけられる。し
たがって、障害のためにメンバを除去する要求が、加入
要求および離脱要求と同時に提案された場合、除去要求
が先に選択される。次に加入要求が選択され、その後で
離脱要求が選択される。

【００５９】障害による除去要求が複数ある場合、それ
らの要求はすべて加入要求より先に選択される。グルー
プ・リーダは除去要求をグループ・リーダが見た順に選
択する（後述するバッチ処理が可能な場合を除く）。同
様に、複数の加入要求がある場合は、それらの要求は同
様にして他のどの要求よりも先に選択される。

【００６０】一実施例では、その他の複数の要求がある
場合、グループ・リーダが最初に受け取った要求が選択
され、その他の要求は廃棄される。グループ・リーダは
それらの廃棄された要求の提供者に要求が廃棄されたこ
とを通知し、その後で、提供者は希望する場合にはその
要求を再提出することができる。本発明の他の実施例で
は、これらの他の要求は受信順に待ち行列化することが
でき、廃棄せずに選択することができる。

【００６１】プロトコルを選択した後、そのプロトコル
について投票を行うかどうかを決定する（照会１１０４
「投票するか？」）。一実施例では、プロトコルを提案
するプロセスは最初の提案時に、投票を行うべきかどう
かを指示する。投票が指示されていない場合、プロトコ
ルは単にアトミック・マルチキャストに過ぎず、そのプ
ロトコルは完了する（ステップ１１０６「終了」）。

【００６２】投票を行う場合は、プロセス・グループの
各提供者がプロトコルについて投票する（ステップ１１
０８「投票権のあるプロセス・グループ・メンバが投票
する」）。具体的には、本発明の原理によると、投票に
よって各提供者はグループを満足させるのに必要なロー
カル・アクションを行うことができ、グループにそれら
のアクションの結果を通知することができる。これは、
先に進む前にすべての提供者が特定の地点に達している
ようにすることによって、バリヤ同期プリミティブとし
て機能する。

【００６３】本発明の一実施例では、各提供者は投票値
を投ずることによって投票し、投票値にはたとえば以下
のものが含まれる。 （ａ）ＡＰＰＲＯＶＥ（承認）は、提供者が、すべての
提供者がこのバリヤに達したらプロトコルを完了させ、
提案されたすべての変更を受け入れたいということを示
す。 （ｂ）ＣＯＮＴＩＮＵＥ（継続）は、提供者が、もう１
回投票ステップによってプロトコルを継続し、提案され
た変更を保留にしておきたいとうことを示す。 （ｃ）ＲＥＪＥＣＴ（拒否）は、提供者が、すべての提
供者がこのバリヤに達したらこのプロトコルを終了さ
せ、拒否することができる提案された変更を拒否したい
ということを示す。

【００６４】本発明の原理によると、プロセス・グルー
プの各提供者はその投票をプロセスと同じプロセッサ上
で実行されているグループ・サービス・デーモンに転送
する。グループ・サービス・デーモンは受け取った投票
値を、そのプロセス・グループに関連づけられたメタグ
ループのグループ・リーダに転送する。たとえば、プロ
セス・グループＸの投票値はプロセッサ・グループＸの
グループ・リーダに転送される。グループ・リーダは投
票値に基づいてそのプロトコルをどのように進めるかを
決定する。次にグループ・リーダは投票の結果を該当す
るプロセッサ・グループの各プロセッサ（すなわちそれ
らのプロセッサ上のグループ・サービス・デーモン）に
マルチキャストし、グループ・サービス・デーモンが提
供者にその結果値を通知する。たとえば、グループ・リ
ーダはプロセッサ・グループＸのグループ・サービス・
デーモンに通知し、そのグループ・サービス・デーモン
が結果をプロセス・グループＸの提供者に送る。

【００６５】提供者の１つがＣＯＮＴＩＮＵＥを投票
し、提供者のいずれもＲＥＪＥＣＴを投票しなかった場
合（照会１１１０「投票を続けるか？」）、プロトコル
はもう１つの投票ステップに進む（ステップ１１０
８）。すなわち提供者は動的な数の同期フェーズを使用
してバリヤ同期を行う。具体的には、本発明の原理によ
ると、プロトコルが持つことができる投票ステップ（ま
たは同期フェーズまたは同期点）の数は動的である。投
票メンバが希望する任意のステップ数とすることができ
る。プロトコルは、いずかの提供者がプロトコルの継続
を望む限り続行することができる。したがって、一実施
例では、投票によって投票ステップ数が動的に制御され
る。しかし、他の実施例では、動的投票ステップ数はプ
ロトコルの開始中に設定することができる。その場合で
も、プロトコルが初期設定されるたびに変更可能である
ため動的である。

【００６６】提供者がもう１つ投票ステップを続けない
ことに投票した場合、プロトコルは２フェーズ・コミッ
トである。投票完了後（２フェーズ投票または多フェー
ズ投票の場合）、投票結果がメンバに送られる。具体的
には、プロセス・グループのいずれか１つの提供者がＲ
ＥＪＥＣＴを投票した場合、プロトコルは終了し、提案
された変更は拒否される。各提供者に対してマルチキャ
ストを使用して、プロトコルが拒否されたことが通知さ
れる（ステップ１１１２「メンバにプロトコルの完了を
通知する」）。一方、すべての提供者がＡＰＰＲＯＶＥ
に投票した場合、プロトコルは完了して提案されたすべ
ての変更が受け入れられる。提供者にはマルチキャスト
を使用して受け入れられたプロトコルが通知される（ス
テップ１１１２「メンバにプロトコルの完了を通知す
る」）。

【００６７】本発明の原理によると、上述のプロトコル
はプロセス・グループ・メンバシップおよびプロセス・
グループ状態値とも統合される。具体的には、本発明の
機構を使用して、プロセス・グループのメンバシップ変
更の管理と監視を行う。グループのメンバシップに加え
られる変更は、前述のプロトコルを介して提案される。
さらに、本発明の機構はグループ状態値の変更も媒介
し、少なくとも１つのプロセス・グループ・メンバが残
っている限り、グループ値の整合性と信頼性が維持され
るように保証する。

【００６８】プロセス・グループのグループ状態値はプ
ロセス・グループの同期された黒板の役割を果たす。一
実施例では、グループ状態値は提供者が制御するアプリ
ケーション固有の値である。グループ状態値は、グルー
プ・サービスによって各プロセスのために維持されるグ
ループ状態データの一部である。グループ状態データに
は、グループ状態値のほか、そのグループの提供者メン
バシップ・リストが含まれる。各提供者は、提供者識別
子によって識別され、このリストは、グループ・サービ
スによって、最も古い提供者（グループに加わっている
最初の提供者）がリストの先頭になり、最も若い提供者
が最後になるように順序づけられる。

【００６９】グループ状態値の変更は、グループ・メン
バ（すなわち提供者）によって前述のプロトコルを介し
て提案される。一実施例では、グループ状態値の内容は
グループ・サービスによって解釈されない。グループ状
態値の意味は、グループ・メンバによって付与される。
本発明の機構によって、すべてのプロセス・グループ・
メンバが、グループ状態値に加えられる同じ順序の変更
を見るように保証され、すべてのプロセス・グループ・
メンバがその更新を見るように保証される。

【００７０】したがって、前述のように、本発明のアプ
リケーション・プログラミング・インタフェースは、た
とえばアトミック・マルチキャスト、２フェーズ・コミ
ット、バリヤ同期、グループ・メンバシップ、およびグ
ループ状態値など複数の機構を含む単一の統一されたプ
ロトコルを提供する。グループ・メンバシップとグルー
プ状態値のためのプロトコルの使い方について以下に詳
述する。

【００７１】前述の投票機構を本発明の原理により使用
して、プロセス・グループのメンバシップの変更を提案
する。たとえば、プロセスがプロセス・グループＸなど
の特定のプロセス・グループに加入したい場合、そのプ
ロセスは加入呼出しを発行する（ステップ１２００「加
入要求を出す」（図１４））。一実施例では、この呼出
しはメッセージとしてローカル通信経路（たとえばＵＮ
ＩＸドメイン・ソケット）で要求側プロセスを実行して
いるプロセッサ上のグループ・サービス・デーモンに送
られる。グループ・サービス・デーモンはネーム・サー
バに要求側プロセスが加入したいプロセス・グループの
グループ・リーダの名前を問い合わせるメッセージをネ
ーム・サーバに送る（ステップ１２０２「グループ・リ
ーダを判断する」）。

【００７２】この要求がその特定のプロセス・グループ
への最初の加入要求である場合、ネーム・サーバはグル
ープ・サービス・デーモンにそれがグループ・リーダで
あることを通知する（照会１２０４「最初の加入要求か
？」）。したがって、前述のようにプロセッサはプロセ
ッサ・グループを作成し、プロセスをプロセス・グルー
プに加える（ステップ１２１０「プロセスを追加す
る」）。具体的には、プロセスはそのプロセス・グルー
プのメンバシップ・リストに追加される。このメンバシ
ップ・リストはグループ・サービスによってたとえば順
序づけられたリストとして維持される。一実施例では、
リストは加入順に順序づけられる。最初に加入したプロ
セスがリストの最初になり、以下同様である。

【００７３】本発明の原理によると、プロセス・グルー
プに最初に加入するプロセスによってそのグループの属
性のセットが識別される。これらの属性はプロセスによ
って送られる加入呼出しに引数として組み込まれる。こ
れらの属性には、たとえば、固有識別子であるグループ
名や、グループが様々なプロトコルをどのように管理し
たいかをグループ・サービスに対して定義する事前指定
情報が含まれる。たとえば、この属性にはプロセス・グ
ループが、後述するバッチ要求を受け入れるかどうかを
示す標識を含めることができる。さらに、他の実施例で
は、属性には、たとえば各提供者におけるプログラミン
グのソフトウェア・レベルを表すクライアントのバージ
ョン番号を含めることができる。これによって、すべて
のグループ・メンバが同じレベルになるように保証する
ことができる。上記の属性は単に一例に過ぎない。特許
請求の発明の精神から逸脱することなく、追加の属性ま
たは異なる属性を含めることができる。

【００７４】照会１２０４「最初の加入要求か？」に戻
って、これが最初の加入要求ではない場合、その加入要
求はネーム・サーバによって指定されたグループ・リー
ダにメッセージを介して送られる（ステップ１２１４
「グループ・リーダに加入要求を送る」）。グループ・
リーダは事前スクリーニング・テストを行う（ステップ
１２１６「事前スクリーン」）。具体的には、グループ
・リーダは要求側プロセスによって指定された属性がグ
ループの最初のプロセスによって設定された属性と同じ
かどうかを判断する。同じでない場合、加入要求は拒否
される。

【００７５】しかし、事前スクリーニング・テストに合
格した場合は、プロセス・グループの提供者に対してた
とえばグループ・リーダからのマルチキャストを介して
その要求が通知され、提供者はそのプロセスをグループ
に加えることを許可するかどうかについて投票する（ス
テップ１２２０「投票する」）。投票は前述のようにし
て行われる。提供者は、そのプロトコルを継続すること
を票決してこの加入について再び投票するか、または加
入を拒否または承認することを票決することができる。
提供者の１つがＲＥＪＥＣＴを投票した場合、その加入
は終了させられ、プロセスはグループに加えられない
（照会１２２２「成功か？」）。しかし、すべての提供
者がＡＰＰＲＯＶＥに投票した場合、プロセスはグルー
プに加えられる（ステップ１２２４「プロセスを追加す
る」）。具体的には、プロセスはグループのメンバシッ
プ・リストの最後に追加される。プロトコルが完了する
と、グループのメンバにその結果が通知される。具体的
には、一実施例ではプロセスが追加され場合はすべての
メンバ（提供者と加入者を含む）に通知されるが、プロ
トコルが拒否された場合は提供者のみに通知される。他
の実施例では、適切とみなされる場合には他のタイプの
メンバにも通知することができる。

【００７６】前述のように提供者は加入要求を使用して
プロセス・グループに加入する。提供者には投票権など
の特定の利便が与えられる。プロセスもプロセス・グル
ープに加入することができるが、（加入呼出しとは異な
る）ＡＰＩ加入呼出しを発行することによって加入す
る。加入者は特定のプロセス・グループを監視すること
ができるが、グループに関与することはできない。

【００７７】加入呼出しが発行されると、そのプロセッ
サ上のグループ・サービスに転送され、そのグループ・
サービス・デーモンがその呼出しを追跡する。グループ
・サービス・デーモンがそのプロセッサ・グループに属
していない場合は、前述のようにそのグループに挿入さ
れることになる。一実施例では、この加入者に関する投
票はなく、提供者および他の加入者を含むグループの他
のメンバはその加入者を認識しない。加入者はまだ作成
されていないプロセス・グループに加入することはでき
ない。

【００７８】グループ・メンバシップは、グループを離
脱したりグループから除去されるグループ・メンバによ
って変更されることもある。一実施例では、グループを
離脱したいグループ・メンバは前述のようにしてグルー
プ・リーダに離脱要求を送る（ステップ１３００「離脱
要求を出す」（図１５））。グループ・リーダは提供者
にマルチキャストを送り、提案された変更について投票
するように提供者に要求する（ステップ１３０２「投票
する」）。この投票は前述のようにして行われ、すべて
の提供者がＡＰＰＲＯＶＥに投票した場合（照会１３０
４）、そのプロセス・グループのメンバシップ・リスト
からプロセスが除去され（ステップ１３０６「プロセス
を除去する」）、すべてのグループ・メンバにその変更
が通知される。しかし、提供者の１つがＲＥＪＥＣＴを
投票した場合、プロセスはそのプロセス・グループの一
員として留まり、プロトコルが終了し、提供者にプロト
コルの拒否が通知される。提供者のいずれもＲＥＪＥＣ
Ｔを投票せず、提供者のいずれか１つがＣＯＮＴＩＮＵ
Ｅを投票した場合は、当然、そのプロトコルの投票がも
う１回継続される。

【００７９】グループのメンバは、グループの他のプロ
セスによって提案された追放プロトコルの承認によって
グループから追放された場合、またはそのグループ・メ
ンバが障害を起こしたりそのメンバを実行しているプロ
セッサが障害を起こした場合、グループを非自発的に離
脱することがある。追放の行われ方は、メンバがグルー
プの離脱を要求する場合について前述したのと同じであ
るが、要求が離脱を希望するプロセスによって出される
のではなく、グループから他のプロセスを除去したいプ
ロセスによって要求が行われる点が異なる。

【００８０】同様に、一実施例ではプロセスが障害を起
こした場合またはプロセスを実行しているプロセッサが
障害を起こした場合、そのプロセスを除去する技法は、
離脱を要求するプロセスを除去するために使用する技法
と同様である。ただし、そのプロセスが離脱を要求する
のではなく、以下で説明するようにグループ・サービス
によって要求が出される。

【００８１】プロセスが障害を起こした場合、一実施例
では障害を起こしたプロセスのプロセッサ上で稼働して
いるグループ・サービス・デーモンによってその障害が
グループ・リーダに通知される。グループ・サービス・
デーモンは、プロセスに関連づけられた（当業者には周
知の）ストリーム・ソケットが障害を起こしたことを検
出すると、プロセスが障害を起こしたと判断する。そう
すると、グループ・リーダは除去を開始する。

【００８２】プロセッサ障害の場合、グループ・リーダ
はその障害を検出し、除去要求を出す。障害を起こした
のがグループ・リーダである場合、要求が出される前
に、本明細書に記載の通りグループ・リーダ回復が行わ
れる。一実施例では、グループ・リーダには、ネットワ
ークの処理ノード全体にわたって分散されたサブシステ
ムによってプロセッサ障害が通知される。このサブシス
テムは、すべての処理ノードに信号を送出し、その信号
に特定のノードが肯定応答しない場合、そのノードはダ
ウンした（または障害を起こした）とみさなれる。次に
この情報がグループ・サービスにブロードキャストされ
る。

【００８３】前述のようにプロセスがグループに加わり
たい場合、またはグループ・メンバがグループを離脱し
たいかまたはグループから除去される場合、グループ・
リーダは各グループ提供者に提案された変更を通知し、
それによって提供者はその変更について投票することが
できるようになる。本発明の原理によると、これらの提
案されたメンバシップ変更は、グループ提供者に１つず
つ（すなわち、１つのプロトコルについて１つの提案グ
ループ・メンバシップ変更）またはバッチ（すなわち、
１つのプロトコルについて複数の提案グループ・メンバ
シップ変更）で提示する。バッチ要求の場合、グループ
・リーダは一例として、所定の時間のあいだ要求を収集
してから、グループ提供者に１つまたは複数のバッチ要
求を提示する。具体的には、その時間中に収集されたす
べての加入要求を含む１つのバッチ要求が送られ、収集
されたすべての離脱要求または除去要求を含む別のバッ
チ要求が送られる。一実施例では、１つのバッチ要求に
はすべて加入またはすべて離脱（および除去）のみを含
めることができ、その両方を組み合わせて含めることは
できない。これは１つの例にすぎない。他の実施例で
は、両方のタイプの要求を組み合わせることができる。

【００８４】バッチ要求がグループ提供者に転送される
と、グループ提供者はそのバッチ要求全体をひとまとま
りとして投票する。したがって、バッチ全体が受け入れ
られるか、継続されるか、または拒否される。

【００８５】本発明の原理によると、各プロセス・グル
ープは要求をバッチ処理することを許可するかどうかを
決めることができる。さらに、各プロセス・グループは
あるタイプの要求をバッチ処理することができるように
し、他のタイプの要求をできないようにするかどうかを
決定することができる。たとえば、ネットワークで実行
されているプロセス・グループがいくつかあるとする。
プロセス・グループＷはすべてのタイプの要求について
バッチ要求を受け取ると決定し、プロセス・グループＸ
はそれとは独立してすべての要求を逐次に受け取ると決
定することができる。さらに、プロセス・グループＹは
加入要求のみのバッチ要求を許し、プロセス・グループ
Ｚは離脱または除去要求のバッチ要求のみを許すことが
できる。したがって、本発明の機構は要求の提示の仕方
と投票の仕方に柔軟性がある。

【００８６】このシステムは柔軟性があるが、グループ
・メンバシップの整合性と信頼性を保証するために本発
明の一実施例で定めたいくつかの規則がある。これらの
規則には一例として以下のものが含まれる。 １．どのグループ・メンバもそのグループに加わる以前
に、障害を起こすことやグループを離脱することが明ら
かにされてははならない。 ２．どのグループ・メンバもその初期障害が処理済みに
なる前に、再びグループに加入することが明らかにされ
てはならない。 ３．グループが加入要求を持っており、しかも障害状態
の定着メンバを持っている場合、障害を起こしたすべて
のメンバを（１つまたは複数の障害プロトコルを使用し
て）処理してからでなければどの加入要求も満たすこと
ができない。 ４．加入を要求している提供者を含むすべての非障害グ
ループ提供者が同じ順序のプロトコルとメンバシップ・
リストを見る。

【００８７】以上、本発明の投票プロトコルをどのよう
に使用してグループ・メンバシップを管理するかを詳述
した。しかし、本発明の原理によると投票プロトコルは
グループ状態値の提案にも使用することができる。具体
的には、投票フェーズ中に、提供者またはプロセス・グ
ループは、投票値の提供に加えてグループの状態値の変
更を提案することができる。これによって、グループ提
供者がグループ情報を他のグループ・メンバに信頼性と
整合性をもたせて反映させることができる。一実施例で
は、グループ状態値（およびメッセージ、更新された投
票値など本明細書に記載されているその他の情報）が、
様々な引数の提示を可能にする投票インタフェースを介
して投票値と共に提供される。

【００８８】たとえば、メンバがグループに加わったり
グループから離脱したりする場合、グループは前述のよ
うに複数ステップ・プロトコルを使用して駆動される。
各投票ステップ中に、グループ・メンバはローカル・ア
クションを行って新しいメンバのための準備をしたり、
障害を起こしたメンバの損失を回復したりする。これら
のローカル・アクションの結果に基づいて、たとえば、
１つまたは複数の提供者がグループ状態値の修正を決定
することができる。一実施例では、グループ状態値は
「アクティブ」になって、処理グループがサービス要求
を受入れ可能であることを示したり、「非アクティブ」
になって、プロセス・グループがたとえばそのグループ
が十分なメンバを持っていないために停止していること
を示したり、「中断」になって、プロセス・グループは
要求を受け入れるが、一時的に要求を処理していないこ
とを示したりすることができる。

【００８９】グループ・サービスは、グループ状態値の
更新が調整されるように保証して、グループ提供者が同
じ整合性ある値を見られるようにする。プロトコルがＡ
ＰＰＲＯＶＥＤの場合、最新の更新済み提案グループ状
態値が新しいグループ状態値である。プロトコルがＲＥ
ＪＥＣＴＥＤの場合、グループの状態値は拒否されたプ
ロトコルが実行を開始する前の状態のままである。

【００９０】本発明の原理によると、投票プロトコルを
使用してグループ・メンバにメッセージをマルチキャス
トすることができる。たとえば、投票値を送るほかに、
提供者はプロセス・グループの他のすべてのメンバに転
送するメッセージを組み込むことができる。グループ状
態値とは異なり、このメッセージは持続性がない。グル
ープ・メンバに示された後は、グループ・サービスはそ
のメッセージを追跡しない。しかし、グループ・サービ
スはすべての非障害グループ提供者に配布されるように
保証する。

【００９１】メッセージはグループ提供者が、たとえば
プロトコル中に投票内の他の応答では伝えることができ
ない重要な情報を転送するために使用することができ
る。たとえば、提供者の投票値に反映することができな
い情報を提供したり、持続性を持たせる必要がない情報
を提供するために使用することができる。一実施例で
は、メッセージによってグループ・メンバに特定の機能
が実行されることを通知することができる。

【００９２】本発明の一実施例によると、プロセス・グ
ループの各提供者はプロトコルの投票フェーズで投票す
ることが求められる。すべての提供者が投票するまで、
プロトコルは完了しないままである。したがって、１つ
または複数の提供者が投票を送っていないという状況を
処理するために、本発明の原理によると、投票プロトコ
ルに１つの機構を設ける。具体的には、この投票機構は
以下で詳述する省略時の投票値を組み込む。

【００９３】たとえば、本明細書に記載のように、プロ
トコルの実行中に提供者に障害が発生した場合や、提供
者が実行しているプロセッサが障害を起こした場合や、
提供者が無応答になった場合に省略時の投票値を使用す
る。省略時の投票値によってプロトコルとプロセス・グ
ループの処理の進行をはかどらせることができる。プロ
セス・グループは、グループがたとえばその属性によっ
て最初に形成されるときにそのグループの省略時の投票
値を初期設定する。一実施例では、省略時の投票地はＡ
ＰＰＲＯＶＥまたはＲＥＪＥＣＴとすることができる。
各投票フェーズ中に、グループ内の変化する条件を反映
するように省略時の投票値を変更することができる。

【００９４】プロトコル中にプロセスに障害が発生した
状況では、前述のようにグループ・サービスがそれを判
断し、したがってプロトコルのどの投票フェーズであっ
ても、グループ・リーダが、障害を起こしたプロセスの
ためにグループの現行省略時投票値を受け渡しすること
になる。同様に、メンバ提供者を実行しているプロセッ
サが障害を起こしたとグループ・サービスが判断した場
合も、グループ・リーダは再度、省略時投票値を受け渡
しする。

【００９５】しかし、プロセッサまたはプロセスが使用
可能であるが無応答の場合も、省略時の投票値を使用す
ることができる。一実施例では、プロセスは、当該プロ
トコルのためにプロセス・グループによって設定された
制限時間内に投票に応答しない場合に無応答とみなされ
る。（各プロセス・グループの各プロトコルがそれ独自
の制限時間を持つことができる。）プロセスが無応答の
場合、プロセス・グループに割り当てられた省略時の投
票値がグループ・リーダによってその特定のプロセスの
ために使用される。一実施例では、制限時間を設けない
ことも可能である。そのような状況では、グループ・サ
ービスは提供者が最終的に応答するかまたは提供者が障
害を起こすまで待つことになる。

【００９６】一実施例では、省略時の投票値を使用する
場合、提供者にそれが通知される。

【００９７】本発明の原理によると、提供者はプロトコ
ル内のどの１つまたは複数の投票ステップでも省略時の
投票値を動的に更新することができる。これによって、
プロトコルの進行とともに障害を処理する柔軟性が与え
られる。提案された省略時値はプロセスの投票値と共に
受け渡しされる。新しい省略時投票値は、後の投票ステ
ップで別の省略時投票値が提案されない限り、プロトコ
ルの残りの期間中有効であり続ける。特定の投票ステッ
プで複数の省略時投票値が提案された場合、一実施例で
は、グループ・サービス（すなわちグループ・リーダ）
は最初に応答したプロセスによって受け渡しされた値を
選択する。プロトコルが完了すると、プロセス・グルー
プの省略時投票値はそのグループのために最初に設定さ
れた値に戻る。

【００９８】省略時投票値は他のあらゆる投票値と同じ
ように扱われる。しかし、一実施例では省略時投票値
は、たとえばメッセージ、グループ状態値、新たに提案
された更新省略時投票値など、投票のための他の情報を
含むことができない。

【００９９】図１３を参照しながら前述したように、前
記のすべての提案プロトコルは１フェーズ・プロトコル
として提案することができる。１フェーズ・プロトコル
では、プロトコルが１つのマルチキャストで提案され、
受け入れられる。したがって、票決をとる必要がない。

【０１００】以上、可用性の高いマルチコンピュータ・
アプリケーションを確実に実現する機構について詳述し
た。一例として、本発明の機構を使用してフォールトト
レラントの高可用性システムを実現することができる。
本発明の機構は、システム内で実行されているプロセス
・グループの状態に加えられる変更の調整、管理、およ
び監視を行う汎用機能を提供するので有利である。

【０１０１】本発明の原理によると、プロセッサ・グル
ープ内のおよびプロセス・グループ内のメンバシップを
動的に更新することができる。いずれの場合も、プロセ
ッサまたはプロセスをグループへの追加またはグループ
からの除去を要求することができる。本発明の機構によ
って、これらの変更が整合性と信頼性のある仕方で行わ
れるようになる。

【０１０２】さらに、本発明の原理によると、メッセー
ジを１つまたは複数の特定のプロセッサ・グループに送
ることができるようにし、すべてのプロセッサ・グルー
プにメッセージを送らなくても済むようにする機構が提
供される。各プロセッサ・グループは、それ自体のメッ
セージのセットの監視と管理を行うことができ、１つま
たは複数のメッセージを逸していないかどうかを判断す
ることができる。メッセージを逸している場合、そのメ
ッセージはグループの他のメンバから取り出すことがで
きる。これらのメッセージのために安定記憶装置を維持
する必要がない。各メンバがこれらのメッセージを持っ
ており、したがって逸したメッセージを他のメンバに供
給することができる。これは、ハードウェアの費用が低
減されるので有利である。

【０１０３】さらに、本発明の原理によると、障害を起
こしたグループ・リーダから回復する機構が提供され
る。これらの機構によって、新しいグループ・リーダが
容易かつ効率的に選択されるようになる。

【０１０４】また、本発明の機構は、プロセスのために
いくつかのプロトコルを単一の統合フレームワークに統
一するアプリケーション・プログラミング・インタフェ
ースも提供する。一例として、この統合アプリケーショ
ン・プログラミング・インタフェースは、プロセス・グ
ループのメンバ間で通信する機能と、プロセス・グルー
プのプロセスを同期させる機能を備える。さらに、この
同じインタフェースは、プロセス・グループのメンバシ
ップ変更とグループ状態値の変更を扱う機能も備える。

【０１０５】このアプリケーション・プログラミング・
インタフェースは、グループ・サービスがプロセスの応
答性を監視することができるようにする機構も備える。
これは、コンピュータ・ネットワーク通信で使用される
ＰＩＮＧ機構と同様にして行うことができる。

【０１０６】以上に加えて、本発明の機構は動的バリヤ
同期技法を提供する。本発明の原理によると、任意の１
つのプロトコルに含まれる同期フェーズの数は可変であ
り、メンバがそのプロトコルに投票することによって決
定することができる。

【０１０７】本発明の機構は、本発明の機構を提供し支
援するコンピュータ可読プログラム・コード手段が含ま
れたコンピュータ使用可能媒体を含む、１つまたは複数
のコンピュータ・プログラム製品に組み込むことができ
る。これらの製品はコンピュータ・システムの一部とし
て組み込むことも別途に販売することもできる。

【０１０８】本明細書に図示する流れ図は例に過ぎな
い。本発明の精神から逸脱することなく、これらの図ま
たは図に図示されているステップには多くの様々な変形
が考えられる。たとえば、それらのステップを異なる順
序で行ったり、ステップを追加、削除、または修正した
りすることができる。これらの変形はすべて特許請求の
範囲の発明の一部とみなされる。

【０１０９】本明細書では好ましい実施例を図示し、詳
述したが、当業者には、本発明の精神から逸脱すること
なく様々な修正、追加、代替策などを行うことができる
ことが明であろう。したがって、それらは特許請求の範
囲に記載の本発明の範囲内に入るものとみなされる。

【０１１０】まとめとして、本発明の構成に関して以下
の事項を開示する。

【０１１１】（１）分散コンピューティング環境におけ
るプロセッサ・グループのグループ・リーダに発生した
障害から回復する方法であって、前記プロセッサ・グル
ープへのプロセッサの加入の順序で順序づけられたメン
バシップ・リストから、前記メンバシップ・リスト内の
次のプロセッサを入手するステップと、前記次のプロセ
ッサを前記プロセッサ・グループの新しいグループ・リ
ーダとして選択するステップとを含む方法。 （２）前記入手するステップが、前記メンバシップ・リ
ストから次のアクティブ・プロセッサを入手するステッ
プを含むことを特徴とする、上記（１）に記載の方法。 （３）前記プロセッサ・グループに前記新しいグループ
・リーダを通知するステップをさらに含む、上記（１）
に記載の方法。 （４）ネーム・サーバが前記新しいグループ・リーダを
前記メンバシップ・リストから選択する、前記新しいグ
ループ・リーダの任命を前記ネーム・サーバに要求する
ステップをさらに含む、上記（１）に記載の方法。 （５）前記メンバシップ・リストが前記プロセッサ・グ
ループの各プロセッサにあることを特徴とする、上記
（１）に記載の方法。 （６）前記入手するステップが、前記プロセッサ・グル
ープのプロセッサが前記プロセッサにある前記メンバシ
ップ・リストから前記新しいグループ・リーダを入手す
るステップを含み、ネーム・サーバに前記新しいグルー
プ・リーダを通知するステップをさらに含むことを特徴
とする、上記（５）に記載の方法。 （７）前記ネーム・サーバが前記プロセッサ・グループ
に前記新しいグループ・リーダを通知するステップをさ
らに含む、上記（６）に記載の方法。 （８）前記新しいグループ・リーダが、前記新しいグル
ープ・リーダが前記新しいグループ・リーダとして選択
される前に、前記プロセッサ・グループに以前に送られ
たメッセージを受け取るステップをさらに含む、上記
（１）に記載の方法。 （９）前記新しいグループ・リーダが前記プロセッサ・
グループのいずれかのプロセッサが逸したメッセージを
提供するステップをさらに含む、上記（８）に記載の方
法。 （１０）前記新しいグループ・リーダに要求を送るステ
ップをさらに含む、上記（１）に記載の方法。

【図面の簡単な説明】

【図１】本発明の原理を組み込んだ分散コンピューティ
ング環境の一例を示す図である。

【図２】本発明の原理による、図１の分散コンピューテ
ィング環境のいくつかの処理ノードの拡大図の一例を示
す図である。

【図３】本発明の原理による、「グループ・サービス」
機能の構成要素の一例を示す図である。

【図４】本発明の原理による、プロセッサ・グループの
一例を示す図である。

【図５】本発明の原理による、図４のプロセッサ・グル
ープの障害を起こしたグループ・リーダの回復に関連す
る論理の一例を示す図である。

【図６】本発明の原理による、図４のプロセッサ・グル
ープの障害を起こしたグループ・リーダの回復に関連す
る論理の他の一例を示す図である。

【図７】本発明の原理による、グループ・リーダの一例
を示す図である。

【図８】本発明の原理による、現行グループ・リーダが
障害を起こした場合に新しいグループ・リーダを選択す
る技法を示す図である。

【図９】本発明の原理による、グループ・リーダから情
報を受け取るネーム・サーバの一例を示す図である。

【図１０】本発明の原理による、プロセッサ・グループ
へのプロセッサの追加に関連する論理の一例を示す図で
ある。

【図１１】本発明の原理による、プロセッサ・グループ
からのプロセッサの離脱に関連する論理の一例を示す図
である。

【図１２】本発明の原理による、プロセス・グループの
一実施例を示す図である。

【図１３】本発明の原理による、プロセス・グループの
プロトコルの処理に関連する論理の一例を示す図であ
る。

【図１４】本発明の原理による、プロセス・グループへ
の加入を要求するプロセスに関連する論理の一例を示す
図である。

【図１５】本発明の原理による、グループからの離脱を
要求するプロセス・グループのメンバに関連する論理の
一例を示す図である。

【符号の説明】

１００ 分散コンピューティング環境 １０２ フレーム １０４ ＬＡＮゲート １０６ 処理ノード ２００ グループ・サービス・デーモン ２０２ プロセス ２０４ アプリケーション・プログラミング・インタフ
ェース ３０２ 内部層 ３０４ 外部層 ４００ プロセッサ・グループ ７００ ネーム・サーバ

───────────────────────────────────────────────────── フロントページの続き (72)発明者 トゥシャル・デーパク・チャンドラ アメリカ合衆国10523 ニューヨーク州エ ルムズフォード ノッブ・ヒル・ドライブ 215 (72)発明者 オーヴァル・セオドア・カービー アメリカ合衆国12601 ニューヨーク州ポ キプシーデイヴィッド・ドライブ 32 (72)発明者 ジョン・アーサー・パーシング、ジュニア アメリカ合衆国10511 ニューヨーク州ブ キャナンコートラント・ストリート 162

Claims (10)

【特許請求の範囲】
1. 【請求項１】分散コンピューティング環境におけるプロ
   セッサ・グループのグループ・リーダに発生した障害か
   ら回復する方法であって、 前記プロセッサ・グループへのプロセッサの加入の順序
   で順序づけられたメンバシップ・リストから、前記メン
   バシップ・リスト内の次のプロセッサを入手するステッ
   プと、 前記次のプロセッサを前記プロセッサ・グループの新し
   いグループ・リーダとして選択するステップとを含む方
   法。
2. 【請求項２】前記入手するステップが、前記メンバシッ
   プ・リストから次のアクティブ・プロセッサを入手する
   ステップを含むことを特徴とする、請求項１に記載の方
   法。
3. 【請求項３】前記プロセッサ・グループに前記新しいグ
   ループ・リーダを通知するステップをさらに含む、請求
   項１に記載の方法。
4. 【請求項４】ネーム・サーバが前記新しいグループ・リ
   ーダを前記メンバシップ・リストから選択する、前記新
   しいグループ・リーダの任命を前記ネーム・サーバに要
   求するステップをさらに含む、請求項１に記載の方法。
5. 【請求項５】前記メンバシップ・リストが前記プロセッ
   サ・グループの各プロセッサにあることを特徴とする、
   請求項１に記載の方法。
6. 【請求項６】前記入手するステップが、前記プロセッサ
   ・グループのプロセッサが前記プロセッサにある前記メ
   ンバシップ・リストから前記新しいグループ・リーダを
   入手するステップを含み、ネーム・サーバに前記新しい
   グループ・リーダを通知するステップをさらに含むこと
   を特徴とする、請求項５に記載の方法。
7. 【請求項７】前記ネーム・サーバが前記プロセッサ・グ
   ループに前記新しいグループ・リーダを通知するステッ
   プをさらに含む、請求項６に記載の方法。
8. 【請求項８】前記新しいグループ・リーダが、前記新し
   いグループ・リーダが前記新しいグループ・リーダとし
   て選択される前に、前記プロセッサ・グループに以前に
   送られたメッセージを受け取るステップをさらに含む、
   請求項１に記載の方法。
9. 【請求項９】前記新しいグループ・リーダが前記プロセ
   ッサ・グループのいずれかのプロセッサが逸したメッセ
   ージを提供するステップをさらに含む、請求項８に記載
   の方法。
10. 【請求項１０】前記新しいグループ・リーダに要求を送
    るステップをさらに含む、請求項１に記載の方法。