cours1_rsd_reparti_model

Master Réseaux et Systèmes Distribués (RSD)
Algorithmique des systèmes
et applications réparties
Modélisation Conceptuelle des Systèmes Distribués
Badr Benmammar
[email protected]
Plan général
 Introduction aux systèmes distribués
 Pré requis
 Programmation réseau en Java : Socket
 Temps dans un système distribué
 Algorithmique distribuée
 Exclusion mutuelle distribuée
 Diffusion atomique
 Élection d’un maître
 Consensus
 Transaction
 Propriété stable : terminaison distribuée d’une application répartie
 Introduction aux composants logiciels (JavaBeans)
 Introduction aux Java Server Pages (JSP)
2
Plan
 Partie I : Systèmes distribués
 Définition
 Objectifs
 Avantages
 Inconvénients
 Applications réparties
 Partie II : Communication dans un système distribué
 Middleware (intergiciel)
 Modèles de communication

Client/serveur

Diffusion de messages

Pair à pair (peer to peer)
 Type de communication

Synchrone

Asynchrone
3
Plan
 Partie III : Algorithmique distribuée
 Voies d’études des systèmes distribués
 Éléments de base d’un système distribué
 Modèles conceptuels de systèmes distribués

Modèle d’interaction

Modèle de fautes


Franches

Par omission

Arbitraires ou byzantines
Détecteur de pannes

Classification

Réalisation
4
Partie I :
Systèmes distribués
5
Systèmes distribués
 Système distribué en opposition à système centralisé (tout est localisé sur la même
machine).
 Définition 1 : ensemble d’ordinateurs indépendants qui apparaît à un
utilisateur comme un système unique et cohérent.
 Exemple
Google : le plus grand parc de serveurs au monde avec environ 1
million de serveurs répartis sur environ 36 sites.
6
Systèmes distribués
 Définition 2 : ensemble d’entités logicielles communiquant entre-elles.
 Entités
logicielles s’exécutent sur des machines reliées entre elles par un
réseau.
 Exemple
Skype : la téléphonie sur IP.
7
Objectifs d’un système distribué
 Transparence (masquer la répartition) :
 Localisation des ressources non perceptible.

URL www.google.com.
 Duplication de ressources non visible.
 Concurrence d’accès aux ressources non perceptible : (ex. accès à un même fichier
ou une même table dans une base de données, vidéo youtube, …).
 Sécurité : confidentialité, intégrité, ..
 Tolérance aux pannes : permettant à un utilisateur de ne pas s’interrompre (ou même se
rendre compte) à cause d’une panne d’une ressource.
 Mise à l’échelle (scalability) : fonctionne efficacement dans différentes échelles :
 Deux postes de travail et un serveur de fichiers.
 Réseau local avec plusieurs centaines de postes de travail et serveurs de fichiers.
 Plusieurs réseaux locaux reliés pour former Internet.
 Ouverture :
 Extensibilité (ajout/MAJ de composants sans en affecter les autres).
 Flexibilité (facilité d’utilisation).
8
Avantages des systèmes distribués
 Utiliser et partager des ressources distantes.
 Système de fichiers : utiliser ses fichiers à partir de n’importe quelle
machine (partager un dossier en réseau).
 Imprimante : partagée entre toutes les machines.
 Optimiser l’utilisation des ressources disponibles.
 Calculs scientifiques distribués sur un ensemble de machines : les grilles
informatiques.
 Système plus robuste.
 Duplication pour fiabilité : deux serveurs de fichiers dupliqués, avec
sauvegarde.
 Plusieurs éléments identiques pour résister à la montée en charge ...
9
Inconvénients/points faibles
 Bien souvent, un élément est central au fonctionnement du système : serveur.
 Si serveur plante : plus rien ne fonctionne.
 Goulot potentiel d’étranglement si débit d’information très important.
 Sans élément central.
 Gestion
du système totalement décentralisée et distribuée.
 Nécessite la
mise en place d’algorithmes +/- complexes.
10
Qu’est ce qu’une application répartie ?
C sous Unix
Application monolithique
Une seul machine, même système
et même langage de programmation
Java sous
Windows
C++ sous
Mac
Application répartie
 Il s’agit d’une application découpée en plusieurs unités.
 Chaque unité peut être placée sur une machine différente.
 Chaque unité peut s’exécuter sur un système différent.
 Chaque unité peut être programmée dans un langage différent.
