JP5258019B2 - アプリケーション・プロセス実行の範囲内での非決定論的オペレーションを管理、ロギング、またはリプレイするための予測方法 - Google Patents

Description

本発明は管理方法に関し、とりわけ、コンピュータ上で実行されるアプリケーション・プロセスの実行中に実施されるソフトウェア・オペレーションに関する、記録または外部監視による、管理方法に関する。この管理は、特に、データ・ロギングの形のオペレーションの記録、または以前にロギングされた実行に対応する所与の実行に従ったリプレイに適用される。

この方法は、それ自体がマルチプロセスもしくはマルチコンピュータ・ソフトウェア・アプリケーションまたはその両方の一部とすることが可能なプロセスの内部イベントを実行するオペレーションに、特に有利に適用される。

本発明は、実行中のソフトウェア・アプリケーションの機能管理においてこうした方法を実装するシステムにも関する。

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

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

このオペレーション管理のコンテキストでは、実行を再構成できるようにするために、１次アプリケーションまたはそのプロセスのうちの１つの機能をロギングすること、すなわち、この機能を表すデータを記録することが、しばしば有用である。１次アプリケーションの実行と共に、次にこのデータがロギング・データの形で生成され、格納およびバックアップのために１つまたは複数の２次ノードに伝送される。

たとえば、１次アプリケーションの機能を詳細に追跡および調査するために、次にこの機能を、後でまたはリモートに制御および監視しながら調査または再構成することが可能である。

また一例として、１次アプリケーションに障害、特にハードウェア障害が発生した場合、１次アプリケーションによって提供されたサービスと置き換えるために、２次ノード上に新しいスタンバイ・アプリケーションを作成することができる。次に、このスタンバイ・アプリケーションを既知の状態、たとえば以前に記録された再始動地点状態で作成することが可能である。スタンバイ・アプリケーションに、１次アプリケーションのロギング・データから１次アプリケーションの実行を障害時点まで再構成させることができる。この再構成またはリプレイの後、スタンバイ・アプリケーションは、そのロギング・データが１次ノード外部で受け取られた、最終イベントまでのアプリケーションと同じ状態になる。障害以前のすべてのイベントが障害までロギングおよび伝送されると、ユーザに対するサービスのわずかな中断で、または中断なしで、スタンバイ・アプリケーションが引き継ぐことができる。

しかしながら現在、多くの既存のアプリケーションはこうした管理機能を持たず、こうした機能を追加するためにこれらのアプリケーションを修正すると、非常に複雑かつコストがかかることになる。

コンピュータの、または１次ノードのシステム・ソフトウェアで、これらの機能を実装することからなるソリューションは、エラーのリスク、ネットワーク内での不安定または不適合、およびシステム・ソフトウェアの分野における特殊技術に関する要件などの、いくつかの重要な欠点を提示する。

加えて、主にユーザのメモリ・スペースで実行され、システム・ソフトウェア自体では数箇所の修正しか必要としない、中間アプリケーションによって引き継がれるこれらの管理機能からなるあるソリューションが、本発明者によって提案されている。

しかしながら、この種のソリューションでは、とりわけ、ロギング・データの作成および処理ならびに１次ノードから２次ノードへのその伝送が、１次アプリケーション自体の実行に関して、ならびに使用される通信ネットワークに対して、かなりの計算負荷を表す。従来技術では、マスタ・アプリケーションは、しばしばこの機能管理が開発状況で十分に使用できないというような性能損失を経験する。

実際には、１次アプリケーションの実行をわかりやすくまたはさらには完全に表せるようにするために、記録および伝送されることになるイベントは、しばしばかなり多数である。さらに、これらイベントの大多数、特に、１次ノードのハードウェアまたはソフトウェア・リソース内部のイベント、たとえば、セマフォの割り当てまたはメモリ内のデータ項目の読み取りを要求するシステム呼び出しは、実行が非常に高速のオペレーションに対応する。

対照的に、これらそれぞれのイベントに関するロギング・データの生成および格納、ならびに伝送は、特に内部イベントの場合、かなり長いオペレーションである。

実際には、各イベントのロギングは、それぞれが、少なくともそれ自体でロギングされたイベントに等しい負荷および作業時間を構成する少なくとも１つ、しばしばいくつかの、ソフトウェア・オペレーションを必要とするプロセスである。実装および内部イベントのタイプに応じて、ロギングが各イベントに対して追加する負荷または作業時間は、一般に１００から１０，０００倍の範囲で増加する。

さらに、コンピュータ外部への伝送に使用されるハードウェアおよびソフトウェア・プロトコルは、一般に、ロギングされるイベント数に対して性能が低く、これがネットワークの使用にとって障害であり、マスタ・アプリケーションの性能にとってボトルネックでもある。

特に非決定論タイプのイベントをロギングしないことによって、ロギングされるイベントの数を削減できるソリューションが存在する。

