JP5519909B2 - アプリケーション・プロセスにおいて内部イベントをリプレイするための非侵入的方法およびこの方法を実装するシステム - Google Patents

Description

本発明は、ソフトウェア・アプリケーションに属するプロセス内で、ログ・ファイルからイベントをリプレイするための方法に関する。この方法は、特に、マルチコンピュータ環境で実行されるアプリケーションに属するプロセス内の内部イベントを対象とする。

本発明の分野は、協働するいくつかのコンピュータによって形成されるコンピュータのネットワークまたはクラスタの分野である。これらのクラスタは、１つまたは複数のサービスをユーザに提供するソフトウェア・アプリケーションを実行するために使用される。こうしたアプリケーションは、単一または複数のプロセスとすることが可能であり、単一のコンピュータ上で実行されるか、あるいは、たとえば、ＭＰＩ（「Ｍｅｓｓａｇｅ Ｐａｓｓｉｎｇ Ｉｎｔｅｒｆａｃｅ（メッセージ受け渡しインターフェース）」）タイプまたは「Ｓｈａｒｅｄ Ｍｅｍｏｒｙ（共有メモリ）」タイプの分散アプリケーションなどのように、いくつかのコンピュータにわたって分散されることが可能である。

特に本発明は、ミドルウェア・タイプのアプリケーションに統合することが可能な、たとえば中間アプリケーションと呼ばれる他のソフトウェア・アプリケーションによって、クラスタ内の、マスタまたは１次と呼ばれるようなアプリケーションの機能を管理することができる。この機能管理は、とりわけ、１次ノード内での、または２次と呼ばれる他のノードと連携した、このアプリケーションのすべてまたは一部の、複製、再配布、確実化、あるいは追跡またはデバッグのオペレーションを含むことができる。

アプリケーションの機能を、たとえばその動作を強制またはリダイレクトすることによって管理するために、あるイベントの発生をシミュレートすることになるデータの注入によって、その環境の特定の開発をシミュレートすることが知られている。こうした実施は、ある状況に対するこのアプリケーションの反応を、たとえばそのデバッグに関してテストする際に有用な場合がある。第１のアプリケーション内で以前に発生したイベントを格納する１つまたは複数のロギング・ファイルがある場合、新しいアプリケーションにこれらと同じイベントを含められることが有用な場合がある。こうしたリプレイは、たとえば、この新しいアプリケーションが以前のものに代わってどのように機能するかを発見するために、その動作をテストするのに役立つ可能性がある。この新しいアプリケーションが、これらの被ロギング・イベントの発生後に開始または活動化したものである場合、こうしたリプレイによってこの新しいアプリケーションを、これらの同じイベントをすでに考慮に入れた状態にすることができる可能性がある。加えて、この新しいアプリケーションが、以前のアプリケーションの所与の状態に対応するリプレイ時点の状態を使用してあらかじめ復元された場合、リプレイ時点後に以前のアプリケーションにロギングされたイベントのリプレイによって、新しいアプリケーションを、これらのイベント発生後の以前のアプリケーションの状態に対応する状態に復元することができる。

アプリケーションの機能中に発生するイベントの中で、このアプリケーションの外からのデータ、すなわち、特に制御の対象でないハードウェアまたはソフトウェア要素からのデータによって、アプリケーション内で開始されたイベントを、外部イベントと呼ぶことができる。これは、たとえばキーボード上でのアクションから発生する信号、または通信ネットワークを介して着信するメッセージとすることができる。

アプリケーション内またはそのプロセスのうちの１つで、内部イベントのシミュレーションまたはリプレイを実施するために、それらを発生させるアクションまたはメッセージを実際に再作成することが知られているが、この方法は、大量のリソースを必要とし、依然として比較的単純な状況に限定されている。これらのイベントの発生後に示されることになる値を得るために、これらイベントの結果を管理および格納するためのメモリの値を修正することも知られている。しかしながらこの方法では、このアプリケーションのプログラミングにおいて複雑さが増加し、これによってコストおよびエラーのリスクが発生する。

加えて、アプリケーションが初めからこうした記録を生成するように設計されていない場合、こうした機能を後で追加することは困難かつコストがかかり、これによってかなりのエラー・リスクとなる。

いくつかの方法は、外部からアプリケーションの機能を強制できるようにプログラムを調整またはデバッグすることによっても使用される。しかしながらこれらの方法は、通常、たとえばシステム内のカーネルを修正または追加することによる、アプリケーションを実行するコンピュータ・システムにおける内部介入を必要とする。さらにこれらのシステム変更は、特定のシステム技術を必要とし、いくつかのネットワーク・コンピュータ間に、エラーおよび不安定性の源となる可能性のある異機種混合をもたらすことになる。たいていの場合、これらの欠点により、記録およびリプレイ原理の使用は、主に調整タスクまたは分離された構成に大いに限定され、実際の開発で使用される広範囲かつストレスのかかる構成には受け入れられない。

さらに、リソースがいくつかのプロセス間で非同期的に共用される場合、１つまたは複数のこれらプロセスのリプレイには、こうしたリソースの共用性に固有の、不確実性または非決定性の要素が含まれる可能性がある。

リプレイ時にプロセスがこうした共用リソースにアクセスしようとすると、このオペレーションの結果は実際に、たとえば、同様にこのリソースにアクセスしている他のプロセスの進行状態などの、予期せぬ要因による影響を受ける場合がある。加えて、２つのプロセスが同時に同じリソースにアクセスしようとした場合、この２つのプロセスを一緒にリプレイするという事実は、ロギング時またはいくつかの異なるリプレイ時に得られる結果と同一の結果を保証するとは限らない。こうした変動性は、たとえば、同時プロセス間の実行速度の差異から、あるいは、ソフトウェア・エージェントのリプレイまたは機能管理によって直接管理することのできない、実行のハードウェア条件における偶然要因または差異から、生じる可能性がある。

この状況は、たとえば、Michiel RONSSE等による出版物「Debuggingshared memory parallel programs using record/replay」Elsevier Science, Ghent 2002 (FGCS 19 (2003)679-687)において、「競合条件（racecondition）」の名前で説明される。

そこには、管理しようとするアプリケーションに応じて特定のプログラミング・タスクを構成し、プログラミングおよび処理能力の両方においてかなりの作業負荷を示す、共用変数のコンテンツの監視を維持することからなる、既知のソリューションが記載されている。この作業負荷によって、このソリューションの実施は費用のかかる柔軟性のないものとなり、その性能はしばしば開発条件の下で使用するには低すぎるものとなる。

同様の出版物において、著者は、非決定論的結果を生成するリスクのある、こうした同時アクセス状況の発生を具体的に検証するために、当該プロセス内で侵入的な（intrusive）方法を使用することからなるソリューションを提案する。こうした方法は、たとえば、リプレイされるアプリケーションの機能内に同期セマフォを追加することを含む。しかしながら、リプレイまたは管理されるアプリケーションにおけるこうした修正は、複雑で、柔軟性がなく、費用がかかるものであり、エラーのリスクを生じさせる。特に、マスタ・アプリケーションの実行中には、ロギング・オペレーションはオペレーション・ノードに対する作業負荷を示し、中間アプリケーションのアクションによる性能低下の原因となる可能性がある。
フランス特許出願第２８２０８２１号 Michiel RONSSE等による「Debuggingshared memory parallel programs using record/replay」Elsevier Science, Ghent 2002 (FGCS 19 (2003)679-687)

本発明の一目的は、アプリケーションまたはそのプロセスの１つにおいて、このアプリケーションおよびこれを実行するシステムに対してできる限り最もトランスペアレントなように、内部イベントのシミュレーションまたはリプレイを可能にする方法を提案することである。

このため、本発明は、ターゲット・プロセスによって、ロギング・データによって表される、被ロギング・オペレーションと呼ばれる少なくとも１つのオペレーションのリプレイを実施することを特徴とする、コンピュータ上でのターゲット・プロセスと呼ばれる少なくとも１つのアプリケーション・プロセスの実行のための方法を提案する。

この方法は、
・被ロギング・オペレーションに対応する被リプレイ・オペレーションと呼ばれるオペレーションを開始し、当該被リプレイ・オペレーションによって得られる結果を表す少なくとも１つのリプレイ結果データをこのターゲット・プロセスに戻す、リプレイ命令と呼ばれる少なくとも１つのプログラム命令を、このターゲット・プロセスによって実行するステップと、
・ターゲット・プロセスによってリプレイ結果データの代わりにロギング・データから抽出された強制データを考慮に入れること、および、被リプレイ・オペレーションに対して被ロギング結果と呼ばれる所与の結果を表すことを含む、強制と呼ばれるプロシージャを、再始動プロセス外部のソフトウェア・エージェントによって実行するステップと、
を含む。

ターゲット・プロセスの外側から制御される強制プロシージャを使用することにより、リプレイの取得が可能になる一方で、この強制を実行するエージェント・プロセスによる機能侵入（intrusion）を制限する。

有利なことには、ターゲット・プロセスは、少なくとも１つの実行可能ファイル内の少なくとも１つのプログラム実行ポインタを移動させることによって、リプレイ命令を自発的に実行する。

とりわけ、本発明に従った方法は、リプレイ命令またはそれが開始する被リプレイ・オペレーションのインターセプト・ステップをさらに有する。

したがって、オリジナルの実行可能ファイルからの自力での進行をアプリケーション・プロセスに任せることが可能である。本発明は、機能への侵入ならびに機能構成への侵入を大幅に削減することが可能である。加えて、本発明は、このリプレイを管理する強制エージェントまたはアプリケーション内で、再始動プロセス実行ポインタの進行メカニズムを体系的に提供する必要がないため、こうしたリプレイ機能を非侵入的に実施することができる。

複数のオペレーションを含むシーケンスをリプレイするために、本発明に従った方法は、一連の被ロギング・オペレーションのリプレイを実施することによって、少なくとも１つのターゲット・プロセスを実行するための、一連の被ロギング・オペレーションを表す、ログと呼ばれるロギング・データの順序付けセットを使用する。

有利な特徴によれば、インターセプト・ステップは、被リプレイ・オペレーションに対応する被ロギング結果を表すロギング・データを含むかどうかを検証するための、ログ・データ・テスト・フェーズをさらに含み、強制ステップは、このログがこうした被ロギング結果を含む場合にのみ実施される。

したがって本発明は、不必要なオペレーションに伴う作業負荷を削減することができる。

特に、被リプレイ・オペレーションが、決定論的オペレーションおよび非決定論的オペレーションの両方を含む場合、有利なことに、強制フェーズは当該決定論的オペレーションのうちの少なくとも１つに適用されない可能性がある。

実際、コンピュータまたはそのソフトウェア・システムあるいはその両方の内部の多数のオペレーションは、決定論的特徴を備えており、すなわち、プロセスの状態およびそれが使用するリソースにのみ依存する結果を与える。同じ状態から、このプロセスのすべてのオペレーション、あるいは、所与のタイプであるかまたはある特定のリソースにのみ影響を与えるすべてのオペレーションを、リプレイすることによって、リプレイされたシーケンスは、必然的に再始動プロセスを被ロギング・プロセスと同じ状態にする。自発的な再始動プロセスが、決定論的オペレーションを実行する新しい命令を実行する場合、得られる結果は、必然的に、被ロギング・プロセスに対応するオペレーションの結果と同一になる。したがって、求める目的の観点から決定論的であると識別されるオペレーションをロギングおよびリプレイしないことによって、ロギングまたはリプレイあるいはその両方によってもたらされる作業負荷を制限することが可能である。

このログは、たとえば、１つまたは複数の所与のプロセスに従って編成可能であり、要件に応じて選択可能な１つまたは複数の観点に従って、リプレイされるすべてのオペレーションのグローバルな視野を構成することができる。

本発明に従った方法は、被ロギング・プロセスのリプレイを実施するターゲット・プロセスを実行するための、被ロギング・プロセスと呼ばれるプロセスの実行時に実行される、少なくとも１つの所与のタイプのオペレーション・セットを表すログを使用することができる。

特に、この方法は、被ロギング・プロセスの実行の少なくとも一部で発生した、すべての被決定論的内部イベントのリプレイを、少なくとも１つのターゲット・プロセスによって実施することができる。

その実行の特定部分ですべての内部イベントを含む被ロギング・シーケンスのリプレイを実行するためにこの方法を使用することによって、および、同一状態から開始することによって、この方法は、ターゲット・プロセスおよび関係するリソースに関して、被ロギング・プロセスの状態と同一の状態を取得することが可能となる。

有利なことには、ログをテストするステップは、ログが被ロギング結果を表すデータを含む、被ロギング・プロセスの実行でまだリプレイされていない第１のオペレーションのポジションと比較した、ターゲット・プロセスの実行でリプレイされたオペレーションのポジションに関する。

したがって再始動プロセス・オペレーションは、リプレイ時に強制フェーズが必要であるか否かを特定する、シーケンスまたはポジション番号を増分することによって、ログに関してより単純に監視することができる。

別の方法として、またはプロセスの一部を形成するオペレーションをグループ化したログの使用と組み合わせて、本発明は、被ロギング・リソースと呼ばれる共有リソースに適用される少なくとも１つの所与のタイプのオペレーション・セットを表すログを使用することによって、リプレイ・プロセスを実施することも提案する。このログから、この方法は、再始動プロセスと呼ばれる少なくとも１つのターゲット・プロセスによって、当該被ロギング・オペレーションのリプレイを実行するために使用され、この再始動プロセスは、ターゲット・リソースと呼ばれるリソースにアクセスし、被ロギング・リソースに対応する。

特に、本発明に従った方法は、ターゲット・プロセスによってリプレイされ、共有タイプの少なくとも１つのターゲット・リソースに関するプリエンプティブ（pre-emptive）属性要求を含む、少なくとも１つのオペレーションに適用することができる。次に強制ステップは、
・このリソースに関してまだリプレイされていない次の被ロギング・オペレーションの被ロギング結果が、ターゲット・プロセスに対する属性に対応するかまたは対応しないかを検証する、テスト・フェーズ・ステップと、
・当該テストの結果が否定である場合は必ず、ターゲット・プロセスが保留され、肯定結果が得られるまで当該テストが反復されるステップと、
を含むことができる。

したがって本発明は、いくつかのプロセス間で共用されるリソースに適用されるリプレイ機能の実施を簡略化する一方で、ロギング中に通知されたこれら異なるプロセスのアクセス順序のリプレイを保持することができる。この機能は、たとえば、セマフォまたは共有メモリ・ゾーンの属性などの、プリエンプティブタイプのオペレーションに適用される。

本発明の特徴によれば、リプレイ命令は、実行可能ファイル外部のオリジナルと呼ばれるルーチンへの呼び出しを含み、インターセプト・ステップは、当該オリジナル・ルーチンの代わりに被修正と呼ばれるルーチンへの呼び出しを含み、この被修正ルーチンが強制オペレーションを実行または開始する。

たとえば、システムによってロードされた動的ライブラリを呼び出す命令の場合、本発明は、アプリケーションの実行可能ファイルが優先として呼び出す、追加のモジュールまたはライブラリをシステムにロードすることによって、インターセプトを実行することを提案する。フランス特許出願第２８２０８２１号に開示されるように、その後、このモジュールは機能管理エージェントまたはアプリケーションによって動的にロードすることが可能であり、オリジナル・ルーチンのコンテンツに加えて、異なるタスクを実行する被修正ルーチンを含むことになる。

有利なことには、被修正ルーチンは、ソフトウェア・システム内で実行される少なくとも１つの命令を含み、ターゲット・プロセス・コンピュータのコンピュータのユーザ・メモリ・スペース内で実行され、ターゲット・プロセスによるリプレイの実施を管理する、リプレイと呼ばれる少なくとも１つのソフトウェア・エージェントへの呼び出しを含む。

