Les dtecteurs de dfaillances

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

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

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 à linstant t
• p fait confiance à q à linstant 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
• W assure 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
• Sil 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 dune majorité de
  correct

19
W

• 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 W (choisir un leader ultime)

20
Consensus avec W

• 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 (tltn/2, registres, S, S)
• dengagement le leader décide
• Quelques complications techniques

21
S

• Lintersection 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 d 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

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 t à 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 tgtt si p
  envoie m à q au temps t alors q reçoit m au plus
  tard en td
• É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 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 nest 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 nest 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
(No Transcript)
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 hD, à chaque
  réception et vérifie quun message arrive avant
  lexpiration du réveil à hD, 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 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 t, 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 n2
  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 W (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)
• W 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, W peut être implémenté
  de façon efficace pour la communication.

52
Application

• Si t1
• Pour implémenter W 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 ?