JP2006253900A - Ｉｐアドレス引き継ぎ方法、ｉｐアドレスアドレス引き継ぎプログラム、サーバおよびネットワークシステム - Google Patents

Abstract

【課題】 同じサービスを提供するサーバに、同じＩＰアドレスが重複割り当てされないようにする。
【解決手段】 待機モードのサーバが、所定期間、実行モードのサーバからハートビート通信のメッセージを受信しなかったとき、待機モードのサーバの記憶装置に記憶されたＩＰアドレスを自己のサーバに割り当て、実行モードに切り替える。このとき、自己のサーバに割り当てたＩＰアドレスと、自己のサーバのＭＡＣアドレスとを含むメッセージを、ブロードキャスト形式で、所定期間送信する。また、実行モードのサーバが、自己のサーバに割り当てられたＩＰアドレスと同じＩＰアドレスと、待機モードのサーバのＭＡＣアドレスとを含むメッセージを受信したとき、自己のサーバに割り当てられていたＩＰアドレスを削除し、待機モードに切り替えるステップを実行する。
【選択図】 図２

Description

本発明は、ＩＰアドレス引き継ぎ方法、ＩＰアドレスアドレス引き継ぎプログラム、サーバおよびネットワークシステムに関する。

コンピュータを接続して構成されるネットワークシステムにおいて、クライアント・サーバモデルに基づいて分散処理を行う際に、システムの可用性を確保するために、同じサービスを提供できるサーバコンピュータをネットワークシステム内に複数台備える構成が採用されている。
この場合、複数台のサーバコンピュータのうち１台が実行系サーバとして動作し、他は待機系のサーバとなっている。

このような高可用性システムが、インターネットプロトコル（ＩＰ）を用いたネットワークにより実現されている場合、クライアントの立場からは、同じサービスを提供するサーバコンピュータには同じＩＰアドレスが割り当てられていることが望ましい。

しかし、ＩＰアドレスが或る時点において重複して割り当てられ、１つのＩＰアドレスに対して複数のＭＡＣアドレス（Media Access Control Address）が対応すると、送信元は、どのＭＡＣアドレスを指定してパケットを送るべきかが決定できない。

そこで、従来の高可用性ネットワークシステムでは、ネットワークに接続され同一のサービスを提供できるサーバコンピュータのうち、実行系サーバ（実行モードのサーバコンピュータ）にはＩＰアドレスを割り当てるが、待機系サーバ（待機モードのサーバコンピュータ）にはＩＰアドレスを割り当てないようにしている。

ここで、待機系サーバは、ハートビート通信（相手側コンピュータの状態を確認するための定期的なメッセージ交換）を行い、実行系サーバのシステムダウンや通信不能等を検出すると、実行系サーバに割り当てられていたＩＰアドレスを引き継いで自己のＩＰアドレスとして設定する。
その後、待機系サーバは、自己のＩＰアドレスとＭＡＣアドレスとを設定したＡＲＰ（Address Resolution Protocol）リクエストをブロードキャスト形式で送信し、これを受けたクライアントは、受信したＡＲＰリクエストに基づき、ＡＲＰキャッシュにおけるＩＰアドレスとＭＡＣアドレスとの対応を更新する。

以後、待機系サーバは、サービスを提供するためのアプリケーションプロセスを起動し、実行系サーバとして動作するようになり、クライアントは実行系サーバ（元待機系サーバ）に対して各種データを要求し、サービスの提供を受ける。このようにしてサーバ切り替え（ＩＰアドレス引き継ぎ）が行われる。

特許文献１には、前記したサーバ切り替え方法において、実行モードと待機モードとの切り替えを短時間で行うための技術が開示されている。
特開平１０−３２０３２３号公報

しかし、前記した技術はいずれも、ハートビート用通信路の障害や遅延により、相手方のサーバの動作状態が把握できなかった場合の考慮がなされていない。つまり、ハートビート用通信路に障害や遅延が発生したが、サーバ自体には障害が発生していないとき、それぞれのサーバが「実行モードに遷移すべき」と判断して、実行系サーバと待機系サーバとにＩＰアドレスが重複して割り当てられてしまうという問題がある。

本発明は、同じサービスを提供できる複数のサーバを有し、高可用性を確保するネットワークシステムにおいて、ハートビート通信による互いの動作状態が確認できない場合でも、ＩＰアドレスが重複して割り当てられることなくサーバ切り替えを行うことができるＩＰアドレスの引き継ぎ方法等を提供することを課題とする。

