JP2005317017A - アプライアンス・ベースの業務継続アーキテクチャにおけるバックアップ・システム障害後の再同期時間の最短化 - Google Patents

Abstract

【課題】アプライアンス・ベースの業務継続アーキテクチャにおいてダウンタイムを最短化するための再同期方法を提供。
【解決手段】少なくとも１つの一次データ記憶装置および一次ホストと、一次ホストのデータ要求をインターセプトし、データ要求に関連する情報を収集するインターセプト・エージェントを含む。更に、一次ホストと通信し遠隔バックアップ・サイトと通信する業務継続アプライアンスを提供する。アプライアンスは、インターセプト・エージェントからインターセプトしたデータ要求に関連する情報を受信する。更に、業務継続アプライアンス内にローカル・キャッシュが含まれる。ローカル・キャッシュは、受信した情報に従って一次データ記憶装置のコピーを維持する。更に、遠隔サイトには、業務継続アプライアンスを介してインターセプトしたデータ要求が供給され、一次データ記憶装置のバックアップを維持する。
【選択図】図１

Description

本開示は、小さい固定サイズのメモリおよび／またはディスク・スペースを用いて、業務継続アーキテクチャにおける１つ以上のバックアップ・システム・コンポーネントに障害が発生した後の再同期時間を最短化する発明を記載する。

情報の時代において、常にデータをオンラインに保持することの重要性は顕著になっている。業務継続（ＢＣ：Business Continuance）および高速データ回復の必要性は重大なものであり、充分に認められている。この問題に対する１つの解決策は、遠隔データ複製（または遠隔ミラーリング）である。遠隔ミラーリングによって、サイト全体に渡る災害が生じている間、データ損失を回避または軽減することができる。また、遠隔サイトにホットスタンバイ・ホストおよびアプリケーションを設け、一次サイトに障害が生じた場合に遠隔サイトにクライアントを誘導することによって、サイト全体の障害が起こった際に連続したデータ・アクセスを保証することができる。遠隔データ複製は、２つの特徴を有する。すなわち、同期および非同期である。サイト全体の災害の間にデータ損失を回避することができるのは、同期遠隔ミラーリングのみである。なぜなら、要求側アプリケーションからの書き込みは、ローカル・サイトおよび遠隔サイトの双方にデータがうまく書き込まれるまで完了と見なされないからである。しかしながら、これは、アプリケーションにとって、性能上の不利となる。非同期遠隔ミラーリングでは、書き込みは、ローカル・サイトに書き込まれた直後に完了と見なされる。続けて、更新が遠隔サイトに送られる。このため、サイト全体の災害が起きた場合、遠隔サイトへの送信を待っているデータがあれば、データ損失が生じるであろう。しかしながら、遠隔ミラーリング用のアプライアンス・ベース・アーキテクチャは、非同期ミラーリングの性能およびほとんど同期ミラーリングの保護を有するので、人気が高まってきている。

かかるアーキテクチャにおいて、データは、一次サイトで動作しているアプリケーションによって格納およびアクセスされる。一次ホストは、アプリケーションの全てのＩ／Ｏ要求を共同で処理するサイト内のホスト集合として定義される。これらの一次ホストの各々に、インターセプト・エージェントがインストールされている。これらのインターセプト・エージェントは、全ての更新を集めて、図１に示すようなアプライアンスで動作しているステージング・エージェントに報告する。アプライアンスは、ローカル・ネットワーク（例えばＬＡＮ）に接続されている場合もあるし、数マイル離れていることもあり得る（例えばＭＡＮ）。一次サイトの全インターセプト・エージェントから全ての更新を受信し、それらを一時的にローカルな永続的ログとして保持し、次いで周期的にバックアップ・エージェントに送信するのは、ステージング・エージェントの任務である。バックアップ・エージェントは、遠隔サイトで動作する。これは、一次サイトのデータがステージング・エージェントによって送信されると、更新によってそのデータを最新のものに保つことによって、そのデータのコピーを維持する。かかるアーキテクチャにおけるバックアップ・システムのコンポーネントとは、アプライアンスおよび遠隔バックアップ・ホストを指す。

アプライアンスは一次サイトに近いので、一次サイトとアプライアンスとの間の複製は、アプリケーションに大きな性能上の不利を与えることなく同期して実行することができる。アプライアンスと遠隔バックアップ・サイトとの間の複製は、非同期に行うことができる。ステージング・エージェントは、まず、インターセプト・エージェントから受信した要求を永続的ログに記録する。アプリケーション要求は、一次ホスト上でうまく実行されてステージング・エージェントの永続的ログに記録されれば、戻ることができる。ステージング・エージェントは、バックグラウンドで永続的ログを処理し、複数の更新を大きいメッセージにまとめてから、それらを遠隔サイトのバックアップ・エージェントに送信する。これによって、ネットワーク利用が著しく改良され、従って、全体的な複製コストが削減される。全体的なアーキテクチャは、大きな不都合を増すことなく、同期および非同期ミラーリングの双方の利点を組み合わせる。いくつかのベンダーが、かかるアーキテクチャによるシステムを構築している［５，３］。このアーキテクチャのもとでは、ステージング・エージェントの永続的ログおよび遠隔バックアップ・サイトの二次データ・コピーが、一次サイトのデータ・コピーの完全なレプリカを形成する。

この複製による解決策では、一次サイトの災害がアプライアンスに影響を及ぼさないならばデータ損失は生じないということに留意すべきである。これは、アプライアンスが数マイル離れたＭＡＮ上にある場合に最も可能性の高いことであろう。しかしながら、一次サイトおよびアプライアンスの双方が同時に災害に直面した場合には、遠隔サイトは非同期にしか更新されず、更新の一部をしそこなう恐れがあるので、データの一部が失われることがある。最悪のケースでは、しそこなった更新の量は、アプライアンスの永続的ログにある更新の量と等しい。このため、アーキテクチャの保証は、従来の同期ミラーリングの保証よりも不充分になる。しかしながら、このアーキテクチャは、多種多様な障害の事例に対処し、同期ミラーリングよりもコストおよび性能の利点がはるかに大きい。最近のフィールド調査では、データ損失およびシステム・ダウンタイムを招いた障害の事例のうち、サイト全体の災害によって引き起こされたのは、わずか３％であることが示されている。このため、アプライアンス・ベースのアーキテクチャは、障害の事例の９７％について、更には、所与のアプライアンスを巻き込まないサイトの災害の部分についても、うまく機能する。従って、効率的な遠隔ミラーリングをサポートすることは、魅力ある代替案である。

このアーキテクチャがあれば、一次ホスト・サイトの障害の回復は簡単である。単に、遠隔サイトに切り替えれば良い。遠隔サイトは、いずれかの新しい要求に対処する前に、アプライアンスにおける全ての待ち状態のログ要求が処理されるのを待たなければならない。しかしながら、アプライアンスの障害に直面すると、永続的ログはもはや利用可能ではなく、従って二次データ・コピーの一部が失われる。何らかの特別な技法を用いない限り、アプライアンス障害からの回復には極めて高い費用がかかることがある。最悪の場合には、一次サイトに格納された全データを遠隔サイトにコピーしなければならないこともあり得る。場合によっては、完全なデータ・コピーを行うよりも、一次サイトのデータを遠隔サイトのデータと比較して、それら２つの間で異なるデータのみを再同期する方が、コストが低いこともある。しかしながら、比較そのものが、双方のサイトの全データ・セットの読み取りを必要とする。データ・ブロックのチェックサムを用いて差を識別する場合、双方のサイトはチェックサムの計算も行わなければならない。明らかに、これは、データ再同期の間のネットワーク帯域幅の点で大きなコストとなるだけでなく、長期に渡って一次ホストのアプリケーションの性能を劣化させる恐れがある。更に、一次サイトがオフラインでない場合、長時間、全システムを非保護モードに置く可能性がある。同様に、遠隔バックアップ・サイトに障害が生じ、三次バックアップ（おそらくはテープ・ライブラリ）から回復するのであれば、この場合にも最悪のケースは、一次サイトのデータ全体をバックアップ・サイトのデータと比較し、それらの差を再同期することであろう。バックアップ・システムのコンポーネントに障害が発生した後でも、古いバックアップ・コピーが常に利用可能であり得ると想定する。これは、アプライアンスの障害にも当てはまる。なぜなら、バックアップ・サイトのデータ・コピーは、古いバックアップ・コピーであるからである。遠隔バックアップ・サイトの障害では、バックアップ・サイトをある時点に復元するために使用可能なテープ・バックアップが常にあると想定する。バックアップ・データ・コピーとも呼ぶこの二次データ・コピーを、一次データと同等の状態にするため、バックアップの時点以降に一次サイトにおいて行われた全ての更新を再同期しなければならない。必要なのは、アプライアンスおよび／または遠隔バックアップ・サイトにおける障害後のこの再同期時間を最短化する問題に対処する解決策である。

