(57)【要約】マルチプロセッサシステムのクラスタにおいて、プロセッサノードが相互の可用性及び作業能力を認識していることが重要である。マルチプロセッサシステムを用いた可用性の高いシステムにおいて、ノードを動的にクラスタ状態にし、クラスタからノードを除去する方法が必要である。これらの動作に対し責任があるプロセッサノードはマネジャーノード（５０）として示される。マネジャーノードは、前記マネジャーノードがその義務を果たすことができないとこの責任を引き受けるために事前選択バックアップを有する。ノードのクラスタに互いに効率的に通信を行なわせるために、クラスタノード間でデータメッセージを迅速に分散することを可能にする分散形メッセージシステムが必要である。
2004519024.tif 000002
【特許請求の範囲】
【請求項１】
（ａ）分散形メッセージ・システムをノード間に設定し、
（ｂ）ネットワークに追加されると、各ノードがその存在をブロードキャストし、他のノードの存在を受信することを必要とし、
（ｃ）クラスタ内の他のノードから情報を受信すると、１つのノードをクラスタマネジャーとして選択し、
（ｄ）異なるノードをクラスタバックアップマネジャーとして選択する、
ネットワーク化システムにおいてノードのクラスタを管理するための方法。
【請求項２】
（ａ）前記クラスタマネジャーがマネジャーの役割を実行していない状態になると、前記バックアップクラスタマネジャーをクラスタマネジャーとして選択し、
（ｂ）もとのクライアントノードが次にバックアップクラスタの役割を引き受ける、
請求項１に記載の方法。
【請求項３】
前記クラスタマネジャー及び前記バックアップクラスタマネジャーの選択は所定の基準によって設定される、請求項１に記載の方法。
【請求項４】
前記クラスタマネジャー及び前記バックアップクラスタマネジャーがクライアントノードとして指定されるクラスタ内の他のノードに対し、ハートビートを確立すること、をさらに含み、前記クライアントノードが前記ハートビートを受信すると、前記クラスタマネジャー及び前記バックアップクラスタマネジャーに対応するハートビートを戻して応答する、請求項１に記載の方法。
【請求項５】
（ａ）分散形メッセージ・システムは、クラスタ・ワイドと通信を行なうためにノードを使用し、
（ｂ）ネットワークに参加すると、ノードは各自の存在をブロードキャストし、他のノードの存在をそれぞれが受信し、
（ｃ）前記ノードがクラスタ内の他のノードから情報を受信すると、クラスタマネジャーとしてノードを選択し、
（ｄ）バックアップクラスタマネジャーの役割を引き受けるようにノードを選択する、
ネットワーク化コンピュータ環境においてノードのクラスタを管理するためのシステム。
【請求項６】
（ａ）前記クラスタマネジャーがマネジャーの役割を実行していない状態になると、前記バックアップクラスタマネジャーがクラスタマネジャーになり、
（ｂ）もとのクライアントノードが次にバックアップマネジャーになる、
請求項５に記載のシステム。
【請求項７】
前記クラスタマネジャー及び前記バックアップクラスタマネジャーの選択が所定の基準を用いて設定される、請求項５に記載のシステム。
【請求項８】
前記クラスタマネジャー及び前記バックアップクラスタマネジャーがクライアントノードとして指定されるクラスタ内の他のノードに対し、ハートビートを確立すること、をさらに含み、前記クライアントノードが前記ハートビートを受信すると、前記クラスタマネジャー及び前記バックアップクラスタマネジャーに対応するハートビートを戻して応答する、請求項５に記載のシステム。
【請求項９】
（ａ）クラスタを構成するノードにクラスタ・ワイドのメッセージを配布するための手段と、
（ｂ）前記ノードがネットワークに参加すると、各自の存在をブロードキャストするための手段と、
（ｃ）各ノードが他のノードの存在を受信するための手段と、
（ｄ）クラスタ内の他のノードから情報を受信すると、前記ノードがクラスタマネジャーとしてノードを選択するための手段と、
（ｅ）クラスタ内の他のノードから情報を受信すると、前記ノードが次にクラスタのバックアップマネジャーとして別のノードを選択するための手段と、
を含む、ネットワーク化コンピュータ環境においてノードのクラスタを管理するためのシステム。
【請求項１０】
（ａ）クラスタマネジャーがマネジャーの役割を実行していない状態になると、バックアップクラスタマネジャーがクラスタマネジャーの役割を引き受けるための手段と、
（ｂ）クラスタマネジャーとしての役割を引き受けると、バックアップマネジャーが代替バックアップマネジャーとしてもとのクライアントノードを選択するための手段と、
をさらに含む、請求項９に記載のシステム。
【請求項１１】
前記クラスタマネジャー及び前記バックアップクラスタマネジャーの選択のための手段は所定の基準を用いて設定される、請求項９に記載のシステム。
【請求項１２】
前記クラスタマネジャー及び前記バックアップクラスタマネジャーがクライアントノードとして指定されたクラスタ内の他のノードにハートビートを確立するための手段をさらに含み、クライアントノードは前記ハートビートを受信すると、前記クラスタマネジャー及び前記バックアップクラスタマネジャーに対応するハートビートを戻して応答する、請求項９に記載のシステム。
【請求項１３】
（ａ）分散形メッセージ・システムは、ノードをクラスタ・ワイドと通信を行なうために使用し、
（ｂ）ノードがネットワークに参加すると、クラスタ・ワイドの各自の存在をブロードキャストし、該ノードは他のノードの存在をそれぞれ受信することができ、
（ｃ）前記ノードがクラスタ内の他のノードから情報を受信すると、クラスタマネジャーとして特定のノードを選択し、
（ｄ）前記ノードがクラスタ内の他のノードから情報を受信すると、次にクラスタのバックアップマネジャーとして別の特定のノードを選択する、
ネットワーク化環境においてノードのクラスタを管理するためのプログラム命令を含むコンピュータ可読媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、多数のノードを含むクラスタを管理するためのシステム及び方法に関する。
【０００２】
【従来の技術】
本出願は、２０００年９月８日に出願された米国仮出願シリアル番号第６０／２３１、４５１号の利益に対する権利が付与される。
【０００３】
クラスタは、協動する、ネットワーク化されたノードの名前付きの集合である。ノードは、サーバであってもよいし、あるいは、データを処理する能力を有するその他の装置であってもよい。このネットワーク上の各ノードには固有のネットワークアドレスが付与される。このクラスタにおける２つ以上のノードは、ソフトウェア使用可能クラスタ管理システム（ＣＭＳ）を使用してクラスタにおける他のノードを管理する機能を有し、ＣＭＳの原理は以下において本発明に組み込まれる。本発明は、処理システムにエラー及び構成要素の障害に対する耐性を備えさせ、さらにこの処理システムに依存する他のシステムに対し高レベルの可用性を維持する枠組み（フレームワーク）を提供する。構成要素のエラー及び障害は処理システムのハードウェア、又は同システムのソフトウェアのいずれかに生じる可能性がある。従来の故障許容システム（フォールト・トレラント・システム）において、互いにタンデム式に実行され、相互のクロック及び命令を鏡映（ミラリング）する、通常は冗長性を有するＣＰＵがある。これによってＣＰＵの処理能力が制限されるのは、同じ作業を完全に複製するからである。しかしながら、ここに記載されたクラスタ管理システムを用いたシステムにおいて、ノードはより自由に結合され、困難に直面している別のノードの作業を引き継ぐように要求されるまで、それぞれのタスクを別個に実行していてもよい。
【０００４】
【発明が解決しようとする課題】
この従来のフォールト・トレラント・システムに優る本発明の利点は、本発明では処理資源ごとにより多くの作業を実行させることである。
【０００５】
【課題を解決するための手段】
この目的を達成するために、この義務が付与されたノード間において多大な協力及び協調が必要とされる。即ち、クラスタに編成される（複数の）ノードは、クラスタのマネジャーとしてクラスタ内の１つのノードを指定する必要がある。好ましい実施の形態において、所与のクラスタにおける可能なノードのすべてには、他のノードを管理する能力が付与される。クラスタ内のノードは、障害に際して相互に代用として供されることができる。上記共用資源が故障した場合に共用するノードをダウン状態にする可能性があるシステム資源を、これらのノードが通常、共用してはならないことは留意すべきである。この開示によるクラスタ管理システム（ＣＭＳ）は、重要なアプリケーションデータを複製することのできるアプリケーションを、ソフトウェア開発者に構築させることを可能にする。このデータはクラスタ内のノード間で共用されることができ、その結果、ネットワークから取り去られる特定のノードに関係なく、アプリケーションが依然として実行されることを可能にする。この複製されたデータは、時間遅延及び機能性の影響を最小限にして、ノードＢ上のアプリケーションがノードＡ上の故障したアプリケーションの機能を迅速に引き継ぐことを可能にする。
【０００６】
本明細書に記載されるクラスタ管理システムは、ノード発見及びクラスタ・メンバーシップの統一モデルを配送する。このシステムは、可用性及び操作性能について、クラスタ内のノードを常に監視する。ノード故障はクラスタマネジャーによって瞬時に検出され、クラスタマネジャーは、これらのノードによって提供されるサービスがバックアップノードに直ちに置き換えられるように指示する。このクラスタ管理システムは、その環境内のノード資源を検出し、それらからクラスタとして実行するノードの名前付きの集合を構築する。メンバとしてのノードはその後、ハートビートを介して継続的に監視される。ハートビートは、ＸＭＬ言語、少量のデータをクラスタ上のアプリケーションに送信する承認されていないコネクションレス型方法を用いた、ユーザ・データグラム・プロトコル（ＵＤＰ）に準拠したメッセージである。ノード間のその他の通信では、以下で詳細に説明されるように、分散形メッセージ・サービス（ＤＭＳ）が使用される。
【０００７】
本発明は、クラスタ管理の分散形システムのモデルをイネーブルにする。このシステムは、元のマネジャーノードが故障すると、ノードにマネジャーの役割を引き受けさせることができる。本発明はまた、管理システムに基準化（スケーリング）させることができ、その結果、多数のノードの管理を可能にする。本発明はさらに、システムに追加ノードを即座に発見させ、管理するノードが故障すると別のノードに直ちに切り換えさせることを可能にする。本発明はまた、システム管理者が適正であると判断する時、彼らにそのシステムを構成させることもできる。
【０００８】
［発明の詳細な説明］
本発明の実施の形態において、ノードのクラスタにおける各ノードには、共通のソフトウェア使用可能機能のセットが付与される。これらの機能は、クラスタ内のノードのメンバーシップを発見し維持する能力と、周期的ショートデータメッセージをハートビートとして使用する能力と、クラスタに結合するために、その可用性をブロードキャストする能力と、クラスタの役割を受け入れ、割り当てる能力と、を含む。ノード間、及びクラスタ間における通信に対し、この実施の形態では、分散形メッセージ・サービス（ＤＭＳ）が使用される。ＤＭＳの説明は以下の通りである。
【０００９】
分散形メッセージ・サービスは、ハードウェア又はソフトウェアのアーキテクチャを用いたクロス・プラットフォーム・メッセージ・サービスを付与する通信ネットワーク・メッセージ・プロトコルを提供する。このアーキテクチャはクラスタ・ワイドの通信をイネーブルし、「オブジェクト管理」構成要素の監視及び制御をイネーブルする。通信スキーマ及びソフトウェア構成要素の監視と制御は、実行時に同時に作動するように設計される。メッセージは通信ライン上を伝送されるデータのセットとして定義される。これにより、データはネットワーク上を伝送される際にメッセージとなる。
【００１０】
分散形メッセージ・サービスは、このようなデータを通信ライン上を移動させる方法を提供する。このデータはあるコンピュータシステムによって別のコンピュータシステムに送信されることができ、第１のコンピュータシステムに第２のコンピュータシステムを監視及び制御させることを可能にする。この機能は異なるタイプのソフトウェアを実行させる異なるタイプのコンピュータの間においてさらに拡張する。このサービスは、ユーザ開発アプリケーションによって呼び出されることができるアプリケーション・プログラミング・インタフェース（ＡＰＩｓ）を含む。
【００１１】
分散形メッセージ・サービスはまた、クラスタ管理用のその他の特徴及び機能に対し外部インタフェースを提供する。ユーザ開発アプリケーションは、これら種々のＡＰＩｓによって使用可能とされる特徴のすべて又は一部のみを使用するように選択することができる。
【００１２】
これらの特徴は、ロギング方法、障害管理方法、及びメモリ内データベースへのアクセスから構成される。メッセージのロギングは、メッセージをシステムデータベースに記憶させることによって行なわれ、これらメッセージは、先のイベントを分析する能力を支援するために、その後で検索されることもある。
【００１３】
メッセージ・サービスはまた、ノード上で実行中の種々のアプリケーション間にデータを付与することもできる。これは、アプリケーションにそれぞれの状態をチェックポイントさせ（現登録設定とともにメモリのコピーを保存させ）、他のノードに変更を知らせ、それら自身の状態変化通知を受け取らせ、それらの役割に関する情報を受け取らせ、他の処理サービスとインタラクションを行なわせたり、あるいはその他の通信を完了させたりすることができる。
【００１４】
メッセージ・サービスは「発行及び加入」モード、要求／応答モデル、及びポイント・ツー・ポイント通信を含んでいる。この実施の形態において、メッセージ・サービスは、ソケットの上位にあるＴＣＰ／ＩＰプロトコルを使用する。ソケットは２つの番号、即ち、機械のＩＰアドレスとＴＣＰソフトウェアで使用されるポート番号と、の組み合わせである。一般の接続モデルは、メッセージ・サービスを使用するアプリケーションに、メッセージをホストクラスタ管理プロセスへ送信させることができる。ホストは、メッセージを他の関係するアプリケーションに伝送する。
【００１５】
主要なメッセージモデルは、「発行及び加入」である。これは、特定のタイプのメッセージにそれらの関係を登録することによって、クラスタの全体にわたって実行中のアプリケーションを相互に通信させることができる。この登録処理は、チャネルと称される仮想通信ネットワークを形成する。
【００１６】
発行されたメッセージは、クラスタ上のアプリケーションの場所に関係なくそのチャネルに加入したアプリケーションのすべてに対しブロードキャストされる。多くの発行者が同一チャネル上で同時に存在することができる。
【００１７】
メッセージの発行者はまた、特定の受信者にメッセージを送ることができる。これは、「発行」ＡＰＩの代わりに「送信」ＡＰＩを使用することによって実現される。これらＡＰＩ、メッセージ経路指定（ルーティング）、及びデリバリは、異なるオペレーティング・システム・アーキテクチャ及びプロセッサ・アーキテクチャにわたって同様に作動することができる。これは、混合プラットフォーム上のアプリケーションに通信させることを可能にする。ユーザ・アプリケーションは、必要に応じて、使用される特定のプロセッサへのメッセージの変換を処理することができる。
【００１８】
メッセージ・サービスはまた、最高可能速度が要求される場合、２つのユーザ・アプリケーション間において直接接続を確立することもできる。これは、アプリケーションを含むノード上で実行中のクラスタ管理プロセスを仲介者として使用することによって実現される。それは２つのノード間に通信リンクを確立し、アプリケーションどうしが直接通信を行なうことを可能にする。この直接通信は、クラスタマネジャーがインストールされる場合、アプリケーションに組み込まれる小さなライブラリルーチンによって容易になされる。メッセージ・サービスは、システム・メッセージ速度を増加し、メッセージの伝送を確実にするために、コンピュータのマルチスレッド機能を使用することができる。
【００１９】
メッセージが必要とされる場合のみルーティングされることを確実にするために、動的に、即ち、「ランタイムで」更新されることができるルートテーブルが使用される。メッセージ・サービスはまた、資源がアップし、実行（活動）中であるシステムに通信を行なうクラスタ上のアプリケーションに対してハートビートと称される少量のデータを実行させるために、単純且つ承認されていないコネクションレス型プロトコルであるユーザ・データグラム・プロトコル（ＵＤＰ）を適用することもできる。メッセージ・サービスは検出及び通知を確認することができる。
【００２０】
冗長なネットワーキングが基本的なトランスポートによってサポートされない場合、メッセージ・サービスはネットワーク接続故障の間における送信中のデータ損失を保証することができない。ネットワークの故障を検出し、自動的にスタンバイ経路に切り換えることになる。関係のある資源には、この切り換え及びデータの潜在的損失が通知されるので、資源は自らのリカバリを実行することができる。
【００２１】
メッセージ・サービスは、誰がメッセージを受け取るかを判断するために既知の加入者のリストとともに使用されるネーミング・システムを使用する。メッセージは、メッセージのタイプ又はカテゴリの論理的グループ化を可能とするファミリー／タイプ構造を有する。メッセージは、リーダ及び任意のデータを含むパケットである。リーダは、発信者及び送信先情報を含む。
【００２２】
メッセージ「発信者」はメッセージを発行するために登録し、「受信者」は発行されたメッセージに加入する。チャネルのファミリー及びタイプによって指定された所与のメッセージは、ゼロ若しくは１以上の、所与の時間における登録済みの発行者又は加入者を有することがある。メッセージ・サービスは、登録済みの発行者及び加入者を把握している。
【００２３】
メッセージの発行者が応答を要求する場合、２つの他のタイプのメッセージ手法が使用される。１つは要求メッセージであり、もう１つは応答メッセージである。これらのメッセージが通常の「発行、加入」タイプと異なる理由は、それらが各自のタイプを識別するように設定される追加のフラグとともに送信されるからである。メッセージの基本構造は、データの前にあるヘッダである。ヘッダは、バージョン情報、送信者の識別、及び送信先情報を含む。これらはルーティング情報としての役割を果たす。送信先情報は、メッセージのチャネル、ファミリー、及びタイプである。ヘッダはまた、データブロックの大きさ、メッセージ識別番号、及び既述された２つのタイプのフラグを含むこともある。データ部分は２値データのストリング又はブロックである可能性がある。
【００２４】
メッセージ・サービスはまた、メッセージに対する応答を要求することができる。応答は、それが受信された同じチャネル、ファミリー、及びタイプに返信されるが、要求メッセージの発信者に対し送信されるにすぎない。送信者は、メッセージのすべての加入者から個々の応答を受け取ることになる。
【００２５】
メッセージ・サービスはまた、メッセージを特定の受信者に送信するために使用することもできる。メッセージの受信者は、メッセージが受信される場合に実行すべきコールバック機能を指定することができる。コールバック機能はメッセージから情報を受け取り、その情報をアプリケーションのサブルーチンにおいて使用することができる。
【００２６】
メッセージが使用するチャネルは、仮想ネットワークとして働く。メッセージングが発生しているクラスタ内で種々のアプリケーションが使用される。アプリケーションの各セットは同様のアプリケーションとメッセージングを行なうことを望んでいるにすぎない。したがって、１つのチャネル上で伝送されるメッセージは他のチャネルによって検出されない。メッセージ・サービスはまた、すべてのチャネルに同時に発行する機能も有する。それは、２つのアプリケーション間に直接接続をセットアップすることもできる。この直接接続は、特定のアドレスを使用するか、又は仲介をするという、いずれかの方法で設定されることができる。特定のアドレスを使用して、メッセージ・サービスを用いた可用性サービスは接続の確立を管理する。一般に、メッセージを送信するアプリケーションは、「待機（スタンバイ）」のような、ターゲット・メッセージが割り当てられた役割によって、メッセージのターゲットを参照するだけである。
【００２７】
可用性サービスは、ターゲットの正確な名称及びアドレスを得るために役割名称を使用する。サービスは許可された接続を受け入れるためにターゲットをセットアップし、メッセージの送信者にうまく進行していることを通知する。他の方法は、仲介による方法である。この場合、可用性サービス上で実行されるメッセージ・サービスは、送信者がメッセージ・ターゲットを決定すると、その処理を行なう。
【００２８】
発明を実施するための最良の形態
本発明の好ましい実施の形態において、クラスタ内の各ノードはクラスタ管理アプリケーション・ソフトウェアを実行する。図１は一般的なノードである。ハードウェア７は、プロセッサ、電源、ネットワークコンポーネント、Ｉ／Ｏコンポーネント、メモリボード等を含む。オペレーティングシステム（Ｏ／Ｓ）６０は、ハードウェアコンポーネントを制御する。クラスタマネジャー５０はＯ／Ｓ６０とユーザアプリケーション１０のミドルウェアの機能を果たす。クラスタマネジャー５０はまた、データベース２０機能、及び（ハートビートの役割４０を含む）メッセージングシステム３０機能をユーザアプリケーション１０と共用する。
【００２９】
ノードのクラスタ管理責任の１つは、クラスタ・メンバーシップ要求に応答するアクティブな役割を引き受けることであり、新しいノードをクラスタの状態にする責任がある。図２は、単一のノードと、そのノードの役割を変更するために生じる可能性があるイベントを示す。イベント１は、オンライン上で、クラスタの状態になる新しいノードの発生を示し、この図に示されたノードは、マネジャー、スタンバイマネジャー、又はクライアントノードとしてのその役割を再確認する。イベント２は非管理状態からマネジャー状態になるノードを示している。イベント３は、管理状態「クライアント状態」から非管理状態になるノードを示している。イベント４は、その逆を示している。イベント５は、マネジャー状態、非管理状態、スタンバイマネジャー状態、又はクライアント状態から、オフライン状態になるノードを示している。イベント６は、オフライン状態から非管理状態になるノードを示している。イベント７は、スプリット・ブレイン発生においてマネジャーとなったノードがクライアントの役割をする状態になるノードを示している。イベント８は、（もとのマネジャーに障害が起きた場合のようにく、）マネジャーの役割になるバックアップの役割にあったノードを示している。イベント９は、スタンバイマネジャーのノードになるクライアントノードを示している。イベント１０は、スプリット・ブレインの発生の間はスタンバイマネジャーになり、状況の転換によって非管理状態に戻るノードを示している。クラスタ内の１つ以上のノードにはクライアントの役割が割り当てられる。このために、ノードがクライアント役割にある場合、そのノードの行動は特定の行動に制限される。クライアントの役割をするクラスタ内のノードは常に、そのクラスタ内の別のノードの指示を受けている。クラスタ内のノードの１つにはマネジャーの役割が割り当てられる。マネジャーはクラスタの制御を受けており、クラスタ内の新しいノードとクラスタ内で障害を起こしたノードの両方を検出する責任がある。クラスタノードの別の役割は、バックアップマネジャーの役割である。この役割におけるノードは、もとのクラスタマネジャーに障害が起きると、引き継ぎが可能なクラスタマネジャーからチェックポイントデータをクラスタマネジャーとして受け取る。クラスタ内のノードはまた、非管理の役割を引き受けることもできる。クラスタの状態になる非管理ノードは、クラスタマネジャー又はそのクラスタ内のその他のノードをアクティブに探索する。非管理役割は、スタートアップ時におけるノードの最初の役割である。クラスタマネジャー及びそのバックアップがともに故障すると、ノードはこの状態に移行することもできる。クラスタ内のノードはオフラインの役割を引き受けることができる。オフラインノードは、クラスタマネジャー又はその他のノードをアクティブに探索しない。そしてまた、クラスタの一部もアクティブではない。オフラインクラスタの役割は、アップグレード又は他のタイプのメンテナンス状態の間に使用される。クラスタ管理システムは、クラスタ内の各ノードに特定の識別を割り当てる。クラスタマネジャーになることは決して許可されない一部のノードがクラスタ内にあるが、これは、メモリのノード制限、処理能力、又は他の何か機能の欠如の理由からである。
【００３０】
ノードのクラスタが最初にネットワーク上に確立されると、各ノードはその存在をブロードキャストし、他のノードからも受信する。ブロードキャストは、割り当てられるクラスタ名称、存在するオブジェクトのクラス、及びクラスタに割り当てられた静的ポリシーを含む。
【００３１】
各ノードはこの情報を受信し、同じ論理を実行し、さらに該論理及び情報を使用し、どのノードがマネジャーとして実行すべきであるかに票を投じる。暫定的に選択されたマネジャーは種々のステップを実行してクラスタの形成を完了させる。すべてのノードが同等である場合、マネジャー基準は最下位ＩＰアドレスである。クラスタマネジャーはメッセージ・サービスを使用して、クラスタ内のすべてのクライアントノードとの接続を確立する。マネジャー及びクライアントの間にそれぞれ接続が確立された後で、それらは、ハートビートを制御するパラメータを含む追加の情報を共用する。これらのパラメータが確立された後で、クライアントはクラスタのメンバとみなされる。
【００３２】
ノード組み込みプロセスは以下のとおりである。
１．マネジャー：故障の場合、ＣＭＳは一定のタイムアウトを設定する。
２．マネジャー：ＣＭＳは、新しいノードへの接続を確立するためにＤＭＳを呼び出す。
３．クライアント：クライアント上のＤＭＳは接続を受け入れる。ＤＭＳはＣＭＳにマネジャーが接続されたことを通知する。
４．クライアント：故障の場合、ＣＭＳは一定のタイムアウトを設定する。
５．クライアント：ＣＭＳは、自己を記述する情報とともにクラスタマネジャーにＤＭＳメッセージを送信する。自己記述情報のタイプはメンバ識別子、ハートビートポート、ハートビート故障期間、故障期間内のハートビート再試行、ｈｔｔｐポート、ホスト名称、ＮＩＣ情報等を含む。
６．マネジャー：ＣＭＳはクライアントを記述するＤＭＳメッセージを受信し、そのデータを保存する。
７．マネジャー：ＣＭＳは、存在しない場合、若しくは複製である場合、固有のクラスタ識別子をノードに割り当てる。
８．マネジャー：ＣＭＳは、クラスタマネジャーを記述するＤＭＳメッセージをクライアントに送信し、そのクライアントにクラスタ役割を割り当てる。
９．クライアント：ＣＭＳは、クラスタマネジャーを記述するＤＭＳメッセージを受信し、そのデータを保存する。
１０．クライアント：ＣＭＳはその好ましいハートビートポートを開放し、ポート上でスレッドを受信するハートビートを開始させる。
１１．クライアント：ＣＭＳは、ハートビートが開始可能であることを指示するマネジャーにＤＭＳメッセージを送信する。
１２．クライアント：ＣＭＳはステップ４において設定されたタイムアウトをキャンセルする。
１３．クライアント：ＣＭＳはノードのクラスタ役割を非管理からクライアントに変更する。
１４．マネジャー：ＣＭＳは、ハートビートが開始可能であることを指示するクライアントからＤＭＳメッセージを受信し、そのデータをクライアントの状態テーブルに保存する。
１５．マネジャー：ＣＭＳはステップ１のタイムアウトをキャンセルする。
１６．マネジャー：ＣＭＳは特定のパラメータでクライアントに対するハートビートを起動させる。
１７．クライアント：ＣＭＳは、可用性マネジャーが管理されたオブジェクトの登録を受け取れる状態にあるという通知のための可用性管理サービスに登録する。
１８．クライアント：ＣＭＳは、可用性マネジャーが管理されたオブジェクトの登録を受け取れる状態にあると通知される。ＣＭＳは、クライアントのクラスタノード、ＮＩＣ等のためのオブジェクトを登録する。ＣＭＳはその登録準備通知要求をキャンセルする。
１９．クライアント：ＣＭＳは、すべての加入者に配信するためのＤＭＳに対しＤＭＳブロードキャストメッセージ、ＳＲＤＭＳ ＴＹＰＥ ＣＬＵＳＴＥＲ ＮＥＷ ＣＬＩＥＮＴを発行する。このメッセージは、新しいクライアントを記述する情報を含む。１つのメッセージは新しいクライアントのそれぞれに送信される。
【００３３】
ステップ１及び４において設定されたタイムアウトが発生すると、組み込みプロセスは中断され、ＣＭＳは再び発見されるまでその発見されたノードを無視する。
【００３４】
クラスタマネジャーは、繰り返されるハートビートの失敗によってノード故障を検出する。クラスタマネジャーは、それらの定期的ブロードキャストメッセージを介して新しいクラスタメンバを検出する。クラスタマネジャーは、メッセージを受け取って、これに応答するために、ハートビート、及びクラスタメンバの能力をともに監視する。これらのメカニズムのいずれかが故障すると、クラスタマネジャーはクラスタクライアントが故障したものと考える。
【００３５】
クラスタマネジャーはまた、ネットワーク冗長性を管理する。ノードが多数のネットワーク・インタフェース・カード（ＮＩＣ）を含む場合、クラスタマネジャーが各ＮＩＣごとに各ノードを自動的にハートビートすることになる。すべてのメッセージングはすべてのネットワーク上で確立されることになるが、各ノード上の１つのネットワークのみがアクティブな管理トラフィックを伝送するように選択されることになる。多数のＮＩＣを備えたノードは、そのアクティブなＮＩＣのいずれか１つが故障すると、故障したものと見なされる。１つのＮＩＣが故障し、他のノードへの通信が問題に直面すると、クラスタマネジャーは、冗長性を有するＮＩＣ及びネットワークへの切り換えを開始する。クラスタマネジャーは、クラスタ内で生じた種々の変化を他のクラスタメンバに伝達する。
【００３６】
クラスタ管理システムはまた、仮想ネットワークアドレスを割り当て、他の管理システムの低レベルネットワークアドレス管理プリミティブへのアクセスを可能にする。例えば、クラスタ管理システムは、通常はオペレーティングシステムによって制御されるＮＩＣ機能を制御するために呼出しを用いることができる。クラスタマネジャーは外部へのハートビートを送信し、ターゲットはクラスタマネジャーに戻って受信されるハートビートで応答する。これは、各ノードにおける最優先スレッド上で生じる。
【００３７】
クラスタ管理システムは、所定数の試行の後で定期的な再試行が受信されるハートビートを作成することができなかった場合に、クライアントが障害を起こしたと判断する。ノード（クライアント又はバックアップマネジャー）は、再試行の数と再試行期間を乗じることによって計算される時間の間にハートビートを受信することに失敗すると、クラスタマネジャーが失敗したと判断する。これは、クライアントとクラスタマネジャーの双方が個々にハートビートを行なう必要性を回避する。
【００３８】
バックアップマネジャーはクラスタ管理サービスを故障に対し瞬時に応答させることを可能にするが、これは、クラスタマネジャーからのチェックポイントデータに対するアクセスを有するからである。チェックポイントは故障からのリカバリ方法である。チェックポイントは、定期的に保存されるプロセッサメモリの重要（クリティカル）部分のコピーである。障害が発生した場合、その最後のチェックポイントはリカバリ・ポイントとしての機能を果たす。マネジャーが使用しポイントチェックするデータは、どの資源がどのノードで使用可能であるか、どの資源が重要（クリティカル）であるかを含み、最初のノードが障害を起こすか、又はオフラインとなる場合に、別のノードに切り換えられることができる。
【００３９】
バックアップマネジャーはまた、クラスタにおけるクライアントのすべてに対するアクティブなメッセージング機能を有する。バックアップマネジャーを選択するために使用されるポリシーは後述される。選択されたノードはクラスタにおける現在のクライアントでなければならない。
【００４０】
ブリッジＩＰノードは、クラスタがローカルネットワークセグメント上にないクラスタメンバを含むことを望む場合に使用される。クラスタマネジャーは、それぞれの候補ブリッジＩＰノードごとにネットワークアドレス及びポート番号を用いて構成されなければならない。クラスタマネジャーは、それぞれの特定ネットワークアドレス及びメッセージシステムのポート番号で通信を行なうことを定期的に試みる。ブリッジＩＰノードが到達されると、通常のメンバーシップ処理が行なわれる。ブリッジＩＰノードが到達されないと、クラスタマネジャーは定期的に接続を試みる。ブリッジＩＰノードはクライアント以外のクラスタ役割において機能を果たすことはできない。
【００４１】
クラスタマネジャーはクライアントが障害を起こしたと判断すると、クライアントに対する通信をクローズする。クラスタマネジャーは、故障中のクライアントを知らせるブロードキャストメッセージをすべての加入者に発行する。このメッセージはロストクライアントを記述する情報を含む。クラスタマネジャーに障害が起きた場合、バックアップクラスタマネジャーはその障害に反応する。クライアントは、バックアップクラスタマネジャーとその後も通信を行なっているのであれば、クラスタマネジャーに障害があったことを通知しない。クラスタマネジャーの障害は、クラスタマネジャーのクラスタアクティビティのすべてを引き受けるように、バックアップクラスタマネジャーを必要とする。バックアップクラスタマネジャーは以下のステップ（１）乃至（５）を実行する。
（１）クラスタマネジャーに対する通信チャネルをクローズする。
（２）それ自身の役割をマネジャーに切り換える。
（３）現在はマネジャーであることをクライアントに通知する。
（４）故障中のクラスタマネジャーに依存した他のサービスを通知する。
（５）新しいマネジャーとして、すべての加入者に対し、それ自身を既述するブロードキャストメッセージを発行する。
【００４２】
クラスタマネジャーが障害を起こさず、その代わりに、バックアップマネジャーが障害を起こす場合、バックアップマネジャーは、クラスタマネジャーの故障と同様にして障害を起こし、もとのクラスタマネジャーが新しいバックアップクラスタマネジャーを選択する。完全なプロセスは以下の通りである。
【００４３】
バックアップクラスタマネジャーにおける障害を検出すると、クラスタマネジャーはバックアップマネジャーへの通信チャネルをクローズする。バックアップマネジャーにおける障害を検出するクライアントは、バックアップマネジャー及びマネジャーのいずれにも障害が起きなければ、その障害を無視することになる。システムはネットワーク上の他の関係者に対し故障中のバックアップマネジャーを通知する。故障中のバックアップクラスタマネジャーへのそれぞれの通信チャネルをクローズするように、すべてのクライアントにメッセージが送信され、対応するハートビートメッセージのすべてをキャンセルする。
【００４４】
新しいバックアップマネジャーが選択される。この情報はクライアントに伝えられる。新しいバックアップクラスタマネジャーは、クラスタマネジャーに新しいバックアップの状態を通知し、必要な通信チャネルを設定する。バックアップクラスタマネジャーは、それに関するすべての加入者の情報を新しいバックアップクラスタマネジャーとして発行する。
【００４５】
クラスタマネジャー及びバックアップクラスタマネジャーがともに障害を起こすと、クライアントは直ちに非管理役割に移行される。クライアントは、マネジャー及びバックアップマネジャーが消失されたことをすべての加入者にブロードキャストメッセージで発行し、クライアントはここで非管理となる。各クライアントは新しいクラスタメンバーシップ処理の開始時にある。クライアントはクライアントのままである所定の静的ポリシーを有するならば、別のクライアントが管理役割を引き受けるまで非管理された役割の状態にある。
【００４６】
「スプリット・ブレイン」が発生する場合がある。これは、クラスタがクラスタマネジャーとして働く２つ以上のノードを有する場合に発生する。これは、ネットワーク障害がクラスタのノードを分離する場合、最も頻繁に発生する。
【００４７】
クラスタ監視機能の１つは、このスプリットを検出し、リゾリューションを起動することである。１つのクラスタマネジャーが、別のクラスタマネジャーがアクティブであることを報知する別のクラスタマネジャーからの通信を受信すると、第１のクラスタマネジャーは併合（マージャ）を開始する。マージャは、クラスタマネジャー選択プロセスを繰り返して起動することによって実現される。新しいクラスタマネジャー選択はこの順序に従う。システムは、マネジャーとしての働きをする２つのノードのうち、まずポリシーとして実際に好ましいとされるマネジャーはどちらであるかを判断する。次に、それが確定しない場合、その選択は最大数のノードをクラスタに蓄積したクラスタマネジャーには履行しない。選択の最終基準は、最下位ＩＰアドレスを有するマネジャーを選択することである。
【００４８】
新しいクラスタマネジャーが決定されると、リタイアするクラスタマネジャーは以下のステップを実行する。新しいクラスタマネジャーにそのクライアントが誰であるかを示し、そのクライアントのすべてに非管理状態に移行するように命じる。併合されたクラスタマネジャーは、リタイアするクラスタマネジャーによって識別される各ノードとともにノード組み込みシーケンスを開始させる。ノード組み込みシーケンスがリタイアするクラスタマネジャーのノードのそれぞれにおいて完了した後に、２つのクラスタは一つに結合される。このクラスタ管理システムのコンテキストには多数のシナリオが存在する。一般的なシナリオの一部はこのように記述される。クラスタに対する新しいノードがインストールされ、提示される。クラスタマネジャーは自動的に新しいノードを検出し、クラスタ管理交換を完了する。クラスタマネジャーサービスは新しいノードの資源が何であるかに注意する。
【００４９】
クライアントの役割にあるノードが障害を起こす。そのノードに依存するアプリケーションは終了する。障害のあるノードに送信された短いＸＭＬメッセージ（ハートビート）は応答されず、クラスタマネジャーはそのノードを障害のあるものとしてマークすることになる。プロセスはさらに、障害のあるノードに依存していた資源をマークし、利用可能であればバックアップ資源を割り当てることができる。
【００５０】
クラスタマネジャーはシステムメンテナンスのために停止される。バックアップクラスタマネジャーはハートビートがもとのクラスタマネジャーによって応答されていないことを検出し、クラスタマネジャーとして自己起動する。バックアップクラスタマネジャーは、クラスタマネジャーになることをクライアントに通知し、バックアップクラスタマネジャー上で実行中のバックアップサービスに切り換えるようにクラスタマネジャー上で実行中の他のサービスを通知する。バックアップクラスタマネジャーがすべてのクライアントに対しオープン接続及びハートビートを有するので、その移行は迅速である。この移行を完了すると、新しいクラスタマネジャーはすべてのクライアントにその新しい状態を知らせ、新しいバックアップクラスタマネジャーはポリシー情報又はその他の基準に基づいて選択される。
【００５１】
バックアップクラスタマネジャーはシステムメンテナンスのために停止される。クラスタマネジャーは故障中のハートビートを検出し、新しいバックアップクラスタマネジャーの選択を開始する。
【００５２】
アプリケーション又は管理者とのインタラクションを行なう３つの異なるアーキテクチャ方法がある。
（１）構成パラメータがａｐｐ．ｘｍｌファイルを介して設定且つ変更されることができる。
（２）埋め込みＪａｖａ（登録商標）で書かれたアプリケーションプログラムインタフェースを介して、アクティブ・ノード・ページのウェブページがクラスタ管理サービスとインタラクションを行なうことを可能にする。
（３）Ｃ言語で書かれたアプリケーションプログラムインタフェースが他のアプリケーションがインタラクションを行なうことを可能にする。
【００５３】
好ましい実施の形態において、以下のＡＰＩが使用される。
【００５４】
【表１】
2004519024.tif 000003
【００５５】
【表２】
2004519024.tif 000004
2004519024.tif 000005
【００５６】
【表３】
2004519024.tif 000006
2004519024.tif 000007
【００５７】
【表４】
2004519024.tif 000008
【００５８】
図３は、各ノード上で実行されるクラスタ管理プロセスを備えた単一のチャネルネットワークを示している。クラスタ管理システム２２０を実行させるノード１（２１０）は、単一のネットワーク接続（２７０）を介してクラスタ管理システム（２６０）を実行させるノード２（２４０）に接続される。ネットワーク接続（２７０）が障害を起こしたり、又は欠陥が生じると、クラスタ管理システムもまた、通信能力の欠如により障害を起こすであろうことは明白である。図４はさらに有効なシステムを示している。ノード１乃至Ｎは冗長なネットワーク接続３００を用いて通信を行なうことによって、一方の接続が障害を起こしても相互の通信を維持する。本発明の好ましい実施の形態を図示し説明したが、本発明の精神から逸脱することなく種々の変形がこれら実施の形態に加えられてもよいことは当業者には明白である。このため、本発明の範囲は本明細書の特許請求の範囲に示されている。
【図面の簡単な説明】
【図１】
クラスタマネジャーを実施するために必要な処理を実行させるノードを示す図である。
【図２】
特定のノードと、それが引き受ける種々の状態を示す図である。
【図３】
それぞれクラスタマネジャーシステムを実行させる、ネットワーク上の２つのノードを示す図である。
【図４】
重複したネットワーク上のｎ個のノードと、それらノードが引き受ける役割を示す図である。
【図１】
2004519024.tif 000009
【図２】
2004519024.tif 000010
【図３】
2004519024.tif 000011
【図４】
2004519024.tif 000012
【国際公開パンフレット】
2004519024.tif 000013
2004519024.tif 000014
2004519024.tif 000015
2004519024.tif 000016
2004519024.tif 000017
2004519024.tif 000018
2004519024.tif 000019
2004519024.tif 000020
2004519024.tif 000021
2004519024.tif 000022
2004519024.tif 000023
2004519024.tif 000024
2004519024.tif 000025
2004519024.tif 000026
2004519024.tif 000027
2004519024.tif 000028
2004519024.tif 000029
2004519024.tif 000030
2004519024.tif 000031
2004519024.tif 000032
2004519024.tif 000033
2004519024.tif 000034
2004519024.tif 000035
2004519024.tif 000036
2004519024.tif 000037
2004519024.tif 000038
2004519024.tif 000039
【国際調査報告】
2004519024.tif 000040