Principes des systèmes d'exploitationPrincipes des ...nlt/cours/master/os/os2.pdf · Page 2 Page 3...

51
Page 1 Page 1 Principes des systèmes d'exploitation Support de transparents Partie 2: Systèmes distribués IUP MIAGE Faculté de sciences -UNSA N. Le Thanh février 1995 Page 2 Plan du cours II- Partie 2 : Systèmes distribués II.1- Introduction objectifs concepts matériels concepts logiciels bases de la conception des systèmes distribués II.2- Communication dans les systèmes distribués couches de protocoles modèle client-serveur appels de procédures à distance communication de groupe Quelques approches pratiques

Transcript of Principes des systèmes d'exploitationPrincipes des ...nlt/cours/master/os/os2.pdf · Page 2 Page 3...

Page 1

Page 1

Principes des systèmes d'exploitationPrincipes des systèmes d'exploitation

Support de transparentsPartie 2: Systèmes distribués

IUP MIAGEFaculté de sciences -UNSA

N. Le Thanhfévrier 1995

Page 2

Plan du coursPlan du coursII- Partie 2 : Systèmes distribuésII.1- Introduction

– objectifs– concepts matériels– concepts logiciels– bases de la conception des systèmes distribués

II.2- Communication dans les systèmes distribués– couches de protocoles– modèle client-serveur– appels de procédures à distance– communication de groupe– Quelques approches pratiques

Page 2

Page 3

Plan du coursPlan du coursII.3- Synchronisation dans les systèmes distribués

– synchronisation d'horloge– exclusion-mutuelle Algorithmes d'élection– transactions atomiques– interblocage dans les systèmes distribués

II.4- Etude de cas (TD/TP)– Service web et programmation Client/serveur sur web– Modèle CORBA et systèmes à objets distribués– Modèles client/serveur et à objets de Java : rmi, jdbc, servlet, applet

Page 4

II- Partie II : systèmes distribuésII.1- Introduction

II- Partie II : systèmes distribuésII.1- Introduction

II.1.1- Objectifs Avantages/Inconvénients

SYSTÈME DISTRIBUÉ = SYSTÈME POSSÈDANT PLUSIEURS PROCESSEURS COOPÉRANTS

OBJECTIFS

- Coût : plusieurs processeurs à bas prix- Puissance de calcul : aucune machine centralisée peut réaliser - Performance : calcul parallèle- Adaptation : à des classes d'applications réelles naturellement distribuées- Fiabilité : résistance aux pannes logicielles ou matérielles- Extensibilité : croissance progressive selon le besoin

Avantages Inconvénients

- partage de données- partage de périphériques- communication- souplesse (politiques de placements)

- logiciels : peu de logiciels disponibles- réseaux : la saturation et délais- sécurité : piratage

Page 3

Page 5

II- Partie II : systèmes distribuésII.1- Introduction

II- Partie II : systèmes distribuésII.1- Introduction

II.1.2- Concepts matériels

Taxonomie de Flynn (1972)- nombre des flux d'instructions- nombre des flux de données

SISD : un seul flux d'instruction et un seul flux de données (ordinateurs centralisé)

SIMD : un seul flux d'instruction et multiples flux de données (machines // vectorielles)

MISD : multiples flux d'instruction et un seul flux de données (pas de machine réelle)

MIMD : multiples flux d'instruction et multiples flux de données

MIMD

systèmes // et dist.Fortement couplés Faiblement couplés

multiprocesseurs(mémoire partagée)

multicalculateurs(mémoire privée)

Bus Commutateur Bus Commutateur

Sequent Encore Ultracomputer RP3 Stations sur LAN Hypercube/Transputeur

Page 6

II- Partie II : systèmes distribuésII.1- Introduction

II- Partie II : systèmes distribuésII.1- Introduction

II.1.2- Concepts matérielsII.1.2.1- Multiprocesseurs à bus

UCCache

UCCache

UCCache

Mémoire

Problèmes

- saturation du bus- cohérence du partagede la mémoire

Solutionajout des mémoires cachesqui stockent des mots récemment lits ou écrits

Problèmes

- cohérence entre lescaches et la mémoire

Solution- cache écriture immédiate(write-through cache)- cache espion(snoopy cache)

(<64 processeurs)

Page 4

Page 7

II- Partie II : systèmes distribuésII.1- Introduction

II- Partie II : systèmes distribuésII.1- Introduction

II.1.2- Concepts matérielsII.1.2.2- Multiprocesseurs commutés

C

C

C

C

M M M MMémoires

UC

Technique de matrice de commutation(Crossbar Switch)

- les UC et mémoires sont reliées par une matricede commutation- à chaque l'intersection, le noeud de commutation(crosspoint switch) peut-être ouvert ou fermé- quand une UC veut accéder à un module de mémoireelle ferme temporairement le noeud de commutationcorresondant- si plusieurs UC veulent accéder au même module,une file d'attente est nécessaire

Inconvénient le nombre des noeuds de commutation nécessaires : il faut n2 de noeuds de commutation pour rélier n UC aux n module de mémoire

réseaux d'interconnexion minimisant le nombre de noeuds ?

Page 8

II- Partie II : systèmes distribuésII.1- Introduction

II- Partie II : systèmes distribuésII.1- Introduction

II.1.2- Concepts matérielsII.1.2.2- Multiprocesseurs commutés

C

C

C

C

M

M

M

M

Principe du réseau oméga (multiétage)- utilisation des commutateurs 2x2 : 2 entrées et deux sorties- chaque commutateur peut relier à n'importe quelle entrée et à n'importe quelle sortie- pour relier n UC à n mémoires, il nécessite n étages dontchacun contient log2n commutateurs 2x2- le nombre nécessaire de commutateurs est : nxlog2n

Inconvénient : Temps de propagation

- Si n= 1024, on a besoin 10 étages- Avec les UC de 50Mhz, le cycle de calcul est de 20ns- une requête mémoire traverse 20 étages (allé/retour) en 20 ns si le temps de commutation est de 1ns- On doit avoir 10 240 commutateurs à 1ns !!!

CONCLUSIONconstruire un gros multiprocesseursfortement couplé à mémoire partagée est difficile et coûteux

Page 5

Page 9

II- Partie II : systèmes distribuésII.1- Introduction

II- Partie II : systèmes distribuésII.1- Introduction

II.1.2- Concepts matérielsII.1.2.3- Multicalculateurs à bus

Mémoire locale

UC

Mémoire locale

UC

Mémoire locale

UC

Stationsde travail(ou UC)

réseau local(ou bus rapide)

