JP2013037433A - サーバ、サーバシステムおよびサーバの冗長切り替え方法 - Google Patents

Abstract

【課題】１つ以上の現用系物理サーバと待機系物理サーバとを含むサーバシステムの障害発生時に早期に回復が可能な制御サーバを提供する。
【解決手段】制御サーバ３００は、データの生成、削除、参照を伴うアプリケーションが運用されるＯＳ２００、２１０、２２０が稼働する複数の現用系サーバの運用状態を監視する手段と、前記現用系物理サーバのＯＳ２００、２１０、２２０と、ホストＯＳ２４０上で前記現用系サーバのＯＳに対応するゲストＯＳ２４２、２４４、２４６が稼働する待機系サーバとのデータを同期する手段と、前記監視する手段が前記現用系物理サーバの一つの運用状態の障害を検出したとき、対応する前記ゲストＯＳ２４２、２４４、２４６の上で、前記現用系物理サーバの一つで運用されていたアプリケーションを起動し、障害が検出された現用系サーバから待機系サーバの対応するゲストＯＳ２４２、２４４、２４６に系を切り替える手段と、を含む。
【選択図】図３

Description

本発明は、冗長構成を備える複数のサーバからなるサーバシステム、およびサーバの冗長切り替え方法に関する。

近年、セキュリティゲートウェイ、ロードバランサ、ネットワーク機器運用制御装置などの装置は、サーバを複数組み合わせた形で構成されている。サーバを複数組み合わせた形で構成される装置に対しては、サービスの持続性などの高信頼性が要求される。今日の企業活動は計算機に依存する面が大きく、計算機システムの停止による損害が大きくなったことが、高信頼性への要求を高める背景の一つである。特に、インターネットの普及や映像サービスなど新しいサービスの台頭によってインターネットトラフィックが急増しており、装置には、高速処理して多様なサービスに対応する通信システムをスピーディーかつ経済的に構築、運用することが要求されている。

これらの装置のうち、データーセンタ、キャリアといったスムースなサービスが必要とされるところに設置される装置、特にサーバシステムは、実際に運用される現用系のほかに予備の装置、サーバを備える冗長化構成が採用され、保守作業や障害発生時に通信の中断時間を減らすようにしている場合もある。サーバシステムに対しては、このような冗長化の一つとして、Ｎ個の現用系サーバとは別に１個の待機系サーバを用意するＮ＋１冗長構成がある。Ｎ＋１冗長構成を採用することによって、サーバシステムの信頼性、特に可用性を上げることができる。

たとえば、一つの筐体内に複数のＣＰＵブレードが収容されたブレードシステムであって、各ＣＰＵブレード上では仮想計算機方式によって実現されたＶＭシステムが稼動するブレードシステムにおいて、予め決められたサーバを予備として待機させ、負荷の平準化や障害によるシステムダウンを回避するシステムが知られている。このようなシステムでは、障害等の発生時に、現用系サーバから予備サーバに仮想システムをマイグレーションすることによって、スムースなシステム運用を実現することができる。

また、あるＣＰＵブレード上で動作するシステム、たとえば仮想システムを別のＣＰＵブレードにマイグレーションする必要が生じたときに、マイグレーション先のＣＰＵブレードを予め決められた一つに限定せず、ブレードの特徴やファンや電源などの動作環境、障害発生状況等などを考慮して、最適のブレードシステムを選択するシステムも知られている（たとえば、特許文献１）。このようなシステムでは、予備のブレードを予め用意する必要がない。さらに、各ＣＰＵブレードについてのシステム運用環境を数値化しておき、障害発生時には同等以上のＣＰＵブレードを移動先として選択するように構成することによって、障害発生から移行完了までに要する時間を短縮することができる。

また、仮想計算機方式によって実現された複数の仮想計算機が動作可能な複数の物理サーバからなる現用系サーバと、仮想計算機が動作する単一の待機系サーバとを備え、現用系サーバのうち物理サーバに障害が発生したときに、その物理サーバで稼動していたＯＳを待機系の仮想サーバとして起動し、仮想計算機が動作している物理サーバに障害が発生したときには、その仮想計算機の仮想化ＯＳを待機系の仮想サーバとして起動するシステムが知られている（たとえば、特許文献２）。このシステムにおける障害回復処理では、現用系サーバのいずれかに障害イベントが発生すると、障害発生サーバが使用していた起動ディスクを待機系サーバに割り当て、待機系サーバの電源をＯＮにする。

また、１台の物理サーバ内に複数のＶＭシステムがサーバとして稼動し、そのうちの一つのブレードが現用系として、別の一つのブレードが待機系として二重化運転している仮想サーバ環境での系の切り替えに際して、同一の物理サーバ上の他の仮想サーバに影響を及ぼさないファイル更新方法が知られている（たとえば、特許文献３）。

特開２００８−２７６３２０号公報 特開２０１０−２１１８１９号公報 特開２０１０−３０２２号公報

一般に、物理サーバ上に複数の仮想サーバを構築した際には、物理サーバに障害が発生するとその上で稼動している全ての仮想サーバが停止してしまい、システムの高信頼性を得ることは難しいという問題があった。一方、独立した複数のサーバでサーバシステムが構築されていれば、単一の物理サーバの障害によってシステム全体が停止することはないが、コストが掛かるという問題があった。

また、現用系サーバとして物理サーバ上に仮想サーバを用いる場合には、ゲストＯＳのＩ／Ｏ操作を並行して行うため、オーバーヘッドが存在するという問題があった。
また、現用系と待機系の二重化構成を取る一組の物理サーバにおいて、正常運転時に待機系をコールドスタンバイ状態で運用していれば、障害が発生した後に待機系にコンフィグ情報を転送してから通信用のアプリケーションを起動することになるため長時間の通信断、サービスの中断を発生させていた。また、障害発生から待機系の運用開始まで時間が掛かるという問題があった。

さらに、従来のＮ＋１冗長化の方法では障害発生時にコールドスタンバイを実施するか、各アプリケーションレベルでＮ＋１冗長構成に対応させる必要があったが、多様化するアプリケーション群にホットスタンバイな二重化対応の実装はあってもＮ＋１重化ホットスタンバイ対応の実装をさせるには開発コストが膨大になるという難点があった。

また、待機系がＮ個の現用系に対応するような方法も考えられるが、多様化する通信アプリケーションにＮ＋１重化対応の冗長構成を意識させたコードを実装することはコスト的に実装が困難である上に待機系での信頼性も低下させていた。

したがって、複数のサーバより構成されるサーバシステムにおけるＮ＋１冗長構成において、ＣＰＵ性能やＩ／Ｏ性能を犠牲にせず、かつコストを抑えて冗長化された信頼性の高いコンピューターシステムが要求されている。

また、信頼性の向上のため、一つの筐体内の複数のサーバより構成されるＮ＋１冗長構成を備えるサーバシステムにおける、系の切替方法、特に障害発生時の回復方法が要求されている。

本発明は上記のような問題に鑑み、複数のＣＰＵブレードを有するブレードサーバや複数のシングルボードコンピュータ（ＳＢＣ）やパケットプロセッシングボード（ＰＰＢ）を有するアドバンストＴＣＡ（ｔｅｌｅｃｏｍ ｃｏｍｐｕｔｉｎｇ ａｒｃｈｉｔｅｃｔｕｒｅ）サーバからなるＮ＋１冗長構成を有するサーバシステムを制御する制御サーバであって、サーバシステムのＣＰＵ性能やＩ／Ｏ性能を犠牲にせずに、しかもコストアドヴァンテージを有し、さらに高可用性を有する制御サーバおよび障害回復制御方法、ならびにそのような制御サーバを含むサーバシステムおよび障害回復方法を提供することを目的とする。

本発明に従う制御サーバは、データの生成、削除、参照を伴って運用されるアプリケーションが運用される１つ以上の現用系物理サーバの運用状態を監視する監視手段と、前記現用系物理サーバと、前記現用系物理サーバの数と同じ数の仮想サーバを含む待機系物理サーバ上の前記現用系物理サーバに対応する前記仮想サーバの一つとの間で前記データの同期を行う同期手段と、前記監視手段が前記現用系物理サーバの一つの運用状態に障害が生じたことを見つけたときに、前記現用系物理サーバの一つに対応する前記仮想サーバの一つの上で、前記現用系物理サーバの一つで運用されていた前記アプリケーションを起動し、前記同期手段によって前記現用系物理サーバ上の前記データと同期していた前記仮想サーバの一つの上の前記データの一つを参照しつつ、前記アプリケーションを運用し、さらに、前記仮想サーバの一つから前記待機系物理サーバに系の切り替えを行う切替手段と、を含むことを特徴とする。

待機系物理サーバ上の仮想サーバで現用系物理サーバのＯＳが稼動するサーバシステムにおいて、現用系とそれに対応する待機系のデータを互いに同期させることによって、コストを抑えつつも、ＣＰＵ性能やＩ／Ｏ性能を犠牲にせず、障害発生時に早期に回復が可能な、高可用性を有する信頼性が高いサーバシステムを制御する制御サーバおよびそのような制御サーバによる障害回復制御方法を提供することができる。

