JP2011164800A - ストレージシステム及びストレージ制御方法 - Google Patents

Abstract

【課題】コピーデータの一貫性の保証とともに、その確認を容易化する。
【解決手段】コピー元筐体４からコピー先筐体６にデータをコピーするストレージシステム２であって、記憶領域生成部（制御部１２、２２、中央制御部）を備える。この記憶領域生成部は、複数に分割されたデータをストレージに格納する際の前記データのグループ化に基づき、ステータス情報を格納するステータス情報記憶領域を前記ストレージ（コピー元筐体４及びコピー先筐体６）側の記憶部１４、２４に生成させる。そして、前記記憶部に生成させた前記ステータス情報記憶領域には、グループ毎の前記ステータス情報が格納される。
【選択図】図１

Description

本発明は、複数のボリューム等にデータを分割して格納するストレージ装置間のデータのコピー制御に関し、例えば、コピーデータをグループ化してストレージ側で管理するストレージシステム及びストレージ制御方法に関する。

ストレージシステムにあっては、異なるストレージ装置筐体間のデータ転送機能として、ボリューム全体又は一部のデータをコピー元装置からコピー先装置にコピーするリモート等価コピー機能（ＲＥＣ：Remote Equivalent Copy）がある。このＲＥＣ機能ではホストから開始コマンドを受け、コピー元装置からコピー先装置へ指定範囲のデータを転送し、その形態はデータの指定範囲の先頭から末尾までを順に転送する。これは初期コピーと称される。そして、このＲＥＣ機能では、初期コピーが完了した領域に書き込まれたデータをコピー先装置に転送することで、コピー元装置とコピー先装置のデータが等価状態に保たれる。

このようなＲＥＣ機能を備えると、ホストを介さずにストレージ装置が直接にデータ転送を行うことができる。従って、ホストのＣＰＵ（Central Processing Unit ）はデータ転送から開放されるので、ホストに対する負荷が軽減される。

このようなＲＥＣ機能に関し、データ内の一貫性を保持するグループを定義すること（特許文献１）や、リモートコピーにおいて、データの時間順序性を保証すること（特許文献２）が知られている。

特開２００２−１８９５７０公報 特開２００８−１８１２８８公報

ところで、ストレージ装置がホストを介さずに直接にデータ転送を行っても、グループ内のデータに一貫性があるかはホスト側で厳重に監視する必要があり、その確認処理がホスト側に課されている。データの一貫性が保証されなければ、データ処理の信頼性が損なわれるからである。

そこで、本開示のストレージシステム及びストレージ制御方法の目的は、コピーデータの一貫性の保証とともに、その確認を容易化することにある。

上記目的を達成するため、本開示のストレージシステムは、コピー元筐体からコピー先筐体にデータをコピーするストレージシステムであって、記憶領域生成部を備える。この記憶領域生成部は、複数に分割されたデータをストレージに格納する際の前記データのグループ化に基づき、ステータス情報を格納するステータス情報記憶領域を前記ストレージ側の記憶部に生成させる。そして、前記記憶部に生成させた前記ステータス情報記憶領域には、グループ毎の前記ステータス情報が格納される。

上記目的を達成するため、本開示のストレージ制御方法は、コピー元筐体からコピー先筐体にデータをコピーするストレージ制御方法であって、記憶領域生成ステップと、ステータス情報格納ステップとを含む。前記記憶領域生成ステップでは、複数に分割されたデータをストレージに格納する際の前記データのグループ化に基づき、ステータス情報を格納するステータス情報記憶領域を前記ストレージ側の記憶部に生成させる。また、前記ステータス情報格納ステップでは、前記記憶部に生成させた前記ステータス情報記憶領域にグループ毎の前記ステータス情報を格納する。

本開示のストレージシステム又はストレージ制御方法によれば、次のような効果が得られる。

(1) ボリュームをストレージ側でグループ管理するシステムを構築できる。

(2) ストレージ間の同期型バックアップにおいて、ストレージ側で複数ボリュームをグループ化し、データの一貫性を保障することができる。

(3) ストレージ側でグループのデータ一貫性を管理することができ、ホスト側ではデータに一貫性があるかの従前の確認処理が不要であり、データの中身をチェックする等の手間が省ける。

(4) システムが被災しても、業務再開処理（ＲＴＯ）が軽減され、システムの復旧作業の迅速化に寄与する。

そして、本発明の他の目的、特徴及び利点は、添付図面及び各実施の形態を参照することにより、一層明確になるであろう。

第１の実施の形態に係るストレージシステムの構成例を示す図である。 第１の実施の形態に係るストレージ制御方法の一例を示すフローチャートである。 第２の実施の形態に係るストレージシステムの機能部の一例を示す図である。 第２の実施の形態に係るストレージシステムのハードウェア構成例を示す図である。 メモリの構成例を示す図である。 コピーセッション管理テーブルの構成例を示す図である。 ボリュームステータス及びその意味を示す図である。 一貫性ステータステーブルの構成例を示す図である。 コピーセッショングループの一貫性管理の状態遷移を示す図である。 グループステータス及びその意味を示す図である。 状態の変更処理の処理手順の一例を示すフローチャートである。 状態の確認処理の処理手順を示すフローチャートである。 グループステータス変更の処理手順を示すフローチャートである。 セッション作成／Resume時のグループステータス変更の処理手順を示すフローチャートである。 削除処理のグループステータス変更の処理手順を示すフローチャートである。 セッションSuspend 処理のグループステータス変更の処理手順を示すフローチャートである。 セッションEquivalent（初期コピー完了）時のグループステータス変更の処理手順を示すフローチャートである。 コピー元サイト及びコピー先サイト間のログ処理システムの一例を示す図である。 ログの記録処理の処理手順の一例を示すフローチャートである。 同期転送中状態を示す図である。 同期転送中断状態を示す図である。 バックアップデータの採取を示す図である。 データ不整合状態を示す図である。 コピー元筐体側の被災時のデータ不整合状態を示す図である。 データ不整合状態を示す図である。 セッション無し状態を示す図である。 コピー先筐体側で業務を再開しセッション無し状態を示す図である。 ホストとストレージとの間の処理シーケンスの一例を示すフローチャートである。 比較例として一貫性テーブルを備えないストレージシステムを示す図である。 二次バックアップの処理手順を示すフローチャートである。 ＲＥＣによるバックアップを示す図である。 一部のボリュームに故障が発生したときの処理を示す図である。 グループの一貫性が保証された状態を示す図である。 故障発生時の状態を示す図である。 バックアップ処理を示す図である。 故障ディスクの復旧を示す図である。 故障したコピー元ボリュームの交換を示す図である。 バックアップしたデータの復旧処理を示す図である。 リカバリ動作を示す図である。 初期コピーが完了し、等価状態を表す図である。 ＲＥＣセッションがSuspend 状態にあることを示す図である。 比較例の状態確認の処理シーケンスを示す図である。

〔第１の実施の形態〕

第１の実施の形態は、コピー元筐体とコピー先筐体とを備えるストレージシステムであって、データを分割して格納する複数のボリュームのコピーセッションをストレージ側でグループ管理する構成である。このグループ管理には、ストレージ側にある記憶部にグループ化を契機にステータス情報記憶領域を生成し、このステータス情報記憶領域にグループ毎のステータスを格納し、ホスト側に通知し又は確認可能とする。

各実施の形態において、ストレージシステムはデータを蓄える記憶システムであって、メモリ、ハードディスク、光ディスク等の記録媒体を備える。ボリュームは、データを記録する手段であって、媒体又は媒体中の記録領域の単位である。単一の媒体が複数のボリュームを構成してもよいし、単一のボリュームが複数の媒体で構成されてもよい。セッションは、データ転送等のデータ交換のために設定される通信等の論理的な接続関係であって、この実施の形態では、データコピーのために設定されるコピー元筐体とコピー先筐体との接続関係を含んでいる。

この第１の実施の形態について、図１を参照する。図１は、第１の実施の形態に係るストレージシステムの一例を示す図である。

このストレージシステム２は、本開示のストレージシステム及びストレージ制御方法の一例であって、図１に示すように、第１のストレージ装置としてコピー元筐体４と、第２のストレージ装置としてコピー先筐体６とを備える。

コピー元筐体４は、ストレージ手段の一例であって、コピー元のデータが格納されるストレージ装置である。このコピー元筐体４には外部制御装置として第１のホスト８が接続されている。このホスト８は、コピー元筐体４に対するデータ書き込み等を指示する手段であって、ホストコンピュータで構成される。

コピー先筐体６は、ストレージ手段の一例であって、コピー元から転送されるデータが格納されるストレージ装置である。このコピー先筐体６には外部制御装置として第２のホスト１０が接続されている。このホスト１０は、コピー先筐体６に蓄積されたデータを用いる制御手段であって、ホスト８と同様にホストコンピュータで構成される。

そして、コピー元筐体４には制御部１２と、記憶部１４と、複数のボリューム１６とが設けられている。制御部１２は、データを分割して格納する複数のボリューム１６をグループ化し、データの書き込み等の各種処理やデータ管理の実行や、例えば、コピーセッションのグループ化を契機に後述のステータス情報記憶領域１５を記憶部１４に生成させる手段である。即ち、制御部１２は、ボリューム１６をデータ毎にグループ単位で管理する手段であり、ステータス情報の記憶領域生成部の一例でもある。また、制御部１２はステータス情報をホスト８に通知する通知手段を構成する。

