JPH1040229A - 分散コンピューティング環境におけるプロセッサ・グループへの加入を管理するためのシステム - Google Patents

Abstract

(57)【要約】 【課題】 分散コンピューティング環境においてプロセ
ッサのグループのメンバシップを管理するシステムを提
供する。 【解決手段】 グループのメンバシップを管理するため
に特定のアクションを識別し、実行する。プロセッサが
プロセッサのグループへの加入を要求し、そのグループ
に加えられる。同様に、プロセッサはグループからの離
脱を要求したり、障害が発生してグループから除去され
たりすることができる。また、メンバのグループは、グ
ループのうちの１つのメンバからグループのうちの他の
メンバに対して出されたマルチキャストを受け取る。さ
らに、分散コンピューティング環境内のプロセッサの各
グループは、メンバのグループのために行われるアクシ
ョンを制御するグループ・リーダを持つ。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は一般には分散コンピ
ューティング環境に関し、具体的には分散コンピューテ
ィング環境のプロセッサのグループ内におけるメンバシ
ップの管理に係わる。

【０００２】

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

【０００３】

【発明が解決しようとする課題】しかし、プロセッサ
が、関連性のあるプロセスを実行するプロセッサ・グル
ープのメンバになれるようにする機構が必要である。す
なわち、アクションをグループ単位で行うことができる
ようにし、プロセッサがグループのメンバになることを
要求することができるようにする機構が必要である。さ
らに、プロセッサ・グループのメンバがグループを離脱
したり、グループから除去されたりすることを可能にす
る機構が必要である。さらに、グループのメンバにメッ
セージをマルチキャストすることができるようにする機
構が必要である。

【０００４】

【課題を解決するための手段】分散コンピューティング
環境においてプロセッサのグループを維持する機構を設
けることによって、従来の技術の欠点が克服され、追加
の利点が得られる。分散コンピューティング環境のプロ
セッサ・グループが行うべき指定アクションが特定さ
れ、そのアクションが実行される。一実施例では、指定
アクションには、プロセッサ・グループにそのグループ
への加入を要求しているプロセッサを追加することや、
メンバ・プロセッサの１つから他のメンバ・プロセッサ
のうちのいずれかに対してメッセージをマルチキャスト
することや、メンバ・プロセッサがグループからの離脱
を要求した場合またはメンバ・プロセッサが障害を起こ
した場合にそのプロセッサをグループから除去すること
や、プロセッサ・グループのグループ・リーダを維持す
ることが含まれる。

【０００５】本発明の他の態様では、分散コンピューテ
ィング環境においてプロセッサのグループに加入する機
構を設ける。プロセッサが、関連性のあるプロセスを含
むプロセッサ・グループに加入するよう要求し、そのプ
ロセッサがそのグループに加えられる。他の実施例で
は、プロセッサが離脱を要求する場合、またはプロセッ
サが障害を起こした場合、プロセッサ・グループからそ
のプロセッサが除去される。

【０００６】本発明の他の実施形態では、グループのう
ちの１つのプロセッサからグループの任意の他のプロセ
ッサにメッセージが送られる。さらに、グループにグル
ープ・リーダを設け、たとえばグループに加入する要求
がグループ・リーダに転送される。

【０００７】本発明のグループのメンバシップ管理技法
によって、アクションをグループ単位で行えるようにな
るので有利である。各グループは、それぞれのプロセッ
サがたとえば、グループ・アクションの実施に関与する
単一の「グループ・サービス」デーモンを実行するプロ
セッサを含む。プロセッサのグループを集合的にメタグ
ループ層と呼び、メタグループ層はグループ・アクショ
ンを行う単純な機構を提供する。

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

