FR2881246A1 - Procede perdictif de gestion, de journalisation ou de rejeu d'operations non deterministes au sein du deroulement d'un processus applicatif - Google Patents

Abstract

La présente invention concerne un procédé de gestion, plus particulièrement par journalisation et rejeu, d'opérations logicielles réalisées au cours du déroulement d'un processus applicatif exécuté sur un ordinateur.Ce procédé s'applique en particulier à des opérations internes renvoyant une donnée de résultat au processus géré, et comprend les étapes suivantes :- exécution d'un traitement logiciel déterministe, dit de fonction de prédiction (FH), se basant sur l'état du processus géré ou de l'application (AOP, ASB), pour fournir un résultat prédit (RP) pour ladite opération ;- test de comparaison pour savoir si la valeur du résultat prédit (RP) correspond ou non à la valeur du résultat réel (DR, RRJ) ;- réalisation d'une phase de gestion complémentaire (CH, DH) de ladite opération gérée, cette gestion complémentaire dépendant du résultat du test précédent.

Description

Procédé prédictif de gestion, de journalisation ou de rejeu d'opérations

non déterministes au sein du déroulement d'un processus applicatif La présente invention concerne un procédé de gestion, plus particulièrement par enregistrement ou contrôle externe, d'opérations logicielles réalisées au cours du déroulement d'un processus applicatif exécuté sur un ordinateur. Cette gestion s'applique en particulier à l'enregistrement d'opérations sous la forme de données de journalisation, ou à un rejeu d'opérations selon un déroulement déterminé correspondant à un déroulement précédemment journalisé.

Le procédé est particulièrement avantageux appliqué aux opérations réalisant des évènements internes de ce processus, qui peut lui-même faire partie d'une application logicielle multi-processus et/ou multiordinateurs.

L'invention concerne également un système mettant en oeuvre un tel procédé dans la gestion du fonctionnement des applications logicielles qu'il exécute.

Le domaine de l'invention est celui des ordinateurs, isolés ou en réseaux ou clusters d'ordinateurs formés de plusieurs ordinateurs collaborant entre eux. Ces clusters sont utilisés pour exécuter des applications logicielles apportant un ou des services à des utilisateurs. Une telle application peut être mono-processus ou multi-processus, et être exécutée sur un seul ordinateur ou distribuée sur plusieurs ordinateurs, par exemple sous la forme d'une application distribuée, de type MPI ( Message Passing Interface ) ou de type mémoire partagée ( Shared Memory ).

L'invention permet en particulier de réaliser une gestion du fonctionnement, au sein du cluster, d'une telle application dite maître ou primaire, par exemple par une autre application logicielle dite application intermédiaire, par exemple une application de type middleware . Cette gestion de fonctionnement peut comprendre entre autres des opérations de réplication, de redistribution, de fiabilisation, ou de traçage ( debugging ) de tout ou partie de cette application, au sein du noeud primaire ou en collaboration avec d'autres noeuds dits secondaires.

Dans le cadre de cette gestion de fonctionnement, il est souvent utile de journaliser le fonctionnement de l'application primaire ou de d'un de ses processus, c'est à dire d'enregistrer des informations représentant ce fonctionnement, et pouvant permettre d'en reconstituer le déroulement. Au fur et à mesure du déroulement de l'application primaire, ces informations sont alors générées sous forme de données de journalisation et sont transmises vers un ou plusieurs noeuds secondaires pour mémorisation et sauvegarde.

Par exemple pour tracer et étudier en détail le fonctionnement de l'application primaire, il est alors possible d'étudier ou de reconstituer ce fonctionnement, ultérieurement ou distance, de façon contrôlée et surveillée.

Par exemple également, si l'application primaire subit une défaillance, en particulier matérielle, il est alors possible de créer une nouvelle application de secours sur un noeud secondaire pour remplacer l'application primaire dans les services qu'elle rendait. Cette application de secours peut alors être créée dans un état connu, par exemple un état de point de reprise enregistré précédemment. A partir des données de journalisation de l'application primaire, il est alors possible de forcer l'application de secours à reconstituer le déroulement de l'application primaire jusqu'au moment de la défaillance. Après cette reconstitution, ou rejeu, l'application de secours se trouve dans le même état que l'application jusqu'au dernier événement dont les données de journalisation ont été reçues à l'extérieur du noeud primaire. Si tous les évènements précédant la défaillance ont bien été journalisés et transmis jusqu'à la défaillance, l'application de secours peut alors prendre le relais avec peu ou pas d'interruption de service vis à vis des utilisateurs.

Or actuellement, de nombreuses applications existantes ne comportent pas de telles fonctionnalités de gestion, et il serait trop complexe et coûteux de les modifier pour les leur ajouter.

La solution qui consiste à implémenter ces fonctionnalités dans le logiciel système de l'ordinateur ou du noeud primaire présente certains inconvénients importants, comme les risques d'erreurs, d'instabilité ou d'incompatibilité au sein du réseau et le fait de nécessiter des compétences spécifiques dans le domaine des logiciels systèmes.

Une solution est proposée par ailleurs par les auteurs de la présente invention, qui consiste à faire prendre en charge ces fonctionnalités de gestion par une application intermédiaire qui est exécutée principalement dans l'espace mémoire utilisateur et ne nécessite que peu de modifications au sein du logiciel système lui-même.

Toutefois, dans ce type de solution entre autres, la création et le traitement des données de journalisation, ainsi que leur transmission du noeud primaire à un noeud secondaire, représentent une charge de calcul importante par rapport à l'exécution de l'application primaire en ellemême, ainsi que pour les réseaux de communication utilisés. Dans l'état de la technique, l'application maître subit alors une telle perte de performance que, souvent, cette gestion de fonctionnement ne peut pas être utilisée de façon satisfaisante en situation d'exploitation.

En effet, pour pouvoir représenter de façon cohérente, voire complète, le déroulement de l'application primaire, les évènements à enregistrer et à transmettre sont souvent très nombreux. De plus, une grande part de ces évènements correspond à des opérations dont l'exécution est très rapide, en particulier les évènements qui sont internes aux ressources matérielles ou logicielles du noeud primaire, par exemple un appel système demandant l'affectation d'un sémaphore ou réalisant la lecture d'une donnée en mémoire.

Par opposition, pour chacun de ces évènements, la génération et la mémorisation ainsi que la transmission des données de journalisation constitue une opération beaucoup plus longue, en particulier pour les évènements internes.

En effet, la journalisation de chaque évènement est en soi un processus qui requiert au moins une et souvent plusieurs opérations logicielles, lesquelles constituent chacune une charge et un temps de travail au moins équivalent à l'événement journalisé en lui-même. Selon les implémentations et le type d'événement interne, la journalisation ajoute pour chaque événement une charge ou un temps de travail plus important d'un facteur allant couramment de 100 à 10 000.

De plus, les protocoles matériels et logiciels utilisés pour la transmission vers l'extérieur d'un ordinateur ont des performances sont en général faibles par rapport au nombre d'évènements journalisés, ce qui constitue également une gêne pour l'exploitation du réseau ainsi qu'un goulet d'étranglement pour les performances de l'application maître.

Certaines solutions existent qui permettent de réduire le nombre d'évènements à journaliser, en particulier en ne journalisant que les évènements de type non déterministes.

Un événement ou l'opération qui le constitue, en particulier une opération logicielle, peut être qualifié de déterministe si le résultat de son exécution ne dépend que des conditions initiales qui prévalaient lors de ce déclenchement. Plus particulièrement dans le cadre d'une gestion d'opération unitaire ou de déroulement ou de fonctionnement telle que décrite ici, une opération est dite déterministe si elle est déterministe du point de vue du processus qui l'a déclenchée, c'est-à- dire si le résultat qu'elle renvoie à ce processus ne dépend que de l'état initial de ce processus. De même, une succession contiguë d'opérations déterministes pourra constituer elle-même une séquence déterministe.

Au sein du déroulement d'un processus applicatif, une grande partie des opérations réalisées sont de nature déterministe, en particulier parmi les opérations internes. Par exemple, des opérations internes de type mathématique ou logique seront le plus souvent déterministes lorsqu'elles n'affectent que des ressources faisant partie de l'état initial de ce processus, et qu'il est seul à pouvoir modifier.

A contrario, certaines opérations portant sur des ressources partagées sont souvent non déterministes vis à vis d'un tel processus. Par exemple, une demande d'attribution d'un sémaphore partagée ou d'un lock sur une zone mémoire partagée avec d'autres processus pourra être non déterministe. En effet, le résultat, c'est à dire l'obtention ou non de ce lock ou de cette attribution pourra dépendre de l'état ou des actions d'autres processus, qui auraient déjà réservé ou non cette ressource.

Cependant, le rejeu et en particulier la journalisation des évènements non déterministes constituent encore une perte de performance qu'il peut être utile de diminuer.

Un but de l'invention est de pallier tout ou partie de ces inconvénients.

L'invention cherche en particulier à obtenir: - une réduction de la charge de travail générée par la journalisation ou le traitement des évènements internes; - une diminution du volume des données de journalisation à transmettre; - une diminution du nombre d'événements non déterministes dont le résultat doit être mémorisé pour pouvoir réaliser un rejeu donnant le même résultat.

L'invention propose un procédé de gestion d'une opération logicielle non déterministe déclenchée par une instruction de programme au sein du déroulement d'un processus applicatif, dit processus géré, exécuté par au moins un ordinateur, dans le cas où la réalisation de ladite opération renvoyant audit processus géré au moins une donnée de résultat, dit résultat réel.

Ce procédé comprend les étapes suivantes: - exécution d'un traitement logiciel déterministe, dit de fonction de prédiction, se basant sur l'état du processus géré ou de l'application à laquelle il appartient, tel qu'il était avant ladite opération, pour fournir une valeur susceptible de correspondre au résultat réel et constituant un résultat prédit pour ladite opération; - test de comparaison pour savoir si la valeur du résultat prédit correspond ou non à la valeur du résultat réel; réalisation d'une phase de gestion complémentaire de ladite opération gérée, cette gestion complémentaire dépendant du résultat du test précédent.

L'invention propose ainsi de réaliser une gestion des opérations non déterministes qui dépende de leur conformité ou non à une prédiction déterministe connue ou calculable, pouvant être vue comme une sorte de grille de conformité reproductible. Il est ainsi possible de réduire la charge de travail de gestion dans les cas où le résultat d'une opération est conforme à cette grille.

Ce gain est particulièrement sensible pour les opérations de journalisation, qui doivent à la fois être enregistrées dans le noeud primaire mais aussi souvent transmises à l'extérieur, et ce au cours de l'exploitation de l'application primaire.

L'invention permet ainsi de réaliser une forme de compression prédictive ou heuristique des opérations ou évènements à journaliser, et d'en réduire la proportion demandant une gestion complète. En effet, lorsque l'opération se comporte de façon conforme à la prédiction, le résultat qu'elle renvoie n'a plus besoin d'être journalisé en lui-même puisque sa valeur peut être retrouvée ultérieurement selon une méthode connue qui pourra être réutilisée le moment venu.

L'invention propose en particulier de gérer une opération, dite journalisée, faisant partie du déroulement d'un processus journalisé exécuté dans un ordinateur dit noeud primaire, cette gestion enregistrant ladite opération journalisée sous la forme de données de journalisation permettant à un processus de reprise exécuté par un noeud secondaire de rejouer une opération, dite rejouée, correspondant à l'opération journalisée et renvoyant au processus de reprise un résultat correspondant à celui de l'opération journalisée.

Dans le cas d'un résultat réel ne correspondant pas au résultat prévu, c'est à dire d'une opération non prédite, la phase de gestion complémentaire comprend alors une mémorisation de données de journalisation incluant une donnée de résultat représentant la valeur du résultat réel de l'opération journalisée.

Il est ainsi possible de reconstituer le déroulement exact de la séquence lors d'une utilisation future de ces données de journalisation. Dans le cas d'un résultat non prédit.

Lors de la journalisation d'une séquence, la phase de test des opérations pour déterminer leur nature déterministe ou non représente une charge supplémentaire. Cependant, à partir d'une certaine proportion d'opérations correctement prédites au sein de cette séquence, on comprend que l'économie réalisée en ne journalisant pas les résultats prédits peut devenir significativement plus importante que la surcharge due à ce test.

Dans le cas contraire, c'est à dire une opération prédite pour laquelle le résultat réel correspond au résultat prévu, l'invention permet d'éviter de mémoriser et/ou transmettre à l'extérieur les données de résultat de l'opération prédite, ce qui constitue un gain de charge de travail.

De façon optionnelle, il est possible de prévoir une mémorisation de données de journalisation incluant une donnée d'identification de l'opération journalisée, par exemple sous la forme d'un numéro de séquencement. Cette donnée d'identification permet de garder une trace de l'exécution de cette opération de façon à pouvoir en tenir compte dans l'utilisation future de ces données de journalisation.

Du fait que la fonction de prédiction est déterministe et connue, le résultat peut être recalculé de façon certaine lors du rejeu, à partir des conditions initiales de l'opération. Si le résultat lors du rejeu n'est pas conforme à cette même prédiction, le résultat de cette prédiction pourra alors servir à forcer le résultat de l'opération de façon à ce que le processus de reprise reçoive bien le même résultat que lors de la journalisation.

Selon l'invention, la journalisation d'une opération déterministe peut alors se faire sans mémoriser ni transmettre le résultat de l'opération, ce qui constitue une économie en terme de charge de travail pour le noeud primaire.

Plus particulièrement, le procédé permet d'enregistrer une séquence, dite journalisée, d'opérations du processus journalisé, ladite séquence incluant au moins une opération, dite non prédite, renvoyant un résultat réel ne correspondant pas au résultat prédit. Cet enregistrement comprend alors une mémorisation d'au moins un fichier journal permettant au processus de reprise de rejouer une séquence, dite rejouée, d'opérations correspondant aux opérations de la séquence journalisée. Dans ce cadre, ledit fichier journal comprend des données représentant le résultat réel, dit journalisé, de ladite opération non prédite et qui sont utilisables pour que, à l'issue d'une opération rejouée correspondant à ladite opération non prédite, le processus de reprise prenne en compte un résultat correspondant audit résultat journalisé.

Selon un mode de réalisation, lors de la journalisation d'une séquence du processus journalisé, au moins une opération prédite et non déterministe est journalisée sans mémoriser, au sein du journal (JSeml) de données de journalisation représentant le résultat réel (DR) de ladite opération journalisée prédite et non déterministe (EVInD).

Optionnellement, la séquence d'incrémentation peut être réinitialisée au cours de la phase de gestion complémentaire réalisée lors d'une opération non prédite.

Les données de journalisation mémorisées dans le journal pour la 10 journalisation d'au moins une opération non prédite, peuvent alors comprendre: d'une part une donnée d'identification représentant la valeur de la donnée de séquencement correspondant à ladite opération non prédite, et; - d'autre part une donnée de résultat représentant le résultat réel renvoyé par ladite opération journalisée.

De façon avantageuse, l'invention propose en particulier d'enregistrer au sein d'un journal au moins une séquence journalisée, cet enregistrement comprenant une répétition itérative, pour chaque opération journalisée constituant un événement interne non déterministe d'au moins un type au sein de ladite séquence, des étapes suivantes: exécution d'un traitement logiciel déterministe se basant sur l'état du processus ou de son application avant ladite opération pour fournir une valeur susceptible de correspondre au résultat réel et constituant un résultat prédit pour ladite opération; - test de comparaison pour savoir si la valeur du résultat prédit correspond ou non à la valeur du résultat réel; dans le cas d'un résultat non prédit, mémorisation dans le journal de données de journalisation comprenant de façon associée d'une part la valeur de la donnée de séquencement correspondant à l'opération en cours, et d'autre part une donnée de résultat représentant la valeur du résultat réel renvoyé au processus journalisé par l'opération en cours.

De façon avantageuse, seules les opérations non prédites donnent lieu à une mémorisation du résultat.

