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

Abstract

【課題】 リモートコピーに障害が発生した場合に、古いデータを記憶するボリュームに基づいて誤った制御が行われるのを未然に防止する。
【解決手段】 ストレージシステムは、第１サイト１Ａと第２サイト１ＢとをネットワークＣＮ１，ＣＮ２で接続して構成される。各ホストコンピュータ３Ａ１，３Ｂ１等には、それぞれ基準指示部５が設けられている。基準指示部５は、リモートコピーに障害が発生した場合に、いずれのサイト（ボリューム）に最新のデータが記憶されているかを特定し、管理する。これにより、リモートコピーの障害発生後に、最新のデータを利用可能なサイト内でフェイルオーバ等を行うことができる。
【選択図】 図１

Description

本発明は、ストレージシステム及びストレージシステムの制御方法に関する。

地理的に離れた複数のサイトにそれぞれ記憶装置を設け、各サイト間を通信ネットワークを介して相互に接続するストレージシステムは、知られている（特許文献１）。このようなストレージシステムでは、いわゆるリモートコピーと呼ばれる技術によって、各サイトに設置された記憶装置の記憶内容を一致させる。従って、いずれかのサイトが使用不能となった場合でも、残された正常なサイトを利用して、業務サービスを引き続き提供することができる。

リモートコピーとは、上位装置としてのホストコンピュータやサーバを介在させることなく、物理的に離れた複数の記憶装置間で、記憶内容を一致させる技術をいう。リモートコピーを行う場合、一方のサイトの記憶装置内にコピー元となる論理ボリュームを用意し、他方のサイトの記憶装置内にコピー先となる論理ボリュームを用意する。これら２つの論理ボリュームは、コピーペアを形成し、コピー元の論理ボリュームにおいてデータが更新された場合、この更新はコピー先の論理ボリュームに反映される。

なお、複数のサーバを疎結合させて一つの集合体を構成し、あたかも一つのサーバであるかのようにして、クライアントマシンへのサービスを提供するクラスタシステムも知られている。
米国特許第５７４２７９２号明細書

物理的に離れた複数のサイト間でデータ内容を同期させ、各サイト毎にそれぞれ別々のサーバにストレージサービスを提供するような場合、もしもリモートコピー機能に障害が発生すると、各サイト間でデータを同期させることができない。従って、各サイト間でデータ内容に相違が生じる。この状態でストレージサービスを提供すると、コピー先論理ボリュームを有するサイトでは、更新データが反映されていない古いデータ群を用いて、誤った運用が行われる可能性がある。

ところで、耐障害性を向上させるために、リモートコピー技術に加えて、クラスタシステムを採用することも考えられる。しかし、クラスタシステムでは、単に、フェイルオーバ元のサーバとフェイルオーバ先のサーバとによって、共有論理ボリュームを排他的に使用しているに過ぎない。クラスタシステムでは、共有された論理ボリュームを単一のボリュームとして認識するだけであり、別々のサイトに設けられた異なる論理ボリューム間でデータが同期しているか否かまでは考慮していない。従って、単純にクラスタシステムとリモートコピー技術とを組み合わせただけでは、有効なディザスタリカバリシステムを構築することはできない。

そこで、本発明の一つの目的は、複数サイトにそれぞれ設けられた記憶装置間の記憶内容を同期させる処理に障害が発生した場合でも、誤った運用が行われるのを未然に防止し、信頼性を向上できるようにしたストレージシステム及びストレージシステムの制御方法を提供することにある。本発明の一つの目的は、フェイルオーバ処理と同期処理とを整合させて、有効なディザスタリカバリシステムを構築可能としたストレージシステム及びストレージシステムの制御方法を提供することにある。本発明の一つの目的は、ホストコンピュータやネットワークに過大な負荷をかけることなく、最新のデータ群を保持する記憶装置を必要なタイミングで特定し、同期障害への耐久性を向上できるようにしたストレージシステム及びストレージシステムの制御方法を提供することにある。本発明のさらなる目的は、後述する実施形態の記載から明らかになるであろう。

上記課題を解決すべく、本発明のストレージシステムは、複数のホストコンピュータ及びこれら各ホストコンピュータに論理ボリュームをそれぞれ提供する記憶装置をそれぞれ備える複数のサイトと、各サイトを互いに通信可能に接続するサイト間ネットワークと、サイト間ネットワークを介して、各記憶装置の論理ボリュームを同期させる同期部と、同期部による処理に同期障害が発生した場合において、基準となるべき記憶装置を指示するための基準指示情報を管理する基準管理部と、基準指示情報に基づいて論理ボリュームの使用を制御する制御部と、を備える。

複数のサイトは物理的に離れており、サイト間ネットワークを介して通信可能に接続されている。各サイトには、それぞれ複数のホストコンピュータ及び少なくとも一つ以上の記憶装置が設けられている。各記憶装置は、例えば、ハードディスクドライブや半導体メモリドライブあるいは光ディスクドライブ等のような複数の記憶デバイスを備えたディスクアレイ装置として構成可能である。複数の記憶デバイスが提供する物理的な記憶領域上には、論理的な記憶領域である論理ボリュームが形成される。各サイト内で、各ホストコンピュータは、それぞれに割り当てられた論理ボリュームにアクセスし、データの読み書きを行う。

各サイトの論理ボリュームのうち同期対象として指定されている論理ボリュームは、同期部によって定期的にまたは不定期に、その記憶内容が同期される。即ち、一方の論理ボリュームがコピー元、他方の論理ボリュームがコピー先としてそれぞれ設定され、同期部は、コピー元の論理ボリュームで更新されたデータを、コピー先の論理ボリュームに転送して書き込ませる。このような物理的に離れたサイト間で記憶内容を一致させる処理は、リモートコピー技術とも呼ばれる。同一の更新データを両方の論理ボリュームにそれぞれ書き込むことにより、コピー元の論理ボリュームの記憶内容とコピー先の論理ボリュームの記憶内容とを一致させることができる。コピー先の論理ボリュームへ更新データを反映させるタイミングとしては、同期式と非同期式とが知られている。詳細はさらに後述するが、同期式の場合は、コピー元の論理ボリュームに更新データを書き込むと略同時に、コピー先の論理ボリュームにも更新データを書き込む。非同期式の場合は、コピー元の論理ボリュームに更新データを書き込んだ後、所定のタイミングで、コピー先の論理ボリュームに更新データを転送する。

例えば、サイト間ネットワークの通信障害や記憶装置内部の障害等により、同期処理を正常に実行できない場合がある。同期処理の正常な実行に影響を与える障害を、ここでは、同期障害と呼ぶ。基準管理部は、基準指示情報を管理する。基準指示情報とは、同期障害が発生した場合において、基準となるべき記憶装置を指し示す情報である。

例えば、一方のサイトの論理ボリューム（コピー元）から他方のサイトの論理ボリューム（コピー先）にデータをコピーしている場合において、同期処理に障害が発生すると、コピー元の論理ボリュームにおける更新内容をコピー先の論理ボリュームに反映させることができない。この場合、最新のデータを保持しているのは、コピー元の論理ボリュームであり、コピー先の論理ボリュームには、同期障害が発生する前の古いデータが保持されている。従って、この場合は、コピー元の論理ボリュームを有する記憶装置が、基準となるべき記憶装置となる。即ち、基準指示情報は、最新のデータを保持している記憶装置（あるいはその記憶装置を有するサイト、またはその記憶装置が有する論理ボリューム）を特定するための情報である。同期障害の発生時には、基準指示情報を参照することにより、２つの論理ボリュームのうちいずれの論理ボリュームが最新のデータを保持しているかを判別することができる。従って、制御部は、例えば、古いデータを記憶する論理ボリュームへのアクセスを中止する等のような制御を行うことができる。

同期部と、基準管理部と、制御部とは、各サイトにそれぞれ設けることができる。これらの各部は、各サイトの各ホストコンピュータにそれぞれ設けることができる。または、同期部と制御部とは、各サイトの各ホストコンピュータにそれぞれ設け、基準管理部は、各サイトの記憶装置にそれぞれ設けることもできる。

各サイトの各ホストコンピュータにより、全体として一つのクラスタを構成することができる。そして、制御部は、障害の発生したホストコンピュータで提供されていた所定のサービスを正常な他のホストコンピュータに引き継がせるフェイルオーバ処理を制御することができる。現在運用されているホストコンピュータが機能を停止した場合、そのホストコンピュータからクライアントマシンに提供されていた情報処理サービス（業務処理サービス）は、待機しているホストコンピュータに引き継がれる。待機していたホストコンピュータは、機能を停止したホストコンピュータが使用している論理ボリュームの使用権限や、ＩＰアドレス等の各種ネットワーク設定情報等を受け継いで、クライアントマシンへの情報処理サービスを再開する。機能を停止した現用系ホストコンピュータから待機系ホストコンピュータへ情報処理サービスの実行を肩代わりさせる処理を、フェイルオーバ処理と呼ぶ。現用系ホストコンピュータの機能が回復し、待機系ホストコンピュータから現用系ホストコンピュータに情報処理サービスの実行を戻す処理を、フェイルバック処理と呼ぶ。

制御部は、基準指示情報に基づいて、フェイルオーバ処理等を行うことができる。例えば、同期障害が発生し、コピーペアを形成する複数の論理ボリューム間で記憶内容が不一致となった場合、最新データを記憶する論理ボリュームを利用可能なホストコンピュータが、フェイルオーバ処理を実行する。

基準管理部は、各サイトのうち基準指示情報の通知を必要とする所定のサイトに、基準指示情報をそれぞれ通知することができる。例えば、基準管理部が各サイトにそれぞれ設けられている場合、同期障害の発生したサイトは、既に同期障害の発生を認識しているので、通知する必要はない。「基準指示情報の通知を必要とする所定のサイト」とは、同期障害の発生したサイト以外の他のサイトを意味する。通知を受けたサイトでは、例えば、半導体メモリやハードディスクドライブ等から構成可能な基準指示情報記憶部に、基準指示情報を格納することができる。

複数の通知をサイトが受信する場合も考えられる。この場合、複数の通知を受信したサイトは、いずれか古い方の基準指示情報を保持することができる。古い方の基準指示情報は、より以前に発行されたものであり、その古い方の基準指示情報を発行したサイトでは、更新データの差分が蓄積されていると考えられる。そこで、古い方の基準指示情報を採用する。

基準管理部による所定のサイトへの通知が正常に完了した場合に、論理ボリュームの使用を許可することができる。即ち、どのサイトが最新データを有するかを、全てのサイトが認識した後で、論理ボリュームの使用を許可することができる。この後、例えば、フェイルオーバ処理が実行されるような場合、各サイトの各ホストコンピュータは、自己の使用する論理ボリュームが最新のデータを記憶しているか否かを判断し、フェイルオーバ先ホストコンピュータとして作動するか否かを決定することができる。

基準指示情報には、予め優先サイトを示す情報を対応付けることもできる。そして、基準管理部による所定のサイトへの通知が正常に完了しなかった場合でも、優先サイトへの通知が正常に完了した場合には、論理ボリュームの使用を許可することもできる。

最新の基準指示情報は、各サイトにそれぞれ通知され、各サイトでそれぞれ保持されるが、例えば、通信障害等の発生により、一部のサイトへの通知が正常に完了しない場合もあり得る。そこで、全サイトへの通知が完了しない場合でも、予め設定された優先サイトへの通知が正常に完了している場合は、論理ボリュームの使用を許可する。優先サイトとは、同期障害が発生した場合に基準として優先的に選択されるサイトであり、システム管理者等によって予め設定される。

優先サイトには、予め指定された所定のサイト、障害発生前における運用サイト、障害発生前における待機サイトのうち、少なくともいずれか一つまたは複数を設定することができる。例えば、複数のサイトのうち、いずれか一つのサイトを優先サイトとして予め指定することができる。例えば、同期障害が発生する前に、情報処理サービスを提供していたサイト（運用サイト）を、優先サイトとして予め設定しておくことができる。例えば、同期障害が発生する前に、待機サイトであったサイトを優先サイトとして予め設定することができる。基準指示情報は、同期処理の対象となる論理ボリュームのペア毎にそれぞれ設定することができる。従って、同期処理の対象となる論理ボリュームのペアが複数存在する場合は、各ペア毎にそれぞれ異なる優先サイトを指定することもできる。

基準管理部は、同期障害の発生が検出された場合に、基準指示情報を更新させることができる。例えば、同期障害が発生する前においても、所定時間毎に基準指示情報を更新し、各サイトに通知する構成も考えられる。しかし、この場合は、更新周期等によっても相違するが、基準指示情報の更新処理、基準指示情報の通知処理、基準指示情報を受信して記憶する処理が頻繁に実行される可能性がある。従って、ホストコンピュータや通信ネットワークの負荷が増加する。また、基準指示情報が各サイトで利用されるのは、同期障害が発生した後である。そこで、同期障害の発生が検出された場合に、基準指示情報を更新させる。これにより、ホストコンピュータ等に大きな負担をかけずに、基準指示情報を更新（生成）させることができる。なお、本発明は、同期障害の発生前に基準指示情報を生成または更新させる構成を意図的に放棄するものではない。特許請求の範囲の記載によっては、このような構成も本発明の範囲に含まれる。

