JPWO2015198449A1 - ストレージシステム - Google Patents

Abstract

本発明のストレージシステムは、それぞれが１以上のボリュームを有する第１ストレージ装置と第２ストレージ装置と、第１ストレージ装置と第２ストレージ装置がアクセス可能な第３ストレージ装置とから構成される。ストレージシステムは、ホストから第１または第２ストレージ装置内のボリュームに対して書き込まれたデータを、第２または第１ストレージ装置のボリュームに複製するよう動作する。また第１ストレージ装置と第２ストレージ装置は、定期的に第３ストレージ装置に対してヘルスチェック情報を書き込む。第１ストレージ装置がホストからライト要求を受信したが、ライトデータを第２ストレージ装置へ複製できなかった場合、第３ストレージ装置に書き込まれているヘルスチェック情報を読み出し、第２ストレージ装置のボリュームがＩ／Ｏ不可になっていることを確認した後、ホストからのライト要求に係る処理を再開する。

Description

本発明は、ストレージシステムの高可用化技術に関する。

現在、多くのストレージ装置では、たとえばＲＡＩＤ（Ｒｅｄｕｎｄａｎｔ Ａｒｒａｙｓ ｏｆ Ｉｎｄｅｐｅｎｄｅｎｔ （ｏｒ Ｉｎｅｘｐｅｎｓｉｖｅ） Ｄｉｓｋｓ）技術等の高信頼化技術を採用することで、ＨＤＤ単体の信頼性を超えた信頼性を提供している。しかし、近年の情報化社会の進化によって上記ＲＡＩＤ技術による提供可能な信頼性では不足する場面も現れてきている。

このような状況に対応する高可用化技術として、たとえば特許文献１に開示されているように、複数（たとえば２台）のストレージ装置（以下、装置Ａ、装置Ｂと呼ぶ）を用いた情報システムを構築し、装置Ａと装置Ｂとの間でデータを二重化する技術がある。特許文献１に開示の情報システムでは、装置Ａと装置Ｂでボリュームを二重書きし、ホストは通常、装置Ａのボリュームにアクセスする構成をとる。そしてホストが装置Ａのボリュームへのアクセス（Ｉ／Ｏ処理）に失敗した場合、装置Ｂのボリュームにアクセスするよう、アクセス先を切り替えることで、業務継続を可能にしている。

このような二重化構成のシステムで求められる要件の１つに、ホストが誤ったデータにアクセスすることを防止できることが挙げられる。特許文献１では、装置Ａと装置Ｂの間のリンクが切断された結果、装置Ａと装置Ｂの間のボリューム二重化（コピー）が失敗した場合の例について開示されている。この場合、ホストが装置Ａのボリュームを用いた運用をしばらく行った後、装置Ａに障害が発生したために、ホストＡが装置Ｂへのアクセスに切り替えることが考えられる。ただしその時点では装置Ｂのボリュームには、装置Ａのボリュームよりも古いデータしか格納されていないため、ホストからのアクセスを受け付けないように制御することが望ましい。

特許文献１に開示の情報システムでは、装置Ａと装置Ｂが共通にアクセスできる障害検出用ボリュームを設け、それを用いることでこの問題を解決している。装置Ａがボリューム二重化の処理に失敗すると、装置Ａは障害検出用ボリュームの内容を読み出し、装置Ｂによって障害情報フラグが書き込まれているかチェックする。障害情報フラグが書き込まれていない場合には、装置Ａが障害検出フラグを書き込み、その後ホストからのアクセス要求に係る処理を再開する。

さらに装置Ａに障害が発生した場合、ホストは装置Ａから装置Ｂへとアクセス先を切り替える。そうすると装置Ｂは障害検出用ボリュームの内容を読み出し、装置Ａによって障害情報フラグが書き込まれているかチェックする。この場合、障害情報フラグが書き込まれているので、装置ＢはホストにＩ／Ｏ失敗を返却する。これにより、ホストが古いデータを読み出すことを防止している。

米国特許第８５９５５４９号明細書

特許文献１に開示されているようなシステム構成は、いわゆるＡｃｔｉｖｅ／Ｓｔａｎｄｂｙ構成と呼ばれる。Ａｃｔｉｖｅ／Ｓｔａｎｄｂｙ構成のシステムでは、一方の装置（たとえば装置Ｂ）は待機系の装置である。ホストは通常、装置Ａのボリュームにアクセスする構成をとる。

一方、ボリュームを二重化するシステムの用途として、上で挙げたような障害時の業務継続の他に、負荷分散等の用途もあり得る。上で説明したものと同じように、装置Ａと装置Ｂでボリュームが二重書きされる構成のシステムにおいて、ホストが装置Ａと装置Ｂに交互にアクセス要求を発行するように運用できると、負荷が装置Ａと装置Ｂに分散され、アクセス性能が向上する。このようなオペレーションが可能な構成は、Ａｃｔｉｖｅ／Ａｃｔｉｖｅ構成と呼ばれる。

この場合、ホストが装置Ｂのボリュームにアクセスしても、装置Ａ内のボリュームと装置Ｂ内のボリュームが二重化された状態が、継続されることが求められる。特許文献１に開示されているようなＡｃｔｉｖｅ／Ｓｔａｎｄｂｙ構成のシステムでは、ホストが装置Ａにアクセスできなくなるまで、装置Ｂはホストからアクセスされないことを前提として構成されている。そのため、ホストが装置Ｂ内のボリュームにアクセスすると、たとえシステムのどこにも異常がない場合であっても、装置Ａ内のボリュームと装置Ｂ内のボリュームが二重化された状態が維持されない（データ二重化処理が停止する）ので、特許文献１に開示の技術では、負荷分散用途には利用できない。

本発明の一実施形態に係るストレージシステムは、それぞれが１以上のボリュームを有する第１ストレージ装置と第２ストレージ装置と、第１ストレージ装置と第２ストレージ装置がアクセス可能な第３ストレージ装置とから構成される。ストレージシステムは、ホストから第１または第２ストレージ装置内のボリュームに対して書き込まれたデータを、第２または第１ストレージ装置のボリュームに複製するよう動作する。

また第１ストレージ装置と第２ストレージ装置は、定期的に第３ストレージ装置に対してヘルスチェック情報を書き込む。第１ストレージ装置がホストからライト要求を受信したが、ライトデータを第２ストレージ装置へ複製できなかった場合、第３ストレージ装置に書き込まれているヘルスチェック情報の内容に基づいて、第２ストレージ装置のボリュームがＩ／Ｏ不可状態にあるか否かを判断し、Ｉ／Ｏ不可状態にあると判断した後、ライト要求に係る処理を再開する。

本発明のストレージシステムでは、Ａｃｔｉｖｅ／Ａｃｔｉｖｅ構成の運用を可能にするとともに、障害時に適切な対応を取ることが可能である。

実施例に係る計算機システムの構成図である。 ストレージ装置が、ホストからのデータ書き込み要求を受け付けた時の処理の概要を説明する図である。 ストレージシステムの別の構成例である。 ストレージ装置のメモリに格納されているプログラムと管理情報を示す図である。 ペア管理テーブルの内容を示す図である。 ＬＤＥＶステータス情報の内容を示す図である。 Ｑｕｏｒｕｍ Ｄｉｓｋに格納される情報を説明する図である。 ＤＫＣ管理情報に格納される情報の内容を示す図である。 ライト処理のフローチャートである。 ライト処理のフローチャートである。 リシンク処理のフローチャートである。 ヘルスチェック処理のフローチャートである。 Ｑｕｏｒｕｍ使用のヘルスチェック／ペア状態変更処理プログラムのフローチャートである。 無応答判定処理のフローチャート（１）である。 無応答判定処理のフローチャート（２）である。 Ｍ−Ｒ間通信障害通知受領処理のフローチャート（１）である。 Ｍ−Ｒ間通信障害通知受領処理のフローチャート（２）である。 Ｍ−Ｒ間通信障害通知受領処理のフローチャート（３）である。 Ｍ−Ｒ間通信障害通知受領処理のフローチャート（４）である。 通信不能ビットマップ編集処理のフローチャート（１）である。 通信不能ビットマップ編集処理のフローチャート（２）である。 更新世代番号設定処理のフローチャートである。 自ＤＫＣペア状態変更処理のフローチャートである。 リード処理のフローチャートである。

以下、図面を参照して、本発明の一実施形態に係るストレージシステムを説明する。なお、本発明は、以下に説明する実施形態に限定されるものではない。

（１） システムの構成
図１は、本発明の一実施形態に係る計算機システムの構成例を示す。計算機システムは、ストレージシステム１とホスト２から構成される。ストレージシステム１は、ストレージ装置１０ａ、ストレージ装置１０ｂ、Ｑｕｏｒｕｍ Ｓｔｏｒａｇｅ１５からなる。

ストレージ装置１０ａは、ＳＡＮ６を介してホスト２やストレージ装置１０ｂと接続される。ＳＡＮ６は、たとえばファイバチャネル規格に従う伝送線（ケーブル）やスイッチ等を用いて構成されるネットワークである。同様にストレージ装置１０ｂも、ＳＡＮ６を介してホスト２やストレージ装置１０ａと接続される。なお、ホスト２とストレージ装置１０間を接続する経路（パス）と、ストレージ装置１０同士（ストレージ装置１０ａとストレージ装置１０ｂ）を接続する経路とを区別するため、以下ではストレージ装置１０同士を接続する経路のことを、「ストレージ装置間パス」または「ＤＫＣ間パス」と呼ぶ。

ストレージ装置１０ａは、ストレージコントローラ（以下、「コントローラ」と略記することもある）１１と複数のドライブ１２１を備えるディスクユニット１２から構成される。ストレージコントローラ１１は、ストレージ装置１０ａで行われるＩ／Ｏ処理などの制御を実行するプロセッサボードであるＭＰＢ１１１、ホスト２やストレージ装置１０ｂとのデータ転送インタフェースであるフロントエンドパッケージ（ＦＥＰＫ）１１２、ディスクユニット１２とのデータ転送インタフェースであるバックエンドパッケージ（ＢＥＰＫ）１１３、キャッシュデータや制御情報などを格納するメモリを備えたメモリパッケージ（ＣＭＰＫ）１１４が、スイッチ（ＳＷ）１１５で相互接続された構成をとる。各構成要素（ＭＰＢ１１１、ＦＥＰＫ１１２、ＢＥＰＫ１１３、ＣＭＰＫ１１４）の数は、図１に示された数に限定されるものではないが、高可用性の確保のため、通常各構成要素は複数存在する。また、これら構成要素を後で増設することも可能である。

各ＭＰＢ１１１は、プロセッサ（ＭＰとも呼ばれる）１４１と、当該プロセッサ１４１が使用するデータを格納するローカルメモリ（ＬＭ）１４２を有する、パッケージボードである。図１ではＭＰＢ１１１に１つのＭＰ１４１だけが搭載されている例が示されているが、ＭＰ１４１の数は１に限定されない。またストレージ装置１０ａは時計（非図示）を有し、ＭＰ１４１は時計から現在時刻情報を取得することができる。なお、時計はＭＰ１４１に内蔵されている構成でもよい。

ＣＭＰＫ１１４は、ＳＭ１４３とＣＭ１４４を有する。ＣＭ１４４は、ホスト２からのライトデータやドライブ１２１から読み出されたデータを一時格納する、いわゆるディスクキャッシュとして用いられる領域である。ＳＭ１４３は、ＭＰＢ１１１が使用する制御情報等を格納する領域である。ＳＭ１４３に格納される情報は、全ＭＰＢ１１１の全ＭＰ１４１からアクセス可能である。ＣＭＰＫ１１４は、停電等の障害が発生した場合のデータ消失を防ぐために、バッテリバックアップ等の手段を備えていることが好ましい。

ＦＥＰＫ１１２は、他の機器（ホスト２やストレージ装置１０ｂ）に対するデータ送受信を行うためのパッケージボードであり、ＳＡＮ６に接続するためのインタフェースを１以上有する。インタフェースには、一例としてファイバチャネルインタフェースが用いられる。図１では、ストレージ装置１０ａとストレージ装置１０ｂが１本の伝送線を介して接続されているが、実際にはストレージ装置１０ａとストレージ装置１０ｂは複数の伝送線で接続される。また、ホスト２とストレージ装置１０間の伝送線の数も、図１に示されている構成に限定されない。複数の伝送線がホスト２とストレージ装置１０間に設けられてよい。

ＢＥＰＫ１１３は、ドライブ１２１とのデータ送受信を行うためのパッケージボードであり、ディスクユニット１２に接続するためのインタフェースを１以上有する。インタフェースには、一例としてＳＡＳ（Ｓｅｒｉａｌ Ａｔｔａｃｈｅｄ ＳＣＳＩ）が用いられる。

ディスクユニット１２には複数のドライブ１２１を備え、各ドライブ１２１には主にホスト２からのライトデータが格納される。ドライブ１２１には、一例としてＨＤＤなどの磁気ディスクが用いられるが、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等、ＨＤＤ以外の記憶媒体を用いてもよい。

ストレージ装置１０ｂは、ストレージ装置１０ａと同様の構成要素を有する装置である（図１では内部構成の記載を省略している）。ただし、各構成要素（ＭＰＢ１１１、ＦＥＰＫ１１２、ドライブ１２１等）の数はストレージ装置１０ａと同じである必要はない。以下、ストレージ装置１０ａ、ストレージ装置１０ｂが共通に備えている機能等を説明する場合、ストレージ装置１０ａ、ストレージ装置１０ｂを区別せず、「ストレージ装置１０」と表記する。

Ｑｕｏｒｕｍ Ｓｔｏｒａｇｅ１５は、ストレージ装置１０ａとストレージ１０ｂとに接続される。Ｑｕｏｒｕｍ Ｓｔｏｒａｇｅ１５の詳細は後述する。

ホスト２は少なくとも、プロセッサ、メモリ、そしてＳＡＮ６に接続するためのインタフェースであるＨＢＡ（Ｈｏｓｔ Ｂｕｓ Ａｄａｐｔｅｒ）を備えた計算機である。プロセッサは、メモリ３０２に格納されたプログラムを実行する。ホスト２上では、一例としてデータベース管理システム（ＤＢＭＳ）等のアプリケーションプログラムが実行され、ストレージ装置１０に格納されたデータにアクセスする。

（２） 動作概要
続いて、ストレージシステム１で行われる、ホスト２からのＩ／Ｏ要求に係る処理の概要を説明する。まずストレージ装置１０がホスト２に提供するボリュームについて説明する。ストレージ装置１０は、自身のディスクユニット１２に存在する複数のドライブ１２１の記憶領域を用いて１以上の論理ボリューム（ボリューム、またはＬＤＥＶとも呼ばれる）を形成する。またストレージ装置１０は、各論理ボリュームに一意な識別番号（論理ボリューム番号またはＬＤＥＶ＃）を付して管理している。そしてホスト２には、この論理ボリュームを提供する。論理ボリュームの形成方法、及び形成された論理ボリュームをホスト２に提供する方法は、公知のストレージ装置で行われているものと同じである。

また実施例に係るストレージシステム１では原則として、ホスト２からのライトデータは、ストレージ装置１０ａの論理ボリュームとストレージ装置１０ｂの論理ボリュームの両方に書き込まれる（いわゆるデータ二重化が行われる）。図２を用いて、ストレージシステム１で行われるデータ二重化の概要を説明する。

データ二重化は、ストレージ装置１０によって実施される。図２の実線は、ストレージ装置１０ａがホスト２からライト要求及びライトデータを受信した時のライトデータの流れを表している。たとえばストレージ装置１０ａがホスト２から、論理ボリューム１２５ａに対するライト要求及びライトデータを受信すると、ストレージ装置１０ａは自身が有する論理ボリューム１２５ａにライトデータを格納する。同時にストレージ装置１０ａはストレージ装置１０ｂに対して、当該ライトデータの複製、及び当該ライトデータの複製を論理ボリューム１２５ｂに書き込む旨の指示（ライト要求）を送信することで、ストレージ装置１０ｂに、当該ライトデータの複製を論理ボリューム１２５ｂに格納させる。

また本発明の実施例に係る計算機システムでは、ホスト２がストレージ装置１０ｂに対してライト要求を発行した場合にも、データ二重化が行われる。図２の点線は、ストレージ装置１０ｂがホスト２からライト要求及びライトデータを受信した時のライトデータの流れを表している。つまり、ストレージ装置１０ｂがホスト２からライト要求及びライトデータを受信すると、論理ボリューム１２５ｂと論理ボリューム１２５ａの両方にライトデータが格納される。

このように、本発明の実施例に係る計算機システムでは、論理ボリューム１２５ｂと論理ボリューム１２５ａには、ストレージシステム１に障害が発生した等の理由でデータ二重化ができない場合を除き、両方に同じデータが格納された状態（同期状態と呼ばれる）にある。そのためホスト２は、論理ボリューム１２５ａと論理ボリューム１２５ｂのいずれにアクセス（リードまたはライト）してもよい。

なお、２つの論理ボリューム（論理ボリューム１２５ａと論理ボリューム１２５ｂ）に対するデータの書き込み順は、論理ボリュームに設定された一種の属性情報によって決められている。最初にデータが書き込まれる論理ボリュームのことはプライマリボリューム（Ｐ−ＶＯＬと表記されることもある）と呼ばれ、２番目にデータが書き込まれる論理ボリュームのことはセカンダリボリューム（Ｓ−ＶＯＬと表記されることもある）と呼ばれる。図２は、論理ボリューム１２５ａがＰ−ＶＯＬ、そして論理ボリューム１２５ｂがＳ−ＶＯＬと定められている場合の例を示している。

また、論理ボリューム１２５ａと論理ボリューム１２５ｂがそれぞれ、異なるストレージ装置１０にある論理ボリュームであることは、少なくともホスト２のアプリケーション５０２には認識されない。本発明の実施例に係る計算機システムでは、論理ボリューム１２５ａと論理ボリューム１２５ｂのボリューム識別子を同じにすることで、論理ボリューム１２５ａと論理ボリューム１２５ｂが同一のボリュームであると、ホスト２の交替パスソフト５０１に認識させるようにしている。

図２の構成において、ホスト２では交替パスソフト５０１が稼働している。交替パスソフト５０１は、ホスト２から論理ボリュームへのアクセス経路（パスと呼ばれる）が複数存在する場合にそれを認識し、論理ボリュームにアクセスする際に、複数のパスのうち、使用するパスを選択する機能を持つ。パスの認識のために、交替パスソフト５０１は、ホスト２から認識できている論理ボリュームに対して、ＳＣＳＩ規格で規定されているＩＮＱＵＩＲＹコマンド等、ボリュームの識別情報を取得するコマンドを発行することによって、ボリューム識別子を取得する。

