Les détecteurs de défaillances

1. Les détecteurs de défaillances

2. + sévères 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 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 dp valeur de décision de p, vp valeur initiale de p, • Accord : si p et q décident, ils décident de la même valeur dp =dq, • 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. Mauvaise nouvelle...

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: Détecteur de défaillances

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 l’union!

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

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

16. W 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: • Il existe un algo avec D qui permet de résoudre P • S’il existe un algo qui résoud P avec un FD D’, D’ permet de construire D

18. Détecteur de défaillancesW • W est le plus faible détcteur de défaillance pour le consensus en présence d’une majorité de correct

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

20. Consensus avec W • Principes: • S’adresser au leader et proposer sa valeur • Le leader s’adresse à tous et propose une valeur • Les processus s’engagent sur cette valeur et informent le leader • Si suffisamment (t<n/2, registres, S, S) d’engagement le leader décide + Quelques complications techniques

21. S • L’intersection des sorties de S pour p et q à deux instants est non vide • + completude • S plus faible détecteurs de défaillance pour un registre • W + S 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? Modèles partiellement synchrones

23. Partiellement synchrone… Propriétés sur les liens de communication: • Il existe une borne δ sur les délais de communications • Cette borne n’est assurée qu’ultimement • Cette borne n’est valable que pour certains processus • Cette borne n’est pas connue • … Propriétés du réseau

24. Oméga… • Reprenons notre détecteur de défaillances W…

25. Réalisation de W • 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: 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 d ) Ultimement parfait àP

27. 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 W est le processus de cette liste ayant la plus petite identité (réalise W )

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 d et t tel que pour tout t’>t si p envoie m à q au temps t’ alors q reçoit m au plus tard en t’’+d • Équité: • si p envoie infiniment souvent un message d’un 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 l’intégrité • S : il existe au moins une source ultime • S+ : il existe au moins une source ultime et un hub.

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

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

34. 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 qu’un message arrive avant l’expiration du réveil à h+D, sinon q suspecte p. • Si le lien de p à q est ponctuel en D à partir de t, après t, q ne suspectera plus p • Si p est mort, q suspectera p pour toujours

35. Techniques de bases… • Si le lien n’est 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é. • S’il existe une borne d telle que, à partir du tempst, tous les messages de p arrivent en d, le timeout n’est plus jamais dépassé

36. 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

37. 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

38. Accusation résultats: • Si p est incorrect le compteur des accusations de p est non borné, • Si p est une source ultime, le compteur d’accusations de p est borné, • Si les compteurs d’accusation 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.

39. Mais… • Le graphe n’est pas fortement connexe: on ne peut pas diffuser de façon fiable les compteurs d’accusations! Perdu?!

40. 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)

41. Solution • Les messages ALIVE de p contiennent les valeurs du compteurs d’accusations 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)

42. 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 l’accusent infiniment souvent) • Et donc tout le monde aura la valeur de son compteur d’accusation (car les sources communiquent bien) • La source ultime communique bien avec elle-même. Au moins un compteur d’accusations est borné.

43. Efficace pour la communication • Le problème de l’algorithme précédent est que tous les processeurs communiquent toujours les n2 liens sont utilisés • Communication efficace: ultimement un seul processus envoie des messages (on ne peut pas mieux)

44. Impossibilité • Résultat: Il n’existe pas d’implémentation efficace pour la communication dans les systèmes S. • Preuve standard par indistingabilité.

45. 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 s’il pense être le leader. • Problème: si p ne reçoit rien de q cela ne prouve pas que q ne communique pas bien…

46. Solution • Accusations et compteur d’accusation comme avant, • Mais on n’accuse que les candidats • Les candidats: les processus dont on sait qu’ils 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

47. Solution • Le leader pour p est le meilleur des candidats (plus petit compteur d’accusation). • 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é quelqu’un de meilleur que lui) il augmente sa phase • Accuser uniquement les candidats • La première fois qu’un candidat dépasse les délais on l’accuse (une seule fois par phase)

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

49. Extensions… • Si on n’exige 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 n’est pas connue

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