JP2007293828A - 継続的データ保護の複数種類のイベントマーカを処理するシステムと方法 - Google Patents

Abstract

【課題】継続的データ保護に対するコンピュータ化されたシステムを提供する。
【解決手段】ストレージサブシステムはストレージコントローラとストレージコントローラに接続されるストレージディスクを含む。ストレージディスクは論理パーティションに割り当てられる。ストレージサブシステムはさらにユーザアプリケーションに関連する現在のデータを保存する一次ボリューム、ユーザアプリケーションに関連するデータの時点コピーを保存するベースボリューム、ユーザアプリケーションに関連するデータを保存するジャーナルボリューム、およびホストによってストレージサブシステムに送られたデータ書き込み要求を止めて、止められた要求に関連するデータを一次ボリュームとベースボリュームに書き込み、およびユーザアプリケーションに関連する第二のデータをジャーナルボリュームに書き込むために構成されたジャーナルマネジャを含む。
【選択図】図２

Description

本発明は、一般的にはデータストレージシステムに、および、より具体的には、ストレージサブシステムを使用した継続的データ保護に関係する。

継続的データ保護（Ｃｏｎｔｉｎｕｏｓ Ｄａｔａ Ｐｒｏｔｅｃｔｉｏｎ；ＣＤＰ）技術はユーザアプリケーションによって実行される全ての書き込み入力―出力（ＩＯ）オペレーションをジャーナル処理することによってユーザデータに対する継続的保護を提供する。ログはストレージデバイス上に保存され、これは一次システムストレージから独立している。近代的ＣＤＰシステムは、イベントのタイミングチェックポイントまたはアプリケーションの設置のような、ターゲットソフトウエアアプリケーションの多様な動作を検出する。次に、ＣＤＰシステムは、それぞれのログレコードのヘッダ内にマーカ情報を書き込んで、ターゲットの動作に関する情報を保存する。

典型的なストレージベースのＣＤＰシステムは米国公開特許出願 Ｎｏ．ＵＳ２００４０２６８０６７Ａ１，タイトル“Ｍｅｔｈｏｄ ａｎｄ ａｐｐａｒａｔｕｓ ｆｏｒ ｂａｃｋｕｐ ａｎｄ ｒｅｃｏｖｅｒｙ ｓｙｓｔｅｍ ｕｓｉｎｇ ｓｔｏｒａｇｅ ｂａｓｅｄ ｊｏｕｒｎａｌｉｎｇ ａｓ ａ ｒｅｆｅｒｅｎｃｅ”に説明されており、これは参考のためにここに組み込まれている。説明されたシステムは書き込みジャーナル処理能力にコピーを提供し、アプリケーションデータのジャーナルログとスナップショットイメージに対する固有のシーケンス番号を保持する。

さらに、いくつかの市販の製品がある。一つの主要企業の製品はＲＥＶＩＯ ＣＰＳ １２００ｉである。この製品の説明はｈｔｔｐ：ｗｗｗ．ｒｅｖｉｖｉｏ．ｃｏｍ／ｉｎｄｅｘ．ａｓｐ？ｐ＝ｐｒｏｄ＿ＣＰＳ＿１２００ｉで見つけることが可能であり、ここでは参考のために組み込まれている。前述の製品はホストシステムによって実行される入力―出力（ＩＯ）オペレーションをミラーリングするために動作する。データのミラーリングは装置によって実行され、これはミラーリングされたＩＯデータを受信し、ジャーナルフォーマットで受信データを保存し、さらに後続のリストアオペレーションに対してインデックス処理情報を提供する。

他のＣＤＰ製品は、これはソフトウエアアプリケーションの振る舞いを調べることが可能であるが、ＸＯＳｏｆｔの Ｅｎｔｅｒｐｒｉｓｅ Ｒｅｗｉｎｄｅｒ Ｕｓｅｒ Ｇｕｉｄｅ製品であり、その説明内容はｈｔｔｐ：ｗｗｗ．ｘｏｓｏｆｔ．ｃｏｍ／ｄｏｃｕｍｅｎｔａｔｉｏｎ／ＥｎｔｅｒｐｒｉｓｅＲｅｗｉｎｄｅｒ＿Ｕｓｅｒ＿Ｇｕｉｄｅ．ｐｄｆからダウンロードでき、ここでは参考のために組み込まれている。この製品は、Ｍｉｃｒｏｓｏｆｔ（Ｒ）Ｅｘｃｈａｎｇｅ（Ｒ）に対して特別にデザインされており、ユーザアプリケーションの振る舞いをベースにしてそれ自身のオペレーションを適応させる。

上記の進歩にもかかわらず、新しい技術がストレージサブシステム内の更なる知能と同じくＣＤＰの振る舞いの更なる効率を提供することを求められ、これはターゲットアプリケーションの振る舞いのより良い理解を必要とする。

本発明の方法は継続的データ保護に対する従来の技術に関連する上記のおよび他の問題の一つ以上を実質的に取り除く方法とシステムに向けられている。

本発明の技術の一つの側面に従うと、継続的データ保護に対するコンピュータ化されたシステムと関連の方法とコンピュータプログラミングプロダクトが提供される。本発明のシステムはユーザアプリケーションを実行するホストとネットワーク相互接続を経由してホストに接続されるストレージサブシステムを含む。ストレージサブシステムはストレージコントローラとストレージコントローラに接続される少なくとも一つのストレージディスクを含む。ストレージディスクは論理パーティションに割り当てられる。本発明のストレージシステムはさらにユーザアプリケーションに関連した現在のデータを保存可能な一次ボリューム、ユーザアプリケーションに関連した第一のデータを保存するベースボリューム、ユーザアプリケーションに関連した第二のデータを保存するジャーナルボリューム、ホストによってストレージサブシステムに送られたデータ書き込み要求を止めて、止められた要求に関連したデータを一次ボリュームとベースボリュームに書き込み、ユーザアプリケーションに関連した第二のデータをジャーナルボリュームに書き込み可能なジャーナルマネジャ、およびホストからコマンド属性を受信し、受信したコマンド属性をベースにジャーナルマネジャを構成可能なコマンドデバイスを含む。

本発明の技術の他の側面に従うと、コンピュータ実施の方法と関連のシステムとコンピュータプログラミングプロダクトが提供される。本発明の方法は、アフタジャーナル処理モードを特定するコマンド属性をストレージサブシステムで受信すること、ユーザアプリケーションによって発行されたストレージアクセスコマンドをストレージサブシステムで止めること、止められたストレージアクセスコマンドが書き込みオペレーションを含むかを決定すること、もしも止められたストレージアクセスコマンドが書き込みオペレーションを含まないと、一次ストレージボリュームで止められたストレージアクセスコマンドを処理し、オペレーションを終了させること、もしも止められたストレージアクセスコマンドが書き込みオペレーションを含むと、ストレージアクセスコマンドに関連したデータを一次ボリュームに書き込むこと、およびストレージアクセスコマンドに関連した増加変化データをジャーナルボリュームに書き込むこと含む。

本発明の技術のさらに他の側面に従うと、コンピュータ実施の方法と関連のシステムとコンピュータプログラミングプロダクトが提供される。本発明の方法は、ビフォアジャーナル処理モードを特定するコマンド属性をストレージサブシステムで受信すること、ユーザアプリケーションによって発行されたストレージアクセスコマンドをストレージサブシステムで止めること、止められたストレージアクセスコマンドが書き込みオペレーションを含むかを決定すること、もしも止められたストレージアクセスコマンドが書き込みオペレーションを含まないと、一次ストレージボリュームで止められたストレージアクセスコマンドを処理し、オペレーションを終了させること、もしも止められたストレージアクセスコマンドが書き込みオペレーションを含むと、ストレージアクセスコマンドに関連したデータを一次ボリュームに書き込むこと、古いデータをベースボリュームからジャーナルボリュームにコピーすること、およびストレージアクセスコマンドに関連したデータをベースボリュームに書き込むこと含む。

本発明に関係する追加の側面は後続の説明で部分的に述べられ、説明から部分的には明かになり、または本発明の実施によって学ぶことができる。本発明の側面は、後続の詳細な説明と添付の特許請求項において特に指摘される要素と多様な要素の組み合わせと側面によって実現され達成されることができる。

前述のおよび後述の説明は典型的および説明的だけであり、いかなる態様においても請求された発明またはその応用を限定する意図がないことは理解される。

添付の図面は、この明細書に組み入れられ、部分を構成し、本発明の実施例を示し、説明と共に、本発明の技術の原理を説明し図示するのに役に立つ。

後述の詳細な説明において、添付の図面が参照され、これにおいて同一の機能要素は同じ番号で示される。前述の添付の図面は、図示のためであるが、限定するものではなく、本発明の原理と一致する特定の実施例と具体化を示す。これらの具体化はこの技術に精通する人達が本発明を実施することを可能にするために充分に詳細に説明されており、および、他の具体化の利用、および構造的な変更および／または多様な要素の置き換えが本発明の範囲と精神から離れることなく実現されることができることが理解される。従って、後述の詳細な説明は限定的な意味で解釈されるべきでない。さらに、説明される本発明の多様な実施例は汎用コンピュータ上で動作するソフトウエアの形式で、特別のハードウエア、またはソフトウエアとハードウエアの組み合わせの形式で具体化されることができる。

最初に、後続の詳細な説明の前に、前述の説明の中で使用されたある特別の用語が説明される。特に、ここで使用されているように、論理ユニット（ＬＵ）はストレージサブシステム上のＳＣＳＩコマンドを使用してホストからデータをアクセスするために使用される単位である。ＬＵは少なくとも一つの論理デバイス（ＬＤＥＶ）にマッピングされる必要がある。論理ユニット番号（ＬＵＮ）は各ＬＵの識別番号であり、これはＳＣＳＩコマンドを使用して論理ユニットを特定するために使用される。各ＬＵはＬＵＮとワールドワイドネーム（Ｗｏｒｌｄ Ｗｉｄｅ Ｎａｍｅ；ＷＷＮ）の関連するセットを有する。