ストレージ装置１０ａが論理ボリューム１２５ａに対するＩＮＱＵＩＲＹコマンドを受信した時、またストレージ装置１０ｂが論理ボリューム１２５ｂに対するＩＮＱＵＩＲＹコマンドを受信した時は、いずれも同一のボリューム識別子をコマンドの送信元（ホスト２）に返却するように構成されている。そのため交替パスソフト５０１は論理ボリューム１２５ａと論理ボリューム１２５ｂが同一のボリュームと認識する。結果として、ホスト２から論理ボリューム１２５ａへのパス（図中の、ホスト２から論理ボリューム１２５ａに至る実線矢印。以下このパスを「パス１」と呼ぶ）の交替パスが、ホスト２から論理ボリューム１２５ｂへのパス（図中の、ホスト２から論理ボリューム１２５ｂに至る点線矢印。以下このパスを「パス２」と呼ぶ）であると判断する。そしてパス１が障害により遮断された場合、あるいはパス１が混雑している場合などには、交替パスソフト５０１がアプリケーションプログラム５０２などから論理ボリューム１２５へのアクセス要求を受け付けると、交替パスソフト５０１はパス２を介してアクセス要求を発行する（つまり論理ボリューム１２５ｂにアクセス要求を発行する）。そして交替パスソフト５０１が論理ボリューム１２５ｂにアクセス要求を発行しても、論理ボリューム１２５ｂには論理ボリューム１２５ａと同一データが格納されているため、問題なく動作する。

（３） Ｑｕｏｒｕｍ Ｄｉｓｋ
続いて、ストレージ装置１０とＱｕｏｒｕｍ Ｓｔｏｒａｇｅ１５との関係について説明する。Ｑｕｏｒｕｍ Ｓｔｏｒａｇｅ１５は、少なくとも１つのボリュームを有するストレージデバイスである。またストレージ装置１０は、ＦＥＰＫ１１２のインタフェースにＱｕｏｒｕｍ Ｓｔｏｒａｇｅ１５等のストレージデバイスが接続された場合、当該ストレージデバイスが有するボリュームにアクセス（リードやライト）できる機能を有している。以下、本実施例では、Ｑｕｏｒｕｍ Ｓｔｏｒａｇｅ１５は１つのボリュームを有しているとする。そしてこのボリュームのことを、「Ｑｕｏｒｕｍ Ｄｉｓｋ」と呼ぶ。

ストレージ装置１０ａは定期的にＱｕｏｒｕｍ Ｄｉｓｋに情報を書き込む。情報の詳細な内容については後述するが、ここで書き込まれる情報は一種のヘルスチェック情報であり、ストレージ装置１０ａが動作中である（障害等の要因で停止していない）ことを示す情報が含まれる。また他のストレージ装置１０（ストレージ装置１０ｂ等）との通信の結果、通信が失敗した等の情報も含まれる。そしてストレージ装置１０ｂは、ストレージ装置１０ａの状態を判断するために、定期的にＱｕｏｒｕｍ Ｄｉｓｋから情報を読み出す。同様にストレージ装置１０ｂも、定期的にＱｕｏｒｕｍ Ｄｉｓｋに情報を書き込む。そしてストレージ装置１０ａは、ストレージ装置１０ｂの状態を判断するために、定期的にこの書き込まれた情報を読み出す。

なお、上では、Ｑｕｏｒｕｍ Ｓｔｏｒａｇｅ１５がストレージ装置１０のＦＥＰＫ１１２のインタフェースに接続される構成について説明したが、ストレージシステム１の構成はこの構成に限定されるものではない。要は、ストレージ装置１０ａ、１０ｂがいずれも、Ｑｕｏｒｕｍ Ｄｉｓｋにアクセス可能になるように、接続されればよい。たとえば上で説明したものとは別の実施形態として、ストレージ装置１０のＢＥＰＫ１１３を介してＱｕｏｒｕｍ Ｓｔｏｒａｇｅ１５が接続されるように構成されてもよい。

また、Ｑｕｏｒｕｍ Ｓｔｏｒａｇｅ１５のハードウェア構成は、ストレージ装置１０と同じハードウェア構成であってもよいし、異なるハードウェア構成であってもよい。また、図１では、ストレージ装置１０ａ（またはストレージ装置１０ｂ）とＱｕｏｒｕｍ Ｓｔｏｒａｇｅ１５が１本の伝送線を介して接続された構成が示されているが、ストレージ装置１０ａ（またはストレージ装置１０ｂ）とＱｕｏｒｕｍ Ｓｔｏｒａｇｅ１５との間の伝送線が複数存在する構成でも良い。

また、以下では、２つのストレージ装置１０（ストレージ装置１０ａと１０ｂ）がＱｕｏｒｕｍ Ｓｔｏｒａｇｅ１５に接続された構成について中心に説明がなされるが、２台より多くのストレージ装置１０がＱｕｏｒｕｍ Ｓｔｏｒａｇｅ１５に接続される構成であってもよい。たとえば図３に示されているように、ストレージ装置１０ａ、１０ｂ、１０ｃがＱｕｏｒｕｍ Ｓｔｏｒａｇｅ１５に接続された構成をとることもできる。

（４） 管理情報の構成
続いて、図４〜図６を用いて、ストレージ装置１０が有する管理情報の内容について説明する。本実施例のストレージ装置１０は少なくとも、ペア管理情報Ｔ３００とＬＤＥＶステータス情報Ｔ４００という管理情報をＳＭ１４３に格納している。また、ＳＭ１４３には、ＤＫＣ管理情報ステージングエリア２００’、Ｑｕｏｒｕｍ格納時刻領域２５０という領域が設けられている。ＤＫＣ管理情報ステージングエリア２００’には、Ｑｕｏｒｕｍ Ｄｉｓｋ上に格納されているＤＫＣ管理情報（後述）が一時格納（ステージング）される。そして、Ｑｕｏｒｕｍ格納時刻領域２５０には、ＭＰ１４１がＱｕｏｒｕｍ Ｄｉｓｋ上のＤＫＣ管理情報を更新した時の時刻が格納される。なお、本実施例では、これらの情報がＳＭ１４３に格納されていて、ＭＰ１４１はＳＭ１４３にアクセスすることで上記情報の参照更新を行う例について説明するが、アクセス性能向上のために、ＳＭ１４３に格納されている情報の一部をＬＭ１４２に複製（キャッシング）しておき、ＭＰ１４１はＬＭ１４２上にキャッシングされた情報にアクセスするようにしてもよい。

ペア管理情報Ｔ３００について説明する。先に述べたとおり、ストレージシステム１では原則として、ホスト２からのライトデータを２つの論理ボリュームに格納する。たとえばストレージ装置１０ａが、ホスト２から論理ボリューム１２５ａに対するライト要求及びライトデータを受信すると、ストレージ装置１０ａの論理ボリューム１２５ａとストレージ装置１０ｂの論理ボリューム１２５ｂとにライトデータが格納される。

図５にペア管理テーブルＴ３００の構成を示す。ペア管理テーブルＴ３００の各行には、１つのボリュームペアの情報が格納される。本明細書では、Ｐ−ＶＯＬと、当該Ｐ−ＶＯＬの複製が書き込まれるＳ−ＶＯＬのペアのことを、「ボリュームペア」と呼ぶ。また、あるＰ−ＶＯＬの複製が格納されるＳ−ＶＯＬは、「Ｐ−ＶＯＬとペア関係にあるボリューム」あるいは「Ｐ−ＶＯＬのペアボリューム」と呼ばれる。逆に、あるＳ−ＶＯＬの複製元データが格納されている論理ボリュームであるＰ−ＶＯＬのことも、「Ｓ−ＶＯＬとペア関係にあるボリューム」、「Ｓ−ＶＯＬのペアボリューム」と呼ばれる。ストレージ装置１０では各ペアに、ペア番号（Ｐａｉｒ＃）と呼ばれる識別子を付して管理しており、Ｐａｉｒ＃（Ｔ３０１）にはペア番号が格納される。そして、ＰＤＫＣ＃（Ｔ３０３）、Ｐ−ＶＯＬ＃（Ｔ３０４）には、ボリュームペアに属するＰ−ＶＯＬの情報（Ｐ−ＶＯＬの属するストレージ装置の製番（シリアル番号）であるＰＤＫＣ＃、Ｐ−ＶＯＬのＬＤＥＶ＃）が格納される。またＳＤＫＣ＃（Ｔ３０５）、Ｓ−ＶＯＬ＃（Ｔ３０６）には、ボリュームペアに属するＳ−ＶＯＬの情報（Ｓ−ＶＯＬの属するストレージ装置を特定可能な識別番号であるＳＤＫＣ＃、Ｓ−ＶＯＬのＬＤＥＶ＃）が格納される。

Ｐａｉｒ Ｓｔａｔｕｓ（Ｔ３０２）には、ボリュームペアの状態（ペアステータス）が格納される。ペアステータスについては後述する。また変更中フラグ（Ｔ３０７）はペアステータスを変更する必要がある際、１（ＯＮ）が設定され、それ以外の場合には０（ＯＦＦ）が設定される。具体的な使われ方は後述する。

ペアステータスについて説明する。各ボリュームペアは、以下に説明するいずれかの状態を有する。これらの状態のことを本明細書では「ペアステータス」と呼ぶ。

（ａ）Ｉｎｉｔｉａｌ−Ｃｏｐｙ状態：
ストレージシステム１は、ボリュームペアを形成する際、最初にＰ−ＶＯＬの内容をすべてＳ−ＶＯＬへとコピーする処理（初期コピー処理と呼ばれる）を行う。この処理中の状態のことを「Ｉｎｉｔｉａｌ−Ｃｏｐｙ状態」と呼ぶ。

（ｂ）Ｄｕｐｌｅｘ状態：
初期コピー処理または後述する再同期処理により、Ｐ−ＶＯＬの内容とＳ−ＶＯＬの内容が同一になったボリュームペアの状態を「Ｄｕｐｌｅｘ状態」と呼ぶ。

（ｃ）Ｓｕｓｐｅｎｄ状態：
Ｐ−ＶＯＬの内容がＳ−ＶＯＬに反映されない状態のことを「Ｓｕｓｐｅｎｄ状態」と呼ぶ。たとえばストレージ装置１０ａとストレージ装置１０ｂを接続する伝送線が遮断されて、コピーが不可能になった場合に、ボリュームペアは「Ｓｕｓｐｅｎｄ状態」になる。あるいはユーザからの指示によって、ボリュームペアが「Ｓｕｓｐｅｎｄ状態」になることもある。なお、ボリュームペアを「Ｓｕｓｐｅｎｄ状態」にする処理のことを、サスペンド（Ｓｕｓｐｅｎｄ）処理と呼ぶ。

（ｄ）Ｄｕｐｌｅｘ−Ｐｅｎｄｉｎｇ状態：
ボリュームペアが、Ｓｕｓｐｅｎｄ状態からＤｕｐｌｅｘ状態に遷移するまでの過渡状態にある場合、そのボリュームペアの状態は「Ｄｕｐｌｅｘ−Ｐｅｎｄｉｎｇ状態」と呼ばれる。この状態の時、Ｓｕｓｐｅｎｄ状態にあったボリュームペアについて、Ｐ−ＶＯＬとＳ−ＶＯＬの内容を一致（同期）させるため、Ｐ−ＶＯＬ（またはＳ−ＶＯＬ）のデータがＳ−ＶＯＬ（またはＰ−ＶＯＬ）へとコピーされる。コピーが完了した時点で、そのボリュームペアの状態は「Ｄｕｐｌｅｘ状態」になる。なお、「Ｓｕｓｐｅｎｄ状態」のボリュームペアをＤｕｐｌｅｘ状態に遷移させる処理のことを、再同期処理（リシンク処理）と呼ぶ。

ペア管理テーブルＴ３００のＰａｉｒ Ｓｔａｔｕｓ（Ｔ３０２）には、上で説明した４つの状態のいずれかが格納される。Ｐａｉｒ Ｓｔａｔｕｓ（Ｔ３０２）に０が格納されている場合、ボリュームペアの状態が「Ｉｎｉｔｉａｌ−Ｃｏｐｙ状態」であることを表し、１が格納されている場合、ボリュームペアの状態が「Ｄｕｐｌｅｘ状態」であることを表す。またＰａｉｒ Ｓｔａｔｕｓ（Ｔ３０２）に２が格納されている場合、ボリュームペアの状態が「Ｓｕｓｐｅｎｄ状態」であることを表し、３が格納されている場合、ボリュームペアの状態が「Ｄｕｐｌｅｘ−Ｐｅｎｄｉｎｇ状態」であることを表す。

なお、上では「Ｉｎｉｔｉａｌ−Ｃｏｐｙ状態」と「Ｄｕｐｌｅｘ−Ｐｅｎｄｉｎｇ状態」がそれぞれ別な状態であるとして説明した。ただしボリュームペアが「Ｉｎｉｔｉａｌ−Ｃｏｐｙ状態」または「Ｄｕｐｌｅｘ−Ｐｅｎｄｉｎｇ状態」である時、いずれもＰ−ＶＯＬとＳ−ＶＯＬの内容が同期中であるという点で一致している。そのため、必ずしも２つの状態を分けて管理する必要はなく、１つの状態として管理するようにしてもよい。

続いて、Ｓｕｓｐｅｎｄ状態にあるボリュームペアについて、やや詳細に説明する。ボリュームペアがＳｕｓｐｅｎｄ状態に変更される理由は１つではない。たとえば上で説明したように、ストレージ装置１０ａとストレージ装置１０ｂを接続する伝送線が遮断された場合もあり得るが、それ以外に、ストレージ装置１０ａまたは論理ボリューム１２５ａに障害が発生して、論理ボリューム１２５ａにアクセスできなくなった場合、またはストレージ装置１０ｂまたは論理ボリューム１２５ｂに障害が発生して、論理ボリューム１２５ｂにアクセスできなくなった場合があり得る。

たとえばストレージ装置１０ａに障害が発生したが、ストレージ装置１０ｂは正常な状態にある場合には、論理ボリューム１２５ｂはホスト２からアクセス可能であるべきである。逆にストレージ装置１０ｂに障害が発生したが、ストレージ装置１０ａは正常な状態にある場合には、論理ボリューム１２５ａはホスト２からアクセス可能であるべきである。そのためストレージ装置１０は、各論理ボリュームのアクセス可否についての情報を管理しておくことが必要である。ＬＤＥＶステータス情報Ｔ４００は各論理ボリュームのアクセス可否状態を管理するために用いられる。

図６にＬＤＥＶステータス情報Ｔ４００の一例を示す。Ｓｔａｔｕｓ（Ｔ４０２）には、ＬＤＥＶ＃（Ｔ４０１）で特定される論理ボリュームの状態が格納される。本明細書では、論理ボリュームがホスト２からアクセス可能な状態にある場合、当該論理ボリュームの状態は「Ｖａｌｉｄ状態」と呼ばれる。逆に論理ボリュームがホスト２からアクセス可能でない状態の場合（たとえば論理ボリュームに障害が発生した場合）、当該論理ボリュームの状態は「Ｉｎｖａｌｉｄ状態」または「閉塞状態」と呼ばれる。

Ｓｔａｔｕｓ（Ｔ４０２）には、０または１のいずれかの状態をとり得る。０の場合、論理ボリュームの状態が「Ｖａｌｉｄ状態」であることを表し、１の場合、論理ボリュームの状態が「Ｉｎｖａｌｉｄ状態」であることを表す。なお、ボリュームペアのペアステータスが“Ｄｕｐｌｅｘ状態”の場合には、当該ボリュームペアに属するＰ−ＶＯＬ及びＳ−ＶＯＬの状態はいずれも「Ｖａｌｉｄ状態」である。

ＬＤＥＶステータス情報Ｔ４００は、各ストレージ装置１０が有している情報である。そして１つのＬＤＥＶステータス情報Ｔ４００には、当該ＬＤＥＶステータス情報Ｔ４００が格納されているストレージ装置１０の有する論理ボリュームについての情報のみが格納される（たとえばストレージ装置１０ｂの有するＬＤＥＶステータス情報Ｔ４００には、ストレージ装置１０ｂの有する論理ボリュームのステータスだけが格納される）。

次に、図７、８を用いて、Ｑｕｏｒｕｍ Ｄｉｓｋに格納される情報の内容について説明する。先に述べたとおり、ストレージ装置１０は定期的にＱｕｏｒｕｍ Ｄｉｓｋに情報を格納する。またストレージ装置１０は定期的に、Ｑｕｏｒｕｍ Ｄｉｓｋに格納された情報の参照を行う。

Ｑｕｏｒｕｍ Ｓｔｏｒａｇｅ１５には、最大でｎ台（ｎはあらかじめ定められている固定値で、２以上の整数値である。一例としてｎ＝１６である）のストレージ装置１０が接続される。Ｑｕｏｒｕｍ Ｓｔｏｒａｇｅ１５に接続されたストレージ装置１０はそれぞれ、Ｑｕｏｒｕｍ Ｄｉｓｋ内の所定の領域に情報を書き込むように制御される。そのため、Ｑｕｏｒｕｍ Ｄｉｓｋ内には、Ｑｕｏｒｕｍ Ｓｔｏｒａｇｅ１５に接続されるストレージ装置１０の最大数（ｎ台）と同数の管理情報格納領域が設けられている。

図７を用いて管理情報格納領域について説明する。Ｑｕｏｒｕｍ Ｄｉｓｋには、ＤＫＣ配列割当表２０１という領域と、ＤＫＣ管理情報格納領域２０２という領域が設けられている。この領域が設けられる位置は、あらかじめ定められている（たとえば領域の先頭は、ボリュームの先頭（０番地）に位置するなど）。初期状態ではいずれの領域にもデータが書き込まれていない（全領域に、たとえば０が書き込まれている）。このうち、ＤＫＣ管理情報格納領域２０２内が、各ストレージ装置１０が定期的に情報を格納する領域である。

図７に示されているように、ＤＫＣ管理情報格納領域２０２は、ＤＫＣ管理情報［０］（２０２−０）、ＤＫＣ管理情報［１］（２０２−０）、．．．、ＤＫＣ管理情報［ｎ−１］（２０２−（ｎ−１））の、ｎ個の部分領域に区分されている。各ストレージ装置１０が定期的に情報を書き込む場合、ＤＫＣ管理情報［０］（２０２−０）〜ＤＫＣ管理情報［ｎ−１］（２０２−（ｎ−１））のいずれか１つの領域に情報を書き込む。

各ストレージ装置１０が情報を書き込む領域は、「Ｑｕｏｒｕｍ Ｄｉｓｋへの登録処理」と呼ばれる処理が行われることによって決定される。この処理はたとえば、ストレージシステム１に１または複数台のストレージ装置１０を導入した場合に、ユーザが管理端末などを用いて、Ｑｕｏｒｕｍ Ｄｉｓｋへの登録処理を行うことを、導入したストレージ装置１０に対して指示することで実行される。そして指示を受けたストレージ装置１０のＭＰ１４１は、ＬＭ１４２に格納されているＤＫＣ登録プログラム１００２を実行する。ＤＫＣ登録プログラム１００２が実行されると、ＭＰ１４１はＱｕｏｒｕｍ ＤｉｓｋのＤＫＣ配列割当表２０１に格納されている情報の内容に基づいて、ストレージ装置１０が情報を書き込む領域を決定する。