たとえば、機能管理アプリケーション内でアプリケーション・プロセスとして、ユーザ・メモリ・スペース内で機能する１つまたは複数のリプレイ・エージェントを使用することにより、システム・スペース内での修正または介入を制限し、それらをターゲット・アプリケーションに関してトランスペアレントに実行しながら、柔軟かつモジュール式にこれらの機能を実施することができる。

１機能によれば、被修正ルーチンは、これを呼び出した命令が、リプレイのコンテキストで実行されるか否かを検証するテスト命令を含み、このテストはリプレイ・エージェントへの呼び出しに影響を与える。

変形形態では、被修正ルーチンは、これを呼び出した命令が、ロギングのコンテキストで実行されるか否かを検証するテスト命令も含み、この場合、ロギング・エージェントへの呼び出しを開始する。

したがって、リプレイを実行するために使用される被修正ルーチンを含むこうしたシステム・モジュールは、そこで実行される様々なアプリケーションの機能、ならびにいかなるリプレイまたはロギング・モードを妨害することなく、１つまたは複数のコンピュータまたはネットワークのノード上にインストールまたはロードすることが可能であるか、あるいはその両方が可能である。

シミュレーションまたはリプレイ機能の改善範囲内で、本発明の他の目的は、アプリケーションまたはこれらのプロセスの少なくとも１つの機能の管理を改善することである。

次に、本発明に従った方法は、被ロギングと呼ばれる少なくとも１つのアプリケーション・プロセスの機能管理を実行し、
・ロギング・データの形で、再始動ポイントと呼ばれる所与のポイントから中断と呼ばれるポイントまでの、前記被ロギング・プロセスの実行時に発生した少なくとも１つの所与のタイプのイベントを表すデータを、記録および格納するステップと、
・被ロギング・プロセスの再始動ポイント状態に対応する状態の再始動プロセスから、当該ロギング・データからの当該イベントを当該再始動プロセスによってリプレイし、この再始動プロセスを中断ポイントでの被ロギング・プロセスの状態に対応する状態にするステップと、
を含む。

本発明の特徴によれば、ロギング・データは、再始動ポイントと呼ばれるその実行における所与のポイント以降に被ロギング・プロセスで発生する、１つまたは複数の所与のタイプのすべてのイベントを表す。次にリプレイ・ステップが、被ロギング・プロセスの再始動ポイント状態に対応する状態から始まる再始動プロセスに適用され、リプレイ・シーケンスは、この再始動プロセスを、被ロギング・シーケンス後の被ロギング・プロセスの状態に対応する状態に復元する。

本発明によれば、再始動ポイントでの被ロギング・プロセスの状態は、特に、再始動ポイント・データの形で取り込みおよび格納され、これを使用して、再始動プロセスは、リプレイ・フェーズを適用する前の再始動ポイント状態に復元される。

本発明に従った方法は、特に、外部イベントならびに内部イベントを含む一連のイベントのリプレイを実行するために使用することができる。したがって本発明は、これら外部のイベントそれぞれを再始動プロセス内に注入またはシミュレーションすることによって、外部イベントのリプレイを実施することを提案する。リプレイの実行における各外部イベントに続き、内部イベントが、直前の外部イベントの発生または処理あるいはその両方に応答して、再始動プロセスによって自発的に実行される。次に再始動プロセスは、外部リプレイ・エージェントによってトリガされた外部イベントの発生に応答して、内部イベントの少なくとも１つの被ロギング・シーケンスのリプレイを実行する。

機能管理の機能における本発明の一目的は、アプリケーションまたはこのアプリケーションからのプロセスのうちの少なくとも１つの機能の少なくとも一部の、デバッグ、あるいは分析または再生成のためのツールを改良することでもある。

したがって本発明は、たとえば、このアプリケーションのデバッグのコンテキスト内で、制御可能な、被追跡アプリケーションと呼ばれるアプリケーションの実行の監視を実施するために、機能管理を使用することを提案する。こうした監視は、被追跡アプリケーションの少なくとも１つのプロセスに適用され、
・被追跡アプリケーションの所与の状態から、被追跡アプリケーションの実行において調査済みシーケンスを構成する複数の一連の連続する被ロギング・シーケンスのロギングを開始するステップと、
・残りの被ロギング・シーケンスの制御された実行を生成する、制御された一連のリプレイ・ステップを生成し、制御リズムに従って調査済みシーケンスのリプレイを生成するステップと、
を含む。

機能管理の機能における本発明の目的は、アプリケーションの、またはこれらプロセスのうちの少なくとも１つの、機能を確実化するためのツールを改良することでもある。

こうした確実化は、特に、そのクライアントに提供されるサービスの観点から、アプリケーションの改良されたオペレーションの連続性の維持を通じて取得することができる。障害時にはこの連続性が全体的である可能性があり、すなわちクライアントは、同じサービスを取得するためにまったくオペレーションを再始動する必要がない。こうした連続性は部分的である可能性もあり、すなわち、同じサービスまたはこのサービスの一部を取得するために、クライアントが反復するかまたは余分に実行しなければならなくなる、オペレーションの数または複雑さあるいはその両方をできる限り低減させることによる。

このコンテキストにおいて、本発明は、クラスタと呼ばれる、通信またはさらに言えば冗長マルチコンピュータ・アーキテクチャの、オペレーション・ノードと呼ばれる少なくとも１つの１次ノードで実行される、管理された被確実化アプリケーションと呼ばれる第１のアプリケーションの機能を確実化するために、機能管理方法を実装することを提案する。この確実化は、スタンバイ・ノードと呼ばれる第２のクラスタ・ノードにおける、スタンバイと呼ばれる第２のアプリケーションの、再始動ポイントでの被確実化アプリケーションの状態に対応する状態への復元を含む。

この復元は、諸実施形態に応じて、または状況に応じて、いかなる障害もなく予防手段として実行するか、または障害検出後に、以前格納されたデータに基づいて実施することができる。

この確実化は、
・開始ポイント以降に被確実化アプリケーションの実行をロギングし、ロギングされたイベントを、オペレーション・ノード外部の少なくとも１つのログ・ファイルに格納するステップと、
・オペレーション・ノード内の障害を検出するステップと、
・被確実化アプリケーションにロギングされたイベントをスタンバイ・アプリケーションでリプレイするために、当該ログ・ファイルを使用し、最後にロギングされたイベント後に、被確実化アプリケーションの状態に対応する状態にスタンバイ・アプリケーションを復元するステップと、
を、さらに含む。

本発明は、協働するコンピュータのネットワークを備え、こうした方法を実装する少なくとも１つのノードを含む、システムも提案する。

とりわけ、本発明は、当該ネットワーク内で実行される少なくとも１つのアプリケーションの機能を管理するために本発明に従った方法を実装する、ミドルウェア・タイプのアプリケーションを使用するようなネットワークを提案する。

本発明は、特に、たとえばネットワーク、または、１つまたは複数のネットワークにわたって分散されたアプリケーション、あるいはその両方を管理する、「ミドルウェア」タイプの環境で適用可能である。

本発明の他の特徴および利点は、まったく限定的でない実施形態の方法の詳細な説明、および添付の図面から明らかとなろう。

図１は、本発明を実施する中間アプリケーションの機能アーキテクチャを示す図である。

クラスタ内で、たとえばトランザクション・アプリケーションなどのＡＯＰマスタ・アプリケーションは、特に様々な形でのデータの入力および出力によって、一定数のサービスをユーザまたはクライアントに提供する。クラスタ内で、このアプリケーションは単一またはマルチタスク（マルチプロセスまたはマルチスレッド）とすることが可能であり、一定数のリソースを使用する。特にこれらのリソースは、たとえば作業メモリのスペース、共有メモリ、またはデータ・ファイルの形の、データとするか、あるいは、たとえばセマフォまたはミューテックス（mutex）の形の状態インジケータとすることができる。

マスタ・アプリケーションは、オペレーティング・ノードＯＰまたは１次ノードと呼ばれるノードを形成する、１つまたは複数のコンピュータ上で実行される。中間アプリケーションＩＮＴと呼ばれる機能管理アプリケーションは、１つまたは複数のクラスタ・ノード内の１つまたは複数の部分で実行される。

諸実施形態によれば、この中間アプリケーションは、クラスタ内で機能するマスタ・アプリケーションの様々な面を処理することができる。こうした中間アプリケーションＩＮＴは、特に、「ミドルウェア・タイプ」の中間クラスタ管理ソフトウェアと並行して、こうしたミドルウェアと統合して、またはそれ自体がミドルウェアの形で、作業を行うことができる。

本明細書で説明する機能を介し、中間アプリケーションＩＮＴを使用して、特に、クラスタ内のマスタ・アプリケーションのすべてまたは一部の複製を生成することができる。マスタ・アプリケーションの複製は、次にリプレイ・アプリケーションと呼ばれることになる他のアプリケーションを提供することが可能である。

特にこうした複製に関連して本明細書で説明される機能は、マスタ・アプリケーションに関する信頼性（reliability）機能の実装、あるいは、「デバッグ」、調整、または開発タスクを実施するためのこのアプリケーションの追跡または調査も可能にする。信頼性実装のための使用には、たとえばバックアップまたは置換アプリケーションとしての再始動アプリケーションが含まれる。追跡またはデバッグの使用には、たとえば、以下で説明するように、被ロギング・イベントの速度低下または制御リズムに従った、イベントのロギングＪＯＰまたはリプレイＲＳＢあるいはその両方が含まれる。

したがって本明細書では、信頼性機能に適用される諸実施形態について、非限定的な例としてのみ説明する。

再始動ポイントまたは「チェックポイント」と呼ばれる異なるポイントで、定期的またはイベント時に、ＡＯＰマスタ・アプリケーションを信頼されるように実行する場合、中間アプリケーションＩＮＴは、２次、または「スタンバイ」ＳＢと呼ばれるノード上で実行される少なくとも１つの再始動アプリケーションＡＳＢを、作成または更新する。

この再始動アプリケーションは、たとえば、再始動方法と呼ばれるアプリケーションの取り込みおよび復元による複製の方法によって、作成または更新される。当該複製方法は、マスタ・オペレーションの状態の取り込みオペレーションＣＡＰと、それに続く、この状態、すなわち、そのプロセスの状態、およびこれが使用するリソースのすべてまたは一部の状態の、復元オペレーションＲＥＳを含む。

こうした取り込みオペレーションＣＡＰ時に、ＡＯＰマスタ・アプリケーションの状態は、チェックポイント状態ＥＰＲを形成するデータの形でバックアップされる。

マスタ・アプリケーションのリソースの一部、特に、ハード・ディスクなどのストレージ手段上の大容量を表すデータ・ファイルを、進行中（on-the-flow）に、ミラー・ディスクまたは共用ディスク上に再始動データ・ファイルを構成する、いくつかの異なるストレージ・メディア上のいくつかのコピーに更新することが可能である。この場合、チェックポイント状態を形成するデータは、これらの再始動データ・ファイルへの参照を構成する情報を含むことができる。

チェックポインティングまたは複製が、直接またはリプレイ・データ・ファイルへの参照のいずれかによる、すべての実行環境およびマスタ・アプリケーション・リソースを含む取り込み状態に基づく場合、当該チェックポイントまたは当該複製はホリスティック（holistic）と呼ぶことができる。

チェックポイント状態ＥＰＲのデータから、中間アプリケーションＩＮＴは、再始動アプリケーションＡＳＢの作成または更新によって復元ＲＥＳを実施することができる。当該復元は、定期的に、または開始イベント時、たとえば管理者またはクラスタ作業負荷を管理するためのメカニズムの要求時に、実施することができる。この復元は、オペレーション・ノードの障害が検出によって検出された後に実施可能であり、その後再始動アプリケーションは、永続または非永続のバックアップ・アプリケーションとして使用することができる。

必要であれば、中間アプリケーションは、マスタ・アプリケーション・サービスのすべてまたは一部の、１つまたは複数の再始動アプリケーションへの切り替えを組織化する。この切り替えをクライアントに対してトランスペアレントにするために、中間アプリケーションは、仮想ネットワーク・アドレスを管理する「メタプロセス」を通じて介入方法を使用し、クライアントのマスタ・アプリケーションからこれら再始動アプリケーションへの接続のマイグレーションを実施することができる。中間アプリケーションは、仮想プロセス識別（仮想ＰＩＤ）を管理する「メタプロセス」を通じて介入方法を使用し、これら再始動またはクローン・プロセスに関する通信を、それらオリジナル・プロセスのものと同一に復元することもできる。

これらの技法は、たとえば、フランス特許第２８４３２１０号に記載されたものとすることができる。

たとえば、マスタ・アプリケーションの作業負荷を分散させるため、またはオペレーション・ノードまたはネットワークの特定要素の保守を可能にするために、任意の障害以外に、復元およびそれに続く部分または全体切り替えを実施することもできる。

この障害または切り替えあるいはその両方を、クライアントの観点からできる限りトランスペアレントとするために、中間アプリケーションは、マスタ・アプリケーションのいくつかのチェックポイントに影響を与えるイベントのすべてまたは一部を記録し、それらを１つまたはいくつかの「ログ」の形でバックアップする。

チェックポイント状態からの復元の完了時、再始動アプリケーションは、当該チェックポイントを確立する際のマスタ・アプリケーションの状態にある。この状態から始まり、中間アプリケーションは、当該チェックポイント以降バックアップされたログを使用して、このチェックポイント以降マスタ・アプリケーションで行われたイベントの、再始動アプリケーションによる再実行またはリプレイを発生させる。

中間アプリケーションは、たとえば、再始動アプリケーションに関するいくつかのリソースが、復元されたチェックポイント以降変更された場合、当該実際の状態に対応する状態に戻されない限り、これらのリソースの実際の状態を干渉することなく、その再実行を実行できるように、これらのリソースの仮想化を実施することもできる。

オペレーション・ノード上でロギングされ、２次ノード上でリプレイされるイベントの中には、外部と呼ばれるイベントと内部と呼ばれるイベントの区別がある。

外部イベントは、マスタ・アプリケーションの出現時に、当該アプリケーションの外部として定義される。したがって外部イベントは、アプリケーション内部で、このアプリケーションの外部からの、すなわち、特に制御を行わないハードウェアまたはソフトウェアからのアクションまたは情報によって開始される、イベントとして定義される。これらの外部イベントは、たとえば、キーボードまたはマウスなどのハードウェア・インターフェース入力であるデータまたは信号入力、あるいは、クライアント・サーバ・アプリケーションの場合のクライアントなどの、ネットワークを介して着信し、外界から入ってくるデータ、の形を取ることができる。最も頻繁には、これら外部イベントは、アプリケーションの環境から推定または再作成することができない。これら外部イベントは、マスタ・アプリケーションによってロギングされ、再始動アプリケーションによってリプレイすることができる。

時にはターゲット・アプリケーションと呼ばれる当該アプリケーションが、１次ノード以外のノード上で実行される要素を組み込む場合、当該アプリケーション内であるが１次ノードの外部であるイベントを、外部イベントとして処理することもできる。

内部イベントは、たとえば、このアプリケーションのプロセスによって受け取られ、同様にアプリケーションの一部である他のプロセスから入ってくる、データまたは信号入力の形で、マスタ・アプリケーションのまたはこれを実行中のノードの、内部として定義される。これらの内部イベントは、直接、あるいは、アプリケーション外部であるがこれを実行しているノードの一部であるソフトウェア・メカニズムまたはエージェントを介して、たとえば、Ｕｎｉｘ（登録商標）タイプのシステムからの「プロセス間通信」（ＩＰＣ）エージェントなどの、パートナ・アプリケーションまたはオペレーティング・システムの一部を介して、受け取ることができる。これらの内部イベントは、たとえば「パイプ」、「信号キュー」、または「メッセージ・キュー」、あるいは「ソケット」のインターフェースから入ってくる、「メッセージ受け渡しイベント」を含むことができる。これらの内部イベントは、「共有メモリ・アクセス」イベント、たとえばセマフォまたは「ミューテックス」を含むこともできる。

