Tolérances de pannes
Introduction
• Concepts de base
• Résilience de processus
• Communications client-serveur fiable
• Communication de groupes fiable
• Validation distribuée (Distributed Commit)
• Reprise sur pannes
Sureté de fonctionnement (Dependability)
• Dependability : Un composant fournit des services à un client. Pour fournir un service le composant repose sur d'autres services. Il en dépend
• Formellement : Un composant C dépend de C* si la bonne exécution de C dépend de la bonne exécution de C*
• Propriétés de la dépendabilité : – Disponibilité : Prêt à être utilisé
– Confiance : Continuité du service fournit – Garantie : Peu de probabilité de catastrophe
– Maintenabilité : Facilité qu'a un système en panne d'être réparé
– Confidentialité : Garanties que le composant conserve ses information – Intégrité : Garanties que le composant n'est pas modifié
• Remarque : En distribué, un composant = processus ou canal de comm
Terminologie
• Panne : Quand un composant n'est pas conforme à sa spécification, il est en panne
• Erreur : L'élément du composant qui amène la panne
• Faute : La cause de l'erreur
• Prévention de faute : Prévient l'occurrence d'une faute
• Tolérance de panne : Conception d'un composant afin qu'il réponde à ses spécification même en présence de fautes (masque leur présence)
• Retraits de fautes : Réduction de la présence, du nombre ou de la gravité des fautes
• Prévision de fautes : Estimation du nombre, des insidences futures et
des conséquences des fautes
Modèles de panne
• panne par omission : des messages sont perdus en entrée ou en sortie ou les deux.
Elle est considérée comme une panne temporelle de durée infinie ;
• panne franche (« fail stop ») : soit le système fonctionne normalement (les résultats sont corrects), soit il ne fait rien. Il s'agit du type de panne le plus simple ;
• panne temporelle : le temps de réponse du système dépasse les exigences des spécifications ;
• panne byzantine : le système donne des résultats aléatoires.
Classification des systèmes tolérant aux pannes
• 7 classes de :
– non prise en compte (système disponible 90% du temps, et donc indisponible plus d'un mois par an),
– à ultra disponible (disponible 99,99999% du temps et donc indisponible seulement 3 secondes par an)
• nombre de « 9 » dans le pourcentage de temps durant lequel les systèmes
de la classe sont disponibles.
Classification des systèmes tolérant
Type Indisponibilité (minutes par an) % disponibilité Classe Unmanaged 50.000 (34 jours, 17 heures et 20 min) 90% 1
Managed 5.000 (3 jours, 11 heures et 20 min) 99% 2
Well managed 500 (8 heures 20 minutes) 99,9% 3
Fault tolerance 50 (un peu moins d'une heure) 99,99% 4
High availability 5 minutes 99,999% 5
Very high availability 0,5 (30 secondes) 99,9999% 6 Ultra high availability 0,05 (3 secondes) 99,99999% 7
• NB : Une année dure 8760 heures, soit 525.600 minutes.
Pannes de crash
• Problème : Pas de différence entre un composant en panne ou un composant très lent
• Exemple : Pour un client qui ne reçoit pas une réponse d'un serveur – Le serveur présente-t'il une panne temporelle ou d'émission ? – Le canal de communication est t-il en faute ? (crash, timing,
omission)
• Panne-Silencieuse (Fial-Silent) : Le composant présente des pannes d'omission ou de crash; Le clietn ne peux pas distinguer
• Panne-Arrêt (Fail-Stop) : Le composant présente des pannes mais elles sont détectables (annonce ou time-out)
• Panne-Sauve (Fail-Safe) : Le composant présente des pannes mais ne
cause pas de problème
Résilience de processus
* en écologie, la résilience est la capacité d'un écosystème ou d'une espèce à récupérer un fonctionnement et/ ou un développement normal après avoir subi un traumatisme ;
* en physique, la résilience est la résistance d'un matériau à un choc ;
* en psychologie, la résilience est un phénomène psychologique consistant à prendre acte de son traumatisme pour ne plus vivre dans la dépression.
* Dans le domaine de la gouvernance, de la gestion du risque et du social, la résilience
communautaire associe les approches précédentes en s'intéressant au groupe et au collectif plus qu'à l'individu isolé.
* En informatique, la résilience est la capacité d'un système ou d'une architecture réseau à continuer de fonctionner en cas de panne.
* Dans le jeu World of Warcraft, la résilience diminue les probabilités de subir des coups critiques, et réduit la quantité de dégâts subis en cas de coups critiques.
==> Une seule solution faire de la REDONDANCE, redondance temporelle, redondance spatiale
Résilience de processus (2)
• On se protège en répliquant et en distribuant les calculs dans un groupe
Groupe plat Groupe hiérarchique
Coordinateur
Travailleur
Pas tolérant, ne passe pas à l'échelle
Groupes et masquage de panne (1/3)
• Quand un groupe peut masquer k pannes concurrentes, il est k-fautes tolérant
• Question : Quelle doit être la taille d'un groupe k-fautes tolérant ?
– Si on a des pannes de crash/performances, il faut k+1 membres pour résister à k pannes
– Si on a des altérations et qu'on a un mécanisme de vote pour connaître les fautifs, il faut 2k+1 membres
• Suppositions : Tous les membres sont identiques et les
processus font les mêmes sorties
Groupes et Masquage de panne (2/3)
• Supposition : les membres du groupe sont différents
• Problème : les membres qui ne sont pas en erreur doivent se mettre d'accord sur une valeur commune
• Il faut 2k+1 membres pour absorber les k fautifs
• Modèle de résistance aux Pannes Bizanthines
2
1 3
2
1 3
b a b
a a a
b
Communication fiable
• Jusqu'ici : résistance de processus (groupes). Comment avoir un canal de communication fiable
• Détection d'erreur :
– Trames des paquets pour la détection d'erreur de bits – Numérotation de trames
• Correction d'erreur :
– Ajout de redondance
– Retransmission des paquets en erreur ou des N derniers
• Remarque : On est dans le domaine du point-à-point
RPC fiable (1/3)
• Problèmes :
– 1 Le client ne peut pas localiser le serveur – 2 La requête cliente est perdue
– 3 Le serveur crash
– 4 La réponse du serveur est perdue – 5 Le client crashe
[1] Simple : on notifie le client
[2] On renvoie la requête
RPC fiable (2/3)
• [3] Les crashes serveur sont plus durs à gérer. Car on ne sais pas se qui s'est passé
• Problème : On doit décider de ce qu'on attend du serveur
– Sémantique d'au moins 1 : Le serveur garanti qu'une opération est réalisée au moins 1 fois
– Sémantique d'au plus 1 : Le serveur garanti qu'une opération est exécutée au plus 1 fois
Réception Exécution Réponse
Req Rép
Serveur
Réception Exécution Crash
Req Rép
Serveur
Réception Crash
Req Rép
Serveur
RPC fiables (3/3)
• 4 On ne peut pas la distinguer du 3. On ne sait donc pas si le serveur à exécuté la requête
– Pas de solutions générale. Une première approche est d'avoir des opérations idempotentes
• 5 Problème : le serveur réalise un calcul et bloque des ressources pour rien (calcul orphelin)
– Le processus orphelin est à la charge du client (reboot)
– Le processus orphelin est à la charge du réseau (Annonce d'une nouvelle époque) – Le processus orphelin est à la charge du serveur (Le processus est borné par un
time-out)
Multicast fiables (1/2)
• Modèle: Canal multicast c avec 2 groupes
– Le groupe d'envoi SND(c)
– Le groupe de réception RCV(c)
• Fiabilité simple : Si un process P de RCV(p) est vivant au moment de l'envoie d'un message m, et
que P ne quitte pas le groupe, m doit être envoyé à P
• Multicast Atomique problème : Comment garantir
que m est transmis à P que si m est envoyé à tous les
membres de RCV(p)
Multicast fiable (2/2)
• Remarque : Si on se place dans un réseau local, le multicast fiable c'est « facile »
• Principe : L'émetteur enregistre le fait qu'il envoie son message
– Si P envoie m, il stocke l'info dans un tampon historique – Chaque receveur ack/nack la (mauvaise)réception de m
– P supprime le message du buffeur quand tout le monde a ack
• Ca ne passe pas l'échelle
Multicast fiable d'échelle : suppression de retransmission
• Idée : un process ne renvoie pas son NACK s'il voit que d'autres process le font déja.
• Supposition :
– Tous les receveurs écoutent le même canal de retour
– Le process en nack planifie aléatoirement une réponse, et la supprime s'il voit entre-temps un message nack
• Question : Pourquoi l'aléa est-t'il important ?
Multicast fiable d'échelle : solution hiérarchique
• Solution de base : Construire un canal de nack hierarchique.
• Quel est le pb avec cette solution ?
• Optimisation possible ?
racine
C R
S C
Multicast atomique
• Idée : Former un multicast fiable en présence de pannes. On raisonne sur les notions de groupes précédentes
• Garanties : Un message n'est délivré qu'aux membres non fautifs.
Tous les membres doivent être d'accord sur les appartenances au groupe
P1 P2 P3 P4
temps
G={P1, P2, P3, P4} G={P1, P2, P4} G={P1, P2, P3, P4}
Synchronisme virtuel (1/2)
• Principe : on fait des vues V ⊆ RVC x( ) ∪ SND c( )
• Les processus sont ajoutés ou supprimés en effectuant des changement de vues vers V*; un changement de vue est réalisé localement par chaque
∈ ∩ * P V V
– Pour chaque état consistent il n'existe qu'une vue unique sur laquelle tous les membres sont d'accord. Note : cela implique que les membres qui ne
sont pas en panne voit les changement de groupes dans le même ordre – Si un message m est envoyé à la vue V avant son changement vers V *.
Alors soit tous les processus membre du changement on reçut le message ou aucun. Note : tous les membre qui ne sont pas en erreur d'une même
vue voient le même ensemble de messages
– Un message envoie dans une vue V ne peut être délivré qu'aux processus
de V et doit être supprimé dans les vues suivante
• Un algorithme multicast fiable satisfaisant ces points est virtuellement synchrone
Synchronisme virtuel
• Un émetteur vers une vue V ne doit pas nécessairement appartenir à la vue
• Si un émetteur S∈ V crashe son message multicast m est vidé avant de,
.
retirer S du groupe m ne sera jamais livré après que S ai quitté le groupe
– Note : Les messages de S peuvent être livrés aux membres de V
avant qu'ils ne se mettent d'accord sur un nouveau groupe
• Si un receveur P tombe les messages peuvent être retrouvés car on ,
.
connait tous les messages d'une vue On peut cependant décider de ne
-{ }
livrer m qu'aux membres V P
• Commentaires : Les messages peuvent arriver dans un ordre
quelconque La seule contrainte est que les messages soient livrés sur. un groupe clairement établi.
Implantation du Synchronisme virtuel (1/3)
• La vue courante est connue des participants par émission d'une liste dest[P]
• Si P∈dest Q alors Q∈[ ] dest P[ ]
• Les messages reçus par P sont mis en journal dans queue P [ ]
• Si P tombe la vue de groupe doit changer mais pas avant que l'ensemble , ,
des messages de P sont purgés
• Chaque message envoyé reçoit une estampille horaire
• On suppose une émission de type FIFO le dernier message estampille la ; (
) [ ][ ]
plus grande de Q vers P est enregistré dans rcvd P Q
• Le vecteur rcvd P[ ][] est envoyé à dest P comme contrôle des messages [ ]
• Chaque process enregistre rcvd Q[ ][] dans remote P Q[ ][ ]
Implantation du Synchronisme virtuel (2/3)
• Remarque : remote[P][Q] montre ce que P sait des messages arrivés à Q
• Un message est stable
si tous les Q dest[P] l'on eu
• Un message stable est
transmis à la couche supérieure
– Les messages sont causals
• Dès que tous les messages d'un process en panne sont livrés, le process peut être retiré de la vue locale
1 2 3 1 5
2 2 2 2 4
3 3 1 4 5
4 4 2 2 4
min 2 1 1 4
Q (RCV)
Implantation du Synchronisme virtuel (3/3)
• Question : Si P tombe et que tous ses messages
transmis aux membres actifs de la vue n'ont pas été envoyés ?
• Solution : Choisir un coordinateur qui connait tous les messages de P, pour les repropager en cas de
panne
• Remarque : Une panne d'un membre est de type
Fail-Stop. Une fois la panne détectée l'annonce de
nouvelle vue est propagée à tous les membres. Tous
les messages de la vue précédente doivent être livrés
Validation distribuée
• Two Phase Commit : Commit à 2 phase, Validation en 2 phases
• Three-Phase Commit
Fondamentaux : Soit une exécution répartie entre
groupes de processus, comment garantir que soit
tous les processus valident le résultat final soit
aucun (atomicité) ?
2PC (1/2)
• Modèle : Le client qui lance la transaction est le
coordinateur; les processus qui doivent valider sont les participants
Phase 1a : Coordinateur envoie REQ_VOTE aux participants (phase de pre-écriture) Phase 1b: Sur réception d'un REQ_VOTE, un participant renvoie OUI ou NON au
coordinateur. S'il envoie NON, il annule son exécution locale
Phase 2a: Le coordinateur collecte tous les votes; si tout est OUI il envoie un ordre COMMIT à tous les membres sinon il envoie un ABORT
Phase 2b: Chaque participant attend son COMMIT ou son ABORT et gère en conséquence
Two-Phase Commit (2/2)
COORDINATEUR
INIT
WAIT
Time-out
ABORT COMMIT
Commit Vote-req
Vote-abort
Global-abort Vote-commit Global-commit
PARTICIPANT
INIT
READY
ABORT COMMIT
Vote-Req
Vote-abort Vote-Req
Vote-commit Global-abort
ACK Global-vote
ACK
2PC – Fautes d'un participant
Observation : On considère une panne d'un participant dans les différents états possibles, et le rétablissement dans cet état
• État initial : Pas de problème, le participant n'a pas perçu le début du protocole, le coordinateur ABORT sur le time-out
• État prêt : Le participant est en attente du commit/abort. Tout est bloqué au niveau du participant. A la reprise, un participant doit apprendre l'état que la transaction a prise
=> on lit le journal du coordinateur
• État abandon : L'idée est de n'avoir que des opération idempotentes (répétable dans le temps sans modification, ex ?). Le principe est de récupérer un état temporaire de sauvegarde
• État commit : Pareil, on se base sur une opération idempotente. On valide l'état temporaire (working space)
Remarque : Le secret du commit distribué est d'avoir des espace temporaires de travail
2PC - Fautes du coordinateur
Observation : La réponse du coordinateur peut être inconnue pendant longtemps (voir même perdue)
Alternative : On ajoute un time-out à un participant sur la réponse du coordinateur; lorsqu'il tombe le participant demande aux autres participants la réponse
Question : un participant peut il ne pas réussir à trouver l'information ?
Observation : Le problème fondamental est qu'un
participant ne peut pas faire de décision locale. Il dépend
d'autre processus éventuellement en panne
3PC - (1/2)
Phase 1a : Coordinateur envoie REQ_VOTE aux participants (phase de pre- écriture)
Phase 1b: Sur réception d'un REQ_VOTE, un participant renvoie OUI ou NON au coordinateur. S'il envoie NON, il annule son exécution locale
Phase 2a: Le coordinateur collecte tous les votes; si tout est OUI il envoie un ordre PREPARE à tous les membres sinon il envoie un ABORT, et s'arrête Phase 2b: Chaque participant attend son PREPARE ou son ABORT (dans ce cas
il s'arrête ici)
Phase 3a: (Prepare to commit) Le coordinateur attend que tous les participants aient acquitté réception du PREPARE, puis envoie un COMMIT à tous
Phase 3b: (Prepare to commit) Les participants attendent le COMMIT
Three-Phase Commit (2/2)
COORDINATEUR
INIT
WAIT
Time-out
ABORT PRECOMMIT
Commit Vote-req
Vote-abort
Global-abort Vote-commit Prepare-commit
PARTICIPANT
INIT
READY
ABORT PRECOMMIT
Vote-Req
Vote-abort Vote-Req
Vote-commit Global-abort
ACK Prepare-commit
Ready-commit
COMMIT
Ready-Commit Global-commit
COMMIT
Ready-Commit ACK
