Algorithmique distribuée 1, consensus, détecteurs de défaillances etc… Hugues Fauconnier LIAFA 1-tolérante aux pannes!

plan  Modèles… synchrone—asynchrone  Les problèmes d’accord  Détecteurs de défaillances… un peu d’algorithmique  Et alors?

Défaillances ?  Défaillances de Processeurs: Pannes définitives (crash) Erreurs d'émission Erreurs de réception Erreurs de réception et d'émission Ne pas suivre son code (byzantin) (avec ou sans authentification) Attaques, sécurité. Attention: p est correct s'il ne commet jamais de défaillances

Et la communication ?  Graphe complet de communication (!)  Identités connues (?)  Communication point à point  Pertes de messages ? Du travail pour assurer ces propriétés… Pas de problème de réseau !

Synchrone -- Asynchrone  Temps… Processeurs:  Synchrones: entre deux pas de calcul de chaque p, chaque q ne fait qu’un nombre borné (connu) de pas de calcul.  Horloges  (dans la suite on suppose en général que les processeurs sont « synchrones ») Communication:  Synchrone: il existe une borne connue δ sur les temps de communication  Asynchrone: il n’existe pas de borne sur les temps de communication

Synchrone -- Asynchrone  S’il n’y a pas de défaillances les deux modèles sont « équivalents »: α- β synchronizers: simulent du synchrone en asynchrone.  S’il peut y avoir des défaillances: Impossibilité du consensus et donc de la plupart des problèmes d’accord en asynchrone, alors que ces problèmes peuvent être résolus en synchrone!!!

Synchrone -- Asynchrone  Synchrone? Comment déterminer les bornes  Performances  Effet d’une mauvaise borne  Asynchrone? Résultats d’impossibilités !!!  (le temps est parfois utile) Meilleure « couverture » et dégradation gracieuse: safety - liveness

Entre les deux: Partiellement synchrone  Il existe une borne (inconnue) sur les délais de communication  Un jour il existera une borne (connue) sur les délais de communication Sans perte de messages ces deux modèles sont (facilement) « identiques » En augmentant régulièrement le délais supposés de communication on atteint la borne (mais du point de vue pratique?)

Partiellement synchrone  Variations: Bonne et mauvaises périodes: une borne existe mais uniquement pendant les bonnes périodes.  Bonnes périodes = ultimement (partiellement synchrone)  Bonnes périodes = souvent et pendant suffisamment longtemps (timed synchronous models) Limiter le syncrhonisme à certains nœuds  Bi-source (ultime) : il existe un p tel que la communication issue et vers p est bornée (ultimement).  Source (ultime) : la communication issue de p est bornée (ultimement)

Et la réalité?  Pertes de messages?  Modèles de défaillances? (réparation?) Responsabilité du process:  (in) correct pour toujours -> réparation?  Transient faults et auto-stabilisation dépendabilité: faute erreur défaillances  Nombre (fini) de processus?  Échelle?  …

Problèmes d’accord…

Coopérer et tolérer des défaillances…  Réplication active: Machines répliquées à états (state machine) Chaque machine:  Recevoir une valeur d’entrée  Changer d’état  Diffuse une valeur de sortie  Recommencer

Redondance  Principe assurer un service Machine à état: abbacdeaaabbbbwxzttwwttzxvtt abbacdeaaabbbb wxzttwwttzxvtt

Réplication passive wxzttwwttzxvttabbacdeXaaabbbbttzxvtt wxzttw abbacde

Réplication active  Chaque processus reçoit les mêmes requêtes et donne les mêmes réponses mêmes séquence d’états abbabbaxwzzy abbabba xwz xwzzy xCCzy xwzzy abbabba

Réplication active  Assurer que les processeurs reçoivent les mêmes informations dans le même ordre: Accord sur l’entrée Diffusion atomique

Tolérer des défaillances  Réplication active et passive  Consensus  Diffusion atomique  … Consensus

Plus formellement…

Consensus d p valeur de décision de p, v p valeur initiale de p,  Accord : si p et q décident, ils décident de la même valeur d p =d q,  Intégrité : la valeur décidée est une des valeurs initiales  Terminaison : tout processus correct décidera un jour.

