(57)【特許請求の範囲】
【請求項１】
インターネット・プロトコル（ＩＰ）ネットワークのクラスタ装置であって、
前記クラスタ装置のクラスタ・メンバーは、単独の専用のインターネット・マシン名およびそのクラスタに対するＩＰアドレスによってアドレス可能なすべてのクラスタ・メンバーの一員である複数のクラスタ・メンバーを含み、
各クラスタ・メンバーは、前記クラスタ装置の他のメンバーと相互接続するために、プロセッサと、メモリと、前記メモリの中のプログラムと、入出力ユニットとを備えるコンピュータ・システムと、
前記クラスタ装置における負荷バランスのために、前記クラスタ・メンバーによって受信された各メッセージ・セッションに対するインデックス番号を発生するためのハッシュ・メカニズムを用いるよう構成されたフィルタ・メカニズムとを含み、
前記フィルタ・メカニズムは、発生された前記インデックス番号と、前記各メッセージ・セッションに割り当てられたクラスタ・メンバー・ＩＤとインデックス番号とを含む割り当てテーブルとに基づき、前記クラスタ・メンバーが前記受信されたメッセージを処理しなければならないか、あるいはそれを無視しなければならないかどうかをチェックするよう構成されている装置。
【請求項２】
請求項１に記載の装置において、前記フィルタ・メカニズムによって発生される前記インデックス番号が、前記メッセージが前記クラスタ・メンバーによって処理されるべきか、あるいは捨てられるべきかどうかを各クラスタ・メンバーにおいて決定するために使用される装置。
【請求項３】
請求項１に記載の装置において、マスタ・ユニットとして指定されたクラスタ・メンバーによって使用されるために各クラスタ・メンバーの中に割当てメカニズムをさらに含み、前記割当てメカニズムは未割当てメッセージのセッションのメッセージが前記マスタ・ユニットによって受信されたときに使用され、前記割当てメカニズムは前記フィルタ・メカニズムによって計算された前記インデックス番号を使用して入力メッセージの処理を負荷バランスさせるために、それ以降の処理に対してクラスタ・メンバーに対してメッセージ・セッションの組を割り当てる装置。
【請求項４】
請求項１に記載の装置において、ＴＣＰ状態を含む各メッセージ・セッションに対する状態をセーブするように構成された第１のプログラム・コード・メカニズムを前記複数の各クラスタ・メンバーの中にさらに含む装置。
【請求項５】
請求項４に記載の装置において、必要な時は常に、他の各クラスタ・メンバーに対して各メッセージ・セッションに対してセーブされた状態の不可欠な部分を転送するように構成された第２のプログラム・コード・メカニズムを複数の各クラスタ・メンバーの中にさらに含む装置。
【請求項６】
請求項５に記載の装置において、マスタ・ユニットとして働いているクラスタ・メンバーが前記クラスタ内の前記他のメンバーの１つにおける装置故障を認識することができ、前記故障したクラスタ・メンバーの作業を前記クラスタの中の残りのメンバーに対して再割当てし、それにより処理負荷を再度バランスさせ、前記メッセージ・セッションを維持することができるように構成されている第３のプログラム・コード・メカニズムを、前記複数の各クラスタ・メンバーの中にさらに含む装置。
【請求項７】
請求項６に記載の装置において、マスタ・ユニットとして動作していないユニットが前記マスタ・ユニットの中に装置の故障を認識することができ、残りのクラスタ・メンバーのうちの１つを新しいマスタ・ユニットとして直ちに、そして協力的に割り当て、前記新しいマスタ・ユニットが前記故障したクラスタ・メンバーの作業を残りのクラスタ・メンバーに対して再割当てし、それにより処理負荷をバランスさせ、前記メッセージ・セッションを維持することができるように構成されている第４のプログラム・コード・メカニズムを複数の各クラスタ・メンバーの中にさらに含む装置。
【請求項８】
請求項１に記載の装置において、前記の各クラスタ・メンバーの前記メモリが、前記クラスタ・メンバーのクラスタ・アドレスを含む前記クラスタ・メンバーのパーソナリティを記述するプログラム・コード・メカニズムを含むフラッシュ・メモリ・カードを含む装置。
【請求項９】
インターネット・プロトコル（ＩＰ）ネットワークのクラスタにおいて複数のコンピュータを動作させるための方法であって、前記クラスタはネットワークのユーザに対してシングル・システム・イメージを提供し、前記方法が、
ａ．プロセッサとメモリと、前記メモリの中のプログラムと、ディスプレイ画面と入出力ユニットとを備えるコンピュータ・システムを含む複数のクラスタ・メンバーを提供するステップと、
ｂ．前記クラスタ・メンバーを一緒に相互接続し、そしてすべてのクラスタ・メンバーに同じインターネット・マシン名および同じＩＰアドレスを割り当て、それにより前記クラスタに到着するメッセージが前記クラスタの中の適切なメンバーによって認識され、任意のクラスタ・メンバーからの出力が前記クラスタから入ってくるものとして認識され、それにより前記クラスタ・メンバーが互いに通信することができるステップと、
ｃ．ハッシュ・メカニズムを使用して前記クラスタ・メンバーによって受信された各メッセージ・セッションに対してインデックス番号を発生し、前記インデックス番号と、前記各メッセージに割り当てられたクラスタ・メンバー・ＩＤとインデックス番号とを含む割り当てテーブルとに基づき、前記クラスタ・メンバーが前記受信されたメッセージを処理しなければならないか、あるいはそれを無視しなければならないかどうかを示すフィルタ・メカニズムを各クラスタ・メンバーの中に提供するステップとを含む方法。
【請求項１０】
請求項９に記載の方法において、各クラスタ・メンバーにおいて前記メッセージがそのクラスタ・メンバーによって処理されるべきか、あるいは捨てられるべきかどうかを決定するために、前記フィルタ・メカニズムによって発生された前記インデックス番号が使用される方法。
【請求項１１】
請求項９に記載の方法において、マスタ・ユニットとして指定されたクラスタ・メンバーによって使用されるために各クラスタ・メンバーの中に割当てメカニズムをさらに含み、前記割当てメカニズムは未割当てのメッセージ・セッションのメッセージがマスタ・ユニットによって受信されたときに使用され、前記割当てメカニズムが前記フィルタ・メカニズムによって計算されたインデックス番号を使用してメッセージ・セッションのセットを、入力メッセージの処理を負荷バランスさせるためにそれ以降の処理のためにクラスタ・メンバーに対して割り当てる方法。
【請求項１２】
請求項９に記載の方法において、ＴＣＰの状態を含む各メッセージ・セッションの接続に対する状態を各クラスタ・メンバーがセーブし、そして前記状態を不可欠な状態の部分と不可欠でない状態の部分とに分けるための追加のステップを含む方法。
【請求項１３】
請求項１２に記載の方法において、各クラスタ・メンバーが他の各クラスタ・メンバーに対して前記クラスタ・メンバーが担当するメッセージ・セッションのためのセーブされた不可欠な状態の部分を転送し、そのような転送が、前記状態の変化の前記不可欠な部分が変化するたびに行われ、それによりすべてのクラスタ・メンバーがすべてのメッセージ・セッションの接続に対する不可欠な状態を含む方法。
【請求項１４】
請求項１３に記載の方法において、各クラスタ・メンバーが前記クラスタ・メンバーの１つの装置故障を認識し、故障したのがマスタ・ユニットであった場合に、前記マスタの役割を直ちに転任し、該転任されたマスタ・ユニットが前記マスタ・ユニットに対して割り当てられていた作業を再割り当てし、残りのクラスタ・メンバー上の負荷を再バランスさせる追加のステップを含む方法。
【請求項１５】
インターネット・プロトコル（ＩＰ）ネットワーク・クラスタ装置であって、
複数の相互接続されたクラスタ・メンバーの各クラスタ・メンバーが、プロセッサと、メモリと、前記メモリの中のプログラムと、入出力ユニットとを有するコンピュータ・システムを備え、
前記複数の各クラスタ・メンバーにおいて、前記複数のクラスタ・メンバーの各々が、一緒に接続されていて前記複数のクラスタ・メンバーの他のメンバーを認識し、適応的にマスタ・ユニットを指定するために前記他のメンバーと協調する手段と、
前記クラスタ・メンバーによって受信された各メッセージ・セッションに対するインデックス番号を発生し、発生された前記インデックス番号と、前記各メッセージ・セッションに割り当てられたクラスタ・メンバー・ＩＤとインデックス番号を含む割り当てテーブルとに基づき、前記クラスタ・メンバーが前記受信されたメッセージを処理しなければならないか、あるいはそれを無視しなければならないかどうかをチェックする手段を含む装置。
【請求項１６】
請求項１５に記載の方法において、各クラスタ・メンバー上で前記メッセージが前記クラスタ・メンバーによって処理されるべきか、あるいは捨てられるべきかどうかを決定するために前記インデックス番号が使用される方法。
【請求項１７】
請求項１５に記載の装置において、前記複数の各クラスタ・メンバーにおいて各メッセージ・セッションに対する不可欠な状態をセーブするための手段をさらに備える装置。
【請求項１８】
請求項１７に記載の装置において、前記複数の各クラスタ・メンバーにおいて、前記クラスタの中の前記他の各メンバーに対して各メッセージ・セッションに対して前記セーブされた不可欠な状態を定期的に転送するための手段をさらに備える装置。
【請求項１９】
請求項１８に記載の装置において、前記複数の各クラスタ・メンバーにおいて、クラスタ・メンバーがマスタ・ユニットとして働き、前記他のクラスタ・メンバーの１つに装置故障を認めるための、そして前記故障したクラスタ・メンバーの作業を前記クラスタの中の残りのメンバーに対して再割当てし、それにより前記処理負荷を再バランスさせてメッセージ・セッションの接続を維持するため、そしてマスタ・ユニットとして働いていないクラスタ・メンバーが前記マスタ・ユニットにおける装置故障を認識することができ、前記残っているクラスタ・メンバーのうちの１つを新しいマスタ・ユニットとして直ちに、そして協調的に指定し、前記新しいマスタ・ユニットが前記故障したクラスタ・メンバーの作業を前記クラスタの中の残っているメンバーに対して再割当てし、それにより処理負荷を再バランスさせ、メッセージ・セッションの接続を維持することができる装置。
【発明の詳細な説明】
【０００１】
（技術分野）
本発明は、一般的なネットワーク通信セクタにおけるコンピュータ・システムの分野に関する。特に、本発明は、インターネット・プロトコル（ＩＰ）ネットワークのクラスタリング・システムのための方法および装置である。
【０００２】
（背景技術）
企業がそれぞれの製品を販売するため、そしてその注文および配送を管理するためにインターネットを使用した電子商取引のアプリケーションをどんどん開発するにつれて、これらの企業はセキュリティおよび高い利用可能性を提供するコスト効率の良いインターネット・リンクを探し求めている。そのような重要なアプリケーションは、メッセージ・トラヒックが成長するにつれて毎日、信頼性の非常に高い、そして容易にスケール可能なネットワーク構成部品によって終日、そして毎日稼働する必要がある。国内の通信事業者および局所インターネット・サービス・プロバイダ（ＩＳＰ）は、これらの要求に対する解決策として、現在、仮想私設網（ＶＰＮ）（広範囲のローカル・エリア・ネットワーク（ＬＡＮ）上での企業のワークグループを一緒に結んでいる高度なインターネット・ベースのバックボーン）を提供している。
【０００３】
いくつかの会社が最近ＶＰＮの製品および／またはシステムをアナウンスまたは提供しており、それらはユーザに対して安全なトラヒックを提供するために、ポイント・ツー・ポイントのトンネリング・プロトコル（ＰＰＴＰ）、およびレイヤ２トンネリング・プロトコル（Ｌ２ＴＰ）以外に、ＩＰＳｅｃ、ＩＫＥ（ＩＳＡＫＭＰ／Ｏａｋｌｅｙ）暗号化キー管理を各種サポートする。これらの製品のいくつかは、ＩＢＭのＮｗａｙｓ  Ｍｕｌｔｉｒｏｔｏｃｏｌ  Ｒｏｕｔｉｎｇ  Ｓｅｒｖｉｃｅｓ（商標）２．２、Ｂａｙ  Ｎｅｔｗｏｒｋｓ  Ｏｐｔｉｖｉｔｙ（商標）およびＣｅｎｔｉｌｌｉｏｎ（商標）の製品、Ａｓｃｅｎｄ  ＣｏｍｍｕｎｉｃａｔｉｏｎのＭｕｌｔｉＶＰＮ（商標）パッケージ、Ｄｉｇｉｔａｌ  ＥｑｕｉｐｍｅｎｔのＡＤＩ  ＶＰＮ製品ファミリ、およびＩｎｄｕｓ  ＲｉｖｅｒのＲｉｖｅｒＷｏｒｋｓ（商標）ＶＰＮ計画された製品を含む。しかし、これらの製品はいずれも管理されたフェイルオーバ・プロセスによって遅延およびセッション消失を最小化する機能を提供してはいない。
【０００４】
これらのＶＰＮは企業のネットワーク・インフラストラクチャに膨大な要求を課す。高い信頼性およびスケーラビリティがあるように作られている必要があるゲートウェイ、ファイアウォール、トンネル・サーバおよび他のチョーク・ポイントなどの故障構成部品の単独ポイントは、「ホット・スタンバイ」および各種のタイプのクラスタリング・システムなどの冗長な装置で対策されている。
【０００５】
例えば、ＣＩＳＣＯ（商標）Ｉｎｃ．は、現在ＬｏｃａｌＤｉｒｅｃｔｏｒ（商標）と呼ばれる新しい製品を提供しており、それはサーバのグループに対するフロントエンドとして機能し、サーバ間のＴＣＰトラヒックを動的に負荷バランスさせて要求に対するタイムリーなアクセスおよび応答を確実にする。ＬｏｃａｌＤｉｒｅｃｔｏｒは、「仮想」サーバの外見をエンド・ユーザに対して提供する。ＬｏｃａｌＤｉｒｅｃｔｏｒが故障した場合においても途切れないアクセスを提供する目的のために、ユーザは、その一次ユニットに対して直接付加される冗長のＬｏｃａｌＤｉｒｅｃｔｏｒシステムを購入し、その冗長ユニットを「ホット」スタンバイとして動作させておく必要がある。このスタンバイ・ユニットはマスタ・ユニットが故障するまでそれ自身の処理作業を行わない。スタンバイ・ユニットは、フェイルオーバＩＰアドレスおよび二次的なメディア・アクセス制御（ＭＡＣ）アドレス（一次ユニットと同じである）ので、スタンバイ・ユニットに対して切り換えるためにアドレス・レゾリューション・プロトコル（ＡＲＰ）は不要である。しかし、スタンバイ・ユニットは各接続上での状態情報を保持しないので、すべてのアクティブな接続はドロップされ、クライアントによって再確立されなければならない。さらに、「ホット・スタンバイ」は、同時並行的に処理しないので、それは処理負荷の軽減や、スケーリング機能を提供しない。
【０００６】
同様に、Ｖａｌｅｎｃｅ（商標）Ｒｅｓｅａｒｃｈ  Ｉｎ．（最近Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｃｏｒｐｏｒａｔｉｏｎによって買収された）は、Ｃｏｎｖｏｙ  Ｃｌｕｓｔｅｒ（商標）（Ｃｏｎｖｏｙ）と呼ばれるソフトウェア製品を提供している。Ｃｏｎｖｏｙは標準のＷｉｎｄｏｗｓ  ＮＴネットワーキング・ドライバとしてインストールされ、既存のＬＡＮ上で稼働する。それはサーバのアプリケーションおよびＴＣＰ／ＩＰクライアントの両方に対してトランスペアレントな方法で動作する。これらのクライアントは１つのＩＰアドレスを使用することによって、それがあたかも単独のコンピュータであるかのようにクラスタにアクセスすることができる。Ｃｏｎｖｏｙはクラスタ化されたコンピュータ間のネットワーキング・トラヒックを自動的にバランスさせ、そしてクラスタ・メンバーがオンラインになるか、あるいはオフラインになるときは常にその負荷を再バランスさせることができる。しかし、このシステムはどのメッセージ・タイプがどのクラスタ・メンバーによって処理されるべきかを決定するために計算集中的な、そしてメモリを浪費する方法を使用するようにみえ、その中でメッセージのソース・ポート・アドレスと宛先ポート・アドレスとの組合せがインデックス・キーとして使用され、そのインデックス・キーは記憶されていて、どのメンバーがそのメッセージを処理するかを決定するために、各入力メッセージの同様な組合せに対して比較されなければならない。さらに、このシステムはフェイルオーバを行わない。
【０００７】
この技術の分野において爆発的に増加しているユーザのバンド幅要求を処理するために、容易にスケール可能なＩＰネットワーク・クラスタ・システムに対するニーズが存在する。さらに、益々多くの人がインターネットに入り込んでより長くその中に止まっているので、クラスタのオーバヘッドをできる限り効率化することによって、スループット、遅延およびパケット消失の面でのネットワークの可用性、信頼性および性能を最大化する必要がある。さらに、すべての接続上の状態情報を効率的にセーブしてパケット消失および再接続に対する必要性を最小化するようにすることによって、ＴＣＰベースのシステムに対する信頼性の高いフェイルオーバ・システムを提供するためのニーズがさらに存在する。
【０００８】
「シングル・システム・イメージ」クラスタなどのコンピュータ・クラスタ・システムがこの分野の技術において周知である。例えば、カイ・ワングおよびツィウェイ・スー（Ｚｈｉｗｅｉ  Ｘｕ）による「スケーラブルな並列コンピューティング」、ＭｃＧｒａｗ‐Ｈｉｌｌ、１９９８年、ＩＳＢＮ  ０‐０７‐０３１７９８‐４の第９章および１０章の４５３〜５６４ページを参照されたい。それらの全文を引用によって本明細書の記載に援用する。ＤＥＣのＴｒｕＣｌｕｓｔｅｒｓ（商標）システム、ＩＢＭのＳＰ（商標）システム、ＭｉｃｒｏｓｏｆｔのＷｏｌｆｐａｃｋ（商標）システムおよびＢｅｒｋｅｌｅｙのＮＯＷプロジェクトなどの各種の商用のクラスタ・システム製品がその中で記述されている。これらのシステムはいずれもスケーラビリティおよび負荷バンランシングおよび管理されたＴＣＰフェイルオーバを組み合わせた効率的なＩＰネットワーク・クラスタ機能を提供するものとしては知られていない。
【０００９】
（発明の概要）
本発明は、ＩＰネットワーク・クラスタに対して経済的で高性能な、適応可能なシステムおよび方法を提供することによって上記システムの欠点を克服する。
本発明は、スケーラビリティの高いシステムを提供することができるＩＰネットワーク・クラスタリング・システムであり、そのシステムはその構成部品を適応的に負荷バランスさせることによってメッセージのスループットを最適化し、そして管理されたフェイルオーバ・プロセスによって、特にＴＣＰモードにおいて遅延およびパケット消失を最小化する。他の周知のトンネル・サーバ・システムは、この組み合わされたスケーラビリティ、負荷バランシングおよび管理されたフェイルオーバを提供することができない。
【００１０】
本発明は、複数のクラスタ・メンバーを含むクラスタ装置を含み、すべてのクラスタ・メンバーが同じインターネット・マシン名およびＩＰアドレスを有しており、各メンバーが汎用プロセッサと、メモリ・ユニットと、そのメモリ・ユニットの中のプログラムと、ディスプレイと、入出力ユニットとを有しており、その装置は、各クラスタ・メンバーの中にフィルタ・メカニズムを有しており、それは非常に効率の良いハッシング・メカニズムを使用して各メッセージ・セッションに対するインデックス番号を発生し、クラスタ・メンバーが特定のメッセージを処理するかどうかを決定するために、そのインデックス番号が使用される。インデックス番号は、さらに、どのクラスタ・メンバーがそのメッセージの処理を担当するかを指定するために使用され、そしてさらに、現在のすべてのクラスタ・メンバー上での処理負荷をバランスさせるために使用される。
【００１１】
本発明は、さらに、ネットワーク・ユーザにシングル・システム・イメージを提供するＩＰネットワーク・クラスタの中の複数のコンピュータを動作させるための方法を含み、その方法は、クラスタ・メンバーを相互接続するためのステップを含み、すべてのクラスタ・メンバーに同じインターネット・マシン名およびＩＰアドレスを割り当て、それにより、すべてのクラスタ・メンバーがそのクラスタに到着するすべてのメッセージを受信することができ、そしてそのクラスタのメンバーによって渡されるすべてのメッセージが単独のユニットから来るように見え、そしてそれらが互いに通信できるようにし；そのクラスタの中のマスタ・ユニットとしてどのクラスタ・メンバーが働くかを適応的に指定し；そしてその方法は効率の高いハッシング・メカニズムを使用して各メッセージ・セッションに対するインデックス番号を発生し、それにより、クラスタ・メンバーが特定のメッセージを処理するべきかどうかを決定するために、そのインデックス番号が使用されるフィルタ・メカニズムを各クラスタ・メンバーの中に提供する。そのインデックス番号は、どのタイプのメッセージの処理をどのクラスタ・メンバーが担当するかを指定するために使用され、そしてさらに、現在のすべてのクラスタ・メンバー上での処理負荷をバランスさせるために使用される。
【００１２】
本発明の他の実施形態は、以下の詳細な説明から当業者なら容易に理解することができるだろう。その中で、本発明を実行するためにこの時点で知られている最善のモードの例を示すことによって、本発明の実施形態だけが示されて説明されている。本発明は他の異なる実施形態で実行することができ、そのいくつかが例示としての目的のために記述され、それら実施形態を本発明の精神および範囲から逸脱することなしに種々の点で修正することができる。
本発明のシステムおよび方法の特徴および利点が以下の説明から明らかになる。
【００１３】
（発明を実施するための最良の形態）
インターネット・プロトコル（ＩＰ）ネットワーク・クラスタを動作させるための方法および装置を開示する。以下の記述において、説明する目的のために、特定のデータおよび構成が本発明の完全な理解を提供するために記述されている。この好適な実施形態の場合には、ＩＰネットワーク・クラスタは、ＶＰＮトンネル・サーバ・クラスタに関して説明する。しかし、当業者なら、本発明は、ファイアウォール・クラスタ、ゲートウェイまたはルータのクラスタなどの各種の用途において特定の詳細なしに実施できることを理解することができるだろう。他の実施形態の場合には、周知のシステムおよびプロトコルは、本発明を不必要に不明瞭化しないために、図式的な、あるいはブロック図の形で示し説明する。
【００１４】
＜動作環境＞
本発明が使用される環境は汎用分散型コンピューティングのシーンを包含し、それはハブ、ルータ、ゲートウェイ、トンネル・サーバ、アプリケーション・サーバなどを備えたローカル・エリア・ネットワークを一般的に含み、他のクライアントおよび他のネットワークにインターネットを経由して接続され、その中でプログラムおよびデータがシステムの他のメンバーによって実行およびアクセスのためにシステムの各種メンバーが利用できるようにされている。代表的なインターネット・ネットワーク構成の要素のいくつかが図１に示されており、その中でクライアント・マシンのメンバー１０５は企業の支店の中にあり、それがゲートウェイ／ハブ／トンネル・サーバ／など１０６に接続されているように示され、１０６それ自身はいくつかのインターネット・サーバ・プロバイダ（ＩＳＰ）の接続１０８を経由してインターネット１０７に接続されている。また、同様にＩＳＰ接続１０４を経由してインターネット１０７に接続されている他の可能なクライアント１０１、１０３も示されており、これらのユニットはゲートウェイ／トンネル・サーバ１１０に対するＩＳＰ接続１０９を経由しておそらくホーム・オフィスに対して通信しており、ゲートウェイ／トンネル・サーバ１１０は各種企業のアプリケーション・サーバ１１２、１１３、１１４に１１１で接続されており、それらは別のハブ／ルータ１１５を通して各種の局所クライアント１１６、１１７、１１８に接続することができる。
【００１５】
現在のＩＰネットワーク・クラスタは、図２に示されている要素を一般的に含むある数の汎用コンピュータ・ユニットから構成されており、その中で汎用システム２０１が、入出力（「Ｉ／Ｏ」）セクション２０５と、１つまたはそれ以上の中央処理ユニット（「ＣＰＵ」）２０７と、メモリ・セクション２０９とを有するマザーボード２０３を含み、メモリ・セクション２０９はそれに関連するフラッシュ・メモリ・カード２１１を備えることができる。Ｉ／Ｏセクション２０５はキーボード２２６、他の同様な汎用コンピュータ・ユニット２２５、２１５、ディスク記憶ユニット２２３およびＣＤ‐ＲＯＭドライブ・ユニット２１７に接続されている。ＣＤ‐ＲＯＭドライブ・ユニット２１７は、ＣＤ‐ＲＯＭ媒体２１９を読むことができ、ＣＤ‐ＲＯＭ媒体２１９は、通常、プログラム２２１および他のデータを含んでいる。これらのプログラムされたコンピュータの論理回路または他の構成部品は、以下にさらに詳しく説明するように、コンピュータ・プログラムによって記述されている一連の特に識別された動作を実行する。
【００１６】
フラッシュ・メモリ・ユニットは、通常、そのようなコンピュータ・システムにおいて各種の目的のために使用される追加のデータを含んでいる。本発明の好適な実施形態の場合には、そのフラッシュ・メモリ・カードは図３に示されているある種のユニットの「パーソナリティ」情報を含めるために使用されている。一般に、現在の実施形態において使用されているフラッシュ・カードは以下のタイプの情報を含む。
【００１７】
暗号化によって署名されたカーネル‐（３０１）
構成ファイル（クラスタ名、特定のユニットＩＰアドレス、クラスタ・アドレス、ルーティング情報の構成など）‐（３０３）
エラー・メッセージ・ログに対するポインタ‐（３０３）
認可証明書‐（３０７）
機密保護手段（例えば、暗号化が必要かどうかなど）‐（３０９）
【００１８】
＜発明＞
本発明は、構成部品を適応的に負荷バランスさせることによってスループットを最適化し、そして管理されたフェイルオーバ・プロセスによって遅延およびセッション消失を最小化するスケーラビリティの大きいシステムを提供することができるインターネット・プロトコル（ＩＰ）クラスタリング・システムである。好適な実施形態の代表的なＩＰクラスタ・システムが図４に示されており、ここでインターネット１０７が代表的なＩＰクラスタ４０１に接続されているように示され、ＩＰクラスタ４０１はプログラムされた汎用コンピュータ・ユニット４０３、４０５、４０７、４０９を含み、これらのコンピュータ・ユニットが受信されたメッセージ・パケットに対するプロトコル・スタック・プロセッサとして働く。ＩＰクラスタ４０１は、通常、ネットワークの中でアプリケーション・サーバまたは他の同様なタイプのユニット４１１に接続されている。
【００１９】
この図の中で、任意の数のユニットが１つのクラスタの中にあり得るが（例えば、メンバー「ｎ」４０９）、しかし、以降の例示としての目的のために、そのクラスタは３つのユニットを有しているものとして表され、本発明のクラスタは３つのユニットだけに限定されるのではないことを理解されたい。また、例示としての目的のために、この好適な実施形態はその用途がＶＰＮトンネル・プロトコルであってよいクラスタとして記述されるが、このクラスタの発明はそのアプリケーションが、例えば、ファイアウォ‐ルとして働く、あるいはゲートウェイとして働く、あるいはセキュリティ装置として働くクラスタとしても使用できることを理解されたい。
【００２０】
本発明の好適な実施形態の場合には、クラスタの各メンバーは、インテルのマザーボードと、２つのインテルのＰｅｎｔｉｕｍ（商標）プロセッサと、６４メガバイトのメモリと、２個のインテルのイーサネット・コントローラと、２つのＨｉＦｎ暗号化プロセッサとを備えるコンピュータ・システムである。各プロセッサによって実行される機能が、図５に示されているように、各プロセッサの汎用メモリ・マップに対する参照によって一般的に示されている。クラスタの各メンバーはオペレーティング・システム・カーネル５０１と、ＴＣＰ／ＩＰスタック・ルーチン５０３と、各種のクラスタ管理ルーチン（以下にさらに詳細に説明される）５０５と、この好適な実施形態の場合には、ＩＰＳｅｃプロトコルを処理するためのコードであるアプリケーション＃１を処理するためのプログラム・コード５０７と、この好適な実施形態の場合には、ＰＰＴＰプロトコルを処理するためのコードであるアプリケーション＃２を処理するためのプログラム・コード５０９と、この好適な実施形態の場合には、Ｌ２ＴＰプロトコルを処理するためのコードであるアプリケーション＃３を処理するためのプログラム・コード５１１と、この好適な実施形態の場合には、おそらく「移動ＩＰ」プロトコルなどの追加のプロトコルを処理するためのコード空間であるアプリケーション＃４を処理するためのプログラム・コード５１３とを備える。これらのプロトコルについての詳細情報は「“ｈｐｐｔ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ」にあるＩＥＴＦのホーム・ページにある。以下の特定のプロトコル記述の全文を引用によって本明細書の記載に援用する。
【００２１】
「ポイント・ツー・ポイントのトンネリング・プロトコル‐‐ＰＰＴＰ」、Ｇｌｅｎ  Ｚｏｒｎ，Ｇ．Ｐａｌｌ，Ｋ．Ｈａｍｚｃｈ，Ｗ．Ｖｅｒｔｈｅｉｎ，Ｊ．Ｔａａｒｕｄ，Ｗ．Ｌｉｔｔｌｅ，０７／２８／１９９８；
「レイヤー２のトンネリング・プロトコル」、Ａｌｌａｎ  Ｒｕｂｅｎｓ，Ｗｉｌｌｉａｍ  Ｐａｌｔｅｒ，Ｔ．Ｋｏｌａｒ，Ｇ．Ｐａｌｌ，Ｍ．Ｌｉｔｔｌｅｗｏｏｄ，Ａ．Ｖａｌｅｎｃｉａ，Ｋ．Ｈａｍｚｅｈ，Ｗ．Ｖｅｒｔｈｅｉｎ，Ｊ．Ｔａａｒｕｄ，Ｗ．Ｍａｒｋ  Ｔｏｗｎｓｌｅｙ，０５／２２／１９９８；
Ｋｅｎｔ，Ｓ．，Ａｔｋｉｎｓｏｎ，Ｒ．，「ＩＰ認証ヘッダ」ｄｒａｆｔ‐ｉｅｔｆ‐ｉｐｓｅｃ‐ａｕｔｈ‐ｈｅａｄｅｒ‐０７．ｔｘｔ
Ｋｅｎｔ，Ｓ．，Ａｔｋｉｎｓｏｎ，Ｒ．，「インターネット・プロトコルのためのセキュリティ・アーキテクチャ」ｄｒａｆｔ‐ｉｅｔｆ‐ｉｐｓｅｃ‐ａｒｃｈ‐ｓｅｃ‐０７．ｔｘｔ
Ｋｅｎｔ，Ｓ．，Ａｔｋｉｎｓｏｎ，Ｒ．，「ＩＰカプセル化セキュリティ・ペイロード（ＥＳＰ）」、ｄｒａｆｔ‐ｉｅｔｆ‐ｉｐｓｅｃ‐ｅｓｐ‐ｖ２‐０６．ｔｘｔ
【００２２】
Ｐｅｒｅｉｒａ．Ｒ．，Ａｄａｍｓ，Ｒ．，「ＥＳＰ  ＣＢＣモード暗号化アルゴリズム」ｄｒａｆｔ‐ｉｅｔｆ‐ｉｐｓｅｃ‐ｃｉｐｈ‐ｃｂｃ‐０４．ｔｘｔ
Ｇｌｅｎｎ，Ｒ．，Ｋｅｎｔ．，Ｓ．，「ヌル暗号化アルゴリズムおよびそのＩＰｓｅｃでの使用」ｄｒａｆｔ‐ｉｅｔｆ‐ｉｐｓｅｃ‐ｃｉｐｈ‐ｎｕｌｌ‐０１．ｔｘｔ
Ｍａｄｓｏｎ，Ｃ．，Ｄｏｒａｓｗａｍｙ，Ｎ．，「明示的ＩＶによるＥＳＰ  ＤＥＳ‐ＣＢＣ暗号化アルゴリズム」、ｄｒａｆｔ‐ｉｅｔｆ‐ｉｐｓｅｃ‐ｃｉｐｈ‐ｄｅｓ‐ｅｘｐｉｖ‐０２．ｔｘｔ
Ｍａｄｓｏｎ，Ｃ．，Ｇｌｅｎｎ，Ｒ．，「ＥＳＰおよびＡＨの内部でのＨＭＡＣ‐ＭＤＳの使用」ｄｒａｆｔ‐ｉｅｔｆ‐ｉｐｓｅｃ‐ａｕｔｈ‐ｈｍａｃ‐ｍｄ５‐９６‐０３．ｔｘｔ
Ｍａｄｓｏｎ，Ｃ．，Ｇｌｅｎｎ，Ｒ．，「ＥＳＰおよびＡＨの中のＨＭＡＣ‐ＳＨＡ‐１‐９６の使用」ｄｒａｆｔ‐ｉｅｔｆ‐ｉｐｓｅｃ‐ａｕｔｈ‐ｈｍａｃ‐ｓｈａ１９６‐０３．ｔｘｔ
【００２３】
Ｈａｒｋｉｎｓ，Ｄ．，Ｃａｒｒｅｌ，Ｄ．，「インターネットのキー交換（ＩＫＥ）」ｄｒａｆｔ‐ｉｅｔｆ‐ｉｐｓｅｃ‐ｉｓａｋｍｐ‐ｏａｋｌｅｙ‐０８．ｔｘｔ
Ｍａｕｇｈａｎ，Ｄ．，Ｓｃｈｅｒｔｌｅｒ，Ｍ．，Ｓｃｈｎｅｉｄｅｒ，Ｍ．，およびＴｕｒｎｅｒ，Ｊ．，「インターネットのセキュリティ・アソシエーションおよびキー管理プロトコル（ＩＳＡＫＭＰ）」ｄｒａｆｔ‐ｉｅｔｆ‐ｉｐｓｅｃ‐ｉｓａｋｍｐ‐１０．｛ｐｓ，ｔｘｔ｝
Ｈ．Ｋ．Ｏｒｍａｎ，「ＯＡＫＬＥＹキーの決定プロトコル」、ｄｒａｆｔ‐ｉｅｔｆ‐ｉｐｓｅｃ‐ｏａｋｌｅｙ‐０２．ｔｘｔ
Ｐｉｐｅｒ，Ｄ．「ＩＳＡＫＭＰのための解釈のインターネットＩＰセキュリティ・ドメイン」ｄｒａｆｔ‐ｉｅｔｆ‐ｉｐｓｅｃ‐ｉｐｓｅｃ‐ｄｏｉ‐１０．ｔｘｔ
【００２４】
ポイント・ツー・ポイントのトンネリング・プロトコル（ＰＰＴＰ）およびレイヤー２のトンネリング・プロトコル（Ｌ２ＴＰ）は現在は「草案」の標準に過ぎないが、非常に近い将来においてインターネット・エンジニアリング・タスク・ホース（ＩＥＴＦ）によって公式の標準として認められると期待され、これらのプロトコルとインターネット・セキュリティ・プロトコル（ＩＰＳｅｃ）とが一緒になってこれらのＶＰＮの要求される機密保護に対する基礎を提供する。
【００２５】
再び図５を参照すると、クラスタ・メンバーの中の好適な実施形態は、メッセージ／セッションの作業ユニットのハッシュ・メンバーおよびその作業ユニットに対して割り当てられているクラスタ・メンバーｉｄを含む作業割当てテーブル５１５と；このクラスタ・メンバーに対するアプリケーションの状態テーブルを含むテーブル５１７と；このクラスタの他のメンバーに対する同様なアプリケーション状態テーブル５１９と；入力メッセージを含めるための領域５２１と；クラスタの他のメンバーからのデータ・メッセージを処理するためのデータ・ハンドラ・ルーチン５２３とを含む。当業者なら、各種の他のルーチンおよびメッセージの記憶をそのようなクラスタ・メンバーのメモリの中に実装して各種の機能およびアプリケーションを実行できることを理解することができるだろう。
【００２６】
このＩＰクラスタの好適な実施形態の一般的な動作が、（１）クラスタに加わるメンバーおよびクラスタから去るメンバーに対するプロセスを含むクラスタ設立（図６）；（２）マスタ・ユニットのイベント処理（図８〜図１３）およびクライアント・ユニットのイベント処理（図１４〜図１６）；（３）最後に、普通のメッセージ処理アクティビティ（図１７）に関して以下に説明される。
【００２７】
ここで図６を参照すると、クラスタ設立アクティビティが示されている。システムのスタートアップ６０１において、クラスタ・メンバーは「加入要求」を送信（同報通信）することによってクラスタに加わろうとする（６０３）。この「加入」メッセージは有効な認証機関から得られた認証証明書を含む。この「加入」メッセージを受け取ると、マスタ・ユニットはその証明書を自分が保持している有効な証明書のリストに対してチェックし、一致するものがなかった場合、その加入が失敗したことをそのクラスタ・メンバーに対して通知する。普通は、ハードウェア・ユニットを既存のクラスタに追加することをシステム管理者が計画するとき、システム管理者は自分のセキュリティ部門または既存のセキュリティ証明書発行機関がその新しいユニットに対して証明書を発行し、そのクラスタの中のマスタに対してその証明書のコピーを送信することを要求することに留意されたい。
【００２８】
このプロセスは誰かが安全保護されたメッセージを得るためにクラスタに対してユニットを違法に付加することができないことを保証する。マスタ・ユニットが、その加入メッセージからの証明書と自分のメモリの中に保持している証明書と一致するものを見つけた場合、「加入ＯＫ」メッセージを送信する。「加入ＯＫ」のメッセージがステップ６０５において受信された場合、このユニットはクラスタ・メンバー（クライアントまたは非マスタ）６０７と指定される。各クラスタ・メンバーはマスタ・ウォッチドッグ・タイマ（すなわち、そのメンバーがある期間、例えば、最近の２００ミリ秒以内の間にマスタから活性保持（ｋｅｅｐａｌｉｖｅ）メッセージを受け取ったかどうかを追跡管理するためのルーチン）を備えていて、そのタイマが時間切れになった場合、すなわち、その期間の間にクラスタからの活性保持メッセージがなかった場合、それはそのマスタ・ユニットが死んでいて（６０７）、そのクラスタ・メンバー／クライアントがそのクラスタに再び加入しようとしている（６１１）ことを意味することに留意されたい。
【００２９】
クラスタ・メンバー／クライアント６０７が再び加入しようとすることになるもう１つのイベントは、それが「脱出要求」メッセージ（すなわち、「そのクラスタを脱出せよ」と告げているメッセージ）６０９を受け取った場合である。その加入要求メッセージ（６０３）を送信しているメンバーが「加入ＯＫ」メッセージを受け取らなかった場合（６１３）、そのメンバーはマスタ・ユニットになることを申し出るパケットを送信（同報通信）する（６１５）。そのメンバーが「他のマスタが存在する」メッセージを受け取った場合（６１７）、そのメンバーは再び６０３において加入しようとする。そのメンバーがマスタになることを申し出るパケットを送信した後、１００ミリ秒の間に応答を受け取らなかった場合（６１９）、そのメンバーはアドレス・レゾリューション・プロトコル（ＡＲＰ）応答を同報通信して、そのネットワーク上のすべてのメンバーにクラスタのＩＰアドレスとしてどのイーサネット・アドレスを使用するかを知らせ（６２１）、それ以降そのクラスタのマスタ・ユニットとして動作する（６２３）。
【００３０】
このプロセスにおいて、そのクラスタ・メンバーが、別のマスタが存在していることの指示を受け取らなかった場合（６１７において）、そして自分が唯一のマスタ６２３であると考えたが、それにもかかわらず「クラスタを脱出せよ」のメッセージを受け取った場合（６４１）、そのメンバーは再び６４２において加入を試みるために戻らなければならない。これは、例えば、この新しいマスタの構成バージョンが正しくなかった場合に起こり得る。そのメンバーは戻って構成を更新し、再び加入を試みることになる。自分が新しいマスタ６２３であると思っているこのメンバーが「マスタ活性保持」メッセージ（別のクラスタ・メンバーが自分がマスタ・ユニットであると思っていることを示している）を受け取った場合（６２５）、そのメンバーはどういうわけでそのマスタ活性保持メッセージが自分からのものであったのかをチェックし（６２７）（普通はマスタは自分自身の活性保持メッセージを受け取らないが、それは起こり得る）、そうであった場合、そのメンバーはそのメッセージを６３９において単に無視する。
【００３１】
しかし、そのマスタ活性保持メッセージが自分以外からのものであった場合（６２９）、それは別のクラスタ・メンバーが自分がマスタ・ユニットであると思っていることを意味し、したがって、何とかしてこの「タイ（ｔｉｅ）」が解消されなければならない。（このタイを解消するプロセスは「マスタ・イベント」処理に関して以下にさらに詳細に説明される）。このタイが、自分がマスタであると考えている新しいクラスタ・メンバーに味方して解消された場合（６３５）そのメンバーは「他のマスタが存在する」メッセージを他のマスタに対して送信し、再びアドレス・レゾリューション・プロトコル（ＡＲＰ）応答を同報通信し、そのネットワーク上のすべてのメンバーに対してそのクラスタのＩＰアドレスとしてどのイーサネット・アドレスを使用するかを６３７において知らせる（他のマスタが同じことを行った可能性があるので）。自分がマスタであると思っているこの新しいクラスタ・メンバーがタイブレーカとならなかった場合（６３３）、そのメンバーはそのクラスタを安定化させようとして再び加入しなければならない。このプロセスによって、単独のクラスタ・メンバーがマスタ・ユニットとして動作し、他のクラスタ・メンバーは、自分達が単なるメンバーであることを理解することになる。
【００３２】
＜マスタ・ユニットのイベントの処理＞
クラスタが形成された後、マスタ・ユニットが対処しなければならない各種のイベントが発生している。この好適な実施形態においてそれらが処理される方法が図８〜図１３を参照して以下に説明される。図８を参照すると、最初のマスタ・ユニット・イベントは２つのクラスタ・メンバーが「マスタ」ユニットであると主張したときの「タイブレーカ」プロセスを示している。上記から、マスタは普通は自分自身の「活性保持」メッセージを受信せず、したがって、マスタが「マスタ活性保持」メッセージを受け取った場合（８０１）、それは別のクラスタ・メンバーが自分がマスタであると思っていることを意味する可能性がある。
【００３３】
この好適な実施形態の場合には、その「マスタ活性保持」メッセージは、クラスタ・メンバーのリストと、適応活性保持間隔（以下にさらに詳細に説明する）と、診断の目的のためだけに使用される各メンバーに対する作業割当ての現在のセットとを含む。したがって、マスタがマスタ活性保持メッセージを受け取ったとき（８０１）、そのマスタは先ず最初に「それは自分からのものか？」と尋ね（８０３）、そうであった場合、そのマスタはこのメッセージを単に無視し（８０７）、脱出する（８０８）。そのマスタ活性保持メッセージがこのマスタ・ユニットからのものでなかった場合（８０４）、「自分はこの他のマスタより多くのクラスタ・メンバーを有しているか？」と尋ねることによって（８０９）、「タイブレーカ」プロセスを開始する。そうであった場合、このマスタは「他のマスタが存在する」メッセージを送信し（８２５）、他のマスタに対してそのマスタが自分の役割を放棄してクラスタに再度加わるよう告げる。
【００３４】
残っているマスタが次に再びアドレス・レゾリューション・プロトコル（ＡＲＰ）応答を同報通信し、そのクラスタのＩＰアドレスとしてどのイーサネット・アドレスを使用するかをネットワーク上のすべてのメンバーに対して知らせ（８２７）、脱出する（８０８）。現在のマスタがこの他のマスタより多くのクラスタ・メンバーを有していなかった場合（８１１）、現在のマスタは「自分は他のマスタより少ないクラスタ・メンバーを有しているか？」と尋ね（８１３）、そうであった場合（８１６）、現在のマスタはクラスタから脱出することによって（８２１）、他のマスタに対してマスタの役割を返上し、メンバー／非マスタとして再加入し（８２３）、図６の６０１へ脱出しなければならない。
【００３５】
現在のマスタが他のマスタより所有しているメンバーの数が少なくなかった場合（８１５）（それは両方とも同じメンバーを有していることを意味する）、「自分のＩＰアドレスが彼のＩＰアドレスより小さいか？」と尋ねることによって（８１７）、最終のタイブレーカが発生し、そうであった場合、再びその現在のマスタがタイブレーカを勝ち取り（８１８）そして「他のマスタが存在する」メッセージを前と同様に送信する（８２５）。しかし、この最終のタイブレーカにならなかった場合（８１９）、現在のマスタはクラスタから脱出し、非クラスタ・メンバーとして再加入する（８２１）。
【００３６】
ここで図９を参照すると、マスタが「クライアントの活性保持メッセージ」（これは非マスタのクラスタ・メンバーからのものである）を受け取ったときに（８３０）、もう１つのマスタ・イベントが発生する。そのマスタは「このクライアントは自分のクラスタの中にあるか？」と尋ね（８３１）、そうでなかった場合、そのマスタはそのクライアントに「クラスタから脱出せよ」メッセージを送信し（８３３）、このクラスタから脱出するようそのクライアントに告げる。そのクライアントがこのマスタのクラスタからのものであった場合、そのマスタはそのクライアントの活性保持メッセージのシーケンス番号および計算された適応活性保持間隔を使用してパケット消失の平均値を計算し、格納する（８３５）。
【００３７】
そのマスタは次にこのクライアントに対するウォッチドッグ・タイマをリセットする（８３７）。ウォッチドッグ・タイマのルーチンはオペレーティング・システムのルーチンであり、それはタイマの値を定期的にチェックしてその値が最近リセットされて以来、フェイルオーバ検出間隔が経過しているかどうかを調べ、そうであった場合、そのウォッチドッグ・タイマは時間切れになったと言われ、次にシステムはその問題のクライアントがそのクラスタから離れたかのように反応し、そのクライアントの作業負荷を残りのクラスタ・メンバーに対して再割り当てする。
【００３８】
上で示されたように、マスタはそのクラスタのメンバー・リストと、適応活性保持間隔（これについては以下にさらに詳しく説明する）と、診断の目的のためだけに使用される各メンバーに対する現在の作業割当てのセットとを含むマスタ活性保持メッセージを定期的に送出する（図１０参照）。さらに、マスタは定期的に（この好適な実施形態の場合には、２秒ごとに）クラスタ・メンバーの負荷バランスをチェックする。
【００３９】
図１１において、タイマが時間切れになると（８５５）、マスタは負荷が最大であるクラスタ・メンバー（例えば［Ｋ］）と負荷が最小であるクラスタ・メンバー（例えば、「Ｊ」）との間の負荷の差を計算し（８５７）、次に「負荷が最大であるメンバー（Ｋ）から負荷が最小であるメンバー（Ｊ）へ１作業ユニットを移動すると何か影響があるか？」、すなわち、Ｋ＞ＪがＫ−１≧Ｊ−１であるかと尋ねる（８５９）。そうであった場合、マスタは負荷が最小であるメンバーをターゲット受領者として負荷が最大であるメンバーに対して「作業再割当て」要求を送信し、その後、マスタは再び負荷の数をチェックする（８６５）。作業ユニットを１つ動かした結果、負荷が最小であるメンバーが負荷が最大であるメンバーより負荷が少ない状態から変わらなかった場合（８６０）、そのマスタは再割当てを行わずに脱出する（８６１）。
【００４０】
クライアント／クラスタ・メンバーに対するウォッチドッグ・タイマが時間切れになったとき、もう１つのマスタ・イベントが発生し、そのマスタはそのクライアントをそのクラスタのデータ・リストから削除し、その削除されたユニットの作業が未割当ての作業のプールへ移り、次のメッセージが到着した場合と同様に普通に再割当てされる（図１２）参照。
【００４１】
ここで図１３を参照すると、マスタがクライアントの加入要求メッセージを受け取ったとき、もう１つのマスタ・イベントがこの好適な実施形態において発生する（８７５）。そのマスタは最初、そのクライアントに「操作進行中」の理由付きのＮＡＫを送信することによって、待つように告げる（８７７）。次に、マスタは存在しているアプリケーションに、１つのクライアントがそのクラスタに加入しようとしていることを、いくつかのアプリケーションがそれに関して知りたいので、通知する（８７９）。例えば、ＩＰＳｅｃがアプリケーションの１つであった場合、ＩＰＳｅｃはこのクライアントをクラスタに加入させることに同意する前に、このクラスタを検証することができる。どれかのアプリケーションがその加入要求をリジェクトした場合、マスタはその理由付きのＮＡＫを送信し（８５５）、脱出する。すべてのアプリケーションがその加入要求を認めた場合、マスタはＡＣＫを送信し、その加入が普通に進行する（８８７）。
【００４２】
＜クライアント・クラスタ・メンバーのイベント＞
非マスタのクラスタ・メンバー（クライアント）も活性保持メッセージを送信し、そのマスタに対するウォッチドッグ・タイマを監視しなければならない。ここで図１４を参照すると、クライアントがマスタの活性保持メッセージを受け取ったとき（８９０）、それは自分の適応活性保持間隔を更新し（８９１）、そしてクラスタ・メンバーのリストをチェックしてメンバーのどれかが失われたかどうかを調べる（８９３）。そうであった場合、このクライアントは自分のアプリケーションに対して、クラスタ・メンバーが離れたことを通知する（８９５）（例えば、ＩＰＳｅｃが知りたがっている）。また、そのクライアントはメンバーのうちのどれかがそのクラスタに追加されたかどうかをチェックして調べ（８９７）、そうであった場合、そのアプリケーションに通信し（８９８）、そして最後にそのマスタを監視するためのウォッチドッグ・タイマをリセットし（８９９）、脱出する。
【００４３】
各クライアントも周期的なタイマを備え、それはマスタによって送信されたネットワーク・パケットの消失値に対して適応するタイマであり、マスタはクライアントがクライアントの活性保持メッセージ（単調に増加する数値を含む）をマスタに対して周期的に送信することを要求する（図１５参照）。また、各クライアントは自分が監視しなければならないマスタのウォッチドッグ・タイマを備え、そのタイマが時間切れになった場合、クライアントはそのクラスタから脱出し、新しい加入メッセージを送信してそのクラスタに再度入らなければならない（図１６参照）。
【００４４】
＜通常のＩＰパケット処理＞
クラスタ・メンバーが自分に割り当てられた作業負荷だけを処理するようにするために、次の３つの方法のうちの１つが使用される。
１．そのマスタのＭＡＣアドレスがクラスタのＩＰアドレスに対して拘束される（ＡＲＰプロトコルを使用して）。そのマスタはフィルタリング機能（以下にさらに詳細に説明する）を適用して、その作業を分類し、各パケット（必要な場合）を適切なクラスタ・メンバーに対して転送する。
２．クラスタ全体にわたるユニキャストＭＡＣアドレスがそのクラスタのＩＰアドレスに対して拘束される（ＡＲＰプロトコルを使用して）。各クラスタ・メンバーは、このＭＡＣ宛先アドレスからのパケットを受け付けるようにそのネットワーク・インターフェースをプログラムする。これで各クラスタ・メンバーは、そのクラスタＩＰアドレス宛先を伴うすべてのパケットを見ることができる。各メンバーはそのフィルタリング関数を適用し、自分の作業負荷の部分でないパケットを捨てる。
３．方法２が使用されるが、ユニキャストのＭＡＣアドレスの代わりに、マルチキャストのＭＡＣアドレスで使用される。この方法はインテリジェントなパケット交換装置がそのネットワークの一部である時に必要である。これらの装置はユニキャストのＭＡＣ宛先アドレス付きのパケットを見るときに各ユニキャストＭＡＣアドレスにどのネットワーク・ポートが関連するかを学習し、そしてその交換装置がそのＭＡＣアドレスに関連するポート（１ポートだけが各ユニキャストＭＡＣアドレスに関連する）に対してのみそのパケットを送信する。マルチキャストのＭＡＣアドレスによって、パケット交換装置がクラスタのＩＰ宛先アドレスを伴うパケットをすべてのクラスタ・メンバーに対して配送するようになる。
【００４５】
この好適な実施形態の場合には、どのクラスタ・メンバーがメッセージを処理するかを指定するため、そして他のメンバーがその発信元のクライアントに対して「リセット」メッセージを間違って送信することなしにそのメッセージを捨てることができるようにするためのメカニズムがある。この好適な実施形態は、入力メッセージ・ヘッダのある種のフィールドを使用してハッシュ関数を計算する「フィルタ」プロセスを各クラスタ・メンバーの中で利用する。このハッシュ計算は作業ユニットの番号をメッセージに対して割り当てること、および作業ユニットを処理のために特定のクラスタ・メンバーに対して割り当てることの両方の手段として働く。この技法によってクラスタ・メンバーはその到来しているメッセージがそれにより処理されなければならないかどうかを知らせることができるようにし、したがって、間違った「リセット」メッセージの可能性が排除される。
【００４６】
「最小のオーバヘッドでクラスタの正しいメンバーに対してその作業をどのように割り当てるか」の問題に対する他の解決策は、ネットワークとクラスタとの間に介在しているハードウェア・フィルタ装置を含むことができ、そのハードウェア・フィルタがメンバーの割当ておよび負荷バランスの機能を行うことになることに留意されたい。すべてのクラスタ・メンバーが同じＭＡＣアドレスを備えているので、すべてのクラスタ・メンバーがすべてのメッセージを受け取り、それらがそのメッセージをさらに処理しなければならないかどうかを告げる方法が、上記のハッシングの方法を使用してその作業ユニットの番号を計算し、その結果の作業ユニット番号をそれぞれの作業負荷テーブルに対してチェックし、それがそれらに割り当てられているかどうかを調べることに留意されたい。これはそのユニットがそれ以上処理する必要がないメッセージをダンプするための高速且つ効率的な方式であり、しかもそれはクラスタ・メンバーが故障したときに負荷バランスおよび効率的なフェイルオーバ処理のための効率的なベースを提供する。
【００４７】
ＩＰパケットの通常の処理が図１７を参照して説明される。パケットの受信時（９０１）に、そのパケットがクラスタのＩＰアドレスに対して当てられているかどうかが決定される（９０３）。そうでなかった場合（９０５）、そのＩＰアドレスがこのクラスタ・メンバーに対するものであるかどうかが決定され、そうであった場合、それはＩＰスタックによってローカルに処理される（９０９）。そのパケットが転送されるべきである場合（ここではシステムはルータのように働く）（９０８）、その作業を分類するために転送フィルタが適用される（９１３）。これはそのパケットがそのクラスタのクライアントに対する普通の作業に対するものであるか、あるいは転送の作業であるかどうかを指定する。アドレスがクラスタのＩＰアドレスであるかどうかをチェックして調べるステップ９０３において、それがクラスタのＩＰアドレスであった場合、その答えはｙｅｓであり、同様な作業セット・フィルタが適用され（９１１）、その中でＩＰのソースおよび宛先アドレスがモジュロ１０２４でハッシュされて各種の目的に対して使用されるインデックス値が作られる。このインデックス値の計算（処理フィルタ）は、現在の実施形態において必要であり、次のようにより完全に説明される。
【００４８】
基本的に、ＩＰアドレス、ＩＰプロトコル、およびＴＣＰ／ＵＤＰポート番号を含むフィールド、そしてそのアプリケーションがＬ２ＴＰであった場合に、そのセッションおよびトンネルＩＤのフィールドがすべて一緒に加算（論理的ＸＯＲ）され、そして次にシフトされて０〜１０２３の範囲のユニークな「作業ユニット」番号が作られる。
例えば、この好適な実施形態の場合には、そのインデックスは次のように計算することができる。
【００４９】
／＊
＊  クラスタのフィルタリング関数の例
＊／
static int Cluster_Filtering_Function(void*Packet, int Forwarding)
｛
struct ip*ip=(struct ip*)Packet;
int i, length;
／＊
＊  このパケットを転送しているかどうかに基づいてフィルタリング方式を選択する。
＊／
if(Forwarding)｛
／＊
＊  ソースおよび宛先ＩＰアドレスについて転送されるパケットをフィルタする。
＊／
i=ip->ip_dst.s_addr;
i＾=ip->ip_src.s_addr;
｝else｛
／＊
＊  転送ではない：ＩＰのソース・アドレスに入れる。
＊／
i=ip->ip_src.s_addr;
／＊
＊  パケットのヘッダ長を獲得し、プロトコル上でディスパッチする。
＊／
length=ip->ip_hl<<2;
if(ip->ip_p==IPPROTO_UDP)｛
／＊
＊  ＵＤＰ：ＵＤＰのソース・ポートおよびソースＩＰアドレスについてハッシュする。
＊／
i＾=((struct udphdr*)((char*)ip+length))->uh_sport;
｝elseif(ip->ip_p)==IPPROTO_TCP)｛
／＊
＊  ＴＣＰのソース・ポートおよびソースＩＰアドレスについてハッシュする。
＊／
i＾=((struct tcphdr*)((char*)ip+length))->th_sport;
｝else｛
／＊
＊  他の任意のプロトコル：宛先およびソースのＩＰアドレスについてハッシュする。
＊／
i＾=ip->ip_dst.s_addr;
｝
｝
／＊
＊  それを作業セット番号に潰す。
＊／
return(IP_CLUSTER_HASH(i));
｝
【００５０】
再び図１７に戻って、作業セットのインデックス値が計算された状態で、この計算を行っている各メンバーは、そのインデックス値を間接的ポインタとして使用して、この作業セットに対してそれが自分の割り当てた作業セットであるかどうかを調べる（９１５，９１７）。このインデックス値が、この作業セットがこのクラスタ・メンバーに対して割り当てられていることを示さなかった場合、このクラスタ・メンバーはそのクラスタのマスタではない場合、そのパケットはこのクラスタ・メンバーによって単純にドロップされる（９２１，９２３，９２５）。
【００５１】
他方、このクラスタ・メンバーがマスタ・ユニットであった場合（９２６）、そのマスタはこの作業セットが処理のために他のクラスタ・メンバーの１つに対して割り当てられていたかどうかをチェックして調べなければならない（９２７）。これが別のクラスタ・メンバーに対して割り当てられていた場合（９２９）、マスタはそのクラスタ・メンバーがその割当ての受領を受信通知したかどうかをチェックして調べ、そうであった場合、マスタは自分がマルチキャスト・モードにあるか、ユニキャスト転送モードにあるかどうかをチェックして調べる（９３３，９３５）。自分がユニキャスト・モードまたはマルチキャスト・モードになっていた場合、そのマスタはそのパケットをドロップする。というのは、その割り当てられたクラスタ・メンバーがそれを見たことになるからである（９３６）。
【００５２】
しかし、そのマスタが転送モードになっていた場合、そのマスタは処理のために割り当てられたメンバーに対してそのパケットを転送する（９４３）。その割り当てられたクラスタ・メンバーがその割当ての受信をまだ受信通知していなかった場合（９４０）、その割当てを受信通知するまでそのパケットをセーブし（９４１）、そして次にそのパケットを処理するために自分に対して転送する（９４３）。この作業セットが割り当てられていたかどうかを９２７においてマスタがチェックして調べたとき、その答えがｎｏであった場合（９２８）、マスタはこの作業セットを負荷が最小であるメンバーに対して割り当て（９３７）、そして次に、その割り当てられたメンバーがその割当ての受信を上記のように受信通知するまで、その前のタスクを再開する（９３９）。作業がこのメンバーに対するものであった場合、そのパケットは局所ＴＣＰ／ＩＰスタックに対して渡される。
【００５３】
＜状態メンテナンス＞
ＲＦＣ  １１８０  Ａ  ＴＣＰ／ＩＰのチュートリアル、Ｔ．ソコロフスキーおよびＣ．ケール、１９９１年１月は、ＴＣＰ／ＩＰのプロトコル・スーツについて一般的に説明しており、全文を引用によって本明細書の記載に援用する。本発明においては、重要な要素はＴＣＰの状態をその状態の不可欠な部分と、その状態の計算可能な部分とに分けるための機能である。例えば、ＴＣＰメッセージの状態は絶えず変わり、したがって、クラスタ・メンバーがこのＴＣＰ状態のすべてを、その状態が変化するたびにそのクラスタの他のすべてのメンバーに対して転送するのは実際的ではない。これは非常に多くの量の記憶および処理時間を必要とし、本質的にそのクラスタのメンバーに対するトラヒックを倍加することになる。これらの入力メッセージの状態を維持するためのメンバー・ユニットの機能は、そのメッセージ・セッションの残りの部分を必要とせずにメンバー・ユニットの故障を扱うための機能にとって重要である。
【００５４】
図７はＴＣＰ状態の要素のうちで不可欠であると考えられ、したがって、それが変化するときにそのクラスタの各メンバーに対して転送されなければならない要素７０１と、不可欠な状態から計算可能であると考えられ、したがって、それが変化するときにクラスタのすべてのメンバーに対して転送される必要はない要素７０３についての好適な実施形態の定義を示している。この実施形態の中のＴＣＰフェイルオーバ状態７００は、実際には３つの部分を含み、それらはすべてのクラスタ・メンバーに対して一度だけ送られる必要がある初期状態の部分７０２；不可欠な部分の中にリストされている任意のアイテムが変化したときに格納するためにすべてのクラスタ・メンバーに対して送信されなければならない不可欠な状態の部分７０１；すべてのメンバーには送られない計算可能な状態の部分７０３である。各要素に対する等号（「＝」）の右にあるデータは、それが計算される必要がある時は常にその要素の値を計算する方法を示している。
【００５５】
＜フェイルオーバの処理＞
上記のように、ＩＰクラスタ装置および方法のこの好適な実施形態は、性能を最適化するようにクラスタの動作を管理するために、各クラスタ・メンバーの動作を監視するための機能も含む。これはどのＴＣＰ／ＩＰネットワークにおいても本来的であるパケット消失のためにクラスタ・メンバーが動作不能であることを宣言することを拒否するための妥当なプロセスを有する以外に、何らかの理由のためにクラスタ・メンバーが動作不能となったときに、そのことをクラスタ・システムが迅速に認識することを確保することを意味する。この監視プロセスは、この好適な実施形態の場合には、各非メンバー・クラスタ・メンバーが「マスタ・ウォッチドッグ・タイマ」をキープし、そしてマスタがすべてのクラスタ・メンバーに対する「クライアント・ウォッチドッグ・タイマ」をキープすることによる方法によって行われる。
【００５６】
これらのウォッチドッグ・タイマは、単なるルーチンであり、それによりそのクラスタ・メンバーのＯＳが定期的に「ウォッチドッグの時間値」をチェックして、それが現在の時刻より時間「ｔ」以上に早いかどうかをチェックする（すなわち、そのウォッチドッグ・タイマの時間値が最近の「ｔ」時間以内にリセットされているかどうかを調べる）。現在の時刻とウォッチドッグ・タイマの時刻値との間の差が時間「ｔ」より大きいことをそのルーチンが発見した場合、そのウォッチドッグ・タイマに関連するクラスタ・メンバーが動作不能であることを宣言する。これらのウォッチドッグ・タイマの時間値は、クラスタ・メンバーが「活性保持」パケット（「心搏」メッセージと呼ばれることもある）を他のメンバーに対して送信するときは常にリセットされる。
【００５７】
一般に「活性保持」メッセージは、１つのネットワーク装置によって送信され、別のネットワーク装置に対して、その２つの間の仮想回路がまだ生きていることを知らせるメッセージである。この好適な実施形態の場合には、マスタ・ユニットはクラスタ・メンバーのリストと、「適応活性保持間隔」とすべてのメンバーに対する作業割当ての現在のセットとを含む「マスタ活性保持」パケットを送信する。非マスタのクラスタ・メンバーは、マスタのウォッチドッグ・タイマを監視し、そのマスタがまだ生きていることを確認し、そしてそのマスタによって供給されている「適応活性保持間隔」の値を使用して、マスタがクラスタ内での自分たちの存在を監視することができるように、どの程度の頻度でそれぞれの「クライアント活性保持」パケットをそれぞれ（非マスタのクラスタ・メンバー）が送信しなければならないかを決定する。「クライアント活性保持」パケットは単調に増加するシーケンス番号を含み、それはそのシステムにおいてパケットの消失を測定し、適応活性保持間隔を調整するために使用されるパケット消失の確率値を調整するために使用される。一般に、これらの計算は、この好適な実施形態の場合には、以下のように行われる。しかし、パケットの消失および関連するウォッチドッグ・タイマの値の等価な対策を実施するために各種のプログラミングおよび論理回路のプロセスを使用することができることは、当業者なら理解することができるだろう。
【００５８】
各クライアントは、その「クライアント活性保持」パケットの中にシーケンス番号を含む。マスタがクライアント「ｘ」に対するこの活性保持パケットを受け取ったとき、マスタは次の計算を行う。
ＳΔ＝［このシーケンス番号］−［最後のシーケンス番号］−１
この値ＳΔは、通常、０または１であり、最近の２つの活性保持メッセージの間にドロップしたパケットの数、すなわち、クライアント「ｘ」に対する現在のパケット消失を表す。
【００５９】
次に、この値が指数関数的スムージングの式において使用されて現在の平均のパケット消失「Ｐ」が次のように計算される。
Ｐｎｅｗ＝Ｐｏｌｄ×［１２７／１２８］＋ＳΔ×［１／１２８］
このＰｎｅｗは消失パケットの確率を表し、
Ｐｎ（Ｐのｎ乗）は、「ｎ」個の次々のパケットが消失する確率を表す。そして１／Ｐｎは、１つのロウの中で「ｎ」個のパケットが消失する頻度である。
【００６０】
したがって、「ｎ」は１つの間隔当たりに消失するパケットの数として定義され、Ｐｎは、その時「ｎ」のパケットを１つの間隔において失う確率である。明らかに与えられた間隔においてある数以上のパケットが消失する場合、そのクラスタ・メンバーは不具合であるか、動作不能であるか、あるいはそのネットワークに問題があるかのいずれかである。この好適な実施形態の場合には、「ｎ」は２から２０までの数値であると仮定し、その値を以下のように適応的に計算する。
【００６１】
その間隔を「Ｋ」と呼び、１／Ｋ＝ｎＰｎと設定する。ポリシーによって、Ｋ＝３６００（これは１週間の期間に等価である）と設定し、次に、ｎＰｎ＜１／３６００である「ｎ」の最小の整数値を計算する。この好適な実施形態の場合には、これは、ｎ＝２として計算を開始し、ｎを１だけ増加しながら、その条件が満足されるまで繰り返す。その結果の値の「ｎ」が適応活性保持間隔であり、それをマスタがすべてのクラスタ・メンバーに対して送信し、クラスタ・メンバーがそれぞれの「クライアント活性保持」メッセージを送信する頻度を求める際に使用される。
【００６２】
これまで本発明を好適な実施形態に関して説明してきたが、各種のタイプの汎用コンピュータのハードウェアを、上記の構成に対して置き換えて等価な結果を得ることができることは、当業者なら理解することができるだろう。同様に、演算回路がインターネットのセキュリティ・プロトコルおよびトンネリング・プロトコルを処理するため、マスタ・ユニットが入力メッセージに対する処理の割当てを適応的に分配することを許すため、およびどのメッセージを自分が処理すべきかをクラスタ・メンバーが認識できるようにするため、およびクラスタの中の他のメンバーからのメッセージを認識するために、特許請求の範囲の中で必要とされる各手段を実行するように構成されることを理解されたい。当業者なら、以下の特許請求の範囲によって判断されるような本発明の真の精神および範囲内にある、この好適な実施形態の変更および変形が可能であることを理解されたい。
【図面の簡単な説明】
【図１】  代表的なインターネットのネットワーク構成を示す。
【図２】  代表的な汎用のコンピュータ／クラスタ・メンバーの構成を示す。
【図３】  関連フラッシュ・メモリ・カード上に含まれているデータの代表的なメモリ・マップを示す。
【図４】  代表的なＩＰネットワーク・クラスタを示す。
【図５】  トンネル・サーバとして働いているクラスタ・メンバーの好適な実施形態の一般的なメモリ・マップを示す。
【図６】  クラスタ確立プロセスを示しているクラスタの一般的な動作のフローチャートを示す。
【図７】  例示としてのＴＣＰ状態データ構造を示す。
【図８】  マスタが処理するイベントおよびマスタでないクラスタ・メンバー（クライアント）が処理しなければならないイベントを示しているフローチャートを示す。
【図９】  マスタが処理するイベントおよびマスタでないクラスタ・メンバー（クライアント）が処理しなければならないイベントを示しているフローチャートを示す。
【図１０】  マスタが処理するイベントおよびマスタでないクラスタ・メンバー（クライアント）が処理しなければならないイベントを示しているフローチャートを示す。
【図１１】  マスタが処理するイベントおよびマスタでないクラスタ・メンバー（クライアント）が処理しなければならないイベントを示しているフローチャートを示す。
【図１２】  マスタが処理するイベントおよびマスタでないクラスタ・メンバー（クライアント）が処理しなければならないイベントを示しているフローチャートを示す。
【図１３】  マスタが処理するイベントおよびマスタでないクラスタ・メンバー（クライアント）が処理しなければならないイベントを示しているフローチャートを示す。
【図１４】  マスタが処理するイベントおよびマスタでないクラスタ・メンバー（クライアント）が処理しなければならないイベントを示しているフローチャートを示す。
【図１５】  マスタが処理するイベントおよびマスタでないクラスタ・メンバー（クライアント）が処理しなければならないイベントを示しているフローチャートを示す。
【図１６】  マスタが処理するイベントおよびマスタでないクラスタ・メンバー（クライアント）が処理しなければならないイベントを示しているフローチャートを示す。
【図１７】  クラスタを確立した後の普通のパケット処理プロセスを示しているフローチャートを示す。
【図１】
0004420420.tif 000002
【図２】
0004420420.tif 000003
【図３】
0004420420.tif 000004
【図４】
0004420420.tif 000005
【図５】
0004420420.tif 000006
【図６】
0004420420.tif 000007
【図７】
0004420420.tif 000008
【図８】
0004420420.tif 000009
【図８Ｂ】
0004420420.tif 000010
【図８Ｃ】
0004420420.tif 000011
【図８Ｄ】
0004420420.tif 000012
【図８Ｅ】
0004420420.tif 000013
【図８Ｈ】
0004420420.tif 000014
【図８Ｆ】
0004420420.tif 000015
【図８Ｇ】
0004420420.tif 000016
【図８Ｉ】
0004420420.tif 000017
【図９】
0004420420.tif 000018
【図１０】
0004420420.tif 000019
【図１１】
0004420420.tif 000020
【図１２】
0004420420.tif 000021
【図１３】
0004420420.tif 000022
【図１４】
0004420420.tif 000023
【図１５】
0004420420.tif 000024
【図１６】
0004420420.tif 000025
【図１７】
0004420420.tif 000026