Vous êtes sur la page 1sur 115

Cours de

Fondements de Bases des Systmes


Distribus
A.U. 2010/11
2 ingnieurs 01,02 et 03

Plan
Introduction:
Dfinition, organisation, proprits,

Partie 1: Bases de lalgorithmique rpartie


1.
2.
3.

Etat dans un systme rparti, ordre, temps,


Observation cohrente
Algorithmique rpartie

Partie2: Tolrance aux pannes et aux fautes


1.

2.
3.
2

Validation atomique
Groupes, diffusion, cohrence
Consensus, prise de dcision

Dfinition dun systme rparti


Ensemble compos dlments relis par un systme de

communication ; les lments ont des fonctions de traitement


(processeurs), de stockage (mmoire), de relation avec le monde
extrieur (capteurs, actionneurs)

Dfinition dun systme rparti


Les diffrents lments du systme ne fonctionnent pas

indpendamment mais collaborent une ou plusieurs tches


communes.
Consquence : une partie au moins de ltat global du
systme est partage entre plusieurs lments (sinon, on
aurait un fonctionnement indpendant)

Dfinition dun systme rparti


A distributed system is one that stops you from getting any

work done when a machine youve never heard of crashes.


Leslie Lamport
Rsum:
linterdpendance entre les lments dun systme rparti
limportance du traitement des dfaillances

Pourquoi des systmes rpartis?


La rpartition est un tat de fait pour un nombre important

dapplications
Besoins propres des applications
Intgration dapplications existantes initialement spares

Intgration massive de ressources


Grilles de calcul, gestion de donnes
Pntration de linformatique dans des domaines nouveaux

dapplication
Intgration dobjets du monde rel (informatique omniprsente )

Surveillance et commande dinstallations

Organisation dun systme rparti


Un schma de base : lintergiciel (middleware)

Lintergiciel sert de super-systme dexploitation pour les applications


7

Proprits des systmes rpartis


Le systme doit pouvoir fonctionner (au moins de faon dgrade) mme

en cas de dfaillance de certains de ses lments


Le systme doit pouvoir rsister des perturbations du systme de
communication (perte de messages, dconnexion temporaire,
performances dgrades)
Le systme doit pouvoir rsister des attaques contre sa scurit (tentatives
de violation de la confidentialit et de lintgrit, usage indu de ressources,
dni de service)
Le systme doit sadapter pour faire face aux changements de conditions
dutilisation et denvironnement
Le systme reste performant lorsque sa taille augmente (nombre
dlments, nombre dutilisateurs, tendue gographique)

Difficults dans les systmes rpartis


Proprit dasynchronisme du systme de communication (pas de borne

suprieure stricte pour le temps de transmission dun message)


Consquence : difficult pour dtecter les dfaillances
Dynamisme (la composition du systme change en permanence)
Consquences : difficult pour dfinir un tat global
Difficult pour administrer le systme
Taille complexe et dveloppe (nombre de composants, dutilisateurs,
dispersion gographique)
Consquence : la capacit de croissance est une proprit importante, mais
difficile raliser
En dpit de ces difficults, des systmes rpartis existent tels que:
le DNS (Domain Name System)
le World Wide Web
divers services sur lInternet

(service de base)
(infrastructure)
(applications)

Que va-t-on voir dans ce cours?


Approche descriptive
tude des divers modles de conception et de construction
dapplications rpartis (client-serveur, vnements et
messages, objets rpartis, composants rpartis, etc.)
tude des diverses classes de systmes, intergiciels et
applications, et de leurs modes dorganisation et de
fonctionnement
Ce nest pas la problmatique de ce cours

10

Que va-t-on voir dans ce cours?


Approche fondamentale
tude des fondements de base des systmes rpartis ; les
problmes fondamentaux (et leur origine), les solutions
connues,
Application de ces principes quelques situations concrtes.
cest lobjet du prsent cours

11

Problmes fondamentaux
Comment dterminer des proprits globales partir dobservations

12

locales ?
Comment coordonner des oprations en labsence dhorloge commune ?
Comment partager des donnes en labsence de mmoire commune ?
Y a-t-il des problmes intrinsquement insolubles ?
Comment dfinir, et maintenir, la cohrence dinformations rparties ?
Comment garder un systme en fonctionnement malgr des dfaillances
partielles

Solutions fondamentales
Il faut dfinir des modles
Un modle est une reprsentation du monde rel
Un modle reprsente des lments rels par des lments abstraits
Un mme systme rel peut tre reprsent par des modles diffrents
selon le problme auquel on sintresse
selon le degr de dtail atteint
Tout modle a des limites
Il faut utiliser les modles
Pour observer et comprendre le comportement du systme rel
Pour prdire le comportement du systme rel dans certaines circonstances
Pour aider commander le systme rel (lui imposer un comportement particulier)
13

Bases de lalgorithmique rpartie


