JP2008533573A - 障害回復アーキテクチャー - Google Patents

Abstract

パケットベースのネットワークにおける障害回復のための方法及びシステム。ネットワーク（５０）はパケットベースのネットワーク（５６）により接続された生産サイト（５２）と回復サイト（５４）とを含む。生産サイト（５２）のミラーリングソフトウエア（６８）は、生産サイトで発生した最後のトランザクションまで回復サイト（５４）を最新のものに保つ。回復制御サーバー（８４）は障害状態又は他の故障を検出するために生産サイトに対しポーリングする。生産サイト（５２）に問題を検出すると、生産サイト（５２）にアクセスする試みが回復サイト（５４）にルーティングされるように回復制御サーバー（８４）がネットワーク（５６）を再設定する。

Description

一般に本発明は電気通信ネットワークに関するものであり、特に、電気通信ネットワークにおいて使用される障害回復技術に関する。

ネットワーク化されたコンピュータシステムの大衆性と利便性により、データベースによるユーザー間でのデータ共有が多くのビジネス環境において普及してきた。データベースを介した情報への集中型アクセスを行なうには、データベースの保守と管理を注意深く考慮する必要がある。さらに、回復技術はハードウエア／デバイスの故障又はアプリケーションロジックの故障の後でのデータベースの一貫性を保証することが必須である。

一般に、回復技術は損傷を受けた後にシステム又はシステムに記憶されたデータをリセットして動作可能な状態にすると共に、バックアップコピーをリストアすることによりデータベースを再構築する方法を提供する。

いずれのデータ回復システムにおいても、興味ある２つのポイントがある。
・第１は目標回復ポイント（ＲＰＯ）であり、これは元のデータとバックアップコピーとの間の最大計画相違を定義する。
・第２は目標回復時間（ＲＴＯ）であり、これはサービスの再開のための最大時間を定義する。

システムバックアップの最も単純な形式の一つとして、磁気テープ上に作られたデータのコピーを遠く離れたアーカイビング・サイトに物理的に輸送することが挙げられる。一般に、この場合にはユーザーはバックアップテープを作っている間はすべてのデータベースの活動を停止する必要がある。次に、この障害回復ではバックアップテープを用いてデータベースを回復させることを必要とする。

