Les systèmes à tolérance de pannes

Introduction

Les progrès remarquables des équipements informatiques et de télécommunications durant ces dernières années ont permis une forte évolution des environnements répartis et parallèles qui les utilisent. On est ainsi passé de réseaux locaux de stations de travail à des réseaux à grande échelle de machines. Cette avancée des équipements a permis l’apparition de nouvelles architectures parallèles de grande taille comme les grappes, les grilles et les systèmes pair à pair. Ces architectures sont conçues pour répondre plus efficacement aux besoins des différents domaines. La tolérance aux pannes dans ces systèmes est un domaine qui à été largement étudié. Il existe un grand nombre de protocoles de tolérance aux pannes, que l’on peut diviser en deux grande familles : Les protocoles par points de reprise et les protocoles par journalisation. Chacune de ces catégories présente des propriétés différentes en terme de performance, et n’est parfois pas applicable selon l’application considérée ou selon le système.

1.La Sûreté de fonctionnement

La sûreté de fonctionnement peut être définit comme la capacité de fournir un service dans lequel un utilisateur peut raisonnablement placer sa confiance. De façon plus quantitative, la sûreté de fonctionnement permet de décider si un système est capable d’assurer que la fréquence de défaillance du service et la gravité de ces défaillances restent inférieurs à un minimum considéré comme acceptable.
La tolérance aux pannes proprement dite n’est en réalité qu’une partie du concept de sûreté de fonctionnement, plus précisément un moyen de la sûreté de fonctionnement.
La sûreté de fonctionnement peut être dé-composé trois points de vue présentés dans les sous-sections suivantes : les entraves à la sûreté de fonctionnement, les attributs de la sûreté de fonctionnement et les moyens permettant de l’assurer.

Les Entraves à la sûreté de fonctionnement

Les fautes, les erreurs et les défaillances sont les causes et les conséquences de la non-sûreté de fonctionnement

Une défaillance du système survient lorsque le service délivré diffère du service spécifié. La défaillance survient parce que le système a un comportement erroné : une erreur est la partie de l’état du système qui est susceptible d’entraîner une défaillance. La cause adjugée ou supposée de l’erreur est une faute. Une erreur est donc la manifestation d’une faute dans le système, et une défaillance est l’effet d’une erreur sur le service. Ceci conduit à la chaîne fondamentale :

– La faute ou panne est caractérisée par sa nature, son origine et son étendue temporelle. La nature d’une faute précise la manière dont elle a été provoquée : intentionnellement ou accidentellement. La cause de l’apparition d’une faute est révélée par son origine. L’étendue temporelle caractérise la persistance ou la durée d’une faute.
– Une erreur est la conséquence d’une faute. Une défaillance survient dès que le système utilise un état erroné. Premièrement, le service ne correspond pas en valeur à celui spécifié. Deuxièmement, le service n’est pas délivré dans l’intervalle de temps spécifié. Le service rendu est toujours en avance ou toujours en retard. Le fait que le système omette de rendre le service est considéré également comme un type d’erreur. Un arrêt (crash) est défini par le fait que le système omet définitivement de délivrer des services.
– Une défaillance dénote l’incapacité d’un élément du système à assurer le service spécifié par l’utilisateur. La défaillance est caractérisée par son domaine, sa perception par les utilisateurs et ses conséquences sur l’environnement.

Les Attributs de la sûreté de fonctionnement

Les attributs de la sûreté de fonctionnement d’un système mettent plus ou moins l’accent sur les propriétés que doivent vérifier la sûreté de fonctionnement du système. Ces attributs permettent d’évaluer la qualité du service fourni par un système. Six attributs de la sûreté de fonctionnement sont définis :

