JP2004302512A - クラスタコンピューティングシステム、および、そのフェールオーバー方法 - Google Patents
クラスタコンピューティングシステム、および、そのフェールオーバー方法 Download PDFInfo
- Publication number
- JP2004302512A JP2004302512A JP2003091265A JP2003091265A JP2004302512A JP 2004302512 A JP2004302512 A JP 2004302512A JP 2003091265 A JP2003091265 A JP 2003091265A JP 2003091265 A JP2003091265 A JP 2003091265A JP 2004302512 A JP2004302512 A JP 2004302512A
- Authority
- JP
- Japan
- Prior art keywords
- wireless communication
- communication device
- site
- failure
- standby
- 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.)
- Pending
Links
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
-
- 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/202—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 processing functionality is redundant
- G06F11/2023—Failover techniques
- G06F11/2028—Failover techniques eliminating a faulty processor or activating a spare
-
- 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/202—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 processing functionality is redundant
- G06F11/2038—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 processing functionality is redundant with a single idle spare processing component
-
- 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/202—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 processing functionality is redundant
- G06F11/2048—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 processing functionality is redundant where the redundant components share neither address space nor persistent storage
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/40—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection
Abstract
【課題】稼動系システムと待機系システムを有するクラスタコンピューティングシステムにおいて、障害の態様によらず、各々のサイト間を接続するネットワークに障害があっても、矛盾なく両サイトを動作させて、障害回復をおこなうことのできるようにする。
【解決手段】稼動系システムと前記待機系システムは、それぞれ無線通信装置を設けて、稼動系システムと待機系システムの間を接続する有線のネットワークが全て、ネットワーク断状態になったときに、稼動系システムの無線通信装置は、稼動系システムの障害を前記待機系システムの無線通信装置との通信により報告する。報告は、稼動系システムの認証ＩＤを送り、待機系システムは、そのパケットを受信した段階で、稼動を開始する。
【選択図】 図１
【解決手段】稼動系システムと前記待機系システムは、それぞれ無線通信装置を設けて、稼動系システムと待機系システムの間を接続する有線のネットワークが全て、ネットワーク断状態になったときに、稼動系システムの無線通信装置は、稼動系システムの障害を前記待機系システムの無線通信装置との通信により報告する。報告は、稼動系システムの認証ＩＤを送り、待機系システムは、そのパケットを受信した段階で、稼動を開始する。
【選択図】 図１
Description
【０００１】
【発明の属する技術分野】
本発明は、クラスタコンピューティングシステム、および、そのフェールオーバー方法に係り、稼動系システムと待機系システムを有するデュプレクス−クラスタリングシステムにおいて、各々のサイト間を接続するネットワークに障害があっても、矛盾なく両サイトを動作させて、障害回復をおこなうことのできるクラスタコンピューティングシステム、および、そのフェールオーバー方法に関する。
【０００２】
【従来の技術】
クラスタコンピューティングシステムは、複数のサーバを一つのシステムと動作させて、システムの可用性、信頼性を向上させるシステムである。このようなクラスタコンピューティングシステムによって、障害が起こったときに、代替しているサーバがデータや処理を引き継ぐ機能を、フェールオーバーと言い、システムの信頼性を高めるために重要な技術になっている。
【０００３】
一般的に、クラスタコンピューティングシステムは、複数のホストコンピュータで、一つの共有する記憶装置システムか、各々別々にアクセス可能な記憶装置を有している。そして、デュプレクスシステムと呼ばれる構成では、この複数のホストコンピュータのうち一つは、稼働ホストコンピュータとして記憶装置システムに対しデータの読み書き等の稼働処理をおこない、それ以外のホストコンピュータは待機ホストコンピュータとして待機状態となっている。稼動ホストコンピュータおよび待機ホストコンピュータは、お互いに状態監視をおこなうことで、片方のホストコンピュータに障害が発生してもそれを検知し、稼動処理を引き継げるようになっている。このようなクラスタコンピューティングシステムとしては、特許文献１に示されるように、サイト間のリンクを選択的に使用して内部通信（ハートビート通信）をおこなう技術が開示されている。
【０００４】
以下、図１７ないし図２０を用いて一般的な従来技術の構成と動作について説明する。
図１７は、記憶装置システムをホストコンピュータ間で共有するクラスタコンピューティングシステムの一般的なシステム構成図である。
図１８は、図１７のシステムでホストコンピュータＡに障害がおこったことを説明する図である。
図１９は、サイト間で記憶装置システムを別個に持つクラスタコンピューティングシステムの一般的なシステム構成図である。
図２０は、図１９のシステムでサイトＡの記憶装置システムＡに障害がおこったことを説明する図である。
【０００５】
記憶装置システムをホストコンピュータ間で共有するクラスタコンピューティングシステムでは、図１７に示されるように、稼動系であるホストコンピュータＡ１０と、待機系であるホストコンピュータＢ１１とが記憶装置システム５１、５２にそれぞれインタフェースケーブルＡ４０、Ｂ４１とが接続され、Ｉ／Ｏ要求をおこなう構成になっている。
【０００６】
この稼動処理をおこなっているホストコンピュータＡ１０、待機状態となっているホストコンピュータＢ１１では、それらをつなぐＩＰネットワーク３０を介してハートビート通信をおこない、お互いの状態監視をおこなっている。
【０００７】
記憶装置システム５０が有する論理的なディスクボリューム（以下、「論理ディスクボリューム」）は、通常の稼動状態では、ホストコンピュータＡ１０がアクセスしている。
【０００８】
もし、図１８のようにホストコンピュータＡ１０に障害が起こったときには、待機系のホストコンピュータＢ１１は、ＩＰネットワーク３０により障害を検知して、稼動を始めて、ホストコンピュータＡ１０の処理を引き継ぎ、記憶装置システムにアクセスするようになる。
【０００９】
このような構成のクラスタコンピューティングシステムは、片方のホストコンピュータに障害が発生しても、稼動処理を維持できるようなシステムとなっている。
【００１０】
しかしながら、稼動処理に必要なデータが格納されている記憶装置システム自体に障害が発生した場合には、稼動処理を継続できない。
【００１１】
したがって、図１９のように稼動系と待機系で記憶装置システムを別々に持つ構成が考えられる。
【００１２】
図１９に示した構成のクラスタコンピューティングシステムでは、稼動系であるサイトＡ１００と待機系であるサイトＢ１０１は、各々、記憶装置システムＡ５１と記憶装置システムＢ５２を持っている。そして、記憶装置システム間で、常時、リモートコピーをおこなっている。リモートコピーとは、物理的に離れた場所にある複数の記憶装置システム同士が、ホストコンピュータを介さずにデータのコピー（二重書き）をおこなう技術である。
【００１３】
リモートコピーをおこなうときには、記憶装置システム同士は、専用回線あるいは公衆回線（図１９では、ＦＣ（Ｆｉｂｅｒ Ｃｈａｎｎｅｌ）ネットワーク４０）で互いに接続されており、稼動系のサイトＡ１００にある記憶装置システムＡ５１のコピー元論理ディスクボリュームが、待機系のサイトＢ１０１の記憶装置システムＢ５２に、コピー先論理ディスクボリュームとしてコピーされる。
【００１４】
このようにして、記憶装置システムＢ５２は、記憶装置システムＡ５１のバックアップ系として動作し、データの一貫性が保持されている。
【００１５】
ここで、図２０に示されるように、記憶装置システムＡ５１はに障害が起こったときには、ホストコンピュータＡ１０が障害を検知し、サイト間を結ぶＩＰネットワーク３０を介して、ホストコンピュータＢ１１に記憶装置システムＡ５１に障害が発生したことを報告する。
【００１６】
一方、サイトＢ１０１における記憶装置システムＢ５２も、ＦＣネットワーク９０を介して、リモートコピー元の記憶装置システムＡ５１に障害が発生したことを検知する。
【００１７】
このように、ホストコンピュータＢ１１は、ホストコンピュータＡ１０からの報告と、インタフェースケーブル１１１を介した記憶装置システムＢ５２の状態を確認すると、サイトＡ１００における記憶装置システムＡ５１に障害が発生したことを認識して、稼働処理を引き継ぐ動作をおこなう。
【００１８】
サイトＡ１００からサイトＢ１０１に稼働処理が引き継がれた後、サイトＡ１００における記憶装置システムＡ５１が復旧し、その記憶装置システムＡ５１が稼働処理を実行できる状態になった場合には、稼働処理を引き継いだホストコンピュータＢ１１が接続される記憶装置システムＢ５２をリモートコピー元として設定し、復旧した記憶装置システムＡ５１をリモートコピー先として再設定して、リモートコピーをおこなうことで、システム全体の稼働を停止することなく、記憶装置システムＡ５１にデータのリカバリーをおこなうことができる。
【００１９】
【特許文献１】
特開２００２−３１２１８９号公報
【００２０】
【発明が解決しようとする課題】
上記従来技術の図１９に示したサイト間で別々の記憶装置システムを持つ構成では、複数のホストコンピュータが記憶装置システムを共有してアクセスする図１５に示したシステムとは異なり、稼動系の記憶装置システム自体に障害が発生した場合でも、稼働処理を継続することができる。
【００２１】
ところで、クラスタコンピューティングシステムでは、ホストコンピュータ間における稼動処理の引き継ぎを可能にするため、常に相手の状態を監視し合う必要がある。図１９に示したシステムでは、ホストコンピュータ間を結ぶＩＰネットワークにおけるハートビート通信と、記憶装置システム間を結ぶＦＣネットワークにおけるリモートコピーを利用して、相手サイトの状態を確認し障害発生を認識する。したがって、障害発生の態様によっては、システムの障害回復がうまくおこなえない場合が生じる。
【００２２】
以下では、障害発生の態様によっては、システムの障害回復がうまくおこなえない場合について、図２１および図２２を用いて説明する。
図２１は、図１９の構成でＩＰネットワーク３０とＦＣネットワーク９０に障害がおこった場合を説明する図である。
図２２は、図１９の構成でサイトＡに障害がおこった場合を説明する図である。
【００２３】
障害発生の態様としては、図２１に示されるように、サイトＡ１００におけるホストコンピュータＡ１０、および、サイトＢ１０１におけるホストコンピュータＢ１１を結ぶＩＰネットワーク３０と、サイトＡ１００における記憶装置システムＡ５１およびサイトＢ１０１における記憶装置システムＢ５２を結ぶＦＣネットワーク９０とが両方とも断線した場合（以下、「サイト間ネットワーク全断」）がある。
【００２４】
このときには、サイト間で通信する手段が全くなくなってしまうために、相手のサイトの状態を監視することができなくなる。
【００２５】
また、別の障害の態様として、図２２に示されるように、例えば、サイトＡ１００におけるホストコンピュータＡ１０および記憶装置システムＡ５１が同時に障害となるなどによって、サイトＡ１００内のシステム全体の障害の場合（以下、「サイト障害」）がある。
【００２６】
このときに、サイトＢ１０１のホストコンピュータＢ１１から見ると、サイトＡ１００から情報を取得できないことは同じなので、図２１に示したサイト間ネットワーク全断の障害なのか、図２２に示したサイト障害なのか全く区別がつかないという問題点がある。
【００２７】
一般に、従来のクラスタコンピューティングシステムでは、サイト間ネットワーク全断が発生し、相手サイトの状態監視が不可能になると、相手サイトの情報を全く取得できなくなるため、ロジックによって次の三つの可能性がある。
（１）相手サイトの状態に関係なく、両サイトにおいて稼働処理を実行してしまう状態（スプリットブレイン状態）
（２）相手サイトの状態に関係なく、両サイトにおいて稼働処理を停止してしまう状態
（３）それまで稼働処理を実行していたサイトにおいてのみ、稼働処理を続行する状態
例えば、図２１に示したサイト間ネットワーク全断の障害により、（１）のスプリットブレイン状態になると、両サイトにおけるホストコンピュータは、自サイトの記憶装置システムにおける論理ディスクボリュームのデータを更新してしまうため、リモートコピー元とリモートコピー先で異なるデータが存在してしまう結果となる。
【００２８】
実際、図２１に示したサイト間ネットワーク全断の障害で、サイトＡ１００におけるホストコンピュータＡ１０は、サイトＢ１０１にサイト障害が発生したと判断し、稼動したままであり、サイトＢ１０１におけるホストコンピュータＢ１１も、サイトＡ１００にサイト障害が発生したと判断したとすると、（１）のスプリットブレイン状態になる。
【００２９】
したがって、図２１に示したサイト間ネットワーク全断の状態で、サイトＡ１００が稼動しているときには、サイトＢ１０１は、依然として待機していなければならないが、図２２のサイト障害状態と区別がつかないため、論理的な制御ができない。図２２の状態では、サイトＢ１０１は、障害を確認した場合には、稼動を開始しなければ、（２）の状態になってしまう。
【００３０】
このように、待機系であるサイトＢ１０１が、サイト間ネットワーク全断の障害か、サイト障害かの区別ができなければ、システム全体の信頼性が確保できないという問題点があった。
【００３１】
また、上記従来技術の特許文献１では、サイト間で複数の選択経路が用意されているので、通常のクラスタシステムよりも強固であり、信頼性が高いということができる。しかしながら、この特許文献１のシステムでも、通信状態が極端に悪いとき、サイト自体かその間の通信路の大規模火災などのリスクには対応できていない。
【００３２】
本発明は、上記問題点を解決するためになされたもので、その目的は、稼動系システムと待機系システムを有するクラスタコンピューティングシステムにおいて、障害の態様によらず、各々のサイト間を接続するネットワークに障害があっても、矛盾なく両サイトを動作させて、障害回復をおこなうことのできるクラスタコンピューティングシステムを提供することにある。
【００３３】
【課題を解決するための手段】
上記問題点は、複数のサイトを有するクラスタコンピューティングシステムにおいて、相手サイトの状態を確認するのに、ホストコンピュータ間のネットワークまたは、記憶装置システム間のネットワークによっていたことにより生じる。これらのネットワークの通信が途絶すると、相手サイトの状態を確認することが不可能となってしまうからである。
【００３４】
上記のＩＰネットワーク、ＦＣネットワークなどのサイト間ネットワークは、有線ケーブルにより、相手サイトの状態監視をおこなっていた。しかしながら、有線ケーブルを用いる場合、地震やケーブル火災等が原因で、それら全てが同時に断線してしまう（サイト間ネットワーク全断）可能性は否定できない。この有線ケーブルの断線は、クラスタコンピューティングシステムの特徴でもある災害対策（ディザスタリカバリ）の効果を著しく損なうことになる。
【００３５】
本発明では、別の有線による状態監視手段における欠点を補うために、無線通信装置による、相手サイトへの障害報告をおこなうことにした。
【００３６】
この構成によれば、障害が発生していない間には、従来のクラスタコンピューティングシステムと何ら変わらない動作をし、状態監視手段である有線ケーブルが断線し、通常のクラスタコンピューティングシステムでは適切な運用を維持できないときでも、無線通信により、相手サイト間と通信手段を確保することにより、信頼性を高めることができる。
【００３７】
すなわち、本発明では、断線する可能性が大きい有線ケーブルとは異なるインフラ（衛星通信、無線ＬＡＮ等）を用いることで、有線ケーブルとの同時故障を最小限に低くした無線通信装置による障害報告を、有線ケーブルによるサイト間の情報交換の代用とすることで、サイト間ネットワーク全断発生後も、相手サイトに障害情報を伝達できるシステムを実現することができる。したがって、上記で示した三つのロジックのいずれにおいても、クラスタコンピューティングシステムにおける適切な運用（障害発生時における稼働処理の引継ぎ等）を実現することが可能となる。
【００３８】
しかしながら、無線通信には、電波障害や、誤動作等による通信の不安定さが懸念事項に挙げられる。そこで、本発明において用いる無線通信は、従来のクラスタコンピューティングシステムにおける状態監視のように、常に相手サイトの状態を監視するような恒久的な接続ではなく、サイト間ネットワーク全断発生後の、稼働処理引継ぎ時においてのみ接続するるように限定し、無線通信における懸念事項を最小限に抑えた通信としている。
【００３９】
このように、本発明のシステムにおいて用いる無線通信装置による障害報告は、従来のサイト間ネットワークにおける状態監視のように、複雑なデータのやり取りや、恒久的な接続をする必要はなく、障害発生の報告を、障害発生時にのみおこなうだけに限定されるため、従来とは異なる構成の状態監視手段となる。
【００４０】
【発明の実施の形態】
以下、本発明に係る各実施形態を、図１ないし図１６を用いて説明する。
【００４１】
〔実施形態１〕
以下、本発明に係る第一の実施形態を図１ないし図１５を用いて説明する。
（Ｉ）クラスタコンピューティングシステムのシステム構成
先ず、図１ないし図４を用いて、本発明の第一の実施形態に係るクラスタコンピューティングシステムのシステム構成について説明する。
図１は、本発明の第一の実施形態に係るクラスタコンピューティングシステムのシステム構成図である。
図２は、ホストコンピュータＡの内部構成図である。
図３は、記憶装置システムＡの内部構成図である。
図４は、無線通信装置Ａの内部構成図である。
【００４２】
本実施形態のクラスタコンピューティングシステムは、図１に示されるように、稼動系システムであるサイトＡ１００と、待機系システムであるサイトＢ１０１からなっている。
【００４３】
そして、稼動系であるホストコンピュータＡ１０と、待機系であるホストコンピュータＢ１１とが記憶装置システム５１、５２にそれぞれインタフェースケーブルＡ４０、Ｂ４１とが接続され、Ｉ／Ｏ要求をおこなう構成になっていることは、従来技術と同様である。
【００４４】
また、稼動処理をおこなっているホストコンピュータＡ１０、待機状態となっているホストコンピュータＢ１１では、それらをつなぐＩＰネットワーク３０を介してハートビート通信をおこない、お互いの状態監視をおこなっていることも従来技術と同様である。
【００４５】
そして、リモートコピー機能を有することも、従来技術と同様であり、稼動系のサイトＡ１００にある記憶装置システムＡ５１のコピー元論理ディスクボリュームが、待機系のサイトＢ１０１の記憶装置システムＢ５２に、コピー先論理ディスクボリュームとしてコピーされる。
【００４６】
このとき、サイトＡ１００におけるホストコンピュータＡ１０は、稼働系システムのホストコンピュータとして、インタフェースケーブルＡ４０で接続されている記憶装置システムＡ５１に対して、読み書き等の稼働処理を実行している。また、サイトＢ１０１におけるホストコンピュータＢ１１は、待機ホストコンピュータとして待機状態となっている。
【００４７】
さらに、サイトＡ１００におけるホストコンピュータＡ１０には、インタフェースケーブルＡＲ１８０を介して、無線通信装置Ａ１６０が接続されており、サイトＢ１０１におけるホストコンピュータＢ１１には、インタフェースケーブルＢＲ１８１を介して、無線通信装置Ｂ１６１が接続されている。
【００４８】
これらの無線通信装置は、例えば、地震や火災、テロ等によってサイト障害が発生した場合でも、無線通信装置に障害が及ばないように、それぞれが、飛行機のボイスレコーダーを格納するブラックボックスのような障害に耐えうる容器に収められており、サイト障害発生後にも、相手サイトへの状態報告がおこなえるような構成となっている。
【００４９】
サイトＡ１００における無線通信装置Ａ１６０は、ホストコンピュータＡ１０からの指示、または、ホストコンピュータＡ１０が故障したという自己判断により、サイトＢ１０１における無線通信装置Ｂ１６１をコールしたり、コールが成功したかどうかをホストコンピュータＡ１０に報告したりする等の機能を持ち、インタフェースケーブルＡＲ１８０を介して、ホストコンピュータＡ１０の状態監視をおこなっている。これにより、無線通信装置Ａ１６０は、サイトＡ１００においてサイト障害が発生した場合でも、このインタフェースケーブルＡＲ１８０を介して障害を検知し、それまでサイトＡ１００でおこなっていた稼働処理を、サイトＢ１０１に引き継ぐように、無線通信装置Ｂ１６１に対してコールができるようになっている。一方、サイトＢ１０１における無線通信装置Ｂ１６１は、サイトＡ１００における無線通信装置Ａ１６０からのコールを受信したり、そのコールがあったか否かをホストコンピュータＢ１１へ報告する等の機能を持ち、無線通信装置Ａ１６０と同様に、インタフェースケーブルＢＲ１８１を介して、ホストコンピュータＢ１１の状態監視をおこなっている。
【００５０】
このように、本発明における無線通信装置は、ホストコンピュータからの命令によりコール開始する機能、ホストコンピュータの状態を監視し、その状態によって自発的にコールを開始する機能、コールの結果をホストコンピュータに報告する機能等、特有のプログラムを有し、本発明における独自の動作をおこなう装置である。
【００５１】
なお、無線通信路としては、衛星通信を使ってもよいし、無線ＬＡＮの機能を使ってもよい。また、携帯電話の通信路である公衆通信網を使ってもよい。
【００５２】
ホストコンピュータＡ１０は、図２に示されるように、ＣＰＵ１０ａ、メモリ１０ｂ、入力装置１０ｃ、表示装置１０ｄ、無線通信装置インタフェース１０ｅ、ＩＰインタフェース１０ｆを備えている。
【００５３】
無線通信装置インタフェース１０ｅは、無線通信装置Ａ１６０と通信するためのインターネットであり、ＩＰインタフェース１０ｆは、他のサイトと通信するためのインタフェースである。これらは、同一の通信インタフェースであってもよい。
【００５４】
また、記憶装置システムＡ５１は、コントローラ５１ａ、制御メモリ５１ｂ、キャッシュメモリ５１ｃ、ＦＣインタフェース５１ｄ、通常複数のディスク装置５１ｅ、５１ｆ、５１ｇ、…を備えている。
【００５５】
コントローラ５１ａは、この記憶装置システム５１の各部を制御する機能を有する。キャッシュメモリ５１ｃは、ディスク装置５１ｅ、…のアクセスを高速化させるためデータをキャッシュしておくためのメモリであり、制御メモリ５１ｂは、コントローラに用いられる制御用のデータをキャッシュするためのメモリである。 ＦＣインタフェース５１ｄは、ファイバチャネルにより他の記憶装置システムを接続する。
【００５６】
無線通信装置Ａ１６０は、図４に示されるように、コントローラ１６０ａ、メモリ１６０ｂ、送受信回路１６０ｃ、ホスト監視部１６０ｄ、ホストインタフェース１６０ｅを備えている。
【００５７】
コントローラ１６０ａは、無線通信装置Ａ１６０の内部を制御しており、ホストインタフェース１６０ｅを介してホストから送られてくるコマンドやホスト監視部１６０ｄからの報告を受け付けて、それを解釈して外部にコマンドを発行する。
【００５８】
ホスト監視部１６０ｄは、ホストインタフェース１６０ｅを介してホストを監視し、結果をコントローラ１６０ａに報告する。
【００５９】
送受信回路１６０ａは、通常の無線通信装置がおこなうようなベースバンド処理、搬送波処理、高周波処理をおこない、コントローラ１６０ａからのコマンドやデータを外部に送信したり、外部からのコマンドやデータを受信して、コントローラ１６０ａに伝える。
（ＩＩ）クラスタコンピューティングシステムの障害時の動作
次に、図５ないし図１３を用いて本実施形態のクラスタコンピューティングシステムの障害時の動作について説明する。
【００６０】
（ＩＩ−１）障害の態様と動作の概要
先ず、図５ないし図８を用いて本実施形態のクラスタコンピューティングシステムの障害の態様と動作の概要について説明する。
図５は、本発明のクラスタコンピューティングシステムで、サイト間ネットワーク全断がおこったときを説明する図である。
図６は、本発明のクラスタコンピューティングシステムで、サイト間ネットワーク全断と記憶装置システムの障害が同時におこったときを説明する図である。
図７は、本発明のクラスタコンピューティングシステムで、サイト障害がおこったときを説明する図である。
図８は、本発明のクラスタコンピューティングシステムで、サイト間ネットワーク全断とサイト障害が同時におこったときを説明する図である。
【００６１】
サイト間ネットワーク全断とは、図５に示される場合であり、既に説明したように、サイトＡ１００におけるホストコンピュータＡ１０、および、サイトＢ１０１におけるホストコンピュータＢ１１を結ぶＩＰネットワーク３０と、サイトＡ１００における記憶装置システムＡ５１およびサイトＢ１０１における記憶装置システムＢ５２を結ぶＦＣネットワーク９０とが両方とも断線した場合である。
【００６２】
この場合には、本発明のシステムでは、稼動系システムは、引き続き稼動を続け、待機系システムでは、引き続き待機を続けることになる。
【００６３】
そして、図６に示されるように、サイト間ネットワーク全断の状態で、記憶装置システム障害がおこったときには、無線通信装置Ａ１６０を介して、サイトＡ１００からサイトＢ１０１に連絡が行き、初めて待機系システムが稼動を開始することになる。
【００６４】
また、サイト障害とは、図７に示されるように、例えば、サイトＡ１００におけるホストコンピュータＡ１０および記憶装置システムＡ５１が同時に障害となるなどによって、サイトＡ１００内のシステム全体が障害となっている場合をいう。
【００６５】
この場合には、サイトＡ１００から無線通信装置Ａ１６０が、サイトＢ１０１に連絡して、待機系システムが稼動を開始することになる。
【００６６】
また、図８に示されているのは、ネットワーク全断とサイト障害が同時に、障害がおこった場合である。
【００６７】
この場合も、図７の場合と同様に、サイトＢ１０１に連絡して、待機系システムが稼動を開始することになる。
【００６８】
図７と図８の場合には、サイトＡ１００の無線通信装置Ａ１６０が、サイト障害が発生したことを検知して、サイトＡ１００から無線通信装置Ａ１６０が、サイトＢ１０１の無線通信装置Ｂ１６１に連絡して、待機系システムが稼動を開始することになる。
【００６９】
サイトＢ１０１の動作としては、図７と図８の場合もいずれも同じであり、サイトＡ１００からの情報が得られないため、無線通信装置Ｂ１６１が無線通信装置Ａ１６０のコールを待ち受ける。そして、サイトＡ１００に障害がおこったときに、障害報告を受け、ホストコンピュータＢ１１に稼動を開始するコマンドを発行して、稼動を開始させる。
【００７０】
（ＩＩ−２）サイトＡにおけるホストコンピュータＡのメイン動作
以下、図９のフローチャートを追いながらサイトＡにおけるホストコンピュータＡのメイン動作について説明する。
図９は、サイトＡにおけるホストコンピュータＡのメイン動作を説明するフローチャートである。
【００７１】
サイトＡ１００におけるホストコンピュータＡ１０は、稼動系システムのホストコンピュータとして稼動処理をおこなっており、ＩＰネットワーク３０およびＦＣネットワーク９０のサイト間ネットワークを利用して、サイトＢ１０１の状態監視をおこなっている。
【００７２】
この状態で、サイトＡ１００内のシステムに、サイトＡ１００におけるホストコンピュータＡ１０において稼動処理の続行が不可能な障害が発生した場合は、サイト間ネットワークにより情報が伝えられ、その稼動処理は、サイトＢ１０１におけるホストコンピュータＢ１１に引き継がれる。
【００７３】
このような一連の動作は、従来のクラスタコンピューティングシステムにおいておこなわれている動作であり、ここでは「通常クラスタ運用処理」（Ｓ６００）と呼ぶ。
【００７４】
ホストコンピュータＡ１０は、この通常クラスタ運用処理時に、サイト間ネットワーク全断が発生し、サイト間ネットワークを利用して、サイトＢ１０１における情報を取得することができなくなると（Ｓ６０１ Ｙｅｓ）、それまで稼働処理をおこなっていたサイトＡ１００におけるホストコンピュータＡ１０が、引き続き稼働処理をおこなう処理（以下、「稼働系優先運用処理」Ｓ６０２）に移る。
【００７５】
従来のクラスタコンピューティングシステムでは、サイト間ネットワーク全断が発生すると、両サイトにおけるホストコンピュータが、互いに相手サイトにサイト障害が発生したと判断し、それまで稼働処理をおこなっていたサイトが稼働処理を停止したり（この場合、両サイトにおいて稼働処理が停止した状態となる）、それまで待機状態となっていたサイトが稼働処理を引き継いでしまう（この場合、スプリットブレイン状態となる）等の問題点を生じていたが、本発明のシステムの場合には、サイト間ネットワーク全断が発生しても、稼動系システムでは、それまでおこなっていた動作を実行し続ける。そして、待機状態となっていたサイトは待機状態を維持することにする。
【００７６】
このような稼動系優先運用処理をおこなうのは、サイト間ネットワーク全断が発生しても、無線通信により情報を伝えることができるため、稼動系システムでは、引き続き処理をおこなって、待機系システムでは、稼動系システムから指示があったときに、初めて稼動処理を開始すればよいという考えに基づくものである。
【００７７】
そして、ホストコンピュータＡ１０が、この稼動側優先運用処理時に、インタフェースケーブルＡ４０により、記憶装置システムＡ５１に障害が発生したことを検知した場合（Ｓ６０３ Ｙｅｓ）、インタフェースケーブルＡ４０自体の障害によっ記憶装置システムＡ５１の情報取得ができないような場合には、それまでおこなっていた稼動処理は続行できないため、記憶装置システム障害対応処理（Ｓ３０００Ｈ）に移る。
【００７８】
（ＩＩ−３）サイトＡにおける無線通信装置Ａ１６０のメイン動作
以下、図１０のサイトＡにおける無線通信装置Ａ１６０のメイン動作について説明する。
図１０は、サイトＡにおける無線通信装置Ａ１６０のメイン動作について説明するフローチャートである。
【００７９】
サイトＡ１００における無線通信装置Ａ１６０は、図１で説明したように、ホストコンピュータＡ１０と、インタフェースケーブルＡＲ１８０で接続されている。
【００８０】
無線通信装置Ａ１６０は、通常、このコマンドを待機する状態（以下、「コマンド待機状態」）となっている（Ｓ７００）。また同時に、インタフェースケーブルＡＲ１８０を介して、ホストコンピュータＡ１０の状態監視もおこっており、インタフェースケーブルＡＲ１８０から取得するホストコンピュータＡ１０の情報を常に監視している。
【００８１】
無線通信装置Ａ１６０は、このコマンド待機時に、サイトＡ１００におけるホストコンピュータＡ１０から、インタフェースケーブルＡＲ１８０を介して後述するコール指示コマンドを受領（Ｓ７０２ Ｙｅｓ）すると、記憶装置システム障害対応処理（Ｓ３０００Ｒ）に移る。
【００８２】
また、無線通信装置Ａ１６０は、このコマンド待機状態のとき、サイトＡ１００におけるサイト障害により、インタフェースケーブルＡＲ１８０を介して、ホストコンピュータＡ１０の情報を取得できない場合（Ｓ７０１ Ｎｏ）、サイト障害対応処理（Ｓ５０００Ｒ）に移る。
【００８３】
（ＩＩ−４）サイトＢにおけるホストコンピュータＢのメイン動作
以下、図１１のフローチャートを追いながらサイトＢにおけるホストコンピュータＢのメイン動作について説明する。
図１１は、サイトＢにおけるホストコンピュータＢのメイン動作について説明するフローチャートである。
【００８４】
サイトＢ１０１におけるホストコンピュータＢ１１は、前述したように、待機系システムのホストコンピュータとして待機状態となっており、ＩＰネットワーク３０およびＦＣネットワーク９０のサイト間ネットワークを利用して、サイトＡ１００の状態監視をおこなっている。
【００８５】
この状態で、サイトＡ１００内のシステムに、サイトＡ１００において稼動処理が続行できないような障害が発生した場合には、サイトＢ１０１におけるホストコンピュータＢ１１がその稼動処理を引き継ぐことになり、このような従来のクラスタコンピューティングシステムにおける運用処理がおこなわれる（通常クラスタ運用処理）（Ｓ８００）。
【００８６】
ホストコンピュータＢ１１は、この通常クラスタ運用処理時に、サイト間ネットワーク全断が発生するか、サイトＡ１００にサイト障害がおこるかして、ＩＰネットワーク３０、および、ＦＣネットワーク９０を利用してサイトＡ１００の状態監視が不可能になると（Ｓ８０１ Ｙｅｓ）、サイトＡの情報取得不能処理（Ｓ４０００Ｈ）に移る。
【００８７】
（ＩＩ−５）サイトＢにおける無線通信装置Ｂのメイン動作
以下、図１２のフローチャートを追いながらサイトＢにおける無線通信装置Ｂのメイン動作について説明する。
図１２は、サイトＢにおける無線通信装置Ｂのメイン動作について説明するフローチャートである。
【００８８】
サイトＢ１０１における無線通信装置Ｂ１６１は、通常、コマンド待機状態となっている（Ｓ９００）。
【００８９】
無線通信装置Ｂ１６１は、このコマンド待機時に、ホストコンピュータＢ１１から待機指示コマンドを受領する（Ｓ９０１ Ｙｅｓ）と、サイトＡの情報取得不能処理（Ｓ４０００Ｒ）に移る。
【００９０】
（ＩＩ−６）サイトＡにおける記憶装置システム障害対応処理の動作
以下、図１３のフローチャートを追いながらサイトＡにおける記憶装置システム障害対応処理の動作について説明する。
図１３は、サイトＡにおいて、ホストコンピュータＡと無線通信装置Ａとの記憶装置システム障害対応処理の動作を並列して示したフローチャートである。
【００９１】
図６に示したように、サイト間ネットワーク全断が発生した後に、サイトＡ１００における記憶装置システムＡ５１に障害が発生したとする。
【００９２】
ホストコンピュータＡ１０の動作としては、Ｓ１０００において記憶装置システム障害対応処理フロー（Ｓ３０００Ｈ）へ移った場合である。
【００９３】
サイトＡ１００におけるホストコンピュータＡ１０は、インタフェースケーブルＡＲ１８０を介して、無線通信装置Ａ１６０に対し、コール指示コマンドを発行する。コール指示コマンドは、無線通信装置Ｂ１６１に対するコールを指示するコマンドである。
【００９４】
無線通信装置Ａ１６０は、コール指示コマンドを受領すると（Ｓ７０１、Ｓ１５０１）、サイトＢ１０１における無線通信装置Ｂ１６１へのコールを開始し、自己の証明として認証ＩＤを含むパケットも送出する（Ｓ１５０２）。
【００９５】
無線通信装置Ａ１６０は、無線通信装置Ｂ１６１へのコールを、無線通信装置Ｂ１６１につながるまで繰り返し（Ｓ１５０３ Ｎｏ）、一度でも無線通信装置Ｂ１６１につながると（Ｓ１５０３ Ｙｅｓ）、その接続はただちに切断される（Ｓ１５０４）。
【００９６】
これは、無線通信装置Ａ１６０における無線通信装置Ｂ１６１への接続が成功した段階で、それが稼動処理の引継ぎ要求が伝わったことにすることを意味する。
【００９７】
後に述べるように、サイトＢ１０１では、一度でも無線通信装置Ｂ１６１につながって、認証ＩＤを受信すると稼動処理を開始するので、この段階で、サイトＡ１００では、記憶装置システム障害対応処理を終えてよい。
【００９８】
（ＩＩ−７）サイトＢにおけるサイトＡの情報取得不能処理の動作
以下、図１４のフローチャートを追いながらサイトＢにおけるサイトＡの情報取得不能処理について説明する。
図１４は、サイトＢにおいて、ホストコンピュータＢと無線通信装置ＢとのサイトＢにおけるサイトＡの情報取得不能処理の動作を並列して示したフローチャートである
障害の態様としては、図５のネットワーク全断障害が起こるか、図７のサイト障害が起こるか、または、図８のようにその両方の障害が起こったとする。
【００９９】
ホストコンピュータＢの動作としては、Ｓ２０００においてサイトＡの情報取得不能処理（Ｓ４０００Ｈ）へ移った場合である。
【０１００】
サイトＢ１０１におけるホストコンピュータＢ１１は、無線通信装置Ｂ１６１に対して、待機指示コマンドを発行する（Ｓ１６００）。待機指示コマンドは、無線通信装置Ｂ１６１が無線通信装置Ａ１６０からのコールを待機するコマンドである。
【０１０１】
無線通信装置Ｂ１６１は、インタフェースケーブルＢＲ１８１を介して、ホストコンピュータＢ１１からの待機指示コマンドを受領し（Ｓ９０１、Ｓ１６０４）、無線通信装置Ａ１６０からのコールを待つ待機状態となる（Ｓ１６０５）。この待機状態は、無線通信装置Ｂ１６１が唯一外部からのコールを受け入れる状態であり、万が一、この待機状態時以外に、外部からコールがあった場合でも、無線通信装置Ｂ１６１はこれを無視し、その時の状態を維持することを意味する。このようにすることにより、誤動作などが防止できる。
【０１０２】
無線通信装置Ｂ１６１は、この待機状態時に、無線通信装置Ａ１６０からのコールがあると（Ｓ１６０６ Ｙｅｓ）、そのコールが無線通信装置Ａ１６０からのものであるか、認証ＩＤを用いて確認し（Ｓ１６０７）、無線通信装置Ａ１６０のコールであることを確認できたら、ホストコンピュータＢ１１に、インタフェースケーブルＢＲ１８１を介して、稼動処理開始指示コマンドを発行する（Ｓ１６０８）。稼動処理開始指示コマンドは、無線通信装置Ｂ１６１がホストコンピュータＢ１１に稼動を処理するコマンドである。
【０１０３】
この稼動処理開始コマンドを受領したホストコンピュータＢ１１は（Ｓ１６０２ Ｙｅｓ）、ここで初めて、サイトＡ１００において稼働処理を続行できない障害が発生したことを認識し、稼動処理を開始する（Ｓ１６０３）。このホストコンピュータＢ１１における稼動処理の開始は、サイトＡ１００におけるホストコンピュータＡ１０でおこなわれていた稼動処理が、サイトＢ１０１におけるホストコンピュータＢ１１に引き継がれたことを意味する。
【０１０４】
（ＩＩ−８）サイトＡにおけるサイト障害後の無線通信装置Ａの動作
図６に示すように、サイトＡ１００において、例えば地震や火災、テロ等によってサイトＡ１００内のシステム全てに障害が発生したようなサイト障害がおこったものとする。また、図８に示すように、サイト障害に加えて、ネットワーク全断障害がおこっている場合もあり得る。
【０１０５】
以下、図１５のフローチャートを追いながらサイトＡにおけるサイト障害後の無線通信装置Ａの動作について説明する。
図１５は、サイトＡにおけるサイト障害後の無線通信装置Ａの動作を示したフローチャートである。
【０１０６】
ただし、無線通信装置Ａ１６０には、ブラックボックスとして遮蔽されているため障害が及んでいないものとする。
【０１０７】
無線通信装置Ａ１６０の動作としては、Ｓ１０００において、サイト障害対応処理（Ｓ５０００Ｒ）へ移った場合である。
【０１０８】
サイトＡ１００における無線通信装置Ａ１６０は、インタフェースケーブルＡＲ１８０を介しての、ホストコンピュータＡ１０の状態監視が不可能となることから、サイトＡ１００において、サイト障害が発生したと判断し、無線通信装置Ｂ１６１へのコールを開始し、自己の証明として認証ＩＤを含むパケットも送出する（Ｓ１７００） 。
【０１０９】
無線通信装置Ａ１６０は、無線通信装置Ｂ１６１へのコールを、無線通信装置Ｂ１６１につながるまで繰り返し（Ｓ１７０１ Ｎｏ）、一度コールが受け付けられと（Ｓ１７０１ Ｙｅｓ）、その接続はただちに切断される（Ｓ１７０２）。無線通信装置Ａ１６０からの無線通信装置Ｂ１６１へのコールが一度でも受け付けられ、それが稼動処理の引継ぎを完了したものとする。
【０１１０】
以下のサイトＢ１０１におけるホストコンピュータＢ１１、および、無線通信装置Ｂ１６１における処理は、記憶装置システム障害対応処理（Ｓ３０００Ｈ、Ｓ３０００Ｒ）と同じである。
【０１１１】
サイトＢ１０１のホストコンピュータＢ１１は、ネットワーク全断の障害でも、サイト障害の場合でも、ＩＰネットワーク３０、および、ＦＣネットワーク９０を利用してサイトＡ１００の状態監視が不可能になるので（Ｓ８０１ Ｙｅｓ）、サイトＡの情報取得不能処理に移る（Ｓ４０００Ｈ）。
【０１１２】
そして、無線通信装置Ｂ１６１に待機指示コマンド発行を出し（Ｓ１６００）、無線通信装置Ｂ１６１は、無線通信装置Ａ１６０のコール待ちになる（Ｓ１６０５、Ｓ１６０６）。そして、無線通信装置Ｂ１６１がコールを受け、認証ＩＤを無線通信装置Ａ１６０から受信すると、無線通信装置Ｂ１６１は、ホストコンピュータＢ１１に稼動処理指示コマンドを出し（Ｓ１６０８）、ホストコンピュータＢ１１は、稼動を開始する（Ｓ１６０３）。
【０１１３】
〔実施形態２〕
以下、本発明に係る第二の実施形態を図１６を用いて説明する。
図１６は、本発明の第二の実施形態に係るクラスタコンピューティングシステムのシステム構成図である。
【０１１４】
第一の実施形態では、サイトＡとサイトＢが別々の記憶装置システムを持ち、リモートコピーをおこなっている場合であった。
【０１１５】
本実施形態では、サイトＡ１００とサイトＢ１０１が記憶装置システム５０を共用しているものとする。このシステム構成で、サイトＡ１００に障害がおこったときにも、同様に無線通信装置Ａ１６０が、無線通信装置Ｂ１６１に連絡させることにより、第一の実施形態と同様に、稼動系システムと待機系システムの連絡をおこなって障害回復の処理をおこなうことができる。
【０１１６】
【発明の効果】
以上のように、本発明では、リモートコピー機能を組み合わせた従来のクラスタコンピューティングシステムに、無線通信装置による相手サイトへの障害報告を導入することによって、サイト間ネットワーク全断発生後でも相手サイトの障害を認識することが可能となる。したがって、例えば、サイト間ネットワーク全断発生後、稼働処理をおこなっているサイトにおいて障害が発生しても、適切な判断で、もう片方のサイトが稼働処理を引き継ぐことができる。
【０１１７】
また、本発明は、従来のシステムにおける状態監視手段として用いる有線ケーブルを単に冗長化することによって、ディザスタリカバリの強化を図るものでなく、有線ケーブルとは異なるインフラを用いた無線通信による状態報告手段を加えることによって、その強化を図る発明である。
【０１１８】
このように、本発明によれば、稼動系システムと待機系システムを有するクラスタコンピューティングシステムにおいて、障害の態様によらず、各々のサイト間を接続するネットワークに障害があっても、矛盾なく両サイトを動作させて、障害回復をおこなうことのできるクラスタコンピューティングシステムを提供することができる。
【図面の簡単な説明】
【図１】本発明の第一の実施形態に係るクラスタコンピューティングシステムのシステム構成図である。
【図２】ホストコンピュータＡの内部構成図である。
【図３】記憶装置システムＡの内部構成図である。
【図４】無線通信装置Ａの内部構成図である。
【図５】本発明のクラスタコンピューティングシステムで、サイト間ネットワーク全断がおこったときを説明する図である。
【図６】本発明のクラスタコンピューティングシステムで、サイト間ネットワーク全断と記憶装置システムの障害が同時におこったときを説明する図である。
【図７】本発明のクラスタコンピューティングシステムで、サイト障害がおこったときを説明する図である。
【図８】本発明のクラスタコンピューティングシステムで、サイト間ネットワーク全断とサイト障害が同時におこったときを説明する図である。
【図９】サイトＡにおけるホストコンピュータＡのメイン動作を説明するフローチャートである。
【図１０】サイトＡにおける無線通信装置Ａ１６０のメイン動作について説明するフローチャートである。
【図１１】サイトＢにおけるホストコンピュータＢのメイン動作について説明するフローチャートである。
【図１２】サイトＢにおける無線通信装置Ｂのメイン動作について説明するフローチャートである。
【図１３】サイトＡにおいて、ホストコンピュータＡと無線通信装置Ａとの記憶装置システム障害対応処理の動作を並列して示したフローチャートである。
【図１４】サイトＢにおいて、ホストコンピュータＢと無線通信装置ＢとのサイトＢにおけるサイトＡの情報取得不能処理の動作を並列して示したフローチャートである
【図１５】サイトＡにおけるサイト障害後の無線通信装置Ａの動作を示したフローチャートである。
【図１６】本発明の第二の実施形態に係るクラスタコンピューティングシステムのシステム構成図である。
【図１７】記憶装置システムをホストコンピュータ間で共有するクラスタコンピューティングシステムの一般的なシステム構成図である。
【図１８】図１７のシステムでホストコンピュータＡに障害がおこったことを説明する図である。
【図１９】サイト間で記憶装置システムを別個に持つクラスタコンピューティングシステムの一般的なシステム構成図である。
【図２０】図１９のシステムでサイトＡの記憶装置システムＡに障害がおこったことを説明する図である。
【図２１】図１９の構成でＩＰネットワーク３０とＦＣネットワーク９０に障害がおこった場合を説明する図である。
【図２２】図１９の構成でサイトＡに障害がおこった場合を説明する図である。
【符号の説明】
１０…ホストコンピュータＡ
１１…ホストコンピュータＢ
２０…論理ディスクボリューム
２１…コピー元論理ディスクボリューム
２２…コピー先論理ディスクボリューム
３０…ＩＰネットワーク
４０…インタフェースケーブルＡ
４１…インタフェースケーブルＢ
５０…記憶装置システム
５１…記憶装置システムＡ
５２…記憶装置システムＢ
９０…ＦＣネットワーク
１００…サイトＡ
１０１…サイトＢ
１６０…無線通信装置Ａ
１６１…無線通信装置Ｂ
１７０…ブラックボックスＡ
１７１…ブラックボックスＢ
１８０…インタフェースケーブルＡＲ
１８１…インタフェースケーブルＢＲ
【発明の属する技術分野】
本発明は、クラスタコンピューティングシステム、および、そのフェールオーバー方法に係り、稼動系システムと待機系システムを有するデュプレクス−クラスタリングシステムにおいて、各々のサイト間を接続するネットワークに障害があっても、矛盾なく両サイトを動作させて、障害回復をおこなうことのできるクラスタコンピューティングシステム、および、そのフェールオーバー方法に関する。
【０００２】
【従来の技術】
クラスタコンピューティングシステムは、複数のサーバを一つのシステムと動作させて、システムの可用性、信頼性を向上させるシステムである。このようなクラスタコンピューティングシステムによって、障害が起こったときに、代替しているサーバがデータや処理を引き継ぐ機能を、フェールオーバーと言い、システムの信頼性を高めるために重要な技術になっている。
【０００３】
一般的に、クラスタコンピューティングシステムは、複数のホストコンピュータで、一つの共有する記憶装置システムか、各々別々にアクセス可能な記憶装置を有している。そして、デュプレクスシステムと呼ばれる構成では、この複数のホストコンピュータのうち一つは、稼働ホストコンピュータとして記憶装置システムに対しデータの読み書き等の稼働処理をおこない、それ以外のホストコンピュータは待機ホストコンピュータとして待機状態となっている。稼動ホストコンピュータおよび待機ホストコンピュータは、お互いに状態監視をおこなうことで、片方のホストコンピュータに障害が発生してもそれを検知し、稼動処理を引き継げるようになっている。このようなクラスタコンピューティングシステムとしては、特許文献１に示されるように、サイト間のリンクを選択的に使用して内部通信（ハートビート通信）をおこなう技術が開示されている。
【０００４】
以下、図１７ないし図２０を用いて一般的な従来技術の構成と動作について説明する。
図１７は、記憶装置システムをホストコンピュータ間で共有するクラスタコンピューティングシステムの一般的なシステム構成図である。
図１８は、図１７のシステムでホストコンピュータＡに障害がおこったことを説明する図である。
図１９は、サイト間で記憶装置システムを別個に持つクラスタコンピューティングシステムの一般的なシステム構成図である。
図２０は、図１９のシステムでサイトＡの記憶装置システムＡに障害がおこったことを説明する図である。
【０００５】
記憶装置システムをホストコンピュータ間で共有するクラスタコンピューティングシステムでは、図１７に示されるように、稼動系であるホストコンピュータＡ１０と、待機系であるホストコンピュータＢ１１とが記憶装置システム５１、５２にそれぞれインタフェースケーブルＡ４０、Ｂ４１とが接続され、Ｉ／Ｏ要求をおこなう構成になっている。
【０００６】
この稼動処理をおこなっているホストコンピュータＡ１０、待機状態となっているホストコンピュータＢ１１では、それらをつなぐＩＰネットワーク３０を介してハートビート通信をおこない、お互いの状態監視をおこなっている。
【０００７】
記憶装置システム５０が有する論理的なディスクボリューム（以下、「論理ディスクボリューム」）は、通常の稼動状態では、ホストコンピュータＡ１０がアクセスしている。
【０００８】
もし、図１８のようにホストコンピュータＡ１０に障害が起こったときには、待機系のホストコンピュータＢ１１は、ＩＰネットワーク３０により障害を検知して、稼動を始めて、ホストコンピュータＡ１０の処理を引き継ぎ、記憶装置システムにアクセスするようになる。
【０００９】
このような構成のクラスタコンピューティングシステムは、片方のホストコンピュータに障害が発生しても、稼動処理を維持できるようなシステムとなっている。
【００１０】
しかしながら、稼動処理に必要なデータが格納されている記憶装置システム自体に障害が発生した場合には、稼動処理を継続できない。
【００１１】
したがって、図１９のように稼動系と待機系で記憶装置システムを別々に持つ構成が考えられる。
【００１２】
図１９に示した構成のクラスタコンピューティングシステムでは、稼動系であるサイトＡ１００と待機系であるサイトＢ１０１は、各々、記憶装置システムＡ５１と記憶装置システムＢ５２を持っている。そして、記憶装置システム間で、常時、リモートコピーをおこなっている。リモートコピーとは、物理的に離れた場所にある複数の記憶装置システム同士が、ホストコンピュータを介さずにデータのコピー（二重書き）をおこなう技術である。
【００１３】
リモートコピーをおこなうときには、記憶装置システム同士は、専用回線あるいは公衆回線（図１９では、ＦＣ（Ｆｉｂｅｒ Ｃｈａｎｎｅｌ）ネットワーク４０）で互いに接続されており、稼動系のサイトＡ１００にある記憶装置システムＡ５１のコピー元論理ディスクボリュームが、待機系のサイトＢ１０１の記憶装置システムＢ５２に、コピー先論理ディスクボリュームとしてコピーされる。
【００１４】
このようにして、記憶装置システムＢ５２は、記憶装置システムＡ５１のバックアップ系として動作し、データの一貫性が保持されている。
【００１５】
ここで、図２０に示されるように、記憶装置システムＡ５１はに障害が起こったときには、ホストコンピュータＡ１０が障害を検知し、サイト間を結ぶＩＰネットワーク３０を介して、ホストコンピュータＢ１１に記憶装置システムＡ５１に障害が発生したことを報告する。
【００１６】
一方、サイトＢ１０１における記憶装置システムＢ５２も、ＦＣネットワーク９０を介して、リモートコピー元の記憶装置システムＡ５１に障害が発生したことを検知する。
【００１７】
このように、ホストコンピュータＢ１１は、ホストコンピュータＡ１０からの報告と、インタフェースケーブル１１１を介した記憶装置システムＢ５２の状態を確認すると、サイトＡ１００における記憶装置システムＡ５１に障害が発生したことを認識して、稼働処理を引き継ぐ動作をおこなう。
【００１８】
サイトＡ１００からサイトＢ１０１に稼働処理が引き継がれた後、サイトＡ１００における記憶装置システムＡ５１が復旧し、その記憶装置システムＡ５１が稼働処理を実行できる状態になった場合には、稼働処理を引き継いだホストコンピュータＢ１１が接続される記憶装置システムＢ５２をリモートコピー元として設定し、復旧した記憶装置システムＡ５１をリモートコピー先として再設定して、リモートコピーをおこなうことで、システム全体の稼働を停止することなく、記憶装置システムＡ５１にデータのリカバリーをおこなうことができる。
【００１９】
【特許文献１】
特開２００２−３１２１８９号公報
【００２０】
【発明が解決しようとする課題】
上記従来技術の図１９に示したサイト間で別々の記憶装置システムを持つ構成では、複数のホストコンピュータが記憶装置システムを共有してアクセスする図１５に示したシステムとは異なり、稼動系の記憶装置システム自体に障害が発生した場合でも、稼働処理を継続することができる。
【００２１】
ところで、クラスタコンピューティングシステムでは、ホストコンピュータ間における稼動処理の引き継ぎを可能にするため、常に相手の状態を監視し合う必要がある。図１９に示したシステムでは、ホストコンピュータ間を結ぶＩＰネットワークにおけるハートビート通信と、記憶装置システム間を結ぶＦＣネットワークにおけるリモートコピーを利用して、相手サイトの状態を確認し障害発生を認識する。したがって、障害発生の態様によっては、システムの障害回復がうまくおこなえない場合が生じる。
【００２２】
以下では、障害発生の態様によっては、システムの障害回復がうまくおこなえない場合について、図２１および図２２を用いて説明する。
図２１は、図１９の構成でＩＰネットワーク３０とＦＣネットワーク９０に障害がおこった場合を説明する図である。
図２２は、図１９の構成でサイトＡに障害がおこった場合を説明する図である。
【００２３】
障害発生の態様としては、図２１に示されるように、サイトＡ１００におけるホストコンピュータＡ１０、および、サイトＢ１０１におけるホストコンピュータＢ１１を結ぶＩＰネットワーク３０と、サイトＡ１００における記憶装置システムＡ５１およびサイトＢ１０１における記憶装置システムＢ５２を結ぶＦＣネットワーク９０とが両方とも断線した場合（以下、「サイト間ネットワーク全断」）がある。
【００２４】
このときには、サイト間で通信する手段が全くなくなってしまうために、相手のサイトの状態を監視することができなくなる。
【００２５】
また、別の障害の態様として、図２２に示されるように、例えば、サイトＡ１００におけるホストコンピュータＡ１０および記憶装置システムＡ５１が同時に障害となるなどによって、サイトＡ１００内のシステム全体の障害の場合（以下、「サイト障害」）がある。
【００２６】
このときに、サイトＢ１０１のホストコンピュータＢ１１から見ると、サイトＡ１００から情報を取得できないことは同じなので、図２１に示したサイト間ネットワーク全断の障害なのか、図２２に示したサイト障害なのか全く区別がつかないという問題点がある。
【００２７】
一般に、従来のクラスタコンピューティングシステムでは、サイト間ネットワーク全断が発生し、相手サイトの状態監視が不可能になると、相手サイトの情報を全く取得できなくなるため、ロジックによって次の三つの可能性がある。
（１）相手サイトの状態に関係なく、両サイトにおいて稼働処理を実行してしまう状態（スプリットブレイン状態）
（２）相手サイトの状態に関係なく、両サイトにおいて稼働処理を停止してしまう状態
（３）それまで稼働処理を実行していたサイトにおいてのみ、稼働処理を続行する状態
例えば、図２１に示したサイト間ネットワーク全断の障害により、（１）のスプリットブレイン状態になると、両サイトにおけるホストコンピュータは、自サイトの記憶装置システムにおける論理ディスクボリュームのデータを更新してしまうため、リモートコピー元とリモートコピー先で異なるデータが存在してしまう結果となる。
【００２８】
実際、図２１に示したサイト間ネットワーク全断の障害で、サイトＡ１００におけるホストコンピュータＡ１０は、サイトＢ１０１にサイト障害が発生したと判断し、稼動したままであり、サイトＢ１０１におけるホストコンピュータＢ１１も、サイトＡ１００にサイト障害が発生したと判断したとすると、（１）のスプリットブレイン状態になる。
【００２９】
したがって、図２１に示したサイト間ネットワーク全断の状態で、サイトＡ１００が稼動しているときには、サイトＢ１０１は、依然として待機していなければならないが、図２２のサイト障害状態と区別がつかないため、論理的な制御ができない。図２２の状態では、サイトＢ１０１は、障害を確認した場合には、稼動を開始しなければ、（２）の状態になってしまう。
【００３０】
このように、待機系であるサイトＢ１０１が、サイト間ネットワーク全断の障害か、サイト障害かの区別ができなければ、システム全体の信頼性が確保できないという問題点があった。
【００３１】
また、上記従来技術の特許文献１では、サイト間で複数の選択経路が用意されているので、通常のクラスタシステムよりも強固であり、信頼性が高いということができる。しかしながら、この特許文献１のシステムでも、通信状態が極端に悪いとき、サイト自体かその間の通信路の大規模火災などのリスクには対応できていない。
【００３２】
本発明は、上記問題点を解決するためになされたもので、その目的は、稼動系システムと待機系システムを有するクラスタコンピューティングシステムにおいて、障害の態様によらず、各々のサイト間を接続するネットワークに障害があっても、矛盾なく両サイトを動作させて、障害回復をおこなうことのできるクラスタコンピューティングシステムを提供することにある。
【００３３】
【課題を解決するための手段】
上記問題点は、複数のサイトを有するクラスタコンピューティングシステムにおいて、相手サイトの状態を確認するのに、ホストコンピュータ間のネットワークまたは、記憶装置システム間のネットワークによっていたことにより生じる。これらのネットワークの通信が途絶すると、相手サイトの状態を確認することが不可能となってしまうからである。
【００３４】
上記のＩＰネットワーク、ＦＣネットワークなどのサイト間ネットワークは、有線ケーブルにより、相手サイトの状態監視をおこなっていた。しかしながら、有線ケーブルを用いる場合、地震やケーブル火災等が原因で、それら全てが同時に断線してしまう（サイト間ネットワーク全断）可能性は否定できない。この有線ケーブルの断線は、クラスタコンピューティングシステムの特徴でもある災害対策（ディザスタリカバリ）の効果を著しく損なうことになる。
【００３５】
本発明では、別の有線による状態監視手段における欠点を補うために、無線通信装置による、相手サイトへの障害報告をおこなうことにした。
【００３６】
この構成によれば、障害が発生していない間には、従来のクラスタコンピューティングシステムと何ら変わらない動作をし、状態監視手段である有線ケーブルが断線し、通常のクラスタコンピューティングシステムでは適切な運用を維持できないときでも、無線通信により、相手サイト間と通信手段を確保することにより、信頼性を高めることができる。
【００３７】
すなわち、本発明では、断線する可能性が大きい有線ケーブルとは異なるインフラ（衛星通信、無線ＬＡＮ等）を用いることで、有線ケーブルとの同時故障を最小限に低くした無線通信装置による障害報告を、有線ケーブルによるサイト間の情報交換の代用とすることで、サイト間ネットワーク全断発生後も、相手サイトに障害情報を伝達できるシステムを実現することができる。したがって、上記で示した三つのロジックのいずれにおいても、クラスタコンピューティングシステムにおける適切な運用（障害発生時における稼働処理の引継ぎ等）を実現することが可能となる。
【００３８】
しかしながら、無線通信には、電波障害や、誤動作等による通信の不安定さが懸念事項に挙げられる。そこで、本発明において用いる無線通信は、従来のクラスタコンピューティングシステムにおける状態監視のように、常に相手サイトの状態を監視するような恒久的な接続ではなく、サイト間ネットワーク全断発生後の、稼働処理引継ぎ時においてのみ接続するるように限定し、無線通信における懸念事項を最小限に抑えた通信としている。
【００３９】
このように、本発明のシステムにおいて用いる無線通信装置による障害報告は、従来のサイト間ネットワークにおける状態監視のように、複雑なデータのやり取りや、恒久的な接続をする必要はなく、障害発生の報告を、障害発生時にのみおこなうだけに限定されるため、従来とは異なる構成の状態監視手段となる。
【００４０】
【発明の実施の形態】
以下、本発明に係る各実施形態を、図１ないし図１６を用いて説明する。
【００４１】
〔実施形態１〕
以下、本発明に係る第一の実施形態を図１ないし図１５を用いて説明する。
（Ｉ）クラスタコンピューティングシステムのシステム構成
先ず、図１ないし図４を用いて、本発明の第一の実施形態に係るクラスタコンピューティングシステムのシステム構成について説明する。
図１は、本発明の第一の実施形態に係るクラスタコンピューティングシステムのシステム構成図である。
図２は、ホストコンピュータＡの内部構成図である。
図３は、記憶装置システムＡの内部構成図である。
図４は、無線通信装置Ａの内部構成図である。
【００４２】
本実施形態のクラスタコンピューティングシステムは、図１に示されるように、稼動系システムであるサイトＡ１００と、待機系システムであるサイトＢ１０１からなっている。
【００４３】
そして、稼動系であるホストコンピュータＡ１０と、待機系であるホストコンピュータＢ１１とが記憶装置システム５１、５２にそれぞれインタフェースケーブルＡ４０、Ｂ４１とが接続され、Ｉ／Ｏ要求をおこなう構成になっていることは、従来技術と同様である。
【００４４】
また、稼動処理をおこなっているホストコンピュータＡ１０、待機状態となっているホストコンピュータＢ１１では、それらをつなぐＩＰネットワーク３０を介してハートビート通信をおこない、お互いの状態監視をおこなっていることも従来技術と同様である。
【００４５】
そして、リモートコピー機能を有することも、従来技術と同様であり、稼動系のサイトＡ１００にある記憶装置システムＡ５１のコピー元論理ディスクボリュームが、待機系のサイトＢ１０１の記憶装置システムＢ５２に、コピー先論理ディスクボリュームとしてコピーされる。
【００４６】
このとき、サイトＡ１００におけるホストコンピュータＡ１０は、稼働系システムのホストコンピュータとして、インタフェースケーブルＡ４０で接続されている記憶装置システムＡ５１に対して、読み書き等の稼働処理を実行している。また、サイトＢ１０１におけるホストコンピュータＢ１１は、待機ホストコンピュータとして待機状態となっている。
【００４７】
さらに、サイトＡ１００におけるホストコンピュータＡ１０には、インタフェースケーブルＡＲ１８０を介して、無線通信装置Ａ１６０が接続されており、サイトＢ１０１におけるホストコンピュータＢ１１には、インタフェースケーブルＢＲ１８１を介して、無線通信装置Ｂ１６１が接続されている。
【００４８】
これらの無線通信装置は、例えば、地震や火災、テロ等によってサイト障害が発生した場合でも、無線通信装置に障害が及ばないように、それぞれが、飛行機のボイスレコーダーを格納するブラックボックスのような障害に耐えうる容器に収められており、サイト障害発生後にも、相手サイトへの状態報告がおこなえるような構成となっている。
【００４９】
サイトＡ１００における無線通信装置Ａ１６０は、ホストコンピュータＡ１０からの指示、または、ホストコンピュータＡ１０が故障したという自己判断により、サイトＢ１０１における無線通信装置Ｂ１６１をコールしたり、コールが成功したかどうかをホストコンピュータＡ１０に報告したりする等の機能を持ち、インタフェースケーブルＡＲ１８０を介して、ホストコンピュータＡ１０の状態監視をおこなっている。これにより、無線通信装置Ａ１６０は、サイトＡ１００においてサイト障害が発生した場合でも、このインタフェースケーブルＡＲ１８０を介して障害を検知し、それまでサイトＡ１００でおこなっていた稼働処理を、サイトＢ１０１に引き継ぐように、無線通信装置Ｂ１６１に対してコールができるようになっている。一方、サイトＢ１０１における無線通信装置Ｂ１６１は、サイトＡ１００における無線通信装置Ａ１６０からのコールを受信したり、そのコールがあったか否かをホストコンピュータＢ１１へ報告する等の機能を持ち、無線通信装置Ａ１６０と同様に、インタフェースケーブルＢＲ１８１を介して、ホストコンピュータＢ１１の状態監視をおこなっている。
【００５０】
このように、本発明における無線通信装置は、ホストコンピュータからの命令によりコール開始する機能、ホストコンピュータの状態を監視し、その状態によって自発的にコールを開始する機能、コールの結果をホストコンピュータに報告する機能等、特有のプログラムを有し、本発明における独自の動作をおこなう装置である。
【００５１】
なお、無線通信路としては、衛星通信を使ってもよいし、無線ＬＡＮの機能を使ってもよい。また、携帯電話の通信路である公衆通信網を使ってもよい。
【００５２】
ホストコンピュータＡ１０は、図２に示されるように、ＣＰＵ１０ａ、メモリ１０ｂ、入力装置１０ｃ、表示装置１０ｄ、無線通信装置インタフェース１０ｅ、ＩＰインタフェース１０ｆを備えている。
【００５３】
無線通信装置インタフェース１０ｅは、無線通信装置Ａ１６０と通信するためのインターネットであり、ＩＰインタフェース１０ｆは、他のサイトと通信するためのインタフェースである。これらは、同一の通信インタフェースであってもよい。
【００５４】
また、記憶装置システムＡ５１は、コントローラ５１ａ、制御メモリ５１ｂ、キャッシュメモリ５１ｃ、ＦＣインタフェース５１ｄ、通常複数のディスク装置５１ｅ、５１ｆ、５１ｇ、…を備えている。
【００５５】
コントローラ５１ａは、この記憶装置システム５１の各部を制御する機能を有する。キャッシュメモリ５１ｃは、ディスク装置５１ｅ、…のアクセスを高速化させるためデータをキャッシュしておくためのメモリであり、制御メモリ５１ｂは、コントローラに用いられる制御用のデータをキャッシュするためのメモリである。 ＦＣインタフェース５１ｄは、ファイバチャネルにより他の記憶装置システムを接続する。
【００５６】
無線通信装置Ａ１６０は、図４に示されるように、コントローラ１６０ａ、メモリ１６０ｂ、送受信回路１６０ｃ、ホスト監視部１６０ｄ、ホストインタフェース１６０ｅを備えている。
【００５７】
コントローラ１６０ａは、無線通信装置Ａ１６０の内部を制御しており、ホストインタフェース１６０ｅを介してホストから送られてくるコマンドやホスト監視部１６０ｄからの報告を受け付けて、それを解釈して外部にコマンドを発行する。
【００５８】
ホスト監視部１６０ｄは、ホストインタフェース１６０ｅを介してホストを監視し、結果をコントローラ１６０ａに報告する。
【００５９】
送受信回路１６０ａは、通常の無線通信装置がおこなうようなベースバンド処理、搬送波処理、高周波処理をおこない、コントローラ１６０ａからのコマンドやデータを外部に送信したり、外部からのコマンドやデータを受信して、コントローラ１６０ａに伝える。
（ＩＩ）クラスタコンピューティングシステムの障害時の動作
次に、図５ないし図１３を用いて本実施形態のクラスタコンピューティングシステムの障害時の動作について説明する。
【００６０】
（ＩＩ−１）障害の態様と動作の概要
先ず、図５ないし図８を用いて本実施形態のクラスタコンピューティングシステムの障害の態様と動作の概要について説明する。
図５は、本発明のクラスタコンピューティングシステムで、サイト間ネットワーク全断がおこったときを説明する図である。
図６は、本発明のクラスタコンピューティングシステムで、サイト間ネットワーク全断と記憶装置システムの障害が同時におこったときを説明する図である。
図７は、本発明のクラスタコンピューティングシステムで、サイト障害がおこったときを説明する図である。
図８は、本発明のクラスタコンピューティングシステムで、サイト間ネットワーク全断とサイト障害が同時におこったときを説明する図である。
【００６１】
サイト間ネットワーク全断とは、図５に示される場合であり、既に説明したように、サイトＡ１００におけるホストコンピュータＡ１０、および、サイトＢ１０１におけるホストコンピュータＢ１１を結ぶＩＰネットワーク３０と、サイトＡ１００における記憶装置システムＡ５１およびサイトＢ１０１における記憶装置システムＢ５２を結ぶＦＣネットワーク９０とが両方とも断線した場合である。
【００６２】
この場合には、本発明のシステムでは、稼動系システムは、引き続き稼動を続け、待機系システムでは、引き続き待機を続けることになる。
【００６３】
そして、図６に示されるように、サイト間ネットワーク全断の状態で、記憶装置システム障害がおこったときには、無線通信装置Ａ１６０を介して、サイトＡ１００からサイトＢ１０１に連絡が行き、初めて待機系システムが稼動を開始することになる。
【００６４】
また、サイト障害とは、図７に示されるように、例えば、サイトＡ１００におけるホストコンピュータＡ１０および記憶装置システムＡ５１が同時に障害となるなどによって、サイトＡ１００内のシステム全体が障害となっている場合をいう。
【００６５】
この場合には、サイトＡ１００から無線通信装置Ａ１６０が、サイトＢ１０１に連絡して、待機系システムが稼動を開始することになる。
【００６６】
また、図８に示されているのは、ネットワーク全断とサイト障害が同時に、障害がおこった場合である。
【００６７】
この場合も、図７の場合と同様に、サイトＢ１０１に連絡して、待機系システムが稼動を開始することになる。
【００６８】
図７と図８の場合には、サイトＡ１００の無線通信装置Ａ１６０が、サイト障害が発生したことを検知して、サイトＡ１００から無線通信装置Ａ１６０が、サイトＢ１０１の無線通信装置Ｂ１６１に連絡して、待機系システムが稼動を開始することになる。
【００６９】
サイトＢ１０１の動作としては、図７と図８の場合もいずれも同じであり、サイトＡ１００からの情報が得られないため、無線通信装置Ｂ１６１が無線通信装置Ａ１６０のコールを待ち受ける。そして、サイトＡ１００に障害がおこったときに、障害報告を受け、ホストコンピュータＢ１１に稼動を開始するコマンドを発行して、稼動を開始させる。
【００７０】
（ＩＩ−２）サイトＡにおけるホストコンピュータＡのメイン動作
以下、図９のフローチャートを追いながらサイトＡにおけるホストコンピュータＡのメイン動作について説明する。
図９は、サイトＡにおけるホストコンピュータＡのメイン動作を説明するフローチャートである。
【００７１】
サイトＡ１００におけるホストコンピュータＡ１０は、稼動系システムのホストコンピュータとして稼動処理をおこなっており、ＩＰネットワーク３０およびＦＣネットワーク９０のサイト間ネットワークを利用して、サイトＢ１０１の状態監視をおこなっている。
【００７２】
この状態で、サイトＡ１００内のシステムに、サイトＡ１００におけるホストコンピュータＡ１０において稼動処理の続行が不可能な障害が発生した場合は、サイト間ネットワークにより情報が伝えられ、その稼動処理は、サイトＢ１０１におけるホストコンピュータＢ１１に引き継がれる。
【００７３】
このような一連の動作は、従来のクラスタコンピューティングシステムにおいておこなわれている動作であり、ここでは「通常クラスタ運用処理」（Ｓ６００）と呼ぶ。
【００７４】
ホストコンピュータＡ１０は、この通常クラスタ運用処理時に、サイト間ネットワーク全断が発生し、サイト間ネットワークを利用して、サイトＢ１０１における情報を取得することができなくなると（Ｓ６０１ Ｙｅｓ）、それまで稼働処理をおこなっていたサイトＡ１００におけるホストコンピュータＡ１０が、引き続き稼働処理をおこなう処理（以下、「稼働系優先運用処理」Ｓ６０２）に移る。
【００７５】
従来のクラスタコンピューティングシステムでは、サイト間ネットワーク全断が発生すると、両サイトにおけるホストコンピュータが、互いに相手サイトにサイト障害が発生したと判断し、それまで稼働処理をおこなっていたサイトが稼働処理を停止したり（この場合、両サイトにおいて稼働処理が停止した状態となる）、それまで待機状態となっていたサイトが稼働処理を引き継いでしまう（この場合、スプリットブレイン状態となる）等の問題点を生じていたが、本発明のシステムの場合には、サイト間ネットワーク全断が発生しても、稼動系システムでは、それまでおこなっていた動作を実行し続ける。そして、待機状態となっていたサイトは待機状態を維持することにする。
【００７６】
このような稼動系優先運用処理をおこなうのは、サイト間ネットワーク全断が発生しても、無線通信により情報を伝えることができるため、稼動系システムでは、引き続き処理をおこなって、待機系システムでは、稼動系システムから指示があったときに、初めて稼動処理を開始すればよいという考えに基づくものである。
【００７７】
そして、ホストコンピュータＡ１０が、この稼動側優先運用処理時に、インタフェースケーブルＡ４０により、記憶装置システムＡ５１に障害が発生したことを検知した場合（Ｓ６０３ Ｙｅｓ）、インタフェースケーブルＡ４０自体の障害によっ記憶装置システムＡ５１の情報取得ができないような場合には、それまでおこなっていた稼動処理は続行できないため、記憶装置システム障害対応処理（Ｓ３０００Ｈ）に移る。
【００７８】
（ＩＩ−３）サイトＡにおける無線通信装置Ａ１６０のメイン動作
以下、図１０のサイトＡにおける無線通信装置Ａ１６０のメイン動作について説明する。
図１０は、サイトＡにおける無線通信装置Ａ１６０のメイン動作について説明するフローチャートである。
【００７９】
サイトＡ１００における無線通信装置Ａ１６０は、図１で説明したように、ホストコンピュータＡ１０と、インタフェースケーブルＡＲ１８０で接続されている。
【００８０】
無線通信装置Ａ１６０は、通常、このコマンドを待機する状態（以下、「コマンド待機状態」）となっている（Ｓ７００）。また同時に、インタフェースケーブルＡＲ１８０を介して、ホストコンピュータＡ１０の状態監視もおこっており、インタフェースケーブルＡＲ１８０から取得するホストコンピュータＡ１０の情報を常に監視している。
【００８１】
無線通信装置Ａ１６０は、このコマンド待機時に、サイトＡ１００におけるホストコンピュータＡ１０から、インタフェースケーブルＡＲ１８０を介して後述するコール指示コマンドを受領（Ｓ７０２ Ｙｅｓ）すると、記憶装置システム障害対応処理（Ｓ３０００Ｒ）に移る。
【００８２】
また、無線通信装置Ａ１６０は、このコマンド待機状態のとき、サイトＡ１００におけるサイト障害により、インタフェースケーブルＡＲ１８０を介して、ホストコンピュータＡ１０の情報を取得できない場合（Ｓ７０１ Ｎｏ）、サイト障害対応処理（Ｓ５０００Ｒ）に移る。
【００８３】
（ＩＩ−４）サイトＢにおけるホストコンピュータＢのメイン動作
以下、図１１のフローチャートを追いながらサイトＢにおけるホストコンピュータＢのメイン動作について説明する。
図１１は、サイトＢにおけるホストコンピュータＢのメイン動作について説明するフローチャートである。
【００８４】
サイトＢ１０１におけるホストコンピュータＢ１１は、前述したように、待機系システムのホストコンピュータとして待機状態となっており、ＩＰネットワーク３０およびＦＣネットワーク９０のサイト間ネットワークを利用して、サイトＡ１００の状態監視をおこなっている。
【００８５】
この状態で、サイトＡ１００内のシステムに、サイトＡ１００において稼動処理が続行できないような障害が発生した場合には、サイトＢ１０１におけるホストコンピュータＢ１１がその稼動処理を引き継ぐことになり、このような従来のクラスタコンピューティングシステムにおける運用処理がおこなわれる（通常クラスタ運用処理）（Ｓ８００）。
【００８６】
ホストコンピュータＢ１１は、この通常クラスタ運用処理時に、サイト間ネットワーク全断が発生するか、サイトＡ１００にサイト障害がおこるかして、ＩＰネットワーク３０、および、ＦＣネットワーク９０を利用してサイトＡ１００の状態監視が不可能になると（Ｓ８０１ Ｙｅｓ）、サイトＡの情報取得不能処理（Ｓ４０００Ｈ）に移る。
【００８７】
（ＩＩ−５）サイトＢにおける無線通信装置Ｂのメイン動作
以下、図１２のフローチャートを追いながらサイトＢにおける無線通信装置Ｂのメイン動作について説明する。
図１２は、サイトＢにおける無線通信装置Ｂのメイン動作について説明するフローチャートである。
【００８８】
サイトＢ１０１における無線通信装置Ｂ１６１は、通常、コマンド待機状態となっている（Ｓ９００）。
【００８９】
無線通信装置Ｂ１６１は、このコマンド待機時に、ホストコンピュータＢ１１から待機指示コマンドを受領する（Ｓ９０１ Ｙｅｓ）と、サイトＡの情報取得不能処理（Ｓ４０００Ｒ）に移る。
【００９０】
（ＩＩ−６）サイトＡにおける記憶装置システム障害対応処理の動作
以下、図１３のフローチャートを追いながらサイトＡにおける記憶装置システム障害対応処理の動作について説明する。
図１３は、サイトＡにおいて、ホストコンピュータＡと無線通信装置Ａとの記憶装置システム障害対応処理の動作を並列して示したフローチャートである。
【００９１】
図６に示したように、サイト間ネットワーク全断が発生した後に、サイトＡ１００における記憶装置システムＡ５１に障害が発生したとする。
【００９２】
ホストコンピュータＡ１０の動作としては、Ｓ１０００において記憶装置システム障害対応処理フロー（Ｓ３０００Ｈ）へ移った場合である。
【００９３】
サイトＡ１００におけるホストコンピュータＡ１０は、インタフェースケーブルＡＲ１８０を介して、無線通信装置Ａ１６０に対し、コール指示コマンドを発行する。コール指示コマンドは、無線通信装置Ｂ１６１に対するコールを指示するコマンドである。
【００９４】
無線通信装置Ａ１６０は、コール指示コマンドを受領すると（Ｓ７０１、Ｓ１５０１）、サイトＢ１０１における無線通信装置Ｂ１６１へのコールを開始し、自己の証明として認証ＩＤを含むパケットも送出する（Ｓ１５０２）。
【００９５】
無線通信装置Ａ１６０は、無線通信装置Ｂ１６１へのコールを、無線通信装置Ｂ１６１につながるまで繰り返し（Ｓ１５０３ Ｎｏ）、一度でも無線通信装置Ｂ１６１につながると（Ｓ１５０３ Ｙｅｓ）、その接続はただちに切断される（Ｓ１５０４）。
【００９６】
これは、無線通信装置Ａ１６０における無線通信装置Ｂ１６１への接続が成功した段階で、それが稼動処理の引継ぎ要求が伝わったことにすることを意味する。
【００９７】
後に述べるように、サイトＢ１０１では、一度でも無線通信装置Ｂ１６１につながって、認証ＩＤを受信すると稼動処理を開始するので、この段階で、サイトＡ１００では、記憶装置システム障害対応処理を終えてよい。
【００９８】
（ＩＩ−７）サイトＢにおけるサイトＡの情報取得不能処理の動作
以下、図１４のフローチャートを追いながらサイトＢにおけるサイトＡの情報取得不能処理について説明する。
図１４は、サイトＢにおいて、ホストコンピュータＢと無線通信装置ＢとのサイトＢにおけるサイトＡの情報取得不能処理の動作を並列して示したフローチャートである
障害の態様としては、図５のネットワーク全断障害が起こるか、図７のサイト障害が起こるか、または、図８のようにその両方の障害が起こったとする。
【００９９】
ホストコンピュータＢの動作としては、Ｓ２０００においてサイトＡの情報取得不能処理（Ｓ４０００Ｈ）へ移った場合である。
【０１００】
サイトＢ１０１におけるホストコンピュータＢ１１は、無線通信装置Ｂ１６１に対して、待機指示コマンドを発行する（Ｓ１６００）。待機指示コマンドは、無線通信装置Ｂ１６１が無線通信装置Ａ１６０からのコールを待機するコマンドである。
【０１０１】
無線通信装置Ｂ１６１は、インタフェースケーブルＢＲ１８１を介して、ホストコンピュータＢ１１からの待機指示コマンドを受領し（Ｓ９０１、Ｓ１６０４）、無線通信装置Ａ１６０からのコールを待つ待機状態となる（Ｓ１６０５）。この待機状態は、無線通信装置Ｂ１６１が唯一外部からのコールを受け入れる状態であり、万が一、この待機状態時以外に、外部からコールがあった場合でも、無線通信装置Ｂ１６１はこれを無視し、その時の状態を維持することを意味する。このようにすることにより、誤動作などが防止できる。
【０１０２】
無線通信装置Ｂ１６１は、この待機状態時に、無線通信装置Ａ１６０からのコールがあると（Ｓ１６０６ Ｙｅｓ）、そのコールが無線通信装置Ａ１６０からのものであるか、認証ＩＤを用いて確認し（Ｓ１６０７）、無線通信装置Ａ１６０のコールであることを確認できたら、ホストコンピュータＢ１１に、インタフェースケーブルＢＲ１８１を介して、稼動処理開始指示コマンドを発行する（Ｓ１６０８）。稼動処理開始指示コマンドは、無線通信装置Ｂ１６１がホストコンピュータＢ１１に稼動を処理するコマンドである。
【０１０３】
この稼動処理開始コマンドを受領したホストコンピュータＢ１１は（Ｓ１６０２ Ｙｅｓ）、ここで初めて、サイトＡ１００において稼働処理を続行できない障害が発生したことを認識し、稼動処理を開始する（Ｓ１６０３）。このホストコンピュータＢ１１における稼動処理の開始は、サイトＡ１００におけるホストコンピュータＡ１０でおこなわれていた稼動処理が、サイトＢ１０１におけるホストコンピュータＢ１１に引き継がれたことを意味する。
【０１０４】
（ＩＩ−８）サイトＡにおけるサイト障害後の無線通信装置Ａの動作
図６に示すように、サイトＡ１００において、例えば地震や火災、テロ等によってサイトＡ１００内のシステム全てに障害が発生したようなサイト障害がおこったものとする。また、図８に示すように、サイト障害に加えて、ネットワーク全断障害がおこっている場合もあり得る。
【０１０５】
以下、図１５のフローチャートを追いながらサイトＡにおけるサイト障害後の無線通信装置Ａの動作について説明する。
図１５は、サイトＡにおけるサイト障害後の無線通信装置Ａの動作を示したフローチャートである。
【０１０６】
ただし、無線通信装置Ａ１６０には、ブラックボックスとして遮蔽されているため障害が及んでいないものとする。
【０１０７】
無線通信装置Ａ１６０の動作としては、Ｓ１０００において、サイト障害対応処理（Ｓ５０００Ｒ）へ移った場合である。
【０１０８】
サイトＡ１００における無線通信装置Ａ１６０は、インタフェースケーブルＡＲ１８０を介しての、ホストコンピュータＡ１０の状態監視が不可能となることから、サイトＡ１００において、サイト障害が発生したと判断し、無線通信装置Ｂ１６１へのコールを開始し、自己の証明として認証ＩＤを含むパケットも送出する（Ｓ１７００） 。
【０１０９】
無線通信装置Ａ１６０は、無線通信装置Ｂ１６１へのコールを、無線通信装置Ｂ１６１につながるまで繰り返し（Ｓ１７０１ Ｎｏ）、一度コールが受け付けられと（Ｓ１７０１ Ｙｅｓ）、その接続はただちに切断される（Ｓ１７０２）。無線通信装置Ａ１６０からの無線通信装置Ｂ１６１へのコールが一度でも受け付けられ、それが稼動処理の引継ぎを完了したものとする。
【０１１０】
以下のサイトＢ１０１におけるホストコンピュータＢ１１、および、無線通信装置Ｂ１６１における処理は、記憶装置システム障害対応処理（Ｓ３０００Ｈ、Ｓ３０００Ｒ）と同じである。
【０１１１】
サイトＢ１０１のホストコンピュータＢ１１は、ネットワーク全断の障害でも、サイト障害の場合でも、ＩＰネットワーク３０、および、ＦＣネットワーク９０を利用してサイトＡ１００の状態監視が不可能になるので（Ｓ８０１ Ｙｅｓ）、サイトＡの情報取得不能処理に移る（Ｓ４０００Ｈ）。
【０１１２】
そして、無線通信装置Ｂ１６１に待機指示コマンド発行を出し（Ｓ１６００）、無線通信装置Ｂ１６１は、無線通信装置Ａ１６０のコール待ちになる（Ｓ１６０５、Ｓ１６０６）。そして、無線通信装置Ｂ１６１がコールを受け、認証ＩＤを無線通信装置Ａ１６０から受信すると、無線通信装置Ｂ１６１は、ホストコンピュータＢ１１に稼動処理指示コマンドを出し（Ｓ１６０８）、ホストコンピュータＢ１１は、稼動を開始する（Ｓ１６０３）。
【０１１３】
〔実施形態２〕
以下、本発明に係る第二の実施形態を図１６を用いて説明する。
図１６は、本発明の第二の実施形態に係るクラスタコンピューティングシステムのシステム構成図である。
【０１１４】
第一の実施形態では、サイトＡとサイトＢが別々の記憶装置システムを持ち、リモートコピーをおこなっている場合であった。
【０１１５】
本実施形態では、サイトＡ１００とサイトＢ１０１が記憶装置システム５０を共用しているものとする。このシステム構成で、サイトＡ１００に障害がおこったときにも、同様に無線通信装置Ａ１６０が、無線通信装置Ｂ１６１に連絡させることにより、第一の実施形態と同様に、稼動系システムと待機系システムの連絡をおこなって障害回復の処理をおこなうことができる。
【０１１６】
【発明の効果】
以上のように、本発明では、リモートコピー機能を組み合わせた従来のクラスタコンピューティングシステムに、無線通信装置による相手サイトへの障害報告を導入することによって、サイト間ネットワーク全断発生後でも相手サイトの障害を認識することが可能となる。したがって、例えば、サイト間ネットワーク全断発生後、稼働処理をおこなっているサイトにおいて障害が発生しても、適切な判断で、もう片方のサイトが稼働処理を引き継ぐことができる。
【０１１７】
また、本発明は、従来のシステムにおける状態監視手段として用いる有線ケーブルを単に冗長化することによって、ディザスタリカバリの強化を図るものでなく、有線ケーブルとは異なるインフラを用いた無線通信による状態報告手段を加えることによって、その強化を図る発明である。
【０１１８】
このように、本発明によれば、稼動系システムと待機系システムを有するクラスタコンピューティングシステムにおいて、障害の態様によらず、各々のサイト間を接続するネットワークに障害があっても、矛盾なく両サイトを動作させて、障害回復をおこなうことのできるクラスタコンピューティングシステムを提供することができる。
【図面の簡単な説明】
【図１】本発明の第一の実施形態に係るクラスタコンピューティングシステムのシステム構成図である。
【図２】ホストコンピュータＡの内部構成図である。
【図３】記憶装置システムＡの内部構成図である。
【図４】無線通信装置Ａの内部構成図である。
【図５】本発明のクラスタコンピューティングシステムで、サイト間ネットワーク全断がおこったときを説明する図である。
【図６】本発明のクラスタコンピューティングシステムで、サイト間ネットワーク全断と記憶装置システムの障害が同時におこったときを説明する図である。
【図７】本発明のクラスタコンピューティングシステムで、サイト障害がおこったときを説明する図である。
【図８】本発明のクラスタコンピューティングシステムで、サイト間ネットワーク全断とサイト障害が同時におこったときを説明する図である。
【図９】サイトＡにおけるホストコンピュータＡのメイン動作を説明するフローチャートである。
【図１０】サイトＡにおける無線通信装置Ａ１６０のメイン動作について説明するフローチャートである。
【図１１】サイトＢにおけるホストコンピュータＢのメイン動作について説明するフローチャートである。
【図１２】サイトＢにおける無線通信装置Ｂのメイン動作について説明するフローチャートである。
【図１３】サイトＡにおいて、ホストコンピュータＡと無線通信装置Ａとの記憶装置システム障害対応処理の動作を並列して示したフローチャートである。
【図１４】サイトＢにおいて、ホストコンピュータＢと無線通信装置ＢとのサイトＢにおけるサイトＡの情報取得不能処理の動作を並列して示したフローチャートである
【図１５】サイトＡにおけるサイト障害後の無線通信装置Ａの動作を示したフローチャートである。
【図１６】本発明の第二の実施形態に係るクラスタコンピューティングシステムのシステム構成図である。
【図１７】記憶装置システムをホストコンピュータ間で共有するクラスタコンピューティングシステムの一般的なシステム構成図である。
【図１８】図１７のシステムでホストコンピュータＡに障害がおこったことを説明する図である。
【図１９】サイト間で記憶装置システムを別個に持つクラスタコンピューティングシステムの一般的なシステム構成図である。
【図２０】図１９のシステムでサイトＡの記憶装置システムＡに障害がおこったことを説明する図である。
【図２１】図１９の構成でＩＰネットワーク３０とＦＣネットワーク９０に障害がおこった場合を説明する図である。
【図２２】図１９の構成でサイトＡに障害がおこった場合を説明する図である。
【符号の説明】
１０…ホストコンピュータＡ
１１…ホストコンピュータＢ
２０…論理ディスクボリューム
２１…コピー元論理ディスクボリューム
２２…コピー先論理ディスクボリューム
３０…ＩＰネットワーク
４０…インタフェースケーブルＡ
４１…インタフェースケーブルＢ
５０…記憶装置システム
５１…記憶装置システムＡ
５２…記憶装置システムＢ
９０…ＦＣネットワーク
１００…サイトＡ
１０１…サイトＢ
１６０…無線通信装置Ａ
１６１…無線通信装置Ｂ
１７０…ブラックボックスＡ
１７１…ブラックボックスＢ
１８０…インタフェースケーブルＡＲ
１８１…インタフェースケーブルＢＲ
Claims (10)
- 稼動系システムと待機系システムよりなるクラスタコンピューティングシステムにおいて、
前記稼動系システムと前記待機系システムは、それぞれ無線通信装置を有し、
前記稼動系システムの無線通信装置は、前記稼動系システムの障害を前記待機系システムの無線通信装置との通信により報告し、
前記障害の報告は、前記稼動系システムと前記待機系システムの間を接続する有線のネットワークが全て、ネットワーク断状態になったときにおこなうことを特徴とするクラスタコンピューティングシステム。 - 前記稼動系システムと待機系システムは、それぞれホストコンピュータと、記憶装置システムとを有し、
各々のホストコンピュータは、クラスタネットワークで接続され、
各々の記憶装置システムは、ストレージ間ネットワークで接続されていて、
前記クラスタネットワークと前記ストレージ間ネットワークが同時に、ネットワーク断状態になったときに、前記障害の報告をおこなうことを特徴とする請求項１記載のクラスタコンピューティングシステム。 - 前記クラスタネットワークは、ＩＰネットワークであり、
前記ストレージ間ネットワークは、ＦＣ（Ｆｉｂｅｒ Ｃｈａｎｎｅｌ）ネットワークであることを特徴とする請求項１記載のクラスタコンピューティングシステム。 - 前記稼動系システムの無線通信装置は、その稼動系システムの認証ＩＤを含むパケットを、前記待機系システムの無線通信装置に発信し、
前記待機系システムの無線通信装置は、その認証ＩＤを含むパケットを受信したときに、前記稼動系システムの障害であると認識して動作することを特徴とする請求項１記載のクラスタコンピューティングシステム。 - 前記稼動系システムの無線通信装置は、ホストコンピュータから、コール指示コマンドを受けて、障害報告の通信を前記待機系システムの無線通信装置におこなうことを特徴とする請求項１記載のクラスタコンピューティングシステム。
- 前記稼動系システムの無線通信装置は、前記稼動系システムのホストコンピュータの障害を監視し、障害を検知したときに、障害報告の通信を前記待機系システムの無線通信装置におこなうことを特徴とする請求項１記載のクラスタコンピューティングシステム。
- 前記待機系システムの無線通信装置は、前記稼動系システムの無線通信装置より、障害報告の通信を受信したときに、前記待機系システムのホストコンピュータに、稼動処理指示コマンドを発行することを特徴とする請求項１記載のクラスタコンピューティングシステム。
- 前記稼動系システムと前記待機系システムのそれぞれ無線通信装置は、
前記稼動系システムと前記待機系システムの各々のサイト障害に対しても、影響を受けないように隔離されたことを特徴とする請求項１記載のクラスタコンピューティングシステム。 - 稼動系システムと待機系システムよりなるクラスタコンピューティングシステムのフェールオーバー方法において、
前記稼動系システムと前記待機系システムは、それぞれ無線通信装置を有し、
前記稼動系システムは、前記待機系システムとの間の有線のサイト間ネットワークから情報を得られなくなったときでも、システムの稼動を継続させ、
前記稼動系システムは、自らのサイトの記憶装置システムに障害を発見したときに、前記稼動系システムの無線通信装置に指示を与えて、前記待機系システムの無線通信装置に、障害を報告する通信をおこなわせ、
前記待機系システムの無線通信装置は、前記稼動系システムの無線通信装置より障害の報告を受けて、前記待機系システムのホストコンピュータに稼動処理の開始を指示することを特徴とするクラスタコンピューティングシステムのフェールオーバー方法。 - 稼動系システムと待機系システムよりなるクラスタコンピューティングシステムのフェールオーバー方法において、
前記稼動系システムと前記待機系システムは、それぞれ無線通信装置を有し、
前記稼動系システムの無線通信装置は、常時、前記稼動系システムの状態を検知し、
前記稼動系システムの無線通信装置が、前記稼動系システムの障害を検知し、かつ、前記待機系システムが、前記稼動系システムのサイト間の有線のネットワークにより、情報が得られなくなったときに、
前記稼動系システムの無線通信装置は、前記待機系システムの無線通信装置に障害の報告する通信をして、
前記待機系システムの無線通信装置は、前記稼動系システムの無線通信装置より障害の報告を受けて、前記待機系システムのホストコンピュータに稼動処理の開始を指示することを特徴とするクラスタコンピューティングシステムのフェールオーバー方法。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003091265A JP2004302512A (ja) | 2003-03-28 | 2003-03-28 | クラスタコンピューティングシステム、および、そのフェールオーバー方法 |
| US10/652,161 US7370099B2 (en) | 2003-03-28 | 2003-08-28 | Cluster computing system and its failover method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003091265A JP2004302512A (ja) | 2003-03-28 | 2003-03-28 | クラスタコンピューティングシステム、および、そのフェールオーバー方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004302512A true JP2004302512A (ja) | 2004-10-28 |
| JP2004302512A5 JP2004302512A5 (ja) | 2006-02-23 |
Family
ID=33404680
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003091265A Pending JP2004302512A (ja) | 2003-03-28 | 2003-03-28 | クラスタコンピューティングシステム、および、そのフェールオーバー方法 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US7370099B2 (ja) |
| JP (1) | JP2004302512A (ja) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2010055136A (ja) * | 2008-08-26 | 2010-03-11 | Mitsubishi Electric Corp | 通信システム及び制御装置及び制御対象装置 |
| JP2012168623A (ja) * | 2011-02-10 | 2012-09-06 | Nec Corp | 待機系計算機、クラスタシステム、サービス提供方法およびプログラム |
Families Citing this family (27)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2004028066A2 (en) * | 2002-09-20 | 2004-04-01 | Tekelec | Methods and systems for locating redundant telephony call processing hosts in geographically separate locations |
| US7558884B2 (en) * | 2004-05-03 | 2009-07-07 | Microsoft Corporation | Processing information received at an auxiliary computing device |
| US7511682B2 (en) | 2004-05-03 | 2009-03-31 | Microsoft Corporation | Context-aware auxiliary display platform and applications |
| US7577771B2 (en) * | 2004-05-03 | 2009-08-18 | Microsoft Corporation | Caching data for offline display and navigation of auxiliary information |
| US7660914B2 (en) * | 2004-05-03 | 2010-02-09 | Microsoft Corporation | Auxiliary display system architecture |
| KR100650574B1 (ko) * | 2004-11-17 | 2006-11-29 | 엘지노텔 주식회사 | 피씨아이를 이용한 이중화 장치의 심볼 테이블 복원 방법 |
| JP2006285919A (ja) * | 2005-04-05 | 2006-10-19 | Hitachi Ltd | 計算機システム、計算機及びリモートコピー処理方法 |
| US9195397B2 (en) | 2005-04-20 | 2015-11-24 | Axxana (Israel) Ltd. | Disaster-proof data recovery |
| US7707453B2 (en) * | 2005-04-20 | 2010-04-27 | Axxana (Israel) Ltd. | Remote data mirroring system |
| US7797570B2 (en) * | 2005-11-29 | 2010-09-14 | Netapp, Inc. | System and method for failover of iSCSI target portal groups in a cluster environment |
| US7584378B2 (en) | 2006-09-07 | 2009-09-01 | International Business Machines Corporation | Reconfigurable FC-AL storage loops in a data storage system |
| US20080285436A1 (en) * | 2007-05-15 | 2008-11-20 | Tekelec | Methods, systems, and computer program products for providing site redundancy in a geo-diverse communications network |
| WO2009047751A2 (en) * | 2007-10-08 | 2009-04-16 | Axxana (Israel) Ltd. | Fast data recovery system |
| FR2925965B1 (fr) * | 2007-12-28 | 2009-12-18 | Bull Sas | Systeme informatique a haute disponibilite |
| WO2009141752A2 (en) * | 2008-05-19 | 2009-11-26 | Axxana (Israel) Ltd. | Resilient data storage in the presence of replication faults and rolling disasters |
| US8370679B1 (en) * | 2008-06-30 | 2013-02-05 | Symantec Corporation | Method, apparatus and system for improving failover within a high availability disaster recovery environment |
| WO2010076755A2 (en) * | 2009-01-05 | 2010-07-08 | Axxana (Israel) Ltd | Disaster-proof storage unit having transmission capabilities |
| US8112659B2 (en) | 2009-06-19 | 2012-02-07 | Oracle International Corporation | Reducing recovery time for business organizations in case of disasters |
| US9021124B2 (en) | 2009-12-02 | 2015-04-28 | Axxana (Israel) Ltd. | Distributed intelligent network |
| US20140173330A1 (en) * | 2012-12-14 | 2014-06-19 | Lsi Corporation | Split Brain Detection and Recovery System |
| US20160164871A1 (en) * | 2013-07-22 | 2016-06-09 | Kaba Ag | Fail-safe distributed access control system |
| US10769028B2 (en) | 2013-10-16 | 2020-09-08 | Axxana (Israel) Ltd. | Zero-transaction-loss recovery for database systems |
| US10102088B2 (en) * | 2013-12-25 | 2018-10-16 | Nec Solution Innovators, Ltd. | Cluster system, server device, cluster system management method, and computer-readable recording medium |
| US10379958B2 (en) | 2015-06-03 | 2019-08-13 | Axxana (Israel) Ltd. | Fast archiving for database systems |
| CN107171820B (zh) * | 2016-03-08 | 2019-12-31 | 北京京东尚科信息技术有限公司 | 信息传输、发送、获取方法和装置 |
| JP2018073231A (ja) * | 2016-11-01 | 2018-05-10 | 富士通株式会社 | ストレージシステムおよびストレージ装置 |
| US10592326B2 (en) | 2017-03-08 | 2020-03-17 | Axxana (Israel) Ltd. | Method and apparatus for data loss assessment |
Citations (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH11126168A (ja) * | 1997-10-23 | 1999-05-11 | Nec Corp | 情報処理システム |
| JPH11175488A (ja) * | 1997-12-16 | 1999-07-02 | Toshiba Corp | サーバシステムおよびフェールオーバ制御方法 |
| JP2000222373A (ja) * | 1999-01-29 | 2000-08-11 | Internatl Business Mach Corp <Ibm> | マルチクラスタ化コンピュ―タ・システムを構成及び管理する方法及び装置 |
| WO2002013033A1 (en) * | 2000-08-04 | 2002-02-14 | 3Pardata, Inc. | Data storage system |
| JP2002170173A (ja) * | 2000-12-01 | 2002-06-14 | Hitachi Mobile Co Ltd | 遠隔監視システム及び装置 |
| WO2002050678A1 (en) * | 2000-12-21 | 2002-06-27 | Legato Systems, Inc. | Method of 'split-brain' prevention in computer cluster systems |
| JP2002185478A (ja) * | 2000-12-15 | 2002-06-28 | Nec Corp | コンピュータシステムにおける共有資源の排他利用方式 |
| JP2002247035A (ja) * | 2001-02-20 | 2002-08-30 | Toshiba Tec Corp | 情報通信システム |
| JP2002312189A (ja) * | 2001-01-12 | 2002-10-25 | Hitachi Ltd | クラスターシステムにおける遠隔ミラーを使用した障害通知方法及びシステム |
Family Cites Families (24)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5356A (en) * | 1847-11-06 | Improvement in chimney-caps | ||
| US103816A (en) * | 1870-05-31 | Improvement in devices for closing the ends of coat-sleeves | ||
| US69334A (en) * | 1867-10-01 | Benedict gantner | ||
| JPH08272666A (ja) | 1995-03-31 | 1996-10-18 | Atsushi Fukumoto | データバックアップ方法と、ミラーリング装置と、その 制御方法。 |
| US5751789A (en) * | 1995-11-13 | 1998-05-12 | Bell Atlantic Network Services, Inc. | SNID with wireless backup |
| US6088659A (en) * | 1997-09-11 | 2000-07-11 | Abb Power T&D Company Inc. | Automated meter reading system |
| US6279032B1 (en) * | 1997-11-03 | 2001-08-21 | Microsoft Corporation | Method and system for quorum resource arbitration in a server cluster |
| US6317844B1 (en) * | 1998-03-10 | 2001-11-13 | Network Appliance, Inc. | File server storage arrangement |
| US6163855A (en) * | 1998-04-17 | 2000-12-19 | Microsoft Corporation | Method and system for replicated and consistent modifications in a server cluster |
| US6144999A (en) * | 1998-05-29 | 2000-11-07 | Sun Microsystems, Incorporated | Method and apparatus for file system disaster recovery |
| US6385643B1 (en) * | 1998-11-05 | 2002-05-07 | Bea Systems, Inc. | Clustered enterprise Java™ having a message passing kernel in a distributed processing system |
| GB2353111A (en) | 1999-08-07 | 2001-02-14 | Ibm | System for wireless communications between computers |
| US6859834B1 (en) * | 1999-08-13 | 2005-02-22 | Sun Microsystems, Inc. | System and method for enabling application server request failover |
| US6826580B2 (en) * | 2000-01-20 | 2004-11-30 | Emc Corporation | Distributed storage resource management in a storage area network |
| US6952737B1 (en) * | 2000-03-03 | 2005-10-04 | Intel Corporation | Method and apparatus for accessing remote storage in a distributed storage cluster architecture |
| US20020069317A1 (en) * | 2000-12-01 | 2002-06-06 | Chow Yan Chiew | E-RAID system and method of operating the same |
| US6691139B2 (en) | 2001-01-31 | 2004-02-10 | Hewlett-Packard Development Co., Ltd. | Recreation of archives at a disaster recovery site |
| US7231391B2 (en) * | 2001-02-06 | 2007-06-12 | Quest Software, Inc. | Loosely coupled database clusters with client connection fail-over |
| US6715098B2 (en) * | 2001-02-23 | 2004-03-30 | Falconstor, Inc. | System and method for fibrechannel fail-over through port spoofing |
| US20020133601A1 (en) * | 2001-03-16 | 2002-09-19 | Kennamer Walter J. | Failover of servers over which data is partitioned |
| US7028217B2 (en) | 2001-06-04 | 2006-04-11 | Lucent Technologies Inc. | System and method of general purpose data replication between mated processors |
| AU2002343424A1 (en) * | 2001-09-28 | 2003-04-14 | Bluesocket, Inc. | Method and system for managing data traffic in wireless networks |
| US7069468B1 (en) * | 2001-11-15 | 2006-06-27 | Xiotech Corporation | System and method for re-allocating storage area network resources |
| US6944788B2 (en) * | 2002-03-12 | 2005-09-13 | Sun Microsystems, Inc. | System and method for enabling failover for an application server cluster |
-
2003
- 2003-03-28 JP JP2003091265A patent/JP2004302512A/ja active Pending
- 2003-08-28 US US10/652,161 patent/US7370099B2/en not_active Expired - Fee Related
Patent Citations (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH11126168A (ja) * | 1997-10-23 | 1999-05-11 | Nec Corp | 情報処理システム |
| JPH11175488A (ja) * | 1997-12-16 | 1999-07-02 | Toshiba Corp | サーバシステムおよびフェールオーバ制御方法 |
| JP2000222373A (ja) * | 1999-01-29 | 2000-08-11 | Internatl Business Mach Corp <Ibm> | マルチクラスタ化コンピュ―タ・システムを構成及び管理する方法及び装置 |
| WO2002013033A1 (en) * | 2000-08-04 | 2002-02-14 | 3Pardata, Inc. | Data storage system |
| JP2004506267A (ja) * | 2000-08-04 | 2004-02-26 | スリーパーデータ インコーポレイテッド | データ記憶システム |
| JP2002170173A (ja) * | 2000-12-01 | 2002-06-14 | Hitachi Mobile Co Ltd | 遠隔監視システム及び装置 |
| JP2002185478A (ja) * | 2000-12-15 | 2002-06-28 | Nec Corp | コンピュータシステムにおける共有資源の排他利用方式 |
| WO2002050678A1 (en) * | 2000-12-21 | 2002-06-27 | Legato Systems, Inc. | Method of 'split-brain' prevention in computer cluster systems |
| JP2004516575A (ja) * | 2000-12-21 | 2004-06-03 | レガート システムズ インコーポレイテッド | コンピュータ・クラスタリング・システムにおいて「スプリット・ブレイン」を防止する方法 |
| JP2002312189A (ja) * | 2001-01-12 | 2002-10-25 | Hitachi Ltd | クラスターシステムにおける遠隔ミラーを使用した障害通知方法及びシステム |
| JP2002247035A (ja) * | 2001-02-20 | 2002-08-30 | Toshiba Tec Corp | 情報通信システム |
Non-Patent Citations (2)
| Title |
|---|
| 小椋 則樹 NORIKI OGURA: "クライアント／サーバシステムにおける信頼性向上の一手法 A New Approach to Improvement in the High Re", 技報 ＵＮＩＳＹＳ ＴＥＣＨＮＯＬＯＧＹ ＲＥＶＩＥＷ ＶＯＬ．１６ ＮＯ．４, vol. 第16巻第4号, JPN6008052460, 28 February 1997 (1997-02-28), pages 13 - 22, ISSN: 0001158777 * |
| 小野 哲: "Ｗｅｂの負荷分散，フェイルオーバ，ＤＢの２重化の基礎を学ぶ クラスタリング入門", ＯＰＥＮ ＤＥＳＩＧＮ 第９巻 第７号, vol. 第9巻第7号, JPN6008052465, 28 May 2002 (2002-05-28), JP, pages 12 - 23, ISSN: 0001158778 * |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2010055136A (ja) * | 2008-08-26 | 2010-03-11 | Mitsubishi Electric Corp | 通信システム及び制御装置及び制御対象装置 |
| JP2012168623A (ja) * | 2011-02-10 | 2012-09-06 | Nec Corp | 待機系計算機、クラスタシステム、サービス提供方法およびプログラム |
| US8977840B2 (en) | 2011-02-10 | 2015-03-10 | Nec Corporation | Failover to a standby system calculator in the loss of communication between currently-used system calculator and standby system calculator |
Also Published As
| Publication number | Publication date |
|---|---|
| US20050005001A1 (en) | 2005-01-06 |
| US7370099B2 (en) | 2008-05-06 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP2004302512A (ja) | クラスタコンピューティングシステム、および、そのフェールオーバー方法 | |
| US10834186B2 (en) | Disaster recovery switchover method and system, and node | |
| US6816951B2 (en) | Remote mirroring with write ordering sequence generators | |
| EP1437658B1 (en) | Coordinating persistent status information with multiple file servers | |
| KR100557399B1 (ko) | 네트웍 매체 링크상태 기능을 이용한 컴퓨터 클러스터링시스템의 가용도 개선방법 | |
| JP4387707B2 (ja) | クラスタリングシステムのサイトでの双方向障害検出の為のシステム及び方法 | |
| EP3285168B1 (en) | Disaster tolerance method and apparatus in active-active cluster system | |
| US20070288585A1 (en) | Cluster system | |
| US20060143497A1 (en) | System, method and circuit for mirroring data | |
| US20130173839A1 (en) | Switch disk array, storage system and data storage path switching method | |
| US7797571B2 (en) | System, method and circuit for mirroring data | |
| JP2004165810A (ja) | 無線ｌａｎ基地局の二重化システム | |
| US20100268687A1 (en) | Node system, server switching method, server apparatus, and data takeover method | |
| KR20020062483A (ko) | 내 고장성 시스템 및 이중화 방법 | |
| JP2006139477A (ja) | 計算機システム、管理方法及びストレージネットワークシステム | |
| KR20030048503A (ko) | 이중화 서버 구조의 데이터 동기화를 위한 통신 시스템 및방법 | |
| KR19990078536A (ko) | 지능망서비스시스템을위한데이터베이스의이중화방법 | |
| JP2006260223A (ja) | ｉＳＣＳＩストレージシステムおよびそのシステムにおけるパス多重化方法 | |
| JP3917467B2 (ja) | 電力系統監視制御システムおよびプログラム | |
| JP2006268278A (ja) | 遠隔保守コンピュータ保守システム | |
| KR20050097015A (ko) | 대형시스템에서 고장 감내 기능 구현을 위한 이중화 방법 | |
| KR100793446B1 (ko) | 이중화 통신 시스템의 페일 오버 및 원복 처리 방법 | |
| KR101397993B1 (ko) | 접속 교환 프로세서 이중화 시스템 및 방법 | |
| JP3119500B2 (ja) | 通信用バス切替方式 | |
| JP2001036510A (ja) | 制御装置の二重化方式および装置間回線二重化方式 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20051228 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20051228 |
|
| RD02 | Notification of acceptance of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7422 Effective date: 20051228 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20081021 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20081201 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20081224 |