記憶部１４はボリューム１６のデータのコピーセッションのグループ毎にステータス情報を格納する手段であって、ステータス情報を格納する手段として例えば、ステータス情報記憶領域１５を生成させる。ステータス情報記憶領域１５は、コピーセッションのグループ化を契機に生成され、例えば、テーブルである。

ボリューム１６はデータを記録する手段であって、媒体又は媒体中の記録領域の単位であることは既述の通りである。

また、コピー先筐体６には制御部２２と、記憶部２４と、複数のボリューム２６とが設けられている。制御部２２も、制御部１２に対応し、分割されたデータを格納する複数のボリューム２６をグループ化し、データの書き込み等の各種処理やデータ管理を実行や、例えば、コピーセッションのグループ化を契機に後述のステータス情報記憶領域２５を記憶部２４に生成させる手段である。即ち、制御部２２は、ボリューム２６をデータ毎にグループ単位で管理する手段であり、ステータス情報の記憶領域生成部の一例でもある。また、制御部２２はステータス情報をホスト１０に通知する通知手段を構成する。

記憶部２４は記憶部１４と同様に、データのコピーセッションのグループ毎にステータス情報を格納する手段であって、ステータス情報を格納する手段として例えば、ステータス情報記憶領域２５を生成させる。ステータス情報記憶領域２５は、コピーセッションのグループ化を契機に生成され、例えば、テーブルである。

そして、ボリューム２６もボリューム１６と同様にデータを記録する手段であって、媒体又は媒体中の記録領域の単位であることは既述の通りである。

次に、グループの一貫性状態の構築処理について、図２を参照する。図２は、グループの一貫性状態の構築処理の処理手順を示すフローチャートである。

この処理手順は、本開示のストレージ制御方法の一例であって、コンピュータで実行されるストレージ制御プログラムの一例である。即ち、この処理手順には、コピー元筐体４からコピー先筐体６へのデータをコピーするコピーセッションを制御する処理を包含している。

そこで、この処理手順では、図２に示すように、データを分割して格納する複数のボリューム１６、２６のコピーセッションをグループ化する（ステップＳ１１）。

このグループ化を契機に記憶部１４にステータス情報記憶領域１５、記憶部２４にステータス情報記憶領域２５を生成させる（ステップＳ１２）。各ステータス情報記憶領域１５、２５には、グループ毎にコピーセッションのステータス情報を格納する（ステップＳ１３）。

ホスト８、１０からのアクセスにより、ストレージ（コピー元筐体４、コピー先筐体６）側にあるステータス情報記憶領域１５、２５にあるステータス情報を通知し、ホスト８、１０から確認することができる（ステップＳ１４）。

斯かる構成によれば、データを分割して格納する複数のボリュームのコピーセッションをグループ化し、そのグループ化を契機にストレージ側にある記憶部１４、２４にステータス情報記憶領域１５、２５を生成させ、グループ毎にデータの一貫性を管理する。この場合、コピーセッションのグループ毎にステータス情報が記憶部１４、２４に格納され、記憶部１４にあるステータス情報はホスト８で確認でき、同様に、記憶部２４にあるステータス情報はホスト１０で確認できる。即ち、ストレージ装置側でデータの一貫性処理された状態をホスト８、１０で容易に確認できる。

従って、このストレージシステム２では、ボリュームをグループ管理するシステムにおいて、ストレージ側でグループのデータ一貫性を監視し管理するので、ホスト８、１０側でのデータ一貫性の構築ないしその確認のための複雑な処理が省かれる。ホスト８、１０側ではデータの中身をチェックする等の負担から開放される。データが被災した後、その被災をデータ一貫性の確認で容易に把握できる等、システムの業務再開処理（ＲＴＯ：Recovery Time Objective)を簡略化でき、システムの復旧作業を迅速化できる。

〔第２の実施の形態〕

第２の実施の形態は、第１の実施の形態で示した構成を具体化するとともに、データコピーの被災を例示し、既述のＲＴＯの迅速化のためのＲＥＣ管理に寄与するストレージシステムの構成、機能及び処理内容に言及している。

この第２の実施の形態について、図３及び図４を参照する。図３は、ストレージシステムの機能部の構成例を示す図、図４は、ストレージシステムのハードウェアの構成例を示す図である。

このストレージシステム２には、ストレージ（コピー元筐体４、コピー先筐体６）側にコピーセッションをグループ管理するため、図３に示すように、コピー制御部３０と、メモリ制御部３２と、ＲＡＩＤ制御部３４とを備える。

コピー制御部３０は、既述の制御部１２（２２）に相当し、コピー機能（データバックアップ）の管理を行う機能部である。この場合、コピーとは、既述のリモート等価コピー機能（ＲＥＣ：Remote Equivalent Copy）である。

メモリ制御部３２は、ストレージの一次記憶領域の管理を行う機能部である。また、ＲＡＩＤ制御部３４は、ストレージのＲＡＩＤ（Redundant Array of Inexpensive Disks）制御やディスクへの読出し又は書込み（Read／Write ）を行う機能部である。

そして、コピー制御部３０には、コマンド受信処理制御部３６と、Ｉ／Ｏ処理制御部３８と、コピーセッション情報管理制御部４０と、グループ情報管理制御部４２と、データ転送制御部４４と、筐体間通信制御部４６とが備えられている。

コマンド受信処理制御部３６は、既述のコピー機能のコマンドの制御を行う機能部である。

Ｉ／Ｏ処理制御部３８は、コピー機能の領域への書き込み読み込みに対する制御を行う機能部である。

コピーセッション情報管理制御部４０は、コピーのセッションの管理を行う機能部であって、グループ情報テーブルの処理を行う。

グループ情報管理制御部４２は、グループ毎の一貫性を示すステータス情報を管理する機能部である。

データ転送制御部４４は、コピー元筐体４側のデータをコピー先筐体６へ転送する制御を行う機能部である。

筐体間通信制御部４６は、コピー元筐体４とコピー先筐体６との間でデータを通信する際の通信機能を実行する機能部であって、グループステータスの転送を行う。

そこで、ストレージシステム２は、図４に示すように、上記機能部を実現するハードウェアを備える。このストレージシステム２には、コピー元筐体４と、コピー先筐体６とが備えられ、コピー元筐体４側にはホスト８、コピー先筐体６にはホスト１０が接続されている。また、コピー元筐体４側には、ストレージ管理装置としてストレージ管理パーソナルコンピュータ（ＰＣ）４８が設置されている。ホスト８、１０は、オペレータが使用するホストコンピュータで構成される。

コピー元筐体４は、ユーザデータのストレージであるコピー元筐体（運用側）を構成し、コピー先筐体６は遠隔地に設置されたユーザデータをコピーするストレージであるコピー先筐体である。

コピー元筐体４には、中央制御部５０と、ディスク５２、５４と、Ｉ／Ｆ（Interface ）制御部５６、５８、６０とが備えられている。

中央制御部５０は、既述の機能部（図３）を実現するハードウェア（ＣＭ：Centralized Moduleであって、ディスク５２、５４、Ｉ／Ｆ制御部５６、５８、６０、メモリ６４等のメモリ制御、コピー制御等の資源管理を行う制御部（コントローラ）である。この中央制御部５０は、ホスト８に対するステータス情報の通知手段でもある。また、この中央制御部５０は、既述のステータス情報記憶領域をメモリ６４に生成させる記憶領域生成部の一例である。

ディスク５２、５４は、既述の複数のボリュームを構成し、ユーザディスクである。Ｉ／Ｆ制御部５６は、ストレージ管理ＰＣ４８を接続するポート及びその制御部である。Ｉ／Ｆ制御部５８は、ホスト８との接続手段であって、チャネルアダプタ（ＣＡ：Channel Adapter ）である。また、Ｉ／Ｆ制御部６０は、コピー先筐体６との遠隔接続手段であって、リモートアダプタ（ＲＡ：Remote Adapter）である。

中央制御部５０は、ＣＰＵ（Central Processing Unit ）６２と、メモリ６４と、Ｉ／Ｆ制御部６６、６８とを備える。

ＣＰＵ６２は、メモリ６４に格納されたＯＳ（Operating System）等のプログラムを実行する手段であって、コピー機能を制御する。

メモリ６４は、中央制御部５０に設定された記録媒体であって、例えば、キャッシュ（Cache ）メモリで構成され、ユーザデータや制御データ等が格納される。このメモリ６４には、既述のステータス情報記憶領域１５の一例として一貫性ステータステーブル１２２が生成され、グループのステータス情報が格納されて管理される。

Ｉ／Ｆ制御部６６はディスク５２が接続されるインターフェイスであり、Ｉ／Ｆ制御部６８はディスク５４が接続されるインターフェイスである。

また、コピー先筐体６には、第１及び第２の中央制御部７０、９０と、ディスク７２、７４、９２、９４と、Ｉ／Ｆ制御部７８、８０、９８、１００とが備えられている。