アプリケーションが実行中の間、内部イベントは、たとえば外部イベントに比べてかなり数が多い。さらに内部イベントは、高速の実行、または特にロギング・オペレーションに関する時間に比べて少ない待ち時間、オペレーションに対応し、とりわけ、後者がネットワーク伝送またはハード・ディスクなどの永続メディア上のストレージを含む場合はそうである。たとえばロギング・オペレーションは、内部イベントの１０から１０，０００倍の持続時間を示す場合がある。

図２に示されるように、チェックポイント以降に発生したイベントのロギングＪＯＰは、外部イベントおよび内部イベントに対して異なるように実施され、別々にバックアップされる。

ネットワークによってクラスタに接続されたオペレーション・ノードＯＰは、それ自体が「ユーザ・スペース」と呼ばれるスペースをサポートする、システム・スペースをサポートするハードウェア・スペースを備える。ＯＳＩモデルの１つまたは複数の最下層を基準にして画定することが可能なハードウェア・スペースは、特に、プロセス、実際のメモリおよびプロセッサ、ならびにネットワーク・カードなどの通信を実行するための、ハードウェア・デバイスを備える。通常、多くの外部イベントは、ネットワークを介して渡される通信の形で、ハードウェア・スペースを介して移行する。

ＯＳＩモデルの１つまたは複数の中間層を基準にして画定することが可能なシステム・スペースは、特にオペレーティング・システムを含む。このシステム・スペースは、Ｕｎｉｘ（登録商標）システムでのソケットの形で、アプリケーションからのハードウェア・スペースを介した外界との通信を管理する、あるいは、たとえばＵｎｉｘ（登録商標）システムでの「パイプ」およびＩＰＣの形で、いくつかのアプリケーション・プロセス間の通信を管理する、様々なソフトウェア・メカニズムおよびエージェントを備える。

ＯＳＩモデルの１つまたは複数の最上層を基準にして画定することが可能なユーザ・スペースは、マスタおよび中間アプリケーションなどのノードによって実行される様々なアプリケーションの一部である、プロセスを備える。このユーザ・スペースでは、たとえばマスタ・アプリケーションなどの１つまたは複数のアプリケーションの一部である、いくつかのプロセスＰ１、Ｐ２、およびＰｎが実行される。これらのプロセスは、システム・スペースからの１つまたは複数の「ソケット」を介して外部と、ならびに、システム・スペースからの１つまたは複数の「パイプ」を介してそれらの間で、情報を交換する。これらのプロセスのいくつかは、状態リソース（図示せず）によって管理された形で、「共有メモリ」リソースＳＨＭにも同時にアクセスする。

チェックポイントをセットアップする場合、中間アプリケーションは、１つまたは複数の新しいログを開始するか、または実行ログ内に「チェックポイント・マーク」を記録することができる。

特に、「ユーザ・スペース」または内部イベント・ログ（「ユーザ・ログ」）（以下で説明）の場合、「ユーザ」という用語は、本明細書では「システム・スペース・ユーザ」の意味に取られることに留意されたい。これは、その後「クライアント」として定義されることになる、アプリケーションと通信する人物またはコンピュータが、たとえこのユーザ・スペースに直接アクセスできない場合であっても、これらアプリケーションが、ノードおよびそのオペレーティング・システムを使用して、ユーザ・スペースにアクセス可能であることを意味する。

外部イベントは、「カーネル・ログ」と呼ばれる、１つまたは複数のファイルＫＬからなるログにバックアップされる（図２を参照）。このバックアップを実施するために、これらのイベントを表すデータが、ノードに着信後、ＯＳＩ国際分類の低レベル層で読み取られる。好ましくはこれらのイベントは、システム・スペース、たとえばカーネル内で、逆多重化（demultiplex）される前、および「プロトコル・スタック」によって処理される前に、読み取られる。このロギングはシステム・スペース内部から直接実行されるため、バッファに書き込むことによって生じる性能損失および不必要なコンテキスト変更を避けることが可能である。

図３は、特にＴＣＰ−ＩＰプロトコル・メッセージの形を取る場合の、外部イベントのロギング・オペレーションをより詳細に示す。マスタ・アプリケーションは、オペレーション・ノードＯＰ上で実行され、少なくとも１つのプロセスＰ１を備える。中間アプリケーションは、オペレーション・ノードＯＰ上で実行される制御プロセスＣｔｌＯＰを有する第１の「ＩｐｌｏｇＯＰ」モジュールと、２次ノードＳＢ上で実行される制御プロセスＣｔｌＳＢを有する第２の「ＩＰｌｏｇＳＢ」とを備える。これらのノードＯＰおよびＳＢのそれぞれで、制御プロセスは、当該ノードのシステム・スペースで実行される、ソフトウェア・メカニズムまたはエージェント「ｄｉｓｐ」（ＤＩＳＰＰ、ＤＩＳＰＳ）のオペレーションを管理する。

Ｕｎｉｘ（登録商標）タイプのシステムの場合、当該「ｄｉｓｐ」エージェントは、特に、システム・スペースにロードされたカーネル・モジュールを備える。このカーネル・モジュールは、システムがブートされた場合、あるいは管理されるかまたは信頼できるようになるアプリケーションを起動する前でさえ、カーネルに動的にロードされる。機能構造の観点からすれば、たとえばＯＳＩ層を参照すると、このモジュールはＩＰ層の下に、ハードウェア・スペースに応じて特にＩＰ層と「ネットワーク・デバイス」層の間に、挿入される。

この「ｄｉｓｐ」エージェントは、ネットワークから受け取られ、ＴＣＰ層にアドレス指定されたメッセージを、インターセプトし、必要に応じて送信または受信により動作する、メッセージ・ファイルＱＯＰおよびＱＳＢに格納することができる。

ステップ１では、クライアントから着信し、プロセスＰ１にアドレス指定されたメッセージが、オペレーション・ノードＯＰのシステム・スペース内の「ｄｉｓｐ」エージェントによって受け取られ、メッセージ・キューＱＯＰ内で保持される。

ステップ２では、メッセージが受け取られたことを表すロギング・メッセージが、「ＤＩＳＰＰ」エージェントによって１次ノードから２次ノードＳＢに送られ、ＤＩＳＰＳエージェントは受信済みメッセージ・キューＱＳＢ内でこれを受け取る。

オペレーション・ノードＯＰは、クライアントとの通信に使用されるものとは異なるネットワーク・デバイスを使用することによって、特に、別のローカル・エリア・ネットワーク（ＬＡＮ）を介して、１つまたは複数の２次ノードＳＢと通信することができる。

いくつかのこれら２次ノードは、オペレーション・ノードＯＰと通信するために、ＲＦＣ １１１２標準に従った「マルチキャスト」タイプのアドレスにもサブスクライブすることができる。たとえばＲＦＣ １１１２標準「Host Extensions for IP Multicasting」によって、２２４．０．０．０から２３９．２５５．２５５．２５５の間の範囲のＩＰアドレスとして定義された、マルチキャスト・アドレスを使用することにより、オペレーション・ノードは、ネットワーク内のすべてのアドレスに送信されることになる伝送によってネットワークに過負荷をかけることなく、いくつかの２次ノードに同時にアドレス指定されたメッセージを、１度だけ送信することができる。

好ましくは、ノードＯＰから他のノードＳＢに送信されるロギング・メッセージは、物理層レベルで受け取られるすべてのパケットを、それらのオリジナルの形で含むはずである。すなわち、マスタ・アプリケーションにアドレス指定されたすべてのデータ、ならびにイーサネット（登録商標）、ＩＰ、およびＴＣＰヘッダなどのネットワーク・データを含む。

ステップ３では、２次ノードＳＢは、肯定応答メッセージをオペレーション・ノードＯＰに送信する。

ステップ４では、オペレーション・ノードＯＰで、対応する肯定応答が受け取られると、メッセージ・キューＱＯＰからメッセージが取り出され、ＴＣＰ層に送信される。

並行ステップ４’では、２次ノードＳＢはメッセージをログに、たとえばカーネル外部イベント・ログＫＬに記録し、受け取ったメッセージ・キューＱＳＢから取り出す。

ステップ５では、オペレーション・ノードＯＰで、マスタ・アプリケーションのＰ１プロセスが「ソケット」要素内のメッセージを読み取り、次に、その動作を続けるためにこれを処理する。

マスタ・アプリケーションは、２次ノードＳＢによる確認応答の後、入ってくるメッセージを考慮するだけであるため、本発明は、ロギングされていないメッセージがアプリケーションによって処理できないことを保証する。たとえば、こうした読み取られていないメッセージをＴＣＰプロトコルの再送機能によって取り出すことはできない。

チェックポイント・マークをカーネル・ログ内に設定しようとする場合、２次ノード内の制御プロセスＣｔｌＳＢは、当該チェックポイント・マークを表すデータをそこに記録する。

内部イベントのコンテンツは、ローカル、すなわちノード内の環境に、先行する外部イベントのコンテンツに、および、プロセッサ内のスケジューリング、あるいはノード内で並行して動作するいくつかのプロセッサまたはコンピュータの管理の問題に、直接依存する。事実上、ほとんどの場合、これらイベントの順序のみがアプリケーションの後続の動作に影響を与える。

中間アプリケーションＩＮＴは、これら内部イベントそれぞれの詳細またはパラメータを記憶せずに、それらイベントの順序をロギングすることに限られる。この選択により、これら内部イベントのロギングＪＯＰについて格納されるデータのボリュームを削減すること、およびこのロギングによりオペレーション・ノードおよびマスタ・アプリケーション内で発生する性能損失を最小限にすること、が可能になる。

内部イベントは、「ユーザ・ログ」と呼ばれる１つまたは複数のファイルで構成されるログにバックアップされる（図２を参照）。

図４に示されるように、１次ノードＯＰおよび２次ノードＳＢは、ハードウェアまたはソフトウェアあるいはその両方の高速相互接続（ＨＳＩ）を介して通信する。当該ＨＳＩシステムは、１次ノードＯＰのロギング・プロセスＰｌｏｇＯＰと２次ノードＳＢのロギング・プロセスＰｌｏｇＳＢとの間で、および、これら２つのノードのオペレーティング・システムのすべてまたは一部をバイパスすることによって直接、データの転送を可能にする。こうしたＨＳＩシステムは、ネットワーク・カードおよびそれらの制御ソフトウェアなどの既存のネットワーク・インターフェース・コントローラを使用することにより、既知の手段に従って実装することができる。こうしたＨＳＩシステムは、またはクラスタ内部の残りのネットワークと並行して、またはこれらと組み合わせて、高性能ネットワーク・デバイスを使用することによって実装することもできる。

内部イベントは、中間アプリケーションのロギング・プロセスＰｌｏｇＯＰによって、オペレーション・ノードＯＰのユーザ・スペース内で精査および読み取られる。これはその後、高速接続システムＨＳＩを介して、これらの内部イベントまたはそれらの発生順序あるいはその両方を表すデータを、２次ノードのロギング・プロセスＰｌｏｇＳＢに送信する。次にこのデータは、「ユーザ・ログ」を形成する１つまたは複数のファイルにバックアップされる。

チェックポイント・マークを「ユーザ・ログ」内に設定しようとする場合、２次ノードの制御プロセスＰｌｏｇＳＢは、このチェックポイント・マークを表すデータをそこに記録する。

好ましくは、ロギング・プロセスＰｌｏｇＯＰは、その「リターン」で、すなわち、その結果がすでに生成されているが、その実行を要求したマスタ・アプリケーション・プロセスにまだ送信されていない場合に、内部イベントを読み取る。

この読み取りは、たとえば入力／出力システム呼び出し、たとえば「パイプ」へのアクセス、および共有メモリ・セグメントＳＨＭをロックするオペレーションへの応答をインターセプトすることによって、実行される。

このインターセプトは、システムによって提供され、アプリケーションによって呼び出される、ルーチンのすべてまたは一部のコンテンツに、記録命令（レコーディング・プローブ）を挿入することによって実施される。レコーディング・プローブは、図７に示されるように、以下で指定されるような「メタプロセス」による動的介入技法を使用することによって、たとえばオリジナル・ルーチン・コードの終わりに対してエピローグを形成する、追加命令の形で追加される。

内部イベント・ログ、「ユーザ・ログ」は、それぞれが内部イベントを表す一連の記録を含む。これらのイベントは、単一ファイルにロギングすることが可能であり、その後、当該リソースまたはプロセスあるいはその両方の識別を含むことになる。それらは、たとえばリソースごと、プロセスごと、またはそれら２つの組み合わせごとに、１つのファイルの、いくつかのファイルに記録することも可能である。

所与のリソースに対応するファイルの場合、これら記録のそれぞれが、特に、
・各リソース固有の順番であり、当該リソース上での新しいイベントまたはオペレーションごとに増分される、当該イベントの連続番号、
・たとえばこのリソースに関する最終イベント以降の経過時間を表す、タイムスタンプ情報、
・たとえば入力／出力リソース（「Ｉ／Ｏ」）に関する「読み取り」または「書き込み」、あるいはセマフォに関する「ロック」または「アンロック」の、イベント・タイプ、
・結果、すなわち入力／出力オペレーションの場合の値、または「ロック」の場合の排他的アクセスを得るプロセスの識別、
の、フィールドを含む。

この結果は、特に、たとえば、２次ノードで復元された再始動またはバックアップ・アプリケーションによる、ログ内のイベントのリプレイ時に、リソースの仮想化を実施するために使用される。格納された結果は、その後、リプレイ時に実行されたＩ／Ｏオペレーション要求の結果として強制される値、または「ロック」を得るタスクの場合、プロセスの仮想識別（仮想ＰＩＤ）を構成することになる。

オペレーション・ノードから１つまたは複数の２次ノードにロギング・データを送信することによる、性能損失を制限するために、いくつかの内部イベントを表すデータの送信を集約することが有用である。

このために、中間アプリケーションは、たとえば、オペレーション・ノードＯＰの１次と呼ばれるロギング・プロセスＰｌｏｇＯＰによって実装される、いくつかの異なる方法の組み合わせを使用することができる。

アプリケーションの内部変更は、このオペレーションが外界に対して何も送信しない限り、外界に関して、たとえばそのクライアントに関して重要でないことが理解される。チェックポイントおよびログから復元された再始動アプリケーションは、当該ログが、ロギングされたマスタ・アプリケーションによって送信された最後の外部メッセージ以降に発生した内部イベントを含まない場合、外界に対するいかなるサービスの割り込みも発生させることはない。

第１の方法によれば、この１次ロギング・プロセスＰｌｏｇＯＰは、内部ロギング・データが発生した場合、ただし非同期モードで、伝送可用性に従い、マスタ・アプリケーション機能のブロッキングなしに、後者が外部メッセージを送信しない限り、これを送信する。マスタ・アプリケーションによる外部メッセージの次の送信で、検出の手段はこの１次ロギング・プロセスに警告し、次にこの外部メッセージの送信を、および場合によっては１つまたは複数のマスタ・アプリケーションのプロセスの実行を、ブロックまたは中断する。このブロックは、その後、すべての内部ロギング・データがこの非同期伝送を介して送信されるまで、または当該データの受け取りを受け取るまで、維持される。

第２の方法によれば、１次ロギング・プロセスＰｌｏｇＯｐは、いくつかの連続する内部イベントを表す内部ロギング・データを、２次ノードのロギング・プロセスＰｌｏｇＳＢに即時に送信せず、バッファに格納する。これは、番号が設定されたしきい値に達した場合、またはアプリケーションが外部と呼ばれるメッセージ、たとえばクライアントまたは外部プロセスにアドレス指定されたデータまたは信号を、外界に送信しなければならない場合にのみ、これらを送信する。マスタ・アプリケーションによる外部メッセージの次の送信時に、検出の手段は、この１次ロギング・プロセスに警告し、次に、この外部メッセージの送信を、および場合によっては１つまたは複数のマスタ・アプリケーションのプロセスの実行を、ブロックまたは中断する。このブロックは、その後、１次ロギング・プロセスが、キャッシュ内の残りのロギング・データを２次ノードに送信するまで、または当該データの受け取りを受け取るまで、維持される。

