(57)【特許請求の範囲】
【請求項１】
ネットワークシステムであって、
所定のサービスを提供可能な第１の処理装置と、
前記所定のサービスを提供可能な第２の処理装置と、
前記所定のサービスを利用するクライアント装置と、
前記第１の処理装置と、前記第２の処理装置と、前記クライアント装置とインタフェースを介して直接的または間接的に接続され、各装置間のパケットを中継するネットワーク中継装置と、
を備え、
前記第１の処理装置と、前記第２の処理装置のアドレスは同一に設定され、
前記ネットワーク中継装置は、
第１の仮想ネットワークの経路情報を記憶する第１の経路情報記憶部と、
第２の仮想ネットワークの経路情報を記憶する第２の経路情報記憶部と、
前記第１の処理装置と、前記第２の処理装置と、前記クライアント装置のそれぞれが、前記第１の仮想ネットワークと、前記第２の仮想ネットワークのいずれに所属するのかを定義したＶＲＦ定義情報を記憶するＶＲＦ定義情報記憶部と、
パケットを受信した際に、前記ＶＲＦ定義情報に従って前記パケットの送信元の装置が所属する仮想ネットワークを判定し、前記送信元の装置が所属する仮想ネットワークに対応した経路情報を用いて経路探索をするパケット転送処理部と、
前記第１の処理装置および前記第２の処理装置の少なくともいずれか一方の状態を監視し、前記監視の対象である処理装置の状態を判定する状態監視部と、
前記処理装置の状態に基づいて、前記経路情報および前記ＶＲＦ定義情報の少なくともいずれか一方を更新するフェイルオーバ処理部と、
を備え、
前記ネットワーク中継装置は、前記クライアント装置が接続されている前記インタフェースから受信したパケットであって、前記アドレスをあて先とする受信パケットを、前記第１の処理装置または前記第２の処理装置のうち、前記所定のサービスを提供可能な状態の一方の処理装置へ中継する、ネットワークシステム。
【請求項２】
所定のサービスを提供可能であり、かつ、アドレスが同一に設定された第１の処理装置および第２の処理装置と、前記所定のサービスを利用するクライアント装置とインタフェースを介して直接的または間接的に接続され、各装置間のパケットを中継するネットワーク中継装置であって、
第１の仮想ネットワークの経路情報を記憶する第１の経路情報記憶部と、
第２の仮想ネットワークの経路情報を記憶する第２の経路情報記憶部と、
前記第１の処理装置と、前記第２の処理装置と、前記クライアント装置のそれぞれが、前記第１の仮想ネットワークと、前記第２の仮想ネットワークのいずれに所属するのかを定義したＶＲＦ定義情報を記憶するＶＲＦ定義情報記憶部と、
パケットを受信した際に、前記ＶＲＦ定義情報に従って前記パケットの送信元の装置が所属する仮想ネットワークを判定し、前記送信元の装置が所属する仮想ネットワークに対応した経路情報を用いて経路探索をするパケット転送処理部と、
前記第１の処理装置および前記第２の処理装置の少なくともいずれか一方の状態を監視し、前記監視の対象である処理装置の状態を判定する状態監視部と、
前記処理装置の状態に基づいて、前記経路情報および前記ＶＲＦ定義情報の少なくともいずれか一方を更新するフェイルオーバ処理部と、
を備え、
前記クライアント装置が接続されている前記インタフェースから受信したパケットであって、前記アドレスをあて先とする受信パケットを、前記第１の処理装置または前記第２の処理装置のうち、前記所定のサービスを提供可能な状態の一方の処理装置へ中継する、ネットワーク中継装置。
【請求項３】
請求項２記載のネットワーク中継装置であって、
前記ＶＲＦ定義情報には、
前記第１の処理装置と、前記クライアント装置とが前記第１の仮想ネットワークに所属し、
前記第２の処理装置が前記第２の仮想ネットワークに所属する、
ことが予め定義され、
前記状態監視部は、少なくとも前記第１の仮想ネットワークに所属する前記第１の処理装置の状態を監視し、
前記フェイルオーバ処理部は、前記処理装置が前記所定のサービスを提供することができない障害状態であると判定された場合に、
前記第１の仮想ネットワークに所属している前記クライアント装置を、前記第２の仮想ネットワークに所属させるように、ＶＲＦ定義情報を更新する、ネットワーク中継装置。
【請求項４】
請求項２記載のネットワーク中継装置であって、
前記ＶＲＦ定義情報には、
前記第１の処理装置と、前記クライアント装置とが前記第１の仮想ネットワークに所属し、
前記第２の処理装置が前記第２の仮想ネットワークに所属する、
ことが予め定義され、
前記状態監視部は、少なくとも前記第１の仮想ネットワークに所属する処理装置の状態を監視し、
前記フェイルオーバ処理部は、前記処理装置が前記所定のサービスを提供することができない障害状態であると判定された場合に、
前記第２の処理装置と、前記クライアント装置とを前記第１の仮想ネットワークに所属させ、前記第１の処理装置を前記第２の仮想ネットワークに所属させるように、ＶＲＦ定義情報を更新する、ネットワーク中継装置。
【請求項５】
請求項２記載のネットワーク中継装置であって、
前記ＶＲＦ定義情報には、
前記第１の処理装置と、前記クライアント装置とが前記第１の仮想ネットワークに所属し、
前記第２の処理装置が前記第２の仮想ネットワークに所属する、
ことが予め定義され、
前記状態監視部は、少なくとも前記第１の仮想ネットワークに所属する前記第１の処理装置の状態を監視し、
前記フェイルオーバ処理部は、前記処理装置が前記所定のサービスを提供することができない障害状態であると判定された場合に、
前記第２の仮想ネットワークの経路情報に、前記第１の仮想ネットワークの経路情報中の前記クライアント装置に関する経路情報をコピーし、
前記第１の仮想ネットワークの経路情報中の、前記第１の処理装置のアドレスをあて先アドレスとするエントリの出力先インタフェースを、前記第２の処理装置が接続されているインタフェースへと更新する、ネットワーク中継装置。
【請求項６】
請求項２記載のネットワーク中継装置であって、
前記ＶＲＦ定義情報には、
前記第１の処理装置が前記第１の仮想ネットワークに所属し、
前記第２の処理装置が前記第２の仮想ネットワークに所属し、
前記クライアント装置が前記第１の仮想ネットワークおよび前記第２の仮想ネットワークの両方に所属する、
ことが予め定義され、
前記パケット転送処理部は、さらに、
前記クライアント装置からパケットを受信した際は、予め定められた規則に従って、前記パケットの送信元である装置毎に、前記第１の仮想ネットワークの経路情報および前記第２の仮想ネットワークの経路情報のいずれか一方を用いて経路探索をし、
前記状態監視部は、前記第１の仮想ネットワークに所属する前記第１の処理装置と、前記第２の仮想ネットワークに所属する前記第２の処理装置の両方の状態を監視し、
前記フェイルオーバ処理部は、監視されている一方の処理装置が前記所定のサービスを提供することができない障害状態であると判定された場合に、
前記第１の仮想ネットワークおよび前記第２の仮想ネットワークの両方に所属していた前記クライアント装置を、前記障害状態であると判定された一方の処理装置が所属する仮想ネットワークから除外するように、ＶＲＦ定義情報を更新する、ネットワーク中継装置。
【請求項７】
請求項２ないし６のいずれか一項記載のネットワーク中継装置であって、さらに、
前記ネットワーク中継装置を管理する管理装置と接続され、
前記フェイルオーバ処理部は、前記管理装置から前記経路情報および前記ＶＲＦ定義情報の少なくともいずれか一方を更新するためのフェイルオーバ指示を受信し、前記経路情報および前記ＶＲＦ定義情報の少なくともいずれか一方を更新する、ネットワーク中継装置。
【請求項８】
請求項３または６または７のいずれか一項記載のネットワーク中継装置であって、
前記状態監視部は、さらに、
前記監視の対象である処理装置が、前記処理装置が前記所定のサービスを提供することができない障害状態であると判定された後においても前記処理装置の監視を継続し、
前記フェイルオーバ処理部は、前記処理装置が前記所定のサービスを提供可能な状態へ復旧したと判定された場合に、
前記経路情報および前記ＶＲＦ定義情報の少なくともいずれか一方を、前記障害状態であると判定される前の状態へと更新するリカバリ処理と、
前記経路情報および前記ＶＲＦ定義情報の更新を行わないロック処理と、
を選択的に実行可能な、ネットワーク中継装置。
【請求項９】
所定のサービスを提供可能な第１の処理装置および第２の処理装置と、前記所定のサービスを利用するクライアント装置と、前記第１の処理装置と、前記第２の処理装置と、前記クライアント装置とインタフェースを介して直接的または間接的に接続され、各装置間のパケットを中継するネットワーク中継装置と、を備えるネットワークシステムの制御方法であって、
前記第１の処理装置と、前記第２の処理装置のアドレスを同一に設定する工程と、
第１の仮想ネットワークの経路情報を記憶する工程と、
第２の仮想ネットワークの経路情報を記憶する工程と、
前記第１の処理装置と、前記第２の処理装置と、前記クライアント装置のそれぞれが、前記第１の仮想ネットワークと、前記第２の仮想ネットワークのいずれに所属するのかを定義したＶＲＦ定義情報を記憶する工程と、
パケットを受信した際に、前記ＶＲＦ定義情報に従って前記パケットの送信元の装置が所属する仮想ネットワークを判定し、前記送信元の装置が所属する仮想ネットワークに対応した経路情報を用いて経路探索をする工程と、
前記第１の処理装置および前記第２の処理装置の少なくともいずれか一方の状態を監視し、前記監視の対象である処理装置の状態を判定する工程と、
前記処理装置の状態に基づいて、前記経路情報および前記ＶＲＦ定義情報の少なくともいずれか一方を更新する工程と、
前記ネットワーク中継装置が、前記クライアント装置が接続されている前記インタフェースから受信した前記アドレスをあて先とする受信パケットを、前記第１の処理装置または前記第２の処理装置のうち、前記所定のサービスを提供可能な状態の一方の処理装置へ中継する工程と、
を備える、ネットワークシステムの制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークシステムに関する。
【背景技術】
【０００２】
高い信頼性（Ｒｅｌｉａｂｉｌｉｔｙ）および可用性（Ａｖａｉｌａｂｉｌｉｔｙ）を有するサーバネットワークシステムを構築するための方法として、フェイルオーバが知られている。フェイルオーバとは、運用系サーバ（もしくは、システム、ネットワーク）で異常事態が発生したとき、自動的に冗長な待機系サーバ（もしくは、システム、ネットワーク）に切り換える機能を意味する。例えば、コールドスタンバイによるフェイルオーバ方法では、サービス（例えば、ＷＥＢサービス等）を提供する運用サーバと、通常は他の処理を行っている、或いは、電源を切って待機している予備サーバとによりシステムを構成する。コールドスタンバイでは、運用サーバで障害が発生した場合、運用サーバに設定していた情報（例えば、ＩＰアドレス）を、予備サーバへ再設定することによってフェイルオーバ処理を実現する（例えば、特許文献１）。
【０００３】
他の例としては、ホットスタンバイによるフェイルオーバ方法がある。ホットスタンバイによるフェイルオーバ方法では、サービスを提供可能な複数のサーバと、ロードバランサまたはＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）サーバとによりシステムを構成する。ホットスタンバイでは、サービスを提供している複数のサーバのいずれかに障害が発生した場合、システムの構成に応じて、次のようにしてフェイルオーバ処理を実現する。ロードバランサを使用する構成では、ロードバランサにおいて、障害が発生したサーバへ処理要求を送信しないようにすることで、フェイルオーバ処理を実現する（例えば、特許文献２）。ＤＮＳを使用する構成では、ＤＮＳサーバにおいて、障害が発生したサーバのＩＰアドレスを通知しないようにすることで、フェイルオーバ処理を実現する（例えば、特許文献３）。
【０００４】
従来のコールドスタンバイによるフェイルオーバ方法では、運用サーバから予備サーバへサービスを引き継ぐ際の情報の再設定に時間を要する。このため、長時間サービスが停止してしまうという問題があった。一方、ホットスタンバイによるフェイルオーバ方法では、短時間でのサービス再開が可能である反面、ロードバランサやＤＮＳサーバといったネットワークシステムの構成要素の導入が必要となる。このため、ネットワークシステムが複雑になるという問題があった。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００５−２５８８４７号公報
【特許文献２】特開２００５−５６３４７号公報
【特許文献３】特開２００５−２５０６２６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
本発明は、サーバネットワークシステムにおいて、構成要素の追加をすることなく、かつ、短時間でのフェイルオーバが可能な技術を提供することを目的とする。
【課題を解決するための手段】
【０００７】
本発明は、上述の課題の少なくとも一部を解決するためになされたものであり、以下の形態として実現することができる。ネットワークシステムであって、所定のサービスを提供可能な第１の処理装置と、前記所定のサービスを提供可能な第２の処理装置と、前記所定のサービスを利用するクライアント装置と、前記第１の処理装置と、前記第２の処理装置と、前記クライアント装置とインタフェースを介して直接的または間接的に接続され、各装置間のパケットを中継するネットワーク中継装置と、を備え、前記第１の処理装置と、前記第２の処理装置のアドレスは同一に設定され、前記ネットワーク中継装置は、第１の仮想ネットワークの経路情報を記憶する第１の経路情報記憶部と、第２の仮想ネットワークの経路情報を記憶する第２の経路情報記憶部と、前記第１の処理装置と、前記第２の処理装置と、前記クライアント装置のそれぞれが、前記第１の仮想ネットワークと、前記第２の仮想ネットワークのいずれに所属するのかを定義したＶＲＦ定義情報を記憶するＶＲＦ定義情報記憶部と、パケットを受信した際に、前記ＶＲＦ定義情報に従って前記パケットの送信元の装置が所属する仮想ネットワークを判定し、前記送信元の装置が所属する仮想ネットワークに対応した経路情報を用いて経路探索をするパケット転送処理部と、前記第１の処理装置および前記第２の処理装置の少なくともいずれか一方の状態を監視し、前記監視の対象である処理装置の状態を判定する状態監視部と、前記処理装置の状態に基づいて、前記経路情報および前記ＶＲＦ定義情報の少なくともいずれか一方を更新するフェイルオーバ処理部と、を備え、前記ネットワーク中継装置は、前記クライアント装置が接続されている前記インタフェースから受信したパケットであって、前記アドレスをあて先とする受信パケットを、前記第１の処理装置または前記第２の処理装置のうち、前記所定のサービスを提供可能な状態の一方の処理装置へ中継する、ネットワークシステム。そのほか、本発明は、以下の形態又は適用例として実現することが可能である。
【０００８】
［適用例１］
ネットワークシステムであって、
所定のサービスを提供可能な第１の処理装置と、
前記所定のサービスを提供可能な第２の処理装置と、
前記所定のサービスを利用するクライアント装置と、
前記第１の処理装置と、前記第２の処理装置と、前記クライアント装置とインタフェースを介して直接的または間接的に接続され、各装置間のパケットを中継するネットワーク中継装置と、
を備え、
前記第１の処理装置と、前記第２の処理装置のアドレスは同一に設定され、
前記ネットワーク中継装置は、前記クライアント装置が接続されている前記インタフェースから受信したパケットであって、前記アドレスをあて先とする受信パケットを、前記第１の処理装置または前記第２の処理装置のうち、前記所定のサービスを提供可能な状態の一方の処理装置へ中継する、ネットワークシステム。
この構成によれば、第１の処理装置と、第２の処理装置は、共に所定のサービスを提供可能であり、かつ、同一のアドレスが設定される。また、ネットワーク中継装置は、クライアント装置からの受信パケットを、第１の処理装置と第２の処理装置のうち、所定のサービスを提供可能な状態の一方の処理装置へ中継する。このため、サーバネットワークシステムにおいて、構成要素の追加をすることなく、かつ、短時間でのフェイルオーバが可能となる。
【０００９】
［適用例２］
適用例１記載のネットワークシステムであって、
前記ネットワーク中継装置は、
第１の仮想ネットワークの経路情報を記憶する第１の経路情報記憶部と、
第２の仮想ネットワークの経路情報を記憶する第２の経路情報記憶部と、
前記第１の処理装置と、前記第２の処理装置と、前記クライアント装置のそれぞれが、前記第１の仮想ネットワークと、前記第２の仮想ネットワークのいずれに所属するのかを定義したＶＲＦ定義情報を記憶するＶＲＦ定義情報記憶部と、
パケットを受信した際に、前記ＶＲＦ定義情報に従って前記パケットの送信元の装置が所属する仮想ネットワークを判定し、前記送信元の装置が所属する仮想ネットワークに対応した経路情報を用いて経路探索をするパケット転送処理部と、
前記第１の処理装置および前記第２の処理装置の少なくともいずれか一方の状態を監視し、前記監視の対象である処理装置の状態を判定する状態監視部と、
前記処理装置の状態に基づいて、前記経路情報および前記ＶＲＦ定義情報の少なくともいずれか一方を更新するフェイルオーバ処理部と、
を備える、ネットワークシステム。
この構成によれば、第１の処理装置と、第２の処理装置に、同一のアドレスを設定することができる。また、状態監視部は、第１の処理装置および第２の処理装置の少なくともいずれか一方の状態を監視する。フェイルオーバ処理部は、処理装置の状態に基づいて、経路情報およびＶＲＦ定義情報の少なくともいずれか一方を更新する。このため、サーバネットワークシステムにおいて、構成要素の追加をすることなく、かつ、短時間でのフェイルオーバが可能となる。
【００１０】
［適用例３］
適用例２記載のネットワークシステムであって、
前記ＶＲＦ定義情報には、
前記第１の処理装置と、前記クライアント装置とが前記第１の仮想ネットワークに所属し、
前記第２の処理装置が前記第２の仮想ネットワークに所属する、
ことが予め定義され、
前記状態監視部は、少なくとも前記第１の仮想ネットワークに所属する前記第１の処理装置の状態を監視し、
前記フェイルオーバ処理部は、前記処理装置が前記所定のサービスを提供することができない障害状態であると判定された場合に、
前記第１の仮想ネットワークに所属している前記クライアント装置を、前記第２の仮想ネットワークに所属させるように、ＶＲＦ定義情報を更新する、ネットワークシステム。
この構成によれば、状態監視部は、クライアント装置に所定のサービスを提供する第１の仮想ネットワークに所属する第１の処理装置の状態を監視し、フェイルオーバ処理部は、当該処理装置がサービスを提供することができない障害状態であると判定された場合に、第１の仮想ネットワークに所属しているクライアント装置を、第２の仮想ネットワークに所属させるように、ＶＲＦ定義情報を更新する。このため、運用系サーバである第１の処理装置に障害が発生した場合であっても、ＶＲＦ定義情報の更新によって、スムーズに待機系サーバである第２の処理装置へのフェイルオーバが可能となる。この結果、サーバネットワークシステムにおいて、構成要素の追加をすることなく、かつ、短時間でのフェイルオーバが実現できる。
【００１１】
［適用例４］
適用例２記載のネットワークシステムであって、
前記ＶＲＦ定義情報には、
前記第１の処理装置と、前記クライアント装置とが前記第１の仮想ネットワークに所属し、
前記第２の処理装置が前記第２の仮想ネットワークに所属する、
ことが予め定義され、
前記状態監視部は、少なくとも前記第１の仮想ネットワークに所属する処理装置の状態を監視し、
前記フェイルオーバ処理部は、前記処理装置が前記所定のサービスを提供することができない障害状態であると判定された場合に、
前記第２の処理装置と、前記クライアント装置とを前記第１の仮想ネットワークに所属させ、前記第１の処理装置を前記第２の仮想ネットワークに所属させるように、ＶＲＦ定義情報を更新する、ネットワークシステム。
この構成によれば、状態監視部は、クライアント装置に所定のサービスを提供する第１の仮想ネットワークに所属する処理装置の状態を監視し、フェイルオーバ処理部は、当該処理装置がサービスを提供することができない障害状態であると判定された場合に、第２の処理装置と、クライアント装置とを第１の仮想ネットワークに所属させ、第１の処理装置を第２の仮想ネットワークに所属させるように、ＶＲＦ定義情報を更新する。このため、適用例１と同様の効果を得ることができる。また、フェイルオーバ処理部は、処理装置についてのＶＲＦ定義情報を更新する。このため、例えば、ネットワーク中継装置に接続される処理装置の数が、ネットワーク中継装置に接続されるクライアント装置の数よりも少ない場合には、ＶＲＦ定義情報の更新量を少なくすることができる。
【００１２】
［適用例５］
適用例２記載のネットワークシステムであって、
前記ＶＲＦ定義情報には、
前記第１の処理装置と、前記クライアント装置とが前記第１の仮想ネットワークに所属し、
前記第２の処理装置が前記第２の仮想ネットワークに所属する、
ことが予め定義され、
前記状態監視部は、少なくとも前記第１の仮想ネットワークに所属する前記第１の処理装置の状態を監視し、
前記フェイルオーバ処理部は、前記処理装置が前記所定のサービスを提供することができない障害状態であると判定された場合に、
前記第２の仮想ネットワークの経路情報に、前記第１の仮想ネットワークの経路情報中の前記クライアント装置に関する経路情報をコピーし、
前記第１の仮想ネットワークの経路情報中の、前記第１の処理装置のアドレスをあて先アドレスとするエントリの出力先インタフェースを、前記第２の処理装置が接続されているインタフェースへと更新する、ネットワークシステム。
この構成によれば、状態監視部は、クライアント装置に所定のサービスを提供する第１の仮想ネットワークに所属する処理装置の状態を監視し、フェイルオーバ処理部は、当該処理装置がサービスを提供することができない障害状態であると判定された場合に、第２の仮想ネットワークの経路情報に、第１の仮想ネットワークの経路情報中のクライアント装置に関する経路情報をコピーし、第１の仮想ネットワークの経路情報中の、前記第１の処理装置のアドレスをあて先アドレスとするエントリの出力先インタフェースを、第２の処理装置が接続されているインタフェースへと更新する。この結果、例えば、ネットワーク中継装置の１つのインタフェースに対して、アドレスの異なる複数の処理装置が接続されている場合であっても、互いの処理装置の状態に影響されないフェイルオーバ処理が可能となる。
【００１３】
［適用例６］
適用例２記載のネットワークシステムであって、
前記ＶＲＦ定義情報には、
前記第１の処理装置が前記第１の仮想ネットワークに所属し、
前記第２の処理装置が前記第２の仮想ネットワークに所属し、
前記クライアント装置が前記第１の仮想ネットワークおよび前記第２の仮想ネットワークの両方に所属する、
ことが予め定義され、
前記パケット転送処理部は、さらに、
前記クライアント装置からパケットを受信した際は、予め定められた規則に従って、前記パケットの送信元である装置毎に、前記第１の仮想ネットワークの経路情報および前記第２の仮想ネットワークの経路情報のいずれか一方を用いて経路探索をし、
前記状態監視部は、前記第１の仮想ネットワークに所属する前記第１の処理装置と、前記第２の仮想ネットワークに所属する前記第２の処理装置の両方の状態を監視し、
前記フェイルオーバ処理部は、監視されている一方の処理装置が前記所定のサービスを提供することができない障害状態であると判定された場合に、
前記第１の仮想ネットワークおよび前記第２の仮想ネットワークの両方に所属していた前記クライアント装置を、前記障害状態であると判定された一方の処理装置が所属する仮想ネットワークから除外するように、ＶＲＦ定義情報を更新する、ネットワークシステム。
この構成によれば、パケット転送処理部は、クライアント装置からパケットを受信した際に、パケットの送信元である装置毎に、予め定められた規則に従って第１の仮想ネットワークの経路情報および第２の仮想ネットワークの経路情報のいずれか一方を用いて経路探索を行う。このため、２台の処理装置の両方をサービスの提供に使用することができる。従って、設備投資の観点から効率の良いネットワークシステムを提供することができる。さらに、状態監視部は、第１の仮想ネットワークに所属する第１の処理装置と、第２の仮想ネットワークに所属する第２の処理装置の両方の状態を監視する。また、フェイルオーバ処理部は、監視対象であるいずれか一方の処理装置が障害状態であると判定された場合に、第１の仮想ネットワークおよび第２の仮想ネットワークの両方に所属していたクライアント装置を、障害状態であると判定された一方の処理装置が所属する仮想ネットワークから除外するように、ＶＲＦ定義情報を更新する。このため、適用例１と同様の効果を得ることができる。
【００１４】
［適用例７］
適用例２ないし６のいずれか一項記載のネットワークシステムであって、さらに、
前記ネットワーク中継装置を管理する管理装置を備え、
前記管理装置は、
前記フェイルオーバ処理部に対して、前記経路情報および前記ＶＲＦ定義情報の少なくともいずれか一方を更新するためのフェイルオーバ指示を送信するフェイルオーバ管理部を備える、ネットワークシステム。
この構成によれば、管理装置のフェイルオーバ管理部は、ネットワーク中継装置のフェイルオーバ処理部に対して、経路情報およびＶＲＦ定義情報の少なくともいずれか一方を更新するためのフェイルオーバ指示を送信する。このため、ネットワーク中継装置の管理装置が予め外部に設けられているような構成においても、適用例１と同様の効果を得ることができる。また、管理装置は、ネットワーク中継装置よりも高度な処理能力を有する場合が多い。従って、例えば、状態監視処理において、障害状態であるか否かの判定以外のより高度な判定（例えば、処理装置のＣＰＵ利用率等）を行うこともできる。
【００１５】
［適用例８］
適用例３または６または７のいずれか一項記載のネットワークシステムであって、
前記状態監視部は、さらに、
前記監視の対象である処理装置が、前記障害状態であると判定された後においても前記処理装置の監視を継続し、
前記フェイルオーバ処理部は、前記処理装置が前記所定のサービスを提供可能な状態へ復旧したと判定された場合に、
前記経路情報および前記ＶＲＦ定義情報の少なくともいずれか一方を、前記障害状態であると判定される前の状態へと更新するリカバリ処理と、
前記経路情報および前記ＶＲＦ定義情報の更新を行わないロック処理と、
を選択的に実行可能な、ネットワークシステム。
この構成によれば、状態監視部は、監視の対象である処理装置が障害状態であると判定された後においても監視を継続する。そして、当該処理装置がサービスを提供可能な状態へ復旧したと判定された場合、フェイルオーバ処理部は、経路情報およびＶＲＦ定義情報の少なくともいずれか一方を、障害状態であると判定される前の状態へと更新するリカバリ処理と、経路情報とＶＲＦ定義情報との更新を行わないロック処理とを選択的に実行することができる。このため、例えば、システム管理者は、処理装置の復旧と同時にシステムが自動的にフェイルオーバする運用方法（リカバリ処理）と、自ら処理装置の復旧を確認したうえで手動によりフェイルオーバさせる運用方法（ロック処理）とを選択することができる。この結果、ネットワークシステムの運用の幅を広げることができる。
【００１６】
なお、本発明は、種々の態様で実現することが可能である。例えば、ネットワークシステム、ネットワーク中継装置、それらの方法または装置の機能を実現するためのコンピュータプログラム、そのコンピュータプログラムを記録した記憶媒体等の形態で実現することができる。
【図面の簡単な説明】
【００１７】
【図１】本発明の一実施例としてのネットワークシステム１０の概略構成を示す説明図である。
【図２】２台のサーバのＩＰアドレス情報の一例を示す説明図である。
【図３】ホスト３０１のＩＰアドレス情報の一例を示す説明図である。
【図４】ホスト３０２のＩＰアドレス情報の一例を示す説明図である。
【図５】ネットワーク装置１００の構成情報を規定するコンフィギュレーション情報の一例を示す説明図である。
【図６】インタフェースデータベース１４０の一例を示す説明図である。
【図７】インタフェースデータベース１４０が図６で示した状態である場合におけるＶＲＦ１ルーティングテーブル１２１の一例を示す説明図である。
【図８】インタフェースデータベース１４０が図６で示した状態である場合におけるＶＲＦ２ルーティングテーブル１２２の一例を示す説明図である。
【図９】状態監視データベース１７０の一例を示す説明図である。
【図１０】障害切替データベース１８０の一例を示す説明図である。
【図１１】復旧切替データベース１９０の一例を示す説明図である。
【図１２】運用サーバ２０１がサービスを提供し得る状態である場合のネットワークシステム１０の動作を示す説明図である。
【図１３】ネットワーク装置１００におけるパケット転送処理の手順を示すフローチャートである。
【図１４】状態監視処理の手順を示すフローチャートである。
【図１５】図１４のステップＳ５０７において更新された後の状態監視データベース１７０を示す説明図である。
【図１６】フェイルオーバ処理（図１４：ステップＳ５０８）の手順を示すフローチャートである。
【図１７】図１６のステップＳ６０１において更新された後のインタフェースデータベース１４０を示す説明図である。
【図１８】図１６のステップＳ６０２において更新された後のＶＲＦ１ルーティングテーブル１２１を示す説明図である。
【図１９】図１６のステップＳ６０２において更新された後のＶＲＦ２ルーティングテーブル１２２を示す説明図である。
【図２０】運用サーバ２０１に障害が検出された場合におけるネットワークシステム１０の動作を示す説明図である。
【図２１】復旧検出時処理（図１４：ステップＳ５０６）の手順を示すフローチャートである。
【図２２】運用サーバ２０１の復旧が検出された場合におけるステップＳ６５１（図２１）で更新された後のインタフェースデータベース１４０を示す説明図である。
【図２３】運用サーバ２０１の復旧が検出された場合におけるステップＳ６５２（図２１）で更新された後のＶＲＦ１ルーティングテーブル１２１を示す説明図である。
【図２４】運用サーバ２０１の復旧が検出された場合におけるステップＳ６５２（図２１）で更新された後のＶＲＦ２ルーティングテーブル１２２を示す説明図である。
【図２５】運用サーバ２０１の復旧が検出された場合におけるネットワークシステム１０の動作を示す説明図である。
【図２６】インタフェースデータベース１４０を初期化するためのコマンドの一例を示す説明図である。
【図２７】第２実施例におけるネットワーク装置１００の構成情報を規定するコンフィギュレーション情報の一例を示す説明図である。
【図２８】第２実施例における障害切替データベース１８０の一例を示す説明図である。
【図２９】第２実施例におけるフェイルオーバ処理（図１４：ステップＳ５０８）の手順を示すフローチャートである。
【図３０】図２９のステップＳ６０１において更新された後のインタフェースデータベース１４０を示す説明図である。
【図３１】図２９のステップＳ６０２において更新された後のＶＲＦ１ルーティングテーブル１２１を示す説明図である。
【図３２】図２９のステップＳ６０２において更新された後のＶＲＦ２ルーティングテーブル１２２を示す説明図である。
【図３３】図２９のステップＳ６１１において更新された後の障害切替データベース１８０を示す説明図である。
【図３４】第３実施例におけるネットワークシステム１０ａの概略構成を示す説明図である。
【図３５】第３実施例において第２のサービスを提供する２台のサーバのＩＰアドレス情報の一例を示す説明図である。
【図３６】第３実施例におけるネットワーク装置１００ａの構成情報を規定するコンフィギュレーション情報の一例を示す説明図である。
【図３７】第３実施例におけるＶＲＦ１ルーティングテーブル１２１の一例を示す説明図である。
【図３８】第３実施例におけるＶＲＦ２ルーティングテーブル１２２の一例を示す説明図である。
【図３９】第３実施例における状態監視データベース１７０の一例を示す説明図である。
【図４０】第３実施例における障害切替経路データベース１８１の一例を示す説明図である。
【図４１】運用サーバ２１１に障害が発生し図１４のステップＳ５０７において更新された後の状態監視データベース１７０を示す説明図である。
【図４２】第３実施例におけるフェイルオーバ処理（図１４：ステップＳ５０８）の手順を示すフローチャートである。
【図４３】図４２のステップＳ７０１において更新された後のＶＲＦ１ルーティングテーブル１２１を示す説明図である。
【図４４】図４２のステップＳ７０３,Ｓ７０４において更新された後のＶＲＦ２ルーティングテーブル１２２を示す説明図である。
【図４５】図４２のステップＳ７０６において更新された後の障害切替経路データベース１８１を示す説明図である。
【図４６】第３実施例において運用サーバ２１１の障害が検出された場合の第１のサービス提供時の動作を示す説明図である。
【図４７】第３実施例において運用サーバ２１１の障害が検出された場合の第２のサービス提供時の動作を示す説明図である。
【図４８】第３実施例において予備サーバ２１２の障害が検出された場合の第１のサービス提供時の動作を示す説明図である。
【図４９】ルーティングテーブルの内容を消去するためのコマンドの一例を示す説明図である。
【図５０】ルーティングテーブルから任意の経路情報を消去するためのコマンドの一例を示す説明図である。
【図５１】第４実施例におけるネットワークシステム１０ｂの概略構成を示す説明図である。
【図５２】第４実施例におけるネットワーク装置１００ｂの構成情報を規定するコンフィギュレーション情報の一例を示す説明図である。
【図５３】第４実施例におけるインタフェースデータベース１４０の一例を示す説明図である。
【図５４】第４実施例におけるＶＲＦロードバランスデータベース１４１の一例を示す説明図である。
【図５５】第４実施例におけるパケット転送処理の手順を示すフローチャートである。
【図５６】第４実施例におけるＶＲＦ１ルーティングテーブル１２１の一例を示す説明図である。
【図５７】第４実施例におけるＶＲＦ２ルーティングテーブル１２２の一例を示す説明図である。
【図５８】第４実施例におけるロードバランス切替データベース１８２の一例を示す説明図である。
【図５９】運用サーバ２０１と予備サーバ２０２とがサービスを提供し得る状態である場合のネットワークシステム１０ｂの動作を示す説明図である。
【図６０】第４実施例におけるフェイルオーバ処理（図１４：ステップＳ５０８）の手順を示すフローチャートである。
【図６１】図６０のステップＳ８０１において更新された後のＶＲＦロードバランスデータベース１４１を示す説明図である。
【図６２】運用サーバ２０１に障害が検出された場合におけるネットワークシステム１０ｂの動作を示す説明図である。
【図６３】第４実施例における復旧検出時処理（図１４：ステップＳ５０６）の手順を示すフローチャートである。
【図６４】運用サーバ２０１の復旧が検出された場合におけるステップＳ８５２（図６３）で更新された後のＶＲＦロードバランスデータベース１４１を示す説明図である。
【図６５】コマンドの一例を示す説明図である。
【図６６】第５実施例におけるネットワークシステム１０ｃの概略構成を示す説明図である。
【図６７】第５実施例におけるネットワーク装置１００ｃの構成情報を規定するコンフィギュレーション情報の一例を示す説明図である。
【図６８】第５実施例におけるインタフェースデータベース１４０の一例を示す説明図である。
【図６９】第５実施例における状態監視処理の手順を示すフローチャートである。
【図７０】フェイルオーバ処理（図６９：ステップＳ９０４）の手順を示すフローチャートである。
【図７１】復旧検出時処理（図６９：ステップＳ９０６）の手順を示すフローチャートである。
【発明を実施するための形態】
【００１８】
次に、本発明の実施の形態を実施例に基づいて以下の順序で説明する。
Ａ．第１実施例：
（Ａ−１）システム構成：
（Ａ−２）障害検出前の動作：
（Ａ−３）状態監視処理：
（Ａ−４）フェイルオーバ処理：
（Ａ−５）障害検出後の動作：
（Ａ−６）復旧検出時処理：
（Ａ−７）復旧検出後の動作：
Ｂ．第２実施例：
（Ｂ−１）第２実施例におけるシステム構成：
（Ｂ−２）第２実施例における状態監視処理（１）：
（Ｂ−３）第２実施例におけるフェイルオーバ処理（１）：
（Ｂ−４）第２実施例における状態監視処理（２）：
（Ｂ−５）第２実施例におけるフェイルオーバ処理（２）：
Ｃ．第３実施例：
（Ｃ−１）第３実施例におけるシステム構成：
（Ｃ−２）第３実施例における状態監視処理（１）：
（Ｃ−３）第３実施例におけるフェイルオーバ処理（１）：
（Ｃ−４）第３実施例における障害検出後の動作：
（Ｃ−５）第３実施例における状態監視処理（２）：
（Ｃ−６）第３実施例におけるフェイルオーバ処理（２）：
（Ｃ−７）第３実施例における状態監視処理（３）：
（Ｃ−８）第３実施例における予備サーバの障害検出後の動作：
Ｄ．第４実施例：
（Ｄ−１）第４実施例におけるシステム構成：
（Ｄ−２）第４実施例における障害検出前の動作：
（Ｄ−３）第４実施例における状態監視処理：
（Ｄ−４）第４実施例におけるフェイルオーバ処理：
（Ｄ−５）第４実施例における復旧検出時処理：
Ｅ．第５実施例：
（Ｅ−１）第５実施例におけるシステム構成：
（Ｅ−２）第５実施例における状態監視処理：
（Ｅ−３）第５実施例におけるフェイルオーバ処理：
（Ｅ−４）第５実施例における復旧検出時処理：
Ｆ．変形例：
【００１９】
Ａ．第１実施例：
（Ａ−１）システム構成：
図１は、本発明の一実施例としてのネットワークシステム１０の概略構成を示す説明図である。ネットワークシステム１０は、２台のサーバ（運用サーバ２０１、予備サーバ２０２）と、ネットワーク装置１００と、２台のホストコンピュータ（ホスト３０１、ホスト３０２）とを備えている。
【００２０】
第１の処理装置としての運用サーバ２０１は、所定のサービス（例えば、ＷＥＢサービス等のサービス）をホストに対して提供するためのサーバコンピュータである。第２の処理装置としての予備サーバ２０２は、運用サーバ２０１がサービスを提供し得る状態の間は、サービスを提供せずに待機する。運用サーバ２０１がサービスを提供し得ない状態の場合は、運用サーバ２０１に代わって所定のサービスを提供する。すなわち、運用サーバ２０１はいわゆる運用系サーバ、予備サーバ２０２はいわゆる待機系サーバである。なお、以降、処理装置のことを「サーバ」とも呼ぶ。
【００２１】
ネットワーク中継装置としてのネットワーク装置１００は、２台のサーバと、２台のホストコンピュータとの間のパケットによる通信を中継するレイヤ３のネットワーク中継装置である。ネットワーク装置１００は、４つのインタフェース（インタフェース１３１〜１３４）と、コンフィギュレーションデータベース１１０と、第１の経路情報記憶部としてのＶＲＦ１ルーティングテーブル１２１と、第２の経路情報記憶部としてのＶＲＦ２ルーティングテーブル１２２と、ＶＲＦ定義情報記憶部としてのインタフェースデータベース１４０と、パケット転送処理部１５０と、フェイルオーバ処理部１６０と、状態監視データベース１７０と、障害切替データベース１８０と、復旧切替データベース１９０とを備えている。
【００２２】
４つのインタフェース（インタフェース１３１〜１３４）は、ネットワーク装置１００と、ネットワーク装置１００に接続される外部装置との間でパケットを送受信する機能を有する。インタフェース１３１は、運用サーバ２０１と回線を介して接続されている。同様に、インタフェース１３２は予備サーバ２０２と、インタフェース１３３はホスト３０１と、インタフェース１３４はホスト３０２と、それぞれ回線を通じて接続されている。
【００２３】
コンフィギュレーションデータベース１１０は、ネットワーク装置１００の構成情報を保持するためのデータベースである。インタフェースデータベース１４０は、ネットワーク装置１００における全てのインタフェースの構成情報を保持するためのデータベースである。パケット転送処理部１５０は、いずれかのインタフェースからパケットを受信した際に、当該パケットを出力すべきインタフェースを判断し、転送を行う処理部である。
【００２４】
フェイルオーバ処理部１６０は、サーバの状態を監視し（以降、「状態監視処理」とも呼ぶ。）、フェイルオーバを実行する（以降、「フェイルオーバ処理」とも呼ぶ。）処理部である。状態監視データベース１７０は、状態監視処理に用いられる情報を保持するためのデータベースである。障害切替データベース１８０は、フェイルオーバ処理に用いられる情報を保持するためのデータベースである。復旧切替データベース１９０は、運用系サーバが障害から復旧した場合に、待機系サーバから運用系サーバへ切り替える処理（以降、「復旧検出時処理」とも呼ぶ。）において用いられる情報を保持するためのデータベースである。
【００２５】
ＶＲＦ１ルーティングテーブル１２１は、２台のサーバと、２台のホストとの間の通信を行うために必要なルーティングテーブルである。ＶＲＦ２ルーティングテーブル１２２は、ＶＲＦ１ルーティングテーブル１２１と同様に、２台のサーバと、２台のホストとの間の通信を行うために必要なルーティングテーブルである。このように、本実施例におけるネットワーク装置１００は、２つのルーティングテーブル（１２１、１２２）を備えている。これら２つのルーティングテーブルは、ネットワーク装置１００が具備するＶＲＦ（Ｖｉｒｔｕａｌ Ｒｏｕｔｉｎｇ ａｎｄ Ｆｏｒｗａｒｄｉｎｇ）技術によって保持される。
【００２６】
ＶＲＦ技術とは、レイヤ３転送を行うネットワーク中継装置に組み込まれている技術であり、複数のルーティングテーブルを保持し、それら複数のルーティングテーブルが同時に機能することを可能とする技術である。同一の装置内に存在するルーティングテーブルが異なれば、互いに干渉されず、独立した動作が可能となる。すなわち、複数のルーティングテーブルに対して、同一のレイヤ３アドレス（以降、「ＩＰアドレス」とも呼ぶ。）を設定することも可能となる。このように、ルーティングテーブルが異なり、同一のＩＰアドレスを設定可能であるということは、ネットワークが分離されている（すなわち、異なる仮想ネットワークを構成している）ということになる。
【００２７】
クライアント装置としてのホスト３０１と、ホスト３０２とは、いわゆるパーソナルコンピュータであり、いずれもネットワーク装置１００を経由して、運用サーバ２０１（または予備サーバ２０２）が提供するサービスを利用する。なお、図１では便宜上、説明上必要としない、他のネットワーク装置、回線、ネットワーク装置１００の内部構造については図示を省略している。このことは、後述する図においても同様である。なお、以降、クライアント装置のことを「ホスト」とも呼ぶ。
【００２８】
図２は、２台のサーバのＩＰアドレス情報の一例を示す説明図である。本実施例における運用サーバ２０１と、予備サーバ２０２には、図２に示すＩＰアドレスと、サブネットマスク長と、デフォルトゲートウェイとがそれぞれ設定される。すなわち、運用サーバ２０１と、予備サーバ２０２には、同じＩＰアドレスが設定される。通常のネットワークシステムにおけるＩＰアドレスは、ネットワーク内における装置やインタフェースを一意に識別するための識別子であるため、同一の値を設定することはできない。しかし、本実施例では、後述するＶＲＦの設定により運用サーバ２０１が所属するネットワークと、予備サーバ２０２が所属するネットワークとが異なるため、同一のＩＰアドレスを設定することが可能となる。
【００２９】
図３は、ホスト３０１のＩＰアドレス情報の一例を示す説明図である。本実施例におけるホスト３０１には、図３に示すＩＰアドレスと、サブネットマスク長と、デフォルトゲートウェイとが設定される。
【００３０】
図４は、ホスト３０２のＩＰアドレス情報の一例を示す説明図である。本実施例におけるホスト３０２には、図４に示すＩＰアドレスと、サブネットマスク長と、デフォルトゲートウェイとが設定される。
【００３１】
図５は、ネットワーク装置１００の構成情報を規定するコンフィギュレーション情報の一例を示す説明図である。このコンフィギュレーション情報は、コンフィギュレーションデータベース１１０に保持される。行Ｃ１は、第１のＶＲＦを定義している。行Ｃ２は、第２のＶＲＦを定義している。
【００３２】
行Ｃ３は、インタフェース１３１を定義している。インタフェースの種類はイーサネット（登録商標）である。なお、後述するインタフェース１３２〜１３４についても、インタフェースの種類は全てイーサネット（登録商標）である。行Ｃ４は、インタフェース１３１が、第１のＶＲＦのネットワークに所属することを定義している。行Ｃ５は、インタフェース１３１のＩＰアドレスと、サブネットマスク長とを定義している。行Ｃ６は、インタフェース１３２を定義している。行Ｃ７は、インタフェース１３２が、第２のＶＲＦのネットワークに所属することを定義している。行Ｃ８は、インタフェース１３２のＩＰアドレスと、サブネットマスク長とを定義している。
【００３３】
ここで、インタフェース１３１のＩＰアドレス（行Ｃ５）と、インタフェース１３２のＩＰアドレス（行Ｃ８）とには、同じ値が定義されている。通常のネットワークシステムにおけるＩＰアドレスは、ネットワーク内における装置やインタフェースを一意に識別するための識別子であるため、同一の値を設定することができない。しかし、インタフェース１３１と、インタフェース１３２とは、異なるＶＲＦに属している（行Ｃ４、Ｃ７）。このため、インタフェース１３１が所属するネットワークと、インタフェース１３２が所属するネットワークとが異なるため、同一のＩＰアドレスを設定することが可能となる。
【００３４】
行Ｃ９は、インタフェース１３３を定義している。行Ｃ１０は、インタフェース１３３が、第１のＶＲＦに所属することを定義している。行Ｃ１１は、次のａ）、ｂ）のことを定義している。
ａ）状態監視ルール５０（詳細は後述）により運用サーバ２０１の障害を検出した際に、インタフェース１３３を第２のＶＲＦのネットワークに所属するよう切り替えを行うこと。
ｂ）状態監視ルール５０により運用サーバ２０１の復旧を検出した際に、インタフェース１３３を第１のＶＲＦのネットワークに所属するように切り替えを行わず、第２のＶＲＦに所属したままにする（ロックする）こと。
行Ｃ１２は、インタフェース１３３のＩＰアドレスと、サブネットマスク長とを定義している。
【００３５】
行Ｃ１３は、インタフェース１３４を定義している。行Ｃ１４は、インタフェース１３４が、第１のＶＲＦに所属することを定義している。行Ｃ１５は、次のｃ）、ｄ）のことを定義している。
ｃ）状態監視ルール５０（詳細は後述）により運用サーバ２０１の障害を検出した際に、インタフェース１３４を第２のＶＲＦのネットワークに所属するよう切り替えを行うこと。
ｄ）状態監視ルール５０により運用サーバ２０１の復旧を検出した際に、インタフェース１３４を第１のＶＲＦのネットワークに所属するように切り替えを行う（リカバリする）こと。
行Ｃ１６は、インタフェース１３４のＩＰアドレスと、サブネットマスク長とを定義している。
【００３６】
行Ｃ１７は、状態監視ルール５０として、第１のＶＲＦのネットワーク内に存在する、ＩＰアドレスが１０．１．１．１を識別子とする装置へのパケットの到達性の監視を規定する。換言すれば、行Ｃ１７は、運用サーバ２０１の状態監視ルールを定義している。なお、図５では、便宜上、説明上必要としないネットワーク装置の構成情報を規定するコンフィギュレーションについては省略している。このことは、後述する図においても同様である。
【００３７】
図６は、インタフェースデータベース１４０の一例を示す説明図である。インタフェースデータベース１４０は、インタフェース番号フィールドと、ＶＲＦ番号フィールドと、ＩＰアドレスフィールドと、サブネットマスク長フィールドとを含んでいる。インタフェース番号フィールドには、ネットワーク装置１００が有するインタフェースの識別子が格納されている。ＶＲＦ番号フィールドには、インタフェースが属するＶＲＦネットワークの識別子が格納されている。ＩＰアドレスフィールドには、インタフェースのＩＰアドレスが格納されている。サブネットマスク長フィールドには、サブネットマスク（ＩＰアドレスのうちの何ビットをネットワークアドレスに使用するかを定義する３２ビットの数値）が格納されている。
【００３８】
このインタフェースデータベース１４０は、ネットワーク装置１００における構成情報を定義したコンフィギュレーションデータベース１１０（図５）に基づき保持される。すなわち、インタフェースデータベース１４０のエントリＥ１には、図５で説明したコンフィギュレーション情報の行Ｃ３〜Ｃ５で定義された情報が格納される。同様に、エントリＥ２には行Ｃ６〜Ｃ８で定義された情報が、エントリＥ３には行Ｃ９、Ｃ１０、Ｃ１２で定義された情報が、エントリＥ４には行Ｃ１３、Ｃ１４、Ｃ１６で定義された情報が、それぞれ格納される。なお、パケット転送処理部１５０は、いずれかのインタフェースからパケットを受信した際に、パケットの転送先を決定するために検索するルーティングテーブルを決定するために、このインタフェースデータベース１４０を用いる。詳細については後述する。
【００３９】
図７は、インタフェースデータベース１４０が図６で示した状態である場合における、ＶＲＦ１ルーティングテーブル１２１の一例を示す説明図である。ＶＲＦ１ルーティングテーブル１２１は、あて先ＩＰアドレスフィールドと、サブネットマスク長フィールドと、ネクストホップＩＰアドレスフィールドと、出力インタフェースフィールドとを含んでいる。あて先ＩＰアドレスフィールドには、あて先のＩＰアドレスが格納されている。サブネットマスク長フィールドには、サブネットマスクが格納されている。ネクストホップＩＰアドレスフィールドには、ネットワーク装置１００が次にパケットを転送すべき装置のＩＰアドレスが格納されている。出力インタフェースフィールドには、パケット転送処理部１５０がパケットを出力するインタフェースの識別子が格納されている。
【００４０】
ＶＲＦ１ルーティングテーブル１２１には、インタフェースデータベース１４０のＶＲＦ番号フィールドの値が「１」であるインタフェースの情報と、当該インタフェースに回線や他のネットワーク装置を介して接続されている装置の情報とが保持される。すなわち、インタフェース１３１、１３３、１３４、および、運用サーバ２０１、ホスト３０１、ホスト３０２の情報が保持される。
【００４１】
エントリＥ１には、運用サーバ２０１の情報が保持されている。具体的には、あて先ＩＰアドレスフィールドには、運用サーバ２０１のＩＰアドレスが格納されている。サブネットマスク長フィールドには、装置あてであることを示す「３２」が格納されている。ネクストホップＩＰアドレスフィールドには、運用サーバ２０１のＩＰアドレスが格納されている。これは、ネットワーク装置１００と、運用サーバ２０１とが、他の装置を経由せず、回線を介して直接接続されているためである。例えば、ネットワーク装置１００と、運用サーバ２０１とが、他の装置を経由して接続されている場合、ネクストホップＩＰアドレスフィールドには、当該他の装置のＩＰアドレスが格納される。出力インタフェースフィールドには、運用サーバ２０１と接続されているインタフェースの識別子が格納されている。
【００４２】
エントリＥ２には、ネットワーク装置１００のインタフェース１３１の情報が保持されている。ネットワーク装置１００が、インタフェース１３１のＩＰアドレスをあて先ＩＰアドレスとしたパケットを受信した場合、当該パケットは転送せずに、ネットワーク装置１００で処理をする必要がある。そのため、ネクストホップＩＰアドレスフィールドと、出力インタフェースフィールドには値が格納されていない（図中では「−」で示している）。
【００４３】
エントリＥ３にはホスト３０１の情報が、Ｅ５にはホスト３０２の情報が、それぞれ格納されている。詳細については、上述した運用サーバ２０１（エントリＥ１）と同様であるため説明を省略する。エントリＥ４にはインタフェース１３３の情報が、Ｅ６にはインタフェース１３４の情報が、それぞれ格納されている。詳細については、上述したインタフェース１３１（エントリＥ２）と同様であるため説明を省略する。
【００４４】
図８は、インタフェースデータベース１４０が図６で示した状態である場合における、ＶＲＦ２ルーティングテーブル１２２の一例を示す説明図である。ＶＲＦ２ルーティングテーブル１２２は、ＶＲＦ１ルーティングテーブル１２１と同様のテーブル構成を有している。ＶＲＦ２ルーティングテーブル１２２には、インタフェースデータベース１４０のＶＲＦ番号フィールドの値が「２」であるインタフェースの情報と、当該インタフェースに回線や他のネットワーク装置を介して接続されている装置の情報とが保持される。すなわち、インタフェース１３２、および、予備サーバ２０２の情報が保持される。
【００４５】
エントリＥ１には予備サーバ２０２の情報が格納されている。詳細については、上述した運用サーバ２０１（図７：エントリＥ１）と同様であるため説明を省略する。エントリＥ２にはインタフェース１３２の情報が格納されている。詳細については、上述したインタフェース１３１（図７：エントリＥ２）と同様であるため説明を省略する。
【００４６】
図９は、状態監視データベース１７０の一例を示す説明図である。状態監視データベース１７０は、監視ＩＤフィールドと、監視先ＩＰアドレスフィールドと、監視先ＶＲＦフィールドと、監視状態フィールドとを含んでいる。監視ＩＤフィールドには、監視対象のグループを識別するための識別子が格納されている。監視先ＩＰアドレスフィールドには、監視対象の装置のＩＰアドレスが格納されている。監視先ＶＲＦフィールドには、監視対象の装置が属するＶＲＦネットワークの識別子が格納されている。監視状態フィールドには、監視対象の装置の状態を表す文字（または記号等）が格納されている。
【００４７】
本実施例では、運用サーバ２０１と予備サーバ２０２とは、異なるＶＲＦに属し、同じＩＰアドレスが付与されている。このため、監視先ＩＰアドレスフィールドの値と、監視先ＶＲＦフィールドの値との組合せによって、監視対象となる装置を一意に識別することができる。図９の例では、監視ＩＤ５０の監視対象の装置は、監視先ＩＰアドレスフィールドの値が１０．１．１．１、かつ、監視先ＶＲＦフィールドの値が第１のＶＲＦであるため、運用サーバ２０１であることがわかる。また、状態監視フィールドの値が「通信可」であるため、運用サーバ２０１は、現在サービスの提供が可能な状態であることがわかる。
【００４８】
図１０は、障害切替データベース１８０の一例を示す説明図である。障害切替データベース１８０は、監視ＩＤフィールドと、切替対象インタフェースフィールドと、切替先ＶＲＦフィールドと、切替後動作フィールドとを含んでいる。監視ＩＤフィールドには、監視対象のグループを識別するための識別子が格納されている。切替対象インタフェースフィールドには、状態監視処理によってフェイルオーバが実行されるインタフェースの識別子が格納されている。切替先ＶＲＦフィールドには、フェイルオーバ処理によって切替が行われる、新しいＶＲＦの識別子が格納されている。切替後動作フィールドには、装置の復旧を検出した際に、インタフェースを元のＶＲＦに戻すか否かを表す文字（または記号等）が格納されている。
【００４９】
この障害切替データベース１８０は、ネットワーク装置１００における構成情報を定義したコンフィギュレーションデータベース１１０（図５）に基づいて保持される。すなわち、障害切替データベース１８０のエントリＥ１には、図５で説明したコンフィギュレーション情報の行Ｃ１１で定義された情報が格納される。同様に、エントリＥ２には行Ｃ１５で定義された情報が格納される。
【００５０】
図１１は、復旧切替データベース１９０の一例を示す説明図である。復旧切替データベース１９０は、監視ＩＤフィールドと、切替対象インタフェースフィールドと、切替先ＶＲＦフィールドとを含んでいる。監視ＩＤフィールドには、監視対象のグループを識別するための識別子が格納される。切替対象インタフェースフィールドには、復旧検出時処理によってＶＲＦの切替が行われるインタフェースの識別子が格納される。切替先ＶＲＦフィールドには、復旧検出時処理によって切替が行われるＶＲＦの識別子が格納される。復旧切替データベース１９０は、後述するフェイルオーバ処理においてエントリが追加されるデータベースであり、初期状態においては、エントリは格納されていない。
【００５１】
（Ａ−２）障害検出前の動作：
図１２は、運用サーバ２０１がサービスを提供し得る状態である場合の、ネットワークシステム１０の動作を示す説明図である。まず、図１２に示すように、ホスト３０１はサービスを提供するサーバ（運用サーバ２０１もしくは予備サーバ２０２）にアクセスするため、あて先ＩＰアドレスを１０．１．１．１とする要求パケットを送信する。このパケットは、図３で説明した自身のデフォルトゲートウェイで指定されているＩＰアドレス（換言すれば、インタフェース１３３のＩＰアドレス）へ送信する。
【００５２】
図１３は、ネットワーク装置１００におけるパケット転送処理の手順を示すフローチャートである。ネットワーク装置１００は、ホスト３０１から送信されたパケットを、インタフェース１３３において受信する（ステップＳ１１）。次に、ステップＳ１２において、パケット転送処理部１５０は、インタフェースデータベース１４０を検索する。具体的には、パケット転送処理部１５０は、インタフェースデータベース１４０のインタフェース番号フィールドの値と、パケットを受信したインタフェースの識別子とが一致するエントリを検索する。そして、パケット転送処理部１５０は、当該一致したエントリのＶＲＦ番号フィールドの値を取得する。図６および図１２の例では、パケット転送処理部１５０は、インタフェースの識別子１３３に一致するエントリＥ３のＶＲＦ番号フィールドの値「１」を取得する。
【００５３】
ステップＳ１３において、パケット転送処理部１５０は、ＶＲＦ番号に対応するルーティングテーブルを検索する。本実施例の場合は、ＶＲＦ番号が「１」の場合は第１のＶＲＦのルーティングテーブル（ＶＲＦ１ルーティングテーブル１２１）を使用する。一方、ＶＲＦ番号が「２」の場合は、第２のＶＲＦのルーティングテーブル（ＶＲＦ２ルーティングテーブル１２２）を使用する。図１２の例では、ステップＳ１２において求めたＶＲＦ番号は「１」であるため、パケット転送処理部１５０は、ＶＲＦ１ルーティングテーブル１２１を検索することとなる。すなわち、パケット転送処理部１５０は、パケット送信元の装置が所属するＶＲＦネットワーク（仮想ネットワーク）に対応した経路情報を用いて経路探索をする。
【００５４】
パケット転送処理部１５０は、ＶＲＦ１ルーティングテーブル１２１のあて先ＩＰアドレスフィールドの値と、受信したパケットのヘッダ中に含まれるあて先ＩＰアドレスを示す情報とが一致するエントリを検索する。そして、パケット転送処理部１５０は、当該一致したエントリの、ネクストホップＩＰアドレスフィールドの値と、出力インタフェースフィールドの値を取得する。図７および図１２の例では、パケット転送処理部１５０は、あて先ＩＰアドレス１０．１．１．１に一致するエントリＥ１のネクストホップＩＰアドレスフィールドの値「１０．１．１．１」と、出力インタフェースフィールドの値「１３１」とを取得する。ステップＳ１４において、パケット転送処理部１５０は、ステップＳ１３で求めた出力インタフェースからパケットを出力する。
【００５５】
上述のようにして、ホスト３０１からの要求パケットは、運用サーバ２０１へ転送される。運用サーバ２０１は、ホスト３０１から受信したパケットをもとにしてサービスを行った後、ホスト３０１に対して応答パケットを送信する。この応答パケットのあて先ＩＰアドレスは、ホスト３０１のＩＰアドレス２０．１．１．１である。このパケットは、図２で説明した自身のデフォルトゲートウェイで指定されているＩＰアドレス（換言すれば、インタフェース１３１のＩＰアドレス）へ送信する。
【００５６】
ネットワーク装置１００は、運用サーバ２０１から送信されたパケットを、１インタフェース１３１において受信する。その後、パケット転送処理部１５０は、当該受信パケットについて、図１３で説明したものと同様の処理を行うことによって、該当する出力インタフェースからパケットを出力する。この結果、運用サーバ２０１からの応答パケットは、ホスト３０１へ転送される。なお、図１２では、ホストからの要求を白抜きの矢印、サーバからの応答を斜線を施した矢印で表している（このことは、後述する同種の図においても同様である。）。このようにして、ホスト３０１と、運用サーバ２０１との間で、双方向の通信が行われることによって、運用サーバ２０１によるサービスの提供が実現する。なお、ホスト３０２についてもホスト３０１と同様の動作となる。
【００５７】
以上のように、運用サーバ２０１の障害検出前においては、運用サーバ２０１が運用系サーバとして機能している。
【００５８】
一方、予備サーバ２０２が接続されているインタフェース１３２は、図６のＶＲＦ番号フィールドの値が「２」であるため、第２のＶＲＦに属している。すなわち、第１のＶＲＦに属するインタフェース１３１、１３３、１３４に接続されている運用サーバ２０１と、ホスト３０１と、ホスト３０２とは、同一のネットワークである第１のＶＲＦに所属している。また、第２のＶＲＦに属するインタフェース１３２に接続されている予備サーバ２０２は、第２のＶＲＦに所属している。このため、図６に示したインタフェースデータベース１４０の状態においては、ホスト３０１およびホスト３０２は、予備サーバ２０２とは異なるＶＲＦネットワークに所属することとなり、予備サーバ２０２と通信を行うことはない。すなわち、障害検出前においては、予備サーバ２０２は待機系サーバとして機能している。
【００５９】
上述の通り、あるサーバを運用系サーバとするためには、サーバが回線を介して接続しているインタフェースのＶＲＦ番号と、ホストが回線を介して接続しているインタフェースのＶＲＦ番号とを同じにすればよい。一方、あるサーバを待機系サーバとするには、サーバが回線を介して接続しているインタフェースのＶＲＦ番号と、ホストが回線を介して接続しているインタフェースのＶＲＦ番号と、を異なる番号にすればよい。
【００６０】
（Ａ−３）状態監視処理：
図１４は、状態監視処理の手順を示すフローチャートである。状態監視部としてのフェイルオーバ処理部１６０は、状態監視データベース１７０を使用し、図１４のフローチャートに従ってサーバの運用状態を監視する。まず、ステップＳ５０１においてフェイルオーバ処理部１６０は、状態監視データベース１７０に記録されている監視ＩＤに対応する監視先ＩＰアドレスフィールドと、監視先ＶＲＦフィールドの値を読み出す。
【００６１】
そして、ステップＳ５０２においてフェイルオーバ処理部１６０は、読み出された監視先ＩＰアドレスと、監視先ＶＲＦの組をもとにして監視先を特定し、当該監視先に対してパケットを送信する。具体的には、ステップＳ５０１において得られるＶＲＦ番号に対応するルーティングテーブルを、ステップＳ５０１において得られる監視先ＩＰアドレスをキーとして検索することにより得られる出力先へパケットを出力する。詳細は図１３のステップＳ１３、Ｓ１４で説明した通りである。
【００６２】
例えば、図９のエントリＥ１（監視ＩＤ：５０）の例では、監視先ＶＲＦフィールドの値は「１」であるため、フェイルオーバ処理部１６０はＶＲＦ１ルーティングテーブル１２１を検索する。このとき、監視先ＩＰアドレスフィールドの値「１０．１．１．１」をキーとして、ＶＲＦ１ルーティングテーブル１２１のあて先ＩＰアドレスフィールドに一致するエントリを検索する。すると、ネクストホップＩＰアドレスは「１０．１．１．１」、出力インタフェースは「１３１」（エントリＥ１）であることが分かる。このようにして、フェイルオーバ処理部１６０は、インタフェース１３１から運用サーバ２０１へ向けてパケットを送信する。
【００６３】
なお、このとき送信されるパケットは、ＩＣＭＰ（Ｉｎｔｅｒｎｅｔ Ｃｏｎｔｒｏｌ Ｍｅｓｓａｇｅ Ｐｒｏｔｏｃｏｌ） Ｅｃｈｏ Ｒｅｑｕｅｓｔパケットであることが好ましい。なお、ＢＦＤ（Ｂｉｄｉｒｅｃｔｉｏｎａｌ Ｆｏｒｗａｒｄｉｎｇ Ｄｅｔｅｃｔｉｏｎ） Ｅｃｈｏパケットや、そのほか本ステップを実施するための独自のパケットであってもかまわない。
【００６４】
次に、ステップＳ５０３においてフェイルオーバ処理部１６０は、ステップＳ５０２で送信したパケットに対する応答パケットを待つ。例えば、ステップＳ５０２において送信したパケットがＩＣＭＰ Ｅｃｈｏ Ｒｅｑｕｅｓｔである場合、応答パケットは、ＩＣＭＰ Ｅｃｈｏ Ｒｅｐｌｙパケットになる。この応答パケットがない場合、フェイルオーバ処理部１６０は、監視の対象である装置が正常に所定のサービスを提供することができない障害状態であるものと判定する。
【００６５】
ステップＳ５０４において、フェイルオーバ処理部１６０は、応答パケットの有無を判断する。応答パケットがあった場合、ステップＳ５０５においてフェイルオーバ処理部１６０は、状態監視データベース１７０を更新する。具体的には、フェイルオーバ処理部１６０は、状態監視データベース１７０の監視ＩＤフィールドの値が現在監視中の監視ＩＤであって、かつ、監視先ＩＰアドレスフィールドの値がステップＳ５０４における応答パケットの送信元であるエントリについて、当該エントリの値を「通信可」へ更新する。その後、ステップＳ５０６においてフェイルオーバ処理部１６０は、復旧検出時処理（詳細は後述）を行う。
【００６６】
一方、応答パケットがなかった場合、ステップＳ５０７においてフェイルオーバ処理部１６０は、状態監視データベース１７０を更新する。具体的には、フェイルオーバ処理部１６０は、状態監視データベース１７０（図９）の監視ＩＤフィールドの値が現在監視中の監視ＩＤであって、かつ、監視先ＩＰアドレスフィールドの値がステップＳ５０４において、応答パケットの送信がなかった装置を示すエントリについて、当該エントリの値を「通信不可」へ更新する。その後、ステップＳ５０８においてフェイルオーバ処理部１６０は、フェイルオーバ処理（詳細は後述）を行う。
【００６７】
図１５は、図１４のステップＳ５０７において更新された後の状態監視データベース１７０を示す説明図である。障害検出前の状態監視データベース１７０を示す図９との違いは、監視ＩＤフィールドの値が「５０」、かつ、監視先ＩＰアドレスが「１０．１．１．１」を示すエントリ（エントリＥ１）の監視状態フィールドの値が「通信不可」となっている点である。
【００６８】
以上のようにして、フェイルオーバ処理部１６０は、１つの監視対象（監視ＩＤ）についての状態監視処理を行う。その後、ステップＳ５０９においてフェイルオーバ処理部１６０は、状態監視データベース１７０に格納されている、全ての監視ＩＤに対する処理を行ったかを判断する。全ての監視ＩＤに対する処理を行った場合、処理を終了する。一方、全ての監視ＩＤに対する処理を行っていない場合、フェイルオーバ処理部１６０は、ステップＳ５０１へ戻り、処理を継続する。
【００６９】
（Ａ−４）フェイルオーバ処理：
図１６は、フェイルオーバ処理（図１４：ステップＳ５０８）の手順を示すフローチャートである。フェイルオーバ処理部１６０は、状態監視処理で障害を検出した監視ＩＤと、図１０で説明した障害切替データベース１８０とを使用し、図１６のフローチャートに従って、障害検出に伴うフェイルオーバ処理を行う。
【００７０】
まず、ステップＳ６０１においてフェイルオーバ処理部１６０は、インタフェースデータベース１４０のＶＲＦ番号を切り替える。具体的には、フェイルオーバ処理部１６０は、障害切替データベース１８０（図１０）のうち、監視ＩＤフィールドの値が、状態監視処理において障害が検出された監視ＩＤと同じエントリを検索する。そして、検索されたエントリについての、切替対象インタフェースフィールドと、切替先ＶＲＦフィールドと、切替後動作フィールドの値を読み出す。次に、フェイルオーバ処理部１６０は、インタフェースデータベース１４０のインタフェース番号フィールドを、読み出された切替対象インタフェースフィールドの値をキーとして検索する。そして、該当するエントリについてのＶＲＦ番号フィールドの値を、読み出された切替先ＶＲＦフィールドの値へと変更する。
【００７１】
次に、ステップＳ６０２においてフェイルオーバ処理部１６０は、インタフェースデータベース１４０に基づいたルーティングテーブルの書き換えを行う。具体的には、まず、フェイルオーバ処理部１６０は、インタフェースデータベース１４０のうち、ＶＲＦ番号フィールドの値が「１」であるエントリの情報のみを格納するように、ＶＲＦ１ルーティングテーブル１２１を書き換える。同様に、フェイルオーバ処理部１６０は、インタフェースデータベース１４０のうち、ＶＲＦ番号フィールドの値が「２」であるエントリの情報のみを格納するように、ＶＲＦ２ルーティングテーブル１２２を書き換える。
【００７２】
ステップＳ６０３においてフェイルオーバ処理部１６０は、切替後動作がロックか否かを判定する。この判定は、ステップＳ６０１で読み出された切替後動作フィールドの値を元に行う。切替後動作フィールドの値が「ロック」である場合、ステップＳ６２０へ遷移する。一方、切替後動作フィールドの値が「ロック」で無い場合は、フェイルオーバ処理部１６０は、復旧切替データベース１９０（図１１）へ監視対象となるエントリの情報を登録する（ステップＳ６１０）。
【００７３】
ステップＳ６２０においてフェイルオーバ処理部１６０は、全ての切替対象について処理を行ったか否かを判定する。具体的には、ステップＳ６０１において検索されたエントリ（障害切替データベース１８０のうち、監視ＩＤフィールドの値が状態監視処理において障害が検出された監視ＩＤと同じエントリ）の切替対象インタフェースの全てについて、上述のステップの処理を行ったか否かを判定する。全ての切替対象について処理を行った場合、処理を終了する。一方、全ての切替対象について処理を行っていない場合、フェイルオーバ処理部１６０は、ステップＳ６０１へ戻り、処理を継続する。
【００７４】
図１７は、図１６のステップＳ６０１において更新された後のインタフェースデータベース１４０を示す説明図である。障害検出前のインタフェースデータベース１４０を示す図６との違いは、インタフェース番号フィールドの値が「１３３」、「１３４」のエントリ（エントリＥ３、Ｅ４）のＶＲＦ番号フィールドの値が「２」となっている点である。
【００７５】
図１８は、図１６のステップＳ６０２において更新された後のＶＲＦ１ルーティングテーブル１２１を示す説明図である。障害検出前のＶＲＦ１ルーティングテーブル１２１を示す図７との違いは、ステップＳ６０１で更新された後のインタフェースデータベース１４０（図１７）に基づいたルーティングテーブルの書き換えが行われている点である。具体的には、あて先ＩＰアドレスフィールドの値がインタフェース１３３、１３４のＩＰアドレスであるエントリ、および、あて先ＩＰアドレスフィールドの値がホスト３０１、３０２（インタフェース１３３、１３４に接続されている装置）のＩＰアドレスであるエントリが削除されている。
【００７６】
図１９は、図１６のステップＳ６０２において更新された後のＶＲＦ２ルーティングテーブル１２２を示す説明図である。障害検出前のＶＲＦ２ルーティングテーブル１２２を示す図８との違いは、ステップＳ６０１で更新された後のインタフェースデータベース１４０（図１７）に基づいたルーティングテーブルの書き換えが行われている点である。具体的には、あて先ＩＰアドレスフィールドの値がインタフェース１３３、１３４のＩＰアドレスであるエントリ、および、あて先ＩＰアドレスフィールドの値がホスト３０１、３０２（インタフェース１３３、１３４に接続されている装置）のＩＰアドレスであるエントリＥ３〜Ｅ６が追加されている。
【００７７】
（Ａ−５）障害検出後の動作：
図２０は、運用サーバ２０１に障害が検出された場合におけるネットワークシステム１０の動作を示す説明図である。図２０に示すように、ホスト３０１は、サービスを提供するサーバ（運用サーバ２０１もしくは予備サーバ２０２）にアクセスするため、あて先ＩＰアドレスを１０．１．１．１とする要求パケットを送信する。このパケットは、図３で説明した自身のデフォルトゲートウェイで指定されているＩＰアドレス（換言すれば、インタフェース１３３のＩＰアドレス）へ送信する。
【００７８】
ネットワーク装置１００は、ホスト３０１から送信されたパケットをインタフェース１３３において受信する（図１３：ステップＳ１１）。次に、パケット転送処理部１５０は、図１７に示したインタフェースデータベース１４０を検索し、インタフェースの識別子１３３に一致するエントリＥ３のＶＲＦフィールドの値「２」を取得する（図１３：ステップＳ１２）。ＶＲＦが２であるため、パケット転送処理部１５０は、図１９に示したＶＲＦ２ルーティングテーブル１２２を検索する（図１３：ステップＳ１３）。このようにして、パケット転送処理部１５０は、ステップＳ１３で求めた出力インタフェース１３２からパケットを出力する。
【００７９】
上述のようにして、ホスト３０１からの要求パケットは、予備サーバ２０２へ転送される。予備サーバ２０２は、ホスト３０１から受信したパケットをもとにしてサービスを行った後、ホスト３０１に対して応答パケットを送信する。この応答パケットのあて先ＩＰアドレスは、ホスト３０１のＩＰアドレス２０．１．１．１である。このパケットは、図２で説明した自身のデフォルトゲートウェイで指定されているＩＰアドレス（換言すれば、インタフェース１３２のＩＰアドレス）へ送信する。
【００８０】
ネットワーク装置１００は、予備サーバ２０２から送信されたパケットを、インタフェース１３２において受信する。その後、パケット転送処理部１５０は、当該受信パケットについて、図１３で説明したものと同様の処理を行うことによって、該当する出力インタフェースからパケットを出力する。この結果、予備サーバ２０２からの応答パケットは、ホスト３０１へ転送される。なお、ホスト３０２についてもホスト３０１と同様の動作となる。
【００８１】
以上のように、運用サーバ２０１の障害検出後においては、予備サーバ２０２が運用系サーバとして機能することがわかる。
【００８２】
（Ａ−６）復旧検出時処理：
図２１は、復旧検出時処理（図１４：ステップＳ５０６）の手順を示すフローチャートである。フェイルオーバ処理部１６０は、状態監視処理で復旧を検出した監視ＩＤと、図１１で説明した復旧切替データベース１９０とを使用し、図２１のフローチャートに従って、復旧検出に伴う復旧検出時処理を行う。
【００８３】
まず、ステップＳ６５１においてフェイルオーバ処理部１６０は、インタフェースデータベース１４０のＶＲＦ番号を切り替える。具体的には、フェイルオーバ処理部１６０は、復旧切替データベース１９０（図１１）のうち、監視ＩＤフィールドの値が、状態監視処理において復旧を検出した監視ＩＤと同じエントリを検索する。そして、検索されたエントリについての、切替対象インタフェースフィールドと、切替先ＶＲＦフィールドの値を読み出す。次に、フェイルオーバ処理部１６０は、インタフェースデータベース１４０のインタフェース番号フィールドを、読み出された切替対象インタフェースフィールドの値をキーとして検索する。そして、該当するエントリについてのＶＲＦ番号フィールドの値を、上読み出された切替先ＶＲＦフィールドの値へと変更する。
【００８４】
次に、ステップＳ６５２においてフェイルオーバ処理部１６０は、ルーティングテーブルの書き換えを行う。具体的には、まず、フェイルオーバ処理部１６０は、ステップＳ６５１において検索された切替先ＶＲＦフィールドの値をもとに、切替後に使用されるルーティングテーブルを判定する。そして、切替後に使用されるルーティングテーブルへ、ｉ）あて先ＩＰアドレスフィールドの値がステップＳ６５１において検索された切替対象インタフェースのＩＰアドレスであるエントリ、ｉｉ）あて先ＩＰアドレスフィールドの値がステップＳ６５１において検索された切替対象インタフェースに接続されている装置のＩＰアドレスであるエントリ、の情報を追加する。一方、切替後には使用されないルーティングテーブルからは、上記ｉ）、ｉｉ）に該当するエントリを削除する。
【００８５】
ステップＳ６５３においてフェイルオーバ処理部１６０は、復旧切替データベース１９０から、ステップＳ６５１、Ｓ６５２において処理を行った切替対象インタフェースを削除する。
【００８６】
ステップＳ６５４においてフェイルオーバ処理部１６０は、全ての切替対象の処理を行ったかを判定する。具体的には、ステップＳ６５１において検索されたエントリ（復旧切替データベース１９０のうち、監視ＩＤフィールドの値が状態監視処理において復旧を検出した監視ＩＤと同じエントリ）の切替対象インタフェースの全てについて、ステップＳ６５１〜Ｓ６５３の処理を行ったか否かを判定する。全ての切替対象について処理を行った場合、フェイルオーバ処理部１６０は、復旧切替データベース１９０から、状態監視処理において復旧を検出した監視ＩＤそのものを削除し、処理を終了する（ステップＳ６５５）。一方、全ての切替対象について処理を行っていない場合、フェイルオーバ処理部１６０は、ステップＳ６５１へ戻り、処理を継続する。
【００８７】
図２２は、運用サーバ２０１の復旧が検出された場合における、ステップＳ６５１（図２１）で更新された後のインタフェースデータベース１４０を示す説明図である。復旧検出前のインタフェースデータベース１４０を示す図１７との違いは、インタフェース番号フィールドの値が「１３４」のエントリ（エントリＥ４）のＶＲＦ番号フィールドの値が「１」となっている点である。
【００８８】
図２３は、運用サーバ２０１の復旧が検出された場合における、ステップＳ６５２（図２１）で更新された後のＶＲＦ１ルーティングテーブル１２１を示す説明図である。復旧検出前のＶＲＦ１ルーティングテーブル１２１を示す図１８との違いは、ｉ）あて先ＩＰアドレスフィールドの値がステップＳ６５１において検索された切替対象インタフェース（インタフェース１３４）のＩＰアドレスであるエントリ、ｉｉ）あて先ＩＰアドレスフィールドの値がステップＳ６５１において検索された切替対象インタフェースに接続されている装置（ホスト３０２）のＩＰアドレスであるエントリＥ３、Ｅ４が追加されている点である。
【００８９】
図２４は、運用サーバ２０１の復旧が検出された場合における、ステップＳ６５２（図２１）で更新された後のＶＲＦ２ルーティングテーブル１２２を示す説明図である。復旧検出前のＶＲＦ２ルーティングテーブル１２２を示す図１９との違いは、ｉ）あて先ＩＰアドレスフィールドの値がステップＳ６５１において検索された切替対象インタフェース（インタフェース１３４）のＩＰアドレスであるエントリ、ｉｉ）あて先ＩＰアドレスフィールドの値がステップＳ６５１において検索された切替対象インタフェースに接続されている装置（ホスト３０２）のＩＰアドレスである図１９のエントリＥ５、Ｅ６が削除されている点である。
【００９０】
なお、運用サーバ２０１の復旧が検出された場合における、状態監視データベース１７０の内容は、図９と同様となる。
【００９１】
（Ａ−７）復旧検出後の動作：
図２５は、運用サーバ２０１の復旧が検出された場合におけるネットワークシステム１０の動作を示す説明図である。図２５に示すように、ホスト３０１が送信した要求パケットは、ネットワーク装置１００によって、予備サーバ２０２へ転送される。予備サーバ２０２は、ホスト３０１から受信したパケットをもとにしてサービスを行った後、ホスト３０１に対して応答パケットを送信する。詳細な流れは、図２０において説明したものと同様である。このように、運用サーバ２０１が復旧した後においても、ホスト３０１は予備サーバ２０２と通信を行う。これは、障害切替データベース１８０（図１０）において、切替対象インタフェースが「１３３」であるエントリの切替後動作が「ロック」とされているためである。
【００９２】
一方、ホスト３０２が送信した要求パケットは、ネットワーク装置１００によって、運用サーバ２０１へ転送される。運用サーバ２０１は、ホスト３０２から受信したパケットをもとにしてサービスを行った後、ホスト３０２に対して応答パケットを送信する。詳細な流れは、図１２において説明したものと同様である。このように、運用サーバ２０１が復旧した後において、ホスト３０２は運用サーバ２０１と通信を行う。これは、障害切替データベース１８０（図１０）において、切替対象インタフェースが「１３４」であるエントリの切替後動作が「リカバリ」とされているためである。
【００９３】
図２６は、インタフェースデータベース１４０を初期化するためのコマンドの一例を示す説明図である。このような運用コマンドを実行することにより、インタフェースデータベース１４０のインタフェース１３３に関する情報を初期化（図６に示した状態）することができる。なお、このコマンドは、ネットワーク装置１００の管理者が、ネットワーク装置１００の管理端末（図示省略）より実行することによって機能する。このことは後述する他のコマンドについても同様である。
【００９４】
インタフェースデータベース１４０の変更に伴い、ＶＲＦ１ルーティングテーブル１２１は図７で説明した状態へ、ＶＲＦ２ルーティングテーブル１２２は図８で説明した状態へ、それぞれ変更される。このため、ネットワークシステム１０を、運用サーバ２０１に障害が発生する前の状態へ復元することが可能となる。
【００９５】
このようにすれば、第１の処理装置（運用サーバ２０１）と第２の処理装置（予備サーバ２０２）は、共に所定のサービスを提供可能であり、かつ、運用サーバ２０１と予備サーバ２０２には、同一のレイヤ３アドレス（ＩＰアドレス）を設定することができる。フェイルオーバ処理部１６０は、ホストにサービスを提供する第１の仮想ネットワーク（ＶＲＦ１）に所属する運用サーバ２０１の状態を監視し、当該サーバがサービスを提供することができない障害状態であると判定された場合に、第１の仮想ネットワークに所属しているクライアント装置（ホスト３０１、３０２）を、第２の仮想ネットワーク（ＶＲＦ２）に所属させるように、ＶＲＦ定義情報（インタフェースデータベース１４０）を更新する。なお、インタフェースデータベース１４０の更新に伴い、経路情報を格納するＶＲＦ１ルーティングテーブル１２１、ＶＲＦ２ルーティングテーブル１２２についても更新がなされる。
【００９６】
上述のように、運用系サーバである運用サーバ２０１に障害が発生した場合であっても、インタフェースデータベース１４０の更新によって、スムーズに待機系サーバである予備サーバ２０２へのフェイルオーバが可能となる。換言すれば、コールドスタンバイによるフェイルオーバ方法における、長時間のサービス停止という課題を解決することができる。また、このようなフェイルオーバは、ネットワーク装置１００が備えるフェイルオーバ処理部１６０が行うため、ホットスタンバイによるフェイルオーバ方法における、ロードバランサやＤＮＳの導入を必要としない。これらの結果、サーバネットワークシステムにおいて、構成要素の追加をすることなく、かつ、短時間でのフェイルオーバが実現できる。
【００９７】
また、上述の状態監視処理において、状態監視部としてのフェイルオーバ処理部１６０は、運用サーバ２０１とホストとが実際に通信に使用する回線を用いて、サーバの運用状態を監視する。そのため、運用サーバ２０１そのものの故障のみならず、ネットワーク装置１００と運用サーバ２０１との間の通信回線に障害が発生した場合においても、フェイルオーバを行うことが可能である。
【００９８】
さらに、状態監視部としてのフェイルオーバ処理部１６０は、運用サーバ２０１が障害状態であると判定された後においても、運用サーバ２０１の監視を継続するため、運用サーバ２０１がサービスを提供可能な状態へ復旧したことを検知することができる。そして、運用サーバ２０１の復旧を検知した場合、フェイルオーバ処理部１６０は、ＶＲＦ定義情報（インタフェースデータベース１４０）を障害状態であると判定される前の状態へと更新するリカバリ処理と、更新を行わないロック処理とを選択的に実行することができる。
【００９９】
このため、例えば、システム管理者は、運用サーバ２０１の復旧と同時にネットワークシステム１０が自動的にフェイルオーバする運用方法（リカバリ処理）と、自ら運用サーバ２０１の復旧を確認したうえで手動によりフェイルオーバさせる運用方法（ロック処理）とを選択することができる。この結果、ネットワークシステムの運用の幅を広げることができる。
【０１００】
Ｂ．第２実施例：
本発明の第２実施例では、サーバが回線を介して接続されているインタフェースのＶＲＦ番号を変更することによって、フェイルオーバを実現する構成を説明する。ネットワークシステム１０の概略構成は、図１に示した第１実施例と同様である。また、第２実施例においては、復旧切替データベース１９０は使用しない。なお、以下では、第１実施例と異なる構成および動作を有する部分についてのみ説明する。
【０１０１】
（Ｂ−１）第２実施例におけるシステム構成：
図２７は、第２実施例におけるネットワーク装置１００の構成情報を規定するコンフィギュレーション情報の一例を示す説明図である。図５に示した第１実施例との違いは、行Ｃ１１、Ｃ１５、Ｃ１７が削除されている点と、行Ｃ２０１、Ｃ２０２、Ｃ２０３が追加されている点であり、他の構成については第１実施例と同様である。
【０１０２】
行Ｃ２０１は、次のｅ）、ｆ）のことを定義している。
ｅ）状態監視ルール５０（詳細は後述）により運用サーバ２０１の障害を検出した際に、インタフェース１３１を第２のＶＲＦのネットワークに所属するよう切り替えを行うこと。
ｆ）状態監視ルール５０（詳細は後述）により予備サーバ２０２の障害を検出した際に、インタフェース１３１を元の状態に戻す（スイッチバックさせる）こと。
【０１０３】
行Ｃ２０２は、次のｇ）、ｈ）のことを定義している。
ｇ）状態監視ルール５０（詳細は後述）により運用サーバ２０１の障害を検出した際に、インタフェース１３２を第１のＶＲＦのネットワークに所属するよう切り替えを行うこと。
ｈ）状態監視ルール５０（詳細は後述）により予備サーバ２０２の障害を検出した際に、インタフェース１３２を元の状態に戻す（スイッチバックさせる）こと。
【０１０４】
行Ｃ２０３は、状態監視ルール５０として、第１のＶＲＦのネットワーク内に存在する、ＩＰアドレスが１０．１．１．１を識別子とする装置へのパケットの到達性の監視を規定する。換言すれば、行Ｃ２０３は、運用サーバ２０１の状態監視ルールを定義している。
【０１０５】
図２８は、第２実施例における障害切替データベース１８０の一例を示す説明図である。図１０に示した第１実施例との違いは、障害切替データベース１８０に格納されているエントリの内容のみである。エントリＥ２１には、図２７で説明したコンフィギュレーション情報の行Ｃ２０１で定義された情報が格納される。また、エントリＥ２２には、図２７で説明したコンフィギュレーション情報の行Ｃ２０２で定義された情報が格納される。
【０１０６】
（Ｂ−２）第２実施例における状態監視処理（１）：
第２実施例における状態監視処理は、図１４で説明した第１実施例と同じ手順により行う。しかし、第２実施例における状態監視処理では、障害の検出と後述するフェイルオーバ処理がなされることを契機として、その監視対象が、運用サーバ２０１ − 予備サーバ２０２ − 運用サーバ２０１・・・ と変化する点において第１実施例と異なる。詳細については後述する。
【０１０７】
（Ｂ−３）第２実施例におけるフェイルオーバ処理（１）：
図２９は、第２実施例におけるフェイルオーバ処理（図１４：ステップＳ５０８）の手順を示すフローチャートである。図１６に示した第１実施例との違いは、ステップＳ６０３の代わりにステップＳ６０４、Ｓ６０５が追加されている点と、ステップＳ６１１が新しく追加されている点であり、他の動作は第１実施例と同じである。
【０１０８】
ステップＳ６０４においてフェイルオーバ処理部１６０は、切替後動作がロックか否かを判定する。この判定は、ステップＳ６０１において検索されたエントリ（図２８に示した障害切替データベース１８０のうち、監視ＩＤフィールドの値が状態監視処理において障害が検出された監視ＩＤと同じエントリ）の切替後動作フィールドの値を元に行う。切替後動作フィールドの値が「ロック」である場合はステップＳ６２０へ遷移する。
【０１０９】
一方、切替後動作フィールドの値が「ロック」で無い場合、ステップＳ６０５においてフェイルオーバ処理部１６０は、切替後動作がスイッチバックであるか否かを判定する。この判定は、ステップＳ６０１で読み出した切替後動作フィールドの値を元に行う。切替後動作フィールドの値が「スイッチバック」で無い場合、ステップＳ６１０においてフェイルオーバ処理部１６０は、復旧切替データベース１９０（図１１）へ監視対象となるエントリの情報を登録した後、ステップＳ６２０へ遷移する。
【０１１０】
一方、切替後動作フィールドの値が「スイッチバック」である場合はステップＳ６１１へ遷移する。ステップＳ６１１においてフェイルオーバ処理部１６０は、障害切替データベース１８０（図２８）の切替先ＶＲＦフィールドの更新を行う。具体的には、フェイルオーバ処理部１６０は、切替先ＶＲＦフィールドの値を、インタフェースデータベース１４０の同じインタフェース番号を有するエントリであって、当該エントリのステップＳ６０１において変更される前のＶＲＦ番号フィールドの値へと更新する。
【０１１１】
図３０は、図２９のステップＳ６０１において更新された後のインタフェースデータベース１４０を示す説明図である。障害検出前のインタフェースデータベース１４０を示す図６との違いは、インタフェース番号フィールドの値が「１３１」のエントリ（エントリＥ２１）のＶＲＦ番号フィールドの値が「２」、インタフェース番号フィールドの値が「１３２」のエントリ（エントリＥ２２）のＶＲＦ番号フィールドの値が「１」となっている点である。
【０１１２】
図３１は、図２９のステップＳ６０２において更新された後のＶＲＦ１ルーティングテーブル１２１を示す説明図である。障害検出前のＶＲＦ１ルーティングテーブル１２１を示す図７との違いは、ステップＳ６０１で更新された後のインタフェースデータベース１４０（図３０）に基づいたルーティングテーブルの書き換えが行われている点である。具体的には、以下の２点である。
・インタフェース１３１を示すエントリＥ１（図７）、および、運用サーバ２０１（インタフェース１３１に接続されている装置）を示すエントリＥ２（図７）が削除されている点。
・インタフェース１３２を示すエントリＥ２１、および、予備サーバ２０２（インタフェース１３２に接続されている装置）を示すエントリＥ２２が追加されている点。
【０１１３】
図３２は、図２９のステップＳ６０２において更新された後のＶＲＦ２ルーティングテーブル１２２を示す説明図である。障害検出前のＶＲＦ２ルーティングテーブル１２２を示す図８との違いは、ステップＳ６０１で更新された後のインタフェースデータベース１４０（図３０）に基づいたルーティングテーブルの書き換えが行われている点である。具体的には、以下の２点である。
・インタフェース１３２を示すエントリＥ１（図８）、および、予備サーバ２０２（インタフェース１３２に接続されている装置）を示すエントリＥ２（図８）が削除されている点。
・インタフェース１３１を示すエントリＥ２１、および、運用サーバ２０１（インタフェース１３１に接続されている装置）を示すエントリＥ２２が追加されている点。
【０１１４】
図３３は、図２９のステップＳ６１１において更新された後の障害切替データベース１８０を示す説明図である。障害検出前の障害切替データベース１８０を示す図２８との違いは、切替対象インタフェースフィールドの値が「１３１」のエントリ（エントリＥ２１）の切替先ＶＲＦフィールドの値が「１」、切替対象インタフェースフィールドの値が「１３２」のエントリ（エントリＥ２２）の切替先ＶＲＦフィールドの値が「２」となっている点である。
【０１１５】
（Ｂ−４）第２実施例における状態監視処理（２）：
図９で説明した通り、監視ＩＤ５０の監視対象の装置は、監視先ＩＰアドレスフィールドの値が１０．１．１．１、かつ、監視先ＶＲＦフィールドの値が第１のＶＲＦである。これは、すなわち、運用サーバ２０１の障害検出前においては運用サーバ２０１であった。
【０１１６】
第２実施例において、運用サーバ２０１の障害が検出された場合の状態監視処理について考える。まず、状態監視処理によってサーバの障害が検出され（図１４：ステップＳ５０４：なし）、フェイルオーバ処理（図１４：ステップＳ５０８）が行われる。フェイルオーバ処理（図２９）によって、図２８に示した状態の障害切替データベース１８０をもとに、インタフェースデータベース１４０は図３０に示した状態へ更新される。また、インタフェースデータベース１４０の更新に伴って、ルーティングテーブル（ＶＲＦ１ルーティングテーブル１２１、ＶＲＦ２ルーティングテーブル１２２）も、図３１、３２に示した状態へ更新される。
【０１１７】
その後の状態監視処理は次のようになる。状態監視データベース１７０が図９に示した状態の場合、エントリＥ１（監視ＩＤ：５０）の例では、監視先ＶＲＦフィールドの値は「１」である。このため、状態監視処理（図１４：ステップＳ５０２）においてフェイルオーバ処理部１６０は、図３１に示したＶＲＦ１ルーティングテーブル１２１を検索する。このとき、監視先ＩＰアドレスフィールドの値「１０．１．１．１」をキーとして、ＶＲＦ１ルーティングテーブル１２１のあて先ＩＰアドレスフィールドに一致するエントリを検索する。すると、ネクストホップＩＰアドレスは「１０．１．１．１」、出力インタフェースは「１３２」（エントリＥ２１）であることが分かる。
【０１１８】
従って、フェイルオーバ処理部１６０は、インタフェース１３２から予備サーバ２０２へ向けてパケットを送信する。すなわち、このことは、図９の監視ＩＤ５０の監視対象の装置が、運用サーバ２０１から予備サーバ２０２へ変更されたことを示している。
【０１１９】
新たな監視対象である予備サーバ２０２は正常に動作している。このため、状態監視処理（図１４：ステップＳ５０３）においてフェイルオーバ処理部１６０は、応答パケットを受信する。応答パケットを受信するため、フェイルオーバ処理部１６０は、状態監視データベース１７０の監視状態フィールドの値を「通信可」へと更新し、復旧検出時処理（図１４：ステップＳ５０６）を行う。しかし、第２実施例における復旧切替データベース１９０には何も情報が登録されていないため、フェイルオーバ処理部１６０は、復旧検出時処理では何も行わない。
【０１２０】
（Ｂ−５）第２実施例におけるフェイルオーバ処理（２）：
次に、予備サーバ２０２の障害が検出された場合のフェイルオーバ処理について考える。まず、状態監視処理によってサーバの障害が検出され（図１４：ステップＳ５０４：なし）、フェイルオーバ処理（図１４：ステップＳ５０８）が行われる。フェイルオーバ処理（図２９）によって、図３３に示した状態の障害切替データベース１８０をもとに、インタフェースデータベース１４０は図６に示した状態へ更新される。また、インタフェースデータベース１４０の更新に伴って、ルーティングテーブル（ＶＲＦ１ルーティングテーブル１２１、ＶＲＦ２ルーティングテーブル１２２）も、図７、８に示した状態へ更新される。すなわち、各データベース（インタフェースデータベース１４０、ＶＲＦ１ルーティングテーブル１２１、ＶＲＦ２ルーティングテーブル１２２）が初期状態へ戻される（スイッチバックされる）ことを意味している。
【０１２１】
その後の状態監視処理は図１４で説明した流れと同じになり、監視ＩＤ５０の監視対象の装置は、運用サーバ２０１へと変更される。このように、第２実施例におけるフェイルオーバ処理部１６０は、運用サーバ２０１の障害を検出した後は、監視対象を予備サーバ２０２へ変更し、予備サーバ２０２を監視する。また、予備サーバ２０２の障害を検出した後は、監視対象を運用サーバ２０１へ変更し、運用サーバ２０１を監視する。すなわち、第２実施例における状態監視処理では、現在サービスを提供しているサーバ（いわゆる運用系サーバ）を監視対象としている。
【０１２２】
このように、第２実施例では、状態監視部としてのフェイルオーバ処理部１６０は、クライアント装置（ホスト３０１、ホスト３０２）に所定のサービスを提供する第１の仮想ネットワーク（ＶＲＦ１）に所属する処理装置（運用サーバ２０１）の状態を監視する。そして、フェイルオーバ処理部１６０は、当該処理装置（運用サーバ２０１）がサービスを提供することができない障害状態であると判定された場合に、第２の処理装置（予備サーバ２０２）と、クライアント装置（ホスト３０１、ホスト３０２）とを第１の仮想ネットワーク（ＶＲＦ１）に所属させ、第１の処理装置（運用サーバ２０１）を第２の仮想ネットワーク（ＶＲＦ２）に所属させるように、ＶＲＦ定義情報であるインタフェースデータベース１４０を更新する。このため、第１実施例と同様の効果を得ることができる。
【０１２３】
さらに、処理装置（運用サーバ２０１、予備サーバ２０２）についてのＶＲＦ定義情報を更新するため、例えば、ネットワーク中継装置１００に接続されるサーバの数が、ネットワーク中継装置１００に接続されるホストの数よりも少ない場合は、ＶＲＦ定義情報の更新量を少なくすることができる。このような場合は、フェイルオーバに要する時間を、より短縮することが可能である。
【０１２４】
Ｃ．第３実施例：
（Ｃ−１）第３実施例におけるシステム構成：
図３４は、第３実施例におけるネットワークシステム１０ａの概略構成を示す説明図である。図１で示した第１実施例との違いは、運用サーバ２０１の代わりに２台の運用サーバ２１１、２２１を備える点と、予備サーバ２０２の代わりに２台の予備サーバ２１２、２２２を備える点と、障害切替データベース１８０の代わりに障害切替経路データベース１８１を備える点と、復旧切替データベース１９０を備えない点であり、他の構成については第１実施例と同様である。なお、以下では、第１実施例と異なる構成および動作を有する部分についてのみ説明する。
【０１２５】
運用サーバ２１１は、第１のサービス（例えば、ＷＥＢサービス等）をホストに対して提供するための運用系サーバコンピュータである。運用サーバ２２１は、第２のサービス（例えば、メールサービス等）をホストに対して提供するための運用系サーバコンピュータである。予備サーバ２１２は、運用サーバ２１１がサービスを提供し得ない状態の場合にサービスを提供する待機系サーバコンピュータである。予備サーバ２２２は、運用サーバ２２１がサービスを提供し得ない状態の場合にサービスを提供する待機系サーバコンピュータである。
【０１２６】
ネットワーク装置１００ａは、４台のサーバと、２台のホストコンピュータとの間の通信を中継するレイヤ３のネットワーク中継装置である。ネットワーク装置１００ａは、４つのインタフェース（インタフェース１３１〜１３４）と、コンフィギュレーションデータベース１１０と、ＶＲＦ１ルーティングテーブル１２１と、ＶＲＦ２ルーティングテーブル１２２と、インタフェースデータベース１４０と、パケット転送処理部１５０と、フェイルオーバ処理部１６０と、状態監視データベース１７０と、障害切替経路データベース１８１とを備えている。
【０１２７】
インタフェース１３１は、運用サーバ２１１および運用サーバ２２１と回線を介して接続されている。同様に、インタフェース１３２は、予備サーバ２１２および予備サーバ２２２と、インタフェース１３３はホスト３０１と、インタフェース１３４はホスト３０２と、それぞれ回線を通じて接続されている。障害切替経路データベース１８１は、フェイルオーバ処理に用いられる情報を保持するためのデータベースである。
【０１２８】
第３実施例において第１のサービスを提供する２台のサーバ（すなわち、運用サーバ２１１および予備サーバ２１２）には、図２に示すＩＰアドレスと、サブネットマスク長と、デフォルトゲートウェイがそれぞれ設定される。すなわち、運用サーバ２１１と、予備サーバ２１２には、同じＩＰアドレスが設定される。
【０１２９】
図３５は、第３実施例において第２のサービスを提供する２台のサーバのＩＰアドレス情報の一例を示す説明図である。第２のサービスを提供する２台のサーバ（すなわち、運用サーバ２２１および予備サーバ２２２）には、図３５に示すＩＰアドレスと、サブネットマスク長と、デフォルトゲートウェイがそれぞれ設定される。すなわち、運用サーバ２２１と、予備サーバ２２２には、同じＩＰアドレスが設定される。
【０１３０】
図３６は、第３実施例におけるネットワーク装置１００ａの構成情報を規定するコンフィギュレーション情報の一例を示す説明図である。図５に示した第１実施例との違いは、行Ｃ１１、Ｃ１５が削除されている点と、行Ｃ３０１、Ｃ３０２、Ｃ３０３が追加されている点であり、他の構成については第１実施例と同様である。
【０１３１】
行Ｃ１７は、状態監視ルール５０として、第１のＶＲＦのネットワーク内に存在する、ＩＰアドレスが１０．１．１．１を識別子とする装置へのパケットの到達性の監視を規定する。換言すれば、行Ｃ１７は、運用サーバ２１１の状態監視ルールを定義している。行Ｃ３０１は、状態監視ルール５１として、第１のＶＲＦのネットワーク内に存在する、ＩＰアドレスが１０．１．１．２を識別子とする装置へのパケットの到達性の監視を規定する。換言すれば、行Ｃ３０１は、運用サーバ２２１の状態監視ルールを定義している。
【０１３２】
行Ｃ３０２は、第１のＶＲＦのネットワーク内にあるＩＰアドレス１０．１．１．１をあて先とする経路情報に関して、状態監視ルール５０で規定した監視先が障害となった場合に、出力インタフェースをインタフェース１３２に切り替えることを定義している。行Ｃ３０３は、第１のＶＲＦのネットワーク内にあるＩＰアドレス１０．１．１．２をあて先とする経路情報に関して、状態監視ルール５１で規定した監視先が障害となった場合に、出力インタフェースをインタフェース１３２に切り替えることを定義している。
【０１３３】
図３７は、第３実施例におけるＶＲＦ１ルーティングテーブル１２１の一例を示す説明図である。図７に示した第１実施例との違いは、エントリＥ３１に運用サーバ２１１の情報が保持されている点と、エントリＥ３２に運用サーバ２２１の情報が保持されている点だけである。
【０１３４】
図３８は、第３実施例におけるＶＲＦ２ルーティングテーブル１２２の一例を示す説明図である。図８に示した第１実施例との違いは、エントリＥ３１に予備サーバ２１２の情報が保持されている点と、エントリＥ３２に予備サーバ２２２の情報が保持されている点だけである。
【０１３５】
図３９は、第３実施例における状態監視データベース１７０の一例を示す説明図である。図９に示した第１実施例との違いは、監視ＩＤ５１を定義するエントリＥ３２が追加されている点である。図３９の例では、監視ＩＤ５０の監視対象の装置は、監視先ＩＰアドレスフィールドの値が１０．１．１．１、かつ、監視先ＶＲＦフィールドの値が第１のＶＲＦであるため、運用サーバ２１１であることがわかる。一方、監視ＩＤ５１の監視対象の装置は、監視先ＩＰアドレスフィールドの値が１０．１．１．２、かつ、監視先ＶＲＦフィールドの値が第１のＶＲＦであるため、運用サーバ２２１であることがわかる。また、運用サーバ２１１、２２１共に現在サービスの提供が可能な状態であることがわかる。
【０１３６】
図４０は、第３実施例における障害切替経路データベース１８１の一例を示す説明図である。障害切替経路データベース１８１は、監視ＩＤフィールドと、切替対象ＶＲＦフィールドと、切替対象経路フィールドと、切替先出力インタフェースフィールドとを含んでいる。監視ＩＤフィールドには、監視対象のグループを識別するための識別子が格納されている。切替対象ＶＲＦフィールドには、状態監視処理によってフェイルオーバが実行されるＶＲＦネットワークの識別子が格納されている。切替対象経路フィールドには、フェイルオーバ処理によって切替が行われる対象の経路を示すあて先ＩＰアドレスが格納されている。切替先出力インタフェースフィールドには、フェイルオーバ処理によって切替が行われる、新しい出力インタフェースの識別子が格納されている。
【０１３７】
この障害切替経路データベース１８１は、ネットワーク装置１００ａにおける構成情報を定義したコンフィギュレーションデータベース１１０に基づいて保持される。すなわち、障害切替経路データベース１８１のエントリＥ３１には、図３６で説明したコンフィギュレーション情報の行Ｃ３０２で定義された情報が格納される。同様に、エントリＥ３２には、行Ｃ３０３で定義された情報が格納される。
【０１３８】
（Ｃ−２）第３実施例における状態監視処理（１）：
第３実施例における状態監視処理は、図１４で説明した第１実施例と同じ手順により行う。
【０１３９】
図４１は、運用サーバ２１１に障害が発生し、図１４のステップＳ５０７において更新された後の状態監視データベース１７０を示す説明図である。障害検出前の状態監視データベース１７０を示す図３９との違いは、監視ＩＤフィールドの値が「５０」、かつ、監視先ＩＰアドレスが「１０．１．１．１」を示すエントリ（エントリＥ３１）の監視状態フィールドの値が「通信不可」となっている点である。
【０１４０】
（Ｃ−３）第３実施例におけるフェイルオーバ処理（１）：
図４２は、第３実施例におけるフェイルオーバ処理（図１４：ステップＳ５０８）の手順を示すフローチャートである。フェイルオーバ処理部１６０は、状態監視処理で障害を検出した監視ＩＤと、図４０で説明した障害切替経路データベース１８１とを使用し、図４２のフローチャートに従って、障害検出に伴うフェイルオーバ処理を行う。
【０１４１】
まず、ステップＳ７０１においてフェイルオーバ処理部１６０は、切替対象経路に対応する出力インタフェースを、切替先出力インタフェースに変更する。具体的には、フェイルオーバ処理部１６０は、障害切替経路データベース１８１（図４０）のうち、監視ＩＤフィールドの値が、状態監視処理において障害が検出された監視ＩＤと同じエントリを検索する。そして、検索されたエントリについての、切替対象ＶＲＦフィールドと、切替対象経路フィールドと、切替先出力インタフェースフィールドと、の値を読み出す。
【０１４２】
フェイルオーバ処理部１６０は、ルーティングテーブルのあて先ＩＰアドレスフィールドを、読み出された切替対象経路フィールドの値をキーとして検索する。このとき検索の対象とするルーティングテーブルは、読み出された切替対象ＶＲＦフィールドの値に対応するルーティングテーブルである。すなわち、読み出された切替対象ＶＲＦフィールドの値が「１」の場合はＶＲＦ１ルーティングテーブル１２１を検索し、「２」の場合はＶＲＦ２ルーティングテーブル１２２を検索する。フェイルオーバ処理部１６０は、検索の結果、一致したエントリについての出力インタフェースフィールドの値を一時的に記憶する。さらに、一致したエントリについての出力インタフェースフィールドの値を、読み出された切替先出力インタフェースフィールドの値へと更新する。
【０１４３】
次に、ステップＳ７０２においてフェイルオーバ処理部１６０は、切替対象出力インタフェースのＶＲＦ番号を検索する。具体的には、インタフェースデータベース１４０（図６）のインタフェース番号フィールドを、読み出された切替先出力インタフェースフィールドの値をキーとして検索する。そして、一致するエントリのＶＲＦ番号フィールドの値を取得する。
【０１４４】
ステップＳ７０３においてフェイルオーバ処理部１６０は、切替対象ＶＲＦのあて先が切替対象出力インタフェースのＶＲＦのルーティングテーブルにあるか否かを判定する。具体的には、ｉ）ステップＳ７０１で読み出された切替対象ＶＲＦフィールドの値に対応するルーティングテーブルに登録されているエントリについてのあて先ＩＰアドレスが、ｉｉ）ステップＳ７０２で取得したＶＲＦ番号フィールドの値に対応するルーティングテーブルに存在するか否かを判定する。
【０１４５】
フェイルオーバ処理部１６０は、ステップＳ７０３において存在しないと判定した場合、上記ｉ）のルーティングテーブルに登録されているあて先ＩＰアドレスの経路情報を、上記ｉｉ）のルーティングテーブルにコピーする（ステップＳ７０４）。一方、ステップＳ７０３において存在すると判定した場合、ステップＳ７０５へ遷移する。
【０１４６】
ステップＳ７０５においてフェイルオーバ処理部１６０は、全ての経路を処理したか否かを判定する。具体的には、フェイルオーバ処理部１６０は、上記ｉ）のルーティングテーブルに登録されている全てのエントリについて、ステップＳ７０３、Ｓ７０４の処理を行ったか否かを判定する。全ての経路を処理していない場合、フェイルオーバ処理部１６０は、ステップＳ７０３へ遷移する。
【０１４７】
一方、全ての経路を処理した場合、ステップＳ７０６においてフェイルオーバ処理部１６０は、切替対象出力インタフェースを、ステップＳ７０１で記憶したインタフェースに変更する。具体的には、フェイルオーバ処理部１６０は、障害切替経路データベース１８１の切替対象出力インタフェースフィールドの値を、ステップＳ７０１で一時的に記憶した値へ更新する。
【０１４８】
ステップＳ７０７においてフェイルオーバ処理部１６０は、全ての切替対象について処理を行ったか否かを判定する。具体的には、ステップＳ７０１において検索されたエントリ（障害切替経路データベース１８１のうち、監視ＩＤフィールドの値が、状態監視処理において障害が検出された監視ＩＤと同じエントリ）の切替対象インタフェースの全てについて、上述のステップの処理を行ったか否かを判定する。全ての切替対象について処理を行った場合、処理を終了する。一方、全ての切替対象について処理を行っていない場合、フェイルオーバ処理部１６０は、ステップＳ７０１へ戻り、処理を継続する。
【０１４９】
第３実施例おいて、運用サーバ２１１の障害が検出された場合のフェイルオーバ処理（図４２）について考える。まず、フェイルオーバ処理部１６０は、障害切替経路データベース１８１のうち、監視ＩＤフィールドの値が「５０」のエントリを検索する（ステップＳ７０１）。そして、フェイルオーバ処理部１６０は、切替対象ＶＲＦ「１」と、切替対象経路「１０．１．１．１」と、切替先出力インタフェース「１３２」とを読み出す。
【０１５０】
次に、フェイルオーバ処理部１６０は、切替対象ＶＲＦ「１」に対応するＶＲＦ１ルーティングテーブル１２１を、切替対象経路「１０．１．１．１」をキーとして検索する。そして、フェイルオーバ処理部１６０は、一致するエントリＥ３１の出力インタフェース「１３１」を一時的に記憶した上で、出力インタフェースフィールドの値を、読み出された切替先出力インタフェース「１３２」へと更新する。
【０１５１】
フェイルオーバ処理部１６０は、インタフェースデータベース１４０を、読み出された切替先出力インタフェース「１３２」をキーとして検索する（ステップＳ７０２）。そして、一致するエントリのＶＲＦ番号「２」を取得する。
【０１５２】
フェイルオーバ処理部１６０は、ｉ）ステップＳ７０１で読み出された切替対象ＶＲＦ「１」に対応するＶＲＦ１ルーティングテーブル１２１に登録されているエントリについてのあて先ＩＰアドレスが、ｉｉ）ステップＳ７０２で取得したＶＲＦ番号「２」に対応するＶＲＦ２ルーティングテーブル１２２に存在するか否かを判定する。そして、フェイルオーバ処理部１６０は、上記ｉ）に存在し、かつ、上記ｉｉ）に存在しないあて先ＩＰアドレスの経路情報を、ＶＲＦ２ルーティングテーブル１２２にコピーする（ステップＳ７０３、Ｓ７０４）。
【０１５３】
図４３は、図４２のステップＳ７０１において更新された後のＶＲＦ１ルーティングテーブル１２１を示す説明図である。障害検出前のＶＲＦ１ルーティングテーブル１２１を示す図３７との違いは、エントリＥ３１の出力インタフェースフィールドの値が更新されている点である。
【０１５４】
図４４は、図４２のステップＳ７０３、Ｓ７０４において更新された後のＶＲＦ２ルーティングテーブル１２２を示す説明図である。障害検出前のＶＲＦ２ルーティングテーブル１２２を示す図３８との違いは、エントリＥ３４〜Ｅ３７が追加されている点である。追加されているエントリＥ３４〜Ｅ３７は、障害検出前のＶＲＦ１ルーティングテーブル１２１に存在し、かつ、障害検出前のＶＲＦ２ルーティングテーブル１２２に存在しないあて先ＩＰアドレスの経路情報である。
【０１５５】
図４５は、図４２のステップＳ７０６において更新された後の障害切替経路データベース１８１を示す説明図である。障害検出前の障害切替経路データベース１８１を示す図４０との違いは、監視ＩＤ５０の監視情報を示すエントリＥ３１の切替先出力インタフェースフィールドの値が「１３１」へと更新されている点である。
【０１５６】
（Ｃ−４）第３実施例における障害検出後の動作：
図４６は、第３実施例において運用サーバ２１１の障害が検出された場合の第１のサービス提供時の動作を示す説明図である。図４６に示すように、ホスト３０１は、第１のサービスを提供するサーバ（運用サーバ２１１もしくは予備サーバ２１２）にアクセスするため、あて先ＩＰアドレスを１０．１．１．１とする要求パケットを送信する。
【０１５７】
ネットワーク装置１００ａは、ホスト３０１から送信されたパケットをインタフェース１３３において受信する（図１３：ステップＳ１１）。次に、パケット転送処理部１５０は、図６に示したインタフェースデータベース１４０を検索し、インタフェースの識別子１３３に一致するエントリのＶＲＦフィールドの値「１」を取得する（図１３：ステップＳ１２）。ＶＲＦが１であるため、パケット転送処理部１５０は、図４３に示したＶＲＦ１ルーティングテーブル１２１を検索する（図１３：ステップＳ１３）。このようにして、パケット転送処理部１５０は、ステップＳ１３で求めたインタフェース１３２からパケットを出力する。
【０１５８】
上述のようにして、ホスト３０１からの要求パケットは、予備サーバ２１２へ転送される。予備サーバ２１２は、ホスト３０１から受信したパケットを元にしてサービスを行った後、ホスト３０１に対して応答パケットを送信する。この応答パケットのあて先ＩＰアドレスは、ホスト３０１のＩＰアドレス２０．１．１．１である。
【０１５９】
ネットワーク装置１００ａは、予備サーバ２１２から送信されたパケットをインタフェース１３２において受信する。その後、パケット転送処理部１５０は、当該受信パケットについて、上述と同様の処理を行う。この際、インタフェースデータベース１４０のインタフェースの識別子１３２に一致するエントリのＶＲＦフィールドの値は「２」であるため、パケット転送処理部１５０は、ＶＲＦ２ルーティングテーブル１２２を検索する。この結果、予備サーバ２１２からの応答パケットはホスト３０１へ転送される。なお、ホスト３０２についてもホスト３０１と同様の動作となる。
【０１６０】
以上のように、第１のサービスを提供する運用サーバ２１１の障害検出後においては、予備サーバ２１２が第１のサービスを提供する運用系サーバとして機能することがわかる。
【０１６１】
図４７は、第３実施例において運用サーバ２１１の障害が検出された場合の第２のサービス提供時の動作を示す説明図である。図４７に示すように、ホスト３０１は、第２のサービスを提供するサーバ（運用サーバ２２１もしくは予備サーバ２２２）にアクセスするため、あて先ＩＰアドレスを１０．１．１．２とする要求パケットを送信する。
【０１６２】
ネットワーク装置１００ａは、ホスト３０１から送信されたパケットをインタフェース１３３において受信する（図１３：ステップＳ１１）。図４６の場合と同様に、パケット転送処理部１５０は、図６に示したインタフェースデータベース１４０を検索し、インタフェースの識別子１３３に一致するエントリのＶＲＦフィールドの値「１」を取得する（図１３：ステップＳ１２）。ＶＲＦが１であるため、パケット転送処理部１５０は、図４３に示したＶＲＦ１ルーティングテーブル１２１を検索する（図１３：ステップＳ１３）。このようにして、パケット転送処理部１５０は、ステップＳ１３で求めたインタフェース１３１からパケットを出力する。
【０１６３】
上述のようにして、ホスト３０１からの要求パケットは、運用サーバ２２１へ転送される。運用サーバ２２１は、ホスト３０１から受信したパケットを元にしてサービスを行った後、ホスト３０１に対して応答パケットを送信する。この応答パケットのあて先ＩＰアドレスは、ホスト３０１のＩＰアドレス２０．１．１．１である。
【０１６４】
ネットワーク装置１００ａは、運用サーバ２２１から送信されたパケットをインタフェース１３１において受信する。その後、パケット転送処理部１５０は、当該受信パケットについて、図１３で説明したものと同様の処理を行う。この際、インタフェースデータベース１４０のインタフェースの識別子１３１に一致するエントリのＶＲＦフィールドの値は「１」となるため、パケット転送処理部１５０は、ＶＲＦ１ルーティングテーブル１２１を検索する。この結果、運用サーバ２２１からの応答パケットはホスト３０１へ転送される。なお、ホスト３０２についてもホスト３０１と同様の動作となる。
【０１６５】
以上のように、第１のサービスを提供する運用サーバ２１１の障害検出後においても、障害が発生していない運用サーバ２２１は、運用サーバ２１１の障害の影響を受けることなく継続して第２のサービスを提供する運用系サーバとして機能することがわかる。
【０１６６】
（Ｃ−５）第３実施例における状態監視処理（２）：
図３９で説明した通り、監視ＩＤ５０の監視対象の装置は、監視先ＩＰアドレスフィールドの値が１０．１．１．１、かつ、監視先ＶＲＦフィールドの値が第１のＶＲＦである。これは、すなわち、運用サーバ２１１の障害検出前においては運用サーバ２１１であった。
【０１６７】
第３実施例において、運用サーバ２１１の障害が検出された場合の状態監視処理について考える。まず、状態監視処理によってサーバの障害が検出され（図１４：ステップＳ５０４：なし）、フェイルオーバ処理（図１４：ステップＳ５０８）が行われる。フェイルオーバ処理（図４２）によって、図４０に示した状態の障害切替経路データベース１８１をもとに、ＶＲＦ１ルーティングテーブル１２１は図４３に示す状態に、ＶＲＦ２ルーティングテーブル１２２は図４４に示す状態に、それぞれ更新される。
【０１６８】
その後の状態監視処理は次のようになる。状態監視データベース１７０が図３９に示した状態の場合、エントリＥ３１（監視ＩＤ：５０）の例では、監視先ＶＲＦフィールドの値は「１」である。このため、状態監視処理（図１４：ステップＳ５０２）においてフェイルオーバ処理部１６０は、図４３に示したＶＲＦ１ルーティングテーブル１２１を検索する。このとき、監視先ＩＰアドレスフィールドの値「１０．１．１．１」をキーとして、ＶＲＦ１ルーティングテーブル１２１のあて先ＩＰアドレスフィールドに一致するエントリを検索する。すると、ネクストホップＩＰアドレスは「１０．１．１．１」、出力インタフェースは「１３２」（図４３：エントリＥ３１）であることが分かる。
【０１６９】
従って、フェイルオーバ処理部１６０は、インタフェース１３２から予備サーバ２１２へ向けてパケットを送信する。すなわち、このことは、図３９のエントリＥ３１に示した監視ＩＤ５０の監視対象の装置が、運用サーバ２１１から予備サーバ２１２へ変更されたことを示している。
【０１７０】
新たな監視対象である予備サーバ２１２は正常に動作している。このため、状態監視処理（図１４：ステップＳ５０３）においてフェイルオーバ処理部１６０は、応答パケットを受信する。応答パケットを受信するため、フェイルオーバ処理部１６０は、状態監視データベース１７０の監視状態フィールドの値を「通信可」へと更新し、復旧検出時処理（図１４：ステップＳ５０６）を行う。しかし、第３実施例における復旧切替データベース１９０には何も情報が登録されていないため、フェイルオーバ処理部１６０は、復旧検出時処理では何も行わない。上述の状態監視処理の動作を行った後の状態監視データベース１７０は、図３９で示した状態となる。
【０１７１】
（Ｃ−６）第３実施例におけるフェイルオーバ処理（２）：
次に、予備サーバ２１２の障害が検出された場合のフェイルオーバ処理について考える。まず、状態監視処理によってサーバの障害が検出され（図１４：ステップＳ５０４：なし）、フェイルオーバ処理（図１４：ステップＳ５０８）が行われる。フェイルオーバ処理（図４２）では、フェイルオーバ処理部１６０は、図４５に示した障害切替経路データベース１８１のうち、監視ＩＤフィールドの値が「５０」のエントリを検索し、切替対象ＶＲＦ「１」と、切替対象経路「１０．１．１．１」と、切替先出力インタフェース「１３１」を読み出す（ステップＳ７０１）。
【０１７２】
フェイルオーバ処理部１６０は、ＶＲＦ１ルーティングテーブル１２１を、切替対象経路「１０．１．１．１」をキーとして検索する。そして、フェイルオーバ処理部１６０は、一致するエントリの出力インタフェース「１３２」を一時的に記憶した上で、出力インタフェースフィールドの値を、上記で読み出された「１３１」へと更新する。
【０１７３】
フェイルオーバ処理部１６０は、図６に示したインタフェースデータベース１４０を、読み出された切替先出力インタフェース「１３１」をキーとして検索する（ステップＳ７０２）。そして、一致するエントリのＶＲＦ番号「１」を取得する。
【０１７４】
フェイルオーバ処理部１６０は、ｉ）ステップＳ７０１で読み出された切替対象ＶＲＦ「１」に対応するＶＲＦ１ルーティングテーブル１２１に登録されているエントリについてのあて先ＩＰアドレスが、ｉｉ）ステップＳ７０２で取得したＶＲＦ番号「１」に対応するＶＲＦ１ルーティングテーブル１２１に存在するか否かを判定する。上記ｉ）、ｉｉ）共に、ＶＲＦ１ルーティングテーブル１２１を参照しているため、ステップＳ７０３の判定は必ず「ＹＥＳ」となる。すなわち、ステップＳ７０４のＩＰアドレスの経路情報のコピーは実行されない。
【０１７５】
ステップＳ７０６において、フェイルオーバ処理部１６０は、障害切替経路データベース１８１の切替先出力インタフェースの値を、上記で一時的に記憶した出力インタフェースの値「１３２」へ更新する。ステップＳ７０７においてフェイルオーバ処理部１６０は、全ての切替対象について処理を行ったと判断し、フェイルオーバ処理を終了する。
【０１７６】
なお、ステップＳ７０１において更新された後のＶＲＦ１ルーティングテーブル１２１は、図３７に示す状態となる。ステップＳ７０４は実行されないため、ＶＲＦ２ルーティングテーブル１２２は図４４に示す状態のままである。また、ステップＳ７０６において更新された後の障害切替経路データベース１８１は、図４０に示す状態となる。
【０１７７】
（Ｃ−７）第３実施例における状態監視処理（３）：
図３９で説明した通り、監視ＩＤ５０の監視対象の装置は、監視先ＩＰアドレスフィールドの値が１０．１．１．１、かつ、監視先ＶＲＦフィールドの値が第１のＶＲＦである。状態監視処理（図１４：ステップＳ５０２）においてフェイルオーバ処理部１６０は、図３７に示したＶＲＦ１ルーティングテーブル１２１を検索する。このとき、監視先ＩＰアドレスフィールドの値「１０．１．１．１」に一致するエントリから、出力インタフェースは「１３１」（図３７：エントリＥ３１）であることが分かる。従って、フェイルオーバ処理部１６０は、インタフェース１３１から運用サーバ２１１へ向けてパケットを送信する。すなわち、このことは、図３９のエントリＥ３１に示した監視ＩＤ５０の監視対象の装置が、予備サーバ２１２から運用サーバ２１１へ戻ったことを示している。
【０１７８】
（Ｃ−８）第３実施例における予備サーバの障害検出後の動作：
図４８は、第３実施例において予備サーバ２１２の障害が検出された場合の第１のサービス提供時の動作を示す説明図である。図４８に示すように、ホスト３０１は、第１のサービスを提供するサーバ（運用サーバ２１１もしくは予備サーバ２１２）にアクセスするため、あて先ＩＰアドレスを１０．１．１．１とする要求パケットを送信する。
【０１７９】
ネットワーク装置１００ａのパケット転送処理部１５０は、図６に示したインタフェースデータベース１４０を検索し、インタフェースの識別子１３３に一致するエントリのＶＲＦフィールドの値「１」を取得する（図１３：ステップＳ１２）。ＶＲＦが１であるため、パケット転送処理部１５０は、図３７に示したＶＲＦ１ルーティングテーブル１２１を検索し（図１３：ステップＳ１３）、インタフェース１３１からパケットを出力する。
【０１８０】
上述のようにして、ホスト３０１からの要求パケットは、運用サーバ２１１へ転送される。運用サーバ２１１は、ホスト３０１から受信したパケットを元にしてサービスを行った後、ホスト３０１に対して応答パケットを送信する。この応答パケットのあて先ＩＰアドレスは、ホスト３０１のＩＰアドレス２０．１．１．１である。
【０１８１】
ネットワーク装置１００ａは、運用サーバ２１１から送信されたパケットをインタフェース１３１において受信する。その後、パケット転送処理部１５０は、当該受信パケットについて、上述と同様の処理を行う。この際、インタフェースデータベース１４０のインタフェースの識別子１３１に一致するエントリのＶＲＦフィールドの値は「１」であるため、パケット転送処理部１５０は、ＶＲＦ１ルーティングテーブル１２１を検索する。この結果、運用サーバ２１１からの応答パケットはホスト３０１へ転送される。なお、ホスト３０２についてもホスト３０１と同様の動作となる。
【０１８２】
以上のように、第１のサービスを提供する予備サーバ２１２の障害検出後においては、運用サーバ２１１が第１のサービスを提供する運用系サーバとして機能することがわかる。なお、第３実施例において予備サーバ２１２の障害が検出された場合の第２のサービス提供時の動作は、図４７で説明したものと同様である。
【０１８３】
図４９は、ルーティングテーブルの内容を消去するためのコマンドの一例を示す説明図である。ネットワーク装置１００ａの管理者が、図４９に示す運用コマンドをネットワーク装置１００ａの管理端末（図示省略）より実行することで、ネットワーク装置１００ａは、ＶＲＦ２ルーティングテーブル１２２のエントリを全て消去する。その後、ネットワーク装置１００ａの学習処理部（図示省略）は、インタフェースデータベース１４０のＶＲＦ番号フィールドの値が「２」であるインタフェースと、当該インタフェースに回線や他のネットワークを介して接続されている装置とのＩＰアドレスを再学習する。そして、学習処理部は、学習した装置等の情報をＶＲＦ２ルーティングテーブル１２２へ格納する。
【０１８４】
上述の通り、一旦予備サーバ２１２を運用系サーバとして機能させた場合、運用系サーバが予備サーバ２１２から運用サーバ２１１へと戻った場合であっても、ＶＲＦ２ルーティングテーブル１２２には、ＶＲＦ１ルーティングテーブル１２１の情報がコピーされたままである。すなわち、ＶＲＦ２ルーティングテーブル１２２は、図４４に示した状態のままであり、不要なエントリＥ３４〜Ｅ３７が存在する。このようにすれば、上記のような不要なエントリを、ルーティングテーブルから削除することができ、ルーティングテーブルの不要なリソース消費を抑制することができる。
【０１８５】
図５０は、ルーティングテーブルから任意の経路情報を消去するためのコマンドの一例を示す説明図である。ネットワーク装置１００ａの管理者が、図５０に示す運用コマンドをネットワーク装置１００ａの管理端末（図示省略）より実行することで、ネットワーク装置１００ａは、ＶＲＦ１ルーティングテーブル１２１のあて先ＩＰアドレスが「１０．１．１．１」であるエントリを消去する。その後、ネットワーク装置１００ａの学習処理部（図示省略）は、インタフェースデータベース１４０のＶＲＦ番号フィールドの値が「１」であるインタフェースのうち、ＩＰアドレスが「１０．１．１．１」である情報を再学習する。そして、学習処理部は、学習した装置等の情報をＶＲＦ１ルーティングテーブル１２１へ格納する。
【０１８６】
上述の通り、一旦予備サーバ２１２を運用系サーバとして機能させた場合、予備サーバ２１２の障害を検出するまでは、予備サーバ２１２が運用系サーバとして機能する。しかし、図５０に示した運用コマンドを実行することによって、ＶＲＦ１ルーティングテーブル１２１は図３７に示す状態となる。このため、強制的に運用サーバ２１１を運用系サーバとして機能させることができる。
【０１８７】
このように、第３実施例では、状態監視部としてのフェイルオーバ処理部１６０は、クライアント装置（ホスト３０１、ホスト３０２）に所定のサービスを提供する第１の仮想ネットワーク（ＶＲＦ１）に所属する処理装置（運用サーバ２１１および運用サーバ２２１）の状態を監視する。そして、フェイルオーバ処理部１６０は、当該処理装置がサービスを提供することができない障害状態であると判定された場合に、第２の仮想ネットワークの経路情報であるＶＲＦ２ルーティングテーブル１２２に、第１の仮想ネットワークの経路情報であるＶＲＦ１ルーティングテーブル１２１中の、クライアント装置に関する経路情報をコピーする。また、ＶＲＦ１ルーティングテーブル１２１中の、第１の処理装置（運用サーバ２１１または運用サーバ２２１）のレイヤ３アドレスをあて先アドレスとするエントリの出力先インタフェースを、第２の処理装置（予備サーバ２１２または予備サーバ２２２）が接続されているインタフェースへと更新する。
【０１８８】
この結果、例えば、ネットワーク装置１００ａの１つのインタフェースに対して、レイヤ３アドレスの異なる複数の処理装置（運用サーバ２１１、運用サーバ２２１）が接続されている場合であっても、互いの処理装置の状態に影響されないフェイルオーバ処理が可能となる。
【０１８９】
Ｄ．第４実施例：
本発明の第４実施例では、運用系サーバと、待機系サーバとの両方を用いてサービスを行いつつ、フェイルオーバを実現する構成を説明する。
【０１９０】
（Ｄ−１）第４実施例におけるシステム構成：
図５１は、第４実施例におけるネットワークシステム１０ｂの概略構成を示す説明図である。図１で示した第１実施例との違いは、障害切替データベース１８０の代わりにロードバランス切替データベース１８２を備える点と、ＶＲＦ定義情報としてのＶＲＦロードバランスデータベース１４１を備える点と、復旧切替データベース１９０を備えない点であり、他の構成については第１実施例と同様である。なお、以下では、第１実施例と異なる構成および動作を有する部分についてのみ説明する。
【０１９１】
運用サーバ２０１および予備サーバ２０２は、例えば、ＷＥＢサービス等のサービスをホストに対して提供するためのサーバコンピュータである。本実施例においては、２台のサーバは共にホットスタンバイ状態でサービスを行う、いわゆる運用系サーバである。
【０１９２】
ＶＲＦロードバランスデータベース１４１は、運用サーバ２０１と、予備サーバ２０２とのどちらを選択して通信を行うかを判断するための基礎となるデータベースである。ロードバランス切替データベース１８２は、フェイルオーバ処理に用いられる情報を保持するためのデータベースである。
【０１９３】
図５２は、第４実施例におけるネットワーク装置１００ｂの構成情報を規定するコンフィギュレーション情報の一例を示す説明図である。図５に示した第１実施例との違いは、行Ｃ１０、Ｃ１１、Ｃ１４、Ｃ１５が削除されている点と、行Ｃ４０１〜Ｃ４０４が追加されている点であり、他の構成については第１実施例と同様である。
【０１９４】
行Ｃ４０１は、次のｉ）〜ｌ）のことを定義している。
ｉ）インタフェース１３３が第１のＶＲＦのネットワークに所属すること。
ｊ）行Ｃ４０２で定義する第２のＶＲＦのネットワークとロードバランスすること。
ｋ）状態監視ルール５０により運用サーバ２０１の障害を検出した際に、インタフェース１３３で受信したパケットのロードバランス先として第１のＶＲＦを対象外にすること。
ｌ）状態監視ルール５０により運用サーバ２０１の復旧を検出した際に、インタフェース１３３で受信したパケットのロードバランス先として第１のＶＲＦを対象外にしたままにする（ロックする）こと。
【０１９５】
行Ｃ４０２は、次のｍ）、ｎ）のことを定義している。
ｍ）インタフェース１３３が第２のＶＲＦのネットワークに所属すること。
ｎ）インタフェース１３３が行Ｃ４０１で定義する第１のＶＲＦのネットワークとロードバランスすること。
【０１９６】
行Ｃ４０３は、次のｏ）〜ｒ）のことを定義している。
ｏ）インタフェース１３４が第１のＶＲＦのネットワークに所属すること。
ｐ）行Ｃ４０４で定義する第２のＶＲＦのネットワークとロードバランスすること。
ｑ）状態監視ルール５０により運用サーバ２０１の障害を検出した際に、インタフェース１３４で受信したパケットのロードバランス先として第１のＶＲＦを対象外にすること。
ｒ）状態監視ルール５０により運用サーバ２０１の復旧を検出した際に、インタフェース１３４で受信したパケットのロードバランス先として第１のＶＲＦを対象にする（リカバリする）こと。
【０１９７】
行Ｃ４０４は、次のｓ）、ｔ）のことを定義している。
ｓ）インタフェース１３４が第２のＶＲＦのネットワークに所属すること。
ｔ）インタフェース１３４が行Ｃ４０３で定義する第１のＶＲＦのネットワークとロードバランスすること。
【０１９８】
図５３は、第４実施例におけるインタフェースデータベース１４０の一例を示す説明図である。図６に示した第１実施例との違いは、インタフェースデータベース１４０に格納されているエントリの内容のみである。エントリＥ４３およびエントリＥ４４のＶＲＦ番号フィールドには「ＬＢ」という値が格納されている。これは、インタフェース１３３およびインタフェース１３４からパケットを受信した際に、予め定められた規則に従ってロードバランス処理を行うことを意味している。ロードバランス処理についての詳細は後述する。
【０１９９】
図５４は、第４実施例におけるＶＲＦロードバランスデータベース１４１の一例を示す説明図である。ＶＲＦロードバランスデータベース１４１は、インタフェース番号フィールドと、ロードバランス種別フィールドと、ＶＲＦ番号フィールドとを含んでいる。インタフェース番号フィールドには、パケットを受信したインタフェースの識別子が格納される。ロードバランス種別フィールドには、ネットワーク装置１００ｂがパケットを転送する際に検索するルーティングテーブルのＶＲＦ番号を特定するための検索方法を示す情報が格納される。ＶＲＦ番号フィールドには、ロードバランス処理の対象となるＶＲＦネットワークの識別子が複数格納される。
【０２００】
図５５は、第４実施例におけるパケット転送処理の手順を示すフローチャートである。図１３に示した第１実施例との違いは、ステップＳ２１〜Ｓ２３が追加されている点だけであり、他の動作については第１実施例と同様である。ステップＳ２１においてパケット転送処理部１５０は、インタフェースデータベース１４０のインタフェース番号フィールドの値と、パケットを受信したインタフェースの識別子とが一致するエントリのＶＲＦ番号フィールドの値が「ＬＢ」であるか否かを判定する。ＶＲＦ番号フィールドの値が「ＬＢ」で無い場合、ステップＳ１３へ遷移する。
【０２０１】
ＶＲＦ番号フィールドの値が「ＬＢ」である場合、ステップＳ２２においてパケット転送処理部１５０は、ＶＲＦロードバランスデータベース１４１を検索する。具体的には、ＶＲＦロードバランスデータベース１４１のインタフェース番号フィールドの値と、パケットを受信したインタフェースの識別子とが一致するエントリを検索する。そして、パケット転送処理部１５０は、当該一致したエントリのロードバランス種別フィールドの値と、ＶＲＦ番号フィールドの値とを取得する。
【０２０２】
ステップＳ２３においてパケット転送処理部１５０は、ＶＲＦ番号を決定する。パケット転送処理部１５０は、ステップＳ２２において取得したロードバランス種別フィールドの値が示す検索方法に従ってＶＲＦ番号を決定する。図５４の例では、ロードバランス種別フィールドには「送信元ＩＰアドレス」という値が格納されている。このため、パケット転送処理部１５０は、送信元ＩＰアドレスをもとにして、所定のルールに基づいてＶＲＦ番号を決定することとなる。所定のルールとは、例えば、次のようなルールを採用することができる。
・送信元ＩＰアドレスが「２０．１．１．１」の場合はＶＲＦ番号フィールドに格納されている複数のＶＲＦネットワークの識別子のうちの前者（すなわち、ＶＲＦ番号１）をＶＲＦ番号であると決定する。
・送信元ＩＰアドレスが「３０．１．１．１」の場合はＶＲＦ番号フィールドに格納されている複数のＶＲＦネットワークの識別子のうちの後者（すなわち、ＶＲＦ番号２）をＶＲＦ番号であると決定する。
【０２０３】
なお、このルールは、上記具体例に示した内容に限らず任意のものを採用することができる。例えば、送信元ＩＰアドレスに基づくハッシュ計算等によりＶＲＦ番号を求めるものとしても良い。また、ＶＲＦ番号を特定するための検索方法は、送信元ＩＰアドレス情報に基づくものに限られない。例えば、送信元ＩＰアドレス以外の情報（受信パケット中に含まれる種々の情報）に基づいてＶＲＦ番号を決定しても良い。また、過去のパケット送信量の統計に基づいて、ＶＲＦ番号を特定することもできる。
【０２０４】
図５６は、第４実施例におけるＶＲＦ１ルーティングテーブル１２１の一例を示す説明図である。第４実施例におけるＶＲＦ１ルーティングテーブル１２１は、図７に示した第１実施例と同様である。ＶＲＦ１ルーティングテーブル１２１には、次のいずれかインタフェースの情報と、当該インタフェースに回線や他のネットワーク装置を介して接続されている装置の情報とが保持される。
・インタフェースデータベース１４０（図５３）のＶＲＦ番号フィールドの値が「１」であるインタフェース。
・インタフェースデータベース１４０（図５３）のＶＲＦ番号フィールドの値が「ＬＢ」であって、ＶＲＦロードバランスデータベース１４１のＶＲＦ番号フィールドの値に「１」が含まれているインタフェース。
すなわち、インタフェース１３１、１３３、１３４、および、運用サーバ２０１、ホスト３０１、ホスト３０２の情報が保持される。
【０２０５】
図５７は、第４実施例におけるＶＲＦ２ルーティングテーブル１２２の一例を示す説明図である。図８に示した第１実施例との違いは、エントリＥ４３〜Ｅ４６が追加されている点だけである。ＶＲＦ２ルーティングテーブル１２２には、次のいずれかインタフェースの情報と、当該インタフェースに回線や他のネットワーク装置を介して接続されている装置の情報とが保持される。
・インタフェースデータベース１４０（図５３）のＶＲＦ番号フィールドの値が「２」であるインタフェース。
・インタフェースデータベース１４０（図５３）のＶＲＦ番号フィールドの値が「ＬＢ」であって、ＶＲＦロードバランスデータベース１４１のＶＲＦ番号フィールドの値に「２」が含まれているインタフェース。
すなわち、インタフェース１３２、１３３、１３４、および、予備サーバ２０２、ホスト３０１、ホスト３０２の情報が保持される。
【０２０６】
図５８は、第４実施例におけるロードバランス切替データベース１８２の一例を示す説明図である。ロードバランス切替データベース１８２は、監視ＩＤフィールドと、切替対象インタフェースフィールドと、ロードバランス対象外ＶＲＦフィールドと、切替後状態フィールドとを含んでいる。監視ＩＤフィールドと、切替対象インタフェースフィールドと、切替後状態フィールドに格納される情報は、図１０で説明した通りである。ロードバランス対象外ＶＲＦフィールドには、監視ＩＤにおける監視対象である装置が通信可状態から通信不可状態となった場合に、ロードバランス処理の対象となるＶＲＦネットワーク群から除外する（換言すれば、ＶＲＦロードバランスデータベース１４１のＶＲＦ番号フィールドから除外する）ＶＲＦ番号が格納されている。
【０２０７】
このロードバランス切替データベース１８２は、ネットワーク装置１００ｂにおける構成情報を定義したコンフィギュレーションデータベース１１０（図５２）に基づいて保持される。すなわち、ロードバランス切替データベース１８２のエントリＥ４１には、図５２で説明したコンフィギュレーション情報の行Ｃ４０１で定義された情報が格納される。同様に、エントリＥ４２には行Ｃ４０３で定義された情報が格納される。
【０２０８】
（Ｄ−２）第４実施例における障害検出前の動作：
図５９は、運用サーバ２０１と予備サーバ２０２とがサービスを提供し得る状態である場合の、ネットワークシステム１０ｂの動作を示す説明図である。ホスト３０１からの要求パケットを受信したネットワーク装置１００ｂは、図５５に示したパケット転送処理に従ってパケットの出力先を決定する。具体的には、パケット転送処理部１５０は、図５３に示すインタフェースデータベース１４０のインタフェースの識別子１３３に一致するエントリＥ４３のＶＲＦ番号フィールドの値「ＬＢ」を取得する（ステップＳ１２）。ＶＲＦ番号が「ＬＢ」であるため、パケット転送処理部１５０はＶＲＦロードバランスデータベース１４１を検索する（ステップＳ２１、２２）。
【０２０９】
次に、パケット転送処理部１５０は、送信元ＩＰアドレス「２０．１．１．１」を元にして、ＶＲＦ番号「１」を決定する（ステップＳ２３）。ステップＳ２３で求めたＶＲＦ番号は「１」であるため、パケット転送処理部１５０は、ＶＲＦ１ルーティングテーブル１２１を検索し、出力インタフェースフィールドの値「１３１」を取得する（ステップＳ１３）。パケット転送処理部１５０は、ステップＳ１３で求めた出力インタフェース１３１からパケットを出力する（ステップＳ１４）。
【０２１０】
運用サーバ２０１は、ホスト３０１から受信したパケットをもとにしてサービスを行った後、ホスト３０１に対して応答パケットを送信する。この、応答パケット中継時には、第１のＶＲＦネットワークが使用される（図５３：エントリＥ４１）。
【０２１１】
一方、ホスト３０２からの要求パケットを受信したネットワーク装置１００ｂは、上述同様、図５５に示したパケット転送処理に従ってパケットの出力先を決定する。具体的には、パケット転送処理部１５０は、インタフェースの識別子１３４に一致するエントリＥ４４のＶＲＦ番号フィールドの値「ＬＢ」を取得する（ステップＳ１２）。ＶＲＦ番号が「ＬＢ」であるため、パケット転送処理部１５０はＶＲＦロードバランスデータベース１４１を検索する（ステップＳ２１、２２）。
【０２１２】
次に、パケット転送処理部１５０は、送信元ＩＰアドレス「３０．１．１．１」を元にして、ＶＲＦ番号「２」を決定する（ステップＳ２３）。ステップＳ２３で求めたＶＲＦ番号は「２」であるため、パケット転送処理部１５０は、ＶＲＦ２ルーティングテーブル１２２を検索し、出力インタフェースフィールドの値「１３２」を取得する（ステップＳ１３）。パケット転送処理部１５０は、ステップＳ１３で求めた出力インタフェース１３２からパケットを出力する（ステップＳ１４）。
【０２１３】
予備サーバ２０２は、ホスト３０２から受信したパケットをもとにしてサービスを行った後、ホスト３０２に対して応答パケットを送信する。この、応答パケット中継時には、第２のＶＲＦネットワークが使用される（図５３：エントリＥ４２）。
【０２１４】
以上のように、運用サーバ２０１および予備サーバ２０２の障害検出前においては、これら２台のサーバにより分散して処理が行われる。すなわち、運用サーバ２０１と、予備サーバ２０２の両方が運用系サーバとして機能している。
【０２１５】
（Ｄ−３）第４実施例における状態監視処理：
第４実施例における状態監視処理は、図１４で説明した第１実施例と同じ手順により行う。
【０２１６】
（Ｄ−４）第４実施例におけるフェイルオーバ処理：
図６０は、第４実施例におけるフェイルオーバ処理（図１４：ステップＳ５０８）の手順を示すフローチャートである。フェイルオーバ処理部１６０は、状態監視処理で障害を検出した監視ＩＤと、図５８で説明したロードバランス切替データベース１８２とを使用し、図６０のフローチャートに従って、障害検出に伴うフェイルオーバ処理を行う。
【０２１７】
まず、ステップＳ８０１においてフェイルオーバ処理部１６０は、ＶＲＦロードバランスデータベースのＶＲＦ番号からロードバランス対象外ＶＲＦを除外する。具体的には、フェイルオーバ処理部１６０は、ロードバランス切替データベース１８２（図５８）のうち、監視ＩＤフィールドの値が、状態監視処理において障害が検出された監視ＩＤと同じエントリを検索する。そして、検索されたエントリについての、切替対象インタフェースフィールドと、ロードバランス対象外ＶＲＦフィールドと、切替後状態フィールドの値を読み出す。次に、フェイルオーバ処理部１６０は、ＶＲＦロードバランスデータベース１４１のインタフェース番号フィールドを、読み出された切替対象インタフェースフィールドの値をキーとして検索する。そして、該当するエントリについてのＶＲＦ番号フィールドの値から、読み出されたロードバランス対象外ＶＲＦフィールドを除外する。
【０２１８】
ステップＳ８０２においてフェイルオーバ処理部１６０は、全ての切替対象について処理を行ったか否かを判定する。具体的には、ステップＳ８０１において検索されたエントリ（ロードバランス切替データベース１８２のうち、監視ＩＤフィールドの値が状態監視処理において障害が検出された監視ＩＤと同じエントリ）の切替対象インタフェースの全てについて、上述のステップの処理を行ったか否かを判定する。全ての切替対象について処理を行った場合、処理を終了する。一方、全ての切替対象について処理を行っていない場合、フェイルオーバ処理部１６０は、ステップＳ８０１へ戻り、処理を継続する。
【０２１９】
図６１は、図６０のステップＳ８０１において更新された後のＶＲＦロードバランスデータベース１４１を示す説明図である。障害検出前のＶＲＦロードバランスデータベース１４１を示す図５４との違いは、インタフェース番号フィールドの値が「１３３」、「１３４」のエントリ（エントリＥ４１、Ｅ４２）のＶＲＦ番号フィールドの値から「１」が除外され、「２」のみとなっている点である。
【０２２０】
図６２は、運用サーバ２０１に障害が検出された場合におけるネットワークシステム１０ｂの動作を示す説明図である。ホスト３０１からの要求パケットを受信したネットワーク装置１００ｂは、図５５に示したパケット転送処理に従ってパケットの出力先を決定する。具体的には、パケット転送処理部１５０は、図５３に示すインタフェースデータベース１４０のインタフェースの識別子１３３に一致するエントリＥ４３のＶＲＦ番号フィールドの値「ＬＢ」を取得する（ステップＳ１２）。ＶＲＦ番号が「ＬＢ」であるため、パケット転送処理部１５０は図６１に示したＶＲＦロードバランスデータベース１４１を検索する（ステップＳ２１、Ｓ２２）。
【０２２１】
次に、パケット転送処理部１５０は、送信元ＩＰアドレス「２０．１．１．１」を元にして、ＶＲＦ番号を決定する（ステップＳ２３）。なお、このとき、図６１に示したＶＲＦロードバランスデータベース１４１の、ＶＲＦ番号フィールドの値（すなわち、ロードバランス処理の対象となるＶＲＦネットワークの識別子）は「２」のみしかないため、パケット転送処理部１５０は、送信元ＩＰアドレスによらずＶＲＦ番号「２」を選択する。その後、パケット転送処理部１５０は、ＶＲＦ２ルーティングテーブル１２２を検索し、出力インタフェースフィールドの値「１３２」を取得する（ステップＳ１３）。パケット転送処理部１５０ステップＳ１３で求めた出力インタフェース１３２からパケットを出力する（ステップＳ１４）。
【０２２２】
予備サーバ２０２は、ホスト３０１から受信したパケットをもとにしてサービスを行った後、ホスト３０１に対して応答パケットを送信する。この、応答パケット中継時には、第２のＶＲＦネットワークが使用される（図５３：エントリＥ４２）。
【０２２３】
一方、ホスト３０２からの要求パケットを受信したネットワーク装置１００ｂの動作は、図５９で説明したものと同様である。
【０２２４】
以上のように、運用サーバ２０１の障害検出後においては、障害が検出されたサーバ以外のサーバ（上述の例では、予備サーバ２０２）によって処理が行われる。すなわち、障害が検出されたサーバ以外のサーバが運用系サーバとして機能する。なお、例えば、３台のサーバ（第１〜第３のサーバ）によってロードバランス処理を行っていた場合は、第１のサーバの障害検出後は、第２のサーバと、第３のサーバとの２台で分散して処理を行う。
【０２２５】
（Ｄ−５）第４実施例における復旧検出時処理：
図６３は、第４実施例における復旧検出時処理（図１４：ステップＳ５０６）の手順を示すフローチャートである。フェイルオーバ処理部１６０は、状態監視処理で復旧を検出した監視ＩＤと、図５８で説明したロードバランス切替データベース１８２とを使用し、図６３のフローチャートに従って、復旧検出に伴う復旧検出時処理を行う。
【０２２６】
まず、ステップＳ８５１においてフェイルオーバ処理部１６０は、切替後動作がロックか否かを判定する。具体的には、フェイルオーバ処理部１６０は、図５８に示したロードバランス切替データベース１８２のうち、監視ＩＤフィールドの値が、状態監視処理において復旧を検出した監視ＩＤと同じエントリを検索する。そして、検索されたエントリについての、切替対象インタフェースフィールドと、ロードバランス対象外ＶＲＦフィールドと、切替後状態フィールドの値を読み出す。読み出された切替後状態フィールドの値が「ロック」である場合、フェイルオーバ処理部１６０は、ステップＳ８５３へ遷移する。
【０２２７】
一方、読み出された切替後状態フィールドの値が「ロック」で無い場合、フェイルオーバ処理部１６０は、ステップＳ８５２において、ＶＲＦロードバランスデータベースのＶＲＦ番号にロードバランス対象外ＶＲＦを追加する。具体的には、フェイルオーバ処理部１６０は、図６１に示したＶＲＦロードバランスデータベース１４１のインタフェース番号フィールドを、読み出された切替対象インタフェースフィールドの値をキーとして検索する。そして、該当するエントリについてのＶＲＦ番号フィールドに、読み出された切替対象インタフェースフィールドの値を追加する。
【０２２８】
ステップＳ８５３においてフェイルオーバ処理部１６０は、全ての切替対象の処理を行ったかを判定する。具体的には、ステップＳ８５１において検索されたエントリ（ロードバランス切替データベース１８２のうち、監視ＩＤフィールドの値が状態監視処理において復旧を検出した監視ＩＤと同じエントリ）の切替対象インタフェースの全てについて、ステップＳ８５２、Ｓ８５２の処理を行ったか否かを判定する。全ての切替対象について処理を行った場合、フェイルオーバ処理部１６０は、処理を終了する。一方、全ての切替対象について処理を行っていない場合、フェイルオーバ処理部１６０は、ステップＳ８５１へ戻って処理を継続する。
【０２２９】
図６４は、運用サーバ２０１の復旧が検出された場合における、ステップＳ８５２（図６３）で更新された後のＶＲＦロードバランスデータベース１４１を示す説明図である。復旧検出前のＶＲＦロードバランスデータベース１４１を示す図６１との違いは、インタフェース番号フィールドの値が「１３４」のエントリ（エントリＥ４２）のＶＲＦ番号フィールドの値に「１」が追加されている点である。
【０２３０】
前述の通り、ＶＲＦロードバランスデータベース１４１のＶＲＦ番号フィールドには、ロードバランス処理の対象となるＶＲＦネットワークの識別子が格納される。すなわち、復旧検出時処理終了後のＶＲＦロードバランスデータベース１４１（図６４）の下では、インタフェース１３３から入力されたパケットは第２のＶＲＦネットワークの下で処理され、インタフェース１３４から入力されたパケットは第１または第２のＶＲＦネットワークの下で処理される。これは、図５８に示したロードバランス切替データベース１８２に従って、インタフェース１３３についてはロック動作が、インタフェース１３４についてはリカバリ動作が行われたことを示している。
【０２３１】
図６５は、コマンドの一例を示す説明図である。このような運用コマンドを実行することにより、ＶＲＦロードバランスデータベース１４１のインタフェース１３３に関する情報を初期化（図５４に示した状態）することができる。このため、ネットワークシステム１０ｂを、運用サーバ２０１に障害が発生する前の状態へ復元することが可能となる。
【０２３２】
このように、第４実施例では、パケット転送処理部１５０は、クライアント装置（ホスト３０１、ホスト３０２）からパケットを受信した際に、予め定められた規則に従ってパケットの送信元である装置毎（ホスト３０１、ホスト３０２）に、第１の仮想ネットワークの経路情報であるＶＲＦ１ルーティングテーブル１２１および第２の仮想ネットワークの経路情報であるＶＲＦ２ルーティングテーブル１２２のいずれか一方を用いて経路探索を行う。このため、２台の処理装置（運用サーバ２０１、予備サーバ２０２）の両方を、サービスの提供に使用することができる。従って、設備投資の観点から、効率の良いネットワークシステムを提供することができる。
【０２３３】
さらに、状態監視部としてのフェイルオーバ処理部１６０は、第１の仮想ネットワーク（ＶＲＦ１）に所属する第１の処理装置（運用サーバ２０１）と、第２の仮想ネットワーク（ＶＲＦ２）に所属する第２の処理装置（予備サーバ２０２）の両方の状態を監視する。そして、フェイルオーバ処理部１６０は、監視対象であるいずれか一方の処理装置が障害状態であると判定された場合に、第１の仮想ネットワークおよび第２の仮想ネットワークの両方に所属していたクライアント装置（ホスト３０１、ホスト３０２）を、障害状態であると判定された一方の処理装置が所属する仮想ネットワークから除外するように、ＶＲＦ定義情報であるＶＲＦロードバランスデータベース１４１を更新する。このため、適用例１と同様の効果を得ることができる。
【０２３４】
Ｅ．第５実施例：
本発明の第５実施例では、サービスを提供するサーバの運用状態を監視する管理用のサーバを備える構成を説明する。
【０２３５】
（Ｅ−１）第５実施例におけるシステム構成：
図６６は、第５実施例におけるネットワークシステム１０ｃの概略構成を示す説明図である。図１で示した第１実施例との違いは、管理装置としての管理サーバ２５０を備える点と、ネットワーク装置１００ｃが、インタフェース１３５を備え、状態監視データベース１７０と、障害切替データベース１８０と、復旧切替データベース１９０とを備えない点であり、他の構成については第１実施例と同様である。なお、以下では、第１実施例と異なる構成および効果を有する部分についてのみ説明する。
【０２３６】
管理サーバ２５０は、インタフェース１３５を介してネットワーク装置１００ｃと接続されている外部装置である。管理サーバ２５０は、運用サーバ２０１および予備サーバ２０２の状態監視を行い、ネットワーク装置１００ｃにフェイルオーバ処理を指示する機能を有する。
【０２３７】
管理サーバ２５０は、フェイルオーバ管理部２５１と、状態監視データベース２５４と、障害切替データベース２５３と、復旧切替データベース２５２とを備えている。フェイルオーバ管理部２５１についての詳細は後述する。状態監視データベース２５４の構成は、状態監視データベース１７０（図９）と同様である。障害切替データベース２５３の構成は、障害切替データベース１８０（図１０）と同様である。復旧切替データベース２５２の構成は、復旧切替データベース１９０（図１１）と同様である。
【０２３８】
本実施例におけるネットワーク装置１００ｃのフェイルオーバ処理部１６０は、管理サーバ２５０からの指示を受け付け、フェイルオーバ処理を実行する処理部である。なお、管理サーバ２５０に設定されるＩＰアドレス、サブネットマスク長、デフォルトゲートウェイは、以後の説明には不要であるため説明を省略する。
【０２３９】
図６７は、第５実施例におけるネットワーク装置１００ｃの構成情報を規定するコンフィギュレーション情報の一例を示す説明図である。図５に示した第１実施例との違いは、行Ｃ１１、Ｃ１５が削除されている点と、行Ｃ５０１〜Ｃ５０３が追加されている点であり、他の構成については第１実施例と同様である。
【０２４０】
行Ｃ５０１は、インタフェース１３５を定義している。インタフェースの種類はイーサネット（登録商標）である。行Ｃ５０２は、インタフェース１３５のＩＰアドレスと、サブネットマスク長とを定義している。行Ｃ５０３は、フェイルオーバを指示するサーバが管理サーバ２５０であることを定義している。この行Ｃ５０３の定義は省略可能である。しかし、意図しない外部装置からのフェイルオーバ指示に基づいてネットワーク装置１００ｃが動作することを抑制するためには、行Ｃ５０３の定義を省略しない方が好ましい。
【０２４１】
なお、インタフェース１３１〜１３４とは異なり、インタフェース１３５には所属するＶＲＦネットワークの定義がされていない。これは、インタフェース１３５はどのＶＲＦネットワークにも所属しないインタフェースであることを意味している。
【０２４２】
図６８は、第５実施例におけるインタフェースデータベース１４０の一例を示す説明図である。図６に示した第１実施例との違いは、エントリＥ５５が追加されている点のみである。エントリＥ５５は、図６７で説明したコンフィギュレーション情報の行Ｃ５０１、Ｃ５０２で定義された情報が格納される。
【０２４３】
（Ｅ−２）第５実施例における状態監視処理：
図６９は、第５実施例における状態監視処理の手順を示すフローチャートである。管理サーバ２５０のフェイルオーバ管理部２５１は、状態監視データベース２５４を使用し、図６９のフローチャートに従ってサーバ（運用サーバ２０１、予備サーバ２０２）の運用状態を監視する。まず、ステップＳ９０１においてフェイルオーバ管理部２５１は、状態監視データベース２５４に基づいて、サーバの監視を行う。この監視における障害（または復旧）有無の判断は、例えば、定期的に監視対象となるサーバに対してパケットを送信し、当該パケットに対する応答パケットの有無により行うことができる。また、他の方法（例えば、ネットワーク装置１００ｃが障害および復旧の監視を行い、その結果を管理サーバ２５０へ定期的に送信するような方法）を採用することもできる。
【０２４４】
ステップＳ９０２においてフェイルオーバ管理部２５１は、状態監視の結果を判定する。監視対象の障害が検出された場合、ステップＳ９０３においてフェイルオーバ管理部２５１は、状態監視データベース２５４の該当するエントリを「通信不可」へと更新する（詳細は、図１４のステップＳ５０７と同様）。その後、ステップＳ９０４においてフェイルオーバ管理部２５１は、フェイルオーバ処理（詳細は後述）を行う。
【０２４５】
一方、ステップＳ９０２において監視対象の復旧が検出された場合、ステップＳ９０５においてフェイルオーバ管理部２５１は、状態監視データベース２５４の該当するエントリを「通信可」へと更新する（詳細は、図１４のステップＳ５０５と同様）。その後、ステップＳ９０６においてフェイルオーバ管理部２５１は、復旧検出時処理（詳細は後述）を行う。
【０２４６】
（Ｅ−３）第５実施例におけるフェイルオーバ処理：
図７０は、フェイルオーバ処理（図６９：ステップＳ９０４）の手順を示すフローチャートである。本フローチャートの左欄には、管理サーバ２５０のフェイルオーバ管理部２５１が行う処理を記載している。また、右欄にネットワーク装置１００ｃのフェイルオーバ処理部１６０が行う処理を記載している。また、このことは後述する図７１についても同様である。
【０２４７】
まず、ステップＳ９１１においてフェイルオーバ管理部２５１は、ＶＲＦ番号の切替指示を行う。具体的には、障害切替データベース２５３のうち、監視ＩＤフィールドの値が、状態監視処理において障害が検出された監視ＩＤと同じエントリを検索する。そして、検索されたエントリについての、切替対象インタフェースフィールドと、切替先ＶＲＦフィールドと、切替後動作フィールドの値を読み出す。そして、読み出された値をもとにインタフェースデータベース１４０の更新を行うための指示を、ネットワーク装置１００ｃのフェイルオーバ処理部１６０に対して送信する。
【０２４８】
これを受信したフェイルオーバ処理部１６０は、ステップＳ９１２において、示された内容に基づくインタフェースデータベース１４０の書換えを行う。その後のルーティングテーブルの書換え（ステップＳ６０２）についても、第１実施例と同様である。
【０２４９】
ステップＳ９１３においてフェイルオーバ管理部２５１は、切替後動作がロックか否かを判定する。この判定は、ステップＳ９１１で読み出された切替後動作フィールドの値を元に行う。切替後動作フィールドの値が「ロック」である場合、ステップＳ９１５へ遷移する。一方、切替後動作フィールドの値が「ロック」で無い場合は、フェイルオーバ管理部２５１は、復旧切替データベース２５２へ監視対象となるエントリの情報を登録する（ステップＳ９１４）。ステップＳ９１５においてフェイルオーバ管理部２５１は、全ての切替対象について処理を行ったか否かを判定する。全ての切替対象について処理を行った場合、処理を終了する。一方、全ての切替対象について処理を行っていない場合、フェイルオーバ管理部２５１は、ステップＳ９１１へ戻り、処理を継続する。
【０２５０】
（Ｅ−４）第５実施例における復旧検出時処理：
図７１は、復旧検出時処理（図６９：ステップＳ９０６）の手順を示すフローチャートである。まず、ステップＳ９２１においてフェイルオーバ管理部２５１は、ＶＲＦ番号の切替指示を行う。具体的には、復旧切替データベース２５２のうち、監視ＩＤフィールドの値が、状態監視処理において復旧を検出した監視ＩＤと同じエントリを検索する。そして、検索されたエントリについての、切替対象インタフェースフィールドと、切替先ＶＲＦフィールドの値を読み出す。そして、読み出された値をもとにインタフェースデータベース１４０の更新を行うための指示を、ネットワーク装置１００ｃのフェイルオーバ処理部１６０に対して送信する。
【０２５１】
これを受信したフェイルオーバ処理部１６０は、ステップＳ９２２において、示された内容に基づくインタフェースデータベース１４０の書換えを行う。その後のルーティングテーブルの書換え（ステップＳ６５２）についても、第１実施例と同様である。ステップＳ９２３においてフェイルオーバ管理部２５１は、復旧切替データベース２５２から、ステップＳ９２１〜Ｓ６５２において処理を行った切替対象インタフェースを削除する。
【０２５２】
ステップＳ９２４においてフェイルオーバ管理部２５１は、全ての切替対象の処理を行ったかを判定する。全ての切替対象について処理を行った場合、フェイルオーバ管理部２５１は、復旧切替データベース２５２から、状態監視処理において復旧を検出した監視ＩＤそのものを削除し、処理を終了する。一方、全ての切替対象について処理を行っていない場合、フェイルオーバ管理部２５１は、ステップＳ９２１へ戻り、処理を継続する。
【０２５３】
本実施例では、管理サーバ２５０のフェイルオーバ管理部２５１が、第１実施例のフェイルオーバ処理部１６０が実施していた機能の一部を実施している。その他の点（例えば、フェイルオーバ処理や、復旧検出時処理の実体的な処理内容）については、第１実施例と同様である。
【０２５４】
このように、第５実施例では、管理装置（管理サーバ２５０）のフェイルオーバ管理部２５１は、ネットワーク装置１００ｃのフェイルオーバ処理部１６０に対して、経路情報およびＶＲＦ定義情報の少なくともいずれか一方を更新するためのフェイルオーバ指示を送信する。このため、ネットワーク中継装置の管理装置が予め外部に設けられているような構成においても、適用例１と同様の効果を得ることができる。
【０２５５】
また、管理サーバ２５０は、ネットワーク装置１００ｃよりも高度な処理能力を有する場合が多い。従って、例えば、状態監視処理において、障害状態であるか否かの判定以外のより高度な判定（例えば、処理装置のＣＰＵ利用率等）を行うこともできる。
【０２５６】
Ｆ．変形例：
なお、この発明は上記の実施例や実施形態に限られるものではなく、その要旨を逸脱しない範囲において種々の態様において実施することが可能であり、例えば次のような変形も可能である。
【０２５７】
Ｆ１．変形例１：
上記実施例では、説明を簡単にするため、２つのＶＲＦを使用する構成について説明した。しかし、ネットワーク装置が備えるＶＲＦの個数は任意に定めることができる。また、ネットワーク装置は、ＶＲＦ属性を持たないグローバルネットワークを含むものとしても良い。この場合、当該グローバルネットワークは、ＶＲＦ属性を持たない一種のＶＲＦとして考えることも可能である。
【０２５８】
Ｆ２．変形例２：
上記実施例では、ネットワークシステム構成の一例を示した。しかし、ネットワークシステム構成は、上述した態様に限らず、本発明の要旨を逸脱しない範囲において任意に定めることができる。具体的には、例えば、ネットワークシステムを構成するサーバやホストの台数は任意に決定することができる。また、サーバやホストは、ネットワーク装置と他のネットワーク装置を介して間接的に接続されるものとしても良い。
【０２５９】
Ｆ３．変形例３：
上記実施例では、ネットワーク装置の構成の一例を示した。しかし、ネットワーク装置の構成は、上述した態様に限らず、本発明の要旨を逸脱しない範囲において任意に定めることができる。具体的には、例えば、ネットワーク装置が有するインタフェースを、ＶＬＡＮ（Ｖｉｒｔｕａｌ Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）で多重化する論理的なインタフェースであるものとすることができる。また、リンクアグリゲーションや、トンネルインタフェースや、ＭＰＬＳ（Ｍｕｌｔｉ-Ｐｒｏｔｏｃｏｌ Ｌａｂｅｌ Ｓｗｉｔｃｈｉｎｇ）のＬＳＰ（Ｌａｂｅｌ Ｓｗｉｔｃｈｅｄ Ｐａｔｈ）といった仮想的なインタフェースを用いても良い。
【０２６０】
Ｆ４．変形例４：
上記実施例では、ネットワーク装置が備える各テーブルについて、その構成の一例を示した。しかし、これらのテーブルが備えるフィールドは、その発明の要旨を逸脱しない範囲において任意に定めることができる。例えば、上記に例示したフィールド以外のフィールドを備えるものとしても良い。また、各テーブルには、ダイレクトマップ方式を用いることも可能である。
【０２６１】
Ｆ５．変形例５：
上記実施例では、状態監視処理における監視対象は、サービスを提供している運用サーバであるものとした。しかし、状態監視処理における監視対象は、任意に定めることができる。例えば、直接サービスを行わないサーバ装置を監視対象とすることもできる。具体的には、サービスを提供するために必要なデータベースサーバや、記憶装置を監視対象としてもよい。このようにすれば、監視対象の装置を、ネットワークシステムの構成によって柔軟に設定することが可能となる。
【０２６２】
Ｆ６．変形例６：
上記実施例では、状態監視処理の一例を示した。しかし、状態監視処理は、上記実施例において例示した方法に限らず、任意の方法を採用することができる。例えば、ネットワーク装置とサーバとの間にＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）セッションを確立させておき、前記ＴＣＰセッションの切断をもって障害の検出としてもよく、ＴＣＰセッションが未確立な状態から、確立した状態になったことをもって、障害からの復旧を検出したとしてもよい。また、サーバの状態を検出するためのセッションは、ＴＣＰセッションに限定する必要もなく、ＢＦＤセッションなどのその他のセッションを利用してもよい。また、ネットワーク装置は、サーバが提供しているサービスにアクセスすることでサーバの運用状態を監視してもよい。
【０２６３】
Ｆ７．変形例７：
上記第５実施例では、管理サーバのフェイルオーバ管理部が、第１実施例のフェイルオーバ処理部が実施していた機能の一部を担うものとして記載した。しかし、このような構成は、第１実施例に限られない。例えば、ネットワーク装置の外部に設けられた管理サーバが、第２〜第５実施例で説明したフェイルオーバ処理部の機能の一部を実施するものとして構成することもできる。例えば、管理サーバ２５０が、第４実施例で説明したロードバランス処理を行う構成とすれば、さらに高度なロードバランス（例えば、サーバのＣＰＵ利用率に応じたロードバランス）を実現することが可能である。
【０２６４】
Ｆ８．変形例８：
上記第２〜５実施例は、上記第１実施例からの構成変更であるものとして記載した。しかし、上記第２〜５実施例は、第１実施例以外の実施例からの構成変更として適用することも可能である。またこれら上記第１〜５実施例を組み合わせて適用することもできる。
【符号の説明】
【０２６５】
１０、１０ａ〜ｃ…ネットワークシステム
５０…状態監視ルール
５１…状態監視ルール
１００、１００ａ〜ｃ…ネットワーク装置
１１０…コンフィギュレーションデータベース
１２１…ＶＲＦ１ルーティングテーブル
１２２…ＶＲＦ２ルーティングテーブル
１３１…インタフェース
１３２…インタフェース
１３３…インタフェース
１３４…インタフェース
１３５…インタフェース
１４０…インタフェースデータベース
１４１…ＶＲＦロードバランスデータベース
１５０…パケット転送処理部
１６０…フェイルオーバ処理部
１７０…状態監視データベース
１８０…障害切替データベース
１８１…障害切替経路データベース
１８２…ロードバランス切替データベース
１９０…復旧切替データベース
２０１…運用サーバ
２０２…予備サーバ
２１１…運用サーバ
２１２…予備サーバ
２２１…運用サーバ
２２２…予備サーバ
２５０…管理サーバ
２５１…フェイルオーバ管理部
２５２…復旧切替データベース
２５３…障害切替データベース
２５４…状態監視データベース
３０１…ホスト
３０２…ホスト
【図１】
0005498102.tif 000002
【図２】
0005498102.tif 000003
【図３】
0005498102.tif 000004
【図４】
0005498102.tif 000005
【図５】
0005498102.tif 000006
【図６】
0005498102.tif 000007
【図７】
0005498102.tif 000008
【図８】
0005498102.tif 000009
【図９】
0005498102.tif 000010
【図１０】
0005498102.tif 000011
【図１１】
0005498102.tif 000012
【図１２】
0005498102.tif 000013
【図１３】
0005498102.tif 000014
【図１４】
0005498102.tif 000015
【図１５】
0005498102.tif 000016
【図１６】
0005498102.tif 000017
【図１７】
0005498102.tif 000018
【図１８】
0005498102.tif 000019
【図１９】
0005498102.tif 000020
【図２０】
0005498102.tif 000021
【図２１】
0005498102.tif 000022
【図２２】
0005498102.tif 000023
【図２３】
0005498102.tif 000024
【図２４】
0005498102.tif 000025
【図２５】
0005498102.tif 000026
【図２６】
0005498102.tif 000027
【図２７】
0005498102.tif 000028
【図２８】
0005498102.tif 000029
【図２９】
0005498102.tif 000030
【図３０】
0005498102.tif 000031
【図３１】
0005498102.tif 000032
【図３２】
0005498102.tif 000033
【図３３】
0005498102.tif 000034
【図３４】
0005498102.tif 000035
【図３５】
0005498102.tif 000036
【図３６】
0005498102.tif 000037
【図３７】
0005498102.tif 000038
【図３８】
0005498102.tif 000039
【図３９】
0005498102.tif 000040
【図４０】
0005498102.tif 000041
【図４１】
0005498102.tif 000042
【図４２】
0005498102.tif 000043
【図４３】
0005498102.tif 000044
【図４４】
0005498102.tif 000045
【図４５】
0005498102.tif 000046
【図４６】
0005498102.tif 000047
【図４７】
0005498102.tif 000048
【図４８】
0005498102.tif 000049
【図４９】
0005498102.tif 000050
【図５０】
0005498102.tif 000051
【図５１】
0005498102.tif 000052
【図５２】
0005498102.tif 000053
【図５３】
0005498102.tif 000054
【図５４】
0005498102.tif 000055
【図５５】
0005498102.tif 000056
【図５６】
0005498102.tif 000057
【図５７】
0005498102.tif 000058
【図５８】
0005498102.tif 000059
【図５９】
0005498102.tif 000060
【図６０】
0005498102.tif 000061
【図６１】
0005498102.tif 000062
【図６２】
0005498102.tif 000063
【図６３】
0005498102.tif 000064
【図６４】
0005498102.tif 000065
【図６５】
0005498102.tif 000066
【図６６】
0005498102.tif 000067
【図６７】
0005498102.tif 000068
【図６８】
0005498102.tif 000069
【図６９】
0005498102.tif 000070
【図７０】
0005498102.tif 000071
【図７１】
0005498102.tif 000072