【０００９】

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【０１１２】（１）分散コンピューティング環境におい
てプロセッサ・グループへの加入を管理するためのシス
テムであって、関連性のあるプロセスを実行するプロセ
ッサ・グループへの加入を要求するようにプログラム可
能なプロセッサと、前記プロセッサを前記プロセッサ・
グループに追加する手段とを含むシステム。 （２）前記プロセッサ・グループに前記加入を通知する
手段をさらに含む、上記（１）に記載のシステム。 （３）前記プロセッサ・グループのうちの１つのプロセ
ッサから前記プロセッサ・グループのうちの他のプロセ
ッサにメッセージを送る手段をさらに含む、上記（１）
に記載のシステム。 （４）前記プロセッサ・グループからプロセッサを除去
する手段をさらに含む、上記（１）に記載のシステム。 （５）前記除去する手段が前記プロセッサ・グループの
メンバシップ・リストから前記プロセッサを削除する手
段を含むことを特徴とする、上記（４）に記載のシステ
ム。 （６）前記プロセッサ・グループに前記プロセッサの除
去を通知する手段をさらに含む、上記（４）に記載のシ
ステム。 （７）前記削除する手段が、前記プロセッサに障害が発
生した場合に前記プロセッサ・グループから前記プロセ
ッサを除去する手段を含むことを特徴とする、上記
（４）に記載のシステム。 （８）前記除去する手段が、前記プロセッサが前記プロ
セッサ・グループを離脱することを要求した場合に前記
プロセッサ・グループから前記プロセッサを除去する手
段を含むことを特徴とする、上記（４）に記載のシステ
ム。 （９）前記プロセッサ・グループに加入する前記要求を
前記プロセッサ・グループのグループ・リーダ・プロセ
ッサに供給する手段をさらに含むことを特徴とする、上
記（１）に記載のシステム。 （１０）前記追加する手段が、前記グループ・リーダ・
プロセッサによって前記プロセッサ・グループの他のプ
ロセッサに前記加入を通知する手段を含むことを特徴と
する、上記（９）に記載のシステム。 （１１）前記グループ・リーダ・プロセッサを探し出す
ように適合可能なネーム・サーバをさらに含み、前記ネ
ーム・サーバは前記分散コンピューティング環境のプロ
セッサを含むことを特徴とする、上記（９）に記載のシ
ステム。 （１２）前記ネーム・サーバが前記プロセッサ・グルー
プのメンバであることを特徴とする、上記（１１）に記
載のシステム。 （１３）前記ネーム・サーバが前記プロセッサ・グルー
プとは独立していることを特徴とする、上記（１１）に
記載のシステム。 （１４）前記追加する手段が、前記プロセッサ・グルー
プのメンバシップ・リストを更新する手段を含むことを
特徴とする、上記（１）に記載のシステム。 （１５）前記メンバシップ・リストが前記プロセッサ・
グループの各プロセッサにあり、前記更新ステップが、
前記プロセッサ・グループの各プロセッサに前記加入を
通知する手段と、各プロセッサによって前記メンバシッ
プ・リストを更新する手段を含むことを特徴とする、上
記（１４）に記載のシステム。 （１６）分散コンピューティング環境においてプロセッ
サ・グループを維持するシステムであって、プロセッサ
・グループが１つまたは複数のメンバ・プロセッサを含
み、前記１つまたは複数のメンバ・プロセッサのそれぞ
れのメンバ・プロセッサが関連性のあるプロセスを含
む、前記分散コンピューティング環境の前記プロセッサ
・グループのために行うべき指定アクションを識別する
手段と、前記プロセッサ・グループのために前記指定ア
クションを行う手段とを含むシステム。 （１７）前記指定アクションが、（ａ）プロセッサが前
記プロセッサ・グループへの加入を要求している、挿入
と、（ｂ）前記１つまたは複数のメンバ・プロセッサが
前記プロセッサ・グループの他のメンバ・プロセッサに
メッセージを転送することを要求している、マルチキャ
ストと、（ｃ）前記１つまたは複数のメンバ・プロセッ
サが前期プロセッサ・グループからの離脱を要求してい
る、離脱と、（ｄ）前記１つまたは複数のメンバ・プロ
セッサのうちの１つのメンバに障害が発生した場合に前
記１つのメンバが前記プロセッサ・グループから除去さ
れる、除去と、（ｅ）前記プロセッサ・グループのグル
ープ・リーダの維持とのうちのいずれかを含むことを特
徴とする、上記（１６）に記載のシステム。

【図面の簡単な説明】

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【符号の説明】

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

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

Claims (17)

【特許請求の範囲】
1. 【請求項１】分散コンピューティング環境においてプロ
   セッサ・グループへの加入を管理するためのシステムで
   あって、 関連性のあるプロセスを実行するプロセッサ・グループ
   への加入を要求するようにプログラム可能なプロセッサ
   と、 前記プロセッサを前記プロセッサ・グループに追加する
   手段とを含むシステム。
2. 【請求項２】前記プロセッサ・グループに前記加入を通
   知する手段をさらに含む、請求項１に記載のシステム。
