Cours Systmes (Distribus) Rpartis Cours Systmes (Distribus) Rpartis

F. Baude (baude@unice.fr), Matrise MIAGE 2003-2004 1- Introduction

objectifs concepts matriels concepts logiciels bases de la conception des systmes distribus des systmes dexploitation aux applications

2- Communication dans les systmes distribus

couches de protocoles modle client-serveur appels de procdures distance communication de groupe Quelques approches pratiques
Page 1

Plan du cours (suite) Plan du cours (suite)

3- Synchronisation dans les systmes distribus
gestion du temps: synchronisation d'horloge lection exclusion-mutuelle transactions atomiques interblocage dans les systmes distribus

4- Etude de cas (TP) -- fait plus tard et dans dautres cours !

Service web et programmation Client/serveur sur web Modle CORBA et systmes objets distribus (? Non !) Modles client/serveur et objets en Java : rmi, servlet/JSP, applet Exemples dautres applications ou services systme : SG fichiers rpartis, SGBD, serveurs dapplications tels EJB, etc...

Page 2

1- Introduction 1- Introduction
1.1- Objectifs, Avantages/Inconvnients 1.1- Objectifs, Avantages/Inconvnients

SYSTME Expl. DISTRIBU = SYSTME POSSDANT PLUSIEURS PROCESSEURS COOPRANTS

OBJECTIFS - Cot : plusieurs processeurs bas prix - Puissance de calcul et de stockage : aucune machine centralise ne peut rivaliser - Performance ( acclration) : via du calcul parallle - Adaptation : des classes d'applications relles naturellement distribues - Fiabilit : rsistance aux pannes logicielles ou matrielles - Extensibilit : croissance progressive selon le besoin

Avantages - partage de donnes - partage de priphriques - communication - souplesse (politiques de placement)

Page 3

Inconvnients - logiciels : moins de logiciels disponibles - rseaux : saturation et dlais - scurit : piratage

1- Introduction 1- Introduction
1.2- Concepts matriels 1.2- Concepts matriels
SISD : Taxonomie de Flynn (1972) - nombre des flux d'instructions - nombre des flux de donnes SIMD : MISD : MIMD : un seul flux d'instruction et un seul flux de donnes (ordinateurs centraliss) un seul flux d'instruction et de multiples flux de donnes (machines //, vectorielles) multiples flux d'instruction et un seul flux de donnes (pas de machine relle ) multiples flux d'instruction et de multiples flux de donnes MIMD systmes // et dist. Fortement coupls multiprocesseurs (mmoire partage) Faiblement coupls multicalculateurs (mmoire prive)

Bus Sequent Encore Sun Enterprise serveurs

Commutateur RP3 et SPx dIBM

Page 4

Commutateur Transputer Machines parallles mmoire rpartie

Rseau Stations de travail sur LAN Grappe de PCs sur un Etherswitch , ou un rseau Myrinet Grilles sur WAN

1- Introduction 1- Introduction
1.2- Concepts matriels 1.2- Concepts matriels
1.2.1- Multiprocesseurs bus

UC Cache

UC Cache

UC Cache

Mmoire

Problmes - saturation du bus - cohrence du partage de la mmoire

Problmes - cohrence entre les caches et la mmoire

Solution ajout des mmoires caches qui stockent des mots rcemment lus ou crits

(<64 processeurs)

Solution - cache criture immdiate (write-through cache) + cache espion (snoopy cache)

Page 5

1- syst? mes II- Partie II1-:Introduction distribu?s II- Partie II :Introduction distribu?s syst? mes
1.2- Concepts matriels II.1- Introduction 1.2- Concepts matriels II.1- Introduction
1.2.2- Multiprocesseurs commuts

Mmoires M C C UC C C M M M

Technique de matrice de commutation (Crossbar Switch) - les UC et mmoires sont relies par une matrice de commutation - chaque intersection, le noeud de commutation (crosspoint switch) peut-tre ouvert ou ferm - quand une UC veut accder un module de mmoire elle ferme temporairement le noeud de commutation correspondant - si plusieurs UC veulent accder au mme module, une file d'attente est ncessaire

Inconvnient le nombre des noeuds de commutation ncessaires : il faut n2 de noeuds de commutation pour relier n UC aux n modules de mmoire rseaux d'interconnexion minimisant le nombre de noeuds ?
Page 6