11
Partie II :
Communication dans un système distribué
12
Communication dans un système distribué
 Objectif : communiquer les éléments d’une application répartie.
 2 manières :
 Bat niveau : directement en appelant les services des couches TCP ou
UDP.
 Exemple
: utilisation des sockets en Java.
 Haut niveau : définition de couches offrant des services plus complexes.
 Couche
réalisée en s’appuyant sur les couches TCP/UDP.
 Exemple

: appel d’une méthode chez une entité distante.
Notion de middleware (intergiciel).
13
Middleware (intergiciel)
 Le terme middleware vient de l’anglais middle (du milieu) et software (logiciel).
 Le middleware est une couche intermédiaire (couche logiciel) qui s’intercale entre
l’infrastructure de communication d’un réseau et les éléments de l’application
distribuée.
Machine 1
Machine 2
Machine N
Middleware
Java
C
C++
Unix
Windows
Mac
14
Middleware
 Définition : le middleware est un logiciel qui se compose d’un ensemble de
services qui permettent à plusieures entités (processus, objets etc.) résidents
sur plusieurs ordinateurs, d’interagir à travers un réseau en dépit des
différences dans les protocoles de communication, architectures des systèmes
locaux, etc..
 Résoudre l’Hétérogénéité : Etre indépendant des systèmes d’exploitation et du
langage de programmation des applications.
 Résoudre l’Interopérabilité : Unifier l’accès à des machines distantes.
15
Middleware
Application Distribuée
Milieu de
développement
applicatif
Service
d’administration
du système
Services
d’abstraction
et coopération
Service de
communication
Infrastructure de communication (exemple
TCP/IP)
16
Middleware : services
 Service de communication : ce service offre une interface qui permet à l’application
distribuée d’échanger les informations entre ses composantes résidentes sur des
ordinateurs avec des caractéristiques matériels et/ou logiciels différentes.
 Services d’abstraction et coopération : ces services représentent le coeur du
middleware et ils comprennent entre autres :
 Directory Service ou service de "pages blanches", qu’il pourvoit à l’identification et
à la localisation d’entités distribuées.
 Security Service pour la protection des éléments critiques comme les données et les
services applicatifs à travers des techniques comme l’authentification et la
cryptographie.
17
Middleware : services
 Services d’administration du système : pour géréer la configuration.
 Milieu de développement applicatif : contient les instruments d’aide à l’écriture du
code par exemple le langage IDL.
 IDL (Interface Definition Language) : est un langage de définition et non un
langage de programmation grâce auquel on définit des interfaces et des structures de
données et non des algorithmes.
 On peut donc, par exemple, écrire des applications clientes en JAVA et des
applications serveurs en C++ et faire communiquer ce client et ce serveur.
 IDL est défini par l’OMG (Object Management Group) et utilisé notamment dans le
cadre d’applications CORBA.
18
Middleware : mécanisme de base
 Les environnements répartis sont basés (pour la plupart) sur
un mécanisme RPC (Remote Procedure Call) (Appel de procédure à distance).
 Ce mécanisme fonctionne en mode requête / réponse.
 Le client effectue une requête (demande un service ),
 Le serveur traite la demande puis retourne une réponse au client.
client
serveur
Emission d’une requête
Traitement
de la requête
Renvoie d’une réponse
19
RPC : principe
Programme
principal (main)
ProcA()
ProcB()
.
.
.
.
.
.
.
.
.
ProcA()
ProcB()
.
.
.
.
.
.
.
.
.
.
.
return
return
Machine 1
Machine 2
Machine 3
20
Exemples de middleware
 RPC (Remote Procedure Call).
 Pas d’objets.
 JAVA RMI (Remote Method invocation).
 Solution purement java.
 CORBA (Common Object Request Broker Architecture).
 Langages de programmation distincts.
.
21
Modèles de communication
 Les éléments distribués interagissent, communiquent entre eux selon plusieurs
modèles possibles :
 Client/Serveur.
 Diffusion de messages.
 Pair à pair (peer to peer).
 Modèle à base de composants.
 EJB (Enterprise
JavaBeans).
 Modèle à base d’agents mobiles.
 Modèles à mémoires « virtuelles » partagées.
