systèmes distribués

Mastère MIAGE, 2006

Systèmes Distribués

Fabrice [email protected]

2Mastère MIAGE, 2006

Thèmes, ÉvaluationThèmes: • Introduction aux systèmes distribués

– Matériel, Logiciel– Communications– Synchronisation

• Outils pour la programmation– Sockets– RPC– Java-RMI

• Introduction aux systèmes Pair-à-Pair

Évaluation• Un mini projet à rendre en binomes• Examen


1- Introduction aux Systèmes Distribués

“… no man is an island, entire of itself; every man is a piece of the

continent, a part of the main.”John Donne (1572-1631).

“The network is the computer”Sun Microsystems, 1985.


Petites définitions

• Pleins de définitions possibles pour un SD:– Un système distribué est une collection

d’ordinateurs indépendants qui apparaissent à l’utilisateur comme un unique système cohérent

– Un système distribué est un ensemble de programmes, s’exécutant sur des ordinateurs différents, reliés par un réseau, et s’échangeant des informations pour exécuter une tache.

• Élément d’un SD– Un élément physique d’un SD (par exemple un

processeur) est appelé hôte ou noeud


Identifier un système distribué

• Comment déterminer si un système est un SD ?

est-ce que c’est…..

– La distance géographique entre les nœuds ? – Le nombre de nœuds disponibles ?– Le système d’exploitation, les protocoles, l’api

utilisés ?


La taille ? Non

• Il y en a de toutes les tailles

– Les sondes contrôlées depuis la terre• Millions de kms• Seulement quelques noeuds (Mars Pathfinder,

1997)

– Internet• Milliers de kms,• Millions de noeuds


• Tailles intermédiaires

– Ordinateurs reliés à une imprimante• ~ 10 mètres• ~ 10 nœuds

– Caisse enregistreuse dans un supermarché• ~ 100 mètres• ~ 100 nœuds

La taille ? Non


• Très petits– Home Cinéma

• ~ 1 mètre• 3-5 noeuds (TV, Stéreo, DVD,…)

– Voitures (GPS, ABS, alarme, ...)• Quelques mètres

– Plein de noeuds– 40% du coût d’une voiture moderne est lié à

l’électronique

– Personal Area Networks• ~ 1 mètre• 3-5 noeuds (montre, portable, PDA, lunettes…)

La taille ? Non


SD vs. Systèmes centralisés

• Quelle sont les différences entre un SD et un système centralisé (ou mono-processeur)– Un système centralisé est un système qui

fonctionne toujours si la connexion réseau est coupée

– Exemples:• Compilateur• Traitements de texte• Certains jeux • Systèmes d’exploitation pour ordinateurs familiaux

(mais de moins en moins vrai)


• Différences principales– Plus un unique espace d’adressage

• Un programme sur un nœud ne peut pas accéder directement aux données d’un autre programme sur un autre nœud.

– Les programmes s’exécutent indépendamment

– Vraie parallélisme (et concurrence) entre les programmes

– Pas d’horloge globale, chaque exécution est différente

– Les communications se font en envoyant des informations sur le réseau

– La latence à un impact important– Les pannes sont courantes



• Objectifs:– Transparence

• Masquer la distribution– Dégradation progressive

• Un système devrait continuer à fonctionner aussi correctement que possible si une de ses parties tombe en panne.

• Les systèmes centralisés tombent en panne complètement.

– Passage à l’échelle• Un SD devrait être capable de gérer un grand

nombre de noeuds.– Hétérogénéité

• Les nœuds peuvent être d’architecture différente, avoir des OS différents…



• Le concept de transparence peut-être appliqué à plusieurs aspects– Localisation : où se trouve la

ressource– Migration : déplacement de la

ressource– Réplication : plusieurs ressources– Concurrence : plusieurs utilisateurs– Panne : panne ou réparation– Persistance : sauvegarde de la

ressource

Transparence


• La centralisation limite le passage à l’échelle– Service centralisé : un unique serveur– Données centralisées : unique point d’accès

pour les données– Algorithmes centralisés : nécessite une

connaissance globale du système• La latence est aussi un facteur limitant• Mais il existe de nombreuses techniques

pour contourner ces problèmes– Serveurs multiples (ex: CDN - DNS)– Bases de données réparties (ex: DNS)– Algorithmes utilisant des informations