これら２つの方法において、外部メッセージを送信しなければならないという事実は、外向きのイベントを構成し、これが、ブロッキングと呼ぶことのできる、すなわち、先行イベントのロギングがこのイベントの実行前にクローズされることを要求する、イベントのタイプを構成する。諸実施形態によれば、最も頻繁には、外部の外向きイベントに加えて、他のタイプのイベントをブロッキングとして選択することができる。

図５は、１次ノードＯＰ外部の伝送前の、いくつかの内部イベントＥＶＩに関するロギング・データＤＪの集約を伴う、イベント・ログのオペレーションを示す。

ステップ１では、ロギング・プロセスＰｌｏｇＯＰが、被ロギング・プロセスＰ１の実行時に、イベントＥＶＩの発生を検出する。

ステップ２では、ロギング・プロセスＰｌｏｇＯＰが、検出されたイベントＥＶＩをブロッキング・タイプとみなさなければならないかどうかをチェックする。

ステップ３では、イベントＥＶＩがブロッキング・タイプでない場合、このイベントのロギングによってロギング・データ項目ＤＪが生成される。

ステップ４では、このロギング・データ項目ＤＪが、次のイベントの検出を待つ前に、バッファ・ログＪＳ１Ｌｏｃａｌを構成する順序付けされた構造内の１次ノードＯＰに格納される。

フェーズ５では、検出されたイベントＥＶＩがブロッキング・タイプの場合、ロギング・プロセスＰｌｏｇＯＰは、バッファ・ログＪＳ１Ｌｏｃａｌに以前にロギングされた内部イベントの実行シーケンスをクローズするフェーズを実施する。

このフェーズ５はステップ６を含み、ここでは、被ロギング・プロセスＰ１の実行が中断され、クロージャ・フェーズ５の満足のいく実行を保留する。

このフェーズ５はステップ７も含み、ここでは１次ノードのロギング・プロセスＰｌｏｇＯＰがバッファ・ログＪＳ１Ｌｏｃａｌのコンテンツを２次ノードのロギング・プロセスＰｌｏｇＳＢに送信し、検出されたイベントＥＶＩに関するログＪＳｅｍ１に格納され、次に先行データが続く。１次ロギング・プロセスＰｌｏｇＯＰは、このイベントが内部イベントでもある場合、バッファ・シーケンスを再始動すると共に、検出されたイベントＥＶＩの直接ロギングを続行する。

図６に示された変形形態では、内部イベントのバッファリングを、ブロッキング・タイプのイベントと場合によっては異なるタイプのイベントによって開始することができる。これには、開始タイプのイベントが含まれる。単一タイプのイベントを、ブロッキング専用タイプ、または開始専用タイプ、あるいはそれら両方のタイプであるとして選択することができる。

この変形形態では、ステップ１のイベント検出の次に、ステップｂ１が続く。このステップｂ１では、検出されたイベントＥＶＩのタイプが開始とみなされる場合、１次ロギング・プロセスＰｌｏｇＯＰは、バッファ・メモリへのロギングに関する現行のシーケンスＳＥＱＣが進行中であるかどうかをチェックし、進行中でない場合はこれを開始する。

後続のステップｂ２では、バッファ・メモリへのロギングに関するこうした現行のシーケンスＳＥＱＣが、検出されたイベントＥＶＩに対して進行中であるかどうかをテストする。

ステップｂ３では、このＥＶＩイベントに対してアクティブな現行のバッファ・シーケンスＳＥＱＣがない場合、その結果はロギング・データ項目ＤＪとしてロギングされる。

ステップｂ４では、当該ロギング・データ項目ＤＪが２次ロギング・プロセスＰｌｏｇＳＢに送られ、それらの先行に続いて、検出されたＥＶＩイベントに関するログ・ファイルＪＳｅｍ１に、先行データに続いて格納される。次に１次ロギング・プロセスＰｌｏｇＯＰは、新しいイベントの検出を待つ。

ステップｂ２に続いて、検出されたイベントＥＶＩに対して現行シーケンスがアクティブの場合、図５に示されるように、このイベントのロギングは続行される。

中間アプリケーションは、すべてまたは一部のサービスをマスタ・アプリケーションから再始動アプリケーションに切り替えたい場合、２次ノード内のこの再始動アプリケーションをチェックポイント状態から復元することによって開始し、次にこの後者のチェックポイント以降にロギングされたイベントのリプレイを実施する。

特に、イベント駆動型のマスタ・アプリケーションの場合、すなわち、開始イベント（外部）、たとえばトランザクション・アプリケーションで、外部イベントおよび内部イベントについて異なるように復元リプレイが実施される。

このアプリケーションについて、こうした機能手段は、外部イベントの受け取りを依然として待つことが可能な少なくとも１つのプロセスを含み、この時点で、内部イベントを含むオペレーションを実施することによって反応する。

したがってリプレイは、ロギングされた外部イベントのアプリケーションへのアクティブな供給、ならびに、再始動アプリケーション自体によってリプレイ時に作成される、内部イベントに応答してロギング済み回答を提供する受動応答を含む。

図７は、外部または「カーネル・ログ」を構成する１つまたは複数のファイルＫＬにロギングされた、ＴＣＰメッセージ・タイプの外部イベントのリプレイＲＳＢのオペレーションを示す。

当該カーネル・ログＫＬは、以前にロギングされたＴＣＰメッセージを再始動アプリケーションのプロセスＰＢ１に再注入するために、中間アプリケーションに属し、２次ノードＳＢのユーザ・スペース内で実行中の、リプレイ・プロセスＰＲＥによって使用される。

この再注入を実施するために、中間アプリケーションＩＮＴは、ＴＣＰメッセージ受け取り層内に、たとえばソフトウェア・メカニズムまたはエージェント「ｉｐｆｉｌｔｅｒ」の形で置かれた、ＩＰ層とＴＣＰ層との間に機能カーネル・モジュールを備える、ソフトウェア・メカニズムまたはエージェントを含むかまたはこれらを使用する。２次ノードは、ユーザ・スペース・プロセスがアクセス可能にするために、それへのアクセスがインターフェースによってシステムに「マッピング」される、ＢＬネットワークに関するローカル・ループ機能も含む。このループＢＬは、たとえばＵｎｉｘ（登録商標）などのオペレーティング・システムに実装されるソフトウェアである仮想ループバック・インターフェースとは対照的に、特に、ＩＰ層下部のデータを再注入できるようにする、ハードウェア・スペース内に物理デバイスを含むことができる。

ステップ１では、リプレイ・プロセスＰＲＥが「カーネル・ログ」ＫＬのファイルにロギングされたメッセージを読み取る。

ステップ２では、リプレイ・プロセスＰＲＥがこのメッセージをネットワーク・ローカル・ループＢＬに注入する。

ステップ３では、このメッセージがＩＰ層によって受け取られ、「ｉｐｆｉｌｔｅｒ」エージェントを介して、処理のためにＴＣＰ層に送られる。

ステップ４では、ＴＣＰ層が受け取りをネットワークに送る場合、後者は「ｉｐｆｉｌｔｅｒ」エージェントによってフィルタリングまたはブロックされることになる。

ステップ５では、メッセージがＴＣＰ層に送られた後、その受け取りがあればそれを受け取った後、「ｉｐｆｉｌｔｅｒ」エージェントは、メッセージがＴＣＰ層によって実際に受け取られたかまたは処理された旨の信号を、リプレイ・プロセスＰＲＥに送信する。

ステップ６では、再始動アプリケーション・プロセスＰＢ１がＴＣＰ層からメッセージを受け取り、それに含まれるパケットの非同期読み取りを実施する。

リプレイ全体にわたり、「ｉｐｆｉｌｔｅｒ」エージェントは再始動アプリケーションをネットワークから分離し、同時に、すべての外部メッセージがＴＣＰ層まで到達するのを防ぎ、同時に、再始動アプリケーションによって送信されるすべてのメッセージが、このアプリケーションに関してトランスペアレントにＩＰ層に到達するのを防ぐ。

リプレイ・アプリケーションでは、２つのリプレイされた外部イベント間で生じる内部イベントのリプレイを実施するために、中間アプリケーションは、再始動アプリケーションの独力での実行を可能にし、同時にそのための関連リソースを仮想化し、受動リプレイを実施する。その後、リプレイ・プロセスＰＲＩは、所与のリソースに関して内部イベントを構成する各オペレーションを検出し、当該リソースにロギング済みの動作を採用するように強制し、このロギング時に当該イベントについて格納された結果をリプレイ・アプリケーションに送信する。

図８から図１０は、共有リソース、たとえば共有メモリ領域への相互排除アクセスを得るために、再始動アプリケーションの２つのプロセスＰＢ１およびＰＢ２から、セマフォＳＥＭ１を要求するオペレーションを含む場合の、内部イベントのリプレイＲＳＢの例を示す。

２次ノードＳＢでの復元時に、これら２つのプロセスＰＢ１、ＰＢ２は、ユーザ・ログを構成するファイルに基づいてリプレイを実施する。それらのリプレイ時に、再始動アプリケーションの実行により、これらそれぞれのプロセスは、内部イベント・ログ「ユーザ・ログ」に含まれるログ・ファイルＪＳＥＭ１が対応する、単一のセマフォＳＥＭ１への呼び出しを実行する。

これらアクセス・オペレーションの検出およびそれらの応答の事前設定は、「メタプロセス」による動的介入の技法を使用して、システムによって提供されアプリケーションによって呼び出されるルーチンのすべてまたは一部のコンテンツで、追加命令を追加することによって実施される。こうした技法は、たとえば特許ＦＲ第２８４３８０９号に記載されたものとすることができる。特に、これらの命令は、コードがオリジナル・ルーチンからの機能を実施する前に集約され、プロローグを形成するか、またはこのコードの後に集約され、エピローグを形成することが可能である。

図９は、ルーチンＲ内へのプロローグおよびエピローグの挿入を示し、改定されたルーチンＲＭが与えられる。この例では、同じ改定済みルーチンＲＭを使用して、マスタ・アプリケーションのロギングを実施し、さらに再始動アプリケーションのリプレイも実施することができることに留意されたい。

アプリケーションの実行可能ファイルの実行時に、プロセスＰは、たとえば、共有メモリ内の所与の領域への相互排除アクセスを得るために所与のセマフォの位置決めを要求する、「ＰＯＳＩＸ．４」標準からのルーチン「ｓｅｍ＿ｗａｉｔ」である、ルーチンＲを呼び出す一連のコードを実行する。マルチスレッド・アプリケーションの場合、これは、同様の役割を果たす命令、「ＰＯＳＩＸスレッド」標準からの「ｐｔｈｒｅａｄ＿ｍｕｔｅｘ＿ｌｏｃｋ」を含むことができる。

起動された際、またはアプリケーションの実行可能ファイルの前にシステムにロードされた介入エージェントＭＥＴＡは、システムのオリジナル・ルーチンＲへの呼び出しをインターセプトし、これを改定されたルーチンＲＭに転送する。この改定済みルーチンは、プロローグを実施する命令が先行し、エピローグを実施する命令が後続する、オリジナル・ルーチンＲを実施または呼び出す命令、「ｓｅｍ＿ｗａｉｔ」を含む。

これらの補足命令は、特に、
プロローグの場合、
ｉｆ（ｒｅｐｌａｙ） ｃｈｅｃｋ（Ｊｓｅｍ１）
エピローグの場合、
ｉｆ（ｒｅｐｌａｙ） ｅｎｄ＿ｃｈｅｃｋ（Ｊｓｅｍ１）
ｅｌｓｅ ｒｅｃｏｒｄ（ｒｅｓｕｌｔ，Ｊｓｅｍ１）
のタイプからのアルゴリズムを含むことができる。

命令「ｉｆ（ｒｅｐｌａｙ）」は、アプリケーションがリプレイを実施するプロセスにあるか否かを示す条件をテストする。

これに対して（「ｅｌｓｅ」）の場合、これは、アプリケーションが通常通りに実行されているため、マスタ・アプリケーションとして取り扱わなければならないことを意味する。次に、エピローグは、前述のようなレコーディング・プローブである、関数「ｒｅｃｏｒｄ（ｒｅｓｕｌｔ，Ｊｓｅｍ１）」を実行し、内部イベントのロギングに参加し、同時に結果「ｒｅｓｕｌｔ」をログ「Ｊｓｅｍ１」に格納する。

「Ｊｓｅｍ１」ログを使用して、リプレイ時に「ｓｅｍ＿ｗａｉｔ」ルーチンが再始動アプリケーションによって呼び出される場合、プロローグは、システムのオリジナルの「ｓｅｍ＿ｗａｉｔ」ルーチンを実施する前に実行される。

図１０は、内部イベント・ログ「ユーザ・ログ」に含まれるＪＳＥＭ１ログから、２つのプロセスＰＢ１、ＰＢ２のリプレイを実施するための、この改定済みルーチンＲＭのオペレーションを示す、時間流れ図である。ＪＳＥＭ１ログにロギングされた各イベントは、当該セマフォＳＥＭ１特有の増分シーケンス＃ＯＰに従って番号付けされる。これら番号＃ＯＰそれぞれに従って、ＪＳＥＭ１ログは、ロギング時に当該ＪＳＥＭ１ログに対応するセマフォを呼び出した、プロセスの識別情報（ＰＩＤ）を含む。

２つのプロセスＰＢ１およびＰＢ２が並行して実行される場合、「ｓｅｍ＿ｗａｉｔ」機能を使用するそれらそれぞれのＳＥＭ１セマフォへの呼び出しは、必ずしも、セマフォのログＪＳＥＭ１に格納された順序で実行されるとは限らない。

「ｉｄ２」識別子プロセスＰＢ２が、リプレイ時にＳＥＭ１セマフォを呼び出した場合、プロローグはステップ２１で、同じプロセス名ＰＢ２で命令「ｃｈｅｃｋ（Ｊｓｅｍ１）」を実行する。この関数「ｃｈｅｃｋ（Ｊｓｅｍ１）」は、ＪＳＥＭ１ログ内の、シーケンス番号ＯＰＳＥＭ１の現在値に対応する行、すなわち行「＃１：ｉｄ１」を読み取る。

この「チェック」機能は、読み取った値ＰＩＤｌｏｇ、すなわち「ｉｄ１」と、呼び出し側のＰＢ２プロセスの識別子、すなわち「ｉｄ２」とを比較する。これらの値が異なることを示す場合、この「チェック」機能は、たとえば連続ループ内での比較であるこの同じステップ２１を再実行することによって、呼び出し側ＰＢ２プロセスの実行を中断する。

その後、ＰＢ１プロセス識別子「ｉｄ１」がリプレイ時にＳＥＭ１セマフォも呼び出した場合、プロローグは「ｃｈｅｃｋ（Ｊｓｅｍ１）」命令も実行するが、今回はステップ１１の新しいＰＢ１呼び出し側プロセスの名前である。当該ＰＢ１呼び出し側プロセスが実際に、アクティブ・シーケンス内の現在の番号、すなわち値「＃１」に対応する行のログに識別子「ｉｄ１」が格納されたプロセスであることを示す場合、「チェック」機能は、ＰＢ１呼び出し側プロセスの実行が続行されることを許可する。

ステップ１２では、その後、改定済みルーチンＲＭがオリジナル・ルーチンＲの機能、すなわち「ｓｅｍ＿ｗａｉｔ」命令を実施し、これにＳＥＭ１セマフォが割り当てられ、ＰＢ１呼び出し側プロセスの値「ｉｄ１」を戻す。