前記した課題を解決するため、本発明は、ネットワークを介してサービスを提供する実行モードのサーバと、このサーバに障害が発生したとき、このサーバのＩＰアドレスを引き継ぎ実行モードに切り替わる１以上の待機モードのサーバとを含むネットワークシステムにおいて、前記待機モードのサーバが、所定期間、前記実行モードのサーバからハートビート通信のメッセージを受信しなかったとき、前記待機モードのサーバの記憶装置に記憶されたＩＰアドレスを自己のサーバに割り当て、実行モードに切り替えるステップと、前記自己のサーバに割り当てたＩＰアドレスと、自己のサーバのＭＡＣアドレスとを含むメッセージを、ブロードキャスト形式で、所定期間送信するステップとを実行するようにした。
一方、前記実行モードのサーバは、自己のサーバに割り当てられたＩＰアドレスと同じＩＰアドレスと、前記待機モードのサーバのＭＡＣアドレスとを含むメッセージを受信したとき、前記自己のサーバに割り当てられていたＩＰアドレスを削除し、待機モードに切り替えるステップを実行する構成とした。
その他の構成については、後記する実施の形態で述べる。

本発明によれば、ハートビート用通信路の障害等で互いの動作状態が確認できない場合でも、同じサービスを提供できるサーバのうち、いずれか１つのサーバにＩＰアドレスが割り当てられるので、複数のサーバに同じＩＰアドレスが重複して割り当てられることによるサービスの提供不可を防止できる。

以下、図面を参照しつつ、本発明を実施するための最良の形態（以下、実施の形態とする）について説明する。

図１は、本発明の実施の形態であるサーバコンピュータを用いて構築されたネットワークシステムのブロック図である。

このネットワークシステムでは、同じサービスを提供できる２台のサーバコンピュータ１（１Ａ,Ｂ）と、このサーバコンピュータ１（１Ａ,Ｂ）のいずれかに対してサービスの提供を要求するクライアントコンピュータ（クライアント）３とがローカルエリアネットワーク（ＬＡＮ）１３で接続された構成となっている。
なお、以下サーバコンピュータは、サーバと略す。

サーバ１（１Ａ,Ｂ）は、例えば、Ｗｅｂサーバやファイルサーバ等であり、クライアント３等のリクエストに応じてＬＡＮ１３経由で各種データの送信や配信等を行う。つまり、クライアント３へサービスを提供する。

ＬＡＮ１３は、サーバ１（１Ａ,Ｂ）およびクライアント３を接続するネットワークであり、例えばインターネット網や地域ＩＰ網であってもよい。
クライアント３は、サーバ１（１Ａ,Ｂ）から各種データの受信や配信を受ける端末装置であり、例えばＰＣ（Personal Computer）である。

サーバ１（１Ａ,Ｂ）は、ＣＰＵ（Central Processing Unit）４、メモリ５、ハードディスク装置（ＨＤ）６およびネットワークインタフェースコントローラ（ＮＩＣ）７,８で構成される。

ＮＩＣ７は、ハートビート用通信路１４に接続されるネットワークインタフェースの制御を行い、ＮＩＣ８は、ＬＡＮ１３に接続されるネットワークインタフェースの制御を行う。

サーバ１（１Ａ,Ｂ）のＣＰＵ４は、メモリ５に格納された所定のプログラムを実行することにより、ＬＡＮ１３に対する制御を含むオペレーティングシステム（ＯＳ）９の機能、監視プロセス１１およびＩＰアドレス割り当てプロセス１５の機能を実現する。
また、前記所定のプログラムは、クライアント３に各種サービスを提供するアプリケーションプロセス（図示せず）を実現している。

また、このネットワークシステムでは、インターネットプロトコル（ＩＰ）を用いた通信が行われ、通信相手を特定するためのＩＰアドレスに対応するＭＡＣアドレス（サーバ１の識別情報）を獲得するためにＡＲＰが使用される。ＯＳ９には、ＡＲＰリクエストの送信および受信、ＡＲＰリプライの送信および受信等、ＡＲＰに関する各種処理を行うＡＲＰハンドラ１０が含まれる。
なお、ＩＰアドレス引き継ぎプログラムは、前記したＡＲＰハンドラ１０、監視プロセス１１およびＩＰアドレス割り当てプロセス１５により実現される。

ＩＰアドレス割り当てプロセス１５は、自己のサーバ１（１Ａ,Ｂ）に対するＩＰアドレスの割り当ておよびＩＰアドレス削除を行う。
監視プロセス１１は、ハートビート用通信路１４経由でサーバ１（１Ａ,Ｂ）とハートビート通信を行い、相手方となるサーバ１（１Ａ,Ｂ）の動作状態を監視する。そして、所定期間、相手方のサーバ１（１Ａ,Ｂ）からハートビート通信のメッセージを受信しなかったとき、ＩＰアドレス割り当てプロセス１５に自己のサーバ１（１Ａ,Ｂ）に対しＩＰアドレスを割り当てさせる。
つまり、所定期間、相手方のサーバ１（１Ａ,Ｂ）からハートビート通信のメッセージを受信しなかったとき、相手方のサーバ１（１Ａ,Ｂ）に障害が発生したとみなして、自己のサーバ１（１Ａ,Ｂ）を実行モードに遷移させる。
なお、本実施の形態において、サーバ１を「実行モードに遷移させる」とは、サーバ１にＩＰアドレスを割り当て、クライアント３からの要求に応じてＬＡＮ１３経由で各種データを送信可能な状態にすることをいう。一方、サーバ１を「待機モードに遷移させる」とは、サーバ１からＩＰアドレスを削除し、クライアント３へのデータ送信を行なわない（サービスを提供しない）状態にすることをいう。

