(57)【要約】      （修正有）【課題】クラスターシステムでの稼働系ホストグループが罹障していないにもかかわらず、待機系ホストグループが稼動系ホストグループからプロセスを横取りしないよう、クラスターシステムの稼動系ホストグループの障害を正確に検出する為のシステムと方法が必要。【解決方法】一つの障害検出方法であって、この方法は第二のロケーションでミラーされているローカルボリュームの一回目の状態チェックを行い、このローカルボリュームに状態変更コマンドを発行し、前記第二のロケーションのホストが状態変更コマンドを発行してから、前記ローカルボリュームの二回目の状態チェックを行い、前記ローカルボリュームの一回目と二回目の状態チェック結果を比較し、前記ローカルボリュームの状態の二回目の結果が一回目と不一致であれば、フェイルオーバ処理を開始することから成る方法。【選択図】  図１
2004252939.tif 000002
【特許請求の範囲】
【請求項１】
一つの方法であって、該方法は：
第二のロケーションでミラーされているローカルボリュームの状態の一回目の取得を行い；
前記第二のロケーションに存在するホストが状態変更コマンドを発行した後に、前記ローカルボリュームの状態の二回目の取得を行い；更に、
前記一回目と二回目の前記ローカルボリュームの状態を比較して、前記第二のロケーションでの障害発生の有無を判定する；
ことから成る方法。
【請求項２】
前記状態変更コマンドはボリュームをプライマリボリューム状態とセカンダリボリューム状態の間で遷移させることを含む、請求項１の方法。
【請求項３】
前記状態変更コマンドはボリュームをミラー状態とミラー停止状態の間で遷移させることを含む、請求項１の方法。
【請求項４】
更に、前記比較結果に基づいて障害の発生をシステムオペレータに通知することから成る、請求項１の方法。
【請求項５】
更に、前記ローカルボリュームの状態の二回目の取得の前に、前記ローカルボリュームに状態変更コマンドを発行することから成る、請求項１の方法。
【請求項６】
更に、前記比較結果に基づいてフェイルオーバ処理を開始することから成る、請求項１の方法。
【請求項７】
一つの方法を実行する為のコンピュータが実行可能な命令を格納したコンピュータ読み取り可能な媒体であって、該方法は：
第二のロケーションでミラーされているローカルボリュームの状態の一回目の取得を行い；
前記第二のロケーションに存在するホストが状態変更コマンドを発行した後に、前記ローカルボリュームの状態の二回目の取得を行い；更に、
前記一回目と二回目の前記ローカルボリュームの状態を比較して、前記第二のロケーションでの障害発生の有無を判定する；
ことから成る方法。
【請求項８】
前記状態変更コマンドはボリュームをプライマリボリューム状態とセカンダリボリューム状態の間で遷移させることを含む、請求項７のコンピュータ読み取り可能な媒体。
【請求項９】
前記状態変更コマンドはボリュームをミラー状態とミラー停止状態の間で遷移させることを含む、請求項７のコンピュータ読み取り可能な媒体。
【請求項１０】
更に、前記方法は、前記比較結果に基づいて障害の発生をシステムオペレータに通知することから成る、請求項７のコンピュータ読み取り可能な媒体。
【請求項１１】
更に、前記方法は、前記ローカルボリュームの状態の二回目の取得の前に前記ローカルボリュームに状態変更コマンドを発行することから成る、請求項７のコンピュータ読み取り可能な媒体。
【請求項１２】
更に、前記方法は、前記比較結果に基づいてフェイルオーバ処理を開始することから成る、請求項７のコンピュータ読み取り可能な媒体。
【請求項１３】
一つのシステムであって、該システムは：
第二のロケーションでミラーされているローカルボリュームの状態の一回目の取得を行う手段；
前記第二のロケーションに存在するホストが状態変更コマンドを発行した後に、前記ローカルボリュームの状態の二回目の取得を行う手段；及び、
前記一回目と二回目の前記ローカルボリュームの状態を比較して、前記第二のロケーションでの障害発生の有無を判定する手段；
とから成るシステム。
【請求項１４】
一つのシステムであって、該システムは一つのエンジンを有し、該エンジンは：
第二のロケーションでミラーされているローカルボリュームの状態の一回目の取得を行い；
前記第二のロケーションに存在するホストが状態変更コマンドを発行した後に、前記ローカルボリュームの状態の二回目の取得を行い；更に、
前記一回目と二回目の前記ローカルボリュームの状態を比較して、前記第二のロケーションでの障害発生の有無を判定することが出来る；
エンジンから成るシステム。
【請求項１５】
前記状態変更コマンドはボリュームをプライマリボリューム状態とセカンダリボリューム状態の間で遷移させることを含む、請求項１４のシステム。
【請求項１６】
前記状態変更コマンドはボリュームをミラー状態とミラー停止状態の間で遷移させることを含む、請求項１４のシステム。
【請求項１７】
前記エンジンは、更に、前記比較結果に基づいて障害の発生をシステムオペレータに通知することが出来る、請求項１４のシステム。
【請求項１８】
前記システムは、更に、第二のエンジンを有し、該第二のエンジンは前記第一のエンジンと通信結合し、前記第一のエンジンがローカルボリュームの二回目の状態を取得する前に、前記ローカルボリュームに状態変更コマンドを発行することが出来る、請求項１４のシステム。
【請求項１９】
前記第一のエンジンは、更に、前記比較結果に基づいてフェイルオーバ処理を開始することが出来る、請求項１４のシステム。
【請求項２０】
一つの方法であって、該方法は：
リモートサイトでミラーされているローカルボリュームに、該ローカルボリュームをミラー停止状態とミラー状態の間で状態の遷移を起こさせる、状態変更コマンドを発行し；更に、
前記リモートサイトでの障害発生を判定する為に、前記状態変更コマンドの発行後前記ローカルボリュームの状態をチェックする；
ことから成る方法。
【請求項２１】
更に、前記チェック結果に基づいてフェイルオーバ処理を開始することから成る、請求項２０の方法。
【請求項２２】
更に、前記チェック結果に基づいてシステムオペレータに障害発生を通知することから成る、請求項２０の方法。
【請求項２３】
一つの方法であって、該方法は：
第二のロケーションでミラーされている第一のロケーションでのボリュームの状態が第一の状態であるかどうかを、前記第二のロケーションのホストが前記第一のロケーションのペアボリュームと前記第二のロケーションのミラーボリュームに対して状態変更コマンドを発行した後に、チェックし；
前記状態が前記第一の状態でなければ、前記第二のロケーションで障害が発生したと判定する；
ことから成る方法。
【請求項２４】
前記コマンドはボリュームをプライマリボリューム状態とセカンダリボリューム状態の間で遷移させることを含む、請求項２３の方法。
【請求項２５】
前記状態変更コマンドはボリュームをミラー状態とミラー停止状態の間で遷移させることを含む、請求項２３の方法。
【請求項２６】
更に、前記第一と第二のロケーションの間でフェイルオーバ処理を開始することから成る、請求項２３の方法。
【請求項２７】
更に、前記ホストが前記コマンドを発行する前に前記第一のロケーションでのボリュームの状態を取得し、前記第一の状態は前記ステップで取得した状態であることから成る、請求項２３の方法。
【請求項２８】
一つの方法であって、該方法は：
第二のロケーションでミラーされている第一のロケーションでのボリュームの状態が第一の状態であるかどうかを、前記第一のロケーションのホストが前記第一のロケーションのペアボリュームと前記第二のロケーションのミラーボリュームに対して状態変更コマンドを発行した後に、チェックし；
前記状態が前記第一の状態でなければ、前記第二のロケーションで状態変化があったと判定する；
ことから成る方法。
【請求項２９】
前記状態変更コマンドはボリュームをミラー状態とミラー停止状態の間で遷移させることを含む、請求項２８の方法。
【請求項３０】
更に、前記第一と第二のロケーションの間でフェイルオーバ処理を開始することから成る、請求項２８の方法。
【請求項３１】
更に、前記ホストが前記コマンドを発行する前に前記第一のロケーションでのボリュームの状態を取得し、前記第一の状態は前記ステップで取得した状態であることから成る、請求項２８の方法。
【請求項３２】
前記第二のロケーションでの状態変化は生存状態から死亡状態への変化であることから成る、請求項２８の方法。
【発明の詳細な説明】
【発明の属する技術分野】
本発明は、一般的にクラスターシステムに関係し、特に、但しこれに限定はしないが、クラスタリングシステムのサイトでの障害通知の為のシステム及び方法を提供する。
【従来の技術】
“クラスタリング”は、複数のコンピュータ（またはホストサ−バ）を結合して、結合された複数のコンピュータをあたかも単一のコンピュータのように動かすことが出来る公知の技術である。クラスタリングは、並列処理、負荷バランス、及び障害回避の為に使用されている。計算集中型のタスク及びリスクを分散させるために、各事業体ではしばしばサーバを集めてクラスターにしている。仮に、クラスターコンピューティングシステム内の一つのサーバが罹障した場合でも、オペレーティングシステムが被害プロセスをクラスターコンピューティングシステム内の生存サーバに移すことにより、エンドユーザは障害サーバが回復される迄の間も業務を継続することが出来る。
クラスターコンピューティングシステムは、アプリケーションのオペレーション中断を防止する為に、次第に普及してきている。或るクラスターコンピューティングシステムは、二つのホスト（例えば、サーバ）グループを持ち、一つのホストグループが稼動系システムを担当し、他のホストグループが待機系システムとして動作する。一つのホストグループは、他のホストグループから地理的に離れて（例えば数百マイルの規模で）分散配置されることが普通である。
各ホストグループは、自らに連携したストレージシステム（例えば、ディスクシステム）を有する。これら二つのストレージシステムは、以下に議論されるリモートミラーリング技術を実装していることが普通である。従って、待機系ホストグループに接続され、連携しているストレージシステムは、稼動系ホストグループに接続され、連携しているストレージシステムと同一のデータを保持している。
この二つのホストサーバグループを接続するネットワークは、典型的にはインターネットのようなＷＡＮ（Ｗｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ：広域ネットワーク）である。二つのホストサーバグループは、このネットワークを介して交信して、エラーチェック等を行うことが出来る。しかしながら、ＷＡＮは、しばしば障害になるので、一般的には信頼性の高いものではない。
インターネットを通したデータ転送は、遅延を蒙り、時にはデータを損失してしまうこともある。従って、待機系ホストグループは、ネットワーク上の問題（例えばリンク障害、データ転送遅れ等）を、誤って稼動系ホストグループの障害と見なしてしまい、（稼動系ホストグループには何も障害がない場合でも、）稼動系ホストグループのプロセスを誤って横取りしてしまうことがあり得る。
稼動系システムのホストグループは、この稼動系システムのホストグループに連携しているストレージシステム内の通常ＰＶＯＬ（Ｐｒｉｍａｒｙ  Ｖｏｌｕｍｅ：プライマリボリューム）と言われるストレージボリュームにアクセスできる。
同様に、待機系システムのホストグループは、この待機系システムのホストグループに連携しているストレージシステム内の通常ＳＶＯＬ（Ｓｅｃｏｎｄａｒｙ  Ｖｏｌｕｍｅ：セカンダリボリューム）  と言われるストレージボリュームにアクセスできる。プライマリボリューム（ＰＶＯＬ）は、セカンダリボリューム（ＳＶＯＬ）によってミラーされる。一つのストレージシステムがＰＶＯＬ、ＳＶＯＬの双方を持つことも出来る。
ストレージベースのリモートミラーリング技術では、所定の距離を離れて維持されている複数のストレージボリューム間にデータのミラーボリュームを生成し、蓄えておく。
この二つのディスクシステムは、ＥＳＣＯＮ（Ｅｎｔｅｒｐｒｉｓｅ  Ｓｙｓｔｅｍ  Ｃｏｎｎｅｃｔｉｖｉｔｙ：エンタープライズシステム接続）アーキテクチュア、ファイバチャネル、通信回線、のようなリモートリンク、又はこれらのリモートリンクの組み合わせを経由して直接接続される。ローカルディスクシステム内のデータは、リモートリンクを通して、リモートディスクシステムに転送され、コピーされる。  これらのリモートリンクは一般に、インターネットのような通常のネットワークに比べて、高度の信頼性がある。もし、リモートリンクの信頼性が低く障害になると、データ損失という大変大きな損失が発生する。
米国特許番号５，４５９，８５７及び５，５４４，３４７にリモートミラーリング技術が開示されている。これらの特許文献では、互いにある距離離れて、リモートリンクで結合された二つのディスクシステムが開示されている。ミラーされたデータは、ローカルディスクシステム及びリモートディスクシステムの双方のディスクに格納されている。ローカルディスクシステムは、ペアの生成が必要になると、ローカルディスク内のデータをコピーする。ホストサーバが当該ディスク内のデ−タを更新すると、このローカルディスクシステムは、当該更新データをリモートリンクを通してリモートディスクシステムに転送する。かくして、一つのディスクシステムのミラーデータイメージを他のディスクシステムに維持する為には、ホスト操作は必要とされない。
米国特許番号５，９３３，６５３では、ローカルディスクシステムとリモートディスクシステム間の別のタイプのデータ転送方法を開示している。同期モードでは、ローカルディスクシステムは、リモートディスクシステムへのデータの転送を完了してから、ホストからの書き込み要求を完了する。準同期モードでは、ローカルディスクシステムは、リモートディスクシステムへの書き込みデータの転送を完了する前にホストからの書き込み要求を完了する。その後のホストからの書き込み要求は、ローカルディスクシステムが前のデータをリモートディスクシステムに転送を完了する迄は実行されない。
適応型コピーモードでは、リモートディスクシステムへ転送すべきデータは、一時的にメモリ内に保存されており、ローカルディスクシステムおよび／またはリモートリンクが、コピータスクを実行できる状態になったときにリモートディスクシステムに転送される。
【発明が解決しようとする課題】
以上に述べた慣用的方法とシステムが有する欠陥を克服する為のシステムと方法が必要である。更に又、クラスターコンピューティングシステムの信頼性を向上させ、これらコンピューティングシステムでの障害検出精度を向上させるシステムと方法が必要である。更に又、クラスターシステムでの稼動系ホストグループが罹障していないにもかかわらず待機系ホストグループが稼動系ホストグループからプロセスを誤って横取りしないように、クラスターシステムの稼動系ホストグループの障害を正確に検出する為のシステムと方法が必要である。
【課題を解決するための手段】
本発明はリモートサイトの障害検出の為のシステムと方法を提供する。本発明のシステムは、セカンダリサイトでミラーされているローカルボリュームに、状態変更コマンドを発行する第一のエンジンを有する。この第一のエンジンに結合した第二のエンジンが、第一のエンジンが上記状態変更コマンドを発行する前に、ローカルボリュームの状態をチェックする。加えて、この第二のエンジンは、セカンダリサイトのホストが次の状態変更コマンドを発行した後に、ローカルボリュームの状態をチェックする。更に、この第二のエンジンは、この二つのローカルボリュームの状態チェック結果を比較して、両者が違っていたらフェイルオーバプロセスを開始する。
本発明の一実施例では、この状態変更コマンドは、ローカルボリュームをプライマリボリューム状態とセカンダリボリューム状態の間で遷移させる機能を持つ。他の実施例では、この状態変更コマンドは、ローカルボリュームをミラー状態とミラー停止状態の間で遷移させる機能を持つ。
本発明の他の実施例では、この第二のエンジンはフェイルオーバプロセスを開始する前に第二の障害検出方法を開始することが出来る。更に本発明の他の実施例では、この第二のエンジンはシステムオペレータに障害発生を通知する機能を持つことが出来る。
本発明の方法は下記により構成される：第二のロケーションでミラーされているローカルボリュームの初回の状態チェックを行う；このローカルボリュームに状態変更コマンドを発行する；第二のロケーションのホストが次の状態変更コマンドを発行後、このローカルボリュームの二回目の状態チェックを行う；このローカルボリュームの状態の初回と二回目のチェック結果を比較する；もし、二回目のチェックでのローカルボリュームの状態が初回のチェック結果と違っていたら、フェイルオーバプロセスを開始する。
【発明の実施の形態】
本発明を以下の図面を参照しながら説明するが、本発明はこの説明に限定されるものではなく、又これに尽きるものでもない。特に断らない限り、全図面を通して同じ要素は、異なった見方をする場合も含めて、同じ参照番号で参照される。
以下の記述は通常のスキルを持った人が本発明を実施したり利用できるように、具体的な応用と要求に基づいて記述されている。この分野にスキルを持った人は、本発明の実施例に対する多様な改変が容易に可能であり、ここで述べられた原理は本発明の精神と範囲を離れる事無く、他の実施方法、応用に適用することが可能である。従って、本発明は以下に示された実施例に限定されることなく、以下に開示された原理、特徴、知識に整合できる範囲で最大限広く解釈される必要がある。
図１は本発明の一実施例に従うシステム５０ａのブロックダイアグラムである。システム５０ａは、プライマリグループ（稼動系ホストグループ）１３０ａ及びセカンダリグループ（待機系ホストグループ）１３０ｂとして示される二つのホストグループで構成される。セカンダリグループ１３０ｂはプライマリグループ１３０ａと実質的には同じでよい。
従って、プライマリグループ１３０ａに対する記述と構成要素は、セカンダリグループ１３０ｂに対しても適用可能である。プライマリグループ１３０ａは典型的に稼動系サイトに存在し、典型的に待機系サイトに存在するセカンダリグループ１３０ｂとは離れて設置される。プライマリグループ１３０ａには一つ以上のホスト１００ａ及び１６０ａが存在し、セカンダリグループ１３０ｂには一つ以上のホスト１００ｂ及び１６０ｂが存在する。これらのホストは典型的にサーバである。
各ホスト１００ａ及び１６０ａは、アプリケーション１０３ａ、クラスタリングプログラム１０４ａ、ハートビートチェック１０１ａ、及びオペレーティングシステム１０２ａを有する。アプリケーション１０３ａ、クラスタリングプログラム１０４ａ、ハートビートチェック１０１ａ、及びオペレーティングシステム１０２ａは、ホスト１００ａ及び１６０ａ上で同期して又は独立して走行する。あるいは又、第一のホスト（例えば、ホスト１００ａ又は１６０ａ）がアプリケーション１０３ａ、クラスタリングプログラム１０４ａ、ハートビートチェック１０１ａ、及びオペレーティングシステム１０２ａを独立に走行させ、第二のホストは、第一のホストが罹障した場合に、これらのプログラムを引き継いで走行させることも出来る。
一つの実施例では、ハートビートチェック１０１ａはモジュール、ソフトウエアプログラム、ファームウエア、ハードウエアまたはこれらのコンポーネントの組合せ、又は他の適当なコンポ−ネントでよい。ハートビートチェック１０１ａはクラスターシステムのサイトでの障害検出を可能にするもので、図３に関連してさらに詳細に議論される。
クラスタリングプログラム１０４ａはホストグループ１３０ａと１３０ｂをクラスターコンピューティングシステムとして稼動させる、通常良く知られたプログラムである。ハートビートチェック１０１ａはクラスタリングプログラム１０４ａから独立したプログラムでも良いし、クラスタリングプログラム１０４ａに付加又は組み込まれて一つのプログラムになっていても良い。
オペレーティングシステム１０２ａはクラスタリングプログラム１０４ａとハートビートチェック１０１ａが使用する為のＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍ  Ｉｎｔｅｒｆａｃｅ：アプリケーションプログラムインターフェース）を提供する。例えば、オペレーティングシステム１０２ａはストレージボリュームに対して、“オープン”、“読み出し”、“書き込み”及び“クローズ”を行わせる。ハートビートチェック１０１ａは例えば、ハートビートメッセージの送信時にこれらのＡＰＩを利用する。（例えば、ボリュームへのポインタを得る為に“オ−プン（ｖｏｌ）”を、メッセージを書き込む為に“書き込み（メッセージ）”  を、及びポインタを破棄する為に“クローズ（ｖｏｌ）”を使用する。）
各ホスト１００ａと１６０ａはユーザの指定に応じて、固有のアプリケーション１０３ａを有することが出来る。例えば、ホスト１００ａはオラクルデータベースを走行させ、ホスト１６０ａは給与支払い業務を走行させても良い。もしホスト１００ａが罹障したら、オラクルデータベースはホスト１６０ａに受け入れられる。この場合、ホスト１６０ａはオラクルデータベースと給与支払い業務双方を走行させることになる。
クラスターコンピューティングシステムで通常良く知られているように、典型的にはアプリケーション１０３ａは通常プライマリグループ１３０ａで走行し、アプリケーション１０３ｂはセカンダリグループ１３０ｂで待機モードになっている。（セカンダリグループ１３０ｂ内の）ハートビートチェック１０１ｂが、プライマリグループ１３０ａに障害が発生したと判断したときは、以下に議論されるように、アプリケーション１０３ａは待機系サイトのセカンダリグループ１３０ｂに“フェイルオーバ”される。言い換えれば、アプリケーション１０３ａが機能しなくなってセカンダリグループ１３０ｂに引き継いだときに、セカンダリグループ１３０ｂのアプリケーション１０３ｂがシステム５０ａの為に走行する。
図１のパス１２０ａは、ホスト１００ａ及び１６０ａとストレージシステム１１０ａとの間の標準プロトコルを用いたデータ転送に使用される。パス１２０ａの例としては、ＳＣＳＩ、ファイバチャネル、ＥＳＣＯＮ、又はイーサネットがあり、これらの標準プロトコルは各々、ＳＣＳＩ−３、ＦＣＰ、ＥＳＣＯＮ、又はＴＣＰ−ＩＰである。
又図１のパス１２０ｂは、ホスト１００ｂ及び１６０ｂとストレージシステム１１０ｂとの間の標準プロトコルを用いたデータ転送に使用される。ここでの標準プロトコルはパス１２０ａと同じであっても良いし、同じでなくても良い。
本発明では、プライマリグループ１３０ａ内の一つのホスト例えばホスト１００ａをマスタホストに選定し、更にセカンダリグループ１３０ｂ内の一つのホスト例えばホスト１００ｂをマスタホストに選定する。以下に述べられる通り、マスタホスト１００ａ及び１００ｂは、フェイルオーバを実行すべきかどうかを判定する為に、“状態変更”信号又はコマンド及び“状態チェック”信号又はコマンドをそれぞれのハートビートボリューム１１１ａ及び１１１ｂに発行する。プライマリグループ１３０ａ内のホスト１６０ａは、その時のマスタホスト１００ａが罹障しているか動作不能状態になっていると見なされると、新しいマスタホストになる事が出来る。同様に、セカンダリグループ１３０ｂ内のホスト１６０ｂは、その時のマスタホスト１００ｂが罹障しているか動作不能状態になっていると見なされると、新しいマスタホストになる事が出来る。
ホスト１００ａ及び１６０ａはネットワーク１４０を経由して、ホスト１００ｂ及び１６０ｂに結合している。かくして、プライマリグループ１３０ａ内の各ホスト１００ａ及び１６０ａはセカンダリグループ１３０ｂ内の各ホスト１００ｂ及び１６０ｂの何れとも交信可能である。典型的にはネットワーク１４０はＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ：ローカルエリアネットワーク）又はインターネットのようなＷＡＮ（Ｗｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ：広域ネットワーク）である。
プライマリグループ１３０ａは稼動系サイトのストレージシステム１１０ａに結合され、セカンダリグループ１３０ｂは待機系サイトのストレージシステム１１０ｂに結合されている。各ストレージシステム１１０ａ及び１１０ｂは、例えばディスクシステムを形成している。各ストレージシステム１１０ａ及び１１０ｂは二つ以上のディスクで構成されていても良い。各ストレージシステム１１０ａ及び１１０ｂは一つ以上のリモートリンク１５０によって相互に結合されており、このリンクを通してストレージシステム１１０ａと１１０ｂとはお互いに交信可能である。典型的には、このリモートリンク１５０は、ＥＳＣＯＮ、ファイバチャネル、及び通信回線又はこれらＥＳＣＯＮ、ファイバチャネル、及び通信回線を含む組合せであってよい。リモートリンク１５０は、一般的に、ネットワーク１４０に比べて、より安全、より高信頼、より高速の通信が可能である。
（ストレージシステム１１０ａ及び１１０ｂで構成される）ディスクシステムは、リモートデータミラーリングシステムを形成し、一つ以上のリモートミラー１１１を有する。各リモートミラー１１１はストレージシステム１１０ａ内のストレージボリューム（ハートビートボリューム）１１１ａ及びストレージシステム１１０ｂ内のストレージボリューム（ハートビートボリューム）１１１ｂで構成される。ハートビートチェック１０１ａ及び１０１ｂは交互に配下のボリューム１１１ａ及び１１１ｂに状態変更コマンドを発行する。状態変更には、ボリュームをプライマリ状態とセカンダリ状態（又はストレージ状態）の間で遷移させたり、ミラー状態とミラー停止状態の間で遷移させたりすることが含まれる。ハートビートチェック１０１ａが慣用の状態変更コマンドをハートビートボリューム１１１ａに発行すると、ストレージシステム１１０ａはハートビートボリューム１１１ａの状態をプライマリ状態からセカンダリ状態に切り替える。
これに伴って、ストレージシステム１１０ａは、リモートリンク１５０を経由して、ストレージシステム１１０ｂに、状態が変わったことを連絡して、ストレージシステム１１０ｂがハートビートボリューム１１１ｂの状態をセカンダリ状態とプライマリ状態の間で切り替える処理を行わせる。
ハートビートチェック１０１ａは、状態変更コマンドを発行する前にハートビートボリューム１１１ａの状態を慣用的技術により読み取り、更にハートビートチェック１０１ｂが次の状態変更コマンドを発行した後に再度読み取る。この結果この前後の状態の間で相違が存在したら、リモートリンク１５０、ボリューム１１１ｂ又はセカンダリグループ１３０ｂに障害があったと判断する。（ここでは、リンク１２０ａ、１２０ｂは安定なリンク（例、短距離ケーブル）とされ、リンク１２０ａ、１２０ｂでの障害は極めて稀であるとして、状態の相違の原因とはしない。）同様に、ハートビートチェック１０１ｂは、状態変更コマンドを発行する前にハートビートボリューム１１１ｂの状態を読み取り、更にハートビートチェック１０１ａが状態変更コマンドを発行した後に再度読み取る。
この結果この前後の状態の間で相違が存在したら、リモートリンク１５０、ボリューム１１１ａ又はプライマリグループ１３０ａに障害があったと判断し、フェイルオーバ処理を開始することが可能である。
リモートミラー１１１、ハートビートボリューム１１１ａ及び１１１ｂ及び（ハートビートボリューム１１１ａをハートビートボリューム１１１ｂに接続する）リモートリンク１５０の数は可変である。ハートビートボリューム１１１ａは幾つかの原因で障害になる可能性がある。従って、二つ以上のミラーペアを使用することはシステム５０ａの高信頼化の為に有益である。
（ストレージシステム１１０ａと１１０ｂで形成される）ディスクシステムは、更に、稼動用データを記憶する為に一つ以上のリモートミラー１１２を有する。各リモートミラー１１２はストレージシステム１１０ａ内のプライマリストレージボリューム（ユーザ用ＰＶＯＬ１１２ａ）及びストレージシステム１１０ｂ内のセカンダリストレージボリューム（ユーザ用ＳＶＯＬ１１２ｂ）を有する。一つの例として、ユーザ用ＰＶＯＬ１１２ａ又は１１２ｂは、オラクル社から提供されるデータベースのような、データベースである。ユーザ用ＰＶＯＬ１１２ａ又は１１２ｂは、ＷＷＷ（Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ）又はテキストファイル等からのデータ記憶用ストレージボリュームとして使用されても良い。
アプリケーション１０３ａがユーザ用ＰＶＯＬ１１２ａ上のデータを更新すると、ストレージシステム１１０ａは、リモートリンク１５１を通して、ストレージシステム１１０ｂにデータを転送する慣用的リモートコピー技術を使用して、当該更新データをユーザ用ＳＶＯＬ１１２ｂに書き込む。交代用リンクとして、リモートリンク１５０が使用されても良い。ストレージシステム１１０ｂは転送されてきたデータを受け取り、ユーザ用ＳＶＯＬ１１２ｂに書き込む。ホスト１００ｂ又は１６０ｂは、（何れが予めマスタホストに指定されていようと、）セカンダリグループ１３０ｂへのフェイルオーバが実施された後に、記憶データの読み取りの為にユーザ用ＳＶＯＬ１１２ｂにアクセスする。
即ち、稼動系サイトで、プライマリグループ１３０ａが割り当てられたオペレーションやタスクの実行が出来ないような障害が発生した場合は、待機系サイトのセカンダリグループ１３０ｂのホスト１００ｂ又は１６０ｂがシステム５０ａの為のオペレーションやタスクを実行する。フェイルオーバの引き金となる障害の例としては、ホスト障害、ストレージシステム又はディスク障害、アプリケーション又はソフトウエア障害、ハードウエア障害、信号パス又は接続障害、又はホストグループ１３０ａがシステム５０ａの為のオペレーションやタスクの実行が出来なくなるような稼動系サイトでの他のタイプの障害が挙げられる。
図２は本発明に基づく例示コンピュータ２００を説明するブロックダイアグラムである。本発明の実施例では、ホスト１００ａ、１６０ａ、１００ｂ、及び１６０ｂはこの例示コンピュータ２００を含むか、このコンピュータの上に実装することができる。この例示コンピュータ２００はＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ：中央処理装置）２０５；稼動メモリ２１０；永続メモリ２２０；Ｉ／Ｏ（Ｉｎｐｕｔ／Ｏｕｔｐｕｔ：入／出力）インターフェース２３０；デイスプレイ２４０及び入力装置２５０を含み、これらは全てシステムバス２６０を通して互いに通信結合されている。ＣＰＵ２０５はインテルＰｅｎｔｉｕｍ（Ｒ）、モトローラＰｏｗｅｒＰＣ（Ｒ）等のマイクロプロセッサ又は永続メモリ２２０内のソフトウエアを実行できる他の如何なるタイプのプロセッサであっても良い。
稼動メモリ２１０はＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ：ランダムアクセスメモリ）又は他の如何なるタイプの読み出し／書き込み可能なメモリデバイス又はメモリデバイスの組合せであっても良い。永続メモリ２２０はハードディスクドライブ、ＲＯＭ（Ｒｅａｄ  ｏｎｌｙ  Ｍｅｍｏｒｙ：読み出し専用メモリ）又は例示コンピュータ２００がシャットオフされた後にもデータを保持できる如何なるタイプのメモリデバイス又はメモリデバイスの組合せであっても良い。Ｉ／Ｏインターフェース２３０はストレージシステム１１０ａのような他のデバイスと有線、無線を問わず通信結合されている。デイスプレイ２４０は陰極線管（ＣＲＴ）表示装置又は他のタイプの表示装置を含んでも良い。入力装置２５０は、キーボード、マウス、又はその他のデータ入力装置又はデータ入力装置の組合せを含んでも良い。
この分野に造詣のある人なら、この例示コンピュータ２００には追加のデバイス、例えば、ネットワーク結合、追加のメモリ、追加のプロセッサ、ＬＡＮ、及びハードウエアチャネル、インターネット又はイントラネットを通してデータ転送する為の入／出力ライン等があってもよいと認識するであろう。更に又、この分野に造詣のある人なら、プログラム及びデータはこの例示コンピュータ２００に別の方法で受信され、格納されても良いと認識するであろう。
図３はハートビートチェック１０１ａの構成を説明するブロックダイアグラムである。本発明の実施例では、ハートビートチェック１０１ｂは、ハートビートチェック１０１ａと実質的に同様である。ハートビートチェック１０１ａは、ハートビートミラー形成エンジン３００；ハートビートミラー停止エンジン３１０；ハービート送信エンジン３２０；ハートビートチェックエンジン３３０；ハートビートステータスデータ構造３４０；及びハートビート状態遷移データ構造３５０を含む。
ハートビートミラー形成エンジン３００は、サイトでの障害検出の為に使用できるように、ミラーボリュームをセットアップする。本発明の一実施例では、ハートビートミラー形成エンジン３００はデイスプレイ２４０上にユーザインタフェースを表示して、ユーザにハートビートボリューム１１１ａ及び１１１ｂのデバイスアドレスのようなハートビートボリュームデバイスアドレスを入力することが出来るようにする。更に加えて、ハートビートミラー形成エンジン３００は、（ハートビートボリュームがＰＶＯＬとＳＶＯＬ状態との間で頻繁に切り替わる為）ユーザに稼動用ボリュームをハートビートボリュームとして使用しないように警告を表示し、実際にユーザが稼動用ボリュームをハートビートボリュームに選んでいないことを確認することも出来る。この確認が終了すると、ハートビートミラー形成エンジン３００は、更に以下に議論されるように、ハートビートミラーを活性化し、ハートビートステータスデータ構造３４０を更新して、ミラーが使用可能になったことを知らせる。
加えて、ハートビートミラー形成エンジン３００は、ハートビートチェック１０１ｂと連携して、状態変更コマンドと状態チェックコマンドが、以下に議論されるように、的確に同期されるように手はずする。ハートビートミラー形成エンジン３００は、何時状態変更コマンドを発行し、何時ハートビートボリューム１１１ｂの状態チェックを実施するか、の計画をハートビートチェック１０１ｂに送信することにより、連携を実行出来る。別案として、ハートビートチェック１０１ａと１０１ｂにはこの計画を事前にセットしておくことも可能で、この場合は、ハートビートミラー形成エンジン３００は、ハートビートチェック１０１ｂについては現時刻を確かめるだけでよい。ハートビートミラー形成エンジン３００については、図７に関連して、更に詳しく議論される。
ハートビートミラー停止エンジン３１０はハートビートミラーを停止し、これに伴って、ハートビートステータスデータ構造３４０を更新する。ハートビートミラー停止エンジン３１０は図８に関連して、更に詳細に論じられる。
ハートビート送信エンジン３２０は、以下に述べられるように、状態変更コマンドをハートビートボリューム１１１ａに定期的に発行する。ハートビートチェックエンジン３３０は、リモートミラーペア１１１ａの状態を、ハートビートチェック１０１ａが状態変更コマンドを発行する時点以前と、ハートビートチェック１０１ｂが状態変更コマンドを発行する時点以後を含む、同期された間隔でチェックする。具体的には、ハートビートチェックエンジン３３０は、ハートビートボリューム１１１ａがプライマリ状態かセカンダリ状態かをチェックし、チェック結果を最新に取得した状態と比較する。もし、ハートビート１０１ｂが状態変更コマンドを発行したと想定される時点以降に当該状態が変化しておれば、ハートビートチェックエンジン３３０は、フェイルオーバ処理を実行する。
本発明の他の実施例として、ハートビートチェックエンジン３３０は、オペレータに表示装置を通して、障害発生の警告通知を行うことも出来る。更に本発明の他の実施例として、ハートビートチェックエンジン３３０は第二の障害検出方法を起動し、第二の方法でも、障害が検出されれば、フェイルオーバ処理を起動することも可能である。
ハートビートステータスデータ構造３４０は、更に図５に関して議論されるように、リモートハートビートミラーが使用可能か否かのデータを含む。更に、ハートビートステータスデータ構造３４０はリモートグループステータスに関するデータ、例えば、リモートグループ１３０ｂが罹障しているか否かのような、情報を保持する。
ハートビートステータスデータ構造３４０に含まれる他の情報には、ハートビートミラーに使用されるデバイス（例えばハートビートボリューム１１１ａ及び１１１ｂ）のアドレスとステータスが含まれる。
ハートビート状態遷移データ構造３５０は、ハートビートミラーペア内のハートビートボリューム１１１ａ及び１１１ｂのような、各ハートビートボリュームの状態データを格納する。各ボリュームに可能な状態としては、ＰＶＯＬ（プライマリボリューム）；ＳＶＯＬ（セカンダリボリューム）；ＳＭＰＬ（単独：未だペアされていない）；ミラー停止状態；及びミラー状態が含まれる。
図４は本発明の一実施例での、ハートビートボリューム１１１ａ及び１１１ｂに対して、状態変更コマンドを発行し、状態をチェックする為のシーケンスを説明する。ハートビートチェック１０１ａのハートビートミラー形成エンジン３００は、ハートビートチェック１０１ｂと協力して、状態変更と状態チェックの処理を適切なシーケンスで行えるようにする。本発明の一つの実施例では、ハートビートチェック１０１ａは、まず状態チェックを発行して、しかる後に（例えば、引き続いて、）状態変更コマンドを発行する。その後に、ハートビート１０１ｂが状態チェック及び状態変更コマンドを発行する。ハートビートチェック１０１ａは、状態チェックコマンドを発行してから状態変更コマンドを発行するシーケンスを繰り返す。
従って、ハートビートチェック１０１ａは、ボリューム１１１ａの状態が変化した否かによって、待機系サイトで障害が発生しているか否かを判定できる。更に、ハートビートチェック１０１ｂも、このシーケンスを繰り返し、ボリューム１１１ｂの状態が変化した否かによって、プライマリサイトで障害が発生しているか否かを判定できる。各シーケンスのステップは１分間隔で発生させても良く、又２分間隔で発生させても良い。この分野に造詣のある人には、このシーケンスで用いられる時間間隔を変えることにより、フェイルオーバ検出精度と速度のバランスを調整できることが理解されるであろう。
代わりの方法として、状態変更と状態チェックコマンドの起動を何かのイベントをベースにしたり、ユーザ指示にすることも出来る。更に又、もしハートビートチェック１０１ａと１０１ｂが対応可能なら、ハートビートチェック１０１ａと１０１ｂは互いに異なった時間間隔で状態変更コマンドを発行することもありえる。例えば、状態変更コマンドを、ハートビートチェック１０１ａが３０秒間隔で、ハートビートチェック１０１ｂが６０秒間隔で発行することも出来るがこれは誤った障害検出に繋がる。然しながら、ハートビートチェック１０１ａは１サイクル当たりに一つ（又はより以上）の障害変化テスト状態を受け入れ、単一の障害変化テスト状態をサイト障害と見なさない様にすることも可能である。
本発明のもう一つの実施例として、ハートビートチェック１０１ａは、ハートビートチェック１０１ｂがハートビートボリューム１１１ｂに状態変更コマンドを発行する予定の前と後の時点で、ハートビートボリューム１１１ａの状態をチェックする方法がある。もし状態変化がない（即ち、ハートビートボリューム１１１ａがＰＶＯＬからＳＶＯＬへと変化していない、又はその逆が起きていない）場合は、セカンダリグループ１３０ｂは罹障していると判断される。同様に、ハートビートチェック１０１ｂは、ハートビートチェック１０１ａがハートビートボリューム１１１ａに状態変更コマンドを発行する予定の前と後の時点で、ハートビートボリューム１１１ｂの状態をチェックすることも出来る。
もし状態が変化していない（即ち、ハートビートボリューム１１１ｂがＰＶＯＬ、ＳＶＯＬの間で変化していない）場合は、プライマリホストグループ１３０ａは罹障していると判断される。上記何れの実施例の場合も、他のサイトでの障害有無を判断するのに、ローカルな状態変化イベントは必要ないことに注目する必要がある。
例えば、ハートビートチェック１０１ａ中のハートビートチェックエンジン３３０は、ハートビート送信エンジン３２０に状態変更コマンドの発行を依頼する必要なしに状態変化を確かめ、システムのオペレーションに支障が無いことを確認することが出来るのである。
本発明の他の実施例においては、ハートビートチェック１０１ｂはハートビートボリューム１１１ｂをミラー状態とミラー停止状態の間で遷移させるべく、状態変更コマンドを発行することが出来る。例えば、ハートビートチェック１０１ｂは、同期コマンドを発行して、次いでハートビートボリューム１１１ｂの状態をチェックする。次に、ハートビートチェック１０１ｂは停止コマンドを発行して、結果をチェックする。次いでこのプロセスは繰り返され、ハートビートチェック１０１ａとの干渉は全く必要ない。
もし、各状態チェックの後に変化が発生しない場合は、稼動系サイトに障害があると判断され、フェイルオーバ処理が起動される。
本発明の更に他の実施例として、ハートビートチェック１０１ａと１０１ｂは共に、（ミラー状態とミラー停止状態の間での）状態変更コマンドと状態チェックコマンドを発行して、リモートサイトの障害を検出することが出来る。例えば、ハートビートチェック１０１ａは、ハートビートボリューム１１１ａの状態をチェックし、次いで、状態変更コマンド（例えば、ミラー停止コマンド）を発行する。ハートビートチェック１０１ｂは、ハートビートボリューム１１１ｂの状態をチェックして、停止状態にあることを確認することにより、障害が存在しないことを確認することが出来る。
もし状態が変化していない（例えばミラー状態のままの）場合は、障害があると判断され、ハートビートチェック１０１ｂはフェイルオーバ処理に入ることが出来る。もし状態が変わっていれば、その後ハートビートチェック１０１ｂは状態変更コマンド（例えば、同期コマンド）を発行し、ハートビートチェック１０１ａはハートビートボリューム１１１ａの状態をチェックして、いまやミラー状態になっていることを確認する。
もし、ミラー状態でない場合は、セカンダリサイトに障害があるとみなされる。このプロセスはその後も繰り返される。
加えて、これらの障害検出方法は、稼動系サイトにおける障害回復状態の判定にも適用できる。例として、稼動系サイトが障害になり、待機系サイトへのフェイルオーバ処理が完了しているとする。従って、待機系サイトが一時的な稼動系サイトとして、アプリケーション１０３ｂを走行させている。この状況においては、ハートビートチェック１０１ｂは、稼動系サイトの回復を確認する為に、上で述べた、単一ホストでのハートビートチェックを実行することが出来る。このケースでは、ハートビートチェック１０１ｂは、ハートビートボリューム１１１ｂに“再同期”（即ちミラー状態への復帰）コマンドを発行する度に状態をチェックする。この状態は、稼動系サイトで、ストレージシステム１１０ａ、リモートミラーリンク１５０、及びペアになっているハートビートボリューム１１１ａが回復する迄は、決して“ミラー状態”に変化することはない。一度、ハートビートボリューム１１１ｂがこの状態変更コマンドに応答して“ミラー状態”に変わったら、このことは、少なくともストレージシステム１１０ａ、リモートミラーリンク１５０、及びペアになっているハートビートボリューム１１１ａが稼動系サイトで機能を回復したことを示す。次に、待機系サイトと稼動系サイトの間で、データボリュームの再同期処理のような、事前の“フォールバック処理”を開始することが出来る。
図５は、ハートビートステータスデータ構造３４０を示す。ハートビートステータスデータ構造３４０は、フィールド５１０でリモートコピーハートビートが使用可能かどうかを示す。ハートビートステータスデータ構造３４０はフィールド５２０では、セカンダリグループ１３０ｂのようなリモートグループが生存しているか（即ち、障害がないか）を示す。ハートビートステータスデータ構造３４０はフィールド５３０、５５０、及び５７０では、ハートビートボリューム１１１ａのようなハートビートボリュームのデバイスアドレスデータを保持する。
ハートビートステータスデータ構造３４０はフィールド５４０、５６０、及び５８０では、ハートビートボリューム１１１ａのようなハートビートボリュームが使用可能か否かを示すデータを保持する。ハートビートミラー形成エンジン３００及びハートビートミラー停止エンジン３１０は、このハートビートステータスデータ構造３４０を更新して、リモートコピーハートビートが使用可能か否かを（フィールド５１０に）反映させ、（フィールド５３０、５５０、及び５７０の）デバイスアドレスを更新する。
ハートビートチェックエンジン３３０は、フィールド５２０を更新して、リモートグループが生存しているか否かを反映させる。フィールド５２０は、ハートビートミラー１１１を形成できるか否かをユーザに示す為に、ハートビートミラー形成エンジン３００によって使用される。
図６はハートビート状態遷移データ構造３５０を示す。各デバイスアドレスに対応して、ハートビートボリューム１１１ａのようなハートビートボリュームの状態を示すフィールドが存在する。これらの状態には、ＰＶＯＬ（プライマリボリューム）、ＳＶＯＬ（セカンダリボリューム）、単独（ミラーなし）、ミラー状態及びミラー停止状態が含まれる。ハートビートチェックエンジン３３０がフィールド６２０−６４０を更新し、デバイス状態を反映させる。ハートビートチェックエンジン３３０はフィールド６２０−６４０を使用し、ハートビートチェック１０１ｂがハートビートボリューム１１１ｂに状態変更コマンドを発行する前後に、ハートビートボリューム１１１ａの状態を比較する。
図７はハートビートミラーを形成するメソッド７００を示すフローチャ−トである。本発明の一実施例では、ハートビートミラー形成エンジン３００がメソッド７００を実行する。先ず最初に、ハートビートをモニタする為のミラーが生成される（７１０）。このミラーはハートビートボリューム１１１ａ及び１１１ｂのような二つのハートビートボリュームの間で形成される。これらのハートビートボリュームは、状態を定期的に変えてしまうので、（例えばアプリケーション１０３ａに用いられるデータを記憶するボリュームである）稼動用ボリュームとしては使用できない。
次にこのミラーはリモートリンク１５０のようなリモートリンクを通して、活性化される（７２０）。活性化（７２０）後、ハートビートステータスデータ構造３４０のようなハートビートステータスデータ構造は更新され（７３０）、ミラーが使用可能か；ローカルハートビートボリュームのデバイスアドレス；各ローカルハートビートボリュームが使用可能か；及びリモートグループが生存しているかが反映される。
データ更新（７３０）終了後、ホスト１６０ｂのようなセカンダリサイトのホストは、ハートビートが形成され、活性化されたことが知らされる（７４０）。加えて、ハートビートチェック１０１ｂが、ハートビートチェック１０１ａと共同して、状態変更コマンドを発行し、状態チェック処理を実行できるようにする為の共同作業情報がセカンダリサイトのホストに送信される。共同作業情報の例としては、コマンド発行の順序シーケンスと、コマンドを実行する時刻情報が含まれる。別の案として、ハートビートチェック１０１ｂは、順序シーケンスは事前設定情報として保有し、共同作業情報としては、時刻情報のみを含むようにしても良い。
セカンダリサイトのホストが報告を受けた（７４０）後に、当セカンダリサイトのハートビートステータスデータ構造は更新される（７５０）。本発明の一実施例では、ハートビートチェック１０１ｂ中のハートビートミラー形成エンジンがこの更新を実施する。この更新には、ミラー状態か否か；ローカルハートビートボリュームのデバイスアドレス；各ローカルハートビートボリュームの使用可能状態；及びリモートグループの生存状態；を示すデータが含まれる。このメソッド７００はこれで終了する。
図８はハートビートミラーを停止するメソッド８００を示すフローチャートである。本発明の一実施例では、ハートビートミラー停止エンジン３１０がこのメソッド８００を実行する。最初にハートビートミラーが停止される（８１０）。その後、ハートビートステータスデータ構造３４０のようなハートビートステータスデータ構造はハートビートミラーの停止状態を反映するように更新される（８２０）。
例えば、フィールド５１０、５４０及び５６０は使用不能状態に変更される。次に、セカンダリ（又は待機系）サイトのホスト１６０ｂのようなホストに停止されたことが知らされる（８３０）。この報告（８３０）の後、セカンダリサイトのハートビートステータスデータ構造は、ローカルハートビートステータスデータ構造の更新（８２０）と同様に更新される（８４０）。以上によりメソッド８００は終了する。
図９はサイトでの障害検出の為のメソッド９００のフローチャートである。一般的に言って、サイトでの障害検出の為のメソッド９００は下記の通り説明される：最初に、ローカルボリュームの状態をある時点でチェックし、この結果を基準状態と比較する。もし両者の間に相違があれば、リモートペアは“罹障している”と判断される。この基準状態は事前に設定することも出来る。他の方法として、どの種類の状態変更コマンドが使用されたかによって決めても良い。更に、この基準状態は特定時点の状態チェック前に取得された状態であっても良い。状態を変更することはメッセージを送信するメカニズムに似ており、状態をチェックすることは問い合わせメカニズムに似ている。どのメカニズムが“状態変更”を実行するか、如何なる頻度で“状態変更”を実行するか、及び如何なる種類の状態変更コマンドが使用されるかは、実装次第である。
本発明の一実施例においては、ハートビート送信エンジン３２０とハートビートチェックエンジン３３０が共同してメソッド９００を実行する。最初に、ハートビートミラー１７０ａのようなリモートハートビートミラーが使用可能かどうかを判定する（９１０）。この判定（９１０）は、ハートビートステータスデータ構造３４０のフィールド５１０をチェックすることにより実行される。もしこのリモートハートビートミラーが使用不能ならメソッド９００は終了する。使用可能なら、ボリューム１１１ａのような全てのローカルハートビートボリュームの状態がＰＶＯＬかＳＶＯＬかがチェックされる（９２０）。更に、ハートビートステータスデータ構造３４０はチェック結果に基づいて更新される（９２０）。
チェック（９２０）の終了後、全ての使用可能のローカルハートビートボリュームに対して、状態変更コマンドが発行される（９３０）。この状態変更コマンドは全てのローカル及びリモートハートビートボリュームの状態を変化させる。一実施例では、この状態変更コマンドはハートビートボリュームをＰＶＯＬからＳＶＯＬへ又はその逆に変化させる。本発明の他の実施例では、この状態変更コマンドはハートビートボリュームをミラー状態からミラー停止状態に又はその逆に変化させる。この状態変更コマンドの発行（９３０）後、メソッド９００はリモートホストが配下のローカルハートビートボリュームに対して状態変更コマンドを発行し終えるのを待つ（９４０）。この待ち時間は事前に設定しておくことが出来る。
この待ち時間（９４０）が終了すると、ローカルハートビートボリュームの状態は再度チェックされる（９５０）。その時のローカルハートビートボリュームの状態は、ハートビートステータスデータ構造３４０に記憶されている前回の状態と比較される（９６０）。二つの連続する状態変更コマンドが（一つはローカルに他はリモートに）発行された訳だから、ローカルハートビートボリュームの状態は元に戻っている必要がある。もし状態が変わったままなら、リモートサイトがハートビートボリュームの状態を元に戻す状態変更コマンドを発行しなかった為で、リモートサイトに障害が発生していることを意味する。もし状態が戻っておれば、次の状態変更コマンドが発行され（９３０）、メソッド９００は繰り返される。もし状態が変わったままなら、フェイルオーバ処理が開始され（９７０）、待機系サイトが障害を見つけた場合は、例えばホスト１００ｂがプライマリホストになりアプリケーション１０３ａを走行する。本発明の他の実施例として、フェイルオーバ処理（９７０）の開始に加えて、又はこれに替えて、メソッド９００はシステムオペレータに障害の発生を音声又は可視メッセージにより通告し、又は、更に障害発生を確認する為に第二の障害検出を実行することも出来る。
本発明の他の実施例として、状態が違っていた場合、メソッド９００は事前設定された時間だけ待って、状態チェック（９５０）と比較（９６０）を繰り返す方法もある。それでも不一致が残れば、フェイルオーバ処理が開始される（９７０）。そうでなければ、状態変更コマンドが発行され（９３０）、メソッド９００は繰り返される。
図１０は本発明の実施例に従うシステム５０ｂのブロックダイアグラムである。システム５０ｂは殆どシステム５０ａと同じである。然しながら、システム５０ｂは、冗長目的に、第二のハートビートミラーを使用可能にしている。もし、第一のミラーペアが障害になっても、第二の  ハートビートミラーを使用して、障害検出を続けることが出来る。
これ迄図解によって本発明の実施例を説明してきたが、これは単に例示の為であって、これ迄の開示により、これ迄の実施例、方法に対して多様な変更、修正が可能である。例えば、状態変更コマンドはＰＶＯＬ、ＳＶＯＬ間の遷移に加えて、ハートビートボリュームのミラー状態、ミラー停止状態の遷移に変えることも出来る。更に、本発明を実施するコンポーネントも、プログラム式汎用デジタルコンピュータを用いても実現できるし、このアプリケーションに特化した集積回路を用いても良いし、更に慣用的コンポーネント及び回路をネットワークで結合して用いても良い。結合は、有線、無線、モデム等を使用しても良い。ここに記述された実施例は、これに尽きるものでもなく、又限定されるものでもない。本発明は、以下に続く請求項によってのみ限定される。
【発明の効果】
従って、このシステムと方法により、クラスターシステムのサイトでの障害検出方法が改善され大きな利益がもたらされる。
【図面の簡単な説明】
【図１】図１は本発明の一実施例に従ったシステムを説明するブロックダイアグラムである。
【図２】図２は本発明に従った例示コンピュータを説明するブロックダイアグラムである。
【図３】図３は図１に示すシステムでのホストにおけるハートビートチェックシステムを説明するブロックダイアグラムである。
【図４】図４は本発明の一実施例に従い、ハートビートボリュームに状態変更コマンドを発行し、その状態をチェックする為のシーケンスを説明する図である
【図５】図５はハートビートステータスデータ構造を説明する図である。
【図６】図６はハートビート状態遷移データ構造を説明する図である。
【図７】図７はハートビートミラーの生成方法を説明するフローチャートである。
【図８】図８はハートビートミラーの停止方法を説明するフローチャートである。
【図９】図９はサイトでの障害検出方法を説明するフローチャートである。
【図１０】図１０は本発明の一実施例に従ったシステムを説明するブロックダイアグラムである。
【符号の説明】
１００ａ・１００ｂ・１６０ａ、１６０ｂ・・・ホスト、１０１・・・ハートビートチェック、１０２・・・ＯＳ、１０３・・・アプリケーション、１０４・・・クラスタリングプログラム、１１０ａ    ・・・稼動系サイトストレージシステム、１１０ｂ待機系サイトストレージシステム、１１１・・・ハートビート（ＰＶＯＬ、ＳＶＯＬ、ＳＭＰＬ）、１１２・・・ユーザ用ＰＶＯＬ、ＳＶＯＬ、２０５・・・ＣＰＵ、２１０・・・稼動メモリ、２２０・・・永続メモリ、２３０・・・Ｉ／Ｏ、２４０・・・表示装置、２５０・・・入力装置、３００・・・ハートビートミラー生成エンジン、３１０・・・ハートビートミラー停止エンジン、３２０・・・ハートビート送信エンジン、３３０・・・ハートビートチェックエンジン、３４０・・・ハートビートステータスデータ構造、３５０・・・ハートビート状態遷移データ構造
【図１】
2004252939.tif 000003
【図２】
2004252939.tif 000004
【図３】
2004252939.tif 000005
【図４】
2004252939.tif 000006
【図５】
2004252939.tif 000007
【図６】
2004252939.tif 000008
【図７】
2004252939.tif 000009
【図８】
2004252939.tif 000010
【図９】
2004252939.tif 000011
【図１０】
2004252939.tif 000012
【外国語明細書】
2004252939.tif 000013
2004252939.tif 000014
2004252939.tif 000015
2004252939.tif 000016
2004252939.tif 000017
2004252939.tif 000018
2004252939.tif 000019
2004252939.tif 000020
2004252939.tif 000021
2004252939.tif 000022
2004252939.tif 000023
2004252939.tif 000024
2004252939.tif 000025
2004252939.tif 000026
2004252939.tif 000027
2004252939.tif 000028
2004252939.tif 000029
2004252939.tif 000030
2004252939.tif 000031
2004252939.tif 000032
2004252939.tif 000033
2004252939.tif 000034
2004252939.tif 000035
2004252939.tif 000036
2004252939.tif 000037
2004252939.tif 000038
2004252939.tif 000039
2004252939.tif 000040
2004252939.tif 000041
2004252939.tif 000042
2004252939.tif 000043
2004252939.tif 000044
2004252939.tif 000045
2004252939.tif 000046
2004252939.tif 000047
2004252939.tif 000048
2004252939.tif 000049
2004252939.tif 000050
2004252939.tif 000051
2004252939.tif 000052
2004252939.tif 000053
2004252939.tif 000054
2004252939.tif 000055
2004252939.tif 000056
2004252939.tif 000057
2004252939.tif 000058
2004252939.tif 000059
2004252939.tif 000060
2004252939.tif 000061