Systmes rpartis Systmes rpartis

Fabrice Rossi http://apiacoa.org/contact.html. Universit Paris-IX Dauphine e

Dnition trs large : un systme rparti est systme informatique dans lequel les ressources ne sont pas centralises Ressources au sens trs large : stockage (disques, bases de donnes) puissance de calcul utilisateurs But : permettre des utilisateurs de manipuler (calcul) leurs donnes (stockage) sans contrainte sur les localisations respectives des lments du systme Gnralisation et amlioration du schma client/serveur : serveurs multiples (quilibrage de charge, redondance) systmes multi-couches (tiers) peer to peer rparti distribu
Syst`mes rpartis p.1/49 e e Syst`mes rpartis p.2/49 e e

Exemples
DNS annuaires X500 Web Systmes multi-couches base de donnes repartie base de donnes repartie ordinateur rparti : donnes, traitement, etc architecture classique pour les systmes mlangeant serveur web, base de donnes, traitement volu, etc systme compltement dcentralis, en gnral pour le stockage rparti calcul rparti super-ordinateur pour le calcul et le stockage rparti
Syst`mes rpartis p.3/49 e e

Exemple : le DNS
Exemple typique dun systme rparti (1984) : DNS : Domain Name System le systme qui permet de trouver ladresse IP associe un nom de machine exemple : www.dauphine.fr 193.49.168.65 DNS : une base de donnes rpartie Rappels TCP/IP : Internet Protocol (IP) : couche rseau base entirement sur ladresse IP (transmission directe au sein dun sous-rseau, par routeur en dehors) Transmission Control Protocol (TCP) : couche transport qui assure larrive des paquets une sorte de systme rparti : pas de contrle central, routes alternatives, etc.

peer to peer

Clusters Grid

Syst`mes rpartis p.4/49 e e

DNS : Architecture logique

systme hirarchique : arbre avec un nom par noeud le nom de la racine est vide chaque noeud est associ des enregistrements (A pour ladresse IP, MX pour le serveur de mail, etc.) domaine : sous-arbre dauphine est un sous-domaine du domaine fr ufrmd sous-domaine de dauphine nom de domaine : nom dun noeud (dauphine) nom complet : suite des noms des noeuds en remontant dans larbre, spars par . et sans prendre en compte la racine : www.dauphine.fr www.ufrmd.dauphine.fr

DNS : exemple
racine (nom vide)

org sens de lecture linuxfr slashdot

fr

sousdomaine

dauphine

www

ceremade

www

Syst`mes rpartis p.5/49 e e

Syst`mes rpartis p.6/49 e e

DNS : architecture physique

Tout est bas sur un systme de dlgation et de rplication : un serveur DNS gre un domaine chaque domaine est gr par aux moins 2 serveurs le protocole DNS propose un mcanisme de rplication (un serveur matre et des esclaves) le gestionnaire dun domaine peut dlguer la gestion dun sous-domaine un autre gestionnaire : fr dlgue la gestion de dauphine.fr aux serveurs de dauphine dauphine.fr dlgue ufrmd.dauphine.fr aux serveurs de lUFR MD, ceremade.dauphine.fr ceux du CEREMADE, etc. requtes : systme de cache local (TTL) dlgation de requte
Syst`mes rpartis p.7/49 e e

DNS : traitement dune requte

Je veux me connecter cvs-etud.ufrmd.dauphine.fr : 1. demande du serveur local un root server 2. rponse du root server : il faut demander un serveur fr (dlgation) 3. fr dauphine.fr 4. dauphine.fr ufrmd.dauphine.fr 5. ufrmd.dauphine.fr 193.51.89.162 Dans le cache aprs cette requte : adresses IP des serveurs DNS de fr, dauphine.fr et ufrmd.dauphine.fr adresse IP de la machine cvs-etud.ufrmd.dauphine.fr Prochaine requte : IP www.dauphine.fr requte directe dauphine.fr.
Syst`mes rpartis p.8/49 e e

