JP3447347B2 - 障害検出方法 - Google Patents

Description

【発明の詳細な説明】 【０００１】 【産業上の利用分野】本発明は、アプリケーションプロ
グラム及び障害検出プログラムを実行する計算機を備え
た計算機システムにおいて、障害発生の有無を検出する
障害検出方法に関し、特に、ネットワークに接続され
た、複数台の計算機から構成される計算機システムの障
害検出方法に関する。 【０００２】 【従来の技術】近年、計算機システムの信頼性に対する
関心が高まってきている。その背景として、従来の計算
機システムにおいて、ダウンサイジングとよばれるよう
に汎用機上にあった機能を端末側に移行する、また、セ
ンタ機能自体をマイクロプロセッサベースの計算機上で
実現することによる低コスト化を図る試みが盛んになさ
れている。ところが、汎用機システムがハードウェアの
故障、誤動作、また、これらを要因とするソフトウェア
障害、ソフトウェア自体の障害に対してその対処手段を
持ち、より高い稼働率や信頼性を実現するのに対し、マ
イクロプロセッサベースの計算機システムでは、障害対
処手段が貧弱であり、高い稼働率や、信頼性を要求され
るアプリケーションを稼働させるのは難しかった。 【０００３】ところで、ダウンサイジングにあたって、
特徴的なこととして、計算機の接続形態の変化がある。
従来の汎用機を中心としたシステムが、その端末群と、
電話回線や、シリアルラインによってクラスタ接続され
ていたのに対し、主にほぼ等価なマイクロプロセッサベ
ースの計算機で構成されるシステムでは個々の計算機
は、高速なローカルエリアネットワークに接続されるこ
とが多くなった。 【０００４】本発明の課題である計算機システムの高い
稼働率、高信頼性を実現するために、過去に商用化され
たものとして、タンデム社、ストラタス社、セコイアシ
ステム社などによるものがある。これらのシステムは、
ハードウェアのコンポーネントを冗長化し、シングルポ
イントフェイル、つまり、ある一つのコンポーネントが
故障したためにシステム全体が停止しないようにできて
いる。しかし、ハードウェアの冗長化のため、これらシ
ステムは高価なものとなっている。 【０００５】近年のハードウェアの信頼性の向上、ま
た、要求される稼働率や信頼性のレベルにより、必ずし
も全てのコンポーネントの冗長化は、コスト面も考える
とそれを要求できない場合も多い。本発明は、かかるシ
ステムに適用され、稼働率、信頼性の向上を図るもの
で、ハードウェアの機構を最小限にとどめ、主にソフト
ウェアによる実現を図る。ハードウェアの冗長度が低い
計算機群で、これらの課題を達成するにあたって、高速
なローカルエリアネットワークが鍵となる。つまり、ハ
ードウェアの冗長度に欠けるところを、ネットワークを
通して、複数台の計算機で補い合うことでカバーする。
このようなアプローチによる製品も幾つか市場に既に出
ていて、ＤＥＣ社のＶＡＸクラスタ、ＩＢＭ社のＨＡＮ
ＦＳなどがある。ＤＥＣ社のＶＡＸクラスタと呼ばれる
製品は、デュアルポートディスクを共有する、ネットワ
ークで接続された複数台の計算機で構成され、主系の計
算機に障害が発生した時は、従系の計算機が業務を代行
する。ＩＢＭ社のＨＡＮＦＳは、同様にディスク装置を
共有するネットワークに接続された複数の計算機から構
成される計算機上で実行されており、複数の計算機間で
ファイル共有サービスを行うプログラムに障害が発生し
た時は、該サービスプログラムは、ディスク装置を共有
している他の計算機上で起動される。 【０００６】特開平４−２３０５３８には、一定時間間
隔内に応答が受信されるか否かを障害発生の判断の１つ
とした障害ソフトウェアコンポーネントの検出方法、特
開平４−３４０６４９には、検知信号の発信によらない
ソフトウェア障害の検出方法が述べられている。特開平
１−６１８５５には、マルチプロセッサシステムにおけ
るバックアッププロセッサの起動方法が述べられてい
る。 【０００７】また、障害発生時の主記憶上のデータのダ
ンプの高速化を図るものの先行事例としては、特開平３
−２１１６３８に、コアデータを圧縮した上で２次記憶
上に退避する方法が述べられている。また、ディスクデ
ータの一貫性を図るために考えられた先行特許として、
特開平１−２７７３７２では、エラー発生すると書き込
んだデータ内容を、ホストシステムに返送する方式が述
べられている。 【０００８】 【発明が解決しようとする課題】本発明の課題は、より
少ないハードウェアの投資で、高い稼働率や、信頼性を
提供する計算機システムを構築するための、基本的要素
を提供するものである。 【０００９】従来のシステムにおいて、ソフトウェア障
害検知機構がタイムアウトを、その障害発生状態か否か
を判断する基準にしている場合、計算機の負荷状態によ
っては送信のために決められた時間よりも長い時間がか
かってしまい、タイムアウトとなり、障害発生と判断さ
れ、正確な判断が下せないという問題点があった。 【００１０】また、障害検知しようとするプログラムが
幾つかのプログラムのサービスを利用して成り立ってい
るとき、あるいは、相互にサービスを利用しあって成り
立っているとき、目的とするプログラムの障害検知を行
うだけでは不十分で、正確な判断ができないという問題
点があった。 【００１１】そして、従来の障害検知方式では、検知機
構自体のシングルポイントフェイルに対応できないとい
う問題点があった。 【００１２】更に、従来の障害検知、復旧方式では、復
旧手段が一律的であり、障害に対して、必要以上の処置
をとらざるを得ない場合が多いという問題点があった。 【００１３】また、ソフトウェア障害が発生し、その復
旧にあたって、ネットワーク内の他の計算機上に移行す
る必要が生じたときに、固定的に移行先の計算機を決め
たのでは、移行先の負荷状況、資源状況によって、必ず
しも移行先として望ましいものとはならない場合がある
という問題点があった。 【００１４】より高稼働率、高信頼性システムを構築す
る上で、障害発生時になくてはならない、主記憶データ
の採取を高速に行うことも課題である。稼働率は、故障
修理期間を短くすることによって向上できる。従って、
システム再立ち上げを行う場合に、主記憶データのダン
プ時間を短くすることは、稼働率向上に寄与する。 【００１５】また、主記憶上にキャッシュされたディス
クデータの一貫性を維持することを課題としており、こ
れによりシステム再立ち上げの場合、ディスク上に構築
されたファイルシステムの一貫性回復のために要する時
間を最小に押さえることができる。 【００１６】また、データベースプログラムなどの保証
すべき信頼性が特に高いアプリケーションに利用される
べき機能で、全てのディスクに対する書き込みオペレー
ションに対し、成功か不成功かの場合に、更新後、更新
前の状態を必ず保証することにより、従来アプリケーシ
ョンプログラムの中で行っていたデータ一貫性保持操作
を簡略化し、かつ、ハードウェアレベルでデータの一貫
性を保証し、システムの高速化を図ることも課題であ
る。 【００１７】本発明は、上記のような問題点を解決し、
課題を達成するためになされたもので、より少ないハー
ドウェア開発で、より高い計算機システムの稼働率、信
頼性を実現することを目的とする。 【００１８】 【課題を解決するための手段】この発明に係る障害検出
方法は、アプリケーションプログラム及び障害検出プロ
グラムを実行する計算機を備えた計算機システムにおい
て、障害発生の有無を検出する障害検出方法であって、
上記計算機は、上記アプリケーションプログラムの実行
に際し、計算機の付加状態を示す値を定期的に採取し、
負荷情報と前記負荷情報に対応した送信頻度情報とを有
する被検側頻度表を参照して、採取された値に応じた送
信頻度を設定すると共に、前記送信頻度でメッセージを
送信し、 上記計算機は、上記障害検出プログラムの実行
に際し、計算機の負荷状態を示す値を定期的に採取し、
負荷情報と前記負荷情報に対応した障害検知頻度情報と
を有する障害検出側頻度表を参照して、採取された値に
応じた障害検知頻度を設定すると共に、上記障害検知頻
度で上記メッセージを受信しない場合に、上記アプリケ
ーションプログラムに障害が発生したと判断することを
特徴とする。 【００１９】 【００２０】 【００２１】 【００２２】 【００２３】 【００２４】 【００２５】 【００２６】 【００２７】 【００２８】 【００２９】 【００３０】 【００３１】 【作用】この発明における障害検出方法は、アプリケー
ションプログラム及び障害検出プログラムを実行する計
算機を備えた計算機システムにおいて、障害発生の有無
を検出する障害検出方法であって、上記計算機は、上記
アプリケーションプログラムの実行に際し、計算機の付
加状態を示す値を定期的に採取し、負荷情報と前記負荷
情報に対応した送信頻度情報とを有する被検側頻度表を
参照して、採取された値に応じた送信頻度を設定すると
共に、前記送信頻度でメッセージを送信し、上記計算機
は、上記障害検出プログラムの実行に際し、計算機の負
荷状態を示す値を定期的に採取し、負荷情報と前記負荷
情報に対応した障害検知頻度情報とを有する障害検出側
頻度表を参照して、採取された値に応じた障害検知頻度
を設定すると共に、上記障害検知頻度で上記メッセージ
を受信しない場合に、上記アプリケーションプログラム
に障害が発生したと判断する。このため、メッセージの
到着に要する時刻が、計算機の負荷によって遅れること
があっても、タイムアウトを障害発生か否かの判断の１
つにすることができる。 【００３２】 【００３３】 【００３４】 【００３５】 【００３６】 【００３７】 【００３８】 【００３９】 【００４０】 【００４１】 【００４２】 【００４３】 【００４４】 【実施例】 実施例１．本実施例における計算機システムの例を図１
を用いて説明する。１０３および１０４は独立した計算
機で、ネットワーク１０１，１０２にそれぞれ接続され
ている。図中には計算機は２台しか描かれていないが、
台数に制限はない。主／副形態で、機能の冗長性を実現
する場合は、主／副それぞれの計算機からアクセスでき
るディスク装置１１０により、二つの計算機間でのコン
システントなデータの引渡しを可能にする。プライマリ
ーサーバ１１１にあるプログラム群１１２，１１３，１
１４はそれぞれ依存関係を持つアプリケーションプログ
ラム、つまり、被検プログラムに相当する。１０６，１
０７，１０８は障害検出プログラムで、被検プログラム
が実行されている同一計算機上で、また、ネットワーク
内の違う計算機上で実行される。１０９は、これら障害
検知機構のセクションの開始／終了などのサービスを行
うチェックエージェントプログラムである。 【００４５】障害検知機構は、アプリケーションプログ
ラム（被検プログラム）の中で処理される部分と障害検
出プログラムの中で処理される部分に分かれて存在して
いる。図２は本実施例による障害検知機構のソフトウェ
ア構成を示している。被検プログラム２０１は、計算機
の負荷状況を調査する負荷検出部２０２と、図３にその
内容を示す負荷に対しての障害検知頻度を示す頻度表２
０３と、障害検出信号を障害検出プログラムに送出する
送信部２０４を含んでいる。一方、障害検出プログラム
は、２０２に等価な負荷検出部２０６，２０３に等しい
頻度表２０７、被検プログラムからの障害検出信号を受
信する受信部２０８を含んでいる。被検プログラム２０
１は、一定期間中に何回かの割合で送信部２０４から”
私は正常である”旨のメッセージを障害検出プログラム
２０５に送信している。障害検出プログラム２０５の受
信部２０８はそのメッセージを受け取り、その内容また
はメッセージが到着するか否かで被検プログラムが正常
であるか否かを判断している。 【００４６】そのため、ソフトウェア障害検知機構がタ
イムアウト（次のメッセージが到着すべき時刻に到着し
ない場合に異常であると判断するまでの時間）を障害発
生状態か否かを判断する基準にしているので、計算機の
負荷状態によっては、一律な判断基準では正確な判断が
下せないという問題点があった。そこで、双方のプログ
ラムは、計算機の負荷状態を定期的に採取し、その値か
ら、障害検知頻度を頻度表に従って設定する。例えば、
頻度表の内容が図３のよう場合、負荷が０のときは頻度
は１０であるから、双方のプログラムは一定期間中に１
０回障害検知のためのメッセージのやり取りを行うこと
になる。なお、負荷は計算機の稼動率とジョブキューの
長さで決まる。 【００４７】また、なぜ双方のプログラムで、負荷検出
部と頻度表を持つかを説明する。被検プログラムで、計
算機の負荷状態により送信頻度を変えているため、障害
検出プログラム側のタイムアウト値も変える必要があ
る。そのため、障害検出プログラム側でも被検プログラ
ムと同様の処理を行い、新しいタイムアウト値を設定す
る。 【００４８】被検プログラムと障害検出プログラムの中
の負荷検出部は、オペレーティングシステムの問い合わ
せ手段を用い、ジョブキューの長さと計算機の稼動率に
より得る。ただし計算機の負荷状況は急峻に変化するこ
とがあるので、双方の負荷検出値に差異が生じることを
防ぐために、負荷検出部には十分長いサンプリング期間
を持たせる。負荷状況はたえず変化するものなので、負
荷は一瞬一瞬の細かい値の検出ではなく、その時間帯の
大まかな傾向値とした方がより実際的である。 【００４９】また、被検プログラムと障害検出プログラ
ムに分けているのはプログラムの作り勝手によるため
と、独立したプログラムにすることにより、被検プログ
ラム側で検出信号を送信できない状態に陥った場合、障
害検出プログラム側ではタイムアウトを障害発生か否か
の判断の１つにするためである。 【００５０】以上のようにこの実施例では、該システム
上で走行するソフトウェアに発生する障害を検知し、障
害状態から回復せしめることを特徴とする計算機システ
ムであって、該障害検知に用いる、被検ソフトウェア自
身の送出する、検出信号の送出頻度を、該システムの負
荷状況により調整する。 【００５１】そのために計算機システムの負荷状況検出
手段、および、計算機システムの負荷状況と、障害検知
頻度の頻度表を、検知信号送信側、つまり、被検プログ
ラムと検知機構にそれぞれ持つことによって、計算機シ
ステムの負荷状況によって、障害検知頻度の調整を行う
ようにしている。 【００５２】実施例２．この実施例では、被検プログラ
ム側の障害検知信号中に、障害検知信号の送信間隔情報
（インターバル情報ともいう）を送り、それをもとに、
障害検出プログラムがタイムアウト時間を設定する例に
ついて述べる。 【００５３】図４はこの実施例の障害検知機構のソフト
ウェア構成を示している。被検プログラム４０１は、計
算機の負荷状況を調査する負荷検出部４０２と、図５に
その内容を示す負荷に対しての障害検知の頻度と、障害
検出プログラムへ送信する障害検知のインターバル情報
を示す頻度表４０３と、障害検出信号を障害検出プログ
ラムに送出する送信部４０５を含んでいる。一方、障害
検出プログラム４０６は、被検プログラムからの障害検
出信号を受信する受信部４０７を含んでいる。被検プロ
グラムは、計算機の負荷状態を定期的に採取し、その値
から頻度表に従って障害検知頻度を設定し、また、頻度
表から障害検知信号の一部として送るべき送出情報を設
定する。例えば、図５の５０１ならば、負荷が０の時は
一定期間に１０回の頻度で、被検プログラムは送出情報
１を含む障害検知信号を、障害検出プログラムに送信す
る。障害検出プログラムは、タイムアウト値を送出情報
に合わせて設定して、障害か否かの判断を行う。 【００５４】これは被検プログラムが正常か否かを障害
検出プログラムにおいて、ある一定期間内に次のメッセ
ージが到着するか否かでも判断しているためである。ま
た、被検プログラム側で負荷の状況により、頻度表を参
照して検出信号の送信間隔を変えているので、その値を
送出情報として障害検出プログラムに知らせる。これに
より障害検出プログラム側では送出情報により被検プロ
グラム側での変化に合わせてタイムアウト値の変更を行
うことができる。 【００５５】以上のようにこの実施例では、障害検出信
号に検知頻度調整のための情報を付加することを特徴と
している。 【００５６】実施例３．障害検知しようとするプログラ
ムが幾つかのプログラムのサービスを利用して成り立っ
ているとき、あるいは、相互にサービスを利用しあって
成り立っているとき、目的とするプログラムの障害検知
を行うだけでは不十分で正確な判断ができない。そのた
めこの実施例では、監視すべきプログラム、および、監
視すべきプログラムがそのサービスを利用しているプロ
グラムとのプログラム間の依存関係を示す表を、障害検
出機構に持つことにより、上記依存関係を持つプログラ
ムの監視を可能にする例について述べる。 【００５７】被検プログラム、障害検出プログラムは、
実施例１または、実施例２の機能を持つ。図６は計算機
システム上で、ある瞬間のプログラムの実行状況を示し
た図である。アプリケーションプログラムＡ（６０
２）、アプリケーションプログラムＢ（６０３）、アプ
リケーションプログラムＣ（６０１）、障害検出プログ
ラム６０４が実行されている。障害検出プログラム６０
４は、図７に詳細を示すアプリケーションプログラム間
の依存関係表６０５、各アプリケーションからの障害検
出信号を受信する受信部６０６を含んでいる。 【００５８】この依存関係表６０５は、つぎのようにし
て設定する。例えば、プログラムＡを作る時、依存する
プログラムはプログラムＢとＣであると判る。プログラ
ムＢは、プログラムＡに依存しており、またプログラム
ＡをとおしてプログラムＣに依存している。プログラム
Ｃは、どのプログラムにも依存していない。このよう
に、各プログラム間の依存関係がわかるので、障害検出
プログラムを作成するときにこれを依存関係表６０５と
して持たせる。 【００５９】図７は、アプリケーションプログラム間の
依存関係を表す依存関係表で、例えば、ＡはＣとＢに依
存しており（７０１）、ＢはＡ、ＡはさらにＣに依存し
ており（７０２）、Ｃはサービスは提供するがいずれの
プログラムにも依存していない（７０３）ことを示すも
のである。障害検出プログラム６０４は、この依存関係
表を参照し、例えばＡのプログラムをモニタする場合に
は、ＣおよびＢのプログラムの障害検知も行う。 【００６０】このようにアプリケーションプログラム間
の依存関係表を持つことにより監視すべきプログラムお
よびこのプログラムが利用するプログラムを総合的に監
視することが可能になる。 【００６１】以上のように、この実施例では、該システ
ム上で互助動作する複数のソフトウェアに発生する障害
を検知し、障害状態から回復することを目的とし、該複
数ソフトウェアの管理情報を持ち、該管理情報中に記述
される全てのソフトウェアについて、障害検出、およ
び、障害回復を行うことを特徴とする計算機システムに
ついて述べた。 【００６２】実施例４．今までの障害検知方式では、検
知機構自体のシングルポイントフェイルに対応できなか
った。この実施例では障害検知機構を２重化することに
より、障害検知機構自体の障害による、システム障害を
回避する例を説明する。 【００６３】図８は被検プログラムと障害検出プログラ
ムのソフトウェア構成を示した図である。被検プログラ
ム８０１は、障害検知信号を主障害検出プログラム８０
２、および、副障害検出プログラム８０３に送信する。
図９に副障害検出プログラムの動作を示す。もし障害が
検出されたならば（９０１）、副障害検出プログラムは
主障害検出プログラムの状態をチェックし（９０２）、
健全ならば何もしない。もし健全でなければ、障害検出
プログラム復旧（９０３）を行う。障害検出プログラム
復旧とは、副障害検出プログラムが主障害検出プログラ
ムを停止させ、副障害検出プログラムが主障害検出プロ
グラムの代わりに被検プログラムの障害に対処する。ま
た、この時副障害検出プログラムは、自分の複製を作
り、以後これに自分を監視させる。なお、当実施例にお
いて主障害検出プログラムは、副障害検出プログラムの
存在を意識しない。 【００６４】この実施例では、該システム上で走行する
ソフトウェアに発生する障害を検知し、障害状態から回
復せしめることを特徴とする計算機システムであって、
障害検知機構を２重化することにより、障害検知機構自
体の障害による、システム障害を回避することを特徴と
する計算機システムについて述べた。 【００６５】実施例５．上記実施例は１例に過ぎず、副
障害検出プログラムが、主障害検出プログラムのみを監
視する方式もある。図１０はこの実施例の被検プログラ
ムと障害検出プログラムの関係を示した図である。 【００６６】実施例６．従来の障害検知、復旧方式で
は、復旧手段が一律的であり、障害に対して、必要以上
の処置をとらざるを得ない場合が多かった。この実施例
では、被検ソフトウェアの送出する検出信号によって障
害種類を類別する障害検出機構を有し、障害種類によっ
て障害回復手順を記述した手順情報を持つこと、また、
手順情報の設定手段を持つことによって障害種類に応じ
た障害復旧手段を提供する例について述べる。 【００６７】この実施例は実施例１から５にある障害検
知機構に適用されるもので、障害検知信号に応じて、障
害復旧、もしくは、サービスを行う。図１１に、障害検
知信号と、障害検出プログラムが起動するサービスの手
順の対応を示す対応表を示す。障害検出プログラムは、
そのプログラム内にこの対応表を含み、障害検知信号を
受けとったならば、対応する手順を実行する。図１１に
ついて説明する。正常信号を受けとっている限り、障害
検出プログラムは何もしない（１００１）。停止信号を
受けとった時は、障害検出プログラムはタイムアウトを
延期する（１００２）。開始信号を受けとった時は、障
害検出プログラムは、該被検プログラムの監視を開始す
る（１００３）。終了信号を受けとった時は、被検プロ
グラムの監視を終了または、終了処理を行う（１００
４）。障害１信号を受けとった時は、同じ処理を３回リ
トライする（１００５）。障害２信号を受けとった時
は、ディスクデータを修復する（１００６）。障害３信
号を受けとった時は、他計算機で再実行する（１００
７）。 【００６８】以上のようにこの実施例では、該システム
上で走行するソフトウェアに発生する障害を検知し、障
害状態から回復せしめることを特徴とする計算機システ
ムであって、被検ソフトウェアの送出する検出信号によ
って障害種類を類別する障害検出機構を有し、障害種類
によって障害回復手順を記述した手順情報を持つことを
特徴とする計算機システムについて説明した。 【００６９】実施例７．ソフトウェア障害が発生し、そ
の復旧にあたって、ネットワーク内の他の計算機上に移
行する必要が生じた時に、固定的に移行先を決めたので
は移行先の負荷状況、資源状況によって、必ずしも移行
先として望ましいものとはならない場合があった。そこ
で、この実施例ではあるサービスが実行されていた計算
機に障害が起きた時に、ネットワーク内のどの計算機で
サービスを継続するかを決定するシステムについて述べ
る。すなわち、ネットワーク内の各計算機の負荷状況、
資源状況を表す表と、その更新手段と、起動すべきプロ
グラムと、負荷状況、および、資源状況との対応を示す
表と、負荷、資源状況の比較結果により、指定されたプ
ログラムの起動を行うことによって達成される。 【００７０】この実施例が適用される計算機システムの
例を図１を用いて説明する。１０３および１０４は独立
した計算機で、ネットワーク１０１，１０２にそれぞれ
接続されている。図中には計算機は２台しか描かれてい
ないが、台数に制限はない。主／副形態で、機能の冗長
性を実現する場合は、主／副それぞれの計算機からアク
セスできるディスク装置１１０により、二つの計算機間
でのコンシステントなデータの引渡しを可能にする。プ
ライマリーサーバ１１１にあるプログラム群１１２，１
１３，１１４はそれぞれ依存関係を持つアプリケーショ
ンプログラム、つまり、前述した実施例で述べてきた被
検プログラムに相当する。１０６，１０７，１０８は障
害検出プログラムで、被検プログラムが実行されている
同一計算機上で、また、ネットワーク内の違う計算機上
で実行される。１０９は、これら障害検知機構のセッシ
ョンの開始／終了などのサービスを行うチェックエージ
ェントプログラムである。 【００７１】もし、被検プログラムに障害が発生したと
き、さらに、計算機１０３自体が稼働不能に陥ったとき
は、スタンドバイサーバ１０５のアプリケーションプロ
グラム群は、ディスク装置１１０、または、ネットワー
クを通してディスク装置１１５のデータが複写されてい
るディスク装置１１６からデータを引き継ぎ、起動され
る。この時、これらの引き継ぎ処理を行うのは、計算機
１０４上の障害検出プログラム１０６である。 【００７２】この実施例は、あるアプリケーションプロ
グラムが実行されている計算機が稼働不能に陥ったとき
に、いずれかの計算機で再実行される時に適用されるも
ので、図１２にそのソフトウェア構成を示す。障害検出
プログラム１２０３は、ある計算機上で実行されている
被検プログラム１２０１から障害検知信号を受けとり、
また、ネットワークに接続された、各計算機の負荷、資
源状況を調査するプログラム１２０２からの状況報告を
定期的に受ける。障害検出プログラム１２０３は、被検
プログラム１２０１の実行条件データをそのプログラム
に含む。 【００７３】各計算機の負荷、資源状況を調査するプロ
グラム１２０２は、オペレーティングシステムの問い合
わせ手段を用い、各計算機の負荷、資源状況を調査す
る。計算機の負荷や資源状況は、報告を受けた時点では
変化していることもあるので、大まかな傾向がわかれば
よいと考え、十分長いサンプリング期間を持たせる。 【００７４】実行条件データの例を図１３に示す。プロ
グラムＡは、計算機の負荷が１以下で、Ｉ／Ｏ頻度が１
００以下、主記憶残が２以上というのがその実行の条件
である（１１０１）。プログラムＢは、計算機の負荷が
４以下で、Ｉ／Ｏ頻度が１０００以下、主記憶残が０．
１以上というのが、その実行の条件である（１１０
２）。一方、障害検出プログラム１２０３は、負荷、資
源状況を調査するプログラム１２０２から、図１４に示
すような情報を定期的に受ける。計算機Ａは負荷が０．
１でＩ／Ｏ頻度が１０、主記憶残が１００である（１３
０１）。計算機Ｂは負荷が２で、Ｉ／Ｏ頻度が５０、主
記憶残が１０である（１３０２）。計算機Ｃは負荷が１
で、Ｉ／Ｏ頻度が１０００、主記憶残が５０である（１
３０３）。これらの情報を照らし合わせた上で、障害検
出プログラムは、障害が発生した被検プログラムをどの
計算機上で再起動するかを決定する。例えば、図１３、
および、図１４のデータで、プログラムＡに障害が発生
したとすると、プログラムＡは計算機Ａ上で再起動され
る。 【００７５】以上のように、この実施例では、１つ、あ
るいは、複数のネットワークに、複数台接続された計算
機によって構成され、互助動作する計算機システムにお
いて、該システム上で走行するソフトウェアは、障害検
知手段により監視され、該ソフトウェアが障害状態であ
り、かつ、走行中の計算機自体に障害があった時に、ネ
ットワークリンク内の健全な他の計算機上で、該ソフト
ウェアの再起動を行うものである。そのとき、他の計算
機上で該ソフトウェアを再起動すべきとき、ネットワー
クリンク内のいずれの計算機上で起動すべきかに関する
情報をもつこと、また、該情報を生成する手段を有する
ことを特徴とする。 【００７６】実施例８．この実施例は、障害発生時の主
記憶上のデータのダンプの高速化を図る例である。主記
憶を分割し、複数のネットワークリンクを通して同時
に、複数の計算機の２次記憶上にダンプすることによ
り、処理の高速化を図る。これは、分割された主記憶領
域に対して、それぞれ、ネットワークリンク、ダンプ先
計算機、その計算機上のデータダンプ用の２次記憶領域
を登録しておくことにより、達成される。 【００７７】本実施例は、図１５にあるような複数のネ
ットワークで接続された複数計算機上で適用されるので
あるが、高速主記憶データダンプは以下のように実現さ
れる。各計算機は図１６に示すような主記憶の管理表を
それぞれ持っている。図１６は、計算機０用の管理表を
示している。０から１１までの主記憶領域は３つに分け
て管理され、０から３の領域の主記憶データは計算機０
のディスク装置０に（１４０１）、４から７の領域の主
記憶データはネットワーク０を通して、計算機１のディ
スク装置０に（１４０２）、８から１１の主記憶領域の
データはネットワーク１を通して、計算機２のディスク
装置０に（１４０３）対応づけられている。計算機に障
害が発生したときは、リセット後の計算機立ち上げ時
に、該管理表に従って主記憶データのダンプが行われ
る。また、システム機構は、図１５に示したが、図１７
に示すシステムでもよい。 【００７８】このようにして、障害発生時になくてはな
らない、主記憶データの採取を高速に行うことができ
る。また、稼働率は、故障修理期間を短くすることによ
って向上できる。従って、システム再立ち上げを行う場
合に、主記憶データのダンプ時間を短くすることは、稼
働率向上に寄与する。 【００７９】以上のように、この実施例では、複数のネ
ットワークリンクに複数台接続された計算機によって構
成され、互助動作する計算機システムにおいて、該シス
テム内のある計算機に障害が発生した時は、該計算機の
主記憶内容を、あらかじめ情報設定手段によって設定さ
れたコアダンプ情報によって分割し、定められたネット
ワークリンクを通して自身を含めた該ネットワークリン
ク内の計算機に送出することにより、退避することを特
徴とする計算機システムについて説明した。 【００８０】実施例９．この実施例は、主記憶上のバッ
ファにキャッシュされたディスクデータの一貫性を維持
することを課題としており、これはシステム再立ち上げ
の場合、ディスク上に構築されたファイルシステムの一
貫性回復のために要する時間を最小に押さえることを可
能にする。すなわち、チェックサムによる主記憶上のデ
ィスクデータを検証し、自計算機上のディスク装置、お
よび、複写されたデータを持つ他計算機のディスク装置
に、ネットワークを通して書き込みを行うことにより実
現される。 【００８１】この実施例は、図１に示すような計算機シ
ステムに適用され、１１５と１１６の関係にあるディス
ク装置が本実施例の対象である。すなわち、ディスク装
置１１５のデータは、ディスク装置１１５に対して書き
込みがあるたびにディスク装置１１６に複写される。計
算機１０３上に読み出された、ディスク装置１１５のデ
ータに対して、更新が加えられるとブロック毎にチェッ
クサムデータがとられる。 【００８２】図１８は本実施例による、計算機上のディ
スクデータの管理情報を示したものである。ドライブー
セクタとなっている項目は、正／副ディスク装置の計算
機とドライブ番号を表しており、フラグは、各バッファ
のステートを示し、チェックサムデータには、各バッフ
ァデータ更新の度にチェックサムデータが格納される。
また、図１９はステートの種類を示す図である。図１８
では、１５０１において管理されるディスクデータは計
算機Ａのディスク装置０で、データの複写先は、計算機
Ｂのディスク装置０で、第０セクタのデータが格納され
ていることを意味する。このバッファのステートはＢＵ
ＳＹでＣＰＵがデータ参照更新、もしくは、チェックサ
ムデータ計算、書き込み中である。１５０２のバッファ
は未使用である。１５０３のバッファは計算機Ａのディ
スク装置０で、データの複写先は、計算機Ｂのディスク
装置０で、第２セクタのデータが格納されている。この
バッファのステートはＤＩＲＴＹで、ディスク装置に書
き戻す必要のあるデータである。１５０４のバッファは
未使用である。 【００８３】ひとたび、この状態で、計算機１０３に相
当する計算機が障害を起こし使用不能になった時は、該
計算機をリセット後、再立ち上げの際に、該管理表に基
づき、ＢＵＳＹ、または、ＤＩＲＴＹであるバッファの
内容に対しチェックサム計算を行い、バッファの内容か
ら得られたチェックサムと管理表中のチェックサムデー
タと一致したならば、バッファ内容が正しいものとして
正／副両方のディスクにバッファの内容の書き出しを行
う。このようにして、障害発生時の主記憶上のバッファ
に読み出され変更されたデータもチェックサムにより、
データが破壊されていないことがわかれば、ディスクに
書き戻し、ディスクデータの一貫性を保つことができ
る。 【００８４】以上のように、この実施例は、１つ、ある
いは、複数のネットワークリンクに複数台接続された計
算機によって構成され、互助動作する計算機システムで
ある。該計算機システムにおいて、ディスク記憶装置上
のデータは異なる計算機上のディスク記憶装置に多重に
格納されており、データとしてファイルシステム等が構
築されており、該ディスクデータ利用時は該データは主
記憶上のバッファに展開され、主記憶上バッファのデー
タは更新時にチェックサムを実行する。そのとき、該デ
ータを利用中の計算機が障害状態となり、該計算機の停
止後、再起動時に主記憶上のバッファは展開されていた
ディスクデータで、更新済みで、かつ、チェックサムデ
ータによりデータの正当性が認められ、さらに、ディス
ク装置への書き戻しが行われていないデータを、該計算
機のディスク装置、および、データの多重化の行われて
いる他計算機のディスク装置に書き戻すことを特徴とす
るものである。 【００８５】実施例１０．本実施例はディスク装置への
書き込みの際にもしエラーが発生しても、書き込み前の
データ状態を保証するものである。エラーの要因として
は、電源断、ディスクヘッドの損傷などが有り得る。本
実施例の適用されたディスク装置は、データ書き込みを
図２０のフローチャートに示す手順で行う。書き込み要
求があれば、まず書き込み先のセクタのデータを退避す
る（１７０１）。退避先としてディスク領域を利用する
ことも、他の不揮発性記憶を利用することも可能であ
る。セクタデータは図２１に示すような形で退避され
る。すなわち、書き込み先のセクタ番号１６０１、書き
込み操作が始まったことを示すＢＥＧＩＮマーク１６０
２、そして、データ１６０３が退避される。このように
データ退避が終了したならば、データの書き込みを始
め、（１７０２）、データの更新に成功すると、１６０
４のＣＯＭＭＩＴマークを書き入れる（１７０３）。仮
に、データの退避中に障害がおきても、ディスクデータ
は保持される。また、データ更新中にエラーが発生した
場合、退避データを調べればＣＯＭＭＩＴマークのない
データはデータ更新中であるとわかるので、この退避し
たデータにより元のデータの復旧が可能になる。また、
退避データは不要になると開放する。 【００８６】以上で説明した機能は、データベースプロ
グラムなどの、保証すべき信頼性が特に高いアプリケー
ションに利用されるべき機能で、全てのディスクに対す
る書き込みオペレーションに対し成功か不成功かの場合
に、更新後、更新前の状態を必ず保証するディスク装置
である。これにより、従来、アプリケーションプログラ
ムの中で行っていたデータ一貫性保持操作が簡略化さ
れ、かつハードウェアレベルでデータ一貫性が保証され
るため、システムの高速化も期待できる。 【００８７】以上のように、この実施例では、データベ
ースプログラムなどの、厳密にデータの一貫性が要求さ
れるプログラムに利用されるディスク記憶装置におい
て、データ更新に当たって、２フェーズコミットメント
を行うことにより、データ更新時に、該ディスク記憶装
置に障害が発生しても、該更新操作前のデータを保証す
ることを特徴とする例について述べた。 【００８８】 【発明の効果】この発明の障害検出方法によれば、計算
機は、アプリケーションプログラムの実行に際し、計算
機の負荷を検出し、その負荷に応じてメッセージの送信
間隔を調整し、計算機は、障害検出プログラムの実行に
際し、計算機の負荷を検出し、その負荷に応じてメッセ
ージの受信間隔を調整する。このため、タイムアウトを
使った障害発生の判断がより正確になる。また、アプリ
ケーションプログラムを実行する計算機と障害検出プロ
グラムを実行する計算機とでそれぞれ負荷検出を行うこ
とにより、アプリケーションプログラムを実行する計算
機で送信間隔を調整することに関する障害が発生した場
合、障害検出プログラムを実行する計算機側で、アプリ
ケーションプログラムを実行する計算機側の障害の発生
を検出することができる効果がある。 【００８９】 【００９０】 【００９１】 【００９２】 【００９３】 【００９４】 【００９５】 【００９６】 【００９７】 【００９８】 【００９９】 【０１００】