.
22
Client/Serveur
 Modèle le plus répandu.
 2 rôles distincts :
 Client : demande que des requêtes ou des services lui soient rendus.
 Serveur : répond aux requêtes des clients.
 Liens
forts entre le client et le serveur.
 Interaction :
 Message du client vers le serveur pour faire une requête.
 Exécution d’un traitement par le serveur pour répondre à la requête.
 Message du serveur vers le client avec le résultat de la requête.
 Interaction de type « 1 vers 1 »
23
Client/Serveur
 Exemple d’interaction :
Client/Serveur WEB
24
Types de Client/Serveur
 Client/Serveur traditionnel :
 RPC (Remote procedure call).
25
Types de Client/Serveur
 Client/Serveur traditionnel :
 RPC (Remote procedure call).
 Client/Serveur à objets :
 RMI (Remote Method Invocation) : communique des objets java.
 CORBA : n’importe quel langage.
 …
26
Types de Client/Serveur
 Client/Serveur traditionnel :
 RPC (Remote procedure call).
 Client/Serveur à objets :
 RMI (Remote Method Invocation) : communique des objets java.
 CORBA : n’importe quel langage.
 …
 Client/Serveur de données :
 Requêtes SQL pour communiquer avec une base de donnée MySQL par exemple.
27
Types de Client/Serveur
 Client/Serveur traditionnel :
 RPC (Remote procedure call).
 Client/Serveur à objets :
 RMI (Remote Method Invocation) : communique des objets java.
 CORBA : n’importe quel langage.
 …
 Client/Serveur de données :
 Requêtes SQL pour communiquer avec une base de donnée MySQL par exemple.
 Client/Serveur WEB :
 Pages web statiques avec HTML.
 Pages web dynamiques avec PHP.
 Servlets (*.java) sont des classes Java exécutées par le serveur en réponse à une
requête du client (en utilisant le protocole http).
 JSP (JavaServer Pages) (*.jsp) représentant un code HTML dans lequel du code
Java est appelé.
RPC, RMI, CORBA, JSP.. : Modèles d’exécution pour le client / serveur
28
Exemple : Application web dans un environnement WAMP
(Windows, Apache, MySQL, PHP)
Serveur Web : Apache (serveur HTTP)
Page HTML avec
du code PHP intégré
HTML
(1) : Demande de la page
PHP
(4) : Renvoi de la page HTML
(2) : demande de l’aide au
générateur de pages dynamiques
Interpréteur PHP
Poste Client
Page HTML avec les résultats
donnés par l’exécution du
programme PHP
HTML
(3) : demande des données
à la base de données : SQL
MySQL
Serveur de base de données
29
Diffusion de messages (broadcast)
 2 rôles distincts :
 Emetteur : envoie des messages (ou événements) à destination de tous les
récepteurs.
 Possibilité de préciser un sous-ensemble de récepteurs (multicast).
 Récepteurs : reçoivent les messages envoyés.
 Interaction :
 Emetteur envoie un message.
 Le middleware s’occupe de transmettre ce message à chaque récepteur.
Multicast
Broadcast
 Modèle d’exécution : Message Oriented Middleware (MOM).
 Package javax.jms permet d’implémenter une architecture de type MOM.
 JMS : Java Message Service.
30
Diffusion de messages (broadcast)
 2 modes de réception :
 Le récepteur va vérifier lui-même qu’il a reçu un message.
 Boîte
aux lettres.
 Le récepteur est prévenu que le message est disponible et il lui est transmis.
 Le
facteur sonne à la porte pour remettre en main propre le
courrier.
 Particularités du modèle :
 Dépendance plus faible entre les participants.
 Pas
besoin pour l’émetteur d’être directement connecté aux récepteurs ni
même de savoir combien ils sont.
 Interaction de type « 1 vers N ».
31
Modèle pair à pair (peer to peer / P2P)
 Un seul rôle : pas de distinction entre les participants.
 Chaque participant est connecté avec tous les participants d’un groupe et tout le
