JP6167722B2 - ストレージシステム，ストレージ制御装置及びデータ転送方法 - Google Patents

Description

本発明は、ストレージシステム，ストレージ制御装置及びデータ転送方法に関する。

ストレージシステムにおいては、複数のストレージ装置をそなえ、一のストレージ（業務ストレージ）装置のデータを他のストレージ（バックアップストレージ）装置に複写することにより、バックアップが行なわれている。
また、遠隔地に配置された複数のストレージ装置間において、一のストレージ装置のデータを地理的に離れた場所の他のストレージ装置に複写するリモートコピー機能も知られている。このようなリモートコピー機能の一つとして、非同期モードでリモートコピーを行なう際のデータの書き込み順序性を保証するＲＥＣ（Remote Equivalent Copy）コンシステンシ・モード機能が知られている。

ストレージ装置としては、例えばＲＡＩＤ（Redundant Arrays of Inexpensive Disks）装置が用いられる。ＲＡＩＤ装置は、複数のＨＤＤ（Hard Disk Drive）を組み合わせて、冗長化されたストレージとして管理するものであり、上位装置に対して仮想的なストレージ（論理ボリューム）を提供する。ＲＡＩＤ装置は、分散キャッシュメモリ型のストレージシステムであり、論理ボリュームのデータのリード／ライト処理を制御モジュール（ＣＭ：Controller Module）毎に実行する。

ＲＥＣ機能においては、コピー元のストレージ装置（コピー元装置）内において記憶媒体内のデータをＣＭ毎に用意されたコピー元装置内の記録専用バッファに格納する。又、ＣＭ毎の各記録専用バッファは、データの読み書き処理の順序性を保証するため、複数の領域（バッファ領域）に分割して管理される。分割した個々のバッファ領域は世代として管理される。

記録専用バッファのバッファ領域がフルになるか、もしくは、データの格納開始から一定時間経過すると、コピー元装置は、同一世代の各バッファ領域内のデータをまとめてネットワークを介して接続されたコピー先のストレージ装置（コピー先装置）へ送信する。以下、ＲＥＣ機能において、コピー元装置の記録専用バッファ内の同一世代のデータをまとめて、ネットワークを介して接続されたコピー先の記憶装置へ送信する手法をまとめ送り方式という場合がある。

コピー先装置においては、受信したデータを記録専用バッファに一旦格納する。コピー先装置は、データの受信をすべて完了すると記録専用バッファ内のデータをまとめてコピー先の記録媒体内へ展開する。
ＲＥＣ機能においては、上述の如く記録専用バッファを使用して順序性のあるまとめ送り方式のコピーを行なうために、各ＣＭについての同世代のバッファ領域をバッファセットという単位で一括制御を行なっている。そして、コピー元記録専用バッファからのデータをバッファセットの単位で展開することで順序性を保証している。

図２１は従来のストレージシステムのバッファ構成を示す図である。この図２１に示すストレージシステム５００は、ネットワーク５０２を介して２つのストレージ装置５０１ａ，５０１ｂが接続されている。この図２１に示す例において、ストレージ装置５０１ａがコピー元装置であり、ストレージ装置５０１ｂがコピー先装置である。以下、ストレージ装置５０１ａをコピー元装置５０１ａという場合があり、ストレージ装置５０１ｂをコピー先装置５０１ｂという場合がある。

ストレージ装置５０１ａ，５０１ｂはそれぞれ、４つのＣＭ＃０〜＃３を備える。コピー元装置５０１ａにおいては、各ＣＭ＃０〜＃３はそれぞれ１つの送信バッファを備えている。一方、コピー先装置においては、各ＣＭ＃０〜＃３はそれぞれローカルバッファとミラーバッファとの２つの受信バッファ（記録専用バッファ）を備えている。
また、コピー元装置５０１ａにおいて、各ＣＭ毎の送信バッファは、それぞれ８つの（８世代分の）バッファ領域に分割されている。一方、コピー先装置５０１ｂにおいては、各ＣＭ＃０〜＃３のローカルバッファ及びミラーバッファが、それぞれコピー先装置５０１ｂと同様に、８つの（８世代分の）バッファ領域に分割されている。

コピー先装置５０１ｂにおいて、コピー元装置５０１ａから送信され、図示しないポートから各ＣＭのローカルバッファに転送されるデータは、他のＣＭのミラーバッファにその複写が格納されることで二重化される。
例えば、コピー元装置５０１ａにおいて、ＣＭ＃０のローカルバッファに転送されるデータは、ＣＭ＃１のミラーバッファにその複写が転送されて格納されることで二重化される。同様に、ＣＭ＃３のローカルバッファに転送されるデータはＣＭ＃０のミラーバッファに二重化され、ＣＭ＃１のローカルバッファに転送されるデータはＣＭ＃２のミラーバッファに二重化される。又、ＣＭ＃２のローカルバッファに転送されるデータはＣＭ＃３のミラーバッファに二重化される。

ここで、リモートコピー手法においては、コピー先装置５０１ｂにおいて、いずれかのＣＭがデグレード（Degrade：縮退）して使用不可の状態となった場合に、そのＣＭのローカルバッファに送信していたデータの送信先を二重化されている他のＣＭのミラーバッファに切り替えることでＲＥＣコンシステンシ転送を継続して行なう手法が知られている。すなわち、デグレードミラー（Degrade Mirror）監視手法である。

例えば、コピー先装置５０１ｂにおいてＣＭ＃０がデグレードした場合には、ＣＭ＃１のミラーバッファに格納されている（二重化されている）データを用いてＣＭ＃０のデータの展開処理を継続する。なお、ＣＭ＃０がデグレードしたことにより、ＣＭ＃１のミラーバッファに格納されるＣＭ＃０のデータは二重化されていない状態（二重化崩れの状態）となる。

また、ＣＭ＃３のローカルバッファに送信していたデータは、ＣＭ＃０のミラーバッファを用いることができないので、このＣＭ＃０のミラーバッファへの転送を行なわせないようにしながら、二重化崩れの状態でＲＥＣコンシステンシ転送を継続させる。以下、このような二重化を行なわせないよう監視している状態を二重化禁止監視状態という場合がある。

ＲＥＣコンシステンシ転送においては、コピー先装置５０１ｂは、記録専用バッファのデータを展開完了、解放する度に、コピー元装置５０１ａに対して、バッファ解放通知と空きバッファ通知とをシーケンシャルに送信する。
例えばＣＭ＃０がデグレードした場合には、コピー先装置５０１ｂは、このデグレードしたＣＭ＃０のバッファを除いた使用可能な（生存している）バッファのバッファ領域を示すＩＤ（受信バッファＩＤ）を空きバッファ通知としてコピー元装置５０１ａに送信する。

コピー元装置５０１ａでは、空きバッファ通知で知らされた受信側バッファＩＤと、送信バッファですでに割り当て済みの受信側バッファＩＤを除いた受信側バッファＩＤとを送信側の空きバッファ管理テーブル（図示省略）に登録する。
コピー元装置５０１ａは、データを送信する際に、この空きバッファ管理テーブルに登録されている受信側バッファＩＤを割り当ててコピー先装置５０１ｂへデータ送信を行なう。コピー先装置５０１ｂにおいては、データ受信時に、このデータに付された受信側バッファＩＤをみて、データの転送先のＣＭを判断する。

さて、前述の如く、一部のＣＭのデグレードにより二重化禁止状態となったコピー先装置５０１ｂにおいては、故障したＣＭの交換等によりデグレードが解消されると、二重化禁止状態を解除する必要がある。二重化禁止状態を解除して、バッファを二重化された状態に戻すことを二重化再構築という。

特開２００６−１０６８８３号公報 特開２００６−２６０２９２号公報 特開２００７−５１１８４４号公報

しかしながら、このような従来のストレージシステムにおいて、二重化再構築を行なう前、すなわち二重化されていないバッファが存在する状態においても、この二重化されていないバッファを備えるＣＭがデグレードするおそれがある。このように、二重化されていないバッファを備えるＣＭがデグレードすると、ＲＥＣセッション（REC Session）を使えない、エラーサスペンド（Error Suspend）の状態となる。

例えば、図２１を用いて前述した例において、コピー先装置５０１ｂにおいて、ＣＭ＃０がデグレードして二重化禁止監視状態にある場合には、ＣＭ＃３のデータは二重化崩れの状態である。この状態で、更にＣＭ＃３がデグレードすると、コピー先装置５０１ｂにおいてＣＭ＃３のデータが消失し、エラーサスペンド状態となる。
エラーサスペンドの状態になると、コピー元装置５０１ａとコピー先装置５０１ｂとの間でＲＥＣセッションを張りなおす必要があり、初期コピーとしてコピー元装置５０１ａの全データのコピーを最初から行なう必要が生じる。従って、順序性保証データ転送の再開に時間がかかるという課題がある。

１つの側面では、本発明は、順序性保証データ転送における冗長故障時に、短時間でデータ転送を再開することができることを目的とする。
なお、前記目的に限らず、後述する発明を実施するための形態に示す各構成により導かれる作用効果であって、従来の技術によっては得られない作用効果を奏することも本発明の他の目的の１つとして位置付けることができる。

このため、このストレージシステムは、第１の記憶装置からネットワークを介して接続された第２の記憶装置に対して順序性保証データ転送を行なうストレージシステムにおいて、前記第２の記憶装置における冗長化された２以上の制御装置にそれぞれ設けられ、データを冗長化して記憶する冗長化された２以上の受信バッファと、前記第１の記憶装置と前記第２の記憶装置との間で順序性保証データのコピー状態の整合性があるか否かを示すコピーセッションの状態を管理するセッション管理部と、順序性保証データが前記冗長化された２以上の受信バッファのいずれからも喪失したことを示すバッファデータロスト状態を管理するバッファ管理部と、を備え、前記第２の記憶装置が前記ストレージシステムの処理を停止させた要因が、前記第２の記憶装置における記憶媒体へのデータの展開処理中に発生した、前記冗長化された２以上の制御装置の多重故障である場合に、前記セッション管理部は前記コピーセッションの状態に整合性なしを設定し、前記バッファ管理部は前記バッファデータロスト状態をロスト状態であると設定し、前記第１の記憶装置と前記第２の記憶装置との間でデータ転送処理が再開された場合に、前記バッファ管理部により前記バッファデータロスト状態が前記ロスト状態であると設定されていると、前記セッション管理部は前記コピーセッションの状態に整合性ありを設定し、前記バッファ管理部は前記バッファデータロスト状態をロスト状態ではないと設定する。

一実施形態によれば、順序性保証データ転送における冗長故障時に、短時間でデータ転送を再開することができる。

実施形態の一例としてのストレージシステムのハードウェア構成を示す図である。 実施形態の一例としてのストレージシステムの機能構成を示す図である。 実施形態の一例としてのストレージシステムにおけるバッファ構成を例示する図である。 実施形態の一例としてのストレージシステムのストレージ装置におけるバッファの冗長化手法を説明する図である。 実施形態の一例としてのストレージシステムにおける受信バッファＩＤ管理テーブルを例示する図である。 実施形態の一例としてのバッファ管理テーブルを例示する図である。 実施形態の一例としてのバッファセット管理テーブルを例示する図である。 実施形態の一例としてのストレージシステムにおけるバッファ解放処理を例示する図である。 実施形態の一例としてのバッファセット管理テーブルを例示する図である。 実施形態の一例としてのストレージシステムにおける初回ネゴシエーション処理を説明するフローチャートである。 実施形態の一例としてのストレージシステムにおける初回ネゴシエーション直後の受信バッファＩＤ管理テーブルを例示する図である。 実施形態の一例としてのストレージシステムにおけるＲＥＣコンシステンシ転送の処理を説明するフローチャートである。 実施形態の一例としてのストレージシステムにおけるデグレード処理を説明するフローチャートである。 実施形態の一例としてのストレージシステムにおいてストレージ装置のＣＭをデグレードさせる例を示す図である。 実施形態の一例としてのストレージシステムにおけるホルト処理を説明するフローチャートである。 実施形態の一例としてのストレージシステムのストレージ装置においてホルト状態が検出される状態を示す図である。 実施形態の一例としてのストレージシステムのストレージ装置においてＲＥＣバッファの枯渇が生じた場合の処理を説明するフローチャートである。 実施形態の一例としてのストレージシステムのストレージ装置における差分ビットマップコピー処理を説明する図である。 実施形態の一例としてのストレージシステムにおけるアップグレード処理を説明するフローチャートである。 実施形態の一例としてのストレージシステムのストレージ装置においてアップグレードされた状態を示す図である。 従来のストレージシステムのバッファ構成を示す図である。