網間ゲートウェイサーバおよびネットワーク機器運用制御サーバが用いられるネットワークシステムを示す図である。 冗長構成を用いるサーバシステムにおける障害回復処理の比較例を示す概略図である。 冗長構成を用いるサーバシステムを示す概略図である。 現用系サーバと待機系サーバで同期処理される経路情報のエントリに関するデータの例である。 現用系サーバと待機系サーバで同期処理されるＡＲＰキャッシュのエントリに関するデータの例である。 現用系サーバと待機系サーバで同期処理されるネイバーキャッシュのエントリに関するデータの例である。 現用系サーバと待機系サーバで同期処理されるセッション、コネクション（ＩＰｖ４）のエントリに関するデータの例である。 現用系サーバと待機系サーバで同期処理されるセッション、コネクション（ＩＰｖ６）のエントリに関するデータの例である。 現用系サーバと待機系サーバで同期処理されるアドレスマッピング情報（ＩＰｖ４）のエントリに関するデータの例である。 現用系サーバと待機系サーバで同期処理されるアドレスマッピング情報（ＩＰｖ６）のエントリに関するデータの例である。 冗長構成を用いるサーバシステムにおける障害回復処理を示す概略図（その１）である。 冗長構成を用いるサーバシステムにおける障害回復処理を示す概略図（その２）である。 冗長構成を用いるサーバシステムにおける障害回復処理を示す概略図（その３）である。 冗長構成を用いるサーバシステムにおける障害回復処理を示す概略図（その４）である。 冗長構成を用いるサーバシステムの全体図である。 冗長構成を用いるサーバシステムのブロック図である。 冗長構成を用いるサーバシステムの構成図である。 冗長構成を用いる別のサーバシステムの構成図である。 冗長構成を用いるさらに別のサーバシステムの構成図である。 冗長構成を用いるサーバシステムにおける障害回復処理のフローチャートである。 冗長構成を用いるサーバシステムにおける障害回復処理のシーケンス図である。 冗長構成を用いるサーバシステムの障害切替直後におけるシステム全体図である。 図１９に示されている障害切替直後における冗長構成を用いるサーバシステムのブロック図である。 冗長構成を用いるサーバシステムのホストＯＳ引き継ぎ後におけるシステム全体図である。 図２１に示されているホストＯＳ引き継ぎ後における冗長構成を用いるサーバシステムのブロック図である。 冗長構成を用いるサーバシステムの通常運用復帰後におけるブロック図である。

以下、本発明の実施形態について、図面を参照しながら説明をする。尚、図中で類似の部分または類似の機能を果たす部分については、同一または類似の参照符号を付与して重複した説明を省略する。

以下では、まず、図２〜６を参照してＮ＋１冗長構成（以下、単に冗長構成とも呼ぶ）を用いるサーバシステムおよび障害回復方法の比較例を説明し、その後、図３〜２３を参照して、本発明に従うシステムおよび方法を説明する。図１は、網間ゲートウェイサーバおよびネットワーク機器運用制御サーバが用いられるシステムの図である。

本発明では、１つ以上の現用系物理サーバおよび待機系物理サーバからなる冗長構成において、仮想化機構（仮想化手段）を用いて待機系物理サーバ上の仮想サーバで現用系物理サーバに対応する複数のＯＳを稼動させ、それぞれの現用系とそれに対応する待機系のデータを互いに同期させることによって、コストを抑えつつも、ＣＰＵ性能やＩ／Ｏ性能を犠牲にせず、障害発生時に早期に回復が可能な、高可用性を有する信頼性が高い装置（網間ゲートウェイサーバおよびネットワーク機器運用制御サーバ）を提供することができる。

＜全般的な説明＞
（比較例）
図１は、サーバシステム（網間ゲートウェイサーバおよびネットワーク機器運用制御サーバ）が用いられるシステムを示す図、図２〜６は、冗長構成を備えるサーバシステム、およびそのサーバシステムにおける系の切替方法、特に障害回復方法の比較例である。

イントラネット１４０ａ、１４０ｂ（まとめて１４０）内の端末からインターネット１２０上のサービスへアクセスするためには網間ゲートウェイサーバ１００ａを経由しなければならず、このような環境中で用いられる網間ゲートウェイサーバ１００ａ、１００ｂ（まとめて１００）は、一般に、大きなパケット処理能力が要求され、したがって網間ゲートウェイサーバ１００として用いられるサーバシステムは、大きなＣＰＵパワーを備えることが要求される。

また、ネットワーク機器運用制御サーバ１３０ａ、１３０ｂはインターネット１２０上の多数のネットワーク機器を運用制御し、ネットワーク機器運用制御サーバ１３０ｃもイントラネット１４０ｂ上の多数のネットワーク機器を運用制御しなければならず、このような環境中で用いられるネットワーク機器運用制御サーバ１３０ａ、１３０ｂ、１３０ｃ（まとめて１３０）もまた、一般に、大きなパケット処理能力が要求され、したがってネットワーク機器運用制御サーバ１３０として用いられる装置も、大きなＣＰＵパワーを備えることが要求される。

図２は、４台の物理サーバからなる冗長構成を備えるサーバシステム１００における障害回復方法の比較例の概略を示している。
図２に示されているサーバシステム１００は、冗長構成を構築する、それぞれオペレーティングシステム（ＯＳ）２００、２１０、２２０、２３０が稼動する通信サーバと制御サーバ３００を含み、通信サーバと制御サーバ３００は一つの筐体内に収容されている。ＯＳ２００、２１０、２２０、２３０が稼動する複数のサーバのうちの３つのＯＳ２００、２１０、２２０が稼動するサーバが現用系サーバ、残りの一つのＯＳ２３０が稼動し得るサーバが待機系サーバである。待機系（予備系）のサーバは、通信機器１００が正常に動作している間は、コールドスタンバイ状態にあるので、障害が発生した直後の状態である図２の（Ａ）では、ＯＳ２３０は破線で示されている。ＯＳ２００、２１０、２２０のそれぞれの上では、通信アプリケーション２００２、２１０２、２２０２が稼動している。これら通信アプリケーション２００２、２１０２、２２０２はそれぞれ、通信アプリケーション用のデータ２００４、２１０４、２２０４を生成、利用しながら運用される。

制御サーバ３００は、オペレーティングシステム（ＯＳ）２００、２１０、２２０、２３０が稼動する通信サーバの監視を行い、必要に応じて系の切替を制御する。そのために、制御サーバ３００は、監視している各通信サーバのコンフィグ情報を保持している。

図２の（Ａ）は、制御サーバ３００が、通信アプリケーション２１０２に障害が発生したことを検知したことを示す図である。この障害は、通信アプリケーション２１０２が運用されるサーバの物理的な障害であっても良いし、ソフトウェア的な障害、たとえば通信アプリケーション２１０２でのトラブル発生であっても良い。このとき、待機系サーバはコールドスタンバイ状態（待機中）にある。

次の図２の（Ｂ）では、予備系のサーバのコールドスタンバイ状態を解き、そのサーバ上で稼動するＯＳ２３０とその上で運用される通信アプリケーション２３０２を起動する。ＯＳ２３０の起動に際しては、障害が発生したサーバのコンフィグ情報が制御サーバ３００から転送される。同時に、障害が発生したサーバ、ＯＳ２１０が稼動していたサーバ、は停止する。

そして図２の（Ｃ）では、もともと待機系であった通信サーバを現用系として運用する。
上述の方法では、制御サーバが現用系サーバの一つに障害を検出した後に，待機系サーバにコンフィグ情報を転送してから通信用のアプリケーションを起動することになる。そのため長時間の通信断・サービス断を発生させていた。

また、待機系サーバをＮ個の現用系サーバに対応させるような方法も考えられるが、多様化する通信アプリケーションにＮ＋１重化対応のＮ＋１冗長構成を意識させたコードを実装することはコスト的に実装が困難である上に待機系での信頼性も低下させてしまう。

（サーバシステムの構成）
図３〜１０を参照して、本発明の一実施例に従うサーバシステム（網間ゲートウェイサーバもしくはネットワーク機器運用制御サーバ）１１０の構成を説明する。サーバシステム（以下、単に装置とも呼ぶ）１１０はＮ＋１冗長構成（以下、単に冗長構成とも呼ぶ）を備える。また、サーバシステム１１０も、図１中の網間ゲートウェイサーバ１００またはネットワーク機器運用制御サーバ１３０として用いられる。

このＮ＋１冗長構成を実現するための手段の一つとしては、１台の物理計算機上に仮想的な計算機を構成し、複数のオペレーティングシステム（ＯＳ）を並列して実行する仮想化のための技術、仮想化機構が知られている。この仮想化機構を、本明細書中では仮想化手段と呼ぶこともある。このような技術には仮想計算機方式や論理分割方式がある。これらの技術を用いた計算機を、仮想化機能を利用した計算機または仮想計算機と呼ぶ。仮想計算機がサーバである場合は、仮想サーバと呼ぶこともある。また、仮想化機構の上で動作するＯＳをゲストＯＳと呼ぶ。仮想化機構がその上で稼動するＯＳを、ホストＯＳと呼ぶ。つまり、ホストＯＳが動作する１台の物理計算機上でＮ＋１個のゲストＯＳを並列して実行し、あたかもＮ＋１台の計算機が存在するかのように構成し、そのうちのＮ台を現用系サーバ、残りの１台を待機系（予備系）サーバとして利用し冗長構成を実現する。