monde effectue les mêmes types d’actions pour partager des données.
 Exemples :
 Modèles d’échanges de fichiers (e-mule, bit-torrent).
 Avec parfois un mode hybride client/serveur – P2P.
 Serveur sert à connaître la liste des fichiers et effectuer des recherches.
 Le mode P2P est utilisé ensuite pour les transferts.
 Chacun envoie une partie du fichier à d’autres participants.
 Skype emploie une technique P2P VoIP (mélange de P2P et de VoIP (voix sur
IP)) pour se connecter avec les autres utilisateurs de Skype.
32
Client/serveur vs P2P
Servent est la contraction du mot serveur et client. Ce terme est souvent
utilisé pour désigner les logiciels P2P.
33
Type de communication (synchrone/asynchrone)
Communication synchrone : même notion de temps, transmission instantanée,
généralement bornée.
34
Type de communication (synchrone/asynchrone)
Communication asynchrone
35
Partie III :
Algorithmique distribuée
36
Voies d’études des systèmes distribués
 Approche « descriptive »
 Etude de modèles de conception d’applications réparties (client-serveur, objets
répartis, architecture).
 Etude de middleware, d’applications et de leurs modes d’organisation et de
fonctionnement.
37
Voies d’études des systèmes distribués
 Approche « descriptive »
 Etude de modèles de conception d’applications réparties (client-serveur, objets
répartis, architecture).
 Etude de middleware, d’applications et de leurs modes d’organisation et de
fonctionnement.
 Approche « fondamentale » : algorithmique distribuée
 Etude des principes de base : problèmes fondamentaux, solutions connues.
 Exemples : Election d’un chef, structure de diffusion, exclusion mutuelle,
détection de la terminaison.
38
Exemples de problèmes fondamentaux
 Comment décrire une exécution répartie ?
 Comment coordonner des opérations en l’absence d’horloge commune ?
 Quelles sont les critères de qualité pour une application distribuée ?
 Comment garantir la cohérence d’informations distribuées ?
39
Éléments de base d’un système distribué
 Processus communiquant.
 Canaux de communication.
Processus E
Processus R
Tampon Emission
Tampon Réception
Canal
40
Processus
 Élément logiciel effectuant un ensemble d’instructions.
 Une instruction correspond à un événement local au processus.
 Dont
les événements d’émission et de réception de messages.
 Il possède une mémoire locale.
 Il possède un état local.
 Ensemble de ses données et des valeurs de ses variables locales.
 Il possède un identifiant qu’il connaît.
 Pas ou peu de connaissance des autres processus du système et de leur état.
 Les processus d’un système s’exécutent en parallèle.
41
Canal de communication
 Canal de communication point à point entre 2 processus.
 Caractéristiques :
 Uni ou bi-directionnel.
 Fiable ou non : perd/modifie ou pas des messages.
 Ordre de réception par rapport à l’émission.
 FIFO
= les messages sont reçus dans l’ordre où ils sont émis.
 Synchrone ou asynchrone.
 Synchrone
: l’émetteur et le récepteur se synchronisent pour réaliser
l’émission et/ou la réception.
 Asynchrone
: pas de synchronisation entre émetteur et récepteur.
 Taille des tampons de message cotés émetteur et récepteur.
 Limitée
ou illimitée
42
Modèle des sockets TCP
 Fiable.
 FIFO.
 Bidirectionnel.
 Asynchrone en émission.
 Emetteur n’est pas bloqué quand il émet quoique fasse le récepteur.
 Synchrone pour la réception.
 On reçoit quand l’émetteur émet.
 Sauf si données non lues dans le tampon coté récepteur.
 Taille limitée des tampons.
43
Performances d’un canal
 Latence : délai entre l’émission d’un message et sa réception.
 Bande passante : nombre d’informations transitant par unité de temps
exprimé en bits/seconde.
 Gigue : variation de temps pour délivrer des messages d’une série (variation
de la latence).
 Important dans le cadre des données multimédia nécessitant des
synchronisations.
 La voix sur IP.
 Perte de messages : due à des phénomènes de congestion sur le réseau.
44
Vers des modèles
 Modéliser pour :
 Représenter un système en simplifiant divers aspect du réel.
 Observer et comprendre le comportement d’un système.
 Prédire ou aider à commander le comportement d’un système.
 Prouver ce comportement à l’aide de techniques formelles.
 Maîtriser la complexité d’un système.