アプライアンスおよびバックアップ・サイトの障害等のバックアップ・システム・コンポーネントの障害の後の潜在的に長い再同期時間は、問題が多い。長い再同期時間は、１つ以上のバックアップ・システム・コンポーネントに障害が発生した場合にどのデータを再同期しなければならないかを一次システムが常に把握しているわけではないという事実によるものである。最も簡単で、多くの場合は最も遅い再同期の方法は、一次サイトおよびバックアップ・サイトの双方における全データ・セットを徹底的に比較して、それらの差をバックアップに適用することである。一次サイトのデータ量が大きい場合、このプロセスは極めて遅いものとなり得る。一次ホストが、障害後にどのデータを再同期しなければならないかを知っていれば、それらのデータ・セットのみを一次コピーからバックアップ・コピーに回復させれば良い。例えば、アプライアンス障害の場合、回復させる必要がある唯一のデータは、ステージング・エージェントの永続的ログにあったデータである。同様に、遠隔サイトに障害が発生した場合を考える。遠隔ホスト回復プロセスでは、まず、遠隔サイトを最新のテープ・バックアップに復元することができる。その後、そのテープ・バックアップ以降に行われた更新のみを一次サイトから回復させなければならない。かかる差が容易に識別可能であれば、バックアップ・システム・コンポーネントの回復はそれほど費用のかかるものではない。一般に、２つのバージョンのデータ・コピー間の差は、システム状況に応じて、数秒分の更新から、何時間分もの更新、更には何日間分もの更新まで、様々であり得る。

一次データ・コピーと、遠隔サイトおよびアプライアンス上のデータとの間のこのような差を追跡するための１つの方法は、一次サイトおよび遠隔サイト上のポイント・イン・タイム・スナップショット機能を利用するものである。その考えは、一次ホストに周期的なスナップショットを取らせるということである。また、遠隔サイトも、スナップショットを保持するが、更新は遅れる。アプライアンスに障害が発生した場合、遠隔ホストは、全ての更新を受信した最新のスナップショットを見つけることができる。そのスナップショット以降に行われた全ての変更は、アプライアンスの永続的ログが機能停止した後にログ内にあった変更の上位集合を形成する。一次ホストが、遠隔サイトによって示されるそのスナップショット以降の変更を識別する効率的な方法を有するならば、それらの変更のみをレプリカに送って、遠隔サイトで完全なレプリカを保証すれば充分である。同様に、遠隔サイトに障害が発生し、最初に最新のテープ・バックアップに復元される場合を考える。最新のテープ・バックアップが、あるスナップショットＮに相当すると仮定すると、回復する必要があるデータは、スナップショットＮ以降に行われた１組の変更である。一次ホストは、スナップショット情報を用いて変更されたデータを識別し、従って、ファイルシステムの全ボリュームではなくデータのサブセットのみを回復させることができる。

上述の手法はデータ再同期時間を著しく短縮するが、一次ホストが適切なスナップショット機能を有する必要があり、このためシステム・ソフトウエア依存性が生じる。また、遠隔バックアップは、スナップショットについて知り、その機構を利用可能であることが必要である。更に、バックアップ・コンポーネントに障害が発生した場合、バックアップ・サイトまたはアプライアンスの迅速な再同期を容易にするため、一次サイトにスナップショット・スケジューリングの要求が課される。スナップショットがあっても、一次サイトは、バックアップを最新にするために用いる所与のスナップショット以降に行われた１組の変更を迅速に識別することができなければならない。これを容易にするため、ソフトウエアは、完全なスナップショット・メタデータのスキャンを回避しなければならない、これは、極めて費用が高く、ホスト・アプリケーションに対して性能の劣化を引き起こし得るからである。しかしながら、スナップショット・メタデータ・スキャンを回避する方法は、多くの場合、一次ホスト・データ処理について性能上の不利を招く。ソフトウエアの複雑さに応じて、場合によっては、ホスト・アプリケーションは、スキャンを完了するため停止しなければならない場合がある。従来のネットワーク・アプライアンスのファイラは、かかる障害の場合のためにスナップショットを用いる。しかしながら、かかるアーキテクチャは、一次サイトおよびバックアップ・サイトにおいて用いられているソフトウエアまたはアプライアンスの均一性に依存する。

スナップショット以外の方法で、一次サイトのいくつかのログにおいて更新を常に把握することによって上述の問題を軽減させるために、いくつかの方法が展開されている。かかるログのレコードが、どのデータが変更されたかを示すので、バックアップ・システム・コンポーネントを回復する場合には、かかるデータのみを再同期すれば良い。しかしながら、これらの解決策でさえ、有限のリソースでは充分に機能しないので、問題がある。いったんログに割り当てたスペースが一杯になると、これらのアルゴリズムは、全てのアプリケーションにそれ以上の更新の発生を停止させる（このためダウンタイムが生じる）か、または、一次バージョンおよびバックアップ・バージョンを徹底的に比較するという長く困難なプロセスの間に一次サイトに障害が生じた場合、ログの蓄積を停止してシステム・データの損失を露呈することのいずれかに頼る。従って、多種多様なバックアップ・システム・コンポーネントの障害に対処する効率的な再同期方法が今なお要望されている。

本発明によれば、アプライアンス・ベースの業務継続アーキテクチャにおいてバックアップ・システム・コンポーネント障害後のデータ再同期時間を最短化するためのシステムが提供される。このシステムは、少なくとも１つの一次データ記憶装置を含む。さらに、このシステムは、少なくとも１つの一次ホスト機械を含み、この一次ホスト機械は、一次データ記憶装置に格納されたデータにアクセスすることができる。また、このシステムは、データ要求をインターセプトし、このインターセプトしたデータ要求に関連する情報を収集するための、少なくとも１つの一次ホスト機械におけるインターセプト・エージェントを含み、このインターセプトしたデータ要求は、データ読み取り要求およびデータ書き込み要求を含む。また、このシステムは、収集した情報を維持するための、少なくとも１つの一次ホスト機械における要約ログを含む。更に、少なくとも１つの業務継続アプライアンスは、一次ホスト機械におけるインターセプト・エージェントと通信し、遠隔バックアップ・サイトと通信する。業務継続アプライアンスは、インターセプト・エージェントからインターセプトしたデータ要求に関連する情報を受信する。少なくとも１つの業務継続アプライアンスは、インターセプト・エージェントと通信し、遠隔バックアップ・サイトと通信する。業務継続アプライアンスは、インターセプト・エージェントから収集した情報を受信する。更に、業務継続アプライアンス内にローカル・キャッシュが含まれる。ローカル・キャッシュは、収集したデータを維持する。更に、遠隔サイトには、収集したデータが供給される、遠隔バックアップ・サイトは、一次データ記憶装置に配置されたデータの二次コピーを維持する。要約ログを利用して、業務継続アプライアンスおよび遠隔バックアップ・サイトの複合障害の場合に再同期時間を最短化する。

本発明は、主に、アプライアンス・ベースの業務継続アーキテクチャにおいて、要約ログを用いて、バックアップ・システム障害後の再同期時間を最短化するためのシステムおよび方法として説明する。以下の記載では、説明の目的のため、本発明の完全な理解を与えるために、複数の具体的な詳細を述べる。しかしながら、本発明は、これらの具体的な詳細なしで実施可能であることは、当業者には明らかであろう。

当業者は、ＣＰＵ、メモリ、Ｉ／Ｏ、プログラム記憶装置、接続バス、および他の適切なコンポーネントを含むデータ処理システム等の装置を、プログラミングまたは他の方法で設計して、本発明の実施を容易にすることが可能であることを認めよう。かかるシステムは、本発明の動作を実行するための適切なプログラム手段を含む。

データ処理システムと共に用いる、予め記録されたディスクまたは他の同様のコンピュータ・プログラム・プロダクト等のシステムは、データ処理システムに本発明の方法の実施を支援させるための記憶媒体を含み、プログラム手段が記録されているものとすることができる。また、かかる装置およびシステムは、本発明の精神および範囲内に該当する。

図１は、アプライアンス・ベースの業務継続アーキテクチャ１０を示す。このアーキテクチャでは、データは、一次サイト１２において動作しているアプリケーションによって格納およびアクセスされる。一次サイト１２は、１つ以上の一次ホスト１４で構成され、一次ホスト１４は、アプリケーションによって行われる全てのＩ／Ｏ要求を処理する。各一次ホスト１４は、インターセプト・エージェント１６を含む。インターセプト・エージェント１６は、アプリケーションによって行われる全てのデータ要求（読み取りおよび書き込み）に関連する統計データおよびパターンを収集する。更に、インターセプト・エージェント１６は、全てのデータ要求に関連する識別証および記述情報を収集する。また、一次ホスト１４は、インターセプト・エージェント１６が収集した統計データ、パターン、識別証、および記述情報を維持するための要約ログ１５を含む。更に、一次ホスト１４は、データ・アクセス・エージェント１７を含む。一次サイト１２は、ＬＡＮ／ＭＡＮ１８に接続されている。

また、アーキテクチャ１０は、ネットワーク・アプライアンス２０を含む。ネットワーク・アプライアンス２０は、ＬＡＮ／ＭＡＮ１８に接続されている。ネットワーク・アプライアンス２０は、ステージング・エージェント２２を含む。インターセプト・エージェント１６は、ステージング・エージェント２２に、収集した統計データおよびアクセス・パターンの全てを供給する。更に、インターセプト・エージェント１６は、ステージング・エージェント２２に、全てのデータ要求および全てのデータ更新を供給する。更に、ネットワーク・アプライアンス２０は、ローカル・キャッシュ９４を含む。

