Vous êtes sur la page 1sur 116

Cours de Systmes Rpartis

ISI 2 ingnieurs
AU 2014/15

Plan
Introduction:
Dfinition, organisation, proprits,

Partie 1: Bases de lalgorithmique rpartie

Etat dans un systme rparti, ordre, temps,


2. Observation cohrente
3. Algorithmique rpartie
1.

Partie2: Tolrance aux pannes et aux fautes

Validation atomique
2. Groupes, diffusion, cohrence
3. Consensus, prise de dcision
1.

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
5

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
6

Organisation dun
systme rparti

n schma de base : lintergiciel (middleware)

Lintergiciel sert de super-systme dexploitation pour les


applications

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
8
Le systme reste performant lorsque sa taille

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) (service de base)
le World Wide Web
(infrastructure)
divers services sur lInternet (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 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
12

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
13 circonstances

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

Pas de bornes sur :


la dure de
communiquent que par messages
transmission dun
Trois types dvnements
message
Local (changement de ltat dun processus)
le rapport des
Li la communication
vitesses
mission dun message
dexcution des
Rception dun message
processus
Les processus (sur diffrents sites) ne

18

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

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)
43

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

44

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


Vi[i] = Vi[i]+1
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
45

Exemple

46

HV et structure de treillis

47

Horloges vectorielles

48

Horloges vectorielles

Dterminer le treillis correspondant


49

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])
50

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
51

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

52

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])

53

Exemple

54

55

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

56

Exercice dapplication
On considre l'excution parallle reprsente par
la figure ci-dessous, dans laquelle :
les lignes horizontales reprsentent les chelles
de temps de processus.
eij reprsente le jme vnement observable sur
le processus Pi.
les flches reliant les vnements de processus
distincts sont des changes de messages
TAF:
Appliquer lalgorithme de lhorloge matricielle sur
les deux systmes rpartis suivants.
57

Exercice dapplication

58

59

Exercice dapplication

1. Donner deux couples d'vnements


concurrents.
2. Quels sont les vnements causalement
dpendants de e11 ?
3. Donner des exemples dvnements
causalement indpendants.
4. Proposer un modle de datation relatif cet
exemple.
5. Provoquer un situation de non dlivrance
60

61

Etat dun Systme Rparti


Notion de Coupure

tat dun systme rparti

Coupures

Coupures cohrentes

Proprits des coupures


cohrentes

Plan
Introduction:
Dfinition, organisation, proprits,

Partie 1: Bases de lalgorithmique rpartie

Etat dans un systme rparti, ordre, temps,


2. Observation cohrente
3. Algorithmique rpartie
1.

Partie2: Tolrance aux pannes et aux fautes

Validation atomique
2. Groupes, diffusion, cohrence
3. Consensus, prise de dcision
1.

67

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
68
grant ces changes de messages pour assurer

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

69

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

70

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
71

Plusieurs grandes familles de


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

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

73

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

74

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
75

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

76

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

77

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)

78

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

79

Contrle par Permission


Un processus demande l'autorisation un sousensemble 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

80

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 }

81

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

82

passera donc aprs lui puisque l'autre processus fera le


contraire

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

83

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 = )
84

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) +1


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

85

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))

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 sousensemble
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
86

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

87

i : i est contenu dans D sous-ensembles


Chaque processus joue autant de fois le rle d'arbitre

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 = ,
88

rponses = 0

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
89

vote = vrai

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
90

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

lection
Utilit et domaines dapplication
Regnration dun jeton perdu : un

jeton et un seul doit tre recr


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

lection
Algorithme de base: Bully algorithm
Algorithme de la brute
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
le Processus est lu sil ne reoit aucune

rponse

lection: algorithme de la brute


(bully)

Election sur un anneau (Chang et Roberts)

95

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

rparti

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 (Partie 1 du cours)
2. Mthodes spcifiques : applicables un
schma particulier de communication
Sur un anneau
Sur un arbre ou un graphe orient (avec
arbre couvrant)

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

Terminaison sur un anneau


(Misra)
Une variable globale couleur =blanc ou

noir (initialement blanc)


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

Terminaison sur un anneau


(Misra)

Misra (1983)
dbut dun traitement (rception de message)
tat := actif;
couleur := noir;
fin dun traitement
tat:= passif;
if jeton_present then
couleur := blanc
envoyer_jeton(1);
jeton_present:=false;

end;
101

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;

End;
102

Tolrance aux pannes et


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

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

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

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 effectivementaccessible aux utilisateurs autoriss, non

aux autres

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

Degr de gravit des dfaillances


Modle: bote noire avec messages entrants et

sortants
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)

Types de Pannes
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)

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

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

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.

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

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.

Vous aimerez peut-être aussi