JPH11508069A - 持続性状態のチェックポイントおよび復旧システム - Google Patents

Abstract

(57)【要約】 チェックポイント復旧システムは、ユーザアプリケーションプロセスに対して、正常実行中に、揮発性状態と、持続性状態の所望の部分とを含むプロセス状態を保存し、その後、保存された状態を復旧する。遅延チェックポイント技術により、チェックポイント実行された揮発性状態と、持続性状態の一部との間の不整合が生じるまで、持続性状態チェックポイントの設定が遅延される。本発明のチェックポイント復旧システムにより、ユーザアプリケーションプロセスは、持続性状態のうち指定した部分をチェックポイントから除外することができる。返値引数のような、復旧前プロセス状態の選択された部分を、チェックポイント実行された状態にユーザアプリケーションプロセスを復旧する前に保護して、保護された状態の復旧前の値をチェックポイントの復旧後も保持することが可能である。保持された返値は、復旧コードのセグメントが復旧後に実行されることを可能にするとともに、正常実行モードを復旧モードから区別することも可能にする。

Description

【発明の詳細な説明】 持続性状態のチェックポイントおよび復旧システム発明の属する技術分野 本発明は、プロセスの状態をチェックポイント実行および復旧するシステムに 関し、特に、持続するプロセス状態の遅延チェックポイントを含む、プロセス状 態を中断および復旧するシステムに関する。従来の技術 ますます、ソフトウェアアプリケーションのユーザは、ソフトウェアがソフト ウェア故障（フォルト）を起こしにくいこと、あるいは少なくとも故障に対して 耐性があることを要求している。例えば、通信交換システムのユーザは、交換シ ステムが連続して利用可能であることを要求する。さらに、通信が、銀行の自動 預払機の場合のような金融取引の場合、あるいはその他の重要なデータの場合、 顧客は最高度のデータ整合性をも要求する。 こうして、ユーザアプリケーションプロセスに結果を引き起こす可能性のある 多くのプログラミングエラーを検出するためのさまざまなソフトウェア検査デバ ッグツールが開発されている。例えば、米国カリフォルニア州SunnyvaleのPure Software，Inc.から市販されており、米国特許第５，１９３，１８０号に記載さ れている、Purify^TMソフトウェア検査ツールは、メモリアクセスエラーおよびメ モリリークを検出するシステムを提供している。Purify^TMシステムは、メモリの 各バイトのアロケーションおよび初期化ステータスをモニタする。さらに、メモ リにアクセスする各ソフトウェア命令ごとに、Purify^TMシステムはテストを実行 し、プログラムが未割当てメモリに書き込みをしていないこと、および、未初期 化あるいは未割当てのメモリから読み出しをしていないことを保証する。 Purify^TMシステムのようなソフトウェア検査デバッグツールは、ユーザアプリ ケーションプロセスにおける故障につながる可能性のある多くのプログラミング エラーを検出するための有効な基礎を提供するが、ソフトウェアデバッグプロセ ス中に確認、検証あるいは検査をいくら実行しても、すべてのソフトウェア故障 を検出して除去し、ユーザアプリケーションプログラムにおける完全な信頼性を 与えることはできない。従って、未検査の境界条件による残留故障、予測しない 例外、および、予期しない実行環境が、検査およびでバッグのプロセスを免れる ことが観察されており、プログラム実行中にトリガされるとこれらは表面化して 、アプリケーションプロセスのクラッシュあるいはハングを引き起こすことによ り、サービス中断を引き起こすことになる。 従って、ユーザアプリケーションが、損失する情報の量を最小にして、故障か ら回復することができる機構を提供することが所望される。そこで、ハードウェ アおよびソフトウェアの障害から効果的に回復して、損失する情報量を最小にす るために、いくつかのチェックポイント実行および復旧の方法が提案されている 。チェックポイント実行およびロールバック（後退復帰）回復の技術に関して一 般的には、R．Koo and S．Toueg，″Checkpointing and Rollback-Recovery for Distributed Systems″，IEEE Trans．Software Eng.，Vol.SE-13，No.1，pp.2 3-31（１９８７年１月）に記載されている。一般に、チェックポイントおよび復 旧の技術は、正常実行中にプロセスの状態を定期的に保存し、その後、障害後に 、保存した状態を復旧する。このようにして、損失する作業の量は、復旧したチ ェックポイント以降にユーザアプリケーションによってなされた進展へと最小化 される。 注意すべき点であるが、プロセスの状態には、揮発性の状態と、持続性の状態 が含まれる。揮発性状態には、障害があると通常は失われてしまうプロセス情報 が含まれる。持続性状態には、ユーザアプリケーションプロセスの現在の実行に 関連するすべてのユーザファイルが含まれる。持続性状態は一般に障害があって も失われないが、データ整合性を維持するために、復旧した揮発性状態と同じポ イントに、持続性状態を復旧する必要がある。 既存のチェックポイント実行および復旧の技術は、揮発性状態のチェックポイ ント実行には十分に対処しているが、これらの方法は、持続性状態のチェックポ イント実行には十分に対処していない。１つのアプローチによれば、すべての持 続性状態、換言すれば、すべてのユーザファイルは、揮発性状態の各チェックポ イントでチェックポイント実行される。明らかに、この方法に伴うオーバーヘッ ドは、ほとんどのアプリケーションで非常に大きくなる。既存のUnix^TMのチェッ クポイントライブラリのような別の方法は、揮発性状態のチェックポイントがと られるときにアクティブあるいはオープンしているユーザファイルのファイルデ ィスクリプタのみをチェックポイント実行する。しかし、この方法では、チェッ クポイントがとられた後にユーザファイルが作成されあるいはアクティブになっ た場合、整合性の問題に遭遇する。その理由は、プロセスが最後のチェックポイ ントに復旧される場合、最後のチェックポイント以降に新たに作成されあるいは アクティブにされたファイルに対する変更はもとに戻されないためである。この ような不整合状態は、検出されない破損ファイルを生じることがしばしば起こり 得る。 このようなチェックポイント実行および復旧の技術は多くのアプリケーション 環境で有効に機能するが、いくつかの制限がある。これらの制限は、克服されれ ば、チェックポイント実行システムの整合性および透明性を拡大するとともに、 これまで考えられなかった他のアプリケーションへの有用性も拡大する。特に、 ほとんどの従来のチェックポイント実行および復旧の技術は、障害回復に関する こと以外のチェックポイント実行および回復の利点を活用していない。 上記の説明から明らかなように、持続性状態全体、あるいはその必要な部分が 、各チェックポイントに含まれることを可能にするチェックポイント実行および 復旧の技術が必要とされている。さらに、不整合が生じるまで持続性状態のチェ ックポイント実行を遅延させる遅延チェックポイント実行および復旧の技術が必 要とされている。さらに、新しいタスクを実行するための開始点として、保存さ れた中間状態を使用することができるように、持続性状態のうちの選択した部分 を、与えられたチェックポイントから除外することも可能な、チェックポイント 実行および復旧のシステムが必要とされている。さらに、保護された状態の復旧 前の値がチェックポイントの復旧後に維持されるように、復旧前に、現在のプロ セス状態のうちの選択した部分を保護することが可能なチェックポイントおよび 復旧のシステムが必要とされている。発明の概要 一般に、本発明の１つの特徴によれば、チェックポイントおよび復旧のシステ ムは、正常実行中にプロセス状態を保存し、その後で、例えば障害後の回復モー ド中に、保存された状態を復旧するために、ユーザアプリケーションプロセスに おいてチェックポイントおよび復旧の技術を実装する。本発明の特徴によれば、 チェックポイントおよび復旧のシステムは、揮発性および持続性の両方の状態の チェックポイントを実行する。一実施例では、持続性状態のチェックポイント実 行は、チェックポイント実行された揮発性状態と、ユーザファイルの間の不整合 が生じるまで、持続性状態のチェックポイントをとることを遅延させる遅延チェ ックポイント法からなる。 本発明のもう１つの特徴によれば、チェックポイントおよび復旧のシステムに より、ユーザあるいはユーザアプリケーションプロセスは、持続性状態のうちの 選択した部分を、チェックポイントから除外すべきであるとして指定することが できる。このようにして、所望の中間状態をチェックポイント実行して、新たな 処理タスクを実行するための開始点として使用することができる。例えば、ユー ザアプリケーションプロセスが長い初期化プロセスを必要とし、その後、同じ初 期化された状態を利用していくつかの入力を処理する場合、入力ファイルをチェ ックポイントから除外し、初期化された状態をチェックポイント実行することが できる。その後、チェックポイント実行された初期化状態を復旧して、新たな入 力ファイルのセットごとに、処理タスクを実行することができる。こうして、ユ ーザアプリケーションプロセスは、所望のあるいは予測可能な状態から、将来の 入力を処理することができる。別の実施例では、本発明のチェックポイントおよ び復旧のシステムは、持続性状態全体、換言すれば、すべてのユーザファイルを 、チェックポイント実行されるプロセス状態の部分がら除外するために利用する ことが可能である。 本発明のもう１つの特徴によれば、コンピュータシステム上で実行されるユー ザアプリケーションプロセスをチェックポイント実行し復旧する方法が実現され る。この方法において、ユーザアプリケーションプロセスは、揮発性状態と、ユ ーザファイルからなる持続性状態とを含むプロセス状態を有する。本発明の方法 は、 チェックポイント位置で揮発性状態をチェックポイント実行するステップと、 持続性状態をモニタして、持続性状態を変更することになるチェックポイント 位置の後のファイル操作を検出するモニタステップと、 モニタステップが、持続性状態の変更が実行されることを検出した場合、持続 性状態のうち少なくとも変更されることになる部分をチェックポイント実行する ステップと、 プロセス状態をチェックポイント位置に復旧することにより、チェックポイン ト位置以降の持続性状態に対する変更をもとに戻すステップと、 チェックポイント位置からユーザアプリケーションプロセスの実行を再開する ステップとからなる。 本発明のさらにもう１つの特徴によれば、ユーザアプリケーションプロセスに 伴う初期化された状態を復旧する方法が実現される。この方法において、ユーザ アプリケーションプロセスは、プロセス状態を有し、少なくとも２セットの入力 ファイルに対する初期化状態に基づいて処理タスクを実行する。本発明の方法は 、 （ａ）ユーザアプリケーションプロセスを初期化して初期化状態を形成するス テップと、 （ｂ）プロセス状態のチェックポイントから除外すべき入力ファイルを指定す るステップと、 （ｃ）プロセス状態のうち除外されなかった部分をチェックポイント実行する ステップと、 （ｄ）初期化状態および現在の入力ファイルのセットに基づいて処理タスクを 実行するステップと、 （ｅ）チェックポイント実行された状態にユーザアプリケーションプロセスを 復旧し、復旧モードを示すあらかじめ定義された返値を生成する復旧ステップと 、 （ｆ）復旧ステップがあらかじめ定義された返値を返した場合、新たな入力フ ァイルのセットを取得して、除外された入力ファイルを置き換えるステップと、 （ｇ）処理すべき入力ファイルのセットごとに、ステップｄ〜ｆを繰り返すス テップとからなる。 本発明のさらに完全な理解は、本発明のさらに多くの特徴および利点について の理解とともに、詳細な説明および図面を参照して得られる。図面の簡単な説明 図１は、本発明によるチェックポイント実行および復旧のシステムを示す概略 ブロック図である。 図２は、ユーザアプリケーションプロセスの実行グラフであり、揮発性チェッ クポイント、持続性チェックポイントおよび代替マシンへのプロセスマイグレー ションを示す。 図３は、ユーザアプリケーションプロセスとオペレーティングシステムの間の ファイルシステムコールをモニタして、持続性状態と揮発性状態の間の不整合を 生じることになる持続性状態に対する変更を検出する割込みルーチンを示す。 図４は、最後の揮発性チェックポイント以降に変更されたファイルごとに持続 性状態のチェックポイント情報を保持する持続性チェックポイントテーブルを示 す。 図５は、ユーザアプリケーションプロセスの実行前に呼び出される例示的な実 行前チェックポイントサブルーチンを記述する流れ図である。 図６は、揮発性状態をチェックポイント実行するために呼び出される例示的な 揮発性状態チェックポイントサブルーチンを記述する流れ図である。 図７は、図３のファイルシステムコール割込みサブルーチンの例示的な実装を 記述する流れ図である。これは、変更が揮発性状態と持続性状態の間の不整合を 生じる前にユーザファイルをチェックポイント実行するために呼び出される。 図８Ａおよび図８Ｂは、まとめて、復旧後の処理を制御することが可能な返値 とともに、指定されたチェックポイントにプロセス状態を復旧するために利用さ れる例示的な復旧サブルーチンを記述する流れ図である。 図９は、ユーザアプリケーションプロセスの実行後に呼び出されることが可能 な例示的なクリーンアップサブルーチンを記述する流れ図である。 図１０は、リソース不足状態によって引き起こされるソフトウェアの途中終了 を迂回するために、本発明の機能を組み込んだサンプルソースコードを示す。 図１１は、追加の入力ファイルおよびパラメータのセットの初期化状態をチェ ックポイント実行しその初期化状態にプロセス状態を復旧するために、本発明の 機能を組み込んだ、長い初期化を迂回する例示的なルーチンを記述する流れ図で ある。 図１２は、クリーンなメモリ状態をチェックポイント実行し、そのクリーンな メモリ状態にプロセス状態を復旧するために、本発明の機能を組み込んだ、例示 的なメモリ再設定サブルーチンを記述する流れ図である。詳細な説明 本発明によるチェックポイント復旧システム１０を図１に示す。以下でさらに 説明するように、チェックポイント復旧システム１０によれば、正常実行中にプ ロセス状態を保存し、その後で、例えば障害後の回復モード中に、保存された状 態を復旧するために、ユーザアプリケーションプロセスにおいてチェックポイン トおよび復旧の技術を実装することが可能となる。このようにして、アプリケー ションプロセスによって失われる作業量は、最後のチェックポイント以降に生成 されたものに限定される。 システムアーキテクチャ 図１に示すように、ここに開示するチェックポイント復旧システム１０は、ミ ニコンピュータ、ワークステーションまたはその他の汎用コンピュータ装置のよ うな処理ノード２０上に実装することが可能である。処理ノード２０は、少なく とも１つの処理ユニット２５およびメモリ記憶デバイス３０を有する。処理ノー ド２０の処理ユニット２５およびメモリ記憶デバイス３０は、既知のように、バ ス６０によって、または、ノード内通信のためのローカル処理ノード２０上のプ ロセス間通信（ＩＰＣ）設備によって、相互接続されることが可能である。さら に、各ノード２０は、既知のように、シリアルまたはパラレルのノード間通信の ための通信リンク７５へのネットワークインタフェース７０によって、他のノー ドあるいはリモート集中回復コーディネータ（図示せず）と相互接続されること も可能である。ネットワークインタフェース７０は、例えば、米国ペンシルヴェ ニア州ピッツバーグのFore Systems，Inc.から市販されているＡＴＭホストアダ プタカードである。このようにして、ユーザアプリケーションプロセスが、例え ば永久的なあるいは長期間のハードウェア障害により、ローカルノード２０上で 回復することができない場合、ユーザアプリケーションプロセスは、リモートの 処理ノードにエクスポートされることが可能である。この技術はしばしばプロセ スマイグレーションと呼ばれる。 処理ユニット２５は、単一のプロセッサとして、あるいは、並列に動作するい くつかのプロセッサとして実現することが可能である。メモリ記憶デバイス３０ は、一般に不安定な揮発性メモリの領域であるが、処理ユニット２５が取得、解 釈および実行することが可能な命令を格納することができる。一実施例では、揮 発性メモリ記憶デバイス３０は、処理ユニット２５によって実行されるプロセス ４０のような各ユーザアプリケーションプロセスに関連するソフトウェアコード とともに、ユーザプロセス４０によって呼び出されるチェックポイントライブラ リ関数５０を格納する。さらに、揮発性メモリ記憶デバイス３０は、既知のよう に、ユーザアプリケーションプロセス４０、および、チェックポイント復旧ライ ブラリ関数５０のそれぞれに関連するデータを記憶するデータセグメントセクシ ョン５５を含む。 ユーザアプリケーションプロセス４０によって呼び出されるチェックポイント ライブラリ関数５０は、チェックポイント復旧ライブラリ１５０から選択される 。チェックポイント復旧ライブラリ１５０は、ローカルに格納することも可能で あり、あるいは、ファイルシステム１２０のように集中ファイルシステム上に格 納することも可能である。ファイルシステム１２０のようなファイルシステムは 、ユーザがアクセス可能なファイルを格納するための集中倉庫を提供する。一般 に、集中ファイルシステム１２０は、不揮発性すなわち持続性メモリの領域であ り、電源がなくても情報を保持することができる。 以下でさらに説明するように、チェックポイント復旧ライブラリ１５０に含ま れる関数は、Ｃプログラミング言語のような高水準プログラミング言語で書かれ たユーザレベルのライブラリ関数である。チェックポイント復旧ライブラリ１５ ０内の関数は、正常実行中にプロセス状態を保存するために、あるいは、例えば 障害後の回復モード中に、保存された状態を復旧するために、ユーザアプリケー ションプロセスが読み出すことができる。一実施例では、チェックポイント復旧 ライブラリ１５０から関数を呼び出すユーザプロセス４０はは、コンパイル中に 、あるいは、ダイナミックリンキングプロセスによって、呼び出される関数のコ ードとバインドされる。 図１に示すように、チェックポイント復旧ライブラリ１５０は、実行前チェッ クポイントサブルーチン１５２を有する。実行前チェックポイントサブルーチン １５２はユーザアプリケーションプロセスの実行前に呼び出される。実行前チェ ックポイントサブルーチン１５２についてさらに詳細には図５に関して後述する 。さらに、チェックポイント復旧ライブラリ１５０は、揮発性状態チェックポイ ントサブルーチン１５４を有する。揮発性状態チェックポイントサブルーチン１ ５４は、ユーザアプリケーションプロセス４０によって呼び出されると、揮発性 メモリ３０から、ディスク１００のような不揮発性メモリの領域に、揮発性状態 のコピーを格納する。チェックポイントディスク１００は、処理ノード２０上に ローカルに存在することも可能であり、あるいは、通信ネットワークのリモート ノード上に存在することも可能である。揮発性状態チェックポイントサブルーチ ン１５４についてさらに詳細には図６に関して後述する。さらに、チェックポイ ント復旧ライブラリ１５０は、ファイルシステムコール割込みサブルーチン１５ ６を有する。ファイルシステムコール割込みサブルーチン１５６は、持続性状態 の所望の部分をチェックポイント実行するための遅延技術を提供する。ファイル システムコール割込みサブルーチン１５６についてはさらに図３および図７に関 して後述する。 また、ライブラリ１５０は、復旧サブルーチン１５８を有する。復旧サブルー チン１５８は、ユーザアプリケーションプロセスを所望のチェックポイントに復 旧するために呼び出される。復旧サブルーチン１５８についてはさらに図８Ａお よび図８Ｂに関して後述する。既に指摘したように、復旧サブルーチン１５８は 、持続性状態チェックポイントから除外されるユーザファイルをユーザが指定す ることを可能にする機構を提供して、ユーザアプリケーションプロセスが所望の あ るいは予測可能な状態から将来の入力を処理することを可能にする。最後に、チ ェックポイント復旧ライブラリ１５０は、クリーンアップサブルーチン１６０を 有する。クリーンアップサブルーチン１６０は、必要な場合に、作成されたチェ ックポイントファイルを削除するために、ユーザアプリケーションプロセスの実 行後に呼び出される。 さまざまな実装において、復旧サブルーチン１５８は、当業者には明らかなよ うに、検出された故障に応じて自動的に開始されることも可能であり、あるいは 、例えばコマンドライン入力によって、ユーザによりマニュアルで開始されるこ とも可能である。自動実装では、図１に示すように、ノード２０のような各ノー ドはウォッチドッグ８０を有することが可能である。ウォッチドッグ８０は、そ れぞれのノード上で実行されているプロセスをモニタするエラー検出モニタ８５ を含む。エラー検出モニタ８５は、プロセスがハングしているかあるいはクラッ シュしたかどうかを判定するために、プロセス４０のような、ノード２０上で実 行されているアプリケーションプロセスを連続してモニタする。 エラー検出モニタ８５によって実行されるモニタリングは、能動的であること も受動的であることも可能である。能動的モニタリング構成では、ウォッチドッ グ８０は、ローカルノード２０上のプロセス間通信（ＩＰＣ）設備を用いてプロ セスにメッセージを定期的に送り、その返値を評価することによって、モニタさ れる各アプリケーションプロセスをポーリングしてそのプロセスの状態を判定し 、プロセスがまだアクティブであるかどうかを判断する。 受動的モニタリング構成では、各アプリケーションプロセスはライブラリ１５ ０からの関数を含み、この関数は、プロセス４０のようなユーザアプリケーショ ンプロセスによって呼び出されると、指定された間隔で、ウォッチドッグ８０へ 、プロセス４０がまだアクティブであることを示すハートビート（鼓動）メッセ ージを送る。指定された間隔の終了前にウォッチドッグ８０がアプリケーション プロセス４０からシグナルを受信しない場合、ウォッチドッグ８０は、アプリケ ーションプロセスがハングしているかあるいはクラッシュしたと推定する。 後でさらに説明するが、エラー検出モニタ８５によってユーザアプリケーショ ンプロセス４０における故障が検出されると、再開始サブシステム９０が、後述 のように、最後のチェックポイントから、故障したアプリケーションプロセスの 再開始を行うことによって、故障したアプリケーションプロセスの回復を試みる 。再開始サブシステム９０は、障害が検出されたときに復旧サブルーチン１５８ を呼び出して、故障したユーザアプリケーションプロセスの再開始を行う。 チェックポイントおよび復旧の概念および定義 チェックポイントおよび復旧の概念および定義に関する一般的に説明は、例え ば、Yi-Min Wang et al.，″Progressive Retry Technique for Software Error Recovery in Distributed Systems″，Proc．of 23rd IEEE Conf．on Fault-To lerant Computing Systems(FTCS)，pp.138-144（１９９３年６月）、あるいは、 R．Koo and S．Toueg，″Checkpointing and Rollback-Recovery for Distribut ed Systems″，IEEE Trans．Software Eng.，Vol.SE-13，No.1，pp.23-31（１９ ８７年１月）に記載されている。一般に、チェックポイントおよび復旧の技術は 、損失する作業の量を最小にするために、正常なプログラム実行中にときどきプ ロセス状態を保存し、その後、例えば障害後に、保存されている状態を復旧する 。 図２に、プロセス４０のようなユーザアプリケーションプロセスの実行を示す 。ユーザアプリケーションプロセス４０が実行を続ける間に、揮発性チェックポ イントＶＣ₁、ＶＣ₂およびＶＣ₃のように、揮発性状態のチェックポイントが呼 び出される。ここで、揮発性状態という用語には、プログラムスタック、オープ ンファイルディスクリプタ、スタティック（静的）およびダイナミック（動的） データセグメントのような、障害時に通常は失われてしまう情報と、オペレーテ ィングシステムレジスタ、プログラムカウンタおよびスタックポインタのような 、現在のプログラム実行に本質的なオペレーティングシステムカーネルに関連す るデータ構造体が含まれる。 さらに、本発明の特徴によれば、ユーザアプリケーションプロセス４０が、ユ ーザファイルの属性のような、持続性状態を変更するファイル操作を実行しよう とする場合、影響されるファイルは、後述のようにして、所望のファイル操作が 実行される前に、持続性チェックポイントＰＣ_3'およびＰＣ_{3 ″}〜によって示さ れるように、チェックポイント実行される。ここで、持続性状態という用語には 、ユ ーザアプリケーションプロセスの現在の実行に関連するすべてのユーザファイル が含まれる。持続性状態は一般に障害時に失われないが、持続性チェックポイン トは、例えば障害が検出されたときにプロセスがその最後の揮発性チェックポイ ントまでロールバックした場合に、持続性状態が揮発性状態と整合することを保 証する。注意すべき点であるが、持続性状態は、与えられたファイルへの更新が 、最後のチェックポイントに関連する揮発性状態と不整合になるまでは、記録さ れない。後述のように、持続性チェックポイントＰＣ_3'およびＰＣ_{3 ″}によって 、最後の揮発性チェックポイント以降の持続性状態へのすべての変更はもとに戻 される。 このようにして、「Ｆ₁」で示される点で障害が検出されると、プロセスの揮 発性状態は、最後の揮発性チェックポイントＶＣ₃に関連するチェックポイント データを復旧することによって、チェックポイントＶＣ₃までロールバックする ことができる。さらに、持続性チェックポイントＰＣ_3'およびＰＣ_{3 ″}によって 、最後の揮発性チェックポイントＶＣ₃以降の持続性状態への変更はそれぞれも とに戻される。こうして、ロールバック後、持続性状態全体は、最後の揮発性チ ェックポイントＶＣ₃のときに存在したとおり、揮発性状態と整合する。注意す べき点であるが、プロセスがマシンＡで再開始することができない場合、図２に 示すように、プロセスマイグレーションによって、プロセスは、マシンＢのよう な代替マシン上で再開始することが可能である。 ファイルシステムコールに割り込むことによる持続性状態のモニタリング 既に指摘したように、持続性状態には、ユーザアプリケーションプロセスの現 在の実行に関連するすべてのユーザファイルが含まれる。一般に、ユーザアプリ ケーションプロセスがユーザファイルにアクセスし、それを変更することが可能 な唯一の方法は、オペレーティングシステムカーネルに送られるファイルシステ ムコールによるものである。従って、ユーザアプリケーションプロセスによって 生成される各ファイルシステムコールに割り込み、チェックポイント復旧システ ム１０によって評価すれば、持続性状態への可能なすべての変更を識別すること が可能である。こうして、図３に概念的に示したように、プロセス４０のような ユーザアプリケーションプロセスによって生成されるすべてのファイルシステム コールは、所望のファイル操作が実際にオペレーティングシステム３００によっ て実行される前に、割込みルーチン１５６によって割り込まれモニタされる。こ れについては図７に関して後述する。このようにして、ファイル操作が持続性状 態に関連するファイルを変更しようとしている場合、影響されるファイルの情態 は整合性を保証するために記録することができる。 一実施例では、持続性状態チェックポイントは、図４に示す持続性チェックポ イントテーブル４００に記録される。持続性チェックポイントテーブル４００は 、ディスクのような持続性メモリに格納され、テーブル４００が変更されるごと にディスクに格納される。各持続性チェックポイントテーブル４００は、特定の ユーザアプリケーションプロセスに関連するとともに、checkpoint idによって 識別される特定の揮発性チェックポイントに関連し、行４０５および４１０のよ うな複数の行を有する。各行は、関連する揮発性チェックポイント以降に何らか の変更を受けたユーザファイルに対応する。「ファイル名」によって示される各 ファイルごとに、持続性チェックポイントテーブル４００は、変更される可能性 のある各ファイル属性ごとのエントリを有する。例えば、持続性チェックポイン トテーブル４００は、各ファイルの「変更時刻」を記録するための列４３５と、 各ファイルの「アクセスモード」を記録するための列４４０と、各ファイルの現 在の「サイズ」を記録するための列４４５を含む。 一実施例では、テーブル４００の各エントリは、与えられたファイルに対して 行が作成されるときに、「−１」のようなデフォルト値で初期化される。その後 、ファイルの属性が変更されると、現在の属性値を、変更前に記録することがで きる。このようにして、復旧されるファイルの与えられた属性が「−１」という 値である場合、その属性は変更されておらず、復旧の必要がない。図７に関して 後述するように、エントリは、ファイルシステムコール割込みサブルーチン１５ ６によって、持続性チェックポイントテーブル４００内に作成される。さらに、 図８Ａおよび図８Ｂに関して後述するように、checkpoint idの値によって識別 される特定のチェックポイントの復旧中に、復旧サブルーチン１５８は持続性チ ェックポイントテーブル４００にアクセスし、それに含まれる情報を利用して持 続 性状態を復旧する。 チェックポイント復旧ライブラリ関数 実行前チェックポイントサブルーチン 既に指摘したように、チェックポイント復旧ライブラリ１５０は、実行前チェ ックポイントサブルーチン１５２を含む。実行前チェックポイントサブルーチン １５２は、ユーザアプリケーションプロセス４０の実行前に実行される。例えば 、Ｃプログラミング言語で書かれたプログラムは、通常、″main″ルーチンを有 する最初の行から実行を開始する。従って、実行前チェックポイントサブルーチ ン１５２の実行は、″main″ルーチンの実行前に呼び出されるべきである。 チェックポイント復旧システム１０は、挿入モードと透過モードという、チェ ックポイントを実行するための２つの動作モードを提供する。挿入モードは、ソ ースコードの所望の位置にチェックポイント関数を挿入することによって、ユー ザアプリケーションプロセスがチェックポイント機構を実装することを可能にす る。透過モードは、指定された時間間隔で自動的にチェックポイントを実行する 機構を提供する。透過モードによれば、ユーザアプリケーションプロセスは、ユ ーザアプリケーションプロセスへの変更や再コンパイルを必要とすることなく、 チェックポイント機構を組み込むことが可能となる。 後述のように、透過モードでは、あらかじめ定義された間隔でチェックポイン トを開始するために、実行前チェックポイントサブルーチン１５２によってクロ ックデーモンプロセスが生成される。後述のように、それぞれの指定された間隔 の終了時に、チェックポイントを開始するために、生成されたクロックデーモン プロセスの指示により、システム割込みコールがオペレーティングシステムによ って関連するユーザアプリケーションプロセスに送信される。 図５に示すように、実行前チェックポイントサブルーチン１５２は、ステップ ５００から開始し、その後、ステップ５０５で、チェックポイント復旧システム １０によって要求される、オープンファイルテーブルおよび持続性チェックポイ ントテーブル４００のようなデータ構造体を初期化する。 その後、ステップ５２０で、例えばコマンドライン上のユーザによる指定から 、 あるいは、環境変数の設定から、ユーザアプリケーションプロセスが挿入モード で実行されているかそれとも透過モードで実行されているかを判定するテストを 実行する。ステップ５２０で、ユーザアプリケーションプロセスが透過モードで 実行されていると判定された場合、ステップ５２５で、例えばforkシステムコー ルによって、クロックデーモンプロセスが生成される。既に指摘したように、ク ロックデーモンプロセスは、指定された間隔でユーザアプリケーションプロセス のチェックポイントを開始するチェックポイントタイマとして作用する。一実施 例では、チェックポイントは、谷間隔が指定されていなければ、３０分ごとのよ うなデフォルト間隔で開始される。 一方、ステップ５２０で、ユーザアプリケーションプロセスが挿入モードで実 行されていると判定された場合は、ユーザアプリケーションプロセスの実行によ って呼び出されるときにのみチェックポイントは開始される。 ステップ５４０で、ユーザアプリケーションプロセスに対する正しいチェック ポイントファイルが既に存在するかどうかを判定するテストが実行される。換言 すれば、このテストは、現在の実行が通常実行モードであるかそれとも回復モー ドであるかを判定する。注意すべき点であるが、ユーザアプリケーションプロセ スが正常終了すると、特に指定しない限り、図９に関して後述するように、クリ ーンアップサブルーチン１６０が、そのユーザアプリケーションプロセスに関連 するチェックポイントファイルを削除する。こうして、ユーザアプリケーション プロセスの開始時にチェックポイントファイルが存在する場合、例えば障害によ り前の実行が正常終了しなかったか、あるいは、ユーザアプリケーションプロセ スが、後の復旧のためにチェックポイントファイルを格納するよう要求したかの いずれかである。ステップ５４０で、ユーザアプリケーションプロセスに対する 正しいチェックポイントファイルが存在すると判定された場合、実行前チェック ポイントサブルーチン１５２は復帰し、図８Ａおよび図８Ｂに関して後述するよ うに、存在するチェックポイントファイルに関連するデータを復旧し、復旧した チェックポイントの時点からユーザアプリケーションプロセスの実行を開始する ために、ステップ５５０で、復旧サブルーチン１５８の実行が開始される。 一方、ステップ５４０で、ユーザアプリケーションプロセスに対する正しいチ ェックポイントファイルが存在しないと判定された場合、実行前チェックポイン トサブルーチン１５２は復帰し、ステップ５６０で、ユーザアプリケーションプ ロセスの実行が開始される。 揮発性状態チェックポイントサブルーチン 既に指摘したように、チェックポイント復旧ライブラリ１５０は、揮発性状態 チェックポイントサブルーチン１５４を有する。揮発性状態チェックポイントサ ブルーチン１５４は、透過モードでは、チェックポイントを開始すべきであると いうクロックデーモンからの割込みシグナルによって、あるいは、挿入モードで は、ユーザアプリケーションプロセスのソースコードに挿入されたチェックポイ ント関数コールが実行されるときに、呼び出される。さらに、後述のように、揮 発性状態チェックポイントサブルーチン１５４は、プログラムカウンタの値が復 旧された後に間接的に復旧サブルーチン１５８から呼び出される。 揮発性状態チェックポイントサブルーチン１５４は、ユーザアプリケーション プロセスを復旧するために必要な、障害時に失われてしまうすべての情報を保存 する。一実施例では、揮発性状態チェックポイントサブルーチン１５４は、各チ ェックポイント間隔を識別するために利用可能なcheckpoint id引数を渡される 。揮発性状態チェックポイントサブルーチン１５４がcheckpoint id引数を渡さ れない場合、以前のチェックポイントデータが上書きされる。checkpoint id引 数はグローバル変数とすることにより、後で、持続性状態のチェックポイントを 実装するファイルシステムコール割込みサブルーチン１５６が、適当な（現在の ）揮発性チェックポイントに持続性状態チェックポイントを関連づけるために、 アクセスすることができる。 既に指摘したように、中央処理ユニット内での値の一時記憶のためのハードウ ェアレジスタ、スタックポインタおよびプログラムカウンタのような、ユーザア プリケーションプロセスの現在の実行に関連するいくつかの揮発性情報は、オペ レーティングシステムカーネルによって管理される。これらのメモリ要素は通常 はユーザアプリケーションプロセスによってアクセス可能ではないが、オペレー ティングシステムは一般に、特定のユーザアプリケーションプロセスによって要 求されるオペレーティングシステム情報をチェックポイント実行することを可能 にするルーチンを提供している。このタスクを実行するためにオペレーティング システムによって提供されるルーチンは、ステップ６１０で、レジスタ、スタッ クポインタおよびプログラムカウンタの内容を保存するために実行される。例え ば、Unixオペレーティングシステムは、これらのオペレーティングシステムデー タ構造体にアクセスし、宣言したグローバルデータ構造体にそれらを保存するse tjmpコールを提供している。それらのグローバルデータ構造体は、その後、揮発 性状態の一部としてチェックポイント実行することができる。setjmpシステムコ ールの動作の詳細については、例えば、W．R．Stevens，″Advanced Programmin g in the Unix Environment″，pp.174-180(Addison Wesley，1992)に記載され ている。 その後、プログラム制御はステップ６２０に進む。注意すべき点であるが、復 旧サブルーチン１５８（図８Ａおよび図８Ｂ）の実行中、所望のチェックポイン トの復旧後、プログラムカウンタの値は、復旧したチェックポイントに対応する 値に復旧される。従って、プログラムカウンタの値が変更されることにより、復 旧サブルーチン１５８は、ステップ６１０の実行の直後の位置にジャンプするこ とになる。さらに注意すべき点であるが、復旧サブルーチン１５８は、０より大 きい返値を返す。これは、復旧後の実行のフローを制御するために利用可能であ る。例えば、あるあらかじめ定義された返値の場合にはあるコードが実行され、 別のあらかじめ定義された返値の場合には別のコードのシーケンスが実行される 。 こうして、ステップ６２０で、setjmpシステムコールのようなオペレーティン グシステムルーチンからの返値が０という値であるかどうかを判定するテストが 実行される。既に指摘したように、復旧サブルーチン１５８により、０より大き い返値を、回復モードで利用することが可能である。ステップ６２０で、返値が ０でないと判定された場合、揮発性状態チェックポイントサブルーチン１５４の 現在の実行が、回復モードで復旧サブルーチン１５８から呼び出されており、プ ログラム制御は、チェックポイント実行を行うことなく直接ステップ６７０に進 む。 一方、ステップ６２０で、返値が０に等しいと判定された場合、揮発性状態チ ェックポイントサブルーチン１５４の現在の実行は復旧サブルーチン１５８から 呼び出されたものではなく、揮発性状態チェックポイントサブルーチン１５４は 揮発性チェックポイントを続ける。すなわち、ステップ６３０で、揮発性チェッ クポイントの時点でオープンしているすべてのファイルのファイルディスクリプ タが、そのファイルのファイル名および現在の位置とともに、オープンファイル テーブルに格納される。オープンファイルテーブルは、各オープンファイルのフ ァイルディスクリプタ、ファイル名および位置を含む。その後、ステップ６４０ で、ユーザアプリケーションプロセスに関連するデータセグメントが、グローバ ル変数およびスタティック変数のようなすべての動的および静的に割り当てられ たメモリと、オープンファイルテーブルを含めて、保存される。最後に、ステッ プ６５０で、スタックの現在の内容が保存される。 揮発性状態チェックポイントサブルーチン１５４の実行はステップ６７０で終 了し、その後、指示された返値とともに復帰する。揮発性状態チェックポイント サブルーチン１５４が０の値を返す場合、これは、チェックポイントをとること に成功したことを示す。さらに、揮発性状態チェックポイントサブルーチン１５ ４が０より大きい値を返す場合、これは、実行のフローを制御するために利用可 能な返値とともに復旧サブルーチン１５８から間接的に実行が復帰していること を示す。 ファイルシステムコール割込みサブルーチン 既に指摘したように、チェックポイント復旧ライブラリ１５０は、持続性状態 チェックポイントを実装するファイルシステムコール割込みサブルーチン１５６ を含む。ファイルシステムコール割込みサブルーチン１５６は、ファイルの特定 の属性を変更する可能性のあるファイルシステムコールに割り込み、必要な場合 には、持続性状態のうちの変更される部分の遅延チェックポイントを実行する。 ファイルシステムコール割込みサブルーチン１５６は、要求されるファイル操作 を実際に実行する前に、持続性状態チェックポイントを実行する。さらに、ファ イルシステムコール割込みサブルーチン１５６は、必要な限りにおいてのみ、持 続性状態のチェックポイントを実行する。 ファイルシステムコール割込みサブルーチン１５６は、それぞれの割り込まれ るファイルシステムコールの受信時に、ステップ７００から開始する。ステップ ７１０で、割り込まれるファイル操作が、チェックポイントの設定を開始すべき ファイル属性を変更するかどうがを判定するテストが実行される。ステップ７１ ０で、割り込まれるファイル操作がチェックポイントの設定を開始すべきファイ ル属性を変更しないと判定された場合、プログラム制御はステップ７５０に進み 、後述のようにして所望のファイル操作を実行する。 一方、ステップ７１０で、割り込まれるファイル操作がチェックポイントの設 定を開始すべきファイル属性を変更すると判定された場合、ステップ７２０で、 ユーザが例えば関数コールを実行すること、コマンドライン引数を入力すること 、あるいは環境変数を設定することによって、現在のファイルはチェックポイン トから除外すべきであると指定したかどうかを判定するテストが実行される。こ のようにして、ユーザあるいはユーザアプリケーションプロセスは、与えられた ファイルが持続性状態チェックポイントに含まれるべきがどうかを、ファイルご とに選択的に指定することができる。 ステップ７２０で、現在のファイルはチェックポイントから除外すべきである と判定された場合、プログラム制御はステップ７５０に進み、後述のようにして 所望のファイル操作を実行する。一方、ステップ７２０で、現在のファイルはチ ェックポイントから除外すべきでないと判定された場合、ステップ７３０で、グ ローバル変数checkpoint idの現在の値によって識別される最後の揮発性チェッ クポイント以降にこのファイルは既にチェックポイント実行されたかどうかを判 定するテストが実行される。ステップ７３０で、最後の揮発性チェックポイント 以降にこのファイルは既にチェックポイント実行されたと判定された場合、プロ グラム制御はステップ７５０に進み、後述のようにして所望のファイル操作を実 行する。 一方、ステップ７３０で、最後の揮発性チェックポイント以降にこのファイル は既にチェックポイント実行されてはいないと判定された場合、ステップ７４０ で、このファイルのシャドウコピーを作成し、ファイル名と、変更される属性の 以前の値を、checkpoint idの現在の値に対応する持続性チェックポイントテー ブル４００に追加することによって、このファイルはチェックポイント実行され る。代替実施例では、持続性状態チェックポイントは、属性ごとに各ファイルを チェックポイント実行し、現在のファイルシステムコールによって影響される属 性のみをチェックポイント実行することによって、さらに最適化することが可能 である。換言すれば、ファイル操作は全属性のうちのサブセットのみに影響し、 ファイル操作がステップ７５０で実行される前に、影響される属性のサブセット のみをチェックポイント実行すればよい。例えば、writeシステムコールが既存 のファイルの終端にデータを追加するのみである場合、そのファイルの、揮発性 チェックポイントにおいて存在したファイル内容は変更されないため、ファイル 内容をチェックポイント実行せず、ファイルサイズをチェックポイント実行すれ ば十分である。復旧後、このファイルは適当なサイズに切り詰めることが可能で ある。 ステップ７４０でファイルをチェックポイント実行した後、必要であれば、ス テップ７５０で、所望のファイル操作を実行することが可能である。持続性状態 チェックポイントは、ファイル操作が実行される前に記録されるため、持続性チ ェックポイントテーブル４００に格納される情報は、最後の揮発性チェックポイ ント以降に各ユーザファイルになされた変更をもとに戻すために使用することが 可能である。ステップ７５０で、所望のファイル操作が実行された後、ファイル システムコール割込みサブルーチン１５６の実行はステップ７６０で終了し、ユ ーザアプリケーションプロセスの実行に復帰する。 復旧サブルーチン 既に指摘したように、チェックポイント復旧ライブラリ１５０は、図８Ａおよ び図８Ｂに示す復旧サブルーチン１５８を含む。復旧サブルーチン１５８は、例 えば障害が検出された後にウォッチドッグ８０によってアプリケーションプロセ スが正しいチェックポイントから再開始されるときに、あるいは、ユーザアプリ ケーションプロセスに対応するソースコードにロールバック関数コールが挿入さ れているときに、呼び出される。ここで、ロールバックという用語は、ユーザあ るいはユーザアプリケーションプロセスによって開始される復旧を示し、回復と いう用語は、正しいチェックポイントファイルによる障害後の復旧を示すために 用いられる。一実施例では、復旧サブルーチン１５８には以下の引数が渡される 。 ・mode（モード）の値は、現在の実行が回復モードであるかそれともロールバ ックモードであるかを示す。 ・checkpoint id（チェックポイントＩＤ）の値およびreturn value（返値） は保持され復旧サブルーチン１５８の実行後に返される。 ・protected variables（保護変数）のリストは、プロセスがチェックポイン トに復旧された後であっても、復旧前の値を維持する。 注意すべき点であるが、checkpoint idの値が指定されない場合、プロセスは最 後のチェックポイントに復旧される。さらに、return valueが指定されない場合 、正の返値（例えば１）が用いられる。復旧サブルーチン１５８は、指示される チェックポイントに対応する揮発性および持続性の状態を復旧するように作用す る。後述のように、復旧サブルーチン１５８は、揮発性チェックポイントを復旧 し、復旧した揮発性チェックポイント以降に持続性状態になされた変更をもとに 戻すことによって、揮発性状態と持続性状態の間の整合性を保証する。 本発明の特徴によれば、復旧サブルーチン１５８がユーザアプリケーションプ ロセスによって呼び出されるときに、return valueおよびprotected variables 配列が指定される。一実施例では、復旧サブルーチン１５８が指示されたチェッ クポイントにロールバックするときには、protected variables配列によって指 示される変数の現在の値が、return value変数の現在の値とともに、保護される 。こうして、特定のチェックポイントへの復旧後、復旧の前に指定されたreturn valueが維持され、復旧後の実行のフローを制御するために利用することが可能 である。さらに、ユーザあるいはユーザアプリケーションプロセスがすべての変 数を特定のチェックポイントにロールバックすることを望まない場合、protecte d variablesの機構を利用して、復旧後にも現在の値を維持すべき変数を指定す ることができる。return valueが指定されない場合、デフォルト値として１が用 いられる。 図８Ａに示すように、呼び出されると、復旧サブルーチン１５８はステップ８ ００から開始される。その後、ステップ８１０で、checkpoint id引数で指示さ れる値に対応する持続性チェックポイントテーブル４００（図４）が読み出され る。ステップ８１５で、ユーザが、例えばコマンドライン入力によってあるいは 環境変数の設定によって、持続性チェックポイントテーブル４００にリストされ たシャドウファイルを復旧してはならないことを示すように、持続性チェックポ イントテーブル４００が変更されるべきことを指示したかどうかを判定するテス トが実行される。ステップ８１５でユーザが持続性チェックポイントテーブル４ ００を変更すべきであることを指示したと判定された場合、ステップ８２０で、 テーブル４００は、指示された変更に従って変更される。 持続性チェックポイントテーブル４００が変更された後、必要であれば、ステ ップ８２５で、テーブル４００にリストされた各ファイルに対応するシャドウフ ァイルを適当なチェックポイントデータから検索し、そのシャドウファイルを現 在のファイル上にコピーすることによって、持続性チェックポイントテーブル４ ００に従って持続性状態が復旧される。さらに、持続性チェックポイントテーブ ル４００にリストされた各ファイルの属性が、テーブル４００内のそれぞれのエ ントリに記録された値に従って変更される。 その後、ステップ８３０で、復旧サブルーチン１５８の現在の実行モードが、 障害後の回復モードであるか、それとも、ユーザが開始したロールバックモード であるか、および、protected variables配列の値が正しいかどうかを判定する テストが実行される。ステップ８３０で、復旧サブルーチン１５８の現在の実行 モードがロールバックモードであり、protected variables配列の値が正しいと 判定された場合、ステップ８３５で、チェックポイント実行されるデータセグメ ントが復旧される間にprotected variables配列によって指定された変数を保護 するために、これらの変数がデータセグメントから一時ファイルにコピーされる 。 その後、ステップ８４０で、checkpoint id引数によって識別される揮発性チ ェックポイントファイルが読み出される。ステップ８４５で、前のステップで取 得した揮発性チェックポイントファイルを用いて、オープンファイルテーブルを 含むデータセグメントが復旧される。 その後、ステップ８５０で、復旧サブルーチン１５８の現在の実行モードがロ ールバックモードであるかどうか、および、protected variables配列の値が正 しいかどうかを判定するテストが再び実行される。ステップ８５０で、復旧サブ ルーチン１５８の現在の実行モードがロールバックモードであり、protected va riables配列の値が正しいと判定された場合、ステップ８５５で、 protected variables配列によって指定された変数は、一時ファイル内の保護さ れた位置からデータセグメントにコピーされて戻される。このようにして、prot ected variables配列で指定される各変数は復旧前の値を維持する。 ステップ８６５で、ユーザが、例えばコマンドライン入力によってあるいは環 境変数の設定によって、オープンファイルテーブルを変更すべきであると指示し たかどうかを判定するテストが実行される。ステップ８６５で、ユーザが、オー プンファイルを変更すべきであると指示したと判定された場合、指示された変更 がステップ８７０で実行される。例えば、後で「長い初期化の迂回」と題する節 で説明する、本発明の特徴を含む１つのアプリケーションでは、復旧されるオー プンファイルテーブルは、以前に処理された入力ファイルの第１のセットをリス トする。処理すべき入力の後続の各セットごとに、入力ファイルの第１のセット を、現在の実行に適した入力ファイルのセットで置き換えるために、オープンフ ァイルテーブルを変更する。 オープンファイルテーブルが変更された後、必要であれば、ステップ８７５で 、オープンファイルテーブルに指示されるファイルディスクリプタが復旧される 。換言すれば、オープンファイルテーブル内の各エントリごとに、ファイルがオ ープンされ、ファイル名は指示されたファイルディスクリプタに関連づけられ、 ファイルの現在位置がオープンファイルテーブルエントリに記録された位置に調 整される。その後、ステップ８８０で、スタックスペースが割り当てられ、ステ ップ８８５で、スタックが、ステップ８４０で読み出された揮発性チェックポイ ントファイル内の情報に従って復旧される。 既に指摘したように、中央処理ユニット内での値の一時記憶のためのハードウ ェアレジスタ、スタックポインタおよびプログラムカウンタのような、ユーザア プリケーションプロセスの実行に関連するいくつかの揮発性情報は、オペレーテ ィングシステムカーネルによって管理される。これらのメモリ要素は通常はユー ザアプリケーションプロセスによってアクセス可能ではないが、オペレーティン グシステムは一般に、特定のユーザアプリケーションプロセスによって要求され るオペレーティングシステム情報を復旧することを可能にするルーチンを提供し ている。このタスクを実行するためにオペレーティングシステムによって提供さ れるルーチンは、ステップ８９０で、レジスタ、スタックポインタおよびプログ ラムカウンタの内容を復旧するために実行される。例えば、Unixオペレーティン グシステムは、これらのオペレーティングシステムデータ構造体を復旧するlong jmpコールを提供している。longjmpシステムコールの動作の詳細については、例 えば、W．R．Stevensの前掲書に記載されている。 既に指摘したように、プログラムカウンタの値が、チェックポイントが復旧さ れるときに記録された値に復旧されると、復旧サブルーチンの実行は、揮発性状 態チェックポイントサブルーチン１５４（図６）のステップ６２０にジャンプす る。こうして、復旧サブルーチン１５８は、揮発性状態チェックポイントサブル ーチン１５４から効果的に復帰することになる。さらに、復旧サブルーチン１５ ８は、指示されたreturn valueおよびprotected variables配列に指示された変 数を復旧前の値に維持したまま復帰する。 クリーンアップサブルーチン 既に指摘したように、チェックポイント復旧ライブラリ１５０は、ユーザアプ リケーションプロセスの実行後に実行されるクリーンアップサブルーチン１６０ を含む。図９に示すように、クリーンアップサブルーチン１６０は、ユーザアプ リケーションプロセスが終了したときにステップ９００から開始される。ステッ プ９１０で、ユーザアプリケーションプロセスの現在の実行モードが透過モード であるかどうかを判定するテストが実行される。ステップ９１０で、現在の実行 モードが透過モードであると判定された場合、ステップ９３０で、実行前チェッ クポイントサブルーチン１５２によって生成されたクロックデーモンプロセスが 削除(kill)される。 その後、ステップ９５０で、ユーザアプリケーションプロセスに関連するチェ ックポイントファイルを維持すべきかどうかを判定するテストが実行される。ス テップ９５０で、チェックポイントファイルを保持すべきでないと判定された場 合、ステップ９７０で、ユーザアプリケーションプロセスに関連するチェックポ イントファイルは削除される。ステップ９８０で、クリーンアップサブルーチン １６０は実行を終了する。 チェックポイント復旧アプリケーション ソフトウェアの途中終了の迂回 ユーザアプリケーションプロセスは、実行の継続に必要なリソースを割り当て ることができないために途中で終了することがある。ソフトウェア障害とは異な り、プロセスがリソース不足状態あるいは例外状態により途中終了するときは、 プロセスは依然として、プログラムが終了する直前の時点での制御下にある。こ こで、例外状態とは、ユーザアプリケーションプロセスによって規定される正常 な実行フロー以外の実行であると定義される。一般に、プロセスが必要なリソー ス（例えば動的メモリ）を割り当てることができないときには、プロセスは、「 リソース割当て不能」状態を示すエラーメッセージを印字し、プログラムは途中 終了する。このようなソフトウェア途中終了は、多くの有用な処理が浪費される ため、特に長時間動作したアプリケーションでは、もちろん好ましくない。一般 に、プロセスは、最初から、あるいは、おそらくは、透過チェックポイントモー ドで指定された間隔で設定された最後のチェックポイントから、再開始しなけれ ばならない。 しかし、本発明によるチェックポイント復旧システム１０によれば、プロセス が終了する時点の直前で、ソースコードにチェックポイント関数コールを挿入す ることが可能である。このようにして、プロセス状態は、後で、途中終了に対応 する位置の直前の点に復旧することができる。さらに、本発明によれば、ユーザ アプリケーションプロセスが最後のチェックポイントに復旧した後の実行制御機 能を利用することによって、復旧サブルーチン１５８の返値は、必要であれば、 現在の実行が特殊な回復処理を開始する回復モードであることを示すことが可能 である。 図１０に、例えば動的メモリを割り当てることの障害によって引き起こされた ソフトウェア途中終了を迂回するために利用可能な本発明の機能を含むソースコ ードのセグメントを示す。第１０１５〜１０５０行に示されるコード列は、第１ ０１０行でプロセスが動的メモリを割り当てることができない限り実行される。 第１０１０行で実行されるmalloc関数コールは、通常Ｃプログラミング言語の関 数ライブラリにあるメモリ割当て関数であり、要求されたサイズのメモリブロッ クを割り当て、宣言されたポインタptrに、割り当てたメモリの開始アドレスの 値を返す。 例えば他のプロセスが残りのスワップスペースを使い尽くしてしまった場合の ように、プロセスが、所望の動的メモリを割り当てることができないとき、プロ セスは、変数MAX RETRY COUNTによって指定される再試行の最大回数を超えるま で、割当てを再試行する。注意すべき点であるが、再試行の規定の最大回数は０ に設定することも可能である。MAX RETRY COUNTを超過すると、ステップ１０２ ５でchkpnt()（チェックポイント）が実行された後、ステップ１０３５でプロセ スは終了する。 既に指摘したように、プロセスが復旧されるとき、復旧サブルーチン１５８（ 図８Ａおよび図８Ｂ）が呼び出され、揮発性状態および持続性状態を最後のチェ ックポイント（換言すれば、終了の直前に実行されたチェックポイント）に復旧 する。注意すべき点であるが、復旧サブルーチン１５８の実行時にプログラムカ ウンタの値が復旧されると、実行は、復旧サブルーチン１５８から揮発性状態チ ェックポイントサブルーチン１５４にジャンプする。復旧サブルーチン１５８は 揮発性状態チェックポイントサブルーチン１５４へ、回復モードを示す正の返値 とともに復帰する。このように、図１０の実施例では、正の返値によって、プロ グラム制御は、回復コードを実行する第１０４０行に進む。この例では、回復コ ードは、retry countを０にリセットして、所望の動的メモリの割当てを再試行 することからなる。しかし、当業者には明らかなように、他の回復コードを実行 することも可能である。 注意すべき点であるが、リソース不足状態は過渡的である可能性があり、プロ セスが環境の変化により復旧されるときには、同じプロセスが別の条件下で実行 されて、リソース不足状態が迂回されることがある。しかし、リソース不足状態 が持続性の場合、例えば、現在のマシンが単に、ユーザアプリケーションプロセ スの要求を満たすには与えられたリソースでは十分ではない場合、途中終了を迂 回するには、より大きい容量を有する別の処理ノードへのプロセスマイグレーシ ョンが必要なこともある。本発明の技術は、プロセスをあるワークステーション 上で開始した後で、リソース不足状態に遭遇した後にのみ、より大きい容量の所 望のリソースを有する別のマシンへプロセスを移動することが可能である。 長い初期化の迂回 多くのソフトウェアプログラムは、しばしば時間のかかる初期化ルーチンを含 む。さらに、同じプログラムが相異なる入力データのセットに対して再実行され る場合、各実行において、時間のかかる初期化ルーチンを繰り返す必要があるこ とが多い。しかし、多くの場合、処理ルーチンの多くの実行が、同じ初期化され た状態を、相異なる入力データで再使用することが可能である。この場合、初期 化状態を保存し、対応するソフトウェアプログラムの将来の実行により異なる入 力データのセットで使用するために復旧することにより、ソフトウェアプログラ ムの効率は大幅に改善される。 本発明の特徴によれば、図１１に示すように、与えられたソフトウェアプログ ラムに関連する初期化状態をチェックポイント実行し、後で異なる入力データに 対して実行するために復旧することができる。それぞれの異なる実行ごとに置換 される入力ファイルはチェックポイントから除外して、新しい入力ファイルをそ れぞれの新しい実行ごとに処理することが可能である。 図１１に示すように、長い初期化を迂回する初期化迂回ルーチン１１００はス テップ１１０５から開始される。まず、ステップ１１１０で、初期化迂回ルーチ ン１１００は、例えばコマンドライン、または、入力ファイル名のセットを含む データファイルから、第１の入力パラメータのセットを読み出す。その後、ステ ップ１１１５で、与えられたユーザアプリケーションプロセスに適する初期化ル ーチンが実行される。ステップ１１２０で、チェックポイントから除外すべきフ ァイル、換言すれば、後のそれぞれの実行で置換すべきファイルが指定される。 その後、ステップ１１３０で、揮発性状態と、前のステップで指定されなかっ た持続性状態の部分とがチェックポイント実行される。チェックポイント関数か ら制御が戻ると、ステップ１１３５で、チェックポイント関数からの返値が０よ り大きい（回復モードを示す）かどうかを判定するテストが実行される。ステッ プ１１３５で、返値が０より大きいと判定された場合、これは、初期化迂回ルー チン１１００の最初の実行であり、ステップ１１５０で、初期化状態と、第１の 入力ファイルおよびパラメータのセットとに従って第１のデータのセットが処理 される。 ステップ１１６０で、さらに処理すべき入力ファイルおよびパラメータのセッ トがあるかどうかを判定するテストが実行される。ステップ１１６０で、さらに 処理すべき入力ファイルおよびパラメータのセットがあると判定された場合、プ ログラム制御はステップ１１７０に進み、復旧サブルーチン１５８が正の返値で 実行される。復旧サブルーチン１５８は、ステップ１１３０で設定されたチェッ クポイントにプロセス状態を復旧する。注意すべき点であるが、ステップ１１３ ０でチェックポイント実行されたオープンファイルテーブルは、第１の入力のセ ットに関連する各入力ファイルをリストしている。しかし、後続の実行では、オ ープンファイルテーブルにリストされた同じファイルディスクリプタのセットが 、それぞれの実行に関連する入力ファイルに関連づけられる。こうして、既に指 摘したように、復旧サブルーチン１５８は、ユーザがオープンファイルテーブル を変更しその変更を反映することを可能にする機構を有している。 注意すべき点であるが、ステップ１１７０で、プロセス状態が最後のチェック ポイントに復旧されると、プログラムカウンタも、そのチェックポイントに対応 する値に復旧され、それにより、プログラム制御は、ステップ１１３０で実行さ れるチェックポイント関数にジャンプする。ステップ１１３０で、プログラム制 御が、上記のように、正の返値でチェックポイントから復帰すると、ステップ１ １３５で実行されるテストの結果、プログラム制御はステップ１１４０に進む。 こうして、入力ファイル名のリストを含む次の入力パラメータのセットは、初期 化ルーチンの再実行を必要とせずに、上記のようなステップ１１５０での実行の ために、ステップ１１４０で読み出される。 しかし、ステップ１１６０で、さらに処理すべき入力ファイルおよびパラメー タのセットがないと判定されると、ステップ１１８０で、初期化迂回ルーチン１ １００の実行は終了する。 メモリ再設定 時間が経つと、好ましくないメモリ状態が生じ、ソフトウェアプロセスの効率 的実行を妨げるとともに、システム性能を徐々に劣化して、最終的にソフトウェ ア障害を引き起こすことがある。例えば、ソフトウェアプログラムは、多くの成 功した市販品を含めて、ある実行パスに対して正しいメモリ解放を行わない場合 に、メモリリークが起こることがある。割り当てられたメモリスペースが、メモ リリークの結果、どのポインタからも参照されていないために、アクセスするこ とができなくなる。一般に、メモリリークは、割り当てられたメモリの第１ブロ ックを指すポインタが、第１ブロックを解放せずに、割当てメモリの第２ブロッ クを指すように再割当てされるときに起こる。メモリリークの結果、全体性能の 累積的な劣化が生じ、理論的には、時間が経つと、プロセスはメモリを使い果た す。 さらに、いくつかの市販のメモリマネージャによって提供されているメモリキ ャッシュおよび弱いメモリ再使用機構は、マシンが需要を満たす十分な物理的容 量を有している場合でも、メモリ不足状態を生じることがある。例えば、ユーザ アプリケーションプロセスが繰り返し小さいメモリブロック（例えば、３２バイ ト以下のブロック）を要求すると、メモリマネージャは、それらの小さいブロッ クを、解放後、別のリストで、あるいは、メモリキャッシュで、小さいメモリブ ロックに対する将来の予想される要求に対して管理する。こうして、これらの小 さいブロックは、より大きいメモリ要求には利用できなくなる。小さいブロック に対する十分多くの要求があった場合、より大きいメモリ要求は、たとえ十分な 物理的容量がある場合でも、拒否されることになる。弱いメモリ再使用機構とは 、例えば３０メガバイトのメモリを有するマシンが、例えば１５メガバイトのメ モリをまず割り当ててから解放するような場合に関するものである。その後、ユ ーザアプリケーションプロセスが１６メガバイトの割当てを要求すると、メモリ 不足状態に遭遇する。その理由は、解放された１５メガバイトに１メガバイトを 追加するのではなく、このメモリマネージャは解放された１５メガバイトを予約 し、１６メガバイトを割り当てようとする。この場合、実際には十分な物理的容 量があるのに、マシンのメモリ限界を超えるようにみえる。 本発明の特徴によれば、図１２に示すメモリ再設定サブルーチン１２００は、 プロセスのメモリを、揮発性状態の一部としての「クリーン」状態においてチェ ックポイント実行し、ソフトウェア障害を防ぐために、ときどきプロセスをその クリーン状態にロールバックする。ステップ１２１０で、メモリ再設定サブルー チン１２００は、ループインデックスｉを０にセットする。その後、ステップ１ ２１５で、適当な初期化ルーチンを実行する。注意すべき点であるが、初期化さ れた状態は、チェックポイント実行される揮発性状態の一部である。 ステップ１２２０で、すべてのユーザファイルをチェックポイントから除外す るように指定する。こうして、チェックポイントが設定され、後で復旧されると きに、クリーンなメモリ状態のみが復旧されることになる。さらに、すべての持 続性状態、換言すれば、すべての入力ファイルをチェックポイントから除外する ことによって、ユーザファイルの現在の内容が復旧後に維持される。ステップ１ ２３０で、揮発性状態チェックポイントサブルーチン１５４（図６）を実行する ことによって、揮発性状態がチェックポイント実行される。その後、ステップ１ ２４０で、初期化状態およびループインデックスｉの現在の値に基づいて、所望 の処理タスクが実行される。ステップ１２４５で、前のステップで実行された処 理タスクの結果が、周知のようにして、出力バッファに書き込まれる。出力バッ ファの内容は、バッファがフルになるまで、あるいは、flushシステムコールが 実行されるまでは、ディスクのような目的とする宛先に送られない。 ステップ１２５０で、さらに処理すべきループインデックスｉの値があるかど うかを判定するテストが実行される。ステップ１２５０で、さらに処理すべきル ープインデックスｉの値があると判定された場合、ステップ１２５５で、ループ インデックスがインクリメントされる。その後、ステップ１２７０で、ループイ ンデックスｉの現在の値が、指定された再設定周期の倍数であるかどうかを判定 するテストが実行される。換言すれば、１５回の実行ごとにクリーンなメモリ状 態を復旧すべきである場合、ループインデックスの現在の値が１５の倍数である かどうかを判定するテストが実行される。ステップ１２７０で、ループインデッ クスｉの現在の値が、指定された再設定周期の倍数でないと判定された場合、プ ログラム制御はステップ１２４０に戻り、上記のようにして処理を継続する。 しかし、ステップ１２７０で、ループインデックスｉの現在の値が、指定され た再設定周期の倍数であると判定された場合、ステップ１２７５で、出力バッフ ァがフラッシュされた後、メモリはクリーン状態に復旧される。その後、ステッ プ１２８０で、返値をループインデックスｉの現在の値に等しくして、復旧サブ ルーチン１５８を実行することによって、揮発性状態にロールバックする。チェ ックポイントはユーザファイルを含まないため、クリーンなメモリ状態のみが復 旧される。既に指摘したように、復旧サブルーチン１５８は、ステップ１２３０ で、チェックポイント関数から返値とともに復帰する。そこで、この返値（ルー プインデックスに等しい）を保持することによって、ユーザアプリケーションプ ロセスの正しい進行が保証される。復旧サブルーチン１５８がチェックポイント 関数から復帰すると、プログラム制御はステップ１２４０に進み、上記の通り継 続する。 ステップ１２５０で、さらに処理すべきループインデックスｉの値がないと判 定された場合、プログラム制御はステップ１２９０に進み、メモリ再設定サブル ーチン１２００の実行は終了する。 理解されるように、ここで説明した実施例およびその変形例は本発明の単なる 例示であり、当業者であれば、本発明の技術的範囲を離れることなく、さまざま な変形例を実施することが可能である。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 フアン、イェンヌン アメリカ合衆国 08807 ニュージャージ ー、サマセット カウンティ、ブリッジウ ォーター、リンバーガー ドライヴ 33 (72)発明者 キンタラ、チャンドラ アメリカ合衆国 07059 ニュージャージ ー、サマセット カウンティ、ウォーレ ン、マウンテン アヴェニュー 29 (72)発明者 ヴォー、キエム−フォン アメリカ合衆国 07922 ニュージャージ ー、ユニオン カウンティ、バークレー ハイツ、スウェンソン サークル 80 (72)発明者 ワン、イー−ミン アメリカ合衆国 07922 ニュージャージ ー、ユニオン カウンティ、バークレー ハイツ、パインウッド クレセント 10

