Systèmes distribués

318
Systèmes distribués Christine MORIN IRISA/Université de Rennes 1 Projet INRIA PARIS Campus universitaire de Beaulieu 35 042 Rennes cedex (France) [email protected] http://www.irisa.fr/paris

description

Systèmes distribués. Christine MORIN IRISA/Université de Rennes 1 Projet INRIA PARIS Campus universitaire de Beaulieu 35 042 Rennes cedex (France) [email protected] http://www.irisa.fr/paris. Plan du cours. Introduction Synchronisation Communication Gestion de la mémoire - PowerPoint PPT Presentation

Transcript of Systèmes distribués

Page 1: Systèmes distribués

Systèmes distribués

Christine MORIN

IRISA/Université de Rennes 1

Projet INRIA PARISCampus universitaire de Beaulieu

35 042 Rennes cedex (France)

[email protected]

http://www.irisa.fr/paris

Page 2: Systèmes distribués

2

Plan du cours

• Introduction• Synchronisation • Communication• Gestion de la mémoire

– Pagination en mémoire distante– Mémoire virtuellement partagée

• Gestion des fichiers– Système de gestion de fichiers distribués– Système de gestion de fichiers parallèles

• Gestion des processus• Sécurité• Haute disponibilité

Page 3: Systèmes distribués

Chapitre 1

Introduction

Page 4: Systèmes distribués

4

Introduction

• Naissance des systèmes distribués• Avantages et inconvénients des systèmes

distribués• Architecture matérielle• Conception de logiciel pour les systèmes

distribués• Evolution du domaine• Applications• Axes de recherche

Page 5: Systèmes distribués

5

Naissance des systèmes distribués

• 1945 – début de l’ère moderne des ordinateurs

• Jusqu’en 1985 – époque des grands calculateurs centralisés très coûteux

• Début des années 80– Avènement des micro-ordinateurs

• Micro-processeurs puissants produits en quantité (faible coût)

– Réseaux locaux (LAN)• Interconnexion d’un grand nombre de machines• Transfert d’informations à 10 Mbits/seconde• Technologies : Ethernet (Xerox), Token Ring (IBM)

– Il devient facile d’interconnecter des ordinateurs• Système distribué• Quel logiciel pour les systèmes distribués ?

Page 6: Systèmes distribués

6

Avantages des systèmes distribués

• Par rapport aux systèmes centralisés– économique

• excellent rapport performance/prix des microprocesseurs

– puissance de calcul• un système pluri-processeur offre une puissance de calcul

supérieure à celle d ’un seul processeur

– distribution naturelle de certaines applications• système de contrôle d’une chaîne de production

• distribution géographique d ’agences bancaires

– haute disponibilité• la défaillance d ’une machine n’affecte pas les autres

– évolution progressive

Page 7: Systèmes distribués

7

Evolution de la technologie des processeurs

Page 8: Systèmes distribués

8

Avantages des systèmes distribués

• Par rapport à des postes de travail indépendants– partage de données entre les utilisateurs

• exemple : système de réservation aérienne

– partage de périphériques coûteux• exemple : imprimante laser couleur, périphériques

d’archivage

– facilitation des communications entre personnes• courrier électronique

– communication asynchrone– modification possible des documents échangés

– flexibilité (distribution de la charge)

Page 9: Systèmes distribués

9

Inconvénients des systèmes distribués

• Logiciel– relativement peu d’expérience de conception,

mise en œuvre et utilisation de logiciels distribués– la distribution doit elle être transparente aux

utilisateurs ?

• Réseau de communication– saturation– perte de messages

• Sécurité– facilité de partage de données rend nécessaire la

protection des données confidentielles

Page 10: Systèmes distribués

10

Architecture matérielle

Système distribué– ensemble de processeurs interconnectés

Différentes architectures selon– le médium de communication– la façon dont les processeurs

communiquent

Page 11: Systèmes distribués

11

Architecture matérielle

Système distribué = architecture MIMD dans la classification de Flynn’s

Ordinateurs parallèles

ou distribués (MIMD)

Multiprocesseurs

(mémoire partagée)

Multicomputers

(mémoire privée)

Bus Réseau RéseauBus

Architectures

fortement

couplées

Architectures

faiblement

couplées

Sequent, Encore RP3 Réseau local Hypercube

Page 12: Systèmes distribués

12

Multiprocesseur à mémoire partagée fondé sur un bus

Bus

Caches

Processeurs

Mémoirepartagée

P1 P2 P3 P4

Page 13: Systèmes distribués

13

Multiprocesseur à mémoire partagée fondé sur un réseau

– Multiprocesseur à mémoire partagée• Processeurs reliés aux modules mémoire par un switch

de type crossbar ou omega

– Multiprocesseur extensible à mémoire partagée• mémoire distribuée adressable à distance, réseau

d’interconnexion rapide point à point• NUMA (CC-NUMA, COMA)

– De la mémoire est associée à chaque processeur. Un processeur accède très rapidement à sa portion de mémoire mais accède avec une latence plus élevée à la mémoire des autres processeurs (Non Uniform Memory Access).

– Problème de placement des données et des calculs

Page 14: Systèmes distribués

14

Multicomputer fondé sur un bus

Bus(LAN)

Mémoire locale

Processeur

Réseau local de stations de travail

Page 15: Systèmes distribués

15

Multicomputer fondé sur un réseau

• Multiprocesseur à mémoire distribuée– Nœuds de calcul reliés par un réseau

d’interconnexion• Intel Hypercube, Paragon (grille)

– Chaque processeur possède sa propre mémoire privée

Page 16: Systèmes distribués

16

Terminologie

• Système parallèle– Système distribué utilisé pour l’exécution d’une

application gourmande en calcul et/ou mémoire– Multiprocesseurs à mémoire partagée et

multicomputers fondés sur un réseau

• Système distribué– Système distribué dans une utilisation pour de

plusieurs tâches indépendantes– Réseaux de stations de travail

• La frontière n’est pas très nette …– les grappes (clusters)

Page 17: Systèmes distribués

17

Réseau de stations de travail (grappe non dédiée)

Ressources de calcul partagées :

Processeurs, Mémoire, Disques

Interconnexion

Garantie d’une stationde travail par personne(active)

Utilisation globale desressources à certainsmoments

Page 18: Systèmes distribués

18

Grappe de calculateurs dédiée

Page 19: Systèmes distribués

19

Page 20: Systèmes distribués

20

Systèmes de communication rapide standard

• Fibre optique– FCS (Fiber Channel Standard)– ATM (Asynchronous Transmission Mode)– SCI (Scalable Coherent Interface)

• 100 Mo/s• … 1 Go/s • dépassement de la vitesse des communications entre

processeurs dans un SMP

– Myrinet– GigabitEthernet

Page 21: Systèmes distribués

21

Des technologies d’interconnexion

Technologie Débit maximum (lien)

Latence mesurée

Bande passante mesurée

Remarques

GigabitEthernet 125 Mo/s 15 à 20 µs

60 à 90 Mo/s

PCI 32 bits/33 MHz

Myrinet 2000 250 Mo/s 3 à 10 µs Jusqu’à 250 Mo/s

PCI 64 bits/66 MHz

Dolphin SCI D330

666 Mo/s 1,5 µs Plus de 200 Mo/s

Liens partagés (topologie en anneau) PCI 64 bits/66 MHz

Page 22: Systèmes distribués

22

Système distribué à grande échelle

Site

Passerelle(routeur)Réseau physique

Internet

A

C

D

E

• Fondé sur un réseau longue distance

B

Page 23: Systèmes distribués

23

Conception de logiciel pour les systèmes distribués

• Importance du système d’exploitation– Donne l’image de la machine pour l’utilisateur– Influence la façon de programmer la machine

• Système d’exploitation entre l’architecture matérielle et les applications– Système d’exploitation pour un système distribué dépend

• de l’architecture sous-jacente • des applications à exécuter

– Applications indépendantes – Applications parallèles

– Système d’exploitation• Faiblement couplé• Fortement couplé

Page 24: Systèmes distribués

24

Système d’exploitation pour système distribué

• Multiprocesseurs à mémoire partagée– Système d’exploitation à temps partagé de type Unix

• Plusieurs processeurs au lieu d’un seul• Illusion d’une machine mono-processeur pour l’utilisateur

– Une seule copie du système d’exploitation sur la machine• Un processus peut s’exécuter sur n’importe quel processeur de

la machine• Une file des processus prêts à s’exécuter conservée en

mémoire partagée• Synchronisation pour l’accès aux structures de données

partagées du noyau– Section critique pour l’exécution de l’ordonnanceur qui gère la file

des processus prêts

• Communication par mémoire partagée

Page 25: Systèmes distribués

25

Système d’exploitation pour système distribué

• Multicomputers– Système d’exploitation faiblement couplé (network operating

system)• Indépendance des machines

– Un programme peut s’exécuter localement sans le réseau– Réseau permet le partage de ressources entre une communauté

d’utilisateurs» Imprimante, serveur de fichiers» Connexion à distance

• Une copie du système d’exploitation sur chaque machine– Système standard + services distribués (exemple NFS)– Hétérogénéité– Modèle client/serveur

• Communication par fichiers partagés

– NOW, Internet, GRID (Grands Systèmes Informatiques Distribués)

Page 26: Systèmes distribués

26

Système d’exploitation pour système distribué

• Système intégré – Vision d’une machine unique (Single System Image)– Machine uni-processeur virtuelle

• La multiplicité des ressources et leur distribution doivent être transparentes pour l’utilisateur

• Nœuds anonymes

• Un même système d’exploitation s’exécute sur chaque machine– Chaque machine possède sa copie locale du système

d’exploitation– Communication par messages

• Grappes de calculateurs

Page 27: Systèmes distribués

27

Objectif du cours

• Architecture matérielle– Multicomputer

• Réseau local de stations de travail• Grappe de calculateurs• Internet

• Système d’exploitation– Services distribués dans un environnement de

type réseau local– Systèmes à image unique

• Notre définition d’un système d’exploitation distribué

Page 28: Systèmes distribués

28

Système à image unique(Single System Image)

• Architecture matérielle– Ensemble de ressources physiques (mémoire,

disque, processeur) distribuées sur différents nœuds

– Mise en œuvre de ressources logiques (segment de mémoire virtuelle, fichier, processus)

• Transparence• Partage• Extensibilité• Haute disponibilité

Page 29: Systèmes distribués

29

Transparence

• Méthode d’accès aux ressources logiques indépendante de leur localisation– Exemple : accès aux fichiers locaux et distants

• Migration des ressources logiques sans modifier la méthode d’accès– Exemple : migration d’un fichier sans changement

de nom

Page 30: Systèmes distribués

30

Partage

• Partage logique– Ressources logiques peuvent être partagées par des

applications sans modifier la méthode d’accès– Exemple : partage d’un fichier, partage d’un segment de

mémoire virtuelle– Sémantique d’accès aux ressources bien définie en présence de

multiples utilisateurs • Transparence de la concurrence

• Partage physique– Partage des ressources physiques des nœuds entre plusieurs

applications– Possibilité pour une application d’utiliser des ressources

physiques situées sur différents nœuds• Transparence du parallélisme

Page 31: Systèmes distribués

31

Extensibilité

• Extensibilité des performances– L’augmentation des ressources physiques conduit à une

augmentation des performances globales du système– Décentralisation

• Aucun nœud ne connaît l’état global du système

• Chaque nœud doit prendre des décisions en fonction des informations disponibles localement

• La défaillance d’un nœud ne doit pas empêcher le bon fonctionnement du système

• Il n’existe pas d’horloge globale dans le système

– Transparence de la réplication• Les multiples copies d’une donnée gérées par le système

d’exploitation doivent être transparentes pour les utilisateurs

Page 32: Systèmes distribués

32

Extensibilité

• Transparence à l’extensibilité– Ajout de nouveaux nœuds– Retrait (prévu) de nœuds

• Intégration ou suppression de ressources sans arrêt du système et sans perturbation pour les applications en cours d’exécution

• Gestion dynamique des ressources– Reconfiguration du système

Page 33: Systèmes distribués

33

Haute disponibilité

• Haute disponibilité– Défaillance d’un nœud n’entraîne pas

l’indisponibilité du système sur les autres nœuds• Seules les applications utilisant les ressources

physiques du nœud défaillant peuvent être perturbées.• Il reste possible de lancer de nouvelles applications sur

la grappe, privée du nœud défaillant– Reconfiguration du système

• Reprise d’applications– Pas de perte des ressources logiques

• Point de reprise d’applications

Page 34: Systèmes distribués

34

Flexibilité

• Possibilité d’ajouter de nouveaux services• Deux approches dans la conception des systèmes

d’exploitation distribués– Système monolithique

• Chaque nœud met en œuvre localement les différents services

– Micro-noyau• Système d ’exploitation conçu comme un ensemble de serveurs en

mode utilisateur au dessus du micro-noyau• Micro-noyau met en œuvre les fonctions de base et réalise

l’interface avec le matériel– Communication inter-processus

• Serveurs réalisent les fonctions classiques d’un système d ’exploitation

– gestion mémoire– gestion de fichiers– gestion des processus

Page 35: Systèmes distribués

35

Evolution du domaine

• Facteurs d’évolution– Evolution de la demande et des moyens

• Besoin des utilisateurs– nouvelles applications (multimédia, mobilité, …)

• Evolution technologique– informatique

– réseau

– Globalisation des systèmes d’information• facteur d’échelle

Page 36: Systèmes distribués

36

Progrès technologiques

• Architecture matérielle des machines– vitesse des processeurs– capacité d’adressage– capacité mémoire et disque

• Réseaux– débit (ATM)– connectivité (réseaux mobiles)

• Systèmes– systèmes ouverts (standard)– micro-noyaux et systèmes spécialisés

Page 37: Systèmes distribués

37

Impact des progrès technologiques

• Grand espace d ’adressage et réseaux haut débit– mémoire virtuelle répartie– partage d’informations complexes selon différents

degrés de cohérence

• Disques de grande taille, réseaux haut débit et connectivité– Web– GRID

Page 38: Systèmes distribués

38

Facteurs d’échelle

• Système réparti de grande taille– Nombre d ’entités

• nombre d ’éléments constituants• nombre d ’utilisateurs• nombre et taille des informations

– Complexité

– Etendue géographique

• Besoins– extensibilité (désignation, localisation, recherche

d ’information, communication)

– maîtrise de la complexité

Page 39: Systèmes distribués

39

Effets des facteurs d’échelle

• hétérogénéité• cohérence des informations• composition du système à un instant donné• défaillance ou indisponibilité de sous-

systèmes• mobilité des machines, utilisateurs et

informations

Page 40: Systèmes distribués

40

Problèmes liés à la taille du système

• Désignation– abandon des identificateurs universels – usage de caches

• Performance et qualité de service• Disponibilité

– réplication

• Sécurité– authentification, cryptographie

• Administration– complexité et hétérogénéité

Page 41: Systèmes distribués

41

Applications

• Applications scientifiques– Calcul parallèle

• Besoin de puissance de calcul et de mémoire• Minimisation du temps de réponse• Partage de mémoire sur une architecture à mémoire

distribuée (mémoire virtuellement partagée)

• Applications coopératives– Système de réservation de places d’avion– Système de gestion d’agences bancaires– Applications multimédias

Page 42: Systèmes distribués

42

Applications

• Applications multimédias– gestion simultanée d’informations de nature

différente : son, image, texte avec une synchronisation de différents flux d’informations