- Facile à construire- Bas coût- Le trafic est moins important(pas d'échange UC-mémoire)- souvent utilisé dans lesréseaux locaux avec une vitessede 10 à 100Mbits/s

Remarque

Le bus rapide peut être construit par lesdifférentes techniques (exemple : réseaubynet de teradata BDC1024

(diffusion)

Page 10

II- Partie II : systèmes distribuésII.1- Introduction

II- Partie II : systèmes distribuésII.1- Introduction

II.1.2- Concepts matérielsII.1.2.4- Multicalculateurs commutés

Treillis

Hypercubes(4 dimensions)

- Un hypercube est un cube à n dimensions- 4 dimensions : 2 cubes de 3 dimensions avec lessommets homologues reliés- 5 dimensions : 2 hypercubes de 4 dimensions avecles sommets homologues reliés- la complexité du câblage croit en log2 du nombre UC- le chemin plus long croit en log2 du nombre UC

- câblage simple- le chemin plus long croit en racine carré du nombre d'UC

RemarqueUtilisation de crossbar et multiétage

16 384 UC1024 UC

Page 6

Page 11

II- Partie II : systèmes distribuésII.1- Introduction

II- Partie II : systèmes distribuésII.1- Introduction

II.1.3- Concepts logicielsII.1.3.1- Classification

Le matériel est important, mais le logiciel l'est plus encore

La classification est, par nature, imprécise et floue :

systèmes d'exploitation faiblement couplés systèmes d'exploitation fortement couplés

- réseaux des ordinateurs indépendants(et alors la coopération des ordinateurs indépendants sans réseau ?)

- multiprocesseurs exécutant un seul programme en // (jeu d'échecs par exemple)- machine des bases de données- machine // à processeurs symétriques ...

multiprocesseursSE faiblement couplé

multiprocesseursSE fortement couplé

multicalculateursSE faiblement couplé

multicalculateursSE fortement couplé

Systèmes d'exploitation réseaux

Systèmes d'exploitation distribués

Systèmes multiprocesseurs à temps partagé

Page 12

II- Partie II : systèmes distribuésII.1- Introduction

II- Partie II : systèmes distribuésII.1- Introduction

II.1.3- Concepts logicielsII.1.3.2- Systèmes d'exploitation réseaux et NFS

La combinaison la plus fréquente : matériels et logiciels faiblement coupés

Réseaux locaux

- postes avec SE indépendant- partage des imprimantes- accès à un autre poste en mode terminal

Connexion point-à-point système d'exploitation réseaux

Internet

- postes indépendants + serveurs de fichiers- système de fichiers partagés- gestion central des utilisateurs

Réseaux locaux Internet

- stations NT- windows workgroups

FTP, TELNET, ...

Novell, LanmanagerUnix, NTserver services

HTTP, NFS(Network File Manager)

posteclient

posteclient

posteclient

Serveurdefichiers

LAN

question

réponse

Page 7

Page 13

II- Partie II : systèmes distribuésII.1- Introduction

II- Partie II : systèmes distribuésII.1- Introduction

II.1.3- Concepts logicielsII.1.3.2- Systèmes d'exploitation réseaux et NFS

Architecture et protocoles NFSserveur1 serveur2

jeuxpacmanpacwomanpacchild

travailnewsmailautres

client1/ client2/jeuxjeuxtravail

pacmanpacwomanpacchild

pacmanpacwomanpacchildtravail

news mailautres

news mailautres

Lan ou Internet

Serveurs- exporter des répertoires (/etc/exports)- gérer les accès aux répertoires exportéspour les clients (locaux ou à distance)- protection des fichiers- transmettre les données aux clients (réponses)- les clients et les serveurs peuvent partager unmême système de fichiers

Clients- monter des répertoires exportés sur sa station- utiliser ces répertoires comme (ou presque) ceux locaux- plusieurs clients peuvent partager les mêmesrépertoires (fichiers partagés)- toute machine peut à la fois client et serveur- systèmes d'exploitation locaux peuvent être <>

Page 14

II- Partie II : systèmes distribuésII.1- Introduction

II- Partie II : systèmes distribuésII.1- Introduction

II.1.3- Concepts logicielsII.1.3.2- Systèmes d'exploitation réseaux et NFS

Architecture et protocoles NFSUn protocole est un ensemble de requêtes envoyées par les clients aux serveurs

auxquelles correspondent les réponses des serveurs aux clients

1er protocole : Protocole de montage1- Le client envoie une requête contenant le chemin d'accès à un répertoire du serveur etune demande de l'autorisation de le monter dans son arborescence.

2- Si le chemin est correct et le répertoire est exportable, le serveur revoie au client une cléde fichier (file handle) concernant ce répertoire. Cette clé comporte des champs qui identifient uniquement le type de Système de Fichiers, le disque, le n° de i-noeud du répertoire et lesinformations sur les protections.

3- Classiquement, le client a un fichier Shell script /etc/rc contenant les commandes de montage.Ce Shell script sera exécuté automatiquement au lancement du système

4- Automontage (Unix de Sun) : le montage se fait automatiquement à la 1ere ouverture d'un fichier à distance, le client contacte les serveurs et monter le répertoire contenant ce fichier

Page 8

Page 15

II- Partie II : systèmes distribuésII.1- Introduction

II- Partie II : systèmes distribuésII.1- Introduction

II.1.3- Concepts logicielsII.1.3.2- Systèmes d'exploitation réseaux et NFS

Architecture et protocoles NFS2ème protocole : Protocole d'accès

1- Le client envoie aux serveurs des requêtes de manipulation des répertoires ou des fichiers

2- La plupart des appels système UNIX sont supportés par NFS, à exception OPEN et CLOSE.L'omission de ces opérations permet aux serveurs de ne pas gérer les fichiers ouverts (serveur sans état (stateless). Chaque requête d'accès se suffit à elle-même. L'appel READ contientla clé du fichier, la position courante et le nombre d'octet à lire. On utilise LOOKUP à la place deOPEN. L'inconvénient principal est l'absence de contrôle de cohérence. On ne peut pas verrouillerle fichier (cas il est toujours à état fermé), donc le partage d'accès peut introduire des incohérences

3- Il existe sous UNIX système V, le mécanisme Remote File System (RFS) qui demande le fichiersoit ouvert avant la lecture. Le serveur doit gérer dans ce cas un descripteur de fichier pour toutfichier ouvert à distance

4- Chaque requête doit s'identifier par la cryptographie à clés publiques. Il possède une clé cryptée à envoyer au serveur . Le serveur stocke des couples (clé, valeur) dans NIS (Network Information Service). Quand on lui envoie une clé, il retourne une valeur.

Page 16

II- Partie II : systèmes distribuésII.1- Introduction

II- Partie II : systèmes distribuésII.1- Introduction

II.1.3- Concepts logicielsII.1.3.2- Systèmes d'exploitation réseaux et NFS

Implantation de NFS

disquelocal

message versserveur

client NFSSystème d'exploitation local

Couche appel système

couche système de fichiers virtuel

message versserveur

disquelocal

Système d'exploitation local

client NFS

couche système de fichiers virtuel

Réseau

Client Serveur

Page 9

Page 17

II- Partie II : systèmes distribuésII.1- Introduction

II- Partie II : systèmes distribuésII.1- Introduction

II.1.3- Concepts logicielsII.1.3.3- Systèmes distribués

Un système distribué est un système qui s'exécute sur un ensemble de machines sans mémoire partagée, mais que pourtant l'utilisateur voir comme une seule et unique machine

Caractéristiques

- possédant un mécanisme de communication interprocessus unique et global permettantla dialogue entre deux processus quelconques

- possédant un système de protection unique et global

- possédant un mécanisme de gestion de processus unique

- possédant un ensemble des appels système unique disponible sur toutes les machines

- possédant un noyau de système d'exploitation identique implanté sur toutes les machines

- possédant un mécanisme de gestion de mémoire identique

Page 18

II- Partie II : systèmes distribuésII.1- Introduction

II- Partie II : systèmes distribuésII.1- Introduction

II.1.3- Concepts logicielsII.1.3.4- Systèmes multiprocesseurs en temps partagé

E (prêt)D (prêt)C (en exécution)B (en exécution)A (en exécution)File d'exécution : D, ESystème d'exploitation

Disque local

Bus

Cache Cache Cache

UC1 UC2 UC3

Processus A en exéc.

Processus B en exéc.

Processus C en exéc.

Mémoire

- Un ensemble des processeurs "symétriques"- Une mémoire commune et un espace disque commun- Tous les programmes sont stockés dans la mémoire partagée- Une file d'attente unique des processus exécutable se trouvent dans la mémoire partagée- L'ordonnanceur travaille en section critique pour éviter que deux UC ne choisissent le même processus à exécuter- L'exclusion mutuelle peut être réalisée en moyennant des sémaphores, moniteurs, ...

Page 10

Page 19

II- Partie II : systèmes distribuésII.1- Introduction

II- Partie II : systèmes distribuésII.1- Introduction

II.1.3- Concepts logicielsII.1.3.5- Tableau de synthèse

Questions S.E.R. S.E.D. S.E.M.

Ressemble-t-il à un monoprecesseur virtuel ? Non Oui Oui

Doit-on avoir le même système d'exploitation ? Non Oui Oui

Combien y a-t-il de copies du système d'exploitation ? N N 1

Comment la communication a-elle assurée ?Fichierspartagés Messages Mémoire

partagée

Faut-il utiliser des protocoles réseau unifiés ? Oui Oui Non

Existe-il une seule file d'attente des exécutables ? Non Non Oui

Le partage des fichiers a-t-il une sémantique bien définie Non Oui Oui

Page 20

II- Partie II : systèmes distribuésII.1- Introduction

II- Partie II : systèmes distribuésII.1- Introduction

II.1.4- Critères d'un système distribuéII.1.4.1- Transparence

Même mode d'utilisation que celui d'un système centralisé en temps partagé : niveau d'utilisateuret niveau de programme

Types de transparence Signification

Transparence à l'emplacement L'utilisateur ne connaît pas où sont situées les ressources

Transparence à la migration Les ressources peuvent être déplacées sans modification de leur nom

Transparence à la duplication L'utilisateur ne connaît pas le nombre de copies existantes

Transparence à la concurrence Plusieurs utilisateurs peuvent partagées en même temps les mêmes ressources

Transparence au parallélisme Des tâches peuvent exécutées en parallèle sans que lesutilisateurs le sachent

Page 11

Page 21

II- Partie II : systèmes distribuésII.1- Introduction

II- Partie II : systèmes distribuésII.1- Introduction

II.1.4- Critères d'un système distribuéII.1.4.2- Souplesse

La facilité de modification de configuration et d'extension

Micronoyau

Utilisateur

Micronoyau

Serveur defichiers

Micronoyau

Serveur derépertoires

Micronoyau

Serveur deprocessus

Bus / réseaux locaux

Noyaumonolithique

Utilisateur

École Monolithique

- Unix en particulier

École Micrinoyau

- WindowsNT en particulier

Page 22

II- Partie II : systèmes distribuésII.1- Introduction

II- Partie II : systèmes distribuésII.1- Introduction

II.1.4- Critères d'un système distribuéII.1.4.3- Fiabilité

La disponibilité est la fraction de temps pendant laquelle le système est utilisable :

- limiter de nombre des composants critiques- dupliquer les parties clés des composants logiciels et matériels (redondance)- maintenir la cohérence des copies (contradiction!!!)

Disponibilité

Les ressources doivent être protégées contre des utilisations abusives et malveillantes. Enparticulier le problème de piratage des données sur le réseau de communication

Sécurité

Le système doit être conçu pour masquer les pannes aux utilisateurs. La panne de certains serveurs (ou leur réintégration dans le système après la réparation) ne doit pas perturber l'utilisation du système en terme de fonctionnalité (NFS sans état par exemple)

Tolérance aux pannes

Page 12

Page 23

II- Partie II : systèmes distribuésII.1- Introduction

II- Partie II : systèmes distribuésII.1- Introduction

II.1.4- Critères d'un système distribuéII.1.4.4- Performances

Critères- temps de réponse - débit (nombre de travaux par heure)- taux d'utilisation du système - pourcentage utilisé de la bande de passante du réseau

Problèmes

- La communication est en général assez lente dans les systèmes distribués - Le mécanisme de reprise sur panne consomme beaucoup de temps

Solutions

- minimiser les échanges de message - maximiser des granules grosses (gros grains) et éviter des grains fins pour les calcul à distance- réduire le champ d'application des mécanismes de reprises sur pannes

Page 24

II- Partie II : systèmes distribuésII.1- Introduction

II- Partie II : systèmes distribuésII.1- Introduction

II.1.4- Critères d'un système distribuéII.1.4.5- Dimensionnement

Goulots d'étranglement potentiels

Concepts Exemple

Composants centralisés Un seul serveur de courrier pour tous les utilisateurs

Tables centralisées Un seul annuaire en ligne

Algorithmes centralisés Avoir un routage qui nécessite une connaissance totale du réseau

- Caractéristique des algorithmes distribués :

- les algorithmes exécutables sur les postes clients ( Java)- aucune machine n'a une information complète sur l'état du système- les machines prennent des décisions à partir des seules informations locales disponibles- la panne d'une machine n'empêche pas l'algorithme de fonctionner- on ne fait pas l'hypothèse de l'existence d'une horloge globale

Page 13

Page 25

II- Partie II : systèmes distribuésII.1- Introduction

II- Partie II : systèmes distribuésII.1- Introduction

II.1.5- Exercices1) Donner deux avantages des systèmes distribués sur les systèmes centralisés2) Un multiprocesseur à bus utilise un cache espion pour gérer une mémoire