また、アーキテクチャ１０は、遠隔サイト２４を含む。例示的な実施形態では、遠隔サイトは、ＷＡＮ２６を介してネットワーク・アプライアンス２０に結合されている。遠隔サイト２４は、バックアップ・エージェント２８を含む。バックアップ・エージェント２８は、ステージング・エージェント２２を介して受信した更新を分析および適用することによって、一次サイト・データのコピーの維持を担う。代替的な実施形態では、バックアップ・エージェント２８は、ネットワーク・アプライアンス２０においてステージング・エージェントと同じ場所に配置することも可能である。

インターセプト・エージェント
アーキテクチャ１０において、インターセプト・エージェント１６は２つの任務を有する。すなわち、（１）ステージング・エージェント２２に更新を送信すること、および（２）Ｉ／Ｏエラーを捕捉し、要求元のアプリケーションに透明な方法で、ステージング・エージェント２２に要求をリダイレクトすることである。本実施形態におけるインターセプト・エージェント１６は、更に、一次ホスト１４に生じるＩ／Ｏに関するアクセス・パターンおよび統計情報を収集する追加の機能も有する。統計情報には、どのデータにアクセスするか（ファイル名またはブロック・アドレスとすることができる）、誰がデータを読み取りまたは書き込みしているか、どのくらいの頻度でデータのアクセスまたは変更が行われるか、いつデータにアクセスするか、等が含まれる。読み取りデータの内容は、ステージング・エージェント２２に転送されない。かかる情報は、全ての読み取り動作について送信する必要はない。その代わり、複数のレコードを１回分にまとめ、データ複製のため送信される更新と抱き合わせにすることができる。例示的な実施形態では、１回分にまとめるため、一次的なメモリ内バッファを割り当てる。更新要求が長時間行われない場合、バッファが一杯になるといつでも、インターセプト・エージェント１６は、記録した情報をステージング・エージェント２２に渡す。インターセプト・エージェント１６は、必要な場合はいつでも、何らかの統計処理を行って、ステージング・エージェント２２に送信するデータ量を減少させる。ステージング・エージェント２２は、かかる情報を、キャッシングおよびプリフェッチのためにどのデータが有用であるかを決めるためのみに用いるので、統計データの送信にわずかな遅延があっても、著しい影響は及ぼさない。

好適な実施形態では、インターセプト・エージェント１６は、ステージング・エージェント２２にどの情報を報告するかに関して、システム管理者によって構成可能である。更に、インターセプト・エージェント１６は、ステージング・エージェント２２に要求を自動的にリダイレクトする前に、管理者が障害の正確な特徴を決定するのを待つように構成することも可能である。かかる構成は、アーキテクチャ１０を利用する組織の必要性によって異なる。

ステージング・エージェント
アーキテクチャ１０において、ステージング・エージェント２２は、以下の任務を有する。すなわち、（１）インターセプト・エージェント１６から更新を受信し、維持している更新ログにそれらを追加すること、（２）更新を非同期的にバックアップ・エージェント２８に送信すること、および（２）インターセプト・エージェントによってリダイレクトされた全てのＩ／Ｏ要求に対処することである。かかるリダイレクトは、一次サイト１２のデータが利用不可能であることの結果である（例えば一次サイト１２の障害）。

一次サイト１２のデータが利用不可能な間の性能の劣化を最小限に抑えるため、ステージング・エージェント２２によって維持される「ホット・キャッシュ」の概念が追加されている。ステージング・エージェント２２によって維持される「ホット・キャッシュ」は、一次サイト１２の一次ホスト１４が利用可能なデータを有さず、最新のデータ・コピーを検索するためにステージング・エージェント２２に接触する場合はいつでも用いられる。ステージング・エージェント２２は、インターセプト・エージェント１６からアクセス・パターンおよび統計データを受信する。その情報に基づいて、ステージング・エージェント２２は、近い将来にどのデータ・セットが必要になりそうかについて、インテリジェントな推測を行う。好適な実施形態では、インテリジェント・ステージング・エージェト１０２に対するインタフェースを設け、かかるインタフェースをシステム管理者が用いて、ステージング・エージェント２２に、特定のデータ・セットをホットとして見なすように命令することができる。１つのデータがホットであるかそうでないかを判定するために、多くの異なる基準を用いることができる。次に、「ホット・データ」の概念について説明する。

ホット・データ
データを「ホット」と識別する際に、様々な基準が用いられる。以下に、データ・ファイルの「ホットさ」について判定を行う際に利用可能な、かかる多くの基準を挙げる。
・ファイルを用いれば用いるほど、潜在的に重要性が高くなる。
・特定のファイルを用いるユーザ数が増えれば増えるほど、データが利用可能でない場合に影響を受けるユーザ集合が大きくなる。
・いくつかの設定では、ファイルのアクセス時間が、その重要性を決定することができる。例えば、あるファイルが通常、夜または週末に通常アクセスされる場合、これは、平日の初めにアクセスされるファイルよりも重要度が低いと言うことができる。
・いくつかの周知の実行ファイルおよびシステム・ファイルは、システムの適切な実行に必要なので、重要である。
・システムおよびユーザ構成ファイルは、ユーザがそれらのシステムにログインするために必要である場合がある。これらのファイルは、対象の記憶装置に常駐している場合、「ホット」と見なすことができる。
・いくつかのディレクトリは、一次サイト１２上で動作する重要なアプリケーションに属する場合があるので、管理者はこれらを重要なものとして構成することができる。
・いくつかのユーザのファイル（例えばＣＥＯのメール）は、他のものよりも重要であると見なすことができる。
・ある人物が休暇中である場合、おそらく、そのユーザのファイルは、彼／彼女の休暇期間中、ホットと見なされない。実社会の知識に基づくこれらおよび他のかかる基準は、必要ならば、管理者によって指定することができる。
・小さいファイルに、キャッシングの間、何らかの優先権を与えることができる。
・メタデータ情報は、通常、ローカル・キャッシュ９４に保持するのに極めて有用であり、ホットと見なすことができる。実際、一次サイト１２においてデータ利用が不可能な間、効率のため、ステージング・エージェント２２がメタデータの全コピーをローカルに維持することができる。
・ファイルの内容も、ファイルの「ホットさ」を示すことができる。
・ファイル名またはその拡張子は、ファイルがどのくらい重要であるかを示すことができる。例えば、foo.cは、foo.oよりも潜在的に重要である。後者は前者から再発生することができるからである。システム・ログ・ファイルと同様、周知のファイル名にも、適切な「ホットさ」を割り当てることができる。

データ・ブロックのホットさを、同様に扱うことができる。データ・ブロックには名前が無いが、より重要性の高いいくつかの周知のデータ・ブロックがある可能性がある。ファイルと同様に、複数のユーザによってまたは何人かの重要ユーザによって高頻度で用いられるデータ・ブロックを、ホットと見なすことができる。

キャッシュ置換
ローカル・キャッシュ９４におけるデータのキャッシュングの一部として、ステージング・エージェント２２は、ローカル・キャッシュ９４がいっぱいである場合に、キャッシュされたどのデータを置換するかも決定する。ステージング・エージェント２２は、アクセス・パターンに基づいて、キャッシュ置換ポリシーを用いることができる。ＬＲＵおよびその後続のもの、ＬＦＵ、およびＡＲＣ等の人気のある方法を、異なる状況下で使用可能である。アーキテクチャ９２はどれも除外しないので、特定のアルゴリズムは指定しない。キャッシュ・ミス情報およびキャッシュ置換情報を、バックアップ・エージェント２８によって用いて、遠隔サイト２４に対するデータ・アクセスを効率的とするように、インテリジェント・データ認識を行うことができる。例えば、ステージング・エージェント２２は、置換したキャッシュ・データ・セットを追跡することができる。かかる情報は、ステージング・エージェント２２から遠隔サイト２４に更新データを複製した場合はいつでも、バックアップ・エージェント２８に追加することができる。バックアップ・エージェント２８は、かかる情報を抽出し、適切な最適化を実行することができる。

インテリジェント・バックアップ・エージェント
アーキテクチャ１０におけるバックアップ・エージェント２８と同様、バックアップ・エージェント２８は、更新要求を再生して、二次データ・コピーを再構築する責任を負う。更に、バックアップ・エージェント２８は、ステージング・エージェント２２によって送信されたアクセス・パターンおよび統計データ（例えばキャッシュ・ミス・レートおよび置換パターン）を分析する。この分析に基づいて、バックアップ・エージェント２８があるデータを検索するように求められた場合はいつでも、データ再編成等の最適化を実行して、Ｉ／Ｏ性能を改善する。データ再編成の１例は、高頻度でアクセスされるデータを複製し、それらを順次格納することである。一次サイト１２に障害が発生すると、バックアップ・エージェント２８は、全ての待ち状態の更新を永続的な記憶装置に適用して、遠隔サイト２４において最新データのコピーを作成する能力を管理者に与える。