【図面の簡単な説明】 【図１】本発明を適用する計算機システムの例を示す
図。 【図２】本発明を適用したソフトウェア構成例を示す
図。 【図３】本発明における頻度表例を示す図。 【図４】本発明を適用したソフトウェア構成例を示す
図。 【図５】本発明における頻度表例を示す図。 【図６】本発明を適用したソフトウェア構成例を示す
図。 【図７】本発明における依存関係表例を示す図。 【図８】本発明を適用したソフトウェア構成例を示す
図。 【図９】本発明における副障害検出プログラムの動作ア
ルゴリズムを示す図。 【図１０】本発明を適用したソフトウェア構成例を示す
図。 【図１１】本発明における障害に対する手順についての
対応表の例を示す図。 【図１２】本発明におけるソフトウェア構成例を示す
図。 【図１３】本発明における被検プログラムの実行条件デ
ータの例を表す図。 【図１４】本発明における計算機の負荷、資源状況の調
査結果の例を示す図。 【図１５】本発明を適用する計算機システムの例を示す
図。 【図１６】本発明における計算機０用の主記憶ダンプ先
の管理表を示す図。 【図１７】本発明を適用する計算機システムの例を示す
図。 【図１８】本発明における計算機上のディスクデータの
管理情報を表す図。 【図１９】本発明におけるバッファのステートの種類を
示す図。 【図２０】本発明におけるディスクデータ書き込みアル
ゴリズムを示す図。 【図２１】本発明における退避データ形態例を表す図。 【符号の説明】 １０３ 計算機（主） １０４ 計算機（副） １０５ スタンドバイサーバ １０６ 障害検出プログラム １０７ 障害検出プログラム（副） １０８ 障害検出プログラム（主） １０９ チェックエージェントプログラム １１０，１１５，１１６ ディスク装置 １１１ プライマリーサーバ １１２，１１３，１１４ 被検プログラム ２０２，２０６ 負荷検出部 ２０３，２０７ 頻度表 ２０４ 送信部 ２０８ 受信部

