Les détecteurs de défaillances

Présentation au sujet: "Les détecteurs de défaillances"— 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 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 Détecteur de défaillances
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. So begin with the definition of Omega. Generally, a failure detector gives to each process a list of suspected processes. A process in this list is suspected to be crashed, but perhaps it is not true. The failure detectors are then defined by the properties that these lists of suspected processes have. Here at each time t, the output of failure detector omega for some process p is a single process say q. We say that this process q is trusted, more precisely we will say that at time t, process p trusts process q. The main property of Omega is that eventually all correct processes trust the same process and this process is correct. (recall that correct means alive forever)

15 Une autre interprétation…
Élection ultime de leader: La sortie de W est le leader actuel W assure que, un jour: Tous les processus ont le même leader Le leader est un processus correct But, Omega can be thought as a leader election. The trusted process is considered to be the current leader. And omega ensures that eventually all processes have the same correct leader. More precisely, each process has a variable leader that holds the identity of a process (the presumed leader) or bottom. Omega ensures that eventually all processes will have the same process as value of this local variable. But be careful, this property is only eventually ensured. At time t, perhaps the value of this variable for some some process p can be for example, Bush, and at the same time, some other processes can have Gore as value. we never know if the value of this variable is really the true leader, we only know that eventually this variable will contain the name of the true leader (for example Bush) but we do not know when. This guarantee seems rather weak, but it is actually powerful.

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éfaillances W
W est le plus faible détcteur de défaillance pour le consensus en présence d’une majorité de correct Actually this kind of leader election can help to solve some tasks efficiently And this kind of leader election is powerful enough to solve consensus in asynchronous systems. There are many algorithms that use that kind of leader election (for example, in Paxos) and in some way some of classical algorithms like the rotating coordinator algorithm can be slightly improved and simplified using a leader election. Omega seems more powerful that Diamond S bu in fatc it is not true. Recall that Diamond S proposes to each process a list of trusted processes such that eventually this list contains only correct processes and such that at least one correct process is shared by all lists. So with omega we get trivially teh properties of Diamond S. For this, the list of trusted proceses is simply the presumed leader, it is eventually a correct process shared by all lists and this list contains eventually only correct processes (in fact a single). In fact, Omega is equivalent to the weakest failure detector to solve consensus Diamond S. There exists some transformation from Diamond S to Omega. (For example in Chu, or in our full version paper). Moreover recall that, the proof given by Chandra and Toug for the weakest failure detector builds in fact Omega.

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 To illustrate the problem let us consider the following simple implementation of Omega. This simple implementation is used, for example, in Paxos. In this implementation, process may crash, and eventually all communication links are timely. That means that, there is some constant delta such that eventually, all messages take at most delta time to be received. This property characterizes the model of partially synchronous system considered. In fact, it is worth noting that in this model of system, we can easily implement an eventually perfect failure detector and then get a leader election.

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 ) More precisely, in this implementation, Periodically , each process sends to all an OK messages, say every eta. Then each process maintains a set of processes from which it received an OK recently, that is within eta plus delta from the last OK message. In this way, if the system ensures the assumed properties, we get a eventually perfect failure detector (When the system stabilizes, every message from each correct process arrives on time (within delta plus eta) and there is a time after which the set will contain all and only all correct processes. Then to get a leader election we take in the set, say, the smallest process and choose it as leader. As eventually, the set will be the same everywhere, clearly, all correct processes will agree on the same leader and so we get omega.

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?

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

36 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 temps t, tous les messages de p arrivent en d, le timeout n’est 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 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.

40 Mais… Le graphe n’est pas fortement connexe: on ne peut pas diffuser de façon fiable les compteurs d’accusations! 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 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)

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

44 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)

45 Impossibilité Résultat: Il n’existe pas d’implé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 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…

47 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

48 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)

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

50 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

51 Extensions Résultat: (f nombre de fautes) Attention:
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.

52 Application Si t=1: Pour implémenter W il suffit d’avoir 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 ?