イベント、またはこれを構成するオペレーション、特にソフトウェア・オペレーションは、その実行の結果が、その開始時に存在した初期条件にのみ依存する場合、決定論的であると認めることができる。とりわけ、前述のような単一のオペレーションもしくは実行または機能を管理するコンテキストでは、オペレーションが、それを開始したプロセスの観点からすると決定論的である場合、すなわち、このプロセスに送信する結果がこのプロセスの初期状態にのみ依存する場合、そのオペレーションは決定論的と呼ばれる。同様に、一連の連続する決定論的オペレーションは、それ自体を決定論的シーケンスに構成することができる。

アプリケーション・プロセスの実行において、実行されるオペレーション、特に内部オペレーションの多くは決定論的である。たとえば数学的または論理的内部オペレーションは、このプロセスの初期状態の一部を形成するリソースにのみ影響を与え、修正だけが可能な場合、たいていは決定論的である。

反対に、こうしたプロセスと比べて、共有リソースに適用されるいくつかのオペレーションはしばしば非決定論的である。たとえば、他のプロセスと共有しているメモリ・ゾーンをカバーする共有セマフォの属性または「ロック」に関する要求は、非決定論的な可能性がある。実際、結果、すなわちこのロックまたは属性の取得等は、時にはこのリソースを予約したかまたは予約していない、他のプロセスの状態またはアクションに依存する可能性がある。

しかしながら、非決定論的イベントのリプレイ、および特にロギングは、有効に削減可能な性能損失を依然として構成する。特に、マスタ・アプリケーションを実行中、ロギング・オペレーションはオペレーション・ノードの作業負荷を表し、中間アプリケーションのアクションによる性能の低下の原因となる可能性がある。
フランス国特許第２８４３２１０号 フランス国特許第２８４３８０９号 ＲＦＣ １１１２標準「Host Extensions for IP Multicasting」

本発明の一目的は、これらの欠点のすべてまたはいくつかを克服することである。

本発明は、特に、
・内部イベントのロギングまたは処理によって生成される作業負荷の削減、
・伝送されるロギング・データの量の削減、
・同じ結果を与えるリプレイを生成できるように結果を格納しなければならない、非決定論的イベントの数の削減、
を達成することを目的とする。

本発明は、少なくとも１台のコンピュータによって実行される、被管理プロセスと呼ばれるアプリケーション・プロセスの単一オペレーション中にプログラム命令によって開始される、非決定論的ソフトウェア・オペレーションを管理するための方法を提案する。ここでは、当該オペレーションの実行により、実結果と呼ばれる少なくとも１つの結果データが被管理プロセスに送信される。

この方法は、
実結果に対応する可能性があり、且つオペレーションに関する予測結果を構成する値を供給するために、当該オペレーションの前にあったような被管理プロセスの状態またはそれが属するアプリケーションの状態に基づいて、予測機能と呼ばれる決定論的ソフトウェア処理を実行するステップと、
予測結果の値が実結果の値に対応するか否かを確定するための比較テスト・ステップと、
先行するテストの結果に依存する、当該被管理オペレーションの補足管理フェーズを実行するステップと、
を含む。

したがって本発明は、一種の再現可能なコンプライアンス・グリッドとしてみなすことのできる、既知の、または計算可能な決定論的予測への適合に依存する、非決定論的オペレーションの管理を実行することを提案する。したがって、オペレーションの結果がこのグリッドに適合する場合、管理作業負荷を減少させることが可能である。

この利得は、１次ノードに記録するだけでなくしばしば外部に伝送しなければならない、１次アプリケーションの活用時のロギング・オペレーションに関して、特に敏感である。

したがって本発明は、ロギングされるオペレーションまたはイベントの予測圧縮またはヒューリスティック圧縮の形を生成し、総合管理を必要とするこれらのオペレーションまたはイベントの比率を低下させることができる。実際、オペレーションが予測したとおりに動作した場合、適切な時点で再使用可能な既知の方法に従って、結果の値を後で見つけることが可能であるため、送信する結果をそれ自体にロギングする必要はない。

本発明は、１次ノードと呼ばれるコンピュータで実行されるロギングされたプロセスの実行シーケンスに含まれる、被ロギング（logged）と呼ばれるオペレーションを管理することを提案し、この管理は、当該被ロギング・オペレーションを、２次ノードによって実行される再始動プロセスが、被ロギング・オペレーションに対応する、被リプレイ（replayed）と呼ばれるオペレーションをリプレイできるようにする、ロギング・データの形で記録し、その被ロギング・オペレーションに対応する結果を再始動プロセスに送信する。

予期された結果に対応しない実結果、すなわち予測されていない（unpredicted）オペレーションの場合、補足管理フェーズは、被ロギング・オペレーションの実結果の値を表す結果データを含むロギング・データを格納する。

したがって、予測されていない結果の場合、このロギング・データの将来の使用時に、シーケンスの正確な実行を再構成することができる。

