La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

Les détecteurs de défaillances. Défaillances ? Processeurs: – Pannes définitives – Erreurs d'émission – Erreurs de réception – Erreurs de réception et.

Présentations similaires


Présentation au sujet: "Les détecteurs de défaillances. Défaillances ? Processeurs: – Pannes définitives – Erreurs d'émission – Erreurs de réception – Erreurs de réception et."— Transcription de la présentation:

1 Les détecteurs de défaillances

2 Défaillances ? Processeurs: – Pannes définitives – Erreurs d'émission – Erreurs de réception – Erreurs de réception et d'émission – Ne pas suivre son code + sévères n nombre de processus t le nombre de pannes toléré es Attention: p est correct s'il ne commet jamais de défaillances

3 Et le réseau? En général: – Communication asynchrone point à point – Graphe complet de communication – Pas de pertes de messages …

4 Consensus d p valeur de décision de p, v p valeur initiale de p, Accord : si p et q décident, ils décident de la même valeur d p =d q, Intégrité : la valeur décidée est une des valeurs initiales Terminaison : tout processus correct décidera un jour.

5 Impossibilité du consensus FLP85: Le consensus est impossible à réaliser dans un système asynchrone dès qu'au moins un processus peut tomber en panne définitive.

6 Que faire? le consensus est fondamental pour la résistance aux défaillances, les systèmes sont généralement asynchrones, dans tous les cas, il est préférable de développer une algorithmique asynchrone.

7 Une solution… Ajouter au système asynchrone ce qui lui manque pour résoudre le consensus:

8 Oracles Ajoutent "juste" ce qu'il faut pour résoudre ce que l'on ne pourrait pas sinon. Permettent de rester en asynchrone. Ne dépendent que des pannes. Définition et spécification rigoureuses. D'un point de vue pratique, un oracle est une primitive utilisée par les algorithmes.

9 Oracles Détecteur de défaillances : donne à chaque processus des informations qui ne sont pas toujours fiables sur les pannes des autres processus.

10 Détecteur de défaillances Des listes de suspects. Propriétés: Complétude : un processus en panne finira par être suspecté Exactitude forte : aucun processus correct ne sera jamais suspecté Exactitude faible : il existe un processus correct qui ne sera jamais suspecté Exactitude forte ultime Exactitude faible ultime

11 Détecteurs de défaillances Parfait (P) : information exacte (complétude et exactitude forte) Fort (S) : complétude et exactitude faible Ultimement P ( P) : un jour les informations exactes Ultimement S ( S) : un jour complétude et exactitude faible

12 Comparaison des détecteurs de défaillances… Réduction: – D est plus faible que D si D peut être implémenté (algorithme distribué) en utilisant D

13 Réduction : exemple Exemple: Complétude faible : tout processus incorrect est soupçonné par au moins un processus correct Complétude forte : tout processus incorrect est soupçonné par tout processus correct Réduction: échanger les listes de suspects et faire lunion!

14 Détecteur de défaillances Détecteur de défaillances : un détecteur de défaillances dont la sortie est un unique processus supposé être correct: q est la sortie de à linstant : p fait confiance à q à linstant assure : un jour tous les processus corrects feront confiance au même processus correct.

15 Une autre interprétation… Une autre interprétation… Élection ultime de leader: La sortie de est le leader actuel assure que, un jour: – Tous les processus ont le même leader – Le leader est un processus correct

16 et S sont équivalents

17 Le plus faible… Déterminer quel est le plus faible détecteur de défaillances permettant de résoudre un problème. D est le plus faible pour P: 1. Il existe un algo avec D qui permet de résoudre P 2. Sil existe un algo qui résoud P avec un FD D, D permet de construire D

18 Détecteur de défaillances Détecteur de défaillances est le plus faible détcteur de défaillance pour le consensus en présence dune majorité de correct

19 En fait ce résultat est plus fort, il montre que quelque soit lensemble dhistoires de pannes (failure pattern) considéré, si on peut réaliser le consensus avec un détecteur de défaillances alors on réaliser (choisir un leader ultime)

