JP4087271B2 - 代理応答装置およびネットワークシステム - Google Patents
代理応答装置およびネットワークシステム Download PDFInfo
- Publication number
- JP4087271B2 JP4087271B2 JP2003074803A JP2003074803A JP4087271B2 JP 4087271 B2 JP4087271 B2 JP 4087271B2 JP 2003074803 A JP2003074803 A JP 2003074803A JP 2003074803 A JP2003074803 A JP 2003074803A JP 4087271 B2 JP4087271 B2 JP 4087271B2
- Authority
- JP
- Japan
- Prior art keywords
- server
- client
- packet
- response
- servers
- 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
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
- G06F11/2035—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant without idle spare hardware
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
- G06F11/2023—Failover techniques
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer And Data Communications (AREA)
- Hardware Redundancy (AREA)
- Multi Processors (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、経済的なスケーラビリティとシステムの高可用性を可能とするクライアントサーバ型のシステムに関する。
【０００２】
【従来の技術】
計算機とネットワークの発達により、クライアントがサーバにメッセージを送信しサーバが処理結果をクライアントにメッセージとして応答するクライアントサーバ型のシステムの適用範囲が広がり、上記システムの可用性(availability)の向上が益々重要になってきた。併せて、システムコストを最小にするため、クライアントの要求量に応じてサーバの処理能力を増減できる経済的なスケーラビリティが求められている。
【０００３】
クライアントサーバ型システムの可用性を向上させる方法には、特許文献１等に記載されるマスタスレーブ方式がある。上記方式は例えば、クライアント、複数のサーバa、bがIP網などの通信ネットワークで接続される。各サーバa、bは、クライアントからの要求に応答するのに必要な情報を共有し、さらに互いに障害発生を検知できる同期部を持つ。
【０００４】
上記方式では、クライアントの要求に応答するサーバaと予備となるサーバbを用意し、サーバaに障害が発生した際には、サーバbは上記障害を検知しサーバaの代わりにクライアントに対して応答する。さらに、クライアントとサーバa、bは、送信先が確実にメッセージを受信するまでメッセージを保持する。これにより、上記方式では、サーバa、bの２つが同時に障害を起こさない限り、クライアントの要求に応答できる。
【０００５】
上記方式はサーバaに対し必ず予備のサーバbが必要になるので経済的なスケーラビリティを持つとは言えないが、さらに、予備のサーバ台数を軽減する方式として、特許文献２に記載される技術が考案されている。
【０００６】
別の可用性向上方式として、クラスタ方式がある。この方式は例えば、クライアント、サーバa、b、負荷分散装置a、bがIP網で接続される構成を備える。この方式でのサーバa、bは、同期部を持たない。負荷分散装置a、bは、互いに障害発生を検知し、障害発生時には代わりに処理を続行できる機能と、サーバa、bの障害発生を検知する機能と、クライアントからのメッセージを障害の発生していないサーバに中継する機能と、サーバからのメッセージをクライアントに中継する機能を持つ。上記方式においてサーバaに障害が発生した場合、負荷分散装置は、それ以降のクライアントからのメッセージを、障害の発生していないサーバbに中継する。さらに、クライアントとサーバa、bは、送信先が確実にメッセージを受信するまでメッセージを保持し、受信が失敗した場合にはメッセージを再送する。上記例では、サーバa、bの２台だけであるが、３台以上でも構わない。これにより、上記方式では、サーバa、bが同時にすべて障害を起こさない限り、クライアントの要求に応答できる。
【０００７】
上記方式は、サーバ台数を増減させることでシステムの処理能力を増減でき、経済的なスケーラビリティを持つ。
【０００８】
【特許文献１】
特開平11-68837号公報
【特許文献２】
特開平5-316116号公報
【０００９】
【発明が解決しようとする課題】
クラスタ方式は、経済的なスケーラビリティを持ち、サーバに障害が発生した際も、障害発生後のクライアントの要求に対しては応答できるだけの可用性を持つ。
【００１０】
しかし、上記方式では、サーバに障害が発生する前にサーバが受信完了していたクライアントの要求に対しては、サーバの障害により上記要求のメッセージが失われるので応答できないという点で可用性に欠ける。特許文献２に記載の技術も同様の課題を持つ。
【００１１】
【課題を解決するための手段】
本発明は、クラスタ方式のシステムに可用性を与える代理応答装置を提供する。
【００１２】
本発明の代理応答装置は、障害発生を監視する監視対象サーバと上記監視対象サーバの代りに応答できる予備サーバのアドレスを保持し、上記監視対象サーバが送受信するメッセージを通信ネットワークから取得する手段と、上記監視対象サーバの障害を検知する手段と、上記監視対象サーバの障害を検知した際には、上記取得したクライアントからの要求のメッセージのうち応答していないメッセージについて、送信元アドレスを上記代理応答装置のアドレスに書き換え、上記予備サーバに送信する手段を有し、上記予備サーバからの応答メッセージの送信元アドレスを上記監視対象サーバのアドレスに書き換えクライアントに中継する手段を有する。
【００１３】
これにより、サーバa、bを監視対象サーバとし、互いに予備のサーバと設定すると、例えばサーバaが受信した後に障害が発生した際、失われるはずのクライアントの要求メッセージは、予め代理応答装置が通信ネットワークから取得しているので、上記メッセージを代理応答装置が予備のサーバに送信し、その応答をクライアントに中継することで、クライアントの要求に応答できる。
【００１４】
【発明の実施の形態】
以下、本発明の実施例について図面を参照して説明する。
【００１５】
図１は、本実施例の代理応答装置を適用したネットワークシステムの概略構成を示す。
【００１６】
クライアント端末(以下、クライアントと言う)3は、インターネットなどの通信ネットワーク(以下IP網という)6aを介して負荷分散装置4a、4bと接続されている。負荷分散装置4aは、サーバ装置(以下、サーバという)2a、2bと、代理応答装置1とIP網6bを介して接続されている。負荷分散装置4bは、負荷分散装置4aの予備であり、負荷分散装置4aに障害が発生した際に、負荷分散装置4aに代り処理を続行する。
【００１７】
クライアント3とサーバ2a、2bでやりとりされるメッセージは、IPパケットを用いて送受信する。この際、メッセージは、必要に応じて複数のIPパケットに分割して送受信される。クライアント3から送信されたIPパケットは、IP網6aを介し、負荷分散装置4aに届く。負荷分散装置4aは、上記クライアント3からの上記IPパケットを、サーバの負荷に応じてサーバ2a又はサーバ2bのいずれかに振分ける。さらに、負荷分散装置4aは、同一のメッセージを構成する複数のIPパケットを同一のサーバに振分ける機能を持つ。なお、サーバは、３台以上でも構わない。
【００１８】
代理応答装置1は、IP網6bに接続され、IP網6bに流れるすべてのIPパケットを取得できる。
【００１９】
図２は、代理応答装置1を実現する情報処理装置のハードウェア構成を示す。代理応答装置1を実現する情報処理装置は、プロセッサ100と、記憶装置108と、IP網6bに接続するための入力回路インタフェイス105および出力回路インタフェイス107と、入力回路インタフェイス105で受信されたIPパケットを一時的に蓄積するための受信バッファ104と、出力回路インタフェイス107で送信すべきIPパケットを一時的に蓄積するための送信バッファ106と、これらを接続するバスなどの内部通信線からなる。記憶装置108は、プログラムメモリ101と、パケットバッファ102と、サーバ管理表103を格納している。プログラムメモリ101には、プロセッサ100が実行し、代理応答装置1を実現する各種制御プログラムが記録され、パケットバッファ102には、クライアント3とサーバ2a、2bがやりとりするIPパケットが蓄積される。記憶装置108は、半導体記憶装置、または、ハードディスクなどの外部記憶装置で構成する。
【００２０】
なお、上記各プログラムは、予め記憶装置108に格納されていてもよいし、図示していない着脱可能な記憶媒体または通信媒体（すなわちネットワークまたはそれを伝搬する搬送波）を介して、上記記憶装置108に導入されてもよい。
【００２１】
上記代理応答装置1は、システム管理者によるデータ入力を可能にするための入力装置と表示装置を備えているが、これらの装置は以下の説明では使用しないため、図2では省略してある。
【００２２】
代理応答装置1は、クライアント3とサーバ2a、2bでやりとりされるメッセージを管理するためのパケットバッファ102を備え、クライアント3が送信した要求のメッセージとそれに対応するサーバ2a、2bの応答のメッセージをまとめて一つの単位（以下、セッションと呼ぶ）として管理する。セッションは、パケットバッファ102のセッション管理エントリ110-1、110-2、・・・に登録される。
【００２３】
図３に、パケットバッファ102の一構成例を示す。
【００２４】
パケットバッファ102の各エントリは、セッション識別子111、クライアントアドレス112、サーバアドレス113、クライアント送信パケットバッファ114、サーバ送信パケットバッファ115とからなる。
【００２５】
セッション識別子111には、各エントリを識別するために、一意な識別子を与えられる。クライアントアドレス112には、要求を送信したクライアント3のIPアドレスが設定される。サーバアドレス113には、上記要求を受信したサーバ2aのIPアドレスが設定される。クライアント送信パケットバッファ114には、クライアント3がサーバ2aに送信したすべてのIPパケットがそのまま格納される。サーバ送信パケットバッファ115には、サーバ2aがクライアント3に送信したすべてのIPパケットがそのまま格納される。
【００２６】
図４に、代理応答装置1が備えるサーバ管理表103の一構成例を示す。サーバ管理表103は、代理応答装置1が監視すべきサーバのIPアドレスと、上記サーバに障害が発生した際に代わりに処理が可能な予備のサーバのIPアドレスを管理するためのものである。サーバ管理表103の各エントリ120-1、120-2、・・・は、監視対象サーバアドレス121、予備サーバアドレス122とからなっている。
【００２７】
図５は、代理応答装置1が扱うIPパケットの概略である。IPパケットは、送信元アドレス150、送信先アドレス151、パケット番号152、パケット種別153、パケットデータ154とからなる。例えば、クライアント3からサーバ2aに送信されたIPパケットの場合、送信元アドレス150にはクライアント3のIPアドレス、送信先アドレス151にはサーバ2aのIPアドレスが設定される。パケット番号152には、送信した最初のIPパケットには1が、その後2、3、・・・と、送信した順番を示す数値が設定される。パケット種別153には、IPパケットの種類が設定される。IPパケットの種類には、接続要求、データ送信、切断要求、受信応答がある。パケットデータ154は、送信したいデータが格納される。
【００２８】
図６は、クライアント3がサーバ2aに要求のメッセージを送信し、サーバ2aが上記メッセージに対する応答のメッセージを応答するセッションにおける、メッセージフローの一例を示した図である。それぞれの矢印はメッセージを構成する一つのIPパケットの送信を示している。
【００２９】
クライアント3は、要求のメッセージの送信に先立ち、接続要求130aをサーバ2aに送信する。サーバ2aは、接続要求130aを受信したことを示す受信応答をクライアント3に送信する。以下、受信応答133-1a、133-2a、135-1a、135-2a、137aは、同様にそれぞれ処理要求132-1a、132-2a、処理結果134-1a、134-2a、切断要求136aに対応する。受信応答を構成するパケットのパケット種別153には「受信応答」が設定されており、パケット番号152にどのパケットを受信したかを示すため上記パケットのパケット番号が設定されている。
【００３０】
続いて、クライアント3は、要求のメッセージを、一つ以上、例えば２つのIPパケット（処理要求132-1a、132-2aとする）によりサーバ2aに送信する。
【００３１】
サーバ2aは、上記要求のメッセージに対応する応答のメッセージを、一つ以上、例えば２つのIPパケット（処理結果134-1a、134-2aとする）によりクライアント3に送信する。なお、上記処理要求132-1a、132-2a、処理結果134-1a、134-2aは、説明の都合上「処理要求」と「処理結果」と呼んでいるが、IPパケットのパケット種別153は、両方ともデータ送信である。
【００３２】
続いて、サーバ2aが、切断要求136aをクライアント3に送信すると、一つのセッションが正常に終了する。クライアント3が切断要求を送信しても良い。
【００３３】
この際、クライアント3およびサーバ2aは、送信したIPパケットに対する受信応答を受信するまで、当該IPパケットを保持し、受信応答が送信されてこない場合には、上記IPパケットを再送する。これにより、クライアント3とサーバ2a間のIP網および負荷分散装置に一時的な障害が発生しても障害復帰後に、正しくIPパケットの送受信が行われる。
【００３４】
代理応答装置1の動作を説明する。代理応答装置1は、サーバ2aに障害が発生した際に、サーバ2aに代わって応答することで、図６で示したフローを正しく終了させる。
【００３５】
図７は、代理応答装置1の動作を例示するフローチャートであり、プロセッサ100の動作として説明する。
【００３６】
代理応答装置1が接続するIP網6bに流れるすべてのIPパケットが、入力回路インタフェイス105により取得され、受信バッファ104に格納される。
【００３７】
プロセッサ100は、受信バッファ104に上記IPパケットがあれば、一つ取得し（ステップ170）、
取得したIPパケットが監視対象のサーバ2aに関係するか否かを、上記IPパケットの送信元アドレス150または送信先アドレス151が、サーバ管理表103の監視対象サーバアドレス121に一致しているかで判定する。もし、ステップ170で受信バッファ104からIPパケットを取得しなかった場合は、ステップ175に進む（ステップ171）。
【００３８】
一致している場合プロセッサ100は、上記IPパケットのパケット種別153が切断要求か判定し（ステップ172）、
切断要求でないなら上記IPパケットをパケットバッファ102の該当するエントリに格納する（ステップ173）。該当するエントリは、上記IPパケットの送信元アドレス150と送信先アドレス151の組が、クライアントアドレス112とサーバアドレス113の組と一致するか（順不同でも一致と見なす）で判定する。格納先は、上記IPパケットの送信先がサーバならクライアント送信パケットバッファ114に、上記IPパケットの送信元がサーバならサーバ送信パケットバッファ115となる。この際、該当するエントリが無い場合には、新しくエントリを作成する。
【００３９】
ステップ172にてパケット種別153が切断要求の場合には、該当するエントリを削除する（ステップ174）。
【００４０】
プロセッサ100は、サーバ管理表103の各エントリの監視対象サーバアドレス121を持つサーバの障害の有無を判定し（ステップ175）、
障害が発生している場合には、代理応答処理を実行する（ステップ177）。サーバの障害の有無の判定方法は、特に限定されないが、一例としては、パケットバッファ102に格納されたすべてのセッションを監視し、サーバから一定時間応答が無いセッションを見つけたら上記サーバに障害が発生したと判定する。他の例としては、サーバで、代理応答装置1に障害がないことを意味するメッセージを送信し続けるプログラムを実行させ、代理応答装置1が上記メッセージを受信できなくなったときに、上記サーバに障害が発生したと判定する。
【００４１】
あるセッションにおいて、最初に代理応答処理を行う場合は、受信している全てのIPパケットを用いて、障害発生までの処理を実行し、同じ状態を再現する。
【００４２】
また、ステップ177は一つのIPパケット毎に実行され、実行後は、ステップ170に戻る。
【００４３】
上述の代理応答処理（ステップ177）の動作の一実施例について図８を用いて詳細に説明する。図8の処理も一つのIPパケット毎に実行され、実行後は、図7のステップ170に戻る。
【００４４】
以下では、クライアント3が、接続要求130a、処理要求132-1a、132-2aをサーバ2aに送信する段階でサーバ2aに障害が発生した場合の第一の障害例と、サーバ2aが、処理結果134-1a、134-2a、切断要求136aをクライアント3に送信する段階でサーバ2aに障害が発生した場合の第二の障害例、とに分け、それぞれの場合における代理応答装置1の動作を説明する。この二つ障害例をあわせると、すべての場合を網羅する。
【００４５】
図９は、第一の障害例のクライアント3、サーバ2a、代理応答装置1、予備のサーバ2bのメッセージフローを示す。代理応答装置1は、クライアント3とサーバ2a間のすべてのIPパケットを受信している。
【００４６】
第一の障害例は、処理要求132-1aをクライアント3が送信した後に、160aにてサーバ2aに障害が発生し応答できない状況である。
【００４７】
プロセッサ100は、図7のステップ170パケットバッファ102の各エントリのサーバアドレス113と、障害が発生したサーバ2aのIPアドレスとを比較し、代理応答すべきセッションを探し（ステップ180）、
上記セッションがある場合には、上記サーバ2aの予備のサーバ2bのアドレスをサーバ管理表103の予備サーバアドレス122から取得し、また、代理応答装置1が受信している、クライアント3とサーバ2a間のIPパケットを参照して、図9の接続要求130b、受信応答131bに示されるように、予備のサーバ2bに接続する（ステップ181）。
【００４８】
ステップ180で、代理応答すべきセッションがない場合、すなわち、障害発生時に代理応答すべきセッションはすべて代理応答処理をしたがまだ障害が回復していない場合は、ステップ177の処理を終了する。
【００４９】
既にサーバ2bに接続している場合には、ステップ181は行わない。
【００５０】
プロセッサ100は、代理応答の対象となるセッションのクライアント送信パケットバッファ114に格納されているすべてのIPパケットに対し、対応する受信応答のIPパケットがサーバ送信パケットバッファ115に存在するか調べる（ステップ182）。
【００５１】
第一の障害例では、処理要求132-1aに対応する受信応答が無いので、上記処理要求132-1aに対応する受信応答133-1aを生成しクライアント3に送信する（ステップ183）。
【００５２】
この際、クライアント3にはサーバ2aに障害が発生していないようにみせるため、受信応答のIPパケットの送信元アドレス151を、サーバ2aのIPアドレスに設定する。代理応答装置1は、処理要求132-2aに対する受信応答133-2aも同様に処理する。
【００５３】
ステップ182において、受信応答のIPパケットの欠落がない場合は、プロセッサ100は、上記セッションのクライアント送信パケットバッファ114に処理要求のメッセージのIPパケットがあるか判定し（ステップ184）、
上記IPパケットがある場合には、上記IPパケットをサーバ2bに送信し、上記IPパケットをクライアント送信パケットバッファ114から削除する（ステップ185）。この際、上記IPパケットの送信元アドレス150と送信先アドレス151は、それぞれ代理応答装置1とサーバ2bのIPアドレスに書換える。この処理は、図9のメッセージフローの処理要求132-1b、132-2bに示される。
【００５４】
サーバ2bには、クライアント3から送信されるのと同等の要求が代理応答装置1から送信されるので、クライアント3から要求されたのと同等の応答を代理応答装置1に行う。この処理は、図9のメッセージフローの受信応答133-1b、133-2bに示される。
【００５５】
ステップ184において、処理要求のメッセージのIPパケットが無い場合は、プロセッサ100は、予備サーバ2bから送信されたIPパケットを判定し、（ステップ186）、
予備サーバが応答したIPパケットが処理結果134-1b、134-2bまたは切断要求136bである場合には、サーバ2bに受信応答パケット133-1b、133-2b、または137bを送信する（ステップ187）。
【００５６】
プロセッサ100は、上記処理結果のIPパケットが既にクライアント3に送信済みか判定するため、サーバ送信パケットバッファ115に格納されているすべてのIPパケットと上記IPパケットのパケット番号152を比較し（ステップ188）、
一致しなかった場合には上記IPパケットが切断要求か判定し（ステップ189）、
切断要求でない場合（処理結果134-1b、134-2bであった場合）には、上記IPパケットをクライアント3に代理応答する（ステップ190）。代理応答する際には、上記IPパケットの送信元アドレス150と送信先アドレス151をそれぞれサーバ2aとクライアント3のIPアドレスに書換え、処理結果134-1a、134-2aとして送信する。
【００５７】
ステップ188で一致した場合は、さらに上記二つのIPパケットのパケットデータ154も一致するか比較し（ステップ191）、一致する場合には、何もしない。
【００５８】
ステップ189で判定した上記IPパケットが切断要求136bの場合には、クライアント3に送信元アドレス150がサーバ2aのIPアドレスである切断要求136aを送信し、パケットバッファ102の上記セッションのエントリを削除する（ステップ192）。
【００５９】
また、ステップ191で比較したパケットデータ154が一致しなかった場合は、例外的なケースではあるが、予備サーバ2bは、サーバ2aと異なる応答と返していることになる。サーバ2bはサーバ2aの予備となりえないのでセッションを終了させ代理応答処理を終了する。さらに、サーバ2bと接続中である場合には、サーバ2bにも切断要求を送信する（ステップ192）。
【００６０】
以上の説明からわかるように、プロセッサ100は、サーバ2aに発生した障害が続く間は、ステップ180以降の処理を実行し、ステップ182、184、186の判定で状況に応じた処理を実行する。
【００６１】
以上の処理により、代理応答装置1は、クライアント3にサーバ2aが応答すべきIPパケットをすべて代理応答したことになる。
【００６２】
第二の障害例では、処理結果134-1aをサーバ2aが送信した後に、160bにてサーバ2aに障害が発生し応答できない状況である。
【００６３】
まず、説明で用いる各パケットの関係について説明する。クライアント3の要求メッセージのIPパケット132-1a、132-2aと、代理要求で使われるIPパケット132-1b、132-2bとは、それぞれパケットデータ154が同一という関係にある。
【００６４】
サーバ2aからの応答メッセージであるIPパケット134-1aと、サーバ2bからの応答メッセージであるIPパケット134-1bとは、パケットデータ154が同一という関係にある。
【００６５】
図１０において、代理応答装置1は、受信しているクライアント3とサーバ2a間のIPパケットを参照して、サーバ2bからの応答メッセージであるIPパケット134-1bを受信する処理までを再現する。
【００６６】
ステップ180〜187、IPパケット130a〜132-2bに関しては、正常なメッセージフロー又は第一の障害例と同様であるので、図１０の処理結果134-1bを受信した場合の動作から説明する。
【００６７】
プロセッサ100は、サーバ2bからの処理結果134-1bを受信すると、既にクライアント3に送信済みか判定する（ステップ188）。
【００６８】
第二の障害例では、処理結果134-1bは、既にクライアント3にサーバ2aが処理結果134-1aで送付しているので、パケット番号が処理結果134-1bと同一の処理結果134-1aが、サーバ送信パケットバッファ115に存在する。この場合プロセッサ100は、上記二つのIPパケットのパケットデータ154も一致するか比較し（ステップ191）、一致する場合には、何もしない。
【００６９】
プロセッサ100は、サーバ2bから処理結果134-2bを受信すると、このパケットはサーバ送信パケットバッファ115に存在しないので、第一の障害例と同様の処理を行う。
【００７０】
以下、第一の障害例と処理は同様であり、第二の障害例でも、代理応答装置1は、クライアント3にサーバ2aが応答すべきIPパケットをすべて代理応答できることになる。
【００７１】
最後に、図1に示したシステム全体の動作を、通常状態から障害発生、代理応答、障害復旧を経て通常状態に戻る一連のサイクルについて、図面を用いて説明する。
【００７２】
図11は、上記サイクルでのメッセージフローを示している。それぞれの矢印は、図６、９、１０とは異なり、複数のIPパケットからなる一つの要求または応答メッセージを示している。
【００７３】
通常状態では、クライアント3a、3bから送られた要求のメッセージ140、142は、負荷分散装置4aに送られた後、サーバの負荷が同じになるようにサーバ2aまたはサーバ2bに送られる。上記要求に対する応答141、応答142は、サーバ2a、サーバ2bから負荷分散装置4aを経由してクライアント3a、3bに送られる。
【００７４】
ここで、要求144aがサーバ2aに送られた直後にサーバ2aで障害160が発生したとする。
【００７５】
上述のように、一つの矢印は、順序性があるIPパケットではなく、独立したメッセージを示しているので、クライアント3aは、要求144aに対する応答がなくても要求145を要求することがある。
【００７６】
負荷分散装置4aは、161で障害を検知すると、つづくクライアント3aからの要求145を障害が発生していないサーバ2bに送る。要求145に対する応答146は、サーバ2bから負荷分散装置4aを経由してクライアント3aに送られる。
【００７７】
代理応答装置1は、162で障害を検知すると、障害発生160のために、サーバ2aがクライアント3aに応答を返していない要求144aについて、要求144aと同一の内容の要求144bをクライアント3aの代わりにサーバ2bに送り、サーバ2aに成りすまして応答147をクライアント3aに送信する。
【００７８】
障害が発生している間は、負荷分散装置4aは、クライアント3bの次の要求148も、サーバ2bに送り、その応答149をクライアント3bに送信する。このため、負荷分散ができないものの、クライアント3a、3bの要求は確実に処理されることになる。
【００７９】
上記負荷分散装置4aの処理と代理応答装置1の処理とは、並行して、あるいは、任意の順番で行われてもよい。
【００８０】
このように、代理応答装置1は、負荷分散装置4aが障害発生を検知して、クライアントの要求を処理するサーバを2aから2bに切り替えるまでの間、サーバ2aが応答していないすべての要求について、同様の処理を行う。
【００８１】
その後、163でサーバ2aの障害が復旧すると、負荷分散装置4aと代理応答装置1は、164、165で復旧を検知し、再び通常の処理に戻る。以降のメッセージ150〜153は、メッセージ141〜143と同様に正常に行われ、負荷も分散される。
【００８２】
【発明の効果】
本発明によれば、可用性とスケーラビリティとを兼ね備えるクラスタ方式のクライアントサーバ型のシステムを提供できる。
【図面の簡単な説明】
【図１】実施例の代理応答装置1を用いたネットワークシステムの一構成図。
【図２】代理応答装置1の構成を示す図。
【図３】代理応答装置1が備えるパケットバッファ102の１実施例を示す図。
【図４】代理応答装置1が備えるサーバ管理表103の１実施例を示す図。
【図５】クライアントとサーバ間で送受信されるパケットフォーマットの１例を示す図。
【図６】クライアント3とサーバ2a間で正常にIPパケットが送受信される場合のメッセージフローを示す図。
【図７】代理応答装置1で実行される処理の一実施例を示すフローチャートの主要部を示す図。
【図８】代理応答装置1で実行される代理応答処理177の１実施例を示すフローチャートの主要部を示す図。
【図９】クライアント3とサーバ2a間で発生した第一の障害例のメッセージフローを示す図。
【図１０】クライアント3とサーバ2a間で発生した第二の障害例のメッセージフローを示す図
【図１１】障害発生から復旧までの代理応答装置1を適用したネットワークシステム内のメッセージフローを示す図。
【符号の説明】
1…代理応答装置、2…サーバ、3…クライアント、4…負荷分散装置、6…ネットワーク、101…プログラム、102…パケットバッファ、103…サーバ管理表。
【発明の属する技術分野】
本発明は、経済的なスケーラビリティとシステムの高可用性を可能とするクライアントサーバ型のシステムに関する。
【０００２】
【従来の技術】
計算機とネットワークの発達により、クライアントがサーバにメッセージを送信しサーバが処理結果をクライアントにメッセージとして応答するクライアントサーバ型のシステムの適用範囲が広がり、上記システムの可用性(availability)の向上が益々重要になってきた。併せて、システムコストを最小にするため、クライアントの要求量に応じてサーバの処理能力を増減できる経済的なスケーラビリティが求められている。
【０００３】
クライアントサーバ型システムの可用性を向上させる方法には、特許文献１等に記載されるマスタスレーブ方式がある。上記方式は例えば、クライアント、複数のサーバa、bがIP網などの通信ネットワークで接続される。各サーバa、bは、クライアントからの要求に応答するのに必要な情報を共有し、さらに互いに障害発生を検知できる同期部を持つ。
【０００４】
上記方式では、クライアントの要求に応答するサーバaと予備となるサーバbを用意し、サーバaに障害が発生した際には、サーバbは上記障害を検知しサーバaの代わりにクライアントに対して応答する。さらに、クライアントとサーバa、bは、送信先が確実にメッセージを受信するまでメッセージを保持する。これにより、上記方式では、サーバa、bの２つが同時に障害を起こさない限り、クライアントの要求に応答できる。
【０００５】
上記方式はサーバaに対し必ず予備のサーバbが必要になるので経済的なスケーラビリティを持つとは言えないが、さらに、予備のサーバ台数を軽減する方式として、特許文献２に記載される技術が考案されている。
【０００６】
別の可用性向上方式として、クラスタ方式がある。この方式は例えば、クライアント、サーバa、b、負荷分散装置a、bがIP網で接続される構成を備える。この方式でのサーバa、bは、同期部を持たない。負荷分散装置a、bは、互いに障害発生を検知し、障害発生時には代わりに処理を続行できる機能と、サーバa、bの障害発生を検知する機能と、クライアントからのメッセージを障害の発生していないサーバに中継する機能と、サーバからのメッセージをクライアントに中継する機能を持つ。上記方式においてサーバaに障害が発生した場合、負荷分散装置は、それ以降のクライアントからのメッセージを、障害の発生していないサーバbに中継する。さらに、クライアントとサーバa、bは、送信先が確実にメッセージを受信するまでメッセージを保持し、受信が失敗した場合にはメッセージを再送する。上記例では、サーバa、bの２台だけであるが、３台以上でも構わない。これにより、上記方式では、サーバa、bが同時にすべて障害を起こさない限り、クライアントの要求に応答できる。
【０００７】
上記方式は、サーバ台数を増減させることでシステムの処理能力を増減でき、経済的なスケーラビリティを持つ。
【０００８】
【特許文献１】
特開平11-68837号公報
【特許文献２】
特開平5-316116号公報
【０００９】
【発明が解決しようとする課題】
クラスタ方式は、経済的なスケーラビリティを持ち、サーバに障害が発生した際も、障害発生後のクライアントの要求に対しては応答できるだけの可用性を持つ。
【００１０】
しかし、上記方式では、サーバに障害が発生する前にサーバが受信完了していたクライアントの要求に対しては、サーバの障害により上記要求のメッセージが失われるので応答できないという点で可用性に欠ける。特許文献２に記載の技術も同様の課題を持つ。
【００１１】
【課題を解決するための手段】
本発明は、クラスタ方式のシステムに可用性を与える代理応答装置を提供する。
【００１２】
本発明の代理応答装置は、障害発生を監視する監視対象サーバと上記監視対象サーバの代りに応答できる予備サーバのアドレスを保持し、上記監視対象サーバが送受信するメッセージを通信ネットワークから取得する手段と、上記監視対象サーバの障害を検知する手段と、上記監視対象サーバの障害を検知した際には、上記取得したクライアントからの要求のメッセージのうち応答していないメッセージについて、送信元アドレスを上記代理応答装置のアドレスに書き換え、上記予備サーバに送信する手段を有し、上記予備サーバからの応答メッセージの送信元アドレスを上記監視対象サーバのアドレスに書き換えクライアントに中継する手段を有する。
【００１３】
これにより、サーバa、bを監視対象サーバとし、互いに予備のサーバと設定すると、例えばサーバaが受信した後に障害が発生した際、失われるはずのクライアントの要求メッセージは、予め代理応答装置が通信ネットワークから取得しているので、上記メッセージを代理応答装置が予備のサーバに送信し、その応答をクライアントに中継することで、クライアントの要求に応答できる。
【００１４】
【発明の実施の形態】
以下、本発明の実施例について図面を参照して説明する。
【００１５】
図１は、本実施例の代理応答装置を適用したネットワークシステムの概略構成を示す。
【００１６】
クライアント端末(以下、クライアントと言う)3は、インターネットなどの通信ネットワーク(以下IP網という)6aを介して負荷分散装置4a、4bと接続されている。負荷分散装置4aは、サーバ装置(以下、サーバという)2a、2bと、代理応答装置1とIP網6bを介して接続されている。負荷分散装置4bは、負荷分散装置4aの予備であり、負荷分散装置4aに障害が発生した際に、負荷分散装置4aに代り処理を続行する。
【００１７】
クライアント3とサーバ2a、2bでやりとりされるメッセージは、IPパケットを用いて送受信する。この際、メッセージは、必要に応じて複数のIPパケットに分割して送受信される。クライアント3から送信されたIPパケットは、IP網6aを介し、負荷分散装置4aに届く。負荷分散装置4aは、上記クライアント3からの上記IPパケットを、サーバの負荷に応じてサーバ2a又はサーバ2bのいずれかに振分ける。さらに、負荷分散装置4aは、同一のメッセージを構成する複数のIPパケットを同一のサーバに振分ける機能を持つ。なお、サーバは、３台以上でも構わない。
【００１８】
代理応答装置1は、IP網6bに接続され、IP網6bに流れるすべてのIPパケットを取得できる。
【００１９】
図２は、代理応答装置1を実現する情報処理装置のハードウェア構成を示す。代理応答装置1を実現する情報処理装置は、プロセッサ100と、記憶装置108と、IP網6bに接続するための入力回路インタフェイス105および出力回路インタフェイス107と、入力回路インタフェイス105で受信されたIPパケットを一時的に蓄積するための受信バッファ104と、出力回路インタフェイス107で送信すべきIPパケットを一時的に蓄積するための送信バッファ106と、これらを接続するバスなどの内部通信線からなる。記憶装置108は、プログラムメモリ101と、パケットバッファ102と、サーバ管理表103を格納している。プログラムメモリ101には、プロセッサ100が実行し、代理応答装置1を実現する各種制御プログラムが記録され、パケットバッファ102には、クライアント3とサーバ2a、2bがやりとりするIPパケットが蓄積される。記憶装置108は、半導体記憶装置、または、ハードディスクなどの外部記憶装置で構成する。
【００２０】
なお、上記各プログラムは、予め記憶装置108に格納されていてもよいし、図示していない着脱可能な記憶媒体または通信媒体（すなわちネットワークまたはそれを伝搬する搬送波）を介して、上記記憶装置108に導入されてもよい。
【００２１】
上記代理応答装置1は、システム管理者によるデータ入力を可能にするための入力装置と表示装置を備えているが、これらの装置は以下の説明では使用しないため、図2では省略してある。
【００２２】
代理応答装置1は、クライアント3とサーバ2a、2bでやりとりされるメッセージを管理するためのパケットバッファ102を備え、クライアント3が送信した要求のメッセージとそれに対応するサーバ2a、2bの応答のメッセージをまとめて一つの単位（以下、セッションと呼ぶ）として管理する。セッションは、パケットバッファ102のセッション管理エントリ110-1、110-2、・・・に登録される。
【００２３】
図３に、パケットバッファ102の一構成例を示す。
【００２４】
パケットバッファ102の各エントリは、セッション識別子111、クライアントアドレス112、サーバアドレス113、クライアント送信パケットバッファ114、サーバ送信パケットバッファ115とからなる。
【００２５】
セッション識別子111には、各エントリを識別するために、一意な識別子を与えられる。クライアントアドレス112には、要求を送信したクライアント3のIPアドレスが設定される。サーバアドレス113には、上記要求を受信したサーバ2aのIPアドレスが設定される。クライアント送信パケットバッファ114には、クライアント3がサーバ2aに送信したすべてのIPパケットがそのまま格納される。サーバ送信パケットバッファ115には、サーバ2aがクライアント3に送信したすべてのIPパケットがそのまま格納される。
【００２６】
図４に、代理応答装置1が備えるサーバ管理表103の一構成例を示す。サーバ管理表103は、代理応答装置1が監視すべきサーバのIPアドレスと、上記サーバに障害が発生した際に代わりに処理が可能な予備のサーバのIPアドレスを管理するためのものである。サーバ管理表103の各エントリ120-1、120-2、・・・は、監視対象サーバアドレス121、予備サーバアドレス122とからなっている。
【００２７】
図５は、代理応答装置1が扱うIPパケットの概略である。IPパケットは、送信元アドレス150、送信先アドレス151、パケット番号152、パケット種別153、パケットデータ154とからなる。例えば、クライアント3からサーバ2aに送信されたIPパケットの場合、送信元アドレス150にはクライアント3のIPアドレス、送信先アドレス151にはサーバ2aのIPアドレスが設定される。パケット番号152には、送信した最初のIPパケットには1が、その後2、3、・・・と、送信した順番を示す数値が設定される。パケット種別153には、IPパケットの種類が設定される。IPパケットの種類には、接続要求、データ送信、切断要求、受信応答がある。パケットデータ154は、送信したいデータが格納される。
【００２８】
図６は、クライアント3がサーバ2aに要求のメッセージを送信し、サーバ2aが上記メッセージに対する応答のメッセージを応答するセッションにおける、メッセージフローの一例を示した図である。それぞれの矢印はメッセージを構成する一つのIPパケットの送信を示している。
【００２９】
クライアント3は、要求のメッセージの送信に先立ち、接続要求130aをサーバ2aに送信する。サーバ2aは、接続要求130aを受信したことを示す受信応答をクライアント3に送信する。以下、受信応答133-1a、133-2a、135-1a、135-2a、137aは、同様にそれぞれ処理要求132-1a、132-2a、処理結果134-1a、134-2a、切断要求136aに対応する。受信応答を構成するパケットのパケット種別153には「受信応答」が設定されており、パケット番号152にどのパケットを受信したかを示すため上記パケットのパケット番号が設定されている。
【００３０】
続いて、クライアント3は、要求のメッセージを、一つ以上、例えば２つのIPパケット（処理要求132-1a、132-2aとする）によりサーバ2aに送信する。
【００３１】
サーバ2aは、上記要求のメッセージに対応する応答のメッセージを、一つ以上、例えば２つのIPパケット（処理結果134-1a、134-2aとする）によりクライアント3に送信する。なお、上記処理要求132-1a、132-2a、処理結果134-1a、134-2aは、説明の都合上「処理要求」と「処理結果」と呼んでいるが、IPパケットのパケット種別153は、両方ともデータ送信である。
【００３２】
続いて、サーバ2aが、切断要求136aをクライアント3に送信すると、一つのセッションが正常に終了する。クライアント3が切断要求を送信しても良い。
【００３３】
この際、クライアント3およびサーバ2aは、送信したIPパケットに対する受信応答を受信するまで、当該IPパケットを保持し、受信応答が送信されてこない場合には、上記IPパケットを再送する。これにより、クライアント3とサーバ2a間のIP網および負荷分散装置に一時的な障害が発生しても障害復帰後に、正しくIPパケットの送受信が行われる。
【００３４】
代理応答装置1の動作を説明する。代理応答装置1は、サーバ2aに障害が発生した際に、サーバ2aに代わって応答することで、図６で示したフローを正しく終了させる。
【００３５】
図７は、代理応答装置1の動作を例示するフローチャートであり、プロセッサ100の動作として説明する。
【００３６】
代理応答装置1が接続するIP網6bに流れるすべてのIPパケットが、入力回路インタフェイス105により取得され、受信バッファ104に格納される。
【００３７】
プロセッサ100は、受信バッファ104に上記IPパケットがあれば、一つ取得し（ステップ170）、
取得したIPパケットが監視対象のサーバ2aに関係するか否かを、上記IPパケットの送信元アドレス150または送信先アドレス151が、サーバ管理表103の監視対象サーバアドレス121に一致しているかで判定する。もし、ステップ170で受信バッファ104からIPパケットを取得しなかった場合は、ステップ175に進む（ステップ171）。
【００３８】
一致している場合プロセッサ100は、上記IPパケットのパケット種別153が切断要求か判定し（ステップ172）、
切断要求でないなら上記IPパケットをパケットバッファ102の該当するエントリに格納する（ステップ173）。該当するエントリは、上記IPパケットの送信元アドレス150と送信先アドレス151の組が、クライアントアドレス112とサーバアドレス113の組と一致するか（順不同でも一致と見なす）で判定する。格納先は、上記IPパケットの送信先がサーバならクライアント送信パケットバッファ114に、上記IPパケットの送信元がサーバならサーバ送信パケットバッファ115となる。この際、該当するエントリが無い場合には、新しくエントリを作成する。
【００３９】
ステップ172にてパケット種別153が切断要求の場合には、該当するエントリを削除する（ステップ174）。
【００４０】
プロセッサ100は、サーバ管理表103の各エントリの監視対象サーバアドレス121を持つサーバの障害の有無を判定し（ステップ175）、
障害が発生している場合には、代理応答処理を実行する（ステップ177）。サーバの障害の有無の判定方法は、特に限定されないが、一例としては、パケットバッファ102に格納されたすべてのセッションを監視し、サーバから一定時間応答が無いセッションを見つけたら上記サーバに障害が発生したと判定する。他の例としては、サーバで、代理応答装置1に障害がないことを意味するメッセージを送信し続けるプログラムを実行させ、代理応答装置1が上記メッセージを受信できなくなったときに、上記サーバに障害が発生したと判定する。
【００４１】
あるセッションにおいて、最初に代理応答処理を行う場合は、受信している全てのIPパケットを用いて、障害発生までの処理を実行し、同じ状態を再現する。
【００４２】
また、ステップ177は一つのIPパケット毎に実行され、実行後は、ステップ170に戻る。
【００４３】
上述の代理応答処理（ステップ177）の動作の一実施例について図８を用いて詳細に説明する。図8の処理も一つのIPパケット毎に実行され、実行後は、図7のステップ170に戻る。
【００４４】
以下では、クライアント3が、接続要求130a、処理要求132-1a、132-2aをサーバ2aに送信する段階でサーバ2aに障害が発生した場合の第一の障害例と、サーバ2aが、処理結果134-1a、134-2a、切断要求136aをクライアント3に送信する段階でサーバ2aに障害が発生した場合の第二の障害例、とに分け、それぞれの場合における代理応答装置1の動作を説明する。この二つ障害例をあわせると、すべての場合を網羅する。
【００４５】
図９は、第一の障害例のクライアント3、サーバ2a、代理応答装置1、予備のサーバ2bのメッセージフローを示す。代理応答装置1は、クライアント3とサーバ2a間のすべてのIPパケットを受信している。
【００４６】
第一の障害例は、処理要求132-1aをクライアント3が送信した後に、160aにてサーバ2aに障害が発生し応答できない状況である。
【００４７】
プロセッサ100は、図7のステップ170パケットバッファ102の各エントリのサーバアドレス113と、障害が発生したサーバ2aのIPアドレスとを比較し、代理応答すべきセッションを探し（ステップ180）、
上記セッションがある場合には、上記サーバ2aの予備のサーバ2bのアドレスをサーバ管理表103の予備サーバアドレス122から取得し、また、代理応答装置1が受信している、クライアント3とサーバ2a間のIPパケットを参照して、図9の接続要求130b、受信応答131bに示されるように、予備のサーバ2bに接続する（ステップ181）。
【００４８】
ステップ180で、代理応答すべきセッションがない場合、すなわち、障害発生時に代理応答すべきセッションはすべて代理応答処理をしたがまだ障害が回復していない場合は、ステップ177の処理を終了する。
【００４９】
既にサーバ2bに接続している場合には、ステップ181は行わない。
【００５０】
プロセッサ100は、代理応答の対象となるセッションのクライアント送信パケットバッファ114に格納されているすべてのIPパケットに対し、対応する受信応答のIPパケットがサーバ送信パケットバッファ115に存在するか調べる（ステップ182）。
【００５１】
第一の障害例では、処理要求132-1aに対応する受信応答が無いので、上記処理要求132-1aに対応する受信応答133-1aを生成しクライアント3に送信する（ステップ183）。
【００５２】
この際、クライアント3にはサーバ2aに障害が発生していないようにみせるため、受信応答のIPパケットの送信元アドレス151を、サーバ2aのIPアドレスに設定する。代理応答装置1は、処理要求132-2aに対する受信応答133-2aも同様に処理する。
【００５３】
ステップ182において、受信応答のIPパケットの欠落がない場合は、プロセッサ100は、上記セッションのクライアント送信パケットバッファ114に処理要求のメッセージのIPパケットがあるか判定し（ステップ184）、
上記IPパケットがある場合には、上記IPパケットをサーバ2bに送信し、上記IPパケットをクライアント送信パケットバッファ114から削除する（ステップ185）。この際、上記IPパケットの送信元アドレス150と送信先アドレス151は、それぞれ代理応答装置1とサーバ2bのIPアドレスに書換える。この処理は、図9のメッセージフローの処理要求132-1b、132-2bに示される。
【００５４】
サーバ2bには、クライアント3から送信されるのと同等の要求が代理応答装置1から送信されるので、クライアント3から要求されたのと同等の応答を代理応答装置1に行う。この処理は、図9のメッセージフローの受信応答133-1b、133-2bに示される。
【００５５】
ステップ184において、処理要求のメッセージのIPパケットが無い場合は、プロセッサ100は、予備サーバ2bから送信されたIPパケットを判定し、（ステップ186）、
予備サーバが応答したIPパケットが処理結果134-1b、134-2bまたは切断要求136bである場合には、サーバ2bに受信応答パケット133-1b、133-2b、または137bを送信する（ステップ187）。
【００５６】
プロセッサ100は、上記処理結果のIPパケットが既にクライアント3に送信済みか判定するため、サーバ送信パケットバッファ115に格納されているすべてのIPパケットと上記IPパケットのパケット番号152を比較し（ステップ188）、
一致しなかった場合には上記IPパケットが切断要求か判定し（ステップ189）、
切断要求でない場合（処理結果134-1b、134-2bであった場合）には、上記IPパケットをクライアント3に代理応答する（ステップ190）。代理応答する際には、上記IPパケットの送信元アドレス150と送信先アドレス151をそれぞれサーバ2aとクライアント3のIPアドレスに書換え、処理結果134-1a、134-2aとして送信する。
【００５７】
ステップ188で一致した場合は、さらに上記二つのIPパケットのパケットデータ154も一致するか比較し（ステップ191）、一致する場合には、何もしない。
【００５８】
ステップ189で判定した上記IPパケットが切断要求136bの場合には、クライアント3に送信元アドレス150がサーバ2aのIPアドレスである切断要求136aを送信し、パケットバッファ102の上記セッションのエントリを削除する（ステップ192）。
【００５９】
また、ステップ191で比較したパケットデータ154が一致しなかった場合は、例外的なケースではあるが、予備サーバ2bは、サーバ2aと異なる応答と返していることになる。サーバ2bはサーバ2aの予備となりえないのでセッションを終了させ代理応答処理を終了する。さらに、サーバ2bと接続中である場合には、サーバ2bにも切断要求を送信する（ステップ192）。
【００６０】
以上の説明からわかるように、プロセッサ100は、サーバ2aに発生した障害が続く間は、ステップ180以降の処理を実行し、ステップ182、184、186の判定で状況に応じた処理を実行する。
【００６１】
以上の処理により、代理応答装置1は、クライアント3にサーバ2aが応答すべきIPパケットをすべて代理応答したことになる。
【００６２】
第二の障害例では、処理結果134-1aをサーバ2aが送信した後に、160bにてサーバ2aに障害が発生し応答できない状況である。
【００６３】
まず、説明で用いる各パケットの関係について説明する。クライアント3の要求メッセージのIPパケット132-1a、132-2aと、代理要求で使われるIPパケット132-1b、132-2bとは、それぞれパケットデータ154が同一という関係にある。
【００６４】
サーバ2aからの応答メッセージであるIPパケット134-1aと、サーバ2bからの応答メッセージであるIPパケット134-1bとは、パケットデータ154が同一という関係にある。
【００６５】
図１０において、代理応答装置1は、受信しているクライアント3とサーバ2a間のIPパケットを参照して、サーバ2bからの応答メッセージであるIPパケット134-1bを受信する処理までを再現する。
【００６６】
ステップ180〜187、IPパケット130a〜132-2bに関しては、正常なメッセージフロー又は第一の障害例と同様であるので、図１０の処理結果134-1bを受信した場合の動作から説明する。
【００６７】
プロセッサ100は、サーバ2bからの処理結果134-1bを受信すると、既にクライアント3に送信済みか判定する（ステップ188）。
【００６８】
第二の障害例では、処理結果134-1bは、既にクライアント3にサーバ2aが処理結果134-1aで送付しているので、パケット番号が処理結果134-1bと同一の処理結果134-1aが、サーバ送信パケットバッファ115に存在する。この場合プロセッサ100は、上記二つのIPパケットのパケットデータ154も一致するか比較し（ステップ191）、一致する場合には、何もしない。
【００６９】
プロセッサ100は、サーバ2bから処理結果134-2bを受信すると、このパケットはサーバ送信パケットバッファ115に存在しないので、第一の障害例と同様の処理を行う。
【００７０】
以下、第一の障害例と処理は同様であり、第二の障害例でも、代理応答装置1は、クライアント3にサーバ2aが応答すべきIPパケットをすべて代理応答できることになる。
【００７１】
最後に、図1に示したシステム全体の動作を、通常状態から障害発生、代理応答、障害復旧を経て通常状態に戻る一連のサイクルについて、図面を用いて説明する。
【００７２】
図11は、上記サイクルでのメッセージフローを示している。それぞれの矢印は、図６、９、１０とは異なり、複数のIPパケットからなる一つの要求または応答メッセージを示している。
【００７３】
通常状態では、クライアント3a、3bから送られた要求のメッセージ140、142は、負荷分散装置4aに送られた後、サーバの負荷が同じになるようにサーバ2aまたはサーバ2bに送られる。上記要求に対する応答141、応答142は、サーバ2a、サーバ2bから負荷分散装置4aを経由してクライアント3a、3bに送られる。
【００７４】
ここで、要求144aがサーバ2aに送られた直後にサーバ2aで障害160が発生したとする。
【００７５】
上述のように、一つの矢印は、順序性があるIPパケットではなく、独立したメッセージを示しているので、クライアント3aは、要求144aに対する応答がなくても要求145を要求することがある。
【００７６】
負荷分散装置4aは、161で障害を検知すると、つづくクライアント3aからの要求145を障害が発生していないサーバ2bに送る。要求145に対する応答146は、サーバ2bから負荷分散装置4aを経由してクライアント3aに送られる。
【００７７】
代理応答装置1は、162で障害を検知すると、障害発生160のために、サーバ2aがクライアント3aに応答を返していない要求144aについて、要求144aと同一の内容の要求144bをクライアント3aの代わりにサーバ2bに送り、サーバ2aに成りすまして応答147をクライアント3aに送信する。
【００７８】
障害が発生している間は、負荷分散装置4aは、クライアント3bの次の要求148も、サーバ2bに送り、その応答149をクライアント3bに送信する。このため、負荷分散ができないものの、クライアント3a、3bの要求は確実に処理されることになる。
【００７９】
上記負荷分散装置4aの処理と代理応答装置1の処理とは、並行して、あるいは、任意の順番で行われてもよい。
【００８０】
このように、代理応答装置1は、負荷分散装置4aが障害発生を検知して、クライアントの要求を処理するサーバを2aから2bに切り替えるまでの間、サーバ2aが応答していないすべての要求について、同様の処理を行う。
【００８１】
その後、163でサーバ2aの障害が復旧すると、負荷分散装置4aと代理応答装置1は、164、165で復旧を検知し、再び通常の処理に戻る。以降のメッセージ150〜153は、メッセージ141〜143と同様に正常に行われ、負荷も分散される。
【００８２】
【発明の効果】
本発明によれば、可用性とスケーラビリティとを兼ね備えるクラスタ方式のクライアントサーバ型のシステムを提供できる。
【図面の簡単な説明】
【図１】実施例の代理応答装置1を用いたネットワークシステムの一構成図。
【図２】代理応答装置1の構成を示す図。
【図３】代理応答装置1が備えるパケットバッファ102の１実施例を示す図。
【図４】代理応答装置1が備えるサーバ管理表103の１実施例を示す図。
【図５】クライアントとサーバ間で送受信されるパケットフォーマットの１例を示す図。
【図６】クライアント3とサーバ2a間で正常にIPパケットが送受信される場合のメッセージフローを示す図。
【図７】代理応答装置1で実行される処理の一実施例を示すフローチャートの主要部を示す図。
【図８】代理応答装置1で実行される代理応答処理177の１実施例を示すフローチャートの主要部を示す図。
【図９】クライアント3とサーバ2a間で発生した第一の障害例のメッセージフローを示す図。
【図１０】クライアント3とサーバ2a間で発生した第二の障害例のメッセージフローを示す図
【図１１】障害発生から復旧までの代理応答装置1を適用したネットワークシステム内のメッセージフローを示す図。
【符号の説明】
1…代理応答装置、2…サーバ、3…クライアント、4…負荷分散装置、6…ネットワーク、101…プログラム、102…パケットバッファ、103…サーバ管理表。
Claims (8)
- クライアントと複数のサーバとに通信ネットワークを介して接続され、前記クライアントの要求メッセージの処理をしているいずれかのサーバに障害が発生した場合に、障害が発生していない他のサーバに、前記要求メッセージの処理を継続させ、継続させた処理結果である応答パケットを前記クライアントに送信する代理応答装置であって、
前記サーバでの障害発生を監視する手段と、
前記サーバが前記クライアントとの間で送受信する要求メッセージを構成する要求パケットと前記要求メッセージに対応する応答メッセージを構成する応答パケットとを前記通信ネットワークから取得し、切断要求パケットを受信するまで保存する手段と、
前記監視する手段が、前記サーバに障害が発生したことを検知した際に、前記保存する手段による保存結果を参照して、前記クライアントに送信されていない応答パケットを、前記他のサーバから取得し、前記クライアントに送信する手段と、を備える代理応答装置。 - 請求項１に記載の代理応答装置であって、
前記応答パケットを前記他のサーバから取得し、前記クライアントに送信する手段は、
前記クライアントから、新たな要求パケットを受信し、前記他のサーバに送信する手段と、
前記他のサーバから、前記新たな要求パケットに対する応答パケットを受信し、前記クライアントに送信する手段と、を備える代理応答装置。 - 請求項２に記載の代理応答装置であって、
前記応答パケットを前記他のサーバから取得し、前記クライアントに送信する手段は、
前記クライアントから要求され、対応する応答パケットを前記サーバから応答されていない要求パケットを、前記他のサーバに送信する手段と、
前記他のサーバから、前記要求パケットに対する応答パケットを受信し、前記クライアントに送信する手段と、を備える代理応答装置。 - 請求項２に記載の代理応答装置であって、
前記複数のサーバのアドレスを保持する手段を備え、
前記応答パケットを前記他のサーバから取得し、前記クライアントに送信する手段は、当該応答パケットの送信元アドレスを障害が発生した前記サーバのアドレスに書き換えて送信する代理応答装置。 - 請求項３に記載の代理応答装置であって、
前記応答されていない要求パケットを、前記他のサーバに送信する手段は、当該要求パケットの送信元アドレスを当該代理応答装置のアドレスに書き換えて送信する代理応答装置。 - 請求項１に記載の代理応答装置であって、
前記監視する手段が、前記サーバに障害が発生したことを検知した場合には、前記保存する手段による保存結果に蓄えられたパケットを用いて、前記サーバにおいて障害が発生した状態を、前記他のサーバとの間で、再現する手段を備える代理応答装置。 - 請求項６に記載の代理応答装置であって、
前記再現する手段は、
前記サーバの障害を検知した際に、蓄積したパケットから前記クライアントが送信したパケットの送信先アドレスを、前記他のサーバのアドレスを書き換えて送信する手段と、
前記他のサーバから応答された応答パケットを受信する手段と、
前記応答パケットの内、前記サーバが前記クライアントに既に送信済みのパケットを識別する手段と、を備える代理応答装置。 - クライアントと、複数のサーバと、負荷分散装置とが通信ネットワークを介して接続されたネットワークシステムにおいて、
前記負荷分散装置は、前記クライアントの要求メッセージを処理しているサーバに障害が発生した場合に、他のサーバに、前記クライアントからの新たな要求メッセージを処理させる手段を備え、
前記代理応答装置は、前記サーバでの障害発生を監視する手段と、前記サーバが前記クライアントとの間で送受信する要求メッセージを構成する要求パケットと前記要求パケットに対応する応答メッセージを構成する応答パケットとを前記通信ネットワークから取得し、切断要求パケットを受信するまで保存する手段と、前記監視する手段が、前記サーバに障害が発生したことを検知した際に、前記保存する手段による保存結果を参照して、前記クライアントに送信されていない応答パケットを、前記他のサーバから取得し、前記クライアントに送信する手段と、を備えるネットワークシステム。
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003074803A JP4087271B2 (ja) | 2003-03-19 | 2003-03-19 | 代理応答装置およびネットワークシステム |
| US10/703,824 US7518983B2 (en) | 2003-03-19 | 2003-11-07 | Proxy response apparatus |
| CNB2003101245671A CN100369413C (zh) | 2003-03-19 | 2003-12-30 | 代理响应设备及用于代理响应设备的方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003074803A JP4087271B2 (ja) | 2003-03-19 | 2003-03-19 | 代理応答装置およびネットワークシステム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004280738A JP2004280738A (ja) | 2004-10-07 |
| JP4087271B2 true JP4087271B2 (ja) | 2008-05-21 |
Family
ID=33290285
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003074803A Expired - Fee Related JP4087271B2 (ja) | 2003-03-19 | 2003-03-19 | 代理応答装置およびネットワークシステム |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US7518983B2 (ja) |
| JP (1) | JP4087271B2 (ja) |
| CN (1) | CN100369413C (ja) |
Families Citing this family (30)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8312530B2 (en) * | 2004-07-12 | 2012-11-13 | Cisco Technology, Inc. | System and method for providing security in a network environment using accounting information |
| JP4869714B2 (ja) * | 2006-01-16 | 2012-02-08 | 株式会社ソニー・コンピュータエンタテインメント | 情報処理装置、信号伝送方法、およびブリッジ |
| WO2008020644A1 (fr) * | 2006-08-18 | 2008-02-21 | Nec Corporation | Serveur mandataire, système de communication, procédé de communication et programme |
| JP2008092217A (ja) * | 2006-09-29 | 2008-04-17 | Toshiba Corp | Ｉｐ電話システム及び電話交換装置 |
| JP4470934B2 (ja) | 2006-10-20 | 2010-06-02 | 日本電気株式会社 | プロキシ・サーバ、通信システム、通信方法及びプログラム |
| JP4959487B2 (ja) * | 2007-09-21 | 2012-06-20 | 株式会社日立製作所 | ネットワークデバイスのプログラム制御方法およびデバイス監視装置 |
| RU2470484C2 (ru) * | 2007-12-17 | 2012-12-20 | Телефонактиеболагет Лм Эрикссон (Пабл) | Избыточность мобильных узлов базовой сети |
| JP4900268B2 (ja) * | 2008-02-04 | 2012-03-21 | 富士通株式会社 | アプリケーション通信制御装置及びプログラム |
| KR101548959B1 (ko) * | 2008-06-04 | 2015-09-01 | 삼성전자주식회사 | 패킷 통신 시스템에서 네트워크 주소 설정을 위한 장치 및방법 |
| JP5446405B2 (ja) * | 2009-04-09 | 2014-03-19 | 富士通株式会社 | イベント検出制御方法及びシステム |
| US8560604B2 (en) | 2009-10-08 | 2013-10-15 | Hola Networks Ltd. | System and method for providing faster and more efficient data communication |
| US8805787B2 (en) * | 2009-10-30 | 2014-08-12 | Verizon Patent And Licensing Inc. | Network architecture for content backup, restoring, and sharing |
| JP2012191542A (ja) * | 2011-03-14 | 2012-10-04 | Toshiba Corp | 通信システム、クライアント通信中継プログラム、サーバ通信中継プログラム |
| JP5729209B2 (ja) * | 2011-08-12 | 2015-06-03 | 富士通株式会社 | 情報処理装置、情報処理システムのテスト方法およびプログラム |
| JP5413482B2 (ja) * | 2012-04-10 | 2014-02-12 | セイコーエプソン株式会社 | アプリケーション実行装置およびアプリケーション実行システム |
| US9241044B2 (en) | 2013-08-28 | 2016-01-19 | Hola Networks, Ltd. | System and method for improving internet communication by using intermediate nodes |
| JP2015197759A (ja) * | 2014-03-31 | 2015-11-09 | 富士通株式会社 | 情報処理装置、情報処理方法およびプログラム |
| US9961131B2 (en) | 2014-04-25 | 2018-05-01 | Microsoft Technology Licensing, Llc | Enhanced reliability for client-based web services |
| CN104794143A (zh) * | 2014-07-30 | 2015-07-22 | 北京中科同向信息技术有限公司 | 一种无代理的备份技术 |
| JP6415925B2 (ja) * | 2014-10-15 | 2018-10-31 | 京セラ株式会社 | 管理装置、管理プログラム、及び管理方法 |
| CN104506372B (zh) * | 2015-01-04 | 2018-09-11 | 中国联合网络通信集团有限公司 | 一种实现主备服务器切换的方法及系统 |
| JP6576071B2 (ja) * | 2015-03-27 | 2019-09-18 | キヤノン株式会社 | 情報処理装置、サーバクライアントシステム、情報処理装置の制御方法及びプログラム |
| US11057446B2 (en) | 2015-05-14 | 2021-07-06 | Bright Data Ltd. | System and method for streaming content from multiple servers |
| CN104991739B (zh) * | 2015-06-19 | 2018-05-01 | 中国科学院计算技术研究所 | 元数据服务器失效接替中精确一次执行语义的方法及系统 |
| JP6511019B2 (ja) * | 2016-06-21 | 2019-05-08 | 日本電信電話株式会社 | サービス継続装置、サービス継続方法およびプログラム |
| EP3313052A1 (en) * | 2016-10-24 | 2018-04-25 | Snips | Means for enhancing privacy of users of a cloud-based service |
| CN106973095A (zh) * | 2017-03-27 | 2017-07-21 | 慧影医疗科技（北京）有限公司 | 基于dicom协议的代理转发方法及装置 |
| EP4311204A3 (en) | 2017-08-28 | 2024-04-10 | Bright Data Ltd. | Method for improving content fetching by selecting tunnel devices |
| US11190374B2 (en) | 2017-08-28 | 2021-11-30 | Bright Data Ltd. | System and method for improving content fetching by selecting tunnel devices |
| LT3780547T (lt) * | 2019-02-25 | 2023-03-10 | Bright Data Ltd. | Turinio parsisiuntimo, naudojant url bandymų mechanizmą, sistema ir būdas |
Family Cites Families (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH05316116A (ja) | 1992-05-14 | 1993-11-26 | Matsushita Electric Ind Co Ltd | サーバの予備系の一元管理装置 |
| JP3224745B2 (ja) * | 1996-07-09 | 2001-11-05 | 株式会社日立製作所 | 高信頼化ネットワークシステム及びサーバ切り替え方法 |
| US6108300A (en) * | 1997-05-02 | 2000-08-22 | Cisco Technology, Inc | Method and apparatus for transparently providing a failover network device |
| JPH1168837A (ja) | 1997-08-20 | 1999-03-09 | Hitachi Ltd | Ｉｐネットワーク上のパケット交換網における着信転送方式 |
| US6266335B1 (en) * | 1997-12-19 | 2001-07-24 | Cyberiq Systems | Cross-platform server clustering using a network flow switch |
| US6230183B1 (en) * | 1998-03-11 | 2001-05-08 | International Business Machines Corporation | Method and apparatus for controlling the number of servers in a multisystem cluster |
| US7409420B2 (en) * | 2001-07-16 | 2008-08-05 | Bea Systems, Inc. | Method and apparatus for session replication and failover |
| US6847975B2 (en) | 2001-07-30 | 2005-01-25 | Hitachi, Ltd. | Proxy processing method |
| US7072332B2 (en) * | 2001-09-27 | 2006-07-04 | Samsung Electronics Co., Ltd. | Soft switch using distributed firewalls for load sharing voice-over-IP traffic in an IP network |
| JP2004070860A (ja) * | 2002-08-09 | 2004-03-04 | Hitachi Ltd | ストリームコンテンツ配送システムおよびプロキシサーバ |
| US7266607B2 (en) * | 2002-08-27 | 2007-09-04 | International Business Machines Corporation | Quasi-high availability hosted applications |
| US6874031B2 (en) * | 2002-10-07 | 2005-03-29 | Qualcomm Inc. | Method and apparatus for sharing authentication session state in a global distributed network |
-
2003
- 2003-03-19 JP JP2003074803A patent/JP4087271B2/ja not_active Expired - Fee Related
- 2003-11-07 US US10/703,824 patent/US7518983B2/en active Active
- 2003-12-30 CN CNB2003101245671A patent/CN100369413C/zh not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| CN100369413C (zh) | 2008-02-13 |
| JP2004280738A (ja) | 2004-10-07 |
| CN1533095A (zh) | 2004-09-29 |
| US20040221207A1 (en) | 2004-11-04 |
| US7518983B2 (en) | 2009-04-14 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4087271B2 (ja) | 代理応答装置およびネットワークシステム | |
| US9659075B2 (en) | Providing high availability in an active/active appliance cluster | |
| US7996517B2 (en) | Transparent network connection takeover | |
| US7987266B2 (en) | Failover in proxy server networks | |
| US6871296B2 (en) | Highly available TCP systems with fail over connections | |
| US20030014684A1 (en) | Connection cache for highly available TCP systems with fail over connections | |
| US9049241B2 (en) | Peer discovery and secure communication in failover schemes | |
| JP4295089B2 (ja) | セッション複製及びフェイルオーバーのための方法及び装置 | |
| JP2004032224A (ja) | サーバ引継システムおよびその方法 | |
| US20150256622A1 (en) | Connection management device, communication system, connection management method, and computer program product | |
| JP2006285377A (ja) | 故障監視プログラム及び負荷分散装置 | |
| CN112671554A (zh) | 一种节点故障处理方法及相关装置 | |
| JP2006229399A (ja) | 通信システム、中継ノード及びそれらに用いる通信方法並びにそのプログラム | |
| JPH1185644A (ja) | 冗長構成システムの系切替制御方法 | |
| CN106708881B (zh) | 基于网络文件系统的交互方法和装置 | |
| CN110661836B (zh) | 消息路由方法、装置及系统、存储介质 | |
| CN114422335A (zh) | 通信方法、装置、服务器及存储介质 | |
| US11757987B2 (en) | Load balancing systems and methods | |
| CN114090342A (zh) | 存储容灾的链路管理方法及消息执行节点、存储控制集群 | |
| JP2001244977A (ja) | データ転送装置、データ転送システム、データ転送方法及び記憶媒体 | |
| CN109510864B (zh) | 一种缓存请求的转发方法、传输方法及相关装置 | |
| CN113973114A (zh) | 云服务器热迁移方法、虚拟交换机和软件定义网络架构 | |
| JPH10116257A (ja) | 分散メディア処理サーバおよび該分散メディア処理サーバを用いた通信ネットワーク | |
| JP4123440B2 (ja) | オブジェクト指向のネットワーク分散型コンピューティングシステム、その負荷分散装置及びサーバ | |
| CN117155762A (zh) | 一种故障隔离方法及相关装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050916 |
|
| RD02 | Notification of acceptance of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7422 Effective date: 20051214 |
|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20060523 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070626 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070824 |
|
| 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: 20080129 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080220 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110228 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 4087271 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110228 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120229 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120229 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130228 Year of fee payment: 5 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| LAPS | Cancellation because of no payment of annual fees |