仮想計算機方式では、仮想計算機モニタ（ＶＭＭ：Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ Ｍｏｎｉｔｏｒ）と呼ばれる制御ソフトウェアが、計算機のハードウェアやプロセッサの動作を制御するためのレジスタ類を仮想化し、１台の物理計算機上に複数の仮想的な計算機、つまり仮想計算機（ＶＭ：Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ）を実現する。このときゲストＯＳはＶＭＭによって生成された仮想計算機上で動作する。より詳細には、ＶＭＭはゲストＯＳが実行する入出力（Ｉ／Ｏ）命令や制御レジスタ等のＣＰＵの特権命令をトラップして、実際の物理デバイスへのアクセスに変換してエミュレート（処理）し、仮想計算機を作り出す。この仮想計算機方式では、複数のゲストＯＳが１つの物理Ｉ／Ｏデバイスを共有することができる。

この仮想計算機方式のＩ／Ｏ制御では、ゲストＯＳによるＩ／Ｏ操作はＶＭＭがエミュレートするため、オーバーヘッドが発生する。動作しているゲストＯＳが複数ある場合には、ＶＭＭは複数のゲストＯＳのＩ／Ｏ操作を並行して行うため、オーバーヘッドの量の予測は容易ではないことがある。

一方、論理分割方式は、ハイパーバイザーと呼ばれる制御ソフトウェアが物理計算機のリソースを論理的に分割することによって、１台の物理計算機上に複数のＶＭを実現する。つまり、ハイパーバイザーは、プロセッサ等のハードウェアが参照するレジスタ、テーブルを操作して、１台の物理計算機を論理的に分割する。ゲストＯＳは、ハイパーバイザーによって分割された区画（論理パーティション）内で実行される。つまり、ゲストＯＳが実行するＩ／Ｏ命令等の特権命令は、エミュレートされることなく、直接的に物理計算機のプロセッサで実行される。論理分割方式は、その構成から、あるゲストＯＳの動作は、同一の物理計算機上で走る別のゲストＯＳの動作からの影響は受け難い。その一方で、複数のゲストＯＳが１つの物理Ｉ／Ｏデバイスを共有することはできない。本明細書中では、ハイパーバイザーを単にホストＯＳと呼ぶことがある。

一般に仮想化機構は、高可用性とコストパフォーマンスが求められる通信制御用テレコムサーバや通信コンピューターシステムのうち、ブレードサーバを冗長構成のコンピューターシステムとして使用する場合や、アドバンストＴＣＡ筐体で使用するボードのうち、単価が高く、かつ使用枚数が装置としてのパケット処理性能に影響するようなパケットプロセッシングボードを冗長構成で使用する場合に好適である。本発明の装置での仮想化手段としては、仮想計算機方式を用いる手段でも論理分割方式を用いる手段でも良い。

サーバシステム１１０では、冗長構成を構築する複数の物理サーバのうち、待機系物理サーバ（以下、単に待機系サーバとも呼ぶ）の１台のみに仮想化計算機（仮想サーバ）が実現されている。

図３に示されているサーバシステム１１０は、冗長構成を構築する、それぞれオペレーションシステム（ＯＳ）２００、２１０、２２０、２４０が稼動する通信サーバ（待機系物理サーバを含む）と制御サーバ３００を含み、通信サーバと制御サーバ３００は一つの筐体内に収容されている。しかしながら、通信サーバと制御サーバ３００は必ずしも一つの筐体内に収容されてなくても良い。ＯＳ２００、２１０、２２０、２３０が稼動する複数のサーバのうちの３つのＯＳ２００、２１０、２２０が稼動するサーバが現用系物理サーバ（以下、単に現用系サーバとも呼ぶ）、残りの１つのＯＳ２４０が稼動するサーバが待機系サーバである。待機系サーバは仮想化手段を含み、仮想化手段を用いて仮想化され仮想サーバが構築されている。ＯＳ２４０は待機系サーバのホストＯＳであって、その上でゲストＯＳ２４２、２４４、２４６が稼動し得る。図２に示されている比較例とは、待機系サーバ上には現用系サーバのそれぞれに対応する仮想サーバが構築されている点が異なっている。また、各仮想サーバは、それぞれに対応する現用系サーバと常に通信し、アプリケーション、たとえば通信アプリケーションのデータが互いに同期されている。

尚、仮想計算機を提供する仮想化手段は待機系サーバのみならず、現用系サーバにも備えられ、現用系サーバもホストＯＳ上でゲストＯＳを稼動させることが可能なように構成されている。

制御サーバ３００はＯＳ２００、２１０、２２０、２３０が稼動する複数のサーバの運用状況を監視する監視手段を有している。そして、監視している各通信サーバのコンフィグ情報を保持している。また、制御サーバ３００は、現用系サーバと待機系サーバの間で通信アプリケーション用のデータの同期を行う同期手段を有する。この同期手段は現用系サーバと待機系サーバの間で通信アプリケーション用のデータの同期を行うが、仮想化手段によって仮想計算機が構築されたサーバにおいて、ゲストＯＳとホストＯＳの間でデータを同期させる機能を有しても良い。ゲストＯＳとホストＯＳの間でデータを同期させる機能は引継手段（第２の同期手段）として、前記同期手段（第１の同期手段）とは別に用意されても良い。この引継手段は、仮想化手段に含まれても良い。

さらに、制御サーバ３００は、現用系サーバのいずれかに障害が発生したときに、障害が発生したサーバから待機系のサーバへの系の切り替えを制御する切替手段を有する。この切替手段（第１の切替手段）は、現用系と待機系は物理的には別個のサーバ間での系の切り換えを制御する。しかし、たとえば、仮想化機構によって仮想計算機が実現している１台の物理サーバ上で、ゲストＯＳが稼動する仮想計算機が現用系、ホストＯＳが稼動する系が待機系として働く場合に、現用系から待機系への系の切り替えが行われることがある。この切り替えの機能は前記切替手段によって担われても良いし、前記切替手段とは別の移動手段（第２の切替手段）によって担われても良い。移動手段は、仮想化手段に含まれても良い。

さらに、サーバシステム１１０では、正常時には、待機系サーバにおいてのみ仮想化手段を用いて、待機系サーバ上で複数のゲストＯＳを起動させる。一般に、待機系は大きなＣＰＵパワーを要せず、仮想化機能を利用した計算機としてもオーバーヘッドは問題にならない。一方、現用系は正常運用時に大きなＣＰＵパワーを要する。しかしながら、本発明の構成を採用することによって、ＣＰＵパワーを浪費する現用系では仮想化機構の使用に伴うオーバーヘッドが存在せず、高い処理性能を有することができる。

また、サーバシステム１１０では、制御サーバ３００は現用系サーバの運用状態を監視する監視手段および現用系サーバ上のデータと待機系の仮想サーバ上のデータを同期させる同期手段を含む。つまり、現用系サーバと待機系サーバの運用状態は制御サーバ３００の監視手段によって監視され、さらに、現用系サーバ上のデータと待機系の仮想サーバ上のデータは制御サーバ３００の同期手段によって同期している。現用系サーバの運用は対応する仮想サーバによっても監視されている。すなわち、仮想化手段が、監視手段、同期手段、切替手段を含んでいても良い。

そして、現用系サーバに障害が発生したときには、待機系上のそれぞれのＯＳによって、現用系サーバで運用していた通信サーバをバックアップする。仮想化機構が稼動する待機系サーバのホストＯＳとゲストＯＳはアプリケーションに対して同一のＡＰＩを提供する必要があるが、現用系サーバでそれぞれ動作しているアプリケーションは同一である必要はない。もちろん、待機系サーバのホストＯＳとゲストＯＳは同一でも良く、Ｌｉｎｕｘ（登録商標）が用いられても良い。

現用系サーバ上で稼動するホストＯＳと待機系サーバ上で稼動するホストＯＳおよびゲストＯＳが提供するＡＰＩは、各ＯＳ上で動作するアプリケーションが共通に使用できるものであればよいが、ＯＳの間の切り替えの際に各ＯＳが独自に使用するＡＰＩに関してはこの限りではない。

また、アプリケーションは現用系サーバおよび待機系サーバ、たとえば待機系サーバ上に構築された仮想サーバの２つのシステム上で動作すればよく、冗長構成に対応する必要はない。よって、各現用系サーバで動作するアプリケーションは同一である必要はない。さらに、一つの現用系サーバ上で複数のアプリケーションが動作しても良い。

図３は、冗長構成を用いるサーバシステムを示す概略図である。本例のサーバシステムは、３つのサーバから構成される現用系サーバと仮想化機構が稼動する１つの待機系サーバを含んでいる。もちろん、現用系サーバを構成するサーバの数は３には限定されない任意の数で構わない。