以下、図面を参照して本ストレージシステム，ストレージ制御装置及びデータ転送方法に係る実施の形態を説明する。ただし、以下に示す実施形態はあくまでも例示に過ぎず、実施形態で明示しない種々の変形例や技術の適用を排除する意図はない。すなわち、本実施形態を、その趣旨を逸脱しない範囲で種々変形（実施形態及び各変形例を組み合わせる等）して実施することができる。又、各図は、図中に示す構成要素のみを備えるという趣旨ではなく、他の機能等を含むことができる。

（Ａ）構成
図１は実施形態の一例としてのストレージシステム１のハードウェア構成を示す図、図２はその機能構成を示す図である。又、図３は実施形態の一例としてのストレージシステム１におけるバッファ構成を例示する図である。
実施形態の一例としてのストレージシステム１は、図１に示すように、リモート回線（通信回線）５０を介して複数（図１に示す例では２つ）のストレージ装置１０，２０が通信可能に接続されている。これらの、ストレージ装置１０，２０は地理的に離れた場所に配置されている。

ストレージ装置１０，２０は、それぞれ１以上（本実施形態では４つ）のＣＭ（情報処理装置）５１１−０〜５１１−３，５２１−０〜５２１−３をそなえる。
また、図１に示す例においては、ストレージ装置１０に上位装置としてのホスト装置２が接続され、又、ストレージ装置２０に上位装置としてのホスト装置３が接続されている。

ホスト装置２，３は、接続されたストレージ装置１０，２０のボリュームにデータの書き込みや読み出しを行なう。例えば、ホスト装置２はストレージ装置１０の業務ボリュームであるコピー元ボリュームに対してリードやライトのデータアクセス要求を行なう。ストレージ装置１０は、このデータアクセス要求に応じてコピー元ボリュームに対するデータアクセスを行ない、ホスト装置２に対して応答を行なう。

なお、ホスト装置２，３は、情報処理装置であり、例えば、図示しない、ＣＰＵ（Central Processing Unit）やメモリ等をそなえたコンピュータである。
本ストレージシステム１は、ストレージ装置１０のボリューム（論理ボリューム）のデータのコピーを他のストレージ装置２０にデータ転送することにより移行（コピー）するデータ移行機能をそなえる。

ここでは、ストレージ装置１０をコピー元筐体（移行元装置）とし、ストレージ装置２０をコピー先筐体（移行先装置）とする。以下、データ移行として、ストレージ装置（第１の記憶装置）１０のディスク装置１３１のデータのコピーをストレージ装置（第２の記憶装置）２０にデータ転送して、ストレージ装置２０のディスク装置２３１に格納する例について説明する。

以下、ストレージ装置１０を移行元装置１０といい、ストレージ装置２０を移行先装置２０という場合がある。又、以下、データのコピーをデータ移行と表現する場合がある。更に、ストレージ装置１０とストレージ装置２０との間におけるリモート回線５０を介したデータ転送をリモート転送という場合がある。
リモート回線５０は、データを通信可能に接続する通信回線であって、例えばＴＣＰ／ＩＰ等の規格に基づきデータ転送を実現する。

ストレージ装置１０，２０は、ホスト装置２，３に対して記憶領域を提供するものであり、例えば、ＲＡＩＤ装置である。なお、図１中においては、便宜上、ストレージ装置１０にホスト装置２が、又、ストレージ装置２０にホスト装置３がそれぞれ接続された状態を示しているが、各ストレージ装置１０，２０にそれぞれ２以上のホスト装置が接続されてもよい。

ストレージ装置１０，２０は、図１に示すように、ＣＭ５１１−０〜５１１−３，５２１−０〜５２１−３及びディスクエンクロージャ１３０，２３０をそなえる。
ＣＭ５１１−０〜５１１−３，５２１−０〜５２１−３はストレージ装置１０，２０における種々の制御を行なうものであり、上位装置であるホスト装置２，３からのストレージアクセス要求（アクセス制御信号）に従って、ディスクエンクロージャ１３０，２３０のディスク装置１３１，２３１へのアクセス制御等、各種制御を行なう。ＣＭ５１１−０〜５１１−３，５２１−０〜５２１−３は互いに同様のハードウェア構成を有する。

以下、ストレージ装置１０においてＣＭ５１１−０をＣＭ＃０という場合があり、同様に、ＣＭ５１１−１，５１１−２，５１１−３をそれぞれＣＭ＃１，＃２、＃３という場合がある。又、ストレージ装置２０においてＣＭ５２１−０をＣＭ＃０という場合があり、同様に、ＣＭ５２１−１，５２１−２，５２１−３をそれぞれＣＭ＃１，＃２、＃３という場合がある。

また、以下、ストレージ装置１０におけるＣＭを示す符号としては、複数のＣＭのうち１つを特定する必要があるときには符号５１１−０〜５１１−３もしくは＃０〜＃３を用いるが、任意のＣＭを指すときには符号５１１を用いるか、もしくは単にＣＭと示す。同様に、ストレージ装置２０におけるＣＭを示す符号としては、複数のＣＭのうち１つを特定する必要があるときには符号５２１−０〜５２１−３もしくは＃０〜＃３を用いるが、任意のＣＭを指すときには符号５２１を用いるか、もしくは単にＣＭと示す。

ディスクエンクロージャ１３０，２３０は、１以上のディスク装置１３１，２３１をそなえる。ディスク装置１３１，２３１は、例えば、ＨＤＤやＳＳＤ（Solid State Drive）である。ストレージ装置１０，２０においては、このＨＤＤ１３１，２３１の記憶領域が論理ボリュームに対して割り当てられる。
ＣＭ５１１，５２１は、図１に示すように、ＣＡ（Channel Adapter）１２４，２２４，ＲＡ（Remote Adapter）１２５，２２５，ＣＰＵ１１０，２１０，ＤＡ（Device Adapter）１２６，２２６及びメモリ１２７，２２７をそなえる。なお、図１に示す例においては、各ストレージ装置１０，２０に４つのＣＭ５１１−０〜５１１−３，５２１−０〜５２１−３がそなえられているが、これに限定されるものではなく、それぞれ３つ以下もしくは４つ以上のＣＭ５１１，５２１をそなえてもよい。

ＣＡ１２４，２２４は、ホスト装置２，３と通信可能に接続するインタフェースコントローラであり、例えば、ファイバチャネルアダプタである。
そして、例えばオペレータがホスト装置２を介して、ストレージ装置１０からストレージ装置２０へのデータ移行指示を入力すると、ＣＡ１２４がデータ移行指示を受信する受信部として機能する。

ＲＡ１２５，２２５は、リモート回線５０を介して他のストレージ装置２０，１０と通信可能に接続（リモート接続）するインタフェースコントローラであり、例えば、ファイバチャネルアダプタである。
ＤＡ１２６，２２６は、ディスクエンクロージャ１３０，２３０と通信可能に接続するインタフェースコントローラであり、例えば、ファイバチャネルアダプタである。

メモリ１２７，２２７はＲＯＭ（Read Only Memory）及びＲＡＭ（Random Access Memory）を含む記憶装置である。メモリ１２７，２２７のＲＯＭには、コピー制御（リモート転送制御）に係るソフトウェアプログラムやこのプログラム用のデータ類が書き込まれている。メモリ１２７，２２７上のソフトウェアプログラムは、ＣＰＵ１１０，２１０に適宜読み込まれて実行される。又、メモリ１２７，２２７のＲＡＭは、一次記憶メモリあるいはワーキングメモリとして利用される。

また、メモリ（ＲＡＭ）１２７，２２７における所定の領域には、例えば、他のストレージ装置２０，１０に対して送信するデータが一時的に格納され、これによりメモリ１２７，２２７は、ＲＥＣバッファ（記録専用バッファ）３０−０〜３０−３，４０−０〜４０−３，４１−０〜４１−３（図３等参照）として機能する。すなわち、メモリ１２７，２２７は、後述するリモート転送時に、他のストレージ装置２０，１０に対して転送するデータを一時的に格納する転送データバッファとして機能する。

図３に示すように、ＲＥＣバッファ３０−０〜３０−３，４０−０〜４０−３，４１−０〜４１−３は、データの読み書き処理の順序性を保証するため、複数の領域（バッファ領域，格納領域）に分割して管理される。分割した個々のバッファ領域は世代として管理する。図３に示す例においては、ＲＥＣバッファ３０−０〜３０−３，４０−０〜４０−３，４１−０〜４１−３は、世代１〜８の８つの世代のバッファ領域にそれぞれ分割されている。各世代のバッファ領域は時系列で管理される。

また、各バッファ領域はストレージ装置１０，２０間のコピー処理の完了後に開放される。開放とは、当該バッファ領域にデータを格納可能な状態とすることである。
ストレージ装置１０において、ＣＭ＃０にはＲＥＣバッファ３０−０が備えられている。同様に、ＣＭ＃１，＃２，＃３には、ＲＥＣバッファ３０−１，３０−２，３０−３がそれぞれ備えられている。

なお、以下、ストレージ装置１０におけるＲＥＣバッファを示す符号としては、複数のＲＥＣバッファのうち１つを特定する必要があるときには符号３０−０〜３０−３を用いるが、任意のＲＥＣバッファを指すときには符号３０を用いる。
また、ストレージ装置１０における各ＲＥＣバッファ３０に備えられる各バッファ領域には、それぞれユニークな識別情報であるバッファＩＤが設定されている。図３に示す例において、ＲＥＣバッファ３０−０にはバッファＩＤ１０００〜１００７で表される８つのバッファ領域が形成されている。

同様に、ＲＥＣバッファ３０−１にはバッファＩＤ１１００〜１１０７で表される８つのバッファ領域が、ＲＥＣバッファ３０−２にはバッファＩＤ１２００〜１２０７で表される８つのバッファ領域が、ＲＥＣバッファ３０−３にはバッファＩＤ１３００〜１３０７で表される８つのバッファ領域がそれぞれ形成されている。
そして、これらの各ＣＭ＃０〜＃３の各ＲＥＣバッファ３０において、図中、左右方向に隣接するバッファ領域が同世代として用いられる。例えば、ＣＭ＃０，＃１，＃２，＃３において、バッファＩＤ１０００，１２００，１２００，１３００の各バッファ領域が同世代として用いられる。

ストレージ装置２０において、ＣＭ＃０には２つのＲＥＣバッファ４０−０，４１−０が備えられている。同様に、ＣＭ＃１にはＲＥＣバッファ４０−１，４１−１が、ＣＭ＃２にはＲＥＣバッファ４０−２，４１−２が、ＣＭ＃３にはＲＥＣバッファ４０−３，４１−３が、それぞれ備えられている。なお、以下、ストレージ装置１０におけるＲＥＣバッファを示す符号としては、複数のＲＥＣバッファのうち１つを特定する必要があるときには符号４０−０〜４０−３や４１−０〜４１−３を用いるが、任意のＲＥＣバッファを指すときには符号４０や４１を用いる。

このストレージ装置２０において、ＲＥＣバッファ４０は、ストレージ装置１０のＲＥＣバッファ３０に対応する。すなわち、ＲＥＣバッファ４０−０がＲＥＣバッファ３０−０に対応し、このＲＥＣバッファ４０−０に形成された各バッファ領域には、ＲＥＣバッファ３０−０の各バッファ領域と同じバッファＩＤが付されている。そして、ＲＥＣコンシステンシ転送において、ストレージ装置１０のＲＥＣバッファ３０−０のデータのコピーが、ストレージ装置２０のＲＥＣバッファ４０−０に格納される。