– disponibilité : c’est la propriété requise par la plupart des systèmes sûrs de fonctionnement. Il s’agit de la fraction de temps durant laquelle le système est disponible pour des fins utiles ;
– fiabilité : cet attribut évalue la continuité du service i.e. le taux en temps de fonctionnement pendant lequel le système ne subit aucune faute ;
sécurité-innocuité : l’absence de conséquences catastrophiques sur l’utilisateur ou son environnement ;
– confidentialité : cet attribut évalue la capacité du système à fonctionner en dépit de fautes intentionnelles et d’intrusions illégales ;
intégrité : l’intégrité d’un système définit son aptitude à assurer des altérations approuvées des données ;
– maintenabilité : cette propriété décrit la souplesse du système vis-à-vis des modifications apportées en vue de sa maintenance.

L’importance des attributs de la sûreté de fonctionnement présentés ci-dessus est principalement liée aux applications et à leurs besoins.

Moyens d’assurer la sûreté de fonctionnement

Les moyens utilisés pour assurer la sûreté de fonctionnement sont définis par les méthodes et les approches utilisées pour assurer cette propriété. Les approches les plus connues sont :
– la prévention des fautes qui s’attache aux moyens permettant d’éviter l’occurrence de fautes dans le système. Ce sont généralement les approches de vérification des modèles conceptuels ;
– L’élimination des fautes qui se focalise sur les techniques permettant de réduire la présence de fautes ou leurs impacts. Cela est réalisé par des méthodes statiques de preuve de la validité du système (simulation, tests, ...) ;
– la prévision des fautes qui prédit l’occurrence des fautes (temps, nombre, impact) et leurs conséquences. Ceci est réalisé généralement par des méthodes d’injection de fautes afin de valider le système relativement à ces fautes ;
– La tolérance aux pannes ou aux fautes qui essaye de fonctionner en dépit des fautes. Le degré de tolérance aux pannes se mesure par la capacité du système à continuer à délivrer son service en présence de fautes.

Les types de pannes

Les pannes qui peuvent survenir durant une exécution peuvent être classées en quatre catégories :
– les pannes franches (crash, fail-stop), que l’on appelle aussi arrêt sur défaillance. C’est le cas le plus simple : on considère qu’un processus peut être dans deux états, soit il fonctionne et donne le résultat correct, soit il ne fait plus rien. Dans le second cas, le processus est considéré comme défaillant.
– les pannes par omission (transient, omission failures). Dans ce cas, on considère que le système peut perdre des messages. Ce modèle peut servir à représenter des défaillances du réseau plutôt que des processus.
– Les pannes de temporisation (timing, performance failures). Ce sont les comportements anormaux par rapport à un temps, comme par exemple l’expiration d’un délai de garde.
Les pannes arbitraires, ou byzantines (malicious, byzantine failures). Cette classe représente toutes les autres pannes : le processus peut alors faire « n’importe quoi », y compris avoir un comportement malveillant.

Le cas le plus simple est bien sûr le cas des pannes franches, et on essaie toujours de s’y ramener, par exemple en tuant un processus en cas de comportement imprévu. La plupart des protocoles de tolérance aux pannes pour les systèmes répartis ne considèrent que ce type de pannes.

Tolérance aux pannes dans les systèmes répartis

De manière générale, un système réparti peut être défini comme un ensemble de nœuds de calcul reliés par un réseau de communication et communiquant entre eux par messages.
Dans ce contexte, la tolérance aux pannes est un besoin imposé par la répartition et c’est pourquoi plusieurs travaux de recherches sur les systèmes répartis ont été réalisés afin de la prendre en compte.

Techniques de tolérance aux pannes

La tolérance aux pannes dans les systèmes répartis et parallèles est toujours réalisée par l’emploi d’un mécanisme de redondance. Cette dernière peut être par duplication de composants, par traitements multiples ou bien par redondance de données, codes, signatures. Dans un tel système à base de processus communicants, les techniques de tolérance aux pannes peuvent être séparées en deux classes : les techniques basées sur la réplication et les techniques basées sur le recouvrement arrière.

La tolérance aux pannes par réplication