また、監視プロセス１１は、サーバ１（１Ａ,Ｂ）が実行モードに遷移したとき、相手方のサーバ１（１Ａ,Ｂ）の動作状態が確認できるまでＡＲＰハンドラ１０にＬＡＮ１３経由でＡＲＰリクエストを送信させる。つまり、相手のサーバ１（１Ａ,Ｂ）に自己のサーバ１（１Ａ,Ｂ）が実行モードに遷移したことを通知する。
また、監視プロセス１１は、ＡＲＰハンドラ１０で相手方のサーバ１（１Ａ,Ｂ）からのＡＲＰリクエストを受信したときは、ＩＰアドレス割り当てプロセス１５に自己のサーバ１（１Ａ,Ｂ）のＩＰアドレス削除を行わせる。すなわち、相手方のサーバ１（１Ａ,Ｂ）が実行モードに遷移したことを確認して、自己のサーバ１（１Ａ,Ｂ）を待機モードに遷移させる。

ＨＤ６（またはメモリ５）は、サーバ１（１Ａ,Ｂ）に設定されるＩＰアドレスと、ハートビート通信を行う相手のサーバ１（１Ｂ）のＭＡＣアドレスとを記憶している。
なお、サーバ１（１Ａ,Ｂ）は同じサービスを提供するサーバであり、それぞれのＨＤ６（またはメモリ５）には同じＩＰアドレスが記憶されるものとする。このＩＰアドレスの入力は、ネットワークシステムの管理者がキーボードやマウス等により手動で入力してもよい。ＡＲＰハンドラ１０は、このＨＤ６（またはメモリ５）に記憶されたＩＰアドレスおよびＭＡＣアドレスを読み出してＡＲＰリクエストおよびＡＲＰリプライの送信を行う。また、ＡＲＰリクエストを受信したときには、このＨＤ６（またはメモリ５）を参照して、そのＡＲＰリクエストが同じサービスを提供するサーバ１、つまりハートビート通信のペアとなるサーバ１から送信されたものか否かを判断する。
ちなみに、ＨＤ６（またはメモリ５）は、請求項における記憶装置に相当する。

さらに、サーバ１（１Ａ,Ｂ）の間にはＬＡＮ１３とは別に両者を直接に接続するハートビート用通信路１４が設けられている。
サーバ１（１Ａ,Ｂ）は、このハートビート用通信路１４を用いて所定期間毎（例えば、１０分間以下の間隔で）にメッセージ交換し合う「ハートビート通信」を行うことにより、互いに相手の動作状態を把握する。
本実施の形態では、このハートビート用通信路１４は、ＬＡＮによって実現するものとするが、例えばＲＳ２３２Ｃ等のシリアル回線であってもよい。また、サーバ１（１Ａ）とサーバ１（１Ｂ）とにハードディスク等の外部記憶装置を共有させることにより実現してもよい。
ちなみに、このハートビート用通信路１４は、１本であってもよいし、複数本であってもよい。

一方、クライアント３は、ＡＲＰによってＩＰアドレスとＭＡＣアドレスとの対応情報を取得すると、クライアント３の記憶部（図示せず）のＡＲＰキャッシュ１２を更新する。このＡＲＰキャッシュ１２は、ＩＰアドレスごとに、当該ＩＰアドレスに対応するＭＡＣアドレスを示したテーブルである。
例えば、図１に示すクライアント３のＡＲＰキャッシュ１２は、ＩＰアドレス「１」のサーバ１は、「Ａ」というＭＡＣアドレスを持つことを示す。
なお、このクライアント３は、図１では１台しか描いていないが、複数台であってもよい。

ここでは、サーバ１Ａは、クライアント３に対してＬＡＮ１３経由でサービスを提供する「実行モード」のサーバであり、サーバ１Ｂは、サービスを提供することなく待機している「待機モード」のサーバであるものとして説明する。

本実施の形態のネットワークシステムにおいて、実行モードのサーバ１Ａがシステムダウン等によりサービスの提供ができなくなった場合には、待機モードのサーバ１Ｂは、これをハートビート通信によって認識し、実行モードへと遷移する。すなわち、サーバの動作モードの切り替えが行われる。
前記したネットワークシステムの各構成要素の詳細は、フローチャートを用いて後記する。

