\n1.La S\u00fbret\u00e9 de fonctionnement<\/strong><\/em><\/p>\n
La s\u00fbret\u00e9 de fonctionnement peut \u00eatre d\u00e9finit comme la capacit\u00e9 de fournir un service dans lequel un utilisateur peut raisonnablement placer sa confiance. De fa\u00e7on plus quantitative, la s\u00fbret\u00e9 de fonctionnement permet de d\u00e9cider si un syst\u00e8me est capable d\u2019assurer que la fr\u00e9quence de d\u00e9faillance du service et la gravit\u00e9 de ces d\u00e9faillances restent inf\u00e9rieurs \u00e0 un minimum consid\u00e9r\u00e9 comme acceptable.
\n
La tol\u00e9rance aux pannes proprement dite n\u2019est en r\u00e9alit\u00e9 qu\u2019une partie du concept de s\u00fbret\u00e9 de fonctionnement, plus pr\u00e9cis\u00e9ment un moyen de la s\u00fbret\u00e9 de fonctionnement.
\n
La s\u00fbret\u00e9 de fonctionnement peut \u00eatre d\u00e9-compos\u00e9 trois points de vue pr\u00e9sent\u00e9s dans les sous-sections suivantes : les entraves \u00e0 la s\u00fbret\u00e9 de fonctionnement, les attributs de la s\u00fbret\u00e9 de fonctionnement et les moyens permettant de l\u2019assurer.<\/p>\n
Les Entraves \u00e0 la s\u00fbret\u00e9 de fonctionnement<\/strong><\/p>\n Les fautes, les erreurs et les d\u00e9faillances sont les causes et les cons\u00e9quences de la non-s\u00fbret\u00e9 de fonctionnement <\/p>\n Une d\u00e9faillance du syst\u00e8me survient lorsque le service d\u00e9livr\u00e9 diff\u00e8re du service sp\u00e9ci\ufb01\u00e9. La d\u00e9faillance survient parce que le syst\u00e8me a un comportement erron\u00e9 : une erreur est la partie de l\u2019\u00e9tat du syst\u00e8me qui est susceptible d\u2019entra\u00eener une d\u00e9faillance. La cause adjug\u00e9e ou suppos\u00e9e de l\u2019erreur est une faute. Une erreur est donc la manifestation d\u2019une faute dans le syst\u00e8me, et une d\u00e9faillance est l\u2019effet d\u2019une erreur sur le service. Ceci conduit \u00e0 la cha\u00eene fondamentale:<\/p>\n – La faute ou panne est caract\u00e9ris\u00e9e par sa nature, son origine et son \u00e9tendue temporelle. La nature d\u2019une faute pr\u00e9cise la mani\u00e8re dont elle a \u00e9t\u00e9 provoqu\u00e9e : intentionnellement ou accidentellement. La cause de l\u2019apparition d\u2019une faute est r\u00e9v\u00e9l\u00e9e par son origine. L\u2019\u00e9tendue temporelle caract\u00e9rise la persistance ou la dur\u00e9e d\u2019une faute. Les Attributs de la s\u00fbret\u00e9 de fonctionnement<\/strong><\/p>\n Les attributs de la s\u00fbret\u00e9 de fonctionnement d\u2019un syst\u00e8me mettent plus ou moins l\u2019accent sur les propri\u00e9t\u00e9s que doivent v\u00e9rifier la s\u00fbret\u00e9 de fonctionnement du syst\u00e8me. Ces attributs permettent d\u2019\u00e9valuer la qualit\u00e9 du service fourni par un syst\u00e8me. Six attributs de la s\u00fbret\u00e9 de fonctionnement sont d\u00e9finis :<\/p>\n – disponibilit\u00e9 : c\u2019est la propri\u00e9t\u00e9 requise par la plupart des syst\u00e8mes s\u00fbrs de fonctionnement. Il s\u2019agit de la fraction de temps durant laquelle le syst\u00e8me est disponible pour des fins utiles ; L\u2019importance des attributs de la s\u00fbret\u00e9 de fonctionnement pr\u00e9sent\u00e9s ci-dessus est principalement li\u00e9e aux applications et \u00e0 leurs besoins.<\/p>\n Moyens d\u2019assurer la s\u00fbret\u00e9 de fonctionnement<\/strong><\/p>\n Les moyens utilis\u00e9s pour assurer la s\u00fbret\u00e9 de fonctionnement sont d\u00e9finis par les m\u00e9thodes et les approches utilis\u00e9es pour assurer cette propri\u00e9t\u00e9. Les approches les plus connues sont : Les pannes qui peuvent survenir durant une ex\u00e9cution peuvent \u00eatre class\u00e9es en quatre cat\u00e9gories : Le cas le plus simple est bien s\u00fbr le cas des pannes franches, et on essaie toujours de s\u2019y ramener, par exemple en tuant un processus en cas de comportement impr\u00e9vu. La plupart des protocoles de tol\u00e9rance aux pannes pour les syst\u00e8mes r\u00e9partis ne consid\u00e8rent que ce type de pannes.<\/p>\n De mani\u00e8re g\u00e9n\u00e9rale, un syst\u00e8me r\u00e9parti peut \u00eatre d\u00e9\ufb01ni comme un ensemble de n\u0153uds de calcul reli\u00e9s par un r\u00e9seau de communication et communiquant entre eux par messages. Techniques de tol\u00e9rance aux pannes<\/strong><\/p>\n La tol\u00e9rance aux pannes dans les syst\u00e8mes r\u00e9partis et parall\u00e8les est toujours r\u00e9alis\u00e9e par l\u2019emploi d\u2019un m\u00e9canisme de redondance. Cette derni\u00e8re peut \u00eatre par duplication de composants, par traitements multiples ou bien par redondance de donn\u00e9es, codes, signatures. Dans un tel syst\u00e8me \u00e0 base de processus communicants, les techniques de tol\u00e9rance aux pannes peuvent \u00eatre s\u00e9par\u00e9es en deux classes : les techniques bas\u00e9es sur la r\u00e9plication et les techniques bas\u00e9es sur le recouvrement arri\u00e8re.<\/p>\n La tol\u00e9rance aux pannes par r\u00e9plication<\/em><\/p>\n La tol\u00e9rance aux pannes par r\u00e9plication se base sur la redondance des processus composants l\u2019application. Cette approche permet de masquer les pannes \u00e9ventuelles : lorsqu\u2019un processus tombe en panne, une des copies de ce processus prend sa place dans le syst\u00e8me. On distingue trois approches diff\u00e9rentes pour r\u00e9aliser la redondance des processus, selon que les copies s\u2019ex\u00e9cutent syst\u00e9matiquement en parall\u00e8le ou que l\u2019ex\u00e9cution des copies soit d\u00e9marr\u00e9e en cas de panne. Plus pr\u00e9cis\u00e9ment, on distingue : L\u2019approche par r\u00e9plication active est souvent utilis\u00e9e dans un contexte o\u00f9 le temps d\u2019ex\u00e9cution est primordial. En effet, les pannes sont tr\u00e8s rapidement masqu\u00e9es et n\u2019influent que tr\u00e8s peu sur le temps d\u2019ex\u00e9cution total. Cependant, cette approche implique la disponibilit\u00e9 d\u2019un nombre important de ressources. L\u2019approche par r\u00e9plication semi-active pr\u00e9sente les m\u00eames propri\u00e9t\u00e9s, avec la capacit\u00e9 de g\u00e9rer les processus non d\u00e9terministes. <\/p>\n Le but d\u2019un protocole de tol\u00e9rance aux pannes par recouvrement arri\u00e8re est de capturer suffisamment de donn\u00e9es pendant une ex\u00e9cution distribu\u00e9e sans panne, et de stocker ces donn\u00e9es en m\u00e9moire stable. Les donn\u00e9es collect\u00e9es doivent pouvoir \u00eatre utilis\u00e9es pour red\u00e9marrer tout ou partie de l\u2019application si une panne est d\u00e9tect\u00e9e ; ces donn\u00e9es doivent former un \u00e9tat recouvrable. Dans un premier temps nous allons voir ces trois notions, puis nous allons voir quelques technique de tol\u00e9rance aux pannes par recouvrement arri\u00e8re.<\/p>\n M\u00e9moire stable<\/strong><\/p>\n L\u2019existence d\u2019une m\u00e9moire stable permet la r\u00e9alisation de la tol\u00e9rance aux pannes par une d\u00e9tection de d\u00e9faillance suivie d\u2019un recouvrement d\u2019erreur. <\/p>\n La m\u00e9moire stable peut \u00eatre d\u00e9finie comme un support persistant de stockage, dont le r\u00f4le principal est d\u2019assurer une accessibilit\u00e9 et une protection aux donn\u00e9es contre les pannes pouvant affecter le syst\u00e8me. Ainsi, suite \u00e0 une panne, un \u00e9tat correct ayant \u00e9t\u00e9 stock\u00e9 ant\u00e9rieurement \u00e0 cette panne sur la m\u00e9moire stable reste accessible ; cela permet au syst\u00e8me un retour \u00e0 un \u00e9tat ant\u00e9rieur. Un support de stockage est vu comme une m\u00e9moire stable si et seulement si les trois conditions suivantes sont vraies :<\/p>\n Principe de la tol\u00e9rance aux pannes par m\u00e9moire stable<\/em><\/p>\n Le principe de cette technique est de remplacer l\u2019\u00e9tat d\u2019erreur par un \u00e9tat correct en se basant sur l\u2019abstraction d\u2019une m\u00e9moire stable pr\u00e9sent\u00e9e dans le paragraphe ci-dessus. Ceci n\u00e9cessite tout d\u2019abord la d\u00e9tection de l\u2019erreur, c\u2019est \u00e0 dire, identifier la partie incorrecte de l\u2019\u00e9tat, afin de pouvoir ensuite effectuer le recouvrement d\u2019erreur. Comme nous l\u2019avons d\u00e9j\u00e0 remarqu\u00e9, pour pouvoir r\u00e9aliser une reprise apr\u00e8s une panne, l\u2019\u00e9tat du syst\u00e8me ou de l\u2019application doit \u00eatre sauvegard\u00e9 p\u00e9riodiquement ou lors de l’occurrence d\u2019\u00e9v\u00e9nements sp\u00e9cifiques. L\u2019\u00e9tat sauvegard\u00e9 doit constituer un point de reprise \u00e0 partir duquel le syst\u00e8me peut fonctionner correctement. Pour assurer cette propri\u00e9t\u00e9, le m\u00e9canisme de tol\u00e9rance aux pannes doit r\u00e9soudre les probl\u00e8mes de reprise suivants : La construction d’un \u00e9tat global coh\u00e9rent d’un syst\u00e8me r\u00e9partis peut \u00eatre vue suivant deux approche : Il est \u00e0 noter que la sauvegarde d\u2019une donn\u00e9es sur une m\u00e9moire stable peut \u00eatre implant\u00e9e par des techniques de codage pour limiter la redondance. Parmi les syst\u00e8mes utilisant cette technique, on peut citer les syst\u00e8mes RAID (Redundant Array of Independent Disks), les serveurs de stockage paire \u00e0 paire. Cette technique a \u00e9t\u00e9 propos\u00e9e pour les syst\u00e8mes de calcul parall\u00e8le.<\/p>\n Capture de l’\u00e9tat d’un processus<\/strong><\/p>\n La tol\u00e9rance aux pannes par recouvrement arri\u00e8re suppose aussi qu\u2019un processus peut capturer une image de son \u00e9tat, ou point de reprise (checkpoint), au cours de son ex\u00e9cution ; cette image peut \u00e9ventuellement \u00eatre stock\u00e9e sur la m\u00e9moire stable. Elle doit pouvoir \u00eatre utilis\u00e9e directement pour red\u00e9marrer le processus ; l\u2019image produite doit donc contenir tout le contexte du processus comme les registres courants, les segments de donn\u00e9es ou la pile d\u2019ex\u00e9cution. La persistance des processus peuvent \u00eatre s\u00e9parer en deux cat\u00e9gories : De plus, nous les comparons selon les crit\u00e8res suivants : Deux techniques permettent de r\u00e9duire le surco\u00fbt induit par la capture d\u2019une image. La premi\u00e8re consiste \u00e0 cr\u00e9er les images de mani\u00e8re incr\u00e9mentale : lors de la capture, seules les parties de l\u2019\u00e9tat qui ont \u00e9t\u00e9 modifi\u00e9es depuis la capture pr\u00e9c\u00e9dente sont stock\u00e9es. Cette technique permet en particulier de r\u00e9duire la taille des images produites. Elle n\u00e9cessite de pouvoir tracer les modifications des zones m\u00e9moire utilis\u00e9es par le processus, et requiert donc des acc\u00e8s de bas niveau. Recouvrabilit\u00e9<\/strong><\/p>\n La notion de recouvrabilit\u00e9 est le point cl\u00e9 de la tol\u00e9rance aux pannes par recouvrement arri\u00e8re ; un \u00e9tat recouvrable est un \u00e9tat stable, c\u2019est-\u00e0-dire sauvegard\u00e9 en m\u00e9moire stable, depuis lequel une ex\u00e9cution peut repartir correctement. Journalisation<\/strong><\/p>\n Le principe du m\u00e9canisme de journalisation est la sauvegarde de l\u2019histoire d\u2019ex\u00e9cution de l\u2019application. Ces m\u00e9canismes s\u2019appuient explicitement sur le fait qu\u2019un processus, peut \u00eatre mod\u00e9lis\u00e9 par une s\u00e9quence d\u2019intervalles d\u2019\u00e9tats d\u00e9terministes. Chaque intervalle d\u2019\u00e9tat d\u00e9bute par un \u00e9v\u00e9nement non d\u00e9terministe, dont l\u2019enregistrement permet la reconstruction de l\u2019\u00e9tat du processus. Un \u00e9v\u00e9nement non d\u00e9terministe peut \u00eatre la r\u00e9ception d\u2019un message ou un \u00e9v\u00e9nement interne au processus. Journalisation pessimiste<\/em><\/p>\n La journalisation pessimiste est une approche qui enregistre sur une m\u00e9moire stable de fa\u00e7on synchrone tous les messages en transit dans le syst\u00e8me. Tout message, une fois arriv\u00e9 dans le contexte du r\u00e9cepteur est forc\u00e9ment enregistr\u00e9, et pourra donc \u00eatre rejou\u00e9 en cas de panne : ainsi, tous les points de reprise du processus sont utilisables pour une reprise, puisque tous les \u00e9v\u00e9nements non d\u00e9terministes ont \u00e9t\u00e9 enregistr\u00e9s depuis la prise de ce point. L\u2019ordre de ces messages doit lui aussi \u00eatre conserv\u00e9, de mani\u00e8re \u00e0 recr\u00e9er lors de la reprise la m\u00eame histoire de message.<\/p>\n Journalisation Optimiste<\/em><\/p>\n Afin d\u2019am\u00e9liorer la performance d\u2019une ex\u00e9cution normale, la journalisation optimiste s\u2019appuie sur l\u2019hypoth\u00e8se \u201coptimiste\u201d qu\u2019un processus peut compl\u00e9ter la journalisation de son \u00e9v\u00e9nement non d\u00e9terministe avant qu\u2019une panne ne survienne. Donc, le stockage sur la m\u00e9moire stable des informations correspondant \u00e0 un \u00e9v\u00e9nement non d\u00e9terministe est asynchrone et le processus n\u2019a pas besoin de se bloquer pendant le stockage sur la m\u00e9moire stable. Journalisation causale<\/em><\/p>\n Le principe de la journalisation causale est d\u2019assurer que le d\u00e9terminant de chaque \u00e9v\u00e9nement non d\u00e9terministe qui pr\u00e9c\u00e8de causalement l\u2019\u00e9tat d\u2019un processus se trouve soit en m\u00e9moire stable, soit est disponible localement pour ce processus. Sauvegarde<\/strong><\/p>\n Lors d\u2019une panne, les approches bas\u00e9es sur la sauvegarde d\u2019\u00e9tat des processus participant au calcul restaurent l\u2019\u00e9tat du syst\u00e8me ou de l\u2019application \u00e0 partir du plus r\u00e9cent ensemble coh\u00e9rent de points de reprise. Cet ensemble coh\u00e9rent de points de reprise est appel\u00e9e ligne de recouvrement. Sauvegarde coordonn\u00e9e<\/em><\/p>\n Ces algorithmes sont \u00e9galement appel\u00e9s synchrones, coh\u00e9rents ou globaux. Le principe de ces algorithmes est la d\u00e9finition de l\u2019\u00e9tat global coh\u00e9rent au moment de la sauvegarde et plus pr\u00e9cis\u00e9ment avant de proc\u00e9der \u00e0 l\u2019\u00e9criture des fichiers de sauvegarde sur la m\u00e9moire stable. Ainsi, au moment de la sauvegarde, une phase de synchronisation durant laquelle les calculs sont interrompus est impos\u00e9e \u00e0 tous les processus de l\u2019application afin de d\u00e9terminer l\u2019\u00e9tat global coh\u00e9rent. Sauvegarde non coordonn\u00e9e<\/em><\/p>\n Les techniques non coordonn\u00e9es \u00e9vitent la phase de synchronisation en laissant \u00e0 chaque processus la d\u00e9cision de sauvegarder son \u00e9tat. Le principal avantage de la sauvegarde non coordonn\u00e9e est qu\u2019un processus peut proc\u00e9der \u00e0 la sauvegarde de son \u00e9tat lorsque celui-ci est minimal, r\u00e9duisant ainsi le s\u00fbrcout de la sauvegarde en terme de quantit\u00e9 d\u2019informations \u00e0 sauvegarder. Sauvegarde induite par les communications<\/em><\/p>\n La sauvegarde induite par les communications, est un compromis entre la sauvegarde coordonn\u00e9e et la sauvegarde non coordonn\u00e9e. Nous avons pr\u00e9sent\u00e9 la notion de s\u00fbret\u00e9 de fonctionnement d’un syst\u00e8me informatique. Et nous avons vue que la tol\u00e9rance aux pannes n’est qu’un moyen pour assurer la s\u00fbret\u00e9 de fonctionnement d’un syst\u00e8me et qu’on utilise toujours la redondance pour l’obtenir. La redandance peu \u00eatre spaciale ou temporelle qui sont bas\u00e9 sur la duplication ou informelle bas\u00e9 sur la m\u00e9moire stable. La m\u00e9moire stable peut \u00eatre d\u00e9compos\u00e9 en deux type la sauvegarde (non coordonn\u00e9e, coordonn\u00e9e ou induite par les communications) et la journalisation (pessimiste, optimiste o causale). Les liens int\u00e9r\u00e9ssants:<\/p>\n Wikipedia-> [?Tol\u00e9rance aux pannes] <\/p>\n liafa<\/a>![\"Rapport_html_78ce3525.gif\"](\"https:\/\/fredptitgars.ovh\/wp-content\/uploads\/2008\/01\/Rapport_html_78ce3525-ad2.gif\")
<\/p>\n
\n– Une erreur est la cons\u00e9quence d\u2019une faute. Une d\u00e9faillance survient d\u00e8s que le syst\u00e8me utilise un \u00e9tat erron\u00e9. Premi\u00e8rement, le service ne correspond pas en valeur \u00e0 celui sp\u00e9cifi\u00e9. Deuxi\u00e8mement, le service n\u2019est pas d\u00e9livr\u00e9 dans l\u2019intervalle de temps sp\u00e9cifi\u00e9. Le service rendu est toujours en avance ou toujours en retard. Le fait que le syst\u00e8me omette de rendre le service est consid\u00e9r\u00e9 \u00e9galement comme un type d\u2019erreur. Un arr\u00eat (crash) est d\u00e9\ufb01ni par le fait que le syst\u00e8me omet d\u00e9finitivement de d\u00e9livrer des services.
\n– Une d\u00e9faillance d\u00e9note l\u2019incapacit\u00e9 d\u2019un \u00e9l\u00e9ment du syst\u00e8me \u00e0 assurer le service sp\u00e9ci\ufb01\u00e9 par l\u2019utilisateur. La d\u00e9faillance est caract\u00e9ris\u00e9e par son domaine, sa perception par les utilisateurs et ses cons\u00e9quences sur l\u2019environnement.<\/p>\n
\n– \ufb01abilit\u00e9 : cet attribut \u00e9value la continuit\u00e9 du service i.e. le taux en temps de fonctionnement pendant lequel le syst\u00e8me ne subit aucune faute ;
\ns\u00e9curit\u00e9-innocuit\u00e9 : l\u2019absence de cons\u00e9quences catastrophiques sur l\u2019utilisateur ou son environnement ;
\n– con\ufb01dentialit\u00e9 : cet attribut \u00e9value la capacit\u00e9 du syst\u00e8me \u00e0 fonctionner en d\u00e9pit de fautes intentionnelles et d\u2019intrusions ill\u00e9gales ;
\nint\u00e9grit\u00e9 : l\u2019int\u00e9grit\u00e9 d\u2019un syst\u00e8me d\u00e9\ufb01nit son aptitude \u00e0 assurer des alt\u00e9rations approuv\u00e9es des donn\u00e9es ;
\n– maintenabilit\u00e9 : cette propri\u00e9t\u00e9 d\u00e9crit la souplesse du syst\u00e8me vis-\u00e0-vis des modifications apport\u00e9es en vue de sa maintenance.<\/p>\n
\n– la pr\u00e9vention des fautes<\/em> qui s\u2019attache aux moyens permettant d\u2019\u00e9viter l’occurrence de fautes dans le syst\u00e8me. Ce sont g\u00e9n\u00e9ralement les approches de v\u00e9rification des mod\u00e8les conceptuels ;
\n– L\u2019\u00e9limination des fautes<\/em> qui se focalise sur les techniques permettant de r\u00e9duire la pr\u00e9sence de fautes ou leurs impacts. Cela est r\u00e9alis\u00e9 par des m\u00e9thodes statiques de preuve de la validit\u00e9 du syst\u00e8me (simulation, tests, …) ;
\n– la pr\u00e9vision des fautes<\/em> qui pr\u00e9dit l’occurrence des fautes (temps, nombre, impact) et leurs cons\u00e9quences. Ceci est r\u00e9alis\u00e9 g\u00e9n\u00e9ralement par des m\u00e9thodes d\u2019injection de fautes afin de valider le syst\u00e8me relativement \u00e0 ces fautes ;
\n– La tol\u00e9rance aux pannes<\/em> ou aux fautes qui essaye de fonctionner en d\u00e9pit des fautes. Le degr\u00e9 de tol\u00e9rance aux pannes se mesure par la capacit\u00e9 du syst\u00e8me \u00e0 continuer \u00e0 d\u00e9livrer son service en pr\u00e9sence de fautes.<\/p>\nLes types de pannes<\/h2>\n
\n– les pannes franches<\/em> (crash, fail-stop), que l\u2019on appelle aussi arr\u00eat sur d\u00e9faillance. C\u2019est le cas le plus simple : on consid\u00e8re qu\u2019un processus peut \u00eatre dans deux \u00e9tats, soit il fonctionne et donne le r\u00e9sultat correct, soit il ne fait plus rien. Dans le second cas, le processus est consid\u00e9r\u00e9 comme d\u00e9faillant.
\n– les pannes par omission<\/em> (transient, omission failures). Dans ce cas, on consid\u00e8re que le syst\u00e8me peut perdre des messages. Ce mod\u00e8le peut servir \u00e0 repr\u00e9senter des d\u00e9faillances du r\u00e9seau plut\u00f4t que des processus.
\n– Les pannes de temporisation<\/em> (timing, performance failures). Ce sont les comportements anormaux par rapport \u00e0 un temps, comme par exemple l\u2019expiration d\u2019un d\u00e9lai de garde.
\n
Les pannes arbitraires, ou byzantines (malicious, byzantine failures). Cette classe repr\u00e9sente toutes les autres pannes : le processus peut alors faire \u00ab n\u2019importe quoi \u00bb, y compris avoir un comportement malveillant.<\/p>\nTol\u00e9rance aux pannes dans les syst\u00e8mes r\u00e9partis<\/h2>\n
\n
Dans ce contexte, la tol\u00e9rance aux pannes est un besoin impos\u00e9 par la r\u00e9partition et c\u2019est pourquoi plusieurs travaux de recherches sur les syst\u00e8mes r\u00e9partis ont \u00e9t\u00e9 r\u00e9alis\u00e9s a\ufb01n de la prendre en compte.<\/p>\n
\n– la r\u00e9plication active<\/em> : toutes les copies de processus s\u2019ex\u00e9cutent en m\u00eame temps. En particulier, tous les messages \u00e0 destination d\u2019un processus sont envoy\u00e9s \u00e0 toutes les copies. Les diff\u00e9rentes copies gardent donc un \u00e9tat \u00e9troitement synchronis\u00e9 durant l\u2019ex\u00e9cution. Ce type de r\u00e9plication permet de g\u00e9rer tout type de faute, en particulier les pannes byzantines. Notons que la r\u00e9plication active impose que tous les processus soient totalement d\u00e9terministes ; on suppose que les ex\u00e9cutions des diff\u00e9rentes copies ne peuvent pas diverger.
\n– la r\u00e9plication passive<\/em> : une seule des copies, la copie primaire, s\u2019ex\u00e9cute \u00e0 la fois. En cas de panne, une copie secondaire est d\u00e9marr\u00e9e et doit rattraper l\u2019ex\u00e9cution jusqu\u2019\u00e0 l\u2019\u00e9tat de la copie primaire avant la panne. L\u2019\u00e9tat des copies secondaires doit donc \u00eatre r\u00e9guli\u00e8rement mis \u00e0 jour par la copie primaire. Cette technique est en fait similaire aux approches par recouvrement arri\u00e8re.
\n– la r\u00e9plication semi-active<\/em> : toutes les copies s\u2019ex\u00e9cutent en m\u00eame temps, mais une seule d\u2019entre elle, la copie ma\u00eetresse, \u00e9met les messages r\u00e9sultants de l\u2019ex\u00e9cution. Ainsi, les autres copies mettent \u00e0 jour leur \u00e9tat interne et sont donc \u00e9troitement synchronis\u00e9es avec la copie ma\u00eetresse. L\u2019int\u00e9r\u00eat de cette approche est de pouvoir prendre en compte les processus non d\u00e9terministes : seule la copie ma\u00eetresse est responsable des choix non d\u00e9terministes, et en informe les autres copies par des messages sp\u00e9cifiques.<\/p>\nLa tol\u00e9rance aux pannes par recouvrement arri\u00e8re<\/h2>\n
\n
On peut donc distinguer trois \u00e9l\u00e9ments cl\u00e9s dans la tol\u00e9rance aux pannes par recouvrement arri\u00e8re :
\n– l\u2019acc\u00e8s \u00e0 une m\u00e9moire stable,
\n– la capacit\u00e9 de capturer l\u2019\u00e9tat des processus,
\n– la caract\u00e9risation et la cr\u00e9ation d\u2019\u00e9tats recouvrables.<\/p>\n\n
\n
Souvent, il y a une confusion entre la m\u00e9moire stable et le composant mat\u00e9riel qui l\u2019implante. La m\u00e9moire stable doit garantir la persistance et l\u2019accessibilit\u00e9 des donn\u00e9es n\u00e9cessaires \u00e0 une reprise apr\u00e8s panne. Ceci peut conduire \u00e0 diff\u00e9rentes mises en \u0153uvre d\u2019une m\u00e9moire stable :
\n– Dans les approches o\u00f9 le m\u00e9canisme de tol\u00e9rance aux pannes ne tol\u00e8re qu\u2019une seule panne, la m\u00e9moire stable d\u2019un processus peut correspondre \u00e0 la m\u00e9moire volatile ou au disque d\u2019un autre processus ;
\n– Si l\u2019objectif de la tol\u00e9rance aux pannes est de tol\u00e9rer un nombre arbitraire de pannes transitoires, le disque dur local de chaque processus peut \u00eatre utilis\u00e9 pour implanter sa m\u00e9moire stable ;
\n– Pour un syst\u00e8me qui tol\u00e8re les pannes permanentes (non transitoires), la m\u00e9moire stable est un support de stockage persistant situ\u00e9 en dehors des n\u0153uds ex\u00e9cutant les processus de calcul ; celle-ci reste accessible \u00e0 tout moment.<\/li>\n<\/ol>\n
\nLa d\u00e9tection de d\u00e9faillances se fait g\u00e9n\u00e9ralement au moyen d\u2019un test de vraisemblance. Ce dernier peut \u00eatre explicite en v\u00e9rifiant des propri\u00e9t\u00e9s sp\u00e9cifiques de l\u2019\u00e9tat, ou implicite via des cons\u00e9quences visibles comme par exemple la violation d\u2019un d\u00e9lai de garde.
\n
Les objectifs de la d\u00e9tection d\u2019erreur sont de pr\u00e9venir, si possible, l\u2019occurrence d\u2019une d\u00e9faillance provoqu\u00e9e par l\u2019erreur, d\u2019\u00e9viter la propagation de l\u2019erreur \u00e0 d\u2019autres composants et de faciliter l’identification ult\u00e9rieure de la faute en vue de son \u00e9limination ou de sa pr\u00e9vention.
\n
Une fois qu\u2019une panne est d\u00e9tect\u00e9e, un m\u00e9canisme de recouvrement doit \u00eatre mis en place pour traiter la panne identifi\u00e9e. Il existe deux techniques de recouvrement :
\n– la reprise : c\u2019est la technique g\u00e9n\u00e9rale qui consiste \u00e0 retourner vers un \u00e9tat ant\u00e9rieur dont on sait qu\u2019il est correct. Cette technique n\u00e9cessite donc la sauvegarde r\u00e9guli\u00e8re de l\u2019\u00e9tat du syst\u00e8me ou de l\u2019application.
\n– la poursuite : c\u2019est une technique sp\u00e9cifique qui consiste \u00e0 reconstituer un \u00e9tat correct, sans retour en arri\u00e8re. La reconstitution n\u2019est souvent que partielle, d\u2019o\u00f9 un service d\u00e9grad\u00e9.<\/p>\n
\n– La sauvegarde et la restauration d\u2019un point de reprise doivent \u00eatre atomiques.
\n– L\u2019\u00e9tat des points de reprise doit lui-m\u00eame \u00eatre prot\u00e9g\u00e9 contre les fautes ;
\n– Dans un syst\u00e8me r\u00e9parti, les points de reprise sont cr\u00e9\u00e9s pour chaque processus. L\u2019ensemble de ces points de reprise doit constituer un \u00e9tat global coh\u00e9rent du syst\u00e8me.<\/p>\n
\n– A priori : les sauvegardes des diff\u00e9rents \u00e9tats des processus coop\u00e9rants sont coordonn\u00e9es pour constituer un \u00e9tat global coh\u00e9rent ;
\n– A posteriori : les sauvegardes des \u00e9tats des processus sont ind\u00e9pendantes ; la reconstitution d\u2019un \u00e9tat global coh\u00e9rent se fait lors de la reprise.<\/p>\n
\n– les m\u00e9thodes offrant une persistance forte, c\u2019est-\u00e0-dire que la capture d\u2019\u00e9tat peut \u00eatre d\u00e9clench\u00e9e \u00e0 n\u2019importe quel moment de l\u2019ex\u00e9cution par un autre processus ind\u00e9pendant,
\n– Les m\u00e9thodes offrant une persistance faible, c\u2019est-\u00e0-dire que la capture d\u2019\u00e9tat ne peut \u00eatre r\u00e9alis\u00e9e que lorsque l\u2019ex\u00e9cution atteint un point particulier, ou point de capture potentielle.<\/p>\n
\n– l\u2019impact sur les performances : le surco\u00fbt global sur le temps d\u2019ex\u00e9cution induit par le m\u00e9canisme de persistance ;
\n– l\u2019efficacit\u00e9 du m\u00e9canisme : le surco\u00fbt sur le temps d\u2019ex\u00e9cution induit par la capture d\u2019une image ;
\n– la portabilit\u00e9 du m\u00e9canisme : si le m\u00e9canisme de persistance peut \u00eatre utilis\u00e9 sur diff\u00e9rentes architectures ;
\n– la portabilit\u00e9 des images : si les images produites peuvent \u00eatre utilis\u00e9es pour red\u00e9marrer les processus sur des architectures diff\u00e9rentes de celle dans laquelle la capture a \u00e9t\u00e9 faite ;
\n– la transparence : si le m\u00e9canisme de persistance fait intervenir l\u2019utilisateur.<\/p>\n
\n
La seconde technique, dite capture non-bloquante, consiste \u00e0 laisser l\u2019ex\u00e9cution continuer pendant la capture de l\u2019image. Pour \u00e9viter les probl\u00e8mes d\u2019incoh\u00e9rence dans l\u2019image captur\u00e9e, on utilise un m\u00e9canisme de copie d\u00e9clench\u00e9e par l\u2019\u00e9criture : les diff\u00e9rentes zones m\u00e9moire utilis\u00e9es par le processus sont prot\u00e9g\u00e9es en \u00e9criture, puis le m\u00e9canisme de persistance copie sur la m\u00e9moire stable puis d\u00e9verrouille une \u00e0 une ces zones m\u00e9moire. Si le processus tente d\u2019acc\u00e9der \u00e0 une zone qui n\u2019a pas encore \u00e9t\u00e9 copi\u00e9e, cette zone est r\u00e9pliqu\u00e9e en m\u00e9moire volatile ; le processus peut alors acc\u00e9der \u00e0 la zone concern\u00e9e, et le m\u00e9canisme de persistance copie le replica sur la m\u00e9moire stable.
\n
Cette optimisation n\u00e9cessite aussi un acc\u00e8s bas niveau au syst\u00e8me de gestion de la m\u00e9moire. Si ces acc\u00e8s sont impossibles, cette technique peut \u00eatre approxim\u00e9e : une copie de la totalit\u00e9 de l\u2019image du processus est d\u2019abord stock\u00e9e en m\u00e9moire volatile, puis cette copie interm\u00e9diaire est copi\u00e9e sur la m\u00e9moire stable. Pendant la copie sur m\u00e9moire stable, le processus peut continuer son ex\u00e9cution. Le co\u00fbt de la copie interm\u00e9diaire en terme de temps mais aussi d\u2019occupation de la m\u00e9moire volatile peut cependant \u00eatre prohibitif.<\/p>\n
\n
En d\u2019autres termes, un \u00e9tat recouvrable :
\n– soit repr\u00e9sente directement un \u00e9tat coh\u00e9rent de l\u2019ex\u00e9cution,
\n– soit contient suffisamment d\u2019informations pour contr\u00f4ler l\u2019ex\u00e9cution jusqu\u2019\u00e0 un \u00e9tat coh\u00e9rent.
\n
Un \u00e9tat coh\u00e9rent correspond \u00e0 un \u00e9tat possible de l\u2019ex\u00e9cution sans panne ; c\u2019est donc un \u00e9tat depuis lequel une ex\u00e9cution peut repartir correctement. Informellement, un \u00e9tat coh\u00e9rent est un \u00e9tat qui ne refl\u00e8te pas les cons\u00e9quences d\u2019\u00e9v\u00e8nements qui n\u2019ont pas encore eu lieu.<\/p>\n
\n
La reprise bas\u00e9e sur la journalisation, suppose que tous les \u00e9v\u00e9nements non d\u00e9terministes peuvent \u00eatre identifi\u00e9s et que les informations correspondant \u00e0 ces \u00e9v\u00e9nements peuvent \u00eatre enregistr\u00e9es sur la m\u00e9moire stable.
\n
En effet, le principe de la reprise bas\u00e9e sur la journalisation est que durant l\u2019ex\u00e9cution normale, chaque processus stocke dans un journal sur m\u00e9moire stable les informations correspondant \u00e0 tous les \u00e9v\u00e9nements non d\u00e9terministes qu\u2019il observe. Apr\u00e8s une panne, le processus d\u00e9faillant reconstruit son \u00e9tat d\u2019avant la panne \u00e0 partir de son \u00e9tat initial et en utilisant son journal, afin de rejouer les \u00e9v\u00e9nements non d\u00e9terministes exactement comme ils se sont produits avant la panne. Pour \u00e9viter la reconstruction de l\u2019\u00e9tat d\u2019un processus d\u00e9faillant \u00e0 partir de son \u00e9tat initial, des sauvegardes p\u00e9riodiques de l\u2019\u00e9tat du processus sont effectu\u00e9es.
\n
Traditionnellement, les \u00e9v\u00e9nements non d\u00e9terministes sont associ\u00e9s aux messages et le m\u00e9canisme de journalisation est donc appel\u00e9 journalisation de messages.
\n
Les protocoles de reprise bas\u00e9s sur la journalisation doivent assurer la \u201ccondition de non orphelinit\u00e9\u201d suivante : en cas de reprise de tous les processus d\u00e9faillants, le syst\u00e8me ou l\u2019application ne contient aucun processus orphelin. Un processus orphelin est un processus dont l\u2019\u00e9tat d\u00e9pend d\u2019un \u00e9v\u00e9nement non d\u00e9terministe, et ce dernier ne peut pas \u00eatre reproduit par l\u2019op\u00e9ration de reprise.
\n
Les techniques de reprise par journalisation diff\u00e8rent par la fa\u00e7on d\u2019assurer et d\u2019implanter la \u201dcondition de non orphelinit\u00e9\u201c d\u00e9finie pr\u00e9c\u00e9demment. Nous allons voir les trois protocoles de journalisation : les journalisations pessimistes, optimistes et causales.<\/p>\n
\n
Il est \u00e9vident que, la journalisation optimiste ne garantit pas toujours la \u00ab\u00a0condition de non orphelinit\u00e9\u201c. Ceci rend l\u2019op\u00e9ration de reprise compliqu\u00e9e, car il faut \u00e9ventuellement retourner en arri\u00e8re plusieurs fois avant de trouver un \u00e9tat coh\u00e9rent.
\n
Les inconv\u00e9nients de cette approche r\u00e9sident dans le risque d\u2019un retour \u00e0 l\u2019\u00e9tat initial de calcul, ce ph\u00e9nom\u00e8ne est commun\u00e9ment appel\u00e9 l\u2019effet domino. De plus, un s\u00fbrcout important d\u00fb au calcul de l\u2019\u00e9tat global coh\u00e9rent est introduit durant la reprise.<\/p>\n
\n
La journalisation causale a l\u2019avantage des deux m\u00e9thodes pr\u00e9c\u00e9dentes en terme de performances \u00e0 l\u2019ex\u00e9cution et en cas de reprise. Comme la journalisation optimiste, la journalisation causale \u00e9vite d\u2019une part, la synchronisation avec la m\u00e9moire stable \u00e0 l\u2019exception du moment de la publication de r\u00e9sultats. D\u2019autre part, comme dans la journalisation pessimiste, la journalisation causale ne cr\u00e9e jamais de processus orphelin. Cela permet la reprise de n\u2019importe quel processus d\u00e9faillant \u00e0 partir de son dernier \u00e9tat sauvegard\u00e9 sans risquer l\u2019effet domino. L\u2019inconv\u00e9nient de cette technique r\u00e9side en la complexit\u00e9 du protocole de recouvrement arri\u00e8re suite \u00e0 une panne.<\/p>\n
\n
Les approches bas\u00e9es sur la sauvegarde n\u2019ont pas besoin de stocker et de rejouer les \u00e9v\u00e9nements non d\u00e9terministes.
\n
La sauvegarde peut \u00eatre class\u00e9e selon trois cat\u00e9gories en fonction du mode de construction de la ligne de recouvrement : sauvegarde coordonn\u00e9e, sauvegarde non-coordonn\u00e9e et sauvegarde induite par les communications.<\/p>\n
\nCette approche pr\u00e9sente l\u2019avantage de ne pas produire d\u2019effet domino en cas de reprise puisque les points de reprise sont garantis coh\u00e9rents. De plus, un seul point de reprise par processus est n\u00e9cessaire ce qui r\u00e9duit le s\u00fbrcout de stockage et de lib\u00e9ration de points de reprise.
\nLe principal inconv\u00e9nient de cette technique est le surco\u00fbt introduit par la coordination de tous les processus participants. Aussi, afin d\u2019am\u00e9liorer les performances de la sauvegarde coordonn\u00e9e, plusieurs techniques ont \u00e9t\u00e9 propos\u00e9es :
\n– la sauvegarde coordonn\u00e9e non bloquante \u00e9vite de bloquer le processus durant la phase de sauvegarde en cr\u00e9ant un processus clone charg\u00e9 de la sauvegarde ;
\n– la sauvegarde avec horloge synchronis\u00e9e \u00e9vite la phase de synchronisation par envois de messages, en utilisant une horloge synchronis\u00e9e ;
\n– la sauvegarde coordonn\u00e9e minimale \u00e9vite la phase de synchronisation globale entre tous les processus en se basant sur le fait qu\u2019un processus n\u2019a besoin de se coordonner qu\u2019avec les processus avec lesquels il a des d\u00e9pendances.<\/p>\n
\n
Mais l\u2019inconv\u00e9nient principal de cette approche est le risque d\u2019effet domino qui peut causer une perte importante du travail r\u00e9alis\u00e9 avant la panne et la sauvegarde inutile de points de reprise, ceux-ci ne faisant jamais partie d\u2019un \u00e9tat global coh\u00e9rent. Ces points de reprise augmentent le co\u00fbt de l\u2019ex\u00e9cution normale et ne servent pas \u00e0 la reprise apr\u00e8s panne. De plus, la sauvegarde non coordonn\u00e9e oblige chaque processus \u00e0 maintenir plusieurs points de reprise.
\n
Afin de d\u00e9terminer un \u00e9tat global coh\u00e9rent, chaque processus dispose d\u2019un journal en m\u00e9moire stable dans lequel il enregistre tout ou partie des messages \u00e9chang\u00e9s ainsi que leurs historiques. Lorsqu\u2019une d\u00e9faillance survient, l\u2019algorithme de reprise utilise les points de reprise locaux et les journaux afin de d\u00e9terminer une ligne de recouvrement.<\/p>\n
\n
L\u2019id\u00e9e principale est d\u2019une part, d\u2019\u00e9viter la coordination des processus en permettant la sauvegarde non coordonn\u00e9e des processus, appel\u00e9e sauvegarde locale, et d\u2019autre part, d\u2019\u00e9viter l\u2019effet domino en for\u00e7ant un processus \u00e0 sauvegarder son \u00e9tat en cas d\u2019\u00e9valuation de la ligne de recouvrement. Cette sauvegarde est alors appel\u00e9e sauvegarde forc\u00e9e.
\n
Le principe de la sauvegarde induite par les communications est d\u2019\u00e9tendre un ensemble de points de reprise locale de l\u2019application \u00e0 un ensemble de points de reprise constituant un \u00e9tat global coh\u00e9rent.<\/p>\nConclusion<\/h2>\n
\n
Pour conclure, il faut noter qu\u2019il n\u2019existe pas de m\u00e9thode de tol\u00e9rance aux pannes qui soit valable dans l\u2019absolu. Seules existent des m\u00e9thodes adapt\u00e9es \u00e0 des hypoth\u00e8ses particuli\u00e8res.<\/p>\n
\n
\n
chez crosoft<\/a>
\n
Wapedia<\/a>
\n
supinfo<\/a><\/p>\nLe RAID<\/h2>\n