JP4458289B2 - クラスタシステム、クラスタメンバ、故障復旧方法及びプログラム - Google Patents
クラスタシステム、クラスタメンバ、故障復旧方法及びプログラム Download PDFInfo
- Publication number
- JP4458289B2 JP4458289B2 JP2005516288A JP2005516288A JP4458289B2 JP 4458289 B2 JP4458289 B2 JP 4458289B2 JP 2005516288 A JP2005516288 A JP 2005516288A JP 2005516288 A JP2005516288 A JP 2005516288A JP 4458289 B2 JP4458289 B2 JP 4458289B2
- Authority
- JP
- Japan
- Prior art keywords
- processing
- packet
- session
- cluster
- sub
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/40—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Computer And Data Communications (AREA)
Description
本発明は、ＩＰパケットを転送するルータとして機能するクラスタシステムに関し、特に、クラスタメンバ間でセッション情報を交換し合わなくとも、故障復旧処理を行うことができるクラスタシステムに関する。
ＩＰ網に設置されるルータには、ＩＰ層の上位層の情報を参照して処理を行う装置がある。たとえば、不正アクセス遮断等に用いられるファイアウォール装置や、ＩＰｓｅｃトンネルを終端するＶＰＮゲートウエイ装置などである。
これらの装置では、通過するパケットが属する上位層のセッションを識別し、識別したセッションの状態に応じてパケットを処理する必要がある。これらの装置は、パケットが通過するたびに、セッションの識別と状態の参照・更新を行うため、処理にかかる計算量が非常に大きくなる。このため、装置を複数台用意して負荷を分散させる技術（ルータクラスタ）が開発されてきた。
負荷分散を行うルータクラスタとしては、例えば、図２０に示す構成を有するものが考えられる。同図に示すルータクラスタは、セッション処理部を有する複数台のルータ装置１０１〜１０ｎと、それらの手前に設置されたパケット振り分け装置１１０とから構成される。パケット振り分け装置１１０は、外部から入力されたパケットを、所定の負荷分散規則に従って、ルータ１００〜１０ｎの内の何れかに振り分けることにより、負荷分散を実現している。
しかし、この図２０に示したルータクラスタは、パケット振り分け装置１１０に負荷が集中するという問題があると共に、パケット振り分け装置１１０に障害が発生した場合、システム全体が麻痺してしまうという問題がある。
そこで、このような問題を解決するため、図２１に示すようなルータクラスタが提案された（例えば、特表２００３−５１７２２１、特表２００３−５１８３３８参照）。
図２１に示した従来のルータクラスタは、１台のマスタールータ装置２００と、複数台のルータ装置（スレーブルータ装置）２０１〜２０ｎとを備えている。各ルータ装置２００〜２０ｎは、セッション処理部と、トラフィック分散フィルタとを備えている。
隣接ノード２１０からルータクラスタへのＩＰパケット（単に、パケットと記す場合もある）は、データリンク層プロトコルでのマルチキャストにより、全ルータ装置２００〜２０ｎで受信される。各ルータ装置２００〜２０ｎ内のトラフィック分散フィルタは、データリンク２２０上でマルチキャストされたＩＰパケットを、トラフィック分散規則に従って、通過或いは廃棄する。
ここで、各ルータ装置２００〜２０ｎが備えているトラフィック分散フィルタのトラフィック分散規則は、次の条件を満たしている。
・同一のパケットが複数のルータ装置内のトラフィック分散フィルタを通過することはない。
・パケットは必ずいずれかのルータ装置内のトラフィック分散フィルタを通過する
各ルータ装置２０１〜２０ｎ内のトラフィック分散フィルタのトラフィック分散規則は、マスタールータ装置２００により設定されるものであり、マスタールータ装置２００は他のルータ装置２０１〜２０ｎ内のトラフィック分散フィルタにどのようなトラフィック分散規則が設定されているのかを把握しており、各ルータ装置２０１〜２０ｎの負荷が均等分散されるように、トラフィック分散規則を設定する。また、マスタールータ装置２００は、トラフィック分散規則に当てはまらないパケットを処理するようなトラフィック分散フィルタを自装置内に備えている。また、マスタールータ装置２００は、処理したパケットのセッション情報から新たなトラフィック分散規則を生成した他のルータ装置２０１〜２０ｎのトラフィック分散フィルタに設定する。なお、マスタールータ装置２００に障害が発生した場合には、他のルータ装置２０１〜２０ｎの何れか１台がマスタールータ装置として動作する。
また、各ルータ装置２００〜２０ｎ内のセッション処理部は、その内部に設定されているセッション処理規則とセッション状態を参照して、パケット分散フィルタを通過してきたパケットを処理し、破棄または転送させる。
各ルータ装置２０１〜２０ｎ内のセッション処理部のセッション処理規則は、マスタールータ装置２００によって設定されるものである。マスタールータ装置２００を含む各ルータ装置２００〜２０ｎは、互いに自身のセッション状態を示すセッション情報を交換し合う。このセッション情報の交換は、一定時間毎に行われ、各ルータ装置２００〜２０ｎは、他のルータ装置のセッション処理規則と交換した他のルータ装置の最新のセッション状態とを保持する。従って、ルータ装置２０１〜２０ｎの何れかに故障が発生した場合、マスタールータ装置２００において、代替する装置を決定し、故障したルータ装置に設定されていた処理規則及びセッション状態を該当装置に引き継がせるという処理を行うことが可能になる。また、マスタールータ装置２００に故障が発生した場合、他のルータ装置がマスタールータ装置２００の処理を引き継ぐことが可能になる。このように、図２１に示したルータクラスタによれば、ルータクラスタを構成するどのルータ装置２００〜２０ｎに障害が発生した場合であっても、自動復旧することが可能になる。
しかしながら、図２１に示した従来のルータクラスタには、次のような課題がある。すなわち、各ルータ装置２０１〜２０ｎのセッション状態は、マスタールータ装置２００に一定の間隔で伝達されるため、マスタールータ装置２００が把握する他のルータ装置２０１〜２０ｎのセッション状態と各ルータ装置２０１〜２０ｎが保持するセッション状態の間に差があることがある。この差により、代替装置の用意により自動故障回復（ｆａｉｌｏｖｅｒ）が行われても、本来処理できないパケットを処理してしまったり、また処理できるはずのパケットが処理できなくなることがある。上記差をなくすため、セッション情報の交換間隔を短くすると、セッション情報の交換にかかる通信量が増えるため、情報交換の負荷が増大する。また、ルータ装置数が増加しても通信の負荷が増大する。これにより、従来のルータクラスタでは、ルータ装置数の増強とｆａｉｌｏｖｅｒ時間の短縮を同時に実現することはできず、スケーラビリティの点で大きな問題が存在した。
これらの装置では、通過するパケットが属する上位層のセッションを識別し、識別したセッションの状態に応じてパケットを処理する必要がある。これらの装置は、パケットが通過するたびに、セッションの識別と状態の参照・更新を行うため、処理にかかる計算量が非常に大きくなる。このため、装置を複数台用意して負荷を分散させる技術（ルータクラスタ）が開発されてきた。
負荷分散を行うルータクラスタとしては、例えば、図２０に示す構成を有するものが考えられる。同図に示すルータクラスタは、セッション処理部を有する複数台のルータ装置１０１〜１０ｎと、それらの手前に設置されたパケット振り分け装置１１０とから構成される。パケット振り分け装置１１０は、外部から入力されたパケットを、所定の負荷分散規則に従って、ルータ１００〜１０ｎの内の何れかに振り分けることにより、負荷分散を実現している。
しかし、この図２０に示したルータクラスタは、パケット振り分け装置１１０に負荷が集中するという問題があると共に、パケット振り分け装置１１０に障害が発生した場合、システム全体が麻痺してしまうという問題がある。
そこで、このような問題を解決するため、図２１に示すようなルータクラスタが提案された（例えば、特表２００３−５１７２２１、特表２００３−５１８３３８参照）。
図２１に示した従来のルータクラスタは、１台のマスタールータ装置２００と、複数台のルータ装置（スレーブルータ装置）２０１〜２０ｎとを備えている。各ルータ装置２００〜２０ｎは、セッション処理部と、トラフィック分散フィルタとを備えている。
隣接ノード２１０からルータクラスタへのＩＰパケット（単に、パケットと記す場合もある）は、データリンク層プロトコルでのマルチキャストにより、全ルータ装置２００〜２０ｎで受信される。各ルータ装置２００〜２０ｎ内のトラフィック分散フィルタは、データリンク２２０上でマルチキャストされたＩＰパケットを、トラフィック分散規則に従って、通過或いは廃棄する。
ここで、各ルータ装置２００〜２０ｎが備えているトラフィック分散フィルタのトラフィック分散規則は、次の条件を満たしている。
・同一のパケットが複数のルータ装置内のトラフィック分散フィルタを通過することはない。
・パケットは必ずいずれかのルータ装置内のトラフィック分散フィルタを通過する
各ルータ装置２０１〜２０ｎ内のトラフィック分散フィルタのトラフィック分散規則は、マスタールータ装置２００により設定されるものであり、マスタールータ装置２００は他のルータ装置２０１〜２０ｎ内のトラフィック分散フィルタにどのようなトラフィック分散規則が設定されているのかを把握しており、各ルータ装置２０１〜２０ｎの負荷が均等分散されるように、トラフィック分散規則を設定する。また、マスタールータ装置２００は、トラフィック分散規則に当てはまらないパケットを処理するようなトラフィック分散フィルタを自装置内に備えている。また、マスタールータ装置２００は、処理したパケットのセッション情報から新たなトラフィック分散規則を生成した他のルータ装置２０１〜２０ｎのトラフィック分散フィルタに設定する。なお、マスタールータ装置２００に障害が発生した場合には、他のルータ装置２０１〜２０ｎの何れか１台がマスタールータ装置として動作する。
また、各ルータ装置２００〜２０ｎ内のセッション処理部は、その内部に設定されているセッション処理規則とセッション状態を参照して、パケット分散フィルタを通過してきたパケットを処理し、破棄または転送させる。
各ルータ装置２０１〜２０ｎ内のセッション処理部のセッション処理規則は、マスタールータ装置２００によって設定されるものである。マスタールータ装置２００を含む各ルータ装置２００〜２０ｎは、互いに自身のセッション状態を示すセッション情報を交換し合う。このセッション情報の交換は、一定時間毎に行われ、各ルータ装置２００〜２０ｎは、他のルータ装置のセッション処理規則と交換した他のルータ装置の最新のセッション状態とを保持する。従って、ルータ装置２０１〜２０ｎの何れかに故障が発生した場合、マスタールータ装置２００において、代替する装置を決定し、故障したルータ装置に設定されていた処理規則及びセッション状態を該当装置に引き継がせるという処理を行うことが可能になる。また、マスタールータ装置２００に故障が発生した場合、他のルータ装置がマスタールータ装置２００の処理を引き継ぐことが可能になる。このように、図２１に示したルータクラスタによれば、ルータクラスタを構成するどのルータ装置２００〜２０ｎに障害が発生した場合であっても、自動復旧することが可能になる。
しかしながら、図２１に示した従来のルータクラスタには、次のような課題がある。すなわち、各ルータ装置２０１〜２０ｎのセッション状態は、マスタールータ装置２００に一定の間隔で伝達されるため、マスタールータ装置２００が把握する他のルータ装置２０１〜２０ｎのセッション状態と各ルータ装置２０１〜２０ｎが保持するセッション状態の間に差があることがある。この差により、代替装置の用意により自動故障回復（ｆａｉｌｏｖｅｒ）が行われても、本来処理できないパケットを処理してしまったり、また処理できるはずのパケットが処理できなくなることがある。上記差をなくすため、セッション情報の交換間隔を短くすると、セッション情報の交換にかかる通信量が増えるため、情報交換の負荷が増大する。また、ルータ装置数が増加しても通信の負荷が増大する。これにより、従来のルータクラスタでは、ルータ装置数の増強とｆａｉｌｏｖｅｒ時間の短縮を同時に実現することはできず、スケーラビリティの点で大きな問題が存在した。
そこで、本発明の目的は、セッション情報をクラスタメンバ間で交換し合うことなく、故障復旧処理を行えるようにすることにある。
本発明にかかる第１のクラスタシステムは、上記目的を達成するため、
複数のクラスタメンバから構成されるクラスタシステムにおいて、
前記各クラスタメンバが、
所定の範囲決定ルールに従って自クラスタメンバが担当する主処理の範囲を示す主処理範囲および副処理の範囲を示す副処理範囲を決定し、前記クラスタシステムに入力されたパケットの内の、前記主処理範囲にマッチするパケットについては、そのパケットが属するセッションの状態を示すセッション情報の記録更新処理を含むセッション処理とパケット転送処理とを行い、前記決定した副処理範囲にマッチするパケットについては、そのパケットが属するセッションの状態を示すセッション情報の記録更新処理を含むセッション処理を行い、自クラスタメンバが副処理を担当しているパケットに対する主処理を担当しているクラスタメンバに故障が発生したとき、前記故障の発生したクラスタメンバが主処理を担当していたパケットの主処理を、前記記録してあるセッション情報を利用して引き継ぐ構成を有することを特徴とする。
より具体的には、本発明にかかる第２のクラスタシステムは、
複数のクラスタメンバから構成されるクラスタシステムにおいて、
前記各クラスタメンバが、
所定の範囲決定ルールと前記クラスタシステムを構成するクラスタメンバ数とに基づいて、自クラスタメンバが担当する主処理の範囲を示す主処理範囲および副処理の範囲を示す副処理範囲を決定する分散処理制御部と、
前記クラスタシステムに入力されたパケットの内、前記分散処理制御部で決定された主処理範囲または副処理範囲にマッチするパケットを通過させるトラフィック分散フィルタと、
パケットが属するセッションの状態を示すセッション情報が格納されるセッション情報保持部と、
前記トラフィック分散フィルタを通過したパケットの内の、前記主処理範囲にマッチしたパケットについては、前記セッション情報保持部に格納されている前記パケットのセッション情報の更新処理を含むセッション処理を実行すると共にパケット出力処理を実行し、前記副処理範囲にマッチしたパケットについては、前記セッション情報保持部に格納されている前記パケットのセッション情報の更新処理を含むセッション処理を実行すると共にパケット破棄処理を実行するセッション処理部と、
該セッション処理部から出力されたパケットの転送処理を行うパケット転送部と、
自クラスタメンバが副処理を担当しているパケットに対する主処理を担当しているクラスタメンバに故障が発生したとき、前記副処理範囲を主処理範囲に変更する故障復旧部とを備えたことを特徴とする。
本発明にかかる第３のクラスタシステムは、各クラスタメンバ間でセッション情報を交換し合わなくとも、故障クラスタメンバの発生時や、新規クラスタメンバの追加時に、各クラスタメンバが担当する主処理範囲や副処理範囲を変更できるようにするため、第２のクラスタシステムにおいて、
前記分散処理制御部が、他のクラスタメンバにおいて故障が発生したとき、及びクラスタシステムに新たなクラスタメンバが追加されたとき、前記範囲決定ルールとクラスタメンバ数とに基づいて新たな主処理範囲および副処理範囲を決定し、それまでの主処理範囲および副処理範囲を旧主処理範囲および旧副処理範囲とする構成を有し、
前記トラフィック分散フィルタが、前記クラスタシステムに入力されたパケットの内、前記新たな主処理範囲、前記新たな副処理範囲、前記旧主処理範囲または前記旧副処理範囲にマッチするパケットを通過させる構成を有し、
前記セッション処理部が、前記トラフィック分散フィルタを通過したパケットの内、前記新たな主処理範囲にマッチしたパケットについては、そのパケットがセッションの開設を要求するパケットであること、或いは前記セッション情報保持部に前記パケットのセッション情報が格納されていることを条件にして、前記セッション情報保持部に格納されている前記パケットのセッション情報の更新処理を含むセッション処理を実行すると共にパケット出力処理を実行し、前記旧主処理範囲のみにマッチしたパケットについては、そのパケットがセッションの開設を要求するパケットである場合には破棄し、そうでない場合には前記セッション情報保持部に前記パケットのセッション情報が格納されていることを条件にして、前記セッション情報保持部に格納されている前記パケットのセッション情報の更新処理を含むセッション処理を実行すると共にパケット出力処理を実行し、前記新たな副処理範囲のみにマッチしたパケットについては、そのパケットがセッションの開設を要求するパケットであること、或いは前記セッション情報保持部に前記パケットのセッション情報が格納されていることを条件にして、前記セッション情報保持部に格納されている前記パケットのセッション情報の更新処理を含むセッション処理を実行すると共にパケット破棄処理を実行し、前記旧副処理範囲のみにマッチしたパケットについては、そのパケットがセッションの開設を要求するパケットである場合には廃棄し、そうでない場合には、前記セッション情報保持部に前記パケットのセッション情報が格納されていることを条件にして、前記セッション情報保持部に格納されている前記パケットのセッション情報の更新処理を含むセッション処理を実行すると共にパケット破棄処理を実行し、前記旧副処理範囲と前記副処理範囲との両方にマッチしたパケットについては、そのパケットがセッションの開設を要求するパケットである場合には、前記セッション情報保持部に格納されている前記パケットのセッション情報の更新処理を含むセッション処理を実行すると共にパケット破棄処理を実行し、そうでない場合は、前記セッション情報保持部に前記パケットのセッション情報が格納されていることを条件にして前記セッション情報保持部に格納されている前記パケットのセッション情報の更新処理を含むセッション処理を実行すると共にパケット出力処理を実行する構成を有することを特徴とする。
また、本発明にかかる第４のクラスタシステムは、第３のクラスタシステムにおいて、
前記各クラスタメンバが、
前記クラスタシステム中のクラスタメンバの識別子が格納されたクラスタメンバリストと、
クラスタメンバ毎の死活監視タイマと、
所定時間毎に自クラスタメンバの識別子を含む広告メッセージを他のクラスタメンバに対して送信すると共に、他のクラスタメンバからの広告メッセージを受信したとき、該広告メッセージの送信元のクラスタメンバに対応する死活監視タイマをリセットする広告メッセージ処理部とを備え、
前記分散処理制御部が、
タイムアウトした死活監視タイマが発生したとき、該タイムアウトした死活監視タイマに対応するクラスタメンバに障害が発生したと認識する構成を有することを特徴とするクラスタシステム。
本発明にかかる第５のクラスタシステムは、第４のクラスタシステムにおいて、
前記分散処理制御部が、
前記広告メッセージ処理部で受信した広告メッセージ中の識別子が前記クラスタメンバリストに含まれていなかった場合、前記識別子のクラスタメンバが追加されたと認識する構成を有することを特徴とする。
本発明にかかる第１のクラスタメンバは、セッション情報をクラスタメンバ間で交換し合うことなく、故障復旧処理を行えるようにするため、
所定の範囲決定ルールに従って自クラスタメンバが担当する主処理の範囲を示す主処理範囲および副処理の範囲を示す副処理範囲を決定し、自クラスタメンバを構成要素とするクラスタシステムに入力されたパケットの内の、前記主処理範囲にマッチするパケットについては、そのパケットが属するセッションの状態を示すセッション情報の記録更新処理を含むセッション処理とパケット転送処理とを行い、前記決定した副処理範囲にマッチするパケットについては、そのパケットが属するセッションの状態を示すセッション情報の記録更新処理を含むセッション処理を行い、自クラスタメンバが副処理を担当しているパケットに対する主処理を担当しているクラスタメンバに故障が発生したとき、前記故障の発生したクラスタメンバが主処理を担当していたパケットの主処理を、前記記録してあるセッション情報を利用して引き継ぐ構成を有することを特徴とする。
本発明にかかる第１の故障復旧方法は、セッション情報をクラスタメンバ間で交換し合うことなく、故障復旧処理を行えるようにするため、
複数のクラスタメンバから構成されるクラスタシステムの故障復旧方法において、
前記各クラスタメンバが、
所定の範囲決定ルールに従って自クラスタメンバが担当する主処理の範囲を示す主処理範囲および副処理の範囲を示す副処理範囲を決定し、前記クラスタシステムに入力されたパケットの内の、前記主処理範囲にマッチするパケットについては、そのパケットが属するセッションの状態を示すセッション情報の記録更新処理を含むセッション処理とパケット転送処理とを行い、前記決定した副処理範囲にマッチするパケットについては、そのパケットが属するセッションの状態を示すセッション情報の記録更新処理を含むセッション処理を行い、自クラスタメンバが副処理を担当しているパケットに対する主処理を担当しているクラスタメンバに故障が発生したとき、前記故障の発生したクラスタメンバが主処理を担当していたパケットの主処理を、前記記録してあるセッション情報を利用して引き継ぐことを特徴とする。
本発明にかかる第１のプログラムは、セッション情報をクラスタメンバ間で交換し合うことなく、故障復旧処理を行えるようにするため、
コンピュータをクラスタメンバとして機能させるためのプログラムであって、
前記コンピュータを、
所定の範囲決定ルールに従って自クラスタメンバが担当する主処理の範囲を示す主処理範囲および副処理の範囲を示す副処理範囲を決定し、自クラスタメンバを構成要素とするクラスタシステムに入力されたパケットの内の、前記主処理範囲にマッチするパケットについては、そのパケットが属するセッションの状態を示すセッション情報の記録更新処理を含むセッション処理とパケット転送処理とを行い、前記決定した副処理範囲にマッチするパケットについては、そのパケットが属するセッションの状態を示すセッション情報の記録更新処理を含むセッション処理を行い、自クラスタメンバが副処理を担当しているパケットに対する主処理を担当しているクラスタメンバに故障が発生したとき、前記故障の発生したクラスタメンバが主処理を担当していたパケットの主処理を、前記記録してあるセッション情報を利用して引き継ぐ手段として機能させる。
本発明にかかる第１のクラスタシステムは、上記目的を達成するため、
複数のクラスタメンバから構成されるクラスタシステムにおいて、
前記各クラスタメンバが、
所定の範囲決定ルールに従って自クラスタメンバが担当する主処理の範囲を示す主処理範囲および副処理の範囲を示す副処理範囲を決定し、前記クラスタシステムに入力されたパケットの内の、前記主処理範囲にマッチするパケットについては、そのパケットが属するセッションの状態を示すセッション情報の記録更新処理を含むセッション処理とパケット転送処理とを行い、前記決定した副処理範囲にマッチするパケットについては、そのパケットが属するセッションの状態を示すセッション情報の記録更新処理を含むセッション処理を行い、自クラスタメンバが副処理を担当しているパケットに対する主処理を担当しているクラスタメンバに故障が発生したとき、前記故障の発生したクラスタメンバが主処理を担当していたパケットの主処理を、前記記録してあるセッション情報を利用して引き継ぐ構成を有することを特徴とする。
より具体的には、本発明にかかる第２のクラスタシステムは、
複数のクラスタメンバから構成されるクラスタシステムにおいて、
前記各クラスタメンバが、
所定の範囲決定ルールと前記クラスタシステムを構成するクラスタメンバ数とに基づいて、自クラスタメンバが担当する主処理の範囲を示す主処理範囲および副処理の範囲を示す副処理範囲を決定する分散処理制御部と、
前記クラスタシステムに入力されたパケットの内、前記分散処理制御部で決定された主処理範囲または副処理範囲にマッチするパケットを通過させるトラフィック分散フィルタと、
パケットが属するセッションの状態を示すセッション情報が格納されるセッション情報保持部と、
前記トラフィック分散フィルタを通過したパケットの内の、前記主処理範囲にマッチしたパケットについては、前記セッション情報保持部に格納されている前記パケットのセッション情報の更新処理を含むセッション処理を実行すると共にパケット出力処理を実行し、前記副処理範囲にマッチしたパケットについては、前記セッション情報保持部に格納されている前記パケットのセッション情報の更新処理を含むセッション処理を実行すると共にパケット破棄処理を実行するセッション処理部と、
該セッション処理部から出力されたパケットの転送処理を行うパケット転送部と、
自クラスタメンバが副処理を担当しているパケットに対する主処理を担当しているクラスタメンバに故障が発生したとき、前記副処理範囲を主処理範囲に変更する故障復旧部とを備えたことを特徴とする。
本発明にかかる第３のクラスタシステムは、各クラスタメンバ間でセッション情報を交換し合わなくとも、故障クラスタメンバの発生時や、新規クラスタメンバの追加時に、各クラスタメンバが担当する主処理範囲や副処理範囲を変更できるようにするため、第２のクラスタシステムにおいて、
前記分散処理制御部が、他のクラスタメンバにおいて故障が発生したとき、及びクラスタシステムに新たなクラスタメンバが追加されたとき、前記範囲決定ルールとクラスタメンバ数とに基づいて新たな主処理範囲および副処理範囲を決定し、それまでの主処理範囲および副処理範囲を旧主処理範囲および旧副処理範囲とする構成を有し、
前記トラフィック分散フィルタが、前記クラスタシステムに入力されたパケットの内、前記新たな主処理範囲、前記新たな副処理範囲、前記旧主処理範囲または前記旧副処理範囲にマッチするパケットを通過させる構成を有し、
前記セッション処理部が、前記トラフィック分散フィルタを通過したパケットの内、前記新たな主処理範囲にマッチしたパケットについては、そのパケットがセッションの開設を要求するパケットであること、或いは前記セッション情報保持部に前記パケットのセッション情報が格納されていることを条件にして、前記セッション情報保持部に格納されている前記パケットのセッション情報の更新処理を含むセッション処理を実行すると共にパケット出力処理を実行し、前記旧主処理範囲のみにマッチしたパケットについては、そのパケットがセッションの開設を要求するパケットである場合には破棄し、そうでない場合には前記セッション情報保持部に前記パケットのセッション情報が格納されていることを条件にして、前記セッション情報保持部に格納されている前記パケットのセッション情報の更新処理を含むセッション処理を実行すると共にパケット出力処理を実行し、前記新たな副処理範囲のみにマッチしたパケットについては、そのパケットがセッションの開設を要求するパケットであること、或いは前記セッション情報保持部に前記パケットのセッション情報が格納されていることを条件にして、前記セッション情報保持部に格納されている前記パケットのセッション情報の更新処理を含むセッション処理を実行すると共にパケット破棄処理を実行し、前記旧副処理範囲のみにマッチしたパケットについては、そのパケットがセッションの開設を要求するパケットである場合には廃棄し、そうでない場合には、前記セッション情報保持部に前記パケットのセッション情報が格納されていることを条件にして、前記セッション情報保持部に格納されている前記パケットのセッション情報の更新処理を含むセッション処理を実行すると共にパケット破棄処理を実行し、前記旧副処理範囲と前記副処理範囲との両方にマッチしたパケットについては、そのパケットがセッションの開設を要求するパケットである場合には、前記セッション情報保持部に格納されている前記パケットのセッション情報の更新処理を含むセッション処理を実行すると共にパケット破棄処理を実行し、そうでない場合は、前記セッション情報保持部に前記パケットのセッション情報が格納されていることを条件にして前記セッション情報保持部に格納されている前記パケットのセッション情報の更新処理を含むセッション処理を実行すると共にパケット出力処理を実行する構成を有することを特徴とする。
また、本発明にかかる第４のクラスタシステムは、第３のクラスタシステムにおいて、
前記各クラスタメンバが、
前記クラスタシステム中のクラスタメンバの識別子が格納されたクラスタメンバリストと、
クラスタメンバ毎の死活監視タイマと、
所定時間毎に自クラスタメンバの識別子を含む広告メッセージを他のクラスタメンバに対して送信すると共に、他のクラスタメンバからの広告メッセージを受信したとき、該広告メッセージの送信元のクラスタメンバに対応する死活監視タイマをリセットする広告メッセージ処理部とを備え、
前記分散処理制御部が、
タイムアウトした死活監視タイマが発生したとき、該タイムアウトした死活監視タイマに対応するクラスタメンバに障害が発生したと認識する構成を有することを特徴とするクラスタシステム。
本発明にかかる第５のクラスタシステムは、第４のクラスタシステムにおいて、
前記分散処理制御部が、
前記広告メッセージ処理部で受信した広告メッセージ中の識別子が前記クラスタメンバリストに含まれていなかった場合、前記識別子のクラスタメンバが追加されたと認識する構成を有することを特徴とする。
本発明にかかる第１のクラスタメンバは、セッション情報をクラスタメンバ間で交換し合うことなく、故障復旧処理を行えるようにするため、
所定の範囲決定ルールに従って自クラスタメンバが担当する主処理の範囲を示す主処理範囲および副処理の範囲を示す副処理範囲を決定し、自クラスタメンバを構成要素とするクラスタシステムに入力されたパケットの内の、前記主処理範囲にマッチするパケットについては、そのパケットが属するセッションの状態を示すセッション情報の記録更新処理を含むセッション処理とパケット転送処理とを行い、前記決定した副処理範囲にマッチするパケットについては、そのパケットが属するセッションの状態を示すセッション情報の記録更新処理を含むセッション処理を行い、自クラスタメンバが副処理を担当しているパケットに対する主処理を担当しているクラスタメンバに故障が発生したとき、前記故障の発生したクラスタメンバが主処理を担当していたパケットの主処理を、前記記録してあるセッション情報を利用して引き継ぐ構成を有することを特徴とする。
本発明にかかる第１の故障復旧方法は、セッション情報をクラスタメンバ間で交換し合うことなく、故障復旧処理を行えるようにするため、
複数のクラスタメンバから構成されるクラスタシステムの故障復旧方法において、
前記各クラスタメンバが、
所定の範囲決定ルールに従って自クラスタメンバが担当する主処理の範囲を示す主処理範囲および副処理の範囲を示す副処理範囲を決定し、前記クラスタシステムに入力されたパケットの内の、前記主処理範囲にマッチするパケットについては、そのパケットが属するセッションの状態を示すセッション情報の記録更新処理を含むセッション処理とパケット転送処理とを行い、前記決定した副処理範囲にマッチするパケットについては、そのパケットが属するセッションの状態を示すセッション情報の記録更新処理を含むセッション処理を行い、自クラスタメンバが副処理を担当しているパケットに対する主処理を担当しているクラスタメンバに故障が発生したとき、前記故障の発生したクラスタメンバが主処理を担当していたパケットの主処理を、前記記録してあるセッション情報を利用して引き継ぐことを特徴とする。
本発明にかかる第１のプログラムは、セッション情報をクラスタメンバ間で交換し合うことなく、故障復旧処理を行えるようにするため、
コンピュータをクラスタメンバとして機能させるためのプログラムであって、
前記コンピュータを、
所定の範囲決定ルールに従って自クラスタメンバが担当する主処理の範囲を示す主処理範囲および副処理の範囲を示す副処理範囲を決定し、自クラスタメンバを構成要素とするクラスタシステムに入力されたパケットの内の、前記主処理範囲にマッチするパケットについては、そのパケットが属するセッションの状態を示すセッション情報の記録更新処理を含むセッション処理とパケット転送処理とを行い、前記決定した副処理範囲にマッチするパケットについては、そのパケットが属するセッションの状態を示すセッション情報の記録更新処理を含むセッション処理を行い、自クラスタメンバが副処理を担当しているパケットに対する主処理を担当しているクラスタメンバに故障が発生したとき、前記故障の発生したクラスタメンバが主処理を担当していたパケットの主処理を、前記記録してあるセッション情報を利用して引き継ぐ手段として機能させる。
図１は、本発明にかかる実施例の全体構成を示すブロック図である。
図２は、クラスタメンバ１−ｉの構成例を示すブロック図である。
図３は、範囲保持部１２１の内容例を示す図である。
図４は、範囲保持部１２１の内容例を示す図である。
図５は、クラスタメンバリスト１７２の内容例を示す図である。
図６は、マルチキャストアドレスによるパケットを受信したときの処理例を示すフローチャートである。
図７は、セッション処理部１３が行うセッション処理の一例を示すフローチャートである。
図８は、セッション処理部１３が行うセッション処理の一例を示すフローチャートである。
図９は、パケット転送部１５が行うパケット転送処理の一例を示すフローチャートである。
図１０は、広告メッセージ処理部１８が行う広告メッセージ送信処理の一例を示すフローチャートである。
図１１は、広告メッセージ処理部１８が行う広告メッセージ受信処理の一例を示すフローチャートである。
図１２は、故障復旧部２０が行う死活監視タイマ監視処理の一例を示すフローチャートである。
図１３は、範囲保持部１２１の内容例を示す図である。
図１４は、範囲保持部１２１の内容例を示す図である。
図１５は、分散処理制御部１７が新規メンバ追加指示を受信した時の処理例を示すフローチャートである。
図１６は、分散処理制御部１７がタイムアウト通知を受けた時の処理例を示すフローチャートである。
図１７は、故障クラスタメンバが発生した時の動作を説明するための図である。
図１８は、新規クラスタメンバが追加された時の動作を説明するための図である。
図１９は、本発明の他の実施例を説明するための図である。
図２０は、従来の技術を説明するためのブロック図である。
図２１は、他の従来の技術を説明するためのブロック図である。
図２は、クラスタメンバ１−ｉの構成例を示すブロック図である。
図３は、範囲保持部１２１の内容例を示す図である。
図４は、範囲保持部１２１の内容例を示す図である。
図５は、クラスタメンバリスト１７２の内容例を示す図である。
図６は、マルチキャストアドレスによるパケットを受信したときの処理例を示すフローチャートである。
図７は、セッション処理部１３が行うセッション処理の一例を示すフローチャートである。
図８は、セッション処理部１３が行うセッション処理の一例を示すフローチャートである。
図９は、パケット転送部１５が行うパケット転送処理の一例を示すフローチャートである。
図１０は、広告メッセージ処理部１８が行う広告メッセージ送信処理の一例を示すフローチャートである。
図１１は、広告メッセージ処理部１８が行う広告メッセージ受信処理の一例を示すフローチャートである。
図１２は、故障復旧部２０が行う死活監視タイマ監視処理の一例を示すフローチャートである。
図１３は、範囲保持部１２１の内容例を示す図である。
図１４は、範囲保持部１２１の内容例を示す図である。
図１５は、分散処理制御部１７が新規メンバ追加指示を受信した時の処理例を示すフローチャートである。
図１６は、分散処理制御部１７がタイムアウト通知を受けた時の処理例を示すフローチャートである。
図１７は、故障クラスタメンバが発生した時の動作を説明するための図である。
図１８は、新規クラスタメンバが追加された時の動作を説明するための図である。
図１９は、本発明の他の実施例を説明するための図である。
図２０は、従来の技術を説明するためのブロック図である。
図２１は、他の従来の技術を説明するためのブロック図である。
次に本発明の実施例について図面を参照して詳細に説明する。
〔実施例の構成の説明〕
図１は本発明にかかるクラスタシステムの一実施例の構成例を示すブロック図である。同図に示すように、本実施例のクラスタシステム１は、ｎ個（複数個）のクラスタメンバ１−１〜１−ｎを備えており、各クラスタメンバ１−１〜１−ｎは、それぞれデータリンク３−１〜３−ｍを介して隣接ＩＰノード２−１〜２−ｍと接続されている。
図２は、クラスタメンバ１−ｉ（１≦ｉ≦ｎ）の構成例を示すブロック図である。
各クラスタメンバ１−ｉは、各データリンク３−１〜３−ｍ毎のインタフェース部（ＩＦ部）１１−１〜１１−ｍと、トラフィック分散フィルタ１２と、セッション処理部１３と、セッション情報保持部１４と、パケット転送部１５と、ルーティングテーブル１６と、分散処理制御部１７と、広告メッセージ処理部１８と、死活監視タイマ部１９と、故障復旧部２０とから構成されている。
インタフェース部１１−ｊ（１≦ｊ≦ｍ）は、パケット転送部１５から渡されたパケットや広告メッセージをデータリンク３−ｊへ送出する機能や、データリンク３−ｊを介して送られてくる、クラスタシステム１固有のＩＰアドレス（クラスタ用アドレス）を宛先として含んだパケットや、自クラスタメンバ１−ｉ固有のＩＰアドレス（メンバ個別アドレス）を宛先として含んだパケット（個々のクラスタメンバが制御用に使用するパケット）や、上記クラスタ用アドレスに対応する所定のデータリンクマルチキャストアドレスを宛先として含んだパケットや、他のクラスタメンバからの広告メッセージを受信する機能を有する。
トラフィック分散フィルタ１２は、範囲保持部１２１を備えている。この範囲保持部１２１には、自クラスタメンバ１−ｉが現在主処理を担当しているトラフィックの範囲（主処理範囲）と、過去において主処理を担当していたトラフィックの範囲（旧主処理範囲）と、現在副処理を担当しているトラフィックの範囲（副処理範囲）と、過去において副処理を担当していたトラフィックの範囲（旧副処理範囲）とが格納されている。
そして、トラフィック分散フィルタ１２は、インタフェース部１１−ｊがデータリンクマルチキャストアドレスを宛先にしたパケットを受信したとき、上記各処理範囲に基づいて、上記パケットを通過させるか（セッション処理部１３に渡すか）、破棄するかを決定する。なお、旧主処理範囲及び旧副処理範囲は、範囲保持部１２１に格納されていない場合もある。
図３，図４に範囲保持部１２１の内容例を示す。図３の例は、主処理範囲ｍｆｉ及び副処理範囲ｂｆ１，ｉ〜ｂｆＰ，ｉにマッチするパケットを通過させ、それ以外のパケットは破棄することを示している。また、図４の例は、主処理範囲ｍｆｉ’、旧主処理範囲ｍｆｉ、副処理範囲ｂｆ１，ｉ’〜ｂｆＰ，ｉ’及び旧副処理範囲ｂｆ１，ｉ〜ｂｆＰ，ｉにマッチするパケットを通過させ、それ以外のパケットは破棄することを示している。
なお、主処理と副処理との違いは、後の説明で明らかになるが、パケット転送部１５において、パケットを送出方路に出力するか、破棄するかの違いがあるだけであり、それ以外は同じ処理が行われる。
セッション処理部１３は、トラフィック分散フィルタ１２を通過したパケットに対して、セッション処理を行う。このセッション処理においては、パケットが属するセッションを識別する処理や、セッション情報保持部１４に保持されているセッション状態を示すセッション情報を更新，削除する処理や、セッション情報保持部１４に新たなセッション情報を登録する処理（セッション開設時）や、パケットのヘッダ情報とセッション情報とに基づいて不正なパケットを破棄する処理を含む処理が行われる。
ここで、セッションとは、ＩＰの拡張プロトコルおよび上位層プロトコルにより提供される仮想通信路を指し、例えば、ＴＣＰのコネクション，ＩＰｓｅｃのＳｅｃｕｒｉｔｙ Ａｓｓｏｃｉａｔｉｏｎなどが含まれる。また、セッション状態とは、これらのセッション毎に保持される固有の情報を指し、ＴＣＰのコネクションの場合は、コネクションの状態，シーケンス番号，応答番号などを含む。また、ＩＰｓｅｃ ＳＡの場合には、ＲＦＣ２４０１で定められるＳＡのパラメータを含む。
パケット転送部１５は、セッション処理部１３から渡されたパケットや、インタフェース部１１−ｊが受信した、宛先がデータリンクマルチキャストアドレス以外のパケットの送出方路を、ルーティングテーブル１６の内容と上記パケットの宛先とに基づいて決定し、次ホップノードへ転送する機能を有する。
死活監視タイマ部１９には、クラスタシステム１を構成する各クラスタメンバ１−１〜１−ｎ毎の死活監視タイマ（図示せず）が設けられている。各死活監視タイマは、リセット後、所定時間Ｔｏｕｔが経過すると、タイムアウト状態になる。
広告メッセージ処理部１８は、所定時間Ｔｓ（Ｔｓ＜Ｔｏｕｔ）毎に、クラスタシステム１内の他のクラスタメンバに対して広告メッセージを送信する機能や、他のクラスタメンバ１−ｋ（１≦ｋ≦ｎ）からの広告メッセージを受信した時、死活監視タイマ部１９に設けられているクラスタメンバ１−ｋ用の死活監視タイマをリセットする機能や、受信した広告メッセージに基づいて新たなクラスタメンバが追加されたことを検出した時、分散処理制御部１７に対して新規メンバ追加指示を出力する機能などを有する。
故障復旧部２０は、死活監視タイマ部１９内に設けられている、各クラスタメンバ１−１〜１−ｎ毎の死活監視タイマの状態を常時監視し、故障の発生したクラスタメンバを検出する機能や、タイムアウト状態になった死活監視タイマを検出したとき（故障の発生したクラスタメンバを検出したとき）、分散処理制御部１７に対して故障したクラスタメンバの識別子を含むタイムアウト通知を行う機能や、故障の発生したクラスタメンバが行っていた主処理を引き継ぐことが必要であるか否かを判定し、引き継ぐことが必要な場合は、トラフィック分散フィルタ１２内の範囲保持部１２１の内容を書き換える機能などを有する。
分散処理制御部１７は、識別子保持部１７１と、クラスタメンバリスト１７２と、範囲決定ルール保持部１７３とを備えている。
識別子保持部１７１には、自クラスタメンバ１−ｉ固有の識別子（例えば、ＩＤｉ）が格納されている。
クラスタメンバリスト１７２には、クラスタシステム１を構成している各クラスタメンバ１−１〜１−ｎの、クラスタメンバリスト１７２内での位置を示す番号と、識別子と、現時点で主処理を担当している範囲（主処理範囲）と、現時点で副処理を担当している範囲（副処理範囲）とが設定されている。
図５にクラスタメンバリスト１７２の一例を示す。図５の例は、番号「ｉ」、識別子「ＩＤｉ」のクラスタメンバ１−ｉは、主処理範囲ｍｆｉにマッチするパケットに対する主処理と、副処理範囲ｂｆ１，ｉ〜ｂｆＰ，ｉにマッチするパケットに対する優先度「１」〜「Ｐ」の副処理とを担当していることを示している。ここで、Ｐは、１≦Ｐ≦（ｎ−１）を満たすものであれば、任意の値（整数）とすることができる。
範囲決定ルール保持部１７３には、クラスタシステム１を構成している各クラスタメンバ１−１〜１−ｎに担当させる主処理範囲ｍｆ１〜ｍｆｎを決定するための主処理範囲決定ルールと、各クラスタメンバ１−１〜１−ｎに担当させる副処理範囲ｂｆ１，１〜ｂｆＰ，ｎを決定するための副処理範囲決定ルールとが格納されている。
主処理範囲決定ルールによって決定される、各クラスタメンバ１−１〜１−ｎが担当する主処理範囲ｍｆ１〜ｍｆｎは、互いに重複せず、且つ、処理すべき全トラフィックを網羅しなければならない。今、例えば、処理すべき全トラフィックをＴ、空集合をφとすると、主処理範囲決定ルールは、次式（１），（２）を満たす主処理範囲ｍｆ１〜ｍｆｎを決定可能なものでなくてはならない。
ｍｆ１∪ｍｆ２∪ … ∪ｍｆｎ＝Ｔ…（１）
ｍｆ１∩ｍｆ２∩ … ∩ｍｆｎ＝φ…（２）
このような条件を満たす主処理範囲決定ルールとしては、例えば、次のようなものを採用することができる。
番号「１」〜「ｎ」のクラスタメンバ１−１〜１−ｎの主処理範囲ｍｆ１〜ｍｆｎを、それぞれ「０」〜「ｎ−１」とする主処理範囲決定ルール。ここで、主処理範囲ｍｆ１〜ｍｆｎ（「０」〜「ｎ−１」）は、パケットのＩＰ送信元アドレスとＩＰ宛先アドレスとに対して可換な演算（例えば、両者の加算或いは乗算）を行い、その演算結果をクラスタ数「ｎ」で除算した時の余りを示す。なお、主処理範囲決定ルールは、これに限られるものではなく、上記した式（１），（２）を満たす主処理範囲を決定できるものであれば、どのようなものであっても良い。
また、副処理範囲決定ルールによって決定される、各クラスタメンバ１−１〜１−ｎが担当する優先度Ｐの副処理範囲ｂｆＰ，１〜ｂｆＰ，ｎは、互いに重複せず、且つ、処理すべき全トラフィックＴを網羅しなければならない。また、各クラスタメンバにおいて、そのクラスタメンバ１−ｉが担当している主処理範囲ｍｆｉと、そのクラスタメンバ１−ｉが担当する優先度「１」〜「Ｐ」の副処理範囲ｂｆ１，ｉ〜ｂｆＰ，ｉとは重複してはならない。つまり、副処理範囲決定ルールは、次式（３）〜（５）を満たす副処理範囲ｂｆＰ，１〜ｂｆＰ，ｎを決定可能なものでなくてはならない。
ｂｆＰ，１ ∪ ｂｆＰ，２ ∪…∪ ｂｆＰ，ｎ＝Ｔ …（３）
ｂｆＰ，１ ∩ ｂｆＰ，２ ∩…∩ ｂｆＰ，ｎ＝φ …（４）
ｍｆｉ ∩ ｂｆ１，ｉ ∩ ｂｆ２，ｉ ∩…∩ ｂｆＰ，ｉ …（５）
また、分散処理制御部１７は、広告メッセージ処理部１８から新規メンバ追加指示が入力された場合や、故障復旧部２０からタイムアウト通知が入力された場合、範囲決定ルール保持部１７３に格納されている主処理範囲決定ルール及び副処理範囲決定ルールに従って各クラスタメンバ１−１〜１−ｎの主処理範囲及び副処理範囲を決定する機能や、クラスタメンバリスト１７２の内容を更新する機能や、トラフィック分散フィルタ１２内の範囲保持部１２１の内容を更新する機能などを有する。
なお、クラスタメンバ１−ｉはコンピュータによって実現可能なものであり、コンピュータによってクラスタメンバ１−ｉを実現する場合は、次のようにする。クラスタメンバ用のプログラムを記録したディスク、半導体メモリ、その他の記録媒体を用意する。コンピュータは、上記プログラムを読み込み、自身の動作を制御することにより、インタフェース部１１−１〜１１−ｍ、トラフィック分散フィルタ１２、セッション処理部１３、パケット転送部１５、ルーティングテーブル１６、分散処理制御部１７、広告メッセージ処理部１８、死活監視タイマ部１９、故障復旧部２０を実現する。
〔実施例の動作の説明〕
次に、上記のように構成される本実施例のクラスタシステムの動作について詳細に説明する。
〔データリンクマルチキャストアドレスを宛先にしたパケットの受信処理〕
先ず、隣接ＩＰノード２−ａ（１≦ａ≦ｍ）からクラスタシステム１を次ホップとして送信されたパケットの処理について説明する。隣接ＩＰノード２−ａは、クラスタシステム１のクラスタ用アドレスを次ホップとするパケットについては、上記クラスタ用アドレスに対応するデータリンクマルチキャストアドレス宛に送信する。
各クラスタメンバ１−１〜１−ｎは、上記マルチキャストされたパケットを受信すると、図６のフローチャートに示す処理を行う。
クラスタメンバ１−ｉ内のトラフィック分散フィルタ１２は、マルチキャストされたパケットをインタフェース部１１−ａを介して受信すると、先ず、そのパケットが、主処理範囲にマッチしているか否かを調べる（ステップＳ５１）。そして、主処理範囲にマッチしている場合には、上記パケットにマッチ種別「主処理範囲」を付加してセッション処理部１３に渡す（ステップＳ５６）。
これに対して、主処理範囲にマッチしていない場合は、旧主処理範囲のみにマッチしているか、旧主処理範囲と副処理範囲の両方にマッチしているか、副処理範囲のみにマッチしているか、それとも旧副処理範囲にマッチしているかを調べる（ステップＳ５２〜Ｓ５５）。
旧主処理範囲のみにマッチしている場合は、パケットにマッチ種別「旧主処理範囲」を付加してセッション処理部１３に渡す（ステップＳ５２において”ＹＥＳ”、Ｓ５６）。
旧主処理範囲と副処理範囲の両方にマッチしている場合は、マッチ種別「旧主処理範囲、副処理範囲」を付加してセッション処理部１３に渡す（ステップＳ５３において”ＹＥＳ”、Ｓ５６）。
副処理範囲のみにマッチする場合は、マッチ種別「副処理範囲」を付加してセッション処理部１３に渡す（ステップＳ５４において”ＹＥＳ”、Ｓ５６）。
旧副処理範囲にマッチする場合は、マッチ種別「旧副処理範囲」を付加してセッション処理部１３に渡す（ステップＳ５５において”ＹＥＳ”、Ｓ５６）。
いずれの範囲にもマッチしない場合は、パケットを破棄する（ステップＳ５５において”ＮＯ”、Ｓ５９）。なお、範囲保持部１２１に旧主処理範囲、旧副処理範囲が格納されていない場合には、旧主処理範囲、旧副処理範囲とはマッチしないことになる。
セッション処理部１３は、トラフィック分散フィルタ１２からマッチ種別の付加されたパケットが渡されると、セッション処理を行う（ステップＳ５７）。このステップＳ５７で行うセッション処理について、図７，図８を参照して詳細に説明する。
セッション処理部１３は、トラフィック分散フィルタ１２からマッチ種別「主処理範囲」の付加されたパケットが渡されると（図７のステップＳ６０１において”ＹＥＳ”）、そのパケットがセッションの開設を要求するものであるか否かを判断する（ステップＳ６０２）。
そして、セッションの開設を要求するパケットであった場合は、セッション情報保持部１４に上記パケットが属するセッションのセッション情報を登録すると共に、上記パケットを処理する（ステップＳ６０３，Ｓ６０４）。
ステップＳ６０４では、不正パケットを破棄する処理などを行う（破棄しなかったパケットは、パケット転送部１５に渡す）。
これに対して、セッションの開設を要求するパケットでなかった場合（ステップＳ６０２において”ＮＯ”）は、上記パケットのヘッダ情報に基づいて、セッション情報保持部１４に上記パケットが属するセッションのセッション情報が存在するか否かを調べる（ステップＳ６０５）。
そして、存在しない場合（自クラスタメンバが上記パケットが属するセッションの開設処理を行っていない場合）は、パケットを破棄し（ステップＳ６０６）、存在する場合（自クラスタメンバが上記パケットが属するセッションの開設処理を行っている場合）は、セッション情報を更新すると共にパケットを処理する（ステップＳ６０３，Ｓ６０４）。なお、パケットがセッション終了を要求するパケットである場合には、ステップＳ６０３において、セッション情報保持部１４に格納されている上記パケットが属するセッションのセッション情報を削除する処理が行われる。
また、トラフィック分散フィルタ１２からマッチ種別「旧主処理範囲」の付加されたパケットが渡された場合（ステップＳ６０７において”ＹＥＳ”）は、そのパケットがセッションの開設を要求するものであるか否かを判断する（ステップＳ６０８）。
そして、セッションの開設を要求するものである場合は、破棄し（ステップＳ６０９）、そうでない場合は、上記パケットが属するセッションのセッション情報がセッション情報保持部１４に格納されているか否かを調べる（ステップＳ６１０）。
該当するセッション情報が存在しなかった場合には、パケットを廃棄し（ステップＳ６０９）、存在する場合には、セッション情報保持部１４に格納されている該当するセッション情報を更新すると共に、不正パケットを破棄するなどの処理を行う（ステップＳ６１１，Ｓ６１２）。
また、トラフィック分散フィルタ１２からマッチ種別「副処理範囲」の付加されたパケットが渡された場合（図８のステップＳ７０１において”ＹＥＳ”）は、セッション処理部１３は、先ず、そのパケットがセッションの開設を要求するものであるか否かを判定する（ステップＳ７０２）。
そして、セッションの開設を要求するものである場合は、セッション情報保持部１４に上記パケットのセッション情報を登録すると共に、上記パケットを破棄する（ステップＳ７０３，Ｓ７０４）。
これに対して、セッションの開設を要求するものでない場合は、上記パケットが属するセッションのセッション情報がセッション情報保持部１４に格納されているか否かを調べる（ステップＳ７０５）。
そして、該当するセッション情報が存在する場合は、セッション情報を更新すると共に、パケットを破棄し（ステップＳ７０３，Ｓ７０４）、存在しない場合は、上記パケットを破棄する（ステップＳ７０６）。
また、トラフィック分散フィルタ１２からマッチ種別「旧副処理範囲」の付加されたパケットが渡された場合（ステップＳ７０７において”ＹＥＳ”）は、そのパケットがセッションの開設を要求するものか否かを調べる（ステップＳ７０８）。
そして、セッションの開設を要求するパケットである場合には、廃棄処理を行い（ステップＳ７０９）、そうでない場合は、セッション情報保持部１４に該当するセッション情報が格納されているか否かを調べる（ステップＳ７１０）。
該当するセッション情報が存在しない場合は、パケットを破棄し（ステップＳ７０９）、存在する場合は、セッション情報を更新すると共にパケットを破棄する（ステップＳ７１１，Ｓ７１２）。
また、トラフィック分散フィルタ１２からマッチ種別「旧主処理範囲、副処理範囲」の付加されたパケットが渡された場合（ステップＳ７０７において”ＮＯ”）は、そのパケットがセッションの開設を要求するものか否かを調べる（ステップＳ７１３）。
そして、セッションの開設を要求するパケットである場合は、開設するセッションのセッション情報をセッション情報保持部１４に登録した後、そのパケットを破棄する（ステップＳ７１４，Ｓ７１５）。
これに対して、セッション開設を要求するパケットでない場合は、セッション情報保持部１４に該当するセッション情報が登録されているか否かを調べる（ステップＳ７１６）。
そして、登録されていない場合は、パケットを破棄し（ステップＳ７１５）、登録されている場合は、セッション情報保持部１４に登録されているセッション情報を更新すると共に、上記パケットをパケット転送部１５に渡す（ステップＳ７１７，Ｓ７１８）。
再び図６に示す処理に戻り、パケット転送部１５は、セッション処理部１３からパケット（マッチ種別はセッション処理部１３で削除されている）が渡されると、パケット転送処理を実行する（ステップＳ５８）。
このステップＳ５８で行うパケット転送処理では、図９のフローチャートに示すように、パケットのＩＰ宛先アドレスに基づいてルーティングテーブル１６を検索することにより送出方路を求め、求めた送出方路に対応したインタフェース部を介してパケットを送出する（ステップＳ８１，Ｓ８２）。なお、パケット転送部１５は、インタフェース部１１−１〜１１−ｍを介して受信した、データリンクマルチキャストアドレスを宛先としないパケットについても同様の処理を行う。
〔広告メッセージの送信処理〕
次に、広告メッセージの送信処理について説明する。クラスタメンバ１−ｉ内の広告メッセージ処理部１８は、図１０のフローチャートに示すように、広告メッセージの送信タイミングになる毎に（ステップＳ９１において”ＹＥＳ”）、クラスタメンバリスト１７２に格納されている全ての識別子（自クラスタメンバ１−ｉがクラスタシステム１内に存在していると認識しているクラスタメンバの識別子）と、識別子保持部１７１に格納されている自クラスタメンバ１−ｉの識別子とを取得し（ステップＳ９２）、それらを含む広告メッセージを、クラスタシステム１内の他のクラスタメンバへ送信する（ステップＳ９３）。
その際、広告メッセージ処理部１８は、クラスタ用ＩＰアドレス以外の所定のマルチキャストまたはブロードキャストアドレスを用いて広告メッセージを送信する。
また、ステップＳ９１では、前回広告メッセージを送信してから所定時間Ｔｓが経過したか否かに基づいて送信タイミングになったか否かを判断しており、上記所定時間Ｔｓは、死活監視タイマのタイムアウト時間Ｔｏｕｔよりも短い時間である。即ち、Ｔｓ＜Ｔｏｕｔの関係を満たしている。また、新規にクラスタシステム１に追加されたクラスタメンバ内のクラスタメンバリスト１７２には、自クラスタメンバの識別子しか格納されていない。
〔広告メッセージの受信処理〕
次に広告メッセージの受信処理について説明する。クラスタメンバ１−ｉ内の広告メッセージ処理部１８は、クラスタシステム１内の他のクラスタメンバ（例えば、クラスタメンバ１−ｎ）からの広告メッセージを受信すると、図１１のフローチャートに示すように、広告メッセージに含まれている送信元クラスタメンバ１−ｎの識別子が、クラスタメンバリスト１７２に登録されているか否かを調べる（ステップＳ１０１）。
そして、クラスタメンバ１−ｎの識別子がクラスタメンバリスト１７２に登録されていると判断した場合（ステップＳ１０１において”ＹＥＳ”）は、死活監視タイマ部１９内に設けられている、クラスタメンバ１−ｎ用の死活監視タイマ（図示せず）をリセットし、その後、分散処理制御部１７に対して広告メッセージに含まれている全識別子を渡す（ステップＳ１０２，Ｓ１０３）。
これに対して、登録されていないと判断した場合（ステップＳ１０１において”ＮＯ”）は、クラスタシステム１に新規クラスタメンバが追加されたと認識し、分散処理制御部１７に対して新規メンバ追加指示を出力する（ステップＳ１０４）。
この新規メンバ追加指示には、広告メッセージの送信元クラスタメンバ１−ｎの識別子が含まれる。
その後、広告メッセージ処理部１８は、死活監視タイマ部１９内に新規クラスタメンバ１−ｎ用の死活監視タイマを生成する（ステップＳ１０５）。なお、死活監視タイマ部１９内に設けられている各死活監視タイマは、それぞれリセットされてから所定時間Ｔｏｕｔが経過するとタイムアウト状態になるものである。
〔故障復旧処理（ｆａｉｌｏｖｅｒ処理）〕
次に故障復旧処理について説明する。クラスタメンバ１−ｉ内の故障復旧部２０は、図１２のフローチャートに示すように、死活監視タイマ部１９内に設けられている各クラスタメンバ用の死活監視タイマの内の１つに注目し、その死活監視タイマがタイムアウト状態になっているか否かを調べる（ステップＳ１１１，Ｓ１１２）。
そして、タイムアウト状態になっていない場合（ステップＳ１１２において”ＮＯ”）は、次の死活監視タイマに注目する（ステップＳ１１１）。
これに対して、現在注目している死活監視タイマ（例えば、クラスタメンバ１−ｎ用の死活監視タイマ）がタイムアウト状態になっている場合（ステップＳ１１２において”ＹＥＳ”）は、自クラスタメンバ１−ｉが、クラスタメンバ１−ｎが主処理を担当しているトラフィックに関し、優先度「１」の副処理を担当しているか否かを判断する（ステップＳ１１３）。この判断は、クラスタメンバリスト１７２を参照して行う。
そして、優先度「１」の副処理を担当している場合（ステップＳ１１３において”ＹＥＳ”）は、トラフィック分散フィルタ１２内の範囲保持部１２１の内容を更新し、クラスタメンバ１−ｎが主処理を担当していたトラフィックの範囲についても、自クラスタメンバ１−ｉで主処理を担当するようにする（ステップＳ１１４）。
例えば、範囲保持部１２１の内容が図３に示すものである場合は、その内容を図１３に示すように変更する。つまり、主処理範囲に、ｂｆ１，ｉを追加し、副処理範囲からｂｆ１，ｉを削除する。なお、図３，図１３において、ｂｆ１，ｉは、クラスタメンバ１−ｎが主処理を担当していた主処理範囲と同一の範囲を示す。
これに対して、優先度「１」の副処理を担当していない場合（ステップＳ１１３において”ＮＯ”）は、クラスタメンバ１−ｎが担当している副処理の中に、自クラスタメンバ１−ｉが担当している副処理とトラフィック範囲が同じで、且つ優先度が自クラスタメンバ１−ｉで担当している副処理よりも高いものがあるか否かを判断する（ステップＳ１１７）。
そして、そのような副処理が存在する場合（ステップＳ１１７において”ＹＥＳ”）は、該当する副処理範囲の優先度を１つ上げる（ステップＳ１１８）。
例えば、範囲保持部１２１の内容が、図３に示すものである場合は、その内容を図１４に示すように変更する。つまり、ｂｆ２，ｉの優先度を「２」から「１」に変更する（優先度を１つ上げる）。なお、図３，図１４において、ｂｆ２，１は、クラスタメンバ１−ｎが優先度「１」の副処理を担当していたトラフィック範囲と同一の範囲を示す。
これに対して、上記した条件を満たす副処理が存在しない場合（ステップＳ１１７において”ＮＯ”）は、ステップＳ１１５の処理を行う。なお、ステップＳ１１５は、ステップＳ１１４或いはステップＳ１１８の終了後にも実行される。
ステップＳ１１５において、故障復旧部２０は、分散処理制御部１７に対してタイムアウト通知を行う。このタイムアウト通知には、タイムアウト状態になった死活監視タイマに対応するクラスタメンバ１−ｎの識別子が含まれている。その後、故障復旧部２０は、死活監視タイマ部１９からクラスタメンバ１−ｎ用の死活監視タイマを削除し（ステップＳ１１６）、再び、ステップ３１１１の処理を行う。
〔新規メンバ追加処理〕
次に、分散処理制御部１７が行う新規メンバ追加処理について説明する。クラスタメンバ１−ｉ内の分散処理制御部１７は、広告メッセージ処理部１８から新規メンバ追加指示が入力されると、図１５のフローチャートに示す処理を行う。なお、新規メンバ追加指示には、新規に追加されたクラスタメンバの識別子としてクラスタメンバ１−ｘの識別子が含まれているとする。
先ず、分散処理制御部１７は、範囲決定ルール保持部１７３に格納されている主処理範囲決定ルール及び副処理範囲決定ルールを使用して、クラスタシステム１内の各クラスタメンバの主処理範囲及び副処理範囲を決定する（ステップＳ１３１）。つまり、クラスタメンバリスト１７２に識別子が格納されている各クラスタメンバ及び追加されたクラスタメンバ１−ｘの主処理範囲及び副処理範囲を決定する。
次に、分散処理制御部１７は、各クラスタメンバの情報（識別子、主処理範囲、副処理範囲）を、識別子をキーにしてソートし、ソート順に番号を付してクラスタメンバリスト１７２に格納する（ステップＳ１３２）。
その後、分散処理制御部１７は、自クラスタメンバ１−ｉが認識しているクラスタシステム構成と、他のクラスタメンバが認識しているクラスタシステム構成が全て同じであるか否かを判断する（ステップＳ１３３）。
この判断は、図１１のステップＳ１０３において、広告メッセージ処理部１８から入力される、広告メッセージ中の全識別子に基づいて行う。つまり、自クラスタメンバ１−ｉがクラスタシステム１内に存在していると認識している各クラスタメンバから広告メッセージが送られてきており、且つ、上記各クラスタメンバから送られてきた広告メッセージ中の全識別子と、自クラスタメンバ１−ｉ内のクラスタメンバリスト１７２に格納されている識別子とが一致する場合、全クラスタメンバが認識しているクラスタシステム構成が同じであると判断する。
ステップＳ１３３において、全クラスタメンバが認識しているクラスタシステム構成が同じであると認識すると、分散処理制御部１７は、トラフィック分散フィルタ１２内の範囲保持部１２１の内容を更新する（ステップＳ１３４）。つまり、現時点において、主処理範囲，副処理範囲であったものを、それぞれ旧主処理範囲，旧副処理範囲とし、ステップＳ１３１で決定した主処理範囲，副処理範囲をそれぞれ主処理範囲，副処理範囲とする。例えば、範囲保持部１２１の内容が図３に示すものであった場合、ステップＳ１３４の処理を行うことにより、その内容は、例えば図４に示すように変更される。
〔タイムアウト通知受信処理〕
次に、分散処理制御部１７が行うタイムアウト通知受信処理について説明する。分散処理制御部１７は、故障復旧部２０からタイムアウト通知が入力されると、図１６のフローチャートに示す処理を行う。なお、タイムアウト通知には、タイムアウトが発生したクラスタメンバの識別子としてクラスタメンバ１−ｎの識別子が含まれているとする。
先ず、分散処理制御部１７は、分散処理制御部１７からクラスタメンバ１−ｎのエントリを削除する（ステップＳ１４１）。
次に、範囲決定ルール保持部１７３に格納されている主処理範囲決定ルール及び副処理範囲決定ルールに基づいて、クラスタメンバリスト１７２に識別子が格納されている各クラスタメンバの主処理範囲及び副処理範囲を決定し、決定した主処理範囲及び副処理範囲に基づいてクラスタメンバリスト１７２を更新する（ステップＳ１４２，１４３）。
その後、分散処理制御部１７は、全てのクラスタメンバが認識しているクラスタシステム構成が同じであるか否かを判断し（ステップＳ１４４）、そうである場合は、トラフィック分散フィルタ１２内の範囲保持部１２１の内容を更新する（ステップＳ１４５）。なお、ステップＳ１４５では、前述したステップＳ１３４と同様の処理が行われる。
次に、具体例を挙げて本実施例の動作を説明する。
今、例えば、クラスタシステム１が４台のクラスタメンバ１−１〜１−４から構成され、クラスタシステム１で処理すべき全トラフィックがＴであるとする。また、各クラスタメンバ１−１〜１−４には、図１７（Ａ），（Ｂ）に示す主処理範囲ｍｆ１〜ｍｆ４及び副処理範囲ｂｆ１，１〜ｂｆ１，４が設定されているとする。即ち、クラスタメンバ１−１，１−２，１−３，１−４が担当している主処理に関する優先度「１」の副処理を、クラスタメンバ１−４，１−１，１−２，１−３が担当している。また、この時点では、旧主処理範囲および旧副処理範囲は設定されていないとする。
このような状態において、隣接ＩＰノード（例えば、隣接ＩＰノード２−１）からクラスタシステム１へパケットがマルチキャストされ、各クラスタメンバ１−１〜１−４が上記パケットを受信したとする。但し、このパケットは、セッションαに属するものとする。
クラスタメンバ１−１，１−２は、上記パケットが主処理範囲、旧処理範囲、副処理範囲、旧副処理範囲の何れにもマッチしないので、パケットを破棄する（図６のステップ５５において全て”ＮＯ”、Ｓ５９）。
クラスタメンバ１−３は、上記パケットが副処理範囲ｂｆ１，３のみにマッチするので、上記パケットに対するセッション処理を実行する（ステップＳ５４において”ＹＥＳ”、Ｓ５６、Ｓ５７）。
また、クラスタメンバ１−４は、上記パケットが主処理範囲ｍｆ４にマッチするので、上記パケットに対するセッション処理を実行する（ステップＳ５１において”ＹＥＳ”、Ｓ５６，Ｓ５７）。
このような状態において、クラスタメンバ１−４に故障が発生したとする。クラスタメンバ１−４に故障が発生すると、クラスタメンバ１−４からは広告メッセージが送出されなくなるので、他のクラスタメンバ１−１〜１−３内に設けられているクラスタメンバ１−４用の死活監視タイマは、タイムアウト状態になる。
クラスタメンバ１−４用の死活監視タイマがタイムアウト状態になると、クラスタメンバ１−４が担当していた主処理に関する優先度「１」の副処理を担当しているクラスタメンバ１−３は、自クラスタメンバ１−３内の範囲保持部１２１を更新し、クラスタメンバ１−４が担当していた主処理を引き継ぐ（図１２のステップＳ１１２において”ＹＥＳ”、Ｓ１１３において”ＹＥＳ”、Ｓ１１４）。つまり、クラスタメンバ１−３においては、副処理範囲ｂｆ１，３が主処理範囲に変更されるため、セッションαに属するパケットの主処理を実行することになる。
その後、クラスタメンバ１−３は、図１６のフローチャートに示すタイムアウト通知受信処理を実行する。他のクラスタメンバ１−１，１−２は、図１２のステップＳ１１３，Ｓ１１７において共に”ＮＯ”となるので、図１６のフローチャートに示すタイムアウト通知受信処理を実行する。
図１６のフローチャートに示す受信処理が行われることにより、正常動作している各クラスタメンバ１−１〜１−３には、図１７（Ｃ），（Ｄ）に示す主処理範囲ｍｆ１’〜ｍｆ３’及び副処理範囲ｂｆ１，１’〜ｂｆ１，３’が設定される。なお、主処理範囲ｍｆ１〜ｍｆ３及び副処理範囲ｂｆ１，１〜ｂｆ１，３は、クラスタメンバ１−１〜１−３の旧主処理範囲及び旧副処理範囲となる。
その後、再び、隣接ＩＰノード２−ａからセッションαに属するパケットが、クラスタシステム１に対してマルチキャストされたとすると、各クラスタメンバ１−１〜１−３において、上記パケットが受信される。
クラスタメンバ１−１内のトラフィック分散フィルタ１２は、上記パケットが、主処理範囲、旧主処理範囲、副処理範囲、旧副処理範囲の何れにもマッチしないので、そのパケットを破棄する（図６のステップＳ５５において”ＮＯ”、Ｓ５９）。
また、クラスタメンバ１−２内のトラフィック分散フィルタ１２は、上記パケットが副処理範囲ｂｆ１，２’のみにマッチするパケットであるので、マッチ種別「副処理範囲」を付加してセッション処理部１３に渡す（図６のステップＳ５４において”ＹＥＳ”、Ｓ５６）。
セッション処理部１３は、マッチ種別「副処理範囲」の付加されたパケットが渡されると、それがセッション開設を要求するパケットでないので、上記パケットのセッション情報がセッション情報保持部１４に格納されているか否かを調べる（図８のステップＳ７０１において”ＹＥＳ”、Ｓ７０２において”ＮＯ”、Ｓ７０５）。この例の場合、該当するセッション情報が格納されていないので、パケットを破棄する（Ｓ７０５において”ＮＯ”、Ｓ７０６）。
クラスタメンバ１−３内のトラフィック分散フィルタ１２は、上記パケットが主処理範囲ｍｆ３’にマッチするので、マッチ種別「主処理範囲」を付加してセッション処理部１３に渡す（図６のステップＳ５１において”ＹＥＳ”，Ｓ５６）。
セッション処理部１３は、マッチ種別「主処理範囲」の付加されたパケットが渡されると、それがセッション開設を要求するパケットでないので、上記パケットに関するセッション情報がセッション情報保持部１４に格納されているか否かを調べる（図７のステップＳ６０１において”ＹＥＳ”，Ｓ６０２において”ＮＯ”，Ｓ６０５）。この例の場合、クラスタメンバ１−３は、クラスタメンバ１−４に故障が発生する前、セッションαに属するパケットに対する副処理を担当していたので、セッション情報保持部１４には該当するセッション情報が存在することになる。
従って、セッション処理部１３は、セッション情報保持部１４に格納されている該当するセッション情報を更新し（ステップＳ６０３）、更に、上記パケットをセッション処理部１３に渡すことになる（ステップＳ６０４）。
その後、隣接ＩＰノード２−ａからセッションβの開設を要求するパケットが、クラスタシステム１に対してマルチキャストされたとする。このパケットは、クラスタシステム１内の各クラスタメンバ１−１〜１−３で受信される。
クラスタメンバ１−１内のトラフィック分散フィルタ１２は、上記パケットが主処理範囲ｍｆ１’にマッチするので、マッチ種別「主処理範囲」を付加してセッション処理部１３に渡す（図６のステップＳ５１において”ＹＥＳ”，Ｓ５６）。
セッション処理部１３は、マッチ種別「主処理範囲」の付加されたパケットが渡されると、それがセッション開設を要求するパケットであるので、セッション情報保持部１４にセッションβに関するセッション情報を登録（新規登録）すると共に、パケットをパケット転送部１５に渡す（図７のＳ６０１において”ＹＥＳ”，Ｓ６０２において”ＹＥＳ”，Ｓ６０３，Ｓ６０４）。
クラスタメンバ１−２内のトラフィック分散フィルタ１２は、上記パケットが旧主処理範囲ｍｆ２のみにマッチするので、マッチ種別「旧主処理範囲」を付加してセッション処理部１３に渡す（図６のＳ５２において”ＹＥＳ”，Ｓ５６）。
セッション処理部１３は、マッチ種別「旧主処理範囲」が付加されたパケットが渡されると、それがセッション開設を要求するものなので、破棄する（図７のステップＳ６０７において”ＹＥＳ”，Ｓ６０８において”ＹＥＳ”，Ｓ６０９）。つまり、クラスタメンバ１−１が上記パケットに対する主処理を担当するので、クラスタメンバ１−２は、上記パケットを破棄する。
クラスタメンバ１−３内のトラフィック分散フィルタ１２は、上記パケットが副処理範囲ｂｆ１，３’のみにマッチするのでマッチ種別「副処理範囲」を付加してセッション処理部１３に渡す（図６のステップＳ５４において”ＹＥＳ”，Ｓ５６）。
セッション処理部１３は、マッチ種別「副処理範囲」の付加されたパケットが渡されると、それがセッション開設を要求するものであるので、セッション情報保持部１４にセッションβに関するセッション情報を登録すると共に、上記パケットを破棄する（図８のステップＳ７０１において”ＹＥＳ”，Ｓ７０２において”ＹＥＳ”，Ｓ７０３，Ｓ７０４）。
以上は、クラスタシステム１内のクラスタメンバ１−４に故障が発生した場合の動作であるが、新たなクラスタメンバが追加された場合の動作は、次のようになる。
今、例えば、クラスタシステム１が３台のクラスタメンバ１−１〜１−３から構成され、クラスタシステム１で処理すべき全トラフィックがＴであるとする。また、各クラスタメンバ１−１〜１−３には、図１８（Ａ），（Ｂ）に示す主処理範囲ｍｆ１〜ｍｆ３及び副処理範囲ｂｆ１，１〜ｂｆ１，３が設定されているとする。即ち、クラスタメンバ１−１，１−２，１−３が担当している主処理に関する優先度「１」の副処理を、クラスタメンバ１−３，１−１，１−２が担当している。また、この時点では、旧主処理範囲および旧副処理範囲は設定されていないとする。
このような状態において、隣接ＩＰノード（例えば、隣接ＩＰノード２−１）からクラスタシステム１へパケットがマルチキャストされ、各クラスタメンバ１−１〜１−３が上記パケットを受信したとする。但し、このパケットは、セッションγに属するものとする。
クラスタメンバ１−１は、上記パケットが主処理範囲、旧主処理範囲、副処理範囲、旧副処理範囲の何れにもマッチしないので、上記パケットを破棄する（図６のステップＳ５５において”ＮＯ”、Ｓ５９）。
クラスタメンバ１−２は、上記パケットが副処理範囲ｂｆ１，２のみにマッチするので、セッション処理を実行する（ステップＳ５４において”ＹＥＳ”、Ｓ５６、Ｓ５７）。
クラスタメンバ１−３は、上記パケットが主処理範囲ｍｆ３にマッチするので、セッション処理を実行する（ステップＳ５１において”ＹＥＳ”、Ｓ５６、Ｓ５７）。
このような状態において、クラスタメンバ１−４が追加されたとすると、各クラスタメンバ１−１〜１−４内の範囲保持部１２１の内容が更新され、各クラスタメンバ１−１〜１−４が担当する主処理範囲、旧主処理範囲、副処理範囲及び旧副処理範囲が更新される（図１５のステップＳ１３１〜Ｓ１３４）。
今、例えば、各クラスタメンバ１−１〜１−４に、図１８（Ｃ）、（Ｄ）に示す主処理範囲ｍｆ１’〜ｍｆ４’及び副処理範囲ｂｆ１，１’〜ｂｆ１，４’が設定されたとする。なお、主処理範囲ｍｆ１〜ｍｆ３及び副処理範囲ｂｆ１，１〜ｂｆ１，３は、クラスタメンバ１−１〜１−３の旧主処理範囲及び旧副処理範囲となる。
その後、再び、隣接ＩＰノード２−１からセッションγに属するパケットが、クラスタシステム１に対してマルチキャストされたとすると、各クラスタメンバ１−１〜１−４において、上記パケットが受信される。
クラスタメンバ１−１内のトラフィック分散フィルタ１２は、上記パケットが主処理範囲、旧主処理範囲、副処理範囲、旧副処理範囲の何れにもマッチしないので、上記パケットを破棄する（図６のステップＳ５５において”ＮＯ”、Ｓ５９）。
クラスタメンバ１−２内のトラフィック分散フィルタ１２は、上記パケットが旧副処理範囲ｂｆ１，２のみにマッチするので、マッチ種別「旧副処理範囲」を付加してセッション処理部１３に渡す（図６のステップＳ５５において”ＹＥＳ”、Ｓ５６）。
セッション処理部１３は、マッチ種別「旧副処理範囲」の付加されたパケットが渡されると、そのパケットがセッション開設を要求するパケットでなく、且つ該当セッション情報がセッション情報保持部１４内に存在するので、セッション情報を更新した後、上記パケットを破棄する（図８のステップＳ７０７において”ＹＥＳ”、Ｓ７０８において”ＮＯ”、Ｓ７１０において”ＮＯ”、Ｓ７０９）。
クラスタメンバ１−３内のトラフィック分散フィルタ１２は、上記パケットが旧主処理範囲ｍｆ３と副処理範囲ｂｆ１，３’の両方にマッチするので、マッチ種別「旧主処理範囲、副処理範囲」を付加してセッション処理部１３に渡す（図６のステップＳ５３において”ＹＥＳ”、Ｓ５６）。
セッション処理部１３は、マッチ種別「旧主処理範囲、副処理範囲」の付加されたパケットがトラフィック分散フィルタ１２から渡されると、そのパケットがセッション開設を要求するものでなく、且つ、セッション情報保持部１４に該当するセッション情報が存在するので、セッション情報を更新した後、上記パケットをパケット転送部１５に渡す（図８のステップＳ７１３において”ＮＯ”、Ｓ７１６において”ＹＥＳ”、Ｓ７１７、Ｓ７１８）。
クラスタメンバ１−４内のトラフィック分散フィルタ１２は、上記パケットが主処理範囲ｍｆ４’にマッチするので、マッチ種別「主処理範囲」を付加してセッション処理部１３に渡す（図６のステップＳ５１において”ＹＥＳ”、Ｓ５６）。
セッション処理部１３は、マッチ種別「主処理範囲」の付加されたパケットが渡されると、そのパケットがセッション開設を要求するものでなく、且つ、セッション情報保持部１４に該当するセッション情報が存在しないので、上記パケットを破棄する（図７のステップＳ６０１において”ＹＥＳ”、Ｓ６０２において”ＮＯ”、Ｓ６０５において”ＮＯ”、Ｓ６０６）。
その後、隣接ＩＰノード２−１が、セッションδの開設を要求するパケットをクラスタシステム１に対してマルチキャストしたとすると、このパケットは、各クラスタメンバ１−１〜１−４で受信される。
クラスタメンバ１−１内のトラフィック分散フィルタ１２は、上記パケットが旧主処理範囲ｍｆ１と副処理範囲ｂｆ１，１’の両方にマッチするので、マッチ種別「旧主処理範囲、副処理範囲」を付加してセッション処理部１３に渡す（図６のステップＳ５３において”ＹＥＳ”、Ｓ５６）。
セッション処理部１３は、マッチ種別「旧主処理範囲、副処理範囲」の付加されたパケットが渡されると、それがセッションの開設を要求するものであるので、セッション情報を更新（セッションδのセッション情報をセッション情報保持部１４に登録）した後、上記パケットを破棄する（図８のステップＳ７１３において”ＹＥＳ”、Ｓ７１４、Ｓ７１５）。
クラスタメンバ１−２内のトラフィック分散フィルタ１２は、上記パケットが主処理範囲ｍｆ２’にマッチするので、マッチ種別「主処理範囲」を付加してセッション処理部１３に渡す（図６のステップＳ５１において”ＹＥＳ”、Ｓ５６）。
セッション処理部１３は、マッチ種別「主処理範囲」の付加されたパケットが渡されると、それがセッションδの開設を要求するパケットであるので、セッション情報をセッション情報保持部１４に登録（セッションδのセッション情報を新規登録）すると共に、上記パケットをパケット転送部１５に渡す（図７のステップＳ６０１，Ｓ６０２において共に”ＹＥＳ”、Ｓ６０３、Ｓ６０４）。
クラスタメンバ１−３内のトラフィック分散フィルタ１２は、上記パケットが旧副処理範囲のみにマッチするので、マッチ種別「旧副処理範囲」を付加してセッション処理部１３に渡す（図６のステップＳ５５において”ＹＥＳ”、Ｓ５６）。
セッション処理部１３は、上記パケットがセッションδの開設を要求するものであるので、破棄する（図８のステップＳ７０７，Ｓ７０８において”ＹＥＳ”、Ｓ７０９）。
クラスタメンバ１−４内のトラフィック分散フィルタ１２は、上記パケットが主処理範囲、旧主処理範囲、副処理範囲、旧副処理範囲の何れにもマッチしないので、上記パケットを破棄する（図６のステップＳ５５において”ＮＯ”、Ｓ５９）。
なお、以上の説明では述べなかったが、各クラスタメンバにおいて、トラフィック分散フィルタ１２内の範囲保持部１２１に格納されている旧主処理範囲，旧副処理範囲の内、関連するセッション（自クラスタメンバにおいて、開設処理を行ったセッション）が全くなくなった旧主処理範囲，旧副処理範囲は削除するようにしても良い。つまり、旧主処理範囲および旧副処理範囲は、その範囲内に関連するセッションが存在する場合のみ有効で、関連するセッションが存在しない場合は無意味なものとなるので、上記したようにする。このようにすることにより、トラフィック分散フィルタ１２で比較対象にする処理範囲数が少なくなるので、処理速度を向上させることができる。
〔発明の他の実施例〕
上述した実施例では、主処理を行っているクラスタメンバが故障した場合、副処理を行っていたクラスタメンバは、自身の主処理に加えて、該当する副処理を主処理に切り替えて処理を行う（ｆａｉｌｏｖｅｒ処理）。トラフィックの処理範囲が再分割され、処理中のセッションが消えれば、各メンバの負荷は再び平均化されるが、短期的にはｆａｉｌｏｖｅｒ後は処理が特定のクラスタメンバに偏る。
本実施例では、各クラスタメンバが担当するトラフィックの範囲の分割を次のように微細に定めることにより、ｆａｉｌｏｖｅｒ後の処理負荷の偏りを低減する。
すなわち、クラスタメンバ数がｎであるとき、トラフィック全体をｎ（ｎ−１）個に分割する。各クラスタメンバは、主処理として、この内の（ｎ−１）個を担当する。また、各クラスタメンバは、副処理として、他の何れかのクラスタメンバが主処理を担当する分割を（ｎ−１）個担当する。但し、この分割は、全て異なるクラスタメンバが主処理を行っている範囲から取るようにする。
すなわち、ある副処理について、ｂｆｉ，ｋを、クラスタメンバ１−ｉが処理する副処理のｋ個目であるとすると、
ｂｆｉ＝ｂｆｉ，１ ∪ ｂｆｉ，２∪…∪ ｂｆｉ，（ｎ−１）である。
ここで、
ｍｆｊ ∩ ｂｆｉ，ｋ＝φ（ただしｋ≠ｊ）
ｂｆ１，ｉ ∪．．．∪ ｂｆ（ｉ−１），ｉ ∪ ｂｆ（ｉ＋１），ｉ ∪．．．∪ ｂｆｎ，ｉ＝ｍｆｉ
となるように、クラスタメンバ１−ｉの副処理範囲ｂｆｉを定める。
割り当ての例を図１９に示す。
このとき、或るクラスタメンバ１−ｉが故障したとすると、他のクラスタメンバの副処理の内、クラスタメンバ１−ｉの主処理に該当する部分だけが主処理に切り替わるため、特定のメンバの主処理が片寄って増加することはなく、全メンバに均一に負荷が分散される。
また、上述した実施例では説明しなかったが、クラスタメンバの経路制御およびパケット転送の機能をＬ３スイッチ相当に置き換えても同様の効果を得ることができる。
以上説明した本発明にかかる第１〜第５のクラスタシステム、第１のクラスタメンバ、第１の故障復旧方法および第１のプログラムによれば、セッション情報をクラスタメンバ間で交換し合うことなく、故障復旧処理を行うことが可能になる。その結果、セッション情報をクラスタメンバ間で交換し合っていた従来の技術に比較して、故障復旧処理を迅速に行うことが可能になると共に、スケーラビリティを高くすることができる。その理由は、副処理を担当しているクラスタメンバにおいて、セッション情報の記録更新処理を行っており、主処理を担当しているクラスタメンバにおいて故障が発生した場合には、副処理を担当しているクラスタメンバが、自クラスタメンバ内に記録されているセッション情報を利用して処理を引き継ぐようにしているからである。
また、本発明にかかる第３のクラスタシステムによれば、各クラスタメンバ間でセッション情報を交換し合わなくとも、故障クラスタメンバの発生時や、新規クラスタメンバの追加時に、各クラスタメンバが担当する主処理範囲や副処理範囲を変更することが可能になる。その理由は、各クラスタメンバにおいて、範囲決定ルールに基づいて新たな主処理範囲および副処理範囲を決定し、それまでの主処理範囲および副処理範囲を旧主処理範囲および旧副処理範囲とするようにしているからである。
〔実施例の構成の説明〕
図１は本発明にかかるクラスタシステムの一実施例の構成例を示すブロック図である。同図に示すように、本実施例のクラスタシステム１は、ｎ個（複数個）のクラスタメンバ１−１〜１−ｎを備えており、各クラスタメンバ１−１〜１−ｎは、それぞれデータリンク３−１〜３−ｍを介して隣接ＩＰノード２−１〜２−ｍと接続されている。
図２は、クラスタメンバ１−ｉ（１≦ｉ≦ｎ）の構成例を示すブロック図である。
各クラスタメンバ１−ｉは、各データリンク３−１〜３−ｍ毎のインタフェース部（ＩＦ部）１１−１〜１１−ｍと、トラフィック分散フィルタ１２と、セッション処理部１３と、セッション情報保持部１４と、パケット転送部１５と、ルーティングテーブル１６と、分散処理制御部１７と、広告メッセージ処理部１８と、死活監視タイマ部１９と、故障復旧部２０とから構成されている。
インタフェース部１１−ｊ（１≦ｊ≦ｍ）は、パケット転送部１５から渡されたパケットや広告メッセージをデータリンク３−ｊへ送出する機能や、データリンク３−ｊを介して送られてくる、クラスタシステム１固有のＩＰアドレス（クラスタ用アドレス）を宛先として含んだパケットや、自クラスタメンバ１−ｉ固有のＩＰアドレス（メンバ個別アドレス）を宛先として含んだパケット（個々のクラスタメンバが制御用に使用するパケット）や、上記クラスタ用アドレスに対応する所定のデータリンクマルチキャストアドレスを宛先として含んだパケットや、他のクラスタメンバからの広告メッセージを受信する機能を有する。
トラフィック分散フィルタ１２は、範囲保持部１２１を備えている。この範囲保持部１２１には、自クラスタメンバ１−ｉが現在主処理を担当しているトラフィックの範囲（主処理範囲）と、過去において主処理を担当していたトラフィックの範囲（旧主処理範囲）と、現在副処理を担当しているトラフィックの範囲（副処理範囲）と、過去において副処理を担当していたトラフィックの範囲（旧副処理範囲）とが格納されている。
そして、トラフィック分散フィルタ１２は、インタフェース部１１−ｊがデータリンクマルチキャストアドレスを宛先にしたパケットを受信したとき、上記各処理範囲に基づいて、上記パケットを通過させるか（セッション処理部１３に渡すか）、破棄するかを決定する。なお、旧主処理範囲及び旧副処理範囲は、範囲保持部１２１に格納されていない場合もある。
図３，図４に範囲保持部１２１の内容例を示す。図３の例は、主処理範囲ｍｆｉ及び副処理範囲ｂｆ１，ｉ〜ｂｆＰ，ｉにマッチするパケットを通過させ、それ以外のパケットは破棄することを示している。また、図４の例は、主処理範囲ｍｆｉ’、旧主処理範囲ｍｆｉ、副処理範囲ｂｆ１，ｉ’〜ｂｆＰ，ｉ’及び旧副処理範囲ｂｆ１，ｉ〜ｂｆＰ，ｉにマッチするパケットを通過させ、それ以外のパケットは破棄することを示している。
なお、主処理と副処理との違いは、後の説明で明らかになるが、パケット転送部１５において、パケットを送出方路に出力するか、破棄するかの違いがあるだけであり、それ以外は同じ処理が行われる。
セッション処理部１３は、トラフィック分散フィルタ１２を通過したパケットに対して、セッション処理を行う。このセッション処理においては、パケットが属するセッションを識別する処理や、セッション情報保持部１４に保持されているセッション状態を示すセッション情報を更新，削除する処理や、セッション情報保持部１４に新たなセッション情報を登録する処理（セッション開設時）や、パケットのヘッダ情報とセッション情報とに基づいて不正なパケットを破棄する処理を含む処理が行われる。
ここで、セッションとは、ＩＰの拡張プロトコルおよび上位層プロトコルにより提供される仮想通信路を指し、例えば、ＴＣＰのコネクション，ＩＰｓｅｃのＳｅｃｕｒｉｔｙ Ａｓｓｏｃｉａｔｉｏｎなどが含まれる。また、セッション状態とは、これらのセッション毎に保持される固有の情報を指し、ＴＣＰのコネクションの場合は、コネクションの状態，シーケンス番号，応答番号などを含む。また、ＩＰｓｅｃ ＳＡの場合には、ＲＦＣ２４０１で定められるＳＡのパラメータを含む。
パケット転送部１５は、セッション処理部１３から渡されたパケットや、インタフェース部１１−ｊが受信した、宛先がデータリンクマルチキャストアドレス以外のパケットの送出方路を、ルーティングテーブル１６の内容と上記パケットの宛先とに基づいて決定し、次ホップノードへ転送する機能を有する。
死活監視タイマ部１９には、クラスタシステム１を構成する各クラスタメンバ１−１〜１−ｎ毎の死活監視タイマ（図示せず）が設けられている。各死活監視タイマは、リセット後、所定時間Ｔｏｕｔが経過すると、タイムアウト状態になる。
広告メッセージ処理部１８は、所定時間Ｔｓ（Ｔｓ＜Ｔｏｕｔ）毎に、クラスタシステム１内の他のクラスタメンバに対して広告メッセージを送信する機能や、他のクラスタメンバ１−ｋ（１≦ｋ≦ｎ）からの広告メッセージを受信した時、死活監視タイマ部１９に設けられているクラスタメンバ１−ｋ用の死活監視タイマをリセットする機能や、受信した広告メッセージに基づいて新たなクラスタメンバが追加されたことを検出した時、分散処理制御部１７に対して新規メンバ追加指示を出力する機能などを有する。
故障復旧部２０は、死活監視タイマ部１９内に設けられている、各クラスタメンバ１−１〜１−ｎ毎の死活監視タイマの状態を常時監視し、故障の発生したクラスタメンバを検出する機能や、タイムアウト状態になった死活監視タイマを検出したとき（故障の発生したクラスタメンバを検出したとき）、分散処理制御部１７に対して故障したクラスタメンバの識別子を含むタイムアウト通知を行う機能や、故障の発生したクラスタメンバが行っていた主処理を引き継ぐことが必要であるか否かを判定し、引き継ぐことが必要な場合は、トラフィック分散フィルタ１２内の範囲保持部１２１の内容を書き換える機能などを有する。
分散処理制御部１７は、識別子保持部１７１と、クラスタメンバリスト１７２と、範囲決定ルール保持部１７３とを備えている。
識別子保持部１７１には、自クラスタメンバ１−ｉ固有の識別子（例えば、ＩＤｉ）が格納されている。
クラスタメンバリスト１７２には、クラスタシステム１を構成している各クラスタメンバ１−１〜１−ｎの、クラスタメンバリスト１７２内での位置を示す番号と、識別子と、現時点で主処理を担当している範囲（主処理範囲）と、現時点で副処理を担当している範囲（副処理範囲）とが設定されている。
図５にクラスタメンバリスト１７２の一例を示す。図５の例は、番号「ｉ」、識別子「ＩＤｉ」のクラスタメンバ１−ｉは、主処理範囲ｍｆｉにマッチするパケットに対する主処理と、副処理範囲ｂｆ１，ｉ〜ｂｆＰ，ｉにマッチするパケットに対する優先度「１」〜「Ｐ」の副処理とを担当していることを示している。ここで、Ｐは、１≦Ｐ≦（ｎ−１）を満たすものであれば、任意の値（整数）とすることができる。
範囲決定ルール保持部１７３には、クラスタシステム１を構成している各クラスタメンバ１−１〜１−ｎに担当させる主処理範囲ｍｆ１〜ｍｆｎを決定するための主処理範囲決定ルールと、各クラスタメンバ１−１〜１−ｎに担当させる副処理範囲ｂｆ１，１〜ｂｆＰ，ｎを決定するための副処理範囲決定ルールとが格納されている。
主処理範囲決定ルールによって決定される、各クラスタメンバ１−１〜１−ｎが担当する主処理範囲ｍｆ１〜ｍｆｎは、互いに重複せず、且つ、処理すべき全トラフィックを網羅しなければならない。今、例えば、処理すべき全トラフィックをＴ、空集合をφとすると、主処理範囲決定ルールは、次式（１），（２）を満たす主処理範囲ｍｆ１〜ｍｆｎを決定可能なものでなくてはならない。
ｍｆ１∪ｍｆ２∪ … ∪ｍｆｎ＝Ｔ…（１）
ｍｆ１∩ｍｆ２∩ … ∩ｍｆｎ＝φ…（２）
このような条件を満たす主処理範囲決定ルールとしては、例えば、次のようなものを採用することができる。
番号「１」〜「ｎ」のクラスタメンバ１−１〜１−ｎの主処理範囲ｍｆ１〜ｍｆｎを、それぞれ「０」〜「ｎ−１」とする主処理範囲決定ルール。ここで、主処理範囲ｍｆ１〜ｍｆｎ（「０」〜「ｎ−１」）は、パケットのＩＰ送信元アドレスとＩＰ宛先アドレスとに対して可換な演算（例えば、両者の加算或いは乗算）を行い、その演算結果をクラスタ数「ｎ」で除算した時の余りを示す。なお、主処理範囲決定ルールは、これに限られるものではなく、上記した式（１），（２）を満たす主処理範囲を決定できるものであれば、どのようなものであっても良い。
また、副処理範囲決定ルールによって決定される、各クラスタメンバ１−１〜１−ｎが担当する優先度Ｐの副処理範囲ｂｆＰ，１〜ｂｆＰ，ｎは、互いに重複せず、且つ、処理すべき全トラフィックＴを網羅しなければならない。また、各クラスタメンバにおいて、そのクラスタメンバ１−ｉが担当している主処理範囲ｍｆｉと、そのクラスタメンバ１−ｉが担当する優先度「１」〜「Ｐ」の副処理範囲ｂｆ１，ｉ〜ｂｆＰ，ｉとは重複してはならない。つまり、副処理範囲決定ルールは、次式（３）〜（５）を満たす副処理範囲ｂｆＰ，１〜ｂｆＰ，ｎを決定可能なものでなくてはならない。
ｂｆＰ，１ ∪ ｂｆＰ，２ ∪…∪ ｂｆＰ，ｎ＝Ｔ …（３）
ｂｆＰ，１ ∩ ｂｆＰ，２ ∩…∩ ｂｆＰ，ｎ＝φ …（４）
ｍｆｉ ∩ ｂｆ１，ｉ ∩ ｂｆ２，ｉ ∩…∩ ｂｆＰ，ｉ …（５）
また、分散処理制御部１７は、広告メッセージ処理部１８から新規メンバ追加指示が入力された場合や、故障復旧部２０からタイムアウト通知が入力された場合、範囲決定ルール保持部１７３に格納されている主処理範囲決定ルール及び副処理範囲決定ルールに従って各クラスタメンバ１−１〜１−ｎの主処理範囲及び副処理範囲を決定する機能や、クラスタメンバリスト１７２の内容を更新する機能や、トラフィック分散フィルタ１２内の範囲保持部１２１の内容を更新する機能などを有する。
なお、クラスタメンバ１−ｉはコンピュータによって実現可能なものであり、コンピュータによってクラスタメンバ１−ｉを実現する場合は、次のようにする。クラスタメンバ用のプログラムを記録したディスク、半導体メモリ、その他の記録媒体を用意する。コンピュータは、上記プログラムを読み込み、自身の動作を制御することにより、インタフェース部１１−１〜１１−ｍ、トラフィック分散フィルタ１２、セッション処理部１３、パケット転送部１５、ルーティングテーブル１６、分散処理制御部１７、広告メッセージ処理部１８、死活監視タイマ部１９、故障復旧部２０を実現する。
〔実施例の動作の説明〕
次に、上記のように構成される本実施例のクラスタシステムの動作について詳細に説明する。
〔データリンクマルチキャストアドレスを宛先にしたパケットの受信処理〕
先ず、隣接ＩＰノード２−ａ（１≦ａ≦ｍ）からクラスタシステム１を次ホップとして送信されたパケットの処理について説明する。隣接ＩＰノード２−ａは、クラスタシステム１のクラスタ用アドレスを次ホップとするパケットについては、上記クラスタ用アドレスに対応するデータリンクマルチキャストアドレス宛に送信する。
各クラスタメンバ１−１〜１−ｎは、上記マルチキャストされたパケットを受信すると、図６のフローチャートに示す処理を行う。
クラスタメンバ１−ｉ内のトラフィック分散フィルタ１２は、マルチキャストされたパケットをインタフェース部１１−ａを介して受信すると、先ず、そのパケットが、主処理範囲にマッチしているか否かを調べる（ステップＳ５１）。そして、主処理範囲にマッチしている場合には、上記パケットにマッチ種別「主処理範囲」を付加してセッション処理部１３に渡す（ステップＳ５６）。
これに対して、主処理範囲にマッチしていない場合は、旧主処理範囲のみにマッチしているか、旧主処理範囲と副処理範囲の両方にマッチしているか、副処理範囲のみにマッチしているか、それとも旧副処理範囲にマッチしているかを調べる（ステップＳ５２〜Ｓ５５）。
旧主処理範囲のみにマッチしている場合は、パケットにマッチ種別「旧主処理範囲」を付加してセッション処理部１３に渡す（ステップＳ５２において”ＹＥＳ”、Ｓ５６）。
旧主処理範囲と副処理範囲の両方にマッチしている場合は、マッチ種別「旧主処理範囲、副処理範囲」を付加してセッション処理部１３に渡す（ステップＳ５３において”ＹＥＳ”、Ｓ５６）。
副処理範囲のみにマッチする場合は、マッチ種別「副処理範囲」を付加してセッション処理部１３に渡す（ステップＳ５４において”ＹＥＳ”、Ｓ５６）。
旧副処理範囲にマッチする場合は、マッチ種別「旧副処理範囲」を付加してセッション処理部１３に渡す（ステップＳ５５において”ＹＥＳ”、Ｓ５６）。
いずれの範囲にもマッチしない場合は、パケットを破棄する（ステップＳ５５において”ＮＯ”、Ｓ５９）。なお、範囲保持部１２１に旧主処理範囲、旧副処理範囲が格納されていない場合には、旧主処理範囲、旧副処理範囲とはマッチしないことになる。
セッション処理部１３は、トラフィック分散フィルタ１２からマッチ種別の付加されたパケットが渡されると、セッション処理を行う（ステップＳ５７）。このステップＳ５７で行うセッション処理について、図７，図８を参照して詳細に説明する。
セッション処理部１３は、トラフィック分散フィルタ１２からマッチ種別「主処理範囲」の付加されたパケットが渡されると（図７のステップＳ６０１において”ＹＥＳ”）、そのパケットがセッションの開設を要求するものであるか否かを判断する（ステップＳ６０２）。
そして、セッションの開設を要求するパケットであった場合は、セッション情報保持部１４に上記パケットが属するセッションのセッション情報を登録すると共に、上記パケットを処理する（ステップＳ６０３，Ｓ６０４）。
ステップＳ６０４では、不正パケットを破棄する処理などを行う（破棄しなかったパケットは、パケット転送部１５に渡す）。
これに対して、セッションの開設を要求するパケットでなかった場合（ステップＳ６０２において”ＮＯ”）は、上記パケットのヘッダ情報に基づいて、セッション情報保持部１４に上記パケットが属するセッションのセッション情報が存在するか否かを調べる（ステップＳ６０５）。
そして、存在しない場合（自クラスタメンバが上記パケットが属するセッションの開設処理を行っていない場合）は、パケットを破棄し（ステップＳ６０６）、存在する場合（自クラスタメンバが上記パケットが属するセッションの開設処理を行っている場合）は、セッション情報を更新すると共にパケットを処理する（ステップＳ６０３，Ｓ６０４）。なお、パケットがセッション終了を要求するパケットである場合には、ステップＳ６０３において、セッション情報保持部１４に格納されている上記パケットが属するセッションのセッション情報を削除する処理が行われる。
また、トラフィック分散フィルタ１２からマッチ種別「旧主処理範囲」の付加されたパケットが渡された場合（ステップＳ６０７において”ＹＥＳ”）は、そのパケットがセッションの開設を要求するものであるか否かを判断する（ステップＳ６０８）。
そして、セッションの開設を要求するものである場合は、破棄し（ステップＳ６０９）、そうでない場合は、上記パケットが属するセッションのセッション情報がセッション情報保持部１４に格納されているか否かを調べる（ステップＳ６１０）。
該当するセッション情報が存在しなかった場合には、パケットを廃棄し（ステップＳ６０９）、存在する場合には、セッション情報保持部１４に格納されている該当するセッション情報を更新すると共に、不正パケットを破棄するなどの処理を行う（ステップＳ６１１，Ｓ６１２）。
また、トラフィック分散フィルタ１２からマッチ種別「副処理範囲」の付加されたパケットが渡された場合（図８のステップＳ７０１において”ＹＥＳ”）は、セッション処理部１３は、先ず、そのパケットがセッションの開設を要求するものであるか否かを判定する（ステップＳ７０２）。
そして、セッションの開設を要求するものである場合は、セッション情報保持部１４に上記パケットのセッション情報を登録すると共に、上記パケットを破棄する（ステップＳ７０３，Ｓ７０４）。
これに対して、セッションの開設を要求するものでない場合は、上記パケットが属するセッションのセッション情報がセッション情報保持部１４に格納されているか否かを調べる（ステップＳ７０５）。
そして、該当するセッション情報が存在する場合は、セッション情報を更新すると共に、パケットを破棄し（ステップＳ７０３，Ｓ７０４）、存在しない場合は、上記パケットを破棄する（ステップＳ７０６）。
また、トラフィック分散フィルタ１２からマッチ種別「旧副処理範囲」の付加されたパケットが渡された場合（ステップＳ７０７において”ＹＥＳ”）は、そのパケットがセッションの開設を要求するものか否かを調べる（ステップＳ７０８）。
そして、セッションの開設を要求するパケットである場合には、廃棄処理を行い（ステップＳ７０９）、そうでない場合は、セッション情報保持部１４に該当するセッション情報が格納されているか否かを調べる（ステップＳ７１０）。
該当するセッション情報が存在しない場合は、パケットを破棄し（ステップＳ７０９）、存在する場合は、セッション情報を更新すると共にパケットを破棄する（ステップＳ７１１，Ｓ７１２）。
また、トラフィック分散フィルタ１２からマッチ種別「旧主処理範囲、副処理範囲」の付加されたパケットが渡された場合（ステップＳ７０７において”ＮＯ”）は、そのパケットがセッションの開設を要求するものか否かを調べる（ステップＳ７１３）。
そして、セッションの開設を要求するパケットである場合は、開設するセッションのセッション情報をセッション情報保持部１４に登録した後、そのパケットを破棄する（ステップＳ７１４，Ｓ７１５）。
これに対して、セッション開設を要求するパケットでない場合は、セッション情報保持部１４に該当するセッション情報が登録されているか否かを調べる（ステップＳ７１６）。
そして、登録されていない場合は、パケットを破棄し（ステップＳ７１５）、登録されている場合は、セッション情報保持部１４に登録されているセッション情報を更新すると共に、上記パケットをパケット転送部１５に渡す（ステップＳ７１７，Ｓ７１８）。
再び図６に示す処理に戻り、パケット転送部１５は、セッション処理部１３からパケット（マッチ種別はセッション処理部１３で削除されている）が渡されると、パケット転送処理を実行する（ステップＳ５８）。
このステップＳ５８で行うパケット転送処理では、図９のフローチャートに示すように、パケットのＩＰ宛先アドレスに基づいてルーティングテーブル１６を検索することにより送出方路を求め、求めた送出方路に対応したインタフェース部を介してパケットを送出する（ステップＳ８１，Ｓ８２）。なお、パケット転送部１５は、インタフェース部１１−１〜１１−ｍを介して受信した、データリンクマルチキャストアドレスを宛先としないパケットについても同様の処理を行う。
〔広告メッセージの送信処理〕
次に、広告メッセージの送信処理について説明する。クラスタメンバ１−ｉ内の広告メッセージ処理部１８は、図１０のフローチャートに示すように、広告メッセージの送信タイミングになる毎に（ステップＳ９１において”ＹＥＳ”）、クラスタメンバリスト１７２に格納されている全ての識別子（自クラスタメンバ１−ｉがクラスタシステム１内に存在していると認識しているクラスタメンバの識別子）と、識別子保持部１７１に格納されている自クラスタメンバ１−ｉの識別子とを取得し（ステップＳ９２）、それらを含む広告メッセージを、クラスタシステム１内の他のクラスタメンバへ送信する（ステップＳ９３）。
その際、広告メッセージ処理部１８は、クラスタ用ＩＰアドレス以外の所定のマルチキャストまたはブロードキャストアドレスを用いて広告メッセージを送信する。
また、ステップＳ９１では、前回広告メッセージを送信してから所定時間Ｔｓが経過したか否かに基づいて送信タイミングになったか否かを判断しており、上記所定時間Ｔｓは、死活監視タイマのタイムアウト時間Ｔｏｕｔよりも短い時間である。即ち、Ｔｓ＜Ｔｏｕｔの関係を満たしている。また、新規にクラスタシステム１に追加されたクラスタメンバ内のクラスタメンバリスト１７２には、自クラスタメンバの識別子しか格納されていない。
〔広告メッセージの受信処理〕
次に広告メッセージの受信処理について説明する。クラスタメンバ１−ｉ内の広告メッセージ処理部１８は、クラスタシステム１内の他のクラスタメンバ（例えば、クラスタメンバ１−ｎ）からの広告メッセージを受信すると、図１１のフローチャートに示すように、広告メッセージに含まれている送信元クラスタメンバ１−ｎの識別子が、クラスタメンバリスト１７２に登録されているか否かを調べる（ステップＳ１０１）。
そして、クラスタメンバ１−ｎの識別子がクラスタメンバリスト１７２に登録されていると判断した場合（ステップＳ１０１において”ＹＥＳ”）は、死活監視タイマ部１９内に設けられている、クラスタメンバ１−ｎ用の死活監視タイマ（図示せず）をリセットし、その後、分散処理制御部１７に対して広告メッセージに含まれている全識別子を渡す（ステップＳ１０２，Ｓ１０３）。
これに対して、登録されていないと判断した場合（ステップＳ１０１において”ＮＯ”）は、クラスタシステム１に新規クラスタメンバが追加されたと認識し、分散処理制御部１７に対して新規メンバ追加指示を出力する（ステップＳ１０４）。
この新規メンバ追加指示には、広告メッセージの送信元クラスタメンバ１−ｎの識別子が含まれる。
その後、広告メッセージ処理部１８は、死活監視タイマ部１９内に新規クラスタメンバ１−ｎ用の死活監視タイマを生成する（ステップＳ１０５）。なお、死活監視タイマ部１９内に設けられている各死活監視タイマは、それぞれリセットされてから所定時間Ｔｏｕｔが経過するとタイムアウト状態になるものである。
〔故障復旧処理（ｆａｉｌｏｖｅｒ処理）〕
次に故障復旧処理について説明する。クラスタメンバ１−ｉ内の故障復旧部２０は、図１２のフローチャートに示すように、死活監視タイマ部１９内に設けられている各クラスタメンバ用の死活監視タイマの内の１つに注目し、その死活監視タイマがタイムアウト状態になっているか否かを調べる（ステップＳ１１１，Ｓ１１２）。
そして、タイムアウト状態になっていない場合（ステップＳ１１２において”ＮＯ”）は、次の死活監視タイマに注目する（ステップＳ１１１）。
これに対して、現在注目している死活監視タイマ（例えば、クラスタメンバ１−ｎ用の死活監視タイマ）がタイムアウト状態になっている場合（ステップＳ１１２において”ＹＥＳ”）は、自クラスタメンバ１−ｉが、クラスタメンバ１−ｎが主処理を担当しているトラフィックに関し、優先度「１」の副処理を担当しているか否かを判断する（ステップＳ１１３）。この判断は、クラスタメンバリスト１７２を参照して行う。
そして、優先度「１」の副処理を担当している場合（ステップＳ１１３において”ＹＥＳ”）は、トラフィック分散フィルタ１２内の範囲保持部１２１の内容を更新し、クラスタメンバ１−ｎが主処理を担当していたトラフィックの範囲についても、自クラスタメンバ１−ｉで主処理を担当するようにする（ステップＳ１１４）。
例えば、範囲保持部１２１の内容が図３に示すものである場合は、その内容を図１３に示すように変更する。つまり、主処理範囲に、ｂｆ１，ｉを追加し、副処理範囲からｂｆ１，ｉを削除する。なお、図３，図１３において、ｂｆ１，ｉは、クラスタメンバ１−ｎが主処理を担当していた主処理範囲と同一の範囲を示す。
これに対して、優先度「１」の副処理を担当していない場合（ステップＳ１１３において”ＮＯ”）は、クラスタメンバ１−ｎが担当している副処理の中に、自クラスタメンバ１−ｉが担当している副処理とトラフィック範囲が同じで、且つ優先度が自クラスタメンバ１−ｉで担当している副処理よりも高いものがあるか否かを判断する（ステップＳ１１７）。
そして、そのような副処理が存在する場合（ステップＳ１１７において”ＹＥＳ”）は、該当する副処理範囲の優先度を１つ上げる（ステップＳ１１８）。
例えば、範囲保持部１２１の内容が、図３に示すものである場合は、その内容を図１４に示すように変更する。つまり、ｂｆ２，ｉの優先度を「２」から「１」に変更する（優先度を１つ上げる）。なお、図３，図１４において、ｂｆ２，１は、クラスタメンバ１−ｎが優先度「１」の副処理を担当していたトラフィック範囲と同一の範囲を示す。
これに対して、上記した条件を満たす副処理が存在しない場合（ステップＳ１１７において”ＮＯ”）は、ステップＳ１１５の処理を行う。なお、ステップＳ１１５は、ステップＳ１１４或いはステップＳ１１８の終了後にも実行される。
ステップＳ１１５において、故障復旧部２０は、分散処理制御部１７に対してタイムアウト通知を行う。このタイムアウト通知には、タイムアウト状態になった死活監視タイマに対応するクラスタメンバ１−ｎの識別子が含まれている。その後、故障復旧部２０は、死活監視タイマ部１９からクラスタメンバ１−ｎ用の死活監視タイマを削除し（ステップＳ１１６）、再び、ステップ３１１１の処理を行う。
〔新規メンバ追加処理〕
次に、分散処理制御部１７が行う新規メンバ追加処理について説明する。クラスタメンバ１−ｉ内の分散処理制御部１７は、広告メッセージ処理部１８から新規メンバ追加指示が入力されると、図１５のフローチャートに示す処理を行う。なお、新規メンバ追加指示には、新規に追加されたクラスタメンバの識別子としてクラスタメンバ１−ｘの識別子が含まれているとする。
先ず、分散処理制御部１７は、範囲決定ルール保持部１７３に格納されている主処理範囲決定ルール及び副処理範囲決定ルールを使用して、クラスタシステム１内の各クラスタメンバの主処理範囲及び副処理範囲を決定する（ステップＳ１３１）。つまり、クラスタメンバリスト１７２に識別子が格納されている各クラスタメンバ及び追加されたクラスタメンバ１−ｘの主処理範囲及び副処理範囲を決定する。
次に、分散処理制御部１７は、各クラスタメンバの情報（識別子、主処理範囲、副処理範囲）を、識別子をキーにしてソートし、ソート順に番号を付してクラスタメンバリスト１７２に格納する（ステップＳ１３２）。
その後、分散処理制御部１７は、自クラスタメンバ１−ｉが認識しているクラスタシステム構成と、他のクラスタメンバが認識しているクラスタシステム構成が全て同じであるか否かを判断する（ステップＳ１３３）。
この判断は、図１１のステップＳ１０３において、広告メッセージ処理部１８から入力される、広告メッセージ中の全識別子に基づいて行う。つまり、自クラスタメンバ１−ｉがクラスタシステム１内に存在していると認識している各クラスタメンバから広告メッセージが送られてきており、且つ、上記各クラスタメンバから送られてきた広告メッセージ中の全識別子と、自クラスタメンバ１−ｉ内のクラスタメンバリスト１７２に格納されている識別子とが一致する場合、全クラスタメンバが認識しているクラスタシステム構成が同じであると判断する。
ステップＳ１３３において、全クラスタメンバが認識しているクラスタシステム構成が同じであると認識すると、分散処理制御部１７は、トラフィック分散フィルタ１２内の範囲保持部１２１の内容を更新する（ステップＳ１３４）。つまり、現時点において、主処理範囲，副処理範囲であったものを、それぞれ旧主処理範囲，旧副処理範囲とし、ステップＳ１３１で決定した主処理範囲，副処理範囲をそれぞれ主処理範囲，副処理範囲とする。例えば、範囲保持部１２１の内容が図３に示すものであった場合、ステップＳ１３４の処理を行うことにより、その内容は、例えば図４に示すように変更される。
〔タイムアウト通知受信処理〕
次に、分散処理制御部１７が行うタイムアウト通知受信処理について説明する。分散処理制御部１７は、故障復旧部２０からタイムアウト通知が入力されると、図１６のフローチャートに示す処理を行う。なお、タイムアウト通知には、タイムアウトが発生したクラスタメンバの識別子としてクラスタメンバ１−ｎの識別子が含まれているとする。
先ず、分散処理制御部１７は、分散処理制御部１７からクラスタメンバ１−ｎのエントリを削除する（ステップＳ１４１）。
次に、範囲決定ルール保持部１７３に格納されている主処理範囲決定ルール及び副処理範囲決定ルールに基づいて、クラスタメンバリスト１７２に識別子が格納されている各クラスタメンバの主処理範囲及び副処理範囲を決定し、決定した主処理範囲及び副処理範囲に基づいてクラスタメンバリスト１７２を更新する（ステップＳ１４２，１４３）。
その後、分散処理制御部１７は、全てのクラスタメンバが認識しているクラスタシステム構成が同じであるか否かを判断し（ステップＳ１４４）、そうである場合は、トラフィック分散フィルタ１２内の範囲保持部１２１の内容を更新する（ステップＳ１４５）。なお、ステップＳ１４５では、前述したステップＳ１３４と同様の処理が行われる。
次に、具体例を挙げて本実施例の動作を説明する。
今、例えば、クラスタシステム１が４台のクラスタメンバ１−１〜１−４から構成され、クラスタシステム１で処理すべき全トラフィックがＴであるとする。また、各クラスタメンバ１−１〜１−４には、図１７（Ａ），（Ｂ）に示す主処理範囲ｍｆ１〜ｍｆ４及び副処理範囲ｂｆ１，１〜ｂｆ１，４が設定されているとする。即ち、クラスタメンバ１−１，１−２，１−３，１−４が担当している主処理に関する優先度「１」の副処理を、クラスタメンバ１−４，１−１，１−２，１−３が担当している。また、この時点では、旧主処理範囲および旧副処理範囲は設定されていないとする。
このような状態において、隣接ＩＰノード（例えば、隣接ＩＰノード２−１）からクラスタシステム１へパケットがマルチキャストされ、各クラスタメンバ１−１〜１−４が上記パケットを受信したとする。但し、このパケットは、セッションαに属するものとする。
クラスタメンバ１−１，１−２は、上記パケットが主処理範囲、旧処理範囲、副処理範囲、旧副処理範囲の何れにもマッチしないので、パケットを破棄する（図６のステップ５５において全て”ＮＯ”、Ｓ５９）。
クラスタメンバ１−３は、上記パケットが副処理範囲ｂｆ１，３のみにマッチするので、上記パケットに対するセッション処理を実行する（ステップＳ５４において”ＹＥＳ”、Ｓ５６、Ｓ５７）。
また、クラスタメンバ１−４は、上記パケットが主処理範囲ｍｆ４にマッチするので、上記パケットに対するセッション処理を実行する（ステップＳ５１において”ＹＥＳ”、Ｓ５６，Ｓ５７）。
このような状態において、クラスタメンバ１−４に故障が発生したとする。クラスタメンバ１−４に故障が発生すると、クラスタメンバ１−４からは広告メッセージが送出されなくなるので、他のクラスタメンバ１−１〜１−３内に設けられているクラスタメンバ１−４用の死活監視タイマは、タイムアウト状態になる。
クラスタメンバ１−４用の死活監視タイマがタイムアウト状態になると、クラスタメンバ１−４が担当していた主処理に関する優先度「１」の副処理を担当しているクラスタメンバ１−３は、自クラスタメンバ１−３内の範囲保持部１２１を更新し、クラスタメンバ１−４が担当していた主処理を引き継ぐ（図１２のステップＳ１１２において”ＹＥＳ”、Ｓ１１３において”ＹＥＳ”、Ｓ１１４）。つまり、クラスタメンバ１−３においては、副処理範囲ｂｆ１，３が主処理範囲に変更されるため、セッションαに属するパケットの主処理を実行することになる。
その後、クラスタメンバ１−３は、図１６のフローチャートに示すタイムアウト通知受信処理を実行する。他のクラスタメンバ１−１，１−２は、図１２のステップＳ１１３，Ｓ１１７において共に”ＮＯ”となるので、図１６のフローチャートに示すタイムアウト通知受信処理を実行する。
図１６のフローチャートに示す受信処理が行われることにより、正常動作している各クラスタメンバ１−１〜１−３には、図１７（Ｃ），（Ｄ）に示す主処理範囲ｍｆ１’〜ｍｆ３’及び副処理範囲ｂｆ１，１’〜ｂｆ１，３’が設定される。なお、主処理範囲ｍｆ１〜ｍｆ３及び副処理範囲ｂｆ１，１〜ｂｆ１，３は、クラスタメンバ１−１〜１−３の旧主処理範囲及び旧副処理範囲となる。
その後、再び、隣接ＩＰノード２−ａからセッションαに属するパケットが、クラスタシステム１に対してマルチキャストされたとすると、各クラスタメンバ１−１〜１−３において、上記パケットが受信される。
クラスタメンバ１−１内のトラフィック分散フィルタ１２は、上記パケットが、主処理範囲、旧主処理範囲、副処理範囲、旧副処理範囲の何れにもマッチしないので、そのパケットを破棄する（図６のステップＳ５５において”ＮＯ”、Ｓ５９）。
また、クラスタメンバ１−２内のトラフィック分散フィルタ１２は、上記パケットが副処理範囲ｂｆ１，２’のみにマッチするパケットであるので、マッチ種別「副処理範囲」を付加してセッション処理部１３に渡す（図６のステップＳ５４において”ＹＥＳ”、Ｓ５６）。
セッション処理部１３は、マッチ種別「副処理範囲」の付加されたパケットが渡されると、それがセッション開設を要求するパケットでないので、上記パケットのセッション情報がセッション情報保持部１４に格納されているか否かを調べる（図８のステップＳ７０１において”ＹＥＳ”、Ｓ７０２において”ＮＯ”、Ｓ７０５）。この例の場合、該当するセッション情報が格納されていないので、パケットを破棄する（Ｓ７０５において”ＮＯ”、Ｓ７０６）。
クラスタメンバ１−３内のトラフィック分散フィルタ１２は、上記パケットが主処理範囲ｍｆ３’にマッチするので、マッチ種別「主処理範囲」を付加してセッション処理部１３に渡す（図６のステップＳ５１において”ＹＥＳ”，Ｓ５６）。
セッション処理部１３は、マッチ種別「主処理範囲」の付加されたパケットが渡されると、それがセッション開設を要求するパケットでないので、上記パケットに関するセッション情報がセッション情報保持部１４に格納されているか否かを調べる（図７のステップＳ６０１において”ＹＥＳ”，Ｓ６０２において”ＮＯ”，Ｓ６０５）。この例の場合、クラスタメンバ１−３は、クラスタメンバ１−４に故障が発生する前、セッションαに属するパケットに対する副処理を担当していたので、セッション情報保持部１４には該当するセッション情報が存在することになる。
従って、セッション処理部１３は、セッション情報保持部１４に格納されている該当するセッション情報を更新し（ステップＳ６０３）、更に、上記パケットをセッション処理部１３に渡すことになる（ステップＳ６０４）。
その後、隣接ＩＰノード２−ａからセッションβの開設を要求するパケットが、クラスタシステム１に対してマルチキャストされたとする。このパケットは、クラスタシステム１内の各クラスタメンバ１−１〜１−３で受信される。
クラスタメンバ１−１内のトラフィック分散フィルタ１２は、上記パケットが主処理範囲ｍｆ１’にマッチするので、マッチ種別「主処理範囲」を付加してセッション処理部１３に渡す（図６のステップＳ５１において”ＹＥＳ”，Ｓ５６）。
セッション処理部１３は、マッチ種別「主処理範囲」の付加されたパケットが渡されると、それがセッション開設を要求するパケットであるので、セッション情報保持部１４にセッションβに関するセッション情報を登録（新規登録）すると共に、パケットをパケット転送部１５に渡す（図７のＳ６０１において”ＹＥＳ”，Ｓ６０２において”ＹＥＳ”，Ｓ６０３，Ｓ６０４）。
クラスタメンバ１−２内のトラフィック分散フィルタ１２は、上記パケットが旧主処理範囲ｍｆ２のみにマッチするので、マッチ種別「旧主処理範囲」を付加してセッション処理部１３に渡す（図６のＳ５２において”ＹＥＳ”，Ｓ５６）。
セッション処理部１３は、マッチ種別「旧主処理範囲」が付加されたパケットが渡されると、それがセッション開設を要求するものなので、破棄する（図７のステップＳ６０７において”ＹＥＳ”，Ｓ６０８において”ＹＥＳ”，Ｓ６０９）。つまり、クラスタメンバ１−１が上記パケットに対する主処理を担当するので、クラスタメンバ１−２は、上記パケットを破棄する。
クラスタメンバ１−３内のトラフィック分散フィルタ１２は、上記パケットが副処理範囲ｂｆ１，３’のみにマッチするのでマッチ種別「副処理範囲」を付加してセッション処理部１３に渡す（図６のステップＳ５４において”ＹＥＳ”，Ｓ５６）。
セッション処理部１３は、マッチ種別「副処理範囲」の付加されたパケットが渡されると、それがセッション開設を要求するものであるので、セッション情報保持部１４にセッションβに関するセッション情報を登録すると共に、上記パケットを破棄する（図８のステップＳ７０１において”ＹＥＳ”，Ｓ７０２において”ＹＥＳ”，Ｓ７０３，Ｓ７０４）。
以上は、クラスタシステム１内のクラスタメンバ１−４に故障が発生した場合の動作であるが、新たなクラスタメンバが追加された場合の動作は、次のようになる。
今、例えば、クラスタシステム１が３台のクラスタメンバ１−１〜１−３から構成され、クラスタシステム１で処理すべき全トラフィックがＴであるとする。また、各クラスタメンバ１−１〜１−３には、図１８（Ａ），（Ｂ）に示す主処理範囲ｍｆ１〜ｍｆ３及び副処理範囲ｂｆ１，１〜ｂｆ１，３が設定されているとする。即ち、クラスタメンバ１−１，１−２，１−３が担当している主処理に関する優先度「１」の副処理を、クラスタメンバ１−３，１−１，１−２が担当している。また、この時点では、旧主処理範囲および旧副処理範囲は設定されていないとする。
このような状態において、隣接ＩＰノード（例えば、隣接ＩＰノード２−１）からクラスタシステム１へパケットがマルチキャストされ、各クラスタメンバ１−１〜１−３が上記パケットを受信したとする。但し、このパケットは、セッションγに属するものとする。
クラスタメンバ１−１は、上記パケットが主処理範囲、旧主処理範囲、副処理範囲、旧副処理範囲の何れにもマッチしないので、上記パケットを破棄する（図６のステップＳ５５において”ＮＯ”、Ｓ５９）。
クラスタメンバ１−２は、上記パケットが副処理範囲ｂｆ１，２のみにマッチするので、セッション処理を実行する（ステップＳ５４において”ＹＥＳ”、Ｓ５６、Ｓ５７）。
クラスタメンバ１−３は、上記パケットが主処理範囲ｍｆ３にマッチするので、セッション処理を実行する（ステップＳ５１において”ＹＥＳ”、Ｓ５６、Ｓ５７）。
このような状態において、クラスタメンバ１−４が追加されたとすると、各クラスタメンバ１−１〜１−４内の範囲保持部１２１の内容が更新され、各クラスタメンバ１−１〜１−４が担当する主処理範囲、旧主処理範囲、副処理範囲及び旧副処理範囲が更新される（図１５のステップＳ１３１〜Ｓ１３４）。
今、例えば、各クラスタメンバ１−１〜１−４に、図１８（Ｃ）、（Ｄ）に示す主処理範囲ｍｆ１’〜ｍｆ４’及び副処理範囲ｂｆ１，１’〜ｂｆ１，４’が設定されたとする。なお、主処理範囲ｍｆ１〜ｍｆ３及び副処理範囲ｂｆ１，１〜ｂｆ１，３は、クラスタメンバ１−１〜１−３の旧主処理範囲及び旧副処理範囲となる。
その後、再び、隣接ＩＰノード２−１からセッションγに属するパケットが、クラスタシステム１に対してマルチキャストされたとすると、各クラスタメンバ１−１〜１−４において、上記パケットが受信される。
クラスタメンバ１−１内のトラフィック分散フィルタ１２は、上記パケットが主処理範囲、旧主処理範囲、副処理範囲、旧副処理範囲の何れにもマッチしないので、上記パケットを破棄する（図６のステップＳ５５において”ＮＯ”、Ｓ５９）。
クラスタメンバ１−２内のトラフィック分散フィルタ１２は、上記パケットが旧副処理範囲ｂｆ１，２のみにマッチするので、マッチ種別「旧副処理範囲」を付加してセッション処理部１３に渡す（図６のステップＳ５５において”ＹＥＳ”、Ｓ５６）。
セッション処理部１３は、マッチ種別「旧副処理範囲」の付加されたパケットが渡されると、そのパケットがセッション開設を要求するパケットでなく、且つ該当セッション情報がセッション情報保持部１４内に存在するので、セッション情報を更新した後、上記パケットを破棄する（図８のステップＳ７０７において”ＹＥＳ”、Ｓ７０８において”ＮＯ”、Ｓ７１０において”ＮＯ”、Ｓ７０９）。
クラスタメンバ１−３内のトラフィック分散フィルタ１２は、上記パケットが旧主処理範囲ｍｆ３と副処理範囲ｂｆ１，３’の両方にマッチするので、マッチ種別「旧主処理範囲、副処理範囲」を付加してセッション処理部１３に渡す（図６のステップＳ５３において”ＹＥＳ”、Ｓ５６）。
セッション処理部１３は、マッチ種別「旧主処理範囲、副処理範囲」の付加されたパケットがトラフィック分散フィルタ１２から渡されると、そのパケットがセッション開設を要求するものでなく、且つ、セッション情報保持部１４に該当するセッション情報が存在するので、セッション情報を更新した後、上記パケットをパケット転送部１５に渡す（図８のステップＳ７１３において”ＮＯ”、Ｓ７１６において”ＹＥＳ”、Ｓ７１７、Ｓ７１８）。
クラスタメンバ１−４内のトラフィック分散フィルタ１２は、上記パケットが主処理範囲ｍｆ４’にマッチするので、マッチ種別「主処理範囲」を付加してセッション処理部１３に渡す（図６のステップＳ５１において”ＹＥＳ”、Ｓ５６）。
セッション処理部１３は、マッチ種別「主処理範囲」の付加されたパケットが渡されると、そのパケットがセッション開設を要求するものでなく、且つ、セッション情報保持部１４に該当するセッション情報が存在しないので、上記パケットを破棄する（図７のステップＳ６０１において”ＹＥＳ”、Ｓ６０２において”ＮＯ”、Ｓ６０５において”ＮＯ”、Ｓ６０６）。
その後、隣接ＩＰノード２−１が、セッションδの開設を要求するパケットをクラスタシステム１に対してマルチキャストしたとすると、このパケットは、各クラスタメンバ１−１〜１−４で受信される。
クラスタメンバ１−１内のトラフィック分散フィルタ１２は、上記パケットが旧主処理範囲ｍｆ１と副処理範囲ｂｆ１，１’の両方にマッチするので、マッチ種別「旧主処理範囲、副処理範囲」を付加してセッション処理部１３に渡す（図６のステップＳ５３において”ＹＥＳ”、Ｓ５６）。
セッション処理部１３は、マッチ種別「旧主処理範囲、副処理範囲」の付加されたパケットが渡されると、それがセッションの開設を要求するものであるので、セッション情報を更新（セッションδのセッション情報をセッション情報保持部１４に登録）した後、上記パケットを破棄する（図８のステップＳ７１３において”ＹＥＳ”、Ｓ７１４、Ｓ７１５）。
クラスタメンバ１−２内のトラフィック分散フィルタ１２は、上記パケットが主処理範囲ｍｆ２’にマッチするので、マッチ種別「主処理範囲」を付加してセッション処理部１３に渡す（図６のステップＳ５１において”ＹＥＳ”、Ｓ５６）。
セッション処理部１３は、マッチ種別「主処理範囲」の付加されたパケットが渡されると、それがセッションδの開設を要求するパケットであるので、セッション情報をセッション情報保持部１４に登録（セッションδのセッション情報を新規登録）すると共に、上記パケットをパケット転送部１５に渡す（図７のステップＳ６０１，Ｓ６０２において共に”ＹＥＳ”、Ｓ６０３、Ｓ６０４）。
クラスタメンバ１−３内のトラフィック分散フィルタ１２は、上記パケットが旧副処理範囲のみにマッチするので、マッチ種別「旧副処理範囲」を付加してセッション処理部１３に渡す（図６のステップＳ５５において”ＹＥＳ”、Ｓ５６）。
セッション処理部１３は、上記パケットがセッションδの開設を要求するものであるので、破棄する（図８のステップＳ７０７，Ｓ７０８において”ＹＥＳ”、Ｓ７０９）。
クラスタメンバ１−４内のトラフィック分散フィルタ１２は、上記パケットが主処理範囲、旧主処理範囲、副処理範囲、旧副処理範囲の何れにもマッチしないので、上記パケットを破棄する（図６のステップＳ５５において”ＮＯ”、Ｓ５９）。
なお、以上の説明では述べなかったが、各クラスタメンバにおいて、トラフィック分散フィルタ１２内の範囲保持部１２１に格納されている旧主処理範囲，旧副処理範囲の内、関連するセッション（自クラスタメンバにおいて、開設処理を行ったセッション）が全くなくなった旧主処理範囲，旧副処理範囲は削除するようにしても良い。つまり、旧主処理範囲および旧副処理範囲は、その範囲内に関連するセッションが存在する場合のみ有効で、関連するセッションが存在しない場合は無意味なものとなるので、上記したようにする。このようにすることにより、トラフィック分散フィルタ１２で比較対象にする処理範囲数が少なくなるので、処理速度を向上させることができる。
〔発明の他の実施例〕
上述した実施例では、主処理を行っているクラスタメンバが故障した場合、副処理を行っていたクラスタメンバは、自身の主処理に加えて、該当する副処理を主処理に切り替えて処理を行う（ｆａｉｌｏｖｅｒ処理）。トラフィックの処理範囲が再分割され、処理中のセッションが消えれば、各メンバの負荷は再び平均化されるが、短期的にはｆａｉｌｏｖｅｒ後は処理が特定のクラスタメンバに偏る。
本実施例では、各クラスタメンバが担当するトラフィックの範囲の分割を次のように微細に定めることにより、ｆａｉｌｏｖｅｒ後の処理負荷の偏りを低減する。
すなわち、クラスタメンバ数がｎであるとき、トラフィック全体をｎ（ｎ−１）個に分割する。各クラスタメンバは、主処理として、この内の（ｎ−１）個を担当する。また、各クラスタメンバは、副処理として、他の何れかのクラスタメンバが主処理を担当する分割を（ｎ−１）個担当する。但し、この分割は、全て異なるクラスタメンバが主処理を行っている範囲から取るようにする。
すなわち、ある副処理について、ｂｆｉ，ｋを、クラスタメンバ１−ｉが処理する副処理のｋ個目であるとすると、
ｂｆｉ＝ｂｆｉ，１ ∪ ｂｆｉ，２∪…∪ ｂｆｉ，（ｎ−１）である。
ここで、
ｍｆｊ ∩ ｂｆｉ，ｋ＝φ（ただしｋ≠ｊ）
ｂｆ１，ｉ ∪．．．∪ ｂｆ（ｉ−１），ｉ ∪ ｂｆ（ｉ＋１），ｉ ∪．．．∪ ｂｆｎ，ｉ＝ｍｆｉ
となるように、クラスタメンバ１−ｉの副処理範囲ｂｆｉを定める。
割り当ての例を図１９に示す。
このとき、或るクラスタメンバ１−ｉが故障したとすると、他のクラスタメンバの副処理の内、クラスタメンバ１−ｉの主処理に該当する部分だけが主処理に切り替わるため、特定のメンバの主処理が片寄って増加することはなく、全メンバに均一に負荷が分散される。
また、上述した実施例では説明しなかったが、クラスタメンバの経路制御およびパケット転送の機能をＬ３スイッチ相当に置き換えても同様の効果を得ることができる。
以上説明した本発明にかかる第１〜第５のクラスタシステム、第１のクラスタメンバ、第１の故障復旧方法および第１のプログラムによれば、セッション情報をクラスタメンバ間で交換し合うことなく、故障復旧処理を行うことが可能になる。その結果、セッション情報をクラスタメンバ間で交換し合っていた従来の技術に比較して、故障復旧処理を迅速に行うことが可能になると共に、スケーラビリティを高くすることができる。その理由は、副処理を担当しているクラスタメンバにおいて、セッション情報の記録更新処理を行っており、主処理を担当しているクラスタメンバにおいて故障が発生した場合には、副処理を担当しているクラスタメンバが、自クラスタメンバ内に記録されているセッション情報を利用して処理を引き継ぐようにしているからである。
また、本発明にかかる第３のクラスタシステムによれば、各クラスタメンバ間でセッション情報を交換し合わなくとも、故障クラスタメンバの発生時や、新規クラスタメンバの追加時に、各クラスタメンバが担当する主処理範囲や副処理範囲を変更することが可能になる。その理由は、各クラスタメンバにおいて、範囲決定ルールに基づいて新たな主処理範囲および副処理範囲を決定し、それまでの主処理範囲および副処理範囲を旧主処理範囲および旧副処理範囲とするようにしているからである。
Claims (14)
- 複数のクラスタメンバから構成されるクラスタシステムにおいて、
前記各クラスタメンバが、
前記クラスタシステムに入力されたパケットの内の、自クラスタメンバが担当する主処理の範囲を示す主処理範囲或いは副処理の範囲を示す副処理範囲にマッチするパケットについて、そのパケットが属するセッションの状態を示すセッション情報の記録更新処理を含むセッション処理を行い、自クラスタメンバが副処理を担当しているパケットに対する主処理を担当しているクラスタメンバに故障が発生したとき、前記故障の発生したクラスタメンバが主処理を担当していたパケットの主処理を、前記記録してあるセッション情報を利用して引き継ぐ構成を有することを特徴とするクラスタシステム。 - 請求項１のクラスタシステムにおいて、
前記主処理範囲と前記副処理範囲を、所定の範囲決定ルールに従って決定すると共に、
前記クラスタシステムに入力されたパケットの内の、前記主処理範囲にマッチするパケットについては、前記セッション処理とパケット転送処理とを行い、前記副処理範囲にマッチするパケットについては、前記セッション処理を行うことを特徴とするクラスタシステム。 - 複数のクラスタメンバから構成されるクラスタシステムにおいて、
前記各クラスタメンバが、
前記クラスタシステムに入力されたパケットの内、自クラスタメンバが担当する主処理の範囲を示す主処理範囲または副処理の範囲を示す副処理範囲にマッチするパケットを通過させるトラフィック分散フィルタと、
パケットが属するセッションの状態を示すセッション情報が格納されるセッション情報保持部と、
前記トラフィック分散フィルタを通過したパケットの内の、前記主処理範囲または前記副処理範囲にマッチしたパケットについて、前記セッション情報保持部に格納されている前記パケットのセッション情報の更新処理を含むセッション処理を実行するセッション処理部と、
該セッション処理部から出力されたパケットの転送処理を行うパケット転送部と、
自クラスタメンバが副処理を担当しているパケットに対する主処理を担当しているクラスタメンバに故障が発生したとき、前記副処理範囲を主処理範囲に変更する故障復旧部とを備えたことを特徴とするクラスタシステム。 - 請求項３のクラスタシステムにおいて、
所定の範囲決定ルールと前記クラスタシステムを構成するクラスタメンバ数とに基づいて、自クラスタメンバが担当する主処理の範囲を示す主処理範囲および副処理の範囲を示す副処理範囲を決定する分散処理制御部を備え、
前記セッション処理部が、前記クラスタシステムに入力されたパケットの内、前記主処理範囲にマッチしたパケットについては、前記セッション情報保持部に格納されている前記パケットのセッション情報の更新処理を含むセッション処理を実行すると共にパケット出力処理を実行し、前記副処理範囲にマッチしたパケットについては、前記セッション情報保持部に格納されている前記パケットのセッション情報の更新処理を含むセッション処理を実行すると共にパケット破棄処理を実行することを特徴とするクラスタシステム。 - 請求項４記載のクラスタシステムにおいて、
前記分散処理制御部が、他のクラスタメンバにおいて故障が発生したとき、及びクラスタシステムに新たなクラスタメンバが追加されたとき、前記範囲決定ルールとクラスタメンバ数とに基づいて新たな主処理範囲および副処理範囲を決定し、それまでの主処理範囲および副処理範囲を旧主処理範囲および旧副処理範囲とし、
前記トラフィック分散フィルタが、前記クラスタシステムに入力されたパケットの内、前記新たな主処理範囲、前記新たな副処理範囲、前記旧主処理範囲または前記旧副処理範囲にマッチするパケットを通過させ、
前記セッション処理部が、前記トラフィック分散フィルタを通過したパケットの内、前記新たな主処理範囲にマッチしたパケットについては、そのパケットがセッションの開設を要求するパケットであること、或いは前記セッション情報保持部に前記パケットのセッション情報が格納されていることを条件にして、前記セッション情報保持部に格納されている前記パケットのセッション情報の更新処理を含むセッション処理を実行すると共にパケット出力処理を実行し、前記旧主処理範囲のみにマッチしたパケットについては、そのパケットがセッションの開設を要求するパケットである場合には破棄し、そうでない場合には前記セッション情報保持部に前記パケットのセッション情報が格納されていることを条件にして、前記セッション情報保持部に格納されている前記パケットのセッション情報の更新処理を含むセッション処理を実行すると共にパケット出力処理を実行し、前記新たな副処理範囲のみにマッチしたパケットについては、そのパケットがセッションの開設を要求するパケットであること、或いは前記セッション情報保持部に前記パケットのセッション情報が格納されていることを条件にして、前記セッション情報保持部に格納されている前記パケットのセッション情報の更新処理を含むセッション処理を実行すると共にパケット破棄処理を実行し、前記旧副処理範囲のみにマッチしたパケットについては、そのパケットがセッションの開設を要求するパケットである場合には廃棄し、そうでない場合には、前記セッション情報保持部に前記パケットのセッション情報が格納されていることを条件にして、前記セッション情報保持部に格納されている前記パケットのセッション情報の更新処理を含むセッション処理を実行すると共にパケット破棄処理を実行する構成を有することを特徴とするクラスタシステム。 - 請求項５記載のクラスタシステムにおいて、
前記セッション処理部が、前記トラフィック分散フィルタを通過したパケットの内、前記旧副処理範囲と前記副処理範囲との両方にマッチしたパケットについては、そのパケットがセッションの開設を要求するパケットである場合には、前記セッション情報保持部に格納されている前記パケットのセッション情報の更新処理を含むセッション処理を実行すると共にパケット破棄処理を実行し、そうでない場合は、前記セッション情報保持部に前記パケットのセッション情報が格納されていることを条件にして前記セッション情報保持部に格納されている前記パケットのセッション情報の更新処理を含むセッション処理を実行すると共にパケット出力処理を実行する構成を有することを特徴とするクラスタシステム。 - 請求項３又は請求項４記載のクラスタシステムにおいて、
前記各クラスタメンバが、
前記クラスタシステム中のクラスタメンバの識別子が格納されたクラスタメンバリストと、
クラスタメンバ毎の死活監視タイマと、
所定時間毎に自クラスタメンバの識別子を含む広告メッセージを他のクラスタメンバに対して送信すると共に、他のクラスタメンバからの広告メッセージを受信したとき、該広告メッセージの送信元のクラスタメンバに対応する死活監視タイマをリセットする広告メッセージ処理部とを備え、
前記分散処理制御部が、
タイムアウトした死活監視タイマが発生したとき、該タイムアウトした死活監視タイマに対応するクラスタメンバに障害が発生したと認識する構成を有することを特徴とするクラスタシステム。 - 請求項７記載のクラスタシステムにおいて、
前記分散処理制御部が、
前記広告メッセージ処理部で受信した広告メッセージ中の識別子が前記クラスタメンバリストに含まれていなかった場合、前記識別子のクラスタメンバが追加されたと認識する構成を有することを特徴とするクラスタシステム。 - 自クラスタメンバを構成要素とするクラスタシステムに入力されたパケットの内の、自クラスタメンバが担当する主処理の範囲を示す主処理範囲或いは副処理の範囲を示す副処理範囲にマッチするパケットについて、そのパケットが属するセッションの状態を示すセッション情報の記録更新処理を含むセッション処理を行い、自クラスタメンバが副処理を担当しているパケットに対する主処理を担当しているクラスタメンバに故障が発生したとき、前記故障の発生したクラスタメンバが主処理を担当していたパケットの主処理を、前記記録してあるセッション情報を利用して引き継ぐ構成を有することを特徴とするクラスタメンバ。
- 請求項９のクラスタメンバにおいて、
前記主処理範囲と前記副処理範囲を、所定の範囲決定ルールに従って決定すると共に、
前記クラスタシステムに入力されたパケットの内の、前記主処理範囲にマッチするパケットについては、前記セッション処理とパケット転送処理とを行い、前記副処理範囲にマッチするパケットについては、前記セッション処理を行うことを特徴とするクラスタメンバ。 - 複数のクラスタメンバから構成されるクラスタシステムの故障復旧方法において、
前記各クラスタメンバが、
前記クラスタシステムに入力されたパケットの内の、自クラスタメンバが担当する主処理の範囲を示す主処理範囲或いは副処理の範囲を示す副処理範囲にマッチするパケットについて、そのパケットが属するセッションの状態を示すセッション情報の記録更新処理を含むセッション処理を行い、自クラスタメンバが副処理を担当しているパケットに対する主処理を担当しているクラスタメンバに故障が発生したとき、前記故障の発生したクラスタメンバが主処理を担当していたパケットの主処理を、前記記録してあるセッション情報を利用して引き継ぐことを特徴とする故障復旧方法。 - 請求項１１記載の故障復旧方法であって、
所定の範囲決定ルールに従って自クラスタメンバが担当する主処理の範囲を示す前記主処理範囲および副処理の範囲を示す前記副処理範囲を決定し、前記クラスタシステムに入力されたパケットの内の、前記主処理範囲にマッチするパケットについては、そのパケットが属するセッションの状態を示すセッション情報の記録更新処理を含むセッション処理とパケット転送処理とを行い、前記決定した副処理範囲にマッチするパケットについては、そのパケットが属するセッションの状態を示すセッション情報の記録更新処理を含むセッション処理を行うことを特徴とする故障復旧方法。 - コンピュータをクラスタメンバとして機能させるためのプログラムであって、
前記コンピュータを、
自クラスタメンバを構成要素とするクラスタシステムに入力されたパケットの内の、自クラスタメンバが担当する主処理の範囲を示す主処理範囲或いは副処理の範囲を示す副処理範囲にマッチするパケットについて、そのパケットが属するセッションの状態を示すセッション情報の記録更新処理を含むセッション処理を行い、自クラスタメンバが副処理を担当しているパケットに対する主処理を担当しているクラスタメンバに故障が発生したとき、前記故障の発生したクラスタメンバが主処理を担当していたパケットの主処理を、前記記録してあるセッション情報を利用して引き継ぐ手段として機能させるプログラム。 - 請求項１３記載のプログラムであって、
前記コンピュータを、
所定の範囲決定ルールに従って自クラスタメンバが担当する主処理の範囲を示す前記主処理範囲および副処理の範囲を示す前記副処理範囲を決定し、前記クラスタシステムに入力されたパケットの内の、前記主処理範囲にマッチするパケットについては、そのパケットが属するセッションの状態を示すセッション情報の記録更新処理を含むセッション処理とパケット転送処理とを行い、前記決定した副処理範囲にマッチするパケットについては、そのパケットが属するセッションの状態を示すセッション情報の記録更新処理を含むセッション処理を行う手段として機能させることを特徴とするプログラム。
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003419005 | 2003-12-17 | ||
| JP2003419005 | 2003-12-17 | ||
| PCT/JP2004/018090 WO2005060187A1 (ja) | 2003-12-17 | 2004-11-29 | クラスタシステム、クラスタメンバ、故障復旧方法及びプログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPWO2005060187A1 JPWO2005060187A1 (ja) | 2007-07-12 |
| JP4458289B2 true JP4458289B2 (ja) | 2010-04-28 |
Family
ID=34675195
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2005516288A Expired - Fee Related JP4458289B2 (ja) | 2003-12-17 | 2004-11-29 | クラスタシステム、クラスタメンバ、故障復旧方法及びプログラム |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US7443787B2 (ja) |
| JP (1) | JP4458289B2 (ja) |
| CN (1) | CN1914862A (ja) |
| WO (1) | WO2005060187A1 (ja) |
Families Citing this family (43)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7761431B2 (en) | 2006-02-16 | 2010-07-20 | International Business Machines Corporation | Consolidating session information for a cluster of sessions in a coupled session environment |
| CN100411460C (zh) * | 2006-07-20 | 2008-08-13 | 华为技术有限公司 | 中继移动交换中心离开组呼的方法 |
| GB0623933D0 (en) * | 2006-11-29 | 2007-01-10 | Ibm | Apparatus and method for synchronizing controller firmware download |
| US7969991B2 (en) * | 2007-04-23 | 2011-06-28 | Mcafee, Inc. | Session announcement system and method |
| US8547844B2 (en) * | 2007-07-10 | 2013-10-01 | Telefonaktiebolaget L M Ericsson (Publ) | System and method for balancing IP gateway services |
| JP5175825B2 (ja) * | 2009-11-06 | 2013-04-03 | 株式会社日立ハイテクノロジーズ | 画像データ配信方法及び検査装置 |
| RU2513918C1 (ru) * | 2010-03-29 | 2014-04-20 | Хуавей Текнолоджиз Ко., Лтд. | Кластерный маршрутизатор и способ кластерной маршрутизации |
| WO2011148493A1 (ja) * | 2010-05-27 | 2011-12-01 | 富士通株式会社 | パケット通信装置及びパケット転送方法 |
| JP5538560B2 (ja) | 2010-11-01 | 2014-07-02 | かもめエンジニアリング株式会社 | アクセス制御方法、アクセス制御装置およびアクセス制御プログラム |
| JP5486547B2 (ja) * | 2011-04-12 | 2014-05-07 | 日本電信電話株式会社 | マルチキャスト配信システム、配信ルータ、および、マルチキャスト配信方法 |
| US10169339B2 (en) | 2011-10-31 | 2019-01-01 | Elwha Llc | Context-sensitive query enrichment |
| US10679309B2 (en) | 2011-12-30 | 2020-06-09 | Elwha Llc | Evidence-based healthcare information management protocols |
| US20130173295A1 (en) | 2011-12-30 | 2013-07-04 | Elwha LLC, a limited liability company of the State of Delaware | Evidence-based healthcare information management protocols |
| US10340034B2 (en) | 2011-12-30 | 2019-07-02 | Elwha Llc | Evidence-based healthcare information management protocols |
| US10559380B2 (en) | 2011-12-30 | 2020-02-11 | Elwha Llc | Evidence-based healthcare information management protocols |
| US10552581B2 (en) | 2011-12-30 | 2020-02-04 | Elwha Llc | Evidence-based healthcare information management protocols |
| US10475142B2 (en) | 2011-12-30 | 2019-11-12 | Elwha Llc | Evidence-based healthcare information management protocols |
| US10528913B2 (en) | 2011-12-30 | 2020-01-07 | Elwha Llc | Evidence-based healthcare information management protocols |
| US9451394B2 (en) | 2012-12-31 | 2016-09-20 | Elwha Llc | Cost-effective mobile connectivity protocols |
| US9713013B2 (en) | 2013-03-15 | 2017-07-18 | Elwha Llc | Protocols for providing wireless communications connectivity maps |
| US9635605B2 (en) | 2013-03-15 | 2017-04-25 | Elwha Llc | Protocols for facilitating broader access in wireless communications |
| US9832628B2 (en) | 2012-12-31 | 2017-11-28 | Elwha, Llc | Cost-effective mobile connectivity protocols |
| US9980114B2 (en) | 2013-03-15 | 2018-05-22 | Elwha Llc | Systems and methods for communication management |
| US9876762B2 (en) | 2012-12-31 | 2018-01-23 | Elwha Llc | Cost-effective mobile connectivity protocols |
| US8965288B2 (en) | 2012-12-31 | 2015-02-24 | Elwha Llc | Cost-effective mobile connectivity protocols |
| US9781664B2 (en) | 2012-12-31 | 2017-10-03 | Elwha Llc | Cost-effective mobile connectivity protocols |
| US9813887B2 (en) | 2013-03-15 | 2017-11-07 | Elwha Llc | Protocols for facilitating broader access in wireless communications responsive to charge authorization statuses |
| US9843917B2 (en) | 2013-03-15 | 2017-12-12 | Elwha, Llc | Protocols for facilitating charge-authorized connectivity in wireless communications |
| US9866706B2 (en) | 2013-03-15 | 2018-01-09 | Elwha Llc | Protocols for facilitating broader access in wireless communications |
| US9693214B2 (en) | 2013-03-15 | 2017-06-27 | Elwha Llc | Protocols for facilitating broader access in wireless communications |
| US9706382B2 (en) | 2013-03-15 | 2017-07-11 | Elwha Llc | Protocols for allocating communication services cost in wireless communications |
| US9596584B2 (en) | 2013-03-15 | 2017-03-14 | Elwha Llc | Protocols for facilitating broader access in wireless communications by conditionally authorizing a charge to an account of a third party |
| US9781554B2 (en) | 2013-03-15 | 2017-10-03 | Elwha Llc | Protocols for facilitating third party authorization for a rooted communication device in wireless communications |
| US9807582B2 (en) | 2013-03-15 | 2017-10-31 | Elwha Llc | Protocols for facilitating broader access in wireless communications |
| US9706060B2 (en) | 2013-03-15 | 2017-07-11 | Elwha Llc | Protocols for facilitating broader access in wireless communications |
| US9838536B2 (en) | 2013-09-30 | 2017-12-05 | Elwha, Llc | Mobile device sharing facilitation methods and systems |
| US9740875B2 (en) | 2013-09-30 | 2017-08-22 | Elwha Llc | Mobile device sharing facilitation methods and systems featuring exclusive data presentation |
| US9805208B2 (en) | 2013-09-30 | 2017-10-31 | Elwha Llc | Mobile device sharing facilitation methods and systems with recipient-dependent inclusion of a data selection |
| US9813891B2 (en) | 2013-09-30 | 2017-11-07 | Elwha Llc | Mobile device sharing facilitation methods and systems featuring a subset-specific source identification |
| US9774728B2 (en) | 2013-09-30 | 2017-09-26 | Elwha Llc | Mobile device sharing facilitation methods and systems in a context of plural communication records |
| US9826439B2 (en) | 2013-09-30 | 2017-11-21 | Elwha Llc | Mobile device sharing facilitation methods and systems operable in network equipment |
| US10572293B2 (en) * | 2017-12-15 | 2020-02-25 | Nicira, Inc. | Node in cluster membership management protocol |
| US10476744B2 (en) | 2017-12-15 | 2019-11-12 | Nicira, Inc. | Coordinator in cluster membership management protocol |
Family Cites Families (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP3366804B2 (ja) * | 1995-09-08 | 2003-01-14 | 株式会社日立製作所 | インタネットワーク装置 |
| US6587836B1 (en) * | 1997-09-26 | 2003-07-01 | Worldcom, Inc. | Authentication and entitlement for users of web based data management programs |
| JP3062155B2 (ja) * | 1998-07-31 | 2000-07-10 | 三菱電機株式会社 | 計算機システム |
| US7480606B2 (en) * | 1998-08-31 | 2009-01-20 | Versity Design, Inc. | VCD-on-demand system and method |
| US6006259A (en) | 1998-11-20 | 1999-12-21 | Network Alchemy, Inc. | Method and apparatus for an internet protocol (IP) network clustering system |
| US6078957A (en) | 1998-11-20 | 2000-06-20 | Network Alchemy, Inc. | Method and apparatus for a TCP/IP load balancing and failover process in an internet protocol (IP) network clustering system |
| AU6778601A (en) * | 2000-06-26 | 2002-01-08 | International Business Machines Corporation | Data management application programming interface for a parallel file system |
| JP2002351760A (ja) * | 2001-05-30 | 2002-12-06 | Mitsubishi Electric Corp | サーバ負荷分散装置、サーバ負荷分散方法およびその方法をコンピュータに実行させるプログラム |
| JP2003131961A (ja) * | 2001-07-09 | 2003-05-09 | Hitachi Ltd | ネットワークシステム及び負荷分散方法 |
| US7080225B1 (en) * | 2002-12-10 | 2006-07-18 | Emc Corporation | Method and apparatus for managing migration of data in a computer system |
-
2004
- 2004-11-29 CN CNA2004800414711A patent/CN1914862A/zh active Pending
- 2004-11-29 JP JP2005516288A patent/JP4458289B2/ja not_active Expired - Fee Related
- 2004-11-29 WO PCT/JP2004/018090 patent/WO2005060187A1/ja active Application Filing
- 2004-12-17 US US11/016,484 patent/US7443787B2/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| WO2005060187A1 (ja) | 2005-06-30 |
| JPWO2005060187A1 (ja) | 2007-07-12 |
| CN1914862A (zh) | 2007-02-14 |
| US20050135343A1 (en) | 2005-06-23 |
| US7443787B2 (en) | 2008-10-28 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4458289B2 (ja) | クラスタシステム、クラスタメンバ、故障復旧方法及びプログラム | |
| US9948553B2 (en) | System and method for virtual network-based distributed multi-domain routing control | |
| JP4524686B2 (ja) | クラスタシステム及びクラスタメンバ並びにプログラム | |
| US9692650B2 (en) | Control apparatus, communication system, communication method, and program | |
| CN108667743B (zh) | 分组数据联网中的拥塞控制 | |
| US6891839B2 (en) | Distributing packets among multiple tiers of network appliances | |
| US6735169B1 (en) | Cascading multiple services on a forwarding agent | |
| EP1022875B1 (en) | Push network | |
| US6836462B1 (en) | Distributed, rule based packet redirection | |
| US8270406B2 (en) | Method and apparatus for blocking forged multicast packets | |
| JP5652565B2 (ja) | 情報システム、制御装置、通信方法およびプログラム | |
| RU2558624C2 (ru) | Устройство управления, система связи, способ связи и носитель записи, содержащий записанную на нем программу для связи | |
| CN102263646B (zh) | 交换机的分布式控制平面内的多播 | |
| US20130246655A1 (en) | Communication path control system, path control device, communication path control method, and path control program | |
| JPWO2005081473A1 (ja) | 通信処理システム、パケット処理負荷分散装置及びそれに用いるパケット処理負荷分散方法 | |
| WO2010069382A1 (en) | Method and apparatus for transferring data packets between a first network and a second network | |
| CN103004144A (zh) | 网状网络中的媒体接入控制桥接 | |
| EP1345356A2 (en) | Topology discovery process and mechanism for a network of managed devices | |
| CN105075196A (zh) | 控制器、通信系统、路径切换方法和程序 | |
| RU2581558C1 (ru) | Узел связи, система связи, устройство управления, способ пересылки пакета и программа | |
| JP3457243B2 (ja) | プッシュ型ネットワーク | |
| US8432809B2 (en) | Method for communication between processors | |
| JP2004236050A (ja) | 負荷分散型中継装置及び負荷分散型中継方法 | |
| JP2019024272A (ja) | 制御装置、制御方法及びプログラム | |
| JP2018113564A (ja) | 通信システム、スイッチ、制御装置、通信方法、および、プログラム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20071010 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20100120 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 4458289 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20100202 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130219 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130219 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140219 Year of fee payment: 4 |
|
| LAPS | Cancellation because of no payment of annual fees |