図２は、図１のサーバのＩＰアドレスの引き継ぎ方法（ＩＰアドレス引き継ぎプログラムの動作）を示すフローチャートである。
以下、適宜図１を参照しつつ、図２を用いて、サーバ１のＩＰアドレスの引き継ぎ方法について説明する。

まず、ステップＳ２１において、サーバ１に電源がＯＮされると、サーバ１は、ＯＳ９および監視プロセス１１を起動する。

そして、ステップＳ２２において、監視プロセス１１が自己の初期動作モードを決定する。これは、予めＨＤ６またはメモリ５に自己のサーバ１の初期動作モード（実行モード／待機モード）が記憶されており、監視プロセス１１が、この初期動作モードの情報を参照して決定する。

ここで、自己のサーバ１の動作モードが実行モードであれば（ステップＳ２３のＹＥＳ）、ステップＳ２４において監視プロセス１１は、ＩＰアドレス割り当てプロセス１５に自己のＩＰアドレスを割り当てさせ、ＡＲＰハンドラ１０にブロードキャストの形式でＡＲＰリクエストを送信させる。

なお、このステップＳ２４でＡＲＰリクエストを送信するのは、クライアント３等のＡＲＰキャッシュ１２におけるＩＰアドレスとＭＡＣアドレスとの対応を更新させる必要があるからである。その後、サーバ１は、アプリケーションプロセスを起動して、クライアント３等にサービスを提供する。

一方、ステップＳ２３において、自己のサーバ１の動作モードが待機モードの場合（ステップＳ２３のＮＯ）、ステップＳ２５に進み、監視プロセス１１が相手方のサーバ１とハートビート通信を行い、相手方のサーバ１の動作状態を監視する。また、このとき、サーバ１は自己のサーバ１にＩＰアドレスの割り当てを行わない。

ここで、サーバ１の監視プロセス１１が、他のサーバ１のハートビート未受信と判断したとき（ステップＳ２６のＹＥＳ）、つまりシステムダウンやハートビート用通信路１４の障害等により、相手方のサーバ１から所定時間ハートビート通信のメッセージを受信しなかったとき、ステップＳ２７において、自己のサーバ１が実行モードへ遷移すべきか否かを判定する。

具体的には、監視プロセス１１は、自己のサーバ１の動作モードが待機モードで、相手方のサーバ１の動作モードが実行モードの場合、自己が実行モードへ遷移すべきと判定する（ステップＳ２７のＹＥＳ）。

一方、自己のサーバ１の動作モードが実行モードの場合、監視プロセス１１は、実行モードへの遷移が不要と判定する（ステップＳ２７のＮＯ）。つまり、監視プロセス１１は、ステップＳ２５に戻り、相手方のサーバ１とハートビート通信を行い、アプリケーションプロセスによりクライアント３等にサービスを提供する。

ステップＳ２７において実行モードへ遷移すべきと判定された場合は（ステップＳ２７のＹＥＳ）、ステップＳ２８へ進んで自己のサーバ１を実行モードへと遷移させる。すなわち、監視プロセス１１は、ＩＰアドレス割り当てプロセス１５により自己のサーバ１にＩＰアドレスを割り当てる。また、ＡＲＰハンドラ１０が、ブロードキャスト形式でＡＲＰリクエストを送信して、ネットワーク内の各ノードに自己のサーバ１のＭＡＣアドレスを通知する。その後、サーバ１は、アプリケーションプロセスを起動してサービスを提供する。

なお、監視プロセス１１（またはＩＰアドレス割り当てプロセス１５）は、自己のサーバ１の実行モード／待機モードの切り替えを行ったとき、ＨＤ６またはメモリ５に現在サーバ１が実行モードか待機モードかを示す情報を記憶しておくものとする。

そして、サーバ１のＡＲＰハンドラ１０は、相手方のサーバ１の状態が確認できるまで、所定間隔でＬＡＮ１３を介してＡＲＰリクエストを送信する（ステップＳ２９）。
以降、ステップＳ２５およびステップＳ２６というループを繰り返し実行しつつ、実行モードのサーバ１は、起動したアプリケーションプロセスにより所定のサービスをクライアント３に提供する。

一方、サーバ１（１Ｂ）の監視プロセス１１は、ＡＲＰハンドラ１０でハートビート通信の相手方のサーバ１（１Ａ）からＡＲＰリクエストを受信したことを検知すると、ＩＰアドレス割り当てプロセス１５に自己のサーバ１を待機モードに切り替えさせる。つまり、自己のサーバ１（１Ｂ）からＩＰアドレスを削除する。すなわち、サーバ１（１Ｂ）はハートビート通信は継続するが、サービスの提供（クライアントからのデータ送信要求に応じたデータの送信）は停止する。