cohérente. Peut-on alors utiliser des sémaphores ?3) Un multicalculateur comprenant 256 UC est organisé en treillis de 16x16. Quel est,

dans le pire des cas, le délais de transmission d'un message (exprimer en nombre de passages d'un UC à la suivante) ?

4) Considérons maintenant un hypercube de 256 UC. Quel est alors le délais de transmission dans le pire de cas ?

5) Pourquoi certains serveurs NFS sont-ils conçu pour être sans état ?6) NFS permet à une machine d'être à la fois client et serveur. Est ce utile ? Pourquoi?7) Quelles sont les tâches essentielles d'un micronoyau ? Quels sont les avantages des

micronoyaux sur les noyaux monolithiques ?8) Un serveur de fichiers expérimental est opérationnel les 3/4 du temps et en

débogage le reste du temps. Combien de fois ce serveur doit-il être dupliqué pour que sa disponibilité soit au moins de 99% ?

Page 26

II- Partie II : systèmes distribuésII.2- Communications dans les systèmes distribués

II- Partie II : systèmes distribuésII.2- Communications dans les systèmes distribués

II.2.1- IntroductionProblème : communication inter-processus

- dans un système centralisé : communiquer par la mémoire partagée- dans un système distribué : en général, l'absence de la mémoire partagée, on doit communiquerpar messages avec des protocoles

Protocole- ensemble de règles qui gère les communication inter-processus dans un système distribué

- il détermine un l'accord sur la façon dont les communications doivent d'effectuer

Plan

- les protocoles de communication (modèle OSI)

- le modèle Client / Serveur

- les Appels de procédure à distance (RPC=Remote Procedure Call)

Page 14

Page 27

II- Partie II : systèmes distribuésII.2- Communications dans les systèmes distribués

II- Partie II : systèmes distribuésII.2- Communications dans les systèmes distribués

II.2.2- Rappels des protocoles OSIII.2.1.1- Introduction

O.S.I. = Open Systems Interconnection reference model

Système ouvert = un système qui prêt à communiquer avec un autre système ouverten utilisant des règles standards (protocoles) quant au formatau contenu et à la signification des messages qui sont envoyésou reçus

Objectif

Définition d'un ensemble de protocoles permettant un accord à tout niveau, depuis lesdétails de bas niveau de la transmission (voltage indiquant la valeur d'un bit, longueur du bit, ...) jusqu'à ceux de plus haut niveau de la présentation de données (longueur d'unnombre, d'une chaîne de caractères, format de représentation des données, ...)

Page 28

II- Partie II : systèmes distribuésII.2- Communications dans les systèmes distribués

II- Partie II : systèmes distribuésII.2- Communications dans les systèmes distribués

II.2.2- Rappels des protocoles OSIII.2.1.2- Modèle en couches OSI

Couche 7

Couche 6

Couche 5

Couche 4

Couche 3

Couche 2

Couche 1

Processus A

Application

Présentation

Session

Transport

Réseau

Liaison

Physique

Machine 1

Processus B

Application

Présentation

Session

Transport

Réseau

Liaison

Physique

Machine 2Deux types de protocoles

orientés connexion orientés sans connexion

Protocole d'application

Protocole de présentation

Protocole de session

Protocole de transport

Protocole de réseau

Protocole de liaison

Protocole physique

support de transmission

Interface

Interface

Interface

Interface

Interface

Interface

Page 15

Page 29

II- Partie II : systèmes distribuésII.2- Communications dans les systèmes distribués

II- Partie II : systèmes distribuésII.2- Communications dans les systèmes distribués

II.2.2- Rappels des protocoles OSIII.2.1.2- Modèle en couches OSI

Deux types de protocoles

orientés connexion orientés sans connexion

Message

Appendice ou"en-queue" deliaison de donnéesEntête d'application

Entête de présentationEntête de session

Entête de transportEntête de réseau

Entête de liaison de données

Message transite sur réseau

Page 30

II- Partie II : systèmes distribuésII.2- Communications dans les systèmes distribués

II- Partie II : systèmes distribuésII.2- Communications dans les systèmes distribués

II.2.2- Rappels des protocoles OSIII.2.1.2- Modèle en couches OSI

- Couche physique : assurer la transmission : connecteurs physique, codages physiquesadaptation au mode de transmission, ...

- Couche de liaison : assurer la transmission sans erreur entre deux extrémistes d'une liaison directe

- Couche réseau : assurer le routage des messages sur les réseaux d'interconnexion(gestion de congestion, choix de chemins, ...

- Couche transport : assurer une transmission fiable entre l'expéditeur et le destinatairecontrôle de perte des paquets, l'ordre des paquets, ...

- Couche de session : extension de la couche transport : mécanismes de synchronisationde reprise sur panes, ... très peu utilisée en pratique !!!

- Couche de présentation : format de données, adaptation au terminal

- Couche d'application: protocoles applicatifs : courrier électronique (X400), ftp, telnet,...

Page 16

Page 31

II- Partie II : systèmes distribuésII.2- Communications dans les systèmes distribués

II- Partie II : systèmes distribuésII.2- Communications dans les systèmes distribués

II.2.2- Modèle Client/ServeurII.2.2.1- Description

Client Serveur

Noyau Noyau

Demande

Réponse

7

6

543

2

1

Demande/Réponse

LiaisonPhysiqueRéseau de connexion

- Protocole simple sans connexion de type Question / Réponse

- Avantage : simplicité - efficacité

- Noyau : assurer l'envoi et réception des messages avec 2 primitives : - send (dest, &ptrm)- receive (adr, &prtm) (adr : l'adresse d'écoute du récepteur)

Page 32

II.2.2- Modèle Client/ServeurII.2.2.2- Adressage

Client Serveur1

2

1 : demande vers S.p12 : réponse vers C.p2

Client Serveur3

2

1 : recherche par diffusion2 : je suis là3 : demande4 : réponse

14

Client Serveur3

4

1 : demande à SN2 : réponse de SN3 : demande4 : réponse

SN1

2

Localisation connue Localisation inconnue Localisation centralisée

- tout client doit connaîtrela localisation et le nominterne de tous les services. Il demande doncexplicitement sous format :

machine.processus

- chaque processus choisitun nom aléatoire telle sortequ'il soit unique- client diffuse une demandede localisation d'un process- le serveur contenant ce processus donne sonadresse machine

- les serveurs ont leur nom unique en code ascii- un serveur gère la localisation etle nom interne des machines - le client connaît seulement l'adresse duserveur de nom. Il lui demande de fournir l'adresse des serveurs à l'exécution

II- Partie II : systèmes distribuésII.2- Communications dans les systèmes distribués

II- Partie II : systèmes distribuésII.2- Communications dans les systèmes distribués

Page 17

Page 33

II.2.2- Modèle Client/ServeurII.2.2.3- Primitives bloquantes et non bloquantes

II- Partie II : systèmes distribuésII.2- Communications dans les systèmes distribués

II- Partie II : systèmes distribuésII.2- Communications dans les systèmes distribués

client bloqué

le messageest envoyé

Client en cours d'exécution

Client en cours d'exécution

déroutement versle noyau, leprocessus clientest bloqué

retour, leprocessusclient estlibéré

client bloqué

le messageest copiéen mémoiretampon

Client en cours d'exécution

Client en cours d'exécution

déroutement versle noyau, leprocessus clientest bloqué

le messageest envoyé

retour, leprocessusclient estlibéré

- le processus appelant send ou receive sera bloquépendant l'émission (ou réception) du message

- l'instruction qui suit send (ou receive) sera exécutéelorsque le message a été complètement émis (ou reçu)

- avantage : simple et claire, facile à la mise en oeuvre- inconvénient : moins performant

- le processus appelant send sera libéré toutede suite, le message sera envoyé en // à l'exécution

- avantage : performant- inconvénient : perte de mémoire tampon,difficile à réaliser, risque de modif. du tampon

Page 34

II.2.2- Modèle Client/ServeurII.2.2.4- Primitives avec tampon ou sans tampon