以下、決定方法の具体的内容を説明する。ＤＫＣ配列割当表２０１には、図４に示されているように、製番［０］（２０１−０）〜製番［ｎ−１］（２０１−（ｎ−１））の領域が設けられている。Ｑｕｏｒｕｍ Ｓｔｏｒａｇｅ１５に接続されたストレージ装置１０によって、Ｑｕｏｒｕｍ Ｄｉｓｋへの登録処理が行われるたびに、ストレージ装置１０は、製番［０］（２０１−０）〜製番［ｎ−１］（２０１−（ｎ−１））のうち、内容が０である領域の中で最も先頭に近い領域に、製番を格納する。たとえば製番［０］〜製番［（ｋ−１）］（ｋは、１≦ｋ＜ｎを満たす整数値）に、すでに非０の値が格納されていた場合には、Ｑｕｏｒｕｍ Ｄｉｓｋへの登録処理を実行するストレージ装置１０は、製番［ｋ］（２０１−ｋ）に、製番を格納する。そしてこのストレージ装置１０は、情報を書き込む際には、ＤＫＣ管理情報［ｋ］（２０２−ｋ）を使用する（ＤＫＣ管理情報［ｋ］（２０２−ｋ）の内容を更新する）と決定される。

Ｑｕｏｒｕｍ Ｄｉｓｋへの登録処理は、上のような方法で行われるため、（ｋ＋１）番目にＱｕｏｒｕｍ Ｄｉｓｋへの登録処理を実行したストレージ装置１０は、ＤＫＣ管理情報［ｋ］に情報の書き込みを行うと決定される。以下、ＤＫＣ管理情報［ｋ］（２０２−ｋ）に情報書き込みを行うストレージ装置１０（製番［ｋ］（２０１−ｋ）に、製番を格納したストレージ装置１０である、ともいえる）のことを、「ＤＫＣ＃ｋ」と表記する。また、この値ｋは、「配列番号」（または「配列＃」）と呼ばれることもある。

またＤＫＣ＃ｋは、ＤＫＣ管理情報［０］（２０２−０）〜ＤＫＣ管理情報［ｎ−１］（２０２−［ｎ−１］）の全ての情報を参照する。ただしＤＫＣ＃ｋは、Ｑｕｏｒｕｍ Ｄｉｓｋに情報を格納する際、ＤＫＣ管理情報［ｋ］（２０２−ｋ）のみしか更新しない。つまり各ストレージ装置１０が同一領域にデータを書き込むことはないため、各ストレージ装置１０がＱｕｏｒｕｍ Ｄｉｓｋを読み書きする際、必ずしも排他制御を行う必要はない。

なお、図７では、各ＤＫＣ管理情報［ｋ］は、Ｑｕｏｒｕｍ Ｄｉｓｋ上に連続して配置されているが、必ずしも各ＤＫＣ管理情報［ｋ］が連続して配置されている必要はない。ストレージ装置１０がＤＫＣ管理情報［ｋ］をＱｕｏｒｕｍ Ｄｉｓｋから読み出す、またはＱｕｏｒｕｍ Ｄｉｓｋに書き出す際に、各ＤＫＣ管理情報［ｋ］の読み出し／書き出し対象のアドレスが一意に特定できるような配置方法であればよい。たとえば各ＤＫＣ管理情報［ｋ］の先頭が、ボリュームの最小アクセス単位であるブロック（たとえば５１２バイト）の先頭に位置するように配置してもよい。

続いて、ＤＫＣ管理情報［ｋ］に格納される情報の内容について、図８を用いて説明する。ＤＫＣ管理情報［ｋ］には少なくとも、図８に示されているように、製番（２０２０）、更新世代番号（２０２１）、通信不能ビットマップＡ（２０２２）、通信不能ビットマップＢ（２０２３）、閉塞了承ビットマップ（２０２４）、応答不能ビットマップＡ（２０２５）、応答不能ビットマップＢ（２０２６）、回復中ビットマップ（２０２７）、前回世代［０］（２０２８−０）〜前回世代［ｎ−１］（２０２８−［ｎ−１］）、前回時刻［０］（２０２９−０）〜前回時刻［ｎ−１］（２０２９−［ｎ−１］）の情報が格納される。

製番（２０２０）には、ＤＫＣ＃ｋの製番が格納される。そのため製番（２０２０）には、ＤＫＣ配列割当表２０１の製番［ｋ］（２０１−ｋ）に格納されている値と同じ値が格納される。

更新世代番号（２０２１）には、ＤＫＣ＃ｋがＤＫＣ管理情報［ｋ］に情報を格納した回数に相当する値が格納される。詳細は後述するが、ストレージ装置１０の運用中、ＤＫＣ＃ｋはＤＫＣ管理情報［ｋ］への情報格納を繰り返し実行する。そして、ＤＫＣ＃ｋはＤＫＣ管理情報［ｋ］へ情報を格納するたびに、更新世代番号（２０２１）に格納する値を１ずつ加算する（たとえば今回の格納処理で、更新世代番号（２０２１）にｍを格納した場合、次回の格納処理の際には、（ｍ＋１）が更新世代番号（２０２１）に格納される）。

通信不能ビットマップＡ（２０２２）は、ｎビットの情報で、各ビットが、ＤＫＣ＃ｋとその他のストレージ装置１０との間のパス（ＤＫＣ間パス）を介した通信が可能か否かを表す。ＤＫＣ＃ｋが、ＤＫＣ＃ｋとＤＫＣ＃ｊ（ｊは、０≦ｊ≦（ｎ−１）を満たす整数値で、かつｊ≠ｋの関係にある）間のパスを介して、ＤＫＣ＃ｊと通信できない状態にあることを検知した時（これはたとえば、ＤＫＣ＃ｋからＤＫＣ＃ｊへのデータ転送が失敗した場合等である）、ＤＫＣ＃ｋは通信不能ビットマップＡ（２０２２）のｊビット目の情報に１を格納する（逆にＤＫＣ＃ｊとＤＫＣ＃ｊ間のパスを介した通信が不可能な状態にあることを検知していない場合には、当該ビットには０が格納される）。詳細は後述する。

以下では、ビットマップのあるビットに「１」が格納された状態を、ビットが「ＯＮである」と呼び、あるビットに「０」が格納された状態を、ビットが「ＯＦＦである」と呼ぶ。また上で述べたとおり、ｊ≠ｋの関係にあるので、ＤＫＣ管理情報［ｋ］の通信不能ビットマップＡ（２０２２）の各ビットのうち、ｋ番目のビットは使用されない。

通信不能ビットマップＢ（２０２３）も通信不能ビットマップＡ（２０２２）と同様に、ｎビットの情報で、ＤＫＣ＃ｋとその他のストレージ装置１０との間のパスの状態に関係する情報である。ＤＫＣ＃ｋが、「ＤＫＣ＃ｊが、ＤＫＣ＃ｊとＤＫＣ＃ｋ間のパスを介した通信が不可能な状態にあることを検知した」という事実を検知した時、ＤＫＣ＃ｋは通信不能ビットマップＢ（２０２３）のｊビット目の情報に１を格納する。詳細は後述する。

閉塞了承ビットマップ（２０２４）もｎビットの情報である。ＤＫＣ＃ｋが、「ＤＫＣ＃ｊが、ＤＫＣ＃ｊとＤＫＣ＃ｋ間のパスを介した通信が不可能な状態にあることを検知した」という事実を検知し、且つその時のＤＫＣ＃ｊとＤＫＣ＃ｋとでペア関係にあるボリュームについて、ＤＫＣ＃ｋのボリュームをＩｎｖａｌｉｄ状態にすることが決定された場合、ＤＫＣ＃ｋは通信不能ビットマップＢ（２０２３）のｊビット目の情報に１を格納する。なお、本実施例では、ボリュームの状態をＩｎｖａｌｉｄ状態にすることを、「閉塞する」と呼ぶこともある。

応答不能ビットマップＡ（２０２５）も、ｎビットの情報で、各ビットは、ストレージ装置１０が障害等の要因で停止したため、Ｑｕｏｒｕｍ Ｄｉｓｋへの情報書き込みを行うヘルスチェック処理が行えない状態になっているか否か、を表す。ＤＫＣ＃ｊが所定時間以上の間、Ｑｕｏｒｕｍ Ｄｉｓｋへの情報書き込みを行っていないことを、ＤＫＣ＃ｋが検知した時、かつ、ＤＫＣ＃ｋの通信不能ビットマップＡ（２０２２）のｊビット目の情報に１が格納されている時、ＤＫＣ＃ｋは応答不能ビットマップＡ（２０２５）のｊビット目の情報に１を格納する。この状態の場合、ストレージ装置１０が停止状態であるため、ホスト２から論理ボリュームに対するＩ／Ｏ要求も受け付けられない状態にある。

応答不能ビットマップＢ（２０２６）も応答不能ビットマップＡ（２０２５）と同様のｎビットの情報であり、ＤＫＣ＃ｋ以外のストレージ装置１０がＤＫＣ＃ｋの状態を検知した時の情報が格納される。「ＤＫＣ＃ｋが所定時間以上の間、Ｑｕｏｒｕｍ Ｄｉｓｋへの情報書き込みを行っていないことを、ＤＫＣ＃ｊが検知した」という事実を、ＤＫＣ＃ｋが検知した時、ＤＫＣ＃ｋは応答不能ビットマップＢ（２０２６）のｊビット目の情報に１を格納する。詳細は後述する。

回復中ビットマップ（２０２７）は、リシンク処理中であることを表す情報である。ＤＫＣ＃ｋがＤＫＣ＃ｊとの間でリシンク処理を実行中の状態である場合、ＤＫＣ＃ｋは回復中ビットマップ（２０２７）のｊビット目の情報に１を格納する。

前回世代［０］（２０２８−０）〜前回世代［ｎ−１］（２０２８−［ｎ−１］）、前回時刻［０］（２０２９−０）〜前回時刻［ｎ−１］（２０２９−［ｎ−１］）は、ＤＫＣ＃ｋが、ＤＫＣ管理情報［ｊ］（ただしｊ≠ｋ）に格納されている更新世代番号（２０２１）の情報を参照した時に用いられる。ＤＫＣ＃ｋはＤＫＣ管理情報格納領域２０２の内容を更新する際、ＤＫＣ管理情報［ｋ］（２０２−ｋ）のみしか更新しないことになっている。ただしＤＫＣ＃ｋは、ＤＫＣ管理情報［０］（２０２−０）〜ＤＫＣ管理情報［ｎ−１］（２０２−［ｎ−１］）の全ての情報を参照することは可能である。そしてＤＫＣ＃ｋは、ＤＫＣ管理情報［０］（２０２−０）〜ＤＫＣ管理情報［ｎ−１］（２０２−［ｎ−１］）を参照することで、他のストレージ装置１０が正常に動作しているか否かを判定する。ＤＫＣ＃ｋが、ＤＫＣ管理情報［ｊ］（ただしｊ≠ｋ）の更新世代番号（２０２１）を参照した時、その情報を、ＤＫＣ管理情報［ｋ］の前回世代［ｊ］に格納する。

ＤＫＣ管理情報［ｋ］の前回時刻［ｊ］には、ＤＫＣ＃ｋが、ＤＫＣ管理情報［ｊ］の更新世代番号（２０２１）を参照した時の時刻を格納する。詳細は後述する。

（５） 処理の流れ
続いて、ストレージシステム１で実行される処理の流れを説明していく。以下で説明する処理は、ストレージ装置１０のＭＰ１４１が、ＬＭ１４２上に格納されているプログラムを実行することによって行われる。ストレージ装置１０のＭＰ１４１で実行されるプログラムについて、図４を用いて説明する。

図４では、ＬＭ１４２上に格納されているプログラムが示されている。ＬＭ１４２上には、Ｉ／Ｏプログラム１００１、ＤＫＣ登録プログラム１００２、ミラーリングプログラム１００３、リシンクプログラム１００４、ヘルスチェックプログラム１００５、Ｑｕｏｒｕｍ使用のヘルスチェック／ペア状態変更処理プログラム１００６が存在する。

Ｉ／Ｏプログラム１００１は、ストレージ装置１０がホスト２から論理ボリュームへのアクセス要求を受信した時に実行されるプログラムである。ＤＫＣ登録プログラム１００２は、先に説明したとおり、Ｑｕｏｒｕｍ Ｄｉｓｋへの登録処理の際に実行されるプログラムである。Ｑｕｏｒｕｍ Ｄｉｓｋへの登録処理は上で説明済みであるので、以下では説明を省略する。

ミラーリングプログラム１００３は、データ二重化（Ｐ−ＶＯＬとＳ―ＶＯＬにデータを書き込む）を行う時に実行されるプログラムである。たとえばＰ−ＶＯＬに書き込まれたデータをＳ−ＶＯＬにも書き込むときに、Ｉ／Ｏプログラム１００１から呼び出されて実行される。

リシンクプログラム１００４は、Ｓｕｓｐｅｎｄ状態のボリュームペアをＤｕｐｌｅｘ状態に変更する際に実行されるプログラムである。またリシンクプログラム１００４は、ユーザからの指示を受けて、開始される。

ヘルスチェックプログラム１００５は、後述するヘルスチェック処理を行うためのプログラムである。ヘルスチェックプログラム１００５は、Ｑｕｏｒｕｍ Ｄｉｓｋに格納された情報を参照することで、各ストレージ装置１０の状態を判定し、判定結果をＱｕｏｒｕｍ Ｄｉｓｋに書き込む処理を行う。

Ｑｕｏｒｕｍ使用のヘルスチェック／ペア状態変更処理プログラム１００６は、上で説明した各プログラムから呼び出される形で実行される。以下、Ｑｕｏｒｕｍ使用のヘルスチェック／ペア状態変更処理プログラム１００６が実行されることで行われる処理のことを、「Ｑｕｏｒｕｍ使用のヘルスチェック／ペア状態変更処理」と呼ぶ。

各プログラムがＱｕｏｒｕｍ使用のヘルスチェック／ペア状態変更処理プログラム１００６を呼び出す時（以下、Ｑｕｏｒｕｍ使用のヘルスチェック／ペア状態変更処理プログラム１００６を呼び出すプログラムのことを、「呼び出し元プログラム」と呼ぶ）、呼び出し元プログラムは少なくとも、以下の２つのパラメータをＱｕｏｒｕｍ使用のヘルスチェック／ペア状態変更処理プログラム１００６に渡す。

１つ目のパラメータは、「処理種別」と呼ばれる。処理種別には、「障害サスペンド」、「リシンク」、「ヘルスチェック」の３種類があり、呼び出し元プログラムは、このいずれか１つを１つめのパラメータとして指定する。

２つ目のパラメータは、処理対象ストレージ装置の製番である。ただし、２つ目のパラメータは指定されないこともある。その場合呼び出し元プログラムは、２つ目のパラメータとして「０」を、Ｑｕｏｒｕｍ使用のヘルスチェック／ペア状態変更処理プログラム１００６に渡す。Ｑｕｏｒｕｍ使用のヘルスチェック／ペア状態変更処理プログラム１００６が実行する処理の詳細は後述する。

続いて、ストレージ装置１０がホスト２からＰ−ＶＯＬに対するライト要求を受け付けた時に、ＭＰ１４１がＩ／Ｏプログラムを実行することに行われる処理の流れを、図９、図１０を用いて説明する。

ストレージ装置１０がホスト２から論理ボリュームに対するライト要求を受け付けると、ホスト２がストレージ装置１０に対して発行するライト要求（ライトコマンド）には、論理ユニット番号（ＬＵＮ）等の、アクセス対象の論理ボリュームを特定する情報が含まれている。ＭＰ１４１がホスト２からのライト要求を受信すると、このライト要求に含まれているアクセス対象論理ボリュームを特定する情報をもとに、アクセス対象論理ボリュームを特定する。続いてペア管理情報Ｔ３００を参照し、アクセス対象論理ボリュームがＰ−ＶＯＬであるかＳ−ＶＯＬであるかを判定する。

アクセス対象論理ボリュームがＰ−ＶＯＬであると判定された場合の処理の流れについて、図９を用いて説明する。ＭＰ１４１は、ペア管理情報Ｔ３００を参照することで、アクセス対象論理ボリュームのペアステータスを確認する（Ｓ１）。ペアステータスがＤｕｐｌｅｘまたはＩｎｉｔｉａｌ ＣｏｐｙまたはＤｕｐｌｅｘ Ｐｅｎｄｉｎｇ状態でない場合（Ｓ１：Ｎ）には、データを二重化しない（Ｐ−ＶＯＬのみに書き込む）。そのため、ＭＰ１４１はＰ−ＶＯＬにデータを書き込む処理のみを実行し（Ｓ９）、処理を終了する。なお、Ｓ９でＭＰ１４１は、ＬＤＥＶステータス情報Ｔ４００を参照することで、論理ボリュームの状態を確認する。論理ボリュームの状態がＩｎｖａｌｉｄ状態である場合、ホスト２にエラーを返却して処理を終了する。

Ｓ１の判定でペアステータスがＤｕｐｌｅｘまたはＩｎｉｔｉａｌ ＣｏｐｙまたはＤｕｐｌｅｘ Ｐｅｎｄｉｎｇ状態であった場合（Ｓ１：Ｙ）、Ｓ２以降の処理が行われる。Ｓ２ではＭＰ１４１はＰ−ＶＯＬへのデータ書き込み処理を実行する。

Ｓ３でＭＰ１４１は、Ｐ−ＶＯＬとペア関係にあるＳ−ＶＯＬが存在するストレージ装置１０（以下、これを相手側ストレージ装置と呼ぶ）に対して、ライト要求を発行し、相手側ストレージ装置から、処理結果の応答情報を受信する。相手側ストレージ装置では、受信したライト要求に基づいて、Ｓ−ＶＯＬへのライト処理を実行し、ライト処理が完了した時点で、ライト要求発行元のストレージ装置（Ｐ−ＶＯＬの存在するストレージ装置）に処理が完了した応答を（処理が成功した場合には「成功」を）返却する。

相手側ストレージ装置における処理結果が「成功」であった場合（Ｓ４：Ｙ）、ホスト２に対し、ライト処理が終了した旨を応答し（Ｓ５）、処理を終了する。相手側ストレージ装置における処理結果が「成功」でなかった場合（Ｓ４：Ｎ。これにはたとえば、相手側ストレージ装置が停止しており、所定時間内に相手側ストレージ装置から処理結果が返却されなかった場合、あるいはＤＫＣ間パスが遮断されて、相手側ストレージ装置にライト要求を送信できなかった場合が含まれる）、Ｓ１０以降の処理が行われる。

Ｓ１０では、ＭＰ１４１はペア管理テーブルＴ３００の中で、相手側ストレージ装置との間でペア関係にある全てのボリュームペアについて、変更中フラグ（Ｔ３０７）を１にする。

Ｓ１１ではＭＰ１４１は、Ｑｕｏｒｕｍ使用のヘルスチェック／ペア状態変更処理プログラム１００６を呼び出すことによって、障害サスペンド処理を実行する。この時ＭＰ１４１は、Ｑｕｏｒｕｍ使用のヘルスチェック／ペア状態変更処理プログラム１００６に対して、処理種別と対象ストレージ装置の製番という２つの情報を、パラメータとして渡す。Ｓ１１ではＭＰ１４１は、処理種別として「障害サスペンド」を、対象ストレージ装置の製番には、相手側ストレージ装置の製番を指定する。処理の詳細は後述する。

Ｓ１２ではＭＰ１４１は、ストレージ装置１０内のボリュームペアの状態を参照する。Ｓ１２でボリュームペアの状態を参照した結果、全ボリュームペアの状態変更が完了したか判定する（Ｓ１３）。具体的には、ペア管理テーブルＴ３００を参照し、変更中フラグ（Ｔ３０７）が全て０であれば、全ボリュームペアの状態変更が完了したと判定する。