1. Ordre, temps, tat dans un systme rparti
2. Observation cohrente
3. Algorithmes rpartis de base

14

Ordre, temps, tat dans un systme


rparti
On veut tre capable de raisonner sur un systme ou une application
Dfinir des prdicats, ce qui implique daccder un tat
Coordonner des activits, ce qui implique de dfinir un ordre

Univers rparti est diffrent:


Pas de mmoire commune (support habituel de ltat)
Pas dhorloge commune (qui dfinit le squencement des

vnements)
Asynchronisme des communications

Pas de borne suprieure sur le temps de transit dun message

Asynchronisme des traitements


Pas de bornes sur le rapport relatif des vitesses dexcution sur deux sites
Consquence de la variabilit de la charge et de labsence (en gnral) de
garanties sur lallocation des ressources
15

Sret et vivacit
On est souvent amen spcifier et vrifier des proprits

dun systme dynamique (voluant dans le temps)


Ces proprits ont deux valeurs:

Sret (safety) : un vnement indsirable narrivera

jamais

Exemples : violation de lexclusion mutuelle incohrence dans les

donnes

Vivacit (liveness) : un vnement dsirable finira par

arriver

Exemples : un message sera dlivr son destinataire


une ressource demande sera rendue disponible
un algorithme se termine

16

Le modle asynchrone (fiable)


Le but est de modliser certains aspects du monde rel
Asynchronisme des communications et des traitements

Cest le modle le plus faible


Les contraintes sont les plus fortes les rsultats sont les

plus gnraux
Bornes sur les cots
Rsultats dimpossibilit

" Le modle peut tre renforc (en levant certaines

contraintes
Exemple : borne suprieure sur le traitement et/ou la dure de

transmission

17

Le modle asynchrone

Les processus (sur diffrents sites) ne

communiquent que par messages


Trois types dvnements

Local (changement de ltat dun processus)


Li la communication
mission dun message
Rception dun message
18

Pas de bornes sur :


la dure de transmission
dun message
le rapport des vitesses
dexcution des
processus

Rception / Dlivrance
On suppose disponible un systme de communication permettant

denvoyer des messages entre processus


Proprits :
1. Un message finit par arriver destination, mais son temps de
transmission nest pas born!; on modlise ainsi une panne (dtecte)
suivie dune ou plusieurs rmission(s)
2. Un message arrive intact (non modifi) ; on suppose que des
mcanismes de dtection / correction derreur sont utiliss
3. Selon le cas, on fera ou non lhypothse que le canal est FIFO entre
deux processus

19

Rception / Dlivrance
Bien distinguer la rception dun message de sa dlivrance son

destinataire

20

vnements, historique, synchronisation


Lexcution dun processus est une suite dvnements (local,

mission, rception) appele historique (ou trace) du processus


pour p1 : e11, e12, e13, , e1k,

Cette suite est ordonne par lhorloge locale du processus p1

Que veut dire synchroniser deux processus ?


Imposer un ordre entre des vnements appartenant ces deux
processus
Exemple : lexclusion mutuelle
fin(C2) prcde deb(C1) ou fin(C1) prcde deb(C2)

21

Relation de prcdence
Le problme :
1) Dfinir une relation globale de prcdence (donner un sens

loprateur prcde )
2) Dfinir un ordre entre deux vnements sur la seule base
dinformations locales
Solution : utiliser le principe de causalit : la cause prcde leffet.

Une relation de prcdence est dite causale si elle est compatible


avec ce principe. Application ici :
Sur un processus : un vnement local ne peut agir localement que

sur les vnements postrieurs


Entre deux processus : lenvoi dun message prcde sa rception
Composition : la relation de causalit est transitive
22

La causalit
Dfinition [Lamport 78] :
e prcde causalement e' ( e e') si :

23

La causalit est potentielle


La relation de prcdence causale ! dfinit en fait une

causalit potentielle (par ngation)


Si e e', on peut simplement dire quon ne viole pas le
principe de causalit en disant que e est la cause de e'. On
peut donc dire que e est une cause potentielle de e', mais pas
que e est effectivement une cause de e' (il faudrait pour cela
analyser la smantique de lapplication)
Certitude que e' ne peut pas tre la cause de e (le futur nagit
pas sur le pass)

24

Dpendance et indpendance causale


Dfinition : pass (ou historique) dun vnement e
hist(e) = lensemble des e' tels que e' e {e}

Seul le pass strict de e peut influencer e


si e' e, alors e' peut influencer e
si (e e), alors il est certain que e' ne peut pas influencer e

Si (e e') et (e' e), on note e || e' et on dit que e et e'

sont causalement indpendants (aucun des deux nappartient au


pass de lautre, aucun des deux ne peut influencer lautre)

25

Problme de datation
Problme : construire un systme de datation des

vnements compatible avec la causalit