ステップ１３では、その後エピローグが、ＰＢ１呼び出し側プロセスの名前で「ｅｎｄ＿ｃｈｅｃｋ（Ｊｓｅｍ１）」命令を実行する。当該「ｅｎｄ＿ｃｈｅｃｋ」機能は、次に、ＰＢ１プロセスの「ｓｅｍ＿ｗａｉｔ」呼び出しをクローズし、保留されてきたＰＢ２プロセスの実行をブロック解除する。このオペレーションは、特に、このＳＥＭ１セマフォのシーケンス番号ＯＰＳＥＭ１の増分を含み、これを次の値「＃２」へと移行させることができる。

この場合、ＰＢ２プロセスによって呼び出された「チェック」機能が、ステップ２２で再度実行され、ＪＳＥＭ１ログ「＃２：ｉｄ２」の次の行を読み取り、そのＰＢ２呼び出し側プロセスに改定済みルーチンＲＭのその実行を続行させる。

ステップ２３では、その後、改定済みルーチンＲＭがオリジナル・ルーチンＲの機能、すなわち「ｓｅｍ＿ｗａｉｔ」命令を実施し、その後、これにＳＥＭ１セマフォが割り当てられ、ＰＢ２呼び出し側プロセスの値「ｉｄ２」を戻す。

ステップ２４では、その後、エピローグが「ｅｎｄ＿ｃｈｅｃｋ（Ｊｓｅｍ１）」命令をＰＢ２呼び出し側プロセスの名前で実行し、ＳＥＭ１セマフォ・シーケンスを再度増分して、リプレイの続行に使用できるようにする。

ＳＥＭ１セマフォの様々なリプレイ済みプロセス要求割り当ての順序に関係なく、そのＪＳＥＭ１ログに格納されたとおりの順序で、したがって、マスタ・このロギングを生成したアプリケーションの実行時と同じ順序でのみ、取得可能であることが明らかである。

これらの追加命令は、マスタ・アプリケーション外部のＭＥＴＡエージェントによって追加され、オペレーティング・システムのいかなる変更もなしにオペレーティング・システムに追加されるため、これらのロギングおよびリプレイ・オペレーションは、マスタ・アプリケーションに対して、システムの既存の要素を変更することなく、トランスペアレントに、かつ煩雑でないように、実施されることが明らかである。

内部イベントが多数であるとした場合、特に、前述の特徴から得られる利点を大幅に損なうことになるいかなる性能低下も避けるために、それらのロギングまたはリプレイあるいはその両方の機能を最適化することが有用である。

２つの外部イベント間で発生する内部イベントのタイプの中で、ほとんどが決定論的である、すなわちその結果が、これらのオペレーションの前のアプリケーションの状態に確実に依存するオペレーションのみを組み込むものと、分類することができる。

他方で、特にマルチタスク・オペレーション時、またはいくつかのノードにわたるそれらの分散時に、いくつかの内部イベントは、アプリケーションまたは１次ノード外部の要素に依存する結果を提供することが可能なオペレーションを含むため、非決定論的タイプである。

非決定論的タイプの内部イベントのみをロギングまたはリプレイすることによって、オペレーション・ノードの過負荷と、マスタ・アプリケーションを信頼可能にするかまたは管理するために、中間アプリケーションの使用によって生じる性能低下とを、制限することが可能である。

図１１および図１２によって示されるように、ロギングおよびリプレイは、特に、作業が決定論的でない内部イベントに対して、結果のロギングのみ、およびリプレイ時の結果の事前設定のみによって、加速させることができる。

すべてのイベントについて、および特に内部イベント（ＥＶＩ）について、ＭＥＴＡ介入メカニズム（図９）は、前述のように、オリジナル・ルーチンＲの代わりに、要求されたオペレーションを実施する改定済みルーチンＲＭを呼び出す。この改定済みルーチンＲＭは、このイベントＥＶＩの発生から、ロギング・プロセスＰｌｏｇＯＰまたはリプレイ・プロセスＰＲＩを開始または通知することが可能であり、必要であれば、このイベントの処理を続行するため、または呼び出したＰ１またはＰＢ１プロセスにこの処理を引き渡すための、合意を待つことが可能な、機能を含む。

これがロギングまたはリプレイを含むかどうかにかかわらず、このイベントＥＶＩの管理は、このイベントの発生に対する反応ステップと、それに続く、コンテンツがこの内部イベントの決定論的または非決定論的性質に依存する追加の管理ステップＧＣ（図１１、図１２）とを含む。

図１１は、内部イベントのロギング・オペレーションを示す。Ｐ１プロセスが被ロギング（ＪＯＰ、図１）実行を介して実行される間に、命令の実行は、ＳＥＭ１セマフォなどの共有リソースへの内部イベントＥＶＩの適用を実施する。

ステップ１では、ロギングされることになるイベントＥＶＩに対応する改定済みルーチンＲＭが、ロギング・プロセスＰｌｏｇＯＰを通知または開始し、このイベントＥＶＩの発生を検出する。

ステップ２では、イベントＥＶＩに対応する改定済みルーチンＲＭは、ＳＥＭ１セマフォ上で、オリジナル・ルーチンＲで要求されたオペレーションを実施し、被ロギング・プロセスＰ１にアドレス指定された結果データＤＲを受け取るかまたは計算する。

ステップ３では、ロギング・プロセスＰｌｏｇＯＰは、Ｐ１ロギング・シーケンス内の検出されたイベントＥＶＩの位置に対応する、たとえばＳＥＭ１セマフォに割り当てられたシーケンス番号ＳＱを増分させる。

ステップ４では、当該プロセスＰｌｏｇＯＰは、検出された内部イベントＥＶＩが決定論的であるか否かを確定するためのテストを実施する。このテストは、たとえばその呼び出し時に改定済みルーチンＲＭから受け取られたパラメータに、またはこの呼び出しと共に送信される結果データＤＲの有無に、または、１次ＯＰノードに以前に格納された命令またはイベント識別に、適用することができる。

ステップ５では、検出されたイベントＥＶＩが非決定論的である場合、ＰｌｏｇＯＰプロセスは、結果データＤＲを２次ノードのＰｌｏｇＳＢロギング・プロセスに送る。これにより、セマフォＳＥＭ１に対応するログ・ファイルＪＳｅｍ１内で関連付けられ、先行するロギングされたイベントの結果に従うように、イベントＥＶＩに対応する結果データＤＲおよびシーケンス番号ＳＱが格納される。ロギング条件に応じて、ＪＳｅｍ１ログに格納されたデータを、ＰｌｏｇＯＰロギング・プロセスによって１次ノード内の永続メディア上のログ・ファイルに、直接格納することもできる。

被ロギング・プロセスＰ１に関する一連の内部イベントの完了時に、ＪＳｅｍ１ログは、シーケンス番号を含むイベントに関するシーケンス番号に関連付けられた、ＳＥＭ１セマフォによって当該Ｐ１プロセスに送られたすべての結果データの順序付けセットを含む。

図１２は、ＪＳｅｍ１ログに格納され、ＳＥＭ１セマフォに対応するイベントの、リプレイ・プロセスＰＲＩ（図８を参照）によって制御された、受動リプレイ・フェーズＲＳＢ（図１）時の、再始動プロセスＰＢ１におけるこの内部イベントＥＶＩに関するリプレイ・オペレーションを示す。ＰＢ１プロセスの実行中、およびＪＳｅｍ１ログからのイベントのリプレイ時に、命令を実行することで、ＳＥＭ１セマフォに適用される非決定論的タイプの内部イベントＥＶＩが実施される。

ステップ１では、ロギングされることになるイベントＥＶＩに対応する改定済みルーチンＲＭは、リプレイ・プロセスＰＲＩを通知または開始し、このプロセスがこのイベントの発生を検出および識別する。

ステップ２では、イベントＥＶＩに対応する改定済みルーチンＲＭは、ＳＥＭ１セマフォ上で、オリジナル・ルーチンＲで要求されたオペレーションを実施し、実際のリプレイ結果ＰＲＪに対応する結果データを受け取るかまたは計算する。改定済みルーチンＲＭは、再始動プロセスＰＢ１の実行を中断し、この結果ＰＲＪを再始動プロセスＰＢ１に送信するためにリプレイ・プロセスＰＲＩからの信号を待つ。

ステップ３では、リプレイ・プロセスＰＲＩは、関連付けられたシーケンス番号ＳＱｉと共に、リプレイに関するＪＳｅｍ１ログ内の次の未使用値ＲＬｉを読み取る。

ステップ４では、たとえばＳＥＭ１セマフォに割り当てられ、ＰＢ１内で検出されたイベントＥＶＩの位置に対応する、シーケンス番号ＳＱを増分するためのプロセスが、シーケンスＰＢ１をリプレイする。

ステップ５では、進行中のリプレイ・イベントＥＶＩがロギング済みイベントに対応するかどうかを確定するために、リプレイ・プロセスＰＲＩが、ログ内の現在のシーケンス番号ＳＱおよび読み取られたシーケンス番号ＳＱｉについてテストを実施する。

事前設定ステップ７では、これらのイベントが対応する場合、リプレイ・プロセスＰＲＩは、ログ内の読み取られた結果ＲＬｉを改定済みルーチンＲＭに送り、このルーチンが、オリジナル・オペレーションＲからの結果ＰＲＪの代わりに、これを格納する。次に改定済みルーチンＲＭは、この結果ＲＬｉを再始動プロセスＰＢ１に戻し、その実行を続行させる。

オプションで、事前設定ステップ７は、リプレイ・プロセスＰＲＩが改定済みルーチンＲＭから実際のリプレイ結果ＲＲＪを受け取り、これと、ロギング時の同じイベントの結果に対応する読み取られた結果ＲＬｉとを比較する、ステップ６によって先行される。当該２つの結果ＲＲＪおよびＲＬｉが対応する場合、プロセスは改定済みルーチンを直接解放し、これがその結果を再始動プロセスＰＢ１に戻して、その実行を続行させる。

したがって、非決定論的イベントは、忠実かつ正確に記録およびリプレイ可能であり、再始動プロセスＰＢ１に関して、ロギング時のターゲット・プロセスＰ１のそれに忠実なリプレイ・ランを保証することが明らかである。

一定のイベントのみがロギングまたはリプレイされるため、および、本発明を実施するための補足的内部オペレーションが、ロギングのためのストレージまたは伝送よりもかなり高速であるため、中間アプリケーションＩＮＴのオペレーションによるオーバヘッドは低減される。

オプションで、オリジナル・ルーチンＲが決定論的なイベントを記録することのみが予想（envisage）される場合、これに対応する改定済みルーチンＲＭは、ロギングまたはリプレイ・プロセスへのいかなる呼び出しの提供も省略することができる同様に、オリジナル・ルーチンＲが非決定論的なイベントを実施することのみが予想される場合、その改定済みルーチンＲＭは、ロギングまたはリプレイ・プロセスへの系統的呼び出しを含むことができる。したがってロギング時に、決定論的性質をテストするためのステップ４（図１１）は、受け取られる呼び出しのタイプによって、または呼び出しが受け取られたという事実によってすら、暗黙的に生成することができる。

アプリケーションのタイプまたはその実行の条件に応じて、所与のタイプの内部イベントが決定論的であるか否かの可能性がある場合、改定済みルーチンＲＭは、そのプロローグまたはそのエピローグあるいはその両方に、このアプリケーションのタイプまたは実行の条件を評価する命令を含むこともできる。

シーケンス番号ＳＱの使用は、オプションとすることもできる。このケースでは、ロギング・プロセスＰｌｏｇＯＰ（図１１）は、イベントＥＶＩが非決定論的タイプである場合、結果データを記憶することに限定される。その一部について、リプレイ・プロセスＲＰＩ（図１２）は、次にロギングされた結果ＲＬｉの読み取りに限定され、これが非決定論的であるとして検出される次のイベントＥＶＩに対して強制されるものとみなされる。

さらに、最適化のヒューリスティックまたは予測的方法は、すべての内部非決定論的イベントを系統的にロギングしないことができる。この方法は、単独で、または他の最適化方法との組み合わせで、実装することができる。

ロギングおよびリプレイ・オペレーションの時間に関するコストが原因で、特に、ノード内部のオペレーションに関して、ロギング・オペレーションの数を削減することができるのであれば、ある数の追加の内部オペレーションを実施することが有用な場合がある。

このヒューリスティック最適化技法は、結果を予測すること、およびマスタ・アプリケーションのオペレーション時に検出された内部イベントのすべてまたは一部にわたって適用することによって動作する、中間アプリケーションによる、ヒューリスティック圧縮の実施を含む。

オペレーション・ノードへのロギング時に、このヒューリスティック圧縮は、たとえば内部ロギング・プロセスＰｌｏｇＯＰによって実施することが可能である。

図１３は、このヒューリスティック圧縮ＣＨを使用する、非決定論的イベントのロギングの機能を示す。

Ｐ１プロセスがＪＯＰ被ロギング・ランを介して実行される間、命令の実行は、ＳＥＭ１セマフォなどの共有リソースに適用される非決定論的タイプの内部イベントＥＶＩｎＤを実施する。

ステップ１では、ロギングされることになるイベントＥＶＩｎＤに対応する改定済みルーチンＲＭｎＤは、ロギング・プロセスＰｌｏｇＯＰを通知または開始し、このプロセスが当該イベントＥＶＩｎＤの発生を検出する。

ステップ２では、イベントＥＶＩｎＤに対応する改定済みルーチンＲＭｎＤは、ＳＥＭ１セマフォ上で、オリジナル・ルーチンＲｎＤで予想されるオペレーションを実施し、被ロギング・プロセスＰ１にアドレス指定された結果データＤＲを受け取るかまたは計算する。

ステップ３では、プロセスＰｌｏｇＯＰは、イベントＥＶＩｎＤの検出によって、含まれるＳＥＭ１リソースに対応するロギング・シーケンス番号ＳＱを増分する。

有利なことに、当該シーケンス番号ＳＱは、１次ノードＯＰ内の作業メモリ内に格納される。したがって、その管理は、結果データを２次ノードに送ることに比べて、または永続メディア上のログ・ファイルに格納することに比べて、非常に低いオーバヘッドを表す。

ＳＥＭ１セマフォおよびそのログＪＳＥＭ１に関連付けられたこのシーケンス番号ＳＱの増分により、結果データＤＲの系統的格納が表すことになるオーバヘッドを避けながら、予測機能ＦＨによって正しく予測された非決定論的イベントＥＶＩｎＤの受け渡しの記録を可能にする。

ステップ４では、プロセスＰｌｏｇＯＰは、予測結果ＲＰの形で、この内部イベントＥＶＩｎＤの結果の予測を含む、ソフトウェア・オペレーションＦＨを実施する。好ましいことには、この予測は、被ロギング・プロセスＰ１の状態またはこのイベントＥＶＩｎＤ以前のマスタ・アプリケーションの状態に基づいて、１つまたは複数の決定論的機能によって構成される、決定論的ソフトウェア・プロセスである。

ステップ５では、プロセスＰｌｏｇＯＰは、予測結果ＲＰと、検出されたイベントＥＶＩｎＤの実行ＲｎＤから出力された実結果ＤＲとを比較する。

ステップ６では、２つの結果ＤＲおよびＲＰが異なる場合、ＰｌｏｇＯＰプロセスは、実結果ＤＲと対応するシーケンス番号ＳＱの値とを、２次ノード・プロセスＰｌｏｇＳＢに転送し、ここで、それらを関連付けることによって、当該リソースＳＥＭ１に対応するログ・ファイルＪｓｅｍ１内の次の行として記憶される。

このステップの際に、当該ＳＥＭ１リソースをロギングするためのシーケンス番号ＳＱの再初期化を予想することが可能である。この場合、シーケンス番号ＳＱは、結果がロギングされた最後のイベント以降に正しく予測されたイベントの数を表す。

被ロギング・プロセスＰ１に関する一連の内部イベントの完了時に、ＪＳｅｍ１ログは、シーケンス番号を含むイベントに関するシーケンス番号に関連付けられた、ＳＥＭ１セマフォによって当該Ｐ１プロセスに送られ、予測機能ＦＨによって正しく予測されなかった、すべての結果データの順序付けセットを含む。