Ｓ１３の判定の結果、全ボリュームペアの状態変更が完了している場合（Ｓ１３：終わり）、ホストに応答を返却して（Ｓ５）、処理を終了する。全ボリュームペアの状態が変更されていない場合（Ｓ１３：処理中）、所定時間待機し（Ｓ１４）、再びＳ１１の処理を実行する。

なお、上で説明した処理の流れは、原則としてボリュームペアの状態がＤｕｐｌｅｘ状態またはＳｕｓｐｅｎｄ状態という、一種の定常状態にある場合の例である。ペアステータスがＩｎｉｔｉａｌ ＣｏｐｙまたはＤｕｐｌｅｘ Ｐｅｎｄｉｎｇ状態のように、過渡状態にある場合には若干異なる処理になる。

Ｓ３において、ペアステータスがＩｎｉｔｉａｌ ＣｏｐｙまたはＤｕｐｌｅｘ Ｐｅｎｄｉｎｇ状態の場合、Ｐ−ＶＯＬ、Ｓ−ＶＯＬ間のデータコピー（以下、バックグラウンドコピーと呼ぶ）が並行して実施されている。ライト要求でライト対象となっている領域が、バックグラウンドコピー処理でコピー済みの場合には、上で説明した処理（Ｓ３）と同じこと（相手側ストレージ装置にライト要求を発行）を行うが、ライト対象の領域がバックグラウンドコピー処理でコピー済みでない場合には、Ｓ３の処理は行わず、ホストに処理成功を返答して、図９の処理を終了する。これは、バックグラウンドコピー処理でライト対象の領域がいずれＳ−ＶＯＬにコピーされるからである。

また、ペアステータスがＩｎｉｔｉａｌ ＣｏｐｙまたはＤｕｐｌｅｘ Ｐｅｎｄｉｎｇ状態の場合に、Ｓ３で相手側ストレージ装置にライト要求を発行した結果、相手側ストレージ装置における処理結果が「成功」でなかった時（Ｓ４：Ｎ）は、アクセス対象のボリューム（ボリュームペア）のペアステータス（Ｐａｉｒ Ｓｔａｔｕｓ（Ｔ３０２））を「Ｓｕｓｐｅｎｄ」状態に、またＰ−ＶＯＬのステータス（Ｓｔａｔｕｓ（Ｔ４０２））は「Ｖａｌｉｄ」状態にして、処理を終了する。これは、Ｉｎｉｔｉａｌ ＣｏｐｙまたはＤｕｐｌｅｘ Ｐｅｎｄｉｎｇ状態では、Ｐ−ＶＯＬの内容がＳ−ＶＯＬにすべて反映されていない状態で、Ｓ−ＶＯＬのデータが有効なデータではないからである。

一方、アクセス対象論理ボリュームがＳ−ＶＯＬであると判定された場合の処理の流れについて、図９を用いて説明する。ＭＰ１４１は、ペア管理情報Ｔ３００を参照することで、アクセス対象論理ボリュームのペアステータスを確認する（Ｓ１）。ペアステータスがＤｕｐｌｅｘ状態でない場合（Ｓ１：Ｎ）には、データを二重化しない（Ｓ−ＶＯＬのみに書き込む）ため、Ｓ−ＶＯＬにデータを書き込む処理のみを実行し（Ｓ９’）、処理を終了する。またＳ９’でＭＰ１４１は、ＬＤＥＶステータス情報Ｔ４００を参照することで、論理ボリュームの状態を確認する。論理ボリュームの状態がＩｎｖａｌｉｄ状態である場合、ホスト２にエラーを返却して処理を終了する。なお、ペアステータスがＩｎｉｔｉａｌ ＣｏｐｙまたはＤｕｐｌｅｘ Ｐｅｎｄｉｎｇ状態の場合、Ｓ−ＶＯＬの状態（Ｓｔａｔｕｓ（Ｔ４０２））はＩｎｖａｌｉｄ状態に設定されている（Ｐ−ＶＯＬと同一のデータが格納されてない、つまり有効なデータが格納されていない）ため、ホスト２にエラーを返却して処理を終了する。

Ｓ１の判定でペアステータスがＤｕｐｌｅｘ状態であった場合（Ｓ１：Ｙ）、Ｓ３’以降の処理が行われる。Ｓ３’ではＭＰ１４１はＳ−ＶＯＬとペア関係にあるＰ−ＶＯＬが存在するストレージ装置１０（以下、これを相手側ストレージ装置と呼ぶ）に対して、ライト要求を発行し、相手側ストレージ装置から、処理結果の応答情報を受信する。

相手側ストレージ装置における処理結果が「成功」であった場合（Ｓ４：Ｙ）、ＭＰ１４１はＳ−ＶＯＬへのデータ書き込み処理を実行し（Ｓ２’）、ホスト２に対し、ライト処理が終了した旨を応答し（Ｓ５）、処理を終了する。相手側ストレージ装置における処理結果が「成功」でなかった場合（Ｓ４：Ｎ）、Ｓ１１以降の処理が行われる。Ｓ１１〜Ｓ１４は、図９で説明したものと同様である。

なお、図９、１０を用いて説明したように、ボリュームペアを構成するいずれのボリューム（Ｐ−ＶＯＬまたはＳ−ＶＯＬ）に対して書き込みが行われた場合でも、Ｐ−ＶＯＬとＳ−ＶＯＬの両方にデータが書き込まれる（二重書きされる）ため、ホスト２はデータを読み出す場合には、ストレージ装置１０ａ（Ｐ−ＶＯＬ）、ストレージ装置１０ｂ（Ｓ−ＶＯＬ）のいずれにアクセスしても良い。

一方、ストレージ装置１０ａ（Ｐ−ＶＯＬ）がホスト２からリード要求を受け付けた場合には、ストレージ装置１０ａはＰ−ＶＯＬから読み出したデータをホスト２に返送し、ストレージ装置１０ｂ（Ｓ−ＶＯＬ）がホスト２からリード要求を受け付けた場合には、ストレージ装置１０ｂはＳ−ＶＯＬから読み出したデータをホスト２に返送する。この時、リード要求でリード対象となっているボリュームがＳ−ＶＯＬであった場合であっても、Ｓ−ＶＯＬからのデータリードのみが行われ、Ｐ−ＶＯＬに対するアクセスは行われない。

続いて図１１を用いて、ストレージ装置１０がユーザから再同期（リシンク）の指示を受信した時に行われる処理の流れを説明する。この時ＭＰ１４１ではリシンクプログラム１００４が実行され、以下で説明する処理が行われる。

Ｓ３１でＭＰ１４１は、ユーザからリシンク指示を受信する。ユーザはホスト２（または管理端末）から、ストレージ装置１０に対してリシンク指示を発行することができる。またリシンク指示には、再同期させたいボリュームペアの情報（Ｐ−ＶＯＬまたはＳ−ＶＯＬの識別子）が含まれている。ＭＰ１４１はペア管理情報Ｔ３００を参照し、リシンク指示に含まれているボリュームペアのペアステータスを確認する。

Ｓ３１で確認したペアステータスが、「Ｓｕｓｐｅｎｄ状態」でなかった場合には（Ｓ３２：ＯＫ）、ボリュームペアの再同期ができないため、ホスト２（または管理端末）にエラーを返却し（Ｓ３４）、処理を終了する。Ｓ３１で確認したペアステータスが、「Ｓｕｓｐｅｎｄ状態」であった場合には（Ｓ３２：ＯＫ）、ＭＰ１４１はＱｕｏｒｕｍ使用のヘルスチェック／ペア状態変更処理プログラム１００６を呼び出す（Ｓ３３）。

ここでＱｕｏｒｕｍ使用のヘルスチェック／ペア状態変更処理プログラム１００６に渡されるパラメータのうち、処理種別としては「リシンク」が渡される。また対象ストレージ装置の製番には、ペア関係にあるボリュームが存在するストレージ装置１０の製番が渡される。たとえばストレージシステム１の構成として、ストレージ装置１０ａにＰ−ＶＯＬが、ストレージ装置１０ｂにＳ−ＶＯＬが存在しており、ストレージ装置１０ａがリシンク指示を受け付けた場合、ストレージ装置１０ｂの製番を、Ｑｕｏｒｕｍ使用のヘルスチェック／ペア状態変更処理プログラム１００６の引数として渡す。

Ｓ３３の処理が完了すると、リシンク処理は終了する。

続いて図１２を用いて、ヘルスチェック処理について説明する。ヘルスチェック処理は、ＭＰ１４１がヘルスチェックプログラム１００５を実行することで行われる。ヘルスチェックプログラム１００５が開始されると、ＭＰ１４１はＱｕｏｒｕｍ使用のヘルスチェック／ペア状態変更処理プログラム１００６を呼び出す（Ｓ４１）。Ｓ４１でＱｕｏｒｕｍ使用のヘルスチェック／ペア状態変更処理プログラム１００６に渡されるパラメータのうち、処理種別としては「ヘルスチェック」が指定され、対象ストレージ装置の製番には、０が指定される。その後、所定時間（一例として５００ｍｓ）待機し（Ｓ４２）、再びＭＰ１４１はＳ４１を実行することを繰り返す。これにより、定期的にＱｕｏｒｕｍ使用のヘルスチェック／ペア状態変更処理プログラム１００６が実行される。

以上のように、Ｉ／Ｏ（ライト）処理が行われる時、ボリュームペアの再同期処理が行われる時、及びヘルスチェック処理が行われる時に、Ｑｕｏｒｕｍ使用のヘルスチェック／ペア状態変更処理プログラム１００６が呼び出される（実行される）。以下では、Ｑｕｏｒｕｍ使用のヘルスチェック／ペア状態変更処理プログラム１００６によって実行される処理の流れについて、図１３以降の図面を用いて説明していく。

図１３は、Ｑｕｏｒｕｍ使用のヘルスチェック／ペア状態変更処理プログラム１００６によって実行される処理の全体の流れを示している。なお、図１３の処理は、全てのストレージ装置１０で実行されるが、以下では、ＤＫＣ＃ｋ（ＤＫＣ管理情報［ｋ］（２０２−ｋ）に情報書き込みを行うストレージ装置１０）のＭＰ１４１で、Ｑｕｏｒｕｍ使用のヘルスチェック／ペア状態変更処理プログラム１００６が実行されている場合について説明する。またＤＫＣ＃ｋのことを、「自ＤＫＣ」または「自装置」と表記することもある。

Ｑｕｏｒｕｍ使用のヘルスチェック／ペア状態変更処理プログラム１００６が呼び出し元プログラムから呼び出されると、ＭＰ１４１はまず、Ｑｕｏｒｕｍ Ｄｉｓｋ上の、ＤＫＣ配列割当表２０１、ＤＫＣ管理情報格納領域２０２に格納されている情報を読み出して、ＤＫＣ管理情報ステージングエリア２００’に格納する（Ｓ１０１）。

続いてＭＰ１４１は、ＤＫＣ管理情報ステージングエリア２００’に格納された情報に基づいて、Ｓ１０２（無応答判定処理）、Ｓ１０３（Ｍ−Ｒ間通信障害通知受領処理）、Ｓ１０４（通信不能ビットマップ編集処理）、Ｓ１０５（更新世代番号設定処理）を実行する。Ｓ１０２〜Ｓ１０５の処理において、ＤＫＣ管理情報ステージングエリア２００’に格納された各種情報の参照、更新が行われる。これらの処理の詳細は後述する。

Ｓ１０５までの処理が終了すると、ＭＰ１４１は、ＤＫＣ管理情報ステージングエリア２００’に格納されている情報を、Ｑｕｏｒｕｍ Ｄｉｓｋに書き戻す（Ｓ１０６）。なお、Ｓ１０１で読み出される情報は、Ｑｕｏｒｕｍ Ｄｉｓｋ上の、ＤＫＣ配列割当表２０１、ＤＫＣ管理情報格納領域２０２に格納されている情報の全てであるが、Ｓ１０６でＱｕｏｒｕｍ Ｄｉｓｋに書き戻される情報は、自装置（ＤＫＣ＃ｋ）が書き込みを行うことに決められている情報、つまりＤＫＣ管理情報［ｋ］（２０２−ｋ）のみである。またＳ１０６でＱｕｏｒｕｍ Ｄｉｓｋに書き戻す処理が完了した直後に、ＭＰ１４１は時計から現在時刻情報を取得し、取得した時刻情報をＱｕｏｒｕｍ格納時刻領域２５０に書き込む。

最後にＳ１０７でＭＰ１４１は、自ＤＫＣペア状態変更処理を行う。自ＤＫＣペア状態変更処理では、自装置のボリュームのペアステータスを変更する。Ｓ１０６までの処理を行った結果、ボリュームペアのペアステータスを「Ｓｕｓｐｅｎｄ状態」に遷移させる必要がある場合には、ペアステータスをＳｕｓｐｅｎｄ状態に変更する（ペア管理情報Ｔ３００に格納されている、ボリュームペアのＰａｉｒ Ｓｔａｔｕｓ（Ｔ３０２）を「２」に変更する等）。逆に、Ｓｕｓｐｅｎｄ状態であったボリュームペアをＤｕｐｌｅｘ状態に遷移させる必要がある場合には、ボリュームペアの再同期処理を行い、再同期が完了した時点で、ペアステータスを「Ｄｕｐｌｅｘ」に変更する（ペア管理情報Ｔ３００に格納されている、ボリュームペアのＰａｉｒ Ｓｔａｔｕｓ（Ｔ３０２）を「１」に変更する）。

以下、Ｓ１０２（無応答判定処理）、Ｓ１０３（Ｍ−Ｒ間通信障害通知受領処理）、Ｓ１０４（通信不能ビットマップ編集処理）、Ｓ１０５（更新世代番号設定処理）で行われる処理の流れを説明する。これらのステップでは先に述べたとおり、ＤＫＣ管理情報ステージングエリア２００’に格納された情報を用いた処理が行われる。なお、説明が冗長になることを避けるため、ＤＫＣ管理情報ステージングエリア２００’に格納された各情報の表記方法を以下のように定める。

ＤＫＣ管理情報ステージングエリア２００’に格納された情報のうち、ＤＫＣ配列割当表２０１の製番［０］（２０１−０）〜製番［ｎ−１］（２０１−（ｎ−１））のうち、たとえばＤＫＣ＃ｍの製番は「ＤＫＣ配列割当表．製番［ｍ］」と表記する。

また、ＤＫＣ管理情報ステージングエリア２００’に格納されたＤＫＣ管理情報［０］（２０２−０）〜ＤＫＣ管理情報［ｎ−１］（２０２−（ｎ−１））内の各情報を明確に特定するため、以下の表記方法が採用される。

まず、先にも述べたが、ここではＤＫＣ＃ｋのＭＰ１４１で、Ｑｕｏｒｕｍ使用のヘルスチェック／ペア状態変更処理プログラム１００６が実行されている場合について説明しており、このＤＫＣ＃ｋ（のＭＰ１４１）のことを、「自ＤＫＣ」または「自装置」と呼ぶ。そしてＤＫＣ管理情報［０］（２０２−０）〜ＤＫＣ管理情報［ｎ−１］（２０２−（ｎ−１））のうち、自ＤＫＣが情報書き込みを行うＤＫＣ管理情報（ＤＫＣ＃ｋが自ＤＫＣであれば、ＤＫＣ管理情報［ｋ］）のことを、「自ＤＫＣ管理情報」と呼ぶ。

また、自ＤＫＣ管理情報の中の、製番（２０２０）、更新世代番号（２０２１）等の各情報を特定する際、「自ＤＫＣ管理情報」と各情報の名称とを、「．」（ピリオド）で連結して表記する。たとえば自ＤＫＣ管理情報中の製番や更新世代番号はそれぞれ、「自ＤＫＣ管理情報．製番」、「自ＤＫＣ管理情報．更新世代番号」と表記される。また、前回世代［ｉ］（２０２８−ｉ）、前回時刻［ｉ］（２０２９−ｉ）も、「自ＤＫＣ管理情報．前回世代［ｉ］」、「自ＤＫＣ管理情報．前回時刻［ｉ］」と表記される（ｉは０≦ｉ≦（ｎ−１）の整数である）。

さらに、Ｓ１０２〜Ｓ１０５の処理の過程で、通信不能ビットマップＡ（２０２２）、通信不能ビットマップＢ（２０２３）、閉塞了承ビットマップ（２０２４）、応答不能ビットマップＡ（２０２５）、応答不能ビットマップＢ（２０２６）、回復中ビットマップ（２０２７）については、１ビットごとの参照、更新が行われる。そのため、これらの各ビットマップの特定のビット（たとえばｊ番目のビット）を特定するために、以下の表記方法が用いられる（ｊは０≦ｊ≦（ｎ−１）の整数である）。

（ａ） 通信不能ビットマップＡのｊ番目のビットは、通信不能ＢＭ＿Ａ｛ｊ｝と表記される。
（ｂ） 通信不能ビットマップＢのｊ番目のビットは、通信不能ＢＭ＿Ｂ｛ｊ｝と表記される。
（ｃ） 閉塞了承ビットマップのｊ番目のビットは、閉塞了承ＢＭ｛ｊ｝と表記される。
（ｄ） 応答不能ビットマップＡのｊ番目のビットは、応答不能ＢＭ＿Ａ｛ｊ｝と表記される。
（ｅ） 応答不能ビットマップＢのｊ番目のビットは、応答不能ＢＭ＿Ｂ｛ｊ｝と表記される。
（ｆ） 回復中ビットマップのｊ番目のビットは、回復中ＢＭ｛ｊ｝と表記される。

そのため、たとえば自ＤＫＣ管理情報に含まれている通信不能ビットマップＡの、ｊ番目のビットは、「自ＤＫＣ管理情報．通信不能ＢＭ＿Ａ｛ｊ｝」、と表記される。その他のビットマップについても、各ビットを特定する際には同様の表記がなされる。

また、自ＤＫＣ管理情報以外のＤＫＣ管理情報についても、上で説明したものと同様の表記方法を用いて表記される。つまり、ＤＫＣ管理情報［ｍ］（ｍは、０≦ｍ≦（ｎ−１）を満たす整数値）内の各情報を表現する際、「ＤＫＣ管理情報［ｍ］」と各情報の名称が、「．」を用いて連結された表記形式が用いられる。

Ｓ１０２〜Ｓ１０５の処理の説明に戻る。図１４及び図１５は、Ｓ１０２の処理、つまり無応答判定処理の流れを示している。無応答判定処理では主に、ＤＫＣ管理情報［ｍ］（０≦ｍ≦（ｎ−１））が、（ＤＫＣ＃ｍによって）更新されているかを確認することで、ＤＫＣ＃ｍが（障害などの要因によって）停止していないか判定する処理を行う。

なお、以降の図に記載の式で、左辺と右辺が「＝」で結合されている式は、右辺の値を左辺に代入する処理であることを意味する。また左辺と右辺が「＝＝」で結合されている式は、左辺の値と右辺の値が等しいか否かを判定する処理であることを意味する。