Exemple : annuaires X500

Le DNS est un tel succs pratique que les annuaires X500 sont bass sur exactement le mme principe : annuaire : contient des enregistrements (entries) (exemple : une personne) chaque enregistrement contient des attributs typs (exemple : une adresse email) le type dun enregistrement est prcis (exemple : dans une personne, on doit avoir un email) le systme de type est hirarchique (modle de lhritage) systme rparti avec dlgation espace de nom global type DNS (hirarchique) recherche, modication, contrle daccs, etc. implmentation pratique : LDAPv3 (Lightweight Directory Access Protocol)
Syst`mes rpartis p.9/49 e e

Exemple : serveur web

Hyper Text Transfer Protocol (HTTP) : solution de base de type client/serveur intrinsquement rparti cause des liens (par exemple, toutes les requtes cgi peuvent tre excute sur un serveur diffrent du serveur principal) Evolutions : traitement sur le client (Javascript, Java, Flash, SVG, etc.) rpartition des calculs entre client et serveur quilibrage de charge (load balancing) : les requtes arrivent sur un serveur principal elles sont relayes (mcanisme de proxy ) sur plusieurs serveurs effectifs (grce mod_rewrite sous apache par exemple) programmes sur le serveur : cgi, servlet, langages de script serveur (JSP, PHP, ASP, etc.) base des architectures multi-niveau
Syst`mes rpartis p.10/49 e e

Serveur web basique

Clients Serveur

Equilibrage de charge
Serveur

Java

Clients Proxy

HTTP ActiveX HTTP

Serveur

Javascript

Syst`mes rpartis p.11/49 e e

Syst`mes rpartis p.12/49 e e

Exemple : Systmes multi-couches

Beaucoup dapplications classiques se dcoupent en plusieurs couches (ou niveau) : Prsentation : tout ce qui permet linteraction avec lutilisateur Application (Business ou Mtier) : toute la logique applicative (vrication des entres de lutilisateur, etc.) Stockage : stockage permanent des informations relatives lapplication Exemple en VPC : prsentation : site web, catalogue papier ( !) application : modalit de rduction, frais de port, identication du client, etc. stockage : SGBD (catalogue, stock, etc.), facturation, analyse des cots (ERP)

Systmes multi-couches : modles

On peut implmenter une application de nombreuses faons : Monolithique : les diffrents niveaux sont imbriqus dans un programme unique Deux couches : presque obligatoire quand on travaille avec un SGBD sur le serveur : le SGBD, avec une partie de la logique applicative (contraintes dintgrit, procdures stockes, etc.) sur le client : prsentation et lautre partie de lapplication Trois couches (ou plus) : client : prsentation des objets mtier objets mtier : toute la logique applicative SGBD : stockage des objets mtier

Syst`mes rpartis p.13/49 e e

Syst`mes rpartis p.14/49 e e

Multi-couches : avantages et inconvnients

Avantages : dcouplage : du code : maintenance plus facile des quipes : chacun son mtier (maquette, administration du SGBD, etc.) rpartition et donc quilibrage de la charge : serveur web (prsentation) serveur des objets mtier SGBD Inconvnients : efcacit bande passante difcult de mise en uvre (conception et programmation dlicates)

Couche de prsentation
Une technique classique, les extensions sur le serveur : cgi (en C, C++, Perl) versions embarques dans le serveur (mod_perl), ou dans un container (Servlet en Java) relativement lourd : il faut produire le code HTML la main dans le programme quilibrage de charge classique : pages statiques sur un serveur, pages dynamiques sur dautres (par exemple) Servlet : quilibrage intgr (le moteur de servlet Tomcat est indpendant du serveur web) Problme : comment accder la couche mtier ?

Syst`mes rpartis p.15/49 e e

Syst`mes rpartis p.16/49 e e

Couche de prsentation (2)