Autres problèmes d’accord  Variantes: Intégrité:  Choisir la valeur proposée par un processus correct  Choisir v si tous les processus corrects proposent v … Diffusion:  Généraux byzantins: Un général en chef propose une valeur et les généraux honnêtes doivent décider la même valeur (accord et terminaison) et si le général en chef est honnête ce doit être la valeur proposée par le général en chef. On peut (en général) passer d’un problème diffusion à un problème d’accord (et vice-versa)

Accords…  Variantes: Atomic commit:  Si tous les processus proposent commit et il n’y a pas de pannes décision commit  Si au moins un processus propose abort décision abort Interactive consistency, terminating reliable broadcast Crusader: si le général est honnête accord sur sa valeur, sinon un processus peut choisir soit SF, soit une valeur proposée par le général. (Exercice: c’est facile en deux « rondes »!)  Attention tous ces problèmes ne sont pas équivalents…

Petite précision…  En l’absence de toute indication contraire. On considère ici  des pannes crash  Pas de pertes de messages.  n processus  Au plus f processus crashs.

Exemple: Diffusion Fiable F-diffuse et F-délivre :  Validité : si un processus correct F-diffuse m tout processus correct F-délivre m  Accord uniforme : si un processus F-délivre m tout processus correct F-délivre m  Intégrité uniforme : tout m est F-délivré au plus une fois par chaque processus et uniquement s'il a été F-diffusé Avec la diffusion fiable tous les processus corrects ont (ultimement) la même liste de messages

Diffusion Fiable? En l'absence de pertes de messages, la diffusion fiable est facile:  quand je reçois un nouveau message pour la première fois je l'envoie à tous et ensuite je le F-délivre  (mais plus difficile avec pertes de messages et/ou graphe de communication non nécessairement complet) Elle est impossible avec des pertes de messages si 2f>=n

Diffusion Atomique A-diffuse et A-délivre :  Validité : si un processus correct A-diffuse m, tout processus correct A-délivre m.  Accord uniforme : si un processus A-délivre m, tout processus correct A-délivre m.  Intégrité uniforme : tout m est A-délivré au plus une fois par chaque processus et uniquement s'il a été A-diffusé.  Ordre : si p et q A-délivrent m et m', ils les A-délivrent dans le même ordre. Avec la diffusion atomique tous les processus corrects ont la même liste dans le même ordre des messages délivrés.

Diffusion atomique = consensus  On peut transformer une diffusion atomique en consensus : choisir la première valeur A-délivrée  Des consensus répétés permettent de réaliser de la diffusion atomique (+ quelques astuces simples)

Résultats…  En synchrone: le problème du consensus peut se résoudre  Facilement pour les pannes crashs avec (f<n)  Plus difficilement pour des pannes byzantines (3f<n)  Dans tous les cas il faut jusqu’à f+1 « rondes »

Mais…

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

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.

Solutions…  Systèmes partiellement synchrones: restreindre le caractère asynchrone du modèle  Modifier la spécification Changer la terminaison: terminer avec probabilité 1 (un exemple plus tard) Restreindre les valeurs d’entrée possibles Ou…

Une solution…  Intuitivement le consensus est impossible parce que (1) la décision peut dépendre d’un seul et (2) on ne peut pas savoir s’il est vivant (il faut attendre son message!) ou s’il est mort.  Ajouter au système asynchrone ce qui lui manque pour résoudre le consensus:

Détecteurs de défaillances…

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

Oracles  Détecteur de défaillances : donne à chaque processus des informations (qui ne sont pas toujours fiables) sur les pannes des autres processus.  On pourrait définir d’autres oracles (oracle de consensus, oracle de diffusion atomique etc…). Le middle ware comme oracle!

Des propriétés Détecteur de défaillances: Chaque p peut consulter son détecteur de défaillances -> 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

Quelques classes… Détecteurs de défaillances  Parfait (P) : information exacte (complétude et exactitude forte) (pas très différent du synchrone)  Fort (S) : complétude et exactitude faible (pas très naturel?)  Ultimement P (  P) : un jour les informations exactes (le système finit par être synchrone)  Ultimement S (  S) : un jour complétude et exactitude faible

