(57)【特許請求の範囲】
【請求項１】
分散コンピュータ環境における機能を利用するために該機能ごとに設立されるプロセッサ・グループについてネーム・サーバがグループ・イベントを管理する方法であって、
（ａ）イベントを要求している１つのプロセッサからのメッセージを前記ネーム・サーバが受信するステップと、
（ｂ）前記メッセージによりいずれのイベントが要求されているかを判断するステップと、
（ｃ）前記イベントがいずれのグループを目的とするものであるかを判断するステップと、
（ｄ）前記目的とするグループがすでに存在するか否かを判断し、存在しない場合は、当該グループを設立するステップと、
（ｅ）前記イベントが前記目的とするグループに参加することを要求するためのルックアップ・イベントである場合、当該グループに参加することを要求しているプロセッサの識別情報を、当該グループ内の関係する全てのプロセッサをリストするための関係パーティ・セット内に記憶するステップと、
（ｆ）前記目的とするグループがグループ・リーダーを有するか否かを判断するステップと、
（ｇ）前記目的とするグループがグループ・リーダーを有していない場合、グループ・リーダーが設定されたときに処理するため、ルックアップ・キュー内にそのメッセージに応答して実行されるべきルックアップ・イベントを記憶するステップと、
（ｈ）前記目的とするグループを要求した最初のプロセッサを前記グループ・リーダーとして設定するステップと、
（ｉ）前記目的とするグループについて前記グループ・リーダーが設定された後、前記ルックアップ・キュー内に記憶された全てのルックアップ・イベントを処理するステップとを含む
分散コンピュータ環境におけるグループ・イベント管理方法。
【請求項２】
各エントリが１つのプロセッサ・グループを表している複数のエントリを有するテーブルが前記ネーム・サーバ内に設けられ、
各プロセッサ・グループについての前記テーブル内のエントリの索引番号により当該各プロセッサ・グループを識別するステップを含む
請求項１に記載の方法。
【請求項３】
前記テーブルの各エントリに実体番号が保持され、
前記各エントリのプロセッサ・グループが解消される毎に、当該各エントリを新しいプロセッサ・グループのために再使用可能とするべく前記実体番号を増分するステップを含む
請求項２に記載の方法。
【請求項４】
前記テーブルの各エントリに連続番号が保持され、
前記テーブル内のグループ・エントリを識別しかつ前記テーブル内の識別されたグループについてその更新イベントを要求する更新メッセージを前記ネーム・サーバに送信するとき、当該更新メッセージに新しい連続番号を含めるステップと、
前記更新メッセージに含まれる新しい連続番号と、前記テーブル・エントリ内の連続番号とを比較し、当該更新メッセージにより識別グループについての前記テーブル・エントリ内の連続番号より前記新しい連続番号が大きい更新イベントのみを実行するステップとを含む
請求項３に記載の方法。
【請求項５】
前記イベントが前記目的とするグループからプロセッサを削除するための削除イベントである場合、当該グループから削除することを要求しているプロセッサの識別情報を、前記関係パーティ・セットから削除するステップと、
グループが設立されていない第１の状態と、グループが設立されているがグループ・リーダーのいない第２の状態と、グループが設立されかつグループ・リーダーのいる第３の状態とからなるグループの状態のうち、前記関係パーティ・セット内のエントリから前記グループの状態を判断するステップとを含む
請求項４に記載の方法。
【請求項６】
分散コンピュータ環境における機能を利用するために該機能ごとに設立されるプロセッサ・グループについてネーム・サーバがグループ・イベントを管理する装置であって、
（ａ）イベントを要求している１つのプロセッサからのメッセージを前記ネーム・サーバが受信する手段と、
（ｂ）前記メッセージによりいずれのイベントが要求されているかを判断する第１の判断手段と、
（ｃ）前記イベントがいずれのグループを目的とするものであるかを判断する第２の判断手段と、
（ｄ）前記目的とするグループがすでに存在するか否かを判断し、存在しない場合は、当該グループを設立する手段と、
（ｅ）前記イベントが前記目的とするグループに参加することを要求するためのルックアップ・イベントである場合、当該グループに参加することを要求しているプロセッサの識別情報を、当該グループ内の関係する全てのプロセッサをリストするための関係パーティ・セット内に記憶する手段と、
（ｆ）前記目的とするグループがグループ・リーダーを有するか否かを判断する第３の判断手段と、
（ｇ）前記目的とするグループがグループ・リーダーを有していない場合、グループ・リーダーが設定されたときに処理するため、ルックアップ・キュー内にそのメッセージに応答して実行されるべきルックアップ・イベントを記憶する手段と、
（ｈ）前記目的とするグループを要求した最初のプロセッサを前記グループ・リーダーとして設定する手段と、
（ｉ）前記目的とするグループについて前記グループ・リーダーが設定された後、前記ルックアップ・キュー内に記憶された全てのルックアップ・イベントを処理する手段とを有する
分散コンピュータ環境におけるグループ・イベント管理装置。
【請求項７】
前記ネーム・サーバ内に設けられ、各エントリが１つのプロセッサ・グループを表している複数のエントリを有するテーブルを有し、
各プロセッサ・グループについての前記テーブル内のエントリの索引番号により当該各プロセッサ・グループが識別される
請求項６に記載の装置。
【請求項８】
前記テーブルの各エントリにおける実体番号と、
前記各エントリのプロセッサ・グループが解消される毎に、当該各エントリを新しいプロセッサ・グループのために再使用可能とするべく前記実体番号を増分する手段とを有する
請求項７に記載の装置。
【請求項９】
前記テーブルの各エントリに連続番号と、
前記テーブル内のグループ・エントリを識別しかつ前記テーブル内の識別されたグループについてその更新イベントを要求する前記ネーム・サーバに対して送信される更新メッセージに含まれる新しい連続番号と、
前記更新メッセージに含まれる新しい連続番号と、前記テーブル・エントリ内の連続番号とを比較し、当該更新メッセージにより識別グループについての前記テーブル・エントリ内の連続番号より前記新しい連続番号が大きい更新イベントのみを実行する手段とを含む
請求項８に記載の装置。
【請求項１０】
前記イベントが前記目的とするグループからプロセッサを削除するための削除イベントである場合、当該グループから削除することを要求しているプロセッサの識別情報を、前記関係パーティ・セットから削除する手段と、
グループが設立されていない第１の状態と、グループが設立されているがグループ・リーダーのいない第２の状態と、グループが設立されかつグループ・リーダーのいる第３の状態とからなるグループの状態のうち、前記関係パーティ・セット内のエントリから前記グループの状態を判断する第４の判断手段とを含む
請求項９に記載の装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、分散コンピュータ環境に関し、特に、分散コンピュータ環境における１又は複数のプロセッサ（以下「ノード」とも称する）のグループについてネーム・サーバによりグループ・イベントを管理することに関する。
【０００２】
【従来の技術】
分散コンピュータ環境におけるコンピュータは、並行にデータを処理する複数のコンピュータ・ノードを含む。このようなシステムの多くは、これらのノードを複数の区画へと組織化することができ、各区画が１又は複数のドメインを有する。各ドメインにおけるノードは、グループとして組織化される。１つのノードは、ただ１つのドメインに含まれてもよいが、複数のグループに含まれてもよい。そして、必要に応じてノードをグループに追加したりグループから取り除いたりできる。
【０００３】
分散コンピュータ環境におけるプロセッサは並行に実行するので、複数のノードについて同時に同じグループに追加したり、削除したり、データを調べたりすることが可能である。グループが前の要求のために未だビジー状態であるときに、ノードからそのグループへ到着した要求を保持できることが重要である。しかも、後の要求が失われたりせず、あるいは、再度その要求を送るよう要求したりしないことが重要である。
【０００４】
【発明が解決しようとする課題】
従って本発明の主な目的は、グループについてのメッセージを送信するノードの識別情報を記憶するために、各プロセッサ・グループの関係パーティ・セットを設けることである。
【０００５】
本発明の更なる目的は、関係パーティ・セットに記憶されたノード識別情報の数及びグループ・リーダーの状態を決定することにより、そのグループの状態を決定することである。
【０００６】
本発明の更なる目的は、グループ・リーダーが設定されていないグループに届くメッセージを記憶するルックアップ・キューを設けること、及び、グループ・リーダーが設定されたときそのルックアップ・キュー内のメッセージを処理することである。
【０００７】
本発明の更なる目的は、テーブル内のエントリの索引番号によりプロセッサ・グループが識別されるように、各エントリが１つのプロセッサ・グループに対応する複数のエントリを有するテーブルを設けることである。
【０００８】
本発明の更なる目的は、テーブルの各エントリに対応するグループが解消される毎にそのエントリ内の実体番号が増分されることにより、そのエントリが新しいグループのために再使用できるように、各エントリ内に実体番号を設けることである。
【０００９】
本発明の更なる目的は、ドメイン内のグループに対して、そのグループ索引と実体番号との組合せである固有のトークンを設けることである。
【００１０】
【課題を解決するための手段】
本発明においては、分散コンピュータ環境におけるプロセッサ・グループについてのグループ・イベントが、ネーム・サーバにより管理される。ネーム・サーバは、イベントを要求するノードの１つからメッセージを受信する。ネーム・サーバは、そのメッセージによりいずれのイベントが要求されているのかを判断し、そのイベントがいずれのグループについてのものかを判断し、そしてそのグループについての関係パーティ・セット内に、その要求しているノードの識別情報を記憶する。ネーム・サーバは、そのグループがグループ・リーダーを有するか否かを判断し、そしてグループ・リーダーがいない場合は、グループ・リーダーが設定されたときに処理されるルックアップ・キュー内のメッセージに応じてそのイベントが実行されるように記憶しておく。グループについてのイベントを要求する最初のノードは、ネーム・サーバによりグループ・リーダーとして設定される。グループの状態は、全くグループが成立していない状態を第１の状態とし、グループは成立しているがグループ・リーダーがいない状態を第２の状態とし、グループが成立しかつグループ・リーダーがいる状態を第３の状態とすることができる。グループの状態は、関係パーティ・セット内のノード識別情報の数及びグループ・リーダーの状態により決定することができる。
【００１１】
本発明の上記及び他の目的、特徴及び利点は、図面と共に説明される以下の好適例についての記述により明らかとされる。
【００１２】
【発明の実施の形態】
図１は、本発明により使用可能な分散コンピュータ・システム１００の概略的構成図である。分散コンピュータ・システム１００としては、Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｂｕｓｉｎｅｓｓ  Ｍａｃｈｉｎｅｓ  Ｃｏｒｐｏｒａｔｉｏｎから市販されているＩＢＭ  ＲＩＳＣ  Ｓｙｓｔｅｍ／６０００  Ｓｃａｌａｂｌｅ  ＰＯＷＥＲｐａｒａｌｌｅｌ  Ｓｙｓｔｅｍ（ＳＰ）分散コンピュータ・システムがある。図１に開示された実施例は、全部で８フレームを有するＳＰコンピュータであり、各フレームが１６個までのノードを有し、全部で１２８のノードが可能である。全てのノード１０６は、ローカル・エリア・ネットワーク（ＬＡＮ）１０２により結合される。当業者には周知の通り、各ノード１０６はコンピュータそのものであり、ＲＩＳＣ  Ｓｙｓｔｅｍ／６０００ワークステーションとすることができる。
【００１３】
ＳＰコンピュータ１００のフレーム内の全てのノードはＬＡＮセグメントに含まれ、ＬＡＮセグメントは、ＬＡＮゲート１０４を介して他のＬＡＮセグメントと結合される。さらに、ＬＡＮ１０２には制御ワークステーション（ＣＷＳ）１１２が接続され、これは、ＳＰコンピュータのオペレーションを制御する。制御ワークステーションは、直接アクセス記憶装置（ＤＡＳＤ）１１４を有し、ここにシステム・データ・リポジトリー・ファイル（ＳＤＲ）が記憶される。ＳＤＲファイルは、システム内のノードのリスト及びそれらの設定等の情報を含む。各ノード１０６もまた、ＳＰコンピュータ１００により処理されたデータを記憶するＤＡＳＤ装置１０７を含む。
【００１４】
一実施例においては、各フレーム内のノードがさらに、ＩＢＭ  Ｓｃａｌａｂｌｅ  ＰＯＷＥＲｐａｒａｌｌｅｌ  ｓｗｉｔｃｈ（ＳＰＳ）１０５へ接続される。各フレームのＳＰＳスイッチ１０５の各々は、バス１１０により他のフレームの隣のＳＰＳスイッチ１０５へ接続される。
【００１５】
周知の通り、ＣＷＳノード１１２が、ＬＡＮ１０２を用いてノード１０６へメッセージ及びデータを送る一方、ノード１０６は、ＳＰスイッチ１０５を用いて互いにメッセージ及びデータを送ることができる。
【００１６】
ＳＰコンピュータ・システムの各ノード１０６及びＣＷＳ１１２は、米国特許出願第０８／６４０４１２号「Ａ  Ｍｅｔｈｏｄ  ｆｏｒ  Ｍａｎａｇｉｎｇ  Ｍｅｍｂｅｒｓｈｉｐ  ｏｆ  ａ  Ｇｒｏｕｐ  ｏｆ  Ｐｒｏｃｅｓｓｏｒｓ  ｉｎ  ａ  Ｄｉｓｔｒｉｂｕｔｅｄ  Ｃｏｍｐｕｔｉｎｇ  Ｅｎｖｉｒｏｎｍｅｎｔ」に記載されたグループ・サービス・デーモンを含む。各ノード１０６は、ソフトウェア若しくはハードウェア、又はこれらの組合せによるものを含んでおり、いずれのノードが立ち上がり使用可能となったかを他の全てのノードに対して報告する。いずれかのノード１０６が故障した場合、ハートビート機能として知られるプロセスによりその識別が他のノードへ知らされる。周知の通り、ＳＰコンピュータ・システム１００のノード１０６は、複数の区画へ分けることができる。
【００１７】
図２は、ノード１０６の区画２００を示す構成図である。区画２００は、さらに１又は複数のドメインへと小さく分けられる。例えば、図２の区画２００は、４個のドメイン２０１Ａ〜２０１Ｄへと分けられている。各ドメイン２０１は、ネーム・サーバ（ＮＳ）２０２を含む。例えば、図２の例では、ドメイン２０１Ａ〜２０１Ｄが各々ネーム・サーバ２０２Ａ〜２０２Ｄを有している。ドメイン２０１内のノードは、１又は複数のグループのメンバーとなることができ、各グループはグループ・リーダー（ＧＬ）により支援される。例えば、ドメイン２０１Ａ内のノードは、３つのグループのメンバーであり、各グループはグループ・リーダー２０４、２０５及び２０６により支援される。ドメイン２０１Ｂ内のノードは、２つのグループのメンバーであり、各グループはグループ・リーダー２０８及び２０９により支援される。同様に、ドメイン２０１Ｃ内のノードは、４つのグループのメンバーであり、各グループはグループ・リーダー２１０、２１１、２１２及び２１３により支援される。ドメイン２０１Ｄ内のノードは、１つのグループのメンバーであり、このグループはグループ・リーダー２１５により支援される。ネーム・サーバの主な機能は、そのドメイン内のグループに加わろうとする各ノードをそのグループのグループ・リーダー（ＧＬ）へ知らせ、そしてグループ・ネームがそのドメイン内で固有であるように保証することである。プロセッサのグループのメンバーを管理すること及びグループ・リーダーの機能は、前述の米国特許出願第０８／６４０４１２号に詳細に開示されている。あるグループに参加しようとしているノードをそのグループのグループ・リーダーに教えるために必要な情報は、そのドメイン内のグループのために各ネーム・サーバにより保持されるテーブルＴに記憶されている。
【００１８】
図３は、ドメイン内のプロセッサ・グループのイベントを管理するためにネーム・サーバにより用いられるテーブル３００の構成図である。テーブル３００は、図２の各ネーム・サーバの各々についてのテーブルＴと同じものである。テーブル３００は複数のエントリを含み、各エントリはプロセッサ・グループを表す。テーブルＴは、グループを識別するために用いられる固有のネームであるグループ・ネームについての列３０１、そのグループのグループ・リーダー（ＧＬ）の識別情報についての列３０２、及びそのグループについての実体番号についての列３０３を含む。後述のように、グループの全てのメンバーが故障するか又はグループから除かれた場合、そのエントリは、別のグループが成立するときに再使用することができる。この再使用は、実体番号３０３を増分するすなわち上げることにより行われる。古いグループについてのイベントが発生された場合、そのイベントは古い実体番号を含んでいるのでネーム・サーバにより無視され、そのイベントが目的とするグループはもはや存在しないことから、新しいグループについてのそのテーブル・エントリは変更されることはない。
【００１９】
テーブル３００はさらに、関係パーティ・セット（ＩＰＳ）についての列３０５を含む。これは、そのグループ内の関係する全てのノードの識別情報をリストするために用いられる。これは、そのグループのメンバーである全てのノードを示すことと似ている。さらに、連続番号の列３０７も含まれ、ここに有効な更新メッセージの連続番号を格納することにより、ネーム・サーバはその受信するメッセージが現在のものか否かを判断できる。最後に、テーブル３００はルックアップ・キューの列３１０を含む。この中には、そのグループについて受信された全てのルックアップ・イベントの識別情報が記憶されるが、それらは現時点では処理されない。
【００２０】
テーブル３００内のエントリの索引番号は、イベントが目的とするグループを識別するためのトークンの一部として用いることができることは明らかであろう。
【００２１】
テーブル３００の利用について説明する。例えば、ノードＸが、ＩＢＭ  の製品である仮想共有ディスク（Ｖｉｒｔｕａｌ  Ｓｈａｒｅｄ  Ｄｉｓｋ：ＶＳＤ）等の機能を利用するためにグループを形成したい場合、ＶＳＤを使用したいとするノードは、自分がＶＳＤグループに参加することを要求するメッセージをネーム・サーバに対して送信する。これは、そのグループについての最初の要求であるから、ネーム・サーバは新しいグループを設立し、そのグループを「ＶＳＤ」と命名することができる。このネームは、第１のエントリ３１１のグループ・ネーム・フィールド３０１に入れられる（符合３１２）。ＶＳＤグループについてのトークンは「１」を含み、これはＶＳＤグループがテーブル３００の第１のエントリに見出されることを示す。
【００２２】
この時点ではグループ・リーダーがいないので、ＧＬフィールドは空エントリのままとなる。しかしながら、テーブル３００にエントリを設定することは、ＶＳＤグループを設立することである。実体番号３１３は「０」にセットされ、これが第１のエントリを使用する最初のグループであることを示す。実体番号３１３は、ＶＳＤグループを識別するトークンの一部ともなる。連続番号３１６が「０」にセットされることにより、そのグループへ送られるいずれのメッセージについても正しい連続番号が識別され、その結果、古いメッセージが処理されないことを確保する。この時点で、ネーム・サーバは、ノードＸに対してルックアップ応答メッセージを送ることにより、ノードＸがグループ・リーダーであることを伝える。なぜなら、ノードＸは、そのグループを要求した最初のノードだからである。しかしながらノードＸは、自分がグループ・リーダーであることを示す更新メッセージを有効連続番号と共にネーム・サーバに対して送るまでは、テーブル３００にＶＳＤ  ＧＬとして導入されない。一方、ネーム・サーバにより受信されるＶＳＤグループについてのルックアップ・メッセージは、グループ・リーダーが割り当てられるまでは全てルックアップ・キュー・フィールド３１８に記憶される。従って、ＧＬフィールド３２０にノード識別情報が入る以前に受信されたＶＳＤグループについてのルックアップ・イベントは、いずれも、後に処理するためにルックアップ・キュー３１８に記憶されることとなる。
【００２３】
ノードＸがＶＳＤグループのグループ・リーダーであることを示す更新メッセージがノードＸから受信されると、ＧＬフィールド３２０へ「Ｘ」が追加される。ルックアップ・キュー３１８に記憶されたいずれのルックアップ・メッセージも、この時点で処理されることとなる。
【００２４】
図４は、ネーム・サーバにより受信され得るイベント、グループがなり得る状態、及び、グループを適切に管理するためにネーム・サーバが採るべき適切な対応動作を示す状態表である。各グループは、グループが設立されていない「状態０」（ＳＴ０）、グループが設立されかつグループ・リーダーがいない「状態１」（ＳＴ１）、グループが設立されかつグループ・リーダーが割り当てられた「状態２」（ＳＴ２）を有する。
【００２５】
図４の表のイベント列に示すように、各イベントは、所与の要求を行うメッセージをネーム・サーバが受信することにより開始される。
【００２６】
イベント４０１は、グループ（ＶＳＤ等）についてのノードからのルックアップであるが、この場合、そのノードはＩＰＳ内にない。イベント４０１におけるグループが状態０にある場合、そのグループが設立されかつその要求ノードへルックアップ応答メッセージが送られ、そしてそのグループについての状態は状態１へと移行する。イベント４０１におけるグループが状態１にある場合、その要求はルックアップ・キューへ入れられる。グループが状態０若しくは状態２へ移行すると、ルックアップ・キュー内のメッセージが処理され、その結果が送られる。イベント４０１におけるグループが状態２にある場合、ルックアップ応答メッセージがその要求ノードへ送られることにより、その要求ノードは、どのノードがグループ・リーダーであるかを伝えられる。全てのグループ状態において、その要求ノードの識別情報は、関係パーティとしてＩＰＳに記憶される。
【００２７】
イベント４０２は、グループについてのルックアップであるが、この場合、そのノードはＩＰＳ内にある。イベントについて状態０にあるエントリはない。なぜならこれは、生じるはずのない状態だからである。イベント４０２におけるグループが状態１にある場合、その要求ノードはＩＰＳから除かれる。その要求はルックアップ・キューに記憶される。状態が、状態０又は状態２に移行すると、ルックアップ・キュー内のメッセージが処理され、その結果が送られる。イベント４０２におけるグループが状態２にある場合、その要求ノードは、どのノードがグループ・リーダーであるかを伝えられる。
【００２８】
イベント４０４は削除であり、そのノードがＩＰＳ内にある。イベント４０４におけるグループが状態１にある場合、要求ノードはＩＰＳから除かれる。そしてこれがＩＰＳ内の最後のエントリであれば、そのグループは状態０へ移行すると共にこのグループにはもはやグループ・リーダーがいなくなる。こうしてそのグループは解消されるので、前述のようにそのエントリが再使用可能となる。イベント４０４におけるグループが状態２にある場合、要求ノードはＩＰＳから除かれる。そしてこれが最後のエントリであれば、そのグループは状態０へ移行する。あるいは要求ノードがグループ・リーダーであれば、そのグループは状態１へ移行する。
【００２９】
イベント４０５はグループからノードを削除するものであり、かつそのノードはＩＰＳ内にない。このイベントにおいては、グループが状態０、状態１又は状態２のいずれかにある場合、エラーが発生される。このイベントは、ノードがメッセージを送信してから故障したときに発生されることがあり、ネーム・サーバはその故障を調べ、そのイベントが処理される前にそのノードをグループから削除する。
【００３０】
イベント４０７は更新であるが、そのノードはグループ・リーダーではない。このイベントについてのメッセージは、ネーム・サーバにより処理されるべく正しいグループ連続番号を含んでいなければならない。このメッセージは、米国特許出願第０８／６４０２１９号「ＭＥＴＨＯＤ  ＦＯＲ  ＧＲＯＵＰ  ＬＥＡＤＥＲ  ＲＥＣＯＶＥＲＹ  ＩＮ  Ａ  ＤＩＳＴＲＩＢＵＴＲＥＤ  ＣＯＭＰＵＴＩＮＧ  ＥＮＶＩＲＯＮＭＥＮＴ」に記載されたグループ・リーダーの故障の結果としての回復プロセスにより発生することができる。このメッセージは、前述の通り、グループを形成したルックアップ・メッセージに応答する更新メッセージとしてもよい。イベント４０７においてグループが状態０にある場合、エラーが発生される。グループが状態１にありかつ更新メッセージ中の連続番号が保存された連続番号よりも新しい場合、そのノードがグループ・リーダーとして記録され、グループは状態２へ移行する。連続番号が古い場合、エラーが発生される。イベント４０７においてグループが状態２にありかつ連続番号がより新しい場合、そのノードが新しいグループ・リーダーとして記録される。メッセージの連続番号の方が古い場合、エラーが発生される。
【００３１】
イベント４０８は更新であり、そのノードが既にグループ・リーダーである。このイベントについてのメッセージは、グループ連続番号を含まなければならない。イベント４０８においてグループが状態０にある場合、エラーが発生される。イベント４０８において状態１にあるエントリはない。この状態は発生し得ないからである。イベント４０８においてグループが状態２にあり、かつ連続番号が、保存されている連続番号よりも新しい場合、その要求しているノードがグループ・リーダーとして保持され、その連続番号が保存される。連続番号が、保存されている連続番号よりも古い場合、エラーが発生される。このイベントは、例えば連続番号が重なるときなどに古い連続番号が正しい連続番号として認識されないように、連続番号を増分するために用いることができる。
【００３２】
イベント４１０は、故障が検知されたときに送信される。例えば、前述の米国特許出願第０８／６４０２１９号に記載がある。イベント４１０においてグループが状態１にある場合、故障したノードは、ＩＰＳ及びルックアップ・キューの全てのエントリから除かれる。もしこれがＩＰＳ内の最後のエントリであれば、状態が、状態０へ変更される。もしグループが状態２にある場合、故障したノードは、ＩＰＳ及びルックアップ・キューの全てのエントリから除かれる。もしこれがＩＰＳ内の最後のエントリであれば、状態が、状態０へ変更される。このノードがグループ・リーダーであるならば、状態が、状態１へ変更される。
【００３３】
図５は、本発明を実施するためにネーム・サーバにより実行されるプログラム５００の流れ図である。図５の流れ図は、説明を簡単にするために単純なブロック図としてある。各イベントにおいて採られる実際の対応動作については、図４の状態図及び以下の説明を参照されたい。
【００３４】
プログラム５００は、ブロック５０１で開始される。ブロック５０２において、ネーム・サーバがメッセージを受信する。ブロック５０３において、プログラムは、そのグループに対してどのイベントが要求されているかを判断し、そのグループのグループ状態を判断し、そしてもし存在するならばグループ・リーダーを判断する。イベントは、ブロック５０５においてルックアップ・イベントヘ、ブロック５０６におい更新イベントへ、ブロック５０７において削除イベントへ、そしてブロック５０８においてノード故障イベントへと分割される。
【００３５】
ブロック５０５のルックアップ・イベントにおいてプログラムは、図４のイベント４０１及び４０２について説明した処理を実行する。ブロック５２８においてプログラムは、グループ状態の変化からルックアップ・キューを処理するべきか否かを決定する。最後に、いずれの要求メッセージもブロック５１４において送信され、プログラムは、次のメッセージを受信するべくブロック５０２へ戻る。
【００３６】
ブロック５０６の更新イベントにおいてプログラムは、ブロック５２０においてそのメッセージのネーム、トークン、及び連続番号を検査する。これらが正しくない場合、ブロック５２２においてエラーが発生される。そしてプログラムは、次のメッセージを受信するべくブロック５０２へ戻る。ネーム、トークン、及び連続番号が正しい場合、ブロック５２４においてプログラムは、イベントにより要求されたとおりにグループ・リーダー及び保存された連続番号を更新する。その後プログラムはブロック５２６へ進み、そのグループ状態を変更すべきか否かを決定する。ブロック５２８においてプログラムは、ルックアップ・キューを処理すべきか否かを決定する。グループ状態の変更により必要となる場合があるからである。ブロック５１４においてプログラムは、イベントにより要求された全てのメッセージを送信し、そして次のメッセージを受信するべくブロック５０２へ戻る。
【００３７】
ブロック５０７の削除イベントである場合、プログラムは、ネーム及びトークンが正しいか否か、及び、削除されるべきノードがＩＰＳ内にあるか否かを判断する。ネーム及びトークンが正しくないか、又は、削除されるべきノードがＩＰＳ内にない場合、ブロック５２２においてプログラムはエラーを発生し、次のメッセージを受信するべくブロック５０２へ戻る。ネーム及びトークンが正しく、かつ、ノードがＩＰＳ内にある場合、ブロック５３２においてプログラムは、ノードをＩＰＳから取り除く。その後プログラムはブロック５２６において、グループ状態を変更すべきか否か決定する。さらにブロック５２８において、ルックアップ・キューを処理すべきか否かを決定し、ブロック５１４においてイベントにより要求された全てのメッセージを送信する。
【００３８】
ブロック５０８のノード故障である場合、ブロック５３２においてプログラムは、全てのグループについてＩＰＳからそのノードを取り除く。その後プログラムはブロック５２６、５２８、及び５１４へ移行し、そして次のメッセージを受信するためにブロック５０２へ戻る。
【００３９】
以上、本発明を好適例について説明したが、本発明をここに開示された詳細な構成に限定することを意図しておらず、これらの変形及び修正は本発明の範囲に含まれる。
【図面の簡単な説明】
【図１】本発明の分散コンピュータ・システムの概略的構成図である。
【図２】図２の分散コンピュータ・システムにおけるプロセッサ・ドメインの構成図である。
【図３】図２のドメイン上のプロセッサ・グループを管理するネーム・サーバのテーブルを示す構成図である。
【図４】図３のテーブルにより管理されるプロセッサ・グループのイベント及び状態を示す状態図である。
【図５】本発明を実施する図２のドメインのネーム・サーバにおけるプログラムの流れ図である。
【符合の説明】
１００  分散コンピュータ・システム
１０２  ローカル・エリア・ネットワーク（ＬＡＮ）
１０４  ＬＡＮゲート
１０５  ＳＰスイッチ
１０６  ノード
１１２  制御ワークステーション
１１４  直接アクセス記憶装置
２００  区画
２０１  ドメイン
２０２  ネーム・サーバ
２０４、２０５、２０６  グループ・リーダー
３００  テーブル
【図１】
0003554471.tif 000002
【図２】
0003554471.tif 000003
【図３】
0003554471.tif 000004
【図４】
0003554471.tif 000005
【図５】
0003554471.tif 000006