1- syst? mes II- Partie II1-:Introduction distribu?s II- Partie II :Introduction distribu?s syst? mes
1.2- Concepts matriels II.1- Introduction 1.2- Concepts matriels II.1- Introduction
1.2.2- Multiprocesseurs commuts

C C C C

Principe dun rseau multi-tages: ex. omega M M M M - utilisation des commutateurs 2x2 : 2 entres et 2 sorties - chaque commutateur peut relier n'importe quelle entre n'importe quelle sortie - pour relier n UC n mmoires, il ncessite log 2n tages dont chacun contient n/2 commutateurs 2x2 - le nombre ncessaire de commutateurs est : nxlog2n

Inconvnient : Temps de propagation - Si n= 1024, on a besoin 10 tages - Avec les UC de 50Mhz, le cycle de calcul est de 20ns - une requte mmoire traverse 20 tages (aller /retour) en 20 ns si le temps de commutation est de 1ns - On doit avoir 10 240 commutateurs 1ns !!!

CONCLUSION construire un gros multiprocesseurs fortement coupl mmoire partage est difficile et coteux

Page 7

1- syst? mes II- Partie II1-:Introduction distribu?s II- Partie II :Introduction distribu?s syst? mes
1.2- Concepts matriels II.1- Introduction 1.2- Concepts matriels II.1- Introduction
1.2.3- Multicalculateurs commuts

Topologie en Grille de 2 dimensions - cblage simple - le chemin plus long croit en racine carre du nombre d'UC - la brique de base est tjs la mme Ex: Machines ad-hoc sur Transputer, T3x (Cray): grille torique Connection Machine 2 et 5 (Fat tree)

Hypercube (4 dimensions)

Ex: le n-cube -> 8192 UC

- Un hypercube est un cube n dimensions - 4 dimensions : 2 cubes de 3 dimensions avec les sommets homologues relis - 5 dimensions : 2 hypercubes de 4 dimensions avec les sommets homologues relis, etc... - la complexit du cblage croit en log2 du nombre UC - le chemin le plus long croit en log2 du nombre UC Absence de Mem. Centrale commune Page 8 => Trouver un autre moyen pour partager de linformation = logiciel - Mmoire Virtuellement Partage -> problmatique NUMA - ou, mode de programmation fond uniquement sur lchange de donnes

1- syst? mes II- Partie II1-:Introduction distribu?s II- Partie II :Introduction distribu?s syst? mes
1.2- Concepts matriels II.1- Introduction 1.2- Concepts matriels II.1- Introduction
1.2.4- Multicalculateurs faiblement interconnects au dessus d un rseau Internet (IP) : meta calculateur

Grappes (cluster) - technologie rseau rapide (giga bits Ethernet, Myrinet, SCI) - un seul frontal (console) : unique point daccs au cluster -- soumission de jobs (LSF,PBS,...) => tous les noeuds de la grappe sont dans le mme domaine dadministration Page Ex: Clusters de type beowulf (PC du commerce 9 Linux + Ethernet) Clusters dIntel, dAMD Athlon, ...

Grilles ( cf. Power Grid) - de stations de travail (desktop grids) et/ou de PC volontaires - de grappes => toutes combinaisons possibles - rseau sous-jacent si possible pas trop lent (ex WAN haut dbit comme Renater 3 -- Gigabits/sec) => difficile problme provenant de la non unicit du domaine dadministration (authentification -- compte invit ; nombreux points dentre effectifs; soumission de jobs sur la grille entire : par dcoupage en sous-ens de jobs vers +eurs noeuds de la grille) Le futur : Agrger des BDs -- ex BD de proteines -> cancer