シーケンスのロギング時に、決定論的性質または非決定論的性質を決定するためにオペレーションをテストするフェーズは、追加の負荷を表す。しかしながら、このシーケンス内で適切に予測されたオペレーションの比率から、予測結果をロギングしないことによって達成される節減は、このテストによる過負荷を大幅に超えるものとなることが明らかである。

これとは反対に、すなわち、予期された結果に実結果が対応する予測オペレーションの場合、本発明は、作業負荷利得を構成する予測されたオペレーションの結果からデータを格納することもしくは外部に送信することまたはその両方を避けることができる。

オプションで、たとえば順序付け番号の形で、被ロギング・オペレーションに関する識別データを含む、ロギング・データのためのストレージを提供することが可能である。識別データは、ロギング・データを将来使用する際に含めることができるようにするために、オペレーションの実行を追跡することができる。

予測機能が決定論的かつ既知である場合、オペレーションの初期条件から、リプレイ時に結果を確実に再計算することができる。リプレイ時の結果が、この同じ予測と一致しない場合、この予測の結果を使用して、再始動プロセスが実際にロギング時と同じ結果を受け取るように、オペレーションの結果を「強制する」ことができる。

本発明によれば、オペレーションの結果を格納または伝送せずに、決定論的オペレーションをロギングすることが可能であり、これは１次ノードの作業負荷に関する節減である。

とりわけ本発明は、被ロギング・シーケンスと呼ばれる、被ロギング・プロセス・オペレーションのシーケンスを記録することが可能であり、予測されていないと呼ばれる少なくとも１つのオペレーションを含む当該シーケンスは、予測結果に対応しない実結果を送信する。この記録は、被ロギング・シーケンス・オペレーションに対応する被リプレイと呼ばれるオペレーションのシーケンスを、再始動プロセスにリプレイさせることが可能な、少なくとも１つのログ・ファイルの格納を含む。このコンテキストでは、当該ログ・ファイルは、被ロギングと呼ばれる当該予測されていないオペレーションの実結果を表し、当該予測されていないオペレーションに対応する被リプレイ・オペレーションの完了時に、再始動プロセスが当該被ロギング結果に対応する結果を含むように使用可能な、データを含む。

一実施形態によれば、少なくとも１つの予測される非決定論的オペレーションは、この予測されるオペレーションに対応する識別データを増分することによって、当該予測される非決定論的被ロギング・オペレーション（ＥＶＩｎＤ）の実結果（ＤＲ）を表す、ロギング・データのログ（ＪＳｅｍ１）内に格納されることなく、被ロギング・プロセス・シーケンスのロギング時にロギングされる。

オプションで、予測されていないオペレーションで実施される補足管理時に、増分シーケンスをリセットすることができる。

したがって、少なくとも１つの予測されていないオペレーションをロギングするためにログに格納されるロギング・データは、
一方で、当該予測されていないオペレーションに対応する順序付けデータの値を表す識別データ、および
他方で、当該被ロギング・オペレーションによって送信された実結果を表す結果データ
を含むことができる。

有利なことに、本発明は特に、少なくとも１つの被ロギング・シーケンスをログ内に記録することを提案し、この記録は、当該シーケンス内に少なくとも１タイプの非決定論的内部イベントを構成する各被ロギング・オペレーションについて、
実結果に対応する可能性が有り、且つ当該オペレーションに関する予測結果を構成する値を提供するために、当該オペレーションの前に、プロセスの状態またはそのアプリケーションに基づいて決定論的ソフトウェア処理を実施するステップと、
予測結果の値が実結果の値に対応するか否かを確定するための比較テスト・ステップと、
予測されていない結果の場合、一方で進行中のオペレーションに対応する順序付けデータの値、および、他方で進行中のオペレーションによってロギングされたプロセスに送られる実結果の値を表す結果データを、関連するように含む、ロギング・データのログに格納するステップと、
の、反復的繰り返しを含む。

有利なことに、予測されていない結果のみが結果の格納を発生させる。

一変形形態によれば、順序付けデータは、予測結果を伴うオペレーションで増分されるのみであり、予測されていない結果を伴うオペレーション時にはリセットされることが可能である。

ロギングと並行にまたはロギングとは独立に、本発明に従った方法は、２次ノードと呼ばれるコンピュータで実行される、被リプレイと呼ばれる、再始動プロセスの一部を形成するオペレーションのシーケンスを管理することができる。

したがって本発明は、ロギングのものと同一またはこれに対応するリプレイ予測機能を使用することによって、データ損失なしに、予測的またはヒューリスティックな圧縮／圧縮解除の形を生成し、これによって、ロギング時と同じ結果をリプレイ時に提供すると共に、格納および伝送されるロギング・データの量を削減することが可能である。このようにロギング・データを使用して、再始動プロセスによってリプレイされるオペレーションの形で、被ロギング・オペレーションのリプレイを実行することができる。

たとえばこの再始動プロセスは、起動された後、その実行可能ファイルから単独で実行することができる。被リプレイ・オペレーションは、このリプレイの実行時に、それらの特徴がこれを指示するごとに自らに結果を提供する。

