cole Doctorale de Grenoble

Master 2 Recherche Systmes et Logiciel

Motivation et objectifs
! Excution de transactions rparties
" Les transactions sont un outil de base pour la tolrance aux fautes
" Transaction = suite dactions A = (A1 ; A2 ; ; An) possdant les
proprits ACID
# Atomicit, Cohrence, Isolation, Durabilit (persistence)
" Dans une application rpartie, les actions peuvent sexcuter sur
des sites diffrents, do ncessit dune coordination

Validation atomique

! Validation
" La validation (opration commit) est une opration cl de
lexcution dune transaction (elle rend les modifications
dfinitives)
" Nous allons examiner comment cette opration est ralise dans
un systme rparti
" Intrt
# pratique (ralisation de transactions rparties)
# thorique (rsultats dimpossibilit ; relations avec autres
protocoles)

Sacha Krakowiak
Universit Joseph Fourier
Projet Sardes (INRIA et IMAG-LSR)
http://sardes.inrialpes.fr/people/krakowia

2003-2004, S. Krakowiak

Plan

Prambule : le paradoxe des gnraux (1)

! Un premier rsultat dimpossibilit

! Introduction la validation

" Si le systme de communication perd des messages de manire

indtectable, il est impossible de raliser un protocole daccord en
un nombre fini dtapes

" Prambule sur la communication

" Spcification du problme

! Solutions historiques

! Le problme de lattaque coordonne

" Validation deux phases : le problme du blocage

A (1500)

" Validation trois phases

B (1500)

! Solutions utilisant la diffusion

C (2 000)

" Spcification du protocole de diffusion (UTRB)

" Ralisation de la validation
" Ralisation du protocole de diffusion

A ! B : message 36 : on attaque demain 5h00

B ! A : bien reu 36
A ! B : bien reu bien reu 36

! [ voir plus tard] Relations entre validation et consensus

J. Gray, Notes on Database Operating Systems, in Operating Systems, An Advanced Course,

Lecture Notes in Computer Science, nr 60, Springer-Verlag (1978)
2003-2004, S. Krakowiak

2003-2004, S. Krakowiak

Le paradoxe des gnraux (2)

Le paradoxe des gnraux (3)

Il nexiste pas de protocole rsolvant le problme de laccord avec

un nombre fini de messages si la communication nest pas fiable

Comment vivre avec dans la pratique ?

Rappelons lhypothse de dfaillance : le systme de communication
perd des messages de manire indtectable

Supposons quil existe de tels protocoles, et considrons celui qui ralise

laccord en utilisant le nombre de message minimal, soit n

En pratique, on essaie de dtecter la perte de messages, soit par signal

du systme de communication lmetteur, soit en gnral au moyen
dun dlai de garde sur laller-retour (hypothse de synchronisme)

Supposons que le dernier message soit de B vers A :

A ! B : messagen1
B ! A : messagen

Exemple concret : laccord confirm

Puisque B ne recevra plus de messages, B a pris une dcision avant

lenvoi de messagen
Puisque le protocole doit fonctionner en cas de perte de messages, la
dcision de A ne doit pas dpendre du contenu de messagen

Le protocole dtablissement de liaison de TCP utilise laccord confirm

(3 messages) :
A ! B : demande
B ! A : accord
A ! B : accord confirm

Mais alors messagen ne sert rien, et on peut le supprimer.

Ceci est contradictoire avec le fait que le protocole est minimal.
2003-2004, S. Krakowiak

Chaque partenaire voit donc un aller-retour

5

2003-2004, S. Krakowiak

Le problme de la validation (commitment)

Spcifications de la validation

! Motivations

Chaque processus contribue la dcision par un vote (OUI ou NON). Un

processus qui vote OUI est prt rendre permanentes ses modifications. Le
protocole doit avoir les proprits suivantes :

" Pour terminer une transaction, il faut dcider de son issue!: validation
(commit) ou annulation (abort)
" La validation rend les modifications dfinitives!; lannulation ramne les
processus leur tat avant transaction (proprit datomicit)

