JP2008004090A - トランザクションモニタリング能力を有するストレージシステム - Google Patents

Abstract

【課題】ストレージシステムにおいてアプリケーションプログラムのトランザクションを管理し、任意の時点でのデータをリカバリ処理する方法を提供する。
【解決手段】ストレージシステムはトランザクションの開始を示す命令を受信し、トランザクションに対するデータを受信するために少なくとも一つの一次ボリュームを決定する。ストレージシステムはまたトランザクションに関連した一次ボリュームに対して指定された書き込みデータを最初に保存するためにログボリュームを提供する。トランザクションが首尾よく完了すると、トランザクションに対してログボリューム内に保存されたデータは一次ボリュームに適用される。
【選択図】図３

Description

本発明は、一般的にはストレージシステムに、および、より具体的には、データ保護を可能にしながら複数のデータアクセス要求を同時に扱う方法に関係する。

継続的データ保護（ＣＤＰ）

継続的データ保護（ＣＤＰ）は、いかなる変更がデータになされる時にもいつもデータがバックアップ処理されるシステムを提供する。継続的データ保護（ＣＤＰ）は、ユーザがリストアオペレーションを実行するための実際の用意ができるまでユーザがデータをリカバリ処理したいと思う時点をユーザが特定する必要がない点で従来のデータバックアップとは異なる。従来のデータバックアップシステムは、一時間、一日、一週間などの、バックアップが行われたある不連続な時点へデータをリストア処理することだけが可能である。しかし、継続的データ保護では、バックアップのスケジュールは存在しない。むしろ、データがディスクに書き込まれる時に、ネットワーク上の他のストレージシステムのような第二の位置にも非同期に書き込まれる。これはディスク書き込みオペレーションになんらかのオーバヘッドをもたらすが、しかし夜間にスケジュールされたバックアップ処理などの必要性を削除する。

従って、ＣＤＰの基本的目的は、データがリカバリ処理されることが必要になる任意の求められるまたは不可欠な時点のデータのリカバリ処理を可能にすることである。実際に、ＣＤＰは、ストレージスナップショット全体、すなわちデータ修正が発生する時点ごとに一つのストレージスナップショットの、継続的なジャーナルまたはログを生成する。ＣＤＰの方法において、ストレージシステム、ホストコンピュータ内のバックアップソフトウエア、または他のハードウエアかソフトウエアはホストコンピュータファイルシステムからの書き込みＩ／Ｏを捕らえ、ログ（時には“ジャーナル”と呼ばれる）として書き込みＩ／Ｏの全てを記録する。またＣＤＰが開始される時に、システムは最初プロダクションボリューム（すなわち、ユーザがデータをバックアップ処理されるようにしたいと思うボリューム）のスナップショットコピーを保持し、これはＣＤＰが開始される時のボリュームの初期イメージである。データをリカバリ処理する時に、ボリュームの初期イメージに対してジャーナルを適用することによって、ＣＤＰの方法は、書き込みＩ／Ｏが一次ボリュームに作成された任意の時点のデータのリカバリを可能にする。

ＣＤＰシステムはブロック−ベースまたはファイル−ベースのシステムであることができる。ブロック−ベースシステムは論理デバイスのブロックレベルで動作し、データブロックが一次ストレージボリュームに書き込まれる時に、書き込まれるデータのコピーがタイムスタンプとなんらかの形の位置データと共にジャーナルに保存される。アプリケーション−レベルの統合はＡＰＩ（ＯｒａｃｌｅまたはＳＱＬサーバのような、Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅｓ）を通してである。ＡＰＩを通しての統合は通常データコンシステンシに対して必要である。

ファイル−ベースの解決方法はブロック−ベースの解決方法と同様な方法で動作する。しかし、ファイル−ベースＣＤＰの解決方法はボリューム全体をリカバリ処理しなければならないよりもファイルレベルでデータをリカバリ処理することがしばしば可能である。さらに、全てのプラットフォームに亘る共通のファイルレベルの解決方法は存在しない、従って、ファイルレベルシステムは特定のアプリケーションとプラットフォームだけに適用可能である。

従って、ＣＤＰの主要な利点はストレージシステム内に生じる全てのトランザクションが記録されることである。さらに、もしもストレージシステムがウイルスで汚染されると、またはもしもシステム内のファイルが破損されるか誤って削除され、問題がしばらく後まで発見されないと、ユーザはファイルの最も近い、破損されていないバージョンにリカバリ処理可能である。さらに、ディスクアレイストレージシステム上に設定されたＣＤＰシステムは数秒でのデータリカバリを可能にし、これはテープのバックアップまたはアーカイブで見込まれるより非常に短時間である。

アプリケーションプログラムトランザクション

アプリケーションプログラムは通常別々の作業単位を一緒に作り上げるいくつかの要求またはデータ更新または他のタスクを含むオペレーションを実行する。これらの別々の作業単位のそれぞれは“トランザクション”と呼ばれる場合がある。トランザクションは典型的には全体でグループとして成功するかまたは失敗するはずの論理オペレーションのグループである。従って、首尾よく実行されるトランザクションに対しては、トランザクションの部分を形成する複数のタスクの各タスクは首尾よく実行されなければならない。例えば、ＡＴＭ（ａｕｔｏｍａｔｅｄ ｔｅｌｌｅｒ ｍａｃｈｉｎｅ）からのお金の引き出しは顧客には単一のオペレーションに見えるかもしれないが、これは実際には二つの主要なオペレーションを有するトランザクションとして考えられることが可能である。（１）お金が支払われなければならない。および（２）顧客の銀行口座は支払われた額を差し引かれなければならない。もしもお金が、顧客の口座で差し引く事無く支払われると、銀行はお金を失う。従って、実行されるトランザクションに対して両方のオペレーションが行われなければならない。さらに、これらの二つの主要なオペレーションのそれぞれはいくつかのサブオペレーションを含む。従って、これらのサブオペレーションの全部もまたトランザクションが成功であるように実行されなければならない。

トランザクションの各タイプは、各アプリケーションプログラム内で、すなわち、アプリケーションプログラムのそれぞれが動作する一つのホストコンピュータまたは一組のホストコンピュータ内で特別に定義された概念であるので、ストレージシステムは通常、Ｉ／Ｏオペレーションが特定のアプリケーションプログラムに対してトランザクションの始め、中間、または終わりかを区別できない。従って、ストレージシステムが、ＣＤＰによってのような、各Ｉ／Ｏにおいてデータをリカバリ処理する能力を有している時さえも、トランザクションの終わりまたはトランザクションの始めにおけるその状態に従ってデータがリカバリ処理されないと、リカバリ処理されたデータは使い物にならないかも知れない。

以下の米国特許出願公開公報は、基本機能がストレージシステム内で実行されるＣＤＰ概念と方法を教示しており、これらの資料の開示内容はそのまま全体を参照してここに組み込まれる。ＵＳ２００４／０２６８０６７、Ｙａｍａｇａｍｉ、名称が“Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ｂａｃｋｕｐ ａｎｄ Ｒｅｃｏｖｅｒｙ Ｓｙｓｔｅｍ ｕｓｉｎｇ Ｓｔｏｒａｇｅ Ｂａｓｅｄ Ｊｏｕｒｎａｌｉｎｇ”；ＵＳ２００５／００１５４１６、Ｙａｍａｇａｍｉ、名称が“Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ｄａｔａ Ｒｅｃｏｖｅｒｙ ｕｓｉｎｇ Ｓｔｏｒａｇｅ Ｂａｓｅｄ Ｊｏｕｒｎａｌｉｎｇ”；ＵＳ２００５／００２２２１３、Ｙａｍａｇａｍｉ、名称が“Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ｓｙｎｃｈｒｏｎｉｚｉｎｇ Ａｐｐｌｉｃａｔｉｏｎｓ ｆｏｒ Ｄａｔａ Ｒｅｃｏｖｅｒｙ ｕｓｉｎｇ Ｓｔｏｒａｇｅ Ｂａｓｅｄ Ｊｏｕｒｎａｌｉｎｇ”；ＵＳ２００５／００２８０２２、Ａｍａｎｏ、名称が“Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ｄａｔａ Ｒｅｃｏｖｅｒｙ Ｓｙｓｔｅｍ ｕｓｉｎｇ Ｓｔｏｒａｇｅ Ｂａｓｅｄ Ｊｏｕｒｎａｌｉｎｇ”；およびＵＳ２００５／０２３５０１６、Ａｍａｎｏ他、名称が“Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ａｖｏｉｄｉｎｇ Ｊｏｕｒｎａｌ Ｏｖｅｒｆｌｏｗ ｏｎ Ｂａｃｋｕｐ ａｎｄ Ｒｅｃｏｖｅｒｙ Ｓｙｓｔｅｍ ｕｓｉｎｇ Ｓｔｏｒａｇｅ Ｂａｓｅｄ Ｊｏｕｒｎａｌｉｎｇ”。しかし、これらの出願のどれも、複数のアプリケーションプログラムによる複数の要求または動作で構成されるトランザクションを管理する方法を開示していない。

複数のアプリケーションプログラムが動作している環境において、データコンシステンシを完全に扱うために、データを扱う二つの方法がある。１）全てのアプリケーションプログラムはデータコンシステンシを扱うことが可能であり、全てのアプリケーションプログラムはトランザクションを管理するために互いに協力する、または２）ストレージシステムはトランザクションを扱う能力を有する。第一の選択（１）の下で、全てのアプリケーションプログラムは互いに適合するために修正されなければならないので、第二の選択（２）を採用し、ストレージシステムがデータコンシステンシを管理可能にすることが望ましい。しかし、一つ以上のホストコンピュータが存在し、複数のアプリケーションプログラムが動作している環境で、ストレージシステムは通常どのＩ／Ｏオペレーションがアプリケーションプログラムに対するトランザクションの開始または終わりであるかを知らない。従って、トランザクションの開始または終わりでデータをリカバリ処理する能力に対する必要性がある。

一つの側面の下で、本発明は、ストレージシステムにおいてトランザクションを管理し、およびアプリケーションプログラムの観点からトランザクションの開始または終了からの任意の時点でストレージシステム内のデータをリカバリ処理する方法を提供する。

本発明のストレージシステムは複数のアプリケーションプログラムからトランザクションの開始および／またはトランザクションの終了に関する情報を受信する手段を含む。ストレージシステムがトランザクションの開始を示す通知を受信した時に、更新Ｉ／Ｏオペレーションがログディスクに記録される。ストレージシステムがトランザクションの終了の通知を受信した時に、ログディスク内の記録されたデータが作業ボリューム内に適用される。

本発明のこれらのおよび他の特徴と利点は好適な実施例の後述の詳細な説明を考慮してこの技術に通常程度に精通した人達に明らかになる。

添付の図面は、上記の一般的な説明、および下記の好適な実施例の詳細な説明と関連して、ここで考慮する本発明の最善の好適な実施例の原理を図示し説明するのに役に立つ。

本発明の後述の詳細な説明において、開示内容の一部分を形成する添付の図面が参照され、ここで本発明が実施される特定の実施例が図示により示されるが、限定するものではない。図面において、同じ番号はいくつかの図を通して実質的に同様の要素を説明する。さらに、図面、前述の議論、後述の説明は典型的および説明的なだけであり、いかなる意味でも本発明の範囲を限定する意図はない。

第一の実施例―システム構成