このようにすることで、ハートビート通信の障害や遅延等により、サーバ１（１Ａ,Ｂ）の双方にＩＰアドレスが重複して割り当てられたときでも、最初に、相手方のサーバ１からのＡＲＰリクエストを受信した方のサーバ１が、すぐに待機モードに切り替わるので、ＩＰアドレスの重複割り当てを一時的なものとすることができる。
よって、クライアント３からのサーバ１宛のパケットが、どちらのサーバ１（１Ａ,Ｂ）に送られるか特定されず、クライアント３がサーバ１（１Ａ,Ｂ）から正常なサービス提供を受けられなくなる可能性を低減することができる。

次に、図３を用いて、稼働中（実行モード）のサーバ１がＡＲＰリクエストを受信したときの動作を説明する。図３は、図１の実行モードのサーバがＡＲＰリクエストを受信したときの動作を示すフローチャートである。

まず、稼動中のサーバ１（１Ａ）は、ＡＲＰハンドラ１０でＡＲＰリクエストを受信すると、監視プロセス１１で、このＡＲＰリクエストの送信元が、ハートビート通信の相手方のサーバ１（１Ｂ）か否かを判断する（ステップＳ３１）。このときの判定は、監視プロセス１１が、ＨＤ６に記憶されたハートビート通信の相手方となるサーバ１（１Ｂ）のＭＡＣアドレスと、受信したＡＲＰリクエストの送信元のＭＡＣアドレスとを参照して行う。

ここで、サーバ１（１Ａ）が、ＡＲＰリクエストの送信元のＭＡＣアドレスを確認するのは、誤ってネットワークシステム外のノード（サーバ）に同じＩＰアドレスが割り当てられたときに、自己のサーバ１（１Ａ）が待機モードに遷移してしまうと、ネットワークシステムが継続してサービスを提供することができなくなるからである。

このとき、ＡＲＰリクエストの送信元が、ハートビート通信が不可能となった相手のサーバ１（１Ｂ）であったとき（ステップＳ３１のＹＥＳ）、ステップＳ３２へ進む。
そして、ステップＳ３２では、監視プロセス１１が、ＩＰアドレス割り当てプロセス１５により、自己のサーバ１（１Ａ）を待機モードへ遷移させ、自己のサーバ１（１Ａ）に割り当てたＩＰアドレスを削除して、ＩＰアドレス未割り当ての状態とする。
すなわち、サーバ１（１Ｂ）で動作モードの切り替えが行われ、サーバ１（１Ａ）に割り当てられていたＩＰアドレスが割り当てられた（引き継いだ）と、サーバ１（１Ａ）の監視プロセス１１が判断すると、自己のサーバ１（１Ａ）のアプリケーションプロセスを停止し、ＩＰアドレスを割り当てないようにする。
なお、このとき、ステップＳ３１で受信したＡＲＰリクエストに対するＡＲＰレスポンスは送信しないものとする。

このようにすることで、ハートビート通信が不能になった場合でも、サーバ１（１Ａ,Ｂ）の双方に同じＩＰアドレスが割り当てられたままの状態になるのを防ぐことができる。そして、ステップＳ３３において、サーバ１（１Ａ）の監視プロセス１１は、サーバ１（１Ｂ）に対し、自己のサーバ１（１Ａ）が待機モードに遷移してＩＰアドレスを削除したことを通知する。このときの通知は、ＬＡＮ１３またはハートビート用通信路１４を介して行うものとする。通知を受けたサーバ１（１Ｂ）は、サーバ１（１Ａ）の状態が確認できたため、最後にＡＲＰリクエストを送信することで、他のクライアント３のＡＲＰキャッシュ１２を更新させる。

これは、クライアント３がサーバ１（１Ａ）からＡＲＰリクエストを受信していたとき（既にＡＲＰキャッシュ１２にサーバ１（１Ａ）のＭＡＣアドレスが記憶されていたとき）も、確実にＡＲＰキャッシュ１２にサーバ１（１Ａ）のＭＡＣアドレスを設定するためである。そして、監視プロセス１１は、ＡＲＰハンドラ１０に所定間隔で送信させていたＡＲＰリクエストの送信を止めるようにする。

一方、ステップＳ３１において、サーバ１（１Ａ）が受信したＡＲＰリクエストの送信元が、相手方のサーバ１（１Ｂ）でない場合は（ステップＳ３１のＮＯ）、ステップＳ３４へ進む。つまり、受信したＡＲＰリクエストの送信元のＭＡＣアドレスが、ハートビート通信の相手のサーバ１（１Ｂ）のＭＡＣアドレスとは異なる場合は、ステップＳ３４へ進む。

ステップＳ３４では、サーバ１（１Ａ）の監視プロセス１１が、ＩＰアドレス重複のエラーメッセージを出力する。このときのエラーメッセージは、サーバ１（１Ａ）のモニタ等の表示手段に出力するようにしてもよいし、メール等で通知するようにしてもよい。
このようにすることで、ネットワークシステムの管理者は、他のノードが誤ってサーバ１（１Ａ,Ｂ）と同じＩＰアドレスを設定したことや、ＩＰアドレスが不正使用されたことを知ることができる。

