JP3290052B2 - ソフトウエア故障回復のための再使用可能なソフトウエアモジュールを持つプログレッシブ再試行法及び装置 - Google Patents

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、一般的には、メッセー
ジパシング用途において使用されるためのソフトウエア
の故障をバイパスするためのシステム、より詳細には、
ソフトウエアの故障の回復の範囲をソフトウエアの故障
がバイパスされるまで徐々に増加させるプログレッシブ
再試行法に基づいてバイパスするための方法と装置に関
する。

【０００２】

【従来の技術】ソフトウエアアプリケーションの利用者
は、そのソフトウエアが故障に対して耐性であることを
ますます要求するようになっている。より具体的には、
ユーザは、故障耐性の二つの要素、つまり、そのアプリ
ケーションソフトウエアの利用性とデータの一貫性の問
題に関心を持っている。例えば、電話通信交換システム
のユーザは、交換システムが継続して利用できることを
要求する。ただし、金融取引を巻き込む伝送、例えば、
銀行テラーマシンに対しては、顧客は、最高水準のデー
タの一貫性についても要求する。

【０００３】ただし、複数の平行プロセスを実行する分
散システムにおいては、メッセージと計算が互いに入り
込み、処理が複雑で、時間に依存する性質があるため
に、ソフトウエアデバッギングの際にいくら検証、確
認、テストを行なったとしても、全てのソフトウエアの
故障を検出及び排除し、そのアプリケーションの利用性
とデータの一貫性に完全な信頼性を与えることは不可能
といえる。従って、テストされなかった境界条件、予期
されなかった例外及び予期されなかった実行環境に起因
する残留故障が、テスト及びデバッギングプロセスを逃
れ、プログラム実行の際にトリガされたとき、本性を現
し、アプリケーションプロセスをクラッシュ或はハング
させ、結果として、サービスを中断させる事態が観察さ
れる。

【０００４】

【発明が解決しようとする課題】従って、これら残留す
るソフトウエアの故障を自動的に検出及びバイパスし、
ソフトウエアの故障からの回復を許す効果的なオンライ
ン再試行メカニズムを開発することが要望される。多く
の研究は、生産システム内での多くのソフトウエアの故
障が過渡的な振る舞いを見せることを示す。従って、こ
のような過渡的なソフトウエアの故障から回復するため
の最も簡単な方法として、異なる条件下でそのアプリケ
ーションプロセスを再開し、こうして同一のプロセスを
実行することが知られている。このアプローチは、通
常、環境多様性と称される。ただし、あるシステムの再
開は、通常、包括的な初期化手続きを必要とし、従っ
て、潜在的にかなり多量のサービスの中断を要求する。

【０００５】現在、システムの再開に伴って失われる時
間の損失を最小にするために、過渡的なハードウエア故
障からより効率的に回復することを目的とした多数のチ
ェックポイント及びロールバック回復技法が提案されて
いる。チェックポイント及びロールバック回復技法の一
般的な議論に関しては、R.Koo 及びS.Toueg によって、
IEEE Trans. Software Eng.、 Vol. SE-13、 No.1、pp.23-
31 (Jan. 1987)に掲載の論文『Checkpointing and Roll
back-Recovery for Distributed Systems 』を参照され
たい。概略すると、チェックポイントとは、あるアプリ
ケーションプロセスと関連するデータの定期的なバック
アップコピーであり、この技法は、アプリケーションプ
ロセスがバックアップメモリデバイス内に格納されたこ
のチェックポイントから再開することを許す。

【０００６】ただし、過渡的なソフトウエア故障から回
復することを目的としたチェックポイント及びロールバ
ック回復技法については、殆ど提案されてないのが実情
である。ここでは、以前に過渡的なハードウエア故障に
対して開発されたロールバック技法を、ソフトウエア故
障をバイパスするためにメッセージの再プレイ及びメッ
セージの並べ替えを利用してソフトウエアエラーから回
復するためにも使用することが提示される。

【０００７】上の議論から明らかなように、最初は、よ
り迅速な回復を達成するためにロールバックにおいて巻
き込まれるプロセスの数及び全ロールバック距離を含む
ロールバックの範囲を最小に押えて過渡的なソフトウエ
ア故障をバイパスするタイプのプログレッシブ再試行シ
ステムが要望される。さらに、前の再試行の試みが失敗
した場合、各再試行ステップ毎にロールバック距離と影
響を受けるプロセスの数を漸進的に増大させ、こうし
て、非決定論的想定の程度を徐々に増大させるタイプの
回復システムが要望される。

【０００８】

【課題を解決するための手段】概説すると、本発明の一
面によると、メッセージパシングメカニズムを介して通
信する複数の平行アプリケーションプロセスを監視する
ための故障耐性（許容）計算システムが提供される。こ
の故障耐性計算システムは、アプリケーションプロセス
をクラッシュ或はハングさせる原因となるそのアプリケ
ーションプロセス内の故障（障害）を検出する。その
後、故障耐性計算システムは、プログレッシブ再試行回
復アルゴリズムを利用してアプリケーションプロセスの
回復を開始するが、このアルゴリズムは、前の再試行ス
テップが検出された故障をバイパスすることに失敗する
と、回復の範囲を徐々に増大させる。

【０００９】本発明のもう一面によると、この故障回復
計算システムは、アプリケーションプロセスを監視する
ための少なくとも一つのウォッチドッグを含む。加え
て、このウォッチドッグは、検出された故障をバイパス
することを試みる回復アルゴリズムを実行するための再
開サブシステムを含む。

【００１０】本発明の一面によると、あるアプリケーシ
ョンプロセスは、故障耐性ライブラリからの適当なファ
ンクションをそのアプリケーションプロセスのコード内
に挿入することによって故障耐性にされる。好ましく
は、この故障耐性ライブラリは、所定の間隔でウォッチ
ドッグに関連するプロセスがまだアクティブであること
を示すハートビートメッセージを送信するハートビート
ファンクションを含む。ウォッチドッグがそのアプリケ
ーションプロセスから所定の間隔が終る前に次の信号を
受信しない場合は、ウォッチドッグは、そのアプリケー
ションプロセスがハング或はクラッシュしたものと見な
す。

【００１１】加えて、故障耐性ライブラリは、あるアプ
リケーションプロセス内のクリティカルデータを指定す
ることを許すクリティカルメモリファンクションを含
む。加えて、故障耐性ライブラリには、指定されたクリ
ティカルデータをチェックポイントファンクションがア
プリケーションプロセスに対して実行される度に不揮発
性メモリの領域にコピーするチェックポイントファンク
ションが提供される。故障耐性ライブラリは、好ましく
は、さらに、あるアプリケーションプロセスが回復モー
ドにおいて不揮発性メモリからチェックポイントデータ
を回復することを可能にする回復ファンクションを含
む。

【００１２】故障回復ライブラリは、好ましくは、さら
に、各出力メッセージをセンダログファイル内にそのメ
ッセージがそのアプリケーションプロセスによって伝送
される前に登録するための故障耐性書込みファンクショ
ンftwrite を含む。あるアプリケーションプロセスが通
常のモードにあるときは、この書込みファンクション
は、メッセージを他のプロセスに送信し、メッセージが
送信される度にセンダログファイル内にこの情報を加え
る。

【００１３】回復状態においては、登録されたメッセー
ジを処理した後に、この書込みファンクションは、各新
たに生成されたメッセージをセンダログファイル内の対
応するメッセージと比較することによって、ピースワイ
ズ決定論的想定の検証を行う。回復において生成された
メッセージが前の実行の際にセンダログファイル内に格
納されたメッセージと同一である場合は、そのメッセー
ジは、再伝送する必要はない。ただし、これらメッセー
ジが同一でない場合は、非決定論的な事象が発生した証
拠であり、回復の範囲を増大することが要求される。

【００１４】故障耐性ライブラリは、好ましくは、さら
に、入力メッセージをレシーバログファイル内にそれら
が受信アプリケーションプロセスによって処理される前
に登録するための故障耐性読出しファンクションftread
を含む。あるアプリケーションプロセスが通常のモード
にあるときは、読出しファンクションは、通信チャネル
からデータを読出し、受信されたメッセージをレシーバ
ログファイル内に登録する。

【００１５】回復状態においては、入力データがレシー
バログファイルから回復ラインの所まで読出され、その
後、データが正規の入力チャネルから読出される。一つ
の好ましい実施例においては、読出しファンクション
は、各受信されたメッセージと関連する送信プロセスの
チェックポイント間隔番号をチェックし、その送信プロ
セスのチェックポイント間隔番号が受信プロセスの現在
のチェックポイント間隔番号より大きい場合は関連する
受信アプリケーションプロセスのチェックポイント動作
を開始し、これによって、大域的に一貫性のあるチェッ
クポイントを確保する。加えて、調節されたチェックポ
イントスキームにおいては、読出しファンクションがチ
ェックポイント制御メッセージを受信すると、読出しフ
ァンクションは、アプリケーションプロセスのチェック
ポイント化動作を開始する。

【００１６】各アプリケーションプロセスによって受信
されたメッセージのメッセージログ内への登録動作は、
結果として、（上記のチェックポイント）確保状態期間
の終端において“論理”チェックポイントを設定するこ
ととなるが、これは、回復において他のプロセスを巻き
込む傾向を持つロールバック伝播のドミノ効果を最小に
する機能を果たす。

【００１７】本発明のもう一面によると、ロールバック
伝播アルゴリズムが提供されるが、これは、監視下のプ
ロセスに対して破棄されてない最後の実チェックポイン
ト或は論理チェックポイントの所の回復ラインを計算す
ることによって回復の範囲を最小にする。

【００１８】本発明のもう一面によると、メッセージロ
グ内のメッセージは回復モードにおいて以下のように分
類される。つまり、関連するプロセスによってその最後
の実チェックポイントから計算された回復ラインまでの
間に受信及び処理されたメッセージは、決定論的メッセ
ージとして分類され、一方、メッセージログ内の計算さ
れた回復ラインの前に送信されたが回復ラインの後に受
信されたメッセージは過渡メッセージと称される。メッ
セージログ内の他の全てのメッセージは、回復モードに
おいては破棄される。

【００１９】本発明のさらにもう一面によると、本発明
の原理を具現するプログレッシブ再試行アルゴリズムが
あるアプリケーションプロセス内に故障が検出されると
この故障したプロセスの回復を試みるために実行され
る。このプログレッシブ再試行アルゴリズムは、回復に
巻き込まれるプロセスの数及び総合ロールバック距離を
含めた回復の範囲を最小にする。プログレッシブ再試行
アルゴリズムは、その後のステップに、前のステップが
検出された故障をバイパスすることに失敗したときにの
み進む。プログレッシブ再試行アルゴリズムは、以下の
ステップ：つまり、レシーバ再プレイ、レシーバ並べ替
え、センダ再プレイ、センダ並べ替え、及び大域的に一
貫性のあるチェックポイントへの広範囲ロールバック、
から構成される。本発明の一層の理解並びに本発明のそ
の他の特徴及び長所については、以下の詳細な説明と図
面を参照にすることによって得られるものである。

【００２０】

【実施例】図１には本発明に従う故障耐性計算システム
５が示される。後に詳細に説明されるように、故障耐性
計算システム５は、メッセージパシングメカニズムを介
して通信を行なう複数の平行アプリケーションプロセス
を監視するための設備を提供する。故障耐性計算システ
ム５はアプリケーションプロセスをクラッシュ或はハン
グさせるアプリケーションプロセス内の故障を検出す
る。すると、故障耐性計算システム５はアプリケーショ
ンプロセスの回復を開始する。本発明の一面によると、
前の再試行ステップが失敗すると次第に回復の範囲を増
大させて行くプログレッシブ再試行回復アルゴリズムが
利用される。

【００２１】故障耐性計算システム５は、複数のプロセ
スを実行する単一のノードから成る環境内で実現するこ
とも、或は別の方法として、図１に示されるように、各
々が一つ或はそれ以上のプロセスを実行する相互に接続
された複数のノードから成る環境内で実現することもで
きる。注目すべき点として、多重ノード環境の自然な冗
長は、多重ノード動作と称されるセクションにおいて後
に詳細に説明されるように、あるノードのハードウエア
或はオペレーティングシステムの故障を検出及び回復す
るための向上されたメカニズムを提供する。ここでは、
後に説明の方法によって、あるノード上の故障耐性プロ
セスが別のノード上で再開できる場合は、このプロセス
は、第一のノード上のハードウエア及びオペレーティン
グシステムの故障に耐える。

【００２２】システムアーキテクチュア 図１に示されるように、ここに開示される故障耐性計算
システム５の一つの好ましい実施例は、複数の処理ノー
ド、例えば、ノード１０と１２を含む。別の方法とし
て、故障耐性計算システム５は、周知の方法によってタ
イムシェアリングメカニズムを実現することによって複
数の平行プロセスを実行できる能力を持つ単一の処理ユ
ニットを持つ単一のノードから構成することもできる。

【００２３】各ノード、例えば、ノード１０と１２は、
少なくとも一つの処理ユニット、例えば、処理ユニット
５０、５２、５４、及びメモリユニット、例えば、メモ
リユニット５５、５７から成るワークステーション或は
他の汎用計算デバイスとして実現することができる。別
の方法として、一つ或はそれ以上の処理ノード、例え
ば、ノード１０と１２を専用のプログラム制御プロセッ
サ、例えば、電話通信スイッチとして実現することもで
きる。

【００２４】一つの実施例においては、故障耐性計算シ
ステム５内の一つ或は複数のノード、例えば、ノード１
０が複数の平行プロセスを実行する能力を持つ平行処理
ワークステーションとして実現される。各処理ユニット
５０、５２、５４は、平行プロセス、例えば、プロセス
Ｐ₀ からＰ_N 及びＰ_A を実行する。あるノード、例え
ば、ノード１０が複数のプロセッサ、例えば、プロセッ
サ５０と５２を含む場合は、各プロセッサは、それ自身
の専用のメモリユニットを持つことも、或は、図１に示
されるように、共通のメモリユニット５５を同一ノード
１０内の他のプロセッサと共有することもできる。各ノ
ード、例えば、ノード１０と１２のメモリユニット５５
は、典型的には、揮発性メモリ４０、４２の領域と不揮
発性メモリ４４、４６の領域を含む。一つの好ましい実
施例においては、各プロセスは、図１に示されるよう
に、メモリユニット５５内に揮発性メモリと不揮発性メ
モリの別個に位置された領域、例えば、プロセスＰ_o に
対するメモリ領域４０、４４を持つ。周知のように、揮
発性メモリは、連続的なパワーなしには情報を保持する
ことができない安定でないメモリの領域である。

【００２５】各プロセスと関連する揮発性メモリ領域４
０は、好ましくは、各々のアプリケーションプロセスと
関連するソフトウエアコードを格納するためのセクショ
ン８０を含む。あるアプリケーションプロセスと関連す
るコードセクション８０は、典型的には、アプリケーシ
ョンコード８１とアプリケーションコードによって呼び
出される故障耐性ライブラリファンクション８２を含
む。故障耐性ライブラリファンクション８２は、故障耐
性ライブラリファンクションと称されるセクションにお
いて後に説明されるように、高水準プログラミング言
語、例えば、Ｃプログラミング言語にて書かれたユーザ
レベルライブラリファンクションである。故障耐性ライ
ブラリファンクション８２は、本発明の一面に従って、
あるアプリケーションプロセス内でそのプロセス内の故
障耐性を実現するために使用される。一つの好ましい実
施例においては、故障耐性ライブラリ８２からルーチン
を呼び出すアプリケーションコードは、編集の際にこう
して呼び出されたファンクションと一緒に束ねられる。

【００２６】加えて、各プロセスと関連する揮発性メモ
リ領域４０は、各々のアプリケーションプロセスと関連
するデータを格納するためのデータセクション８４を含
む。後に説明される一つの好ましい実施例においては、
故障耐性ライブラリ８２は、クリティカルメモリファン
クションを含む。これは、ユーザがアプリケーションプ
ロセスと関連するあるデータをクリティカルなデータで
あると指定することを可能にする。このクリティカルな
データは、好ましくは、故障耐性計算システム５によっ
て、クリティカルメモリ５８の領域内に格納される。ユ
ーザによってクリティカルなデータであると指定されな
いアプリケーションプロセス内のデータは、非クリティ
カルメモリ８６の領域内に格納される。

【００２７】後に詳細に説明される本発明の一面による
と、故障耐性ライブラリ８２は、チェックポイントファ
ンクションを含む。これは、アプリケーションプロセス
によって呼び出されると、揮発性メモリ４０からのユー
ザによって指定されたクリティカルなデータ８５のコピ
ーを、パワーが存在しないときにも情報を保持すること
ができる安定なメモリデバイスである不揮発性メモリ４
４の領域８８内に格納する。不揮発性メモリ４４は、メ
モリユニット５５の一部分とすることも、或は遠隔ファ
イルシステムであってもよい。多重ノード環境において
は、クリティカルメモリコピー８８は、好ましくは、後
に説明されるように、主ノードに加えて、バックアップ
ノード上に保存される。

【００２８】本発明のさらにもう一面によると、故障耐
性計算システム５によってメッセージログが各プロセス
によって送受されるメッセージに関する情報、例えば、
各メッセージの内容のコピーと、各メッセージがアプリ
ケーションプロセスによって処理された順番に関する情
報を格納するために維持される。一つの好ましい実施例
においては、後にそれぞれ図５ａと５ｂとの関連で説明
されるレシーバログファイル９０とセンダファイル９２
が、各プロセスに対して、それぞれ関連するプロセスに
よって受信或は送信されたメッセージに関する情報を格
納するために別個に維持される。

【００２９】一つの好ましい実施例においては、大域一
貫性チェックポイント確定の各成功において、中央回復
コーディネータ７５は、全てのプロセスに対して、新た
なレシーバ及びセンダファイル９０、９２を開くことを
要求するメッセージを同報通信する。この方法によっ
て、各アプリケーションプロセスに対する現在のレシー
バ及びセンダファイル９０、９２は、最後の大域一貫性
チェックポイント以降の関連するアプリケーションプロ
セスによって受信されたメッセージに関する情報のみを
格納することとなる。