II- Partie II : systèmes distribuésII.2- Communications dans les systèmes distribués

II- Partie II : systèmes distribuésII.2- Communications dans les systèmes distribués

AC S

Noyau Noyau

réseau

A

C S

Noyau

réseau

- sans tampon : le message envoyé par le clientsera copié par le noyau du serveur dans la zoneptrm et pour le processus A à l'adresse adr dans l'appel receive(adr,ptrm) déclenché par le processus A

- problème : si le processus client a appelé sendavant que le processus serveur appelle receivealors, le noyau du serveur n'a ni adresse du processus serveur ni l'adresse de l'endroit oùil doit copier le message reçu !!!

- avec tampon : les messages envoyés par lesclients sont déposés dans une boite aux lettres.Le processus serveur A qui appelle un receiveva déclencher une recherche par le noyau dansla boite aux lettres. Si le message existe, le noyauva le copier dans la zone de mémoire ptrm etlibérer le processus A. Sinon l'appel receive serabloqué pour l'attente de l'arrivée du message

- problème : quand la boite aux lettres est saturée,on doit refuser tous les messages qui arrivent !!!

Page 18

Page 35

II.2.2- Modèle Client/ServeurII.2.2.5- Primitives fiables et non fiables

II- Partie II : systèmes distribuésII.2- Communications dans les systèmes distribués

II- Partie II : systèmes distribuésII.2- Communications dans les systèmes distribués

C S

1

23

4 C S

1

3

2

Message avec accusés de réception individuels Message avec la réponse = 1 accusé de réception1- Demande (client au serveur)2- ACK (noyau à noyau)3- Réponse (serveur à client)4- ACK (noyau à noyau)

1- Demande (client au serveur)2- Réponse (serveur à client)3- ACK dans certain cas (noyau à noyau)(si le calcul est cher, on peut bloquerle résultat au serveur jusqu'à qu'il reçoitun ACK du client (3)

On peut avoir un compromis entre 2 solutions précédantes :

1- Demande (client au serveur)2- ACK éventuellement si la réponse n'est pas revenue dans certain temps (noyau à noyau)3- Réponse servant ACK si dans le lape de temps prévu (serveur à client)4- ACK éventuellement (noyau à noyau)

Page 36

II.2.2- Modèle Client/ServeurII.2.2.6- Résumé

II- Partie II : systèmes distribuésII.2- Communications dans les systèmes distribués

II- Partie II : systèmes distribuésII.2- Communications dans les systèmes distribués

Objet Option 1 Option 2 Option 3

Adressage numéro de la machine adresse choisie par le proc. nom ASCII avec SN

Blocage primitives bloquantes primitives non-bloquantes avec copie vers le noyau

primitives non-bloquantes avec interruption

Mémorisation pas de tampon tampon temporaire boite aux lettre

Fiabilité non fiable demande-ACK-réponse-ACK demande--réponse-ACK

Code source-dest. DescriptionType de paquetREQREPACKAYAIAATAAU

demanderéponse

accusé de réceptiones-tu vivant ?

Je suis vivantessaye à nouveau

adresse inconnue

client-serveurserveur-clientnoyau-noyauclient-serveurserveur-clientserveur-clientserveur-client

le client désire un serveurla réponse du serveur au clientle paquet précédent est arrivéle serveur fonctionne-t-il ?le serveur n'est pas en pannele serveur est saturéaucun processus sur serveur utilise cette adresse

Page 19

Page 37

II.2.2- Modèle Client/ServeurII.2.2.6- Résumé

II- Partie II : systèmes distribuésII.2- Communications dans les systèmes distribués

II- Partie II : systèmes distribuésII.2- Communications dans les systèmes distribués

REQ

REPClient Serveur

REQ

REPClient Serveur

ACK

ACK

REQREPClient Serveur

ACK

REQ

REPClient Serveur

ACK

ACK

AYAIAA

a) b)

c) d)

Exemples des échanges des paquets dans le protocole Client/Serveur

Page 38

II.2.3- Appels de procédures à distanceII.2.3.1- Introduction

II- Partie II : systèmes distribuésII.2- Communications dans les systèmes distribués

II- Partie II : systèmes distribuésII.2- Communications dans les systèmes distribués

Problème du modèle Client/ServeurConcept basé sur l'échange explicite de données donc orienté Entrées/Sorties qui ne peut pas être le principe clé d'un système distribué

Appels de procédures à distanceConcept introduit par Birrell et Nelson en 1984 : lorque un processus sur la machine A appelle une procédure sur une machine B, le processus sur A est suspendu pendant l'exécution dela procédure appelée se déroule sur B. Des informations peuvent être transmises de l'appelantvers l'appelé ou l'inverse par des paramètres

Page 20

Page 39

II.2.3- Appels de procédures à distanceII.2.3.2- Opération de base de RPC

Mécanisme d'appel de procédure dans un système centralisé

II- Partie II : systèmes distribuésII.2- Communications dans les systèmes distribués

II- Partie II : systèmes distribuésII.2- Communications dans les systèmes distribués

compte = read(idf, tampon, nboct);0

SP

Variables localesau prog. appelant

0SP

Variables localesau prog. appelant

nbocttampon

idf

adresse de retour

variables localesde read

0

SP

Variables localesau prog. appelant

- modes de passage : par valeur ou par pointeur- nature des paramètres : entré - sorti - entré / sorti

Page 40

II.2.3- Appels de procédures à distanceII.2.3.2- Opération de base de RPC

II- Partie II : systèmes distribuésII.2- Communications dans les systèmes distribués

II- Partie II : systèmes distribuésII.2- Communications dans les systèmes distribués

prog.appelant

prog.appelé

noyau noyau

Subrogé client Subrogé serveur

assemblageparamètre

désassemblageparamètre

désassemblageparamètre

assemblageparamètre

appel

retour

Appel

retour

Page 21

Page 41

II.2.3- Appels de procédures à distanceII.2.3.3- Passage de paramètres

II- Partie II : systèmes distribuésII.2- Communications dans les systèmes distribués

II- Partie II : systèmes distribuésII.2- Communications dans les systèmes distribués

noyau noyau

Subrogé client Subrogé serveur

.

.n=somme(4,7)

.

.

messagesomme

47

messagesomme

47

somme(i,j)int i,i;{return (i+j);}

Page 42

II.2.3- Appels de procédures à distanceII.2.3.4- Nommage dynamique (dynamic binding)

II- Partie II : systèmes distribuésII.2- Communications dans les systèmes distribués

II- Partie II : systèmes distribuésII.2- Communications dans les systèmes distribués

Problème

la localisation du serveur par le client : écrire dans le code client l'adresse du serveur ou utiliserle mécanisme de nommage dynamique

subrogé clientgestionnairede noms

subrogé serveur

1

2

3

4a

ba : enregistrer un nom (exportation de l'interface)b : supprimer un nom

1- recherche un nom (importation)2- retourne l'identificateur et descripteur3 et 4- RPC

Page 22

Page 43

II.2.3- Appels de procédures à distanceII.2.3.5- Sémantique de RPC en cas d ’échec

Cinq classes d ’erreurs

1. Le client est incapable de localiser le serveur

2. La demande du client au serveur est perdue

3. La réponse du serveur au client est perdue

4. Le serveur tombe en panne après avoir reçu une demande

5. Le client tombe en panne après avoir envoyé une demande

II- Partie II : systèmes distribuésII.2- Communications dans les systèmes distribués

II- Partie II : systèmes distribuésII.2- Communications dans les systèmes distribués

Page 44

II.2.4- Communication de groupe (multipoints)II.2.4.1- Introduction

II- Partie II : systèmes distribuésII.2- Communications dans les systèmes distribués

II- Partie II : systèmes distribuésII.2- Communications dans les systèmes distribués

E R

E

RR

R

R

R

R

R

R R

R

R

R

Généralisation du RPC

Un émetteur doit communiquer enparallèle à n récepteurs regoupésdans un groupe sémantique

Point-à-Point

Un-à-Plusieurs

Page 23

Page 45

II.2.4- Communication de groupe (multipoints)II.2.4.2- Classement

a) Groupes fermés et groupes ouverts

II- Partie II : systèmes distribuésII.2- Communications dans les systèmes distribués

II- Partie II : systèmes distribuésII.2- Communications dans les systèmes distribués

Communicationnon autorisée

Un groupe fermée n ’autorise que lescommunications

intra-groupe

Les étrangers peuventenvoyer de messagesau groupe ouvert

Page 46

II.2.4- Communication de groupe (multipoints)II.2.4.2- Classements

b) Groupes de paires ou groupes hiérarchisés

II- Partie II : systèmes distribuésII.2- Communications dans les systèmes distribués

II- Partie II : systèmes distribuésII.2- Communications dans les systèmes distribués

Groupe de paires Groupe hiérarchisé

Coordinateur

Travailleurs

Page 24

Page 47

II.2.4- Communication de groupe (multipoints)II.2.4.3- Gestion des groupes

II- Partie II : systèmes distribuésII.2- Communications dans les systèmes distribués

II- Partie II : systèmes distribuésII.2- Communications dans les systèmes distribués

- Création, dissolution d ’un groupe- Adhésion à un groupe ou retrait d ’un groupe

Gestion centralisée Gestion distribuée

- Un serveur de groupes qui gère unebase de données des groupes et unebase de données des membres

- Avantages : efficace, claire et facile à implanter