Validit : La dcision est soit valider, soit annuler

" La dcision est prise linitiative dun participant quelconque, et doit

vrifier diffrentes proprits (cf plus loin) pour satisfaire aux spcifications
des transactions

Intgrit : Tout processus dcide au plus une fois (une dcision est
dfinitive)
Accord uniforme : Tous les processus (corrects ou non) qui dcident
prennent la mme dcision

! Hypothses
" La communication est fiable (messages dlivrs sans altration)!et
synchrone (une borne est connue sur le temps de transmission des
messages, ainsi que sur les vitesses relatives des processus)

Justificationx : Si la dcision est valider, alors il y a au moins x processus

qui ont vot OUI [diffrentes variantes du protocole selon choix de x ; en
pratique, x = n (le nombre total de processus)]

N.B. il suffit de faire cette hypothse sur une dure couvrant celle de la transaction

" Les processus peuvent subir des pannes franches. Un processus en panne
peut tre rpar et rintgrer la transaction. Un processus est dit correct sil
nest jamais tomb en panne

Obligationx : Si x processus votent OUI, et si ces x processus sont

corrects, alors la valeur dcide est valider [en pratique x = n]

" Chaque processus peut crire des donnes en mmoire stable, ou

permanente, qui survit aux dfaillances
2003-2004, S. Krakowiak

Terminaison : tout processus correct dcide au bout dun temps fini

7

2003-2004, S. Krakowiak

Remarques sur les spcifications

Un peu dhistoire
Solution initiale : Gray (1978), protocole de validation 2 phases (2-phase
commit, ou 2PC)

Les dcisions valider et annuler ne sont pas symtriques. Il nest pas

ncessaire que tous les processus aient vot NON pour dcider
dannuler

Le protocole 2PC peut ne pas se terminer (mme avec communication

synchrone). Recherche dun protocole de validation non bloquante (NonBlocking Atomic Commitment, ou NBAC)

Limplication de la proprit de justification nest pas symtrique : la

dcision dannuler peut tre prise mme si tous les processus ont
vot OUI

Protocole de validation non bloquant 3 phases (3PC) (Skeen, 1982)

Exemple : tous les processus ont vot OUI ; un processus tombe en

panne avant que la dcision de valider ne soit prise

Protocole non bloquant utilisant la diffusion uniforme temporise

(Babaoglu - Toueg, 1992)

La proprit dobligation est ncessaire pour exclure les solutions

triviales (par exemple : tous les processus dcident toujours
dannuler)

Relations entre validation et consensus (dtails plus tard)

La validation est plus difficile que le consensus, mais une forme plus
faible (pratiquement acceptable) de validation se ramne au consensus
avec le protocole Paxos (Lamport)
avec dtecteurs de pannes imparfaits (Chandra - Toueg)

Lhypothse de la communication fiable et synchrone exclut le

partitionnement du rseau (le rseau est maintenu connexe malgr
les pannes de site)

2003-2004, S. Krakowiak

2003-2004, S. Krakowiak

10

Protocole 2 phases (2PC)

Un processus coordinateur interroge

tous les processus (participants)
Chaque participant envoie son vote
au coordinateur
Quand le coordinateur a reu tous les
votes, il prend sa dcision :
tous oui : valider
autrement : annuler
Le coordinateur envoie la dcision
tous les participants ; chacun dcide
conformment ce message

2PC : dtection de dfaillances

coordinateur participant
p0
pi

coordinateur
p0

enqute ?

participant
pi

enqute ?

enqute ?

ph. 1
vote

vote

vote

pas
tous
OUI

tous
OUI

coordinateur participant
p0
pi

Participant : si le
coordinateur na pas
rpondu aprs le dlai de
garde, on suppose quil
est en panne

enqute ?

vote

ph. 2

valider

annuler

dlai de garde
2" + #

temps

Coordinateur : si des rponses