【００３０】後に詳細に説明されるように、あるアプリ
ケーションプロセス内で故障が検出された場合、ログに
基づく回復が本発明に従って実行されるが、これは、故
障プロセスをクリティカルメモリコピー８８内に格納さ
れた最後のチェックポイントから再開し、次に、最後の
チェックポイント以降に送信或は受信されたメッセージ
ログ９０、９２からのメッセージを再プレイし、故障が
検出されたポイントまでのプロセス状態を再生すること
によって実現される。

【００３１】個々のノード、例えば、ノード１０の処理
ユニット５０、５２及びメモリユニット５５は、周知の
方法にてノード内通信のためにバス６０或はローカルノ
ード上のプロセス間通信（ＩＣＰ）設備によって相互接
続される。これに加えて、各ノード１０、１２は、他の
ノード及び中央回復コーディネータ７５と、後に説明さ
れるように、ノード間通信のために、周知の方法にて、
通信網６５とデータリンク６７−７１を介して相互接続
される。

【００３２】図１に示されるように、各ノード、例え
ば、ノード１０は、ウォッチドッグ１５を持つが、これ
は、各々のノード上で実行しているプロセスを監視する
ためのエラー検出モニタ２０を含む。ウォッチドッグ１
５は、図４ａとの関連で後に詳細に説明される故障耐性
プロセスリスト２５を維持する。これは、ウォッチドッ
グ１５によって監視されるべき各々のノード１０上で実
行しているプロセスをリストする。

【００３３】ウォッチドッグ１５のエラー検出モニタ２
０は、故障耐性プロセスリスト２５内にリストされた各
アプリケーションプロセス、例えば、プロセスＰ₀ を絶
え間なく監視し、そのプロセスがハング或はクラッシュ
したか調べる。エラー検出モニタ２０によって遂行され
る監視は、能動的であっても受動的であってもよい。能
動的な監視構成においては、ウォッチドッグ１５は、各
監視されるアプリケーションプロセスをポリーングし、
その状態を決定する。これはそのプロセスにローカルノ
ード１０上のプロセス間通信（ＩＣＰ）設備を使用して
メッセージを送り、返された値を評価することによっ
て、そのプロセスがまだアクティブであるか決定するこ
とによって行なわれる。

【００３４】受動的な監視構成においては、各アプリケ
ーションプロセスは、後に説明される故障耐性ライブラ
リ８２からのファンクションを含む。これは、関連する
プロセスがまだアクティブであることを示すハートビー
トメッセージを所定の間隔でウォッチドッグ１５に送
る。ウォッチドッグ１５が所定の間隔が終了するまでに
アプリケーションプロセスからの次の信号を受信しない
場合は、ウォッチドッグ１５は、アプリケーションプロ
セスがハング或はクラッシュしたものとみなす。

【００３５】ウォッチドッグ１５はまた図７から１４と
の関連で後に説明される本発明に従うプログレッシブ再
試行回復アルゴリズム７００を実行するための再開サブ
システム３０を含む。後にさらに詳細に説明されるよう
に、エラー検出モニタ２０によってアプリケーションプ
ロセス内の故障が発見されると、再開サブシステム３０
は、故障アプリケーションプロセスの回復を試みる。こ
れは、後に説明される方法によって、この最後のチェッ
クポイントの所で、故障したアプリケーションプロセス
の再開を先導し、最後のチェックポイント以降のセンダ
及びレシーバログファイル９０、９２内に登録されたメ
ッセージの再処理を行ない、故障したアプリケーション
プロセスをクラッシュが検出されたポイントの状態にま
で持って行くことによって達成される。

【００３６】本発明の一面によると、プログレッシブ再
試行回復アルゴリズム７００は、チェックポイント化動
作、ロールバック、メッセージ再プレイ及びメッセージ
並べ替え動作を利用して、回復に伴うプロセスの数、並
びに総ロールバック距離を最小にする。図７から１４と
の関連で下に説明されるように、プログレッシブ再試行
回復アルゴリズム７００は、前の再試行ステップが失敗
すると、ロールバックの範囲を徐々に増大させる複数の
再試行ステップから構成される。

【００３７】一つの好ましい実施例においては、中央回
復コーディネータ７５がセットの大域的に一貫性のある
チェックポイントを維持し、ロールバック伝播の範囲を
最小にし、また、回復モードの際に、後に説明されるよ
うに、回復ラインを計算するために利用される。好まし
くは、中央回復コーディネータ７５は、現在故障耐性計
算システム５によって監視されており、各々が実行中で
ある全てのアプリケーションプロセスをリストする故障
耐性プロセスリトス２５のコピーを含む。

【００３８】加えて、中央回復コーディネータ７５は、
好ましくは、セットの一貫性のある大域チェックポイン
トを維持するための大域チェックポイントコーディネー
タ７７を含む。大域チェックポイントは、各監視される
アプリケーションプロセスからの一つのチェックポイン
トを持つセットのチェックポイントである。ロールバッ
ク伝播規則によると、あるメッセージの送信プロセスが
最後のチェックポイントにロールバックし、あるメッセ
ージの送信を取り消すと、そのメッセージの受信プロセ
スもロールバックし、そのメッセージの受信を取り消
す。こうして、一貫性のある大域チェックポイントと
は、ロールバック伝播規則を犯す任意の二つのチェック
ポイントを含むことのない大域的なチェックポイントで
ある。

【００３９】一つの実施例においては、チェックポイン
ト化動作が開始され、後に説明されるチェックポイント
ファンクションを使用して一つのプロセスによって成功
裡に確定される度に、この事実が中央回復コーディネー
タ７５に通知される。中央回復コーディネータ７５は、
すると、好ましくは、一つのメッセージを全ての他の監
視されているアプリケーションプロセスに、これらに適
当なチェックポイントを取るように送信し、こうして、
結果としてのセットのチェックポイントが一貫性を持つ
ことが保証される。

【００４０】加えて、大域的に一貫性のあるチェックポ
イントは、通信誘発チェックポイント化動作を実現する
ことによって確保することもできる。この方法において
は、メッセージを受信するプロセスは、そのメッセージ
の見出し情報内に示される送信プロセスのチェックポイ
ント間隔番号が受信プロセスのチェックポイント間隔番
号よりも大きな場合は、一つのチェックポイントを取
る。その後、その受信プロセスと関連するウォッチドッ
グ１５が新たなチェックポイントの指標を中央回復コー
ディネータ７５の大域チェックポイントコーディネータ
７７に送信する。

【００４１】一つの代替の実施例として、レイジーチェ
ックポイント調節を使用する無調節チェックポイントシ
ステムを実現することも可能である。これに関しては、
Yi-Min Wang とW.Kent Fuchsによって、Proc. IEEE Sym
posium Reliable Distributed Propagation、pp.78-85
(Oct. 1993 ) に掲載の論文『Lazy Checkpoint Coordin
ation for Bounding Rollback Propagation』における
レイジーチェックポイント調節スキームの説明を参照す
ること。加えて、中央回復コーディネータ７５は、好ま
しくは、さらに、回復ライン計算サブシステム７９を含
むが、これは、図１５ａと１５ｂとの関連で後に詳細に
説明される回復ライン計算アルゴリズム１５００を実現
する。