同様に、ＲＥＣバッファ４０−１，４０−２，４０−３に形成された各バッファ領域には、ＲＥＣバッファ３０−１，３０−２，３０−３の各バッファ領域と同じバッファＩＤがそれぞれ付されている。そして、ＲＥＣコンシステンシ転送において、ストレージ装置１０のＲＥＣバッファ３０−１，３０−２，３０−３のデータのコピーが、ストレージ装置２０のＲＥＣバッファ４０−１，４０−２，４０−３にそれぞれ格納される。なお、これらのＲＥＣバッファ４０をローカルバッファといい、以下、ＲＥＣバッファ４０をローカルバッファ４０という場合がある。

ストレージ装置２０において、ＲＥＣバッファ４１は、ＲＥＣバッファ４０に対応して備えられ、ＲＥＣバッファ４０と同様の構成を備える。ただし、これらのＲＥＣバッファ４１の各バッファ領域には、ＲＥＣバッファ４０とは異なるバッファＩＤが設定されている。
例えば、図３に示す例において、ＲＥＣバッファ４１−０にはバッファＩＤ１０８０〜１０８７で表される８つのバッファ領域が形成されている。

同様に、ＲＥＣバッファ４１−１にはバッファＩＤ１１８０〜１１８７で表される８つのバッファ領域が、ＲＥＣバッファ４１−２にはバッファＩＤ１２８０〜１２８７で表される８つのバッファ領域が、ＲＥＣバッファ４１−３にはバッファＩＤ１３８０〜１３８７で表される８つのバッファ領域がそれぞれ形成されている。
ＲＥＣバッファ４１には、ＲＥＣバッファ４０に格納されるデータのコピーが格納される。これらのＲＥＣバッファ４１をミラーバッファという。以下、ＲＥＣバッファ４１をミラーバッファ４１という場合がある。

ただし、本ストレージシステム１においては、ミラーバッファ４１には、他のＣＭのローカルバッファ４０のコピーが格納される。具体的には、各ＣＭのミラーバッファ４１には、当該ＣＭと対（ペア）もしくはセットを成す他のＣＭのローカルバッファ４０のコピーが格納される。
また、本ストレージシステム１においては、各ＣＭ５１１についての同世代のバッファ領域がバッファセットという単位で取り扱われ、一括制御される。

例えば、図３に示す例において、ＣＭ＃０のバッファＩＤ１０００、ＣＭ＃１のバッファＩＤ１１００，ＣＭ＃２のバッファＩＤ１２００及びＣＭ＃３のバッファＩＤ１３００の各バッファが同世代のバッファ領域であり、同じバッファセットを構成する。同様に、図３に示す例において、ストレージ装置１０，２０において紙面横方向に並ぶ８つのバッファ領域が、同世代のバッファ領域であり、同じバッファセットを構成する。

また、各バッファセットには、バッファセットを一意に特定するためのバッファセットＩＤが設定されている。図３に示す例においては、８つのバッファセットが示されており、各バッファセットＩＤとして、例えば、０〜ｎ（ｎ＝８）の整数が用いられる。
ここで、ストレージ装置２０においては、２つのＣＭをペア（もしくはセット）とする。本実施形態においては、ＣＭ＃０とＣＭ＃１とがペアを構成し、ＣＭ＃２とＣＭ＃３とがペアを構成する。

そして、各ＣＭのミラーバッファ４１には、当該ＣＭとペアを組むＣＭのローカルバッファ４０のデータのコピーを格納することにより、ローカルバッファ４０のデータを冗長化している。
すなわち、ストレージ装置２０においては、ローカルバッファ４０及びミラーバッファ４１により冗長化され、これらのローカルバッファ４０及びミラーバッファ４１が冗長化受信バッファを構成する。

図４は実施形態の一例としてのストレージシステム１のストレージ装置２０におけるバッファの冗長化手法を説明する図である。
この図４中において矢印で示すように、ストレージ装置２０において、ＣＭ＃０のミラーバッファ４１−０には、ＣＭ＃１のローカルバッファ４０−１のデータのコピーが格納される。同様に、ＣＭ＃１のミラーバッファ４１−１には、ＣＭ＃０のローカルバッファ４０−０のデータのコピーが格納され、ＣＭ＃２のミラーバッファ４１−２は、ＣＭ＃３のローカルバッファ４０−３のデータのコピーが格納される。又、ＣＭ＃３のミラーバッファ４１−３には、ＣＭ＃２のローカルバッファ４０−２のデータのコピーが格納される。

以下、これらのペアを成す１組のＣＭ（ＣＭ＃０とＣＭ＃１，ＣＭ＃２とＣＭ＃３）のことをペアＣＭという場合がある。
なお、ＲＥＣバッファ３０−０〜３０−３，４０−０〜４０−３，４１−０〜４１−３を用いたデータのリモート転送手法については後述する。
また、メモリ１２７，２２７における他の所定の領域には、ホスト装置２，３から受信したデータや、ホスト装置２，３に対して送信するデータが一時的に格納され、これによりメモリ１２７，２２７はバッファメモリとしても機能する。又、メモリ１２７には、図示しないコピービットマップも格納される。

コピービットマップは、上述したＲＥＣバッファ３０，４０，４１によるデータの更新順序を保証できなった状態でのストレージ装置１０側でデータの整合性を保証するために用いられる。このコピービットマップには、ストレージ装置１０における更新データ箇所やコピーセッション復旧までのデータ更新箇所等が差分ビットマップの形で記録される。
さらに、メモリ１２７，２２７における他の所定の領域には、後述するＣＰＵ１１０，２１０がプログラムを実行する際に、データやプログラムが一時的に格納・展開される。又、メモリ１２７における他の所定の領域には、ＲＥＣコンシステンシ転送において一般的に用いられる、図示しない、セッションマッピングテーブルやＲＥＣバッファ制御テーブル等も格納される。

また、メモリ１２７のＲＡＭには、後述する、受信バッファＩＤ管理テーブル１０１，バッファ管理テーブル１０２，バッファセット管理テーブル１０３及びセッション管理テーブル１０４が格納される。メモリ２２７のＲＡＭには、後述する、受信バッファＩＤ管理テーブル２０１，バッファ管理テーブル２０２，バッファセット管理テーブル２０３及びセッション管理テーブル２０４が格納される。

メモリ１２２，２２２のＲＯＭには、ＣＰＵ１１０，２１０が実行するプログラムや種々のデータが格納されている。
ＣＰＵ１１０，２１０は、種々の制御や演算を行なう処理装置であり、メモリ１２２等に格納されたプログラムを実行することにより、種々の機能を実現する。
そして、ストレージ装置１０のＣＰＵ１１０は、図２に示すように、ＩＯ処理部１１，送信側コピー処理部１２，送信側ネゴシエーション処理部１３，送信側デグレード処理部１４，送信側ホルト処理部１５，送信側アップグレード処理部１６及びテーブル管理部１７として機能する。

また、ストレージ装置２０のＣＰＵ２１０は、図２に示すように、受信側コピー処理部２１，受信側ネゴシエーション処理部２３，受信側デグレード処理部２４，受信側ホルト処理部２５，受信側アップグレード処理部２６及びテーブル管理部２７として機能する。
なお、ＩＯ処理部１１，送信側コピー処理部１２，送信側ネゴシエーション処理部１３，送信側デグレード処理部１４，送信側ホルト処理部１５，送信側アップグレード処理部１６及びテーブル管理部１７としての機能を実現するためのプログラムや、受信側コピー処理部２１，受信側ネゴシエーション処理部２３，受信側デグレード処理部２４，受信側ホルト処理部２５，受信側アップグレード処理部２６及びテーブル管理部２７として機能するためのプログラムは、例えばフレキシブルディスク，ＣＤ（ＣＤ−ＲＯＭ，ＣＤ−Ｒ，ＣＤ−ＲＷ等），ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−ＲＡＭ，ＤＶＤ−Ｒ，ＤＶＤ＋Ｒ，ＤＶＤ−ＲＷ，ＤＶＤ＋ＲＷ，ＨＤ ＤＶＤ等），ブルーレイディスク，磁気ディスク，光ディスク，光磁気ディスク等の、コンピュータ読取可能な記録媒体に記録された形態で提供される。そして、コンピュータはその記録媒体から図示しない読取装置を介してプログラムを読み取って、内部記憶装置または外部記憶装置に転送し格納して用いる。又、そのプログラムを、例えば磁気ディスク，光ディスク，光磁気ディスク等の記憶装置（記録媒体）に記録しておき、その記憶装置から通信経路を介してコンピュータに提供するようにしてもよい。

ＩＯ処理部１１，送信側コピー処理部１２，送信側ネゴシエーション処理部１３，送信側デグレード処理部１４，送信側ホルト処理部１５，送信側アップグレード処理部１６及びテーブル管理部１７としての機能を実現する際には、内部記憶装置（本実施形態ではメモリ１２７）に格納されたプログラムがコンピュータのマイクロプロセッサ（本実施形態ではＣＰＵ１１０）によって実行される。このとき、記録媒体に記録されたプログラムをコンピュータが読み取って実行するようにしてもよい。

同様に、受信側コピー処理部２１，受信側ネゴシエーション処理部２３，受信側デグレード処理部２４，受信側ホルト処理部２５，受信側アップグレード処理部２６及びテーブル管理部２７としての機能を実現する際には、内部記憶装置（本実施形態ではメモリ２２７）に格納されたプログラムがコンピュータのマイクロプロセッサ（本実施形態ではＣＰＵ２１０）によって実行される。このとき、記録媒体に記録されたプログラムをコンピュータが読み取って実行するようにしてもよい。

（ａ）ストレージ装置１０
ストレージ装置１０において、ＣＭ５１１は、ＩＯ処理部１１，送信側コピー処理部１２，送信側ネゴシエーション処理部１３，送信側デグレード処理部１４，送信側ホルト処理部１５，送信側アップグレード処理部１６及びテーブル管理部１７として機能する。又、ＣＭ５１１には、受信バッファＩＤ管理テーブル１０１，バッファ管理テーブル１０２，バッファセット管理テーブル１０３及びセッション管理テーブル１０４が備えられる。なお、図２に示す例においては、ストレージ装置１０に備えられた複数のＣＭ５１１のうち、マスタとして機能する一のＣＭ５１１のみを示し、スレーブとして機能する他のＣＭ５１１の図示を省略している。すなわち、ＩＯ処理部１１，送信側コピー処理部１２，送信側ネゴシエーション処理部１３，送信側デグレード処理部１４，送信側ホルト処理部１５，送信側アップグレード処理部１６及びテーブル管理部１７として機能は、マスタＣＭ５１１に備えられる。

ＩＯ処理部１１は、ホスト２から送信されるデータ（ライトデータ）を受け付け、処理する。ＩＯ処理部１１は、格納予約処理部１１１及び格納処理部１１２を備える。
格納予約処理部１１１は、ホスト２から送信されたライトデータをバッファメモリに格納し、ＲＥＣバッファ３０に格納する準備を行なう。
格納処理部１１２は、ＲＥＣバッファ３０へのデータの格納制御を行なう。格納処理部１１２は、ＲＥＣバッファ３０がアクティブになると、格納予約処理部１１によって準備されたライトデータをバッファメモリから読み出し、ＲＥＣバッファ３０に格納する。

送信側コピー処理部１２は、ストレージ装置１０のデータのコピーをＲＥＣコンシステンシ転送によりストレージ装置２０に転送する処理を行なう。送信側コピー処理部１２は、ストレージ装置１０とストレージ装置２０との間のデータ転送を制御する。本実施形態において、送信側コピー処理部１２は、ストレージ装置１０からストレージ装置２０へのデータ転送をＲＥＣコンシステンシ転送を用いて行なう。