本発明に従った管理は、ロギング・データを使用して、非決定論的被リプレイ・オペレーションごとに、ロギング時に戻された結果に対応する強制と呼ばれる結果を、再始動プロセスが考慮するようにすることができる。

本発明によれば、補足管理フェーズは、ロギング時に少なくとも１つの予測されていない非決定論的オペレーションについて、
リプレイされているオペレーションに対応するオペレーションのロギング時に戻された結果を表す、被ロギングと呼ばれる結果データのロギング・データにおける読み取りと、
被リプレイ・オペレーションの結果のインターセプト、および被リプレイ・オペレーションから生じる結果に代わる、強制された結果の再始動プロセスへの転送と、
を含む。

したがって、その実行可能ファイル内で、ロギング時に予測されていないオペレーションを実行する命令を再始動プロセスが実行するごとに、補足管理フェーズは、ロギング・データに適合するために、結果をチェックまたは強制することが可能であり、したがって、被ロギング・プロセスのそれに適合する再始動プロセスの実行をもたらすことが可能である。

他方で、ロギング時にオペレーションの結果が正しく予測された場合、たとえオペレーションが非決定論的であり、その実結果が不確実であっても、ロギング・データは結果データを含まなくてもよい。

ロギング時に予測された少なくとも１つの非決定論的オペレーションについて、補足管理フェーズは、
当該オペレーションのロギングおよび被リプレイ・オペレーションへの予測結果の提供に使用される、予測機能に対応する、リプレイ予測機能と呼ばれる決定論的ソフトウェア処理を実施するステップと、
被リプレイ・オペレーションの結果をインターセプトし、被リプレイ・オペレーションから生じる結果に代わって、強制された結果として予測結果を再始動プロセスに転送するプロセスと、
を含むことができる。

したがって、たとえ格納されていない場合であっても、ロギング時に取得された実結果を見つけること、および、リプレイされた結果がこれに適合するかどうかをチェックすること、または適合しない場合はこれを強制することが可能である。

加えて、ロギング・データがロギングされた結果を含まない各オペレーションについて、補足管理フェーズは、当該被リプレイ・オペレーションを表す順序付け値の増分を含む。

したがって、準拠した実行を維持するために有用でもなく必要でもない限り、その実行に介入することなく、この増分により、再始動プロセスの進行を監視することができる。必要以上に介入しないという事実は、リプレイを管理するプロセスもしくはアプリケーションにとって、またはそれらを実行するコンピュータにとって、作業の節減となる。

特に、予測されるオペレーションおよび予測されていないオペレーションの両方を含むシーケンスの場合、量の少ないロギング・データおよび必要とする作業負荷の少ないストレージの使用と共に、被ロギング・プロセスの実行に対応するか、またはこれとまったく同一の、リプレイを取得することが可能である。

本発明に従った方法は、特に、管理されたシーケンス内で少なくとも１つのタイプのイベントを生成するすべてのオペレーションを管理するために実装することができる。

したがって、ある特定の項目、たとえば他のプロセス、ユーザ、または特定のリソースに関して、プロセスのすべての実行を表す、ロギングまたはリプレイを実行することが可能である。

さらに、この方法は、本質的に非決定論的であると識別されるすべてのオペレーションを管理するために使用されるか、または本質的に非決定論的であると識別される結果を送信することができる。

様々なバージョンで、このヒューリスティックな最適化の方法は、様々な方法で他の最適化方法と組み合わせることができる。

たとえば、決定論的オペレーションのみがロギングされないソリューションでは、残りのオペレーションの一部のみ、すなわち非決定論的であり、かつ予測されていないオペレーションのみ、をロギングすることによって、作業負荷を最適化することが可能である。

とりわけ、本発明に従った方法は、管理されたシーケンス内で、管理されたプロセスもしくはそのアプリケーション、またはそれらを実行中のコンピュータの内部に非決定論的イベントを生成する、すべてのオペレーションを管理する。

外部イベントの管理との連携において、本発明は、特に、活用時に、同じ制限で管理されたアプリケーションの任意の減速をロギング可能にするために、プロセスの実行全体を管理することができる。

たとえばロギングまたはリプレイの、こうした管理は、実行可能ファイルから実行された命令によって開始され、当該実行ファイルの外部にあるオリジナルと呼ばれるルーチンへの呼び出しを含む、少なくとも１つのオペレーションに有利に適用される。

柔軟性がありごくわずかに煩雑な実装を可能にする方法の、本発明の一実施形態によれば、当該命令の実行は、オリジナル・ルーチンではなく、被修正ルーチンへの呼び出しを生成し、この被修正ルーチンは、この方法の実装を生成または開始する。

被修正ルーチンは、特に、システム・ソフトウェア内で実行される少なくとも１つの命令を含むことができる。この命令は、少なくとも１つのロギングまたはリプレイ・ソフトウェア・エージェントの呼び出しを行い、方法の実装を保証し、管理されたプロセスまたはターゲット・プロセスのコンピュータのユーザ・メモリ・スペース内で実行される。

