Système répartis

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. Redondance
 Principe assurer un service
 Machine à état:
abbacdeaaabbbb wxzttwwttzxvtt
abbacdeaaabbbb wxzttwwttzxvtt

14. Réplication passive
wxzttwwttzxvtt
abbacdeXaaabbbb ttzxvtt
wxzttw
abbacde

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

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

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:

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

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. W et S
 W et S sont équivalents:
 Exercice:
 W 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)

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
Read 1
Read 0
Write 0
Read 0
Read 1

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

51. Quorum comme détecteur de
défaillances..
 Détecteur de quorum S :
 S propose une liste de processus
 S assure la complétude ultime
 Il y a toujours une intersection non vide dans les listes
proposées par S
 Résultat:
 Détecteur de quorum S 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…)

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

53. Ben Or
1. On échange nos valeurs v (0 ou 1)
 j’attend de recevoir les valeurs provenant de mon quorum S
 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 S
 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.

54. Ben Or…
 Il n’y a pas de blocage (complétude de S)
 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.

55. 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 (!?)

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

57. 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)!

58. Et réciproquement?
 On a vu que Ω et S 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 S
 Ω et S est le plus faible détecteur de
défaillances pour résoudre le
consensus.

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