内部イベントのロギングがこうしたヒューリスティック最適化を使用して実施された場合、中間アプリケーションは、２次ノードでのリプレイの際にヒューリスティック圧縮解除を実施する。このヒューリスティック圧縮解除は、圧縮に使用されたものと同一の予測を使用し、ヒューリスティック圧縮でのロギング時と同じイベントに適用される。

図１４は、ＳＥＭ１セマフォに適用されるログＪＳｅｍ１に基づいて、内部リプレイ・プロセスＰＲＩ（図８を参照）によって制御される、再始動プロセスＰＢ１の受動リプレイにおける、このヒューリスティック圧縮解除ＤＨを使用した、非決定論的イベントに関するリプレイ・オペレーションを示す。

ＪＳｅｍ１ログからのイベントのリプレイ時に、命令の実行は、ＳＥＭ１セマフォに適用する非決定論的タイプの内部イベントＥＶＩｎＤを実施する。

ステップ１では、リプレイされるイベントＥＶＩｎＤに対応する改定済みルーチンＲＭｎＤは、リプレイ・プロセスＰＲＩを通知または開始し、このプロセスがこのイベントＥＶＩｎＤの発生を検出および識別する。

ステップ２では、イベントＥＶＩｎＤに対応する改定済みルーチンＲＭｎＤは、ＳＥＭ１セマフォ上で、オリジナル・ルーチンＲｎＤで要求されたオペレーションを実施し、実際のリプレイ結果ＰＲＪに対応する結果データを受け取るかまたは計算する。改定済みルーチンＲＭｎＤは、リプレイ・プロセスＰＢ１の実行を中断する。次に、当該結果ＰＲＪを再始動プロセスＰ１に転送するため、およびその実行を継続させるために、リプレイ・プロセスＰＲＩからの信号を待つ。

ステップ３では、プロセスＰＲＩは、セマフォＳＥＭ１に対応するシーケンス番号ＳＱの値を読み取り、これを増分する。

ステップ４では、内部リプレイ・プロセスＰＲＩは、このシーケンス番号ＳＱと、この同じリソースＳＥＭ１に対応するログ・ファイルＪＳｅｍ１に格納されたものからまだリプレイされていない、次のシーケンス番号ＳＱｉとを比較する。

ステップ５では、これらのシーケンス番号ＳＱおよびＳＱｉが対応する場合、内部リプレイ・プロセスＰＲＩは、このシーケンス番号にＳＱｉについてこのログに格納された結果ＲＬｉを読み取り、これを検出されたイベントＥＶＩｎＤによって戻される強制結果ＲＦとして格納する。次に、内部リプレイ・プロセスＰＲＩは、ログＪＳｅｍ１内の行ＳＱｉによって表されるイベントがリプレイされた旨の事実を格納し、次に検出されるイベントの処理のためにこの同じログの次の行ＳＱｊを活動化させる。

このステップでは、当該ＳＥＭ１リソースをリプレイするためにシーケンス番号ＳＱの再初期化を予想することが可能である。

ステップ６では、これらのシーケンス番号ＳＱおよびＳＱｉが対応しない場合、内部リプレイ・プロセスＰＲＩは、予測結果ＲＰＪの形の、この内部イベントのロギング時に生成されたものと同じ結果予測を含む、ソフトウェア・オペレーションＦＨを実施する。内部リプレイ・プロセスＰＲＩは、その後、この予測の結果ＲＰＪを、検出されたイベントＥＶＩｎＤによって戻される強制結果ＲＦとして格納する。

ステップ８では、内部リプレイ・プロセスＰＲＩは、強制結果ＲＦを改定済みルーチンＲＭｎＤに転送し、内部イベントＥＶＩｎＤによって戻される実際のリプレイされた結果ＲＲＪに代わって、再始動プロセスＰＢ１に賦課（impose）される。その後、改定済みルーチンは、再始動プロセスＰＢ１にその実行を続行させる。

オプションで、この事前設定に先行して、これら２つの結果ＲＲＪおよびＲＦを比較するためのテスト・ステップ７を実行し、これらの結果が対応する場合は再始動プロセスＰＢ１での動作を避けることができる。

予測最適化のこの方法で使用される順序付けデータＳＱの識別は、前述のもの（図１１および図１２）と異なる変数で構成可能であるか、またはこれらと併せて編成および処理可能であることに留意されたい。

したがって、すべての非決定論的イベントの結果をロギングすることなく、非決定論的イベントを忠実かつ正確に記録およびリプレイできることが明らかである。この場合、ロギング時にターゲット・プロセスＰ１のそれに忠実な再始動プロセスＰＢ１のリプレイ・ランの実行を保証しながら、これらのロギングおよびリプレイ・オペレーションを最適化することが可能である。

ロギング・オペレーションとノード内部での単純な計算オペレーションとの間の速度の差を考えると、たとえ使用される予測機能が非常に高い成功率を持たない場合であっても、このヒューリスティック最適化技法は有用な可能性がある。この差が大きい場合、５０％未満の予測成功率でも有用な最適化を可能にすることができる。

このヒューリスティック最適化技法は、単一のイベントまたは内部イベントのグループをロギングした後、これらをリプレイするために、同じ機能が使用される場合、いくつかの異なる予測機能を使用することも可能である。使用する予測機能の選択は、たとえば、知識データベースまたは規則から始まる、アプリケーションの状態またはその環境に従って実行することができる。この変更は、中間アプリケーションによって格納されたロギング・データに格納することができる。このヒューリスティック最適化技法は、ロギング時にその成功率を評価することによって、およびこの成功率の値またはその変化に基づいて当該機能の変更を開始することによって、自動的に適応するように（auto-adaptively）使用することも可能である。

このヒューリスティック最適化技法で使用される予測機能の一例に、異なるクライアントからの内部イベントの順序に基づいた、内部イベントの発生順序の予測が含まれる。

図１５および図１６は、それぞれ３つの異なるクライアントによって起動される３つのタスクＴａ、Ｔｂ、Ｔｃを実行する、それぞれ「ａ」、「ｂ」、および「ｃ」と格付けされた識別子を備える、３つのプロセスＰｒｏｃＡ、ＰｒｏｃＢ、ＰｒｏｃＣに参加する、外部および内部イベントの発生を示す。これら様々なタスクは、それぞれ、たとえば第１の外部イベントＥａ１、Ｅｂ１、Ｅｃ１と、第２の外部イベントＥａ２、Ｅｂ２、Ｅｃ２とを含む。これら第１と第２の外部イベントの間に、これらタスクそれぞれが、２つの内部非決定論的イベントの開始を含む。図１５および図１６では、タスクＴａに関する連続する内部イベントはＩａ１およびＩａ２と呼ばれ、タスクＴｂのそれらはＩｂ１およびＩｂ２と呼ばれ、タスクＴｃのそれらはＩｃ１およびＩｃ２と呼ばれる。これらの内部イベントＩａ１からＩｃ２は、互いに異なるか、または、たとえば単一セットの共有メモリ領域へのロック割り振りなどの、単一の決められたリソースを含むことができる。

ほぼ同時のタスク時、および特にそれらが同様または共通の部分を有するか、または同様の実行時間を有する、あるいはその両方である場合、予測機能は、中間内部イベントＩａ１、Ｉｂ１、Ｉｃ１の発生順序が、それらに先行する外部イベントの発生順序と同じになるという予測からなる。

マスタ・アプリケーションが実行している間、オペレーション・ノードＯＰ上での第１の外部イベントＥａ１、Ｅｂ１、Ｅｃ１の発生順序は、たとえば内部ロギング・プロセスＰｌｏｇＯＰで、中間アプリケーションによって記録される。たとえばこの外部イベントの順序は、これら外部イベントに関連付けられたプロセスの一連の識別子または一連の値「ａ ｂ ｃ」を含む。

このリソースに関する新しい内部イベントが検出されるごとに、予測機能は、この内部イベントの結果、すなわちこのリソースにわたってロックを取得することになるプロセスの識別子、すなわち、これを要求したばかりのもの、を予測する。次にこの予測された結果は、このリソースにわたってロックを取得した最後のプロセスの識別子と、外部イベントのこの順序とを比較することによって計算される。

したがって予測機能は、それぞれが破線で示され、その結果が右端に示されている、予測Ｐｅ１からＰｅ６のセットを作成する。

図１５は、内部イベントが外部イベントの順序に従う場合に、これらの内部イベントの各発生に対して行われる予測の値を示す。外部イベントの順序「ａ ｂ ｃ」から、および発生した最後の内部イベントから、予測機能は、６つの文字のみで示される一連の値「ａ ｂ ｃ ａ ｂ ｃ」を形成する予測を行う。ヒューリスティック最適化のコンテキストでは、内部ロギング・プロセスＰｌｏｇＯＰは、内部イベントが予測機能によって正しく予測されているため、これら内部イベントについてのロギング・データを転送するための要件を持たない。

図１６は、内部イベントが外部イベントの順序に従わず、「ｂ」を識別するためのプロセスＰｒＢのタスクＴｂが、他の２つのタスクよりも高速に実行されている場合に、これらの内部イベントの各発生に対して行われる予測の値を示す。外部イベントの順序「ａ ｂ ｃ」から、および発生した最後の内部イベントから、予測機能は、一連の値「ａ ｂ ｃ ｃ ａ ｂ」を形成する予測を行う。これは、２つの予測Ｐｅ３およびＰｅ６が偽として示され、これによって内部ロギング・プロセスＰｌｏｇＯＰが２つの発生時にロギング・データを転送することを表す。したがってこのロギング・データは、不正確として示された第３の予測Ｐｅ３の完了時の、伝送Ｌ１における値「ｃ」、および次に、同様に不正確として示された第６の予測Ｐｅ６の完了時の、伝送Ｌ２における値「ｃ」を含む。

これらの不正確な予測Ｐｅ３およびＰｅ６にもかかわらず、このヒューリスティック最適化は、内部ロギング・プロセスＰｌｏｇＯＰが、不在時に発生した６つではなく２つの伝送Ｌ１およびＬ２のみに影響を与えることが可能であることが明らかである。６つのうち４つの伝送を節減することで、この最適化技法を実施するために必要な内部計算およびオペレーションの場合よりもかなり大量の作業時間を表し、したがって特にオペレーション・ノードでの性能をかなり向上させることができる。

さらに、オペレーティング・システムによる標準実施によって、非決定論的動作を生成することになるいくつかの内部イベントでは、セマンティクスの変更による最適化技法を使用することが可能である。この技法は、決定論的動作を与えるために、ノードにおけるこうしたイベントの実施に対する改定を含む。中間アプリケーションは、オペレーション・ノードおよび２次ノードにおいてこの改定を同一にし、それによってこれら変更された内部イベントの結果を予測可能にする。実施に対するこの改定は、ルーチンＲを実施するオリジナル・イベントを、このイベントに対して改定済み動作を実施する改定済みルーチンＲＭに置き換える、「メタプロセス」を通じた介入技法によって動的に実行されることになる。この改定を実施するために使用される技法は、プロローグおよびエピローグにレコーディング・プローブを追加するための前述の技法（図９を参照）と同様であるが、改定済みルーチンに関する中央部分のコードへの改定を含むことができる。この実施改定は、マスタ・アプリケーションに対してトランスペアレントに生成され、オペレーティング・システムの既存の要素は変更しない。これらの改定済みルーチンのうちの１つをマスタ・アプリケーションで、または少なくとも所定のおよび格納された実行間隔にわたって使用することによって、当該変更されたイベントの結果を格納する必要なしに、マスタ・アプリケーションの進化をロギングすることが可能である。同じ改定済みルーチンを、リプレイ・アプリケーションを実行する場合と同じ間隔にわたって使用することで、マスタ・アプリケーションの再現性を維持し、同時に、ロギングおよびリプレイの性能を向上させることができる。

この改定済み動作は、たとえば、オリジナル・ルーチンがいくつかの異なる結果を送信できた所与の状況から、改定済みルーチンが、オリジナル・ルーチンによって提供可能であった、マスタ・アプリケーションおよびオペレーティング・システムによって予想される結果のみを提供するように計画することによって、オリジナルの動作と同じ仕様に準拠し、これに完全に適合できるように設計される。

セマンティック変更による最適化のこの技法は、再始動アプリケーションの復元時にリプレイできるように、その結果をオペレーション・ノードにログしなければならない、非決定論的内部イベントの数を削減することができる。

異なる当事者のオペレーションおよび対話の一例が、図２２に図示される。

たとえばシステム・ソフトウェア内の処理エージェントは、結果ＤＲをプロセス、たとえば被ロギング・プロセスＰ１に転送する、オペレーションを実施する。特に内部の多くのオペレーションまたはイベントについて、当該オペレーションは、決定要素（determinant）と呼ばれるリソースのセットＲＤｅｔと比べて本質的に決定論的な、オペレーション・プロセスＴＯによって実施される。

プロセスＰ１がアクセス可能なリソースからいくつかを、このプロセスＰ１の状態についての知識から再現可能リソースＲＲｅｐｒと呼ぶことができる。当該再現可能リソースは、特に、状態が排他的にこれに依存するリソースを含む。

処理エージェントＡＴのオペレーションにおいて、ＴＯオペレーションの処理は、たとえば当該再現可能リソースからのＤＥＲデータのみを使用することから、プロセスＰ１の再現可能リソースＲＲｅｐｒに関して決定論的である、処理部分ＴＤを含むことができる。

オペレーション・プロセスＴＯが、プロセスＰ１の再現可能リソースＲＲｅｐｒに含まれないＳＥＭ１からの個人データを使用する処理の他の部分を含む場合、これはこのＴｎＤ部分の結果とって一般的であるため、すべてのＴＯ処理は、これを呼び出す処理Ｐ１に関して決定論的でない。

こうした状況において、このセマンティック変更技法は、この改定の結果として生じるオペレーションが、再現可能リソースＲＲｅｐｒと比べて決定論的であるように、処理エージェントの動作またはこれが使用または生成するデータを改定するために、管理エージェントＡＧを使用することから構成される場合がある。

この管理エージェントは、ＴＯオペレーティング・プロセスの内部オペレーションを改定するために、機能修正処理ＴＭＦを使用する。

当該同一プロセスＰ１に対して非決定論的ソースを構成することができる結果ＤＲに対する変動を補償するために、決定要素リソースＲＤｅｔから出力されるがプロセスＰ１に関して再現可能（ＲＲｅｐｒ）ではない、入力データＤＥを使用することもできる。こうした補償は、入力データＤＥを補償済み入力データＤＥＣに修正するＴＣ１によって、または結果データＤＲを補償済み結果データＤＲＣに修正するＴＣ２によって、実施することができる。

この管理エージェントＡＧは、グローバル処理ＡＴおよびＡＧの効率を最適化するために、１つまたは複数のセマンティック変更パラメータＰＣＳに応じて、実行した修正ＴＭＦ、ＴＣ１、ＴＣ２を選択または調整（regulate）することもできる。ロギングＪＯＰとリプレイＲＳＢとの間の再現性を維持するために、このセマンティック変更パラメータＰＣＳに対する変動が、再現可能リソースＲＲｅｐｒからのデータによってのみ決定されること、またはその変動がロギング時にログＵＬ、ＫＬに格納され、リプレイＲＳＢ時に同じ方法で読み取りおよび適用されることで、十分である。

この動作の変化は、特に、所与のリソースについて競合するいくつかのプロセスの管理に影響を与える局面に関する可能性がある。

図１７および図１８は、Ｕｎｉｘ（登録商標）タイプの環境において「ｒｅａｄ（読み取り）」ルーチンを使用することにより、受け取ったメッセージを読み取るために、オペレーションを決定論的にするための、セマンティック変更によるこの最適化技法の使用例を示す。