Selon une variante, l'incrémentation de la donnée de séquencement peut n'être faite que lors d'une opération au résultat prédit, et être réinitialisée lors d'une opération au résultat non prédit.

En parallèle avec la journalisation ou indépendamment, le procédé selon l'invention permet de gérer une séquence, dite rejouée, d'opérations faisant partie du déroulement d'un processus de reprise, exécuté dans un ordinateur dit noeud secondaire.

En utilisant une fonction de prédiction de rejeu qui soit identique ou corresponde à celle de la journalisation, l'invention réalise ainsi une forme de compression/décompression prédictive ou heuristique sans perte de données, qui peut fournir lors du rejeu les mêmes résultats que lors de la journalisation tout en diminuant la quantité de données de journalisation à mémoriser et à transmettre. Les données de journalisation.peuvent alors être utilisées pour réaliser un rejeu des opérations journalisées, sous forme d'opérations rejouées par un processus de reprise.

Ce processus de reprise peut par exemple être lancé puis s'exécuter de lui-même à partir de son ou ses fichiers exécutables. Lors du déroulement de ce rejeu, les opérations rejouées fournissent alors d'elles même un résultat, chaque fois que leur nature le commande.

La gestion selon l'invention peut alors utiliser les données de journalisation pour obtenir que, dans chaque cas d'une opération rejouée non déterministe, le processus de reprise prenne en compte un résultat, dit forcé, correspondant au résultat retourné lors de la journalisation, Selon l'invention, la phase de gestion complémentaire comprend alors, pour au moins une opération non déterministe non prédite lors de la journalisation: - une lecture dans les données de journalisation d'une donnée de résultat dit journalisé représentant le résultat retourné lors de la journalisation de l'opération correspondant à l'opération en cours de rejeu; - 10 - une interception du résultat de l'opération rejouée et une transmission du résultat forcé au processus de reprise en lieu et place du résultat issu de l'opération rejouée.

Ainsi, chaque fois que le processus de reprise exécute, au sein de son fichier exécutable, une instruction réalisant une opération non prédite lors de la journalisation, la phase de gestion complémentaire permet alors de vérifier ou de forcer le résultat pour qu'il soit conforme aux données de journalisation, et réaliser ainsi un déroulement du processus de reprise conforme à celui du processus journalisé.

Par contre, lorsque le résultat de l'opération a été correctement prédit lors de la journalisation, les données de journalisation peuvent ne pas contenir de donnée de résultat, même si l'opération n'est pas déterministe et son résultat réel incertain.

Pour au moins une opération non déterministe qui a été prédite lors de la journalisation la phase de gestion complémentaire peut alors comprendre les phases suivantes, : exécution d'un traitement logiciel déterministe, dit de fonction de prédiction de rejeu, correspondant à la fonction de prédiction utilisée pour la journalisation de ladite opération et fournissant un résultat prédit pour l'opération rejouée; interception du résultat de l'opération rejouée et transmission du résultat prédit, en tant que résultat forcé, au processus de reprise en lieu et place du résultat issu de l'opération rejouée.

Il est ainsi possible de retrouver le résultat réel obtenu lors de la journalisation bien qu'il n'ait pas été mémorisé, et de vérifier que le résultat rejoué lui est conforme, ou de le forcer s'il ne l'est pas.

De plus, pour chaque opération pour laquelle les données de journalisation ne comprennent pas de résultat journalisé, la phase de gestion complémentaire comprend une incrémentation d'une valeur de séquencement représentant ladite opération rejouée.

Ainsi, l'incrémentation permet de suivre l'avancement du processus de reprise, sans intervenir dans son déroulement tant que cela n'est pas utile ou nécessaire pour maintenir un déroulement conforme. Le fait de ne pas intervenir plus que nécessaire constitue alors une économie de travail - 11 - pour le processus ou pour l'application gérant le rejeu, ou pour l'ordinateur qui les exécute.

En particulier dans le cas d'une séquence comportant à la fois des opérations prédites et des opérations non prédites, il est possible d'obtenir un rejeu qui corresponde au déroulement du processus journalisé, voire même qui lui soit exactement identique, tout en utilisant des données de journalisation d'un volume réduit et dont la mémorisation requiert moins de charge de travail.

Le procédé selon l'invention peut être mis en oeuvre en particulier pour gérer l'ensemble des opérations réalisant, au sein de la séquence gérée, des évènements d'au moins un type.

Il est ainsi possible de réaliser une journalisation ou un rejeu qui représente la totalité du déroulement du processus vis à vis de certains éléments particuliers, par exemple un autre processus, un utilisateur, ou une ressource particulière.

De plus, ce procédé peut être utilisé pour gérer l'ensemble des opérations identifiées comme étant de nature non déterministe ou renvoyant un résultat identifié comme étant de nature non déterministe.

Dans différentes variantes, cette méthode d'optimisation heuristique peut bien sûr être combinée de différentes façon avec d'autres.

Par exemple au sein d'une solution où seules les opérations déterministes ne sont pas journalisées, il est ainsi possible d'optimiser encore plus la charge de travail en ne journalisant qu'une partie des opérations restantes, c'est à dire seulement les opérations non déterministes et non prédites.

Plus particulièrement, le procédé selon l'invention gère l'ensemble des opérations réalisant, au sein de la séquence gérée, des évènements non déterministes internes au processus géré, ou à son application, ou à l'ordinateur qui les exécute.

En coordination avec une gestion des évènements externes, l'invention permet ainsi de gérer l'intégralité du déroulement du processus, en particulier pour permettre une journalisation en cours d'exploitation tout en limitant le ralentissement de l'application gérée.

- 12 - Lorsque la gestion, par exemple journalisation ou rejeu, s'applique à au moins une opération déclenchée par une instruction exécutée depuis un fichier exécutable et comprenant un appel à une routine, dite d'origine, externe audit fichier exécutable, Selon un mode de réalisation du procédé permettant une implémentation souple et peu intrusive, l'exécution de ladite instruction réalise alors un appel à une routine dite modifiée, en lieu et place de ladite routine d'origine, cette routine modifiée réalisant ou déclenchant la mise en oeuvre du procédé.

La routine modifiée peut en particulier comprendre au moins une instruction exécutée au sein du logiciel système et qui réalise un appel à au moins un agent logiciel de journalisation ou de rejeu, assurant la mise en oeuvre du procédé et étant exécuté dans l'espace mémoire utilisateur de l'ordinateur du processus géré, ou processus cible.

Il est ainsi possible de réaliser une implémentation de cette gestion essentiellement au sein de l'espace utilisateur, par exemple de façon à minimiser les interventions dans le logiciel système et limiter les risques d'erreurs et d'hétérogénéité entre différents ordinateurs au sein du réseau.

Plus particulièrement, la routine modifiée comprend une instruction de test vérifiant si l'instruction qui l'a appelée est exécutée dans le cadre d'une journalisation ou d'un rejeu, ce test conditionnant alors l'appel à un agent de gestion de type journalisation ou respectivement de type rejeu.

La mise en oeuvre de la gestion selon différents usages peut ainsi être réalisée avec une meilleure souplesse par les mêmes agents, par exemple par une même application intermédiaire et/ou un même module noyau, qu'il s'agisse de journalisation ou de rejeu.

La fonction de prédiction peut utiliser différents types de traitements logiciels, en particulier basés sur l'état du processus, de son application, ou des ressources qu'ils sont seuls à pouvoir modifier.

Ainsi, dans un mode de réalisation particulier, le procédé selon l'invention utilise au moins une fonction de prédiction comprenant un traitement logiciel déterministe qui dépend des caractéristiques d'un ou plusieurs événements externes d'au moins un type, survenus précédemment au cours du déroulement du processus géré.

- 13 - Selon une particularité, le procédé selon l'invention journalise au moins une première opération en utilisant une première fonction de prédiction et une deuxième opération en utilisant une deuxième fonction de prédiction.

En utilisant plusieurs fonctions de prédiction différentes, il est alors possible d'adapter le mode de journalisation aux circonstances de façon à en optimiser les performances, en utilisant pour le rejeu de chaque opération la même fonction de prédiction utilisée que lors de la journalisation de l'opération correspondante.

Selon une variante, le procédé utilise une fonction de prédiction choisie par sélection ou combinaison déterministe au sein d'une pluralité de fonctions déterminées, en particulier en fonction du type d'opération gérée, par exemple selon sa nature ou selon la ressource qu'elle concerne. Lors du rejeu, ce choix de la fonction de prédiction pourra alors se reproduire de façon identique ou correspondante au choix effectué lors de la journalisation.

Selon une autre variante, le choix de la fonction de prédiction utilisée dépend de l'évolution d'une grandeur mesurée ou calculée au fur et à mesure du déroulement du processus journalisé, par exemple l'évolution du taux de réussite de la fonction de prédiction au cours de la journalisation pourra déterminer un changement de cette fonction ou de certains de ses paramètres.

Selon l'invention, le fichier journal peut alors comprendre des données représentant au moins un choix de fonction de prédiction ou de paramètres conditionnant un tel choix. La mémorisation de la nature et/ou du moment de ce changement lors de la

journalisation permettra alors de réaliser le même changement au même stade du déroulement lors du rejeu.

Dans le cadre d'une amélioration des fonctionnalités de simulation ou de rejeu, un autre objectif de l'invention est d'améliorer la gestion du fonctionnement d'une application ou d'au moins un des ces processus.

Le procédé selon l'invention réalise alors une gestion de fonctionnement d'au moins un processus applicatif dit journalisé et comprend les étapes suivantes: journalisation de l'ensemble des évènements d'au moins un type déterminé survenus au cours du déroulement dudit processus journalisé à partir d'un point déterminé dit de reprise et jusqu'à un point dit d'interruption, et mémorisation d'un journal issu de ladite journalisation; à partir d'un processus de reprise dans un état correspondant à l'état de point de reprise du processus journalisé, rejeu par ledit processus de reprise desdits évènements à partir dudit journal, amenant ainsi le processus de reprise à un état correspondant à l'état du processus journalisé au point d'interruption.

L'état du processus journalisé au point de reprise peut en particulier être capturé et mémorisé sous la forme de données de point de reprise, qui sont utilisées pour restaurer le processus de reprise à l'état de point de reprise avant de lui appliquer l'étape de rejeu.

Le procédé selon l'invention peut en particulier être utilisé pour réaliser un rejeu d'une succession d'évènements comprenant des évènements externes ainsi que des évènements internes. L'invention propose alors d'effectuer le rejeu des évènements externes par injection ou simulation de chacun de ces évènements externes auprès du processus de reprise. Les évènements internes qui suivent chaque événement externe dans le déroulement du rejeu sont alors exécutés par le processus de reprise de sa propre initiative en réaction à la survenue et/ou au traitement de l'événement externe qui les précède immédiatement. Le processus de reprise réalise alors le rejeu d'au moins une séquence journalisée d'évènements internes en réaction à la survenue d'un événement externe déclenché par un agent de rejeu externe.

Au sein des fonctionnalités de gestion de fonctionnement, un objectif de l'invention est également d'améliorer les outils de mise au point ou d'analyse ou de reproduction d'au moins une partie du fonctionnement d'une application, ou d'au moins un des processus de cette application.

La gestion de fonctionnement peut alors réaliser un suivi du déroulement d'une application, dite application tracée, par exemple dans le cadre de la mise au point de cette application ( debugging ). Ce suivi - 15 s'applique alors à au moins un processus de l'application tracée et comprenant les étapes suivantes: à partir d'un état déterminé de l'application tracée, journalisation d'une pluralité de séquences journalisées successives et contiguës constituant une séquence étudiée au sein du déroulement de l'application tracée; réalisation d'une succession commandée d'étapes de rejeu réalisant un déroulement commandé de la suite des séquences journalisées, réalisant ainsi un rejeu de la séquence étudiée selon un rythme commandé.

Au sein des fonctionnalités de gestion de fonctionnement, un objectif de l'invention est aussi d'améliorer les outils de fiabilisation du fonctionnement d'une application, ou d'au moins un des ces processus.

Une telle fiabilisation peut être obtenue en particulier à travers le maintien d'une continuité améliorée du fonctionnement de l'application du point de vue des services qu'elle fourni à ses clients. Lors d'une défaillance, une telle continuité peut être totale, c'est-à-dire que les clients n'ont pas à recommencer la moindre opération pour obtenir le même service. une telle continuité peut également être partielle, c'est-à-dire en diminuant le plus possible le nombre et/ou la complexité des opérations que des clients auront à faire à nouveau ou en plus pour obtenir le même service ou une partie de ce service.

Dans cet objectif, l'invention propose de mettre en oeuvre la gestion de fonctionnement pour fiabiliser le fonctionnement d'une première application, dite application fiabilisée, exécutée dans au moins un premier noeud, dit noeud opérationnel, d'une architecture multiordinateurs communicante, dite cluster.

Cette fiabilisation comprend une restauration, dans un état correspondant à l'état de l'application fiabilisée au point de reprise, d'une deuxième application dite de secours, au sein d'un deuxième noeud du cluster, dit noeud stand-by.

Selon les modes de réalisation ou selon les situations, la restauration peut se faire hors de toute défaillance et à titre préventif, ou être réalisée - 16 - après la détection d'une défaillance à partir de données mémorisées auparavant.

La fiabilisation comprend en outre les étapes suivantes: -journalisation du déroulement de l'application fiabilisée depuis le point de reprise, et mémorisation, à l'extérieur du noeud opérationnel, des évènements journalisés dans au moins un fichier journal; détection d'une défaillance au sein du noeud opérationnel; utilisation dudit fichier journal pour rejouer dans l'application de secours les évènements journalisés dans l'application fiabilisée depuis le point de reprise, restaurant ainsi l'application de secours dans un état correspondant à l'état de l'application fiabilisée après le dernier évènement journalisé.

L'invention propose également un système comprenant un ordinateur mettant en oeuvre un tel procédé de gestion, ou un réseau d'ordinateurs collaborant entre eux et incluant au moins un tel ordinateur.

Plus particulièrement, l'invention propose un tel réseau utilisant une application de type middleware mettant en oeuvre le procédé selon l'invention pour gérer le fonctionnement d'au moins une application exécutée au sein dudit réseau.

L'invention est applicable en particulier au sein d'un environnement de type middleware , par exemple réalisant une gestion de réseau et/ou d'applications distribuées dans un ou plusieurs réseaux.

D'autres particularités et avantages de l'invention ressortiront de la description détaillée d'un mode de mise en oeuvre nullement limitatif, et des dessins annexés sur lesquels: la figure 1 est un schéma symbolique illustrant l'architecture fonctionnelle d'une application intermédiaire mettant en oeuvre l'invention; la figure 2 est un schéma symbolique résumant l'organisation de la journalisation des évènements sur un noeud opérationnel; la figure 3 est un schéma symbolique illustrant le fonctionnement de la journalisation des évènements externes d'un noeud opérationnel et leur sauvegarde sur un noeud secondaire; la figure 4 est un schéma symbolique illustrant le fonctionnement de la journalisation des évènements internes d'un noeud opérationnel et leur sauvegarde sur un noeud secondaire; les figures 4a et 4b illustrent deux variantes du fonctionnement d'un mécanisme de transmission groupée des données de journalisation d'une séquence d'évènements internes; la figure 5 est un schéma symbolique illustrant le fonctionnement du re-jeu des évènements externes journalisés lors de la mise à jour d'une application de reprise sur un noeud secondaire; la figure 6 est un schéma symbolique illustrant le fonctionnement du re-jeu des évènements internes lors de la mise à jour d'une application de reprise sur un noeud secondaire; la figure 7 est un schéma symbolique de l'utilisation d'une technique d'interposition, lors d'un appel à une routine système, pour insérer des instructions supplémentaires dans l'exécution de cette routine; la figure 8 est un schéma temporel illustrant le déroulement du re-jeu d'un évènement interne pour deux processus concurrents, utilisant un ajout d'instructions supplémentaires dans une routine système pour obtenir le même déroulement que lors de la journalisation; les figures 8a et 8b illustrent le fonctionnement de la journalisation et du rejeu des évènements internes de façon à ne traiter que les évènements non déterministes; les figures 8c et 8d sont des schémas illustrant le fonctionnement de l'optimisation le journalisation interne par compression et respectivement décompression heuristique; les figures 9 et 10 sont des schémas symboliques illustrant un exemple d'optimisation, par compression heuristique, de la journalisation d'évènements internes non- déterministes dans des cas d'ordonnancement différent d'évènements internes entre deux évènements externes, au sein de plusieurs processus simultanés sur un noeud opérationnel; la figure 11 est un schéma symbolique illustrant le fonctionnement non déterministe d'une opération de lecture par la routine read d'un système de type Unix ; la figure 12 est un schéma symbolique illustrant un comportement de cette même routine, rendu déterministe par changement dynamique de sémantique; les figures 13 et 14 sont des schémas symboliques illustrant le fonctionnement non déterministe d'une opération de réception de données dans l'application, en provenance de deux canaux concurrents du système d'exploitation, par les routines select ou poli d'un système de type Unix ; la figure 15 est un schéma symbolique illustrant un comportement de cette même routine, rendu déterministe par changement dynamique de sémantique; la figure 16 est un schéma illustrant les interactions mises en oeuvre par un changement de sémantique.