送信側コピー処理部１２は、バッファ切替処理部１２１，割当処理部１２２及び転送処理部１２３を備える。
バッファ切替処理部１２１は、ＲＥＣコンシステンシ転送におけるバッファ領域の世代間の切り替えを行なう。例えば、バッファ切替処理部１２１は、所定期間毎にＲＥＣバッファ３０のアクティブな世代を、次世代のバッファ領域に切り替える。又、バッファ切替処理部１２１は、ストレージ装置１０においてＲＥＣバッファ３０におけるアクティブな（最新の）世代の領域のメモリサイズが枯渇した場合に、ＲＥＣバッファ３０のアクティブな世代を、次世代のバッファ領域に切り替える。

なお、このバッファ切替処理部１２１によるバッファ領域の切り替えは、既知の種々の手法を用いて行なうことができ、その詳細な説明は省略する。
割当処理部１２２は、ストレージ装置２０にデータを送信する際に、受信バッファＩＤ管理テーブル１０１を参照して、受信側バッファＩＤを割り当てる処理を行なう。
図５は実施形態の一例としてのストレージシステム１における受信バッファＩＤ管理テーブル１０１，２０１を例示する図である。この図５に示す例においては、ストレージ装置２０に備えられたＲＥＣバッファ４０の各バッファ領域（バッファＩＤ）に対して、使用状況（空き状況）を示す“割当”もしくは“未割当”が対応付けられている。すなわち、このバッファ管理テーブル１０１において、“未割当”が設定されているバッファＩＤがストレージ装置２０で使用可能なバッファ領域を示す。

割当処理部１２２は、この受信バッファＩＤ管理テーブル１０１において“未割当”が設定されているバッファＩＤを選択して、送信するデータに割り当てる。
なお、この割当処理部１２２によるバッファＩＤの割当手法は、既知の種々の手法を用いて行なうことができ、その詳細な説明は省略する。
また、割当処理部１２２は、ストレージ装置２０のバッファ解放処理部２１３から、解放したバッファ領域のバッファＩＤ（受信バッファＩＤ）を解放通知とともに受信すると、この受信バッファＩＤ管理テーブル１０１におけるバッファＩＤに対して“未割当”を設定する。

転送処理部（転送継続処理部）１２３は、ＲＥＣバッファ３０に格納されているデータをストレージ装置２０に送信する。転送処理部１２３は、データを、割当処理部１２２によって割り当てられたバッファＩＤとともにストレージ装置２０に送信する。転送処理部１２３は、各ＣＭ５１１についての同世代のバッファ領域（バッファセット）単位でデータ転送を行なう。すなわち、転送処理部１２３はバッファセットを成す各バッファ領域のデータを一括してストレージ装置２０に転送する。

なお、この転送処理部１２３によるデータ転送手法は、既知の種々の手法を用いて行なうことができ、その詳細な説明は省略する。
また、転送処理部１２３は、ストレージ装置２０のバッファの状態（バッファ状態）として、後述するバッファ管理テーブル１０２に“Halt”が設定されている場合には、データの転送を行なわない。バッファ状態“Halt”は、バッファが使えない状態であり、順序性保障動作ができない状態を示す。

バッファ状態がホルト（Halt）の状態においては、ストレージ装置１０，２０間でコピーデータの転送は行なわれず、順序性保証されたデータ格納も行なわれない。
そして、ホスト装置２等からストレージ装置１０に対して更新が行なわれると、ＲＥＣセッションに関連付けされているコピービットマップ（図示省略）に更新箇所が記憶される。

なお、バッファ状態として設定される情報としては、“Halt ”の他に、“Active”と“Buffering”とがある。バッファ状態“Active”は、バッファが使える状態であり、順序性保障動作ができる状態を示す。すなわち、転送処理部１２３は、バッファ管理テーブル１０２においてバッファ状態として“Active”が設定されている場合に、データの転送を行なう。

バッファ状態の“Active”は、ＲＥＣバッファ３０が使用可能な状態を示し、ＲＥＣバッファ３０を用いたストレージ装置１０，２０間でのコピーが可能であることを示す。
バッファ状態の“Active”の状態においては、ストレージ装置１０とストレージ装置２０との間では、順序性保証された転送を行ないながら、ＲＥＣバッファ３０には順序性保証されたデータ格納が行なわれる。

バッファ状態が“Halt”及び“Buffering”の各状態は、いずれもＲＥＣバッファ３０を用いたストレージ装置１０，２０間でのコピーを実施不可な状態（ホルト状態）であることを示す。このホルト状態においては、送信側ホルト処理部１５や受信側ホルト処理部２５によるホルト処理が実行される。
ただし、バッファ状態が“Buffering”においては、ＲＥＣバッファ３０のコピーデータは、ストレージ装置１０からストレージ装置２０へ転送はされないものの、ＲＥＣバッファ３０にはデータを格納可能である。すなわち、ホスト装置２等からストレージ装置１０に対して更新が行なわれると、ＲＥＣバッファ３０に更新にかかるデータを格納することで、順序性保証は維持されている。

すなわち、ストレージ装置１０からストレージ装置２０へ転送はされないものの、順序性保障されたデータ格納を送信側のストレージ装置１０においてキープした状態である。
メモリ上のバッファやディスクバッファでバッファリングし続けている状態で、ストレージ装置１０，２０間で転送が再開されると、バッファ状態が“Buffering”から“Active”に変更され、ストレージ装置１０，２０間でＲＥＣバッファ３０を順序性保証された転送が再開される。

バッファの状態が転送再開で“Halt”から“Active”に変わると、コピービットマップに記憶された更新箇所に従って、ストレージ装置１０からストレージ装置２０に対して更新差分データが送信される（差分ビットマップコピー）。そして、この差分ビットマップコピーが完了した時点で、ストレージ装置１０とストレージ装置２０とのデータが整合性あり（Equivalent）な状態となる。

すなわち、コピーセッションの状態が “Copying” から “Equivalent” に遷移し、ストレージ装置１０，２０間で順序性保証データ転送が再開される。
送信側ネゴシエーション処理部１３は、ストレージ装置１０におけるネゴシエーション処理を行なう。
ネゴシエーションは、例えば、ストレージシステム１の起動時に実行され、例えば、認証方式の他、パラメータ・キーとそれに対応する適正な範囲値等を交換することにより、セッションの確立を行なう。送信側ネゴシエーション処理部１３は、ストレージ装置２０の受信側ネゴシエーション処理部２３との間でネゴシエーションを行なう。

また、送信側ネゴシエーション処理部１３は、ネゴシエーション処理時において、バッファ管理テーブル１０２やバッファセット管理テーブル１０３の初期化を行なう。
なお、本ストレージシステム１におけるネゴシエーション時の処理は図１１を用いて後述する。
送信側デグレード処理部１４は、ストレージ装置１０において機器のデグレードを行なう。デグレードは、異常等が検知された機器を使用不可の状態（退避状態，非認識状態）にすることで、この機器による影響がシステム内の他の部位に波及することを阻止する。デグレードの手法としては、例えば、バスの遮断や電力供給の遮断等、既知の種々の手法を用いて行なうことができる。

例えば、ストレージ装置１０において、いずれかのＣＭに異常が検知された場合に、送信側デグレード処理部１４は、そのＣＭをデグレードさせ使用不可な状態にする。
送信側デグレード処理部１４は、例えば、対象機器への電力供給やデータパスを遮断することでデグレードを実施する。なお、この送信側デグレード処理部１４によるデグレード手法は、既知の種々の手法を用いて行なうことができ、その詳細な説明は省略する。

送信側アップグレード処理部１６は、ストレージ装置１０において、送信側デグレード処理部１４によりデグレードされた機器を復旧（アップグレード）させて、使用可能な状態にする。例えば、いずれかのＣＭがデグレードした状態において、保守作業者がデグレードされたＣＭを交換等した場合には、送信側アップグレード処理部１６は、このＣＭをアップグレードさせる。

送信側アップグレード処理部１６は、例えば、遮断されていた対象機器への電力供給やデータパスを復旧させることでアップグレードを実施する。なお、この送信側アップグレード処理部１６によるアップグレード手法は、既知の種々の手法を用いて行なうことができ、その詳細な説明は省略する。
送信側ホルト処理部（設定処理部）１５は、ストレージ装置２０においてシステム内の処理を停止させるホルト（Halt）状態が検出された場合の処理を行なう。送信側ホルト処理部１５は、ストレージ装置２０においてホルト状態が検出されると、ストレージ装置２０へのデータ転送を中止させるとともに、バッファ管理テーブル１０２におけるバッファの状態を“Buffering”とする。又、送信側ホルト処理部１５は、後述するセッション管理テーブル１０４におけるコピーセッションの状態（フェーズ）を“Equivalent（整合性あり）”の状態から“Copying（整合性なし）”に変更する。

更に、送信側ホルト処理部１５は、バッファ管理テーブル１０２において受信側バッファデータロスト状態に“ロスト状態である”旨の設定を行なう。
例えば、図１６においては、ストレージ装置２０において、ペアＣＭを構成するＣＭ＃０とＣＭ＃１とがともにデグレードしている状態を示している。このように、ペアＣＭを構成する２つのＣＭが同時にデグレードすると（以下、ペアデグレードという場合がある）、ＣＭ＃０，＃１のローカルバッファ４０及びミラーバッファ４１の各データは、いずれも消失することとなる。

本ストレージシステム１においては、このように、ペアＣＭを構成する２つのＣＭが同時にデグレードした場合には、エラーサスペンド状態にはせずに、ホルト状態へ切り替え、ネゴシエーション禁止状態とする。
テーブル管理部（転送継続処理部，セッション管理部，バッファ管理部）１７は、受信バッファＩＤ管理テーブル１０１，バッファ管理テーブル１０２，バッファセット管理テーブル１０３及びセッション管理テーブル１０４を管理し、これらのテーブルの設定値の変更等を行なう。

また、テーブル管理部１７（セッション管理部）は、後述するバッファ管理テーブル１０２の受信側バッファデータロスト状態を参照して、受信側バッファデータロスト状態に“ロスト状態”が設定されている場合には、以下の処理を行なう。
すなわち、後述するセッション管理テーブル１０４におけるコピーセッションの状態（フェーズ）を“Copying（整合性なし）”から“Equivalent（整合性あり）”に書き換える。このように、テーブル管理部１７は、セッション管理テーブル１０４の設定の変更等を行なうことにより、コピーセッションの状態を管理する。

また、テーブル管理部（バッファ管理部）１７は、後述するバッファ管理テーブル１０２における受信側バッファデータロスト状態を“ロスト状態である”から“ロスト状態ではない”に書き換える。これにより、ストレージ装置１０からストレージ装置２０への順序性保証データ転送が継続して実行されることになる。このように、テーブル管理部１７は、バッファ管理テーブル１０２の設定の変更等を行なうことにより、バッファデータロスト状態を管理する。

バッファ管理テーブル１０２は、ストレージ装置１０におけるＲＥＣバッファ３０に関する情報をテーブル状に管理する。なお、このバッファ管理テーブル１０２と同様の構成を備えるバッファ管理テーブル２０２がストレージ装置２０にも格納されている。
図６は実施形態の一例としてのバッファ管理テーブル１０２，２０２を例示する図である。バッファ管理テーブル１０２，２０２は、この図６に示すように、バッファ領域のサイズに関する情報（送信バッファサイズ，１ＣＭ１バッファサイズ，バッファリストサイズ，１ＣＭあたりのバッファトータルサイズ，送信バッファセット数）や、ＲＥＣバッファ４０の使用状態を示す情報（バッファ状態，ネゴシエーション状態，受信側バッファデータロスト状態，展開処理中バッファセットＩＤ，各バッファセットの使用状態）を備える。

なお、ストレージ装置１０に備えられるバッファ管理テーブル１０２においては属性として“送信筐体”が設定され、ストレージ装置２０に備えられるバッファ管理テーブル２０２においては属性として“受信筐体”が設定される。
バッファ状態としては、前述した“Active”，“Halt”及び“Buffering”のうちいずれかの状態が格納される。

また、受信側バッファデータロスト状態は、受信側のＲＥＣ３０がロスト状態であるか否かを示すものであり、「ロスト状態である」もしくは「ロスト状態ではない」のいずれかの状態が格納される。この受信側バッファデータロスト状態における「ロスト状態である」もしくは「ロスト状態ではない」旨の設定は、例えばフラグ等により設定される。
なお、バッファ管理テーブル１０２，２０２において、受信側バッファデータロスト状態以外の情報は、既知のバッファ管理テーブルと同様であるので、その説明は省略する。