La tolérance aux pannes par réplication se base sur la redondance des processus composants l’application. Cette approche permet de masquer les pannes éventuelles : lorsqu’un processus tombe en panne, une des copies de ce processus prend sa place dans le système. On distingue trois approches différentes pour réaliser la redondance des processus, selon que les copies s’exécutent systématiquement en parallèle ou que l’exécution des copies soit démarrée en cas de panne. Plus précisément, on distingue :
– la réplication active : toutes les copies de processus s’exécutent en même temps. En particulier, tous les messages à destination d’un processus sont envoyés à toutes les copies. Les différentes copies gardent donc un état étroitement synchronisé durant l’exécution. Ce type de réplication permet de gérer tout type de faute, en particulier les pannes byzantines. Notons que la réplication active impose que tous les processus soient totalement déterministes ; on suppose que les exécutions des différentes copies ne peuvent pas diverger.
– la réplication passive : une seule des copies, la copie primaire, s’exécute à la fois. En cas de panne, une copie secondaire est démarrée et doit rattraper l’exécution jusqu’à l’état de la copie primaire avant la panne. L’état des copies secondaires doit donc être régulièrement mis à jour par la copie primaire. Cette technique est en fait similaire aux approches par recouvrement arrière.
– la réplication semi-active : toutes les copies s’exécutent en même temps, mais une seule d’entre elle, la copie maîtresse, émet les messages résultants de l’exécution. Ainsi, les autres copies mettent à jour leur état interne et sont donc étroitement synchronisées avec la copie maîtresse. L’intérêt de cette approche est de pouvoir prendre en compte les processus non déterministes : seule la copie maîtresse est responsable des choix non déterministes, et en informe les autres copies par des messages spécifiques.

L’approche par réplication active est souvent utilisée dans un contexte où le temps d’exécution est primordial. En effet, les pannes sont très rapidement masquées et n’influent que très peu sur le temps d’exécution total. Cependant, cette approche implique la disponibilité d’un nombre important de ressources. L’approche par réplication semi-active présente les mêmes propriétés, avec la capacité de gérer les processus non déterministes.

La tolérance aux pannes par recouvrement arrière

Le but d’un protocole de tolérance aux pannes par recouvrement arrière est de capturer suffisamment de données pendant une exécution distribuée sans panne, et de stocker ces données en mémoire stable. Les données collectées doivent pouvoir être utilisées pour redémarrer tout ou partie de l’application si une panne est détectée ; ces données doivent former un état recouvrable.
On peut donc distinguer trois éléments clés dans la tolérance aux pannes par recouvrement arrière :
– l’accès à une mémoire stable,
– la capacité de capturer l’état des processus,
– la caractérisation et la création d’états recouvrables.

Dans un premier temps nous allons voir ces trois notions, puis nous allons voir quelques technique de tolérance aux pannes par recouvrement arrière.

Mémoire stable

L’existence d’une mémoire stable permet la réalisation de la tolérance aux pannes par une détection de défaillance suivie d’un recouvrement d’erreur.

La mémoire stable peut être définie comme un support persistant de stockage, dont le rôle principal est d’assurer une accessibilité et une protection aux données contre les pannes pouvant affecter le système. Ainsi, suite à une panne, un état correct ayant été stocké antérieurement à cette panne sur la mémoire stable reste accessible ; cela permet au système un retour à un état antérieur. Un support de stockage est vu comme une mémoire stable si et seulement si les trois conditions suivantes sont vraies :

1. Accessibilité : il existe à tout moment de l’exécution un chemin permettant d’accéder aux données sauvegardées même en présence des pannes.
2. Protection : les pannes affectant le système ou l’application n’altèrent pas les données.
3. Atomicité : les mises à jour des données sur le support de stockage se font de manière atomique.
   Souvent, il y a une confusion entre la mémoire stable et le composant matériel qui l’implante. La mémoire stable doit garantir la persistance et l’accessibilité des données nécessaires à une reprise après panne. Ceci peut conduire à différentes mises en œuvre d’une mémoire stable :
   – Dans les approches où le mécanisme de tolérance aux pannes ne tolère qu’une seule panne, la mémoire stable d’un processus peut correspondre à la mémoire volatile ou au disque d’un autre processus ;
   – Si l’objectif de la tolérance aux pannes est de tolérer un nombre arbitraire de pannes transitoires, le disque dur local de chaque processus peut être utilisé pour implanter sa mémoire stable ;
   – Pour un système qui tolère les pannes permanentes (non transitoires), la mémoire stable est un support de stockage persistant situé en dehors des nœuds exécutant les processus de calcul ; celle-ci reste accessible à tout moment.