En particulier dans le déroulement de l'application maître, les opérations de journalisation représentent une charge de travail pour le noeud opérationnel, et peuvent être la cause d'une baisse de performances du fait de l'action de l'application intermédiaire.

La figure 1 illustre l'architecture fonctionnelle d'une application intermédiaire mettant en oeuvre l'invention.

Au sein d'un cluster, une application maître AOP, par exemple une application transactionnelle, rend un certain nombre de services à des utilisateurs ou clients, en particulier par entrée et sortie d'informations sous différentes formes. Au sein du cluster, cette application peut être mono- ou multi-tâches (processus ou threads ), et utilise un certain nombre de ressources. En particulier, ces ressources peuvent être des données, par exemple sous la forme d'espaces de mémoire de travail, de mémoire partagée, ou de fichiers de données, ou être des indicateurs d'état, par exemple sous la forme de sémaphores, ou de mutex.

L'application maître est exécutée sur un ou plusieurs ordinateurs formant un noeud, appelé noeud opérationnel OP ou noeud primaire. Une application de gestion de fonctionnement, dite application intermédiaire INT, est exécutée, en une ou plusieurs parties, sur un ou plusieurs noeuds du cluster.

- 19 - Selon les modes de réalisation, cette application intermédiaire peut gérer différents aspects du fonctionnement de l'application maître au sein du cluster. Une telle application intermédiaire INT peut en particulier travailler en parallèle avec un logiciel de gestion intermédiaire du cluster de type middleware , être intégrée au sein d'un tel middleware, ou constituer elle-même une forme de middleware.

A travers les fonctionnalités décrites ici, l'application intermédiaire INT peut être utilisée en particulier pour réaliser une réplication de tout ou partie d'une application maître au sein du cluster. La réplication d'une application maître peut fournir une autre application qui sera alors appelée application de reprise.

Les fonctionnalités décrites ici, en particulier dans le cadre d'une telle réplication, permettent également de réaliser une fiabilisation de l'application maître, ou un traçage ou une étude de cette application pour réaliser des travaux de mise au point ( debugging ), d'ajustement ou de développement. Une utilisation en fiabilisation comprendra par exemple l'application de reprise comme application de secours ou de remplacement. Une utilisation en traçage ou mise au point comprendra par exemple une journalisation JOP et/ou un re-jeu RSB d'évènements, comme décrit ciaprès, selon un rythme ralenti ou commandé, d'évènements journalisés.

Les modes de réalisation appliqués à la fiabilisation ne sont donc décrits ici qu'à titre d'exemples non limitatifs.

En différents points du déroulement de l'application maître AOP à fiabiliser, dits points de reprise ou checkpoints , de façon régulière ou sur évènement, l'application intermédiaire INT crée ou maintient à jour au moins une application de reprise ASB exécutée sur un noeud dit secondaire, ou stand by SB.

Cette application de reprise est crée ou maintenue à jour par exemple par une méthode de réplication par capture et restauration d'application, dite méthode de reprise. Cette méthode de réplication comprend des opérations de capture CAP d'état de l'application maître suivies d'opérations de restauration RES de cet état, c'est-à-dire de l'état de ses processus et de tout ou partie des ressources qu'elle utilise.

- 20 - Lors d'une telle opération de capture CAP, l'état de l'application maître AOP est sauvegardé sous forme de données formant un état de point de reprise EPR.

Certaines ressources de l'application maître, en particulier des fichiers de données représentant un volume important sur des moyens de mémorisation comme des disques durs, peuvent être maintenues à jour au fil de l'eau en plusieurs exemplaires sur plusieurs supports de stockage différents, constituant des fichiers de données de reprise sur des disques miroirs ou des disques partagés. Dans ce cas, les données formant un état de point de reprise peuvent comprendre des informations constituant des références à ces fichiers de données de reprise.

Lorsqu'un point de reprise ou une réplication est basé sur une capture d'état reprenant l'ensemble de l'environnement d'exécution et des ressources de l'application maître, soit directement soit par des références à des fichiers de données de reprise, ce point de reprise ou cette réplication peut être qualifié de holistique.

A partir des données d'un état de point de reprise EPR, l'application intermédiaire INT peut effectuer une restauration RES, par création ou mise à jour, d'une application de reprise ASB. Cette restauration peut s'effectuer de façon régulière ou sur évènement déclenchant, par exemple à la demande d'un administrateur ou d'un mécanisme de gestion de la charge de travail du cluster. Cette restauration peut également s'effectuer après une défaillance du noeud opérationnel, détectée par des moyens de détection, l'application de reprise pouvant alors être utilisée comme une application de secours permanente ou non.

En cas de besoin, l'application intermédiaire organise un basculement de tout ou partie des services de l'application maître vers une ou plusieurs applications de reprise. Pour que ce basculement se fasse de façon transparente pour les clients, l'application intermédiaire peut utiliser une méthode d'interposition par metaprocess gérant des adresses réseau virtuelles, et réalisant une migration des connexions des clients depuis l'application maître vers ces applications de reprise. L'application intermédiaire peut également utiliser une méthode d'interposition par metaprocess gérant des identifications virtuelles de processus (PID - 21 - virtuels), permettant de restaurer les communications de ces processus clones de façon identique à celles de leurs processus originaux.

Ces techniques peuvent être par exemple celles décrites dans le brevet FR 2 843 210.

Une restauration suivie d'un basculement partiel ou total peuvent également s'effectuer hors défaillance, par exemple pour répartir la charge de travail de l'application maître ou permettre une maintenance de certains éléments du noeud opérationnel ou du réseau.

De façon à ce que cette défaillance et/ou ce basculement soient le plus transparents possible du point de vue des clients, l'application intermédiaire enregistre tout ou partie des évènements affectant l'application maître entre plusieurs points de reprise, et les sauvegarde sous la forme d'un ou plusieurs journaux ou Iogs .

A l'issue d'une restauration à partir d'un état de point de reprise, l'application de reprise se trouve dans l'état de l'application maître lors de l'établissement de ce point de reprise. A partir de cet état, l'application intermédiaire utilise les journaux sauvegardés depuis ce point de reprise pour faire ré-exécuter, ou rejouer, par l'application de reprise, les évènements qui ont eu lieu dans l'application maître depuis ce point de reprise. Cette ré-exécution, ou re-jeu, est réalisée de façon à ce que l'application de reprise arrive à l'état où était l'application maître après le dernier évènement sauvegardé, par exemple à un état précédant immédiatement une défaillance.

L'application intermédiaire peut également réaliser une virtualisation de certaines ressources vis-à-vis de l'application de reprise, par exemple dans le cas où ces ressources ont changé depuis le point de reprise restauré, pour lui permettre d'effectuer sa ré-exécution sans interférer avec l'état réel de ces ressources, tant qu'elle n'est pas revenu à un état correspondant à cet état réel.

Parmi les évènements à journaliser sur le noeud opérationnel et à rejouer sur le noeud secondaire, on peut distinguer des évènements dits externes et des évènements dit internes.

Les évènements externes sont définis comme extérieurs à l'application concernée, en l'occurrence l'application maître. Ainsi, on peut - 22 qualifier d'évènements externes ceux qui sont déclenchés dans l'application par des actions ou des informations provenant de l'extérieur de cette application, c'est-à-dire en particulier provenant d'éléments matériels ou logiciels qu'elle ne contrôle pas. Ces évènements externes peuvent prendre la forme d'entrées de données ou de signaux, par exemple des entrées d'interfaces matérielles, telles que clavier ou souris, ou des informations arrivant par le réseau et provenant du monde extérieur, comme d'un client dans le cas d'une application client-serveur. Le plus souvent, ces évènements externes ne peuvent pas être déduits ou recréés à partir de l'environnement de l'application. Ces évènements externes sont journalisés du côté de l'application maître et peuvent être rejoués du côté de l'application de reprise.

Si l'application concernée, parfois appelée application cible, comporte des éléments exécutés sur un autre noeud que le noeud primaire, les évènements dans cette application mais extérieurs au noeud primaire peuvent également être traités comme des évènements externes.

Les évènements internes sont définis comme internes à l'application maître ou au noeud qui l'exécute, par exemple sous forme d'entrées de données ou de signaux reçu par un processus de cette application et provenant d'un autre processus qui fait aussi partie de l'application. Ces évènements internes peuvent être reçus directement ou par l'intermédiaire de mécanismes ou agents logiciels extérieurs à l'application mais faisant partie du noeud qui l'exécute, par exemple par l'intermédiaire d'applications partenaires ou faisant partie du système d'exploitation, comme l'agent Inter Process Communication (IPC) d'un système de type Unix. Ces évènements internes peuvent comprendre des évènements de transmission de messages ( message passing events ), par exemple provenant de files d'attente ( pipe , signal queues ou message queues ) ou d'interfaces de type socket . Ces évènements internes peuvent comprendre également des évènements d'accès à des mémoires partagées ( shared memory access ), par exemple des sémaphores ou des mutex .

Au cours du déroulement d'une application, les évènements internes sont particulièrement nombreux, par exemple par rapport aux évènements -23 externes. De plus, les évènements internes correspondent à des opérations d'exécution rapide, ou de faible latence, en particulier par rapport à la durée d'une opération de journalisation, surtout lorsque celle-ci comprend une transmission réseau ou une mémorisation sur un support permanent comme un disque dur. A titre d'exemple, une opération de journalisation peut représenter une durée de 10 à 10000 fois plus élevée qu'un évènement interne.

Ainsi qu'illustré en figure 2, la journalisation JOP des évènements survenus depuis un point de reprise est réalisée de façon différente pour les 10 évènements externes et internes, et sauvegardée séparément.

Un noeud opérationnel OP, raccordé au cluster par un réseau, comprend un espace matériel, supportant un espace système, qui supporte lui-même un espace dit espace utilisateur . L'espace matériel, qui peut être défini par référence à une ou plusieurs des couches les plus basses du modèle OSI, comprend en particulier les dispositifs matériels d'exécution de processus, mémoire physique et processeurs, et de communication, tels que des cartes réseau. Typiquement, une grande part des évènements externes transitent par l'espace matériel, sous forme de communications passant par le réseau.

L'espace système, qui peut être défini par référence à une ou plusieurs des couches intermédiaires du modèle OSI, comprend en particulier le système d'exploitation. Cet espace système comprend divers mécanismes ou agents logiciels gérant les communications des applications avec le monde extérieur à travers l'espace matériel, par exemple sous la forme de sockets dans un système Unix, ou gérant les communications entre plusieurs processus d'applications, par exemple sous la forme de pipe et d'IPC dans un système Unix.

L'espace utilisateur, qui peut être défini par référence à une ou plusieurs des couches les plus élevées du modèle OSI, comprend les processus faisant partie des diverses applications exécutées par le noeud, telles que l'application maître et l'application intermédiaire. Dans cet espace utilisateur sont exécutés plusieurs processus P1, P2, et Pn faisant partie d'une ou plusieurs applications, par exemple l'application maître. Ces processus échangent des informations avec l'extérieur par l'intermédiaire - 24 - d'un ou plusieurs sockets de l'espace système, et entre eux par l'intermédiaire d'un ou plusieurs éléments pipes de l'espace système. Certains de ces processus accèdent également, de façon concourante et gérée par des ressources d'état (non représentées), à des ressources de mémoire partagée SHM ( shared memory ).

Lors de l'établissement d'un point de reprise, l'application intermédiaire peut démarrer un ou plusieurs nouveaux journaux, ou enregistrer une marque de point de reprise ( checkpoint mark ) dans le ou les journaux en cours.

Il est à noter que le terme de utilisateur , en particulier dans le cas de I < espace utilisateur ou du journal d'évènements internes user log (décrit plus loin), est ici à prendre dans un sens de utilisateur de l'espace système . C'est-à-dire que l'espace utilisateur est accessible aux applications utilisant le noeud et son système d'exploitation, même si cet espace utilisateur n'est pas directement accessible à des personnes ou ordinateurs communiquant avec ces applications, et qui seront alors qualifiés de clients .

Les évènements externes sont sauvegardés dans un journal, constitué d'un ou plusieurs fichiers KL, appelé kernel log (cf.figure 2).

Pour réaliser cette sauvegarde, les données représentant ces évènements sont lues, après leur arrivée au sein du noeud, à un bas niveau des couches de la classification internationale OSI. Préférentiellement, ces évènements externes sont lus dans l'espace système, par exemple dans le kernel, avant d'être démultiplexés, et avant d'être traités par la pile ( protocol stack ).

Du fait que cette journalisation se fait directement depuis l'intérieur de l'espace système, il est possible d'éviter des pertes de performances causées par des écritures de tampon ou de changements de contexte non nécessaires.

La figure 3 illustre plus en détails le fonctionnement de la journalisation d'évènements externes, en particulier lorsqu'ils prennent la forme de messages au protocole TCP-IP. L'application maître s'exécute sur le noeud opérationnel OP et comprend au moins un processus P1. L'application intermédiaire comprend d'une part un module IPIogOP comprenant un processus de contrôle CtIOP, s'exécutant sur le noeud - 25 opérationnel OP, et d'autre part un module IPIogSB comprenant un processus de contrôle CtISB s'exécutant sur un noeud secondaire SB. Sur chacun de ces noeuds OP et SB, le processus de contrôle configure et gère le fonctionnement d'un mécanisme ou agent logiciel disp (DISPP, DISPS) , s'exécutant dans l'espace système du noeud concerné.

Dans le cas d'un système de type Unix, cet agent disp comprend en particulier un module noyau (kernel), chargé dans l'espace système. Ce module noyau est chargé dynamiquement dans le noyau au moment du démarrage (boot) du système, ou bien avant le lancement de l'application à gérer ou à fiabiliser. Du point de vue de la structure fonctionnelle, par exemple en référence aux couches OSI, ce module s'insère sous la couche IP, en particulier entre la couche IP et la couche network device qui dépend de l'espace matériel.

Cet agent disp peut intercepter et stocker les messages, reçus du 15 réseau à destination de la couche TCP, dans une file d'attente QOP et QSB, fonctionnant en transmission ou en réception selon les besoins.

En étape 1, un message provenant d'un client, à destination du processus P1, est reçu par l'agent disp au sein de l'espace système du noeud opérationnel OP, qui le garde dans une file d'attente de transmission QOP.

En étape 2, un message de journalisation, représentant le message reçu, est transmis par l'agent DISPP du noeud primaire à un noeud secondaire SB, où un agent DISPS le reçoit en file d'attente de réception QSB.

Le noeud opérationnel OP peut en particulier communiquer avec un ou plusieurs noeuds secondaires SB par sur un réseau local (LAN) séparé, en utilisant un dispositif réseau différent de celui utilisé pour communiquer avec les clients.

