JP3573463B2 - 計算の状態を再構成する方法ならびにシステム - Google Patents

Description

発明の背景
1. 発明の分野
本発明はコンピュータ処理システムに関し、なかでも、並列処理コンピュータ環境において割り込まれた計算の状態を再構成する方法とシステムに関する。
2. 関連技術の説明
単一プロセッサ式コンピュータの計算速度は過去30年にわたって飛躍的に速くなった。しかし、多くの分野で、最速の単一プロセッサ式コンピュータをも越える計算容量が要求されている。一例がトランザクション処理で挙げられる。この分野では、複数のユーザが同時にコンピュータ資源にアクセスしており、システムが市場で受け入れられるには応答時間が短くなければならない。データベース検索で他の例が見いだせる。この分野では、数百ギガバイトの情報を処理せねばならず、直列式コンピュータでデータを処理すると数日または数週間かかる。したがって、こうした問題を処理するために多様な「並列処理」システムが開発されてきた。この説明のために、並列処理システムには、複数の中央演算処理装置（CPU）を用いたコンピュータシステム構成が含まれている。こうしたコンピュータシステムには、構内型（たとえば、SMPコンピュータなどのマルチプロセッサシステム）、構内分散型（たとえばクラスタまたはMPP（高度並列計算機）として接続された複数のプロセッサ）、または遠隔型、または遠隔分散型（たとえば、LANまたはWANネットワークを介して接続された複数のプロセッサ）が挙げられる。
並列処理システムで動作する複数の複雑なデータ処理アプリケーションは通常、様々な外部のデータ収集（ファイル、データベースなど）に変更を加える。こうしたアプリケーションは、１つまたは複数のプログラムを同時または連続して動作させることで変更を加える。障害が発生すると、外部のデータ収集に部分的な変更を加える。このため現行または他のアプリケーションではデータが使用できなくなる。並列処理システムでは、データ収集がしばしば様々なノードや記憶装置（たとえば、磁気ディスク）にわたって拡がっているので問題が複雑になり、データの状態を「元に戻す（ロールバック（roll back））」のに必要な仕事は記憶装置の数に比例して増加する。同様に、終了しなければならないプログラムの数も増大する。
こうした障害から回復するためには、現行の（すなわち、障害のある）アプリケーションを閉じて、
（１）開始時からそのアプリケーションにより加えられたすべての変更を元に戻す（「完全な復帰」）または
（２）システムの状態を中間の「チェックポイント」まで回復して、その点から実行を再起動する（「部分復帰」）
チェックポイントからの部分原状復帰（「チェックポインティング」としても知られている）は完全原状復帰より有益である。というのは、障害が発生しても喪失する仕事が少ないし、部分復帰では保持する情報は少なくてすむからである。しかし、チェックポインティングは複雑な技術的問題である。というのは、（１）実行中のプログラムの状態を捕捉することと、（２）修正中のすべてのデータファイルの状態を一貫して元に戻すことと、（３）プログラム間で移送されるデータ（たとえば、ネットワークを介して送られるデータ）を捕捉することが困難なためである。アプリケーションプログラムはチェックポインティングを実行するために特に書き込まなければならないことが多いことにより問題はいっそう複雑になる。一般に、チェックポインティング動作がチェックポインティングソフトウェアプログラムに明示呼出しを追加するときには必ずプログラムのソースコードを実質的に変えることになるように作成されているプログラムを修正することはできない。さらに、大半のオペレーティングシステムはプログラム間移送データを捕捉する手段を備えてはいない。
したがって、特にチェックポインティングを備えてないアプリケーションにチェックポインティングを備える方法が必要である。本発明は、並列処理システムにおいて実行中のアプリケーションに特に有益で、分散処理システムにおいて実行中のアプリケーションでも有益なこうした方法を提供するものである。
発明の要約
本発明は、システムで使用されるプログラムを修正する必要もなく、基本オペレーティングシステムを変更する必要もない並列および分散アプリケーションを実行しチェックポイントまで戻す方法とシステムである。本発明には、２つの個別の実施例が含まれる。第１の好ましい実施例は以下の概略工程を含む。
（１）並列処理システム上でアプリケーションを起動する。
（２）複数のコマンドおよび応答の記録を含むアプリケーションの処理を制御する。
（３）コミット規約を制御する。
（４）アプリケーションの障害を検出する。
（５）記録されたコマンドおよび応答を「再生した」後で最近にコミットされたトランザクションからアプリケーションの実行を継続する。
第２の好ましい実施例は以下の概略工程を含む。
（１）並列処理システム上でアプリケーションを起動する。
（２）アプリケーションを制御するドライバプログラムのメモリイメージの再帰記録を含むアプリケーションの処理を制御する。
（３）コミット規約を制御する。
（４）アプリケーションの障害を検出する。
（５）ドライバアプリケーションの記録メモリイメージを「再生した」後で最近コミットされたトランザクションからアプリケーションの実行を続ける。
進歩的アーキテクチャの主要な特色は以下の通りである。
（１）中央制御：複数のアプリケーションを制御の中心点から実行する。好ましい実施例では、単一の制御スレッドを備えた単一「ドライバ」プログラムが、アプリケーションを形成するすべてのプログラムとデータ収集をインスタンス生成し監視する。
（２）ホストおよびエージェントを介した制御：複数のノード上で処理を分散させるために、「エージェント」と呼ばれるプログラムがリモートノードで変更を実行するために使用される。好ましい実施例では、個々のエージェントが各ノードでインスタンス生成される。システムの全体制御は「上位」プログラムにより維持される。このプログラムは、ドライバプログラムとエージェントを介した通信を管理して、グローバルシステム状態を維持する。
（３）単一コマンドチャンネル：「コマンドチャンネル」はドライバプログラムとホストプログラム間で維持される。好ましい実施例では、ドライバプログラムが、一連のコマンドと応答を介してのみシステムに変更を加える。
（４）コマンドチャンネルの通信量またはメモリイメージの記録：第１実施例では、コマンドチャンネルを介して送られるコマンドと応答のすべてはホストプログラムにより記録され、不揮発性記憶装置に保存される。第２実施例では、アプリケーションを制御するドライバプログラムのメモリイメージは、ホストプログラムにより再帰的に記録され、不揮発性記憶装置に保存される。
（５）トランザクション準拠制御：好ましい実施例では、コマンドチャンネルを介して実行された動作のすべては、グローバルアトミシティを確保するためにコミット規約（好ましくは、２相コミット規約）を使用する。
（６）反復による回復：上記のメカニズムを用いて、本発明は、障害のあるアプリケーションを、単純に再実行することで「回復」する機能を備えている。要約すると、すべてのデータの状態をコミット規約を介して回復して、コマンドチャンネル上の記録された通信量が、ドライバプログラムを「だまして」、ドライバプログラムが新しいアプリケーションを実行していると信じさせるか、またはドライバプログラムの最後の良好な状態のメモリイメージを回復する。単一スレッド式コンピュータプログラムの決定論的な特質のために、ドライバプログラムは、最後の良好な状態の時点では、プログラムが実行された最初の時と同じ状態で、終了されなければならない。
本発明は主に、従来のデータ処理アプリケーション（たとえば、アカウントシステム、バッチトランザクションシステムなど）に用いられるが、本発明は、ファイルまたはデータベースに変更を加える大半のコンピュータアプリケーションに適用可能である。
本発明の好ましい実施例の詳細は、添付図面ならびに以下の説明に詳述される。本発明の詳細が分かると、付随する多くの新規技術や変更が当業者には明らかになるであろう。
【図面の簡単な説明】
図１は、本発明によるチェックポインティングシステムのソフトウェア構成要素と制御の流れを示す構成図である。
図2Aは、本発明によるチェックポイントされたプログラムの通常の実行を示す構成図である。
図2Bは、図2Aのチェックポイントされたプログラムの実行中の障害を示す構成図である。
図2Cは、図2Bの障害からの回復を示す構成図である。
図３は、本発明による障害からの回復中のチェックポインティングシステムのソフトウェア構成要素と制御の流れを示す構成図である。
図４は、本発明の反復実施例の基本的な機能動作を要約して示す流れ図である。
図５は、本発明の回復実施例の基本的な機能動作を要約して示す流れ図である。
上記様々な図面の同じ参照番号と指示は同じ要素を示している。
発明の詳細な説明
本発明を通して、図示の好ましい実施例と例は、本発明を制限するものではなく例示するものとして考慮すべきである。
概観
図１は、本発明によるチェックポインティングシステムのソフトウェア構成要素と制御の流れを示す構成図である。ホストシステム10は、ホストプログラム12と、ドライバプログラム14と、コマンドと応答を記録するデータ記憶システム16とを備える。ホストプログラム12とドライバプログラム14はコマンドチャンネル18（たとえば、物理的バス上の論理チャンネル）により相互接続される。好ましい実施例では、ホストプログラム12は実際は、ドライバプログラム14のアドレス空間内のオブジェクトである。ホストプログラムを実行する個別プロセスを代りに実行することもできる。ただし、「ホストプログラム」と「ドライバプログラム」への分割は、本発明のアーキテクチャを記載する便宜的な方法である。
ホストシステム10は、エージェント通信チャンネル22（たとえば、従来の物理的データリンク22）により少なくとも１つのリモートシステム20に接続されている。各リモートシステム20内には、リモートデータ記憶装置26に接続されたエージェント24がある。
図１に示す構成要素すべてが通常の実行中には動作中である。ドライバプログラム14は複数のコマンドをホストプログラム12に発行して、様々なリモートシステム20上のアプリケーションの動作を実行する。ホストプログラム12は、複数のコマンドを１つまたは複数のエージェント24に発行して要求された動作を実行することでこうしたコマンドに応答する。動作が完了するとエージェント24はホストプログラム12に応答し、次に、ポストプログラム12はドライバプログラム14に返答する。ドライバプログラム14とホストプログラム12の間のコマンドと応答のすべてはデータ記憶システム16に記録される。
図2Aは、本発明によるチェックポイントされたシステムの通常の実行を示す。図示の例では、アプリケーションは３つの段階で実行される、初期状態０で始まり、段階０を介してチェックポイント１状態に進み、段階１を介してチェックポイント２状態に進み、段階２を介して最終状態に進む。
図2Bは、図2Aのチェックポイントされたプログラムの実行中に障害を示す構成図である。例えばノードの１つが「クラッシュ」して、再起動しなければならない場合には障害が発生する場合がある。図示の例では、チェックポイント１状態に到達した後で、しばしば、障害が発生する。段階１の真ん中で実行が停止し、並列処理システムの外部状態が不本意な障害状態になる。
図2Cは、本発明を用いて図2Bに示す障害からの回復を示す構成図である。アプリケーションが再実行されることで回復されると、障害段階１で実行された動作が元に戻り、処理システムの外部状態をチェックポイント１状態の状態に戻す。すべての完了段階（この例では、段階０）は「反復」または「回復」される。反復では、ドライバプログラム14はその初期状態から再起動され、通常に機能する。しかし、ドライバプログラム14はチェックポイント１状態にある同じ状態に到達するまでは外部状態変化は発生しない。回復においては、ドライバプログラム14の保存イメージが回復され、その点から通常に機能する。その後、障害段階（この例では段階１）ならびにその後のすべての段階が通常に実行されて、チェックポイント２の状態を介して最終状態に至るまでアプリケーションが実行される。
図３は、反復中の本発明によるチェックポインティングシステムのアーキテクチャを示す構成図である。反復モード中には、ドライバプログラム14は初期状態から開始する。ドライバプログラム14からの各コマンドはホストプログラム12に再発行される。ホストプログラム12は、そのコマンドを、データ記憶システム16に以前記憶された記録コマンドおよび応答と突き合わせる。ドライバプログラム14からのコマンド列が記録コマンドと一致している限り、対応する記録応答がホストプログラム12によりドライバプログラム14に送られる。実際には、ドライバプログラム14を「だまして」、反復中の複数段階が通常に実行中であると思わせる。しかし、データは実際には変形されたり、移動されたりすることはない。したがって、反復段階は、ドライバプログラム14が最後の良好なチェックポイント状態に到達するまで、極めて迅速に遂行される。このチェックポイントで、ホストプログラム12は、反復モードから切り替えられて、通常の動作モードに戻されて、ドライバプログラム14からのコマンドをリモートシステム20のエージェント24に通常の方式で供給する。
本発明は、ハードウェアまたはソフトウェアまたは両者の組合せにより実施可能である。しかし、好ましくは、本発明は、プロセッサ、データ記憶システム（揮発性メモリおよび不揮発性メモリおよび／または記憶要素を含む）、少なくとも１台の入力装置、および少なくとも１台の出力装置とをそれぞれ含む複数台のプログラム式コンピュータで実行されるコンピュータプログラムで実施される。プログラムコードは、入力データに適用されて、本明細書に記載の機能を実行し、出力情報を生成する。出力情報は、周知の方式で、１つまたは複数の出力装置に送られる。
各プログラムは、コンピュータシステムとやり取りするために高レベル手続き形プログラミング言語またはオブジェクト指向プログラミング言語で実施されるのが好ましい。しかし、望ましければ、アセンブリー言語または機械言語で実施することも可能である。いかなる場合でも、言語はコンパイル済みまたは翻訳済み言語である。
こうしたコンピュータプログラムはそれぞれ、汎用または特定目的プログラム式コンピュータにより読み取り可能なそれぞれ記憶媒体または装置（たとえば、ROMまたは磁気ディスク）に記憶されるのが好ましく、記憶媒体または装置がコンピュータにより読み取られるとコンピュータが構成され動作して、本明細書に記載された処理手順を実行する。本発明のシステムは、コンピュータプログラムで構成されるコンピュータ読取可能な記憶媒体として実施することも可能である。この場合、このように構成された記憶媒体によりコンピュータは特定かつ事前定義方式で動作して、本明細書に記載された機能を実行する。
ドライバプログラム
本発明は、１つまたは複数の従来の非チェックポインティングプログラムの実行をセットアップし制御する監視機能を備えたドライバプログラム14を使用する。望まれれば追加機能も加えられる。好ましい実施例では、ドライバプログラム14は少なくとも以下に定義した機能を実行する。
（ａ）起動ジョブ：ドライバプログラム14が起動するときに、プログラム14は、ホストシステム10がホストプログラム12をインスタント生成するよう要請する。ホストシステム10は、ホストプログラム12およびデータ記憶システム16とやり取りをするために、コマンドチャンネル18の識別子またはポインタをドライバプログラム14に備えることで応答する。ドライバプログラム14は、コマンドチャンネル18を介してホストプログラム12に接続され、「開始ジョブ」コマンドをホストプログラム12に発行する。このコマンドは、データ記憶システム16にホストシステム10により確立される「回復ファイル」の名前を含む。（実施例によっては、「接続」は個別のプロセスの開始を要求するものもあり、内部データ構造の初期化を要求するものもある。どちらの場合でも、第１動作は常に上記のジョブを開始することである。
（ｂ）コマンド：コマンドチャンネル18は少なくとも以下のコマンドをドライバプログラム14から受け取る。
（１）遠隔手続呼出し：この呼出しによりコマンドがリモートエージェント24により実行される。遠隔手続呼出し（RPC）コマンドは、コマンドが実行されるノードを指定する。そのノードで現在実行中のエージェントがない場合、ホストプログラム12はそのノードでリモートエージェント24を起動する。
（２）開始プロセス：このコマンドによりプロセスがエージェント24により起動される。再び、このコマンドはプロセスが実行されるノードを指定する。そのノードに現在実行中のエージェントがない場合、ホストプログラム12はそのノードでリモートエージェント24を起動する。
（３）待機：このコマンドは、すべてのプロセスが実行を終えるまでドライバプログラム14の機能実行を中止させる。
（４）準備：コミット：ロールバック：これら３つのコマンドは、従来の２相コミットトランザクション処理プロトコルに関して通常の従来技術の意味である。
（ｃ）応答の受信：各コマンドの実行の結果、正確に１つのメッセージが返される。コマンドおよび応答は恣意的に混合できる（たとえば、複数のコマンドを発行して、その後対応する応答が返ってくる。）ドライバプログラム14はホストプログラム12から少なくとも以下に示す応答を受け取る。
（１）遠隔手順呼出し応答：このメッセージの内容は、RPCコマンドにより引き起こされた処理手順にのみ対応する。
（２）プロセスID:プロセスがシステム（ホスト10またはリモート20）で実行されると、システムはそのプロセス用の識別子で応答する。
（３）待機状況：様々なプロセスが首尾よく終了したかどうかについての指示。
（４）準備／コミット／ロールバック状況：成功または失敗状況指標。
（ｄ）中止：このコマンドは実行が停止されることを意味する。ホストプログラム12はロールバックの実行を企てる（たとえば、計算に関わるノードの１つがクラッシュするとこの企ては失敗することがある）。ロールバックが成功してもしなくても、コマンドチャンネル18は通常壊される。中止コマンドは、たとえば、ドライバプログラム14が実行障害を検出するとドライバプログラム14により手動で発行される。中止コマンドは、ドライバプログラム14に障害が発生すると暗示的に発行される場合もある。
（ｅ）ジョブ終了：このコマンドは実行する仕事が残ってないことを示す。コマンドチャンネル18は通常壊され、アプリケーションにより成された変更はすべて取り消せなくなる。
（ｆ）追加コマンド：追加コマンドは望ましければ追加可能であるが、本開示のためには重要ではない。
重要なことは、ドライバプログラム14がアプリケーションの実行を一連の『段階』であって、アプリケーショ ンの全てのプロセスが前記実行段階間において停止され ることが要求される実行段階に分割して、すべてのプロセスが段階の間で静止するよう要求される（たとえば、未実行のデータ転送を残してないアイドル状態からの脱出またはその状態への到達）。段階は以下に示す工程から構成される。
（１）ドライバプログラム14は一連のRPC（たとえば、データファイルなどのセットアップ）を発行する。これら一連のRPCは１つまたは複数のアプリケーションプログラムにより必要とされる。
（２）オプションとして、ドライバプログラム14は一連の起動プロセスコマンドを発行する。
（３）任意のプロセスが起動した場合、望ましい数のプロセスが起動した後で、ドライバプログラム14は待機コマンドを発行して、待機が完了するまで動作を中止して、プロセスが完了する時間を確保する。一般に、他のプロセスと相互交信する必要のあるすべてのプロセスは同時に開始されるべきである。
（４）工程（１）−（３）のシーケンスは望まれれば数回繰り返すことができる。
（５）ドライバプログラム14は準備およびコミットコマンドを発行して、現トランザクションがコミットされ、現トランザクション中に成された変更を永続的なものにする。
（６）更なる実行段階が続く。
主要な工程は、再帰的に待機コマンドを発行している。というのはこのコマンドが終了した後で、このシステムには活動状態のアプリケーションプログラムがないことと、通信チャンネルに移送データがないことが保証されるからである。この特徴により本発明は、プログラムの実行状態と通信チャンネルの移送データを捕捉する際の固有の困難に対処できる。
こうした設計の結果、プログラムの実行中にはチェックポイントは作成されない。アプリケーションプログラムの１つが数時間実行されている場合、チェックポイントを作成できない数時間の期間が必要となる。任意の段階の実行時間が過剰にならないように保証するのはドライバプログラム14の責任である。このドライバプログラム14はこのシステムのユーザによりしばしば書き込まれるものである。
段階の持続時間を削減するのに使用できる従来の２つの技術がある。第１の技術は、１段階内の処理の連続工程の間で「パイプライン化」の使用を削減することである。特に、通常の実施では、通信チャンネルを介して構成プログラムを連結することでこれらの構成プログラムからアプリケーションを構成する。これは「パイプライン」と呼ばれる技術である。両構成プログラムは同じ段階で実行されなければならない。この結果、段階が長くなりすぎる場合には、ドライバのライターが一次ファイルを通信チャンネルと代替することができ、個々の実行段階で各構成プログラムを実行できる。第２技術は、データをいっそう細かく分割することである。たとえば、10ギガバイトの単一ファイルを処理しないで、それぞれ１ギガバイトの10のサブファイルに分割し、単一実行段階で各サブファイルを処理することもできる。大半のアプリケーションの実行時間はそれらの入力ファイルの長さにほぼ比例しているという事実のために、この方法は、たとえば、段階の持続時間を10分の１に減らすことができ、チェックポイントが作成できる周波数をいっそう改良する。（従来技術では、この追加部分分割が特別に実施され、通常はプログラムの修正と、おそらく追加ソフトウェアの書込が必要となる。本発明の譲渡人に譲渡された「構成要素準拠並列アプリケーションのチェックポイントを増加させる分割増加システムならびに方法（Overpartitioning System and Method for Increasing Checkpoints in Component−based Parallel Applications）」の名称の共同出願を参照のこと。一般的な方法では、元のプログラムを修正することなく部分分割が実行できると説明されている。）
状態データベース（SDB）
ホストシステム10はそれ自体のために状態データベース（「ホストSDB」）を作成する。各エージェント24はそれ自体の状態データベース（「エージェントSDB」）も作成する。ホストSDBは、本発明の反復実施例を使用するときにコマンドチャンネル通信量を記録し、どの段階が実行中かを記録し、コミット処理のために必要な情報を記録するのに使用される。エージェントSDBは、回復処理およびコミット処理のための情報を記録するのに使用される。好ましい実施例では、SDBは、SDBにアクセスするプログラムの寿命の間だけメモリにある。しかし、SDBへの変更すべてが、データ記憶システム16など不揮発性記憶機構の順序づけられたジャーナルファイル（「ログ」）に連続して記録される。任意に時点で、SDBは対応するログからメモリに再構成可能である。好ましい実施例では、ログはSDBに関連する唯一の一貫した記録機構である。SDBの再構成は空のデータベースから始まりログからデータベースへの一連の変更を読み取り、メモリ内データベース内容の変更を反映させることにより実行される。
好ましい実施例では、SDBへの入力はすべてテキスト列の対、キーと値の形である。入力（「Put」）を書き込むと、呼出しプログラムが、データベースに記憶されているキー／値入力を供給する。Put動作の前に同一のキーをもつ入力がある場合、それは置換される。入力（「Get」）を読み取ると、呼出しプログラムはキーを供給し、そのキーをもつ入力がある場合、その値列が戻される。さらに、好ましい実施例では、SDBインターフェースはリストの作成が可能である。リストは、キーによるのではなく連続してアクセス可能な入力の連続である。リスト入力は通常の列値である。
ユーザは、ログファイルの名前を付与することでSDBを「開く」。ログファイルがある場合、それが読み取られ、対応するSDBがログ内容から再構成される。ログファイルが存在しない場合、ログファイルが作成され、SDBは空のデータを構造としてメモリに作成される。次いで、SDBは、それが閉じられるまでPutおよびGet動作を利用可能である。データベースの閉鎖は、閉鎖動作を用いれば明示的に実行され、アクセスプログラムが終了すると暗示的に実行される。
好ましい実施例では、SDB上のすべての動作が「トランザクション」に分類される。GetまたはPutは、進行中のトランザクションがない場合新しいトランザクションを起動する。トランザクションは、以後のPutsまたはGetsを通して以下のようになるまで継続する。
（１）SDBコミット動作が実行されるまで。
（２）SDBロールバック動作が実行されるまで。この動作はSDB上の全トランザクションの効果を無効にする。
（３）SDBが閉鎖されるまで。この場合には判明している最後の良好な状態まで任意の活動中のトランザクションを暗示的に戻す。
好ましい実施例では、SDB上のトランザクションは全体的なコミットアーキテクチャの一部ではなく、いっそう細かく細分できる。
ホストプログラム
ドライバプログラム14がジョブを始めると、ホストシステム10はコマンドチャンネル18を作成して、ドライバプログラム14とホストプログラム12の間でデータのやり取りを可能にする。ホストプログラム12は、コマンドチャンネル18のホストシステム10側でデータを処理する。各アプリケーション当たりのホストプログラム12が１つある。ホストプログラム12は以下のように動作する。
（ａ）ジョブの開始：好ましい実施例では、以下の機能がアプリケーションの始めにホストプログラム12により実行される。
（１）ジョブID:ホストプログラム12は、ホストプログラム12が実行中のシステムのインターネットアドレスを用いて「ジョブID」と呼ばれる固有識別子と、タイムスタンプと、ホストプログラム12のプロセスIDを作成する。
（２）ホストSDB:ホストプログラム12は、ジョブIDを識別子として使用することでホストSDBを作成する。好ましい実施例では、ジョブIDはホストSDBに記憶される。
（３）回復ファイル：ホストプログラム12はその実行の開始時に「回復ファイル」と呼ばれるファイルをデータ記憶システム16にも書き込む。このファイルはジョブIDも含んでいる。このジョブIDはホストSDBを開くために使用される。
（ｂ）リモートノードおよびエージェント：ホストプログラム12は複数のプロセスを開始させ、１つまたは複数のエージェント24を介してファイル／データベース上で動作する。各エージェント24はホストプログラムとの双方向に接続（エージェントコマンドチャンネル22）を確立して、コマンドをエージェント24に送信し、エージェント24から応答を受けとる。エージェント24は、アプリケーションプログラムが実行されるかまたはファイルまたは他のデータ収集が配置されている各リモートシステム20で起動する。好ましい実施例では、複数のエージェント24が、アプリケーションの開始時に一度にすべてが起動せずに、必要に応じて起動される。
（ｃ）段階の実行：ホストプログラム12は複数のエージェント24を使用して、ドライバプログラム14により指示された通りに、非チェックポインティングアプリケーションの実行を複数段階であって、アプリケーションの全 てのプロセスが前記実行段階間において停止されること が要求される実行段階に分割する。ホストプログラム12は、この分割を実施するトランザクションメカニズムを制御し、以下に記載のように簿記および調整機能を実行する。
好ましい実施例では、各段階はゼロから番号が振られる。１つの段階は常に４つの状態「実行中、エラー、準備完了またはコミット中」の１つである。新しい段階が始まると、それは実行状態である。遠隔動作がその段階中に実行されているのでこの段階は実行状態で継続する。
現在の段階番号とその状態はホストSDBに記録されている。この情報はあらゆる状態遷移で記録される。段階中の任意の時点で、ドライバプログラム14はロールバック機能を呼び出すことができる。この機能により現段階中にこれまで実行されたすべての動作の実行が無効になり、すべての変更された状態が段階の開始時の状態まで戻され、その段階を実行状態にする。
各段階中に、実行状態の間、ドライバプログラム14が開始プロセスおよび遠隔処理手順呼出し（RPC）コマンドをホストプログラム12に発行する。ホストプログラム12はこうしたコマンドを適切なエージェント24に送り、各エージェント24からの応答をまとめて、その応答をドライバプログラム14に送る。本発明の反復実施例では、こうしたコマンドと対応する応答のすべてがホストSDBに記録されている。この情報は、以下に記載したように「反復モード」で使用される。
ドライバプログラム14により起動されたプロセスすべてが終了すると、ドライバプログラム14は準備機能を呼び出して、アプリケーションの現段階を準備完了状態にする。この後で、ドライバプログラム14はコミット機能を呼び出す。この機能は段階中に実行された動作すべてを完全、正確かつ改変不能に実行して、この段階を終える。ロールバック機能は準備完了状態でも呼び出せ、準備機能の前に呼びだされたのと同じ効果をもたらすことができる。
本発明の好ましい実施例は従来の２相コミットプロトコルを使用する。好ましい反復実施例では、２相コミットプロトコルは以下のようなものである。
（１）準備：準備コマンドは以下の動作によりホストプログラム12により実行される。
１）現段階番号を含むキーにより、ホストSDBの現段階から記録されたコマンドチャンネルデータを記憶する。こうした情報がすでにある場合には（たとえば、コミット処理中に障害が発生した同じ段階の前の実行によるもの）、重ね書きされる。
２）現段階中に複数のコマンドを実行した各エージェント24にホストプログラム12から準備コマンドを送る。各エージェントは、従来の２相コミット規約に応じて、以後の任意の時点で、エージェント24の制御下ですべての資源の状態を回復するロールバックコマンドを実行するかまたは、エージェント24の制御下ですべての資源の変更を永続的なものにするコミットコマンドを実行するように、準備完了状態を入力する。この準備完了状態は持続可能でなければならない。すなわち、システム障害の後で準備完了状態を再構成し、ロールバックまたはコミット動作を実行することが可能でなければならない。準備完了状態に達すると、各エージェント24は、準備コマンドに応答することでこのことを知らせることになる。
３）すべてのエージェント24は準備コマンドが首尾よく完了したことを示すまで待機する。
４）ホストプログラム12の状態を準備完了状態に設定し、ホストSDBの変更を通知する。
（２）コミット：コミットコマンドは以下のようにして実行される。
１）ホストプログラム12の状態をコミット状態に設定し、ホストSDBの変更を通知する。
２）段階中に複数のコマンドを実行した各エージェント24にコミットコマンドを送る。次に、各エージェント24は、その制御下にあるすべての資源に加えられた変更が永続的になり、ロールバック時に必要とされたかもしれない情報を除去する。こうした処理が完了すると、各エージェント24は、コミットコマンドに応答することによりこのことを合図する。
３）すべてのエージェント24はコミットコマンドが首尾よく完了したことを示すまで待機する。
４）ホストプログラム12の状態を実行状態に設定し、段階番号を増分し、ホストSDBの変更を通知する。
実行状態または準備完了状態中に、エラー状態がオペレーティングシステムまたはアプリケーションにより検出される場合には、その段階はエラー状態となる。好ましい実施例では、この状態の間には、さらに遠隔動作を実行することはできないし、段階の状態を変更することもできないし、新しい段階を開始することもできない。好ましい実施例では、この時点での規約による動作は以下のものだけである。
（１）デバッギング：ドライバプログラム14は、周知の方式で、複数の通報コマンドを使用して、アプリケーションをデバッグしたり、さらに／または診断情報を収集することができる。
（２）イグジット（退出）：ドライバプログラム14が出ていくと、ホストプログラム12は、ドライバプログラム14に代わってロールバックコマンドを発行できる。
（３）ロールバック：ドライバプログラム14はロールバックコマンドを発行できる。このコマンドは、現段階の開始時の状態にシステムを戻し、上記のようにファイル／データベースに加えられた変更を元に戻す。
要約すると、ホストプログラム12の規約状態変化は以下の通りである。
（１）初期状態：実行中
（２）コミット状態以外の任意の状態においては、エラー条件によりエラー状態に遷移する。ロールバックコマンドによりまたはドライバプログラム14が出た場合にはこの状態から脱出できる。このロールバックコマンドによりシステムは実行状態になる。
（３）実行状態では、準備動作により準備完了状態に遷移する。実行状態または準備完了状態中に、ロールバック動作により段階が元に戻され、その場合には段階番号は同じであり、システムは実行状態に戻る。
（４）準備完了状態では、コミット動作によりコミット状態に遷移される。この状態はコミット動作の持続中続き、段階番号を埋め、現段階を終了し、実行状態の新しい段階を始める。一旦ホストSDBがコミット状態への遷移を記録すると、エラーの検出によりシステムは打ち切られる。システムが再起動すると、コミット動作が完了する。コミット状態中にはロールバックは不可能である。
アプリケーションの全段階を完了（コミット）すると、ドライバプログラム14は閉鎖コマンドを発行する。このコマンドはアプリケーションが首尾よく完了したことを示している。この動作は回復ファイルとホストSDBを除去する。
本発明の回復実施例では、処理手順は同様であるが、例外点がいくつかある。第１に、コマンドと応答がホストSDBに記憶されない。逆に、準備コマンドがドライバプログラム14により発行されホストプログラム12と複数のエージェント24により実行されると、ドライバプログラム14のメモリイメージファイルが、周知の方式で、ディスクドライブなどの不揮発性記憶機構に記憶されるのが好ましい。メモリイメージは、ドライバプログラム14の（交換ファイル等を含む）アドレス空間全体、またはドライバプログラム14の保存状態を再創造するのに必要な（ドライバプログラム14の特定の実施用のプログラマにより決定された）ドライバプログラム14の臨界データ構造だけを含む。（たとえば、メモリのプログラム静止画を記憶されているイメージファイルと比較することにより）ホストプログラム12およびデータ記憶システム16とやり取りをするために、メモリイメージファイルの書込みが確認されシステムが準備完了状態に入ると、コミットコマンドは、上記のように、ドライバプログラム14により発行されホストプログラム12と複数のエージェント24により実行される。好ましい実施例では、以前のメモリイメージファイルが削除する前に（すなわち、「Ａ」と「Ｂ」コピーが周知の方式で維持される）次のメモリイメージファイルが書き込まれ確認される。以前のメモリイメージファイルは、コミット動作が完了しなければ削除されない。
（ｄ）回復：閉鎖動作を実行することなく終了したアプリケーションは障害が発生したと考えられる。アプリケーションが再起動されると、回復を起動する。好ましい実施例では、ホストプログラム12が開始するときは常に、ホストプログラム12は回復ファイルがあるかどうかを検査する。好ましい実施例では、ファイルがあると、ホストプログラム12は、前の障害が発生したと仮定して、前のジョブを再度開始しようとする。
回復の第１工程は、すべてのファイルとデータベースをそれらの最近コミットした状態に回復することである。ホストSDBが実行、エラーまたは準備完了の状態を指示する場合、ホストプログラム12はロールバックコマンドを発行し、すべてのコミットされていない動作を周知の方式で元に戻す。ホストSDBがコミット状態を示す場合、ホストプログラム12はコミットコマンドを再発行し、割り込まれたコミット動作であるのが明らかな動作を完了する。
本発明の反復実施例では、ホストプログラム12は反復モードを入力する。上記したように、ドライバプログラム14は、適切な段階番号を含むキーを用いて、単一コマンドチャンネル18を介してシステムの残りと相互に作用する。その通信量はコミット処理中にホストSDBに自動的に記憶される。段階を反復するときには、ホストプログラム12はホストSDBから保存されたコマンドチャンネル通信量を検索することにより開始する。反復のために、ドライバプログラム14はその初期状態から再起動され、通常に機能する。反復期間中に、ドライバプログラム14により送られたすべてのコマンドがホストプログラム12により捨てられる。（安全のために、記録されたコマンドメッセージ通信量とそれらのコマンドを比較した後に行われる。ただし、これはオプションである。）ドライバプログラム14がコマンドチャンネル18を介して応答メッセージを受け取ろうとするときは常に、データ記憶システム16に記録された到来応答通信量からホストプログラム12により応答が取り出され、即座にドライバプログラム14に送られる。単一スレッド式コンピュータプログラムの決定特性のために、このプロセスの結果、ドライバプログラム14は障害のある実行中に行われたのと同じコマンド列を実行する。制御されたアプリケーションプログラムは以前の実行で実行されたのと同じ状態で終了することになる。
すべてのコミットされた段階からの記録されたコマンドチャンネル通信量が再生されると、以下のことが保証される。
（１）ドライバプログラム14が、最近のコミット動作までその状態を（反復により）回復されたこと。
（２）すべてのファイルとデータベースが、最近のコミット動作までそれらの状態を（２相コミットプロトコルにより）回復されたこと。
したがって、システムの状態は回復され、実行が通常通り進む。
本発明の回復実施例では、処理手順はいくぶん異なる。
（１）ホストSDBが準備完了状態を示し２つのメモリイメージファイル（ＡとＢ）が保存されていると、ホストプログラム12はより新しいファイルを削除する（したがって、２重コミットが阻止される）、ロールバックコマンドを発行し、より古いイメージファイル（すなわち、ドライバプログラム14の最後に知られた良好な保存されたイメージ）をメモリに再ロードする。ホストSDBが準備完了状態を示し１つのメモリイメージファイル（ＡまたはＢ）が保存される場合、ホストプログラム12がロールバックコマンドを発行し、そのイメージファイルをメモリに再ロードする。
（２）ホストSDBがコミット状態を示している場合、ホストプログラム12はコミットコマンドを発行し、最新のイメージファイルをメモリに再ロードする。
（３）ホストSDBが実行中またはエラー状態を示し、メモリイメージファイルが２つ保存されている場合、ホストプログラム12はロールバックコマンドを発行し、より新しいイメージファイルをメモリに再ロードする。メモリイメージファイルが１つ保存されている場合、ホストプログラム12はロールバックコマンドを発行しそのイメージファイルをメモリに再ロードする。
どの場合でも、ホストプログラム12はコマンドチャンネル18を再設定し、ドライバプログラム14の実行を再開する。
回復プロトコルは以下のことを保証する。
（１）コミット状態に入る前に障害が発生すると、ロールバックが実行され、最も古い（前準備状態）メモリイメージが使用される。コミット状態中に障害が発生すると、コミット動作は終了して、最新の（後準備状態）メモリイメージが使用される。コミット状態に入った後で障害が発生すると、ロールバックが実行され最新の（後準備状態）メモリイメージが使用される。
（２）ファイルとデータベースもすべて最新のコミット動作までそれらの状態に（たとえば、２相コミットプロトコルにより）回復される。
したがって、システムの状態が回復され、実行は通常通り進む。
エージェント
以下の説明はホストプログラム12に起動される各エージェント24に適用される。用語「ローカルノード」は、特定のエージェント24が実行中のシステムを示すのに使用される。
各エージェント24はアプリケーションを実行するのに必要な実際の動作を実行する。エージェント24の役割は、それが実行中のリモートシステム20でのみ複数の動作を実行することである。これらの動作には遠隔処理手順呼出しの実行、こうした動作のコミットとロールバック、ならびに複数のプロセスの作成と監視が含まれる。エージェント24は、アプリケーションが実行可能な時と方法を制御しているので、アプリケーションとオペレーティングシステムの「間に」あると考えることができる。
遠隔手続き呼出し（RPC）の形で複数のコマンドがドライバプログラム14によりエージェント24にホストプログラム12を介して送られている。好ましい実施例では、RPCコマンドはコマンド識別子とその後に続く一連の引数から構成され、引数はすべてテキスト列である。エージェント24は、RPCコマンド識別子を「RPCハンドラ」にマッピングするテーブルを含む。ハンドラはサブルーチンを呼び出してRPCを実行し、RPCをコミットし、RPCをロールバックするオブジェクトである。したがって、エージェント24は適切なRPCハンドラを探しだして、そのRPCハンドラにRPCの引数を与えることによりRPCを処理する。RPCハンドラルーチンは引数列を解析して、要求された動作を実行する。この後で、RPCハンドラルーチンは応答列を作成し、この応答列はホストプログラム12を介してドライバプログラム14に送り返される。各応答列にはコマンドの成功についての情報と要求された戻りデータが含まれている。好ましい実施例には、以下に説明するように、複数のプロセスを開始するために特殊なRPCが使用されている。
エージェント24が起動すると、それが受信する第1PRCコマンドは開始エージェントコマンドである。このコマンドはエージェント24にアプリケーション用のジョブIDを通知して、ローカルノードに固有の「ノードID」を指定する。次に、エージェント24は「エージェントSDB」と呼ばれる状態データベースを開く。エージェントSDBの名前はジョブIDとノードIDから誘導されるので、アプリケーションを通して固有である。
各エージェント24はホストプログラム12に沿ってアプリケーションの複数の段階を追跡する。ホストプログラム12が準備またはコミット動作を実行するときには、準備ノードとコミットノードRPCコマンドをエージェント24のそれぞれに送ることで実行される。好ましい実施例では、一旦エージェント24がすべて首尾よくそれら固有の準備ノードコマンドに応答すると、ドライバプログラム14はアプリケーション全体が準備完了状態にあるとしか考えられないことになる。同様に、エージェント24がすべてそれらのコミットノードコマンドに首尾よく応答した場合には、アプリケーションは遂行された段階を考慮し次の段階に進むだけである。
各エージェント24は現段階とその状態をエージェントSDBに記録する。４つの定義された状態と可能な状態変化はホストプログラム12と同じであり、通常の場合には、ホストプログラム12のこれらの状態と状態変化に追随する。現段階状態（および現段階番号）は「ノード状態」RPCコマンドによりドライバプログラム14により検索できる。
ドライバプログラム14が閉鎖機能を呼び出すと、閉鎖コマンドが各エージェント24に発行される。各エージェント24は、ローカル段階状態が実行中で実行中のプロセスがないことを検査することで応答して、その関連するエージェントSDBを削除する。
好ましい実施例では、各エージェント24は複数のRPC動作を実行する。これらのRPC動作は段階の一部なので、コミット／ロールバックトランザクションアーキテクチャに応じている。これを実行するには、各エージェント24はそのエージェントSDBを使用する。特に、各段階では、エージェント24はそのエージェントSDBに「CR_LIST」と呼ばれるリストを作成し、各動作毎にデータが入力される。各入力は、周知の方式で、動作を元に戻すのに十分な情報を保持している。このリストは、動作が実行されたのと逆の順序でそれらの動作は元に戻されるよう順序づけられるのが好ましい。
好ましい実施例では、統一するために、RPCすべてが以下の制限に従うようになっている。
（１）RPCがファイル／データベースの状態を変える場合、そのファイル／データベースに加える変更をロールバックするのに必要な情報をそのRPCは保存し、CR_LISTの入力を作成しなければならない。この入力は実行中のRPCコマンドの識別を備えてなければならないので、適切なRPCハンドラはコミット／ロールバック処理中に配置できる。
（２）各RPCハンドラは、（RPCがデータベースまたはファイルへの変更を加えない場合には空白動作となる）準備、コミットおよびロールバック動作を実施する手段を備えてなければならない。
（３）各RPCハンドラはオプションで、各エージェント24のSDBを使用して、用件を充足するのに必要な情報を記憶することができる。
（４）ファイル／データベースの状態に変更を加えないRPCに特殊な動作は不必要である。
好ましい実施例では、アプリケーションプログラムは以下に示す規則に従わなければならない。
（１）プロセスがファイル／データベースを修正する場合、変更をロールバックし準備／コミット／ロールバック動作を実施する手段を備えてなければならない。エージェント24の制御下での複数のプロセスは、エージェントSDBにもアクセスする。たとえば、アプリケーションプログラムはCR_LISTに複数の入力を作成可能である。こうした入力は、適切なコミット／ロールバック動作を実施するRPCコマンド用の識別子を含んでなければならない。しかし、この場合には、RPCは実際には発生しないので、「ダミーRPC」の識別子が入力される。
（２）代りに、ドライバプログラム14は、同じ効果をもつプロセスのために複数のRPCを発行することができる。
エージェント24への開始プロセスコマンドによりエージェント24は特殊なアプリケーションプログラムイメージファイルを実行させて、ローカルノードで「プロセス」を開始する。好ましい実施例では、このコマンドへの引数は以下を供給する。
（１）プログラム用の実行可能イメージファイル
（２）プログラムの引数リスト
（３）プログラムが必要とする任意のオペレーティングシステム環境情報
（４）標準入出力およびエラーチャンネルとして使用されるプロセスに対して開かれるファイルまたはパス名
（５）実行が成功したことを示す、プログラムを終了させる出口状況コード
（６）デバッグモード（デバッギングは以下に記載される）
各エージェント24はその制御下ですべてのプロセスのリストを維持する。プロセスが始まると、これらのプロセスの識別子がこのリストに追加される。
好ましい実施例では、各エージェント24は、ドライバプログラム14に応答して初めてプロセスの終了を待機する。各エージェント24によりプロセスは、そのプロセスの実行を監視しながらエージェント24と同時に実行される。常に、エージェント24はプロセスの「プロセス状態」を知っている。この状態は、好ましい実施例ではPS_RUNNING,PS_ERROR,PS_DEBUGまたはPS_EXITEDの１つである。
PS_RUNNING状態は周知の問題なしにプログラムプロセスが実行中であることを示す。PS_ERROR状態は、プロセスが解決不可能な問題に遭遇したことが判明したことを示し、さらに（１）プロセスがエラー条件（信号またはエラートラップ）を合図するか、（２）障害を示すエラー状況で終了したか、または（３）通常ではない方式で終了したか（たとえば、中止またはオペレータによる手段終了など）を示している。PS_EXITED状態は、プロセスが首尾よく実行を完了し、通常の方式で終了したことを示している。PS_DEBUG状態は以下の「デバッギング」で説明される。
好ましい実施例では、ドライバプログラム14は「ProcState」PRCコマンドを使用してプロセスの状態を尋ねることができる。各エージェント24は、集合プロセス状態も維持し、エージェントが全体として開始するよう指令されたすべてのプロセスの状態を示す。この集合状態は「ノードプロセス状態」と呼ばれ、ノードのコミット／ロールバック状態（実行中、準備完了、コミット中、エラー）から離れている。ノードプロセス状態はこれら４つのプロセス状態と同じであり、以下のように定義される。
（１）任意のプロセスがPS_DEBUG状態にある場合、集合状態はPS_DEBUGである。そうでない場合、
（２）任意のプロセスがPS_ERROR状態にある場合、集合状態がPS_ERRORである。そうでない場合、
（３）任意のプロセスがPS_RUNNING状態にある場合、集合状態はPS_RUNNINGである。そうでない場合、
（４）集合状態はPS_EXITEDである（すべてのプロセスは通常に終了した）。
ノードプロセス状態の遷移はノードのコミット／ロールバック状態に影響を及ぼす。特に、ノードプロセス状態がPS_ERROR状態に遷移する場合、ノードのコミット／ロールバック状態は自動的にエラー状態に遷移する。さらに、プロセス状態がPS_EXITEDの場合には、実行中状態から準備完了状態または準備完了状態からコミット状態への遷移だけが唯一つの規約順守である。
集合プロセス状態はノード状態エージェントコマンドによりドライバプログラム14により検索可能である。
好ましい実施例では、複数のプロセスは標準エラー入出力チャンネルを介してエラーメッセージを発する。たとえば、UNIXでは、これは「stderr」入出力ファイルである。こうした出力はオプションとして、任意のプロセスからエージェント24に経路設定可能であり、「Eread」RPCコマンドを介してドライバプログラム14に利用可能である。
ドライバプログラム14は、１つのノードまたはノードのセットにおいて始まったすべてのプロセスが実行を完了するまで実行を継続できない環境にしばしば入る。この環境に適応するには、エージェント24はドライバプログラム14から「待機」コマンドを指示する。待機コマンドにより、ノードプロセス状態がPS_RUNNING状態を終えるまで（すなわち、状態はPS_DEBUG,PS_ERRORまたはPS_EXITED）エージェント24はその応答を遅延させる。待機コマンドへの応答は、待機状態を終了させる処理を示している。ドライバプログラム14は、待機状態中にエージェント24に「sync」RPCコマンドを送ることで待機状態を取り消すこともできる。介入待機応答が偶然受信されてもされなくてもSync（同期）コマンドは動作する（というのは、待機応答および同期コマンドがコマンドチャンネル18で交差しているからである）。
プロセスデバッギング
時には、ドライバプログラム14によりユーザがシステムの特定のプロセスをデバッグできるようにすることが有益である。デバッギングは、特定のオペレーティングシステムの元で利用可能な標準デバッガの制御下でのプロセスの実行を必要とする。ユーザは実行の最初からプロセスのデバッグを希望できる。代りに、プロセスがエラー状態に遭遇する場合、すなわち、プロセスがPS_ERRORプロセス状態に遷移するときのみに、ユーザはそのプロセスのデバッグを希望できる。
好ましい実施例では、あるプロセスが（開始プロセスコマンドを用いて）始められる場合、そのプロセスは、DEBUG_NONE,DEBUG_START及びDEBUG_TRACEの３つのデバッグモードの任意のもので実行可能になるように指定できる。DEBUG_NONEデバッグモードのプロセスではデバッガを動作させる必要なない。DEBUG_STARTモードで指定された処理は関連するデバッガにより始めから実行されることになる。DEBUG_TRACEモードで指定された処理はエージェント24により監視され、こうした処理が様々な検出可能エラー状態（エラートラップ、信号または仕切りなど）の任意の状態に入る場合、こうした状態は停止され、デバッガは障害プロセスに接続された状態で実行される。
好ましい実施例では、エージェント24はデバッガを自主的に起動しない。代りに、プロセスが（デバッグモードにより指示されたように）デバッギングが必要な場合には、エージェント24はプロセスをPS_DEBUGプロセス状態に遷移する。これにより集合プロセス状態はPS_DEBUGに遷移する。この状態はドライバプログラム14に伝えられる（たとえば、この状態は待機状態を終了させることになる）。この時点で、ドライバプログラム14は「デバッグ」RPCコマンドを用いてプロセス用のデバッガを呼び出すことができる。このコマンドは実行すべきプログラム、おそらくはシェルスクリプトを指定し、選択のデバッガを起動するのに十分な情報が（引数リストを介して）そのプログラムに送られる。
回復
各エージェントは、そのエージェントSDBに記憶されているローカル段階番号と状態を維持する。段階番号は準備／コミットプロトコルを介してホストプログラム12のそれと同期する。段階状態は、プロセス状態から主に誘導され、アプリケーション用の現段階の状態を全体的に計算するためにドライバプログラム14により使用される。
ドライバプログラム14は、障害により再呼出しに失敗すると、ホストプログラム12にジョブを開始するよう伝える。「回復ファイル」が発見されると、ホストプログラム12は「回復モード」に入り、以下のようにエージェント24の状態を回復する。
（１）ホストSDBは、障害時に実行中の一連のエージェント24のプロセスを判定するのに使用される。
（２）新しいエージェント24は各ノードで作成される。
（３）新しいエージェント24には、ジョブIDをもつ「エージェント開始」コマンドが付与される。
（４）エージェントSDBは依然として存在しているから（その名前はジョブIDから誘導される）、エージェント24はこのジョブIDを従来のアプリケーションとして認識する。
（５）各エージェント24はそのログから再構成されたSDBを開き、現段階番号、状態およびコミット−ロールバックリストを抽出する。
（６）ホストプログラム12は、コミット中以外の状態にある場合、エージェント24にロールバックコマンドを送る。このコマンドによりエージェント24はその段階で実行された動作すべてを逆の順序で以前の状態に戻す。他方、ホストプログラム12は、コミット状態にある場合には、エージェント24にコミットコマンドを再発行する。コミット状態にあることが判明しているエージェント24は、コミット−ロールバックリストを準方向に横切り、すべての入力のコミット方法を実行することで明らかに割り込みコミット動作であるものを完了することになる。実行状態にあることが判明しているエージェント24は、コミットコマンドを空コマンドとして処理することになる（というのは、以前のコミット動作が他のノードではまだだがそのノードでは明らかに完了しているからである）。
（７）その時点では、エージェント24は実行状態にあるその段階の開始時にあると考えて、ドライバプログラム14からの複数のコマンドの取出しを開始する。
要約
図４は、本発明の反復実施例の基本機能動作を要約形式で示す流れ図である。ドライバプログラム14はリモートシステム20で複数のプロセスを開始する（ステップ40）。ホストプログラム12は、ドライバプログラム14からのすべての制御コマンドを、ドライバプログラム14へのすべての応答と同様に（ステップ42）、記録する（ステップ41）。各エージェント24は、その各リモートシステム20の各段階でアプリケーションを実行する（ステップ43）。アプリケーションは準備−コミットプロトコルを実行して、システムの一貫性を維持しながらシステムおよびファイルの状態を記憶する（ステップ44）。障害が発生すると、システムの状態が回復され、ドライバプログラム14が再起動し、ホストプログラム12にコマンドを発行する（ステップ45）。ホストプログラム12は各コマンドに対する応答を読み取り、実行されるまで、反復モードでドライバプログラム14に応答を送る（ステップ46）。次いで、ドライバプログラム14は、最後の良好なチェックポイントからアプリケーションプロセスの制御を続ける。
図５は、本発明の回復実施例の基本機能動作を要約形式で示す流れ図である。ドライバプログラム14はリモートシステム20でプロセスを開始する（ステップ50）。各エージェント24は、その各リモートシステム20で各段階のアプリケーションを実行する（ステップ51）。アプリケーションはコミットプロトコルの準備部分を実行して、システムおよびファイルの状態を記憶する（ステップ52）。準備プロトコルが実行されるとドライバメモリ14のメモリイメージが記憶される（ステップ53）。アプリケーションがコミットプロトコルを実行して、システムの一貫性を維持しながらシステムおよびファイル状態の保存を完了する（ステップ54）。障害が発生すると、システムの状態が回復して、ドライバプログラム14の記憶メモリイメージがメモリに再ロードされる（ステップ55）。次いで、ドライバプログラム14は、最後の良好なチェックポイントからアプリケーションプロセスの制御を続ける（ステップ56）。
本発明について多くの実施例が説明されてきた。しかし、本発明の精神と範囲から逸脱することなく様々な修正を加えることが可能なことを理解すべきである。たとえば、本発明はCPUが１つのシステムに適用可能である。さらに、２相コミットプロトコルが好ましいが、システム一貫性を維持しながらシステムの状態を安全に保存する他のコミットプロトコルが使用できる。したがって、本発明は特定の例示実施例によって制限されるものではなく、添付の請求の範囲によってのみ制限されるものであることを理解すべきである。