Approche : introduire un processus observateur p0 qui est
inform, par message, de tout vnement du systme
La suite des vnements enregistre par p0 est une
observation globale du systme

26

Problme de datation

27

Problme de datation: Validit des


observations
Une observation du systme est un ordonnancement

particulier des vnements du systme.


Une observation est dite valide si pour tout couple
dvnements (e, e') tels que
e e', O(e) prcde O(e'). Sinon, elle est dite invalide (elle viole la
causalit)

28

Problme de datation: Validit des


observations

Canal non FIFO. Lobservation viole la causalit : les

vnements sont observs dans lordre inverse de leur


occurrence
29

Problme de datation: Validit des


observations

La causalit est encore viole :


e11 e22 , mais ces vnements sont observs dans lordre inverse.

Ce phnomne est indpendant de la proprit FIFO

30

Observation valide
Temporairement, lever lhypothse dasynchronisme
temps de transmission born = & et supposer quon dispose

dune horloge HR donnant le temps rel.


Chaque vnement transmis lobservateur est estampill par
HR
une observation de e est le couple (e, HR(e))

31

Observation valide
Au temps t, on dlivre tous les messages ayant des

estampilles < t & dans lordre des estampilles.

32

Caractrisation des observations


valides
Condition de validit:
" Dans un systme o les observations sont ordonnes par
des estampilles H, une condition suffisante de validit est :
e e' H(e) < H(e') : condition de validit faible de
lhorloge (implication dans un seul sens)
Cette condition est trivialement satisfaite par HR

33

Etat Global?
Pas de HR
Temps de propagation des messages nest pas born
Objectif: construire un systme dhorloges assurant une

observation valide, en respectant la condition de validit


faible
Labsence de borne & aura une consquence sur la
compltude, non sur la validit

34

Horloges logiques (Lamport)


Principe:
chaque site i, un compteur HLi valeurs entires
Un vnement e se produisant sur le site i est dat par la
valeur courante de HLi , soit HLi(e)
Un message m mis partir du site i porte une estampille
gale sa date dmission

35

Algorithme de Lamport
Initialisation :
HLi = 0

vnement local :
HLi = HLi + 1

Envoi dun message m :


on envoie (m, Em), avec Em = HLi (aprs incrmentation)

Rception dun message (m, Em) :


HLi = max (HLi, Em) + 1

36

Exemple

HL satisfait la condition de validit faible :


e e' H(e) < H(e')

Mais H(e) < H(e') (e e').


Donc ou bien e' e, ou bien e' || e

37

Ordre strict et total


Lordre nest pas strict. Deux vnements peuvent avoir la

mme estampille: ils sont alors causalement indpendants. Si