データ・アクセス・エージェント
データ・アクセス・エージェント１７は、一次サイト１２のデータに対するクライアントとして機能する。これは、一次サイト１２の記憶装置からのデータの読み取りおよびこれに対するデータの書き込みの双方を行うことができる。これは２つの目的で用いられる。第１に、ステージング・エージェント２２によって用いられて、「ホット」と判定され、ローカル・キャッシュ９４に二次コピーを保持しなければならないと決定された一次サイト１２からのデータを読み取る。第２に、障害の後、一次サイト１２においてハードウエアの問題が解決した場合、ステージング・エージェント２２は、データ・アクセス・エージェント１７を利用して、一次サイト１２がその使用不可能の時間中に抜かしてしまったデータを書き込む。待ち状態のデータは、ステージング・エージェント２２のログに格納され、データ・アクセス・エージェント１７が提供するインタフェースを介して一気に供給される。データ・アクセス・エージェント１７は、一次サイト１２のデータに読み取り／書き込みアクセスを有するならば、一次サイト１２のどこにでも配置することができる。データ・アクセス・エージェント１７は、一次サイト１２の全データを復元しこれにアクセスすることができる。代替的な実施形態では、データ・アクセス・エージェント１７は、ネットワーク・アプライアンス２０内でステージング・エージェント２２と同じ場所に配置することができる。

自動化回復
ステージング・エージェント２２は、障害後に一次サイト１２を最新の状態に戻すことを支援する。インターセプト・エージェント１６が一次サイトの記憶装置への書き込みに失敗した場合はいつでも、ステージング・エージェント２２に、この障害および更新要求について知らせる。ステージング・エージェント２２は、そのログに更新を保持するので、いったん一次サイトの障害が修理されると、それらを一次サイト１２に再生することができる。通常、一次サイト１２の記憶装置は、最初にいくつかのバックアップ・テープから回復させることができる。次いで、バックアップ時間後に発行された全ての更新を適用して、一次記憶装置を完全に最新の状態にしなければならない。これを行う１つの方法は、障害後に遠隔サイト２４において最新のテープ・バックアップを作成し、そのテープを一次記憶装置の復元に用いることである。いったん復元されると、一次記憶装置は、ステージング・エージェント２２のログに配置されているデータのサブセットを抜かしているだけである。ステージング・エージェント２２は、システム管理者によって命令されると、データ・アクセス・エージェント１７を用いることによって、これらの更新を一次サイト１２に再生することができる。一次サイト１２が最新の状態になると、インターセプト・エージェント１６に知らせ、一次サイト１２の通常の動作を再開する。

本発明は、アーキテクチャ１０におけるバックアップ・システム・コンポーネントの障害からのいっそう効率的な回復を容易にする。回復は、ネットワーク・アプライアンス２０および／または遠隔サイト２４のための再同期時間の最短化により、更に効率的になる。

一次ホスト１４における要約ログ１５を用いて、過去のある時点以降に一次ホスト１４に格納したデータに行われた１組の変更を維持する。要約ログのために、有限のメモリおよび有限のディスク・スペースを利用する。要約ログ１５は、変更の内容自体を含まないが、これを用いて、ネットワーク・アプライアンス２０および／または遠隔サイト２４に障害が発生した場合に回復させるデータを推測することができる。

図２は、要約ログ１５に書き込みを行う方法４０を示す。ブロック４２において、方法４０が開始する。

ブロック４４では、インターセプト・エージェント１６は、一次ホスト１４に行われたデータ更新要求を識別し、そのデータ更新要求に関連する情報を収集する。

ブロック４６では、更新するデータがブロックまたはファイルのどちらであるかについて判定を行う。ファイルである場合、次いでブロック４８において、インターセプト・エージェント１６は、要約ログ１５に、ファイル更新のレコードを作成する。ブロックである場合、次いでブロック５０において、インターセプト・エージェント１６は、要約ログに、ブロック更新のレコードを作成する。

ブロック５２では、インターセプト・エージェント１６は、ブロック４４において収集した情報をステージング・エージェント２２に供給する。

ブロック５４において、方法４０は終了する。

要約ログのレコードは論理更新要求を含むが、変更したデータ内容は含まない。例えば、ファイル領域に対する書き込み要求では、レコードは単に、ファイル名、ファイル・オフセット、および更新されるファイル領域の長さとすることができる。ディスク・ブロックの更新では、これは、ディスクＩＤ、ディスク・アドレス、および更新するディスク・ブロック数とすることができる。

一次ホスト１４に対する大きなコストを回避するため、要約ログ１５のサイズは、比較的小さい値、例えば数十メガバイトのメモリおよび数ギガバイトのディスク・スペースとして維持しなければならない。バックアップ・システム・コンポーネントに障害が発生した場合、要約ログ１５を用いて、どのデータを更新し、一次ホスト１５と遠隔サイト２４との間で再同期する必要があるかを決定することができる。要約ログ１５は、常に、再同期する必要があるデータの正確な上位集合を供給する。更新の量が極めて多い場合でも、過剰な再同期の量は最小限に維持される。開示する本発明は、再同期しなければならない変更量が全データ・セットよりも著しく少ない場合に、最も有用である。実際、これはほとんどの場合に当てはまる。

図３は、要約ログ１５を圧縮する方法５６を示す。ブロック５８において、方法５６が開始する。

ブロック６０では、インターセプト・エージェント１６は、データ更新情報を要約ログ１５に供給する。通常、要約ログ１５に空き領域がある場合、正確な変更情報を記録することができる。かかる情報を再同期の間に用いる場合、システムはどのデータを回復させる必要があるかを正確に知っているので、再同期時間は最適と考えられる。

ブロック６２では、要約ログ１５がその容量に達しているかについて判定を行う。答えがノーである場合、次いでブロック６４において、要約ログ１５に更新要求のレコードを作成する。

ブロック６２に戻る。答えがイエスである場合、次いでブロック６６において、複製しているデータのタイプ（例えばファイルまたはディスク・ブロック）に応じて、常に正確な変更情報を保持する代わりに、データ・タイプに固有の情報を利用して、データの変更の「要約」を作成する。ここで、要約を作成するプロセスを圧縮と呼ぶ。かかる要約は、どのデータを変更したかに関して正確さが低い可能性があるが、データを再同期するためには、この情報で充分である。圧縮を行う場合でも再同期時間が最適に近く保持されていることを保証するため、１組の圧縮アルゴリズムを含み、異なるシステム状況のもとで適切な圧縮アルゴリズムをどのように選択するかの戦略も含む。

ブロック７０において、方法５６は終了する。

一般に、要約ログ１５の割り当てサイズが大きくなればなるほど、そこに格納される変更情報がいっそう正確になる。このため、要約ログ１５の領域が大きいと、結果として、その領域が小さい場合よりも再同期時間が短くなる。全体的に、本発明は、通常のシステム実行時の間ならびにコンポーネント障害および回復モードの間の双方について、一次ホスト１４に対する性能およびリソースのオーバーヘッドが極めて小さい。これは、所与のシステム・リソースについて、最適に近いデータ再同期時間で、幅広い範囲の障害状態に適応可能である。

アプライアンスの障害から回復するためには、アプライアンスの永続的ログにおける全ての更新に対応するレコードを要約ログが含むならば、一次ホスト・サイトから要約ログに基づいた最新のデータ・コピーを単に読み取り、それらを新たに設置したアプライアンスに送信することによって、アプライアンス障害から回復することができる。これは、要約ログが全ての更新レコードを無制限に保持する必要はないことを示す。再同期がうまく機能するためには、極めて限られた変更履歴を保持するだけで良い。更に、要約ログは一次サイトに常駐しているので、要約ログを小さく保持し有限として、一次ホストのリソースの使いすぎを避けることが重要である。

図４は、要約ログ１５を維持するための方法７２を示す。ステージング・エージェント２２が、遠隔サイト２４によって更新レコードのコピーが受信されたことの確認を送信した場合、更新レコードを除去することで、要約ログ１５を有限に保持することができる。バックアップ・エージェント２８はすでに更新レコードを受信したので、ステージング・エージェントの永続的ログ内の対応するレコードも除去することができる。ブロック７４において、方法７２が開始する。

ブロック７６では、一次ホスト１４で受信した更新要求を識別する。

ブロック７８では、識別した更新要求にタイムスタンプを添付する。タイムスタンプは、要約ログ１５からどのレコードを除去可能であるかの識別を容易にするために添付する。

ブロック８０では、要約ログ１５において、識別した更新要求のレコードを作成する。

ブロック８２では、インターセプト・エージェント１６は、ステージング・エージェント２２に、更新要求のレコードを供給する。ステージング・エージェント２２は、インターセプト・エージェント１６からの全ての要求を時間の順に処理する。従って、遠隔サイト２４において１組の要求を維持している場合はいつでも、ステージング・エージェント２２は、インターセプト・エージェント１６に、遠隔サイト２４上で維持されている最新の更新のタイムスタンプについて知らせることができる。次いで、インターセプト・エージェント１６は、もっと小さいまたは等しいタイムスタンプを有する全てのレコードを要約ログ１５から除去し、要約ログ１５のサイズを小さくする。