Claims (4)

1. 並列処理システムにおいて事前プログラム式チェックポインティング機能を備えてないコンピュータアプリケーションを実行する方法であって、（ａ）並列処理システムにおいて個々の実行段階であって、アプリケーションの全てのプロセスが前記実行段階間において停止されることが要求される実行段階でアプリケーションを実行する工程と、（ｂ）複数のコマンドを発行し、こうしたコマンドに応答することで前記アプリケーションの各実行段階の処理を制御する工程と、（ｃ）こうしたコマンドとこれらコマンドに対する応答すべてを記録する工程と、（ｄ）首尾よく完了した実行段階それぞれの終了状態を保存する工程と、（ｅ）こうした実行段階の任意の段階での前記アプリケーションの障害を検出する工程と、（ｆ）障害が検出された実行段階の前の実行段階の最後に保存された終了状態を回復する工程と、（ｇ）前記アプリケーションの実行の開始から障害が検出された実行段階の前の実行段階の最後に保存された終了状態までの記録コマンドおよびこうしたコマンドに対する応答すべてを反復する工程と、（ｈ）障害が検出された実行段階の開始から前記アプリケーションを再開する工程と、を有する方法。
2. 並列処理システムにおいて事前プログラム式チェックポインティング機能を備えてないコンピュータアプリケーションを実行するコンピュータ装置であって、（ａ）並列処理システムにおいて個々の実行段階であって、アプリケーションの全てのプロセスが前記実行段階間において停止されることが要求される実行段階でアプリケーションを実行する手段と、（ｂ）複数のコマンドとそれらのコマンドへの応答を発行することで前記アプリケーションの各実行段階の処理を制御する手段と、（ｃ）こうしたコマンドとこれらコマンドに対する応答すべてを記録する手段と、（ｄ）首尾よく完了した実行段階それぞれの終了状態を保存する手段と、（ｅ）こうした実行段階の任意の段階での前記アプリケーションの障害を検出する手段と、（ｆ）障害が検出された実行段階の前の実行段階の最後に保存された終了状態を回復する手段と、（ｇ）前記アプリケーションの実行の開始から障害が検出された実行段階の前の実行段階の最後に保存された終了状態までの記録コマンドおよびこうしたコマンドに対する応答すべてを反復する手段と、（ｈ）障害が検出された実行段階の開始から前記アプリケーションを再開する手段と、を有するコンピュータ装置。
3. 並列処理システムにおいて事前プログラム式チェックポインティング機能を備えてないコンピュータアプリケーションを実行する方法であって、（ａ）アプリケーションを個々の実行段階であって、アプリケーションの全てのプロセスが前記実行段階間において停止されることが要求される実行段階に分割する工程と、（ｂ）並列処理システムで前記アプリケーションの実行を開始する工程と、（ｃ）複数のコマンドを発行し、こうしたコマンドに応答することで前記アプリケーションの各実行段階の処理を制御する工程と、（ｄ）こうしたコマンドとこれらコマンドに対する応答すべてを記録する工程と、（ｅ）２相コミットプロトコルにより首尾よく完了した実行段階それぞれの終了状態を保存する工程と、（ｆ）こうした実行段階の任意の段階での前記アプリケーションの障害を検出する工程と、（ｇ）障害が検出された実行段階の前の実行段階の最後に保存された終了状態を回復する工程と、（ｈ）前記アプリケーションの実行の開始から障害が検出された実行段階の前の実行段階の最後に保存された終了状態までの記録コマンドおよびこうしたコマンドに対する応答すべてを反復する工程と、（ｉ）障害が検出された実行段階の開始から前記アプリケーションを再開する工程と、を有する方法。
4. 並列処理システムにおいて事前プログラム式チェックポインティング機能を備えてないコンピュータアプリケーションを実行するコンピュータ装置であって、該コンピュータ装置は、（ａ）アプリケーションを個々の実行段階であって、アプリケーションの全てのプロセスが前記実行段階間において停止されることが要求される実行段階に分割する手段と、（ｂ）並列処理システムで前記アプリケーションの実行を開始する手段と、（ｃ）複数のコマンドを発行し、こうしたコマンドに応答することで前記アプリケーションの各実行段階の処理を制御する手段と、（ｄ）こうしたコマンドとこれらコマンドに対する応答すべてを記録する手段と、（ｅ）２相コミットプロトコルにより首尾よく完了した実行段階それぞれの終了状態を保存する手段と、（ｆ）こうした実行段階の任意の段階での前記アプリケーションの障害を検出する手段と、（ｇ）障害が検出された実行段階の前の実行段階の最後に保存された終了状態を回復する手段と、（ｈ）前記アプリケーションの実行の開始から障害が検出された実行段階の前の実行段階の最後に保存された終了状態までの記録コマンドおよびこうしたコマンドに対する応答すべてを反復する手段と、（ｉ）障害が検出された実行段階の開始から前記アプリケーションを再開する手段と、を有するコンピュータ装置。

Images