バッファセット管理テーブル１０３は、各バッファセットに関する情報をテーブル状に管理する。
図７は実施形態の一例としてのバッファセット管理テーブル１０３を例示する図である。
バッファセット管理テーブル１０３は、バッファセット毎、すなわち、バッファセットＩＤに対して、バッファセットリンクPrev及びバッファセットリンクNextが関連付けて登録されている。

ここで、バッファセットリンクPrevは、一つ前の世代のバッファセットのバッファセットＩＤである。なお、図７に示す例においては、バッファセットＩＤ＝０のバッファセットが先頭（最も古い世代）であるので、便宜上“0xffff”が設定されている。バッファセットリンクNextは、一つ後の世代のバッファセットのバッファセットＩＤである。
また、バッファセット管理テーブル１０３は、バッファセットを構成する各バッファ領域の状態を管理している。

すなわち、バッファセットを構成する各バッファ領域のバッファＩＤ（送信バッファＩＤ，受信バッファＩＤ）に対して、バッファ送信状態とバッファセット管理テーブル受信状態とが関連付けて登録されている。これらのバッファ送信状態及びバッファセット管理テーブル受信状態としては、“送信中”もしくは“送信済み”が設定される。
バッファセット管理テーブル１０３は、例えば、バッファ領域へのデータを格納時や、ストレージ装置１０（送信側）とストレージ装置２０（受信側）とで送受信バッファをくくりつける際、データ送信時、データ送信完了時、バッファセット解放時、等のタイミングで更新される。

ストレージ装置１０，２０間の順序性保証データ転送途中でストレージ装置２０においてペアデグレードが生じてコピーセッションが停止された場合には、後述の如くコピーセッションの状態が“Copying” から “Equivalent” に遷移して再開されると、コピー元のストレージ装置１０は、このバッファセット管理テーブル１０３を参照することで、最後に実行していたバッファセットのコピーを再度行なうことができる。

セッション管理テーブル１０４は、ストレージ装置１０とストレージ装置２０との間のコピーセッションの状態を管理するテーブルであり、コピーセッション毎に、“Copying（整合性なし）”もしくは“Equivalent（整合性あり）”が設定される。なお、このセッション管理テーブル１０４と同様の構成を備えるセッション管理テーブル２０４がストレージ装置２０にも格納されている。

（ｂ）ストレージ装置２０
ストレージ装置２０において、ＣＭ５２１は、受信側コピー処理部２１，受信側ネゴシエーション処理部２３，受信側デグレード処理部２４，受信側ホルト処理部２５，受信側アップグレード処理部２６及びテーブル管理部２７として機能する。又、ＣＭ５２１には、受信バッファＩＤ管理テーブル２０１，バッファ管理テーブル２０２，バッファセット管理テーブル２０３及びセッション管理テーブル２０４が備えられる。なお、図２に示す例においては、ストレージ装置２０に備えられた複数のＣＭ５２１のうち、マスタとして機能する一のＣＭ５２１のみを示し、スレーブとして機能する他のＣＭ５２１の図示を省略している。すなわち、受信側コピー処理部２１，受信側ネゴシエーション処理部２３，受信側デグレード処理部２４，受信側ホルト処理部２５，受信側アップグレード処理部２６及びテーブル管理部２７として機能は、マスタＣＭ５２１に備えられる。

受信側コピー処理部２１は、ストレージ装置１０からＲＥＣコンシステンシ転送によりストレージ装置２０に転送されたデータのコピーを受信する処理を行なう。受信側コピー処理部２１は、ストレージ装置１０とストレージ装置２０との間のデータ転送を制御する。
受信側コピー処理部２１は、受信処理部２１１，展開処理部２１２及びバッファ解放処理部２１３を備える。

受信処理部２１１は、ストレージ装置１０から送信されたバッファセットのデータを受信する。又、受信処理部２１１は、受信したデータに付された受信バッファＩＤを参照して、受信したバッファセットを成す各データを、それぞれ対応するローカルバッファ４０のバッファ領域に格納する。又、受信処理部２１１は、受信した各データのコピーをミラーバッファ４１にも転送し、それぞれ対応するミラーバッファ４１のバッファ領域に格納する。

展開処理部２１２は、受信処理部２１１がストレージ装置１０から送信されるバッファセットの全てのデータ受信を完了すると、ＲＥＣバッファ（ローカルバッファ４０，ミラーバッファ４１）内のバッファセットのデータをまとめてコピー先のディスク装置（記憶媒体）２３１内へ展開する。展開処理部２１２は、ストレージ装置１０からのデータをバッファセットの単位で展開する。

バッファ解放処理部２１３は、展開処理部２１２がデータの展開を完了すると、データの格納に用いたローカルバッファ４０及びミラーバッファ４１を解放する。ここで、バッファの解放とは、新たにデータを格納可能な状態にすることをいう。又、バッファ解放処理部２１３は、解放する（受信可能となる）バッファ領域の受信バッファＩＤをストレージ装置１０に通知する。

図８は実施形態の一例としてのストレージシステム１におけるバッファ解放処理を例示する図であり、図５に例示した受信バッファＩＤ管理テーブル１０１，２０１に対応している。
この図８に示す例においては、ストレージ装置１０からストレージ装置２０に対して、ＣＭ＃０〜ＣＭ＃３のバッファＩＤ１００２，１１０２，１２０２及び１３０２からなるバッファセットのデータの展開が完了した状態を示す。又、バッファＩＤ１００３，１００４，１１０３，１１０４，１２０３，１２０４，１３０３及び１３０４のバッファセットのデータの転送も完了している。ただし、これらのバッファＩＤ１００３，１００４，１１０３，１１０４，１２０３，１２０４，１３０３及び１３０４の各バッファ領域は、バッファ解放処理部２１３により解放されていないので、これらのバッファＩＤは“割当”の状態である。又、これら以外のバッファ領域は“未割当”である。なお、この図８中においては、便宜上、ミラーバッファ４１等の図示を省略している。

展開処理部２１２がＩＤ１００２，１１０２，１２０２及び１３０２からなるバッファセットのデータの展開処理を完了すると、バッファ解放処理部２１３は、バッファ解放通知により、解放したバッファ領域のバッファＩＤ（受信バッファＩＤ）をストレージ装置１０に通知する。すなわち、本ストレージシステム１においては、バッファ解放処理部２１３は、解放したバッファ領域のバッファＩＤ（受信バッファＩＤ）の通知と解放通知とを１回の通信でストレージ装置１０に通知する。

具体的には、バッファ解放処理部２１３は、ストレージ装置１０に対してバッファセットを解放するように送信する解放通知に、受信バッファＩＤを載せて送信する。すなわち、従来手法の如く解放通知に対する応答を待って受信バッファＩＤを通知する代わりに、解放通知に対する応答を待つことなく、解放通知とともに受信バッファＩＤ（空きバッファ通知）を送信する。

バッファ解放処理部２１３は、ストレージ装置１０から、この空きバッファ通知に対する応答（空きバッファ通知応答）を受信すると、受信側バッファセット解放を行なう。
これにより、ストレージ装置２０からストレージ装置１０に対して、空きバッファ通知を短時間で送信することができるとともに、通信回数を低減させることができる。従って、転送効率を向上させ、ネットワーク５０を有効に用いることができる。

受信側ネゴシエーション処理部２３は、ストレージ装置２０におけるネゴシエーション処理を行なう。
受信側ネゴシエーション処理部２３は、ペアＣＭの少なくとも一方がアップグレードしていて使用可能な状態である場合にネゴシエーション処理を行ない、ペアＣＭの両方がデグレードしている場合には、ネゴシエーション処理を行なわない。

また、受信側ネゴシエーション処理部２３は、ネゴシエーション処理時において、バッファ管理テーブル２０２やバッファセット管理テーブル２０３の初期化を行なう。又、このネゴシエーション処理時において、受信側ネゴシエーション処理部２３は、ストレージ装置１０に対して空き受信バッファＩＤの通知を行なう。
なお、本ストレージシステム１におけるネゴシエーション時の処理は図１１を用いて後述する。

受信側デグレード処理部２４は、ストレージ装置２０において機器のデグレードを行なう。例えば、ストレージ装置２０において、いずれかのＣＭに異常が検知された場合に、受信側デグレード処理部２４は、そのＣＭをデグレードさせ使用不可な状態にする。なお、この受信側デグレード処理部２４によるデグレード手法も、送信側デグレード処理部１４と同様に既知の種々の手法を用いて行なうことができ、その詳細な説明は省略する。

受信側アップグレード処理部２６は、ストレージ装置２０において、受信側デグレード処理部２４によりデグレードされた機器を復旧（アップグレード）させて、使用可能な状態にする。例えば、いずれかのＣＭがデグレードした状態において、保守作業者がデグレードされたＣＭを交換等した場合には、受信側アップグレード処理部２６は、このＣＭをアップグレードさせる。

受信側アップグレード処理部２６は、例えば、遮断されていた対象機器への電力供給やデータパスを復旧させることでアップグレードを実施する。なお、この受信側アップグレード処理部２６によるアップグレード手法も、送信側アップグレード処理部１６と同様に既知の種々の手法を用いて行なうことができ、その詳細な説明は省略する。
受信側ホルト処理部２５は、ストレージ装置２０においてシステム内の処理を停止させるホルト状態が検出された場合の処理を行なう。受信側ホルト処理部２５は、ホルト状態が検出されると、ホルト要因がペアＣＭがデグレードしたことによるものであり、且つ、展開処理途中である場合に、セッション管理テーブル２０４におけるコピーセッションの状態（フェーズ）を“Equivalent（整合性あり）”から“Copying（整合性なし）”に変更する処理を行なう。又、受信側ホルト処理部２５は、バッファ管理テーブル２０２において、受信側バッファデータロスト状態に“ロスト状態である”旨の設定を行なう。

一方、ホルト要因がペアＣＭがデグレードしたことによるものではない場合や、展開処理途中ではない場合には、受信側ホルト処理部２５は、ホルト検出を抑止する（ホルト検出待ち合わせ）。例えば、ストレージ装置１０のバッファが枯渇することによりホルト状態が生じた場合には、受信側ホルト処理部２５は、ホルト状態が生じなかったものとする。

すなわち、受信側ホルト処理部２５は、ペアＣＭのうちいずれかが動作可能である場合には、ホルト状態の検出を待ち合わせる。又、受信側ホルト処理部２５は、ホルト要因がペアＣＭであった場合でも、展開処理途中に生じたものではない場合には、ホルト状態の検出を待ち合わせる。
テーブル管理部（転送継続処理部）２７は、受信バッファＩＤ管理テーブル２０１，バッファ管理テーブル２０２，バッファセット管理テーブル２０３及びセッション管理テーブル２０４を管理し、これらのテーブルの設定値の変更等を行なう。

また、テーブル管理部２７は、バッファ管理テーブル２０２の受信側バッファデータロスト状態を参照して、受信側バッファデータロスト状態に“ロスト状態”が設定されている場合には、以下の処理を行なう。
すなわち、セッション管理テーブル２０４におけるコピーセッションの状態（フェーズ）を“Copying（整合性なし）”から“Equivalent（整合性あり）”に書き換える。又、バッファ管理テーブル２０２における受信側バッファデータロスト状態を“ロスト状態である”から“ロスト状態ではない”に書き換える。これにより、ストレージ装置１０とストレージ装置２０との間の順序性保証データ転送が継続して実行されることになる。

バッファセット管理テーブル２０３は、各バッファセットに関する情報をテーブル状に管理する。
図９は実施形態の一例としてのバッファセット管理テーブル２０３を例示する図である。
バッファセット管理テーブル２０３には、バッファセット管理テーブル１０３と同様に、バッファセット毎、すなわち、バッファセットＩＤに対して、バッファセットリンクPrev及びバッファセットリンクNextが関連付けて登録されている。

