(57)【特許請求の範囲】
【請求項１】
処理対象となるトラフィックの全範囲を複数の部分範囲に分割した際の各部分範囲に対し、現用処理を行うクラスタメンバと、予備処理を行うクラスタメンバとを備え、
前記予備処理を行うクラスタメンバは、
受信したパケットが属するセッションのセッション状態を保持するセッション状態保持手段と、
自クラスタメンバが予備処理を担当している部分範囲のパケットを受信したとき、前記パケットが属するセッションのセッション状態が前記セッション状態保持手段に保持されておらず、且つ、前記パケットが正規のパケットであることを条件にして、前記パケットが属するセッションのセッション状態を前記セッション状態保持手段に格納するセッション依存処理手段と、
前記部分範囲について現用処理を担当している他のクラスタメンバに故障が発生したとき、前記セッション状態保持手段に保持されているセッション状態を利用して前記他のクラスタメンバが行っていた処理を前記セッション依存処理手段に引き継がせる引継制御手段と
を備えることを特徴とするクラスタシステム。
【請求項２】
請求項１記載のクラスタシステムにおいて、
前記クラスタメンバは、システム稼動中に消滅したクラスタメンバの代わりに追加されることを特徴とするクラスタシステム。
【請求項３】
請求項１記載のクラスタシテムにおいて、
前記現用処理を行うクラスタメンバは、
自クラスタメンバが現用処理を担当している部分範囲の不正なパケットを受信したとき、前記パケットを破棄する不正パケット処理手段と、
前記破棄したパケットが属するセッションを特定するセッション識別子を含んだ転送拒否通知を送信する転送拒否通知送信手段とを備え、
前記予備処理を行うクラスタメンバの前記セッション依存処理手段は、
自クラスタメンバが予備処理を担当している部分範囲のパケットを受信したとき、前記パケットが属するセッションのセッション状態が前記セッション状態保持手段に格納されていないことを条件にして、前記パケットが属するセッションのセッション状態を前記セッション状態保持手段に格納するセッション状態格納手段と、
前記転送拒否通知を受信したとき、前記セッション状態保持手段に保持されているセッション状態の内の、前記転送拒否通知に含まれているセッション識別子によって特定されるセッションのセッション状態を削除するセッション状態削除手段とを備えることを特徴とするクラスタシステム。
【請求項４】
請求項１記載のクラスタシステムにおいて、
前記予備処理を行うクラスタメンバの前記セッション依存処理手段は、
自クラスタメンバが予備処理を担当している部分範囲のパケットを受信したとき、前記パケットが属するセッションのセッション状態が前記セッション状態保持手段に格納されていないことを条件にして、前記パケットが属するセッションのセッション状態を前記セッション状態保持手段に格納するセッション状態格納手段と、
前記セッション状態が前記セッション状態保持手段に格納されたときからの時間を計時し、所定時間経過後に前記セッション状態を前記セッション状態保持手段から削除するセッション監視タイマ手段と、
前記部分範囲の現用処理を担当しているクラスタメンバが前記パケットを次ホップへ転送したことを検出し、前記セッション監視タイマ手段による計時を停止させるデータリンク監視手段と
を備えることを特徴とするクラスタシステム。
【請求項５】
請求項１記載のクラスタシステムにおいて、
前記予備処理を行うクラスタメンバの前記セッション依存処理手段は、
自クラスタメンバが予備処理を担当している部分範囲のパケットを受信したとき、前記パケットが属するセッションのセッション状態が前記セッション状態保持手段に格納されていないことを条件にして、前記パケットが属するセッションのセッション状態を保留識別子と共に前記セッション状態保持手段に格納するセッション状態格納手段と、
前記セッション状態が前記セッション状態保持手段に格納されたときからの時間を計時し、所定時間経過後に前記保留識別子が付加されている前記セッション状態を前記セッション状態保持手段から削除するセッション監視タイマ手段と
を備えることを特徴とするクラスタシステム。
【請求項６】
請求項５記載のクラスタシステムにおいて、
前記現用処理を行うクラスタメンバは、
自クラスタメンバが現用処理を担当している部分範囲の不正なパケットを受信したとき、前記パケットを破棄する不正パケット処理手段と、
前記破棄したパケットが属するセッションを特定するセッション識別子を含んだ転送拒否通知を送信する転送拒否通知送信手段とを備え、
前記予備処理を行うクラスタメンバの前記セッション依存処理手段は、前記転送拒否通知を受信したとき、前記セッション状態保持手段に保持されているセッション状態の内の、前記転送拒否通知に含まれているセッション識別子によって特定されるセッションのセッション状態を削除するセッション状態削除手段をさらに備えることを特徴とするクラスタシステム。
【請求項７】
請求項６記載のクラスタシステムにおいて、
前記予備処理を行うクラスタメンバの前記セッション依存処理手段は、前記転送拒否通知を受信したとき、前記セッション状態削除手段により削除された前記セッション状態以外に前記保留識別子が付加されたセッション状態が前記セッション状態保持手段に保持されている場合、これらのセッション状態から前記保留識別子を削除する保留識別子削除手段をさらに備えることを特徴とするクラスタシステム。
【請求項８】
請求項７記載のクラスタシステムにおいて、
前記現用処理を行うクラスタメンバの前記転送拒否通知送信手段は、自クラスタメンバにおいてパケットを取りこぼす可能性のあるエラーが発生したとき、前記転送拒否通知にエラー識別子を付加し、
前記予備処理を行うクラスタメンバの前記保留識別子削除手段は、前記受信した転送拒否通知に前記エラー識別子が付加されている場合、前記保留識別子の削除を行わないことを特徴とするクラスタシステム。
【請求項９】
請求項５記載のクラスタシステムにおいて、
前記現用処理を行うクラスタメンバは、前記セッション監視タイマ手段により前記セッション状態が削除される前記所定時間よりも短い時間間隔で、セッション識別子を含まない空転送拒否通知を送信する空転送拒否通知送信手段をさらに備え、
前記予備処理を行うクラスタメンバの前記セッション依存処理手段は、自クラスタメンバが予備処理を担当している部分範囲について現用処理を担当している他のクラスタメンバから前記空転送拒否通知を受信したとき、前記セッション状態保持手段に保持されている前記セッション状態から前記保留識別子を削除する保留識別子削除手段をさらに備えることを特徴とするクラスタシステム。
【請求項１０】
請求項５記載のクラスタシステムにおいて、
前記予備処理を行うクラスタメンバの前記セッション依存処理手段は、前記部分範囲の現用処理を担当しているクラスタメンバが前記パケットを次ホップへ転送したことを検出し、前記パケットに属するセッションのセッション状態から前記保留識別子を削除するデータリンク監視手段をさらに備えることを特徴とするクラスタシステム。
【請求項１１】
請求項１記載のクラスタシステムにおいて、
前記現用処理を行うクラスタメンバは、自クラスタメンバが現用処理を担当している部分範囲について予備処理を担当している他のクラスタメンバに、所定のタイミングでメンバ広告を送信するメンバ広告送信手段をさらに備え、
前記予備処理を行うクラスタメンバの前記引継制御手段は、自クラスタメンバが予備処理を担当している部分範囲について現用処理を担当している他のクラスタメンバからのメンバ広告が所定時間以上受信されない場合、前記処理の引き継ぎを行う手段を備えることを特徴とするクラスタシステム。
【請求項１２】
受信したパケットが属するセッションのセッション状態を保持するセッション状態保持手段と、
自クラスタメンバが予備処理を担当している部分範囲のパケットを受信したとき、前記パケットが属するセッションのセッション状態が前記セッション状態保持手段に保持されておらず、且つ、前記パケットが正規のパケットであることを条件にして、前記パケットが属するセッションのセッション状態を前記セッション状態保持手段に格納するセッション依存処理手段と、
前記部分範囲について現用処理を担当している他のクラスタメンバに故障が発生したとき、前記セッション状態保持手段に保持されているセッション状態を利用して前記他のクラスタメンバが行っていた処理を前記セッション依存処理手段に引き継がせる引継制御手段と
を備えることを特徴とするクラスタメンバ。
【請求項１３】
請求項１２記載のクラスタメンバにおいて、
前記セッション依存処理手段は、
自クラスタメンバが現用処理を担当している部分範囲の不正なパケットを受信したとき、前記パケットを破棄する不正パケット処理手段と、
前記破棄したパケットが属するセッションを特定するセッション識別子を含んだ転送拒否通知を送信する転送拒否通知送信手段と、
自クラスタメンバが予備処理を担当している部分範囲のパケットを受信したとき、前記パケットが属するセッションのセッション状態が前記セッション状態保持手段に格納されていないことを条件にして、前記パケットが属するセッションのセッション状態を前記セッション状態保持手段に格納するセッション状態格納手段と、
自クラスタメンバが予備処理を担当している部分範囲について現用処理を担当している他のクラスタメンバからの転送拒否通知を受信したとき、前記セッション状態保持手段に保持されているセッション状態の内の、前記転送拒否通知に含まれているセッション識別子によって特定されるセッションのセッション状態を削除するセッション状態削除手段と
を備えることを特徴とするクラスタメンバ。
【請求項１４】
請求項１２記載のクラスタメンバにおいて、
前記セッション依存処理手段は、
自クラスタメンバが予備処理を担当している部分範囲のパケットを受信したとき、前記パケットが属するセッションのセッション状態が前記セッション状態保持手段に格納されていないことを条件にして、前記パケットが属するセッションのセッション状態を前記セッション状態保持手段に格納するセッション状態格納手段と、
前記セッション状態が前記セッション状態保持手段に格納されたときからの時間を計時し、所定時間経過後に前記セッション状態を前記セッション状態保持手段から削除するセッション監視タイマ手段と、
前記部分範囲の現用処理を担当しているクラスタメンバが前記パケットを次ホップへ転送したことを検出し、前記セッション監視タイマ手段による計時を停止させるデータリンク監視手段と
を備えることを特徴とするクラスタメンバ。
【請求項１５】
受信したパケットが属するセッションのセッション状態を保持するセッション状態保持手段と、
自クラスタメンバが予備処理を担当している部分範囲のパケットを受信したとき、前記パケットが属するセッションのセッション状態が前記セッション状態保持手段に保持されておらず、且つ、前記パケットが正規のパケットであることを条件にして、前記パケットが属するセッションのセッション状態を前記セッション状態保持手段に格納するセッション依存処理手段と、
前記部分範囲について現用処理を担当している他のクラスタメンバに故障が発生したとき、前記セッション状態保持手段に保持されているセッション状態を利用して前記他のクラスタメンバが行っていた処理を前記セッション依存処理手段に引き継がせる引継制御手段と
をコンピュータに実現させるプログラム。
【請求項１６】
請求項１５記載のプログラムにおいて、
前記セッション依存処理手段として、
自クラスタメンバが現用処理を担当している部分範囲の不正なパケットを受信したとき、前記パケットを破棄する不正パケット処理手段と、
前記破棄したパケットが属するセッションを特定するセッション識別子を含んだ転送拒否通知を送信する転送拒否通知送信手段と、
自クラスタメンバが予備処理を担当している部分範囲のパケットを受信したとき、前記パケットが属するセッションのセッション状態が前記セッション状態保持手段に格納されていないことを条件にして、前記パケットが属するセッションのセッション状態を前記セッション状態保持手段に格納するセッション状態格納手段と、
自クラスタメンバが予備処理を担当している部分範囲について現用処理を担当している他のクラスタメンバからの転送拒否通知を受信したとき、前記セッション状態保持手段に保持されているセッション状態の内の、前記転送拒否通知に含まれているセッション識別子によって特定されるセッションのセッション状態を削除するセッション状態削除手段と
をコンピュータに実現させるプログラム。
【請求項１７】
請求項１５記載のプログラムにおいて、
前記セッション依存処理手段として、
自クラスタメンバが予備処理を担当している部分範囲のパケットを受信したとき、前記パケットが属するセッションのセッション状態が前記セッション状態保持手段に格納されていないことを条件にして、前記パケットが属するセッションのセッション状態を前記セッション状態保持手段に格納するセッション状態格納手段と、
前記セッション状態が前記セッション状態保持手段に格納されたときからの時間を計時し、所定時間経過後に前記セッション状態を前記セッション状態保持手段から削除するセッション監視タイマ手段と、
前記部分範囲の現用処理を担当しているクラスタメンバが前記パケットを次ホップへ転送したことを検出し、前記セッション監視タイマ手段による計時を停止させるデータリンク監視手段と
をコンピュータに実現させるプログラム。
【請求項１８】
処理対象となるトラフィックの全範囲を複数の部分範囲に分割した際の各部分範囲に対し、現用処理を行うクラスタメンバと、予備処理を行うクラスタメンバとを備え、
前記予備処理を行うクラスタメンバは、
受信したパケットが属するセッションのセッション状態を保持するセッション状態保持手段と、
自クラスタメンバが予備処理を担当している部分範囲のパケットを受信したとき、前記パケットが属するセッションのセッション状態が前記セッション状態保持手段に保持されておらず、且つ、自クラスタメンバが予備処理を担当している現用メンバが、前記パケットが正規のパケットであると判断したことを条件にして、前記パケットが属するセッションのセッション状態を前記セッション状態保持手段に格納するセッション依存処理手段と、
前記部分範囲について現用処理を担当している他のクラスタメンバに故障が発生したとき、前記セッション状態保持手段に保持されているセッション状態を利用して前記他のクラスタメンバが行っていた処理を前記セッション依存処理手段に引き継がせる引継制御手段と
を備えることを特徴とするクラスタシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＩＰパケットを転送するルータとして機能するクラスタシステム及びこれを構成するクラスタメンバに関し、特に、故障したクラスタメンバの代わりに新たに追加してクラスタメンバ上に、既設のセッションのセッション状態を復元する機能を有するクラスタシステム及びクラスタメンバに関する。
【背景技術】
【０００２】
ＩＰ網に設置されるルータには、ＩＰ層の上位層の情報を参照して処理を行う装置がある。たとえば、不正アクセス遮断等に用いられるファイアウォール装置や、ＩＰsecトンネルを終端するＶＰＮゲートウエイ装置などである。これらの装置は、パケットを受信する度に、受信したパケットが属する上位層のセッションを識別し、識別したセッションの状態（内部の記憶部に保持されている）と受信したパケットのヘッダ部の内容とに応じた処理（例えば、不正パケットの破棄など）を行うため、処理量が非常に多くなる。このため、装置を複数台用意して負荷を分散させる技術(クラスタシステム)が開発されてきた。【０００３】
このようなクラスタシステムの従来例としては、特表２００３−５１７２２１号公報または特表２００３−５１８３３８号公報に記載のものが知られている。この従来のクラスタシステムは、図２０に示すように、１台のマスタールータ装置１２００と、複数台のルータ装置（スレーブルータ装置）１２０１〜１２０ｎとから構成されている。各ルータ装置１２００〜１２０ｎは、それぞれの内部に、セッション処理部と、トラフィック分散フィルタとを備えている。【０００４】
隣接ＩＰノード１２１０からクラスタシステムへのＩＰパケット（単に、パケットと記す場合もある）は、データリンク層プロトコルでのマルチキャストにより、全ルータ装置１２００〜１２０ｎで受信される。各ルータ装置１２００〜１２０ｎ内のトラフィック分散フィルタは、データリンク１２２０上でマルチキャストされたＩＰパケットを、トラフィック分散規則に従って、通過或いは廃棄する。【０００５】
ここで、各ルータ装置１２００〜１２０ｎが備えているトラフィック分散フィルタのトラフィック分散規則は、次の条件を満たしている。
・同一のパケットが複数のルータ装置内のトラフィック分散フィルタを通過することはない。
・パケットは必ずいずれかのルータ装置内のトラフィック分散フィルタを通過する。【０００６】
各ルータ装置１２０１〜１２０ｎ内のトラフィック分散フィルタのトラフィック分散規則は、マスタールータ装置１２００により設定される。マスタールータ装置１２００は他のルータ装置１２０１〜１２０ｎ内のトラフィック分散フィルタにどのようなトラフィック分散規則が設定されているのかを把握しており、各ルータ装置１２０１〜１２０ｎの負荷が均等分散されるように、トラフィック分散規則を設定する。また、マスタールータ装置１２００は、トラフィック分散規則に当てはまらないパケットを処理するようなトラフィック分散フィルタを自装置内に備えている。また、マスタールータ装置１２００は、処理したパケットのセッション状態から新たなトラフィック分散規則を生成して、他のルータ装置１２０１〜１２０ｎのトラフィック分散フィルタに設定する。尚、マスタールータ装置１２００に故障が発生した場合には、他のルータ装置１２０１〜１２０ｎの何れか１台がマスタールータ装置として動作する。【０００７】
また、各ルータ装置１２０１〜１２０ｎ内のセッション処理部は、その内部に設定されているセッション処理規則とセッション状態を参照して、パケット分散フィルタを通過してきたパケットを処理し、破棄または転送させる。【０００８】
各ルータ装置１２０１〜１２０ｎ内のセッション処理部のセッション処理規則は、マスタールータ装置１２００によって設定されるものである。マスタールータ装置１２００を含む各ルータ装置１２００〜１２０ｎは、互いに自身のセッション状態を示すセッション状態を交換し合う。このセッション状態の交換は、一定時間毎に行われ、各ルータ装置１２００〜１２０ｎは、他のルータ装置のセッション処理規則と、交換した他のルータ装置の最新のセッション状態とを保持する。従って、ルータ装置１２０１〜１２０ｎの何れかに故障が発生した場合、マスタールータ装置１２００において、代替する装置を決定し、故障したルータ装置に設定されていた処理規則及びセッション状態を該当装置に引き継がせるという処理を行うことが可能になる。また、マスタールータ装置１２００に故障が発生した場合、他のルータ装置がマスタールータ装置１２００の処理を引き継ぐことが可能になる。
【発明の開示】
【発明が解決しようとする課題】
【０００９】
上述した従来の技術によれば、クラスタシステムを構成するどのルータ装置に障害が発生した場合であっても、自動復旧することが可能になる。しかし、自動復旧後は、故障したルータ装置（故障ルータ装置）が担当していた処理を他のルータ装置が担当することになるため、他のルータ装置の負荷が増大する。従って、いくら自動復旧できるからといって、そのまま放置しておくことは好ましくなく、正常に動作するルータ装置（新ルータ装置）をクラスタシステムに追加し、その台数を当初の台数に戻すことが望ましい。【００１０】
新ルータ装置を追加する場合、故障ルータ装置が保持していたセッション状態を新ルータ装置上に復元する必要がある。上述した従来の技術は、マスタールータ装置と新ルータ装置とが通信を行うことにより、新ルータ装置上にセッション状態を復元している。しかし、その際には、セッション状態だけでなく、送達確認などを行うための制御情報もやり取りすることが必要になるため、通信コストが高くなるという問題があった。【００１１】
そこで、本発明の目的は、新たに追加したクラスタメンバ上にセッション状態を復元する際の通信コストを低減させることにある。
【課題を解決するための手段】
【００１２】
このような目的を達成するために、本発明にかかるクラスタシステムは、処理対象となるトラフィックの全範囲を複数の部分範囲に分割した際の各部分範囲に対し、現用処理を行うクラスタメンバと、予備処理を行うクラスタメンバとを備え、前記予備処理を行うクラスタメンバは、受信したパケットが属するセッションのセッション状態を保持するセッション状態保持手段と、自クラスタメンバが予備処理を担当している部分範囲のパケットを受信したとき、前記パケットが属するセッションのセッション状態が前記セッション状態保持手段に保持されておらず、且つ、前記パケットが正規のパケットであることを条件にして、前記パケットが属するセッションのセッション状態を前記セッション状態保持手段に格納するセッション依存処理手段と、前記部分範囲について現用処理を担当している他のクラスタメンバに故障が発生したとき、前記セッション状態保持手段に保持されているセッション状態を利用して前記他のクラスタメンバが行っていた処理を前記セッション依存処理手段に引き継がせる引継制御手段とを備えることを特徴とする。【００１３】
また、本発明にかかるクラスタメンバは、受信したパケットが属するセッションのセッション状態を保持するセッション状態保持手段と、自クラスタメンバが予備処理を担当している部分範囲のパケットを受信したとき、前記パケットが属するセッションのセッション状態が前記セッション状態保持手段に保持されておらず、且つ、前記パケットが正規のパケットであることを条件にして、前記パケットが属するセッションのセッション状態を前記セッション状態保持手段に格納するセッション依存処理手段と、前記部分範囲について現用処理を担当している他のクラスタメンバに故障が発生したとき、前記セッション状態保持手段に保持されているセッション状態を利用して前記他のクラスタメンバが行っていた処理を前記セッション依存処理手段に引き継がせる引継制御手段とを備えることを特徴とする。
【発明の効果】
【００１４】
本発明では、自クラスタメンバが予備処理を担当している部分範囲において、正規のパケットを受信したときに、そのパケットが属するセッションのセッション状態をセッション状態保持手段に登録する。このため、例えば予備処理を行うクラスタメンバが故障した場合や、現用処理への引き継ぎにより消滅した場合に、そのクラスタメンバの代わりに動作するクラスタメンバを新たに追加するにあたって、送達確認などを行うための制御情報をやり取りすることなく、新たに追加したクラスタメンバ上にセッション状態を復元することができる。従って、セッション状態を復元する際の通信コストを低減させることが可能になる。
【図面の簡単な説明】
【００１５】
【図１】図１は、本発明にかかるクラスタシステムの第１の実施例の全体構成例を示すブロック図である。
【図２】図２は、各クラスタメンバ１−１〜１−Ｎが担当する現用処理，予備処理の範囲を示した図である。
【図３】図３は、クラスタメンバ１−１の構成例を示すブロック図である。
【図４】図４は、セッション処理部１５の機能を示すブロック図である。
【図５】図５は、セッション状態同期部１６の機能を示すブロック図である。
【図６】図６は、死活監視部２０の機能を示すブロック図である。
【図７】図７は、現用処理用パケットフィルタ１２を介してパケットが入力されたときのセッション処理部１５の処理例を示すフローチャートである。
【図８】図８は、予備処理用パケットフィルタ１３を介してパケットが入力されたときのセッション処理部１５の処理例を示すフローチャートである。
【図９】図９は、セッション処理部１５からセッション識別子が渡されたときにセッション状態同期部１６が行う転送拒否通知送信処理の処理例を示すフローチャートである。
【図１０】図１０は、セッション状態同期部１６が一定時間毎に行う空転送拒否通知送信処理の処理例を示すフローチャートである。
【図１１】図１１は、セッション監視タイマ部１７が行うセッション監視タイマ監視処理の一例を示すフローチャートである。
【図１２】図１２は、死活監視部２０が行うメンバ広告送信処理の一例を示すフローチャートである。
【図１３】図１３は、死活監視部２０がメンバ広告を受信したときの処理例を示すフローチャートである。
【図１４】図１４は、死活監視部２０が行う死活監視タイマ監視処理の一例を示すフローチャートである。
【図１５Ａ】図１５Ａは、クラスタメンバ１−２に故障が発生したときの復旧処理を説明するための図である。
【図１５Ｂ】図１５Ｂは、クラスタメンバ１−２に故障が発生したときの復旧処理を説明するための図である。
【図１５Ｃ】図１５Ｃは、クラスタメンバ１−２に故障が発生したときの復旧処理を説明するための図である。
【図１６】図１６は、セッション状態同期部１６がペア現用クラスタメンバからの転送拒否通知を受信したときの処理例を示すフローチャートである。
【図１７】図１７は、本発明の第２の実施例において使用するクラスタメンバ１−１ａの構成例を示すブロック図である。
【図１８】図１８は、セッション処理部１５ａが現用処理用パケットフィルタ１２を介してパケットを受信したときの処理例を示すフローチャートである。
【図１９】図１９は、セッション処理部１５ａが予備処理用パケットフィルタ１３を介してパケットを受信したときの処理例を示すフローチャートである。
【図２０】図２０は、従来の技術を説明するためのブロック図である。
【発明を実施するための最良の形態】
【００１６】
次に本発明の実施例について図面を参照して詳細に説明する。【００１７】
〔実施例の構成の説明〕
本発明の第１の実施例について説明する。図１に示すように、本実施例のクラスタシステム１は、ｎ個（複数個）のクラスタメンバ１−１〜１−ｎを備えている。各クラスタメンバ１−１〜１−ｎは、それぞれデータリンク３−１〜３−ｍを介して隣接ＩＰノード２−１〜２−ｍと接続されている。データリンク３−１〜３−ｍは、マルチキャストまたはブロードキャストをサポートしている。【００１８】
各クラスタメンバ１−１〜１−ｎには、共通のクラスタＩＰアドレス「Ｃ」が割り当てられている。隣接ＩＰノード２−１〜２−ｍからは、クラスタシステム１は、上記クラスタＩＰアドレス「Ｃ」を持つ、単一のＩＰノードとして認識される。【００１９】
また、各クラスタメンバ１−１〜１−ｎには、共通のクラスタマルチキャストＭＡＣアドレス「Ｍ」が割り当てられている。このクラスタマルチキャストＭＡＣアドレス「Ｍ」宛に送られるパケットは、全クラスタメンバ１−１〜１−ｎで受信されるよう、予め設定されている。【００２０】
更に、各クラスタメンバ１−１〜１−ｎには、それぞれ個別のＩＰアドレス「ｃ１」〜「ｃｎ」が割り当てられている。このＩＰアドレスは、クラスタメンバ１−１〜１−ｎ間の通信などに利用される。【００２１】
図２を参照し、各クラスタメンバ１−１〜１−ｎが担当する現用処理，予備処理の範囲について説明する。本実施例では、符号３１に示すように、クラスタシステム１が処理対象にしているトラフィックの全範囲Ｔをｎ個（クラスタメンバ数）の部分範囲Ｔ１，Ｔ２，Ｔ３，…，Ｔｎに分割している。そして、各クラスタメンバ１−１，１−２，１−３，…，１−ｎには、それぞれ符号３２に示すように、部分範囲Ｔ１，Ｔ２，Ｔ３，…，Ｔｎの現用処理を担当させ、符号３３に示すように、部分範囲Ｔ２，Ｔ３，…，Ｔｎ，Ｔ１の予備処理を担当させている。【００２２】
尚、各部分範囲Ｔ１〜Ｔｎは、各クラスタメンバ１−１〜１−ｎの負荷が均等（処理するパケット数が均等）になるように定めることが望ましく、例えば、次のようにする。パケットのＩＰ送信元アドレスとＩＰ宛先アドレスとに対して可換な演算（例えば、両者の加算，乗算など）を行い、その演算結果をクラスタメンバ数「ｎ」で割る。その時の余りが「０」〜「ｎ−１」となったパケットをそれぞれ部分範囲Ｔ１〜Ｔｎに属するパケットとする。【００２３】
また、本実施例では、各クラスタメンバ１−１〜１−ｎに担当させる現用処理，予備処理の範囲を図２に示すものとしたが、これに限られるものではなく、次式（１）〜（５）を満たせばどのようなものであっても良い。尚、式（１）〜（５）において、mfi,bfiはそれぞれクラスタメンバ１−ｉ（１≦ｉ≦ｎ）が現用処理，予備処理を担当する範囲を示し、φは空集合を示す。【００２４】
mf1 ∪ mf2 ∪ ... ∪ mfn＝Ｔ  …（１）
mf1 ∩ mf2 ∩ ... ∩ mfn＝φ  …（２）
bf1 ∪ bf2 ∪ ... ∪ bfn＝Ｔ  …（３）
bf1 ∩ bf2 ∩ ... ∩ bfn＝φ  …（４）
bfi ∩ mfi＝φ                …（５）【００２５】
また、本実施例では、１台のクラスタメンバに、異なる部分範囲の現用処理と予備処理とを担当させるようにしたが、１台のクラスタメンバには、１つの部分範囲の現用処理或いは予備処理のみを担当させるようにしても良い。このようにした場合には、クラスタメンバの台数は部分範囲の数の２倍必要になる。【００２６】
図３を参照し、クラスタメンバ１−１の構成例について説明する。クラスタメンバ１−１は、インタフェース部（ＩＦ部）１１−１〜１１−ｎと、現用処理用パケットフィルタ１２と、予備処理用パケットフィルタ１３と、セッション処理部１５及びセッション状態同期部１６を含むセッション依存処理部１４と、セッション監視タイマ部１７と、セッション状態保持部１８と、冗長構成情報保持部１９と、死活監視部２０と、死活タイマ部２１と、経路制御部２２と、ルーティングテーブル２３とを備えている。尚、他のクラスタメンバ１−２〜１−ｎもクラスタメンバ１−１と同様の構成を有している。【００２７】
インタフェース部１１−１〜１１−ｍは、それぞれデータリンク３−１〜３−ｍに接続され、パケット等を送受信する。【００２８】
現用処理用パケットフィルタ１２は、インタフェース部１１−１〜１１−ｍから入力されたパケット等の内、自クラスタメンバ１−１が現用処理を担当する部分範囲のパケットをセッション処理部１５に渡し、それ以外は予備処理用パケットフィルタ１３に渡す機能を有する。【００２９】
予備処理用パケットフィルタ１３は、現用処理用パケットフィルタ１２から渡されたパケット等の内、自クラスタメンバ１−１が予備処理を担当する部分範囲のパケットをセッション処理部１５に渡し、それ以外はセッション状態同期部１６，死活監視部２０に出力する機能を有する。【００３０】
セッション処理部１５は、現用処理用パケットフィルタ１２，予備処理用パケットフィルタ１３からパケットが渡された場合、次のような処理を行う。【００３１】
〔現用処理用パケットフィルタ１２からパケットが渡されたときのセッション処理部１５の処理〕
・パケットが属するセッションを識別する。これは図４に示すセッション識別部１５１の機能である。
・セッション確立パケット（例えば、ＴＣＰのＳＹＮパケットなど）ならば、そのパケットが属するセッションのセッション識別子とセッション状態とを対応付けてセッション状態保持部１８に登録する。これは図４に示すセッション状態格納部１５２の機能である。
・不正パケットならば、そのパケットを破棄すると共に、セッション状態同期部１６に上記不正パケットが属するセッションのセッション識別子を通知する。これは図４に示す不正パケット処理部１５３の機能である。
・既設セッションの正常なパケットならば、セッション状態保持部１８に保持されているセッション状態を更新すると共に、上記パケットを経路制御部２２に渡す。これは図４に示すセッション状態更新部１５４の機能である。【００３２】
〔予備処理用パケットフィルタ１３からパケットが渡されたときのセッション処理部１５の処理〕
・パケットが属するセッションを識別する。これは図４に示すセッション識別部１５１の機能である。
・セッション確立パケットならば、そのパケットが属するセッションのセッション識別子とセッション状態とを対応付けてセッション状態保持部１８に登録し、その後、パケットを破棄する。これは図４に示すセッション状態格納部１５２の機能である。
・既設セッションのパケットならば、セッション状態保持部１８に登録されている該当するセッション状態を更新し、その後、パケットを破棄する。これは図４に示すセッション状態更新部１５４の機能である。
・既設セッションのパケットでないならば、パケットが属するセッションのセッション識別子とセッション状態と保留フラグ（保留識別子）とを対応付けてセッション状態保持部１８に登録すると共に、セッション監視タイマ部１７に対して上記セッション用のセッション監視タイマを設定することを指示し、その後、パケットを破棄する。これは図４に示すセッション状態格納部１５２の機能である。【００３３】
ここで、セッションは、ＩＰの拡張プロトコルおよび上位層プロトコルにより提供される仮想通信路を指し、例えば、ＴＣＰのコネクション,ＩＰｓｅｃのSecurity Associationなどが含まれる。セッション状態は、これらのセッション毎に保持される固有の情報を指し、ＴＣＰのコネクションの場合は、 コネクションの状態，シーケンス番号，応答番号などを含む。また、ＩＰｓｅｃ  ＳＡの場合には、ＲＦＣ２４０１で定められるＳＡのパラメータを含む。【００３４】
エラーフラグ２４には、パケットを取りこぼす可能性のあるエラーがクラスタメンバ１−１において発生したとき、図示を省略したエラー検出手段によりエラーフラグ＝“１”が設定される。【００３５】
セッション状態同期部１６は、次のような機能を有する。【００３６】
・セッション処理部１５から破棄パケットが属するセッションのセッション識別子が渡されたとき、上記セッション識別子と、エラーフラグ２４の値とを含んだ転送拒否通知を、自クラスタメンバ１−１が現用処理を担当している部分範囲の予備処理を担当しているクラスタメンバ（ペア予備クラスタメンバと記す場合がある）に送信し、その後、エラーフラグ２４を“０”に更新する。これは図５に示す転送拒否通知送信部１６１の機能である。
・一定時間毎に、ペア予備クラスタメンバに対して、エラーフラグ２４の値を含んだ転送拒否通知（セッション識別子は含んでいない。空転送拒否通知と呼ぶ場合がある）を送信し、その後、エラーフラグ２４を“０”に更新する。これは図５に示す空転送拒否通知送信部１６２の機能である。
・自クラスタメンバ１−１が予備処理を担当している部分範囲の現用処理を担当しているクラスタメンバ（ペア現用クラスタメンバと記す場合もある）からの転送拒否通知を受信したとき、それに含まれているエラーフラグが“１”であれば、セッション状態保持部１８に保持されているセッション状態の内の、上記転送拒否通知に含まれているセッション識別子によって特定されるセッションのセッション状態を削除する。エラーフラグが“０”であれば、セッション状態保持部１８に保持されているセッション状態の内の、上記転送拒否通知に含まれているセッション識別子によって特定されるセッションのセッション状態を削除すると共に、保留フラグ削除候補になっているセッション状態の保留フラグを削除する。更に、保留フラグが付いているセッション状態のセッション識別子を保留フラグ削除候補として保持する。これは図５に示すセッション状態削除部１６３、保留フラグ削除部１６４の機能である。【００３７】
セッション監視タイマ部１７は、セッション状態がセッション状態保持部１８に登録されたときかの時間を計時し、所定時間以上、保留フラグが付いたままになっているセッション状態（タイムアウトしたセッション監視タイマに対応するセッションのセッション状態）を、セッション状態保持部１８から削除する機能を有する。【００３８】
冗長構成情報保持部１９には、自クラスタメンバ１−１と冗長構成になっているクラスタメンバ（ペア現用クラスタメンバ，ペア予備クラスタメンバ）のＩＰアドレスが格納されている。【００３９】
死活タイマ部２１は、ペア予備クラスタメンバ用の死活監視タイマ（図示せず）と、ペア現用クラスタメンバ用の死活監視タイマ（図示せず）との２つの死活監視タイマを有している。【００４０】
死活監視部２０は、次のような機能を有している。【００４１】
・メンバ広告送信タイミングとなる毎に、ペア予備クラスタメンバ及びペア現用クラスタメンバにメンバ広告を送信する。これは図６に示すメンバ広告送信部２０１の機能である。
・ペア予備クラスタメンバ或いはペア現用クラスタメンバからのメンバ広告を受信したとき、死活タイマ部２１に対して該当する死活監視タイマのリセットを指示する。これは図６に示すタイマリセット部２０２の機能である。
・ペア現用クラスタメンバ用の死活監視タイマがタイムアウトしたとき、セッション処理部１５に対して予備処理用パケットフィルタ１３が現用処理用パケットフィルタに切り替わったことを通知する。即ち、ペア現用クラスタメンバに故障が発生したとき、セッション状態保持部１８に保持されているセッション状態を利用して、ペア現用クラスタメンバが行っていた処理をセッション処理部１５に引き継がせる。これは図６に示す引継制御部２０３の機能である。
・ペア予備クラスタメンバ用の死活監視タイマがタイムアウトしたとき、システム管理者にそのことを通知する。これは図６に示す管理者通知部２０４の機能である。【００４２】
経路制御部２２は、セッション処理部１５から渡されたパケットの宛先とルーティングテーブル２３の内容とに基づいて、送出方路とするインタフェース部を決定し、そのインタフェース部を介して上記パケットを次ホップに転送する機能などを有する。【００４３】
尚、クラスタメンバ１−１はコンピュータによって実現可能なものであり、コンピュータによってクラスタメンバ１−１を実現する場合は、次のようにする。クラスタメンバ用のプログラムを記録したディスク、半導体メモリ、その他の記録媒体を用意する。コンピュータは、上記プログラムを読み込み、自身の動作を制御することにより、自コンピュータ上にインタフェース部１１−１〜１１−ｍ、現用処理用パケットフィルタ１２、予備処理用パケットフィルタ１３、セッション依存処理部１４、セッション監視タイマ部１７、死活監視部２０、死活タイマ部２１、経路制御部２２を実現する。【００４４】
〔実施例の動作の説明〕
次に、本実施例の動作について詳細に説明する。【００４５】
先ず、図１を参照してクラスタシステム１と隣接ＩＰノード２−１〜２−ｍとの関係について説明する。クラスタシステム１の各クラスタメンバ１−１〜１−ｎは、クラスタＩＰアドレス「Ｃ」をターゲットとするＡＲＰメッセージへの応答として、クラスタマルチキャストＭＡＣアドレス「Ｍ」を返す。これにより、隣接ＩＰノード２−１〜２−ｍがアドレス「Ｃ」を次ホップとして送出するパケットを含むデータリンクフレームはアドレス「Ｍ」宛に送られ、全クラスタメンバ１−１〜１−ｎで受信される。【００４６】
次に、クラスタシステム１内の各クラスタメンバ１−１〜１−ｎの動作について説明する。尚、各クラスタメンバ１−１〜１−ｎの動作は同じであるので、ここでは、クラスタメンバ１−ｉ（１≦ｉ≦ｎ）の動作を例に挙げて説明する。【００４７】
クラスタメンバ１−ｉ内の現用処理用パケットフィルタ１２は、インタフェース部１１−１〜１１−ｎを介してパケット（隣接ＩＰノード２−１〜２−ｍからのパケットや、他のクラスタメンバ１−２〜１−ｎからのメンバ広告，転送拒否通知）が入力されると、そのパケットが、自クラスタメンバ１−ｉが現用処理を担当している部分範囲に属しているか否かを調べる。そして、属している場合には、そのパケットをセッション処理部１５に渡し、属していない場合は、予備処理用パケットフィルタ１３に渡す。【００４８】
予備処理用パケットフィルタ１３は、現用処理用パケットフィルタ１２からパケットが渡されると、そのパケットが、自クラスタメンバ１−ｉが予備処理を担当している部分範囲に属しているか否かを調べる。そして、属している場合には、そのパケットをセッション処理部１５に渡し、属していない場合には、セッション状態同期部１６及び死活監視部２０に対して上記パケット（メンバ広告，転送拒否通知）を出力する。【００４９】
セッション処理部１５は、現用処理用パケットフィルタ１２，予備処理用パケットフィルタ１３からパケットが入力されると、それぞれ図７，図８のフローチャートに示す処理を実行する。【００５０】
先ず、図７を参照して現用処理用パケットフィルタ１２を介してセッション処理部１５にパケットが入力された場合の動作について説明する。【００５１】
セッション処理部１５は、現用処理用パケットフィルタ１２を介してパケットが入力されると、先ず、そのパケットが属するセッションを識別する（図７のステップＳ４１）。その後、パケットがセッション確立パケットであるか否かを調べる（ステップＳ４２）。【００５２】
そして、セッション確立パケットである場合（ステップＳ４２がＹＥＳ）は、ステップＳ４１で識別したセッションのセッション識別子と、上記セッションのセッション状態とを対応付けてセッション状態保持部１８に登録し、更に、セッション確立パケットを経路制御部２２に渡す（ステップＳ４３，Ｓ４８）。これに対して、セッション確立パケットでない場合（ステップＳ４２がＮＯ）は、パケットのヘッダ情報とセッション状態保持部１８に保持されている該当するセッションのセッション状態とに基づいて上記パケットが不正パケットであるか否かを判断する（ステップＳ４４）。例えば、セッション状態がセッション状態保持部１８に保持されていないパケットや、セッション状態保持部１８に保持されているセッション状態とパケットのヘッダ部の内容（ヘッダ情報）とに矛盾があるパケットを不正パケットとする。ヘッダ情報は、例えば、パケットの宛先および送信元のＩＰアドレスや、上位層（ＴＣＰやＵＤＰなど）のヘッダ部に含まれる、宛先および送信元のポート番号などである。【００５３】
そして、不正パケットでない、即ち正規のパケットと判断した場合（ステップＳ４４がＮＯ）は、セッション状態保持部１８に登録されている該当するセッション状態を、今回入力されたパケットのヘッダ部の内容に応じて更新し、更に、上記パケットを経路制御部２２に渡す（ステップＳ４７，Ｓ４８）。経路制御部２２は、パケットが渡されると、そのパケットの宛先とルーティングテーブル２３の内容とに基づいて、送出方路とするインタフェース部を決定し、そのインタフェース部を介して上記パケットを次ホップに転送する。【００５４】
これに対して、不正パケットであると判断した場合（ステップＳ４４がＹＥＳ）は、パケットを破棄すると共に、破棄したパケットが属するセッションのセッション識別子をセッション状態同期部１６に渡す（ステップＳ４５，Ｓ４６）。【００５５】
セッション状態同期部１６は、セッション処理部１５からセッション識別子が渡されると、図９のフローチャートに示すように、先ず、エラーフラグ２４を参照する（ステップＳ６１）。その後、セッション状態同期部１６は、エラーフラグ２４の値と、破棄パケットが属するセッションのセッション識別子とを含み、且つ、宛先をペア予備クラスタメンバのＩＰアドレスとした転送拒否通知を経路制御部２２に渡し、更に、エラーフラグ２４を“０”に更新する（ステップＳ６２，Ｓ６３）。尚、ペア予備クラスタメンバのＩＰアドレスは、冗長構成情報保持部１９に保持されている。【００５６】
また、セッション状態同期部１６は、セッション処理部１５から破棄パケットが属するセッションのセッション識別子が渡された場合だけでなく、一定時間毎に、転送拒否通知をペア予備クラスタメンバに送信する処理を行っている。図１０を参照すると、セッション状態同期部１６は、一定時間が経過する毎に（ステップＳ７４がＹＥＳとなる毎に）、エラーフラグ２４の値を含み、セッション識別子は含まない転送拒否通知（空転送拒否通知）をペア予備クラスタメンバに送信し（ステップＳ７１，Ｓ７２）、その後、エラーフラグ２４の値を“０”に更新する処理を行っている。尚、上記一定時間は、後述するセッション監視タイマがタイムアウトする時間よりも短い時間とする。【００５７】
次に、図８を参照し、予備処理用パケットフィルタ１３を介してセッション処理部１５にパケットが入力された場合の動作について説明する。【００５８】
セッション処理部１５は、予備処理用パケットフィルタ１３を介してパケットが入力されると、先ず、上記パケットが属するセッションを識別する（図８のステップＳ５１）。その後、セッション確立パケットであるか否かを判断する（ステップＳ５２）。【００５９】
そして、セッション確立パケットである場合（ステップＳ５２がＹＥＳ）は、ステップＳ５１で識別したセッションのセッション識別子と、上記セッションのセッション状態とを対応付けてセッション状態保持部１８に登録し、その後、上記パケットを破棄する（ステップＳ５３，Ｓ５８）。これに対して、セッション確立パケットでないと判断した場合（ステップＳ５２がＮＯ）は、既設セッションに属するパケットであるか否かを判断する（ステップＳ５４）。【００６０】
そして、既設セッションに属するパケットである場合（ステップＳ５４がＹＥＳ）は、セッション状態保持部１８に登録されている該当するセッション状態を更新した後、パケットを破棄する（ステップＳ５５，Ｓ５８）。【００６１】
これに対して、既設セッションのパケットでない場合（ステップＳ５４がＮＯ）は、ステップＳ５１で識別したセッションのセッション識別子と、上記セッションのセッション状態と、保留フラグとを対応付けてセッション状態保持部１８に登録し（ステップＳ５６）、更に、セッション監視タイマ部１７に対して上記セッション用のセッション監視タイマを設定することを指示し（ステップＳ５７）、その後、上記パケットを破棄する（ステップＳ５８）。【００６２】
セッション監視タイマ部１７は、セッション処理部１５からの指示に従い、指示されたセッション用のセッション監視タイマ（図示せず）を設定する。また、セッション監視タイマ部１７は、図１１のフローチャートに示すセッション監視タイマ監視処理も行っている。図１１を参照すると、セッション監視タイマ部１７は、設定されているセッション監視タイマ（１個も設定されていない場合もある）の中にタイムアウトしたセッション監視タイマが発生すると（ステップＳ８１，Ｓ８２がＹＥＳ）、セッション状態保持部１８を検索し、上記セッション監視タイマと対応するセッションのセッション状態に保留フラグが付されているか否かを調べる（ステップＳ８３）。そして、保留フラグが付いている場合は、該当するセッション状態をセッション状態保持部１８から削除した後、タイムアウトしたセッション監視タイマを削除する（ステップＳ８４，Ｓ８５）。これに対して、保留フラグが付いていない場合は、タイムアウトしたセッション監視タイマを削除する（ステップＳ８５）。これにより、一定時間以上、保留フラグが付いたままになっているセッション状態が一律に削除される。【００６３】
以上が、現用処理用パケットフィルタ１２，予備処理用パケットフィルタ１３を介してセッション処理部１５へパケットが入力されたときのクラスタメンバ１−ｉの動作である。【００６４】
上述した動作が各クラスタメンバ１−１〜１−ｎで実行されることにより、同一部分範囲についての現用処理，予備処理を担当している２台のクラスタメンバで同一のセッション状態が保持される。【００６５】
次に、各クラスタメンバ１−１〜１−ｎが、ペア予備クラスタメンバ，ペア現用クラスタメンバの故障を検出し、復旧するために行っている処理について説明する。この場合も、クラスタメンバ１−ｉの動作を例に挙げて説明する。【００６６】
クラスタメンバ１−ｉ内の死活監視部２０は、図１２のフローチャートに示すように、メンバ広告送信タイミングとなる毎に（ステップＳ９１がＹＥＳとなる毎に）、メンバ広告を経路制御部２２に渡す（ステップＳ９２）。メンバ広告には、送信元のクラスタメンバ１−ｉを特定するメンバ識別子が含まれている。また、宛先は、ペア予備クラスタメンバ及びペア現用クラスタメンバが受信できるアドレス（例えば、クラスタマルチキャストＭＡＣアドレス）となっている。経路制御部２２は、メンバ広告が死活監視部２０から渡されると、ルーティングテーブル２３の内容に基づいて決まるインタフェース部１１−ｊ（１≦ｊ≦ｍ）を介してデータリンク３−ｊに送出する。【００６７】
クラスタメンバ１−ｉで受信された他のクラスタメンバからのメンバ広告は、現用処理用パケットフィルタ１２及び予備処理用パケットフィルタ１３を介して死活監視部２０に入力される。死活監視部２０は、入力されたメンバ広告の送信元がペア現用クラスタメンバ或いはペア予備クラスタメンバである場合には、図１３のフローチャートに示すように、死活タイマ部２１に対して該当する死活監視タイマをリセットすることを指示する（ステップＳ１０１）。即ち、送信元がペア現用クラスタメンバである場合には、ペア現用クラスタメンバ用の死活監視タイマをリセットするように指示し、送信元がペア予備クラスタメンバである場合には、ペア予備クラスタメンバ用の死活監視タイマをリセットするように指示する。これに応答して、死活タイマ部２１は指示された死活監視タイマをリセットする。尚、死活監視部２０は、ペア予備クラスタメンバ，ペア現用クラスタメンバ以外のクラスタメンバから送られてきたメンバ広告は破棄する。【００６８】
また、死活監視部２０は、図１４のフローチャートに示す死活監視タイマ監視処理を行っている。【００６９】
図１４を参照すると、死活監視部２０は、ペア現用クラスタメンバ用の死活監視タイマ，ペア予備クラスタメンバ用の死活監視タイマがタイムアウトしたか否かを常に監視している（ステップＳ１１１〜Ｓ１１４）。そして、ペア予備クラスタメンバ用の死活監視タイマがタイムアウトした場合（ステップＳ１１４がＹＥＳ）、ペア予備クラスタメンバに故障が発生したと見なし、そのことをシステムログや画面表示などでシステム管理者に通知する（ステップＳ１１５）。また、ペア現用クラスタメンバ用の死活監視タイマがタイムアウトした場合（ステップＳ１１２がＹＥＳ）は、ペア現用クラスタメンバに故障が発生したと見なし、ステップＳ１１６以降の処理を行う。ステップＳ１１６では、自クラスタメンバ１−ｉ内のセッション状態保持部１８に保持されているセッション状態の内の、保留フラグが付されているセッション状態を削除し、ステップＳ１１７では、セッション処理部１５に対して予備処理用パケットフィルタ１３が現用処理用パケットフィルタに切り替わったことを通知し、ステップＳ１１８では、ペア現用クラスタメンバに故障が発生したことをシステム管理者へ通知する。尚、セッション処理部１５は、予備処理用パケットフィルタ１３が現用処理用パケットフィルタに切り替わったことが通知された後は、予備処理用パケットフィルタ１３を介して入力されるパケットについても、図７のフローチャートに示す処理を行う。つまり、ペア現用クラスタメンバが故障した場合、そのクラスタメンバが担当していた現用処理を引き継ぐことになる。【００７０】
本実施例の場合、１台のクラスタメンバが故障すると、２つの部分範囲について、その部分範囲の予備処理を担当するクラスタメンバが存在しなくなる。即ち、故障したクラスタメンバが予備処理を担当していた部分範囲と、故障したクラスタメンバが現用処理を担当していた部分範囲の予備処理を担当するクラスタメンバが存在しなくなる。【００７１】
例えば、クラスタシステム１において、図１５Ａに示すように、各クラスタメンバ１−１，１−２，…，１−ｎが、部分範囲Ｔ１，Ｔ２，…，Ｔｎの現用処理（実線の矢印で示す）と、部分範囲Ｔ２，Ｔ３，…，Ｔ１の予備処理（破線の矢印で示す）とを担当している状態において、クラスタメンバ１−２に故障が発生すると、図１５Ｂに示すように、クラスタメンバ１−２が現用処理を担当していた部分範囲Ｔ２とクラスタメンバ１−２が予備処理を担当していた部分範囲Ｔ３の予備処理を担当するクラスタメンバが存在しなくなってしまう。尚、故障したクラスタメンバ１−２が現用処理を担当していた部分範囲Ｔ２の現用処理は、クラスタメンバ１−１によって引き継がれる。【００７２】
このような場合、システム管理者は、図１５Ｃに示すように、故障したクラスタメンバ１−２に代えて、部分範囲Ｔ２の現用処理と、部分範囲Ｔ３の予備処理を担当する新たなクラスタメンバ１−２ａをクラスタシステム１に追加すると共に、故障したクラスタメンバ１−２の現用処理を引き継いでいたクラスタメンバ１−１内のセッション処理部１５の状態を元の状態（予備処理用パケットフィルタ１３を介して入力されたパケットに対しては、図８のフローチャートに示す処理を実行する状態；部分範囲Ｔ２の予備処理を担当する状態）に戻す。尚、新たに追加したクラスタメンバ１−２ａは、故障したクラスタメンバ１−２と同様の構成，機能を有するものである。但し、追加された時点においては、クラスタメンバ１−２ａ内のセッション状態保持部１８には、全くセッション状態が登録されていない。【００７３】
以下、故障したクラスタメンバ１−２の代わりに、新たなクラスタメンバ１−２ａが追加された場合の動作を説明する。【００７４】
追加されたクラスタメンバ１−２ａにパケットが入力された場合、それが、現用処理を担当している部分範囲Ｔ２に属するものであれば、現用処理用パケットフィルタ１２を介してセッション処理部１５に入力され、予備処理を担当している部分範囲Ｔ３に属するものであれば、予備処理用パケットフィルタ１３を介してセッション処理部１５に入力され、それ以外のものであれば、セッション状態同期部１６，死活監視部２０に入力される。【００７５】
セッション処理部１５は、現用処理用パケットフィルタ１２を介してパケットが入力された場合は、前述した図７のフローチャートに示す処理を実行し、予備処理用パケットフィルタ１３を介してパケットが入力された場合は、前述した図８のフローチャートに示す処理を実行する。【００７６】
ここで、予備処理用パケットフィルタ１３を介して入力されたパケットが既設セッションに属していないパケットである場合、即ちセッション状態保持部１８にセッション状態が保持されていないセッションに属するパケットである場合（図８のステップＳ５４がＮＯ）、クラスタメンバ１−２ａのセッション処理部１５では、上記パケットが属するセッションのセッション識別子，セッション状態に保留フラグを付けてセッション状態保持部１８に登録すると共に、セッション監視タイマ部１７に対して上記セッションに対応するセッション監視タイマを設定することを指示する（ステップＳ５６，Ｓ５７）。【００７７】
ここで、保留フラグを付けて上記パケットが属するセッションのセッション状態をセッション状態保持部１８に登録するのは、次の理由からである。即ち、上記パケットは、部分範囲Ｔ３の現用処理を担当しているクラスタメンバ１−３において、既設セッションに属する正規のパケットとして処理されている可能性があるからである。もし、上記パケットが既設セッションに属する正規のパケットである場合には、セッション状態同期部１６が行う、図１６のフローチャートに示す処理により、保留フラグは削除される。また、上記パケットが不正パケットである場合には、セッション状態同期部１６が行う、図１６のフローチャートに示す処理により、セッション状態保持部１８に保持されている、上記パケットが属するセッションのセッション状態は削除される。また、一定時間以上、保留フラグが付いたままになっているセッション状態も、セッション監視タイマ部１７が行う、図１１のフローチャートに示す処理により削除される。【００７８】
クラスタメンバ１−２ａ内のセッション状態同期部１６は、ペア現用クラスタメンバ（この例の場合、クラスタメンバ１−３）で不正パケットがあったときに送信される転送拒否通知を、予備処理用パケットフィルタ１３を介して受信すると、図１６のフローチャートに示す処理を行う。先ず、転送拒否通知に含まれているエラーフラグが“１”であるか“０”であるかを判定する（ステップＳ１３１）。【００７９】
その結果、エラーフラグが“０”の場合、即ち、クラスタメンバ１−３が正常に動作している場合（ステップＳ１３１がＮＯ）は、セッション状態保持部１８に保持されているセッション状態の中から、転送拒否通知中のセッション識別子によって特定されるセッション状態を削除する（ステップＳ１３３）。これにより、セッション状態保持部１８から、不正パケットにかかるセッション状態が削除される。【００８０】
また、本実施例では、この不正パケットよりも前にクラスタメンバ１−２ａで受信されたパケットを原則として正規のパケットとみなし、正規のパケットとみなしたパケットが属するセッションのセッション状態から保留フラグを削除する。ここでは、前回の転送拒否通知を受信したときの処理の後にセッション状態保持部１８に保持されている保留フラグ付きのセッション状態を保留フラグ削除候補とし、この候補となっているセッション状態の保留フラグを今回の転送拒否通知の受信によって削除する（ステップＳ１３４）。
また、セッション状態保持部１８に保持されているセッション状態の内の、保留フラグ付きのセッション状態のセッション識別子を保留フラグ削除候補として保持する（ステップＳ１３５）。このような処理を行うことにより、その後に仮にセッション監視タイマがタイムアウトしても、正規のパケットが属するセッションのセッション状態から保留フラグが削除されているので、そのセッション状態がセッション状態保持部１８から削除されることはない。【００８１】
しかし、ペア現用クラスタメンバ１−３で不正パケットを取りこぼし、不正パケットの存在が転送拒否通知により当該クラスタメンバ１−２ａに通知されないと、ペア現用クラスタメンバ１−３で次に不正パケットが確認されたときの転送拒否通知により、当該クラスタメンバ１−２ａに保持されている不正パケットにかかるセッション状態から保留フラグが削除され、そのセッション状態が保持され続けることになる。【００８２】
これを防止するため、本実施例では、転送拒否通知に含まれているエラーフラグが“１”である場合、即ち、ペア現用クラスタメンバ１−３でパケットを取りこぼす可能性があるエラーが発生している場合（ステップＳ１３１がＹＥＳ）は、転送拒否通知中のセッション識別子によって特定されるセッションのセッション状態をセッション状態保持部１８から削除する処理のみを行ない（ステップＳ１３２）、保留フラグ削除以降の処理を行わない。これにより、ペア現用クラスタメンバ１−３で不正パケットの取りこぼしがあっても、その後にその不正パケットが確認されたときに、その不正パケットにかかるセッション状態を当該クラスタメンバ１−２ａのセッション状態保持部１８から削除することが可能となる。尚、図１６のフローチャートに示した処理は、他のクラスタメンバ内のセッション状態同期部１６においても行われる。【００８３】
このように、本実施例では、ペア現用クラスタメンバ１−３で不正パケットを確認したときに転送拒否通知を送信し、当該クラスタメンバ１−２ａで正規のパケットにかかるセッション状態から保留フラグを削除する処理を行う。従って、この方式では、少なくともペア現用クラスタメンバ１−３に不正パケットが送られてこないと、正規のパケットにかかるセッション状態には保留フラグが付いたままになる。さらに、ペア現用クラスタメンバ１−３で転送するパケットが増えてくると、パケットを取りこぼす可能性が高くなり、仮に不正パケットが送られてきても転送拒否通知に含まれるエラーフラグが“１”となって、やはり保留フラグを削除することができない。しかし、保留フラグはなるべく短時間で削除することが望ましい。その理由は、ペア現用クラスタメンバ１−３が故障しその処理を当該クラスタメンバ１−２ａが引き継ぐときに、保留フラグが付いているセッション状態についてはその正当性を判断できないため、すべて破棄せざるを得ないからである。【００８４】
そこで、本実施例では、上述したように、ペア現用クラスタメンバ１−３からセッション状態識別子を含まない空転送拒否通知を定期的に送信する。この空転送拒否通知を受信した当該クラスタメンバ１−２ａでは、エラーフラグが“０”である場合（ステップＳ１３１がＹＥＳ）、セッション状態の削除処理を行わず、保留フラグ削除候補となっているセッション状態に付いている保留フラグの削除と、次の保留フラグ削除候補の指定のみの処理を行う（ステップＳ１３４，Ｓ１３５）。これにより、保留フラグ付きが長時間続く状態を改善することができる。【００８５】
上述した処理により、クラスタメンバ１−３が保持する部分範囲Ｔ３に関するセッション状態について、実際にそのセッションのパケットが転送されれば、クラスタメンバ１−２ａでも部分範囲Ｔ３に関するセッション状態が復元される。【００８６】
〔発明の他の実施例〕
次に本発明の第２の実施例について説明する。本実施例は、転送拒否通知を不要にしたことを特徴とする。【００８７】
図１７に示す本実施例で使用するクラスタメンバ１−１ａと、図３に示したクラスタメンバ１−１との相違点は、セッション依存処理部１４の代わりにセッション依存処理部１４ａを備えている点、セッション監視タイマ部１７の代わりにセッション監視タイマ部１７ａを備えている点、冗長構成情報保持部１９を備えていない点、およびエラーフラグ２４を備えていない点である。【００８８】
セッション依存処理部１４ａとセッション依存処理部１４との相違点は、セッション処理部１５の代わりにセッション処理部１５ａを備えている点、データリンク監視部２５が追加されている点、セッション状態同期部１６を備えていない点である。【００８９】
尚、クラスタメンバ１−１ａはコンピュータによって実現可能なものであり、コンピュータによってクラスタメンバ１−１ａを実現する場合は、次のようにする。クラスタメンバ用のプログラムを記録したディスク、半導体メモリ、その他の記録媒体を用意する。コンピュータは、上記プログラムを読み込み、自身の動作を制御することにより、自コンピュータ上にインタフェース部１１−１〜１１−ｍ、現用処理用パケットフィルタ１２、予備処理用パケットフィルタ１３、セッション依存処理部１４ａ、セッション監視タイマ部１７ａ、死活監視部２０、死活監視タイマ部２１、経路制御部２２を実現する。【００９０】
次に、本実施例の動作について説明する。ここでは、前述した第１の実施例との相違点のみを説明する。【００９１】
セッション処理部１５ａは、現用処理用パケットフィルタ１２からパケットが入力された場合、図１８のフローチャートに示す処理を行い、予備処理用パケットフィルタ１３からパケットが入力された場合、図１９のフローチャートに示す処理を行う。【００９２】
図１８のフローチャートと図７のフローチャートとの相違点は、ステップＳ４６の処理がない点だけである。つまり、本実施例では、現用処理用パケットフィルタ１２を通過したパケットを破棄した場合であっても、第１の実施例のように、転送拒否通知をペア予備クラスタメンバに送信することはない。【００９３】
また、図１９のフローチャートと図８のフローチャートとの相違点は、ステップＳ５７とステップＳ５８との間にステップＳ５７１が追加されている点だけである。つまり、本実施例では、予備処理用パケットフィルタ１３を介して入力されたパケットが、セッション確立パケットでも、既設セッションに属するパケットでもない場合（ステップＳ５４がＮＯ）、第１の実施例で行われていた処理（ステップＳ５６，Ｓ５７）に加え、上記パケットのパケット識別子をデータリンク監視部２５に渡す処理も行われる（ステップＳ５７１）。尚、ステップＳ５６では、上記パケットが属するセッションのセッション状態とセッション識別子とに保留フラグを付けてセッション状態保持部１８に登録する処理が行われ、ステップＳ５７では、セッション監視タイマ部１７ａに対して、上記セッションに対応するセッション監視タイマを設定することを指示する処理が行われる（これによりセッション監視タイマ部１７ａによる計時が開始される）。【００９４】
データリンク監視部２５は、送出側のデータリンクを監視しており、セッション処理部１５ａから渡されたパケット識別子のパケットを検出した場合（パケットが次ホップに転送された場合）には、セッション監視タイマ部１７ａに設定されているセッション監視タイマの内の、上記パケットが属するセッションのセッション監視タイマを削除し（これによりセッション監視タイマ部１７ａによる計時が停止する）、更に、セッション状態保持部１８に保持されている上記セッションのセッション状態から保留フラグを削除する。もし、データリンク監視部２５が、上記パケット識別子のパケットを検出できなかった場合には、セッション監視タイマ部１７ａに設定されている上記パケットが属するセッションのセッション監視タイマがタイムアウトし、セッション状態保持部１８に保持されているセッションのセッション状態が削除される。【００９５】
本実施例のクラスタメンバでは、上述した処理が行われるので、故障したクラスタメンバの代わりに新たなクラスタメンバを追加した場合、新たなクラスタメンバが予備処理を担当している部分範囲についての現用処理を担当しているクラスタメンバ（ペア現用クラスタメンバ）が保持している上記部分範囲に関するセッション状態と同一のセッション状態を、上記新たなクラスタメンバ上に復元することが可能になる。本実施例では、第１の実施例のように、ペア現用クラスタメンバから新たなクラスタメンバに転送拒否通知を送信する必要がなくなるので、通信コストを更に低減することが可能になる。
【図１】
0004524686.tif 000002
【図２】
0004524686.tif 000003
【図３】
0004524686.tif 000004
【図４】
0004524686.tif 000005
【図５】
0004524686.tif 000006
【図６】
0004524686.tif 000007
【図７】
0004524686.tif 000008
【図８】
0004524686.tif 000009
【図９】
0004524686.tif 000010
【図１０】
0004524686.tif 000011
【図１１】
0004524686.tif 000012
【図１２】
0004524686.tif 000013
【図１３】
0004524686.tif 000014
【図１４】
0004524686.tif 000015
【図１５Ａ】
0004524686.tif 000016
【図１５Ｂ】
0004524686.tif 000017
【図１５Ｃ】
0004524686.tif 000018
【図１６】
0004524686.tif 000019
【図１７】
0004524686.tif 000020
【図１８】
0004524686.tif 000021
【図１９】
0004524686.tif 000022
【図２０】
0004524686.tif 000023