Plusieurs de ces noeuds secondaires peuvent également être abonnés à une adresse de type multicast selon le standard RFC 1112 pour communiquer avec le noeud opérationnel OP. L'utilisation d'une adresse multicast, par exemple définie par le standard RFC 1112 Host Extensions for IP Multicasting ) comme une adresse IP dans la plage située entre 224.0.0.0 et 239.255.255.255, permet ainsi au noeud opérationnel de - 26 -n'émettre qu'une seule fois les messages destinés simultanément à plusieurs noeuds secondaires, sans pour autant alourdir le réseau par une émission qui serait envoyée à toutes les adresses du réseau.

Préférentiellement, le message de journalisation transmis d'un noeud OP à un autre noeud SB contient la totalité du ou des paquets reçus au niveau de la couche physique, sous leur forme originale. C'est-à-dire qu'il contient les données destinées à l'application maître, mais aussi les données de réseau telles que les entêtes Ethernet, IP, et TCP.

En étape 3, le noeud secondaire SB transmet un message d'accusé de 10 réception au noeud opérationnel OP.

En étape 4, sur le noeud opérationnel OP et une fois que l'accusé de réception correspondant a été reçu, le message est retiré de la filed'attente de transmission QOP et transmis à la couche TCP.

Dans une étape 4' parallèle, le noeud secondaire SB enregistre le message dans un journal, par exemple le journal KL kernel log des évènements externes, et le retire de la file d'attente de réception QSB.

En étape 5, sur le noeud opérationnel OP, le processus P1 de l'application maître lit le message dans l'élément socket et le traite pour la suite de son fonctionnement.

Du fait que la prise en compte, par l'application maître, du message arrivant ne se fait qu'après accusé de réception de la part du noeud secondaire SB, l'invention permet d'être sûr qu'un message non journalisé ne puisse être traité par l'application. Par exemple, un tel message non lu peut alors être récupéré par les fonctions de retransmission du protocole TCP.

Si une marque de point de reprise est prévue dans le journal kernel log , le processus de contrôle CtISB du noeud secondaire y enregistre des données représentant cette marque de point de reprise.

Le contenu d'un évènement interne dépend directement de l'environnement local, c'est-à-dire au sein du noeud, du contenu des évènements externes précédents, et de questions d'ordonnancement au sein d'un processeur ou de gestion de plusieurs processeurs ou ordinateurs fonctionnant en parallèle au sein d'un noeud. De ce fait, dans la plupart des - 27 - cas, seul l'ordre de ces évènements influe sur le comportement ultérieur de l'application.

L'application intermédiaire INT se contente de journaliser l'ordre de ces évènements internes, sans mémoriser le détail, ou les paramètres, de chacun d'eux. Ce choix permet alors de diminuer le volume des données à mémoriser pour la journalisation JOP de ces évènements internes, et donc de minimiser la perte de performance engendrée dans le noeud opérationnel et l'application maître par cette journalisation.

Les évènements internes sont sauvegardés dans un journal, constitué 10 d'un ou plusieurs fichiers, appelé user log (cf. figure 2).

Ainsi qu'illustré en figure 4, les noeuds primaire OP et secondaire SB communiquent par un système matériel et/ou logiciel d'interconnexion haute vitesse HSI. Ce système HSI permet des transferts de données entre le processus de journalisation PIogOP du noeud primaire OP et un processus de journalisation PlogSB d'un noeud secondaire SB, et ce directement en contournant tout ou partie des systèmes d'exploitation de ces deux noeuds. Un tel système HSI peut être implémenté, selon des moyens connus, en utilisant les contrôleurs d'interface réseau existant, comme les cartes réseaux et leur logiciels pilotes. Un tel système HSI peut également être réalisé en utilisant des dispositifs réseau haute performance, en parallèle ou en combinaison avec le reste du réseau interne au cluster.

Les évènements internes sont scrutés et lus au sein de l'espace utilisateur du noeud opérationnel OP par un processus de journalisation PlogOP de l'application intermédiaire. Celui-ci transmet alors au processus de journalisation PlogSB du noeud secondaire, par le système de connexion haute vitesse HSI, des données représentant ces évènements internes et/ou leur ordre de survenance. Ces données sont alors sauvegardées dans un ou plusieurs fichiers formant le journal User log .

Si une marque de point de reprise est prévue dans le journal user log , le processus de journalisation PIogSB du noeud secondaire y enregistre des données représentant cette marque de point de reprise.

De façon préférentielle, le processus de journalisation PIogOP lit les évènements internes à leur retour , c'est-à-dire lorsque le résultat en est - 28 - déjà produit mais pas encore transmis au processus de l'application maître qui en a demandé l'exécution.

Cette lecture se fait par exemple en interceptant les appels systèmes d'entrée/sortie, par exemple un accès à un pipe , et les réponses à des opérations de verrouillage de segments de mémoire partagée SHM.

Cette interception peut être réalisée en insérant des instructions d'enregistrement ( recording probes ou sondes d'enregistrement) dans le contenu de tout ou partie des routines fournies par le système et appelées par l'application. Ces sondes d'enregistrement sont ajoutées sous forme d'instructions supplémentaires, formant par exemple un épilogue à la fin du code de la routine d'origine tel qu'illustré en figure 7, en utilisant une technique d'interposition dynamique par metaprocess , comme précisé plus loin.

Le journal des évènements internes, le user log , comprend ainsi une succession d'enregistrements représentant chacun un évènement interne. Ces évènements peuvent être journalisés dans un seul fichier, et comprendront alors une identification des ressources et/ou des processus concernés. Ils peuvent également être journalisés dans plusieurs fichiers, à raison par exemple d'un fichier par ressource, ou par processus, ou par combinaison des deux.

Pour un fichier correspondant à une ressource déterminée, chacun de ces enregistrements comprend en particulier les champs suivants: un numéro de séquence de l'évènement concerné, au sein d'une séquence propre à chaque ressource, et qui est incrémenté à chaque nouvel évènement ou opération sur cette ressource; une information temporelle, représentant par exemple la durée écoulée depuis le dernier évènement concernant cette ressource; un type d'évènement, par exemple read ou write pour une ressource d'entrée/sortie ( I/O ) ou lock ou unlock pour un sémaphore; 29 - un résultat, c'est-à-dire une valeur dans le cas d'une opération d'entrée/sortie ou une identification d'un processus obtenant un accès exclusif dans le cas d'un lock .

Ce résultat sera en particulier utilisé pour réaliser une virtualisation de ressources, par exemple lors du re-jeu des évènements d'un journal par une application de reprise ou de secours restaurée sur un noeud secondaire. Le résultat mémorisé constituera alors une valeur à forcer comme résultat d'une demande d'opération I/O faite au cours du re-jeu, ou une identification virtuelle de processus (PID virtuel) dans le cas d'une tâche obtenant un lock .

De façon à limiter les pertes de performances dues à la transmission des données de journalisation, depuis le noeud opérationnel vers un ou plusieurs noeuds secondaires, il est utile de regrouper l'envoi de données représentant plusieurs évènements internes.

Pour cela, l'application intermédiaire peut utiliser une combinaison de plusieurs méthodes différentes, par exemple mises en oeuvre par le processus de journalisation PIogOP dit primaire du noeud opérationnel OP.

On comprend que l'évolution interne d'une application n'a pas d'importance vis-à-vis du monde extérieur, par exemple vis-à-vis de ses clients, tant que cette opération n'envoie rien vers le monde extérieur. Une application de reprise, restaurée à partir d'un point de reprise et d'un journal, ne comportera aucune interruption de ses services au monde extérieur si ce journal n'inclut pas les évènements internes qui ont eu lieu depuis le dernier message externe émis par l'application maître qui a été journalisée.

Selon une première méthode, ce processus de journalisation primaire PIogOP envoie les données de journalisation interne au fil de l'eau mais en mode asynchrone et au fur et à mesure des possibilités de transmission, sans bloquer le fonctionnement de l'application maître, tant que celle- ci n'envoie pas de message externe. Lors du prochain envoi par l'application maître d'un message externe, des moyens de détection en avertissent le processus de journalisation primaire qui bloque ou suspend l'émission de ce message externe, et possiblement l'exécution d'un ou plusieurs processus de l'application maître. Ce blocage est alors maintenu jusqu'à ce que la - 30 - totalité des données de journalisation interne en cours de transmission asynchrone aient été envoyées, ou jusqu'à ce qu'il ait reçu un accusé de réception pour ces données.

Selon une deuxième méthode, le processus de journalisation primaire PIogOP mémorise dans un tampon ou cache les données de journalisation interne représentant plusieurs évènements internes successifs, sans les transmettre immédiatement au processus de journalisation PIogSB du noeud secondaire. Il ne les transmet que lorsque leur nombre atteint un seuil déterminé, ou lorsque l'application doit envoyer un message dit externe au monde extérieur, par exemple des données ou un signal à destination d'un client ou d'un processus externe. Lors du prochain envoi par l'application maître d'un message externe, des moyens de détection en avertissent le processus de journalisation primaire qui bloque ou suspend l'émission de ce message externe et possiblement l'exécution d'un ou plusieurs processus de l'application maître. Ce blocage est alors maintenu jusqu'à ce que le processus de journalisation primaire ait transmis au noeud secondaire les données de journalisation restant dans le cache, ou jusqu'à ce qu'il ait reçu un accusé de réception pour ces données.

Dans ces deux méthodes, le fait d'avoir à émettre un message externe constitue un événement sortant externe, qui constitue un type d'événement que l'on peut qualifier de bloquant, c'est à dire qui nécessite que la journalisation des évènements précédents soit clôturée avant exécution de cet évènement. Selon les modes de réalisation, d'autres types d'évènements peuvent aussi être choisis comme bloquants, le plus souvent en plus des évènements sortants externes.

La figure 4a illustre le fonctionnement d'une journalisation d'évènements avec regroupement des données de journalisation DJ de plusieurs évènements internes EVI avant transmission à l'extérieur du noeud primaire OP.

En une étape 1, le processus de journalisation PIogOP détecte, au sein du déroulement d'un processus journalisé P1, la survenue d'un d'événement EVI.

- 31 - En une étape 2, le processus de journalisation PlogOP vérifie si l'événement détecté EVI est d'un type devant être considéré comme bloquant.

En une étape 3, si l'événement EVI n'est pas d'un type bloquant, la journalisation de cet événement produit une donnée de journalisation DJ.

En une étape 4, cette donnée de journalisation DJ est mémorisée au sein du noeud primaire OP dans une structure ordonnée constituant un journal tampon JSlLocal, avant d'attendre la détection d'un prochain événement.

En une phase 5, lorsque l'événement détecté EVI est d'un type bloquant, le processus de journalisation PIogOP réalise une phase de clôture de la séquence courante des évènements internes précédemment journalisés dans le journal tampon JSlLocal.

Cette phase 5 comprend une étape 6, où l'exécution du processus 15 journalisé P1 est suspendu en attendant la bonne exécution de la phase de clôture 5.

Cette phase 5 comprend aussi une étape 7, où le processus de journalisation PIogOP du noeud primaire OP transmet le contenu du journal tampon JSlLocal au processus de journalisation du noeud secondaire PlogSB, qui le mémorise dans le journal JSem1 concernant l'événement détecté EVI, à la suite des données précédentes. Le processus de journalisation primaire PlogOP continue alors la journalisation de l'événement détecté EVI, en reprenant une séquence tampon si cet événement est aussi un événement interne.

Dans une variante illustrée en figure 4b, la mémorisation en tampon d'évènements internes peut être déclenchée par des types d'évènements possiblement différents des évènements de type bloquant. Il s'agit alors d'évènements de type déclenchant. Un même type d'événement peut être choisi comme constituant un type seulement bloquant ou seulement déclenchant ou les deux.

Dans cette variante, l'étape 1 de détection d'un événement est suivie d'une étape bi. Dans cette étape b1, si l'événement détecté EVI est d'un type considéré comme déclenchant, le processus de journalisation primaire PIogOP vérifie si une séquence courante SEQC de journalisation en mémoire tampon est en cours, et en initialise une si ce n'est pas le cas.

En une étape suivante b2, teste si une telle séquence courante SEQC de journalisation en mémoire tampon est en cours pour l'événement 5 détecté EVI.

En une étape b3, si aucune séquence courante tampon SEQC n'est active pour cet événement EVI, son résultat est journalisé en tant que donnée de journalisation DJ.

En une étape b4, cette donnée de journalisation DJ est transmise au processus de journalisation secondaire PlogSB qui le mémorise à la suite des précédents dans le fichier journal JSeml concernant l'événement détecté EVI, à la suite des données précédentes. Le processus de journalisation primaire PIogOP attend alors la détection d'un nouvel événement.

A la suite de l'étape b2, si un séquence courante est active pour l'événement détecté EVI, la journalisation de cet événement se poursuit de la même façon qu'en figure 4a.

Lorsque l'application intermédiaire veut basculer tout ou partie des services de l'application maître vers une application de reprise, elle commence par restaurer une telle application de reprise sur un noeud secondaire à partir d'un état de point de reprise, puis effectue un rejeu des évènements journalisés depuis ce dernier point de reprise.

En particulier pour une application maître qui fonctionne de façon évènementielle, c'est à dire sur évènements déclenchants (externes), par exemple une application transactionnelle, le re-jeu de restauration s'effectue de façon différente pour les évènements externes ou pour les évènements internes.

Un tel fonctionnement signifie, pour l'application, qu'elle comprend au moins un processus qui peut rester à attendre de recevoir un évènement externe, et y réagir en réalisant des opérations comprenant des évènements internes.

Le re-jeu comprend alors donc une fourniture active à l'application des évènements externes journalisés, et une réponse passive fournissant les réponses journalisées en réponse à des évènements internes que le - 33 déroulement de l'application de reprise crée de lui-même au cours du rejeu.

La figure 5 illustre le fonctionnement du re-jeu RSB des évènements externes de type messages TCP, journalisés dans un ou plusieurs fichiers KL constituant le journal externe kernel log .

Ce kernel log KL est utilisé par un processus de re-jeu PRE, appartenant à l'application intermédiaire et s'exécutant dans l'espace utilisateur du noeud secondaire SB, pour réinjecter dans un processus PB1 de l'application de reprise les messages TCP journalisés précédemment.

Pour effectuer cette réinjection, l'application intermédiaire INT comprend ou utilise un mécanisme ou agent logiciel s'interposant dans les couches de réception de messages TCP, par exemple sous la forme d'un mécanisme ou agent logiciel ipfilter , comprenant un module kernel fonctionnant entre les couches IP et TCP. Le noeud secondaire comprend également une fonctionnalité de boucle locale de réseau BL, dont l'accès est adressé ( mapped ) par une interface au sein du système pour être accessible à des processus de l'espace utilisateur. Cette boucle BL peut comprendre en particulier un dispositif physique au sein de l'espace matériel, qui lui permet de réinjecter des données à la base de la couche IP, contrairement à des interfaces virtuelles de loop-back qui sont réalisées de façon logicielle au sein d'un système d'exploitation, par exemple Unix.

En une étape 1, le processus de re-jeu PRE lit un message journalisé dans les fichiers du kernel log KL.

En une étape 2, le processus de re-jeu PRE injecte ce message dans l'interface de la boucle locale de réseau BL.

En une étape 3, ce message est reçu par la couche IP, qui la transmet, par l'intermédiaire de l'agent ipfilter , à la couche TCP pour traitement.

En une étape 4, si la couche TCP envoie un accusé de réception vers le réseau, celui-ci sera filtré ou bloqué par l'agent ipfilter .

En une étape 5, après avoir transmis le message vers la couche TCP, après avoir reçu son accusé de réception s'il y en a un, l'agent ipfilter signale au processus de re-jeu PRE que le message a bien été reçu ou traité par la couche TCP.