3. 【請求項３】前記プロセッサ・グループのうちの１つの
   プロセッサから前記プロセッサ・グループのうちの他の
   プロセッサにメッセージを送る手段をさらに含む、請求
   項１に記載のシステム。
4. 【請求項４】前記プロセッサ・グループからプロセッサ
   を除去する手段をさらに含む、請求項１に記載のシステ
   ム。
5. 【請求項５】前記除去する手段が前記プロセッサ・グル
   ープのメンバシップ・リストから前記プロセッサを削除
   する手段を含むことを特徴とする、請求項４に記載のシ
   ステム。
6. 【請求項６】前記プロセッサ・グループに前記プロセッ
   サの除去を通知する手段をさらに含む、請求項４に記載
   のシステム。
7. 【請求項７】前記削除する手段が、前記プロセッサに障
   害が発生した場合に前記プロセッサ・グループから前記
   プロセッサを除去する手段を含むことを特徴とする、請
   求項４に記載のシステム。
8. 【請求項８】前記除去する手段が、前記プロセッサが前
   記プロセッサ・グループを離脱することを要求した場合
   に前記プロセッサ・グループから前記プロセッサを除去
   する手段を含むことを特徴とする、請求項４に記載のシ
   ステム。
9. 【請求項９】前記プロセッサ・グループに加入する前記
   要求を前記プロセッサ・グループのグループ・リーダ・
   プロセッサに供給する手段をさらに含むことを特徴とす
   る、請求項１に記載のシステム。
10. 【請求項１０】前記追加する手段が、前記グループ・リ
    ーダ・プロセッサによって前記プロセッサ・グループの
    他のプロセッサに前記加入を通知する手段を含むことを
    特徴とする、請求項９に記載のシステム。
11. 【請求項１１】前記グループ・リーダ・プロセッサを探
    し出すように適合可能なネーム・サーバをさらに含み、
    前記ネーム・サーバは前記分散コンピューティング環境
    のプロセッサを含むことを特徴とする、請求項９に記載
    のシステム。
12. 【請求項１２】前記ネーム・サーバが前記プロセッサ・
    グループのメンバであることを特徴とする、請求項１１
    に記載のシステム。
13. 【請求項１３】前記ネーム・サーバが前記プロセッサ・
    グループとは独立していることを特徴とする、請求項１
    １に記載のシステム。
14. 【請求項１４】前記追加する手段が、前記プロセッサ・
    グループのメンバシップ・リストを更新する手段を含む
    ことを特徴とする、請求項１に記載のシステム。
15. 【請求項１５】前記メンバシップ・リストが前記プロセ
    ッサ・グループの各プロセッサにあり、前記更新ステッ
    プが、 前記プロセッサ・グループの各プロセッサに前記加入を
    通知する手段と、 各プロセッサによって前記メンバシップ・リストを更新
    する手段を含むことを特徴とする、請求項１４に記載の
    システム。
16. 【請求項１６】分散コンピューティング環境においてプ
    ロセッサ・グループを維持するシステムであって、 プロセッサ・グループが１つまたは複数のメンバ・プロ
    セッサを含み、前記１つまたは複数のメンバ・プロセッ
    サのそれぞれのメンバ・プロセッサが関連性のあるプロ
    セスを含む、前記分散コンピューティング環境の前記プ
    ロセッサ・グループのために行うべき指定アクションを
    識別する手段と、 前記プロセッサ・グループのために前記指定アクション
    を行う手段とを含むシステム。
17. 【請求項１７】前記指定アクションが、 （ａ）プロセッサが前記プロセッサ・グループへの加入
    を要求している、挿入と、 （ｂ）前記１つまたは複数のメンバ・プロセッサが前記
    プロセッサ・グループの他のメンバ・プロセッサにメッ
    セージを転送することを要求している、マルチキャスト
    と、 （ｃ）前記１つまたは複数のメンバ・プロセッサが前期
    プロセッサ・グループからの離脱を要求している、離脱
    と、 （ｄ）前記１つまたは複数のメンバ・プロセッサのうち
    の１つのメンバに障害が発生した場合に前記１つのメン
    バが前記プロセッサ・グループから除去される、除去
    と、 （ｅ）前記プロセッサ・グループのグループ・リーダの
    維持とのうちのいずれかを含むことを特徴とする、請求
    項１６に記載のシステム。