partielles (ex: P2P)

Passage à l’échelle


• Il est plus facile de se rappeler d’un mot/phrase que d’une série de chiffres…

• Les noms de domaine sont des suites alphanumériques de caractères séparées par des points

• Chaque segment a une taille/valeur arbitraire (mais limitée)

• Le segment le plus significatif (le plus à droite) est normalisé – com, edu, gov, info, org, net, biz…

• La transformation du nom de domaine en adresse IP se fait en contactant un serveur de domaine (DNS)

• Les serveurs DNS sont organisés hiérarchiquement• Au sommet se trouvent les serveurs racine • Chaque organisation peut mettre en place son

serveur

Exemple: Nom de domaine


Nom de domaine - 2

Client

ServeursDNS

Serveur Web

http://www.google.com

IP?

XXX.XXX.X

XX.XXX

•Pour communiquer, un client doit connaître l’IP d’un serveur et un numéro de port

•Cette adresse s’obtient auprès d’un serveur DNS (lookup)

http get


Serveurs DNS

com

.

org gov biz fr

unice free inria

• Une requête DNS est envoyée au serveur du domaine dont dépend la machine

• Si le serveur n’a pas autorité il demande à son parent…

• Les réponses parcourent le chemin inverse et sont mises en cache

amazon


Exemple: CDN• Content Delivery Network • Un (très) gros serveur peut supporter plusieurs

centaines de milliers de connexions par secondes• MAIS:

– Rien pour la latence– Le réseau peut être un goulot d’étranglement (cf.

9/11)

• Solutions: – Avoir le même contenu sur plusieurs serveurs– Diriger un client vers un serveur « proche » – Approcher physiquement le contenu du client

• Problèmes:– Diriger le client– Assurer la synchronisations des miroirs


Routage de contenu• Donner au client le contenu disponible à l’endroit le plus approprié• Plusieurs métriques

– Proximité au sens réseau– Proximité géographique– Temps de réponse– Type d’utilisateur (payant…)

• Routage global par redirection DNS– Sous un même nom sont regroupés plusieurs serveurs– Le serveur DNS retourne au client la « bonne » IP– Mais

• Risque de latence élevée pour le lookup• La requête DNS ne contient pas d’information sur le contenu demandé

• Routage par port TCP– La requête est redirigée par un serveur vers d’autres serveurs suivant le

numéro de port• Routage de niveau 7

– Analyse du contenu de la requête– Une requête peut générer plusieurs sous requêtes transparentes

• Web Cache Communication Protocol– Un routeur intercepte les demandes des clients et les envoient à des caches– Les caches indiquent aux routeurs (avec WCPP) quels protocoles ils servent


Conclusion• Les systèmes distribués viennent

dans toutes les tailles • Caractéristiques:

• Multiples espaces d’adressage• Parallélisme, concurrence et absence

d’horloge globale. • Latences et pannes


2- Matériel pour les systèmes distribués


Introduction• En pratique tous les systèmes

distribués sont composés de plusieurs processeurs

• Mais l’organisation varie– Mémoire– Interconnexion– Homogénéité/Hétérogénéité

• Influence– La façon de programmer– La façon de les utiliser– Les performances


Organisation• Mémoire privée (multicalculateurs)

– Chaque processeur à sa propre mémoire • Mémoire partagée (multiprocesseurs)

– L’ensemble des processeurs partagent la mémoire• Interconnexion à bus

– Tous les processeurs utilisent un seul médium pour communiquer

• Interconnexion par commutation – Les processeurs communiquent par un ensemble de

câbles– Les messages se déplacent sur ces câbles et des

décisions de routage sont prises à chaque nœud d’interconnexion

• Homogénéité– La même technologie est utilisée partout

• Hétérogénéité– Des ordinateurs différents sont connectés par des

réseaux différents– Ex: Internet (ATM, IP, Fibre, Ethernet…)


Multiprocesseurs à bus• Tous les processeurs ont accès à la même mémoire à

travers un bus• Exemples:

– Bi-Processeurs – Processeurs multi-cores

• Cohérence– Si le CPU A écrit un mot en mémoire et que le CPU b y

accède ensuite, il aura la bonne valeur• Implémentation naïve peu performante