また、バッファセット管理テーブル２０３は、バッファセットを構成する各バッファ領域の状態を管理している。
すなわち、バッファセットを構成する各バッファ領域のバッファＩＤ（送信バッファＩＤ，受信バッファＩＤ）に対して、バッファ受信状態，バッファセット管理テーブル受信状態及び受信可不可状態が関連付けて登録されている。バッファ受信状態及びバッファセット管理テーブル受信状態としては、“送信中”もしくは“送信済み”が設定される。又、受信可不可状態としては、“Mirror受信不可”，“Local受信不可”，“不可”及び“可”のいずれかが設定される。すなわち、ストレージ装置１０においてローカルバッファ４０における各バッファ領域や、ミラーバッファ４１におけるそのミラー領域が受信可能であるか否かを示す情報が設定される。

例えば、図３に示すストレージ装置１０において、ＣＭ＃１がデグレードすると、ＣＭ＃０はローカルバッファ４０側だけで受信して、ＣＭ＃１はローカルバッファ４０が使えずに、ＣＭ＃０のミラーバッファ４１側がＣＭ＃１のローカルバッファ４０の肩代わりで受信する状態になる。
このとき、受信バッファＩＤ“0x10xx”のバッファ領域は、“Mirror 受信不可”の状態となり、又、受信バッファＩＤ“0x11xx”のバッファ領域は、“Local 受信不可”の状態となる。なお、バッファＩＤ中の“x”は、変数（例えば、０〜３の整数）を示す。

ここで、ＣＭ＃０とＣＭ＃１との両方がデグレードとなると、受信バッファＩＤ“0x10xx”及び“0x11xx”の各バッファ領域は、いずれもLocal/Mirror 両方とも受信不可の状態、すなわち“不可”の状態になる。
バッファセット管理テーブル２０３は、例えば、データ受信時やデータ展開時、バッファセット解放時、等のタイミングで更新される。

（Ｂ）動作
実施形態の一例としてのストレージシステム１における初回ネゴシエーション処理を、図１１を参照しながら図１０に示すフローチャート（ステップＡ１〜Ａ９）に従って説明する。なお、図１１は実施形態の一例としてのストレージシステム１における初回ネゴシエーション直後の受信バッファＩＤ管理テーブル１０１，２０１を例示する図である。

ストレージ装置１０において、送信側ネゴシエーション処理部１３は、ネゴシエーションが行なわれたか否かを確認する（ステップＡ１）。既にネゴシエーションが行なわれている場合には（ステップＡ１のＮＯルート参照）、処理を終了する。
ネゴシエーションが未だ行なわれていない場合には（ステップＡ１のＹＥＳルート参照）、送信側ネゴシエーション処理部１３は、ストレージ装置２０の受信側ネゴシエーション処理部２３に対して通知（初期通知）を行なう（ステップＡ２）。

受信側ネゴシエーション処理部２３は、各ペアＣＭについて、その少なくとも一方のＣＭがアップグレードしているか否かを確認する（ステップＡ３）。ペアＣＭを構成する両方のＣＭがデグレードしている場合には（ステップＡ３のＮＯルート参照）、ステップＡ８に移行する。
ペアＣＭを構成する少なくとも一方のＣＭがアップグレードしている、すなわち正常に動作している場合には（ステップＡ３のＹＥＳルート参照）、受信側ネゴシエーション処理部２３は、バッファ管理テーブル２０２の初期化を行なう（ステップＡ４）。又、ここで、バッファ枯渇により生じたホルト処理において行なわれるネゴシエーションの場合には、受信側バッファデータロストの状態を忘れる処理を行なう。具体的には、テーブル管理部２７は、バッファ管理テーブル２０２における受信側バッファデータロスト状態を“ロスト状態ではない”に設定する。

受信側ネゴシエーション処理部２３は、バッファセット管理テーブル２０３の初期化を行なう（ステップＡ５）。更に、受信側ネゴシエーション処理部２３は、ストレージ装置１０に対して空き受信バッファＩＤの通知を行なう（ステップＡ６）。これにより、図１１に示すように、受信バッファＩＤ管理テーブル１０１，２０１において、各バッファＩＤに“未割当”が設定される。又、受信側ネゴシエーション処理部２３は、バッファ管理テーブル２０２のネゴシエーション状態に“ネゴシエーション処理済み”を設定する。

ストレージ装置１０においては、送信側ネゴシエーション処理部１３が、バッファ管理テーブル１０２及びバッファセット管理テーブル１０３の初期化を行なう（ステップＡ７）。
また、ここで、バッファ枯渇により生じたホルト処理において行なわれるネゴシエーションの場合には、受信側バッファデータロストの状態を忘れる処理を行なう。具体的には、テーブル管理部１７は、バッファ管理テーブル１０２における受信側バッファデータロスト状態を“ロスト状態ではない”に設定する。

そして、送信側ネゴシエーション処理部１３は、バッファ管理テーブル１０２のネゴシエーション状態に“ネゴシエーション処理済み”を設定する（ステップＡ８）。
また、セッション管理テーブル１０４において、コピーセッションの状態が “Copying” から “Equivalent” に遷移すると、ストレージ装置１０，２０間で順序性保証データ転送が再開可能となる。これにより、ストレージ装置１０，２０間で、図１２に示すＲＥＣコンシステンシ転送（順序性保証データ転送）が再開され（ステップＡ９）、処理を終了する。又、バッファ管理テーブル１０２，２０２のバッファ状態には“Active”が設定される。

このように、ネゴシエーション処理が完了し、バッファ管理テーブル１０２，２０２のネゴシエーション状態に“ネゴシエーション済み”が設定され、バッファ状態に“Active”が設定されると、ＲＥＣバッファ３０，４０，４１へのバッファリングが可能となる。すなわち、ストレージ装置１０において、ホスト２からＩ／Ｏ処理を受け付け可能な状態となる。

次に、実施形態の一例としてのストレージシステム１におけるＲＥＣコンシステンシ転送の処理を、図１２に示すフローチャート（ステップＢ１〜Ｂ１８）に従って説明する。
ホスト２からストレージ装置１０に対してライト処理が行なわれると、ストレージ装置１０において、Ｉ／Ｏ処理を受け付ける（ステップＢ１）。
ここで、ＲＥＣバッファ３０が枯渇状態であるか否かを確認し（ステップＢ２）、ＲＥＣバッファ３０が枯渇した状態であれば（ステップＢ２のＹＥＳルート参照）、ホルト処理を起動して（ステップＢ３）、処理を終了する。なお、ホルト処理については、図１５及び図１６を参照しながら後述する。

ＲＥＣバッファ３０が枯渇していない場合には（ステップＢ２のＮＯルート参照）、格納予約処理部１１１が、ホスト２から送信されたライトデータをバッファメモリに格納し、ＲＥＣバッファ３０に格納する準備を行なう（ステップＢ４）。
格納処理部１１２は、ＲＥＣバッファ３０へのデータの格納制御を行なう（ステップＢ５）。

例えば、ＲＥＣバッファ３０のバッファ領域へデータを格納してから所定期間を経過したり、アクティブな世代の領域のバッファ領域の空き容量が枯渇すると、バッファ切替処理部１２１は、ＲＥＣバッファ３０のアクティブな世代を、次世代のバッファ領域に切り替える（ステップＢ６）。
その後、割当処理部１２２が、受信バッファＩＤ管理テーブル１０１を参照して、受信側バッファＩＤを割り当て、転送処理部１２３が、バッファセットのデータを、割当処理部１２２によって割り当てられたバッファＩＤとともにストレージ装置２０に送信する（ステップＢ７）。転送処理部１２３はバッファ状態に“Active”が設定されていれば、データ転送を実行する。

ストレージ装置２０においては、受信処理部２１１が、ストレージ装置１０から送信されたバッファセットのデータを受信し（ステップＢ８）、ローカルバッファ４０及びミラーバッファ４１に格納する。展開処理部２１２は、ローカルバッファ４０もしくはミラーバッファ４１のデータをディスク装置２３１内へ展開する（ステップＢ９）。
テーブル管理部２７は、バッファ管理テーブル２０２の受信側バッファデータロスト状態を参照して、ロスト状態であるか否かを確認する（ステップＢ１０）。受信側バッファデータロスト状態に“ロスト状態”が設定されている場合には（ステップＢ１０のＹＥＳルート参照）、テーブル管理部２７は、セッション管理テーブル２０４におけるコピーセッションの状態（フェーズ）を“Copying（整合性なし）”から“Equivalent（整合性あり）”に書き換える（ステップＢ１１）。コピーセッションの状態が “Copying” から “Equivalent” に遷移すると、ストレージ装置１０，２０間で順序性保証データ転送が再開可能となる。

また、テーブル管理部２７は、バッファ管理テーブル２０２における受信側バッファデータロスト状態を“ロスト状態ではない”に設定する（ステップＢ１２）。すなわち、受信側バッファデータロストの状態を忘れる。そして、バッファ解放処理部２１３は、データの格納に用いたローカルバッファ４０及びミラーバッファ４１を解放する（ステップＢ１３）。又、バッファ解放処理部２１３は、バッファ解放通知により、解放したバッファ領域のバッファＩＤ（受信バッファＩＤ）をストレージ装置１０に通知する。一方、受信側バッファデータロスト状態に“ロスト状態”が設定されていない場合には（ステップＢ１０のＮＯルート参照）、ステップＢ１１，Ｂ１２をスキップしてステップＢ１３に移行する。

ストレージ装置１０においても、テーブル管理部１７は、バッファ管理テーブル１０２の受信側バッファデータロスト状態を参照して、ロスト状態であるか否かを確認する（ステップＢ１４）。受信側バッファデータロスト状態に“ロスト状態”が設定されている場合には（ステップＢ１４のＹＥＳルート参照）、テーブル管理部２７は、セッション管理テーブル１０４におけるコピーセッションの状態（フェーズ）を“Copying（整合性なし）”から“Equivalent（整合性あり）”に書き換える（ステップＢ１５）。ストレージ装置１０とストレージ装置２０との両方においてコピーセッションの状態が“Copying” から “Equivalent” に遷移すると、ストレージ装置１０，２０間で順序性保証データ転送が再開される。

また、テーブル管理部１７は、バッファ管理テーブル１０２における受信側バッファデータロスト状態を“ロスト状態ではない”に設定する（ステップＢ１６）。すなわち、受信側バッファデータロストの状態を忘れる。
そして、割当処理部１２２が、受信バッファＩＤ管理テーブル１０１を参照して、空き受信バッファＩＤの割当処理を行なう（ステップＢ１７）。又、受信側バッファデータロスト状態に“ロスト状態”が設定されていない場合には（ステップＢ１４のＮＯルート参照）、ステップＢ１５，Ｂ１６をスキップしてステップＢ１７に移行する。その後、バッファ解放処理を行ない（ステップＢ１８）、処理を終了する。

なお、この図１２に示すフローチャートにおいては、ステップＢ１においてＩＯ処理が行なわれた以降にステップＢ７の転送処理が実行されているが、ＩＯ処理と転送処理とは同期して行なわれるものではない。すなわち、ＲＥＣバッファ４０，４１が受信可能な状態となれば、ステップＢ７以降の処理が実行される。
次に、実施形態の一例としてのストレージシステム１における受信側デグレード処理部２４によるデグレード処理を、図１４を参照しながら、図１３に示すフローチャート（ステップＣ１〜Ｃ４）に従って説明する。なお、図１４は実施形態の一例としてのストレージシステム１においてストレージ装置２０のＣＭをデグレードさせる例を示す図である。この図１４に示す例においては、ストレージ装置２０のＣＭ＃０に異常が検知されデグレードさせる。

この図１４に示すように、ストレージ装置２０のＣＭ＃０でリカバリ不可な異常が検知されると、受信側デグレード処理部２４は、デグレード対象であるＣＭ＃０のローカルバッファ４０を受信不可に設定する（ステップＣ１）。
また、受信側デグレード処理部２４は、デグレード対象であるＣＭ＃０のミラーバッファ４１をミラーリング不可に設定する（ステップＣ２）。すなわち、ＣＭ＃１のローカルバッファ４０のデータのコピーの格納を不可にして、ＣＭ＃０をデグレードさせる。なお、これらのステップＣ１，Ｃ２の順序は逆であってもよく、又、同時に行なってもよい。