図３（Ａ）は、待機系サーバが起動中の状態を示しており、ホストＯＳ２４０、ゲストＯＳ２４２、２４４、２４６、およびそれぞれゲストＯＳ２４２、２４４、２４６上で稼動し得る通信アプリケーション２４２２、２４４２、２４６２は破線で示されている。待機系サーバでは、冗長構成をとるサーバシステムの待機系のホストＯＳ上で運用系サーバのＯＳの数と同じ数だけゲストＯＳが稼動している。つまり、予備系はウォームスタンバイ状態にあるとも言うこともできる。

図３（Ｂ）は、サーバシステム１１０が正常に運用されている状態である。この状態で待機系サーバの各ゲストＯＳ２４２、２４４、２４６上には、現用系サーバ上で運用される通信アプリケーション２００２、２１０２、２２０２のデータ２００４、２１０４、２２０４と同期した通信アプリケーションのデータ２４２４、２４４４、２４６４が置かれる。つまり、現用系サーバと待機系サーバではアプリケーション用のデータの同期が行われている。現用系サーバでデータ２００４、２１０４、２２０４の変更が発生した場合、それぞれが運用系サーバの一つに対応する待機系サーバの上のゲストＯＳにデータを転送し、アプリケーションのデータの同期をする。サーバシステム１１０の運用中、それぞれゲストＯＳ２４２、２４４、２４６が稼動する待機サーバの上のデータ２４２４、２４４４、２４６４は、対応する現用系サーバのＯＳ２００、２１０、２２０のデータ２００４、２１０４、２２０４と同期をし続ける。この同期処理は、制御サーバ３００および／または待機系サーバに備えられる同期手段によって実行される。

同期するデータの例には、次のようなものが含まれ得る。
１）経路情報（ＬＳＡ等）、
２）ＡＲＰキャッシュテーブル、
３）ネイバーキャッシュテーブル、
４）ＴＣＰ／ＵＤＰセッション情報、
５）ＨＴＴＰ／ＨＴＴＰＳコネクション情報、
６）ＮＡＴアドレスマッピング情報、
７）ＱｏＳ均等割り当て帯域情報、
８）ファイアーウォール用アクセス禁止情報（フィルタリング情報）
９）フローテーブル、
１０）各種統計情報、
１１）装置状態。

経路情報を含むデータの例は図４に示されている。図４に示されているデータは、ＲＦＣ４３４０に従うフォーマットを有している。ここでは、ＲＦＣ（Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ）のようにＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）による業界標準に従うフォーマットを有するＬＳＡ（リンクステートアドバタイズメント）を例として挙げたが、ルーティングプロトコルにおける経路管理情報であれば、ＬＳＡに限定されない。

ＡＲＰ（Ａｄｄｒｅｓｓ Ｒｅｓｏｌｕｔｉｏｎ Ｐｒｏｔｏｃｏｌ）キャッシュテーブルの例は図５に示されている。図５に示されているデータは、ＲＦＣ８２６／ＲＦＣ５２２７／ＲＦＣ５４５９に従うフォーマットを有している。ＡＲＰキャッシュテーブルは、ＴＣＰ／ＩＰネットワークでイーサネットフレームを送信するために必要な宛先のＭＡＣアドレスを、宛先のＩＰアドレスに対応させるためのテーブルである。

ネイバーキャッシュテーブルの例は図６に示されている。図６に示されているデータは、ＲＦＣ２４６１、チャプター４．４に従うフォーマットを有している。チャプターネイバーキャッシュテーブルは、ＩＰｖ６でのＩＰアドレスとＭＡＣアドレスのマッピングの際に用いられるテーブルである。

ＴＣＰ／ＵＤＰセッション情報とは、１対１の通信処理で使われるプロトコルであるＴＣＰ（トランスミッションコントロール プロトコル）またはＵＤＰ（ユーザ データグラムプロトコル）の接続（セッション）に関する情報である。

ＨＴＴＰ／ＨＴＴＰＳコネクション情報とは、ＨＴＴＰ（ハイパーテキスト転送プロトコル）またはＨＴＴＰによる通信よりセキュリティを強化したＨＴＴＰＳに則った接続（コネクション）に関する情報である。

ＴＣＰ／ＵＤＰセッション情報、ＨＴＴＰ／ＨＴＴＰＳコネクション情報を含むデータの例は図７、８に示されている。
ＮＡＴアドレスマッピング情報とは、ＮＡＴ（Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｉｏｎ）を用いたアドレス間の対応に関する情報である。一般には、プライベートＩＰアドレスとグローバルＩＰアドレスを対応付けするための情報である。ＩＰｖ４およびＩＰｖ６に準拠するＮＡＴアドレスマッピング情報を含むデータの例は、それぞれ図９および１０に示されている。

ＱｏＳ均等割り当て帯域情報とは、ネットワーク上で、一定の通信速度を保証するために、ある特定の通信のために予約された帯域に関する情報である。
フローテーブルとは特定のＩＰアドレスやポート番号、ＭＡＣアドレス、ＭＰＬＳラベル、入力ポートなどを組み合わせることによってデータの流れを表現した情報である。

また、各種統計情報には、トラフィックの量などが含まれても良い。
装置状態としては、消費電力、ＣＰＵ稼働率、ＣＰＵ温度などサーバとしての動作を特徴付ける量であれば任意の量であって良い。

サーバシステム１１０のハードウェア構成は、図３に示されたような構成に限定されない。より詳細には、複数のサーバを備え、それぞれのサーバ上でデータを参照しながら稼動するアプリケーションが運用される冗長構成をとるサーバシステムであって、複数のサーバのうち少なくとも一つは待機系サーバ、残りは現用系サーバとして運用され、待機系サーバは仮想化機構を用いて仮想化されて複数の仮想サーバ（仮想計算機）が実現し、仮想サーバ上では現用系サーバのＯＳに対応するＯＳが稼動しており、現用系サーバとそれに対応する待機系サーバ上の仮想サーバの間で、現用系サーバで運用されているアプリケーションのデータが同期されるように構成されるものであれば良い。サーバシステムは一つの筐体内に収めされていても良いが、必ずしもそうでなくても良い。図３に示されている構成では、サーバシステムは一つの筐体内に収納されている。

また、少なくとも待機系サーバは、仮想化されたサーバにおいて、ホストＯＳ上に置かれるデータとゲストＯＳ上に置かれるデータ間の同期を行う引継手段を有している。
このような構成を有することによって、サーバシステムは、単一の物理サーバの障害によってシステム全体が停止することはないという利点を有する。また、現用系サーバは仮想化されていないので、正常運転時には仮想化によるオーバーヘッドが存在しないという利点を有する。さらに、正常時に待機系サーバでは、ゲストＯＳが稼動し、現用系サーバとアプリケーションのデータについて同期しているので、ホットスタンバイに比べて消費電力を抑えることができる。また、高可用性を実現することができる。さらに、アプリケーションとしては二重化対応のみを意識すればよいので、アプリケーションコストの開発が容易であり、これはアプリケーション自体およびアプリケーションが動作するシステムの信頼性を高めることができる。また、冗長構成によるコストメリットを実現するとともにネットワークの高信頼化を実現することができる。

（障害回復処理）
図１１を参照して、仮想化機能を利用した冗長構成を備えるサーバシステム１１０における障害回復処理を説明する。

図１１（Ａ）は、図３（Ｂ）に示されたサーバシステム１１０の複数のサーバのうち、ＯＳ２１０が稼動するサーバにハードウェア的またはソフトウェア的な障害が発生し、それを制御サーバ３００が検出したところである。このとき、ＯＳ２１０上で稼動するアプリケーション２１０２のデータ２１０４と、待機サーバ上のゲストＯＳ２４４上に置かれるデータ２４４４とは同期している。しかし、アプリケーション２４４２は稼動していない。

図１１（Ｂ）では、制御サーバ３００が現用系サーバのひとつに障害が検出されたことに応答して、障害が検出された現用系サーバから、待機系サーバ上の対応するゲストＯＳ２４２、２４４、２４６に系を切り替え、待機サーバでの通信、サービスを開始する。それと同時に、障害が検出された現用系サーバ、すなわちＯＳ２１０が稼動するサーバを停止する。

図１１（Ｃ）では、制御サーバ３００は、ゲストＯＳ２４４上で通信アプリケーション２４４２が稼動することによって、性能低下が発生するか否かを判断し、もし性能低下が発生する場合には、ホストＯＳ２３０上でアプリケーション２３０２を新待機系として起動し、新待機系上のデータ２３０４を、同一の物理サーバ上でデータ２４４４と同期させる。この系の切り替えは、制御サーバ３００に備えられる切替手段によって行われても良いし、制御サーバ３００に備えられる切替手段とは別の移動手段によって行われても良い。

図１１（Ｄ）では、全ゲストＯＳ２４２、２４４、２４６をシャットダウンする。これにより通信アプリケーション２４２２、２４４２、２４６２はホストＯＳ２３０上で現用系として動作し、並行して仮想計算機が動作することによる性能低下を防ぐことができる。

図１１（Ｃ）から図１１（Ｄ）への切り替えは、同一の物理サーバ上で行われるため、データの同期の方法には幾つかの方法がある。例としては、
１）仮想サーバ内ネットワーク経由での同期、
２）メモリマップによる同期、
３）共有ディスクによる同期、
４）上記１）〜３）の少なくとも二つの組み合わせによる同期、
を挙げることができる。