中央制御部７０は、既述の機能部（図３）を実現するハードウェア（ＣＭ）であって、ディスク７２、７４、Ｉ／Ｆ制御部７８、８０、メモリ８４等のメモリ制御、コピー制御等の資源管理を行う制御部（コントローラ）である。また、この中央制御部７０は、既述のステータス情報記憶領域をメモリ８４に生成させる記憶領域生成部の一例である。

中央制御部９０は、既述の機能部（図３）を実現するハードウェア（ＣＭ）であって、ディスク９２、９４、Ｉ／Ｆ制御部９８、１００、メモリ１０４等のメモリ制御、コピー制御等の資源管理を行う制御部（コントローラ）である。中央制御部７０、９０は、ホスト１０に対するステータス情報の通知手段でもある。また、この中央制御部９０は、既述のステータス情報記憶領域をメモリ１０４に生成させる記憶領域生成部の一例である。

ディスク７２、７４、９２、９４は、既述の複数のボリュームを構成し、ユーザディスクである。Ｉ／Ｆ制御部７８は、コピー元筐体４との遠隔接続手段であって、リモートアダプタ（ＲＡ）である。Ｉ／Ｆ制御部８０、９８は、ホスト１０と接続する手段であって、チャネルアダプタ（ＣＡ）である。

中央制御部７０には、ＣＰＵ８２と、メモリ８４と、Ｉ／Ｆ制御部８６、８８とが備えられ、また、中央制御部９０には、ＣＰＵ１０２と、メモリ１０４と、Ｉ／Ｆ制御部１０６、１０８とが備えられている。

ＣＰＵ８２は、メモリ８４に格納されたＯＳ等のプログラムを実行する手段であって、コピー機能を制御する。また、ＣＰＵ１０２は、メモリ１０４に格納されたＯＳ等のプログラムを実行する手段であって、コピー機能を制御する。

メモリ８４は、中央制御部７０に設定された記録媒体であって、例えば、キャッシュメモリで構成され、ユーザデータや制御データ等が格納される。このメモリ８４には、既述のステータス情報記憶領域２５の一例として一貫性ステータステーブル１２２が生成され、グループのステータス情報が格納されて管理される。同様に、メモリ１０４は、中央制御部９０に設定された記録媒体であって、例えば、キャッシュメモリで構成され、ユーザデータや制御データ等が格納される。このメモリ１０４にも、既述のステータス情報記憶領域２５の一例として一貫性ステータステーブル１２２が生成され、グループのステータス情報が格納されて管理される。

Ｉ／Ｆ制御部８６はディスク７２が接続されるインターフェイスであり、Ｉ／Ｆ制御部８８はディスク７４が接続されるインターフェイスである。Ｉ／Ｆ制御部１０６はディスク９２が接続されるインターフェイスであり、Ｉ／Ｆ制御部１０８はディスク９４が接続されるインターフェイスである。

メモリ６４、８４、１０４について、図５を参照する。図５は、メモリの構成例を示す図である。図５において、図４と同一部分には同一符号を付してある。

メモリ６４は例えば、キャッシュメモリで構成され、このメモリ６４には図５に示すように、データ記憶領域１１０と、プログラム記憶領域１１２と、ワーク領域１１４とが設定される。データ記憶領域１１０には、ユーザデータ１１６、制御データ１１８が格納されるとともに、コピーセッション管理テーブル１２０、一貫性ステータステーブル１２２が形成されている。コピーセッション管理テーブル１２０には、コピーセッションの管理情報が格納され、一貫性ステータステーブル１２２にはグループのステータス情報が格納される。プログラム記憶領域１１２には、ＯＳ１２４、データ転送制御プログラム１２６、その他の制御プログラム１２８が格納される。ワーク領域１１４は、演算処理や制御処理に用いられる。

メモリ８４、１０４は、メモリ６４と同様の構成を備えていればよく、この実施の形態では、同一構成であるので、その説明を省略する。

各種管理テーブルについて、図６、図７及び図８を参照する。図６は、コピーセッション管理テーブルの一例を示す図、図７は、ボリュームステータス及びその意味を説明するための図、図８は、一貫性ステータステーブルの一例を示す図である。

コピーセッション管理テーブル１２０には、コピーデータをグループで管理するための管理情報を格納し、この管理情報はグループの特定、モード、状態、フェーズ、ボリューム等の特定情報を包含している。このコピーセッション管理テーブル１２０には、図６に示すように、コピー管理番号１３０、グループ番号１３２、転送モード１３４、ステータス（Status）１３６、フェーズ（Phase ）１３８が格納されている。更に、コピーセッション管理テーブル１２０には、コピー元コピー対象ボリューム１４０、コピー先コピー対象ボリューム１４２が格納されている。更に、コピーセッション管理テーブル１２０には、コピー元コピー対象開始位置１４４、コピー先コピー対象開始位置１４６、コピー対象ブロック数１４８、コピー状態管理ビットマップ（Bitmap）１５０が格納されている。

コピー管理番号１３０は、コピーセッションにつけられる一意的な番号である。グループ番号１３２は、グループを識別するための識別情報の一例である。

転送モード１３４は、コピー種別を示す情報であって、コピーモードには同期モードと非同期モードがある。この転送モード１３４には同期モード又は非同期モードの何れかが格納される。

ステータス（Status）１３６は、コピーセッションの状態を表す情報である。このステータスには、初期状態（Idle）、動作状態（Active）、一時切離し状態（Suspend ）、エラー状態（Errsus）の何れかの状態がある。

フェーズ（Phase ）１３８は、コピーセッションの動作を示している。このフェーズには、コピー処理非動作（Nopair）、コピー処理動作中（Copying ）、等価状態（Equivalent）がある。

これらボリュームステータス及びその意味は、図７に示す通りであり、“セッション無し”は、ボリュームのコピー設定が行われていない状態である。“Active／Copying ”は、コピー元への書き込みに同期してコピー先へデータを転送する。コピー元には未転送データ有り。コピー先ボリュームは不完全なデータであり、利用不可の状態である。“Active／Equivalent”は、コピー元への書き込みに同期してコピー先へデータを転送する。コピー元には未転送データ有り。コピー先ボリュームはコピー元ボリュームと一致しており、利用可能の状態である。“Suspend ／Copying ”は、コピー元への書き込みデータをコピー先へ転送しない。Active／Copying 状態で転送を中断した状態であり、コピー先ボリュームは不完全なデータであり、利用不可の状態である。“Suspend ／Equivalent”は、コピー元への書き込みデータをコピー先へ転送しない。“Active／Equivalent”状態で転送を中断した状態であり、コピー先ボリュームは転送中断時のコピー元データと一致しており、中断時点のスナップショットとして利用可能の状態である。“Suspend ”と記述した部分は、Suspend （ホスト指定による中断）とHalt（ストレージ側で回線切れ検出等によるエラー中断）があり、ここでは２つをまとめてSuspend と記述している。

コピー元コピー対象ボリューム１４０は、コピー元のコピー対象であるボリュームの識別情報であって、例えば、転送元論理ユニット番号（コピー元ＬＵＮ）である。

コピー先コピー対象ボリューム１４２は、コピー先のコピー対象であるボリュームの識別情報であって、例えば、転送先論理ユニット番号（コピー先ＬＵＮ）である。

コピー元コピー対象開始位置１４４は、コピー元のコピー対象の開始位置を特定する情報であって、例えば、転送元論理ユニットでのコピー開始アドレス（コピー元コピー対象開始ＬＢＡ）である。

コピー先コピー対象開始位置１４６は、コピー先のコピー対象の開始位置を特定する情報であって、例えば、転送先論理ユニットでのコピー開始アドレス（コピー先コピー対象開始ＬＢＡ）である。

コピー対象ブロック数１４８は、コピー対象のコピー転送量である。また、コピー状態管理ビットマップ１５０は、コピー状態を表すビットマップ情報である。即ち、コピー状態をビットマップで管理するので、コピー状態管理ビットマップ１５０はコピー状態を表す情報である。

また、一貫性ステータステーブル１２２は、コピー開始（ＲＥＣのStart ）でグループ番号の指定に基づいて作成される。この一貫性ステータステーブル１２２は、中央制御部５０、７０、９０にあるメモリ６４、８４、１０４のデータ記憶領域１１０にグループ数だけ保持される。そこで、一貫性ステータステーブル１２２には、グループ毎のデータの一貫性を表す情報が格納され、この実施の形態では、図８に示すように、グループ番号１３２、一貫性ステータス１５２が格納されている。グループ番号１３２は、コピーセッション管理テーブル１２０のグループ番号１３２に対応し、一貫性ステータステーブル１２２はコピーセッション管理テーブル１２０とグループ番号１３２で関係付けられている。また、一貫性ステータス１５２は、一貫性状態にあるか否かを表す状態情報である。

コピーセッショングループの一貫性管理について、図９及び図１０を参照する。図９は、コピーセッショングループの一貫性管理の状態遷移を示す図、図１０は、グループステータス及びその意味を示す図である。

同期型バックアップの複数動作時におけるコピーセッションは、コピーセッション管理テーブル１２０を用いて管理され、このコピーセッション管理テーブル１２０には、既述の通り、コピーセッションを表す管理番号、対象ボリューム、対象サイズ、開始位置、グループ番号等の管理情報が格納される。そして、各コピーグループの一貫性状態は、一貫性ステータステーブル１２２で管理される。