システムバックアップの更に最近の形式では、ネットワークの相互接続を使用して生産(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））をＰＰＣＭに送信する。この段階はカスタマーサイト及びプロバイダーサイトのＣＥ-ＰＥデバイスの設定についての変更を伴う。
３）生産サイトでのサービスが再開され、クライアントが元のアプリケーションサーバー６２にアクセスする。
４）回復サイト５４にて回復サーバー７８により用いられるハードウエアリソースが解放され（自由なリソースプールに戻される）。
５）同期／非同期ミラーリング（又は複製）手順が再起動される。

図８は本発明を実行する方法のフローチャートを示す。プロセスブロック２１０では、回復サイトがポーリングにより生産サイトでの問題を検出する。プロセスブロック２１２では、生産サイトへのアクセスの試みが回復サイトにルーティングされるように、回復サイトが自動的にネットワークの再設定を実行する。このようなリクエストはエクストラネット又はイントラネットリクエストに由来し得る。

本発明の利点は上記説明から明らかである。
特に、利点の一つは、ＲＰＯ及びＲＴＯパラメータがミラーリングプロセスにより実行される複製によって最適化されることである。

別の利点は、本発明は生産又は回復サイトで採用されるソフトウエア／ハードウエア解決策に依存しないことである。
さらに別の利点は、クライアントを回復サーバーにルーティングする自動再ルーティングである。

最後に、本発明について多くの変更及び変形が為し得ることは明らかであるが、すべて本発明の範囲に存する。
例えば、本解決策を拡張及び変更して、それを達成する個々の構成要素に作用させるか、又は既存の構成要素を当該技術における制御アーキテクチャーに統合することができる。

特に、生産サイトでは、同期／非同期ミラーリングソフトウエアを提供する構成要素は特定の技術に限定されない。それらはホストベース、ネットワークベース、又はアレイベースの仮想化機構、及びソフトウエアモジュール又は特定のハードウエア構成要素により実現できる。

さらに、ここに記載した「障害」とは、生産サイトが何がしかの理由で機能していないことを意味する。これは実際の障害が生ぜざるを得なかったことを意味しない。

さらにまた、生産サイトと回復サイトとの間の相互接続ネットワークでは、リモートサイトへのミラーリング／複製フローのために用いられるプロトコルは、回復サイトのストレージにて生産サイトで行われるのと同じ書き込みを再生する機能を実行する限りは、標準的又は独占的なプロトコル（例えば、ＳＣＳＩ）とし得る。

加えて、回復サイトでは、ネットワーク上で起動するための機構は、生産サイトにてデータにアクセスするのに用いられるか又は２つのサイト間での相互接続において用いられるプロトコルとは異なるトランスポートプロトコル（例えばファイバーチャンネル又はｉＳＣＳＩ）を回復サイトにてローカルに使用できる。さらに、回復制御サーバーは、同じデバイス内にすべてを一緒に構築するか、又は要求される基本機能を達成する他のデバイスの特徴若しくは機能性を利用する分散方式にて構築できる。これらの機能の制御ロジックは、独立のシステムで実現できるか、又は上記デバイスの一つにおいて追加機能として統合できる。特に、回復サイトでアプリケーションサーバーを再開した後に提供されるサービスのネットワーク再ルーティングは、別のシステムにより部分的に又は完全に制御され、手持ちのシステムのインテリジェンスモジュールに統合され、接続プロバイダーに関するエクストラネット／イントラネットＶＰＮサイトの動的管理に委ねられ得る。この再ルーティング機構は、２つのサイト間及びクライアントと生産サイトとの間で用いられる特定の接続性に基づいて様々な代替物（ＭＰＬＳ ＶＰＮ又は積み重ね可能なＶＬＡＮ／ｄｏｔｌｑなど）を使用できる。同様に、回復制御サーバー内部のストレージゲートウエイの構成要素は、ゲートウエイ又はストレージスイッチなどの市販プロダクトに既に存在するベースモジュールを統合することによって実現できる。

プライマリサイトを正常な条件にリストアすること（フェイルバック）を更に最適化するために、本解決策の回復及びリストア機構は、動的又は動的でない特定のＱｏＳ機構とすることもでき、これは回復及びリストア段階における動作を加速させるためにリストア活動の時間窓を小さくして、正常な動作条件において利用可能なものよりも広い伝送帯域を有する相互接続を２つのサイト間に提供する。

予想されるように、回復サイトの回復サーバーによって特に個々の回復サーバー上に形成された処理用ハードウエアリソースを最適化するために、本解決策により保護されるアプリケーションサーバーのハードウエア特徴をリソースプールを構成するシステムのものから切り離すべく、特定のソフトウエアモジュールをインストールして物理リソースを仮想化できる。

このことにより、このような回復サーバーを生産サイトのプライマリサーバーのハードウエアと互換性を有せしめると共に、より効率的なリソースの割り当てを保証することが更に容易になる。このようにして、システムの物理ドライバを仮想化する機能のお陰で（１：１仮想化）、異なるハードウエアが同じ物理設定上でエミュレートされるのが可能にされ、最新式の障害回復サービスは生産サイトのアプリケーションサーバーのものと同じハードウエア設定を有するサーバーを採用することから解放され得る。加えて、１つより多いアプリケーションサーバーイメージに対して同じハードウエアリソースを同時に利用するために仮想化ソフトウエアを使用することもできる（ｎ：１仮想化）。

本発明に従って障害回復を実行するためのシステム図である。 図１の生産サイトの詳細システム図である。 広域ネットワークの詳細図である。 回復制御サーバーの詳細図である。 正常な動作状態の期間におけるネットワークトラヒックのフローを示す。 障害回復の状況でのネットワークトラヒックのフローを示す。 フェイルバック状況でのネットワークトラヒックのフローを示す。 本発明を実装するための方法のフローチャートである。

符号の説明

５０ 本発明のシステム
５２ 生産サイト
５４ 回復サイト
５６ 生産サイトと回復サイトとの間に接続されたネットワーク
５８ エクストラネットクライアント

Claims (17)

1. パケットベースのネットワーク（５６）により接続される生産サイト（５２）と回復サイト（５４）とを含むアーキテクチャーにおいて障害回復を実行する方法であって、
   生産サイト（５２）の問題を検出する工程と；
   問題の検出に応じて、パケットベースのネットワーク（５６）を介して生産サイト（５２）にアクセスする試みが回復サイト（５４）にルーティングされるように、パケットベースのネットワーク（５６）を自動的に再設定する工程と；
   を含むことを特徴とする方法。
2. 少なくとも生産サイト（５２）の一部で生じた変更が自動的に回復サイト（５４）にコピーされるように、少なくとも前記生産サイト（５２）の一部をミラーリングする工程（１８０）を更に含む、請求項１に記載の方法。
3. 所定の時間間隔で回復サイト（５４）から生産サイト（５２）をポーリングする工程（１８４）を更に含む、請求項１又は２に記載の方法。
4. 生産サイトの問題の解決を検出すると共に、回復データを回復サイト（５４）から生産サイト（５２）にコピーする（１９０）ことによって生産サイトを自動的にリストアする、請求項１〜３のいずれか一項に記載の方法。
5. 生産サイトをリストアした後、生産サイト（５２）へのアクセスを可能にするようにネットワーク（５６）を自動的に再設定する、請求項４に記載の方法。
6. 生産サイトのサーバー（６２）のネットワークアドレスを用いてイントラネットコンピュータ（６４）及びエクストラネットコンピュータ（５８）から回復サイト（５４）の回復サーバー（７８）にアクセスする工程を含む、請求項１〜５のいずれか一項に記載の方法。
7. 前記問題を検出する工程が、
   生産サイトのサーバー（６２）をポーリングする工程と；
   サーバー（６２）からの応答を所定の期間待つ工程と；
   前記所定の期間が終了すると障害回復手順を開始する工程と；
   を含む請求項１〜６のいずれか一項に記載の方法。
8. 回復サイト（５４）の回復サーバー（７８）を回復サーバーのプールから選択する工程を更に含む、請求項１〜７のいずれか一項に記載の方法。
9. 前記選択する工程が、生産サイト（５２）のサーバー（６２）に関連したハードウエア特徴を検索すると共に、該特徴を回復サイトのプールにある回復サーバー（７８）のハードウエア特徴とできるだけ厳密に照合する工程を含む、請求項８に記載の方法。
10. 前記ネットワーク（５６）を再設定する工程が、生産サイト（５２）のネットワークアドレスを有するリクエストを回復サイト（５４）に再ルーティングする工程を含む、請求項１〜９のいずれか一項に記載の方法。
11. 生産サイト（５２）のサーバー（６２）の状態の安定なコピーと生産サイトのサーバー（６２）のコピーの両方を最後のトランザクションまで回復サイトに記憶する工程を更に含む、請求項１〜１０のいずれか一項に記載の方法。
12. パケットベースの電気通信ネットワーク（５６）によって接続される生産サイト（５２）と回復サイト（５４）とを含むと共に、該ネットワーク（５６）において障害回復を実行するためのシステム（５０）であって、
    回復サイト（５４）に設置された回復制御サーバー（８４）を備え、回復制御サーバー（８４）が、
    生産サイト（５２）の問題を検出することができる第１のモジュール（１５４）と；
    問題を検出すると、生産サイト（５２）へのアクセスの試みが回復サイト（５４）にルーティングされるように、前記ネットワークを自動的に再設定することができる第２のモジュール（１６０）と；
    を含むことを特徴とするシステム。
13. 生産サイト（５２）に設置されると共にミラーリングモジュール（６８）を備えたアプリケーションサーバー（６２）を更に含み、ミラーリングモジュール（６８）が生産サイトのアプリケーションサーバーのイメージの同期複製を回復サイト（５４）に対して実行する、請求項１２に記載のシステム。
14. 回復サイト（５４）に備えられると共に生産サイトのアプリケーションサーバー（６２）についての情報を記憶するデータベース（１５２）を更に含む、請求項１３に記載のシステム。
15. 前記アプリケーションサーバー（６２）についての情報が、
    ・アプリケーションサーバーのルーティング計画；
    ・イントラネット及びエクストラネットクライアントに対するアプリケーションサーバーのアクセス規則；
    ・アプリケーションサーバーのハードウエア特徴；及び
    ・イメージ特徴；
    のうちの１つ以上を含む、請求項１４に記載のシステム。
16. パケットベースの電気通信ネットワーク（５６）により接続される生産サイト（５２）と回復サイト（５４）とを含んだアーキテクチャーであって、障害回復を実行するための請求項１２〜１６のいずれか一項に記載のシステム（５０）を含むことを特徴とするアーキテクチャー。
17. パケットベースの電気通信ネットワーク（５６）を介して生産サイト（５２）に接続される回復サイト（５４）であって、
    回復制御サーバー（８４）を備え、回復制御サーバー（８４）は、
    生産サイト（５２）の問題を検出することができる第１のモジュール（１５４）と；
    問題を検出すると、生産サイト（５２）にアクセスする試みが回復サイト（５４）にルーティングされるように前記ネットワークを自動的に再設定することができる第２のモジュール（１６０）と；
    を含むことを特徴とする回復サイト。