JP4028627B2 - クライアントサーバシステムおよびクライアントサーバシステムの通信管理方法 - Google Patents
クライアントサーバシステムおよびクライアントサーバシステムの通信管理方法 Download PDFInfo
- Publication number
- JP4028627B2 JP4028627B2 JP27898597A JP27898597A JP4028627B2 JP 4028627 B2 JP4028627 B2 JP 4028627B2 JP 27898597 A JP27898597 A JP 27898597A JP 27898597 A JP27898597 A JP 27898597A JP 4028627 B2 JP4028627 B2 JP 4028627B2
- Authority
- JP
- Japan
- Prior art keywords
- server
- lan
- lan interface
- communication link
- physical address
- 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
Landscapes
- Computer And Data Communications (AREA)
- Small-Scale Networks (AREA)
- Maintenance And Management Of Digital Transmission (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、ＬＡＮ（ローカル・エリア・ネットワーク）環境において、ある計算機の通信装置を他の計算機の通信装置で肩代わりする方式に係わるクライアントサーバシステムおよびクライアントサーバシステムの通信管理方法に関する。
【０００２】
【従来の技術】
従来の計算機クラスタ、ホットスタンバイなどの技術では、ある計算機に故障が発生し、処理を継続できなくなった場合、代替の計算機が処理を引き継ぐことが行われている。
【０００３】
クラスタには、さまざまな方式があるが、その一例として、図１１を用いてクラスタ処理の引継ぎを説明する。主系サーバ１０１、並びに待機系サーバ１１０があり、処理引継ぎを行うクラスタ制御ＳＷ（ソフトウェア）が動作している。通常時、各サーバはそれぞれに別の処理を実行する。クラスタ制御ＳＷは、制御用通信リンク１２０を用いて相手が正しく動作しているかどうかを定期的に検査する。
【０００４】
主系サーバ１０１に故障が発生し、主系サーバ１０１のクラスタ制御ＳＷがそれを検知した場合、主系サーバ１０１は処理を停止し、待機系サーバ１１０のクラスタ制御ＳＷに通知する。或いは、待機系サーバ１１０のクラスタ制御ＳＷが定期的に主系サーバ１０１を検査した際に主系サーバ１０１の故障を検知する。上記のいずれに於いても待機系サーバ１１０のクラスタ制御ＳＷは、主系サーバ１０１が処理を停止したことを検知できる。
【０００５】
次に、待機系サーバ１１０は、主系サーバ１０１で実行されていた処理を引き継ぐことを開始する。引き継ぐべき処理は予め定義しておくことが必要である。処理を引き継ぐために必要なことは、以下の２点である。
（１）どの計算機で実行しても、同一の結果が出る環境を整える
例えば、データベースサービスを主系サーバが行っていた場合、待機系サーバでそのサービスを引き継ぐためには、データベースファイルに、主系サーバが処理を停止していても、待機系サーバがアクセスできることが必要になる。
（２）通信先の切り替え
ネットワークを通じて、他の計算機と通信している場合は、相手の計算機にわからないように、通信相手を主系サーバから待機系サーバに切り替える。
【０００６】
上記（１）を実現するための方法が提案されているが、ここでの説明は省略する。ここでは（２）の通信先の切り替えについて説明する。
主系サーバ１０１が他の計算機に提供しているサービスは、ネットワークを通じて、要求やその結果をやりとりする。主系サーバ１０１と通信を行う他の計算機は、主系サーバ１０１に故障が発生し、主系サーバ１０１が処理を停止しても、主系サーバ１０１宛で通信を行い続ける。
【０００７】
これらの通信を待機系サーバ１１０で引き継ぐために、主系サーバ１０１のアドレス宛のパケットを待機系サーバ１１０が受信し、主系サーバ１０１のアドレスからパケットを送信する。ＴＣＰ／ＩＰでは、ＩＰアドレスを複数持つことができるので、この機能を使う。
【０００８】
通常時には、待機系サーバ１１０は自身のＩＰアドレスのみを受信している。主系サーバ１０１が処理を停止した後、待機系サーバ１１０のクラスタ制御ＳＷは、主系サーバ１０１のＩＰアドレスも受信できるようにＴＣＰ／ＩＰソフトウェアに設定をする。これで、主系サーバ１０１のパケットを受信でき、他の計算機は主系サーバ１０１が停止したことによる変更をしなくてよい。
【０００９】
主系サーバ１０１が復帰すれば、待機系サーバ１１０は肩代わりしていたサービスを停止し、通信に関しても主系サーバ１０１のパケットを受信するのを中止する。尚、上記技術として特開平８−２１２０９５が存在する。
【００１０】
【発明が解決しようとする課題】
しかしながら上述従来技術においては、主系サーバのＬＡＮ１２１に対する通信装置に故障があると、待機系サーバ１１０が主系サーバ１０１宛の通信を引き受けるために、待機系サーバ１１０が、主系サーバ１０１のＬＡＮ１２１の物理アドレスではなく、各トランスポート（ＴＣＰ／ＩＰ，ＮＥＴＢＥＵＩなど）毎にある論理アドレスすべてを受信するように変更を通知しなければならないという問題があった。
【００１１】
本発明は上記事情を考慮して成されたもので、上記不具合を解消し、主系サーバのＬＡＮの物理アドレスを待機系サーバが受信可能としたクライアントサーバシステムおよびクライアントサーバシステムの通信管理方法を提供することを目的とする。
【００１２】
【課題を解決するための手段】
上記目的を達成するため、本発明のクライアントサーバシステムは、主系サーバ及び待機系サーバを有してなるクライアントサーバシステムにおいて、前記主系サーバと前記待機系サーバとの間を接続する専用の通信リンクと、前記主系サーバおよび前記待機系サーバとＬＡＮとの間に介在して設けられ、計算機のＬＡＮインタフェースが接続される複数個のポートを有し、各ポート先のＬＡＮインタフェースの物理アドレスを記憶して、ＬＡＮから取り込んだ当該記憶している物理アドレス宛てのパケットを、前記複数個のポートの中の該当のポート先のＬＡＮインタフェースのみに転送するＬＡＮスイッチと、を具備し、前記主系サーバは、自サーバのＬＡＮインタフェースを用いたＬＡＮ経由の通信処理が実行不可能となる故障が発生した場合、自サーバのＬＡＮインタフェースの物理アドレスを前記専用の通信リンクを介して前記待機系サーバに通知すると共に、前記専用の通信リンクを介して前記ＬＡＮ経由の通信処理用のパケットの送受信を代行する旨を前記専用の通信リンクを介して前記待機系サーバに依頼する手段を具備し、前記待機系サーバは、前記専用の通信リンクを介した前記ＬＡＮ経由の通信処理用のパケットの送受信の代行を前記専用の通信リンクを介して前記主系サーバから依頼された場合、前記ＬＡＮからのパケットをすべて受信するモードに自サーバのＬＡＮインタフェースを設定すると共に、前記専用の通信リンクを介して通知された前記主系サーバのＬＡＮインタフェースの物理アドレスを送信元アドレスとするパケットを自サーバのＬＡＮインタフェースを用いて前記ＬＡＮに送出して、前記主系サーバのＬＡＮインタフェースの物理アドレス宛てのパケットを自サーバのＬＡＮインタフェースに転送するように前記ＬＡＮスイッチに学習させる手段を具備する、ことを特徴とする。
【００１３】
また、本発明のクライアントサーバシステムの通信管理方法は、主系サーバと、待機系サーバと、前記主系サーバと前記待機系サーバとの間を接続する専用の通信リンクと、前記主系サーバおよび前記待機系サーバとＬＡＮとの間に介在して設けられ、計算機のＬＡＮインタフェースが接続される複数個のポートを有し、各ポート先のＬＡＮインタフェースの物理アドレスを記憶して、ＬＡＮから取り込んだ当該記憶している物理アドレス宛てのパケットを、前記複数個のポートの中の該当のポート先のＬＡＮインタフェースのみに転送するＬＡＮスイッチとをを有してなるクライアントサーバシステムの通信管理方法であって、前記主系サーバは、自サーバのＬＡＮインタフェースを用いたＬＡＮ経由の通信処理が実行不可能となる故障が発生した場合、自サーバのＬＡＮインタフェースの物理アドレスを前記専用の通信リンクを介して前記待機系サーバに通知すると共に、前記専用の通信リンクを介して前記ＬＡＮ経由の通信処理用のパケットの送受信を代行する旨を前記専用の通信リンクを介して前記待機系サーバに依頼し、前記待機系サーバは、前記専用の通信リンクを介した前記ＬＡＮ経由の通信処理用のパケットの送受信の代行を前記専用の通信リンクを介して前記主系サーバから依頼された場合、前記専用の通信リンクを介して通知された前記主系サーバのＬＡＮインタフェースの物理アドレスを送信元アドレスとするパケットを自サーバのＬＡＮインタフェースを用いて前記ＬＡＮに送出し、前記主系サーバのＬＡＮインタフェースの物理アドレス宛てのパケットを、自サーバのＬＡＮインタフェースに転送するように前記ＬＡＮスイッチに学習させる、ことを特徴とする。
【００２０】
【発明の実施の形態】
以下、図面を参照して本発明の実施形態を説明する。尚、この実施形態では、説明を分かりやすくするために、主系サーバ、待機系サーバと名づけているが、主系サーバと待機系サーバに本質的な違いはなく、それぞれ別の処理を独立に行うことが可能である。
（第一の実施形態）
図１は本発明の実施形態に於けるシステム構成を示すブロック図である。尚、ここでは主系サーバ１の各構成要素を主として説明を行うが、待機系サーバ１０もまったく同様の構成であってよい。
【００２１】
上記各サーバ１，１０に於いて、トランスポート５，１４は、ＬＡＮインタフェース２，１１、並びにＬＡＮドライバ３，１２を介して受け取ったパケットを、サーバプロセス７，１６に渡す役割を果たす。ここでは、説明を分かり易くするためにトランスポートをＴＣＰ／ＩＰとする。
【００２２】
ＬＡＮインタフェース２，１１は、ＬＡＮ２１に対してパケットの送受信を行う装置である。予め指定された物理アドレス宛のパケットがＬＡＮ２１上に発信されると受信を行い、ＬＡＮドライバ３，１２に通知する。また、ＬＡＮドライバ３，１２から渡されたパケットをＬＡＮ２１上に発信する。ここでは、説明を分かり易くするために、ＬＡＮはイーサネットであるとする。
【００２３】
ＬＡＮドライバ３，１２は、ＬＡＮインタフェース２，１１を制御する。ＬＡＮインタフェース２，１１が受信したパケットをトランスポート５，１４が使用できるデータに加工し、トランスポート５，１４、通信管理部４，１３へ渡す。また、トランスポート５，１４より渡されたデータから、ＬＡＮ２１上へ発信するパケットを作成し、ＬＡＮインタフェース２，１１を介してＬＡＮ２１上に発信させる。また、ＬＡＮインタフェース２，１１を使用している際に、その故障を検知し、通信管理部４，１３に通知する。
【００２４】
通信リンク２０は、上記各サーバ１，１０の間の通信を行う専用のリンクである。
サーバプロセス７，１６は、ネットワーク上の他の計算機から利用可能なサービスを提供する。例えば、データベースサービスなどを行う。複数のサーバプロセス７，１６が存在でき、且つ主系サーバ１と待機系サーバ１０でそのサービスの内容が異なってもよい。
【００２５】
クライアント２２は、主系サーバ１、待機系サーバ１０のサービスをＬＡＮを経由して利用する計算機である。クライアントも複数存在することができる。
通信管理部４，１３は、主系サーバ１、待機系サーバ１０の故障の状態を保持し、正常時、故障発生時の処理を制御する。保持する状態としては、両サーバが正常、自サーバに故障発生、他サーバに故障発生、両サーバに故障発生の４つである。故障はさまざまな種類があり、その検出もさまざまであるが、本発明の実施形態においては、ＬＡＮ２１を通じての通信処理のみが行えない場合だけが関係する。従って、ＬＡＮ２１を通じての通信処理のみが行えず、その他の処理がすべて行える場合のみを故障として扱う。
【００２６】
例えば、ＬＡＮインタフェース２が使用不能になったときがこの故障にあたる。ＬＡＮインタフェース２の故障は、ＬＡＮドライバ３がパケットの送受信を行った場合に検知できる。
【００２７】
さらに、クラスタ制御部６が定期的にＬＡＮドライバ３を通じてＬＡＮインタフェース２を検査するなどの方法を取ることもできる。
また、待機系サーバ１０から主系サーバ１へＬＡＮ２１経由でデータを送信し、その内容を検査することで、正しく動作しているかどうかを検査する方法も考えられる。
【００２８】
また、故障からの回復を診断する方法もさまざまである。例えば、故障の発生していない待機系サーバ１０のＬＡＮインタフェース１１からＬＡＮインタフェース２へパケットを送信し、受信できるかどうかを定期的に確認する。或いは主系サーバ１内で故障から回復したかどうかを検査する処理を定期的に行うなどが考えられる。
【００２９】
本発明では、故障発生、回復の検出は、主系サーバ１のハードウェア、或いはＬＡＮドライバ３などのソフトウェアが行い、通信管理部４へ通知を行う、或いは通信管理部４が自身で行うものとする。
【００３０】
図４に通信管理部４の状態変化を示す。通信管理部４は、主系サーバ１（自サーバ）の故障を検出すると、自サーバに故障発生の状態になり、通信リンク２０を通じて待機系サーバ２０の通信管理部１３に通知する。
【００３１】
待機系サーバ２０の通信管理部１３は通知を受けて、他サーバに故障発生の状態となる（ＲＢ）。
また、故障から回復した場合、自身の状態を両サーバ正常にし、故障通知と同様に通信管理部１３に通知する。
【００３２】
通信管理部１３は通知を受け、両サーバ正常の状態に変化する（ＲＡ）。
両サーバとも故障の場合は、後述するように複数のＬＡＮインタフェースを持つ場合のみ可能である。ここでは、説明のためにＬＡＮインタフェースは一つとし、複数の場合は、その違いのみを後述する。従って、両サーバとも故障の場合は、通信を肩代わりできない。
【００３３】
通信管理部４が、本発明の特徴である故障時の通信の切り替えを行う部分である。通信管理部４は、実際のＬＡＮへの通信を制御するＬＡＮドライバと、トランスポートの間に位置し、この間のデータのやり取りを制御する。また、故障時には、通信リンク２０を通じて、通信管理部１３と通信を行う。
【００３４】
通信管理部４は、ＬＡＮドライバ３を通して、ＬＡＮインタフェース２の故障を検知することができる。また、ＬＡＮドライバ３から渡されたＬＡＮからの受信パケットのアドレスを検査することができ、さらには、ＬＡＮドライバ３は渡されたパケットをＬＡＮに送信するだけの機能であるので、送信パケットのアドレスを変更することもできる。
【００３５】
上記通信管理部４の動作処理手順を図５にフローチャートで示す。
ステップ６０及び６２で、故障通知か送信或いは受信処理かを判断する。ステップ６６からは受信処理である。また、他サーバの通信管理部からと自サーバからの通知、データの送受信の両方を処理している。例えばステップ７０で他サーバへデータを送ると、他サーバの通信管理部は、これを送信処理としてステップ６２の処理へ入り、他サーバ故障としてステップ６４，６５の流れを実行する。
【００３６】
次に、通常時、故障時に分けて、通信の方法を説明する。
図２の通常時の通信処理を示す概念図を用いて、通常時の処理を説明する。
通信管理部４、１３ともに両サーバ正常の状態であり、それぞれのサーバは、内蔵するＬＡＮインタフェースを用いて通信を行う。
【００３７】
サーバプロセスが発信するデータは、トランスポート５、通信管理部４、ＬＡＮドライバ３によって処理されて、ＬＡＮインタフェース２を通じＬＡＮ２１へ送信される。ＬＡＮ２１からＬＡＮインタフェース２宛てに到着したパケットは、逆の経路を辿ってサーバプロセス７へ届く。
【００３８】
通信管理部４は、両サーバ正常の状態にあり、送信、受信されるデータをトランスポート５とＬＡＮドライバ３の間で中継するのみである。
次に、図３の故障発生時の通信処理を示す概念図を用いて、主系サーバ１に故障が発生した場合を例にして、故障時の処理を説明する。通信管理部４が故障を検知し、状態を自サーバ故障とする。
【００３９】
次に、故障発生を通信リンク２０を通じて通信管理部１３へ通知する。その通知に、相手に肩代わりしてもらいたい物理アドレスを併せて送信する。通信管理部１３は故障通知を受け取って、他サーバ故障の状態となる。
【００４０】
自サーバ故障の状態となった通信管理部４は、サーバプロセス７等から送られてくるＬＡＮ２１へ送信すべきデータを、通信リンク２０を通して、通信管理部１３へ送る。また、逆に通信管理部１３から送られてきた受信データをサーバプロセス７へ渡す。
【００４１】
他サーバ故障の状態となっている通信管理部１３は、ＬＡＮ２１からＬＡＮインタフェース１１の物理アドレス宛てに到着したパケットや、サーバプロセス１６が出すパケットを通常時と同様に送受信する。障害通知を主系サーバ１から受け取ると、ＬＡＮドライバ１２を使ってＬＡＮインタフェース１１がＬＡＮインタフェース２の物理アドレス宛てのパケットも受信するように設定を変更する。
【００４２】
通信管理部４から通信リンク２０を通じて送られてくるパケットは、ＬＡＮインタフェース２の物理アドレスから送信されたパケットとして、ＬＡＮインタフェース１１から送信する。具体的には、パケットの送信者のアドレスにＬＡＮインタフェース２の物理アドレスが入ったパケットをＬＡＮ２１へ送出する。
【００４３】
ＬＡＮインタフェース１１が受信したＬＡＮインタフェース２宛のパケットは、通信管理部１３において、パケットの宛先を見ることで、主系サーバ１宛てか、待機系サーバ１０宛てかを判断することができる。待機系サーバ１０宛のものは、通常時の処理と同様、そのままトランスポート１４へ渡す。主系サーバ１宛てのものは、通信リンク２０を通じて、通信管理部４へ送信する。
【００４４】
主系サーバ１の故障がなくなり、主系サーバ１が通信を再開できるようになった場合を説明する。
通信管理部４が故障がなくなったことを検知したとする。通信リンク２０を用いて、通信管理部１３へ通知し、両通信管理部とも状態を両サーバ正常の状態とする。
【００４５】
以後のデータ送受信は、図２のようにそれぞれのサーバが、自身のＬＡＮインタフェースを用いて行う状態となる。ＬＡＮインタフェースが複数ある場合でも、対応することが可能である。但し、主系サーバ１が接続しているＬＡＮには、待機系サーバ１０も必ず接続している必要がある。
【００４６】
通信管理部４が、待機系サーバ１０の通信管理部１３へ故障通知を出す際に、どのＬＡＮに接続しているＬＡＮインタフェースが故障したかを示す情報を合わせて送れば、これまで説明した方法で、待機系サーバ１０が主系サーバ１の送受信を肩代わりできる。この場合は、どのＬＡＮと通信が不可能かという情報を保持し動作を決定すればよい。
【００４７】
ＬＡＮインタフェースの種類によっては、ＬＡＮ２１から受信する物理アドレスを１つしか設定できないものがある。上記説明では、主系サーバ１の分と、待機系サーバ１０の分の合わせて２つの物理アドレスが受け取れることが前提となっている。この場合には、待機系サーバ１０のＬＡＮドライバ１２は、ＬＡＮインタフェースを、ＬＡＮ２１に送信されるすべてのパケットを受信するモードに変更する。
【００４８】
ＬＡＮドライバ１２は、受信したパケットをすべて通信管理部１３へ中継する。通信管理部１３は、受信したパケットから待機系サーバ１０宛てのパケットと主系サーバ１宛てのパケットのみを選び出す処理を行うことで、この問題を解決することができる。
【００４９】
上記したように本実施形態によれば、主系サーバ１に障害が発生し、通信処理ができなくなった場合に、待機系サーバ１０のＬＡＮインタフェース１１を通じて通信処理を継続することができる。
【００５０】
また、トランスポートが使用する論理アドレスではなく、ＬＡＮ２１の物理アドレスを肩代わりする形を取るので、ＬＡＮ２１上の他の計算機に通知して、論理アドレスと物理アドレスの組み合わせを変更しなくてよい。
【００５１】
さらに、クライアント２２によっては、その内部に論理アドレスと物理アドレスの組み合わせを静的に保持し、待機系サーバ１０からの通知で変更できない場合がある。この実施形態では、クライアントのこの組み合わせを変更せずに、待機系サーバ１０が主系サーバ１の代わりに受信を行っているので、このようなクライアントがＬＡＮ２１上にあっても対応することが可能である。
（第二の実施形態）
上記した第一の実施形態において、ＬＡＮインタフェースの種類によっては、物理アドレスを１つしか受信できない仕様のものがある。このようなＬＡＮインタフェースを持つ待機系サーバが、第一の実施形態のように主系サーバの物理アドレス宛てのパケットも受信しようとする場合、すでに述べたように、すべてのパケットを受信し、その中から、待機系サーバのＬＡＮインタフェースの物理アドレス宛と、主系サーバのＬＡＮインタフェースの物理アドレス宛てのパケットを選別する処理を通信管理部が行う必要がある。
【００５２】
この場合、ＬＡＮインタフェースはＬＡＮ上のすべてのパケットを受信するために、処理が非常に多くなること、また、待機系サーバの通信管理部も処理が非常に多くなる等の問題がある。
【００５３】
そこで、図６に示すように、一般に使用されているＬＡＮスイッチ３０を使用するシステム構成を第二の実施形態として説明する。尚、図６に於いて上記第一の実施形態と同様な構成要件については図１と同様な符号を付してその説明を省略する。
【００５４】
ＬＡＮスイッチ３０は、ここでは、イーサネットで使用するイーサスイッチとする。イーサスイッチは、計算機のＬＡＮインタフェースが接続する複数のポートを持つ。ポートの先には、一台の計算機だけではなくハブで接続した複数の計算機であってもよい。
【００５５】
イーサスイッチは、ポートから出されるパケットをスキャンし、各ポートに接続されている計算機のＬＡＮインタフェースの物理アドレスを、ポートごとに記憶する。
【００５６】
各ポートに接続されていると記憶した物理アドレス宛のパケットをイーサスイッチが受け取ると、そのポートにのみパケットを送信し、他のパケットには送信しない。
【００５７】
通常のハブなどでは、すべてのポートに必ずパケットを送信するが、上記のように接続されているポートにのみパケットを送信することで、余計なトラフィックを抑えることができる。
【００５８】
通常時、故障時とも、第一の実施形態と同じ動作を行う。但し、通信管理部１３が、主系サーバ１の通信を肩代わりする動作を開始するときに、ＬＡＮ２１に対し、主系サーバ１のＬＡＮインタフェース２の物理アドレスを送信元アドレスとするパケットを、ブロードキャスト、或いはＬＡＮインタフェース１１宛に送信する。
【００５９】
これにより、ＬＡＮスイッチ３０は、ＬＡＮインタフェース２の物理アドレス宛のパケットをＬＡＮインタフェース１１が接続しているポートに送信するように学習する。
【００６０】
上述したように本実施形態によれば，第一の実施形態の効果に加えて、以下の効果がある。すなわち、イーサスイッチが行うパケットのフィルタリングにより、待機系サーバのＬＡＮインタフェースに到着するパケットが少なくなり、障害時の待機系サーバの処理が第一の実施形態の場合より少なくなる。
（第三の実施形態）
前記従来技術で述べたように、論理アドレスを肩代わりする場合に、ＬＡＮ上のクライアント２２に影響を与えることなく、論理アドレスを肩代わりすることができる。
【００６１】
この実施形態を図７乃至図１０を用いて説明する。
この実施形態は、上記した第一の実施形態の構成に加えて、パケットフィルタ４０を加えたシステム構成である。尚、図中、上記第一の実施形態と同様の構成要素については図１と同様の符号を付してその説明を省略する。
【００６２】
まず、図８を参照してパケットフィルタ４０について説明する。
図８に示すように、パケットフィルタ４０は、計算機のＬＡＮインタフェースが接続するポート４１を複数個備え、変換するパケットのアドレスを貯えるアドレス変換表４２と、各ポートから到着するパケットを監視し、アドレスの書き換えをアドレス変換表４２に基づいて行うフィルタ４３とを内部にもつ。
【００６３】
パケットフィルタ４０は、通常のＬＡＮ２１のハブと同様に、ポートから到着したパケットを他のポート全部へ伝達する。その際に、アドレス変換表４２の元アドレス５１に登録されているアドレスを送信先に持つパケットが到着すると、その送信先を新アドレス５２に記録されているものと置き換えて、すべてのポートへ伝達する。また、パケットの送信元アドレスに関しても同様に変換を行う。
【００６４】
パケットフィルタ４０に上記のようなアドレスの置き換えを指示するために、パケットフィルタ４０は、自身を特定する物理アドレスを持つ。
ＬＡＮ２１に接続している計算機が、パケットフィルタ４０を制御するためには、パケットフィルタ４０の物理アドレス宛に、元アドレスと、新アドレスをパケットに格納して送信する。
【００６５】
パケットフィルタ４０は、そのパケットを受信して、アドレス変換表４２に登録する。また、元アドレス（アドレスの値をＡとする）と新アドレスが同じアドレスとなっているデータを含むパケットを受け取ると、アドレス変換表４２の元アドレスがＡのエントリを検索し、エントリがあれば、それを削除する。
【００６６】
尚、パケットフィルタ４０は、上記第二の実施形態で述べたＬＡＮスイッチの機能を合わせ持つ構成であってもよい。
通信管理部４，１３は、通常時は、第一の実施形態と同様に動作する。
【００６７】
次に、故障時を説明する。第一の実施形態と同様、主系サーバ１が故障したとする。故障通知、通信管理部４、１３の状態変化、主系サーバ１の通信管理部４の動作は、第一の実施形態と同様である。
【００６８】
異なるのは、待機系サーバ１０の通信管理部１３が行う、通信の肩代わりの動作と位置である。これを図１０を用いて説明する。
通信管理部４，１３は、トランスポートとサーバプロセスの間に位置する。
【００６９】
通信管理部１３は、通信管理部４から故障通知を受け取ると、トランスポート１４に、主系サーバ１のトランスポート５の論理アドレス（ＴＣＰ／ＩＰではＩＰアドレス）宛てのパケットも受信できるように指示する。
【００７０】
一般に使用されるＴＣＰ／ＩＰなどのトランスポート１４は、複数の論理アドレスを扱うことができるようになっているものが殆どであるので、これには特別な仕組みは必要ない。
【００７１】
通常のトランスポートでは、効率をあげるために、ＬＡＮ上の他のクライアントが、ＬＡＮ上のマシンの論理アドレスと物理アドレスの組を内部にキャッシュしている。
【００７２】
新しい論理アドレスの使用を待機系サーバ１０が開始する場合、特に本実施形態では、すでに主系サーバ１の物理アドレスと組になっていた論理アドレスを引き継ぐために、このキャッシュの破棄が必須となる。これらのキャッシュを破棄するために、ブロードキャストを行ったり、パケットをＬＡＮ上に送信するなどの動作が通常は行われる。
【００７３】
ＬＡＮ上のクライアントが保持しているであろう論理アドレスと物理アドレスの組のキャッシュを更新させるための動作を行わなくてよい。その理由を次に説明する。
【００７４】
通信管理部１３は、次に、パケットフィルタ４０に対して、主系サーバ１のＬＡＮインタフェース２の物理アドレスを元アドレス、待機系サーバ１０のＬＡＮインタフェース１１の物理アドレスを新アドレスとする組のデータを含むパケットを送信する。
【００７５】
パケットフィルタ４０はこのパケットを受信し、上記物理アドレスの組をアドレス変換表４２に記録する。このようにすることで、ＬＡＮインタフェース２宛てのパケットは、ＬＡＮインタフェース１１に、パケットフィルタ４０が届くことを保証することになる。従って、ＬＡＮ上のクライアントは主系サーバ１のＬＡＮインタフェース２宛にパケットを送信し続けるが、実際に受信するのは待機系サーバ１０となる。
【００７６】
ＬＡＮインタフェース１１で受信したパケットは、ＬＡＮドライバ１２、トランスポート１４を通って、通信管理部１３に届く。通信管理部１３は、パケットの宛先の論理アドレスを見て、主系サーバ宛か、待機系サーバ宛かを判断することができ、パケットをそれぞれに振り分ける。
【００７７】
次に、主系サーバ１の故障が直った場合について説明する。この際は上記第一の実施形態と同様に故障が直ったことを検知すると、通信管理部４は、通信管理部１３に通知する。
【００７８】
通信管理部１３は、トランスポート１４に対し、これまで肩代わりしていた主系サーバ１の論理アドレスを扱うことを中止するように、トランスポート１４に通知する。
【００７９】
さらに、パケットフィルタ４０に対し、元アドレス、新アドレスともに主系サーバ１のＬＡＮインタフェース２の物理アドレスであるパケットをパケットフィルタ４０に送信して、パケットのアドレスの変換を停止することを指示する。
【００８０】
これで、パケットフィルタ４０によるパケットの振り替えが中止され、主系サーバ１でパケットが受信できるようになり、待機系サーバ１０では、自身宛てのパケットのみが受信できる状態に戻ることができる。
【００８１】
上述した実施形態によれば、クライアントが保持している論理アドレス、物理アドレスのキャッシュに影響を与えることなく、待機系サーバが主系サーバのパケットを受信することができるようになる。
【００８２】
また、第一及び第二の実施形態で述べたように受信する物理アドレスが１つしか指定できないＬＡＮインタフェースを用いる場合に、すべてのパケットを受信するモードを使用する必要がない。
（第四の実施形態）
上述したすべての実施形態において、主系サーバ１と待機系サーバ１０は、故障時に専用の通信リンク２０を用いて、待機系サーバ１０による通信の代替のためのデータのやり取りを行っていた。
【００８３】
この実施形態では主系サーバ１、並びに待機系サーバ１０が、複数のＬＡＮにつながっており、複数のＬＡＮインタフェースに故障が発生し、通信ができなくなる状況になっても、少なくとも一つは通信できるＬＡＮがあれば、専用の通信リンクの代わりにＬＡＮを用いて、上記の故障通知、データのやり取りを行うことができる。この実施形態によれば、主系サーバと待機系サーバの間に専用の通信リンクが必要ない。
【００８４】
なお。この発明の手法は、ソフトウェアとしての実現が可能であるため、コンピュータによって実行させることのできるプログラムとして、フロッピィディスク、光ディスクおよび半導体メモリなどのコンピュータ読取り可能な記録媒体に格納して頒布することが可能である。そして、この記録媒体の内容を読取ったコンピュータは、その読取ったプログラムを実行制御することによって、前述した処理の実行を実現する。
【００８５】
【発明の効果】
以上詳記したように本発明によれば、トランスポート（ＴＣＰ／ＩＰなど）の論理アドレス（ＩＰアドレス）と、ＬＡＮの物理アドレスの組み合わせを変更するために、ＬＡＮ上の他の計算機に通知を出す必要がない。また、複数のトランスポートを使用していた場合は、それぞれのトランスポートごとに処理が必要であるが、本発明ではＬＡＮの物理アドレスのレベルでパケットの送受信を代替するため、その必要がない。
【００８６】
また、本発明によれば、ＬＡＮスイッチを用いることで、待機系のＬＡＮインタフェースに到着するパケットが少なくなり、待機系サーバとそのＬＡＮインタフェースに対する負荷をより小さくすることができる。
【００８７】
また、本発明によれば、パケットの物理アドレスを変換することができ、且つそれを動的に行うことができる。
さらに、本発明によれば、トランスポートが管理する論理アドレスを肩代わりするがＬＡＮ上の他のクライアントに対し論理アドレスと物理アドレスの組み合わせを変更させずに済むという効果を奏する。
【図面の簡単な説明】
【図１】本発明の第一実施形態に係るシステムの構成を示すブロック図。
【図２】上記実施形態に於ける通常時の通信処理を示す概念図。
【図３】上記実施形態に於ける故障発生時の通信処理を示す概念図。
【図４】上記実施形態に於ける状態遷移図。
【図５】上記実施形態に於ける通信管理部の処理手順を示すフローチャート。
【図６】本発明の第二実施形態に係るＬＡＮスイッチを使用したシステムの構成を示すブロック図。
【図７】本発明の第三実施形態に係るパケットフィルタを用いた構成例を示すブロック図。
【図８】上記実施形態に於けるパケットフィルタの構成を示す図。
【図９】上記実施形態に於けるアドレス変換テーブルの構成を示す図。
【図１０】上記実施形態に於ける故障時の通信処理を示す概念図。
【図１１】従来のシステムによる通信処理を示す概念図。
【符号の説明】
１…主系サーバ、
２…ＬＡＮインタフェース、
３…ＬＡＮドライバ、
４…通信管理部、
５…トランスポート、
６…クラスタ制御部、
７…サーバプロセス、
１０…待機系サーバ、
１１…ＬＡＮインタフェース、
１２…ＬＡＮドライバ、
１３…通信管理部、
１４…トランスポート、
１６…サーバプロセス、
２０…通信リンク、
２１…ＬＡＮ、
２２…クライアント、
３０…ＬＡＮスイッチ、
４０…パケットフィルタ、
４１…ポート、
４２…アドレス変換表、
４３…フィルタ。
【発明の属する技術分野】
本発明は、ＬＡＮ（ローカル・エリア・ネットワーク）環境において、ある計算機の通信装置を他の計算機の通信装置で肩代わりする方式に係わるクライアントサーバシステムおよびクライアントサーバシステムの通信管理方法に関する。
【０００２】
【従来の技術】
従来の計算機クラスタ、ホットスタンバイなどの技術では、ある計算機に故障が発生し、処理を継続できなくなった場合、代替の計算機が処理を引き継ぐことが行われている。
【０００３】
クラスタには、さまざまな方式があるが、その一例として、図１１を用いてクラスタ処理の引継ぎを説明する。主系サーバ１０１、並びに待機系サーバ１１０があり、処理引継ぎを行うクラスタ制御ＳＷ（ソフトウェア）が動作している。通常時、各サーバはそれぞれに別の処理を実行する。クラスタ制御ＳＷは、制御用通信リンク１２０を用いて相手が正しく動作しているかどうかを定期的に検査する。
【０００４】
主系サーバ１０１に故障が発生し、主系サーバ１０１のクラスタ制御ＳＷがそれを検知した場合、主系サーバ１０１は処理を停止し、待機系サーバ１１０のクラスタ制御ＳＷに通知する。或いは、待機系サーバ１１０のクラスタ制御ＳＷが定期的に主系サーバ１０１を検査した際に主系サーバ１０１の故障を検知する。上記のいずれに於いても待機系サーバ１１０のクラスタ制御ＳＷは、主系サーバ１０１が処理を停止したことを検知できる。
【０００５】
次に、待機系サーバ１１０は、主系サーバ１０１で実行されていた処理を引き継ぐことを開始する。引き継ぐべき処理は予め定義しておくことが必要である。処理を引き継ぐために必要なことは、以下の２点である。
（１）どの計算機で実行しても、同一の結果が出る環境を整える
例えば、データベースサービスを主系サーバが行っていた場合、待機系サーバでそのサービスを引き継ぐためには、データベースファイルに、主系サーバが処理を停止していても、待機系サーバがアクセスできることが必要になる。
（２）通信先の切り替え
ネットワークを通じて、他の計算機と通信している場合は、相手の計算機にわからないように、通信相手を主系サーバから待機系サーバに切り替える。
【０００６】
上記（１）を実現するための方法が提案されているが、ここでの説明は省略する。ここでは（２）の通信先の切り替えについて説明する。
主系サーバ１０１が他の計算機に提供しているサービスは、ネットワークを通じて、要求やその結果をやりとりする。主系サーバ１０１と通信を行う他の計算機は、主系サーバ１０１に故障が発生し、主系サーバ１０１が処理を停止しても、主系サーバ１０１宛で通信を行い続ける。
【０００７】
これらの通信を待機系サーバ１１０で引き継ぐために、主系サーバ１０１のアドレス宛のパケットを待機系サーバ１１０が受信し、主系サーバ１０１のアドレスからパケットを送信する。ＴＣＰ／ＩＰでは、ＩＰアドレスを複数持つことができるので、この機能を使う。
【０００８】
通常時には、待機系サーバ１１０は自身のＩＰアドレスのみを受信している。主系サーバ１０１が処理を停止した後、待機系サーバ１１０のクラスタ制御ＳＷは、主系サーバ１０１のＩＰアドレスも受信できるようにＴＣＰ／ＩＰソフトウェアに設定をする。これで、主系サーバ１０１のパケットを受信でき、他の計算機は主系サーバ１０１が停止したことによる変更をしなくてよい。
【０００９】
主系サーバ１０１が復帰すれば、待機系サーバ１１０は肩代わりしていたサービスを停止し、通信に関しても主系サーバ１０１のパケットを受信するのを中止する。尚、上記技術として特開平８−２１２０９５が存在する。
【００１０】
【発明が解決しようとする課題】
しかしながら上述従来技術においては、主系サーバのＬＡＮ１２１に対する通信装置に故障があると、待機系サーバ１１０が主系サーバ１０１宛の通信を引き受けるために、待機系サーバ１１０が、主系サーバ１０１のＬＡＮ１２１の物理アドレスではなく、各トランスポート（ＴＣＰ／ＩＰ，ＮＥＴＢＥＵＩなど）毎にある論理アドレスすべてを受信するように変更を通知しなければならないという問題があった。
【００１１】
本発明は上記事情を考慮して成されたもので、上記不具合を解消し、主系サーバのＬＡＮの物理アドレスを待機系サーバが受信可能としたクライアントサーバシステムおよびクライアントサーバシステムの通信管理方法を提供することを目的とする。
【００１２】
【課題を解決するための手段】
上記目的を達成するため、本発明のクライアントサーバシステムは、主系サーバ及び待機系サーバを有してなるクライアントサーバシステムにおいて、前記主系サーバと前記待機系サーバとの間を接続する専用の通信リンクと、前記主系サーバおよび前記待機系サーバとＬＡＮとの間に介在して設けられ、計算機のＬＡＮインタフェースが接続される複数個のポートを有し、各ポート先のＬＡＮインタフェースの物理アドレスを記憶して、ＬＡＮから取り込んだ当該記憶している物理アドレス宛てのパケットを、前記複数個のポートの中の該当のポート先のＬＡＮインタフェースのみに転送するＬＡＮスイッチと、を具備し、前記主系サーバは、自サーバのＬＡＮインタフェースを用いたＬＡＮ経由の通信処理が実行不可能となる故障が発生した場合、自サーバのＬＡＮインタフェースの物理アドレスを前記専用の通信リンクを介して前記待機系サーバに通知すると共に、前記専用の通信リンクを介して前記ＬＡＮ経由の通信処理用のパケットの送受信を代行する旨を前記専用の通信リンクを介して前記待機系サーバに依頼する手段を具備し、前記待機系サーバは、前記専用の通信リンクを介した前記ＬＡＮ経由の通信処理用のパケットの送受信の代行を前記専用の通信リンクを介して前記主系サーバから依頼された場合、前記ＬＡＮからのパケットをすべて受信するモードに自サーバのＬＡＮインタフェースを設定すると共に、前記専用の通信リンクを介して通知された前記主系サーバのＬＡＮインタフェースの物理アドレスを送信元アドレスとするパケットを自サーバのＬＡＮインタフェースを用いて前記ＬＡＮに送出して、前記主系サーバのＬＡＮインタフェースの物理アドレス宛てのパケットを自サーバのＬＡＮインタフェースに転送するように前記ＬＡＮスイッチに学習させる手段を具備する、ことを特徴とする。
【００１３】
また、本発明のクライアントサーバシステムの通信管理方法は、主系サーバと、待機系サーバと、前記主系サーバと前記待機系サーバとの間を接続する専用の通信リンクと、前記主系サーバおよび前記待機系サーバとＬＡＮとの間に介在して設けられ、計算機のＬＡＮインタフェースが接続される複数個のポートを有し、各ポート先のＬＡＮインタフェースの物理アドレスを記憶して、ＬＡＮから取り込んだ当該記憶している物理アドレス宛てのパケットを、前記複数個のポートの中の該当のポート先のＬＡＮインタフェースのみに転送するＬＡＮスイッチとをを有してなるクライアントサーバシステムの通信管理方法であって、前記主系サーバは、自サーバのＬＡＮインタフェースを用いたＬＡＮ経由の通信処理が実行不可能となる故障が発生した場合、自サーバのＬＡＮインタフェースの物理アドレスを前記専用の通信リンクを介して前記待機系サーバに通知すると共に、前記専用の通信リンクを介して前記ＬＡＮ経由の通信処理用のパケットの送受信を代行する旨を前記専用の通信リンクを介して前記待機系サーバに依頼し、前記待機系サーバは、前記専用の通信リンクを介した前記ＬＡＮ経由の通信処理用のパケットの送受信の代行を前記専用の通信リンクを介して前記主系サーバから依頼された場合、前記専用の通信リンクを介して通知された前記主系サーバのＬＡＮインタフェースの物理アドレスを送信元アドレスとするパケットを自サーバのＬＡＮインタフェースを用いて前記ＬＡＮに送出し、前記主系サーバのＬＡＮインタフェースの物理アドレス宛てのパケットを、自サーバのＬＡＮインタフェースに転送するように前記ＬＡＮスイッチに学習させる、ことを特徴とする。
【００２０】
【発明の実施の形態】
以下、図面を参照して本発明の実施形態を説明する。尚、この実施形態では、説明を分かりやすくするために、主系サーバ、待機系サーバと名づけているが、主系サーバと待機系サーバに本質的な違いはなく、それぞれ別の処理を独立に行うことが可能である。
（第一の実施形態）
図１は本発明の実施形態に於けるシステム構成を示すブロック図である。尚、ここでは主系サーバ１の各構成要素を主として説明を行うが、待機系サーバ１０もまったく同様の構成であってよい。
【００２１】
上記各サーバ１，１０に於いて、トランスポート５，１４は、ＬＡＮインタフェース２，１１、並びにＬＡＮドライバ３，１２を介して受け取ったパケットを、サーバプロセス７，１６に渡す役割を果たす。ここでは、説明を分かり易くするためにトランスポートをＴＣＰ／ＩＰとする。
【００２２】
ＬＡＮインタフェース２，１１は、ＬＡＮ２１に対してパケットの送受信を行う装置である。予め指定された物理アドレス宛のパケットがＬＡＮ２１上に発信されると受信を行い、ＬＡＮドライバ３，１２に通知する。また、ＬＡＮドライバ３，１２から渡されたパケットをＬＡＮ２１上に発信する。ここでは、説明を分かり易くするために、ＬＡＮはイーサネットであるとする。
【００２３】
ＬＡＮドライバ３，１２は、ＬＡＮインタフェース２，１１を制御する。ＬＡＮインタフェース２，１１が受信したパケットをトランスポート５，１４が使用できるデータに加工し、トランスポート５，１４、通信管理部４，１３へ渡す。また、トランスポート５，１４より渡されたデータから、ＬＡＮ２１上へ発信するパケットを作成し、ＬＡＮインタフェース２，１１を介してＬＡＮ２１上に発信させる。また、ＬＡＮインタフェース２，１１を使用している際に、その故障を検知し、通信管理部４，１３に通知する。
【００２４】
通信リンク２０は、上記各サーバ１，１０の間の通信を行う専用のリンクである。
サーバプロセス７，１６は、ネットワーク上の他の計算機から利用可能なサービスを提供する。例えば、データベースサービスなどを行う。複数のサーバプロセス７，１６が存在でき、且つ主系サーバ１と待機系サーバ１０でそのサービスの内容が異なってもよい。
【００２５】
クライアント２２は、主系サーバ１、待機系サーバ１０のサービスをＬＡＮを経由して利用する計算機である。クライアントも複数存在することができる。
通信管理部４，１３は、主系サーバ１、待機系サーバ１０の故障の状態を保持し、正常時、故障発生時の処理を制御する。保持する状態としては、両サーバが正常、自サーバに故障発生、他サーバに故障発生、両サーバに故障発生の４つである。故障はさまざまな種類があり、その検出もさまざまであるが、本発明の実施形態においては、ＬＡＮ２１を通じての通信処理のみが行えない場合だけが関係する。従って、ＬＡＮ２１を通じての通信処理のみが行えず、その他の処理がすべて行える場合のみを故障として扱う。
【００２６】
例えば、ＬＡＮインタフェース２が使用不能になったときがこの故障にあたる。ＬＡＮインタフェース２の故障は、ＬＡＮドライバ３がパケットの送受信を行った場合に検知できる。
【００２７】
さらに、クラスタ制御部６が定期的にＬＡＮドライバ３を通じてＬＡＮインタフェース２を検査するなどの方法を取ることもできる。
また、待機系サーバ１０から主系サーバ１へＬＡＮ２１経由でデータを送信し、その内容を検査することで、正しく動作しているかどうかを検査する方法も考えられる。
【００２８】
また、故障からの回復を診断する方法もさまざまである。例えば、故障の発生していない待機系サーバ１０のＬＡＮインタフェース１１からＬＡＮインタフェース２へパケットを送信し、受信できるかどうかを定期的に確認する。或いは主系サーバ１内で故障から回復したかどうかを検査する処理を定期的に行うなどが考えられる。
【００２９】
本発明では、故障発生、回復の検出は、主系サーバ１のハードウェア、或いはＬＡＮドライバ３などのソフトウェアが行い、通信管理部４へ通知を行う、或いは通信管理部４が自身で行うものとする。
【００３０】
図４に通信管理部４の状態変化を示す。通信管理部４は、主系サーバ１（自サーバ）の故障を検出すると、自サーバに故障発生の状態になり、通信リンク２０を通じて待機系サーバ２０の通信管理部１３に通知する。
【００３１】
待機系サーバ２０の通信管理部１３は通知を受けて、他サーバに故障発生の状態となる（ＲＢ）。
また、故障から回復した場合、自身の状態を両サーバ正常にし、故障通知と同様に通信管理部１３に通知する。
【００３２】
通信管理部１３は通知を受け、両サーバ正常の状態に変化する（ＲＡ）。
両サーバとも故障の場合は、後述するように複数のＬＡＮインタフェースを持つ場合のみ可能である。ここでは、説明のためにＬＡＮインタフェースは一つとし、複数の場合は、その違いのみを後述する。従って、両サーバとも故障の場合は、通信を肩代わりできない。
【００３３】
通信管理部４が、本発明の特徴である故障時の通信の切り替えを行う部分である。通信管理部４は、実際のＬＡＮへの通信を制御するＬＡＮドライバと、トランスポートの間に位置し、この間のデータのやり取りを制御する。また、故障時には、通信リンク２０を通じて、通信管理部１３と通信を行う。
【００３４】
通信管理部４は、ＬＡＮドライバ３を通して、ＬＡＮインタフェース２の故障を検知することができる。また、ＬＡＮドライバ３から渡されたＬＡＮからの受信パケットのアドレスを検査することができ、さらには、ＬＡＮドライバ３は渡されたパケットをＬＡＮに送信するだけの機能であるので、送信パケットのアドレスを変更することもできる。
【００３５】
上記通信管理部４の動作処理手順を図５にフローチャートで示す。
ステップ６０及び６２で、故障通知か送信或いは受信処理かを判断する。ステップ６６からは受信処理である。また、他サーバの通信管理部からと自サーバからの通知、データの送受信の両方を処理している。例えばステップ７０で他サーバへデータを送ると、他サーバの通信管理部は、これを送信処理としてステップ６２の処理へ入り、他サーバ故障としてステップ６４，６５の流れを実行する。
【００３６】
次に、通常時、故障時に分けて、通信の方法を説明する。
図２の通常時の通信処理を示す概念図を用いて、通常時の処理を説明する。
通信管理部４、１３ともに両サーバ正常の状態であり、それぞれのサーバは、内蔵するＬＡＮインタフェースを用いて通信を行う。
【００３７】
サーバプロセスが発信するデータは、トランスポート５、通信管理部４、ＬＡＮドライバ３によって処理されて、ＬＡＮインタフェース２を通じＬＡＮ２１へ送信される。ＬＡＮ２１からＬＡＮインタフェース２宛てに到着したパケットは、逆の経路を辿ってサーバプロセス７へ届く。
【００３８】
通信管理部４は、両サーバ正常の状態にあり、送信、受信されるデータをトランスポート５とＬＡＮドライバ３の間で中継するのみである。
次に、図３の故障発生時の通信処理を示す概念図を用いて、主系サーバ１に故障が発生した場合を例にして、故障時の処理を説明する。通信管理部４が故障を検知し、状態を自サーバ故障とする。
【００３９】
次に、故障発生を通信リンク２０を通じて通信管理部１３へ通知する。その通知に、相手に肩代わりしてもらいたい物理アドレスを併せて送信する。通信管理部１３は故障通知を受け取って、他サーバ故障の状態となる。
【００４０】
自サーバ故障の状態となった通信管理部４は、サーバプロセス７等から送られてくるＬＡＮ２１へ送信すべきデータを、通信リンク２０を通して、通信管理部１３へ送る。また、逆に通信管理部１３から送られてきた受信データをサーバプロセス７へ渡す。
【００４１】
他サーバ故障の状態となっている通信管理部１３は、ＬＡＮ２１からＬＡＮインタフェース１１の物理アドレス宛てに到着したパケットや、サーバプロセス１６が出すパケットを通常時と同様に送受信する。障害通知を主系サーバ１から受け取ると、ＬＡＮドライバ１２を使ってＬＡＮインタフェース１１がＬＡＮインタフェース２の物理アドレス宛てのパケットも受信するように設定を変更する。
【００４２】
通信管理部４から通信リンク２０を通じて送られてくるパケットは、ＬＡＮインタフェース２の物理アドレスから送信されたパケットとして、ＬＡＮインタフェース１１から送信する。具体的には、パケットの送信者のアドレスにＬＡＮインタフェース２の物理アドレスが入ったパケットをＬＡＮ２１へ送出する。
【００４３】
ＬＡＮインタフェース１１が受信したＬＡＮインタフェース２宛のパケットは、通信管理部１３において、パケットの宛先を見ることで、主系サーバ１宛てか、待機系サーバ１０宛てかを判断することができる。待機系サーバ１０宛のものは、通常時の処理と同様、そのままトランスポート１４へ渡す。主系サーバ１宛てのものは、通信リンク２０を通じて、通信管理部４へ送信する。
【００４４】
主系サーバ１の故障がなくなり、主系サーバ１が通信を再開できるようになった場合を説明する。
通信管理部４が故障がなくなったことを検知したとする。通信リンク２０を用いて、通信管理部１３へ通知し、両通信管理部とも状態を両サーバ正常の状態とする。
【００４５】
以後のデータ送受信は、図２のようにそれぞれのサーバが、自身のＬＡＮインタフェースを用いて行う状態となる。ＬＡＮインタフェースが複数ある場合でも、対応することが可能である。但し、主系サーバ１が接続しているＬＡＮには、待機系サーバ１０も必ず接続している必要がある。
【００４６】
通信管理部４が、待機系サーバ１０の通信管理部１３へ故障通知を出す際に、どのＬＡＮに接続しているＬＡＮインタフェースが故障したかを示す情報を合わせて送れば、これまで説明した方法で、待機系サーバ１０が主系サーバ１の送受信を肩代わりできる。この場合は、どのＬＡＮと通信が不可能かという情報を保持し動作を決定すればよい。
【００４７】
ＬＡＮインタフェースの種類によっては、ＬＡＮ２１から受信する物理アドレスを１つしか設定できないものがある。上記説明では、主系サーバ１の分と、待機系サーバ１０の分の合わせて２つの物理アドレスが受け取れることが前提となっている。この場合には、待機系サーバ１０のＬＡＮドライバ１２は、ＬＡＮインタフェースを、ＬＡＮ２１に送信されるすべてのパケットを受信するモードに変更する。
【００４８】
ＬＡＮドライバ１２は、受信したパケットをすべて通信管理部１３へ中継する。通信管理部１３は、受信したパケットから待機系サーバ１０宛てのパケットと主系サーバ１宛てのパケットのみを選び出す処理を行うことで、この問題を解決することができる。
【００４９】
上記したように本実施形態によれば、主系サーバ１に障害が発生し、通信処理ができなくなった場合に、待機系サーバ１０のＬＡＮインタフェース１１を通じて通信処理を継続することができる。
【００５０】
また、トランスポートが使用する論理アドレスではなく、ＬＡＮ２１の物理アドレスを肩代わりする形を取るので、ＬＡＮ２１上の他の計算機に通知して、論理アドレスと物理アドレスの組み合わせを変更しなくてよい。
【００５１】
さらに、クライアント２２によっては、その内部に論理アドレスと物理アドレスの組み合わせを静的に保持し、待機系サーバ１０からの通知で変更できない場合がある。この実施形態では、クライアントのこの組み合わせを変更せずに、待機系サーバ１０が主系サーバ１の代わりに受信を行っているので、このようなクライアントがＬＡＮ２１上にあっても対応することが可能である。
（第二の実施形態）
上記した第一の実施形態において、ＬＡＮインタフェースの種類によっては、物理アドレスを１つしか受信できない仕様のものがある。このようなＬＡＮインタフェースを持つ待機系サーバが、第一の実施形態のように主系サーバの物理アドレス宛てのパケットも受信しようとする場合、すでに述べたように、すべてのパケットを受信し、その中から、待機系サーバのＬＡＮインタフェースの物理アドレス宛と、主系サーバのＬＡＮインタフェースの物理アドレス宛てのパケットを選別する処理を通信管理部が行う必要がある。
【００５２】
この場合、ＬＡＮインタフェースはＬＡＮ上のすべてのパケットを受信するために、処理が非常に多くなること、また、待機系サーバの通信管理部も処理が非常に多くなる等の問題がある。
【００５３】
そこで、図６に示すように、一般に使用されているＬＡＮスイッチ３０を使用するシステム構成を第二の実施形態として説明する。尚、図６に於いて上記第一の実施形態と同様な構成要件については図１と同様な符号を付してその説明を省略する。
【００５４】
ＬＡＮスイッチ３０は、ここでは、イーサネットで使用するイーサスイッチとする。イーサスイッチは、計算機のＬＡＮインタフェースが接続する複数のポートを持つ。ポートの先には、一台の計算機だけではなくハブで接続した複数の計算機であってもよい。
【００５５】
イーサスイッチは、ポートから出されるパケットをスキャンし、各ポートに接続されている計算機のＬＡＮインタフェースの物理アドレスを、ポートごとに記憶する。
【００５６】
各ポートに接続されていると記憶した物理アドレス宛のパケットをイーサスイッチが受け取ると、そのポートにのみパケットを送信し、他のパケットには送信しない。
【００５７】
通常のハブなどでは、すべてのポートに必ずパケットを送信するが、上記のように接続されているポートにのみパケットを送信することで、余計なトラフィックを抑えることができる。
【００５８】
通常時、故障時とも、第一の実施形態と同じ動作を行う。但し、通信管理部１３が、主系サーバ１の通信を肩代わりする動作を開始するときに、ＬＡＮ２１に対し、主系サーバ１のＬＡＮインタフェース２の物理アドレスを送信元アドレスとするパケットを、ブロードキャスト、或いはＬＡＮインタフェース１１宛に送信する。
【００５９】
これにより、ＬＡＮスイッチ３０は、ＬＡＮインタフェース２の物理アドレス宛のパケットをＬＡＮインタフェース１１が接続しているポートに送信するように学習する。
【００６０】
上述したように本実施形態によれば，第一の実施形態の効果に加えて、以下の効果がある。すなわち、イーサスイッチが行うパケットのフィルタリングにより、待機系サーバのＬＡＮインタフェースに到着するパケットが少なくなり、障害時の待機系サーバの処理が第一の実施形態の場合より少なくなる。
（第三の実施形態）
前記従来技術で述べたように、論理アドレスを肩代わりする場合に、ＬＡＮ上のクライアント２２に影響を与えることなく、論理アドレスを肩代わりすることができる。
【００６１】
この実施形態を図７乃至図１０を用いて説明する。
この実施形態は、上記した第一の実施形態の構成に加えて、パケットフィルタ４０を加えたシステム構成である。尚、図中、上記第一の実施形態と同様の構成要素については図１と同様の符号を付してその説明を省略する。
【００６２】
まず、図８を参照してパケットフィルタ４０について説明する。
図８に示すように、パケットフィルタ４０は、計算機のＬＡＮインタフェースが接続するポート４１を複数個備え、変換するパケットのアドレスを貯えるアドレス変換表４２と、各ポートから到着するパケットを監視し、アドレスの書き換えをアドレス変換表４２に基づいて行うフィルタ４３とを内部にもつ。
【００６３】
パケットフィルタ４０は、通常のＬＡＮ２１のハブと同様に、ポートから到着したパケットを他のポート全部へ伝達する。その際に、アドレス変換表４２の元アドレス５１に登録されているアドレスを送信先に持つパケットが到着すると、その送信先を新アドレス５２に記録されているものと置き換えて、すべてのポートへ伝達する。また、パケットの送信元アドレスに関しても同様に変換を行う。
【００６４】
パケットフィルタ４０に上記のようなアドレスの置き換えを指示するために、パケットフィルタ４０は、自身を特定する物理アドレスを持つ。
ＬＡＮ２１に接続している計算機が、パケットフィルタ４０を制御するためには、パケットフィルタ４０の物理アドレス宛に、元アドレスと、新アドレスをパケットに格納して送信する。
【００６５】
パケットフィルタ４０は、そのパケットを受信して、アドレス変換表４２に登録する。また、元アドレス（アドレスの値をＡとする）と新アドレスが同じアドレスとなっているデータを含むパケットを受け取ると、アドレス変換表４２の元アドレスがＡのエントリを検索し、エントリがあれば、それを削除する。
【００６６】
尚、パケットフィルタ４０は、上記第二の実施形態で述べたＬＡＮスイッチの機能を合わせ持つ構成であってもよい。
通信管理部４，１３は、通常時は、第一の実施形態と同様に動作する。
【００６７】
次に、故障時を説明する。第一の実施形態と同様、主系サーバ１が故障したとする。故障通知、通信管理部４、１３の状態変化、主系サーバ１の通信管理部４の動作は、第一の実施形態と同様である。
【００６８】
異なるのは、待機系サーバ１０の通信管理部１３が行う、通信の肩代わりの動作と位置である。これを図１０を用いて説明する。
通信管理部４，１３は、トランスポートとサーバプロセスの間に位置する。
【００６９】
通信管理部１３は、通信管理部４から故障通知を受け取ると、トランスポート１４に、主系サーバ１のトランスポート５の論理アドレス（ＴＣＰ／ＩＰではＩＰアドレス）宛てのパケットも受信できるように指示する。
【００７０】
一般に使用されるＴＣＰ／ＩＰなどのトランスポート１４は、複数の論理アドレスを扱うことができるようになっているものが殆どであるので、これには特別な仕組みは必要ない。
【００７１】
通常のトランスポートでは、効率をあげるために、ＬＡＮ上の他のクライアントが、ＬＡＮ上のマシンの論理アドレスと物理アドレスの組を内部にキャッシュしている。
【００７２】
新しい論理アドレスの使用を待機系サーバ１０が開始する場合、特に本実施形態では、すでに主系サーバ１の物理アドレスと組になっていた論理アドレスを引き継ぐために、このキャッシュの破棄が必須となる。これらのキャッシュを破棄するために、ブロードキャストを行ったり、パケットをＬＡＮ上に送信するなどの動作が通常は行われる。
【００７３】
ＬＡＮ上のクライアントが保持しているであろう論理アドレスと物理アドレスの組のキャッシュを更新させるための動作を行わなくてよい。その理由を次に説明する。
【００７４】
通信管理部１３は、次に、パケットフィルタ４０に対して、主系サーバ１のＬＡＮインタフェース２の物理アドレスを元アドレス、待機系サーバ１０のＬＡＮインタフェース１１の物理アドレスを新アドレスとする組のデータを含むパケットを送信する。
【００７５】
パケットフィルタ４０はこのパケットを受信し、上記物理アドレスの組をアドレス変換表４２に記録する。このようにすることで、ＬＡＮインタフェース２宛てのパケットは、ＬＡＮインタフェース１１に、パケットフィルタ４０が届くことを保証することになる。従って、ＬＡＮ上のクライアントは主系サーバ１のＬＡＮインタフェース２宛にパケットを送信し続けるが、実際に受信するのは待機系サーバ１０となる。
【００７６】
ＬＡＮインタフェース１１で受信したパケットは、ＬＡＮドライバ１２、トランスポート１４を通って、通信管理部１３に届く。通信管理部１３は、パケットの宛先の論理アドレスを見て、主系サーバ宛か、待機系サーバ宛かを判断することができ、パケットをそれぞれに振り分ける。
【００７７】
次に、主系サーバ１の故障が直った場合について説明する。この際は上記第一の実施形態と同様に故障が直ったことを検知すると、通信管理部４は、通信管理部１３に通知する。
【００７８】
通信管理部１３は、トランスポート１４に対し、これまで肩代わりしていた主系サーバ１の論理アドレスを扱うことを中止するように、トランスポート１４に通知する。
【００７９】
さらに、パケットフィルタ４０に対し、元アドレス、新アドレスともに主系サーバ１のＬＡＮインタフェース２の物理アドレスであるパケットをパケットフィルタ４０に送信して、パケットのアドレスの変換を停止することを指示する。
【００８０】
これで、パケットフィルタ４０によるパケットの振り替えが中止され、主系サーバ１でパケットが受信できるようになり、待機系サーバ１０では、自身宛てのパケットのみが受信できる状態に戻ることができる。
【００８１】
上述した実施形態によれば、クライアントが保持している論理アドレス、物理アドレスのキャッシュに影響を与えることなく、待機系サーバが主系サーバのパケットを受信することができるようになる。
【００８２】
また、第一及び第二の実施形態で述べたように受信する物理アドレスが１つしか指定できないＬＡＮインタフェースを用いる場合に、すべてのパケットを受信するモードを使用する必要がない。
（第四の実施形態）
上述したすべての実施形態において、主系サーバ１と待機系サーバ１０は、故障時に専用の通信リンク２０を用いて、待機系サーバ１０による通信の代替のためのデータのやり取りを行っていた。
【００８３】
この実施形態では主系サーバ１、並びに待機系サーバ１０が、複数のＬＡＮにつながっており、複数のＬＡＮインタフェースに故障が発生し、通信ができなくなる状況になっても、少なくとも一つは通信できるＬＡＮがあれば、専用の通信リンクの代わりにＬＡＮを用いて、上記の故障通知、データのやり取りを行うことができる。この実施形態によれば、主系サーバと待機系サーバの間に専用の通信リンクが必要ない。
【００８４】
なお。この発明の手法は、ソフトウェアとしての実現が可能であるため、コンピュータによって実行させることのできるプログラムとして、フロッピィディスク、光ディスクおよび半導体メモリなどのコンピュータ読取り可能な記録媒体に格納して頒布することが可能である。そして、この記録媒体の内容を読取ったコンピュータは、その読取ったプログラムを実行制御することによって、前述した処理の実行を実現する。
【００８５】
【発明の効果】
以上詳記したように本発明によれば、トランスポート（ＴＣＰ／ＩＰなど）の論理アドレス（ＩＰアドレス）と、ＬＡＮの物理アドレスの組み合わせを変更するために、ＬＡＮ上の他の計算機に通知を出す必要がない。また、複数のトランスポートを使用していた場合は、それぞれのトランスポートごとに処理が必要であるが、本発明ではＬＡＮの物理アドレスのレベルでパケットの送受信を代替するため、その必要がない。
【００８６】
また、本発明によれば、ＬＡＮスイッチを用いることで、待機系のＬＡＮインタフェースに到着するパケットが少なくなり、待機系サーバとそのＬＡＮインタフェースに対する負荷をより小さくすることができる。
【００８７】
また、本発明によれば、パケットの物理アドレスを変換することができ、且つそれを動的に行うことができる。
さらに、本発明によれば、トランスポートが管理する論理アドレスを肩代わりするがＬＡＮ上の他のクライアントに対し論理アドレスと物理アドレスの組み合わせを変更させずに済むという効果を奏する。
【図面の簡単な説明】
【図１】本発明の第一実施形態に係るシステムの構成を示すブロック図。
【図２】上記実施形態に於ける通常時の通信処理を示す概念図。
【図３】上記実施形態に於ける故障発生時の通信処理を示す概念図。
【図４】上記実施形態に於ける状態遷移図。
【図５】上記実施形態に於ける通信管理部の処理手順を示すフローチャート。
【図６】本発明の第二実施形態に係るＬＡＮスイッチを使用したシステムの構成を示すブロック図。
【図７】本発明の第三実施形態に係るパケットフィルタを用いた構成例を示すブロック図。
【図８】上記実施形態に於けるパケットフィルタの構成を示す図。
【図９】上記実施形態に於けるアドレス変換テーブルの構成を示す図。
【図１０】上記実施形態に於ける故障時の通信処理を示す概念図。
【図１１】従来のシステムによる通信処理を示す概念図。
【符号の説明】
１…主系サーバ、
２…ＬＡＮインタフェース、
３…ＬＡＮドライバ、
４…通信管理部、
５…トランスポート、
６…クラスタ制御部、
７…サーバプロセス、
１０…待機系サーバ、
１１…ＬＡＮインタフェース、
１２…ＬＡＮドライバ、
１３…通信管理部、
１４…トランスポート、
１６…サーバプロセス、
２０…通信リンク、
２１…ＬＡＮ、
２２…クライアント、
３０…ＬＡＮスイッチ、
４０…パケットフィルタ、
４１…ポート、
４２…アドレス変換表、
４３…フィルタ。
Claims (2)
- 主系サーバ及び待機系サーバを有してなるクライアントサーバシステムにおいて、
前記主系サーバと前記待機系サーバとの間を接続する専用の通信リンクと、
前記主系サーバおよび前記待機系サーバとＬＡＮとの間に介在して設けられ、計算機のＬＡＮインタフェースが接続される複数個のポートを有し、各ポート先のＬＡＮインタフェースの物理アドレスを記憶して、ＬＡＮから取り込んだ当該記憶している物理アドレス宛てのパケットを、前記複数個のポートの中の該当のポート先のＬＡＮインタフェースのみに転送するＬＡＮスイッチと、
を具備し、
前記主系サーバは、
自サーバのＬＡＮインタフェースを用いたＬＡＮ経由の通信処理が実行不可能となる故障が発生した場合、自サーバのＬＡＮインタフェースの物理アドレスを前記専用の通信リンクを介して前記待機系サーバに通知すると共に、前記専用の通信リンクを介して前記ＬＡＮ経由の通信処理用のパケットの送受信を代行する旨を前記専用の通信リンクを介して前記待機系サーバに依頼する手段を具備し、
前記待機系サーバは、
前記専用の通信リンクを介した前記ＬＡＮ経由の通信処理用のパケットの送受信の代行を前記専用の通信リンクを介して前記主系サーバから依頼された場合、前記ＬＡＮからのパケットをすべて受信するモードに自サーバのＬＡＮインタフェースを設定すると共に、前記専用の通信リンクを介して通知された前記主系サーバのＬＡＮインタフェースの物理アドレスを送信元アドレスとするパケットを自サーバのＬＡＮインタフェースを用いて前記ＬＡＮに送出して、前記主系サーバのＬＡＮインタフェースの物理アドレス宛てのパケットを自サーバのＬＡＮインタフェースに転送するように前記ＬＡＮスイッチに学習させる手段を具備する、
ことを特徴とするクライアントサーバシステム。 - 主系サーバと、待機系サーバと、前記主系サーバと前記待機系サーバとの間を接続する専用の通信リンクと、前記主系サーバおよび前記待機系サーバとＬＡＮとの間に介在して設けられ、計算機のＬＡＮインタフェースが接続される複数個のポートを有し、各ポート先のＬＡＮインタフェースの物理アドレスを記憶して、ＬＡＮから取り込んだ当該記憶している物理アドレス宛てのパケットを、前記複数個のポートの中の該当のポート先のＬＡＮインタフェースのみに転送するＬＡＮスイッチとをを有してなるクライアントサーバシステムの通信管理方法であって、
前記主系サーバは、
自サーバのＬＡＮインタフェースを用いたＬＡＮ経由の通信処理が実行不可能となる故障が発生した場合、自サーバのＬＡＮインタフェースの物理アドレスを前記専用の通信リンクを介して前記待機系サーバに通知すると共に、前記専用の通信リンクを介して前記ＬＡＮ経由の通信処理用のパケットの送受信を代行する旨を前記専用の通信リンクを介して前記待機系サーバに依頼し、
前記待機系サーバは、
前記専用の通信リンクを介した前記ＬＡＮ経由の通信処理用のパケットの送受信の代行を前記専用の通信リンクを介して前記主系サーバから依頼された場合、前記ＬＡＮからのパケットをすべて受信するモードに自サーバのＬＡＮインタフェースを設定すると共に、前記専用の通信リンクを介して通知された前記主系サーバのＬＡＮインタフェースの物理アドレスを送信元アドレスとするパケットを自サーバのＬＡＮインタフェースを用いて前記ＬＡＮに送出して、前記主系サーバのＬＡＮインタフェースの物理アドレス宛てのパケットを、自サーバのＬＡＮインタフェースに転送するように前記ＬＡＮスイッチに学習させる、
ことを特徴とするクライアントサーバシステムの通信管理方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP27898597A JP4028627B2 (ja) | 1996-12-02 | 1997-10-13 | クライアントサーバシステムおよびクライアントサーバシステムの通信管理方法 |
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP8-321743 | 1996-12-02 | ||
| JP32174396 | 1996-12-02 | ||
| JP27898597A JP4028627B2 (ja) | 1996-12-02 | 1997-10-13 | クライアントサーバシステムおよびクライアントサーバシステムの通信管理方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH10224378A JPH10224378A (ja) | 1998-08-21 |
| JP4028627B2 true JP4028627B2 (ja) | 2007-12-26 |
Family
ID=26553127
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP27898597A Expired - Fee Related JP4028627B2 (ja) | 1996-12-02 | 1997-10-13 | クライアントサーバシステムおよびクライアントサーバシステムの通信管理方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4028627B2 (ja) |
Families Citing this family (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP3111935B2 (ja) | 1997-08-15 | 2000-11-27 | 日本電気株式会社 | Ｌａｎエミュレーションサーバ二重化方式 |
| WO2000079397A1 (en) * | 1999-06-23 | 2000-12-28 | Fujitsu Limited | Network protocol controller and network protocol controlling method, and recorded medium on which network protocol controlling program is recorded |
| US6865157B1 (en) * | 2000-05-26 | 2005-03-08 | Emc Corporation | Fault tolerant shared system resource with communications passthrough providing high availability communications |
| JP4747758B2 (ja) * | 2005-09-21 | 2011-08-17 | 日立電線株式会社 | ネットワーク装置 |
| JP4768558B2 (ja) * | 2006-09-19 | 2011-09-07 | 株式会社東芝 | ネットワーク監視方法および監視装置 |
-
1997
- 1997-10-13 JP JP27898597A patent/JP4028627B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JPH10224378A (ja) | 1998-08-21 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6208616B1 (en) | System for detecting errors in a network | |
| US6597700B2 (en) | System, device, and method for address management in a distributed communication environment | |
| CN1954559B (zh) | 网络节点群集的冗余路由能力 | |
| US6760859B1 (en) | Fault tolerant local area network connectivity | |
| US6052733A (en) | Method of detecting errors in a network | |
| US5781715A (en) | Fault-tolerant bridge/router with a distributed switch-over mechanism | |
| US6938092B2 (en) | TCP offload device that load balances and fails-over between aggregated ports having different MAC addresses | |
| US6134678A (en) | Method of detecting network errors | |
| US7518983B2 (en) | Proxy response apparatus | |
| US6105151A (en) | System for detecting network errors | |
| US20060256801A1 (en) | Gateway system | |
| US6594776B1 (en) | Mechanism to clear MAC address from Ethernet switch address table to enable network link fail-over across two network segments | |
| JP2004519024A (ja) | 多数のノードを含むクラスタを管理するためのシステム及び方法 | |
| JP2004032224A (ja) | サーバ引継システムおよびその方法 | |
| US20060206611A1 (en) | Method and system for managing programs with network address | |
| US20030101275A1 (en) | Information processing system accessed through network and control method of packet transfer load | |
| WO1998049620A1 (en) | Redundant server failover in networked environment | |
| JPH09259096A (ja) | ネットワーク高信頼化方式及びシステム | |
| JP4028627B2 (ja) | クライアントサーバシステムおよびクライアントサーバシステムの通信管理方法 | |
| JP2008283608A (ja) | 冗長化された通信経路を切り替える計算機、プログラム及び方法 | |
| JPH09293059A (ja) | 分散システム及びその運用管理方法 | |
| JP4133738B2 (ja) | 高速ネットワークアドレス引継ぎ方法、ネットワーク装置及びプログラム | |
| AU2001249114B2 (en) | Non-fault tolerant network nodes in a multiple fault tolerant network | |
| JP2007133542A (ja) | 情報引継ぎシステム、情報引継ぎ方法、現用系ノード及び待機系ノード | |
| AU2001249114A1 (en) | Non-fault tolerant network nodes in a multiple fault tolerant network |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20041013 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20070129 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070206 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070409 |
|
| 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: 20071009 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20071012 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101019 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101019 Year of fee payment: 3 |
|
| LAPS | Cancellation because of no payment of annual fees |