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