第一の仮想サーバ内ネットワーク経由での同期方法は、現用系サーバから待機系の仮想サーバに切り替えた方法と同じであるが逆向きの方法で仮想ネットワークを経由して、ゲストＯＳが稼動する仮想サーバから、ホストＯＳが稼動する物理サーバにデータを同期させる。これらのデータの同期処理は、制御サーバ３００および／または待機系サーバに備えられる同期手段によって実行され得る。

第二のメモリマップによる同期方法は、仮想サーバ上のメモリ空間と物理サーバ上のアプリケーション上のメモリ空間のうち、同期させるデータが保持されている領域をマッピングすることによりデータを同期させる方法である。この方法を用いることにより、切り替えを高速に実行することができる。

第三の共有ディスクによる同期方法では、次のようなステップを踏む。まず、仮想サーバ群と物理サーバの間に共有ディスクを設定する。たとえば物理サーバ側でＮＦＳサーバを起動し、仮想サーバ側はＮＦＳクライアントとしてディスクを共有する。次に、仮想サーバ上で動作するアプリケーションは、同期するデータをディスクに書き込む。仮想サーバから物理サーバへと系を切り替えたあとでは、物理サーバ上で動作するアプリケーションが共有されているディスクに書き込まれたデータを利用する。

第四の方法は、上記第一から第三の方法の少なくとも二つを組み合わせて得られる方法である。
上記４つの方法のうち第一の方法を除く同期方法は、現用系サーバと待機系サーバの間でのデータの同期を行う同期手段とは別の引継手段によって行われても良い。つまり、引継手段では、仮想化されたサーバにおいて、ホストＯＳ上に置かれるデータとゲストＯＳ上に置かれるデータ間の同期を行うものとする。

なお、制御サーバ３００に備えられる各手段、監視手段、同期手段、切替手段は、ソフトウェアプログラムによってまたは専用ハードウェアによって実行される。
上記のような処置によって、従来は時として、障害の発生時に現用系から待機系へのデータ設定から再起動まで、数十秒〜数分の通信の中断が発生することがあったが、性能低下を伴わずに数秒以内で切り替えをすることができる。

＜実施例＞
図１２〜２３を参照して、サーバシステム１１０およびサーバシステム１１０での障害回復方法について説明する。

以下では、一つの筐体内に４台のブレードを含むサーバシステムであって、そのうち３台が現用系物理サーバ（以下、単に現用系サーバとも呼ぶ）として、残りの１台が待機系（予備系）物理サーバ（以下、単に待機系サーバとも呼ぶ）として機能するものについて説明するが、ブレードの個数はこのような値に限定されない任意の数で構わないことは当業者には明らかであろう。

（サーバシステムの構成）
まず、図１２〜１６を参照して、サーバシステム１１０の構成について説明する。サーバシステム１１０は、図１の網間ゲートウェイサーバ１００またはネットワーク機器運用制御サーバ１３０として機能する。

図１２は、サーバシステム１１０のシステム全体図である。サーバシステム１１０は、それぞれ現用系のＯＳ＃１、＃２、＃３（それぞれ２００、２１０、２２０）が稼動する現用系サーバ１２０２、１２０４、１２０６、ホストＯＳ２３０が稼動する待機系サーバ１２０８、およびスイッチ１２１０、１２１２を含んでいる。現用系サーバ１２０２、１２０４、１２０６は、正常運転時には、スイッチ１２１０および１２１２に接続されている。待機系サーバ１２０８のホストＯＳ２３０の上では、仮想化機能を用いて、ゲストＯＳ＃１、＃２、＃３（それぞれ２４２、２４４、２４６）が稼動する３つの仮想計算機（仮想サーバ）が実現している。

待機系サーバ１２０８の上のゲストＯＳ＃１、＃２、＃３は、それぞれ図３のゲストＯＳ２４２、２４４、２４６に対応し、ゲストＯＳ＃１、＃２、＃３が稼動する仮想計算機はそれぞれ、図３のゲストＯＳ２４２、２４４、２４６が稼動する仮想計算機に対応する。

待機系サーバ１２０８上に構築された３つの仮想計算機（仮想サーバ）は、ソフトスイッチ２４８を介してスイッチ１２１２と繋がっている。また、現用系サーバ１２０２、１２０４、１２０６の正常運転時には、３つの仮想計算機はスイッチ１２１０とは繋がっていなくて良い。

これら現用系サーバ１２０２、１２０４、１２０６および待機系サーバ１２０８は、それぞれ、図３のオペレーションシステム（ＯＳ）２００、２１０、２２０、２４０が稼動する通信サーバに対応する。

スイッチ１２１０は、各サーバ１２０２、１２０４、１２０６、１２０８と外部のインターネット／イントラネット１２０／１４０の間に配置されている。各サーバ１２０２、１２０４、１２０６にはそれぞれ、クラスＡのＩＰアドレス、“１０．２３．４．１２１”、“１０．２３．４．１２２” 、“１０．２３．４．１２３”が割り当てられている。これらのクラスＡのＩＰアドレスは、待機系サーバ１２０８の上で稼動するホストＯＳ＃１、＃２、＃３（それぞれ２４２、２４４、２４６）が稼動するサーバまたは待機系のゲストＯＳ＃１、＃２、＃３対しても付与されている。また、待機系サーバのホストＯＳに対しては、クラスＡのＩＰアドレス“１０．２３．４．１２４”が割り当てられている。

スイッチ１２１２は、内部保守用のイーサネットワークのスイッチである。各現用系サーバ１２０２、１２０４、１２０６にはそれぞれクラスＣのＩＰアドレス、“１９２．１６８．１．１”、“１９２．１６８．１．２” 、“１９２．１６８．１．３” が割り当てられている。ホストＯＳ２３０が稼動する待機系サーバ１２０８には、“１９２．１６８．１．４” が割り当てられている。さらに、待機系サーバ１２０８の上で仮想化機構を用いて実現する仮想計算機のＯＳ、即ちゲストＯＳ＃１、＃２、＃３（それぞれ２４２、２４４、２４６）にはそれぞれ、 “１９２．１６８．１．４１”、“１９２．１６８．１．４２”、“１９２．１６８．１．４３”が割り当てられる。

現用系サーバ１２０２、１２０４、１２０６上で稼動するアプリケーション２００２、２１０２、２２０２に付随するデータは、サーバシステム１１０内の各サーバを互いに接続する内部保守イーサネットワークを介して、３つの仮想サーバ上に置かれるデータと同期する。

スイッチ１２１０またはスイッチ１２１２は、制御サーバ３００として機能する。即ち、スイッチ１２１０またはスイッチ１２１２は、監視手段、同期手段、および切替手段を有する。切替手段は、現用系サーバ１２０２、１２０４、１２０６で障害が発生しないかを監視する。同期手段は、現用系サーバ１２０２、１２０４、１２０６と待機系サーバ１２０８の間でアプリケーションのデータを同期させ、切替手段は、必要に応じてスイッチ１２１０を制御し、さらに現用系サーバ１２０２、１２０４、１２０６と待機系サーバ１２０８の運用を制御する機能、特に現用系サーバ１２０２、１２０４、１２０６と待機系サーバ１２０８の間の系の切り替えを行う機能を有している。スイッチ１２１２は、現用系サーバ１２０２、１２０４、１２０６および待機系サーバ１２０８と内部保守イーサネットワークを介して電気的に接続されている。

尚、ＳＲ−ＩＯＶなど仮想化をサポートしたネットワークカードを利用する場合には、ソフトスイッチはネットワークカードに内蔵されていても良い。

図１３は、図１１に示されているサーバシステム１１０のブロック図である。
サーバシステム１１０は、現用系サーバ１２０２、１２０４、１２０６、および待機系（予備系）のサーバ１２０８を含む。各サーバ上では、それぞれホストＯＳ２００、２１０、２２０、２３０が稼動している。現用系サーバ１２０２、１２０４、１２０６では、ホストＯＳ２００、２１０、２２０、２３０の上で直接、アプリケーション２００２ａ〜２００２ｂ、２１０２ａ〜２１０２ｄ、２２０２が稼動する。一方、待機系サーバ１２０８では、ホストＯＳ２３０上に仮想化機構を用いて実現された３つの仮想計算機１２１４、１２１６、１２１８が構築され、それぞれゲストＯＳ２４２、２４４、２４６が稼動している。さらに、３つのゲストＯＳ２４２、２４４、２４６上で、それぞれフローエンジン（ミドルウェア）２４２４、２４４４、２４６４とアプリケーション２００２ａ〜２００２ｂ、２１０２ａ〜２１０２ｄ、２２０２が稼動する。つまり、アプリケーション２００２ａ〜２００２ｂ、２１０２ａ〜２１０２ｄ、２２０２は二重化に対応している。本実施例で、ホストＯＳはＬｉｎｕｘである。しかしながら、ホストＯＳはＬｉｎｕｘ（登録商標）には限定されない。また、現用系サーバと待機系サーバのホストＯＳが同一である必要もないし、複数の現用系サーバのホストＯＳが同一である必要もなく、同一ＡＰＩを提供するＯＳであれば良い。