– 4 ou 5 CPUs saturent le bus• Solution: ajouter du cache au niveau de chaque

processeur– Tous les accès mémoire passent pas le cache– Si hit rate élevé, moins de messages sur le bus– Mais problème de la cohérence des caches

UCCache

UCCache

UCCache

Mémoire


Multiprocesseurs à commutation• Les systèmes à bus ne passent pas à

l’échelle• Pour des systèmes de plus de 256

processeurs, on utilise d’autres techniques

• Réseau d’interconnexion– La mémoire est divisée en modules– Les processeurs y sont reliés par une

matrice de commutation (crossbar switch)– A chaque intersection, le nœud de

commutation (crosspoint switch) peut-être ouvert ou fermé

– L’accès à un module mémoire est synchronisé

• Les demandes sont mises dans une file d’attente

• Inconvénient– Nécessite beaucoup de nœuds

d’interconnexion (n*m)

C

C

C

C

M M M M

Mémoires

UC


Multiprocesseurs à commutation• Alternatives à la matrice

– Réseau oméga– NUMA

• Réseau oméga– Des commutateurs à 2 entrées et 2 sorties– Nécessite de passer par plusieurs pour

atteindre la mémoire– A besoin d’être extrêmement rapide, donc

coûteux• NUMA

– NonUniform Memory Access– Accès hiérarchique à la mémoire

• Les processeurs ont une mémoire locale accessibles rapidement

• L’accès à la mémoire d’un autre processeur est plus lent

– En général plus rapide que l’oméga– Mais plus difficile à programmer

• Bien placer les données est non trivial

C

C

C

C

M

M

M

M


Multicalculateurs• Beaucoup plus facile à construire

qu’un système multiprocesseurs • Mémoire privée donc

communications CPU à CPU (volume plus faible que CPU vers mémoire)

• Multicalculateurs homogènes à bus– Les nœuds sont dans des racks– Et reliés par un réseau rapide (Fast

Ethernet)– Passage à l’échelle problématique

(100 nœuds max)


Multicalculateurs• Multicalculateurs homogènes

commutés– Les messages sont routés à travers un

réseau d’interconnexion• Plusieurs topologies possibles• Grille à 2 dimensions

– Câblage simple– Le chemin le plus long est en

n


Multicalculateurs• Tore

– Extension de la grille– Les processeurs frontières sont reliés à

leurs homologues– Nécessite un câblage plus long


Multicalculateurs• Hypercube

– Cube à n dimensions– 4 dimensions: 2 cubes à 3 dimensions

reliés par les sommets homologues– Complexité du câblage en log(n)– Chemin le plus long en log(n)


IBM BlueGene/L

• 1er au classement mondial• 131072 processeurs et 32768 Go de mémoire• Interconnexion par tore 3D (chaque processeur a 6 voisins)


Cray XT3

• 2000 à 30 000 processeurs Opterons• Reliés par un tore 3D• Actuellement 6eme au classement mondial

avec 10880 processeurs


Multicalculateurs• Les multicalculateurs commutés

sont très variés– Modèles à plusieurs milliers de CPUs

coûtant plusieurs millions d’euros– Clusters: PCs reliés par du matériel

« grand public »• Ce qui les différencie souvent est le

matériel pour l’interconnexion– Faible latence et haut débit sont

coûteux


56x2 Opterons

32x2 Xeons

105x2 Opterons

216x2 Opterons32x2 PowerPC

103x2 Itaniums

64x2 Xeons64x2 Opterons

32x2 Opterons

56x2 Opterons

Grid’5000


3- Logiciels pour les systèmes distribués


Systèmes d’exploitations• Le matériel est important, mais c’est le logiciel

qui détermine le système distribué• Ressemblent beaucoup à des systèmes

d’exploitation classiques– Gèrent l’accès au matériel– Permet le partage de ressources (mémoire, CPU…)– Masquent l’hétérogénéité

• Système fortement couplé– L’OS fournit une unique vue des ressources– Souvent appelé Distributed Operation System

• Systèmes multiprocesseurs• Systèmes multicalculateurs

• Système faiblement couplé– Chaque ordinateur a son propre OS– Appelé Network Operating System


Systèmes multiprocesseurs• Dans le cas de plusieurs processeurs

