Master Réseaux et Systèmes Distribués (RSD) Algorithmique des systèmes

Slides:



Advertisements
Présentations similaires
Projets et Programmes (p&p) Un nouveau concept pour définir les modalités de mise en œuvre FORMATION LAF – JUIN 2009.
Advertisements

SRT 2 NTP. Nécessité ● Les ordinateurs utilisent des horloges à quartz – Peu de précision – Tendance à dériver – Parfois plusieurs secondes par jour.
Tutoriel : faire le montage des enregistrement audio des p’tit déj’ Contact Ce tutoriel est conçu pour le logiciel libre Audacity, téléchargeable gratuitement.
Université de Nantes CHORD Vincent Trève. Introduction ● Problématique – Comment accéder efficacement aux données réparties sur un système pair à pair?
1 Le management des entreprises en STS ( 2 EME année) Formation du 21 OCTOBRE 2008.
Refonte du portail eaufrance Présentation du cadre de référence pour avis GCIB – 14/10/2014 – Anne Macaire.
ARCHITECTURE RESEAUX.
Attribution des parcours éducatifs
Le Mouvement Directionnel
Reforme du collège physique chimie au cycle 4
La ProbabilitÉ.
Ecriture collaborative d’une dissertation en classe
La Politique Qualité 1.
Besoin d’une volontaire pour lancer un volant de Badminton !
Algorithme et programmation
Master Réseaux et Systèmes Distribués (RSD) Algorithmique des systèmes
Master Réseaux et Systèmes Distribués (RSD)
Microéconomie I.
Niveau 2 : Tables de plongée
Probabilités.
Master Réseaux et Systèmes Distribués (RSD) Algorithmique des systèmes
Activités algorithmiques
Master Réseaux et Systèmes Distribués (RSD) Algorithmique des systèmes
Master Réseaux et Systèmes Distribués (RSD) Algorithmique des systèmes
Master Réseaux et Systèmes Distribués (RSD) Algorithmique des systèmes
Master Réseaux et Systèmes Distribués (RSD) Algorithmique des systèmes
Plans d’expériences: Plans factoriels
Reprise du cours ( ) Au menu du jour :
STRATÉGIES ET INSTRUMENTS D´ÉVALUATION
Master Réseaux et Systèmes Distribués (RSD) Algorithmique des systèmes
Programmation Impérative II
Information, Communication, Calcul
Eléments de la Théorie des Probabilités
Evaluation de la formation
Stabilité des porteurs horizontaux (Poutres)
Création Et Modification De La Structure De La Base De Données
1.2 dénombrement cours 2.
3- Nouvelles pages d’accueil
Réseaux de neurones appliqués à la reconnaissance de caractères
Exercice : le jeu. Vous devez concevoir l’algorithme permettant de jouer avec votre calculatrice : elle détermine au hasard un nombre caché entier entre.
Master Réseaux et Systèmes Distribués (RSD) Algorithmique des systèmes
SDRP & MA Problème du rendez vous : un algorithme probabiliste et une analyse probabiliste 09/11/2018.
LA LOI DU 5 JUILLET 2010 Rénovation du dialogue social
Tarifs et mobilité bancaire
Eléments de la Théorie des Probabilités
Portail de saisie et de restitution
CRITERES DE QUALITE 1) PRECISION 2) RAPIDITE 3) AMORTISSEMENT
Lois de Probabilité Discrètes
Portail de saisie et de restitution
Régulation et transports
Élections locales probabilistes
TTR : Résumé exécutif Schéma global du processus validé entre RNE et FTE.
L’expérimentation de la médiation préalable obligatoire
Tu t’amuses en jouant au hockey ?
Championnat de France individuel
Dr Florence PUTTO-AUDE Pédopsychiatre Thérapie familiale systémique CMPP départemental (st Adrien) IME les Figuiers 1.
Travaux Pratiques de physique
MASTER 1 Aspects financiers et comptes de résultats
Tris Simples/Rapides.
Diapositives 6 : Mes candidats
Les différents modes de démarrage de Windows
Formation « Utiliser un site Internet école »
Retour d’expérience Solutions organisationnelles
Diapositives 9 : Mes candidats
Présentation projet de fin d’études
Elections locales probabilistes
Parcours adapté L’évaluation au service des apprentissages
Tu t’amuses en jouant au hockey ?
Séminaire communication Projet UE Geresh Cam Jeudi 7 mars 2019
Séquence 1:Analyse du système d’information comptable
Transcription de la présentation:

Badr Benmammar badr.benmammar@gmail.com Master Réseaux et Systèmes Distribués (RSD) Algorithmique des systèmes et applications réparties Accord et coordination Consensus Badr Benmammar badr.benmammar@gmail.com

Accord et coordination Une famille de problèmes en algorithmique distribuée. Catégories de problèmes de cette famille : Accord sur l’accès à une ressource partagée Exclusion mutuelle Accord sur l’ordre d’envoi de messages à tous Diffusion atomique Accord sur un processus jouant un rôle particulier Élection d’un maître Accord sur une valeur commune Consensus Accord sur une action à effectuer par tous ou personne Transaction

Accord sur une valeur commune « Consensus »

Plan Consensus : principe général Conditions à valider Consensus dans différents environnements : Sans faute Synchrone, panne franche Asynchrone, panne franche Asynchrone, fautes byzantines Synchrone, fautes byzantines Problème des généraux byzantins Consensus : résumé

Principe général Des processus doivent se mettre d’accord sur une valeur commune. Deux étapes : Chaque processus fait une mesure ou un calcul : valeur locale qui est proposée à tous les autres processus. Les processus, à partir de toutes les valeurs proposées, doivent se décider sur une valeur unique commune. Soit un processus initie le consensus. Soit le consensus est lancé à des instants prédéterminés.

Les processus, à partir des 3 seuils proposés, doivent se décider Exemple : Consensus dans le cadre des DIDS (système de détection d’intrusion distribué) P1 P2 P3 Les processus, à partir des 3 seuils proposés, doivent se décider sur un seuil commun

Conditions à valider Accord : La valeur décidée est la même pour tous les processus corrects. Validité : La valeur choisie par un processus est une des valeurs proposées par l’ensemble des processus. Intégrité : Un processus décide au plus une fois : pas de changement de choix de valeur. Terminaison : La phase de décision se déroule en un temps fini : tout processus correct décide en un temps fini.

Consensus : sans faute Solution simple : Après la mesure locale, un processus envoie sa valeur à tous les autres. A la réception de toutes les valeurs (après un temps fini par principe), un processus applique une fonction donnée sur l’ensemble des valeurs. La fonction est la même pour tous les processus. Chaque processus est donc certain d’avoir récupéré la valeur commune qui sera la même pour tous. 40 P1 40 40 P3 P2

Consensus : sans faute Solution simple : Après la mesure locale, un processus envoie sa valeur à tous les autres. A la réception de toutes les valeurs (après un temps fini par principe), un processus applique une fonction donnée sur l’ensemble des valeurs. La fonction est la même pour tous les processus. Chaque processus est donc certain d’avoir récupéré la valeur commune qui sera la même pour tous. 40 P1 50 40 40 P3 P2 50 50

Consensus : sans faute Solution simple : Après la mesure locale, un processus envoie sa valeur à tous les autres. A la réception de toutes les valeurs (après un temps fini par principe), un processus applique une fonction donnée sur l’ensemble des valeurs. La fonction est la même pour tous les processus. Chaque processus est donc certain d’avoir récupéré la valeur commune qui sera la même pour tous. 40 P1 60 50 40 40 P3 P2 60 50 50 60

Consensus : sans faute Les processus appliquent la même fonction sur l’ensemble des valeurs. 40 P1 60 50 40 40 P3 P2 60 50 50 60

Consensus : sans faute Min ---40 Min ---40 Min ---40 Les processus appliquent la même fonction sur l’ensemble des valeurs. Min ---40 40 P1 60 50 40 40 P3 P2 60 50 50 Min ---40 Min ---40 60

Consensus : sans faute Autre solution simple : Passer par un processus coordinateur qui centralise la réception des valeurs proposées et fait la décision, puis la diffuse. Ces solutions fonctionnent pour les systèmes distribués synchrones ou asynchrones. La différence est le temps de terminaison qui est borné ou non. P1 P3 P2 40 50 60 Coordinateur

Consensus : sans faute Max ---60 Autre solution simple : Passer par un processus coordinateur qui centralise la réception des valeurs proposées et fait la décision, puis la diffuse. Ces solutions fonctionnent pour les systèmes distribués synchrones ou asynchrones. La différence est le temps de terminaison qui est borné ou non. P1 P3 P2 40 50 60 Coordinateur Max ---60