ステップＳ３５では、サーバ１（１Ａ）のＡＲＰハンドラ１０は、受信したＡＲＰリクエストの送信元のノードに、自己のＩＰアドレスおよびＭＡＣアドレスを設定したＡＲＰリプライを応答し、前記送信元のノードにＩＰアドレスの重複割り当てを通知する。また、サーバ１（１Ａ）のＡＲＰハンドラ１０は、自己のサーバ１（１Ａ）のＭＡＣアドレスを設定したＡＲＰリクエストをブロードキャスト送信し、クライアント３のＡＲＰキャッシュ１２における当該ＩＰアドレスに対するＭＡＣアドレスを、サーバ１（１Ａ）のものに更新させる。
このようにすることで、ＡＲＰキャッシュ１２に他のノードのＭＡＣアドレスが設定されることを防止することができる。つまり、ネットワークトラフィックが混乱するのを防止できる。

以上の説明したように、待機モードのサーバ１（１Ｂ）は、他のサーバ１（１Ａ）とのハートビート通信不能を検出した場合は、動作モードを実行モードに切り替えて、ＩＰアドレスを設定する。つまり、サーバ１（１Ａ）に設定されていたＩＰアドレスを引き継ぐようにする。また、このとき、サーバ１（１Ｂ）は、他のサーバ１（１Ａ）の状態が確認できるまで、ブロードキャストの形式でＡＲＰリクエストを送信し、サーバ１（１Ａ）が、他のサーバ１（１Ｂ）からのＡＲＰリクエストを受信したときに、待機モードへの切り替えをするので、ハートビート用通信路１４の障害等で互いサーバ１（１Ａ,Ｂ）の動作状態が分からない場合でも、同じＩＰアドレスが重複して割り当てられることがなくなる。

また、サーバ１（１Ａ,Ｂ）の間で、実行モード（稼動サーバ）の切り替えがあった場合でも、クライアント３は、同じＩＰアドレスを設定してサーバ１にアクセスすればよいので、サーバ１の切り替えは透過的なものとすることができる。

前記した実施の形態では、待機モードのサーバ１（１Ｂ）が、ＩＰアドレスを引き継ぎ、サービスを継続するものとして説明したが、事前に定義した優先度に基づき実行モードのサーバ１（１Ａ）がサービスを継続するようにしてもよい。

つまり、図２のステップＳ２７において、自己のサーバ１が既に実行モードであった場合でも、監視プロセス１１が自己のサーバ１の優先度と相手方のサーバ１の優先度とを比較して、自己のサーバ１の優先度が高ければ、ステップＳ２９およびステップＳ２８を実行する。
一方、実行モードのサーバ１が、他のサーバ１のハートビート未受信と判断し、かつ監視プロセス１１が自己のサーバ１の優先度と相手方のサーバ１の優先度とを比較して、自己のサーバ１の優先度が低いと判断したときは、待機モードに切り替える。つまり、ステップＳ３２と同様にＩＰアドレスを削除し、ステップＳ３３と同様に待機モードに遷移したことを通知する。

なお、このときの優先度比較は、監視プロセス１１が、ＨＤ６またはメモリ５に記憶されたサーバ１（１Ａ,Ｂ）の優先度を示す優先度テーブルを参照して行う。
以下の表１は、サーバ１（１Ａ）の優先度テーブルの例である。

表１に示すように、優先度テーブルは、ハートビート通信を行うサーバ１（１Ａ,Ｂ）のＩＰアドレス、ＭＡＣアドレス、実行モードに切り替えるときの優先度に関する項目で構成される。
なお、この優先度テーブルは、サーバ１（１Ａ,Ｂ）の現在の動作モード（実行モード／待機モードの別）に関する項目を含んでいてもよい。

例えば、表１において、ＩＰアドレス「１」のサーバのうち、ＭＡＣアドレス「Ａ」のサーバ１（１Ａ）の優先度は「１」であり、現在の動作モードは「実行モード」であることを示している。また、ＭＡＣアドレス「Ｂ」のサーバ１（１Ｂ）の優先度は「２」であり、こちらも現在の動作モードは「実行モード」であることを示している。

ここで、表１に示すように、自己のサーバ１（１Ａ）の優先度が他のサーバ１（１Ｂ）よりも高いときは、監視プロセス１１は、動作モードを実行モードのままとし、ＡＲＰハンドラ１０にＡＲＰリクエストを送信させる。一方、自己のサーバ１（１Ａ）の優先度が低いときは、監視プロセス１１はＩＰアドレス割り当てプロセス１５にＩＰアドレス削除を行わせ、自己のサーバ１（１Ａ）を待機モードに遷移させる。