したがって、たとえばシステム・ソフトウェアにおける介入を最小限にし、エラー、およびネットワーク内の様々なコンピュータ間での異機種混合のリスクを制限するように、基本的にユーザ・スペース内でこの管理の実装を生成することが可能である。

とりわけ、被修正ルーチンは、ルーチンを呼び出した命令が、ロギングまたはリプレイのコンテキストで実行されるかどうかを検証するテスト命令を含み、このテストは、それぞれロギング・タイプまたはリプレイ・タイプの管理エージェントへの呼び出しに影響を与える。

したがって、異なるユーザに従った管理の実装は、ロギングまたはリプレイのいずれかに関して、同じエージェントにより、たとえば単一の中間アプリケーションもしくは単一のカーネル・モジュールまたはその両方により、柔軟性が向上した状態で生成することができる。

予測機能は、特にプロセス、そのアプリケーション、または修正のみが可能なリソースの状態に基づいて、異なるタイプのソフトウェア処理を使用することができる。

したがって、特定の一実施形態では、本発明に従った方法は、管理されたプロセスの実行時に以前に発生した、少なくとも１タイプの１つまたは複数の外部イベントの特徴に依存する決定論的ソフトウェア処理を含む、少なくとも１つの予測機能を使用する。

特定の一機能によれば、本発明に従った方法は、第１の予測機能を使用することによって少なくとも１つの第１のオペレーションを、また第２の予測機能を使用することによって第２のオペレーションを、ロギングする。

いくつかの異なる予測機能を使用することによって、効率を最適化するために、対応するオペレーションのロギングに使用されるのと同じ予測機能を、各オペレーションのリプレイに使用して、このロギング方法を環境に適合させることが可能である。

一変形形態によれば、この方法は、特に、管理されるオペレーションのタイプに依存して、たとえばその性質または含まれるリソースに従って、決定論的選択または複数の所与の機能内での組み合わせによって選択された予測機能を使用する。この予測機能の選択は、リプレイ時に、ロギング時に実行された選択と同一に、またはこれに対応して、再生成することができる。

他の変形形態によれば、使用される予測機能の選択は、被ロギング・プロセスの実行中に測定または計算された変数の変化に依存し、たとえば、ロギング時の予測機能の成功率における変化は、この機能の変化またはそのパラメータの一部の変化を決定することができる。

本発明によれば、ログ・ファイルは、こうした選択に影響を与える予測機能またはパラメータの少なくとも１つの選択を表すデータを含むことができる。

ロギング時にこの変更の特徴または時期を格納することで、その後リプレイ時に、同じ実行ポイントで同じ変更を生成することができるようになる。

シミュレーションまたはリプレイ機能の向上に関連して、本発明の他の目的は、アプリケーションの機能またはこれらプロセスのうちの少なくとも１つの管理を向上させることである。

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

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

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

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

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

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

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

この目的において、本発明は、クラスタと呼ばれる通信マルチコンピュータ・アーキテクチャの、オペレーション・ノードと呼ばれる少なくとも１つの１次ノードで実行される、被確実化アプリケーションと呼ばれる第１のアプリケーションの機能を確実化するために、機能管理を実装することを提案する。

この確実化は、スタンバイ・ノードと呼ばれる第２のクラスタ・ノードにおける、スタンバイと呼ばれる第２のアプリケーションの、再始動ポイントでの被確実化アプリケーションの状態に対応する状態への復元を含む。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Claims (20)

1. 少なくとも１台のコンピュータ（ＯＰ、ＳＢ）によって実行され、被管理プロセス（Ｐ１、ＰＢ１）と呼ばれるアプリケーション・プロセスの実行中にプログラム命令によって開始される非決定論的ソフトウェア・オペレーション（ＥＶＩｎＤ）を管理するための方法であって、
   前記オペレーションの実行により、実結果（ＤＲ、ＲＲＪ）と呼ばれる少なくとも１つの結果データが前記被管理プロセスに送信され、
   前記オペレーション（ＥＶＩｎＤ）の前に前記被管理プロセスの状態またはそれが属するアプリケーション（ＡＯＰ、ＡＳＢ）の状態に基づいて、予測機能（ＦＨ）と呼ばれる決定論的ソフトウェア処理を実行して、前記オペレーションに対して前記実結果に対応する値を供給して予測結果（ＲＰ）を構成するステップと、
   予測結果（ＲＰ）の値が実結果（ＤＲ、ＲＲＪ）の値に対応するか否かを確定するための比較テスト・ステップと、
   先行するテストの結果に依存し、前記被管理プロセスに対するオペレーションの補足管理フェーズ（ＣＨ、ＤＨ）を実行するステップと、
   被ロギング（ＥＶＩｎＤ、図１３）と呼ばれるオペレーションを管理して、１次ノード（ＯＰ）と呼ばれるコンピュータで実行される被ロギングプロセス（Ｐ１）の実行の一部を形成し、この管理が２次ノードによって実行されるリスタートプロセスをイネーブルするロギング・データの形式で被ロギング・オペレーションを記録して、前記被ロギング・オペレーションに対応する被リプレイと呼ばれるオペレーションをリプレイし、前記被ロギング・オペレーションの結果に対応する結果を前記リスタートプロセスに送信するステップとを、含み、
   補足管理フェーズ（ＣＨ）は、さらに、
   前記実結果（ＤＲ）が予測結果（ＲＰ）に対応しない場合に、予測されていないオペレーションと呼ばれるようになる前記被ロギング・オペレーション（ＥＶｌｎＤ）の実結果（ＤＲ）の値を示す結果データを含むロギングデータを記憶し、
   ２次ノードと呼ばれるコンピュータで実行され、リスタートプロセス（ＰＢ１）の実行の一部を形成し被リプレイと呼ばれるシーケンスを管理し、ロギングデータ（ＪＳｅｍ１）を用いて、非決定論的被リプレイ・オペレーションごとに、前記リスタートプロセスがロギングの間の戻された結果に対応し強制（ＲＦ）と呼ばれる結果を考慮するようにすることを含み、
   補足管理フェーズ（ＤＨ）は、少なくともロギングデータがロギング結果を有しないオペレーション（ＥＶｉｎＤ）に対して、前記被リプレイ・オペレーションを示す順序付け値（ＳＱ）をインクリメントすることを含む、方法。