図１は本発明の方法と装置が適用されるシステムの例を示す。システムは一つ以上のホストコンピュータ１（ここ以後で“ホスト１”と呼ばれる）、およびストレージシステム２で構成される。ホスト１は、直接接続２７経由で、またはストレージエリアネットワーク２８の部分としてファイバチャネル（ＦＣ）スイッチ（ＦＣ−ＳＷ）４経由で、ストレージシステム２とコミュニケーションのために接続されることができる。さらに、ホスト１はＬＡＮスイッチ６を含むローカルエリアネットワーク（ＬＡＮ）２９経由で互いにコミュニケーションを行うことが可能である。ＬＡＮスイッチ６の物理インタフェースはこの実施例においてはイーサネット（登録商標）であるが、ネットワーキングプロトコールの他のタイプであることもできる。

ホスト１はＵＮＩＸ（登録商標）またはＷｉｎｄｏｗｓ（登録商標）のオペレーティングシステムを実行するＰＣ／ＡＴ互換のコンピュータまたはワークステーションであることができる。他の実施例において、ホスト１はＩＢＭのＯＳ／３９０（登録商標）またはｚ／ＯＳ（登録商標）のオペレーティングシステムを実行するメインフレームコンピュータであることができる。ホスト１は少なくともＣＰＵ１１、メモリ１３、ネットワークインタフェースコントローラ（ＮＩＣ）１４、およびＨＢＡ（ｈｏｓｔ ｂｕｓ ａｄａｐｔｅｒ）１２で構成される。ホスト１はＨＢＡ１２経由でストレージシステム２内にデータを保存し、アクセスする。

ディスクストレージシステム２は、ハードディスクドライブのような、少なくとも一つの物理デバイス３０に接続されるディスクコントローラ２０を含む。ディスクコントローラ２０は少なくともＣＰＵ２１、メモリ２３、キャッシュメモリ２５、ＮＶＲＡＭ（ｎｏｎｖｏｌａｔｉｌｅ ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）２６、一つ以上のファイバチャネル（ＦＣ）インタフェース２４および一つ以上のディスクインタフェース２２を含む。これらの要素は以下のように機能する。

ＣＰＵ２１はホストＩ／Ｏ要求を処理し、物理デバイス３０との間でデータを保存しおよび取り出す、などのためのソフトウエアプログラムを実行する。本発明に関係のある特定のプログラムの詳細は以下に説明される。

メモリ２３はＣＰＵ２１で実行されるソフトウエアプログラムを保存するために使用されるコンピュータで読み出し可能な媒体であり、物理デバイス３０内に保存されるデータを保存しおよび管理するために必要な情報を保存するために使用される。

キャッシュメモリ２５はホスト１から書き込まれるデータを一時的に保存するために使用され、またはホスト１へのストレージシステム２の応答時間を短縮するためにホスト１によって読み出されるデータを保存するために使用される。もしもストレージシステム２が障害をおこしてもデータが保持されるように、キャッシュメモリ２５はバッテリーバックアップメモリである場合がある。

ＮＶＲＡＭ２６は、ストレージシステムが最初に電源投入された時に機能するブートプログラムを保存するために使用される。ストレージシステム２がブート処理を開始する時に、ＮＶＲＡＭ２６内のプログラムはメモリ２３内にロードされ、ＣＰＵ２１によって実行される。

ＦＣインタフェース（ＦＣＩ／Ｆ）２４はホスト１とのコミュニケーションのためにストレージシステムを接続する。代わりに、ＦＣＩ／Ｆ２４は、イーサネット（登録商標）インタフェース、またはストレージシステム２がホスト１とデータをコミュニケーションすることが可能な他のインタフェースである場合がある。

ディスクインタフェース２２は少なくとも一つの物理デバイス３０をコントローラ２０に接続するために使用される。本実施例において、ディスクインタフェース２２（ここ以後では“ディスクＩ／Ｆ２２”と呼ばれる）はファイバチャネルインタフェースであり、物理デバイス３０はファイバチャネルプロトコルに従ってディスクコントローラ２０によってアクセスされるファイバチャネルディスクデバイスである。他の実施例において、ディスクＩ／Ｆ２２はＡＴＡインタフェースであることができる。このケースでは、ディスクＩ／Ｆ２２に接続される物理デバイス３０は、ＡＴＡプロトコルに従ってディスクコントローラ２０によってアクセスされるＡＴＡ（シリアルＡＴＡまたはパラレルＡＴＡ）ディスクデバイスである。

この開示内容において、ストレージデバイスを参照する時に、物理デバイス、論理デバイス、および仮想デバイスのようないくつかの異なる用語が使用される。これらの用語は以下のように一般的に定義されることができる。

物理デバイス：物理デバイス３０は好ましくはデータを保存するためのハードディスクドライブであり、好ましい実施例においてはＦＣディスクドライブであるが、ＳＡＴＡディスクドライブまたは他のタイプのディスクドライブも使用されることができる。代わりに、あるアプリケーションでは、物理デバイス３０は半導体メモリ、光ディスク、または他のマスストレージデバイスである場合がある。

論理デバイス：ディスクコントローラ２０は複数の物理デバイスを使用する少なくとも一つの論理デバイスを構築する。図２は論理デバイス３１の概念図を示す。図２内の論理デバイス３１は四つの物理デバイス３０（ディスク３０−１、３０−２、３０−３および３０−４）で構成される。１，１；２，１；などとラベル付けされた各領域は“ストライプ”と呼ばれる。Ｐ１、Ｐ２、などのラベル付けされた領域は“パリティストライプ”と呼ばれ、これは対応するストライプのパリティデータを保存するために使用される。図２は一つの論理デバイス３１が複数の物理デバイス３０から生成される例を示す。他の実施例では、一つより多い論理デバイスが複数の物理デバイスから定義される場合があり、または一つより多い論理デバイスが一つの物理デバイスから定義される場合がある。

仮想デバイス：ディスクコントローラ２０は少なくとも一つの論理デバイスを使用する少なくとも一つの仮想デバイスを構築する。仮想デバイスは論理デバイスのスナップショットイメージを生成するために構築される。これの追加の詳細は以下で説明される。

機能図

図３は図１に示されるシステムの機能図を示す。ホスト１およびディスクコントローラ２０内のメモリ１３と２３のそれぞれに、本発明を実現するための複数のソフトウエアモジュールが存在する。ＣＰＵ１１はホスト１内のこれらのソフトウエアモジュールを実行し、ＣＰＵ２１はコントローラ２０内のソフトウエアモジュールを実行する。これらのソフトウエアモジュールは、実行される時に、好ましくはメモリ１３と２３内に保存されるが、これらはまたハードディスク、光ディスク、または他のコンピュータで読み出し可能な媒体上に、ローカル的にまたは遠隔的に、全体でまたは部分的に保存される場合がある。ホスト１上で実行されるソフトウエアモジュールはアプリケーションプログラム１３３、オペレーティングシステム１３２、およびトランザクションＩ／Ｏドライバ１３１を含む。これらのソフトウエアモジュールのそれぞれの目的と機能は以下のようである。

アプリケーションプログラム１３３：アプリケーションプログラム１３３（ここ以後は“アプリケーション１３３”または“ＡＰ１３３”と呼ばれる）はリレーショナルデータベース管理システム（ＲＤＢＭＳ）、ワールドワイドウエブサーバなどのような、望みの機能を実行するためにホスト１上で動作するプログラムである。

オペレーティングシステム１３２：オペレーティングシステム１３２はＡＰ１３３が実行されることを可能にする基本的基盤を提供する。

トランザクションＩ／Ｏドライバ１３１：これは、ＡＰ１３３がトランザクションを扱う時にＡＰ１３３によって使用されるデバイスドライバモジュールである。他の実施例では、トランザクションＩ／Ｏドライバ１３１はＯＳ１３２の一部分である場合がある。さらに他の実施例では、トランザクションＩ／Ｏドライバ１３１は、ＡＰ１３３が必要に応じてトランザクションＩ／Ｏドライバ１３１にリンク可能となるように、動的または静的リンクライブラリプログラムとして提供される場合がある。

ＣＰＵ２１によってコントローラ２０内で実行されるソフトウエアモジュールは論理デバイスマネジャ２３１、トランザクションモニタ２３２、およびＩ／Ｏプロセス２３３を含む。これらのソフトウエアモジュールのそれぞれの目的と機能は以下のようである。

論理デバイスマネジャ２３１：このソフトウエアモジュールは一つ以上の物理デバイス３０から一つ以上の論理デバイス（図２の論理デバイス３１のような）を定義する。論理デバイスマネジャ２３１はまた特定された論理デバイスのスナップショットイメージを生成することが可能である。

トランザクションモニタ２３２：トランザクション処理命令がトランザクションＩ／Ｏドライバ１３１経由でホスト１から受信される時に、このモジュールは動作する。トランザクションモニタ２３２は以下でより詳細に説明される。

Ｉ／Ｏプロセス２３３：このモジュールはホスト１からのＩ／Ｏ要求を扱う。以下でより詳細に説明されるように、トランザクション処理命令が受信される時に、Ｉ／Ｏプロセス２３３はトランザクション処理を扱うためにトランザクションモニタ２３２をコールする。

さらに、図３に示される以下のタイプの論理と仮想デバイスおよびボリュームが本発明を実行するために使用される。

一次ボリューム３１１：これは、ＡＰ１３３が、ＡＰ１３３の特定の機能に依存して、データベーステーブル、などのようなデータを保存するために使用する論理デバイスである。さらに、ＡＰ１３３が一つより多い一次ボリュームを使用する場合があり、または複数のアプリケーションプログラム１３３が同じ一次ボリュームの一つまたは複数個を使用する場合がある。

ログディスク３１２：ログディスクまたはログボリュームは少なくとも一つの論理デバイスで構成され、以下でさらに説明される方法でトランザクションモニタ２３２によって使用される。

スナップショットボリューム３１３：一次ボリューム３１１の時点イメージはスナップショットボリューム３１３内に保存される。スナップショットボリューム３１３は、トランザクションが失敗した時にデータをリカバリ処理するために使用される。ローカルミラーリングまたはコピーオンライトスナップショット技術のような、スナップショットボリュームを生成するための技術を説明するいくつかの従来の技術がある。本実施例において、ストレージシステム２はスナップショットを保持するためにコピーオンライトスナップショット技術を使用する。この技術の下で、ストレージシステム２がスナップショットを取得する必要がある時点で、コントローラ２０はスナップショットを保存するために一次ボリューム３１１に対応する仮想デバイスを生成する。任意の書き込み要求が一次ボリューム３１１に来る時に、書き込み要求で指定された領域を更新する前に、領域内のデータは最初に未使用論理デバイスに保存される。コピーオンライトスナップショットオペレーションの更なる詳細は、例えば、米国特許５，６４９，１５２、Ｏｈｒａｎ他内に開示されており、この開示内容は参照して本明細書に組み入れられる。

ホストが論理デバイスをアクセスする方法

各論理デバイスは、ユニークな識別番号を論理デバイスに割り当てることによって、論理デバイスマネジャ２３１によって管理される。このユニークな識別番号は“論理デバイス番号”（ＬＤＥＶ番号）と呼ばれる。また、ホスト１が論理デバイスをアクセスする時に、ポートアドレスとＬＵＮ（Ｌｏｇｉｃａｌ Ｕｎｉｔ Ｎｕｍｂｅｒ）を指定する。従って、ホスト１が論理デバイスをアクセスすることを可能にするために、ポートアドレスとＬＵＮのセットがホスト１からアクセス可能である必要がある各論理デバイスに割り当てられる。