図１４〜１６は、上記のようなサーバシステム１１０のハードウェア構成の例である。
図１４は、図１２、１３のようなシステム構成を有するブレードサーバ４００を示している。ブレードサーバ４００では、ブレード筐体４１０内に複数のブレード（図１４では４枚のブレード）４０２、４０４、４０６、４０８が搭載されている。図示されていないが、制御サーバ３００の機能を果たすシャーシマネージメントモジュール（ＣＭＭ）も搭載されていても良い。ブレード４０２、４０４、４０６、４０８は、ブレード筐体４１０に抜き差し可能に構成され、ラックに比べて省スペースを図ることが可能である。ブレードサーバ４００内の各ブレードはＣＰＵを備えるＮ＋１冗長構成を有する。各ブレード４０２、４０４、４０６、４０８にはネットワーク接続用の端子、たとえばイーサネット（Ｅｔｈｅｒｎｅｔ）（登録商標）規格に準拠した端子が設けられている。

図１５は、ＡＴＣＡ（Ａｄｖａｎｃｅｄ Ｔｅｌｅｃｏｍ Ｃｏｍｐｕｔｉｎｇ Ａｒｃｈｉｔｅｃｔｕｒｅ）サーバ５００を示している。
ＡＴＣＡサーバ５００は、ＡＴＣＡ筐体５０２、シングルボードコンピュータ（ＳＢＣ）ブレードまたはパケットプロセッシングボード（ＰＢＢ）ブレード５０４、５０６、５０８、５１０、５１２、５１４、５１６、５１８、シャーシマネージメントモジュール（ＣＭＭ）５２０のほか、図示されていない、ＲＴＭ（Ｒｅａｒ Ｔｒａｎｓｉｔｉｏｎ Ｍｏｄｕｌｅ）等を含み得る。ＳＢＣブレードは、ＣＰＵを搭載するブレードであり、ＰＢＢブレードはパケット処理を行う。図１５に示されているＡＴＣＡサーバ５００は、ＳＢＣブレードまたはＰＢＢブレードを８枚搭載し、これらのブレードがＮ＋１冗長構成を構築する。ＲＴＭは、ブレードとペアで実装される拡張モジュールで、ハードディスクやファイバーチャネル、ＩＰ回線などの入出力（Ｉ／Ｏ）回路を実装する。ＡＴＣＡ筐体５０２は、前述の各ユニットを搭載する筐体である。ＣＭＭ５２０は、ＡＴＣＡ筐体５０２に搭載された各ユニットの状態監視や制御を行う。ＣＭＭ５２０はまた、制御サーバ３００の機能を実行し得る。

本例では、制御サーバ３００の機能を実行するためにＣＭＭ５２０を備えたが、Ｎ＋１冗長構成内部の待機系サーバが制御サーバ３００の機能を実行しても良い。

図１６に示されているＡＴＣＡサーバ６００では、ＡＴＣＡ筐体６０２に搭載された複数のＳＢＣブレードまたはＰＢＢブレード６０４、６０６、６０８、６１０、６１２、６１４、６１６、６１８の一部のみがＮ＋１冗長構成を構築する。具体的には、ＳＢＣブレードまたはＰＢＢブレード６０４、６０６は二重化構成のサーバを構築し、ＳＢＣブレードまたはＰＢＢブレード６０８、６１０、６１２、６１４、６１６、６１８がＮ＋１冗長構成を構築する。

（障害回復処理）
図１７〜２３を参照しながら、サーバシステム１１０における障害回復処理について説明する。

図１７、１８はそれぞれ、サーバシステム１１０における障害回復処理のフローチャートおよびシーケンス図である。図１８のシーケンス図において、待機系サーバ４は、ホストＯＳ２３０を有するサーバを指す。

Ｓ１００では、現用系サーバ１２０２、１２０４、１２０６は待機系サーバ１２０８上の各ゲストＯＳ２４２、２４４、２４６またはゲストＯＳ２４２、２４４、２４６が稼動する仮想サーバ１２１４、１２１６、1２１８とデータを同期する。

Ｓ１０２では、現用系サーバ１２０４で障害が発生するとする。すると、Ｓ１０４または／およびＳ１０６で障害が検出される。より具体的には、Ｓ１０４では、制御サーバ３００が現用系サーバ１２０４の障害を検出する。Ｓ１０６では、現用系サーバ１２０４のペアである待機系仮想サーバ１２１６によって現用系サーバ１２０４の障害が検出される。

次にＳ１０８で、現用系サーバ１２０４に対応する待機系仮想サーバ１２１６が、現用系仮想サーバとして動作を開始する。このときのシステム図が図１９に、ブロック図が図２０に示されている。

Ｓ１０８の次のＳ１１０では、待機系仮想サーバ１２１６から待機系サーバ１２０８に切り替えを実施し、ホストＯＳ２３０が稼動する待機系サーバ１２０８が、新たな現用系サーバとして動作を開始する。このときのシステム図が図２１に示されている。この待機系仮想サーバ１２１６から待機系サーバ１２０８への切り替えは、制御サーバの切替手段によって実行されても良い。しかしながら、この系の切り替えは、同一の物理サーバ上での切り替えなので、制御サーバ３００に備えられる切替手段（第一の切替手段）とは別の、仮想化手段に備えられる移動手段（第二の切替手段）によって実行されても良い。

待機系仮想サーバ１２１６から待機系サーバ１２０８への切り替えには、上述の引継手段によって実行されても良い。
そしてＳ１１２で、待機系サーバ１２０８は、ホストＯＳ２３０上で稼動している仮想サーバ１２１４、１２１６、1２１８をシャットダウンする。この仮想サーバのシャットダウンは、制御サーバ３００または仮想化手段が備えるシャットダウン手段によって実行される。

図１７、１８には示されていないが、Ｓ１１２の後、サーバ１２０４を再起動させ（図２２）、サーバ１２０４において仮想化機構を用いて、障害発生前のサーバ１２０８と同一の構成を有する新たな待機系サーバを構築しても良い（図２３）。図２２は、図２１に示されているホストＯＳ引き継ぎ後における本発明に従うＮ＋１冗長構成を用いるサーバシステムのブロック図、図２３は、本発明のサーバシステムの通常運用復帰後におけるサーバシステムのブロック図である。図２３に示されているブロック図は、障害発生前のものと同一である。

待機系仮想サーバ１２１６から待機系サーバ１２０８への系の切り替えのタイミングは、第一または第二の切替手段によって判定されても良い。たとえば、制御サーバによって得られる各サーバ、今の場合現用系サーバ１２０２、１２０６および待機系仮想サーバ１２１６の運用状態に関するデータを基に、待機系仮想サーバ１２１６の処理スピードに不足がある場合にのみ、待機系仮想サーバ１２１６から待機系サーバ１２０８への系の切り替えを行っても良い。たとえば、サーバ１２０８のＣＰＵ稼働率を基に系の切り替えを行っても良い。または、待機系仮想サーバ１２１６の運用状態に関するデータを基に、待機系仮想サーバ１２１６から待機系サーバ１２０８への系の切り替え作業が待機系仮想サーバ１２１６の処理に影響を及ぼさないと判断されたときに行っても良い。たとえば、待機系仮想サーバ１２１６のトラフィック量が小さいときに系の切り替えを行っても良い。

上記のような構成を採用することによって、待機系物理サーバ上の仮想サーバで現用系物理サーバのＯＳが稼動するサーバシステムにおいて、現用系とそれに対応する待機系のデータを互いに同期させることによって、コストを抑えつつも、ＣＰＵ性能やＩ／Ｏ性能を犠牲にせず、障害発生時に早期に回復が可能な、高可用性を有する信頼性が高いサーバシステムを制御する制御サーバを得ることができる。

また、コストを抑えつつも、ＣＰＵ性能やＩ／Ｏ性能を犠牲にせず、障害発生時に早期に回復が可能な、高可用性を有する信頼性が高い、前記制御サーバによって実行され得る障害回復制御方法を得ることができる。