- 34 - En une étape 6, le processus PB1 de l'application de reprise reçoit le message de la couche TCP, et réalise une lecture asynchrone du ou des paquets qu'il contient.

Pendant toute la durée du re-jeu, l'agent ipfilter isole l'application de reprise du réseau, en empêchant tous les messages extérieurs d'arriver jusqu'à la couche TCP, et en empêchant tous les messages émis par l'application de reprise d'arriver jusqu'à la couche IP, de façon transparente vis-à-vis de cette application.

Au sein de l'application de reprise, pour effectuer le re-jeu des évènements internes prenant place entre deux évènements externes rejoués, l'application intermédiaire laisse l'application de reprise s'exécuter d'elle-même, tout en virtualisant pour elle les ressources concernées, réalisant ainsi un rejeu passif. Un processus de re-jeu PRI détecte alors chaque opération constituant un évènement interne concernant une ressource déterminée, et force cette ressource à adopter le comportement qui a été journalisé, renvoyant ainsi à l'application de reprise le résultat mémorisé pour cet évènement lors de cette journalisation.

Les figures 6 à 8 illustrent un exemple de re-jeu RSB d'un évènement interne, dans un cas où il comprend une opération de prise d'un sémaphore SEM1 par deux processus PB1 et PB2 de l'application de reprise, en vue d'obtenir un accès en exclusion mutuelle à une ressource partagée, par exemple une zone de mémoire partagée.

Au cours d'une restauration sur un noeud secondaire SB, ces deux processus PB1, PB2 réalisent un re-jeu à partir de fichiers constituant un journal user log . Au cours de leur re-jeu, l'exécution de l'application de reprise amène ces processus à réaliser chacun un appel à un même sémaphore SEM1, auquel correspond un fichier journal JSEM1 inclus dans le journal des évènements internes user log .

La détection de ces opérations d'accès et le forçage de leur réponse sont réalisés en utilisant en ajoutant des instructions supplémentaires dans le contenu de tout ou partie des routines fournies par le système et appelées par l'application, en utilisant une technique d'interposition dynamique par metaprocess . Une telle technique peut être par exemple celle décrite dans le brevet FR 2 843 809. En particulier, ces instructions - peuvent être regroupées avant le code réalisant les fonctions de la routine d'origine et former alors un prologue, ou être regroupées après ce code et former un épilogue.

La figure 7 illustre ainsi l'insertion d'un prologue et d'un épilogue au sein d'une routine R, donnant ainsi une routine modifiée RM. Dans cet exemple, il est à noter que la même routine modifiée RM peut-être utilisée pour réaliser une journalisation d'une application maître et également pour réaliser un rejeu d'une application de reprise.

Lors de l'exécution des fichiers exécutables de l'application, un processus P exécute une ligne de code appelant la routine R, par exemple la routine sem_wait au standard POSIX.4 , qui demande le positionnement d'un sémaphore déterminé lui attribuant un accès en exclusion mutuelle à une zone déterminée de mémoire partagée. Dans le cas d'une application multi-thread, il peut s'agir d'une instruction pthread_mutex_lock du standard POSIX Threads qui remplit un rôle similaire.

Un agent d'interposition META, chargé dans le système au démarrage ou avant les fichiers exécutables de l'application, intercepte l'appel à la routine d'origine R du système, et le redirige vers la routine modifiée RM.

Cette routine modifiée comprend des instructions réalisant ou appelant la routine R d'origine sem_wait , précédées par des instructions réalisant un prologue et suivies par des instructions réalisant un épilogue.

Ces instructions supplémentaires peuvent comprendre, en particulier, un algorithme des types suivants: Pour le prologue: if (replay) check(3sem1) Pour l'épilogue: if (replay) end_check(3seml) else record(result, 7seml) Les instruction "if(replay)" testent une condition indiquant si l'application est en train de réaliser un re-jeu ou non.

Dans le cas contraire ( else ), cela signifie que l'application s'exécute de façon normale et doit donc être traitée comme une application maître. L'épilogue exécute alors une fonction record(result, Jsemi) , qui - 36 - constitue une sonde d'enregistrement telle que citée précédemment et participe à la journalisation d'un évènement interne en mémorisant le résultat result dans le journal Jseml .

Lorsque la routine sem_wait est appelée par l'application de reprise au cours d'un re-jeu utilisant le journal Jseml , le prologue est exécuté avant la réalisation de la routine sem_wait d'origine du système.

La figure 8 représente un organigramme temporel qui illustre le fonctionnement de cette routine modifiée RM pour effectuer le re-jeu des deux processus PB1, PB2 à partir du journal JSEM1 inclus dans le journal d'évènements internes User Log . Chaque évènement journalisé dans le journal JSEM1 est numéroté selon une séquence incrémentale #OP propre au sémaphore SEM1 concerné. Associé à chacun de ces numéros #op, le journal JSEM1 contient une identification PID du processus qui a appelé le sémaphore correspondant à ce journal JSEM1, lors de la journalisation.

Chacun des deux processus PB1 et PB2 s'exécutant de façon parallèle, leurs appels respectifs au sémaphore SEM1 par la fonction sem_wait ne se font pas forcément dans l'ordre mémorisé dans le journal JSEM1 du sémaphore.

Lorsque le processus PB2 d'identifiant id2 appelle le sémaphore SEM1 au cours du re-jeu, le prologue exécute alors l'instruction check(Jseml) au nom de ce même processus PB2, en une étape 21. Cette fonction check(Jseml) lit dans le journal JSEM1 la ligne correspondant à la valeur actuelle du numéro de la séquence OPSEM1, soit la ligne #1: idl .

Cette fonction check compare la valeur PIDlog lue, soit id1 , à l'identifiant du processus PB2 appelant, soit id2 . Lorsqu'elle constate que ces valeurs diffèrent, cette fonction check suspend l'exécution du processus PB2 appelant, par exemple en ré-exécutant cette même étape 21 de comparaison en boucle continue.

Par la suite, lorsque le processus PB1 d'identifiant id1 appelle lui aussi le sémaphore SEM1 au cours du re-jeu, le prologue exécute également l'instruction check(Jseml) , mais cette fois au nom du nouveau processus appelant PB1, en une étape 11. Lorsqu'elle constate que - 37 ce processus appelant PB1 est bien celui dont l'identifiant idl est mémorisé dans le journal à la ligne correspondant au numéro actuel de la séquence active, soit la valeur #1 , la fonction check autorise la poursuite de l'exécution du processus appelant PB1.

En une étape 12, la routine modifiée RM réalise alors les fonctionnalités de la routine R d'origine, soit l'instruction sem_wait , qui lui attribue donc le sémaphore SEM1 et renvoie la valeur idl du processus appelant PB1.

En une étape 13, l'épilogue exécute alors l'instruction end_check(Jseml) au nom du processus appelant PB1. Cette fonction end_check clôt alors l'appel sem_wait du processus PB1 et débloque l'exécution du processus PB2 qui était en attente. Cette opération peut comprendre en particulier une incrémentation du numéro de la séquence OPSEMI de ce sémaphore SEM1, le faisant passer à la valeur suivante #2 .

Dans ce cas, lorsque la fonction check appelée par le processus PB2 s'exécute à nouveau en une étape 22, elle lit la ligne suivante du journal JSEM1 #2: id2 et laisse son processus PB2 appelant poursuivre son exécution de la routine modifiée RM.

En une étape 23, la routine modifiée RM réalise alors à son tour les fonctionnalités de la routine R d'origine, soit l'instruction sem_wait , qui lui attribue donc le sémaphore SEM1 et renvoie la valeur id2 du processus appelant PB1.

En une étape 24, l'épilogue exécute alors l'instruction end_check(Jseml) au nom du processus PB2 appelant, incrémentant à nouveau la séquence du sémaphore SEM1 et le rendant disponible pour la suite du re-jeu.

Quel que soit l'ordre dans lequel les différents processus en cours de rejeu demandent l'attribution du sémaphore SEM1, on voit qu'ils ne peuvent ainsi l'obtenir que dans l'ordre exact mémorisé dans son journal JSEM1, et donc dans le même ordre que lors du déroulement de l'application maître ayant donné lieu à cette journalisation.

Du fait que ces instructions supplémentaires sont ajoutées par un agent META extérieur à l'application maître et ajouté au système d'exploitation sans modification de celui-ci, on voit que ces opérations de journalisation et re-jeu s'effectuent de façon transparente et non intrusive, pour l'application maître et sans modification des éléments préexistants du système.

Etant donné l'importance du nombre d'évènements internes, il est utile d'optimiser le fonctionnement de leur journalisation et/ou leur re-jeu, en particulier pour éviter une dégradation des performances qui rendrait peu significatifs les bénéfices obtenus par les caractéristiques décrites ci-dessus.

Parmi les types d'évènements internes survenant entre deux évènements externes, la plupart peuvent être qualifiés de déterministes, c'est-àdire ne comportant que des opérations dont le résultat dépend exactement de l'état de l'application avant ces opérations.

Par contre, en particulier dans le cas d'applications multi-tâches ou réparties sur plusieurs noeuds, certains évènements internes sont d'un type non-déterministe, car ils comprennent des opérations qui peuvent fournir un résultat dépendant de facteurs extérieurs à l'application ou au noeud primaire.

En ne journalisant, ou rejouant, que les évènements internes de types non déterministes, il est ainsi possible de limiter la surcharge de travail du noeud opérationnel, et donc la baisse de performances, causées par l'utilisation de l'application intermédiaire pour fiabiliser ou gérer l'application maître.

Ainsi qu'illustré en 8a et 8b, la journalisation et le re-jeu peuvent être accélérés en particulier en ne journalisant le résultat et en ne forçant le rejeu que pour les évènements internes dont le comportement n'est pas déterministe.

Pour tous les évènements, et en particulier les évènements internes EVI, un mécanisme d'interposition META (figure 7), tel que décrit précédemment, appelle une routine modifiée RM réalisant l'opération prévue au lieu d'une routine d'origine R. Cette routine modifiée RM comprend une fonctionnalité pouvant réveiller ou informer un processus de journalisation PIogOP ou un processus de rejeu PRI de la survenue de cet événement EVI, et si besoin attendre son accord pour poursuivre le - 39 - traitement de cet événement ou pour rendre la main au processus P1 ou PB1 qui l'a appelée.

Qu'il s'agisse de journalisation ou de rejeu, la gestion de cet événement EVI comprend alors une étape réagissant à la survenue de cet événement, suivie d'une étape de gestion complémentaire GC (figures 8a, 8b) dont le contenu dépend de la nature déterministe ou non de cet événement interne. La figure 8a illustre le fonctionnement de la journalisation d'un

événement interne. Au cours du déroulement du processus P1 en cours de journalisation JOP (figure 1), l'exécution d'une instruction réalise un événement interne EVI portant sur une ressource partagée, comme un sémaphore SEM1.

En une étape 1, la routine modifiée RM correspondant à l'événement à journaliser EVI informe ou réveille le processus de journalisation PIogOP, 15 qui détecte ainsi la survenue de cet événement EVI.

En une étape 2, la routine modifiée RM correspondant à l'événement EVI réalise sur le sémaphore SEM1 l'opération prévue dans la routine d'origine R et reçoit ou calcule une donnée de résultat DR à destination du processus journalisé P1.

En une étape 3, le processus de journalisation PIogOP incrémente un numéro de séquence SQ, par exemple affecté au sémaphore SEM1, correspondant à la position de l'événement détecté EVI au sein d'une séquence de P1 en cours de journalisation.

En une étape 4, ce processus PIogOP effectue un test pour savoir si l'événement interne EVI détecté est d'un type déterministe ou non. Ce test peut porter par exemple sur un paramètre reçu de la routine modifiée RM lors de son appel, ou sur la présence d'une donnée de résultat DR transmise avec cet appel, ou sur une identification d'instruction ou d'événement mémorisée par ailleurs dans le noeud primaire OP.

En une étape 5, si l'événement détecté EVI est d'un type non-déterministe, le processus PIogOP transmet la donnée de résultat DR au processus de journalisation PlogSB du noeud secondaire. Celui-ci mémorise alors la donnée de résultat DR et le numéro de séquence SQ correspondant à l'événement EVI, de façon associée au sein d'un fichier de journalisation - 40 - JSeml correspondant au sémaphore SEM1, à la suite des données de résultat des évènements journalisés précédents. Selon les conditions de journalisation, les données mémorisées dans le journal JSeml peuvent aussi être directement mémorisées dans un fichier journal sur support permanent dans le noeud primaire par le processus de journalisation PIogOP.

A l'issue d'une séquence d'évènements internes du processus journalisé P1, le journal JSeml contient ainsi une suite ordonnée de toutes les données de résultats renvoyées par le sémaphore SEM1 à ce processus Pl, associées aux numéros de séquence des évènements qu'elles concernent.

La figure 8b illustre le fonctionnement du rejeu de cet événement interne EVI, au sein d'un processus de reprise PB1, lors d'une phase de rejeu RSB (figure 1) passif, contrôlé par un processus de rejeu PRI (cf. figure 6), des événements mémorisés dans le journal JSeml correspondant au sémaphore SEM1. Au cours du déroulement du processus PB1 en cours de rejeu des évènements du journal JSeml, l'exécution d'une instruction réalise un événement interne EVI d'un type non déterministe portant sur le sémaphore SEM1.

En une étape 1, la routine modifiée RM correspondant à l'événement à journaliser EVI informe ou réveille le processus de rejeu PRI, qui ainsi détecte et identifie ainsi la survenue de cet événement.

En une étape 2, la routine modifiée RM correspondant à l'événement EVI réalise sur le sémaphore SEM1 l'opération prévue dans la routine d'origine R, et reçoit ou calcule une donnée de résultat correspondant à un résultat réel de rejeu RRJ. La routine modifiée RM suspend alors l'exécution du processus de reprise PB1 et attend un signal du processus de rejeu PRI pour transmettre ce résultat RRJ au processus de reprise PB1.

En une étape 3, le processus de rejeu PRI lit dans le journal JSeml la prochaine valeur RLi non utilisée pour le rejeu, avec le numéro de séquence SQi qui lui est associé.

En une étape 4, le processus de incrémente un numéro de séquence SQ, par exemple affecté au sémaphore SEM1, correspondant à la position -41 - de l'événement détecté EVI au sein d'une séquence de PB1 en cours de rejeu.

En une étape 5, le processus de rejeu PRI effectue un test sur le numéro de séquence actuel SQ et le numéro de séquence lu SQi dans le journal, pour savoir si l'événement en cours EVI de rejeu correspond à un événement journalisé.

En une étape de forçage 7, si ces événement correspondent, le processus de rejeu PRI transmet le résultat lu RLi dans le journal à la routine modifiée RM, qui le mémorise en lieu et place du résultat RRJ de l'opération d'origine R. La routine modifiée RM retourne alors ce résultat RLi au processus de reprise PB1 et le laisse poursuivre son exécution.

De façon optionnelle, l'étape de forçage 6 est précédée d'une étape 6, dans laquelle le processus de rejeu PRI reçoit de la routine modifiée RM le résultat réel de rejeu RRJ et le compare au résultat lu RLi correspondant au résultat du même événement lors de la journalisation. Si ces deux résultats RRJ et RLi correspondent, le processus libère directement la routine modifiée qui retourne son résultat au processus de reprise PB1 et le laisse poursuivre son exécution.

Ainsi, on voit que les évènements non déterministes peuvent être enregistrés et rejoués de façon fidèle et exacte, assurant un déroulement du processus de reprise PB1 lors du rejeu qui soit fidèle à celui du processus cible P1 lors de la journalisation.

Du fait que seuls certains évènements sont journalisés ou rejoués, et parce que les opérations internes supplémentaires de mise en oeuvre de l'invention sont bien plus rapides qu'une mémorisation ou transmission pour journalisation, on diminue la surcharge de travail due au fonctionnement de l'application intermédiaire INT.