Technique plus facile dutilisation, les langages embarqus : intgration des commandes dans le code HTML JSP (Java), ASP (Visual Basic ( !)), Embperl (Perl), PHP (langage spcique), etc. quilibrage parfois trs volu : le moteur JSP Tomcat est indpendant du serveur web Mme problme que les extensions : comment accder la couche mtier ?

Couche mtier
Accs direct au SGBD : solutions classiques et standardises : ODBC et JDBC solutions spciques : interface SGBD de Perl, de PHP, etc. problme : expertise SQL (transactions par exemple) Accs masqu au SGBD : persistance automatique (EJB CMP et JDO pour Java par exemple) solutions relativement nouvelles srement lavenir Lien avec la couche de prsentation : solution basique : bibliothque (i.e., le code mtier est excut par la couche de prsentation) approche distribue : cest un des objets de ce cours !
Syst`mes rpartis p.18/49 e e

Syst`mes rpartis p.17/49 e e

Exemple multi-couches
HTML+JSP HTTP Interprtation des JSP

Exemple : peer to peer

Principe : peer to peer pur : pas de serveur ; connexions directes entre les participants peer to peer pratique : lessentiel des communications seffectue entre les participants (mais il reste des serveurs) Buts : trs forte resistance la panne partage de la bande passante Exemples : Napster (serveur central) Edonkey 2000 (plusieurs serveurs) Freenet et overnet (peer to peer pur)

Spcifique

client

serveur web

Tomcat

???

On peut ajouter des serveurs chaque niveau

JDBC

SGBD

objets mtier
Syst`mes rpartis p.19/49 e e Syst`mes rpartis p.20/49 e e

Edonkey 2000
But : piratage (soyons clair !) ou (en langue de bois) partage de documents. Architecture : tout le monde peut devenir serveur sur le serveur : liste des clients pour chaque client : liste des documents proposs au tlchargement communication client vers serveur : le client demande un document le serveur lui renvoie la liste des clients qui possdent le document communication client vers client : tlchargement des documents morceaux par morceaux (un client peut tlcharger une partie dun document dun client et le reste dun autre)
Syst`mes rpartis p.21/49 e e

Edonkey 2000
requtes tendues Serveur Client abba.mp3 pamela.jpg lordoftherings.avi a b c a a d e Client Client d ... ... e ... ... ... ... ... ... ... Client Serveur Client

Client a

Client b

Client c

Client

Client

b tlcharge lordoftherings.avi

Requtes tendues : depuis un client vers un autre serveur.

Syst`mes rpartis p.22/49 e e

Freenet
Mmes buts ! Architecture : vritable peer to peer aucun serveur recherche dun document : un client demande un document ses amis (autres clients) quand un client reoit une requte de documents laquelle il ne peut pas rpondre, il propage cette requte dautres clients la rponse suit le chemin inverse condentialit forte : tout est crypt Dans les deux cas (Edonkey 2000 et Freenet), on obtient une sorte de systme de chiers distribu.
initiateur de la recherche 3

Freenet
4 5 6 1 7 recherche donnes erreur

propritaire initial des donnes

Dessin daprs les documents de conception de freenet.

pas de boucle routage bas sur les cls des documents

Syst`mes rpartis p.23/49 e e

Syst`mes rpartis p.24/49 e e

Exemple : les clusters

La puissance de calcul dun microprocesseur est souvent insufsante : simulations en physique, chimie, ingnierie, etc. effets spciaux et images de synthse intelligence articielle (jeu dchecs, etc.) ... Solution simple, les systmes multi-processeurs symtriques (SMP) : plusieurs processeurs dans un mme ordinateur mmoire partage threads Quand cest encore insufsant, les clusters : plusieurs ordinateurs (ventuellement SMP) connexion haut dbits (ethernet 100Mb, plusieurs cartes par machine)
Syst`mes rpartis p.25/49 e e

Les clusters
En gnral (Beowulf, Mosix, etc.) : processus, i.e., mmoire non partage passage de message transparence rseau totale : deux processus communiquent comme si ils taient sur la mme machine migration de processus quilibrage dynamique de la charge Problmes : programmation parallle trs dlicate pas de vrai standard pas de mmoire partage rpartie

Syst`mes rpartis p.26/49 e e