論理デバイス（ＬＤＥＶ）はストレージサブシステム内にデータを保存するために構成されたストレージ領域である。これは少なくとも一つの物理ディスクを含むことができる。イメージはジャーナルデータが適用されるＬＤＥＶである。仮想ＬＵはそのＬＵに関連したＬＤＥＶの存在に関係なくホストからアクセス可能なＬＵである。マーカはホストのエージェントからストレージサブシステムに送られる。最後に、ヘッダ／フッタ情報はデータとマーカを保持するために提供されるジャーナルに対するメタデータを含む場合があり、これはホストから送られる。

第一の実施例
本発明の第一の実施例は、ストレージサブシステム上に配置されたＣＤＰが属性と動作のテーブルを使用して属性をベースにしたアプリケーションの動作を選択する能力を提供する方法を示す。本発明のシステムのＣＤＰはビフォアとアフタの両方のジャーナル処理モードで動作できる。本発明の概念を使用して達成されることのできる利点の一つは、アプリケーションの状態が変化する時に、アプリケーションがＣＤＰ動作モードを制御可能であり、それによって、アプリケーションが開始される時に、ストレージサブシステムのＣＤＰ上のジャーナルデータの長さが短くされることが可能であることである。さらに、もしもデータベースアプリケーションのようなアプリケーションがオンラインバックアップモードに入るか、またはリカバリオペレーションに入り込んでさえも、アプリケーションは“ビフォア”イメージを保持可能である。

物理的構成
図１は本発明の第一の典型的な実施例の多様なハードウエア構成部分、およびこれらの構成部分の間の相互接続を示す図である。図１に示される本発明の実施例は少なくとも一つのストレージサブシステム３０に実効的に接続される少なくとも一つのホスト１０を含む。ホスト１０はホスト１０のハードウエアプラットホーム上で動作するオペレーティングシステム（ＯＳ）を含むことができる。ホスト１０のハードウエアは標準的ワークステーションまたはパーソナルコンピュータの形で具体化されることができる。ホストは中央処理装置（ＣＰＵ）１１、メモリ１２、および内部ストレージディスクドライブ１３を含むことができる。ホストはまたファイバチャネル（ＦＣ）またはイーサネット（登録商標）スイッチ４００にホスト１０を接続可能なホストバスアダプタ（ＨＢＡ）１４を含むことができる。各ホスト１０はストレージサブシステム３０によって提供される一つ以上の論理ユニット（ＬＵ）上にそのデータを保存することができる。

ストレージサブシステム３０は後述の能力を有することができる。特に、ストレージサブシステム３０はストレージサブシステム３０のストレージリソース内に割り当てられた論理ストレージユニット（ＬＵ）上にファイバチャネルプロトコル（ＦＣＰ）を通してＳＣＳＩ−２，３コマンドを使用してデータを保存するために構成されることができる。ストレージサブシステム３０はさらに一つ以上のＲＡＩＤコントローラ（ＣＴＬ）２０と一つ以上のストレージディスクドライブ３２を組み込むことができる。コントローラ２０は一つ以上の中央処理装置、一つ以上のメモリユニット、および一つ以上のネットワークインタフェース（ＮＩＣ）を含むことができ、これはイーサネット（登録商標）および／またはＦＣポート２１と２２を含むことができる。前述のポートは、ＳＣＳＩＩ／Ｏオペレーションの処理を可能にするためにストレージエリアネットワーク（ＳＡＮ）に、またはディスク３２にシステムを接続するために提供されることができる。ストレージサブシステム３０のＲＡＩＤ構成はストレージサブシステム内に存在するいくつかのディスク３２を使用することができる。コントローラ２０は好適には不揮発性ランダムアクセスメモリ（ＮＶＲＡＭ）を含み、データキャッシュデバイスまたは、例えば、電源不良からデータを保護するためのデバイスとして前述のＮＶＲＡＭを利用するために構成される。

コントローラ２０は、ＳＣＳＩワールド内のターゲットＩＤを特定し、およびファイバチャネル（ＦＣ）ポート上の論理ユニット番号（ＬＵＮ）を含み、関連するＷＷＮ（Ｗｏｒｌｄ Ｗｉｄｅ Ｎａｍｅ）を有するポートをストレージサブシステムに提供する。ストレージサブシステムはさらに管理コンソール２３を含み、これは内部相互接続を経由してストレージサブシステム３０に接続されることができる。ストレージサブシステム３０はさらにスイッチ／ハブ４０１を経由してシステム３０に接続されるコンソール４０２を通してアクセスされることができる。コンソール４０２は、ストレージサブシステム３０を管理するために用意された汎用ウェブベースのＰＣまたは同様のワークステーションシステムを使用して具体化されることができる。コンソール２３はストレージサブシステム３０の保守者によって利用されるために構成される。コンソール４０２はストレージシステム管理者による使用のために提供され、ストレージシステムの筐体の外に配置されることができ、および前述のスイッチ／ハブ４０１を通してアクセス可能である。

論理構成
図２は本発明のシステムの説明される実施例の多様なソフトウエア構成部分の論理的構成とこれらの構成部分の中の相互動作を示す構成図である。

ＳＡＮ４００
ストレージエリアネットワーク（ＳＡＮ）４００はホスト１０とストレージサブシステム３０の間の論理データ接続を提供する。ＳＡＮ４００は、例えば、スイッチまたはハブを使用して具体化されることができ、例えば、ファイバチャネル（ＦＣ）および／またはイーサネット（登録商標）プロトコルにより動作し、この技術に精通した人に良く知られている。この技術に精通した人に理解されるように、本発明は何らかの特定のプロトコルに限定されることはなく、他の適切なプロトコルがＳＡＮ４００を具体化するのに使用されることができる。ＳＡＮの機能は、例えば、適切なファイバチャネル（ＦＣ）スイッチまたはハブ、またはイーサネット（登録商標）スイッチまたはハブによって提供されることができる。

ＬＡＮ／ＷＡＮ４０１
ＬＡＮ／ＷＡＮ４０１は、例えば、イーサネット（登録商標）、ＦＤＤＩ，またはトークンリングスイッチ等のような多様なネットワークスイッチを使用して、コンソール４０２とストレージサブシステム３０の間の論理接続を提供する。ストレージサブシステム３０はストレージサブシステム３０を管理する目的のために他のホストからここへのアクセスを可能にするためにＬＡＮ／ＷＡＮ４０１に接続される。

ホスト１０
ホスト１０はオペレーティングシステム（ＯＳ）（図には示されていない）、データベースアプリケーション（ＤＢ）のようなアプリケーション１６、およびエージェント１５を含むことができる。ＯＳは、限定することなく、ＵＮＩＸ（Ｒ），Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（Ｒ），ＳＵＮ（ＴＭ）Ｓｏｌａｒｉｓ（ＴＭ），ＩＢＭ（Ｒ）のＺ／ＯＳ（Ｒ）またはＡＩＸ（Ｒ）を含む任意の適切なオペレーティングシステムであることができる。この技術に精通した人に理解されるように、多くの他のタイプのオペレーティングシステムが、この技術に精通した人に知られており、使用されることができる。アプリケーションは、データベース（ＤＢ）または任意の他の種類のオフィスータイプのアプリケーションのようなトランザクションタイプのアプリケーションであることができる。

エージェント１５はストレージサブシステム３０とコミュニケーションを行う。エージェントとストレージサブシステムの間のコミュニケーションに対して利用されるコミュニケーション方法に関して、本発明の一つの実施例はＳＣＳＩコマンドセットを使用してストレージデバイスを制御する技術を使用する。この技術はこの技術に精通した人に良く知られており、例えば、ヨーロッパ特許Ｎｏ．ＥＰ１２４６０５０に説明されており、これはここで参考のために組み入れられる。エージェント１５は一般的にＥＰ１２４６０５０で説明されているシステムのホストコンピュータ上のオペレーションＡＰＩ（ＲＭＬＩＭ）に対応することを注意すべきである。一方で、本発明のコマンドデバイス（ＣＭＤＤＥＶ）３６は一般的にＥＰ１２４６０５０に説明されているコマンドデバイス（ＣＭ）と同じである。

エージェント１５はストレージサブシステム３０内に配置されたＣＤＰを制御するために構成された、いくつかのアプリケーションプログラミングインタフェース（ＡＰＩ）を有することができる。特に、図３はそれぞれのＡＰＩの典型的なリストを示す。エージェント１５のＡＰＩセット内の各機能コールはインスタンス番号を有する。このインスタンスはコミュニケーションパスがエージェント１５とＣＭＤＤＥＶ３６の間で確立された後に生成される。各機能コールはストレージサブシステムにアプリケーションとストレージサブシステムの間のコミュニケーションを特定することを可能にするために生成されたインスタンスを使用する。後述の説明は特定の機能の役割に関する詳細な情報を提供する。

ＣｒｅａｔｅＣＴＧ機能はストレージサブシステム３０内のＣＴＧＧｒｏｕｐＮａｍｅの名前を使用して図２に示されるグループ３９のようなコンシステンシグループを生成する。コンシステンシグループは論理ユニット（ＬＵ）の中の入力と出力（ＩＯ）の連続性を提供し、これはストレージサブシステム３０のコンシステンシグループ内のターゲット論理デバイス（ＬＤＥＶ）とＣＭＤＤＥＶ３６を含む。コンシステンシグループ内で、アフタジャーナル（ＪＮＬ）とビフォアＪＮＬメカニズム（以下で詳細に説明される）は一緒に使用可能である。新しいコンシステンシグループが生成される時に、新しい行が図５に示されるリスト３３に追加される。