コピーグループ毎に新規に構造体として例えば、一貫性ステータステーブル１２２が用意され、そこに一貫性を示す状態が作成される。即ち、グループの一貫性の判断基準となる状態として、図９に示すように、同期転送中状態１６２、同期転送中断状態１６４、データ不整合状態１６６、セッション無し状態１６８の４状態を定義し、これらを個別に監視するとともに、セッション状態の変更に応じてステータスを変更させる。ここで、同期転送中状態１６２とは、グループを構成する全ての同期コピーセッションが等価状態であることである。同期転送中断状態１６４は、同期転送中状態１６２のグループに対し、一括切り離し処理が実行された場合であって、グループを構成する全ての同期コピーセッションが切り離し状態であることである。セッション無し状態１６８とは、グループ内に同期コピーセッションが一つも存在しないことである。また、データ不整合状態１６６は、上記以外の状態である。そして、このステータスが同期転送中状態１６２又は同期転送中断状態１６４であれば、データに一貫性があり、それ以外の状態即ち、データ不整合状態１６６又はセッション無し状態１６８では、データに一貫性が無いと判断する。グループステータス及びその意味は、図１０に示す通りである。

そこで、図９では、コピーセッションのグループの一貫性状態に対し、ある事象が発生した際に、どのような状態に変更されるかを示している。

同期転送中状態１６２から一括切り離し処理を終了し、又は同期転送中に被災した場合には、同期転送中断状態１６４に遷移する（ステップＳ２１）。同期転送中状態１６２からグループ内の一部のセッションを削除しても、同期転送中状態１６２のままである（ステップＳ２Ｘ１）。

同期転送中断状態１６４から切り離されたセッションを再開し、又は新セッションを作成すると、データ不整合状態１６６に遷移する（ステップＳ２２）。また、同期転送中状態１６２から一部のセッションを切り離し、又は新セッションを作成すると、データ不整合状態１６６に遷移する（ステップＳ２３）。同期転送中断状態１６４からグループ内の一部のセッションを削除しても、同期転送中断状態１６４のままである（ステップＳ２Ｘ２）。

データ不整合状態１６６から全てのセッションが等価状態へ移行すると、同期転送中状態１６２に遷移する（ステップＳ２４）。データ不整合状態１６６において、新セッションを作成したり、又はグループ内の切り離されたセッションを再開させたときはデータ不整合状態１６６のままである（ステップＳ２Ｘ３）。

同期転送中状態１６２、同期転送中断状態１６４又はデータ不整合状態１６６から全てのセッションを削除すると、セッション無し状態１６８に遷移する（ステップＳ２５、Ｓ２６、Ｓ２７）。即ち、初期状態に遷移する。

また、セッション無し状態１６８からセッションを作成すると、データ不整合状態１６６に遷移する（ステップＳ２８）。

そして、グループの一貫性を示す状態の変更処理は、中央制御部５０、７０、９０のＣＰＵ６２、８２、１０２で実行する。この実行の契機は、以下の通りである。

(a) グループを構成する同期型コピーセッションに対するコマンドの作成、削除、切り離し又は再開の場合。

(b) グループを構成する同期型コピーセッション全てのセッションが等価になった場合。

(c) グループを構成する同期型コピーセッションの一括切り離し処理の実行時。

また、グループの一貫性を示す状態の判断条件（判断基準）として既述の同期転送中状態１６２、同期転送中断状態１６４、データ不整合状態１６６、セッション無し状態１６８が設定されている。従って、コピーグループのステータスが同期転送中状態１６２又は同期転送中断状態１６４であれば、データに一貫性があり、それ以外の場合はデータに一貫性が欠如していることになる。

そこで、状態の変更処理について、図１１を参照する。図１１は、状態の変更処理の処理手順を示すフローチャートである。

この処理手順は、本開示のストレージ制御方法の一例であって、一貫性状態変更の処理手順である。

既述の同期転送中断状態１６４への変更は、一貫性ステータスの変更の条件により実行される。即ち、グループに対する一括切り離しコマンド処理、又は被災によるグループ内のバックアップ一括停止処理が実行されない限り、同期転送中断状態１６４に遷移しない。そのため、グループを構成するそれぞれの同期型バックアップセッションがそれぞれのタイミングで切り離されても、一貫性ステータスはデータ不整合状態１６６となる。これにより、コピー元サイトで被災が発生し同期型バックアップが切り離し状態になった場合のデータの一貫性が保証される。

そこで、この処理手順では、図１１に示すように、一貫性状態変更処理が開始されると、確認処理として、同期型バックアップコマンドに対し実行されたコマンド種別を確認し（ステップＳ３１）、現在の一貫性状態を確認する（ステップＳ３２）。これらのステップＳ３１、Ｓ３２の確認により、一貫性状態に変更が行われるか確認を行う（ステップＳ３３）。

一貫性ステータスに変更が行われていれば（ステップＳ３３のＹＥＳ）、新たな一貫性状態を決定し（ステップＳ３４）、変更された一貫性状態を一貫性ステータステーブル１２２に格納し（ステップＳ３５）、この一貫性状態変更処理を終了する。

一貫性状態に変更が行われていなければ（ステップＳ３３のＮＯ）、この一貫性状態変更処理を終了する。

次に、状態の確認処理について、図１２を参照する。図１２は、状態の確認処理の処理手順を示すフローチャートである。

この処理手順は、本開示のストレージ制御方法の一例であって、状態の確認処理の処理手順であり、同期型バックアップの複数動作時におけるコピーセッションのグループの一貫性の状態の取得処理である。

グループの一貫性の状態は、ホスト８、１０よりストレージ（コピー元筐体４、コピー先筐体６）に対しコマンドを発行することにより、取得できる。そのために、新規にグループステータス確認コマンドを作成する。本コマンドはバックアップ元のストレージ、又はバックアップ先のストレージに対しホストより発行し、データ記憶領域１１０に保存してある、それぞれのグループの一貫性ステータスを取得してホスト８、１０に対して通知する。

そこで、この処理手順では、状態の確認処理として、一貫性状態確認処理が開始されると、ホスト８、１０よりストレージへグループステータス確認コマンドを発行する（ステップＳ４１）。ストレージはグループステータス確認コマンドを受領する（ステップＳ４２）。これにより、指定されたグループが存在するかを判定する（ステップＳ４３）。指定されたグループが存在すれば（ステップＳ４３のＹＥＳ）、ストレージは指定されたグループの一貫性ステータステーブル１２２より獲得したステータスをホストへ通知し（ステップＳ４４）、この一貫性状態確認処理を終了する。

また、指定されたグループが存在しなければ（ステップＳ４３のＮＯ）、この一貫性状態確認処理を終了する。

次に、グループステータス変更について、図１３を参照する。図１３は、グループステータス変更の処理手順を示すフローチャートである。

このグループステータス変更は、本開示のストレージ制御方法の一例であって、各処理の巡回処理によって実行される。

そこで、この処理手順では、セッション状態の変更を認識し（ステップＳ５１）、このセッション状態の変更を認識すると、セッション作成又はResumeかを確認する（ステップＳ５２）。セッション作成又はResumeであれば（ステップＳ５２のＹＥＳ）、（Ａ）セッション作成又はResumeの処理を実行し（ステップＳ５３）、ステップＳ５１に戻る。

セッション作成又はResumeでなければ（ステップＳ５２のＮＯ）、セッション削除であるかを確認する（ステップＳ５４）。セッション削除であれば（ステップＳ５４のＹＥＳ）、（Ｂ）削除処理を実行し（ステップＳ５５）、ステップＳ５１に戻る。

セッション削除でなければ（ステップＳ５４のＮＯ）、セッションのSuspend であるかを確認する（ステップＳ５６）。セッションのSuspend であれば（ステップＳ５６のＹＥＳ）、（Ｃ）Suspend 処理を実行し（ステップＳ５７）、ステップＳ５１に戻る。

セッションのSuspend でなければ（ステップＳ５６のＮＯ）、（Ｄ）Equivalent処理を実行し（ステップＳ５８）、ステップＳ５１に戻る。

次に、（Ａ）セッション作成／Resumeについて、図１４を参照する。図１４は、（Ａ）セッション作成／Resume時のグループステータス変更の処理手順を示すフローチャートである。

この処理手順では、セッション作成又はResumeが実行されると、グループステータスをデータ不整合状態に移行させ（ステップＳ５３１）、既述のステップＳ５１（図１３）にリターンする。

次に、（Ｂ）削除処理について、図１５を参照する。図１５は、（Ｂ）削除処理時のグループステータス変更の処理手順を示す示すフローチャートである。

この処理手順では、（Ｂ）削除処理の実行が開始されると、全セッションが削除されたかが確認される（ステップＳ５５１）。全セッションが削除されていれば（ステップＳ５５１のＹＥＳ）、セッション無し状態に遷移する（ステップＳ５５２）。

全セッションが削除されていなければ（ステップＳ５５１のＮＯ）、残ったセッションの全てがActive／ Equivalent であるかを確認する（ステップＳ５５３）。残ったセッションの全てがActive／ Equivalent であれば（ステップＳ５５３のＹＥＳ）、同期転送中状態へ遷移する（ステップＳ５５４）。