Les Grid
Quand un cluster ne suft pas, on passe au grid : plusieurs ordinateurs (beaucoup !) pas de contrainte de gographie (un grid peut mettre en commun des ordinateurs rpartis dans plusieurs pays) architectures physiques et logicielles htrognes Exemples : Seti@Home et toutes ses variantes supers calculateurs (NASA, NSF, etc.) Commentaires : lavenir des super-calculateurs pas encore de norme programmation trs dlicate problmes de scurit

Les problmes
Ces exemples illustrent les problmes classiques des systmes rpartis : communication : lossature de tout systme rparti la zone de compromis entre efcacit et facilit de programmation htrognit : portabilit interoprabilit scurit : authentication droits daccs (politiques de scurit) dploiement administration

Syst`mes rpartis p.27/49 e e

Syst`mes rpartis p.28/49 e e

Communication dans un systme rparti

Plusieurs niveaux dabstraction : bas niveau : socket niveau intermdiaire : transparence rseau pour les appels de fonction (Remote Procedure Call), systmes base de messages (PVM, MPI, SOAP, etc.) haut niveau : transparence rseau pour les objets (Object Request Broker ) trs haut niveau : objets rpartis et objets mobiles Actuellement : protocoles spcialiss : bas niveau (DNS, LDAP, etc.) applications multi-couches : RPC ou ORB calcul distribu (cluster et grid) : PVM et MPI web services : SOAP Avenir : ? ? ?

Sockets
Rappels : connexion stable (TCP) bi-directionnelle entre deux programmes fonctionnent comme des chiers : le descriptor en C, stream en Java trs bas niveau : il faut connatre ladresse ip et le numro de port du serveur pas de transparence rseau gestion par le programmeur du protocole (langue parle par le serveur) souple efcace interoprable avec un bon protocole (difcile) on peut faire encore plus efcace : User Datagram Protocol (UDP). Encore plus bas niveau (pas de connexion).
Syst`mes rpartis p.30/49 e e

Syst`mes rpartis p.29/49 e e

Sockets (2)
Beaucoup de solutions actuelles sont bases sur TCP ou mme sur UDP : client/serveur TCP : Simple Mail Transfer Protocol, File Transfer Protocol, Hyper Text Transfer Protocol, etc. systmes rpartis : Domain Name System (UDP pour les requtes, TCP pour le reste) Lightweight Directory Access Protocol TCP Edonkey 2000 (UDP et TCP) freenet (implmentable au dessus de diverses mthodes de transport, mais en gnral TCP) jeux en rseaux etc.

Sockets (3)
Mise en uvre dlicate car il faut tout faire : mettre au point un protocole : mise en place de la connexion (scurit) commandes reconnues par le serveur (paramtres et rsultats) codes derreur etc. programmer le serveur fournir une API pour le client (sinon le client doit parler directement au serveur) fournir un minimum de transparence rseau tre interoprable (exemple bid endian et little endian) Difcile et surtout trs redondant automatiser ce processus.
Syst`mes rpartis p.31/49 e e Syst`mes rpartis p.32/49 e e

Vers le haut niveau

Que peut-on automatiser ? reprsentation portable des donnes passage de messages appel de fonctions distance objets distants objets rpartis objets mobiles ???

eXternal Data Representation (XDR)

Une grosse difcult redondante : la reprsentation interne des donnes dpend dans la machine (bid endian et little endian par exemple). Une solution XDR : norme issue de SUN (RFC 1832) et de lONC systme de reprsentation des donnes indpendant du hardware : prcise lordre des octets (bid endian) orient C (int, oat, struct, etc.) langage de description des types trs inspir du C. Exemple : 1 const MAXNAME = 20; 2 struct person { 3 string firstname<MAXNAME>; 4 string lastname<MAXNAME>; 5 };