Consensus : sans faute Autre solution simple : Passer par un processus coordinateur qui centralise la réception des valeurs proposées et fait la décision, puis la diffuse. Ces solutions fonctionnent pour les systèmes distribués synchrones ou asynchrones. La différence est le temps de terminaison qui est borné ou non. P1 60 P3 P2 40 50 60 Coordinateur 60 60

Consensus : synchrone, panne franche Et communications fiables : pas de perte ni de duplication de messages. Peut donc déterminer si un processus n’a pas répondu, c’est-à-dire s’il est planté. 1er cas : P1 plante avant l’envoi de sa valeur à P2 et P3. 2ème cas : P1 plante pendant l’envoi de sa valeur, un seul processus reçoit la valeur de P1. Utiliser la diffusion fiable. Tous les processus recevront exactement les mêmes valeurs et pourront appliquer la même fonction de choix qui aboutira forcément au même choix. P1 P3 P2 50 60 P2 détecte que P1 est en panne P3 détecte que P1 Min ---50

Consensus : asynchrone, panne franche En 1983, Fischer, Lynch & Paterson (FLP) ont montré que : Dans un système asynchrone, même avec un seul processus fautif, il est impossible d’assurer que l’on atteindra le consensus (ne se termine pas toujours). FLP précise qu’on atteindra pas toujours le consensus, mais pas qu’on ne l’atteindra jamais. En théorie, le consensus n’est pas atteignable systématiquement en asynchrone. Mais, malgré ce résultat, il est possible en pratique d’atteindre des résultats satisfaisants. Définir des algorithmes non parfaits.

Consensus : asynchrone, panne franche Algorithme de Paxos (Lamport, 89) : algorithme non parfait de consensus en asynchrone, contexte de pannes franches. Principe très général : Un processus coordinateur tente d’obtenir les valeurs des processus et choisi la valeur majoritaire. Si le processus coordinateur se plante, d’autres processus peuvent reprendre son rôle. P1 Importance des délais de garde P3 P2 60 50 Coordinateur

Consensus : asynchrone, panne franche Algorithme de Paxos (Lamport, 89) : algorithme non parfait de consensus en asynchrone, contexte de pannes franches. Principe très général : Un processus coordinateur tente d’obtenir les valeurs des processus et choisi la valeur majoritaire. Si le processus coordinateur se plante, d’autres processus peuvent reprendre son rôle. P1 Importance des délais de garde P3 P2 Lancer un algorithme d’Election pour élire le nouveau coordinateur 60 50 Coordinateur

Consensus : asynchrone, fautes byzantines Contexte de fautes byzantines bien plus complexe à gérer que les pannes franches. Consensus pas toujours atteignable en asynchrone, panne franche. Consensus pas toujours atteignable en asynchrone, fautes byzantines.

Consensus : synchrone, fautes byzantines En synchrone, contrairement aux pannes franches, il n’est pas possible d’assurer que le consensus sera toujours atteint dans un contexte de fautes byzantines. Lamport, Shostak et Pease ont montré en 1982, via le problème des généraux byzantins, que : Si f est le nombre de processus fautifs, il faut au minimum 3f + 1 processus (au total) pour que le consensus soit assuré. En dessous, il n’est pas assuré. Exemple : avec 2 processus fautifs, il faut au minimum 7 processus au total (5 corrects) pour terminer le consensus. Les algorithmes à mettre en œuvre sont relativement lourds en nombre de messages.

Problème des généraux byzantins Un ensemble de généraux doivent se coordonner pour mener une attaque, doivent tous faire la même chose (attaquer ou battre en retraite). Le général en chef prend l’ordre et l’envoie aux autres généraux (ses lieutenants). Ces derniers se renvoient l’ordre entre eux pour s’assurer qu’il est bien reçu et est bien le bon. Problème : Un certain nombre de généraux peuvent être des traîtres. Ils vont envoyer des ordres différents aux autres généraux. Les généraux loyaux doivent détecter les traîtres et ignorer leurs ordres.

Problème des généraux byzantins Contexte avec 3 généraux : généralisable à des multiples de 3 d’où le « 3f + 1 ». Deux cas : Gauche : le lieutenant 2 est le traitre, il renvoie le mauvais ordre. Droite : le chef est le traître, il envoie deux ordres différents. Dans les 2 cas, le lieutenant 1 reçoit deux ordres contradictoires en étant incapable de savoir lequel est le bon.

Problème des généraux byzantins Avec un troisième lieutenant (donc 4 généraux), le lieutenant 1 recevrait un message de plus qui permettrait de savoir quel est le bon ordre.

