Algorithmique distribuée 1 , consensus, détecteurs de défaillances etc…

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

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

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

4. 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 !

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

6. 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!!!

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

8. 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?)

9. 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)

10. 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? • …

11. Problèmes d’accord…

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

13. abbacdeaaabbbb abbacdeaaabbbb wxzttwwttzxvtt Redondance • Principe assurer un service • Machine à état: wxzttwwttzxvtt

14. ttzxvtt wxzttwwttzxvtt abbacdeXaaabbbb wxzttw abbacde Réplication passive

15. abbabba abbabba abbabba abbabba xwzzy xwz xwzzy xCCzy xwzzy xwzzy abbabba 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 abbabba

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

17. Tolérer des défaillances • Réplication active et passive • Consensus • Diffusion atomique • … Consensus

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

19. 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)

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

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

22. Exemple: Diffusion Fiable F-diffuse et F-délivre : • Validité : si un processus correct F-diffusem tout processus correct F-délivrem • Accord uniforme : si un processus F-délivrem tout processus correct F-délivrem • 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

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

24. Diffusion Atomique A-diffuse et A-délivre : • Validité : si un processus correct A-diffusem, tout processus correct A-délivrem. • Accord uniforme : si un processus A-délivrem, tout processus correct A-délivrem. • 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 qA-délivrentm 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.

25. 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)

26. 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 »

27. Mais…

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

29. 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. ???

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

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

32. Détecteurs de défaillances…

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

34. 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!

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

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

37. 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!

38. 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?

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

40. Démarche : • Déterminer le « meilleur » oracle pour P • (déterminer la connaissance nécessaire sur les pannes) • Algorithme pour P avec cet oracle • 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

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

42. Application au consensus…

43. 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!

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

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

46. WetàS • WetàS sont équivalents: • Exercice: • West 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)

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

48. Linéarisable Write 1 0 Write 0 Read 1 Read 0 Read 1 Read 0

49. 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)

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