Oracles? Mais pas trop  Dans quelles modèles de systèmes peut-on les réaliser? (avec des pings ou des hearbeat) P dans un système synchrone  Si p ne répond pas dans les délais il est mort! S dans un système dans lequel un processus correct communique en moins de d vers tous les autre depuis le début (source)  Le heartbeat de la source arrive toujours à, l’heure.  P dans un système:  ultimement toutes les communications sont bornées pas delta  Les délais de communication ne peuvent croître indéfiniment!  Augmenter la borne supposée… un jour on attient la borne!  S dans un système:  Il existe une source ultime  Les messages de la source ultime arriveront (un jour) à temps!

Comparaisons  Réduction: A est plus faible que B (A ≤ B) si on peut implémenter A à partir de B Ordre partiel ≈ Détecteur minimal pour résoudre un problème P:  Quelle information sur les pannes est nécessaire pour résoudre P?

Pourquoi chercher le détecteur minimale pour P? En déterminant la connaissance minimale sur les pannes :  THEORIE: On peut alors comparer la difficulté des problèmes: exemple implémentation d’objets en mémoire partagée  PRATIQUE: Déterminer les conditions de synchronie sur le système nécessaires pour réaliser cette détection de défaillances.

Démarche : 1. Déterminer le « meilleur » oracle pour P  (déterminer la connaissance nécessaire sur les pannes) 2. Algorithme pour P avec cet oracle 3. Réalisation de l’oracle:  Déterminer les conditions de « synchronisme » nécessaires pour réaliser cet oracle -> modèle partiellement synchrone Implémenter l’oracle dans ce modèle

Démarche…  Si le détecteur de défaillances est minimal  Si les conditions sur le système pour implémenter le détecteur sont minimales  On obtient : un algorithme pour résoudre P avec des conditions minimales sur le système.

Application au consensus…

Pour faire un consensus…  S’adresser à un chef (coordinateur) Le chef est correct Tout le monde lui fait confiance (liveness) Détecteur de défaillances!  Pouvoir bloquer la valeur décidée (si p décide il faut garantir que tout q qui décidera après doit décider la même chose) (safety) Détecteur de défaillances!

Leader ultime Un chef simplifie les choses (?)  élire un chef: Tout le monde est d’accord sur l’identité du chef Le chef est vivant pour toujours (!) (il existe un temps t à partir duquel tout le monde a un seul chef et ce chef est correct (= vivant pour toujours))

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 q: p fait confiance à q à l’instant t   assure : un jour tous les processus corrects feront confiance au même processus correct.

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   et  S sont équivalents: Exercice:   est dans  S (par définition)  Réciproquement: si on compte le nombre de fois que des processus sont suspectés quelque part dans  S + diffusion de ces compteurs, le processus le moins suspecté est leader (c’est le même pour tous : diffusion il est correct : complétude)

Registres pour un « lock »  Un moyen simple de « bloquer » la valeur choisie est d’avoir des registres atomiques Un registre:  Une lecture retourne la dernière valeur écrite  Linéarisable: on peut linéariser les opérations de lecture et d’écriture

Linéarisable Write 1 0 Read 1 Read 0 Write 0 Read 0 Read 1

Implémentation en présence de pannes?  Les valeurs écrites sont maintenues par les processus Pour écrire, l’écrivain envoie sa valeur et attend de savoir qu’un ensemble suffisamment grand de processus a accepté son écriture Pour lire, demander la valeur à suffisamment de processus pour être sûr d’obtenir la dernière valeur écrite Suffisamment grand? L’ensemble des participants à l’écriture doit avoir une intersection non vide avec l’ensemble des participants à la lecture (+ pouvoir déterminer quelle écriture est la plus récente)

Quorum…  S’il y a une majorité de processus corrects l’écrivain attend qu’une majorité de processus ait enregistré sa nouvelle valeur le lecteur attend d’avoir la valeur d’une majorité de processus. Nécessairement, parmi ces valeurs il y a la dernière valeur écrite. (un compteur permet de déterminer quelle est la dernière valeur).  Plus généralement, il faut que L’écrivain attende d’un ensemble E de processus vivants et que le lecteur obtienne sa valeur d’un ensemble F de processus vivants tel que: E  F   E et F doivent être des éléments d’un quorum  E et F doivent être des processus vivants

