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