2. さらに、被ロギング（ＥＶＩｎＤ、図１３）と呼ばれる被ロギング・オペレーションを管理して、１次ノード（ＯＰ）と呼ばれるコンピュータで実行されるロギングされたプロセス（Ｐ１）の実行の一部を形成し、２次ノードによって実行されるリスタートプロセスをイネーブルするロギング・データの形式で前記被ロギング・オペレーションを記録し、被ロギング・オペレーションに対応し被リプレイと呼ばれるオペレーションをリプレイして、前記被ロギング・オペレーションの結果に対応する結果を前記リスタートプロセスに送信し、
   前記補足管理のプロセスは、前記被ロギング・オペレーションに対して識別データを計算することを特徴とする請求項１に記載の方法。
3. さらに、前記被ロギング・プロセスによって実行されるオペレーションの被ロギングシーケンスを記録することを含み、
   前記シーケンスは、予測結果（ＲＰ）に対応しない実結果（ＤＲ）を、予測されていないと呼ばれる少なくとも１つの予測されていないオペレーション（ＥＶＩＤ）に送信して、前記リスタートプロセスをイネーブルする少なくとも１つのログファイル（ＪＳｅｍ１）を記憶して、被ロギング・シーケンスのオペレーションに対応し被リプレイと呼ばれるシーケンスをリプレイし、
   前記ログファイルは、前記予測されていないオペレーションの被ロギング（ＤＲ）と呼ばれる実結果を示すデータを含み、前記データは前記予測されていないオペレーションに対応する被リプレイ・オペレーションの完了時に、リスタートプロセスが前記被ロギング結果に対応する結果を考慮の対象とするように使用可能であることを特徴とする請求項１に記載の方法。
4. 前記予測される非決定論的被ロギング・オペレーション（ＥＶＩｎＤ）の実結果（ＤＲ）を表すロギング・データが、ログ（ＪＳｅｍ１）に格納されることなく、少なくとも１つの予測される非決定論的オペレーションが被ロギング・プロセス・シーケンスのロギング時にロギングされることを特徴とする請求項１に記載の方法。
5. 少なくとも１つの予測されていないオペレーション（ＥＶＩｎＤ）をロギングするために、ログ（ＪＳｅｍ１）に格納されるロギング・データが、
   前記予測されていないオペレーションに対応する順序付けデータの値（ＳＱ）を表す識別データ、および
   前記被ロギング・オペレーションによって送信された実結果を表す結果データ（ＤＲ）を含むことを特徴とする、請求項４に記載の方法。
6. 少なくとも１つの被ロギング・シーケンスをログ（ＪＳｅｍ１）に記録して、この記録によって前記シーケンスに各被ロギング・オペレーションに対して少なくとも１タイプの非決定論的内部イベント（ＥＶＩｎＤ）を構成し、
   前記オペレーションの前に、前記プロセス（Ｐ１）の状態またはそのアプリケーション（ＡＯＰ）に基づいて決定論的ソフトウェア処理（ＦＨ）を行って、前記オペレーションに対して前記実結果に対応する値を供給して予測結果（ＲＰ）を供給するステップ（４）と、
   予測結果（ＲＰ）の値が実結果（ＤＲ）の値に対応するか否かを確定するための比較テスト・ステップ（５）と、
   予測されていない結果の場合、進行中のオペレーションに対応する順序付けデータ（ＳＱ）の値、および、進行中のオペレーション（ＥＶＩｎＤ）によってロギングされたプロセスに送られる実結果の値を表す結果データ（ＤＲ）を、関連するようにロギング・データのログ（ＪＳｅｍ１）に格納する（６）ステップとを有し、
   これらステップを反復的に繰り返すことを特徴とする、請求項２乃至５のいずれか一項に記載の方法。