ＡｄｄＬＤＥＶｔｏＣＴＧ機能は、ターゲットＬＵとＣＭＤＤＥＶを含み、論理ユニット（ＬＵ）マッピングされた論理デバイス（ＬＤＥＶ）を定義されたコンシステンシグループ内に追加することを要求する。ストレージサブシステムは図５に示されるテーブル３３のＬＤＥＶ列６２内で、適切なコンシステンシグループに対応する行内に追加されたＬＤＥＶを保存する。

ＤｅｌＬＤＥＶｔｏＣＴＧ機能はコンシステンシグループ内に以前追加されたＬＤＥＶを定義されたコンシステンシグループから削除する。このコマンドを受け取ると、ストレージサブシステムは図５のテーブル３３の列６２内のＬＤＥＶのリストから特定されたＬＤＥＶを削除する。

ＩｎｓｅｒｔＭａｒｋｅｒ機能はアプリケーション属性を有するコンシステンシグループに対応するマーカを発行する。前述のアプリケーション属性はアプリケーションの振る舞いをベースにストレージシステムのオペレーションを制御する。アプリケーション属性とＣＤＰ動作の間のマッピングはストレージサブシステム３０内で定義され保存される。前述の定義はエージェントまたはコンソールからコントローラにロードされる。アプリケーション属性およびＣＤＰ動作はＣＤＰアーキテクチャをベースにしており、以下で詳細に説明される。

ＬｉｓｔＭａｒｋｅｒ機能はＡＰＩによって特定されるＪＮＬマーカのリストを示す。機能がストレージサブシステム上で実行される時に、ＪＮＬマネジャはマーカを読み出す。ジャーナル処理の性能を最善にするために、マーカはキャッシュを使用して保存される場合がある。この機能の実行の結果はマーカ処理された時刻およびマーカに対応する属性を含む。

ＳｅａｒｃｈＭａｒｋｅｒ機能はＪＮＬのヘッダのユーザ特定フィールド内の一つ以上のキーをベースにマーカを検索することを本発明のシステムに要求する。ストレージサブシステムは検索の結果を返し、これはシーケンス番号＃、検索されたフィールド名、およびＪＮＬマーカの値を含む。

ＣｒｅａｔｅＶｉｒｔｕａｌＬＵ機能は以下で詳細に説明される仮想ＬＵを生成することを要求する。ＤｅｌｅｔｅＶｉｒｔｕａｌＬＵ機能は特定のポートから生成された仮想ＬＵを削除することを要求する。仮想ＬＵの削除の後で、ストレージサブシステム３０は、選択されたポートに対応する行において、図５に示されるＤＥＶ列８４からその仮想ＬＵに対応するエントリを削除する。

ＣｒｅａｔｅＶＬＵＧ機能は仮想ＬＵのグループを生成することを要求する。ストレージサブシステム３０は新しい仮想ＬＵグループを生成し、図１９に示されるテーブル３３０内に新しい行を挿入する。挿入された行は生成された仮想ＬＵグループの仮想ＬＵグループ識別子３３１とニックネーム３３２を含む。ニックネーム３３２は対応する機能コールから入力される。図１９のテーブル３３０内の仮想ＬＵＮ番号３３３は機能コールで特定されたＬＵＮを使用して繰り返し実行されるＣｒｅａｔｅＶｉｒｔｕａｌＬＵ機能を使用して生成される。

ＭａｐＣＴＧｔｏＶＬＵＧ機能は時刻とシーケンス＃によって特定されたＪＮＬからコンシステンシグループのイメージのセットを生成することを要求し、生成され名前をつけられた仮想ＬＵグループにセットをマッピングする。ストレージサブシステムがコンシステンシグループ上のイメージのセットをマッピングする時に、ストレージサブシステムはＭａｐＩｍａｇｅＴｏＶＬＵ機能を実行する。各ＭａｐＩｍａｇｅＴｏＶＬＵオペレーション上のターゲットＶＬＵを選択する順序はコンシステンシグループ上のソースＬＵＮの増加順である。例えば、コンシステンシグループ上にＬＵＮ１、２、３、および４があり、仮想ＬＵコンシステンシグループ上に仮想ＬＵＮ２０、２１、２２、２３がある。最初に、ＬＵＮ１に対するイメージは仮想ＬＵＮ２０にマッピングされ、増加順にＬＵＮ２に対するイメージは仮想ＬＵＮ２１にマッピングされる。これはＬＵＮ４まで続く。

ＵｎＭａｐＣＴＧｆｒｏｍＶＬＵＧ機能は生成され名前をつけられた仮想ＬＵグループからセットを非マップ化することを要求する。ストレージサブシステムは各イメージに対して繰り返しＵｎＭａｐＩｍａｇｅＦｒｏｍＶＬＵを使用して図１９上の仮想ＬＵグループ内の仮想ＬＵＮ番号３３３に説明されているイメージのセットを非マップ化する。

ＭａｐＩｍａｇｅＴｏＶＬＵ機能は特定のＬＤＥＶに適用されるジャーナルレコードを表すイメージを生成することを要求する。適用されるジャーナルの部分は時刻とシーケンス＃によって特定される。次に、システムはユーザアプリケーションにアクセス可能な仮想ＬＵに生成されたイメージをマッピングする。ストレージサブシステムは、特定された時刻とシーケンス＃と一致するヘッダ情報を有するＪＮＬからレコードを選択し、ボリュームを生成する。本発明のこの特徴はビフォア／アフタＪＮＬメカニズムの説明に関連して以下に説明される。イメージが生成された後で、このイメージは図１５内に示されるテーブル２５のＤＥＶ列８４を使用してＬＵにマッピングされる。

ＵｎＭａｐＩｍａｇｅＦｒｏｍＶＬＵ機能は仮想ＬＵの生成されたグループからイメージを非マップ化することを要求する。ストレージサブシステムは図１５のＤＥＶ列８４から選択されたイメージに対応するエントリを削除する。

ＬｏａｄＡｐｐｌｉｃａｔｉｏｎＡｔｔｒｉｂｕｔｅｓＴａｂｌｅ機能はアプリケーションと動作テーブル６０の情報を説明する構成ファイルをホストにロードする。フォーマットは、各列はカンマで区切られ、行は改行で区切られるＣＳＶフォーマットをコントローラ２０に対して使用可能である。コントローラ２０はフォーマットを６０のようなそれらのメモリフォーマットに変換する。

ＡｃｔｉｖａｔｅＴａｂｌｅ機能はマーカオペレーションの後続の使用に対してアプリケーション属性と動作テーブル６０をアクティブにする。ＤｅａｃｔｉｖａｔｅＴａｂｌｅ機能はマーカオペレーションを不使用にするためにアプリケーション属性と動作テーブル６０を非アクティブにする。本発明の実施例において、前述のＡＰＩオペレーションに対するコマンドラインインタフェースが提供され、パラメータも上記の機能コールとして提供さる。

ＡＰＩの振る舞いはＣＤＰアーキテクチャをベースにしており、以下で詳細に説明される。ホストも構成ファイル１７を保持し、これはＬｏａｄＡｐｐｌｉｃａｔｉｏｎＡｔｔｒｉｂｕｔｅｓＴａｂｌｅ機能に関して説明される。

ストレージサブシステム３０
本発明の一つの実施例において、ストレージサブシステム３０のモジュールは、コントローラ（ＣＴＬ）上で実行され、光媒体、ＦＤ，および／または他の取り外し可能なデバイスのようなプログラムコードのインストールフォームとして提供されるマイクロコードで可能になる。マイクロコードはパリティグループマネジャ、物理ディスクからＩＯ処理に論理ストレージを提供するために論理デバイスを生成する論理デバイスマネジャ（ＬＤＥＶマネジャ）２３、ポート２２およびジャーナル（ＪＮＬ）２４を含む。以下の説明は前述のモジュールに関する追加の詳細を提供する。

パリティグループマネジャ（このモジュールは図２内には記述されていない）
このモジュールはマイクロコードの一部分であり、ＲＡＩＤ０／１／２／３／４／５／６技術を使用するディスクからのパリティグループを含む。ＲＡＩＤ６はＲＡＩＤ５技術をベースにしており、保存されたデータの２重パリティ保護を含む。生成されたパリティグループは図４に示されるＬＤＥＶ構成テーブル２９内にリスト化され、ストレージサブシステム３０内のパリティグループを特定するためのパリティグループ番号列５１、ＲＡＩＤのリソースから生成される使用可能容量サイズ列５２、ＲＡＩＤ構成列５３、およびディスク列５４を有する。

ＬＤＥＶマネジャ２３
ＬＤＥＶマネジャ２３はＬＤＥＶの構造とＬＵのＩＯからの振る舞いを管理する。ＬＤＥＶは、ＬＵがデータを保存しホストから／へ提供するための論理ストレージ領域を提供する。ＬＤＥＶはパリティグループの一部分であり、管理者はＬＤＥＶの数を追加するＬＤＥＶの範囲を定義し初期的にフォ−マッティングする。ＬＤＥＶとパリティグループの間のマッピングはＬＤＥＶ構成２９（図４）内に保存される。パリティグループ番号５１において、ＬＤＥＶ構成のレコードはストレージサブシステム内の論理デバイスを特定するためのＬＤＥＶ番号５５、パリティグループ上のＬＤＥＶの開始アドレスを表すための開始論理ブロックアドレス（ＬＢＡ）５６、パリティグループ上のＬＤＥＶの最終アドレスを表すための最終ＬＢＡ５７、およびＬＤＥＶのサイズを表すためのサイズ５８を有する。初期フォーマットは管理者によって要求される。フォーマットデータのデフォルト値は０である。フォーマットデータはコンソール４０２経由で管理者によってＮＵＬＬまたは他の文字で再構成可能である。