なお、自己のサーバ１（１Ａ）が「待機モード」に切り替わったとき、監視プロセス１１が動作モードの欄の情報を「待機モード」に書き換えるようにしてもよい。また、他のサーバ１（１Ｂ）が待機モードに遷移した旨の通知を受信したときには、このサーバ１（１Ｂ）の動作モードの欄を「待機モード」に書き換えるようにしてもよい。
ちなみに、この優先度テーブルの情報は、ネットワークシステムの管理者等が、サーバ１（１Ａ,Ｂ）に接続されたキーボードやマウス等を用いて手動入力するようにしてもよい。また、管理者等が、各サーバ１の動作モードを確認できるように、優先度テーブルの情報をモニタ等の表示手段で表示するようにしてもよい。

なお、図２のステップＳ２９において、ＡＲＰハンドラ１０がＡＲＰリクエストを送信する間隔は、クライアント３のＡＲＰキャッシュ１２における該当ＩＰアドレスに対するエントリーが無効とならない間隔にすることが望ましい。

つまり、誤って他のノードに同じＩＰアドレスが設定された場合、この間にＡＲＰキャッシュ１２がクリアされ、クライアント３がＡＲＰリクエストを送信すると、ＡＲＰキャッシュ１２に他のノードのＭＡＣアドレスに書き換えるおそれがあるからである。

また、サーバ１が他のノードにＩＰアドレスが重複割り当てされたことを検出すると、サーバ１が自己のＭＡＣアドレスを設定したＡＲＰリクエストをブロードキャスト送信する。つまり、クライアント３のＡＲＰキャッシュ１２のＭＡＣアドレスを訂正することができる。その結果、ネットワークトラヒックの混乱により生じるクライアント３へのサービス提供の不可を防止することができ、従来よりも可用性の高いネットワークシステムの構築が可能となる。

なお、前記した実施の形態では、同じサービスを提供するサーバ１が２台の場合について説明したが、このサーバ１は３台以上で構成されていてもよい。

この場合には、前記した優先度テーブル（表１参照）において、複数の待機モードのサーバ１の情報が記述されることになる。そして、待機モードのサーバ１は、実行モードのサーバ１とのハートビート通信が不可能になったとき、この優先度テーブルを参照する。ここで、この優先度テーブルに記述された待機モードのサーバ１の中で、自己の優先度が最も高ければ、サーバ１は実行モードへの切り替えを行い、自己の優先度が２番目以降であれば実行モードへの切り替えは行わない。
このようにすることで、待機モードのサーバ１が２台以上あるときも、１台のサーバ１が実行モードに切り替わる（ＩＰアドレスの引き継ぎをする）ようにすることができる。

本発明は、前記した実施の形態に限定されず、発明の趣旨を逸脱しない範囲で応用可能である。
例えば、前記した実施の形態では、図２のステップＳ２９（ステップＳ２８）で、自己のサーバ１（１Ｂ）は、相手方のサーバ１（１Ａ）の状態が確認できるまで、ＡＲＰリクエストを送信することとしたが、このとき送信するメッセージは、サーバ１（１Ｂ）のＭＡＣアドレスが含まれるメッセージであれば、ＡＲＰリクエスト以外のものであってもよい。
つまり、サーバ１（１Ａ）が、サーバ１（１Ｂ）からのメッセージであることを識別できる情報であればよい。

本実施の形態に係るサーバ１（１Ａ,Ｂ）は、前記したような処理を実行させるＩＰアドレス引き継ぎプログラムによって実現することができ、そのプログラムをコンピュータによる読み取り可能な記憶媒体（ＣＤ−ＲＯＭ等）に記憶して提供することが可能である。また、そのプログラムを、ネットワークを通して提供することも可能である。

本発明の実施の形態であるサーバコンピュータを用いて構築されたネットワークシステムのブロック図である。 図１のサーバの動作モードの切り替えの動作（ＩＰアドレス引き継ぎプログラム）を示すフローチャートである。 図１の実行モードのサーバがＡＲＰリクエストを受信したときの動作を示すフローチャートである。

符号の説明

１（１Ａ,Ｂ） サーバ
１０ ＡＲＰハンドラ
１１ 監視プロセス
１５ ＩＰアドレス割り当てプロセス

Claims (10)