残ったセッションの全てがActive／ Equivalent でなければ（ステップＳ５５３のＮＯ）、現在のグループステータスがデータ転送中断状態であるかを確認する（ステップＳ５５５）。現在のグループステータスがデータ転送中断状態であれば（ステップＳ５５５のＹＥＳ）、同期転送中状態へ遷移する（ステップＳ５５６）。

現在のグループステータスがデータ転送中断状態でなければ（ステップＳ５５５のＮＯ）、データ不整合状態へ遷移する（ステップＳ５５７）。

次に、（Ｃ）Suspend 処理について、図１６を参照する。図１６は、セッションSuspend 処理時のグループステータス変更の処理手順を示すフローチャートである。

この処理手順では、（Ｃ）Suspend 処理の実行が開始されると、グループ内の一部のみをSuspend 処理するかを確認する（ステップＳ５７１）。グループ内の一部のみをSuspend 処理するのであれば（ステップＳ５７１のＹＥＳ）、データ不整合状態へ遷移する（ステップＳ５７２）。

グループ内の一部のみをSuspend 処理しないのであれば（ステップＳ５７１のＮＯ）、現在、同期転送中状態かを確認する（ステップＳ５７３）。現在、同期転送中状態であれば（ステップＳ５７３のＹＥＳ）、同期転送中断状態へ遷移させる（ステップＳ５７４）。また、現在、同期転送中状態でなければ（ステップＳ５７３のＮＯ）、データ不整合状態に遷移させる（ステップＳ５７５）。

次に、（Ｄ）Equivalent処理について、図１７を参照する。図１７は、セッションEquivalent（初期コピー完了）時のグループステータス変更の処理手順を示すフローチャートである。

この処理手順では、（Ｄ）Equivalent処理の実行が開始されると、全セッションがActive／Equivalentかを確認する（ステップＳ５８１）。全セッションがActive／Equivalentであれば（ステップＳ５８１のＹＥＳ）、同期転送中状態へ遷移する（ステップＳ５８２）。また、全セッションがActive／Equivalentでなければ（ステップＳ５８１のＮＯ）、データ不整合状態へ遷移する（ステップＳ５８３）。

以上の通り、データの一貫性の状態が判定され、保証される。このデータの一貫性について、ストレージのリモートコピーでは、“ホストからコピー元への更新順序”と、“コピー元からコピー先への更新順序”を保証することが、コピー先データの一貫性を保証することと同一とされる。本開示のストレージシステム及びストレージ制御方法では、グループの整合性状態が同期転送中状態１６２の場合はコピー元への書き込みに同期してコピー先へ転送しているので、順序性が保証されている。また、同期転送中断状態１６４の場合は、前記順序性が保証された状態でグループ内の全ボリュームの転送を同時に停止するため、これも順序性が保証されている。

この順序性保証がデータの一貫性を保証することになる。即ち、ファイルシステムやデータベースはデータテーブルの更新前、ログに書き込むことで、処理途中に障害が発生しても正常にリカバリできる機能を備える。

次に、順序性保証について、図１８及び図１９を参照する。図１８は、コピー元サイト及びコピー先サイト間のログ処理システムを示す図、図１９は、ログの記録処理の処理手順を示すフローチャートである。図１８において、図４と同一部分には同一符号を付してある。

ログ処理システムは、図１８に示すように、コピー元サイト４００とコピー先サイト６００が存在している。コピー元サイト４００には、既述のホスト８及び中央制御部５０が設置され、中央制御部５０にはデータボリューム４１６、ログボリューム４１８が備えられている。また、コピー先サイト６００には、既述のホスト１０及び中央制御部９０が設置され、中央制御部９０にはデータボリューム６１６、ログボリューム６１８が備えられている。

このようなコピー元サイト４００とコピー先サイト６００との間のデータコピーの処理手順では、図１９に示すように、更新前及び更新後のデータ１をログに書き込み（ステップＳ６１）、データ１を更新し（ステップＳ６２）、更新前及び更新後のデータ２をログに書き込む（ステップＳ６３）。このデータ２を更新する（ステップＳ６４）。そして、コミットデータをログに書き込む（ステップＳ６５）。

このようなログ処理において、データ１とデータ２は同時に更新されるべきデータである。例えば、データ１は銀行口座の引き落とし元、データ２は振り込み先である。仮に、ステップＳ６３の処理中にホストがエラーにより停止した場合、ホストの再起動後にリカバリ処理が動作する。このリカバリ処理は、ログを読み込んで、コミットデータを検索し、未コミット状態であるデータ１及びデータ２を更新前のデータに戻す。なお、ホストはステップＳ６４の書き込み完了応答が無い限り、ステップＳ６５の書き込みを行わない。

リモートコピーで順序性を保証していない場合には、コピー元サイトでステップＳ６１〜Ｓ６５の処理が完了したが、データ１及びデータ５のコミットデータのみが転送され、データ２が転送されていない状態があり得る。この状態でコピー先サイトにてリカバリ処理が起動しても、ステップＳ６５のコミットデータがあるため、データ１とデータ２の不整合状態が解消されない。これではデータベースとして使用出来ない。

そこで、通常、データテーブルとログは異なるボリュームに格納されるため、ボリューム間でデータの順序性（＝一貫性）を保証する必要がある。本開示のストレージシステム及びストレージ制御方法では、既述のディスク５２、５４、７２、７４、９２、９４（図４）に限定されるものではなく、このようなデータボリューム４１６、６１６とログボリューム４１８、６１８をグループ化し、グループとしての一貫性が保たれることを保証している。

次に、データに一貫性が無い場合の復旧手順について、図２０、図２１、図２２、図２３、図２４、図２５、図２６及び図２７を参照する。図２０は、同期転送中状態を示す図、図２１は、同期転送中断状態を示す図、図２２は、バックアップデータの採取を示す図、図２３は、データ不整合状態を示す図、図２４は、コピー元筐体側の被災時のデータ不整合状態を示す図、図２５は、データ不整合状態を示す図、図２６は、セッション無し状態を示す図、図２７は、コピー先筐体側で業務を再開しセッション無し状態を示す図である。図２０〜図２７において、図４と同一部分には同一符号を付してある。

リモートコピーシステムを構成したストレージシステム２では、一定のタイミングでリモートコピーの転送を中断し、コピー先筐体で整合性のあるデータのバックアップを採取する。コピー元筐体の被災時、コピー先ボリュームに整合性が無いと判断した場合はこの１世代前のバックアップより復旧を行うことができる。

このストレージシステム２では、コピー元筐体４において、コピー元ボリューム４１１、４１２、４１３が１つのコピーグループＧを構成する。これに対応し、コピー先筐体６には、コピー先ボリューム６１１、６１２、６１３及びバックアップボリューム６２１、６２２、６２３がそれぞれ１つのコピーグループＧを構成している。

そこで、通常運用中（同期転送中状態）では、図２０に示すように、ホスト８でＩ／Ｏ処理が実行されると、コピー元筐体４にあるコピー元ボリューム４１１〜４１３からデータがコピー先筐体６のコピー先ボリューム６１１〜６１３に転送され、コピーされる。

また、バックアップ取得のため、Concurrent Suspendコマンド発行（同期転送中断状態）では、図２１に示すように、ホスト８から Concurrent Suspend コマンドが発行されると、リモート転送中断となる。即ち、コピー中断となる。

また、コピー先筐体６でバックアップの採取（同期転送中断状態）では、図２２に示すように、ホスト８、１０からＩ／Ｏ再開が実行され、ホスト１０からコピー先筐体６に対してＯＰＣコマンドが発行され、コピー先筐体６では、バックアップ採取が実行される。即ち、コピー先ボリューム６１１〜６１３からデータがバックアップボリューム６２１〜６２３に採取される。

また、コピーを順次再開（データ不整合状態）する場合には、図２３に示すように、ホスト８からコピー元筐体４に Resume コマンドが発行される。

また、図２４に示すように、同期が取れる前にコピー元筐体４で被災が発生した場合には、データ不整合状態となる。

コピー元筐体４が被災した場合には、図２５に示すように、コピー先筐体６で整合性状態を確認し、不整合と認識する。即ち、データ不整合状態となる。

コピー元筐体４が被災した場合には、図２６に示すように、ホスト１０からコピー先筐体６にリストアコマンドを発行し、コピー先筐体６で瞬時リストアを実行する。

この場合、リモートコピーセッションを削除した後、コピー先筐体６でバックアップボリューム６２１〜６２３よりリストアを実行する。即ち、セッション無し状態となる。

また、コピー元筐体４が被災した場合には、図２７に示すように、ホスト１０とコピー先筐体６とで業務を再開させる。この場合、セッション無し状態である。

次に、一貫性状態の確認について、図２８を参照する。図２８は、ホストとストレージとの間の処理シーケンスを示すフローチャートである。図２８において、図４と同一部分には同一符号を付してある。

この処理シーケンスは、ホスト８又はホスト１０とストレージ即ち、コピー元筐体４又はコピー先筐体６との間の一貫性確認処理の手順であって、本開示のストレージ制御方法又はストレージ制御プログラムの一例である。