サイト間ネットワークは、各サイトの記憶装置同士を通信可能に接続する記憶装置間ネットワークと、各サイトの各ホストコンピュータ同士を通信可能に接続するホストコンピュータ間ネットワークとを含んで構成することができる。そして、同期部は、記憶装置間ネットワークを介して、各記憶装置の論理ボリュームを同期させ、基準管理部は、ホストコンピュータ間ネットワークを介して、各サイトのうち基準指示情報の通知を必要とする所定のサイトに、基準指示情報をそれぞれ通知する。このように、同期処理で用いるネットワークとは別系統のネットワークを介して、基準指示情報を各サイトに通知させることにより、記憶装置間ネットワークの故障等によって同期障害が発生した場合でも、基準指示情報を各サイトに通知することができる。

サイト間ネットワークは、さらに、各サイト内で各ホストコンピュータと記憶装置とを通信可能に接続するサイト内ネットワーク同士を通信可能に接続するサイト内ネットワーク間ネットワークを含むことができる。そして、基準管理部は、ホストコンピュータ間ネットワークまたはサイト内ネットワーク間ネットワークのいずれか一つを介して、各サイトのうち基準指示情報の通知を必要とする所定のサイトに、基準指示情報をそれぞれ通知することもできる。

各サイトの各ホストコンピュータのうち、所定のホストコンピュータにのみ基準指示情報を保持させ、他のホストコンピュータは所定のホストコンピュータにアクセスすることにより、基準指示情報を利用する構成でもよい。

同期部は、同期障害が解消した場合に、基準指示情報に示されている記憶装置をコピー元の記憶装置として、同期処理を実行することもできる。これにより、障害回復後に、最新データを記憶する記憶装置から他の記憶装置に最新データを転送し、両者の記憶内容を一致させることができる。

そして、障害回復後の同期処理が正常に完了した場合、基準管理部は、基準指示情報をリセットすることができる。

本発明の機能、手段、ステップの全部または一部は、例えば、マイクロコンピュータにより実行されるコンピュータプログラムとして構成可能な場合がある。そして、このコンピュータプログラムは、例えば、ハードディスク、光ディスク、半導体メモリ等の記憶媒体に固定して配布することができる。または、コンピュータプログラムをインターネット等の通信ネットワークを介して、配信することもできる。

以下、図面に基づき、本発明の実施の形態を説明する。図１は、本実施形態の全体概念図である。詳細はさらに後述するが、図１に示すように、本実施形態のストレージシステムは、複数の第１ホストコンピュータ（３Ａ１，３Ａ２）及びこれら各第１ホストコンピュータ（３Ａ１，３Ａ２）に論理ボリュームをそれぞれ提供する第１記憶装置（２Ａ）を有する第１サイト（１Ａ）と、複数の第２ホストコンピュータ（３Ｂ１，３Ｂ２）及びこれら各第２ホストコンピュータ（３Ｂ１，３Ｂ２）に論理ボリュームをそれぞれ提供する第２記憶装置（２Ｂ）を有する第２サイト（１Ｂ）と、第１サイト（１Ａ）内で、各第１ホストコンピュータ（３Ａ１，３Ａ２）と第１記憶装置（２Ａ）とを通信可能に接続する第１サイト内ネットワーク（ＣＮ３Ａ）と、第２サイト（１Ｂ）内で、各第２ホストコンピュータ（３Ｂ１，３Ｂ２）と第２記憶装置（２Ｂ）とを通信可能に接続する第２サイト内ネットワーク（ＣＮ３Ｂ）と、第１記憶装置（２Ａ）と第２記憶装置（２Ｂ）とを通信可能に接続する記憶装置間ネットワーク（ＣＮ１）と、各第１ホストコンピュータ（３Ａ１，３Ａ２）と各第２ホストコンピュータ（３Ｂ１，３Ｂ２）とを通信可能に接続するホストコンピュータ間ネットワーク（ＣＮ２）と、を備えている。

そして、本実施形態では、各第１ホストコンピュータ（３Ａ１，３Ａ２）及び各第２ホストコンピュータ（３Ｂ１，３Ｂ２）に、各第１，第２ホストコンピュータ（３Ａ１，３Ａ２，３Ｂ１，３Ｂ２）を全体として一つのクラスタに構成するクラスタ制御部（４）と、記憶装置間ネットワーク（ＣＮ１）を介して、第１記憶装置（２Ａ）の論理ボリュームと第２記憶装置（２Ｂ）の論理ボリュームとを同期させる同期部（後述の実施例を参照）と、同期部による処理に同期障害が発生した場合に、第１記憶装置（２Ａ）と第２記憶装置（２Ｂ）のいずれを基準とすべきかを指示するための基準指示情報を管理する基準管理部（５）とを、それぞれ設けてある。

基準管理部（５）は、同期障害の発生が検出された場合に、基準指示情報を更新して、相手方のサイト（１Ａまたは１Ｂ）に基準指示情報を通知する。クラスタ制御部（４）は、フェイルオーバ発生原因となる障害が発生した場合に、基準指示情報に基づいて、フェイルオーバ処理を実行する。

以上が本実施形態の全体構成の概要である。各部の構成をさらに詳しく述べると、サイト１Ａとサイト１Ｂとは、例えば、ある都市と別のある都市、同一構内のある建物と別のある建物等のように、物理的に離れて設けられる。ここで、例えば、サイト１Ａは、図示せぬ多数のクライアントマシンに対して情報処理サービスを提供する現用系サイトであり、サイト１Ｂは、サイト１Ａに不測の事態が発生した場合のバックアップとなる待機系サイトである。

各サイト１Ａ、１Ｂには、それぞれ複数のホストコンピュータ及び一つ以上の記憶装置が設けられている。記憶装置２Ａ，２Ｂは、例えば、ディスクアレイサブシステム等のような大容量の外部記憶装置システムとして構成される。記憶装置２Ａ，２Ｂは、それぞれのホストコンピュータに対して論理ボリュームを提供する。

ホストコンピュータ３Ａ１，３Ａ２，３Ｂ１，３Ｂ２（以下、全体としてホストコンピュータ３）は、例えば、サーバマシンとして構成される。ホストコンピュータ３は、自己に割り当てられた論理ボリュームにアクセスし、データの読み書きを行う。また、ホストコンピュータ３は、クラスタを構成している。

通常時には、図１中の上側に示すように、サイト１Ａの各ホストコンピュータ３Ａ１，３Ａ２からクライアントマシンに対して、情報処理サービスが提供される。同期障害（リモートコピー障害）が発生する前の通常状態では、基準指示情報に「ノーマル」状態が設定される。

図１中の下側に示すように、例えば、ケーブルの断線やリンク障害等を原因として、記憶装置間ネットワークＣＮ１を介した同期処理に障害が発生した場合を考える。この場合は、サイト１Ａの記憶装置２Ａに書き込まれたデータを、サイト１Ｂの記憶装置２Ｂに転送することができない。同期障害が発生した後も、サイト１Ａでは、各ホストコンピュータ３Ａ１，３Ａ２のいずれかまたは両方が、クライアントマシンからの要求に応じて記憶装置２Ａにアクセスし、データの更新を続ける。サイト１Ａの記憶装置２Ａには、差分データ６が蓄積されていく。差分データ６は、コピーペアを形成する２つの論理ボリュームの間に生じたデータ群であり、コピー元の記憶装置２Ａ内で発生し、蓄積される。

同期障害の発生が検出されると、基準指示情報は、「ノーマル」状態から「第１サイト（１Ａ）」状態に変更される。「第１サイト」状態とは、最新のデータを保有するサイトが第１サイト１Ａであることを示している。もしも、同期障害が回復する前に、ホストコンピュータ３Ａ１が機能を停止した場合は、フェイルオーバ処理が実行される。ホストコンピュータ３は、自己の使用可能な記憶装置が最新のデータを保持しているか否かに基づいて、フェイルオーバ処理を行うか否かを決定する。

図１に示す例では、最新データは記憶装置２Ａに保持されている。従って、この記憶装置２Ａを利用可能なホストコンピュータ３Ａ２がフェイルオーバ処理を実行する。第２サイト１Ｂのホストコンピュータ３Ｂ１，３Ｂ２は、基準指示情報に示された記憶装置２Ａを利用することができないので、フェイルオーバ処理を実行しない。これにより、同期障害の発生した後で、古いデータに基づく誤った運用が開始されるのを防止することができ、ストレージシステムの信頼性を高めることができる。また、フェイルオーバ先の候補となるホストコンピュータが複数存在する場合でも、最新のデータにアクセス可能か否かに基づいて、適切なフェイルオーバ先コンピュータを選択することができる。これにより、システム管理者が明示の指示を与えることなく、自動的に適切なホストコンピュータでフェイルオーバ処理を実行させることができ、使い勝手が向上する。以下、本実施形態をより詳細に説明する。

図２は、ストレージシステムの全体概要を示すブロック図である。このストレージシステムは、例えば、第１サイト１０Ａと、第２サイト１０Ｂとを備えており、各サイト１０Ａ，１０Ｂ間は、通信ネットワークＣＮ１２，ＣＮ１３によって接続されている。なお、後述の実施例からも明らかなように、ストレージシステムは３つ以上のサイトから構成することもできる。

第１サイト１０Ａと第２サイト１０Ｂとは、例えば、別々の都市に設置することができる。また、第１サイト１０Ａと第２サイト１０Ｂとは、例えば、同一行政区画に位置する異なる地点に設置することもできる。さらに、第１サイト１０Ａと第２サイト１０Ｂとは、例えば、同一敷地内のそれぞれ異なる建物内に設けることもできる。

第１サイト１０Ａと第２サイト１０Ｂとは、基本的に同一構造を備える。ディザスタリカバリシステムとしての機能を発揮可能であれば、両サイト１０Ａ，１０Ｂは異なる構成であってもよい。一つの例として、第１サイト１０Ａは、図外のクライアントマシンに対して情報処理サービスを提供する現用系サイト（稼働系サイト）である。第２サイト１０Ｂは、第１サイト１０Ａに障害が発生した場合にバックアップするバックアップサイト（待機系サイト）である。

もっとも、サイト全体を稼働系または待機系のいずれか一方として使用する必要はなく、情報処理サービスを提供するアプリケーションプログラム毎に、稼働系サイトと待機系サイトとをそれぞれ設定してもよい。例えば、第１のアプリケーションプログラムの稼働系サイトを第１サイト１０Ａとし、第２のアプリケーションプログラムの稼働系サイトを第２サイト１０Ｂとすることもできる。

第１サイト１０Ａは、複数のホストコンピュータＨＡ１，ＨＡｎと、記憶装置システム２０Ａとを備えている。各ホストコンピュータＨＡ１，ＨＡｎは、図３と共に後述するように、マイクロコンピュータを用いたサーバマシンとして構成される。各ホストコンピュータＨＡ１，ＨＡｎは、データ最新性保障モジュール３０と、クラスタソフトウェア４０と、リモートコピー制御モジュール５０とを、それぞれ備えている。これら各ソフトウェア３０，４０，５０の詳細は、図４と共に後述する。

記憶装置システム２０Ａは、例えば、ディスクアレイサブシステムとして構成することができる。記憶装置システム２０Ａは、後述のように、複数の論理ボリューム２１２を備えており、これらの論理ボリューム２１２は、ホストコンピュータＨＡ１，ＨＡｎによって利用される。

各ホストコンピュータＨＡ１，ＨＡｎは、サイト内の通信ネットワークＣＮ１１を介して、記憶装置システム２０Ａと接続されている。この通信ネットワークＣＮ１１は、例えば、SAN（Storage Area Network）として構成され、ファイバチャネルプロトコルに従ってデータ通信を行う。

各ホストコンピュータＨＡ１，ＨＡｎは、ホストコンピュータ間を相互に接続する通信ネットワークＣＮ１２を介して、それぞれ接続されている。また、第１サイト１０Ａの各ホストコンピュータＨＡ１，ＨＡｎは、通信ネットワークＣＮ１２を介して、第２サイト１０Ｂの各ホストコンピュータＨＢ１，ＨＢｎとも相互に接続されている。このホストコンピュータ間の通信ネットワークＣＮ１２は、例えば、インターネット、LAN（Local Area Network）、WAN（Wide Area Netwrok）、MAN（Metropolitan Area Network）等のようなネットワークとして構成され、TCP/IP（Transmission Control Protocol/Internet Protocol）等に基づいてデータ通信を行う。

第２サイト１０Ｂも、上述した第１サイト１０Ａと同様に、複数のホストコンピュータＨＢ１，ＨＢｎと、記憶装置システム２０Ｂとを備えている。これらの構成は、第１サイト１０Ａで述べたと同様であるので、その説明を省略する。

ここで、記憶装置システム２０Ａと記憶装置システム２０Ｂとは、記憶装置間ネットワークとしてのリモートコピーラインＣＮ１３によって直接的に接続されている。リモートコピーラインＣＮ１３は、例えば、専用線または公衆回線により構成される。

なお、サイト内ネットワークＣＮ１１は、ファイバチャネルプロトコル（SCSI：Small Computer System Interface）を用いる構成に限らず、例えば、iSCSIのように、SCSIコマンドをIPパケットで包み込み、ブロックレベルのデータ転送をＩＰ網で実行する構成でもよい。