Principe de la tolérance aux pannes par mémoire stable

Le principe de cette technique est de remplacer l’état d’erreur par un état correct en se basant sur l’abstraction d’une mémoire stable présentée dans le paragraphe ci-dessus. Ceci nécessite tout d’abord la détection de l’erreur, c’est à dire, identifier la partie incorrecte de l’état, afin de pouvoir ensuite effectuer le recouvrement d’erreur.
La détection de défaillances se fait généralement au moyen d’un test de vraisemblance. Ce dernier peut être explicite en vérifiant des propriétés spécifiques de l’état, ou implicite via des conséquences visibles comme par exemple la violation d’un délai de garde.
Les objectifs de la détection d’erreur sont de prévenir, si possible, l’occurrence d’une défaillance provoquée par l’erreur, d’éviter la propagation de l’erreur à d’autres composants et de faciliter l’identification ultérieure de la faute en vue de son élimination ou de sa prévention.
Une fois qu’une panne est détectée, un mécanisme de recouvrement doit être mis en place pour traiter la panne identifiée. Il existe deux techniques de recouvrement :
– la reprise : c’est la technique générale qui consiste à retourner vers un état antérieur dont on sait qu’il est correct. Cette technique nécessite donc la sauvegarde régulière de l’état du système ou de l’application.
– la poursuite : c’est une technique spécifique qui consiste à reconstituer un état correct, sans retour en arrière. La reconstitution n’est souvent que partielle, d’où un service dégradé.

Comme nous l’avons déjà remarqué, pour pouvoir réaliser une reprise après une panne, l’état du système ou de l’application doit être sauvegardé périodiquement ou lors de l’occurrence d’événements spécifiques. L’état sauvegardé doit constituer un point de reprise à partir duquel le système peut fonctionner correctement. Pour assurer cette propriété, le mécanisme de tolérance aux pannes doit résoudre les problèmes de reprise suivants :
– La sauvegarde et la restauration d’un point de reprise doivent être atomiques.
– L’état des points de reprise doit lui-même être protégé contre les fautes ;
– Dans un système réparti, les points de reprise sont créés pour chaque processus. L’ensemble de ces points de reprise doit constituer un état global cohérent du système.

La construction d’un état global cohérent d’un système répartis peut être vue suivant deux approche :
– A priori : les sauvegardes des différents états des processus coopérants sont coordonnées pour constituer un état global cohérent ;
– A posteriori : les sauvegardes des états des processus sont indépendantes ; la reconstitution d’un état global cohérent se fait lors de la reprise.

Il est à noter que la sauvegarde d’une données sur une mémoire stable peut être implantée par des techniques de codage pour limiter la redondance. Parmi les systèmes utilisant cette technique, on peut citer les systèmes RAID (Redundant Array of Independent Disks), les serveurs de stockage paire à paire. Cette technique a été proposée pour les systèmes de calcul parallèle.

Capture de l’état d’un processus

La tolérance aux pannes par recouvrement arrière suppose aussi qu’un processus peut capturer une image de son état, ou point de reprise (checkpoint), au cours de son exécution ; cette image peut éventuellement être stockée sur la mémoire stable. Elle doit pouvoir être utilisée directement pour redémarrer le processus ; l’image produite doit donc contenir tout le contexte du processus comme les registres courants, les segments de données ou la pile d’exécution. La persistance des processus peuvent être séparer en deux catégories :
– les méthodes offrant une persistance forte, c’est-à-dire que la capture d’état peut être déclenchée à n’importe quel moment de l’exécution par un autre processus indépendant,
– Les méthodes offrant une persistance faible, c’est-à-dire que la capture d’état ne peut être réalisée que lorsque l’exécution atteint un point particulier, ou point de capture potentielle.