【００４２】回復の概念と定義 回復の概念と定義の詳細な議論に関しては、Yi-Min Wan
g らによって、Proc.of 23d IEEE Conf. on Fault-Tole
rant Computing System (FTCS）、pp.138-144(June、199
3）に掲載の論文『Progressive Retry Technique for S
oftware ErrorRecovery in Distributed Systems』を参
照されたい。一般的に、エラー検出モニタ２０があるプ
ロセス、例えば、図２ａのプロセスＰ_a 内に“Ｆ₁ ”と
マークされているポイントにおいて故障を検出すると、
ウォッチドッグ１５の再開サブシステム３０は、プロセ
スＰ_a のＰ_a と関連する最後のチェックポイントＣ_a、4
までのロールバックを、クリティカルメモリコピーから
のプロセスＰ_a と関連する最後のチェックポイントデー
タを回復することによって開始する。プロセスＰ_a のチ
ェックポイントＣ_a、4 へのロールバックは、メッセージ
Ｍ_a の送信を取り消す。従って、プロセスＰ_b も、発信
プロセスがロールバックしてメッセージの送信を取り消
した場合は、受信プロセスもロールバックしてそのメッ
セージの受信を取り消さなければならないことを記述す
るロールバック伝播規則を満足させるために、Ｍ_a の受
信の前の状態までロールバックし、メッセージＭ_a の受
信を取り消さなければならない。さもなければ、メッセ
ージＭ_a が故障耐性計算システム５内で“受信されたが
ただし送信されてない”と記録され、結果として、シス
テム状態の非一貫性が発生することとなる。

【００４３】ただし、本発明の一面によると、プロセス
Ｐ_a は、Ｍ_a がそこから生成された状態を再生すること
が可能であり、こうして、正当にとどまるためにＭ_a の
受信に基づいてＰ_b を実行することを許す。こうして、
プロセスＰ_b は、メッセージＭ_a の受信を取り消すため
にロールバックする必要はなくなる。これは、後に説明
されるピースワイズの決定論的想定及び最後の実チェッ
クポイント以降のレシーバ及びセンダログファイル９
０、９２内にプロセスＰ_a に対して登録されているメッ
セージを利用して達成することができる。

【００４４】あるプロセスによる各メッセージの受信
は、予測不能な或は非決定論的な事象であるが、ただ
し、このピースワイズ決定論的想定は、状態間隔と称さ
れる任意の二つの連続して受信されたメッセージ間のプ
ロセス実行は、決定論的であることを記述する。そこ
で、あるプロセスがメッセージ内容と受信されたメッセ
ージの処理順番の両方を登録している場合は、そのログ
内のメッセージの決定論的再プレイによって各々のプロ
セスの状態を再生することが可能である。前述したよう
に、あるプロセスによってあるメッセージが受信される
度に、非決定論的事象は、レシーバログファイル９０内
に登録され、これは、結果として、続いて起こる状態間
隔の終端の所に“論理的”チェックポイントを置く。こ
のようにして、この追加の“論理”チェックポイント
は、回復において他のプロセスを巻き込む傾向を持つロ
ールバック伝播のドミノ効果を最小にする機能を持つ。

【００４５】図２ｂに示されるように、プロセスＰ_a と
関連する最後の実チェックポイントＣ_a、6 は、チェック
ポイントが取られたポイントの所でのプロセス状態の再
生を可能にする。加えて、このメッセージログとピース
ワイズ決定論的想定は、結果として、この状態再生の能
力のために、各受信されたメッセージによって開始され
た状態間隔の終端の所に“論理”チェックポイントＬ
_a、1 、Ｌ_a、2 、及びＬ_{a、 3} を置く。こうして、プロセス
Ｐ_a は、図２ｂに示されるように、物理的にはチェック
ポイントＣ_a、6 までロールバックするが、これは、“論
理的”には、最後の“論理”チェックポイントＬ_a、3 ま
でロールバックするのみであり、従って、メッセージＭ
₄ の送信の取消を行なう必要はない。このために、プロ
セスＰ_a のロールバックは、プロセスＰ_b を巻き込む必
要はない。こうして、“物理的なロールバックの距離”
は個々のプロセスのロールバックの範囲を決定するが、
一方に、“論理的なロールバックの距離”は他のプロセ
スへのロールバック伝播の範囲、従って、回復に伴うプ
ロセスの数を制御する。

【００４６】ピースワイズ決定論的想定は、ロールバッ
クの範囲を限定するために利用することができるが、こ
れは実行全体を通じて正当であるわけではない。例え
ば、幾つかの非決定論的事象は、実時間性の関数に依存
し、単に、記録及び再プレイすることはできない。例え
ば、ある特定のプロセスは、ある特定のメッセージを２
p.m. 以前である場合に限って送信する。従って、回復
が２ p.m. の直後に開始された場合は、このメッセージ
は再生されるべきでない。従って、単に、メッセージロ
グ内のメッセージの全てを再生することは、正確である
とはいえない。

【００４７】従って、本発明の一面によると、後に詳細
に説明されるように、回復においてあるプロセスによっ
て再生されたメッセージが、ピースワイズ決定論的想定
を検証する目的で、初期の実行の際にメッセージログ内
にそのプロセスによって格納されたメッセージと比較さ
れる。例えば、図２ｂに示されるように、回復モードに
てメッセージＭ₄ の再生が行なわれた後に、プロセスＰ
_a によって再生されたメッセージが初期の処理の際にセ
ンダログファイル９２内に格納されたメッセージと比較
される。これらメッセージが同一である場合は、ピース
ワイズ決定論的想定は正当であるものと見なされ、この
メッセージは、プロセスＰ_b に再送信される必要はな
い。従って、プロセスＰ_b は、このロールバックに参入
する必要はない。ただし、再生されたメッセージＭ₄ が
センダログファイル９２内に格納されたメッセージと同
一でない場合は、介入する非決定論的な事象が発生した
はずである。従って、プロセスＰ_a は、その状態を、こ
の非決定論的事象が発生する前の状態である最後の実際
の或は論理的な事象、例えば、図２ｂに示される論理チ
ェックポイントＬ_a、1 まで再生できるのみである。従っ
て、非決定論的事象を越える全ての論理チェックポイン
トＬ_a、2 及びＬ_a、3 は、利用できなくなり、破棄される
べきである。従って、プロセスＰ_a は、メッセージＭ₄
の送信を取り消す必要があり、プロセスＰ_b は、メッセ
ージＭ₄ の受信の前の最後の論理チェックポイント、つ
まり、論理チェックポイントＬ_b、1 までロールバックし
なければならない。

【００４８】本発明のもう一面によると、プログレッシ
ブ再試行回復アルゴリズム７００の幾つかのステップ
は、後に詳細に説明されるように、一つ或はそれ以上の
アプリケーションプロセスのレシーバログファイル９０
内の幾つかのメッセージを並べ替えることによってソフ
トウエア故障をバイパスすることを試みる。従って、正
しいことを保証するために、どのメッセージが並べ替え
でき、どのメッセージがそれらの元の順番で再プレイさ
れなければならないかを認識することが重要である。

【００４９】図３に示されるように、回復に巻き込まれ
るプロセスの状態を回復ライン３１０の所まで回復する
ために、故障耐性計算システム５は、これらのプロセス
を回復ライン３１０の手前の各プロセスの最後の実チェ
ックポイントである再開ライン３０２から、各チェック
ポイントと関連するクリティカルメモリコピー８８を回
復することによって再開することができる。好ましく
は、上に説明のように、中央回復コーディネータ７５に
よって計算される回復ライン３１０は、最後の利用可能
な大域的に一貫性のあるセットの論理チェックポイント
或は実チェックポイントの所に位置される。

【００５０】再開ライン３０２以前に処理されたメッセ
ージ、例えば、メッセージＭ₁ は、古くなったメッセー
ジであると称され、回復には使用することができない。
再開ライン３０２と回復ライン３１０との間で受信及び
処理されたメッセージ、例えば、メッセージＭ₂ とＭ₃
は、それらのメッセージ内容と処理の順番の両方がレシ
ーバログファイル９０内に登録されているはずである。
これらメッセージは、決定論的メッセージと称され、こ
れらは、決定論的再生のために、再開の後に、回復ライ
ン３１０に到達するためにそれらの元の順番に再プレイ
されるべきである。

【００５１】過渡メッセージと称される回復ライン３１
０の前に送信され、受信プロセスによって回復ライン３
１０の後に処理されたメッセージ、例えば、メッセージ
Ｍ₄及びＭ₅ に対しては、ログ内のメッセージ内容の情
報のみが正当である。過渡メッセージに対する処理の順
番は、ログされることもないし、また、不当でもない。
過渡メッセージは、実際には、まだ通信チャネル内を伝
わっている最中であり、従って、未知の伝送遅延のため
に、どのような順番で到達するか決定されてない。過渡
メッセージは、並べ替えすることができる唯一のメッセ
ージである。最後に、孤児メッセージと称される回復ラ
イン３１０以降に送信されたメッセージ、例えば、メッ
セージＭ₆ 及びＭ₇ は、この回復ラインとの関係では、
送信と受信を取り消される。従って、孤児メッセージ
は、ロールバックの際に不当と判断され、受信プロセス
によって破棄されるべきであり、さもなければ、この回
復ラインは、一貫性を持たないものとなる。

【００５２】故障耐性を実現するためのデータ構造 図４に示される故障耐性プロセスリスト２５は、故障耐
性計算システム５によって監視されているプロセスに関
する情報を維持する。一つの好ましい実施例において
は、故障耐性プロセスリスト２５と同一のコピーが各ノ
ードのウォッチドッグ１５によって維持される。故障耐
性プロセスリスト２５は、各々がある監視されているア
プリケーションプロセスと関連する複数のロウ、例え
ば、ロウ４０５、４０７、４０９、及び４１１を維持す
る。カラム４２０内にリストされる各アプリケーション
プロセスに対して、故障耐性プロセスリスト２５は、カ
ラム４２５内に、このプロセスと通信するために使用さ
れるべきローカルノードのプロセス間通信（ＩＣＰ）ポ
ートの指標を含む。

【００５３】多重ノード環境の場合は、故障耐性プロセ
スリスト２５は、好ましくは、一次ノードがアクティブ
である場合は各アプリケーションプロセスがその上で実
行されるべき一次ノードを示す指標を格納するカラム４
３０、一次ノードが動作してない場合のアプリケーショ
ンプロセスに対するバックアップノードのリストを格納
するカラム４３５、並びに関連するアプリケーションプ
ロセスが実行している現在のノードの指標を格納するカ
ラム４４０を含む。

【００５４】故障耐性プロセスリスト２５は、さらに、
カラム４４５内に、クリティカルファイルの指標、例え
ば、各プロセスと関連するクリティカルメモリコピー８
８、並びにセンダ及びレシーバログファイル９０、９２
を含む。最後に、故障耐性プロセスリスト２５は、オプ
ションとして、カラム４４８内にある時間限界を含む
が、これは、受動的エラー検出構成において、ウォッチ
ドッグ１５がアプリケーションプロセスがハングされた
という結論を下す前にハートビートメッセージ間で待た
れるべき最大の時間を示す。

【００５５】多重ノード環境の場合は、故障耐性計算シ
ステム５内の各ウォッチドッグ１５は、好ましくは、図
４に示されるノードリスト３２を維持する。これは、故
障耐性計算システム５内で現在アクティブな各ノードを
リストする。一つの好ましい実施例においては、ノード
リスト３２内の各ノード、例えば、ノード１０及び１２
は、好ましくは、ノードリスト３２内に列挙されている
次のノードを監視する。こうして、ノードリスト３２内
のノードの順番はリング構成を決定する。あるノードが
サービスから外されると、この情報は、好ましくは、後
に詳細に説明される方法にて、各ノードの所に格納され
ているノードリスト３２が適切に更新されるように各生
存ノードに同報通信される。

【００５６】前述のように、あるアプリケーションプロ
セスによって受信或は送信された各メッセージは、好ま
しくは、それぞれ、レシーバ或はセンダログファイル９
０、９２内に登録される。好ましくは、図５ａに示され
るレシーバログファイル９０が、、故障耐性計算システ
ム５によって監視される各プロセスに対して、関連する
プロセスによって受信された各メッセージに対する情報
を格納するために維持される。好ましくは、各メッセー
ジは、アプリケーションプロセスを受信した時点で、処
理される前に、レシーバログファイル９０内に登録され
る。

【００５７】レシーバログファイル９０は、最後の成功
チェックポイント以降の関連するプロセスによって受信
された各メッセージと関連する複数のロウ、例えば、ロ
ウ５０２、５０４、５０６を維持する。カラム５２０内
にリストされる各受信されたメッセージに対して、レシ
ーバログファイル９０は、カラム５２２内に、メッセー
ジサイズの指標を含み、カラム５２４内に、メッセージ
内容の指標を含む。カラム５２２及び５２４内の情報
は、回復モードにおいて、後に説明される方法によっ
て、ピースワイズ決定論的想定を検証するための比較の
ために使用される。ここで、カラム５２０内に示される
識別は、単に、例を挙げることのみを目的とすることに
注意すべきである。

【００５８】加えて、レシーバログファイル９０は、カ
ラム５２６内に、送信プロセスの識別の指標を含む。こ
れは、システムの初期化の際に送信プロセスのローカル
ノードのウォッチドッグ１５によって割り当てること
も、或は中央回復コーディネータ７５によって割り当て
ることもできる。レシーバログファイル９０はさらに、
カラム５２８内に、送信プロセスのチェックポイント間
隔番号の指標を含み、カラム５３０内には、送信プロセ
スの論理チェックポイント番号の指標を含む。カラム５
２８及び５３０内の情報は、回復モードにおいて、後に
説明される方法に従って、回復ラインを決定するための
ロールバック伝播のために使用される。後に説明される
ように、送信プロセスのチェックポイント間隔番号は、
関連するアプリケーションプロセスに対してチェックポ
イントが成功裡に実行される度に増分され、送信プロセ
ス論理チェックポイント番号は、送信プロセスによって
新たなメッセージが受信される度に増分される。

【００５９】最後に、レシーバログファイル９０は、オ
プションとして、カラム５３２内に、各メッセージと関
連する参照識別番号を含むこともできる。この参照識別
番号は、プログレッシブ再試行回復アルゴリズムにおい
て、同一の送信プロセスからのメッセージを並べ替えす
べきか決定するために使用される。一つの実施例におい
ては、同一の参照識別番号を持つ同一の送信プロセスか
らのレシーバログファイル９０内のメッセージは、並べ
替えできない。一方、異なる参照識別番号を持つ同一の
送信プロセスからのメッセージは、並べ替えできる。

【００６０】一つの好ましい実施例においては、好まし
くは、関連するプロセスがチェックポイントを成功裡に
実行する度に“ダミー”エントリがレシーバログファイ
ル９０内に置かれる。このようにして、レシーバログフ
ァイル９０内のメッセージが受信プロセスの適当なチェ
ックポイント間隔番号と関連付けられ、このために、最
後の実チェックポイント以降に受信されたメッセージを
プログレッシブ再試行回復アルゴリズム７００の幾つか
のステップの最中に識別することが可能である。

【００６１】同様にして、好ましくは、図５ｂに示され
るセンダログファイル９２が故障耐性計算システム５に
よって監視される各プロセスに対して、関連するプロセ
スによって送信された各メッセージに対する情報を格納
するために維持される。センダログファイル９２は、最
後の成功裡のチェックポイント以降の関連するプロセス
によって送信されたメッセージと各々が関連する複数の
ロウ、例えば、ロウ５５２、５５４、５５６、５５８を
含む。カラム５７０内にリストされる各送信されたメッ
セージに対して、センダログファイル９２は、カラム５
７２内に、メッセージサイズの指標を含み、カラム５７
４内にメッセージ内容の指標を含む。カラム５７２及び
５７４内の情報は、後に説明される方法に従って、回復
モードにおいて、比較のために使用される。ここで、カ
ラム５７０内に示される識別は、単に、例を挙げること
のみを目的とすることに注意すべきである。

【００６２】加えて、センダログファイル９２は、カラ
ム５７６内に、受信プロセスのプロセス識別子の指標を
含むが、これは、システム初期化の際に受信プロセスの
ローカルノードのウォッチドッグ１５によって割り当て
ることも、或は中央回復コーディネータ７５によって割
り当てることもできる。センダログファイル９２はさら
に、カラム５７８内に、送信プロセスの論理チェックポ
イント番号の指標を含む。前述のように、送信プロセス
の論理チェックポイント番号は、新たなメッセージが送
信プロセスによって受信される度に増分される。それぞ
れ図５ａと５ｂに示されるレシーバ及びセンダログファ
イル９０及び９２には、図６ａから６ｆとの関連で後に
説明されるプロセスＰ₂ に対する情報が示される。

【００６３】多重ノード動作 多重ノード環境の場合は、各ウォッチドッグ１５は、好
ましくは、さらに、ノード故障を検出するために循環様
式にてもう一つのノードのウォッチドッグ１５を監視す
る。多重ノード環境における故障耐性の議論に関して
は、本発明の譲受人に譲渡された、１９９２年９月３０
日出願の『Apparatus and Method for Fault-Tolerant
Computing 』という名称の合衆国特許出願第０７／９５
４，５４９号；及びR.Bianchini、 Jr.及びR.Buskens に
よってProc. of 21st IEEE Conf. on Fault Tolerant C
omputing Systems（FTCS)、pp.222-29 (July 1991) に掲
載の論文『An Adaptive Distributed System-Level Dia
gnosis Algorithm and Its Implementation 』を参照さ
れたい。

【００６４】一般的に述べて、多重ノード環境において
は、各ノード内のウォッチドッグ１５は、各々のノード
上でローカル的に実行しているアプリケーションプロセ
スの状態、並びに、少なくとも一つの他のノードの状態
を監視する。ウォッチドッグ１５は、図４ｂとの関連で
上で説明されたノードリスト３２を含むが、これはウォ
ッチドッグ１５がどの単一或は複数のノードを監視して
いるかを示すために使用される。好ましくは、ノードリ
スト３２と同一のコピーが、各ノード内のウォッチドッ
グ１５に提供される。第一のノードが故障すると、これ
は第一のノードを監視しているもう一つのノード上のウ
ォッチドッグ１５によって検出される。監視しているウ
ォッチドッグ１５は、生存ノードに、ノードリスト３２
が故障したノードが失われたことを反映するようにノー
ドリスト３２を修正すべきであることを示すメッセージ
を同報通信する。加えて、検出された故障の直前に故障
したノード上で実行されていた各プロセスに対する故障
耐性プロセスリスト２５のカラム４３５内に示されるバ
ックアップノードは、各々のプロセスを再開することを
要求される。

【００６５】ただし、あるノード内のウォッチドッグ１
５が他のノードからのアプリケーションプロセスを再開
するためには、監視しているウォッチドッグ１５がその
プロセスの状態のコピーを持つことが必要である。この
ために、前述のように、各ノードは、ローカルノード上
で実行中のプロセスの状態のコピーを維持するための不
揮発性メモリ４４を含む。こうして維持されるコピーと
しては、各プロセスのクリティカルメモリ８８のチェッ
クポイントコピー、並びに、各ローカルプロセスに対す
るレシーバログファイル９０及びセンダログファイル９
２が含まれる。加えて、多重ノード環境においては、プ
ロセス状態が一次ノードからその監視しているウォッチ
ドッグ１５と関連するバックアップノードにコピーされ
る。一つの好ましい実施例においては、各々のアプリケ
ーションプロセスに対するクリティカルメモリコピー８
８或はログファイル９０、９２内に重大な変化が発生す
る度に、コピーが監視されているノード内のウォッチド
ッグ１５によって作成され、監視しているウォッチドッ
グ１５に送信される。

【００６６】上の説明から明らかなように、各ウォッチ
ドッグ１５は、任意の時間において、故障耐性計算シス
テム５内のどこで各監視されているアプリケーションプ
ロセスがランしているかを知っている必要がある。この
情報は、好ましくは、故障耐性プロセスリスト２５のカ
ラム４４０内に含まれるが、各ウォッチドッグ１５は、
この情報の同一のコピーを持つ。故障耐性プロセスリス
ト２５の一貫性は、各ウォッチドッグ１５が、それが監
視されるプロセスを開始或は再開したときに、他の全て
のウォッチドッグ１５に一つのメッセージを同報通信
し、一方、各ウォッチドッグ１５が、このメッセージに
応答して、そのメッセージによって要求されるように故
障耐性プロセスリスト２５を更新することによって維持
される。前に故障していたノードがサービスに戻ると、
このノード内のウォッチドッグ１５は、もう一つのノー
ド内のウォッチドッグ１５からノードリスト３２のコピ
ー及び故障耐性プロセスリスト２５を得る。この故障耐
性プロセスリスト２５は、図４ａとの関連で上に述べた
ように、この前に故障していたノードに対してローカル
であるアプリケーションプロセスを現在実行しているノ
ード、及びこれらプロセスを再開するために必要なロー
カルプロセスの状態を含む状態ファイルの位置を示す。
ウォッチドッグ１５は、現在それらプロセスを実行して
いるノードからこれらファイルのコピーを得て、この状
態コピーを使用してこれらプロセスを再開する。上に述
べたように、ウォッチドッグ１５があるプロセスを再開
すると、これは、故障耐性計算システム５内の他のウォ
ッチドッグ１５にメッセージを送信し、あるウォッチド
ッグ１５がその再開されたプロセスを実行している場合
は、このウォッチドッグ１５は、そのプロセスの実行を
停止し、その故障耐性プロセスリスト２５を、そのプロ
セスが現在適切な一次ノード上で実行していることを示
すように修正する。他の全てのウォッチドッグ１５は、
単に、それらの故障耐性プロセスリスト２５を上に説明
された方法で修正する。

【００６７】故障耐性ライブラリファンクション 本発明の一面によると、あるアプリケーションプロセス
は、故障耐性ライブラリ８２からの適当なファンクショ
ンをそのアプリケーションプロセスに対するコード内に
挿入することによって故障耐性にされる。前に述べたよ
うに、故障耐性ライブラリ８２は、好ましくは、ハート
ビートファンクションを含む。これは、あるアプリケー
ションプロセスによって呼び出されると、ウォッチドッ
グ１５に、それと関連するプロセスがまだアクティブで
あることを示すハートビートメッセージを所定の間隔で
送信する。ウォッチドッグ１５が所定の間隔の終了まで
にそのアプリケーションプロセスから次の信号を受信し
ない場合は、ウォッチドッグ１５は、そのアプリケーシ
ョンプロセスがハング或はクラッシュしたものと見な
す。

【００６８】加えて、故障耐性ライブラリ８２は、クリ
ティカルメモリファンクションを含む。これは、ユーザ
がアプリケーションプロセス内のどのデータがクリティ
カルデータであるかを選択的に指定することを可能に
し、指定されたデータは、そのアプリケーションプロセ
スによってチェックポイントファンクションが実行され
る度に不揮発性メモリ４４のある領域内にコピーされ
る。

【００６９】こうして、あるアプリケーションプロセス
によるチェックポイントファンクションへの呼び出しが
ある度に、クリティカルデータが、好ましくは、安定な
メモリデバイス上に格納される。加えて、チェックポイ
ントが成功裡に実行される度に、好ましくは、関連する
アプリケーションプロセスの、二つの連続するチェック
ポイント間の間隔であるチェックポイント間隔番号が増
分される。チェックポイントファンクションが成功裡に
遂行されると、チェックポイントファイル名、プロセス
識別子及び現在のチェックポイント間隔番号を含むメッ
セージがウォッチドッグ１５に送られる。この方法によ
って、ウォッチドッグ１５は、この情報を使用して、チ
ェックポイントファイルを一つ或はそれ以上のバックア
ップノード上に複製し、また、大域チェックポイントコ
ーディネータ７７に調節されたチェックポイント環境内
のこの新たなチェックポイントについて通知する。通知
を受けると、大域チェックポイントコーディネータ７７
は、好ましくは、残りの監視されているプロセスに大域
チェックポイントを示す。

【００７０】加えて、故障耐性ライブラリ８２は、好ま
しくは、回復ファンクションを含む。これは、アプリケ
ーションプロセスが、後に詳細に説明されるように、回
復モードにおいて、クリティカルメモリコピー８８から
チェックポイントの所のデータを回復することを可能に
する。

【００７１】故障耐性ライブラリ８２は、好ましくは、
さらに、以降ftwrite と称される故障耐性書込みファン
クションを含む。これは、各出力メッセージをセンダロ
グファイル９２内に、そのメッセージがアプリケーショ
ンプロセスによって送信される前に登録する。多重ノー
ド環境内においては、この出力データが複製され、バッ
クアップマシン上のウォッチドッグ１５によって登録さ
れる。あるアプリケーションプロセスが通常のモードに
あるときは、ftwiteファンクションは、他のプロセスに
メッセージを送信し、各送信されたメッセージに対し
て、センダログファイル内にその情報を加える。

【００７２】ftwrite ファンクションによって送信され
る各メッセージは、好ましくは、メッセージ識別子、送
信プロセスのプロセス識別子、送信プロセスのチェック
ポイント間隔番号と論理チェックポイント番号、及びオ
プションとしての参照識別番号を含む。チェックポイン
ト間隔番号は調節されたチェックポイントを実現するた
めに使用される。前に述べたように、参照識別番号は同
一の送信プロセスからのメッセージが並べ替えできるか
否かを示すために使用される。

【００７３】ただし、回復状態においては、登録された
メッセージが処理された後に、ftwrite ファンクション
が、以下に説明される方法にて、ピースワイズ決定論的
想定を検証する目的で、各新たに生成されたメッセージ
をセンダログファイル９２内の対応するメッセージと比
較するために実行される。回復の際に生成されたメッセ
ージが前の実行の際にセンダログファイル９２内に格納
されたメッセージと同一である場合は、メッセージは再
送される必要はない。ただし、メッセージが同一でない
場合は、非決定論的事象が発生しており、後に説明され
る方法に従って、回復の範囲が広げられる。

【００７４】故障耐性ライブラリ８２は、好ましくは、
さらに、以降ftreadと称される故障耐性読出しファンク
ションを含む。これは、入力メッセージをレシーバログ
ファイル９０内に、これらが受信アプリケーションプロ
セスによって処理される前に登録する。多重ノード環境
においては、入力データが複製され、バックアップマシ
ン上のウォッチドッグ１５によって登録される。あるア
プリケーションプロセスが通常のモードにある場合は、
ftreadファンクションは、ＩＰＣチャネルからデータを
読出し、受信されたメッセージをレシーバログファイル
９０内に登録する。

【００７５】ただし、回復状態においては、後に説明さ
れる方法によって、入力データがレシーバログファイル
９０から回復ライン３１０の所まで読出され、その後、
任意のデータが正規の入力チャネルから読出される。一
つの好ましい実施例においては、ftreadファンクション
は、各受信されたメッセージと関連する送信プロセスの
チェックポイント間隔番号をチェックし、送信プロセス
のチェックポイント間隔番号が受信プロセスの現在のチ
ェックポイント間隔番号よりも大きな場合は関連する受
信アプリケーションプロセスのチェックポイントを起動
し、これによって、大域的に一貫性のあるチェックポイ
ントを確保する。加えて、ftreadファンクションが中央
回復コーディネータ７５からチェックポイント制御メッ
セージを受信したときも、ftreadファンクションは、そ
のアプリケーションプロセスのチェックポイントを起動
する。

【００７６】図６ａから６ｆは、複数の平行アプリケー
ションプロセスに対する通信パターンを図解し、これら
プロセスが図８から１１との関連で後に説明されるプロ
グレッシブ再試行回復アルゴリズム７００の様々なステ
ップによってどのような効果を受けるかを示す。以下で
は、図６ａから６ｆを参照し、プログレッシブ再試行回
復アルゴリズム７００の各ステップを図解しながら、プ
ログレッシブ再試行回復アルゴリズム７００について解
説される。

【００７７】図６ａから６ｆは、以下の約束を使用し
て、様々な回復概念を図解する。各プロセスと関連する
加算記号“＋”は、各プロセスに対する最後の実チェッ
クポイントの時間上の位置を示す。四角のボックス内の
加算記号は、各プロセスに対する論理チェックポイント
の時間上の位置を示す。加算記号のない四角のボックス
は、最後の正当な論理チェックポイントを示し、これ
は、各プロセスに対する回復ラインを形成する。最後に
最後の実エッチングポイントを示す加算記号が円の中に
位置される場合は、これは、関連するプロセスがプログ
レッシブ再試行回復の現在のステップに巻き込まれてい
ることを示す指標である。

【００７８】プログレッシブ再試行回復アルゴリズム 本発明の原理を具現するプログレッシブ再試行回復アル
ゴリズムは、図７に示されるように、ステップ７０１か
ら開始される。ステップ７０５において、ウォッチドッ
グ１５のエラー検出モニタ２０が監視されているアプリ
ケーションプロセス内に故障を発見するまで、テストが
反復的に遂行される。ステップ７０５において故障が検
出されると、ステップ７１０において、現在の検出され
た故障がこのプロセスに対して以前に検出された故障と
同一であるか決定するためのテストが遂行される。一つ
の実施例においては、同一のプロセスに対する前の故障
からの所定の時間しきい値内に検出された故障は同一の
故障であると見なされる。ステップ７１０において、現
在検出された故障がこのプロセスに対する前に検出され
た故障と同一の故障でないことが発見された場合は、存
在する場合、これがこの故障を修正するための最初の試
みであり、プログレッシブ再試行方法が、この故障プロ
セスの回復を試みるためにステップ１から開始される。

【００７９】このために、プログレッシブ再試行回復ア
ルゴリズム７００のどのステップが現在実行されるべき
かを制御するカウンタ変数Ｎがステップ７１５におい
て、プログレッシブ再試行回復アルゴリズム７００の最
初のステップが試みられるべきであることを示すため
に、１にセットされる。ただし、ステップ７１０におい
て、現在発見された故障がこのプロセスに対する前に検
出された故障と同一の故障であることが発見された場合
は、この故障を修正する前の試みが不成功であったこと
を意味する。従って、プログレッシブ再試行回復アルゴ
リズム７００の範囲が故障プロセスの回復を試みるため
に増大されなければならない。このために、ステップ７
２０において、プログレッシブ再試行回復アルゴリズム
７００の次のステップが試みられるべきであることを示
すために１だけ増分される。

【００８０】ステップ７２５において、カウンタ値Ｎの
現在の値が１であるかを決定するためのテストが遂行さ
れる。ステップ７２５において、カウンタ変数Ｎの値が
１であることが決定された場合は、ステップ７３０にお
いて、最初の故障プロセスと関連するレシーバログファ
イル９０のバックアップコピーが作成される。プログレ
ッシブ再試行回復アルゴリズム７００の各ステップが試
みられる度に、レシーバログファイル９０内の情報が破
棄される。好都合なことに、レシーバログファイル９０
のバックアップコピーは、必要なときに、この情報にア
クセスすることを可能にする。

【００８１】図８との関連で後に説明されるプログレッ
シブ再試行方法のステップ１であるレシーバ再プレイサ
ブルーチン８００がステップ７３５において実行され
る。その後、プログラム制御はステップ７９５に進み、
ここでプログレッシブ再試行回復アルゴリズム７００は
退出する。故障プロセスは、すると、前に検出されたソ
フトウエアエラーのバイパスを試みるために通常のプロ
グラム実行を再開する。第二の実行において故障がバイ
パスされない場合は、次の故障が検出された時点でプロ
グレッシブ再試行回復アルゴリズム７００が再開され、
ステップ２の再試行に進む。

【００８２】ただし、ステップ７２５において、カウン
タ変数Ｎの値が１でないことが決定された場合は、ステ
ップ７４０において、カウンタ変数Ｎの値が２に等しい
か決定するためのテストが遂行される。ステップ７４０
において、カウンタ変数Ｎの値が２であることが決定さ
れた場合は、故障の可能性のあるソースは、別のプロセ
スから受信されたメッセージである。このために、好ま
しくは、ステップ７４５において、オフラインデバッグ
のために、チェックポイントファイルのコピーと、セン
ダ及びレシーバログファイル９０と９２とがトレースフ
ァイル内にコピーされる。

【００８３】次に、図９との関連で後に説明されるプロ
グレッシブ再試行法のステップ２であるレシーバ並べ替
えサブルーチン９００がステップ７５０において実行さ
れる。その後、プログラム制御は、ステップ７９５に進
み、ここでプログレッシブ再試行回復アルゴリズム７０
０は退出する。次に、監視されているプロセスの全てが
通常のプログラム実行に戻り、前に検出されたソフトウ
エア故障のバイパスを試みる。故障がバイパスされない
場合、プログレッシブ再試行回復アルゴリズム７００が
次に故障が検出されたとき再開され、ステップ３の再試
行へと進む。

【００８４】ただし、ステップ７４０において、カウン
タ変数Ｎの値が２に等しくないことが決定された場合
は、ステップ７５５において、カウンタ変数Ｎの値が３
に等しいか決定するためのテストが遂行される。ステッ
プ７５５において、カウンタ変数Ｎの値が３に等しいこ
とが決定された場合は、次に、図１０との関連で後に説
明されるプログレッシブ再試行法のステップ３であるセ
ンダ再プレイサブルーチン１０００がステップ７６０に
おいて実行される。その後、プログラム制御はステップ
７９５に進み、ここでプログレッシブ再試行回復アルゴ
リズム７００は退出する。全ての監視下のプロセスが通
常のプログラム実行に戻り、故障のバイパスを試みる。
故障がバイパスされない場合は、プログレッシブ再試行
回復アルゴリズム７００が次の故障が検出された時点で
再開され、ステップ４の再試行に進む。

【００８５】ただし、ステップ７５５において、カウン
タ変数Ｎの値が３に等しくないことが決定された場合
は、ステップ７６５において、カウンタ変数Ｎの値が４
に等しいか決定するためのテストが遂行される。ステッ
プ７６５において、カウンタ変数Ｎが４に等しいことが
決定された場合は、次に、図１１との関連で後に説明さ
れるプログレッシブ再試行法のステップ４であるセンダ
並べ替えサブルーチン１１００がステップ７７０におい
て実行される。その後、プログラム制御はステップ７９
５に進み、ここで、プログレッシブ再試行回復アルゴリ
ズム７００は、次の故障が検出されるまで退出する。

【００８６】ただし、ステップ７６５において、カウン
タ変数Ｎの値が４に等しくないことが決定された場合
は、ステップ７７５において、カウンタ変数Ｎの値が５
に等しいか決定するためのテストが遂行される。ステッ
プ７７５においてカウンタ変数Ｎの値が５に等しいこと
が決定された場合は、次に、図１２との関連で後に説明
されるプログレッシブ再試行法のステップ５である広範
囲ロールバック再試行サブルーチン１２００がステップ
７８０において実行される。その後、プログラム制御は
ステップ７９５に進み、ここでプログレッシブ再試行回
復アルゴリズム７００は、次の故障が検出されるまで退
出する。

【００８７】ただし、ステップ７７５においてカウンタ
変数Ｎの値が５に等しくないことが決定された場合は、
ステップ７８５において、カウンタ変数Ｎの値が５より
大きいか決定するためのテストが遂行される。ステップ
７８５においてカウンタ変数Ｎの値が５よりも大きいこ
とが決定された場合は、プログレッシブ再試行回復アル
ゴリズム７００は、故障プロセスを回復できなかったこ
とを意味する。従って、システムは、ステップ７９０に
おいて、完全な再初期化と共に再開されなければならな
い。別の方法として、ステップ７９０において、プログ
レッシブ再試行回復アルゴリズム７００が故障プロセス
を成功裡に回復できなかったことを示すエラー或は警告
メッセージを生成することもできる。その後、プログラ
ム制御はステップ７９５に進み、ここで、プログレッシ
ブ再試行回復アルゴリズム７００は、次の故障が検出さ
れるまで退出する。

【００８８】ステップ１−−レシーバ再プレイ 前述のように、プログレッシブ再試行回復アルゴリズム
７００は、プログレッシブ再試行法のステップ１におい
てレシーバ再プレイサブルーチン８００を実行する。レ
シーバ再プレイサブルーチン８００は、図８に示される
ように、ステップ８０１から開始される。レシーバ再プ
レイサブルーチン（ステップ１）８００は、故障プロセ
スを最後のチェックポイントまで回復し、次に、故障プ
ロセスのレシーバログファイル９０内の最後の実チェッ
クポイント以降に受信されたメッセージを再プレイする
ことによって、故障をバイパスすることを試みる。一つ
の好ましい実施例においては、これは、ステップ８２０
において、故障プロセスに対して図１４ａと１４ｂとの
関連で後に説明される決定論的再プレイサブルーチン１
４００を実行することによって実現される。

【００８９】前述のように、好ましくは、個々のメッセ
ージが処理の前に登録される。従って、検出された故障
の前に故障プロセスによって送信或は受信された各メッ
セージは、故障プロセスのレシーバログファイル９０及
びセンダログファイル９２内に登録されている。従っ
て、決定論的再プレイサブルーチン１４００を使用し
て、登録されているメッセージを再プレイすることによ
って、故障プロセスは、その状態をそれがエラーを検出
したポイントまで再生することができる。

【００９０】図６ａに示されるように、ウォッチドッグ
１５のエラー検出モニタ２０によって、プロセスＰ₂ に
対して“Ｆ”とマークされているポイントにおいて故障
が検出されると、ウォッチドッグ１５の再開サブルーチ
ン３０は、プログレッシブ再試行回復アルゴリズム７０
０を始動して故障をバスパスすることを試みる。ステッ
プ１の再試行において、決定論的再試行サブルーチン１
４００は、プロセスＰ₂ のレシーバログファイル９０内
の各メッセージを再プレイし、環境多様性の概念に基づ
いて故障のバイパスを試みる。つまり、幾つかのケース
においては、過渡的な故障が幾つかの環境要因、例え
ば、互いに排他的な衝突、資源が利用できない、予期せ
ぬ信号その他の理由によって発生するが、これらは、回
復が実行さる時点ではもはや存在せず、ステップ１の再
試行が成功する可能性がある。

【００９１】後に説明されるように、本発明の一面によ
ると、ピースワイズ決定論的想定の妥当性が決定論的再
プレイサブルーチン１４００によって、決定論的再プレ
イの際にプロセスＰ₂ によって生成された各メッセージ
を評価することによって検証される。回復の際に再生さ
れたメッセージが初期の処理の際にセンダログファイル
９２内に格納されたメッセージと等しくない場合は、非
決定論的事象が発生したものと判断される。

【００９２】例えば、図６ｂに示されるように、決定論
的再プレイサブルーチン１４００は、Ｐ₂ のメッセージ
ログ内の各メッセージをメッセージＭ_f に至るまで再プ
レイする。メッセージＭ_f が再生された時点で、決定論
的再プレイサブルーチン１４００は、以下に説明される
方法にて、非決定論的事象ｅが発生したことを決定する
が、この結果として、生成されたメッセージＭ_f の以前
のバージョンはもはや正当でないとされる。こうして、
プロセスＰ₂ は、その状態を非決定論的事象ｅの直前の
論理チェックポイントまで再生できるのみであり、非決
定論的事象を越える全ての論理チェックポイントは利用
できず、破棄されなければならない。従って、プロセス
Ｐ₂ は、メッセージＭ_f 、並びにメッセージＭ_g の送信
を取り消し、論理チェックポイントＬ_2、2 までロールバ
ックしなければならず、従って、図６ｂ内の新たな回復
ライン１０によって示されるように、回復において、プ
ロセスＰ₁ を巻き込むこととなる。プロセスＰ₁ は、送
信が取り消されたメッセージＭ_g 及びＭ_f の前の最後の
論理チェックポイント、つまり、論理チェックポイント
Ｌ_1、3 までロールバックしなければならない。注目すべ
き点として、このように前の実行から離れることによっ
て、過渡的な故障を起こすソフトウエア故障をバイパス
する追加の機会が提供される。

【００９３】ステップ８２０（図８）における決定論的
再プレイサブルーチン１４００の実行に続いて、プログ
ラム制御は、ステップ８４０において、プログレッシブ
再試行回復アルゴリズム７００に戻り、故障プロセスに
対する通常の実行が再開される。前に検出された故障が
バイパスされた場合は、プログラム制御は継続される。
ただし、故障がバイパスされなかった場合は、エラー検
出モニタ２０が故障を再び検出し、プログレッシブ再試
行回復アルゴリズム７００をステップ２の再プレイから
再開する。

【００９４】ステップ２−−レシーバ並べ替え 前述のように、プログレッシブ再試行回復アルゴリズム
７００は、プログレッシブ再試行法のステップ２におい
てレシーバ並べ替えサブルーチン９００を実行する。レ
シーバ並べ替えサブルーチン９００は、図９に示される
ように、ステップ９０１から開始される。

【００９５】ステップ１の再試行が不成功であった場合
は、故障の原因としては、他のプロセスから受信された
メッセージによる可能性が高い。ロールバックの範囲を
最小にするために、最初にステップ２の再試行が、実際
に送信プロセスを巻き込むことなしに、受信されたメッ
セージに関する他の可能なシナリオをローカル的にシミ
ュレートするために試みられる。

【００９６】原則として、入り通信チャネルの伝送遅延
は予測不能である。従って、異なるプロセスから受信さ
れたメッセージは、通常は、特定の到達順序を持つもと
の想定することはできない。従って、故障プロセスによ
るメッセージの並べ替え動作が異なるメッセージの到達
順序をシミュレートするために使用される。ただし、同
一送信プロセスからのメッセージは、同一の順序での処
理を要求することに注意する。

【００９７】後に説明されるように、故障プロセスは、
故障プロセスのレシーバログファイル９０内にリストさ
れている全ての受信メッセージの並べ替えを試みる。レ
シーバ並べ替えサブルーチン（ステップ２）９００は、
最初に、ステップ９１０において、故障プロセスのレシ
ーバログファイル９０内の故障プロセスによって最後の
実チェックポイント以降に受信された各メッセージに対
する処理順番情報を破棄する。これは、故障プロセスに
対する最初に受信されたメッセージ以降の全ての論理チ
ェックポイントを不当にする機能を果たす。

【００９８】その後、故障プロセスと関連するウォッチ
ドッグ１５が、ステップ９２０において、ステップ２の
回復のために回復ライン３１０を計算し直すリクエスト
を故障プロセスの指標と共に中央回復コーディネータ７
５に送信する。中央回復コーディネータ７５がいかにし
てこのリクエストを処理し、回復ラインを再計算するか
は、図１５ａと１５ｂとの関連で、後に説明される。

【００９９】中央回復コーディネータ７５は、回復ライ
ンの計算を終えると、監視下の各アプリケーションプロ
セスに再計算された回復ライン情報を同報通信する。再
計算された回復ラインを受信すると、監視下の各プロセ
スは、それぞれプロセスＰ₀及びＰ_N に対して、図９の
処理ブランチ９３０及び９４０に示されるように、実質
的に平行的に回復ラインを処理し、適当な応答を決定す
る。プロセスＰ₀ は、ステップ９５０において、中央回
復コーディネータ７５から同報通信された回復ライン３
１０を受信する。その後、ステップ９６０において、プ
ロセスＰ₀ に対して、図１３との関連で後に説明される
プロセスメッセージ登録サブルーチン１３００が実行さ
れる。

【０１００】処理順番情報がレシーバログファイル９０
内の全てのメッセージに対して破棄されているために、
最初に受信されたメッセージ以降の故障プロセスの論理
チェックポイントはもはや利用することはできない。従
って、故障プロセスによって送信された全てのメッセー
ジは送信を取り消されなければならず、送信を取り消さ
れたメッセージを受信したプロセスは全て、ステップ２
の再試行に参入しなければならない。

【０１０１】図６ｃに示されるように、ウォッチドッグ
１５のエラー検出モニタ２０によって、“Ｆ”とマーク
されたポイントにおいて、プロセスＰ₂ に対して故障が
再び検出されると、ウォッチドッグ１５の再開サブシス
テム３０は、再度プログレッシブ再試行回復アルゴリズ
ム７００を開始し、故障をバイパスすることを試みる。
故障が前に検出された故障と同一である場合は、プログ
レッシブ再試行回復アルゴリズム７００は、ステップ２
の再試行を開始する。故障プロセスＰ₂ のそれが最初に
受信したメッセージ以降の論理チェックポイントはもは
や利用できないために、図６ｃに示されるような回復ラ
インが中央回復コーディネータ７５によって送信され
る。この回復は、メッセージＭ_g とＭ_f の送信が取り消
されたために、プロセスＰ₁ を巻き込む。後に説明され
るように、プロセスＰ₂ 及びＰ₁ のメッセージログ内の
メッセージが、図１３との関連で後に説明されるよう
に、プロセスメッセージログサブルーチン１３００によ
って処理され、ソフトウエア故障をバイパスすることが
試みられる。

【０１０２】図９に示されるように、プロセスＰ_N は、
ステップ９７０と９８０において、同報通信された回復
ライン３１０を受信及び処理するが、これは、プロセス
Ｐ_Nによって、プロセスＰ₀ 及び他の全ての監視下のプ
ロセスの処理と実質的に平行して処理される。監視下の
全てのプロセスが再計算された回復ライン３１０の処理
を完了すると、プログラム制御は、ステップ９９０にお
いて、プログレッシブ再試行回復アルゴリズム７００に
戻り、通常の実行が、各監視下のプロセスＰ₀ からＰ_N
に対して再開される。前に検出された故障がバイパスさ
れた場合は、プログラム制御は継続される。故障がバイ
パスされなかった場合は、エラー検出モニタ２０が故障
を再び検出し、プログレッシブ再試行回復アルゴリズム
７００が今回はステップ３を試みて再開される。

【０１０３】ステップ３−−センダ再プレイ 前述のように、プログレッシブ再試行回復アルゴリズム
７００は、プログレッシブ再試行法のステップ３におい
て、センダ再プレイサブルーチン１０００を実行する。
センダ再プレイサブルーチン（ステップ３）１０００は
図１０に示されるように、ステップ１００１から開始さ
れる。センダ再プレイサブルーチン（ステップ３）１０
００は、最初に、ステップ１０１０において、故障プロ
セスのレシーバログファイル９０内のその故障プロセス
によって最後の実チェックポイント以降に受信された全
てのメッセージを破棄する。後に説明されるように、こ
れら破棄されたメッセージの送信プロセスは、次に、こ
れらメッセージを故障プロセスに再送し、故障プロセス
内の故障をバイパスすることを試みる。

【０１０４】故障プロセスと関連するウォッチドッグ１
５は、次に、ステップ１０２０において、ステップ３の
回復に対する回復ライン３１０を再計算するリクエスト
を故障プロセスの指標と共に中央回復コーディネータ７
５に送信する。中央回復コーディネータ７５がどのよう
にこのリクエストを処理し、回復ラインを再計算するか
については、図１５ａと１５ｂとの関連で後に説明され
る。中央回復コーディネータ７５は、回復ラインの再計
算を完了すると、再計算された回復ライン情報を各監視
されているアプリケーションプロセスに同報通信する。
再計算された回復ラインを受信すると、各監視されてい
るプロセスは、それぞれ、プロセスＰ₀ 及びＰ_N に対し
て、図１０内の処理ブランチ１０３０と１０４０によっ
て示されるように、実質的に平行して回復ラインを処理
し、適当な応答を決定する。

【０１０５】プロセスＰ₀ は、ステップ１０５０におい
て、中央回復コーディネータ７５から同報通信された回
復ライン３１０を受信する。その後、ステップ１０６０
において、プロセスＰ₀ に対して、図１３との関連で後
に説明されるプロセスメッセージログサブルーチン１３
００が実行される。破棄されたメッセージを送信したプ
ロセスは、プロセスメッセージログサブルーチン１３０
０を使用して、これらメッセージを故障されたプロセス
によって受信されるように、可能な異なる順番にて送信
することによって、故障をバイパスすることを試みる。

【０１０６】図６ｄに示されるように、ウォッチドッグ
１５のエラー検出モニタ２０によって、“Ｆ”とマーク
されたポイントにおいて、プロセスＰ₂ に対して故障が
検出されると、ウォッチドッグ１５の再開サブシステム
３０は、プログレッシブ再試行回復アルゴリズム７００
を開始して、故障をバイパスすることを試みる。ステッ
プ３において、プロセスメッセージログサブルーチン１
３００は、破棄されたメッセージを送信したプロセス
に、これらメッセージを再送するように指令する。

【０１０７】後に述べられるように、プロセスメッセー
ジログサブルーチン１３００は、決定論的メッセージを
再プレイするために決定論的再プレイサブルーチン１４
００を実行する。決定論的再プレイサブルーチン１４０
０は、ピースワイズ決定論的想定が妥当であるか検証す
るために、決定論的再プレイの際にプロセスＰ₂ によっ
て生成された各メッセージを評価する。回復の際に生成
されたメッセージが初期の処理の際にセンダログファイ
ル９２内に格納されたメッセージと等しくない場合は、
非決定論的な事象が発生したものと見なされる。

【０１０８】例えば、図６ｅに示されるように、決定論
的再プレイサブルーチン１４００は、Ｐ₃ のメッセージ
ログ内の各メッセージをメッセージＭ_a に至るまで再プ
レイする。メッセージＭ_a が再生された時点で、決定論
的再プレイサブルーチン１４００は、後に説明される方
法に従って、非決定論的な事象ｅが発生したことを決定
するが、この結果として、生成されたＭ_a の以前のバー
ジョンが不当にされる。このため、プロセスＰ₃ は、そ
の状態を非決定論的な事象ｅの直前の論理チェックポイ
ントＬ_3、1 までしか再生することができず、非決定論的
な事象を越える全ての論理的チェックポイントは、利用
できず、破棄されなければならない。従って、プロセス
Ｐ₃ は、論理チェックポイントＬ_3、1 までロールバック
し、メッセージＭ_a 、Ｍ_d 及びＭ_s の送信を取り消す必
要があり、従って、図６ｅ内の新たな回復ライン３１０
によって示されるように、この回復には、プロセスＰ₄
が巻き込まれる。

【０１０９】図１０に示されるように、プロセスＰ_N
は、ステップ１０７０及び１０８０において、同報通信
された回復ライン３１０を受信及び処理するが、これら
はプロセスＰ_N によって、プロセスＰ₀ 及び他の全ての
監視されているプロセスの処理と実質的に平行して処理
される。監視下のプロセスの全てが再計算された回復ラ
イン３１０の処理を終了した後に、プログラム制御は、
ステップ１０９０において、プログレッシブ再試行回復
アルゴリズム７００に戻り、通常の実行が各監視下のプ
ロセスＰ₀ からＰ_N に対して再開される。前に検出され
た故障がバイパスされた場合は、プログラム制御は継続
される。ただし、そうでない場合は、エラー検出モニタ
２０が故障を再び検出し、プログレッシブ再試行回復ア
ルゴリズム７００を今回はステップ４を試みるために再
開する。

【０１１０】ステップ４−−センダ並べ替え 前述のように、プログレッシブ再試行回復アルゴリズム
７００は、プログレッシブ再試行法のステップ４におい
てセンダ並べ替えサブルーチン１１００を実行する。セ
ンダ並べ替えサブルーチン（ステップ４）１１００は、
図１１に示されるように、ステップ１１０１から開始さ
れる。ステップ４の再試行において、プログレッシブ再
試行回復アルゴリズム７００は、回復の範囲及び非決定
論的性質の程度を増大するが、これは、回復において故
障プロセスにメッセージを送信したプロセスを巻き込
み、これらに、それらのレシーバログファイル９０内の
過渡メッセージをこれらを再処理する前に並べ替えさせ
ることによって行なわれる。並べ替えられた過渡メッセ
ージの再処理の際に、故障プロセスに以前にメッセージ
を送信したプロセスが、故障プロセスに再びメッセージ
を送信する。

【０１１１】故障プロセスと関連するウォッチドッグ１
５は、最初に、ステップ１１１０において、最後の実チ
ェックポイント以降に故障プロセスにメッセージを送信
した全てのプロセスに関して、レシーバログファイル９
０内の、故障プロセスに送信された最初のメッセージよ
り前に位置する論理チェックポイントより後ろの各メッ
セージに対して、処理順番情報を破棄する。これは、故
障プロセスにメッセージを送信した全てのプロセスに関
して、最後の実チェックポイント以降の、故障プロセス
に送信された最初のメッセージより後の全ての論理チェ
ックポイントを無効にする機能を持つ。

【０１１２】その後、故障プロセスと関連するウォッチ
ドッグ１５は、ステップ１１２０において、ステップ４
の回復のための回復ライン３１０を再計算するリクエス
トを故障プロセスの指標と共に中央回復コーディネータ
７５に送信する。中央回復コーディネータ７５がどのよ
うにこのリクエストを処理し、回復ラインを再計算する
かについては、後に、図１５ａと１５ｂとの関連で説明
される。一般的にいって、ステップ４の回復において、
中央回復コーディネータ７５は、故障プロセスにメッセ
ージを送信した各プロセスに対して、故障プロセスに送
信された最初のメッセージより後ろの全ての論理チェッ
クポイントを破棄する。中央回復コーディネータ７５が
回復ラインの再計算を終了すると、これは、再計算され
た回復ラインの情報を各監視下のアプリケーションプロ
セスに同報通信する。再計算された回復ラインを受信す
ると、各監視下のプロセスは、回復ラインを実質的に平
行して処理し、図１１内の処理ブランチ１１３０及び１
１４０によって示されるように、それぞれ、プロセスＰ
₀ 及びＰ_N に対して、適当な応答を決定する。

【０１１３】プロセスＰ₀ は、ステップ１１５０におい
て、中央回復コーディネータ７５から同報通信された回
復ライン３１０を受信する。その後、図１３との関連で
後に説明されるプロセスメッセージログサブルーチン１
３００がステップ１１６０においてプロセスＰ₀ に対し
て実行される。

【０１１４】図６ｆに示されるように、故障プロセスＰ
_２ にメッセージを送信したプロセスに関して、故障プ
ロセスに送信された最初のメッセージよりも後ろの全て
の論理チェックポイントが破棄される。こうして、プロ
セスＰ_１ は、論理チェックポイントＬ_１、１ まで論理
的にロールバックし、Ｐ_３ は論理チェックポイントＬ
_３、１ まで論理的にロールバックすることが要求され
る。プロセスＰ_３ が、メッセージＭ_ｓ の送信を取り消
すことを要求するために、プロセスＰ_４ がこのロール
バックに参入することを要求される。

【０１１５】図１１に示されるように、プロセスＰ_N
は、ステップ１１７０及び１１８０において、同報通信
された回復ライン３１０を受信及び処理するが、これは
プロセスＰ_N によって、プロセスＰ₀ 及び他の全ての監
視下のプロセスの処理と実質的に平行して処理される。
監視下のプロセスの全てが再計算された回復ライン３１
０の処理を終了すると、プログラム制御は、ステップ１
１９０において、プログレッシブ再試行回復アルゴリズ
ム７００に戻り、各プロセスＰ₀ からＰ_N に対して通常
の実行を再開する。前に検出された故障がバイパスされ
た場合は、プログラム制御は、継続される。バイパスさ
れない場合は、エラー検出モニタ２０は、再び故障を検
出し、プログレッシブ再試行回復アルゴリズム７００を
今回はステップ５を試みて再開する。

【０１１６】ステップ５−−広範囲ロールバック プログレッシブ再試行回復アルゴリズム７００のステッ
プ１から４において遂行された全てのローカル化された
再試行が一つ或はそれ以上のソフトウエア故障をバイパ
スすることに失敗した場合は、プログレッシブ再試行回
復アルゴリズム７００は、広範囲ロールバックを実現す
るために、大域的に一貫性のあるセットのチェックポイ
ントを利用する。前述のように、プログレッシブ再試行
回復アルゴリズム７００は、プログレッシブ再試行法の
ステップ５において広範囲ロールバック再試行サブルー
チン１２００を実行する。広範囲ロールバック再試行サ
ブルーチン（ステップ５）１２００は、図１２に示され
るように、ステップ１２０１から開始される。故障プロ
セスと関連するウォッチドッグ１５は、ステップ１２２
０において、ステップ５の回復のための回復ライン３１
０を再計算するリクエストを中央回復コーディネータ７
５に送信する。中央回復コーディネータ７５がこのリク
エストを処理し、回復ラインを再計算する方法について
は、後に図１５ａと１５ｂとの関連で説明される。

【０１１７】中央回復コーディネータ７５が回復ライン
の再計算を終えると、これは各監視下のアプリケーショ
ンプロセスに再計算された回復ライン情報について同報
通信する。再計算された回復ラインを受信すると、各監
視下のプロセスは、それぞれ、プロセスＰ₀ 及びＰ_N に
対して、図１２の処理ブランチ１２３０及び１２４０に
よって示されるように、回復ラインを実質的に平行して
処理し、適当な応答を決定する。プロセスＰ₀ は、ステ
ップ１２５０において、中央回復コーディネータ７５か
ら同報通信された回復ライン３１０を受信する。その
後、後に図１３との関連で説明されるプロセスメッセー
ジログサブルーチン１３００がステップ１２６０におい
てプロセスＰ₀ に対して実行される。同様にして、ステ
ップ１２７０及び１２８０において、プロセスＰ_N は、
同報通信された回復ライン３１０を受信及び処理する
が、これは、プロセスＰ_N によって、プロセスＰ₀ 及び
他の全ての監視下のプロセスの処理と実質的に平行して
処理される。

【０１１８】監視下の全てのプロセスが再計算された回
復ライン３１０の処理を終了すると、プログラム制御
は、ステップ１２９０において、プログレッシブ再試行
回復アルゴリズム７００に戻り、各監視下のプロセスＰ
₀ からＰ_N に対して通常の実行が再開される。前に検出
された故障がバイパスされた場合は、プログラム制御は
継続される。故障がバイパスされなかった場合は、検出
モニタ２０が故障を再び検出し、プログレッシブ再試行
回復アルゴリズム７００を再開するが、今回は、システ
ムを完全に再開することが要求される。

【０１１９】回復再プレイサブルーチン 前述のように、プロセスメッセージログサブルーチン１
３００が、プログレッシブ再試行回復アルゴリズム７０
０の各ステップにおいて、一つ或は複数のプロセスに対
して実行される。プロセスメッセージログサブルーチン
１３００は、関連するプロセスのレシーバログファイル
９０内の全てのメッセージを再計算された回復ラインに
基づいて分類する。その後、プロセスメッセージログサ
ブルーチン１３００は、決定論的メッセージの再プレイ
及び過渡メッセージの再送信を開始する。加えて、プロ
セスメッセージログサブルーチン１３００は、ステップ
２の再試行において、故障プロセスに対する過渡メッセ
ージの並べ替えを行ない、さらに、ステップ４の再試行
においては、故障プロセスにメッセージを送信した全て
のプロセスに関してこれを行なう。プロセスメッセージ
ログサブルーチン１３００は、複数の異なるアプリケー
ションプロセスによって、別個に実質的に平行して遂行
されることに注意する。

【０１２０】プロセスメッセージログサブルーチン１３
００は、ステップ１３０１において任意のプロセスによ
って開始される。ステップ１３１０において、プロセス
メッセージログサブルーチン１３００を実行しているア
プリケーションプロセスの現在のプロセス状態が回復ラ
インの所に位置するか決定するためのテストが遂行され
る。ステップ１３１０において、プロセスメッセージロ
グサブルーチン１３００を実行しているアプリケーショ
ンプロセスの現在のプロセス状態が既に回復ラインの所
にあることが決定された場合は、そのアプリケーション
プロセスは、状態の再生に対する処理を遂行する必要は
ない。従って、プログラム制御は、ステップ１３８０に
おいて、呼び出しファンクションに戻る。ただし、ステ
ップ１３１０において、プロセスメッセージログサブル
ーチン１３００を実行しているアプリケーションプロセ
スの現在のプロセス状態が回復ラインの所にないことが
決定された場合は、関連するアプリケーションプロセス
のレシーバログファイル９０内の全てのメッセージは、
図３との関連で上に定義されたように、決定論的、過
渡、或は孤児メッセージとして分類される。

【０１２１】ステップ１３３０において、プロセスメッ
セージログサブルーチン１３００を実行しているアプリ
ケーションプロセスに対する、これらが回復ラインの後
に送信されたものでありもはや正当でない、全ての孤児
メッセージが破棄される。その後、アプリケーションプ
ロセスは、ステップ１３４０において、その最後の実チ
ェックポイントに戻り、次に、後に図１４ａと１４ｂと
の関連で説明される決定論的再プレイサブルーチン１４
００を開始し、そのアプリケーションプロセスに対する
決定論的メッセージを回復ラインに至るまで再プレイす
る。次に、ステップ１３５０において、再計算された回
復ラインと共に含まれるメッセージが現在のアプリケー
ションプロセスがその過渡メッセージを並べ替えるべき
であることを示すか決定するためのテストが遂行され
る。ステップ２の再試行の場合は、故障プロセスが、そ
のメッセージの並べ替えを行ない、一方、ステップ４の
再試行の場合は、故障プロセスにメッセージを送信した
プロセスが、それらのメッセージの並べ替えを行なうこ
とに注意する。一つの好ましい実施例においては、中央
回復コーディネータ７５は、図１５ａと１５ｂとの関連
で後に説明されるように、再計算された回復ラインと共
にメッセージベクトルを送信する。このメッセージベク
トルは、各監視下のプロセスに対して一つの欄を持つ。
ある特定のプロセスがその過渡メッセージを並べ替える
ことを要求される場合は、メッセージベクトル内の対応
する欄が、好ましくは、“０１”の二進値にセットされ
る。

【０１２２】一つの好ましい実施例においては、ステッ
プ２及びステップ４の再試行において過渡メッセージの
並べ替えを行なうための複数のオプションが提供され
る。省略時並べ替えオプションにおいては、好ましく
は、異なる参照識別子を持つ過渡メッセージがランダム
に並べ替えられるが、ただし、好ましくは、同一の参照
識別子を持つ同一の送信プロセスからのメッセージの順
番は維持される。こうして、メッセージが送信されると
きに参照識別子を指定することによって、必要に応じ
て、メッセージの従属性を強化することが可能である。
別の並べ替えオプションとして、同一プロセスからのメ
ッセージを一つのグループにまとめ、資源の解放を要求
するメッセージを資源の割り当てを要求するメッセージ
が実行される前に実行し、また、メッセージログ内に二
つのメッセージのみが存在する場合は、順番を反対にす
ることも可能である。

【０１２３】ステップ１３５０において、現在のアプリ
ケーションプロセスがその過渡メッセージの並べ替えを
行なうべきであることが決定された場合は、ステップ１
３７０において、これらの再プレイ及び再処理を行なう
前に、これらメッセージが適当に並べ替えられる。ただ
し、ステップ１３５０において、現在のアプリケーショ
ンプロセスがその過渡メッセージを並べ替えるべきでな
いことが決定された場合は、これらメッセージは、ステ
ップ１３６０において、適当なアプリケーションプロセ
スに伝送するために、単純に、通信チャネルに再供給さ
れる。その後、プログラム制御はステップ１３８０に進
み、ここで制御は呼び出しファンクションに戻る。

【０１２４】前述のように、決定論的再プレイサブルー
チン１４００は、プロセスメッセージログサブルーチン
１３００のステップ１３４０において、アプリケーショ
ンプロセスがその最後の実チェックポイントにロールバ
ックした後に実行される。決定論的再プレイサブルーチ
ン１４００は、あるアプリケーションプロセスのレシー
バログファイル９０内の全ての決定論的メッセージを決
定論的に再プレイし、これによって、状態の再生を可能
にする。加えて、決定論的再プレイサブルーチン１４０
０は、後に説明されるように、好ましくは、ピースワイ
ズ決定論的想定を検証するためのメカニズムを含む。決
定論的再プレイサブルーチン１４００は、ステップ１４
０１から開始される。その後、決定論的再プレイサブル
ーチン１４００は、ステップ１４１０において、現在の
アプリケーションプロセスのレシーバログファイル９０
から現在のメッセージを取り出し、次に、ステップ１４
１５において、取り出されたメッセージを処理する。

【０１２５】ステップ１４２０において、アプリケーシ
ョンプロセスによる現在取り出されたメッセージの処理
の結果として、送信されるべき一つ或はそれ以上のメッ
セージが生成されるか調べるためのテストが遂行され
る。ステップ１４２０においてアプリケーションプロセ
スによる現在取り出されたメッセージの処理の結果とし
て送信されるべきメッセージが生成されないことが決定
された場合は、プログラム制御は、後に説明されるステ
ップ１４４５に進む。ただし、ステップ１４２０におい
てアプリケーションプロセスによる現在取り出されたメ
ッセージの処理の結果として送信されるべき少なくとも
一つのメッセージが生成されたことが決定された場合
は、ステップ１４２５において、ピースワイズ決定論的
想定を検証するためのテストが遂行される。これは、回
復の現在のステップにおいて再生されたメッセージが初
期の実行の際にセンダログファイル９２内に格納された
メッセージと同一であるか検証することによって行なわ
れる。

【０１２６】ステップ１４２５において、再生されたメ
ッセージがセンダログファイル９２内に格納されたメッ
セージと同一であることが発見された場合は、ステップ
１４３０において、再計算された回復ラインと共に含ま
れるメッセージが再生されたメッセージが故障プロセス
に向けられる場合に現在のアプリケーションプロセスが
実際に再生されたメッセージを送信すべきであることを
示すかを決定するためのテストが遂行される。故障プロ
セスにメッセージを送信したプロセスは、ステップ３の
再試行においてこれら再生されたメッセージを再送信す
ることに注意する。一つの好ましい実施例においては、
中央回復コーディネータ７５は、図１５ａと１５ｂとの
関連で後に説明されるように、再計算された回復ライン
と共にメッセージベクトルを送信する。このメッセージ
ベクトルは、各監視下のプロセスに対する欄を持つ。あ
る特定のプロセスがステップ３の再試行において故障プ
ロセスにメッセージを再送信すべきであるときは、メッ
セージベクトル内の各々の欄が、好ましくは、“１０”
の二進値にセットされる。

【０１２７】ステップ１４３０において、再計算された
回復ラインと共に含まれるメッセージが現在のアプリケ
ーションプロセスが実際に再生されたメッセージを送信
すべきであることを示さない場合は、プログラム制御
は、後に説明されるように、メッセージを送信すること
なしに、ステップ１４４０に進む。ただし、ステップ１
４３０において、再計算された回復ラインと共に含まれ
るメッセージが現在のアプリケーションプロセスが実際
に再生されたメッセージを送信すべきであり、その再生
されたメッセージが故障プロセスに向けられるべきであ
ることが示される場合は、このメッセージは、ステップ
１４３５において、故障プロセスに向けられる。

【０１２８】ステップ１４４０において、現在受信され
たメッセージの処理に基づいて、送信されるべき追加の
メッセージが存在するか決定するためのテストが遂行さ
れる。ステップ１４４０において、現在の受信されたメ
ッセージの処理に基づいて送信されるべき追加のメッセ
ージが存在することが決定された場合は、プログラム制
御はステップ１４２５に戻り、上に説明の方法で継続す
る。ただし、ステップ１４４０において、現在受信され
たメッセージの処理に基づいて送信すべき追加のメッセ
ージが存在しないことが決定された場合は、プログラム
制御はステップ１４４５に進む。

【０１２９】ステップ１４４５においてレシーバログフ
ァイル９０内に処理されるべき追加の決定論的メッセー
ジが存在しないか決定するためのテストが遂行される。
ステップ１４４５において、レシーバログファイル９０
内に処理されるべき追加の決定論的メッセージが存在す
ることが決定された場合は、プログラム制御はステップ
１４１５に戻り、上に説明の方法で継続される。一方、
ステップ１４４５において、レシーバログファイル９０
内に処理されるべき追加の決定論的メッセージが存在し
ないことが決定された場合は、プログラム制御は、ステ
ップ１４４７において、プロセスメッセージログサブル
ーチン１３００に戻る。

【０１３０】ただし、ステップ１４２５において、再生
されたメッセージがセンダログファイル９２内に格納さ
れたメッセージと同一でないことが決定された場合は、
非決定論的な事象が発生しており、ピースワイズ決定論
的想定は許されない。従って、ステップ１４５０（図１
４ｂ）において、この非決定論的な事象より後の現在の
アプリケーションプロセスに対する全ての論理チェック
ポイントが破棄される。

【０１３１】現在のアプリケーションプロセスと関連す
るウォッチドッグ１５は、次に、ステップ１４５５にお
いて、中央回復コーディネータ７５に回復ライン３１０
を再計算するリクエストを送信する。中央回復コーディ
ネータ７５がこのリクエストを処理し、回復ラインを再
計算する方法は、図１５ａと１５ｂとの関連で後に説明
される。

【０１３２】中央回復コーディネータ７５が回復ライン
の再計算を終えると、これは、再計算された回復ライン
情報を各監視下のアプリケーションプロセスに同報通信
する。再計算された回復ラインを受信すると、各監視下
のプロセスは、それぞれ、プロセスＰ₀ 及びＰ_N に対し
て、図１４ｂ内の処理ブランチ１４６０及び１４６５に
よって示されるように、再計算された回復ラインを実質
的に平行して処理し、適当な応答を決定する。

【０１３３】プロセスＰ₀ は同報通信された回復ライン
３１０をステップ１４７０において中央回復コーディネ
ータ７５から受信する。その後、ステップ１４７５にお
いて、図１３と関連して上で説明されたプロセスメッセ
ージログサブルーチン１３００がプロセスＰ₀ に対して
再実行される。同様にして、プロセスＰ_N は、ステップ
１４８０及び１４８５において、同報通信された回復ラ
イン３１０を受信及び処理するが、これは、プロセスＰ
_N によって、プロセスＰ₀ 及び他の全ての監視下のプロ
セスの処理と実質的に平行して処理される。

【０１３４】全ての監視下のプロセスが再計算された回
復ライン３１０の処理を終了すると、プロセス制御はス
テップ１４９０においてプログレッシブ再試行回復アル
ゴリズム７００に戻り、各監視下のプロセスＰ₀ からＰ
_N に対して通常の実行が再開される。前に検出された故
障がバイパスされた場合は、プログラム制御は継続され
る。故障がバスパスされなかった場合は、エラー検出モ
ニタ２０が再び故障を検出し、プログレッシブ再試行回
復アルゴリズム７００が再開される。

【０１３５】回復ラインの計算 前述のように、故障プロセスを監視しているウォッチド
ッグ１５は、プログレッシブ再試行回復アルゴリズム７
００のステップ２から５の各々において、中央回復コー
ディネータ７５に、回復ラインを計算するリクエストを
送信する。中央回復コーディネータ７５は、これらリク
エストを処理し、図１５ａと１５ｂに示される回復ライ
ン計算アルゴリズム１５００を実行する。回復ライン計
算アルゴリズム１５００は、回復ラインの計算に対する
リクエストを受信した時点で、ステップ１５０５から開
始される。前述のように、回復ライン計算リクエスト
は、プログレッシブ再試行回復アルゴリズム７００の現
在のステップの指標及び故障プロセスの指標を含む。

【０１３６】その後、回復ライン計算アルゴリズム１５
００は、ステップ１５１０において、再計算された回復
ラインと共に同報通信されるメッセージベクトルをリセ
ットする。一つの好ましい実施例においては、メッセー
ジベクトルは、メッセージを各監視下のアプリケーショ
ンプロセスに送信するための欄を含むことに注意する。
二進メッセージ値００は、好ましくは、関連するアプリ
ケーションプロセスが通常のモードであることを示す。
二進メッセージ値０１は、好ましくは、関連するアプリ
ケーションプロセスが、そのレシーバログファイル９０
内のメッセージをそれらが再プレイ及び再処理される前
に並べ替えるべきであることを示す。最後に、二進メッ
セージ値１０は、好ましくは、関連するアプリケーショ
ンプロセスがステップ３の再試行において故障アプリケ
ーションプロセスに実際にメッセージを再送信すべきで
あることを示す。

【０１３７】ステップ１５１５において、プログレッシ
ブ再試行回復アルゴリズム７００によって制御され、現
在のステップ番号を決定するカウンタ変数Ｎが２に等し
いか決定するためのテストが遂行される。ステップ１５
１５においてカウンタ変数Ｎの値が２に等しいことが決
定された場合は、これは、中央回復コーディネータ７５
が現在の故障の回復のために回復ラインを再計算する最
初の試みである。中央回復コーディネータ７５は、ステ
ップ１の回復には巻き込まれないことに注意する。

【０１３８】従って、中央回復コーディネータ７５は、
ステップ１５２０において、監視下の全てのアプリケー
ションプロセスに、それらのレシーバログファイル９０
内の全てのメッセージに関して従属情報を要求するメッ
セージを同報通信する。中央回復コーディネータ７５
は、ステップ１５２５において各監視下のプロセスから
送信された従属情報を受信する。故障プロセスは、レシ
ーバ並べ替えサブルーチン（ステップ２）９００の実行
の際に最後の実チェックポイントより後のそのレシーバ
ログファイル９０内のメッセージに対する処理順番情報
を破棄するが、これは、結果として、最初に受信された
メッセージより後の論理チェックポイントを無効にする
機能を果たすことに注意する。従って、回復ライン計算
アルゴリズム１５００は、ステップ１５２８において、
最後の実チェックポイント以降に故障プロセスによって
受信された最初のメッセージより後の従属情報から故障
プロセスに対する論理チェックポイントを除去すべきで
ある。

【０１３９】ステップ２の再試行においては、故障プロ
セスのみがそのレシーバログファイル９０内のメッセー
ジの並べ替えを行なうべきである。従って、回復ライン
計算アルゴリズム１５００は、ステップ１５３０におい
て、故障プロセスに対するメッセージベクトル欄を二進
値の“０１”にセットし、故障プロセスが、そのレシー
バログファイル９０内の過渡メッセージを、それらを再
プレイ及び再処理する前に並べ替えるべきであることを
示す。その後、プログラム制御は、ステップ１５７０
（図１５ｂ）に進む。

【０１４０】ただし、ステップ１５１５においてカウン
タ変数Ｎの値が２に等しくないことが決定された場合
は、ステップ１５３５においてカウンタ変数Ｎの値が３
に等しいか決定するためのテストが遂行される。ステッ
プ３の再試行に対しては、回復ライン計算アルゴリズム
１５００は、ステップ２の再試行に対して決定されたの
と同一の回復ラインを構成するが、ただし、メッセージ
ベクトルが修正される点に注意する。ステップ１５３５
において、カウンタ変数Ｎの値が３に等しいことが決定
された場合は、回復ライン計算アルゴリズム１５００
は、ステップ１５４０において、故障プロセスにメッセ
ージを送信した監視下の全てのアプリケーションプロセ
スに対してメッセージベクトル欄を二進値の“１０”に
セットし、これらプロセスがそれらのレシーバログファ
イル９０内の決定論的メッセージを実際に再送信すべき
であることを示す（図１５ｂ）。

【０１４１】ただし、ステップ１５３５において、カウ
ンタ変数Ｎの値が３に等しくないことが決定された場合
は、ステップ１５４５において、カウンタ変数Ｎの値が
４に等しいか決定するためのテストが遂行される。ステ
ップ１５４５においてカウンタ変数Ｎの値が４に等しい
ことが決定された場合は、回復ライン計算アルゴリズム
１５００は、ステップ１５５０において、故障プロセス
にメッセージを送信した全てのプロセスについて、後に
説明される通信グラフから、故障プロセスに送信された
最初のメッセージより後ろの全ての論理チェックポイン
トを除去する。

【０１４２】その後、回復ライン計算アルゴリズム１５
００は、ステップ１５５５において、故障プロセスにメ
ッセージを送信した全ての監視下のアプリケーションプ
ロセスに対してメッセージベクトル欄を二進値の“０
１”にセットし、これらのプロセスがそれらのレシーバ
ログファイル９０内の過渡メッセージをこれらを再プレ
イ及び再処理する前に並べ替えるべきであることを示
す。その後、プログラム制御は、ステップ１５７０に進
む（図１５ｂ）。ただし、ステップ１５４５においてカ
ウンタ変数Ｎの値が４に等しくないことが決定された場
合は、ステップ１５６０（図１５ｂ）において、カウン
タ変数Ｎの値が５に等しいか決定するためのテストが遂
行される。ステップ１５６０において、カウンタ変数Ｎ
の値が５に等しい場合は、回復ライン計算アルゴリズム
１５００は、ステップ１５６５において、全ての監視下
のプロセスについて、全ての監視下のプロセスのそれら
の一貫性のある大域チェックポイントに至るまでの広範
囲ロールバックを開始するために、全ての論理チェック
ポイントを破棄する。その後、プログラム制御は、ステ
ップ１５７０（図１５ｂ）に進む。

【０１４３】プログラム制御がステップ１５７０（図１
５ｂ）に到達した時点では、回復ライン計算アルゴリズ
ム１５００は、既にそのステップ２の再試行の実行の際
に従属情報を集めており、また、必要であれば、ステッ
プ４とステップ５の再試行に対するステップ１５５０及
びステップ１５６５において、従属情報の修正を終了し
ている。回復ライン計算アルゴリズム１５００は、ステ
ップ１５７０において、必要に応じて修正されたこれら
従属情報を使用して通信グラフを構成し、次に、ステッ
プ１５８０において、ロールバック伝播アルゴリズムと
構成された通信グラフを使用して、回復ラインを再計算
する。通信グラフを構成するため、及び回復ラインを計
算するためにロールバック伝播アルゴリズムを適用する
ための、適当な方法の説明に関しては、Yi-Min Wang と
W.Kent Fuchsによって、Proc. IEEE Symposium Reliabl
e Distributed Systems、pp.78-85（Oct.1993) に掲載の
論文『Lazy Checkpoint Coordination for Bounding Ro
llback Propagation』を参照されたい。その後、回復ラ
イン計算アルゴリズム１５００は、再計算された回復ラ
インをメッセージベクトルと共に、全ての監視下のアプ
リケーションプロセスに同報通信し、これらは、上に説
明の方法によって処理される。