- Inconvénients : fragile devant les pannes

- Un groupe se crée s ’il y a au moinsun adhérant- pour adhérer à un groupe, le processus demandeur doit envoyersa demande à tous les membres dugroupe

- Avantage : Robustesse- Inconvénient : complexe et coûteuse

Page 48

II.2.4- Communication de groupe (multipoints)II.2.4.4- Adressage des groupes

II- Partie II : systèmes distribuésII.2- Communications dans les systèmes distribués

II- Partie II : systèmes distribuésII.2- Communications dans les systèmes distribués

0 1 2 3 4 0 1 2 3 4 0 1 2 3 4

Diffusion restreinte(multicasting)

Diffusion globale(broadcasting)

monodifusion(point-to-point)

Adressage par prédicat(predicate addressing)

+ + +

Page 25

Page 49

II.2.4- Communication de groupe (multipoints)II.2.4.5- Atomicité

II- Partie II : systèmes distribuésII.2- Communications dans les systèmes distribués

II- Partie II : systèmes distribuésII.2- Communications dans les systèmes distribués

Propriété de diffusion atomique (atomic broadcast)

Un message envoyé à un groupe doit être reçu par tous ses membres ou par aucun

Algorithme de « relais intra-groupe » (Joseph et Birman 1989)

1- L ’expéditeur envoie un message à tous les membres d ’un groupe (des temporisateurssont armés et des retransmissions faites si nécessaire)

2- Tout membre de ce groupe, qui a reçu ce message pour la première fois, doit l ’envoyerà tous les membres du groupe (des temporisateurs sont armés et des retransmissions faites si nécessaire)

3- Tout membre de ce groupe, qui a reçu ce message plus qu ’une fois, doit simplement le détruire

Page 50

II.2.4- Communication de groupe (multipoints)II.2.4.6- Séquencement

II- Partie II : systèmes distribuésII.2- Communications dans les systèmes distribués

II- Partie II : systèmes distribuésII.2- Communications dans les systèmes distribués

Propriété de séquencement

Soient A et B 2 messages à envoyer à un groupe de processus G. Si A est envoyé avant B sur le réseau, ils doivent être reçus par tous les membres du groupe G dans le même ordre : A puis B

S2

S1C1

C2

M1

M2

1

2

34

MAJ Incohérente

- Séquencement global (global time ordering) : conserver, en réception, l ’ordre des messages à émission. Si C1 envoie M1 avant que C2 envoie M2, alors le système doit assurer que tous les membres de G reçoivent M1 avant M2

- Séquencement cohérent (Consistent time ordering) :Le système établir l ’ordre d ’envoie des messages et assurer que cet ordre soit respecté à la réception des messages.

Solutions

Page 26

Page 51

II.2.4- Communication de groupe (multipoints)II.2.4.7- Groupes non disjoints

II- Partie II : systèmes distribuésII.2- Communications dans les systèmes distribués

II- Partie II : systèmes distribuésII.2- Communications dans les systèmes distribués

A DB

C

1 2

34

Groupe 1 Groupe 2

L ’ordre de recouvrement des groupesnon respecté :

- B reçoit le message de A puis D- C reçoit le message de D puis A

Si B et C est une base de données dupliquée on peut avoir une incohérence de MAJ

Solution

Introduction des mécanisme de séquencement qui tient compte du recouvrement des groupes

La mise en œuvre est compliquéeet coûteuse

Problème

Page 52

II.2.4- Communication de groupe (multipoints)II.2.4.8- Elasticité

II- Partie II : systèmes distribuésII.2- Communications dans les systèmes distribués

II- Partie II : systèmes distribuésII.2- Communications dans les systèmes distribués

G1 G3

G2 G4

Lan 1

Lan 2

Lan 3

Lan 4

Diffusionmultiple

Propriété

La communication de groupe doit être invariante par rapport à la taille du groupe : L’algorithme doit êtreefficace dans un petit groupe comme dans un grand groupe (nombre de membre et taille de l’espace)

Problèmes

- beaucoup d ’algorithmes fonctionnent très bien dans des petits groupes mais deviennent non fiable dans desgrands groupe- la taille de réseau avec la présence des passerelles rendplus compliqué le problème de communication de groupe

Page 27

Page 53

II.2.5- Résumé

II- Partie II : systèmes distribuésII.2- Communications dans les systèmes distribués

II- Partie II : systèmes distribuésII.2- Communications dans les systèmes distribués

Protocoles orientés connexion

Protocoles orientés Question/Réponse

Modèle en couches OSI

ModèleClient/Serveur

ModèleR.P.C.

ModèleCommunication de G.

Applications distribuées

Page 54

II.2.6- Approches pratiquesApplications Clients / Serveur : Modèle de base

II- Partie II : systèmes distribuésII.2- Communications dans les systèmes distribués

II- Partie II : systèmes distribuésII.2- Communications dans les systèmes distribués

ApplicationClient

ApplicationServeurProtocole de l ’application

Protocole de communication sur réseaux

Identification du service(N° port, @machine)

Exemple : Services Internet

- Telnet : Terminal Network protocol- Ftp : File transport Protocol- Courriers électroniques : SMTP, POP3, …- Web : HTTP et Navigateur- ...

Page 28

Page 55

II.2.6- Approches pratiquesApplications Clients / Serveur : Modèle 3-Tiers

II- Partie II : systèmes distribuésII.2- Communications dans les systèmes distribués

II- Partie II : systèmes distribuésII.2- Communications dans les systèmes distribués

ApplicationClient

ApplicationServeur

Protocole de communication sur réseaux

Identification du service(N° port, @machine)

Exemples

- ODBC : Object DataBase Connectivity- JDBC : Java DataBase Connectivity- Applications intra/internet- Message Queues- CORBA, DCOM / ACTIVEX, Java Rmi

Middleware« standard » « standard »

Page 56

II.2.6- Approches pratiquesApplications Clients / Serveur sur web

II- Partie II : systèmes distribuésII.2- Communications dans les systèmes distribués

II- Partie II : systèmes distribuésII.2- Communications dans les systèmes distribués

Navigateur WEB« Client universel »

+JavaScript, Japplet,

Plug-ins

Application ServeurSGBDApp. PropriétairesServletAutres

TCP/IP

Identification du service(N° port, @machine)

Exemples

- Commerces électroniques- Applications Intranet / Internet / Extranet- Télétravail- Téléenseignement- ...

Server HTTP

- Communication- Distribution- Sécurité

HTTP CGI/Autres

Page 29

Page 57

II.2.6- Exercices

1- Si les primitives de communication dans un système client/serveur sont non bloquantes, un appel send rendlamain avant que le message ne soit complètement envoyé. Pour réduire les pertes de temps, certains systèmes ne copient pas les données dans le noyau, mais les transmettent directement à partir de l ’espace utilisateur. Pour un tel système, donnez 2 façons d ’avertir l ’appelant que la transmission est terminée et qu’il peut donc réutiliser le tampon d’émission

2- Pour chacune des applications suivantes, pensez vous qu’une sémantique du type « une fois au moins » soit meilleure qu’une sémantique du type « une fois au plus » ? Justifiez :a) lecture et écriture de fichier sur un serveur de fichiers;b) compilation d ’un programme;c) opérateur bancaire à distance.

3- Supposons que le temps pris pour exécuter un RPC vide (sans données) soit de 1ms et qu ’il faille 1,5ms pour chaque Ko de données. Quel sera le temps mis pour lire 32Ko sur un serveur de fichiers en un seul RPC de 32Ko ? Et en 32 RPC de 1Ko ?

4- Proposer un mécanisme de gérer l ’appartenance à un groupe en supposant que le réseau permet la diffusion globale atomique

5- Considérons un système distribué dans lequel toutes les machines sont des multiprocesseurs redondants de telle sorte que la probabilité de panne soit quasi nulle. Proposez une méthode simple pour implanter la diffusion atomique avec séquencement globale un utilisant seulement la monodiffusion. (Indication : organisez ces machine en un anneau logique)

II- Partie II : systèmes distribuésII.2- Communications dans les systèmes distribués

II- Partie II : systèmes distribuésII.2- Communications dans les systèmes distribués

Page 58

II.3.1- Introduction

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

Coopération interprocessus

- Sections critiques- Exclusion mutuelle- Mécanismes de synchronisation- Mécanismes transactionnels

Systèmes centralisésMEMOIRE COMMUNE

Systèmes distribuésMEMOIRES PRIVEES

SémaphoresMoniteurs...

Mécanismes

?Mécanismes

- Mesure de temps dans lessystèmes distribués

- Exclusion mutuelle dans unsystème distribué

- Algorithmes d ’élection

- Algorithmes de transactionsatomiques

- Interblocage dans les systèmes distribués

Page 30

Page 59

II.3.2- Synchronisation d ’horlogeII.3.2.1- Introduction

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

Propriétés d’algorithmes distribués

1- les informations importantessont disséminées sur plusieursmachines2- les processus prennent des décisions fondées uniquementsur l ’information disponiblelocalement3- la garantie de la fiabilité doitêtre renforcée (talon d ’Achille à éviter)4- il n ’existe pas d ’horlogecommune ni de source de temps universel

M2 : CompilationM1 : Edition du prog.

120

121

122

123

124

122

123

124

125

126

Temps

Horloge M1 Horloge M2

Créationoutput.o

Créationoutput.c

Page 60