図３は、サイトのハードウェア構成に着目した概略ブロック図である。図３では、第１サイト１０Ａを中心に説明するが、第２サイト１０Ｂも同様のハードウェア構成を備えている。

ホストコンピュータＨＡ１，ＨＡｎは、基本的に同一構造を備えているので、ホストコンピュータＨＡ１を例に挙げてその構成を説明する。なお、以下の説明では、各ホストコンピュータを特に区別しない場合に、「ホストコンピュータＨ」または「ホストコンピュータＨ（番号）」と示す。

ホストコンピュータＨＡ１は、例えば、CPU３１０と、メモリ３２０と、ディスク３３０と、ディスクインターフェース（以下「Ｉ／Ｆ」）３４０と、上位ネットワークＩ／Ｆ３５０と、キーボードスイッチ３６０と、ディスプレイ３７０とを備え、これら各部はバス３８０により相互に接続されている。

CPU（Central Processing Unit）３１０は、メモリ３２０に記憶されているプログラムコードを読み込んで実行する。CPU３１０が所定のプログラムコードを実行することにより、クラスタ制御やリモートコピー制御等の各処理または機能がホストコンピュータＨＡ１上に実現される。

メモリ３２０は、例えば、ROM（Read Only Memory）やRAM（Random Access Memory）等から構成される。図中では、ROMとRAMの区別をしていないが、実際には、プログラムコード等を格納するROMと、一時的記憶領域や作業領域等として使用されるRAMとが設けられる。ディスク３３０は、例えば、ハードディスクドライブとして構成される。ディスク３３０には、例えば、プログラムやデータが記憶される。また、ディスク３３０の一部の記憶領域は、一時ファイルを格納するために使用される場合もある。

ディスクＩ／Ｆ３４０は、サイト内ネットワークＣＮ１１を介して、記憶装置システム２０Ａとの間のデータ授受を制御する回路である。ディスクＩ／Ｆ３４０は、例えば、SCSIやiSCSI等に基づいて、ブロックレベルのデータ転送を制御する。上位ネットワークＩ／Ｆ３５０は、ホストコンピュータ間ネットワークＣＮ１２を介して、他のホストコンピュータ（ＨＡｎ，ＨＢ１〜ＨＢｎ）との間のデータ授受を制御する回路である。上位ネットワークＩ／Ｆ３５０は、例えば、IP（Internet Protocol）に基づいて、データ転送を制御する。

キーボードスイッチ３６０は、情報入力手段の一例であり、システム管理者は、キーボードスイッチ３６０を介して、必要な指示等を入力することができる。ディスプレイ３７０は、情報出力手段の一例であり、例えば、CRT（Cathode Ray Tube）ディスプレイ、液晶ディスプレイ、プラズマディスプレイ、EL（Electronic Luminescent）ディスプレイ等から構成される。ディスプレイ３７０には、システム管理者からの明示の要求に応じて、あるいは自発的に、種々の情報が表示される。なお、これらに限らず、例えば、音声入力装置、音声出力装置、ポインティングデバイス、プリンタ等を用いてもよい。

記憶装置システム２０Ａのハードウェア構成を説明する。記憶装置システム２０Ａは、例えば、RAIDグループ２１０と、ディスク制御部２２０と、ホストＩ／Ｆ２３０と、装置間Ｉ／Ｆ２４０と、キャッシュメモリ２５０と、共有メモリ２６０と、スイッチング制御部２７０と、サービスプロセッサ（SVP）２８０と、を備えて構成される。

RAID（Redundant Array of Independent Disks）グループ２１０は、複数のディスクドライブ２１１を含んでおり、例えば、RAID１やRAID５等のRAIDに基づく冗長記憶を提供する。各ディスクドライブ２１１は、例えば、ハードディスクドライブ、半導体メモリ装置、光ディスクドライブ、光磁気ディスクドライブ等の記憶デバイスから構成することができる。各ディスクドライブ２１１が提供する物理的な記憶領域上には、論理的な記憶領域である論理ボリューム２１２を少なくとも一つ以上設定可能である。論理ボリューム２１２には、ホストコンピュータＨから利用される多数のデータが記憶される。また、別の論理ボリューム２１２には、制御情報等を格納し、システム領域として利用することもできる。なお、ディスクドライブ２１１は、その全てが記憶装置システム２０Ａの筐体内に位置する必要はない。例えば、同一サイト内に設置された他の記憶装置システム（不図示）が有する論理ボリュームを、記憶装置システム２０Ａの論理ボリュームとして使用することもできる。以下の説明では、論理ボリュームを「ボリューム」と省略して記載する場合がある。

ディスク制御部２２０は、各ディスクドライブ２１１との間のデータ授受を制御するものである。ディスク制御部２２０は、例えば、CPUやROM、RAM等を含んだマイクロコンピュータシステムとして構成される。ディスク制御部２２０は、記憶装置システム２０Ａ内に複数設けられる。ディスク制御部２２０は、例えば、SCSIやiSCSI等に基づいて、ディスクドライブ２１１との間でブロックレベルのデータ転送を行う。

ホストＩ／Ｆ２３０は、サイト内ネットワークＣＮ１１を介して、ホストコンピュータＨとの間のデータ転送を制御するものである。ホストＩ／Ｆ２３０は、ディスク制御部２２０と同様に、マイクロコンピュータシステムとして構成可能である。ホストＩ／Ｆ２３０は、ホストコンピュータＨの種類（サーバかメインフレームか等）に応じて、それぞれ用意することができる。なお、本実施例では、ホストコンピュータＨをサーバとして構成する場合を例に挙げて説明するが、メインフレームであってもよい。

装置間Ｉ／Ｆ２４０は、リモートコピーラインＣＮ１３を介して、他のサイト１０Ｂの記憶装置システム２０Ｂとの間でデータ通信を行うものである。装置間Ｉ／Ｆ２４０は、論理ボリューム２１２に書き込まれた更新データや差分データを、ホストコンピュータＨを介さずに、相手方の記憶装置システム２０Ｂに転送する。

ここで、リモートコピーについて、簡単に説明すると、記憶装置システム２０Ａが有する複数の論理ボリューム２１２と、記憶装置システム２０Ｂが有する複数の論理ボリューム２１２とのうち、同期対象となる論理ボリュームが予めそれぞれ選択される。これら選択された一対の論理ボリューム２１２は、一方がコピー元ボリュームとなり、他方がコピー先ボリュームとなる。ホストコンピュータＨからコピー元ボリュームに書き込まれたデータ（更新データ）は、装置間Ｉ／Ｆ２４０からリモートコピーラインＣＮ１３を介して、コピー先ボリュームに転送され、コピー先ボリュームに書き込まれる。

また、リモートコピーの停止期間中に、コピー元ボリュームに書き込まれたデータは、差分データとして管理される。差分データは、例えば、差分ビットマップテーブル等を用いて管理可能である。リモートコピーを再開する場合、まず先に、コピー元ボリュームからコピー先ボリュームに差分データが転送され、各ボリュームの再同期が行われる。

キャッシュメモリ２５０は、例えば、揮発または不揮発の半導体メモリから構成することができる。キャッシュメモリ２５０は、ホストコンピュータＨからのライトデータを記憶する。また、キャッシュメモリ２５０は、論理ボリューム２１２から読み出されたリードデータを記憶する。ここで、キャッシュメモリ２５０上に記憶されるデータは、例えば、以下のように分類可能である。一つは、キャッシュメモリ２５０にのみ記憶され、ディスクドライブ２１１に書き込まれていない状態のデータである。この状態のデータを、例えば「ダーティデータ」と呼ぶ。もう一つは、キャッシュメモリ２５０とディスクドライブ２１１のいずれにも記憶されている状態のデータである。この状態のデータを、例えば、「クリーンデータ」と呼ぶ。

共有メモリ２６０は、例えば、不揮発または揮発の半導体メモリから構成することができる。共有メモリ２６０は、例えば、ホストコンピュータＨから受信した各種コマンドや、記憶装置システム２０Ａの制御に使用する制御情報等を記憶する。これらのコマンドや制御情報等は、複数の共有メモリ２６０によって、冗長記憶される。なお、キャッシュメモリ２５０と共有メモリ２６０とは、それぞれ別々のメモリとして構成することもできるし、あるいは、一つのメモリの一部をキャッシュメモリ領域として使用し、残りを共有メモリ領域として使用することもできる。

スイッチング制御部２７０は、各ディスク制御部２２０と、各ホストＩ／Ｆ２３０と、装置間Ｉ／Ｆ２４０と、キャッシュメモリ２５０と、共有メモリ２６０とを、それぞれ相互に接続するものである。スイッチング制御部２７０は、例えば、超高速クロスバスイッチ等から構成することができる。

SVP２８０は、ホストＩ／Ｆ２３０を介して、記憶装置システム２０Ａ内の各部の状態を収集し監視する。SVP２８０は、収集した内部状態の情報を生データのままで、あるいは、統計処理したデータとして、外部の管理端末（不図示）に出力する。SVP２８０が収集可能な情報としては、例えば、装置構成、電源アラーム、温度アラーム、入出力速度（IOPS）等が挙げられる。システム管理者は、管理端末からSVP２８０を介して、RAID構成の設定変更や、各種パッケージ（ホストＩ／Ｆ、ディスク制御部等）の閉塞処理等を行うことができる。

次に、記憶装置システム２０Ａの作動について説明する。ホストＩ／Ｆ２３０は、サイト内ネットワークＣＮ１１を介して、ホストコンピュータＨからライトコマンド及びライトデータを受信する。受信されたライトコマンドは共有メモリ２６０に記憶され、受信されたライトデータはキャッシュメモリ２５０に記憶される。ディスク制御部２２０は、共有メモリ２６０を随時参照している。ディスク制御部２２０は、共有メモリ２６０に記憶されている未処理のライトコマンドを発見すると、このライトコマンドに従って、キャッシュメモリ２５０からライトデータを読み出し、アドレス変換等を行う。ディスク制御部２２０は、ライトコマンドによって指定された論理ボリューム２１２を構成する各ディスクドライブ２１１に、ライトデータを記憶させる。

ホストコンピュータＨからデータを書き込まれた論理ボリューム２１２が、コピー元ボリュームに設定されている場合、このライトデータは、装置間Ｉ／Ｆ２４０からリモートコピーラインＣＮ１３を介して、コピー先ボリュームを有する記憶装置システム２０Ｂに転送される。転送先の記憶装置システム２０Ｂは、装置間Ｉ／Ｆを介してライトデータを受信すると、このライトデータをキャッシュメモリに格納し、転送元の記憶装置システム２０Ａに対して、書込み完了を報告する。転送先の記憶装置システム２０Ｂは、書込み完了の報告後、適当なタイミングで、ライトデータをコピー先ボリュームに書込む。

転送元の記憶装置システム２０ＡのホストＩ／Ｆ２３０は、転送先の記憶装置システム２０Ｂから書込み完了が報告されたことを確認した後、ホストコンピュータＨに対して、書込み完了を報告する。以上のように、転送先の記憶装置システム２０Ｂからの書込み完了報告を待ってから、ホストコンピュータＨに書込み完了を報告する方法を、同期式リモートコピーと呼ぶ。

これに対し、転送元の記憶装置システム２０Ａが、ホストコンピュータＨからのライトデータをキャッシュメモリ２５０に記憶させた時点で、ホストコンピュータＨに書込み完了を報告する方法を非同期式リモートコピーと呼ぶ。同期式リモートコピーの場合は、転送先からの応答を待つ時間だけ処理時間が長くなる。しかし、転送が正常に完了したことを確認してからホストコンピュータＨに書込み完了を報告するため、コピー元ボリュームとコピー先ボリュームとが同期していることを保証できる。非同期式リモートコピーの場合は、相手方の記憶装置システム２０Ｂにライトデータを転送する前に、ホストコンピュータＨに書込み完了を報告するため、応答時間を短縮することができる。しかし、コピー元ボリュームの記憶内容が更新されたか否かを確認していないため、リモートコピーが正常に完了したことを確実に保証することはできない。

以上のように、同期式リモートコピーと非同期式リモートコピーとの２つの方式が知られている。これら各方式は、それぞれの構成に由来する技術的性質を有する。同期式リモートコピーの確実性と、非同期式リモートコピーの高速性とは、例えば、サイト間の物理的な距離や要求される応答性等を考慮して、必要に応じた使い分けが可能である。

例えば、稼働系サイト１０Ａと待機系サイト１０Ｂとの距離が、数十キロ以下程度のような比較的短い場合は、同期式リモートコピーを採用しても、伝播遅延や応答時間による影響を受けにくい。本実施例では、同期式リモートコピーを例に挙げて説明する。しかし、後述の実施例からも明らかなように、本発明は、非同期式リモートコピーを採用することもできる。

ホストコンピュータＨからのリード要求を処理する場合を説明する。ホストＩ／Ｆ２３０は、ホストコンピュータＨからリードコマンドを受信すると、このリードコマンドを共有メモリ２６０に記憶させる。ディスク制御部２２０は、共有メモリ２６０内で未処理のリードコマンドを発見すると、このリードコマンドによって指定された論理ボリューム２１２を構成する各ディスクドライブ２１１からデータを読み出す。ディスク制御部２２０は、読み出したデータをキャッシュメモリ２５０に記憶させる。また、ディスク制御部２２０は、要求されたデータの読出しが完了した旨を、共有メモリ２６０を介して、ホストＩ／Ｆ２３０に通知する。ホストＩ／Ｆ２３０は、キャッシュメモリ２５０からデータを読み込み、ホストコンピュータＨに送信する。