Claims (1)

1. 【特許請求の範囲】 １．コンピュータシステム上で実行されるユーザアプリケーションプロセスを チェックポイント実行し復旧する方法において、 前記ユーザアプリケーションプロセスは、揮発性状態と、ユーザファイルから なる持続性状態とを含むプロセス状態を有し、 前記方法は、 （ａ）チェックポイント位置で揮発性状態をチェックポイント実行するステッ プと、 （ｂ）持続性状態をモニタして、持続性状態を変更することになるチェックポ イント位置の後のファイル操作を検出するステップと、 （ｃ）前記ステップｂが、持続性状態の変更が実行されることを検出した場合 、持続性状態のうち少なくとも変更されることになる部分をチェックポイント実 行するステップと、 （ｄ）プロセス状態を前記チェックポイント位置に復旧することにより、チェ ックポイント位置以降の持続性状態に対する変更をもとに戻すステップと、 （ｅ）チェックポイント位置からユーザアプリケーションプロセスの実行を再 開するステップとからなることを特徴とする、ユーザアプリケーションプロセス をチェックポイント実行し復旧する方法。 ２．揮発性状態のチェックポイント実行は、自動的に、定期的に呼び出される ことを特徴とする請求項１の方法。 ３．揮発性状態のチェックポイント実行は、前記ユーザアプリケーションプロ セス中の関数コールによって呼び出されることを特徴とする請求項１の方法。 ４．持続性状態のチェックポイント実行は、持続性状態を変更することになる ファイル操作を検出する割込みルーチンによって呼び出されることを特徴とする 請求項１の方法。 ５．前記方法は、前記チェックポイントから除外すべきユーザファイルを指定 するステップをさらに有し、 持続性状態のうち少なくとも変更されることになる部分のチェックポイント実 行は、指定された除外されるファイルのチェックポイントを含まないことを特徴 とする請求項１の方法。 ６．持続性状態のチェックポイント実行は、揮発性状態と持続性状態の間の不 整合が生じるまで実行されないことを特徴とする請求項１の方法。 ７．持続性状態のうちチェックポイント実行される部分は中間状態であり、 前記ステップｅは、前記中間状態以降の入力を処理することを特徴とする請求 項１の方法。 ８．コンピュータシステム上で実行されるユーザアプリケーションプロセスを チェックポイント実行し復旧する方法において、 前記ユーザアプリケーションプロセスは、揮発性状態と、ユーザファイルから なる持続性状態とを含むプロセス状態を有し、 前記方法は、 （ａ）チェックポイント位置で揮発性状態をチェックポイント実行するステッ プと、 （ｂ）チェックポイント位置の後に実行される各変更ごとに、変更される少な くとも１つのユーザファイルの少なくとも一部をチェックポイント実行するステ ップと、 （ｃ）プロセス状態を前記チェックポイント位置に復旧することにより、チェ ックポイント位置以降の前記ユーザファイルに対する変更をもとに戻すステップ と、 （ｄ）チェックポイント位置からユーザアプリケーションプロセスの実行を再 開するステップとからなることを特徴とする、ユーザアプリケーションプロセス をチェックポイント実行し復旧する方法。 ９．揮発性状態のチェックポイント実行は、自動的に、定期的に呼び出される ことを特徴とする請求項８の方法。 １０．揮発性状態のチェックポイント実行は、前記ユーザアプリケーションプ ロセス中の命令によって呼び出されることを特徴とする請求項８の方法。 １１．変更される少なくとも１つのユーザファイルの少なくとも一部のチェッ クポイント実行は、該ユーザファイルのうちの１つを変更するファイル操作を検 出した割込みルーチンによって呼び出されることを特徴とする請求項８の方法。 １２．前記方法は、前記チェックポイントから除外すべきユーザファイルを指 定するステップをさらに有し、 変更される少なくとも１つのユーザファイルの少なくとも一部のチェックポイ ント実行は、指定された除外されるファイルのチェックポイントを含まないこと を特徴とする請求項８の方法。 １３．変更される少なくとも１つのユーザファイルの少なくとも一部のチェッ クポイント実行は、揮発性状態とユーザファイルの間の不整合が生じるまで実行 されないことを特徴とする請求項８の方法。 １４．ユーザファイルのうちチェックポイント実行される部分は中間状態であ り、 前記ステップｄは、前記中間状態以降の入力を処理することを特徴とする請求 項８の方法。 １５．ユーザアプリケーションプロセスに伴う初期化状態を復旧する方法にお いて、 ユーザアプリケーションプロセスは、プロセス状態を有し、少なくとも２セッ トの入力ファイルに対する初期化状態に基づいて処理タスクを実行し、 前記方法は、 （ａ）ユーザアプリケーションプロセスを初期化して初期化状態を形成するス テップと、 （ｂ）プロセス状態のチェックポイントから除外すべき入力ファイルを指定す るステップと、 （ｃ）プロセス状態のうち除外されなかった部分をチェックポイント実行する ステップと、 （ｄ）前記初期化状態および現在の入力ファイルのセットに基づいて処理タス クを実行するステップと、 （ｅ）チェックポイント実行された状態にユーザアプリケーションプロセスを 復旧し、復旧モードを示すあらかじめ定義された返値を生成するステップと、 （ｆ）前記ステップｅが前記あらかじめ定義された返値を返した場合、新たな 入力ファイルのセットを取得して、除外された入力ファイルを置き換えるステッ プと、 （ｇ）処理すべき入力ファイルのセットごとに、ステップｄ〜ｆを繰り返すス テップとからなることを特徴とする、ユーザアプリケーションプロセスに伴う初 期化状態を復旧する方法。 １６．前記プロセス状態は揮発性状態および持続性状態を含み、 前記ステップｃは、 揮発性状態をチェックポイント実行するステップと、 持続性状態をモニタして、持続性状態を変更することになるチェックポイント 位置の後のファイル操作を検出するモニタステップと、 前記モニタステップが、持続性状態の変更が実行されることを検出した場合、 持続性状態のうち少なくとも変更されることになる部分をチェックポイント実行 するステップとからなることを特徴とする請求項１５の方法。