図４はストレージシステム２によって保持されるＬＵマッピングテーブル４００を示す。ＬＵマッピングテーブル４００は、互いに対応するポートアドレス（ＰＯＲＴ）４０１、ＬＵＮ４０２、およびＬＤＥＶ番号４０３の組み合わせを保持する。本実施例において、ポートアドレス４０１のそれぞれは図１内のＦＣインタフェース２４の一つに関連するので、ファイバチャネルプロトコル内のワールドワイドネーム（ＷＷＮ）が各ポートアドレス４０１に割り当てられる。ＬＵマッピングテーブル４００を使用することによって、ストレージシステム２がポートとＬＵＮを指定するＩ／Ｏコマンドを受信する時に、アクセスされる論理デバイスのＬＤＥＶ番号はユニークに決定されることが可能である。

トランザクションリスト

図５は本実施例のトランザクションリストを示す。“トランザクション”はアプリケーション１３３内で実行されるオペレーションの単位である。本実施例において、トランザクションはアプリケーション１３３によって定義される。トランザクションの開始時、ＡＰ１３３は、トランザクションが何時開始するかをストレージシステム２に知るようにさせるための要求をストレージシステム２に発行する（すなわち、“ＲｅｑｕｅｓｔＴｒａｎｓａｃｔｉｏｎ”機能）。ストレージシステム２がトランザクションの開始を示す要求を受信する時に、任意の後続の書き込みＩ／Ｏ要求とそれに続く書き込みデータは最初、一次ボリューム３１１を更新する代わりにログディスク３１２に保存される。ＡＰ１３３が以下に説明される“コミット”コマンドを使用してトランザクションを完了することをストレージシステム２に命令する時に、ログディスク３１２内の書き込みデータは一次ボリューム３１１に適用される。

トランザクションリスト５００はキャッシュメモリ２５またはメモリ２３内に保存される。書き込みＩ／Ｏがストレージシステム２によって受信される時に、書き込みデータは連続してログディスク３１２に保存され、書き込みデータに関する情報はトランザクションリスト５００に保存される。トランザクションリスト５００は以下の情報を保存するためのフィールドを含む。

ＩＤ５０１：各トランザクションはＩＤ５０１に対するフィールド内に保存される“トランザクションＩＤ”と呼ばれるユニークな識別番号または識別子を有する。

ＳＥＱ＃５０２：トランザクションモニタ２３２は、トランザクションが開始した後にストレージシステムによって受信される各書き込み要求（および書き込みデータ）の書き込み順序を保持し記録を付ける必要がある。従って、本実施例の下で、０から開始して連続的に増えるシーケンス番号が本実施例内の各書き込み要求に割り当てられる。シーケンス番号は各トランザクションに対してＳＥＱ＃５０２のフィールド内に保存される。他の実施例の下で、他の番号付けまたは記録付けシステムが使用される場合がある。

ＤＥＶ＃５０３：このフィールドは、データを保存するために意図した受け手として書き込み要求内に指定された論理デバイス（すなわち、一次ボリューム３１１）のＬＤＥＶ番号を含む。

ＨＥＡＤ５０４：このフィールドは、データを保存するためにターゲットＬＢＡとして書き込み要求内に指定された一次ボリューム３１１内のアドレス（論理ブロックアドレスすなわちＬＢＡ）を含む。

ＬＥＮＧＴＨ５０５：このフィールドは書き込み要求内に指定された書き込みデータの長さを示す。

ＬＯＧＤＥＶ５０６：このフィールドは特定のＳＥＱ＃５０２に対応する書き込みデータが保存されるログディスク３１２の論理デバイス番号を示す。

ＬＯＧＡＤＤＲ５０７：このフィールドは特定のＳＥＱ＃５０２に対応する書き込みデータが保存されるログディスク内のＬＢＡを示す。従って、ＬＯＧＤＥＶ５０６とＬＯＧＡＤＤＲ５０７の組み合わせは、特定のＳＥＱ＃５０２で特定された書き込み要求に対応する書き込みデータが保存される、ログディスク３１２内の位置を特定するために使用されることが可能である。

図１８はログディスク３１２内に保存されるデータのフォーマットを示す。各データ１８２はＨＥＡＤＥＲ１８１とＦＯＯＴＥＲ１８３に伴われる。ＨＥＡＤＥＲ１８１は書き込みコマンド情報を含み、これはトランザクションリスト５００’。内のＳＥＱ＃５０２、ＤＥＶ＃５０３、ＨＥＡＤ５０４、およびＬＥＮＧＴＨ５０５を含む。ＦＯＯＴＥＲ１８３はエラー訂正符号（ＥＣＣ）と何らかのパッディングデータ（ＨＥＡＤＥＲ１８１、データ１８２、およびＦＯＯＴＥＲ１８３のサイズが標準ディスクブロックのサイズ（すなわち、５１２バイト）の倍数であるように）を含む。ＭＡＲＫＥＲ１８４もまた、コミットコマンド（以下に説明）が発行される時に、ログディスク３１２内に更新データと共に保存される。ＭＡＲＫＥＲ１８４は、コミットコマンドがトランザクションに対して発行されたこと、およびそのトランザクションに関係するデータが今は作業ボリュームに適用されることができることの表示として役立つ。

トランザクション管理テーブル

図６はストレージシステム２内に保持されるトランザクション管理テーブル６００を示す。ＲｅｑｕｅｓｔＴｒａｎｓａｃｔｉｏｎ機能（以下に説明）から変換されたコマンドがストレージシステム２によって受信される時に、コントローラ２０はユニークなトランザクションＩＤを生成し、コマンドによって特定された各論理ボリュームは生成されたトランザクションＩＤでトランザクション管理テーブル６００上に登録される。トランザクション管理テーブル６００は、トランザクションＩＤ６０１と、ＩＤ６０１によって特定される特定のトランザクションによって書き込みデータがそれらに指定されたＬＤＥＶのデバイス番号（ＤＥＶ＃）６０２を含む。

トランザクション処理ＡＰＩ

図７はトランザクションＩ／Ｏドライバ１３１によって提供されるトランザクション処理ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）のリスト７００を示し、これは本実施例においてＣ−プログラミング機能として提供される。ＡＰ１３３はトランザクションを管理するため、およびトランザクションの間に一次ボリュームをアクセスするためにこれらのＡＰＩを使用する。トランザクションＩ／Ｏドライバ１３１がこれらのＡＰＩ経由でＡＰ１３３から要求を受信する時に、トランザクションＩ／Ｏドライバ１３１は各ＡＰＩ機能要求をストレージシステム２へのコマンドに変換する。本実施例において、ＲＥＡＤまたはＷＲＩＴＥのような標準ＦＣＰ−ＳＣＳＩコマンドをベースにした特有なコマンドがトランザクションＩ／Ｏドライバ１３１とストレージシステム２の間で使用される。本発明で使用されるＡＰＩ機能は以下のようである。

ｉｎｔ ＲｅｑｕｅｓｔＴｒａｎｓａｃｔｉｏｎ（ｃｈａｒ＊＊ＤＥＶＬＩＳＴ）７０１：ＡＰ１３３がトランザクションを起動する時に、ＡＰ１３３はストレージシステム２へのＲｅｑｕｅｓｔＴｒａｎｓａｃｔｉｏｎ機能をコールする。応答で、ストレージシステム２は、特定のトランザクションを特定するために使用される、ストレージシステム２内で定義されるトランザクション番号を返す。ＤＥＶＬＩＳＴは、トランザクションが動作している間にＡＰ１３３がアクセスする必要がある一次ボリューム３１１のリストをストレージシステム２に示す入力パラメータである。ＤＥＶＬＩＳＴの部分として、デバイスファイル名のリストが特定されるべきである。さらに、図８に示されるように、複数のホスト１が一つのトランザクションを共有する時に、ＲｅｑｕｅｓｔＴｒａｎｓａｃｔｉｏｎ機能によって渡されたリスト８００内の各行は、図８で示されるように、コロンで接続されたホスト名とデバイスファイル名（“／ｄｅｖ／ｒｄｓｋ／ｃ３ｔ０ｄ０”のような）で構成される。トランザクションＩ／Ｏドライバ１３１がコールされる時に、それはデバイスファイル名のリストを一次ボリュームのポートアドレスとＬＵＮのセットに変換し、この情報（一次ボリュームのポートアドレスとＬＵＮ）をストレージシステム２に送る。ストレージシステム２において、ＲｅｑｕｅｓｔＴｒａｎｓａｃｔｉｏｎから変換されたコマンドが来る時に、トランザクションＩ／Ｏドライバ１３１はユニークなトランザクションＩＤを生成し、コマンドによって特定される各論理ボリュームは生成されたトランザクションＩＤでトランザクション管理テーブル６００（図６）上に登録される。

ｉｎｔ ＴＰ＿Ｏｐｅｎ（ｉｎｔ ｔｒａｎｓａｃｔｉｏｎ，ｃｏｎｓｔ ｃｈａｒ＊ｐａｔｈｎａｍｅ，ｉｎｔ ｆｌａｇｓ）７０２：このコマンドは、ＡＰ１３３が一次ボリューム３１１の一つをアクセスする前に使用される。第一の入力パラメータ“トランザクション”はトランザクションＩＤを特定するためのパラメータである。ＴＰ＿Ｏｐｅｎ機能は、それが成功する時にファイル記述子（ｆｄ）を返し、これはＴＰ＿ＲｅａｄまたはＴＰ＿Ｗｒｉｔｅ機能のような、続く機能に対して使用される。ＴＰ＿Ｏｐｅｎ機能内で使用される他のパラメータ（パス名とフラッグ）は標準Ｃ−プログラミングシステムコール内のオープンシステムコール機能と同じである。パス名は、ＲｅｑｕｅｓｔＴｒａｎｓａｃｔｉｏｎ機能内で指定されるような、デバイスファイル名の一つである場合があり、または、もしもＯＳ１３２またはＡＰ１３３が論理デバイス上にファイルシステムを生成し、論理デバイスがＲｅｑｕｅｓｔＴｒａｎｓａｃｔｉｏｎ機能によって登録されたものであると、パス名は論理デバイス内のファイル名の一つであることが可能である。一つより多いＴＰ＿Ｏｐｅｎ機能がトランザクションごとにコールされることが可能であることに注意すべきである。

ｏｆｆ＿ｔ ＴＰ＿Ｌｓｅｅｋ（ｉｎｔ ｔｒａｎｓａｃｔｉｏｎ，ｉｎｔ ｆｄ，ｏｆｆ＿ｔ ｏｆｆｓｅｔ，ｉｎｔ ｗｈｅｎｃｅ）７０３：この機能は、トランザクションＩＤが第一のパラメータとして特定される必要がある以外は、標準ｌｓｅｅｋシステムコールと同様である。ＡＰ１３３が一次ボリュームまたはファイルを読み出すかまたは書き込む位置を再位置付けする時に、ＴＰ＿Ｌｓｅｅｋ機能はＴＰ＿ＲｅａｄまたはＴＰ＿Ｗｒｉｔｅ機能コールと共に使用される。再位置付けは後述のようなパラメータ“ｗｈｅｎｃｅ”に従って実行される。（これは標準ｌｓｅｅｋシステムコールと同じである。）

ＳＥＥＫ＿ＳＥＴ：データを読み出し／書き込みする位置は一次ボリューム３１１またはファイルの先頭において“オフセット”バイトに設定される。