その標準実装では、アプリケーションによって開始された「ｒｅａｄ」ルーチンが、入力チャネルＩＣＨ内のメッセージを読み取り、これらを当該アプリケーションに転送するために、バッファ・メモリＢのゾーンを使用する。メッセージは、システム内で連続データの形で受け取られる、これらのデータは、着信した際に入力チャネルを形成するメモリ・ゾーン内に格納される。その構成によれば、「ｒｅａｄ」オペレーションは異なるサイズのバッファを使用することができるが、このバッファは全体として入力チャネルでの各読み取りに使用される。

この例では、アプリケーションは、入力チャネルＩＣＨを介して連続的に着信する３つのメッセージＭ１、Ｍ２、Ｍ３を受け取るために、サイズ「５０」のバッファＢに対して一連の「ｒｅａｄ」オペレーションを使用する。これら３つのメッセージは、それぞれ「２０」、「３０」、および「５０」に等しいデータ・ボリュームを表す。しかしながら、一方ではデータが入力チャネル内で着信する速度、および他方では読み取りオペレーションの速度が、ロギングまたはリプレイの段階では予測不可能なように、互いに異なる場合がある。

図１７は、オリジナルの「ｒｅａｄ」ルーチンを使用して同じ３つのメッセージを読み取るための、２つの異なる可能なシナリオを示す。

最初のシナリオＳＣＡでは、サイズ「２０」の第１のメッセージＭ１からのデータのみが着信したため、第１の読み取りＲＡ１が行われる。バッファＢは完全には満たされず、オペレーションはコンテンツ「Ｍ１」およびデータ・サイズ「２０」に対応する結果を戻す。次に、第２のメッセージＭ２のみが着信した後に、第２の読み取りＲＡ２が行われ、コンテンツ「Ｍ２」およびデータ・サイズ「３０」に対応する結果を戻す。次に、第３のメッセージＭ３の着信後、第３の読み取りＲＡ３が行われ、コンテンツ「Ｍ３」およびデータ・サイズ「５０」に対応する結果を戻す。たとえば、アプリケーションによって受け取られたデータのサイズについては、この第１のシナリオＳＣＡは「２０、３０、および５０」に等しい３つの結果のセットを戻す。

第２のシナリオＳＣＢでは、同じ第１および第２のメッセージＭ１、Ｍ２がすでに着信したとして第１の読み取りＲＢ１が行われ、コンテンツ「Ｍ１、Ｍ２」およびデータ・サイズ「５０」に対応する結果を戻す。次に、第３のメッセージＭ３の到着後、第２の読み取りＲＢ２が行われ、コンテンツ「Ｍ３」およびデータ・サイズ「５０」に対応する結果を戻す。アプリケーションによって受け取られたデータのサイズについては、この第２のシナリオＳＣＢは、同じメッセージの読み取りに関する「５０、５０」に等しい２つの結果のセットを戻す。

したがってこれら２つのシナリオは、一方は「２０、３０、５０」および他方は「５０、５０」の、異なる結果を戻す。ここで「ｒｅａｄ」オペレーションを実施する標準的なシステム・ルーチンは、マスタ・アプリケーションのロギングならびに再始動アプリケーションのリプレイについて、アプリケーションの観点から非決定論的なイベントを実施する。

図１７と同じ状況で、図１８は、オリジナルの「ｒｅａｄ」ルーチンの代わりに改定済み「ｒｅａｄＭ」ルーチンを使用することによって得られる、単一のシナリオＳｃＵを表す。

この例では、改定済みルーチンは受け取られる各メッセージの実際の長さを認識し、たとえバッファＢが満杯でなく、入力チャネルＩＣＨ内で読み取るデータが依然として存在する場合であっても、単一のメッセージに対応するデータのみを入力チャネルＩＣＨ内で読み取る。マスタ・アプリケーションのロギングの場合、改定済みルーチンは、これら同じメッセージの受け取りに対応する外部イベント・ロギング・メカニズム、たとえばＩＰｌｏｇＯＰモジュールを使用して、メッセージＭ１、Ｍ２、Ｍ３の実際の長さを認識する。再始動アプリケーションが復元中のリプレイの場合、改定済みルーチンは、これら同じメッセージの受け取りに対応する外部イベント・リプレイ・メカニズム、たとえばＩＰｌｏｇＳＢモジュールを使用して、メッセージＭ１、Ｍ２、Ｍ３の実際の長さを認識する。

このようにして、これら２つの異なる着信シナリオＳＣＡ、ＳＣＢは、アプリケーションによって受け取られるデータのサイズに関して「２０、３０、５０」に等しい３つの結果の単一セットの発生時に、読み取りオペレーションに対して単一の動作を与える。

同様に、バッファＢの他のサイズについて、異なる結果セットを生成するオリジナルの「ｒｅａｄ」ルーチンが可能である。

したがって、バッファ・サイズ「２０」の場合、以下の結果、たとえば「２０、２０、２０、２０、２０」または「２０、２０、１０、２０、２０、１０」を得ることができる。

バッファ・サイズ「１００」の場合、以下の結果、たとえば「２０、３０、５０」または「５０、５０」または「２０、８０」、または「１００」を得ることができる。

他方で、各バッファ・サイズについて、改定された「ｒｅａｄＭ」ルーチンは単一の結果セットしか与えることができない。

したがって、バッファ・サイズ「２０」の場合、得られる結果セットは「２０、２０、１０、２０、２０、１０」となる。

バッファ・サイズ「１００」の場合、得られる結果セットは「２０、３０、５０」となる。

したがって改定された「ｒｅａｄＭ」ルーチンは、こうした読み取りオペレーションに対応する内部イベントのための決定論的動作を実施する。

図１９から図２１は、キューイング・ループを実施するアプリケーション・プロセスによって開始され、特にいくつかのファイル記述子に関連付けられたいくつかの入力／出力（Ｉ／Ｏ）チャネルからデータを受け取ることが可能な、決定論的な多重化読み取りオペレーションを行うために使用される、セマンティック変更によるこの最適化技法の他の使用例を示す。この例は、Ｕｎｉｘ（登録商標）タイプの環境における「ｓｅｌｅｃｔ（選択）」ルーチンの使用に基づくものであるが、「ｐｏｌｌ（ポーリング）」ルーチンの使用にも適用可能である。

この例では、２つの異なるチャネルＩＣＨ１、ＩＣＨ２にアドレス指定された、それぞれ「ａ」、「ｂ」、および「ｃ」に等しいコンテンツを備えた３つのメッセージＭ１、Ｍ２、Ｍ３が、ノード・オペレーティング・システムＯＳによって受け取られる。

この例は、特に、第１のチャネルＩＣＨ１による「ストリーム」の形でのデータ、および第２のチャネルＩＣＨ２によるＴＣＰタイプのメッセージまたはパケットの形でのデータの、受け取りに適用可能である。オペレーティング・システムＯＳでは、２つのＴＣＰパケットと、それに続く「ストリーム」パケットが、それぞれ「ａ」、「ｂ」、および「ｃ」に等しいコンテンツを備えた３つの連続するメッセージＭ１、Ｍ２、Ｍ３として受け取られる。

これらをその作業負荷に従って受け取る場合、オペレーティング・システムＯＳは、チャネルＩＣＨ１、ＩＣＨ２内のこのデータを、それらのタイプに応じて処理および分配する。その実行中の所与の瞬間に、アプリケーションは、「ｓｅｌｅｃｔ」ルーチンを呼び出して、メッセージを受け取る際に介することができる異なるチャネルに対して読み取りオペレーションを開始する。

その標準的な実施において、「ｓｅｌｅｃｔ」ルーチンは、第１のチャネルＩＣＨ１内の、およびそれに続く第２のチャネルＩＣＨ２内の、キューイング・データを読み取り、これを即時に、それらを読み取った順序でアプリケーションに転送する。

ここで、一方ではオペレーティング・システムＯＳ内でデータが着信する速度、オペレーティング・システムによるその処理速度、および入力チャネル内でのその着信速度、ならびに他方では、一連の読み取りオペレーションのアプリケーションによる実行速度は、ロギングまたはリプレイの段階では予測できないようにそれぞれ異なる可能性がある。

図１９に示された第１のシナリオＳＣＡでは、アプリケーションは、２つの入力チャネルＩＣＨ１、ＩＣＨ２内に３つのメッセージがすでに着信しているため、第１の瞬間ＩＡで「ｓｅｌｅｃｔ」ルーチンによって多重化読み取りを開始する。「ｓｅｌｅｃｔ」ルーチンはデータを読み取る場合、第１に、第１のチャネルＩＣＨ１内に含まれる３番目のメッセージを読み取り、次に、第２のチャネルＩＣＨ２内の最初の２つのメッセージＭ１、Ｍ２を読み取る。次に「ｓｅｌｅｃｔ」ルーチンは、このデータを読み取り順に転送するため、読み取りオペレーションはデータ・セット「ｃ、ａ、ｂ」を含む結果を生成する。

図２０に示された第２のシナリオＳＣＢでは、アプリケーションは、第２の入力チャネルＩＣＨ２内に最初の２つのメッセージしか着信していないため、第１の瞬間ＩＢで「ｓｅｌｅｃｔ」ルーチンによって多重化読み取りを開始する。「ｓｅｌｅｃｔ」ルーチンはデータを読み取る場合、第２のチャネルＩＣＨ２内の最初の２つのメッセージＭ１、Ｍ２のみを読み取り、このデータを読み取り順に、すなわちセット「ａ ｂ」で、アプリケーションに転送する。次の読み取り時に、第３のメッセージＭ３が第１のチャネルＩＣＨ１内に着信した後、「ｓｅｌｅｃｔ」ルーチンはこの第３のメッセージを読み取り、これをアプリケーションに転送する。当該第２のシナリオＳＣＢでは、オリジナルの「ｓｅｌｅｃｔ」ルーチンによる読み取りオペレーションはデータ・セット「ａ、ｂ、ｃ」を含む結果を生成する。

これら２つの異なるシナリオＳＣＡ、ＳＣＢは、一方については「ｃ、ａ、ｂ」、他方については「ａ、ｂ、ｃ」という、異なる結果を戻す。ここで、「ｓｅｌｅｃｔ」オペレーションを実施する標準システム・ルーチンは、マスタ・アプリケーションのロギングならびに再始動アプリケーションのリプレイについて、アプリケーションの観点から非決定論的なイベントを実施する。

図１９および図２０と同じ状況について、図２１は、オリジナルの「ｓｅｌｅｃｔ」ルーチンの代わりに改定された「ｓｅｌｅｃｔＭ」ルーチンを使用することによって得られる、単一の結果を表す。

この例では、改定済みルーチンは、メッセージがオペレーティング・システムＯＳ内に着信する順序を認識し、着信した順序でメッセージを読み取る。さらに、あいまいさのリスクを低減させるために、改定済みルーチンは毎回単一のファイル記述子のみを送信する。改定済みルーチンは、たとえば入力チャネルＩＣＨ１、ＩＣＨ２内のメッセージのコンテンツを検査することによって、あるいはロギングまたはリプレイ・データから、メッセージが着信する順序に関する情報を取得することができる。

このようにして、これら２つの異なる着信シナリオＳＣＡ、ＳＣＢは、多重化読み取りオペレーションに単一の動作、結果として「ａ ｂ ｃ」に等しい３つの結果の単一セットを与える。

決定論的にするための標準の環境で、決定論的でなかった内部イベントの動作を実施する一定のルーチンのオペレーション方法をこのように改定することにより、非決定論的イベントの数が削減されることが明らかである。この改訂が、マスタ・アプリケーションでのロギング時と、再始動アプリケーションでのリプレイ時に、まったく同様に適用される場合、リプレイの完了時に、マスタ・アプリケーションの状態に対応する状態にあるか、当該マスタ・アプリケーションとの満足できるオペレーションの連続性を有する、再始動アプリケーションを、取得可能にするためにロギングしなければならないイベントの数が削減される。

したがって、セマンティック変更によるこの最適化技法は、ロギングおよびリプレイ・オペレーションならびに中間アプリケーションの性能を向上させられることが明らかである。

実際、このセマンティック変更の技法が適用されるルーチンに従って、およびそれらに対して実行される改定の性質に従って、当該ルーチンにおける性能に、そのオリジナルの動作と比べてわずかな低下が発生する可能性がある。しかしながら、ロギング・オペレーションの速度低下を考えると、ロギングすることになるオペレーションの数に関して生じる節減により、中間アプリケーション内のマスタ・オペレーションの全体性能が大幅に向上できることになる。

この説明で、中間アプリケーションのメカニズムは、主に、オペレーション・ノードまたは２次ノードのユーザ・スペース内で実行されるプロセスまたはモジュールによって実施されることがわかる。これは特に、本明細書では、参照「Ｐｌｏｇ」（図２）、「ＩＰｌｏｇＯＰ」および「ＩＰｌｏｇＳＢ」（図３）、「ＰｌｏｇＯＰ」および「ＰｌｏｇＳＢ」（図４）、「ＰＲＥ」（図７）および「ＰＲＩ」（図８）、「ＭＥＴＡ」（図９）の下の中間アプリケーションＩＮＴ（図１）で識別される、外部または内部の、ロギングまたはリプレイ・プロセスを意味する。

これとは対照的に、システム・スペース内で実行されるメカニズムは、とりわけ介入モジュール、またはアプリケーション・モジュールから管理される機能を追加または改定するためのモジュールを備える。これは特に、本明細書では、参照「ＤＩＳＰ」（図３）、および「ｉｐｆｉｌｔｅｒ」（図７）の下で識別される、モジュールを意味する。一定のこれらカーネル・モジュールは、必要に応じて、アプリケーション・モジュールからロードまたはアンロードすることも可能である。

中間アプリケーションの実行および「存続（life）」がユーザ・スペース内で生じるという事実により、異なるノードのオペレーティング・システムとの対話を制限することができる。この特徴は、特に、配置および管理における柔軟性、オペレーティング・システムに対するある種の独立性、およびそれらの任意の異機種混合性を提供し、タイプまたは解放の非互換性のリスクを制限し、関連しないノードのシステム・スペースにおいて、またはそれほどではなくとも当該中間アプリケーションの配置において、介入を制限することができる。このオペレーティング・システムに対する独立性は、システム・スペースの既存の要素への過大な介入を避けること、ならびに、これらのオペレーティング・システムおよびそれらを管理する組織の政策への指定および変更に対するある種の商業的および技術的な独立性を維持することによって、開発時間およびコストを制限することもできる。

前述の中間アプリケーションは、ユーザまたはクラスタの管理者に、他のアプリケーションに関するサポートまたは管理サービスを提供するために、様々な方法で、および様々な組み合わせに従って、実施可能である。こうしたサービスは、特に、「ミドルウェア」のネットワーク・ソフトウェア製品の形で取得することが可能であり、クラスタにおける、オリジナル版（「レガシー」）の１つまたは複数のアプリケーションの管理、最適化、または信頼性の向上を可能にすると同時に、たとえばクラスタの性質に適合される、柔軟性あるいは追加のセキュリティまたは耐障害性の機能を提供する。

こうした中間アプリケーションの使用は、とりわけ、これらのアプリケーションによってクライアントに提供されるサービスを確保する形を取ることができる。したがって各アプリケーションは、マスタ・アプリケーションとして扱うこと、および、必要に応じてそのクライアントに対するマスタ・アプリケーションを置き換えるために、再始動アプリケーションの形で復元することが可能である。

所与のノードのすべてまたは一部で実行中のアプリケーションによって提供されるサービスは、オリジナルのノードを完全に解放することによって、動的にまたはオンデマンドで、１つまたは複数の他のノードに移行することもできる。したがって、保守、試行、アップグレード、または置換のいずれであっても、このノード上で望まれるすべてのハードウェアまたはソフトウェアの介入を実施することが可能となる。

こうした中間アプリケーションを使用して、特に、ネットワークにおける能力、可用性、またはその地理的状況、たとえばそのクライアントまたは使用されるデータからの遠隔性に従って、異なるハードウェアの使用を最適化するために、特に、異なるノード間で作業負荷を分散する（負荷平準化）のための機能を備える、「ミドルウェア」タイプの環境を実装することができる。