– applications orientées grand public• abonnement et équipement dédiés chez les abonnés

• Exemples– vidéo à la demande (magnétoscope virtuel)– réunion virtuelle (communication et partage

d’information) avec stations de travail multimédias – commerce électronique, presse électronique

Page 43: Systèmes distribués

43

Applications

• Besoins – qualité de service

• temps réel mou• disponibilité• sécurité• qualité des informations transmises (son, image)

– solutions fondées sur des techniques de réservation de ressources et l’utilisation de réseaux à haut débit

– synchronisation multi-utilisateur• communication de groupe• cohérence de l’information traitée (tableau virtuel)

Page 44: Systèmes distribués

44

Applications

• Courrier électronique et le Web– mise en relation entre un ou plusieurs utilisateurs

identifiés ou non• échange d ’informations• consultation de données multimédias

• Problématique– désignation (système extensible)– grand nombre d’utilisateurs– hétérogénéité

• réseaux• systèmes d’exploitation et des logiciels

Page 45: Systèmes distribués

45

Applications

• Solutions– protocole IP indépendant des architectures sous-

jacentes– transparence de la localisation des informations

accédées– affichage standard de l’information (HTML)– réseaux à haut débit et nœuds de routage

performants

Page 46: Systèmes distribués

46

Applications

• Applications temps réel dur– systèmes temps réels à sûreté critique– exemples

• systèmes embarqués : avionique, automobile, ...

• Problématique– respect des échéances temporelles

• défaillance catastrophique en cas de non respect des échéances

• Solutions– modèle de tâches

• comportement prévisible, temps d ’exécution maximal

– algorithmes d ’ordonnancement– tests de faisabilité

Page 47: Systèmes distribués

47

Axes de recherche

• Architecture des systèmes – nano-noyaux– système pour les nouvelles architectures parallèles

(multiprocesseurs extensibles)

• Systèmes distribués pour des réseaux à très haut débit (100 Mbits/s à 1 Gbits/s)– Systèmes pour grappes

• multiprocesseur virtuel• serveur extensible pour les services grand public

• Systèmes distribués à très grande échelle• intégration des réseaux de télécommunication • Internet• GRID (Middleware)

Page 48: Systèmes distribués

48

Axes de recherche

• Systèmes distribués incluant des sites mobiles construits avec des réseaux sans fil– Ubiquité– Mobilité des calculs, données, utilisateurs, machines

• Support pour le travail coopératif– multimédia, communication de groupe, cohérence

• Tolérance aux fautes– disponibilité et temps-réel

• Environnements de développement d’applications réparties– architecture logicielle (composants)

Page 49: Systèmes distribués

49

Bibliographie

• Construction des systèmes d’exploitation répartis, R. Balter, J.-P. Banâtre, S. Krakowiak éditeurs, INRIA collection didactique, 1991.

• Modern Operating Systems, A. Tanenbaum, Prentice-Hall International Editions, 1992.

• [Rozier et al 1988] Chorus Distributed Operating Systems, Computing Systems, Vol 1, No 4, octobre 1988.

• [Accetta et al 1986] Mach : a new kernel foundation for Unix Development, Proc of Usenix Summer conference 1986.

• [Cheriton 1988] The V Distributed System, Communications of the ACM, Vol 31, No3, 1988.

Page 50: Systèmes distribués

Chapitre 2

Synchronisation

Page 51: Systèmes distribués

51

Synchronisation

• Ordonnancement• Exclusion mutuelle• Election• Terminaison• Interblocage

– voir cours d’algorithmique répartie

Page 52: Systèmes distribués

52

Ordonnancement

• Notion d’événement– Sur chaque site, on définit un état local qui est

modifié par l’exécution des processus du site– Evénement

• changement local d’état sur un site• envoi ou réception d’un message

Page 53: Systèmes distribués

53

Ordre sur les événements

• Evénements locaux à un site– chaque site possède une horloge locale

• on peut définir un ordre total strict sur les événements locaux à un site

• Evénements distants– les délais de transmission des messages sont

variables– l ’état d’un site est perçu par les autres sites

uniquement à travers les informations véhiculées par les messages

• deux sites distincts peuvent avoir une vision différente de l’état d’un troisième site

Page 54: Systèmes distribués

54

Ordonnancement des événements

• Relation de précédence causale• Horloges logiques et ordonnancement par

estampilles• Horloges vectorielles et ordonnancement

causal

Page 55: Systèmes distribués

55

Relation de précédence causale [LAMPORT 78]

• Soient A et B deux événements. A précède directement B ssi l’une des conditions suivantes est vraie :– A et B se produisent sur le même site et A est antérieur à B

sur ce site– A est l’envoi d’un message m sur un site et B est la

réception de m sur un autre site

• La relation précède (notée ) est la fermeture transitive de la relation précède directement.

• La relation est une relation d’ordre partiel appelée relation de précédence causale.

Page 56: Systèmes distribués

56

Exemple

S1

S2

S3

e11 e12 e13

e21 e23 e25e22 e24

e31 e32 e33 e34

e21

e22

e23

e24

e25

e31e11

e12

e13

e33

e32

e34

Page 57: Systèmes distribués

57

Evénements concurrents

• Evénements causalement indépendants• Définition du passé d’un événement

– hist (e) = {e} {e ’ tq e ’e }

• Evénements concurrents– A || B <=> non(A B) et non (B A)

• Aucun des deux événements n’appartient au passé de l ’autre

• Aucun des deux événements ne peut influer sur l’autre

Page 58: Systèmes distribués

58

Exemple

S1

S2

S3

e11 e12 e13

e21 e23 e25e22 e24

e31 e32 e33 e34

e21

e22

e23

e24

e25

e31e11

e12

e13

e33

e32

e34e25 et e32 sont concurrents

Page 59: Systèmes distribués

59

Observation d’un calcul réparti

• Observation d’un calcul réparti E = définition d’un ordre total (noté <<) sur les événements de E : e, e ’ E: e e ’ => e<<e ’

• Observation valide = compatible avec la relation de précédence causale (ie pourrait être observée par un observateur externe réel)

Page 60: Systèmes distribués

60

Exemple

e11,e21,e31,e22,e23,e32,e24,e25,e12,e33,e13,e34 valide

e11,e21,e31,e22,e32,e23,e24,e25,e12,e33,e13,e34 valide

e11,e21,e31,e22,e32,e23,e24,e25,e12,e33,e34,e13 invalide

S2

S3

e11 e12 e13

e21 e23 e25e22 e24

e31 e32 e33 e34

S1

Page 61: Systèmes distribués

61

Horloges logiques et ordonnancement par estampilles

• Objectif– dater (pour ordonner) les événements dans un

système réparti en respectant les propriétés :• L’ordre des dates est compatible avec la relation de

précédence causale• La datation d’un événement sur un site ne met en œuvre

que des informations locales

Page 62: Systèmes distribués

62

Réalisation des horloges logiques

• Un compteur entier Hi est conservé sur chaque site Si

• Un événement e sur le site Si est daté par H(e) = Hi

• Initialisation

– Hi = 0, pour tout i

• A chaque événement local sur Si

– Hi := Hi + 1 ;

– e est daté par Hi

• Chaque message est estampillé par la date de son émission :

– (m, E(m)), avec E(m) = H(émission)• A la réception d’un message (m, E(m)) sur le site Si

– Hi := max (Hi, E(m)) + 1

Page 63: Systèmes distribués

63

Exemple

0 1 3 4 6

0

1 2 3 4 5

0

2 3

S1

S2

S3

Deux événements sont datés 2 l’ordre sur les estampilles n’est pas strict.

Page 64: Systèmes distribués

64

Ordre strict sur les estampilles

• Deux événements causalement indépendants se produisant sur des sites distincts peuvent avoir la même date.

• Pour avoir un ordre strict sur les estampilles, il suffit de définir un ordre arbitraire sur les sites.

• Estampille = (numéro de site, heure logique)• Définition d’une relation d’ordre total strict :

– soient A et B deux événements se produisant respectivement sur les sites Si et Sj et estampillés par (i,Ha) et (j,Hb)

– (A<<B) (Ha<Hb) ou ((Ha=Hb) et (i<j))

Page 65: Systèmes distribués

65

Datation par estampilles

(1,0) (1,1) (1,3) (1,4) (1,6)

(2,0)

(2,1) (2,2) (2,3) (2,4) (2,5)

(3,0)

(3,2) (3,3)

S1

S2

S3

Les événements sont totalement ordonnés.

Page 66: Systèmes distribués

66

Utilisation des horloges logiques

• Algorithmes de mise en œuvre de files d’attente virtuelles réparties– exclusion mutuelle

– mise à jour cohérente de copies multiples

– diffusion cohérente

• détermination de l’événement le plus récent dans un ensemble d’événements– gestion de la cohérence de caches

– mise en œuvre de la mémoire virtuellement partagée

• génération de noms uniques• synchronisation d’horloges physiques

Page 67: Systèmes distribués

67

Limitations de l’ordonnancement par estampilles

• Les estampilles définissent un ordre total mais la relation de dépendance causale est un ordre partiel.

• Les estampilles effacent artificiellement la notion de dépendance causale– A<<B : A B ou A et B concurrents– soient A et B deux événements concurrents estampillés

respectivement par Ha et Hb

• on peut avoir indifféremment Ha = Hb, Ha< Hb, Ha> Hb.

• Les estampilles ne sont pas denses– si H(e) < H(e ’), on ne peut pas savoir s’il existe e ’ ’ tq

e e  ’ ’ et e ’ ’ e ’

• La caractérisation de l’indépendance causale est nécessaire pour certaines applications tq la mise au point. Il faut une horloge V tq

e e  ’ V(e) < V(e ’)

Page 68: Systèmes distribués

68

Ordonnancement causalDatation causale par historique

S1

S2

S3

e11

e21

e22

e23

e24

e25

e31 e32 e33 e34

e12 e13

Hist(e33) ={e11,e21,e22,e23,e24,e25,e31,e32,e33}

Page 69: Systèmes distribués

69

Utilisation du passé d’un événement pour la datation