図４は、ホストコンピュータＨのソフトウェア構成の要部を模式的に示すブロック図である。ホストコンピュータＨは、例えば、ＯＳ（Operating System）や各種デバイスドライバ等を備えている。これに加えて、ホストコンピュータＨは、図４に示すように、データ最新性保障モジュール（以下、「保障モジュール」とも呼ぶ）３０と、クラスタソフトウェア４０と、リモートコピー制御モジュール５０とを備えている。

なお、図４中では、ホストコンピュータＨ１にのみ各ソフトウェア３０，４０，５０を設けているかのように示しているが、実際には、クラスタシステムを構成する全てのホストコンピュータＨ１，Ｈ２，Ｈ３に、それぞれ各ソフトウェア３０，４０，５０が実装されている。また、各ソフトウェア３０，４０，５０がそれぞれ実現すべき各機能は、プログラムコードやデータから構成する必要はなく、例えば、その一部または全部をハードウェア回路から構成してもよい。

保障モジュール３０は、どのサイトに設けられているボリュームが最新のデータを記憶しているかを管理するためのソフトウェアであり、他の保障モジュール３０との間で通信を行うための通信機能を備えている。

保障モジュール３０は、例えば、最新性管理情報３１と、更新管理情報３２とをそれぞれ管理することができる。最新性管理情報３１は、図６と共に後述するように、各コピーペア毎に、どのサイトのボリュームが最新のデータを記憶しているかを、それぞれ記憶している。なお、最新性管理情報を「データ最新性管理情報」とも呼ぶ。最新性管理情報３１は、「基準指示情報」に対応する。

更新管理情報３２は、最新性管理情報３１が他の全てのホストコンピュータＨに対して、通知されたか否かを管理するものである。つまり、更新管理情報３２は、最新性管理情報３１の各ホストコンピュータＨへの通知状態を管理するための情報である。詳細はさらに後述するが、保障モジュール３０は、リモートコピーに障害が発生した場合に、更新管理情報３２を更新し、他の各ホストコンピュータＨにそれぞれ通知する。

即ち、保障モジュール３０は、リモートコピーの障害が発生した場合に、基準となるべきボリューム（最新データを記憶するボリューム）を判定し、他のホストコンピュータＨにそれぞれ通知する。この通知は、例えば、リモートコピーの障害発生を検出した保障モジュール３０から、他の全ての保障モジュール３０に対し、所定の情報をそれぞれ送信させることにより、実現可能である。また、例えば、所定回数だけ繰り返して通知することもできる。

クラスタソフトウェア４０は、クラスタシステムを制御するものである。各サイト１０Ａ，１０Ｂの各ホストコンピュータＨ（ノード）は、各クラスタソフトウェア４０の連携により、全体として一つのクラスタを構成している。各クラスタソフトウェア４０は、例えば、ハートビート通信を行うことにより、監視対象のホストコンピュータＨが機能を停止したか否かを監視することができる。

また、クラスタソフトウェア４０は、クラスタを制御するための各種のモジュールを備えている。本発明と関連するモジュールとしては、例えば、リソース管理モジュール４１と、コピー管理リソース４２とを挙げることができる。

リソース管理モジュール４１は、クラスタ制御の一部として、クラスタに使用されるリソースを管理するものである。リソースとしては、例えば、各論理ボリュームやホストコンピュータＨのネットワーク設定等を挙げることができる。

コピー管理リソース４２は、設定されたリモートコピーのペアをクラスタのリソースとして登録し、リモートコピーを管理するものである。コピー管理リソース４２は、コピーペアの操作に関する指示を受け取って、ボリュームの設定を変更する。また、コピー管理リソース４２は、定期的に、コピーペアを構成するボリュームの状態を確認することもできる。さらに、コピー管理リソース４２は、リモートコピーの障害が発生した場合に、保障モジュール３０に対して、そのボリュームが使用可能であるか否かを問い合わせることもできる。

リモートコピー制御モジュール５０は、リモートコピーの作動を制御する。リモートコピー制御モジュール５０は、コピー管理リソース４２からの指示に基づいて、例えば、コピーペアの形成、コピーペアの分割、コピーペアの状態確認、コピーペアの反転といった操作を行う。コピーペアの各状態については、さらに後述する。なお、以下の説明では、コピーペアを「ペア」と略記する場合がある。

フェイルオーバの実行方法について簡単に説明する。一つの方法として、いずれかのホストコンピュータＨが機能を停止すると、そのホストコンピュータＨとの間のハートビート通信が途絶し、そのホストコンピュータＨの機能停止が検出される。フェイルオーバ先として選択されたホストコンピュータＨのクラスタソフトウェア４０は、フェイルオーバ元のホストコンピュータＨが使用していたボリュームやネットワーク設定情報等の資源を引継ぐ。フェイルオーバ先のホストコンピュータＨは、フェイルオーバ元で提供されていた情報処理サービス（業務サービス）を再開する。ホストコンピュータＨの情報処理サービスを利用するクライアントマシンは、稼働系ホストコンピュータＨから待機系ホストコンピュータＨへの交替を特に意識しない。

このような処理方法とは別に、例えば、計画的な停止を行う場合や、稼働系ホストコンピュータＨが部分的に機能を停止する場合、稼働系ホストコンピュータＨが一時的に過負荷状態になったような場合には、別の方法を実行することができる。即ち、フェイルオーバ元の稼働系ホストコンピュータＨから、フェイルオーバ先として選択されたホストコンピュータＨに対し、フェイルオーバ処理の開始を明示的に要求する。このフェイルオーバ処理の開始要求を受信したホストコンピュータＨは、ネットワーク設定情報やボリューム等の資源を引き継いで、情報処理サービスの提供を開始する。

図５は、ボリュームが取り得る各種のペア状態とこれら各ペア状態間での遷移を模式的に示す状態遷移図である。図５に示すように、リモートコピーの対象となるボリュームのペア状態としては、例えば、「ペア分割状態」、「コピー元状態」及び「コピー先状態」の３種類を挙げることができる。

「ペア分割状態」とは、リモートコピーの対象となっていない状態を示す。「ペア分割状態」のボリュームに対して、このボリュームに繋がるホストコンピュータＨは、リードアクセス及びライトアクセスの両方を行うことができる。ここで、例えば、「ペア分割状態」になった場合に、ペア分割以後に生じた差分データをビットマップ等で別途管理しておくことができる。これにより、コピーペアの再同期時には、差分データのみをコピー先ボリュームに転送すればよく、再同期の所要時間を短縮することができる。または、コピーペアをいったん分割した後で再同期させる場合、コピー元ボリュームの記憶するデータを丸ごと全てコピー先ボリュームに転送して、ペア状態を再構築する方法等もある。

「コピー元状態」とは、コピー元ボリュームとして設定された状態である。「コピー元状態」のボリュームに対して、このボリュームに繋がるホストコンピュータＨは、リードアクセス及びライトアクセスの両方が可能である。「コピー元状態」に設定されたボリュームの記憶内容が更新されると、これに同期して、「コピー先状態」に設定されたボリュームの記憶内容も更新される。なお、リモートコピーに何らかの障害が発生している場合は、コピー元ボリュームの記憶内容の変更に応じて、コピー先ボリュームの記憶内容を変更させることができなくなる。即ち、リモートコピーの障害時には、コピー元ボリュームへのライトアクセスを許可しても、ライトデータをコピー先ボリュームに書き込ませることができない。従って、リモートコピーに障害が発生した場合は、「コピー元状態」のボリュームへのライトアクセスを禁止する。この場合、コピー元ボリュームに対するホストコンピュータＨのＩ／Ｏ要求（ライトアクセス）は、失敗となる。

「コピー先状態」とは、「コピー元状態」と対になる状態であり、コピー先ボリュームとして設定された状態を示す。「コピー先状態」に設定されたボリュームには、「コピー元状態」に設定されたボリュームへの更新が、同期して反映される。「コピー先状態」に設定されたボリュームに対しては、このボリュームに繋がれるホストコンピュータＨからライトアクセスすることはできない。なお、「コピー先状態」に設定されたボリュームへのリードアクセスは、許可してもよいし、禁止してもよい。

次に、各ペア状態間の遷移について説明する。仮に、コピーペアを構成する各ボリュームの初期状態を「ペア分割状態」であるとする。「ペア分割状態」の２つのボリュームのうち、一方のボリュームに関して「ペア形成指示」を発行すると（Ｐ１）、このボリュームは、「ペア分割状態」から「コピー元状態」に変化する。このボリュームは、コピー元ボリュームとなる。そして、このコピー元ボリュームとペアを構成する他方のボリュームは、「ペア分割状態」から「コピー先状態」に変化する（Ｐ３）。

「コピー元状態」に設定されているボリュームに関して、そのボリュームに繋がるホストコンピュータＨから「ペア分割指示」を発行した場合（Ｐ２）、「コピー元状態」から「ペア分割状態」に変化する。これとほぼ同時に、「コピー先状態」に設定されているボリュームも、「ペア分割状態」に変化する。「コピー先状態」に設定されているボリュームに関して「ペア分割指示」を発行した場合も（Ｐ４）、上記同様の変化を生じる。即ち、「コピー先状態」のボリュームも「コピー元状態」のボリュームも、ともに「ペア分割状態」に変化する。

リモートコピーの方向は、ボリュームに設定された状態により定まる。「コピー元状態」に設定されているボリュームから、「コピー先状態」に設定されているボリュームに向けて、ライトデータが転送される。このリモートコピーの方向は、「ペア反転指示」を発行することにより、反転させることができる。

「コピー元状態」に設定されているボリュームに関して、そのボリュームに繋がるホストコンピュータＨから「ペア反転指示」を発行すると（Ｐ５）、そのボリュームは「コピー元状態」から「コピー先状態」に変化する。同時に、相手方のボリュームは、「コピー先状態」から「コピー元状態」に変化する。同様に、「コピー先状態」に設定されているボリュームに関して、そのボリュームに繋がるホストコンピュータＨから「ペア反転指示」を発行すると（Ｐ６）、「コピー先状態」のボリュームは「コピー元状態」に変化し、「コピー元状態」のボリュームは「コピー先状態」に変化する。

図６は、保障モジュール３０によって管理される最新性管理情報３１及び更新管理情報３２の構成をそれぞれ示す説明図である。

最新性管理情報３１は、図６中の上側に示すように、例えば、コピーペアをそれぞれ識別するためのコピーペア番号と、ペア基準状態を登録した時刻と、ペア基準状態とをそれぞれ対応付けることにより、構成することができる。なお、登録時刻には、年月日を含めてもよい。

ペア基準状態とは、上述したペア状態とは異なり、基準となるべきボリュームを指定する情報である。基準となるべきボリュームとは、ペアを構成する各ボリュームのうち最新のデータを記憶している方のボリュームを意味する。ペア基準状態としては、例えば、「ノーマル状態」、「第１サイト（稼働系サイト）」及び「第２サイト（待機系サイト）」を挙げることができる。

「ノーマル状態」とは、通常の運用に従う状態であり、従って、コピー元ボリュームが基準となる。「第１サイト状態」とは、第１サイト１０Ａに設けられているボリュームが基準となることを示す状態である。「第２サイト状態」とは、第２サイト１０Ｂに設けられているボリュームが基準となることを示す状態である。このように、最新性管理情報３１は、各リモートコピーのペア毎に、それぞれのペアで基準となるべきボリュームを指示している。最新性管理情報３１は、リモートコピーの障害が発生した場合に、基準となるべきボリュームを、そのボリュームの設置されているサイト名で指定する。

なお、図６中では、ペアボリューム＃１が「ノーマル状態」、ペアボリューム＃２が「第１サイト状態」、ペアボリューム＃３が「第２サイト状態」としてそれぞれ表示されているが、これは説明のための表示である。

更新管理情報３２は、図６中の下側に示すように、例えば、コピーペア番号と、そのペアボリュームを利用するホストコンピュータ名と、最新性管理情報３１を通知した結果を示す更新結果状態とを、それぞれ対応付けることにより、構成可能である。

更新結果状態としては、例えば、「未実施状態」、「成功状態」及び「失敗状態」を挙げることができる。ここで、「未実施状態」とは、最新性管理情報３１をホストコンピュータＨに通知する前の状態を示す。「成功状態」とは、ホストコンピュータＨへの最新性管理情報３１の通知が成功し、そのホストコンピュータＨで最新性管理情報３１が更新された状態を示す。「失敗状態」とは、ホストコンピュータＨへの最新性管理情報３１の通知が失敗に終わった状態を示す。なお、更新結果中の「−」は、最新性管理情報３１の発行元であるため、通知が不要な状態を示す。

図７は、フェイルオーバ処理の概要を示すフローチャートである。フェイルオーバ処理は、同一サイト内で実行することもできるし、他のサイトで実行することもできる。