ブロック８４では、ステージング・エージェント２２は、バックアップ・エージェント２８に、インターセプト・エージェント１６から受信した識別された更新要求のレコードを供給する。

ブロック９０では、ステージング・エージェント２２は、バックアップ・エージェント２８を介した遠隔サイト２４との通信によって、遠隔サイト２４において維持された（例えばテープ、ディスク等に送った）最新の更新要求のタイムスタンプに関する情報をインターセプト・エージェント１６に供給する。

ブロック９２では、インターセプト・エージェント１６は、最新の更新のタイムスタンプより前のタイムスタンプを有する全てのレコードを除去する。

ブロック９４において、方法７２は終了する。

方法７２は、要約ログ１５が所望のサイズよりも大きくなったケースには対応しない。なぜなら、複数の更新が遠隔サイト２４上に維持されないからである。この場合、ステージング・エージェント２２の永続的ログも、これに対応して大きくなる。これは多くの状況で起こり得る。例えば、遠隔サイト２４とネットワーク・アプライアンス２０との間のＷＡＮ２６はあまりにも遅いか中断する恐れがあり、または遠隔サイトの要求処理があまりに遅く、その結果、ネットワーク・アプライアンス２０の永続的ログに更新が蓄積されてしまう。また、これは、一次サイト１４に並外れて高いレートの更新がある場合にも起こる場合がある。かかる状況に対処するため、要約ログ１５が範囲よりも大きくならないように、複数の変更記述を高レベルの変更要約に圧縮するためのアルゴリズムを提供する。かかる圧縮戦略では、障害回復の間に適用しなければならない更新に関する情報は失われないが、最適よりも長い再同期時間になることがある。このアルゴリズムは、常に、かかる圧縮のための余分な再同期時間を最短化しようとするように機能する。最短の再同期時間を得るように最適化しながら有限の要約ログ・サイズを維持するために使用可能な利用可能圧縮アルゴリズムのタイプについて、更に以下で説明する。

図５は、要約ログ１５がその容量に達したことに対応して要約ログを圧縮する方法９６を示す。

ブロック９８において、方法９６が開始する。

ブロック９９では、一次ホスト１４に対するデータ更新要求を識別する。

ブロック１００では、要約ログ１５のメモリ・バッファ部が容量に達したか否かについて判定を行う。答えがイエスである場合、次いでブロック１０２において、圧縮アルゴリズムを用いて、圧縮のためにメモリ・バッファ部内のデータを識別する。ブロック１０４では、ブロック１０２で識別したデータを圧縮する。

ブロック１０６では、要約ログ１５において識別した更新要求のレコードを作成する。

ブロック１０８では、インターセプト・エージェント１６は、ステージング・エージェント２２に、更新要求のレコードを供給する。ステージング・エージェント２２は、インターセプト・エージェント１６からの全ての要求を時間の順に処理する。従って、遠隔サイト２４において１組の要求を維持した場合はいつでも、ステージング・エージェント２２は、インターセプト・エージェント１６に、遠隔サイト２４上で維持されている最新の更新のタイムスタンプについて知らせることができる。次いで、インターセプト・エージェント１６は、もっと小さいまたは等しいタイムスタンプを有する全てのレコードを要約ログ１５から除去し、要約ログ１５のサイズを小さくする。

ブロック１１０では、ステージング・エージェント２２は、バックアップ・エージェント２８に、インターセプト・エージェント１６から受信した識別した更新要求のレコードを供給する。

ブロック１１６では、ステージング・エージェント２２は、バックアップ・エージェント２８を介した遠隔サイト２４との通信によって、インターセプト・エージェント１６に、遠隔サイト２４において維持された（例えばテープ、ディスク等に送った）最新の更新要求のタイムスタンプに関する情報を供給する。

ブロック１１８では、インターセプト・エージェント１６は、最新の更新のタイムスタンプの直前のタイムスタンプを有する全てのレコードを除去する。

ブロック１２０において、方法９６は終了する。

遠隔バックアップ・サイトの障害ならびに同時発生した遠隔バックアップおよびアプライアンスの障害に対処するため、上述の手法にわずかな変更を適用することができる。

遠隔サイト２４が障害すると、これは最初に最新のテープ・バックアップに復元可能であると想定される。一次ホスト・サイト１４から回復しなければならない残りのデータは、一次データ・コピーと最新テープ・バックアップとの差である。これは、ネットワーク・リソースの点であまりコストがかからないはずである。通常、長距離ネットワーク上ではデータ・セット全体のごく一部のみを再同期する必要があるからである。かかる効率的な回復を容易にするため、要約ログ１５は、遠隔サイト２４のそのテープ・バックアップ後に発生した全ての更新のための要約レコードを含まなければならない。これは、バックアップ・エージェント２８に、テープ・バックアップを開始した場合はいつでも、何らかの情報をステージング・エージェント２２に送信させることによって実行可能である。次いで、ステージング・エージェント２２は、この情報をインターセプト・エージェント１６に転送する。この情報は、テープ・バックアップが開始した時の最新の維持された更新要求のタイムスタンプを示す。この時点で、もっと小さいまたは等しいタイムスタンプを有する全てのレコードを、要約ログ１５から除去することができる。このため、要約ログ１５は、ステージング・エージェント２２の障害から回復するために必要な要約レコードの上位集合を含む。ネットワーク・アプライアンス２０および遠隔サイト２４の双方が同時に障害した場合であっても、要約ログ１５を用いて、再同期しなければならないデータ・セットを識別し、これによって回復コストを著しく削減することができる。

ステージング・エージェント２２は、まだ、インターセプト・エージェント１６に、時々、遠隔サイト２４に維持された最新の更新のタイムスタンプを通知させることができる。ネットワーク・アプライアンス２０に障害が発生した場合、インターセプト・エージェント１６は、全ての要約ログ・レコードを処理する必要はない。代わりに、これは、ステージング・エージェント２２が送信した最新のタイムスタンプよりも大きいタイムスタンプを有する全てのレコードを再同期すれば良い。このように、同一の要約ログ１５を用いて、ネットワーク・アプライアンス２０および遠隔サイト２０の双方の障害を効率的に回復させることができる。一般に、要約ログ１５に予備の空間がある限り、インターセプト・エージェント１６は、必要なよりも多くの変更レコードを無限に保持することができ、インターセプト・エージェント１６が所与の障害の事例にどのレコードを用いる必要があるかを把握する容易な方法がある。例えば、最新のＮテープ・バックアップ以降の変更記述を保持するための充分なログ空間がある場合、Ｎ−１のテープ・バックアップが利用不可能であるとしても、システムは、一次データ・コピーとバックアップ・データ・コピーとの間の徹底的なスキャンおよび比較を行うことなく、データを回復させることができる。

要約ログ１５の一部は一次ホスト１４の一次メモリであるので、一次ホスト１４がクラッシュした場合、一次ホスト１４が再始動した後に要約ログ１５の一部が失われる場合がある。これは大きな問題とはならないであろう。なぜなら、通常、要約ログ１５のレコードは、ある時間期間の間だけ保持され、バックアップ・システム・コンポーネントに障害がある場合にのみ用いられるからである。その時間期間の間、かかる障害が起こらなければ、古い要約ログ・レコードは必要ない。一次ホスト１４の障害に直面した場合でも要約ログ１５の情報を保持することが望ましい場合、ステージング・エージェント２２は、それ自身の永続的記憶装置に要約ログ１５をミラーリングすることができる。このように、一次ホスト１４がクラッシュした場合、ステージング・エージェント２２に連絡することによって、迅速に要約ログ１５をリロードすることができる。ステージング・エージェント２２による要約ログ１５のコピーの作成には、高い費用はかからない。なぜなら、これは、永続的ログを書き込むように、または永続的ログを処理する背景プロセスとして実行可能であるからである。

有限の要約ログのための圧縮アルゴリズム
要約ログ１５の圧縮を達成するには、要約ログ１５内の多数のデータ更新レコードを少数の高レベル要約レコードに要約して、要約ログ１５における格納空間要求を低減させる。圧縮は、再同期時間を長くする場合があるが、再同期時間をできる限り最適に近く保持するように機能する。圧縮は、要約ログ１５が容量に達した場合にのみトリガされる。通常の場合、要約ログ１５が適度に大きい限り、圧縮はトリガされない。

ここで、レコードの局所性（時間および空間）および要約の組み合わせに基づいて、例示的な圧縮アルゴリズムを詳しく説明する。

データ・アクセスは、通常、何らかの時間および空間の局所性を示す。例えば、一般的なファイルシステムの使用は、ファイルシステム階層における更新の局所性を示す。このため、数時間から数日までのいずれかの短い時間期間において、更新が行われた異なるディレクトリの数は、通常、ディレクトリの合計数に比べて少ない。同様に、ブロック・デバイス・アクセスは、あるレベルのデータ局所性を示すが、局所性はファイルシステムにおけるよりも明白でない場合がある。

