Tolérances de pannes. Stéphane Frénot -MID - V Part I - Pannes 1

Transcription

1 Tolérances de pannes Stéphane Frénot -MID - V Part I - Pannes 1

2 Introduction Concepts de base Résilience de processus Communications client-serveur fiable Communication de groupes fiable Validation distribuée (Distributed Commit) Reprise sur pannes Stéphane Frénot -MID - V Part I - Pannes 2

3 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 Stéphane Frénot -MID - V Part I - Pannes 3

4 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 Stéphane Frénot -MID - V Part I - Pannes 4

5 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. Stéphane Frénot -MID - V Part I - Pannes 5

6 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. Stéphane Frénot -MID - V Part I - Pannes 6

7 Classification des systèmes tolérant Type Indisponibilité (minutes par an) % disponibilité Classe Unmanaged (34 jours, 17 heures et 20 min) 90% 1 Managed (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 minutes. Stéphane Frénot -MID - V Part I - Pannes 7

8 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 Stéphane Frénot -MID - V Part I - Pannes 8

9 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 Stéphane Frénot -MID - V Part I - Pannes 9

10 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 Stéphane Frénot -MID - V Part I - Pannes 10

11 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 Stéphane Frénot -MID - V Part I - Pannes 11

12 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 a 2 b 1 b 3 Il faut 2k+1 membres pour absorber les k fautifs Modèle de résistance aux Pannes Bizanthines a 2 a 1 3 b Stéphane Frénot -MID - V Part I - Pannes 12

13 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 Stéphane Frénot -MID - V Part I - Pannes 13

14 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 Stéphane Frénot -MID - V Part I - Pannes 14

15 RPC fiable (2/3) [3] Les crashes serveur sont plus durs à gérer. Car on ne sais pas se qui s'est passé Req Rép Serveur Réception Exécution Réponse Req Rép Serveur Réception Exécution Crash Req Rép Serveur Réception Crash 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 Stéphane Frénot -MID - V Part I - Pannes 15

16 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) Stéphane Frénot -MID - V Part I - Pannes 16

17 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) Stéphane Frénot -MID - V Part I - Pannes 17

18 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 Stéphane Frénot -MID - V Part I - Pannes 18

19 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? Stéphane Frénot -MID - V Part I - Pannes 19

20 Multicast fiable d'échelle : solution hiérarchique Solution de base : Construire un canal de nack hierarchique. R C C S racine Quel est le pb avec cette solution? Optimisation possible? Stéphane Frénot -MID - V Part I - Pannes 20

21 Multicast atomique Idée : Former un multicast fiable en présence de pannes. On raisonne sur les notions de groupes précédentes temps P1 P2 P3 P4 G={P1, P2, P3, P4} G={P1, P2, P4} G={P1, P2, P3, P4} Garanties : Un message n'est délivré qu'aux membres non fautifs. Tous les membres doivent être d'accord sur les appartenances au groupe Mot-clé : Multicast virtuellement synchrone Stéphane Frénot -MID - V Part I - Pannes 21

22 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 synchrone virtuellement Stéphane Frénot -MID - V Part I - Pannes 22

23 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. Stéphane Frénot -MID - V Part I - Pannes 23

24 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] Stéphane Frénot -MID - V Part I - Pannes 24

25 Implantation du Synchronisme virtuel (2/3) Remarque : remote[p][q] montre ce que P sait des Q (RCV) 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 min Dès que tous les messages d'un process en panne sont livrés, le process peut être retiré de la vue locale Stéphane Frénot -MID - V Part I - Pannes 25

26 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 Stéphane Frénot -MID - V Part I - Pannes 26

27 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é)? Stéphane Frénot -MID - V Part I - Pannes 27

28 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 Stéphane Frénot -MID - V Part I - Pannes 28

29 Two-Phase Commit (2/2) Commit Vote-req COORDINATEUR INIT Vote-abort WAIT Global-abort ABORT Vote-Req Vote-abort Global-abort ACK ABORT PARTICIPANT Time-out Vote-commit Global-commit COMMIT INIT Vote-Req Vote-commit READY Global-vote ACK COMMIT Stéphane Frénot -MID - V Part I - Pannes 29

30 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 pour conserver les résultats et simplifier la reprise en cas de panne Stéphane Frénot -MID - V Part I - Pannes 30

31 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 Stéphane Frénot -MID - V Part I - Pannes 31

32 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 Stéphane Frénot -MID - V Part I - Pannes 32

33 Three-Phase Commit (2/2) Commit Vote-req COORDINATEUR INIT Vote-abort WAIT Global-abort ABORT Vote-Req Vote-abort Global-abort ACK ABORT PARTICIPANT Time-out Vote-commit Prepare-commit PRECOMMIT INIT Vote-Req Vote-commit READY Prepare-commit Ready-commit PRECOMMIT Ready-Commit Global-commit Ready-Commit ACK COMMIT COMMIT Stéphane Frénot -MID - V Part I - Pannes 33

34 3PC Participants en fautes Élément de base : un participant peut-il trouver quoi faire après un crash (etat Ready ou pre-commit), même si d'autres participants ou le coordinateur est en panne? Idée : Les participants et le coordinateur ne différent jamais de plus d'une transition d'état Observation : Quand un participant est dans l'état pre-commit, il peut toujours valider (mais il n'a pas le droit de le faire par rapport aux autres processus en panne) Observation : On peut avoir besoin de réélire un nouveau coordinateur pour réémettre le commit final Stéphane Frénot -MID - V Part I - Pannes 34

35 Répartition d'une application Application de Présentation Middleware Implicite Application de traitement Application de Données Système d'exploitation Données Middleware Explicite RMI Système d'exploitation Middleware Système SGFdistribué Données Système d'exploitation Données Stéphane Frénot -MID - V Part I - Pannes 35