7. ２次ノード（ＳＢ）と呼ばれるコンピュータで実行され、リスタートプロセス（ＰＢ１）の実行の一部を形成するオペレーションについて被リプレイと呼ばれるシーケンスを管理して、当該管理がロギング・データ（ＪＳｅｍ１、図１４）を用いて非決定論的被リプレイ・オペレーションごとに、ロギング時（ＪＯＰ）に戻された結果に対応する強制（ＲＦ）と呼ばれる結果をリスタートプロセスに考慮させ、
   補足管理フェーズ（ＤＨ）は、ロギング時に少なくとも１つの予測されていない非決定論的オペレーション（ＥＶＩｎＤ）について、
   リプレイされているオペレーション（ＥＶＩｎＤ）に対応するオペレーションのロギング時に戻された結果を示し、被ロギング（ＲＬｉ）と呼ばれる結果データの前記ロギング・データにおける読み取り（５）と、
   被リプレイ・オペレーションの結果（ＲＲＪ）のインターセプト、および被リプレイ・オペレーションから生じる結果（ＲＲＪ）に代わる強制された結果（ＲＬｉ）のリスタートプロセス（ＰＢ１）への転送（８）と、
   を含むことを特徴とする、請求項１に記載の方法。
8. ２次ノードと呼ばれるコンピュータで実行され、リスタートプロセス（ＰＢ１）の実行の一部を形成するオペレーションについて被リプレイと呼ばれるシーケンスを管理して、当該管理がロギング・データ（ＪＳｅｍ１）を用いて、非決定論的被リプレイ・オペレーションごとに、ロギング時に戻された結果に対応する強制（ＲＦ）と呼ばれる結果をリスタートプロセスに考慮させ、
   補足管理フェーズ（ＤＨ）は、ロギング時に予測された少なくとも１つの非決定論的オペレーションについて、
   前記オペレーションのロギングに用いられる予測機能に対応し、被リプレイ・オペレーションの予測結果（ＲＰ）を提供するリプレイ予測機能（ＦＨ）と呼ばれる決定論的ソフトウェア処理を実施するステップ（６）と、
   被リプレイ・オペレーションの結果（ＲＲＪ）をインターセプトし、被リプレイ・オペレーションから生じる結果（ＲＲＪ）に代わって予測結果（ＲＰ）をリプレイプロセスに転送するステップ（８）と、
   を含むことを特徴とする、請求項１乃至７のいずれか一項に記載の方法。
9. 本質的に非決定論的であると識別されるすべてのオペレーションを管理するか、または本質的に非決定論的であると識別される結果を送信することを特徴とする、請求項３乃至８のいずれか一項に記載の方法。
10. 被管理シーケンス内で、被管理プロセス（Ｐ１、ＰＢ１）、またはそのアプリケーション（ＡＯＰ、ＡＳＢ）、またはそれらを実行するコンピュータ（ＯＰ、ＳＢ）について、内部に非決定論的イベントを生成するすべてのオペレーションを管理することを特徴とする、請求項３乃至９のいずれか一項に記載の方法。
11. 実行可能ファイル（ＥＸＥ、図９）から実行された命令によって開始され、前記実行可能ファイルの外部にあるオリジナルと呼ばれるルーチン（Ｒ、ＲｎＤ）への呼び出しを含む、少なくとも１つのオペレーション（ＥＶＩｎＤ）を管理し、前記命令の実行は、前記オリジナル・ルーチンではなく、被修正と呼ばれるルーチン（ＲＭ、ＲＭｎＤ）への呼び出しを実行し、この被修正ルーチンは、方法の実装を生成または開始することを特徴とする、請求項１乃至１０のいずれか一項に記載の方法。
12. 被修正ルーチン（ＲＭｎＤ）が、システム・ソフトウェア（ＯＰＳ、ＳＢＳ）内で実行される少なくとも１つの命令を含み、この命令が、少なくとも１つの管理ソフトウェア・エージェント（ＰｌｏｇＯＰ、ＲＰＩ）を呼び出し、この管理ソフトウェア・エージェントが、方法の実装を管理し、被管理プロセスのためにコンピュータのユーザ・メモリ・スペース（ＯＰＵ、ＳＢＵ）内で実行されることを特徴とする、請求項１１に記載の方法。
13. 被修正ルーチン（ＲＭｎＤ）は、ルーチンを呼び出した命令が、ロギングまたはリプレイのコンテキストで実行されるかどうかを検証するテスト命令を含み、このテストが、それぞれロギング・タイプ（ＰｌｏｇＯＰ）またはリプレイ・タイプ（ＰＲＩ）の管理エージェントへの呼び出しに影響を与えることを特徴とする、請求項１１または１２に記載の方法。
14. 被管理プロセス（Ｐ１、ＰＢ１）の実行時に以前に発生した、少なくとも１タイプの１つまたは複数の外部イベントの特徴に依存する決定論的ソフトウェア・プロセスを含む、少なくとも１つの予測機能（ＦＨ）を使用することを特徴とする、請求項１０乃至１３のいずれか一項に記載の方法。
15. 第１の予測機能を使用することによって少なくとも１つの第１のオペレーションを、また第２の予測機能を使用することによって第２のオペレーションを、ロギングすることを特徴とする、請求項３乃至１４のいずれか一項に記載の方法。
16. 決定論的選択または複数の所与の機能内での組み合わせによって選択された予測機能（ＦＨ）を使用することを特徴とする、請求項１５に記載の方法。
17. 使用される予測機能（ＦＨ）の選択が、被ロギング・プロセス（Ｐ１）の実行中に測定または計算された変数の変化に依存することを特徴とする、請求項１５または１６に記載の方法。
18. 被ロギング（Ｐ１）と呼ばれる少なくとも１つのアプリケーション・プロセスの機能管理を実施し、
    リスタートと呼ばれる所与のポイントから、中断ポイントと呼ばれるポイントまでの、前記被ロギング・プロセスの実行時に発生した、少なくとも１つの所与のタイプのすべてのイベントをロギング（ＪＯＰ）し、前記ロギングから発生するログ（ＵＬ、ＫＬ、ＪＳｅｍ１）を格納するステップと、
    被ロギング・プロセスのリスタートポイント状態に対応する状態でリスタートプロセス（ＰＢ１）を開始し、前記リスタートプロセスによって前記格納したログであるジャーナルから前記イベントをリプレイ（ＲＳＢ）し、リスタートプロセスを、中断ポイントでの被ロギング・プロセスの状態に対応する状態にするステップと、
    を含むことを特徴とする、請求項１乃至１７のいずれか一項に記載の方法。