ポート２２
ポート２２はＷＷＮ上の論理ユニット経由でＬＤＥＶをＳＡＮ４００に提供する。図１５はＬＵとＬＤＥＶ ＬＵＮ（論理ユニット番号）８３とＬＤＥＶ８４の間のマッピングテーブルを示す。ハードウエアポート８１列内の各値は図１のポート２２の一つに対応する。各ポート２２はホストから特定されるそれ自身のＷＷＮを有する。複数のＬＵはポート２２上に割り当て可能である。ＬＵはＷＷＮ８２とＬＵＮ８３のセットで特定される。ポート上のＬＵの最大数はＦＣ−ＳＣＳＩ仕様をベースにして２５６である。さらに、各ＬＵはホスト１０からのデータを保存するためにＬＤＥＶにマッピングされる。このマッピング情報をベースに、ＣＴＬ２０はポート２２からＳＣＳＩコマンドを受信し、適切なＬＤＥＶをアクセスするためにＷＷＮ８２とＬＵＮ８３のセットをＬＤＥＶ８４に変換する。

いくつかのＬＵはＣＭＤＤＥＶとして構成可能である。ＬＵがコンソール４０２によってＣＭＤＤＥＶとして定義される時に、図１５のＣＭＤＤＥＶ８５の行がチェックされる。ストレージ管理者はＬＵを生成し、コンソール４０２を使用してＣＭＤＤＥＶをＬＵに設定する。各ＬＵにおいて、たとえＬＵがＬＤＥＶまたはイメージを有していなくても、管理者はホストに対してＬＵを表すために仮想ＬＵとしてＬＵを構成可能である。管理者が仮想ＬＵとしてＬＵを設定する時に、ストレージサブシステムはＶＬＵビット８６をオンにする。このモードで、ストレージサブシステムはいつもＬＵ上のＬＤＥＶの割り当てに関係なくＬＵをホストに提供する。

仮想ＬＵ＆仮想ＬＵグループ（図には示されていない）
仮想ＬＵは最初ポートに関連するＬＤＥＶに非マップ化される；ストレージサブシステム上の仮想ＬＵのケースにおいて、仮想ＬＵに対するＬＵは機能コールのパラメータの一つである論理ユニット番号を有する。従って、ホストは標準ＳＣＳＩコマンドを使用してＬＵをアクセス可能である。例えば、ホストからのＳＣＳＩのｉｎｑｕｉｒｙに応答して、ＬＤＥＶが非マップ化されている事実を考慮して、仮想ＬＵは標準の応答で応答する。ＳＣＳＩのｉｎｑｕｉｒｙの結果として、ＬＵのサイズは最大可能ストレージ容量または任意のストレージサブシステム特定のサイズ、例えば２ＧＢである。しかし仮想ＬＵは何らの関連ＬＤＥＶを有さない。従って、イニシエータから来るＳＣＳＩ読み出し／書き込みオペレーションが仮想ＬＵ上で実行される時に、仮想ＬＵはエラーまたはサイズ０のような他のタイプの応答でイニシエータに応答する。

ＣｒｅａｔｅＶＬＵ機能において、ＪＮＬマネジャはポート上のＬＵＮに対応する図１５のＶＬＵ８６のエントリをマーキングする。もしもＬＤＥＶであり適用されたジャーナルであるイメージ（後で説明される）が仮想ＬＵにマッピングされると、ｉｎｑｕｉｒｙはマッピングされたＬＤＥＶのサイズであるサイズを返す。ＳＣＳＩ読み出し／書き込みオペレーションが実行される時に、ボリュームは読み出し可能である。追加の情報として、いくつかのオペレーティングシステムは接続された新しいＬＵの後にデバイス名を混ぜるので、この仮想ＬＵはデバイス名の番号の順序を固定するのに役に立つ。仮想ＬＵグループはコンシステンシグループ上のイメージのセットを仮想ＬＵのセットにリストアするのに役に立つ。

図１９は仮想ＬＵグループのテーブル３３０を示す。テーブル３３０は仮想ＬＵグループ（ＶＬＵＧ）番号３３１、ニックネーム３３２、および仮想ＬＵＮ（論理ユニット番号）＃１３３３を含み、コントローラのメモリ上に配置される。テーブルはエージェント１５のＡＰＩおよび特にＭａｐＩｍａｇｅＴｏＶＬＵとＵｎＭａｐＩｍａｇｅＦｒｏｍＶＬＵコールによって保持され、これはここより前で詳細に説明されている。コンソール４０２は仮想ＬＵグループの値を設定することができる。

ジャーナルマネジャ２４
ジャーナルマネジャはターゲットＬＤＥＶがアプリケーションマーカオペレーションを含むことに対してアフタジャーナル（ＪＮＬ）とビフォアジャーナルメカニズムを管理する。ビフォアおよびアフタジャーナルメカニズムが詳細に論議される前に、ボリューム構成が最初に説明される。

[構成]
ターゲットＬＤＥＶとアフタＪＮＬ／ビフォアＪＮＬメカニズムのボリュームの間のマッピングはＣＤＰ構成テーブル３３内のレコードとして図５に表されている。テーブルの各レコードはコンシステンシグループ番号（Ｃ．Ｇ．＃）６１，ＣＤＰ保護されたターゲットＬＤＥＶ番号６２、コマンドデバイス（ＣＭＤＤＥＶ）のＬＤＥＶ番号６３、およびアフタＪＮＬＬＤＥＶ６４とビフォアＪＮＬＬＤＥＶ６５を含むＣＤＰ保護モードを含む。もしも保護モードが可能であると、関係するボリューム情報もレコード６６から６９内に保存される。アフタＪＮＬメカニズムが可能であるケースでは、ベースＬＤＥＶ６６とＪＮＬＬＤＥＶ６７が特定される。また、ビフォアＪＮＬメカニズムが可能であるケースでは、ベースＬＤＥＶ６８とＪＮＬＬＤＥＶ６９が特定される。コンシステンシグループの設定はサーバ管理者またはＤＢＡによってそれらのＡＰＩまたはコンソールを通してホストエージェント１５経由で行われることができる。６４から６９の設定はコンソール４０２を経由してストレージ管理者によって行われる。

ＬＤＥＶの割り当てにおいて、ＬＤＥＶマネジャはＬＤＥＶプール（図６）からＬＤＥＶを提供する。そしてストレージ管理者はＬＤＥＶプール内のフリーＬＤＥＶ６８からＬＤＥＶを取得する。もしもＬＤＥＶがベースＬＤＥＶまたはＪＮＬＬＤＥＶに割り当てられると、ＬＤＥＶはＬＤＥＶプール内の“使用されている” ＬＤＥＶ６９として扱われる。

[アフタＪＮＬメカニズム]
図７はアフタＪＮＬメカニズムの図を示す。アフタＪＮＬメカニズムはホストからの書き込みＩＯの履歴を作成する。この構成には、一次ＬＤＥＶ（一次ＶＯＬ）３５、ベースＬＤＥＶ（ベースＶＯＬ）３７、ＪＮＬＬＤＥＶ（ＪＮＬＶＯＬ）３８およびコマンドデバイス（ＣＭＤＤＥＶ）３６がある。一次ＬＤＥＶはＣＤＰに対するターゲットボリュームである。ベースＬＤＥＶはＪＮＬＬＤＥＶ３８上のジャーナル処理の開始におけるコピーデータの時点、および各ジャーナルオペレーションでカウントされるシーケンス番号を有しており、ＰＩＴコピーの生成の後に番号を残す。ＪＮＬＬＤＥＶはＩＯジャーナルとマーカのような関係するＣＤＰ情報とＩＯオペレーションの情報を有する。ＣＭＤＤＥＶはＳＣＳＩインバンドコミュニケーションを使用した、ホストとストレージサブシステムの間のコミュニケーション方法を提供する。オペレーションはＣＭＤＤＥＶに対してＬＤＥＶ上の論理デバイスの範囲に対するＳＣＳＩ読み出し／書き込みコマンドによって行われる。

ＪＮＬマネジャはＪＮＬＬＤＥＶ上の現在の書き込み位置を見つけるためのＪＮＬポインタ５０を有する。ＪＮＬポインタは０から開始し、論理ブロックアドレス（ＬＢＡ）によって管理する。もしもＪＮＬボリュームがＶＴＯＣまたはＭＢＲ領域のような管理領域を有するならば、開始アドレスは管理領域のサイズだけシフトされる。

図８はターゲットＬＤＥＶに向けられた書き込みコマンドを扱うための処理手順を示し、これは図７に示されるシステムによって扱われる。以下は前述の処理手順の特定のステップの詳細な説明である。

処理手順の開始
ステップ１１１：ＪＮＬマネジャはホストから送られるＳＣＳＩＣＭＤを受信する。（図７の処理手順１）

ステップ１１２：ＪＮＬマネジャはコマンドがＷＲＩＴＥ６，ＷＲＩＴＥ１０等のようなＳＣＳＩ ＷＲＩＴＥコマンドであるか、またはそうでないかをチェックする。もしもコマンドがＷＲＩＴＥコマンドであると、処理手順はステップ１１３に進む。もしもそうでないと、処理手順はステップ１１７に進む。

ステップ１１３：ＪＮＬマネジャはイニシエータのＳＣＳＩコマンドをベースにターゲット一次ＬＤＥＶに対するデータを一次ＬＤＥＶに書き込む。（図７の処理手順２）