Optionnellement, lorsqu'une routine d'origine R n'est prévue que pour réaliser des évènements qui sont déterministes, une routine modifiée RM qui lui correspond peut ne pas prévoir du tout d'appel à un processus de journalisation ou de rejeu. De même, lorsqu'une routine d'origine R n'est prévue que pour réaliser des évènements non-déterministes, sa routine modifiée RM peut comprendre un appel systématique à un processus de journalisation ou de rejeu. lors de la journalisation, l'étape 4 (figure 8a) de - 42 - test de la nature déterministe peut alors être implicitement réalisée dans le type d'appel reçu ou dans le fait même de recevoir un appel.

Dans le cas où un type donné d'évènement interne peut être déterministe ou non selon le type d'application ou les conditions de son exécution, la routine modifiée RM peut aussi inclure dans son prologue et/ou son épilogue des instructions évaluant ce type d'application ou ces conditions d'exécution.

L'utilisation d'un numéro de séquence SQ peut aussi être optionnelle. Dans ce cas, le processus de journalisation PIogOP (figure 8a) se contente de mémoriser la donnée de résultat lorsque l'événement EVI est de type non déterministe. De son côté, le processus de rejeu PRI (figure 8b) se contente de lire le prochain résultat RLi journalisé, et considère qu'il s'agit du résultat à forcer pour le prochain événement EVI détecté comme étant non déterministe.

En outre, une méthode d'optimisation heuristique, ou prédictive, permet de ne pas journaliser systématiquement tous les évènements internes non déterministes. Cette méthode peut être mise en oeuvre seule ou en combinaison avec d'autres méthodes d'optimisation.

Du fait du coût en termes de temps des opérations de journalisation et rejeu, en particulier par rapport à des opérations internes à un noeud, il peut en effet être intéressant de réaliser un certain nombre d'opérations internes supplémentaires si cela permet de diminuer le nombre de d'opérations de journalisation.

Cette technique d'optimisation heuristique comprend la mise en oeuvre, par l'application intermédiaire, d'une compression heuristique fonctionnant par prédiction de résultats et portant sur tout ou partie des évènements internes détectés lors du fonctionnement de l'application maître.

Lors de la journalisation au sein du noeud opérationnel, cette 30 compression heuristique peut par exemple être mis en oeuvre par le processus de journalisation interne PlogOP.

La figure 8c illustre le fonctionnement de la journalisation d'un événement non déterministe, avec utilisation d'une telle compression heuristique CH.

- 43 - Au cours du déroulement du processus P1 en cours de journalisation JOP, l'exécution d'une instruction réalise un événement interne EVInD d'un type non déterministe portant sur une ressource partagée, comme un sémaphore SEM1.

En une étape 1, la routine modifiée RMnD correspondant à l'événement à journaliser EVInD informe ou réveille le processus de journalisation PlogOP, qui détecte ainsi la survenue de cet événement EVInD.

En une étape 2, la routine modifiée RMnD correspondant à l'événement EVInD réalise sur le sémaphore SEM1 l'opération prévue dans la routine d'origine RnD et reçoit ou calcule une donnée de résultat DR à destination du processus journalisé P1.

En une étape 3, le processus PIogOP incrémente le numéro de séquence SQ de journalisation correspondant à la ressource SEM1 15 concernée par l'évènement détecté EVInD.

Avantageusement, ce numéro de séquence SQ est mémorisé en mémoire de travail au sein du noeud primaire OP. De ce fait, sa gestion représente une charge de travail très faible par rapport à la transmission d'une donnée de résultat vers un noeud secondaire ou sa mémorisation dans un fichier journal sur support permanent.

Cette incrémentation du numéro de séquence SQ associé au sémaphore SEM1 et à son journal JSEM1 permet ainsi d'enregistrer le passage d'un événement non déterministe EVInD correctement prédit par la fonction de prédiction FH tout en évitant la surcharge de travail que représenterait la mémorisation systématique de la donnée de résultat DR.

En une étape 4, le processus PIogOP réalise une opération logicielle FH comprenant une prédiction du résultat de cet évènement interne EVInD sous la forme d'un résultat prédit RP. De préférence, cette prédiction est un traitement logiciel déterministe constitué d'une ou plusieurs fonctions déterministes basées sur l'état du processus P1 journalisé ou de l'application maître avant cet évènement EVInD.

En une étape 5, le processus PlogOP compare le résultat prédit RP avec le résultat réel DR issu du déroulement RnD de l'évènement EVInD détecté.

- 44 - En une étape 6, si ces deux résultats DR et RP sont différents, le processus PIogOP transmet le résultat réel DR et la valeur correspondante du numéro de séquence SQ, au processus PIogSB du noeud secondaire, qui les mémorise de façon associée, comme ligne suivante dans le fichier journal Jseml correspondant à la ressource concernée SEM1.

Lors de cette étape, il est possible de prévoir une réinitialisation du numéro de séquence SQ de journalisation de la ressource SEM1 concernée. Dans ce cas, le numéro de séquence SQ représente le nombre d'évènements correctement prédits depuis le dernier événement dont le résultat a été journalisé.

A l'issue d'une séquence d'évènements internes du processus journalisé P1, le journal JSeml contient ainsi une suite ordonnée de toutes les données de résultats renvoyées par le sémaphore SEM1 à ce processus P1 et qui n'ont pas été prédites correctement par la fonction de prédiction FH.

Dans le cas où la journalisation des évènements internes a été réalisée en utilisant une telle optimisation heuristique, l'application intermédiaire met alors en oeuvre une décompression heuristique lors d'un re-jeu au sein d'un noeud secondaire. Cette décompression heuristique utilise une prédiction identique à celle utilisée pour la compression et porte sur les mêmes évènements que lors de la journalisation avec compression heuristique.

La figure 8d illustre ainsi le fonctionnement du rejeu d'un événement non déterministe, avec utilisation d'une telle décompression heuristique DH, au sein d'un rejeu passif d'un processus de reprise PB1, contrôlé par un processus de re-jeu interne PRI (cf. figure 6), à partir du journal JSeml portant sur le sémaphore SEM1.

Au cours du rejeu des évènements du journal JSeml, l'exécution d'une instruction réalise un événement interne EVInd d'un type non 30 déterministe portant sur le sémaphore SEM1.

En une étape 1, la routine modifiée RMnD correspondant à l'événement à journaliser EVInD informe ou réveille le processus de rejeu PRI, qui ainsi détecte et identifie ainsi la survenue de cet événement EVInD.

- 45 - En une étape 2, la routine modifiée RMnD correspondant à l'événement EVInD réalise sur le sémaphore SEM1 l'opération prévue dans la routine d'origine RnD et reçoit ou calcule une donnée de résultat correspondant à un résultat réel de rejeu RRJ. La routine modifiée RMnD suspend alors l'exécution du processus de reprise PB1. Elle attend alors un signal du processus de rejeu PRI pour transmettre ce résultat RRJ au processus de reprise P1 et pour le laisser poursuivre son exécution.

En une étape 3, le processus PRI lit et incrémente la valeur d'un numéro de séquence SQ correspondant au sémaphore SEM1.

En une étape 4, le processus de re-jeu interne PRI compare ce numéro de séquence SQ avec le prochain numéro de séquence SQi non encore rejoué parmi ceux mémorisés dans le fichier journal Jseml correspondant à cette même ressource SEM1.

En une étape 5, si ces numéros de séquence SQ et SQi correspondent entre eux, alors le processus de re-jeu interne PRI lit le résultat mémorisé RLi dans ce journal pour ce numéro de séquence SQi, et le mémorise comme résultat forcé RF à retourner par l'évènement détecté EVInD. Le processus de re-jeu interne PRI mémorise alors le fait que l'événement représenté par la ligne SQi du journal JSeml a été rejoué, et active la ligne suivante SQj de ce même journal pour le traitement du prochain événement détecté.

Lors de cette étape, il est possible de prévoir une réinitialisation du numéro de séquence SQ de rejeu de la ressource SEM1 concernée.

En une étape 6, si ces numéros de séquence SQ et SQi ne correspondent pas entre eux, le processus de re-jeu interne PRI réalise une opération logicielle FH comprenant la même prédiction de résultat que celle réalisée lors de la journalisation de cet évènement interne, sous la forme d'un résultat prédit RPJ. Le processus de re-jeu interne PRI mémorise alors le résultat RPJ de cette prédiction comme résultat forcé RF à retourner par l'évènement détecté EVInD.

En une étape 8, le processus de re-jeu interne PRI transmet le résultat forcé RF à la routine modifiée RMnD, qui l'impose au processus de reprise PB1 en lieu et place du résultat réel rejoué RRJ retourné par -46 l'événement interne EVInD. La routine modifiée laisse ensuite le processus de reprise PB1 poursuivre son exécution.

De façon optionnelle, ce forçage peut être précédé d'une étape 7 de test pour comparer ces deux résultats RRJ et RF, et éviter d'intervenir dans le processus de reprise PB1 si ces résultats correspondent.

Il est à noter que les données d'identification ou de séquencement SQ utilisées dans cette méthode d'optimisation prédictive peuvent constituer des variables différentes de celles décrites précédemment (figures 8a et 8b), ou être organisées et traitées de façon à être communes avec elles.

On voit ainsi que, même sans journaliser le résultats de tous les évènements non déterministes, ceux-ci peuvent être enregistrés et rejoués de façon fidèle et exacte. De cette façon, il est donc possible d'optimiser ces opérations de journalisation et rejeu tout en assurant un déroulement du processus de reprise PB1 lors du rejeu qui soit fidèle à celui du processus cible P1 lors de la journalisation.

Etant donné la différence de vitesse entre les opérations de journalisation et de simples opérations de calculs internes à un noeud, cette technique d'optimisation heuristique peut être intéressante même si la fonction de prédiction utilisée n'a pas un taux de succès très élevé. Si cette différence est grande, même un taux de succès de prédiction inférieur à 50 % peut permettre une optimisation utile.

Cette technique d'optimisation heuristique peut également utiliser plusieurs fonctions de prédiction différentes, du moment que c'est la même qui est utilisée pour journaliser puis rejouer un même évènement ou groupes d'évènements internes. Le choix de la fonction de prédiction à utiliser peut s'effectuer en fonction de l'état de l'application ou de son environnement, par exemple à partir d'une base de connaissances ou de règles. Ce changement peut alors être mémorisé au sein des données de journalisation mémorisées par l'application intermédiaire. Cette technique d'optimisation heuristique peut également être utilisée de façon auto adaptative, en évaluant son taux de succès au fur et à mesure de la journalisation et en déclenchant un changement de cette fonction basé sur la valeur de ce taux de succès ou sur sa variation.

- 47 - Un exemple de fonction de prédiction utilisée dans cette technique d'optimisation heuristique comprend une prédiction de l'ordre de survenue des évènements internes en se basant sur l'ordre de survenue des évènements externes provenant de différents clients.

Les figures 9 et 10 illustrent la survenue d'évènements externes et internes participant à trois processus ProcA, ProcB, ProcC d'identifiants valant respectivement a , b , et c , par exemple exécutant trois tâches Ta, Tb, Tc lancées respectivement par trois clients différents. Ces différentes tâches comprennent par exemple chacune un premier évènement externe Eal, Ebl, Ecl, et un deuxième évènement externe Ea2, Eb2, Ec3. Entre ces premiers et deuxièmes évènements externes, chacune de ces tâches comprend le déclenchement de deux évènements internes non déterministes. En figures 9 et 10, les évènements internes successifs de la tâche Ta sont ainsi référencés Iai et Ia2, ceux de la tâche Tb sont référencés Ibl et Ib2, et ceux de la tâche Tc sont référencés Icl et Ic2. Ces évènements internes Iai à Ic2 peuvent être différents l'un de l'autre, ou bien concerner une même ressource déterminée, par exemple des attributions de verrou ( lock allocation ) à une même zone déterminée de mémoire partagée.

Dans le cas de tâches sensiblement simultanées, et en particulier lorsqu'elles ont des parties similaires ou communes entre elles et/ou présentent des durées d'exécution similaires, une fonction de prédiction consiste à prédire que l'ordre de survenue des évènements internes Ia1, Ib1, Icl intermédiaires sera le même que l'ordre de survenue des évènements externes qui les précédent.

Au cours du déroulement de l'application maître, l'ordre de survenue des premiers évènements externes Eal, Ebl, Ecl sur le noeud opérationnel OP est enregistré par l'application intermédiaire, par exemple au sein du processus de journalisation interne PIogOP. Par exemple, cet ordre d'évènements externes comprend la succession des identifiants des processus associés à ces évènements externes, soit la suite des valeurs a b c .

Lors de chaque détection d'un nouvel évènement interne concernant cette ressource, la fonction de prédiction réalise une prédiction du résultat 48 - de cet évènement interne, c'est-à-dire de l'identité du processus qui va obtenir le verrou sur cette ressource, c'est-à-dire celui qui vient de le demander. Ce résultat prédit sera alors calculé en comparant l'identité du dernier processus ayant obtenu le verrou sur cette ressource avec cet ordre d'évènements externes.

Ainsi, la fonction de prédiction effectuera une suite de prédictions Pel à Pe6 figurées chacune par une ligne pointillée et dont le résultat est indiqué à son extrémité de droite.

La figure 9 illustre les valeurs des prédictions réalisées à chaque survenue d'un évènement interne, dans le cas où ces évènements internes suivent l'ordre d'évènements externes. A partir de l'ordre d'évènements externes a b c et du dernier évènement interne survenu, la fonction de prédiction réalisera ainsi une prédiction constituant la suite de valeurs a b c a b c , qui se révèleront juste dans ces six cas. Dans le cadre d'une optimisation heuristique, le processus de journalisation interne PIogOP n'aura ainsi pas besoin de transmettre de données de journalisation pour ces évènements internes, puisqu'ils ont été correctement prévus par la fonction de prédiction.

La figure 10 illustre les valeurs des prédictions réalisées à chaque survenue d'un évènement interne, dans un cas où ces évènements internes ne suivent pas exactement l'ordre d'évènements externes, la tâche Tb du processus PrB d'identifiant b s'exécutant de façon plus rapide que les deux autres tâches. A partir de l'ordre d'évènements externes a b c et du dernier évènement interne survenu, la fonction de prédiction réalisera ainsi une prédiction constituant la suite de valeurs a b c c a b . On voit que deux prédictions Pe3, Pe6 se révèleront fausses, ce qui conduira le processus de journalisation interne PlogOP à transmettre des données de journalisation en deux occasions. Ces données de journalisation comprendront ainsi la valeur c en une transmission L1 à l'issue de la troisième prédiction Pe3 qui s'est révélée erronée, puis la valeur c en une transmission L2 à l'issue de la sixième prédiction P6 qui s'est également révélée erronée.

Malgré ces prédictions erronées Pe3, Pe6, on voit que cette technique d'optimisation heuristique aura permis au processus de journalisation - 49 - interne PIogOP de n'effectuer que deux transmissions L1, L2 au lieu des six qu'il aurait fallu en son absence. Une telle économie de quatre transmissions sur six représente un temps de travail suffisamment plus grand que les calculs et opérations internes qui sont nécessaires pour mettre en oeuvre cette technique d'optimisation, et peut apporter ainsi un gain de performance significatif, en particulier au sein du noeud opérationnel.