ＳＥＥＫ＿ＣＵＲ：位置は現在の位置プラス“オフセット”バイトに設定される。

ＳＥＥＫ＿ＥＮＤ：位置はファイルまたはボリュームのサイズプラス“オフセット”バイトに設定される。三つの全ての“ｗｈｅｎｃｅ”パラメータに対して、位置は各ファイル記述子“ｆｄ”を有するトランザクションＩ／Ｏドライバ１３１によって管理される。

ｓｓｉｚｅ ｔ ＴＰ＿Ｒｅａｄ（ｉｎｔ ｔｒａｎｓａｃｔｉｏｎ，ｉｎｔ ｆｄ，ｖｏｉｄ＊ｂｕｆ，ｓｉｚｅ＿ｔ ｃｏｕｎｔ）７０４：この機能は、トランザクションＩＤが第一のパラメータとして特定される以外は、標準読み出しシステムコールと同様である。ＡＰ１３３がトランザクションＩＤによって特定されるトランザクションの間に一次ボリュームからデータを読み出す時に、ＴＰ＿Ｒｅａｄ機能は使用される。トランザクションＩ／Ｏドライバ１３１がＴＰ＿Ｒｅａｄ機能のコールを受信する時に、データ読み出し位置（ファイル記述子“ｆｄ”で管理される）と読み出しデータカウント（“カウント”パラメータ）は一次ボリュームから読み出されるブロックのＬＢＡと数に変換され、ＲＥＡＤコマンドとトランザクションＩＤが組み合わされるＦＣＰ−ＳＣＳＩベースのコマンドが発行される。

ｓｓｉｚｅ ｔ ＴＰ＿Ｗｒｉｔｅ（ｉｎｔ ｔｒａｎｓａｃｔｉｏｎ，ｉｎｔ ｆｄ，ｖｏｉｄ＊ｂｕｆ，ｓｉｚｅ＿ｔ ｃｏｕｎｔ）７０５：この機能は、トランザクションＩＤが第一のパラメータとして特定される以外は、標準書き込みシステムコールと同様である。ＡＰ１３３がトランザクションＩＤで特定されるトランザクションの間に一次ボリュームにデータを書き込む時に、ＴＰ＿Ｗｒｉｔｅ機能が使用される。トランザクションＩ／Ｏドライバ１３１がＴＰ＿Ｗｒｉｔｅ機能のコールを受信する時に、データ書き込み位置（ファイル記述子“ｆｄ”で管理される）と書き込みデータカウント（“カウント”パラメータ）はデータが一次ボリューム内に書き込まれるブロックのＬＢＡと数に変換され、ＦＣＰ−ＳＣＳＩベースのコマンドが、ＷｒｉｔｅコマンドとトランザクションＩＤを含み、発行される。ストレージシステム２内において、書き込みデータはログディスク３１２内に保存され、一次ボリューム３１１に書き込まれない、しかしＡＰ１３３が、ＴＰ＿Ｒｅａｄ機能７０４を使用して書き込みデータと同じＬＢＡを特定する一次ボリューム上のデータを読み出す時に、書き込みデータが取り出される（すなわち、データが一次ボリューム上に書き込まれているようにＡＰ１３３には見える。）

ｉｎｔ Ｃｏｍｍｉｔ（ｉｎｔ ｔｒａｎｓａｃｔｉｏｎ）７０６：ＡＰ１３３は、特定のトランザクションに関連する全てのタスクが完了した後でトランザクションの終わりにこの機能をコールする。トランザクションＩＤは入力パラメータとして特定される必要がある。コミット機能がコールされる時に、ログディスク３１２内の特定されたトランザクションＩＤに関連する書き込みデータは一次ボリュームに適用される。ストレージシステム２内の一次ボリュームにデータを適用するオペレーションが首尾よく実行される時に、コミット機能はＡＰ１３３に値“０”を返す。何らかの理由で失敗すると、エラーがコミットオペレーションの間に発生したことを示すために“−１”が返される。機能がＡＰ１３３によってコールされる時に、もしもストレージシステム２にまだ書き込まれていない書き込みデータが存在すると、トランザクションＩ／Ｏドライバ１３１は最初にトランザクションＩＤに関連する全てのデータをストレージシステム２内に書き込み、次に一次ボリューム３１１にデータを適用する命令をストレージシステム２に発行する。

ｉｎｔ ＴＰ＿Ｃｌｏｓｅ（ｉｎｔ ｔｒａｎｓａｃｔｉｏｎ，ｉｎｔ ｆｄ）７０７：トランザクションＩＤが特定される以外は標準Ｃ−プログラミングシステムコールのクローズ機能と同じである。ＴＰ＿Ｃｌｏｓｅ機能はパラメータ“ｆｄ”で特定されるファイルをクローズするために使用される。

ｖｏｉｄ ＤｅｌｅｔｅＴｒａｎｓａｃｔｉｏｎ（ｉｎｔ ｔｒａｎｓａｃｔｉｏｎ）７０８：ＡＰ１３３がトランザクションを停止し（トランザクションパラメータで特定された）、トランザクションをロールバックしたい時に、ＡＰ１３３はこの機能をコールする。ＤｅｌｅｔｅＴｒａｎｓａｃｔｉｏｎ機能がコールされる時点までストレージシステム２に書き込まれるデータはストレージシステム２によって捨てられる。

処理フロー − ＲｅｑｕｅｓｔＴｒａｎｓａｃｔｉｏｎ

図９は、ＲｅｑｕｅｓｔＴｒａｎｓａｃｔｉｏｎ７０１機能がホスト１においてコールされる時のストレージシステム２内のオペレーションの処理フローを示す。最初に、ホスト１内のトランザクションＩ／Ｏドライバ１３１はＡＰ１３３から受信されたＲｅｑｕｅｓｔＴｒａｎｓａｃｔｉｏｎ７０１機能をＦＣベースのコマンドに変換し、変換されたコマンドをストレージシステム２に送る。次に、以下のステップがストレージシステム２によって実行される。

ステップ１０００：ストレージシステム２において、Ｉ／Ｏプロセス２３３は変換されたコマンドを受信する。Ｉ／Ｏプロセス２３３は受信されたコマンドが上記で説明されたトランザクション管理コマンドの一つであるかを決定し、肯定的な決定をすると、コマンドをトランザクションモニタ２３２に渡す。

ステップ１００１：トランザクションモニタ２３２がＩ／Ｏプロセス２３３からコマンドを受信すると、トランザクションモニタ２３２はトランザクション管理テーブル６００をチェックすることによって未使用トランザクションＩＤを生成する。

ステップ１００２：トランザクションモニタ２３２は、受信された論理デバイス番号のリストのどれかが他のトランザクションに既に割り当てられているかを確認するために、コマンドと共に受信された論理デバイス番号のリストをチェックする。これはトランザクション管理テーブル６００を検索することによって行われることが可能である。もしもコマンドによって特定される論理デバイスの一つが他のトランザクションに既に割り当てられていると、処理は異常終了し、エラーを返す。もしもコマンド内で特定される論理デバイスのどれも他のトランザクションにまだ割り当てられていないと、処理はステップ１００３に進む。

ステップ１００３：トランザクションモニタ２３２はコマンド内の論理デバイス番号のリストをステップ１００１で生成されたトランザクションＩＤでトランザクション管理テーブル６００に登録する。

ステップ１００４：トランザクションモニタ２３２はホスト１にトランザクションＩＤを返し、処理は完了する。

処理フロー − ＴＰ＿Ｗｒｉｔｅ Ｒｅｑｕｅｓｔ

図１０はＴＰ＿Ｗｒｉｔｅ Ｒｅｑｕｅｓｔ７０５の処理フローを示し、これは次のステップを含む。

ステップ１１０１：Ｉ／Ｏプロセス２３３は、コマンドがトランザクション管理コマンドか、およびコマンドがトランザクションＩＤを含むかを決定する。もしも決定が肯定的であると、処理はステップ１１０２に進む。もしも決定が否定的であると、コマンドは本発明または特定のトランザクションのトランザクション管理方法に関係していなく（すなわち、これはＷＲＩＴＥのような標準ＦＣＰ−ＳＣＳＩコマンドである）、処理はステップ１１１１に進む。

ステップ１１０２：トランザクションモニタ２３２は、指定された論理デバイス（すなわち、一次ボリューム）が指定されたトランザクションＩＤでトランザクション管理テーブル６００内に登録されているかを決定するために、コマンドと共に来るパラメータをチェックする。もしもトランザクション管理テーブル６００が特定のトランザクションＩＤに登録された指定された論理デバイスを含むと、処理はステップ１１０３に進む。もしもそうでないと、処理は異常終了し、エラーを返す。

ステップ１１０３：トランザクションモニタ２３２は特定の論理デバイスがロックされているかをチェックする。もしも特定の一次ボリュームがロックされていると、処理は論理デバイスがアンロックされるまで待つ。具体化の他の方法では、処理は、特定の論理デバイスがアンロックされるのを待たないで終了し、デバイスがロックされていることをホスト１に通知する場合があり、または処理は予め決められた時間だけ待った後にホストにロックされているとの通知を返す場合がある。

ステップ１１０４：トランザクションモニタ２３２は書き込みデータが書き込まれるログディスク３１２のエリアを割り当てる（すなわち、使用可能なスペースの一つ以上のブロック）。このステップは、他のホストコンピュータ内の他のアプリケーションプログラムからのような他の書き込みＩ／Ｏ処理がこのステップにおいて割り当てられたエリアにデータを上書きしないようにする、一種のロック処理である。

ステップ１１０５：トランザクションモニタ２３２は書き込みデータをログディスク３１２に保存する。

ステップ１１０６：トランザクションモニタ２３２は、ステップ１１０４と１１０５で実行された書き込み要求に関する情報をトランザクションリスト５００に加え、次に処理は終了する。

ステップ１１１１：Ｉ／Ｏプロセス２３３は、書き込み要求によって指定されたデバイスがトランザクション管理テーブル６００に登録されているかを決定する。もしもデバイスがトランザクション管理テーブル６００内に登録されていると、これはデバイスがトランザクションの部分であるが、しかしトランザクションＩＤが書き込み要求に含まれていなかったことを意味するので、処理は異常終了し、エラーを返す。もしもデバイスがトランザクション管理テーブル６００内に登録されていないと、処理はステップ１１１２に進む。

ステップ１１１２：Ｉ／Ｏプロセス２３３は通常の書き込みＩ／Ｏ処理を実行し、処理は終了する。他の実施例において、通常のＷＲＩＴＥコマンドが来る時に、指定された論理デバイスがトランザクション管理テーブル６００内に登録されているまたはいないに関係なく、書き込み要求は実行される場合がある。しかし、このようなケースでは、書き込みデータのコンシステンシは保持されることができない。

処理フロー − ＴＰ＿Ｒｅａｄ Ｒｅｑｕｅｓｔ

図１１はＴＰ＿Ｒｅａｄ Ｒｅｑｕｅｓｔがストレージシステム内で受信される時の処理フローを示し、次のステップを含む。

ステップ１２０１：Ｉ／Ｏプロセス２３３は、コマンドがトランザクション管理コマンドか、およびコマンドがトランザクションＩＤを含むかを決定する。もしも決定が肯定的であると、処理は１２０２に進む。もしも決定が、コマンドがトランザクション管理コマンドではない（すなわち、これはＲＥＡＤのような標準ＦＣＰ−ＳＣＳＩコマンドである）とのことであると、処理は１２１１に進む。

