Post on 03-Apr-2015
Introduction à la tolérance aux défaillances
Joffroy Beauquier
LRI CNRS – Université Paris Sud
Défaillances
Motivation Accroissement du nombre des
composants Impossibilité de relancer le
système chaque fois qu’une défaillance se produit
Le problème se pose aussi dans le cas séquentiel
Trois approches Algorithmes robustes Auto-stabilisation Etats de reprise et retours en
arrière
Les hypothèses (algorithmes robustes) Les défaillances n’affectent qu’une
partie du système Utilisation de la redondance par la
multiplication Mais problème du consensus Bien entendu les défaillances
peuvent frapper l’algorithme de consensus
Types de défaillances (algorithmes robustes) Processus initialement morts Défaillances définitives Omissions Comportement byzantin
(malveillant) Hiérarchie de défaillances
Les hypothèses (auto-stabilisation) Les défaillances peuvent frapper
tout ce qui n’est pas fixe dans le système (mémoires, canaux mais pas le code)
Les défaillances sont peu fréquentes (par rapport au temps de récupération)
Algorithmes robustes L’effet des défaillances est masqué La correction est maintenue tout au
long de l’exécution Le surcoût dû au contrôle est très
important Approche réservée à des systèmes
critiques (aviation civile, contrôle de centrales nucléaires, navette spatiale)
Algorithmes auto-stabilisants L’effet des défaillances n’est pas
masqué Après des défaillances, le
comportement cesse d’être correct, mais après un certain délai, il le redevient, sans intervention extérieure ou centralisée
Le surcoût en phase stabilisée est faible
Auto-stabilisation
Temps
Etats
Etats légitimes
Défaillances
Problèmes de décision (alg. robustes) Chaque processus dispose d’une
valeur d’entrée Chaque processus (correct) doit
écrire de manière irréversible une valeur de sortie
La valeur de décision dépend des valeurs d’entrée
Consensus sur les entrées Calculs répliqués sur plusieurs machines (au
début d’un pas, les valeurs d’entrée sont identiques)
Pour chaque pas de calcul, on obtient donc autant de résultats que de réplications
En l’absence de défaillances tous les résultats sont identiques
Avec des défaillances ils peuvent être différents. On veut que les processus non défaillants tombent d’accord sur la valeur à utiliser pour le pas suivant
Consensus : exemples L’effet d’un capteur défectueux,
qui donne des résultats différents de ceux des capteurs en bon état, doit être neutralisé
La navette spatiale
Voteur
1 1 1 1
1
0111
Diffusion fiable
Diffusion fiable Un diffuseur doit envoyer une valeur à
tous les autres processus Chaque processus doit décider une
valeur Tous les processus corrects doivent
décider la même valeur Si le diffuseur est non-défaillant, la
valeur décidée doit être la valeur du diffuseur
Commit/abort
Commit-Abort Base de données répliquée Une transaction impliquant plusieurs
sites doit être exécutée (commit) soit sur tous les sites, soit sur aucun (abort)
Vote des sites (oui ou non) Si tous les sites votent oui chacun doit
décider oui Si un des sites vote non chacun doit
décider non
Election Un des processus doit décider
d’être le leader et les autres de ne pas l’être
Régénération du jeton d’un token ring
Désignation d’un serveur
Group membership Systèmes en ligne (contrôle du
traffic aérien, système d’exploitation)
Les composants défectueux doivent être réparés
Nécessité de reconfigurer le groupe des processeurs actifs
Consensus : spécification Terminaison : tout processus non
défaillant décide une valeur Accord : deux processus non
défaillants ne décident pas deux valeurs différentes
Non-trivialité : si les valeurs initiales des processus non défaillants sont égales, c’est la seule valeur de décision possible
Consensus : résultat d’impossibilité Il n’existe pas d’algorithme
résolvant le consensus dans un système asynchrone où les défaillances se réduisent à une seule panne « crash »
Contourner le résultat d’impossibilité Introduire des hypothèses de
synchronisme partiel Détecteurs de défaillances Solutions probabilistes
Les détecteurs de défaillances Chandra et Toueg (1996)
RéseauRéseau
Oracle
Oracle
P en panne?
P en panne?
Peut-être!
Peut-être!
Les détecteurs de défaillances Défaillances de type « crash » Un détecteur de défaillances est
un module qui fournit une liste de processus suspectés de crash
Détecteur le plus faible pour résoudre le consensus : il existe un instant à partir duquel il existe un processus correct qui n’est jamais suspecté
Auto-stabilisation
Temps
Etats
Etats légitimes
Défaillances
Auto-stabilisation
Temps
Etats
Etats légitimes
Défaillances
Auto-stabilisation : le cas du token ring
Chaque processus possède une seule variable de type {0, 1, 2, 3, 4, 5}
4
3
0
3
0
5
Auto-stabilisation : le cas du token ring
4
3
0
3
0
5
5
3
0
3
0
5
Auto-stabilisation : le cas du token ring
5
3
0
3
0
5
5
5
0
3
0
5
5
5
0
3
3
5
Auto-stabilisation : le cas du token ring
5
5
0
3
3
5
5
5
0
5
3
5
5
5
0
5
5
5
Auto-stabilisation : le cas du token ring
5
5
0
5
5
5
5
5
5
5
5
5
5
5
5
5
5
0
Avantages de l’auto-stabilisation (1) Pas besoin d’initialisation Adaptée par nature aux réseaux
dynamiques Pas besoin de reset ni d’intervention
extérieure pas de centralisation Très faible surcoût en phase stabilisée :
les échanges sont purement locaux Tolérance suffisante pour les applications
non critiques
Avantages de l’auto-stabilisation (2) Pas de diffusions coûteuses Solutions à mémoire bornée Solutions time-adaptive Technique éprouvée et
incontournable La formalisation permet d’obtenir
des outils génériques qui simplifient la programmation
Conclusion (1) Deux aspects critiques des
systèmes répartis actuels : fiabilité et sécurité
Pour la fiabilité, deux approches : Réplication + consensus : coûteux, mais
les défaillances sont masquées Auto-stabilisation : moins coûteux, mais
la correction n’est pas garantie durant la phase de stabilisation
Conclusion (2)
La solution réside sans doute dans la complémentarité des deux approches (Cf. Projet de maison intelligente de Microsoft)
Il existe aussi d’autres techniques à base de points de reprise