1. ネットワークを介してサービスを提供する実行モードのサーバと、このサーバに障害が発生したとき、このサーバのＩＰアドレスを引き継ぎ実行モードに切り替わる１以上の待機モードのサーバとを含むネットワークシステムにおける、ＩＰアドレス引き継ぎ方法であって、
   前記待機モードのサーバが、
   所定期間、前記実行モードのサーバからハートビート通信のメッセージを受信しなかったとき、前記待機モードのサーバの記憶装置に記憶されたＩＰアドレスを自己のサーバに割り当て、実行モードに切り替えるステップと、
   前記自己のサーバに割り当てたＩＰアドレスと、自己のサーバのＭＡＣアドレスとを含むメッセージを、ブロードキャスト形式で、所定期間送信するステップとを実行し、
   前記実行モードのサーバが、
   自己のサーバに割り当てられたＩＰアドレスと同じＩＰアドレスと、前記待機モードのサーバのＭＡＣアドレスとを含むメッセージを受信したとき、前記自己のサーバに割り当てられていたＩＰアドレスを削除し、待機モードに切り替えるステップを実行することを特徴とするＩＰアドレス引き継ぎ方法。
2. 前記各サーバは、その記憶装置にハートビート通信を行うサーバの識別情報ごとに前記各サーバが実行モードに切り替えるときの優先度を示す優先度テーブルを格納し、
   前記待機モードのサーバは、
   所定期間、前記実行モードのサーバからハートビート通信のメッセージを受信せず、かつ前記優先度テーブルにおいて自己のサーバの優先度が他のサーバよりも高かったとき、前記自己のサーバを実行モードへ切り替えることを特徴とする請求項１に記載のＩＰアドレス引き継ぎ方法。
3. 前記実行モードから待機モードに切り替えたサーバは、
   前記自己のサーバのＭＡＣアドレスを含む待機モード切り替えメッセージを送信するステップをさらに実行し、
   前記待機モードから実行モードに切り替えたサーバは、
   前記待機モード切り替えメッセージを受信したとき、前記自己のサーバに割り当てたＩＰアドレスと自己のサーバのＭＡＣアドレスとを含むメッセージの送信を停止することを特徴とする請求項１または請求項２に記載のＩＰアドレス引き継ぎ方法。
4. 前記待機モードのサーバが送信する前記自己のサーバに割り当てたＩＰアドレスと前記自己のサーバのＭＡＣアドレスとを含むメッセージは、ＡＲＰリクエストであることを特徴とする請求項１または請求項２に記載のＩＰアドレス引き継ぎ方法。
5. 前記実行モードのサーバは、
   前記待機サーバ以外のサーバを送信元とするＡＲＰリクエストを受信したとき、前記サーバへ、前記実行モードのサーバＩＰアドレスとＭＡＣアドレスとを設定したＡＲＰリプライを送信することを特徴とする請求項４に記載のＩＰアドレス引き継ぎ方法。
6. コンピュータに、請求項１に記載のＩＰアドレス引き継ぎ方法を実行させることを特徴とするＩＰアドレス引き継ぎプログラム。
7. 同じサービスを提供する他のサーバとハートビート通信を行って、互いの動作状態を確認するとともにＩＰアドレスの引き継ぎを行うサーバであって、
   前記各サーバに割り当てるべきＩＰアドレスおよび前記各サーバのＭＡＣアドレスを示すテーブルを記憶する記憶装置と、
   前記テーブルから読み出したＩＰアドレスと自己のサーバのＭＡＣアドレスとを含むＡＲＰリクエストを、ブロードキャスト形式で送信するとともに、前記各サーバからのＡＲＰリクエストを受信するＡＲＰハンドラと、
   前記自己のサーバに前記テーブルから読み出したＩＰアドレスを割り当てと、前記自己のサーバからのＩＰアドレス削除とを行うＩＰアドレス割り当てプロセスと、
   前記ハートビート通信を行うための通信路経由で、前記同じサービスを提供する他のサーバと前記ハートビート通信を行い、所定期間、前記他のサーバからハートビート通信のメッセージを受信しなかったとき、前記ＩＰアドレス割り当てプロセスにＩＰアドレスの割り当てさせるとともに、前記ＡＲＰハンドラに前記他のサーバの動作状態が確認できるまでＡＲＰリクエストを送信させる監視プロセスと、
   を備えることを特徴とするサーバ。
8. 前記監視プロセスは、
   前記同じサービスを提供する他のサーバからＡＲＰリクエストを受信したとき、前記ＩＰアドレス割り当てプロセスに前記自己のサーバからＩＰアドレスの削除させるよう構成されていることを特徴とする請求項７に記載のサーバ。
9. 前記監視プロセスは、
   前記同じサービスを提供する他のサーバ以外のノードからＡＲＰリクエストを受信したとき、前記ＡＲＰハンドラに、前記ノードへ、前記自己のサーバのＩＰアドレスとＭＡＣアドレスとを設定したＡＲＰリプライを送信させるとともに、前記自己のサーバのＩＰアドレスとＭＡＣアドレスとを設定したＡＲＰリクエストを送信させるよう構成されていることを特徴とする請求項８に記載のサーバ。
10. 請求項７ないし請求項９のいずれか１項に記載のサーバを複数備えることを特徴とするネットワークシステム。

Images