20 Consensus avec Consensus avec Principes: – Sadresser au leader et proposer sa valeur – Le leader sadresse à tous et propose une valeur – Les processus sengagent sur cette valeur et informent le leader – Si suffisamment (t

21 Lintersection des sorties de pour p et q à deux instants est non vide + completude plus faible détecteurs de défaillance pour un registre + plus faible FD pour le consensus (quelquesoit le nombre de pannes)

22 Détecteur de défaillances Permettent de résoudre le consensus Ceux qui le permettent ne peuvent être réalisés en asynchrone (FLP!) Comment les implémenter?

23 Partiellement synchrone… Propriétés sur les liens de communication: – Il existe une borne δ sur les délais de communications – Cette borne nest assurée quultimement – Cette borne nest valable que pour certains processus – Cette borne nest pas connue – …

24 Oméga… Reprenons notre détecteur de défaillances …

25 Réalisation de Réalisation de Implémentation dans un modèle partiellement synchrone – Efficacité (pas trop de messages) – hypothéses « faibles » sur le système partiellement synchrone

26 Implementation simple: Implementation simple: En supposant : uniquement des crashs ultimement tous les liens de communications sont ponctuels (il existe un instant τ à partir duquel tous les messages sont reçus en au plus ) Ultimement parfait P

27 Implementation simple: Implementation simple: Chaque processus envoie à intervalle régulier un message OK à tous Chaque processus maintient la liste des processus desquels il a reçu un message OK récemment (réalise P) La sortie de est le processus de cette liste ayant la plus petite identité (réalise )

28 Liens de communication Propriétés possibles pour un lien de p à q: Intégrité: – (les messages sont vraiment des messages) toujours supposée Ponctualité ultime: – Il existe et tel que pour tout > si p envoie m à q au temps t alors q reçoit m au plus tard en + Équité: – si p envoie infiniment souvent un message dun certain type à q alors, q reçoit une infinité de messages de ce type.

29 Sources et hubs p est une source ultime si et seulement si p est correct et tous les liens sortant de p sont ultimement ponctuels p est un hub si et seulement si p est correct et tous les liens entrants et sortants sont équitables.

30 Systèmes S -, S et S + S - : aucune hypothèse sauf lintégrité S : il existe au moins une source ultime S + : il existe au moins une source ultime et un hub.

31 Remarques La borne pour la ponctualité est inconnue des processus, Avec S - tous les messages peuvent se perdre… (rien à espérer) Avec S le graphe de communication nest pas fortement connexe… Avec S, S + les processus ne connaissent pas la source ultime ou le hub.

32 dans un système S dans un système S Au moins une source ultime, mais le graphe de communication nest pas nécessairement fortement connexe Arriver à un accord ultime sur un leader (1) Tous les corrects ont le même leader (2) Ce leader est un processus correct Possible?

33 Surveiller et accuser

34

35 Surveiller, techniques de bases… Suspecter les processeurs qui communiquent mal: – Si le lien de p à q est ponctuel en D, et q connaît D: Facile: p émet régulièrement ALIVE, tous les h, q remonte un réveil avec timeout h+D, à chaque réception et vérifie quun message arrive avant lexpiration du réveil à h+D, sinon q suspecte p. – Si le lien de p à q est ponctuel en D à partir de, après, q ne suspectera plus p – Si p est mort, q suspectera p pour toujours

36 Techniques de bases… Si le lien nest pas immédiatement ponctuel mais seulement ultimement ponctuel? – p émet régulièrement, et q augmente son réveil chaque fois que le timeout est dépassé. – Sil existe une borne d telle que, à partir du temps, tous les messages de p arrivent en d, le timeout nest plus jamais dépassé

37 Résultat: Si p est une source ultime, p ne sera donc plus soupçonné par personne, Si p est mort il sera soupçonné par tous Mais comment avoir un leader? Le même pour tous Le garder pour toujours

38 Techniques de bases: accusation Quand q constate que p a dépassé le délai il accuse p mais lui laisse une chance : il augmente son timeout pour p. Associer à chaque processus un compteur des accusations: – À chaque fois que p est accusé, on augmente le compteur de p. – « diffuser » le compteur des accusations

39 Accusation résultats: Si p est incorrect le compteur des accusations de p est non borné, Si p est une source ultime, le compteur daccusations de p est borné, Si les compteurs daccusation sont diffusés de façon fiables, ultimement tous les compteurs bornés atteignent leur borne! Choisir le moins pourri: Le leader est le processus ayant le plus petit compteur.

40 Mais… Le graphe nest pas fortement connexe: on ne peut pas diffuser de façon fiable les compteurs daccusations! Perdu?!

41 Non, ça peut marcher! Une source ultime communique bien ultimement avec tous. Remarques: Si une source ultime accuse p, p le saura (tout le monde aussi si le source le dit). Si une source ultime communique bien avec q, elle peut le faire savoir (relais)

42 Solution Les messages ALIVE de p contiennent les valeurs du compteurs daccusations de p Relayer une fois des messages ALIVE quand ils sont dans les délais S1: ceux avec qui on communique bien directement, accusation sinon S2: ceux avec qui on communique bien indirectement (p a reçu de q dans les délais un message de relais de q pour r)

43 Pourquoi? Si p est mort, il ne peut pas être leader (son compteur est non borné) Si le compteur de p est borné alors il communique bien (au moins) avec les sources ultimes (sinon elles laccusent infiniment souvent) Et donc tout le monde aura la valeur de son compteur daccusation (car les sources communiquent bien) La source ultime communique bien avec elle- même. Au moins un compteur daccusations est borné.

44 Efficace pour la communication Le problème de lalgorithme précédent est que tous les processeurs communiquent toujours les n 2 liens sont utilisés Communication efficace: ultimement un seul processus envoie des messages (on ne peut pas mieux)

45 Impossibilité Résultat: Il nexiste pas dimplémentation efficace pour la communication dans les systèmes S. Preuve standard par indistingabilité.

46 Efficace pour la communication dans S + S + : au moins un hub et au moins une source ultime. Principe: un processus német des messages ALIVE que sil pense être le leader. Problème: si p ne reçoit rien de q cela ne prouve pas que q ne communique pas bien…

47 Solution Accusations et compteur daccusation comme avant, Mais on naccuse que les candidats Les candidats: les processus dont on sait quils ont essayé dêtre leader (ont émis des messages ALIVE) – p est candidat pour q tant que q reçoit dans les délais des messages ALIVE – p se considère toujours comme candidat

48 Solution Le leader pour p est le meilleur des candidats (plus petit compteur daccusation). – Si p est son propre leader, il envoie des messages ALIVE régulièrement Phase et compteur: – Quand p est accusé il augmente son compteur – Quand p renonce (il a trouvé quelquun de meilleur que lui) il augmente sa phase Accuser uniquement les candidats – La première fois quun candidat dépasse les délais on laccuse (une seule fois par phase)

49 Bilan Conditions « minimales » de synchronie Algorithmes efficaces pour implémenter (avec conditions raisonnables) Tout est bon!

50 Extensions… Si on nexige plus que tous les liens issus de p soient ponctuels: Définition: p est une j-source: au moins j liens sortant de p sont ultimement ponctuels (si p est incorrect p est un n-source !) Attention: la borne nest pas connue

51 Extensions Résultat: (f nombre de fautes) – peut être implémenté si au il y a au moins une -f-source correcte. Attention: cette -f-source nest pas connue les liens peuvent perdre des messages – Si les liens sont fiables, peut être implémenté de façon efficace pour la communication.

52 Application Si t=1: – Pour implémenter il suffit davoir un seul lien ultimement ponctuel (ce qui est toujours réalisé si un processus est incorrect!!!) Étonnant?

53 Conclusion Détecteur de défaillances approche à la fois abstraite et pratique Un aperçu des méthodes et des résultats

54 Quelques pointeurs…. F.B.Schneider Implementation fault- tolerant services using the state machine approach: A tutorial ACM Computing Surveys 22(4) 90 Distributed Systems S.J Mullender editor, Addison-Wesley 93 N. Lynch Distributed Algorithms Morgan Kaufman 96

55 Quelques pointeurs Fischer, Lynch &Paterson: Impossibility of distributed consensus with one faulty processes JACM 32(2) 85 Dwork, Lynch & Stockmeyer Consensus in the presence of partial synchrony JACM 35(2) 88 Chandra & Toueg Unreliable failure detector for reliable distributed systems JACM 43(2) 96

56 Quelques pointeurs Chandra, Hadzilacos & Toueg The weakest failure detector for solving consensus JACM 43(4) 96 Delporte,Fauconnier, Guerraoui, Kouznetsov (DSN2002 –rapports internes)

57 Quelques pointeurs…. Aguilera, Delporte, Fauconnier, Toueg: Stable leader election DISC 2001

58 Conclusion… Détection de défaillances comme abstraction Détection de défaillances comme outil Implémentation des détections de défaillances Et le réseau ?


Télécharger ppt "Les détecteurs de défaillances. Défaillances ? Processeurs: – Pannes définitives – Erreurs d'émission – Erreurs de réception – Erreurs de réception et."

Présentations similaires


Annonces Google