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

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

  • Upload
    jaclyn

  • View
    34

  • Download
    0

Embed Size (px)

DESCRIPTION

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: - PowerPoint PPT Presentation

Citation preview

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

Algorithmique distribuée1, consensus, détecteurs de défaillances etc…

Hugues Fauconnier LIAFA

1-tolérante aux pannes!

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

plan Modèles… synchrone—asynchrone

Les problèmes d’accord

Détecteurs de défaillances… un peu d’algorithmique

Et alors?

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

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

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

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 !

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

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

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

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

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

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

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

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

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

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)

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

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

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

Problèmes d’accord…

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

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

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

Redondance Principe assurer un service

Machine à état:

abbacdeaaabbbb wxzttwwttzxvtt

abbacdeaaabbbb wxzttwwttzxvtt

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

Réplication passive

wxzttwwttzxvttabbacdeXaaabbbb ttzxvtt

wxzttwabbacde

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

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

xwzzyabbabba

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

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

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

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

Consensus

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

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

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

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)

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

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…

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

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.

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

Exemple: Diffusion FiableF-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

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

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

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

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

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

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)

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

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 »

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

Mais…

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

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.

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

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.

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

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…

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

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:

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

Détecteurs de défaillances…

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

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

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

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!

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

Des propriétésDé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

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

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

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

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!

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

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?

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

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.

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

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

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

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.

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

Application au consensus…

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

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!

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

Leader ultimeUn 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))

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

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.

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

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 : diffusionil est correct : complétude)

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

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

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

Linéarisable

Write 10

Read 1

Read 0

Write 0

Read 0

Read 1

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

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)

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

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

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

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

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

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!

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

Ben Or1. 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 valeurde 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.

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

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.

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

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

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

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 Or1. 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) à tousRecevoir x,r de tous les processus de mon Quorum Si tous les x sont identiques à z (z≠?) alors décider zsinon si au moins un x est différent de ? v:=cette valeur

3. r:=r+1

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

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

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

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.

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

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.