II.3.2- Synchronisation d ’horlogeII.3.2.2- Horloges logiques

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

Horloge logique

Temporisateur associé à chaqueprocesseur permettant générer un compteur de temps local (desimpulsion d ’horloge)

Problème de dérive d ’horloge

Dans un systèmes multiprocsseursau fil de temps, la synchronisationdes horloges se dégrade

Introduction des erreurs

06121824303642485460

08162432404856647280

0102030405060708090100

1 2 3

(a)

06121824303642487076

08162432404861697785

0102030405060708090100

1 2 3

(b)

A

B

C

D

A

B

C

D

Algorithme Lamport (1990)

Page 31

Page 61

II.3.2- Synchronisation d ’horlogeII.3.2.3- Horloges physiques

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

Soleil

Orbite terrestre

Vers unegalaxieéloignée

Position de la Terre au moment dutransit du Soleil (jour n)

Position de la Terre au moment dutransit du Soleil (jour 0)

∅∅

Au transit du Soleiln jours plus tardla Terre a tourné d ’unpeu moins de 360°xn

Le transit du Soileil correspondau moment où le Soleil rejointson zénith

- Besoin pour les applications « temps réel »- Nécessité de plusieurs horloges

- Problèmes :- synchronisation avec l’horloge universelle- synchronisation entre les horloges

Page 62

II.3.2- Synchronisation d ’horlogeII.3.2.3- Horloges physiques

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

1 2 3 4 5 6 7 8 9 10 11 12 1314 15 1617 1819 20 2122 23 2425 26

1 2 3 4 5 6 7 8 9 11 12 13 14 15 16 17 18 19 21 22 23 24 25

Secondes sautées introduites quand il devient nécessaire de se synchroniser avec le soleil

TAI

Secondessolaires

Réglage du décalage entre TAI et l ’horloge solaire : 1 seconde sautée quand le tempssolaire devient supérieur à 800ms

TUC = Temps Universel CoordonnéUCT = Universal Coordonated Temps

Page 32

Page 63

II.3.2- Synchronisation d ’horlogeII.3.2.4- Algorithmes de synchronisation d’horloges physiques

Modèle commun de communication

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

Horloge p

arfait

e

Horlo

ge ra

pide

Horloge lente

dCdt = 1

dCdt > 1

dCdt < 1

TUC,t

Tem

ps d

e l’ h

o rl o

g e, C

- Chaque machine a 1 compteur de temps qui produitune interruption H fois /s. Quand ce compteur vient àépuisement, le gestionnaire d ’interruption ajoute 1 àl’horloge logique qui sont réglée à partir une date fixeen commun- Soit C la valeur de cette horloge, soit t le temps TUC,la valeur de l ’horloge sur la machine p est Cp(t)- Dans un monde parfait, on a Cp(t)=t pour tout couple(p,t). En d ’autres termes, dC/dt devrait idéalement êtreégal à 1- En réalité, il existe une constante ρ, appelée taux dedérive maximum, telle que :

1 - ρ ≤ dC/dt ≤ 1 + ρ- Si 2 horloges dérivent du TUC dans des directionsopposées, leur décalage après un temps ∆t sera aumaximum 2ρ∆t

Pour garantir que deux horloges nedérivent pas plus que δ, alors les horloges doivent être resynchroniséesau moins toute les δ/2ρ secondes

Page 64

II.3.2- Synchronisation d ’horlogeII.3.2.4- Algorithmes de synchronisation d ’horloges physiques

Algorithme de Cristian (1989)

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

Machine Client Serveur de temps

T0

T1

Tem

ps

Chaque machine interroge périodiquement (< toutes les δ/2ρ s)le serveur de temps pour avoir l ’heure courante afin de pouvoir corriger d ’une manière adéquate son horloge

La correction d ’une horloge doit se faire graduellement.On retarde (ou accélère) une horloge rapide (ou lente)en diminuant (ou ajoutant) un certain nombre de ns de la (au) constante de temps utilisée pour avancer l ’horloge logique dans la routine d ’interruption. Cettecorrection a pour une durée nécessaire correspondantau décalage de l ’horloge locale par rapport le CTUC

La machine Client doit tenir compte le temps de propagation des messages entre lui et le serveur de temps. La valeur de correction est

Ccor = (T1-T2)/2 + CTUCSi le temps de gestion l ’interruption I sur serveur est connu, on peut le tenir compte dans la formule :

Ccor = (T1-T2-I)/2 + CTUC

Page 33

Page 65

II.3.2- Synchronisation d’horlogeII.3.2.4- Algorithmes de synchronisation d’horloges

Algorithme de Berkeley

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

2:00

2:30 1:50

2:00

2:002:00

2:00

2:30 1:50

0

-10+30

2:05

3:05 3:05

+5

+15-25

Dans UNIX de Berkeley (Gusella et Zatti, 1989), le serveur de temps est actif et scructepériodiquement chaque machine pour luis demande l ’heure. A partir de ses réponses,il calcule le temps moyen et demande à toutes les machines de régler son horloge

Page 66

II.3.2- Synchronisation d’horlogeII.3.2.4- Algorithmes de synchronisation d’horloges

Algorithmes basés sur la moyenne

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

Chaque machinediffuse son heureau début d ’unepériode de temps[T0+iR, T0+(i+1)R]

Chaque machine démarre un temporisateur et collectetous les messages arrivésdurant l ’intervalle S

Chaque machine exécute unmême algorithme à partir desdonnées reçu pour l ’obtentiond ’une heure moyenne

Page 34

Page 67

II.3.3- Exclusion mutuelleII.3.3.1- Rappels

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

RessourceCommune

Prog.1

Prog.2

Processus A Processus BSectionscritiques

Exclusion mutuelle

A tout instant du système, il y a au maximum 1 processus qui peut entrer dans une section

critique

Dans les systèmes centralisés

SémaphoresMoniteurs

Compteurs d ’événementsMessages

Contrainte dans un système distribué

Les mécanismes basés sur une mémoire commune ne sont plus valables

Page 68

II.3.3- Exclusion mutuelleII.3.3.2- Un algorithme centralisé

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

0 1 2

C

Demande

OKFile d ’attente

Coordinateur

0 1 2

C

Demande Pas deréponse

Coordinateur

0 1 2

C

RelâchementOK

Coordinateur2

Situation 1 Situation 2 Situation 3

Page 35

Page 69

II.3.3- Exclusion mutuelleII.3.3.3- Un algorithme distribué (Ricart & Agrawala-1981)

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

Hypothèse : il existe un ordre total sur les événements (ex. utilisation de l’algorithme Lamport)

0

1 2

8

8

1212

8 12

0

1 2

OK OK

0

1 2

OK

P0 et P2 veulent entrer dansune même section critique

P0 est plus ancien, il gagneet entre en section critique

OKP1 entre en section critique

Page 70

II.3.3- Exclusion mutuelleII.3.3.4- Un algorithme de type anneau à jeton

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

0

12

3

4

5

678

9

- établir un anneau logique entre les processus- introduire un jeton dans l ’anneau- le processus possédant le jeton peut entrer en sectioncritique. Il garde le jeton jusqu’à sa sortie de la sectioncritique. Il passe ensuite le jeton au processus suivant dans l ’anneau logique- sinon, il passe le jeton au processus suivant dans l ’anneau logique

Problèmes- la perte de jeton -> algorithmes de détection et régénérer le jeton- la panne d ’un processus -> régénérer l ’anneauou l ’algorithme de détection de la mort du voisin

Page 36

Page 71

II.3.3- Exclusion mutuelleII.3.3.5- Conclusion et comparaison

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

Type d’algorithme

Nombre de messages

par entrée/sortieTemps avant

entrée Problèmes

Centralisé

Distribué

Anneau à jeton

3

2(n-1)

1 à ∞

2

2(n-1)

0 à n-1

Plantage du coordinateur

Plantage d ’un processus

Perte de jeton, plantage de processus

L ’algorithme distribué est beaucoup plus sensible au plantage que l ’algorithme centralisé !

Page 72

II.3.4- Algorithmes d’électionII.3.4.1- Introduction

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

0

12

3

4

5

678

9

QUI VA NOUSGOUVERNER ?

Hypothèses

- chaque processus a 1 numéro d ’identification unique- il n ’existe qu’un processus par machine - chaque processus connaît l ’identité de tous les autres processus, mais ne sait pas qui est actif et qui ne l ’est pas

But

organiser une élection qui garantie que :- le processus élu soit actif- l ’élection soit terminée avec l ’accord de tous les processus sur l ’identité du processus élu

Page 37

Page 73

II.3.4- Algorithmes d’électionII.3.4.2- Algorithme du plus fort

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

2 1

4 5

0

7

6

3

2 1

4 5

0

7

6

3

2 1

4 5

0

7

6

3

2 1

4 5

0

7

6

3

2 1

4 5

0

7

6

3

(a) (b) (c)

(d) (e)

électionélection

élection

OK

OKélection

électi

on

élection

OK

Coordinateur

Page 74

II.3.4- Algorithmes d’électionII.3.4.3- Algorithme pour anneau

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

1 2

3

4

56

7

0

Pas de réponse

Panne del ’anciencoordinateur

Message d’élection

Message d’élection

2

23

5

56

567

Anneau sans jeton

Page 38

Page 75

II.3.5- Transaction atomiques distribuéesII.3.5.1- Introduction

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

Problème

Accès concurrents aux ressources communes

Niveau bas d ’abstraction« Sections Critiques »