Problème des généraux byzantins Avec un troisième lieutenant (donc 4 généraux), le lieutenant 1 recevrait un message de plus qui permettrait de savoir quel est le bon ordre. Ltn 3 attaque retraite Valeur majoritaire

Consensus : synchrone, fautes byzantines Algorithme des généraux byzantins correspond à une réalisation de consensus dans un contexte de fautes byzantines. Condition : n = nombre de généraux, m = nombre de traîtres. Il faut : n >= 3m+1. Algorithme des généraux : P(m) : algorithme pour m traîtres au plus. Chaque lieutenant Li possède une valeur locale vi qui est l’ordre qu’il a décidé de suivre, déterminé en fonction de ce qu’il a reçu des autres généraux. S’appliquera de manière récursive : P(m–1), P(m–2) jusqu’à atteindre P(0). Pour un P(x), un processus joue le rôle de chef et diffuse sa valeur à tous les autres lieutenants.

Consensus : synchrone, fautes byzantines P(0) : pas de traître 1. Le chef diffuse sa valeur à tous les lieutenants Li. 2. Pour tout i, à la réception de la valeur du chef, chaque lieutenant positionne vi à la valeur reçue. Si ne reçoit rien, vi = DEF (absence de valeur). P(m) : m traîtres (m > 0) 1. Le chef diffuse sa valeur à tous les lieutenants Li. 2. Pour chaque Li, à la réception de la valeur du chef, chaque lieutenant positionne vi à la valeur reçue. 3. Chaque lieutenant exécute P(m–1) en jouant le rôle du chef : diffusion de sa valeur aux (n–2) autres lieutenants. 4. Une fois reçu la valeur vj de chacun des lieutenants (vj = DEF si rien reçu de Lj), détermine la valeur locale vi. vi = valeur majoritaire parmi les vj ou DEF si pas de majorité.

Avec un seul traitre : m=1 P(1) Chef valeur1 Valeurn-1 valeur2 valeur3 Ltn 1 Ltn 2 Ltn n-1 Ltn 3 . . . . v1=valeur1 v2=valeur2 vn-1=valeurn-1 v3=valeur3

Avec un seul traitre : m=1 P(1) Chef valeur1 Valeurn-1 valeur2 valeur3 Ltn 1 Ltn 2 Ltn n-1 Ltn 3 . . . . v1=valeur1 v2=valeur2 vn-1=valeurn-1 v3=valeur3 P(0) P(0) P(0) P(0)

Avec un seul traitre : m=1 P(1) Chef valeur1 Valeurn-1 valeur2 valeur3 Ltn 1 Ltn 2 Ltn n-1 Ltn 3 . . . . v1=valeur1 v2=valeur2 vn-1=valeurn-1 v3=valeur3 P(0) P(0) P(0) P(0) v1=valeur1 v2=valeur2 . vn-1=valeurn-1 v1=valeur1 v2=valeur2 . vn-2=valeurn-2 v2=valeur2 . vn-1=valeurn-1 v1=valeur1 . vn-1=valeurn-1

Avec un seul traitre : m=1 Trouver la valeur majoritaire pour chaque processus P(1) Chef valeur1 Valeurn-1 valeur2 valeur3 Ltn 1 Ltn 2 Ltn n-1 Ltn 3 . . . . v1=valeur1 v2=valeur2 vn-1=valeurn-1 v3=valeur3 P(0) P(0) P(0) P(0) v1=valeur1 v2=valeur2 . vn-1=valeurn-1 v1=valeur1 v2=valeur2 . vn-2=valeurn-2 v2=valeur2 . vn-1=valeurn-1 v1=valeur1 . vn-1=valeurn-1

Avec un seul traitre : m=1 Ltn 3 attaque retraite Valeur majoritaire P(1) P(0)

Consensus : résumé Selon le contexte de faute et le modèle temporel (avec communications fiables dans tous les cas) : Asynchrone : Impossibilité de définir des algorithmes assurant d’aboutir à un consensus dans tous les cas (franche ou byzantine). Problème principal : impossibilité de différencier un processus planté d’un message lent. Synchrone : Panne franche : consensus atteignable systématiquement. Panne byzantine : consensus assuré si on ne dépasse pas un seuil de processus au comportement byzantin en proportion du nombre global de processus. n = nombre de processus, m = nombre de processus fautifs. Il faut : n > 3m.