1- syst? mes II- Partie II1-:Introduction distribu?s II- Partie II :Introduction distribu?s syst? mes
1.3- Concepts logiciels II.1-Concepts logiciels 1.3- Introduction II.1- Introduction
1.3.1- Classification
Le matriel est important, mais le logiciel de base (SE ou plus gnralement Syst. Operatoire ) l'est plus encore ! La classification est, par nature, imprcise et floue : systmes d'exploitation faiblement coupls - rseaux dordinateurs indpendants (et alors les ordinateurs indpendants avec rseau dfaillant continuent +/- fonctionner ) (Ex les 15000 PCs du cluster Google ou toute archi . gographiquement repartie .) multiprocesseurs SE faiblement coupl multiprocesseurs SE fortement coupl systmes d'exploitation fortement coupls - multiprocesseurs faits pour excuter un seul programme en // (jeu d'checs, calcul scientifique) - machines ddies (ex: // intra --plutot que inter-requete sur BDs -- cf Oracle //, Informix, etc)

Systmes d'exploitation distribus Systmes d'exploitation rseaux

multicalculateurs multicalculateurs SE faiblement coupl SE fortement coupl

Page 10

Systmes multiprocesseurs temps partag

1- syst? mes II- Partie II1-:Introduction distribu?s II- Partie II :Introduction distribu?s syst? mes
1.3- Concepts logiciels II.1-Concepts logiciels 1.3- Introduction II.1- Introduction
1.3.2- Systmes d'exploitation rseau et NFS

La combinaison la plus frquente : matriels et logiciels faiblement coupls Connexion point--point - postes avec SE indpendant - partage des imprimantes - accs un autre poste en mode terminal Rseaux locaux - stations NT - windows workgroups Internet FTP, TELNET, HTTP, RLOGIN... poste client poste client poste client systme d'exploitation rseau - postes indpendants + serveurs de fichiers - systmes de fichiers partags (NFS) - gestion centrale des utilisateurs (CD, NIS) Novell, LanManager Unix+NFS, NTserver services

Serveur de fichiers

question LAN
Page 11

rponse

1- syst? mes II- Partie II1-:Introduction distribu?s II- Partie II :Introduction distribu?s syst? mes
1.3- Concepts logiciels II.1-Concepts logiciels 1.3- Introduction II.1- Introduction
Architecture NFS (Sun)

serveur1 jeux pacman pacwoman pacchild

serveur2 travail news mail autres

Serveurs - exporter des rpertoires (/etc/exports) - grer les accs aux rpertoires exports pour les clients (locaux ou distance) - protection des fichiers, cohrence - transmettre les donnes aux clients ( rponses ) - les clients et les serveurs peuvent partager un mme systme de fichiers Clients - monter des rpertoires exports sur sa station - utiliser ces rpertoires comme (ou presque) ceux locaux - plusieurs clients peuvent partager les mmes rpertoires (fichiers partags) - toute machine peut tre la fois client et serveur - systmes d'exploitation locaux peuvent tre <>
Page 12

Lan ou Internet client1/ jeux travail pacman pacwoman pacchild client2/jeux pacman pacwoman pacchild travail news mail autres news mail autres

Protocoles NFS
Un protocole est un ensemble de requtes envoyes par les clients aux serveurs auxquelles correspondent les rponses des serveurs aux clients

1er protocole : Protocole de montage 1- Le client envoie une requte contenant le chemin d'accs un rpertoire du serveur et une demande dautorisation de le monter dans son arborescence. 2- Si le chemin est correct et le rpertoire est exportable, le serveur revoie au client une cl de fichier (file handle) concernant ce rpertoire . Cette cl comporte des champs qui identifient uniquement le type de Systme de Fichiers, le disque, le n de i-noeud du rpertoire et les informations sur les protections. 3- Classiquement, le client a un fichier Shell script /etc/init.d/ netfs contenant entre autre les commandes de montage. Ce Shell script sera excut automatiquement au lancement du systme 4- Automontage (Unix de Sun) : le montage se fait automatiquement la 1ere ouverture d'un fichier distance, le client contacte les serveurs et monte le rpertoire contenant ce fichier
Page 13

2me protocole : Protocole d'accs 1- Le client envoie au serveur des requtes de manipulation des rpertoires ou des fichiers 2- La plupart des appels systme UNIX sont supports par NFS, lexception de OPEN et CLOSE. L'omission de ces oprations permet aux serveurs de ne pas grer les fichiers ouverts (serveur sans tat (stateless)). Chaque requte d'accs se suffit elle-mme . L'appel READ contient la cl du fichier, la position courante et le nombre d'octets lire. On utilise LOOKUP la place de OPEN. L'inconvnient principal est l'absence de contrle de cohrence : On ne peut pas verrouiller le fichier (car il est toujours ltat ferm), donc le partage d'accs peut introduire des incohrences (=> lock manager). De plus, pour des raisons de performance, les clients utilisent des caches => MAJ incohrentes Ex: Append difficile ! Rem- Il existe sous UNIX systme V (uniquement), le Remote File System (RFS) qui demande que le fichier soit ouvert avant la lecture. Le serveur doit grer dans ce cas un descripteur de fichier pour tout fichier ouvert distance ( statefull, mais smantique du SGF Unix respecte)
Page 14

Mode de fonctionnement de NFS

Point de vue dune application Cliente, tournant sur une machine dite cliente Machine dite Serveur

Couche appel systme (MOUNT, READ,...) couche systme de fichiers virtuels

couche systme de fichiers virtuel

Module E/S du syst. d'exploitation local

client NFS

serveur NFS

Systme d'exploitation local

disque local

message vers serveur

message vers serveur

disque local

Rseau
Page 15

1- Introduction 1- Introduction
1.3- Concepts logiciels 1.3- Concepts logiciels
1.3.3- Systmes distribus
Un systme distribu est un systme qui s'excute sur un ensemble de machines sans mmoire partage , mais que l'utilisateur voit comme une seule et unique machine au point que la dfaillance dune machine dont lutilisateur ignore jusqu lexistence peut rendre sa propre machine inutilisable ...

Caractristiques - possdant un mcanisme de communication interprocessus unique et global permettant le dialogue entre deux processus quelconques - possdant un systme de protection unique et global - possdant un mcanisme de gestion de processus unique - possdant un ensemble dappels systme unique, disponible sur toutes les machines - possdant un noyau de systme d'exploitation identique implant sur toutes les machines - possdant un mcanisme de gestion de mmoire identique

Page 16

1- Introduction 1- Introduction
1.3- Concepts logiciels 1.3- Concepts logiciels
1.3.4- Systmes multiprocesseurs temps partag
Mmoire E ( prt) D (prt) UC1 Processus A en exc . Cache UC2 Processus B en exc . Cache UC3 Processus C en exc . Cache C (en excution) B (en excution) A (en excution) File d'excution : D, E Noyau SE Bus - Un ensemble de processeurs "symtriques" - Une mmoire commune et un espace disque commun - Tous les programmes sont stocks dans la mmoire partage - Une file d'attente unique des processus excutables se trouvent dans la mmoire partage - L'ordonnanceur travaille en section critique pour viter que deux UC ne choisissent le mme processus excuter - L'exclusion mutuelle peut tre ralise en utilisant des smaphores, moniteurs, ...
Page 17

Disque local

1- Introduction 1- Introduction
1.3- Concepts logiciels 1.3- Concepts logiciels
1.3.5- Tableau de synthse sur la classification des Systmes dexploitation

Questions Ressemble-t-il un monoprocesseur virtuel ? Doit-on avoir le mme systme d'exploitation (local) ? Combien y a-t-il de copies du systme d'exploitation ? Quel est le mode de communication dinfo naturel ? Existe-il une seule file d'attente des excutables ?

S.E.Res. Non Non N Fichiers partags +messages Non

S.E.Dist. Oui Oui N Messages Non mais coopration

S.E.MemP. Oui Oui 1 Mmoire partage Oui

Page 18

1- Introduction 1- Introduction
1.4- Critres de Conception dun S.E.D. ou dun Syst. opratoire 1.4- Critres de Conception dun S.E.D. ou dun Syst. opratoire pour une architecture distribue pour une architecture distribue
1.4.1- Transparence
Mme mode d'utilisation que celui d'un systme centralis temps partag : au niveau dun lutilisateur et au niveau dun programme (appels au systme )

Types de transparence Transparence l'emplacement Transparence la migration Transparence la duplication Transparence la concurrence Transparence au paralllisme

Signification L'utilisateur ne connat pas o sont situes les ressources Les ressources peuvent tre dplaces sans modification de leur nom L'utilisateur ne connat pas le nombre de copies existantes Plusieurs utilisateurs peuvent partager en mme temps les mmes ressources Des tches peuvent sexcuter en parallle sans que les utilisateurs le sachent

Page 19

1- Introduction 1- Introduction
1.4- Critres de Conception dun S.E.D. ou dun Syst. opratoire 1.4- Critres de Conception dun S.E.D. ou dun Syst. opratoire pour une architecture distribue pour une architecture distribue
1.4.2- Souplesse

La facilit de modification, de configuration et d'extension

Utilisateur Noyau monolithique

Utilisateur

Serveur de fichiers Micronoyau

Serveur de rpertoires Micronoyau

Serveur de processus Micronoyau

Micronoyau

Bus / rseaux locaux cole Monolithique - 1ers Unix en particulier - Linux (meme si modules) cole Micronoyau - WindowsNT et encore, pas pour tout ! - Mach (Unix/ Posix )
Page 20

=> idee intressante qui permet de btir un systme operatoire pour grappe ou grille, sur des systemes dexploitation usuels (par ex. gestion transparente des soumissions de tches utilisant des sondes de performance.)

10

1- Introduction 1- Introduction
1.4- Critres de Conception dun S.E.D. ou dun Syst. opratoire 1.4- Critres de Conception dun S.E.D. ou dun Syst. opratoire pour une architecture distribue pour une architecture distribue
1.4.3- Fiabilit
Disponibilit La disponibilit est la fraction de temps pendant laquelle le systme est utilisable : - limiter le nombre des composants critiques - dupliquer les parties cls des composants logiciels et matriels (redondance) - mais implique de savoir maintenir la cohrence des copies Scurit Les ressources doivent tre protges contre des utilisations abusives et malveillantes. En particulier le problme de piratage des donnes sur le rseau de communication

Tolrance aux pannes Le systme doit tre conu pour masquer les pannes aux utilisateurs. La panne de certains serveurs (ou leur rintgration dans le systme aprs la rparation) ne doit pas perturber l'utilisation du systme en terme de fonctionnalit (NFS sans tat par exemple)
Page 21

1- Introduction 1- Introduction
1.4- Critres de Conception dun S.E.D. ou dun Syst. opratoire 1.4- Critres de Conception dun S.E.D. ou dun Syst. opratoire pour une architecture distribue pour une architecture distribue
1.4.4- Performances
Critres - dbit (nombre de travaux par heure) - pourcentage utilis de la bande de passante du rseau

- temps de rponse - taux d'utilisation du systme

Problmes - La communication est en gnral assez lente dans les systmes distribus par rapport accs fichier - Le mcanisme de tolrance aux pannes requiert beaucoup doprations inutiles si pas de panne !

Solutions Minimiser les changes de message par exemple en faisant en sorte de - maximiser des granules grosses (gros grains) et viter des grains fins pour les calculs distance - rduire le champ d'application des mcanismes de reprises sur pannes (car cela engendre des transmissions dinformation, et donc, les rserver aux parties critiques)

Page 22

11

1- Introduction 1- Introduction
1.4- Critres de Conception dun S.E.D. ou dun Syst. opratoire 1.4- Critres de Conception dun S.E.D. ou dun Syst. opratoire pour une architecture distribue pour une architecture distribue
1.4.5- Dimensionnement
Goulots d'tranglement potentiels Concepts Composants centraliss Tables centralises Algorithmes centraliss Exemple Un seul serveur de courrier pour tous les utilisateurs Un seul annuaire en ligne Avoir un routage qui ncessite une connaissance totale du rseau

- Caractristiques des algorithmes distribus : - aucun processus n'a une information complte sur l'tat du systme - les processus prennent des dcisions partir des seules informations locales disponibles - la panne d'un processus n'empche pas l'algorithme de fonctionner - on ne fait pas l'hypothse de l'existence d'une horloge physique globale entre les machines sur lesquelles tournent les processus mettant en oeuvre lalgo.
Page 23

1- Introduction 1- Introduction
1.5- Des Systmes dexploitation rseau ou distribus (rpartis) 1.5- Des Systmes dexploitation rseau ou distribus (rpartis) aux Applications distribues (rparties) aux Applications distribues (rparties)
u La transition est naturelle. Des mmes exigences, des mmes problmes, le mme genre de solutions ! u Par exemple: pour un SED, il faut des mcanismes de communication logiciels pour faire cooprer : les noyaux de SE locaux , les clients avec les serveurs offrant des services systme (ex, clients et serveurs NFS), les diffrents serveurs pour des soucis de tolrance aux pannes, etc => on utilise courament des sockets ou des RPC entre processus u Pour une Appli Distribue, il faut des mcanismes de communication similaires entre les excutifs des langages (ex entre JVMs , entre JVM et serveur de noms/localisation) entre les entits programmes dans ces langages (ex, entre Objets Java) => on utilise courament des envois de messages ou des RMI, qui seront construits au-dessus de ceux offerts par le SED u On peut faire le mme parallle par ex avec un service de mmoire partage offert par le SE ou par le niveau applicatif (ex, JavaSpaces); avec un service de communication collective (ex, JMS) u Le niveau applicatif permet souvent de pallier aux insuffisances du SE ! ( avec en plus, plus de portabilit)
Page 24

12

1- Introduction 1- Introduction
1.6- Quelques questions 1.6- Quelques questions
1) Donner deux avantages des systmes distribus sur les systmes centraliss 2) Un multiprocesseur bus utilise un cache espion pour grer une mmoire cohrente. Peut-on alors utiliser des smaphores ? 3) Un multicalculateur comprenant 256 UC est organis en grille de 16x16. Quel est, dans le pire des cas, le dlai de transmission d'un message (exprimer en nombre de passages d'une UC la suivante) ? 4) Considrons maintenant un hypercube de 256 UC. Quel est alors le dlai de transmission dans le pire de cas ? 5) Quels avantages/inconvnients y a-t-il ce que les serveurs NFS soient conus pour tre sans tat ? 6) NFS permet une machine d'tre la fois client et serveur.Est-ce utile ? Pourquoi? 7) Quelles sont les tches essentielles d'un micronoyau ? Quels sont les avantages des micronoyaux sur les noyaux monolithiques ? 8) Pourquoi un cache write-through est insuffisant dans le cas dune architecture mmoire partage, o chaque UC a un cache local ?
Page 25