- le contrôle de synchronisation doitêtre fait par les programmeurs

- les mécanismes de synchronisationsont visibles dans le programme

- pour des programmeurs bienspécialisés

Niveau haut d ’abstraction« Transactions Atomiques »

- le contrôle de synchronisation estassuré par le système d’exploitation

- les mécanismes de synchronisationsont cachés aux programmeurs

- pour des programmeurs nonspécialisés

SOLUTIONS

Page 76

II.3.5- Transaction atomiques distribuéesII.3.5.1- Introduction

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

Résultat : C1 = 5 000 et C2 = -4 000

10 000 -4 000

C1 C2

5 000

Temps

Lire(C1)C1:= C1-5000Ecrire(C1)Lire(C2)C2:= C2+5000Ecrire(C2)

Panne

LA PERTE D ’ARGENT

Prog. inventaire

Ancien inventaireMise à jour

Nouvel inventaire

Un système tolérant aux pannes

Page 39

Page 77

II.3.5- Transaction atomiques distribuéesII.3.5.2- Modèle de transaction

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

TRANSACTION

On appelle transaction l'unité de traitement séquentiel, exécutée pour le compte d'un processus, appliquée à une mémoire stable cohérente, restitue une mémoire stable cohérente

PROPRIÉTÉS

- Atomicité : Une transaction est une unité logique indivisible de traitement qui est soit complètement exécutée soit complètement abandonnée

- Sérialité : Les transactions concurrentes n ’interfèrent pas entre elles

- Permanence : Si une transaction est validée, tous les changements par elle sur la mémoire stable sont devenus définitifs

Page 78

II.3.5- Transaction atomiques distribuéesII.3.5.2- Modèle de transaction

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

Mémoire stable

Ordonnancementtransactionnel

Primitives de spécification des transactions

BEGIN TRANSACTIONEND_TRANSACTIONABORT_TRANSACTIONREADWRITE Exécution

concurrentedes transactions

Mécanismes de contrôle et de synchronisation

Page 40

Page 79

II.3.5- Transaction atomiques distribuéesII.3.5.2- Modèle de transaction

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

BEGIN_TRANSACTIONREAD C1 C1 := C1 - 5000 WRITE C1 READ C2 C2 := C2 + 5000 WRITE C2 END_TRANSACTION

(1) (2) (3) (4) (5) (6) (7) (8)

Etat cohérent avant

Etat cohérent après

Eta

t tra

nsito

ire

Mémoirestable

La mise-à-jour sûre par une transaction

Page 80

II.3.5- Transaction atomiques distribuéesII.3.5.2- Modèle de transaction

Transactions imbriquées

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

T

T1 T2 T3

T11 T12 T21 T22 T31 T32 T33

T211 T212 T213

Une hiérarchie des transactions impliquées

Une transaction peut contenir des sous-transactionsappelées transactions imbriquées

- les filles d ’une transaction n esont pas nécessairement exécutéessur le même processeur

- la profondeur d ’imbrication peut-êtrequelconque, ce qui engendre certains problèmes de gestion de cohérence et de performance

Page 41

Page 81

II.3.5- Transaction atomiques distribuéesII.3.5.3- Implantation de l’atomicité de transaction

Mémoire d ’ombre (espace de travail privé)

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

1 2 0

012

index

1 2 0

0 ’ 3 ’

012

index0 ’123 ’

Index privés

1 2

0 3

index

0123

Page 82

II.3.5- Transaction atomiques distribuéesII.3.5.3- Implantation de l’atomicité de transaction

Journal des inscriptions (writeahead log)

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

x=0;

y=0;

begin transaction

x=x+1;

y=y+2;

x=y*y;

end transaction

x=0/1 x=0/1

y=0/2

x=0/1

y=0/2

x=1/4

Temps

Valeurs du journal par étapes

Page 42

Page 83

II.3.5- Transaction atomiques distribuéesII.3.5.3- Implantation de l’atomicité de transaction

Protocole de validation en deux phases (GRAY 78)

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

Coordinateur Subordonné

- Ecrire « Préparation » dans lejournal- Envoyer le message « Préparation »

- Collection tourtes les réponses- Ecrire « Prêt » dans le journalEnvoyer le message « Prêt »

- Ecrire les enregistrements du journal- Envoyer le message « Validation »

- Collection toutes les réponsesEcrire « Validation » dans le journalValiderEnvoyer le message « Terminer »

Phase 1

Phase 2

Page 84

II.3.5- Transaction atomiques distribuéesII.3.5.4- Implantation de sérialité de la transaction

Définitions de base

• CONTRÔLEUR (SCHEDULER) : Un contrôleur transactionnel est un module système chargé de contrôler les accès concurrent aux données

• GRANULE : On appelle granule l'unité de données dont l'accès est contrôlé individuellement par un contrôleur

• OPÉRATION : Une opération est une suite d'actions élémentaires accomplissant une fonction sur un granule en respectant sa cohérence interne

• RÉSULTAT DE L'OPÉRATION : Le résultat d'une opération est l'état du granule concerné après l'application de l'opération considérée anssi que les effets de bords provoqués par l'opération

• ORDONNANCEMENT DE TRANSACTIONS (SCHEDULE - LOG) : Une ordonnancement des transactions (T1, T2, ..., Tn) est une séquence d'actions élémentaires obtenues en interclassant les diverses actions des transactions concernant

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

Page 43

Page 85

II.3.5- Transaction atomiques distribuéesII.3.5.4- Implantation de sérialité de la transaction

Définitions de base : Exemples

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

T1 T2Lire A → a1 Lire A → a2a1 + 1 → a1 a2 * 2 → a2Ecrire a1 → A Ecrire a2 → ALire B → b1 Lire B → b2b1 + 1 → b1 b1 * 2 → b2Ecrire b1 → B Ecrire b2 → B

ORDONNANCEMENT 1 ORDONNANCEMENT 2T1: Lire A → a1 T2: Lire A → a2T1: a1 + 1 → a1 T2: a2 * 2 → a2T1: Ecrire a1 → A T1: Lire A → a1T2: Lire A → a2 T1: a1 + 1 → a1T2: a2 * 2 → a2 T2: Ecrire a2 → AT2: Ecrire a2 → A T2: Lire B → b2T1: Lire B → b1 T2: b1 * 2 → b2T1: b1 + 1 → b1 T1: Ecrire a1 → AT1: Ecrire b1 → B T1: Lire B → b1T2: Lire B → b2 T1: b1 + 1 → b1T2: b1 * 2 → b2 T1: Ecrire b1 → BT2: Ecrire b2 → B T2: Ecrire b2 → B

O11

O21

O22

O12

Page 86

II.3.5- Transaction atomiques distribuéesII.3.5.4- Implantation de sérialité de la transaction

Propriétés des opérations

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

Opérations compatibles

Deux opérations Oi et Oj sont compatibles si et seulement si quel que soit l ’exécution simultanée de

Oi et Oj le résultat de cette exécution est identique que celui d’une exécution

séquentielle de ces opérations, soit de Oisuivie par Oj soit de Oj suivie par Oi

O11: Lire A → a1 a1 + 1 → a1 Imprimer a1

O21: Lire A → a2 a2 * 2 → a2 Ecrire a2 → A

O12: Lire A → a1 a1 + 1 → a1 Imprimer a1

O22: Lire A → a2 a2 * 2 → a2 Imprimer a2

O13: Lire A → a1 a1 + 1 → a1 Ecrire a1 → A

O23: Lire A → a2 a2+10 → a2 Ecrire a2 → A

Opérations permutables

Deux opérations Oi et Ojsont permutables si et

seulement si toute exécutionséquentielle de Oi suivie par Oj donne le même résultat

que celle de Oj suivie par Oi

Compatibles

Permutables

Page 44

Page 87

II.3.5- Transaction atomiques distribuéesII.3.5.4- Implantation de sérialité de la transaction

Ordonnancements sérialisables : définition

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

ORDONNANCEMENT SERIALISE - SUCCESSION (SERIAL SCHEDULE)

Un ordonnancement O de T1, .., Tn est dit sérialisé s'il est une exécution séquentiel des ces transactions

(formellement s’il existe une permutation šde (1, 2, ..,n) telle que O = < Tš(1), Tš(2), .., Tš(n) >)

PROPRIÉTÉ

Une succession est une exécution sans perte

d'opérations niinconsistances

ORDONNANCEMENT SÉRIALISABLE (SERIALIZABLE SCHEDULE)

Un ordonnancement quelconque de T1, .., Tn est dit sérialisable si et seulement s’il donne pour chaque transaction participante le même

résultat qu'une succession de T1, .., Tn

Page 88

II.3.5- Transaction atomiques distribuéesII.3.5.4- Implantation de sérialité de la transaction

Ordonnancements sérialisables : caractérisation

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