要約ログ１５が容量に達すると、変更情報を全く失うことなく、多数の変更記述を少数のレコードにパックすることによって、データ・セットにおける任意の数の更新を要約することができる。例えば、更新された全てのファイルおよびディレクトリをカバーする少数の先祖を拾うことによって、ファイルシステム階層における１組の更新を要約することができる。再同期の間、それらのサブツリーのみを再同期する必要がある。サブツリーはファイルシステム全体よりも著しく小さいので、再同期のための比較またはデータ・コピーでさえも高速となる。同様に、ブロック・デバイス・アクセスの場合、更新したブロック数は、包含的範囲に統合することができる。

かかる圧縮の結果、比較のために変更が失われなくても、変更記述において正確さが失われる場合があることに留意すべきである。更に、適切な圧縮戦略を選択すると、変更記述の正確さは高く、従って、再同期時間が最適な時間から大きく逸脱することはない。

要約ログ１５の効率的かつ効果的な圧縮を容易にするため、適切な要約ログ１５のデータ構造を作り出してデータ更新記述レコードを追跡するので、一次ホスト１４のデータ処理に対する影響を最小に抑えて、圧縮を効率的に実行可能である。また、異なる状況のもとでどのようにデータを圧縮するかを決定する１組の圧縮戦略が含まれる。適切な圧縮戦略の選択は、システム条件に基づく。以下に、ファイルシステムのデータを一例として用いて、これらの問題にどのように対処するかを示す。以下に説明するように、これらの技法は、ディスク・ブロック・データをサポートするように拡張または変更することができる。

データ構造
先に述べたように、要約ログ１５は、メモリ・バッファおよびいくらかのディスク・スペースを含む。考察を容易にするため、要約ログのディスク部分は、常にメモリ・バッファの倍数のサイズであると仮定する。メモリ・バッファは、最新の変更記述を含む。インターセプト・エージェント１６は、常にメモリ内バッファを最初に更新する。メモリに空間が残っていない場合は、要約ログ１５のメモリ内バッファはディスクに一気に供給される。メモリ内バッファが連続メモリ領域の外に割り当てられた場合、それをディスクに書き込むため、大きな順次書き込みが必要である。これらのメモリ内バッファの各々は、要約ログ１５のチャンクとして知られる。ファイルシステム・データのための高速圧縮を容易にするため、ノードの階層を効率的に表すことができるデータ構造を用いる。各ノードは、ディレクトリまたはファイルに相当する。概念上、更新が報告された場合はいつでも、まだ存在しないならば、データ構造においてパスを表すノードを作成し、これによってファイルシステムに更新を記録する。かかるメモリにおける動作は、ほとんどツリーのルックアップおよび更新であるので、高い費用はかからない。既存のノードがすでに更新をカバーする場合、データ構造は変更されない。例えば、あるディレクトリ・ノードが、その子供が潜在的に更新されたことをすでに示しており、その子供に関連した別の更新が受信された場合には、その子供がすでに更新されていると識別されるので、何も実行されない。

好適な実施形態において、以下のデータ構造表現を利用する。

ファイル・ノード このノードは、それが表すファイルまたは複数のファイルを表す名前または規則的な表現を含む。フラグを用いて、更新がファイル・メタデータまたはファイル内容に対するものであることを示すことができる。ファイル内容については、これは、更新領域のファイル・オフセットおよび長さ、ならびにファイルの全体サイズの点から、更新されたファイル領域を含むことができる。

ディレクトリ・ノード このノードは、これが表すディレクトリまたは複数のディレクトリを表す名前または規則的な表現を含む。これは、このディレクトリにルートを持つファイル・サブツリーにおける更新の最大深さを示す、「深さ」と呼ばれるフィールドを有する。このため、あるファイルが再度名付けられてこのディレクトリに配置された場合、ディレクトリのリストのみが更新されるので、深さはゼロであろう。ディレクトリ下でファイルを作成すると、深さは１となる。なぜなら、ディレクトリのリストの他に、１レベル下のファイルを更新したからである。−１の深さは、このノードが更新されなかったが、更新されたノードの祖先であることを意味する。このため、かかるノードは、単に、更新されたノードへのパスを指定するのに役立つだけである。一方、「無限」の深さ（ここでは−２を用いる）は、このディレクトリ下での全サブツリーが潜在的に更新され、従って、バックアップ・システム・コンポーネント障害の場合、バックアップは全サブツリーを再同期する必要があり得ることを意味する。また、フラグを用いて、ディレクトリ更新がメタデータまたはディレクトリ内容に対するものであると示すことができる。

迅速な要約ログ１５のレコード除去を容易にするため、各チャンクにおいて、記録された最新の更新のタイムスタンプを追跡するので、インターセプト・エージェント１６が除去対象のレコードに関するタイムスタンプ情報をステージング・エージェント２２から受信した場合はいつでも、単にそのチャンクに対する記録された最新のタイムスタンプをチェックすれば良い。そのタイムスタンプが、ステージング・エージェント２２から受信したものよりも小さい場合、そのチャンク内の全てのレコードを除去することができる。チャンクがローカル・ファイルに格納されている場合は、そのファイルを除去することができる。いったん要約ログ１５が割り当てられたスペースの近くに達すると、最も古いチャンクから始めて、以下で述べる様々な圧縮戦略の１つ以上を適用することによって最も古いＮ個のチャンクを圧縮することによって、要約ログ１５を圧縮することができる。Ｎは構成可能なパラメータである。いったん圧縮されると、いくらかの要約ログ１５の空間が解放される。解放されたスペース量がある所定の閾値に達するまで、同じプロセスを繰り返す。圧縮を行ってもタイムスタンプ情報は維持されるので、マージの後でも、必要に応じてチャンクを除去することができる。遠隔サイト２４にデータを維持またはバックアップする場合に、古いレコードが最初に除去されるので、最も古いチャンクが最初に圧縮される。

圧縮戦略
要約ログ１５のサイズを制限するため、１組の圧縮戦略を定義する。戦略は、１つ以上の所与のチャンクに作用し、それらを調整するので、要約ログ１５において、ある指定されたスペース量を解放することができる。戦略は、以下を含む。

エクステント（extent）圧縮 ファイル領域を更新した場合はいつでも、更新のファイル・オフセットおよび長さを適宜ファイル・ノードに加える。これらのファイル領域レコードをマージして、いくらかのスペースを開放することができる。第１のファイル領域の終端と第２の領域の冒頭との間に最小の差を有するレコードをマージする。また、全てのファイル領域を除去して、全ファイルを更新したことを示すことができる。

名前圧縮 ある形態の規則的表現を用いることによって、ファイルおよびディレクトリの名前を圧縮可能である。例えば、「foolongname」は、「fo*」と表すことができる。

兄弟（sibling）圧縮 名前圧縮戦略を、兄弟ファイルまたはディレクトリに用いて、ノード数を減らすことができる。このため、複数のディレクトリ・ノードをマージする場合、新しいノードのために、兄弟間の最大深さ値を用いる。

深さの増大 ディレクトリの深さ値を増大させて、新しい深さ値によってカバーされる全てのノードを解放することができる。

名前の圧縮、深さの増大、およびエクステント圧縮等の戦略は個々のノードに適用し、兄弟圧縮は１群のノードに適用することができる。明らかに、最悪の場合には、圧縮を行った結果、ツリー内にあるのは１つのノードのみ、すなわちファイルシステムのルートを表すノードのみとなり得る。これは、ファイルシステムの更新に関する具体的な情報が利用可能でなく、結果として再同期時間が極めて長くなり得ることを意味する。これが示すことは、要約ログ１５が、少なくとも、ルート・ノードを保持するのに必要な空間（数バイト）と同じくらいの大きさである場合、我々のアルゴリズムは確かに限界があるということである。実際には、データ局所性があると、これが起こる可能性は低い。

正しい戦略の選択
要約ログ１５においてスペースを解放するためには、正しい１組の戦略を正しい１組のノードに適用して、最小量だけ再同期時間を長くするが所望のスペース量を解放するようにする必要がある。解放される所望のスペース量をＭとし、階層内のノード数をＮとし、異なる戦略数をＳとする。階層内の各ノードおよびノードに適用可能な各戦略について、Δｍ_i,jを計算する。これは、ノードiに対する戦略ｊの適用によって解放されるスペース量である。また、Δｔ_i,jを計算することができる。これは、ノードiに対する戦略ｊの適用によって増大する再同期時間の量である。このため、問題は、以下のように公式化することができる。

上述の問題の公式化は、合計の再同期時間増大を最小限に抑え、解放されるメモリがＭ以上であるように、１組の（ノード、戦略）組を選ばなければならないことを表す。これは、０−１ナップザック問題の最小化の変形である。この問題はＮＰハードとして知られるが、分岐限定技法、動的計画技法、状態空間の緩和および前処理のように、この問題を解決するためには周知の技法がある。また、極めて迅速にほぼ最適な解を得る周知の多項式時間アルゴリズムも用いることができる。最も単純な次善の解決策は、問題を、連続ナップザック問題にマッピングし、貪欲アルゴリズム（greedy algorithm）を用いて、ほとんどの場合にほぼ最適な解に達することであろう。貪欲アルゴリズムは、有限の空間を用いる場合に充分に機能する。