【０１４４】メッセージ並べ替えによるバイパス 特定の故障の性質に関する情報を得ることができる場合
は、プログレッシブ再試行回復アルゴリズム７００の並
べ替えステップに直接に進むのが適当である。プログレ
ッシブ再試行回復アルゴリズム７００の再プレイステッ
プ、つまり、ステップ１及び３は、非決定論的な振る舞
いをするアプリケーションプロセス内のソフトウエア故
障をバスパスするのに適する。ただし、これら再プレイ
ステップは、決定論的な振る舞いを示すアプリケーショ
ンプロセス、換言すれば、同一の入力を与えられた場合
同一に振る舞うアプリケーションプロセス内の故障をバ
イパスするのには適当でない。従って、決定論的な振る
舞いを示すことが知られている特定のアプリケーション
プロセスに対しては、回復は、直接に並べ替えステッ
プ、つまり、ステップ２及び４に進むべきである。

【０１４５】一つの実施例においては、故障耐性ライブ
ラリ８２には、あるアプリケーションプロセスによって
呼び出されると、非決定論ビットをセットし、そのプロ
セスがある非決定論的な振る舞い、例えば、時間従属事
象、システム呼の失敗、或は信号の割り込みを含むこと
を示す一つのファンクションが含まれる。従って、エラ
ー検出モニタ２０によってアプリケーションプロセス内
にある故障が検出されると、再開サブシステム３０は、
非決定論ビットの値を評価し、このビットがそのアプリ
ケーションプロセスによってセットされているか決定す
る。このビットがセットされている場合は、その回復
は、ステップ１の再試行から開始されるべきである。た
だし、このビットがセットされてない場合は、回復は、
直接に並べ替えステップに進むべきである。この並べ替
えステップは、故障プロセスによって受信された入力の
シーケンスを並べ替える機能を果たす。故障プロセスに
よって受信された順序を持つ入力は、メッセージ、ファ
イル、事象、動作或は他のデータであり得ることに注意
する。