45
Modèles conceptuels de systèmes distribués
 On modélise un système distribué selon plusieurs dimensions.
 Modèle d’interaction.

Modèle de canal.

Modèle temporel.
 Modèle de fautes.
 Modèle de sécurité.
 Non
traité dans ce cours.
46
Modèle d’interaction d’un système distribué
 Contient un modèle de canal et un modèle temporel.
 Modèle de canal : uni ou bi-directionnel, fiable ou non, ordre de réception par
rapport à l’émission, synchrone ou asynchrone, taille des tampons de message cotés
émetteur et récepteur.
 Modèle temporel : deux modèles principaux :
 Système distribué synchrone : possède les 3 caractéristiques suivantes :

Le temps pour exécuter une étape du processus est compris entre une borne
min et une borne max connues.

Un message émis est reçu dans un délai max connu.

L’horloge locale d’un processus dérive au plus d’une certaine durée connue et
bornée du temps réel.
 Système distribué asynchrone : il n’y aucune borne.

Sur la durée d’exécution d’une étape du processus.

Sur le délai de réception d’un message.

Sur la dérive de l’horloge locale d’un processus par rapport au temps réel.
47
Synchrone/Asynchrone
 Un modèle synchrone est un modèle où les contraintes temporelles sont
bornées.
 On sait qu’un processus évoluera dans un temps borné.
 On sait qu’un message arrivera en un certain délai.
 On connaît la limite de dérive des horloges locales.
 Un modèle asynchrone n’offre aucune borne temporelle.
 Modèle bien plus contraignant et rendant impossible ou difficile la mise
en œuvre de certains algorithmes distribués.
48
Modèle de fautes
 4 grands types de fautes ou pannes :
 Franches : le processus ne fait plus rien.
 Par omission : des messages sont perdus ou non délivrés.
 Arbitraires ou byzantines : le processus renvoie des valeurs fausses
et/ou fait «n’importe quoi», ne respectant pas ses spécifications, en
donnant des résultats non-conformes.
 Cas
de fautes les plus complexes à gérer.
 Temporelles : uniquement pour un système distribué synchrone
(dépassement des bornes temporelles).
Processus correct : processus non planté, qui ne fait pas de fautes.
49
Fautes Franches
 Le processus ne fait plus rien.
 Classification des fautes :
 Crash-stop : un processus s’arrête et reste hors-service.
 Crash-recovery : un processus s’arrête mais il peut se relancer après un
certain temps.
50
Fautes par omission
 Processus ou canal ne réalise pas une action.
 Classification des fautes :
 Omission du canal : un message positionné dans un tampon d’émission
d’un processus n’arrive jamais dans le tampon de réception du
destinataire.
 Omission en émission : un processus envoie un message mais il n’est
pas placé dans le tampon d’émission.
 Omission en réception : un message est placé dans le tampon de
réception d’un processus mais le processus ne le reçoit pas.
51
Fautes arbitraires/byzantines
 Fautes quelconques et souvent difficilement détectables.
 Processus :
 Calcul erroné ou non fait.
 État interne faux.
 Valeur fausse renvoyée pour une requête.
 Canal :
 Message modifié, dupliqué voire supprimé.
 Message « créé ».
 En pratique peu de fautes arbitraires sur les canaux car les couches
réseaux assurent la fiabilité de la communication.
52
Fautes arbitraires/byzantines
 On distingue couramment les pannes byzantines naturelles des pannes
byzantines volontaires.
 Pannes byzantines naturelles proviennent généralement d’erreurs
physiques non détectées (mémoire, transmissions réseaux, etc.).
 Pannes byzantines volontaires proviennent principalement d’attaques
visant à faire échouer le système (sabotage, virus, etc.).
53
Fautes temporelles
 Uniquement pour un système distribué synchrone : dépassement des bornes
temporelles.
 Une étape du processus s’exécute en plus de temps que la borne prévue.
 Un message émis est reçu après un délai supérieur à la borne prévue.
 L’horloge locale dérive d’une valeur supérieure à la borne prévue.
54
Résumé sur les fautes
4 grands types de pannes
Arbitraires
Franches
Par omission
ou
Temporelles
byzantines
Crash-stop
Naturelles
Crash-recovery
Volontaires
Omission du canal
Omission en réception
Omission en émission
55
Détecteur de pannes
 Définition : élément associé aux processus «essayant» de déterminer l’état des