De plus, nous les comparons selon les critères suivants :
– l’impact sur les performances : le surcoût global sur le temps d’exécution induit par le mécanisme de persistance ;
– l’efficacité du mécanisme : le surcoût sur le temps d’exécution induit par la capture d’une image ;
– la portabilité du mécanisme : si le mécanisme de persistance peut être utilisé sur différentes architectures ;
– la portabilité des images : si les images produites peuvent être utilisées pour redémarrer les processus sur des architectures différentes de celle dans laquelle la capture a été faite ;
– la transparence : si le mécanisme de persistance fait intervenir l’utilisateur.

Deux techniques permettent de réduire le surcoût induit par la capture d’une image. La première consiste à créer les images de manière incrémentale : lors de la capture, seules les parties de l’état qui ont été modifiées depuis la capture précédente sont stockées. Cette technique permet en particulier de réduire la taille des images produites. Elle nécessite de pouvoir tracer les modifications des zones mémoire utilisées par le processus, et requiert donc des accès de bas niveau.
La seconde technique, dite capture non-bloquante, consiste à laisser l’exécution continuer pendant la capture de l’image. Pour éviter les problèmes d’incohérence dans l’image capturée, on utilise un mécanisme de copie déclenchée par l’écriture : les différentes zones mémoire utilisées par le processus sont protégées en écriture, puis le mécanisme de persistance copie sur la mémoire stable puis déverrouille une à une ces zones mémoire. Si le processus tente d’accéder à une zone qui n’a pas encore été copiée, cette zone est répliquée en mémoire volatile ; le processus peut alors accéder à la zone concernée, et le mécanisme de persistance copie le replica sur la mémoire stable.
Cette optimisation nécessite aussi un accès bas niveau au système de gestion de la mémoire. Si ces accès sont impossibles, cette technique peut être approximée : une copie de la totalité de l’image du processus est d’abord stockée en mémoire volatile, puis cette copie intermédiaire est copiée sur la mémoire stable. Pendant la copie sur mémoire stable, le processus peut continuer son exécution. Le coût de la copie intermédiaire en terme de temps mais aussi d’occupation de la mémoire volatile peut cependant être prohibitif.

Recouvrabilité

La notion de recouvrabilité est le point clé de la tolérance aux pannes par recouvrement arrière ; un état recouvrable est un état stable, c’est-à-dire sauvegardé en mémoire stable, depuis lequel une exécution peut repartir correctement.
En d’autres termes, un état recouvrable :
– soit représente directement un état cohérent de l’exécution,
– soit contient suffisamment d’informations pour contrôler l’exécution jusqu’à un état cohérent.
Un état cohérent correspond à un état possible de l’exécution sans panne ; c’est donc un état depuis lequel une exécution peut repartir correctement. Informellement, un état cohérent est un état qui ne reflète pas les conséquences d’évènements qui n’ont pas encore eu lieu.

Journalisation

Le principe du mécanisme de journalisation est la sauvegarde de l’histoire d’exécution de l’application. Ces mécanismes s’appuient explicitement sur le fait qu’un processus, peut être modélisé par une séquence d’intervalles d’états déterministes. Chaque intervalle d’état débute par un événement non déterministe, dont l’enregistrement permet la reconstruction de l’état du processus. Un événement non déterministe peut être la réception d’un message ou un événement interne au processus.
La reprise basée sur la journalisation, suppose que tous les événements non déterministes peuvent être identifiés et que les informations correspondant à ces événements peuvent être enregistrées sur la mémoire stable.
En effet, le principe de la reprise basée sur la journalisation est que durant l’exécution normale, chaque processus stocke dans un journal sur mémoire stable les informations correspondant à tous les événements non déterministes qu’il observe. Après une panne, le processus défaillant reconstruit son état d’avant la panne à partir de son état initial et en utilisant son journal, afin de rejouer les événements non déterministes exactement comme ils se sont produits avant la panne. Pour éviter la reconstruction de l’état d’un processus défaillant à partir de son état initial, des sauvegardes périodiques de l’état du processus sont effectuées.
Traditionnellement, les événements non déterministes sont associés aux messages et le mécanisme de journalisation est donc appelé journalisation de messages.
Les protocoles de reprise basés sur la journalisation doivent assurer la “condition de non orphelinité” suivante : en cas de reprise de tous les processus défaillants, le système ou l’application ne contient aucun processus orphelin. Un processus orphelin est un processus dont l’état dépend d’un événement non déterministe, et ce dernier ne peut pas être reproduit par l’opération de reprise.
Les techniques de reprise par journalisation diffèrent par la façon d’assurer et d’implanter la ”condition de non orphelinité“ définie précédemment. Nous allons voir les trois protocoles de journalisation : les journalisations pessimistes, optimistes et causales.

