復旧システム、復旧方法、冗長制御装置及び冗長制御プログラム
【課題】予備拠点及び予備サーバを用意するためのコストを軽減し、サービス中断時間を短縮することができるようにする。
【解決手段】本発明の復旧システムは、各拠点に、サービス提供を実行する第１サーバと待機する第２サーバと上記サービス提供に必要なサービスデータを保存するデータ保存手段とを有して、サービスの提供を行う１又は複数のノードを備え、各ノードは、他の拠点に設置された他ノードとの間で代替関係が設定されており、データ保存手段は、自ノードが提供するサービスのサービスデータと、他の拠点の代替関係にある他ノードが提供するサービスのサービスデータとを保存するものであり、第２サーバが、第１サーバの障害又は他拠点の代替関係にある他ノードの障害発生時に、データ保存手段から必要なサービスデータを取得して、障害の生じたサービスの提供を実行することを特徴とする。
【解決手段】本発明の復旧システムは、各拠点に、サービス提供を実行する第１サーバと待機する第２サーバと上記サービス提供に必要なサービスデータを保存するデータ保存手段とを有して、サービスの提供を行う１又は複数のノードを備え、各ノードは、他の拠点に設置された他ノードとの間で代替関係が設定されており、データ保存手段は、自ノードが提供するサービスのサービスデータと、他の拠点の代替関係にある他ノードが提供するサービスのサービスデータとを保存するものであり、第２サーバが、第１サーバの障害又は他拠点の代替関係にある他ノードの障害発生時に、データ保存手段から必要なサービスデータを取得して、障害の生じたサービスの提供を実行することを特徴とする。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、復旧システム、復旧方法、冗長制御装置及び冗長制御プログラムに関し、例えば、火災や地震等のように大規模な災害によって、ある拠点に設置したサーバ全体が使用不可能となった場合に、当該サーバが提供していたサービスを迅速に復旧させるシステムや方法等に適用し得るものである。
【背景技術】
【０００２】
例えば、コールサーバ等のように音声通信を実現するサーバは高可用性が求められており、サーバ等に障害が発生した場合には、迅速かつ確実にサービスを復旧することが求められている。
【０００３】
従来、上記のような高可能性が求められるサーバの復旧システムとしては、主として、次に示すような第１の方法〜第３の方法を用いて実現している。
【０００４】
（第１の方法）
第１の方法は、例えば、２台のサーバが論理的に１台のサーバのように見せかける方法である。第１の方法について図２を用いて説明する。
【０００５】
第１の方法では、サービスを提供するために参照する各種データは、２台のサーバ５１０及び５２０が共有して使用するストレージ５３０に格納されている。
【０００６】
２台のサーバをそれぞれ０系サーバ５１０、１系サーバ５２０とし、２台のサーバと共有ストレージ５３０とを有してサービスを提供する単位を「ノード５００」と呼ぶことにする。また、ノード５００がサービスを提供する際に参照するデータを総称して、そのノード５００の「サービスデータ」を呼ぶことにする。
【０００７】
ＩＰアドレスは、割り当て単位、及び、使用目的に応じて、物理ＩＰアドレスと論理ＩＰアドレスを使用する。物理ＩＰアドレスは、サーバ単位に固定的に割り当て、サーバの稼働状態を監視する目的等で使用する。論理ＩＰアドレスは、ノード単位に付与し、そのノードがサービスを提供するために使用する。
【０００８】
２台のサーバの内、どちらか一方のサーバの稼働状態だけが「運転中」に設定され、もう一方のサーバの稼働状態は「待機中」に設定される。このとき、「運転中」のサーバに対して、ノードに割り当てられた論理ＩＰアドレスを設定し、「運転中」のサーバがストレージ内のサービスデータを参照しながらサービスを提供する。
【０００９】
例えば、図２（Ａ）では、０系サーバ５１０が「運転中」となり、１系サーバが「待機中」となっている。その結果、０系サーバ５１０に論理ＩＰアドレス「172.16.1.1」が設定され、０系サーバ５１０がストレージ５３０内のサービスデータを参照してサービスを提供している。
【００１０】
そして、「運転中」のサーバが故障により使用不能となった場合には、「稼働中」のサーバの稼働状態が「運転中」に変わり、サービスの提供を引き継ぐ。その後、故障したサーバが修理されて復旧した場合、復旧したサーバの稼働状態は「待機中」となる。
【００１１】
例えば、図２（Ａ）において、「運転中」の０系サーバ５１０が故障した場合には、１系サーバ５２０の稼働状態が「待機中」から「運転中」に変更され、図２（Ｂ）に示す状態となる。
【００１２】
図２（Ｂ）では、０系サーバ５１０が「故障中」のため、１系サーバ５２０が「運転中」となっている。その結果、１系サーバ５２０に論理ＩＰアドレス「172.16.1.1」が設定され、１系サーバ５２０がストレージ５３０内のサービスデータを参照してサービスを提供することになる。また図２（Ｂ）において、「故障中」の０系サーバ５１０が復旧した場合には、０系サーバ５２０の稼働状態が「待機中」に設定され、図２（Ｃ）に示す状態となる。
【００１３】
上記のように、第１の方法では、０系サーバと１系サーバの間でサービスを提供するサーバが切り替わってもサービスを提供するＩＰアドレスは同一の論理ＩＰアドレスであるため、このノードと通信する他のノードから見た場合、サービスの中断時間はサーバの切り替え時間だけの短時間で済む。
【００１４】
また、第１の方法では、サービスを提供するために使用する論理的ＩＰアドレスを２台のサーバ間で動的に設定するため、２台のサーバは、同一拠点の同一サブネット内に設置する必要がある。
【００１５】
このため、第１の方法の場合、故障のため片方のサーバが使用不能となる状況においては、短時間でサービスを回復することができるが、被災拠点内の全サーバが使用不能となるような状況においては、０系サーバと１系サーバの両方が同時に使用不能となるため、サービスを回復することができない。
【００１６】
（第２の方法）
第２の方法は、拠点内の運用サーバの他に、予備サーバを設置しておく方法である。このとき、予備サーバのストレージには、同一拠点内の全ての運用サーバから、定期的にサービスデータをコピーしておく。第２の方法について図３を用いて説明する。
【００１７】
通常は、運用サーバに対して、ノードに割り当てられた論理ＩＰアドレスを設定し、運用サーバがストレージ内のサービスデータを参照しながらサービスを提供する。
【００１８】
図３（Ａ）では、運用サーバ５４０に論理ＩＰアドレス「172.16.1.1」が設定され、運用サーバ５４０がストレージ５５０内のサービスデータを参照してサービスを提供する。
【００１９】
そして、運用サーバが故障により使用不能となった場合には、予備サーバがサービスの提供を引き継ぐ。その後、故障した運用サーバが修理されて復旧した場合には、予備サーバから運用サーバにサービスの提供を引き継ぐ。
【００２０】
例えば、図３（Ａ）において、運用サーバ５４０が故障した場合には、図３（Ｂ）に示す状態となる。図３（Ｂ）では、運用サーバ５４０が「故障中」のため、予備サーバ５６０に論理ＩＰアドレス「172.16.1.1」が設定され、予備サーバ５６０がストレージ５７０内に持っている故障した運用サーバ５４０のサービスデータを参照してサービスを提供する。
【００２１】
その後、図３（Ｂ）において、故障した運用サーバ５４０が復旧した場合には、再び、図３（Ａ）に示す状態に戻り、運用サーバ５４０がサービスを提供する。
【００２２】
第２の方法の場合、運用サーバと予備サーバの間でサービスを提供するサーバが切り替わってもサービスを提供するＩＰアドレスは同一の論理ＩＰアドレスであるため、このノードと通信する他のノードから見た場合、サービスの中断時間はサーバの切り替え時間だけの短時間となる。
【００２３】
また、第２の方法では、サービスを提供するために使用する論理的ＩＰアドレスを運用サーバと予備サーバの間で動的に設定するため、運用サーバと予備サーバは、同一拠点の同一サブネット内に設置する必要がある。
【００２４】
このため、第２の方法の場合、故障のため運用サーバが使用不能となる状況においては、短時間でサービスを回復することができるが、被災拠点内の全サーバが使用不能となるような状況においては、運用サーバと予備サ−バの両方が同時に使用不能となるため、サービスを回復することができない。
【００２５】
（第３の方法）
第３の方法は、被災拠点内の全サーバが使用不能となるような状況においてもサービスの提供を回復可能とするために、運用拠点とは異なる予備拠点に予備のノードを設置しておく方式である。このとき、予備拠点には、全ての拠点の全てのノードから、定期的にサービスデータをバックアップしておく。第３の方法について図４及び図５を用いて説明する。
【００２６】
図４では、関東拠点と関西拠点が運用拠点で、東海拠点が予備拠点となっている。被災拠点内の全ノードが使用不能とった場合には、被災拠点のノード５００に代わって、予備拠点のノード５８０がサービスの提供を引き継ぐ。
【００２７】
図４において、関西拠点が被災して、関西拠点の運用サーバ５１０が使用不能となった場合には、図５に示すような状態となる。図５では、予備拠点の東海拠点にバックアップされた関西拠点のノード５００のサービスデータを、東海拠点の予備ノード５８０にコピーし、東海拠点の予備ノード５８０が関西拠点の運用ノード５００のサービスを引き継いでいる。
【００２８】
ただし、予備ノード５８０は運用ノード５００とは別な拠点のサブネット内に設置されているので、運用ノードと予備ノードでは異なる論理ＩＰアドレスを使用することになる。このため、サービスを再開する前に、被災拠点以外の全ノードと予備拠点の全ノードにおいて、通信相手のＩＰアドレスに関する情報を変更する必要がある。
【００２９】
図５では、サービスデータとして、電話番号から接続先ノードの論理ＩＰアドレスを求めるためのルーチング情報を持っている場合を示している。
【００３０】
例えば、図４のルーチング情報では電話番号「06」に対して関西１ノードの論理ＩＰアドレス「172.17.1.1」が設定されており、電話番号「075」に対して関西２ノードの論理ＩＰアドレス「172.17.2.1」が設定されている。
【００３１】
被災した関西拠点の代わりに東海拠点がサービスを引き継ぐためには、図５のようにルーチング情報を書き換え、電話番号「06」に対して東海１ノードの論理ＩＰアドレス「172.18.1.1」を設定し、電話番号「075」に対して東海２ノードの論理ＩＰアドレス「172.18.1.2」を設定しなければならない。
【００３２】
第３の方法では、被災拠点内の全サーバが使用不能となるような状況において、サービス提供を回復することが可能となっているが、バックアップからのサービスデータのコピー作業と、その後のサービスデータの変更作業が必要となるため、被災拠点のサービス提供が回復するまでには時間がかかる。
【先行技術文献】
【特許文献】
【００３３】
【特許文献１】特開２００７−６０３５号公報
【発明の概要】
【発明が解決しようとする課題】
【００３４】
例えば、ＩＰ電話の接続を制御するサーバの場合、０系サーバと１系サーバとの間で「運転中」のサーバが切り替わっても、接続済みセッションを切断することなく、切り替わった系でセッションを継続できるようにする目的で、第１の方法を用いる場合がある。
【００３５】
「運転中」状態のサーバが切り替わっても、接続済みセッションを０系サーバと１系サーバの間で引き継げるようにするため、セッションの情報を「運転中」の系から「待機中」の系への転送をする。
【００３６】
系間でのセッション情報の転送は、セッション毎、及び、セッションの状態変更毎に必要となるため、セッション情報の転送に必要な通信量は大きい。このため、セッション情報の転送は、ストレージ経由ではなく、系間を接続する専用のＬＡＮ（ローカルエリアネットワーク）を用意して、直接系間で通信を実施する。
【００３７】
このように、多量のセッション情報の転送を実施するため、ＩＰ電話の接続を制御するサーバでは、「運転中」状態のサーバと「待機中」状態のサーバが対になっている第１の方法の構成が望ましい。
【００３８】
ただし、第１の方法だけでは、被災拠点の全てのノードが使用不能となるような状況ではサービスを継続できなくなるため、図４及び図５に示すように、第１の方法と第３の方法を併用する場合がある。
【００３９】
しかしながら、第１の方法と第３の方法とを組み合わせた方法には、次のような問題が生じ得る。
【００４０】
第１に、第１の方法のためのサーバ２重化に加えて、第３の方法のための予備拠点および予備サーバを用意する必要があり、コストが大きくなるという問題が生じ得る。
【００４１】
第２に、拠点災害時の復旧には、第３の方法を用いるため、バックアップからのサービスデータのコピー作業と、その後のサービスデータの変更作業のため、サービス中断時間が長くなるという問題が生じ得る。
【００４２】
そこで、本発明は、上記課題に鑑み、予備拠点及び予備サーバを用意するためのコストを軽減し、サービス中断時間を短縮することができる復旧システム、復旧方法、冗長制御装置及び冗長制御プログラムを提供する。
【課題を解決するための手段】
【００４３】
かかる課題を解決するために、第１の本発明の復旧システムは、各拠点に、サービス提供を実行する第１サーバと待機する第２サーバと上記サービス提供に必要なサービスデータを保存するデータ保存手段とを有して、サービスの提供を行う１又は複数のノードを備え、（１）各ノードは、他の拠点に設置された他ノードとの間で代替関係が設定されており、（２）データ保存手段は、自ノードが提供するサービスのサービスデータと、他の拠点の代替関係にある他ノードが提供するサービスのサービスデータとを保存するものであり、（３）第２サーバが、第１サーバの障害又は他拠点の代替関係にある他ノードの障害発生時に、データ保存手段から必要なサービスデータを取得して、障害の生じたサービスの提供を実行することを特徴とする。
【００４４】
第２の本発明の復旧方法は、各拠点に、サービス提供を実行する第１サーバと待機する第２サーバと上記サービス提供に必要なサービスデータを保存するデータ保存手段とを有して、サービスの提供を行う１又は複数のノードを備え、（１）各ノードは、他の拠点に設置された他ノードとの間で代替関係を設定し、（２）データ保存手段は、自ノードが提供するサービスのサービスデータと、他の拠点の代替関係にある他ノードが提供するサービスのサービスデータとを保存し、（３）第２サーバが、第１サーバの障害又は他拠点の代替関係にある他ノードの障害発生時に、データ保存手段から必要なサービスデータを取得して、障害の生じたサービスの提供を実行することを特徴とする。
【００４５】
第３の本発明の冗長制御装置は、所定のサービスを提供する同一ノードにおける他のサーバ、又は、予め設定された他の拠点の代替関係が設定された他のサーバとの間で冗長構成をとるサーバの冗長制御装置であって、（１）自ノードが提供するサービスのサービスデータと、他の拠点の代替関係にある他ノードが提供するサービスのサービスデータとを保存するデータ保存手段と、（２）自ノードが通常時にサービスを提供する通常モード時の論理ノード情報と、他拠点の代替関係にあるノードのサービスを提供する代替モード時の論理ノード情報とをノード毎に予め設定したサーバ情報を格納するサーバ情報格納手段と、（３）自身の動作状態を認識する動作状態認識手段と、（４）動作状態認識手段により認識された自身の動作状態に応じて、サーバ情報から論理ノード情報を検索し、検索した論理ノード情報に対応するサービスデータをデータ保存手段から取得して冗長制御を行う冗長制御手段とを備えることを特徴とする。
【００４６】
第４の本発明の冗長制御プログラムは、所定のサービスを提供する同一ノードにおける他のサーバ、又は、予め設定された他の拠点の代替関係が設定された他のサーバとの間で冗長構成をとるサーバの冗長制御プログラムであって、自ノードが提供するサービスのサービスデータと、他の拠点の代替関係にある他ノードが提供するサービスのサービスデータとを保存するデータ保存手段と、自ノードが通常時にサービスを提供する通常モード時の論理ノード情報と、他拠点の代替関係にあるノードのサービスを提供する代替モード時の論理ノード情報とをノード毎に予め設定したサーバ情報を格納するサーバ情報格納手段とを備える冗長制御装置を、（１）自身の動作状態を認識する動作状態認識手段、（２）動作状態認識手段により認識された自身の動作状態に応じて、サーバ情報から論理ノード情報を検索し、検索した論理ノード情報に対応するサービスデータをデータ保存手段から取得して冗長制御を行う冗長制御手段として機能させることを特徴とする。
【発明の効果】
【００４７】
本発明によれば、予備拠点及び予備サーバを用意するためのコストを軽減し、サービス中断時間を短縮することができる。
【図面の簡単な説明】
【００４８】
【図１】第１の実施形態の復旧システムの構成を示す構成図である。
【図２】従来の第１の復旧方法を説明する説明図である。
【図３】従来の第２の復旧方法を説明する説明図である。
【図４】従来の第３の復旧方法を説明する説明図である（その１）。
【図５】従来の第３の復旧方法を説明する説明図である（その２）。
【図６】第１の実施形態のサーバの内部構成を示す内部構成図である。
【図７】第１の実施形態のサーバの冗長制御部の機能構成を示すブロック図である。
【図８】第１の実施形態のサーバ情報の構成を説明する説明図である。
【図９】第１の実施形態のサービスデータの構成を説明する説明図である。
【図１０】第１の実施形態のサーバにおける冗長制御処理を示すフローチャートである。
【図１１】第１の実施形態において正常時の動作の様子を示す説明図である。
【図１２】第１の実施形態において０系サーバが故障した場合の様子を示す説明図である。
【図１３】第１の実施形態において他の拠点の代替関係にあるノードが故障した場合の様子を示す説明図である。
【図１４】第１の実施形態において接続先決定処理を示すフローチャートである。
【図１５】第１の実施形態の通常モードのときの接続先決定処理の様子を示す説明図である（その１）。
【図１６】第１の実施形態の通常モードのときの接続先決定処理の様子を示す説明図である（その２）。
【図１７】第１の実施形態の代替モードのときの接続先決定処理の様子を示す説明図である（その１）。
【図１８】第１の実施形態の代替モードのときの接続先決定処理の様子を示す説明図である（その２）。
【図１９】第２の実施形態の復旧システムの構成を示す構成図である。
【図２０】第２の実施形態の第１の冗長制御処理におけるサーバの状態を説明する説明図である。
【図２１】第２の実施形態の第１の冗長制御処理を行う予備サーバの冗長制御部の機能構成を示すブロック図である。
【図２２】第２の実施形態の第１の冗長制御処理を示すフローチャートである。
【図２３】第２の実施形態の論理ＩＰアドレス取得処理を示すフローチャートである。
【図２４】第２の実施形態の第１の冗長制御処理におけるサーバの状態を説明する説明図である。
【図２５】第２の実施形態の第２の冗長制御処理におけるサーバの状態を説明する説明図である。
【図２６】第２の実施形態の第２の冗長制御処理を行う予備サーバの冗長制御部の機能構成を示すブロック図である。
【図２７】第２の実施形態の第２の冗長制御処理を示すフローチャートである。
【図２８】第２の実施形態の第２の冗長制御処理におけるサーバの状態を説明する説明図である（その１）。
【図２９】第２の実施形態の第２の冗長制御処理におけるサーバの状態を説明する説明図である（その２）。
【図３０】第２の実施形態の第３の冗長制御処理におけるサーバの状態を説明する説明図である。
【図３１】第２の実施形態の第３の冗長制御処理を行う予備サーバの冗長制御部の機能構成を示すブロック図である。
【図３２】第２の実施形態の第３の冗長制御処理を示すフローチャートである。
【図３３】第２の実施形態の第３の冗長制御処理におけるサーバの状態を説明する説明図である（その１）。
【図３４】第２の実施形態の第３の冗長制御処理におけるサーバの状態を説明する説明図である（その２）。
【発明を実施するための形態】
【００４９】
（Ａ）第１の実施形態
以下では、本発明の復旧システム、復旧方法、冗長制御装置及び冗長制御プログラムの第１の実施形態を図面を参照しながら説明する。
【００５０】
第１の実施形態は、例えば、ＩＰネットワーク上で音声通信を実現するサーバ（例えばコールサーバ等）を各拠点に設置してＩＰ電話サービスを提供するシステムの復旧システムに本発明を適用した場合の実施形態を例示して説明する。
【００５１】
（Ａ−１）第１の実施形態の構成
図１は、第１の実施形態に係るＩＰ電話システムの復旧システムの構成を示す構成図である。図１に例示するように、第１の実施形態の復旧システム１０Ａは、ＩＰ電話サービスを提供する運用拠点として、例えば２箇所の関東拠点と関西拠点を備え、関東拠点と関西拠点との間でＷＡＮ（ワイドエリアネットワーク）を形成するネットワークである。
【００５２】
関東拠点及び関西拠点ではそれぞれ、関東拠点ＬＡＮ及び関西拠点ＬＡＮが敷設されており、この関東拠点ＬＡＮ及び関西拠点ＬＡＮにはそれぞれ、３台のノードＥＮ１〜ＥＮ３及びノードＷＮ１〜ＷＮ３が接続されている。ここで、関東拠点ＬＡＮと関西拠点ＬＡＮは、それぞれ異なるサブネットである。
【００５３】
ノードＥＮ１〜ＥＮ３及びノードＷＮ１〜ＷＮ３は、各拠点でのＩＰ電話を制御するものであり、それぞれサーバを識別するための論理的なノード名が付与されている。関東拠点に設置のノードＥＮ１〜ＥＮ３のノード名はそれぞれ「関東１」、「関東２」、「関東３」とし、関西拠点に設置のノードＷＮ１〜ＷＮ３のノード名はそれぞれ「関西１」、「関西２」、「関西３」とする。
【００５４】
ノードＥＮ１〜ＥＮ３及びノードＷＮ１〜ＷＮ３は、０系サーバ１及び１系サーバ２の２台のサーバと、ストレージ３とを少なくとも有して、２重化構成（冗長構成）によりサーバの故障に備えた高可用性を実現している。
【００５５】
また、ノードＥＮ１〜ＥＮ３及びノードＷＮ１〜ＷＮ３は、異なる拠点のノードとの間で１対１の対応付けがなされている。この対応付けの関係により、拠点被災時に互いにサービス提供を代替して行うことができる。
【００５６】
ここでは、「関東１」と「関西１」、「関東２」と「関西２」、「関東３」と「関西３」のノードが対応付けられて代替関係にある。例えば、関西拠点が被災して関西拠点の全てのノードＷＮ１〜ＷＮ３が故障した場合、「関東１」ノードＥＮ１が「関西１」ノードＷＮ１のサービス提供を代替し、「関東２」ノードＥＮ２が「関西２」ノードＷＮ２のサービス提供を代替し、「関東３」ノードＥＮ３が「関西３」ノードＷＮ３のサービス提供を代替する。
【００５７】
図６は、０系サーバ１及び１系サーバ２の構成を示す構成図である。０系サーバ１及び１系サーバ２は同じ構成を備えており、自身が動作する状態に応じて実行する動作モードが異なる。なお、図６では、０系サーバ１及び１系サーバ２をまとめてサーバ１００と示す。
【００５８】
図６において、サーバ１００は、アプリケーション１０１、冗長制御部１０２、ＯＳ１０３、ハードディスク１０４を少なくとも有する。
【００５９】
アプリケーション１０１は、自サーバが提供するサービスに関するアプリケーション（例えば、ＩＰ電話等）である。ＯＳ１０３は、例えばＬｉｎｕｘ（登録商標）等の一般的なＯＳを適用することができる。
【００６０】
冗長制御部１０２は、ＯＳ１０３上で動作するものであり、自ノードにおける他のサーバや、他の拠点の代替関係にある他ノードの障害発生時に、ストレージ３からサービスの提供に必要なサービスデータを取得して、障害の生じたサービスの提供を実行する冗長制御を行うものである。
【００６１】
図７は、冗長制御部１０２の機能構成を示すブロック図である。図７において、冗長制御部１０２は、動作モード認識部１１、通常モード（運転中）制御部１２、通常モード（待機中）制御部１３、代替モード制御部１４、接続先決定部１５を少なくとも有する。
【００６２】
動作モード認識部１１が、自身の動作モードを認識するものである。動作モード認識部１１は、自サーバの動作モードに応じて、通常モード（運転中）制御部１２、通常モード（待機中）制御部１３、代替モード制御部１４による制御を実行させる。なお、動作モード認識部１１の認識する動作モードとしては、通常モード（運転中）、通常モード（待機中）、代替モード、故障中などを認識する。
【００６３】
例えば、自サーバが１系サーバの場合、動作モード認識部１１は自サーバの通常時を通常モード（運転中）と認識する。しかし、既存の故障検出方法等により自サーバの故障が検出された場合、動作モード認識部１１は故障中と認識する。
【００６４】
また例えば、自サーバが０系サーバの場合、動作モード認識部１１は自サーバの通常時を通常モード（待機中）と認識する。しかし、既存の故障検出方法（例えばｐｉｎｇ等を利用した生存確認方法を用いた故障検出方法）等により、自ノードの１系サーバ２の故障を検出した場合、動作モード認識部１１は自サーバを通常モード（運転中）と認識する。さらに、例えば既存の故障検出方法（例えばｐｉｎｇ等を利用した生存確認方法を用いた故障検出方法）等により代替関係にある他拠点のノードが故障した場合、動作モード認識部１１は自サーバを代替モードと認識する。
【００６５】
通常モード（運転中）制御部１２は、動作モードが通常モード（運転中）の場合に、自サーバの動作を制御するものである。通常モード（運転中）制御部１２の機能構成としては、サーバ情報検索部１２１、論理ＩＰアドレス設定部１２２、サービスデータ取得部１２３を少なくとも有する。
【００６６】
サーバ情報検索部１２１は、自サーバの物理ＩＰアドレスをキーとして、ハードディスク１０４に保持されるサーバ情報から、自サーバの動作モードに応じた論理ノード情報（論理ノード名及び論理ＩＰアドレス）を検索して取得するものである。
【００６７】
ここで、論理ノード情報とは、サービス提供を行う論理ノードに関する情報であり、特に論理ノード名及び論理ＩＰアドレスをいう。
【００６８】
論理ＩＰアドレス設定部１２２は、サーバ情報検索部１２１により検索された通常モードの論理ＩＰアドレスを自サーバに設定するものである。これにより、論理ＩＰアドレスを用いてサービスの提供を実行することができる。
【００６９】
サービスデータ取得部１２３は、サーバ情報検索部１２１により検索された通常モードの論理ノード名に対応するサービスデータを、ストレージ３から取得するものである。これにより、当該論理ノード名のサービスデータを取得することができ、このサービスデータを用いて引き続きサービス提供を継続することができる。
【００７０】
通常モード（待機中）制御部１３は、動作モードが通常モード（待機中）の場合に、自サーバの動作を待機状態に制御する。
【００７１】
代替モード制御部１４は、動作モードが代替モードの場合に、自サーバの動作を制御するものである。代替モード制御部１４の機能構成としては、サーバ情報検索部１４１、論理ＩＰアドレス設定部１４２、サービスデータ取得部１４３を少なくとも有する。
【００７２】
サーバ情報検索部１４１は、自サーバの物理ＩＰアドレスをキーとして、ハードディスク１０４に保持されるサーバ情報から、代替モードの論理ノード名及び論理ＩＰアドレスを検索して取得するものである。
【００７３】
論理ＩＰアドレス設定部１４２は、サーバ情報検索部１４１により検索された代替モードの論理ＩＰアドレスを自サーバに設定するものである。これにより、論理ＩＰアドレスを用いてサービスの提供を実行することができる。
【００７４】
サービスデータ取得部１４３は、サーバ情報検索部１４１により検索された代替モードの論理ノード名に対応するサービスデータを、ストレージ３から取得するものである。これにより、当該論理ノード名のサービスデータを取得することができ、このサービスデータを用いて引き続きサービス提供を継続することができる。
【００７５】
接続先決定部１５は、ストレージ３に保持されるサービスデータ（ルーチング情報）を用いて、ユーザ端末の電話番号から接続すべきサーバを決定するものである。接続先決定部１５の処理は、動作の項において詳細に説明する。
【００７６】
ハードディスク１０４は、各ノードＥＮ１〜ＥＮ３及びＷＮ１〜ＷＮ３の拠点間の代替関係を示すサーバ情報を保持するものである。全てのサーバは、同じ内容のサーバ情報をハードディスク１０４に保持している。
【００７７】
図８は、サーバ情報の構成例を例示する説明図である。図８に示すように、サーバ情報は、「物理ＩＰ」、「通常モード」、「代替モード」を大きな項目とする。そして、図８に示すサーバ情報は、０系サーバと１系サーバの物理ＩＰアドレス、代替運用していない「通常モード」での論理ノード名と論理ＩＰアドレス、代替運用している「代替モード」での論理ノード名と論理ＩＰアドレスを一組とした情報を持っている。
【００７８】
また、図８に例示するサーバ情報は、「関東１」と「関西１」、「関東２」と「関西２」、「関東３」と「関西３」のノード組み合わせで代替関係を登録している。この設定の場合、関東拠点が被災した場合には、関東１〜関東３のサーバに代わりに関西１〜関西３のサーバが代替し、関西拠点が被災した場合には、関西１〜関西３に代わり、関東１〜関東３のサーバが代替してサービスを提供する。
【００７９】
このように、代替関係にあるサーバは、互いに相手のサービスを引き継いでサービスの提供を行うため、各拠点間のサーバは、相互にサービスデータを定期的に交換し合い、相互のサービスデータをストレージ３に保持している。
【００８０】
ストレージ３は、各ノードの０系サーバ１及び１系サーバ２が共用するサービスデータと、代替関係にある他拠点のノードのサービスデータを保持するものである。ここで、サービスデータとは、ノードがサービス提供する際に参照するデータの総称をいう。例えば、ＩＰ電話サービスを提供する場合、サービスデータは、呼の接続制御に必要なデータをいい、例えば、ユーザ情報やルーチング情報等を含む。
【００８１】
ストレージ３は、代替関係にある他拠点のノードと定期的にサービスデータの交換を行い、サービスデータの更新を行っている。また、ストレージは、自ノードのサービスデータと、代替関係にある他ノードのサービスデータとの区別するために、サービスデータを論理ノード名毎に格納する。すなわち、例えば、関東１ノードＥＮ１の場合、論理ノード名「関東１」のサービスデータと、論理ノード名「関西１」のサービスデータとを、論理ノード名がアクセスキーとなるようにして格納する。
【００８２】
図９は、ストレージ３に保存されるサービスデータの例を示す構成図である。図９（Ａ）及び図９（Ｂ）はユーザ情報の構成例であり、図９（Ｃ）はルーチング情報の構成例を示す。
【００８３】
図９（Ａ）及び図９（Ｂ）に例示するように、ユーザ情報は、ユーザ端末の電話番号とユーザ端末のＩＰアドレスとを対応付けた情報である。ここで、ユーザ端末は、接続するノードによる呼制御を受ける。そのため、各ノードＥＮ１〜ＥＮ３及びＷＮ１〜ＷＮ３は、それぞれ異なるユーザ情報を保持している。
【００８４】
例えば、図９（Ａ）は、「関東１」ノードＥＮ１が保持するユーザ情報例であり、例えば電話番号が「0322220001」のユーザ端末のＩＰアドレスは「10.10.0.1」であることを示す。また、図９（Ｂ）は、「関西１」ノードＷＮ１が保持するユーザ情報例であり、例えば、電話番号が「0622220001」のユーザ端末のＩＰアドレスは「10.20.0.1」であることを示す。
【００８５】
図９（Ｃ）に例示するように、ルーチング情報は、電話番号に対して接続先となるノードとの対応関係を示す情報である。例えば、図９（Ｃ）において、電話番号「03」で始まる電話番号のユーザ端末の呼制御を行う場合には、「関東１」ノードＥＮ１が接続先となる。
【００８６】
なお、サービスデータは、例えばルーチング情報のようにノードを示す情報の場合、論理ＩＰアドレスだけでなく、「論理ノード名」を用いて指定するようにする。
【００８７】
（Ａ−２）第１の実施形態の動作
次に、第１の実施形態の復旧システムの処理の動作を、図面を参照しながら詳細に説明する。
【００８８】
図１０は、各ノードのサーバ１００における冗長制御処理の動作を示すフローチャートである。図１０に示す処理では、サーバ１００が、どの論理ＩＰアドレスを用いて、どのノードのサービスを提供するかを決定する。
【００８９】
（Ａ−２−１）正常時の処理
まず、全拠点のサーバが正常に動作する場合を例示する。図１１は、正常時のノードにおけるサーバの様子を示す説明図である。なお、図１１では、「関東１」ノードＥＮ１の様子を例示する。
【００９０】
この場合、拠点の全ノードＥＮ１〜ＥＮ３及びＷＮ１〜ＷＮ３は、０系サーバ１及び１系サーバ２のどちらか一方が「運転中」に設定され、他方が「待機中」に設定される。また、両方のサーバはいずれも「通常モード」に設定される。
【００９１】
例えば、図１１（Ａ）において、物理ＩＰアドレス「172.16.1.10」の０系サーバ１が「運転中」である場合、０系サーバ１の動作モード認識部１１は、自サーバが通常モード（運転中）であると判断し（ステップＳ１０１）、ステップＳ１０２に移行する。
【００９２】
図１１（Ｂ）に示すように、０系サーバ１において、通常モード（運転中）制御部１２のサーバ情報検索部１２１は、自サーバの物理ＩＰアドレス「172.16.1.10」をキーとして、サーバ情報の物理ＩＰの欄を検索し、一致した行の通常モード欄から論理ノード名「関東１」及び論理ＩＰアドレス「172.16.1.1」を取得する（ステップＳ１０２）。
【００９３】
そして、論理ＩＰアドレス設定部１２２は、論理ＩＰアドレス「172.16.1.1」を自サーバに設定し（ステップＳ１０３）、サービスデータ取得部１２３が、論理ノード名「関東１」をキーとして、ストレージ３のサービスデータから「関東１」のサービスデータを取得する（ステップＳ１０４）。これにより、０系サーバ１は、「関東１」ノードＥＮ１の通常モード（運転中）として動作し、「関東１」ノードＥＮ１に求められるサービスを提供することができる。
【００９４】
一方、例えば、図１１（Ａ）及び（Ｃ）に示すように、１系サーバ２は「待機中」となるため（ステップＳ１０１）、ステップＳ１０５に移行する。このとき、１系サーバ２は、正常に動作しているため「通常モード」であるから（ステップＳ１０５）、サービスの提供をせずに待機する（ステップＳ１０６）。
【００９５】
（Ａ−２−２）自ノードの「運転中」サーバの故障時の処理
次に、自ノードの「運転中」サーバの故障時の処理動作を説明する。図１２は、「運転中」サーバの故障時の処理動作の様子を示す説明図である。
【００９６】
例えば、図１２（Ａ）に示すように、「運転中」の０系サーバ１が故障した場合、１系サーバ２が、「待機中」から「運転中」に状態変更する。
【００９７】
なお、状態変更処理の方法は、種々の方法を適用することができ、例えば、既存する故障検出方法等により０系サーバ１の故障検出を契機として、１系サーバ２は「待機中」から「運転中」に状態を変更する。
【００９８】
まず、「関東１」ノードＥＮ１において、状態変更により１系サーバ２は「運転中」となるから（ステップＳ１０１）、１系サーバ２のサーバ情報検索部１２１は、図１２（Ｂ）に示すように、１系サーバ２の物理ＩＰアドレス「172.16.1.11」をキーとして、サーバ情報の物理ＩＰ欄を検索して、一致する行の通常モード欄から、論理ノード名「関東１」及び論理ＩＰアドレス「172.16.1.1」を取得する（ステップＳ１０２）。
【００９９】
そして、論理ＩＰアドレス設定部１２２は、論理ＩＰアドレス「172.16.1.1」を自サーバに設定し（ステップＳ１０３）、サービスデータ取得部１２３が、論理ノード名「関東１」をキーとして、ストレージ３のサービスデータから「関東１」のサービスデータを取得する（ステップＳ１０４）。これにより、図１２（Ｃ）に示すように、１系サーバ２は、「関東１」ノードＥＮ１の通常モード（運転中）として動作し、「関東１」ノードＥＮ１に求められるサービスを提供することができる。
【０１００】
（Ａ−２−３）拠点の全ノードが被災した場合の処理
次に、拠点の全ノードが被災した場合の処理動作を説明する。図１３は、代替関係にあるノードが故障した場合の処理動作の様子を示す説明図である。
【０１０１】
例えば、関西拠点の「関西１」〜「関西３」の全ノードＷＮ１〜ＷＮ３が被災に遭い、使用不能となった場合、関東拠点の「関東１」〜「関東３」のノードＥＮ１〜ＥＮ３は「通常モード」から「代替モード」に状態変更する。
【０１０２】
なお、「代替モード」への状態変更の方法も、種々の方法を適用することができ、例えば、既存の故障検出方法等により代替関係にあるノード又はサーバの故障検出を契機として、「通常モード」から「代替モード」への状態変更とする方法を適用できる。
【０１０３】
例えば、図１３（Ａ）において、「関東１」ノードＥＮ１の０系サーバ１は、「運転中」であるので、０系サーバ１は、引き続き論理ＩＰアドレス「172.16.1.1」を用いて論理ノード名「関東１」のサービスを提供する。
【０１０４】
一方、図１３（Ａ）に例示する「待機中」の１系サーバ２は、「通常モード」から「代替モード」に変更するので（ステップＳ１０５）、ステップＳ１０７に移行し、代替ノードの論理ＩＰアドレスと論理ノードが決められる。
【０１０５】
まず、図１３（Ｂ）に示すように、１系サーバ２において、代替モード制御部１４のサーバ情報検索部１４１は、自サーバの物理ＩＰアドレス「172.16.1.11」をキーとして、サーバ情報の物理ＩＰ欄から検索し、一致する行の代替モード欄から論理モード名「関西１」及び論理ＩＰアドレス「172.16.1.2」を取得する（ステップＳ１０７）。
【０１０６】
そして、論理ＩＰアドレス設定部１４２は、論理ＩＰアドレス「172.16.1.2」を自サーバに設定し（ステップＳ１０８）、サービスデータ取得部１４３が、論理ノード名「関西１」をキーとして、ストレージ３のサービスデータから「関西１」のサービスデータを取得する（ステップＳ１０９）。
【０１０７】
これにより、図１３（Ｃ）に示すように、１系サーバ２は、代替モードとして動作し、「関西１」ノードＷＮ１のサービスを提供することができる。一方、０系サーバ１は、通常モード（運転中）として動作し、「関東１」ノードＥＮ１のサービスを提供することができる。
【０１０８】
（Ａ−２−４）接続先サーバの決定処理
次に、各サーバが、ストレージ３に保持されるルーチン情報を参照して、ユーザ端末の電話番号から接続先とするサーバを決定する処理動作を説明する。図１４は、接続先サーバの決定処理を示すフローチャートである。
【０１０９】
（ａ）通常モードの場合
図１５及び図１６は、全拠点のノードが正常に動作する場合の様子を示す説明する。
【０１１０】
図１５に示すように、「関東１」ノードＥＮ１及び「関西１」ノードＷＮ１において、０系サーバ１と１系サーバ２のいずれか一方は「運転中」に設定され、他方は「待機中」に設定されており、両者は「通常モード」に設定されている。
【０１１１】
この場合に、例えば、電話番号「0622220001」のユーザ端末に接続するサーバを決定する場合の処理を例示する。
【０１１２】
まず、図１６に示すように、サーバの接続先決定部１５は、電話番号「0622220001」をキーとして、ストレージ３に保持されるルーチング情報を検索し、電話番号のプレフィックスが一致した行の論理ノード欄から論理ノード名「関西１」を取得する（ステップＳ２０１）。
【０１１３】
このとき、「関東１」ノードＥＮ１のサーバは「通常モード」であるから（ステップＳ２０２）、ステップＳ２０３に移行する。接続先決定部１５は、論理ノード名「関西１」をキーとして、サーバ情報の通常モードの欄の論理ＩＰ欄から、論理ノード名「関西１」の論理ＩＰアドレス「172.17.1.1」を取得する（ステップＳ２０３）。
【０１１４】
その結果、電話番号「0622220001」に対しては、論理ＩＰアドレス「172.17.1.1」が求まり、この論理ＩＰアドレスが設定されている「関西１」ノードＷＮ１の「運転中」である０系サーバに接続する。
【０１１５】
（ｂ）代替モードの場合
図１７は、関西拠点が災害に遭い、全ノードＷＮ１が使用不能となり、関東拠点のノードＥＮ１が代替モードとなっている場合の様子を示す説明図である。
【０１１６】
図１７に示すように、この場合、関東拠点の「関東１」ノードＥＮ１は「代替モード」の状態であり、０系サーバ１は「関東１」のサービスを提供し、１系サーバ２が「関西１」のサービスを提供している。
【０１１７】
この場合、電話番号「0622220001」のユーザ端末を接続するサーバを決定する場合を例示する。
【０１１８】
まず、図１８に示すように、各サーバの接続先決定部１５は、電話番号「0622220001」をキーとして、ストレージ３のルーチング情報を検索し、電話番号のプレフィックスが一致した行の論理ノード欄から論理ノード名「関西１」を取得する（ステップＳ２０１）。
【０１１９】
このとき、関東拠点のノードは代替モードであるから（ステップＳ２０２）、ステップＳ２０５に移行する。接続先決定部１５は、論理ノード名「関西１」をキーとして、サーバ情報の代替モードの欄の論理ＩＰ欄から、論理ノード名「関西１」の論理ＩＰアドレス「172.16.1.2」を取得する（ステップＳ２０５）。
【０１２０】
その結果、電話番号「0622220001」に対しては、論理ＩＰアドレス「172.16.1.2」が求まり、この論理ＩＰアドレスが設定されている「関東１」ノードＥＮ１の１系サーバに接続する。
【０１２１】
（Ａ−３）第１の実施形態の効果
上記のように、第１の実施形態によれば、拠点災害は発生していない場合、各ノードは０系サーバと１系サーバで２重化した構成となり、一方のサーバが「運転中」となり、他方のサーバが「待機中」となる。この時、「運転中」のサーバが改障しても「待機中」のサーバを「運転中」に変更することで、０系サーバと１系サーバの間でサービスを引継ぐことができる。また、その際のサービス中断時間は、サーバ切り替えに要する時間だけで済む。
【０１２２】
また、拠点災害が発した場合、被災拠点のノードの代わりに、代替関係にあるノードの「待機中」のサーバがサービスを引き継ぐことができる。また、その際のサービス中断時間は、サーバ切り替えに要する時間だけで済む。
【０１２３】
このように、故障に対する高可用性と、拠点災害に対する高可用性の両方を実現でき、かつ、予備拠点に予備サーバを設置するようなコストの追加が発生しない。
【０１２４】
その結果、従来のように予備拠点及び予備ノードを新たに設ける必要がなくなるので、従来よりもコストの改善ができる。また、サーバの切り替えだけの時間で済むので、サービス中断時間も短縮することができる。
【０１２５】
（Ｂ）第２の実施形態
次に、本発明の復旧システム、復旧方法、冗長制御装置及び冗長制御プログラムの第２の実施形態を図面を参照しながら説明する。
【０１２６】
第１の実施形態では、「待機中」サーバが、被災拠点のサーバの代わりに、サービスを提供する場合を説明した。
【０１２７】
しかし、この場合、代替モードのノードにおいては２重化を構成していない状態となる。従って、この状態でいずれかのサーバが故障となると、そのサーバが提供していたノードのサービスが提供できなくなる。
【０１２８】
そこで、第２の実施形態では、可用性のある第１の実施形態に対して、さらに拠点毎に予備サーバを設置して、さらに可用性を高めることができる。
【０１２９】
（Ｂ−１）第２の実施形態の全体構成
図１９は、第２の実施形態の復旧システム１０Ｂの構成を示す構成図である。図１９に示すように、第２の実施形態の復旧システム１０Ｂは、関東拠点及び関西拠点に、予備サーバ４及びストレージ５を新たに備える点である。
【０１３０】
予備サーバ４は、自身の拠点に設置されているノードの０系サーバ１又は１系サーバ２のいずれかが故障した場合に、そのノードが提供しているサービスを引き続き提供する予備的に設けられた代理サーバである。なお、予備サーバ４は、既存技術を利用して当該拠点のサーバの故障検出等をトリガとして動作する。
【０１３１】
また、予備サーバ４は、基本的には、０系サーバ１及び１系サーバ２と同じ構成を備えるが、冗長制御部１０２による冗長制御処理が０系サーバ１及び１系サーバ２と異なる。
【０１３２】
ここで、予備サーバ４による冗長制御処理の方法は、種々の方法を広く適用することができ、例えば後述する３つの方法を適用することができる。そこで、以下では、予備サーバ４による３つの方法例を説明する。
【０１３３】
なお、ストレージ５は、サービスデータを保持するものであるが、予備サーバ４の２重化方法の種別に応じて、どの範囲のサービスデータを保持するか変わってくる。そのため、以下では、ストレージ５に保持するサービスデータの範囲も含めて説明する。
【０１３４】
（Ｂ−２）第２の実施形態の詳細構成及び動作
（Ｂ−２−１）第１の冗長制御処理
第１の冗長制御処理は、予備サーバ４がストレージ５に、全拠点の全ノードＥＮ１〜ＥＮ３及びＷＮ１〜ＷＮ３のサービスデータをコピーして保持する方式である。
【０１３５】
図２０は、第１の冗長制御処理を説明する説明図である。この場合、図２０に示すノードＥＮ１は代替モードであり、０系ノード１は「関東１」のサービスを提供しており、１系ノード２は「関西１」のサービスを提供している。
【０１３６】
ストレージ５は、全ての拠点の全てのノードＥＮ１〜ＥＮ３及びＷＮ１〜ＷＮ３のサービスデータを保持するものである。ここで、サービスデータのコピーは、例えば、被災拠点の有無に関わらず定期的に実行しても良いし、被災拠点が発生した場合に限定して、定期的に実行しても良い。
【０１３７】
予備サーバ４は、サーバ情報を参照して、故障を起こしたサーバが提供しているノードの論理ノード名に基づいて、論理ＩＰアドレスを取得し、この論理ＩＰアドレスを自サーバに設定して、故障したサーバが提供していたノードのサービスを引き続き提供するものである。
【０１３８】
図２１は、予備サーバ４の冗長制御部１０２の機能構成を示すブロック図である。図２１に示すように、予備サーバ４の冗長制御部１０２は、論理ＩＰアドレス取得部４１１、論理ＩＰアドレス設定部４１２、サービスデータ取得部４１３を少なくとも有する。
【０１３９】
論理ＩＰアドレス取得部４１１は、故障したサーバが実行する論理ノード名をキーとして、サーバ情報から、通常モードの論理ノード欄から論理ＩＰアドレスと、代替ノードの論理ノード欄から論理ＩＰアドレスとを取得し、これらの論理ＩＰアドレスから自身の物理ＩＰアドレスと同一サブネットの論理ＩＰアドレスを選択するものである。
【０１４０】
論理ＩＰアドレス設定部４１２は、論理ＩＰアドレス取得部４１１により選択された論理ＩＰアドレスを自サーバに設定するものである。
【０１４１】
サービスデータ取得部４１３は、代理する論理ノード名をキーとして、ストレージ５からサービスデータを取得するものである。
【０１４２】
次に、第１の冗長制御処理の動作を、図面を参照しながら説明する。図２０（Ａ）に示すように、図２０（Ａ）の１系ノード２に故障が発生した場合に、１系ノード２が実行していた論理ノード名を指定して、故障サーバ（１系ノード２）から予備サーバ４に切り替える処理を例示する。
【０１４３】
図２２は、第１の冗長制御処理の動作を示すフローチャートである。また、図２３は、論理ＩＰアドレスの取得処理を示すフローチャートである。
【０１４４】
例えば、図２０（Ｂ）の１系ノード２は、「関西１」ノードＷＮ１に対応するサービスを提供しているから、１系ノード２が故障すると、「関西１」ノードＷＮ１のサービス提供ができなくなる。
【０１４５】
このため、予備サーバ４が代替する論理ノード名は「関西１」となる。予備サーバ４は論理ノード名「関西１」に対する論理ＩＰアドレスを取得する（ステップＳ３０１）。
【０１４６】
図２４（Ａ）に示すように、論理ＩＰアドレス取得部４１１は、論理ノード名「関西１」をキーとして、サーバ情報の通常モードの論理ノード欄を検索し、一致した行から通常モードの論理ＩＰアドレス「172.17.1.1」を取得する（ステップＳ４０１）。
【０１４７】
また、論理ＩＰアドレス取得部４１１は、論理ノード名「関西１」をキーとして、サーバ情報の代替モードの論理ノード欄を検索し、一致した行から代替モードの論理ＩＰアドレス「172.16.1.2」を取得する（ステップＳ４０２）。
【０１４８】
次に、論理ＩＰアドレス取得部４１１は、ステップＳ４０１及びＳ４０２で取得した論理ＩＰアドレスのうち、予備サーバ４の物理ＩＰアドレス「172.16.4.10」と同一サブネットの論理ＩＰアドレス「172.16.1.2」を選択する（ステップＳ４０３）。
【０１４９】
その結果、図２４（Ｂ）に示すように、予備サーバ４は、論理ＩＰアドレス設定部４１２が論理ＩＰアドレス「172.16.1.2」を設定し（ステップＳ３０２）、サービスデータ取得部４１３がストレージ５内の論理ノード名「関西１」のサービスデータを参照してサービスを提供する（ステップＳ３０３）。
【０１５０】
第１の冗長制御処理によれば、予備サーバ５のストレージサイズが全拠点全ノード分だけ必要となるが、サービス中断時間はサーバ切り替えの時間だけで済むので、サービス中断時間を短くできる。
【０１５１】
（Ｂ−２−２）第２の冗長制御処理
第２の冗長制御処理は、予備サーバ４のストレージ５に、サービスデータをコピーして保存しておかない方式である。
【０１５２】
図２５（Ａ）は、第２の冗長制御処理を説明する説明図である。この場合、図２５（Ａ）に示すノードＥＮ１は代替モードであり、０系ノード１は「関東１」のサービスを提供しており、１系ノード２は「関西１」のサービスを提供している。
【０１５３】
ストレージ５は、サービスデータを保存しておらず、予備サーバ４がサービスを代替する論理ノードが決まった後に、その代替するノードのサービスデータをコピーして保存する。
【０１５４】
予備サーバ４は、サーバ情報を参照して、故障を起こしたサーバが提供しているノードの論理ノード名に基づいて、論理ＩＰアドレスを取得し、この論理ＩＰアドレスを自サーバに設定して、故障したサーバが提供していたノードのサービスを引き続き提供するものである。
【０１５５】
また、予備サーバ４は、サーバ情報を参照して、故障したノードの物理ＩＰアドレスを検索し、その検索したノードから、サービスを継続するノードのサービスデータをストレージ５にコピーするものである。
【０１５６】
図２６は、予備サーバ４の冗長制御部１０２の機能構成を示すブロック図である。図２６に示すように、予備サーバ４の冗長制御部１０２は、論理ＩＰアドレス取得部４２１、論理ＩＰアドレス設定部４２２、物理ＩＰアドレス取得部４２３、サービスデータコピー部４２４、サービスデータ取得部４２５を少なくとも有する。
【０１５７】
なお、論理ＩＰアドレス取得部４２１、論理ＩＰアドレス設定部４２２及びサービスデータ取得部４２５は、論理ＩＰアドレス取得部４１１、論理ＩＰアドレス設定部４１２及びサービスデータ取得部４１３と同じ処理を行うものである。
【０１５８】
物理ＩＰアドレス取得部４２３は、論理ＩＰアドレス取得部４２１が選択した論理ＩＰアドレスをキーとして、サーバ情報の通常モードと代替モードの論理ノード欄を検索し、一致した行の物理ＩＰ欄から物理ＩＰアドレスを取得するものである。この物理ＩＰアドレスは、代替ノードのサービスデータをストレージ３に保持しているノードのサーバの物理ＩＰアドレスである。
【０１５９】
サービスデータコピー部４２４は、物理ＩＰアドレス取得部４２３により取得された物理ＩＰアドレスを用いて、代替するノード名のサービスデータをストレージ５にコピーするものである。
【０１６０】
次に、第２の冗長制御処理の動作を、図面を参照しながら説明する。図２５（Ｂ）に示すように、図２５（Ａ）の１系ノード２に故障が発生した場合に、１系ノード２が実行していた論理ノード名を指定して、故障サーバ（１系ノード２）から予備サーバ４に切り替える処理を例示する。
【０１６１】
図２７は、第２の冗長制御処理の動作を示すフローチャートである。
【０１６２】
例えば、図２５（Ｂ）の１系ノード２は、「関西１」ノードＷＮ１に対応するサービスを提供しているから、１系ノード２が故障すると、「関西１」ノードＷＮ１のサービス提供ができなくなる。
【０１６３】
このため、予備サーバ４が代替する論理ノード名は「関西１」となる。予備サーバ４は、図２３のフローチャートで説明した方法により、論理ノード名「関西１」に対する論理ＩＰアドレスを取得する（ステップＳ５０１）。
【０１６４】
図２８に示すように、論理ＩＰアドレス取得部４２１が、論理ノード名「関西１」の論理ＩＰアドレス「172.16.1.2」を選択する（ステップＳ４０１〜Ｓ４０３）。
【０１６５】
次に、物理ＩＰアドレス取得部４２３は、論理ＩＰアドレス「172.16.1.2」をキーとして、サーバ情報の通常モードと代替モードの論理ＩＰ欄を検索し、一致した行の物理ＩＰ欄から２つの物理ＩＰアドレス「172.16.1.10」と「172.16.1.11」を取得する（ステップＳ５０２）。
【０１６６】
そして、サービスデータコピー部４２４が、図２９に示すように、２つの物理ＩＰアドレス「172.16.1.10」と「172.16.1.11」のサーバに接続し、応答のあったサーバかに論理ノード名「関西１」を通知し、当該サーバから論理ノード名「関西１」に対応するサービスデータを取得し、ストレージ５に保持する（ステップＳ５０３）。
【０１６７】
その結果、図２９に示すように、予備サーバ４は、論理ＩＰアドレス設定部４２２が論理ＩＰアドレス「172.16.1.2」を設定し（ステップＳ５０４）、サービスデータ取得部４２５がストレージ５内の論理ノード名「関西１」のサービスデータを参照してサービスを提供する（ステップＳ５０５）。
【０１６８】
第２の冗長制御処理によれば、予備サーバ４のストレージサイズが１ノード分だけで済むが、切り替え時にサービスデータをコピーするための時間だけ、サービスの中断時間が長くなる。
【０１６９】
（Ｂ−２−３）第３の冗長制御処理
第３の冗長制御処理は、予備サーバのストレージに、予備サーバ４と同一拠点のノードの分のサービスデータだけをコピーしておく方式である。
【０１７０】
ストレージ５は、同一拠点の各ノードのストレージ３が保持するサービスデータを保持するものである。このサービスデータのコピーは、例えば、被災拠点の有無に関わらず定期的に実行しても良いし、又例えば被災拠点が発生した場合に限定して、定期的に実行しても良い。
【０１７１】
予備サーバ４は、サーバ情報を参照して、故障を起こしたサーバが提供しているノードの論理ノード名に基づいて、論理ＩＰアドレスを取得し、さらにその論理ＩＰアドレスをキーとして、故障を起こしたサーバと同一ノードの他サーバの論理ＩＰアドレスを取得するものである。
【０１７２】
また、予備サーバ４は、故障を起こしたサーバと同一ノードの他サーバに対して、故障を起こしたサーバが提供していたサービスを提供するように、状態変更を指示すると共に、自身が上記他サーバが提供していたサービスの提供を行うようにするものである。
【０１７３】
図３１は、予備サーバ４の冗長制御部１０２の機能構成を示すブロック図である。図３１に示すように、予備サーバ４の冗長制御部１０２は、論理ＩＰアドレス取得部４３１、論理ＩＰアドレス設定部４３２、サービスデータ確認部４３３、状態変更指示部４３４、サービスデータ取得部４３５を少なくとも有する。
【０１７４】
なお、論理ＩＰアドレス取得部４３１、論理ＩＰアドレス設定部４３２及びサービスデータ取得部４３５は、論理ＩＰアドレス取得部４１１、論理ＩＰアドレス設定部４１２及びサービスデータ取得部４１３と同じ処理を行うものである。
【０１７５】
サービスデータ確認部４３３は、代替する論理ノード名のサービスデータがストレージ５にあるか否かを確認するものである。
【０１７６】
状態変更指示部４３４は、サービスデータ確認部４３３により代替する論理ノード名のサービスデータがストレージ５にない場合、論理ＩＰアドレス取得部４３１が取得した論理ＩＰアドレスのサーバに対して、状態を「運用中」から「待機中」に変更指示するものである。
【０１７７】
次に、第３の冗長制御処理の動作を、図面を参照しながら説明する。図３０（Ｂ）に示すように、図３０（Ａ）の１系ノード２に故障が発生した場合に、１系ノード２が実行していた論理ノード名を指定して、故障サーバ（１系ノード２）から予備サーバ４に切り替える処理を例示する。
【０１７８】
図３２は、第３の冗長制御処理の動作を示すフローチャートである。
【０１７９】
例えば、図３０（Ｂ）の１系ノード２は、「関西１」ノードＷＮ１に対応するサービスを提供しているから、１系ノード２が故障すると、「関西１」ノードＷＮ１のサービス提供ができなくなる。
【０１８０】
このため、予備サーバ４が代替する論理ノード名は「関西１」となる。予備サーバ４は、図２３のフローチャートで説明した方法により、論理ノード名「関西１」に対する論理ＩＰアドレスを取得する（ステップＳ６０１）。
【０１８１】
図３３及び図３４に示すように、論理ＩＰアドレス取得部４３１が、論理ノード名「関西１」の論理ＩＰアドレス「172.16.1.2」を選択する（ステップＳ４０１〜Ｓ４０３）。
【０１８２】
次に、サービスデータ確認部４３３は当該論理ノード名のサービスデータがストレージ５にあるか否かを確認する（ステップＳ６０２）。そして、ストレージ５にサービスデータがある場合、論理ＩＰアドレス設定部４３２は、その論理ＩＰアドレスを自サーバに設定して（ステップＳ６０４）、サービスデータ取得部４３５がサービスデータを参照しながらサービスを提供する（ステップＳ６０５）。
【０１８３】
一方、上記の例のように、サービスデータがストレージ５にない場合には、次のような処理を行う。
【０１８４】
論理ＩＰアドレス取得部４３１は、論理ＩＰアドレス「172.16.1.2」をキーとして、サーバ情報の代替モードの論理ノード欄を検索し、一致した行の通常ノード欄から論理ノード名及び論理ＩＰアドレス「172.16.1.1」を取得する（ステップＳ６０６）。
【０１８５】
状態変更指示部４３４は、ステップＳ６０６で求めた論理ＩＰアドレス「172.16.1.1」のサーバ（０系サーバ１）に接続し、そのサーバを「運転中」から「待機中」に変更指示を行う（ステップＳ６０７）。
【０１８６】
これにより、当該サーバ（０系サーバ１）は、第１の実施形態で説明した図１０に示すような処理を行い、論理ＩＰアドレス「172.16.1.2」を自サーバ（０系サーバ１）設定し、代替する論理ノード名「関西１」をキーとして、ストレージ内の関西１データを参照してサービスを提供する。
【０１８７】
また、予備サーバ４は、論理ＩＰアドレス設定部４３２が論理ＩＰアドレス「172.16.1.1」を設定し（ステップＳ６０８）、サービスデータ取得部４３５が論理ノード名「関東１」をキーとして、ストレージ５内の関東１のサービスデータを参照してサービスを提供する（ステップＳ６０９）。
【０１８８】
第３の冗長制御処理によれば、予備サーバ４のストレージサイズが拠点内の全ノード分だけで済むが、サーバ切り替えが２回発生する場合がある。
【０１８９】
（Ｂ−３）第２の実施形態の効果
上記のように、第２の実施形態によれば、拠点災害が発して、ある拠点の待機状態のサーバが被災拠点のサーバの代わりにサービスを提供している状態において、いずれかのサーバ故障が発生した場合、各拠点に設置された予備サーバに切り替えてサービスを提供することができる。
【０１９０】
（Ｃ）他の実施形態
上述した第１及び第２の実施形態では、ＩＰ電話の接続を制御するサーバに適用した場合を例として説明したが、その他のＩＰネットワークサーバにも適用可能である。
【０１９１】
上述した第１及び第２の実施形態では、関東と関西の２拠点の場合を例として説明したが、２拠点以上の複数拠点で運用する場合にも適用可能である。
【０１９２】
上述した第１及び第２の実施形態では、サービスデータの格納先として、ノード毎に０系サーバと１系サーバで共有するストレージを利用する形態で説明したが、拠点内の全ノードで共有する別サーバ（ファイルサーバやＤＢサーバ）を利用した場合にも適用可能である。
【符号の説明】
【０１９３】
１…０系サーバ、２…１系サーバ、３…ストレージ、４…予備サーバ、５…ストレージ、１０Ａ及び１０Ｂ…復旧システム、１０１…アプリケーション、１０２…冗長制御部、
１０３…ＯＳ、１０４…ハードディスク、
１１…動作モード認識部、１２…通常モード（運転中）制御部、
１３…通常モード（待機中）制御部、１４…代替モード制御部、１５…接続先決定部、
１２１…サーバ情報検索部、１２２…論理ＩＰアドレス設定部、
１２３…サービスデータ取得部、１４１…サーバ情報検索部、
４１１、４２１、４３１…論理ＩＰアドレス取得部、
１４２、４１２、４２２、４３２…論理ＩＰアドレス設定部、
１４３、４１３、４２５、４３５…サービスデータ取得部、
４２３…物理ＩＰアドレス取得部、４２４…サービスコピー部、
４３３…サービスデータ確認部、４３４…状態変更指示部。
【技術分野】
【０００１】
本発明は、復旧システム、復旧方法、冗長制御装置及び冗長制御プログラムに関し、例えば、火災や地震等のように大規模な災害によって、ある拠点に設置したサーバ全体が使用不可能となった場合に、当該サーバが提供していたサービスを迅速に復旧させるシステムや方法等に適用し得るものである。
【背景技術】
【０００２】
例えば、コールサーバ等のように音声通信を実現するサーバは高可用性が求められており、サーバ等に障害が発生した場合には、迅速かつ確実にサービスを復旧することが求められている。
【０００３】
従来、上記のような高可能性が求められるサーバの復旧システムとしては、主として、次に示すような第１の方法〜第３の方法を用いて実現している。
【０００４】
（第１の方法）
第１の方法は、例えば、２台のサーバが論理的に１台のサーバのように見せかける方法である。第１の方法について図２を用いて説明する。
【０００５】
第１の方法では、サービスを提供するために参照する各種データは、２台のサーバ５１０及び５２０が共有して使用するストレージ５３０に格納されている。
【０００６】
２台のサーバをそれぞれ０系サーバ５１０、１系サーバ５２０とし、２台のサーバと共有ストレージ５３０とを有してサービスを提供する単位を「ノード５００」と呼ぶことにする。また、ノード５００がサービスを提供する際に参照するデータを総称して、そのノード５００の「サービスデータ」を呼ぶことにする。
【０００７】
ＩＰアドレスは、割り当て単位、及び、使用目的に応じて、物理ＩＰアドレスと論理ＩＰアドレスを使用する。物理ＩＰアドレスは、サーバ単位に固定的に割り当て、サーバの稼働状態を監視する目的等で使用する。論理ＩＰアドレスは、ノード単位に付与し、そのノードがサービスを提供するために使用する。
【０００８】
２台のサーバの内、どちらか一方のサーバの稼働状態だけが「運転中」に設定され、もう一方のサーバの稼働状態は「待機中」に設定される。このとき、「運転中」のサーバに対して、ノードに割り当てられた論理ＩＰアドレスを設定し、「運転中」のサーバがストレージ内のサービスデータを参照しながらサービスを提供する。
【０００９】
例えば、図２（Ａ）では、０系サーバ５１０が「運転中」となり、１系サーバが「待機中」となっている。その結果、０系サーバ５１０に論理ＩＰアドレス「172.16.1.1」が設定され、０系サーバ５１０がストレージ５３０内のサービスデータを参照してサービスを提供している。
【００１０】
そして、「運転中」のサーバが故障により使用不能となった場合には、「稼働中」のサーバの稼働状態が「運転中」に変わり、サービスの提供を引き継ぐ。その後、故障したサーバが修理されて復旧した場合、復旧したサーバの稼働状態は「待機中」となる。
【００１１】
例えば、図２（Ａ）において、「運転中」の０系サーバ５１０が故障した場合には、１系サーバ５２０の稼働状態が「待機中」から「運転中」に変更され、図２（Ｂ）に示す状態となる。
【００１２】
図２（Ｂ）では、０系サーバ５１０が「故障中」のため、１系サーバ５２０が「運転中」となっている。その結果、１系サーバ５２０に論理ＩＰアドレス「172.16.1.1」が設定され、１系サーバ５２０がストレージ５３０内のサービスデータを参照してサービスを提供することになる。また図２（Ｂ）において、「故障中」の０系サーバ５１０が復旧した場合には、０系サーバ５２０の稼働状態が「待機中」に設定され、図２（Ｃ）に示す状態となる。
【００１３】
上記のように、第１の方法では、０系サーバと１系サーバの間でサービスを提供するサーバが切り替わってもサービスを提供するＩＰアドレスは同一の論理ＩＰアドレスであるため、このノードと通信する他のノードから見た場合、サービスの中断時間はサーバの切り替え時間だけの短時間で済む。
【００１４】
また、第１の方法では、サービスを提供するために使用する論理的ＩＰアドレスを２台のサーバ間で動的に設定するため、２台のサーバは、同一拠点の同一サブネット内に設置する必要がある。
【００１５】
このため、第１の方法の場合、故障のため片方のサーバが使用不能となる状況においては、短時間でサービスを回復することができるが、被災拠点内の全サーバが使用不能となるような状況においては、０系サーバと１系サーバの両方が同時に使用不能となるため、サービスを回復することができない。
【００１６】
（第２の方法）
第２の方法は、拠点内の運用サーバの他に、予備サーバを設置しておく方法である。このとき、予備サーバのストレージには、同一拠点内の全ての運用サーバから、定期的にサービスデータをコピーしておく。第２の方法について図３を用いて説明する。
【００１７】
通常は、運用サーバに対して、ノードに割り当てられた論理ＩＰアドレスを設定し、運用サーバがストレージ内のサービスデータを参照しながらサービスを提供する。
【００１８】
図３（Ａ）では、運用サーバ５４０に論理ＩＰアドレス「172.16.1.1」が設定され、運用サーバ５４０がストレージ５５０内のサービスデータを参照してサービスを提供する。
【００１９】
そして、運用サーバが故障により使用不能となった場合には、予備サーバがサービスの提供を引き継ぐ。その後、故障した運用サーバが修理されて復旧した場合には、予備サーバから運用サーバにサービスの提供を引き継ぐ。
【００２０】
例えば、図３（Ａ）において、運用サーバ５４０が故障した場合には、図３（Ｂ）に示す状態となる。図３（Ｂ）では、運用サーバ５４０が「故障中」のため、予備サーバ５６０に論理ＩＰアドレス「172.16.1.1」が設定され、予備サーバ５６０がストレージ５７０内に持っている故障した運用サーバ５４０のサービスデータを参照してサービスを提供する。
【００２１】
その後、図３（Ｂ）において、故障した運用サーバ５４０が復旧した場合には、再び、図３（Ａ）に示す状態に戻り、運用サーバ５４０がサービスを提供する。
【００２２】
第２の方法の場合、運用サーバと予備サーバの間でサービスを提供するサーバが切り替わってもサービスを提供するＩＰアドレスは同一の論理ＩＰアドレスであるため、このノードと通信する他のノードから見た場合、サービスの中断時間はサーバの切り替え時間だけの短時間となる。
【００２３】
また、第２の方法では、サービスを提供するために使用する論理的ＩＰアドレスを運用サーバと予備サーバの間で動的に設定するため、運用サーバと予備サーバは、同一拠点の同一サブネット内に設置する必要がある。
【００２４】
このため、第２の方法の場合、故障のため運用サーバが使用不能となる状況においては、短時間でサービスを回復することができるが、被災拠点内の全サーバが使用不能となるような状況においては、運用サーバと予備サ−バの両方が同時に使用不能となるため、サービスを回復することができない。
【００２５】
（第３の方法）
第３の方法は、被災拠点内の全サーバが使用不能となるような状況においてもサービスの提供を回復可能とするために、運用拠点とは異なる予備拠点に予備のノードを設置しておく方式である。このとき、予備拠点には、全ての拠点の全てのノードから、定期的にサービスデータをバックアップしておく。第３の方法について図４及び図５を用いて説明する。
【００２６】
図４では、関東拠点と関西拠点が運用拠点で、東海拠点が予備拠点となっている。被災拠点内の全ノードが使用不能とった場合には、被災拠点のノード５００に代わって、予備拠点のノード５８０がサービスの提供を引き継ぐ。
【００２７】
図４において、関西拠点が被災して、関西拠点の運用サーバ５１０が使用不能となった場合には、図５に示すような状態となる。図５では、予備拠点の東海拠点にバックアップされた関西拠点のノード５００のサービスデータを、東海拠点の予備ノード５８０にコピーし、東海拠点の予備ノード５８０が関西拠点の運用ノード５００のサービスを引き継いでいる。
【００２８】
ただし、予備ノード５８０は運用ノード５００とは別な拠点のサブネット内に設置されているので、運用ノードと予備ノードでは異なる論理ＩＰアドレスを使用することになる。このため、サービスを再開する前に、被災拠点以外の全ノードと予備拠点の全ノードにおいて、通信相手のＩＰアドレスに関する情報を変更する必要がある。
【００２９】
図５では、サービスデータとして、電話番号から接続先ノードの論理ＩＰアドレスを求めるためのルーチング情報を持っている場合を示している。
【００３０】
例えば、図４のルーチング情報では電話番号「06」に対して関西１ノードの論理ＩＰアドレス「172.17.1.1」が設定されており、電話番号「075」に対して関西２ノードの論理ＩＰアドレス「172.17.2.1」が設定されている。
【００３１】
被災した関西拠点の代わりに東海拠点がサービスを引き継ぐためには、図５のようにルーチング情報を書き換え、電話番号「06」に対して東海１ノードの論理ＩＰアドレス「172.18.1.1」を設定し、電話番号「075」に対して東海２ノードの論理ＩＰアドレス「172.18.1.2」を設定しなければならない。
【００３２】
第３の方法では、被災拠点内の全サーバが使用不能となるような状況において、サービス提供を回復することが可能となっているが、バックアップからのサービスデータのコピー作業と、その後のサービスデータの変更作業が必要となるため、被災拠点のサービス提供が回復するまでには時間がかかる。
【先行技術文献】
【特許文献】
【００３３】
【特許文献１】特開２００７−６０３５号公報
【発明の概要】
【発明が解決しようとする課題】
【００３４】
例えば、ＩＰ電話の接続を制御するサーバの場合、０系サーバと１系サーバとの間で「運転中」のサーバが切り替わっても、接続済みセッションを切断することなく、切り替わった系でセッションを継続できるようにする目的で、第１の方法を用いる場合がある。
【００３５】
「運転中」状態のサーバが切り替わっても、接続済みセッションを０系サーバと１系サーバの間で引き継げるようにするため、セッションの情報を「運転中」の系から「待機中」の系への転送をする。
【００３６】
系間でのセッション情報の転送は、セッション毎、及び、セッションの状態変更毎に必要となるため、セッション情報の転送に必要な通信量は大きい。このため、セッション情報の転送は、ストレージ経由ではなく、系間を接続する専用のＬＡＮ（ローカルエリアネットワーク）を用意して、直接系間で通信を実施する。
【００３７】
このように、多量のセッション情報の転送を実施するため、ＩＰ電話の接続を制御するサーバでは、「運転中」状態のサーバと「待機中」状態のサーバが対になっている第１の方法の構成が望ましい。
【００３８】
ただし、第１の方法だけでは、被災拠点の全てのノードが使用不能となるような状況ではサービスを継続できなくなるため、図４及び図５に示すように、第１の方法と第３の方法を併用する場合がある。
【００３９】
しかしながら、第１の方法と第３の方法とを組み合わせた方法には、次のような問題が生じ得る。
【００４０】
第１に、第１の方法のためのサーバ２重化に加えて、第３の方法のための予備拠点および予備サーバを用意する必要があり、コストが大きくなるという問題が生じ得る。
【００４１】
第２に、拠点災害時の復旧には、第３の方法を用いるため、バックアップからのサービスデータのコピー作業と、その後のサービスデータの変更作業のため、サービス中断時間が長くなるという問題が生じ得る。
【００４２】
そこで、本発明は、上記課題に鑑み、予備拠点及び予備サーバを用意するためのコストを軽減し、サービス中断時間を短縮することができる復旧システム、復旧方法、冗長制御装置及び冗長制御プログラムを提供する。
【課題を解決するための手段】
【００４３】
かかる課題を解決するために、第１の本発明の復旧システムは、各拠点に、サービス提供を実行する第１サーバと待機する第２サーバと上記サービス提供に必要なサービスデータを保存するデータ保存手段とを有して、サービスの提供を行う１又は複数のノードを備え、（１）各ノードは、他の拠点に設置された他ノードとの間で代替関係が設定されており、（２）データ保存手段は、自ノードが提供するサービスのサービスデータと、他の拠点の代替関係にある他ノードが提供するサービスのサービスデータとを保存するものであり、（３）第２サーバが、第１サーバの障害又は他拠点の代替関係にある他ノードの障害発生時に、データ保存手段から必要なサービスデータを取得して、障害の生じたサービスの提供を実行することを特徴とする。
【００４４】
第２の本発明の復旧方法は、各拠点に、サービス提供を実行する第１サーバと待機する第２サーバと上記サービス提供に必要なサービスデータを保存するデータ保存手段とを有して、サービスの提供を行う１又は複数のノードを備え、（１）各ノードは、他の拠点に設置された他ノードとの間で代替関係を設定し、（２）データ保存手段は、自ノードが提供するサービスのサービスデータと、他の拠点の代替関係にある他ノードが提供するサービスのサービスデータとを保存し、（３）第２サーバが、第１サーバの障害又は他拠点の代替関係にある他ノードの障害発生時に、データ保存手段から必要なサービスデータを取得して、障害の生じたサービスの提供を実行することを特徴とする。
【００４５】
第３の本発明の冗長制御装置は、所定のサービスを提供する同一ノードにおける他のサーバ、又は、予め設定された他の拠点の代替関係が設定された他のサーバとの間で冗長構成をとるサーバの冗長制御装置であって、（１）自ノードが提供するサービスのサービスデータと、他の拠点の代替関係にある他ノードが提供するサービスのサービスデータとを保存するデータ保存手段と、（２）自ノードが通常時にサービスを提供する通常モード時の論理ノード情報と、他拠点の代替関係にあるノードのサービスを提供する代替モード時の論理ノード情報とをノード毎に予め設定したサーバ情報を格納するサーバ情報格納手段と、（３）自身の動作状態を認識する動作状態認識手段と、（４）動作状態認識手段により認識された自身の動作状態に応じて、サーバ情報から論理ノード情報を検索し、検索した論理ノード情報に対応するサービスデータをデータ保存手段から取得して冗長制御を行う冗長制御手段とを備えることを特徴とする。
【００４６】
第４の本発明の冗長制御プログラムは、所定のサービスを提供する同一ノードにおける他のサーバ、又は、予め設定された他の拠点の代替関係が設定された他のサーバとの間で冗長構成をとるサーバの冗長制御プログラムであって、自ノードが提供するサービスのサービスデータと、他の拠点の代替関係にある他ノードが提供するサービスのサービスデータとを保存するデータ保存手段と、自ノードが通常時にサービスを提供する通常モード時の論理ノード情報と、他拠点の代替関係にあるノードのサービスを提供する代替モード時の論理ノード情報とをノード毎に予め設定したサーバ情報を格納するサーバ情報格納手段とを備える冗長制御装置を、（１）自身の動作状態を認識する動作状態認識手段、（２）動作状態認識手段により認識された自身の動作状態に応じて、サーバ情報から論理ノード情報を検索し、検索した論理ノード情報に対応するサービスデータをデータ保存手段から取得して冗長制御を行う冗長制御手段として機能させることを特徴とする。
【発明の効果】
【００４７】
本発明によれば、予備拠点及び予備サーバを用意するためのコストを軽減し、サービス中断時間を短縮することができる。
【図面の簡単な説明】
【００４８】
【図１】第１の実施形態の復旧システムの構成を示す構成図である。
【図２】従来の第１の復旧方法を説明する説明図である。
【図３】従来の第２の復旧方法を説明する説明図である。
【図４】従来の第３の復旧方法を説明する説明図である（その１）。
【図５】従来の第３の復旧方法を説明する説明図である（その２）。
【図６】第１の実施形態のサーバの内部構成を示す内部構成図である。
【図７】第１の実施形態のサーバの冗長制御部の機能構成を示すブロック図である。
【図８】第１の実施形態のサーバ情報の構成を説明する説明図である。
【図９】第１の実施形態のサービスデータの構成を説明する説明図である。
【図１０】第１の実施形態のサーバにおける冗長制御処理を示すフローチャートである。
【図１１】第１の実施形態において正常時の動作の様子を示す説明図である。
【図１２】第１の実施形態において０系サーバが故障した場合の様子を示す説明図である。
【図１３】第１の実施形態において他の拠点の代替関係にあるノードが故障した場合の様子を示す説明図である。
【図１４】第１の実施形態において接続先決定処理を示すフローチャートである。
【図１５】第１の実施形態の通常モードのときの接続先決定処理の様子を示す説明図である（その１）。
【図１６】第１の実施形態の通常モードのときの接続先決定処理の様子を示す説明図である（その２）。
【図１７】第１の実施形態の代替モードのときの接続先決定処理の様子を示す説明図である（その１）。
【図１８】第１の実施形態の代替モードのときの接続先決定処理の様子を示す説明図である（その２）。
【図１９】第２の実施形態の復旧システムの構成を示す構成図である。
【図２０】第２の実施形態の第１の冗長制御処理におけるサーバの状態を説明する説明図である。
【図２１】第２の実施形態の第１の冗長制御処理を行う予備サーバの冗長制御部の機能構成を示すブロック図である。
【図２２】第２の実施形態の第１の冗長制御処理を示すフローチャートである。
【図２３】第２の実施形態の論理ＩＰアドレス取得処理を示すフローチャートである。
【図２４】第２の実施形態の第１の冗長制御処理におけるサーバの状態を説明する説明図である。
【図２５】第２の実施形態の第２の冗長制御処理におけるサーバの状態を説明する説明図である。
【図２６】第２の実施形態の第２の冗長制御処理を行う予備サーバの冗長制御部の機能構成を示すブロック図である。
【図２７】第２の実施形態の第２の冗長制御処理を示すフローチャートである。
【図２８】第２の実施形態の第２の冗長制御処理におけるサーバの状態を説明する説明図である（その１）。
【図２９】第２の実施形態の第２の冗長制御処理におけるサーバの状態を説明する説明図である（その２）。
【図３０】第２の実施形態の第３の冗長制御処理におけるサーバの状態を説明する説明図である。
【図３１】第２の実施形態の第３の冗長制御処理を行う予備サーバの冗長制御部の機能構成を示すブロック図である。
【図３２】第２の実施形態の第３の冗長制御処理を示すフローチャートである。
【図３３】第２の実施形態の第３の冗長制御処理におけるサーバの状態を説明する説明図である（その１）。
【図３４】第２の実施形態の第３の冗長制御処理におけるサーバの状態を説明する説明図である（その２）。
【発明を実施するための形態】
【００４９】
（Ａ）第１の実施形態
以下では、本発明の復旧システム、復旧方法、冗長制御装置及び冗長制御プログラムの第１の実施形態を図面を参照しながら説明する。
【００５０】
第１の実施形態は、例えば、ＩＰネットワーク上で音声通信を実現するサーバ（例えばコールサーバ等）を各拠点に設置してＩＰ電話サービスを提供するシステムの復旧システムに本発明を適用した場合の実施形態を例示して説明する。
【００５１】
（Ａ−１）第１の実施形態の構成
図１は、第１の実施形態に係るＩＰ電話システムの復旧システムの構成を示す構成図である。図１に例示するように、第１の実施形態の復旧システム１０Ａは、ＩＰ電話サービスを提供する運用拠点として、例えば２箇所の関東拠点と関西拠点を備え、関東拠点と関西拠点との間でＷＡＮ（ワイドエリアネットワーク）を形成するネットワークである。
【００５２】
関東拠点及び関西拠点ではそれぞれ、関東拠点ＬＡＮ及び関西拠点ＬＡＮが敷設されており、この関東拠点ＬＡＮ及び関西拠点ＬＡＮにはそれぞれ、３台のノードＥＮ１〜ＥＮ３及びノードＷＮ１〜ＷＮ３が接続されている。ここで、関東拠点ＬＡＮと関西拠点ＬＡＮは、それぞれ異なるサブネットである。
【００５３】
ノードＥＮ１〜ＥＮ３及びノードＷＮ１〜ＷＮ３は、各拠点でのＩＰ電話を制御するものであり、それぞれサーバを識別するための論理的なノード名が付与されている。関東拠点に設置のノードＥＮ１〜ＥＮ３のノード名はそれぞれ「関東１」、「関東２」、「関東３」とし、関西拠点に設置のノードＷＮ１〜ＷＮ３のノード名はそれぞれ「関西１」、「関西２」、「関西３」とする。
【００５４】
ノードＥＮ１〜ＥＮ３及びノードＷＮ１〜ＷＮ３は、０系サーバ１及び１系サーバ２の２台のサーバと、ストレージ３とを少なくとも有して、２重化構成（冗長構成）によりサーバの故障に備えた高可用性を実現している。
【００５５】
また、ノードＥＮ１〜ＥＮ３及びノードＷＮ１〜ＷＮ３は、異なる拠点のノードとの間で１対１の対応付けがなされている。この対応付けの関係により、拠点被災時に互いにサービス提供を代替して行うことができる。
【００５６】
ここでは、「関東１」と「関西１」、「関東２」と「関西２」、「関東３」と「関西３」のノードが対応付けられて代替関係にある。例えば、関西拠点が被災して関西拠点の全てのノードＷＮ１〜ＷＮ３が故障した場合、「関東１」ノードＥＮ１が「関西１」ノードＷＮ１のサービス提供を代替し、「関東２」ノードＥＮ２が「関西２」ノードＷＮ２のサービス提供を代替し、「関東３」ノードＥＮ３が「関西３」ノードＷＮ３のサービス提供を代替する。
【００５７】
図６は、０系サーバ１及び１系サーバ２の構成を示す構成図である。０系サーバ１及び１系サーバ２は同じ構成を備えており、自身が動作する状態に応じて実行する動作モードが異なる。なお、図６では、０系サーバ１及び１系サーバ２をまとめてサーバ１００と示す。
【００５８】
図６において、サーバ１００は、アプリケーション１０１、冗長制御部１０２、ＯＳ１０３、ハードディスク１０４を少なくとも有する。
【００５９】
アプリケーション１０１は、自サーバが提供するサービスに関するアプリケーション（例えば、ＩＰ電話等）である。ＯＳ１０３は、例えばＬｉｎｕｘ（登録商標）等の一般的なＯＳを適用することができる。
【００６０】
冗長制御部１０２は、ＯＳ１０３上で動作するものであり、自ノードにおける他のサーバや、他の拠点の代替関係にある他ノードの障害発生時に、ストレージ３からサービスの提供に必要なサービスデータを取得して、障害の生じたサービスの提供を実行する冗長制御を行うものである。
【００６１】
図７は、冗長制御部１０２の機能構成を示すブロック図である。図７において、冗長制御部１０２は、動作モード認識部１１、通常モード（運転中）制御部１２、通常モード（待機中）制御部１３、代替モード制御部１４、接続先決定部１５を少なくとも有する。
【００６２】
動作モード認識部１１が、自身の動作モードを認識するものである。動作モード認識部１１は、自サーバの動作モードに応じて、通常モード（運転中）制御部１２、通常モード（待機中）制御部１３、代替モード制御部１４による制御を実行させる。なお、動作モード認識部１１の認識する動作モードとしては、通常モード（運転中）、通常モード（待機中）、代替モード、故障中などを認識する。
【００６３】
例えば、自サーバが１系サーバの場合、動作モード認識部１１は自サーバの通常時を通常モード（運転中）と認識する。しかし、既存の故障検出方法等により自サーバの故障が検出された場合、動作モード認識部１１は故障中と認識する。
【００６４】
また例えば、自サーバが０系サーバの場合、動作モード認識部１１は自サーバの通常時を通常モード（待機中）と認識する。しかし、既存の故障検出方法（例えばｐｉｎｇ等を利用した生存確認方法を用いた故障検出方法）等により、自ノードの１系サーバ２の故障を検出した場合、動作モード認識部１１は自サーバを通常モード（運転中）と認識する。さらに、例えば既存の故障検出方法（例えばｐｉｎｇ等を利用した生存確認方法を用いた故障検出方法）等により代替関係にある他拠点のノードが故障した場合、動作モード認識部１１は自サーバを代替モードと認識する。
【００６５】
通常モード（運転中）制御部１２は、動作モードが通常モード（運転中）の場合に、自サーバの動作を制御するものである。通常モード（運転中）制御部１２の機能構成としては、サーバ情報検索部１２１、論理ＩＰアドレス設定部１２２、サービスデータ取得部１２３を少なくとも有する。
【００６６】
サーバ情報検索部１２１は、自サーバの物理ＩＰアドレスをキーとして、ハードディスク１０４に保持されるサーバ情報から、自サーバの動作モードに応じた論理ノード情報（論理ノード名及び論理ＩＰアドレス）を検索して取得するものである。
【００６７】
ここで、論理ノード情報とは、サービス提供を行う論理ノードに関する情報であり、特に論理ノード名及び論理ＩＰアドレスをいう。
【００６８】
論理ＩＰアドレス設定部１２２は、サーバ情報検索部１２１により検索された通常モードの論理ＩＰアドレスを自サーバに設定するものである。これにより、論理ＩＰアドレスを用いてサービスの提供を実行することができる。
【００６９】
サービスデータ取得部１２３は、サーバ情報検索部１２１により検索された通常モードの論理ノード名に対応するサービスデータを、ストレージ３から取得するものである。これにより、当該論理ノード名のサービスデータを取得することができ、このサービスデータを用いて引き続きサービス提供を継続することができる。
【００７０】
通常モード（待機中）制御部１３は、動作モードが通常モード（待機中）の場合に、自サーバの動作を待機状態に制御する。
【００７１】
代替モード制御部１４は、動作モードが代替モードの場合に、自サーバの動作を制御するものである。代替モード制御部１４の機能構成としては、サーバ情報検索部１４１、論理ＩＰアドレス設定部１４２、サービスデータ取得部１４３を少なくとも有する。
【００７２】
サーバ情報検索部１４１は、自サーバの物理ＩＰアドレスをキーとして、ハードディスク１０４に保持されるサーバ情報から、代替モードの論理ノード名及び論理ＩＰアドレスを検索して取得するものである。
【００７３】
論理ＩＰアドレス設定部１４２は、サーバ情報検索部１４１により検索された代替モードの論理ＩＰアドレスを自サーバに設定するものである。これにより、論理ＩＰアドレスを用いてサービスの提供を実行することができる。
【００７４】
サービスデータ取得部１４３は、サーバ情報検索部１４１により検索された代替モードの論理ノード名に対応するサービスデータを、ストレージ３から取得するものである。これにより、当該論理ノード名のサービスデータを取得することができ、このサービスデータを用いて引き続きサービス提供を継続することができる。
【００７５】
接続先決定部１５は、ストレージ３に保持されるサービスデータ（ルーチング情報）を用いて、ユーザ端末の電話番号から接続すべきサーバを決定するものである。接続先決定部１５の処理は、動作の項において詳細に説明する。
【００７６】
ハードディスク１０４は、各ノードＥＮ１〜ＥＮ３及びＷＮ１〜ＷＮ３の拠点間の代替関係を示すサーバ情報を保持するものである。全てのサーバは、同じ内容のサーバ情報をハードディスク１０４に保持している。
【００７７】
図８は、サーバ情報の構成例を例示する説明図である。図８に示すように、サーバ情報は、「物理ＩＰ」、「通常モード」、「代替モード」を大きな項目とする。そして、図８に示すサーバ情報は、０系サーバと１系サーバの物理ＩＰアドレス、代替運用していない「通常モード」での論理ノード名と論理ＩＰアドレス、代替運用している「代替モード」での論理ノード名と論理ＩＰアドレスを一組とした情報を持っている。
【００７８】
また、図８に例示するサーバ情報は、「関東１」と「関西１」、「関東２」と「関西２」、「関東３」と「関西３」のノード組み合わせで代替関係を登録している。この設定の場合、関東拠点が被災した場合には、関東１〜関東３のサーバに代わりに関西１〜関西３のサーバが代替し、関西拠点が被災した場合には、関西１〜関西３に代わり、関東１〜関東３のサーバが代替してサービスを提供する。
【００７９】
このように、代替関係にあるサーバは、互いに相手のサービスを引き継いでサービスの提供を行うため、各拠点間のサーバは、相互にサービスデータを定期的に交換し合い、相互のサービスデータをストレージ３に保持している。
【００８０】
ストレージ３は、各ノードの０系サーバ１及び１系サーバ２が共用するサービスデータと、代替関係にある他拠点のノードのサービスデータを保持するものである。ここで、サービスデータとは、ノードがサービス提供する際に参照するデータの総称をいう。例えば、ＩＰ電話サービスを提供する場合、サービスデータは、呼の接続制御に必要なデータをいい、例えば、ユーザ情報やルーチング情報等を含む。
【００８１】
ストレージ３は、代替関係にある他拠点のノードと定期的にサービスデータの交換を行い、サービスデータの更新を行っている。また、ストレージは、自ノードのサービスデータと、代替関係にある他ノードのサービスデータとの区別するために、サービスデータを論理ノード名毎に格納する。すなわち、例えば、関東１ノードＥＮ１の場合、論理ノード名「関東１」のサービスデータと、論理ノード名「関西１」のサービスデータとを、論理ノード名がアクセスキーとなるようにして格納する。
【００８２】
図９は、ストレージ３に保存されるサービスデータの例を示す構成図である。図９（Ａ）及び図９（Ｂ）はユーザ情報の構成例であり、図９（Ｃ）はルーチング情報の構成例を示す。
【００８３】
図９（Ａ）及び図９（Ｂ）に例示するように、ユーザ情報は、ユーザ端末の電話番号とユーザ端末のＩＰアドレスとを対応付けた情報である。ここで、ユーザ端末は、接続するノードによる呼制御を受ける。そのため、各ノードＥＮ１〜ＥＮ３及びＷＮ１〜ＷＮ３は、それぞれ異なるユーザ情報を保持している。
【００８４】
例えば、図９（Ａ）は、「関東１」ノードＥＮ１が保持するユーザ情報例であり、例えば電話番号が「0322220001」のユーザ端末のＩＰアドレスは「10.10.0.1」であることを示す。また、図９（Ｂ）は、「関西１」ノードＷＮ１が保持するユーザ情報例であり、例えば、電話番号が「0622220001」のユーザ端末のＩＰアドレスは「10.20.0.1」であることを示す。
【００８５】
図９（Ｃ）に例示するように、ルーチング情報は、電話番号に対して接続先となるノードとの対応関係を示す情報である。例えば、図９（Ｃ）において、電話番号「03」で始まる電話番号のユーザ端末の呼制御を行う場合には、「関東１」ノードＥＮ１が接続先となる。
【００８６】
なお、サービスデータは、例えばルーチング情報のようにノードを示す情報の場合、論理ＩＰアドレスだけでなく、「論理ノード名」を用いて指定するようにする。
【００８７】
（Ａ−２）第１の実施形態の動作
次に、第１の実施形態の復旧システムの処理の動作を、図面を参照しながら詳細に説明する。
【００８８】
図１０は、各ノードのサーバ１００における冗長制御処理の動作を示すフローチャートである。図１０に示す処理では、サーバ１００が、どの論理ＩＰアドレスを用いて、どのノードのサービスを提供するかを決定する。
【００８９】
（Ａ−２−１）正常時の処理
まず、全拠点のサーバが正常に動作する場合を例示する。図１１は、正常時のノードにおけるサーバの様子を示す説明図である。なお、図１１では、「関東１」ノードＥＮ１の様子を例示する。
【００９０】
この場合、拠点の全ノードＥＮ１〜ＥＮ３及びＷＮ１〜ＷＮ３は、０系サーバ１及び１系サーバ２のどちらか一方が「運転中」に設定され、他方が「待機中」に設定される。また、両方のサーバはいずれも「通常モード」に設定される。
【００９１】
例えば、図１１（Ａ）において、物理ＩＰアドレス「172.16.1.10」の０系サーバ１が「運転中」である場合、０系サーバ１の動作モード認識部１１は、自サーバが通常モード（運転中）であると判断し（ステップＳ１０１）、ステップＳ１０２に移行する。
【００９２】
図１１（Ｂ）に示すように、０系サーバ１において、通常モード（運転中）制御部１２のサーバ情報検索部１２１は、自サーバの物理ＩＰアドレス「172.16.1.10」をキーとして、サーバ情報の物理ＩＰの欄を検索し、一致した行の通常モード欄から論理ノード名「関東１」及び論理ＩＰアドレス「172.16.1.1」を取得する（ステップＳ１０２）。
【００９３】
そして、論理ＩＰアドレス設定部１２２は、論理ＩＰアドレス「172.16.1.1」を自サーバに設定し（ステップＳ１０３）、サービスデータ取得部１２３が、論理ノード名「関東１」をキーとして、ストレージ３のサービスデータから「関東１」のサービスデータを取得する（ステップＳ１０４）。これにより、０系サーバ１は、「関東１」ノードＥＮ１の通常モード（運転中）として動作し、「関東１」ノードＥＮ１に求められるサービスを提供することができる。
【００９４】
一方、例えば、図１１（Ａ）及び（Ｃ）に示すように、１系サーバ２は「待機中」となるため（ステップＳ１０１）、ステップＳ１０５に移行する。このとき、１系サーバ２は、正常に動作しているため「通常モード」であるから（ステップＳ１０５）、サービスの提供をせずに待機する（ステップＳ１０６）。
【００９５】
（Ａ−２−２）自ノードの「運転中」サーバの故障時の処理
次に、自ノードの「運転中」サーバの故障時の処理動作を説明する。図１２は、「運転中」サーバの故障時の処理動作の様子を示す説明図である。
【００９６】
例えば、図１２（Ａ）に示すように、「運転中」の０系サーバ１が故障した場合、１系サーバ２が、「待機中」から「運転中」に状態変更する。
【００９７】
なお、状態変更処理の方法は、種々の方法を適用することができ、例えば、既存する故障検出方法等により０系サーバ１の故障検出を契機として、１系サーバ２は「待機中」から「運転中」に状態を変更する。
【００９８】
まず、「関東１」ノードＥＮ１において、状態変更により１系サーバ２は「運転中」となるから（ステップＳ１０１）、１系サーバ２のサーバ情報検索部１２１は、図１２（Ｂ）に示すように、１系サーバ２の物理ＩＰアドレス「172.16.1.11」をキーとして、サーバ情報の物理ＩＰ欄を検索して、一致する行の通常モード欄から、論理ノード名「関東１」及び論理ＩＰアドレス「172.16.1.1」を取得する（ステップＳ１０２）。
【００９９】
そして、論理ＩＰアドレス設定部１２２は、論理ＩＰアドレス「172.16.1.1」を自サーバに設定し（ステップＳ１０３）、サービスデータ取得部１２３が、論理ノード名「関東１」をキーとして、ストレージ３のサービスデータから「関東１」のサービスデータを取得する（ステップＳ１０４）。これにより、図１２（Ｃ）に示すように、１系サーバ２は、「関東１」ノードＥＮ１の通常モード（運転中）として動作し、「関東１」ノードＥＮ１に求められるサービスを提供することができる。
【０１００】
（Ａ−２−３）拠点の全ノードが被災した場合の処理
次に、拠点の全ノードが被災した場合の処理動作を説明する。図１３は、代替関係にあるノードが故障した場合の処理動作の様子を示す説明図である。
【０１０１】
例えば、関西拠点の「関西１」〜「関西３」の全ノードＷＮ１〜ＷＮ３が被災に遭い、使用不能となった場合、関東拠点の「関東１」〜「関東３」のノードＥＮ１〜ＥＮ３は「通常モード」から「代替モード」に状態変更する。
【０１０２】
なお、「代替モード」への状態変更の方法も、種々の方法を適用することができ、例えば、既存の故障検出方法等により代替関係にあるノード又はサーバの故障検出を契機として、「通常モード」から「代替モード」への状態変更とする方法を適用できる。
【０１０３】
例えば、図１３（Ａ）において、「関東１」ノードＥＮ１の０系サーバ１は、「運転中」であるので、０系サーバ１は、引き続き論理ＩＰアドレス「172.16.1.1」を用いて論理ノード名「関東１」のサービスを提供する。
【０１０４】
一方、図１３（Ａ）に例示する「待機中」の１系サーバ２は、「通常モード」から「代替モード」に変更するので（ステップＳ１０５）、ステップＳ１０７に移行し、代替ノードの論理ＩＰアドレスと論理ノードが決められる。
【０１０５】
まず、図１３（Ｂ）に示すように、１系サーバ２において、代替モード制御部１４のサーバ情報検索部１４１は、自サーバの物理ＩＰアドレス「172.16.1.11」をキーとして、サーバ情報の物理ＩＰ欄から検索し、一致する行の代替モード欄から論理モード名「関西１」及び論理ＩＰアドレス「172.16.1.2」を取得する（ステップＳ１０７）。
【０１０６】
そして、論理ＩＰアドレス設定部１４２は、論理ＩＰアドレス「172.16.1.2」を自サーバに設定し（ステップＳ１０８）、サービスデータ取得部１４３が、論理ノード名「関西１」をキーとして、ストレージ３のサービスデータから「関西１」のサービスデータを取得する（ステップＳ１０９）。
【０１０７】
これにより、図１３（Ｃ）に示すように、１系サーバ２は、代替モードとして動作し、「関西１」ノードＷＮ１のサービスを提供することができる。一方、０系サーバ１は、通常モード（運転中）として動作し、「関東１」ノードＥＮ１のサービスを提供することができる。
【０１０８】
（Ａ−２−４）接続先サーバの決定処理
次に、各サーバが、ストレージ３に保持されるルーチン情報を参照して、ユーザ端末の電話番号から接続先とするサーバを決定する処理動作を説明する。図１４は、接続先サーバの決定処理を示すフローチャートである。
【０１０９】
（ａ）通常モードの場合
図１５及び図１６は、全拠点のノードが正常に動作する場合の様子を示す説明する。
【０１１０】
図１５に示すように、「関東１」ノードＥＮ１及び「関西１」ノードＷＮ１において、０系サーバ１と１系サーバ２のいずれか一方は「運転中」に設定され、他方は「待機中」に設定されており、両者は「通常モード」に設定されている。
【０１１１】
この場合に、例えば、電話番号「0622220001」のユーザ端末に接続するサーバを決定する場合の処理を例示する。
【０１１２】
まず、図１６に示すように、サーバの接続先決定部１５は、電話番号「0622220001」をキーとして、ストレージ３に保持されるルーチング情報を検索し、電話番号のプレフィックスが一致した行の論理ノード欄から論理ノード名「関西１」を取得する（ステップＳ２０１）。
【０１１３】
このとき、「関東１」ノードＥＮ１のサーバは「通常モード」であるから（ステップＳ２０２）、ステップＳ２０３に移行する。接続先決定部１５は、論理ノード名「関西１」をキーとして、サーバ情報の通常モードの欄の論理ＩＰ欄から、論理ノード名「関西１」の論理ＩＰアドレス「172.17.1.1」を取得する（ステップＳ２０３）。
【０１１４】
その結果、電話番号「0622220001」に対しては、論理ＩＰアドレス「172.17.1.1」が求まり、この論理ＩＰアドレスが設定されている「関西１」ノードＷＮ１の「運転中」である０系サーバに接続する。
【０１１５】
（ｂ）代替モードの場合
図１７は、関西拠点が災害に遭い、全ノードＷＮ１が使用不能となり、関東拠点のノードＥＮ１が代替モードとなっている場合の様子を示す説明図である。
【０１１６】
図１７に示すように、この場合、関東拠点の「関東１」ノードＥＮ１は「代替モード」の状態であり、０系サーバ１は「関東１」のサービスを提供し、１系サーバ２が「関西１」のサービスを提供している。
【０１１７】
この場合、電話番号「0622220001」のユーザ端末を接続するサーバを決定する場合を例示する。
【０１１８】
まず、図１８に示すように、各サーバの接続先決定部１５は、電話番号「0622220001」をキーとして、ストレージ３のルーチング情報を検索し、電話番号のプレフィックスが一致した行の論理ノード欄から論理ノード名「関西１」を取得する（ステップＳ２０１）。
【０１１９】
このとき、関東拠点のノードは代替モードであるから（ステップＳ２０２）、ステップＳ２０５に移行する。接続先決定部１５は、論理ノード名「関西１」をキーとして、サーバ情報の代替モードの欄の論理ＩＰ欄から、論理ノード名「関西１」の論理ＩＰアドレス「172.16.1.2」を取得する（ステップＳ２０５）。
【０１２０】
その結果、電話番号「0622220001」に対しては、論理ＩＰアドレス「172.16.1.2」が求まり、この論理ＩＰアドレスが設定されている「関東１」ノードＥＮ１の１系サーバに接続する。
【０１２１】
（Ａ−３）第１の実施形態の効果
上記のように、第１の実施形態によれば、拠点災害は発生していない場合、各ノードは０系サーバと１系サーバで２重化した構成となり、一方のサーバが「運転中」となり、他方のサーバが「待機中」となる。この時、「運転中」のサーバが改障しても「待機中」のサーバを「運転中」に変更することで、０系サーバと１系サーバの間でサービスを引継ぐことができる。また、その際のサービス中断時間は、サーバ切り替えに要する時間だけで済む。
【０１２２】
また、拠点災害が発した場合、被災拠点のノードの代わりに、代替関係にあるノードの「待機中」のサーバがサービスを引き継ぐことができる。また、その際のサービス中断時間は、サーバ切り替えに要する時間だけで済む。
【０１２３】
このように、故障に対する高可用性と、拠点災害に対する高可用性の両方を実現でき、かつ、予備拠点に予備サーバを設置するようなコストの追加が発生しない。
【０１２４】
その結果、従来のように予備拠点及び予備ノードを新たに設ける必要がなくなるので、従来よりもコストの改善ができる。また、サーバの切り替えだけの時間で済むので、サービス中断時間も短縮することができる。
【０１２５】
（Ｂ）第２の実施形態
次に、本発明の復旧システム、復旧方法、冗長制御装置及び冗長制御プログラムの第２の実施形態を図面を参照しながら説明する。
【０１２６】
第１の実施形態では、「待機中」サーバが、被災拠点のサーバの代わりに、サービスを提供する場合を説明した。
【０１２７】
しかし、この場合、代替モードのノードにおいては２重化を構成していない状態となる。従って、この状態でいずれかのサーバが故障となると、そのサーバが提供していたノードのサービスが提供できなくなる。
【０１２８】
そこで、第２の実施形態では、可用性のある第１の実施形態に対して、さらに拠点毎に予備サーバを設置して、さらに可用性を高めることができる。
【０１２９】
（Ｂ−１）第２の実施形態の全体構成
図１９は、第２の実施形態の復旧システム１０Ｂの構成を示す構成図である。図１９に示すように、第２の実施形態の復旧システム１０Ｂは、関東拠点及び関西拠点に、予備サーバ４及びストレージ５を新たに備える点である。
【０１３０】
予備サーバ４は、自身の拠点に設置されているノードの０系サーバ１又は１系サーバ２のいずれかが故障した場合に、そのノードが提供しているサービスを引き続き提供する予備的に設けられた代理サーバである。なお、予備サーバ４は、既存技術を利用して当該拠点のサーバの故障検出等をトリガとして動作する。
【０１３１】
また、予備サーバ４は、基本的には、０系サーバ１及び１系サーバ２と同じ構成を備えるが、冗長制御部１０２による冗長制御処理が０系サーバ１及び１系サーバ２と異なる。
【０１３２】
ここで、予備サーバ４による冗長制御処理の方法は、種々の方法を広く適用することができ、例えば後述する３つの方法を適用することができる。そこで、以下では、予備サーバ４による３つの方法例を説明する。
【０１３３】
なお、ストレージ５は、サービスデータを保持するものであるが、予備サーバ４の２重化方法の種別に応じて、どの範囲のサービスデータを保持するか変わってくる。そのため、以下では、ストレージ５に保持するサービスデータの範囲も含めて説明する。
【０１３４】
（Ｂ−２）第２の実施形態の詳細構成及び動作
（Ｂ−２−１）第１の冗長制御処理
第１の冗長制御処理は、予備サーバ４がストレージ５に、全拠点の全ノードＥＮ１〜ＥＮ３及びＷＮ１〜ＷＮ３のサービスデータをコピーして保持する方式である。
【０１３５】
図２０は、第１の冗長制御処理を説明する説明図である。この場合、図２０に示すノードＥＮ１は代替モードであり、０系ノード１は「関東１」のサービスを提供しており、１系ノード２は「関西１」のサービスを提供している。
【０１３６】
ストレージ５は、全ての拠点の全てのノードＥＮ１〜ＥＮ３及びＷＮ１〜ＷＮ３のサービスデータを保持するものである。ここで、サービスデータのコピーは、例えば、被災拠点の有無に関わらず定期的に実行しても良いし、被災拠点が発生した場合に限定して、定期的に実行しても良い。
【０１３７】
予備サーバ４は、サーバ情報を参照して、故障を起こしたサーバが提供しているノードの論理ノード名に基づいて、論理ＩＰアドレスを取得し、この論理ＩＰアドレスを自サーバに設定して、故障したサーバが提供していたノードのサービスを引き続き提供するものである。
【０１３８】
図２１は、予備サーバ４の冗長制御部１０２の機能構成を示すブロック図である。図２１に示すように、予備サーバ４の冗長制御部１０２は、論理ＩＰアドレス取得部４１１、論理ＩＰアドレス設定部４１２、サービスデータ取得部４１３を少なくとも有する。
【０１３９】
論理ＩＰアドレス取得部４１１は、故障したサーバが実行する論理ノード名をキーとして、サーバ情報から、通常モードの論理ノード欄から論理ＩＰアドレスと、代替ノードの論理ノード欄から論理ＩＰアドレスとを取得し、これらの論理ＩＰアドレスから自身の物理ＩＰアドレスと同一サブネットの論理ＩＰアドレスを選択するものである。
【０１４０】
論理ＩＰアドレス設定部４１２は、論理ＩＰアドレス取得部４１１により選択された論理ＩＰアドレスを自サーバに設定するものである。
【０１４１】
サービスデータ取得部４１３は、代理する論理ノード名をキーとして、ストレージ５からサービスデータを取得するものである。
【０１４２】
次に、第１の冗長制御処理の動作を、図面を参照しながら説明する。図２０（Ａ）に示すように、図２０（Ａ）の１系ノード２に故障が発生した場合に、１系ノード２が実行していた論理ノード名を指定して、故障サーバ（１系ノード２）から予備サーバ４に切り替える処理を例示する。
【０１４３】
図２２は、第１の冗長制御処理の動作を示すフローチャートである。また、図２３は、論理ＩＰアドレスの取得処理を示すフローチャートである。
【０１４４】
例えば、図２０（Ｂ）の１系ノード２は、「関西１」ノードＷＮ１に対応するサービスを提供しているから、１系ノード２が故障すると、「関西１」ノードＷＮ１のサービス提供ができなくなる。
【０１４５】
このため、予備サーバ４が代替する論理ノード名は「関西１」となる。予備サーバ４は論理ノード名「関西１」に対する論理ＩＰアドレスを取得する（ステップＳ３０１）。
【０１４６】
図２４（Ａ）に示すように、論理ＩＰアドレス取得部４１１は、論理ノード名「関西１」をキーとして、サーバ情報の通常モードの論理ノード欄を検索し、一致した行から通常モードの論理ＩＰアドレス「172.17.1.1」を取得する（ステップＳ４０１）。
【０１４７】
また、論理ＩＰアドレス取得部４１１は、論理ノード名「関西１」をキーとして、サーバ情報の代替モードの論理ノード欄を検索し、一致した行から代替モードの論理ＩＰアドレス「172.16.1.2」を取得する（ステップＳ４０２）。
【０１４８】
次に、論理ＩＰアドレス取得部４１１は、ステップＳ４０１及びＳ４０２で取得した論理ＩＰアドレスのうち、予備サーバ４の物理ＩＰアドレス「172.16.4.10」と同一サブネットの論理ＩＰアドレス「172.16.1.2」を選択する（ステップＳ４０３）。
【０１４９】
その結果、図２４（Ｂ）に示すように、予備サーバ４は、論理ＩＰアドレス設定部４１２が論理ＩＰアドレス「172.16.1.2」を設定し（ステップＳ３０２）、サービスデータ取得部４１３がストレージ５内の論理ノード名「関西１」のサービスデータを参照してサービスを提供する（ステップＳ３０３）。
【０１５０】
第１の冗長制御処理によれば、予備サーバ５のストレージサイズが全拠点全ノード分だけ必要となるが、サービス中断時間はサーバ切り替えの時間だけで済むので、サービス中断時間を短くできる。
【０１５１】
（Ｂ−２−２）第２の冗長制御処理
第２の冗長制御処理は、予備サーバ４のストレージ５に、サービスデータをコピーして保存しておかない方式である。
【０１５２】
図２５（Ａ）は、第２の冗長制御処理を説明する説明図である。この場合、図２５（Ａ）に示すノードＥＮ１は代替モードであり、０系ノード１は「関東１」のサービスを提供しており、１系ノード２は「関西１」のサービスを提供している。
【０１５３】
ストレージ５は、サービスデータを保存しておらず、予備サーバ４がサービスを代替する論理ノードが決まった後に、その代替するノードのサービスデータをコピーして保存する。
【０１５４】
予備サーバ４は、サーバ情報を参照して、故障を起こしたサーバが提供しているノードの論理ノード名に基づいて、論理ＩＰアドレスを取得し、この論理ＩＰアドレスを自サーバに設定して、故障したサーバが提供していたノードのサービスを引き続き提供するものである。
【０１５５】
また、予備サーバ４は、サーバ情報を参照して、故障したノードの物理ＩＰアドレスを検索し、その検索したノードから、サービスを継続するノードのサービスデータをストレージ５にコピーするものである。
【０１５６】
図２６は、予備サーバ４の冗長制御部１０２の機能構成を示すブロック図である。図２６に示すように、予備サーバ４の冗長制御部１０２は、論理ＩＰアドレス取得部４２１、論理ＩＰアドレス設定部４２２、物理ＩＰアドレス取得部４２３、サービスデータコピー部４２４、サービスデータ取得部４２５を少なくとも有する。
【０１５７】
なお、論理ＩＰアドレス取得部４２１、論理ＩＰアドレス設定部４２２及びサービスデータ取得部４２５は、論理ＩＰアドレス取得部４１１、論理ＩＰアドレス設定部４１２及びサービスデータ取得部４１３と同じ処理を行うものである。
【０１５８】
物理ＩＰアドレス取得部４２３は、論理ＩＰアドレス取得部４２１が選択した論理ＩＰアドレスをキーとして、サーバ情報の通常モードと代替モードの論理ノード欄を検索し、一致した行の物理ＩＰ欄から物理ＩＰアドレスを取得するものである。この物理ＩＰアドレスは、代替ノードのサービスデータをストレージ３に保持しているノードのサーバの物理ＩＰアドレスである。
【０１５９】
サービスデータコピー部４２４は、物理ＩＰアドレス取得部４２３により取得された物理ＩＰアドレスを用いて、代替するノード名のサービスデータをストレージ５にコピーするものである。
【０１６０】
次に、第２の冗長制御処理の動作を、図面を参照しながら説明する。図２５（Ｂ）に示すように、図２５（Ａ）の１系ノード２に故障が発生した場合に、１系ノード２が実行していた論理ノード名を指定して、故障サーバ（１系ノード２）から予備サーバ４に切り替える処理を例示する。
【０１６１】
図２７は、第２の冗長制御処理の動作を示すフローチャートである。
【０１６２】
例えば、図２５（Ｂ）の１系ノード２は、「関西１」ノードＷＮ１に対応するサービスを提供しているから、１系ノード２が故障すると、「関西１」ノードＷＮ１のサービス提供ができなくなる。
【０１６３】
このため、予備サーバ４が代替する論理ノード名は「関西１」となる。予備サーバ４は、図２３のフローチャートで説明した方法により、論理ノード名「関西１」に対する論理ＩＰアドレスを取得する（ステップＳ５０１）。
【０１６４】
図２８に示すように、論理ＩＰアドレス取得部４２１が、論理ノード名「関西１」の論理ＩＰアドレス「172.16.1.2」を選択する（ステップＳ４０１〜Ｓ４０３）。
【０１６５】
次に、物理ＩＰアドレス取得部４２３は、論理ＩＰアドレス「172.16.1.2」をキーとして、サーバ情報の通常モードと代替モードの論理ＩＰ欄を検索し、一致した行の物理ＩＰ欄から２つの物理ＩＰアドレス「172.16.1.10」と「172.16.1.11」を取得する（ステップＳ５０２）。
【０１６６】
そして、サービスデータコピー部４２４が、図２９に示すように、２つの物理ＩＰアドレス「172.16.1.10」と「172.16.1.11」のサーバに接続し、応答のあったサーバかに論理ノード名「関西１」を通知し、当該サーバから論理ノード名「関西１」に対応するサービスデータを取得し、ストレージ５に保持する（ステップＳ５０３）。
【０１６７】
その結果、図２９に示すように、予備サーバ４は、論理ＩＰアドレス設定部４２２が論理ＩＰアドレス「172.16.1.2」を設定し（ステップＳ５０４）、サービスデータ取得部４２５がストレージ５内の論理ノード名「関西１」のサービスデータを参照してサービスを提供する（ステップＳ５０５）。
【０１６８】
第２の冗長制御処理によれば、予備サーバ４のストレージサイズが１ノード分だけで済むが、切り替え時にサービスデータをコピーするための時間だけ、サービスの中断時間が長くなる。
【０１６９】
（Ｂ−２−３）第３の冗長制御処理
第３の冗長制御処理は、予備サーバのストレージに、予備サーバ４と同一拠点のノードの分のサービスデータだけをコピーしておく方式である。
【０１７０】
ストレージ５は、同一拠点の各ノードのストレージ３が保持するサービスデータを保持するものである。このサービスデータのコピーは、例えば、被災拠点の有無に関わらず定期的に実行しても良いし、又例えば被災拠点が発生した場合に限定して、定期的に実行しても良い。
【０１７１】
予備サーバ４は、サーバ情報を参照して、故障を起こしたサーバが提供しているノードの論理ノード名に基づいて、論理ＩＰアドレスを取得し、さらにその論理ＩＰアドレスをキーとして、故障を起こしたサーバと同一ノードの他サーバの論理ＩＰアドレスを取得するものである。
【０１７２】
また、予備サーバ４は、故障を起こしたサーバと同一ノードの他サーバに対して、故障を起こしたサーバが提供していたサービスを提供するように、状態変更を指示すると共に、自身が上記他サーバが提供していたサービスの提供を行うようにするものである。
【０１７３】
図３１は、予備サーバ４の冗長制御部１０２の機能構成を示すブロック図である。図３１に示すように、予備サーバ４の冗長制御部１０２は、論理ＩＰアドレス取得部４３１、論理ＩＰアドレス設定部４３２、サービスデータ確認部４３３、状態変更指示部４３４、サービスデータ取得部４３５を少なくとも有する。
【０１７４】
なお、論理ＩＰアドレス取得部４３１、論理ＩＰアドレス設定部４３２及びサービスデータ取得部４３５は、論理ＩＰアドレス取得部４１１、論理ＩＰアドレス設定部４１２及びサービスデータ取得部４１３と同じ処理を行うものである。
【０１７５】
サービスデータ確認部４３３は、代替する論理ノード名のサービスデータがストレージ５にあるか否かを確認するものである。
【０１７６】
状態変更指示部４３４は、サービスデータ確認部４３３により代替する論理ノード名のサービスデータがストレージ５にない場合、論理ＩＰアドレス取得部４３１が取得した論理ＩＰアドレスのサーバに対して、状態を「運用中」から「待機中」に変更指示するものである。
【０１７７】
次に、第３の冗長制御処理の動作を、図面を参照しながら説明する。図３０（Ｂ）に示すように、図３０（Ａ）の１系ノード２に故障が発生した場合に、１系ノード２が実行していた論理ノード名を指定して、故障サーバ（１系ノード２）から予備サーバ４に切り替える処理を例示する。
【０１７８】
図３２は、第３の冗長制御処理の動作を示すフローチャートである。
【０１７９】
例えば、図３０（Ｂ）の１系ノード２は、「関西１」ノードＷＮ１に対応するサービスを提供しているから、１系ノード２が故障すると、「関西１」ノードＷＮ１のサービス提供ができなくなる。
【０１８０】
このため、予備サーバ４が代替する論理ノード名は「関西１」となる。予備サーバ４は、図２３のフローチャートで説明した方法により、論理ノード名「関西１」に対する論理ＩＰアドレスを取得する（ステップＳ６０１）。
【０１８１】
図３３及び図３４に示すように、論理ＩＰアドレス取得部４３１が、論理ノード名「関西１」の論理ＩＰアドレス「172.16.1.2」を選択する（ステップＳ４０１〜Ｓ４０３）。
【０１８２】
次に、サービスデータ確認部４３３は当該論理ノード名のサービスデータがストレージ５にあるか否かを確認する（ステップＳ６０２）。そして、ストレージ５にサービスデータがある場合、論理ＩＰアドレス設定部４３２は、その論理ＩＰアドレスを自サーバに設定して（ステップＳ６０４）、サービスデータ取得部４３５がサービスデータを参照しながらサービスを提供する（ステップＳ６０５）。
【０１８３】
一方、上記の例のように、サービスデータがストレージ５にない場合には、次のような処理を行う。
【０１８４】
論理ＩＰアドレス取得部４３１は、論理ＩＰアドレス「172.16.1.2」をキーとして、サーバ情報の代替モードの論理ノード欄を検索し、一致した行の通常ノード欄から論理ノード名及び論理ＩＰアドレス「172.16.1.1」を取得する（ステップＳ６０６）。
【０１８５】
状態変更指示部４３４は、ステップＳ６０６で求めた論理ＩＰアドレス「172.16.1.1」のサーバ（０系サーバ１）に接続し、そのサーバを「運転中」から「待機中」に変更指示を行う（ステップＳ６０７）。
【０１８６】
これにより、当該サーバ（０系サーバ１）は、第１の実施形態で説明した図１０に示すような処理を行い、論理ＩＰアドレス「172.16.1.2」を自サーバ（０系サーバ１）設定し、代替する論理ノード名「関西１」をキーとして、ストレージ内の関西１データを参照してサービスを提供する。
【０１８７】
また、予備サーバ４は、論理ＩＰアドレス設定部４３２が論理ＩＰアドレス「172.16.1.1」を設定し（ステップＳ６０８）、サービスデータ取得部４３５が論理ノード名「関東１」をキーとして、ストレージ５内の関東１のサービスデータを参照してサービスを提供する（ステップＳ６０９）。
【０１８８】
第３の冗長制御処理によれば、予備サーバ４のストレージサイズが拠点内の全ノード分だけで済むが、サーバ切り替えが２回発生する場合がある。
【０１８９】
（Ｂ−３）第２の実施形態の効果
上記のように、第２の実施形態によれば、拠点災害が発して、ある拠点の待機状態のサーバが被災拠点のサーバの代わりにサービスを提供している状態において、いずれかのサーバ故障が発生した場合、各拠点に設置された予備サーバに切り替えてサービスを提供することができる。
【０１９０】
（Ｃ）他の実施形態
上述した第１及び第２の実施形態では、ＩＰ電話の接続を制御するサーバに適用した場合を例として説明したが、その他のＩＰネットワークサーバにも適用可能である。
【０１９１】
上述した第１及び第２の実施形態では、関東と関西の２拠点の場合を例として説明したが、２拠点以上の複数拠点で運用する場合にも適用可能である。
【０１９２】
上述した第１及び第２の実施形態では、サービスデータの格納先として、ノード毎に０系サーバと１系サーバで共有するストレージを利用する形態で説明したが、拠点内の全ノードで共有する別サーバ（ファイルサーバやＤＢサーバ）を利用した場合にも適用可能である。
【符号の説明】
【０１９３】
１…０系サーバ、２…１系サーバ、３…ストレージ、４…予備サーバ、５…ストレージ、１０Ａ及び１０Ｂ…復旧システム、１０１…アプリケーション、１０２…冗長制御部、
１０３…ＯＳ、１０４…ハードディスク、
１１…動作モード認識部、１２…通常モード（運転中）制御部、
１３…通常モード（待機中）制御部、１４…代替モード制御部、１５…接続先決定部、
１２１…サーバ情報検索部、１２２…論理ＩＰアドレス設定部、
１２３…サービスデータ取得部、１４１…サーバ情報検索部、
４１１、４２１、４３１…論理ＩＰアドレス取得部、
１４２、４１２、４２２、４３２…論理ＩＰアドレス設定部、
１４３、４１３、４２５、４３５…サービスデータ取得部、
４２３…物理ＩＰアドレス取得部、４２４…サービスコピー部、
４３３…サービスデータ確認部、４３４…状態変更指示部。
【特許請求の範囲】
【請求項１】
各拠点に、サービス提供を実行する第１サーバと待機する第２サーバと上記サービス提供に必要なサービスデータを保存するデータ保存手段とを有して、サービスの提供を行う１又は複数のノードを備え、
上記各ノードは、他の拠点に設置された他ノードとの間で代替関係が設定されており、
上記データ保存手段は、自ノードが提供するサービスのサービスデータと、他の拠点の上記代替関係にある他ノードが提供するサービスのサービスデータとを保存するものであり、
上記第２サーバが、上記第１サーバの障害又は上記他拠点の代替関係にある他ノードの障害発生時に、上記データ保存手段から必要な上記サービスデータを取得して、障害の生じたサービスの提供を実行することを特徴とする復旧システム。
【請求項２】
上記第２サーバは、
自ノードが通常時にサービスを提供する通常モード時の論理ノード情報と、他拠点の代替関係にあるノードのサービスを提供する代替モード時の論理ノード情報とを上記ノード毎に予め設定したサーバ情報を格納するサーバ情報格納手段と、
障害発生時に、自身の動作状態に応じて上記サーバ情報から上記論理ノード情報を検索し、検索した上記論理ノード情報に対応する上記サービスデータを上記データ保存手段から取得して冗長制御を行う冗長制御手段と
を備えることを特徴とする請求項１に記載の復旧システム。
【請求項３】
上記各拠点に、当該拠点の上記各ノードのいずれかのサーバに障害が生じたときに、その障害サーバのサービス提供を実行する予備サーバ及び予備データ保存手段をさらに備え、
上記予備サーバが、上記障害サーバのサービス提供に係る上記サービスデータを上記予備データ保存手段から取得して、上記障害サーバのサービス提供を実行することを特徴とする請求項１又は２に記載の復旧システム。
【請求項４】
上記予備データ保存手段が、全拠点の全ノードのサービスデータを保存するものであり、
上記予備サーバは、上記障害サーバの上記論理ノード情報に対応する上記サービスデータを上記予備データ保存手段から取得してサービス提供を行う
ことを特徴とする請求項３に記載の復旧システム。
【請求項５】
上記予備サーバが、上記障害サーバの上記論理ノード情報に基づいて、上記サーバ情報から上記障害サーバの属する上記ノードを検索し、この検索した上記ノードから上記障害サーバのサービス提供に係る上記サービスデータを上記予備データ保存手段に複製してサービス提供を行うことを特徴とする請求項３に記載の復旧システム。
【請求項６】
上記予備データ保存手段が、自身と同一拠点に設置された全ノードのサービスデータを保存するものであり、
上記予備サーバが、
上記予備データ保存手段に、上記障害サーバの上記論理ノード情報に対応する上記サービスデータの有無を確認するサービスデータ確認部と、
上記サービスデータがある場合には、上記予備データ保存手段から上記サービスデータを取得してサービス提供する第１のサービスデータ取得部と、
上記サービスデータがない場合には、上記障害サーバと冗長構成をとるサーバに対して動作状態の変更指示を行う状態変更指示部と、
上記障害サーバと冗長構成をとるサーバがサービス提供していた上記論理ノード情報の上記サービスデータを上記予備データ保存手段から取得してサービス提供を行う第２のサービスデータ取得部と
を有することを特徴とする請求項３に記載の復旧システム。
【請求項７】
各拠点に、サービス提供を実行する第１サーバと待機する第２サーバと上記サービス提供に必要なサービスデータを保存するデータ保存手段とを有して、サービスの提供を行う１又は複数のノードを備え、
上記各ノードは、他の拠点に設置された他ノードとの間で代替関係を設定し、
上記データ保存手段は、自ノードが提供するサービスのサービスデータと、他の拠点の上記代替関係にある他ノードが提供するサービスのサービスデータとを保存し、
上記第２サーバが、上記第１サーバの障害又は上記他拠点の代替関係にある他ノードの障害発生時に、上記データ保存手段から必要な上記サービスデータを取得して、障害の生じたサービスの提供を実行する
ことを特徴とする復旧方法。
【請求項８】
所定のサービスを提供する同一ノードにおける他のサーバ、又は、予め設定された他の拠点の代替関係が設定された他のサーバとの間で冗長構成をとるサーバの冗長制御装置であって、
自ノードが提供するサービスのサービスデータと、他の拠点の上記代替関係にある他ノードが提供するサービスのサービスデータとを保存するデータ保存手段と、
自ノードが通常時にサービスを提供する通常モード時の論理ノード情報と、他拠点の代替関係にあるノードのサービスを提供する代替モード時の論理ノード情報とを上記ノード毎に予め設定したサーバ情報を格納するサーバ情報格納手段と、
自身の動作状態を認識する動作状態認識手段と、
上記動作状態認識手段により認識された自身の動作状態に応じて、上記サーバ情報から上記論理ノード情報を検索し、検索した上記論理ノード情報に対応する上記サービスデータを上記データ保存手段から取得して冗長制御を行う冗長制御手段と
を備えることを特徴とする冗長制御装置。
【請求項９】
所定のサービスを提供する同一ノードにおける他のサーバ、又は、予め設定された他の拠点の代替関係が設定された他のサーバとの間で冗長構成をとるサーバの冗長制御プログラムであって、
自ノードが提供するサービスのサービスデータと、他の拠点の上記代替関係にある他ノードが提供するサービスのサービスデータとを保存するデータ保存手段と、
自ノードが通常時にサービスを提供する通常モード時の論理ノード情報と、他拠点の代替関係にあるノードのサービスを提供する代替モード時の論理ノード情報とを上記ノード毎に予め設定したサーバ情報を格納するサーバ情報格納手段と
を備える冗長制御装置を、
自身の動作状態を認識する動作状態認識手段、
上記動作状態認識手段により認識された自身の動作状態に応じて、上記サーバ情報から上記論理ノード情報を検索し、検索した上記論理ノード情報に対応する上記サービスデータを上記データ保存手段から取得して冗長制御を行う冗長制御手段
として機能させることを特徴とする冗長制御プログラム。
【請求項１】
各拠点に、サービス提供を実行する第１サーバと待機する第２サーバと上記サービス提供に必要なサービスデータを保存するデータ保存手段とを有して、サービスの提供を行う１又は複数のノードを備え、
上記各ノードは、他の拠点に設置された他ノードとの間で代替関係が設定されており、
上記データ保存手段は、自ノードが提供するサービスのサービスデータと、他の拠点の上記代替関係にある他ノードが提供するサービスのサービスデータとを保存するものであり、
上記第２サーバが、上記第１サーバの障害又は上記他拠点の代替関係にある他ノードの障害発生時に、上記データ保存手段から必要な上記サービスデータを取得して、障害の生じたサービスの提供を実行することを特徴とする復旧システム。
【請求項２】
上記第２サーバは、
自ノードが通常時にサービスを提供する通常モード時の論理ノード情報と、他拠点の代替関係にあるノードのサービスを提供する代替モード時の論理ノード情報とを上記ノード毎に予め設定したサーバ情報を格納するサーバ情報格納手段と、
障害発生時に、自身の動作状態に応じて上記サーバ情報から上記論理ノード情報を検索し、検索した上記論理ノード情報に対応する上記サービスデータを上記データ保存手段から取得して冗長制御を行う冗長制御手段と
を備えることを特徴とする請求項１に記載の復旧システム。
【請求項３】
上記各拠点に、当該拠点の上記各ノードのいずれかのサーバに障害が生じたときに、その障害サーバのサービス提供を実行する予備サーバ及び予備データ保存手段をさらに備え、
上記予備サーバが、上記障害サーバのサービス提供に係る上記サービスデータを上記予備データ保存手段から取得して、上記障害サーバのサービス提供を実行することを特徴とする請求項１又は２に記載の復旧システム。
【請求項４】
上記予備データ保存手段が、全拠点の全ノードのサービスデータを保存するものであり、
上記予備サーバは、上記障害サーバの上記論理ノード情報に対応する上記サービスデータを上記予備データ保存手段から取得してサービス提供を行う
ことを特徴とする請求項３に記載の復旧システム。
【請求項５】
上記予備サーバが、上記障害サーバの上記論理ノード情報に基づいて、上記サーバ情報から上記障害サーバの属する上記ノードを検索し、この検索した上記ノードから上記障害サーバのサービス提供に係る上記サービスデータを上記予備データ保存手段に複製してサービス提供を行うことを特徴とする請求項３に記載の復旧システム。
【請求項６】
上記予備データ保存手段が、自身と同一拠点に設置された全ノードのサービスデータを保存するものであり、
上記予備サーバが、
上記予備データ保存手段に、上記障害サーバの上記論理ノード情報に対応する上記サービスデータの有無を確認するサービスデータ確認部と、
上記サービスデータがある場合には、上記予備データ保存手段から上記サービスデータを取得してサービス提供する第１のサービスデータ取得部と、
上記サービスデータがない場合には、上記障害サーバと冗長構成をとるサーバに対して動作状態の変更指示を行う状態変更指示部と、
上記障害サーバと冗長構成をとるサーバがサービス提供していた上記論理ノード情報の上記サービスデータを上記予備データ保存手段から取得してサービス提供を行う第２のサービスデータ取得部と
を有することを特徴とする請求項３に記載の復旧システム。
【請求項７】
各拠点に、サービス提供を実行する第１サーバと待機する第２サーバと上記サービス提供に必要なサービスデータを保存するデータ保存手段とを有して、サービスの提供を行う１又は複数のノードを備え、
上記各ノードは、他の拠点に設置された他ノードとの間で代替関係を設定し、
上記データ保存手段は、自ノードが提供するサービスのサービスデータと、他の拠点の上記代替関係にある他ノードが提供するサービスのサービスデータとを保存し、
上記第２サーバが、上記第１サーバの障害又は上記他拠点の代替関係にある他ノードの障害発生時に、上記データ保存手段から必要な上記サービスデータを取得して、障害の生じたサービスの提供を実行する
ことを特徴とする復旧方法。
【請求項８】
所定のサービスを提供する同一ノードにおける他のサーバ、又は、予め設定された他の拠点の代替関係が設定された他のサーバとの間で冗長構成をとるサーバの冗長制御装置であって、
自ノードが提供するサービスのサービスデータと、他の拠点の上記代替関係にある他ノードが提供するサービスのサービスデータとを保存するデータ保存手段と、
自ノードが通常時にサービスを提供する通常モード時の論理ノード情報と、他拠点の代替関係にあるノードのサービスを提供する代替モード時の論理ノード情報とを上記ノード毎に予め設定したサーバ情報を格納するサーバ情報格納手段と、
自身の動作状態を認識する動作状態認識手段と、
上記動作状態認識手段により認識された自身の動作状態に応じて、上記サーバ情報から上記論理ノード情報を検索し、検索した上記論理ノード情報に対応する上記サービスデータを上記データ保存手段から取得して冗長制御を行う冗長制御手段と
を備えることを特徴とする冗長制御装置。
【請求項９】
所定のサービスを提供する同一ノードにおける他のサーバ、又は、予め設定された他の拠点の代替関係が設定された他のサーバとの間で冗長構成をとるサーバの冗長制御プログラムであって、
自ノードが提供するサービスのサービスデータと、他の拠点の上記代替関係にある他ノードが提供するサービスのサービスデータとを保存するデータ保存手段と、
自ノードが通常時にサービスを提供する通常モード時の論理ノード情報と、他拠点の代替関係にあるノードのサービスを提供する代替モード時の論理ノード情報とを上記ノード毎に予め設定したサーバ情報を格納するサーバ情報格納手段と
を備える冗長制御装置を、
自身の動作状態を認識する動作状態認識手段、
上記動作状態認識手段により認識された自身の動作状態に応じて、上記サーバ情報から上記論理ノード情報を検索し、検索した上記論理ノード情報に対応する上記サービスデータを上記データ保存手段から取得して冗長制御を行う冗長制御手段
として機能させることを特徴とする冗長制御プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【公開番号】特開２０１１−６１６２６（Ｐ２０１１−６１６２６Ａ）
【公開日】平成２３年３月２４日（２０１１．３．２４）
【国際特許分類】
【出願番号】特願２００９−２１０９２４（Ｐ２００９−２１０９２４）
【出願日】平成２１年９月１１日（２００９．９．１１）
【出願人】（３０８０３３７２２）株式会社ＯＫＩネットワークス (165)
【出願人】（５９１０５１６４５）株式会社ＯＫＩソフトウェア (173)
【Ｆターム（参考）】
【公開日】平成２３年３月２４日（２０１１．３．２４）
【国際特許分類】
【出願日】平成２１年９月１１日（２００９．９．１１）
【出願人】（３０８０３３７２２）株式会社ＯＫＩネットワークス (165)
【出願人】（５９１０５１６４５）株式会社ＯＫＩソフトウェア (173)
【Ｆターム（参考）】
[ Back to top ]