Les détecteurs de Les détecteurs de défaillancesdéfaillances

Défaillances ?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éesAttention: p est correct s'il ne commet jamais de défaillances

Et le réseau?Et le réseau?

En général:– Communication asynchrone point à

point– Graphe complet de communication– Pas de pertes de messages…

ConsensusConsensus

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.

Impossibilité du consensusImpossibilité 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.

Que faire?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.

Une solution…Une solution…

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

OraclesOraclesAjoutent "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.

OraclesOracles

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

Détecteur de défaillancesDé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 ultimeExactitude faible ultime

Détecteurs de défaillancesDé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

Comparaison des détecteurs Comparaison des détecteurs de défaillances…de défaillances…

Réduction:– D est plus faible que D’ si D peut être

implémenté (algorithme distribué) en utilisant D’

Réduction : exempleRéduction : exemple

Exemple: Complétude faible : tout processus incorrect est soupçonné par au moins un processus correctComplétude forte : tout processus incorrect est soupçonné par tout processus correct

Réduction:échanger les listes de suspects et faire l’union!

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 à l’instant :

p fait confiance à q à l’instant

assure : un jour tous les processus corrects feront

confiance au même processus correct.

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

et S sont équivalents

Le plus faible…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. S’il existe un algo qui résoud P avec un FD D’, D’ permet de construire D

Détecteur de défaillancesDétecteur de défaillances

est le plus faible détcteur de défaillance pour le consensus en présence d’une majorité de correct

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

Consensus avec Consensus avec 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, )d’engagement le leader décide

+ Quelques complications techniques

L’intersection 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)

Détecteur de défaillancesDétecteur de défaillances

Permettent de résoudre le consensusCeux qui le permettent ne peuvent

être réalisés en asynchrone (FLP!)Comment les implémenter?

Partiellement synchrone…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– …

Oméga…Oméga…

Reprenons notre détecteur de défaillances …

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

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 parfaitP

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 )

Liens de communicationLiens 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 d’un

certain type à q alors, q reçoit une infinité de messages de ce type.

Sources et hubsSources 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.

Systèmes Systèmes SS--, , SS et et SS++

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.

RemarquesRemarques

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 n’est pas fortement connexe…

Avec S, S+ les processus ne connaissent pas la source ultime ou le hub.

dans un système dans un système SS

Au moins une source ultime, mais le graphe de communication n’est 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?

Surveiller, techniques de Surveiller, techniques de bases…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 , après , q ne suspectera plus p

– Si p est mort, q suspectera p pour toujours

Techniques de bases…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 , tous les messages de p arrivent en d, le timeout n’est plus jamais dépassé

Résultat: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

Techniques de bases: Techniques de bases: accusationaccusation

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

Accusation résultats: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.

Mais…Mais…

Le graphe n’est pas fortement connexe: on ne peut pas diffuser de façon fiable les compteurs d’accusations!

Perdu?!

Non, ça peut marcher!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)

SolutionSolution

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)

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

Efficace pour la Efficace pour la communicationcommunication

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)

ImpossibilitéImpossibilité

Résultat: Il n’existe pas d’implémentation efficace pour la communication dans les systèmes S.

Preuve standard par indistingabilité.

Efficace pour la Efficace pour la communication dans communication dans SS++

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…

SolutionSolution

Accusations et compteur d’accusation comme avant,

Mais on n’accuse que les candidatsLes 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

SolutionSolution

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)

BilanBilan

Conditions « minimales » de synchronie Algorithmes efficaces pour implémenter

(avec conditions raisonnables)

Tout est bon!

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

ExtensionsExtensions

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 n’est pas connue les liens peuvent perdre des messages– Si les liens sont fiables, peut être

implémenté de façon efficace pour la communication.

ApplicationApplication

Si t=1:– Pour implémenter il suffit d’avoir un

seul lien ultimement ponctuel (ce qui est toujours réalisé si un processus est incorrect!!!)

Étonnant?

Conclusion Conclusion

Détecteur de défaillancesapproche à la fois abstraite et pratiqueUn aperçu des méthodes et des résultats

Quelques pointeurs….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

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

Quelques pointeursQuelques pointeurs

Chandra, Hadzilacos & Toueg The weakest failure detector for solving consensus JACM 43(4) 96

Delporte,Fauconnier, Guerraoui, Kouznetsov (DSN2002 –rapports internes)

Quelques pointeurs….Quelques pointeurs….

Aguilera, Delporte, Fauconnier, Toueg: Stable leader election DISC 2001

Conclusion…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 ?