ステップ１２０２：トランザクションモニタ２３２は、指定された論理デバイス（すなわち、一次ボリューム）がコマンド内で特定されたトランザクションＩＤでトランザクション管理テーブル６００内に登録されているかを決定するために、コマンドに含まれるパラメータをチェックする。もしも指定された論理デバイスが登録されていると、処理は１２０３に進む。もしもそうでないと、処理は異常終了し、エラーがホスト１に返される。

ステップ１２０３：トランザクションモニタ２３２は、論理デバイスがロックされているかを決定する。もしも特定の論理デバイスがロックされていると、処理は論理デバイスがアンロックされるまで待つ。具体化の他の方法では、処理は論理デバイスがアンロックされるのを待つこと無く終了し、論理デバイスがロックされていることをホスト１に通知するか、または処理は、デバイスがロックされていることをホストに通知する前に予め決められた期間だけ待つ場合がある。

ステップ１２０４：トランザクションモニタ２３２は、ＴＰ＿Ｒｅａｄコマンドで指定された領域（ＬＢＡ）がＴＰ＿Ｗｒｉｔｅコマンドによって以前に上書きされたかを決定する。もしもこのケースであると、読み出し要求によって要求された更新データは一次ボリューム３１１内ではなくログディスク３１２内に存在する。データはトランザクションリスト５００の内容を検索することによって見つけられることが可能である。もしも更新データがログディスク３１２内に存在すると、処理はステップ１２０５に進む。もしもそうでないと、処理はステップ１２１１に進む。

ステップ１２０５：トランザクションリスト５００を使用して、処理は、そのＨＥＡＤ５０４が読み出し要求内で特定されるＬＢＡと一致する最新の更新データを見つける。次にトランザクションモニタ２３２は、読み出し要求内で特定されるＬＢＡにトランザクションリスト５００内で対応するＬＢＡ（ＬＯＧＡＤＤＲ５０７）においてログディスク３１２からデータを読み出すことをＩ／Ｏプロセス２３３に命令する読み出し要求をＩ／Ｏプロセス２３３に送る。

ステップ１２０６：Ｉ／Ｏプロセス２３３はホスト１に読み出しデータを返す。

ステップ１２１１：Ｉ／Ｏプロセス２３３は指定されたブロックを読み出し、読み出されたデータをホスト１に返す。

処理フロー − コミット機能

図１２はコミット機能を実行するための処理を示し、これは次のステップを含む。

ステップ１３０１：トランザクションモニタ２３２は、特定のトランザクションＩＤに従ってコミット機能によって指定された特定のトランザクションに関係する一次ボリューム３１１をロックする。

ステップ１３０２：トランザクションモニタ２３２は一つ以上の一次ボリュームのスナップショットを取得する。このオペレーションは選択的であり、上記で議論されたＣＯＷ技術を使用することができる。選択的スナップショットを取得する利点は、もしもコミット機能がアプリケーションプログラムまたはトランザクションモニタ２３２に直接には関係しない何らかのエラー（例えば、ストレージシステム内の電源障害または他の理由）のために実行の間に失敗すると、データのリカバリを可能にすることである。

ステップ１３０３：トランザクションモニタ２３２は、ログディスク３１２内に保存された書き込みデータをトランザクションリスト５００内の書き込み要求情報（要素５０３、５０４、５０５、５０６、５０７）に従って一次ボリューム３１１に適用する。書き込み順序を正しく保つために、書き込みオペレーションは各書き込みに対してシーケンス番号ＳＥＱ＃５０２に従って行われる。

ステップ１３０４：もしも書き込みデータが適用されている間にエラーが発生すると、処理は異常終了し、エラーが返される。もしも一次ボリューム３１２にデータを適用することが首尾よく終了すると、処理はステップ１３０５に進む。

ステップ１３０５：トランザクションモニタ２３２はＩ／Ｏプロセス２３３に一次ボリューム３１１をアンロックすることを命令する。

ステップ１３０６：トランザクションモニタ２３２はトランザクションリスト５００内の指定されたトランザクションＩＤに関係するエントリを削除し、処理を正常に終了する。すなわち、トランザクションＩＤ５０１フィールドが指定されたトランザクションＩＤに等しい全てのエントリはリストから削除される。エントリを削除した後に、対応するトランザクションＩＤに関係する書き込みデータが保存されているログディスク３１２内のエリアは他のトランザクションに対してデータを保存するために使用される。また、本実施例において、トランザクションＩＤはステップ１３０６の後でストレージシステム２内で削除され、他のＲｅｑｕｅｓｔＴｒａｎｓａｃｔｉｏｎコマンドがストレージシステム２によって受信される時に、削除されたトランザクションＩＤは再使用されることができる。

コミット機能が失敗すると、またはＡＰ１３３がコミット機能を発行する前にトランザクションの間になされた変更をロールバックしたいと思う時に、ＤｅｌｅｔｅＴｒａｎｓａｃｔｉｏｎ機能７０８が使用される。トランザクションモニタ２３２がトランザクションＩ／Ｏドライバ１３１からＤｅｌｅｔｅＴｒａｎｓａｃｔｉｏｎ要求を受信する時に、トランザクションモニタ２３２はトランザクションリスト５００内の指定されたトランザクションＩＤに関係するエントリを削除し、これは図１２内で述べられたコミット機能内のステップ１３０６と同じである。またトランザクションＩＤそれ自身も削除される。さらに、もしもコミット機能がコミット機能を実行している間に失敗すると、トランザクションリスト５００内のエントリを削除することに加えて、コミット機能が実行される前にデータをリカバリ処理するために、トランザクションモニタ２３２はスナップショットボリューム３１３内の内容で一次ボリューム３１１内の内容を更新する。

本実施例において、各トランザクションによって管理されるディスク領域はボリュームごとに定義される。しかし、他の実施例では、各トランザクションによって管理されるディスク領域は部分的ボリューム（ボリューム内の二つのＬＢＡによって特定される領域内で一つまたは複数の隣接するディスクブロックを定義することによってなど）として定義されることが可能である。

第二の実施例

第二の実施例内のハードウエアとソフトウエアは第一の実施例に関して上記で説明されたものと同じである。第一の実施例からの第二の実施例の違いは、以下のように、各トランザクションの管理方法とトランザクションＡＰＩの使用方法にある。

ｉｎｔ ＲｅｑｕｅｓｔＴｒａｎｓａｃｔｉｏｎ（ｃｈａｒ＊＊ＤＥＶＬＩＳＴ）：ＡＰ１３３がＲｅｑｕｅｓｔＴｒａｎｓａｃｔｉｏｎ機能をコールする時に、ストレージシステム２は、第一の実施例に関して上記で説明されたように、ストレージシステム２内で定義されたトランザクション番号を返す。ＡＰ１３３によるＲｅｑｕｅｓｔＴｒａｎｓａｃｔｉｏｎ機能のコール動作の処理とストレージシステム２の応答は、図９内のような、第一の実施例で上記に説明されたものと、第二の実施例とは同じである。

ｉｎｔ ｏｐｅｎ（ｃｏｎｓｔ ｃｈａｒ＊ｐａｔｈｎａｍｅ，ｉｎｔ ｆｌａｇｓ）：上記に説明されたＴＰ＿Ｏｐｅｎ機能７０２の代わりに、標準Ｃ−プログラミングシステムコールが第二の実施例に対して使用される。

ｏｆｆ＿ｔ ｌｓｅｅｋ（ｉｎｔ ｆｄ，ｏｆｆ＿ｔ ｏｆｆｓｅｔ，ｉｎｔ ｗｈｅｎｃｅ）：上記に説明されたＴＰ＿Ｌｓｅｅｋ機能７０３の代わりに、標準Ｃ−プログラミングシステムコールが第二の実施例に対して使用される。

ｓｓｉｚｅ＿ｔ ｒｅａｄ（ｉｎｔ ｆｄ，ｖｏｉｄ＊ｂｕｆ，ｓｉｚｅ＿ｔ ｃｏｕｎｔ）：上記に説明されたＴＰ＿Ｒｅａｄ機能７０４の代わりに、標準Ｃ−プログラミングシステムコールが第二の実施例に対して使用される。従って、第二の実施例の下で、ストレージシステム２内で、もしもＲＥＡＤコマンドがＲｅｑｕｅｓｔＴｒａｎｓａｃｔｉｏｎ機能によって登録された論理デバイスをターゲットにし、ＦＣ−ＳＣＳＩのＲＥＡＤコマンドが、データがログディスク３１２内に保存されているＬＢＡを含むと、データはログディスク３１２から読み出される。

ｓｓｉｚｅ＿ｔ ｗｒｉｔｅ（ｉｎｔ ｆｄ，ｖｏｉｄ＊ｂｕｆ，ｓｉｚｅ＿ｔ ｃｏｕｎｔ）：上記に説明されたＴＰ＿Ｗｒｉｔｅ機能７０５の代わりに、標準Ｃ−プログラミングシステムコールが第二の実施例内において使用される。従って、第二の実施例の下で、書き込みシステムコールはＦＣ−ＳＣＳＩのＷＲＩＴＥコマンドに変換され、ストレージシステム２に発行される。ストレージシステム２内で、もしもＷＲＩＴＥコマンドがＲｅｑｕｅｓｔＴｒａｎｓａｃｔｉｏｎ機能によってトランザクション管理テーブル６００内に登録された論理デバイスをターゲットにすると、書き込みデータはログディスク３１２内に保存され、コミット機能が発行されるまで一次ボリューム３１１に書き込まれない。

ｉｎｔ Ｃｏｍｍｉｔ（ｉｎｔ ｔｒａｎｓａｃｔｉｏｎ）：第二の実施例内のコミット機能は第一の実施例に関して上記に説明されたものと同様である。第一の実施例からの違いはトランザクションＩＤが、コミット機能が実行された後にトランザクションリスト５００から削除されないことである。

ｉｎｔ ｃｌｏｓｅ（ｉｎｔ ｆｄ）：上記に説明されたＴＰ＿Ｃｌｏｓｅ機能７０７の代わりに、標準Ｃ−プログラミングシステムコールが第二の実施例内で使用される。

ｖｏｉｄ ＤｅｌｅｔｅＴｒａｎｓａｃｔｉｏｎ（ｉｎｔ ｔｒａｎｓａｃｔｉｏｎ）：第二の実施例内のＤｅｌｅｔｅＴｒａｎｓａｃｔｉｏｎ機能は第一の実施例に関して上記に説明されたものと同様である。わずかな違いが以下の論議で説明される。

処理フロー − 書き込み要求

図１３は本発明の第二の実施例内の書き込みオペレーションの処理フローを示す。第一の実施例からの違いは、第一の実施例内のステップ１１０１が図１３内に存在せず、ステップ１１０２はステップ１１０２’で置き換えられることである。

ステップ１１０２’において、トランザクションモニタ２３２は、書き込み要求がＲｅｑｕｅｓｔＴｒａｎｓａｃｔｉｏｎ機能によって指定された論理デバイスの一つをターゲットにするか、またはそうでないかを決定する。もしも決定が肯定的であると、処理はステップ１１０３に進み、第一の実施例内の図１０に関して上記に説明されたものと同じ書き込みオペレーションを実行する。もしも書き込み要求がＲｅｑｕｅｓｔＴｒａｎｓａｃｔｉｏｎ機能によって指定された論理デバイスをターゲットにしないと、書き込みオペレーションはトランザクションの部分として管理される必要は無く、処理はステップ１１１２に進み、第一の実施例内の図１０に関して上記に説明されたように、通常の書き込みＩ／Ｏオペレーションを実行する。図１３の残りは図１０に対して上記に説明されたものと同じであり、ここで繰り返される必要は無い。