Ｓ２０１でＭＰ１４１は、自装置の配列番号を特定する。具体的には、ＤＫＣ配列割当表．製番［０］〜ＤＫＣ配列割当表．製番［ｎ−１］の中で、自装置の製番と等しい値が格納されているものを特定する。たとえば、ＤＫＣ配列割当表．製番［ｋ］（０≦ｋ≦（ｎ−１））が自装置の製番と等しい場合、ｋが自装置の配列番号であると特定される。以下、自装置の配列番号がｋであった場合を例にとって説明する。Ｓ２０１でＭＰ１４１は、変数ｓｅｌｆｂｌを用意し、変数ｓｅｌｆｂｌに値ｋを代入する。またＳ２０１の処理により、ＭＰ１４１は、ＤＫＣ管理情報ステージングエリア２００’に格納された情報（ＤＫＣ管理情報［０］（２０２−０）〜ＤＫＣ管理情報［ｎ−１］（２０２−（ｎ−１）））のうち、ＤＫＣ管理情報［ｓｅｌｆｂｌ］が自ＤＫＣ管理情報であると特定することができる。

次にＭＰ１４１はＤＫＣ管理情報［０］〜ＤＫＣ管理情報［ｎ−１］について、Ｓ２０３〜Ｓ２１７のループ処理を実行する。Ｓ２０３でＭＰ１４１は変数ｃｔｃを用意し、初期値に０を代入する。そしてＭＰ１４１はＳ２０４〜Ｓ２１６の処理を１回実行した時点で、変数ｃｔｃの値に１を加算し、再びＳ２０４〜Ｓ２１６の処理を実行する。そして変数ｃｔｃの値がｎ（たとえば１６）に到達した時点で、ＭＰ１４１はループ処理を終了する。

また、図１４以降の各図面において「ｃｏｎｔｉｎｕｅ」と記載されている箇所（たとえば以下で説明するＳ２０４の判定処理で、判定結果が肯定的だった場合（Ｓ２０４：Ｙｅｓ）に進む処理）は、それ以降（Ｓ２０６以降）の処理は実行せず、ループ終了（Ｓ２１７）に進むことを意味する。Ｓ２１７（ループ終了）では、ＭＰ１４１は変数ｃｔｃの値に１を加算し、ｃｔｃの値がｎ未満であれば再びＳ２０４〜Ｓ２１６の処理を実行する。ただし変数ｃｔｃの値に１を加算した結果、ｃｔｃの値がｎ以上になった場合には処理を終了する。以下、Ｓ２０４〜Ｓ２１６の処理について説明していく。

Ｓ２０４でＭＰ１４１は、ＤＫＣ配列割当表．製番［ｃｔｃ］またはＤＫＣ管理情報［ｃｔｃ］．製番の値が、ＮＵＬＬ（０）であるか判定する。ＤＫＣ配列割当表．製番［ｃｔｃ］またはＤＫＣ管理情報［ｃｔｃ］．製番の値がＮＵＬＬである場合（Ｓ２０４：Ｙｅｓ）、配列番号ｃｔｃのストレージ装置は、Ｑｕｏｒｕｍ Ｄｉｓｋへの登録処理が行われていない（ストレージシステム１内に、配列番号ｃｔｃのストレージ装置は存在しない）ことを意味する。そのためこの場合には、Ｓ２０５以降の処理は行わず、Ｓ２１７（ループ終了）に進む。一方ＤＫＣ配列割当表．製番［ｃｔｃ］及びＤＫＣ管理情報［ｃｔｃ］．製番の値がいずれもＮＵＬＬではない場合（Ｓ２０４：Ｎｏ）、Ｓ２０６以降の処理が行われる。

Ｓ２０６ではＭＰ１４１は、変数ｓｅｌｆｂｌと変数ｃｔｃの値が等しいか判定し、等しい場合（Ｓ２０６：Ｙｅｓ）には、Ｓ２０９以降の処理は行わず、Ｓ２０３に戻る。なぜならＳ２０９以降では、自ＤＫＣ以外のストレージ装置（以下、これを「相手側ＤＫＣ」と呼ぶ）のＤＫＣ管理情報［ｃｔｃ］の内容を参照することで、相手側ＤＫＣ（ＤＫＣ＃ｃｔｃ）が停止しているか否かを判定する。変数ｓｅｌｆｂｌと変数ｃｔｃの値が等しい場合、ＤＫＣ管理情報［ｃｔｃ］は自ＤＫＣ管理情報と同じものであり、参照する意味がないため、Ｓ２０９以降の処理は行われない（Ｓ２１７に進む）。変数ｓｅｌｆｂｌと変数ｃｔｃの値が等しくない場合（Ｓ２０６：Ｎｏ）には、Ｓ２０７以降の処理を行う。

Ｓ２０９ではＭＰ１４１は、ＤＫＣ管理情報［ｃｔｃ］．更新世代が、自ＤＫＣ管理情報．前回世代［ｃｔｃ］と等しいか判定する。ＤＫＣ管理情報［ｃｔｃ］．更新世代が、自ＤＫＣ管理情報．前回世代［ｃｔｃ］と等しい場合（Ｓ２０９：Ｙｅｓ）、自ＤＫＣが前回無応答判定処理を実行した時から、ＤＫＣ管理情報［ｃｔｃ］．更新世代の値が変更されていないことを意味する。この場合には、ＤＫＣ＃ｃｔｃが障害等の要因で停止している可能性があるので、Ｓ２１１以降で更なる確認が行われる。

一方Ｓ２０９の判定がＮｏの場合、自ＤＫＣが前回無応答判定処理を実行した後に、ＤＫＣ管理情報［ｃｔｃ］．更新世代の値が変更されていることを意味する（ＤＫＣ＃ｃｔｃは動作していると判断できる）。その場合にはＭＰ１４１は、自ＤＫＣ管理情報．前回世代［ｃｔｃ］に、ＤＫＣ管理情報［ｃｔｃ］．更新世代の値を代入し、また自ＤＫＣ管理情報．前回時刻［ｃｔｃ］に０を代入し（Ｓ２１０）、Ｓ２１７に進む。Ｓ２１０で更新された、自ＤＫＣ管理情報．前回世代［ｃｔｃ］、自ＤＫＣ管理情報．前回時刻［ｃｔｃ］の情報は、次回無応答判定処理が実行された時に用いられる。

Ｓ２１１では、ＭＰ１４１は自ＤＫＣ管理情報．前回時刻が０であるか判定し、０でない場合には（Ｓ２１１：Ｎｏ）、Ｓ２１３の処理を実行し、０である場合には（Ｓ２１１：Ｙｅｓ）、Ｓ２１２の処理を実行する。自ＤＫＣ管理情報．前回時刻が０である場合とは、自ＤＫＣが前回無応答判定処理を実行した際、Ｓ２１０が実行されたことを意味する。つまり、前回無応答判定処理を実行した時まではＤＫＣ＃ｃｔｃは正常で、今回初めて更新世代が更新されていないことを検出した場合に該当する。この場合にはＳ２１２で、ＭＰ１４１は、自ＤＫＣ管理情報．前回世代［ｃｔｃ］に、ＤＫＣ管理情報［ｃｔｃ］．更新世代の値を代入し、また自ＤＫＣ管理情報．前回時刻［ｃｔｃ］には、時計から取得した現在時刻（Ｓ２１２を実施している時点の時刻）を代入する。そしてＳ２１７に進む。

Ｓ２１３では、現在の時刻と自ＤＫＣ管理情報．前回時刻［ｃｔｃ］を比較し、ＤＫＣ＃ｃｔｃが所定時間以上無応答の状態が続いているか（タイムアウトであるか）判定する。具体的には、
（現在の時刻−自ＤＫＣ管理情報．前回時刻［ｃｔｃ］）≧閾値
であるか比較する（閾値はたとえば５秒等の値である）。この閾値のことを、以下では「タイムアウト時間」と呼ぶこともある。自ＤＫＣ管理情報．前回時刻［ｃｔｃ］にはＳ２１２を実行した時刻（更新世代が更新されていないことを初めて検出した時刻）が格納されている。つまりここでは、更新世代が更新されていないことを初めて検出した時刻から、タイムアウト時間に相当する時間が経過したかを判定しているといえる。タイムアウトでない（更新世代が更新されていないことを初めて検出した時刻から、まだタイムアウト時間に相当する時間は経過していない）場合には（Ｓ２１３：Ｎｏ）、Ｓ２１７に進む。

タイムアウトと判定された場合（Ｓ２１３：Ｙｅｓ）、ＭＰ１４１は自ＤＫＣ管理情報に、ＤＫＣ＃ｃｔｃが所定時間以上Ｑｕｏｒｕｍ Ｄｉｓｋへの書き込みを行っていないと判断した（つまりＤＫＣ＃ｃｔｃが停止しており、応答できない状態にあると判断した）ことを表す情報を格納する。具体的には、自ＤＫＣ管理情報．応答不能ＢＭ＿Ａ｛ｃｔｃ｝の値が「１」に設定される（Ｓ２１５）。

ただしＳ２１５の前に、ＭＰ１４１は、自ＤＫＣ管理情報．通信不能ＢＭ＿Ａ｛ｃｔｃ｝が「１」で、かつ、ＤＫＣ管理情報［ｃｔｃ］．応答不能ＢＭ＿Ａ｛ｓｅｌｆｂｌ｝が０であるか判定し（Ｓ２１４）、この判定が肯定的である場合にＳ２１５を実行する。Ｓ２１４の判定が行われる理由は、ＤＫＣ管理情報［ｃｔｃ］．応答不能ＢＭ＿Ａ｛ｓｅｌｆｂｌ｝をＯＮにする条件として、タイムアウトになった（所定時間以上Ｑｕｏｒｕｍ Ｄｉｓｋへの書き込みが行われていない）という条件に加え、ストレージ装置１０ａからストレージ装置１０ｂへのデータ転送（あるいはストレージ装置１０ｂからストレージ装置１０ａへのデータ転送）が失敗した場合（図９または図１０ Ｓ４の判定がＮの場合）であることも、条件の１つにしているからである。

ストレージ装置１０ａからストレージ装置１０ｂ（あるいはストレージ装置１０ｂからストレージ装置１０ａへのデータ転送）へのデータ転送が失敗した場合は、ストレージ装置１０ｂ（または１０ａ）が障害で停止している可能性が高い。逆に単にタイムアウトになった場合には、ストレージ装置１０の負荷が高いなどの要因で、Ｑｕｏｒｕｍ Ｄｉｓｋへの書き込みが遅れているだけで、ストレージ装置１０が正常に稼働している可能性もある。そのため、本実施例の無応答判定処理では、ストレージ装置１０が停止していることをより確実に判定するため、Ｓ２１４の判定を行っている。

Ｓ２１４の判定がＮｏである場合には、Ｓ２１５の処理は行わない。代わりに自ＤＫＣ管理情報．前回時刻［ｃｔｃ］に、タイムアウト時刻より所定時間だけ前の時刻（たとえばタイムアウト時刻より０．５秒前の時刻）を代入し（Ｓ２１６）、Ｓ２１７に進む。なお、タイムアウト時刻とはタイムアウトと判定される時刻のことで、
（更新世代が更新されていないことを検知した時刻した時刻（Ｓ２１２が行われた時刻））＋タイムアウト時間＝タイムアウト時刻
の関係にある。

続いて、Ｍ−Ｒ間通信障害通知受領処理の流れを、図１６〜図１９を用いて説明する。Ｓ３０１〜Ｓ３０６は、図１４のＳ２０１〜Ｓ２０６と同じ処理である。

Ｓ３０７でＭＰ１４１は、自ＤＫＣ管理情報．回復中ＢＭ｛ｃｔｃ｝が「１」であるか判定する。自ＤＫＣ管理情報．回復中ＢＭ｛ｃｔｃ｝が「１」の場合（Ｓ３０７：Ｙｅｓ）、Ｓ３０８、Ｓ３０９の処理が行われる。

Ｓ３０８でＭＰ１４１は、ＤＫＣ管理情報［ｃｔｃ］．通信不能ＢＭ＿Ａ｛ｓｅｌｆｂｌ｝、ＤＫＣ管理情報［ｃｔｃ］．通信不能ＢＭ＿Ｂ｛ｓｅｌｆｂｌ｝、ＤＫＣ管理情報［ｃｔｃ］．閉塞了承ＢＭ｛ｓｅｌｆｂｌ｝、ＤＫＣ管理情報［ｃｔｃ］．応答不能ＢＭ＿Ａ｛ｓｅｌｆｂｌ｝、ＤＫＣ管理情報［ｃｔｃ］．応答不能ＢＭ＿Ｂ｛ｓｅｌｆｂｌ｝のいずれか１つ以上が「１」であるか判定する。これらのビットのいずれかが「１」である場合とは、ＤＫＣ＃ｃｔｃが回復処理中であることを意味する。そのため、これらのビットのいずれかが「１」である場合（Ｓ３０８：Ｙｅｓ）、Ｓ３２２（ループ終了）に進む。これらのビットの全てが［０］である場合（Ｓ３０８：Ｎｏ）、ＭＰ１４１は自ＤＫＣ管理情報．回復中ＢＭ｛ｃｔｃ｝を「０」にする（Ｓ３０９）。

Ｓ３０９の処理の後、あるいはＳ３０７の判定で自ＤＫＣ管理情報．回復中ＢＭ｛ｃｔｃ｝が「０」の場合（Ｓ３０７：Ｎｏ）、ＭＰ１４１はＤＫＣ管理情報［ｃｔｃ］．通信不能ＢＭ＿Ａ｛ｓｅｌｆｂｌ｝が「１」であるか判定する（Ｓ３１０）。ＤＫＣ管理情報［ｃｔｃ］．通信不能ＢＭ＿Ａ｛ｓｅｌｆｂｌ｝が「１」である場合（Ｓ３１０：Ｙｅｓ）とは、相手側のＤＫＣ（ＤＫＣ＃ｃｔｃ）が、自ＤＫＣとＤＫＣ＃ｃｔｃ間のパスによるデータ通信が不可能であると判断していることを意味する。この場合ＭＰ１４１は、Ｓ３１３以降の処理を実行して、自装置の論理ボリュームを閉塞状態にすべきか判定する。一方ＤＫＣ管理情報［ｃｔｃ］．通信不能ＢＭ＿Ａ｛ｓｅｌｆｂｌ｝が「０」である場合（Ｓ３１０：Ｎｏ）には、ＭＰ１３１は自ＤＫＣ管理情報．閉塞了承ＢＭ｛ｃｔｃ｝と、自ＤＫＣ管理情報．通信不能ＢＭ＿Ｂ｛ｃｔｃ｝を「０」にして（Ｓ３１１，Ｓ３１２）、Ｓ３１８以降の処理に進む。

Ｓ３１３では、ＭＰ１４１は、以下の（ａ）〜（ｃ）の３条件のいずれかに該当するかを判定する。
（ａ） 自装置が、自装置とＤＫＣ＃ｃｔｃとの間のパスが遮断されていることをまだ検知していない（自ＤＫＣ管理情報．通信不能ＢＭ＿Ａ｛ｃｔｃ｝が０）
（ｂ） 自装置が、自装置とＤＫＣ＃ｃｔｃとの間のパスが遮断されていることを検知し（自ＤＫＣ管理情報．通信不能ＢＭ＿Ａ｛ｃｔｃ｝が１）、かつ自装置の製番がＤＫＣ＃ｃｔｃの製番よりも大きい（自ＤＫＣ管理情報．製番＞ＤＫＣ管理情報［ｃｔｃ］．製番）
（ｃ） ＤＫＣ＃ｃｔｃは、自装置が応答不能の状態にあると判断している（実ＤＫＣ管理情報［ｃｔｃ］．応答不能ＢＭ＿Ａ｛ｓｅｌｆｂｌ｝が１である）

本実施例に係るストレージシステムでは、ストレージ装置１０間のパスが遮断された場合、１台のストレージ装置１０について、当該ストレージ装置１０のボリュームをＩ／Ｏ不可（Ｉｎｖａｌｉｄ状態。ホスト２からのＩ／Ｏ要求の受け付けを禁止）にする。この時、原則としてホスト２からのＩ／Ｏ要求を受け付け中のストレージ装置１０のボリュームについてはＩ／Ｏ不可にしないように制御される。そのため、たとえばストレージ装置１０ａからストレージ装置１０ｂへのデータ転送が失敗した場合（図９ Ｓ４の判定がＮの場合）には、原則として、ストレージ装置１０ａのボリューム（Ｐ−ＶＯＬ）はＩ／Ｏ不可にしないように制御される。

詳細は後述するが、自ＤＫＣから相手側ストレージ装置へのデータ転送が失敗した場合には、自ＤＫＣ管理情報．通信不能ＢＭ＿Ａ｛ｃｔｃ｝が１になる。そのため自ＤＫＣから相手側ストレージ装置へのデータ転送が失敗した場合には、上の条件（ａ）に該当しないため、Ｓ３１４以降の処理が行われない。逆に相手側ＤＫＣでは自ＤＫＣ管理情報．通信不能ＢＭ＿Ａ｛ｃｔｃ｝が０になるため、上の条件（ａ）に該当することになり、Ｓ３１４以降の処理が行われる。

ただし、ストレージ装置１０ａ、ストレージ装置１０ｂの両方が、ほぼ同時期に相手側ストレージ装置へのデータ転送を行っている場合もあり得る（ストレージ装置１０ａ、１０ｂの両方で、図９または図１０の処理を行っている場合）。その場合、両方のストレージ装置１０で、通信不能ＢＭ＿Ａが１になっている。その場合には、自ＤＫＣと相手側ストレージ装置の製番を比較し、製番が大きいストレージ装置１０のボリュームをＩ／Ｏ不可にするように制御される。そのために、条件（ｂ）が設けられている。

また、相手側ストレージ装置で、すでに自ＤＫＣが応答不能状態と判断している場合には、相手側ストレージ装置のボリュームをＩ／Ｏ不可にしないように制御される。そのために条件（ｃ）が設けられている。

上の３条件のいずれかに該当する場合（Ｓ３１３：Ｙｅｓ）、Ｓ３１４の処理が実行される。上の３条件のいずれにも該当しない場合（Ｓ３１３：Ｎｏ）、Ｓ３１４〜Ｓ３１６の処理は実行されず、ＭＰ１４１はＳ３１７の処理を実行する。Ｓ３１７ではＭＰ１４１は、自ＤＫＣ管理情報．通信不能ＢＭ＿Ｂ｛ｃｔｃ｝を「１」にする（つまり、「相手ＤＫＣ（ＤＫＣ＃ｃｔｃ）が自装置との間のパスが遮断されたことを検知した」という事実を、自装置が検知した旨を記録する）。

Ｓ３１４ではさらに、ＭＰ１４１は以下の（ｄ）〜（ｆ）の３条件すべてに該当するか判定する。
（ｄ） ＤＫＣ＃ｃｔｃのボリュームがＩｎｖａｌｉｄ状態でない（ＤＫＣ管理情報［ｃｔｃ］．閉塞了承ＢＭ｛ｓｅｌｆｂｌ｝が０）
（ｅ） 自装置は、ＤＫＣ＃ｃｔｃが応答不能と判定していない（自ＤＫＣ管理情報．応答不能ＢＭ＿Ａ｛ｃｔｃ｝が０）
（ｆ） 自装置のボリュームがＩｎｖａｌｉｄ状態でない（自ＤＫＣ管理情報．閉塞了承ＢＭ｛ｃｔｃ｝が０）