on veut un ordre strict, il faut ajouter un critre (en gnral
on prend le numro du processus)
Si e pi, e pj, alors
(HL(e), i) < (HL(e'), j) ssi HL(e) < HL(e') ou (HL(e) = HL(e')

et i<j)

38

Non-dtection des vnements


manquants
p1 reoit des messages des autres processus. On souhaite

quils lui soient dlivrs dans lordre de leurs estampilles.


Dlivrance de m2 (3) et rception de m4 (8). Peut-on le
dlivrer ?

39

Non-dtection des vnements


manquants
Les trois situations sont indistinguables avec les HL
Plus gnralement, si HL(e) < HL(e'), existe-t-il e" tel que e

e" e' ?
Question insoluble. Il sagit dune proprit de vivacit (un
vnement va-t-il arriver ?)
Risque dun vnement ne soit pas dtect.

40

Solution: les messages stables.


un message reu est stable si aucun message portant une

estampille infrieure ne parviendra au destinataire


dlivrer un message que sil est stable
Attendre la rception dun message de tous les metteurs

potentiels. Puis, les dlivrer dans lordre des estampilles.


Canaux FIFO (si non FIFO, cest possible mais plus
complexe)

41

Solution: les messages stables.


Connatre tous les metteurs potentiels
Traiter la non rception dun processus : envoyer un message

avec demande de rponse (ping)


Pas de garantie pour la terminaison quelle soit en temps fini.

(Dans la pratique, on utilise un dlai de garde, avec le risque


dune arrive tardive)

42

Applications des horloges logiques


Mcanismes utilisant une file dattente rpartie
Exclusion mutuelle
Mise jour de copies multiples
Diffusion cohrente

Dtermination de laccs le plus rcent


Invalidation de cache
Mmoire virtuelle rpartie

Aide la synchronisation physique

43

Horloges vectorielles
On cherche caractriser la dpendance causale, en construisant un
systme de datation H qui ait la proprit de validit forte :
e e H(e) < H(e')
Applications
observation, mise au point (attribution dune cause un effet)
communication causale, diffusion causale
contrle et maintien de la cohrence dinformations (Ex: la reprise

aprs une panne)

44

Horloges vectorielles: Fidge, Mattern (1988)


Ide
inclure le pass de lvnement mission dans lestampille H du
message
Principe
Horloge vectorielle / Site
Taille
Nombre de sites

But
Dater les vnements
Identique aux horloges logiques
45

Horloges vectorielles: Fidge, Mattern (1988)


Fonctionnement
Associer un vecteur Vi chaque site Pi
Init : Vi = (0, , 0)
Evnement local Pi
Vi[i] = Vi[i]+1

Emission dun message m estampill par Vm


Vm = Vi de lmetteur

Rception dun message (m, Vm) par Pi


Vi[i] = Vi[i]+1
Vi[j] = max(Vi[i], Vm[j]) pour j = 1..n, j i
46

Exemple

47

HV et structure de treillis

48

Horloges vectorielles

49

Horloges vectorielles

Dterminer le treillis correspondant


50

Horloges matricielles
Synthse
Horloge logique ou scalaire
Rduite un nombre
Ce que Pi connat du systme (Hi)

Horloge vectorielle
Vecteur dhorloges scalaires
Ce que Pi connat de Pj (Hi[j])

Horloge matricielle
Matrice dhorloges
Ce que Pi connat de ce que Pj connat de Pk (Hi[j,k])
51

Horloges matricielles
Principe
Horloge matricielle/Site
nxn
Evnement ei de Pi
Dat par la valeur courante de HMi

Envoi de message
Estampill par Hmi

Smantique
Interprtation de HMi[j,k]
Nombre de messages de Pj vers Pk dont Pi a connaissance

52

Horloges matricielles
Evnement local Pi
HMi[i,i] = HMi[i,i] + 1

Envoi de message vers Pj


HMi[i,i] = HMi[i,i] + 1
HMi[i,j] = HMi[i,j] + 1

53

Horloges matricielles
Rception de (m,Em) par Pj
Dlivr que si tous les messages qui sont causalement

antrieurs lui ont t dlivrs


Em[j,i] = HMi[j,i] + 1
Pour tout k i,j: Em[k,i] = HMi[k,i] (messages des autres sites)

Dlivrance et MAJ horloges


HMi[i,i] = HMi[i,i] + 1
HMi[j,i] = HMi[j,i] + 1
Pour tout k i,j et pour tout l i: HMi[k,l] = max(HMi[k,l], Em[k,l])

54

Exemple

55

Exercice dapplication

56

Exercice dapplication

57

Horloges matricielles
Applications
mise au point fine (exemple : noyau Chorus)
dlivrance causale des messages
gestion de bases de donnes dupliques

58

Horloges matricielles
Optimisations
les horloges matricielles sont coteuses ( O(n2) )
Diverses optimisations ont t proposes
partitionner le systme en sous-systmes (interaction

faible entre sous-systmes) - rduit n


exploiter des caractristiques spcifiques du systme
(synchronisation)
restreindre la profondeur du pass

59

Plan
Introduction:
Dfinition, organisation, proprits,

Partie 1: Bases de lalgorithmique rpartie


1.
2.
3.

Etat dans un systme rparti, ordre, temps,


Observation cohrente
Algorithmique rpartie

Partie2: Tolrance aux pannes et aux fautes


1.

2.
3.
60

Validation atomique
Groupes, diffusion, cohrence
Consensus, prise de dcision

Dfinition
Exclusion mutuelle
Contexte de plusieurs processus s'excutant en parallle
Accs une ressource partage par un seul processus la fois
Exclusion mutuelle en distribu
Accs une ressource partage distante par un seul processus la fois
Processus distribus
Requtes et gestion d'accs via des messages changs entre les processus
Ncessit de mettre en uvre des algorithmes grant ces changes de
messages pour assurer l'exclusion mutuelle

61

Rappel
Un processus est dans 3 tats possibles, par rapport l'accs la

ressource

Demandeur : demande utiliser la ressource, entrer dans la

section
Dedans : dans la section critique, utilise la ressource partage
Dehors : en dehors de la section et non demandeur d'y entrer
62

Changement d'tat par un processus


De dehors demandeur pour demander accder la ressource
De dedans dehors pour prciser qu'il libre la Ressource
Le passage de l'tat demandeur l'tat dedans est gr par le

systme et/ou l'algorithme de gestion d'accs la ressource

63

Plusieurs grandes familles de mthodes


Contrle par un serveur qui centralise les demandes

d'accs la ressource partage

Contrle par jeton


Un jeton circule entre les processus et donne l'accs la ressource
La gestion et l'affectation du jeton et donc l'accs la ressource
est faite par les processus entre eux
Deux approches : jeton circulant en permanence ou affect la
demande des processus
Contrle par permission
Les processus s'autorisent mutuellement accder la ressource
64

Plusieurs grandes familles de mthodes


Contrle par un serveur centraliseur
Avantages
Trs simple mettre en oeuvre
Simple pour grer la concurrence d'accs la ressource
Inconvnients
Ncessite un lment particulier pour grer l'accs
Potentiel point faible, goulot d'tranglement

65

Plusieurs grandes familles de mthodes


Contrle par jeton
Principe gnral
Un jeton unique circule entre tous les processus
Le processus qui a le jeton est le seul qui peut accder la section
critique
Versions de lalgorithme
Anneau sur lequel circule le jeton en permanence
Jeton affect la demande des processus

66

Plusieurs grandes familles de mthodes


Contrle par jeton sur anneau
un processus reoit le jeton
S'il est dans l'tat demandeur : il passe dans l'tat dedans et accde

la ressource
S'il est dans l'tat dehors, il passe le jeton son voisin
Quand le processus quitte l'tat dedans, il passe le jeton son
voisin

67

Contrle par jeton sur anneau


Avantages
Trs simple mettre en uvre
Intressant si nombreux processus demandeurs de la ressource
quitable en terme de nombre d'accs et de temps d'attente
Aucun processus n'est privilgi

Inconvnients
Ncessite des changes de messages (pour faire circuler le jeton) mme si aucun
site ne veut accder la ressource
Temps d'accs la ressource peut tre potentiellement long
Si le processus i+1 a le jeton et que le processus i veut accder la ressource et
est le seul vouloir y accder, il faut que le jeton fasse tout le tour de l'anneau

68

Contrle par jeton avec communication


entre processus
Soit N processus avec un canal bi-directionnel entre chaque processus
Canaux fiables mais pas forcment FIFO
Localement, un processus Pi possde un tableau nbreq, de taille N
Pour Pi, nbreq [ j ] est le nombre de requtes d'accs que le processus Pj a

fait et que Pi connat (par principe il les connat toutes)


Le jeton est un tableau de taille N
jeton [ i ] est le nombre de fois o le processus Pi a accd la ressource
La case i de jeton n'est modifie que par Pi quand celui-ci accde la
ressource
69

Contrle par jeton avec communication entre processus


(suite)
Initialisation
Pour tous les sites Pi : j [ 1 .. N ] : nbreq [ j ] = 0

Jeton j [ 1 .. N ] : jeton [ j ] = 0
Un site donn possde le jeton au dpart

Quand un site veut accder la ressource et n'a pas le jeton


Envoie un message de requte tous les processus

70

Contrle par jeton avec communication entre processus


(suite)
Quand processus Pj reoit un message de requte venant de Pi
Pj modifie son nbreq localement : nbreq [ i ] = nbreq [ i ] + 1
Pj mmorise que Pi a demand avoir la ressource
Si Pj possde le jeton et est dans l'tat dehors
Pj envoie le jeton Pi

Quand processus rcupre le jeton


Il accde la ressource (passe dans l'tat dedans)

71

Contrle par jeton avec communication entre processus


(suite)
Quand Pi libre la ressource (passe dans l'tat dehors)
Met jour le jeton : jeton [ i ] = jeton [ i ] + 1

Parcourt nbreq pour trouver un j tel que :


nbreq [ j ] > jeton[j]
Une demande d'accs la ressource de Pj n'a pas encore t

satisfaite : Pi envoie le jeton Pj


Si aucun processus n'attend le jeton : Pi le garde

72

Contrle par Permission


Un processus demande l'autorisation un sous-ensemble
donn de tous les processus
Deux modes:
Permission individuelle : un processus peut donner sa
permission plusieurs autres la fois
Permission par arbitre : un processus ne donne sa permission

qu' un seul processus la fois

Les sous-ensembles sont conus alors tel qu'au moins un processus

soit commun 2 sous-ensembles : il joue le rle d'arbitre

73

Permission individuelle
un processus peut donner sa permission plusieurs

autres la fois

Chaque processus demande l'autorisation tous les

autres (sauf lui par principe)

Liste des processus interroger par le processus Pi pour accder

la ressource : Ri = { 1, ... , N } { i }

74

Permission individuelle
Se base sur une horloge logique (Lamport) pour garantir le

bon fonctionnement de l'algorithme

Ordonnancement des demandes d'accs la ressource


Si un processus ayant fait une demande d'accs reoit une demande

d'un autre processus avec une date antrieure la sienne, il donnera


son autorisation l'autre processus
passera donc aprs lui puisque l'autre processus fera le contraire

75

Algorithme de [Ricart & Agrawala, 81]


Chaque processus gre les variables locales suivantes:

Une horloge Hi
Une variable dernier qui contient la date de la dernire demande d'accs la

ressource
L'ensemble Ri
Un ensemble d'identificateurs de processus dont on attend une rponse :
attendu
Un ensemble d'identificateurs de processus dont on diffre le renvoi de
permission si on est plus prioritaire qu'eux : diffr
Initialisation
Hi = dernier = 0
diffr = , attendu = Ri
76

Algorithme de [Ricart & Agrawala, 81]


Si un processus veut accder la ressource, il excute
Hi = Hi + 1
dernier = Hi
attendu = Ri
Envoie une demande de permission tous les processus de Ri avec estampille ( Hi, i )
Se met alors en attente de rception de permission de la part de tous les processus dont
l'identificateur est contenu dans attendu
Quand l'ensemble attendu est vide, le processus a reu la permission de tous les autres
processus
Accde alors la ressource partage
Quand accs termin
Envoie une permission tous les processus dont l'id est dans diffr
diffr est ensuite rinitialis (diffr = )
77

Algorithme de [Ricart & Agrawala, 81]


Quand un processus Pi reoit une demande de permission de la

part du processus Pj contenant l'estampille (H, j)

Met jour Hi : Hi = max (Hi, H)


Si Pi pas en attente d'accs la ressource : envoie permission Pj
Sinon, si Pi est en attente d'accs la ressource
Si Pi est prioritaire : place j dans l'ensemble diffr

On lui enverra la permission quand on aura accd la ressource


Si Pj est prioritaire : envoi permission Pj,
Pj doit passer avant moi, je lui envoie ma permission
La priorit est dfinie selon la datation des demandes d'accs la ressource de chaque
processus
Le processus prioritaire est celui qui a fait sa demande en premier
Ordre des dates : l'ordre << de l'horloge de Lamport :
( dernier, i ) << ( H, j ) si ( ( dernier < H ) ou ( dernier = H et i < j ) )

78

Permission par arbitre


Un processus ne donne qu'une permission la fois
Il redonnera sa permission un autre processus quand le processus a

qui il avait donn prcdemment la permission lui a indiqu qu'il a


fini d'accder la ressource

La sret est assure car


Les sous-ensemble de processus qui un processus demande la

permission sont construits tel qu'ils y ait toujours au moins un


processus commun 2 sous-ensemble
Un processus commun 2 sous-ensembles est alors arbitre

Comme il ne peut donner sa permission qu' un seul processus, les processus

de 2 sous-ensembles ne peuvent pas tous donner simultanment la permission


2 processus diffrents
C'est donc ce processus commun qui dtermine qui donner la ressource
79

Algorithme de [Maekawa, 85]


Chaque processus Pi possde un sous-ensemble Ri d'identificateurs

de processus qui Pi demandera l'autorisation d'accder la


ressource

i,j [ 1..N ] : Ri Rj
Deux sous-ensembles de 2 processus diffrents ont obligatoirement au moins un

lment en commun (le ou les arbitres) Cela rend donc inutile le besoin de
demander la permission tous les processus, d'o les sous-ensembles Ri ne
contenant pas tous les processus

i : | Ri | = K
Pour une raison d'quit, les sous-ensembles ont la mme taille pour tous les

processus

i : i est contenu dans D sous-ensembles


Chaque processus joue autant de fois le rle d'arbitre qu'un autre processus

80

Fonctionnement de l'algorithme
Chaque processus possde localement
Une variable vote permettant de savoir si le processus a dj vot (a

dj donn sa permission un processus)


Une file file d'identificateurs de processus qui ont demand la
permission mais qui on ne peut la donner de suit
Un compteur rponses du nombre de permissions reues

Initialisation
tat non demandeur, vote = faux et file = , rponses = 0

81

Fonctionnement de l'algorithme (Suite)


Quand processus Pi veut accder la ressource
rponses = 0
Envoie une demande de permission tous les processus de Ri
Quand rponses = | Ri |, Pi a reu une permission de tous, il accde alors
la ressource
Aprs l'accs la ressource, envoie un message tous les processus de
Ri pour les informer que la ressource est libre
Quand processus Pi reoit une demande de permission de la part du processus
Pj
Si Pi a dj vot (vote = vrai) ou accde actuellement la ressource : place
l'identificateur de Pj en queue de file
Sinon : envoie sa permission Pj et mmorise qu'il a vot
vote = vrai
82

Fonctionnement de l'algorithme (Suite)


Quand Pi reoit de la part du processus Pj un message lui indiquant que
Pj a libr la ressource
Si file est vide, alors vote = faux
Pi a dj autoris tous les processus en attente d'une permission de sa

part
Si file est non vide
Retire le premier identificateur (disons k) de la file et envoie Pk

une permission d'accs la ressource


vote reste vrai

83

lection
Problme
Parmi un ensemble de processus, en choisir un et un

seul (et le faire connatre tous)

scurit : un seul processus lu


vivacit : un processus doit tre lu en temps fini

Llection peut tre dclenche par un processus

quelconque, ventuellement par plusieurs processus


Lidentit de llu est en gnral indiffrente, on peut
donc (par exemple) choisir le processus qui a le plus
grand numro
Difficult : des processus peuvent tomber en panne
pendant llection
84

lection
Utilit
Rgnration dun jeton perdu : un jeton et un seul

doit tre recr


Dans les algorithmes de type matre-esclave : lire
un nouveau matre
en cas de dfaillance du matre courant

85

lection
Bully algorithm
Hypothses
Rseau fiable et synchrone
Identit des processus connue par tous

Principe
Bas sur la recherche dun min dun ensemble
Demande dlection par inondation
Rponse ceux qui ont un numro infrieur
Processus lu sil ne reoit aucune rponse

86

lection: algorithme de la brute (bully)

87

Election sur un anneau (Chang et Roberts)

88

Election sur un anneau (Chang )


Candidature du site Pi
candidat i:= true;
envoyer_suivant(lection,i);
Rception sur Pi du message (ELECT,k)
Switch
k > i : envoyer_suivant(lection,k);
k<i:

if candidati:=false then
candidat i:=true;
envoyer_suivant(lection,i);
end;

k = i : Envoyer (ALL, ELECTED, i) /* le site i a t lu */

89

Terminaison (1)
Modle de calcul rparti (rappel)
Ensemble de processus communiquant par messages ; tat actif ou passif
Programme (cyclique) de chaque processus :
loop
1. attendre un message (passage temporaire ltat passif)
2. excuter un calcul local en rponse ce message
3. le calcul peut comporter lenvoi de messages dautres processus
ou la terminaison du processus (passage dfinitif ltat passif)
end

Problme de la terminaison
Vrifier que le calcul est achev
Cela implique deux conditions sur ltat global du systme
Tous les processus sont au repos (passifs)
Aucun message nest en transit
En effet larrive dun message en transit peut relancer le calcul

90

Terminaison (2)
Mthodes pour dtecter la terminaison

1. Mthode gnrale : analyse de ltat global


La terminaison est une proprit stable
On peut donc la dtecter par examen dun tat global
enregistr
2. Mthodes spcifiques : applicables un schma
particulier de communication
Sur un anneau
Sur un arbre ou un graphe orient (avec arbre
couvrant)

91

Terminaison sur un anneau


Principe :
visiter lanneau (dans le sens de la

communication) et vrifier que tous


les sites sont passifs (aprs un tour
complet)
Difficult :
un message mis aprs le passage du
visiteur (et non visible par celui-ci)
peut venir ractiver (derrire lui) un
site trouv passif

92

Terminaison sur un anneau (Misra)


Chaque site a une couleur blanc ou noir

(initialement blanc)
noir = a t actif depuis le dernier passage du jeton,
blanc = noir
Le jeton porte un compteur des sites trouvs passifs
Terminaison = tous les sites blancs aprs 1 tour

93

Lalgorithme de Misra
procdures dun site :
dbut dun traitement (rception de message)
tat := actif;
couleur := noir; /* couleur de lactivit dun site */

fin dun traitement


tat:= passif;
if jeton_present then
couleur := blanc /* couleur de linactivit dun site */
envoyer_jeton(1);
jeton_present:=false;

end;

94

rception du jeton(j)
if tat :=actif then /* site actif */
jeton_present :=true;
else
if j=N and couleur=blanc then /* site non actif */
terminaison_dtecte;
else
if couleur=blanc then
envoyer_jeton(j+1);
else
couleur:=blanc;
envoyer_jeton(1);
end;
end;
95

End;

Etat dun Systme Rparti


Notion de Coupure

tat dun systme rparti

97

Coupures

98

Coupures cohrentes

99

Proprits des coupures cohrentes

100

Caractrisation des coupures


cohrentes

101

Partie2 :
Tolrance aux fautes
Introduction, techniques de base

Plan
Dfinition de base
Sret de fonctionnement
Dfaillances
Degr de gravit des dfaillances

Modle
Panne franche
Panne par omission
Panne de temporisation
Pannes arbitraires (ou byzantines)

Mesures de fiabilit et disponibilit


Analyse des dfaillances
Comment assurer la sret de fonctionnement
Tolrance aux fautes

tapes
Techniques

Traitement des erreurs


Recouvrement
Compensation

103

Dfinition de base
Service
Ensemble de fonctions dfini par une interface, contrat
entre le fournisseur et lutilisateur du service.
Proprit dun systme informatique permettant ses
utilisateurs de placer une confiance justifie dans le service
que dlivre le systme

104

Proprits attendues dun service


Proprits fonctionnelles (dfinies dans les spcifications

dinterface)
validit (correctness) : le systme est conforme ses

spcifications proprits de sret et de vivacit


Proprits non fonctionnelles
performances ; sret de fonctionnement

105

Sret de fonctionnement
(dependability)
Fiabilit (reliability): le systme est en tat (continu) de rendre le

service

Mesure : probabilit (fonction du temps t) que le systme ne soit pas

dfaillant entre le temps 0 et le temps t

Disponibilit (availability) : le service est disponible en permanence


Mesure : fraction du temps (sur une priode dtermine) durant laquelle le

systme fournit le service

Scurit (au sens safety) : un mauvais fonctionnement du systme na

pas dincidence catastrophique sur son environnement

Scurit (au sens security) : le systme assure la confidentialit et

lintgrit des informations ainsi que le contrle de laccs au service


le service est effectivement accessible aux utilisateurs autoriss, non aux

autres

106

Dfaillances
Dfinition
Un systme (ou composant) est sujet une dfaillance (failure)

lorsque son comportement nest pas conforme sa spcification


Synonyme de dfaillance : panne

Le systme ou composant est considr comme une

bote noire; on ne regarde que son comportement


global, observ linterface
On peut dfinir diffrents degrs de gravit de
dfaillance en fonction de leur impact sur la sret
de fonctionnement
107

Degr de gravit des dfaillances


Modle: bote noire avec messages entrants et sortants

Types de Pannes:
Panne franche
Panne par omission
Panne temporisation
Pannes arbitraires (ou byzantines)

108

Types de Pannes
Panne franche
Dit aussi : arrt sur dfaillance (fail stop)
ou bien le systme fonctionne, et
donne un rsultat correct
ou bien il est en panne (dfaillant), et
ne fait rien
Cest le cas le plus simple, et on essaie de sy
ramener (au besoin en forant larrt dun
composant ds quune erreur y a t dtecte
: technique fail fast)
Pannes de temporisation
Les dviations par rapport aux spcifications
concernent uniquement le temps (par
exemple temps de raction un
vnement)
109

Panne par omission


Le systme perd des messages entrants
(omission en rception), sortants (omission en
mission), ou les deux. Il ny a pas dautres
dviations par rapport aux spcifications
Ce modle peut servir reprsenter des
dfaillances du rseau
Plus difficile traiter que la panne franche

Pannes arbitraires (ou byzantines)


Le systme peut faire nimporte quoi (y compris
avoir un comportement malveillant)
Hypothse parfois ncessaire pour des systmes trs
haute fiabilit dans un environnement hostile
(nuclaire, spatial)
Traitable, mais ncessite une redondance leve

Mesures de fiabilit et disponibilit


Mesure de la fiabilit
Probabilit R(t) que le systme ne soit pas dfaillant entre 0 et t
Temps moyen jusqu la prochaine panne : E(R(t)) = MTTF (Mean

Time To Failure)

Mesure de la disponibilit
Disponibilit instantane : Probabilit A(t) que le systme soit

disponible (fournisse un service correct) linstant t


Disponibilit moyenne a = E(A(t)) : fraction moyenne du temps o le
systme est disponible (sur une priode donne)
Rparation
Rparer un systme en panne : le remettre en tat de rendre un

service correct
Mesure : temps moyen de rparation : MTTR (Mean Time To Repair)
110

Analyse des dfaillances


De lerreur la dfaillance
Une erreur est susceptible de provoquer une dfaillance, mais ne
la provoque pas ncessairement (ou pas immdiatement)
Parce quil y a une redondance interne suffisante pour que le systme

continue de fournir le service


Parce que la partie errone de ltat nest pas utilise pour telle ou
telle fonction

Une erreur est latente tant quelle na pas provoqu de dfaillance


Le temps entre lapparition de ltat derreur et la dfaillance est

le dlai de latence

plus le dlai de latence est long, plus la recherche des causes dune

dfaillance est difficile

111

Comment assurer la sret de


fonctionnement
1.

vitement des fautes : vise empcher loccurrence de


fautes
Par la prvention
Analyser les causes potentielles de fautes
Prendre des mesures pour les liminer (pas toujours possible) ou rduire
leur probabilit
Par lvaluation
Prvoir les fautes (et les mesures pour y faire face)
Prvision souvent statistique

Par la vrification
Avant mise en route du systme : examiner les fautes restantes, et
liminer celles que lon peut liminer
112

Comment assurer la sret de


fonctionnement
2. Tolrance aux fautes : vise prserver le service malgr
loccurrence de fautes
Par la redondance
du matriel, et/ou
des traitements, et/ou
des donnes.

113

Tolrance aux fautes: tapes


Dtection
Dcouvrir lexistence dune erreur (tat incorrect) ou dune

dfaillance (comportement incorrect)

Localisation
Identifier le point prcis (dans l'espace et le temps) o lerreur (ou

la dfaillance) est apparue

Isolation
Confiner lerreur pour viter sa propagation dautres parties du

systme

Rparation
Remettre du systme en tat de fournir un service correct
114

Traitement des erreurs


Recouvrement (error recovery)
Remplacer ltat derreur par un tat correct
Ncessite dtection de lerreur (identification de la partie
incorrecte de ltat),
Deux techniques de recouvrement
reprise (backward recovery)
poursuite (forward recovery)

Compensation (error masking)


Ltat possde une redondance interne suffisante pour
dtecter et corriger lerreur (les tests externes de
vraisemblance sont inutiles)
115