Syst`mes rpartis p.33/49 e e

Syst`mes rpartis p.34/49 e e

Reprsentation des donnes : autres solutions

De trs nombreuses autres solutions sont disponibles : Network Data Representation Mme principe que XDR, mais propos par lOpen Group (ex Open Software Foundation) Elment de Distributed Computing Environement Relativement rpandu sous Unix mais pas sous Linux XML-RPC Contient entre autre une reprsentation de donnes structures en XML A la mode... Simple Object Access Protocol Evolution de XML-RPC dnie par le W3 Reprsentation de donnes structures en XML (modle des types des schmas) Trs la mode...
Syst`mes rpartis p.35/49 e e

Systmes messages : PVM

Le standard des cluster s est Parallel Virtual Machine : cible : cluster de machines (htrogne) un programme PVM est un ensemble de processus transparence rseau totale : chaque processus est identi par un id qui est utilis le contrle et la communication message : bloc de mmoire rendu indpendant de la machine grce XDR communication optimise : mmoire partage sur une mme machine, TCP sinon API C (C++) et fortran Grand pas en avant : optimisation automatique, transparence rseau, portabilit des donnes et du code, interoprabilit.

Syst`mes rpartis p.36/49 e e

Systmes messages : MPI

Message Passing Interface est lautre standard des clusters et super-ordinateurs : cible : machines parallles plus de primitives de communication que PVM (broadcast, etc.) en gnral plus efcace que PVM sur les machines parallles portable Contrairement PVM, il faut ajouter une sur-couche (MPICHG2 version Grid de MPI) pour obtenir la transparence rseau, linteroprabilit, la tolrance la panne, etc.

Systmes messages
Avantages : portabilit transparence rseau interoprabilit efcacit Inconvnients : messages de bas niveau (au mieux struct) technique de programmation spcique (ni procdurale, ni objet) Autres solutions bases sur des messages, beaucoup moins orientes clusters : SOAP Java Message Service Ce sont des solutions de plus haut niveau, en gnral moins efcaces mais plus accessibles.

Syst`mes rpartis p.37/49 e e

Syst`mes rpartis p.38/49 e e

Appel de fonctions distance (RPC)

Ide de base : proposer au programmeur la transparence rseau pour les appels de fonctions. Quelques solutions : ONC Remote Procedure Call (C, Sun) DCE Remote Procedure Call (C, Open Group) Remote Methode Invocation (Java, Sun) XML RPC (tout langage, Userland) SOAP (tout langage, W3C) Principe de base : le client appelle une fonction normale un code local transforme lappel de fonction en un message (au sens large), envoy au serveur un code sur le serveur transforme le message en un appel de fonction le serveur excute lappel de fonction mme chose en sens inverse pour la rponse du serveur
Syst`mes rpartis p.39/49 e e

Les RPC
Vocabulaire : souche (stub) : reprsentant local du serveur traduction de lappel local en message squelette (skeleton) : quivalent de la souche sur le serveur traduction du message en appel local empaquetage (marshalling) : reprsentation des donnes de lappel (ou du rsultat) sous forme dun message dpaquetage (unmarshalling) : opration inverse Premire brique du RPC, la reprsentation des donnes interoprable : XDR pour les RPC ONC NDR pour les RPC DCE XML pour XML RPC et son successeur SOAP Srialisation Java pour RMI (pas seulement)

Syst`mes rpartis p.40/49 e e

Les RPC ONC et DCE

RPC classiques : orients programmation procdurale (C) limitent le travail du programmeur : un langage permet de dcrire la fonction (extension de XDR par exemple) un programme adapt engendre partir du langage le stub et le skeleton il reste programmer : la fonction intgrer au serveur le client (connexion au serveur et appel de la fonction) fonctionnent essentiellement avec TCP et UDP exemple incontournable : Network File System DCE ONC + scurit + threads

