(57)【特許請求の範囲】
【請求項１】
ネットワークを介して互いに結合された複数のノードと、一のグループを形成し且つ前記複数のノードのうち少なくとも１つのノードによって実行されるように構成された複数のメンバ・ジョブ（以下「メンバ」と略記）とを備え、前記グループ内の互いに異なるメンバが通信損失が介在する異なるノード間に配置される場合には、前記グループが複数のパーティションに分割され、前記異なるメンバ間の通信が再確立される場合には、前記複数のパーティションを再び前記グループに併合する操作を開始するためのマージ要求が前記複数のパーティション内の各メンバに送信されるようになっているクラスタ化コンピュータ・システムにおいて、前記複数のパーティション内の各メンバによって受信されたマージ要求を処理する方法であって、
（ａ）前記各メンバが配置された各ノードにおいて、当該各メンバが受信した各要求の相対的受信順序を示すために当該各受信要求に対して一連の受信識別子をローカルに割り当てるとともに、当該各受信要求をそれに関連したプロトコルの実行が開始するまで当該各ノード内のキュー上に保持するように、当該各メンバの初期化を行うステップと、
（ｂ）前記各メンバが配置された前記各ノードにおいて、前記マージ要求を受信するステップと、
（ｃ）前記各メンバが配置された前記各ノードにおいて、各受信要求を前記受信識別子に基づいて順番に処理するため、前記マージ要求の受信の時点で前記キュー上に保持されている各受信要求の受信識別子を前記マージ要求の受信識別子と比較し、当該各受信要求の受信識別子が当該マージ要求の受信識別子よりも小さい場合には、当該各受信要求をキャンセルするステップと、
を有することを特徴とする方法。
【請求項２】
前記ステップ（ｃ）は、前記キャンセルすべき各受信要求の発信元に対してキャンセル完了メッセージを返送するステップを含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記ステップ（ｃ）は、前記各受信要求の受信識別子が前記マージ要求の受信識別子よりも小さくない場合には、当該各受信要求に関連したプロトコルを実行するステップを有することを特徴とする請求項１に記載の方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、一般にクラスタ化したコンピュータ・システム上でのマージ処理に関する。
【０００２】
【従来の技術】
「クラスタ化」は、コンピュータ・タスクを協同して実行するために多数のコンピュータ又はノードによってネットワークが構築されているコンピュータ・システム構成を意味する。コンピュータ・クラスタの重要な態様は、クラスタ内のノード全てが単一のシステム像を示すということであり、すなわちユーザから見ればクラスタ内のノードが単一のコンピュータ又は実体として集合的に現れるということである。
【０００３】
クラスタ化は、パフォーマンス及び信頼性が高いことが重要である比較的大規模なマルチ・ユーザ・コンピュータ・システムにおいてしばしば利用される。例えば、クラスタ化は冗長性又は耐故障性（フォールト・トレランス）を与えるために使用することもでき、その結果、万が一クラスタ内の任意のノードが故障してもそのノードによって以前に実行された操作が該クラスタ内の他のノードによって処理される。クラスタ化は、多数のノードによってしばしば単一のコンピュータよりも多くのタスクを並行処理することができるため、全体的なパフォーマンスの増加にも使用することができる。しばしば、負荷の最適配分もまたタスクがノード間に適正に分配されることを保証することで個々のノードが過負荷状態になるのを防ぎ、それによって全体的なシステム・パフォーマンスを最大限にする。クラスタ化の具体的な適用例として、例えばデータベース又は記憶装置等の共有リソースに対するマルチ・ユーザ・アクセスを提供することが挙げられる。なぜなら、多数のノードによって比較的多くのユーザ・アクセス要求を処理することができ、またクラスタ内のノードの何れか１つが故障しても共有リソースは利用可能であるためである。
【０００４】
クラスタは、個々のノード内での「ジョブ」又は「プロセス」の実行を介してコンピュータ・タスクを処理する。場合によっては、異なるノードで実行されているジョブが互いに協同して１つのコンピュータ・タスクを処理する。そのような協同的ジョブは、互いに通信することができ、「グループ」として知られている論理的な実体を用いてクラスタ内で管理される。グループには何らかの形の識別子が割り当てられており、そのような識別子がグループ内の各ジョブに付けられ、該グループ内におけるメンバシップを示すことになる。
【０００５】
グループ内のメンバ・ジョブ（以下、「グループ・メンバ」又は「メンバ」とも称する）は、順序付けられたメッセージに基づくスキームを使用して互いに通信し合う。この際、どのメンバも他のメンバと同一順序で他のメンバによって送られたメッセージを見るように、グループ・メンバ間で送信されたメッセージの順序が保たれ、ノード間の同期が確保される。グループ・メンバによって実行される操作に対する要求は、しばしば「プロトコル」と呼ばれ、一般にそれは該グループのメンバによって協同的に複数のタスクが実行される１つ以上のプロトコルを使用して行われる。
【０００６】
クラスタは、例えばメンバ・ジョブをグループに加えるか、又は該グループから除去する必要がある場合、しばしばメンバシップ変更プロトコルを使用することでグループ・メンバシップにおける変化をサポートする。幾つかのクラスタ化システムでは、メンバシップ変更プロトコルは、ピア・プロトコルの一種として実現され、全てのメンバがメッセージを受信し、各メンバがどのようにそのプロトコルを処理するかをローカルに決定し、またメッセージがそのメンバによって首尾よく処理されたかどうかを示す承認を送り返すことが求められる。ピア・プロトコルによれば、メンバは全てのメンバから承認を受けるまで他の作業を進めることを禁止される。他のシステムでは、メンバ変更プロトコルは、マスタ・スレーブ・プロトコルとして処理してもよく、該メンバの１つはリーダとして選ばれ、プロトコルが適当に処理されることを確実にするために他のメンバを制御する。
【０００７】
クラスタ化コンピュータ・システムで実現可能なメンバシップ変更操作として独特なものの一例としてマージが挙げられる。マージは、クラスタ内の通信損失に起因してグループがパーティション化された後に必要となる。特に、クラスタにおける通信損失に起因して、該クラスタ内における１つ以上のノードと他のノードとの間の通信が妨げられることがある。そのため、１つのグループ内の異なるメンバが通信損失が介在する異なるノード間に配置される時は常に、該グループの多数の、しかし独立したインスタンス（以下、「パーティション」とも称する）がクラスタ内に形成されることがある。したがって、マージは、通信が再確立された後に、複数のパーティションを再び単一のグループに併合（マージ）するために使用される。
【０００８】
通信損失のように、マージは１つのグループに関して非同期的である。すなわち、マージは任意の時間に生ずることができる。しかし、グループが通信損失に起因してパーティション化されている場合でさえ、各パーティションは有用な作業を実行する。さらに、パーティションは、ノード障害のインスタンスとは異なり、パーティション化の結果として当該パーティションを「離れた」任意のメンバがアクティブなままであり、有用な作業を実行しているものと想定する。その結果、マージが生ずる場合はいつでも、パーティション内の任意に進行中の作業が適当な方法で処理されること、さらに多数のパーティションで実行されている進行中の作業が整合していることを保証することが必要であり、それによってグループのメンバの全てがマージの完了時に互いに「同期」される。さもなければ、異なるメンバ間の競合又は不整合は、システム・エラー、データ破壊、又はシステム障害さえも引き起こすかもしれない。
【０００９】
前述のマージ操作の非同期性を前提として、従来のクラスタ化コンピュータ・システムは、元のグループ編成を再確立するためにマージが可能な限り素早く生ずることを保証するべく、マージ要求を受けると直ちにそのような操作を行う。しかし、そのようにすることで多くの不確定的なアクションを導入することがある。なぜなら、マージの時点で進行中のプロトコルは、該マージが処理された後に、すなわち要求元のメンバによって認識されていたメンバシップが変化した後に、完了するであろうからである。
【００１０】
さらに、従来のクラスタ化コンピュータ・システムは、マージ操作を行うために、マスタ・スレーブ型プロトコルを利用する。しかし、マスタ・スレーブ型プロトコルは、多くの点で著しく制限されている。第１に、マスタ・スレーブ型プロトコルは、リーダ又はマスタの障害を生ずる場合が多い。第２に、マスタ・スレーブ型プロトコルは、しばしばマージ実行に使用される集中データ構造を必要とするため、ノード間の追加的な通信を必要とし、地理的に分散したノードに関して著しく制限される。
【００１１】
【発明が解決しようとする課題】
したがって、当該技術分野において、クラスタ化コンピュータ・システムにおいて多数のパーティションを併合するためにマージ操作を行う改善された方法が強く求められている。
【００１２】
【課題を解決するための手段】
従来技術の前記課題を解決するため、本発明は、一グループの各パーティションにおいて全ての保留中のプロトコルが処理されるまで、該グループ内のマージ・プロトコルの実行を遅らせるために、順序付けられたメッセージを使用する。前記マージ・プロトコルの実行の遅延は、例えば、該マージ・プロトコルの実行に先立って、保留されている各プロトコルのキャンセル又は完了の何れかを保証することによって行われる。各グループ・メンバの観点からは、前記マージ・プロトコルの実行は、以前に受信された保留中の要求の全ての処理が完了するまで、該メンバによる前記マージ要求の処理を禁止することによって遅延される。
【００１３】
従来のクラスタ化コンピュータ・システムでは、クラスタ内のプロトコルの順序外でマージ・プロトコルが実行されるのに対し、本発明では、マージ・プロトコルが他のプロトコルとともに順序付けられる。そのようにすることで、パーティションの同期が著しく単純化される。なぜなら、各グループ・メンバは、保留中のプロトコルが保留中のマージ・プロトコルの前又は後の何れに要求されたかを判断し、その結果に応じて（すなわち、前記マージ・プロトコルの前後でどのメンバがパーティション／グループに存在するかに基づいて）保留中のプロトコルを処理することができるからである。さらに、そのようにすることで、ピア型マージ・プロトコルの使用が促進され、パーティション同期の実行にマスタ又は集中データ構造に頼る必要がなくなる。
【００１４】
本発明の構成は、特許請求の範囲に示される。しかし、本発明をより一層理解し、また本発明の実施に伴う利点及び目的をより一層理解するために、以下の詳細な説明及び添付図面を参照すべきである。
【００１５】
【発明の実施の形態】
以下で説明する実施形態は、クラスタ化コンピュータにおいてマージ要求を処理するために（例えば、クラスタ化コンピュータ・システムの１つ以上のノードに論理的に常駐する複数のパーティションを併合するために）、順序付けられたメッセージを利用する。例えば、図１のクラスタ化コンピュータ・システム８は、相互接続ネットワーク１１を介して互いに相互接続した複数のノード１０を有することができる。クラスタ化コンピュータ・システムで普通に利用される任意のネットワーク・トポロジを本発明と整合する態様で使用することができる。さらに、個々のノード１０を、他のノードに近接して配置するか、又は広域ネットワーク（ＷＡＮ）を介して他のノードから離隔して配置することができる。
【００１６】
クラスタ化コンピュータ・システムの状況では、少なくとも幾つかのコンピュータ・タスクは、互いに通信することができる複数の協同的コンピュータ・プロセス（以下、「ジョブ」とも称する）を実行中の多数のノードによって協同的に実行される。そのような協同的ジョブは、１つの「グループ」に論理的に編成され、その場合、各協同的ジョブは、該グループの「メンバ」と呼ばれる。しかし、複数のグループ・メンバは、必ずしも共通のタスクについて動作する必要はない。１つのグループに属する複数のメンバにとって必要とされる全ては、実行中にそのようなメンバが互いに通信することができるということである。
【００１７】
図１は、複数のノード１０からなるクラスタを例示する。参照の便宜上、これらのノードには、連続する識別子１、２、３、．．．．Ｎ、Ｎ＋１、Ｎ＋２、．．．Ｍ（Ｍ＞Ｎ）が付されている。このような様々なノード内に常駐する複数のジョブＪ１〜Ｊ７は、クラスタ化コンピュータ・システムの例示的なグループのメンバを形成する。図１に示すように、クラスタ化コンピュータ・システムのノードは、全てのグループに加わる必要はない（例えば、ノード３）。さらに、所定のグループからの多数のジョブが同一のノードに常駐してもよい（例えば、ノード１のジョブＪ１及びＪ２）。
【００１８】
この実施形態では、メンバ・ジョブは、順序付けられたメッセージを用いることで互いに通信を行う。そのようなメッセージの一部を、ここでは「要求」と呼ぶ。これらの「要求」は、ユーザ（例えば、クラスタ化コンピュータ・システム内の１つ以上のノードで実行されるアプリケーション又は他のコンピュータ・プロセス）による起動に応答して「プロトコル」を開始させるために使用される。プロトコルは、１つのグループの全てのメンバが処理するために必要とする、作業の単位である。プロトコル要求に応答して、各メンバは、特定のプロトコルの成功又は失敗を示す肯定応答メッセージを戻すことが必要とされる。さらに、どのメンバも、全てのグループ・メンバから肯定応答メッセージを受信するまで、その操作を継続することを許されず、もし１つのメンバに障害が生ずると、該障害が肯定応答メッセージに翻訳され、プロトコルがハングアップするのを防ぐ。
【００１９】
グループ内のメンバシップは静的である必要はない。多くのクラスタ化コンピュータ・システムは、１つのグループにメンバを加えたり、該グループからメンバを削除したりする能力をサポートする。グループのメンバシップにおける変化は、メンバシップ変更プロトコルと呼ばれる特定のプロトコルを介して処理され、具体的には、グループの全てのメンバに送られたメンバシップ変更要求メッセージの使用を介して処理される。
【００２０】
前述のように、クラスタ化コンピュータ・システムの実行中に生ずるかもしれない１つの現象は、グループ内のジョブが互いに通信するための能力を切断する通信損失であり、その場合、該グループは２つ以上のパーティションに分割され始めるか、又は同一グループの独立したインスタンスとなる。一例として、図１のジョブＪ１〜Ｊ７によって１つのグループが形成されている場合に、もしノードＮとノードＮ＋１との間で通信損失が生ずるならば、２つのパーティションＰ１及びＰ２が生成され、パーティションＰ１にジョブＪ１〜Ｊ４が組み込まれ、パーティションＰ２にジョブＪ５〜Ｊ７が組み込まれるであろう。
【００２１】
この実施形態では、通信が再確立されるたびに、マージ要求を介して開始されたマージ・プロトコルを使用することにより、複数のパーティションを併合することが可能である。マージ要求は、併合されるべき各パーティションの全てのメンバに送られ、各メンバは適当な肯定応答メッセージを介して応答する。マージ・プロトコルは、１つのグループに関して非同期的に開始され得る。したがって、そのようなプロトコルは、他のプロトコルを実行中の任意の時間に開始されることがある。しかし、マージが起こる時に各パーティション内のメンバが異なるプロトコルを処理することができるものと仮定すると、該マージ・プロトコルが完了した時点におけるグループ・メンバ間のコヒーレンスを保証するために該他のプロトコルを適当な方法で実行することが重要である。
【００２２】
例えば、もしマージが生じる時に１つのパーティション内で１つのプロトコルが実行されているならば、該プロトコルに関連したメッセージは、他のパーティション内の他のプロトコルに対するメッセージと区別されなければならない。また、別のパーティションではなく、１つのパーティション内に保留中のプロトコル要求がある場合には、マージに先立って、これらの保留中のプロトコル要求を処理することが必要である。全てのパーティションが同一のプロトコルで働くように、マージ後に複数のパーティションを同期させることも必要である。
【００２３】
本発明の実施形態は、マージに先立って開始された任意のプロトコル要求の処理がマージ・プロトコル処理に先立って完了することを保証することにより、そのようなコヒーレンスを提供することを試みる。この実施形態は、順序付けられたメッセージを使用することに依存しており、それによって各プロトコル要求に受信識別子（例えば、数字又は他の適当な一続きの標識）が割り当てられ、該識別子は他の受信された要求に対するそのような要求の受信の相対的順番を示す。この実施形態では、他のメッセージ、例えば肯定応答メッセージには、要求識別子が割り当てられるのではなく、該メッセージが応答する特定の要求を識別するための要求ハンドルが割り当てられる。したがって、マージ要求は、同期ポイントとして機能し、そのポイント以降は任意の要求が全てのグループ・メンバに送られたものと見なされよう。
【００２４】
保留状態にあるプロトコル要求は、該要求が関連しているプロトコルのキャンセル又は終了の何れかによって、マージ・プロトコル要求の処理に先立って処理される。この実施形態では、マージ・プロトコル要求の受信時点で未だ実行が開始されていない任意の保留プロトコル要求がキャンセルされるのに対し、マージ・プロトコル要求の受信時点で実行が開始されている任意の保留プロトコル要求は該マージの処理に先立って完了することが許される。
【００２５】
クラスタ化コンピュータ・システムによるコンピュータ・タスクの取り扱いを説明するために本明細書で具体的に使用された以外の用語を他の環境で使用してもよいことは容易に理解されるだろう。したがって、本発明は、本明細書で使用した特定の用語（例えば、プロトコル、要求、メッセージ、ジョブ、マージ、パーティション等）に限定されるべきではない。
【００２６】
図２は、クラスタ化コンピュータ・システム８を構成するノード１０の１つのハードウェア構成を例示する。ノード１０は、例えばネットワーク・サーバ、ミッドレンジ・コンピュータ、メインフレーム・コンピュータ等のマルチユーザ・コンピュータの何れかを総称的に表す。しかし、本発明は他のコンピュータ及びデータ処理システム、例えばワークステーション、デスクトップ・コンピュータ、ポータブル・コンピュータ等のスタンドアロン又はシングルユーザ・コンピュータ、又は他のプログラム可能な電子デバイス（例えば、埋め込み式コントローラ等）で実現可能であることを理解すべきである。
【００２７】
ノード１０は、キャッシュ・システム１６内に配置された１レベル以上のキャッシュ・メモリを介して主記憶装置１４に結合した１つ以上のシステム・プロセッサ１２を有する。さらに、主記憶装置１４はシステム入出力（Ｉ／Ｏ）バス１８と複数のインタフェース・デバイス（例えば、入出力アダプタ２０、ワークステーション・コントローラ２２、及び記憶制御装置２４に結合しており、それぞれが１つ以上の外部ネットワーク（例えば、クラスタ・ネットワーク１１）、１つ以上のワークステーション２８、及び／又は１つ以上の記憶装置、例えば直接アクセス記憶装置（ＤＡＳＤ）２６に対する外部アクセスを提供する。代替的に、他のコンピュータ・アーキテクチャも使用することができる。
【００２８】
本発明に従ったマージ・プロトコル処理を実現するために、ジョブ特有のメッセージ処理機能を各ノードに実現されたクラスタ管理ソフトウェアに実現してもよい。例えば、ノード１０は、主記憶装置１４に常駐したオペレーティング・システム３０を有するものとして図示されている。このオペレーティング・システム３０は、本発明に従ったマージ・プロトコル処理を実現するためにクラスタ・マネージャ・プログラム３２を実現する。１つ以上のジョブ又はアプリケーション３４も図示されており、その各々はクラスタ・マネージャ・プログラム３２に実現されたクラスタ化機能にアクセスする。しかし、この機能はノード１０内にあるソフトウェアの他のレイヤに実現されてもよいこと、さらにクラスタ化コンピュータ・システム８内の他のプログラム、コンピュータ、又はコンポーネント間で割り当てられたものであってもよいことは十分に理解されるであろう。したがって、本発明は本明細書に記載された特定のソフトウェア実現に限定されるものではない。
【００２９】
以下、前述のマージ・プロトコル処理機能を実現するために利用される具体的なルーチンに焦点を合わせて説明する。本発明の実施形態を実現するために実行されるルーチンは、オペレーティング・システム又は特定のアプリケーションの一部、コンポーネント、モジュール、又は一連の命令として実現されようとも、ここでは「コンピュータ・プログラム」又は単に「プログラム」と呼ぶことにする。コンピュータ・プログラムは、コンピュータの種々のメモリ及び記憶装置内に様々な時間に常駐し、コンピュータの１つ以上のプロセッサによって読み出し及び実行される場合、本発明の種々の態様を具体化するステップ又は要素を実行するのに必要なステップをコンピュータに実行させる。
【００３０】
後述する種々のプログラムは、本発明の特定の実施形態で実現されるアプリケーションに基づいて識別することができよう。しかし、以下の特定のプログラム名は何れも単に便宜上用いられているにすぎないので、本発明はそのような名称によって識別及び／又は実現される特定のアプリケーションのみでの使用に限定されるべきものではない。
【００３１】
図３及び図４は、グループ・メンバによる実行に適したジョブ初期化ルーチン５０及び受信メッセージ処理ルーチン６０をそれぞれ説明するための図である。なお、これらのルーチンの内部には、前述のマージ・プロトコル処理機能が実現されている。図３のジョブ初期化ルーチン５０は、１つのノード上で１つのジョブが生成されるときはいつでも呼び出される。ルーチン５０に含まれる機能の大部分はマージ・プロトコルの処理には関係ないが、このルーチンでは、マージ・プロトコルの処理に関連した１対の変数を初期化することが行われる。具体的に説明すると、ブロック５２は該ジョブに対するローカル受信（ＬＲ）変数を初期化するもので、該ＬＲ変数は該ジョブによって受信された要求に対して一連の受信識別子を割り当てるために使用される。ブロック５４は、最終マージ（ＬＭ）変数を初期化するもので、該ＬＭ変数は該ジョブによって受信された最終（最も最近に受信した）マージ要求の受信識別子を表す。各変数は、例えば、ゼロの値に初期化される。続いて、ブロック５６は、他のジョブの初期化操作を従来の方法で実行し、それによってルーチン５０が完了する。
【００３２】
図４の受信メッセージ処理ルーチン６０は、１つのジョブが新しいメッセージを受信すると直ちに、すなわち順序付けられたメッセージ・サービスが該メッセージをキュー上に置くと直ちに実行される。ルーチン６０は、ブロック６２で受信されたメッセージに対するメッセージ要求ハンドル（ＲＨ）を得ることによって開始される。既に説明したように、１つのメッセージに対する要求ハンドルは１つのプロトコルを一意的に識別するので、要求及び肯定応答又は他の応答を互いに一致させることができる。
【００３３】
次に、ブロック６４は、既に受信したプロトコル要求に対する肯定応答又は他の応答とは対照的に、受信メッセージがプロトコル要求であるかどうかを判断する。もしそうであれば、ブロック６５に移り、該受信された要求に対して任意の保存メッセージが存在するかどうかの判断が行われる。後述するように、肯定応答等のメッセージは、保留中の（しかし、まだ処理されていない）要求に対して受信され、そのような保留中の要求に関連した保存メッセージを該ジョブに送り出すことができるのは、該保留中の要求が処理される場合である。したがって、そのような状況では、ブロック６５からブロック６６に移り、任意のそのような保存メッセージを該ジョブへ送る。
【００３４】
一度、保存メッセージがそのジョブに送られると（或いは、保存メッセージが存在していなければ）、ブロック６７に移り、（例えば、単調に増加する数列の任意の数を用いて）ローカル受信（ＬＲ）変数を増分することにより、先に受信された要求に後続する現在の要求メッセージに対する受信識別子を生成する。次に、ブロック６８は、ローカル受信（ＬＲ）変数の現在の値を要求メッセージに割り当て、それによって受信識別子を要求メッセージと対応付ける。
【００３５】
次に、ブロック７０は、要求メッセージがマージ要求であるかを判断する。もしそうであれば、ブロック７２に移り、最終マージ（ＬＭ）変数を要求メッセージの受信識別子（すなわち、ローカル受信（ＬＲ）変数の現在の値）と等しく設定する。続いて、ブロック７４に移り、現在の要求メッセージに対する受信識別子（ローカル受信（ＬＲ）変数の現在の値によって表される）が最終受信要求の受信識別子（最終マージ（ＬＭ）変数の現在の値によって表される）よりも小さいかどうかを判断する。また、ブロック７０に戻り、もし要求メッセージがマージ要求でなければ、ブロック７２を飛び越えて直接ブロック７４に移る。
【００３６】
もし、現在の要求メッセージに対する受信識別子が最終受信マージ要求の受信識別子よりも小さければ（マージが生じたことを示す場合）、ブロック７４からブロック７６に移って、マージ・プロトコル処理を実行する。この実施形態では、マージ・プロトコル処理は、現在の要求メッセージによって表されたプロトコルをキャンセルすることを取り入れている。具体的には、該プロトコルの発信元に対して応答を戻すことにより、その要求がマージに起因してキャンセルされたことを示すようにしている。発信元は、要求がキャンセルされたことを知らされると、（必要に応じて）プロトコルを再試行する要求を再発行することができる。マージ要求が処理されると、各メンバは、他のパーティションの全てに対するメンバシップで更新される。そのようにして、再発行されたプロトコルを含む任意の将来のプロトコルは、単にパーティション・メンバではなく、全てのメンバからの応答を必要とするであろう。
【００３７】
ブロック７４に戻り、もし現在の要求メッセージに対する受信識別子が最終受信マージ要求の受信識別子よりも大きければ（マージが生じていないことを示す場合）、単にブロック７８に移り、従来の方法で、例えば後続処理のために該メッセージをジョブに対して送出することで、プロトコル処理を継続する。また、次の点にも留意しておくべきである。すなわち、もし現在の要求メッセージがマージ要求であれば、該現在の要求メッセージのローカル受信（ＬＲ）番号は最終マージ（ＬＭ）番号と同一となり、そのためブロック７４からブロック７８に移り、そこで該メッセージをジョブへ送出することでマージ要求の処理を継続させるだろう。それによって、受信要求の処理が完了する。
【００３８】
ブロック６４に戻り、もし受信メッセージがプロトコル要求でなければ、ブロック８０に移り、該メッセージに対する要求ハンドル（ＲＨ）が任意の保留中の要求のものと一致するかどうかを判断する。すなわち、該受信メッセージが保留中又は現在処理中のプロトコルに対する肯定応答又は他の応答であるかどうかを判断する。もしそうでなければ、ブロック８２に移り、ただ単に該メッセージを破棄して受信メッセージの処理を完了する。代替的に、該メッセージを後続の処理のために保存してもよい。
【００３９】
しかし、もし受信メッセージの要求ハンドル（ＲＨ）が保留中の要求のものと一致すれば、ブロック８０からブロック８３に移り、該受信メッセージの要求ハンドル（ＲＨ）が現在の要求のものと一致するかどうかを判断する。もしそうであれば、ブロック８４に移り、該メッセージがジョブに送出され、それによってプロトコルの完了が可能となる。一方、もし受信メッセージが保留中の要求（現在の要求ではない）に対するものであれば、ブロック８３からブロック８６に移り、後での再生のために該メッセージを保存する。次に、メッセージの処理が完了し、ルーチン６０が終了する。
【００４０】
したがって、ルーチン６０におけるマージ・プロトコル処理は、基本的に、マージが生じた時に既に実行されていた要求を除いて、マージの時点までの全ての要求をキャンセルすることが容易に理解されるだろう。マージ後に受信された要求は、全てのメンバに送られたものと仮定されるので、そのような要求はキャンセルされない。
【００４１】
また、前述のルーチン５０および６０は、ピア型マージ・プロトコルを前提とし、グループ内の全てのメンバが任意のプロトコルに参加するものと仮定する。したがって、もしプロトコル中にマージが生ずるならば、該プロトコルに対して別のパーティションからのメンバが該プロトコルに参加することを禁止することが望ましい。したがって、マージ要求の処理を遅らせることにより、保留中の全てのプロトコル（現在実行されている全てのものが含まれる）が完了（例えば、終了又はキャンセルの何れか）するまで、新しいメンバは認識されない。また、ピア・プロトコルの性質上、各メンバは、特定の要求を実行又はキャンセルすべきかをローカルに判断することができる。しかし、マスタ・スレーブ・プロトコル環境で本発明が実現されてもよいことを理解すべきである。
【００４２】
また、プロトコルが後で処理される時にメッセージを再生することができるように、将来のプロトコルのためにメッセージを保存しておくことが望ましいことがある。そのような状況が生じるのは、例えば、１つのパーティションがマージに先行するプロトコルを実行しているが、別のパーティションが直ちにマージ・プロトコルの実行を開始したような場合（例えば、そのパーティションが保留中の要求を有していなかった場合）である。１つののパーティションがマージを開始する準備ができている場合には、マージ・プロトコルからの全てのメッセージを保存して再生できるようにすることが望ましい。将来のプロトコルは、保留中の要求の要求ハンドル（ＲＨ）を走査することによって検出することができる。過去のプロトコル（すなわち、現在のプロトコル又は将来のプロトコル以外のプロトコル）に対するメッセージが破棄され、またもしメッセージ要求ハンドルが保留中又は将来の要求ハンドルと一致しなければ（すなわち、マージに先立って該要求が別のパーティションから送られた場合）、そのようなメッセージが検出される。
【００４３】
一例として、図１のパーティションＰ１及びＰ２がそれぞれ以下の要求メッセージを所定の順番で受信するものと仮定する。
【００４４】
Ｐ１：Ｒ１１、Ｒ１２、Ｒ１３．．．Ｒ１ｘ、Ｍ、Ｒ３
Ｐ２：Ｒ２１、Ｒ２２、Ｒ２３．．．Ｒ２ｙ、Ｍ、Ｒ３
【００４５】
式中、Ｍはマージ要求である。したがって、要求Ｒ１１からＲ１ｘ及び要求Ｒ２１からＲ２ｙは、マージ要求Ｍに先立って、各パーティションによって受信される。さらに、要求Ｒ３は、マージ要求Ｍの後に、両方のパーティションによって受信される。
【００４６】
さらに、説明の便宜上、マージ要求Ｍが受信された時に、パーティションＰ１が要求Ｒ１１を実行しており、パーティションＰ２が要求Ｐ２１を実行しているものと仮定する。マージ要求Ｍは、最終マージ（ＬＭ）番号を更新する。さらに、要求Ｒ１２〜Ｒ１ｘ及びＲ２２〜Ｒ２ｙは、最終マージ（ＬＭ）番号よりも小さいローカル受信（ＬＲ）番号を有する。
【００４７】
要求Ｒ１１及びＲ２１は異なる要求ハンドル（ＲＨ）を持つため、それらのメッセージは任意の他のプロトコルによっては受信されない。さらに、マージ要求Ｍは未だ処理されていないので、Ｐ１又はＰ２の何れもプロトコル・レベルでマージについて知ることはない（但し、クラスタ・マネージャ通信機構は、それらがマージされるものと見なす）。ルーチン６０内の前述の機能に基づいて、要求Ｒ１１及びＲ２１は完了することを許される。次に、要求Ｒ１２がパーティションＰ１によって処理される準備を完了していると、そのローカル受信（ＬＲ）番号が最終マージ（ＬＭ）番号よりも小さくなり、その結果、この要求がキャンセルされる。同様のアクションは、要求Ｒ１３〜Ｒ１ｘ及びＲ２２〜Ｒ２ｙに関しても起こる。マージ要求Ｍが処理され、さらにマージされたグループの全てのメンバ上でＲ３が処理される。
【００４８】
例えば、もしパーティションＰ２が要求Ｒ２１を実行している最中にパーティションＰ１がマージ要求Ｍの実行を開始すれば、パーティションＰ１のメンバは、マージ要求Ｍに対する肯定応答メッセージをパーティションＰ２に送ることができる。しかし、パーティションＰ２内の各メンバは、その保留中要求のリストを走査することにより、肯定応答メッセージがマージ要求Ｍに関する要求ハンドルと一致することを検出する。その結果、パーティションＰ２内の各メンバは、これらのメッセージを保存し、パーティションＰ２内でマージ要求Ｍが処理される場合にそのようなメッセージに対して応答する。
【００４９】
マージ要求Ｍが最終的に処理されると、全てのパーティションが同期する。マージ要求Ｍの処理は全ての将来のプロトコルが認識するメンバシップを更新するので、そのようなプロトコルは全てのパーティションからの全てのメンバを含むことになる。肯定応答ラウンドが使用されるので、処理に先立って全てのメンバが肯定応答メッセージを送信し、かつ全てのメンバから肯定応答メッセージを受信するまで、全てのメンバが待ち状態となるだろう。したがって、マージされたグループが同期される。次に、マージされたグループ上で、要求Ｒ３を処理することができる。そのローカル受信（ＬＲ）番号は最終マージ（ＬＭ）番号よりも大きくなるので、プロトコルは全てのグループ・メンバ上で実行されるだろう。
【００５０】
前述の機能は、種々のクラスタ化コンピュータ・システムで実現可能である。本発明の１つの可能なアプリケーションは、例えばInternational Business Machines Corporationから入手可能であるＡＳ／４００ベースのクラスタ化コンピュータ・システムにある。そのようなインプリメンテーションでは、各ノードのマシン・インタフェース（ＭＩ）レイヤ内にある要求キューに要求を保持し、そのような要求が処理可能な状態となると、デキューするようにしてもよい。要求ハンドルは、要求がグループに送られる時に割り当てられる汎用固有識別子（ＵＵＩＤ：Universally Unique IDentifiers）として実現してもよい。
【図面の簡単な説明】
【図１】  本発明に従ったクラスタ化コンピュータ・システムのブロック図である。
【図２】  図１に示すクラスタ化コンピュータ・システムのノードの１つを説明するためのブロック図である。
【図３】  図１に示すクラスタ化コンピュータ・システムのグループ・メンバによって実行されるジョブ初期化ルーチンのプログラム・フローを説明するためのフローチャートである。
【図４】  図１に示すクラスタ化コンピュータ・システムのグループ・メンバによって実行される受信メッセージ処理ルーチンのプログラム・フローを説明するためのフローチャートである。
【符号の説明】
８        クラスタ化コンピュータ・システム
１０      ノード
１１      ネットワーク（クラスタ・ネットワーク）
３０      オペレーティング・システム
３２      クラスタ・マネージャ・プログラム
３４、３６    ジョブ又はアプリケーション
【図１】
0003798661.tif 000002
【図２】
0003798661.tif 000003
【図３】
0003798661.tif 000004
【図４】
0003798661.tif 000005