Pour certains évènements internes dont une implémentation standard par le système d'exploitation réalise un comportement non déterministe, il est possible d'utiliser une méthode d'optimisation par changement sémantique. Cette méthode comprend une modification de l'implémentation de tels évènements au sein du noeud, de façon à leur donner un comportement qui soit déterministe. L'application intermédiaire réalise cette modification de façon identique au sein du noeud opérationnel et du ou des noeuds secondaires, ce qui rend prévisibles les résultats de ces évènements internes modifiés. Cette modification d'implémentation se fait de façon dynamique par une technique d'interposition par un metaprocess qui remplace une routine d'origine R d'implémentation d'un évènement par une routine modifiée RM implémentant un comportement modifié pour cet évènement. La technique utilisée pour réaliser cette modification est similaire à celle décrite ci-dessus (cf. figure 7) pour l'ajout de sondes d'enregistrement en prologue et épilogue, mais peut comprendre une modification du code de la partie centrale de la routine modifiée. Cette modification d'implémentation est réalisée de façon transparente pour l'application maître et ne modifie pas les éléments préexistants du système d'exploitation. Par une utilisation de ces routines modifiées dans l'application maître, de façon permanente ou sur au moins un intervalle d'exécution déterminé et mémorisé, il est ainsi possible de journaliser l'évolution de l'application maître sans avoir à mémoriser le résultat de ces évènements modifiés. L'utilisation des mêmes routines modifiées sur les mêmes intervalles d'exécution d'une application de reprise, permet alors de conserver la reproductibilité de l'application maître en améliorant les performances de la journalisation comme du re- jeu.

- 50 - Ce comportement modifié est conçu de façon à répondre aux mêmes spécifications que le comportement d'origine et être entièrement compatible avec lui, par exemple en prévoyant qu'à partir d'une situation donnée où la routine d'origine aurait pu renvoyer plusieurs résultats différents, la routine modifiée ne fournisse que des résultats qui auraient pu être fournis par la routine d'origine et sont donc prévus par l'application maître et le système d'exploitation.

Cette technique d'optimisation par changement sémantique permet de diminuer le nombre d'évènements internes non déterministes dont le résultat doit être journalisé dans le noeud opérationnel pour pouvoir être rejoué lors de la restauration d'une application de reprise.

Un exemple de fonctionnement et d'interaction des différents intervenants sont illustrés de façon symbolique en figure 16.

Un agent de traitement AT, par exemple au sein du logiciel système, réalise une opération renvoyant un résultat DR à un processus, par exemple un processus journalisé P1. Pour un grand nombre d'opérations ou évènements, en particulier internes, la réalisation de cette opération se fait par un traitement d'opération TO, qui est d'une nature déterministe par rapport à un ensemble de ressources dites déterminantes RDet.

Parmi les ressources accessibles au processus Pi, certaines peuvent être qualifiées de ressources reproductibles RRepr à partir de la connaissance de l'état de ce processus P1. Ces ressources reproductibles comprennent en particulier les ressources dont l'état dépend exclusivement de lui.

Dans le fonctionnement de l'agent de traitement AT, le traitement d'opération TO peut comprendre une partie TD de traitement qui est déterministe par rapport aux ressources reproductibles RRepr du processus P1, par exemple parce qu'elle n'utilise que des données DER provenant de ces ressources reproductibles RRepr.

Dans le cas où le traitement d'opération TO comprend une autre partie de traitement utilisant des données DE qui proviennent de ressources SEM1 n'appartenant pas aux ressources reproductibles RRepr du processus P1, il est fréquent que le résultat de cette partie TnD, et donc de l'ensemble 51 - du traitement TO, ne soit pas déterministe vis à vis du processus P1 qui y fait appel.

Dans une telle situation, cette méthode de changement sémantique peut consister à utiliser un agent de gestion AG pour modifier le comportement de l'agent de traitement ou les données qu'il utilise ou produit, de façon à ce que l'opération résultant de cette modification soit déterministe par rapport aux ressources reproductibles RRepr.

Cet agent de gestion peut utiliser un traitement de modification de fonctionnement TMF pour modifier le fonctionnement interne du traitement 10 d'opération TO.

Il peut aussi utiliser des données d'entrées DE issues des ressources déterminantes RDet mais non reproductibles (RRepr) vis à vis du processus P1, pour compenser les variations de résultat DR pouvant constituer une source de non déterminisme pour ce même processus P1. Une telle compensation peut s'effectuer en modifiant TC1 les données d'entrées DE en données d'entrée compensées DEC, ou en modifiant TC2 les données de résultat DR en données de résultat compensées DRC.

Cet agent de gestion AG peut en outre choisir ou régler les modifications TMF, TC1, TC2 qu'il effectue en fonction d'un ou plusieurs paramètres de changement sémantique PCS, de façon à optimiser l'efficacité du traitementglobal AT et AG. De façon à rester reproductible entre une journalisation JOP et un rejeu RSB, il suffit que les variations de ce paramètre de changement sémantique PCS ne soient déterminées que par des données provenant des ressources reproductibles RRepr, ou que ses variations soient mémorisées au sein du journal UL, KL lors de la journalisation et soient lues et appliquées de la même façon lors du rejeu RSB.

Cette modification de comportement peut concerner en particulier les aspects touchant à la gestion de plusieurs processus concurrents auprès d'une ressource déterminée.

Les figures 11 et 12 illustrent un exemple d'utilisation de cette technique d'optimisation par changement sémantique pour rendre déterministe une opération de lecture de messages reçu, en utilisant la routine read dans un environnement de type Unix.

- 52 - Dans son implémentation standard, la routine read , déclenchée par une application, utilise une zone de mémoire tampon B pour lire des messages dans un canal d'entrée ICH ( input channel ) et les transmettre à cette application. Les messages reçus dans le système sous forme de données successives qui sont mémorisées dans une zone de mémoire constituant le canal d'entrée, au fur et à mesure qu'elles arrivent. Selon sa configuration, l'opération read peut utiliser un tampon de différentes tailles, mais ce tampon est utilisé intégralement à chaque lecture dans le canal d'entrée.

Dans cet exemple, l'application utilise une succession d'opérations read de tampon B de taille 50 , pour recevoir trois messages M1, M2, M3 qui lui arrivent successivement dans le canal d'entrée ICH. Ces trois messages représentent des volumes de données valant respectivement 20 , 30 , et 50 . Or la vitesse d'arrivée des données dans le canal d'entrée, d'une part, et la vitesse d'exécution par l'application d'une succession d'opérations de lecture, d'autre part, peuvent varier l'une par rapport à l'autre d'une façon qui n'est pas prévisible au stade d'une journalisation ou d'un re-jeu.

La figure 11 représente ainsi deux scénarios différents possibles pour 20 la lecture des mêmes trois messages à l'aide d'une routine read d'origine.

Dans un premier scénario SCA, une première lecture RAI s'effectue alors que seul les données du premier message M1 de taille 20 sont arrivées. Le tampon B n'est pas rempli entièrement, et l'opération retourne un résultat correspondant au contenu M1 et d'une taille de données de 20 . Une deuxième lecture RA2 s'effectue alors après arrivée du seul deuxième message M2, ce qui retourne un résultat correspondant au contenu M2 et d'une taille de données de 30 . Une troisième lecture RA3 s'effectue alors après arrivée du troisième message M3, ce qui retourne un résultat correspondant au contenu M3 et d'une taille de données de 50 . Par exemple pour la taille des données reçues par l'application, ce premier scénario A restitue donc une suite de trois résultats valant 20, 30, 50 .

- 53 - Dans un deuxième scénario SCB, une première lecture RB1 s'effectue alors que les mêmes premier et deuxième messages M1, M2 sont déjà arrivés, ce qui retourne un résultat correspondant au contenu M1, M2 et d'une taille de données de 50 . Une deuxième lecture RB2 s'effectue alors après arrivée du troisième message M3, ce qui retourne un résultat correspondant au contenu M3 et d'une taille de données de 50 . Pour la taille des données reçues par l'application, ce premier scénario SCA restitue donc une suite de deux résultats valant 50, 50 , et ce pour la lecture des mêmes messages.

Ces deux scénarios retournent donc des résultats différents, 20, 30, 50 pour l'un et 50, 50 pour l'autre. En cela, la routine système standard implémentant l'opération read réalise un évènement non déterministe du point de vue de l'application, qu'il s'agisse de la journalisation de l'application maître ou du re-jeu d'une application de reprise.

Pour la même situation qu'en figure 11, la figure 12 représente le scénario unique ScU qui sera obtenu en utilisant une routine modifiée readM en lieu et place de la routine d'origine read .

Dans cet exemple, la routine modifiée prend connaissance de la longueur réelle de chacun des messages reçus et ne lit dans le canal d'entrée ICH que des données correspondant à un seul message, même si le tampon B n'est pas rempli et qu'il reste des données à lire dans le canal d'entrée ICH. Dans le cas de la journalisation de l'application maître, la routine modifiée prend connaissance de la longueur réelle des messages M1, M2, M3 grâce au mécanisme de journalisation des évènements externes correspondant à la réception de ces mêmes messages, par exemple le module IPIogOP. Dans le cas d'un re-jeu lors de la restauration d'une application de reprise, la routine modifiée prend connaissance de la longueur réelle des messages M1, M2, M3 grâce au mécanisme de re-jeu des évènements externes correspondant à la réception de ces mêmes messages, par exemple le module IPIogSB.

Ces deux scénarios d'arrivée SCA, SCB différents donnent alors un même comportement de l'opération de lecture, en l'occurrence une unique -54 suite de trois résultats valant 20, 30, 50 , pour la taille des données reçues par l'application.

De même pour d'autres tailles du tampon B, une routine read d'origine produit différentes suites de résultats sont possibles.

Ainsi, pour un tampon de taille 20 , peuvent être obtenus par exemple: 20, 20, 20, 20, 20 ou 20, 20, 10, 20, 20, 10 .

Pour un tampon de taille 100 , peuvent être obtenus par exemple: 20, 30, 50 ou 50, 50 ou 20, 80 ou 100 .

Par contre, pour chaque taille de tampon, une routine readM ainsi modifiée ne peut donner qu'une seule suite de résultats.

Ainsi, pour un tampon de taille 20 , la suite de résultats obtenue sera 20, 20, 10, 20, 20, 10 .

Pour un tampon de taille 100 , la suite de résultats obtenue sera 20, 30, 50 .

La routine readM ainsi modifiée réalise donc bien un comportement déterministe pour l'évènement interne correspondant à une telle opération de lecture.

Les figures 13 à 15 illustrent un autre exemple d'utilisation de cette technique d'optimisation par changement sémantique, utilisée pour rendre déterministe une opération de lecture multiplexée déclenchée par un processus d'une application réalisant une boucle d'attente et pouvant recevoir des données de plusieurs canaux d'entrée/sortie ( I/O channels ), en particulier associés à plusieurs descripteurs de fichiers. Cet exemple est basé sur l'utilisation de la routine select dans un environnement de type Unix, mais pourrait être également être appliqué à l'utilisation de la routine poli .

Dans le présent exemple, trois messages M1, M2, M3 de contenus valant respectivement a , b et c sont reçus par le système d'exploitation OS du noeud, à destination de deux canaux différents ICH1, ICH2.

Cet exemple peut s'appliquer en particulier à la réception de données sous forme de flux ( stream ) par le premier canal ICH1, et de données sous forme de messages ou paquets de type TCP par le deuxième canal ICH2. Au sein du système d'exploitation OS, deux paquets TCP suivis d'un - 55 paquet stream sont alors reçus sous la forme de trois messages successifs M1, M2, M3 de contenu valant respectivement a , b et c .

Au fur et à mesure qu'il les reçoit et selon sa charge de travail, le système d'exploitation OS traite et répartit ces données dans les canaux ICH1, ICH2 correspondant à leur type. A un instant donné de cours de son exécution, l'application appelle la routine select pour déclencher une opération de lecture des différents canaux par lesquels elle peut recevoir des messages.

Dans son implémentation standard, la routine select lit les données en attente dans le premier canal ICH1 puis dans le deuxième canal ICH2, et les transmet aussitôt à l'application, dans l'ordre où elle les a lues.

Or la vitesse d'arrivée des données dans le système d'exploitation OS, la vitesse de leur traitement par le système d'exploitation, et donc leur vitesse d'arrivée dans les canaux d'entrée, d'une part, et la vitesse d'exécution par l'application d'une succession d'opérations de lecture, d'autre part, peuvent varier l'une par rapport à l'autre d'une façon qui n'est pas prévisible au stade d'une journalisation ou d'un re-jeu.

Dans un premier scénario SCA illustré en figure 13, l'application déclenche une lecture multiplexée par la routine select à un premier instant IA, alors que les trois messages sont déjà arrivés dans les deux canaux d'entrée ICH1, ICH2. Lorsque la routine select lit les données, elle lit donc d'abord le troisième message contenu dans le premier canal ICH1, puis les deux premiers messages M1, M2 dans le deuxième canal ICH2. La routine select transmet ensuite ces données dans l'ordre de lecture, et l'opération de lecture produit donc un résultat comprenant la suite de données c, a, b .

Dans un deuxième scénario SCB illustré en figure 14, l'application déclenche une lecture multiplexée par la routine select à un premier instant IB, alors que seuls les deux premiers messages sont arrivés dans le deuxième canal d'entrée ICH2. Lorsque la routine select lit les données, elle lit donc seulement les deux premiers messages M1, M2 dans le deuxième canal ICH2 et transmet ces données à l'application dans l'ordre de lecture, soit la suite a b . Lors d'une lecture suivante, après que le - 56 - troisième message M3 soit arrivé dans le premier canal ICH1, la routine select lit ce troisième message et le transmet à l'application. Dans ce deuxième scénario B, l'opération de lecture par la routine select d'origine produit donc un résultat comprenant la suite de données a b c .

Ces deux scénarios différents SCA, SCB retournent donc des résultats différents, c a b pour l'un et a b c pour l'autre. En cela, la routine système standard implémentant l'opération select réalise un évènement non déterministe du point de vue de l'application, qu'il s'agisse de la journalisation de l'application maître ou du re-jeu d'une application de reprise.

Pour la même situation qu'en figures 13 et 14, la figure 15 représente le résultat unique qui sera obtenu en utilisant une routine modifiée selectM en lieu et place de la routine d'origine select .

Dans cet exemple, la routine modifiée prend connaissance de l'ordre d'arrivée des messages dans le système d'exploitation OS, et lit les messages dans l'ordre où ils sont arrivés. D'ailleurs, pour diminuer les risques d'ambiguïté, la routine modifiée ne renvoie à chaque fois qu'un seul descripteur de fichier. La routine modifiée peut obtenir les informations d'ordre d'arrivée des messages par exemple en examinant le contenu de messages au sein des canaux d'entrées ICH1, ICH2, ou à partir des données de journalisation ou de re-jeu.

Ces deux scénarios d'arrivée différents SCA, SCB donnent alors un même comportement de l'opération de lecture multiplexée, en l'occurrence une unique suite de trois résultats valant a b c .

En modifiant ainsi le mode de fonctionnement de certaines routines implémentant le comportement d'évènements internes qui n'étaient pas déterministes dans un environnement standard pour les rendre déterministes, on voit que l'on obtient une réduction du nombre d'évènements non déterministes. Lorsque cette modification est appliquée de façon identique lors de la journalisation dans l'application maître et lors du re-jeu dans une application de reprise, on diminue donc le nombre d'évènements qui doivent être journalisés pour pouvoir obtenir à l'issue du re-jeu une application de reprise qui soit dans un état correspondant à celui - 57 - de l'application maître ou qui présente une bonne continuité de fonctionnement avec cette application maître.

Ainsi, on voit que cette technique d'optimisation par changement sémantique permet d'améliorer les performances des opérations de journalisation et de re-jeu, et donc de l'application intermédiaire.

En effet, selon les routines auxquelles on applique cette technique de changement sémantique, et selon la nature de la modification qu'on leur apporte, il peut en résulter une légère perte de performances au sein de cette routine par rapport à son comportement d'origine. Toutefois, étant donnée la lenteur des opérations de journalisation, l'économie générée en termes de nombre d'opérations à journaliser peut permettre d'améliorer de façon significative les performances globales de l'application maître dans le cadre de l'application intermédiaire.

Dans cette description, on voit que les mécanismes de l'application intermédiaire sont principalement réalisés par des processus ou modules s'exécutant dans l'espace utilisateur du noeud opérationnel ou des noeuds secondaires. Il s'agit en particulier des processus de journalisation ou rejeu, externes ou internes, identifiés ici au sein de l'application intermédiaire INT (figure 1) sous les références Plog (figure 2), IPIogOP et IPIogSB (figure 3), PIogOP et PIogSB (figure 4), PRE (figure 5) et PRI (figure 6), META (figure 7).