Quorum comme détecteur de défaillances..  Détecteur de quorum  :   propose une liste de processus  assure la complétude ultime Il y a toujours une intersection non vide dans les listes proposées par   Résultat: Détecteur de quorum  est le plus faible détecteur de défaillances pour réaliser un registre. (dans un sens c’est facile dans l’autre un peu moins…)

Algorithmes (enfin!)…  Consensus probabiliste: Si tout le monde propose la même valeur c’est facile de se mettre d’accord. Essayons de proposer la même valeur!

Ben Or 1. On échange nos valeurs v (0 ou 1)  j’attend de recevoir les valeurs provenant de mon quorum   Si je n’ai que des 0 ou que des 1 alors w:= cette valeur sinon w:=? ici, à cause des propriétés de quorum on ne peut pas avoir des processus avec w=0 et d’autres avec w=1  On échange nos valeurs w (0, 1, ou ?) j’attend de recevoir les valeurs provenant de mon quorum  Si je n’ai qu’un seule valeur (0 ou 1) je décide cette valeur avec le quorum si je n’ai que des 0 (resp. 1) personne ne peut avoir ni que des « ? » ni des 1 (resp. 0) Si j’ai une valeur (0 ou 1) et ? alors v:=cette valeur de toute façon l’autre valeur est éliminée Si je n’ai que des ? Je tire une valeur v:=random(0,1); Comme je ne sais pas quoi choisir remettons-nous en au hasard.

Ben Or…  Il n’y a pas de blocage (complétude de  )  Intégrité? Si tous les processus proposent la même valeur tous décident à la fin de la ronde 2.  Accord? Si quelqu’un décide 0, alors aucun w ne pouvait être à 1 (quorum sur ronde 1) à la fin de la ronde 2, tous les processus ont reçu au moins un 0, et donc mettrons v à 0 ou décideront => aucune autre décision ne sera possible  Terminaison? Si à la fin de la ronde 2 aucun processus n’a vu que des « ? » alors ils changent tous v pour la même valeur. Sinon certains changent v pour une valeur unique (disons 0) et d’autres tirent, le hasard fait bien les choses ils finiront bien par tous tirer 0.

De Ben Or au Consensus…  Le but du tirage est de garantir qu’un jour toutes les valeurs proposées en ronde 1 de Ben Or soient les mêmes.  Un chef peut bien remplacer le hasard!  Il suffit de prendre la valeur qu’il propose (c’est le chef il a donc raison!)  Si on a tous le même chef on aura les mêmes valeurs (!?)

Avec le leader… Ronde r: 1. Envoyer sa valeur (v,r) à tous Attendre de recevoir la valeur (x,r) de mon leader v:=x 2. Ben Or 1. Envoyer (v,r) à tous Recevoir x,r de tous les processus de mon Quorum  Si tous les x reçus sont égaux à z alors w:=z sinon w:=?choisir cette valeur 2. Envoyer (w,r) à tous Recevoir x,r de tous les processus de mon Quorum  Si tous les x sont identiques à z (z ≠ ?) alors décider z sinon si au moins un x est différent de ? v:=cette valeur 3. r:=r+1

Consensus…  Accord + intégrité? Comme Ben Or  Terminaison? Un jour (ronde R) tous les processus ont le même (correct) processus comme leader. Ce leader propose à tous la même valeur Ils décideront tous cette valeur (Ben Or)!

Et réciproquement?  On a vu que Ω et  permettent de réaliser le consensus.  Réciproquement, on peut montrer (plus difficile) que de tout détecteur de défaillances permettant de réaliser le consensus, on peut construire Ω et   Ω et  est le plus faible détecteur de défaillances pour résoudre le consensus.