───────────────────────────────────────────────────── フロントページの続き (56)参考文献 特開 平４−47426（ＪＰ，Ａ) 特開 昭63−251845（ＪＰ，Ａ) 特開 平４−177547（ＪＰ，Ａ) 特開 平２−79143（ＪＰ，Ａ) 特開 昭55−78347（ＪＰ，Ａ) 実開 昭61−74141（ＪＰ，Ｕ) (58)調査した分野(Int.Cl.⁷，ＤＢ名) G06F 11/30

Claims (1)

1. (57)【特許請求の範囲】 【請求項１】 アプリケーションプログラム及び障害検
   出プログラムを実行する計算機を備えた計算機システム
   において、障害発生の有無を検出する障害検出方法であ
   って、 上記計算機は、上記アプリケーションプログラムの実行
   に際し、計算機の付加状態を示す値を定期的に採取し、
   負荷情報と前記負荷情報に対応した送信頻度情報とを有
   する被検側頻度表を参照して、採取された値に応じた送
   信頻度を設定すると共に、前記送信頻度でメッセージを
   送信し、 上記計算機は、上記障害検出プログラムの実行に際し、
   計算機の負荷状態を示す値を定期的に採取し、負荷情報
   と前記負荷情報に対応した障害検知頻度情報とを有する
   障害検出側頻度表を参照して、採取された値に応じた障
   害検知頻度を設定すると共に、上記障害検知頻度で上記
   メッセージを受信しない場合に、上記アプリケーション
   プログラムに障害が発生したと判断することを特徴とす
   る障害検出方法。