Journalisation pessimiste

La journalisation pessimiste est une approche qui enregistre sur une mémoire stable de façon synchrone tous les messages en transit dans le système. Tout message, une fois arrivé dans le contexte du récepteur est forcément enregistré, et pourra donc être rejoué en cas de panne : ainsi, tous les points de reprise du processus sont utilisables pour une reprise, puisque tous les événements non déterministes ont été enregistrés depuis la prise de ce point. L’ordre de ces messages doit lui aussi être conservé, de manière à recréer lors de la reprise la même histoire de message.

Journalisation Optimiste

Afin d’améliorer la performance d’une exécution normale, la journalisation optimiste s’appuie sur l’hypothèse “optimiste” qu’un processus peut compléter la journalisation de son événement non déterministe avant qu’une panne ne survienne. Donc, le stockage sur la mémoire stable des informations correspondant à un événement non déterministe est asynchrone et le processus n’a pas besoin de se bloquer pendant le stockage sur la mémoire stable.
Il est évident que, la journalisation optimiste ne garantit pas toujours la "condition de non orphelinité“. Ceci rend l’opération de reprise compliquée, car il faut éventuellement retourner en arrière plusieurs fois avant de trouver un état cohérent.
Les inconvénients de cette approche résident dans le risque d’un retour à l’état initial de calcul, ce phénomène est communément appelé l’effet domino. De plus, un sûrcout important dû au calcul de l’état global cohérent est introduit durant la reprise.

Journalisation causale

Le principe de la journalisation causale est d’assurer que le déterminant de chaque événement non déterministe qui précède causalement l’état d’un processus se trouve soit en mémoire stable, soit est disponible localement pour ce processus.
La journalisation causale a l’avantage des deux méthodes précédentes en terme de performances à l’exécution et en cas de reprise. Comme la journalisation optimiste, la journalisation causale évite d’une part, la synchronisation avec la mémoire stable à l’exception du moment de la publication de résultats. D’autre part, comme dans la journalisation pessimiste, la journalisation causale ne crée jamais de processus orphelin. Cela permet la reprise de n’importe quel processus défaillant à partir de son dernier état sauvegardé sans risquer l’effet domino. L’inconvénient de cette technique réside en la complexité du protocole de recouvrement arrière suite à une panne.

Sauvegarde

Lors d’une panne, les approches basées sur la sauvegarde d’état des processus participant au calcul restaurent l’état du système ou de l’application à partir du plus récent ensemble cohérent de points de reprise. Cet ensemble cohérent de points de reprise est appelée ligne de recouvrement.
Les approches basées sur la sauvegarde n’ont pas besoin de stocker et de rejouer les événements non déterministes.
La sauvegarde peut être classée selon trois catégories en fonction du mode de construction de la ligne de recouvrement : sauvegarde coordonnée, sauvegarde non-coordonnée et sauvegarde induite par les communications.

Sauvegarde coordonnée