その後、受信側デグレード処理部２４は、デグレードさせたＣＭ＃０とペアＣＭを構成するＣＭ＃１もデグレードしているか否か、すなわち、ペアＣＭを構成するＣＭ＃０，ＣＭ＃１の両方がデグレードしているかを確認する（ステップＣ３）。これらのペアＣＭの両方がデグレードしている場合には（ステップＣ３のＹＥＳルート参照）、ステップＣ４において、受信側ホルト処理部２５が、ホルト処理を行なって（ステップＣ４）、処理を終了する。なお、ホルト処理については、図１５及び図１６を参照しながら後述する。

また、ペアＣＭ（ＣＭ＃０，ＣＭ＃１）の少なくとも一方のＣＭがデグレードしていない場合には（ステップＣ３のＮＯルート参照）、そのまま処理を終了する。
次に、実施形態の一例としてのストレージシステム１におけるホルト処理を、図１６を参照しながら、図１５に示すフローチャート（ステップＤ１〜Ｄ１２）に従って説明する。なお、図１６は実施形態の一例としてのストレージシステム１のストレージ装置２０においてホルト状態が検出される状態を示す図である。この図１６に示す例においては、ストレージ装置２０においてペアＣＭを構成するＣＭ＃０及びＣＭ＃１の両方がデグレードしている。

前述の如く、本ストレージシステム１においては、ペアＣＭを構成する２つのＣＭが同時にデグレードした場合には、エラーサスペンド状態にはせずに、ホルト状態へ切り替える。
ホルト状態が検出されると、ストレージ装置２０において、受信側ホルト処理部２５は、ホルト要因がペアＣＭを構成するＣＭがともにデグレードしたことであるか否かを確認する（ステップＤ１）。ホルト要因がペアデグレードである場合には（ステップＤ１のＹＥＳルート参照）、次に、ストレージ装置２０において受信したデータの展開中であったか否かを確認する（ステップＤ２）。

展開中であった場合には（ステップＤ２のＹＥＳルート参照）、ストレージ装置２０においてＲＥＣバッファ４０，４１に格納されたバッファは、ストレージ装置１０とストレージ装置２０との間で整合性がない状態であると考えられる。受信側ホルト処理部２５は、テーブル管理部２７を介して、セッション管理テーブル２０４におけるコピーセッションの状態（フェーズ）を“Equivalent（整合性あり）”から“Copying（整合性なし）”に変更する。（ステップＤ３）。これにより、ストレージ装置２０においてＲＥＣバッファ４０，４１に格納されたデータは破棄されることとなる。

そして、受信側ホルト処理部２５は、ＲＥＣバッファ４０，４１のデータを破棄し（ステップＤ４）、バッファ管理テーブル２０２において、受信側バッファデータロスト状態に“ロスト状態である”旨の設定を行なう。すなわち、受信バッファデータロスト状態を覚える（ステップＤ５）。そして、受信側ホルト処理部２５はホルト検出の待ち合わせを行なう（ステップＤ６）。なお、このホルト検出の待ち合わせは既知の手法であり、その詳細な説明は省略する。

また、ホルト要因がペアＣＭを構成するＣＭがともにデグレードしたことではない場合（ステップＤ１のＮＯルート参照）や、展開中でなかった場合には（ステップＤ２のＮＯルート参照）、ステップＤ３〜Ｄ５の処理をスキップしてステップＤ６に移行する。
一方、ストレージ装置１０においては、送信側ホルト処理部１５が、ストレージ装置２０におけるホルト状態を検出し（ステップＤ７）、ストレージ装置２０へのデータ転送を中止させるとともに、バッファの状態を“Buffering”とする（ステップＤ８）。これにより、転送処理部１２３によるストレージ装置１０へのデータ転送は行なわれないが、ＲＥＣバッファ３０へのデータの格納（バッファリング）は行なわれることとなる。

送信側ホルト処理部１５は、テーブル管理部１７を介して、バッファ管理テーブル１０２において、受信側バッファデータロスト状態に“ロスト状態である”旨の設定を行なう。すなわち、受信バッファデータロスト状態を覚える（ステップＤ９）。
また、送信側ホルト処理部１５（テーブル管理部１７）は、セッション管理テーブル１０４におけるコピーセッションの状態（フェーズ）を“Equivalent（整合性あり）”の状態から“Copying（整合性なし）”に変更する（ステップＤ１０）。

その後、送信側コピー処理部１２による再送信の準備を行ない（ステップＤ１１）、送信側ネゴシエーション処理部１３によるネゴシエーション処理を行なう（ステップＤ１２）。
このネゴシエーション処理において、図１０のステップＡ３〜Ａ９と同様の処理が行なわれる。すなわち、受信側ネゴシエーション処理部２３が、各ペアＣＭについて、その少なくとも一方のＣＭがアップグレードしているか否かを確認する。そして、ペアＣＭを構成する少なくとも一方のＣＭがアップグレードしている場合には、ネゴシエーションが行なわれる。これにより、バッファ管理テーブル１０２，２０２のネゴシエーション状態に“ネゴシエーション済み”が設定され、バッファ状態に“Active”が設定されると、ＲＥＣバッファ３０，４０，４１への格納処理やバッファ切替処理が可能となり、ストレージ装置１０からストレージ装置２０へデータ転送可能な状態となる。

ストレージ装置１０からストレージ装置２０へデータ転送可能な状態になると、図１２のステップＢ７以降の処理が実行される。すなわち、ストレージ装置１０からストレージ装置２０へデータ転送が再開される。
コピー元のストレージ装置１０は、バッファセット管理テーブル１０３を参照し、最後に実行していたバッファセットのコピーから再開する。

これにより、ストレージ装置１０のＲＥＣバッファ３０とストレージ装置２０のＲＥＣバッファ４０，４１との間の順序性が保証され、ＲＥＣセッションを張り直し初期コピーを行なうことなく、順序性保証データ転送を再開することができる。
次に、実施形態の一例としてのストレージシステム１のストレージ装置１０においてＲＥＣバッファ３０の枯渇が生じた場合の処理を、図１７に示すフローチャート（ステップＦ１〜Ｆ５）に従って説明する。

ストレージ装置１０においてＲＥＣバッファ３０の枯渇が検出されると、テーブル管理部１７は、バッファ管理テーブル１０２におけるバッファ状態に“Halt”を設定する（ステップＦ１）。
また、テーブル管理部１７は、セッション管理テーブル１０４において、“Equivalent”となっているコピーセッションを“Copying”に変更する（ステップＦ２）。

ホスト２等によりボリュームへの変更が行なわれると、その変更箇所がコピービットマップに記憶される（ステップＦ３）。 その後、送信側コピー処理部１２による再送信の準備を行ない（ステップＦ４）、送信側ネゴシエーション処理部１３によるネゴシエーション処理を行ない（ステップＦ５）、処理を終了する。
次に、実施形態の一例としてのストレージシステム１のストレージ装置１０における差分ビットマップコピー処理について、図１８に示すフローチャート（ステップＧ１〜Ｇ７）に従って説明する。なお、ストレージ装置１０において、差分ビットマップコピーのコピースケジュール（差分ビットマップコピースケジュール）は定期的に起動される。

ストレージ装置１０においては、先ず、送信側ネゴシエーション処理部１３によるネゴシエーションが行なわれているか否かを確認する（ステップＧ１）。ネゴシエーションが未だ行なわれていない場合には（ステップＧ１のＮＯルート参照）、処理を終了する。
ネゴシエーションが行なわれている場合には（ステップＧ１のＹＥＳルート参照）、バッファ管理テーブル１０２における受信側バッファデータロスト状態を参照して、“ロスト状態ではない”であるか否かを確認する（ステップＧ２）。

受信側バッファデータロスト状態に“ロスト状態ではない” が設定されている場合には（ステップＧ２のＹＥＳルート参照）、送信側コピー処理部１２が、コピービットマップに記憶されている更新箇所を差分コピースケジュールに反映させる（ステップＧ３）。
送信側コピー処理部１２は、差分コピースケジュールに従って、差分ビットマップコピーを行なう（ステップＧ４）。

送信側コピー処理部１２は、セッションのコピービットマップに記憶されている全ての差分コピーが完了したか否かを確認する（ステップＧ５）。 差分コピー（差分ビットマップコピー）が完了していない場合には（ステップＧ５のＮＯルート参照）、差分コピーが完了するまでステップＧ５を繰り返し行なう。
差分コピー（差分ビットマップコピー）が完了した場合には（ステップＧ５のＹＥＳルート参照）、テーブル管理部１７は、セッション管理テーブル１０４におけるコピーセッションの状態（フェーズ）を“Copying”から“Equivalent”に書き換える（ステップＧ６）。

これにより、ストレージ装置１０，２０間で順序性保証データ転送が再開可能となり、ストレージ装置１０，２０間で、図１２に示すＲＥＣコンシステンシ転送（順序性保証データ転送）が再開され（ステップＧ７）、処理を終了する。
また、受信側バッファデータロスト状態に“ロスト状態” が設定されている場合も（ステップＧ２のＮＯルート参照）、処理を終了する。

このように、ストレージ装置１０においてＲＥＣバッファ３０の枯渇によるホルト状態となった場合であっても、差分ビットマップコピーを行なうことにより、ストレージ装置１０，２０間で、ＲＥＣコンシステンシ転送を再開することができる。
次に、実施形態の一例としてのストレージシステム１における受信側アップグレード処理部２６によるアップグレード処理を、図２０を参照しながら、図１９に示すフローチャート（ステップＥ１〜Ｅ２）に従って説明する。なお、図２０は実施形態の一例としてのストレージシステム１のストレージ装置２０においてアップグレードされた状態を示す図である。この図２０に示す例においては、ストレージ装置２０においてデグレードしていたＣＭ＃０がアップグレードされている。

受信側アップグレード処理部２６は、アップグレードの対象のＣＭ（例えば、ＣＭ＃０）のローカルバッファ４０を受信可能に設定する（ステップＥ１）。
また、受信側アップグレード処理部２５は、アップグレード対象であるＣＭ＃０のミラーバッファ４１をミラーリング可に設定する（ステップＥ２）。すなわち、ＣＭ＃１のローカルバッファ４０のデータのコピーの格納を可能な状態にして、ＣＭ＃０をアップグレードさせる。なお、これらのステップＥ１，Ｅ２の順序は逆であってもよく、又、同時に行なってもよい。

ペアデグレードの状態のＣＭの少なくとも１つのＣＭをアップグレードさせることにより、ペアデグレードが解消される。これにより、送信側ネゴシエーション処理部１３及び受信側ネゴシエーション処理部２３によるネゴシエーションが実行される（図１０のステップＡ３のＹＥＳルート参照）。ネゴシエーションが実行されることにより、前述の如く、バッファ状態に“Active”が設定され、ストレージ装置１０からストレージ装置２０へデータ転送が再開される。

（Ｃ）効果
このように、実施形態の一例としてのストレージシステム１によれば、ストレージ装置１０からストレージ装置２０へのＲＥＣコンシステンシ・モードコピー（順序性保証データ転送）時において、コピー先のストレージ装置２０でＲＥＣバッファ４０，４１からのデータ展開時にペアデグレードが発生した場合には、エラーサスペンド状態にはしないで、ホルト状態へ切り替える。

このホルト状態において、ストレージ装置２０において受信したデータの展開中であった場合に、受信側ホルト処理部２５及び送信側ホルト処理部１５が、セッション管理テーブル２０４，１０４におけるコピーセッションの状態（フェーズ）を“Equivalent（整合性あり）”から“Copying（整合性なし）”に変更する。更に、受信側ホルト処理部２５及び送信側ホルト処理部１５が、バッファ管理テーブル２０２，１０２において、受信側バッファデータロスト状態に“ロスト状態である”旨の設定を行なう。

