Brevet FR2745100A1 — publié le 19970822

8YsTEME INFORMATIQUE A TRANSPARENCE DE PANNE POUR LES APPLICATIONS UTILISATEUR L'invention se rapporte à un système informatique à transparence de pane pour les applications utilisateurs, en cours d'exécution. L'invention se rapporte plus particulièrement aux systèmes informatiques tolérants aux fautes. Ces systèmes permettent d'assurer la continuité du service en présence de défaillances. Un objet de l'invention est de proposer un système tolérant aux fautes supportant l'exécution d'applications standard, c'est à-dire d'application ne nécessitant pas de modifications spécifiques pour profiter de la tolérance aux fautes. On entend par systèmes informatiques des ensembles formés d'une ou plusieurs machines de traitement de données du type ordinateur ou micro-ordinateur lesquelles peuvent être reliées entre elles par un réseau local ou à travers le réseau public ou au moyen de lignes spécialisées. On s'intéresse plus particulièrement ici aux machines qui sont au service des autres et qui pour cela sont aptes à mettre en oeuvre une ou plusieurs applications, il s'agit de machines couramment appelées serveurs. On rappelle qu'une machine désirant faire appel au services offerts par un serveur doit avant tout se connecter à ce serveur lorsque la liaison se fait par le réseau public. Dans la suite on parlera de serveur étant bien entendu qu'un serveur est une machine de type ordinateur Ou micro-ordinateur apte à mettre en oeuvre une ou plusieurs applications, le déroulement de ces applications ayant pour effet d'offrir des service à d'autres machines. Un système est dit à transparence de panne lorsque les applications utilisateur s'exécutant sur le système ignorent les mécanismes mis en oeuvre pour assurer la continuité du service en cas de défaillance. On entend par défaillance ou pannes ou faute, toute défaillance matérielle transitoire ou permanente, les défaillances logicielles transitoires, les opérations de maintenance et les défaillances dites catastrophiques (feu, inondations, ...). I1 est usuel de diviser un système informatique en quatre ensembles que l'on hiérarchise sous forme de niveaux ou de couches. Le niveau le plus bas est le niveau matériel et concerne uniquement la machine en tant que matériel "hard" selon la terminologie anglosaxonne. Le niveau du dessus correspond au système d'exploitation de la machine. Le niveau au-dessus correspond à l'application ou aux applications mises en oeuvre et le dernier niveau correspond au niveau utilisateur. I1 existe à ce jour des moyens équipant les systèmes informatiques en vue de masquer des pannes ou défaillances, notamment du matériel. Ces moyens consistent généralement à doubler le matériel, c'est-à-dire à adjoindre une deuxième machine à la machine sur laquelle s'exécutent les applications. Deux techniques sont usités pour obtenir la tolérance aux fautes, à savoir la technique dite réplication active et la technique à réplication passive. Le principe de la réplication active est le suivant chaque calcul est répliqué et exécuté sur n machines distinctes et peut ainsi supporter la défaillance simultanée de n-l machines. La réplication active prend pour hypothèse un comportement déterministe des processus. Les réplicas synchronisent leurs exécutions à chaque fois qu'un message est reçu ou envoyé à un autre processus pour assurer que tous les réplicas réalisant un même calcul reçoivent les messages provenant d'autres processus dans le même ordre. La réplication active a pour principal avantage un temps de reprise court (les calculs sont synchronisés). Par contre, cette forte synchronisation peut s'avérer pénalisante du point de vue des performances dans un environnement distribué. Dans ce cas, il est possible de relâcher la synchronisation des réplicas en ne les synchronisant pas à chaque message. On parle alors de réplication active asynchrone. Le principe de la réplication passive est de relancer les calculs à partir d'un état sauvegardé précédemment. Cet état, appelé point de reprise, doit être sauvegardé périodiquement (pour limiter la quantité de travail à réeffectuer lors de la reprise) dans une mémoire stable. On entend par point de reprise un état du système sauvegardé en vue de sa restauration éventuelle, par exemple suite à une défaillance. On entend par mémoire stable un support de stockage présentant les trois propriétés suivantes - inaltérabilité : les données stockées ne sont pas altérées par une défaillance interne à la mémoire stable, - accessibilité : il existe toujours un moyen d'accéder aux données stockées dans la mémoire stable, - atomicité des mises à jour : la mise à jour des données stockées dans la mémoire stable est soit entièrement effectuée, soit pas du tout ; y compris en présence de défaillances durant la mise à jour. La mémoire stable possède toutes les propriétés requises pour le stockage de points de reprise. Ces techniques sont mises en oeuvre par différents systèmes connus à ce jour. Chacun apporte une solution à ce problème, malheureusement quelque fois partielle, quelque fois trop coûteuse. En effet, les solutions proposées à ce jour en vue d'obtenir une transparence aux pannes pour des niveaux supérieurs ne résolvent que partiellement le problème, soit parce qu'elles n'assurent pas une transparence à tous les niveaux, soit parce qu'elles sont trop complexes donc trop onéreuses, soit qu'elles sont contraignantes dans la mise en oeuvre. Ces solutions reposent essentiellement soit sur l'utilisation de matériel spécifique, soit sur des modifications du système d'exploitation existant. I1 existe aussi des solutions reposant sur du matériel standard et sur un système d'exploitation non modifié, mais ne fiabilisant qu'une partie du système d'exploitation. Les solutions qui font intervenir un matériel spécifique font appel à la réplication des composants matériel. Le système d'exploitation nécessite une adaptation à ce matériel. On peut citer comme exemples de système tolérants aux fautes les systèmes où architectures suivants - Tandem Integrity S2 qui a fait l'objet de la publication suivante D. Jewett. Integrity S2 A Fault-Tolerant Unix Platform. Proc. of 21st International Symposium on Fault Tolerant Computing Systems, pages 512-519, Montréal, Canada, Juin 1991. Le système est monoprocesseur. Le processeur est tripliqué. Les autres sous-systèmes sont dupliqués. - L'architecture qui a fait l'objet de la publication suivante [Weber & Beirne 91] S. Weber & J. Beirne. The Stratus Architecture. Proc. of 2lst International Symposium on Fault-Tolerant Computing Systems, page 79-85, Montréal, Canada, Juin 1991. Il s'agit d'un système multiprocesseur à mémoire partagée. Chaque carte est dupliquée en interne ; une différence des sorties entraîne l'arrêt de la carte. Les cartes fonctionnent par paire ; en cas de défaillance d'une carte, l'autre carte prend le relais. - Sequoia qui a fait l'objet de la publication suivante [Bernstein 88] Ph. A Bernstein. Sequoia A Fault-Tolerant Tightly Coupled Multiprocessor for Transaction Processing. IEEE Computer, 21(2):37-45, février 1988. Il s'agit également d'un système multiprocesseur à mémoire partagée. Tous les composants matériels sont dupliqués. Les défaillances des processeurs sont tolérées par retour arrière (annulation des derniers accès mémoire effectués et reprise des calculs sur une processeur valide). Comme on l'a déjà dit, d'autres solutions reposent sur l'emploi d'un système d'exploitation spécifique ou modifié. On peut citer comme exemple les systèmes suivants - Targon/32 de Nixdorf Ce système a fait l'objet d'une publication. [Borg et al. 89] A. Borg, W Blau, W. Graetsch, F. Hermann & W. Oberle. Fault Tolerance under UNIX. ACM Transactions on Computer Systems, 7(1):1-24, 1989. Dans le cas de ce système les processus sont répliqués par paires. Un réplica actif effectue les calculs et un réplica passif reçoit périodiquement une copie de l'état du réplica actif pour permettre la reprise des calculs en cas de défaillance. Cette fonctionnalité est supportée par un système d'exploitation entièrement spécifique. - Twinix (Tolerance Computer) Twinix utilise du matériel standard (deux PC reliés par un lien de communication) et un système d'exploitation standard (Chorus/mix) . Pour assurer la tolérance aux fautes, les processus et le système d'exploitation sont maintenus en réplication active (les mêmes calculs sont effectués sur les deux machines). La synchronisation des deux machine s'effectue à chaque entrée dans le système d'exploitation. Twinix nécessite des modifications du système d'exploitation, notamment au niveau de l'ordonnanceur pour assurer la synchronisation des deux machines ainsi qu'au niveau des gestionnaires de périphériques. Les deux autres solutions indiquées dans la suite posent un problème de fiabilisation des ressources. En effet, ces deux propositions s'appuient sur du matériel standard et sur un système d'exploitations non modifié mais ne fiabilisent qu'une faible partie des ressources du système d'exploitation ou requièrent une modification des applications. - La première proposition HA/CMP (IMB) a fait l'objet d'une publication [Bhide et al. 91] A. Bhide, S. Morgan & E. Elnozahy. A Highly Available File Server. Usenix 1991 Winter Conference, 1991. HA/CMP offre principalement un système de disques partagés, un protocole de détection des défaillances et un mécanisme de reconfiguration des adresses réseau des machines par doublement des cartes réseau. Sans modification des applications, HA/CMP permet seulement le lancement automatique d'une application sur une machine valide en cas de défaillance. I1 est aussi possible de programmer des applications spécifiques à l'aide de bibliothèques offrant des fonctions de détection des défaillances et de verrouillage distribué pour régler les problèmes de partage des disques. Quel que soit le mode de fonctionnement choisi, le basculement n'est pas transparent pour les applications tournant sur le système et les connexions externes en cours sont perdues. - La deuxième proposition nDFS/REPL (AT & T) a fait l'objet d'une publication [Fowler et al. 92] G. Fowler, Y. Huan, D. Kom & H. Rao. A User-Level Replicated File System. Proc. of Usenix 1992 Summer Conference, pages 279-290, juin 1992. nDFS/REPL est un système de fichiers répliqué utilisant une paire de machines. Les deux principaux points mis en avant par les concepteurs de ce système sont la non modification du système d'exploitation hôte et la transparence vis-à-vis des applications. Les appels au système de fichiers effectués par les applications s'exécutant sur la machine principale sont interceptés au niveau de la librairie C partagée et transmis à une machine de secours pour y être réexécutés. Ainsi, la défaillance de la machine principale laisse le système de fichiers de la machine de secours dans une état correspondant à celui de la dernière écriture effectuée sur la machine primaire. Cette approche ne fiabilise pas le système d'exploitation et les applications, mais maintient uniquement la cohérence du sous-système de gestion de fichiers. On citera également les publications de Mark E. Russinovich à savoir - Fault Tolerance of Off-The-Shelf Applications and Hardware. Mark Russinovich and Zary Segall. Proceedings of the 25th International Symposium on Fault-Tolerant Computing Systems, Pasadena, June 27-30, 1995. IEEE Computer Society Press, ISBN 0-8188-7079-7, ISSN 0731-3071. - Application-Transparent Fault Management. Mark E. Russinovich. Phd Thesis, Carnegie Mellon University, August 19,1994, (URL http://www.cs.uregon.edu/-mer). Le système décrit dans ces publications évoque l'usage d'une paire de machines, mais les mécanismes qui y sont décrits sont adaptés à l'usage d'une seule machine et non d'une paire et ne permettent pas de gérer les entrées-sorties externes. En effet, même dans le cas d'une paire de machines, le système fonctionne comme s'il ne possédait que la puissance d'une machine car les processus s'exécutent complètement sur les deux machines, toute la puissance de la machine dite "de secours" étant occupée. La machine de secours ne peut pas exécuter d'application pour son propre compte et donc être à la fois machine principale et machine de secours. D'autre part, dans ce système, le systeme de synchronisation de reprise reste lourd et nécessite un grand nombre de communications entre les deux machines. La présente invention a pour objet de remédier à ces problèmes. La présente invention a plus particulièrement pour objet un système informatique à transparence de panne vis-à-vis des applications exécutées, lequel comporte au moins une machine reliée à des périphériques pour des liaisons externes cette machine étant apte à exécuter des processus intervenant dans le déroulement de ces applications, la machine étant munie de son système d'exploitation et d'au moins une mémoire de sauvegarde dite stable pour le stockage des données utiles à la reprise d'une application en cas de défaillance, caractérisé en ce que cette machine comporte une interface logique (FTX) interposée entre le système d'exploitation et les processus de l'application, cette interface étant apte à intercepter les appels système effectués par les processus sur la machine et à les enregistrer dans un journal propre à chaque processus en mémoire stable afin de permettre une réplication active de l'environnement d'exécution système des processus, et en ce que cette interface établit des points de reprise des processus et les stocke en mémoire stable afin de permettre une réplication passive à l'environnant utilisateur des processus. Selon une deuxième caractéristique de l'invention, le système comporte une première machine dite machine principale assurant l'exécution d'une ou plusieurs applications, cette machine étant munie d'une interface logique (FTX), et au moins une deuxième machine dite machine de secours pour assurer la reprise en cas de défaillance, laquelle est également munie d'une interface logique (FTX), les deux machines étant reliées par un lien de communication. Chaque machine peut être à la fois machine principale et machine de secours. Selon une autre caractéristique, l'interface de la machine principale est apte à : - sauvegarder régulièrement en mémoire stable les points de reprise des processus afin de pouvoir assurer leur réplication passive, - intercepter les appels système et sauvegarder en mémoire stable la liste ordonnée de ces appels et de leurs réponses afin de pouvoir assurer la réplication active du noyau, - transmettre toutes les entrées extérieures vers l'interface logique (FTX) de la machine de secours, l'interface de la machine de secours est apte 1) en fonctionnement normal, - à traiter les appels système et les entrées effectuées sur la machine principale et stockés en mémoire stable, - à détecter une défaillance de la machine principale, 2) en fonctionnement dégradé, c'est-à-dire e cas de défaillance de la machine principale à - ramener le système d'exploitation de la machine de secours dans un état équivalent à celui qu'occupait le système d'exploitation de la machine principale au moment de la défaillance, - relancer les processus de la machine en panne depuis le dernier point de reprise accessible dans la mémoire stable, - assurer les fonctions de l'interface (FTX) de la machine principale. Avantageusement, afin de faciliter la synchronisation tout en limitant le nombre de communications entre les machines, l'interface (FTX) enregistre les appels système dans un journal propre à chaque processus correspondant à un segment de la mémoire stable (PAL), ces journaux (PAL) permettant en fonctionnement normal de communiquer à la machine de secours l'activité système des processus de la machine principale, et durant une phase de reprise à communiquer l'ordre partiel des événements inscrit dans les journaux assurant un ordonnancement de l'exécution des processus équivalent à celui de la machine principale. L'interface de la machine principale intercepte les appels et enregistre ou non dans le journal de chaque processus ces appels et leurs paramètres, selon la nature de l'appel. Dans le cas d'un appel déterministe modifiant l'environnement d'exécution système, ces appels devant être réexécutés par la machine de secours, l'interface enregistre le nom de l'appel, les parametres de l'appel et la ou les dépendances dans le journal du processus (PAL). De préférence, l'interface n'enregistre pas, c'està-dire qu'elle va ignorer les appels déterministes consultant l'environnement d'exécution système local, car ces appels n'ont pas à être exécutés sur la machine de secours. En revanche, l'interface enregistre dans le journal du processus correspondant les appels déterministes consultant l'environnement d'exécution système global. L'enregistrement comporte dans ce cas la ou les dépendances. En outre, l'interface enregistre dans le journal du processus correspondant, les appels système non déterministes ainsi que les résultas rendus par l'appel. Selon une autre caractéristique, pour générer les dépendances, l'interface (FTX) crée pour chaque ressource système (fichier, sémaphore, socket, ...) en cours d'utilisation par les processus, une structure d'information (RIS) comprenant - l'identité de la ressource, - l'identité du dernier processus l'ayant accédé, - un verrou, - des informations nécessaires à la réintégration. Ainsi pour chaque appel intercepté, l'interface (FTX) effectue les opérations suivantes - localisation des structures d'information (RIS) correspondant aux ressources accédées par l'appel, - verrouillage des ressources au moyen du verrou contenu dans les structures (RIS), - exécution de l'appel système, - stockage dans le journal (PAL) du processus ayant fait l'appel, du nom de l'appel et éventuellement des valeurs de retour, - pour chaque structure verrouillée si le dernier processus à avoir pris le verrou n'est pas le processus courant, création d'une dépendance vers l'enregistrement correspondant au dernier appel système ayant accédé la ressource, validation des transactions associées aux journaux des deux processus, mise à jour dans la structure de l'identité de l'enregistrement correspondant au dernier appel système. - libération des verrous. Selon une autre caractéristique, la réexécution par la machine de secours des appels système effectués sur la machine principale n'est autorisée qu'après validation des journaux (PAL) par l'interface (FTX). Avantageusement, l'interface (FTX) valide les journaux suivant des critères prédéterminés. Ainsi selon une autre caractéristique, la validation des journaux a lieu dans les cas suivants - lors du dépassement d'une taille prédéfinie pour la mémoire de stockage des journaux, - après établissement d'un point de reprise par le processus concerné, - après exécution d'une opération de sortie externe par le processus concerné, - lorsqu'il y a dépendance avec un journal qui doit être validé. De préférence, l'interface (FTX) établit des points de reprise à des intervalles de temps réguliers dépendant du temps de reprise souhaité pour les applications. L'interface (FTX) établit en outre un point de reprise pour un processus lors de la réception d'un signal asynchrone par ce processus dans le cas où ce processus n'exécute pas un appel système. Selon une autre caractéristique, l'accès au système d'entrée-sortie se fait au moyen d'appels système déterminés, ces appels système sont stockés par l'interface (FTX) dans le journal (PAL) correspondant en mémoire stable, l'interface stocke en outre dans ce cas les entrées provenant des périphériques externes dans un autre journal (PIL) réservé à cet effet. Avantageusement, les appels système correspondent dans ce cas à des opérations de lecture, d'écriture vers un périphérique et, d'ouverture et de fermeture du périphérique. Selon un autre mode de réalisation, le système informatique ne comporte qu'une machine assurant à la fois l'exécution des applications et la reprise de l'exécution après une défaillance et en ce que la mémoire de sauvegarde est réalisée par les ou les disques durs de la machine. D'autres avantages et particularités de l'invention apparaîtront à la lecture de la description qui est faite et qui est donnée à titre d'exemple illustratif, et non limitatif en regard des dessins annexés sur lesquels - la figure 1, représente l'architecture matérielle d'un système informatique selon l'invention, - la figure 2, représente l'architecture matérielle nécessaire à la mise en oeuvre d'une mémoire stable, - la figure 3, représente l'architecture logicielle du système selon l'invention, - la figure 4, représente le moyen de communication entre les deux machine, - la figure 5, illustre l'algorithme de traitement des appels système selon l'invention, - la figure 6, illustre l'algorithme de traitement des dépendances pour la gestion des ressources partagées, - la figure 7, représente le schéma fonctionnel de gestion des E/S externes, - la figure 8, illustre la gestion des dépendances entre journaux PAL sur la machine de secours, - la figure 9, illustre les étapes de la phase de réintégration sur la machine à réintégrer. L'invention qui va être décrite dans la suite s'applique tout particulièrement à la gestion de l'annuaire électronique. Selon l'exemple préféré de réalisation qui est donné dans la suite, la mise en oeuvre de l'invention a été effectuée sur un système d'exploitation UNIX. Toutefois, cette mise en oeuvre peut être réalisée à partir de tout autre système d'exploitation , en particulier sur des systèmes à base de micro-noyau. D'autre part, le mode de réalisation préféré repose sur le mode de réplication à deux machines. Ce mode de réalisation n'est pas le seul envisageable dès l'instant où l'on dispose d'un site d'exécution principal, d'un site de reprise et d'un dispositif de stockage des données de reprise. On peut par conséquent disposer - d'une seule machine La machine principale et la machine de secours sont confondues et les données de reprises sont stockées sur les disques de la machine. Cependant, cette configuration n'assure ni le masquage des défaillances vis-à-vis de l'extérieur du système, ni la continuité du service. Par contre, le matériel n'est pas dupliqué. Une telle configuration peut s'avérer intéressante pour des applications de longue durée s'exécutant sur un gros calculateur ayant un temps moyen de fonctionnement entre deux défaillances du même ordre de grandeur que le temps d'exécution de l'application (machine massivement parallèle). - de n machines Ce mode de réplication est une généralisation du mode de réplication de base. Ici, la détermination du site de secours se fait pour chaque processus. Chaque machine est machine principale et machine de secours pour une partie des processus de chacune des autres machines. La figure 1, correspond à l'exemple de réalisation d'un système conforme à l'invention. Ce système comporte une machine principale 10 et une machine de secours 20. Chaque machine dispose d'une mémoire de masse 11 et 21, de liaisons externes 50 et d'une mémoire stable 40. A un instant donné chaque machine peut se trouver dans un des cinq états suivants - (P)rincipale - (S)ecours - (D)éfaillante - (R)eprise - (Ré)intégration L'état de reprise est un état temporaire, correspondant à la phase où la défaillance été détectée, mais où la machine de secours n'est pas encore en état d'assurance de service. Cette phase se doit d'être la plus courte possible afin d'assurer une bonne continuité du service. L'état de réintégration correspond à la phase où la défaillance a été traitée, mais où la machine n'est pas encore en état d'assurer la fonction de machine de secours. Globalement le système peut être dans quatre modes de fonctionnement - Normal : une machine dans l'état (P) et une dans l'état (S) - Dégradé : une machine dans l'état (P) et une dans l'état (D) - Reprise : une machine dans l'état (R) et une dans l'état (D) - Panne : deux machines dans l'état (D). La mémoire stable sert à stocker tout aussi bien des points de reprise de processus utilisateur que des journaux d'appels système comme on va le voir. Avantageusement, l'architecture matérielle proposée de mémoire stable s'appuie sur l'utilisation de deux machines avec deux mémoires centrales et une liaison entre les deux machines. Cette architecture est illustrée par la figure 2. On pourra choisir une liaison optique, ce qui autorise un écartement des deux machines supérieur au kilomètre, et ce qui assure une résistance aux défaillances catastrophiques. A un point de validation, les données stables en cours de modification sont recopiées de façon atomique sur les versions de retour arrière par l'intermédiaire du lien. une mémoire stable assure ainsi des données toujours accessibles, même en présence de la défaillance d'une machine ; elle assure également une récupération de ses données dans un état cohérent correspondant au dernier point de validation. Le lien doit être dimensionné de façon à assurer une recopie efficace entre les deux mémoires centrales. Ce débit dépend de la fréquence de validation des données stables. Le dimensionnement des deux machines est aisé dans le cas d'une configuration simple : il suffit de dimensionner à la même taille les deux mémoires. Par contre, pour une configuration croisée, il est nécessaire de dimensionner la mémoire centrale d'une machine, de manière à ce qu'elle puisse supporter une exécution efficace de ses propres applications et en même temps, concerner des points de reprise pour les applications de l'autre machine. La figure 3 illustre l'architecture logicielle du système selon l'invention. Selon l'invention, chaque machine possède une interface logique FTX placée entre le système d'exploitation et les processus de l'application. L'interface FTX de la machine principale a pour rôle - de sauvegarder régulièrement en mémoire stable les points de reprise des processus afin de pouvoir assurer leur réplication passive. - d'intercepter les appels système et de sauvegarder en mémoire stable la liste ordonnée de ces appels et de leurs réponse afin de pouvoir assurer la réplication active du noyau. - de transmettre toutes les entrées extérieures vers le FTX de la machine de secours. L'interface FTX de la machine de secours a pour rôle En fonctionnement normal - de traiter les appels système et entrées effectués sur l'autre machine et stockés en mémoire stable, de façon à maintenir le noyau en réplication active asynchrone. - de surveiller le bonne fonctionnement de la machine principale de façon à détecter toute défaillance. En fonctionnement dégradé - de ramener le système d'exploitation de la machine de secours dans une état équivalent à celui qu'occupait le système d'exploitation de la machine principale au moment de la défaillance. Le traitement à effectuer sur la machine de secours diffère suivant la nature de l'appel système comme cela sera détaillé plus loin. D'une façon générale, ce traitement consiste, en fonctionnement normal, à exécuter l'appel et à réinjecter les entrées transmises de façon à maintenir en permanence le système d'exploitation de la machine de secours dans un état antérieur à celui de la machine principale comme le veut le principe de la réplication active asynchrone. En phase de reprise, les processus relancés vont, dans un premier temps, réeffectuer les mêmes appels système que ceux effectués sur la machine principale entre leur dernier point de reprise et l'instant de la défaillance. Ces processus vont donc atteindre au bout d'un temps fini, l'état qu'ils avaient lors de la défaillance et continuer alors normalement leur exécution. De même pour le noyau, pour qui l'exécution de ces appels système a pour effet de le ramener dans un état abstrait équivalent à celui de la machine principale lors de la défaillance. Ramener le système d'exploitation de la machine de secours dans un état équivalent à celui de la machine principale, ne signifie pas installer le système de la machine de secours dans un état physiquement identique à celui de la machine principale. En interne, les deux systèmes de fichiers ne contiennent pas forcément les mêmes informations. L'interface FTX permet en outre, dans le cas de ressources partagées par des processus, d'associer aux appels système journalisés des dépendances. Ces dépendances indiquent l'ordre dans lequel les ressources du système d'exploitation sont accédées par les processus ; elles forment un ordre partiel sur les différents appels système contenu dans les journaux. Une dépendance est réalisée par un pointeur sur un enregistremen La figure 4, illustre la communication entre les interfaces FTX des deux machines. Pour réaliser la mise à disposition de l'activité du système de la machine principale au FTX de la machine de secours, l'activité de chaque processus de la machine principale est journalisée dans un segment de mémoire stable, le PAL. I1 y a un journal PAL par processus. La machine principale met à jour les PAL et valide périodiquement les transactions associées à ces segments stables. La validation des PAL est optimisée par un mécanisme de validation asynchrone de type connu. Les informations validées contenues dans les PAL sont ensuite traitées sur la machine de secours. Les journaux PAL ont deux fonctions principales - en fonctionnement normal, il permettent de communiquer à la machine de secours l'activité système des processus de la machine principale de façon à permettre, en cas de défaillance, l'installation sur la machine de secours d'un environnement d'exécution système équivalent à celui de la machine principale. - durant la phase de reprise, l'ordre partiel des événements inscrits dans l'ensemble des PAL permet de réaliser sur la machine de secours un ordonnancement de l'exécution des processus équivalent à celui observé sur la machine principale avant la défaillance. Un journal PAL contient des enregistrements correspondant aux événements suivants - appel système, - établissement d'un point de reprise, - réception d'un signal. Les enregistrements correspondant aux appels système sont journalisés dans le PAL sur la machine principale après leur exécution. I1 comprennent systématiquement l'identité et les paramètres de l'appel. I1 peuvent aussi, selon le type d'appel, contenir les résultats de l'appel. La journalisation des appels système se fait selon l'algorithme donné sur la figure 5. Lorsqu'un appel est intercepté par l'interface FTX, l'interface vérifie si l'appel système manipule une ressource partagée ou non. Si c'est le cas, l'interface gère les ressources partagées selon l'algorithme représenté à la figure 6. Si ce n'est pas le cas, l'appel système est exécuté. Suivant le type d'appel système les données à journaliser sont différentes. - Dans le cas d'appels déterministes modifiant l'environnement d'exécution système Ces appels doivent être exécutés sur la machine de secours. Un enregistrement doit donc être journalisés dans le PAL du processus ayant effectué l'appel. Cet enregistrement comporte le nom de l'appel et les paramètres de l'appel ainsi qu'une ou des dépendances. Pour les paramètres d'entrée passés par référence (par exemple le pointeur sur le tampon contenant les données à écrire dans un "write"), le contenu de la zone pointée par le paramètre est inscrit dans le PAL. - Dans le cas d'appels déterministes consultant l'environnement d'exécution système local, c'est-à-dire la partie de l'environnement d'exécution système qui n'est accessible que par ce processus. Ces appels n'ont pas à être exécutés sur la machine de secours. I1 n'est donc pas nécessaire le les journaliser dans un PAL. - Dans le cas d'appels déterministes consultant l'environnement d'exécution système global Ces appels n'ont pas à être exécutés sur la machine de secours, mais il peuvent dépendre d'autres enregistrements utilisant la même ressource. Dans ce cas, un enregistrement doit donc être journalisés comportant la ou les dépendances. Les paramètres de l'appel n'ont pas à être journalisés. - Dans les cas d'appels système indéterministes Ces appels doivent être traités au cas par cas. De façon générale, le résultat rendu par l'appel système ainsi que les modifications indéterministes des ressources système accédées doivent être ajoutées à l'enregistrement correspondant à l'appel. Des dépendances sont associées aux appels système journalisés. Ces dépendances indiquent l'ordre dans lequel les ressources système d'exploitation sont accédées par les processus ; elles forment un ordre partiel sur les différents appels système contenus dans les journaux. Ainsi, un appel système a2 est dépendant d'un appel système a1 si a2 doit être exécuté après a1 sur la machine de secours pour garantir la cohérence de l'état des noyaux sur les deux machines. Tous les appels système manipulant une ressource partagée par plusieurs processus sont susceptibles d'être dépendants. L'algorithme d'enregistrement des dépendances est résumé sur la figure 6. Pour chaque appel intercepté l'interface effectue les opérations suivantes - localisation des structures d'information RIS correspondant aux ressources accédées par l'appel, - création éventuelle d'une nouvelles structure RIS si l'appel (open, socket, semget, etc...) accède à une nouvelle ressource pour laquelle la structure RIS est inexistante, - verrouillage des ressources grâce au verrou contenu dans les structure RIS, - exécution de l'appel système, - stockage dans le journal PAL du processus ayant fait l'appel, du nom de l'appel et suivant les cas, des valeur de retour. Pour chaque structure RIS verrouillée - si le dernier processus à avoir pris le verrou n'est pas le processus courant il y a création d'une dépendance vers l'enregistrement correspondant au dernier appel système ayant accédé la ressource (l'identité de cet enregistrement est contenue dans la structure RIS). Les transactions associées aux journaux PAL de ces deux processus sont validées, - mise à jour dans la structure RIS de l'identité de l'enregistrement correspondant au dernier appel système. - libération des verrous. Au cours de son exécution un appel système peut se bloquer en attente d'une ressource (opération sur un sémaphore, lecture sur un "pipe" vide, etc...). Aussi, après le verrouillage de la structure RIS, un test est effectué pour vérifier si l'appel va être bloquant. S'il ne l'est pas, l'appel est effectué normalement. Sinon la ressource est déverrouillée et le processus se met en attente. Cette information est mémorisé dans la structure RIS correspondante avant le déverrouillage. L'interface ne met à la disposition de la machine de secours les appels système effectués sur la machine principale, pour réexécution, qu'après avoir validé les journaux. Cette validation est réalisée suivant des critères prédéterminés, à savoir - le dépassement d'une taille mémoire prédéfinie. Ce critère permet de limiter l'occupation mémoire sur la machine principale ainsi que la durée de la reprise en cas de défaillance (les appels système journalisés ne sont transmis pour exécution à la machine de secours que lors de la validation). - l'établissement d'un point de reprise par le processus concerné. Cette validation garantit que les appels système précédant l'établissement de ce point de reprise seront bien exécutés sur la machine de secours. Ainsi, il sera possible d'amener l'état du noyau de la machine de secours dans un état équivalent à celui du noyau de la machine principale lors de l'établissement de ce point de reprise. - l'exécution d'une opération de sortie externe par les processus concerne. Cette validation garantit que les appels système précédant l'opération de sortie seront réexécutés sur la machine de secours. Grâce à la propriété de déterminisme de la réexécution, l'opération de sortie est effectuée à l'identique sur la machine de secours. A ce moment, la sortie n'est pas physiquement effectuée puisqu'elle a déjà été effectuée sur la machine principale. La défaillance est ainsi masquée vis-à-vis de l'extérieur du système. - la dépendance avec un journal devant être validé. La relation de dépendance doit être préservée sur la machine de secours en cas de défaillance. Ainsi, sur l'exemple précédent, le journal contenant l'appel système a2 ne peut être validé avant que le journal contenant l'appel système a1 n'ait été validé. Dans le cas de dépendances croisées (chaque journal doit être validé avant l'autre), il est nécessaire de procéder à une validation atomique (tout ou rien) des journaux concernés. On va maintenant se reporter au schéma de la figure 7 qui illustre la gestion des entrées sorties E/S par l'interface. En fonctionnement normal, un système d'E/S externe est connecté à la machine principale et une application au dessus du système d'exploitation accède à ce système via des appels système tels que par exemple "open, read, write, close". Le principe général de la solution en fonctionnement normal est le suivant. Sur la machine principale, le FTX stocke dans le PAL en mémoire stable tous les appels open(), read(), write(), close() effectués par les processus (comme il le fait déjà dans la solution générale) . I1 gère en plus un nouveau journal en mémoire stable, le journal PIL où sont stockées les entrées provenant des périphériques externes. Le journal PIL peut être placé à divers niveaux dans le système. Au niveau le plus haut, les données stockées dans le journal PIL sont les données récupérées par les appels système read() sur la machine principale. A un niveau intermédiaire, les données stockées dans le journal PIL peuvent être par exemple des données récupérées par les appels read() au driver du système d'entrée-sortie E/S externe. Au niveau le plus bas, les données arrivant sur la ligne physique connectée à la machine principale sont également injectées sur la ligne physique connectée à la machine de secours. Dans ce cas, le journal PIL n'a pas besoin d'être mis en oeuvre en mémoire stable : un simple routage de la sortie du périphérique vers les entrées externes des deux machines est suffisant. En pratique, le choix du meilleur niveau d'intégration du journal PIL se fait suivant le périphérique externe géré. Cette gestion permet d'assurer une transparence des défaillances vis-à-vis de l'extérieur du système. Cela est obtenu grâce à - une validation du journal du processus effectuant une sortie externe et transmission des entrées externes sur la machine de secours, - un reroutage des communications vers la machine de secours en cas de défaillance, - la perte d'une entrée ou la duplication (ou la perte) d'une sortie étant toujours possible, une défaillance de la machine principale est assimilée à une défaillance temporaire de la ligne de communication. Pour les protocoles de communication supportant la perte et la duplication de messages, la transparence est garantie. Sur la machine de secours, les opérations d'ouverture et de fermeture du périphérique [open() et close()] sont rejouées. les opérations d'écriture ne doivent pas provoquer de sortie vers le périphérique externe puisque les sorties ont déjà été faites par la machine principale. De la même façon que pour le journal PIL, les sorties vers un périphérique externe peuvent être coupées à divers niveaux dans le système. Au niveau le plus haut, les opérations d'écriture [write()] figurant dans le PAL ne sont pas rejouées sur la machine de secours. Au niveau le plus bas, la sortie physique de la machine de secours n'est pas connectée. Les opération de lecture [read()] figurant dans le PAL sont rejouées sur la machine de secours à partir de ce qui a été stocké dans le journal PIL. Par conséquent, la machine principale n'a pas besoin de stocker dans le PAL les données rendues par les opérations read(). Du point de vue des validations, le PAL doit être validé à chaque écriture [write()] vers un périphérique externe. La validation du PAL provoque son transfert vers la machine de secours. Le PAL sur la machine de secours assure en cas de défaillance que les processus relancés rejouent de manière déterministe (dans le même ordre) les appels système réalisés sur la machine principale. Par conséquent, valider le PAL à chaque écriture vers un périphérique externe assure en cas de défaillance que les processus effectuant les sorties reproduiront exactement la même séquence d'écriture vers le périphérique externe. Cette propriété est importante car les sorties vers les périphériques externes ne sont pas récupérables et ne doivent pas être remises en cause en cas de défaillance par une reprise indéterministe de processus qui les effectuent. On notera que la propriété de réexécution déterministe est obtenue par une validation du PAL sans qu'il soit nécessaire de prendre de point de reprise des processus à chaque appel write() vers un dispositif externe. Toujours du point de vue des validations, à chaque fois qu'une donnée provenant d'un périphérique externe est reçue par la machine principale, elle est stockée dans le journal PIL et le PIL est validé. I1 est nécessaire de valider le journal PIL et de transférer au plus tôt les données reçues vers la machine de secours. On a vue que les appels système contenus dans les journaux des différents processus sont réexécutés sur la machine de secours après validation des journaux. Deux contraintes de synchronisation sont alors à respecter pour la réexécution - La réexécution doit respecter l'ordre partiel entre le appels système des différents processus défini sur la machine principale. - Un appel système ne peut pas être réexécuté si il a été effectué sur la machine principale après le dernier point de reprise du processus correspondant. En effet, ce point de reprise sera restauré en cas de défaillance. A cet instant, le système d'exploitation de la machine de secours devra donc se trouver dans l'état où se trouvait celui de la machine principale au moment de l'établissement du point de reprise. La réexécution des appels système journalisés est effectuée par ces processus fantômes correspondant aux processus de la machine principale. Ces processus fantômes n'ont pas d'autre fonction que de permettre l'exécution des appels système sur la machine de secours. Cette réexécution a lieu en différé puisqu'un appel système n'est visible sur la machine de secours qu'après validation du PAL le contenant. Les noyaux des machines sont donc bien en réplication active asynchrone. Chacun des processus fantôme a accès à la partie validée du PAL du processus auquel il correspond et exécute les appels système contenus dans ce PAL sous le contrôle de l'interface FTX. Le processus fantôme traite en fonction de la nature de l'enregistrement - Pour un appel système sans dépendance Le processus fantôme exécute l'appel, puis efface l'enregistrement du PAL. Un pointer RP est alors avancé dans le PAL ce qui peut provoquer la libération d'un processus préalable bloqué en attente de l'exécution de cet appel. Le processus fantôme utilise les paramètres stockés dans l'enregistrement pour effectuer l'appel. I1 ne tient pas compte des résultats de l'appel puisque le processus fantôme n'effectue aucun calcul propre et a pour seul rôle de modifier l'état abstrait du noyau. - Pour un appel système contenant une dépendance Le processus fantôme est bloqué jusqu'à ce que le pointeur RP du processus désigné par la dépendance soit supérieur au numéro d'enregistrement contenu dans cette dépendance. Lorsque c'est le cas, l'enregistrement est traité de la même façon que ci-dessus. - Pour un marqueur de point de reprise Les processus fantôme est bloqué en attendant l'établissement d'un nouveau point de reprise par le processus correspondant sur la machine principale. Lorsque cet événement se produit, le pointer RP est avancé dans le PAL et l'exécution normale des appels système peut recommencer. La figure 8, illustre un exemple de gestion des dépendances entre journaux PAL sur la machine de secours - le processus P3 est bloqué en attente d'établissement d'un prochain point de reprise, car son pointer RP a atteint un marqueur de point de reprise, - le processus P2 est bloqué car l'enregistrement pointé par son pointeur RP dépend du traitement d'un enregistrement non encore exécuté par P3 (et qui ne pourra l'être qu'au prochain établissement d'un point de reprise), - le processus P1 peut traiter trois enregistrements, jusqu'au prochain marqueur de point de reprise. En effet, ces enregistrements ne comportent pas de dépendance ou dépendent d'enregistrement déjà traités. On va maintenant décrire la phase de reprise après défaillance. La phase de reprise a pour but la restauration de l'environnement d'exécution système et la restauration des environnements utilisateur. Dans un premier temps, les appels système stockés dans les PAL sont traités comme en fonctionnement normal : les processus fantômes exécutent les appels non traités en mettant à jour leur pointeur RP au fur et à mesure et en tenant compte des dépendances. De cette façon, au bout d'un temps fini, les processus fantômes non bloqués par une dépendance vont voir leur RP pointer sur le marqueur de leur plus récent point de reprise contenu dans leur PAL. Pour ces processus, l'environnement système se trouve alors dans un état équivalent à celui qu'il avait sur la machine principale lors de l'établissement de ce point de reprise. Quand un processus est bloqué sur ce marqueur, la restauration de son environnement utilisateur peut alors s'effectuer. Pour ce faire, le FTX installe le point de reprise dans le processus fantôme correspondant. Ce dernier se retrouve donc dans l'état où était le processus de la machine principale au moment de l'établissement de point de reprise. I1 cesse ainsi d'être un processus fantôme et se comporte désormais comme une processus "normal", doté de ses propres données et exécutant sont propre code. Au fur et à mesure de la progression des pointeurs RP due aux exécutions des appels système, l'ensemble des processus fantômes est ainsi progressivement remplacé par un ensemble de processus "restaurés" dans des états qu'ont eu les processus de la machine principale. Du fait de leur déterminisme, ces processus "restaurés" vont dans un premier temps effectuer les mêmes appels que dans le passé sur la machine principale, tel qu'ils ont été enregistrés dans leur PAL. Le FTX ordonne alors tous les appels provenant de ces processus suivant l'ordre de leur PAL. Pour ce faire, il intercepte les appels de la même manière qu'un FTX de machine principale, autorise l'exécution de ces appels en fonction des dépendances et gère leurs RP en conséquence. Ce faisant, d'autres processus fantômes peuvent ainsi être débloqués par le jeu des dépendances et devenir à leur tour des processus "restaurés" lorsque leur pointeur RP aura atteint le marqueur de leur plus récent point de reprise. Lorsque le RP d'un processus atteint la fin de son PAL, le processus se bloque. En effet, si ce processus continuait son exécution, il serait susceptible d'exécuter des appels système interférant avec des appels journalisés dans les PAL d'autres processus. Le seul moyen de conserver un ordonnancement correct des appels système est de bloquer le processus jusqu'à ce qu'il n'y ait plus d'appels système à ordonner. Quand tous les processus ont épuisé leur PAL, le FTX les débloque pour qu'il continue leur exécution la phase de reprise est terminée. Le noyau ainsi que l'ensemble des processus se trouvent alors dans le même état que sur la machine principale. On va maintenant décrire la réintégration. On rappelle que le mode de fonctionnement de réintégration est le mode transitoire survenant après le traitement de la défaillance d'une machine ou lors de l'initialisation du système dans son ensemble. La réparation de la machine défaillante peut se réduire à une simple réinitialisation (reboot) dans le cas d'une défaillance transitoire ou bien nécessiter le changement d'un composant défaillant dans le cas d'une défaillance matérielle permanente. On appellera machine principale la machine assurant seule le fonctionnement dégradé, et machine à réintégrer la machine ayant subi la défaillance et dont la panne a été réparée. Le but de la réintégration est de mettre la machine à réintégrer dans un état tel qu'elle soit capable d'assurer pleinement le rôle de machine de secours. Pour ce faire, la machine à réintégrer doit posséder - des disques dans un état équivalent à ceux de la machine principale, - un noyau dans un état équivalent à celui dans lequel était le noyau de la machine principale, - l'accès aux PAL, - les points de reprise de tous les processus s'exécutant sur la machine principale. Aussi, distingue-t-on trois étapes successives dans ce mode de fonctionnement 1. réintégration des disques, 2. réintégration de l'état du noyau, 3. phase transitoire de récupération des points de reprise. Les étapes de la phase de réintégration sur la machine à réintégrer sont illustrées par le schéma le la figure 9. En ce qui concerne les PAL, on ne stockera pas lors d'une défaillance sur la machine principale, l'ensemble des PAL durant toute la durée de la phase de traitement de la défaillance pour des raisons évidentes de place occupée. En fonctionnement dégradé, le stockage dans les PAL des différentes activités des processus est donc arrêté. Dès que la réintégration de l'état système est terminée, le FTX de la machine principale peut recommencer à journaliser l'activité du système dans les PAL et valider ce dernier de façon à ce qu'il soit disponible sur la machine à réintégrer. L'accès aux points de reprise ne pose pas non plus de problème majeur. On établit un point de reprise pour chaque processus de la machine principale comme en fonctionnement normal. I1 n'est nul besoin d'établir l'ensemble de ces points de reprise atomiquement puisque les appels système effectués par un processus après son point de reprise sont stockés dans son PAL. REVENDICATIONS 1. Système informatique à transparence de panne vis-à-vis des applications exécutées, lequel comporte au moins une machine reliée à des périphériques par une liaison externe, cette machine étant apte à exécuter des processus intervenant dans le déroulement de ces applications, la machine étant munie de son système d'exploitation et d'au moins une mémoire de sauvegarde dite stable pour le stockage des données utiles à la reprise d'une application en cas de défaillance, caractérisé en ce que cette machine comporte une interface logique (FTX) interposée entre le système d'exploitation et les processus de l'application, cette interface étant apte à intercepter les appels système effectués par la machine et à les enregistrer en mémoire stable afin de permettre une réplication active de l'environnement d'exécution système des processus, et en ce que cette interface établit des points de reprise des processus et les stocke en mémoire stable afin de permettre une réplication passive de l'environnement utilisateur des processus, cette interface (FTX) gérant également les entrées sorties (E/S) externes de la machine. 2. Système informatique selon la revendication 1, caractérisé en ce que le système comporte une première machine dite machine principale assurant l'exécution d'une ou plusieurs applications, cette machine étant munie d'une interface logique (FTX), et au moins une deuxième machine dite machine de secours pour assurer la reprise en cas de défaillance, laquelle est également munie d'une interface logique (FTX), les deux machines étant reliées par un lien de communication. 3. Système informatique selon la revendication 2, caractérisé en ce que chaque machine est à la fois machine principale et machine de secours. 4. Système informatique selon l'une quelconque des revendications précédentes, caractérisé en ce que l'interface de la machine principale est apte à - sauvegarder régulièrement en mémoire stable les points de reprise des processus afin de pouvoir assurer leur réplication passive, - intercepter les appels système et sauvegarder en mémoire stable la liste ordonnée de ces appels et de leurs réponses afin de pouvoir assurer la réplication active du noyau, - transmettre toutes les entrées extérieures vers l'interface logique (FTX) de la machine de secours, l'interface de la machine de secours est apte 1) en fonctionnement normal, - à traiter les appels système et les entrées effectuées sur la machine principale et stockés en mémoire stable, - à détecter une défaillance de la machine principale, 2) en fonctionnement dégradé, c'est-à-dire en cas de défaillance de la machine principale à - ramener le système d'exploitation de la machine de secours dans un état équivalent à celui qu'occupait le système d'exploitation de la machine principale au moment de la défaillance, - relancer les processus de la machine en panne depuis le dernier point de reprise accessible dans la mémoire stable, - assurer les fonctions de l'interface (FTX) de la machine principale. 5. Système informatique selon l'une quelconque des revendications précédentes, caractérisé en ce que l'interface (FTX) enregistre les appels système dans un journal propre à chaque processus correspondant à un segment de la mémoire stable (PAL), ces journaux (PAL) permettant en fonctionnement normal de communiquer à la machine de secours l'activité système des processus de la machine principale, et durant une phase de reprise à communiquer l'ordre partiel des événements inscrit dans les journaux assurant un ordonnancement de l'exécution des processus équivalent à celui de la machine principale. 6. Système informatique selon l'une quelconque des revendications précédentes, caractérisé en ce que l'interface de la machine principale intercepte les appels et enregistre ou non dans le journal de chaque processus ces appels et leurs paramètres selon la nature de l'appel. 7. Système informatique selon la revendication 5, caractérisé en ce que dans le cas d'un appel déterministe modifiant l'environnement d'exécution système, ces appels devant être réexécutés par la machine de secours, l'interface enregistre le nom de l'appel, les paramètres de l'appel et la ou les dépendances dans le journal du processus (PAL). 8. Système informatique selon la revendication 5, caractérisé en ce que l'interface n'enregistre pas, c'est-à-dire qu'elle ignore les appels déterministes consultant l'environnement d'exécution système local, ces appels n'ayant pas à être exécutés sur la machine de secours. 9. Système informatique selon la revendication 5, caractérisé en ce que l'interface enregistre dans le journal du processus correspondant les appels déterministes consultant ltenvironnement d' exécution système global, l'enregistrement comportant dans ce cas la ou les dépendances. 10. Système informatique selon la revendication 5, caractérisé en ce que l'interface enregistre dans le journal du processus correspondant, les appels système non déterministes ainsi que les résultas rendus par l'appel. 11. Système informatique selon la revendication 5, caractérisé en ce que pour générer les dépendances, l'interface (FTX) crée pour chaque ressource système (fichier, sémaphore, socket, ...) en cours d'utilisation par les processus, une structure d'information (RIS) comprenant - l'identité de la ressource, - l'identité du dernier processus l'ayant accédé, - un verrou, - des informations nécessaires à la réintégration. 12. Système informatique selon l'une quelconque des revendications précédentes, caractérisé en ce que pour chaque appel intercepté l'interface (FTX) effectue les opérations suivantes - localisation des structures d'information (RIS) correspondant aux ressources accédées par l'appel, - verrouillage des ressources au moyen du verrou contenu dans les structures (RIS), - exécution de l'appel système, - stockage dans le journal (PAL) du processus ayant fait l'appel, du nom de l'appel et éventuellement des valeurs de retour, - pour chaque structure verrouillée si le dernier processus à avoir pris le verrou n'est pas le processus courant, création d'une dépendance vers l'enregistrement correspondant au dernier appel système ayant accédé la ressource, validation des transactions associées aux journaux des deux processus, mise à jour dans la structure de l'identité de l'enregistrement correspondant au dernier appel système. - libération des verrous. 13. Système informatique selon l'une quelconque des revendications précédentes, caractérisé en ce que la réexécution par la machine de secours des appels système effectués , la machine principale n'est autorisée qu'après validation des journaux (PAL) par l'interface (FTX). 14. Système informatique selon la revendication 12, caractérisé en ce que l'interface (FTX) valide les journaux suivant des critères prédéterminés. 15. Système informatique selon la revendication 13, caractérisé en ce que la validation des journaux a lieu dans les cas suivants - lors du dépassement d'une taille prédéfinie pour la mémoire de stockage des journaux, - après établissement d'un point de reprise par le processus concerné, - après exécution d'une opération de sortie externe par le processus concerné, - lorsqu'il y a dépendance avec un journal qui doit être validé. 16. Système informatique selon l'une quelconque des revendications précédentes, caractérise en ce que l'interface (FTX) établit des points de reprise à des intervalles de temps réguliers dépendant du temps de reprise souhaité pour les applications 17. Système informatique selon l'une quelconque des revendications précédentes, caractérisé en ce que l'interface (FTX) établit en outre un point de reprise pour un processus lors de la réception d'un signal asynchrone par ce processus dans le cas où ce processus n'exécute pas un appel système. 18. Système informatique selon l'une quelconque des revendications précédentes, caractérisé en ce que l'accès au système d'entrée-sortie se fait au moyen d'appels système déterminés, et en ce que ces appels système sont stockés par l'interface (FTX) dans le journal (PAL) correspondant en mémoire stable, l'interface stocke en outre dans ce cas les entrées provenant des périphériques externes dans un autre journal (PIL) réservé à cet effet. 19. Système informatique selon la revendication 18, caractérisé en ce que les appels système correspondent à des opérations de lecture, d'écriture vers un périphérique et, d'ouverture et de fermeture du périphérique. 20. Système informatique selon la revendication 1, caractérisé en ce qu'il ne comporte qu'une machine assurant à la fois l'exécution des applications et la reprise de l'exécution après une défaillance et en ce que la mémoire de sauvegarde est réalisée par les ou les disques durs de la machine. 21. Système informatique selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il met en oeuvre l'application gestion de l'annuaire téléphonique numérique.