Transformations de base - Séparation des opération :remplacer les exécutions simultanées des couples d ’opérations compatibles E(Oi,Oj)par l ’exécution séquentielle équivalente (soit <Oi,Oj> soit <Oj,Oi>- Permutation d ’opérations:remplacer l ’ordre d ’exécution d ’un couple d ’opérations permutables <Oi,Oj>par l ’ordre inverse <Oj,Oi>

Théorème 1Une condition suffisante pour qu ’ un ordonnancementsoit sérialisable est qu ’il puisse être transformé par l ’application des deux transformations de base en unordonnancement sérialisé (succession) des transactionscomposantes

ORDONNANCEMENT 1T1: Lire A → a1 T1: a1 + 1 → a1T1: Ecrire a1 → AT2: Lire A → a2T2: a2 * 2 → a2T2: Ecrire a2 → AT1: Lire B → b1T1: b1 + 1 → b1T1: Ecrire b1 → BT2: Lire B → b2T2: b1 * 2 → b2T2: Ecrire b2 → B

O11

O21

O22

O12

ORDONNANCEMENT 2T1: Lire A → a1 T1: a1 + 1 → a1T1: Ecrire a1 → AT1: Lire B → b1T1: b1 + 1 → b1T1: Ecrire b1 → B T2: Lire A → a2T2: a2 * 2 → a2T2: Ecrire a2 → AT2: Lire B → b2T2: b1 * 2 → b2T2: Ecrire b2 → B

O11

O21

O22

O12

Page 45

Page 89

II.3.5- Transaction atomiques distribuéesII.3.5.4- Implantation de sérialité de la transactionOrdonnancements sérialisables : Graphe de précédence

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

Précédence

Soit S une ordonnancement sans opération simultanée. On dit que Ti précède Tj (noté Ti<Tj) dans S si et seulement s ’il existe deux opérations non permutables Oi et Oj telles que Oi est exécutée par Ti avant Oj par Tj

ORDONNANCEMENT 1

T1: A+1 → AT2: A*2 → AT1: B+1 → BT2: B*2 → B

T1 T2

ORDONNANCEMENT 2

T1: A+1 → AT2: A*2 → AT2: B*2 → BT1: B+1 → B

T1 T2

Théorème 2Une condition suffisante pour qu’un ordonnancement soit sérialisable est que le graphede précédence associé estsans circuit

Page 90

II.3.5- Transaction atomiques distribuéesII.3.5.4- Implantation de sérialité de la transaction

Verrouillage en deux phases

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

1 0

00

L E

L

E

Matrice de compatibilité

C

T1, T2, ...,Tn n transactions à exécuter

A(g,i) est le vecteur de mode actuellementposé par Ti sur le granule g

Opérations protocolaires- LOCK(g,M) permet à une transaction demander de poserun verrou de type M sur le granule g- UNLOCK(g) permet à une transaction demander de leverle verrou qu ’il a posé sur le granule g

ThéorèmeLes modes d ’opération demandés lors d ’une primitiveLOCK(g,M) exécutée par une transaction Tp sont compatibleavec les modes en cours d ’exécution sur g par les autres transaction si et seulement si :

M ⊂ ¬ (¬C * ∪ A(g,i))i≠p

M est le vecteur de modes de verrou demandés par une transaction Tp sur le granule g

Page 46

Page 91

II.3.5- Transaction atomiques distribuéesII.3.5.4- Implantation de sérialité de la transaction

Verrouillage en deux phases

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

Procédure LOCK (g,M)Si M ⊂ ¬ (¬C * ∪ A(g,i))

i≠p

alors A(g,p) := A(g,p) ∪ Msinon « inserer ‘(p,M) dans Q[j] »;

« bloquer la transaction Tp »;finsi;

fin LOCK;

Procédure UNLOCK (g)A(g,p) := (0);Pour chaque (q,M ’) de Q[g] faire

Si M ’ ⊂ ¬ (¬C * ∪ A(g,i))i≠q

alors A(g,q) := A(g,p) ∪ M ’«Extraire (q,M ’) de Q[j] »;« débloquer la transaction Tq »;

finsi; finpour;fin UNLOCK;

Restriction « deux phases »

Une transaction est dit à deux phasessi et seulement si elle n ’exécute pas deLOCK après avoir exécuté UNLOCK

ThéorèmeTout ordonnancement complète d ’un ensemble detransactions « deux-phases » est sérialisable

Page 92

II.3.5- Transaction atomiques distribuéesII.3.5.4- Implantation de sérialité de la transaction

Verrouillage en deux phases

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

Point de verrouillage

Phasede croissance

Phasede diminution

Nombre de verrous

Temps

Page 47

Page 93

II.3.5- Transaction atomiques distribuéesII.3.5.4- Implantation de sérialité de la transaction

Contrôle de concurrence optimiste (Kung et Robinson, 1981)

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

Principes de fonctionnement

- considérer que chaque transaction se compose de deux étapes :- une étape de lecture et calcul privé- une étape d'écriture réelle dans la base (commitment)

- ordonner les transactions selon le moment où elles terminent la première étape de lecture et de calcul

- contrôler que les accès conflictuels aux granules s'effectuent bien dans l'ordre ainsi obtenu

Idée de base

1) Allez de l ’avant et faites tout ce que vous voulez, sans faire attention à ce que les autres font2) S ’il arrive un problème, on s ’en occupera plus tard

Page 94

II.3.5- Transaction atomiques distribuéesII.3.5.4- Implantation de sérialité de la transaction

Estampillage

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

Estampille de granule

valeur numérique associée à un granule mémorisantl ’estampille de la dernière transaction ayant opérésur ce granule

Estampille de transaction

valeur numérique unique associée à une transactionau moment de son commencement

Principes

1- toute transaction a un estampille unique. Les estampilles forme un ordre total des transaction2- une transaction ayant accédé à un granule doit mémoriser son estampille sur le granule 3- une transaction veut accéder à un granule doit comparer son estampille avec ce du granule, si il estplus jeune que celui dernière, il peut accéder au granule4- dans le cas contraire, il devra se suicider

Page 48

Page 95

II.3.5- Transaction atomiques distribuéesII.3.5.4- Interblocage

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

T1 T2

A

B

t1

t2t3

t4

t1 > t2 > t3 > t4

Quatre stratégies de gestion

1. La politique de l ’autruche (ignorer le problème)

2. La détection (permettre aux interblocages de se produire, les détecter, puis tenter de les éliminer)

3. La prévention (rendre de façon statique lesinterblocages structurelles impossibles)

4. L ’évitement (éviter les interblocages en distribuant les ressources avec précaution)

Page 96

II.3.5- Transaction atomiques distribuéesII.3.5.4- Interblocage

Graphe des attentes et graphes d ’allocation

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

Graphe des attentes (Murphy68)

Soient T l ’ensemble de n transactions concurrenteset R une relation binaire sur T, appelée « attend »,définie comme suit : Ti attend Tj si et seulementsi Ti attend le verrouillage d ’un granule g qui a déjàété verrouillé par Tj. G(T,r) est le graphe conçu surT par cette relation R

Théorème :Il existe un interblocage si et seulement si le graphedes attentes possède un circuit

Graphe des allocations (Holt72)

Soient T l ’ensemble de n transactions concurrenteset G l ’ensembles des granules. Le graphe des allocationsse compose des sommets dans T+G et des arcs définis comme suit : un arc relie Gi à Tp si et seulement si Tp a obtenu le verrouillage sur Gi; un arc relie Tq à Gj si etseulement si Tq attend un verrou sur Gj

Théorème :Une condition nécessaire d ’existence d ’un interblocageest que le graphe des allocations possède un circuit

T0T1

T2

T1 T2

G1 G2

Page 49

Page 97

II.3.5- Transaction atomiques distribuéesII.3.5.4- Interblocage

Détection des interblocages : algorithmes centralisés

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

A

B

R

S CS

T

A

B

R

S C

T

A

B

R

S C

T

Machine 0 Machine 1 Coordinateur Coordinateur

(1) (2) (3) (4)

Problème de la « mort injuste »

Page 98

II.3.5- Transaction atomiques distribuéesII.3.5.4- Interblocage

Détection des interblocages : algorithmes distribués

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

35

6

7

80 1 2

4

Machine 1Machine 0 Machine 2

(0,2,3)

(0,4,6)

(0,5,7)

(0,8,0)

Algorithme de Chandy-Misra-Haas (1983)

Page 50

Page 99

II.3.5- Transaction atomiques distribuéesII.3.5.4- Interblocage

Prévention des interblocages : généralité

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

Principe La prévention des interblocages consiste à construire prudemment le système de façon de rendre les interblocages

structurellement impossibles. Autrement dit, elle consiste à supprimer l ’une des conditions qui rend possiblel ’interblocage

Contraintes d ’allocation

- un processus ne détient qu’une ressource à la fois- un processus doit déclarer toutesces ressources qu’il a besoin- un processus doit relâcher les ressources qu’il détient pour pouvoir allouer une nouvelle

Ordonnancement des ressources

- préordonner toutes les ressources du système

- un processus doit acquérir les ressources qu’il a besoin dansl ’ordre strictement croissant

Ordonnancement des transactions

- préordonner toutes les transactions par l ’estampille

- déterminer une politique d ’allocation des ressources adéquate permettant d ’éviter lesinterblocages

Page 100

II.3.5- Transaction atomiques distribuéesII.3.5.4- Interblocage

Prévention des interblocages : algorithme « attente-mort » (wait-die)

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

Plus vieux

Plus jeune

10

20

Attente Plus jeune

Plus vieux

20

10

Mort

Décision

Page 51

Page 101

II.3.5- Transaction atomiques distribuéesII.3.5.4- Interblocage

Prévention des interblocages : algorithme « blessure-attente »

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

II- Partie II : systèmes distribuésII.3- Synchronisation dans les systèmes distribués

Plus vieux

Plus jeune

10

20

Préemption« Blesser le jeune » Plus jeune

Plus vieux

20

10

Attente

Décision