条件（ｄ）〜（ｆ）の意味について概説する。相手側ＤＫＣ（ＤＫＣ＃ｃｔｃ）が閉塞している場合（あるいは相手側ＤＫＣでボリュームがＩ／Ｏ不可（Ｉｎｖａｌｉｄ状態）にされている場合）、自装置のボリュームをＩ／Ｏ不可にするべきではない。そのために条件（ｄ）、（ｅ）が設けられている。

また、すでに自装置のボリュームがＩ／Ｏ不可（Ｉｎｖａｌｉｄ状態）である場合には、これ以上自装置のボリュームをＩ／Ｏ不可にする処理は不要である。これを判定するために条件（ｆ）が設けられている。

上の３条件のすべてに該当する場合（Ｓ３１４：Ｙｅｓ）、ＭＰ１４１は自装置の論理ボリュームをＩ／Ｏ不可（Ｉｎｖａｌｉｄ）状態にする（Ｓ３１５）。具体的には、論理ボリュームのステータス（ＬＤＥＶステータス情報Ｔ４００のＳｔａｔｕｓ（Ｔ４０２））を「Ｉｎｖａｌｉｄ」にし、また自装置の論理ボリュームが属するボリュームペアのペアステータス（ペア管理テーブルＴ３００のＰａｉｒ Ｓｔａｔｕｓ（Ｔ３０２））を「Ｓｕｓｐｅｎｄ状態」にする。

Ｓ３１５の後、ＭＰ１４１は、自ＤＫＣ管理情報．閉塞了承ＢＭ｛ｃｔｃ｝を「１」にし（Ｓ３１６）、Ｓ３１７以降の処理を実行する。Ｓ３１７の処理は先に述べたとおりである。

Ｓ３１８以降は、相手側ＤＫＣ（ＤＫＣ＃ｃｔｃ）が自装置を応答不能状態と判定している場合の処理である。この場合、自装置の論理ボリュームを閉塞状態にする。

Ｓ３１８でＭＰ１４１は、ＤＫＣ管理情報［ｃｔｃ］．応答不能ＢＭ＿Ａ｛ｓｅｌｆｂｌ｝が１か確認することにより、ＤＫＣ＃ｃｔｃが自装置を応答不能と判断しているか判定する。ＤＫＣ管理情報［ｃｔｃ］．応答不能ＢＭ＿Ａ｛ｓｅｌｆｂｌ｝が１でない場合（Ｓ３１８：Ｎｏ）、ＭＰ１４１は自ＤＫＣ管理情報．応答不能ＢＭ＿Ｂ｛ｃｔｃ｝を０に設定し（Ｓ３２５）、Ｓ３２２に進む。Ｓ３２５の処理は、リシンク処理の場合に実行される処理である。

ＤＫＣ管理情報［ｃｔｃ］．応答不能ＢＭ＿Ａ｛ｓｅｌｆｂｌ｝が１である場合（Ｓ３１８：Ｙｅｓ）、ＭＰ１４１は自ＤＫＣ管理情報．応答不能ＢＭ＿Ｂ｛ｃｔｃ｝が０か判定する（Ｓ３１９）。自ＤＫＣ管理情報．応答不能ＢＭ＿Ｂ｛ｃｔｃ｝が０の場合には（Ｓ３１９：Ｙｅｓ）、Ｓ３２０の処理を実行する。この処理はＳ３１５と同じである。そして自ＤＫＣ管理情報．応答不能ＢＭ＿Ｂ｛ｃｔｃ｝を１にして（Ｓ３２１）、Ｓ３２２に進む。

自ＤＫＣ管理情報．応答不能ＢＭ＿Ｂ｛ｃｔｃ｝が１の場合（Ｓ３１９：Ｎｏ）とは、すでに、過去に行われたＭ−Ｒ間通信障害通知受領処理によって、ＭＰ１４１は自装置の論理ボリュームがＩｎｖａｌｉｄ状態にされている（過去にＳ３２０、Ｓ３２１が実行された）場合である。そのため、Ｓ３２０、Ｓ３２１の処理は実行せずにＳ３２２に進む。

続いて、通信不能ビットマップ編集処理の流れを、図２０、図２１を用いて説明する。通信不能ビットマップ編集処理は、自ＤＫＣ管理情報．通信不能ＢＭ＿Ａをセットまたはリセットする処理である。自ＤＫＣ管理情報．通信不能ＢＭ＿Ａは、自ＤＫＣが相手ＤＫＣとの通信が不可能である状態を表す情報であるから、ヘルスチェック処理（図１２）の場合には、セットされない。逆に、ホスト２からのライト要求に係る処理の過程で、相手側ＤＫＣへのデータ書き込みが失敗した場合（たとえば図９ Ｓ４：Ｎの場合）に、自ＤＫＣ管理情報．通信不能ＢＭ＿Ａがセットされる。またリシンク処理（図１１）の場合には、自ＤＫＣが相手ＤＫＣとの通信が可能になるので、自ＤＫＣ管理情報．通信不能ＢＭ＿Ａがリセットされる。

Ｓ４０１は、図１４のＳ２０１と同じ処理である。

Ｓ４０３ではＭＰ１４１は、呼び出し元プログラムから渡された処理種別を参照し、処理種別が「ヘルスチェック」であるか判定する。処理種別が「ヘルスチェック」である場合（Ｓ４０３：Ｙｅｓ）、処理を終了する。処理種別が「ヘルスチェック」でない場合（Ｓ４０３：Ｎｏ）、Ｓ４０４以降の処理が実行される。

Ｓ４０４でＭＰ１４１は、相手側ＤＫＣの配列番号を特定する。具体的には、ＤＫＣ配列割当表．製番［０］〜ＤＫＣ配列割当表．製番［ｎ−１］の中で、呼び出し元プログラムから渡された相手側装置の製番と等しい値が格納されているものを特定する。たとえば、ＤＫＣ配列割当表．製番［ｊ］（０≦ｊ≦（ｎ−１））が相手側装置の製番と等しい場合、ｊが相手側ＤＫＣの配列番号であると特定される。以下、相手側ＤＫＣの配列番号がｊであった場合を例にとって説明する。

ＭＰ１４１は、変数ｍａｔｅｂｌを用意し、変数ｍａｔｅｂｌに値ｊを代入する。これによりＤＫＣ管理情報［ｍａｔｅｂｌ］が、相手側ＤＫＣのＤＫＣ管理情報と特定できる。以下、ＤＫＣ管理情報［ｍａｔｅｂｌ］のことを、「相手ＤＫＣ管理情報」と表記する。

Ｓ４０６ではＭＰ１４１は、呼び出し元プログラムから渡された処理種別を参照し、処理種別が「障害サスペンド」であるか判定する。処理種別が「障害サスペンド」である場合（Ｓ４０６：Ｙｅｓ）、Ｓ４０７の処理が実行される。一方、処理種別が「障害サスペンド」でない場合（Ｓ４０６：Ｎｏ）とは、処理種別に「リシンク」が指定されている。この場合にはＳ４０９以降の処理（図２１）に進む。

Ｓ４０７ではＭＰ１４１は、自ＤＫＣ管理情報．閉塞了承ＢＭ｛ｍａｔｅｂｌ｝が０であるか判定する。つまり相手側ＤＫＣのボリュームとペア関係にある自ＤＫＣのボリュームを閉塞したか否かを判定する。自ＤＫＣ管理情報．閉塞了承ＢＭ｛ｍａｔｅｂｌ｝が０である場合（Ｓ４０７：Ｙｅｓ。つまり相手側ＤＫＣのボリュームとペア関係にある自ＤＫＣのボリュームを閉塞していない場合）、ＭＰ１４１は、自ＤＫＣ管理情報．通信不能ＢＭ＿Ａ｛ｍａｔｅｂｌ｝を１にする（Ｓ４０８）。

Ｓ４０９以降は、処理種別として「リシンク」が指定された場合に行われる処理である。ＭＰ１４１は、自ＤＫＣ管理情報．通信不能ＢＭ＿Ａ｛ｍａｔｅｂｌ｝、自ＤＫＣ管理情報．通信不能ＢＭ＿Ｂ｛ｍａｔｅｂｌ｝、自ＤＫＣ管理情報．閉塞了承ＢＭ｛ｍａｔｅｂｌ｝、自ＤＫＣ管理情報．応答不能ＢＭ＿Ａ｛ｍａｔｅｂｌ｝、自ＤＫＣ管理情報．応答不能ＢＭ＿Ｂ｛ｍａｔｅｂｌ｝をすべて０にする（Ｓ４０９〜Ｓ４１３）。

Ｓ４１４でＭＰ１４１は、相手ＤＫＣ管理情報．通信不能ＢＭ＿Ａ｛ｍａｔｅｂｌ｝、相手ＤＫＣ管理情報．通信不能ＢＭ＿Ｂ｛ｍａｔｅｂｌ｝、相手ＤＫＣ管理情報．閉塞了承ＢＭ｛ｍａｔｅｂｌ｝、相手ＤＫＣ管理情報．応答不能ＢＭ＿Ａ｛ｍａｔｅｂｌ｝、相手ＤＫＣ管理情報．応答不能ＢＭ＿Ｂ｛ｍａｔｅｂｌ｝のいずれか１つ以上のビットが１であるか判定する。これらのいずれかのビットが１である場合には、まだ相手側ＤＫＣの状態は正常な状態ではないため、ＭＰ１４１は自ＤＫＣ管理情報．回復中ＢＭ＿Ａ｛ｍａｔｅｂｌ｝を１にして（Ｓ４１５）、処理を終了する。すべてのビットが０である場合には（Ｓ４１４：Ｎｏ）、Ｓ４１５を実行せずに処理を終了する。

リシンク時の通信不能ビットマップ編集処理は、自ＤＫＣ、相手側ＤＫＣの両方で並行して実行される。自ＤＫＣ、相手側ＤＫＣの両方で同期してリシンク処理を完了させたいため、自ＤＫＣでは、相手側ＤＫＣの通信不能ＢＭ＿Ａ｛ｍａｔｅｂｌ｝、通信不能ＢＭ＿Ｂ｛ｍａｔｅｂｌ｝、閉塞了承ＢＭ｛ｍａｔｅｂｌ｝、応答不能ＢＭ＿Ａ｛ｍａｔｅｂｌ｝、応答不能ＢＭ＿Ｂ｛ｍａｔｅｂｌ｝がすべてＯＦＦ（０）になるまでは、回復中ＢＭ＿Ａ｛ｍａｔｅｂｌ｝を１にしておき、リシンク処理中の状態を維持する。また相手側ＤＫＣでも同様の処理が行われる。

図２２は、更新世代番号設定処理のフローチャートである。更新世代番号設定処理は、自ＤＫＣのＤＫＣ管理情報（前に設定した処理と同様、これを「自ＤＫＣ管理情報」と呼ぶ）。の更新世代番号に１を加算する処理である。Ｓ５０１でＭＰ１４１は自ＤＫＣの配列番号を特定する。これはＳ２０１と同様の処理である。以下、自ＤＫＣの配列番号がｋで、自ＤＫＣ管理情報＝ＤＫＣ管理情報［ｋ］の関係にあるとする。

Ｓ５０２でＭＰ１４１は、自ＤＫＣ管理情報．更新世代番号（つまりＤＫＣ管理情報［ｋ］．更新世代番号）に１を加算し、処理を終了する。

図２３は、自ＤＫＣペア状態変更処理のフローチャートである。

Ｓ６０１は、自ＤＫＣの配列番号を特定する処理である。これはＳ２０１等と同様である。またＳ６０３は、相手側ＤＫＣの配列番号を特定する処理である。これはＳ４０４と同様の処理である。

Ｓ６０４で、ＭＰ１４１は呼び出し元プログラムから渡された処理種別がリシンクであるか判定し、リシンクである場合にはＳ６０７、Ｓ６０８の処理を実行する。リシンク以外の場合には、Ｓ６０５、Ｓ６０６の処理が実行される。

Ｓ６０５で、ＭＰ１４１は相手側ＤＫＣでボリュームがＩｎｖａｌｉｄ状態にされているか（ＤＫＣ管理情報［ｍａｔｅｂｌ］．閉塞了承ＢＭ｛ｓｅｌｆｂｌ｝が１であるか）、相手側ＤＫＣが応答不能の状態にあるか（自ＤＫＣ管理情報．応答不能ＢＭ＿Ａ｛ｍａｔｅｂｌ｝が１か）を判定する。いずれかの条件に該当する場合には（Ｓ６０５：Ｙｅｓ）、ＭＰ１４１はペア管理テーブルＴ３００内の、相手側ＤＫＣのボリュームとペア関係にあるボリュームのペアステータス（Ｔ３０２）を変更し、併せて変更中フラグ（Ｔ３０７）をＯＦＦにし（Ｓ６０６）、処理を終了する。Ｓ６０５の判定でいずれの条件にも該当しない場合には（Ｓ６０５：Ｎｏ）、ＭＰ１４１はＳ６０６を実行せずに処理を終了する。

相手側ＤＫＣでボリュームがＩｎｖａｌｉｄ状態にされている場合、あるいは相手側ＤＫＣが応答不能の状態にある場合とは、いずれもボリュームペアは同期不可能な状態であるので、自ＤＫＣ側のボリュームペアのうち、相手側ＤＫＣ（ＤＫＣ＃ｍａｔｅｂｌ）のボリュームとペア関係にあるボリュームについては、ペアステータス（ペア管理テーブルＴ３００のＰａｉｒ Ｓｔａｔｕｓ（Ｔ３０２））を２（Ｓｕｓｐｅｎｄ）に変更する。またボリュームのステータス（Ｓｔａｔｕｓ（Ｔ４０２））は「Ｖａｌｉｄ」とする。

Ｓ６０７で、ＭＰ１４１は自ＤＫＣ管理情報．回復中ＢＭ｛ｍａｔｅｂｌ｝がＯＮ（１）であるか判定する。ＯＦＦ（０）の場合には（Ｓ６０７：Ｎｏ）、相手側ＤＫＣも回復されていることを意味する。そのため、ＭＰ１４１はペア管理テーブルＴ３００内の、相手側ＤＫＣのボリュームとペア関係にあるボリュームのペアステータス（Ｔ３０２）を３（Ｄｕｐｌｅｘ−Ｐｅｎｄｉｎｇ）に変更し、併せて変更中フラグ（Ｔ３０７）をＯＦＦにし（Ｓ６０８）、処理を終了する。

（６） 具体例
以下では、ストレージ装置１０に障害が発生した時、またはストレージ装置１０ａとストレージ装置１０ｂ間のパス（ＤＫＣ間パス）に障害が発生した場合を例にとって、ストレージシステム１で行われる処理の流れを説明する。また最後に、Ｑｕｏｒｕｍ Ｄｉｓｋへの書き込みが遅延した場合の、ストレージシステム１の動作について説明する。

（６−１） ストレージ装置１０に障害が発生した場合
以下では一例として、ストレージ装置１０ｂに障害が発生し、ストレージ装置１０ｂが停止した場合について説明する。なお、上で述べたとおり、ストレージシステム１には、２台より多くのストレージ装置１０が含まれる構成もあり得るが、以下では説明の簡単化のため、ストレージシステム１にはホスト２とＱｕｏｒｕｍ Ｓｔｏｒａｇｅ１５の他には、２台のストレージ装置１０（ストレージ装置１０ａ及び１０ｂ）のみが存在する構成を例にとって説明する。ストレージ装置１０ａにはＰ−ＶＯＬが存在し、当該Ｐ−ＶＯＬとペア関係にあるＳ−ＶＯＬがストレージ装置１０ｂに存在しているものとする。また、Ｑｕｏｒｕｍ Ｄｉｓｋへの登録処理が行われた結果、ストレージ装置１０ａの配列番号が０、ストレージ装置１０ｂの配列番号が１に決定されているものとする。

ホスト２からストレージ装置１０ａが、Ｐ−ＶＯＬに対するライト要求を受信すると、ストレージ装置１０ａではＩ／Ｏプログラム１００１が実行される、つまり図９の処理が実行される。図９の処理の実行過程で、Ｓ−ＶＯＬ（Ｓ−ＶＯＬのあるストレージ装置１０ｂ）に対してライト要求を発行するが（図９ Ｓ３）、ストレージ装置１０ｂは障害が発生して停止しているため、Ｓ−ＶＯＬに対するライト処理は失敗する。そのためＩ／Ｏプログラム１００１はＱｕｏｒｕｍ使用のヘルスチェック／ペア状態変更処理プログラム１００６を呼び出す（Ｓ１１）。

Ｑｕｏｒｕｍ使用のヘルスチェック／ペア状態変更処理プログラム１００６が実行されると、上で説明したとおり、ＭＰ１４１はＤＫＣ管理情報ステージングエリア２００’にＤＫＣ配列割当表２０１、ＤＫＣ管理情報格納領域２０２の情報を読み出し、Ｓ１０２以降の処理を実施する。なお、ストレージ装置１０ａのＭＰ１４１でＱｕｏｒｕｍ使用のヘルスチェック／ペア状態変更処理プログラム１００６が実行される場合、ＤＫＣ管理情報［０］が、自ＤＫＣ管理情報であり、ＤＫＣ管理情報［１］が相手側ＤＫＣ管理情報である（ストレージ装置１０ａ、１０ｂの配列番号がそれぞれ０、１だからである）。

ストレージ装置１０ａでＳ１０２（無応答判定処理）が行われる時の処理の流れを説明する。なお、ストレージシステム１に２台のストレージ装置１０ａ、１０ｂのみが存在する構成の場合、無応答判定処理では、自ＤＫＣ管理情報（ＤＫＣ管理情報［０］である）をＤＫＣ管理情報［１］と比較する処理のみが行われる。

ストレージ装置１０ｂが停止している場合、ＤＫＣ管理情報［１］の更新世代番号の更新も停止する。そのためストレージ装置１０ａがＳ２０９の判定を行うと、判定結果はＹｅｓになり、Ｓ２１１が実行される。ストレージ装置１０ｂが停止してからはじめてＳ２１１が実行される場合には、自ＤＫＣ管理情報．前回時刻には０が格納されている。そのため、Ｓ２１２でＭＰ１４１は、自ＤＫＣ管理情報．前回世代［１］に、ＤＫＣ管理情報［１］．更新世代の値を代入し、また自ＤＫＣ管理情報．前回時刻［１］には、現在の時刻を代入し、無応答判定処理（Ｓ１０２）が終了する。

続いてストレージ装置１０ａのＭＰ１４１は、Ｓ１０３（Ｍ−Ｒ間通信障害通知受領処理）を実行する。ただしストレージ装置１０ｂが停止してからはじめてＳ１０３が実行される場合には、以下に説明する通り、目立った処理（特定のビットマップをＯＮにする等）は行われない。

Ｓ３０７の判定が実行される際、自ＤＫＣ管理情報．回復中ＢＭ［１］は０であるから、Ｓ３０８，Ｓ３０９の処理は行われず、Ｓ３１０の判定が行われる。またＳ３１０の判定では、ＤＫＣ管理情報［１］．通信不能ＢＭ＿Ａ｛０｝はＯＦＦ（０）である（ストレージ装置１０ｂは障害で停止したため、ＤＫＣ管理情報［１］．通信不能ＢＭ＿Ａ｛０｝をＯＮにすることなく停止しているからである）ので、Ｓ３１１，Ｓ３１２で、自ＤＫＣ管理情報．閉塞了承ＢＭ｛１｝、自ＤＫＣ管理情報．通信不能ＢＭ｛１｝がＯＦＦにされる。その後、Ｓ３１８以降の処理が実行される。