Ces algorithmes sont également appelés synchrones, cohérents ou globaux. Le principe de ces algorithmes est la définition de l’état global cohérent au moment de la sauvegarde et plus précisément avant de procéder à l’écriture des fichiers de sauvegarde sur la mémoire stable. Ainsi, au moment de la sauvegarde, une phase de synchronisation durant laquelle les calculs sont interrompus est imposée à tous les processus de l’application afin de déterminer l’état global cohérent.
Cette approche présente l’avantage de ne pas produire d’effet domino en cas de reprise puisque les points de reprise sont garantis cohérents. De plus, un seul point de reprise par processus est nécessaire ce qui réduit le sûrcout de stockage et de libération de points de reprise.
Le principal inconvénient de cette technique est le surcoût introduit par la coordination de tous les processus participants. Aussi, afin d’améliorer les performances de la sauvegarde coordonnée, plusieurs techniques ont été proposées :
– la sauvegarde coordonnée non bloquante évite de bloquer le processus durant la phase de sauvegarde en créant un processus clone chargé de la sauvegarde ;
– la sauvegarde avec horloge synchronisée évite la phase de synchronisation par envois de messages, en utilisant une horloge synchronisée ;
– la sauvegarde coordonnée minimale évite la phase de synchronisation globale entre tous les processus en se basant sur le fait qu’un processus n’a besoin de se coordonner qu’avec les processus avec lesquels il a des dépendances.

Sauvegarde non coordonnée

Les techniques non coordonnées évitent la phase de synchronisation en laissant à chaque processus la décision de sauvegarder son état. Le principal avantage de la sauvegarde non coordonnée est qu’un processus peut procéder à la sauvegarde de son état lorsque celui-ci est minimal, réduisant ainsi le sûrcout de la sauvegarde en terme de quantité d’informations à sauvegarder.
Mais l’inconvénient principal de cette approche est le risque d’effet domino qui peut causer une perte importante du travail réalisé avant la panne et la sauvegarde inutile de points de reprise, ceux-ci ne faisant jamais partie d’un état global cohérent. Ces points de reprise augmentent le coût de l’exécution normale et ne servent pas à la reprise après panne. De plus, la sauvegarde non coordonnée oblige chaque processus à maintenir plusieurs points de reprise.
Afin de déterminer un état global cohérent, chaque processus dispose d’un journal en mémoire stable dans lequel il enregistre tout ou partie des messages échangés ainsi que leurs historiques. Lorsqu’une défaillance survient, l’algorithme de reprise utilise les points de reprise locaux et les journaux afin de déterminer une ligne de recouvrement.

Sauvegarde induite par les communications

La sauvegarde induite par les communications, est un compromis entre la sauvegarde coordonnée et la sauvegarde non coordonnée.
L’idée principale est d’une part, d’éviter la coordination des processus en permettant la sauvegarde non coordonnée des processus, appelée sauvegarde locale, et d’autre part, d’éviter l’effet domino en forçant un processus à sauvegarder son état en cas d’évaluation de la ligne de recouvrement. Cette sauvegarde est alors appelée sauvegarde forcée.
Le principe de la sauvegarde induite par les communications est d’étendre un ensemble de points de reprise locale de l’application à un ensemble de points de reprise constituant un état global cohérent.

Conclusion

Nous avons présenté la notion de sûreté de fonctionnement d’un système informatique. Et nous avons vue que la tolérance aux pannes n’est qu’un moyen pour assurer la sûreté de fonctionnement d’un système et qu’on utilise toujours la redondance pour l’obtenir. La redandance peu être spaciale ou temporelle qui sont basé sur la duplication ou informelle basé sur la mémoire stable. La mémoire stable peut être décomposé en deux type la sauvegarde (non coordonnée, coordonnée ou induite par les communications) et la journalisation (pessimiste, optimiste o causale).
Pour conclure, il faut noter qu’il n’existe pas de méthode de tolérance aux pannes qui soit valable dans l’absolu. Seules existent des méthodes adaptées à des hypothèses particulières.

Les liens intéréssants :

Wikipedia-> Tolérance aux pannes

liafa
chez crosoft
Wapedia
supinfo

Le RAID

Comment ca marche
howto

Le systeme
Cours de Systemes II