本発明はこれまで説明してきた例に限定されるものではなく、本発明の枠組みを逸脱することなく多数の改定が実行可能であることは明白である。

本発明を実施する中間アプリケーションの機能アーキテクチャを示す記号図である。 オペレーション・ノードにイベントをロギングするための機構を要約した記号図である。 オペレーション・ノードおよび２次ノード上のそのバックアップからの、外部イベントのロギングのオペレーションを示す、記号図である。 オペレーション・ノードおよび２次ノード上のそのバックアップからの、内部イベントのロギングのオペレーションを示す、記号図である。 一連の内部イベントからのロギング・データの集約伝送のためのメカニズムの、オペレーション・バージョンを示す図である。 一連の内部イベントからのロギング・データの集約伝送のためのメカニズムの、オペレーション・バージョンを示す図である。 ２次ノードで再始動アプリケーションを更新する間の、被ロギング外部イベントのリプレイ機能を示す記号図である。 ２次ノードで再始動アプリケーションを更新する間の、内部イベントのリプレイ機能を示す記号図である。 当該ルーチンの実行に補足命令を挿入するための、システム・ルーチンへの呼び出し時の介入技法の使用を示す記号図である。 ロギング時と同じ進行を取得するためにシステム・ルーチンへの補足命令の追加を使用する、２つの同時プロセスに関する内部イベントの進行を示す時間図である。 非決定論的イベントのみを処理するような内部イベントの、ロギング・オペレーションを示す図である。 非決定論的イベントのみを処理するような内部イベントの、リプレイ・オペレーションを示す図である。 ヒューリスティック圧縮による内部ロギングの最適化を示す図である。 ヒューリスティック圧縮解除による内部ロギングの最適化を示す図である。 オペレーション・ノード上のいくつかの同時プロセスにおける、２つの外部イベント間での内部イベントの異なるスケジューリング時の、ヒューリスティック圧縮による、非決定論的内部イベントのロギングの最適化の一例を示す記号図である。 オペレーション・ノード上のいくつかの同時プロセスにおける、２つの外部イベント間での内部イベントの異なるスケジューリング時の、ヒューリスティック圧縮による、非決定論的内部イベントのロギングの最適化の一例を示す記号図である。 「Ｕｎｉｘ（登録商標）」タイプのシステムにおける、「ｒｅａｄ」ルーチンによる読み取りオペレーションの非決定論を示す記号図である。 動的セマンティック変更によって決定論的となった、同じルーチンの一動作を示す記号図である。 「Ｕｎｉｘ（登録商標）」タイプのシステムにおける「選択」および「ポーリング」ルーチンによる、オペレーション・システムの２つの競合チャネルからのアプリケーションのデータ受け取りオペレーションの非決定論を示す、記号図である。 「Ｕｎｉｘ（登録商標）」タイプのシステムにおける「選択」および「ポーリング」ルーチンによる、オペレーション・システムの２つの競合チャネルからのアプリケーションのデータ受け取りオペレーションの非決定論を示す、記号図である。 動的セマンティック変更によって決定論的となった、同じルーチンの一動作を示す記号図である。 セマンティック変更によって使用される対話を示す図である。

Claims (19)

1. コンピュータ（ＳＢ）上でターゲット・プロセス（ＰＢ１）と呼ばれる少なくとも１つのアプリケーション・プロセスの実行のための方法であって、
   ロギング・データ（ＪＳｅｍ１）によって表される、被ロギング・オペレーションと呼ばれる少なくとも１つのオペレーションのターゲット・プロセスによって形成されるリプレイ（ＲＳＢ）を実施し、
   前記方法は、
   前記被ロギング・オペレーションに対応する被リプレイ・オペレーション（ＥＶＩ）と呼ばれるオペレーションを開始し、前記被リプレイ・オペレーション（ＥＶＩ）によって得られる結果を表す少なくとも１つのリプレイ結果データ（ＲＲＪ）を前記ターゲット・プロセス（ＰＢ１）に戻す、リプレイ命令と呼ばれる少なくとも１つのプログラム命令を、前記ターゲット・プロセスによって実行するステップと、
   前記リプレイ結果データ（ＲＲＪ）の代わりに前記ロギング・データから発行された強制データを前記ターゲット・プロセスが採用すること、および、前記被リプレイ・オペレーションに対して被ロギング結果（ＲＬｉ）と呼ばれる所与の結果を表すこと、を含む強制と呼ばれる処理を、再始動プロセス外部のソフトウェア・エージェント（ＰＲＩ）によって実施するステップと、
   前記リプレイ命令またはそれが開始する前記被リプレイ・オペレーション（ＥＶＩ）のインターセプト・ステップ（ＭＥＴＡ）であって、前記インターセプト・ステップ（ＭＥＴＡ）が、被ロギング結果（ＲＬｉ）を表すロギング・データを含むかどうかを検証するために、前記ロギング・データ（ＪＳｅｍ１）をテストするステップをさらに含み、前記被ロギング結果は前記被リプレイ・オペレーション（ＥＶＩ）に対応し、前記強制と呼ばれる前記処理は前記ログがそのような被ロギング結果（ＲＬｉ）を含む場合にのみ実行される、前記インターセプト・ステップ（ＭＥＴＡ）と、
   一連の被ロギング・オペレーションのリプレイ（ＲＳＢ）を実施することによって、少なくとも１つのターゲット・プロセス（ＰＢ１）を実行するために、一連の被ロギング・オペレーションを表す、ログ（ＵＬ、ＪＳｅｍ１）と呼ばれるロギング・データの順序付けセットを使用するステップと
   を含み、前記被ロギングと呼ばれるプロセス（Ｐ１）の実行の少なくとも一部で発生した、すべての被決定論的内部イベント（ＥＶＩｎＤ）のリプレイ（ＲＳＢ）を、少なくとも１つのターゲット・プロセス（ＰＢ１）によって実行する、前記方法。
2. 少なくとも１つの実行可能ファイル（ＥＸＥ）内の少なくとも１つのプログラム実行ポインタを移動させることによって、前記ターゲット・プロセス（ＰＢ１）が前記リプレイ命令を自発的に実行する、請求項１に記載の方法。
3. 前記被リプレイ・オペレーションが、一方で決定論的オペレーションを、および他方で非決定論的オペレーションを含み、
   前記強制と呼ばれる前記処理は前記決定論的オペレーションのうちの少なくとも１つに適用されない、
   請求項１に記載の方法。
4. 被ロギングと呼ばれるプロセス（Ｐ１）の実行時に実行される、少なくとも１つの所与のタイプのすべてのオペレーションを表すログ（ＪＳｅｍ１、ＵＬ）を使用し、
   前記ログは、前記被ロギング・プロセスのリプレイ（ＲＳＢ）を実行するターゲット・プロセス（ＰＢ１）を実行できるように設計されている、
   請求項１または２に記載の方法。
5. 所与のリソース（ＳＥＭ１）に関する、被ロギングと呼ばれるプロセス（Ｐ１）の実行時に実行される、少なくとも１つの所与のタイプのすべてのオペレーションを表すログ（ＪＳｅｍ１、ＵＬ）を使用し、
   前記ログは、前記所与のリソース（ＳＥＭ１）に関する前記被ロギング・プロセスのリプレイ（ＲＳＢ）を実行するターゲット・プロセス（ＰＢ１）を実行できるように設計されている、
   請求項１〜４のいずれか一項に記載の方法。
6. 前記ロギング・データ（ＪＳｅｍ１）をテストするステップが、前記ログ（ＪＳｅｍ１）が被ロギング結果（ＲＬｉ）を表すデータを含む、前記被ロギング実行でまだリプレイされていない第１のオペレーションのポジション（ＳＱｉ）に関して比較した、前記ターゲット・プロセス（ＰＢ１）の実行での前記被リプレイ・オペレーションのポジション（ＳＱ）に関する、請求項１〜５のいずれか一項に記載の方法。
7. 再始動プロセスと呼ばれる少なくとも１つのターゲット・プロセス（ＰＢ１、ＰＢ２）によって、前記被ロギング・オペレーションのリプレイを実行するために、被ロギング・リソース（ＳＥＭ１）と呼ばれる共有リソースに適用される少なくとも１つの所与のタイプのすべてのオペレーションを表すログ（ＪＳｅｍ１）を使用し、
   前記再始動プロセスは、前記被ロギング・リソースに対応するターゲット・リソース（ＳＥＭ１）と呼ばれるリソースにアクセスする、
   請求項１〜６のいずれか一項に記載の方法。
8. ターゲット・プロセス（ＰＢ２）によって少なくとも１つの被リプレイ・オペレーションに適用され、共用リソース・タイプの少なくとも１つのターゲット・リソース（ＳＥＭ１）の属性に関するプリエンプティブ要求を含み、
   前記強制と呼ばれる前記処理が、
   前記リソースに関してまだリプレイされていない次の被ロギング・オペレーション（＃１）の前記被ロギング結果（ｉｄ１）が、前記ターゲット・プロセス（ＰＢ２）に対する属性に対応するかまたは対応しないかを検証する、テスト・ステップと、
   前記テストの結果が否定である場合は必ず、前記ターゲット・プロセス（ＰＢ２）を保留し、肯定結果が得られるまで前記テストを反復するステップと
   を含む、請求項７に記載の方法。
9. 前記リプレイ命令が、前記実行可能ファイル（ＥＸＥ）外部のオリジナル（Ｒ）と呼ばれるルーチンへの呼び出しを含み、
   前記インターセプト・ステップ（ＭＥＴＡ）が、前記オリジナル・ルーチンの代わりに被修正（ＲＭ）と呼ばれるルーチンへの呼び出しを含み、
   前記被修正ルーチンが強制処理を実行または開始する、
   請求項１〜８のいずれか一項に記載の方法。
10. 前記被修正ルーチン（ＲＭ）が、ソフトウェア・システム（ＳＢＳ）内で実行される少なくとも１つの命令を含み、
    前記ターゲット・プロセス（ＰＢ１、ＰＢ２）のコンピュータのユーザ・メモリ・スペース（ＳＢＵ）内で実行され、前記ターゲット・プロセスによるリプレイの実施を管理する、リプレイ・エージェント（ＰＲＩ）と呼ばれる少なくとも１つのソフトウェア・エージェントへの呼び出しを含む、
    請求項９に記載の方法。
11. 前記被修正ルーチン（ＲＭ）が、これを呼び出した命令が、リプレイ（ＲＳＢ）のコンテキストで実行されるか否かを検証するためのテスト命令を含み、
    前記テストは前記リプレイ・エージェント（ＰＲＩ）への呼び出しに影響を与える、
    請求項９または１０に記載の方法。
12. 前記被ロギング・プロセス（ＰＩ）と呼ばれる少なくとも１つのアプリケーション・プロセスの機能の管理を実行し、
    前記方法が、
    ロギング・データ（ＵＬ、ＫＬ）の形で、再始動ポイントと呼ばれる所与のポイントから中断と呼ばれるポイントまでの、前記被ロギングと呼ばれるプロセス（Ｐ１）の実行時に発生した少なくとも１つの所与のタイプのイベントを表すデータを、記録（ＪＯＰ）および格納するステップと、
    前記被ロギングと呼ばれるプロセス（Ｐ１）の前記再始動ポイント状態に対応する状態の再始動プロセス（ＰＢ１）から、前記ロギング・データ（ＵＬ、ＫＬ）からの前記イベントを前記再始動プロセスによってリプレイ（ＲＳＢ）するステップであって、従って前記再始動プロセスを前記中断ポイントでの前記被ロギング・プロセスの状態に対応する状態にする、前記リプレイ（ＲＳＢ）するステップと
    を含む、請求項１〜１１のいずれか一項に記載の方法。
13. 前記ロギング・データ（ＵＬ、ＫＬ）が、再始動ポイントと呼ばれるその実行における所与のポイント以降に前記被ロギングと呼ばれるプロセス（Ｐ１）で発生する、１つまたは複数の所与のタイプのすべてのイベントを表し、
    前記リプレイ（ＲＳＢ）するステップが、被ロギング・プロセスの前記リプレイ・ポイント状態に対応する状態から始まる前記再始動プロセス（ＰＢ１）に適用され、
    被リプレイ・シーケンスは、前記再始動プロセスを、前記被ロギング・シーケンス後の前記被ロギング・プロセスの状態に対応する状態に復元する、
    請求項１２に記載の方法。
14. 外部リプレイ・エージェント（ＰＲＥ）によって開始された外部イベントの発生に応答して、前記再始動プロセス（ＰＢ１）が、内部イベントの少なくとも１つの被ロギング・シーケンスの前記リプレイ（ＲＳＢ）を実行する、請求項１２または１３に記載の方法。
15. 前記再始動ポイントでの前記被ロギングと呼ばれるプロセス（Ｐ１）の状態が、再始動ポイント・データ（ＥＰＲ）の形で取り込み（ＣＡＰ）および格納され、これを使用して、前記再始動プロセスが、前記リプレイ・フェーズ（ＲＳＢ）を適用する前の前記再始動ポイント状態に復元（ＲＥＳ）される、請求項１２〜１４のいずれか一項に記載の方法。
16. 被追跡アプリケーション（ＡＯＰ）と呼ばれるアプリケーションの実行の監視を実行し、前記監視が、前記被追跡アプリケーションの少なくとも１つのプロセス（Ｐ１）に適用され、
    前記方法が、
    前記被追跡アプリケーションの所与の状態から、前記被追跡アプリケーションの実行において調査済みシーケンスを構成する複数の一連の連続する被ロギング・シーケンスのロギング（ＪＯＰ）を開始するステップと、
    残りの前記被ロギング・シーケンスの制御された実行を生成する、制御された一連のリプレイ・ステップ（ＲＳＢ）を生成し、制御リズムに従って調査済みシーケンスのリプレイを生成するステップと
    を含む、請求項１２〜１５のいずれか一項に記載の方法。
17. クラスタと呼ばれる、通信マルチコンピュータ・アーキテクチャの、オペレーション・ノード（ＯＰ）と呼ばれる少なくとも１つの１次ノードで実行される、被確実化アプリケーション（ＡＯＰ）と呼ばれる第１のアプリケーションの機能の確実化を実施し、
    前記確実化は、スタンバイ・ノードと呼ばれる第２のクラスタ・ノードにおける、スタンバイ・アプリケーション（ＡＳＢ）と呼ばれる第２のアプリケーションの、前記再始動ポイントでの前記被確実化アプリケーションの状態に対応する状態への復元（ＲＥＳ）を含み、
    前記確実化は、
    前記開始ポイント以降に前記被確実化アプリケーション（ＡＯＰ）の実行をロギング（ＪＯＰ）し、ロギングされたイベントを、前記オペレーション・ノード（ＯＰ）外部の少なくとも１つのログ・ファイル（ＵＬ、ＫＬ）に格納するステップと、
    前記オペレーション・ノード（ＯＰ）内の障害を検出するステップと、
    被確実化アプリケーション（ＡＯＰ）にロギングされた前記イベントを前記スタンバイ・アプリケーション（ＡＳＢ）でリプレイ（ＲＳＢ）するために、前記ログ・ファイルを使用し、最後にロギングされたイベント後に、前記被確実化アプリケーションの状態に対応する状態に前記スタンバイ・アプリケーションを復元するステップと
    をさらに含む、請求項１３〜１６のいずれか一項に記載の方法。
18. 協働するコンピュータのネットワークを備えているシステムであって、請求項１〜１７のいずれか一項に記載の方法を実装する少なくとも１つのノード（ＯＰ、ＳＢ）を備えている、前記システム。
19. 前記ネットワーク内で実行される少なくとも１つのアプリケーション（ＡＯＰ）の機能を管理するために、ミドルウェア・タイプのアプリケーション（ＩＮＴ）を使用する、請求項１８に記載のシステム。

Images