Les RPC bass sur XML

Principe de base, reprsentation des donnes en XML : XML RPC : trs simple la spcication donne seulement la reprsentation dun appel de fonction en XML ne dpend pas du langage source le transport est assur par HTTP SOAP : beaucoup plus ambitieux format de message au sens gnral indpendant du transport (HTTP, Mail, etc.) les outils proposs autour de XML RPC et de SOAP sont intoprables mais non standard relativement haut niveau

Syst`mes rpartis p.41/49 e e

Syst`mes rpartis p.42/49 e e

Remote Methode Invocation (RMI)

Technologie spcique Java : RPC en Java orient objet trs intgr Java : pas de langage extrieur par exemple travail minimal pour le programmeur Mme sil sagit dune technique RPC, elle est trop orient objet pour tre vraiment comparable avec les autres techniques. Voir la suite pour les liens avec CORBA.

Appel de fonctions distance

Avantages des RPC ONC et DCE : transparence rseau portabilit grce aux standards interoprabilit (idem) indpendant du langage bonnes performances en gnral pour les RPC ONC et DCE Inconvnient : orient procdure (dpass). Avantages des RPC XML : haut niveau (sans tre objet) intgration internet trs forte (Web services) Inconvnients : technologies trs rcentes performances en retrait

Syst`mes rpartis p.43/49 e e

Syst`mes rpartis p.44/49 e e

Objects distants
Appel de mthodes distance, RPC objets : ide de base : apporter les bnces de lobjet aux systmes rpartis. Par exemple : encapsulation polymorphisme etc. plusieurs grands standards : CORBA (Common Object Request Broker Architecture) Java RMI Microsoft COM+/DCOM (Distributed Component Object Model) tous bass sur la notion dinterface et sur des mcanismes de bas niveau semblables ceux utiliss par les RPC

CORBA
A la fois lanctre et le standard : norme de lObject Management Group version actuelle 3.0.2 (dcembre 2002) bas sur un bus logiciel, lObjet Request Broker (ORB) totalement interoprable : les objets sont dcrits en IDL (Interface Denition Language) implments dans nimporte quel langage (Java, C++, C, etc.) les ORB sont des plus en plus compatibles, mme au niveau source nombreuses implmentations, commerciales et open source, mais pas toujours en accord avec la norme (en gnral, la norme 2.4 est supporte)

Syst`mes rpartis p.45/49 e e

Syst`mes rpartis p.46/49 e e

Java RMI
Les RPC objets version Java. Deux versions : Java Remote Method Protocol Internet InterORB Protocol (celui de CORBA) JRMP est spcique Java et donc trs intgr la plate-forme : programmation minimale concepts Java en version rpartie (par exemple Garbage Collecting rparti) portabilit au sens Java ne peut communiquer quavec une autre JVM RMI-IIOP est bas sur le protocole de CORBA : programmation plus complexe (mais pas besoin dIDL) intgration moins bonne interoprable

COM+/DCOM
Solution Microsoft base sur COM+ et sur les RPC DCE : propritaire Microsoft (des portages commerciaux existent) multi-langage (IDL) Garbage Collecting rparti programmation plus lourde que CORBA (trs verbeux) accs aux services de Windows Intrts limits par rapport CORBA, sauf en environnement 100% Microsoft.

Syst`mes rpartis p.47/49 e e

Syst`mes rpartis p.48/49 e e

Trs haut niveau

Diffusion plus condentielle et outils plus exprimentaux : objets rpartis : lespace de stockage allou lobjet est effectivement rparti sur les diffrents clients gestion des rpliques, contrle de modication, etc. objets mobiles : objet (i.e., donnes et code) libre de passer dune machine une autre lobjet bouge mais nest pas accessible distance exemple volu : agent capable denchrir sur un site de type ebay

Syst`mes rpartis p.49/49 e e