【０１４６】加えて、資源割り当て問題、例えば、資源
の枯渇に起因することが知られているソフトウエア故障
からの回復も直接にステップ２の並べ替えに進むべきで
ある。例えば、あるシステムが二つのファイル記述子の
みを持ち、そのシステムが３つの一連のファイルを開く
リクエストを、その間にはさまれたファイルを閉じるリ
クエストなしに受信すると、このシステムは、ファイル
記述子を使いつくしてまい、結果として資源割り当て問
題が発生する。ただし、システムがその入力のシーケン
スの並べ替えを行なう場合は、ファイルを閉じるリクエ
ストをファイルを開く第三のリクエストの前に処理する
ことによって、このソフトウエア故障をバスパスするこ
とが可能である。さらに、プロセスが入力が特定の順番
で到着することを想定するが、これらが実際にはそれと
は異なる順番で到着するようなレーシングバグに起因す
ることが知られているソフトウエア故障からの回復もス
テップ２の並べ替えに進むべきである。こうして、入力
のシーケンスが並べ替えられると、これらが適当な順番
を取り、ソフトウエア故障をバスパスする機会が得られ
る。

【０１４７】一例 ステップ１の再試行の解説 あるシステムが共有データ構造にアクセスする複数のプ
ロセスを含み、互いに排他的なアクセスを確保するため
のロッキングメカニズムがバグを含む或はシステム内に
このメカニズムが存在しない場合は、あるプロセスがデ
ータ構造の読出しを試みている際に別のプロセスがデー
タ構造の更新、例えば、新たなデータノードを挿入する
ためにポインタの操作を行なうような事態が発生し得
る。このような場合、読出しプロセスが、セグメント化
違反故障を受信し、これがウォッチドッグ１５によって
検出され、このために回復が再開されることとなる。読
出しプロセスが再開され、ステップ１の再試行の際に再
び同一のデータ構造にアクセスするためのリクエストメ
ッセージが再プレイされた場合、この読出し動作は、デ
ータ構造を更新するプロセスが更新を終えている可能性
が高いために、成功することとなる。