既述の処理によってグループの一貫性状態が構築されるが、この一貫性状態の確認では、図２８に示すように、ホスト８又はホスト１０から該当するグループ情報の取得要求が発せられる（ステップＳ７１）。

このグループ情報の取得要求を受けたコピー元筐体４又はコピー先筐体６では、通知されたグループ番号を用いて一貫性ステータステーブル１２２からグループ一貫性ステータスを取得する（ステップＳ７２）。これに基づき、コピー元筐体４又はコピー先筐体６からグループの一貫性状態の通知がグループ情報の取得要件を発したホスト８又はホスト１０に対して発せられる（ステップＳ７３）。

一貫性状態の通知を受けたホスト８又はホスト１０では、通知されたグループに対する一貫性を確認することができる（ステップＳ７４）。

次に、第２の実施の形態のストレージシステム２において、ＲＥＣコマンド及びその動作を以下に説明する。

(1) START コマンド

ホストよりＲＥＣの開始を行いたい場合、ストレージに対し、コピー管理番号、グループ番号、モード、コピー元ＬＵＮ、コピー先ＬＵＮ、コピー元対象開始位置、コピー先対象開始位置を通知する。ストレージは指定された先の情報をストレージ内のキャッシュ領域にあるセッション管理テーブルに記憶する。その後、セッション管理テーブルのステータスをACTIVE、フェーズをCopying に変更した後、ホストへコマンド完了を通知する。それと同時に、ストレージはコピー元のデータをコピー先へと転送を開始する。

(2) Suspend コマンド

ホストよりＲＥＣの切り離しを行いたい場合、ストレージに対し切り離しを行いたいＲＥＣセッションのコピー管理番号、グループ番号、モード、コピー元ＬＵＮ、コピー先ＬＵＮ、コピー元対象開始位置、コピー先対象開始位置をストレージに通知する。ストレージは指定された先の情報がストレージ内のキャッシュ領域にあるセッション管理テーブルに存在することを確認する。存在の確認後、セッション管理テーブルのステータスをSuspend に変更した後、ホストへコマンド完了を通知する。

(3) Resumeコマンド

ホストよりＲＥＣの再接続を行いたい場合、ストレージに対し再接続を行いたいＲＥＣセッションのコピー管理番号、グループ番号、モード、コピー元ＬＵＮ、コピー先ＬＵＮ、コピー元対象開始位置、コピー先対象開始位置をストレージに通知する。ストレージは指定された先の情報がストレージ内のメモリ６４（例えば、キャッシュ領域）にあるコピーセッション管理テーブル１２０に存在することを確認する。存在の確認後、セッション管理テーブルのステータスをActiveに変更した後、ホストへコマンド完了を通知する。

コマンド応答後、切り離し時に書き込みがあった場合、その書き込みがあったデータをコピー先に転送を開始する。

(4) Stopコマンド

ホスト８よりＲＥＣセッションの停止を行いたい場合、ストレージに対し停止を行いたいＲＥＣセッションのコピー管理番号、グループ番号、モード、コピー元ＬＵＮ、コピー先ＬＵＮ、コピー元対象開始位置、コピー先対象開始位置をストレージに通知する。ストレージは指定された先の情報がストレージ内のメモリ６４（例えば、キャッシュ領域）にあるセッション管理テーブルに存在することを確認する。存在の確認後、セッション管理テーブルの情報を削除した後、ホストへコマンド完了を通知する。

以上述べた第２の実施の形態から明らかなように、ストレージシステム又はストレージ制御方法の特徴事項は以下の通りである。

(1) ボリュームをグループ管理するシステムにおいて、ストレージ側でグループのデータ一貫性を管理することでホスト側がデータの中身をチェックし、データに一貫性があるか確認する手間が省ける。これにより、被災発生後の業務再開処理（ＲＴＯ：Recovery Time Objective)を縮小でき、復旧作業を迅速化できる。

(2) グループとしてのデータ一貫性をストレージ側で“グループの一貫性ステータス”として管理することができる。

(3) グループのステータスはコピー元筐体及びコピー先筐体の何れからも参照できる。

(4) ストレージはグルーピングされたＲＥＣのそれぞれのセッションに対し、ホストよりコマンドを発行し各ＲＥＣのセッションのステータスの変更を行うとき、又は各ＲＥＣセッションが等価状態となって、ＲＥＣセッションのフェーズを変更する際、あるいはストレージで災害が発生して各ＲＥＣセッションのステータスの変更を行う場合に“グループの一貫性ステータス”の変更を行う。ホスト８はそれぞれのグループの“グループの一貫性ステータス”を採取して確認し、グループの一貫性をそのステータス情報の中身から確認する。この変更された“グループの一貫性ステータス”はコピー元筐体のストレージの中央制御部５０のメモリ６４に一貫性ステータステーブル１２２を作成し、保持する。

これにより、コピー先筐体６のホスト１０は“グループの一貫性ステータス”を確認することによりデータの一貫性を確認でき、複雑な処理を経ることなく、データが使用可能かを判断することができる。

ホスト側がグルーピングされた複数のＲＥＣセッションに対しＲＥＣを切り離すために一貫性を確認する処理を行う場合には、グループに属する複数のＲＥＣセッションに対してステータス情報の取得及びホスト８、１０から１つのグループに１つの“グループの一貫性ステータス”を取得し参照するだけで済む。このため、処理の短縮及び資源の無駄を省くことができる。

(5) “グループの一貫性ステータス”はストレージ内で管理することにより、ストレージ内で発生した事象においても、即座にグループステータス情報に反映でき、グループステータス参照時のホスト８、１０でのタイムラグを削減できる。

〔比較例〕

比較例は、上記実施の形態において、グループに関する一貫性テーブルの生成や、一貫性ステータスを監視しない場合の構成例である。このような比較例では、ホスト側の負担が大きくなるが、その処理の内容を示したものである。このような処理における不都合は上記実施の形態において解消されている。

この比較例について、図２９、図３０、図３１、図３２、図３３、図３４、図３５、図３６、図３７、図３８、図３９、図４０、図４１及び図４２を参照する。図２９は、一貫性テーブルを備えないストレージシステムを示す図、図３０〜図４１は、コピー処理及びその被災を示す図、図４２は、比較例における処理シーケンスを示す図である。

このストレージシステム５０２は、図２９に示すように、ストレージとしてコピー元筐体５０４とコピー先筐体５０６とを備え、コピー元筐体５０４にはホスト５０８が接続されている。コピー元筐体５０４とコピー先筐体５０６とはネットワーク５２８で接続されている。コピー元筐体５０４にはコピー元ボリューム７００、コピー先筐体５０６にはコピー先ボリューム８００が設置されている。

このようなストレージシステム５０２において、ＲＥＣ機能が備えられている。このＲＥＣ機能が、異なるストレージ装置のコピー元筐体５０４とコピー先筐体５０６との間におけるデータ転送機能であって、ボリュームの全体又は一部のデータをコピー元筐体５０４からコピー先筐体５０６へコピーするコピー機能であることは既述の通りである。このようなＲＥＣ機能がホスト５０８を介さずにコピー元筐体５０４とコピー先筐体５０６との間で直接にデータ転送を行うので、ホスト５０８側にあるＣＰＵがデータ転送から開放され、その負荷が軽減されることも既述した通りである。

ここで、ＲＥＣ機能の起動単位は“セッション”と称される。ストレージ装置側に設置されたＣＰＵでは、このセッション毎にコピー元領域、コピー先領域、コピーサイズ、状態（Status）、段階（Phase ）、コピー種別を管理する。セッションは、StatusとPhase とを組み合わせてコピー状態を管理するので、コピー状態（Status）は、不活性状態（Idle）、活性状態（Active）、コピー中断状態（Suspend ）、故障状態（Errsus）があり、Phase には、コピー段階（Copying ）、等価段階（Equivalent）がある。

Statusの変更には、ホスト５０８からのコマンド指示による変更と、装置故障等の発生によりストレージ装置自身で行う変更とがある。ホストからコマンド指示により変更を行った場合は、コマンドの応答を以てStatusを変更したこととなる。Phase はＲＥＣ機能のバックアップ状況を示すものである。

Phase において、ＲＥＣ機能の初期コピー中であるか、等価状態であるかの判断を行う。なお、ＲＥＣにおいてPhase の変更はストレージ装置内部で動作し、ホストに対しては変更を通知しない。

ホスト５０８がＲＥＣ機能のPhase を確認する場合には、状態表示コマンドを実行する。状態表示コマンドをストレージ装置が受けると、ホスト５０８から指定されたＲＥＣセッションのStatusとPhase をホスト５０８に対して通知する。

ＲＥＣ機能は、既述のステータス及びフェーズを含むＲＥＣセッションの管理テーブルをメモリ上で管理する。

そこで、ＲＥＣ同期モードについて、既述のストレージシステム５０２では、ＲＥＣ機能の種類として、ソリューションを目的としたデータ保全（災害対策）等の同期モードがある。この同期モードでは、コピー先ボリューム８００に対する書き込みは、コピー元ボリューム７００と同期して行われる。書き込み（Write ）Ｉ／Ｏが発行された場合、コピー先ボリューム８００への転送（コピー処理）が完了した後で、ホスト５０８へのＩ／Ｏ完了報告を行う。なお、同期性を持ったコピーであるため、ホスト５０８からの書き込み順序は、コピー先ボリューム８００に対しても保証される。

