(57)【要約】【課題】信頼性が高く連続運転に適しかつ安価に構築可能なサーバシステム及び仲介装置並びに誤り隠蔽方法等を提供する。【解決手段】クライアントサーバ型システムにおけるサーバ側のシステムにおいて、クライアントからの要求をサーバに転送するとともに、サーバから受信した前記要求に対する応答のうち正当なものを要求元のクライアントに転送する転送手段を備えた仲介装置を複数設けるとともに、クライアントからは単一のサーバとして見せるとともに、サーバからは単一のルータとして見せる仮想アドレスを予め決定し、前記仲介装置は、前記仮想アドレス宛の要求及び応答を前記転送手段が転送できるように制御する制御手段とを備える。【選択図】            図１
2004227534.tif 000002
【特許請求の範囲】
【請求項１】
クライアントサーバ型システムにおけるサーバ側のシステムにおいて、
クライアントからの要求をサーバに転送するとともに、サーバから受信した前記要求に対する応答のうち正当なものを要求元のクライアントに転送する転送手段を備えた仲介装置を複数設けるとともに、
クライアントからは単一のサーバとして見せるとともに、サーバからは単一のルータとして見せる仮想アドレスを予め決定し、
前記仲介装置は、前記仮想アドレス宛の要求及び応答を前記転送手段が転送できるように制御する制御手段とを備えた
ことを特徴とするサーバシステム。
【請求項２】
クライアント・サーバ・仲介装置間の通信として、ＴＣＰ／ＩＰプロトコルスイートを用い、前記仮想アドレスとしてネットワーク層における仮想ＩＰアドレスを割り当てる
ことを特徴とする請求項１記載のサーバシステム。
【請求項３】
クライアント・サーバ・仲介装置間の通信として、イーサネットを用い、前記仮想アドレスとしてデータリンク層における仮想ＭＡＣアドレスを割り当てる
ことを特徴とする請求項１記載のサーバシステム。
【請求項４】
前記仲介装置は、前記仮想アドレスの下位のレイヤのアドレスを問い合わせる要求に対し、応答を返す応答手段を備えた
ことを特徴とする請求項１乃至３何れか１項記載のサーバシステム。
【請求項５】
前記応答手段は、ＡＲＰ要求に対して応答する
ことを特徴とする請求項４記載のサーバシステム。
【請求項６】
前記サーバは、前記仲介装置から受け取る複数の同一のパケットのうち、重複する２つ目以降のパケットを廃棄するパケット廃棄手段を備えたことを特徴とする請求項１乃至５何れか１項記載のサーバシステム。
【請求項７】
前記クライアントは、前記仲介装置から受け取る複数の同一のパケットのうち、重複する２つ目以降のパケットを廃棄するパケット廃棄手段を備えた
ことを特徴とする請求項１乃至６何れか１項記載のサーバシステム。
【請求項８】
前記仲介装置は、お互いにサーバ管理情報を確認し合い、不一致が生じた場合には同じ内部状態になるように修正する修正手段を備えた
ことを特徴とする請求項１乃至７何れか１項記載のサーバシステム。
【請求項９】
前記仲介装置は、前記仮想アドレス宛の要求及び応答を受け取った際、前記仲介装置の数だけコピーを作成し、全ての仲介装置へ送信するコピー作成・送信手段を備えた
ことを特徴とする請求項１乃至８何れか１項記載のサーバシステム。
【請求項１０】
クライアントサーバ型システムにおけるサーバ側のシステムにおいてクライアントとサーバの間に介在する仲介装置であって、
クライアントからの要求をサーバに転送するとともに、サーバから受信した前記要求に対する応答のうち正当なものを要求元のクライアントに転送する転送手段と、
クライアントからは単一のサーバとして見せるとともに、サーバからは単一のルータとして見せる仮想アドレスを予め決定し、
前記仮想アドレス宛の要求及び応答を前記転送手段が転送できるように制御する制御手段とを備えた
ことを特徴とする仲介装置。
【請求項１１】
クライアントサーバ型システムにおけるサーバで発生した誤りをクライアントに対して隠蔽する方法において、
クライアントとサーバの間に、クライアントからの要求をサーバに転送するとともに、サーバから受信した前記要求に対する応答のうち正当なものを要求元のクライアントに転送する転送手段を備えた仲介装置を複数介在させ、
クライアントからは単一のサーバとして見せるとともに、サーバからは単一のルータとして見せる仮想アドレスを予め決定し、前記仮想アドレス宛の要求及び応答を前記転送手段が転送できるように制御する
ことを特徴とするクライアントサーバ型システムにおける誤り隠蔽方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、障害などによるサービスの停止が許されないＥＣサーバ、Ｗｅｂサーバ、認証サーバなどのインターネットビジネス用システムや通信網のノードシステムなどのサーバシステムに関する。
【０００２】
【従来の技術】
この種のサーバシステムは、クライアントに対して常にサービスを適切に提供する必要がある。すなわち、サーバシステムの「誤り」を隠蔽し、「障害（ｆａｉｌｕｒｅ）」の発生を防止する必要がある。ここで「障害」とはシステムの機能損失を意味する。「障害」の発生要因の具体例としては、例えば、ハードウェアにおけるバグや故障、ソフトウェアにおけるバグなどが挙げられる。そして、これら「障害」の原因を「フォールト」と呼ぶ。仮に、システムに「フォールト」が存在していても、そのことが直ちに「障害」を引き起こすとは限らず潜在することもある。「フォールト」が原因で異常が表面化することを「誤り（ｅｒｒｏｒ）」という。そして、「誤り」が発生したシステムが正常な状態から逸脱すると「障害」が発生する。なお、「誤り」はバグや故障などの狭義の「フォールト」のみが原因ではなく、例えば、間欠故障やオペレータの設定ミスや操作ミスなども「誤り」の原因となる。
【０００３】
この「誤り」を隠蔽することができる高信頼性サーバシステムの一例として、「サーバシステム、仲介装置、クライアントサーバ型システムにおける誤り隠蔽方法」（特願２００１−２５６５１１号）が提案されている。この高信頼性サーバシステムの一例について、図１９を参照し説明する。なお、ここではクライアントに対してＷｅｂサービスを提供するシステムについて例示する。
【０００４】
この高信頼性サーバシステム１０１０は、図１９に示すように、クライアント１０４１の要求を受け取り、該要求に対する応答をする高信頼性サーバ１０２０と、高信頼性サーバ１０２０とクライアント１０４１との間に介在する仲介装置１０３０とを備えている。
【０００５】
高信頼性サーバ１０２０は、一つ以上のサーバで構成されている。図１９の例では、高信頼性サーバ１０２０は、３つのサーバ１０２１、１０２２、１０２３で構成される。仲介装置からそれぞれのサーバへ送信された同じ要求に対して、各サーバは正常に稼働していれば同じ応答を返す。
【０００６】
仲介装置１０３０は、ネットワーク１０５０を介してクライアント１０４１からの要求を受け取り、後述する適切なタイミングで高信頼性サーバ１０２０へ転送し、高信頼性サーバからの応答の正当性をチェックして正しい応答をクライアント１０４１へ返す制御部１０３１と、高信頼性サーバ１０２０の各サーバ１０２１、１０２２、１０２３の状態を管理するサーバ管理表１０３２とを備えている。制御部１０３１は、サーバ管理表１０３２に対してどのサーバが正常であるか、又は障害があるかを登録し、このサーバ管理表１０３２を参照して、どのサーバにクライアント１０４１からの要求を処理させるかを判断する。サーバ管理表１０３２は、サーバを識別するためのサーバＩＤ、サーバのＩＰアドレス、サーバの稼働情報から構成される。
【０００７】
クライアント１０４１は、Ｗｅｂブラウザを用いて、ネットワーク１０５０を経由して高信頼性サーバ１０２０にＷｅｂページを要求する。
【０００８】
次に、仲介装置１０３０の動作について説明する。クライアント１０４１は、高信頼性サーバシステム１０１０へＷｅｂページ要求メッセージ１１１０を送信する。制御部１０３１はこの要求メッセージ１１１０を受け取り、サーバ管理表１０３２を見て、正常なサーバへ転送する。図１９の例では、サーバ１０２１、１０２２、１０２３が正常であるため、制御部１０３１は要求メッセージ１１１０のコピー１１１１、１１１２、１１１３を作り、それぞれをサーバ１０２１、１０２２、１０２３へ転送する。
【０００９】
サーバ１０２１は、要求メッセージ１１１１を受け取り、応答１１２１を制御部１０３１へ返す。同様に、サーバ１０２２は応答１１２２を、サーバ１０２３は応答１１２３を制御部１０３１へ返す。制御部１０３１は、応答１１２１、１１２２、１１２３で多数決を行い、多数派の応答を正常と判断しクライアント１０４１へ応答１１２０を返す。
【００１０】
もし、多数決の結果、全部が一致せず不一致の応答があった場合、その応答を返したサーバは障害であると制御部１０３１は判断し、サーバ管理表１０３２の稼働状態情報を「正常」から「障害」へ変更する。以後、制御部１０３１は障害となったサーバへ、クライアントからの要求を転送しない。
【００１１】
上記のようなシステムの他に、２つの計算機が平行して同じ処理を行う二重系システム（例えば、特許文献１参照）、オンライン側及びスタンバイ側とに分かれた２系の制御コンピュータ間において、タスク同期をとる制御システム（例えば、特許文献２参照）等が従来技術として知られている。
【００１２】
【特許文献１】
特開昭５２−６０５４０号公報
【特許文献２】
特開平１−３０３５６２号公報
【００１３】
【発明が解決しようとする課題】
上述のように、従来の高信頼性サーバシステムでは、クライアントからの要求を受け取った制御部は、複数のサーバへ該要求を転送し、該要求に対するサーバからの応答を受け取り多数決を実行するという方式を採用してきた。従って、もしあるサーバが障害となり誤った応答を制御部へ返したとしても、多数決によってその誤りを隠蔽することができた。
【００１４】
しかし、制御部自体が障害となった場合には、システム全体がダウンしてしまうという問題点があった。また、この問題を避けるために制御部を単に複数並べることも考えられるが、この場合には、クライアントやサーバからは複数の制御部が見えてしまう。このため、制御部が障害のたびに、クライアントとサーバ側で手動で設定を変更する必要が生じたり、又は、手動での設定を避ける場合には自動化するためにクライアントとサーバの双方に改造する必要が生じるという問題があった。
【００１５】
本発明は、上記事情に鑑みてなされたものであり、その目的とするところは、信頼性が高く連続運転に適しかつ安価に構築可能なサーバシステム及び仲介装置並びに誤り隠蔽方法を提供することにある。
【００１６】
【課題を解決するための手段】
上記目的を達成するために、本願発明は、クライアントサーバ型システムにおけるサーバ側のシステムにおいて、クライアントからの要求をサーバに転送するとともに、サーバから受信した前記要求に対する応答のうち正当なものを要求元のクライアントに転送する転送手段を備えた仲介装置を複数設けるとともに、クライアントからは単一のサーバとして見せるとともに、サーバからは単一のルータとして見せる仮想アドレスを予め決定し、前記仲介装置は、前記仮想アドレス宛の要求及び応答を前記転送手段が転送できるように制御する制御手段とを備えたことを特徴とするサーバシステムをもって解決手段とする。
【００１７】
本発明によれば、クライアント・サーバ間の要求及び応答を転送している一の仲介装置が障害となっても、他の正常な仲介装置によって転送を継続できるので、システム全体のダウンを防ぎ、より高信頼なクライアントサーバ型システムを構築できる。また、仮想アドレスをあらかじめ決めておき、どの仲介装置もこれらの仮想アドレス宛の要求と応答を処理できるようにしている。これにより、どの仲介装置が障害等によりダウンしても、サーバやクライアントは何の変更も必要ない。すなわち、既存のサーバやクライアントを無改造で利用できるので、信頼性の高いクライアントサーバ型システムを低コストで構築することができる。
【００１８】
【発明の実施の形態】
本発明の第一の実施形態に係る高信頼性サーバシステムについて図面を参照しながら説明する。図１は本実施形態に係る高信頼性サーバシステムの全体構成を説明するブロック図である。なお、本実施形態では、認証サービスを提供するシステム、すなわちサーバがＲＡＤＩＵＳサーバであるシステムについて例示する。また、サーバが稼働しているパソコンや仲介装置では、ＯＳとしてＬｉｎｕｘ（登録商標）が稼働しているシステムを例示する。
【００１９】
この高信頼性サーバシステム１０は、図１に示すように、クライアント７０からの要求に対して応答を返す高信頼性サーバ２０と、高信頼性サーバ２０とクライアント７０との間に介在する仲介装置３０とを備えている。図１の例では、仲介装置３０として２つの仲介装置３０ａ及び３０ｂとを備えている。なお、以下の説明において、複数の仲介装置３０及びその構成要素の各々を個別に表す場合は、仲介装置３０ａや仲介装置３０ｂなどのように、符号「ａ」「ｂ」を付して表すものとする。
【００２０】
このシステムにおいて、各装置間の通信プロトコル体系は不問である。本実施形態ではＴＣＰ／ＩＰプロトコルスイートを用いた。なお、ＴＣＰ／ＩＰプロトコルスイートは、ＴＣＰ及びＩＰを狭義に表すものではなく、ＵＤＰやＡＲＰなどを含む広義のプロトコル体系を意味する。
【００２１】
高信頼性サーバ２０は、一つ以上のサーバで構成される。図１の例では、高信頼性サーバ２０は、３つのサーバ２１、２２、２３で構成される。仲介装置からそれぞれのサーバへ送信された同じ要求に対して、各サーバは正常に稼働していれば同じ応答をする。サーバ２１、２２、２３は、コンピュータ上などで動作するソフトウェアで実装しても良いし、ハードウェアで実装しても良い。すなわち、高信頼性サーバ２０は、複数のハードウェアによって実現しても良いし、一台のハードウェア上に複数のサーバを実装することによって実現しても良い。図１の例では、サーバ２１、２２、２３はそれぞれコンピュータ９１、９２、９３上で動作しているソフトウェアである。コンピュータ９１、９２、９３はそれぞれＩＰアドレス１７２．１６．３．３、１７２．１６．３．４、１７２．１６．３．５が割り当てられている。また、コンピュータ９１、９２、９３はそれぞれＭＡＣアドレスｃｃ：ｃｃ：ｃｃ：ｃｃ：ｃｃ：０３、ｃｃ：ｃｃ：ｃｃ：ｃｃ：ｃｃ：０４、ｃｃ：ｃｃ：ｃｃ：ｃｃ：ｃｃ：０５を有している。
【００２２】
クライアント７０は、高信頼性サーバシステム１０によりサービスの提供を受ける装置である。本実施形態では、クライアント７０としてＲＡＳ（Ｒｅｍｏｔｅ  Ａｃｃｅｓｓ  Ｓｅｒｖｅｒ）などのＮＡＳ（Ｎｅｔｗａｒｋ  Ａｃｃｅｓｓ  Ｓｅｒｖｅｒ）であるものを例示する。また、本実施形態では、クライアント７０には、ＩＰアドレスとして１９２．１６８．３．２００が割り当てられている。また、ＭＡＣアドレス、ｄｄ：ｄｄ：ｄｄ：ｄｄ：ｄｄ：００を有している。
【００２３】
仲介装置３０は、サーバ２１、２２、２３側ネットワーク（以下、内郡ネットワークという）８１に接続するＮＩＣ（Ｎｅｔｗｏｒｋ  Ｉｎｔｅｒｆａｃｅ  Ｃａｒｄ）３１と、クライアント側ネットワーク（以下、外部ネットワークという）８２と接続するＮＩＣ３２とを備えている。また、仲介装置３０は、ＮＩＣ３１を介して内部ネットワーク８１からパケットを受信する内部ネットワーク側パケット受信部３３と、ＮＩＣ３１を介して内部ネットワーク８１へパケットを送信する内部ネットワーク側パケット送信部３４と、ＮＩＣ３２を介して外部ネットワーク８２からパケットを受信する外部ネットワーク側パケット受信部３５と、ＮＩＣ３２を介して外部ネットワーク８２へパケットを送信する外部ネットワーク側パケット送信部３６とを備えている。さらに、仲介装置３０は、内部ネットワーク側パケット受信部３３及び外部ネットワーク側パケット受信部３５から受信したパケットに対して後述する処理を行い、内部ネットワーク側パケット送信部３４及び外部ネットワーク側パケット送信部３６を用いてパケットを送信するパケット制御部４０を備えている。
【００２４】
各仲介装置３０は、ＮＩＣ３１を介して、サーバ２１、２２、２３が動作しているコンピュータ９１、９２、９３に接続されている内部ネットワーク８１と接続している。図１の例では、コンピュータ９１、９２、９３とＮＩＣ３２はリピータハブ８３に接続されている。また、各仲介装置３０は、ＮＩＣ３２を介して、クライアント７０が接続されている外部ネットワーク８２に接続されている。図１の例では、クライアント７０とＮＩＣ３２はリピータハブ８４に接続されている。
【００２５】
外部ネットワーク８２と接続するＮＩＣ３２及び内部ネットワーク８１と接続するＮＩＣ３１には、仲介装置３０ごとに異なるＩＰアドレスが割り当てられ、また、それぞれが異なるＭＡＣアドレス（ハードウェアアドレス）を有している。図１の例では、仲介装置３０ａのＮＩＣ３２ａには、ＩＰアドレスとして１９２．１６８．３．１が割り当てられており、ＭＡＣアドレスはａａ：ａａ：ａａ：ａａ：ａａ：０１である。仲介装置３０ｂのＮＩＣ３２ｂには、ＩＰアドレスとして１９２．１６８．３．２が割り当てられており、ＭＡＣアドレスはａａ：ａａ：ａａ：ａａ：ａａ：０２である。また、図１の例では、仲介装置３０ａのＮＩＣ３１ａには、ＩＰアドレスとして１７２．１６．３．１が割り当てられており、ＭＡＣアドレスはｂｂ：ｂｂ：ｂｂ：ｂｂ：ｂｂ：０１である。仲介装置３０ｂのＮＩＣ３１ｂには、ＩＰアドレスとして１７２．１６８．３．２が割り当てられており、ＭＡＣアドレスはｂｂ：ｂｂ：ｂｂ：ｂｂ：ｂｂ：０２である。
【００２６】
次に、仮想サーバと仮想ルータについて説明する。本願発明の目的である、クライアントやサーバを無改造で利用しつつ、さらなる高信頼化を提供することを実現するためには、以下の二つの条件を満たす必要がある。
【００２７】
（１）もし、高信頼性サーバシステム１０の内部で障害が発生したとしても、クライアント７０にはその障害は隠蔽される。つまり、クライアント７０は、その障害によって動作や設定を変更する必要はなく、障害前と変わらずに高信頼性サーバシステム１０からサービスを受けることができる。
【００２８】
（２）もし、複数の仲介装置３０のうち何れかで障害が発生したとしても、各サーバ２１、２２、２３にはその障害は隠蔽される。つまり、各サーバ２１、２２、２３は、その障害によって動作や設定を変更する必要はなく、障害前と変わらずにクライアント７０と通信することができる。
【００２９】
本願発明では、上記条件（１）を実現するために「仮想サーバ」を定義し、上記条件（２）を実現するために「仮想ルータ」を定義する。
【００３０】
仮想サーバとは、高信頼性サーバシステムの内部構成を隠蔽し、クライアントから見て仮想的に一つのサーバに見えるサーバのことである。例えば、図１に例示した高信頼性サーバシステム１０の場合、図２に示すように、クライアント７０から見て仮想ＩＰアドレス１９２．１６８．３．１００、仮想ＭＡＣアドレスａａ：ａａ：ａａ：ａａ：ａａ：００を持った仮想サーバ１１のことである。
【００３１】
ここで、仮想ＩＰアドレスとは、仮想サーバ１１に割り当てられたＩＰアドレスであり、クライアント７０はこのＩＰアドレス宛に要求パケットを送信する。仮想ＭＡＣアドレスとは、仮想サーバ１１に割り当てられたＭＡＣアドレスであり、仮想サーバ１１が接続されているネットワーク、つまり、高信頼性サーバシステム１０が接続されている外部ネットワーク８２に接続されている通信機器が仮想サーバ１１と通信を行う場合に使われるＭＡＣアドレスである。つまり、仮想ＭＡＣアドレスとは、外部ネットワーク８２に接続されている通信機器が仮想ＩＰアドレスに対するアドレス解決要求（ＡＲＰ要求パケットを送信する）を行った際に得られる（ＡＲＰ応答パケットに含まれる）ＭＡＣアドレスのことである。仮想ＩＰアドレスと仮想ＭＡＣアドレスは、外部ネットワーク８２に接続されている通信機器が持っているＩＰアドレス及びＭＡＣアドレスと重複しないように選択する必要がある。ここで注意すべき点は、仮想ＩＰアドレス及び仮想ＭＡＣアドレスを持った通信機器は実際には存在しないことである。従って、ＡＲＰ要求に対するＡＲＰ応答は、通常は仮想ＩＰアドレス及び仮想ＭＡＣアドレスを持った通信機器のＬｉｎｕｘカーネルで実行されるが、仮想ＩＰアドレス及び仮想ＭＡＣアドレスを持った通信機器が存在しないため、アドレス解決されないという問題が生じる。この問題を解決するために、仲介装置３０は疑似ＡＲＰ応答部を持っており、アドレス解決を実現する（詳細は後述する）。
【００３２】
このような構成により、一つ以上の仲介装置が正常でありかつ一つ以上のサーバが正常であれば、仮想サーバ１１は正常に機能する。従って、仮想サーバ１１の実現により、高信頼性サーバシステム１０の内部で障害があろうと無かろうと、クライアント７０はＩＰアドレス１９２．１６８．３．１００の仮想サーバ１１と通信することだけを行なえば良い。つまり、上記条件（１）を満足することができる。
【００３３】
仮想ルータとは、仲介装置の冗長化構成を隠蔽し、サーバから見て仮想的な一つのルータに見えるルータのことである。例えば、図１の高信頼性サーバシステム１０の場合、図３に示すように、サーバ２１、２２、２３から見て、内部ネットワーク８１側に仮想ＩＰアドレス１７２．１６．３．１００、仮想ＭＡＣアドレスｂｂ：ｂｂ：ｂｂ：ｂｂ：ｂｂ：００を持っている仮想ルータ３７のことである。
【００３４】
ここで、仮想ＩＰアドレスとは、仮想ルータ３７に割り当てられたＩＰアドレスである。内部ネットワーク８１に接続されている通信機器は、外部ネットワーク８２へパケットを転送する際の、ルータのＩＰアドレスとして認識する。一方、仮想ＭＡＣアドレスとは、仮想ルータ３７に割り当てられたＭＡＣアドレスであり、内部ネットワーク８１に接続されている通信機器が、仮想ルータ３７と通信を行う場合に使われるＭＡＣアドレスである。つまり、仮想ＭＡＣアドレスとは、内部ネットワーク８１に接続されている通信機器が、仮想ＩＰアドレスに対するアドレス解決要求（つまり、ＡＲＰ要求パケットを送信する）を行った際に得られる（ＡＲＰ応答パケットに含まれる）ＭＡＣアドレスのことである。仮想ＩＰアドレスと仮想ＭＡＣアドレスは、内部ネットワーク８１に接続されている通信機器の有するＩＰアドレス及びＭＡＣアドレスと重複しないように選択する必要がある。ここで注意すべき点は、仮想ＩＰアドレス及び仮想ＭＡＣアドレスを持った通信機器は実際には存在しないことである。従って、ＡＲＰ要求に対するＡＲＰ応答は、通常は仮想ＩＰアドレス及び仮想ＭＡＣアドレスを持った通信機器のＬｉｎｕｘカーネルで実行されるが、仮想ＩＰアドレス及び仮想ＭＡＣアドレスを持った通信機器が存在しないため、アドレス解決されないという問題が生じる。この問題を解決するために、仲介装置３０は疑似ＡＲＰ応答部を持っており、アドレス解決を実現する（詳細は後述する）。
【００３５】
このような構成により、一つ以上の仲介装置３０が正常であれば、仮想ルータ３７は正常に機能する。従って、仮想ルータ３７の実現により、各仲介装置３０で障害があろうと無かろうと、内部ネットワーク８１に接続されている通信機器（図１の例の場合、サーバ２１、２２、２３）はＩＰアドレス１７２．１６．３．１００の仮想ルータ３７と通信することだけを行えば良い。つまり、上記条件（２）を満足することができる。
【００３６】
次に、仮想サーバ／仮想ルータを実現するための詳細について説明する。なお、仮想サーバはクライアントから見えるものであり、仮想ルータはサーバから見えるものであるが、以下に説明する方法により仮想サーバ、仮想ルータともに実現することができる。
【００３７】
まず始めに、パケット制御部４０の詳細な構成について図４を参照して説明する。図４に示すように、パケット制御部４０は、高信頼性サーバ２０の全てのサーバ（図１の例の場合、サーバ２１、２２、２３）の状態を管理するサーバ管理表４２と、内部ネットワークにおいて、仮想ルータのＩＰアドレス解決要求に対して応答を返す内部ネットワーク側擬似ＡＲＰ応答部４３と、外部ネットワークにおいて、仮想サーバのＩＰアドレス解決要求に対して応答を返す外部ネットワーク側擬似ＡＲＰ応答部４４と、クライアント７０からの要求を受け取り高信頼性サーバ２０へ該要求を転送し、高信頼性サーバ２０からの応答の正当性をチェックして正しい応答をクライアント７０へ返すサーバ制御部４１とを備えている。
【００３８】
サーバ制御部４１は、サーバ管理表４２に対してどのサーバが正常であるか、又は障害があるかを登録し、このサーバ管理表４２を参照して、どのサーバにクライアント７０からの要求を処理させるかを判断する。
【００３９】
図５に、サーバ管理表４２の一例を示す。図５に示すように、サーバ管理表４２は、各サーバを識別するためのサーバＩＤ、サーバが動作しているコンピュータのＩＰアドレス、サーバの稼働状態から構成されている。図５の例では、各サーバの状態が正常である場合を示している。
【００４０】
サーバ制御部４１は、各サーバからの応答パケットからサーバの障害を検出した場合、サーバ管理表４２内の該当するサーバの稼働状態を「正常」から「障害」に変更する。例として、サーバ２３が障害状態になった場合のサーバ管理表４２を図６に示す。
【００４１】
一方、サーバ制御部４１は、障害状態となっているサーバが正常となったことを検出した場合、サーバ管理表４２の稼働状態を「障害」から「正常」に変更する。例えば、サーバ２３が障害から復旧した場合、サーバ制御部４１はサーバ管理表４２を図６に示すものから図５に示すものへと変更する。サーバが正常になったことを認識する方法としては、例えば、サーバ制御部４１がサーバにパケットを投げてその応答から判断する方法や、コンピュータが立ち上がった時にサーバ制御部４１へサーバが立ち上がったことを通知するソフトウェアをコンピュータ上で動作させる方法などが挙げられる。
【００４２】
次に、内部ネットワーク側でのパケット送受信処理について説明する。内部ネットワークで行われる通信は、サーバ２１、２２、２３と仮想ルータ３７との間の通信である。なお、図１の例では、コンピュータ９１、９２、９３は、デフォルトゲートウェイを仮想ルータ３７に設定している。
【００４３】
まず、通信に先立って、コンピュータ９１、９２、９３は仮想ＩＰアドレス１７２．１６．３．１００に対するＭＡＣアドレスを知る必要があるため、コンピュータ９１、９２、９３はＡＲＰ要求パケットをブロードキャストする。前述のように、実際には、仮想ＩＰアドレス１７２．１６．３．１００を持った通信機器は存在しないため、通常はアドレス解決されず、コンピュータ９１、９２、９３は通信を行えないという問題が発生する。この問題を避けるために、内部ネットワーク側パケット受信部３３は、ＮＩＣ３１をｐｒｏｍｉｓｃｕｏｕｓ  ｍｏｄｅ（ＮＩＣに到着する全てのパケットを受信するモード）に設定することでリピータハブ８３に到着する全てのパケットをｒａｗ  ｓｏｃｋｅｔで受信できるようにし、受信したパケットのうち仮想ＩＰアドレス１７２．１６．３．１００のＡＲＰ要求パケットを内部ネットワーク側擬似ＡＲＰ応答部４３へ渡す。同じネットワークに接続されている機器のＭＡＣアドレスと重複しないようにあらかじめ選んだ仮想ＭＡＣアドレスを疑似ＡＲＰ応答部４３は返送する。全ての疑似ＡＲＰ応答部４３は同じ仮想ＭＡＣアドレスを返すように設定しておかなければならない。この例では、疑似ＡＲＰ応答部４３ａと４３ｂは、仲介装置３０、コンピュータ９１、９２、９３のＭＡＣアドレスと重複しないｂｂ：ｂｂ：ｂｂ：ｂｂ：ｂｂ：００を含んだＡＲＰ応答パケットを返す。複数の仲介装置が正常稼働している場合は、複数のＡＲＰ応答パケットがコンピュータ９１、９２、９３それぞれへ返されるが、同じ内容のパケットなので問題ない。このようにして、仮想ＩＰアドレスに対するアドレス解決が実現され、コンピュータ９１、９２、９３は仮想ルータ３７宛にパケット送信可能となる。
【００４４】
なお、上記ＮＩＣをｐｒｏｍｉｓｃｕｏｕｓ  ｍｏｄｅに設定し、フィルタ（必要なパケットだけｒａｗ  ｓｏｃｋｅｔで受信する）を行うには、カーネルが提供しているＴＣＰ／ＩＰスタックを使わずに、データリンク層からアプリケーション層へパケットを取り込むライブラリｌｉｂｐｃａｐ（ｆｔｐ：／／ｆｔｐ．ｅｅ．ｌｂｌ．ｇｏｖ／ｌｉｂｐｃａｐ．ｔａｒ．Ｚ）を使うのが便利である。
【００４５】
次に、内部ネットワーク８１における仲介装置３０の応答パケット受信処理について説明する。図７に内部ネットワーク８１を経由して仮想ルータ３７へやってくるパケットフォーマットを例示する。図７の例では、コンピュータ９１から仮想ルータ３７へ送信されたパケットのフォーマットである。
【００４６】
図７に示すように、該パケットの送信先ＭＡＣアドレスは仲介装置３０ａのものでも仲介装置３０ｂのものでもない。さらに、宛先ＩＰアドレスも仲介装置３０ａのものでも仲介装置３０ｂのものでもない。そこで、上記のごとく内部ネットワーク側パケット受信部３３は、ｌｉｂｐｃａｐを使いパケットを受信する。宛先ＩＰアドレスがクライアント７０の場合、サーバ制御部４１へ渡す。なお、この動作は内部ネットワーク側パケット受信部３３ａも内部ネットワーク側パケット受信部３３ｂも並行して同時に行う。
【００４７】
次に、内部ネットワーク８１における仲介装置３０の要求パケット送信処理について説明する。図８に仮想ルータ３７から内部ネットワーク８１を経由してサーバへ送信されるパケットのフォーマットを例示する。図８の例では、仲介装置３０（仲介装置３０ａと仲介装置３０ｂともに）からコンピュータ９１へ送信されるパケットのフォーマットである。
【００４８】
図８に示すように、該パケットの送信元ＩＰアドレスは、仲介装置３０ａでも仲介装置３０ｂでもなく、クライアント７０である。これは、サーバ２１に対して仲介装置３０を単なるルータに見せるためである。また、送信元ＭＡＣアドレスも仲介装置３０ａでも仲介装置３０ｂでもない。従って、該パケットは、カーネルが提供している標準のＴＣＰ／ＩＰスタックを利用して通常のｓｏｃｋｅｔを使って送信することができない。そこで、内部ネットワーク側パケット送信部３４がイーサネットヘッダ、ＩＰヘッダ、ＵＤＰヘッダを作成しｒａｗ  ｓｏｃｋｅｔを使ってサーバ２１へ送信する。
【００４９】
複数の仲介装置が正常稼働している場合、サーバは正常稼働している仲介装置の数の、図８に示すパケットを受信することになる。全てのパケットは全く同じであるため、最初の一つだけを処理し残りのパケットはサーバで捨てる必要がある。例えば、ＲＡＤＩＵＳのようにＵＤＰを使ったアプリケーションの場合、重複して複数の同じパケットを受信する可能性があるため、二つ目以降の重複パケットを捨てる機能は通常は元々持っている。従って、既に上記不必要なパケットを捨てる機能は実装済みであり、本発明のためにサーバを改造する必要はない。
【００５０】
次に、外部ネットワーク側でのパケット送受信処理について説明する。外部ネットワーク８２で行われる通信は、クライアント７０と仮想サーバ１１間の通信である。
【００５１】
まず、通信に先立って、クライアント７０は仮想ＩＰアドレス１９２．１６８．３．１００に対するＭＡＣアドレスを知る必要があるため、クライアント７０は、ＡＲＰ要求パケットをブロードキャストする。前述のように、実際には、仮想ＩＰアドレス１９２．１６８．３．１００を持った通信機器は存在しないため、通常はアドレス解決されず、クライアント７０は通信を行えないという問題が発生する。この問題を避けるために、外部ネットワーク側パケット受信部３５はＮＩＣ３２をｐｒｏｍｉｓｃｕｏｕｓ  ｍｏｄｅ（ＮＩＣに到着する全てのパケットを受信するモード）に設定することでリピータハブ８４に到着する全てのパケットをｒａｗｓｏｃｋｅｔで受信できるようにし、受信したパケットのうち仮想ＩＰアドレス１９２．１６８．３．１００のＡＲＰ要求パケットを、外部ネットワーク側擬似ＡＲＰ応答部４４へ渡す。同じネットワークに接続されている機器のＭＡＣアドレスと重複しないようにあらかじめ選んだ仮想ＭＡＣアドレスを擬似ＡＲＰ応答部４４は返送する。全ての疑似ＡＲＰ応答部４４は同じ仮想ＭＡＣアドレスを返すように設定しておかなければならない。この例では、疑似ＡＲＰ応答部４４ａと４４ｂは、仲介装置３０、クライアント７０のＭＡＣアドレスと重複しないａａ：ａａ：ａａ：ａａ：ａａ：００を含んだＡＲＰ応答パケットを返す。複数の仲介装置が正常稼動している場合は、複数のＡＲＰ応答パケットがクライアント７０へ返されるが、同じ内容のパケットなので問題ない。このようにして、仮想ＩＰアドレスに対するアドレス解決が実現され、クライアント７０は仮想サーバ１１宛にパケット送信可能となる。
【００５２】
なお、上記ＮＩＣをｐｒｏｍｉｓｃｕｏｕｓ  ｍｏｄｅに設定し、フィルタ（必要なパケットだけｒａｗ  ｓｏｃｋｅｔで受信する）を行うには、カーネルが提供しているＴＣＰ／ＩＰスタックを使わずに、データリンク層からアプリケーション層へパケットを取り込むライブラリｌｉｂｐｃａｐ（ｆｔｐ：／／ｆｔｐ．ｅｅ．ｌｂｌ．ｇｏｖ／ｌｉｂｐｃａｐ．ｔａｒ．Ｚ）を使うのが便利である。
【００５３】
次に、外部ネットワーク８２における仲介装置３０の要求パケット受信処理について説明する。図９に外部ネットワーク８２を経由して仮想サーバ１１へやってくるパケットフォーマットを例示する。図９の例では、クライアント７０から仮想サーバ１１へ送信されたパケットのフォーマットである。
【００５４】
図９に示すように、該パケットの送信先ＭＡＣアドレスは仲介装置３０ａのものでも仲介装置３０ｂのものでもない。そこで、上記のごとく外部ネットワーク側パケット受信部３５はｌｉｂｐｃａｐを使いパケットを受信する。宛先ＩＰアドレスが仮想サーバ１１の場合、サーバ制御部４１へ渡す。なお、この動作は外部ネットワーク側パケット受信部３５ａも外部ネットワーク側パケット受信部３５ｂも並行して同時に行う。
【００５５】
次に、外部ネットワーク８２における仲介装置３０の応答パケット送信処理について説明する。図１０に仮想サーバ３０から外部ネットワーク８２を経由してクライアント７０へ送信されるパケットのフォーマットを例示する。図１０の例では、仲介装置３０（仲介装置３０ａと伸介装置３０ｂともに）からクライアント７０へ送信されるパケットのフォーマットである。
【００５６】
図１０に示すように、送信元ＭＡＣアドレスも仲介装置３０ａでも仲介装置３０ｂでもない。従って、該パケットは、カーネルが提供している標準のＴＣＰ／ＩＰスタックを利用して通常のｓｏｃｋｅｔを使って送信することができない。そこで、外部ネットワーク側パケット送信部３６がイーサネットヘッダ、ＩＰへッダ、ＵＤＰヘッダを作成しｒａｗ  ｓｏｃｋｅｔを使ってクライアント７０へ送信する。
【００５７】
複数の仲介装置が正常稼働している場合、クライアントは正常稼働している仲介装置の数の、図１０に示すパケットを受信することになる。全てのパケットは全く同じであるため、最初の一つだけを処理し、残りのパケットはクライアントで捨てる必要がある。例えば、ＲＡＤＩＵＳのようにＵＤＰを使ったアプリケーションの場合、重複して複数の同じパケットを受信する可能性があるため、二つ目以降の重複パケットを捨てる機能は通常は元々持っている。従って、既に上記不必要なパケットを捨てる機能は実装済みであり、本発明のためにクライアントを改造する必要はない。
【００５８】
次に、サーバ制御部４１の動作について図面を参照して説明する。なお、例として取り上げる高信頼性サーバシステムの構成と各装置は、図１に示したような状態であるとする。図１１はサーバ制御部４１の動作を説明するフローチャートである。また、図１２及び図１３は、高信頼性サーバシステム１０の動作を説明する図である。
【００５９】
サーバ制御部４１は、クライアント７０からの要求パケットを外部ネットワーク側パケット受信部３５が受信したかどうかをチェックし（ステップＳＡ１）、要求パケットが無かった場合、再び要求パケット受信をチェックする。要求パケットがあった場合、サーバ管理表４２で稼働状態が「正常」となっているサーバへ内部ネットワーク側パケット送信部３４を用いて該要求パケットを送信する（ステップＳＡ２）。以上の処理によりクライアントからの要求の流れを図１２の太線矢印で示す。
【００６０】
次に、タイマを設定して各サーバからの応答パケットをチェックする（ステップＳＡ３）。タイムアウトではない場合、サーバからの応答パケットを内部ネットワーク側パケット受信部３３が受信したかどうかをチェックする（ステップＳＡ４）。サーバからの応答パケットを受信しなかった場合、再びタイムアウトのチェックを行う（ステップＳＡ３）。サーバからの応答パケットを受信した場合、前記要求パケットの宛先サーバの全てから応答パケットを受信したかどうかをチェックする（ステップＳＡ５）。全ての応答パケットが揃ってない場合、再びタイムアウトのチェックを行う（ステップＳＡ３）。
【００６１】
全ての応答パケットが揃った場合、障害になったサーバがあるかどうかをチェックする（ステップＳＡ６）。障害になったサーバがあるかどうかを判断する方法としては、例えば、複数の応答で多数決を行う方法や、応答に含まれるデータの正当性をチェックする方法などが挙げられる。後者のデータ正当性のチェックの方法としては、例えば、有り得ないコードが含まれている場合には、障害と判断する、有るはずのコードが含まれていない場合には、障害と判断する、などが挙げられる。障害になったサーバがある場合、サーバ管理表４２に、該当するサーバの稼働状態を「障害」と登録する（ステップＳＡ７）。その後に、正常な応答パケットを外部ネットワーク側パケット送信部３６を用いてクライアント７０へ送信する（ステップＳＡ８）。
【００６２】
前記ステップＳＡ６において障害になったサーバがない場合、正常な応答パケットを外部ネットワーク側パケット送信部３６を用いてクライアント７０へ送信する（ステップＳＡ８）。
【００６３】
また、前記ステップＳＡ３においてタイムアウトになった場合、すなわち応答パケットを返さないサーバが存在する場合、当該サーバは障害であると判断し、サーバ管理表４２に、該当するサーバの稼働状態を「障害」と登録し（ステップＳＡ９）、他に障害になったサーバがあるかどうかをチェックする（ステップＳＡ６）。そして、正常な応答パケットを外部ネットワーク側パケット送信部３６を用いてクライアント７０へ送信する（ステップＳＡ８）。
【００６４】
応答パケットをクライアント７０へ送信した（ステップＳＡ８）後は、再びクライアント７０からの要求をチェックする（ステップＳＡ１）。以上の処理によるサーバからクライアント７０への応答パケットの流れを図１３の太線矢印で示す。また、サーバ２３が障害となった場合のサーバ管理表４２は、前述したように図６に示すようなものとなる。
【００６５】
以上のような処理により、高信頼性サーバ２０を構成する各サーバ２１、２２、２３のうち「障害」となったサーバへは、クライアント７０からの要求パケットは転送されず、高信頼性サーバシステム１０から切り離されたことになる。
【００６６】
仲介装置３０ａ、３０ｂは、お互いを意識せずに、独立に動作する、そのため、もし、どちらかの仲介装置が障害となったとしても、もう一方の仲介装置に影響を与えない。例えば、仲介装置３０ａが障害となってダウンした場合、仲介装置３０ａの生死を知ることなく、仲介装置３０ｂは上述の仮想サーバ、仮想ルータの動作を継続する。
【００６７】
同じように、仲介装置が障害から復旧したとしても、もう一方の仲介装置に影響を与えない。例えば、障害でダウンしていた仲介装置３０ａが復旧して上述の仮想サーバ、仮想ルータの動作を開始したとしても、仲介装置３０ａの生死を知ることなく仲介装置３０ｂは上述の仮想サーバ、仮想ルータの動作を継続する。
【００６８】
上記のように仲介装置３０ａと３０ｂが同じ処理を並行して独立に実行するためには、仲介装置３０ａと３０ｂに全く同じパケットが送られなければならないという条件を満たすしくみが必要である。しかし、クライアント７０は仮想サーバ１１宛に一つのパケットのみ、サーバ２１、２２、２３は仮想ルータ３７宛に一つのパケットのみしか送信しないため、通常では上記条件を満たせない。本実施例ではリピータハブ８３、８４とｐｒｏｍｉｓｃｕｏｕｓ  ｍｏｄｅにしたＮＩＣ３１、３２を組み合わせることで上記条件を満たしている。つまり、リピータハブは全てのポートに全てのパケットを送信するという特徴と、ｐｒｏｍｉｓｃｕｏｕｓ  ｍｏｄｅにしたＮＩＣはポートに到達した全てのパケットを受信するという特徴とを組み合わせて上記条件を実現している。
【００６９】
よって、本実施例では、リピータハブの代わりに、例えば、単純にスイッチングハブに置き換えることはできない。まし、リピータハブを使用できない場合は、別途、パケットをコピーし全ての仲介装置へ転送する手段が必要となる。
【００７０】
本発明の第二の実施形態に係る高信頼性サーバシステムについて図面を参照して説明する。図１４は、第二の実施形態に係る高信頼性サーバシステムの全体構成を説明するブロック図である。
【００７１】
本実施形態が第一の実施形態と異なる点は、３つの仲介装置３０を備えている点にある。しかし、仲介装置３０はお互いを意識せずに動作するので、２つであろうと３つであろうと、あるいはそれ以上であろうと動作は変わらない。
【００７２】
異なる点は、サーバが受け取るパケットの数とクライアントが受け取るパケットの数である。第一の実施形態では、仲介装置３０は２つだったので、最大で２つの同じパケットを受信するので、２つ目は破棄する必要があった。第二の実施形態では、仲介装置３０は３つなので、最大３つの同じパケットを受信することになる。従って、サーバ及びクライアントは２つ目、３つ目のパケットを破棄する必要がある。
【００７３】
本発明の第三の実施形態に係る高信頼性サーバシステムについて図面を参照して説明する。図１５は第三の実施形態に係るパケット制御部４５を説明するブロック図である。
【００７４】
本実施形態が第一及び第二の実施形態と異なる点は、パケット制御部にサーバ管理表修正部４６を備えている点にある。これに伴い、以下の動作が追加される。
【００７５】
サーバ管理表修正部４６の動作について、図１６を参照して説明する。図１６は、サーバ管理表修正部４６の動作を説明するフローである。
【００７６】
まず、サーバ管理表修正部４６は自分自身が管理するサーバ管理表４２の内容を外部ネットワーク側パケット送信部３６を使って仮想サーバ１１宛に送信する（ステップＳＢ１）。次に、サーバ管理表修正部４６は外部ネットワーク側パケット受信部３５を使って転送されてきたサーバ管理表４２を受信する（ステップＳＢ２）。こうして受信したサーバ管理表４２の情報を比較し、同じかどうかを判定する（ステップＳＢ３）。
【００７７】
同じであった場合（ステップＳＢ３のＹＥＳ）、何もせず一定期間スリープした後（ステップＳＢ５）、再び自分自身が管理するサーバ管理表４２の内容を外部ネットワーク側パケット送信部３６を使って仮想サーバ１１宛に送信する（ステップＳＢ１）。
【００７８】
同じでなかった場合（ステップＳＢ３のＮＯ）、何らかのアルゴリズムで自分自身が管理するサーバ管理表４２を修正する（ステップＳＢ４）。例えば、「正常」と「障害」というように稼働状態が異なる場合、「障害」が正しい状態と判断し「正常」から「障害」へ修正する。または、多数決で決定しても良い。「障害」に変更されたサーバは、システムから切り離され、以後、クライアントからの要求を転送しない。修正後、一定期間スリープした後（ステップＳＢ５）、再び自分自身が管理するサーバ管理表４２の内容を外部ネットワーク側パケット送信部３６を使って仮想サーバ１１宛に送信する（ステップＳＢ１）。
【００７９】
このようにして、互いに独立に動作している仲介装置３０間で、何らかの原因で状態が不一致になった場合、サーバ管理表４２を修正することができる。
【００８０】
本発明の第四の実施形態に係る高信頼性サーバシステムについて図面を参照して説明する。図１７は第四の実施形態に係る高信頼性サーバシステム１００の全体構成を説明するブロック図、図１８は第四の実施形態に係るパケット制御部４００を説明するブロック図である。
【００８１】
本実施形態が第一の実施形態と異なる点は、内部ネットワーク８１が存在せず、高信頼性サーバ２０と仲介装置３００ともに同一のネットワーク８２０に接続されていることである。
【００８２】
これに伴い、仲介装置３００は内部ネットワーク側パケット受信部３３と外部ネットワーク側パケット受信部３５を合わせ持ったパケット受信部３５０を備え、内部ネットワーク側パケット送信部３４と外部ネットワーク側パケット送信部３６を合わせ持ったパケット送信部３６０を備える。また、パケット制御部４００は、内部ネットワーク側疑似ＡＲＰ応答部４３と外部ネットワーク側疑似ＡＲＰ応答部４４を合わせ持った疑似ＡＲＰ応答部４４０を備える。
【００８３】
上記のごとく、内部ネットワーク８１を無くすことで高信頼性サーバシステムの構成ブロック図は変わるが、ネットワーク８２０を論理的に外部ネットワーク８２と内部ネットワーク８１に分けて考えれば、第一の実施形態と同じである。
【００８４】
なお、各サーバは同じ応答を返すならば同じ実装である必要はない。すなわち、バージョン、仕様、プログラム言語、コンパイラの種類、コンパイラオプション、ハードウェアかソフトウェアか、などが異なっていても良い。さらに、サーバは一つの部品で構成されていても複数の部品で構成されていても良い。
【００８５】
また、上記実施形態では、パケット送受信部、制御部、サーバ管理表、擬似ＡＲＰ応答部、サーバ管理表修正部を一つの仲介装置に実装し、サーバは別の装置で実装しているが、高信頼性サーバシステムの各構成要素の物理的位置関係は任意である。すなわち、例えば、各構成要素を一つのコンピュータ上に実装しても良いし、異なるコンピュータ上にばらばらに実装しても良い。また、一部を同一のコンピュータに実装しても良い。
【００８６】
さらに、上記実施例では、サーバが３つの例を示しているが、サーバは３つ以上あっても良い。また、サーバ障害に対する信頼性の低下が許されるのであれば、サーバは３つ以下であっても良い。
【００８７】
さらに、上記実施形態では、クライアントが一つの場合を想定しているが、クライアントが複数あっても良い。
【００８８】
さらに、第一の実施例では、仮想サーバ１１の仮想ＩＰアドレスと仮想ＭＡＣアドレスは、外部ネットワーク８２に接続されている通信機器（仲介装置３０も含む）が持っていないものを選んだが、いづれか一つの仲介装置３０のＮＩＣ３２のＩＰアドレスを仮想ＩＰアドレスとして選んでも良いし、いづれか一つの仲介装置３０のＮＩＣ３２のＭＡＣアドレスを仮想ＭＡＣアドレスとして選んでも良い。ただし、重要なことは、全ての仲介装置３０で、仮想ＩＰアドレスのＡＲＰ要求に対するＡＲＰ応答は同じものを返さなければならない。
【００８９】
さらに、第一の実施例では、仮想ルータ３７の仮想ＩＰアドレスと仮想ＭＡＣアドレスは、内部ネットワーク８１に接続されている通信機器（仲介装置３０も含む）が持っていないものを選んだが、いづれか一つの仲介装置３０のＮＩＣ３１のＩＰアドレスを仮想ＩＰアドレスとして選んでも良いし、いづれか一つの仲介装置３０のＮＩＣ３１のＭＡＣアドレスを仮想ＭＡＣアドレスとして選んでも良い。ただし、重要なことは、全ての仲介装置３０で、仮想ＩＰアドレスのＡＲＰ要求に対するＡＲＰ応答は同じものを返さなければならない。
【００９０】
なお、上記実施形態は例示的なものであり、本発明はこれに限定されるものではない。本発明の範囲は特許請求の範囲によって示されており、この特許請求の範囲の意味に入る全ての変形例は本発明に含まれるものである。
【００９１】
【発明の効果】
以上説明したように、本発明によれば、クライアント・サーバ間の要求及び応答を転送している一の仲介装置が障害となっても、他の正常な仲介装置によって転送を継続できるので、システム全体のダウンを防ぎ、より高信頼なクライアントサーバ型システムを構築できる。また、仮想アドレスをあらかじめ決めているので、どの仲介装置もこれらの仮想アドレス宛の要求と応答を処理できるようにしている。従って、障害等により仲介装置がｄｏｗｎしても、サーバやクライアントは何の変更も必要ない。すなわち、既存のサーバやクライアントを無改造で利用できるので、高信頼なクライアントサーバ型システムを低コストで構築することができる。
【図面の簡単な説明】
【図１】第一の実施形態に係る高信頼性サーバシステムの全体構成を説明するブロック図
【図２】クライアントから仲介装置を見た場合のシステムの見え方を示した図
【図３】サーバから仲介装置を見た場合のシステムの見え方を示した図
【図４】仲介装置の構成を説明するブロック図
【図５】サーバ管理表の一例を説明する図
【図６】サーバ管理表の他の一例を説明する図
【図７】パケットのフォーマットを説明する図
【図８】パケットのフォーマットを説明する図
【図９】パケットのフォーマットを説明する図
【図１０】パケットのフォーマットを説明する図
【図１１】仲介装置の動作を説明する図
【図１２】クライアントからの要求の流れを説明する図
【図１３】サーバからの応答の流れを説明する図
【図１４】第二の実施形態に係る高信頼性サーバシステムの全体構成を説明するブロック図
【図１５】第三の実施形態に係るパケット制御部４５を説明するブロック図
【図１６】第三の実施形態に係るサーバ管理表修正部の動作を説明する図
【図１７】第四の実施形態に係る高信頼性サーバシステムの全体構成を説明するブロック図
【図１８】第四の実施形態に係るパケット制御部を説明するブロック図
【図１９】従来の高信頼性サーバシステムの構成図
【符号の説明】
１０…高信頼性サーバシステム、１１…仮想サーバ、２０…高信頼性サーバ、２１、２２、２３…サーバ、３０ａ、３０ｂ、３０ｃ、３００ａ、３００ｂ…仲介装置、３１ａ、３１ｂ、３２ａ、３２ｂ…ＮＩＣ、３３ａ、３３ｂ…内部ネットワーク側パケット受信部、３４ａ、３４ｂ…内部ネットワーク側パケット送信部、３５ａ、３５ｂ…外部ネットワーク側パケット受信部、３５０ａ、３５０ｂ…パケット受信部、３６ａ、３６ｂ…外部ネットワーク側パケット送信部、３６０ａ、３６０ｂ…パケット送信部、３７…仮想ルータ、４０ａ、４０ｂ、４００ａ、４００ｂ…パケット制御部、４１…サーバ制御部、４２…サーバ管理表、４３…内部ネットワーク側擬似ＡＲＰ応答受信部、４４…外部ネットワーク側擬似ＡＲＰ応答受信部、４６…サーバ管理表修正部、７０…クライアント、８１…内部ネットワーク、８２…外部ネットワーク、８２０…ネットワーク、８３、８４…リピータＨＵＢ、９１、９２、９３…コンピュータ、１０１０…高信頼性サーバシステム、１１１１、１１１２、１１１３…コピー、１０２０…高信頼性サーバ、１０２１、１０２２、１０２３…サーバ、１０３０…仲介装置、１０３１…制御部、１０３２…サーバ管理表、１０４１…クライアント、１０５０…ネットワーク。
【図１】
2004227534.tif 000003
【図２】
2004227534.tif 000004
【図３】
2004227534.tif 000005
【図４】
2004227534.tif 000006
【図５】
2004227534.tif 000007
【図６】
2004227534.tif 000008
【図７】
2004227534.tif 000009
【図８】
2004227534.tif 000010
【図９】
2004227534.tif 000011
【図１０】
2004227534.tif 000012
【図１１】
2004227534.tif 000013
【図１２】
2004227534.tif 000014
【図１３】
2004227534.tif 000015
【図１４】
2004227534.tif 000016
【図１５】
2004227534.tif 000017
【図１６】
2004227534.tif 000018
【図１７】
2004227534.tif 000019
【図１８】
2004227534.tif 000020
【図１９】
2004227534.tif 000021