Ｓ３１８の判定において、ＤＫＣ管理情報［１］．応答不能ＢＭ＿Ａ｛０｝はＯＦＦ（０）である（上で述べた理由と同様である。ストレージ装置１０ｂは障害で停止したため、ＤＫＣ管理情報［１］．応答不能ＢＭ＿Ａ｛０｝をＯＮにすることなく停止している）ので、自ＤＫＣ管理情報．応答不能ＢＭ＿Ｂ｛１｝をＯＦＦにして（Ｓ３２５）、Ｍ−Ｒ間通信障害通知受領処理は終了する。

続いてストレージ装置１０ａのＭＰ１４１は、Ｓ１０４（通信不能ビットマップ編集処理）を実行する。この時呼び出し元プログラムから処理種別として「障害サスペンド」が指定されているので、Ｓ４０７、Ｓ４０８の処理が実行される。Ｓ４０７、Ｓ４０８の処理の結果、ＭＰ１４１は、自ＤＫＣ管理情報．通信不能ＢＭ＿Ａ｛１｝をＯＮにして、処理を終了する（なお、自ＤＫＣ（ストレージ装置１０ａ）ではボリュームをＩｎｖａｌｉｄ状態にする処理は行っていないため、Ｓ４０７の判定（自ＤＫＣ管理情報．閉塞了承ＢＭ｛１｝がＯＦＦか？）はＹｅｓとなる）。

続いてストレージ装置１０ａのＭＰ１４１は、Ｓ１０５（更新世代番号設定処理）を実行する。ここでは自ＤＫＣ管理情報．更新世代番号が１加算される。その後Ｓ１０６で、自ＤＫＣ管理情報がＱｕｏｒｕｍ Ｄｉｓｋに書き戻される。

また、Ｓ１０６の後、Ｓ１０７が実行されるが、この段階では、自ＤＫＣ管理情報．応答不能ＢＭ＿Ａ｛１｝は０であるので、Ｓ１０７ではペア状態変更は行われないまま、Ｑｕｏｒｕｍ使用のヘルスチェック／ペア状態変更処理プログラム１００６は終了する。

全ボリュームペアの状態が変更されるまでは、所定時間の後（Ｓ１４）、繰り返しＱｕｏｒｕｍ使用のヘルスチェック／ペア状態変更処理プログラム１００６が実行される（Ｓ１１）。以下、ストレージ装置１０ｂが無応答になって（Ｑｕｏｒｕｍ Ｄｉｓｋへの書き込みを行わなくなり）、タイムアウト時間が経過した後に、ストレージ装置１０ａでＳ１１が実行された場合について、以下で説明する。

この場合、Ｓ１０２（無応答判定処理）の中で、タイムアウトの判定（Ｓ２１３）が行われることにより、Ｓ２１４の判定が行われる。この処理が行われるよりも前に、自ＤＫＣ管理情報．通信不能ＢＭ＿Ａ｛１｝はＯＮにされている（通信不能ビットマップ編集処理 Ｓ４０８が実行されることによって）。またＤＫＣ管理情報［１］．応答不能ＢＭ＿Ａ｛０｝はＯＦＦであるので、自ＤＫＣ管理情報．応答不能ＢＭ＿Ａ｛１｝がＯＮにされる（Ｓ２１５）。

自ＤＫＣ管理情報．応答不能ＢＭ＿Ａ｛１｝がＯＮにされたので、この後に行われるＳ１０７（自装置のボリュームペアのペア状態変更）で、ストレージ装置１０ａは、ストレージ装置１０ｂとペア関係にあるボリュームのペアステータスをＳｕｓｐｅｎｄに変更し（なお、上でも述べたとおりこの場合、ボリュームのステータス（Ｓｔａｔｕｓ（Ｔ４０２））は「Ｖａｌｉｄ」とし、ホスト２からのＩ／Ｏ要求は受付可能としている）、Ｑｕｏｒｕｍ使用のヘルスチェック／ペア状態変更処理プログラム１００６の実行（Ｓ１１）を終了する。その後ストレージ装置１０ａは、ホスト２から受け付けたＩ／Ｏ処理を再開する（Ｓ１２、Ｓ１３、Ｓ５）。

このように、ストレージ装置１０ａは、ストレージ装置１０ｂが定期的にＱｕｏｒｕｍ Ｄｉｓｋに書き込むヘルスチェック情報（ＤＫＣ管理情報）を参照することで、ストレージ装置１０ｂが停止している（つまりそのためにＳ−ＶＯＬがアクセス不可能になっている）ことを確認し、ストレージ装置１０ｂが停止していることを確認した後Ｉ／Ｏ処理を再開するようにしている。これにより、ホスト２が誤ったデータ（Ｓ−ＶＯＬ）にアクセスすることがないようにしている。

一方ストレージ装置１０ｂは、ストレージ装置１０ｂで発生した障害が修復された後、再起動される。再起動後、ストレージ装置１０ｂでは、ヘルスチェックプログラム１００５が実行されることにより、Ｑｕｏｒｕｍ Ｄｉｓｋの読み出し、及びＱｕｏｒｕｍ Ｄｉｓｋから読み出したＤＫＣ管理情報の内容の参照が行われる。本例の場合、Ｑｕｏｒｕｍ Ｄｉｓｋを読み出した結果、ストレージ装置１０ｂはＤＫＣ管理情報［０］．応答不能ＢＭ＿Ａ｛１｝がＯＮになっていることを確認する。これによりストレージ装置１０ｂは、ストレージ装置１０ａはストレージ装置１０ｂが無応答（障害などの要因で停止）になったために、ボリュームペアをＳｕｓｐｅｎｄ状態にしていると理解する。

そのためストレージ装置１０ｂは、ペア管理テーブルＴ３００の各ボリュームペアのペアステータス（Ｔ３０２）を２（Ｓｕｓｐｅｎｄ）にする。またＬＤＥＶステータス情報Ｔ４００に格納されている各論理ボリュームの中で、ストレージ装置１０ａのボリュームとペア関係にある論理ボリュームのＳｔａｔｕｓ（Ｔ４０２）を１（Ｉｎｖａｌｉｄ）にする。これによりストレージ装置１０ｂは、ホスト２から、ストレージ装置１０ａのボリュームとペア関係にあるボリュームに対するＩ／Ｏ要求を受け付けず、ホスト２が誤ったデータにアクセスすることを抑止する。その後ユーザがリシンク指示をストレージ装置１０に発行すると、ストレージ装置１０でリシンク（再同期）が行われ、ストレージ装置１０ａ、１０ｂ内のボリュームペアの状態はＤｕｐｌｅｘ状態になる。リシンクの完了の後、ストレージシステム１は従来通り、正常に稼働を始める。

上で説明した処理の流れでは、ＤＫＣ管理情報［０］．応答不能ＢＭ＿Ａ｛１｝がＯＮになっていなければ、ストレージ装置１０ｂは再起動時に、ボリュームのＳｔａｔｕｓ（Ｔ４０２）をＩｎｖａｌｉｄにしない。再起動時にＤＫＣ管理情報［０］．応答不能ＢＭ＿Ａ｛１｝がＯＮになっていない場合とは、たとえばストレージ装置１０ｂは障害で停止したが、その間ホスト２からライト要求が到来しなかった場合が挙げられる。この場合、ストレージ装置１０ａと１０ｂでボリュームの内容は一致（同期）しているため、再同期の必要がない（Ｄｕｐｌｅｘ状態を維持していてもよい）。そのため、本実施例のストレージシステム１では、ＤＫＣ管理情報［０］．応答不能ＢＭ＿Ａ｛１｝がＯＮになっていなければ、ストレージ装置１０ｂは再起動時に、ボリュームのＳｔａｔｕｓ（Ｔ４０２）をＩｎｖａｌｉｄにしない。ただし別の実施形態として、ストレージ装置１０の再起動時は、各論理ボリュームのＳｔａｔｕｓ（Ｔ４０２）を一律Ｉｎｖａｌｉｄにするようにしてもよい。

（６−２） ＤＫＣ間パスに障害が発生した場合
以下では一例として、ストレージ装置１０ａ、１０ｂ間のパスに障害が発生した場合（ただしストレージ装置１０は正常に稼動している）について説明する。なお、（６−１）と同様、ストレージシステム１にはホスト２とＱｕｏｒｕｍ Ｓｔｏｒａｇｅ１５の他には、２台のストレージ装置１０（ストレージ装置１０ａ及び１０ｂ）のみが存在する構成を例にとって説明する。ストレージ装置１０ａにはＰ−ＶＯＬが存在し、当該Ｐ−ＶＯＬとペア関係にあるＳ−ＶＯＬがストレージ装置１０ｂに存在しているものとする。また、Ｑｕｏｒｕｍ Ｄｉｓｋへの登録処理が行われた結果、ストレージ装置１０ａの配列番号が０、ストレージ装置１０ｂの配列番号が１に決定されているものとする。

（６−１）のケースと同様、ストレージ装置１０ａがホスト２から、Ｐ−ＶＯＬに対するライト要求を受信すると、図９の処理が実行される。図９の処理の実行過程で、Ｓ−ＶＯＬ（Ｓ−ＶＯＬのあるストレージ装置１０ｂ）に対してライト要求を発行するが（図９ Ｓ３）、ＤＫＣ間パスに障害が発生しているためにＳ−ＶＯＬに対するライト処理は失敗する（なお、ＤＫＣ間パスが複数設けられている場合、全てのＤＫＣ間パスに障害が発生している場合に、Ｓ−ＶＯＬに対するライト処理が失敗する）。そのためＩ／Ｏプログラム１００１はＱｕｏｒｕｍ使用のヘルスチェック／ペア状態変更処理プログラム１００６を呼び出す（Ｓ１１）。

（６−１）のケースと同様、この場合Ｑｕｏｒｕｍ使用のヘルスチェック／ペア状態変更処理プログラム１００６が（ペア状態の変更が完了するまで）何回か実行される。１回目のＱｕｏｒｕｍ使用のヘルスチェック／ペア状態変更処理プログラム１００６の実行の際には、（６−１）で説明したものと同様の処理が実行され、自ＤＫＣ管理情報．通信不能ＢＭ＿Ａ｛１｝がＯＮに設定される。

（６−１）のケースでは、ストレージ装置１０ｂが無応答になって、タイムアウト時間が経過した後で、ストレージ装置１０ａでＱｕｏｒｕｍ使用のヘルスチェック／ペア状態変更処理プログラム１００６が実行されると、自ＤＫＣ管理情報．応答不能ＢＭ＿Ａ｛１｝がＯＮにされた（Ｓ２１５）。一方（６−２）のケースでは、ストレージ装置１０ｂは停止していないため、ストレージ装置１０ｂからＱｕｏｒｕｍ Ｄｉｓｋに対する書き込みは継続的に実施される。そのためストレージ装置１０ａにおいて、自ＤＫＣ管理情報．応答不能ＢＭ＿Ａ｛１｝がＯＮにされることはない。

ただし（６−２）のケースでは、ストレージ装置１０ｂは、ストレージ装置１０ｂで定期的に実行されるヘルスチェック処理（Ｓ４１）により、ストレージ装置１０ａがＱｕｏｒｕｍ Ｄｉｓｋに書き込んだ自ＤＫＣ管理情報（ＤＫＣ管理情報［０］）の内容を参照する。そしてそれにより、自ＤＫＣ管理情報．通信不能ＢＭ＿Ａ｛１｝の内容が変化したことを検知する。以下、ストレージ装置１０ｂでヘルスチェック処理が実行されることで生じる、各種管理情報の状態遷移について説明する。なお、以下では、ストレージ装置１０ａが、自ＤＫＣ管理情報．通信不能ＢＭ＿Ａ｛１｝をＯＮにした後の、ストレージ装置１０ｂでの状態推移を説明する。

ストレージ装置１０ｂでヘルスチェック処理が実行されると、Ｑｕｏｒｕｍ使用のヘルスチェック／ペア状態変更処理プログラム１００６が呼び出され、Ｓ１０１〜Ｓ１０７の処理が実行される。このうち、無応答判定処理（Ｓ１０２）では、特に何も行われない。これはストレージ装置１０ａ、１０ｂともに停止していないため、定期的に更新世代番号をＱｕｏｒｕｍ Ｄｉｓｋに書き込んでいるからである。

Ｓ１０３（Ｍ−Ｒ間通信障害通知受領処理）では、ＤＫＣ管理情報［０］．通信不能ＢＭ＿Ａ｛１｝がＯＮになっているため、Ｓ３１３〜Ｓ３１７の処理が実行される。その結果、ストレージ装置１０ｂでは、Ｓ−ＶＯＬを閉塞（Ｉｎｖａｌｉｄ）状態にし（Ｓ３１５）、自ＤＫＣ管理情報．閉塞了承ＢＭ｛０｝（ＤＫＣ管理情報［１］．閉塞了承ＢＭ｛０｝）をＯＮにする（Ｓ３１６）。これによりストレージ装置１０ｂは、ストレージ装置１０ａのボリュームとペア関係にあるボリュームに対するホスト２からのＩ／Ｏ要求を受け付けなくなるので、ホスト２が誤ったデータにアクセスすることを抑止できる。

そしてストレージ装置１０ｂはＳ３１７で、自ＤＫＣ管理情報．通信不能ＢＭ＿Ｂ｛０｝（ＤＫＣ管理情報［１］．通信不能ＢＭ＿Ｂ｛０｝）を「１」にする（つまり、相手ＤＫＣ（ＤＫＣ＃０）が自装置（ＤＫＣ＃１）との間のパスが遮断されたことを検知したという事実を、自装置が検知した旨を記録する）。ここで更新された情報（ＤＫＣ管理情報［１］．閉塞了承ＢＭ｛０｝、ＤＫＣ管理情報［１］．通信不能ＢＭ＿Ｂ｛０｝）は、Ｓ１０６でＱｕｏｒｕｍ Ｄｉｓｋに書き込まれる。

ストレージ装置１０ｂのヘルスチェック処理（Ｓ４１）によってＱｕｏｒｕｍ Ｄｉｓｋに書き込まれた情報は、ストレージ装置１０ａで実行されるＱｕｏｒｕｍ使用のヘルスチェック／ペア状態変更処理プログラム１００６によって読み取られる。ストレージ装置１０ａで実行される、Ｑｕｏｒｕｍ使用のヘルスチェック／ペア状態変更処理プログラム１００６では、ＤＫＣ管理情報［１］．閉塞了承ＢＭ｛０｝がＯＮであることを検知する（Ｓ６０５）。

ＤＫＣ管理情報［１］．閉塞了承ＢＭ｛０｝がＯＮである場合、ＤＫＣ＃１（つまりストレージ装置１０ｂ）では、ＤＫＣ＃０（ストレージ装置１０ａ）とペア関係にあるボリュームがＩｎｖａｌｉｄ状態になっている（また同時にペアステータスはＳｕｓｐｅｎｄ状態になっている）。

そのためストレージ装置１０ａでは、ストレージ装置１０ｂのＳ−ＶＯＬはホスト２からのＩ／Ｏ要求を受け付けられない状態にあると理解することができるので、ストレージ装置１０ａは、ストレージ装置１０ｂとペア関係にあるボリュームペアについて、ペアステータスをＳｕｓｐｅｎｄに変更する（ただしボリュームの状態（ＬＤＥＶステータス情報Ｔ４００のＳｔａｔｕｓ（Ｔ４０２）は、０（Ｖａｌｉｄ）として、ホスト２からのＩ／Ｏを受け付け可能な状態にしておく）。その後、ストレージ装置１０ａは、ホスト２から受け付けているライト要求に係る処理を再開し、ホストに応答を返却する（Ｓ５）。

なお、上の説明では、ホスト２が（ストレージ装置１０ａの）Ｐ−ＶＯＬに対してライト要求を発行した時の、ストレージシステム１の状態の遷移を説明したが、ホスト２がＳ−ＶＯＬ（ストレージ装置１０ｂ）にライト要求を発行した場合も、上で説明したものと同様の処理が行われる。ストレージ装置１０ｂは（ストレージ装置１０ａの）Ｐ−ＶＯＬが閉塞（Ｉｎｖａｌｉｄ）状態になったことを確認して、ライト要求に係る処理を再開する。

（６−３） Ｑｕｏｒｕｍ Ｄｉｓｋへの書き込みが遅延した場合
上で説明した（６−２）のケースでは、ストレージ装置１０ｂは、ストレージ装置１０ｂで定期的にヘルスチェック処理（Ｓ４１）を実行していることが前提のケースである。ただし、ストレージ装置１０ｂで定期的にヘルスチェック処理が行われず、Ｑｕｏｒｕｍ Ｄｉｓｋへの書き込みが遅延する場合もある。これはたとえば、ストレージ装置１０ｂのＭＰ１４１の負荷が高くなりすぎた場合に発生し得る。このような場合でも、ホスト２が誤ったデータにアクセスすることを防ぐ必要がある。

以下では（６−２）と同様に、ストレージ装置１０ａ、１０ｂ間のパスに障害が発生した場合（ただしストレージ装置１０は正常に稼動している）について説明する。なお、ストレージシステム１の構成は、（６−１）または（６−２）で説明したものと同じとする。また（６−３）では、ストレージ装置１０ｂは正常に稼動しているが、ストレージ装置１０ｂのＭＰ１４１が過負荷状態にあるなどの理由で、ヘルスチェック処理を定期的に行うことが出来ない状態にあり、結果として、一定時間以上（たとえば上で述べたタイムアウト時間以上）ヘルスチェック処理が実施されなかった場合を想定する。

この場合、ストレージ装置１０ｂは正常に稼動しているものの、Ｑｕｏｒｕｍ Ｄｉｓｋへのヘルスチェック情報の書き込みが行われないため、ストレージ装置１０ａは（６−１）で説明した場合と同様に、自ＤＫＣ管理情報．応答不能ＢＭ＿Ａ｛１｝をＯＮにし（Ｓ２１５）、ストレージ装置１０ｂとペア関係にあるボリューム（Ｐ−ＶＯＬ）のペアステータスをＳｕｓｐｅｎｄに変更する（Ｓ１０７（自ＤＫＣペア状態変更処理）が実行されることにより、ボリュームのペア状態が変更される）。ただしこの時、ストレージ装置１０ａのボリュームのステータスはＩｎｖａｌｉｄ状態にはされない（Ｖａｌｉｄ状態のままである）。そのため、この後でホスト２からストレージ装置１０ａのボリューム（Ｐ−ＶＯＬ）に対してライト要求が到来した場合には、Ｐ−ＶＯＬへのデータ書き込みが行われる。