同期モードのＩ／Ｏ処理手順は、第１に、Write Ｉ／Ｏの要求、第２に、リモートコピー転送、第３に、リモート転送完了、第４に、Write Ｉ／Ｏ完了通知で完了する。

災害対策等でＲＥＣ機能を使用したバックアップにおいて、コピー先ボリューム８００から更に別のディスク（Disk）又はテープに２次バックアップを行う運用がある。この場合、ＲＥＣ機能のコピー先ボリューム８００のフェーズが既述のEquivalentであることを確認する必要がある。Copying(初期コピー中) では、コピー先ボリューム８００は不完全なデータであるため、利用することができないからである。

２次バックアップ中にコピー元ボリューム７００からコピー先ボリューム８００へデータ転送が行われると、２次バックアップデータにコピー元ボリューム７００から転送されたデータが混在し意味を持たないデータとなってしまう。そのため、２次バックアップの作成はコピー元ボリューム７００からコピー先ボリューム８００への転送を中断した状態で行う。

ＲＥＣ機能のコピー先ボリューム８００から２次バックアップを作成する手順について、図３０を参照する。図３０は、２次バックアップを作成する処理手順を示すフローチャートである。

この処理手順は以下の通りである。

(1) ホスト５０８からストレージ（コピー元筐体５０４）へＲＥＣ開始コマンドが実行される（ステップＳ１１１）。

(2) ストレージは指定されたコピー元領域からコピー先領域へ初期コピーを開始する（ステップＳ１１２）。

この場合、ＲＥＣセッションを作成し、Status／ PhaseをActive／Copying に設定する。ＲＥＣセッションはストレージ内のメモリ上にセッション管理テーブルとして格納する。

(3) ホストよりストレージに対し、該当ＲＥＣセッションの状態確認コマンドの発行を行う（ステップＳ１１３）。

(4) ストレージはストレージ内の管理制御部のメモリ内のセッション管理テーブルの情報をホスト５０８へ通知する（ステップＳ１１４）。

(5) 初期コピーが完了するまで、ステップＳ１１３、Ｓ１１４を繰り返す（ステップＳ１１３〜Ｓ１１５）。

(6) 初期コピーが完了すると、該当セッションのフェーズをEquivalentへ変更し、ストレージ内の管理制御部のメモリ内のセッション管理テーブルに格納する（ステップＳ１１６）。

(7) ホスト５０８は該当ＲＥＣセッションのフェーズがEquivalentへ変更したことを確認後、２次バックアップを作成したいタイミングで転送中断（Suspend ）コマンドを発行する（ステップＳ１１７）。

(8) ホスト５０８よりSuspend コマンドを受信後、ストレージ装置は該当ＲＥＣセッションのStatusをSuspend へ変更し、セッション管理テーブルに格納し、ホスト５０８へ対してコマンド完了の通知を行う（ステップＳ１１８）。

(9) ホスト５０８よりストレージに対し、該当ＲＥＣセッションの状態確認コマンドの発行を行う（ステップＳ１１９）。

(10) ストレージはホスト５０８へストレージ内のセッション管理テーブルの情報を通知する（ステップＳ１２０）。

(11) ホスト５０８はストレージより通知されたステータスがSuspend ／Equivalentであることを確認し、コピー先ボリューム８００から２次バックアップを作成する（ステップＳ１２１）。これにより、処理を終了する。

次に、複数のＲＥＣにおけるバックアップでは、このようなデータベースシステム等の場合、ボリューム単位だけではなく、複数ボリューム（グループ）単位でデータの一貫性が必要な場合がある。例えば、データシステムのデータを複数のボリュームに分散して書き込み、グループ内のボリュームが揃わないと、データべースシステムの機能を果たせない場合である。

複数のＲＥＣセッションに対するコピー状態を確認するには、先に述べたＲＥＣセッションのステータスとフェーズの複数セッションに対して行う必要がある。

このような場合、ホストにおいてＲＥＣセッションをグルーピングし、そのグループを構成しているＲＥＣセッションに対してそれぞれ状態確認コマンドを発行し、ホスト５０８側で個々のＲＥＣセッションの結果をまとめ、グループとしてコピー先ボリュームの確認を行う。

ホスト５０８側でそのグループに対するコピー先の状態を確認するには、各ボリューム７００、８００のＲＥＣセッションのステータスとフェーズを、それぞれグループを構成するだけ確認する必要がある。

この比較例では、第１の課題として、ホスト５０８側においても、グループにおける各ＲＥＣセッションのステータス一覧の保持が必要である。

また、第２の課題として、グループを構成するＲＥＣセッションの数が多ければ多い程、ホスト５０８では各ＲＥＣセッションのステータスとフェーズの確認作業が増加し、処理時間が増大する。

また、ＲＥＣセッションのステータスとフェーズはストレージの内部処理又は異常検出により遷移する場合がある。グループを構成するＲＥＣセッションが多ければ多い程、既述の管理テーブルによる一貫性管理がなければ、確認処理の時間が増大することが予想される。ホスト５０８がグループ内のＲＥＣセッションの状態を確認中に、ストレージの内部処理あるいは異常検出によりステータスとフェーズが変更されるという不都合も予想される。しかも、ストレージの内部処理又は異常検出でＲＥＣのステータスが変更したときには、ホストへ対しステータスが変更されたことを通知しない。

このため、第３の課題として、ホスト５０８側で所持しているグループ内の各ＲＥＣのステータスとストレージ内で管理しているグループ内の各ＲＥＣのステータスがずれることが予想される。

グルーピングされたＲＥＣセッションに対して、コピー先のデータを更にバックアップすることができる（コピー先のグループとして一貫性が取れている）のは、全てのＲＥＣセッションがActive／Equivalent又はSuspend ／Equivalentとなった場合である。それぞれのボリューム毎に切り離しコマンドを個々に行うと、切り離しを行ったタイミングがずれる。

次に、このストレージシステム５０２において、あるストレージのボリュームの故障時はそのボリュームのみリモート転送が停止し、その他のボリュームのリモート転送が継続した場合について説明する。

バックアップサイトであるコピー先筐体５０６のデータは、グループ内の全てのＲＥＣセッションのステータスがSuspend ／Equivalentとあったとしても、複数のボリュームに跨がったコピー先ボリューム８００の一貫性を取ることができなくなり、グループとしての一貫性が失われる場合がある。

図３１は正常なコピー状態を示し、図３２は被災の場合を示す。図３１に示すように、ホスト５０８のデータベース（ＤＢ）にデータＡ→データＢ→データＣの順番に書き込み処理を行う。図３２には、データＣの書き込み時にボリューム７１２（ボリューム２）の故障が発生した事象を示す。データＣの書き込み処理においてボリューム２で故障が発生したため、ボリューム２に対するデータＣ−２の書き込みは失敗するが、ボリューム１、３への書き込みは成功する。

比較例のシステムにおいては、ストレージ側でそれぞれのボリュームに対するデータの関連付けは行っていないため、ボリューム２に対するデータＣ−２の書き込みに失敗しても、ボリューム１、ボリューム３は正常のため、データＣの書き込みを許可してしまう。そのため、分割されたデータの一部が不足しているのに拘わらず、処理が進んでしまい、コピー先筐体５０６側でのデータの一貫性が取れなくなる。

そのため、複数のボリュームをグループとして管理し、あるボリュームのリモート転送が行われなかった場合、グループ内の全ボリュームのリモート転送を即時に停止させる処理がある。

これらの処理によって、グループとしてとあるタイミングでの一括切り離し、又は障害が発生した時点によるグループ内ＲＥＣの一括切り離しが可能となる。

このとき、グループ内のＲＥＣ個々のセッションの状態を確認すると全てのセッションのステータスがSuspend となる。この際、ホストはストレージ装置に対してグループに属する全てのＲＥＣセッションの状態の取得を依頼し、ストレージ装置より渡された各ＲＥＣセッションのステータスとフェーズを確認し一貫性を確認する。

コピー元筐体５０４側のサイトで被災が発生し、業務をコピー先筐体５０６のサイトへ切り替えたとき、コピー先サイトにあるホストからはコピー先ストレージ装置のデータに一貫性があるか判断できない場合がある。ストレージ装置のディスク故障により、あるＲＥＣセッションのみ異常となり、該当グループが切り離された後、故障したディスクを復旧し、異常となったＲＥＣセッションを再起動したときに、筐体間の経路が切れたときである。即ち、第４の課題として、ボリューム単位ではコピーセッションの状態を確認することで一貫性の有無を判断できるが、グループ単位で一貫性があるかは判断できない。

(1) ストレージにおいて、ＲＥＣセッションが３つ存在しているとする。ホストは上記３つのＲＥＣセッションに対し、ホスト内部でグループ内のＲＥＣセッションの状態管理を行っていることを前提とする。この場合、ホスト内の状態管理手段は問わない。

図３３に示すように、それぞれのＲＥＣ同期セッションのステータスがActive、フェーズがEquivalentであるため、コピー元装置への書き込みは即座にコピー先装置に反映され、コピー元装置及びコピー先装置のディスクの中身は同一のものであることが保証できる状態である。