ステップ１１４：ＪＮＬマネジャはＪＮＬＬＤＥＶ３８上のＪＮＬポインタのＬＢＡから開始するジャーナルに対する、ヘッダ（ＨＤ）情報（後で詳細）、データ、フッタ（ＦＴ）情報を書き込む。（図７の処理手順３）

ステップ１１５：ＪＮＬマネジャはヘッダ、データ、フッタの合計サイズだけポインタを増やす。

ステップ１１６：ＪＮＬマネジャはＳＣＳＩコンディションステートを使用して書き込みの結果をホストに返す。

ステップ１１７：ＪＮＬマネジャは一次ＬＤＥＶ上でＲＥＡＤ６オペレーションのような他のＳＣＳＩコマンドを実行する。

処理手順の終了
ヘッダ／フッタ情報はヘッダ／フッタビット、システム内のＩＯを特定するためのシーケンス＃、ジャーナルデータ、マーカ等のようなどんなタイプのヘッダ／フッタであるかを示すためのヘッダ／フッタに対するＣＭＤタイプ、もしもＣＭＤタイプがジャーナルデータならばＣＭＤ，もしもＣＭＤタイプがマーカ等ならばＣＤＰ動作、ＣＤＰ動作に対する属性と属性に対するコメント、ＪＮＬマネジャがＪＮＬマネジャ内のＩＯを受信する時刻、ホストから受信されるＳＣＳＩコマンド、ジャーナルデータに対する開始アドレスとサイズ、もしも情報がフッタならばヘッダシーケンス番号を含む。

シーケンス＃はヘッダ／フッタの挿入ごとに増やされる。もしもシーケンス＃がその最大の番号より上であると、番号は０に戻ることができる。ＣＤＰ動作、属性、およびコメントは文字または２進符号データとして保つ。ＣＤＰ動作は図１３のリストをベースにしたＣＤＰ動作の名前を保持し、属性は属性のリスト６１をベースにマーカ上の属性の名前を保持し、コメントはアプリケーションとジャーナルマネジャ入力コメントを保持する。

ヘッダ／フッタ情報のサイズは、本発明では４掛けるＬＢＡの２ＫＢである。ヘッダ／フッタのサイズはより大きい容量であるため拡大できる。

ホストからのＭａｐＩｍａｇｅＴｏＶＬＵをベースにしたリストアオペレーションに関して、ストレージサブシステムはＭａｐＩｍａｇｅＴｏＶＬＵ内の時刻または“イメージを生成する”属性内の時刻とシーケンス番号によって特定されるイメージを生成する。

オペレーションの前に、このオペレーションは仮想ＬＵを使用するので、ＪＮＬマネジャは、仮想ＬＵがストレージサブシステム内で働くＭａｐＩｍａｇｅＴｏＶＬＵ機能を使用してジャーナルがＬＤＥＶに適用するイメージをマッピングするかどうかをチェックする。もしも他のイメージが仮想ＬＵ上にマッピングされていて、読み出し／書き込みアクセスが最後の１分以内に実行されていたならば、このオペレーションは、仮想ＬＵが使用されているので省かれる。もしもそうでないと、イメージはＵｎＭａｐＩｍａｇｅｆｒｏｍＶＬＵ機能の働きを使用して非マップ化され、フリーに戻る。以下は図１４（ａ）に示される処理手順のステップの詳細な説明である。

処理手順の開始
ステップ１４０：ＪＮＬマネジャは時刻またはシーケンス番号と時刻で要求されるヘッダを捜す。もしもヘッダがあると、処理はステップ１４１へ続く。もしもヘッダがないと、処理は処理の終了に進む。

ステップ１４１：ＪＮＬマネジャはＬＤＥＶプールから同じサイズのＬＤＥＶを割り当てる。同じボリュームのサイズを見つけるために、ＪＮＬマネジャはＬＤＥＶマネジャテーブル２９上のサイズ列５８内を捜す。

ステップ１４２：ＪＮＬマネジャはベースＬＤＥＶから新しいＬＤＥＶへのコピーを生成する。

ステップ１４３：ＪＮＬマネジャはベースＬＤＥＶに対する第一のジャーナルデータからジャーナルデータを見つけられたヘッダに適用する。

ステップ１４４：ＪＮＬマネジャは仮想ＬＵを通してＬＤＥＶを送り出す。

処理手順の終了
[ビフォアＪＮＬメカニズム]
図９はビフォアＪＮＬメカニズムの図を示す。ビフォアＪＮＬメカニズムは同じデータが一次ＬＤＥＶに保存されているベースボリュームに対するＪＮＬの履歴を生成する。この構成は一次ＬＤＥＶ（一次ＬＤＥＶ）３５、ベースＬＤＥＶ（ベースＶＯＬ）３５７、ＪＮＬＬＤＥＶ（ＪＮＬＶＯＬ）３５８およびコマンドデバイス（ＣＭＤＤＥＶ）３６を含む。一次ＬＤＥＶはＣＤＰに対するターゲットボリュームである。ベースＬＤＥＶ３５７はホストの書き込みオペレーションによって一次ＬＤＥＶに書き込まれた同じデータを保存し、各ジャーナルオペレーションでカウントされるシーケンス番号を有する。

ＪＮＬボリュームはベースＬＤＥＶに対するコピーオンライトジャーナルとマーカのような関係したＣＤＰ情報と入力―出力（ＩＯ）情報を有する。ＣＭＤＤＥＶはまたアフタＪＮＬメカニズムと同じく提供される。

ＪＮＬマネジャはまたＪＮＬＬＤＥＶ内の現在の書き込み位置を特定するＪＮＬポインタ３５９を有する。

この開示内容において、一次ＬＤＥＶとベースＬＤＥＶはバックアップの目的で複製がとられることが仮定されている。しかし、ベースボリューム無しでターゲットＬＤＥＶだけを使用することも可能である。従って、ベースＬＤＥＶが取り除かれる場合がある。このケースにおいて、ＪＮＬマネジャはベースＬＤＥＶ３５７の代わりにターゲット一次ＬＤＥＶ上にコピーオンライトジャーナルを保持し、ＪＮＬＬＤＥＶ３５８上にジャーナルデータを保存する。従って、図９の処理手順はステップ１，３および４を実行するが、ステップ２は実行しない。

図１０は図９に示される構成に対応するターゲットＬＤＥＶに対する書き込みコマンドの処理手順を示す。示される処理手順の特定のステップは以下で説明される。

処理手順の開始
ステップ１２１：ＪＮＬマネジャはホストから送られるＳＣＳＩＣＭＤを受信する。（図９の処理手順１）

ステップ１２２：ＪＮＬマネジャはコマンドがＷＲＩＴＥ６，ＷＲＩＴＥ１０のようなＳＣＳＩ ＷＲＩＴＥコマンドであるか、またはそうでないかをチェックする。もしもコマンドがＷＲＩＴＥコマンドであると、処理手順はステップ１２３に進む。もしもそうでないと、処理手順はステップ１２８に進む。

ステップ１２３：ＪＮＬマネジャはＳＣＳＩコマンドが送られたデータをＳＣＳＩコマンドをベースにターゲット一次ＬＤＥＶに書き込む。（図９の処理手順２）

ステップ１２４：ＪＮＬマネジャはＷＲＩＴＥオペレーションのＬＢＡとサイズで示される古いデータをベースＬＤＥＶ３５７から読み出し、ＪＮＬポインタのＬＢＡから開始するジャーナルに対するヘッダ（ＨＤ）情報（後で詳細に）、古いデータ、フッタ（ＦＴ）情報をＪＮＬＬＤＥＶ３５８に書き込む。（図９の処理手順３）

ステップ１２５：ＪＮＬマネジャはＳＣＳＩコマンドが送られたデータを送られたＳＣＳＩコマンドをベースにベースＬＤＥＶ５に書き込む。（図９の処理手順４）

ステップ１２６：ＪＮＬマネジャはヘッダ、データ、フッタのサイズをポインタに加算する。

ステップ１２７：ＪＮＬマネジャはＳＣＳＩコンディションステートを使用して書き込みの結果をホストへ返す。

ステップ１２８：ＪＮＬマネジャは一次ＬＤＥＶ上でＲＥＡＤ６のような他のＳＣＳＩコマンドを実行する。

処理手順の終了
ベースＬＤＥＶを取り除くケースでは、処理手順はステップ１２３を省略し、ステップ１２５のベースＬＤＥＶの代わりに一次ボリューム上にデータを書き込む。

ホストからのＭａｐＩｍａｇｅＴｏＶＬＵをベースにしたリストアオペレーションに関して、ストレージサブシステムはＭａｐＩｍａｇｅＴｏＶＬＵ内の時刻または“イメージを生成する”属性内の時刻とシーケンス番号によって特定されるイメージを生成する。以下は図１４（ｂ）に示される処理手順の特定のステップの説明である。

処理手順の開始
ステップ１４５：ＪＮＬマネジャはＪＮＬＶＯＬ上の時刻またはシーケンス番号と時刻をベースにしたヘッダを捜す。もしもヘッダがあると、処理はステップ１４６へ続く。もしもヘッダがないと、処理は処理手順の終了に進む。

ステップ１４６：ＪＮＬマネジャは同じサイズのＬＤＥＶをＬＤＥＶプールから割り当てる。ボリュームの同じサイズを見つけるために、ＪＮＬマネジャは図６上のフリーＬＤＥＶプール６８をベースにＬＤＥＶマネジャテーブル２９上のサイズ列５８内で一次ＬＤＥＶと同じサイズのボリュームを捜す。

ステップ１４７：ＪＮＬマネジャは新しいＬＤＥＶへのベースＬＤＥＶに対するデータの時点を生成し、ＬＤＥＶのシーケンス番号上にジャーナルの現在のシーケンス番号を残す。