1- Introduction 1- Introduction
1.6- Quelques pistes de rponses 1.6- Quelques pistes de rponses
1) Donner deux avantages des systmes distribus sur les systmes centraliss Redondance matrielle => tolrance augmente ; Partage de la charge selon fonctionnalits (ex, mail, news, home dirs) 2) Un multiprocesseur bus utilise un cache espion pour grer une mmoire cohrente. Peut-on alors utiliser des smaphores ? Oui, car si on prend ou on met une bille du smaphore, cest une criture mmoire que le cache espion verra donc => invalidation de cache 3) Un multicalculateur comprenant 256 UC est organis en grille de 16x16. Quel est, dans le pire des cas, le dlai de transmission d'un message (exprimer en nombre de passages d'une UC la suivante) ? Le diamtre dune grille est la racine carre du nombre dUC, donc ici de 16 4) Considrons maintenant un hypercube de 256 UC. Quel est alors le dlai de transmission dans le pire de cas ? Le diamtre dun hypercube est le logarithme en base 2 du nombre dUcs, soit 8. 5) Quels avantages/inconvnients y a-t-il ce que les serveurs NFS soient conus pour tre sans tat ? Page 26 1 Avantage: aprs panne, la reprise se fait sans besoin de restauration d tats des fichiers qui taient en cours dutilisation. 1 Inconvnient: la smantique nest pas parfaitement identique au cas centralis Unix.

13

6) NFS permet une machine d'tre la fois client et serveur. Est-ce utile ? Pourquoi? Oui, parfaitement utile: en tant que client, par exemple importer la partition de mails; en tant que serveur, par exemple, exporter /usr/ si par exemple, on y a install un logiciel particulier (mais pas install sur les autres machines du rseau) 7) Quelles sont les tches essentielles d'un micronoyau? Quels sont les avantages des micronoyaux sur les noyaux monolithiques ? Grer les interruptions, matrielles ou logicielles; ordonnancer lexcution des processus; bref, faire le lien entre le matriel et le logiciel. Les noyaux monolithiques sont difficilement extensibles et maintenables. Avec un micronoyau on peut dporter en mode utilisateur diverses fonctionalits que lon trouve souvent au sein de noyaux monolithiques (ex, authentifier les connexions des utilisateurs). Avec un micro-noyau, il est donc plus simple de mettre jour ceci. 8) Pourquoi un cache write-through est insuffisant dans le cas dune architecture mmoire partage, o chaque UC a un cache local ? Car si les Ucs ont dans leur cache local une variable qui est modifie directement en mmoire centrale, ils nauront pas pour autant la dernire valeur.

Page 27

14