クラスタを構成する各ホストコンピュータＨは、それぞれのクラスタソフトウェア４０によって、フェイルオーバを実行すべき障害が検出されたか否か、または、フェイルオーバの開始要求を受信したか否かを、監視している（Ｓ１）。

他のホストコンピュータＨで障害が発生した場合、または、他のホストコンピュータＨからフェイルオーバ開始要求を受信した場合には（S1：YES）、フェイルオーバ処理の実行に必要な共有ボリューム（論理ボリューム）を使用可能か否かを判定する（Ｓ２）。この共有ボリュームは、リモートコピーペアを構成している。後述するように、その共有ボリュームのペア操作が可能な場合は、そのボリュームを利用してフェイルオーバ処理を実行することができる。また、その共有ボリュームのペア操作（ペア状態の変更操作）ができない場合でも、データ最新性保障モジュール処理により、使用可能と判断された場合は、そのボリュームを用いてフェイルオーバ処理を実行することができる。

フェイルオーバに必要な共有ボリュームを利用できない場合（S2：NO）、クラスタソフトウェア４０は、フェイルオーバ元のホストコンピュータまたは他のホストコンピュータの全てに対し、フェイルオーバ処理の実行が不能である旨を通知する（Ｓ３）。必ずしもそうである必要はないが、この処理不能通知を受信した他のホストコンピュータＨは、自身でフェイルオーバ処理を実行可能か否かを判定することができる。

フェイルオーバに必要な共有ボリュームを利用可能な場合（S2：YES）、フェイルオーバ先となるホストコンピュータＨは、フェイルオーバ元のホストコンピュータＨからＩＰアドレス等のネットワーク設定情報を引継ぎ（Ｓ４）、フェイルオーバ元ホストコンピュータに成り代わる。また、フェイルオーバ先ホストコンピュータＨは、Reserveコマンド等を発行することにより、共有ボリュームの排他制御を開始する（Ｓ５）。そのほか、業務サービスの再開に際して必要な各処理を終えた後、フェイルオーバ先ホストコンピュータＨは、クライアントマシンに対するサービス提供を再開する（Ｓ６）。

例えば、第１サイト１０ＡのホストコンピュータＨＡ１が業務サービスを提供していると仮定し、このホストコンピュータＨＡ１が機能を停止したとする。リモートコピーに障害が発生していない場合、ホストコンピュータＨＡ１が使用しているコピー元ボリュームの記憶内容は、コピー先ボリュームに同期して反映されており、両者の記憶内容は一致している。従って、業務サービスの提供に使用されているコピー元ボリュームまたはコピー先ボリュームのいずれか一方を利用可能なホストコンピュータであれば、フェイルオーバ処理を実行することができる。

これに対し、もしも、フェイルオーバ処理の開始前に、リモートコピーに障害が発生している場合は、業務サービスの提供に使用されているコピー元ボリュームとコピー先ボリュームとの記憶内容は、一致していない。両者の記憶内容は相違し、最新のデータは、コピー元ボリュームの側に差分データとして蓄積されている。この場合、もしも、最新のデータが反映されていないボリュームを用いて、フェイルオーバ処理を実行すると、データの整合性が失われ、誤った運用が行われる。従って、本実施例では、後述のように、コピーペアを構成する２つのボリュームのうち、最新のデータを記憶しているボリュームを基準として運用を再開させるようにしている。

図８は、コピー管理リソース４２によって実行される制御処理を示すフローチャートである。図８に示す処理は、コピー管理リソース４２がリソース管理モジュール４１から要求を受信すると開始する。

コピー管理リソース４２は、リソース管理モジュール４１からの要求が「オンライン要求」であるか「状態確認要求」であるかを判別する（Ｓ１１）。ここで、オンライン要求とは、ボリュームの使用開始を要求するためのものである。「状態確認要求」とは、ボリュームの状態を確認するためのものである。

リソース管理モジュール４１がオンライン要求を発行した場合、このリソース管理モジュール４１を有するホストコンピュータＨがコピー元となるように、リモートコピー制御モジュール５０に指示を出し、このホストコンピュータＨに繋がるボリュームの状態を「コピー元状態」に変更させる（Ｓ１２）。このコピー元ステータスへの変更処理（Ｓ１２）については、図９と共に後述する。

次に、「コピー元状態」への変更が成功したか否かを判定する（Ｓ１３）。「コピー元状態」への変更が成功した場合は、リソース管理モジュール４１への戻り値に「成功」をセットする（Ｓ１４）。何の異常も生じていない通常の場合は、Ｓ１３の判定結果は「成功」となる。

これに対し、もしも、例えば、リモートコピーラインＣＮ１３にリンク切れ等の障害が発生していたり、あるいは、記憶装置システム内のリモートコピー機能に異常が生じているような場合は、対象とするボリュームの状態を「コピー元状態」に変更させることができない。

「コピー元状態」への変更が失敗した場合は、保障モジュール３０に対して、ペア操作を試みたボリュームを使用可能か否か、即ち、そのボリュームが最新のデータを記憶しているボリュームであるか否かを問い合わせる（Ｓ１５）。このデータ最新性保障モジュール処理の詳細は、図１０と共に後述する。

保障モジュール３０は、コピー管理リソース４２からの問合せに対して、「成功」または「失敗」のいずれかを回答する。「成功」とは、「コピー元状態」への変更操作に失敗したボリュームが最新データを記憶しており、そのボリュームを用いてフェイルオーバ処理等を実行可能であることを意味する。「失敗」とは、そのボリュームが最新のデータを記憶しておらず、そのボリュームを用いてフェイルオーバ処理等の制御処理を実行すると、誤った運用が行われる可能性があることを意味する。

保障モジュール３０からの応答が「成功」の場合は、「ペア分割指示」を発行させ（Ｓ１７）、リソース管理モジュール４１に「成功」した旨を応答する（Ｓ１４）。操作対象のコピーペアを解除させることにより、図５と共に説明したように、そのボリュームへのリードアクセス及びライトアクセスが可能となる。

保障モジュール３０からの応答が「失敗」の場合は、そのボリュームを用いてフェイルオーバ処理等を行うことができない場合なので、リソース管理モジュール４１に「失敗」した旨を報告する（Ｓ１８）。

以上のＳ１２〜Ｓ１８は、リソース管理モジュール４１からのオンライン要求を処理するためのステップである。次に、リソース管理モジュール４１がステータスの確認を要求した場合の処理（Ｓ１９〜Ｓ２５）を説明する。

リソース管理モジュール４１は、定期的にボリュームの状態を確認する。コピー管理リソース４２は、リソース管理モジュール４１からステータス確認要求を受け取ると、リモートコピー制御モジュール５０を介して、コピーペアの状態を確認する（Ｓ１９）。

ペア状態の確認結果（Ｓ２０）は、２種類に分けることができる。一つは、そのボリュームのペア状態が「コピー元状態（正常）」である場合である。他の一つは、そのボリュームのペア状態が「コピー元状態（異常）」または「ペア分割状態」のいずれかの場合である。「コピー元状態（正常）」とは、そのボリュームがコピー元に設定されており、かつ、何の異常もなく正常に使用可能であることを示す。「コピー元状態（異常）」とは、そのボリュームがコピー元に設定されているが、何らかの異常（リモートコピー障害）が生じている場合を示す。

ペア状態が「コピー元状態（正常）」の場合は、リソース管理モジュール４１に「成功」した旨を報告する（Ｓ２１）。ペア状態が「コピー元（異常）」または「ペア分割状態」のいずれかである場合は、保障モジュール３０に対し、そのボリュームを使用可能か否かを問い合わせる（Ｓ２２）。

Ｓ１５の説明でも述べたように、保障モジュール３０からの回答が「成功」の場合は、そのボリュームを使用可能な場合なので、「ペア分割指示」を発行し（Ｓ２４）、リソース管理モジュール４１に「成功」を報告する（Ｓ２１）。なお、「ペア分割指示」は、自動的に発行してもよいし、システム管理者が手動で発行させてもよい。一方、保障モジュール３０からの回答が「失敗」の場合は、リソース管理モジュール４１に「失敗」を報告する（Ｓ２５）。

以上のように、何の障害も発生していない場合は、リソース管理モジュール４１からのオンライン要求及びステータス確認要求のいずれに対しても、コピー管理リソース４２は「成功」を報告する。これに対し、例えば、リンク切れや記憶装置システムの異常等により、リモートコピーの制御を正常に実行できない場合は、コピー管理リソース４２からリソース管理モジュール４１に「失敗」が報告される。

図９は、図８中にＳ１２で示した「コピー元ステータス変更処理」の詳細を示すフローチャートである。まず最初に、コピー管理リソース４２は、ペア状態の変更が要求されたボリュームの現在のペア状態を確認する（Ｓ３１）。

そして、現在のペア状態の確認結果に応じて、以降の処理を行う（Ｓ３２）。現在のペア状態が「ペア分割状態」の場合は、戻り値に「失敗」をセットする（Ｓ３３）。現在のペア状態が「コピー先状態」の場合は、「コピー元状態」に設定変更させるべく、「ペア反転指示」を実行させる（Ｓ３４）。ペアの反転指示が成功したか否かを判定し（Ｓ３５）、ペア反転に成功した場合は、戻り値に「成功」をセットする（Ｓ３６）。ペア反転に失敗した場合は、戻り値に「失敗」をセットする（Ｓ３７）。

現在のペア状態が「コピー元状態（正常）」の場合は、戻り値に「成功」をセットする（Ｓ３８）。現在のペア状態が「コピー元状態（異常）」の場合は、戻り値に「失敗」をセットする（Ｓ３９）。

図１０は、図８中にＳ１５，Ｓ２２で示した「データ最新性保障モジュール処理」の詳細を示すフローチャートである。保障モジュール３０は、以下に述べるように、コピー管理リソース４２からの要求により、所望のボリュームを使用可能か否かを判定する。ここで、図８と共に述べたように、所望のボリュームに対するペア状態操作が失敗した場合に、保障モジュール３０は、コピー管理リソース４２から問合せを受ける。ペア状態の操作に失敗する場合とは、例えば、リモートコピーラインＣＮ１３の故障や、記憶装置システム内の障害等により、コピーペアを構成するボリュームの状態を変更できない場合、つまり、少なくともリモートコピー機能の実行に障害が生じている場合である。

このように、図１０に示す処理は、ストレージシステム内でリモートコピー障害が発生しているような場合に、実行される。まず、保障モジュール３０は、コピー管理リソース４２からボリュームの使用可否について問合せを受けると、最新性管理情報３１を確認する（Ｓ４１）。

保障モジュール３０は、問合せされたボリュームについてのペア基準状態を確認する（Ｓ４２）。上述の通り、「ペア基準状態」とは、リモートコピー障害の発生時に基準となるべきボリュームを特定するための情報であり、「ノーマル状態」、「第１サイト状態」、「第２サイト状態」の３種類が用意されている。「ノーマル状態」が設定されている場合は正常な状態を、「第１サイト状態」及び「第２サイト状態」のようにサイト名が登録されている場合は異常発生状態を、それぞれ示す。

最新性管理情報３１に現在設定されているペア基準状態が「ノーマル状態」の場合は、ペア基準状態として自サイト名を登録し、また、現在時刻を登録する（Ｓ４３）。もしも、図１０の処理が第１サイト１０Ａに属するホストコンピュータＨＡ１〜ＨＡｎのいずれかで実行された場合、これら各ホストコンピュータＨＡにそれぞれ繋がるボリュームのペア基準状態として、「第１サイト状態」がセットされる。逆に、第２サイト１０Ｂに属するホストコンピュータＨＢ１〜ＨＢｎのいずれかで、上記処理が実行された場合、これら各ホストコンピュータＨＢにそれぞれ接続されたボリュームのペア基準状態として、「第２サイト状態」がセットされる。つまり、ペア基準状態が「ノーマル状態」にセットされていた場合は、そのサイト内のボリュームに差分データが蓄積されているか、または蓄積される可能性がある。そこで、そのサイト内のボリュームが最新データを保有する基準ボリュームであることを、最新性管理情報３１に登録する。

次に、保障モジュール３０は、他のホストコンピュータＨにそれぞれ設けられている保障モジュール３０に対して、最新性管理情報３１に変更が生じた旨をそれぞれ通知し、保持させる（Ｓ４４）。本実施例では、この最新性管理情報３１の通知・登録処理を「他サイト登録処理」と呼ぶ。なお、「他サイト」の保障モジュール３０に限らず、自サイト内の他の保障モジュール３０にも通知され、登録が要求される。他サイト登録処理の詳細は、図１１と共に後述する。

次に、各サイトの各保障モジュール３０に対して、最新性管理情報３１の更新がそれぞれ通知され、登録されたかを判定する（Ｓ４５）。最新性管理情報３１の通知及び登録要求の処理が全て成功した場合は、戻り値に「成功」をセットする（Ｓ４６）。いずれか一つの保障モジュール３０において、最新性管理情報３１の通知等が失敗した場合は、戻り値に「失敗」をセットする（Ｓ４７）。

一方、前記Ｓ４２で現在のペア基準状態として、いずれかのサイト名が登録されていた場合（逆に言えば、「ノーマル状態」以外の状態であった場合）は、登録済のサイト名が自サイト名であるか否かを判定する（Ｓ４８）。