以上の実施例を含む実施形態に関し、さらに以下の付記を開示する。
（付記１）
データの生成、削除、参照を伴って運用されるアプリケーションが運用される１つ以上の現用系物理サーバの運用状態を監視する監視手段と、
前記現用系物理サーバと、前記現用系物理サーバの数と同じ数の仮想サーバを含む待機系物理サーバ上の前記現用系物理サーバに対応する前記仮想サーバの一つとの間で前記データの同期を行う同期手段と、
前記監視手段が前記現用系物理サーバの一つの運用状態に障害が生じたことを見つけたときに、前記現用系物理サーバの一つに対応する前記仮想サーバの一つの上で、前記現用系物理サーバの一つで運用されていた前記アプリケーションを起動し、前記同期手段によって前記現用系物理サーバ上の前記データと同期していた前記仮想サーバの一つの上の前記データの一つを参照しつつ、前記アプリケーションを運用し、さらに、前記仮想サーバの一つから前記待機系物理サーバに系の切り替えを行う切替手段と、
を含む制御サーバ。
（付記２）
前記切替手段は、
前記待機系物理サーバの上のデータを前記待機系物理サーバ上に同期させる引継手段と、
前記待機系物理サーバの上で前記アプリケーションを起動し、前記仮想サーバの一つから前記待機系物理サーバへ系の切り替えを行う移動手段と、
を含む付記１の制御サーバ。
（付記３）
さらに、前記仮想サーバの少なくとも一つをシャットダウンするシャットダウン手段を含む、付記１または２の制御サーバ。
（付記４）
前記監視手段は、少なくとも前記仮想サーバの一つの運用状態を監視し、
前記切替手段は、前記仮想サーバの一つの運用状態に基づいて、前記仮想サーバの一つから前記待機系物理サーバへ系の切り替えを開始する、
請求項１または２の制御サーバ。
（付記５）
データの生成、削除、参照を伴って運用されるアプリケーションが運用される１つ以上の現用系物理サーバの運用状態を監視することと、
前記現用系物理サーバと、前記現用系物理サーバの数と同じ数の仮想サーバを含む待機系物理サーバ上の前記現用系物理サーバに対応する前記仮想サーバの一つとの間で前記データの同期を行うことと、
前記監視手段が前記現用系物理サーバの一つの運用状態に障害が生じたことを見つけたときに、前記現用系物理サーバの一つに対応する前記仮想サーバの一つの上で、前記現用系物理サーバの一つで運用されていた前記アプリケーションを起動し、前記同期手段によって前記現用系物理サーバ上の前記データと同期していた前記仮想サーバの一つの上の前記データの一つを参照しつつ、前記アプリケーションを運用し、さらに、前記仮想サーバの一つから前記待機系物理サーバに系の切り替えを行うことと、
を含む障害回復制御方法。
（付記６）
前記切り替えを行うことは、さらに、
前記待機系物理サーバの上のデータを前記待機系物理サーバ上に同期させることと、
前記待機系物理サーバの上で前記アプリケーションを起動し、前記仮想サーバの一つから前記待機系サーバへ系の切り替えを行うことと、
を含む付記５の障害回復制御方法。
（付記７）
さらに、前記仮想サーバの少なくとも一つをシャットダウンすることを含む、付記５または６の障害回復制御方法。
（付記８）
前記監視することは、少なくとも前記仮想サーバの一つの運用状態を監視し、
前記切り替えを行うことは、前記仮想サーバの一つの運用状態に基づいて、前記仮想サーバの一つから前記待機系物理サーバへ系の切り替えを開始する、
付記５または６の障害回復制御方法。
（付記９）
データの生成、削除、参照を伴って運用されるアプリケーションが運用される１つ以上の現用系物理サーバと、
仮想サーバを提供する仮想化手段と、前記仮想化手段によって提供される前記現用系物理サーバの数と同じ数の仮想サーバを含む待機系物理サーバと、
前記現用系物理サーバの運用状態を監視する監視手段と、
前記現用系物理サーバとそれに対応する前記仮想サーバの間で前記データの同期を行う同期手段と、
前記監視手段が前記現用系物理サーバの一つの運用状態に障害が生じたことを見つけたときに、前記現用系物理サーバの一つに対応する前記仮想サーバの一つの上で、前記現用系物理サーバの一つで運用されていた前記アプリケーションを起動し、前記同期手段によって前記現用系物理サーバ上の前記データと同期していた前記仮想サーバの一つの上の前記データの一つを参照しつつ、前記アプリケーションを運用し、さらに、前記仮想サーバの一つから前記待機系物理サーバに系の切り替えを行う切替手段と、
を含む制御サーバと、
を含むサーバシステム。
（付記１０）
前記切替手段は、
前記待機系物理サーバの上のデータを前記待機系物理サーバ上に同期させる引継手段と、
前記待機系物理サーバの上で前記アプリケーションを起動し、前記仮想サーバの一つから前記待機系物理サーバへ系の切り替えを行う移動手段と、
を含む付記９のサーバシステム。
（付記１１）
データの生成、削除、参照を伴って運用されるアプリケーションが運用される１つ以上の現用系物理サーバと、
仮想サーバを提供する仮想化手段と、前記仮想化手段によって提供される前記現用系物理サーバの数と同じ数の仮想サーバを含む待機系物理サーバと
前記現用系物理サーバの運用状態を監視する監視手段と、前記現用系物理サーバとそれに対応する前記仮想サーバの間で前記データの同期を行う同期手段を含み、前記監視手段が前記現用系物理サーバの一つの運用状態に障害が生じたことを見つけたときに、前記現用系物理サーバの一つに対応する前記仮想サーバの一つの上で、前記現用系物理サーバの一つで運用されていた前記アプリケーションを起動し、前記同期手段によって前記現用系物理サーバ上の前記データと同期していた前記仮想サーバの一つの上の前記データの一つを参照しつつ、前記アプリケーションを運用し、さらに、前記仮想サーバの一つから前記待機系物理サーバに系の切り替えを行う切替手段と、含む制御サーバと、
前記待機系物理サーバの上のデータを前記待機系サーバ上に同期させる引継手段と、
前記待機系物理サーバの上で前記アプリケーションを起動し、前記仮想サーバの一つから前記待機系物理サーバへ系の切り替えを行う移動手段と、
を含むサーバシステム。
（付記１２）
前記制御サーバは、前記仮想サーバの少なくとも一つをシャットダウンするシャットダウン手段を含む、付記９乃至１１のいずれか一つのサーバシステム。
（付記１３）
前記仮想化手段は、前記仮想サーバの少なくとも一つをシャットダウンするシャットダウン手段を含む、付記９乃至１１のいずれか一つのサーバシステム。
（付記１４）
前記監視手段は、少なくとも前記仮想サーバの一つの運用状態を監視し、
前記切替手段は、前記仮想サーバの一つの運用状態に基づいて、前記仮想サーバの一つから前記待機系物理サーバへ系の切り替えを開始する、
付記９または１０のサーバシステム。
（付記１５）
前記監視手段は、少なくとも前記仮想サーバの一つの運用状態を監視し、
前記移動手段は、前記前記仮想サーバの運用状態に基づいて、前記仮想サーバの一つから前記待機系物理サーバへ系の切り替えを開始する、
付記１１のサーバシステム。
（付記１６）
前記運用状態はＣＰＵ稼働率である、付記１４または１５のサーバシステム。
（付記１７）
前記運用状態はパケットのトラフィック量である、付記１４または１５のサーバシステム。
（付記１８）
１つ以上の現用系物理サーバと待機系物理サーバを含むサーバシステムの障害回復方法であって、
前記現用系物理サーバ上で、データの生成、削除、参照を伴って運用されるアプリケーションを運用することと、
前記現用系物理サーバの数と同じ数の仮想サーバを前記待機系物理サーバ上で運用することと、
前記現用系物理サーバの運用状態を監視することと、
前記現用系物理サーバとそれに対応する前記仮想サーバの一つとの間で前記データの同期を行うことと、
前記監視手段が前記現用系物理サーバの一つの運用状態に障害が生じたことを見つけたときに、前記現用系物理サーバの一つに対応する前記仮想サーバの一つの上で、前記現用系物理サーバの一つで運用されていた前記アプリケーションを起動し、前記同期手段によって前記現用系物理サーバ上の前記データと同期していた前記仮想サーバの一つの上の前記データの一つを参照しつつ、前記アプリケーションを運用し、さらに、前記仮想サーバの一つから前記待機系物理サーバに系の切り替えを行うことと、
を含む障害回復方法。
（付記１９）
前記切り替えを行うことは、さらに、
前記待機系物理サーバの上のデータを前記待機系物理サーバ上に同期させることと、
前記待機系物理サーバの上で前記アプリケーションを起動し、前記仮想サーバの一つから前記待機系物理サーバへ系の切り替えを行うことと、
を含む付記１８の障害回復方法。
（付記２０）
１つ以上の現用系物理サーバと待機系物理サーバを含むサーバシステムの障害回復方法であって、
前記現用系物理サーバ上で、データの生成、削除、参照を伴って運用されるアプリケーションを運用することと、
前記現用系物理サーバの数と同じ数の仮想サーバを前記待機系物理サーバ上で運用することと、
前記現用系物理サーバの運用状態を監視することと、
前記現用系物理サーバとそれに対応する前記仮想サーバの一つとの間で前記データの同期を行うことと、
前記監視手段が前記現用系物理サーバの一つの運用状態に障害が生じたことを見つけたときに、前記現用系物理サーバの一つに対応する前記仮想サーバの一つの上で、前記現用系物理サーバの一つで運用されていた前記アプリケーションを起動し、前記同期手段によって前記現用系物理サーバ上の前記データと同期していた前記仮想サーバの一つの上の前記データの一つを参照しつつ、前記アプリケーションを運用し、さらに、前記仮想サーバの一つから前記待機系物理サーバに系の切り替えを行うことと、
前記待機系物理サーバの上のデータを前記待機系サーバ上に同期させることと、
前記待機系物理サーバの上で前記アプリケーションを起動し、前記仮想サーバの一つから前記待機系物理サーバへ系の切り替えを行うことと、
を含む障害回復方法。
（付記２１）
さらに、前記仮想サーバの少なくとも一つをシャットダウンすることを含む、付記１８乃至２０のいずれか一つの障害回復方法。
（付記２２）
前記監視することは、少なくとも前記仮想サーバの一つの運用状態を監視し、
前記切り替えを行うことは、前記仮想サーバの一つの運用状態に基づいて、前記仮想サーバの一つから前記待機系物理サーバへ系の切り替えを開始する、
付記１８または１９の障害回復方法。
（付記２３）
前記運用状態はＣＰＵ稼働率である、付記２２の障害回復方法。
（付記２４）
前記運用状態はパケットのトラフィック量である、付記２２の障害回復方法。