グループＧ内の全てのＲＥＣセッションのステータスとフェーズがActive／Equivalentである場合は、全てのＲＥＣセッションについてコピー元装置及びコピー先装置の等価が取れているため、グループとしても一貫性が保障された状態である。

(2) グルーピングされているＲＥＣ同期モードセッションにおいて、あるボリュームで故障が発生すると、ストレージは同一グループにおける全てのＲＥＣセッションを切り離し状態とする（図３４）。

故障発生前の時点で、グループ内の全てのＲＥＣセッションのステータスがActiveかつフェーズがEquivalentであるならば、故障が発生した時点での元ボリュームと先ボリュームの同一性が保障されている。また、故障発生以降にデータが書き込まれたとしても、コピー先装置へ転送されないため、そのグループにおける一貫性が保障される。この際、ホストからコピー元装置への書き込みが、故障のため、停止されるとする。

(3) 図３５に示すように、グループの一貫性が確認できた場合は、復旧に使用する等を行うため、コピー先装置筐体からそれぞれバックアップを取る。

(4) コピー元装置筐体の故障ディスクを復旧する。そのため、図３６に示すように、エラーとなったＲＥＣの設定を削除する。ＲＥＣ１の設定を削除した時点を表す。

(5) 図３７に示すように、ＲＥＣ１を削除した後、故障したコピー元ボリューム１を交換する。元ボリューム１を交換したことにより、元ボリューム１のデータは初期化される。

(6) 図３８に示すように、復旧したコピー元ボリューム１に対してバックアップしたデータを復旧する。復旧手段は特に問わない。

(7) 図３９に示すように、コピー元装置へのバックアップが完了したところで、コピー元装置筐体が復旧したため、ホストからコピー元装置筐体へのアクセスを許す。同時に、ＲＥＣセッションが削除されたため、コピー元装置ボリューム１からコピー先装置ボリューム１へのＲＥＣ１を再度開始する。ＲＥＣを開始すると、コピー元装置ボリュームのデータをコピー先装置へバックアップする。

図３９において、コピー元装置筐体への書き込みを許可したので、コピー元装置へは新データとなっている。ＲＥＣ２とＲＥＣ３はＲＥＣ１のバックアップが完了するまではSuspend のままとするリカバリ方法とする。

(8) 図４０に示すように、ＲＥＣ１の初期コピーが完了し、コピー元装置及びコピー先装置の等価が取れた状態となる。

この状態のときにＲＥＣ１はコピー元ボリュームとコピー先ボリュームの等価が取れている状態であるが、ＲＥＣ２とＲＥＣ３はコピー先装置のデータの内容は故障時のもので、コピー元の最新のデータが反映されていないことになる。

(9) 図４０に示す状態でストレージ装置の筐体間の経路が切れると、図４１に示すように、全てのＲＥＣセッションがSUSPEND となる。

この状態で各ＲＥＣセッションの状態をセッション毎の状態表示コマンドで確認すると、セッションステータスはSUSPEND であり、コピー元装置とコピー先装置の状態が切り離されている状態である。また、セッションのフェーズは全てEquivalentであり、SUSPEND となった瞬間のコピー元装置とコピー先装置の等価状態が保障されている状態となる。

この状態は各セッションのステータスとフェーズの判断では、図３４に示す状態と区別できない。しかし、ＲＥＣ１とＲＥＣ２、３のSUSPEND となった時間帯が異なるため、コピー先のデータの一貫性が取れていない。

そこで、比較例のグループ毎の一貫性状態確認処理について、図４２を参照する。図４２は、比較例のグループ毎の一貫性状態確認処理の処理シーケンスを示す図である。

比較例では、ホスト５０８からグループを構成するＲＥＣセッション除法の取得要求がストレージに対して発せられる（ステップＳ２０１）。これを受けたストレージではＲＥＣセッション毎にセッション情報の複数の獲得処理が実行される（ステップＳ２０２）。この処理に基づき、多数のセッション情報通知が発せられ、ホスト５０８に通知される（ステップＳ２０３）。ホスト５０８では、一貫性の確認処理として、取得した複数のセッション情報を確認し、グループに対する一貫性を確認する（ステップＳ２０４）。このような処理手順では、ホスト５０８側の処理の負荷が大きく、時間的なロスも大である。

この比較例で挙げた第１ないし第４の課題及び一貫性の確認処理について、上記実施の形態のストレージシステム及びストレージ制御方法では、グループの状態を表す一貫性テーブルの生成、一貫性ステータスの管理及び通知により全て解決されている。

〔他の実施の形態〕

(1) 上記実施の形態では、ストレージ側にある記憶部１４、２４にステータス情報記憶領域１５、２５や、一貫性ステータステーブル１２２を生成させているが、これに限定されない。ホスト８、１０側の記憶部に同様にステータス情報記憶領域１５、２５や、一貫性ステータステーブル１２２を生成させ、ストレージ側と同期してステータス情報を監視し管理する構成としてもよい。

(2) 上記実施の形態では、複数のコピーセッションのグループ化を契機にストレージ側に一貫性ステータステーブルを生成しているが、これに限定されない。コピーセッションのグループ化の契機とは、グループ化が予想される場合には、予め一貫性ステータステーブルを生成させておいてもよい。その場合、そのステータステーブルに一貫性ステータス情報を格納すればよい。

次に、以上述べた実施例を含む実施の形態に関し、更に以下の付記を開示する。以下の付記に本発明が限定されるものではない。

（付記１） コピー元筐体からコピー先筐体にデータをコピーするストレージシステムであって、
複数に分割されたデータをストレージに格納する際の前記データのグループ化に基づき、ステータス情報を格納するステータス情報記憶領域を前記ストレージ側の記憶部に生成させる記憶領域生成部を備え、前記記憶部に生成させた前記ステータス情報記憶領域にグループ毎の前記ステータス情報を格納することを特徴とするストレージシステム。

（付記２） 前記ステータス情報を通知する通知手段を備え、該通知手段は、前記コピー元筐体又は前記コピー先筐体に接続されたホストに前記ステータス情報を通知することを特徴とする付記１に記載のストレージシステム。

（付記３） 前記ステータス情報記憶領域は、前記記憶部に作成される管理テーブルに格納されたグループ情報で関係付けられていることを特徴とする付記１に記載のストレージシステム。

（付記４） コピー元筐体からコピー先筐体にデータをコピーするストレージ制御方法であって、
複数に分割されたデータをストレージに格納する際の前記データのグループ化に基づき、ステータス情報を格納するステータス情報記憶領域を前記ストレージ側の記憶部に生成させるステップと、
前記記憶部に生成させた前記ステータス情報記憶領域にグループ毎の前記ステータス情報を格納するステップと、
を含むことを特徴とするストレージ制御方法。

（付記５） 更に、前記コピー元筐体又は前記コピー先筐体に接続されたホストに前記ステータス情報を通知するステップと、
を含むことを特徴とする付記４に記載のストレージ制御方法。

以上説明したように、ストレージシステム及びストレージ制御方法の最も好ましい実施の形態等について説明したが、本発明は、上記記載に限定されるものではなく、特許請求の範囲に記載され、又は発明を実施するための形態に開示された発明の要旨に基づき、当業者において様々な変形や変更が可能であることは勿論であり、斯かる変形や変更が、本発明の範囲に含まれることは言うまでもない。

２ ストレージシステム
４ コピー元筐体
６ コピー先筐体
８、１０ ホスト
１４、２４ 記憶部
１５、２５ ステータス情報記憶領域
５０、７０、９０ 中央制御部
６４、８４、１０４ メモリ
１２２ 一貫性ステータステーブル

Claims (5)

1. コピー元筐体からコピー先筐体にデータをコピーするストレージシステムであって、
   複数に分割されたデータをストレージに格納する際の前記データのグループ化に基づき、ステータス情報を格納するステータス情報記憶領域を前記ストレージ側の記憶部に生成させる記憶領域生成部を備え、前記記憶部に生成させた前記ステータス情報記憶領域にグループ毎の前記ステータス情報を格納することを特徴とするストレージシステム。
   
2. 前記ステータス情報を通知する通知手段を備え、該通知手段は、前記コピー元筐体又は前記コピー先筐体に接続されたホストに前記ステータス情報を通知することを特徴とする請求項１に記載のストレージシステム。
   
3. 前記ステータス情報記憶領域は、前記記憶部に作成される管理テーブルに格納されたグループ情報で関係付けられていることを特徴とする請求項１に記載のストレージシステム。
   
4. コピー元筐体からコピー先筐体にデータをコピーするストレージ制御方法であって、
   複数に分割されたデータをストレージに格納する際の前記データのグループ化に基づき、ステータス情報を格納するステータス情報記憶領域を前記ストレージ側の記憶部に生成させるステップと、
   前記記憶部に生成させた前記ステータス情報記憶領域にグループ毎の前記ステータス情報を格納するステップと、
   を含むことを特徴とするストレージ制御方法。
   
5. 更に、前記コピー元筐体又は前記コピー先筐体に接続されたホストに前記ステータス情報を通知するステップと、
   を含むことを特徴とする請求項４に記載のストレージ制御方法。

Images