最新性管理情報３１に自サイト名が既に登録されている場合は、戻り値に「成功」をセットする（Ｓ４９）。最新性管理情報３１にセットされているサイト名が他のサイトの名称である場合は、戻り値に「失敗」をセットする（Ｓ５０）。使用を所望するボリュームに関するペア基準状態に他のサイト名が登録されている場合、その所望のボリュームは最新データを記憶しておらず、リモートコピー障害発生後の基準ボリュームとして使用不能な場合である。従って、この場合、戻り値に「失敗」がセットされる。

図１１は、図１０中にＳ４４として示した「他サイト登録処理」の詳細を示すフローチャートである。まず、保障モジュール３０は、最新性管理情報３１を参照し、通知すべきホストコンピュータＨを特定する（Ｓ６１）。即ち、ペア基準状態が変更されたボリュームを共有するホストコンピュータＨを全て検出する。

次に、保障モジュール３０は、そのボリュームを共有する各ホストコンピュータＨの保障モジュール３０に対して、更新されたペア基準状態をそれぞれ通知し、サイト名登録処理の開始をそれぞれ要求する（Ｓ６２）。サイト名登録処理の詳細は、図１２と共に後述するが、簡単には、他の保障モジュール３０に対してペア基準状態の更新を要求する処理である。

そして、保障モジュール３０は、ペア基準状態を通知した他の各ホストコンピュータＨ（保障モジュール３０）からの応答を待つ（Ｓ６３）。保障モジュール３０は、他の各保障モジュール３０からの応答結果を、更新管理情報３２の「更新結果」の欄にそれぞれ登録する（Ｓ６４）。

保障モジュール３０は、更新管理情報３２を参照し、他の各保障モジュール３０からの応答（戻り値）が全て「成功」であるか否かを判定する（Ｓ６５）。更新管理情報３２の更新結果が全て「成功」である場合、ペア基準状態が正常に通知されて更新された場合だから、戻り値に「成功」をセットする（Ｓ６６）。これに対し、更新結果の欄に一つでも「失敗」が登録された場合は、基準となるべきボリュームがどのボリュームであるかについて、正確に認識していないホストコンピュータＨが存在する場合である。この場合は、正確に認識していないホストコンピュータＨにより、誤ったペア操作が行われる可能性がある。そこで、戻り値に「失敗」をセットする（Ｓ６７）。

図１２は、図１１中のＳ６２に関連し、ペア基準状態としてのサイト名の登録要求を処理するフローチャートである。

ペア基準状態を更新（生成）した保障モジュール３０からサイト名登録処理要求を受信すると、図１２に示す処理が実行される。ここで、通知元の保障モジュール３０が発行するサイト名登録処理要求には、ペア基準状態が変更されたペアボリュームを特定するためのコピーペア番号と、ペア基準状態の更新時刻と、更新されたペア基準状態の内容とが、それぞれ含まれている。

まず、通知を受けた保障モジュール３０は、自己の保有する最新性管理情報３１を確認する（Ｓ７１）。通知を受けた保障モジュール３０は、通知されたボリュームに関するペア基準状態を確認する（Ｓ７２）。通知されたボリュームのペア基準状態に「ノーマル状態」がセットされている場合、通知先の保障モジュール３０は、現在のペア基準状態を通知されたペア基準状態に書き換える（Ｓ７３）。

即ち、サイト名の登録を要求してきた保障モジュール３０の存在するサイト名（要求元サイト名）と、要求元サイト名でペア基準状態が更新された時刻とを、自己の最新性管理情報に登録する。そして、通知先の保障モジュール３０は、通知元の保障モジュール３０に対し、「成功」した旨を応答する（Ｓ７４）。

一方、Ｓ７２において、通知先の最新性管理情報にサイト名が既に登録されていた場合、この登録済のサイト名と通知元（要求元）のサイト名とが一致するか否かを判定する（Ｓ７５）。登録済のサイト名と通知元のサイト名とが一致する場合（S75：YES）、戻り値に「成功」をセットする（Ｓ７４）。登録済のサイト名と通知元のサイト名とが不一致の場合（S75：NO）、登録済サイト名を登録した時刻（そのペア基準状態が更新された時刻）と、通知されたサイト名の更新時刻とをそれぞれ確認し（Ｓ７６）、両者を比較する（Ｓ７７）。つまり、既に登録済のサイト名を旧ペア基準状態、新たに通知されたサイト名を新ペア基準状態と呼ぶと、あるホストコンピュータＨの保障モジュール３０において旧ペア基準状態が生成された時刻（図中の「登録時刻」）と、別のあるホストコンピュータＨの保障モジュール３０において新ペア基準状態が生成された時刻（図中の「要求時刻」）とを比較する。

新ペア基準状態の生成時刻の方が古い場合は、新ペア基準状態としてのサイト名及び生成時刻を最新性管理情報にそれぞれ登録し（Ｓ７８）、戻り値に「成功」をセットする（Ｓ７４）。これに対し、新ペア基準状態の生成時刻の方が旧ペア基準状態の生成時刻よりも新しい場合は、最新性管理情報を更新することなく、戻り値に「失敗」をセットする（Ｓ７９）。つまり、より以前に生成されたペア基準状態が優先する。ペア基準状態を先に生成した方のサイトでは、より早くから最新のデータが蓄積されている可能性が高いためである。

このように、本実施例では、ペア基準状態の通知が競合した場合に、より古い方のペア基準状態を優先させることにより、より早くから蓄積されている方の差分データが尊重されるようにしている。

図１３は、リカバリ処理を示すフローチャートである。このリカバリ処理は、例えば、リモートコピーの障害が復旧した後で、コピーペアを再度形成するような場合に、システム管理者が手動で実行させることができる。

まず、保障モジュール３０は、最新性管理情報３１に登録されている各ペア基準状態をそれぞれ「ノーマル状態」に設定し、ペア基準状態を初期化する（Ｓ８１）。また、保障モジュール３０は、最新性管理情報３１に登録されている各更新時刻をそれぞれ消去し、更新時刻の初期化を行う（Ｓ８２）。

次に、保障モジュール３０は、各コピーペア毎に（ペアボリューム毎に）、そのボリュームを共用するホストコンピュータ名を確認する（Ｓ８３）。保障モジュール３０は、確認された各ホストコンピュータＨに対して、それぞれの保障モジュール３０が有する最新性管理情報の初期化をそれぞれ要求する（Ｓ８４）。

この初期化要求を受けた他の保障モジュール３０は、ペア基準状態を「ノーマル状態」に戻し（Ｓ８５）、また、更新時刻を消去し（Ｓ８６）、最新性管理情報の初期化が完了した旨を初期化要求元の保障モジュール３０に通知する（Ｓ８７）。

最新性管理情報の初期化を要求した保障モジュール３０は、他の保障モジュール３０からの初期化完了通知が到着するのを待ち（Ｓ８８）、初期化完了通知が到着するたびに更新管理情報３２の更新結果の欄に「未実施」をセットする（Ｓ８９）。

ここで、最新性管理情報３１の全体を一律に初期化させる必要はなく、リモートコピー障害の回復に関係する部分のみを初期化させればよい。また、初期化要求元の保障モジュール３０は、初期化完了通知を受領するたびに更新管理情報３２を更新させる構成でもよいし、受領した初期化完了通知をメモリ上に保存しておき、全ての初期化完了通知を受領した後で、一括して更新管理情報３２を更新させる構成でもよい。

図１４は、障害復旧処理のフローチャートである。この障害復旧処理は、図１３と共に述べたリカバリ処理を自動的に実行させるための処理である。この障害復旧処理は、保障モジュール３０が実行してもよいし、保障モジュール３０とは別のモジュールで実行させてもよい。ここでは、保障モジュール３０の一機能とした場合を説明する。

ここで、図１４に関連するクラスタソフトウェア４０は、リモートコピー障害等の障害が発生した後に、障害が回復したか否かを調査させるべく、コピー管理リソース４２に対して調査要求を定期的に出力する機能を備えているものとする。図１４に示す以外の場合、クラスタソフトウェア４０は、定期的な障害回復調査機能を保有している必要性は必ずしもない。

コピー管理リソース４２は、クラスタソフトウェア４０からの調査指示を受けて、障害が回復したか否かを調査する。障害が回復している場合、コピー管理リソース４２は、保障モジュール３０に障害が回復した旨を通知する。この通知を受けて、図１４に示す障害回復処理が実行される。

保障モジュール３０は、最新性管理情報３１に登録されているペア基準状態を一つ分（１行）だけ確認し（Ｓ９１）、ペア基準状態にサイト名が登録されているか否かを判定する（Ｓ９２）。ペア基準状態に「ノーマル状態」が登録されている場合（S92：NO）、処理を終了する。

ペア基準状態に「第１サイト状態」または「第２サイト状態」のいずれかが登録されている場合（S92：YES）、保障モジュール３０は、最新のデータ内容を有するボリュームのペア状態が「コピー元状態」となるように、リモートコピー制御モジュール５０に対して、コピーペアの形成を指示する（Ｓ９３）。

コピーペアの形成に失敗した場合は（S94：失敗）、リモートコピー障害が完全に回復していないか、あるいは、新たなリモートコピー障害が発生している場合なので、コピーペアの操作を諦め、Ｓ９１に戻る。そして、次のペア基準状態を確認する。

コピーペアの操作に成功した場合は（S94：成功）、図１３で説明したリカバリ処理を開始させる（Ｓ９５）。これにより、リモートコピー機能が障害から回復した後に、自動的に、最新性管理情報３１等の初期化を行うことができる。

図１５，図１６は、障害が発生した場合の全体動作の概要を示す説明図である。まず、ある時点で、記憶装置システム２０Ａに第１の障害が発生したとする。この記憶装置システム内の障害により、リモートコピー機能も停止する。業務処理サービスの提供（運用）は、ホストコンピュータＨＡ１で行われているとする。

リモートコピーに障害が発生した後、稼働系ホストコンピュータＨＡ１に別の第２の障害が発生し、業務処理サービスの運用が停止したとする。これにより、他のホストコンピュータＨＡｎ，ＨＢ１〜ＨＢｎでフェイルオーバを実行する必要を生じる。

フェイルオーバ先の選定方法には、種々のものが知られているが、例えば、生存しているノード数（正常なホストコンピュータ数）の多いサイトでフェイルオーバを実行させる方法や、疑似乱数等を用いてフェイルオーバ先をランダムに決定する方法等がある。

図１５に示す第１の障害発生パターンでは、第１サイト１０Ａの記憶装置システム２０Ａが第１の障害によって機能を停止しているので、第２サイト１０ＢのいずれかのホストコンピュータＨＢ１〜ＨＢｎにより、フェイルオーバが実行される。フェイルオーバ先のホストコンピュータは、障害発生前にコピー先ボリュームとして使用されていたボリュームを、コピー元ボリュームに反転させて、業務処理サービスを提供する。

図１６は、第２の障害発生パターンを示す。この例では、リモートコピーラインＣＮ１３に第３の障害が発生したものとする。この障害により、コピー元ボリュームとコピー先ボリュームとを同期させることができなくなる。第１サイト１０Ａ内では、ホストコンピュータＨＡ１〜ＨＡｎからのＩ／Ｏ要求によって、新たなデータが時々刻々と発生する。これらの新たな更新データは、コピー先ボリュームに転送することができないため、差分データＤとして記憶装置システム２０Ａ内に蓄積される。

リモートコピーの発生後に、稼働系ホストコンピュータＨＡ１に第４の障害が発生し、機能を停止したとする。上述のように、例えば、生存ノード数の多いサイトまたはランダムに、フェイルオーバ先が決定される。

もしも、第２サイト１０ＢのホストコンピュータＨＢ１〜ＨＢｎのいずれかがフェイルオーバ先として選定された場合、ホストコンピュータＨＢは、同期が取られていないボリューム（障害発生前のコピー先ボリューム）を用いて、業務処理サービスの提供を再開する可能性がある。しかし、上述のように、本実施例では、保障モジュール３０によって基準となるべきボリュームを管理しており、ボリュームの使用を開始する前に、保障モジュール３０に対してそのボリュームの使用可否を問い合わせる。

従って、本実施例では、リモートコピーの障害が回復してリカバリ処理が行われない限り、第２サイト１０Ｂ内の各ホストコンピュータＨＢ１〜ＨＢｎは、いずれもフェイルオーバ先として稼働することはできない。

第２サイト１０Ｂ内でフェイルオーバ先の選択が失敗する結果、やがて、第１サイト１０Ａ内のホストコンピュータＨＡｎがフェイルオーバ先として選定される。最新データは第１サイト１０Ａ内に保持されているので、第１サイト１０Ａ内のホストコンピュータＨＡは、フェイルオーバ先として適切である。

つまり、本実施例によれば、リモートコピーの障害時に、フェイルオーバ先として不適当なホストコンピュータは、必要なボリュームを使用することができないため、その不適当なホストコンピュータによってフェイルオーバ処理が実行されることはない。従って、古いデータに基づいた誤った運用が開始されるのを未然に防止することができる。

