UE 2.7 Défaillances organiques et processus dégénératifs ...
Les détecteurs de défaillances. Défaillances ? Processeurs: – Pannes définitives – Erreurs...
-
Upload
eustacia-deschamps -
Category
Documents
-
view
106 -
download
0
Transcript of Les détecteurs de défaillances. Défaillances ? Processeurs: – Pannes définitives – Erreurs...
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 ?