【０１４８】注意すべき点として、このタイプの故障
は、互いに排他的なアクセスを保証するためのロッキン
グメカニズムを提供することによって回避することもで
きるが、キメの粗いロックは、結果として、読出しプロ
セスを不必要にブロックすることとなり、反対に、キメ
の細かいロックは、結果として、大きな性能の劣化を引
き起こし、追加のソフトウエア上の複雑さを導入するこ
ととなる。従って、プログレッシブ再試行法のステップ
１のメッセージ再プレイは、同時性問題を扱うためのロ
ッキングメッセージに対する信頼性があり、効率の良い
代替を提供する。

【０１４９】ステップ２の再試行の解説 ファイルを維持するためのファイルシステムは、通常、
３つの主要な動作、つまり、ファイルを開く動作、ファ
イルに書込む動作及びファイルを閉じる動作を利用す
る。ファイルを識別するために利用されるファイル記述
子の数は限られているために、ファイルシステムがファ
イル記述子を使い尽くしてしまうことがある。従って、
ファイルシステムは、現在幾つのファイルが開かれてい
るかを追跡することが要求される。全てのファイル記述
子が利用された場合には、境界条件が発生することとな
る。この境界条件を扱う資源マネジャがバグを持つ場
合、ファイルシステムは、境界条件が発生する度にハン
グアップすることとなる。

