障害回復アーキテクチャ
【課題】パケットベースのネットワークにおける障害回復のための方法及びシステムを提供すること。
【解決手段】ネットワーク（５０）はパケットベースのネットワーク（５６）により接続された生産サイト（５２）と回復サイト（５４）とを含む。生産サイト（５２）のミラーリングソフトウエア（６８）は、生産サイトで発生した最後のトランザクションまで回復サイト（５４）を最新のものに保つ。回復制御サーバ（８４）は障害状態又は他の故障を検出するために生産サイトに対しポーリングする。生産サイト（５２）に問題を検出すると、生産サイト（５２）にアクセスする試みが回復サイト（５４）にルーティングされるように回復制御サーバ（８４）がネットワーク（５６）を再設定する。
【解決手段】ネットワーク（５０）はパケットベースのネットワーク（５６）により接続された生産サイト（５２）と回復サイト（５４）とを含む。生産サイト（５２）のミラーリングソフトウエア（６８）は、生産サイトで発生した最後のトランザクションまで回復サイト（５４）を最新のものに保つ。回復制御サーバ（８４）は障害状態又は他の故障を検出するために生産サイトに対しポーリングする。生産サイト（５２）に問題を検出すると、生産サイト（５２）にアクセスする試みが回復サイト（５４）にルーティングされるように回復制御サーバ（８４）がネットワーク（５６）を再設定する。
【発明の詳細な説明】
【技術分野】
【０００１】
一般に本発明は通信ネットワークに関するものであり、特に、通信ネットワークにおいて使用される障害回復技術に関する。
【背景技術】
【０００２】
ネットワーク化されたコンピュータシステムの大衆性と利便性により、データベースによるユーザー間でのデータ共有が多くのビジネス環境において普及してきた。データベースを介した情報への集中型アクセスを行なうには、データベースの保守と管理を注意深く考慮する必要がある。さらに、回復技術はハードウエア／デバイスの故障又はアプリケーションロジックの故障の後でのデータベースの一貫性を保証することが必須である。
【０００３】
一般に、回復技術は損傷を受けた後にシステム又はシステムに記憶されたデータをリセットして動作可能な状態にすると共に、バックアップコピーをリストアすることによりデータベースを再構築する方法を提供する。
【０００４】
いずれのデータ回復システムにおいても、興味ある２つのポイントがある。
・第１は目標回復ポイント（ＲＰＯ）であり、これは元のデータとバックアップコピーとの間の最大計画相違を定義する。
・第２は目標回復時間（ＲＴＯ）であり、これはサービスの再開のための最大時間を定義する。
【０００５】
システムバックアップの最も単純な形式の一つとして、磁気テープ上に作られたデータのコピーを遠く離れたアーカイビング・サイトに物理的に輸送することが挙げられる。一般に、この場合にはユーザーはバックアップテープを作っている間はすべてのデータベースの活動を停止する必要がある。次に、この障害回復ではバックアップテープを用いてデータベースを回復させることを必要とする。
【０００６】
システムバックアップの更に最近の形式では、ネットワークの相互接続を使用して生産(production)サイトの周期的なバックアップを実行する。このようなバックアップが行われる時間はネットワーク管理者により制御される。アプリケーションサーバをリストアするための方法は、古いシステムと同様の特徴を有するハードウエアを含めて新しいシステムをインストールすること、及びシステムについてのバックアップされたイメージを回復サイトからリストアすることを含む。
【０００７】
Ｖｅｒｉｔａｓにより供給される別の従来技術のシステム（本特許出願の出願日時点ではＵＲＬ：http://www.veritas.com/Products/www?c=product&refId=140にてインターネットからダウンロードで入手可能）は、バックアップ手順の正確な実行に必要な種々の段階、及びクライアントをリストアする後続の段階を制御するためのソフトウエアモジュールのアーキテクチャを検討している。特に、Ｖｅｒｉｔａｓの解決策では、バックアップ動作の制御と管理のためのサーバ、クライアントのリストア段階の制御のためのサーバ、リストアのために必要なプログラム及び設定をクライアントに与えるサーバ、及び最後にリモート・ブーティングの管理のためのサーバを含めて、個別の各機能面について様々なサーバが使用される。
【０００８】
別の従来技術の解決策は、標題「Cisco Network Boot Installation and Configuration Guide, Release 3.1」の論文（本特許出願の出願日時点ではＵＲＬ：http://www.cisco.com/en/US/products/hw/ps4159/ps2160/products_installation_and_configuration_guide_book09186a00801a45bO.htmlにてインターネットからダウンロードで入手可能）に記載のシスコ・ネットワーク・ブート・システムであり、オペレーティングシステム、サーバ上のアプリケーション及びデータを含めてシステムイメージ全体のコピーを作る。バックアップはネットワーク管理者によって相互に実行される。シスコの解決策は、複製を行なったプライマリサーバと同じハードウエアの特徴を有するという条件で、ネットワーク上でブート手順を遠隔で実行する可能性を与える。したがって、回復サーバはネットワークからシステムイメージの遠隔コピーをリストアし、プライマリサーバにより以前に保証されたサービスを再提供することができる。
【０００９】
米国特許公開ＵＳ２００４／０１５３６９８Ａ１には、損傷又は破壊した通信ネットワーク要素のサービスについて障害に対する準備及び修復をするシステム及び方法が提供されている。ネットワーク要素のための障害バックアップをするコンピュータ実行方法は、複数のネットワーク要素との接続性を得ることを含む。複数のコンピュータ読み取り可能なサービス連続性データをネットワーク要素のローカルメモリに生成するコンピュータルーチンを呼び出すために、ホストコンピュータは１つ以上の指令をネットワーク要素に送信できる。ネットワーク要素の障害回復のためにコンピュータ実行可能な構成要素から成る自動システムが、障害バックアップ動作のために指定された複数のネットワーク要素を選択するように構成されたコンピュータ実行可能なコントローラ構成要素を含む。コンピュータ実行可能なエンジン構成要素は、前記複数のネットワーク要素への接続性を得るよう構成される共に、前記ネットワーク要素の各々に対してサービス連続性データを複製するために１つ以上の指令をネットワーク要素に送信するよう構成される。
【００１０】
米国特許公開ＵＳ２００４／００７８３９７Ａ１では、ファイルシステム障害回復技術が、自動監視、故障検出及び第１指定ターゲットから指定グループの第２指定ターゲットの一つへの多段階フェイルオーバーを提供する。フェイルオーバーが所定の順序で起こるように、第２指定ターゲットに優先順位を付けてもよい。第１指定ターゲットと第２指定ターゲットとの間での情報の複製により、動作の連続性を最大限にするようにフェイルオーバーが可能となる。加えて、ユーザー特定の動作は、故障検出及び／又はフェイルオーバー動作及び／又はフェイルバック動作のすぐあとで開始できる。
【特許文献１】米国特許公開ＵＳ２００４／０１５３６９８Ａ１
【特許文献２】米国特許公開ＵＳ２００４／００７８３９７Ａ１
【発明の概要】
【発明が解決しようとする課題】
【００１１】
発明の目的及び概要
出願人は、障害発生の後にシステムをリストアする際に、クライアントが好ましくは良好なＲＰＯ及びＲＴＯ値を維持しつつも設定を手動で変えて回復サイトの回復サーバにアクセスする必要がなく、ネットワーク要素のリストアとは独立にクライアントがサービスにアクセスできることを保証するという問題が存在することに気付いた。
【課題を解決するための手段】
【００１２】
出願人は、この問題は障害回復を実行する請求項１の方法により解決できることを見いだした。
【００１３】
特に、出願人は、この問題はクライアントを回復サーバにルーティングする自動再ルーティング機構を提供することによって解決できることを見いだした。さらに、サーバのデータ及び設定を最後のトランザクションに常に一致させることができるミラーリング手順を介するデータ複製段階のための自動制御・管理機構を提供することによってこの問題を解決できることを見いだした。
【００１４】
本発明の別の態様は、障害回復を実行する請求項１２に記載のシステムに関する。
【００１５】
本発明の別の態様は、少なくとも１つのコンピュータのメモリにロード可能であると共に、コンピュータ上で実行するとき本発明の方法の工程を実行するためのソフトウエアコード部分を含んでいるコンピュータプログラムプロダクトに関する。ここで用いられているように、このようなコンピュータプログラムプロダクトというときには、コンピュータシステムを制御して本発明の方法の実行を整合させるための命令を含んだコンピュータ読み出し可能媒体をいうのと等価である。「少なくとも１つのコンピュータ」というのは、明らかに本発明を分散／モジュール方式で実装する可能性を強調するものである。
【００１６】
本発明のさらに好ましい態様が独立請求項及び以下の明細書において記載される。
【００１７】
本発明をさらに良く理解するために、単なる例であって限定するものと解釈すべきでない好ましい態様を、添付図面を参照して以下で説明する。
【図面の簡単な説明】
【００１８】
【図１】本発明に従って障害回復を実行するためのシステム図である。
【図２】図１の生産サイトの詳細システム図である。
【図３】広域ネットワークの詳細図である。
【図４】回復制御サーバの詳細図である。
【図５】正常な動作状態の期間におけるネットワークトラヒックのフローを示す。
【図６】障害回復の状況でのネットワークトラヒックのフローを示す。
【図７】フェイルバック状況でのネットワークトラヒックのフローを示す。
【図８】本発明を実装するための方法のフローチャートである。
【発明を実施するための形態】
【００１９】
本発明の好ましい態様の詳細な説明
図１は生産サイト５２、回復サイト５４、生産サイトと回復サイトとの間に接続されたネットワーク５６、及びエクストラネットクライアント５８を含んだシステム５０の図である。生産サイトは１つ以上のアプリケーションサーバ６２に接続されたストレージ６０を含むことができる。例えばイーサネットスイッチ及びＩＰルータを含み得るネットワーク６６を介してアプリケーションサーバ６２にアクセスするために、１つ以上のイントラネットクライアント６４が使用される。ボックス６６にはまた、認証システム、ファイアウォール又はアプリケーションサーバへのアクセスを阻止する侵入検出システムを含み得るセキュリティデバイスも示されている。リモートストレージボリューム上のアプリケーションサーバのローカルイメージの同期複製を実行するために、ミラーリングソフトウエアモジュール６８が用いられる。このような同期複製によって、ストレージ６０上に置かれたデータが最後のトランザクションまで回復サイト５４上にて保持されたコピーと一致することが保証される。また、最後のトランザクションがサーバの設定に対する損傷を引き起こした場合に、前にセーブされた安定なイメージに戻ることができるように、システムの安定な動作条件に対応したシステムのイメージをミラーリングソフトウエアモジュールがセーブすることも望ましい。
【００２０】
回復サイト５４は１つ以上の回復サーバ７８、ネットワーク・セキュリティデバイス８０、ストレージエリアネットワーク（ＳＡＮ）デバイス８２、及び回復制御サーバ８４を含むことができる。回復サーバ７８は障害が発生した場合にアプリケーションサーバ６２を模倣するよう構成される。障害が発生した場合にアプリケーションサーバ６２に最も密接に関連したプールの一つを使用できるように、様々なハードウエアの特徴を有する回復サーバのプールを提供することが望ましい。ＳＡＮデバイス８２はミラーリングソフトウエアモジュール６８から提供されるミラーデータを記憶する。ネットワーク・セキュリティデバイス８０は生産サイトのネットワーク・セキュリティデバイス６６と同じ機能を回復サイト５４のために実行する。回復制御サーバ８４は、それらのアクセス可能性を監視するよう管理された各アプリケーションサーバ６２に対して周期的なリクエスト（キープアライブ）を実行する。このようにして、回復制御サーバ８４は生産サイト５２に問題があるか否かを監視できる。加えて、回復制御サーバ８４は、１つ以上のアプリケーションサーバ６２からミラーリングソフトウエア６８を介して回復サイト５４のＳＡＮストレージ８２へのストレージフローを監視してもよい。例えばポーリングなどによって回復制御サーバ８４から生産サイト５２を監視するのに多くの技術を使用できる。後にさらに説明するように、回復制御サーバ８４はまた、生産サイトで問題が検出された場合に生産サイト５２から回復サイト５４への自動切替えを制御する。その際、問題が検出されたアプリケーションサーバ６２に最も密接に関連している利用可能なサーバのプールから回復サーバ７８の一つを選択する必要があるかもしれない。加えて、回復制御サーバ８４は、エクストラネットクライアント５８及びイントラネットクライアント６４が回復サーバ７８に自動的かつシームレスにアクセスできるように必要なネットワーク５６、６６を自動的に再設定する。最後に、アプリケーションサーバ６２がリストアされると共にＳＡＮデバイス８２からのデータがコピーされて生産サイト５２に戻される必要がある場合に、回復制御サーバ８４はフェイルバック条件を自動的に管理できる。
【００２１】
図２は可能性のある生産サイト５２のさらに詳細な例を示す。アプリケーションサーバ６２はシステムイメージ１００を含む。システムイメージ１００はオペレーティングシステム１０２、アプリケーション１０４の一組、及びオペレーティングシステムとアプリケーションが操作するデータ１０６を含む。大容量ストレージ６０はデータ１０６がセーブされるローカル記憶デバイスを含む。記憶イニシエータ１１０もまたアプリケーションサーバ６２上に存在する。記憶イニシエータ１１０は、ネットワークインフラストラクチャー（例えば、ＬＡＮ、ＷＡＮなど）を介してアクセスできるリモートストレージボリュームにデータを転送可能にするソフトウエアモジュールである。ソフトウエアミラー６８はアプリケーションサーバ６２においてローカルイメージの同期複製を実行するソフトウエアモジュールである。次に、ローカルイメージは記憶イニシエータモジュール１１０を介して回復サイト５４にて記憶される。ソフトウエアミラーモジュール６８はまた、異なる時間間隔で複数のシステムイメージを保持するように、システムイメージのスナップショットを取ることもできる。よって、最後のトランザクションを有することに加えて、異なる時間間隔にてシステムの安定なコピーを有することが可能である。このことにより、システムは異なる時間に取得した１つ以上の安定なコピーを有することができるので、システムは既知の安定な状態に戻ることができる。ソフトウエアミラー６８を用いてシステムイメージのリモートコピーが実行されるので、特定の製造業者に属する独占的な解決策からアーキテクチャが解放される。上記の種類のソフトウエアミラーモジュールは例えばインターネットＵＲＬ：http://www.veritas.com/Products/www?c=product&refId=3（本特許出願の出願日の時点で）からダウンロードにて利用できる。
【００２２】
イントラネットクライアント６４はネットワークデバイス１１２（この場合、レベル２及びレベル３デバイスとして示されている）を介してアプリケーションサーバ６２にアクセスできる。よって、ネットワークデバイス１１２は、生産サイトのパケットベースのネットワークのために使用されるデバイスであり、メトロポリタン、国内、又は国際レベルでのアクセスのために第三者のパケットベースのネットワークに接続することを可能にする。ネットワークデバイス１１２はＬＡＮ／ＭＡＮ技術、ＩＰルータなどとし得る。セキュリティデバイス１１４はエクストラネットクライアントからの無許可アクセスに対してセキュリティを提供する。例えば、セキュリティデバイスとして、ファイアウォール、侵入検出システムなどを挙げることができる。セキュリティデバイスは、任意の所望の規格（例えば、ＳＮＭＰ）やコマンドラインインターフェースを介して監視及び構成が行える。
【００２３】
図３はＷＡＮ５６をさらに詳しく示す。ＷＡＮ５６はエクストラネット５８と生産サイト５２と回復サイト５４との間の相互接続を可能にする。様々なプロトコルを使用できる。例えば、２つのサイトを相互接続すべく仮想プライベートネットワーク（ＶＰＮ）サービスを使用可能にするために、マルチプロトコル・ラベル・スイッチング（ＭＰＬＳ）プロトコルを用いることができる。ＷＡＮ５６は全体的に１２０で示された複数のネットワークスイッチングデバイスを含む。具体的には、カスタマーエッジデバイス（例えば、ネットワークをクライアントコンピュータに接続するのに用いられるルータやスイッチなどのネットワークの装置）１２２、１２４はそれぞれ生産サイト５２と回復サイト５４に配置されると共に、プロバイダーのポイント・オブ・プレゼンス（ＰｏＰ）に位置するプロバイダーエッジ（ＰＥ）ネットワークデバイス１２６、１２８、（例えば、カスタマーエッジデバイスとの接続を可能にするサービスプロバイダーのネットワークの一部であるルータ）との通信を可能にする。他のプロバイダーネットワークデバイス１３０（単にＰで示されている）はプロバイダーエッジ１２６、１２８とエクストラネット５８との間の通信を可能にする。新しいサイトを既存のＶＰＮに加えるために、プロバイダーは例えばプロビジョニングプラットホーム（プロビジョニングプラットホーム）を用いて正しい設定をＣＥ及びＰＥデバイスに与えることができる。ＭＰＬＳ ＶＰＮはＩＰレベルの接続を同じＶＰＮに属するサイトに提供することを可能にする。（仮想プライベートＬＡＮサービスなどの）より革新的な解決策は、同じＶＰＮに属するサイト間でイーサネット接続を設置することを可能にする。ＭＰＬＳ ＶＰＮ解決策のように、新しいサイトをＶＰＬＳに加えるために、プロバイダーＣＥ及びＰＥデバイスに作用するのみである。これら２つの解決策の主要な違いは、ＶＰＬＳサービスの場合にプロバイダーがカスタマーによって行われたルーティングを管理しないことである。
【００２４】
後でさらに説明するように、回復サイトの回復制御サーバ８４は、障害が発生した場合にエクストラネット５８及びイントラネットクライアント６４が回復サイト５４にアクセスできるように、ネットワークデバイス１２０を再ルーティングする能力を有する。回復制御サーバ８４は、その動作ドメイン（生産サイト及び回復サイト）に属するシステムに対する動作規則を自律的に設定し、必要ならば、ネットワークオペレータなどの第三者により一般に実行される他の制御システムとインターフェースすることによって、その直接制御の外部でシステムと相互作用できる。
【００２５】
図４は回復制御サーバ８４のさらなる詳細を示す。説明のために、ＭＰＬＳ機能と共にＷＡＮが用いられる場合を示しているが、上述したようなプライベート仮想ネットワーク解決策の設定を可能にする他のパケットベースのネットワークを使用することもできる。カスタマー情報マネージャーモジュール１５０（ＣＩＭＭ）は、リポジトリモジュール１５２内部のメタデータを取り扱うと共に、生産サイト５２のアプリケーションサーバ６２の特徴を示すソフトウエアモジュールである。リポジトリモジュール１５０に記憶された情報として下記のものを挙げることができる：
・アプリケーションサーバのルーティング計画。
・イントラネット／エクストラネットクライアントに対するアプリケーションサーバのアクセス規則。
・生産サイトのネットワークトポロジー及び生産サイトと回復サイトとの相互接続についての情報。
・アプリケーションサーバのハードウエア特徴。
・オペレーティングシステム、インストールされたソフトウエアパッケージなどに関するイメージ特徴。
・サービスについて合意されたサービス・レベル・アグリーメント。
・生産サイトのアプリケーションサーバと互換性のある特徴を有する回復サイトのサーバの可用性。
【００２６】
アプリケーションサーバ制御モジュール（ＡＳＣＭ）１５４は、生産サイト５２のアプリケーションサーバのアクセス可能性を検査するソフトウエアモジュールである。この検査は、サーバのＩＰアドレスをポーリングすること、又はサーバ６２内にインストールされたアプリケーションがアクティブであることを確認することによって実行される。制御の追加レベルは、ローカルストレージとリモートストレージとの間で同期ミラーリングプロセスを可能にするソフトウエアによって有効にされる。アプリケーションサーバ６２が設定可能なしきい値（例えば、３０秒、ただしこの時間は特定のアプリケーションに依存して変わり得る）を超える期間の間アクセスされ得ないならば、ＡＳＣＭモジュール１５４が障害回復手順を起動するためのリクエストを行なう。
【００２７】
ストレージゲートウエイ制御モジュール（ＳＧＣＭ）１５６はストレージゲートウエイ管理システムにリクエストを行い、下記の機能を実行できる。
・回復サイト５４のストレージデバイスに対する、アプリケーションサーバ６２によるアクセス。ストレージアクセスはアクセスコントロールリスト（ＡＣＬ）の設定を介して管理され、アクセスコントロールリスト（ＡＣＬ）は、どのサーバが所与のストレージデバイスにアクセスする許可を有しているかを特定する。
・リソースを解放又は割当てするリクエスト。この機能は、例えば所与のアプリケーションサーバに対して障害回復サービスを停止することが決定されていたという理由で、予め割り当てられたリソースを解放するリクエストを行なうことを可能にし、又は逆に言えば新しいストレージリソースを割り当てることを可能にする。この機能は、カスタマーにより署名されたＳＬＡについての情報を更新すると共に、リポジトリ１５２に保持される。
・フェイルバック条件における複製プロセスの管理。障害回復手順の後、この機能は、回復サイト５４の回復サーバ７８によりローカルで使用されるデータのコピーを生産サイト５２のストレージボリューム上で実行可能にする。データが生産サイトにて首尾一貫した方法にてリストアされた後は、初期動作条件に戻ることができ、この初期動作条件では、イントラネット及びエクストラネットクライアントによりアクセスされるサービスが生産サイトのアプリケーションサーバにより公開される。
・割り当てられたリソースの使用ステータスの検査。この機能により、ストレージデバイスの効果的な活用についての統計値を得ることができると共に、新しいデバイス（回復サイトのプールのための処理及びストレージリソース）の取得を前もって評価することができる。
【００２８】
プロビジョニングプラットホーム制御モジュール（ＰＰＣＭ）１５８は、プロビジョニングプラットホームに対するリクエストを取り扱うソフトウエアモジュールである。ネットワークデバイスの供給業者は、プログラミングメタ言語において受信したリクエストをネットワークデバイスに与えられる設定に翻訳可能にするプロビジョニングプラットホームを提供する。ＰＰＣＭ１５８は生産サイト５２と回復サイト５４とを相互接続するネットワークのトポロジーに基づいてこれらのリクエストを実行する。プロビジョニングシステムは、それらが取り扱うネットワークインフラストラクチャーのトポロジー的記述と、ネットワークの所望の最終状態の記述とに基づいて、デバイスに与えられるべき設定指令を自動的に生成する。これらのリクエストは例えば以下のモードにて行なうことができる。
【００２９】
静的モード：プロビジョニングシステムにリクエストをするために必要な情報がカスタマーリポジトリ内部に予め割り当てられる。故障が生じた場合、情報がデータベースから抽出され、方式に従って調製され、プロビジョニングシステムに送られる。
【００３０】
動的モード：プロビジョニングシステムにリクエストをするために必要な情報がプロビジョニングシステムと制御モジュールとの間の相互作用を通じて動的に得られる。この場合、必ずしもデータベースにおいて情報を予め構成する必要はない。
【００３１】
障害回復制御モジュール（ＤＲＣＭ）１６０は、アプリケーションサーバ制御モジュール１５４により知らされた故障の発生に応じて障害回復プロセスを自動化することを扱うソフトウエアモジュールである。このモジュールはカスタマーリポジトリ１５２に含まれる情報に従って以下の手順を起動できる。
・生産サイト５２のネットワークのトポロジー及び生産サイト５２と回復サイト５４との相互接続に関する情報を収集する目的での、カスタマー情報マネージャーモジュール１５０との相互作用。
・生産サイト５２にて設定されたルーティング計画を回復サイト５４に移動させるための、プロビジョニングプラットホーム制御モジュール１５８へのメッセージの送信。この段階はカスタマーサイトとプロバイダーサイトに存在するＣＥデバイスの設定、及び対応するＰＥデバイスの設定についての変更を含む。
・回復サイト５４内のＳＡＮデバイス８２にセーブされた最近のシステムイメージを識別する目的での、ストレージゲートウエイ制御モジュール１５６との相互作用。
・ディスクレス起動の時に回復サイト５４のサーバプールにおける指定回復サーバが生産サイト５２のアプリケーションサーバ６２と同じＩＰアドレスを受信するための、回復サイトのＤＨＣＰ（ダイナミックホストコンフィグレーションプロトコル）サーバの設定。
・アプリケーションサーバ６２と互換性のある特徴を有する回復サイト５４のリソースプールに属するハードウエアシステムを識別するための、カスタマー情報マネージャーモジュール１５０との相互作用。
・回復サーバ７２上でのディスクレス起動手順を有効にする。例えば、インターネットでＵＲＬ：http://www.cisco.com/en/US/products/hw/ps4159/ps2160/products_installation_and_configuration_guide_book09186a00801a45b0.html（本特許出願の出願日の時点で）からダウンロードで利用可能な種類のディスクレス起動手順が使用できる。
【００３２】
モジュール１５０、１５４、１５６、１５８、及び１６０は回復制御サーバ８４内にあるＣＰＵ１７２により実行される。加えて、これらのモジュールは通信のためにインターフェースモジュール１６２と相互作用する。インターフェースモジュール１６２は、キープアライブモジュール１６４、ストレージゲートウエイアダプタ１６６、プロビジョニングプラットホームアダプタ１６８、及びストレージプラットホームアダプタ１７０を含めて様々なアダプタを含む。
【００３３】
アプリケーションサーバ６２が生産サイト５２にてリストアされるとき、手動又は自動でフェイルバック手順を起動して、ネットワーク設定を故障前の状態に戻して割り当てられたリソースを解放することができる。フェイルバック手順は、回復モードに関して自明の対称性を有するので、回復手順に類似のロジックに従う。
【００３４】
最初にシステムを設定するために、ソフトウエアミラー６８がアプリケーションサーバ６２上にインストールされて同期若しくは非同期ミラーリング又は周期的な複製を実行する。回復制御サーバ８４はいくつかの設定動作を実行する。例えば、ＳＧＣＭ１５６は生産サイト５２のストレージ６０とアプリケーションサーバ６２のＩＰアドレスとを関連付けるための設定を実行する。ＰＰＣＭ１５８はリポジトリモジュール１５２内部にロードされるべきネットワーク設定のためにプロビジョニングシステムに対してリクエストを行なう。ロードされる情報は以下のものを含み得る：
生産サイト５２と回復サイト５４との接続を確保するために使用されるＣＥ-ＰＥネットワークデバイスＩＤ。障害回復に伴うすべてのサイトから回復サイトへのアクセス可能性を確保するのに用いられるＣＥ-ＰＥネットワークデバイスＩＤ。障害回復の場合に回復サイトに移動するために生産サイトにて用いられるルーティング計画。サービスへのアクセス規則を定義する生産サイトのＣＥデバイス上で設定されたアクセスコントロールリストが、エクストラネット接続を介してアプリケーションサーバにより利用可能にされる。
【００３５】
回復制御サーバ８４におけるＣＩＭＭ１５０は、アプリケーションサーバ６２及び生産サイトに関する情報をリポジトリモジュール１５２に加える。このような情報としては、サーバのハードウエア特徴（例えば、システムイメージのサイズ、ネットワークインターフェースの数など）、アプリケーションサーバのソフトウエア特徴、及びＰＰＣＭ１５８から発せられる情報が挙げられる。
【００３６】
最後に、ＡＳＣＭ１５４はサーバの可用性を調べるために周期的なポーリングを起動する。もしサーバが応答しないならば、障害回復手順を起動する。
【００３７】
図５は正常な動作条件でのシステムを示す。ＡＳＣＭ１５４はアプリケーションサーバが矢印１８０により示されるようにアクティブであることを調べる。また、アプリケーションサーバのシステム管理者はアプリケーションサーバプラットホーム上で為されたハードウエアの変更を障害回復サービスの管理者に知らせることが望ましい。その目的は、リポジトリ１５２に保持された情報を最新のものに維持すると共に、障害回復手順が起動された場合に正しい回復サーバを選択可能にすることである。矢印１８２で示されるように、通常運転中、エクストラネットクライアント５８は生産サイト５２のアプリケーションサーバ６２にアクセスする。情報はサーバ６２上で更新されているので、ソフトウエアミラー６８は情報が矢印１８０で示されるように回復サイト５４でも記憶されることを保証する。
【００３８】
設定可能なしきい値を超えた時間間隔の間ＡＳＣＭ１５４がアプリケーションサーバ６２からＡＣＫメッセージを受信しない場合に、障害回復手順が起動される。ＤＲＣＭ１６０を用いて、回復制御サーバ８４は以下の手順を起動できる。
１）生産サイトのネットワークのトポロジー及び生産サイトと回復サイトとの相互接続に関する情報を収集する目的で、ＣＩＭＭ１５０と相互作用する。
２）生産サイトにて構成されたルーティング計画を回復サイトに移動させるために、メッセージ（マイグレートネットワーク（MigrateNetwork））をＰＰＣＭに送信する。この段階はカスタマーサイト及びプロバイダーサイトのＣＥ-ＰＥデバイスの設定についての変更を伴う。
３）回復サイト内のストレージシステムにセーブされた最近のシステムイメージを識別する目的で、ＳＧＣＭと相互作用する（複製機構が用いられる場合には最近のものに一致し得る）。
４）起動（ディスクレス起動）される際に回復サーバを有効にして生産サイトのアプリケーションサーバと同じＩＰアドレスを受信するために、回復サイトのＤＨＣＰサーバの設定を行なう。
５）アプリケーションサーバと互換性のある特徴を有する回復サイトのリソースプールに属するハードウエアシステムを識別するために、ＣＩＭＭと相互作用する。
６）ディスクレス起動手順を可能にする：この段階では、ＧＵＩは人間のオペレータに待機中のハードウエアリソースプールから選択された回復サーバを始動できることを知らせる。
【００３９】
内部ストレージ（ディスクレス）を有していないかもしれない回復サーバは、アプリケーションサーバのシステムイメージ（ＩＰアドレス、ボリューム名、ＬＵＮなど）を含んだストレージシステムにアクセスすることに関連したＩＰアドレスと情報とを得るために、ＤＨＣＰサーバにリクエストを行なう。いったんこの情報が受信されると、回復サーバはネットワーク上でディスクレス起動を実行できる。フィニッシュを起動するとき、回復サーバは最後のトランザクションまで元のアプリケーションサーバに一致している。あらゆるイントラネット、エクストラネット又はインターネットクライアントは、障害回復手順で設定された接続を用いてＴＣＰ／ＩＰを介して回復サーバのリストアされたサービスにアクセスできる。
【００４０】
図６は障害回復手順が開始された後のデータフローを示す。矢印１８８で示されるように、エクストラネットクライアントが生産サイト５２にアクセスしようと試みるとき、リクエストが自動的に回復サイト５４に再ルーティングされる。このことはエクストラネットユーザーに対してトランスペアレントに行われ、エクストラネットユーザーが回復サイトについて異なるネットワークアドレスをタイピングする必要はない。よって、エクストラネットクライアントの観点からは、たとえ実際には回復サイトにアクセスされていても、生産サイトに依然としてアクセスされている。
【００４１】
図７はフェイルバック条件を示す。フェイルバック手順は障害回復手順の後に初期状態に戻ることを可能にする。生産サイト５２のアプリケーションサーバ６２がリストアされた後も、すべてのサービスが回復サイトにより提供される期間が依然として存在する。
【００４２】
フェイルバック手順は上述した正常動作条件に戻るために以下の段階を含むことができる。
１）ＳＧＣＭ１５６が、矢印１９０で示すように生産サイト上で回復サイトのデータの一致したコピーを行なうために、逆複製手順を起動する。
２）回復サイトにて構成されたルーティング計画を生産サイトに移動させるために、ＤＲＣＭがメッセージ（マイグレートネットワーク（MigrateNetwork））をＰＰＣＭに送信する。この段階はカスタマーサイト及びプロバイダーサイトのＣＥ-ＰＥデバイスの設定についての変更を伴う。
３）生産サイトでのサービスが再開され、クライアントが元のアプリケーションサーバ６２にアクセスする。
４）回復サイト５４にて回復サーバ７８により用いられるハードウエアリソースが解放され（自由なリソースプールに戻される）。
５）同期／非同期ミラーリング（又は複製）手順が再起動される。
【００４３】
図８は本発明を実行する方法のフローチャートを示す。プロセスブロック２１０では、回復サイトがポーリングにより生産サイトでの問題を検出する。プロセスブロック２１２では、生産サイトへのアクセスの試みが回復サイトにルーティングされるように、回復サイトが自動的にネットワークの再設定を実行する。このようなリクエストはエクストラネット又はイントラネットリクエストに由来し得る。
【００４４】
本発明の利点は上記説明から明らかである。
【００４５】
特に、利点の一つは、ＲＰＯ及びＲＴＯパラメータがミラーリングプロセスにより実行される複製によって最適化されることである。
【００４６】
別の利点は、本発明は生産又は回復サイトで採用されるソフトウエア／ハードウエア解決策に依存しないことである。
【００４７】
さらに別の利点は、クライアントを回復サーバにルーティングする自動再ルーティングである。
【００４８】
最後に、本発明について多くの変更及び変形が為し得ることは明らかであるが、すべて本発明の範囲に存する。
【００４９】
例えば、本解決策を拡張及び変更して、それを達成する個々の構成要素に作用させるか、又は既存の構成要素を当該技術における制御アーキテクチャに統合することができる。
【００５０】
特に、生産サイトでは、同期／非同期ミラーリングソフトウエアを提供する構成要素は特定の技術に限定されない。それらはホストベース、ネットワークベース、又はアレイベースの仮想化機構、及びソフトウエアモジュール又は特定のハードウエア構成要素により実現できる。
【００５１】
さらに、ここに記載した「障害」とは、生産サイトが何がしかの理由で機能していないことを意味する。これは実際の障害が生ぜざるを得なかったことを意味しない。
【００５２】
さらにまた、生産サイトと回復サイトとの間の相互接続ネットワークでは、リモートサイトへのミラーリング／複製フローのために用いられるプロトコルは、回復サイトのストレージにて生産サイトで行われるのと同じ書き込みを再生する機能を実行する限りは、標準的又は独占的なプロトコル（例えば、ＳＣＳＩ）とし得る。
【００５３】
加えて、回復サイトでは、ネットワーク上で起動するための機構は、生産サイトにてデータにアクセスするのに用いられるか又は２つのサイト間での相互接続において用いられるプロトコルとは異なるトランスポートプロトコル（例えばファイバーチャンネル又はｉＳＣＳＩ）を回復サイトにてローカルに使用できる。さらに、回復制御サーバは、同じデバイス内にすべてを一緒に構築するか、又は要求される基本機能を達成する他のデバイスの特徴若しくは機能性を利用する分散方式にて構築できる。これらの機能の制御ロジックは、独立のシステムで実現できるか、又は上記デバイスの一つにおいて追加機能として統合できる。特に、回復サイトでアプリケーションサーバを再開した後に提供されるサービスのネットワーク再ルーティングは、別のシステムにより部分的に又は完全に制御され、手持ちのシステムのインテリジェンスモジュールに統合され、接続プロバイダーに関するエクストラネット／イントラネットＶＰＮサイトの動的管理に委ねられ得る。この再ルーティング機構は、２つのサイト間及びクライアントと生産サイトとの間で用いられる特定の接続性に基づいて様々な代替物（ＭＰＬＳ ＶＰＮ又は積み重ね可能なＶＬＡＮ／ｄｏｔｌｑなど）を使用できる。同様に、回復制御サーバ内部のストレージゲートウエイの構成要素は、ゲートウエイ又はストレージスイッチなどの市販プロダクトに既に存在するベースモジュールを統合することによって実現できる。
【００５４】
プライマリサイトを正常な条件にリストアすること（フェイルバック）を更に最適化するために、本解決策の回復及びリストア機構は、動的又は動的でない特定のＱｏＳ機構とすることもでき、これは回復及びリストア段階における動作を加速させるためにリストア活動の時間窓を小さくして、正常な動作条件において利用可能なものよりも広い伝送帯域を有する相互接続を２つのサイト間に提供する。
【００５５】
予想されるように、回復サイトの回復サーバによって特に個々の回復サーバ上に形成された処理用ハードウエアリソースを最適化するために、本解決策により保護されるアプリケーションサーバのハードウエア特徴をリソースプールを構成するシステムのものから切り離すべく、特定のソフトウエアモジュールをインストールして物理リソースを仮想化できる。
【００５６】
このことにより、このような回復サーバを生産サイトのプライマリサーバのハードウエアと互換性を有せしめると共に、より効率的なリソースの割り当てを保証することが更に容易になる。このようにして、システムの物理ドライバを仮想化する機能のお陰で（１：１仮想化）、異なるハードウエアが同じ物理設定上でエミュレートされるのが可能にされ、最新式の障害回復サービスは生産サイトのアプリケーションサーバのものと同じハードウエア設定を有するサーバを採用することから解放され得る。加えて、１つより多いアプリケーションサーバイメージに対して同じハードウエアリソースを同時に利用するために仮想化ソフトウエアを使用することもできる（ｎ：１仮想化）。
【符号の説明】
【００５７】
５０ 本発明のシステム
５２ 生産サイト
５４ 回復サイト
５６ 生産サイトと回復サイトとの間に接続されたネットワーク
５８ エクストラネットクライアント
【技術分野】
【０００１】
一般に本発明は通信ネットワークに関するものであり、特に、通信ネットワークにおいて使用される障害回復技術に関する。
【背景技術】
【０００２】
ネットワーク化されたコンピュータシステムの大衆性と利便性により、データベースによるユーザー間でのデータ共有が多くのビジネス環境において普及してきた。データベースを介した情報への集中型アクセスを行なうには、データベースの保守と管理を注意深く考慮する必要がある。さらに、回復技術はハードウエア／デバイスの故障又はアプリケーションロジックの故障の後でのデータベースの一貫性を保証することが必須である。
【０００３】
一般に、回復技術は損傷を受けた後にシステム又はシステムに記憶されたデータをリセットして動作可能な状態にすると共に、バックアップコピーをリストアすることによりデータベースを再構築する方法を提供する。
【０００４】
いずれのデータ回復システムにおいても、興味ある２つのポイントがある。
・第１は目標回復ポイント（ＲＰＯ）であり、これは元のデータとバックアップコピーとの間の最大計画相違を定義する。
・第２は目標回復時間（ＲＴＯ）であり、これはサービスの再開のための最大時間を定義する。
【０００５】
システムバックアップの最も単純な形式の一つとして、磁気テープ上に作られたデータのコピーを遠く離れたアーカイビング・サイトに物理的に輸送することが挙げられる。一般に、この場合にはユーザーはバックアップテープを作っている間はすべてのデータベースの活動を停止する必要がある。次に、この障害回復ではバックアップテープを用いてデータベースを回復させることを必要とする。
【０００６】
システムバックアップの更に最近の形式では、ネットワークの相互接続を使用して生産(production)サイトの周期的なバックアップを実行する。このようなバックアップが行われる時間はネットワーク管理者により制御される。アプリケーションサーバをリストアするための方法は、古いシステムと同様の特徴を有するハードウエアを含めて新しいシステムをインストールすること、及びシステムについてのバックアップされたイメージを回復サイトからリストアすることを含む。
【０００７】
Ｖｅｒｉｔａｓにより供給される別の従来技術のシステム（本特許出願の出願日時点ではＵＲＬ：http://www.veritas.com/Products/www?c=product&refId=140にてインターネットからダウンロードで入手可能）は、バックアップ手順の正確な実行に必要な種々の段階、及びクライアントをリストアする後続の段階を制御するためのソフトウエアモジュールのアーキテクチャを検討している。特に、Ｖｅｒｉｔａｓの解決策では、バックアップ動作の制御と管理のためのサーバ、クライアントのリストア段階の制御のためのサーバ、リストアのために必要なプログラム及び設定をクライアントに与えるサーバ、及び最後にリモート・ブーティングの管理のためのサーバを含めて、個別の各機能面について様々なサーバが使用される。
【０００８】
別の従来技術の解決策は、標題「Cisco Network Boot Installation and Configuration Guide, Release 3.1」の論文（本特許出願の出願日時点ではＵＲＬ：http://www.cisco.com/en/US/products/hw/ps4159/ps2160/products_installation_and_configuration_guide_book09186a00801a45bO.htmlにてインターネットからダウンロードで入手可能）に記載のシスコ・ネットワーク・ブート・システムであり、オペレーティングシステム、サーバ上のアプリケーション及びデータを含めてシステムイメージ全体のコピーを作る。バックアップはネットワーク管理者によって相互に実行される。シスコの解決策は、複製を行なったプライマリサーバと同じハードウエアの特徴を有するという条件で、ネットワーク上でブート手順を遠隔で実行する可能性を与える。したがって、回復サーバはネットワークからシステムイメージの遠隔コピーをリストアし、プライマリサーバにより以前に保証されたサービスを再提供することができる。
【０００９】
米国特許公開ＵＳ２００４／０１５３６９８Ａ１には、損傷又は破壊した通信ネットワーク要素のサービスについて障害に対する準備及び修復をするシステム及び方法が提供されている。ネットワーク要素のための障害バックアップをするコンピュータ実行方法は、複数のネットワーク要素との接続性を得ることを含む。複数のコンピュータ読み取り可能なサービス連続性データをネットワーク要素のローカルメモリに生成するコンピュータルーチンを呼び出すために、ホストコンピュータは１つ以上の指令をネットワーク要素に送信できる。ネットワーク要素の障害回復のためにコンピュータ実行可能な構成要素から成る自動システムが、障害バックアップ動作のために指定された複数のネットワーク要素を選択するように構成されたコンピュータ実行可能なコントローラ構成要素を含む。コンピュータ実行可能なエンジン構成要素は、前記複数のネットワーク要素への接続性を得るよう構成される共に、前記ネットワーク要素の各々に対してサービス連続性データを複製するために１つ以上の指令をネットワーク要素に送信するよう構成される。
【００１０】
米国特許公開ＵＳ２００４／００７８３９７Ａ１では、ファイルシステム障害回復技術が、自動監視、故障検出及び第１指定ターゲットから指定グループの第２指定ターゲットの一つへの多段階フェイルオーバーを提供する。フェイルオーバーが所定の順序で起こるように、第２指定ターゲットに優先順位を付けてもよい。第１指定ターゲットと第２指定ターゲットとの間での情報の複製により、動作の連続性を最大限にするようにフェイルオーバーが可能となる。加えて、ユーザー特定の動作は、故障検出及び／又はフェイルオーバー動作及び／又はフェイルバック動作のすぐあとで開始できる。
【特許文献１】米国特許公開ＵＳ２００４／０１５３６９８Ａ１
【特許文献２】米国特許公開ＵＳ２００４／００７８３９７Ａ１
【発明の概要】
【発明が解決しようとする課題】
【００１１】
発明の目的及び概要
出願人は、障害発生の後にシステムをリストアする際に、クライアントが好ましくは良好なＲＰＯ及びＲＴＯ値を維持しつつも設定を手動で変えて回復サイトの回復サーバにアクセスする必要がなく、ネットワーク要素のリストアとは独立にクライアントがサービスにアクセスできることを保証するという問題が存在することに気付いた。
【課題を解決するための手段】
【００１２】
出願人は、この問題は障害回復を実行する請求項１の方法により解決できることを見いだした。
【００１３】
特に、出願人は、この問題はクライアントを回復サーバにルーティングする自動再ルーティング機構を提供することによって解決できることを見いだした。さらに、サーバのデータ及び設定を最後のトランザクションに常に一致させることができるミラーリング手順を介するデータ複製段階のための自動制御・管理機構を提供することによってこの問題を解決できることを見いだした。
【００１４】
本発明の別の態様は、障害回復を実行する請求項１２に記載のシステムに関する。
【００１５】
本発明の別の態様は、少なくとも１つのコンピュータのメモリにロード可能であると共に、コンピュータ上で実行するとき本発明の方法の工程を実行するためのソフトウエアコード部分を含んでいるコンピュータプログラムプロダクトに関する。ここで用いられているように、このようなコンピュータプログラムプロダクトというときには、コンピュータシステムを制御して本発明の方法の実行を整合させるための命令を含んだコンピュータ読み出し可能媒体をいうのと等価である。「少なくとも１つのコンピュータ」というのは、明らかに本発明を分散／モジュール方式で実装する可能性を強調するものである。
【００１６】
本発明のさらに好ましい態様が独立請求項及び以下の明細書において記載される。
【００１７】
本発明をさらに良く理解するために、単なる例であって限定するものと解釈すべきでない好ましい態様を、添付図面を参照して以下で説明する。
【図面の簡単な説明】
【００１８】
【図１】本発明に従って障害回復を実行するためのシステム図である。
【図２】図１の生産サイトの詳細システム図である。
【図３】広域ネットワークの詳細図である。
【図４】回復制御サーバの詳細図である。
【図５】正常な動作状態の期間におけるネットワークトラヒックのフローを示す。
【図６】障害回復の状況でのネットワークトラヒックのフローを示す。
【図７】フェイルバック状況でのネットワークトラヒックのフローを示す。
【図８】本発明を実装するための方法のフローチャートである。
【発明を実施するための形態】
【００１９】
本発明の好ましい態様の詳細な説明
図１は生産サイト５２、回復サイト５４、生産サイトと回復サイトとの間に接続されたネットワーク５６、及びエクストラネットクライアント５８を含んだシステム５０の図である。生産サイトは１つ以上のアプリケーションサーバ６２に接続されたストレージ６０を含むことができる。例えばイーサネットスイッチ及びＩＰルータを含み得るネットワーク６６を介してアプリケーションサーバ６２にアクセスするために、１つ以上のイントラネットクライアント６４が使用される。ボックス６６にはまた、認証システム、ファイアウォール又はアプリケーションサーバへのアクセスを阻止する侵入検出システムを含み得るセキュリティデバイスも示されている。リモートストレージボリューム上のアプリケーションサーバのローカルイメージの同期複製を実行するために、ミラーリングソフトウエアモジュール６８が用いられる。このような同期複製によって、ストレージ６０上に置かれたデータが最後のトランザクションまで回復サイト５４上にて保持されたコピーと一致することが保証される。また、最後のトランザクションがサーバの設定に対する損傷を引き起こした場合に、前にセーブされた安定なイメージに戻ることができるように、システムの安定な動作条件に対応したシステムのイメージをミラーリングソフトウエアモジュールがセーブすることも望ましい。
【００２０】
回復サイト５４は１つ以上の回復サーバ７８、ネットワーク・セキュリティデバイス８０、ストレージエリアネットワーク（ＳＡＮ）デバイス８２、及び回復制御サーバ８４を含むことができる。回復サーバ７８は障害が発生した場合にアプリケーションサーバ６２を模倣するよう構成される。障害が発生した場合にアプリケーションサーバ６２に最も密接に関連したプールの一つを使用できるように、様々なハードウエアの特徴を有する回復サーバのプールを提供することが望ましい。ＳＡＮデバイス８２はミラーリングソフトウエアモジュール６８から提供されるミラーデータを記憶する。ネットワーク・セキュリティデバイス８０は生産サイトのネットワーク・セキュリティデバイス６６と同じ機能を回復サイト５４のために実行する。回復制御サーバ８４は、それらのアクセス可能性を監視するよう管理された各アプリケーションサーバ６２に対して周期的なリクエスト（キープアライブ）を実行する。このようにして、回復制御サーバ８４は生産サイト５２に問題があるか否かを監視できる。加えて、回復制御サーバ８４は、１つ以上のアプリケーションサーバ６２からミラーリングソフトウエア６８を介して回復サイト５４のＳＡＮストレージ８２へのストレージフローを監視してもよい。例えばポーリングなどによって回復制御サーバ８４から生産サイト５２を監視するのに多くの技術を使用できる。後にさらに説明するように、回復制御サーバ８４はまた、生産サイトで問題が検出された場合に生産サイト５２から回復サイト５４への自動切替えを制御する。その際、問題が検出されたアプリケーションサーバ６２に最も密接に関連している利用可能なサーバのプールから回復サーバ７８の一つを選択する必要があるかもしれない。加えて、回復制御サーバ８４は、エクストラネットクライアント５８及びイントラネットクライアント６４が回復サーバ７８に自動的かつシームレスにアクセスできるように必要なネットワーク５６、６６を自動的に再設定する。最後に、アプリケーションサーバ６２がリストアされると共にＳＡＮデバイス８２からのデータがコピーされて生産サイト５２に戻される必要がある場合に、回復制御サーバ８４はフェイルバック条件を自動的に管理できる。
【００２１】
図２は可能性のある生産サイト５２のさらに詳細な例を示す。アプリケーションサーバ６２はシステムイメージ１００を含む。システムイメージ１００はオペレーティングシステム１０２、アプリケーション１０４の一組、及びオペレーティングシステムとアプリケーションが操作するデータ１０６を含む。大容量ストレージ６０はデータ１０６がセーブされるローカル記憶デバイスを含む。記憶イニシエータ１１０もまたアプリケーションサーバ６２上に存在する。記憶イニシエータ１１０は、ネットワークインフラストラクチャー（例えば、ＬＡＮ、ＷＡＮなど）を介してアクセスできるリモートストレージボリュームにデータを転送可能にするソフトウエアモジュールである。ソフトウエアミラー６８はアプリケーションサーバ６２においてローカルイメージの同期複製を実行するソフトウエアモジュールである。次に、ローカルイメージは記憶イニシエータモジュール１１０を介して回復サイト５４にて記憶される。ソフトウエアミラーモジュール６８はまた、異なる時間間隔で複数のシステムイメージを保持するように、システムイメージのスナップショットを取ることもできる。よって、最後のトランザクションを有することに加えて、異なる時間間隔にてシステムの安定なコピーを有することが可能である。このことにより、システムは異なる時間に取得した１つ以上の安定なコピーを有することができるので、システムは既知の安定な状態に戻ることができる。ソフトウエアミラー６８を用いてシステムイメージのリモートコピーが実行されるので、特定の製造業者に属する独占的な解決策からアーキテクチャが解放される。上記の種類のソフトウエアミラーモジュールは例えばインターネットＵＲＬ：http://www.veritas.com/Products/www?c=product&refId=3（本特許出願の出願日の時点で）からダウンロードにて利用できる。
【００２２】
イントラネットクライアント６４はネットワークデバイス１１２（この場合、レベル２及びレベル３デバイスとして示されている）を介してアプリケーションサーバ６２にアクセスできる。よって、ネットワークデバイス１１２は、生産サイトのパケットベースのネットワークのために使用されるデバイスであり、メトロポリタン、国内、又は国際レベルでのアクセスのために第三者のパケットベースのネットワークに接続することを可能にする。ネットワークデバイス１１２はＬＡＮ／ＭＡＮ技術、ＩＰルータなどとし得る。セキュリティデバイス１１４はエクストラネットクライアントからの無許可アクセスに対してセキュリティを提供する。例えば、セキュリティデバイスとして、ファイアウォール、侵入検出システムなどを挙げることができる。セキュリティデバイスは、任意の所望の規格（例えば、ＳＮＭＰ）やコマンドラインインターフェースを介して監視及び構成が行える。
【００２３】
図３はＷＡＮ５６をさらに詳しく示す。ＷＡＮ５６はエクストラネット５８と生産サイト５２と回復サイト５４との間の相互接続を可能にする。様々なプロトコルを使用できる。例えば、２つのサイトを相互接続すべく仮想プライベートネットワーク（ＶＰＮ）サービスを使用可能にするために、マルチプロトコル・ラベル・スイッチング（ＭＰＬＳ）プロトコルを用いることができる。ＷＡＮ５６は全体的に１２０で示された複数のネットワークスイッチングデバイスを含む。具体的には、カスタマーエッジデバイス（例えば、ネットワークをクライアントコンピュータに接続するのに用いられるルータやスイッチなどのネットワークの装置）１２２、１２４はそれぞれ生産サイト５２と回復サイト５４に配置されると共に、プロバイダーのポイント・オブ・プレゼンス（ＰｏＰ）に位置するプロバイダーエッジ（ＰＥ）ネットワークデバイス１２６、１２８、（例えば、カスタマーエッジデバイスとの接続を可能にするサービスプロバイダーのネットワークの一部であるルータ）との通信を可能にする。他のプロバイダーネットワークデバイス１３０（単にＰで示されている）はプロバイダーエッジ１２６、１２８とエクストラネット５８との間の通信を可能にする。新しいサイトを既存のＶＰＮに加えるために、プロバイダーは例えばプロビジョニングプラットホーム（プロビジョニングプラットホーム）を用いて正しい設定をＣＥ及びＰＥデバイスに与えることができる。ＭＰＬＳ ＶＰＮはＩＰレベルの接続を同じＶＰＮに属するサイトに提供することを可能にする。（仮想プライベートＬＡＮサービスなどの）より革新的な解決策は、同じＶＰＮに属するサイト間でイーサネット接続を設置することを可能にする。ＭＰＬＳ ＶＰＮ解決策のように、新しいサイトをＶＰＬＳに加えるために、プロバイダーＣＥ及びＰＥデバイスに作用するのみである。これら２つの解決策の主要な違いは、ＶＰＬＳサービスの場合にプロバイダーがカスタマーによって行われたルーティングを管理しないことである。
【００２４】
後でさらに説明するように、回復サイトの回復制御サーバ８４は、障害が発生した場合にエクストラネット５８及びイントラネットクライアント６４が回復サイト５４にアクセスできるように、ネットワークデバイス１２０を再ルーティングする能力を有する。回復制御サーバ８４は、その動作ドメイン（生産サイト及び回復サイト）に属するシステムに対する動作規則を自律的に設定し、必要ならば、ネットワークオペレータなどの第三者により一般に実行される他の制御システムとインターフェースすることによって、その直接制御の外部でシステムと相互作用できる。
【００２５】
図４は回復制御サーバ８４のさらなる詳細を示す。説明のために、ＭＰＬＳ機能と共にＷＡＮが用いられる場合を示しているが、上述したようなプライベート仮想ネットワーク解決策の設定を可能にする他のパケットベースのネットワークを使用することもできる。カスタマー情報マネージャーモジュール１５０（ＣＩＭＭ）は、リポジトリモジュール１５２内部のメタデータを取り扱うと共に、生産サイト５２のアプリケーションサーバ６２の特徴を示すソフトウエアモジュールである。リポジトリモジュール１５０に記憶された情報として下記のものを挙げることができる：
・アプリケーションサーバのルーティング計画。
・イントラネット／エクストラネットクライアントに対するアプリケーションサーバのアクセス規則。
・生産サイトのネットワークトポロジー及び生産サイトと回復サイトとの相互接続についての情報。
・アプリケーションサーバのハードウエア特徴。
・オペレーティングシステム、インストールされたソフトウエアパッケージなどに関するイメージ特徴。
・サービスについて合意されたサービス・レベル・アグリーメント。
・生産サイトのアプリケーションサーバと互換性のある特徴を有する回復サイトのサーバの可用性。
【００２６】
アプリケーションサーバ制御モジュール（ＡＳＣＭ）１５４は、生産サイト５２のアプリケーションサーバのアクセス可能性を検査するソフトウエアモジュールである。この検査は、サーバのＩＰアドレスをポーリングすること、又はサーバ６２内にインストールされたアプリケーションがアクティブであることを確認することによって実行される。制御の追加レベルは、ローカルストレージとリモートストレージとの間で同期ミラーリングプロセスを可能にするソフトウエアによって有効にされる。アプリケーションサーバ６２が設定可能なしきい値（例えば、３０秒、ただしこの時間は特定のアプリケーションに依存して変わり得る）を超える期間の間アクセスされ得ないならば、ＡＳＣＭモジュール１５４が障害回復手順を起動するためのリクエストを行なう。
【００２７】
ストレージゲートウエイ制御モジュール（ＳＧＣＭ）１５６はストレージゲートウエイ管理システムにリクエストを行い、下記の機能を実行できる。
・回復サイト５４のストレージデバイスに対する、アプリケーションサーバ６２によるアクセス。ストレージアクセスはアクセスコントロールリスト（ＡＣＬ）の設定を介して管理され、アクセスコントロールリスト（ＡＣＬ）は、どのサーバが所与のストレージデバイスにアクセスする許可を有しているかを特定する。
・リソースを解放又は割当てするリクエスト。この機能は、例えば所与のアプリケーションサーバに対して障害回復サービスを停止することが決定されていたという理由で、予め割り当てられたリソースを解放するリクエストを行なうことを可能にし、又は逆に言えば新しいストレージリソースを割り当てることを可能にする。この機能は、カスタマーにより署名されたＳＬＡについての情報を更新すると共に、リポジトリ１５２に保持される。
・フェイルバック条件における複製プロセスの管理。障害回復手順の後、この機能は、回復サイト５４の回復サーバ７８によりローカルで使用されるデータのコピーを生産サイト５２のストレージボリューム上で実行可能にする。データが生産サイトにて首尾一貫した方法にてリストアされた後は、初期動作条件に戻ることができ、この初期動作条件では、イントラネット及びエクストラネットクライアントによりアクセスされるサービスが生産サイトのアプリケーションサーバにより公開される。
・割り当てられたリソースの使用ステータスの検査。この機能により、ストレージデバイスの効果的な活用についての統計値を得ることができると共に、新しいデバイス（回復サイトのプールのための処理及びストレージリソース）の取得を前もって評価することができる。
【００２８】
プロビジョニングプラットホーム制御モジュール（ＰＰＣＭ）１５８は、プロビジョニングプラットホームに対するリクエストを取り扱うソフトウエアモジュールである。ネットワークデバイスの供給業者は、プログラミングメタ言語において受信したリクエストをネットワークデバイスに与えられる設定に翻訳可能にするプロビジョニングプラットホームを提供する。ＰＰＣＭ１５８は生産サイト５２と回復サイト５４とを相互接続するネットワークのトポロジーに基づいてこれらのリクエストを実行する。プロビジョニングシステムは、それらが取り扱うネットワークインフラストラクチャーのトポロジー的記述と、ネットワークの所望の最終状態の記述とに基づいて、デバイスに与えられるべき設定指令を自動的に生成する。これらのリクエストは例えば以下のモードにて行なうことができる。
【００２９】
静的モード：プロビジョニングシステムにリクエストをするために必要な情報がカスタマーリポジトリ内部に予め割り当てられる。故障が生じた場合、情報がデータベースから抽出され、方式に従って調製され、プロビジョニングシステムに送られる。
【００３０】
動的モード：プロビジョニングシステムにリクエストをするために必要な情報がプロビジョニングシステムと制御モジュールとの間の相互作用を通じて動的に得られる。この場合、必ずしもデータベースにおいて情報を予め構成する必要はない。
【００３１】
障害回復制御モジュール（ＤＲＣＭ）１６０は、アプリケーションサーバ制御モジュール１５４により知らされた故障の発生に応じて障害回復プロセスを自動化することを扱うソフトウエアモジュールである。このモジュールはカスタマーリポジトリ１５２に含まれる情報に従って以下の手順を起動できる。
・生産サイト５２のネットワークのトポロジー及び生産サイト５２と回復サイト５４との相互接続に関する情報を収集する目的での、カスタマー情報マネージャーモジュール１５０との相互作用。
・生産サイト５２にて設定されたルーティング計画を回復サイト５４に移動させるための、プロビジョニングプラットホーム制御モジュール１５８へのメッセージの送信。この段階はカスタマーサイトとプロバイダーサイトに存在するＣＥデバイスの設定、及び対応するＰＥデバイスの設定についての変更を含む。
・回復サイト５４内のＳＡＮデバイス８２にセーブされた最近のシステムイメージを識別する目的での、ストレージゲートウエイ制御モジュール１５６との相互作用。
・ディスクレス起動の時に回復サイト５４のサーバプールにおける指定回復サーバが生産サイト５２のアプリケーションサーバ６２と同じＩＰアドレスを受信するための、回復サイトのＤＨＣＰ（ダイナミックホストコンフィグレーションプロトコル）サーバの設定。
・アプリケーションサーバ６２と互換性のある特徴を有する回復サイト５４のリソースプールに属するハードウエアシステムを識別するための、カスタマー情報マネージャーモジュール１５０との相互作用。
・回復サーバ７２上でのディスクレス起動手順を有効にする。例えば、インターネットでＵＲＬ：http://www.cisco.com/en/US/products/hw/ps4159/ps2160/products_installation_and_configuration_guide_book09186a00801a45b0.html（本特許出願の出願日の時点で）からダウンロードで利用可能な種類のディスクレス起動手順が使用できる。
【００３２】
モジュール１５０、１５４、１５６、１５８、及び１６０は回復制御サーバ８４内にあるＣＰＵ１７２により実行される。加えて、これらのモジュールは通信のためにインターフェースモジュール１６２と相互作用する。インターフェースモジュール１６２は、キープアライブモジュール１６４、ストレージゲートウエイアダプタ１６６、プロビジョニングプラットホームアダプタ１６８、及びストレージプラットホームアダプタ１７０を含めて様々なアダプタを含む。
【００３３】
アプリケーションサーバ６２が生産サイト５２にてリストアされるとき、手動又は自動でフェイルバック手順を起動して、ネットワーク設定を故障前の状態に戻して割り当てられたリソースを解放することができる。フェイルバック手順は、回復モードに関して自明の対称性を有するので、回復手順に類似のロジックに従う。
【００３４】
最初にシステムを設定するために、ソフトウエアミラー６８がアプリケーションサーバ６２上にインストールされて同期若しくは非同期ミラーリング又は周期的な複製を実行する。回復制御サーバ８４はいくつかの設定動作を実行する。例えば、ＳＧＣＭ１５６は生産サイト５２のストレージ６０とアプリケーションサーバ６２のＩＰアドレスとを関連付けるための設定を実行する。ＰＰＣＭ１５８はリポジトリモジュール１５２内部にロードされるべきネットワーク設定のためにプロビジョニングシステムに対してリクエストを行なう。ロードされる情報は以下のものを含み得る：
生産サイト５２と回復サイト５４との接続を確保するために使用されるＣＥ-ＰＥネットワークデバイスＩＤ。障害回復に伴うすべてのサイトから回復サイトへのアクセス可能性を確保するのに用いられるＣＥ-ＰＥネットワークデバイスＩＤ。障害回復の場合に回復サイトに移動するために生産サイトにて用いられるルーティング計画。サービスへのアクセス規則を定義する生産サイトのＣＥデバイス上で設定されたアクセスコントロールリストが、エクストラネット接続を介してアプリケーションサーバにより利用可能にされる。
【００３５】
回復制御サーバ８４におけるＣＩＭＭ１５０は、アプリケーションサーバ６２及び生産サイトに関する情報をリポジトリモジュール１５２に加える。このような情報としては、サーバのハードウエア特徴（例えば、システムイメージのサイズ、ネットワークインターフェースの数など）、アプリケーションサーバのソフトウエア特徴、及びＰＰＣＭ１５８から発せられる情報が挙げられる。
【００３６】
最後に、ＡＳＣＭ１５４はサーバの可用性を調べるために周期的なポーリングを起動する。もしサーバが応答しないならば、障害回復手順を起動する。
【００３７】
図５は正常な動作条件でのシステムを示す。ＡＳＣＭ１５４はアプリケーションサーバが矢印１８０により示されるようにアクティブであることを調べる。また、アプリケーションサーバのシステム管理者はアプリケーションサーバプラットホーム上で為されたハードウエアの変更を障害回復サービスの管理者に知らせることが望ましい。その目的は、リポジトリ１５２に保持された情報を最新のものに維持すると共に、障害回復手順が起動された場合に正しい回復サーバを選択可能にすることである。矢印１８２で示されるように、通常運転中、エクストラネットクライアント５８は生産サイト５２のアプリケーションサーバ６２にアクセスする。情報はサーバ６２上で更新されているので、ソフトウエアミラー６８は情報が矢印１８０で示されるように回復サイト５４でも記憶されることを保証する。
【００３８】
設定可能なしきい値を超えた時間間隔の間ＡＳＣＭ１５４がアプリケーションサーバ６２からＡＣＫメッセージを受信しない場合に、障害回復手順が起動される。ＤＲＣＭ１６０を用いて、回復制御サーバ８４は以下の手順を起動できる。
１）生産サイトのネットワークのトポロジー及び生産サイトと回復サイトとの相互接続に関する情報を収集する目的で、ＣＩＭＭ１５０と相互作用する。
２）生産サイトにて構成されたルーティング計画を回復サイトに移動させるために、メッセージ（マイグレートネットワーク（MigrateNetwork））をＰＰＣＭに送信する。この段階はカスタマーサイト及びプロバイダーサイトのＣＥ-ＰＥデバイスの設定についての変更を伴う。
３）回復サイト内のストレージシステムにセーブされた最近のシステムイメージを識別する目的で、ＳＧＣＭと相互作用する（複製機構が用いられる場合には最近のものに一致し得る）。
４）起動（ディスクレス起動）される際に回復サーバを有効にして生産サイトのアプリケーションサーバと同じＩＰアドレスを受信するために、回復サイトのＤＨＣＰサーバの設定を行なう。
５）アプリケーションサーバと互換性のある特徴を有する回復サイトのリソースプールに属するハードウエアシステムを識別するために、ＣＩＭＭと相互作用する。
６）ディスクレス起動手順を可能にする：この段階では、ＧＵＩは人間のオペレータに待機中のハードウエアリソースプールから選択された回復サーバを始動できることを知らせる。
【００３９】
内部ストレージ（ディスクレス）を有していないかもしれない回復サーバは、アプリケーションサーバのシステムイメージ（ＩＰアドレス、ボリューム名、ＬＵＮなど）を含んだストレージシステムにアクセスすることに関連したＩＰアドレスと情報とを得るために、ＤＨＣＰサーバにリクエストを行なう。いったんこの情報が受信されると、回復サーバはネットワーク上でディスクレス起動を実行できる。フィニッシュを起動するとき、回復サーバは最後のトランザクションまで元のアプリケーションサーバに一致している。あらゆるイントラネット、エクストラネット又はインターネットクライアントは、障害回復手順で設定された接続を用いてＴＣＰ／ＩＰを介して回復サーバのリストアされたサービスにアクセスできる。
【００４０】
図６は障害回復手順が開始された後のデータフローを示す。矢印１８８で示されるように、エクストラネットクライアントが生産サイト５２にアクセスしようと試みるとき、リクエストが自動的に回復サイト５４に再ルーティングされる。このことはエクストラネットユーザーに対してトランスペアレントに行われ、エクストラネットユーザーが回復サイトについて異なるネットワークアドレスをタイピングする必要はない。よって、エクストラネットクライアントの観点からは、たとえ実際には回復サイトにアクセスされていても、生産サイトに依然としてアクセスされている。
【００４１】
図７はフェイルバック条件を示す。フェイルバック手順は障害回復手順の後に初期状態に戻ることを可能にする。生産サイト５２のアプリケーションサーバ６２がリストアされた後も、すべてのサービスが回復サイトにより提供される期間が依然として存在する。
【００４２】
フェイルバック手順は上述した正常動作条件に戻るために以下の段階を含むことができる。
１）ＳＧＣＭ１５６が、矢印１９０で示すように生産サイト上で回復サイトのデータの一致したコピーを行なうために、逆複製手順を起動する。
２）回復サイトにて構成されたルーティング計画を生産サイトに移動させるために、ＤＲＣＭがメッセージ（マイグレートネットワーク（MigrateNetwork））をＰＰＣＭに送信する。この段階はカスタマーサイト及びプロバイダーサイトのＣＥ-ＰＥデバイスの設定についての変更を伴う。
３）生産サイトでのサービスが再開され、クライアントが元のアプリケーションサーバ６２にアクセスする。
４）回復サイト５４にて回復サーバ７８により用いられるハードウエアリソースが解放され（自由なリソースプールに戻される）。
５）同期／非同期ミラーリング（又は複製）手順が再起動される。
【００４３】
図８は本発明を実行する方法のフローチャートを示す。プロセスブロック２１０では、回復サイトがポーリングにより生産サイトでの問題を検出する。プロセスブロック２１２では、生産サイトへのアクセスの試みが回復サイトにルーティングされるように、回復サイトが自動的にネットワークの再設定を実行する。このようなリクエストはエクストラネット又はイントラネットリクエストに由来し得る。
【００４４】
本発明の利点は上記説明から明らかである。
【００４５】
特に、利点の一つは、ＲＰＯ及びＲＴＯパラメータがミラーリングプロセスにより実行される複製によって最適化されることである。
【００４６】
別の利点は、本発明は生産又は回復サイトで採用されるソフトウエア／ハードウエア解決策に依存しないことである。
【００４７】
さらに別の利点は、クライアントを回復サーバにルーティングする自動再ルーティングである。
【００４８】
最後に、本発明について多くの変更及び変形が為し得ることは明らかであるが、すべて本発明の範囲に存する。
【００４９】
例えば、本解決策を拡張及び変更して、それを達成する個々の構成要素に作用させるか、又は既存の構成要素を当該技術における制御アーキテクチャに統合することができる。
【００５０】
特に、生産サイトでは、同期／非同期ミラーリングソフトウエアを提供する構成要素は特定の技術に限定されない。それらはホストベース、ネットワークベース、又はアレイベースの仮想化機構、及びソフトウエアモジュール又は特定のハードウエア構成要素により実現できる。
【００５１】
さらに、ここに記載した「障害」とは、生産サイトが何がしかの理由で機能していないことを意味する。これは実際の障害が生ぜざるを得なかったことを意味しない。
【００５２】
さらにまた、生産サイトと回復サイトとの間の相互接続ネットワークでは、リモートサイトへのミラーリング／複製フローのために用いられるプロトコルは、回復サイトのストレージにて生産サイトで行われるのと同じ書き込みを再生する機能を実行する限りは、標準的又は独占的なプロトコル（例えば、ＳＣＳＩ）とし得る。
【００５３】
加えて、回復サイトでは、ネットワーク上で起動するための機構は、生産サイトにてデータにアクセスするのに用いられるか又は２つのサイト間での相互接続において用いられるプロトコルとは異なるトランスポートプロトコル（例えばファイバーチャンネル又はｉＳＣＳＩ）を回復サイトにてローカルに使用できる。さらに、回復制御サーバは、同じデバイス内にすべてを一緒に構築するか、又は要求される基本機能を達成する他のデバイスの特徴若しくは機能性を利用する分散方式にて構築できる。これらの機能の制御ロジックは、独立のシステムで実現できるか、又は上記デバイスの一つにおいて追加機能として統合できる。特に、回復サイトでアプリケーションサーバを再開した後に提供されるサービスのネットワーク再ルーティングは、別のシステムにより部分的に又は完全に制御され、手持ちのシステムのインテリジェンスモジュールに統合され、接続プロバイダーに関するエクストラネット／イントラネットＶＰＮサイトの動的管理に委ねられ得る。この再ルーティング機構は、２つのサイト間及びクライアントと生産サイトとの間で用いられる特定の接続性に基づいて様々な代替物（ＭＰＬＳ ＶＰＮ又は積み重ね可能なＶＬＡＮ／ｄｏｔｌｑなど）を使用できる。同様に、回復制御サーバ内部のストレージゲートウエイの構成要素は、ゲートウエイ又はストレージスイッチなどの市販プロダクトに既に存在するベースモジュールを統合することによって実現できる。
【００５４】
プライマリサイトを正常な条件にリストアすること（フェイルバック）を更に最適化するために、本解決策の回復及びリストア機構は、動的又は動的でない特定のＱｏＳ機構とすることもでき、これは回復及びリストア段階における動作を加速させるためにリストア活動の時間窓を小さくして、正常な動作条件において利用可能なものよりも広い伝送帯域を有する相互接続を２つのサイト間に提供する。
【００５５】
予想されるように、回復サイトの回復サーバによって特に個々の回復サーバ上に形成された処理用ハードウエアリソースを最適化するために、本解決策により保護されるアプリケーションサーバのハードウエア特徴をリソースプールを構成するシステムのものから切り離すべく、特定のソフトウエアモジュールをインストールして物理リソースを仮想化できる。
【００５６】
このことにより、このような回復サーバを生産サイトのプライマリサーバのハードウエアと互換性を有せしめると共に、より効率的なリソースの割り当てを保証することが更に容易になる。このようにして、システムの物理ドライバを仮想化する機能のお陰で（１：１仮想化）、異なるハードウエアが同じ物理設定上でエミュレートされるのが可能にされ、最新式の障害回復サービスは生産サイトのアプリケーションサーバのものと同じハードウエア設定を有するサーバを採用することから解放され得る。加えて、１つより多いアプリケーションサーバイメージに対して同じハードウエアリソースを同時に利用するために仮想化ソフトウエアを使用することもできる（ｎ：１仮想化）。
【符号の説明】
【００５７】
５０ 本発明のシステム
５２ 生産サイト
５４ 回復サイト
５６ 生産サイトと回復サイトとの間に接続されたネットワーク
５８ エクストラネットクライアント
【特許請求の範囲】
【請求項１】
パケットベースのネットワーク（５６）により接続される生産サイト（５２）と回復サイト（５４）とを含むアーキテクチャにおいて障害回復を実行する方法であって、
生産サイト（５２）の問題を検出する工程と；
問題の検出に応じて、パケットベースのネットワーク（５６）を介して生産サイト（５２）にアクセスする試みが回復サイト（５４）にルーティングされるように、パケットベースのネットワーク（５６）を自動的に再設定する工程と；
を含むことを特徴とする方法。
【請求項２】
少なくとも生産サイト（５２）の一部で生じた変更が自動的に回復サイト（５４）にコピーされるように、少なくとも前記生産サイト（５２）の一部をミラーリングする工程（１８０）を更に含む、請求項１に記載の方法。
【請求項３】
所定の時間間隔で回復サイト（５４）から生産サイト（５２）をポーリングする工程（１８４）を更に含む、請求項１又は２に記載の方法。
【請求項４】
生産サイトの問題の解決を検出すると共に、回復データを回復サイト（５４）から生産サイト（５２）にコピーする（１９０）ことによって生産サイトを自動的にリストアする、請求項１〜３のいずれか一項に記載の方法。
【請求項５】
生産サイトをリストアした後、生産サイト（５２）へのアクセスを可能にするようにネットワーク（５６）を自動的に再設定する、請求項４に記載の方法。
【請求項６】
生産サイトのサーバ（６２）のネットワークアドレスを用いてイントラネットコンピュータ（６４）及びエクストラネットコンピュータ（５８）から回復サイト（５４）の回復サーバ（７８）にアクセスする工程を含む、請求項１〜５のいずれか一項に記載の方法。
【請求項７】
前記問題を検出する工程が、
生産サイトのサーバ（６２）をポーリングする工程と；
サーバ（６２）からの応答を所定の期間待つ工程と；
前記所定の期間が終了すると障害回復手順を開始する工程と；
を含む請求項１〜６のいずれか一項に記載の方法。
【請求項８】
回復サイト（５４）の回復サーバ（７８）を回復サーバのプールから選択する工程を更に含む、請求項１〜７のいずれか一項に記載の方法。
【請求項９】
前記選択する工程が、生産サイト（５２）のサーバ（６２）に関連したハードウエア特徴を検索すると共に、該特徴を回復サイトのプールにある回復サーバ（７８）のハードウエア特徴とできるだけ厳密に照合する工程を含む、請求項８に記載の方法。
【請求項１０】
前記ネットワーク（５６）を再設定する工程が、生産サイト（５２）のネットワークアドレスを有するリクエストを回復サイト（５４）に再ルーティングする工程を含む、請求項１〜９のいずれか一項に記載の方法。
【請求項１１】
生産サイト（５２）のサーバ（６２）の状態の安定なコピーと、最後のトランザクションまでの生産サイトのサーバ（６２）のコピーとの両方を回復サイトに記憶する工程を更に含む、請求項１〜１０のいずれか一項に記載の方法。
【請求項１２】
パケットベースの通信ネットワーク（５６）によって接続される生産サイト（５２）と回復サイト（５４）とを含むと共に、該ネットワーク（５６）において障害回復を実行するためのシステム（５０）であって、
回復サイト（５４）に設置された回復制御サーバ（８４）を備え、回復制御サーバ（８４）が、
生産サイト（５２）の問題を検出することができる第１のモジュール（１５４）と；
問題を検出すると、生産サイト（５２）へのアクセスの試みが回復サイト（５４）にルーティングされるように、前記ネットワークを自動的に再設定することができる第２のモジュール（１６０）と；
を含むことを特徴とするシステム。
【請求項１３】
生産サイト（５２）に設置されると共にミラーリングモジュール（６８）を備えたアプリケーションサーバ（６２）を更に含み、ミラーリングモジュール（６８）が生産サイトのアプリケーションサーバのイメージの同期複製を回復サイト（５４）に対して実行する、請求項１２に記載のシステム。
【請求項１４】
回復サイト（５４）に備えられると共に生産サイトのアプリケーションサーバ（６２）についての情報を記憶するデータベース（１５２）を更に含む、請求項１３に記載のシステム。
【請求項１５】
前記アプリケーションサーバ（６２）についての情報が、
・アプリケーションサーバのルーティング計画；
・イントラネット及びエクストラネットクライアントに対するアプリケーションサーバのアクセス規則；
・アプリケーションサーバのハードウエア特徴；及び
・イメージ特徴；
のうちの１つ以上を含む、請求項１４に記載のシステム。
【請求項１６】
パケットベースの通信ネットワーク（５６）により接続される生産サイト（５２）と回復サイト（５４）とを含んだアーキテクチャであって、障害回復を実行するための請求項１２〜１６のいずれか一項に記載のシステム（５０）を含むことを特徴とするアーキテクチャ。
【請求項１７】
パケットベースの通信ネットワーク（５６）を介して生産サイト（５２）に接続される回復サイト（５４）であって、
回復制御サーバ（８４）を備え、回復制御サーバ（８４）は、
生産サイト（５２）の問題を検出することができる第１のモジュール（１５４）と；
問題を検出すると、生産サイト（５２）にアクセスする試みが回復サイト（５４）にルーティングされるように前記ネットワークを自動的に再設定することができる第２のモジュール（１６０）と；
を含むことを特徴とする回復サイト。
【請求項１】
パケットベースのネットワーク（５６）により接続される生産サイト（５２）と回復サイト（５４）とを含むアーキテクチャにおいて障害回復を実行する方法であって、
生産サイト（５２）の問題を検出する工程と；
問題の検出に応じて、パケットベースのネットワーク（５６）を介して生産サイト（５２）にアクセスする試みが回復サイト（５４）にルーティングされるように、パケットベースのネットワーク（５６）を自動的に再設定する工程と；
を含むことを特徴とする方法。
【請求項２】
少なくとも生産サイト（５２）の一部で生じた変更が自動的に回復サイト（５４）にコピーされるように、少なくとも前記生産サイト（５２）の一部をミラーリングする工程（１８０）を更に含む、請求項１に記載の方法。
【請求項３】
所定の時間間隔で回復サイト（５４）から生産サイト（５２）をポーリングする工程（１８４）を更に含む、請求項１又は２に記載の方法。
【請求項４】
生産サイトの問題の解決を検出すると共に、回復データを回復サイト（５４）から生産サイト（５２）にコピーする（１９０）ことによって生産サイトを自動的にリストアする、請求項１〜３のいずれか一項に記載の方法。
【請求項５】
生産サイトをリストアした後、生産サイト（５２）へのアクセスを可能にするようにネットワーク（５６）を自動的に再設定する、請求項４に記載の方法。
【請求項６】
生産サイトのサーバ（６２）のネットワークアドレスを用いてイントラネットコンピュータ（６４）及びエクストラネットコンピュータ（５８）から回復サイト（５４）の回復サーバ（７８）にアクセスする工程を含む、請求項１〜５のいずれか一項に記載の方法。
【請求項７】
前記問題を検出する工程が、
生産サイトのサーバ（６２）をポーリングする工程と；
サーバ（６２）からの応答を所定の期間待つ工程と；
前記所定の期間が終了すると障害回復手順を開始する工程と；
を含む請求項１〜６のいずれか一項に記載の方法。
【請求項８】
回復サイト（５４）の回復サーバ（７８）を回復サーバのプールから選択する工程を更に含む、請求項１〜７のいずれか一項に記載の方法。
【請求項９】
前記選択する工程が、生産サイト（５２）のサーバ（６２）に関連したハードウエア特徴を検索すると共に、該特徴を回復サイトのプールにある回復サーバ（７８）のハードウエア特徴とできるだけ厳密に照合する工程を含む、請求項８に記載の方法。
【請求項１０】
前記ネットワーク（５６）を再設定する工程が、生産サイト（５２）のネットワークアドレスを有するリクエストを回復サイト（５４）に再ルーティングする工程を含む、請求項１〜９のいずれか一項に記載の方法。
【請求項１１】
生産サイト（５２）のサーバ（６２）の状態の安定なコピーと、最後のトランザクションまでの生産サイトのサーバ（６２）のコピーとの両方を回復サイトに記憶する工程を更に含む、請求項１〜１０のいずれか一項に記載の方法。
【請求項１２】
パケットベースの通信ネットワーク（５６）によって接続される生産サイト（５２）と回復サイト（５４）とを含むと共に、該ネットワーク（５６）において障害回復を実行するためのシステム（５０）であって、
回復サイト（５４）に設置された回復制御サーバ（８４）を備え、回復制御サーバ（８４）が、
生産サイト（５２）の問題を検出することができる第１のモジュール（１５４）と；
問題を検出すると、生産サイト（５２）へのアクセスの試みが回復サイト（５４）にルーティングされるように、前記ネットワークを自動的に再設定することができる第２のモジュール（１６０）と；
を含むことを特徴とするシステム。
【請求項１３】
生産サイト（５２）に設置されると共にミラーリングモジュール（６８）を備えたアプリケーションサーバ（６２）を更に含み、ミラーリングモジュール（６８）が生産サイトのアプリケーションサーバのイメージの同期複製を回復サイト（５４）に対して実行する、請求項１２に記載のシステム。
【請求項１４】
回復サイト（５４）に備えられると共に生産サイトのアプリケーションサーバ（６２）についての情報を記憶するデータベース（１５２）を更に含む、請求項１３に記載のシステム。
【請求項１５】
前記アプリケーションサーバ（６２）についての情報が、
・アプリケーションサーバのルーティング計画；
・イントラネット及びエクストラネットクライアントに対するアプリケーションサーバのアクセス規則；
・アプリケーションサーバのハードウエア特徴；及び
・イメージ特徴；
のうちの１つ以上を含む、請求項１４に記載のシステム。
【請求項１６】
パケットベースの通信ネットワーク（５６）により接続される生産サイト（５２）と回復サイト（５４）とを含んだアーキテクチャであって、障害回復を実行するための請求項１２〜１６のいずれか一項に記載のシステム（５０）を含むことを特徴とするアーキテクチャ。
【請求項１７】
パケットベースの通信ネットワーク（５６）を介して生産サイト（５２）に接続される回復サイト（５４）であって、
回復制御サーバ（８４）を備え、回復制御サーバ（８４）は、
生産サイト（５２）の問題を検出することができる第１のモジュール（１５４）と；
問題を検出すると、生産サイト（５２）にアクセスする試みが回復サイト（５４）にルーティングされるように前記ネットワークを自動的に再設定することができる第２のモジュール（１６０）と；
を含むことを特徴とする回復サイト。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【公開番号】特開２０１２−１００３１３（Ｐ２０１２−１００３１３Ａ）
【公開日】平成２４年５月２４日（２０１２．５．２４）
【国際特許分類】
【外国語出願】
【出願番号】特願２０１１−２８１９５９（Ｐ２０１１−２８１９５９）
【出願日】平成２３年１２月２２日（２０１１．１２．２２）
【分割の表示】特願２００８−５０００５２（Ｐ２００８−５０００５２）の分割
【原出願日】平成１７年３月１０日（２００５．３．１０）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．イーサネット
【出願人】（５０３１４８２７０）テレコム・イタリア・エッセ・ピー・アー (87)
【Ｆターム（参考）】
【公開日】平成２４年５月２４日（２０１２．５．２４）
【国際特許分類】
【出願番号】特願２０１１−２８１９５９（Ｐ２０１１−２８１９５９）
【出願日】平成２３年１２月２２日（２０１１．１２．２２）
【分割の表示】特願２００８−５０００５２（Ｐ２００８−５０００５２）の分割
【原出願日】平成１７年３月１０日（２００５．３．１０）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．イーサネット
【出願人】（５０３１４８２７０）テレコム・イタリア・エッセ・ピー・アー (87)
【Ｆターム（参考）】
[ Back to top ]