その後、ストレージ装置１０，２０間でデータ転送が再開された場合に、受信側バッファデータロスト状態に“ロスト状態”が設定されている場合には、テーブル管理部２７，１７が、セッション管理テーブル２０４，１０４におけるコピーセッションの状態（フェーズ）を“Copying（整合性なし）”から“Equivalent（整合性あり）”に書き換える。これにより、ＲＥＣセッションを継続することができ、更新差分のコピーを実施するだけで順序性保障されたＲＥＣ（ＲＥＣコンシステンシ）を再開することができる。従って、ストレージ装置２０においてペアデグレードが発生した場合においても、ＲＥＣセッションを張り直し初期コピーを最初からやり直す必要がなく、短時間でデータ転送を再開することができる。

ペアデグレードの状態において、ペアＣＭを構成しているＣＭのうち少なくとも一方がアップグレードされると、送信側ネゴシエーション処理部１３及び受信側ネゴシエーション処理部２３によるネゴシエーション処理が開始される（図１０のステップＡ３のＹＥＳルート参照）。ネゴシエーションが実行されることにより、前述の如く、バッファ状態に“Active”が設定され、ストレージ装置１０からストレージ装置２０へデータ転送が再開される。すなわち、ストレージ装置１０とストレージ装置２０との間でＲＥＣセッションを張りなおす必要がなく、ストレージ装置１０からストレージ装置２０へのＲＥＣセッションを再開される。ストレージ装置１０とストレージ装置２０とが等価となった時点で順序性保証されたＲＥＣコンシステンシ動作が再開される。このように、ＲＥＣセッションを張り直し初期コピーを行なうことなく、データ転送を再開させることができる。

また、ストレージ装置２０において、展開処理部２１２がバッファセットのデータの展開処理を完了すると、バッファ解放処理部２１３は、バッファ解放通知により受信バッファＩＤをストレージ装置１０に通知する。すなわち、解放したバッファ領域の受信バッファＩＤの通知と解放通知とを１回の通信でストレージ装置１０に通知する。これにより、ストレージ装置２０からストレージ装置１０に対して、空きバッファ通知を短時間で送信することができるとともに、通信回数を低減させることができる。従って、転送効率を向上させ、ネットワーク５０を有効に用いることができる。

ストレージ装置１０，２０間の順序性保証データ転送途中でストレージ装置２０においてペアデグレードが生じてコピーセッションが停止された場合には、コピーセッションの状態が“Copying” から “Equivalent” に遷移して再開されると、コピー元のストレージ装置１０は、このバッファセット管理テーブル１０３を参照し、最後に実行していたバッファセットのコピーを再度行なう。

これにより、ストレージ装置１０のＲＥＣバッファ３０とストレージ装置２０のＲＥＣバッファ４０，４１との間の順序性が保証され、ＲＥＣセッションを張り直し初期コピーを行なうことなく、順序性保証データ転送を再開することができる。
また、ストレージ装置１０，２０間の順序性保証データ転送途中でストレージ装置２０においてペアデグレードが生じると、受信側ホルト処理部２５（テーブル管理部２７）は、セッション管理テーブル２０４におけるコピーセッションの状態（フェーズ）を“Equivalent（整合性あり）”から“Copying（整合性なし）”に変更する。これにより、コピー元であるストレージ装置１０において何らかの障害が生じてバッファセット管理テーブル１０３のデータが損傷した場合にも、ストレージ装置１０，２０間でＲＥＣバッファ３０，４０，４１のデータに整合性が無いことを知ることができ、信頼性を向上させることができる。

（Ｄ）その他
開示の技術は上述した実施形態に限定されるものではなく、本実施形態の趣旨を逸脱しない範囲で種々変形して実施することができる。本実施形態の各構成及び各処理は、必要に応じて取捨選択することができ、あるいは適宜組み合わせてもよい。
例えば、上述した実施形態においては、ストレージ装置１０のディスク装置１３１のデータのコピーをストレージ装置２０にデータ転送して、ストレージ装置２０のディスク装置２３１に格納する例について説明しているが、これに限定されるものではない。ストレージ装置２０のディスク装置２３１のデータのコピーをストレージ装置１０にデータ転送して、ストレージ装置１０のディスク装置１３１に格納してもよい。すなわち、ストレージ装置２０がストレージ装置１０の各機能を備えるとともに、ストレージ装置１０がストレージ装置２０の各機能を備えてもよい。

また、上述した開示により本実施形態を当業者によって実施・製造することが可能である。

１ ストレージシステム
２，３ ホスト
１０，２０ ストレージ装置
１１ ＩＯ処理部
１２ 送信側コピー処理部
１３ 送信側ネゴシエーション処理部
１４ 送信側デグレード処理部
１５ 送信側ホルト処理部
１６ 送信側アップグレード処理部
１７，２７ テーブル管理部（バッファ管理部，セッション管理部）
２１ 受信側コピー処理部
２３ 受信側ネゴシエーション処理部
２４ 受信側デグレード処理部
２５ 受信側ホルト処理部
２６ 受信側アップグレード処理部
３０，３０−０〜３０−３ ＲＥＣバッファ
４０，４０−０〜４０−３ ローカルバッファ（ＲＥＣバッファ）
４１，４１−０〜４１−３ ミラーバッファ（ＲＥＣバッファ）
５０ リモート回線
１０１，２０１ 受信バッファＩＤ管理テーブル
１０２，２０２ バッファ管理テーブル
１０３，２０３ バッファセット管理テーブル
１０４，２０４ セッション管理テーブル
１１０，２１０ ＣＰＵ
１１１ 格納予約処理部
１１２ 格納処理部
１２１ バッファ切替処理部
１２２ 割当処理部
１２３ 転送処理部
２１１ 受信処理部
２１２ 展開処理部
２１３ バッファ解放処理部
１２４，２２４ ＣＡ
１２５，２２５ ＲＡ
１２６，２２６ ＤＡ
１２７，２２７ メモリ
１３０，２３０ ディスクエンクロージャ
１３１，２３１ ディスク装置
５１１，５１１−０〜５１１−３，５２１，５２１−０〜５２１−３ ＣＭ（ストレージ制御装置）

Claims (9)

1. 第１の記憶装置からネットワークを介して接続された第２の記憶装置に対して順序性保証データ転送を行なうストレージシステムにおいて、
   前記第２の記憶装置における冗長化された２以上の制御装置にそれぞれ設けられ、データを冗長化して記憶する冗長化された２以上の受信バッファと、
   前記第１の記憶装置と前記第２の記憶装置との間で順序性保証データのコピー状態の整合性があるか否かを示すコピーセッションの状態を管理するセッション管理部と、
   順序性保証データが前記冗長化された２以上の受信バッファのいずれからも喪失したことを示すバッファデータロスト状態を管理するバッファ管理部と、を備え、
   前記第２の記憶装置が前記ストレージシステムの処理を停止させた要因が、前記第２の記憶装置における記憶媒体へのデータの展開処理中に発生した、前記冗長化された２以上の制御装置の多重故障である場合に、前記セッション管理部は前記コピーセッションの状態に整合性なしを設定し、前記バッファ管理部は前記バッファデータロスト状態をロスト状態であると設定し、
   前記第１の記憶装置と前記第２の記憶装置との間でデータ転送処理が再開された場合に、前記バッファ管理部により前記バッファデータロスト状態が前記ロスト状態であると設定されていると、前記セッション管理部は前記コピーセッションの状態に整合性ありを設定し、前記バッファ管理部は前記バッファデータロスト状態をロスト状態ではないと設定する
   ことを特徴とする、ストレージシステム。
2. 前記バッファ管理部は、前記第２の記憶装置における前記ストレージシステムの処理停止中において、前記冗長化された２以上の制御装置のうち少なくとも一の制御装置が有効である場合に、当該制御装置の受信バッファのバッファ状態を有効状態に設定することを特徴とする、請求項１記載のストレージシステム。
3. 前記第２の記憶装置は、展開が完了した時点のバッファ解放通知で今回解放する受信可能な受信バッファ識別情報を前記第１の記憶装置へ通知することを特徴とする、請求項１又は２記載のストレージシステム。
4. 第１の記憶装置からネットワークを介して接続された第２の記憶装置に対して順序性保証データ転送を行なうストレージシステムにおいて、前記第１又は第２の記憶装置に備えられる制御装置であって、
   前記第２の記憶装置における冗長化された２以上の受信バッファと、
   前記第１の記憶装置と前記第２の記憶装置との間で順序性保証データのコピー状態の整合性があるか否かを示すコピーセッションの状態を管理するセッション管理部と、
   順序性保証データが前記冗長化された２以上の受信バッファのいずれからも喪失したことを示すバッファデータロスト状態を管理するバッファ管理部と、を備え、
   前記第２の記憶装置が前記ストレージシステムの処理を停止させた要因が、前記第２の記憶装置における記憶媒体へのデータの展開処理中に発生した、前記冗長化された２以上の制御装置の多重故障である場合に、前記セッション管理部は前記コピーセッションの状態に整合性なしを設定し、前記バッファ管理部は前記バッファデータロスト状態をロスト状態であると設定し、
   前記第１の記憶装置と前記第２の記憶装置との間でデータ転送処理が再開された場合に、前記バッファ管理部により前記バッファデータロスト状態が前記ロスト状態であると設定されていると、前記セッション管理部は前記コピーセッションの状態に整合性ありを設定し、前記バッファ管理部は前記バッファデータロスト状態をロスト状態ではないと設定する
   ことを特徴とする、ストレージ制御装置。
5. 前記バッファ管理部は、前記第２の記憶装置における前記ストレージシステムの処理停止中において、前記冗長化された２以上の制御装置のうち少なくとも一の制御装置が有効である場合に、当該制御装置のバッファのバッファ状態を有効状態に設定することを特徴とする、請求項４記載のストレージ制御装置。
6. 前記第２の記憶装置は、展開が完了した時点のバッファ解放通知で今回解放する受信可能な受信バッファ識別情報を前記第１の記憶装置へ通知することを特徴とする、請求項４又は５記載のストレージ制御装置。
7. 第１の記憶装置からネットワークを介して接続された第２の記憶装置に対して順序性保証データ転送を行なうストレージシステムにおける順序性保証データ転送方法であって、
   冗長化された２以上の受信バッファは、前記第２の記憶装置における冗長化された２以上の制御装置にそれぞれ設けられ、データを冗長化して記憶し、
   セッション管理部は、前記第１の記憶装置と前記第２の記憶装置との間で順序性保証データのコピー状態の整合性があるか否かを示すコピーセッションの状態を管理し、
   バッファ管理部は、順序性保証データが前記第２の記憶装置において前記冗長化された２以上の受信バッファのいずれからも喪失したことを示すバッファデータロスト状態を管理し、
   前記第２の記憶装置が前記ストレージシステムの処理を停止させた要因が、前記第２の記憶装置における記憶媒体へのデータの展開処理中に発生した、前記冗長化された２以上の制御装置の多重故障である場合に、前記セッション管理部は前記コピーセッションの状態に整合性なしを設定し、前記バッファ管理部は前記バッファデータロスト状態をロスト状態であると設定し、
   前記第１の記憶装置と前記第２の記憶装置との間でデータ転送処理が再開された場合に、前記バッファデータロスト状態が前記ロスト状態であると設定されていると、前記セッション管理部は前記コピーセッションの状態に整合性ありを設定し、前記バッファ管理部は前記バッファデータロスト状態をロスト状態ではないと設定する
   ことを特徴とする、データ転送方法。
8. 前記バッファ管理部は、前記第２の記憶装置における前記ストレージシステムの処理停止中において、前記冗長化された２以上の制御装置のうち少なくとも一の制御装置が有効である場合に、当該制御装置のバッファのバッファ状態を有効状態に設定することを特徴とする、請求項７記載のデータ転送方法。
9. 前記第２の記憶装置は、展開が完了した時点のバッファ解放通知で今回解放する受信可能な受信バッファ識別情報を前記第１の記憶装置へ通知することを特徴とする、請求項７又は８記載のデータ転送方法。

Images