Et alors? (conclusion)  Les détecteurs de défaillances permettent de caractériser la connaissance nécessaire sur les pannes pour réaliser le consensus  Les détecteurs de défaillances permettent d’écrire des (beaux) algorithmes de consensus en asynchrone  Ils sont pratiques (pour France telecom et le projet apache)  Ils peuvent se réaliser efficacement dans des systèmes partiellement synchrones (Carole)  Même P. FrainIaud pourra les utiliser pour insérer/retirer des sites sur son anneau.

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é

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: 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 (laissons-lui une chance).  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:  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 pire: Le leader est le processus ayant le plus petit compteur.

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!  Une source ultime communique bien ultimement avec tous. Remarques:  Si une source ultime accuse p, p le saura (tout le monde aussi si la source le dit).  Si une source ultime communique bien avec q, elle peut le faire savoir (relais)

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)

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 communication  Le problème de l’algorithme précédent est que tous les processeurs communiquent toujours les n 2 liens sont utilisés  Communication efficace: ultimement un seul processus envoie des messages (on ne peut pas mieux)

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

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

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)

Bilan  Conditions « minimales » de synchronie  Algorithmes efficaces pour implémenter  (avec conditions raisonnables)  Auto-stabilisation : de n’importe quel état on converge Tout est bon!

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

Extensions  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.

Application  Si f=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?

Démarche : 1. Déterminer le « meilleur » oracle pour P  (déterminer la connaissance nécessaire sur les pannes) 2. Algorithme pour P avec cet oracle 3. Réalisation de l’oracle:  Déterminer les conditions de « synchronisme » nécessaires pour réaliser cet oracle -> modèle partiellement synchrone Implémenter l’oracle dans ce modèle fini

Conclusion ? Détecteur de défaillances approche à la fois abstraite et pratique Un aperçu des méthodes et des résultats Après la conclusions

Perspectives (I)  Grande échelle:   O(n) messages échangés pour   Stabilité: on ne change de leader que si on a une bonne raison de le faire Le leader choisi communique bien avec un groupe suffisamment important de processus « Localité »  Extension à une notion de groupes

Perspectives (II)  Autres types de pannes: Pannes byzantines : un processus incorrect est un adversaire du système  Détection de défaillances?  Élection de leader?  Systèmes partiellement synchrones: Trouver le système minimal pour le consensus.

Perspectives (III)  Objets et mémoire partagées Détection de défaillances versus hardware…  Extensions des résultats sur les détecteurs de défaillances à des modèles plus généraux (graphe de communication, grande échelle) Réseau

Perspectives (IV)  Grande échelle (encore!) Nouveaux problèmes, nouvelles perspectives? Modèles partiellement synchrones Autres approches, auto-stabilisation, auto- organisation?

Autres travaux…  Algorithmique Atomic multicast (OPODIS2000), generic broadcast (DISC00) Early stopping (PODC, TPDS)  Temps-réel Real-time Atomic broadcast (SRDS99) Real-time groups (ICDCS2001) Système de phases (OPODIS99)  Modèles Complexité (SIROCO2002), Transformation automatique(SRDS2003)

Autres sujets d’intérêts  Algorithmique distribuée efficace  Modèles de calcul  Temps-réel: Projets ATR et AGS  Conception: Méthode TRDF (G. LeLann) et projets industriels  …

Détecteurs de défaillances…  Omega: Stabilité (DISC01) Partiellement synchrone (PODC03)  Quorum Réaliste (DSN2002) Registres (DISC02)

Collaborations  C. Delporte (LIAFA)  S. Toueg (Toronto)  R. Guerraoui (EPFL)  M. Aguilera (HP labs)  G. LeLann (INRIA)  IRISA (Raynal, Hurfin)  LRI parallélisme et grand large

Divers…  AS algo distribuée et applications  Egide collaboration avec l’EPFL  Ècole de printemps d’informatique théorique (2003) Algorithmique distribuée

Divers…  Collaborations industrielles et projets: Projet ATR (DRET, INRIA, CNRS, Dassault, Thalès, Axlog) (2001) Projet AGS (IRISA, CNES) (2004)

Enseignement et responsabilité…  Responsable du dess logiciels fondamentaux depuis… longtemps  LMD …  Cours: Initiation, Java, programmation objet, systèmes, réseaux, algorithme distribuée et parallèle, …