一方で、ストレージ装置１０ｂは正常に稼動しているが、ヘルスチェック処理を定期的に行うことが出来ない状態である。そのため、ストレージ装置１０ｂでは、ボリュームのペアステータス（Ｔ３０２）、ボリュームのＳｔａｔｕｓ（Ｔ４０２）は変更されない。つまりストレージ装置１０ｂにおいて、ストレージ装置１０ａのボリュームとペア関係にあるボリュームはいずれも、ペアステータス（Ｔ３０２）は「Ｐａｉｒ」、ボリュームのステータス（Ｔ４０２）は「Ｖａｌｉｄ」状態にある。

ここで、ストレージ装置１０ａにおいてＰ−ＶＯＬのペア状態が（Ｓｕｓｐｅｎｄに）変更された後で、ホスト２がＰ−ＶＯＬのある領域（仮にこの領域のアドレス（ＬＢＡ）がＡであったとする）にデータを書き込んだとすると、そのデータはストレージ装置１０ｂのボリューム（Ｓ−ＶＯＬ）には反映されない。その後ホスト２がＳ−ＶＯＬの同領域（アドレスＡ）のデータをリードする要求をストレージ装置１０ｂに発行した場合、ストレージ装置１０ｂがＳ−ＶＯＬに格納されているデータを返送すると、ホスト２がＰ−ＶＯＬに書き込んだデータは返送されず、誤ったデータが返送されることになる。

本実施例のストレージシステム１では、このような場合にホスト２に誤ったデータが返送されないように、リード要求を受信したときには、以下に説明するような処理が行われる。

図２４は、ストレージ装置１０が論理ボリューム（Ｐ−ＶＯＬまたはＳ−ＶＯＬ）に対するリード要求を受け付けた時に行われる処理の流れを示している。ストレージ装置１０が論理ボリュームに対するリード要求を受け付けると、まずＭＰ１４１は、ペア管理情報Ｔ３００を参照することで、アクセス対象論理ボリュームの状態がＤｕｐｌｅｘ状態か否か確認する（Ｓ５１）。論理ボリュームの状態がＤｕｐｌｅｘ状態でない場合（Ｓ５１：Ｎｏ）、Ｓ５４以降の処理が行われる。

Ｓ５４では、ＭＰ１４１はＬＤＥＶステータス情報Ｔ４００を参照し、アクセス対象論理ボリュームのＳｔａｔｕｓ（Ｔ４０２）が「Ｉｎｖａｌｉｄ」状態か否か判定する。Ｉｎｖａｌｉｄ状態である場合（Ｓ５４：Ｙｅｓ）には、リード要求の要求元（ホスト２など）にエラーを応答し（Ｓ５６）、処理を終了する。Ｖａｌｉｄ状態である場合（Ｓ５４：Ｎｏ）には、アクセス対象ボリュームからデータをリードし、リード要求の要求元（ホスト２など）にリードデータ及び処理が成功した旨の応答を返却し（Ｓ５５）、処理を終了する。

一方、Ｓ５１で論理ボリュームの状態がＤｕｐｌｅｘ状態である場合（Ｓ５１：Ｙｅｓ）、ＭＰ１４１はＱｕｏｒｕｍ格納時刻領域２５０に格納されている時刻情報（以下、これを「格納時刻」と呼ぶ）を読み出す（Ｓ５２）。Ｓ５３では、ＭＰ１４１は現在時刻と格納時刻の差が、所定の上限値を超過しているか否か判定し、所定の上限値を超過していない場合には（Ｓ５３：Ｎｏ）、先に説明したＳ５４以降の処理を行う。所定の上限値を超過している場合には（Ｓ５３：Ｙｅｓ）、所定時間待機し（Ｓ５８）、その後再びＳ５１の処理を実行する。Ｓ５３での上限値とは、一例として、（先に説明したタイムアウト時間−０．５秒）などの時間である。

ストレージ装置１０がヘルスチェック処理等を実行したことによりＱｕｏｒｕｍ Ｄｉｓｋに対するヘルスチェック情報の書き込みを行った場合、Ｑｕｏｒｕｍ格納時刻領域２５０に、そのときの時刻情報を格納する（Ｓ１０６）。そのためＳ５２、Ｓ５３の判定が行われることによって、ＭＰ１４１は、ストレージ装置１０が最後にＱｕｏｒｕｍ Ｄｉｓｋに対する書き込みを行ってからの経過時間を知ることが出来る。

ストレージ装置１０が最後にＱｕｏｒｕｍ Ｄｉｓｋに対する書き込みを行ってからの経過時間が、一定時間（上限値）を超過している場合、ストレージ装置１０でのヘルスチェック処理（Ｑｕｏｒｕｍ Ｄｉｓｋへの書き込み）が遅延している可能性がある。ヘルスチェック処理が遅延している場合、本来はボリュームの状態が（Ｉｎｖａｌｉｄ状態等に）変更される必要があるにもかかわらず、ヘルスチェック処理が遅延しているために、ボリューム状態の適切な変更が行われていない可能性がある。そのためストレージ装置１０では、Ｑｕｏｒｕｍ Ｄｉｓｋへの書き込みが行われるのを待って（Ｓ５８）から、リード処理を行うようにしている。

なお、上で説明した処理の順序は、上で説明した順序に限定されるものではない。ボリュームからのデータリードを行う前に、現在時刻よりも所定時間以内にＱｕｏｒｕｍ Ｄｉｓｋへの書き込みが行われていることが確認できれば良い。そのためたとえばＳ５２、Ｓ５３、Ｓ５８の処理を、Ｓ５１の処理（ペアステータスを確認する処理）の前に実行するようにしてもよい。

（６−３）のケースの説明に戻る。ストレージ装置１０ｂで一定時間以上（たとえば上で述べたタイムアウト時間以上）ヘルスチェック処理が実施されなかった場合に、ストレージ装置１０ｂのＳ−ＶＯＬに対してホスト２からリード要求を受信すると、上で説明した処理（図２４）が行われる。この場合、Ｓ５３で現在時刻と格納時刻が、
（現在時刻―格納時刻）＞上限値
の関係にあると判定されるため、所定時間待機し（Ｓ５８）、ふたたびＳ５１からの処理が行われる。

ここで、リード要求に係る処理が所定時間待機（Ｓ５８）している間に、ストレージ装置１０ｂでヘルスチェック処理（Ｑｕｏｒｕｍ Ｄｉｓｋへの書き込み）が実行された場合を想定する。その場合、ストレージ装置１０ｂは（６−２）で説明した処理を行うため、ストレージ装置１０ｂのボリューム（ストレージ装置１０ａのＰ−ＶＯＬとペア関係にあるボリューム）のステータス（Ｓｔａｔｕｓ（Ｔ４０２））は「Ｉｎｖａｌｉｄ」に変更される（またペアステータスは「Ｓｕｓｐｅｎｄ」にされる）。

リード要求に係る処理では、所定時間待機（Ｓ５８）の後、再びＳ５１からの処理を再開する。そうすると、Ｓ５１の後、ＭＰ１４１はＳ５４の処理を行うが、アクセス対象ボリュームのステータスは「Ｉｎｖａｌｉｄ」に変更されているため、ＭＰ１４１はホスト２にエラーを応答して処理を終了する（つまりホスト２に誤ったデータを返却しない）。

以上が、本発明の実施例に係るストレージシステムの説明である。本発明の実施例に係るストレージシステムは、それぞれが１以上のボリュームを有する第１ストレージ装置と第２ストレージ装置と、第１ストレージ装置と第２ストレージ装置がアクセス可能なＱｕｏｒｕｍ Ｄｉｓｋとで構成され、第１ストレージ装置の第１ボリュームと第２ストレージ装置の第２ボリュームとの間でデータが二重化される。第１ストレージ装置と第２ストレージ装置はまた、Ｑｕｏｒｕｍ Ｄｉｓｋに対して定期的にヘルスチェック情報を書き込むとともに、定期的にＱｕｏｒｕｍ Ｄｉｓｋに書き込まれているヘルスチェック情報を読み出すことによって各ストレージ装置のステータスを確認している。

各ストレージ装置がＱｕｏｒｕｍ Ｄｉｓｋに対して、定期的にヘルスチェック情報を書き込んでいるため、第１ストレージ装置から第２ストレージ装置へのデータ転送が失敗した場合、第１ストレージ装置は第２ストレージ装置の書き込んだヘルスチェック情報を確認することで、第２ストレージ装置が停止した状態にあるのか否か、あるいは第２ボリュームがＩ／Ｏ不可の状態にあるのか否かを判断することができる。

特に、第１ストレージ装置と第２ストレージ装置との間でのデータ二重化ができない状態だが、第２ストレージ装置が停止していない場合（たとえばＤＫＣ間パスが遮断された場合が該当する）、第２ストレージ装置を停止させないままにしておくと、ホストが誤ったデータにアクセスする事態を招くことがある。たとえばホストから第１ストレージ装置へのアクセスが継続され、その後ホストが第２ストレージ装置へのアクセスへとアクセスパスを切り替えた時、第２ボリュームには第１ボリュームよりも古いデータしか格納されていないからである。そのため、このような場合には、第１ストレージ装置は第２ストレージ装置を停止させてから、ホストからのアクセスを継続する必要がある。

本発明の実施例に係るストレージシステムでは、ＤＫＣ間パスを介した第１ストレージ装置から第２ストレージ装置へのデータ転送が失敗した際、第１ストレージ装置はＱｕｏｒｕｍ Ｄｉｓｋ上の通信不能ビットマップに、ＤＫＣ間パスを介した第２ストレージ装置との通信が不可能な状態にある旨の情報を書き込む。一方第２ストレージ装置では、定期的なＱｕｏｒｕｍ Ｄｉｓｋの読み出しを行うことによって、第１ストレージ装置がＤＫＣ間パスを介した第２ストレージ装置との通信が不可能な状態にある旨を検知する。これに応じて第２ストレージ装置では、第２ボリュームを閉塞させて、ホストからのＩ／Ｏを受け付け不可能な状態にする。そしてＱｕｏｒｕｍ Ｄｉｓｋには、「第１ストレージ装置が第２ストレージ装置との通信が不可能な状態にある旨を検知した」ことを第２ストレージ装置が確認した旨の情報、及び第２ボリュームを閉塞させた（Ｉ／Ｏ不可の状態にした）旨の情報を格納する。

第１ストレージ装置は定期的にＱｕｏｒｕｍ Ｄｉｓｋ上の情報をチェックし、第２ボリュームが閉塞された旨の情報を検知した時点で、Ｉ／Ｏ処理を再開させる。これにより、第１ストレージ装置は、第２ストレージ装置の第２ボリュームが閉塞になったことを確認してから、ホストからのＩ／Ｏ処理を再開するため、ホストが誤ったデータにアクセスすることを防ぐことができる。

以上、本発明の実施例を説明してきたが、これは本発明の説明のための例示であって、本発明を上で説明した実施例に限定する趣旨ではない。本発明は、他の種々の形態でも実施可能である。実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。

各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の記録装置、または、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置いてもよい。また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。

１: ストレージシステム
２: ホスト
６: ＳＡＮ
１０ａ: ストレージ装置
１０ｂ: ストレージ装置
１１: ストレージコントローラ
１２: ディスクユニット
１５: Ｑｕｏｒｕｍ Ｓｔｏｒａｇｅ
１１１: ＭＰＢ
１１２: ＦＥＰＫ
１１３: ＢＥＰＫ
１１４: ＣＭＰＫ
１１５: スイッチ（ＳＷ）
１２１: ドライブ
１４１: ＭＰ
１４２: ＬＭ
１４３: ＳＭ
１４４: ＣＭ

Claims (12)

1. 第１ストレージ装置と、装置間パスを介して前記第１ストレージ装置に接続された第２ストレージ装置と、前記第１ストレージ装置及び前記第２ストレージ装置に接続された第３ストレージ装置とから構成されるストレージシステムであって、
   前記第１ストレージ装置と前記第２ストレージ装置はそれぞれ、ボリュームと、１以上の記憶デバイスを有し、定期的に前記第３ストレージ装置にヘルスチェック情報を書き込むように構成されており、
   前記第１ストレージ装置は、ホスト計算機から前記第１ストレージ装置内の第１ボリュームに対するライトデータ及び該ライトデータのライト要求を受け付けると、前記第１ボリュームに前記ライトデータを書き込むとともに、前記装置間パスを介して前記第２ストレージ装置に、前記第２ストレージ装置内の第２ボリュームに前記ライトデータを書き込む指示を発行するよう構成され、
   前記第２ストレージ装置は、前記ホスト計算機から前記第２ボリュームに対するライトデータ及び該ライトデータのライト要求を受け付けると、前記装置間パスを介して前記第１ストレージ装置に、前記第１ボリュームに前記ライトデータを書き込む指示を発行するとともに、前記第２ボリュームに前記ライトデータを書き込むように構成されており、
   前記第１ストレージ装置は、前記ホスト計算機から受け付けた前記ライト要求の処理中に、前記第２ボリュームへのライトデータの書き込みに失敗した場合、
   前記第３ストレージ装置に書き込まれた前記ヘルスチェック情報を読み出し、
   前記読み出したヘルスチェック情報に基づいて、前記第２ボリュームがＩ／Ｏ不可状態にあるか否かを判断し、
   前記第２ボリュームがＩ／Ｏ不可状態にあると判断した後、前記ライト要求に係る処理を再開する、
   ことを特徴とする、ストレージシステム。
2. 前記第２ストレージ装置は、前記ホスト計算機から受け付けた前記ライト要求の処理中に、前記第１ボリュームへのライトデータの書き込みに失敗した場合、
   前記第３ストレージ装置に書き込まれた前記ヘルスチェック情報を読み出し、
   前記読み出したヘルスチェック情報に基づいて、前記第１ボリュームがＩ／Ｏ不可状態にあるか否かを判断し、
   前記第１ボリュームがＩ／Ｏ不可状態にあると判断した後、前記ライト要求に係る処理を再開する、
   ことを特徴とする、請求項１に記載のストレージシステム。
3. 前記第１ストレージ装置は、前記ホスト計算機から受け付けたライト要求の処理中に、前記第２ボリュームへのライトデータの書き込みに失敗した場合、
   前記装置間パスを介した通信ができない状態である旨を表す情報を、前記ヘルスチェック情報に含めて前記第３ストレージ装置に格納し、
   前記第２ストレージ装置は、前記第１ストレージ装置が格納した前記ヘルスチェック情報の中に、前記装置間パスを介した通信ができない状態である旨を表す情報が含まれていることを確認すると、前記第２ボリュームをＩ／Ｏ不可状態にする、
   ことを特徴とする、請求項１に記載のストレージシステム。
4. 前記第２ストレージ装置は、前記第２ボリュームをＩ／Ｏ不可状態にした後、前記第２ボリュームがＩ／Ｏ不可状態にある旨を表す情報を前記ヘルスチェック情報に含めて前記第３ストレージ装置に格納し、
   前記第１ストレージ装置は、前記第２ストレージ装置が格納した前記ヘルスチェック情報の中に、前記第２ボリュームがＩ／Ｏ不可状態にある旨を表す情報が含まれていることを確認すると、前記ライト要求に係る処理を再開する、
   ことを特徴とする、請求項３に記載のストレージシステム。
5. 前記第１ストレージ装置は、前記第３ストレージ装置に書き込まれた前記ヘルスチェック情報を読み出した時、前記第２ストレージ装置が前記ヘルスチェック情報を所定時間以上の間、前記第３ストレージ装置に書き込んでいないか否かを判断し、
   前記第２ストレージ装置が前記ヘルスチェック情報を所定時間以上、前記第３ストレージ装置に書き込んでいない場合、前記第１ストレージ装置は前記第２ストレージ装置が停止状態にあると判断する、
   ことを特徴とする、請求項１に記載のストレージシステム。
6. 前記第１ストレージ装置及び前記第２ストレージ装置は、前記ヘルスチェック情報の更新回数に相当する値である更新世代番号を、前記ヘルスチェック情報に含めて前記第３ストレージ装置に格納するよう構成されており、
   前記第１ストレージ装置は、前記第２ストレージ装置の書き込んだ更新世代番号が、所定時間以上の間変更されていない場合、前記第２ストレージ装置が停止状態にあると判断することを特徴とする、
   請求項５に記載のストレージシステム。
7. 前記第１ストレージ装置は、前記第３ストレージ装置に書き込まれた前記ヘルスチェック情報を読み出すたびに、前記ヘルスチェック情報に含まれる、前記第２ストレージ装置の書き込んだ更新世代番号を記録しており、
   前記第１ストレージ装置はまた、前記第３ストレージ装置に書き込まれた前記ヘルスチェック情報を読み出すと、前記読み出されたヘルスチェック情報に含まれる前記第２ストレージ装置の書き込んだ更新世代番号が、前記記録されている更新世代番号と同じか否かを判定することによって、前記第２ストレージ装置の書き込んだ更新世代番号が変更されていないことを判定することを特徴とする、
   請求項６に記載のストレージシステム。
8. 前記第１ストレージ装置は、前記ヘルスチェック情報に含まれる、前記第２ストレージ装置の書き込んだ更新世代番号が、前記記録されている更新世代番号と同じであることを、初めて検知した時点の時刻を記録しておき、
   前記第１ストレージ装置が、前記記録された時刻から所定時間以上経過した後に前記第３ストレージ装置に書き込まれた前記ヘルスチェック情報を読み出した時、
   前記読み出されたヘルスチェック情報に含まれる前記第２ストレージ装置の書き込んだ更新世代番号と、前記記録されている更新世代番号が同じである場合、前記第２ストレージ装置の書き込んだ更新世代番号が所定時間以上の間更新されていないと判断することを特徴とする、
   請求項７に記載のストレージシステム。
9. 前記第１ストレージ装置は前記第２ストレージ装置が停止状態にあると判断すると、前記第２ストレージ装置が停止状態にある旨を表す情報を前記ヘルスチェック情報に含めて前記第３ストレージ装置に書き込み、
   前記第２ストレージ装置は起動時に、第３ストレージ装置から前記ヘルスチェック情報を読み出し、
   前記ヘルスチェック情報に、前記第２ストレージ装置が停止状態にある旨を表す情報が前記第１ストレージ装置によって書き込まれていることを検出すると、
   前記第２ボリュームをＩ／Ｏ不可状態にすることを特徴とする、
   請求項５に記載のストレージシステム。
10. 前記第２ストレージ装置は、前記第１ボリュームがＩ／Ｏ不可状態にあることを確認した後、前記第２ボリュームに前記ライトデータを書き込むことを特徴とする、
    請求項２に記載のストレージシステム。
11. 前記第１ストレージ装置及び前記第２ストレージ装置は、前記第３ストレージ装置に前記ヘルスチェック情報を書き込むたびに、前記ヘルスチェック情報を書き込んだ時刻を記憶しており、
    前記第２ストレージ装置は、前記ホスト計算機から前記第２ボリュームに対するリード要求を受け付けると、
    前記記憶された時刻に基づいて、前記第２ストレージ装置が前記ヘルスチェック情報を一定時間以内に更新したか判定し、
    前記ヘルスチェック情報が一定時間以内に更新されていない場合、前記ヘルスチェック情報が更新されるまで、前記リード要求に係る処理を所定時間待機する、
    ことを特徴とする、請求項１に記載のストレージシステム。
12. 前記ヘルスチェック情報が一定時間以内に更新されている場合、前記第２ボリュームからデータをリードして、前記ホスト計算機に返送する、
    ことを特徴とする、請求項１１に記載のストレージシステム。

Images