１０ ネットワークシステム
１００ａ、１００ｂ（１００）、１１０、４００、５００ 網間ゲートウェイサーバ
１２０ インターネット
１３０ａ、１３０ｂ、１３０ｃ（１３０） ネットワーク機器運用制御サーバ
１４０ａ、１４０ｂ（１４０） イントラネット
２００、２１０、２２０、２３０ ２４２、２４４、２４６、２４８、２５０、２５２ オペレーティングシステム
２００２ａ、２００２ｂ（２００２）、２１０２ａ、２１０２ｂ、２１０２ｃ、２１０２ｄ（２１０２）、２２０２、２３０２、２４２２、２４４２、２４６２ アプリケーション
２００４、２１０４、２２０４、２３０４、２４２４、２４４４、２４６４ データ
２４４４、２４８４、２５０４、２５２４ ミドルウェア
３００ 制御サーバ
１２０２、１２０４、１２０６、１２０８ サーバ
１２１０、１２１２ スイッチ
１２１４、１２１６、1２１８ 仮想サーバ
２４８ ソフトスイッチ
４００ ブレードサーバ
４０２、４０４、４０６、４０８ ブレード
４１０ ブレード筐体
５００ ＡＴＣＡサーバ
５０４、５０６、５０８、５１０、５１２、５１４、５１６、５１８ シングルボードコンピュータ（ＳＢＣ）ブレードまたはパケットプロセッシングボード（ＰＢＢ）ブレード
５２０ シャーシマネージメントモジュール（ＣＭＭ）

Claims (15)

1. データの生成、削除、参照を伴って運用されるアプリケーションが運用される１つ以上の現用系物理サーバの運用状態を監視する監視手段と、
   前記現用系物理サーバと、前記現用系物理サーバの数と同じ数の仮想サーバを含む待機系物理サーバ上の前記現用系物理サーバに対応する前記仮想サーバの一つとの間で前記データの同期を行う同期手段と、
   前記監視手段が前記現用系物理サーバの一つの運用状態に障害が生じたことを見つけたときに、前記現用系物理サーバの一つに対応する前記仮想サーバの一つの上で、前記現用系物理サーバの一つで運用されていた前記アプリケーションを起動し、前記同期手段によって前記現用系物理サーバ上の前記データと同期していた前記仮想サーバの一つの上の前記データの一つを参照しつつ、前記アプリケーションを運用し、さらに、前記仮想サーバの一つから前記待機系物理サーバに系の切り替えを行う切替手段と、
   を含むサーバ。
2. 前記切替手段は、
   前記待機系物理サーバの上のデータを前記待機系物理サーバ上に同期させる引継手段と、
   前記待機系物理サーバの上で前記アプリケーションを起動し、前記仮想サーバの一つから前記待機系物理サーバへ系の切り替えを行う移動手段と、
   を含む請求項１のサーバ。
3. さらに、前記仮想サーバの少なくとも一つをシャットダウンするシャットダウン手段を含む、請求項１または２のサーバ。
4. 前記監視手段は、少なくとも前記仮想サーバの一つの運用状態を監視し、
   前記切替手段は、前記仮想サーバの一つの運用状態に基づいて、前記仮想サーバの一つから前記待機系物理サーバへ系の切り替えを開始する、
   請求項１または２のサーバ。
5. データの生成、削除、参照を伴って運用されるアプリケーションが運用される１つ以上の現用系物理サーバと、
   仮想サーバを提供する仮想化手段と、前記仮想化手段によって提供される前記現用系サーバの数と同じ数の仮想サーバを含む待機系物理サーバと、
   前記現用系物理サーバの運用状態を監視する監視手段と、
   前記現用系物理サーバとそれに対応する前記仮想サーバの間で前記データの同期を行う同期手段と、
   前記監視手段が前記現用系物理サーバの一つの運用状態に障害が生じたことを見つけたときに、前記現用系物理サーバの一つに対応する前記仮想サーバの一つの上で、前記現用系物理サーバの一つで運用されていた前記アプリケーションを起動し、前記同期手段によって前記現用系物理サーバ上の前記データと同期していた前記仮想サーバの一つの上の前記データの一つを参照しつつ、前記アプリケーションを運用し、さらに、前記仮想サーバの一つから前記待機系物理サーバに系の切り替えを行う切替手段と、
   を含む制御サーバと、
   を含むサーバシステム。
6. 前記切替手段は、
   前記待機系物理サーバの上のデータを前記待機系物理サーバ上に同期させる引継手段と、
   前記待機系物理サーバの上で前記アプリケーションを起動し、前記仮想サーバの一つから前記待機系物理サーバへ系の切り替えを行う移動手段と、
   を含む請求項１のサーバシステム。
7. データの生成、削除、参照を伴って運用されるアプリケーションが運用される１つ以上の現用系物理サーバと、
   前記現用系サーバの数と同じ数の仮想サーバを含む待機系物理サーバと
   前記現用系物理サーバの運用状態を監視する監視手段と、前記現用系物理サーバとそれに対応する前記仮想サーバの間で前記データの同期を行う同期手段を含み、前記監視手段が前記現用系物理サーバの一つの運用状態に障害が生じたことを見つけたときに、前記現用系物理サーバの一つに対応する前記仮想サーバの一つの上で、前記現用系物理サーバの一つで運用されていた前記アプリケーションを起動し、前記同期手段によって前記現用系物理サーバ上の前記データと同期していた前記仮想サーバの一つの上の前記データの一つを参照しつつ、前記アプリケーションを運用し、さらに、前記仮想サーバの一つから前記待機系物理サーバに系の切り替えを行う切替手段と、含む制御サーバと、
   前記待機系物理サーバの上のデータを前記待機系物理サーバ上に同期させる引継手段と、
   前記待機系物理サーバの上で前記アプリケーションを起動し、前記仮想サーバの一つから前記待機系物理サーバへ系の切り替えを行う移動手段と、
   を含むサーバシステム。
8. 前記制御サーバは、前記仮想サーバの少なくとも一つをシャットダウンするシャットダウン手段を含む、請求項１乃至３のいずれか一つのサーバシステム。
9. 前記仮想化手段は、前記仮想サーバの少なくとも一つをシャットダウンするシャットダウン手段を含む、請求項１乃至３のいずれか一つのサーバシステム。
10. 前記監視手段は、少なくとも前記仮想サーバの一つの運用状態を監視し、
    前記切替手段は、前記仮想サーバの一つの運用状態に基づいて、前記仮想サーバの一つから前記待機系サーバへ系の切り替えを開始する、
    請求項１または２のサーバシステム。
11. 前記監視手段は、少なくとも前記仮想サーバの一つの運用状態を監視し、
    前記移動手段は、前記前記仮想サーバの運用状態に基づいて、前記仮想サーバの一つから前記待機系サーバへ系の切り替えを開始する、
    請求項３のサーバシステム。
12. データの生成、削除、参照を伴って運用されるアプリケーションが運用される１つ以上の現用系物理サーバの運用状態を監視することと、
    前記現用系物理サーバと、前記現用系サーバの数と同じ数の仮想サーバを含む待機系物理サーバ上の、前記現用系物理サーバに対応する前記仮想サーバの一つとの間で前記データの同期を行うことと、
    前記監視手段が前記現用系物理サーバの一つの運用状態に障害が生じたことを見つけたときに、前記現用系物理サーバの一つに対応する前記仮想サーバの一つの上で、前記現用系物理サーバの一つで運用されていた前記アプリケーションを起動し、前記同期手段によって前記現用系物理サーバ上の前記データと同期していた前記仮想サーバの一つの上の前記データの一つを参照しつつ、前記アプリケーションを運用し、さらに、前記仮想サーバの一つから前記待機系物理サーバに系の切り替えを行うことと、
    を含む障害回復制御方法。
13. 前記切り替えを行うことは、さらに、
    前記待機系物理サーバの上のデータを前記待機系物理サーバ上に同期させることと、
    前記待機系物理サーバの上で前記アプリケーションを起動し、前記仮想サーバの一つから前記待機系物理サーバへ系の切替を行うことと、
    を含む請求項１２の障害回復制御方法。
14. さらに、前記仮想サーバの少なくとも一つをシャットダウンすることを含む、請求項１２または１３の障害回復制御方法。
15. 前記監視することは、少なくとも前記仮想サーバの一つの運用状態を監視し、
    前記切替を行うことは、前記仮想サーバの一つの運用状態に基づいて、前記仮想サーバの一つから前記待機系物理サーバへ系の切り替えを開始する、
    請求項１２または１３の障害回復制御方法。