JP2002116920A - クラスタシステム、クラスタシステムにおける監視方法およびコンピュータプログラム - Google Patents
クラスタシステム、クラスタシステムにおける監視方法およびコンピュータプログラムInfo
- Publication number
- JP2002116920A JP2002116920A JP2000305970A JP2000305970A JP2002116920A JP 2002116920 A JP2002116920 A JP 2002116920A JP 2000305970 A JP2000305970 A JP 2000305970A JP 2000305970 A JP2000305970 A JP 2000305970A JP 2002116920 A JP2002116920 A JP 2002116920A
- Authority
- JP
- Japan
- Prior art keywords
- active
- standby
- failure
- cluster
- cluster management
- 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
Landscapes
- Hardware Redundancy (AREA)
- Debugging And Monitoring (AREA)
Abstract
(57)【要約】
【課題】 クラスタシステムの管理を行うプロセスと、
そのプロセスが使うリソースを外部から監視し、システ
ムの動作に関係する問題点が発見された場合に、そのシ
ステムを停止させるクラスタシステムを提供することに
ある。 【解決手段】 運用系装置および待機系装置がネットワ
ークによって接続され、互いの状況を監視するクラスタ
システムであって、運用系装置および待機系装置のそれ
ぞれに備えられ、互いの情報のやりとりにより運用系／
待機系の判断を行うクラスタ管理手段と、運用系装置で
起動されるサービスプロセス実行手段と、それぞれに備
えられたクラスタ管理手段に異常がないか否かを検出す
る障害検出手段と、障害検出手段によって障害発生を検
出したときは前記サービスプロセスの処理を停止させ、
待機系装置を稼働させる手段とを含むことを特徴とする
クラスタシステムである。
そのプロセスが使うリソースを外部から監視し、システ
ムの動作に関係する問題点が発見された場合に、そのシ
ステムを停止させるクラスタシステムを提供することに
ある。 【解決手段】 運用系装置および待機系装置がネットワ
ークによって接続され、互いの状況を監視するクラスタ
システムであって、運用系装置および待機系装置のそれ
ぞれに備えられ、互いの情報のやりとりにより運用系／
待機系の判断を行うクラスタ管理手段と、運用系装置で
起動されるサービスプロセス実行手段と、それぞれに備
えられたクラスタ管理手段に異常がないか否かを検出す
る障害検出手段と、障害検出手段によって障害発生を検
出したときは前記サービスプロセスの処理を停止させ、
待機系装置を稼働させる手段とを含むことを特徴とする
クラスタシステムである。
Description
【０００１】
【発明の属する技術分野】 本発明は、クラスタシステ
ムに関し、特にクラスタシステムにおける監視方法およ
びコンピュータプログラムに関する。
ムに関し、特にクラスタシステムにおける監視方法およ
びコンピュータプログラムに関する。
【０００２】
【従来の技術】 システムの可用性を高める構成とし
て、同一のサービスを提供できる計算機を複数台用意し
ておき、現在サービスを提供している計算機に障害が発
生した場合には、用意されている他の正常な計算機に引
き継ぐことにより、サービスが使用不能になる時間を最
小限にする、いわゆるクラスタシステムがある。特開平
３−６２２３５号公報には、各クラスタ毎に計算機ダウ
ンの監視機構を設けるダウン監視処理方式が提案されて
おり、また、特開平１０−２４７９１１号公報には、各
サーバに状態変化監視部を設け、状態変化を共用管理部
へ通知するシステム監視情報管理方法が提案されてい
る。
て、同一のサービスを提供できる計算機を複数台用意し
ておき、現在サービスを提供している計算機に障害が発
生した場合には、用意されている他の正常な計算機に引
き継ぐことにより、サービスが使用不能になる時間を最
小限にする、いわゆるクラスタシステムがある。特開平
３−６２２３５号公報には、各クラスタ毎に計算機ダウ
ンの監視機構を設けるダウン監視処理方式が提案されて
おり、また、特開平１０−２４７９１１号公報には、各
サーバに状態変化監視部を設け、状態変化を共用管理部
へ通知するシステム監視情報管理方法が提案されてい
る。
【０００３】
【発明が解決しようとする課題】 しかし、このような
従来システムにおいては、各機構が持つクラスタシステ
ムの監視を行うプロセスに異常終了、暴走、リソース障
害、高負荷によるスローダウンなどの障害が発生した場
合、他機構との情報のやり取りができなくなってしま
う。このため、各機構間で異なった情報に基づく行動を
してしまい、クラスタシステム動作の一貫性が保たれな
くなるといういわゆるスプリットブレイン現象が発生し
てしまう。本発明は前記事情に鑑みてなされたもので、
クラスタシステムの管理を行うプロセスと、そのプロセ
スが使うリソースを外部から監視して、システムの動作
に関係する問題点が発見された場合に、そのシステムを
停止させることにより、フェールセーフに且つスプリッ
トブレイン現象の発生を防止するクラスタシステムにお
ける監視方法を提供することにある。
従来システムにおいては、各機構が持つクラスタシステ
ムの監視を行うプロセスに異常終了、暴走、リソース障
害、高負荷によるスローダウンなどの障害が発生した場
合、他機構との情報のやり取りができなくなってしま
う。このため、各機構間で異なった情報に基づく行動を
してしまい、クラスタシステム動作の一貫性が保たれな
くなるといういわゆるスプリットブレイン現象が発生し
てしまう。本発明は前記事情に鑑みてなされたもので、
クラスタシステムの管理を行うプロセスと、そのプロセ
スが使うリソースを外部から監視して、システムの動作
に関係する問題点が発見された場合に、そのシステムを
停止させることにより、フェールセーフに且つスプリッ
トブレイン現象の発生を防止するクラスタシステムにお
ける監視方法を提供することにある。
【０００４】
【課題を解決するための手段】 上記課題を解決するた
めに、本発明は、運用系装置および待機系装置がネット
ワークによって接続され、互いの状況を監視するクラス
タシステムにおける監視方法であって、前記運用系装置
および前記待機系装置の稼働中、互いの情報のやりとり
により運用系／待機系の判断を行うステップと、前記運
用系装置内の障害検出を行うステップと、前記障害検出
によって障害発生を検出したときは前記運用系装置の処
理を停止させ、前記待機系装置を稼働させるステップと
を含むことを特徴とするクラスタシステムにおける監視
方法である。従って、クラスタ管理部の動作監視を、監
視部に任せることで、外側から見た客観的な監視を行う
ことができる。また、クラスタ管理部の外部にある監視
部を使用することで、クラスタ管理部が異常終了し、ク
ラスタ管理ができなくなってしまう障害を監視すること
ができる。また、どのようなプロセスであっても、異常
終了させるような不安定なシステムを外部の監視部がＯ
Ｓに対して自動的に終了させるようにするため、大規模
な異常が発生する前に、フェイルセーフにサービスを移
行で、サービスプロセスが二重に立ち上がらなくなり、
スプリットブレイン現象を防ぐことができる。
めに、本発明は、運用系装置および待機系装置がネット
ワークによって接続され、互いの状況を監視するクラス
タシステムにおける監視方法であって、前記運用系装置
および前記待機系装置の稼働中、互いの情報のやりとり
により運用系／待機系の判断を行うステップと、前記運
用系装置内の障害検出を行うステップと、前記障害検出
によって障害発生を検出したときは前記運用系装置の処
理を停止させ、前記待機系装置を稼働させるステップと
を含むことを特徴とするクラスタシステムにおける監視
方法である。従って、クラスタ管理部の動作監視を、監
視部に任せることで、外側から見た客観的な監視を行う
ことができる。また、クラスタ管理部の外部にある監視
部を使用することで、クラスタ管理部が異常終了し、ク
ラスタ管理ができなくなってしまう障害を監視すること
ができる。また、どのようなプロセスであっても、異常
終了させるような不安定なシステムを外部の監視部がＯ
Ｓに対して自動的に終了させるようにするため、大規模
な異常が発生する前に、フェイルセーフにサービスを移
行で、サービスプロセスが二重に立ち上がらなくなり、
スプリットブレイン現象を防ぐことができる。
【０００５】
【発明の実施の形態】 以下、本発明の実施の形態につ
いて図面を参照して説明する。 （第１の実施の形態）図１は、本発明に係るクラスタシ
ステムの一実施例の形態を示すブロック構成図である。
このシステムは、計算機０および計算機１がネットワー
クにより接続されているクラスタシステムであり、プロ
セスの存在を確認するものである。計算機０は、サービ
ス処理部４を動作させることにより、現時点においてサ
ービスを提供している側の運用系の計算機である。クラ
スタシステムでは、運用系計算機である計算機０が障害
を起こした場合、現在運用系として稼働している計算機
０に代わって自らが運用系となってサービスを提供でき
るよう待機系の計算機である計算機１が待機している。
クラスタシステムでは、サービス処理部４の起動、終了
などの管理は、すべてクラスタ管理部３、７が行う。ま
た、計算機０と計算機１は、クラスタ管理部３、７を共
に動作させることにより、それぞれの系情報を通信する
ことで、運用系／待機系の役割をし、クラスタシステム
を構成している。計算機０では、まず最初に、クラスタ
管理部３が起動され、待機している計算機１で起動され
たクラスタ管理部７と連携をとり、計算機０が運用系計
算機であるか、待機系計算機であるかの決定を行う。こ
こでは、計算機０が運用系であるとする。
いて図面を参照して説明する。 （第１の実施の形態）図１は、本発明に係るクラスタシ
ステムの一実施例の形態を示すブロック構成図である。
このシステムは、計算機０および計算機１がネットワー
クにより接続されているクラスタシステムであり、プロ
セスの存在を確認するものである。計算機０は、サービ
ス処理部４を動作させることにより、現時点においてサ
ービスを提供している側の運用系の計算機である。クラ
スタシステムでは、運用系計算機である計算機０が障害
を起こした場合、現在運用系として稼働している計算機
０に代わって自らが運用系となってサービスを提供でき
るよう待機系の計算機である計算機１が待機している。
クラスタシステムでは、サービス処理部４の起動、終了
などの管理は、すべてクラスタ管理部３、７が行う。ま
た、計算機０と計算機１は、クラスタ管理部３、７を共
に動作させることにより、それぞれの系情報を通信する
ことで、運用系／待機系の役割をし、クラスタシステム
を構成している。計算機０では、まず最初に、クラスタ
管理部３が起動され、待機している計算機１で起動され
たクラスタ管理部７と連携をとり、計算機０が運用系計
算機であるか、待機系計算機であるかの決定を行う。こ
こでは、計算機０が運用系であるとする。
【０００６】次に、監視部２を起動させる。監視部２
は、クラスタ管理部３が存在しているか否かの定期的な
監視を開始する。そして、計算機０は、サービス処理部
４を立ち上げサービスを行う。一方、計算機１は、クラ
スタ管理部７を立ち上げる。そして、クラスタ管理部３
からの計算機０が運用系計算機であったときは、その情
報により、クラスタ管理部７は、自分が待機系計算機だ
と判断する。次に、計算機１は監視部６を起動させる。
監視部６は、クラスタ管理部７が存在しているか否かの
定期的な監視を開始する。次に、図２を用いて監視部２
の動作を説明する。まず、監視部２は、クラスタ管理部
３が強制終了、異常状態などの予知しない原因により終
了していないか（存在しているか）の定期的な監視を開
始する（Ｓ１）。そして、クラスタ管理部３に障害が発
生しているか否かを判断する（Ｓ２）。ここで障害が発
生していないと判断された場合には、一定時間障害発生
確認（存在確認）を停止し（Ｓ３）、障害が発生してい
ると判断された場合には、機構（各系）全体を終了させ
る（Ｓ４）。監視部６についても上記と同様で、監視部
６は、クラスタ管理部７が存在しているか否かの定期的
な監視を開始する（Ｓ１）。そして、クラスタ管理部７
に障害が発生しているか否かを判断する（Ｓ２）。ここ
で障害が発生していないと判断された場合には、一定時
間障害発生確認（存在確認）を停止し（Ｓ３）、障害が
発生していると判断された場合には、機構（各系）全体
を終了させる（Ｓ４）。
は、クラスタ管理部３が存在しているか否かの定期的な
監視を開始する。そして、計算機０は、サービス処理部
４を立ち上げサービスを行う。一方、計算機１は、クラ
スタ管理部７を立ち上げる。そして、クラスタ管理部３
からの計算機０が運用系計算機であったときは、その情
報により、クラスタ管理部７は、自分が待機系計算機だ
と判断する。次に、計算機１は監視部６を起動させる。
監視部６は、クラスタ管理部７が存在しているか否かの
定期的な監視を開始する。次に、図２を用いて監視部２
の動作を説明する。まず、監視部２は、クラスタ管理部
３が強制終了、異常状態などの予知しない原因により終
了していないか（存在しているか）の定期的な監視を開
始する（Ｓ１）。そして、クラスタ管理部３に障害が発
生しているか否かを判断する（Ｓ２）。ここで障害が発
生していないと判断された場合には、一定時間障害発生
確認（存在確認）を停止し（Ｓ３）、障害が発生してい
ると判断された場合には、機構（各系）全体を終了させ
る（Ｓ４）。監視部６についても上記と同様で、監視部
６は、クラスタ管理部７が存在しているか否かの定期的
な監視を開始する（Ｓ１）。そして、クラスタ管理部７
に障害が発生しているか否かを判断する（Ｓ２）。ここ
で障害が発生していないと判断された場合には、一定時
間障害発生確認（存在確認）を停止し（Ｓ３）、障害が
発生していると判断された場合には、機構（各系）全体
を終了させる（Ｓ４）。
【０００７】従って、クラスタ管理部３、７の動作監視
を、クラスタ管理部３、７よりも負荷が低い監視部２、
６に任せることで、外側から見た客観的な監視を行うこ
とができる。また、クラスタ管理部３、７の外部にある
監視部２、６を使用することで、クラスタ管理部３、７
が異常終了し、クラスタ管理ができなくなってしまう障
害を監視することができる。また、定期的な外部からの
監視を行うことによって、クラスタ管理部３、７の異常
終了がわかる。つまり、どのようなプロセスであって
も、異常終了させるようなシステムは不安定である。そ
れを外部の監視部がＯＳに対して自動的に終了させるよ
うにするため、大規模な異常が発生する前に、フェイル
セーフにサービスを移行できる。さらに、計算機０のク
ラスタ管理部３が監視部２により存在しないと判断され
た場合、機構の動作を終了させることで、クラスタシス
テムによって管理できていない計算機０のサービスプロ
セスの動作を停止させることができる。これにより、ク
ラスタ管理部７は、クラスタ管理部３が存在しないこと
がわかり、計算機１を運用系計算機として立ち上げる。
そして、計算機１内に、サービス処理部４と同様のサー
ビス部を立ち上げる。このことにより、サービスプロセ
スが二重に立ち上がらなくなり、スプリットブレイン現
象を防ぐことができる。
を、クラスタ管理部３、７よりも負荷が低い監視部２、
６に任せることで、外側から見た客観的な監視を行うこ
とができる。また、クラスタ管理部３、７の外部にある
監視部２、６を使用することで、クラスタ管理部３、７
が異常終了し、クラスタ管理ができなくなってしまう障
害を監視することができる。また、定期的な外部からの
監視を行うことによって、クラスタ管理部３、７の異常
終了がわかる。つまり、どのようなプロセスであって
も、異常終了させるようなシステムは不安定である。そ
れを外部の監視部がＯＳに対して自動的に終了させるよ
うにするため、大規模な異常が発生する前に、フェイル
セーフにサービスを移行できる。さらに、計算機０のク
ラスタ管理部３が監視部２により存在しないと判断され
た場合、機構の動作を終了させることで、クラスタシス
テムによって管理できていない計算機０のサービスプロ
セスの動作を停止させることができる。これにより、ク
ラスタ管理部７は、クラスタ管理部３が存在しないこと
がわかり、計算機１を運用系計算機として立ち上げる。
そして、計算機１内に、サービス処理部４と同様のサー
ビス部を立ち上げる。このことにより、サービスプロセ
スが二重に立ち上がらなくなり、スプリットブレイン現
象を防ぐことができる。
【０００８】（第２の実施の形態）図３は、本発明に係
るクラスタシステムの他の実施例の形態を示すブロック
構成図である。ここで、ＯＳ管理情報部１２、１７は、
機構を制御するオペレーションシステムが持つ管理情報
である。このＯＳ管理情報部１２、１７は、各プロセス
を起動させるために必要な全ての情報「プロセス情報」
を持つ。また、クラスタ管理部１６は、クラスタ管理部
のプロセス情報１３に対応付けられており、クラスタ管
理部１９は、クラスタ管理部のプロセス情報１８に対応
付けられている。また、計算機１０のクラスタ管理部１
６と、計算機１１のクラスタ管理部１９は、ネットワー
クを通じて特定のパケットを定期的に送受信しており、
一定時間内にパケットが相手系から受信された場合、相
手系が正常に動作していると認識する。この通信を、ハ
ートビートの送受信という。計算機１０では、まず、ク
ラスタ管理部１６が起動され、同時にＯＳ管理情報部１
２の中にクラスタ管理プロセスの処理情報１３が生成さ
れる。次に、クラスタ管理部１６は、クラスタ管理部１
９と連絡を取り合い（ハートビートの送受信を行い）自
分が運用系か、待機系かを決定する。ここでは、計算機
１０が運用系であるとする。
るクラスタシステムの他の実施例の形態を示すブロック
構成図である。ここで、ＯＳ管理情報部１２、１７は、
機構を制御するオペレーションシステムが持つ管理情報
である。このＯＳ管理情報部１２、１７は、各プロセス
を起動させるために必要な全ての情報「プロセス情報」
を持つ。また、クラスタ管理部１６は、クラスタ管理部
のプロセス情報１３に対応付けられており、クラスタ管
理部１９は、クラスタ管理部のプロセス情報１８に対応
付けられている。また、計算機１０のクラスタ管理部１
６と、計算機１１のクラスタ管理部１９は、ネットワー
クを通じて特定のパケットを定期的に送受信しており、
一定時間内にパケットが相手系から受信された場合、相
手系が正常に動作していると認識する。この通信を、ハ
ートビートの送受信という。計算機１０では、まず、ク
ラスタ管理部１６が起動され、同時にＯＳ管理情報部１
２の中にクラスタ管理プロセスの処理情報１３が生成さ
れる。次に、クラスタ管理部１６は、クラスタ管理部１
９と連絡を取り合い（ハートビートの送受信を行い）自
分が運用系か、待機系かを決定する。ここでは、計算機
１０が運用系であるとする。
【０００９】次に、クラスタ管理部１６の起動後、クラ
スタ管理部１６の実行優先度よりも監視部１５の方が優
先度が高くなるように監視部１５を起動する。次に、ク
ラスタ管理部１６は、サービス処理部１４を起動する。
一方、計算機１１は、クラスタ管理部１９を起動すると
同時に、ＯＳ管理情報部１７の中にクラスタ管理プロセ
スのプロセス情報１８を生成する。次に、監視部２０を
起動し、定期的な監視を行う。次に、図４を用いて監視
部１５の動作を説明する。まず、監視部１５は、クラス
タ管理部１６よりも優先度が高くなるように設定する
（Ｓ１１）。次に、現在時刻をＯＳから取得しＡとする
（Ｓ１２）。次に、監視部１５は、クラスタ管理プロセ
スのプロセス情報１８の情報を参照して、プロセス／ス
レッドの最終時刻をＯＳから取得しＢとする（Ｓ１
３）。次に、ＡとＢの差を算出する（Ｓ１４）。ここ
で、所定のしきい値と前述の差を比較し、しきい値の方
が小さい場合には、一定時間障害発生確認（存在確認）
を停止し（Ｓ１６）、しきい値の方が大きい場合には、
機構（各系）全体を終了させる（Ｓ１７）。監視部２０
についても同様で、監視部２０をクラスタ管理部１９よ
りも優先度が高くなるように設定する（Ｓ１１）。次
に、現在時刻をＯＳから取得しＡとする（Ｓ１２）。次
に、監視部２０は、クラスタ管理プロセスのプロセス情
報１８の情報を参照して、処理／スレッドの最終時刻を
ＯＳから取得しＢとする（Ｓ１３）。次に、ＡとＢの差
を算出する（Ｓ１４）。ここで、所定のしきい値と前述
の差を比較し、しきい値の方が小さい場合には、一定時
間障害発生確認（存在確認）を停止し（Ｓ１６）、しき
い値の方が大きい場合には、機構（各系）全体を終了さ
せる（Ｓ１７）。
スタ管理部１６の実行優先度よりも監視部１５の方が優
先度が高くなるように監視部１５を起動する。次に、ク
ラスタ管理部１６は、サービス処理部１４を起動する。
一方、計算機１１は、クラスタ管理部１９を起動すると
同時に、ＯＳ管理情報部１７の中にクラスタ管理プロセ
スのプロセス情報１８を生成する。次に、監視部２０を
起動し、定期的な監視を行う。次に、図４を用いて監視
部１５の動作を説明する。まず、監視部１５は、クラス
タ管理部１６よりも優先度が高くなるように設定する
（Ｓ１１）。次に、現在時刻をＯＳから取得しＡとする
（Ｓ１２）。次に、監視部１５は、クラスタ管理プロセ
スのプロセス情報１８の情報を参照して、プロセス／ス
レッドの最終時刻をＯＳから取得しＢとする（Ｓ１
３）。次に、ＡとＢの差を算出する（Ｓ１４）。ここ
で、所定のしきい値と前述の差を比較し、しきい値の方
が小さい場合には、一定時間障害発生確認（存在確認）
を停止し（Ｓ１６）、しきい値の方が大きい場合には、
機構（各系）全体を終了させる（Ｓ１７）。監視部２０
についても同様で、監視部２０をクラスタ管理部１９よ
りも優先度が高くなるように設定する（Ｓ１１）。次
に、現在時刻をＯＳから取得しＡとする（Ｓ１２）。次
に、監視部２０は、クラスタ管理プロセスのプロセス情
報１８の情報を参照して、処理／スレッドの最終時刻を
ＯＳから取得しＢとする（Ｓ１３）。次に、ＡとＢの差
を算出する（Ｓ１４）。ここで、所定のしきい値と前述
の差を比較し、しきい値の方が小さい場合には、一定時
間障害発生確認（存在確認）を停止し（Ｓ１６）、しき
い値の方が大きい場合には、機構（各系）全体を終了さ
せる（Ｓ１７）。
【００１０】従って、クラスタ管理部１６のプロセス／
スレッド最終動作時間と所定のしきい値を比較すること
により、クラスタ管理部１６が使用しているリソースの
障害による極端なスローダウンを監視でき、それにより
不安定な機構をフェイルセーフにシステムを停止、再起
動等行うことで、未然にクラスタシステムの不正動作を
防ぐことができる。また、クラスタ管理プロセスの動作
監視を、クラスタ管理プロセスよりも軽快でクラスタ管
理プロセスのプロセス優先度以上の監視専用プログラム
にさせることにより、クラスタ管理プロセスよりもスロ
ーダウンに強くなり、クラスタ管理プロセスのスローダ
ウン監視を行うことができる。さらにまた、運用系の計
算機０がもつプロセス全てがスローダウン状態になった
場合、待機系の計算機１がハートビートを送出しなくな
ったと認識してサービス処理を起動した際にはスプリッ
トブレイン現象が発生するが、スローダウン状態から復
帰した際には処理優先度が比較的高い専用の監視プロセ
スが機構全体を停止させてくれるため、スプリットブレ
イン現象が発生している時間を最少にすることができ
る。 （第３の実施の形態）図５は、本発明に係るクラスタシ
ステムの他の実施例の形態を示すブロック構成図であ
る。
スレッド最終動作時間と所定のしきい値を比較すること
により、クラスタ管理部１６が使用しているリソースの
障害による極端なスローダウンを監視でき、それにより
不安定な機構をフェイルセーフにシステムを停止、再起
動等行うことで、未然にクラスタシステムの不正動作を
防ぐことができる。また、クラスタ管理プロセスの動作
監視を、クラスタ管理プロセスよりも軽快でクラスタ管
理プロセスのプロセス優先度以上の監視専用プログラム
にさせることにより、クラスタ管理プロセスよりもスロ
ーダウンに強くなり、クラスタ管理プロセスのスローダ
ウン監視を行うことができる。さらにまた、運用系の計
算機０がもつプロセス全てがスローダウン状態になった
場合、待機系の計算機１がハートビートを送出しなくな
ったと認識してサービス処理を起動した際にはスプリッ
トブレイン現象が発生するが、スローダウン状態から復
帰した際には処理優先度が比較的高い専用の監視プロセ
スが機構全体を停止させてくれるため、スプリットブレ
イン現象が発生している時間を最少にすることができ
る。 （第３の実施の形態）図５は、本発明に係るクラスタシ
ステムの他の実施例の形態を示すブロック構成図であ
る。
【００１１】ここで、ディスクＩＯキューとは、ディス
クへの書き込み要求を並べているものである。計算機３
０では、まず、クラスタ管理部３６が起動される。次
に、監視部４４が起動される。そして、クラスタ管理部
４３は、クラスタ管理部３６と通信を行い、計算機１が
待機系の計算機であることを決定する。次に、クラスタ
管理部３６は、自分の動き、行動情報をディスク３４に
書込むために、ＯＳに対して書込み要求を行いＯＳがＯ
ＳのＩＯキュー３２に対して、キューイングする。次
に、ＯＳは、ディスクＩＯキュー３２により、書込み要
求３３がある場合、ディスク３４に対して書込みを行
う。また、クラスタ管理部３６の起動後、監視部３７が
起動される。クラスタ管理部３６とクラスタ管理部４３
は、互いに通信を行い、運用系か待機系かを決定する。
ここで、計算機３０が運用系とする。そして、運用系と
なったのクラスタ管理部３６は、サービス処理部３８を
生成する。一方、待機系計算機３１は、クラスタ管理部
４３を起動する。クラスタ管理部４３は、自分の動作、
行動の情報をディスク４１への書込むためにＯＳに対し
て書込み要求を行い、ＯＳがＯＳのＩＯキュー３９に対
しキューイングする。
クへの書き込み要求を並べているものである。計算機３
０では、まず、クラスタ管理部３６が起動される。次
に、監視部４４が起動される。そして、クラスタ管理部
４３は、クラスタ管理部３６と通信を行い、計算機１が
待機系の計算機であることを決定する。次に、クラスタ
管理部３６は、自分の動き、行動情報をディスク３４に
書込むために、ＯＳに対して書込み要求を行いＯＳがＯ
ＳのＩＯキュー３２に対して、キューイングする。次
に、ＯＳは、ディスクＩＯキュー３２により、書込み要
求３３がある場合、ディスク３４に対して書込みを行
う。また、クラスタ管理部３６の起動後、監視部３７が
起動される。クラスタ管理部３６とクラスタ管理部４３
は、互いに通信を行い、運用系か待機系かを決定する。
ここで、計算機３０が運用系とする。そして、運用系と
なったのクラスタ管理部３６は、サービス処理部３８を
生成する。一方、待機系計算機３１は、クラスタ管理部
４３を起動する。クラスタ管理部４３は、自分の動作、
行動の情報をディスク４１への書込むためにＯＳに対し
て書込み要求を行い、ＯＳがＯＳのＩＯキュー３９に対
しキューイングする。
【００１２】次に、図６を用いてファイル書込動作を説
明する。まず、監視部３７は、監視部３７が持つ所定の
しきい値にしたがって、タイマ設定を行う（Ｓ３１）。
次に、監視部３７は、ディスク３４に対して同期を用い
た書込要求をＯＳに対し行う（Ｓ３２）。次に、ＯＳは
ＯＳのディスクＩＯキュー３２に監視部３７から受け取
った書込要求をキューイングする（Ｓ３３）。次に、タ
イマ設定された時間が終了した後、その時点で書込要求
が終了しているか否か判断する（Ｓ３４）。ここで、書
込要求が終了されていなければ、一定時間障害発生確認
（存在確認）を停止し（Ｓ３５）、書込要求が終了され
ていれば、機構（各系）全体を終了させる（Ｓ３６）。
一方、非同期書込みの場合には、監視部３７は、現在処
理中の書込要求がいくつあるかをカウントし（Ｓ４
１）、書込要求数が監視部３７の持っているしきい値を
越えているかの判断を行う（Ｓ４２）。ここで、しきい
値を越えていない時は、非同期を用いて書込み（Ｓ４
３）、一定時間障害発生確認（存在確認）を停止し（Ｓ
４４）、しきい値を越えている場合には、機構（各系）
全体を終了させる（Ｓ４５）。従って、クラスタ管理プ
ロセスの外部にクラスタ管理プロセスの使用するディス
クを監視するプロセスを作ることで、クラスタ管理プロ
セスの処理にアラームやシグナルなどの複雑な処理を持
つ必要が無くなる。
明する。まず、監視部３７は、監視部３７が持つ所定の
しきい値にしたがって、タイマ設定を行う（Ｓ３１）。
次に、監視部３７は、ディスク３４に対して同期を用い
た書込要求をＯＳに対し行う（Ｓ３２）。次に、ＯＳは
ＯＳのディスクＩＯキュー３２に監視部３７から受け取
った書込要求をキューイングする（Ｓ３３）。次に、タ
イマ設定された時間が終了した後、その時点で書込要求
が終了しているか否か判断する（Ｓ３４）。ここで、書
込要求が終了されていなければ、一定時間障害発生確認
（存在確認）を停止し（Ｓ３５）、書込要求が終了され
ていれば、機構（各系）全体を終了させる（Ｓ３６）。
一方、非同期書込みの場合には、監視部３７は、現在処
理中の書込要求がいくつあるかをカウントし（Ｓ４
１）、書込要求数が監視部３７の持っているしきい値を
越えているかの判断を行う（Ｓ４２）。ここで、しきい
値を越えていない時は、非同期を用いて書込み（Ｓ４
３）、一定時間障害発生確認（存在確認）を停止し（Ｓ
４４）、しきい値を越えている場合には、機構（各系）
全体を終了させる（Ｓ４５）。従って、クラスタ管理プ
ロセスの外部にクラスタ管理プロセスの使用するディス
クを監視するプロセスを作ることで、クラスタ管理プロ
セスの処理にアラームやシグナルなどの複雑な処理を持
つ必要が無くなる。
【００１３】また、クラスタ管理プロセスと関係ない独
立した監視部がディスクチェックすることで、クラスタ
管理プロセスが書込要求のためにロックした場合であっ
ても、客観的にクラスタシステムの制御を行うことがで
きる。また、ディスク監視プロセスが、定期的にクラス
タ管理プロセスが使用するディスクを監視することで、
ディスクの不調・故障などによるリトライなどを事前に
察知することができ、未然にフェールセーフに機構を停
止することができる。 （第４の実施の形態）図７は、本発明に係るクラスタシ
ステムの他の実施例の形態を示すブロック構成図であ
る。監視部５３は、クラスタ管理部５２に問題が生じて
いないか確認をとり、監視部５７は、クラスタ管理部５
６に問題が生じていないか確認をとり、お互い通信し合
っている。計算機５０は、旧運用系の計算機であり、ス
プリットブレイン現象が発生したために停止すべきはず
であるが、停止していない系である。計算機５０で障害
発生が起きると、計算機５４は、その障害を発見し、自
ら運用系計算機になることを決定する。次に、クラスタ
管理部５６は、計算機５４が運用系計算機になったた
め、クラスタ管理部５６を起動させる。このことによ
り、スプリットブレイン現象が発生してしまっていた。
立した監視部がディスクチェックすることで、クラスタ
管理プロセスが書込要求のためにロックした場合であっ
ても、客観的にクラスタシステムの制御を行うことがで
きる。また、ディスク監視プロセスが、定期的にクラス
タ管理プロセスが使用するディスクを監視することで、
ディスクの不調・故障などによるリトライなどを事前に
察知することができ、未然にフェールセーフに機構を停
止することができる。 （第４の実施の形態）図７は、本発明に係るクラスタシ
ステムの他の実施例の形態を示すブロック構成図であ
る。監視部５３は、クラスタ管理部５２に問題が生じて
いないか確認をとり、監視部５７は、クラスタ管理部５
６に問題が生じていないか確認をとり、お互い通信し合
っている。計算機５０は、旧運用系の計算機であり、ス
プリットブレイン現象が発生したために停止すべきはず
であるが、停止していない系である。計算機５０で障害
発生が起きると、計算機５４は、その障害を発見し、自
ら運用系計算機になることを決定する。次に、クラスタ
管理部５６は、計算機５４が運用系計算機になったた
め、クラスタ管理部５６を起動させる。このことによ
り、スプリットブレイン現象が発生してしまっていた。
【００１４】監視部５３、５７は、自機構内にサービス
処理部５１、５５が動作している場合、いつサービス処
理部５１，５５が起動されたかという情報を、定期的に
他の機構に対してネットワークを用いて伝達している。
自系がサービス処理部５１、５５を起動している場合
に、他の監視プロセス５３、５７から情報を受け取った
時に、その情報と自系のサービス処理部５１、５５の起
動時刻と比較して、それより新しい情報を受け取ってい
た場合には、機構全体を終了する。従って、外部にスプ
リットブレイン現象が起きていないかを監視する機構を
置くことで、クラスタ管理プロセスがが自浄できないよ
うなスプリットブレインを起こす場合でも、フェールセ
ーフに旧運用系を停止させることができるため、クラス
タシステム内で２つサービスが立ち上がっているような
状況を防ぐことができる。 （第５の実施の形態）図８は、本発明に係るクラスタシ
ステムの他の実施例の形態を示すブロック構成図であ
る。このシステムは、運用系計算機０および待機系計算
機１がネットワークにより接続されているクラスタシス
テムである。ここで、サービス制御部６６、７２は、ク
ラスタ管理部Ａ６２、クラスタ管理部Ｂ６３、．．．、
クラスタ管理部Ｎ６４、クラスタ管理部Ａ６８、クラス
タ管理部Ｂ６９、．．．、クラスタ管理部Ｎ７０が制御
するサービス処理部６７の起動・終了などの処理を実際
に行うプロセスである。
処理部５１、５５が動作している場合、いつサービス処
理部５１，５５が起動されたかという情報を、定期的に
他の機構に対してネットワークを用いて伝達している。
自系がサービス処理部５１、５５を起動している場合
に、他の監視プロセス５３、５７から情報を受け取った
時に、その情報と自系のサービス処理部５１、５５の起
動時刻と比較して、それより新しい情報を受け取ってい
た場合には、機構全体を終了する。従って、外部にスプ
リットブレイン現象が起きていないかを監視する機構を
置くことで、クラスタ管理プロセスがが自浄できないよ
うなスプリットブレインを起こす場合でも、フェールセ
ーフに旧運用系を停止させることができるため、クラス
タシステム内で２つサービスが立ち上がっているような
状況を防ぐことができる。 （第５の実施の形態）図８は、本発明に係るクラスタシ
ステムの他の実施例の形態を示すブロック構成図であ
る。このシステムは、運用系計算機０および待機系計算
機１がネットワークにより接続されているクラスタシス
テムである。ここで、サービス制御部６６、７２は、ク
ラスタ管理部Ａ６２、クラスタ管理部Ｂ６３、．．．、
クラスタ管理部Ｎ６４、クラスタ管理部Ａ６８、クラス
タ管理部Ｂ６９、．．．、クラスタ管理部Ｎ７０が制御
するサービス処理部６７の起動・終了などの処理を実際
に行うプロセスである。
【００１５】計算機６０は、まず最初に、クラスタ管理
部Ａ６２、クラスタ管理部Ｂ６３、．．．、クラスタ管
理部Ｎ６４のうち複数のクラスタ管理部を起動させる。
クラスタ管理部Ａ６２、クラスタ管理部Ｂ６
３、．．．、クラスタ管理部Ｎ６４は、それぞれ、計算
機６１のクラスタ管理部Ａ６８、クラスタ管理部Ｂ６
９、．．．、クラスタ管理部Ｎ７０と連携をとり、自分
が運用系計算機であるか、待機系計算機であるかの決定
を行う。ここで計算機６０が運用系計算機とする。ここ
で、クラスタ管理部Ａ６２、クラスタ管理部Ｂ６
３、．．．、クラスタ管理部Ｎ６４は、それぞれ共に同
じ動作を行う。次に、監視部６５は、クラスタ管理部Ａ
６２、クラスタ管理部Ｂ６３、．．．、クラスタ管理部
Ｎ６４の外部に与える要求がすべて同じか否かを確認す
る。監視部６５は、複数のクラスタ管理部Ａ６２、クラ
スタ管理部Ｂ６３、．．．、クラスタ管理部Ｎ６４が発
行する実動作命令を比較し、もし違う動作指示を行うプ
ロセスが存在した場合には、異常が発生したものと認識
して機構全体を停止させる。一方、もし同じ動作指示で
あった場合には、その実動差命令をサービス制御部６６
に渡す。
部Ａ６２、クラスタ管理部Ｂ６３、．．．、クラスタ管
理部Ｎ６４のうち複数のクラスタ管理部を起動させる。
クラスタ管理部Ａ６２、クラスタ管理部Ｂ６
３、．．．、クラスタ管理部Ｎ６４は、それぞれ、計算
機６１のクラスタ管理部Ａ６８、クラスタ管理部Ｂ６
９、．．．、クラスタ管理部Ｎ７０と連携をとり、自分
が運用系計算機であるか、待機系計算機であるかの決定
を行う。ここで計算機６０が運用系計算機とする。ここ
で、クラスタ管理部Ａ６２、クラスタ管理部Ｂ６
３、．．．、クラスタ管理部Ｎ６４は、それぞれ共に同
じ動作を行う。次に、監視部６５は、クラスタ管理部Ａ
６２、クラスタ管理部Ｂ６３、．．．、クラスタ管理部
Ｎ６４の外部に与える要求がすべて同じか否かを確認す
る。監視部６５は、複数のクラスタ管理部Ａ６２、クラ
スタ管理部Ｂ６３、．．．、クラスタ管理部Ｎ６４が発
行する実動作命令を比較し、もし違う動作指示を行うプ
ロセスが存在した場合には、異常が発生したものと認識
して機構全体を停止させる。一方、もし同じ動作指示で
あった場合には、その実動差命令をサービス制御部６６
に渡す。
【００１６】サービス処理部６７は、全てのクラスタ管
理部Ａ６２、クラスタ管理部Ｂ６３、．．．、クラスタ
管理部Ｎ６４がサービス処理部６７を起動させるように
監視部６５に対し命令を行った場合、監視部６５はサー
ビス制御部６６に対しサービス処理部６７を生成するよ
う要求する。サービス制御部６６は、要求に従い、サー
ビス処理部６７を生成する。一方、待機系である計算機
６１は、クラスタ管理部Ａ６８、クラスタ管理部Ｂ６
９、．．．、クラスタ管理部Ｎ７０を起動する。クラス
タ管理部Ａ６８、クラスタ管理部Ｂ６９、．．．、クラ
スタ管理部Ｎ７０は、クラスタ管理部Ａ６２、クラスタ
管理部Ｂ６３、．．．、クラスタ管理部Ｎ６４と通信を
し、待機を決定する。監視部７１は、クラスタ管理部Ａ
６８、クラスタ管理部Ｂ６９、．．．、クラスタ管理部
Ｎ７０の行動が同じか否かを監視する。次に、図９を用
いて監視部６５の動作を説明する。まず、クラスタ管理
部Ａ６２、クラスタ管理部Ｂ６３、．．．、クラスタ管
理部Ｎ６４は、それぞれ外部に対する要求を出す（Ｓ５
０１〜Ｓ５０３）。次に、監視部６５は、この要求が全
て同じか否かを確認する（Ｓ５１）。そして、全て同じ
であれば、監視部６５はサービス制御部６６に対してサ
ービス処理部６７を生成するよう要求する。そして、一
定時間障害発生確認（存在確認）を停止する（Ｓ５３）
一方、Ｓ５１における要求が１つでも異なれば、機構
（各系）全体を終了させる。（Ｓ５４）。
理部Ａ６２、クラスタ管理部Ｂ６３、．．．、クラスタ
管理部Ｎ６４がサービス処理部６７を起動させるように
監視部６５に対し命令を行った場合、監視部６５はサー
ビス制御部６６に対しサービス処理部６７を生成するよ
う要求する。サービス制御部６６は、要求に従い、サー
ビス処理部６７を生成する。一方、待機系である計算機
６１は、クラスタ管理部Ａ６８、クラスタ管理部Ｂ６
９、．．．、クラスタ管理部Ｎ７０を起動する。クラス
タ管理部Ａ６８、クラスタ管理部Ｂ６９、．．．、クラ
スタ管理部Ｎ７０は、クラスタ管理部Ａ６２、クラスタ
管理部Ｂ６３、．．．、クラスタ管理部Ｎ６４と通信を
し、待機を決定する。監視部７１は、クラスタ管理部Ａ
６８、クラスタ管理部Ｂ６９、．．．、クラスタ管理部
Ｎ７０の行動が同じか否かを監視する。次に、図９を用
いて監視部６５の動作を説明する。まず、クラスタ管理
部Ａ６２、クラスタ管理部Ｂ６３、．．．、クラスタ管
理部Ｎ６４は、それぞれ外部に対する要求を出す（Ｓ５
０１〜Ｓ５０３）。次に、監視部６５は、この要求が全
て同じか否かを確認する（Ｓ５１）。そして、全て同じ
であれば、監視部６５はサービス制御部６６に対してサ
ービス処理部６７を生成するよう要求する。そして、一
定時間障害発生確認（存在確認）を停止する（Ｓ５３）
一方、Ｓ５１における要求が１つでも異なれば、機構
（各系）全体を終了させる。（Ｓ５４）。
【００１７】従って、外部の客観的な監視プロセスを用
いて、複数のクラスタ管理ソフトの動作を監視すること
で、クラスタ管理処理自体の不正動作を監視できる。次
に、図１０を用いて監視部６５の他の動作を説明する。
まず、クラスタ管理部Ａ６２、クラスタ管理部Ｂ６
３、．．．、クラスタ管理部Ｎ６４は、それぞれ外部に
対する要求を出す（Ｓ６０１〜Ｓ６０３）。次に、監視
部６５は、この要求の多数意見を確認する（Ｓ６１）。
そして、その要求の多数意見についての処理を実行監視
部６５はサービス制御部６６に対してサービス処理部６
７を生成するよう要求する（Ｓ６２）。そして、一定時
間障害発生確認（存在確認）を停止する（Ｓ６３）。一
方、Ｓ６１における要求のうち少数意見については、そ
のプロセスを停止する（Ｓ６４）。従って、外部の客観
的な監視プロセスを用いて、複数のクラスタ管理ソフト
の動作を監視することで、クラスタ管理処理自体の不正
動作を監視できる。その他、本発明はその要旨を逸脱し
ない範囲で種々変形して実施できる。
いて、複数のクラスタ管理ソフトの動作を監視すること
で、クラスタ管理処理自体の不正動作を監視できる。次
に、図１０を用いて監視部６５の他の動作を説明する。
まず、クラスタ管理部Ａ６２、クラスタ管理部Ｂ６
３、．．．、クラスタ管理部Ｎ６４は、それぞれ外部に
対する要求を出す（Ｓ６０１〜Ｓ６０３）。次に、監視
部６５は、この要求の多数意見を確認する（Ｓ６１）。
そして、その要求の多数意見についての処理を実行監視
部６５はサービス制御部６６に対してサービス処理部６
７を生成するよう要求する（Ｓ６２）。そして、一定時
間障害発生確認（存在確認）を停止する（Ｓ６３）。一
方、Ｓ６１における要求のうち少数意見については、そ
のプロセスを停止する（Ｓ６４）。従って、外部の客観
的な監視プロセスを用いて、複数のクラスタ管理ソフト
の動作を監視することで、クラスタ管理処理自体の不正
動作を監視できる。その他、本発明はその要旨を逸脱し
ない範囲で種々変形して実施できる。
【発明の効果】 クラスタシステムの管理を行うプロセ
スと、そのプロセスが使うリソースを外部から監視し
て、システムの動作に関係する問題点が発見された場合
に、そのシステムを停止させることにより、フェールセ
ーフに且つスプリットブレイン現象の発生を防止するこ
とができる。
スと、そのプロセスが使うリソースを外部から監視し
て、システムの動作に関係する問題点が発見された場合
に、そのシステムを停止させることにより、フェールセ
ーフに且つスプリットブレイン現象の発生を防止するこ
とができる。
【図１】本発明に係るクラスタシステムの一実施例の形
態を説明する図。
態を説明する図。
【図２】図１に示すクラスタシステムの監視プロセスの
流れを説明する図。
流れを説明する図。
【図３】本発明に係るクラスタシステムの他の実施例の
形態を説明する図。
形態を説明する図。
【図４】図３に示すクラスタシステムの監視プロセスの
流れを説明する図。
流れを説明する図。
【図５】本発明に係るクラスタシステムの他の実施例の
形態を説明する図。
形態を説明する図。
【図６】図５に示すクラスタシステムの監視プロセスの
流れを説明する図。
流れを説明する図。
【図７】本発明に係るクラスタシステムの他の実施例の
形態を説明する図。
形態を説明する図。
【図８】本発明に係るクラスタシステムの他の実施例の
形態を説明する図。
形態を説明する図。
【図９】図８に示すクラスタシステムの監視プロセスの
流れを説明する図。
流れを説明する図。
【図１０】図８に示すクラスタシステムの監視プロセス
の流れを説明する図。
の流れを説明する図。
１、１０、３０、５０、６０…運用系計算機 ２、１１、３１、５４、６１…待機系計算機 ３、６、１５、２０、３７、４４、５３、５７、６５、
７１…監視部 ４、７、１６、１９、３６、４４、５２、５６…クラス
タ管理部 ５、１４、３８、５１、５５、６７…サービス処理部
７１…監視部 ４、７、１６、１９、３６、４４、５２、５６…クラス
タ管理部 ５、１４、３８、５１、５５、６７…サービス処理部
Claims (10)
- 【請求項１】 運用系装置および待機系装置がネットワ
ークによって接続され、互いの状況を監視するクラスタ
システムにおける監視方法であって、 前記運用系装置および前記待機系装置の稼働中、互いの
情報のやりとりにより運用系／待機系の判断を行うステ
ップと、 前記運用系装置内の障害検出を行うステップと、 前記障害検出によって障害発生を検出したときは前記運
用系装置の処理を停止させ、前記待機系装置を稼働させ
るステップとを含むことを特徴とするクラスタシステム
における監視方法。 - 【請求項２】 前記運用系装置内の障害検出を行うステ
ップは、プロセスの存在の有無により障害検出すること
を特徴とする請求項１記載のクラスタシステムにおける
監視方法。 - 【請求項３】 前記運用系装置内の障害検出を行うステ
ップは、プロセス／スレッドの動作間隔により障害検出
することを特徴とする請求項１記載のクラスタシステム
における監視方法。 - 【請求項４】 前記運用系装置内の障害検出を行うステ
ップは、前記運用系／待機系の判断を行うステップより
も優先度を高くすることを特徴とする請求項３記載のク
ラスタシステムにおける監視方法。 - 【請求項５】 前記運用系装置内の障害検出を行うステ
ップは、 前記運用系装置および前記待機系装置にて起動されるサ
ービスプロセスの動作時刻により障害検出することを特
徴とする請求項１記載のクラスタシステムにおける監視
方法。 - 【請求項６】 運用系装置および待機系装置がネットワ
ークによって接続され、互いの状況を監視するクラスタ
システムにおける監視方法であって、 前記運用系装置および前記待機系装置の稼働中、互いの
情報のやりとりの動作履歴を残すと共に運用系／待機系
の判断を行うステップと、 前記運用系装置内の障害検出を前記履歴を用いて行うス
テップと、 前記障害検出によって障害発生を検出したときは前記運
用系装置の処理を停止させ、前記待機系装置を稼働させ
るステップとを含むことを特徴とするクラスタシステム
における監視方法。 - 【請求項７】 運用系装置および待機系装置がネットワ
ークによって接続され、互いの状況を監視するクラスタ
システムにおける監視方法であって、 前記運用系装置および前記待機系装置の稼働中、互いの
複数の情報のやりとりにより運用系／待機系の判断を行
うステップと、 前記互いの複数の情報の一致の度合いにより前記運用系
装置内の障害検出を行うステップと、 前記障害検出によって障害発生を検出したときは前記運
用系装置の処理を停止させ、前記待機系装置を稼働させ
るステップとを含むことを特徴とするクラスタシステム
における監視方法。 - 【請求項８】 運用系装置および待機系装置がネットワ
ークによって接続され、互いの状況を監視するクラスタ
システムであって、 前記運用系装置および前記待機系装置のそれぞれに備え
られ、互いの情報のやりとりにより運用系／待機系の判
断を行うクラスタ管理手段と、 前記運用系装置で起動されるサービスプロセス実行手段
と、 前記それぞれに備えられたクラスタ管理手段に異常がな
いか否かを検出する障害検出手段と、 前記障害検出手段によって障害発生を検出したときは前
記サービスプロセスの処理を停止させ、前記待機系装置
を稼働させる手段とを含むことを特徴とするクラスタシ
ステム。 - 【請求項９】 運用系装置および待機系装置がネットワ
ークによって接続され、互いの状況を監視するコンピュ
ータプログラムであって、 前記運用系装置および前記待機系装置の稼働中、互いの
情報のやりとりにより運用系／待機系の判断を行う機能
と、 前記運用系装置内の障害検出を行う機能と、 前記障害検出によって障害発生を検出したときは前記運
用系装置の処理を停止させ、前記待機系装置を稼働させ
る機能とを実現させるコンピュータプログラム。 - 【請求項１０】 運用系装置および待機系装置がネット
ワークによって接続され、互いの状況を監視するコンピ
ュータプログラムであって、 前記運用系装置および前記待機系装置の稼働中、互いの
複数の情報のやりとりにより運用系／待機系の判断を行
う機能と、 前記互いの複数の情報の一致の度合いにより前記運用系
装置内の障害検出を行う機能と、 前記障害検出によって障害発生を検出したときは前記運
用系装置の処理を停止させ、前記待機系装置を稼働させ
る機能とを実現させるコンピュータプログラム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000305970A JP2002116920A (ja) | 2000-10-05 | 2000-10-05 | クラスタシステム、クラスタシステムにおける監視方法およびコンピュータプログラム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000305970A JP2002116920A (ja) | 2000-10-05 | 2000-10-05 | クラスタシステム、クラスタシステムにおける監視方法およびコンピュータプログラム |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2002116920A true JP2002116920A (ja) | 2002-04-19 |
Family
ID=18786734
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000305970A Pending JP2002116920A (ja) | 2000-10-05 | 2000-10-05 | クラスタシステム、クラスタシステムにおける監視方法およびコンピュータプログラム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2002116920A (ja) |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7263036B2 (en) | 2002-05-27 | 2007-08-28 | Nec Corporation | Time correction system in cluster system |
| JP2009080704A (ja) * | 2007-09-26 | 2009-04-16 | Toshiba Corp | 仮想計算機システム及び同システムにおけるサービス引き継ぎ制御方法 |
| JP2010044781A (ja) * | 2003-01-02 | 2010-02-25 | Fisher Rosemount Syst Inc | アプリケーションステーションで利用される冗長マネージャ |
| JP2015523644A (ja) * | 2012-05-30 | 2015-08-13 | シマンテック コーポレーションＳｙｍａｎｔｅｃ Ｃｏｒｐｏｒａｔｉｏｎ | 多層構成アプリケーションの災害復旧のためのシステム及び方法 |
| JP2020194217A (ja) * | 2019-05-24 | 2020-12-03 | アズビル株式会社 | 冗長システム及びデータ同期方法 |
| JP7209784B1 (ja) | 2021-08-23 | 2023-01-20 | 三菱電機株式会社 | 冗長化システム及び冗長化方法 |
-
2000
- 2000-10-05 JP JP2000305970A patent/JP2002116920A/ja active Pending
Cited By (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7263036B2 (en) | 2002-05-27 | 2007-08-28 | Nec Corporation | Time correction system in cluster system |
| JP2010044781A (ja) * | 2003-01-02 | 2010-02-25 | Fisher Rosemount Syst Inc | アプリケーションステーションで利用される冗長マネージャ |
| JP2009080704A (ja) * | 2007-09-26 | 2009-04-16 | Toshiba Corp | 仮想計算機システム及び同システムにおけるサービス引き継ぎ制御方法 |
| JP2015523644A (ja) * | 2012-05-30 | 2015-08-13 | シマンテック コーポレーションＳｙｍａｎｔｅｃ Ｃｏｒｐｏｒａｔｉｏｎ | 多層構成アプリケーションの災害復旧のためのシステム及び方法 |
| JP2020194217A (ja) * | 2019-05-24 | 2020-12-03 | アズビル株式会社 | 冗長システム及びデータ同期方法 |
| JP7422492B2 (ja) | 2019-05-24 | 2024-01-26 | アズビル株式会社 | 冗長システム及びデータ同期方法 |
| JP7209784B1 (ja) | 2021-08-23 | 2023-01-20 | 三菱電機株式会社 | 冗長化システム及び冗長化方法 |
| JP2023030364A (ja) * | 2021-08-23 | 2023-03-08 | 三菱電機株式会社 | 冗長化システム及び冗長化方法 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7418627B2 (en) | Cluster system wherein failover reset signals are sent from nodes according to their priority | |
| KR100557399B1 (ko) | 네트웍 매체 링크상태 기능을 이용한 컴퓨터 클러스터링시스템의 가용도 개선방법 | |
| JP4505763B2 (ja) | ノードクラスタの管理 | |
| KR100358663B1 (ko) | 클러스터 노드 디스트레스 신호 | |
| JP4695705B2 (ja) | クラスタシステムおよびノード切り替え方法 | |
| US7925922B2 (en) | Failover method and system for a computer system having clustering configuration | |
| JPH03164837A (ja) | 通信制御処理装置の切替方法 | |
| US20040177242A1 (en) | Dynamic computer system reset architecture | |
| TW200426571A (en) | Policy-based response to system errors occurring during os runtime | |
| JP2002116920A (ja) | クラスタシステム、クラスタシステムにおける監視方法およびコンピュータプログラム | |
| WO2019227839A1 (zh) | 一种基于bmc的文件传输方法、装置、设备及介质 | |
| JP2009026182A (ja) | プログラム実行システム及び実行装置 | |
| JPH10116261A (ja) | 並列計算機システムのチェックポイントリスタート方法 | |
| JP3266841B2 (ja) | 通信制御装置 | |
| JPH1196033A (ja) | 情報処理装置 | |
| JPH10171769A (ja) | 複合計算機システム | |
| KR102517831B1 (ko) | 미션 크리티컬 시스템 환경에서의 소프트웨어 관리방법 및 그 시스템 | |
| JP3812434B2 (ja) | ヘルスチエック方式 | |
| JPH02310755A (ja) | ヘルスチェック方式 | |
| JP6368842B2 (ja) | プロセス監視プログラム及びプロセス監視システム | |
| JP2885583B2 (ja) | 通信手順制御システム | |
| JPH11232143A (ja) | マルチスレッドの監視方法 | |
| JPH08329023A (ja) | 並列電子計算機システム | |
| KR20170041557A (ko) | 가상 시스템에서 장애 조치를 판단하는 장치 및 그 방법 | |
| JP2000295259A (ja) | Ｌａｎ異常検出装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050131 |
|
| A711 | Notification of change in applicant |
Free format text: JAPANESE INTERMEDIATE CODE: A712 Effective date: 20050322 |
|
| A711 | Notification of change in applicant |
Free format text: JAPANESE INTERMEDIATE CODE: A711 Effective date: 20050328 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20060830 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060926 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20061124 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20070807 |