(57)【特許請求の範囲】
【請求項１】
相互に接続された多数のノードと、これらの全ノードがアクセス可能に接続された共有資源とから成り、前記各ノード上に相互に依存する複数のレベルに分類された多数のサブシステムを有するマルチプロセッサ・クラスタ・システムにおいて、前記クラスタにノードを加入し、クラスタ全体が前記共有資源を含む実質的に単一のノードとして動作するようにする方法であって、
現在前記クラスタ内にある複数のノード上で実行中の全レベルのサブシステムに、そのクラスタに対して加入および離脱するノードの遷移を通知することによって前記複数の各ノードにおいてクラスタ全体の状態遷移の一貫した処理を実行することを特徴とする前記方法。
【請求項２】
請求項１記載の方法において、前記サブシステムがより高位のサブシステムとより低位のサブシステムから成り、より高位のサブシステムの動作が対応するより下位のサブシステムの動作に依存することを特徴とする前記方法。
【請求項３】
請求項２記載の方法であって、現在前記クラスタ内にある全ての前記ノード上の前記サブシステムの１つに、遷移を通知し、現在前記クラスタ内にある全ての前記ノード上の前記サブシステムの他のものに、遷移を通知する前に、前記サブシステムの前記１つにおいて、前記通知を処理することを含むことを特徴とする前記方法。
【請求項４】
請求項３記載の方法であって、前記クラスタに加入するノードの遷移を、低位サブシステムから始めて順に高位サブシステムまでのサブシステムに通知することを含むことを特徴とする前記方法。
【請求項５】
請求項３記載の方法であって、前記クラスタから友好的に離脱するノードの遷移を、高位サブシステムから始めて順に低位サブシステムまでのサブシステムに通知することを含むことを特徴とする前記方法。
【請求項６】
請求項３記載の方法であって、
他のプロセッサによって前記クラスタから追い出されたノードの遷移を、低位サブシステムから始めて順に高位サブシステムまでのサブシステムに通知することを含むことを特徴とする前記方法。
【請求項７】
請求項２記載の方法において、前記サブシステムは、ユーザ・プログラムと相互作用を行う、高位サブシステムを含むことを特徴とする前記方法。
【請求項８】
請求項７記載の方法において、前記高位サブシステムは、前記ユーザ・プログラムを実行するノードが前記クラスタを離脱するとき、自動的かつ原子的に、ユーザ・プログラムを他のノードに移転するサービスを含むことを特徴とする前記方法。
【請求項９】
請求項２記載の方法において、前記サブシステムは、分散鎖錠マネージャ・サブシステムと、仮想ディスク・マネージャ・サブシステムと、共有ファイル・サブシステムとを含むことを特徴とする前記方法。
【請求項１０】
請求項１記載の方法において、前記クラスタに加入するノードの遷移について、前記方法は、
ａ）前記加入するノードのサブシステムを登録し、遷移通知を受け取るステップと、
ｂ）前記ノードを前記クラスタに加入するステップと、
ｃ）前記クラスタ内の登録済みサブシステムに、前記加入するノードが前記クラスタに加入したことを通知するステップと、
を含むことを特徴とする前記方法。
【請求項１１】
請求項１記載の方法において、他のノードによって前記クラスタから追い出される１つのノードの遷移について、前記方法は、
ａ）前記１つのノードが前記クラスタから追い出されていることを、前記他のノードが登録済みサブシステムに通知するステップと、
ｂ）前記１つのノード上で実行中の登録済みプログラムを原子的に別のノードに移転し、前記プログラムを復元して前記別のノード上で実行するステップと、
を含むことを特徴とする前記方法。
【請求項１２】
相互に接続された多数のノードと、これらの全ノードがアクセス可能に接続された共有資源とから成り、前記各ノード上に相互に依存する複数のレベルに分類された多数のサブシステムを有するマルチプロセッサ・クラスタ・システムにおいて、クラスタ内の前記ノードの特定のものの上でクライアント・サービスを実行し、当該クライアント・サービスに対してクラスタ全体が前記共有資源を含む実質的に単一のノードとして動作するようにする方法であって、
ノードを前記クライアント・サービスに関係付ける規則を定義する選択因子を用いて、各クライアント・サービスを実行するノードを選択し、前記クライアント・サービスを前記選択されたノードに登録し、現在前記クラスタ内にあるノードに、前記特定のクライアント・サービスが前記特定のノードに登録されたことを通知し、更に前記特定のノードが前記クラスタを離脱するとき、前記特定のサービスを他のノードに移転することを含む前記方法。
【請求項１３】
請求項１２記載の方法であって、更に、前記クライアント・サービスを前記選択されたノードに登録したことに応答して、前記クライアント・サービスに含まれる作用パラメータにしたがって、当該ノード上のクライアント・サービスを起動することを含むことを特徴とする前記方法。
【請求項１４】
請求項１３記載の方法であって、更に、クライアント・サービスを、親クライアント・サービスと、少なくとも１つの子クライアント・サービスに類別し、類別されたクライアント・サービスを同一ノードに登録し、前記親クライアント・サービスに含まれる作用パラメータにしたがって、類別されたクライアント・サービスを起動することを含むことを特徴とする前記方法。
【請求項１５】
請求項１２記載の方法において、前記選択因子は、許可ノードと、不許可ノードと、ノード優先度とを含む群から選択されることを特徴とする前記方法。
【請求項１６】
請求項１２記載の方法であって、更に、前記クラスタに加入するノードに、前記特定のクライアント・サービスが前記特定のノードに登録されたことを通知することを含むことを特徴とする前記方法。
【請求項１７】
請求項１２記載の方法であって、イベント監視部を用いて、あるノードに登録されたクライアント・サービスを前記ノードにおいて監視することを含むことを特徴とする前記方法。
【請求項１８】
請求項１７記載の方法であって、前記クライアント・サービスの登録に応答して前記イベント監視部をイネーブルし、前記クライアント・サービスの登録抹消に応答して前記イベント監視部をディゼーブルすることを含むことを特徴とする前記方法。
【請求項１９】
請求項１２記載の方法において、前記多数のサブシステムは、前記ノードのどれが現在前記クラスタにあるのかを制御するクラスタ・メンバシップ・マネージャを含み、前記クラスタ・メンバシップ・マネージャは、どのノードが前記クラスタにあるのかについての通知を与えることを特徴とする前記方法。
【請求項２０】
請求項１９記載の方法において、前記ノードの内特定のノード上でのサービス開始は、前記多数のサブシステムの別の１つによって実行されることを特徴とする前記方法。
【請求項２１】
相互に接続された多数のノードと、これらの全ノードにアクセス可能に接続された共有資源と、前記ノード間のクラスタ通信媒体とから成り、前記各ノード上の多数のサブシステムを有するマルチプロセッサ・クラスタ・システムであって、
現在前記クラスタ内にある複数のノード上で実行中のサブシステムに、そのクラスタに対して加入および離脱するノードの遷移を通知することによって前記複数の各ノードにおいてクラスタ全体の状態遷移の一貫した処理を実行するように構成されたメンバシップ・マネージャ・サブシステムと、
クラスタ・エラーを検出し、これに反応するように構成されたイベント・マネージャ・サブシステムと、
前記イベント・マネージャに応答し、クラスタ内の前記ノードの特定のものの上でクライアント・サービスを実行し、当該クライアント・サービスに対してクラスタ全体が前記共有資源を含む実質的に単一のノードとして動作するように構成された登録および起動サービスであって、各クライアント・サービスに対してノードを選択し、当該ノードに前記クライアント・サービスを登録し、現在前記クラスタ内にあるノードに、前記特定のサービスが前記特定ノードに登録されたことを通知する、前記登録および起動サービスと、
から成ることを特徴とする前記マルチプロセッサ・クラスタ・システム。
【請求項２２】
請求項２１記載のマルチプロセッサ・クラスタ・システムにおいて、前記サブシステムがより高位のサブシステムとより低位のサブシステムから成り、より高位のサブシステムの動作が対応する低位のサブシステムの動作に依存することを特徴とする前記マルチプロセッサ・クラスタ・システム。
【請求項２３】
請求項２２記載のマルチプロセッサ・クラスタ・システムにおいて、前記メンバシップ・マネージャ・サブシステムは、現在前記クラスタ内にある全ての前記ノード上の前記サブシステムの１つに遷移を通知し、前記メンバシップ・マネージャ・サブシステムが、現在前記クラスタ内にある全ての前記ノード上の他のサブシステムに前記遷移を通知する前に、全ノード上の前記サブシステムの１つが前記通知を処理することを特徴とする前記マルチプロセッサ・クラスタ・システム。
【請求項２４】
請求項２３記載のマルチプロセッサ・クラスタ・システムにおいて、前記メンバシップ・マネージャは、ノードがクラスタに加入する遷移を、低位サブシステムから開始し、高位サブシステムまで連続的に、サブシステムに通知することを特徴とする前記マルチプロセッサ・クラスタ・システム。
【請求項２５】
請求項２３記載のマルチプロセッサ・クラスタ・システムにおいて、前記メンバシップ・マネージャは、ノードが友好的に前記クラスタを離脱する遷移を、高位サブシステムから開始し、低位サブシステムまで連続的に、サブシステムに通知することを特徴とする前記マルチプロセッサ・クラスタ・システム。
【請求項２６】
請求項２３記載のマルチプロセッサ・クラスタ・システムにおいて、前記メンバシップ・マネージャは、ノードが他のプロセッサによって前記クラスタから追い出される遷移を、低位サブシステムから開始し、高位サブシステムまで連続的に、サブシステムに通知することを特徴とする前記マルチプロセッサ・クラスタ・システム。
【請求項２７】
請求項２１記載のマルチプロセッサ・クラスタ・システムにおいて、前記登録および起動サービスは、クライアント・サービスをノードに登録したことに応答して、前記クライアント・サービスに含まれる作用パラメータにしたがって、前記ノード上で前記クライアント・サービスを起動することを特徴とする前記マルチプロセッサ・クラスタ・システム。
【請求項２８】
請求項２７記載のマルチプロセッサ・クラスタ・システムにおいて、前記登録および起動サービスは、クライアント・サービスを親クライアント・サービスと少なくとも１つの子クライアント・サービスとして類別するように構成され、前記登録および起動サービスは、更に、類別したクライアント・サービスを同一ノードに登録し、前記親クライアント・サービスに含まれる作用パラメータにしたがって、類別したクライアント・サービスを起動することを特徴とする前記マルチプロセッサ・クラスタ・システム。
【請求項２９】
請求項２１記載のマルチプロセッサ・クラスタ・システムにおいて、前記登録および起動サービスは、ノードを前記クライアント・サービスに関係付ける規則を定義する選択因子を用いて、各クライアント・サービスを実行するノードを選択し、前記クライアント・サービスを前記選択されたノードに登録し、現在前記クラスタ内にあるノードに、前記特定のクライアント・サービスが前記特定のノードに登録されたことを通知
することを特徴とする前記マルチプロセッサ・クラスタ・システム。
【請求項３０】
請求項２１記載のマルチプロセッサ・クラスタ・システムにおいて、前記登録および起動サービスは、更に、クラスタに加入するノードに、特定のクライアント・サービスが特定のノードに登録されたことを通知することを特徴とする前記マルチプロセッサ・クラスタ・システム。
【請求項３１】
請求項２１記載のマルチプロセッサ・クラスタ・システムにおいて、前記イベント・マネージャは、ノードに登録されたクライアント・サービスを、当該ノードにおいて監視するイベント監視部を含むことを特徴とする前記マルチプロセッサ・クラスタ・システム。
【請求項３２】
相互に接続された多数のノードと、これらの全ノードにアクセス可能に接続された共有資源とを有するマルチプロセッサ・クラスタ・システムにおいて、クラスタ内の前記ノードの特定のものの上でクライアント・サービスを実行し、当該クライアント・サービスに対してクラスタ全体が前記共有資源を含む実質的に単一のノードとして動作するようにする方法であって、
クライアント・サービスに対して前記ノードの内の１つを選択してそのクライアント・サービスを前記選択されたノードに登録し、そのクライアント・サービスを前記選択したノードに登録したことに応答して、前記クライアント・サービスに含まれる動作パラメータにしたがって、前記選択されたノード上で前記クライアント・サービスを起動することを含むことを特徴とする前記方法。
【請求項３３】
請求項３２記載の方法であって、前記ノードが前記クラスタを離脱する場合、前記クライアント・サービスを他のノードに移転することを特徴とする前記方法。
【請求項３４】
請求項３２記載の方法において、前記移転は、前記作用パラメータにしたがって、前記クライアント・サービスを前記他のノード上で再起動することを含むことを特徴とする前記方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、一般的にマルチプロセッサ・システムに関し、更に特定すれば、ディスク共有クラスタ・システム(shared-disk cluster system)に関するものである。更に特定すれば、本発明は、マルチプロセッサ・クラスタ・システムにおいて、ノードの加入(join)および離脱(disjoin)を行うためのフレームワーク(framework)に関するものである。
【０００２】
【従来の技術】
マルチプロセッサ・クラスタ・システムは通常多数のノードを含み、これらは私用通信相互接続部(private communication interconnect)と相互接続されている。また、クラスタ・システムは、仮想ハード・ディスクのような共有クラスタ資源も含み、この共有資源に対するアクセスの調整を支援するオペレーティング・システムを実行する全ノードが、共通クラスタ資源にアクセスすることができる。クラスタ・システムには多くの利点がある。即ち、クラスタ・システムでは、可用性(availability)はクラスタに加わっているアクティブな全ノードに依存しないので、ユーザに高い可用性を提供する。１つ以上のノードが、可用性に必ずしも影響を与えることなく、クラスタを離脱することができる。新たなノードをシステムに追加する際、システムを一旦中断(take down)させて再起動(reboot)させる必要がない。加えて、ノードは、互いに異なるプロセッサ構造を組み込むことができ、このため、システムの拡張性が容易となる。このように、クラスタ・システムは、集合体(aggregate)として高い性能を提供する。
【０００３】
ディスク分散クラスタ・システムは、通常、共有される仮想ディスク上のデータ汚染を回避するために、分散鎖錠システム(distributed lock system)を必要とする、データベース・サービスに用いられてきた。このようなクラスタ・システムにおけるメンバシップ管理は、分散鎖錠システムにクラスタの意識性(awareness)を与える必要があった。しかしながら、このような共有ディスク・クラスタ・システムは、クラスタの意識性がサブシステムの１層にしか拡張しないので、限界があった。個々のオペレーティング・システムは、高位のサブシステムが低位のサブシステム動作に依存しなければいけないように層別された多数のサブシステムを有する。公知のクラスタ・メンバシップ管理技法には、クラスタに加入および離脱するノードのクラスタ遷移を通じて、このような層別されたサブシステムを把握できるものはない。
【０００４】
クライアント・サービス(client service)は、通常、クラスタのノード間で分散されるので、どのノードがどのサービスを実施するのかについて、広範囲の調整が必要となる。これは、ノードがクラスタに加入するノード遷移またはノードがクラスタから離脱するノード遷移の間、特に困難である。これは、殆どのサービスがクラスタの環境を知らないからである。クライアント・サービスは、通常、それら自体にとって、実行すべき最良のノードを決定する。現在サービスを実行中のノードがクラスタを離脱する場合、復元を開始するには、復元機構が必要となろう。この調整のために個々のサービスにそれら自体の機構を実施させると、クラスタ・サービスをクラスタ・システム上で実行可能とするためには、細部にまでおよぶ修正が必要となる。この場合、一貫性のない機構が使用され得るので、クラスタの運営(administration)がより複雑かつ困難となる。
【０００５】
【発明が解決しようとする課題】
本発明は、ノード遷移を通じて関連する全てのサブシステムを把握する(take)ことによって、層別される多数のサブシステムを有するオペレーティング・システムを備えたマルチプロセッサ・クラスタ・システムを容易に使用できるようにするものである。また、本発明は、ユーザ・アプリケーションを含む広範囲の計算処理(computing activities)を含む、クラスタを意識しないクライアント・サービス(non-cluster-aware client service)に、クラスタの意識性をもたらす。これによって、ユーザはクラスタ・システムを一単位として扱うことができるようになり、クラスタ・システムは、特定ノード上でのクライアント・サービスの起動、ノード間のクライアント・サービスの移動、およびクライアント・サービスの終了を含むクラスタ全体におよぶ可用性を、クライアント・サービスに提供する。
【０００６】
【課題を解決するための手段】
本発明は、システムのユーザには実質的に統一されたプロセッサのように現われるクラスタにおいて、マルチプロセッサ・システムの特定のプロセッサ、即ち、ノードを結合する方法および装置を提供する。本発明の一態様によれば、現在前記クラスタ内にあるノード上で実行中の多数のサブシステムに、当該クラスタに対して加入および離脱を行うノードの遷移を通知する。これによって、クラスタ・ノードのサブシステムに、クラスタ内のアクティブなメンバシップの一貫したビュー(view)を与え、ノード遷移を通じて、ノードのサブシステム全てを把握することができる。本発明のこの態様は、レベルにおいて相互依存し、低位サブシステムの動作に高位サブシステムが依存するサブシステムにおいて特に有用である。個々の遷移は、全ノード上の同一レベルのサブシステムに通知される。各ノードの通知を受けたサブシステムがその通知を処理し、その処理が完了したことを承認するまで、通知は他のサブシステム・レベルには移行しない。当該遷移がノードのクラスタへの加入である場合、低位サブシステムから開始し高位サブシステムまで連続的に、サブシステムに通知する。当該遷移がノードのクラスタからの友好的離脱の場合、高位サブシステムから開始し低位サブシステムまで連続的に、サブシステムに通知する。当該遷移が、他のノードによるあるノードの非友好的追い出しである場合、低位サブシステムから開始し上位サブシステムまで連続的に、サブシステムに通知する。
【０００７】
本発明の別の態様によれば、登録および起動機能(registration and launch function)を提供する。この場合、ユーザ・アプリケーションを含むクライアント・サービスは、当該クライアント・サービスにはクラスタが実質的に単一装置(uniform unit)と見なせるように、クラスタ内の特定ノード上で開始される。各クライアント・サービスにノードを選択し、当該クライアント・サービスをそのノードに登録する。現在クラスタにあるノードには、特定のサービスが特定のノードに登録されたことが通知される。このように、サービスが登録されているノードがクラスタを離脱する場合、クライアント・サービスは、他のノードに移転することができる。クライアント・サービスは、このサービスをノードに登録することに応答して、サービスに含まれる作用パラメータにしたがって、ノード上で起動することができる。これによって、クライアント・サービスは、移転される毎に明示的に開始する必要がなくなるので、クライアント・サービスにクラスタ全体におよぶ可用性が与えられる。クライアント・サービスは、親サービスと１つ以上の子サービスとに類別すれば有利である。類別されたクライアント・サービスは同一ノードに登録され、群内の全ての起動動作(launching activity)に、親サービスに含まれる作用パラメータを利用する。各クライアント・サービスに対するノードの選択は、当該クライアント・サービスのための選択因子のデータベースを設け、クラスタ内のノードの可用性に関する情報に、選択因子を適用する。選択因子は、ノードをクライアント・サービスに関係付ける規則を確定する。
【０００８】
このような登録および起動機能は、好ましくは、クライアント・メンバシップ・マネージャからのノード遷移の通知を受けるサブシステムである、イベント・マネージャの構成物である。イベント・マネージャは、イベント監視部を用いて、特定ノードに登録されているクライアント・サービスを監視し、ノード遷移のようなイベントの発生に応答して実行される作用項目を与える。イベント監視部は、クライアント・サービスの登録に応答してイネーブルし、当該クライアント・サービスの登録抹消に応答してディゼーブルすればよい。
【０００９】
本発明のこれらおよびその他の目的、利点ならびに特徴は、以下の明細書を図面に関連付けながら検討することにより、明確となろう。
【００１０】
【発明の実施の形態】
ハードウエア
これより図面およびその中に描かれている例示的実施例を具体的に参照していく。マルチプロセッサ・クラスタ・システム２５は、多数のノード２６と、物理ディスク２８のような共有クラスタ資源とを含む。物理ディスク２８は、多数の物理ディスク駆動装置（図１）で構成することも可能である。各ノード２６は、プロセッサ（ＣＰＵ）、物理メモリ、キャッシュ、共有および個別バス・インターフェース、および任意の専用素子を含む。各ノードは、マサチューセッツ州ウエストボロのData General Corporationから販売されているDG/UX5.4のようなＵＮＩＸに基づくオペレーティング・システムを実行する。前記DG/UX5.4は、このようなオペレーティング・システムに対応するものであれば、あらゆるハードウエア構成上で実行可能である。このようなハードウエア構成の一例は、Data Generalによって販売されている、AViiON（登録商標）ファミリーである。
【００１１】
クラスタ・システム２５は、更に、ノード２６が他の全てのノードに直接対話できるようにする、専用の共有クラスタ通信媒体である相互接続部３６と、ディスク２８のような、共有バスに物理的に接続されている全ての装置を、全てのノードに共有可能にする共有クラスタＩ／Ｏバス３２とを含む。図示した実施例では、共有バス３２は、ＳＣＳＩ標準バスである。
【００１２】
ソフトウエア
クラスタ・システム２５は、専用の共有クラスタ仮想ディスクを占める、単一のメンバシップ・データベース３４を含む。この専用の共有クラスタ仮想ディスクは、クラスタ認識ブートストラップ(cluster-cognizant bootstrap)３８と共に、物理ディスク２８上に常駐する。メンバシップ・データベース３４は、ノード２６の起動(boot)、処理停止(shutdown)、またはパニック(panic)に必要な、永続的ノード構成情報４０を管理する。このような永続的情報は、システムを構成するノードの識別番号と、ノード識別番号によるインデックスを付与された、各ノードについての構成情報とを含む。更に、メンバシップ・データベース３４は、ノード状態についての遷移性情報(transient information)を収容する、アクティブ・メンバシップ状態データベース４２も含む。この遷移性状態は、ノードがクラスタに友好的に加入する場合、友好的に離脱する場合、または非友好的に追い出される場合に動的に変化する。１つのノードは、以下に示す状態のいずれかを有することができる。
【００１３】
インアクティブ(inactive)−ノードが構成されていないか、またはクラスタのアクティブな構成物ではない。
【００１４】
加入中(joining)−ノードがクラスタに加入する過程にある。これが意味するのは、当該ノードが他のノードに、それがクラスタに友好的に加入する意図を通知したが、クラスタ内のノードの登録されているサブシステム全てが、この新たなノードを友好的に含む遷移を完了していないということである。
【００１５】
加入(joined)−ノードが完全にクラスタに加入し、クラスタ内のノードの登録されているサブシステム全てが、新たなノードを含む遷移を完了している。
【００１６】
離脱中(leaving)−ノードがクラスタを離脱する過程にある。これが意味するのは、当該ノードが他のノードに、それがクラスタから友好的に離脱する意図を通知したが、クラスタ内のノードの登録されているサブシステム全てが、この新たなノードを友好的に除外する遷移を完了していないということである。
【００１７】
強制離脱(forced leaving)−他のノードがこのノードをクラスタ外に追い出す過程にある。他のノードがあるノードを追い出し得るのは、他のノードとの通信ができない等のように、当該ノードが適正に機能しない場合である。他のノードが強制離脱処理を完了した後、他のノードはこのノードにインアクティブという印を付ける。強制離脱させられたノードは、他のノードがそれを追い出したことを知った後、パニックに陥る。ノードがパニックに陥ると、共有クラスタ資源の転化を回避するために、それ以上の処理を中止する。
【００１８】
Ａ．メンバシップ・マネージャ
クラスタ・システム２５は、遷移通知フレームワーク４４を含む、メンバシップ・マネージャ・フレームワークを含む。遷移通知フレームワーク４４は、クラスタ遷移の通知を受信しなくてはならない、全てのカーネル・レベルおよびユーザ・レベルのサブシステムに、通知を与える（図２ないし図１７）。遷移通知フレームワーク４４の目的は、クラスタ認識サブシステム、即ち、ノード間でクラスタ遷移情報を処理するための一貫した技法を提供することである。クラスタ認識サブシステムは、ノードのクラスタ・メンバシップ・マネージャ・サブシステム４６に登録されているサブシステムである。図示した実施例では、各ノード２６は、クラスタ・メンバシップ・マネージャ・サブシステム４６を含む、４つのカーネル・レベルのサブシステムを含み、遷移通知フレームワーク４４、分散鎖錠マネージャ（ＤＬＭ）サブシステム４８、仮想ディスク・マネージャ（ＶＤＭ）サブシステム５０、および共有ファイル・システム（ＦＳＦＳ）サブシステム５２を、集合的に備えている。加えて、各ノード２６は、少なくとも１つのユーザ・レベルのサブシステム、即ち、イベント・マネージャ・サブシステム５４を含む。このようなサブシステム４６〜５４は、レベルにおいて互いに独立している。図示した実施例では、メンバシップ・マネージャ４６は最下位のサブシステムであり、イベント・マネージャ５４は最上位のサブシステムである。しかしながら、これよりも高位のサブシステムを他に設けることも可能である。サブシステムには全体的な遷移順位が与えられ、レベルが低いサブシステム程受ける値は小さく、レベルが高いサブシステム程受ける値は大きい。
【００１９】
遷移通知フレームワーク４４は次のように動作する。ノードがクラスタに加入する前に、当該ノードの対象サブシステムは、クラスタ遷移の通知を受ける意志を登録する。登録されたサブシステムは、当該ノードのメンバシップ・マネージャ・サブシステム４６からの遷移通知を待つことを妨げる、制御のスレッドも供給しなければならない。以下でより詳しく示すが、ノードの友好的加入と強制離脱の間、全ノードのメンバシップ・マネージャ・サブシステム４６は、全体的な遷移順序付け方式に関してボトム・アップ式(bottom-up fashion)に、ノードの登録されたサブシステムに通知するように調整を行う。このようにして、メンバシップ・マネージャ・サブシステムは、最初に、最も低い順位を有するノードのサブシステム全てに通知を行い、続いて最高の順位に達するまで、次に高い順位のノードのサブシステムに通知を行う。逆に、ノードの友好的離脱の間、全てのノードのメンバシップ・マネージャ・サブシステム４６は、トップ・ダウン式状(top-down fashion)に、ノードの登録されたサブシステムに通知する。即ち、最初に、最も高い順位を有するノードのサブシステム全てに通知を行い、続いて最低の順位に達するまで、次に低い順位のノードのサブシステムに通知を行う。この順序付けは、高位サブシステムの低位サブシステムに対する依存性を満足するようになっている。即ち、低位サブシステムが最初にノードの加入遷移を処理するので、高位サブシステムが依存するサブシステム、即ち、低位サブシステムがその加入を知っており、その処理を完了したことを高位サブシステムに保証することができる。逆に、離脱遷移の間、離脱するノードにおいて下位サブシステムが動作状態を維持するように、高位サブシステムが最初に友好的離脱を処理しなければならない。非友好的離脱は、低位から上位に処理され、次に最も高いレベルにおいて復元を試みる前に、全エラー状態が上方向に伝搬される。
【００２０】
各ノードのメンバシップ・マネージャ・サブシステムは、各ノードの現インライン・サブシステム(currently-in-line subsystem)がその遷移のための処理完了を承認するまで、次のインライン・サブシステム(next-in-line subsystem)への通知を行わない。しかしながら、各ノードのメンバシップ・マネージャ・サブシステムは、同時に異なるノードの多数の遷移を処理することを、登録されているサブシステムに通知することができる。これらの遷移は各々異なるタイプのものであってもよい。これによって、クラスタ全体の給電を止めた停電の後に多くのノードが起動する場合のように、多くのノードが同時に遷移を行うような状況における処理能力(performance)を改善することができる。しかしながら、各ノードのメンバシップ・マネージャは、特定の遷移対象ノードについて、順序を乱してサブシステムに通知することはない。その結果、異なるノードの多数の遷移は、同時に異なるサブシステム・レベルで処理可能であるが、クラスタ・メンバシップ・マネージャ・フレームワークは、各遷移対象ノードに対して、適正なサブシステムの順序を確保する。
【００２１】
遷移通知フレームワーク４４を利用して、友好的加入、友好的離脱、および非友好的強制離脱に関係するクラスタ・サブシステムの例について、図２ないし図１７を参照する。これらの図は、潜在的に２ノード・クラスタを有するクラスタ・システムを示す。図３ないし図１７に示す例は、３つ以上のノードに一般化し、各ノード遷移は、各サブシステムによって、一度に１回ずつ、全ノードにわって連続的に行うようにすることもできる。各メンバシップ・マネージャは、現レベルの全ノードが新たなノードに対するそれらの遷移処理の完了を承認するまで、同じノード遷移を次に最も高いサブシステムに伝搬しない。
【００２２】
図３に示す状態において、クラスタはアクティブなメンバを全く含まない。システム管理部(system administrator)は、ノードＮ０に給電し、その起動(boot)を開始する。ノードＮ１への給電は停止したままである。最初のアクティブ・メンバとしてクラスタに友好的に加入するために、ノードＮ０はクラスタ・メンバシップ・データベース３４を開き、その構成情報を検索する。ノードＮ０は、そのカーネル・サブシステム４６〜５２を初期化する。カーネル・サブシステム４６〜５２は各々、遷移通知のためにそれら自体を登録する（図４）。サブシステムは、この時点ではクラスタの遷移が発生していないので、ブロックするカーネルの呼び出しを行うスレッド(thread)を生成する。ノードＮ０のＩＮＩＴサブシステム（図示せず）は、現在登録されている最上位のサブシステムによって、ノードＮ０の友好的加入を開始する。ノードＮ０のメンバシップ・マネージャ・サブシステム４６はクラスタを形成し、Ｎ０の現状態を加入中として印す。ノードＮ０のメンバシップ・マネージャ４６は、そのＤＬＭサブシステム４８に、ノードＮ０がクラスタに加入中である（図５）ことを通知する。ノードＮ０のＤＬＭサブシステム４８のスレッドは呼び起こされ(awake)、ノードＮ０の新たな加入状態を知り、加入処理を別のＤＬＭスレッドに渡し、次いでその加入を完了する。ノードＮ０のＬＤＭサブシステムはノードＮ０の状態を加入済として印し、ノードＮ０のメンバシップ・マネージャ４６に、ＤＬＭはノードＮ０に対するそれ自体の加入処理を完了したことを通知する。ノードＮ０のＶＤＭサブシステム５０およびＳＦＳサブシステム５２について、同一処理を繰り返す（図６）。
【００２３】
カーネル・レベルにおいてクラスタに加入した後、ノードＮ０はユーザ空間に移る（図７ないし図９）。ノードＮ０のＩＮＩＴサブシステム（図示せず）は、イベント・マネージャ・サブシステム５４を生成する。ノードＮ０のイベント・マネージャ５４は未だＮ０の友好的加入を処理していないので、直ちに戻るスレッドを生成する。ノードＮ０の友好的加入を処理した後、ノードＮ０のイベント・マネージャ５４は、ノードＮ０の状態を加入済みとして印し、ノードＮ０のメンバシップ・マネージャ４６に、ノードＮ０の友好的加入を処理したことを通知する。
【００２４】
図１０において、管理部はノードＮ１に給電し、これを起動する。これによって、ノードＮ０およびＮ１は、ノードＮ１の友好的加入を実行する。ノードＮ１はメンバシップ・データベース３４を開き、その構成情報を検索し、そのカーネル・サブシステム４６〜５２を初期化する。カーネル・サブシステムは遷移通知のために登録を行う。加入するノードのメンバシップ・マネージャは、クラスタに加入するために、クラスタ・マスタ・ノードと交渉しなければならない。クラスタに多数のノードがある場合、デッカーのアルゴリズム(Decker's algorithm)を用いて、１つのノードをマスタ・ノードとする。デッカーのアルゴリズムは当技術では公知である。マスタ・ノードは、メンバシップ・データベース３４の特定領域に、その鼓動(heartbeat)を書き込む。加入するノードは、このような領域の鼓動を検査して、マスタ・ノードを識別する。ノードＮ１のメンバシップ・マネージャ・サブシステム４６は、ノードＮ０のメンバシップ・マネージャと交渉し、クラスタに加入する。この場合、ノードＮ０は当該クラスタ内の唯一のノードであるので、マスタ・ノードでなければならない。ノードＮ０およびＮ１のメンバシップ・マネージャは、ノードＮ１の状態を、クラスタに加入中として印す。ノードＮ０およびＮ１のメンバシップ・マネージャは、ノードＮ１がクラスタに加入したことを、それらの各ＤＬＭサブシステム４８に通知する。双方のＤＬＭサブシステムは、それらの呼び出しによって起動し、ノードＮ１の友好的加入の処理を開始する。双方のＤＬＭサブシステムがノードＮ１の友好的加入の処理を調整した後、これらＤＬＭサブシステムは、ノードＮ１の状態を、加入済みとして印し、メンバシップ・マネージャに知らせる。双方からのＤＬＭの承認を受けた後、ノードＮ０およびＮ１のメンバシップ・マネージャは、ノードＮ１がクラスタに加入中であることを、各ＶＤＭサブシステム５０に知らせる（図１１）。双方のＶＤＭサブシステムがノードＮ１の加入を処理した後、双方のサブシステムはノードＮ１の状態を加入済みと印し、これをそれぞれのメンバシップ・マネージャに知らせる。
【００２５】
カーネル・レベルにおいてクラスタに加入した後、ノードＮ１はユーザ空間に移行し、そのＩＮＩＴサブシステム（図示せず）がイベント・マネージャ５４を生成する。ノードＮ１のイベント・マネージャは、それ自体をメンバシップ・マネージャに登録する。ノードＮ１のイベント・マネージャは、カーネルの呼び出しを行うスレッドを生成する。ノードＮ１のイベント・マネージャはノードＮ１の友好的加入を処理しなければならないので、これは直ちに戻される。ノードＮ０のイベント・マネージャが起動して、ノードＮ１の友好的加入の処理を行う。ノードＮ１の友好的加入の処理を調整した後、双方のイベント・マネージャ５４は、ノードＮ１の状態を加入済みとして印し、この友好的加入をそれぞれのメンバシップ・マネージャに知らせる。図１２に示すように、ノードＮ１の加入が行われる。
【００２６】
ノードが友好的離脱を開始できるのは、当該ノードが未だ加入中状態にある間である。しかしながら、加入中のサブシステムは、加入中の状態を直接離脱中またはインアクティブな状態に変換しない。加入中のサブシステムは、加入遷移を完了し知らせなければならない。メンバシップ・マネージャは、登録されたサブシステム・レベルへの通知の間に、加入中状態を離脱中状態に転換するのみである。
【００２７】
ノードの停止(shutdown)の間に発生するもののような、遷移通知フレームワーク４４による、ノードの友好的離脱の処理について、図１３および図１４を参照しながら例示する。ノードＮ０は、友好的離脱を開始する適切な呼び出しを行うことによって、その停止を開始する。ノードＮ０およびＮ１のメンバシップ・マネージャ・サブシステムは、ノードＮ０を離脱中として印す。ノードＮ０およびＮ１のメンバシップ・マネージャは、ノードＮ０の遷移によって、双方のイベント・マネージャ５４を起動する。双方のイベント・マネージャは、ノードＮ０の状態が離脱中であることに気付き、ノードＮ０の友好的離脱の処理をそれぞれが調整しながら開始する。以下で更に詳細に述べるが、双方のイベント・マネージャによるノードＮ０の友好的離脱の処理は、かなりの量のアプリケーション・レベルでの停止を伴う場合があり、その後に双方のイベント・マネージャはノードＮ０をインアクティブとして印し、それらの各メンバシップ・マネージャに通知する。ノードＮ０のメンバシップ・マネージャは、遷移通知のために、ノードＮ０のイベント・マネージャの登録を自動的に抹消し、これによって、ノードＮ０のイベント・マネージャはこれ以上の通知を受け取らなくなる。次に、ノードＮ０およびＮ１のメンバシップ・マネージャは、双方のノードのＳＦＳサブシステム５２、次に双方のＶＤＭサブシステム５０、更にＤＬＭサブシステム４８で、同じ繰り返し処理を実行する。最後に、双方のノードのメンバシップ・マネージャは、ノードＮ０をインアクティブとして印す。これはノードＮ０の友好的離脱の終了でもある。ノードＮ０はカーネル・レベルでの停止処理を実行し、ブート・コマンド・ライン(boot command line)に戻る。
【００２８】
ここで注記すべきは、他のノードがノードの友好的離脱を処理している間、このノードは友好的加入の開始を許されていないということである。実際、この状況は、離脱中のノードが異常な死を遂げ、他のノードが離脱中のノードの死を通知する機会を有する前にこのノードが再起動する場合に発生し得る。離脱中のノードが実際に死んだことを他のノードが通知すると直ちに、他のノードは死んだノードをクラスタから追い出して、それらの友好的離脱処理を取り止める。その後、他のノードは新たなノードの友好的加入要求を受け入れる。
【００２９】
非友好的強制離脱は異常な状況である。例えば、あるノードがもはや他のクラスタ・ノードと通信することができなくなった場合である。一旦追い出されたノードが、他のノードがそのノードをクラスタの外に追い出したことを知ると、追い出されたノードはパニックに陥る。遷移通知フレームワーク４４は、追い出されたノードがどの共有クラスタ資源をも転化(corrupt)させないことを保証する。登録されているサブシステムが、追い出されたノードの友好的加入または離脱を処理している最中、各ノードのメンバシップ・マネージャは、処理中のサブシステムに、当該ノードの友好的処理を取り止め、処理の復元を開始するように、再度通知することもできる。
【００３０】
強制離脱の一例を図１５ないし図１７に示す。これは、ノードＮ１のクラスタへの加入、およびノードＮ０の起動およびクラスタの友好的加入から開始する。一例として、ノードＮ０およびＮ１のメンバシップ・マネージャがＶＤＭサブシステム５０を介してノードＮ０の友好的加入を処理したが、ノードＮ０上での相互接続不良のためにノードＮ０およびＮ１のＳＦＳサブシステムが通信することができず、ＳＦＳサブシステム５２からのノードＮ０の友好的加入処理完了の承認を受け取っていない場合、ノードＮ０の友好的加入は未決状態にあるとして記される（図１５）。ノードＮ１のメンバシップ・マネージャは、ノードＮ１がもはやノードＮ０と通信できないことを知る。ノードＮ１は、ノードＮ０の状態を強制離脱として印すことによって、ノードＮ０をクラスタから追い出す。ノードＮ０のメンバシップ・マネージャは、ノードＮ１がノードＮ０を追い出したことを知り、直ちにパニックに陥る（図１６）。ノードＮ１のメンバシップ・マネージャは、最下位のサブシステムから始めて、登録されている最高位のサブシステムにまで移行することによって、強制離脱処理を開始する。ノードＮ１のＤＬＭサブシステム４８は、ノードＮ０を強制離脱中として印し、加入済みからの急激な遷移を通知し、図１６に示すように復元処理を開始する。ノードＮ１のＤＬＭサブシステムが、ノードＮ０の状態をインアクティブと印すことによって、ノードＮ０の強制離脱に対する復元処理完了を承認した後、ノードＮ１のメンバシップ・マネージャは、ＶＤＭサブシステム５０に関して、同一の繰り返し処理を実行する。
【００３１】
ノードＮ０は、ノードＮ１のサブシステム全てがノードＮ０の強制離脱の処理を完了してしまうまでは、クラスタへの友好的再加入が許されない。ノードＮ１のメンバシップ・マネージャが最終的にノードＮ１のＳＦＳサブシステム５２に引き継いだとき、このサブシステムはノードＮ０の元来の友好的加入処理を取り止め、復元処理を実行し、次いで、ノードＮ０の状態をインアクティブとして印すことによって、強制離脱処理の完了を承認する。ノードＮ１のメンバシップ・マネージャは、通常、登録されている最上位のサブシステム、即ち、イベント・マネージャ５４を介して強制離脱の通知を繰り返す。しかしながら、ＳＦＳサブシステム５２が、ノードＮ１の友好的加入試行を通知される最上位サブシステムであったので、強制離脱処理は、ＳＦＳサブシステムのみを介して進行する。適切な最上位サブシステム、この場合ＳＦＳサブシステムを介して強制離脱通知を処理した後、ノードＮ１のメンバシップ・マネージャは、ノードＮ０の状態をインアクティブとして印す（図１７）。
【００３２】
表１は、所与の遷移ノードについて、メンバシップ・マネージャが登録済みサブシステムに送る通知の形式、および登録済みサブシステムがその遷移処理を完了した後にメンバシップ・マネージャが当該登録済みサブシステムから受け取ることが予想される対応する承認を示す。また、表１は、登録済サブシステムが遷移対象ノードに対する元の通知を未だ処理している間に、メンバシップ・マネージャが登録済サブシステムに送る可能性がある再通知も纏めてある。
【００３３】
登録済みサブシステムの中には、特定のノード遷移の１つに対して、２段階以上の遂行動作(two-or-more-phase commitment operation)を実行する必要があるものもある。このような多重段階遂行を可能にするために、メンバシップ・マネージャ４６はバリア同期(barrier synchronization)を与える。各登録済みサブシステムは、当該サブシステムが各ノード遷移形式毎に必要とするバリア数を指定する。次に、メンバシップ・マネージャは、サブシステム・レベルとバリア同期させた通知を供給する。所与のサブシステム・レベルにおける全ノードは、メンバシップ・マネージャが次の順番のサブシステム(next-in-order subsystem)に移行する前に、特定のバリアに対するその遷移処理の完了を承認しなければならない。例えば、ＤＬＭサブシステムが、加入遷移の間に、２つの「加入」バリアを要求した場合、全ＤＬＭサブシステムは、それらがバリア１について通知を受ける前に、加入バリア０を承認しなければならない。これらのサブシステムがバリア１を承認した後、加入遷移はＶＤＭサブシステムに伝搬する。ＶＤＭサブシステムは異なる数のバリアを有している場合もある。また、特定のレベルにおける全サブシステムは、各遷移形式について、同数のバリアを登録しなければならない。
【００３４】
遷移通知ネットワーク４４の状態図を図２に示し、個々の登録済みサブシステムがノード遷移に対して受け取る可能性がある通知の形式を例示する。図２において観察されようが、各遷移形式について、遷移は多数のバリアを介して進められる場合がある。明確化のために、強制離脱には１つのバリアのみを示す。しかしながら、多数のバリアも許されている。破線は遷移通知を表わす。実線は、単一ノードにおけるあるいは多数のノードにわたる、個々のサブシステムからの承認を表わす。
【００３５】
【表１】
0003953549.tif 000002
【００３６】
Ｂ．イベント・マネージャ
イベント・マネージャ・サブシステム５４は、クライアント・サービスに対するクラスタ全体におよぶ可用性を与える、ユーザ空間のサブシステムである。この後者の機能は、イベント・マネージャ・サブシステム５４（図２３）の構成物である登録および起動サービス(registration and launch service)５６（図１８ないし図２３）によって実行される。イベント・マネージャ・サブシステム５４は、特定の状態を監視する多数の監視部６０ａ〜６０ｇを有するイベント・マネージャ・デーモン(event manager daemon)５８を含む。ある監視部が問題を検出した場合、イベント・マネージャ・サブシステム５４は、作用機能(action function)６２によって、この問題を解決する。登録および起動サービス５６は、イベント・マネージャ・デーモンの監視部と看做すことができるが、有用な付加機能の実行も行う。これについては、以下でより詳細に説明する。
【００３７】
クライアント・サービスは、ユーザ・アプリケーションを含むいずれかの計算処理(computing activity)であり、クラスタ内の１つのノードまたは２つ以上のノード上で実行される。ここで問題となるのは、どのノードまたはノード群が最初に各クライアント・サービスを供給するかを決定することである。加えて、故障という状況の間、どのノードがどのサービスを実施するかを調整する必要もある。個々のクライアント・サービスがそれら自体の機構を実施して実行すべき最良の位置を決定し、現在サービスを提供しているノードがクラスタを離脱する場合に復元を開始するとすると、クラスタの運用管理に大きな負担が強いられることになる。登録および起動サービス５６は、クライアント・サービスを実行するノードを選択し、当該クライアント・サービスをこのノードに登録し、現在クラスタ内にあるノードに、特定のクライアント・サービスがそのノードに登録されることを通知することによって、非クラスタ意識アプリケーション(non-cluster-aware applications)にクラスタの意識性を与える。加えて、登録および起動サービス５６は任意の起動または実行能力を備え、当該サービスが特定のノードに登録されるときに起動する。更に、起動能力(launching capability)は、あるサービスを１つのノードから他のノードに制御しながら移転するために用いることもできる。起動能力は、「作用機能」とも呼ばれ、クライアント・サービスの開始、移動および終了能力を備える、クラスタ全体の可用性を高めるものである。このようなクライアント・サービスの移転は、例えば、クラスタに加入するまたはクラスタから離脱するノードの結果発生する。登録および起動サービスを主に使用するサービスの例には、例えば、印刷サブシステム、浮動インターネット・プロトコル(IP:internet protocol)、ネットワーク形成サービス、およびライセンス・サーバ(license server)が含まれるが、他のサービスもこの登録および起動サービスを利用できる利点がある。
【００３８】
１．登録
登録は、あるクラスタにおける１つのノードまたは２つ以上のノードが、既に定義されているクライアント・サービスに対する責任を要求する、または割り当てられる処理である。これは、クラスタ全体において原子単位(atomic basis)で行われる。登録は、登録済みノードが指定されたクライアント・サービスの義務を遂行する責任の要求を指示する。登録または登録抹消の結果として、「作用機能」として知られる、随意選択のサービス開始、通知、および停止コマンドが呼び出される。このように、登録は、クライアント・サービスを開始即ち起動し、ユーザ・サービスにクラスタの意識性を与える。クラスタの意識性は、登録完了時における、当該クラスタ内の他のノード、および後にクラスタに加入するノードへ登録を通知することの結果である。
【００３９】
２．選択
登録動作の一部として、どのノードを特定の責任に割り当てるかの選択について、１組の選択パラメータ、即ち、データベース項目６４による指示を受ける。これらの選択パラメータは、いつ、どこで、どのような条件の下でサービスを登録すべきかを指定する、１組のデータベース項目を含むことができる。しかしながら、選択関数の中には、特定のノードの最新処理実績統計(recent performance statistics)を含む、他の基準を含ませることもできる。管理部が供給する優先因子(priority factor)は、以下のようにして選択することができる。
【００４０】
許可ノード(Allowable_Nodes)−登録が許されているクラスタからのノード。全てのノードは、給電される(powered up)必要がなくても、クラスタの潜在的メンバでなければならない。単一のワイルドカード文字(wildcard character)を用いて、クラスタの潜在的ノードを全て指定することもできる。
【００４１】
ノード優先度(Node Preferences)−ノード優先度は、全てのノードが全てのクライアント・サービスを等しく支援するわけではないという事実から生じたものである。ノード優先度は、順序なしリストまたは順序付きリストとして、指定することができる。順序なしメンバ間での選択は、クラスタの最新の性能特性による影響を受ける。順序付きリストの処理は、最上位メンバから行われる。
【００４２】
無許可ノード(Disallowable_Nodes)−登録が許されていないクラスタからのノード。クライアント・サービスの無許可ノードにノードを追加しても、サービスの移転は自動的に開始されない。
【００４３】
自動登録(Auto_Register)−これは、クラスタに最初に給電するときに用いられ、各ユーザ・クライアント・サービスを登録し開始する必要が潜在的にある。自動レジスタ・ファイルは、どのような条件の下で、サービスを登録すべきかを管理部が定義できるようにする。
【００４４】
配置方針(Placement_Policy)−これは、どのような形式の登録原理(registering philosophy）を採用するのかを示す。即ち、クライアント・サービスを正確に１つのノード上に登録するのか、あるいは各許可ノード上に登録し開始するのかを示す。
【００４５】
図２０に示すように、クライアント・サービスは、自動開始６６または外部開始６８のいずれかから開始することができる。意志決定ノード(decision-making node)の登録および起動サービスは、先に述べた選択パラメータを利用して、最良のノードを６４で選択する。意志決定ノードは、クラスタ内のどのノードでもよい。これは、ファイル鎖錠(file lock)の所有によって決定され、クラスタ全体の信号(semaphore)を用いて処理される。成熟度(maturity)がクライアント・サービスに適用される場合、登録および起動サービスは状態７０に移り、成熟度を待つ。成熟度とは、クラスタの成熟度のことである。クラスタが所与のクライアント・サービスに関して成熟しているのは、許可ノードのリストから少なくとも１つのノードが活動中(up)であり、かつ（ａ）主要ノードが入手可能であり、（ｂ）十分なノードが活動中であり、または（ｃ）十分な時間が過ぎている場合である。一旦クラスタが成熟したなら（７０）、または成熟度が適用されない場合、登録および起動サービスは、選択したノードにサービスを開始するように通知し、他のノードにはクライアント・サービスが特定のノードに割り当てられたことを通知する（７２）。次に、このクライアント・サービスを開始即ち起動する（７４）。各登録および起動クライアント・サービスは、以下に述べること（類別）を除いて、独立した選択因子(choosing factor)を有する。
【００４６】
３．類別
登録および起動サービス５６は、類別７６として知られている連合(association)に、クライアント・サービスを互いに関連付けることを可能にする（図１８および図１９）。類別機構は、親クライアント・サービス７８と１つ以上の子クライアント・サービス８０との間の関係である。この類別構成の目的は、特定のサービスを一緒に配置しなければならない連合を、管理部が指定できるようにすることである。子は、親を配置した所であればどこにでも配置される。子サービスは選択因子を全く有さず、親の選択因子のみが用いられる。図１９に示すように、類別７６’は、他のサービス８０’の子である子サービス８０を含んでもよく、一方サービス８０’は親サービス７８の子であり、子（８０および８０’）は全て親サービス７８の配置下にある。
【００４７】
各子８０の登録は、その親が首尾よく登録され、その開始コマンド(start_command)があれば、これを首尾よく完了するまで、処理待ちとなる。親の登録が完了した後、各子を処理する。同様に、親の登録抹消(de-register)は、子の登録抹消も意味する。先ず適切に呼び出された停止コマンド(stop_command)によって、子の登録を抹消する。類別７６に移ると、類別された子８０は、常に最初に停止され最後に開始される。
【００４８】
４．作用機能
登録および起動サービス５６は、登録トランザクションの結果として行われる種々の作用に対応する。作用は、登録および起動サービスの「起動」の一面である。類別７６および選択パラメータと組み合わせると、作用は、クラスタ全体の可用性に対して、多くのクライアント・サービスが登録および起動サービスに全体的に依存するようにする。開始、移動および終了は全て、登録および起動サービス５６を用いて、実行することができる。
【００４９】
図示した実施例における登録および起動サービス５６は、以下にあげる４つの作用機能を含む。
【００５０】
開始コマンド(Start_Command)−クライアント・サービスの登録成功時に、データベースをチェックして、このようなコマンドがサービスと関連付けられているか否か判定する。このようなコマンドが存在する場合、登録されているノード上でクライアント・サービスを実行する。首尾よく開始が完了するまで、登録は完了しない。開始動作ができない場合、許可ノード・リスト内の他のノード上でクライアント・サービスの開始を試みる。
【００５１】
停止コマンド(Stop_Command)−クライアント・サービスを終了しようとするときに、データベースをチェックして、このコマンドの存在を判定する。停止コマンドが終了するまで登録抹消は完了しない。
【００５２】
通知コマンド(Notify_Command)−このコマンドは、クライアント・サービスが特定のノードに割り当てられたことを他のノードに知らせる機構を提供する。クライアント・サービスが首尾よく登録されたとき、データベースをチェックして、このコマンドが当該サービスと関連付けられているか否かを判定する。関連付けられている場合、登録済みノードを除いて、許可ノード・リスト内の全ノード上で、これを実行する。サービスを登録した後に許可ノード・リスト内のあるノードがクラスタに加入し、そのサービスが通知コマンドを有する場合、このコマンドを新たなノード上で開始する。これは、クラスタを離脱しその後再度加入したノードを含む。開始コマンドがある場合、首尾よく開始するまで、通知は保留となる。
【００５３】
復元コマンド(Recovery_Command)−これは、ノードが非友好的にクラスタから離脱する時に用いられる。追い出されたノード上に登録されている各サービスについて、データベースをチェックし、当該サービスと関連付けられた復元コマンドがあるか否か判定する。あるのであれば、実行する。復元動作のためのノードは、選択パラメータ６４を用いて決定する。復元が完了したとき、サービスは登録抹消される。通常、その後、サービスは、存続するノード(surviving nodes)の内の１つに登録され、開始される。
【００５４】
作用機能に密接に関係する概念は、移転の概念である。あるサービスの移転は、２つの作用機能の組み合わせによって達成する。先ず、サービスを所在を突き止め、登録を抹消する。第２に、それを登録し開始する。サービスの移転は、種々の状況下において、非常に役に立つことがある。ある状況では、管理部がサービスの移動を望む場合もある。他の状況では、移転機能を用いて、友好的に停止されたあるノードのために全サービスを移転することもある。また、他の状況では、サービスが、その性質上、頻繁に移動することもある。サービスの移動には影響がないので、サービスが好適なノード以外のノードに配置されている場合に、好適なノードがクラスタに加入したときに、このようなサービスを自動的に移転するようにしてもよい。
【００５５】
あるクライアント・サービスを１つのノードから他のノードへ移転する最中にあるとき、移転対象のノードによって「移転意向」フラグをセットする。登録および起動サービス５６の遷移についての移転意向フラグの効果は、図２１を参照することによって、理解することができよう。登録および起動サービス５６は、開始状態８２、登録済み状態８４、停止状態８６、登録抹消状態８８、および復元状態９０を含む。停止、開始、および復元状態の各々は、それらの各コマンドが存在しない場合、飛ばされることになる。開始状態８２は、サービスが開始過程にあることを示す。開始が成功であれば、サービスは登録済み状態８４に進む。登録済み状態は８４は、サービスがあるノード上で動作状態となることを要求していることを示す。動作状態のノードの友好的離脱における他のノードへの移転の一部として、移転意向フラグがセットされた場合、登録済みサービスは停止状態８６に移転する。登録済みサービスは、外部登録抹消または移転動作の一部として、停止状態８６に移転する。停止コマンドの完了時に、サービスは停止状態８６から登録抹消状態８８に遷移し、当該サービスが現在登録されておらず、現在進行中のノード遷移がないことを示す。移転されるサービスは、通常、登録抹消状態８８から開始状態８２に直接移行する。復元状態９０が発生するのは、サービスが登録済み状態８４または停止状態８６にあった間に、あるノードが非友好的にクラスタから離脱する場合のみである。種々の中間状態を示す図２２に、より詳細な状態遷移図を示す。
【００５６】
表２は、ノードＮ０、Ｎ１、およびＮ２を有する３ノード・クラスタにおける、状態遷移の一例を示す。この例は、許可ノードがノードＮ０およびノードＮ１であり、成熟度カウント(maturity_count)が２に等しく、成熟時間(maturity_time)が５に等しい場合に基づくものである。この例の開始時では、全てのノードはダウン状態にある。時点ｔ1において、ノードＮ２が起動するため、このノードのステータスはアップ状態に変化する。ノードＮ２は許可ノード・リストにはないので、何の変化も起こらない。時点ｔ2において、サービスはクラスタの成熟度を待っており、ノードＮ０が起動する。時点ｔ3において、成熟度時間が経過し、サービス開始コマンドがノードＮ０上で実行される。開始は時点ｔ4において完了し、ノードＮ０上にサービスが登録される。時点ｔ5において、ノードＮ１が起動する。このサービスは既に登録済みなので、何の作用も発生しない。しかしながら、「通知作用」を定義すると、それはこの時点でノードＮ１上で実行されることになる。時点ｔ6において、ノードＮ２は友好的にクラスタを離脱するが、これもサービスには影響を与えない。時点ｔ7において、ノードＮ０は友好的離脱を開始する。この結果、サービスは停止状態となり、移転意向フラグがセットされる。停止は時点ｔ8において完了する。サービスは、時点ｔ9において、開始状態にあるノードＮ１に移転される。時点ｔ10において開始が完了したときに、サービスはＮ１上に登録されることになる。時点ｔ11において、ノードＮ０は友好的離脱を完了し、停止する。これは、データベース内における変化を表わすものではない。なぜなら、ノードのアップ／ダウン・ステータスは、データベースに保持されている状態ではないからである。時点ｔ12において、ノードＮ１は友好的離脱を開始し、サービスを停止状態とする。時点ｔ13において停止が完了したとき、サービスは登録を抹消され、移転意向フラグはクリアされる。
【００５７】
【表２】
0003953549.tif 000003
【００５８】
表３に示す例では、ノードＮ０を好適ノードとして定義し、残りのノードを許可ノードとして定義してある。成熟度カウントは２に設定する。自動レジスタは自動に設定する。配置方針は、１つのノード上での登録に設定する。移転コストはない。この例の開始時点において、３つのノードＮ０、Ｎ１およびＮ２は全てダウン状態にある。時点ｔ1において、ノードＮ０が起動し、サービスはノード０上で開始状態に入る。時点ｔ2において、開始が完了し、サービスはノードＮ０上で登録される。時点ｔ3において、ノードＮ１が起動し、サービスがノードＮ０に登録されたことの通知を受ける。時点ｔ4およびｔ7の間で、ノードＮ０は友好的にクラスタを離脱する。サービスはノードＮ１に移転し、そこに登録される。時点ｔ8において、ノードＮ２が起動し、サービスがノードＮ１上に登録されたことの通知を受ける。時点ｔ9において、ノードＮ０が起動し、サービスがノード１上に登録されたことの通知を受ける。時点ｔ10において、起動後直ちに、ノードＮ０は、自由な移転が許可され、ノードＮ１への移転が好ましいことを認める。ノードＮ０は自動的に移転を開始する。サービスは停止状態８６に入り、時点ｔ11において停止が完了する。時点ｔ12において、サービスはノードＮ０上で開始状態に入る。開始は時点ｔ13において完了し、サービスはノードＮ０上に登録される。ノードＮ１およびＮ２は、サービスがノードＮ０上に登録されたことの通知を受ける。
【００５９】
【表３】
0003953549.tif 000004
【００６０】
５．イベント・マネージャ・デーモン
登録および起動サービス５６は自動的にイベント・マネージャ・デーモン５８に、クライアント・サービスに関する状態を監視するよう要求する。イベント・マネージャ・デーモン５８は、イベント群(event_group)を定義することによって応答する。登録および起動サービスは、当該サービスの登録時にこのイベント群をイネーブルし、このサービスの登録抹消に応答してイベント群をディゼーブルするように、イベント・マネージャ・デーモンに要求する。イベント・マネージャ・デーモン５８が問題を検出した場合、イベント・アクション６２を呼び出してその問題を解決する。登録および起動サービスに直接通信を戻すことはない。
【００６１】
表４は、イベント・マネージャ・デーモン５８によって監視されるイベントに対応するフィールドを示す。イベント名フィールドに加えて、ＩＮパラメータおよびＯＵＴパラメータ用フィールドがあり、これらによって、イベントが発生したときに、適切なイベント監視部をセットして検出を行い、ＯＵＴパラメータを満たすイベントを定義する。出力は、特定のイベントと関連付けられた作用機能６２に使用可能となる。イベント群を用いると、そうしなければ無関係なイベントを論理的に関連付け、いつ、どこで、そしてどのような条件の下でそれらをイネーブルするのかを指定することができる。
【００６２】
【表４】
0003953549.tif 000005
【００６３】
イベント・マネージャ・サブシステム５４において、イベント・マネージャ・デーモン５８は、制御の中心である。監視部６０ａ〜６０ｇは全て、通信ライブラリを経て、イベント・マネージャ・デーモンに接続する。イベント・マネージャ・サブシステム５４に設けられた監視部の１つはメンバシップ・マネージャ監視部６０ｅであり、前述したようにメンバシップ・マネージャ・サブシステム４６からノード遷移の通知を受け取り、遷移通知フレームワーク４４にインターフェースを提供する。イベント・マネージャ・サブシステム５４は、このようなノード遷移の意識性を登録および起動サービス５６に与える。
【００６４】
登録および起動サービス５６が特に適している用途の一例は、クラスタ・システム２５上に浮動ライセンス・サーバ(floating license server)を設けるというものである。ライセンスされたソフトウエアは、１つのサービスとして確定され、クラスタ内の所与の数のノード上で実行することが許される。登録および起動サービスは、ライセンスされたソフトウエアをノードの１つに持ち出す起動プログラムを実行する。当該ノードが友好的に、または非友好的に停止した場合、登録および起動サービスは、離脱が非友好的でない場合復元の後に、ライセンスされたソフトウエアを新たなノードに移転する。
【００６５】
以上のように、本発明は、遷移を通じて、関連するサブシステムの多数の層を把握し、１つのクラスタ内の全ノード間で加入および離脱の調整を行う、厳格に調整されたクラスタ・メンバシップ・マネージャ・フレームワークを提供する。サブシステムの１つはユーザ空間にあってもよく、ノードのクラスタへの加入およびクラスタからの離脱の結果として発生する、ユーザ・アプリケーションを含むクライアント・サービスの移転を実行する。他のユーザ空間アプリケーションも、実行時に、メンバシップ・マネージャ遷移通知フレームワークに登録することができる。したがって、マルチプロセッサ・クラスタ技術の高度な集合体処理能力を向上させる、確固としたシステムを提供することができる。
【００６６】
以上具体的に説明した実施例においては、本発明の原理から逸脱することなく変更や修正が可能であるので、本発明は、均等論を含む特許法の原理にしたがって解釈される特許請求の範囲によってのみ、限定されることを意図するものである。
【図面の簡単な説明】
【図１】  本発明によるマルチプロセッサ・クラスタ・システムのブロック図。
【図２】  １サブシステム・レベルにおける遷移通知フレームワークの状態遷移図。
【図３】  ２ノード・クラスタにおいて、クラスタに加入するノードを示す、サブシステムの状態図。
【図４】  ２ノード・クラスタにおいて、クラスタに加入するノードを示す、サブシステムの状態図。
【図５】  ２ノード・クラスタにおいて、クラスタに加入するノードを示す、サブシステムの状態図。
【図６】  ２ノード・クラスタにおいて、クラスタに加入するノードを示す、サブシステムの状態図。
【図７】  ２ノード・クラスタにおいて、クラスタに加入するノードを示す、サブシステムの状態図。
【図８】  ２ノード・クラスタにおいて、クラスタに加入するノードを示す、サブシステムの状態図。
【図９】  ２ノード・クラスタにおいて、クラスタに加入するノードを示す、サブシステムの状態図。
【図１０】  ２ノード・クラスタにおいて、クラスタに加入するノードを示す、サブシステムの状態図。
【図１１】  ２ノード・クラスタにおいて、クラスタに加入するノードを示す、サブシステムの状態図。
【図１２】  ２ノード・クラスタにおいて、クラスタに加入するノードを示す、サブシステムの状態図。
【図１３】  ２ノード・クラスタにおいて、ノードのクラスタからの友好的離脱を示す、サブシステムの状態図。
【図１４】  ２ノード・クラスタにおいて、ノードのクラスタからの友好的離脱を示す、サブシステムの状態図。
【図１５】  ２ノード・クラスタにおいて、ノードのクラスタからの非友好的離脱を示す、サブシステムの状態図。
【図１６】  ２ノード・クラスタにおいて、ノードのクラスタからの非友好的離脱を示す、サブシステムの状態図。
【図１７】  ２ノード・クラスタにおいて、ノードのクラスタからの非友好的離脱を示す、サブシステムの状態図。
【図１８】  クラスタ・サービスの類別を示すブロック図。
【図１９】  多数のクライアント・サービス群の生成を示す、図１７と同様の図。
【図２０】  クライアント・サービスの起動を示す状態遷移図。
【図２１】  クライアント・サービスの遷移状態を示す状態遷移図。
【図２２】  更に他の遷移状態を示す図２０と同様の図。
【図２３】  本発明によるイベント・マネージャ・サブシステムのブロック図。
【符号の説明】
２５    マルチプロセッサ・クラスタ・システム
２６    ノード
２８    物理ディスク
３６    相互接続部
３２    共有クラスタＩ／Ｏバス
３４    メンバシップ・データベース
４０    永続的ノード構成情報
４２    アクティブ・メンバシップ状態データベース
４４    遷移通知フレームワーク
４６    クラスタ・メンバシップ・マネージャ・サブシステム
４８    分散鎖錠マネージャ（ＤＬＭ）サブシステム
５０    仮想ディスク・マネージャ（ＶＤＭ）サブシステム
５２    共有ファイル・システム（ＦＳＦＳ）サブシステム
５４    イベント・マネージャ・サブシステム
５６    登録および起動サービス
６０ａ〜６０ｇ    監視部
５８    イベント・マネージャ・デーモン
６２    作用機能
６４    データベース項目
７８    親クライアント・サービス
８０    子クライアント・サービス
【図１】
0003953549.tif 000006
【図２】
0003953549.tif 000007
【図３】
0003953549.tif 000008
【図４】
0003953549.tif 000009
【図５】
0003953549.tif 000010
【図６】
0003953549.tif 000011
【図７】
0003953549.tif 000012
【図８】
0003953549.tif 000013
【図９】
0003953549.tif 000014
【図１０】
0003953549.tif 000015
【図１１】
0003953549.tif 000016
【図１２】
0003953549.tif 000017
【図１３】
0003953549.tif 000018
【図１４】
0003953549.tif 000019
【図１５】
0003953549.tif 000020
【図１６】
0003953549.tif 000021
【図１７】
0003953549.tif 000022
【図１８】
0003953549.tif 000023
【図１９】
0003953549.tif 000024
【図２０】
0003953549.tif 000025
【図２１】
0003953549.tif 000026
【図２２】
0003953549.tif 000027
【図２３】
0003953549.tif 000028