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