処理フロー − 読み出し要求

図１４は第二の実施例内の読み出しオペレーションの処理フローを示す。第一の実施例からの違いは、第一の実施例内のステップ１２０１は図１４内に存在せず、ステップ１２０２はステップ１２０２’で置き換えられることである。

ステップ１２０２’において、トランザクションモニタ２３２は、読み出し要求がＲｅｑｕｅｓｔＴｒａｎｓａｃｔｉｏｎ機能によって指定された論理デバイスをターゲットにするか、またはそうでないかを決定する。もしも決定が肯定的であると、処理はステップ１２０３に進み、第一の実施例内の図１１に関して上記に説明されたものと同じ読み出しオペレーションを実行する。しかし、もしも読み出し要求がＲｅｑｕｅｓｔＴｒａｎｓａｃｔｉｏｎ機能によって指定された論理デバイスをターゲットにしないと、処理はステップ１２１１に進み、これもまた上記に説明されたように、通常の読み出しＩ／Ｏオペレーションを実行する。図１４の残りは図１１に対して上記に説明されたものと同じであり、ここで繰り返される必要は無い。

コミット機能

第二の実施例内のコミット機能は、トランザクションＩＤがステップ１３０６においてストレージシステム２内で削除されないこと以外、図１２に関して上記に説明された、第一の実施例内とほとんど同じである。第二の実施例内において、ＤｅｌｅｔｅＴｒａｎｓａｃｔｉｏｎ機能がコールされる時だけ、トランザクションＩＤは削除される。従って、第二の実施例内において、ユーザまたはＡＰ１３３は、特定のアプリケーションプログラムが完了点に達する前は同じトランザクションＩＤを再使用し、特定のアプリケーションプログラムが完了点に達する時にはコミット機能の後でＤｅｌｅｔｅＴｒａｎｓａｃｔｉｏｎ機能をコールする。

第三の実施例

前述の内容から、本発明は複数のアプリケーションプログラムが協同で動作する情報システムに対して有用であり、アプリケーションプログラムにおいてトランザクションの開始または終了で一貫した状態でデータをリカバリ処理する時に特に有用であることは明らかである。第三の典型的な実施例として、図１５は複数のアプリケーションプログラムが本発明の技術を使用して一緒に動作できる方法の例を示す。

第三の実施例のシステム構成は、二次ストレージシステム２−２が一次ストレージシステム２−１に接続されていること以外は、第一と第二の実施例のそれと同様である。一次ストレージシステム２−１と二次ストレージシステム２−２のハードウエア構成は、第一の実施例において上記に説明されたストレージシステム２のそれと同じであることができる。しかし、追加のリンク７は一次ストレージシステム２−１から二次ストレージシステム２−２にデータをコピーするために提供されることができる。リンク７はファイバチャネルリンク、イーサネット（登録商標）、または他のデータコミュニケーション媒体であることができる。さらに、ストレージシステム２−１、２−２とホスト１−１、１−２に対するソフトウエア構成に関して、ソフトウエアモジュールは第一の実施例に関して上記に説明されたものと同様である。しかし、ストレージシステム２−１、２−２のそれぞれは、ミラーリングの目的などで、一次ストレージシステム１−１上の一次ボリューム３１１−１から二次ストレージシステム２−２上の二次ボリューム３１４への複製を制御するために、複製マネジャ２３４−１、２３４−２をそれぞれ含む。さらに、ホスト１−１はホスト１−２上に含まれるサブＡＰ２ １３４−２と異なることができるサブ−アプリケーションプログラム（サブＡＰ１）１３４−１を含み、これは以下でより詳細に説明される。ホスト１−１とホスト１−２のハードウエア構造は第一の実施例に関して上記に説明されたホスト１と同じであることができる。

図１６は、以下のように、ホスト１−１と１−２上のソフトウエアモジュールの間の機能的関係を示す。

メインＡｐｐプログラム（ＡＰ）１３３−１と１３３−２：これは、ウエブベースアプリケーションプログラム、ＥＲＰ（Ｅｎｔｅｒｐｒｉｓｅ Ｒｅｓｏｕｒｃｅ ｐｌａｎｎｉｎｇ）プログラムなどのような、この実施例の基本的アプリケーションプログラムである。ＡＰ１３３はユーザの要求を管理し、ユーザの要求などに従ってＩ／Ｏを処理するためにサブＡＰ１ １３４−１またはサブＡＰ２ １３４−２を呼び出す。またＡＰ１３３は一次ストレージシステム２−１上の一次ボリューム３１１−１ａと３１１−１ｂ内などのデータのコンシステンシを制御し、サブ−アプリケーションプログラムを呼び出す。従って、ＡＰ１３３−１と１３３−２はまた“スケジューラ”またはタスクスケジューラ部分を有すると呼ばれる場合がある。

サブＡＰ１ １３４−１とサブＡＰ２ １３４−２：これらのプログラムはＡＰ１３３のスケジューラによって呼び出され、一次ストレージシステム２−１への読み出し／書き込み要求を処理する。本実施例において、これらのプログラムは一般的には商用のＲＤＢＭＳプログラムのようなトランザクション処理能力を有さない。

ＡＰ１３３のスケジューラがユーザから購買注文（例えば、もしもＡＰ１３３−１、ＡＰ１３３−２のスケジューラとサブＡＰ１ １３４−１とサブＡＰ２ １３４−２がオンラインショッピングアプリケーションを構成する場合）のような要求を受信する時に、ホスト１−１と１−２上のＡＰ１３３−１とＡＰ１３３−２が、それぞれ、在庫表のチェック、在庫の更新、勘定データベースの更新などのような要求を処理することをサブＡＰ１ １３４−１またはサブＡＰ２ １３４−２に、それぞれ、命令する（いくつかのケースでは、ホスト１−１または１−２の一方のＡＰ１３３がＡＰ１ １３４−１とＡＰ２ １３４−２の両方に命令する場合がある）。サブＡＰ１ １３４−１とサブＡＰ２ １３４−２のそれぞれが要求を終了する時に、トランザクションの処理の特定の要求またはステップが終了したとの通知をＡＰ１３３のスケジューラに返す。

本実施例において、ＡＰ１３３のスケジューラはサブＡＰ１３４−１、１３４−２がデータを保存するために使用する論理デバイス（または論理デバイスの部分）を知っている。従って、ＡＰ１３３のスケジューラがサブＡＰ１３４に要求を発行する前に、それはサブＡＰ１３４が使用する論理デバイス（または論理デバイスの部分）の識別情報で一次ストレージシステム２−１にＲｅｑｕｅｓｔＴｒａｎｓａｃｔｉｏｎ機能を発行する。サブＡＰ１３４がその要求またはタスクを終了した後に、ＡＰ１３３のスケジューラはコミット要求を一次ストレージシステム２−１に発行する。従って、図１６内に示される機能性は、サブＡＰ１ １３４−１からデータを保存する一次ボリューム１ ３１１−１ａ、およびサブＡＰ２ １３４−２からデータを保存する一次ボリューム２ ３１１−１ｂで示される二つの一次ボリュームがある以外は、第一と第二の実施例に対して上記に説明された処理と同様である。

一次ストレージシステム２−１において、第一の実施例または第二の実施例に対して上記に説明されたように、ＲｅｑｕｅｓｔＴｒａｎｓａｃｔｉｏｎ機能を受信した後に、ストレージシステム２−１は特定のトランザクションに関連した任意の書き込みデータをログディスク３１２−１内に保存する。トランザクションに関連する全てのタスクが首尾よく完了した時に、およびＡＰ１３３からコミット要求を受信した後に、ストレージシステム２−１はログディスク３１２−１内の書き込みデータを一次ボリューム３１１−１（３１１−１ａおよび／または３１１−１ｂ）内に適用する。サブＡＰ１３４−１、１３４−２の一方またはＡＰ１３３のスケジューラがトランザクションの間に失敗する時に、ＡＰ１３３のスケジューラはＤｅｌｅｔｅＴｒａｎｓａｃｔｉｏｎ要求を一次ストレージシステム２−１に発行する。一次ストレージシステム２−１がＤｅｌｅｔｅＴｒａｎｓａｃｔｉｏｎ要求を受信する時に、それは削除要求で特定されるトランザクションＩＤに対応するログディスク３１２内の書き込みデータを捨てる。さらに、システム内に異なるスケジューラとサブＡＰ１３４を有するＡＰ１３３の複数のセットがあることが可能である。

リモートバックアップ／リストア

第三の実施例において、システムはまた一次ストレージシステム２−１内のデータをミラーリングするために二次ストレージシステム２−２を含むことができる。一次と二次ストレージシステム２−１と２−２は複製マネジャモジュール２３４−１と２３４−２をそれぞれ有する。一次ストレージシステム２−１または一次サイト（すなわち、一次サイトには一次ストレージシステム２−１と少なくとも一つのホスト１を含む）が故障すると、二次サイト（すなわち、二次サイトには二次ストレージシステム２−２と少なくとも一つのホスト１を含む）は、フェイルオーバ処理技術の下で処理を引き継ぐことができる。

図１７と２１は複製マネジャモジュール２３４−１と２３４−２の処理フローを示す。複製マネジャモジュール２３４−１と２３４−２は各トランザクション内に存在し共存する。例えば、二つのトランザクションが一次ストレージシステム２−１内で定義されている時に、二つの複製マネジャモジュール２３４−１は一次ストレージシステム２−１内で動作し、二つの複製マネジャモジュール２３４−２は二次ストレージシステム２−２内で動作する。リモートミラーリングオペレーションは二つのコピーオペレーション、初期コピーおよび更新コピーから成る。図１７は複製マネジャモジュール２３４−１の初期コピーオペレーションの処理フローを示し、図２１は、複製マネジャモジュール２３４−２が更新されたコピーデータを受信した時の処理フローを示す。

リモートミラーリングが開始された時に、システムのユーザは、トランザクションＩＤ、一次ストレージシステム２−１内の一つ以上の一次ボリューム３１１−１、および二次ストレージシステム２−２内の一次ボリューム３１１−１内のデータがミラーリングされる一つ以上の行き先または二次ボリューム３１４（ここ以後は二次ボリューム３１４と呼ばれる）を特定して、二次ストレージシステム２−２内にミラーを生成するためにトランザクションＩ／Ｏドライバ１３１経由でリモートコピーコマンドを発行する。二次ストレージシステム２−２内の二次ボリューム３１４が、第一と第二の実施例内において上記で説明されたように、本発明の下で、一次ボリューム３１１と同様に扱われるけれども、二次ボリュームはホスト１上のＡＰ１３１からよりも、一次ストレージシステムからデータを受信することに注意すべきである。各二次ボリューム３１４の容量はミラーリングする一次ボリューム３１１のそれと同じか、より大きいので、ユーザは最初二次ボリューム３１４を手動で選択／割り当てをすることができる。他の実施例において、ユーザがミラーを生成するコマンドを発行する時に、複製マネジャモジュール２３４−１と２３４−２の一方は、二次ボリューム２１４として役立つ適切な論理デバイスを二次ストレージシステム２−２内に見つけることが可能である。

処理フロー − 初期コピー

図１７に示されるように、ミラーを生成する要求が受信される時に、一次ストレージシステム２−１内の複製マネジャ２３４−１は次のステップを実行する。