autres processus.
 Généralement, on se base sur une communication fiable.
 Messages non
perdus.
 Classification des caractéristiques des détecteurs :
 Complétude : un processus fautif est soupçonné de l’être par un
processus correct.
 Exactitude : un processus correct n’est jamais soupçonné par aucun
processus correct.
 Deux variantes à chaque fois :

Forte : par tous les processus.

Faible : par au moins un processus.
56
Classification de détecteurs de pannes
 Complétude :
 Forte : tout processus fautif finit par être soupçonné par tous les
processus corrects.
 Faible : tout processus fautif finit par être soupçonné par au moins un
processus correct.
 Les deux complétudes sont équivalentes :
 Par principe, la forte implique la faible.
 La faible implique la forte.
 Localement,
un détecteur gère la liste des processus qu’il soupçonne
comme fautifs.
 Les

détecteurs s’échangent leurs listes via diffusion.
Au bout d’un certain temps, un processus soupçonné fautif sera
référencé comme fautif par tous les processus.
 Hypothèse
valable si diffusion fiable.
57
Classification de détecteurs de pannes
 Exactitude :
 Version totale :
 Forte
: aucun processus correct n’est jamais soupçonné par aucun
processus correct.
 Faible
: au moins un processus correct n’est jamais soupçonné par
aucun processus correct.
 Version plus faibles : vérifiée au bout d’un certain temps.
 Finalement
forte : au bout d’un certain temps, aucun processus
correct n’est plus jamais soupçonné par aucun processus correct.
 Finalement
faible : au bout d’un certain temps, au moins un
processus correct n’est plus jamais soupçonné par aucun processus
correct.
58
Classification de détecteurs de pannes
 Au final, 8 combinaisons :
Exactitude
Forte
Complétude
Forte
Faible
Finalement
Forte
Finalement
Faible
P
Faible
Mais complétude forte équivalent à la faible, reste donc 4 combinaisons.
Détecteur parfait (fiable) : classe P(erfect).
Complétude et exactitude fortes.
 Tout processus fautif finit par être soupçonné par tous les processus corrects.
 Aucun processus correct n’est jamais soupçonné par aucun processus correct.
59
Réalisation de détecteurs de pannes : synchrone vs asynchrone
 Système synchrone (timeouts pour détecter les pannes).
DélaiTrans.
DélaiTrans.
DélaiTrait.
T = 2 DélaiTrans. + DélaiTrait.
60
Réalisation de détecteurs de pannes : synchrone vs asynchrone
 Système synchrone (timeouts pour détecter les pannes).
DélaiTrans.
DélaiTrans.
DélaiTrait.
T = 2 DélaiTrans. + DélaiTrait.
 Système asynchrone : difficulté (voire impossibilité) de différencier un
message lent d’un processus mort.
 Importance des délais de garde.

Trop petit : soupçonne avec erreur des processus.

Trop grand : temps long avant de détecter la mort d’un processus.
61
Réalisation de détecteurs de pannes : synchrone vs asynchrone
 Système synchrone :
 Grace au délai borné de réception des messages, on sait qu’on recevra un
message dans un certain délai si le processus est vivant.
 Peut construire un détecteur de pannes fiable (parfait).
 Système asynchrone :
 Temps de propagation des messages non bornés.
 Difficulté
(voire impossibilité) de différencier un message lent d’un
processus mort.
 Détecteur parfait est non réalisable dans un système asynchrone.
 Mais
souvent on peut se contenter de détecteurs imparfaits.
62
Bibliographie
63
Algorithmique distribuée
 Algorithmique et techniques de base des systèmes répartis, Sacha
Krakowiak, Cours de M2 recherche "Systèmes et Logiciel", Université Joseph
Fournier (Grenoble).
 http://proton.inrialpes.fr/~krakowia/Enseignement/M2R-SL/SR/
 Conception des Systèmes répartis, Gérard Padiou, enseignements à
l’ENSEEIHT (Toulouse).
 http://padiou.perso.enseeiht.fr/
 Synchronisation et état global dans les systèmes répartis, Serge Raynal,
Eyrolles, 1992.
64