ステップ１４８：ＪＮＬマネジャは要求されたシーケンス番号から新しいＬＤＥＶ上のシーケンス番号にジャーナルデータを適用する。

ステップ１４９：ＪＮＬマネジャは仮想ＬＵを通してＬＤＥＶを送り出す。

処理手順の終了
[マーカ]
アフタ／ビフォアＪＮＬメカニズムの前に、ＪＮＬマネジャ２４はコンシステンシグループ内のＣＭＤＤＥＶに対するＳＣＳＩオペレーションを監視する。コンシステンシグループはＣＤＰ構成３３内で定義されるグループ内のＣＭＤＤＥＶを含むＬＵの中でＩＯを連続させる。図１１はＪＮＬマネジャの働きを示す。

処理手順の開始
ステップ１３１：ＪＮＬマネジャはポート２２からＳＣＳＩＣＭＤを受信する。

ステップ１３２：ＪＮＬマネジャは、ＳＣＳＩＣＭＤがファイバチャネルフレーム内の見つけられたＦＣＰ＿ＬＵＮであるＬＵＮをベースにしたＣＭＤＤＥＶに対するものであるかをチェックする。ＬＵとＣＭＤＤＥＶの間の関係の定義はテーブル２５内のＣＭＤＤＥＶ８５上に記載されている。もしもＳＣＳＩＣＭＤのターゲットＬＵＮがＣＭＤＤＥＶに対するものであると、処理手順はステップ１３４に進む。もしもＳＣＳＩＣＭＤのターゲットＬＵＮがそれに対するものでないと、処理手順はステップ１３３に進む。

ステップ１３３：ＪＮＬマネジャは一次ＬＤＥＶに対するＳＣＳＩコマンドを処理する。処理手順は図５内の各保護モード６４，６５をチェックして図８内のステップ１１０と図１０内のステップ１２０へ続く。

ステップ１３４：ＪＮＬマネジャはＳＣＳＩＣＭＤが上記で説明されたＡＰＩオペレーションをベースにしたＣＤＰに対するものか、またはそうでないかをチェックする。もしもＣＭＤがＣＤＰに対するものであると、処理手順はステップ１３６に進む。もしもＣＭＤがそれに対するものでないと、処理手順はステップ１３５に進む。

ステップ１３５：ＪＮＬマネジャはＳｈａｄｏｗＩｍａｇｅ（Ｒ）のようなローカルミラーおよびＴｒｕｅＣｏｐｙのようなリモートミラーオペレーションを含むＣＭＤＤＥＶに対する他のコマンドを処理する。

ステップ１３６：ＪＮＬマネジャはＣＭＤがホストからのＩｎｓｅｒｔＭａｒｋｅｒオペレーションに対するものであるかをチェックする。もしもオペレーションがＩｎｓｅｒｔＭａｒｋｅｒであると、処理手順はステップ１３７に進む。もしもオペレーションがＩｎｓｅｒｔＭａｒｋｅｒに対するものでないと、処理手順はステップ１３８に進む。

ステップ１３７：ＪＮＬマネジャはマーカの属性をベースにしてマーカ上のアプリケーション属性と動作テーブルからＣＤＰ動作を選択する。我々は後でアプリケーション属性と動作に対する関係について論議する。およびＪＮＬマネジャは選択された動作を実行する。

ステップ１３８：ＪＮＬマネジャはＣＤＰ上のオペレーションを選択し、オペレーションを実行する。

処理手順の終了
ステップ１３７に関して、ＪＮＬマネジャはアプリケーション属性と動作テーブルからＣＤＰ動作を選択する。テーブルは図１２に示される。テーブルはコンソール４０２またはアプリケーションエージェントによって定義される。テーブルはコンソールアプリケーションエージェントからファイルとしてまたは他の種類の配置方法からロードされることができる。テーブルはＩｎｓｅｒｔＭａｒｋｅｒ機能内の示された属性パラメータである属性およびストレージサブシステム内のＣＤＰオペレーションを実行するＣＤＰ動作を含む。ＣＤＰ動作の例、図１３は動作のリストを示す。以下は動作の詳細である。

（ａ）“ビフォアＪＮＬを開始する”（６０１）

“ビフォアＪＮＬを開始する”動作のケースにおいて、ＪＮＬマネジャは一次ＬＤＥＶからベースＬＤＥＶへの時点コピー（ＰＩＴ）データを作成する。ＰＩＴの後で、ＪＮＬマネジャはホストからのＩＯを中断し、図５内の保護モード６５をオンにし、ＣＤＰ動作としての“ビフォアＪＮＬを開始する”、属性、アプリケーションからのコメントを含むマーカとしてヘッダとフッタ情報を書き込む。ＪＮＬマネジャはまた、もしもＪＮＬＬＤＥＶへのヘッダとフッタ情報内にあるならばＣＭＤタイプ、ＣＤＰ動作、属性、およびコメントを増やしたシーケンス番号で書き込む。次に、ＪＮＬマネジャはベースＬＤＥＶからＪＮＬＬＤＥＶへのコピーオンライトジャーナルを開始し、ＩＯ処理を再開する。もしも一次ＬＤＥＶとベースＬＤＥＶが同じボリュームであると、ＰＩＴオペレーションは必要でない。

（ｂ）“ビフォアＪＮＬを終了する”（６０２）

“ビフォアＪＮＬを終了する”動作のケースにおいて、ＪＮＬマネジャはＩＯジャーナル処理を中断し、一次ＬＤＥＶとベースＬＤＥＶの間の書き込みを複製した。ＪＮＬマネジャは図５内の保護モード６５をオフにし、ＪＮＬＬＤＥＶ上のアプリケーションからの“ビフォアＪＮＬを終了する”、属性、およびコメントを含むマーカとしてヘッダとフッタ情報を書き込む。ＪＮＬマネジャはまた、もしもＪＮＬＬＤＥＶへのヘッダとフッタ情報内にあるならばＣＭＤタイプ、ＣＤＰ動作、属性、およびコメントを増やしたシーケンス番号で書き込む。もしも一次ＬＤＥＶとベースＬＤＥＶが同じボリュームであると、一次ＬＤＥＶとベースＬＤＥＶの間の中断または複製されるＩＯオペレーションは必要でない。

（ｃ）“アフタＪＮＬを開始する”（６０３）

“アフタＪＮＬを開始する” 動作のケースにおいて、ＪＮＬマネジャは一次ＬＤＥＶとベースＬＤＥＶの間のＰＩＴボリュームを作成する。ＰＩＴオペレーションの後で、ＪＮＬマネジャは図５内の保護モード６４をオンにし、“アフタＪＮＬを開始する”を含むマーカとしてヘッダとフッタ情報を書き込み、次にアプリケーションからＪＮＬＬＤＥＶへのＩＯ書き込みジャーナル、属性およびコメントを開始する。ＪＮＬマネジャはまた、もしもヘッダとフッタ情報内にあるならば、ＣＭＤタイプ、ＣＤＰ動作、属性、およびコメントを増やしたシーケンス番号で書き込む。

（ｄ）“アフタＪＮＬを終了する”（６０４）

“アフタＪＮＬを終了する” 動作のケースにおいて、ＪＮＬマネジャはＩＯジャーナル処理を止める。ＪＮＬマネジャは図５内の保護モード６４をオフにし、ＪＮＬＬＤＥＶ上の“アフタＪＮＬを終了する”であるマーカとしてヘッダとフッタ情報を書き込む。ＪＮＬマネジャはまた、もしもＪＮＬＬＤＥＶへのヘッダとフッタ情報内にあるならば、ＣＭＤタイプ、ＣＤＰ動作、属性、およびコメントを増やしたシーケンス番号で書き込む。

（ｅ）“イメージを生成する”（６０５）

オペレーションは同時にマーカを挿入した後にボリュームのイメージを生成する。働きについて、ＪＮＬマネジャは最初にＪＮＬＬＤＥＶに“イメージを生成する”であるアプリケーション提供属性を示すヘッダとフッタ情報を書き込む。ＪＮＬマネジャは、既に上記で説明された各ＪＮＬメカニズムをベースにイメージを生成する。

（ｆ）“アプリケーションマーカ”（６０６）

アプリケーションはＪＮＬＬＤＥＶ上のコメントにトランザクションＩＤを含むアプリケーションの属性として残されるアプリケーションマーカを使用する。ＪＮＬマネジャはＪＮＬＬＤＥＶに“アプリケーションマーカ”であるアプリケーション提供属性を示すヘッダとフッタ情報を書き込む。

ＪＮＬマネジャはまた、もしもＪＮＬＬＤＥＶへのヘッダとフッタ情報内にあるならば、ＣＭＤタイプ、ＣＤＰ動作、属性、およびコメントを増やしたシーケンス番号で書き込む。

（ｆ）“システムマーカ”（６０７）

ＪＮＬマネジャはＪＮＬＬＤＥＶ上のコメント内にＰＩＴイベントのようなＪＮＬマネジャのイベントを残すために“システムマーカ”を使用する。

ＪＮＬマネジャはまた、もしもＪＮＬＬＤＥＶへのヘッダとフッタ情報内にあるならば、ＣＭＤタイプ、ＣＤＰ動作、属性、およびコメントを増やしたシーケンス番号で書き込む。

同時にアフタとビフォアＪＮＬメカニズムとの働き
アフタとビフォアＪＮＬは独立に同時に働くことが可能である。しかしマーカは各メカニズムへのフィルタであることができる。本特許において、図１２内の動作の６３はＪＮＬメカニズムを区別するために役に立つ。各属性に対応するＪＮＬメカニズム６３のエントリがビフォアであると、ＪＮＬマネジャはホストからのマーカをベースにビフォアＪＮＬＬＤＥＶにヘッダ／フッタ情報を書き込む。またもしもアフタであると、ＪＮＬマネジャはホストからのマーカをベースにアフタＪＮＬＬＤＥＶにヘッダ／フッタ情報を書き込み、またもしもアフタとビフォアであると、ＪＮＬマネジャはホストからのマーカをベースにアフタＪＮＬＬＤＥＶとビフォアＪＮＬＬＤＥＶの双方にヘッダ／フッタ情報を書き込む。