ステップ３００１：複製マネジャ２３４−１はミラーを生成する要求をホスト１から受信する。複製マネジャ２３４−１が、各一次ボリューム３１１−１内のデータが二次ストレージシステム２−２内のどの論理デバイスにコピーされるべきかを決定可能なように、要求は少なくともトランザクションＩＤと、一次ボリューム３１１−１と二次ボリューム３１４から成る少なくとも一対のペア情報を含む。

ステップ３００２：複製マネジャ２３４−１は、特定の一次ボリューム３１１−１のそれぞれのスナップショットを取得するためにスナップショットボリューム３１３−１を生成する。結果として、一次ボリューム３１１−１のそれぞれの内のデータの時点イメージがスナップショットボリューム３１３−１内に保存される。本実施例において、第一の実施例と同様に、コピーオンライトスナップショット技術はスナップショットを取得するために使用されることができ、従って、スナップショットデータはスナップショットボリューム３１３内に仮想的に保存される。

ステップ３００３：複製マネジャ２３４はスナップショットボリューム３１３から二次ボリューム３１４にデータをコピーすることを開始する。コピー処理はスナップショットボリューム３１３の先頭のＬＢＡから最後尾まで連続的に発生する。

ステップ３００４：もしも全てのデータがコピー処理を終了すると、処理はステップ３００５に進む。もしもそうでないと、処理は全てのデータがコピーされるまで待つ。

ステップ３００５：複製マネジャ２３４−１はスナップショットボリューム３１３−１を削除し、初期コピーのステップは完了する。

ステップ３００６：全てのデータをコピーした後に、複製マネジャ２３４−１は更新コピーオペレーションを開始する。この実施例内の更新コピーオペレーションは、ログディスク３１２−１内のデータを二次ストレージシステム２−２内の二次ログディスク３１２−２にコピーすることによって実行されることが可能である。

二次ストレージシステム２−２内の初期コピー処理は複製マネジャ２３４−２によって管理される。複製マネジャ２３４−２は一次ストレージシステム２−１から初期コピーデータを受信し、初期コピーデータを二次ボリューム３１４に保存する。

一次ストレージシステム２−１内の更新コピーオペレーションはまた、ログディスク３１２−１内のデータを二次ストレージシステム２−２に定期的に送ることによって複製マネジャ２３４−１によって実行される。トランザクションモニタ２３２によって削除されたログディスク３１２−１内のデータを有することを避けるために、図２０に関して以下に説明されるように、ログディスク３１２−１内のデータが複製マネジャ２３４によってストレージシステム２内の二次ログディスク３１２−２にコピーされた後に、データがログディスク３１２−１から削除されることを複製マネジャ２３４が許可する場合だけ、ログデータ削除処理が実行される。

図１９は本実施例で使用されるトランザクションリスト５００’を示す。第一の実施例からのトランザクションリスト５００’の違いはＦＬＡＧ５０８列が追加されていることである。もしもＦＬＡＧ５０８の値が“１”であると、これは、ログディスク３１２−１内の対応するデータが既に更新コピーオペレーションによって二次ストレージシステム２−２に送信されていることを意味する。もしもデータがまだ二次ストレージシステム２−２に送信されていないと、ＦＬＡＧ５０８の値は“０”であり、データは、それが送信されるまで削除から保護される。

処理フロー − 一次ストレージシステム内の更新コピー

図２０は一次ストレージシステム２−１内の更新コピーの処理フローを示す。処理は定期的に動作し（一分に一回のように）、次のステップを含む。

ステップ３５０１：複製マネジャ２３４は、二次ストレージシステム２−２にまだ送られていないデータがあるかを決定するためにトランザクションリスト５００’をチェックする。このデータは、ＦＬＡＧ５０８が“０”かまたは“１”かをチェックすることによって見つけられることが可能である。もしもＦＬＡＧ５０８が“０”のエントリがあると、処理はステップ３５０２に進む。もしもそうでないと、新しいデータがログディスク３１３−１に書き込まれたかを決定するために次のサイクルまで、処理は待つ。

ステップ３５０２：複製マネジャ２３４は“０”のＦＬＡＧ５０８を有するデータを二次ストレージシステム２−２に送る。複数の書き込みデータが二次ストレージシステム２−２に送られることは可能であるが、ＦＬＡＧ５０８が“０”の全てのデータが同時に送られる必要はない。送られる多くのデータエントリがある時に、データは複数の更新コピーオペレーションによって送られる場合がある。さらに、データはそのシーケンス番号（ＳＥＱ＃５０２）に従って通常は送られるが、各書き込みデータを送る順序は維持される必要はない。

ステップ３５０３：データが二次ストレージシステム２−２に送られ、複製マネジャ２３４−１が二次ストレージシステム２−２から確認通知を受信する時に、複製マネジャ２３４−１はストレージシステム２−２に送られたトランザクションリスト５００’の各エントリ内でＦＬＡＧ５０８を“１”に設定する。

データが二次ストレージシステム２−２に送られる時に、書き込みコマンド情報もまた送られる。図１８は二次ストレージシステム２−２内のログディスク３１２−２内に保存されるデータのフォーマットを示す。上記に説明されたログディスク３１２と同様に、各データ１８２はＨＥＡＤＥＲ１８１とＦＯＯＴＥＲ１８３に伴われる。ＨＥＡＤＥＲ１８１は書き込みコマンド情報を含み、これはトランザクションリスト５００’内のＳＥＱ＃５０２、ＤＥＶ＃５０３、ＨＥＡＤ５０４、およびＬＥＮＧＴＨ５０５を含む。しかし、ＤＥＶ＃５０３に関しては、ＤＥＶ＃５０３フィールド内にある値それ自身は送られない。代わりに、二次ボリューム３１４（二次ストレージシステム２−２内のボリューム、これは一次ボリューム３１１とペアの関係にあり、一次ストレージシステム２−１から来るデータがここに書き込まれる）内の対応する論理デバイス番号が送られる。コミットコマンドが発行される時に、ＭＡＲＫＥＲ１８４もまたログディスク３１２−２内に更新データと共に保存される。ＭＡＲＫＥＲ１８４は、コミットコマンドがトランザクションに対して発行されたこと、およびこのトランザクションに関係するデータが今は作業ボリュームに適用されることができ、このケースではこれは二次ボリューム３１４であることの表示として役立つ。

上記に述べられたように、二次ボリューム３１４は手動でユーザによって割り当てられることができる。他の実施例では、二次ボリューム３１４は、既知のリモートコピー技術を使用して一次ストレージシステム２−１または二次ストレージシステム２−２によって自動的に決定される場合がある。

処理フロー − 二次ストレージシステム内の更新コピー

図２１は二次ストレージシステム２−２内の更新コピーの処理フローを示す。二次ストレージシステム内の処理もまた定期的に実行され、次のステップを含む。

ステップ４００１：複製マネジャ２３４−２は一次ストレージシステム２−１から更新データを受信し、ログディスク３１２−２内にデータを保存する。

ステップ４００２：もしも複製マネジャ２３４−２がステップ４００１においてＭＡＲＫＥＲ１８４を受信すると、処理はステップ４００３に進む。もしもそうでないと、処理は追加のデータを待つためにステップ４００１に戻る。

ステップ４００３：複製マネジャ２３４−２は特定のトランザクションの開始からの全てのデータと特定のトランザクションの終了（ＭＡＲＫＥＲ１８４を含む）が受信されたかをチェックする。もしも全てのデータが受信されていると、処理はステップ４００４に進む。もしもそうでないと、処理は、二次ストレージシステム２−２に到着していないデータを再び送ることを一次ストレージシステム２−１に要求するためにステップ４０１１に進む。

ステップ４００４：もしも二次ストレージシステム２−２が他のタスクを実行していてビジーであると、処理はステップ４００１に戻る。もしもそうでないと、処理はステップ４００５に進む。

ステップ４００５：複製マネジャ２３４−２は、二次ログディスク３１２−２内のデータを二次ボリューム３１４に適用することをトランザクションモニタ２３２−２に命令する。

ステップ４００６：複製マネジャ２３４−２は、二次ボリューム３１４に適用された二次ログディスク３１２−２内のデータを削除することをトランザクションモニタ２３２−２に命令する。

ステップ４０１１：もしもトランザクションの部分を形作る全てのデータが受信されていないと、複製マネジャ２３４−２は二次ストレージシステム２−２に到着していないデータを再び送る要求を一次ストレージシステム２−１に送る。

一次サイトが障害の時に、典型的なフェイルオーバ処理手順の下で、ユーザは二次サイトでアプリケーションプログラムを再開することを試みる。二次サイトで、アプリケーションプログラムを再開する前に、ユーザは二次サイトのホスト１−３、１−４の一方から二次ストレージシステム２−２にコミット機能を発行する。二次ストレージシステム２−２が要求を受信する時に、もしも二次ボリューム３１４にまだ適用されていないログディスク３１２−２内のデータがあると、二次ストレージシステム２−２はログディスク３１２−２内のデータを二次ボリューム３１４に連続的に適用する。しかし二次ボリューム３１４に適用されるデータは、トランザクションの開始からトランザクションの終わりまでの全てのデータがログディスク３１２−２に到着しているトランザクションデータに限定される。トランザクションが不完全なログディスク３１２−２内の他のデータは捨てられる。この処理手順の下で、二次サイトでアプリケーションプログラムを再開する時に、アプリケーションプログラムは、一次サイトが障害となった時に完全でなかったトランザクションのちょうど開始点でデータをアクセス可能である。

従って、前述の内容から、本発明のストレージシステムはトランザクションの開始とトランザクションの終わりに関する情報をアプリケーションプログラムから受信する手段を有すると見ることができる。ストレージシステムがトランザクションの開始を示す通知を受信する時に、更新Ｉ／Ｏオペレーションはログディスクに記録され、ストレージシステムがトランザクションの終わりの通知を受信する時に、ログディスク内に記録されたデータは作業ボリュームに委ねられることができる。この手段で、本発明は、ストレージシステム内のＩ／Ｏトランザクションを扱い、トランザクションを管理するためにアプリケーションプログラムに対して基本的基盤を提供する方法を提供する。

さらに、特定の実施例がこの明細書の中で示され、説明されたが、この技術に通常程度に精通する人達は、同じ目的を達成することを意図する任意の脚色が開示された特定の実施例に置き換えられることができることを理解する。この開示内容は本発明の任意のおよび全ての適応または変化を包括することを意図しており、上記の説明は説明的な形で行われたが、限定的なものではないことが理解される。従って、本発明の範囲は、添付の特許請求項に関して、この特許請求項が権利を有する同等物の全範囲と共に、適切に決定されるべきである。