accédant à la même mémoire, les accès doivent être protégés

• Très similaire à un OS monoprocesseur• Difficile de porter un OS mono en multi

– Nécessite souvent des changements profonds

– Les OS modernes sont pensés multiprocesseurs dés le début

• Rend le nombre de processeurs transparents pour l’application

• Protection de la mémoire grâce à des primitives de synchronisation– Sémaphores et moniteurs


Systèmes multicalculateurs• Très différent d’un OS monoprocesseur• Les données nécessaires au fonctionnement global du

système ne sont plus dans une zone de mémoire partagée• Chaque nœud a

– son propre noyau (kernel) responsable de la gestion des ressources locales (mémoire, CPU, disque…)

– Un module pour gérer les communications inter processeurs• Une couche commune au dessus des noyaux implémente

un OS supportant l’exécution parallèle et concurrente de taches

• Services parfois fournis:– Mémoire partagée!– Affectation des taches à certains processeurs– Gestion des pannes

Applications distribuées

Services distribués

noyau noyau noyau


Communications par messages• Si pas de mémoire partagée,

communication par messages• Différences

– Buffers ou non– Blocage ou non

• Bufferisation possible à 2 endroits– Du côté de l’appelant– Du côté de l’appelé

• Bloquage– Dépend de la bufferisation


Communications par messages

• Blocage de l’appelant– S1 : mise en buffer, seulement si plein– S2 : envoie du message– S3 : réception du message– S4 : transmission du message a l’appelé– Si blocage en S2 , S3 ou S4 alors buffer appelant inutile

• Blocage de l’appelé– Possible seulement en S3 : buffer vide ou pas de buffer

• L’appelé peut décider de vérifier périodiquement si des messages sont disponibles (polling) mais

– Fréquence trop rapide signifie gâchis de CPU– Fréquence trop lente, risque de pertes de messages (buffer plein)

Appelant ReceveurS1

S2 S3

S4


Fiabilité des communications• L’émetteur a-t-il une garantie que

son message a bien été reçu ?• Si fiabilité les messages sont

garantis d’arriver en S3

• Si blocage en S1 ou S2 fiabilité non obligatoire

• Si blocage en S3 ou S4, fiabilité obligatoire!


Systèmes distribués à mémoire partagée• Les multiprocesseurs sont plus simples à

programmer que les multicalculateurs– Accéder à des variables partagées est plus

simple que communiquer par messages

• Il est possible d’émuler une mémoire partagée sur les multicalculateurs

• Page-Based Distributed Shared Memory– Unique espace d’adressage virtuel– Les pages physiques sont reparties sur les

différentes machines– Quand un processeur demande une page non

locale, le système d’exploitation la copie localement


Systèmes distribués à mémoire partagée• Pour améliorer les performances, on peut

répliquer les pages en lecture seule– Permet à plusieurs processeurs d’avoir localement la

même page– Limite les chargements

• Réplication de toutes les pages– Possibles lorsqu’elles ne sont que lues– Si modifications, alors il faut prendre des mesures

(avant ou après ?)• Inconsistance

– Il est possible d’abandonner la stricte consistence– Mais rend la programmation beaucoup plus

compliqué • Taille des pages

– Quelle est la bonne taille?– D’où vient le coût d’un transfert?


Network Operating Systems• Ne suppose pas que le système est homogène

et qu’une vue globale doit être fournie• Les machines et leurs OS peuvent être

différents, mais elles sont toutes reliées par un réseau

• Un NOS fournit des mécanismes pour utiliser les services disponibles sur certaines machines

• Exemples:– rlogin, ssh…


Services réseau

noyau noyau noyau

Services réseau

Services réseau


Middleware• Un DOS ne gère pas des machines

indépendantes• Un NOS ne donne pas une vue cohérente

de machines• Comment avoir le meilleur des 2 ?• On ajoute une couche au dessus d’un

NOS pour masquer l’hétérogénéité, le middleware


Services réseau

noyau noyau noyau

Services réseau

Services réseau

Middleware


4- Outils pour la programmation


Outil de base: Sockets

• Introduit dans Berkeley Unix 4.2 (BSD) en 1981

• Représentation point à point d’un flux de données

• Un programme peut – Écrire des données– Lire des données

