Brevet FR2843209A1 — publié le 20040206

"Procédé de réplication d'une application logicielle dans une architecture multi-ordinateurs, procédé pour réaliser une continuité de fonctionnement mettant en oeuvre ce procédé de réplication, et système multi-ordinateurs ainsi équipé " La présente invention concerne un procédé pour répliquer une application logicielle dans une architecture multi10 ordinateurs (cluster). Elle vise également un procédé pour réaliser une continuité de fonctionnement d'une application logicielle au sein d'un cluster d'ordinateurs, qui met en oeuvre le procédé de réplication selon l'invention, ainsi qu'un système multi-ordinateurs implémentant ce procédé de continuité de fonctionnement. Le domaine de l'invention est celui des clusters d'ordinateurs formés de plusieurs ordinateurs collaborant entre eux. Ces clusters sont par exemple prévus pour exécuter des applications logicielles. Ainsi, à un instant donné, une application est exécutée sur l'un des ordinateurs du cluster, appelé noeud primaire ou opérationnel (OP), tandis que les autres ordinateurs du cluster sont appelés noeuds secondaires ou " stand- by " (SB), dans un contexte d'architecture redondante. Or, l'exploitation de tels clusters montre que se posent des problèmes de fiabilité qui peuvent être dus à des défaillances du matériel ou du système d'exploitation, à des erreurs humaines, ou à la défaillance des applications ellesmêmes. Pour résoudre ces problèmes de fiabilité, il existe actuellement des mécanismes, dits de haute disponibilité, qui sont mis en oeuvre sur la plupart des clusters actuels et qui sont basés sur un redémarrage automatique à froid de l'application sur un noeud de secours parmi l'un des noeuds secondaires du cluster. Or ces mécanismes basés sur un redémarrage automatique ne permettent pas d'assurer une continuité totale du services fourni par l'application en cours d'exécution au moment de a défaillance. En particulier, se pose le problème de la réplication d'une application logicielle au sein d'une architecture multi-ordinateurs, cette réplication devant assurer une continuité totale de service. Un objectif principal de la présente invention est donc de proposer un procédé pour répliquer une application logicielle dans une architecture multi-ordinateurs (cluster), ladite application logicielle étant préalablement exécutée sur un premier ordinateur dudit cluster constituant un noeud primaire et étant destinée à être répliquée sur au moins un autre ordinateur dudit cluster constituant un noeud secondaire, comprenant une réplication des ressources associées à ladite application logicielle. Cet objectif principal est atteint avec un tel procédé de réplication caractérisé en ce qu'il comprend une mise à jour au fil de l'eau des ressources répliquées par un mécanisme d'introspection dynamique prévu pour fournir la structure de l'application à répliquer, ainsi que le graphe dynamique des ressources et dépendances mises en oeuvre. On peut en outre avantageusement prévoir que ce procédé de réplication comprenne en outre une création et une maintenance d'un arbre de dépendance, qui fournit à chaque instant des informations sur les ressources qu'il est nécessaire de répliquer. Il est important de noter que dans le procédé de réplication selon l'invention, le nombre de noeuds secondaires ou stand-by concernés peut être quelconque. Dans un mode de réalisation préféré de l'invention, le procédé de réplication selon l'invention comprend en outre un mécanisme dit de " point de reprise (" checkpointing ") par lequel les ressources à répliquer sont répliquées sur un ou plusieurs noeuds secondaires. Le procédé de réplication selon l'invention peut avantageusement comprendre les trois étapes suivantes: - capture des ressources sur le noeud primaire, transfert par le réseau vers un ou plusieurs noeuds secondaires, - restauration sur le ou les noeuds secondaires. Le procédé de réplication selon l'invention peut être avantageusement mis en oeuvre pour une optimisation automatique de ressources informatiques par partage de charge par répartition dynamique de processus. Il peut aussi être utilisé pour une maintenance non interruptive par relocation à la demande de processus au travers d'un réseau de ressources informatiques, ou pour une préservation de contexte applicatif dans des applications mobiles. Un autre but de la présente invention est de proposer un procédé pour réaliser une continuité de fonctionnement d'une application logicielle dans une architecture multiordinateurs (cluster), cette application étant exécutée à un instant donné sur l'un des ordinateurs du cluster, appelé noeud principal ou opérationnel, les autres ordinateurs dudit cluster étant appelés noeuds secondaires. Cet autre objectif est atteint avec un procédé pour réaliser une continuité de fonctionnement d'une application logicielle dans une architecture multi-ordinateurs (cluster), cette application étant exécutée à un instant donné sur l'un des ordinateurs du cluster, appelé noeud principal, les autres ordinateurs dudit cluster étant appelés noeuds secondaires. -4 Suivant l'invention, le procédé comprend les étapes suivantes: réplication de l'application sur au moins des noeuds secondaires, de façon à réaliser au moins un clone de ladite application, - mise à jour au fil de l'eau dudit ou desdits clones, et - en cas de détection d'une défaillance ou d'un événement affectant ledit noeud principal, basculement de service vers l'un au moins desdits clones. Ainsi, avec le procédé de réalisation de continuité de fonctionnement selon l'invention, il est désormais possible de disposer de noeuds secondaires pourvus de clones d'application résultant de la réplication de l'application et aptes à relayer sans discontinuité cette application en cas de détection de défaillance ou d'événement affectant le noeud principal. La réplication mise en oeuvre dans le procédé de réplication selon l'invention est avantageusement de type holistique. On dispose ainsi d'un clonage de l'application au fil de l'eau, avec une mise à jour de ces clones, de façon déterministe et complète. Ces clones sont dits " chauds ", c'est-à-dire qu'ils sont la réplique exacte de l'application et de tout son contexte opératoire. Ils sont mis à jour régulièrement (périodiquement ou sur évènements caractéristiques). Ces clones contiennent toutes les ressources et informations requises par l'application pour fournir son service. Le procédé de réplication selon l'invention permet en outre de superviser l'état de toutes les ressources nécessaires au bon fonctionnement de l'application. Quand la dégradation rédhibitoire de l'une d'entre elles est détectée, le procédé de réplication selon l'invention prévoit une -5 élection d'un clone comme nouveau primaire et lui ordonne de prendre la main. Cette élection est appelée basculement et est transparente pour le reste du monde qui communique avec l'application: bien que le noeud primaire soit mis hors service, le service fourni par l'application n'est pas interrompu car il est repris avec tout son contexte par le clone élu. On peut ainsi garantir que tout message transmis par le reste du monde à l'application sera traité, soit par le noeud primaire (pré-basculement), soit par le clone (postbasculement). Pour ce faire, le procédé de réplication selon l'invention peut en outre comporter un enregistrement sur chaque clone (en plus du mécanisme de clonage périodique) de tous les messages reçus par le primaire depuis la dernière mis à jour des clones. Ces messages seront réinjectés dans le clone élu nouveau primaire en cas de basculement. La réplication holistique reprend des mécanismes déjà mis en òuvre dans des systèmes existants de migration de process. Cependant, la conception et l'utilisation qui en sont faites dans le procédé de réplication selon l'invention diffèrent de tous les travaux antérieurs connus. Le procédé de réalisation de continuité de fonctionnement selon l'invention met ainsi en òuvre une réplication transparente, holistique et optimisée, dédiée à la continuité de service par délocalisation de l'application et virtualisation des ressources. Avec ce procédé, on résout plusieurs limitations des implémentations classiques qui les rendaient inopérantes pour une utilisation en tolérance aux pannes au sein d'une architecture multi-ordinateurs en cluster. Une première limitation résidait dans le problème de l'indépendance entre noeud primaire et noeud secondaire. Dans les systèmes classiques, la réplication d'une ressource d'un noeud primaire vers un noeud secondaire présuppose et nécessite la présence opérationnelle du noeud primaire pendant tout le procédé. Le procédé de réplication selon l'invention résout cette limitation, puisque le clone peut à tout instant vivre de façon autonome même en cas de disparition du primaire. Cette dé-corrélation primaire / secondaire est un pré requis pour la tolérance aux pannes. Comme la réplication implémentée dans le procédé de réplication selon l'invention est holistique, on capture l'intégralité cohérente de ressources asynchrones interdépendantes. Dans les procédés de l'art antérieur, seuls étaient capturés les états de ressources indépendantes. Une autre limitation des procédés de l'art antérieur résidait dans le problème de l'intrusivité. Le procédé de réplication selon l'invention est non intrusif sur le code source: les instances antérieures nécessitent de modifier le code source (ou de le concevoir explicitement) pour que les processus informatiques créés et les ressources utilisées puissent être migrés. Il est à noter que pour la mise en oeuvre du procédé de réplication selon l'invention, on peut avantageusement utiliser des techniques d'ingénierie logicielle non intrusive dynamique, qui ont fait l'objet d'une demande de brevet publiée le 2 aot 2002 sous le numéro FR2820221. Ces techniques d'ingénierie logicielle permettent de manipuler des applications dans leur représentation binaire (exécutable), de façon à rendre le procédé de réalisation de continuité de fonctionnement selon l'invention transparent pour l'application et donc générique. Suivant un autre aspect de l'invention, il est proposé un système multiordinateurs prévu pour exécuter sur au moins des ordinateurs au moins une application logicielle, -7 implémentant le procédé pour réaliser une continuité de fonctionnement selon l'invention. D'autres avantages et caractéristiques de l'invention apparaîtront à l'examen 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 illustre la fonction de miroir dynamique mise en òuvre dans le procédé de réplication selon l'invention; -la figure 2 illustre schématiquement les principes de réplication de données mis en òuvre dans le procédé de réplication selon l'invention; -la figure 3 représente un exemple d'architecture logicielle mettant en oeuvre le procédé de réplication selon l'invention, pour la supervision et la détection de défaillance; -la figure 4 illustre schématiquement des principes de supervision mis en oeuvre dans le procédé de réplication selon l'invention; -la figure 5 illustre schématiquement le mécanisme de copie sur écriture (" copy on write ") mis en oeuvre dans le procédé de réplication selon l'invention; -la figure 6 illustre schématiquement le mécanisme d'incrémentation pour réplication mis en oeuvre dans le procédé de réplication selon l'invention; et -la figure 7 illustre schématiquement le mécanisme de commutation mis en oeuvre dans le procédé de réplication selon l'invention. On va d'abord décrire, en référence aux figures précitées, le fonctionnement du mécanisme de réplication holistique mis en oeuvre dans le procédé de réplication selon l'invention. Pour que l'application puisse correctement tourner sur un noeud secondaire dans le cas d'un basculement, il est nécessaire que l'ensemble des ressources requises par cette application soit également répliqué sur le noeud secondaire. Si ces ressources sont des ressources à état, i.e. qu'elles varient au fil de l'exécution de l'application et contribuent à son contexte global, alors leur état doit également être capturé et répliqué de façon cohérente. L'ensemble de ces ressources est découvert à l'initialisation de l'application puis maintenu à jour au fil de l'eau par des mécanismes d'introspection dynamique qui permettent d'obtenir automatiquement la structure de l'application à protéger, ainsi que le graphe dynamique des ressources et dépendances mises en oeuvre. Ces mécanismes s'appuient sur les caractéristiques réflexives des binaires, sur les mécanismes d'héritage des systèmes d'exploitation et sur la surveillance, via une instrumentation binaire, des mécanismes incluant les appels système - qui contribuent à modifier l'état de ses ressources. En référence à la figure 4, dans un exemple de mise en oeuvre du procédé de réplication selon l'invention, des pilotes (drivers) d'introspection et de surveillance assurent une surveillance sur tous les noeuds du cluster et transmettrent des données de surveillances à la base d'information de gestion MIB du système. Cette base MIB est sollicitée à la fois dans la gestion du cluster sur le noeud opérationnel pour les déclenchements de point de reprise (checkpoint> et dans la gestion du cluster sur des noeuds " back-up ". La base MIB est également sollicitée par le gestionnaire de supervision avec une base MIB synthétique et est accédée par l'administrateur système auquel sont associées des interfaces utilisateur graphiques (GUI). 9 2843209 Le résultat de ce travail de découverte et d'introspection au fil de l'eau est la création et la maintenance d'un " arbre de dépendance ", qui fournit au procédé de réplication selon l'invention à chaque instant des informations sur les ressources qu'il est nécessaire de répliquer. L'existence de ce graphe garantit la complétude et la cohérence des clones. Un autre mécanisme de point de reprise (" checkpointing "), mis en oeuvre dans le procédé de réalisation de continuité de fonctionnement selon l'invention, consiste à répliquer les ressources sur un ou plusieurs noeuds secondaires. Ce mécanisme de réplication des ressources est réalisé en trois étapes: - capture des ressources sur le noeud primaire, transfert par le réseau vers un ou plusieurs noeuds secondaires, et - restauration sur le ou les noeuds secondaires. Les ressources répliquées incluent: - la mémoire virtuelle de chaque processus concerné ainsi que sa pile d'appel, - des ressources systèmes (inter process communication, connexion réseau, etc.), et - des données écrites sur disques. Le mécanisme de réplication des ressources assure que l'ensemble des ressources nécessaires à l'application est transféré de façon complète et cohérente (d'o holistique). La mise en òuvre du procédé de réplication selon l'invention garantit que l'application puisse continuer de vivre sur le secondaire sans perdre son contexte: l'application est délocalisée, le matériel et le système d'exploitation sous-jacent sont virtualisés, l'application se comportant indépendamment de sa localisation physique. - 10 - 2843209 En cas de basculement, l'application n'est pas considérée comme stoppée: elle continue de tourner dans son contexte, mais sur d'autre ressources matérielles. Les ressources mises en oeuvre par l'application sont diverses et variées (multi process, système d'exploitation, etc.). Elle vivent de façon asynchrone, sur un environnement non déterministe. Le procédé de réplication selon l'invention met en oeuvre un algorithme de " checkpointing " (génération de points de reprise) asynchrone une barrière de synchronisation est transmise à toutes les ressources et le procédé de réplication selon l'invention garantit que la capture d'état est complète et cohérente. On va maintenant décrire une technique d'optimisation mise en òuvre dans le procédé de réplication selon l'invention. La capture déterministe et complète de l'état de toutes les ressources est coteuse pour les performances du système. Or, un faible impact sur les performances de l'application est un pré requis pour l'acceptabilité par le marché du produit et donc in fine pour son utilité. Plusieurs techniques d'optimisation ont donc été conçues et développées pour minimiser cet impact. Premièrement, le point de reprise quasi synchrone est une optimisation des mécanismes de génération de point de reprise (checkpointing) classiques: il offre la cohérence de capture des algorithmes synchrones, sans pour autant nécessiter l'arrêt total du système pendant la capture que nécessitent les algorithmes asynchrones. La période du point de reprise est ajustable, de sorte à optimiser le compromis entre le temps de reprise après basculement (potentiellement d'autant plus long que la période entre deux points de reprise est longue) et la quantité d'information d'état à capturer et à transférer. il 2843209 Par ailleurs, le point de reprise est incrémental: seules les différences d'état entre deux points de reprise sont transmises, comme l'illustre l'exemple fonctionnel de la figure 1. Dans cet exemple, un point de reprise incrémental est effectué à partir de l'application maître pour obtenir l'application réplique et un disque partagé entre les deux noeuds primaire et secondaire est mis en oeuvre. Ainsi, le premier point de reprise est cher en performance (initialisation des clones) mais les suivants sont d'impact faible. Le point de reprise est également discriminant l'analyse intelligente du graphe de dépendance permet de limiter au strict nécessaire la quantité d'information à transmettre. Enfin, des mécanismes de " Copy On Write " (copie sur écriture) offerts par le système d'exploitation sont mis en oeuvre pour séparer le temps de capture du temps de transfert, en référence à la figure 5 qui illustre un exemple de mise en òuvre d'un mécanisme de copie sur écriture dans un procédé de réplication selon l'invention, à la suite du déclenchement d'un point de reprise. Dans cet exemple, le mécanisme de copie sur écriture intervient sur des blocs de données (mémoire ou disque) pour une nouvelle référence, après une requête en écriture issue d'un Utilisateur via un process ou un i-node (noeud d'index). Seuls les blocs de données modifiés sont répliqués, comme l'illustre la figure 6. On va maintenant décrire un exemple de mise en oeuvre du mécanisme de génération de point de reprise quasi-synchrone au sein du procédé de réalisation de continuité de fonctionnement selon l'invention. Ce mécanisme inclut: - une barrière de synchronisation de processus (" Process Synchronisation Barrier ": PSB), - 12 - une gestion de ressources (" Ressource Management " RM), - une gestion de ressources système (" System Resources Management ": (SRM), et - une gestion de ressources de processus (" Process Resources Management " (PRM). La barrière de synchronisation de processus (PSB) est un mécanisme permettant de synchroniser le blocage des processus composant une application tout en respectant la gestion des entrées/sorties en cours, dans le but de pouvoir prendre à un instant T une "photographie" non floue de l'état du système et de l'application. La gestion de ressources (RM) est un ensemble d'automates génériques permettant de mettre en oeuvre le séquencement des différentes phases du checkpointing vis à vis des différentes ressources nécessaires pour répliquer une application d'une machine sur une autre: La gestion de ressources système (SRM) inclut des mécanismes permettant de gérer les différentes routines de gestion des ressources systèmes utilisées par une application (ensemble de processus) lors des différentes phases du mécanisme de génération de point de reprise. La gestion de ressources de processus (PRM) inclut des mécanismes permettant de gérer les différentes routines de gestion des ressources utilisées par un processus lors des différentes phases du mécanisme de génération de point de reprise. Ce code est chargé dynamiquement à l'intérieur des processus applicatifs lors de leur lancement. Il existe aujourd'hui trois phases principales qui sont elles même découpées en différentes phases nécessaires pour la captures des ressources utilisées par l'application. - 13 La raison d'être de ces différentes sous-phases est de minimiser les temps de blocages applicatif liés à la récupération/restauration des différentes ressources applicatives et système ainsi que de garantir la cohérence des informations sauvegardées. DUMP: RMPREDUMP RMDUMP RMPOSTDUMP RM ABORTDUMP RESTORE: RMPRERESTORE, RMNRESTORE, RMPOSTRESTORE, RMABORTRESTORE, SWITCH: RM PRE SWITCH, RMSWITCH, RMPOST SWITCH, RMABORTSWITCH, On va maintenant décrire une virtualisation des ressources systèmes dans le cadre du procédé de réplication selon l'invention. Certaines ressources systèmes UNIX sont caractérisées par un identifiant unique propre à chaque machine. Ces identifiants sont stockés sous forme de variables par les applications, ce qui leur permet de pouvoir les référencer. Lors de la migration d'une application d'une machine à une autre la mémoire des applications est intégralement transférée, y compris les données relatives aux ressources systèmes. Pour pouvoir garantir l'unicité du référencement des ressources système par une application - 14 - 2843209 META-CLUSTER met en oeuvre des mécanismes de virtualisation de ces ressources, permettant de maintenir des identifiants uniques entre les différentes machines composant un CLUSTER. Ces mécanismes de virtualisation sont aujourd'hui appliqués pour les identifiants de ressources système suivants: - Processus - PIPE - FIFO - IPC System V - Mémoires partagées - Sémaphores - Message queues - Socket AF UNIX - Threads Les mécanismes de virtualisation assurent donc l'unicité du référencement d'une ressource système au sein du cluster ainsi que sa translation vers une ressource système sur chaque machine. Ils sont implémentés sous la forme de modules noyau dynamiques assurant la non-préemptivité de requêtes qui leurs sont faites, sur des systèmes mono et multiprocesseurs, et avec une capacité à instrospecter les différentes routines permettant de manipuler ces identifiants. A titre d'exemple non limitatif, une routine getpid est instrumentée par META lors de la prise en charge de l'application par META-CLUSTER et son utilisation par l'application retourne un CLUSTERPID qui pourra ensuite être utilisé par l'application sur toute routine prenant un PID comme paramètres (kill, waitpid,...). Le procédé de réplication selon l'invention inclut aussi un module de réplication de fichiers de données applicatives entre le noeud opérationnel et le noeud stand-by, désigné sous le terme de CFOR (Cluster File system Optimized Replication: - 15 - 2843209 Réplication Optimisée de système de Fichier pour Cluster), en en référence à la figure 2. Le module CFOR réalise ainsi les fonctions suivantes a) écriture de données b) modification du Log (journal) c) ordre de réplication d) synthèse construite à partir des données e) synthèse de transfert f) mise à jour du système de fichiers (FS) Le fonctionnement de ce module de réplication est le suivant entre chaque copie (dump), CFOR construit à la volée un journal cumulatif et synthétique des modifications apportées au système de fichiers par les applications contrôlées par le cluster. Les modifications du système de fichier sont extraites à la volée par instrumentation dans les processus applicatifs des divers appels systèmes: write(2), mkdir(2), rmdir(2), unlink(2)... Le principe consiste à ne mémoriser que les actions sans les données. Ainsi si une application écrit 2Mo dans un fichier, on ne mémorise que l'action "fichier, écriture, début, fin", les 2Mo de données ayant été sauvegardés par l'OS sur le disque, il n'est pas nécessaire de les dupliquer ailleurs. Les écritures multiples sont synthétisées au fil de l'eau. Si une application effectue les actions suivantes: l.ouverture du fichier 'toto' 2.écriture de 30000 octets à l'offset 30 dans le fichier toto 3.écriture de 20000 octets à l'offset 20 dans le fichier toto 4.fermeture du fichier 'toto' Le log CFOR résultant sera: - 16 *fichier toto, 20 ? 30030 Au moment de la copie (dump), les données structurelles (metadata) ainsi que le contenu des modifications sont enregistrés dans un fichier séparé. Ce fichier séparé est transmis sur le noeud stand-by et son exploitation permet de synchroniser l'arborescence de manière à ce qu'elle soit strictement identique à celle du noeud opérationnel au moment du dump. On va maintenant décrire le mécanisme de synchronisation mis en oeuvre dans le procédé de réplication selon l'invention. Lors de l'apparition d'une machine SB, il faut synchroniser son système de fichiers (FS) par rapport à celui du noeud opérationnel OP. Cette synchronisation doit se faire sans bloquer le noeud opérationnel OP donc elle se fait sur un système de fichiers en constante évolution. Afin d'éviter le problème des images floues, la synchronisation se fait au travers d'un instantané (snapshot) du système de fichiers (file system) du noeud opérationnel OP. La procédure est décomposée en 2 phases afin de limiter la taille du log de CFOR. 1.Création d'un instantané (snapshot) sur le noeud opérationnel OP 2.1ère synchro avec le noeud SB 3.Destruction de l'instantané (snapshot) sur le noeud opérationnel OP 4.Activation du log de CFOR et création d'un 2éme instantané (snapshot) sur le noeud opérationnel OP 5. 2éme synchronisation avec le noeud SB (elle doit être la plus courte possible). - 17 - 2843209 6.Suppression de l'instantané (snapshot) sur le noeud opérationnel OP, le noeud SB étant prêt à recevoir un première copie (dump) totale. 7.A la prochaine copie (dump), transfert du log de CFOR et mise à jour du système de fichiers FS du noeud SB avec les données de CFOR 8.le cycle normal des copie/restauration (dump/restore) est en place. La recopie de la mémoire d'un processus se fait en analysant dynamiquement l'organisation mémoire interne du processus et en isolant les différentes zones - texte - données - pile d'exécution L'analyse de la mémoire est effectuée sans intrusion dans le code utilisateur en s'appuyant sur les données fournies par le système d'exploitation (Operating System). Ces données sont capturées et analysées dans le contexte même du processus et permettent de créer la table des zones mémoires utilisées. Une fois l'analyse terminée, les agents d'interposition des appels système d'allocation/libération mémoire assurent le suivi de l'évolution de la table des zones mémoires. Lors de la copie (dump), seules les zones mémoire modifiables, c'est à dire accessibles en écriture sont transférées sur le noeud stand-by o elles seront recopiées. Ainsi le processus sur le noeud stand-by contient les mêmes zones mémoires avec les mêmes données que sur le noeud opérationnel. La sauvegarde du contenu de la mémoire devant être atomique du point de vue d'un processus, elle doit se faire sans que le processus ne puisse en changer l'état, donc processus bloqué. Afin de ne pas bloquer le processus trop - 18 - 2843209 longtemps, on s'appuie sur le mécanisme de " Copy On Write " du système d'exploitation (primitive (fork) par exemple) pour créer une copie de l'image mémoire du processus et on transfert cette image vers les noeuds stand-by. Une fois le transfert terminé, l'image mémoire maintenue par les mécanismes de " Copy On Write " est supprimée. Le procédé de réplication selon l'invention met aussi en òuvre un mécanisme de copie (dump) incrémentale qui s'appuie sur l'analyse mémoire, mais ajoute en plus un mécanisme de protection des pages en écriture. Une fois l'analyse des pages effectuée, toutes les pages accessibles en écriture sont protégées, c'est à dire qu'une écriture dans une de ces pages déclenche l'émission d'un signal de violation de protection de pages. La protection s'appuie sur les mécanismes fournis par le système d'exploitation tel que l'appel système " mprotect ". Lorsque l'application tente de modifier une donnée, la ou les pages contenant cette donnée sont marquées comme modifiées et déprotégées. Le déroulement du code applicatif n'est pas impacté par l'adjonction de ces mécanismes (non intrusivité). Lors d'une copie (dump) incrémentale, seules les pages modifiées depuis le précédent dump sont transférées. La copie (dump) terminée, toutes les pages modifiées sont re-protégées afin de détecter les prochaines écritures. La copie (dump) incrémentale permet de réduire la taille des données à transférer vers le stand-by à chaque copie (dump). La gestion des déclenchements des points de reprise peut être effectuée à partir de la base MIB qui reçoit, du noeud primaire ou opérationnel, des informations sur les états du système et de l'application, des informations sur les événements et call-back sur l'application et des informations délivrées par un analyseur d'état synthétique, comme - 19 - 2843209 l'illustre la figure 7. L'organisation du basculement de l'application du noeud primaire vers un noeud secondaire agit par exemple sur un dernier point de reprise EVENT, un dernier point de reprise PERIODIC, un enregistrement (logging) d'entrée, et peut inclure: - le choix d'un scénario de basculement, - le choix d'un point de reprise, - le déclenchement de la restauration, - le déclenchement (ou non) du re-jeu du Log - la notification du nouveau noeud opérationnel. Bien sr, 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 exemples sans sortir du cadre de l'invention. - 20 - 2843209 REVENDICATIONS 1. Procédé pour répliquer une application logicielle dans une architecture multi-ordinateurs (cluster), ladite application logicielle étant préalablement exécutée sur un premier ordinateur dudit cluster constituant un noeud primaire et étant destinée à être répliquée sur au moins un autre ordinateur dudit cluster constituant un noeud secondaire, comprenant une réplication des ressources associées à ladite application logicielle, caractérisé en ce qu'il comprend une mise à jour au fil de l'eau desdites ressources répliquées par un mécanisme d'introspection dynamique prévu pour fourni la structure de l'application à répliquer, et un graphe dynamique des ressources et dépendances mises en oeuvre. 2. Procédé de réplication selon la revendication 1, caractérisé en ce qu'il comprend en outre une création et une maintenance d'un arbre de dépendance, qui fournit à chaque instant des informations sur les ressources qu'il est nécessaire de répliquer. 3. Procédé de réplication selon l'une des revendications 1 ou 2, caractérisé en ce qu'il comprend en outre un mécanisme de génération de point de reprise (" checkpointing "), par lequel les ressources à répliquer sont répliquées sur un ou plusieurs noeuds secondaires. 4. Procédé de réplication selon la revendication 3, caractérisé en ce qu'il comprend trois étapes: - capture des ressources sur le noeud primaire, - 21 - 2843209 - transfert par le réseau vers un ou plusieurs noeuds secondaires, et - restauration sur le ou les noeuds secondaires. 5. Procédé de réplication selon l'une quelconque des revendications précédentes, caractérisé en ce que les ressources répliquées incluent: - la mémoire virtuelle de chaque processus concerné ainsi que sa pile d'appel, - des ressources systèmes (inter process communication, connexion réseau, etc.), et - des données écrites sur disques. 6. Procédé de réplication selon l'une quelconque des revendications précédentes et la revendication 3, caractérisé en ce qu'il comprend en outre un mécanisme d'optimisation du mécanisme de génération de point de reprise. 7. Procédé de réplication selon la revendication 6, caractérisé en ce que le mécanisme de " checkpointing " est incrémental. 8. Procédé de réplication selon l'une des revendications 6 ou 7, caractérisé en ce que le mécanisme de " checkpointing " est discriminant. 9. Procédé de réplication selon l'une des revendications 6 à 8, caractérisé en ce que le mécanisme de " checkpointing " inclut au moins l'une des fonctions suivantes: - une barrière de synchronisation de processus (PSB), - une gestion de ressources (RM), - une gestion de ressources système (SRM),et - 22 - 2843209 - une gestion de ressources de processus (PRM). 10. Procédé de réplication selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comprend en outre un mécanisme de réplication de fichiers de données applicatives entre un noeud opérationnel (OP) sur lequel l'application est exécutée et un noeud dit de stand-by (SB). 11. Procédé pour réaliser une continuité de fonctionnement d'une application logicielle dans une architecture multiordinateurs (cluster), cette application étant exécutée à un instant donné sur l'un des ordinateurs du cluster, appelé noeud primaire ou opérationnel, les autres ordinateurs dudit cluster étant appelés noeuds secondaires, ce procédé mettant en oeuvre le procédé de réplication selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comprend les étapes suivantes - réplication de l'application sur au moins des noeuds secondaires, de façon à réaliser au moins un clone de ladite application, - mise à jour au fil de l'eau dudit ou desdits clones, et - en cas de détection d'une défaillance ou d'un événement affectant ledit noeud opérationnel, basculement de service vers l'un au moins desdits clones. 12. Procédé de continuité de fonctionnement selon la revendication 11, caractérisé en ce que la réplication de l'application est de nature holistique. - 23 - 2843209 13. Procédé de continuité de fonctionnement selon l'une revendication 11 ou 12, caractérisé en ce qu'il comprend en outre une mise à jour des clones de l'application. 14. Procédé de continuité de fonctionnement selon l'une des revendications 11 à 13, caractérisé en ce qu'il comprend en outre une supervision de l'état de ressources nécessairement au fonctionnement de l'application. 15. Procédé de continuité de fonctionnement selon l'une des revendications 11 à 14, caractérisé en ce qu'il comprend en outre, à la suite d'une détection d'une défaillance ou d'un événement affectant le noeud opérationnel, une étape pour élire, parmi des clones installés sur des noeuds secondaires, un clone pour être substitué à l'application initiale, le noeud sur lequel ledit clone élu est installé devenant le nouveau noeud opérationnel. 16. Procédé de continuité de fonctionnement selon l'une des revendications 11 à 15, caractérisé en ce qu'il comprend en outre un enregistrement sur chaque clone de messages reçus par le noeud primaire ou opérationnel, ces messages étant réinjectés dans le clone élu nouvel opérationnel en cas de basculement. 17. Système multi-ordinateurs prévu pour exécuter sur au moins desdits ordinateurs au moins une application logicielle, implémentant le procédé pour réaliser une continuité de fonctionnement selon l'une quelconque des revendications 11 à 16. 18. Application du procédé de réplication selon l'une quelconque des revendications 1 à 10, pour une optimisation - 24 - 2843209 automatique de ressources informatiques par partage de charge par répartition dynamique de processus. 19. Application du procédé de réplication selon l'une quelconque des revendications 1 à 10, pour une maintenance non interruptive par relocation à la demande de processus au travers d'un réseau de ressources informatiques. 20. Application du procédé de réplication selon l'une quelconque des revendications 1 à 10, pour une préservation de contexte applicatif dans des applications mobiles.