図１は本発明の第一の実施例の方法と装置が適用されるシステムの例を示す。 図２は一つの論理デバイスが複数の物理デバイスから生成される方法の例を示す。 図３は図１に示されるシステムの機能図を示す。 図４はストレージシステムによって保持されるＬＵマッピングテーブルを示す。 図５は第一の実施例のトランザクションリストの説明を示す。 図６はトランザクション管理テーブルを示す。 図７はトランザクションＩ／Ｏドライバによって提供されるトランザクション処理ＡＰＩのリストを示す。 図８はＲｅｑｕｅｓｔＴｒａｎｓａｃｔｉｏｎ機能によって渡されるリストを示す。 図９はＲｅｑｕｅｓｔＴｒａｎｓａｃｔｉｏｎ機能がホストにおいてコールされる時のストレージシステム内のオペレーションのフローを示す。 図１０はＴＰ_Ｗｒｉｔｅ Ｒｅｑｕｅｓｔの処理フローを示す。 図１１はＴＰ_Ｒｅａｄ処理フローを示す。 図１２はコミット機能の処理を示す。 図１３は書き込みオペレーションの処理フローを示す。 図１４は読み出しオペレーションの処理フローを示す。 図１５は複数のアプリケーションプログラムが本発明の技術で機能する代わりの実施例を示す。 図１６はホストコンピュータ上のソフトウエアモジュールの間の機能的関係を示す。 図１７複製マネジャの初期コピーオペレーションの処理フローを示す。 図１８はログディスクの論理構造を示す。 図１９は第三の実施例で使用されるトランザクションリストを示す。 図２０は一次ストレージシステム内の更新コピーの処理フローを示す。 図２１は二次ストレージシステム内の更新コピーの処理フローを示す。

Claims (20)

1. ストレージシステムにおいてアプリケーションプログラムのトランザクションを管理する方法において、
   （ａ）前記のストレージシステムにおいて、第一のトランザクションの開始を示す命令を受信するステップと、
   （ｂ）前記の第一のトランザクションに対するデータを受信するために少なくとも一つの一次ボリュームを決定するステップと、
   （ｃ）前記の第一のトランザクションに対する前記の一次ボリュームに対して指定された書き込みデータを最初に保存するためのログボリュームを提供するステップと、
   （ｄ）前記の第一のトランザクションの完了を示す命令を前記のストレージシステムにおいて受信するステップと、
   （ｅ）ステップ（ｄ）の後で、前記の第一のトランザクションに対する前記のログボリューム内に保存された前記のデータを前記の少なくとも一つの一次ボリュームに書き込むステップと、
   から成ることを特徴とする方法。
2. もしも前記の少なくとも一つの一次ボリュームのデータへの読み出し要求が、前記のログボリューム内に保存されたが、まだ前記の少なくとも一つの一次ボリュームに書き込まれていないデータに対応すると、データがあたかも前記の少なくとも一つの一次ボリューム内に含まれているかのようにアプリケーションプログラムに示されるように、前記のログボリューム内に保存された前記の対応するデータが取り出されるステップをステップ（ｄ）の前にさらに含むことを特徴とする請求項１に記載の方法。
3. 前記の第一のトランザクションに対して要求された任意の論理デバイスが既に処理中の第二のトランザクションによって使用されているかの通知を返すステップをステップ（ａ）の後にさらに含むことを特徴とする請求項１に記載の方法。
4. 書き込み要求が、トランザクション識別子が前記の書き込み要求に含まれているかを決定することによって、前記の第一のトランザクションに対するものかあるいは通常の書き込み要求に対するものかを決定するステップをステップ（ａ）の後にさらに含むことを特徴とする請求項１に記載の方法。
5. 書き込み要求が、前記の書き込み要求内で指定された論理デバイスが前記の第一のトランザクションに対する書き込みターゲットとして特定されているかを決定することによって、前記の第一のトランザクションに対するものかあるいは通常の書き込み要求に対するものかを決定するステップをステップ（ａ）の後にさらに含むことを特徴とする請求項１に記載の方法。
6. 前記のログボリューム内の前記のデータの実際のストレージ位置を前記の第一の一次ボリューム内の前記のデータのターゲットストレージ位置と関連させるために前記のログボリュームへの各書き込みに続く情報を更新するステップをステップ（ｃ）の後にさらに含むことを特徴とする請求項１に記載の方法。
7. ステップ（ｅ）を開始する前に前記の一次ボリュームのスナップショットを生成するステップをステップ（ｄ）の後にさらに含むことを特徴とする請求項１に記載の方法。
8. 第一の一次ボリューム、第二の一次ボリューム、および少なくとも一つのログディスクを有する第一のストレージシステム内にデータを保存する方法において、
   そこでの実行のための第一のアプリケーションプログラムを有する少なくとも一つのホストが前記のストレージシステムとコミュニケーションを行い、
   トランザクションに対してトランザクション識別子を生成するステップと、
   前記の第一のアプリケーションプログラムによって呼び出され、前記の第一の一次ボリュームにデータを送る第一のサブアプリケーションから前記のトランザクションに対する第一の書き込みデータを前記の第一のストレージシステムによって受信するステップと、
   前記のアプリケーションプログラムによって呼び出され、前記の第二の一次ボリュームにデータを送る第二のサブアプリケーションから前記のトランザクションに対する第二の書き込みデータを前記の第一のストレージシステムによって受信するステップと、
   前記の第一の書き込みデータと前記の第二の書き込みデータをログボリューム内に保存するステップと、
   前記のトランザクションが完了していることを示す命令を受信するステップと、
   前記のトランザクションの完了に続いて、前記の第一の書き込みデータを前記の第一の一次ストレージボリュームに、および前記の第二の書き込みデータを前記の第二の一次ストレージボリュームに適用するステップと、
   から成ることを特徴とする方法。
9. 前記のトランザクションが完了していることを示す前記の命令を受信する前に読み出し要求を受信するステップと、
   前記の読み出し要求がまだ完了していない前記のトランザクションに対するものであるかを決定するステップと、
   をさらに含み、
   もしも前記の読み出し要求がまだ完了していない前記のトランザクションに対するものであると、およびもしも要求されたデータに対するアドレスが、前記のトランザクションの開始から更新された前記の第一または第二の一次ボリューム内の位置を指し示すと、前記の要求されたデータの最も新しいバージョンが前記のログボリュームから読み出され、前記の読み出し要求への応答で返されることを特徴とする請求項８に記載の方法。
10. 前記のトランザクション識別子が前記の読み出し要求に含まれていたかを決定するステップによって、および／または
    前記の読み出し要求によってターゲットにされた論理デバイスが前記のトランザクションに対して指定されるかを決定するステップによって、
    前記の読み出し要求が前記のトランザクションに対するものであるかを決定するステップをさらに含むことを特徴とする請求項９に記載の方法。
11. 前記の第一または第二の一次ボリュームの少なくとも一つのリモートコピーを受信するための少なくとも一つの二次ボリュームと少なくとも一つの二次ログボリュームを有し、前記の第一のストレージシステムとコミュニケーションを行う第二のストレージシステムを提供するステップと、
    前記のログボリュームから前記の二次ログボリュームに更新データを送るステップと、
    前記のトランザクションの完了の通知を受信すると、前記のトランザクションに関係する前記の二次ログボリューム内のデータを前記の二次ボリュームに適用するステップと、
    をさらに含むことを特徴とする請求項８に記載の方法。
12. もしも障害が前記の第一のストレージシステムの位置で発生すると、前記の第二のストレージシステムへのアクセスを有する第二のホスト上の第二のアプリケーションプログラムを再開するステップと、
    完了していないトランザクションに対するデータを前記の二次ログボリュームから削除するステップと、
    完了しているトランザクションに対する前記の二次ログボリュームからのデータを前記の二次ボリュームに適用するステップと、
    をさらに含むことを特徴とする請求項１１に記載の方法。
13. 各一次ボリュームのスナップショットを生成することによって、前記の少なくとも一つの一次ボリュームから前記の少なくとも一つの二次ボリュームにデータの初期コピーを実行するステップと、
    前記のスナップショットボリュームから前記の一次ボリュームとミラーペアを形成する二次ボリュームにデータをコピーするステップと、
    をさらに含むことを特徴とする請求項１１に記載の方法。
14. データが前記のログボリュームから前記の二次ログボリュームにコピーされたかを追跡するステップと、
    前記のトランザクションの完了に続いて前記のトランザクションに対する全てのデータが前記の二次ログボリュームにコピーされるまで前記のトランザクションに関係する情報の削除を防止するステップと、
    をさらに含むことを特徴とする請求項１１に記載の方法。
15. 前記のストレージシステムが、前記の書き込み要求が前記のトランザクションに対するものであることを決定可能であるために、前記のトランザクションに関係する各書き込み要求と共に前記のトランザクション識別子を含むステップをさらに含むことを特徴とする請求項８に記載の方法。
16. ターゲットの論理デバイスが前記のトランザクションに対して指定されているかを決定することによって、各書き込み要求が前記のトランザクションに関係するかを前記の第一のストレージシステムによってチェックするステップをさらに含むことを特徴とする請求項８に記載の方法。
17. コントローラと少なくとも一つのストレージデバイスを含む第一のストレージシステムと、
    第一のホスト上で動作する第一のアプリケーションを含み、前記の第一のストレージシステムとコミュニケーションを行う前記の第一のホストと、
    を備え、
    前記のホスト上で動作する第一のモジュールが、前記のアプリケーションによって起動されるトランザクションに対するトランザクション識別子を生成することを、前記のストレージシステムに要求し、
    前記のストレージシステム上で動作する第二のモジュールが、書き込み要求が前記のトランザクションに対するものかを決定し、
    第一の書き込み要求が前記のトランザクションに対するものである時に、前記の第二のモジュールが第一の書き込みデータを前記の第一の書き込み要求のターゲットである第一の一次ボリュームの代わりにログボリュームに最初は保存されるようにし、
    複数のタスクが実行され前記のトランザクションが首尾よく完了した時に、前記の第二のモジュールが、前記のトランザクションに対する前記の第一の書き込みデータを前記のログボリュームから前記の第一の一次ボリュームに適用する通知を前記の第一のモジュールから受信することを特徴とするシステム。
18. 前記のトランザクションの部分として呼び出され、第二のホスト上で動作する第二のアプリケーションを有し、前記の少なくとも一つのストレージシステムとコミュニケーションを行う前記の第二のホストをさらに含み、
    前記の第二のホストによって書き込まれるデータのターゲットとして前記の第一のストレージシステム上の第二の一次ボリュームをさらに含み、
    前記の第二のホストが前記のトランザクションの部分として前記のストレージシステムに第二の書き込み要求を発行する時に、前記の第二のストレージシステムが第二の書き込みデータを前記のログボリュームに保存し、
    前記のトランザクションが首尾よく完了する時に、前記の第二のモジュールが、前記のトランザクションに対する前記の第二の書き込みデータを前記のログボリュームから前記の第二の一次ボリュームに適用する通知を前記の第一のモジュールから受信することを特徴とする請求項１７に記載のシステム。
19. 前記の第二のモジュールが前記のトランザクションに対する読み出し要求を受信する時に、前記の第二のモジュールが、読み出されることを要求されたデータが前記のトランザクションの部分として更新され、前記のログボリュームに保存されたかを決定し、
    もしも前記の要求されたデータが前記のログボリュームに保存されたならば、前記の第二のモジュールが前記の要求されたデータの最も最近のバージョンを前記のログボリュームから読み出されるようにし、前記の要求に応答して返されるようにすることを特徴とする請求項１７に記載のシステム。
20. 二次ボリュームと二次ログボリュームを含み、前記の第一のストレージシステムとコミュニケーションを行う第二のストレージシステムをさらに含み、
    リモートコピー機能が前記の第一のストレージシステム上の前記の第一の一次ボリュームと前記の二次ストレージシステム上の前記の二次ボリュームの間で確立され、
    前記の第一のストレージシステム上の前記のログディスク上の更新データが前記の第二のストレージシステム上の前記の二次ログディスクにコピーされ、
    前記のトランザクションの完了の通知を受信すると、前記のトランザクションに対する前記の二次ログディスク上の前記の更新データが前記の二次ボリュームに適用されることを特徴とする請求項１７に記載のシステム。

Images