manquent aprs le dlai de garde,
dcision = annuler
(tous les sites nont pas vot OUI)

Noter que le coordinateur et chaque participant voient un aller-retour

(dlai de garde utilisable)
2003-2004, S. Krakowiak

coordinateur participant
p0
pi

11

2003-2004, S. Krakowiak

dlai de
garde 2" + T

Le participant essaie de dterminer si une

dcision a t prise, en interrogeant les autres
participants (un autre participant peut avoir
reu une rponse du coordinateur)
12

2PC : scnario de blocage

2PC : scnario de blocage (2)

Entre le moment o il a vot OUI et le moment o il

reoit une rponse du coordinateur, un participant
est dans une zone dincertitude (un autre participant
peut se trouver soit en phase de validation soit en
phase dannulation, et les deux issues sont possibles)

coordinateur participant
p0
pi
enqute ?
vote
OUI

La possibilit de blocage provient de lincertitude sur ltat global

(pas de connaissance partage)
tat pi
vot (OUI)

vot (NON)

vot (OUI)

possible

possible

vot (NON)

possible

possible

Cela peut conduire un scnario de blocage :

zone
dincertitude

pi a vot OUI et se trouve dans la zone

dincertitude
Le coordinateur tombe en panne aprs avoir
envoy une dcision valider ou annuler
certains participants
ces participants tombent en panne leur tour

tat pj

Une dcision a t prise mais pi (correct) na aucun

moyen de la connatre (au moins jusqu' un ventuel
redmarrage du coordinateur)
2003-2004, S. Krakowiak

dcid
valider
dcid
annuler

enqute ?

2003-2004, S. Krakowiak

enqute ?

ph. 1
vote

possible

possible

14

Raction lcoulement du dlai de garde

1. Dcider annuler
2. lire un nouveau coordinateur
3. Rien
4. lire un nouveau coordinateur

coordinateur participant
p0
pi
enqute ?

vote

vote

prparer
ack

pas
tous
OUI

Le nouveau coordinateur interroge les participants

certains annuls : dcider annuler
certains valids : dcider valider
tous incertains : dcider annuler
certains prts mais aucun valid :
reprendre lenvoi du message prparer

annuler

tous
ack

ph. 3

possible

Reprise aprs dfaillance

si navait pas vot : annuler
si avait dcid : continuer avec dcision prise
si incertain : consulter autres participants

valider

15

2003-2004, S. Krakowiak

prparer
ack

incertain

N.B. sil ny a pas de perte de messages,

alors les acquittements sont redondants

possible

3PC : dtection de dfaillances

coordinateur participant coordinateur participant

p0
pi
p0
pi

ph. 1

possible

2003-2004, S. Krakowiak

Protocole 3 phases (3PC)

tous
OUI

possible

possible

dcid
annuler

la suite dun vote OUI, toutes les possibilits restent ouvertes

13

Le coordinateur interroge les participants

Chaque participant renvoie son vote
Si la dcision est annuler, elle est envoye
aux participants (comme en 2PC)
Sinon, le coordinateur envoie prparer
Chaque participant renvoie un
acquittement
Quand il a reu tous les acquittements, le
coordinateur renvoie valider

possible

dcid
valider

2
prt

3
valider

4
valid
16

3PC : connaissance partage

Validation utilisant la diffusion

Il ny a pas dtat o pi soit incertain (aprs vote OUI) et pj ait dcid valider.
Le protocole 3PC introduit une connaissance partage.
2PC : un processus qui dcide valider sait que tous ont vot OUI
3PC : un processus qui dcide valider sait (en outre) que tous savent
que tous ont vot OUI
tat pi

tat pj

vot (OUI)

vot (NON)

vot (OUI)

possible

possible

vot (NON)

possible

possible

prt

possible

dcid
valider
dcid
annuler

possible

prt

dcid
valider

possible