【０１５０】以下の例はステップ２のメッセージ並べ替
えによって、いかにしてファイルシステム内の境界条件
がバイパスできるかを解説する。ここで、コマンドＯ₁
は、ファイル１を開くコマンドを表わし、コマンドＷ₁
はファイル１にデータを書込むコマンドを表わし、コマ
ンドＣ₁ は、ファイル１を閉じるコマンドを表わし、ま
た、ファイルシステムは、同時に、最高２つまでの開い
たファイルを持つことができるものとする。このファイ
ルシステムがコマンドシーケンス、 Ｏ₁ Ｏ₂ Ｗ₁ Ｗ₂ Ｏ₃ Ｗ₃ Ｃ₁ Ｃ₂ を受信した場合、このファイルシステムは、Ｏ₃ を処理
した段階で境界条件に入り、ハングアップすることとな
る。すると、ソフトウエア故障がウォッチドッグ１５に
よって検出され、これは、故障プロセスの再開を開始す
る。

【０１５１】注意すべき点として、この故障は、ステッ
プ１の再試行によっては、これらメッセージがレシーバ
ログファイル９０から同一の順番で再プレイされた場合
は、境界条件がこれでも発生するために、バスパスする
ことはできない。従って、プログレッシブ再試行回復ア
ルゴリズム７００は、ステップ２の再試行に進む。ステ
ップ２の再試行において、メッセージシーケンスが以下
のように並べ替えられることとなる。 Ｏ₁ Ｗ₁ Ｃ₁ Ｏ₂ Ｗ₂ Ｃ₂ Ｏ₃ Ｗ₃ こうして並べ替えられたメッセージが故障プロセスによ
って、再プレイされ、再処理された場合、境界条件は発
生せず、ソフトウエア故障はバイパスされることとな
る。

【０１５２】ステップ３の再試行の解説 相互接続システムにおいては、チャネル制御モニタ（Ｃ
ＣＭ）プロセスが電話通信スイッチ内の空いたチャネル
を追跡するために利用される。ＣＣＭプロセスは、２つ
の他のプロセス、つまり：チャネル割り当てリクエスト
を送信するチャネル割り当て（ＣＡ）プロセスと、チャ
ネル割り当て解除リクエストを送信するチャネル割り当
て解除プロセス、からメッセージを受信する。ＣＣＭプ
ロセスに対する境界条件は、全てのチャネルが使用され
ており、プロセスが追加の割り当てリクエストを受信し
たときに発生する。境界条件が発生すると、幾つかのチ
ャネルを解放するため或はそれ以上のリクエストをブロ
ックするために、クリーンアップ手続きが呼び出され
る。ただし、このクリーンアップ手続きがソフトウエア
エラーを含む場合は、このクリーアップ手続きは、バグ
がトリガされたときクラッシュすることとなる。

【０１５３】以下の例は、ステップ３のメッセージ再プ
レイが故障をいかにしてバスパスするために利用できる
かを解説する。ここで、利用できるチャネルの数は５で
あり、コマンドｒ₂ は、二つのチャネルを要求するコマ
ンドを表わし、コマンドｆ₂は、二つのチャネルを解放
するコマンドを表わすものとする。境界条件のために、
以下のコマンドシーケンス、つまり、 ＣＡが ｒ₂ ｒ₃ ｒ₁ を送信 ＣＤが ｆ₂ ｆ₃ ｆ₁ を送信 ＣＣＭが ｒ₂ ｒ₃ ｒ₁ を受信 はＣＣＭプロセスのクラッシュを起こすこととなる。つ
まり、ＣＣＭプロセスは、ｒ₁ を受信した時点でクラッ
シュし、結果として、境界条件が発生する。ただし、Ｃ
ＣＭプロセスが、このクラッシュの前にメッセージｆ₂
を受信し、登録する場合は、ＣＣＭプロセスは、これら
の登録されたメッセージ（メッセージログ）を並べ替え
ることによって回復可能である。ただし、ＣＣＭプロセ
スがｆ₂ コマンドを登録する前にクラッシュした場合>
は、ステップ２に再試行によるメッセージｒ₂ 、ｒ₃ 、
ｒ₁ の並べ替えは、役立たない。この場合には、ＣＣＭ
のローカル的な回復は失敗し、ＣＡ及びＣＤは、それら
のメッセージを再送信することが要求される（ステップ
３）。

【０１５４】オペレーティングシステムのスケジューリ
ング及び伝送遅延の非決定性のために、これらメッセー
ジは、ステップ３のメッセージ再プレイにおいて、ＣＣ
Ｍプロセスの所に異なる順番で到着する可能性がある。
例えば、ＣＣＭプロセスが、これらメッセージを以下の
順番で受信することも考えられる。 ｒ₂ ｆ₂ ｒ₃ ｆ₃ ｒ₁ ｆ₁ この場合は境界条件は発生せず、従って、ステップ３の
再試行は、成功することとなる。

【０１５５】ステップ４の再試行の解説 我々は、我々の第四番目の例として、交換システム内で
の信号ルーティングポイント（ＳＲＰ）の使用を挙げ
る。ＳＲＰの任務は、データパケットを発信スイッチか
ら宛先スイッチにルートすることにある。各ＳＲＰは、
そのバッファ内のパケットの数がしきい値を超えたと
き、入りトラヒックを低減するために、用心のために他
のＳＲＰにＯＣメッセージを送信するための内臓式の過
負荷制御（ＯＣ）メカニズムを持つ。通常の動作におい
ては、ＳＲＰ−Ｘは、あるスイッチに向けられたデータ
パケットをＳＲＰ−Ａ或はＳＲＰ−Ｂのいずれかを通じ
てルートできるものと想定する。ＳＲＰ−ＸがＳＲＰ−
ＡからのＯＣメッセージを受信すると、これは、ＳＲＰ
−Ａの潜在的な過負荷を回避するために、ＳＲＰ−Ｂを
通じて全てのデータパケットをルートすることを開始す
る。ただし、同時に、ＳＲＰ−Ｂに直接に接続されたス
イッチは、サービスリクエストの突然のバーストを受信
する。これら二つのタイプのトラヒックは、ＳＲＰ−Ｂ
のバッファをすぐに満杯にし、このプロセスは、過負荷
制御メカニズムが呼び出される前にクラッシュし、ソフ
トウエア故障が発生する。

【０１５６】ステップ１から３におけるメッセージの再
プレイ及び並べ替えを通じてのＳＲＰ−Ｂのローカル的
な再試行では、これらが過負荷状態をバイパスすること
ができないために、故障を回復することはできない。こ
のために、ＳＲＰ−Ｘメッセージの再プレイを巻き込む
ステップ３の再試行でも、同一の故障が発生する。従っ
て、ＳＲＰ−Ｘは、ステップ４の再試行を開始し、ルー
トされるべきパケットとＳＲＰ−ＡからのＯＣメッセー
ジの並べ替えを試みる。これは、結果として、ＯＣメッ
セージの処理を遅らせ、ＳＲＰ−Ｂを通じてのトラヒッ
クを低減し、ＳＲＰ−Ｂに回復する機会を与える。ＳＲ
Ｐ−Ａに対する潜在的な過負荷は、起こらない場合もあ
り、発生した場合でも、ソフトウエア故障を起こすこと
なしに問題なく扱うことが可能となる。ここに示され解
説された幾つかの実施例及びバリエーションは、単に、
本発明の原理を解説するためのものであり、当業者にお
いては、様々な修正を、本発明の精神及び範囲から逸脱
することなしに実現することが可能であることが理解で
きるものである。

【図面の簡単な説明】

【図１】本発明に従う故障耐性計算システムを図解する
略ブロック図である。

【図２ａ】通信グラフを図解し、実チェックポイントと
論理チェックポイントを解説する図の１である。

【図２ｂ】通信グラフを図解し、実チェックポイントと
論理チェックポイントを解説する図の２である。

【図３】通信グラフを図解し、再開、回復ラインとメッ
セージの分類について解説する。

【図４ａ】図１の故障耐性計算システム内で実行する各
監視下のアプリケーションプロセスに対して現在の情報
を維持する故障耐性プロセスリストを図解する。

【図４ｂ】図１の故障耐性計算システムの多重モード環
境内の現在アクティブな各処理ノードのリストを維持す
るノードリストを図解する。

【図５ａ】それぞれ、関連するアプリケーションプロセ
スによって、それぞれ、受信或は送信されたメッセージ
の各々に関する情報を維持するレシーバログファイル及
びセンダログファイルの図解の１である。

【図５ｂ】それぞれ、関連するアプリケーションプロセ
スによって、それぞれ、受信或は送信されたメッセージ
の各々に関する情報を維持するレシーバログファイル及
びセンダログファイルの図解の２である。

【図６ａ】複数の平行アプリケーションプロセスに対す
る通信パターンを図解し、これらプロセスが図７のプロ
グレッシブ再試行回復アルゴリズムの様々なステップに
よってどのような効果を受けるかを示す図の１である。

【図６ｂ】複数の平行アプリケーションプロセスに対す
る通信パターンを図解し、これらプロセスが図７のプロ
グレッシブ再試行回復アルゴリズムの様々なステップに
よってどのような効果を受けるかを示す図の２である。

【図６ｃ】複数の平行アプリケーションプロセスに対す
る通信パターンを図解し、これらプロセスが図７のプロ
グレッシブ再試行回復アルゴリズムの様々なステップに
よってどのような効果を受けるかを示す図の３である。

【図６ｄ】複数の平行アプリケーションプロセスに対す
る通信パターンを図解し、これらプロセスが図７のプロ
グレッシブ再試行回復アルゴリズムの様々なステップに
よってどのような効果を受けるかを示す図の４である。

【図６ｅ】複数の平行アプリケーションプロセスに対す
る通信パターンを図解し、これらプロセスが図７のプロ
グレッシブ再試行回復アルゴリズムの様々なステップに
よってどのような効果を受けるかを示す図の５である。

【図６ｆ】複数の平行アプリケーションプロセスに対す
る通信パターンを図解し、これらプロセスが図７のプロ
グレッシブ再試行回復アルゴリズムの様々なステップに
よってどのような効果を受けるかを示す図の６である。

【図７】検出された故障を回復するために再開サブシス
テムによって利用される一例としてのプログレッシブ再
試行回復アルゴリズムを説明する流れ図である。

【図８】図７のプログレッシブ再試行回復アルゴリズム
のステップ１において利用される一例としてのレシーバ
再プレイサブルーチンを説明する流れ図である。

【図９】図７のプログレッシブ再試行回復アルゴリズム
のステップ２において利用される一例としてのレシーバ
並べ替えサブルーチン９００を説明する流れ図である。

【図１０】図７のプログレッシブ再試行回復アルゴリズ
ムのステップ３において利用される一例としてのセンダ
再プレイサブルーチンを説明する流れ図である。

【図１１】図７のプログレッシブ再試行回復アルゴリズ
ムのステップ４において利用される一例としてのセンダ
並べ替えサブルーチンを説明する流れ図である。

【図１２】図７のプログレッシブ再試行回復アルゴリズ
ムのステップ５において利用される一例としての広範囲
ロールバック再試行サブルーチンを説明する流れ図であ
る。

【図１３】図７のプログレッシブ再試行回復アルゴリズ
ムのステップ２から５の際に利用される一例としてのプ
ロセスメッセージログサブルーチンを説明する流れ図で
ある。

【図１４ａ】一体となって図１３のプロセスメッセージ
ログサブルーチンによって回復の際に図５ａと５ｂのメ
ッセージログ内のメッセージを決定論的に再プレイする
ために利用される一例としての決定論的再プレイサブル
ーチンを説明する流れ図の１である。

【図１４ｂ】一体となって図１３のプロセスメッセージ
ログサブルーチンによって回復の際に図５ａと５ｂのメ
ッセージログ内のメッセージを決定論的に再プレイする
ために利用される一例としての決定論的再プレイサブル
ーチンを説明する流れ図の２である。

【図１５ａ】一体となって図７のプログレッシブ再試行
回復アルゴリズムの様々なステップに対する新たな回復
ラインの計算において中央回復コーディネータによって
利用される一例としての回復ライン計算アルゴリズムを
説明する流れ図の１である。

【図１５ｂ】一体となって図７のプログレッシブ再試行
回復アルゴリズムの様々なステップに対する新たな回復
ラインの計算において中央回復コーディネータによって
利用される一例としての回復ライン計算アルゴリズムを
説明する流れ図の２である。

【符号の説明】

１０、１２ ノード ５０、５２、５４ 処理ユニット ５５、５７ メモリユニット

───────────────────────────────────────────────────── フロントページの続き (72)発明者 エンナン ファン アメリカ合衆国 08807 ニュージャー シィ，ブリッジウォーター，リンバーガ ー ドライヴ 33 (72)発明者 チャンドラ モハン キンタラ アメリカ合衆国 07059 ニュージャー シィ，ウォーレン，マウンテン アヴェ ニュー 29 (72)発明者 イー−ミン ワン アメリカ合衆国 07922 ニュージャー シィ，バークレイ ハイツ，パインウッ ド クレッサント 10 (56)参考文献 特公 昭60−29412（ＪＰ，Ｂ２) (58)調査した分野(Int.Cl.⁷，ＤＢ名) G06F 11/14 G06F 15/00

Claims (16)

(57)【特許請求の範囲】
1. 【請求項１】 アプリケーションプロセス内の故障をバ
   スパスするための装置であって、この装置が： 複数の平行アプリケーションプロセスを実行するための
   少なくとも一つのプロセッサ； 一つ或はそれ以上の前記のアプリケーションプロセスを
   監視するためのエラー検出モニタ（２０）及びこのモニ
   タによって前記の複数のアプリケーションプロセスの一
   つの中に検出された故障をバイパスするためにプログレ
   ッシブ再試行回復アルゴリズム（７００）を実行するた
   めの再開サブシステム（３０）を含むウォッチドッグ
   （１５）；及び前記のアプリケーションプロセスを故障
   耐性にするために前記の一つ或はそれ以上のアプリケー
   ションプロセスから呼び出すことができる複数の故障耐
   性ライブラリファンクション（８２）を格納するための
   メモリデバイス（５５）を含み、この故障耐性ライブラ
   リが： あるアプリケーションプロセスと関連するデータのチェ
   ックポイント化動作を定期的に遂行するためのチェック
   ポイントファンクション； 回復モードの間に、前記メモリデバイスに含まれる不揮
   発性メモリ（４４）からチェックポイント化されたデー
   タを復元するための回復ファンクション； 前記のアプリケーションプロセスによって生成された各
   出力メッセージを、前記の各出力メッセージがそのアプ
   リケーションプロセスによって別のアプリケーションプ
   ロセスに伝送される前に前記不揮発性メモリに記憶され
   たセンダログファイル（９２）内に登録するための故障
   耐性書込みファンクションであって、回復モードの間に
   一つ或はそれ以上の前記の出力メッセージを抑圧するた
   めのメカニズムを含むような故障耐性書き込みファンク
   ション；及び前記のアプリケーションプロセスによって
   別のアプリケーションプロセスから受信された各入力メ
   ッセージをそれらが受信アプリケーションプロセスによ
   って処理される前に前記不揮発性メモリに記憶されたレ
   シーバログファイル（９０）内に登録するための故障耐
   性読出しファンクションであって、通常の動作において
   は、通信チャネルから入力データを読出して受信された
   各入力メッセージをレシーバログファイル内に登録し、
   回復モードにおいては、この入力データが前記のレシー
   バログファイルから読出されるようになっている故障耐
   性読出しファンクションを含むことを特徴とする装置。
2. 【請求項２】 前記の故障耐性ライブラリがさらに所定
   の間隔で前記のエラー検出モニタに関連するプロセスが
   まだアクティブであることを示すハートビートメッセー
   ジを送信するためのファンクションを含み、前記のエラ
   ー検出モニタが前記のアプリケーションプロセスからの
   ハートビート信号が前記の所定の間隔が終了する前に受
   信されなかったときに故障を検出することを特徴とする
   請求項１の故障バイパス装置。
3. 【請求項３】 前記の故障耐性ライブラリがさらにある
   アプリケーションプロセス内のクリティカルデータを指
   定することを許すクリティカルメモリファンクションを
   含み、前記のチェックポイントファンクションが前記指
   定されたクリティカルデータを前記不揮発性メモリの所
   定のエリアにコピーすることを特徴とする請求項１の故
   障バイパス装置。
4. 【請求項４】 前記の故障耐性書込みファンクションが
   前記の回復モードにおいて各新たに生成されたメッセー
   ジを前記のセンダログファイル内の対応するメッセージ
   と比較することによってピースワイズ決定論的想定を検
   証することを特徴とする請求項１の故障バイパス装置。
5. 【請求項５】 前記の故障耐性読出しファンクションが
   受信された各メッセージ内に含まれる送信プロセスのチ
   ェックポイント間隔番号をチェックし、前記の送信プロ
   セスのチェックポイント間隔番号が受信プロセスの現在
   のチェックポイント間隔番号よりも大きい場合、関連す
   る受信アプリケーションプロセスのチェックポイント化
   動作を開始し、これによって、一貫性を持つ大域的なチ
   ェックポイントを確保することを特徴とする請求項１の
   故障バイパス装置。