Par opposition, les mécanismes s'exécutant dans l'espace système comprennent surtout des modules d'interposition, ou d'ajout ou de modification de fonctionnalités, qui sont gérés depuis les modules applicatifs. Il s'agit en particulier des modules identifiés ici sous les références DISP (figure 3), ipfilter (figure 5). Certains de ces modules noyau peuvent d'ailleurs être chargés ou déchargés au fur et à mesure des besoins, depuis les modules applicatifs.

Le fait que le déroulement et la vie de l'application intermédiaire aient lieu dans l'espace utilisateur permet de limiter les interactions avec le système d'exploitation des différends noeuds. Cette particularité apporte en particulier une souplesse de déploiement et de gestion, une certaine indépendance vis-à-vis des systèmes d'exploitation et de leur éventuelle hétérogénéité, limite les risques d'incompatibilité de type ou de versions, et - 58 - permet de limiter les interventions dans l'espace système des noeuds qui ne sont pas ou peu concernés par le déploiement de cette application intermédiaire. Cette indépendance vis-à-vis des systèmes d'exploitation permet également de limiter les temps et coûts de développement en évitant d'intervenir trop profondément dans des éléments préexistants de l'espace système, et de garder une certaine indépendance commerciale ou techniques vis-à-vis des spécifications et évolutions de ces systèmes d'exploitation ou des politiques des organismes qui les gèrent.

Une application intermédiaire telle que décrite ci-dessus peut être implémentée de différentes façons et selon différentes combinaisons pour fournir aux utilisateurs ou gestionnaires d'un cluster un service de soutien ou de gestion à d'autres applications. Un tel service peut en particulier être obtenu sous la forme d'un produit logiciel réseau de type middle-ware , permettant de gérer, d'optimiser ou de fiabiliser, au sein d'un cluster, une ou plusieurs applications dans leur version d'origine ( legacy ) tout en leur assurant des fonctionnalités de souplesse ou de sécurité supplémentaires, par exemple adaptées à la nature du cluster.

Une utilisation d'une telle application intermédiaire peu plus particulièrement prendre la forme d'une sécurisation des services rendus par ces applications à leurs clients. Chaque application pourra alors être traitée comme une application maître, et être restaurée sous la forme d'une application de reprise, pour remplacer l'application maître vis-à-vis de ses clients en cas de besoin.

Les services rendus par des applications s'exécutant en tout ou partie sur un noeud déterminé pourront également être déplacés vers un ou plusieurs autres noeuds de façon dynamique et à la demande, en libérant complètement leur noeud d'origine. Il sera ainsi possible de réaliser toutes les interventions matérielles ou logicielles voulues sur ce noeud, qu'il s'agisse de maintenance, d'essais, d'évolutions ou de remplacement.

Une telle application intermédiaire peut être utilisée en particulier pour réaliser un environnement de type middle-ware comprenant des fonctionnalités de répartition de charge de travail ( load balancing ) entre différents noeuds, pour optimiser l'utilisation des différentes matérielles, en particulier en fonction de leur puissance, de leur disponibilité, ou de leur - 59 - situation géographique au sein du réseau, par exemple leur éloignement vis-à-vis de leurs clients ou des données qui sont utilisées.

Bien sûr, l'invention n'est pas limitée aux exemples qui viennent d'être décrits et de nombreux aménagements peuvent être apportés à ces 5 exemples sans sortir du cadre de l'invention.

- 60 -

Claims (22)

REVENDICATIONS

1. Procédé de gestion d'une opération logicielle (EVInD) non déterministe déclenchée par une instruction de programme au sein du déroulement d'un processus applicatif, dit processus géré (P1, PB1), exécuté par au moins un ordinateur (OP, SB), la réalisation de ladite opération renvoyant audit processus géré au moins une donnée de résultat, dit résultat réel (DR, RRJ), ce procédé comprenant les étapes suivantes: -exécution d'un traitement logiciel déterministe, dit de fonction de prédiction (FH), se basant sur l'état du processus géré ou de l'application (AOP, ASB) à laquelle il appartient, tel qu'il était avant ladite opération (EVInD), pour fournir une valeur susceptible de correspondre au résultat réel et constituant un résultat prédit (RP) pour ladite opération; - test de comparaison pour savoir si la valeur du résultat prédit (RP) correspond ou non à la valeur du résultat réel (DR, RRJ) ; - réalisation d'une phase de gestion complémentaire (CH, DH) de ladite opération gérée, cette gestion complémentaire dépendant du résultat du test précédent.

2. Procédé selon la revendication 1, caractérisé en ce qu'il gère une opération, dite journalisée (EVInD; fig.8c), faisant partie du déroulement d'un processus journalisé (P1) exécuté dans un ordinateur dit noeud primaire (OP), cette gestion enregistrant ladite opération journalisée sous la forme de données de journalisation permettant à un processus de reprise exécuté par un noeud secondaire de rejouer une opération, dite rejouée, correspondant à l'opération journalisée et renvoyant au processus de reprise un résultat correspondant à celui de l'opération journalisée, la phase de gestion complémentaire (CH) comprenant en outre, dans le cas d'un résultat réel (DR) ne correspondant pas au résultat prévu (RP), une mémorisation de données de journalisation incluant une donnée de résultat représentant la valeur du résultat réel (DR) de l'opération journalisée (EVInD), alors qualifiée d'opération non prédite.

- 61 -

3. Procédé selon l'une des revendications 1 ou 2, caractérisé en ce qu'il gère une opération, dite journalisée (EVInD), faisant partie du déroulement d'un processus journalisé (P1) exécuté dans un ordinateur dit noeud primaire (OP), cette gestion enregistrant ladite opération journalisée sous la forme de données de journalisation permettant à un processus de reprise exécuté par un noeud secondaire de rejouer une opération, dite rejouée, correspondant à l'opération journalisée et renvoyant au processus de reprise un résultat correspondant à celui de l'opération journalisée la phase de gestion complémentaire (CH) comprenant en outre un calcul d'une donnée d'identification (SQ) de l'opération journalisée (EVInD).

4. Procédé selon l'une des revendications 2 ou 3, caractérisé en ce qu'il enregistre (JOP) une séquence, dite journalisée, d'opérations du processus journalisé (P1), ladite séquence incluant au moins une opération (EVID), dite non prédite, renvoyant un résultat réel (DR) ne correspondant pas au résultat prédit (RP), cet enregistrement comprenant une mémorisation d'au moins un fichier journal (JSeml) permettant au processus de reprise de rejouer une séquence, dite rejouée, d'opérations correspondant aux opérations de la séquence journalisée, ledit fichier journal comprenant des données représentant le résultat réel, dit journalisé (DR), de ladite opération non prédite et qui sont utilisables pour que, à l'issue d'une opération rejouée correspondant à ladite opération non prédite, le processus de reprise prenne en compte un résultat correspondant audit résultat journalisé.

5. Procédé selon l'une des revendications 2 à 4, caractérisé en ce que, lors de la journalisation d'une séquence du processus journalisé, au moins une opération prédite et non déterministe est journalisée sans mémoriser, au sein du journal (JSeml) de données de journalisation représentant le résultat réel (DR) de ladite opération journalisée prédite et non déterministe (EVInD).

- 62 -

6. Procédé selon la revendication 5, caractérisé en ce que, pour la journalisation d'au moins une opération non prédite (EVInD), les données de journalisation mémorisées dans le journal ()Seuil) comprennent: - d'une part une donnée d'identification représentant la valeur de la donnée de séquencement (SQ) correspondant à ladite opération non prédite, et; d'autre part une donnée de résultat (DR) représentant le résultat réel renvoyé par ladite opération journalisée.

7. Procédé selon l'une des revendications 3 à 6, caractérisé en ce qu'il enregistre (JOP) au sein d'un journal (JSeml) au moins une séquence journalisée, cet enregistrement comprenant une répétition itérative, pour chaque opération journalisée constituant un événement interne non déterministe (EVInD) d'au moins un type au sein de ladite séquence, des étapes suivantes: exécution (4) d'un traitement logiciel déterministe (FH) se basant sur l'état du processus (P1) ou de son application (AOP) avant ladite opération pour fournir une valeur susceptible de correspondre au résultat réel et constituant un résultat prédit (RP) pour ladite opération; test de comparaison (5) pour savoir si la valeur du résultat prédit (RP) correspond ou non à la valeur du résultat réel (DR) ; dans le cas d'un résultat non prédit, mémorisation (6) dans le journal (JSeml) de données de journalisation comprenant de façon associée d'une part la valeur de la donnée de séquencement (SQ) correspondant à l'opération en cours, et d'autre part une donnée de résultat (DR) représentant la valeur du résultat réel renvoyé au processus journalisé par l'opération en cours(EVInD).

8. Procédé selon la revendication 1, caractérisé en ce qu'il gère une séquence, dite rejouée, d'opérations faisant partie du déroulement d'un processus de reprise (PB1), exécuté dans un ordinateur dit noeud secondaire (SB), cette gestion utilisant des données de journalisation (JSeml; fig.8d) pour obtenir que, dans chaque cas d'une opération rejouée - 63 - non déterministe, le processus de reprise prenne en compte un résultat, dit forcé (RF), correspondant au résultat retourné lors de la journalisation (JOP), la phase de gestion complémentaire (DH) comprenant, pour au moins une opération non déterministe (EVInD) non prédite lors de la journalisation: - une lecture (5) dans les données de journalisation d'une donnée de résultat dit journalisé (RLi) représentant le résultat retourné lors de la journalisation de l'opération correspondant à l'opération (EVInD) en cours de rejeu; - une interception du résultat (RRJ) de l'opération rejouée et une transmission (8) du résultat forcé (RLi) au processus de reprise (PB1) en lieu et place du résultat (RRJ) issu de l'opération rejouée.

9. Procédé selon l'une des revendications 1 ou 8, caractérisé en ce qu'il gère une séquence, dite rejouée, d'opérations faisant partie du déroulement d'un processus de reprise (PB1), exécuté dans un ordinateur dit noeud secondaire, cette gestion utilisant des données de journalisation (JSeml) pour obtenir que, dans chaque cas d'une opération rejouée non déterministe, le processus de reprise prenne en compte un résultat, dit forcé (RF), correspondant au résultat retourné lors de la journalisation, la phase de gestion complémentaire (DH) comprenant alors les phases suivantes, pour au moins une opération non déterministe qui a été prédite lors de la journalisation: - exécution (6) d'un traitement logiciel déterministe, dit de fonction de prédiction de rejeu (FH), correspondant à la fonction de prédiction utilisée pour la journalisation de ladite opération et fournissant un résultat prédit (RP) pour l'opération rejouée; - interception du résultat (RRJ) de l'opération rejouée et transmission (8) du résultat prédit (RP), en tant que résultat forcé (RF), au processus de reprise en lieu et place du résultat (RRJ) issu de l'opération rejouée.

- 64 -

10. Procédé selon l'une des revendications 1 ou 8 ou 9, caractérisé en ce qu'il gère une séquence, dite rejouée, d'opérations faisant partie du déroulement d'un processus de reprise(PB1), exécuté dans un ordinateur dit noeud secondaire, cette gestion utilisant des données de journalisation (JSeml) pour obtenir que, dans chaque cas d'une opération rejouée non déterministe, le processus de reprise prenne en compte un résultat, dit forcé (RF), correspondant au résultat retourné lors de la journalisation, la phase de gestion complémentaire (DH) comprenant, au moins pour chaque opération (EVInD) pour laquelle les données de journalisation ne comprennent pas de résultat journalisé, une incrémentation (3) d'une valeur de séquencement (SQ) représentant ladite opération rejouée.

11. Procédé selon l'une des revendications 4 à 10, caractérisé en ce qu'il gère l'ensemble des opérations identifiées comme étant de nature non déterministe ou renvoyant un résultat identifié comme étant de nature non déterministe.

12. Procédé selon l'une des revendications 4 à 11, caractérisé en ce qu'il gère l'ensemble des opérations réalisant, au sein de la séquence gérée, des évènements non déterministes internes au processus géré (Pi, PB1) ou à son application (AOP, ASB), ou à l'ordinateur (OP, SB)qui les exécute.

13. Procédé selon l'une des revendications 1 à 12, caractérisé en ce qu'il gère au moins une opération (EVInD) déclenchée par une instruction exécutée depuis un fichier exécutable (EXE; fig.7) et comprenant un appel à une routine, dite d'origine (R, RnD), externe audit fichier exécutable, l'exécution de ladite instruction réalisant un appel à une routine dite modifiée (RM, RMnD), en lieu et place de ladite routine d'origine, cette routine modifiée réalisant ou déclenchant la mise en oeuvre du procédé.

14. Procédé selon la revendication 13, caractérisé en ce que la routine modifiée (RMnD) comprend au moins une instruction exécutée au sein du logiciel système (OPS, SBS) et réalisant un appel à au moins un agent logiciel de gestion (PlogOP, PRI), gérant la mise en oeuvre du procédé et - 65 - étant exécuté dans l'espace mémoire utilisateur (OPU, SBU) de l'ordinateur du processus géré.

15. Procédé selon l'une des revendications 13 ou 14, caractérisé en ce que la routine modifiée (RMnD) comprend une instruction de test vérifiant si l'instruction qui l'a appelée est exécutée dans le cadre d'une journalisation ou d'un rejeu, ce test conditionnant l'appel à un agent de gestion de type journalisation (PIogOP) ou respectivement de type rejeu (PRI).

16. Procédé selon l'une des revendications 12 à 15, caractérisé en ce qu'il utilise au moins une fonction de prédiction (FH) comprenant un traitement logiciel déterministe qui dépend des caractéristiques d'un ou plusieurs événements externes d'au moins un type, survenus précédemment au cours du déroulement du processus géré (P1, PB1).

17. Procédé selon l'une des revendications 4 à 16, caractérisé en ce qu'il journalise au moins une première opération en utilisant une première fonction de prédiction et une deuxième opération en utilisant une deuxième fonction de prédiction.

18. Procédé selon la revendication 17, caractérisé en ce qu'il utilise une fonction de prédiction (FH) choisie par sélection ou combinaison déterministe au sein d'une pluralité de fonctions déterminées.

19. Procédé selon l'une des revendications 17 ou 18, caractérisé en ce que le choix de la fonction de prédiction (FH) utilisée dépend de l'évolution d'une grandeur mesurée ou calculée au fur et à mesure du déroulement du processus journalisé (P1).

20. Procédé selon l'une des revendications 18 ou 19, caractérisé en ce que le fichier journal (UL, KL, JSemi) comprend des données représentant au moins un choix de fonction de prédiction (FH) ou un choix de paramètres conditionnant un tel choix.

- 66 -

21. Procédé selon l'une des revendications 2 à 20, caractérisé en ce qu'il réalise une gestion de fonctionnement d'au moins un processus applicatif dit journalisé (P1) et comprend les étapes suivantes: journalisation (JOP) de l'ensemble des évènements d'au moins un type déterminé survenus au cours du déroulement dudit processus journalisé à partir d'un point déterminé dit de reprise et jusqu'à un point dit d'interruption, et mémorisation d'un journal (UL, KL, JSeml) issu de ladite journalisation; - à partir d'un processus de reprise (PB1) dans un état correspondant à l'état de point de reprise du processus journalisé, rejeu (RSB) par ledit processus de reprise desdits évènements à partir dudit journal, amenant ainsi le processus de reprise à un état correspondant à l'état du processus journalisé au point d'interruption.

22. Procédé selon la revendication 21, caractérisé en ce que l'état du processus journalisé (P1) au point de reprise est capturé (CAP) et mémorisé sous la forme de données de point de reprise (EPR), qui sont utilisées pour restaurer (RES) le processus de reprise (PB1) à l'état de point de reprise avant de lui appliquer l'étape de rejeu (RSB).