BAApplication

Socket write

write

read

read


Primitives• Les sockets fournissent un ensemble

d’opérations de base (les primitives)– Socket: création d’une socket– Bind: Attachement de la socket à une

adresse locale– Listen: Annonce l’acceptation des

connexions– Accept: Bloque jusqu’à l’arrivée d’une

demande de connexion– Connect: Demande de connexion– Send: Envoie de données– Receive: Lecture de données– Close: Fermeture


Sockets en Java• Jusqu’à JDK 1.4 : I/Os bloquantes

– Deux classes : java.net.Socket et java.net.ServerSocket

– Beaucoup de classes pour la gestion des streams

– Toutes les opérations (lecture ou écriture) sont bloquantes

– 1 ou 2 threads nécessaires pour chaque socket• Surcoût mémoire et changement de

contexte • available() permet de savoir si des

données sont disponibles mais utilisation du CPU


Nouvelle API pour les Sockest

• Nouveauté dans JDK 1.4: I/Os non bloquantes– 2 nouvelles abstractions de haut niveau

• Buffers: conteneur à données linéaire• Channels: Tube de communication bidirectionnel

supportant des opérations bloquantes et non bloquantes• Une classe Selector pour multiplexer les événements :

base du passage à l’échelle– ServerSocketChannel et SocketChannel– Support d’opérations bas-niveau de gather/scatter – Fichier mappés en mémoire, gestion des buffers…– Package java.nio.*


Limitations des sockets• Description des données (ce qui sera lu et écrit)

– Chaque application doit le définir – L’implémentation doit être identique sur chaque nœud– Problèmes: ordre des bits, symboles spéciaux…

• Protocole de communication (comment lire et écrire)

– Chaque application doit le définir– L’implémentation doit être consistante sur tous les noeuds– Problèmes: taille de buffer, synchronisation, timeouts, ...

• Conséquences– Beaucoup de temps est passé à récrire le même code– Des erreurs sont faciles à faire, mais difficiles à trouver


Sockets vs. Procédures• Probleme: 2 abstractions différentes dans la même

application– Local: structures de données et procédures– Distant: Flux de données et lecture/écriture dans des sockest

• Idée: Pourquoi ne pas tout programmer sous forme de procédures? – Le programmeur n’a plus à se soucier de détails bas-niveau, il

peut se concentrer sur son application. – Première implémentation avec RPC (Remote Procedure Calls)

• Fonctionnement : Un outil génère du code– Code pour convertir des appels de procédure en données

écrite ou lues sur des sockets– Code pour convertir les structures de données en données

compatibles avec les sockets (marshalling / unmarshalling ou Serialization/Deserialization)


Remote Procedure Calls (RPC)• Permet de donner l’impression d’un appel local

pour un appel distant• Code généré

– Du côté appelant: stubs – Du côté appelé: skeletons

• Passage de paramètre par valeur• RPC est fait pour le langage C

– Toujours utilisé aujourd’hui, par exemple pour NFS

BA

Stub Skeleton

Application

RPC


Remote Procedure Calls

• Le rôle du Stub est de: – Transformer les structures de données passées en

paramètres de la procédure en flux d’octets (marshalling)– Écrire ces données dans la socket– Attendre jusqu’à ce que des données soient disponibles en

lecture– Lis les données et les converties en structure

(unmarshalling)– Retourne le résultat à l’appelant comme résultat de son

appel de méthode

A

Stub


Remote Procedure Calls

• Le Skeleton doit – Attendre que des données soient disponibles en

lecture– Lire un flux d’octets et construire la structure

correspondante– Appeler la méthode correspondante sur B avec les

paramètres– Transformer le résultat en flux d’octets – Envoyer ce résultat à l’appelant

B

Skeleton


Remote Procedure Calls • Limitations de RPC

– Peu de transparence• Les machines distantes sont trouvées avec leur adresse

IP et le numéro de port– Pas de nommage symbolique

• Impossible de trouver un service suivant son nom ou son type

– Pas de chargement de code dynamique• Le stub doit être pré installé chez l’appelant, le skeleton

chez l’appelé• Le code pour le marshalling/unmarshalling est

spécifique et doit être présent des 2 côtés– Aucun mécanisme de tolérance aux pannes ou de