データ構造によって用いられるメモリ割り当てアルゴリズムに依存するが、Δｍ_i,jを計算することは難しくない。Δｔ_i,jを正確に計算するには、データ構造に何が格納されているかということ以上の情報が必要である。エクステント圧縮の場合、ファイルの全サイズが既知であり、再同期にかかる時間の推定値が利用可能なＮバイトのファイル・データであれば、Δｔ_i,jを推定することができる。ディレクトリ・ノードについて深さを増大させる場合、どのくらいの再同期時間が増すかを知ることが役立つ。これには、どれくらいの余分なデータを再同期しなければならないかについての推定値が必要である。これは、多くの場合、ファイルおよびディレクトリ・サイズ情報が必要であることを意味する。この情報を得るための１つの方法は、圧縮しているノード下でファイルおよびディレクトリのメタデータにアクセスすることである。別の方法は、遠隔サイト２４からメタデータ情報を収集して一次ホスト１４の性能に対する影響を回避することである。遠隔サイト２４における情報は、一次ホスト１４における情報よりも正確さが低い場合がある。なぜなら、いくつかの要求は、ステージング・エージェント２２から遠隔サイト２４まで同期されていない可能性があるからである。しかしながら、推定値のみが必要であるので、この手法は妥当である。かかる情報収集は、連続バックグラウンド・プロセスとして、または圧縮が必要な場合に、実行可能である。圧縮が必要な場合にこれを行うと、一次ホスト１４の処理が短時間影響を受ける場合がある。しかしながら、圧縮はまれにしか行われないので、これは大きな欠点ではない。あるいは、再同期時間の最適に近い性質をあきらめることによって、メタデータ情報を全く収集しないことも可能である。むしろ、ある経験則の「推測」を用いて、再同期時間の推定値を与えることができる。例えば、ディレクトリおよびファイルの適当な平均サイズを推測して再同期時間を推定することができる。

ディスク・ブロックについては、上述のエクステント圧縮と同様の方法で圧縮を達成することができる。ファイル・エクステントの代わりに、固定サイズのディスク・ブロックを処理する。最悪の場合、圧縮の結果として単一のディスク区画となる。かかるディスク・ブロック変更レコードを追跡するために用いられるデータ構造は、ディスクＩＤ、ディスク・ブロック・アドレス、およびそのディスク・アドレスから開始する変更したブロック数の組み合わせとすることができる。

要約ログを用いたバックアップ・システム障害後の再同期
いったん要約ログ１５を形成すると、再同期は簡単である。要約ログ１５レコードが正確な変更情報を記述するならば、システムは、一次ホスト１４からの変更記述に基づいてデータを単に読み取り、それを古いバックアップ・コピーに適用することができる。圧縮したレコードでは、２つの可能性がある。

（１）システムは、要約ログ１５のレコードによって示されたものを何でも単に読み取ることができる。これは、変更の何らかの上位集合が読み取られ、バックアップ・コピーに書き込まれる可能性があることを意味する。読み取られた余分なデータ量が大した量でない場合、これは問題ではない。
（２）一方、要約した情報が、再同期するデータ量に対して大きな追加となる場合、データを再同期する前に、要約ログ１５のレコードが記述するデータに対して比較を行うことができる。異なるデータのみを、（例えば遠隔サイト２４における）バックアップ・コピーに書き込めば良い。かかる比較は全データ・セットに行うわけではないので、比較は適度に迅速に行うことができる。しかしながら、実際には、かかる比較は回避される。

これは、多くの方法で達成可能である。例えば、遠隔バックアップ・コピーを一次コピーと同期させ、クリーンな永続的ログから始めること、または、要約ログ１５を読み取って、潜在的に実際の変更の上位集合である１組の変更を取得することによって、ネットワーク・アプライアンス２０に論理的に同等な永続的ログを再作成することにより、達成可能である。

このように、アプライアンス・ベースの業務継続アーキテクチャにおいて、要約ログを用いてバックアップ・システム障害後の再同期時間を最短化するためのシステムおよび方法について述べた。本発明を、具体的な例示的実施形態を参照して説明したが、本発明の広範な精神および範囲から逸脱することなく、これらの実施形態に様々な変形および変更を行い得ることは明らかであろう。従って、明細および図面は、限定的な意味でなく例示的な意味に考えられるものである。

アプライアンス・ベースの業務継続アーキテクチャを示す。 要約ログに書き込みを行う方法を示す。 要約ログを圧縮する方法を示す。 要約ログを維持するための方法を示す。 要約ログがその容量に達したことに応答して要約ログを圧縮する方法を示す。

Claims (56)

1. アプライアンス・ベースの業務継続アーキテクチャにおいてバックアップ・システム・コンポーネント障害後のデータ再同期時間を最短化するためのシステムであって、
   少なくとも１つの一次データ記憶装置と、
   前記一次データ記憶装置に格納されたデータにアクセスすることができる一次ホスト機械と、
   データ要求をインターセプトし、インターセプトしたデータ要求に関連する情報を収集するための、前記少なくとも１つの一次ホスト機械におけるインターセプト・エージェントと、
   収集した情報を維持するための、前記少なくとも１つの一次ホスト機械における要約ログと、
   前記インターセプト・エージェントおよび遠隔バックアップ・サイトと通信し、前記インターセプト・エージェントから前記収集した情報を受信する、少なくとも１つの業務継続アプライアンスと、
   前記業務継続アプライアンス内に含まれ、収集したデータを維持するローカル・キャッシュと、
   前記一次データ記憶装置に配置されたデータの二次コピーを維持し、前記収集したデータを供給される前記遠隔バックアップ・サイトと、
   を有し、前記要約ログを利用して、前記業務継続アプライアンスおよび前記遠隔バックアップ・サイトの複合障害の場合に再同期時間を最短化する、システム。
2. 前記収集した情報が、前記一次データ記憶装置に対する更新に関連する識別証および記述情報を含む、請求項１に記載のシステム。
3. 前記収集した情報が、構成可能な時間期間の間、前記要約ログによって維持される、請求項１に記載のシステム。
4. 前記構成可能な時間期間が、前記遠隔バックアップ・サイトによってデータが永続記憶装置にバックアップされたか否かに基づく、請求項１に記載のシステム。
5. 前記インターセプト・エージェントが前記収集した情報にタイムスタンプを含めることを利用して、どの情報を前記遠隔サイトにおける永続記憶装置に移動したかを識別する、請求項４に記載のシステム。
6. 永続記憶装置にデータを移動する際に、前記遠隔バックアップ・サイトが維持したデータのタイムスタンプを前記インターセプト・エージェントに供給し、前記インターセプト・エージェントが同等またはもっと早期のタイムスタンプを有する全データを前記要約ログから除去する、請求項５に記載のシステム。
7. 前記永続記憶装置がテープ・バックアップを含む、請求項１に記載のシステム。
8. 前記要約ログがその容量に達した際に前記要約ログの内容を圧縮することによって前記要約ログを維持する、請求項１に記載のシステム。
9. 各データ要求に関連して収集した情報量を圧縮により低減させることで、各データ要求に関連する前記収集した情報の要約のみを維持する、請求項８に記載のシステム。
10. どの情報を要約するかについての決定が、前記要約ログ内の最も古い収集した情報を識別し、前記要約ログ内に前記収集した情報の格納を開始するための適当な場所ができるまで、最も古いものから最も新しいものまで収集した情報を要約することを含む、請求項９に記載のシステム。
11. 識別可能なグループ内にある複数の更新要求を識別し、前記複数の更新要求の各々に関連する収集した情報を、前記識別可能グループへの更新を記述する単一情報レコードによって置換することを更に有する、請求項１０に記載のシステム。
12. 前記識別可能グループがファイルを含む、請求項１１に記載のシステム。
13. 前記識別可能グループが連続データのブロックを含む、請求項１１に記載のシステム。
14. アプライアンス・ベースの業務継続アーキテクチャにおいてバックアップ・システム・コンポーネント障害後のデータ再同期時間を最短化するためのシステムであって、
    少なくとも１つの一次データ記憶装置と、
    前記一次データ記憶装置および要約ログを含む少なくとも１つの一次ホスト機械と、
    を有し、前記要約ログが、前記一次ホスト機械に行われたデータ要求に関連する収集した情報を維持する、システム。
15. 前記データ要求に関連する情報を収集するための、前記少なくとも１つの一次ホスト機械におけるインターセプト・エージェントを更に含む、請求項１４に記載のシステム。
16. 前記インターセプト・エージェントが業務継続アプライアンスと通信し、収集した情報のコピーを前記業務継続アプライアンスに転送する、請求項１５に記載のシステム。
17. 前記業務継続アプライアンスが、前記収集した情報をローカル・キャッシュに格納する、請求項１６に記載のシステム。
18. 前記業務継続アプライアンスが、前記一次データ記憶装置に配置されたデータの二次コピーを維持する遠隔バックアップ・サイトに前記収集した情報を供給する、請求項１７に記載のシステム。
19. 前記要約ログを用いて、前記アプライアンス・ベースの業務継続アーキテクチャの遠隔バックアップ・システムに障害が発生した場合の再同期時間を最短化する、請求項１４に記載のシステム。
20. 前記収集した情報が、前記一次データ記憶装置に対する更新に関連する識別証および記述情報を含む、請求項１４に記載のシステム。
21. 前記収集した情報が、
    データ要求が読み取り要求か書き込み要求かを示すタイプを含む、データ要求の記述と、
    データ要求が書き込み要求である場合に該データ要求に関連したデータと、
    前記一次ホストにおいて収集される、データ要求に関連したアクセス・パターンおよび統計データと、
    を含む、請求項１４に記載のシステム。
