JP4387707B2 - クラスタリングシステムのサイトでの双方向障害検出の為のシステム及び方法 - Google Patents
クラスタリングシステムのサイトでの双方向障害検出の為のシステム及び方法 Download PDFInfo
- Publication number
- JP4387707B2 JP4387707B2 JP2003191589A JP2003191589A JP4387707B2 JP 4387707 B2 JP4387707 B2 JP 4387707B2 JP 2003191589 A JP2003191589 A JP 2003191589A JP 2003191589 A JP2003191589 A JP 2003191589A JP 4387707 B2 JP4387707 B2 JP 4387707B2
- Authority
- JP
- Japan
- Prior art keywords
- state
- local volume
- change command
- host
- time
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
- 238000000034 method Methods 0.000 title claims abstract description 58
- 238000001514 detection method Methods 0.000 title abstract description 16
- 230000008859 change Effects 0.000 claims abstract description 109
- 230000000977 initiatory effect Effects 0.000 claims abstract description 4
- 230000008569 process Effects 0.000 claims description 16
- 230000007704 transition Effects 0.000 claims description 16
- 230000004044 response Effects 0.000 claims description 12
- 238000010586 diagram Methods 0.000 description 11
- 230000015572 biosynthetic process Effects 0.000 description 9
- 238000012546 transfer Methods 0.000 description 9
- 230000015654 memory Effects 0.000 description 8
- 238000012545 processing Methods 0.000 description 8
- 230000005540 biological transmission Effects 0.000 description 5
- 238000004891 communication Methods 0.000 description 4
- 239000000835 fiber Substances 0.000 description 4
- 238000005516 engineering process Methods 0.000 description 3
- 230000006870 function Effects 0.000 description 3
- 230000004913 activation Effects 0.000 description 2
- 238000007796 conventional method Methods 0.000 description 2
- 230000007246 mechanism Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000002085 persistent effect Effects 0.000 description 2
- 238000011084 recovery Methods 0.000 description 2
- 230000001360 synchronised effect Effects 0.000 description 2
- 238000012360 testing method Methods 0.000 description 2
- 230000003936 working memory Effects 0.000 description 2
- 239000008186 active pharmaceutical agent Substances 0.000 description 1
- 230000003044 adaptive effect Effects 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000012790 confirmation Methods 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 230000007812 deficiency Effects 0.000 description 1
- 230000001934 delay Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 230000000007 visual effect Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/2053—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant
- G06F11/2056—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant by mirroring
- G06F11/2069—Management of state, configuration or failover
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
- G06F11/0727—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a storage system, e.g. in a DASD or network based storage system
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0751—Error or fault detection not based on redundancy
- G06F11/0754—Error or fault detection not based on redundancy by exceeding limits
- G06F11/0757—Error or fault detection not based on redundancy by exceeding limits by exceeding a time limit, i.e. time-out, e.g. watchdogs
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/2053—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant
- G06F11/2056—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant by mirroring
- G06F11/2071—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant by mirroring using a plurality of controllers
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Hardware Redundancy (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、一般的にクラスターシステムに関係し、特に、但しこれに限定はしないが、クラスタリングシステムのサイトでの障害通知の為のシステム及び方法を提供する。
【０００２】
【従来の技術】
“クラスタリング”は、複数のコンピュータ（またはホストサ−バ）を結合して、結合された複数のコンピュータをあたかも単一のコンピュータのように動かすことが出来る公知の技術である。クラスタリングは、並列処理、負荷バランス、及び障害回避の為に使用されている。計算集中型のタスク及びリスクを分散させるために、各事業体ではしばしばサーバを集めてクラスターにしている。仮に、クラスターコンピューティングシステム内の一つのサーバが罹障した場合でも、オペレーティングシステムが被害プロセスをクラスターコンピューティングシステム内の生存サーバに移すことにより、エンドユーザは障害サーバが回復される迄の間も業務を継続することが出来る。
【０００３】
クラスターコンピューティングシステムは、アプリケーションのオペレーション中断を防止する為に、次第に普及してきている。或るクラスターコンピューティングシステムは、二つのホスト（例えば、サーバ）グループを持ち、一つのホストグループが稼動系システムを担当し、他のホストグループが待機系システムとして動作する。一つのホストグループは、他のホストグループから地理的に離れて（例えば数百マイルの規模で）分散配置されることが普通である。
【０００４】
各ホストグループは、自らに連携したストレージシステム（例えば、ディスクシステム）を有する。これら二つのストレージシステムは、以下に議論されるリモートミラーリング技術を実装していることが普通である。従って、待機系ホストグループに接続され、連携しているストレージシステムは、稼動系ホストグループに接続され、連携しているストレージシステムと同一のデータを保持している。
【０００５】
この二つのホストサーバグループを接続するネットワークは、典型的にはインターネットのようなＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ：広域ネットワーク）である。二つのホストサーバグループは、このネットワークを介して交信して、エラーチェック等を行うことが出来る。しかしながら、ＷＡＮは、しばしば障害になるので、一般的には信頼性の高いものではない。
【０００６】
インターネットを通したデータ転送は、遅延を蒙り、時にはデータを損失してしまうこともある。従って、待機系ホストグループは、ネットワーク上の問題（例えばリンク障害、データ転送遅れ等）を、誤って稼動系ホストグループの障害と見なしてしまい、（稼動系ホストグループには何も障害がない場合でも、）稼動系ホストグループのプロセスを誤って横取りしてしまうことがあり得る。
【０００７】
稼動系システムのホストグループは、この稼動系システムのホストグループに連携しているストレージシステム内の通常ＰＶＯＬ（Ｐｒｉｍａｒｙ Ｖｏｌｕｍｅ：プライマリボリューム）と言われるストレージボリュームにアクセスできる。
【０００８】
同様に、待機系システムのホストグループは、この待機系システムのホストグループに連携しているストレージシステム内の通常ＳＶＯＬ（Ｓｅｃｏｎｄａｒｙ Ｖｏｌｕｍｅ：セカンダリボリューム） と言われるストレージボリュームにアクセスできる。プライマリボリューム（ＰＶＯＬ）は、セカンダリボリューム（ＳＶＯＬ）によってミラーされる。一つのストレージシステムがＰＶＯＬ、ＳＶＯＬの双方を持つことも出来る。
【０００９】
ストレージベースのリモートミラーリング技術では、所定の距離を離れて維持されている複数のストレージボリューム間にデータのミラーボリュームを生成し、蓄えておく。
【００１０】
この二つのディスクシステムは、ＥＳＣＯＮ（Ｅｎｔｅｒｐｒｉｓｅ Ｓｙｓｔｅｍ Ｃｏｎｎｅｃｔｉｖｉｔｙ：エンタープライズシステム接続）アーキテクチュア、ファイバチャネル、通信回線、のようなリモートリンク、又はこれらのリモートリンクの組み合わせを経由して直接接続される。ローカルディスクシステム内のデータは、リモートリンクを通して、リモートディスクシステムに転送され、コピーされる。 これらのリモートリンクは一般に、インターネットのような通常のネットワークに比べて、高度の信頼性がある。もし、リモートリンクの信頼性が低く障害になると、データ損失という大変大きな損失が発生する。
【００１１】
米国特許番号５，４５９，８５７及び５，５４４，３４７にリモートミラーリング技術が開示されている。これらの特許文献では、互いにある距離離れて、リモートリンクで結合された二つのディスクシステムが開示されている。ミラーされたデータは、ローカルディスクシステム及びリモートディスクシステムの双方のディスクに格納されている。ローカルディスクシステムは、ペアの生成が必要になると、ローカルディスク内のデータをコピーする。ホストサーバが当該ディスク内のデ−タを更新すると、このローカルディスクシステムは、当該更新データをリモートリンクを通してリモートディスクシステムに転送する。かくして、一つのディスクシステムのミラーデータイメージを他のディスクシステムに維持する為には、ホスト操作は必要とされない。
【００１２】
米国特許番号５，９３３，６５３では、ローカルディスクシステムとリモートディスクシステム間の別のタイプのデータ転送方法を開示している。同期モードでは、ローカルディスクシステムは、リモートディスクシステムへのデータの転送を完了してから、ホストからの書き込み要求を完了する。準同期モードでは、ローカルディスクシステムは、リモートディスクシステムへの書き込みデータの転送を完了する前にホストからの書き込み要求を完了する。その後のホストからの書き込み要求は、ローカルディスクシステムが前のデータをリモートディスクシステムに転送を完了する迄は実行されない。
【００１３】
適応型コピーモードでは、リモートディスクシステムへ転送すべきデータは、一時的にメモリ内に保存されており、ローカルディスクシステムおよび／またはリモートリンクが、コピータスクを実行できる状態になったときにリモートディスクシステムに転送される。
【００１４】
【発明が解決しようとする課題】
以上に述べた慣用的方法とシステムが有する欠陥を克服する為のシステムと方法が必要である。更に又、クラスターコンピューティングシステムの信頼性を向上させ、これらコンピューティングシステムでの障害検出精度を向上させるシステムと方法が必要である。更に又、クラスターシステムでの稼動系ホストグループが罹障していないにもかかわらず待機系ホストグループが稼動系ホストグループからプロセスを誤って横取りしないように、クラスターシステムの稼動系ホストグループの障害を正確に検出する為のシステムと方法が必要である。
【００１５】
【課題を解決するための手段】
本発明は、第一のホストと第二のホストとをネットワークを介して接続し、第一のホストと第二のホストから交互に状態変更コマンドを発行するに際して、各ホストは、状態変更コマンドを発行したときに、自己が管理するローカルボリュームの状態を遷移させるとともに、相手のホストに対して、相手のホストが管理するローカルボリュームの状態遷移を指示し、自己が状態変更コマンドを発行する前と相手のホストが状態変更コマンドを発行した後に、それぞれ自己が管理するローカルボリュームの状態を取得し、自己が状態変更コマンドを発行する前に取得した、ローカルボリュームの状態と、相手のホストが状態変更コマンドを発行した後に取得した、ローカルボリュームの状態とを比較して、両者が異なるときには、相手のホストで障害が発生したことを検出することを特徴とするものである。
【００１６】
本発明の一実施例では、この状態変更コマンドは、ローカルボリュームをプライマリボリューム状態とセカンダリボリューム状態の間で遷移させる機能を持つ。他の実施例では、この状態変更コマンドは、ローカルボリュームをミラー状態とミラー停止状態の間で遷移させる機能を持つ。
【００１７】
本発明の他の実施例では、この第二のエンジンはフェイルオーバプロセスを開始する前に第二の障害検出方法を開始することが出来る。更に本発明の他の実施例では、この第二のエンジンはシステムオペレータに障害発生を通知する機能を持つことが出来る。
【００１８】
本発明の方法は下記により構成される：第二のロケーションでミラーされているローカルボリュームの初回の状態チェックを行う；このローカルボリュームに状態変更コマンドを発行する；第二のロケーションのホストが次の状態変更コマンドを発行後、このローカルボリュームの二回目の状態チェックを行う；このローカルボリュームの状態の初回と二回目のチェック結果を比較する；もし、二回目のチェックでのローカルボリュームの状態が初回のチェック結果と違っていたら、フェイルオーバプロセスを開始する。
【００１９】
【発明の実施の形態】
本発明を以下の図面を参照しながら説明するが、本発明はこの説明に限定されるものではなく、又これに尽きるものでもない。特に断らない限り、全図面を通して同じ要素は、異なった見方をする場合も含めて、同じ参照番号で参照される。
【００２０】
以下の記述は通常のスキルを持った人が本発明を実施したり利用できるように、具体的な応用と要求に基づいて記述されている。この分野にスキルを持った人は、本発明の実施例に対する多様な改変が容易に可能であり、ここで述べられた原理は本発明の精神と範囲を離れる事無く、他の実施方法、応用に適用することが可能である。従って、本発明は以下に示された実施例に限定されることなく、以下に開示された原理、特徴、知識に整合できる範囲で最大限広く解釈される必要がある。
【００２１】
図１は本発明の一実施例に従うシステム５０ａのブロックダイアグラムである。システム５０ａは、プライマリグループ（稼動系ホストグループ）１３０ａ及びセカンダリグループ（待機系ホストグループ）１３０ｂとして示される二つのホストグループで構成される。セカンダリグループ１３０ｂはプライマリグループ１３０ａと実質的には同じでよい。
従って、プライマリグループ１３０ａに対する記述と構成要素は、セカンダリグループ１３０ｂに対しても適用可能である。プライマリグループ１３０ａは典型的に稼動系サイトに存在し、典型的に待機系サイトに存在するセカンダリグループ１３０ｂとは離れて設置される。プライマリグループ１３０ａには一つ以上のホスト１００ａ及び１６０ａが存在し、セカンダリグループ１３０ｂには一つ以上のホスト１００ｂ及び１６０ｂが存在する。これらのホストは典型的にサーバである。
【００２２】
各ホスト１００ａ及び１６０ａは、アプリケーション１０３ａ、クラスタリングプログラム１０４ａ、ハートビートチェック１０１ａ、及びオペレーティングシステム１０２ａを有する。アプリケーション１０３ａ、クラスタリングプログラム１０４ａ、ハートビートチェック１０１ａ、及びオペレーティングシステム１０２ａは、ホスト１００ａ及び１６０ａ上で同期して又は独立して走行する。あるいは又、第一のホスト（例えば、ホスト１００ａ又は１６０ａ）がアプリケーション１０３ａ、クラスタリングプログラム１０４ａ、ハートビートチェック１０１ａ、及びオペレーティングシステム１０２ａを独立に走行させ、第二のホストは、第一のホストが罹障した場合に、これらのプログラムを引き継いで走行させることも出来る。
【００２３】
一つの実施例では、ハートビートチェック１０１ａはモジュール、ソフトウエアプログラム、ファームウエア、ハードウエアまたはこれらのコンポーネントの組合せ、又は他の適当なコンポ−ネントでよい。ハートビートチェック１０１ａはクラスターシステムのサイトでの障害検出を可能にするもので、図３に関連してさらに詳細に議論される。
【００２４】
クラスタリングプログラム１０４ａはホストグループ１３０ａと１３０ｂをクラスターコンピューティングシステムとして稼動させる、通常良く知られたプログラムである。ハートビートチェック１０１ａはクラスタリングプログラム１０４ａから独立したプログラムでも良いし、クラスタリングプログラム１０４ａに付加又は組み込まれて一つのプログラムになっていても良い。
【００２５】
オペレーティングシステム１０２ａはクラスタリングプログラム１０４ａとハートビートチェック１０１ａが使用する為のＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ：アプリケーションプログラムインターフェース）を提供する。例えば、オペレーティングシステム１０２ａはストレージボリュームに対して、“オープン”、“読み出し”、“書き込み”及び“クローズ”を行わせる。ハートビートチェック１０１ａは例えば、ハートビートメッセージの送信時にこれらのＡＰＩを利用する。（例えば、ボリュームへのポインタを得る為に“オ−プン（ｖｏｌ）”を、メッセージを書き込む為に“書き込み（メッセージ）” を、及びポインタを破棄する為に“クローズ（ｖｏｌ）”を使用する。）
【００２６】
各ホスト１００ａと１６０ａはユーザの指定に応じて、固有のアプリケーション１０３ａを有することが出来る。例えば、ホスト１００ａはオラクルデータベースを走行させ、ホスト１６０ａは給与支払い業務を走行させても良い。もしホスト１００ａが罹障したら、オラクルデータベースはホスト１６０ａに受け入れられる。この場合、ホスト１６０ａはオラクルデータベースと給与支払い業務双方を走行させることになる。
【００２７】
クラスターコンピューティングシステムで通常良く知られているように、典型的にはアプリケーション１０３ａは通常プライマリグループ１３０ａで走行し、アプリケーション１０３ｂはセカンダリグループ１３０ｂで待機モードになっている。（セカンダリグループ１３０ｂ内の）ハートビートチェック１０１ｂが、プライマリグループ１３０ａに障害が発生したと判断したときは、以下に議論されるように、アプリケーション１０３ａは待機系サイトのセカンダリグループ１３０ｂに“フェイルオーバ”される。言い換えれば、アプリケーション１０３ａが機能しなくなってセカンダリグループ１３０ｂに引き継いだときに、セカンダリグループ１３０ｂのアプリケーション１０３ｂがシステム５０ａの為に走行する。
【００２８】
図１のパス１２０ａは、ホスト１００ａ及び１６０ａとストレージシステム１１０ａとの間の標準プロトコルを用いたデータ転送に使用される。パス１２０ａの例としては、ＳＣＳＩ、ファイバチャネル、ＥＳＣＯＮ、又はイーサネットがあり、これらの標準プロトコルは各々、ＳＣＳＩ−３、ＦＣＰ、ＥＳＣＯＮ、又はＴＣＰ−ＩＰである。
【００２９】
又図１のパス１２０ｂは、ホスト１００ｂ及び１６０ｂとストレージシステム１１０ｂとの間の標準プロトコルを用いたデータ転送に使用される。ここでの標準プロトコルはパス１２０ａと同じであっても良いし、同じでなくても良い。
【００３０】
本発明では、プライマリグループ１３０ａ内の一つのホスト例えばホスト１００ａをマスタホストに選定し、更にセカンダリグループ１３０ｂ内の一つのホスト例えばホスト１００ｂをマスタホストに選定する。以下に述べられる通り、マスタホスト１００ａ及び１００ｂは、フェイルオーバを実行すべきかどうかを判定する為に、“状態変更”信号又はコマンド及び“状態チェック”信号又はコマンドをそれぞれのハートビートボリューム１１１ａ及び１１１ｂに発行する。プライマリグループ１３０ａ内のホスト１６０ａは、その時のマスタホスト１００ａが罹障しているか動作不能状態になっていると見なされると、新しいマスタホストになる事が出来る。同様に、セカンダリグループ１３０ｂ内のホスト１６０ｂは、その時のマスタホスト１００ｂが罹障しているか動作不能状態になっていると見なされると、新しいマスタホストになる事が出来る。
【００３１】
ホスト１００ａ及び１６０ａはネットワーク１４０を経由して、ホスト１００ｂ及び１６０ｂに結合している。かくして、プライマリグループ１３０ａ内の各ホスト１００ａ及び１６０ａはセカンダリグループ１３０ｂ内の各ホスト１００ｂ及び１６０ｂの何れとも交信可能である。典型的にはネットワーク１４０はＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ：ローカルエリアネットワーク）又はインターネットのようなＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ：広域ネットワーク）である。
【００３２】
プライマリグループ１３０ａは稼動系サイトのストレージシステム１１０ａに結合され、セカンダリグループ１３０ｂは待機系サイトのストレージシステム１１０ｂに結合されている。各ストレージシステム１１０ａ及び１１０ｂは、例えばディスクシステムを形成している。各ストレージシステム１１０ａ及び１１０ｂは二つ以上のディスクで構成されていても良い。各ストレージシステム１１０ａ及び１１０ｂは一つ以上のリモートリンク１５０によって相互に結合されており、このリンクを通してストレージシステム１１０ａと１１０ｂとはお互いに交信可能である。典型的には、このリモートリンク１５０は、ＥＳＣＯＮ、ファイバチャネル、及び通信回線又はこれらＥＳＣＯＮ、ファイバチャネル、及び通信回線を含む組合せであってよい。リモートリンク１５０は、一般的に、ネットワーク１４０に比べて、より安全、より高信頼、より高速の通信が可能である。
【００３３】
（ストレージシステム１１０ａ及び１１０ｂで構成される）ディスクシステムは、リモートデータミラーリングシステムを形成し、一つ以上のリモートミラー１１１を有する。各リモートミラー１１１はストレージシステム１１０ａ内のストレージボリューム（ハートビートボリューム）１１１ａ及びストレージシステム１１０ｂ内のストレージボリューム（ハートビートボリューム）１１１ｂで構成される。ハートビートチェック１０１ａ及び１０１ｂは交互に配下のボリューム１１１ａ及び１１１ｂに状態変更コマンドを発行する。状態変更には、ボリュームをプライマリ状態とセカンダリ状態（又はストレージ状態）の間で遷移させたり、ミラー状態とミラー停止状態の間で遷移させたりすることが含まれる。ハートビートチェック１０１ａが慣用の状態変更コマンドをハートビートボリューム１１１ａに発行すると、ストレージシステム１１０ａはハートビートボリューム１１１ａの状態をプライマリ状態からセカンダリ状態に切り替える。
【００３４】
これに伴って、ストレージシステム１１０ａは、リモートリンク１５０を経由して、ストレージシステム１１０ｂに、状態が変わったことを連絡して、ストレージシステム１１０ｂがハートビートボリューム１１１ｂの状態をセカンダリ状態とプライマリ状態の間で切り替える処理を行わせる。
【００３５】
ハートビートチェック１０１ａは、状態変更コマンドを発行する前にハートビートボリューム１１１ａの状態を慣用的技術により読み取り、更にハートビートチェック１０１ｂが次の状態変更コマンドを発行した後に再度読み取る。この結果この前後の状態の間で相違が存在したら、リモートリンク１５０、ボリューム１１１ｂ又はセカンダリグループ１３０ｂに障害があったと判断する。（ここでは、リンク１２０ａ、１２０ｂは安定なリンク（例、短距離ケーブル）とされ、リンク１２０ａ、１２０ｂでの障害は極めて稀であるとして、状態の相違の原因とはしない。）同様に、ハートビートチェック１０１ｂは、状態変更コマンドを発行する前にハートビートボリューム１１１ｂの状態を読み取り、更にハートビートチェック１０１ａが状態変更コマンドを発行した後に再度読み取る。
【００３６】
この結果この前後の状態の間で相違が存在したら、リモートリンク１５０、ボリューム１１１ａ又はプライマリグループ１３０ａに障害があったと判断し、フェイルオーバ処理を開始することが可能である。
【００３７】
リモートミラー１１１、ハートビートボリューム１１１ａ及び１１１ｂ及び（ハートビートボリューム１１１ａをハートビートボリューム１１１ｂに接続する）リモートリンク１５０の数は可変である。ハートビートボリューム１１１ａは幾つかの原因で障害になる可能性がある。従って、二つ以上のミラーペアを使用することはシステム５０ａの高信頼化の為に有益である。
【００３８】
（ストレージシステム１１０ａと１１０ｂで形成される）ディスクシステムは、更に、稼動用データを記憶する為に一つ以上のリモートミラー１１２を有する。各リモートミラー１１２はストレージシステム１１０ａ内のプライマリストレージボリューム（ユーザ用ＰＶＯＬ１１２ａ）及びストレージシステム１１０ｂ内のセカンダリストレージボリューム（ユーザ用ＳＶＯＬ１１２ｂ）を有する。一つの例として、ユーザ用ＰＶＯＬ１１２ａ又は１１２ｂは、オラクル社から提供されるデータベースのような、データベースである。ユーザ用ＰＶＯＬ１１２ａ又は１１２ｂは、ＷＷＷ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）又はテキストファイル等からのデータ記憶用ストレージボリュームとして使用されても良い。
【００３９】
アプリケーション１０３ａがユーザ用ＰＶＯＬ１１２ａ上のデータを更新すると、ストレージシステム１１０ａは、リモートリンク１５１を通して、ストレージシステム１１０ｂにデータを転送する慣用的リモートコピー技術を使用して、当該更新データをユーザ用ＳＶＯＬ１１２ｂに書き込む。交代用リンクとして、リモートリンク１５０が使用されても良い。ストレージシステム１１０ｂは転送されてきたデータを受け取り、ユーザ用ＳＶＯＬ１１２ｂに書き込む。ホスト１００ｂ又は１６０ｂは、（何れが予めマスタホストに指定されていようと、）セカンダリグループ１３０ｂへのフェイルオーバが実施された後に、記憶データの読み取りの為にユーザ用ＳＶＯＬ１１２ｂにアクセスする。
【００４０】
即ち、稼動系サイトで、プライマリグループ１３０ａが割り当てられたオペレーションやタスクの実行が出来ないような障害が発生した場合は、待機系サイトのセカンダリグループ１３０ｂのホスト１００ｂ又は１６０ｂがシステム５０ａの為のオペレーションやタスクを実行する。フェイルオーバの引き金となる障害の例としては、ホスト障害、ストレージシステム又はディスク障害、アプリケーション又はソフトウエア障害、ハードウエア障害、信号パス又は接続障害、又はホストグループ１３０ａがシステム５０ａの為のオペレーションやタスクの実行が出来なくなるような稼動系サイトでの他のタイプの障害が挙げられる。
【００４１】
図２は本発明に基づく例示コンピュータ２００を説明するブロックダイアグラムである。本発明の実施例では、ホスト１００ａ、１６０ａ、１００ｂ、及び１６０ｂはこの例示コンピュータ２００を含むか、このコンピュータの上に実装することができる。この例示コンピュータ２００はＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ：中央処理装置）２０５；稼動メモリ２１０；永続メモリ２２０；Ｉ／Ｏ（Ｉｎｐｕｔ／Ｏｕｔｐｕｔ：入／出力）インターフェース２３０；デイスプレイ２４０及び入力装置２５０を含み、これらは全てシステムバス２６０を通して互いに通信結合されている。ＣＰＵ２０５はインテルＰｅｎｔｉｕｍ（Ｒ）、モトローラＰｏｗｅｒＰＣ（Ｒ）等のマイクロプロセッサ又は永続メモリ２２０内のソフトウエアを実行できる他の如何なるタイプのプロセッサであっても良い。
【００４２】
稼動メモリ２１０はＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ：ランダムアクセスメモリ）又は他の如何なるタイプの読み出し／書き込み可能なメモリデバイス又はメモリデバイスの組合せであっても良い。永続メモリ２２０はハードディスクドライブ、ＲＯＭ（Ｒｅａｄ ｏｎｌｙ Ｍｅｍｏｒｙ：読み出し専用メモリ）又は例示コンピュータ２００がシャットオフされた後にもデータを保持できる如何なるタイプのメモリデバイス又はメモリデバイスの組合せであっても良い。Ｉ／Ｏインターフェース２３０はストレージシステム１１０ａのような他のデバイスと有線、無線を問わず通信結合されている。デイスプレイ２４０は陰極線管（ＣＲＴ）表示装置又は他のタイプの表示装置を含んでも良い。入力装置２５０は、キーボード、マウス、又はその他のデータ入力装置又はデータ入力装置の組合せを含んでも良い。
【００４３】
この分野に造詣のある人なら、この例示コンピュータ２００には追加のデバイス、例えば、ネットワーク結合、追加のメモリ、追加のプロセッサ、ＬＡＮ、及びハードウエアチャネル、インターネット又はイントラネットを通してデータ転送する為の入／出力ライン等があってもよいと認識するであろう。更に又、この分野に造詣のある人なら、プログラム及びデータはこの例示コンピュータ２００に別の方法で受信され、格納されても良いと認識するであろう。
【００４４】
図３はハートビートチェック１０１ａの構成を説明するブロックダイアグラムである。本発明の実施例では、ハートビートチェック１０１ｂは、ハートビートチェック１０１ａと実質的に同様である。ハートビートチェック１０１ａは、ハートビートミラー形成エンジン３００；ハートビートミラー停止エンジン３１０；ハービート送信エンジン３２０；ハートビートチェックエンジン３３０；ハートビートステータスデータ構造３４０；及びハートビート状態遷移データ構造３５０を含む。
【００４５】
ハートビートミラー形成エンジン３００は、サイトでの障害検出の為に使用できるように、ミラーボリュームをセットアップする。本発明の一実施例では、ハートビートミラー形成エンジン３００はデイスプレイ２４０上にユーザインタフェースを表示して、ユーザにハートビートボリューム１１１ａ及び１１１ｂのデバイスアドレスのようなハートビートボリュームデバイスアドレスを入力することが出来るようにする。更に加えて、ハートビートミラー形成エンジン３００は、（ハートビートボリュームがＰＶＯＬとＳＶＯＬ状態との間で頻繁に切り替わる為）ユーザに稼動用ボリュームをハートビートボリュームとして使用しないように警告を表示し、実際にユーザが稼動用ボリュームをハートビートボリュームに選んでいないことを確認することも出来る。この確認が終了すると、ハートビートミラー形成エンジン３００は、更に以下に議論されるように、ハートビートミラーを活性化し、ハートビートステータスデータ構造３４０を更新して、ミラーが使用可能になったことを知らせる。
【００４６】
加えて、ハートビートミラー形成エンジン３００は、ハートビートチェック１０１ｂと連携して、状態変更コマンドと状態チェックコマンドが、以下に議論されるように、的確に同期されるように手はずする。ハートビートミラー形成エンジン３００は、何時状態変更コマンドを発行し、何時ハートビートボリューム１１１ｂの状態チェックを実施するか、の計画をハートビートチェック１０１ｂに送信することにより、連携を実行出来る。別案として、ハートビートチェック１０１ａと１０１ｂにはこの計画を事前にセットしておくことも可能で、この場合は、ハートビートミラー形成エンジン３００は、ハートビートチェック１０１ｂについては現時刻を確かめるだけでよい。ハートビートミラー形成エンジン３００については、図７に関連して、更に詳しく議論される。
【００４７】
ハートビートミラー停止エンジン３１０はハートビートミラーを停止し、これに伴って、ハートビートステータスデータ構造３４０を更新する。ハートビートミラー停止エンジン３１０は図８に関連して、更に詳細に論じられる。
【００４８】
ハートビート送信エンジン３２０は、以下に述べられるように、状態変更コマンドをハートビートボリューム１１１ａに定期的に発行する。ハートビートチェックエンジン３３０は、リモートミラーペア１１１ａの状態を、ハートビートチェック１０１ａが状態変更コマンドを発行する時点以前と、ハートビートチェック１０１ｂが状態変更コマンドを発行する時点以後を含む、同期された間隔でチェックする。具体的には、ハートビートチェックエンジン３３０は、ハートビートボリューム１１１ａがプライマリ状態かセカンダリ状態かをチェックし、チェック結果を最新に取得した状態と比較する。もし、ハートビート１０１ｂが状態変更コマンドを発行したと想定される時点以降に当該状態が変化しておれば、ハートビートチェックエンジン３３０は、フェイルオーバ処理を実行する。
【００４９】
本発明の他の実施例として、ハートビートチェックエンジン３３０は、オペレータに表示装置を通して、障害発生の警告通知を行うことも出来る。更に本発明の他の実施例として、ハートビートチェックエンジン３３０は第二の障害検出方法を起動し、第二の方法でも、障害が検出されれば、フェイルオーバ処理を起動することも可能である。
【００５０】
ハートビートステータスデータ構造３４０は、更に図５に関して議論されるように、リモートハートビートミラーが使用可能か否かのデータを含む。更に、ハートビートステータスデータ構造３４０はリモートグループステータスに関するデータ、例えば、リモートグループ１３０ｂが罹障しているか否かのような、情報を保持する。
【００５１】
ハートビートステータスデータ構造３４０に含まれる他の情報には、ハートビートミラーに使用されるデバイス（例えばハートビートボリューム１１１ａ及び１１１ｂ）のアドレスとステータスが含まれる。
【００５２】
ハートビート状態遷移データ構造３５０は、ハートビートミラーペア内のハートビートボリューム１１１ａ及び１１１ｂのような、各ハートビートボリュームの状態データを格納する。各ボリュームに可能な状態としては、ＰＶＯＬ（プライマリボリューム）；ＳＶＯＬ（セカンダリボリューム）；ＳＭＰＬ（単独：未だペアされていない）；ミラー停止状態；及びミラー状態が含まれる。
【００５３】
図４は本発明の一実施例での、ハートビートボリューム１１１ａ及び１１１ｂに対して、状態変更コマンドを発行し、状態をチェックする為のシーケンスを説明する。ハートビートチェック１０１ａのハートビートミラー形成エンジン３００は、ハートビートチェック１０１ｂと協力して、状態変更と状態チェックの処理を適切なシーケンスで行えるようにする。本発明の一つの実施例では、ハートビートチェック１０１ａは、まず状態チェックを発行して、しかる後に（例えば、引き続いて、）状態変更コマンドを発行する。その後に、ハートビート１０１ｂが状態チェック及び状態変更コマンドを発行する。ハートビートチェック１０１ａは、状態チェックコマンドを発行してから状態変更コマンドを発行するシーケンスを繰り返す。
【００５４】
従って、ハートビートチェック１０１ａは、ボリューム１１１ａの状態が変化した否かによって、待機系サイトで障害が発生しているか否かを判定できる。更に、ハートビートチェック１０１ｂも、このシーケンスを繰り返し、ボリューム１１１ｂの状態が変化した否かによって、プライマリサイトで障害が発生しているか否かを判定できる。各シーケンスのステップは１分間隔で発生させても良く、又２分間隔で発生させても良い。この分野に造詣のある人には、このシーケンスで用いられる時間間隔を変えることにより、フェイルオーバ検出精度と速度のバランスを調整できることが理解されるであろう。
【００５５】
代わりの方法として、状態変更と状態チェックコマンドの起動を何かのイベントをベースにしたり、ユーザ指示にすることも出来る。更に又、もしハートビートチェック１０１ａと１０１ｂが対応可能なら、ハートビートチェック１０１ａと１０１ｂは互いに異なった時間間隔で状態変更コマンドを発行することもありえる。例えば、状態変更コマンドを、ハートビートチェック１０１ａが３０秒間隔で、ハートビートチェック１０１ｂが６０秒間隔で発行することも出来るがこれは誤った障害検出に繋がる。然しながら、ハートビートチェック１０１ａは１サイクル当たりに一つ（又はより以上）の障害変化テスト状態を受け入れ、単一の障害変化テスト状態をサイト障害と見なさない様にすることも可能である。
【００５６】
本発明のもう一つの実施例として、ハートビートチェック１０１ａは、ハートビートチェック１０１ｂがハートビートボリューム１１１ｂに状態変更コマンドを発行する予定の前と後の時点で、ハートビートボリューム１１１ａの状態をチェックする方法がある。もし状態変化がない（即ち、ハートビートボリューム１１１ａがＰＶＯＬからＳＶＯＬへと変化していない、又はその逆が起きていない）場合は、セカンダリグループ１３０ｂは罹障していると判断される。同様に、ハートビートチェック１０１ｂは、ハートビートチェック１０１ａがハートビートボリューム１１１ａに状態変更コマンドを発行する予定の前と後の時点で、ハートビートボリューム１１１ｂの状態をチェックすることも出来る。
【００５７】
もし状態が変化していない（即ち、ハートビートボリューム１１１ｂがＰＶＯＬ、ＳＶＯＬの間で変化していない）場合は、プライマリホストグループ１３０ａは罹障していると判断される。上記何れの実施例の場合も、他のサイトでの障害有無を判断するのに、ローカルな状態変化イベントは必要ないことに注目する必要がある。
【００５８】
例えば、ハートビートチェック１０１ａ中のハートビートチェックエンジン３３０は、ハートビート送信エンジン３２０に状態変更コマンドの発行を依頼する必要なしに状態変化を確かめ、システムのオペレーションに支障が無いことを確認することが出来るのである。
【００５９】
本発明の他の実施例においては、ハートビートチェック１０１ｂはハートビートボリューム１１１ｂをミラー状態とミラー停止状態の間で遷移させるべく、状態変更コマンドを発行することが出来る。例えば、ハートビートチェック１０１ｂは、同期コマンドを発行して、次いでハートビートボリューム１１１ｂの状態をチェックする。次に、ハートビートチェック１０１ｂは停止コマンドを発行して、結果をチェックする。次いでこのプロセスは繰り返され、ハートビートチェック１０１ａとの干渉は全く必要ない。
【００６０】
もし、各状態チェックの後に変化が発生しない場合は、稼動系サイトに障害があると判断され、フェイルオーバ処理が起動される。
【００６１】
本発明の更に他の実施例として、ハートビートチェック１０１ａと１０１ｂは共に、（ミラー状態とミラー停止状態の間での）状態変更コマンドと状態チェックコマンドを発行して、リモートサイトの障害を検出することが出来る。例えば、ハートビートチェック１０１ａは、ハートビートボリューム１１１ａの状態をチェックし、次いで、状態変更コマンド（例えば、ミラー停止コマンド）を発行する。ハートビートチェック１０１ｂは、ハートビートボリューム１１１ｂの状態をチェックして、停止状態にあることを確認することにより、障害が存在しないことを確認することが出来る。
【００６２】
もし状態が変化していない（例えばミラー状態のままの）場合は、障害があると判断され、ハートビートチェック１０１ｂはフェイルオーバ処理に入ることが出来る。もし状態が変わっていれば、その後ハートビートチェック１０１ｂは状態変更コマンド（例えば、同期コマンド）を発行し、ハートビートチェック１０１ａはハートビートボリューム１１１ａの状態をチェックして、いまやミラー状態になっていることを確認する。
【００６３】
もし、ミラー状態でない場合は、セカンダリサイトに障害があるとみなされる。このプロセスはその後も繰り返される。
【００６４】
加えて、これらの障害検出方法は、稼動系サイトにおける障害回復状態の判定にも適用できる。例として、稼動系サイトが障害になり、待機系サイトへのフェイルオーバ処理が完了しているとする。従って、待機系サイトが一時的な稼動系サイトとして、アプリケーション１０３ｂを走行させている。この状況においては、ハートビートチェック１０１ｂは、稼動系サイトの回復を確認する為に、上で述べた、単一ホストでのハートビートチェックを実行することが出来る。このケースでは、ハートビートチェック１０１ｂは、ハートビートボリューム１１１ｂに“再同期”（即ちミラー状態への復帰）コマンドを発行する度に状態をチェックする。この状態は、稼動系サイトで、ストレージシステム１１０ａ、リモートミラーリンク１５０、及びペアになっているハートビートボリューム１１１ａが回復する迄は、決して“ミラー状態”に変化することはない。一度、ハートビートボリューム１１１ｂがこの状態変更コマンドに応答して“ミラー状態”に変わったら、このことは、少なくともストレージシステム１１０ａ、リモートミラーリンク１５０、及びペアになっているハートビートボリューム１１１ａが稼動系サイトで機能を回復したことを示す。次に、待機系サイトと稼動系サイトの間で、データボリュームの再同期処理のような、事前の“フォールバック処理”を開始することが出来る。
【００６５】
図５は、ハートビートステータスデータ構造３４０を示す。ハートビートステータスデータ構造３４０は、フィールド５１０でリモートコピーハートビートが使用可能かどうかを示す。ハートビートステータスデータ構造３４０はフィールド５２０では、セカンダリグループ１３０ｂのようなリモートグループが生存しているか（即ち、障害がないか）を示す。ハートビートステータスデータ構造３４０はフィールド５３０、５５０、及び５７０では、ハートビートボリューム１１１ａのようなハートビートボリュームのデバイスアドレスデータを保持する。
【００６６】
ハートビートステータスデータ構造３４０はフィールド５４０、５６０、及び５８０では、ハートビートボリューム１１１ａのようなハートビートボリュームが使用可能か否かを示すデータを保持する。ハートビートミラー形成エンジン３００及びハートビートミラー停止エンジン３１０は、このハートビートステータスデータ構造３４０を更新して、リモートコピーハートビートが使用可能か否かを（フィールド５１０に）反映させ、（フィールド５３０、５５０、及び５７０の）デバイスアドレスを更新する。
【００６７】
ハートビートチェックエンジン３３０は、フィールド５２０を更新して、リモートグループが生存しているか否かを反映させる。フィールド５２０は、ハートビートミラー１１１を形成できるか否かをユーザに示す為に、ハートビートミラー形成エンジン３００によって使用される。
【００６８】
図６はハートビート状態遷移データ構造３５０を示す。各デバイスアドレスに対応して、ハートビートボリューム１１１ａのようなハートビートボリュームの状態を示すフィールドが存在する。これらの状態には、ＰＶＯＬ（プライマリボリューム）、ＳＶＯＬ（セカンダリボリューム）、単独（ミラーなし）、ミラー状態及びミラー停止状態が含まれる。ハートビートチェックエンジン３３０がフィールド６２０−６４０を更新し、デバイス状態を反映させる。ハートビートチェックエンジン３３０はフィールド６２０−６４０を使用し、ハートビートチェック１０１ｂがハートビートボリューム１１１ｂに状態変更コマンドを発行する前後に、ハートビートボリューム１１１ａの状態を比較する。
【００６９】
図７はハートビートミラーを形成するメソッド７００を示すフローチャ−トである。本発明の一実施例では、ハートビートミラー形成エンジン３００がメソッド７００を実行する。先ず最初に、ハートビートをモニタする為のミラーが生成される（７１０）。このミラーはハートビートボリューム１１１ａ及び１１１ｂのような二つのハートビートボリュームの間で形成される。これらのハートビートボリュームは、状態を定期的に変えてしまうので、（例えばアプリケーション１０３ａに用いられるデータを記憶するボリュームである）稼動用ボリュームとしては使用できない。
【００７０】
次にこのミラーはリモートリンク１５０のようなリモートリンクを通して、活性化される（７２０）。活性化（７２０）後、ハートビートステータスデータ構造３４０のようなハートビートステータスデータ構造は更新され（７３０）、ミラーが使用可能か；ローカルハートビートボリュームのデバイスアドレス；各ローカルハートビートボリュームが使用可能か；及びリモートグループが生存しているかが反映される。
【００７１】
データ更新（７３０）終了後、ホスト１６０ｂのようなセカンダリサイトのホストは、ハートビートが形成され、活性化されたことが知らされる（７４０）。加えて、ハートビートチェック１０１ｂが、ハートビートチェック１０１ａと共同して、状態変更コマンドを発行し、状態チェック処理を実行できるようにする為の共同作業情報がセカンダリサイトのホストに送信される。共同作業情報の例としては、コマンド発行の順序シーケンスと、コマンドを実行する時刻情報が含まれる。別の案として、ハートビートチェック１０１ｂは、順序シーケンスは事前設定情報として保有し、共同作業情報としては、時刻情報のみを含むようにしても良い。
【００７２】
セカンダリサイトのホストが報告を受けた（７４０）後に、当セカンダリサイトのハートビートステータスデータ構造は更新される（７５０）。本発明の一実施例では、ハートビートチェック１０１ｂ中のハートビートミラー形成エンジンがこの更新を実施する。この更新には、ミラー状態か否か；ローカルハートビートボリュームのデバイスアドレス；各ローカルハートビートボリュームの使用可能状態；及びリモートグループの生存状態；を示すデータが含まれる。このメソッド７００はこれで終了する。
【００７３】
図８はハートビートミラーを停止するメソッド８００を示すフローチャートである。本発明の一実施例では、ハートビートミラー停止エンジン３１０がこのメソッド８００を実行する。最初にハートビートミラーが停止される（８１０）。その後、ハートビートステータスデータ構造３４０のようなハートビートステータスデータ構造はハートビートミラーの停止状態を反映するように更新される（８２０）。
【００７４】
例えば、フィールド５１０、５４０及び５６０は使用不能状態に変更される。次に、セカンダリ（又は待機系）サイトのホスト１６０ｂのようなホストに停止されたことが知らされる（８３０）。この報告（８３０）の後、セカンダリサイトのハートビートステータスデータ構造は、ローカルハートビートステータスデータ構造の更新（８２０）と同様に更新される（８４０）。以上によりメソッド８００は終了する。
【００７５】
図９はサイトでの障害検出の為のメソッド９００のフローチャートである。一般的に言って、サイトでの障害検出の為のメソッド９００は下記の通り説明される：最初に、ローカルボリュームの状態をある時点でチェックし、この結果を基準状態と比較する。もし両者の間に相違があれば、リモートペアは“罹障している”と判断される。この基準状態は事前に設定することも出来る。他の方法として、どの種類の状態変更コマンドが使用されたかによって決めても良い。更に、この基準状態は特定時点の状態チェック前に取得された状態であっても良い。状態を変更することはメッセージを送信するメカニズムに似ており、状態をチェックすることは問い合わせメカニズムに似ている。どのメカニズムが“状態変更”を実行するか、如何なる頻度で“状態変更”を実行するか、及び如何なる種類の状態変更コマンドが使用されるかは、実装次第である。
【００７６】
本発明の一実施例においては、ハートビート送信エンジン３２０とハートビートチェックエンジン３３０が共同してメソッド９００を実行する。最初に、ハートビートミラー１７０ａのようなリモートハートビートミラーが使用可能かどうかを判定する（９１０）。この判定（９１０）は、ハートビートステータスデータ構造３４０のフィールド５１０をチェックすることにより実行される。もしこのリモートハートビートミラーが使用不能ならメソッド９００は終了する。使用可能なら、ボリューム１１１ａのような全てのローカルハートビートボリュームの状態がＰＶＯＬかＳＶＯＬかがチェックされる（９２０）。更に、ハートビートステータスデータ構造３４０はチェック結果に基づいて更新される（９２０）。
【００７７】
チェック（９２０）の終了後、全ての使用可能のローカルハートビートボリュームに対して、状態変更コマンドが発行される（９３０）。この状態変更コマンドは全てのローカル及びリモートハートビートボリュームの状態を変化させる。一実施例では、この状態変更コマンドはハートビートボリュームをＰＶＯＬからＳＶＯＬへ又はその逆に変化させる。本発明の他の実施例では、この状態変更コマンドはハートビートボリュームをミラー状態からミラー停止状態に又はその逆に変化させる。この状態変更コマンドの発行（９３０）後、メソッド９００はリモートホストが配下のローカルハートビートボリュームに対して状態変更コマンドを発行し終えるのを待つ（９４０）。この待ち時間は事前に設定しておくことが出来る。
【００７８】
この待ち時間（９４０）が終了すると、ローカルハートビートボリュームの状態は再度チェックされる（９５０）。その時のローカルハートビートボリュームの状態は、ハートビートステータスデータ構造３４０に記憶されている前回の状態と比較される（９６０）。二つの連続する状態変更コマンドが（一つはローカルに他はリモートに）発行された訳だから、ローカルハートビートボリュームの状態は元に戻っている必要がある。もし状態が変わったままなら、リモートサイトがハートビートボリュームの状態を元に戻す状態変更コマンドを発行しなかった為で、リモートサイトに障害が発生していることを意味する。もし状態が戻っておれば、次の状態変更コマンドが発行され（９３０）、メソッド９００は繰り返される。もし状態が変わったままなら、フェイルオーバ処理が開始され（９７０）、待機系サイトが障害を見つけた場合は、例えばホスト１００ｂがプライマリホストになりアプリケーション１０３ａを走行する。本発明の他の実施例として、フェイルオーバ処理（９７０）の開始に加えて、又はこれに替えて、メソッド９００はシステムオペレータに障害の発生を音声又は可視メッセージにより通告し、又は、更に障害発生を確認する為に第二の障害検出を実行することも出来る。
【００７９】
本発明の他の実施例として、状態が違っていた場合、メソッド９００は事前設定された時間だけ待って、状態チェック（９５０）と比較（９６０）を繰り返す方法もある。それでも不一致が残れば、フェイルオーバ処理が開始される（９７０）。そうでなければ、状態変更コマンドが発行され（９３０）、メソッド９００は繰り返される。
【００８０】
図１０は本発明の実施例に従うシステム５０ｂのブロックダイアグラムである。システム５０ｂは殆どシステム５０ａと同じである。然しながら、システム５０ｂは、冗長目的に、第二のハートビートミラーを使用可能にしている。もし、第一のミラーペアが障害になっても、第二の ハートビートミラーを使用して、障害検出を続けることが出来る。
【００８１】
これ迄図解によって本発明の実施例を説明してきたが、これは単に例示の為であって、これ迄の開示により、これ迄の実施例、方法に対して多様な変更、修正が可能である。例えば、状態変更コマンドはＰＶＯＬ、ＳＶＯＬ間の遷移に加えて、ハートビートボリュームのミラー状態、ミラー停止状態の遷移に変えることも出来る。更に、本発明を実施するコンポーネントも、プログラム式汎用デジタルコンピュータを用いても実現できるし、このアプリケーションに特化した集積回路を用いても良いし、更に慣用的コンポーネント及び回路をネットワークで結合して用いても良い。結合は、有線、無線、モデム等を使用しても良い。ここに記述された実施例は、これに尽きるものでもなく、又限定されるものでもない。本発明は、以下に続く請求項によってのみ限定される。
【００８２】
【発明の効果】
従って、このシステムと方法により、クラスターシステムのサイトでの障害検出方法が改善され大きな利益がもたらされる。
【００８３】
【図面の簡単な説明】
【図１】図１は本発明の一実施例に従ったシステムを説明するブロックダイアグラムである。
【図２】図２は本発明に従った例示コンピュータを説明するブロックダイアグラムである。
【図３】図３は図１に示すシステムでのホストにおけるハートビートチェックシステムを説明するブロックダイアグラムである。
【図４】図４は本発明の一実施例に従い、ハートビートボリュームに状態変更コマンドを発行し、その状態をチェックする為のシーケンスを説明する図である
【図５】図５はハートビートステータスデータ構造を説明する図である。
【図６】図６はハートビート状態遷移データ構造を説明する図である。
【図７】図７はハートビートミラーの生成方法を説明するフローチャートである。
【図８】図８はハートビートミラーの停止方法を説明するフローチャートである。
【図９】図９はサイトでの障害検出方法を説明するフローチャートである。
【図１０】図１０は本発明の一実施例に従ったシステムを説明するブロックダイアグラムである。
【００８４】
【符号の説明】
１００ａ・１００ｂ・１６０ａ、１６０ｂ・・・ホスト、１０１・・・ハートビートチェック、１０２・・・ＯＳ、１０３・・・アプリケーション、１０４・・・クラスタリングプログラム、１１０ａ ・・・稼動系サイトストレージシステム、１１０ｂ待機系サイトストレージシステム、１１１・・・ハートビート（ＰＶＯＬ、ＳＶＯＬ、ＳＭＰＬ）、１１２・・・ユーザ用ＰＶＯＬ、ＳＶＯＬ、２０５・・・ＣＰＵ、２１０・・・稼動メモリ、２２０・・・永続メモリ、２３０・・・Ｉ／Ｏ、２４０・・・表示装置、２５０・・・入力装置、３００・・・ハートビートミラー生成エンジン、３１０・・・ハートビートミラー停止エンジン、３２０・・・ハートビート送信エンジン、３３０・・・ハートビートチェックエンジン、３４０・・・ハートビートステータスデータ構造、３５０・・・ハートビート状態遷移データ構造
【発明の属する技術分野】
本発明は、一般的にクラスターシステムに関係し、特に、但しこれに限定はしないが、クラスタリングシステムのサイトでの障害通知の為のシステム及び方法を提供する。
【０００２】
【従来の技術】
“クラスタリング”は、複数のコンピュータ（またはホストサ−バ）を結合して、結合された複数のコンピュータをあたかも単一のコンピュータのように動かすことが出来る公知の技術である。クラスタリングは、並列処理、負荷バランス、及び障害回避の為に使用されている。計算集中型のタスク及びリスクを分散させるために、各事業体ではしばしばサーバを集めてクラスターにしている。仮に、クラスターコンピューティングシステム内の一つのサーバが罹障した場合でも、オペレーティングシステムが被害プロセスをクラスターコンピューティングシステム内の生存サーバに移すことにより、エンドユーザは障害サーバが回復される迄の間も業務を継続することが出来る。
【０００３】
クラスターコンピューティングシステムは、アプリケーションのオペレーション中断を防止する為に、次第に普及してきている。或るクラスターコンピューティングシステムは、二つのホスト（例えば、サーバ）グループを持ち、一つのホストグループが稼動系システムを担当し、他のホストグループが待機系システムとして動作する。一つのホストグループは、他のホストグループから地理的に離れて（例えば数百マイルの規模で）分散配置されることが普通である。
【０００４】
各ホストグループは、自らに連携したストレージシステム（例えば、ディスクシステム）を有する。これら二つのストレージシステムは、以下に議論されるリモートミラーリング技術を実装していることが普通である。従って、待機系ホストグループに接続され、連携しているストレージシステムは、稼動系ホストグループに接続され、連携しているストレージシステムと同一のデータを保持している。
【０００５】
この二つのホストサーバグループを接続するネットワークは、典型的にはインターネットのようなＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ：広域ネットワーク）である。二つのホストサーバグループは、このネットワークを介して交信して、エラーチェック等を行うことが出来る。しかしながら、ＷＡＮは、しばしば障害になるので、一般的には信頼性の高いものではない。
【０００６】
インターネットを通したデータ転送は、遅延を蒙り、時にはデータを損失してしまうこともある。従って、待機系ホストグループは、ネットワーク上の問題（例えばリンク障害、データ転送遅れ等）を、誤って稼動系ホストグループの障害と見なしてしまい、（稼動系ホストグループには何も障害がない場合でも、）稼動系ホストグループのプロセスを誤って横取りしてしまうことがあり得る。
【０００７】
稼動系システムのホストグループは、この稼動系システムのホストグループに連携しているストレージシステム内の通常ＰＶＯＬ（Ｐｒｉｍａｒｙ Ｖｏｌｕｍｅ：プライマリボリューム）と言われるストレージボリュームにアクセスできる。
【０００８】
同様に、待機系システムのホストグループは、この待機系システムのホストグループに連携しているストレージシステム内の通常ＳＶＯＬ（Ｓｅｃｏｎｄａｒｙ Ｖｏｌｕｍｅ：セカンダリボリューム） と言われるストレージボリュームにアクセスできる。プライマリボリューム（ＰＶＯＬ）は、セカンダリボリューム（ＳＶＯＬ）によってミラーされる。一つのストレージシステムがＰＶＯＬ、ＳＶＯＬの双方を持つことも出来る。
【０００９】
ストレージベースのリモートミラーリング技術では、所定の距離を離れて維持されている複数のストレージボリューム間にデータのミラーボリュームを生成し、蓄えておく。
【００１０】
この二つのディスクシステムは、ＥＳＣＯＮ（Ｅｎｔｅｒｐｒｉｓｅ Ｓｙｓｔｅｍ Ｃｏｎｎｅｃｔｉｖｉｔｙ：エンタープライズシステム接続）アーキテクチュア、ファイバチャネル、通信回線、のようなリモートリンク、又はこれらのリモートリンクの組み合わせを経由して直接接続される。ローカルディスクシステム内のデータは、リモートリンクを通して、リモートディスクシステムに転送され、コピーされる。 これらのリモートリンクは一般に、インターネットのような通常のネットワークに比べて、高度の信頼性がある。もし、リモートリンクの信頼性が低く障害になると、データ損失という大変大きな損失が発生する。
【００１１】
米国特許番号５，４５９，８５７及び５，５４４，３４７にリモートミラーリング技術が開示されている。これらの特許文献では、互いにある距離離れて、リモートリンクで結合された二つのディスクシステムが開示されている。ミラーされたデータは、ローカルディスクシステム及びリモートディスクシステムの双方のディスクに格納されている。ローカルディスクシステムは、ペアの生成が必要になると、ローカルディスク内のデータをコピーする。ホストサーバが当該ディスク内のデ−タを更新すると、このローカルディスクシステムは、当該更新データをリモートリンクを通してリモートディスクシステムに転送する。かくして、一つのディスクシステムのミラーデータイメージを他のディスクシステムに維持する為には、ホスト操作は必要とされない。
【００１２】
米国特許番号５，９３３，６５３では、ローカルディスクシステムとリモートディスクシステム間の別のタイプのデータ転送方法を開示している。同期モードでは、ローカルディスクシステムは、リモートディスクシステムへのデータの転送を完了してから、ホストからの書き込み要求を完了する。準同期モードでは、ローカルディスクシステムは、リモートディスクシステムへの書き込みデータの転送を完了する前にホストからの書き込み要求を完了する。その後のホストからの書き込み要求は、ローカルディスクシステムが前のデータをリモートディスクシステムに転送を完了する迄は実行されない。
【００１３】
適応型コピーモードでは、リモートディスクシステムへ転送すべきデータは、一時的にメモリ内に保存されており、ローカルディスクシステムおよび／またはリモートリンクが、コピータスクを実行できる状態になったときにリモートディスクシステムに転送される。
【００１４】
【発明が解決しようとする課題】
以上に述べた慣用的方法とシステムが有する欠陥を克服する為のシステムと方法が必要である。更に又、クラスターコンピューティングシステムの信頼性を向上させ、これらコンピューティングシステムでの障害検出精度を向上させるシステムと方法が必要である。更に又、クラスターシステムでの稼動系ホストグループが罹障していないにもかかわらず待機系ホストグループが稼動系ホストグループからプロセスを誤って横取りしないように、クラスターシステムの稼動系ホストグループの障害を正確に検出する為のシステムと方法が必要である。
【００１５】
【課題を解決するための手段】
本発明は、第一のホストと第二のホストとをネットワークを介して接続し、第一のホストと第二のホストから交互に状態変更コマンドを発行するに際して、各ホストは、状態変更コマンドを発行したときに、自己が管理するローカルボリュームの状態を遷移させるとともに、相手のホストに対して、相手のホストが管理するローカルボリュームの状態遷移を指示し、自己が状態変更コマンドを発行する前と相手のホストが状態変更コマンドを発行した後に、それぞれ自己が管理するローカルボリュームの状態を取得し、自己が状態変更コマンドを発行する前に取得した、ローカルボリュームの状態と、相手のホストが状態変更コマンドを発行した後に取得した、ローカルボリュームの状態とを比較して、両者が異なるときには、相手のホストで障害が発生したことを検出することを特徴とするものである。
【００１６】
本発明の一実施例では、この状態変更コマンドは、ローカルボリュームをプライマリボリューム状態とセカンダリボリューム状態の間で遷移させる機能を持つ。他の実施例では、この状態変更コマンドは、ローカルボリュームをミラー状態とミラー停止状態の間で遷移させる機能を持つ。
【００１７】
本発明の他の実施例では、この第二のエンジンはフェイルオーバプロセスを開始する前に第二の障害検出方法を開始することが出来る。更に本発明の他の実施例では、この第二のエンジンはシステムオペレータに障害発生を通知する機能を持つことが出来る。
【００１８】
本発明の方法は下記により構成される：第二のロケーションでミラーされているローカルボリュームの初回の状態チェックを行う；このローカルボリュームに状態変更コマンドを発行する；第二のロケーションのホストが次の状態変更コマンドを発行後、このローカルボリュームの二回目の状態チェックを行う；このローカルボリュームの状態の初回と二回目のチェック結果を比較する；もし、二回目のチェックでのローカルボリュームの状態が初回のチェック結果と違っていたら、フェイルオーバプロセスを開始する。
【００１９】
【発明の実施の形態】
本発明を以下の図面を参照しながら説明するが、本発明はこの説明に限定されるものではなく、又これに尽きるものでもない。特に断らない限り、全図面を通して同じ要素は、異なった見方をする場合も含めて、同じ参照番号で参照される。
【００２０】
以下の記述は通常のスキルを持った人が本発明を実施したり利用できるように、具体的な応用と要求に基づいて記述されている。この分野にスキルを持った人は、本発明の実施例に対する多様な改変が容易に可能であり、ここで述べられた原理は本発明の精神と範囲を離れる事無く、他の実施方法、応用に適用することが可能である。従って、本発明は以下に示された実施例に限定されることなく、以下に開示された原理、特徴、知識に整合できる範囲で最大限広く解釈される必要がある。
【００２１】
図１は本発明の一実施例に従うシステム５０ａのブロックダイアグラムである。システム５０ａは、プライマリグループ（稼動系ホストグループ）１３０ａ及びセカンダリグループ（待機系ホストグループ）１３０ｂとして示される二つのホストグループで構成される。セカンダリグループ１３０ｂはプライマリグループ１３０ａと実質的には同じでよい。
従って、プライマリグループ１３０ａに対する記述と構成要素は、セカンダリグループ１３０ｂに対しても適用可能である。プライマリグループ１３０ａは典型的に稼動系サイトに存在し、典型的に待機系サイトに存在するセカンダリグループ１３０ｂとは離れて設置される。プライマリグループ１３０ａには一つ以上のホスト１００ａ及び１６０ａが存在し、セカンダリグループ１３０ｂには一つ以上のホスト１００ｂ及び１６０ｂが存在する。これらのホストは典型的にサーバである。
【００２２】
各ホスト１００ａ及び１６０ａは、アプリケーション１０３ａ、クラスタリングプログラム１０４ａ、ハートビートチェック１０１ａ、及びオペレーティングシステム１０２ａを有する。アプリケーション１０３ａ、クラスタリングプログラム１０４ａ、ハートビートチェック１０１ａ、及びオペレーティングシステム１０２ａは、ホスト１００ａ及び１６０ａ上で同期して又は独立して走行する。あるいは又、第一のホスト（例えば、ホスト１００ａ又は１６０ａ）がアプリケーション１０３ａ、クラスタリングプログラム１０４ａ、ハートビートチェック１０１ａ、及びオペレーティングシステム１０２ａを独立に走行させ、第二のホストは、第一のホストが罹障した場合に、これらのプログラムを引き継いで走行させることも出来る。
【００２３】
一つの実施例では、ハートビートチェック１０１ａはモジュール、ソフトウエアプログラム、ファームウエア、ハードウエアまたはこれらのコンポーネントの組合せ、又は他の適当なコンポ−ネントでよい。ハートビートチェック１０１ａはクラスターシステムのサイトでの障害検出を可能にするもので、図３に関連してさらに詳細に議論される。
【００２４】
クラスタリングプログラム１０４ａはホストグループ１３０ａと１３０ｂをクラスターコンピューティングシステムとして稼動させる、通常良く知られたプログラムである。ハートビートチェック１０１ａはクラスタリングプログラム１０４ａから独立したプログラムでも良いし、クラスタリングプログラム１０４ａに付加又は組み込まれて一つのプログラムになっていても良い。
【００２５】
オペレーティングシステム１０２ａはクラスタリングプログラム１０４ａとハートビートチェック１０１ａが使用する為のＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ：アプリケーションプログラムインターフェース）を提供する。例えば、オペレーティングシステム１０２ａはストレージボリュームに対して、“オープン”、“読み出し”、“書き込み”及び“クローズ”を行わせる。ハートビートチェック１０１ａは例えば、ハートビートメッセージの送信時にこれらのＡＰＩを利用する。（例えば、ボリュームへのポインタを得る為に“オ−プン（ｖｏｌ）”を、メッセージを書き込む為に“書き込み（メッセージ）” を、及びポインタを破棄する為に“クローズ（ｖｏｌ）”を使用する。）
【００２６】
各ホスト１００ａと１６０ａはユーザの指定に応じて、固有のアプリケーション１０３ａを有することが出来る。例えば、ホスト１００ａはオラクルデータベースを走行させ、ホスト１６０ａは給与支払い業務を走行させても良い。もしホスト１００ａが罹障したら、オラクルデータベースはホスト１６０ａに受け入れられる。この場合、ホスト１６０ａはオラクルデータベースと給与支払い業務双方を走行させることになる。
【００２７】
クラスターコンピューティングシステムで通常良く知られているように、典型的にはアプリケーション１０３ａは通常プライマリグループ１３０ａで走行し、アプリケーション１０３ｂはセカンダリグループ１３０ｂで待機モードになっている。（セカンダリグループ１３０ｂ内の）ハートビートチェック１０１ｂが、プライマリグループ１３０ａに障害が発生したと判断したときは、以下に議論されるように、アプリケーション１０３ａは待機系サイトのセカンダリグループ１３０ｂに“フェイルオーバ”される。言い換えれば、アプリケーション１０３ａが機能しなくなってセカンダリグループ１３０ｂに引き継いだときに、セカンダリグループ１３０ｂのアプリケーション１０３ｂがシステム５０ａの為に走行する。
【００２８】
図１のパス１２０ａは、ホスト１００ａ及び１６０ａとストレージシステム１１０ａとの間の標準プロトコルを用いたデータ転送に使用される。パス１２０ａの例としては、ＳＣＳＩ、ファイバチャネル、ＥＳＣＯＮ、又はイーサネットがあり、これらの標準プロトコルは各々、ＳＣＳＩ−３、ＦＣＰ、ＥＳＣＯＮ、又はＴＣＰ−ＩＰである。
【００２９】
又図１のパス１２０ｂは、ホスト１００ｂ及び１６０ｂとストレージシステム１１０ｂとの間の標準プロトコルを用いたデータ転送に使用される。ここでの標準プロトコルはパス１２０ａと同じであっても良いし、同じでなくても良い。
【００３０】
本発明では、プライマリグループ１３０ａ内の一つのホスト例えばホスト１００ａをマスタホストに選定し、更にセカンダリグループ１３０ｂ内の一つのホスト例えばホスト１００ｂをマスタホストに選定する。以下に述べられる通り、マスタホスト１００ａ及び１００ｂは、フェイルオーバを実行すべきかどうかを判定する為に、“状態変更”信号又はコマンド及び“状態チェック”信号又はコマンドをそれぞれのハートビートボリューム１１１ａ及び１１１ｂに発行する。プライマリグループ１３０ａ内のホスト１６０ａは、その時のマスタホスト１００ａが罹障しているか動作不能状態になっていると見なされると、新しいマスタホストになる事が出来る。同様に、セカンダリグループ１３０ｂ内のホスト１６０ｂは、その時のマスタホスト１００ｂが罹障しているか動作不能状態になっていると見なされると、新しいマスタホストになる事が出来る。
【００３１】
ホスト１００ａ及び１６０ａはネットワーク１４０を経由して、ホスト１００ｂ及び１６０ｂに結合している。かくして、プライマリグループ１３０ａ内の各ホスト１００ａ及び１６０ａはセカンダリグループ１３０ｂ内の各ホスト１００ｂ及び１６０ｂの何れとも交信可能である。典型的にはネットワーク１４０はＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ：ローカルエリアネットワーク）又はインターネットのようなＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ：広域ネットワーク）である。
【００３２】
プライマリグループ１３０ａは稼動系サイトのストレージシステム１１０ａに結合され、セカンダリグループ１３０ｂは待機系サイトのストレージシステム１１０ｂに結合されている。各ストレージシステム１１０ａ及び１１０ｂは、例えばディスクシステムを形成している。各ストレージシステム１１０ａ及び１１０ｂは二つ以上のディスクで構成されていても良い。各ストレージシステム１１０ａ及び１１０ｂは一つ以上のリモートリンク１５０によって相互に結合されており、このリンクを通してストレージシステム１１０ａと１１０ｂとはお互いに交信可能である。典型的には、このリモートリンク１５０は、ＥＳＣＯＮ、ファイバチャネル、及び通信回線又はこれらＥＳＣＯＮ、ファイバチャネル、及び通信回線を含む組合せであってよい。リモートリンク１５０は、一般的に、ネットワーク１４０に比べて、より安全、より高信頼、より高速の通信が可能である。
【００３３】
（ストレージシステム１１０ａ及び１１０ｂで構成される）ディスクシステムは、リモートデータミラーリングシステムを形成し、一つ以上のリモートミラー１１１を有する。各リモートミラー１１１はストレージシステム１１０ａ内のストレージボリューム（ハートビートボリューム）１１１ａ及びストレージシステム１１０ｂ内のストレージボリューム（ハートビートボリューム）１１１ｂで構成される。ハートビートチェック１０１ａ及び１０１ｂは交互に配下のボリューム１１１ａ及び１１１ｂに状態変更コマンドを発行する。状態変更には、ボリュームをプライマリ状態とセカンダリ状態（又はストレージ状態）の間で遷移させたり、ミラー状態とミラー停止状態の間で遷移させたりすることが含まれる。ハートビートチェック１０１ａが慣用の状態変更コマンドをハートビートボリューム１１１ａに発行すると、ストレージシステム１１０ａはハートビートボリューム１１１ａの状態をプライマリ状態からセカンダリ状態に切り替える。
【００３４】
これに伴って、ストレージシステム１１０ａは、リモートリンク１５０を経由して、ストレージシステム１１０ｂに、状態が変わったことを連絡して、ストレージシステム１１０ｂがハートビートボリューム１１１ｂの状態をセカンダリ状態とプライマリ状態の間で切り替える処理を行わせる。
【００３５】
ハートビートチェック１０１ａは、状態変更コマンドを発行する前にハートビートボリューム１１１ａの状態を慣用的技術により読み取り、更にハートビートチェック１０１ｂが次の状態変更コマンドを発行した後に再度読み取る。この結果この前後の状態の間で相違が存在したら、リモートリンク１５０、ボリューム１１１ｂ又はセカンダリグループ１３０ｂに障害があったと判断する。（ここでは、リンク１２０ａ、１２０ｂは安定なリンク（例、短距離ケーブル）とされ、リンク１２０ａ、１２０ｂでの障害は極めて稀であるとして、状態の相違の原因とはしない。）同様に、ハートビートチェック１０１ｂは、状態変更コマンドを発行する前にハートビートボリューム１１１ｂの状態を読み取り、更にハートビートチェック１０１ａが状態変更コマンドを発行した後に再度読み取る。
【００３６】
この結果この前後の状態の間で相違が存在したら、リモートリンク１５０、ボリューム１１１ａ又はプライマリグループ１３０ａに障害があったと判断し、フェイルオーバ処理を開始することが可能である。
【００３７】
リモートミラー１１１、ハートビートボリューム１１１ａ及び１１１ｂ及び（ハートビートボリューム１１１ａをハートビートボリューム１１１ｂに接続する）リモートリンク１５０の数は可変である。ハートビートボリューム１１１ａは幾つかの原因で障害になる可能性がある。従って、二つ以上のミラーペアを使用することはシステム５０ａの高信頼化の為に有益である。
【００３８】
（ストレージシステム１１０ａと１１０ｂで形成される）ディスクシステムは、更に、稼動用データを記憶する為に一つ以上のリモートミラー１１２を有する。各リモートミラー１１２はストレージシステム１１０ａ内のプライマリストレージボリューム（ユーザ用ＰＶＯＬ１１２ａ）及びストレージシステム１１０ｂ内のセカンダリストレージボリューム（ユーザ用ＳＶＯＬ１１２ｂ）を有する。一つの例として、ユーザ用ＰＶＯＬ１１２ａ又は１１２ｂは、オラクル社から提供されるデータベースのような、データベースである。ユーザ用ＰＶＯＬ１１２ａ又は１１２ｂは、ＷＷＷ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）又はテキストファイル等からのデータ記憶用ストレージボリュームとして使用されても良い。
【００３９】
アプリケーション１０３ａがユーザ用ＰＶＯＬ１１２ａ上のデータを更新すると、ストレージシステム１１０ａは、リモートリンク１５１を通して、ストレージシステム１１０ｂにデータを転送する慣用的リモートコピー技術を使用して、当該更新データをユーザ用ＳＶＯＬ１１２ｂに書き込む。交代用リンクとして、リモートリンク１５０が使用されても良い。ストレージシステム１１０ｂは転送されてきたデータを受け取り、ユーザ用ＳＶＯＬ１１２ｂに書き込む。ホスト１００ｂ又は１６０ｂは、（何れが予めマスタホストに指定されていようと、）セカンダリグループ１３０ｂへのフェイルオーバが実施された後に、記憶データの読み取りの為にユーザ用ＳＶＯＬ１１２ｂにアクセスする。
【００４０】
即ち、稼動系サイトで、プライマリグループ１３０ａが割り当てられたオペレーションやタスクの実行が出来ないような障害が発生した場合は、待機系サイトのセカンダリグループ１３０ｂのホスト１００ｂ又は１６０ｂがシステム５０ａの為のオペレーションやタスクを実行する。フェイルオーバの引き金となる障害の例としては、ホスト障害、ストレージシステム又はディスク障害、アプリケーション又はソフトウエア障害、ハードウエア障害、信号パス又は接続障害、又はホストグループ１３０ａがシステム５０ａの為のオペレーションやタスクの実行が出来なくなるような稼動系サイトでの他のタイプの障害が挙げられる。
【００４１】
図２は本発明に基づく例示コンピュータ２００を説明するブロックダイアグラムである。本発明の実施例では、ホスト１００ａ、１６０ａ、１００ｂ、及び１６０ｂはこの例示コンピュータ２００を含むか、このコンピュータの上に実装することができる。この例示コンピュータ２００はＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ：中央処理装置）２０５；稼動メモリ２１０；永続メモリ２２０；Ｉ／Ｏ（Ｉｎｐｕｔ／Ｏｕｔｐｕｔ：入／出力）インターフェース２３０；デイスプレイ２４０及び入力装置２５０を含み、これらは全てシステムバス２６０を通して互いに通信結合されている。ＣＰＵ２０５はインテルＰｅｎｔｉｕｍ（Ｒ）、モトローラＰｏｗｅｒＰＣ（Ｒ）等のマイクロプロセッサ又は永続メモリ２２０内のソフトウエアを実行できる他の如何なるタイプのプロセッサであっても良い。
【００４２】
稼動メモリ２１０はＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ：ランダムアクセスメモリ）又は他の如何なるタイプの読み出し／書き込み可能なメモリデバイス又はメモリデバイスの組合せであっても良い。永続メモリ２２０はハードディスクドライブ、ＲＯＭ（Ｒｅａｄ ｏｎｌｙ Ｍｅｍｏｒｙ：読み出し専用メモリ）又は例示コンピュータ２００がシャットオフされた後にもデータを保持できる如何なるタイプのメモリデバイス又はメモリデバイスの組合せであっても良い。Ｉ／Ｏインターフェース２３０はストレージシステム１１０ａのような他のデバイスと有線、無線を問わず通信結合されている。デイスプレイ２４０は陰極線管（ＣＲＴ）表示装置又は他のタイプの表示装置を含んでも良い。入力装置２５０は、キーボード、マウス、又はその他のデータ入力装置又はデータ入力装置の組合せを含んでも良い。
【００４３】
この分野に造詣のある人なら、この例示コンピュータ２００には追加のデバイス、例えば、ネットワーク結合、追加のメモリ、追加のプロセッサ、ＬＡＮ、及びハードウエアチャネル、インターネット又はイントラネットを通してデータ転送する為の入／出力ライン等があってもよいと認識するであろう。更に又、この分野に造詣のある人なら、プログラム及びデータはこの例示コンピュータ２００に別の方法で受信され、格納されても良いと認識するであろう。
【００４４】
図３はハートビートチェック１０１ａの構成を説明するブロックダイアグラムである。本発明の実施例では、ハートビートチェック１０１ｂは、ハートビートチェック１０１ａと実質的に同様である。ハートビートチェック１０１ａは、ハートビートミラー形成エンジン３００；ハートビートミラー停止エンジン３１０；ハービート送信エンジン３２０；ハートビートチェックエンジン３３０；ハートビートステータスデータ構造３４０；及びハートビート状態遷移データ構造３５０を含む。
【００４５】
ハートビートミラー形成エンジン３００は、サイトでの障害検出の為に使用できるように、ミラーボリュームをセットアップする。本発明の一実施例では、ハートビートミラー形成エンジン３００はデイスプレイ２４０上にユーザインタフェースを表示して、ユーザにハートビートボリューム１１１ａ及び１１１ｂのデバイスアドレスのようなハートビートボリュームデバイスアドレスを入力することが出来るようにする。更に加えて、ハートビートミラー形成エンジン３００は、（ハートビートボリュームがＰＶＯＬとＳＶＯＬ状態との間で頻繁に切り替わる為）ユーザに稼動用ボリュームをハートビートボリュームとして使用しないように警告を表示し、実際にユーザが稼動用ボリュームをハートビートボリュームに選んでいないことを確認することも出来る。この確認が終了すると、ハートビートミラー形成エンジン３００は、更に以下に議論されるように、ハートビートミラーを活性化し、ハートビートステータスデータ構造３４０を更新して、ミラーが使用可能になったことを知らせる。
【００４６】
加えて、ハートビートミラー形成エンジン３００は、ハートビートチェック１０１ｂと連携して、状態変更コマンドと状態チェックコマンドが、以下に議論されるように、的確に同期されるように手はずする。ハートビートミラー形成エンジン３００は、何時状態変更コマンドを発行し、何時ハートビートボリューム１１１ｂの状態チェックを実施するか、の計画をハートビートチェック１０１ｂに送信することにより、連携を実行出来る。別案として、ハートビートチェック１０１ａと１０１ｂにはこの計画を事前にセットしておくことも可能で、この場合は、ハートビートミラー形成エンジン３００は、ハートビートチェック１０１ｂについては現時刻を確かめるだけでよい。ハートビートミラー形成エンジン３００については、図７に関連して、更に詳しく議論される。
【００４７】
ハートビートミラー停止エンジン３１０はハートビートミラーを停止し、これに伴って、ハートビートステータスデータ構造３４０を更新する。ハートビートミラー停止エンジン３１０は図８に関連して、更に詳細に論じられる。
【００４８】
ハートビート送信エンジン３２０は、以下に述べられるように、状態変更コマンドをハートビートボリューム１１１ａに定期的に発行する。ハートビートチェックエンジン３３０は、リモートミラーペア１１１ａの状態を、ハートビートチェック１０１ａが状態変更コマンドを発行する時点以前と、ハートビートチェック１０１ｂが状態変更コマンドを発行する時点以後を含む、同期された間隔でチェックする。具体的には、ハートビートチェックエンジン３３０は、ハートビートボリューム１１１ａがプライマリ状態かセカンダリ状態かをチェックし、チェック結果を最新に取得した状態と比較する。もし、ハートビート１０１ｂが状態変更コマンドを発行したと想定される時点以降に当該状態が変化しておれば、ハートビートチェックエンジン３３０は、フェイルオーバ処理を実行する。
【００４９】
本発明の他の実施例として、ハートビートチェックエンジン３３０は、オペレータに表示装置を通して、障害発生の警告通知を行うことも出来る。更に本発明の他の実施例として、ハートビートチェックエンジン３３０は第二の障害検出方法を起動し、第二の方法でも、障害が検出されれば、フェイルオーバ処理を起動することも可能である。
【００５０】
ハートビートステータスデータ構造３４０は、更に図５に関して議論されるように、リモートハートビートミラーが使用可能か否かのデータを含む。更に、ハートビートステータスデータ構造３４０はリモートグループステータスに関するデータ、例えば、リモートグループ１３０ｂが罹障しているか否かのような、情報を保持する。
【００５１】
ハートビートステータスデータ構造３４０に含まれる他の情報には、ハートビートミラーに使用されるデバイス（例えばハートビートボリューム１１１ａ及び１１１ｂ）のアドレスとステータスが含まれる。
【００５２】
ハートビート状態遷移データ構造３５０は、ハートビートミラーペア内のハートビートボリューム１１１ａ及び１１１ｂのような、各ハートビートボリュームの状態データを格納する。各ボリュームに可能な状態としては、ＰＶＯＬ（プライマリボリューム）；ＳＶＯＬ（セカンダリボリューム）；ＳＭＰＬ（単独：未だペアされていない）；ミラー停止状態；及びミラー状態が含まれる。
【００５３】
図４は本発明の一実施例での、ハートビートボリューム１１１ａ及び１１１ｂに対して、状態変更コマンドを発行し、状態をチェックする為のシーケンスを説明する。ハートビートチェック１０１ａのハートビートミラー形成エンジン３００は、ハートビートチェック１０１ｂと協力して、状態変更と状態チェックの処理を適切なシーケンスで行えるようにする。本発明の一つの実施例では、ハートビートチェック１０１ａは、まず状態チェックを発行して、しかる後に（例えば、引き続いて、）状態変更コマンドを発行する。その後に、ハートビート１０１ｂが状態チェック及び状態変更コマンドを発行する。ハートビートチェック１０１ａは、状態チェックコマンドを発行してから状態変更コマンドを発行するシーケンスを繰り返す。
【００５４】
従って、ハートビートチェック１０１ａは、ボリューム１１１ａの状態が変化した否かによって、待機系サイトで障害が発生しているか否かを判定できる。更に、ハートビートチェック１０１ｂも、このシーケンスを繰り返し、ボリューム１１１ｂの状態が変化した否かによって、プライマリサイトで障害が発生しているか否かを判定できる。各シーケンスのステップは１分間隔で発生させても良く、又２分間隔で発生させても良い。この分野に造詣のある人には、このシーケンスで用いられる時間間隔を変えることにより、フェイルオーバ検出精度と速度のバランスを調整できることが理解されるであろう。
【００５５】
代わりの方法として、状態変更と状態チェックコマンドの起動を何かのイベントをベースにしたり、ユーザ指示にすることも出来る。更に又、もしハートビートチェック１０１ａと１０１ｂが対応可能なら、ハートビートチェック１０１ａと１０１ｂは互いに異なった時間間隔で状態変更コマンドを発行することもありえる。例えば、状態変更コマンドを、ハートビートチェック１０１ａが３０秒間隔で、ハートビートチェック１０１ｂが６０秒間隔で発行することも出来るがこれは誤った障害検出に繋がる。然しながら、ハートビートチェック１０１ａは１サイクル当たりに一つ（又はより以上）の障害変化テスト状態を受け入れ、単一の障害変化テスト状態をサイト障害と見なさない様にすることも可能である。
【００５６】
本発明のもう一つの実施例として、ハートビートチェック１０１ａは、ハートビートチェック１０１ｂがハートビートボリューム１１１ｂに状態変更コマンドを発行する予定の前と後の時点で、ハートビートボリューム１１１ａの状態をチェックする方法がある。もし状態変化がない（即ち、ハートビートボリューム１１１ａがＰＶＯＬからＳＶＯＬへと変化していない、又はその逆が起きていない）場合は、セカンダリグループ１３０ｂは罹障していると判断される。同様に、ハートビートチェック１０１ｂは、ハートビートチェック１０１ａがハートビートボリューム１１１ａに状態変更コマンドを発行する予定の前と後の時点で、ハートビートボリューム１１１ｂの状態をチェックすることも出来る。
【００５７】
もし状態が変化していない（即ち、ハートビートボリューム１１１ｂがＰＶＯＬ、ＳＶＯＬの間で変化していない）場合は、プライマリホストグループ１３０ａは罹障していると判断される。上記何れの実施例の場合も、他のサイトでの障害有無を判断するのに、ローカルな状態変化イベントは必要ないことに注目する必要がある。
【００５８】
例えば、ハートビートチェック１０１ａ中のハートビートチェックエンジン３３０は、ハートビート送信エンジン３２０に状態変更コマンドの発行を依頼する必要なしに状態変化を確かめ、システムのオペレーションに支障が無いことを確認することが出来るのである。
【００５９】
本発明の他の実施例においては、ハートビートチェック１０１ｂはハートビートボリューム１１１ｂをミラー状態とミラー停止状態の間で遷移させるべく、状態変更コマンドを発行することが出来る。例えば、ハートビートチェック１０１ｂは、同期コマンドを発行して、次いでハートビートボリューム１１１ｂの状態をチェックする。次に、ハートビートチェック１０１ｂは停止コマンドを発行して、結果をチェックする。次いでこのプロセスは繰り返され、ハートビートチェック１０１ａとの干渉は全く必要ない。
【００６０】
もし、各状態チェックの後に変化が発生しない場合は、稼動系サイトに障害があると判断され、フェイルオーバ処理が起動される。
【００６１】
本発明の更に他の実施例として、ハートビートチェック１０１ａと１０１ｂは共に、（ミラー状態とミラー停止状態の間での）状態変更コマンドと状態チェックコマンドを発行して、リモートサイトの障害を検出することが出来る。例えば、ハートビートチェック１０１ａは、ハートビートボリューム１１１ａの状態をチェックし、次いで、状態変更コマンド（例えば、ミラー停止コマンド）を発行する。ハートビートチェック１０１ｂは、ハートビートボリューム１１１ｂの状態をチェックして、停止状態にあることを確認することにより、障害が存在しないことを確認することが出来る。
【００６２】
もし状態が変化していない（例えばミラー状態のままの）場合は、障害があると判断され、ハートビートチェック１０１ｂはフェイルオーバ処理に入ることが出来る。もし状態が変わっていれば、その後ハートビートチェック１０１ｂは状態変更コマンド（例えば、同期コマンド）を発行し、ハートビートチェック１０１ａはハートビートボリューム１１１ａの状態をチェックして、いまやミラー状態になっていることを確認する。
【００６３】
もし、ミラー状態でない場合は、セカンダリサイトに障害があるとみなされる。このプロセスはその後も繰り返される。
【００６４】
加えて、これらの障害検出方法は、稼動系サイトにおける障害回復状態の判定にも適用できる。例として、稼動系サイトが障害になり、待機系サイトへのフェイルオーバ処理が完了しているとする。従って、待機系サイトが一時的な稼動系サイトとして、アプリケーション１０３ｂを走行させている。この状況においては、ハートビートチェック１０１ｂは、稼動系サイトの回復を確認する為に、上で述べた、単一ホストでのハートビートチェックを実行することが出来る。このケースでは、ハートビートチェック１０１ｂは、ハートビートボリューム１１１ｂに“再同期”（即ちミラー状態への復帰）コマンドを発行する度に状態をチェックする。この状態は、稼動系サイトで、ストレージシステム１１０ａ、リモートミラーリンク１５０、及びペアになっているハートビートボリューム１１１ａが回復する迄は、決して“ミラー状態”に変化することはない。一度、ハートビートボリューム１１１ｂがこの状態変更コマンドに応答して“ミラー状態”に変わったら、このことは、少なくともストレージシステム１１０ａ、リモートミラーリンク１５０、及びペアになっているハートビートボリューム１１１ａが稼動系サイトで機能を回復したことを示す。次に、待機系サイトと稼動系サイトの間で、データボリュームの再同期処理のような、事前の“フォールバック処理”を開始することが出来る。
【００６５】
図５は、ハートビートステータスデータ構造３４０を示す。ハートビートステータスデータ構造３４０は、フィールド５１０でリモートコピーハートビートが使用可能かどうかを示す。ハートビートステータスデータ構造３４０はフィールド５２０では、セカンダリグループ１３０ｂのようなリモートグループが生存しているか（即ち、障害がないか）を示す。ハートビートステータスデータ構造３４０はフィールド５３０、５５０、及び５７０では、ハートビートボリューム１１１ａのようなハートビートボリュームのデバイスアドレスデータを保持する。
【００６６】
ハートビートステータスデータ構造３４０はフィールド５４０、５６０、及び５８０では、ハートビートボリューム１１１ａのようなハートビートボリュームが使用可能か否かを示すデータを保持する。ハートビートミラー形成エンジン３００及びハートビートミラー停止エンジン３１０は、このハートビートステータスデータ構造３４０を更新して、リモートコピーハートビートが使用可能か否かを（フィールド５１０に）反映させ、（フィールド５３０、５５０、及び５７０の）デバイスアドレスを更新する。
【００６７】
ハートビートチェックエンジン３３０は、フィールド５２０を更新して、リモートグループが生存しているか否かを反映させる。フィールド５２０は、ハートビートミラー１１１を形成できるか否かをユーザに示す為に、ハートビートミラー形成エンジン３００によって使用される。
【００６８】
図６はハートビート状態遷移データ構造３５０を示す。各デバイスアドレスに対応して、ハートビートボリューム１１１ａのようなハートビートボリュームの状態を示すフィールドが存在する。これらの状態には、ＰＶＯＬ（プライマリボリューム）、ＳＶＯＬ（セカンダリボリューム）、単独（ミラーなし）、ミラー状態及びミラー停止状態が含まれる。ハートビートチェックエンジン３３０がフィールド６２０−６４０を更新し、デバイス状態を反映させる。ハートビートチェックエンジン３３０はフィールド６２０−６４０を使用し、ハートビートチェック１０１ｂがハートビートボリューム１１１ｂに状態変更コマンドを発行する前後に、ハートビートボリューム１１１ａの状態を比較する。
【００６９】
図７はハートビートミラーを形成するメソッド７００を示すフローチャ−トである。本発明の一実施例では、ハートビートミラー形成エンジン３００がメソッド７００を実行する。先ず最初に、ハートビートをモニタする為のミラーが生成される（７１０）。このミラーはハートビートボリューム１１１ａ及び１１１ｂのような二つのハートビートボリュームの間で形成される。これらのハートビートボリュームは、状態を定期的に変えてしまうので、（例えばアプリケーション１０３ａに用いられるデータを記憶するボリュームである）稼動用ボリュームとしては使用できない。
【００７０】
次にこのミラーはリモートリンク１５０のようなリモートリンクを通して、活性化される（７２０）。活性化（７２０）後、ハートビートステータスデータ構造３４０のようなハートビートステータスデータ構造は更新され（７３０）、ミラーが使用可能か；ローカルハートビートボリュームのデバイスアドレス；各ローカルハートビートボリュームが使用可能か；及びリモートグループが生存しているかが反映される。
【００７１】
データ更新（７３０）終了後、ホスト１６０ｂのようなセカンダリサイトのホストは、ハートビートが形成され、活性化されたことが知らされる（７４０）。加えて、ハートビートチェック１０１ｂが、ハートビートチェック１０１ａと共同して、状態変更コマンドを発行し、状態チェック処理を実行できるようにする為の共同作業情報がセカンダリサイトのホストに送信される。共同作業情報の例としては、コマンド発行の順序シーケンスと、コマンドを実行する時刻情報が含まれる。別の案として、ハートビートチェック１０１ｂは、順序シーケンスは事前設定情報として保有し、共同作業情報としては、時刻情報のみを含むようにしても良い。
【００７２】
セカンダリサイトのホストが報告を受けた（７４０）後に、当セカンダリサイトのハートビートステータスデータ構造は更新される（７５０）。本発明の一実施例では、ハートビートチェック１０１ｂ中のハートビートミラー形成エンジンがこの更新を実施する。この更新には、ミラー状態か否か；ローカルハートビートボリュームのデバイスアドレス；各ローカルハートビートボリュームの使用可能状態；及びリモートグループの生存状態；を示すデータが含まれる。このメソッド７００はこれで終了する。
【００７３】
図８はハートビートミラーを停止するメソッド８００を示すフローチャートである。本発明の一実施例では、ハートビートミラー停止エンジン３１０がこのメソッド８００を実行する。最初にハートビートミラーが停止される（８１０）。その後、ハートビートステータスデータ構造３４０のようなハートビートステータスデータ構造はハートビートミラーの停止状態を反映するように更新される（８２０）。
【００７４】
例えば、フィールド５１０、５４０及び５６０は使用不能状態に変更される。次に、セカンダリ（又は待機系）サイトのホスト１６０ｂのようなホストに停止されたことが知らされる（８３０）。この報告（８３０）の後、セカンダリサイトのハートビートステータスデータ構造は、ローカルハートビートステータスデータ構造の更新（８２０）と同様に更新される（８４０）。以上によりメソッド８００は終了する。
【００７５】
図９はサイトでの障害検出の為のメソッド９００のフローチャートである。一般的に言って、サイトでの障害検出の為のメソッド９００は下記の通り説明される：最初に、ローカルボリュームの状態をある時点でチェックし、この結果を基準状態と比較する。もし両者の間に相違があれば、リモートペアは“罹障している”と判断される。この基準状態は事前に設定することも出来る。他の方法として、どの種類の状態変更コマンドが使用されたかによって決めても良い。更に、この基準状態は特定時点の状態チェック前に取得された状態であっても良い。状態を変更することはメッセージを送信するメカニズムに似ており、状態をチェックすることは問い合わせメカニズムに似ている。どのメカニズムが“状態変更”を実行するか、如何なる頻度で“状態変更”を実行するか、及び如何なる種類の状態変更コマンドが使用されるかは、実装次第である。
【００７６】
本発明の一実施例においては、ハートビート送信エンジン３２０とハートビートチェックエンジン３３０が共同してメソッド９００を実行する。最初に、ハートビートミラー１７０ａのようなリモートハートビートミラーが使用可能かどうかを判定する（９１０）。この判定（９１０）は、ハートビートステータスデータ構造３４０のフィールド５１０をチェックすることにより実行される。もしこのリモートハートビートミラーが使用不能ならメソッド９００は終了する。使用可能なら、ボリューム１１１ａのような全てのローカルハートビートボリュームの状態がＰＶＯＬかＳＶＯＬかがチェックされる（９２０）。更に、ハートビートステータスデータ構造３４０はチェック結果に基づいて更新される（９２０）。
【００７７】
チェック（９２０）の終了後、全ての使用可能のローカルハートビートボリュームに対して、状態変更コマンドが発行される（９３０）。この状態変更コマンドは全てのローカル及びリモートハートビートボリュームの状態を変化させる。一実施例では、この状態変更コマンドはハートビートボリュームをＰＶＯＬからＳＶＯＬへ又はその逆に変化させる。本発明の他の実施例では、この状態変更コマンドはハートビートボリュームをミラー状態からミラー停止状態に又はその逆に変化させる。この状態変更コマンドの発行（９３０）後、メソッド９００はリモートホストが配下のローカルハートビートボリュームに対して状態変更コマンドを発行し終えるのを待つ（９４０）。この待ち時間は事前に設定しておくことが出来る。
【００７８】
この待ち時間（９４０）が終了すると、ローカルハートビートボリュームの状態は再度チェックされる（９５０）。その時のローカルハートビートボリュームの状態は、ハートビートステータスデータ構造３４０に記憶されている前回の状態と比較される（９６０）。二つの連続する状態変更コマンドが（一つはローカルに他はリモートに）発行された訳だから、ローカルハートビートボリュームの状態は元に戻っている必要がある。もし状態が変わったままなら、リモートサイトがハートビートボリュームの状態を元に戻す状態変更コマンドを発行しなかった為で、リモートサイトに障害が発生していることを意味する。もし状態が戻っておれば、次の状態変更コマンドが発行され（９３０）、メソッド９００は繰り返される。もし状態が変わったままなら、フェイルオーバ処理が開始され（９７０）、待機系サイトが障害を見つけた場合は、例えばホスト１００ｂがプライマリホストになりアプリケーション１０３ａを走行する。本発明の他の実施例として、フェイルオーバ処理（９７０）の開始に加えて、又はこれに替えて、メソッド９００はシステムオペレータに障害の発生を音声又は可視メッセージにより通告し、又は、更に障害発生を確認する為に第二の障害検出を実行することも出来る。
【００７９】
本発明の他の実施例として、状態が違っていた場合、メソッド９００は事前設定された時間だけ待って、状態チェック（９５０）と比較（９６０）を繰り返す方法もある。それでも不一致が残れば、フェイルオーバ処理が開始される（９７０）。そうでなければ、状態変更コマンドが発行され（９３０）、メソッド９００は繰り返される。
【００８０】
図１０は本発明の実施例に従うシステム５０ｂのブロックダイアグラムである。システム５０ｂは殆どシステム５０ａと同じである。然しながら、システム５０ｂは、冗長目的に、第二のハートビートミラーを使用可能にしている。もし、第一のミラーペアが障害になっても、第二の ハートビートミラーを使用して、障害検出を続けることが出来る。
【００８１】
これ迄図解によって本発明の実施例を説明してきたが、これは単に例示の為であって、これ迄の開示により、これ迄の実施例、方法に対して多様な変更、修正が可能である。例えば、状態変更コマンドはＰＶＯＬ、ＳＶＯＬ間の遷移に加えて、ハートビートボリュームのミラー状態、ミラー停止状態の遷移に変えることも出来る。更に、本発明を実施するコンポーネントも、プログラム式汎用デジタルコンピュータを用いても実現できるし、このアプリケーションに特化した集積回路を用いても良いし、更に慣用的コンポーネント及び回路をネットワークで結合して用いても良い。結合は、有線、無線、モデム等を使用しても良い。ここに記述された実施例は、これに尽きるものでもなく、又限定されるものでもない。本発明は、以下に続く請求項によってのみ限定される。
【００８２】
【発明の効果】
従って、このシステムと方法により、クラスターシステムのサイトでの障害検出方法が改善され大きな利益がもたらされる。
【００８３】
【図面の簡単な説明】
【図１】図１は本発明の一実施例に従ったシステムを説明するブロックダイアグラムである。
【図２】図２は本発明に従った例示コンピュータを説明するブロックダイアグラムである。
【図３】図３は図１に示すシステムでのホストにおけるハートビートチェックシステムを説明するブロックダイアグラムである。
【図４】図４は本発明の一実施例に従い、ハートビートボリュームに状態変更コマンドを発行し、その状態をチェックする為のシーケンスを説明する図である
【図５】図５はハートビートステータスデータ構造を説明する図である。
【図６】図６はハートビート状態遷移データ構造を説明する図である。
【図７】図７はハートビートミラーの生成方法を説明するフローチャートである。
【図８】図８はハートビートミラーの停止方法を説明するフローチャートである。
【図９】図９はサイトでの障害検出方法を説明するフローチャートである。
【図１０】図１０は本発明の一実施例に従ったシステムを説明するブロックダイアグラムである。
【００８４】
【符号の説明】
１００ａ・１００ｂ・１６０ａ、１６０ｂ・・・ホスト、１０１・・・ハートビートチェック、１０２・・・ＯＳ、１０３・・・アプリケーション、１０４・・・クラスタリングプログラム、１１０ａ ・・・稼動系サイトストレージシステム、１１０ｂ待機系サイトストレージシステム、１１１・・・ハートビート（ＰＶＯＬ、ＳＶＯＬ、ＳＭＰＬ）、１１２・・・ユーザ用ＰＶＯＬ、ＳＶＯＬ、２０５・・・ＣＰＵ、２１０・・・稼動メモリ、２２０・・・永続メモリ、２３０・・・Ｉ／Ｏ、２４０・・・表示装置、２５０・・・入力装置、３００・・・ハートビートミラー生成エンジン、３１０・・・ハートビートミラー停止エンジン、３２０・・・ハートビート送信エンジン、３３０・・・ハートビートチェックエンジン、３４０・・・ハートビートステータスデータ構造、３５０・・・ハートビート状態遷移データ構造
Claims (10)
- 第一のサイトに存在する第一のホストが、第二のサイトにおいてミラーリングされている第一のローカルボリュームの状態を一回目に取得するステップと、
前記第一のローカルボリュームの状態を一回目に取得した後、前記第一のホストが、第一の状態変更コマンドを発行するステップと、
前記第一の状態変更コマンドの発行を条件に、前記第一のホストが、前記第一のローカルボリュームの状態を遷移させるステップと、
前記第二のサイトに存在する第二のホストが、前記第一の状態変更コマンドの発行に応答して、前記第二のサイトに存在する第二のローカルボリュームの状態を遷移させるステップと、
前記第一の状態変更コマンドが発行された後、前記第二のホストが、前記第二のローカルボリュームの状態を一回目に取得するステップと、
前記第二のローカルボリュームの状態を一回目に取得した後、前記第二のホストが、第二の状態変更コマンドを発行するステップと、
前記第二の状態変更コマンドの発行を条件に、前記第二のホストが、前記第二のローカルボリュームの状態を遷移させるステップと、
前記第二の状態変更コマンドの発行に応答して、前記第一のホストが、前記第一のローカルボリュームの状態を遷移させるステップと、
前記第二の状態変更コマンドが発行された後、前記第一のホストが、前記第一のローカルボリュームの状態を二回目に取得するステップと、
前記第二のサイトでの障害発生の有無を判定するために、前記第一のホストが、前記一回目と二回目の前記第一のローカルボリュームの状態を比較するステップと、
前記一回目と二回目の前記第一のローカルボリュームの状態を比較した後、前記第一のホストが、第三の状態変更コマンドを発行するステップと、
前記第二のホストが、前記第三の状態変更コマンドの発行に応答して、前記第二のローカルボリュームの状態を遷移させるステップと、
前記第三の状態変更コマンドが発行された後、前記第二のホストが、前記第二のローカルボリュームの状態を二回目に取得するステップと、
前記第一のサイトでの障害発生の有無を判定するために、前記第二のホストが、前記一回目と二回目の前記第二のローカルボリュームの状態を比較するステップと、
を備えることを特徴とする方法。 - 前記第一のホストは、前記第一の状態変更コマンドの発行を条件に、あるいは前記第二の状態変更コマンドの発行に応答して、
プライマリボリューム状態とセカンダリボリューム状態との間で前記第一のローカルボリュームを遷移させ、
前記第二のホストは、前記第一の状態変更コマンドまたは前記第三の状態変更コマンドの発行に応答して、あるいは前記第二の状態変更コマンドの発行を条件に、
プライマリボリューム状態とセカンダリボリューム状態との間で前記第二のローカルボリュームを遷移させる
ことを特徴とする請求項１に記載の方法。 - 前記第一のホストは、前記第一の状態変更コマンドの発行を条件に、あるいは前記第二の状態変更コマンドの発行に応答して、
ミラーリング状態とミラーリング停止状態との間で前記第一のローカルボリュームを遷移させ、
前記第二のホストは、前記第一の状態変更コマンドまたは前記第三の状態変更コマンドの発行に応答して、あるいは前記第二の状態変更コマンドの発行を条件に、
ミラーリング状態とミラーリング停止状態との間で前記第二のローカルボリュームを遷移させる
ことを特徴とする請求項１に記載の方法。 - 更に、前記第一のホストが、その比較結果として、前記一回目と二回目の前記第一のローカルボリュームの状態が異なるとき、または前記第二のホストが、その比較結果として、前記一回目と二回目の前記第二のローカルボリュームの状態が異なるときに障害の発生をシステムオペレータに通知するステップ
を備えることを特徴とする請求項１乃至請求項３のうち何れか１項に記載の方法。 - 更に、前記第一のホストが、その比較結果として、前記一回目と二回目の前記第一のローカルボリュームの状態が異なるとき、または前記第二のホストが、その比較結果として、前記一回目と二回目の前記第二のローカルボリュームの状態が異なるときにフェイルオーバ処理を開始するステップ
を備えることを特徴とする請求項１乃至請求項４のうち何れか１項に記載の方法。 - 第一のサイトに存在する第一のホストと、前記第一のホストとネットワークを介して接続されて第二のサイトに存在する第二のホストと、
前記第一のサイトに存在する第一のローカルボリュームと、前記第一のローカルボリュームとリモートリンクを介して接続されて前記第二のサイトに存在する第二のローカルボリュームとを備え、
前記第一のホストは、
前記第一のローカルボリュームの状態を一回目に取得する手段と、
前記第一のローカルボリュームの状態を一回目に取得した後、第一の状態変更コマンドを発行する手段と、
前記第一の状態変更コマンドの発行を条件に、前記第一のローカルボリュームの状態を遷移させる手段を備え、
前記第二のホストは、
前記第一の状態変更コマンドの発行に応答して、前記第二のローカルボリュームの状態を遷移させる手段と、
前記第一の状態変更コマンドが発行された後、前記第二のローカルボリュームの状態を一回目に取得する手段と、
前記第二のローカルボリュームの状態を一回目に取得した後、第二の状態変更コマンドを発行する手段と、
前記第二の状態変更コマンドの発行を条件に、前記第二のローカルボリュームの状態を遷移させる手段を備え、
さらに、前記第一のホストは、
前記第二の状態変更コマンドの発行に応答して、前記第一のローカルボリュームの状態を遷移させる手段と、
前記第二の状態変更コマンドが発行された後、前記第一のローカルボリュームの状態を二回目に取得する手段と、
前記第二のサイトでの障害発生の有無を判定するために、前記一回目と二回目の前記第一のローカルボリュームの状態を比較する手段と、
前記一回目と二回目の前記第一のローカルボリュームの状態を比較した後、第三の状態変更コマンドを発行する手段を備え、
さらに、前記第二のホストは、
前記第三の状態変更コマンドの発行を条件に、前記第二のローカルボリュームの状態を遷移させる手段と、
前記第三の状態変更コマンドが発行された後、前記第二のローカルボリュームの状態を二回目に取得する手段と、
前記第一のサイトでの障害発生の有無を判定するために、前記一回目と二回目の前記第二のローカルボリュームの状態を比較する手段を、
を備えることを特徴とするシステム。 - 前記第一の状態変更コマンドの発行を条件に、前記第一のローカルボリュームの状態を遷移させる手段および前記第二の状態変更コマンドの発行に応答して、前記第一のローカルボリュームの状態を遷移させる手段は、
プライマリボリューム状態とセカンダリボリューム状態との間で前記第一のローカルボリュームを遷移させ、
前記第一の状態変更コマンドの発行に応答して、前記第二のローカルボリュームの状態を遷移させる手段と前記第二の状態変更コマンドの発行を条件に、前記第二のローカルボリュームの状態を遷移させる手段および前記第三の状態変更コマンドの発行を条件に、前記第二のローカルボリュームの状態を遷移させる手段は、
プライマリボリューム状態とセカンダリボリューム状態との間で前記第二のローカルボリュームを遷移させる
ことを特徴とする請求項６に記載の方法。 - 前記第一の状態変更コマンドの発行を条件に、前記第一のローカルボリュームの状態を遷移させる手段および前記第二の状態変更コマンドの発行に応答して、前記第一のローカルボリュームの状態を遷移させる手段は、
ミラーリング状態とミラーリング停止状態との間で前記第一のローカルボリュームを遷移させ、
前記第一の状態変更コマンドの発行に応答して、前記第二のローカルボリュームの状態を遷移させる手段と前記第二の状態変更コマンドの発行を条件に、前記第二のローカルボリュームの状態を遷移させる手段および前記第三の状態変更コマンドの発行を条件に、前記第二のローカルボリュームの状態を遷移させる手段は、
ミラーリング状態とミラーリング停止状態との間で前記第二のローカルボリュームを遷移させる
ことを特徴とする請求項６に記載の方法。 - 更に、前記第一のホストが、その比較結果として、前記一回目と二回目の前記第一のローカルボリュームの状態が異なるとき、または前記第二のホストが、その比較結果として、前記一回目と二回目の前記第二のローカルボリュームの状態が異なるときに障害の発生をシステムオペレータに通知する手段
を備えることを特徴とする請求項６乃至請求項８のうち何れか１項に記載の方法。 - 更に、前記第一のホストが、その比較結果として、前記一回目と二回目の前記第一のローカルボリュームの状態が異なるとき、または前記第二のホストが、その比較結果として、前記一回目と二回目の前記第二のローカルボリュームの状態が異なるときにフェイルオーバ処理を開始する手段
を備えることを特徴とする請求項６乃至請求項９のうち何れか１項に記載の方法。
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US10/273,048 US7076687B2 (en) | 2002-10-16 | 2002-10-16 | System and method for bi-directional failure detection of a site in a clustering system |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| JP2004252939A JP2004252939A (ja) | 2004-09-09 |
| JP2004252939A5 JP2004252939A5 (ja) | 2006-08-17 |
| JP4387707B2 true JP4387707B2 (ja) | 2009-12-24 |
Family
ID=32092721
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003191589A Expired - Lifetime JP4387707B2 (ja) | 2002-10-16 | 2003-07-04 | クラスタリングシステムのサイトでの双方向障害検出の為のシステム及び方法 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US7076687B2 (ja) |
| JP (1) | JP4387707B2 (ja) |
Families Citing this family (31)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6889309B1 (en) * | 2002-04-15 | 2005-05-03 | Emc Corporation | Method and apparatus for implementing an enterprise virtual storage system |
| AU2003268454B2 (en) | 2002-09-06 | 2009-04-02 | Metric Holdings Llc | Method and system for processing email during an unplanned outage |
| US7426652B2 (en) * | 2002-09-09 | 2008-09-16 | Messageone, Inc. | System and method for application monitoring and automatic disaster recovery for high-availability |
| JP4325843B2 (ja) * | 2002-12-20 | 2009-09-02 | 株式会社日立製作所 | 論理ボリュームコピー先性能調整方法及び装置 |
| WO2004086191A2 (en) * | 2003-03-20 | 2004-10-07 | Rosenfelt Michael I | Method and system for providing backup messages to wireless devices during outages |
| US7089383B2 (en) * | 2003-06-06 | 2006-08-08 | Hewlett-Packard Development Company, L.P. | State machine and system for data redundancy |
| US7475134B2 (en) * | 2003-10-14 | 2009-01-06 | International Business Machines Corporation | Remote activity monitoring |
| AU2004286660B2 (en) | 2003-10-27 | 2011-06-16 | Hitachi Vantara, LLC | Policy-based management of a redundant array of independent nodes |
| JP2005196467A (ja) * | 2004-01-07 | 2005-07-21 | Hitachi Ltd | ストレージシステム、ストレージシステムの制御方法、及びストレージ制御装置 |
| US7137042B2 (en) * | 2004-03-17 | 2006-11-14 | Hitachi, Ltd. | Heartbeat apparatus via remote mirroring link on multi-site and method of using same |
| JP4382602B2 (ja) * | 2004-04-23 | 2009-12-16 | 株式会社日立製作所 | リモートコピーシステム |
| JP4401895B2 (ja) * | 2004-08-09 | 2010-01-20 | 株式会社日立製作所 | 計算機システム、計算機及びそのプログラム。 |
| US9141481B1 (en) | 2010-08-06 | 2015-09-22 | Open Invention Network, Llc | System and method for reliable non-blocking messaging for multi-process application replication |
| US8589953B1 (en) | 2010-08-06 | 2013-11-19 | Open Invention Network, Llc | System and method for transparent consistent application-replication of multi-process multi-threaded applications |
| US8584145B1 (en) | 2010-08-06 | 2013-11-12 | Open Invention Network, Llc | System and method for dynamic transparent consistent application-replication of multi-process multi-threaded applications |
| US8281184B1 (en) | 2010-08-06 | 2012-10-02 | Open Invention Network Llc | System and method for reliable non-blocking messaging for multi-process application replication |
| US8621275B1 (en) | 2010-08-06 | 2013-12-31 | Open Invention Network, Llc | System and method for event-driven live migration of multi-process applications |
| US8301700B1 (en) | 2010-08-06 | 2012-10-30 | Open Invention Network Llc | System and method for event-driven live migration of multi-process applications |
| US9043640B1 (en) * | 2005-08-26 | 2015-05-26 | Open Invention Network, LLP | System and method for event-driven live migration of multi-process applications |
| US8615578B2 (en) * | 2005-10-07 | 2013-12-24 | Oracle International Corporation | Using a standby data storage system to detect the health of a cluster of data storage servers |
| JP4856467B2 (ja) * | 2006-05-01 | 2012-01-18 | 株式会社日立製作所 | ストレージ資源管理システム、ストレージ資源管理方法および管理計算機 |
| JP5142580B2 (ja) * | 2006-06-29 | 2013-02-13 | キヤノン株式会社 | 表面解析方法および表面解析装置 |
| US20090055689A1 (en) * | 2007-08-21 | 2009-02-26 | International Business Machines Corporation | Systems, methods, and computer products for coordinated disaster recovery |
| JP2009176284A (ja) * | 2007-12-25 | 2009-08-06 | Fuji Xerox Co Ltd | ファイル共有システム |
| US8370679B1 (en) * | 2008-06-30 | 2013-02-05 | Symantec Corporation | Method, apparatus and system for improving failover within a high availability disaster recovery environment |
| US9135127B1 (en) | 2010-08-06 | 2015-09-15 | Open Invention Network, Llc | System and method for dynamic transparent consistent application-replication of multi-process multi-threaded applications |
| WO2015098589A1 (ja) * | 2013-12-25 | 2015-07-02 | Ｎｅｃソリューションイノベータ株式会社 | クラスタシステム、サーバ装置、クラスタシステムの管理方法、及びコンピュータ読み取り可能な記録媒体 |
| US9361194B2 (en) * | 2014-03-20 | 2016-06-07 | Netapp Inc. | Mirror vote synchronization |
| US9836368B2 (en) | 2015-10-22 | 2017-12-05 | Netapp, Inc. | Implementing automatic switchover |
| US10203890B1 (en) * | 2016-09-20 | 2019-02-12 | Tintri Inc. | Multi-tier mechanism to achieve high availability in a multi-controller system |
| US11003369B1 (en) | 2019-01-14 | 2021-05-11 | Pure Storage, Inc. | Performing a tune-up procedure on a storage device during a boot process |
Family Cites Families (23)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5544347A (en) * | 1990-09-24 | 1996-08-06 | Emc Corporation | Data storage system controlled remote data mirroring with respectively maintained data indices |
| JP3087429B2 (ja) * | 1992-04-03 | 2000-09-11 | 株式会社日立製作所 | 記憶装置システム |
| US5459857A (en) * | 1992-05-15 | 1995-10-17 | Storage Technology Corporation | Fault tolerant disk array data storage subsystem |
| JPH0713905A (ja) * | 1993-06-23 | 1995-01-17 | Hitachi Ltd | 記憶装置システム及びその制御方法 |
| DE69523124T2 (de) * | 1994-12-15 | 2002-05-29 | Hewlett-Packard Co. (N.D.Ges.D.Staates Delaware), Palo Alto | Fehlererkennungssystem für einen gespiegelten Speicher in einer duplizierten Steuerung eines Plattenspeicherungssystems |
| EP0721162A2 (en) * | 1995-01-06 | 1996-07-10 | Hewlett-Packard Company | Mirrored memory dual controller disk storage system |
| GB9601584D0 (en) * | 1996-01-26 | 1996-03-27 | Hewlett Packard Co | Fault-tolerant processing method |
| US6052797A (en) | 1996-05-28 | 2000-04-18 | Emc Corporation | Remotely mirrored data storage system with a count indicative of data consistency |
| US5933653A (en) * | 1996-05-31 | 1999-08-03 | Emc Corporation | Method and apparatus for mirroring data in a remote data storage system |
| US6363497B1 (en) * | 1997-05-13 | 2002-03-26 | Micron Technology, Inc. | System for clustering software applications |
| WO1998059291A1 (fr) | 1997-06-20 | 1998-12-30 | Hitachi, Ltd. | Procede de commande d'une unite de commande de memoire |
| US6163855A (en) * | 1998-04-17 | 2000-12-19 | Microsoft Corporation | Method and system for replicated and consistent modifications in a server cluster |
| US6247140B1 (en) * | 1998-07-07 | 2001-06-12 | International Business Machines Corporation | Parallel remote administration of mirrored and alternate volume groups in a distributed data processing system |
| US6053797A (en) * | 1998-07-17 | 2000-04-25 | Eastgate Innovations Incorporated | Interactive toy |
| WO2000007105A1 (fr) | 1998-07-27 | 2000-02-10 | Hitachi, Ltd. | Systeme informatique |
| EP0981091B1 (en) | 1998-08-20 | 2008-03-19 | Hitachi, Ltd. | Data copying in storage systems |
| US6785840B1 (en) * | 1999-08-31 | 2004-08-31 | Nortel Networks Limited | Call processor system and methods |
| US6658478B1 (en) * | 2000-08-04 | 2003-12-02 | 3Pardata, Inc. | Data storage system |
| US6847991B1 (en) * | 2000-09-06 | 2005-01-25 | Cisco Technology, Inc. | Data communication among processes of a network component |
| US6785678B2 (en) * | 2000-12-21 | 2004-08-31 | Emc Corporation | Method of improving the availability of a computer clustering system through the use of a network medium link state function |
| US7275100B2 (en) * | 2001-01-12 | 2007-09-25 | Hitachi, Ltd. | Failure notification method and system using remote mirroring for clustering systems |
| US20030005350A1 (en) * | 2001-06-29 | 2003-01-02 | Maarten Koning | Failover management system |
| JP2003076592A (ja) * | 2001-09-04 | 2003-03-14 | Hitachi Ltd | データ格納システム |
-
2002
- 2002-10-16 US US10/273,048 patent/US7076687B2/en not_active Expired - Fee Related
-
2003
- 2003-07-04 JP JP2003191589A patent/JP4387707B2/ja not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| JP2004252939A (ja) | 2004-09-09 |
| US7076687B2 (en) | 2006-07-11 |
| US20040078644A1 (en) | 2004-04-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4387707B2 (ja) | クラスタリングシステムのサイトでの双方向障害検出の為のシステム及び方法 | |
| US6907543B2 (en) | Data storage system | |
| US7734596B2 (en) | Automatic failover configuration with redundant abservers | |
| US8255369B2 (en) | Automatic failover configuration with lightweight observer | |
| US7627584B2 (en) | Database system configured for automatic failover with no data loss | |
| US8423515B2 (en) | Database system configured for automatic failover with user-limited data loss | |
| US7043665B2 (en) | Method, system, and program for handling a failover to a remote storage location | |
| US6601187B1 (en) | System for data replication using redundant pairs of storage controllers, fibre channel fabrics and links therebetween | |
| US6996691B2 (en) | Method for transaction command ordering in a remote data replication system | |
| US7603581B2 (en) | Remote copying of updates to primary and secondary storage locations subject to a copy relationship | |
| US7275100B2 (en) | Failure notification method and system using remote mirroring for clustering systems | |
| JP4892185B2 (ja) | 分散リモートコピーシステム | |
| US6643795B1 (en) | Controller-based bi-directional remote copy system with storage site failover capability | |
| JP4751117B2 (ja) | データ複製を利用したフェイルオーバとデータ移行 | |
| US7668879B2 (en) | Database system configured for automatic failover with no data loss | |
| US6658590B1 (en) | Controller-based transaction logging system for data recovery in a storage area network | |
| US20090019096A1 (en) | System and article of manufacture for mirroring data at storage locations | |
| US20040064639A1 (en) | Controller-based remote copy system with logical unit grouping | |
| US20040260970A1 (en) | Method, system, and program for mirroring data between sites | |
| JP2003099306A (ja) | 計算機システムおよび計算機システムにおけるバックアップ方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| RD01 | Notification of change of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7421 Effective date: 20060420 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060630 Free format text: JAPANESE INTERMEDIATE CODE: A821 Effective date: 20060630 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060630 |
|
| RD02 | Notification of acceptance of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7422 Effective date: 20060630 |
|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20071012 |
|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20090209 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20090406 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090528 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20090929 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20091001 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121009 Year of fee payment: 3 |