gestion des erreurs


Java-RMI• RMI signifie Remote Method Invocation• Introduit dés JDK 1.1• Partie intégrante du cœur de Java• RMI = RPC en Java + chargement dynamique

de code• Même notions de stubs et skeletons• Fonctionne avec l’API de sérialization (utilisée

également pour la persistance) • Possibilité de faire interagir RMI avec CORBA

et DCOM


RMI: Fonctionnalités• Masque pratiquement tout le réseau à

l’application• Très similaire à RPC• Utilisation de l’interface Remote Java• Appels distants bloquants

– L’appelant est bloqué jusqu’à ce que le résultat soit disponible

• Les références vers des objets « normaux »sont passées par copie profonde (deep copy) grâce à la sérialisation

• Les références vers des objets distants sont passées par référence


Implémenter un objet distant• Un objet qui à des méthodes appelables à

distance est appelé objet distant• Les seules méthodes accessibles à distance

seront celles spécifiées dans l’interface Remote– Écriture d’un interface spécifique à l’objet,

étendant l’interface java.rmi.Remote

• Chaque méthode distante doit annoncer lever l’exception java.rmi.RemoteException– Sert à indiquer les problèmes liés à la

distribution

• L’objet devra fournir une implémentation de ces méthodes


Implémenter un objet distantimport java.rmi.Remote;import java.rmi.RemoteException;

public interface MonInterfaceDistante extends

Remote { public void echo() throws

RemoteException;}

• Cette interface indique que l’objet qui l’implémentera aura la méthode echo() appelable à distance


Implémenter un objet distantimport java.rmi.Remote;import java.rmi.RemoteException;import java.rmi.server.UnicastRemoteObject; public class MonObjetDistant extends UnicastRemoteObject { implements MonInterfaceDistante public MonObjetDistant() throws RemoteException {} public void echo() throws RemoteException{ System.out.println(« Echo »); }}

• L’objet distant doit finalement implémenter les méthodes de l’interface

• Hériter de java.rmi.server.UnicastRemoteObject• Et avoir un constructeur sans paramètre levant aussi

l’exception


Utiliser un objet distant• Pour utiliser un objet distant il faut

– Connaître sont interface– Le trouver!– L’utiliser

• RMI fournit un service de nommage permettant de localiser un objet par son nom : le registry– L’objet s’enregistre sous un nom

« bien connu »– Les clients demandent une référence

vers cet objet


Utiliser un objet distantimport java.rmi.RemoteException; public class Client { public static void main(String args) { MonInterfaceDistante mod = ….. // du code pour trouver l’objet try { mod.echo(); } catch (RemoteException e) { e.printStackTrace(); } }}

• Une fois la référence obtenue, il suffit d’appeler la méthode dessus, en prenant garde aux éventuelles exceptions


Trouver un objet distant• L’objet doit s’enregistrer dans le registry

– Programme lancé auparavant sur la même machine que l’objet distant : rmiregistry

– Utilise le port 1090 par defaut– Possibilité de le démarrer depuis l’application

(LocateRegistry)• Il agit comme un service d’annuaire• Les noms ressemblent à des URLs

– protocole://machine:port/nom– Protocole, machine et port sont optionnels– Objet toto sur la machine locale: ///toto

• Les méthodes de gestion sont regroupées dans la classe Naming

• L’objet distant appel Naming.bind• Le client appel Naming.lookup


Générer les stubs et skeletons• Une fois l’objet distant écrit, il est

possible de générer les stubs et les skeletons

• Outils fournit dans Java: rmic• Prends le nom complet de la classe

distante (package+nom)• Génère 2 fichiers ( _Stub et _Skel)• Ne met dans le stub que les méthodes

spécifiées dans l’interface distante• Possibilité de voir le code source avec

l’option –keep


RMI: en résumé1. Écrire l’interface distante2. Écrire le code de l’objet distant

1. Implémenter l’interface2. Ajouter le code pour le registry (en général dans le

main ou le constructeur)3. Compiler4. Générer les stub et skeleton5. Écrire le client

1. Obtenir une référence vers l’objet distant2. Appeler les méthodes

6. Compiler7. Exécuter

1. Démarrer le serveur2. Démarrer le client3. Debugger

systèmes distribués

Documents