22. 前記収集した情報が、構成可能な時間期間の間、前記要約ログによって維持される、請求項１４に記載のシステム。
23. 前記構成可能な時間期間が、前記遠隔バックアップ・サイトによってデータが永続記憶装置にバックアップされたか否かに基づく、請求項２２に記載のシステム。
24. 前記インターセプト・エージェントが収集された情報にタイムスタンプを含めることを利用して、どの情報を前記遠隔バックアップ・サイトにおける永続記憶装置に移動したかを識別する、請求項２３に記載のシステム。
25. 永続記憶装置にデータを移動する際に、前記遠隔バックアップ・サイトが前記維持したデータのタイムスタンプを前記インターセプト・エージェントに供給し、前記インターセプト・エージェントが同等またはもっと早期のタイムスタンプを有する全データを前記要約ログから除去する、請求項２４に記載のシステム。
26. 前記永続記憶装置がテープ・バックアップを含む、請求項２５に記載のシステム。
27. 前記要約ログがその容量に達した際に前記要約ログの内容を圧縮することによって前記要約ログを維持する、請求項１４に記載のシステム。
28. 各データ要求に関連して収集した情報量を圧縮により低減させることで、各データ要求に関連する前記収集した情報の要約のみを維持する、請求項２７に記載のシステム。
29. どの情報を要約するかについての決定が、前記要約ログ内の最も古い収集した情報を識別し、前記要約ログ内に収集した情報の格納を開始するための適当な場所ができるまで、最も古いものから最も新しいものまで収集した情報を要約することを含む、請求項２８に記載のシステム。
30. 識別可能なグループ内にある複数の更新要求を識別し、前記複数の更新要求の各々に関連する収集した情報を、前記識別可能グループへの更新を記述する単一情報レコードによって置換することを更に有する、請求項２９に記載のシステム。
31. 前記識別可能グループがファイルを含む、請求項３０に記載のシステム。
32. 前記識別可能グループが連続データのブロックを含む、請求項３０に記載のシステム。
33. アプライアンス・ベースの業務継続アーキテクチャにおいてバックアップ・システム・コンポーネント障害後のデータ再同期時間を最短化する方法であって、
    一次ホスト機械に行われたデータ要求をインターセプトするステップと、
    インターセプトしたデータ要求に関する情報を収集するステップと、
    収集した情報を、前記一次ホスト機械にある要約ログに格納するステップと、
    前記収集した情報を業務継続アプライアンスに供給し、前記業務継続アプライアンスが一次データ記憶装置に配置されたデータの二次コピーを維持する遠隔バックアップ・サイトに前記収集した情報のコピーを供給するステップと、
    を有し、前記要約ログを利用して、前記業務継続アプライアンスおよび前記遠隔バックアップ・サイトの複合障害の場合に再同期時間を最短化する、方法。
34. 前記収集した情報が、前記データ要求に関連する識別証および記述情報を含む、請求項３３に記載の方法。
35. 前記収集した情報が、構成可能な時間期間の間、前記要約ログによって維持される、請求項３３に記載の方法。
36. 前記構成可能な時間期間が、前記遠隔バックアップ・サイトにおいてデータが永続記憶装置にバックアップされたか否かに基づく、請求項３３に記載の方法。
37. 前記収集した情報がタイムスタンプを含むことを用いて、どの情報を前記遠隔バックアップ・サイトにおける永続記憶装置に移動したかを識別する、請求項３６に記載の方法。
38. 永続記憶装置にデータを移動する際に、前記遠隔バックアップ・サイトが維持したデータのタイムスタンプを前記一次ホストに供給し、同等またはもっと早期のタイムスタンプを有する前記要約ログ内の全データを除去する、請求項３７に記載の方法。
39. 前記永続記憶装置がテープ・バックアップを含む、請求項３６に記載の方法。
40. 前記要約ログがその容量に達した際に前記要約ログの内容を圧縮することによって前記要約ログを維持する、請求項３３に記載の方法。
41. 各データ要求に関連して収集した情報量を圧縮により低減させることで、各データ要求に関連する収集した情報の要約のみを維持するステップを含む、請求項４０に記載の方法。
42. どの情報を要約するかについての決定が、前記要約ログ内の最も古い収集した情報を識別し、前記要約ログ内に収集した情報の格納を開始するための適当な場所ができるまで、最も古いものから最も新しいものまで収集した情報を要約することを含む、請求項４１に記載の方法。
43. 識別可能なグループ内にある複数の更新要求を識別し、前記複数の更新要求の各々に関連する収集した情報を、前記識別可能グループへの更新を記述する単一情報レコードによって置換するステップを更に有する、請求項４２に記載の方法。
44. 前記識別可能グループがファイルを含む、請求項４３に記載の方法。
45. 前記識別可能グループが連続データのブロックを含む、請求項４３に記載の方法。
46. 一次ホスト機械、前記一次ホスト機械と通信する業務継続アプライアンス、および前記業務継続アプライアンスと通信し、一次データ記憶装置に配置されたデータの二次コピーを維持する遠隔バックアップ・サイトを含むアプライアンス・ベースの業務継続システムにおいて、バックアップ・システム・コンポーネント障害後のデータ再同期時間を最短化するためのプログラムであって、前記一次ホスト機械に、
    前記一次ホスト機械に行われたデータ要求をインターセプトするステップと、
    インターセプトしたデータ要求に関連する情報を収集するステップと、
    収集した情報を、前記一次ホスト機械にある要約ログに格納するステップと、
    前記収集した情報を、該情報のコピーを前記遠隔バックアップ・サイトに供給する業務継続アプライアンスに供給するステップと、
    を実行させ、前記要約ログを利用して、前記業務継続アプライアンスおよび前記遠隔バックアップ・サイトの複合障害の場合に再同期時間を最短化させる、プログラム。
47. 前記収集した情報が、前記データ要求に関連する識別証および記述情報を含む、請求項４６に記載のプログラム。
48. 前記一次ホスト機械に、前記収集した情報を、構成可能な時間期間の間、前記要約ログによって維持するステップを実行させる、請求項４６に記載のプログラム。
49. 前記構成可能な時間期間が、前記遠隔バックアップ・サイトにおいてデータが永続記憶装置にバックアップされたか否かに基づく、請求項４６に記載のプログラム。
50. 前記一次ホスト機械に、前記収集した情報がタイムスタンプを含むことを用いて、どの情報を前記遠隔バックアップ・サイトにおける永続記憶装置に移動したかを識別するステップを実行させる、請求項４９に記載のプログラム。
51. 永続記憶装置にデータを移動する際に、前記一次ホスト機械に、前記遠隔バックアップ・サイトから維持したデータのタイムスタンプを受信するステップと、同等またはもっと早期のタイムスタンプを有する前記要約ログ内の全データを除去するステップとを実行させる、請求項５０に記載のプログラム。
52. 前記要約ログがその容量に達した際に、前記一次ホスト機械に、前記要約ログの内容を圧縮することによって前記要約ログを維持するステップを実行させる、請求項４６に記載のプログラム。
53. 前記一次ホスト機械に、各データ要求に関連して収集した情報量を圧縮により低減させることで、各データ要求に関連する収集した情報の要約のみを維持するステップを実行させる、請求項５２に記載のプログラム。
54. どの情報を要約するかについての決定が、前記要約ログ内の最も古い収集した情報を識別し、前記要約ログ内に収集した情報の格納を開始するための適当な場所ができるまで、最も古いものから最も新しいものまで収集した情報を要約するステップを含む、請求項５３に記載のプログラム。
55. 前記一次ホスト機械に、識別可能なグループ内にある複数の更新要求を識別し、前記複数の更新要求の各々に関連する収集した情報を、前記識別可能グループへの更新を記述する単一情報レコードによって置換するステップを更に実行させる、請求項５４に記載のプログラム。
56. アプライアンス・ベースの業務継続アーキテクチャにおいてバックアップ・システム・コンポーネント障害後のデータ再同期時間を最短化するためのシステムであって、
    アプライアンス・ベースの業務継続アーキテクチャにおいて一次ホスト機械に行われたデータ要求をインターセプトし、インターセプトしたデータ要求に関連する情報を収集するための手段と、
    収集した情報を維持するための手段と、
    障害が発生したバックアップ・コンポーネントを復元した後に、前記収集した情報を利用して、前記アプライアンス・ベースの業務継続アーキテクチャにおいて前記バックアップ・コンポーネントを再同期するための手段と、
    を有する、システム。

Images