• La connaissance de l’historique des événements permet de déterminer la dépendance causale :– hist(e) = {e ’ tq e ’ e}{e}– e e ’ e hist(e ’)– e || e ’ ((ehist(e ’)) et (e ’ hist(e))

• Inconvénient : taille de l ’historique• Solution : horloges vectorielles

– pour définir hist(e), un seul événement par site suffit.

Page 70: Systèmes distribués

70

Horloges vectoriellesFidge 88 - Mattern 88

• Définition– histi(e) = {e ’ hist (e) tq e ’ Si}

(événements de l’historique qui se sont produits sur Si)

• Propriétés– e i,k histi(e) j<k : e i,j histi(e)

– Donc un seul entier suffit pour représenter histi(e) : le nombre d’événements de histi(e)

– Comme hist(e) =histi(e), il faut un vecteur V(e) pour représenter hist(e).

1 i n : V(e)(i) = k, tq e i,k histi (e) et e i,k+1 histi(e)

V(e)(i) = nombre d’événements de Si connus de e

Page 71: Systèmes distribués

71

Réalisation des horloges vectorielles

• On associe un vecteur Vi à chaque site Si

• Initialement, Vi = (0,…,0)

• A chaque événement local à Si, Vi(i) := Vi(i) + 1

• Chaque message m porte une estampille Vm = Vi de l ’émetteur

• A la réception de (m, Vm) par un site Si :

– Vi(i) := Vi(i) + 1 ;

– Vi(j) := max (Vi(j), Vm(j)) pour j = 1, …, n, j i

Page 72: Systèmes distribués

72

Exemple

S1

S2

S3

S4

(1,1,0,0) (2,1,0,0) (3,1,0,0)

(0,1,0,0)

(0,2,0,0) (2,3,3,1)

(0,0,1,1)

(2,1,2,1) (2,1,3,1)

(0,0,0,1) (0,0,0,2)

Page 73: Systèmes distribués

73

Propriétés des horloges vectorielles

• Relation d’ordre partiel sur les horloges vectorielles– V V ’ défini par i : V(i) V ’(i)– V< V ’ défini par V V ’ et V V ’– V || V ’ défini par non (V < V ’) et non (V ’ < V)

• Les horloges vectorielles sont densessoit ei Si, ej Sj. Si V(ei)(k) < V(ej)(k), pour k j,

alors il existe ek tel que non(ekei) et (ek ej)

Page 74: Systèmes distribués

74

Dépendance causale et horloges vectorielles

• Les horloges vectorielles représentent exactement la dépendance causale

A,B :

AB V(A) < V(B)

A||B V(A) || V(B)

Page 75: Systèmes distribués

75

Démonstration

• Si A B alors par transitivité i : {xSi, x A}{x Si, x B} (passé de A inclus dans passé de

B) donc i : Vi(A) < Vi(B)

• Supposons A||B, ASk, B Si

soit histk(B) = {x Sk, xB} (passé de B dans Sk)

soit C = max (histk(B)) au sens de

Par construction, C B (car C histk(B) et CB)

Alors C A (sinon on aurait A B) donc

histk(C) = histk(B) histk(A)

d ’où Vk(B) < Vk(A)

Par un raisonnement symétrique : Vi(A) < Vi(B)

Donc V(A) || V(B)

Page 76: Systèmes distribués

76

Utilisation des horloges vectorielles

• Datation• Diffusion fiable avec ordonnancement causal• Simulation répartie• Calcul d’état global• Mise au point

Page 77: Systèmes distribués

77

Bibliographie

• [Lamport 78] Time, clocks and the ordering of events in a distributed system, Communications of the ACM, Vol 21, Juillet 1978.

• [Fidge 88] Timestamps in message-passing systems that preserve the partial ordering, Proc. 11th Australian conference, Février 1988.

• [Mattern 88] Virtual time and global states in distributed systems, International conference on parallel and distributed algorithms, North Holland, 1988.

Page 78: Systèmes distribués

Chapitre 3

Communication

Page 79: Systèmes distribués

79

Communication entre processus

• Système centralisé– communication par mémoire partagée

• Système distribué– communication par échange de messages

• Protocole de communication– Ensemble de règles auxquelles adhèrent les processus qui

veulent communiquer

• Modèle client/serveur– Requête/réponse

– appel de procédure à distance

• Communication entre plusieurs processus– diffusion

• groupe de processus• tous les processus du système

Page 80: Systèmes distribués

80

Plan

• Protocoles de communication dans les systèmes à grande échelle

• Modèle client/serveur• Appel de procédure à distance (RPC)• Communication de groupe

Page 81: Systèmes distribués

81

Protocoles de communication dans les systèmes à grande échelle

• Modèle OSI (Open Systems Interconnection)– Généralités

• Modèle OSI développé par l’ISO (International Standards Organization) qui est un organisme de normalisation

Page 82: Systèmes distribués

82

Exemple basique

Interface réseau Interface réseau

Pilote

Protocoles Protocoles

Pilote

Médium physique

Matériel

Système d’exploitation

Applications Applications

Exemple : HTTP sur TCP/IP sur Ethernet

Ethernet

Ethernet

TCP/IP

HTTP

Machine A Machine B

Navigateur Serveur Web

Page 83: Systèmes distribués

83

Le modèle OSI

Physique Physique Physique Physique

LiaisonLiaisonLiaison Liaison

RéseauRéseauRéseau Réseau

Transport

Session

Présentation

Transport

Session

Présentation

Application ApplicationProtocole d’application

Protocole de présentation

Protocole de session

Protocole de transport

Bit

Trame

Paquet

TPDU

SPDU

PPDU

APDU

Site A Site B

1

2

3

4

5

6

7

Sous-réseau

Médium physique

Page 84: Systèmes distribués

84

Transmission des données dans le modèle OSI

Processusémetteur

ProcessusrécepteurDonnée

DonnéeAH

PH Donnée

SH Donnée

TH Donnée

NH Donnée

DH DTDonnée

Bits

Application

Présentation

Session

Transport

Réseau

Liaison

Physique

Canal de transmission de données

Application

Présentation

Session

Transport

Réseau

Liaison

Physique

Page 85: Systèmes distribués

85

Les couches basses OSI

• La couche physique– Transmission de bits de manière brute sur un

médium de communication– Assure que si le site d’émission envoie un bit à 1

(0), le site de réception reçoit un bit à 1 (0)– Interface mécanique et électrique

• La couche liaison de données– Transmission d’une suite de bits (trame) sans

erreur du site d’émission au site de réception– Fabrication des trames, gestion d’acquittements,

contrôle de flux, transmission full-duplex

Page 86: Systèmes distribués

86

Les couches basses OSI (2)

• La couche réseau– Transmission de paquets entre un site d’émission

et un site de réception– Routage, contrôle de congestion, interconnexion

de réseaux hétérogènes, facturation

Page 87: Systèmes distribués

87

La couche transport OSI

• Accepte des données de la couche session, les découpe en plus petites unités et assure que les unités sont transmises au site de destination de façon efficace

• Rend la couche session indépendante des changement de technologie du matériel

• Multiplexage des connexions transport sur une connexion réseau ou utilisation de plusieurs connexions réseaux pour une connexion transport de façon transparente à la couche session

Page 88: Systèmes distribués

88

La couche transport OSI (2)

• Différents services à fournir à la couche session– canal point à point sans erreur délivrant les messages dans

l’ordre d ’émission– datagramme sans garantie sur l’ordre de délivrance– diffusion de messages

• Protocole de bout en bout entre site source et site de destination

• Gestion de connexions multiples dans chaque site• Etablissement et relâchement des connexions

réseaux• Contrôle de flux

Page 89: Systèmes distribués

89

Exemple

Site A Site B

Plusieurs connexions transport simultanées entre différents processus sur divers sites.

Site C

Page 90: Systèmes distribués

90

Les couches hautes OSI : session

• Permet à des utilisateurs sur différentes machines d’établir des sessions entre eux

• Session : transport de données + services avancés– synchronisation

• Exemples de services de niveau session– dialogue entre utilisateurs

• jeton

– transfert de fichiers entre deux machines• Transfert d’un très gros fichier plus long que l’intervalle moyen

entre deux défaillances

• Gestion du transfert d’un fichier de manière à éviter la reprise du transfert depuis le début en cas de défaillance

Page 91: Systèmes distribués

91

Les couches hautes OSI : présentation

• S’intéresse à la syntaxe et à la sémantique de l’information transmise

• Exemples– encodage de données dans une norme agréée

• les machines utilisent différents codes (ASCII, EBCDIC) pour représenter les chaînes de caractères

• définition de formats abstraits pour permettre à des machines hétérogènes de communiquer

• couche de présentation effectue les conversions entre les formats abstraits et les codes des machines

– compression de données– chiffrement

Page 92: Systèmes distribués

92

Les couches hautes OSI : application

• Nombreux protocoles d’usage courant– Terminal de réseau virtuel

• exemple– éditeur de texte conçu pour un terminal virtuel car doit être

capable de fonctionner sur des terminaux réels aux caractéristiques différentes

– logiciel de traduction entre terminal virtuel et terminal réel

– Transfert de fichiers• convention de désignation, représentation des données

diffèrent selon les systèmes de fichiers– gestion de l’hétérogénéité

– Services de courrier électronique, web, consultation d’annuaires ...

Page 93: Systèmes distribués

93

Exemple : Internet

• Interconnexion de réseaux (Internetworking)– Donner aux utilisateurs l’illusion d’un seul réseau et d’un

service de communication universel

Site

InternetA

B

C

D

E

Page 94: Systèmes distribués

94

Architecture de l’Internet

Site

Passerelle(routeur)Réseau physique

Internet

A

B

C

D

E

Page 95: Systèmes distribués

95

Interconnexion de réseaux

Réseau 1 Réseau 2

G1

Réseau 1 Réseau 2 Réseau 3

G1 G2

Passerelle (gateway)

Interconnexion de réseaux physiques

Passerelle route les paquets en fonction du réseau de destinationTransit des paquets du réseau 1 vers le réseau 3 à travers le réseau 2

Page 96: Systèmes distribués

96

Caractéristiques de l’Internet

• Applications indépendantes des technologies de communication sous-jacentes et de la topologie des réseaux– Logiciel d’accès à Internet sur chaque site, seul ce logiciel

doit être changé pour prendre en compte les nouvelles technologies

– Changement de topologie ou de technologie de communication transparent aux applications

• Pas de réseau central– Architecture complètement distribuée

• tous les réseaux physiques sont traités de manière identique quelque soit leur taille

– Identificateurs universels (nom ou adresse) pour les sites de l’Internet

Page 97: Systèmes distribués

97

Internet dans le modèle OSI

Physique

Liaison

Réseau

Transport

Session

Présentation

Application

1

2

3

4

5

6

7

IP

UDP TCP

RPC

XDR

HTTP

FTP TELNETNFS DNS HTML NTP SMTP

SNMP

ARP

Page 98: Systèmes distribués

98

Exemple : FTP entre des sites sur un LAN

Client FTP Serveur FTP

TCP

IP

TCP

IP

PiloteEthernet

PiloteEthernet

Ethernet

Liaison (2)

Réseau (3)

Transport (4)

Application (7)

Protocole FTP

Protocole TCP

Protocole IP

Protocole Ethernet

Page 99: Systèmes distribués

99

Exemple : FTP entre des sites sur des réseaux distincts

Client FTP Serveur FTP

TCP

IP

TCP

IP

PiloteEthernet

PiloteToken Ring

Ethernet

Protocole FTP

Protocole TCP

Protocole Ethernet

Token Ring

IP

PiloteEthernet

PiloteToken Ring

IP IP

Protocole Token RingRouteur

Réseau (3)

Transport (4)

Application (7)

Liaison (2)

Page 100: Systèmes distribués

100

Discussion

• La pile de protocole implique la gestion de diverses entêtes– Satisfaisant pour un réseau longue distance– Pénalisant sur un réseau local (LAN)

• Le modèle OSI est un modèle réseau– Aucune définition de la structure d’un système

distribué

Page 101: Systèmes distribués

101

Modèle client/serveur

• Vision du client

Client

• Vision du serveur

• Une machine exécute un ou plusieurs processus client ou serveur.

• Exemples– serveur de fichiers, serveur de calcul, serveur de noms, serveur

d’impression

Service distantrequête

réponse

traitementrequêtes réponses

Page 102: Systèmes distribués

102

Modèle client serveur

Noyau Noyau

Site 1 Site 2 Site 3

Réseau

(exemple : Ethernet)

Requête

Réponse

Client Serveur

1

2

3

4

567

Requête/réponse

Liaison

Physique

Page 103: Systèmes distribués

103

Réalisation du client

• Construction d’un message de requête– Type du message

• Exemple (serveur de fichiers) : Créer, lire, écrire, supprimer

– Données• Exemple (serveur de fichiers) : pour une lecture, nom du fichier,

nombre d’octets à lire, position dans le fichier• Source (client) et Destination (serveur)

• Envoi du message de requête au serveur• Exemple (serveur de fichiers) : le message est envoyé au

serveur de fichier

• Réception d’une réponse du serveur• Exemple (serveur de fichiers) : le message reçu contient les

octets lus

Page 104: Systèmes distribués

104

Réalisation du serveur

• Processus cyclique– réception d’un message de requête– traitement selon le type de requête

• Exemple (serveur de fichiers) : lecture sur disque pour traiter une requête de lecture

– envoi du message de réponse au client

• Processus veilleur et traitement de la requête par un processus d’un pool de processus exécutants (créés statiquement)

• Processus veilleur et traitement de la requête par un processus exécutant créé dynamiquement

Page 105: Systèmes distribués

105

Communication par message

• Emission d’un message– envoyer (message, destinataire)

• Réception d’un message– recevoir (adresse,message)

Page 106: Systèmes distribués

106

Choix de conception

• Adressage• Primitives bloquantes ou non bloquantes• Gestion de tampons de message• Communication fiable ou non fiable

Page 107: Systèmes distribués

107

Adressage

• Adresse fondée sur un numéro de machine– Adresse = numéro de machine

• Comment distinguer plusieurs processus s’exécutant sur une même machine

– Adresse = numéro de machine + numéro local de processus

– Adresse = numéro de machine + adresse locale• Processus indique au noyau qu’il utilise une adresse

locale donnée

• Pas de transparence à la localisation

Page 108: Systèmes distribués

108

Adressage

• Attribution d’une adresse unique de processus ne contenant pas de numéro de machine par un serveur centralisé– Serveur centralisé gère un compteur incrémenté

de 1 chaque fois qu’une adresse est attribuée– Solution non extensible

• Chaque processus s’attribue une adresse unique – Choix dans un grand espace d’adressage pour

avoir une faible probabilité de choix d’une même adresse par deux processus distincts

Page 109: Systèmes distribués

109

Adressage

– Problème : à quelle machine envoyer un message• Diffusion de l’adresse à toutes les machines• Celle sur laquelle s’exécute le processus désigné répond• Possibilité de gérer un cache de translation des

adresses de processus en numéros de machine

• Utilisation de noms symboliques pour désigner les processus– Serveur de désignation établit la correspondance

entre un nom symbolique et une adresse de processus

– Traduction du nom à l’exécution et gestion de caches de noms

Page 110: Systèmes distribués

110

Primitives bloquantes ou non bloquantes

• Primitive d’envoi de message– Bloquante pendant toute la durée de transmission du

message• Pas de recouvrement calcul/communication

– Non bloquante• Utilisateur ne peut pas modifier son tampon tant que celui-ci n’a

pas été transmis– Comment savoir que la transmission est terminée ?

» Interruption

• Recopie du tampon utilisateur dans un tampon du noyau– Coût de la copie qui s’ajoute à celle effectuée pour le transfert du

message dans le tampon d ’émission de la carte d’interface réseau

– Définition du terme bloquant• Jusqu’à transmission ou bien jusqu’à acquittement ?

Page 111: Systèmes distribués

111

Primitives bloquantes ou non bloquantes

• Primitive de réception– En général, bloquant– Non bloquant

• Primitive d’attente ou de test d’arrivée d’un message

• Limitation de la durée de blocage– En cas de défaillance, attente infinie– Time-out (délai de garde)

Page 112: Systèmes distribués

112

Gestion de tampons de message• Que se passe-t-il si un message arrive sur une machine

avant qu’un processus n’ait demandé sa réception ?– Envoi avant réception– Plusieurs processus envoient un message au même serveur

qui peut être occupé à traiter un autre message

• Boîte aux lettres– Un processus indique au noyau l’adresse à laquelle il est

susceptible de recevoir un message– Le noyau alloue une boîte aux lettres au processus (tampons

pour recevoir des messages) au processus dans laquelle sont déposés les messages adressés au processus

– Primitive de réception bloquante si la boîte aux lettres est vide– Réception d’un message = extraction du message de la boîte

aux lettres

Page 113: Systèmes distribués

113

Gestion de tampons de message

– Une boîte aux lettres n’est pas de taille infinie• Que faire lorsque la boîte aux lettres est pleine ?

• L’émetteur d’un message s’assure qu’un tampon est disponible pour la réception du message avant de l’émettre– Envoi d’un message préalable de réservation d’un

tampon

Page 114: Systèmes distribués

114

Communication fiable ou non fiable• Réseau non fiable

– Un paquet peut être perdu– Délai d’acheminement des paquets variable– Déséquencement possible des paquets

• Message utilisateur peut être fractionné en plusieurs paquets

• Primitive non fiable– Programme utilisateur doit gérer la perte

• Primitive fiable– Gestion d’acquittements explicites par le noyau pour les messages de

requête et de réponse• Message de réponse peut servir d’acquittement au message de requête

– Retransmission en cas de perte• Numérotation des messages en séquence pour éviter qu’un message ne

soit traité deux fois

– Acquittement de message ou de paquet

Page 115: Systèmes distribués

115

Appel de procédure à distance

Appel de procédure local

P

c

P

Site client Site serveur

c s

(appel, P, paramètres)

(réponse, P, résultats)

Appel de procédure à distance

Page 116: Systèmes distribués

116

Différence entre appel local et appel de procédure à distance

• gestion de la création et de l’exécution du processus serveur

• transmission des paramètres à l’appel et des résultats au retour

• mécanismes de conversion pour le passage des paramètres et résultats car client et serveur peuvent être écrits dans des langages différents et s’exécuter sur des processeurs différents

• spécification du comportement en cas de défaillance

Page 117: Systèmes distribués

117

Mécanismes de base

• Transparence de l’appel à distance pour le client et le serveur– talon client

• sur le site appelant, fournit au processus client une interface identique à celle de la procédure appelée

– talon serveur• sur le site appelé, fournit au processus serveur une

interface identique à celle d’un appel local

– chaque talon doit être lié au programme d’un processus sur le site correspondant et fonctionne comme un représentant de l’autre processus sur le site distant

Page 118: Systèmes distribués

118

Réalisation d’un appel de procédure à distance

appel

retour

emballage

<attente>

déballage

déballage

Gestion processus

emballage

Exécution procédure

Programme appelant Talon client Talon serveur Programme appelé

messageEnvoiparamètres

Réception paramètres

Envoi résultatsmessageRéception

résultats

Site appelant (client) Site appelé (serveur)

Système decommunication

Page 119: Systèmes distribués

119

Réalisation d’un appel de procédure à distance

• Fonctions du talon client– emballage : mise en forme des paramètres pour le transport

sur le réseau– envoyer vers le site appelé un message contenant l’identité

de la procédure appelée et les paramètres– provoquer le blocage du processus client en attente de la

réponse– réveil du client lors de l’arrivée du message de réponse– extraction des résultats et convertir si besoin– exécuter le retour de procédure avec transmission des

résultats

Page 120: Systèmes distribués

120

Réalisation d’un appel de procédure à distance

• Fonction du talon serveur– à partir du message reçu, déterminer la procédure

appelée et déballer les paramètres– exécuter la procédure appelée en lui passant les

paramètres – préparer le message de retour en emballant les

résultats– envoyer le message de retour au site appelant– terminer l’exécution

Page 121: Systèmes distribués

121

Emballage/déballage

• Définition d’un format standard pour la représentation des données– spécifie la représentation des données

élémentaires et des constructions• Transmission des paramètres et résultats par valeur

car espaces d ’adressages de l’appelé et de l’appelant sont différents

• Pas de pointeur car interprétation à distance impossible

• Transmission de structures complexes si procédures d’emballage et déballage fournies

Page 122: Systèmes distribués

122

Langages de description d’interface et compilateurs de talons

• Outils fournis aux programmeurs d ’applications réparties pour réaliser des RPC sans avoir à connaître le détail des mécanismes sous-jacents.

• Spécification des interfaces dans un langage approprié– pour chaque procédure qui peut être appelée à distance, le

programme spécifie• le nom de la procédure• pour chaque paramètre, son type et son sens de

transmission– lorsque le langage de spécification d’interface est commun à

plusieurs langages de programmation, possibilité de communication entre des programmes écrits dans ces différents langages

Page 123: Systèmes distribués

123

Compilateur de talons

• Produit les talons clients et serveurs à partir de la spécification d’interfaces de procédures

• Possède deux fonctions– engendre les procédures d’emballage et de

déballage • construit une procédure d’emballage des paramètres et

de déballage des résultats pour le talon client• construit une procédure de déballage des paramètres et

d’emballage des résultats pour le talon serveur

– réalise la liaison pour l’appel de procédure

Page 124: Systèmes distribués

124

Liaison

• Liaison statique– compilateur de talons associe à chaque procédure

une identification interne unique (numéro d’ordre) qui permet à l’appelant de la désigner

• cette identification est emballée avec les paramètres dans le message d’appel

– chaque talon serveur conserve une table engendrée par le compilateur de talons qui associe l’identification interne de chaque procédure exportée par le site et l’adresse de cette procédure

Page 125: Systèmes distribués

125

Liaison

• Liaison dynamique– nom symbolique qui est transmis dans le message

d’appel– correspondance entre nom symbolique et nom

interne établie à l’exécution• modalités dépendent du langage et de la sémantique de

la liaison dynamique

Page 126: Systèmes distribués

126

Localisation du serveur

• Appel à un serveur de liaison• Serveur

– Enregistre / dé-enregistre ses services auprès du serveur de liaison

• Enregistrer (nom, version, adresse, numéro unique)• Dé-enregistrer (nom, version, numéro unique)

• Client– Recherche de serveur

• Chercher (nom, version)– Rend l’adresse et le numéro unique du serveur s’il existe

Page 127: Systèmes distribués

127

Traitement des défaillances

• 3 entités sujettes à défaillance– site client, site serveur et système de

communication

• Nécessité de définir le comportement de l’appel de procédure à distance dans les différentes hypothèses de défaillance– sémantique de l’appel de procédure à distance

• Réaliser les mécanismes nécessaires au traitement des défaillances

Page 128: Systèmes distribués

128

Exemples de défaillances

• Impossible de contacter le serveur• Perte d’un message client -> serveur

– appel ou acquittement

• Perte d’un message serveur -> client– retour, acquittement

• Défaillance du serveur au cours de l’appel– À quel moment exactement ?

• Défaillance du client entre l’appel et le retour

Page 129: Systèmes distribués

129

Sémantiques de l’appel de procédure à distance (défaillance du serveur)

• Exécution incertaine (may be semantics [SPECTOR 82]– un seul message d’appel– en présence de pannes

• procédure exécutée 0, 1 fois ou partiellement

• Exécution au moins une fois (at least once semantics [BACON 87]– en présence de panne

• au moins une fois si le client reçoit message de RETOUR

Page 130: Systèmes distribués

130

Sémantiques du RPC

• Exécution au moins une fois (suite)– Protocole : délai de garde sur site client

• retransmission du message d ’APPEL• abandon de l’appel par le site client à l’issue d’un

nombre prédéfini de retransmissions sans message de RETOUR

– Convient aux procédures idempotentes

Page 131: Systèmes distribués

131

Sémantiques du RPC

• Exécution au moins une fois et retour du résultat de la dernière exécution (last of many semantics) [LAMPSON 81]

• Protocole– retransmission du message APPEL– numérotation en séquence des messages APPEL

correspondants à un même RPC– conservation du dernier message APPEL envoyé

Page 132: Systèmes distribués

132

Sémantiques du RPC

– Serveur conserve le numéro de séquence du dernier message APPEL reçu et chaque message APPEL donnant lieu à une exécution

– Serveur n’exécute un APPEL que si son numéro de séquence est supérieur à ceux reçus antérieurement

– Client élimine tous les messages RETOUR ne correspondant pas au dernier message APPEL

Page 133: Systèmes distribués

133

Sémantiques du RPC

• Critique– fonctionne en l’absence de pannes de sites – fonctionne en présence de pannes des sites client

ou serveur en cas d’appels non imbriqués– mis en défaut en cas d’appels de procédure

imbriqués si un des sites de la chaîne d’appel est défaillant

Page 134: Systèmes distribués

134

Sémantiques du RPC

• Exécution au plus une fois (at most once semantics) [LISKOV 87, Argus]– motivée par la construction d’applications

distribuées très fiables (système bancaire)• fondée sur des actions atomiques (tout ou rien)

– redondance

– mise en œuvre coûteuse

– procédure exécutée 0 ou 1 fois en cas de défaillance

Page 135: Systèmes distribués

135

Le problème des orphelins(défaillance du client)

• Cause des orphelins– retransmission du message APPEL peut provoquer

plusieurs exécutions de la procédure appelée, toutes sauf une sont des orphelins

– exception ou défaillance du client • quand le client cesse d’attendre le message RETOUR,

l ’exécution de la procédure sur le serveur est un orphelin

• Orphelins indésirables– peuvent interférer avec les exécutions valides– consomment des ressources du système

• augmentation des conflits, baisse des performances

Page 136: Systèmes distribués

136

Traitement des orphelins

• Prévention• Elimination• Récupération

Page 137: Systèmes distribués

137

Traitement des orphelins

• Prévention– numérotation des messages d ’APPEL avec un

identificateur unique (uid) associé à l’appel de procédure à distance

– serveur écarte tous les messages redondants– conservation du résultat et de l’uid d’un appel en

mémoire stable pour faire face à la défaillance du serveur

Page 138: Systèmes distribués

138

Traitement des orphelins

• Elimination– à l’initiative du site client

• élimination lors d’une reprise après panne du site client

• contacte les sites ayant donné lieu à des appels

• notifie l’appelant

– à l ’échéance d’un délai d’exécution• dans les systèmes où les horloges des sites sont

synchronisées

• un site élimine un processus qui exécute un appel au bout d ’un temps fixé

– à l’initiative du site serveur• lorsqu’un site est détecté en panne, les appels qu’il a initialisés

sont éliminés

Page 139: Systèmes distribués

139

Traitement des orphelins

• Récupération– suppose l’existence d ’un mécanisme de reprise

après panne des processus– sauvegarde d’un point de reprise lors de chaque

appel de procédure à distance– conservation en mémoire stable des numéros de

séquence des messages d’APPEL et de RETOUR– conservation des résultats de l’appel en mémoire

stable sur le serveur

Page 140: Systèmes distribués

140

Diffusion

• Généralités• Diffusion atomique

– Problèmes– Le protocole de Schneider 86

• Protocole de diffusion atomique Chang et Maxemchuk 84

• Protocoles de diffusion fiable du système Isis– Le système de communication d ’Isis– protocole ABCAST (ordre total)– protocole CBCAST(diffusion causale)

Page 141: Systèmes distribués

141

Diffusion

• Dans un système distribué, la communication point à point n’est pas toujours bien adaptée.

• Un message peut être destiné à un groupe de processus.

émetteur récepteurs

Page 142: Systèmes distribués

142

Exemples d ’utilisation des groupes de processus

• Service de gestion de fichiers tolérant aux fautes mis en œuvre par plusieurs serveurs

• Gestion de copies multiples pour des raisons d ’efficacité ou de disponibilité– exemple : base de données répliquée

• Réalisation d ’algorithmes répartis– élection– terminaison

Page 143: Systèmes distribués

143

Communication de groupe

• Lorsqu’un message est destiné à un groupe de processus tous les membres du groupe le reçoivent.

• Les groupes sont dynamiques : création, suppression, ajout ou retrait de membres– retrait d ’un membre suite à une défaillance– changement de la composition du groupe au cours d ’une

diffusion– reconstitution d ’un groupe

• Intérêt de l’abstraction de groupe – un processus peut envoyer un message à un groupe de

serveurs sans en connaître le nombre ou la localisation

Page 144: Systèmes distribués

144

Mise en œuvre de la communication de groupe

• Primitives du réseau de communication– la mise en œuvre de la diffusion d ’un message à

un groupe s ’appuie sur les primitives de communication du réseau sous-jacent :

• envoyer (message, site)• diffuser_groupe (message, groupe_site) (multicast)• diffuser (message) (broadcast)

Page 145: Systèmes distribués

145

Caractéristiques d’une diffusion fiable

• Diffusion atomique– propriété du tout ou rien : le message diffusé est délivré à tous les

membres corrects du groupe ou à aucun d ’entre-eux.

• Ordre de réception des messages diffusés– ordre de réception identique pour tous les membres du groupe

• pour un émetteur unique et un seul groupe récepteur• pour un ensemble d ’émetteurs et un seul groupe récepteur• pour un ensemble d ’émetteurs et plusieurs groupes non disjoints

– préservation de l ’ordre d ’émission• aucun ordre garanti• ordre total• ordre causal

Page 146: Systèmes distribués

146

Emetteur unique et un seul groupe de réception

• Si deux messages m1 et m2 sont diffusés par un site S vers un groupe, alors tous les membres du groupe reçoivent m1 et m2 dans le même ordre.

S A B C

(m1,G1)

(m2,G1)

G1 = {A,B,C}

Page 147: Systèmes distribués

147

Plusieurs émetteurs et un groupe de réception unique

• Si m1 et m2 sont destinés à un même groupe, les membres de ce groupe reçoivent m1 et m2 dans un ordre identique même si m1 et m2 proviennent de deux sources différentes.

S1 A B C S2

(m1,G1) (m2,G1)

G1 = {A,B,C}

Page 148: Systèmes distribués

148

Plusieurs émetteurs et plusieurs groupes destinataires

• Si deux messages m1 et m2 sont délivrés à deux processus P1 et P2, ils sont délivrés dans un ordre identique même si m1 et m2 proviennent de sources différentes.

S1 A B C S2

(m1,G1) (m2,G2)

G1 = {A,B,C}

G2 = {A,B}

Page 149: Systèmes distribués

149

Séquencement des messages selon l ’ordre causal

• DéfinitionSoient les deux événements E1 = émission (m1)

et E2 = émission (m2),

L ’ordre causal est respecté si la propriété suivante est respectée :

si (E1E2) et m1 et m2 ont même destinataire alors

réception(m1) réception(m2)

• ExempleS1

S2

S3

m1 m2

m3

Page 150: Systèmes distribués

150

Hypothèse sur la fiabilité du système

• Sites fail-stop• Réseau de communication non fiable

– perte, duplication, déséquencement des messages

– non altération des messages pendant leur transmission

– partitionnement du réseau

Page 151: Systèmes distribués

151

Diffusion atomique

• Atomicité – un message diffusé est reçu par tous les membres du

groupe destinataire non défaillants ou par aucun d ’entre

eux.• Idée de mise en œuvre

– pour un réseau point à point offrant une communication point à point fiable

– L ’émetteur envoie le message à chacun de ses destinataires. Lorsque le message arrive sur un site destinataire, il est délivré

Page 152: Systèmes distribués

152

Problèmes

• Défaillance de l ’émetteur avant d ’avoir envoyé le message à tous les destinataires– nécessité de détecter pour les sites destinataires

la défaillance de l ’émetteur– conservation des messages diffusés– élimination des messages bien reçus par le

groupe destinataire– éviter qu’un destinataire ne reçoive deux fois le

même message

Page 153: Systèmes distribués

153

Protocole Schneider 86

• Site initiateur– envoyer le message m à tous les sites destinataires

• Site destinataire recevant msi m pas déjà reçu alors

• envoyer m à tous les autres sites destinataires • délivrer m localement

fsi• Atomicité garantie• Coût élevé en communication et espace mémoire• Nécessité d ’un mécanisme permettant à un site de savoir qu’un

message diffusé a bien été reçu par tous ses destinataires.

Page 154: Systèmes distribués

154

Protocole Chang et Maxemchuk 84

• Protocole de diffusion atomique avec émetteurs multiples et groupe destinataire unique

• Les sites opérationnels forment un anneau défini par une liste connue de tous les sites.

• Un des sites de l ’anneau, appelé site jeton possède le jeton.• Hypothèses de défaillance

– site fail stop

– service de communication de type datagramme

– détection des défaillances après R tentatives de transmission d ’un message

• Hypothèses sur le réseau– le réseau offre une primitive de type diffuser (tous les sites

reçoivent tous les messages)

Page 155: Systèmes distribués

155

Philosophie du protocole

• Système à acquittement positif– Le message est retransmis jusqu’à ce qu’un acquittement

soit reçu de la part de chaque destinataire.

Si N sites doivent recevoir un message, au moins N messages d’acquittement sont transmis.Aucune garantie sur l’ordre de réception des messages par les destinataires.

Page 156: Systèmes distribués

156

Système à acquittement négatif

• Le séquencement des messages est facile à assurer si on a un seul émetteur et plusieurs destinataires.

• Le site émetteur attribue un numéro de séquence aux messages et les messages sont délivrés à leurs destinataires dans l ’ordre des numéros de séquence.

• Les destinataires ne sont pas tenus d ’acquitter explicitement les messages reçus car la perte est détectée par les trous dans la séquence. Un message manquant est demandé à l ’émetteur.

Page 157: Systèmes distribués

157

Le protocole

• Le protocole de Chang et Maxemchuk tire profit des deux approches.

• Un système avec plusieurs émetteurs peut se comporter comme un système à un seul émetteur en transmettant tous les messages à un site chargé du séquencement (site jeton)

• Système à acquittement positif entre les émetteurs et le site jeton

• Système à acquittement négatif entre le site jeton et les sites destinataires

Site émetteur

Site jeton

Sites destinataires

Page 158: Systèmes distribués

158

Principe de fonctionnement

• Le site émetteur attribue au message diffusé un numéro unique (S,n) et envoie le message à ses destinataires.

• Le site jeton attribue une estampille e au message et transmet un message d ’acquittement au site émetteur.

• Les autres sites destinataires n’acquittent pas les messages et délivrent les messages diffusés dans l’ordre des estampilles (e).

• Le site jeton sert les requêtes de retransmission émises par les sites destinataires ayant détecté un trou dans la séquence de messages.

Page 159: Systèmes distribués

159

Problèmes de mise en œuvre

• Problèmes– conservation des messages pour une durée indéfinie– défaillance du site jeton

• Solution : les sites sont site jeton à tour de rôle.

• Transmission du jeton– à l ’occasion de l ’envoi d ’un message d ’acquittement– message spécifique contenant la valeur de la prochaine

estampille– un site accepte de devenir site jeton que s ’il a reçu tous les

messages estampillés

Page 160: Systèmes distribués

160

Diffusion fiable

• Tolérance aux fautes dans le protocole de Chang et Maxemchuk– Protocole à deux phases

• phase 1 : réception du message par tous les sites• phase 2 : remise du message à tous les destinataires

– La politique de retransmission des messages assure• Lorsque le jeton revient sur le site qui a acquitté m, m est

reçu par tous les sites– à partir de cet instant le message peut être délivré à ses

destinataires

• Lorsque le jeton a terminé son deuxième tour, le message a été délivré à ses destinataires. Les sites peuvent donc écarter toutes les informations concernant le message.

Page 161: Systèmes distribués

161

Défaillance ou insertion d ’un site

• Phase de reconfiguration– Reconstitution de l ’anneau– Election d ’un nouveau site jeton

• complexe car plusieurs sites peuvent simultanément initialiser la reconfiguration

Page 162: Systèmes distribués

162

Caractéristiques du protocole

• Influencées par la fréquence de transmission du jeton– Délai avant remise d ’un message et capacité de

stockage diminuent quand la fréquence de transmission du jeton augmente

– Le nombre de messages de contrôle diminue lorsqu’il a beaucoup de diffusion

– Cas limite où le jeton n ’est jamais transmis : protocole non tolérant aux fautes

– Le délai de transmission dépend de la taille de l ’anneau

Page 163: Systèmes distribués

163

Protocoles de diffusion fiable du système Isis

• Isis est mis en œuvre au dessus d ’Unix.

ABCAST GBCAST CBCAST

Gestion des vues

Communication inter-site

Protocole standard TCP/IP

Page 164: Systèmes distribués

164

Caractéristiques des protocoles de diffusion fiable d ’Isis

• ABCAST– diffusion atomique

– ordre total sur les messages diffusés (plusieurs émetteurs, groupes destinataires multiples)

• CBCAST– diffusion atomique

– ordonnancement des messages selon l ’ordre causal

• GBCAST– ordre total sur les messages diffusés quelque soit le type de

diffusion

– utilisé pour gérer dynamiquement les groupes de processus

Page 165: Systèmes distribués

165

Le protocole de communication inter-site

• Objectif– transfert des messages avec mécanisme d ’acquittement– détection et traitement des défaillances de sites

• Principe– Envoi périodique d’un message « j’existe » par tout site à

tous les autres– Si un site ne reçoit pas message « j ’existe » d ’un autre site

S au bout d ’un temps déterminé, il le considère en panne et initialise le protocole de changement de vue

• un site peut être détecté en panne alors qu ’il ne l ’est pas

– A chaque site est associé un numéro d ’incarnation incrémenté lors de chaque recouvrement après panne

• transmis avec chaque message, il permet d ’écarter les messages périmés

Page 166: Systèmes distribués

166

Le protocole de gestion des vues

• Permet à tous les sites d’avoir la même vision du système : les sites observent les pannes et les recouvrements de sites dans un même ordre

• Structure de données sur chaque site Si

– vue des sites = liste de couples (site,numéro d ’incarnation)• modifiée en cas de panne ou recouvrement : séquence des vues V0, V1, …

Vn

• Fonctionnement du protocole– chaque site conserve la séquence des vues– la vue est une séquence ordonnée par rapport aux sites– le premier site selon l’ordre est le gestionnaire des vues

• initialise le protocole de gestion des vues quand un changement est détecté

– si un site détecte que tous les sites qui le précèdent sont défaillants, il devient le gestionnaire des vues (GV).

Page 167: Systèmes distribués

167

Protocole de modification des vues

• Protocole de validation à deux phases– Gestionnaire des vues (GV)

• calcul d ’une extension de vue par GV en cas de détection de panne ou recouvrement, ajout de la vue V t+1 à la séquence

• GV n ’accepte plus les messages émis dans une incarnation n ’appartenant pas à Vt+1

• GV envoie une proposition d ’extension de la séquence de vue à tous les sites de Vt+1 (message de type proposition)

– Un site S reçoit un message proposition• S n ’accepte plus les messages émis dans une incarnation

n ’appartenant pas à Vt+1

• S envoie un acquittement positif s ’il n ’a pas reçu d ’autres requêtes d ’extension de vues et si la vue correspond bien aux changements déjà mémorisés dans les autres vues de la séquence sinon S envoie un acquittement négatif contenant les messages manquants.

Page 168: Systèmes distribués

168

Protocole de modification des vues

• Collecte des acquittements par GV– validation de la séquence des vues si tous les

acquittements sont positifs

– sinon, protocole repris au départ

• Protocole correct sous les hypothèses suivantes– non partitionnement du réseau

– tous les sites ne tombent pas en panne au même moment

– terminaison du protocole si la fréquence des défaillances n ’est pas trop élevée

Page 169: Systèmes distribués

169

Le protocole ABCAST

• Protocole de diffusion atomique avec ordre total sur l ’ensemble des messages diffusés

• Groupes destinataires multiples

Page 170: Systèmes distribués

170

Principe du protocole

• Protocole en deux phases• Phase 1 : choix d’une estampille unique pour le message diffusé

– L ’émetteur attribue une estampille provisoire au message diffusé (date d ’émission, numéro du site émetteur)

– Chaque site destinataire propose à l ’émetteur une nouvelle estampille supérieure à toutes les estampilles des messages en attente et met le message en attente

• Phase 2 : Attribution de l’estampille finale et information des destinataires– L ’estampille définitive attribuée par l’émetteur est le

maximum des valeurs proposées par les destinataires– Elle est envoyée à tous les destinataires qui délivrent les

messages dans l’ordre des estampilles définitives

Page 171: Systèmes distribués

171

IllustrationEtape 1 : arrivée des messages

Site 1 Site 2

Site 3

14 15

16

m3 m1 m2

15,1 16,1 17,1

NL NL NL

m2 m1 m3

16,2 17,2 18,2

NL NL NL

m1 m3 m2

17,3 18,3 19,3

NL NL NL

Page 172: Systèmes distribués

172

Etape 2 : 17,3 = estampille finale de m1

Site 1 Site 2

Site 3

m2 m1 m3

16,2 17,3 18,2

NL L NL

m3 m2 m1

15,1 17,1 17,3

NL NL L

m1 m3 m2

17,3 18,3 19,3

L NL NL

Page 173: Systèmes distribués

173

Etape 3 : 19,3 = estampille finale de m2

Site 1 Site 2

Site 3

m3 m2

18,3 19,3

NL L

m1 m3 m2

17,3 18,2 19,3

L NL L

m3 m1 m2

15,1 17,3 19,3

NL L L

Page 174: Systèmes distribués

174

Etape 4 : 18,3 = estampille finale de m3

Site 1 Site 2

Site 3

m1 m3 m2

17,3 18,3 19,3

L L L

m3 m2

18,3 19,3

L L

m3 m2

18,3 19,3

L L

Page 175: Systèmes distribués

175

Traitement des défaillances

• Défaillance d ’un site destinataire– le site est ignoré, la diffusion se termine normalement pour les

autres sites valides

• Défaillance de l ’émetteur– élection d ’un remplaçant parmi les destinataires qui assure la

terminaison

• Remarque : le protocole ne fait pas la distinction entre les deux situations suivantes– un site destinataire délivre le message diffusé et tombe en panne

– un site destinataire tombe en panne avant de délivrer le message diffusé

• inacceptable pour la mise à jour de copies multiples

Page 176: Systèmes distribués

176

Commentaires

• Ordonnancement des messages centralisé sur le site émetteur

• Protocole se déroule en 2 phases donc délai de terminaison au moins égal au temps nécessaire pour 3 transferts de message

• Si le réseau offre une primitive de diffusion, elle peut être utilisée pour émettre le message et l’estampille définitive

Page 177: Systèmes distribués

177

Le protocole CBCAST

• Protocole de diffusion atomique avec ordonnancement causal

• Permet de délivrer un message dès sa réception

Page 178: Systèmes distribués

178

Idée de base

• Lorsqu’un message m est transmis, tous les messages envoyés avant m et connus sur le site émetteur sont transmis en même temps que m.

• Mise en œuvre

– chaque site Si gère un tampon de messages MSGi contenant dans l ’ordre tout message reçu ou envoyé par Si

– Envoi d’un message de Si à Sk

• insertion de m dans MSGi

• envoi de MSGi à Sk

– Réception de M sur Sk (actions exécutées pour tout m de M)

• si m MSGk, m est ignoré sinon m est inséré dans MSGk fsi

• si Sk est destinataire de m, m est délivré fsi

Page 179: Systèmes distribués

179

Bibliographie

• [Birrell et al 84] Implementing remote procedure calls, ACM Transactions on Computer systems, Vol 2, No1, Février 1984.

• [CHANG 84] Reliable Broadcast Protocols, Chang et Maxemchuk, ACM TOCS vol. 2, no 3, août 84, pp:251-273.

• [Birman 87] Reliable Communication in the Presence of Failures, Birman et Joseph, ACM TOCS vol. 5, no 1, février 87, pp:47-76.

Page 180: Systèmes distribués

Chapitre 4

Gestion de la mémoire

Page 181: Systèmes distribués

181

Problématique

• Partage de mémoire à l’échelle d’un réseau local de stations de travail (ou d’une grappe)– Mémoire partagée distribuée

• illusion d’une mémoire partagée au dessus de modules mémoire physiquement distribués

• modèle de programmation simple pour les applications parallèles

• Exploitation de la ressource mémoire de la grappe– Pagination en mémoire distante– Caches coopératifs pour les systèmes de fichiers

• disparité croissante entre la vitesse des processeurs et celle des disques

• exploitation de la mémoire disponible des nœuds

Page 182: Systèmes distribués

182

Plan

• Rappel sur les mécanismes de gestion de la mémoire virtuelle

• Pagination en mémoire distante • Mémoire partagée distribuée (DSM)

Page 183: Systèmes distribués

183

Rappel sur les mécanismes de gestion de la mémoire virtuelle

Espace virtuel [1]

Espace physique [2]

[5] cadre de

page

Table des pages [3]

[4] Page 1

Page 2

Page n

[6] L/E

Page 184: Systèmes distribués

184

Pagination

Page 1

Page 2

Page n

Invalide

Disque de pagination

Espace virtuelMémoire physique

Page 185: Systèmes distribués

185

Algorithme de remplacement

• Choix d’une page à remplacer pour libérer un cadre de page lorsque la mémoire est saturée

• Page modifiée recopiée sur le disque de pagination

• Politique de choix de la page– FIFO– LRU– …

Page 186: Systèmes distribués

186

Pagination en mémoire distante

• Idée– Tirer profit de la mémoire disponible des nœuds et

de la faible latence du réseau haut débit pour réaliser un mécanisme de pagination efficace

– Paginer en mémoire distante plutôt que sur le disque local

– Global Memory Service (GMS) [H. Levy, Washington, 95]

– Remote Paging [Marcatos, Forth (Grèce), 99]

Page 187: Systèmes distribués

187

Comparaison des performances d’un disque dur et d’un réseau

• Pour un accès aléatoire à une page mémoire

Latence (µs)

Débit de crête (Mo/s)

Accès aléatoire à une page de 4 Ko (ms)

Disque 10 000 12 11

Ethernet 100

10 12 1

Myrinet 4 160 0.2

Page 188: Systèmes distribués

188

GMS

• Gestion globale de la mémoire– Injection d’une page d’un nœud quelconque vers

un nœud quelconque– Pages de données d’un processus, pages de

données du SGF– Politique de remplacement globale– Traitement de l’ajout et du retrait de nœuds

Page 189: Systèmes distribués

189

Principe de fonctionnement

Mémoire locale

Mémoire globale

accès mémoire locale < accès mémoire globale < accès disque

Pages référencéeslocalement

Pages stockées localementà la demande d ’un nœud distant

Page 190: Systèmes distribués

190

Algorithme de remplacement

• Pages privées ou partagées– Exemple de page partagée : page d’un fichier

partagé entre plusieurs processus

• Mémoire globale ne contient que des pages privées et propres– Pas de problème en cas de défaillance d’un site

distant

Page 191: Systèmes distribués

191

Algorithme de remplacement

• Traitement d’un défaut de page du site P• Cas 1

– Page en défaut dans la mémoire globale du site Q• Échange de la page en défaut avec une page

quelconque de la mémoire globale de P• Page en défaut devient locale sur P

– Proportion de pages locales et globales inchangée sur Q

Page 192: Systèmes distribués

192

Algorithme de remplacement

• Cas 2– La page en défaut se trouve dans la mémoire

globale de Q mais P ne dispose que de pages locales

• Échange de la page locale la plus ancienne de P avec la page en défaut de la mémoire globale de Q

– La proportion des pages locales et globales n’est pas modifiée sur P et Q

Page 193: Systèmes distribués

193

Algorithme de remplacement

• Cas 3– La page en défaut se trouve sur un disque

• Elle est chargée dans la mémoire locale de P.• GMS choisit la page la plus ancienne de la grappe (sur

le nœud Q) pour l’éliminer de la mémoire (après recopie sur disque si besoin)

• Une page de la mémoire globale de P est envoyée sur Q– Si P n’a pas de page globale, sa plus ancienne page locale

est sélectionnée pour être envoyée sur Q.

Page 194: Systèmes distribués

194

Algorithme de remplacement

• Cas 4– La page en défaut est une page partagée située

en mémoire locale de Q.• Duplication de la page dans la mémoire locale de P• La page la plus ancienne de la grappe (sur le nœud R)

est évincée (après recopie si nécessaire). Une page de la mémoire globale de P est déplacée vers la mémoire globale de R.

– Si P n’a pas de page globale, sa plus ancienne page locale est envoyée.

Page 195: Systèmes distribués

195

Propriétés

• Gestion dynamique des mémoires locales et globales

• Si un nœud est très actif et consomme beaucoup de mémoire, sa mémoire locale se remplit et il envoie des pages sur des nœuds distants.

• Les nœuds inactifs hébergeant des pages anciennes évincent ces pages pour stocker des pages globales pour le compte de nœuds distants.

Page 196: Systèmes distribués

196

Gestion d’un algorithme LRU à l’échelle de la grappe

• Problème – Identifier la page la plus ancienne sans maintenir un état

global complet du système.

• Gestion d’informations approximatives sur l’état des pages globales

• Notion d’époque– Une époque a une durée maximale T.– Au plus M remplacements de page dans la grappe au cours

d’une époque.– Les valeurs T et M varient d’une époque à l’autre en fonction

de la charge de calcul et de l’état de la mémoire globale.

Page 197: Systèmes distribués

197

Algorithme LRU global

• Début d’une nouvelle époque– Quand l’époque courante a atteint sa durée

maximale T.– Quand M pages globales ont été remplacées.– Quand des imprécisions importantes ont été

détectées.

• Informations conservées sur chaque nœud– Âge des pages locales et globales hébergées sur

le nœud– Envoi d’un résumé de cette information au début

de chaque époque à un nœud initiateur.

Page 198: Systèmes distribués

198

Algorithme LRU global

• Initiateur– Reçoit les informations des nœuds– Calcule un âge minimum de remplacement MinAge

permettant de remplacer M pages pendant la prochaine époque

– Calcule un poids wi associé à chaque nœud i (nombre de pages libres ou anciennes (âge supérieur à MinAge) dont il dispose proportionnellement aux autres nœuds

• Plus un nœud dispose de pages libres, plus son poids est élevé

– Envoie la liste des poids wi et MinAge à tous les nœuds– Le nœud de poids le plus élevé est désigné comme

initiateur pour la prochaine époque

Page 199: Systèmes distribués

199

Algorithme LRU global

• Déroulement d’une époque– Eviction d’une page par nœud P

• Vérifie si l’âge de la page est supérieur à MinAge– Si oui, destruction de la page– Si non, envoi de la page au nœud i choisi avec une probabilité

proportionnelle à wi– La page la plus ancienne de i est détruite et la page évincée par P

devient globale sur i

• Approximation du LRU– Si M pages détruites globalement, ce sont les M plus

anciennes de la grappe– Quand le nœud initiateur a reçu wi pages, il déclare la fin de

l’époque en cours

Page 200: Systèmes distribués

200

Eléments de mise en œuvre

• GMS mis en œuvre dans OSF 1• Système de gestion de mémoire virtuelle et

cache de fichiers unifié contenant les pages des fichiers projetés en mémoire virtuelle et les pages des fichiers accédés par l’interface standard

• Noyau modifié pour détourner les fonctions d’ajout et de retrait de pages dans le cache de fichiers et les fonctions de remplacement du système de mémoire virtuelle

Page 201: Systèmes distribués

201

Eléments de mise en œuvre

• Toutes les pages gérées par GMS sont associées à un fichier sur disque

• Pages identifiées de manière unique par un uid– Adresse IP du nœud hébergeant le fichier associé – Numéro de la partition contenant le fichier – I-nœud du fichier– Offset dans le fichier

• Etat possible d’une page– Présente et privée en mémoire locale– Présente et partagée en mémoire locale sur plusieurs

nœuds– Présente en mémoire globale– Non présente en mémoire

Page 202: Systèmes distribués

202

Eléments de mise en œuvre

• Localisation d’une page dans la grappe– Gestionnaire de cadre de pages sur chaque nœud

• Liste des pages locales et globales présentes dans la mémoire physique locale

– Gestionnaire de cache global• Structure de données distribuée à travers le réseau

– Localisation du nœud hébergeant une page donnée

Page 203: Systèmes distribués

203

Mémoire partagée distribuée

• Exécution d’application parallèle sur un système distribué

• Mise en œuvre du modèle de programmation par mémoire partagée sur une architecture à mémoire distribuée

• Première mémoire partagée distribuée logicielle– Ivy, mémoire virtuelle partagée [Kai Li, 1986]

Page 204: Systèmes distribués

204

Vision du programmeur

• Une DSM est un espace d’adressage linéaire accessible par tous les processus formant une application parallèle

• Données identifiées par des adresses• Deux primitives

– Lire (load)– Écrire (store)

• Un programme conçu pour un multiprocesseur à mémoire partagée n’est pas modifié sauf dans sa phase d’initialisation

Page 205: Systèmes distribués

205

Mémoire partagée distribuéeProcessus 0

Processus 1

Processeur 0

Processeur 1

Écriture 0x4000

Lecture 0x4000

0x4000

Espace virtuel

[1]

[2]

[3]

[4]

[5]

Page 206: Systèmes distribués

206

Mémoire partagée distribuée

• Les données de l’utilisateur placées en DSM sont dupliquées dans la mémoire des nœuds sur lesquels s’exécutent les processus de l’application en fonction des accès réalisés– Accès concurrent aux données– Exploitation du parallélisme

• Avantages– Exploitation de la localité spatiale et temporelle

• La mémoire des nœuds se comporte comme un cache dans un multiprocesseur à mémoire partagée

– Application insensible au placement initial des données en mémoire

Page 207: Systèmes distribués

207

Fonctionnement d’une DSM : l’exemple de Ivy

• DSM– Logiciel distribué constitué de plusieurs processus

s’exécutant simultanément sur différents nœuds– Communications explicites entre ces processus

pour donner l’illusion aux processus de l’application que la mémoire est partagée

– Duplication des données dans les mémoires locales des nœuds qui sont vues comme des caches de l’espace virtuellement partagé

Page 208: Systèmes distribués

208

Conception d’une DSM

• Comment et sous quelles conditions déplacer les données de l’utilisateur ?– Quel modèle mémoire ?– Quel protocole de cohérence ? (gestion des copies multiples

des données)

• Comment connaître l’état du système distribué et y retrouver des données ?– Stocker des états internes dans un répertoire distribué

• Comment détecter et contrôler les accès des processus utilisateur aux données partagées ?– Comment gérer les espaces d’adressage ?

Page 209: Systèmes distribués

209

Modèle mémoire et protocole de cohérence

• Modèle mémoire : contrat entre l’utilisateur et la DSM– Précise le comportement de la DSM lors des

accès mémoire de l’application

• Exemple : modèle mémoire à cohérence séquentielle [Lamport 79] (Ivy)– Toute écriture dans l’espace partagé est

immédiatement visible par les autres nœuds et toute lecture renvoie la dernière valeur écrite

– Sur un même nœud, les lectures et écritures sont effectuées dans l’ordre du programme

Page 210: Systèmes distribués

210

Cohérence séquentielle : exemple

•P1 : Ex(1)

• P2 : Ey(2)

• P3 : Ly(2) Lx(0) Lx(1)

• ordre séquentiel des opérations des processeurs :

–Ey(2) Ly(2) Lx(0) Ex(1) Lx(1)

Page 211: Systèmes distribués

211

Protocole de cohérence

• Modèle mémoire mis en œuvre au sein de la DSM par un protocole de cohérence

• Protocole de cohérence– Décrit les opérations à mettre en œuvre pour

répondre à des événements comme les accès mémoire

– Yvy• Espace d’adressage partagé divisé en page• Protocole de cohérence gère individuellement chaque

page

Page 212: Systèmes distribués

212

Protocole de cohérence (Ivy)

• Etat global d’une page (dans le système distribué)– Lecture par un ou plusieurs nœuds– Lecture et écriture par un seul et unique nœud

• Garantie de la cohérence séquentielle– Accès en écriture bloque accès en lecture par les

autres nœuds– Lors d’un nouvel accès à la page, ces autres

nœuds doivent obtenir une copie de la dernière version de la page

• Vision immédiate des opérations d’écriture récentes

Page 213: Systèmes distribués

213

Protocole de cohérence (Ivy)

• Etat local de la page sur un nœud donné– Invalide

• Pas d’accès, état lors de l’initialisation du système

– Lecture-seule• Accès en lecture, état global = lecture

• État sur les autres nœuds : lecture-seule ou invalide

– Lecture-écriture• Accès en lecture et écriture, état global = lecture et écriture

• Etat sur les autres nœuds = invalide

• Changements d’état provoqués par les accès aux données partagées sur les différents nœuds

Page 214: Systèmes distribués

214

Etat des espaces d’adressage

Etat nœud 1 Etat nœud 2 Etat nœud nEtat dans

l’espace partagé

Lecture

Lecture et écriture

Lecture-seuleLecture-seule

Invalide Invalide

Invalide

Lecture-écriture

Page 215: Systèmes distribués

215

Diagramme des transitions (Ivy)

Événement local

Lecture

Écriture

Écriture

événement distant

Lecture-seule

Invalide Lecture-écriture

écriture Lecture

écriture

Invalide ou lecture-seule

Invalide ou lecture-seule

ou lecture-écriture Invalide

Page 216: Systèmes distribués

216

Invalidation

• Passage de l’état lecture à l’état lecture et écriture entraîne une phase d’invalidation– Suppression de toutes les copies de la page dans

le système distribué pour donner un droit d’accès en lecture-écriture au futur écrivain

Page 217: Systèmes distribués

217

Etats internes et répertoires

• Gestionnaires de la DSM doivent stocker des états internes– Information permettant de localiser les données– Information permettant de déterminer les actions à

accomplir lors d’un événement

• Ivy– Stockage de l’état global de la page– Quand état global = lecture, stockage du copyset

(liste des nœuds ayant une copie de la page, utile pour réaliser la phase d’invalidation)

– Informations stockées dans le répertoire

Page 218: Systèmes distribués

218

Gestion du répertoire

• Gestionnaires– Le gestionnaire d’une page sait sur quel nœud sont stockées

les informations du répertoire relatives à cette page– Le gestionnaire d’une page est contacté lors de chaque

accès au répertoire

• Propriétaires– Le propriétaire d’une page stocke l’entrée de répertoire

associée à cette page et fournit les informations du répertoire sur demande du gestionnaire

• Plusieurs configurations du répertoire– Selon que le propriétaire est statique ou dynamique– Selon que le gestionnaire est centralisé ou distribué

Page 219: Systèmes distribués

219

Algorithme du gestionnaire centralisé

• Gestionnaire centralisé– Un nœud reçoit toutes les demandes pour une

page donnée• Gestionnaire unique pour toutes les pages• Gestionnaire statiquement distribué

– Gestionnaire connaît le propriétaire– Propriétaire conserve les informations internes– Propriétaire dynamique

• Le dernier nœud ayant fait une écriture sur la page est le propriétaire

Page 220: Systèmes distribués

220

Cas d’une écriture

Demandeur Propriétaire

GestionnaireDemande d’écriture Demande d’écriture

Migration du propriétaire

Modification

des nœuds distants

Mise à jour du propriétaire

[1] [2]

[3][4]

[5]

[6]

Page 221: Systèmes distribués

221

Gestionnaire distribué dynamique

• Le gestionnaire est fusionné avec le propriétaire• Pour envoyer des requêtes au gestionnaire, tous les

nœuds possèdent le nom d’un propriétaire probable– Propagation de la requête de propriétaire probable en

propriétaire probable jusqu’au propriétaire effectif

• Mise à jour de l’information propriétaire probable– Lorsqu’un nœud reçoit une demande d’accès, il positionne

le propriétaire probable au nœud demandeur– Lorsqu’un nœud reçoit une réponse à une demande

d’accès, il positionne le gestionnaire probable sur lui-même

• Lorsque la demande est parvenue au propriétaire effectif, elle est traitée de la même façon que dans l’algorithme du gestionnaire centralisé

Page 222: Systèmes distribués

222

Fonctionnement du gestionnaire dynamique (cas d’une écriture)

Demandeur Gestionnaire/Propriétaire

Propriétaires probablesDemande d’écriture

Demande d’écriture

Migration du propriétaire

Modification

des nœuds distants

[1]

[3]

[4][2]

[8][5]

Mise à jour du

propriétaire probable

[6][7]

Page 223: Systèmes distribués

223

Gestion des espaces d’adressage

• Détecter et contrôler les accès aux données partagées– Ivy utilise le mécanisme de pagination

• Espace d’adressage partagé créé dans l’espace virtuel de chaque processus

• DSM manipule la table des pages des processus– État initial des pages de la DSM : aucun droit d’accès

• Défaut de page– Pris en charge par un gestionnaire d’exception spécifique pour la

plage d’adresses de la DSM qui active le protocole de cohérence– Ré-exécution de l’instruction fautive

• Un gestionnaire sur chaque nœud qui reçoit les demandes des autres nœuds et modifie en conséquence la table des pages

Page 224: Systèmes distribués

224

Problèmes soulevés par Ivy

• Granularité de gestion de la cohérence– Faux partage

• Ping-pong

• Double faute– Lecture suivie d’une écriture

• Pas d’anticipation des accès de l’application– préchargement

• Influence du réseau d’interconnexion sur les performances

Page 225: Systèmes distribués

225

Faux partageDonnées distinctes

dans la même page

P0 P1

Page

Ping-pong

Page 226: Systèmes distribués

226

Autres modèles de cohérence

• Cohérence faible (Weak Consistency [Dubois et al 86])

• Cohérence relâchée (Release Consistency [Gharacharloo et al 90])– Ces modèles distinguent les accès aux variables

de synchronisation– Ils permettent de masquer les temps de latence

des accès mémoire

Page 227: Systèmes distribués

227

Bibliographie

• [Archibald et al 86] Cache Coherence Protocols : Evaluation using a Multiprocessor simulation model, ACM Transactions on Computer Systems, Vol 4, No 4, novembre 1986.

• [Li et al 89] Memory Coherence in Shared virtual memory, ACM Transactions on Computer systems, Vol. 7, No4, novembre 1989.

• [Feeley et al 95] Implementing global memory management in a workstation cluster, Proc. Of the 15th ACM symposium on Operating Systems Principles, pp 201-212, décembre 1995.

Page 228: Systèmes distribués

Chapitre 5

Gestion des disques

Page 229: Systèmes distribués

229

Rappel sur les systèmes de gestion de fichiers

• Un service de gestion de fichiers (SGF) propose à l’utilisateur une interface d’accès simple et rapide aux unités de stockage secondaire (disque, bande, …) grâce à l’abstraction de fichier.– Fichier = suite linéaire d’octets stockés sur disque

• Rôle d’un SGF– Interface d’accès (open, read, write, seek, close)– Gestion de l’espace de stockage (blocs libres,

implantation des fichiers sur disque)

Page 230: Systèmes distribués

230

Interface d’accès

• Désignation• Protection• Accès logique

Page 231: Systèmes distribués

231

Désignation

• L’utilisateur donne des noms symboliques aux fichiers– /user/cmorin/enseignement/DEA-beyrouth/cours.ppt

• Le SGF utilise un nom interne pour localiser le fichier sur le disque– I-nœud sous Unix

• Traduction des noms symboliques en noms internes– Espace de désignation hiérarchique

• Arborescence de répertoires

– Répertoire • Fichier spécial géré par le SGF• Fichier contenant des couples (nom symbolique, i-nœud)

– Le nom absolu du fichier constitue le chemin d’accès au fichier• Répertoire racine

Page 232: Systèmes distribués

232

Protection

• Spécification par l’utilisateur de droits d’accès aux fichiers– Lecture, écriture, exécution – Définition de catégories d’utilisateurs (propriétaire,

groupe, autres sous Unix)

• Stockage des attributs de protection dans l’i-nœud du fichier

Page 233: Systèmes distribués

233

Accès logique

• Utilisateur voit un fichier comme un tableau infini d’octets– Consultation, modification d’un nombre quelconque d’octets

à partir de n’importe quel indice– Changement de taille dynamique

• Information de gestion des accès logique– Taille – Position courante (pointeur de fichier)

• Fonctions de l’interface– Ouverture, fermeture, lecture, écriture, déplacement

Page 234: Systèmes distribués

234

Gestion du stockage

• Disque– Pile de plateaux rotatifs

• Cylindre = ensemble de pistes• Piste divisée en secteurs• Un bras unique et multiples têtes

• Accès à une information sur disque– Cylindre, tête, secteur de départ, nombre de

secteurs contigus, type d’opération (lire, écrire)– SGF masque ces paramètres physiques

• Manipulation de blocs disques (unité d’accès élémentaire)

Page 235: Systèmes distribués

235

Gestion du stockage

• Fichier découpé en blocs logiques • Blocs logiques placés dans des blocs disque

alloués dynamiquement– Pas forcément consécutifs

• Deux types d’information sur disque– Information de contrôle (i- nœud sous Unix)

• Description du fichier

– Données du fichier

Page 236: Systèmes distribués

236

Organisation des données (Unix)

• i-nœud (descripteur de fichier)– type (ordinaire, catalogue, spécial)– nom et groupe du propriétaire du fichier– informations de protection– information de localisation physique : table d’implantation

• nbblocs < 10 : accès direct

• nbblocs >10 : 1 niveau d’indirection

• nbblocs >138 : 2 niveaux d’indirection

• nbblocs >16522 : 3 niveaux d’indirection

– taille du fichier (en octets)– dates de création, de dernière modification, de dernier accès

Page 237: Systèmes distribués

237

Table d’implantation

T[12]T[11]T[10]

T[0]à

T[9]Accès direct

Blocssur

disque

Tables de 128 entrées

Remarque : temps d’accès non

uniforme

Page 238: Systèmes distribués

238

Accès aux fichiers

Disque

Mémoire

Blocs

I-noeud

I-noeudR

X

Table des fichiers ouverts

Table des i-nœuds actifs

Nom local

Processus 1

Processus 2

Page 239: Systèmes distribués

239

Amélioration des performances

• Disque– Latence élevée (quelques millisecondes)– Faible débit (quelques mégaoctets par seconde)

• Optimisations– Cache disque

• Maintien en mémoire vive des blocs de fichiers les plus fréquemment accédés (localité temporelle)

– Accès en quelques micro-secondes– Disque moins sollicité

– Pré-chargement• Chargement de données en mémoire vive avant qu’un accès ne

soit demandé par un processus (localité spatiale)

– Cache à écriture retardée• Regroupement des écritures à un même bloc disque• Perte de données en cas d’arrêt brutal du système

Page 240: Systèmes distribués

240

Gestion des caches

• Idée ancienne– cache pour pallier la lenteur des disques– buffer cache du système de fichiers

• Principe– conservation des blocs utilisés par les applications dans des

tampons en mémoire (localité temporelle)– premier accès : accès au disque– accès suivants servis par le cache

• Gain– amélioration des performances en lecture– amélioration des performances en écriture

• modifications conservées en cache

Page 241: Systèmes distribués

241

SGF et système distribué

• Système de gestion de fichiers distribué– Réseau de stations de travail– NFS, AFS

• Système de gestion de fichiers parallèle– Grappe– Galley, xFS, Vesta,

Page 242: Systèmes distribués

242

Système de gestion de fichiers distribué (SGFD)

• Système permettant un accès transparent via une interface unique et standard aux disques locaux d’un nœud et aux disques des nœuds distants

• Modèle client /serveur– Serveur

• Met en œuvre un service de gestion de fichiers pour les disques de son nœud d’exécution

– Client• Exécuté sur la machine des utilisateurs• Fait le lien entre l’application et les serveurs distants

Page 243: Systèmes distribués

243

Architecture d’un SGFD

Application

Cache client

Application

Cache client

Nœud client Nœud client

Cache serveur

Réseau

Fichier 1

Fichier 2

Nœud serveur

Page 244: Systèmes distribués

244

Caches de fichiers

• Dans un réseau– cache serveur

• Pour pallier la latence des accès aux disques

– caches clients • mémoire• disque local

– Pour limiter les accès au serveur

Page 245: Systèmes distribués

245

Problématique

• Désignation– Un seul espace des noms global au système

• Localisation– Localisation d’un fichier doit être possible à partir de son

nom symbolique

• Transparence– Transparence à la localisation et à la migration

• Cohérence– Plusieurs processus sur différents nœuds peuvent accéder

simultanément au même fichier• Sémantique de partage

– Cohérence des copies multiples d’un fichier dans les caches

Page 246: Systèmes distribués

246

Système de gestion de fichiers parallèle (SGFP)

• Motivation– Peu d’évolution des performances des disques

comparativement à l’évolution de la puissance des processeurs

• E/S freinent les calculs

– Capacité limitée des disques• Quelques giga-octets• Fichier de l’ordre du tera-octets utilisés par les applications

scientifiques

• SGFP– Augmentation de la bande passante et de la capacité des

disques tout en masquant la multiplicité et la distribution des disques

Page 247: Systèmes distribués

247

Définition d’un SGFP

• Service permettant de gérer l’accès en parallèle à des fichiers dont les données sont physiquement distribuées sur un ensemble de disques répartis dans un système distribué– Fragmentation des fichiers – Mise en œuvre logicielle d’un RAID

Page 248: Systèmes distribués

248

Architecture d’un SGFP

Cache serveur

Cache client

Application

Cache serveurCache client

Application

Cache serveur

Cache client

Application

Cache serveurCache client

Application

Fichier 1

Fichier 2

Page 249: Systèmes distribués

249

Problématique

• Distribution– Répartition des fragments pour réaliser un maximum

d’accès aux disques en parallèle quelle que soit la requête

• Localisation– Retrouver rapidement les fragments d’un fichier sans

encombrer inutilement le réseau

• Cohérence– Accès en parallèle aux données des fichiers par des

processus sur différents nœuds• Cohérence des données dupliquées

• Sémantique du pointeur de fichier

Page 250: Systèmes distribués

250

Plan

• Désignation (SGFD)• Sémantique de partage de fichiers• Caches coopératifs• Réplication de données• Etude de cas : NFS• Etude de cas : AFS• Problèmes spécifiques aux SGFP

– Stockage– Interface d’accès

Page 251: Systèmes distribués

251

Désignation symbolique

• Trois types de structure de l’espace des noms dans les systèmes répartis– interconnexion des arbres de désignation de

chaque site par une super-racine (catalogue réseau contenant la racine de chaque site)

• une syntaxe particulière indique qu’un nom est global sinon il s’agit d’un nom contextuel interprété par rapport à la racine locale du site

• préservation de l’usage des noms locaux antérieurs• Exemple : Unix United (Newcastle Connection)

– compatibilité avec le système de désignation Unix

• Pas de transparence à la localisation et à la migration

Page 252: Systèmes distribués

252

Exemple de super racine (Unix United)

/../

mimosa maya paravec

usr christine usr eric

bin prog fich ...

...

...

cp prog /../maya/eric Copie du fichier prog sur le site maya

Page 253: Systèmes distribués

253

Désignation symbolique

– interconnexion à la demande des espaces des noms de chaque site en établissant des références (montage logique)

• analogue du montage dans le système Unix• on crée un lien entre une entrée dans un catalogue et

une arborescence sur une machine distante.• Structure potentiellement complexe qui n’est pas une

arborescence si des règles simplificatrices ne sont pas utilisées

– exemple : monter partout le catalogue complet d ’une machine sous le nom symbolique attribué à cette machine, même environnement sur toutes les machines

• Exemple : NFS• Transparence à la localisation mais pas à la migration

Page 254: Systèmes distribués

254

Montage logique

Dir1

usr

Partagé

usr

local

Dir1

usr

local

S1: U : U :

(avant) (après)

Page 255: Systèmes distribués

255

Exemple : NFS

Machine mimosa Machine maya Machine paravec

/ / /

usr mimosa maya mimosa maya paravec paravec

bin christine eric

prog fich

Page 256: Systèmes distribués

256

Exemple : le système Andrew

Espace des noms sur une station

bin lib tmp

Fichiers locaux

Vice (Vast Integrated Computing Environment)

Fichiers partagés

Espace de nomscommun

Lien symbolique

/

Page 257: Systèmes distribués

257

Désignation symbolique

• Espace des noms géré par un service externe au SGFD– un serveur de nom central qui peut être mis en œuvre de

façon répartie gère les noms des entités du système– noms globaux (uid)– Exemple : système de gestion de fichiers Locus

• Localisation à partir de l’UID– localisation du serveur à partir de l’UID– encodage de l’UID du serveur dans l’UID du fichier– correspondance entre UID du serveur et son adresse mise

en cache – Exemples : Chorus, Amoeba

Page 258: Systèmes distribués

258

Localisation

• Super-racine– Trivial, le nom du fichier contient son

emplacement

• Montage logique– Mécanisme de localisation invoqué lors de la

traversée du répertoire monté– Utilisation d’une table de montage

• Point de montage, nom du répertoire monté, nom du serveur de fichier hébergeant le répertoire monté

Page 259: Systèmes distribués

259

Sémantique de partage

• Spécifie la sémantique de partage lorsque plusieurs utilisateurs accèdent simultanément au même fichier.

• Sémantique unix : le résultat de chaque écriture est immédiatement propagée aux fichiers ouverts et une lecture retourne la dernière valeur du fichier.

• Sémantique de session : écritures sont effectuées sur une copie de travail et le résultat est rendu permanent à l’issue de la session. Encapsulée dans des opérations ouvrir et fermer (sémantique des sessions propre à chaque application) – maj non propagées aux sessions déjà ouvertes

• Sémantique de fichiers immuables : fichiers en lecture seulement – 2 opérations seulement : créer et lire un fichier

Page 260: Systèmes distribués

260

Sémantique de partage

• Sémantique de transaction (atomique) : entre le début et la fin d’une transaction, toutes les opérations d’accès à un fichier sont atomiques et le résultat de l’exécution de transactions concurrentes est équivalent à l’exécution séquentielle (dans un ordre non défini de ces transactions)

Page 261: Systèmes distribués

261

Impact sur la gestion de la cohérence des caches

• Cache inactif en écriture– Les données d’un fichier ouvert en écriture ne sont pas

placées en cache• Pas de problème de cohérence• Sérialisation des accès en lecture et écriture sur le serveur (pb de

performance)• Exemple : Sprite

• Vérification sur accès– Chaque bloc possède une copie maître sur le serveur

maintenue à jour en permanence• Répercution immédiate des écriture en cache sur le serveur

– Chaque accès en lecture à un bloc du cache local entraîne une vérification auprès du serveur

• Vérification périodique pour limiter la consommation de bande passante (perte de cohérence)

Page 262: Systèmes distribués

262

Impact sur la gestion de la cohérence des caches

• Copie unique– Un bloc de fichier possède un seul emplacement dans

l’ensemble des caches clients (PAFS)• Une seule copie en cache d’un bloc donc pas de problème de

cohérence

• Jeton– Similaire aux mécanismes de gestion de la cohérence

séquentielle dans les DSM• N accès en lecture, 1 seul accès en écriture autorisé• Avant de modifier un fichier, un nœud doit obtenir le jeton• Si un autre nœud demande le jeton, invalidation du cache local

avant de transmettre le jeton

– AFS, Coda : granularité fichier– xFS : granularité bloc

Page 263: Systèmes distribués

263

Caches coopératifs

• Certains nœuds ont un cache vide alors que d ’autres nœuds n’ont pas assez de place dans leur cache

• Quand un nœud a besoin d’un bloc, le bloc se trouve souvent dans le cache d’un autre nœud

• Caches coopératifs– Définition : service pour assurer le partage et la coordination

des blocs présents dans les caches de fichiers d’un ensemble de nœuds

– évitent des accès disque => amélioration performances– augmentation de la vitesse réseau => efficacité de la

coopération entre les nœuds

Page 264: Systèmes distribués

264

Différentes stratégies de caches coopératifs

• Cache coopératif privé– Mémoire des nœuds distants considérée comme une

extension du cache local– Un nœud actif évince les blocs de son cache dans la

mémoire d’un nœud distant inactif• Le nœud actif a accès aux blocs de son cache local et dans

son cache privé distant• Lorsque le nœud inactif redevient actif, il vide de sa mémoire

les blocs du cache coopératif

– Inconvénients• un nœud actif ne bénéficie pas des blocs situés dans les

caches locaux des nœuds distants• Un nœud ne peut pas utiliser les blocs injectés par un autre

nœud dans sa mémoire locale

Page 265: Systèmes distribués

265

Cache coopératif glouton

• L’ensemble des caches locaux des nœuds est géré comme un seul gros cache.– Chaque nœud place les blocs dans son cache local sans

coordination avec les autres nœuds.– Sur un défaut de cache du nœud P

• Envoi d’une requête au serveur de fichier

• Si le serveur de fichier possède le bloc dans son cache, il l’envoie au nœud P

• Sinon, le serveur de fichiers consulte un répertoire indiquant le contenu des caches clients

– Si un client possède le bloc demandé, la requête lui est transmise– Sinon lecture du bloc sur le disque, envoi du bloc à P et

mémorisation du fait que P possède une copie du bloc.

Page 266: Systèmes distribués

266

Cache coopératif glouton

• Inconvénients– Serveur = goulot d’étranglement– Duplication des blocs dans différents caches

(gaspillage de la ressource mémoire)

Page 267: Systèmes distribués

267

Cache coopératif statique

• Gestion globale des caches locaux sous forme d’un cache associatif par ensemble – Il y a autant d’ensemble que de nœuds– Chaque ensemble est de la taille du cache local d’un nœud

• Placement/recherche d’un bloc en cache– Détermination de l’ensemble dans lequel le bloc doit se

trouver par une fonction de hachage– Les blocs ne sont pas répliqués dans le cache global

• Intérêts– une seule copie

• pas besoin de cohérence– augmentation des performances des écritures

• tous les blocs dans le cache sont différents– meilleure efficacité du cache (pas de gaspillage de mémoire)

Page 268: Systèmes distribués

268

Cache coopératif statique

• Intérêts (suite)– amélioration de la localité quand cela ne coûte rien

• remplacement d’un bloc (appartenant aux 5% blocs LRU) dans le cache du nœud chargeant un nouveau bloc au lieu du bloc LRU dans le cache global

• Inconvénients– Chaque accès à un bloc donné nécessite de contacter le

nœud hébergeant le bloc• Augmentation du trafic réseau• Mauvaise exploitation de la localité spatiale et temporelle

• PAFS (Toni Cortès, Université polytechnique de Catalogne)

Page 269: Systèmes distribués

269

Cache coopératif centralisé

• Intermédiaire entre le cache coopératif glouton et le cache coopératif privé

• Le cache de chaque client est divisé en 2 parties– Cache local géré par le nœud– Cache global utilisé comme extension du cache disque du serveur

• Sur défaut dans le cache local d’un nœud P– Envoi d’une requête au serveur– Si bloc présent dans le cache local du serveur, il est retourné à P– Sinon, vérification de la présence du bloc dans l’extension du

cache du serveur sur les nœuds distants– Si un nœud distant héberge le bloc, la requête lui est transmise – Sinon, donnée lue sur le disque, transmise à P et placée dans le

cache local du serveur

Page 270: Systèmes distribués

270

Cache coopératif centralisé

• En cas de saturation du cache local du serveur– Le bloc le plus ancien (selon LRU) est injecté dans

le cache global sur un nœud distant

• Avantages– Taux de succès dans le cache global élevé– Taille restreinte des caches locaux diminue le taux

de succès local– Charge importante du serveur pour la coordination

centralisée du cache

Page 271: Systèmes distribués

271

Cache coopératif distribué

• Variante du mécanisme de coopération gloutonne– Singleton = bloc présent dans le cache d’un seul

client à travers la grappe– Limitation du nombre de copies d’un bloc– Eviction des singletons évitée ou retardée

• Mis en œuvre dans le système XFS

Page 272: Systèmes distribués

272

Exemple XFS

• 3 objectifs– contenu des caches clients accessibles par tous les nœuds– singletons conservés en cache le plus longtemps possible– un bloc est caché dans un nœud qui a une forte probabilité

de le référencer (localité physique privilégiée)

• Cache d’un nœud divisé en 2 parties– cache local : blocs accédés par des processus locaux– cache global : blocs conservés pour le compte de processus

distants

Page 273: Systèmes distribués

273

Exemple XFS

• Algorithme de remplacement– Entrée d ’un bloc dans le cache local

• élimination du cache local du bloc LRU ayant des copies distantes

• s ’il n ’y a que des singletons, le bloc LRU est envoyé à distance dans un nœud choisi arbitrairement

– si le nœud distant n’a pas de place, il remplace un bloc ayant des copies multiples

– s ’il ne peut pas, élimination du bloc reçu

– Elimination des blocs inutiles• quand un bloc a été transmis plus de N fois sans être

utilisé, il est éliminé• N= 0 : cache coopératif glouton

Page 274: Systèmes distribués

274

Exemple XFS

• Requête d ’accès à un bloc distant– bloc copié dans le cache local du nœud

demandeur– réplication pour augmenter la localité physique

Page 275: Systèmes distribués

275

XFS

• Inconvénients de l ’approche XFS– mécanisme de cohérence complexe– réplication => sous-utilisation du cache qui se

comporte comme un cache plus petit– gain de performance obtenu grâce à la localité

physique contrebalancé par les messages échangés

Page 276: Systèmes distribués

276

Disponibilité

• Réplication – équilibrage de charge– disponibilité – efficacité : technique classique de distribution

• Transparence de la réplication : les clients ne sont pas au fait de cette réplication et ne voient qu’une unique copie

• Service de fichiers assure la gestion des copies– atomicité de l’opération globale de mise à jour de l’ensemble

des copies– modèle transactionnel (englober toutes les mises à jour au

sein d’une transaction) peut être trop fort • cohérence relâchée• tolérance aux fautes

Page 277: Systèmes distribués

277

Lecture / écriture

• Options pour les opérations de lecture– Read-one-primary : lecture sur une copie primaire– Read-one : lecture sur une copie quelconque – Read-quorum: lecture à partir d’un quorum de

copies

• Options pour les opérations d’écriture– Write-one-primary : écriture sur une copie primaire

qui propage les mises à jour (ou invalide)– Write-all : mis à jour atomique de toutes les copies– Write-quorum: mise à jour appliquée à un quorum

de copies

Page 278: Systèmes distribués

278

Cohérence d ’exemplaires multiples d ’un fichier

• Copie maîtresse– toutes les copies peuvent être consultées– seule la copie maîtresse peut être modifiée

• modifications répercutées sur les autres copies• ne garantit pas que toute lecture rend la dernière valeur

écrite• défaillance de la copie maîtresse empêche la

modification du fichier mais il reste disponible en lecture

• Aucune garantie de cohérence– suffisant pour certaines applications– cohérence à la charge de l ’application

Page 279: Systèmes distribués

279

Duplication de la copie principale(One copy serializability)

• Read-one-primary / write-one primary– pas de réelle distribution

• Read-one / write-one-primary• Read-one / write all

Sérialisation assurée sur la copie sur laquelle est effectuée la mise à jour

Cohérence forte

Protocole de mise à jour atomique nécessaire

Page 280: Systèmes distribués

280

Votes majoritaires (1)

• Exemple écriture suivie d’une lecture

• Ecriture suivie d’une écriture

Ecriture

44

Lecture

4 4

4

Ecriture

Ecriture

Page 281: Systèmes distribués

281

Votes majoritaires (2) : numéros de versions

• Exemple écriture suivie d’une lecture

• Ecriture suivie d’une écriture

44

4 4

44

4

45

4 5

55

4Ecriture

45

4 5

55

4

Lecture

44

4 4

44

4

45

4 5

55

4Ecriture

65

6

55

6

Ecriture

6

Page 282: Systèmes distribués

282

Votes majoritaires (3)

• Notations– R(d) : quorum de lecture– W(d) : quorum d’écriture– N(d) : nombre de copies

• Lecture/écriture – R(d) +W(d) > N(d)

• Ecriture/écriture– 2*W(d) > N(d)

• Remarque R(d) = 1, W(d) = N : read-one/write-all

Page 283: Systèmes distribués

283

Exemple : NFS

Application Client Protocole Protocole Serveur SGF centralisé

RPC

•Permettre aux utilisateurs d ’avoir une visibilité potentielle sur tous

les fichiers du système réparti et de travailler sur tout fichier local ou distant•Spécification de NFS distingue deux services

• service de montage• permet de rendre visible les arborescences locales sur n ’importe quelle

machine distante

•Protocole de montage

•service d ’accès à distance• accès aux fichiers à distance

•Protocole NFS

•Mise en œuvre

• modèle client/serveur

Page 284: Systèmes distribués

284

Protocole de montage

• Etablissement d ’une connexion logique initiale entre un client et un serveur– rend accessible un répertoire d ’un serveur de façon transparente

à une machine cliente– serveur de montage conserve une liste d ’exportation qui indique

les répertoires locaux exportés et les machines autorisées à les monter

– requête de montage envoyée au serveur de montage situé sur la machine serveur concernée

– le serveur de montage renvoie au client un descripteur du répertoire monté (identificateur du SGF et du fichier dans ce SGF)

– les utilisateurs de la machine cliente peuvent accéder les fichiers du répertoire de façon transparente

Page 285: Systèmes distribués

285

Protocole NFS

• Recherche d ’un fichier dans un répertoire• Lecture d ’un ensemble d ’entrées de

répertoire• Manipulation des liens, des répertoires et des

fichiers • Accès aux attributs des fichiers• Lecture, écriture des fichiers

Page 286: Systèmes distribués

286

Protocole NFS

• Protocole sans état– transmission de toutes les informations

nécessaires à l’opération effectuée dans la requête• augmentation de la taille des requêtes et de leur temps de

traitement

• les opérations susceptibles de générer un état (ouverture, fermeture) sont gérées par le client

– défaillance d’une machine client n’a aucune répercussion sur le service

– la défaillance du serveur entraîne l ’indisponibilité des fichiers locaux

» restauration de la cohérence du disque à la reprise mais pas de synchronisation avec les clients

Page 287: Systèmes distribués

287

Mise en œuvre de NFS

Appels système

Interface VFS/Vnode

SGF local Client NFS

RPC/XDR

Interface VFS/Vnode

Serveur NFS SGF local

RPC/XDR

Client Serveur

Page 288: Systèmes distribués

288

Le système Andrew File System (AFS)

• Développé à Carnegie Mellon– Grand nombre de sites et d’utilisateurs

• stations de travail d’un campus (réseau pour l ’éducation), étudiants

• accès uniforme aux ressources du réseau

• Structure– Réseaux locaux «Ethernet greffé sur une « colonne vertébrale »– Chaque réseau local comporte un serveur

• serveurs communiquent à travers la colonne vertébrale• Vice : ensemble des serveurs• serveurs ne font pas confiance aux clients (Stations Virtue)

des réseaux locaux

Page 289: Systèmes distribués

289

Accès aux fichiers

• Disque local – stockage des fichiers temporaires– cache des fichiers distants

• Accès aux fichiers distants– tout fichier est recopié en une fois dans le cache

• faible trafic réseau

– fichier distant accédé comme un fichier local (après transfert)

– mise à jour du fichier à la fermeture

Page 290: Systèmes distribués

290

Partage de fichier en écriture

• Utilisation d’un serveur à état– le serveur propriétaire d’un fichier mémorise la

liste de l’ensemble des clients ayant une copie du fichier

– le serveur peut invalider une copie de fichier dans un cache (callback)

• avant une opération de modification• à la fermeture du fichier par un client

Page 291: Systèmes distribués

291

Problèmes spécifiques aux SGFP

• Stockage des données sur disque• Interface d’accès

Page 292: Systèmes distribués

292

Fragmentation des données sur plusieurs disques

• Dans le but d’utiliser les disques des différents nœuds pour augmenter le débit des accès disques

• Déjà fait par matériel dans les disques RAID (Redundant Arrays of Inexpensive Disks)– plusieurs disques connectés à un seul contrôleur

pour obtenir un débit supérieur au débit d’un seul disque

Page 293: Systèmes distribués

293

RAID

• Pourquoi la haute performance ?– Obtention de données sur chaque disque en même temps

• augmentation de la bande passante disque

– Opération « seek » effectuée en parallèle sur chaque disque• diminution du temps nécessaire à cette opération

– éléments mécaniques des disques ralentissent les opérations usuelles

» déplacement de la tête de lecture» rotation du disque

– Dans certains RAID, traitement de plusieurs requêtes en parallèle

Page 294: Systèmes distribués

294

Entrelacement des données sur disque

• Grain fin– unité de données de petite taille

• tous les disques sont accédés en parallèle pour chaque requête

– avantage• débit de transfert

– inconvénients• 1 seule requête logique à la fois• disques perdent du temps à positionner la tête de lecture

Page 295: Systèmes distribués

295

Entrelacement des données sur disque

• Gros grain– unités de données de grande taille

• accès à quelques disques pour les requêtes de petite taille

• accès à tous les disques pour les requêtes de grande taille

– avantages• plusieurs requêtes de petite taille servies en parallèle• haut débit pour les requêtes de grande taille• parallélisme des opérations de « seek » quand plusieurs

requêtes de petite taille sont traitées en parallèle

Page 296: Systèmes distribués

296

RAID et tolérance aux fautes

• Plusieurs disques– probabilité de défaillance d’un disque élevée

• Redondance de données et mécanismes de tolérance aux fautes– ne pas perdre d ’information si un disque est

défaillant

• 5 niveaux de RAID– selon l ’organisation des données sur les disques– (RAID-0 : pas de redondance)

Page 297: Systèmes distribués

297

RAID-0

• Fragmentation mais pas de redondance

Page 298: Systèmes distribués

298

RAID-1

• Disques miroirs (unité de fragmentation = bloc)

•Écriture d ’une donnée sur 2 disques•Lecture sur un disque•Solution coûteuse en espace disque

Page 299: Systèmes distribués

299

RAID -2

Unité de fragmentation = bitParité = code de Hamming (ECC mémoire)

Disques de données Disques de parité

Gain en espace disque par rapport à RAID-1

Page 300: Systèmes distribués

300

RAID-3

Unité de fragmentation = bit1 disque de parité (ou exclusif)

•Lecture de tous les disques de données•Ecriture => accès au disque de parité•Inconvénient : une seule requête de lecture à la fois

Page 301: Systèmes distribués

301

RAID-4

Unité de fragmentation = bloc1 disque de parité

•Plusieurs requêtes de lecture en parallèle•Accès en écriture séquentiels à cause des accès au disque de parité

Page 302: Systèmes distribués

302

RAID-5

Unité de fragmentation = blocPas de spécialisation des disques

Avantage par rapport à RAID-4 : suppression du goulot d ’étranglement du disque de parité en répartissant les blocs de parité sur différents disques

Schéma qui offre les meilleures performances sauf pour les petites écritures

Page 303: Systèmes distribués

303

Traitement des petites écritures

• Approche lecture-modification-écriture

XOR1

2

Page 304: Systèmes distribués

304

Traitement des petites écritures

XOR

• Approche régénération - écriture

1

2

Page 305: Systèmes distribués

305

RAID logique

• Même idée que RAID matériel mais disques ne sont pas connectés au même contrôleur

• Système de fichiers est responsable de la distribution des données et de la gestion de la redondance

• Mêmes problèmes et mêmes avantages que RAID matériels mais solutions différentes– système distribué

Page 306: Systèmes distribués

306

Distribution des données

• d = nombre de disques disponibles

• Distribution étendue– fichier découpé en d fragments– Chaque fragment sur un disque différent

• Distribution cyclique– fichier découpé en fragments de taille fixe– placement des fragments cycliquement sur différents

disques• fragment n sur disque n modulo d

Page 307: Systèmes distribués

307

Groupes de fragmentation

• Grand nombre de disques dans une grappe– difficile de réaliser des écritures sur tous les disques donc

beaucoup de petites écritures (inefficaces en RAID-5)– parité ne permet pas de tolérer la défaillance de plus d’un

disque

• Un nœud qui réalise une lecture n’a pas forcément le débit réseau nécessaire pour lire tous les disques en parallèle– performance en pratique = fraction de la performance

théorique

• Solution : fragmentation des fichiers sur un sous-ensemble des disques

Page 308: Systèmes distribués

308

Groupes de fragmentation

• Avantages– Plusieurs clients peuvent accéder en parallèle à

des groupes différents– Plusieurs disques peuvent être défaillants en

même temps s ’ils appartiennent à un groupe différent

• Inconvénient (mineur)– besoin de plus d ’espace de stockage car 1 disque

de parité par groupe

Page 309: Systèmes distribués

309

Interface

• Interface traditionnelle– open (fichier)

• un pointeur de fichier par open

– close (fichier)– read (fichier, &tampon, taille)– write (fichier, &tampon, taille)– seek ()

• Limitations– pas de pointeur partagé entre plusieurs processus

(impossible de créer un processus fils sur un noeud distant)– plusieurs opérations pour lire des portions non contiguës

d’un fichier (gestion de l’atomicité par le programmeur)

Page 310: Systèmes distribués

310

Besoins

• Application indique comment les données seront utilisées– permet au système de placer les données pour

profiter du parallélisme potentiel du matériel– algorithme de remplacement

• Coordination des opérations d ’E/S dans les applications parallèles– données partagées

Page 311: Systèmes distribués

311

Pointeur de fichier partagé

• Pointeur global partagé– Plusieurs processus partagent le même pointeur

de fichier• nouvelle position du pointeur observée par tous les

processus après des opérations read, write, seek• difficile à mettre en œuvre efficacement dans un

système distribué

Page 312: Systèmes distribués

312

Pointeur de fichier partagé

• Approche pour des accès en tourniquet (round robin)– Les processus se donnent le tour pour les accès

au fichier– Facile à mettre en œuvre

• l ’état du pointeur doit seulement être transmis au processus suivant

• seul le processus ayant le pointeur peut faire des requêtes d ’E/S

Page 313: Systèmes distribués

313

Pointeur de fichier partagé

• Idée – pointeur distribué partagé pour éviter que deux processus

accèdent à un même portion du fichier

• Le système de fichier attribue un disque à chaque processus en tourniquet

• Quand un disque D est attribué à un processus P– P lit/écrit tous les blocs du fichier F situés sur le disque D– changement de disque selon un algorithme de tourniquet– même comportement pour P avec le nouveau disque

• Terminaison– quand tous les disques sur lesquels se trouvent des blocs

du fichier F ont été attribués à un processus

Page 314: Systèmes distribués

314

Exemples

• MPI-IO– Ouverture du fichier par plusieurs processus

– un pointeur local par processus– un pointeur partagé

– Utilisation du pointeur local• MPI_FILE_READ

• MPI_FILE_WRITE

– Utilisation du pointeur partagé• MPI_FILE_READ_SHARED

• MPI_FILE_WRITE_SHARED

• SPIFFI– plusieurs types de pointeur partagé au choix de l ’application

Page 315: Systèmes distribués

315

Méthodes d ’accès

• Galley

– (1) Accès par pas

– (2) Accès par pas imbriqué

– (3) Accès défini par une liste d ’accès de type 1 ou 2

Page 316: Systèmes distribués

316

Méthodes d ’accès

• Accès par pas simple

Lecture de n segments de m octets espacés de p octets

n = 3m = 2Kop = 5Ko

Page 317: Systèmes distribués

317

Méthodes d ’accès

• Accès par pas imbriqué

Struct gfs_stride vec[2]// pas internevec[0].f_stride = 2048 ; // p = 2Kovec[0].m_stride = 1024 ; // m= 1Kovec[0].quantity = 3 ; // n = 3// pas externevec[1].f_stride = 7168 ; // p = 7Kovec[1].m_stride = 3 * 1024 ; // quantité de données lues au 2eme niveauvec[1].quantity = 3 ; // n = 3 fois

// opération par pas imbriquéb = gfs_read_nested (file_id, buffer, file_offset, size_to_read, vec, 2)

...

1er niveau

2eme niveau

Page 318: Systèmes distribués

318

Bibliographie

• [Leach et al 1983] The Architecture of an Integrated Local Network, IEEE Journal on selected areas in communications, Vol 1, No 5, Novembre 1983.

• [Satyanarayanan 1989] A survey of distributed file systems Rapport technique No CMU CS 89-116 Carnegie mellon University, février 1989.

• [Svobodova 198] File servers for network Based Distributed Systems, ACM Computing surveys, Vol 16 No 4, Décembre 1984.

• [Howard et al] Scale and Performance in a Distributed File System, ACM Transactions on Computer Systems, Vol 6, No 1, Février 1988.

• [Satyanarayanan et al 1990] Coda : a highly available file system for a distributed workstation environment, IEEE Transactions on Computer, Vol 39, N4, Avril 1990.

• [Sandberg 1985] Design and implementation of the Sun network file system, Summer Unisenix Conference Proc. Juin 1985.