(57)【特許請求の範囲】
【請求項１】
分散コンピュータ環境におけるプロセッサ・ドメインのメンバーを管理する方法であって、
前記ドメイン内の使用可能な最小番号ノードを決定するステップと、
前記ドメイン内の前記最小番号ノードに対して他の使用可能なノードから追従メッセージを周期的に送信するステップと、
前記最小番号ノードが該最小番号ノードとは別のノードをみなしネーム・サーバ（ＲＮＳ）として認識していない場合、全ての前記追従メッセージを前記最小番号ノードが受信したことに応答して、前記ドメイン内の前記プロセッサを管理するために前記最小番号ノードがネーム・サーバとなるべく２段階コミット・プロトコルを実行するステップとを含み、
前記２段階コミット・プロトコルが、
前記最小番号ノードから前記他の使用可能なノードに対して第１段階（Ｐ１）挿入メッセージを送信するステップと、
前記第１段階挿入メッセージに応答して、前記最小番号ノードが前記ネーム・サーバとなることに同意する前記他の使用可能なノードから前記最小番号ノードに対して肯定（ＡＣＫ）メッセージを送信するステップと、
全ての前記肯定メッセージを前記最小番号ノードが受信したことに応答して、前記最小番号ノードが前記ネーム・サーバとなったことを前記他の使用可能なノードに対して通知するコミット・メッセージを送信するステップとを含み、
前記最小番号ノードが該最小番号ノードとは別のノードをみなしネーム・サーバ（ＲＮＳ）として認識している場合、該最小番号ノードによる追従メッセージの受信に応答して、該最小番号ノードから該追従メッセージを送信しているノードに対して該みなしネーム・サーバを識別するマイリーダー（ＭＬＩ）・メッセージを送信するステップと、
前記マイリーダー・メッセージの受信に応答して、前記マイリーダー・メッセージを受信した前記ノードから前記みなしネーム・サーバに対して追従メッセージを周期的に送信するステップと、
前記追従メッセージに応答して前記みなしネーム・サーバが、該みなしネーム・サーバを前記ネーム・サーバとして成立させるための前記２段階コミット・プロトコルを実行するステップとをさらに含む
プロセッサ・ドメインのメンバー管理方法。
【請求項２】
設定された時間間隔の間でのみ前記追従メッセージを受信するステップを含む
請求項１に記載の方法。
【請求項３】
分散コンピュータ環境におけるプロセッサ・ドメインのメンバーを管理する装置であって、
前記ドメイン内の使用可能な最小番号ノードを決定する手段と、
前記ドメイン内の前記最小番号ノードに対して他の使用可能なノードから追従メッセージを周期的に送信する追従メッセージ手段と、
前記最小番号ノードが該最小番号ノードとは別のノードをみなしネーム・サーバ（ＲＮＳ）として認識していない場合、全ての前記追従メッセージを前記最小番号ノードが受信したことに応答して、前記ドメイン内の前記プロセッサを管理するために前記最小番号ノードがネーム・サーバとなるべく２段階コミットを実行する２段階コミット手段とを備え、
前記２段階コミット手段が、
前記最小番号ノードから前記他の使用可能なノードに対して第１段階（Ｐ１）挿入メッセージを送信する手段と、
前記第１段階挿入メッセージに応答して、前記最小番号ノードが前記ネーム・サーバとなることに同意する前記他の使用可能なノードから前記最小番号ノードに対して肯定メッセージ（ＡＣＫ）を送信する肯定手段と、
全ての前記肯定メッセージを前記最小番号ノードが受信したことに応答して、前記最小番号ノードが前記ネーム・サーバとなったことを前記他の使用可能なノードに対して通知するコミット・メッセージを送信するコミット・メッセージ手段とを含み、
前記最小番号ノードが該最小番号ノードとは別のノードをみなしネーム・サーバ（ＲＮＳ）として認識している場合、該最小番号ノードによる追従メッセージの受信に応答して、該最小番号ノードから該追従メッセージを送信しているノードに対して該みなしネーム・サーバを識別するマイリーダー・メッセージを送信するマイリーダー（ＭＬＩ）・メッセージ手段と、
前記マイリーダー・メッセージの受信に応答して、前記マイリーダー・メッセージを受信した前記ノードから前記みなしネーム・サーバに対して追従メッセージを周期的に送信する第２の追従メッセージ手段と、
前記追従メッセージに応答して、前記みなしネーム・サーバにおいて該みなしネーム・サーバを前記ネーム・サーバとして成立させるために前記２段階コミットを実行する第２の２段階コミット手段とをさらに備える
プロセッサ・ドメインのメンバー管理装置。
【請求項４】
前記２段階コミット手段がタイマーによって設定された時間間隔の間でのみ前記追従メッセージを受信する請求項３に記載の装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、分散コンピュータ環境に関し、特に、分散コンピュータ環境における１又は複数のプロセッサからなるドメインのメンバーを管理することに関する。
【０００２】
【従来の技術】
分散コンピュータ環境におけるコンピュータは、並行にデータを処理する複数のコンピュータ・ノードを含む。このようなシステムの多くは、これらのノードを複数の区画へと組織化することができ、各区画が１又は複数のドメインを有する。各ドメインは、異なるコンピュータ・プログラムを同時に実行することができる。これらのシステムの多くにおいては、１つのノードが各ドメインを制御する。各ノードがラインに加わるか若しくは立ち上がることにより使用可能となると、そのノードはドメインへ割り当てられなければならず、そしてそのドメイン内の他のノードはその新しいノードを認知しなければならない。それにより、その区画内で実行中のプログラムのタスクを共有することができる。このことは、所与のシステムにおいては、各ノードがそのシステム内の他の各ノードへメッセージを送っていずれのノードがそのドメインを制御しているかそしていずれのタスクがいずれのノードへ割り当てられているか等の情報を判断することにより行われる。
【０００３】
利用度の高いアプリケーションにおいて、故障したノードを回復させる回復プロセスのある場合、回復しようとしているその故障したノードは、初めてラインに加わる（作動中となる）新しいノードと同じ情報を見出すことが必要となる。さらに、その故障したノードがそのドメインを制御するノードである場合には、区画内においてそのドメインの制御を代わりに行う新しいノードを指示する必要もある。多くの場合、各ノードからそのドメイン内の他の各ノードへメッセージを送り、いずれのノードが未だ使用可能であるかを判断して新しい制御ノードを割り当てることにより行われる。このような方式によると結果的に、ノードが新たに加わったり回復されたりする毎に大量のメッセージ・トラフィックが送られることとなる。
【０００４】
【発明が解決しようとする課題】
本発明の目的は、ノードが初めてラインに加わる際にドメイン内の全てのノードについてのネーム・サーバ・ノードを確定することである。
【０００５】
本発明の更なる目的は、ノードがフリッカーを生じているとき、そのノードが立ち上がろうとするのか若しくは停止しようとするのかを確認するプロトコルを提供することである。
【０００６】
本発明の更なる目的は、古いネーム・サーバ・ノードが故障しまたは停止してしまったとき、新しいネーム・サーバ・ノードを選択することができるような回復のプロトコルを提供することである。
【０００７】
【課題を解決するための手段】
本発明は、ドメインに参加しようとする新しいノードが、新しいノードの参加を制御するネーム・サーバ・ノードに対してメッセージを送るのみでよいようなＰＲＯＣＬＡＩＭプロトコルを提供する。
【０００８】
本発明は、既に参加しているノードと新しいノードとの間でのみ送られるメッセージによりその新しいノードがネーム・サーバとなることができるＰＲＯＣＬＡＩＭプロトコルを提供する。
【０００９】
本発明は、停止すると報告されたノードが実際に停止するのか否か、又は停止しそうに見えるだけなのか否かを確認するＦＬＩＣＫＥＲプロトコルを提供する。
【００１０】
本発明は、故障したノードの回復を実行するために、ネーム・サーバ・ノードへメッセージを送るのみでよいＲＥＣＯＶＥＲプロトコルを提供する。
【００１１】
本発明は、古いネーム・サーバが故障したときに新しいネーム・サーバを決定でき、その際、ＲＥＣＯＶＥＲプロトコルが新しいネーム・サーバとそのドメイン内の他のノードとの間でメッセージを送るのみでよいようなＲＥＣＯＶＥＲプロトコルを提供する。
【００１２】
本発明は、ＲＥＣＯＶＥＲプロトコルが完了する前に古いネーム・サーバが使用可能となった場合に、回復プロセスを終了させて古いネーム・サーバがその役割を復活できるようなＲＥＣＯＶＥＲプロトコルを提供する。
【００１３】
本発明における上記及び他の目的、特徴並びに利点は、図面に示された本発明の好適な実施例のより詳細な説明により明らかとされるであろう。
【００１４】
【発明の実施の形態】
図１は、本発明により使用可能な分散コンピュータ・システム１００の概略的構成図である。分散コンピュータ・システム１００としては、Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｂｕｓｉｎｅｓｓ  Ｍａｃｈｉｎｅｓ  Ｃｏｒｐｏｒａｔｉｏｎから市販されているＩＢＭ  ＲＩＳＣ  Ｓｙｓｔｅｍ／６０００  Ｓｃａｌａｂｌｅ  ＰＯＷＥＲｐａｒａｌｌｅｌ  Ｓｙｓｔｅｍ（ＳＰ）分散コンピュータ・システムがある。図１に開示された実施例は、全部で８フレームを有するＳＰコンピュータであり、各フレームが１６個までのノードを有し、全部で１２８のノードが可能である。全てのノード１０６は、ローカル・エリア・ネットワーク（ＬＡＮ）１０２により結合される。当業者には周知の通り、各ノード１０６はコンピュータそのものであり、ＲＩＳＣ  Ｓｙｓｔｅｍ／６０００ワークステーションとすることができる。
【００１５】
ＳＰコンピュータ１００のフレーム内の全てのノードはＬＡＮセグメントに含まれ、ＬＡＮセグメントは、ＬＡＮゲート１０４を介して他のＬＡＮセグメントと結合される。さらに、ＬＡＮ１０２には制御ワークステーション（ＣＷＳ）１１２が接続され、これは、ＳＰコンピュータのオペレーションを制御する。制御ワークステーションは、直接アクセス記憶装置（ＤＡＳＤ）１１４を有し、ここにシステム・データ・リポジトリー・ファイル（ＳＤＲ）が記憶される。ＳＤＲファイルは、システム内のノードのリスト及びそれらの設定等の情報を含む。各ノード１０６もまた、ＳＰコンピュータ１００により処理されたデータを記憶するＤＡＳＤ装置１０７を含む。
【００１６】
一実施例においては、各フレーム内のノードがさらに、ＩＢＭ  Ｓｃａｌａｂｌｅ  ＰＯＷＥＲｐａｒａｌｌｅｌ  ｓｗｉｔｃｈ（ＳＰＳ）１０５へ接続される。各フレームのＳＰＳスイッチ１０５の各々は、バス１１０により他のフレームの隣のＳＰＳスイッチ１０５へ接続される。
【００１７】
周知の通り、ＣＷＳノード１１２が、ＬＡＮ１０２を用いてノード１０６へメッセージ及びデータを送る一方、ノード１０６は、ＳＰスイッチ１０５を用いて互いにメッセージ及びデータを送ることができる。
【００１８】
ＳＰコンピュータ・システムの各ノード１０６及びＣＷＳ１１２は、米国特許出願第０８／６４０４１２号「Ａ  Ｍｅｔｈｏｄ  ｆｏｒ  Ｍａｎａｇｉｎｇ  Ｍｅｍｂｅｒｓｈｉｐ  ｏｆ  ａ  Ｇｒｏｕｐ  ｏｆ  Ｐｒｏｃｅｓｓｏｒｓ  ｉｎ  ａ  Ｄｉｓｔｒｉｂｕｔｅｄ  Ｃｏｍｐｕｔｉｎｇ  Ｅｎｖｉｒｏｎｍｅｎｔ」に記載されたグループ・サービス・デーモンを含む。各ノード１０６は、ソフトウェア若しくはハードウェア、又はこれらの組合せによるものを含んでおり、いずれのノードが立ち上がり使用可能となったかを他の全てのノードに対して報告する。いずれかのノード１０６が故障した場合、ハートビート機能として知られるプロセスによりその識別が他のノードへ知らされる。周知の通り、ＳＰコンピュータ・システム１００のノード１０６は、複数の区画へ分けることができる。
【００１９】
図２は、ノード１０６の区画２００を示す構成図である。区画２００は、さらに１又は複数のドメインへと小さく分けられる。例えば、図２の区画２００は、４個のドメイン２０１Ａ〜２０１Ｄへと分けられている。各ドメイン２０１は、ネーム・サーバ２０２を含む。例えば、図２の例では、ドメイン２０１Ａ〜２０１Ｄが各々ネーム・サーバ（ＮＳ）２０２Ａ〜２０２Ｄを有している。ドメイン２０１内のノードは、１又は複数のグループのメンバーとなることができ、各グループはグループ・リーダー（ＧＬ）により支援される。例えば、ドメイン２０１Ａ内のノードは、３つのグループのメンバーであり、各グループはグループ・リーダー２０４、２０５及び２０６により支援される。ドメイン２０１Ｂ内のノードは、２つのグループのメンバーであり、各グループはグループ・リーダー２０８及び２０９により支援される。同様に、ドメイン２０１Ｃ内のノードは、４つのグループのメンバーであり、各グループはグループ・リーダー２１０、２１１、２１２及び２１３により支援される。ドメイン２０１Ｄ内のノードは、１つのグループのメンバーであり、このグループはグループ・リーダー２１５により支援される。ネーム・サーバの主な機能は、そのドメイン内のグループに加わろうとする各ノードをそのグループのグループ・リーダー（ＧＬ）へ知らせ、そしてグループ・ネームがそのドメイン内で固有であるように保証することである。プロセッサのグループのメンバーを管理すること及びグループ・リーダーの機能は、前述の米国特許出願第０８／６４０４１２号に詳細に開示されている。あるグループに参加しようとしているノードをそのグループのグループ・リーダーに教えるために必要な情報は、そのドメイン内のグループのために各ネーム・サーバにより保持されるテーブルＴに記憶されている。テーブルＴ及びそのエントリについては、米国特許出願第０８／６８４２４６号「ＭＡＮＡＧＩＮＧ  ＧＲＯＵＰ  ＥＶＥＮＴＳ  ＢＹＡ  ＮＡＭＥ  ＳＥＲＶＥＲ  ＦＯＲ  Ａ  ＧＲＯＵＰ  ＯＦ  ＰＲＯＣＥＳＳＯＲＳ  ＩＮ  Ａ  ＤＩＳＴＲＩＢＵＴＥＤ  ＣＯＭＰＵＴＩＮＧ  ＥＮＶＩＲＯＮＭＥＮＴ」に開示されている。
【００２０】
本発明の目的の中に、ドメインへ新しいノードを追加し、ノードが故障したときドメインからそのノードを取り除き、そしてそのネーム・サーバ・ノードが故障したときドメインを回復させることがある。
本発明におけるネーム・サーバの機能は、次の通りである。
１．新しいノードがネーム・サーバ・ノードを識別できるように、全ての新しいノードに対して宣言する。
２．ノードが故障した場合、米国特許出願第０８／６４０４１２号に記載のグループからノードを取り除く方法と同様に、その故障したノードをドメインから削除する。
３．新しいノードから追従メッセージを収集した後、ドメインへ追従するノードを挿入する。
【００２１】
一実施例においては、ドメインが互いを見出すと、小さい方のドメインのネーム・サーバ（あるいは、大きさが同じ場合は、より大きい番号のネーム・サーバ）が自分のドメインを解散する。その結果、全てのノードが他のドメインに加わることとなる。
【００２２】
図３は、新ノードがドメインに追加される場合のＰＲＯＣＬＡＩＭプロトコルのプロトコル状態図である。各ノード１０６は、ただ１つのドメインに追加される。以下の説明においては、簡単とするためにただ１つのドメインについて説明する。新ノードが最初に使用可能となるとき、未確定状態３０１に入る。その後、新ノードはそのローカル・ハートビート機能を調べることにより、最小番号のノード（ＬＮＮ）であるか否かを判断する。本発明では、ドメイン内の最小番号ノードに対してネーム・サーバを割り当てるようにしている。
【００２３】
新ノードが最小番号のノードである場合、アセンド（ａｓｃｅｎｄ）状態３０２へ移行する。アセンド状態にあるノードが、より小さい番号をもつ新ノードが使用可能となったことを見出した場合、このノードは、自分が最小番号のノードではないことを認識し、矢印３０３に示すように未確定状態３０１へ戻る。アセンド状態にあるノードが、このドメインには既にネーム・サーバ・ノードが存在することを示すＰＲＯＣＬＡＩＭメッセージを受信した場合、このノードは挿入保留状態３０５へ移行する。この状態３０５については後述する。アセンド状態３０２にあるノードが使用可能な他の全てのノードから追従メッセージを受信した場合、後述するように、このノードはアセンディング（ａｓｃｅｎｄｉｎｇ）状態３０６に移行する。アセンディング状態３０６にあるとき、ノードは、そのノードに追従した他の全てのノードに対して第１段階（Ｐ１）挿入メッセージを送る。ドメインへの新ノードの挿入は、グループへのノードの挿入と同じであり、上記の米国特許出願第０８／６４０４１２号に開示されている。
【００２４】
他のノードの各々が第１段階挿入メッセージを受信すると、各ノードはそのアクションに同意することを示す肯定（ＡＣＫ）メッセージにより応答するか、又は、そのアクションに同意しないことを示す否定（ＮＡＣＫ）メッセージにより応答する。ノードがネーム・サーバであるときは、ＮＡＣＫメッセージを送ることができる。アセンディング状態３０６にあるノードが、自分が最小番号のノードでないことを認識した場合又はＮＡＣＫメッセージを受信した場合、他のノードに対して挿入プロセスを中止することを示す中止メッセージを同報通信し、そして矢印３０７を経て未確定状態３０１へ戻る。アセンディング状態３０６にあるノードが、ネーム・サーバ・ノードからＰＲＯＣＬＡＩＭメッセージを受信した場合、そのノードは中止メッセージを同報通信し、矢印３０９を経て挿入保留状態３０５へ移行する。
【００２５】
アセンディング状態３０６にあるノードが、他の全てのノードから肯定メッセージを受信した場合、自分が現在ネーム・サーバであることを示すコミット（ｃｏｍｍｉｔ）・メッセージを他の全てのノードに対して送信し、ネーム・サーバ成立状態３１０へ移行する。この時点で、ドメインが形成されたことになり、全てのドメイン・ノードが確定状態３１７又は状態３１０にある。そして、全てのノードが、いずれのノードがネーム・サーバであるかを認知している。
【００２６】
未確定状態３０１において、新ノードが、自分が最小番号ではないと判断した場合、矢印３１３を経て追従状態３１２へと移行する。追従状態３１２にあるノードは、最小番号ノードに対して周期的に追従メッセージを送信する。最小番号ノードに対するこの追従メッセージは、新ノードがそのドメインに参加しようとしていることを示しかつ新ノードがそのノードを最小番号ノードとして認識していることを示す。最小番号ノードが既にそのドメインのメンバーでありかつ別のノードをネーム・サーバとして認識している場合、最小番号ノードは、いずれがネーム・サーバであるかを示すマイリーダー（ＭＬＩ）・メッセージをその新ノードに対して送り返す。ＭＬＩメッセージによりネーム・サーバとして識別されたノードは、みなし（ｒｅｐｕｔｅｄ）ネーム・サーバ（ＲＮＳ）として認知される。
【００２７】
追従状態３１２にある新ノードは、他のノードがネーム・サーバとして設定されていることを示すＰＲＯＣＬＡＩＭメッセージを受信することができる。追従状態３１２にある新ノードが、適切なＰ１挿入メッセージを受信した場合、矢印３１７を経て挿入状態３１６へ移行する。挿入状態３１６にある新ノードは、Ｐ１挿入メッセージを送信しているノードに対してＰ１肯定メッセージを送信する。挿入状態３１６にあるノードが中止メッセージを受信した場合、新ノードは、矢印３１９を経て未確定状態３０１へ移行する。挿入状態３１６にある新ノードが、そのＰ１肯定メッセージに応答するコミット・メッセージを受信した場合、新ノードは確定状態３１７へ移行する。この時点で、新ノードはそのドメインへ受け入れられ、いずれがネーム・サーバ・ノードであるかを認知している。
【００２８】
挿入保留状態３０５にあるとき新ノードは、みなしネーム・サーバ（ＲＮＳ）・ノードに対して周期的に追従メッセージを送信する。ＲＮＳノードは、ＭＬＩメッセージ若しくはＰＲＯＣＬＡＩＭメッセージのいずれかをより早く受信することにより識別されたノードである。挿入保留状態３０５にあるノードがそのローカル・ハートビート機能を介してＲＮＳノードが故障したことを発見した場合、新ノードは矢印３２０を経て未確定状態３０１へ戻る。一方、挿入保留状態３０５にある新ノードが適切なＲＮＳノードからＰ１挿入メッセージを受信した場合、前述のように、挿入状態３１６へ移行してＰ１肯定メッセージを送信する。挿入状態３１６にあるノードが、そのローカル・ハートビート機能を介してＲＮＳノードが故障したことを発見した場合、後述するように、そのノードは矢印３３０を経て未確定状態５０２へ移行する。
【００２９】
新ノードが未確定状態３０１へ戻ったならば必然的に、その新ノードが状態３１０においてネーム・サーバとなるか又は確定状態３１７においてドメインへ受け入れられるかするまで、状態から状態へと移行するプロセス全体を再び開始することとなる。
【００３０】
アセンド状態３０２において、ハートビート機能が他の使用可能なノードを発見できるようにコロナ・タイマー３５０が含まれている。これにより可能な限り大きな単一ドメインが形成される。コロナ・タイマーは、アセンド状態３０２に入るときセットされる。全ての使用可能なノードから追従メッセージが受信されかつアセンド状態３０２においてコロナ・タイマーが時間切れとなった場合にのみ、発見された使用可能に立ち上がったノードが立ち上がり使用可能なノードとみなされ、そして前述のように、状態はアセンディング状態３０６へ続く。コロナ・タイマーは、全ての立ち上がりノードを配置するべく、ＳＰコンピュータ・システム１００内の全てのネットワークを探索するために十分な時間をハートビート機能に対して与える。コロナ・タイマーが長すぎる場合、サービス・プロバイダ使用グループは、それらのサービスをドメインに提供することが不必要に遅延させられる。従って、双方の関係を満足するために、合理的な中間値が選ばれる。実施例においては、コロナ・タイマーは２０秒にセットされる。
【００３１】
図４は、ＦＬＩＣＫＥＲプロトコルのプロトコル状態図を示しており、そこでは、使用可能性がフリッカ方式に起動、停止、再び起動するように、ノードが故障（停止）し、そして使用可能（起動）となるように見える。故障のように見える場合、実際に故障していることもあるし、あるいは、ノードが故障したかのように見える区画化若しくは一時的ネットワーク状態等の結果であるかもしれない。前述のように、ハートビート機能は、ドメイン内の全てのノードの状態を継続的にモニタしている。ノードの通常状態すなわち起動状態は、図４のブロック４０１に示されている。ノードが停止したことをハードビート機能が報告したとき、ノードの状態が矢印４０９を経てブロック４０２の推定停止状態へ移行する。続いて、ノードが復帰したことをハートビート機能が報告したとき、グループ・サービスは、ノードが実際に再び使用可能となったことを確認しようとする。こうして、矢印４０７を経てノードの状態は、非停止状態４０３へ移行する。これは過渡的状態である。非停止状態４０３にあるとき、その故障したノードに対してメッセージが送られ、そしてそのノードが実際に起動しているのか停止しているのかを調べるために応答を待つ。このプロセスは、ＰＩＮＧプロトコルとして知られている。ＰＩＮＧメッセージに対する応答としてそのノードから適宜の肯定応答が受信された場合には、そのノードが起動状態にあると確認される結果、矢印４０４を経て起動状態４０１へと戻る。各ノード間のＰＩＮＧメッセージについては周知の技術であり、ここでは詳細に説明しない。ＰＩＮＧメッセージに対する応答として故障したノードから否定応答が受信された場合には、そのノードが停止したと確認され、そのノードは矢印４０６を経て確認停止状態４０５へ移行する。応答が受信されない場合は、ノードは非停止状態４０３のまま維持され、そして応答が受信されるまでＰＩＮＧメッセージが周期的に送信される。非停止状態４０３にあるノードが故障したことをハートビート機能が報告した場合、このノードは、矢印４０８を経て推定停止状態４０２へと戻される。
【００３２】
図５は、ネーム・サーバ・ノードが故障した様子がある場合におけるＲＥＣＯＶＥＲプロトコルについてのプロトコル状態図である。ネーム・サーバ・ノードが故障したとき、回復プロセスを介して新しいネーム・サーバ・ノードが選択される必要があることは自明であろう。回復プロセスは、ドメイン内のノードを適切に操作するためにドメイン内で生き残っているノードへネーム・サーバの役割を渡すことができる。ノードが故障したとき、この事実は、前述のようにハートビート機能を介して全てのノードへ報告される。各ノードにおけるグループ・サービス・デーモンが、ネーム・サーバが故障したことを判断したとき、各ノードにおけるグループ・サービス・デーモンの各々が、図５の回復プロトコルを通して進行する。このプロトコルの最初において、ノードは、図３における確定状態３１７と同じ確定状態５０１にある。ネーム・サーバが故障したとき、ノードの状態は確定状態５０１から矢印５３３を経て未確定状態５０２へ移行する。未確定状態５０２においてグループ・サービス・デーモンは、メンバシップ・リストを調べることにより、いずれのノードが次のネーム・サーバとしてリスト上に載っているかを判断する。これについては、前述の米国特許出願第０８／６４０４１２号に記載されている。この次のネーム・サーバは、クラウン・プリンス（ｃｒｏｗｎ  ｐｒｉｎｃｅ）すなわちＣＰとして識別される。ノードがクラウン・プリンスである場合、そのノードが矢印５３４を経てアセンド状態５０３へ移行する。そのノードが現在起動していると認識する他のノードから全ての回復メッセージを受信したならば、そのノードはアセンディング状態５０４へ移行する。コロナ・タイマー５５０もまたアセンド状態５０３にあり、これは前述のコロナ・タイマー３５０と同じである。回復メッセージについては、追従状態５１０に関連して詳細に後述する。アセンディング状態５０４にあるＣＰノードは、第１段階引継メッセージをそのドメインの他の全てのノードへ送信する。メンバシップ・リスト中のさらに古いＣＰノードが起動したためにそのノードがＣＰノードではないことがそのローカル・ハートビート機能を介して判明したり、あるいは、第１段階引継（ＴＯＰ１）否定メッセージを受信したりした場合には、そのノードは他の全てのノードに対して中止メッセージを同報通信し、そして矢印５０５を介して未確定状態５０２へ戻る。他の全てのノードから第１段階引継肯定メッセージを受信したならば、ＣＰノードは、第２段階引継（ＴＯＰ２）メッセージを他のノードへ同報通信し、矢印５０７を介してネーム・サーバ成立状態５０６へ移行する。ＴＯＰ２メッセージに応答して、他のノードは、新しいネーム・サーバ用のテーブルＴを再構築するために必要なデータを送信する。これにより新しいネーム・サーバはネーム・サーバの役割を引き継ぐことができる。あるノードがそのテーブルＴデータを送信する前に故障した場合、そのノードはネーム・サーバにより通常通りにドメインから除かれ、そしてそのノードの欠如は何の影響も及ぼさない。新たなネーム・サーバがテーブルＴについての全データを取得した後、自らが新しいネーム・サーバであることを示すためにコミット引���メッセージを他の全てのノードに対して通信し、そして矢印５４５を経て完了状態５４０へ移行する。完了状態５４０においては、ネーム・サーバはいつでも前述の米国特許出願第０８／６８４２４６号に開示されたルックアップを処理することができる。
【００３３】
未確定状態５０２にあるノードが、自身がＣＰノードではないと判断した場合、矢印５１１を経て追従状態５１０へ移行する。追従状態にあるノードは、前述のように、メンバシップ・リストで識別されたＣＰノードに対して周期的に回復メッセージを送信する。この時点で、ドメイン内の他の全てのノードが同じ回復プロトコルを行っており、かつそれらのノードもＣＰノードに対して周期的な回復メッセージを送っていることは自明であろう。こうすることにより、前述の通り、ＣＰノードがアセンド状態５０３に達したとき、他の全てのノードから全ての回復メッセージを集めることができ、アセンディング状態５０４に移行することができる。追従状態５１０にあるノードが、アセンディング状態５０４にあるＣＰノードから第１段階引継（ＴＯＰ１）メッセージを取得すると、存在しているノードは矢印５１３を経て引き継ぎ状態５１２へ移行し、ＴＯＰ１メッセージに応答して肯定メッセージを送信する。これにより、アセンディング状態５０４にあるＣＰノードは、そのドメイン内の全てのノードから肯定メッセージを受信した後、ネーム・サーバ成立状態５０６へ移行する。
【００３４】
追従状態５１０にあるノードが、自身がＣＰノードであると判断した場合、矢印５１５を経てアセンド状態５０３へと移行する。また、アセンド状態５０３にあるノードが、メンバシップ・リスト中のより上位のＣＰノードが起動したために自身がＣＰノードでないと判断した場合も、アセンド状態５０３から矢印５１６を経て追従状態５１０へと移行する。追従状態５１０にあるノードが、ＣＰノードが故障したと判断した場合、このノードは矢印５１７を経て未確定状態５０２へと戻る。引継状態５１２にあるノードが、ＣＰノードが故障したか若しくはＴＯＰ１中止メッセージを取得したと判断した場合、そのノードは、引継状態５１２から矢印５２０を経て未確定状態５０２へと戻る。引継状態にあるノードが第２段階引継（ＴＯＰ２）メッセージを受信した場合、そのノードは、新しいネーム・サーバに対してＴテーブルを再構築するために必要なデータを送信し、矢印５２１を経て確定状態５０１へと移行する。こうしてノードが確定状態５０１へ移行すると、そのノードは、自身がネーム・サーバでないことを再び認知するが、いずれがネーム・サーバであるかすなわち成立状態５０６となったノードを認知している。
【００３５】
ノードが追従状態５１０にあり、かつ、故障の回復プロセスを開始しているネーム・サーバが図４に関して述べた確認状態へ戻るとき、「王の帰還」として知られる条件が検知されている。この場合、そのノードは追従状態５１０から矢印５２２を経て確定状態５０１へ移行し、回復が停止し、そして古いネーム・サーバがネーム・サーバ・ノードに留まる。
【００３６】
ＰＲＯＣＬＡＩＭプロトコル又はＲＥＣＯＶＥＲプロトコルの間にいずれかのルックアップ・メッセージが発生された場合、そのノードがＰＲＯＣＬＡＩＭ確定状態３１７若しくはＲＥＣＯＶＥＲ確定状態５０１のいずれかになるまでは、ルックアップ・メッセージがローカルにキューされる。ＰＲＯＣＬＡＩＭプロトコルにおいては、ルックアップ・キュー内にローカルに記憶されたメッセージは、そのノードが確定状態３１７に入ったときそのメッセージをネーム・サーバへ送ることにより、３６０で処理される。ＲＥＣＯＶＥＲプロトコルにおいては、ノードが確定状態５０１にありかつ新しいネーム・サーバからコミット引継（ＴＯＣ）メッセージを受信したとき、５７０に示すように、そのノードは、ネーム・サーバに対してメッセージを送ることによりルックアップ・キュー内にローカルに記憶されたメッセージを処理する。そして、矢印５７５を経て確定状態５０１に戻るすなわち留まる。
【００３７】
図３のＰＲＯＣＬＡＩＭプロトコルの挿入状態３１６へ戻って、ＲＮＳノードが故障したとノードが判断した場合、そのノードは、いずれが新しいネーム・サーバであるかを判断するために探さなければならないが、そのドメイン内にいずれかのノードが残っているか否かについては定かでない。従ってそのノードは、未確認フラグをセットして、矢印３３０を経て図５のＲＥＣＯＶＥＲプロトコルの未確定状態５０２へと移行する。
【００３８】
図５に戻って、アセンド状態５０３にあるノードが、未確認フラグがセットされておりそして他の全てのノードが故障したと判断した場合、そのノードは、矢印５６０を経て図３のＰＲＯＣＬＡＩＭプロトコルの未確定状態３０１へ移行する。同様に、追従状態５１０にあるノードが、未確認フラグがセットされておりかつそのドメイン内の他の全てのノード故障したと判断した場合、そのノードは、矢印５６５を経て図３のＰＲＯＣＬＡＩＭプロトコルの未確定状態３０１へ移行する。これらの最後の２つの条件は、ネーム・サーバが故障しかつそのドメイン内に他のノードがないときに生じる可能性がある。その場合、そのノードは、ドメインを設立するためにＰＲＯＣＬＡＩＭプロトコルへ進まなければならない。
【００３９】
ＲＥＣＯＶＥＲプロトコルの確定状態５０１又はＰＲＯＣＬＡＩＭプロトコルの未確定状態３０１に達したとき、未確認フラグはクリアされる。
【００４０】
このようにして本発明は、ドメイン内の全てのノードが最初にライン上に出現するときにこれらのノードのためにネーム・サーバ・ノードを設定する。さらに、ノードにフリッカが生じたとき、そのノードが起動するのか停止するのかを確認するプロトコルを提供する。またさらに、元のネーム・サーバ・ノードが故障するか停止したとき新しいネーム・サーバを選択することができるプロトコルを提供する。
以上、本発明の好適例について説明したが、開示された構成に限定する意図でないことは自明であろう。全ての変形及び修正は本発明の範囲内に含まれる。
【図面の簡単な説明】
【図１】本発明の分散コンピュータ・システムの概略構成図である。
【図２】図１の分散コンピュータ・システムにおけるプロセッサ・ドメインの構成図である。
【図３】プロセッサが図２のドメインを結合させるためのＰＲＯＣＬＡＩＭプロトコルのプロトコル状態図である。
【図４】図２のドメイン内においてフリッカーを生じているノードについてのノード状態を取得するためのＦＬＩＣＫＥＲプロトコルのプロトコル状態図である。
【図５】図２のドメイン内において故障した後に回復されようとしているノードについてのＲＥＣＯＶＥＲプロトコルのプロトコル状態図である。
【符合の説明】
１００  分散コンピュータ・システム
１０２  ローカル・エリア・ネットワーク（ＬＡＮ）
１０４  ＬＡＮゲート
１０５  ＳＰスイッチ
１０６  ノード
１１２  制御ワークステーション
１１４  直接アクセス記憶装置
２００  区画
２０１  ドメイン
２０２  ネーム・サーバ
２０４、２０５、２０６  グループ・リーダー
【図１】
0003554472.tif 000002
【図２】
0003554472.tif 000003
【図３】
0003554472.tif 000004
【図４】
0003554472.tif 000005
【図５】
0003554472.tif 000006