6. 【請求項６】 前記のプログレッシブ再試行回復アルゴ
   リズムが複数の再試行ステップを含み、前の再試行ステ
   ップが検出された故障をバスパスすることに失敗したと
   き、徐々に回復ロールバックの範囲が増大されて行くこ
   とを特徴とする請求項１の故障バイパス装置。
7. 【請求項７】 前記のプログレッシブ再試行回復アルゴ
   リズムが： 前記の故障プロセスをそのプロセスと関連する最後のチ
   ェックポイントまで回復し、前記の故障プロセスと関連
   する前記のメッセージログ内の最後のチェックポイント
   以降に前記の故障プロセスによって受信されたメッセー
   ジを前記の検出された故障の時点まで再プレイするため
   にレシーバ再プレイステップを遂行するステップ；及び
   前記のレシーバ再プレイステップによって前記のソフト
   ウエア故障がバスパスされない場合に、レシーバ並べ替
   えステップを遂行するステップを含み、ここでは、前記
   の故障プロセスのメッセージログ内の受信されたメッセ
   ージの少なくとも二つの順番が並べ替えられ、その後に
   再プレイが試みられ；プログレッシブ再試行回復アルゴ
   リズムがさらに前記のレシーバ並べ替えステップによっ
   て前記のソフトウエア故障がバイパスされない場合はセ
   ンダ再プレイステップを遂行するステップを含み、ここ
   で、前記の故障プロセスと関連する前記のメッセージロ
   グ内の前記の複数のメッセージの中の最後のチェックポ
   イントより後に前記の故障プロセスによって受信された
   一つ或はそれ以上のメッセージが破棄され、その後、前
   記の破棄されたメッセージを前記の故障プロセスに送信
   した各送信プロセスが前記のセンダ再プレイステップの
   際に前記の故障プロセスに複数のメッセージを再送信
   し；プログレッシブ再試行回復アルゴリズムがさらに； 前記のセンダ再プレイステップによって前記のソフトウ
   エア故障がバイパスされない場合、センダ並べ替えステ
   ップを遂行するステップを含み、ここでは、最後のチェ
   ックポイント以降に故障プロセスによって受信されたメ
   ッセージを前記の故障プロセスに送信した各送信プロセ
   スがそのメッセージログ内の前記の少なくとも二つのメ
   ッセージを並べ替え、その後、前記のメッセージの再プ
   レイを試み；プログレッシブ再試行回復アルゴリズムが
   さらに前記のセンダ並べ替えステップによって前記のソ
   フトウエア故障がバイパスされない場合は、広範囲ロー
   ルバックステップを遂行し、ここで、この広範囲ロール
   バックステップが、前記の監視下のステップの各々を最
   後の一貫性のある大域チェックポイントまでロールバッ
   クさせることを特徴とする請求項１の故障バイパス装
   置。
8. 【請求項８】 前記のプログレッシブ再試行回復アルゴ
   リズムが監視下の各プロセスに対して破棄されてない最
   後の利用可能な実チェックポイント或は論理チェックポ
   イントの所の回復ラインを計算するためにロールバック
   伝播アルゴリズムを採用し、このロールバック伝播アル
   ゴリズムがロールバック伝播規則を守らせ、ここで、前
   記のメッセージログ内の関連するプロセスによって受信
   及び処理された前記の関連するプロセスの最後の実チェ
   ックポイントから前記の計算された回復ラインまでの間
   のメッセージが決定論的メッセージと称され、前記のメ
   ッセージログ内の前記の計算された回復ラインの前に送
   信され前記の回復ラインの後に受信されたメッセージが
   過渡メッセージと称され、前記のプログレッシブ再試行
   回復アルゴリズムが： 前記の故障したプロセスを最後のチェックポイントまで
   回復し、次に、前記の故障プロセスと関連するメッセー
   ジログ内の前記の故障プロセスによって前記の最後のチ
   ェックポイント以降に受信されたメッセージを前記の検
   出された故障のポイントまで再プレイするために、レシ
   ーバ再プレイステップを遂行するステップ；及び前記の
   レシーバ再プレイステップによって前記のソフトウエア
   の故障がバイパスされない場合は、レシーバ並べ替えス
   テップを遂行するステップを含み、前記のレシーバ並べ
   替えステップがさらに： 前記の故障したプロセスと関連する前記のメッセージロ
   グ内の最後のチェックポイントより後に受信されたメッ
   セージに対する処理順番情報を破棄するサブステップ； 回復ラインを計算するサブステップ； 前記の故障したプロセスのメッセージログ内の過渡メッ
   セージの並べ替えを行なうサブステップ；及び現在のプ
   ロセス状態が回復ラインの所にない監視下の各プロセス
   のメッセージログ内の決定論的メッセージを再プレイ
   し、過渡メッセージを再プレイ或は再供給するサブステ
   ップを含み；プログレッシブ再試行回復アルゴリズムが
   さらに前記のレシーバ並べ替えステップによって前記の
   ソフトウエアの故障がバイパスされない場合は、センダ
   再プレイステップを遂行するステップを含み、このセン
   ダ再プレイステップがさらに： 前記の故障プロセスと関連するメッセージログ内の前記
   の故障プロセスによって前記の故障プロセスに対して確
   保された最後のチェックポイントよりも後に受信された
   メッセージを破棄するサブステップ；及び現在のプロセ
   ス状態が前記の回復ラインの所にない監視下の各プロセ
   スのメッセージログ内の決定論的メッセージを再プレイ
   し、過渡メッセージを再供給するサブステップを含み、
   ここで、初期の処理の際に前記の破棄されたメッセージ
   を前記の故障プロセスに送信した各送信プロセスが、こ
   のセンダ再プレイステップにおいて、前記の故障プロセ
   スにメッセージを再送信し；このプログレッシブ再試行
   回復アルゴリズムがさらに前記のセンダ再プレイステッ
   プによって前記のソフトウエアの故障がバスパスされな
   い場合はセンダ並べ替えステップを遂行するステップを
   含み、このセンダ並べ替えステップがさらに： 前記の送信プロセスと関連するメッセージログ内の前記
   の故障プロセスと関連する最後のチェックポイント以降
   に前記の送信プロセスによって前記の故障プロセスに送
   信された最初のメッセージより前の論理チェックポイン
   トより後の各メッセージに対する処理順番情報を破棄す
   るサブステップ； 回復ラインを再計算するサブステップ； 前記の送信プロセスと関連するメッセージログ内の過渡
   メッセージの並べ替えを行なうサブステップ；及び現在
   のプロセス状態が前記の回復ラインの所にない監視下の
   各プロセスのメッセージログ内の決定論的メッセージを
   再プレイし、過渡メッセージを再プレイ或は再供給する
   サブステップを含み；前記のプログレッシブ再試行回復
   アルゴリズムがさらに前記のセンダ並べ替えステップに
   よって前記のソフトウエアの故障がバスパスされない場
   合は、広範囲ロールバックステップを遂行するステップ
   を含み、この広範囲ロールバックステップが前記の監視
   下の各プロセスを最後の一貫性のある大域チェックポイ
   ントまでロールバックさせることを特徴とする請求項１
   の故障バイパス装置。
9. 【請求項９】 アプリケーションプロセスを故障耐性に
   するための方法であって、 あるアプリケーションプロセスを故障耐性にするために
   そのアプリケーションプロセス内の故障耐性ライブラリ
   から複数の適当なファンクションを呼び出すステップを
   含み、この故障耐性ライブラリが： あるアプリケーションプロセスと関連するデータのチェ
   ックポイント化動作を定期的に遂行するためのチェック
   ポイントファンクション； 回復モードの際に不揮発性メモリからチェックポイント
   化されたデータを復元するための回復ファンクション；
   及び前記のアプリケーションプロセスによって生成され
   た各出力メッセージを、前記の各出力メッセージがその
   アプリケーションプロセスによって別のアプリケーショ
   ンプロセスに伝送される前に前記不揮発性メモリに記憶
   されたセンダログファイル内に登録するための故障耐性
   書込みファンクションであって、ここでこの故障耐性書
   込みファンクションが回復モードの間に一つ或はそれ以
   上の前記の出力メッセージを抑圧するためのメカニズム
   を含むような故障耐性書き込みファンクション；及び前
   記のアプリケーションプロセスによって別のアプリケー
   ションプロセスから受信された各入力メッセージをそれ
   らが受信アプリケーションプロセスによって処理される
   前に前記不揮発性メモリに記憶されたレシーバログファ
   イル内に登録するための故障耐性読出しファンクション
   であって、通常の動作においては、通信チャネルから入
   力データを読出して受信された各入力メッセージをレシ
   ーバログファイル内に登録し、回復モードにおいては、
   この入力データが前記のレシーバログファイルから読出
   されるようになっている故障耐性読出しファンクション
   を含み、；前記故障耐性にするための方法がさらに前記
   のアプリケーションプロセスをソフトウエアの故障がな
   いか監視するステップ；及び前記の監視ステップにおい
   て故障が検出された場合、前記の故障を回復するために
   プログレッシブ再試行回復アルゴリズムを実行するステ
   ップを含み、このプログレッシブ再試行回復アルゴリズ
   ムが複数の再試行ステップを含み、これらステップが前
   の再試行ステップが検出された故障をバイパスすること
   に失敗したとき、回復ロールバックの範囲を徐々に増大
   するようになっていることを特徴とする方法。
10. 【請求項１０】 前記の故障耐性ライブラリがさらに所
    定の間隔で前記のエラー検出モニタに関連するプロセス
    がまだアクティブであることを示すハートビートメッセ
    ージを送信するためのファンクションを含み、前記のエ
    ラー検出モニタが前記のアプリケーションプロセスから
    のハートビート信号が前記の所定の間隔が終了する前に
    受信されなかったときに故障を検出することを特徴とす
    る請求項９の方法。
11. 【請求項１１】 前記の故障耐性ライブラリがさらにあ
    るアプリケーションプロセス内のクリティカルデータを
    指定することを許すクリティカルメモリファンクション
    を含み、前記のチェックポイントファンクションが前記
    の指定されたクリティカルデータを前記不揮発性メモリ
    の所定のエリアにコピーすることを特徴とする請求項９
    の方法。
12. 【請求項１２】 前記の故障耐性書込みファンクション
    が前記の回復モードにおいて各新たに生成されたメッセ
    ージを前記のセンダログファイル内の対応するメッセー
    ジと比較することによってピースワイズ決定論的想定を
    検証することを特徴とする請求項９の方法。
13. 【請求項１３】 前記の故障耐性読出しファンクション
    が受信された各メッセージ内に含まれる送信プロセスの
    チェックポイント間隔番号をチェックし、前記の送信プ
    ロセスのチェックポイント間隔番号が受信プロセスの現
    在のチェックポイント間隔番号よりも大きい場合、関連
    する受信アプリケーションプロセスのチェックポイント
    化動作を開始し、これによって、一貫性を持つ大域的な
    チェックポイントを確保することを特徴とする請求項９
    の方法。
14. 【請求項１４】 前記のプログレッシブ再試行回復アル
    ゴリズムが複数の再試行ステップを含み、前の再試行ス
    テップが検出された故障をバスパスすることに失敗した
    とき、徐々に回復ロールバックの範囲が増大されて行く
    ことを特徴とする請求項９の方法。
15. 【請求項１５】 前記のプログレッシブ再試行回復アル
    ゴリズムが： 前記の故障プロセスをそのプロセスと関連する最後のチ
    ェックポイントまで回復し、前記の故障プロセスと関連
    する前記のメッセージログ内の最後のチェックポイント
    以降に前記の故障プロセスによって受信されたメッセー
    ジを前記の検出された故障の時点まで再プレイするため
    にレシーバ再プレイステップを遂行するステップ；及び
    前記のレシーバ再プレイステップによって前記のソフト
    ウエア故障がバスパスされない場合に、レシーバ並べ替
    えステップを遂行するステップを含み、ここでは、前記
    の故障プロセスのメッセージログ内の受信されたメッセ
    ージの少なくとも二つの順番が並べ替えられ、その後に
    再プレイが試みられ；プログレッシブ再試行回復アルゴ
    リズムがさらに前記のレシーバ並べ替えステップによっ
    て前記のソフトウエア故障がバイパスされない場合はセ
    ンダ再プレイステップを遂行するステップを含み、ここ
    で、前記の故障プロセスと関連する前記のメッセージロ
    グ内の前記の複数のメッセージの中の最後のチェックポ
    イントより後に前記の故障プロセスによって受信された
    一つ或はそれ以上のメッセージが破棄され、その後、前
    記の破棄されたメッセージを前記の故障プロセスに送信
    した各送信プロセスが前記のセンダ再プレイステップの
    際に前記の故障プロセスに複数のメッセージを再送信
    し；プログレッシブ再試行回復アルゴリズムがさらに； 前記のセンダ再プレイステップによって前記のソフトウ
    エア故障がバイパスされない場合、センダ並べ替えステ
    ップを遂行するステップを含み、ここでは、最後のチェ
    ックポイント以降に故障プロセスによって受信されたメ
    ッセージを前記の故障プロセスに送信した各送信プロセ
    スがそのメッセージログ内の前記の少なくとも二つのメ
    ッセージを並べ替え、その後、前記のメッセージの再プ
    レイを試み；プログレッシブ再試行回復アルゴリズムが
    さらに前記のセンダ並べ替えステップによって前記のソ
    フトウエア故障がバイパスされない場合は、広範囲ロー
    ルバックステップを遂行し、ここで、この広範囲ロール
    バックステップが、前記の監視下のステップの各々を最
    後の一貫性のある大域チェックポイントまでロールバッ
    クさせることを特徴とする請求項９の方法。
16. 【請求項１６】 前記のプログレッシブ再試行回復アル
    ゴリズムが監視下の各プロセスに対して破棄されてない
    最後の利用可能な実チェックポイント或は論理チェック
    ポイントの所の回復ラインを計算するためにロールバッ
    ク伝播アルゴリズムを採用し、このロールバック伝播ア
    ルゴリズムがロールバック伝播規則を守らせ、ここで、
    前記のメッセージログ内の関連するプロセスによって受
    信及び処理された前記の関連するプロセスの最後の実チ
    ェックポイントから前記の計算された回復ラインまでの
    間のメッセージが決定論的メッセージと称され、前記の
    メッセージログ内の前記の計算された回復ラインの前に
    送信され前記の回復ラインの後に受信されたメッセージ
    が過渡メッセージと称され、前記のプログレッシブ再試
    行回復アルゴリズムが： 前記の故障したプロセスを最後のチェックポイントまで
    回復し、次に、前記の故障プロセスと関連するメッセー
    ジログ内の前記の故障プロセスによって前記の最後のチ
    ェックポイント以降に受信されたメッセージを前記の検
    出された故障のポイントまで再プレイするために、レシ
    ーバ再プレイステップを遂行するステップ；及び前記の
    レシーバ再プレイステップによって前記のソフトウエア
    の故障がバイパスされない場合は、レシーバ並べ替えス
    テップを遂行するステップを含み、前記のレシーバ並べ
    替えステップがさらに： 前記の故障したプロセスと関連する前記のメッセージロ
    グ内の最後のチェックポイントより後に受信されたメッ
    セージに対する処理順番情報を破棄するサブステップ； 回復ラインを計算するサブステップ； 前記の故障したプロセスのメッセージログ内の過渡メッ
    セージの並べ替えを行なうサブステップ；及び現在のプ
    ロセス状態が回復ラインの所にない監視下の各プロセス
    のメッセージログ内の決定論的メッセージを再プレイ
    し、過渡メッセージを再プレイ或は再供給するサブステ
    ップを含み；プログレッシブ再試行回復アルゴリズムが
    さらに前記のレシーバ並べ替えステップによって前記の
    ソフトウエアの故障がバイパスされない場合は、センダ
    再プレイステップを遂行するステップを含み、このセン
    ダ再プレイステップがさらに： 前記の故障プロセスと関連するメッセージログ内の前記
    の故障プロセスによって前記の故障プロセスに対して確
    保された最後のチェックポイントよりも後に受信された
    メッセージを破棄するサブステップ；及び現在のプロセ
    ス状態が前記の回復ラインの所にない監視下の各プロセ
    スのメッセージログ内の決定論的メッセージを再プレイ
    し、過渡メッセージを再供給するサブステップを含み、
    ここで、初期の処理の際に前記の破棄されたメッセージ
    を前記の故障プロセスに送信した各送信プロセスが、こ
    のセンダ再プレイステップにおいて、前記の故障プロセ
    スにメッセージを再送信し；このプログレッシブ再試行
    回復アルゴリズムがさらに前記のセンダ再プレイステッ
    プによって前記のソフトウエアの故障がバスパスされな
    い場合はセンダ並べ替えステップを遂行するステップを
    含み、このセンダ並べ替えステップがさらに： 前記の送信プロセスと関連するメッセージログ内の前記
    の故障プロセスと関連する最後のチェックポイント以降
    に前記の送信プロセスによって前記の故障プロセスに送
    信された最初のメッセージより前の論理チェックポイン
    トより後の各メッセージに対する処理順番情報を破棄す
    るサブステップ； 回復ラインを再計算するサブステップ； 前記の送信プロセスと関連するメッセージログ内の過渡
    メッセージの並べ替えを行なうサブステップ；及び現在
    のプロセス状態が前記の回復ラインの所にない監視下の
    各プロセスのメッセージログ内の決定論的メッセージを
    再プレイし、過渡メッセージを再プレイ或は再供給する
    サブステップを含み；前記のプログレッシブ再試行回復
    アルゴリズムがさらに前記のセンダ並べ替えステップに
    よって前記のソフトウエアの故障がバスパスされない場
    合は、広範囲ロールバックステップを遂行するステップ
    を含み、この広範囲ロールバックステップが前記の監視
    下の各プロセスを最後の一貫性のある大域チェックポイ
    ントまでロールバックさせることを特徴とする請求項９
    の方法。