19. 請求項１乃至１８のいずれか一項に記載の方法の各ステップをコンピュータに実施させるプログラム。
20. 少なくとも１台のコンピュータ（ＯＰ、ＳＢ）によって実行され、被管理プロセス（Ｐ１、ＰＢ１）と呼ばれるアプリケーション・プロセスの実行中にプログラム命令によって開始される非決定論的ソフトウェア・オペレーション（ＥＶＩｎＤ）を管理するためのシステムであって、
    前記オペレーションの実行により、実結果（ＤＲ、ＲＲＪ）と呼ばれる少なくとも１つの結果データが前記被管理プロセスに送信され、
    前記オペレーション（ＥＶＩｎＤ）の前に前記被管理プロセスの状態またはそれが属するアプリケーション（ＡＯＰ、ＡＳＢ）の状態に基づいて、予測機能（ＦＨ）と呼ばれる決定論的ソフトウェア処理を実行して、前記オペレーションに対して前記実結果に対応する値を供給して予測結果（ＲＰ）を構成する手段と、
    予測結果（ＲＰ）の値が実結果（ＤＲ、ＲＲＪ）の値に対応するか否かを確定するための比較テスト手段と、
    先行するテストの結果に依存し、前記被管理プロセスに対するオペレーションの補足管理フェーズ（ＣＨ、ＤＨ）を実行する手段と、
    被ロギング（ＥＶＩｎＤ、図１３）と呼ばれるオペレーションを管理して、１次ノード（ＯＰ）と呼ばれるコンピュータで実行される被ロギングプロセス（Ｐ１）の実行の一部を形成し、この管理が２次ノードによって実行されるリスタートプロセスをイネーブルするロギングデータの形式で被ロギング・オペレーションを記録して、前記被ロギング・オペレーションに対応する被リプレイと呼ばれるオペレーションをリプレイし、前記被ロギング・オペレーションの結果に対応する結果を前記リスタートプロセスに送信する手段とを、含み、
    補足管理フェーズ（ＣＨ）を実行する手段は、さらに、
    前記実結果（ＤＲ）が予測結果（ＲＰ）に対応しない場合に、予測されていないオペレーションと呼ばれるようになる前記被ロギング・オペレーション（ＥＶｌｎＤ）の実結果（ＤＲ）の値を示す結果データを含むロギングデータを記憶し、
    ２次ノードと呼ばれるコンピュータで実行され、リスタートプロセス（ＰＢ１）の実行の一部を形成し被リプレイと呼ばれるシーケンスを管理し、ロギングデータ（ＪＳｅｍ１）を用いて、非決定論的被リプレイ・オペレーションごとに、前記リスタートプロセスがロギングの間の戻された結果に対応し強制（ＲＦ）と呼ばれる結果を考慮するようにすることを含み、
    補足管理フェーズ（ＤＨ）を実行する手段は、少なくともロギングデータがロギング結果を有しないオペレーション（ＥＶｉｎＤ）に対して、前記被リプレイ・オペレーションを示す順序付け値（ＳＱ）をインクリメントすることを含む、システム。

Images