! Motivations
" Le problme de la connaissance partage identifi dans 3PC peut
tre abord en utilisant un protocole de diffusion
" Il existe de nombreux protocoles de diffusion (tudis plus tard
dans le cours). Les spcifications de chaque protocole doivent tre
adaptes aux hypothses de dfaillance et aux besoins spcifiques
dutilisation

dcid
annuler

! Dmarche

possible

" Dfinir un protocole gnrique de validation utilisant la diffusion

# gnrique : acceptant un protocole de diffusion quelconque
" Spcifier un protocole de diffusion ayant les proprits souhaites
" Examiner la ralisation de la validation avec ce protocole
" Examiner la ralisation du protocole de diffusion

possible
possible

possible

possible

possible

possible

possible

2003-2004, S. Krakowiak

17

2003-2004, S. Krakowiak

Un protocole gnrique de validation (1)

18

Un protocole gnrique de validation (2)

Schma densemble dune transaction

Coordinator

Participant

Initialisation (par un processus quelconque)

send [transaction, !c, participants] to all participants

send [VOTE_REQUEST] to all

set-timeout (local_clock + 2")
wait-for (receipt of votes from all)
if (all votes YES) then
broadcast(commit, participants)
else broadcast(abort, participants)
on-timeout
broadcast(abort, participants)

set-timeout (Cknow + $c + ")

wait-for (receipt of VOTE_REQUEST from coord.)
send (vote) to coordinator
if (vote = NO) then
decide (abort)
else
set-timeout (Cknow + $c + 2" + $b )
wait-for(delivery of decision messages)
if (decision mess. is abort) then
decide (abort)
else decide (commit)
on-timeout // coordinator failed
decide according to termin. protocol
on-timeout
decide (abort)

Programme des participants (y compris initiateur)

upon (receipt of [transaction, !c, participants])
Cknow = local clock
// perform operations requested by transaction
if (willing and able to make updates permanent) then
vote = YES
else
vote = NO
// decide commit or abort for the transaction
atomic_commitment(transaction, participants)

La structure est la mme que

celle du protocole 2PC
. Babaoglu, S. Toueg, Non-blocking Atomic
Commitment, in S. Mullender (ed.), Distributed
Systems (2nd edition), Addison-Wesley, 1993

. Babaoglu, S. Toueg, Non-blocking Atomic Commitment, in S. Mullender (ed.), Distributed Systems (2nd
edition), Addison-Wesley, 1993
19

20

Validation avec diffusion simple (1)

Validation avec diffusion simple (2)

Le protocole de terminaison (raction la panne du coordinateur) tente de
dterminer si une dcision a t prise en contactant les participants
survivants.
Sa terminaison en temps fini nest pas garantie

Les proprits de lalgorithme de validation dpendent du protocole broadcast

insr dans le protocole gnrique
Cas 1 : broadcast = diffusion simple (synchrone) :
si un processus correct diffuse m, tous les processus destinataires
corrects dlivrent m
pour tout message m, tout destinataire dlivre m au plus une fois, et
seulement si un processus a diffus m
il existe une constante connue $b telle que si la diffusion a t lance au
temps (physique) t, aucum message ne sera dlivr aprs t + $b

Exemple (dj vu) :

le coordinateur prend une dcision, la diffuse certains participants, puis
tombe en panne
ces participants tombent en panne leur tour
En fait le protocole de validation qui utilise la diffusion simple nest autre que
2PC

Cette diffusion na pas la proprit tout ou rien (diffusion fiable). En cas de

panne de lmetteur pendant la diffusion, un message peut tre dlivr
certains destinataires seulement

2003-2004, S. Krakowiak

Il faut renforcer les spcifications de l'algorithme de diffusion pour quil ait la

proprit tout ou rien

21

diffusion simple

Validation avec diffusion fiable uniforme (1)

22

Validation avec diffusion fiable uniforme (2)

Cas 2 : broadcast = diffusion fiable uniforme synchrone :

si un processus correct diffuse m, tous les processus destinataires
corrects dlivrent m
pour tout message m, tout destinataire dlivre m au plus une fois, et
seulement si un processus a diffus m
il existe une constante connue $b telle que si la diffusion a t lance au
temps (physique) t, aucun message ne sera dlivr aprs t + $b
+ accord uniforme
si un processus (correct ou non) dlivre m, tous les processus corrects
dlivrent m

Le protocole de diffusion fiable

uniforme synchrone est appel
UTRB (Uniform Timed Reliable
Broadcast)
Le protocole du coordinateur est
inchang (broadcast est maintenant
la diffusion UTRB)
Le protocole des participants est
inchang, sauf pour le protocole de
terminaison (panne du coordinateur)
devenu inutile : on dcide dannuler
car on sait quaucune dcision
contradictoire ne peut avoir t prise

uniformit
Cette diffusion a la proprit tout ou rien (diffusion fiable). En cas de panne de
lmetteur pendant la diffusion, le message est dlivr tous les participants ou
aucun. En outre luniformit garantit laccord entre tous les processus : si un
processus a dcid avant de tomber en panne, tous les processus corrects
destinataires sont au courant de cette dcision. Donc le scnario de blocage est
impossible
2003-2004, S. Krakowiak

2003-2004, S. Krakowiak

. Babaoglu, S. Toueg, Non-blocking Atomic

Commitment, in S. Mullender (ed.), Distributed
Systems (2nd edition), Addison-Wesley, 1993
23

Participant
set-timeout (Cknow + $c + ")
wait-for (receipt of VOTE_REQUEST from coord.)
send (vote) to coordinator
if (vote = NO) then
decide (abort)
else
set-timeout (Cknow + $c + 2" + $b )
wait-for(delivery of decision messages)
if (decision mess. is abort) then
decide (abort)
else decide (commit)
on-timeout
decide (abort)
on-timeout
decide (abort)
24

Diffusion simple

Validation avec diffusion fiable uniforme (3)

Pour conclure ltude de la validation, il reste fournir une ralisation des

protocoles de diffusion
" diffusion simple

On peut dmontrer (cf Babaoglu & Toueg) que le protocole de validation utilisant
la diffusion fiable uniforme synchrone (UTRB) satisfait aux spcifications de la
validation, y compris labsence de blocage :

" diffusion fiable uniforme synchrone (UTRB)

Diffusion simple dans un groupe G de processus

(composition fixe)

Tout processus correct dcide

On peut en outre prvoir le cas de restauration dun processus dfaillant
(protocole de reprise). On peut ainsi assurer que :

metteur :
send (m) to all processes in G
deliver (m)

Tout participant au courant de la transaction dcide, condition de rester

vivant suffisamment longtemps (borne connue) aprs sa reprise sur
dfaillance

2003-2004, S. Krakowiak

destinataire (" metteur) :

upon (receipt of m)
deliver (m)

25

Diffusion fiable uniforme synchrone (UTRB)

! Importance
" Pratique : algorithme de base pour la ralisation de transactions
rparties

Diffusion fiable uniforme synchrone dans un

groupe G de processus (composition fixe)

destinataire (" metteur) :

upon (first receipt of m)
send (m) to all processes in G
deliver (m)

26

Conclusion (provisoire) sur la validation

Un premier algorithme, simple mais peu efficace (nombre de messages % n2)

metteur :
send (m) to all processes in G
deliver (m)

Rappel : un message
envoy via send par un
processus correct parvient
son destinataire
(correct) en un temps t < "

Rappel : un message envoy via

send par un processus correct
parvient son destinataire
(correct) en un temps t < "

" Thorique : un des deux problmes fondamentaux de prise de

dcision concerte (lautre est le consensus, voir plus tard)

! Solutions
" Ncessitent en pratique des hypothses fortes sur la
communication et le synchronisme
" Protocoles de base : 2PC, 3PC

! Reste voir
" Relations entre validation et consensus
# consquences thoriques
# consquences pratiques

Un algorithme plus efficace sera prsent plus tard

27

2003-2004, S. Krakowiak

28