本実施例は、上述のように構成されるので、以下の効果を奏する。本実施例では、リモートコピーに障害が発生した場合において、最新データを保持している基準となるべきボリューム（または記憶装置システムあるいはサイト）を特定して管理し、最新性管理情報３１に基づいてボリュームの使用を制御する。従って、リモートコピーの障害発生後に、例えば、フェイルオーバ処理等の別の制御処理が古いデータに基づいて開始されるのを未然に防止できる。これにより、ストレージシステムの信頼性を向上させることができ、また、リモートコピー処理とフェイルオーバ処理とを整合させて、より有効なディザスタリカバリシステムを構築することができる。

本実施例では、リモートコピーの障害発生後において、ペアボリュームの使用を開始する場合に、最新性管理情報３１のペア状態を更新し、他の保障モジュール３０に通知する構成とした。従って、例えば、一定周期でペア状態を更新して通知させる場合に比べて、ホストコンピュータやネットワークの負荷を低減させつつ、ストレージシステムの信頼性を高めることができる。

図１７〜図２０に基づいて、第２実施例を説明する。本実施例の特徴の一つは、最新性管理情報の通知が一部のホストコンピュータについて正常に処理されなかった場合であっても、ボリュームの使用を可能とする点にある。

図１７は、本実施例によるストレージシステムの一部を構成するホストコンピュータの機能構成の概略を示すブロック図である。ソフトウェアの機能構成は、第１実施例とほぼ同様であるが、最新性管理情報３１Ａ及び更新管理情報３２Ａの構成が第１実施例と相違する。

図１８に示すように、最新性管理情報３１Ａには、新たに「ポリシー」の情報が各コピーペア毎にそれぞれ対応付けられている。このポリシーとは、例えば、ホストコンピュータ間ネットワークＣＮ１２の障害やホストコンピュータ内の障害等により、最新性情報の交換が不能となった場合に備えて、予め基準となるサイト（ボリュームまたは記憶装置システム）を指定しておくための情報である。

ポリシーには、例えば、「第１サイト状態」または「第２サイト状態」のようにサイト名を設定することができる。あるいは、ポリシーとして、「障害発生前運用サイト」または「障害発生前待機サイト」を設定することもできる。障害発生前運用サイトとは、障害発生前において稼働系サイトであったサイトを障害発生後の基準サイトとする情報であり、障害発生前待機サイトとは、障害発生前において待機系サイトであったサイトを障害発生後の基準サイトとする情報である。

更新管理情報３２Ａには、新たに「所属サイト」の情報が各ホストコンピュータ毎にそれぞれ対応付けられている。所属サイトとは、そのホストコンピュータが所属しているサイトを特定するための情報である。

図１９は、保障モジュール３０により実行されるデータ最新性保障モジュール処理のフローチャートである。本実施例に特徴的な部分を説明すると、他サイト登録処理が失敗に終わった場合（S45：失敗）、ポリシー判定処理が実行される（Ｓ１０１）。ポリシー判定処理の詳細は、図２０と共に後述する。

次に、ポリシー判定処理の判定結果が「成功」の場合は、所望のボリュームの使用が可能な場合なので、戻り値に「成功」をセットする（Ｓ４６）。これに対し、ポリシーの判定結果が「失敗」の場合は、所望のボリュームの使用が許可されない場合なので、戻り値に「失敗」をセットする（Ｓ４７）。

つまり、本実施例では、一部の保障モジュール３０において最新性管理情報の更新処理（サイト名登録要求受信処理）が正常に行われなかった場合に、直ちにそのボリュームを使用不可とするのではなく、予め設定されているポリシーを参照し、使用可能か否かを再度判定する。これにより、もしも、ホストコンピュータ間ネットワークＣＮ１２に通信障害等が発生し、他サイト登録処理が失敗に終わった場合でも、ポリシーに基づいてボリュームの使用を許可することができる。

図２０は、図１９中のＳ１０１で示すポリシー判定処理のフローチャートである。まず、保障モジュール３０は、最新性管理情報３１Ａに設定されているポリシーを確認する（Ｓ１１１）。保障モジュール３０は、更新管理情報３２Ａを参照し、その更新結果の欄に「失敗」がセットされているホストコンピュータの名称及び所属サイト名をそれぞれ確認する（Ｓ１１２）。更新結果の欄に「失敗」がセットされているホストコンピュータは、最新性管理情報の更新を行うことができなかったコンピュータである。

次に、保障モジュール３０は、最新性管理情報３１Ａにセットされているポリシーのサイト名（以下、「ポリシー登録サイト名」）と、更新に失敗したホストコンピュータが所属するサイト名（以下、「失敗サイト名」）とを比較し、ポリシー登録サイト名と失敗サイト名とが一致するか否かを判定する（Ｓ１１３）。

ポリシー登録サイト名と失敗サイト名とが一致しない場合、即ち、失敗サイト名の中にポリシー登録サイト名が含まれていない場合は、優先サイトとして予め指定されたサイトへの通信が正常に行われている場合なので、保障モジュール３０は、戻り値に「成功」をセットする（Ｓ１１４）。

ポリシー登録サイト名と失敗サイト名とが一致する場合、即ち、失敗サイト名の中にポリシー登録サイト名が含まれている場合は、基準となるべきサイトで何らかの障害が発生している場合なので、戻り値に「失敗」をセットする（Ｓ１１５）。

但し、ポリシー判定の結果が「成功」であったとしても、間違ったポリシーが設定されていたような場合は、そのボリュームを使用することはできない。例えば、第２サイト１０Ｂが優先サイトとしてポリシーに設定されており、第１サイト１０Ａで他サイト登録処理を実行したような場合である。この場合、第２サイト１０Ｂに何の障害も発生していなければ、ポリシー判定結果は「成功」となるが、第１サイト１０ＡのホストコンピュータＨＡは、第２サイト１０Ｂの記憶装置システム２０Ｂを利用することはできない。そこで、例えば、ポリシー登録サイト名と失敗サイト名とが不一致であって、かつ、ポリシー登録サイト名と自サイト名とが一致する場合に、戻り値に「成功」をセットするように構成することができる。あるいは、最新性管理情報３１Ａにポリシーを定義する場合に、優先サイト名と自サイト名との整合性をチェックするように構成してもよい。

図２１に基づいて、第３実施例を説明する。本実施例の特徴の一つは、優先サイトを相対的に選択する点にある。第２実施例では、図１８中の最新性管理情報３１Ａのペアボリューム番号＃１の行に示すように、ポリシーとして、優先すべきサイトが直接指定されている場合を説明した。

これに対し、本実施例では、図１８中の最新性管理情報３１Ａのペアボリューム番号＃２，＃３にそれぞれ示すように、ポリシーとして、優先すべきサイトを相対的に指定する場合を説明する。

本実施例のポリシー判定処理では、図２１に示すように、最新性管理情報３１Ａを参照してポリシーを確認した後（Ｓ１２１）、対象となるペアボリュームのペア状態（コピー元、コピー先、ペア分割）を確認する（Ｓ１２２）。また、保障モジュール３０は、更新管理情報３２Ａを参照し、失敗サイト名を確認する（Ｓ１２３）。

次に、保障モジュール３０は、相対的に指定されているポリシー登録サイト名と、現在のペア状態とが一致するか否かを判定し、さらに、現在のペア状態がポリシーに適合する場合は、このポリシー登録サイト名と失敗サイト名とが一致するか否か（失敗サイト名にポリシー登録サイト名が含まれているか否か）を判定する（Ｓ１２４）。

ポリシー登録サイト名と失敗サイト名とが不一致の場合、保障モジュール３０は、戻り値に「成功」をセットする（Ｓ１２５）。ポリシー登録サイト名と失敗サイト名とが一致する場合、保障モジュール３０は、戻り値に「失敗」をセットする（Ｓ１２６）。

具体例を挙げる。例えば、所望のボリュームのペア状態が「コピー元状態」、ポリシーが「障害前運用サイト」の場合、現在のペア状態とポリシーとは適合する。また、この場合は、自サイトであるため、失敗サイト名とポリシー登録サイト名とは一致しない。従って、このコピー元ボリュームの使用は許可される。

図２２に基づいて、第４実施例を説明する。本実施例では、ペア状態が「コピー元状態（異常）」である場合に、ホストコンピュータＨからのライトアクセスを可能とした点に一つの特徴がある。

このように構成すると、リモートコピー障害時の動作が、第３実施例において、ポリシーに障害発生前運用サイトを設定する場合と同様の動作となる。つまり、本実施例では、リモートコピーに障害が発生した場合、運用サイトのホストコンピュータは、今まで使用していたコピー元ボリュームをそのまま継続して使用することができる。

また、リモートコピーが行われていない場合でも、コピー元ボリュームへのライトアクセス（及びリードアクセス）が許可されるので、本実施例は、いわゆる非同期式リモートコピーの場合に適用することができる。即ち、非同期式リモートコピーの場合、リモートコピーの停止期間中は、同期式リモートコピーにおいてリモートコピーに障害が発生している期間と結果的に同様となる。

第５実施例では、図２３に示すように、クラスタソフトウェア４０内に複数のコピー管理リソース４２を設け、複数のボリューム２１２を同時に利用する。

第６実施例では、図２４に示すように、コピー管理リソース４２Ａをクラスタソフトウェア４０Ａから独立させる。クラスタソフトウェア４０Ａは、例えば、データベースアプリケーションプログラム等のような外部ディスク（論理ボリューム）を利用する他のアプリケーションプログラム４０Ｂと同様に、プログラムの開始時にコピー管理リソース４２Ａを呼び出して、オンライン要求処理等を利用する。

図２５に基づいて、第７実施例を説明する。本実施例の特徴の一つは、全てのホストコンピュータ内で最新性管理情報を保持するのではなく、各サイト内でそれぞれ一つのホストコンピュータにのみ最新性管理情報を保持させる点にある。

図２５の全体ブロック図に示すように、各サイト１０Ａ，１０Ｂ内において、それぞれ一つ以上のホストコンピュータＨＡ１，ＨＢ１のみが最新性管理情報３１を保持している（図中では、各サイトで一つずつ保持する場合を示す）。これら各ホストコンピュータＨＡ１，ＨＢ１を、例えば、最新性管理ホストコンピュータと呼ぶことができる。

そして、他のホストコンピュータＨＡｎ，ＨＢｎは、問合せ処理３３を実行させることにより、最新性管理ホストコンピュータＨＡ１，ＨＢ１から最新性管理情報３１を取得して使用する。つまり、最新性管理ホストコンピュータＨＡ１，ＨＢ１以外の他のホストコンピュータの保障モジュール３０Ａは、データ最新性保障モジュール処理の実行を最新性管理ホストコンピュータＨＡ１，ＨＢ１の保障モジュール３０に委ね、その処理結果を利用する。

図２６は、本実施例によるコピー管理リソース制御処理のフローチャートである。この処理は、最新性管理ホストコンピュータ以外のホストコンピュータで実行される。最新性管理ホストコンピュータの処理は、前記実施例と同様である。本実施例では、Ｓ１３０，Ｓ１３１にそれぞれ示すように、最新性管理ホストコンピュータのデータ最新性保障モジュール３０へ処理を委ねる。

なお、信頼性向上の観点からは、各サイト内に複数の最新性管理ホストコンピュータを設けるのが好ましい。このように、サイト内の全ホストコンピュータに最新性管理情報３１を保持させるのではなく、その中の一部（但し、複数であるのが好ましい）のホストコンピュータにのみ最新性管理情報３１を保持させる。これにより、他サイト登録処理によって最新性管理情報３１の更新を要求する場合に、要求先のホストコンピュータ数を少なくすることができ、他サイト登録処理の成功確率を高めることができる。

図２７は、第８実施例によるストレージシステムの全体構成図である。本実施例の一つの特徴は、最新性管理情報３１を各記憶装置システム２０Ａ，２０Ｂにそれぞれ保持させる点にある。

各保障モジュール３０Ａは、リモートコピーに障害が発生した場合、ペア基準状態を特定し、記憶装置システム内の最新性管理情報３１に登録させる。そして、各保障モジュール３０Ａは、コピー管理リソース４２からボリューム使用可否の問合せを受けると、自サイト内の記憶装置システムにアクセスし、最新性管理情報３１を参照する。

従って、他サイト登録処理では、各サイトの記憶装置システム２０Ａ，２０Ｂにそれぞれ最新性管理情報３１を記憶させるだけでよく、他サイト登録処理の成功率を高めることができる。なお他のサイトの記憶装置システムに最新性管理情報３１を記憶させる場合、ホストコンピュータ間ネットワークＣＮ１２を介して、そのサイトに存在するいずれか一つのホストコンピュータＨに最新性管理情報３１を送信すればよい。最新性管理情報３１を受信したホストコンピュータＨは、この最新性管理情報３１を自サイトの記憶装置システムに記憶させる。

図２８は、第９実施例に係るストレージシステムの全体構成図である。本実施例では、第８実施例と同様に、各サイト１０Ａ，１０Ｂの各記憶装置システム２０Ａ，２０Ｂ内に最新性管理情報３１を記憶させる。

第８実施例と異なる点は、各サイト１０Ａ，１０Ｂのサイト内ネットワークＣＮ１１同士がネットワークＣＮ１４によって連結されており、保障モジュール３０Ａは、サイト内ネットワークＣＮ１１等を介して、直接的に最新性管理情報３１を記憶装置システム２０Ａ，２０Ｂにそれぞれ記憶させることができる点にある。