イメージの生成において、ストレージサブシステム３０はソースＪＮＬメカニズムを選択することができる。例えば、もしもＤＢが時刻または時刻とシーケンスによってイメージを生成することをＪＮＬマネジャに要求するならば、ＪＮＬマネジャはアフタＪＮＬメカニズムのイメージ生成を選ぶ。もしもＤＢがＨＢＳからＨＢＥへの属性の間のイメージを生成することをストレージサブシステムに要求するならば、ストレージサブシステムはビフォアＪＮＬメカニズムのイメージ生成を選ぶ。コントローラはこの設定を有する。

コンソール４０２
コンソール４０２は管理者がＬＡＮ／ＷＡＮ４０１を経由してストレージサブシステムを管理するための能力を提供する。コンソールはＬＤＥＶの生成、ＬＤＥＶから論理ユニット（ＬＵ）へのマッピンッグ、ＬＤＥＶプールの生成、ＬＤＥＶからＬＵへのマッピンッグ等のためのＧＵＩを提供する。

特に、アプリケーション属性と動作の間のリンクを作るために、コンソールはＧＵＩを提供する。図１６はＧＵＩの例を示す。二つの列がある。一つはアプリケーション属性２２１である。アプリケーション属性はＡＰＩにおいて定義され、使用される。他はＣＤＰ動作である。各属性はＣＤＰ動作を有する。ストレージ管理者またはＤＢＡは動作のリストから動作を選択する。もしも管理者またはＤＢＡが他の行を加えるかまたは行を削除することを欲するならば、ボタン２２３は最後の行に行を増やすことが可能であり、ボタン２２４は最後の行から行を減らすことが可能である。

設定の後で、管理者またはＤＢＡは適用ボタン２２５を押す。テーブル情報はＬｏａｄＡｐｐｌｉｃａｔｉｏｎＡｔｔｒｉｂｕｔｅｓＴａｂｌｅ機能を使用してストレージサブシステム３０内のアプリケーション属性―動作テーブル６０上にロードされ、次にＡｃｔｉｖａｔｅＴａｂｌｅ機能を使用してコントローラ上のテーブルをアクティブにする。

アプリケーションを有する本発明のシステムを使用するための構成
アプリケーション属性と動作テーブルが使用可能である前に、システム設定は完成されていなければならない。この構成で、ビフォアとアフタ双方のＪＮＬメカニズムがターゲット一次ＬＤＥＶに対して使用されることが仮定されている。構成は後述のようである。

図２１はストレージに対する構成を示す。ストレージ管理者はターゲット一次ＬＤＥＶ３５、ＣＭＤＤＥＶ３６、アフタＪＮＬに対する二つのベースＬＤＥＶ３７、ビフォアＪＮＬに対する３５７、アフタＪＮＬＬＤＥＶ３８，およびビフォアＪＮＬＬＤＥＶ３５８を割り当て、ターゲット一次ＬＤＥＶとＣＭＤデバイスをポート２２に接続されたホスト上のＬＵにマッピングし、およびターゲット一次ＬＤＥＶ、ベースＬＤＥＶおよび図５内においてコンソール４０２を経由してＣＤＰ構成３３を構成するＪＮＬＬＤＥＶの間の関係を作成する。サーバ管理者はコンシステンシグループを生成する。

ストレージ管理者はまたコンソール５０またはエージェント１６を経由してコンシステンシグループに対する仮想ＬＵと仮想ＬＵグループを生成し、データをリスアするためにＬＤＥＶプール６８上の一次ＬＤＥＶと同じサイズを有するフリーＬＤＥＶを準備する。

サーバシステム管理者はホスト１０上にＯＳをインストールし、ターゲットＬＤＥＶとＣＭＤＤＥＶを含むＬＵを発見する。続いて、ＤＢＡまたはサーバ管理者はホスト上にエージェント１５をインストールし、ＣＭＤデバイスとの接続を確立する。

その後で、ＤＢＡは、アプリケーションのイベントをベースにエージェント１５のＡＰＩにコールを発行可能な、データベース（ＤＢ）アプリケーションのようなアプリケーションをホスト１５内にインストールする。

アプリケーション属性―動作テーブル６０は二つの方法を使用して定義されることができる。この一つの方法に従って、管理者はデータベース（ＤＢ）提供構成ファイル１７をベースにしてこのテーブルを定義する。ＤＢＡまたはストレージ管理者はデータベースによって提供される構成ファイル１７をベースにしてコンソール４０２のＧＵＩまたはホスト１０のエージェント１５のコマンドラインインタフェースを使用してアプリケーション属性―動作テーブル６０を生成する。もしもホスト１０が使用されると、テーブル情報はＬｏａｄＡｐｐｌｉｃａｔｉｏｎＡｔｔｒｉｂｕｔｅＴａｂｌｅ機能ベースのコマンドを使用してコントローラ２０にロードされ、次にテーブルはＡｃｔｉｖａｔｅＴａｂｌｅ機能ベースのコマンドを使用してアクティブにされる。他の方法はＬｏａｄＡｐｐｌｉｃａｔｉｏｎＡｔｔｒｉｂｕｔｅＴａｂｌｅ機能を使用して構成テーブルをロードし、次にＡｃｔｉｖａｔｅＴａｂｌｅ機能を使用してそれをアクティブにすることを含む。

属性に関して、この説明において、属性はＤＢの内部コマンドであることが仮定されている。もしも他の内部コマンドがあると、適切なコマンド属性マッピングが生成されることが可能である。対応するマッピングテーブルが図２０内に示される。

システムの振る舞い
図１７と図１８は、アプリケーションがＣＤＰに対する属性機能を使用する時の使用ケースを示す。

特に、図１７は、このアプリケーションがノーマルオペレーションの間に後述のオペレーションを実施するバックアップの振る舞いの例を示す。

振る舞いの開始
ステップ３０１：ＤＢＡはターゲット一次ＬＤＥＶ上に保存されるマウントテーブルスペースオペレーションをＤＢに発行する。

ステップ３０２：ＤＢはマーカを経由してマウントの属性（ＭＴ）を発行する。

ステップ３０３：ストレージサブシステムはアプリケーション属性と動作テーブルをベースにアフタＪＮＬを開始する動作（６０３）を実行する。

ステップ３０４：ストレージサブシステムのＡＣＫの後で、ＤＢはテーブルスペースをマウント処理する。ＤＢのクライアントアプリケーションはマウントオペレーションの後でＳＱＬコマンドセットを実行する。

ステップ３０５：ＤＢは、ＤＢがデータベーステーブルに対するコンシステンシステートを示し、それらのオペレーションを止めるチェックポイントを実行し、ＤＢはテーブル３３５をベースにマーカを経由してＣＰの属性を発行する。

ステップ３０６：ストレージサブシステムはテーブルをベースにイメージを生成するオペレーションを実行する。

ステップ３０７：ストレージサブシステムのＡＣＫの後で、ＤＢはＳＱＬコマンドセットを実行し続ける。

ステップ３０８：ＤＢＡはＤＢへのホットバックアップモードを開始する。

ステップ３０９：ＤＢはホットバックアップモードを開始した後でマーカを経由してＨＢＳ属性を発行する。

ステップ３１０：ストレージサブシステムはテーブル６０をベースにビフォアＪＮＬを開始する動作（６０１）を実行する。

ステップ３１１：ストレージサブシステムのＡＣＫの後で、ＤＢはホットバックアップモードになる。

ステップ３１２：ＤＢはＤＢＡにプロンプトを返す。

ステップ３１３：ＤＢは、エージェントＩｎｓｅｒｔＭａｒｋｅｒＡＰＩ経由のトランザクションの各コミットの後でシステムコミット番号のようなトランザクション番号を有するアプリケーションマーカを挿入することを要求する。トランザクション番号はマーカ内のコメントフィールド上に保存される。

ステップ３１４：ストレージサブシステムはアプリケーションマーカオペレーションを実行する。

ステップ３１５：ストレージサブシステムのＡＣＫの後で、ＤＢはそれらのトランザクションを処理し続ける。

ステップ３１６：ＤＢＡはホットバックアップモードの終了を要求する。

ステップ３１７：ＤＢはテーブル３３５をベースにホットバックアップモードの後でマーカを経由してＨＢＥ属性を発行する。

ステップ３１８：ストレージサブシステムはテーブル６０をベースにビフォアＪＮＬを終了する動作（６０２）を実行する。

ステップ３１９：ストレージサブシステムのＡＣＫの後で、ＤＢはホットバックアップモードを終了し、ＳＱＬコマンドセットを実行し続ける。

ステップ３２０：ＤＢＡはそれらのプロンプトを受信する。

ステップ３２１：ＤＢＡはテーブルスペースをアンマウント処理する。

ステップ３２２：ＤＢはテーブルスペースをアンマウント処理し、テーブル３３５をベースにマーカ経由でＭＴＥ属性を発行する。

ステップ３２３：ストレージサブシステムはテーブル６０をベースにアフタＪＮＬを終了する動作（６０４）を実行する。

ステップ３２４：ストレージサブシステムのＡＣＫの後で、ＤＢはＤＢＡに結果を返す。

ステップ３２５：ＤＢＡはそれらのプロンプトを受信する。

振る舞いの終了
リストアオペレーションに関して、ＤＢＡはエージェントのＡＰＩを経由してストレージサブシステムへのホットバックアップモードに取り入れられるイメージを要求する。ＤＢ経由のＤＢＡからの要求はＳｅｒｃｈＭａｒｋｅｒのＡＰＩを使用してＨＢＳ属性を検索し、ＨＢＳマーカのリストを受信し、ＭａｐＩｍａｇｅＴｏＶＬＵまたはＭａｐＣＴＧｔｏＶＬＵＧのＡＰＩを使用してＨＢＳマーカのリストから選択されるシーケンスと時刻によって特定されるイメージを要求することである。ＤＢＡはＶＬＵからのバックアップデータを使用可能である。ＤＢ上のデータをリカバリするために、ＤＢＡは、ＣＤＰはほんのわずかな中断でＤＢログとテーブルスペースを取るので、ＤＢのロールフォワード処理を使用してＤＢのログをＤＢのテーブルスペースに適用する。

もしもＤＢＡがトランザクション番号にロールバック処理とロールフォワード処理をする必要があると、ＤＢのログとテーブルスペースはロールバック情報を有しない。この状況において、本発明はロールバックをリカバリするために役に立つ。もしもイメージが修正されてないと、ストレージはユーザ要求属性のシーケンスを有するヘッダからイメージのシーケンス番号までジャーナルデータを適用する。ビフォアまたはアフタジャーナルを選択するために、もしも要求された番号がイメージのシーケンス番号より下ならば、ＪＮＬマネジャはビフォアＪＮＬを選択する。またもしも要求された番号がそれより上ならば、ＪＮＬマネジャはアフタＪＮＬを選択する。

例えば（図２１）、ＶＬＵにマッピングされシーケンス番号として２６を有するイメージ３４１がある。もしもＤＢＡがＳＣＮ１１内にシーケンス番号として４０をリストアすることを欲すると、ＪＮＬマネジャはアフタＪＮＬを選択する。一方で、もしもＤＢＡがＳＣＮ９内にシーケンス番号として２３をリストアすることを欲すると、ＪＮＬマネジャはビフォアＪＮＬを選択する。

利点を考慮したアプリケーションの振る舞いは以下のようである。

ステップ３０１と３１５を使用するマウント処理／アンマウト処理オペレーションに関して、ジャーナルの長さはＤＢの非アティブの間に削除可能である。

ステップ３０６であるチェックポイントオペレーションに関して、管理者は前に生成されたボリュームイメージを使用可能である。

ステップ３０９と３１２であるバックアップを開始する／終了するオペレーションに関して、ＤＢはアフタＪＮＬメカニズムを使用してロールバックイメージを生成可能である。

リカバリに関して、もしもＤＢがバックアップモードに入っても、ＤＢはリストアに関するデータをロールバック処理することが可能である。

図１８は他の例を示し、これはリカバリ処理手順の間に以下のオペレーションを実行するアプリケーションを含む。この例で、データベースまたは関係の情報が失われると、ＤＢＡが責任を引き受ける。

振る舞いの開始
ステップ３４１：ＤＢＡはＲＥＣＯＶＥＲ ＴＡＢＬＥＳＰＡＣＥのようにテーブルスペースをリカバすることをデータベースに示す。

ステップ３４２：オペレーションの後で、ＤＢはエージェントＩｎｓｅｒｔＭａｒｋｅｒのＡＰＩを経由してテーブル３３５をベースにＲＴＳ属性を含むマーカを挿入する。

ステップ３４３：ストレージサブシステムはテーブル６０をベースにしたＲＴＳ属性をベースにビフォアＪＮＬを開始する動作（６０１）を実行する。

ステップ３４４：ストレージサブシステムのＡＣＫの後で、ＤＢはそれらのログからトランザクションに対するリカバリオペレーションを処理することを開始する。

ステップ３４５：ＤＢは、エージェントＩｎｓｅｒｔＭａｒｋｅｒのＡＰＩを経由してジャーナル上に書き込まれるトランザクションの各コミットの後にシステムチェンジ番号（ＳＣＮ）のようなトランザクション番号を有するマーカを挿入する。トランザクション番号はマーカ内のコメントフィールド上に保存される。

ステップ３４６：ストレージサブシステムはアプリケーションマーカオペレーションを実行する。

ステップ３４７：ストレージサブシステムのＡＣＫの後で、ＤＢはそれらのログからトランザクションに対するリカバリオペレーションを処理することを続ける。

ステップ３４８：ＤＢＡはＤＢからのリカバリに関する現在の実行トランザクション番号を受信する。

ステップ３４９：ＤＢがすべてのログを適用した後で、ＤＢはリカバリテーブルスペースの終了を知らせるマーカＲＴＥを発行する。

ステップ３５０：ストレージサブシステムはテーブル６０をベースにビフォアＪＮＬを終了する動作（６０２）を実行する。

ステップ３５１：ストレージサブシステムのＡＣＫの後で、ＤＢは結果をＤＢＡに返す。

ステップ３５２：ＤＢはＤＢＡに対してプロンプトを返す。

振る舞いの終了
ＤＢＡがロールフォワードオペレーションの後にデータのリストア処理を終了した時に、もしもＤＢＡがＪＮＬのコメントフィールド内のＳＣＮ番号によってマーカを検索することをＳｅａｒｃｈＭａｒｋｅｒ機能コールによってＤＢに要求すると、ストレージサブシステムはヘッダの一部分として書き込まれたマーカのリストを提供する。マーカのリストから、ＤＢＡはコメント内に現れるＳＣＮに対応するイメージを回復するためのシーケンス＃と時刻を選択する。次にＤＢＡはシーケンス＃によって特定されたボリュームを取得することをＭａｐＣＴＧｔｏＶＬＵＧ機能コールを使用してＤＢに要求する。ストレージサブシステムは仮想ＬＵグループ上で特定される仮想ＬＵ上のイメージのセットを提供する。ＤＢは仮想ＬＵマッピングの後にテーブルスペースをマウント処理することができる。

最後に、ここで説明された処理と技術はいかなる特定の装置に本来的に関係しているものではなく、構成要素の任意の適切な組み合わせによって具体化されることができることは理解されるべきである。さらに、多様なタイプの一般目的のデバイスはここで説明された教えに従って使用されることができる。ここで説明された方法のステップを実行するために特別の装置を構築することはまた有益である。本発明は特定の例に関係して説明され、これはあらゆる点で限定的よりも説明的であることを意図している。この技術に精通する人達はハードウエア、ソフトウエア、およびファームウエアの多くの異なる組み合わせが本発明を実施するために適切であることを理解する。例えば、説明されたソフトウエアはアセンブラ、Ｃ／Ｃ＋＋，ｐｅｒｌ、ｓｈｅｌｌ、ＰＨＰ，Ｊａｖａ（登録商標）等の多種類のプログラミングまたはスクリプティング言語で具体化できる。

さらに、本発明の他の具体化は明細書の考察およびここで開示された本発明の実施からこの技術に精通する人達に明かである。説明された実施例の多様な側面および／または構成要素はデータ複製機能を有するコンピュータ化されたストレージシステム内で単独にまたは任意の組み合わせで使用されることができる。仕様と例は典型的なものとしてだけと考えられ、本発明の真の範囲と精神は後述の請求項によって示されることを意図している。

図１は本発明の実施例による典型的なシステムアーキテクチャを表す。 図２は本発明のシステムの多様なソフトウエア構成要素の典型的な論理構成とそれらの間の相互動作を示す図である。 図３はエージェントアプリケーションの典型的なアプリケーションプログラミングインタフェースを示す。 図４は典型的な論理デバイスマネジャテーブルを示す。 図５は本発明のＣＤＰシステムの典型的な構成を示す。 図６は本発明のシステム内の論理デバイスのプールを示す。 図７はアフタジャーナルモニタの典型的な振る舞いを示す。 図８はターゲット論理デバイスに向けられた書き込みコマンドを扱うための処理手順を示す。 図９はビフォアジャーナルモニタの典型的な振る舞いを示す。 図１０はターゲット論理デバイスに対する書き込みコマンドを扱うための典型的な処理手順を示す。 図１１は本発明のジャーナルマネジャのオペレーションを示す。 図１２は特定の属性に対応する動作を示す典型的なアプリケーション属性と動作テーブルを表す。 図１３は本発明のＣＤＰシステムの動作のリストを提供する。 図１４はビフォアとアフタジャーナルを使用したリストア処理の典型的な動作シーケンスを示す。 図１５は論理ユニットから論理デバイスへのマッピングテーブルの典型的な実施例を示す。 図１６は本発明のＣＤＰシステムの典型的なグラフィカルユーザインタフェースを示す。 図１７と図１８は本発明の属性機能によってアプリケーションと相互に作用する本発明のＣＤＰシステムのオペレーションを示す。 図１７と図１８は本発明の属性機能によってアプリケーションと相互に作用する本発明のＣＤＰシステムのオペレーションを示す。 図１９は仮想論理ユニットグループに関する情報を保存するテーブルの典型的な実施例を示す。 図２０はデータベースアプリケーションの内部イベントと本発明のＣＤＰシステムの対応する属性の間のマッピングを提供する。 図２１は本発明の実施例に従ったストレージシステムの典型的な構成を示す。

Claims (51)

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. 前記のコンピュータで読み出し可能な命令がさらに
    ｉ． 前記の仮想論理ユニットのサイズに対する要求を受信し、
    ｉｉ． もしも前記の仮想論理ユニットに関連する論理デバイスがあると、前記の論理デバイスの前記のサイズを返し、
    ｉｉｉ． もしも前記の仮想論理ユニットに関連する論理デバイスがないと、０またはエラーを返す
    ことを前記の一つ以上のプロセッサに行わせることを特徴とする請求項４８に記載のコンピュータで読み出し可能な媒体。

Images