なお、第８実施例と本実施例とを結合させ、各保障モジュール３０Ａから各記憶装置システム２０Ａ，２０Ｂに最新性管理情報３１を送信する経路を、ホストコンピュータ間ネットワークＣＮ１２とサイト内ネットワークＣＮ１１との２系統設けてもよい。このように、複数の経路で最新性管理情報３１を記憶装置システム２０Ａ，２０Ｂに送信可能とすることにより、冗長性が増し、より信頼性を高めることができる。

図２９は、第１０実施例に係るストレージシステムの全体構成図である。本実施例の一つの特徴は、保障モジュール３０Ｂを各記憶装置システム２０Ａ，２０Ｂ内にそれぞれ設け、かつ、これら各保障モジュール３０ＢをリモートコピーラインＣＮ１３とは別のネットワークＣＮ１５で直接的に接続した点にある。

従って、本実施例では、ホストコンピュータＨ上で実行されていたデータ最新性保障モジュール処理は、記憶装置システム２０Ａ，２０Ｂ内で実行される。保障モジュール間ネットワークＣＮ１５としては、例えば、SANやインターネット等を採用可能である。

図３０は、第１１実施例に係るストレージシステムの全体構成図である。本実施例では、３個のボリュームが同期して運用されている。即ち、第１サイト１０Ａ内のボリュームと、第２サイト１０Ｂ内のボリュームと、第３サイト１０Ｃ内のボリュームとは、互いに同期している。いずれか一つのボリュームがコピー元となり、他の二つのボリュームがコピー先となる。４個以上のボリュームを同期させることもできる。

なお、本発明は、上述した実施の形態に限定されない。当業者であれば、本発明の範囲内で、種々の追加や変更等を行うことができる。例えば、当業者であれば、前記各実施例を適宜組み合わせることができる。

本発明の実施形態の概念を示す説明図である。 第１実施例に係るストレージシステムの全体構成図である。 サイトのハードウェア構成を示すブロック図である。 ホストコンピュータのソフトウェア構成を示すブロック図である。 コピーペアが取り得るペア状態と各ペア状態の遷移を示す説明図である。 最新性管理情報及び更新管理情報の構成を示す説明図である。 フェイルオーバ処理のフローチャートである。 コピー管理リソース制御処理のフローチャートである。 コピー元ステータス変更処理のフローチャートである。 データ最新性保障モジュール処理のフローチャートである。 他サイト登録処理のフローチャートである。 サイト名登録要求受信処理のフローチャートである。 リカバリ処理のフローチャートである。 障害復旧処理のフローチャートである。 第１の障害発生パターンを示す模式図である。 第２の障害発生パターンを示す模式図である。 第２実施例に係るストレージシステムのホストコンピュータのソフトウェア構成を示すブロック図である。 最新性管理情報及び更新管理情報の構成を示す説明図である。 データ最新性保障モジュール処理のフローチャートである。 ポリシー判定処理のフローチャートである。 第３実施例に係るストレージシステムのポリシー判定処理のフローチャートである。 第４実施例に係るストレージシステムのペア状態の遷移図である。 第５実施例に係るストレージシステムのホストコンピュータのソフトウェア構成を示すブロック図である。 第６実施例に係るストレージシステムのホストコンピュータのソフトウェア構成を示すブロック図である。 第７実施例に係るストレージシステムのブロック図である。 コピー管理リソース制御処理のフローチャートである。 第８実施例に係るストレージシステムのブロック図である。 第９実施例に係るストレージシステムのブロック図である。 第１０実施例に係るストレージシステムのブロック図である。 第１１実施例に係るストレージシステムのブロック図である。

符号の説明

１Ａ…サイト（稼働系）、１Ｂ…サイト（待機系）、２Ａ，２Ｂ…記憶装置、３Ａ，３Ｂ…ホストコンピュータ、４…基準指示部、５…クラスタ制御部、６…差分データ、１０Ａ，１０Ｂ，１０Ｃ…サイト、２０Ａ，２０Ｂ，２０Ｃ…記憶装置システム、３０，３０Ａ，３０Ｂ…データ最新性保障モジュール、３１，３１Ａ…最新性管理情報、３２，３２Ａ…更新管理情報、４０，４０Ａ…クラスタソフトウェア、４０Ｂ…アプリケーションプログラム、４１…リソース管理モジュール、４２，４２Ａ…コピー管理リソース、５０…リモートコピー制御モジュール、２１０…RAIDグループ、２１１…ディスクドライブ、２１２…論理ボリューム、２２０…ディスク制御部、２３０…ホストＩ／Ｆ、２４０…装置間Ｉ／Ｆ、２５０…キャッシュメモリ、２６０…共有メモリ、２７０…スイッチング制御部、３１０…CPU、３２０…メモリ、３３０…ディスクドライブ、３４０…ディスクＩ／Ｆ、３５０…上位ネットワークＩ／Ｆ、３６０…キーボードスイッチ、３７０…ディスプレイ、３８０…バス、ＣＮ…ネットワーク、Ｈ…ホストコンピュータ

Claims (20)

1. 複数のホストコンピュータ及びこれら各ホストコンピュータに論理ボリュームをそれぞれ提供する記憶装置をそれぞれ備える複数のサイトと、
   前記各サイトを互いに通信可能に接続するサイト間ネットワークと、
   前記サイト間ネットワークを介して、前記各記憶装置の前記論理ボリュームを同期させる同期部と、
   前記同期部による処理に同期障害が発生した場合において、基準となるべき記憶装置を指示するための基準指示情報を管理する基準管理部と、
   前記基準指示情報に基づいて前記論理ボリュームの使用を制御する制御部と、
   を備えたストレージシステム。
2. 前記同期部と、前記基準管理部と、前記制御部とは、前記各サイトにそれぞれ設けられている請求項１に記載のストレージシステム。
3. 前記同期部と、前記基準管理部と、前記制御部とは、前記各サイトの前記各ホストコンピュータにそれぞれ設けられている請求項１に記載のストレージシステム。
4. 前記同期部と、前記制御部とは、前記各サイトの前記各ホストコンピュータにそれぞれ設け、前記基準管理部は、前記各サイトの前記記憶装置にそれぞれ設けられている請求項１に記載のストレージシステム。
5. 前記各サイトの前記各ホストコンピュータは、全体として一つのクラスタを構成しており、
   前記制御部は、障害の発生したホストコンピュータで提供されていた所定のサービスを正常な他のホストコンピュータに引き継がせるフェイルオーバ処理を制御するものである請求項１に記載のストレージシステム。
6. 前記基準管理部は、前記各サイトのうち前記基準指示情報の通知を必要とする所定のサイトに、前記基準指示情報をそれぞれ通知する請求項１に記載のストレージシステム。
7. 前記所定のサイトは、前記通知を複数受信した場合に、いずれか古い方の前記基準指示情報を保持する請求項６に記載のストレージシステム。
8. 前記基準管理部による前記所定のサイトへの前記通知が正常に完了した場合に、前記論理ボリュームの使用が許可される請求項６に記載のストレージシステム。
9. 前記基準指示情報には、予め優先サイトを示す情報が対応付けられており、
   前記基準管理部による前記所定のサイトへの前記通知が正常に完了しなかった場合でも、前記優先サイトへの前記通知が正常に完了した場合には、前記論理ボリュームの使用が許可される請求項６に記載のストレージシステム。
10. 前記優先サイトには、予め指定された所定のサイト、障害発生前における運用サイト、障害発生前における待機サイトのうち、少なくともいずれか一つまたは複数を設定可能である請求項９に記載のストレージシステム。
11. 前記基準管理部は、前記同期障害の発生が検出された場合に、前記基準指示情報を更新させる請求項１に記載のストレージシステム。
12. 前記サイト間ネットワークは、前記各サイトの記憶装置同士を通信可能に接続する記憶装置間ネットワークと、前記各サイトの各ホストコンピュータ同士を通信可能に接続するホストコンピュータ間ネットワークとを含んでおり、
    前記同期部は、前記記憶装置間ネットワークを介して、前記各記憶装置の前記論理ボリュームを同期させるものであり、
    前記基準管理部は、前記ホストコンピュータ間ネットワークを介して、前記各サイトのうち前記基準指示情報の通知を必要とする所定のサイトに、前記基準指示情報をそれぞれ通知するものである、請求項６に記載のストレージシステム。
13. 前記サイト間ネットワークは、さらに、前記各サイト内で前記各ホストコンピュータと前記記憶装置とを通信可能に接続するサイト内ネットワーク同士を通信可能に接続するサイト内ネットワーク間ネットワークを含んでおり、
    前記基準管理部は、前記ホストコンピュータ間ネットワークまたは前記サイト内ネットワーク間ネットワークのいずれか一つを介して、前記各サイトのうち前記基準指示情報の通知を必要とする所定のサイトに、前記基準指示情報をそれぞれ通知するものである、請求項１３に記載のストレージシステム。
14. 前記各サイトの前記各ホストコンピュータのうち、所定のホストコンピュータにのみ前記基準指示情報を保持させ、他のホストコンピュータは前記所定のホストコンピュータにアクセスすることにより、前記基準指示情報を利用する請求項１に記載のストレージシステム。
15. 前記同期部は、前記同期障害が解消した場合に、前記基準指示情報に示されている記憶装置をコピー元の記憶装置として、前記同期処理を実行する請求項１に記載のストレージシステム。
16. 前記基準管理部は、前記同期処理が正常に完了した場合に、前記基準指示情報をリセットさせる請求項１５に記載のストレージシステム。
17. 複数の第１ホストコンピュータ及びこれら各第１ホストコンピュータに論理ボリュームをそれぞれ提供する第１記憶装置を有する第１サイトと、
    複数の第２ホストコンピュータ及びこれら各第２ホストコンピュータに論理ボリュームをそれぞれ提供する第２記憶装置を有する第２サイトと、
    前記第１サイト内で、前記各第１ホストコンピュータと前記第１記憶装置とを通信可能に接続する第１サイト内ネットワークと、
    前記第２サイト内で、前記各第２ホストコンピュータと前記第２記憶装置とを通信可能に接続する第２サイト内ネットワークと、
    前記第１記憶装置と前記第２記憶装置とを通信可能に接続する記憶装置間ネットワークと、
    前記各第１ホストコンピュータと前記各第２ホストコンピュータとを通信可能に接続するホストコンピュータ間ネットワークと、を備え、
    （Ａ）前記各第１ホストコンピュータ及び前記各第２ホストコンピュータには、
    （Ａ１）前記各第１，第２ホストコンピュータを全体として一つのクラスタに構成するクラスタ制御部と、
    （Ａ２）前記記憶装置間ネットワークを介して、前記第１記憶装置の前記論理ボリュームと前記第２記憶装置の前記論理ボリュームとを同期させる同期部と、
    （Ａ３）前記同期部による処理に同期障害が発生した場合に、前記第１記憶装置と前記第２記憶装置のいずれを基準とすべきかを指示するための基準指示情報を管理する基準管理部と、をそれぞれ設け、
    （Ｂ）前記基準管理部は、前記同期障害の発生が検出された場合に、前記基準指示情報を更新して、相手方のサイトに前記基準指示情報を通知し、
    （Ｃ）前記クラスタ制御部は、フェイルオーバ発生原因となる障害が発生した場合に、前記基準指示情報に基づいて、フェイルオーバ処理を実行する、
    ストレージシステム。
18. 複数のホストコンピュータ及びこれら各ホストコンピュータに論理ボリュームをそれぞれ提供する記憶装置をそれぞれ備える複数のサイトと、前記各サイトを互いに通信可能に接続するサイト間ネットワークと、このサイト間ネットワークを介して、前記各記憶装置の前記論理ボリュームを同期させる同期部と、を備えたストレージシステムの制御方法であって、
    前記同期部による処理に同期障害が発生したか否かを検出する検出ステップと、
    前記同期障害が検出された場合に、前記各記憶装置のうち基準となるべき記憶装置を一つ選択して基準指示情報を生成する生成ステップと、
    前記生成された基準指示情報を、前記各サイトのうち前記基準指示情報の通知を必要とする所定のサイトにそれぞれ通知する通知ステップと、
    前記所定のサイトへの通知を終えた後に、前記各記憶装置の利用を許可する許可ステップと、
    を含むストレージシステムの制御方法。
19. さらに、フェイルオーバ処理を実行するか否かを判定する第１判定ステップと、
    前記フェイルオーバ処理を実行すべきと判定された場合に、前記基準指示情報に基づいて、前記フェイルオーバ処理に使用する論理ボリュームが使用可能か否かを判定する第２判定ステップと、
    前記フェイルオーバ処理に使用する論理ボリュームが使用可能な場合は、前記フェイルオーバ処理を実行する実行ステップと、
    前記フェイルオーバ処理に使用する論理ボリュームが使用不能な場合は、他のホストコンピュータに前記フェイルオーバ処理の実行を依頼する依頼ステップと、
    を含む請求項１８に記載のストレージシステムの制御方法。
20. 前記許可ステップは、予め設定されている優先サイトへの前記通知が正常に完了した場合には、前記所定のサイトへの前記通知が全て正常に完了していない場合でも、前記各記憶装置の利用を許可するようになっている請求項１８に記載のストレージシステムの制御方法。
    

Images