Vous êtes sur la page 1sur 14

cole Doctorale de Grenoble Master 2 Recherche Systmes et Logiciel

Gestion rpartie de donnes : bref historique (1)


Pendant longtemps, la gestion de donnes est reste centralise : les donnes sont conserves en un lieu unique Systme de gestion de fichiers (SGF classique, composant du systme d!exploitation) Systme de gestion de bases de donnes (SGBD) Puis des considration de disponibilit ont amen dupliquer (localement) les fichiers ou bases de donnes, totalement ou partiellement d!o problmes de cohrence entre les copies multiples Vers les annes 1975 ont t dvelopps des prototypes de serveurs de fichiers accessibles distance, puis de SGF rpartis Vers les annes 1985 sont apparus les premiers SGF rpartis commerciaux (NFS), utilisant un protocole client-serveur (RPC) Les problmes de cohrence se posent propos des diffrents caches prsents dans les SGF. Paralllement sont dveloppes les transactions rparties pour les SGBD rpartis (cf problme de la validation atomique)
2003-2004, S. Krakowiak 2

Gestion rpartie de donnes - 1


Duplication et cohrence

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

Gestion rpartie de donnes : bref historique (2)


Au dbut des annes 1980 sont apparus les premiers systmes objets rpartis (prototypes de recherche). La notion d!intergiciel (middleware) est issue de ces travaux. La premire norme concernant un intergiciel objets (CORBA) est sortie en 1991. D!autres formes d!intergiciel (composants logiciels) ont suivi depuis. Les problmes de cohrence dus la duplication de donnes (pour la disponibilit et l!efficacit d!accs) et la ralisation de transactions sont toujours prsents Principaux problmes nouveaux : Modles de programmation (client-serveur, objects rpartis, vnements asynchrones, composants) et liaison avec les langages Structures de l!intergiciel pour l!accs des informations distantes Scurit Ces aspects sont traits dans le cours Construction d!applications rparties

Gestion rpartie de donnes : bref historique (3)


Le Web apparat au dbut des annes 1990 et modifie la vision de l!accs l!information. Le potentiel est celui d!un vaste SGBD, peu structur, l!chelle de tout l!Internet, dont le contenu et mme l!organisation changent en permanence Les modles d!organisation des SGF et SGBD classiques sont trop rigides et ne passent pas grande chelle. On explore de nouvelles formes, comme les systmes pair pair (peer to peer, P2P), et les outils correspondants modles vnements diffusion grande chelle nouvelles formes de stockage rparti Autre aspect : les rseaux mobiles. Caractristiques connectivit non permanente et de qualit variable localisation variable des donnes La gestion de donnes dans ces rseaux est un autre thme de recherche actuel
3 2003-2004, S. Krakowiak 4

2003-2004, S. Krakowiak

Gestion rpartie de donnes : problmes abords

Duplication et cohrence
! Pourquoi dupliquer les donnes ?
" Disponibilit des donnes : permettre l!accs aux donnes mme en cas de dfaillance d!un support # technique dj utilise pour des donnes centralises, avec copie(s) locale(s) " Rapidit d!accs : placer une copie des donnes prs (en temps d!accs) de leur point d!utilisation # technique des caches, dj utilise en centralis # extension aux caches logiciels, donnes locales vs donnes distantes

Duplication et cohrence des donnes (*) Modles de cohrence Protocoles pour la cohrence Exemples Diffusion grande chelle Algorithmes pidmiques Exemples Systmes pair pair Classification et choix de conception Exemples Tables de hachage rparties (DHT)
(*) Source et rfrence pour la duplication et la cohrence : A. S. Tanenbaum & M. van Steen, Distributed Systems - Principles and Paradigms, Prentice Hall, 2002, ch. 6
2003-2004, S. Krakowiak 5

! Cohrence : la contrepartie de la duplication


" Les diverses copies d!une mme donne doivent tre cohrentes, c!est-dire apparatre comme une copie unique " En fait, cette notion mme de cohrence peut avoir de nombreuses interprtations " Le maintien de la cohrence a un cot. Il faut faire un compromis entre le cot et la qualit de la cohrence

2003-2004, S. Krakowiak

Accs des donnes dupliques


vue idale

Divers cas de duplication de donnes


degr de couplage dcroissant Mmoire virtuelle rpartie Extension de la mmoire virtuelle donnes copie 1 Serveurs dupliqus fortement coupls (petit nombre) Serveurs dupliqus faiblement coupls (nombre important, variable) Caches rpartis couplage fort (multiprocesseur) couplage faible (Web) mode dconnect (mobiles)
7

processus client

accs (lire, crire)

donnes

vue relle Le protocole de cohrence assure : l!excution des oprations des clients la mise en cohrence mutuelle des copies conformmement un comportement dfini par un modle de cohrence

processus client

cohrence centre sur le serveur

protocole de cohrence

processus client

donnes copie 2

processus client

donnes copie 3

cohrence centre sur le client


8

Modle de cohrence
Un modle de cohrence pour des donnes rparties spcifie un contrat entre un client et le systme de gestion de donnes (avec engagement mutuel) Les donnes rparties sont un ensemble d!lments (un lment peut avoir une granularit quelconque : octet, enregistrement, fichier, etc.). Les oprations sont lire et crire (ventuellement des oprations plus complexes, mais toujours divises entre consultation et modification) Le modle de cohrence le plus contraignant est celui qui correspond exactement la vue idale des donnes Cohrence stricte Toute lecture sur un lment x renvoie une valeur correspondant l!criture la plus rcente sur x
9

Cohrence stricte
Toute lecture sur un lment x renvoie une valeur correspondant l!criture la plus rcente sur x La ralisation d!un protocole ralisant la cohrence stricte dans un systme rparti pose deux problmes. Dfinition de l!vnement le plus rcent Ralisation instantane des oprations La dfinition de l!vnement le plus rcent ncessite des horloges parfaitement synchronises (cart nul entre deux sites quelconques) Une opration qui ncessite un accs distant ne peut tre instantane (plus prcisment, une opration locale lance aprs une opration distante peut se terminer avant) La cohrence stricte est un modle idal (non ralisable), que l!on essaie d!approcher au moyen de modles moins contraignants
10

Linarisabilit
La condition de linarisabilit a dj t dfinie pour les serveurs dupliqus, pour des requtes transmises aux serveurs. L!accs des donnes dupliques en est un cas particulier, dans lequel les oprations se rduisent lire et crire Le rsultat de l!excution d!un ensemble de processus clients est identique celui d!une excution dans laquelle : Toutes les oprations sur les donnes (vues comme centralises) sont excutes selon une certaine squence S Si deux oprations op1 et op2 (lectures ou critures) sont telles que op1 ! op2, alors op1 et op2 figurent dans cet ordre dans S La cohrence interne des donnes est respecte dans S (aprs une criture, et jusqu! la suivante, une lecture dlivre la valeur crite) Rappel : on dit que op1 ! op2 si t(fin(op1)) < t(dbut(op2)), o t est une date vrifiant la validit forte (en pratique une heure donne par des horloges physiques synchronises)
11

Cohrence squentielle
La linarisabilit est coteuse raliser en pratique. Aussi dfinit-on une condition plus faible, la cohrence squentielle : Le rsultat de l!excution d!un ensemble de processus clients est identique celui d!une excution dans laquelle : Toutes les oprations sur les donnes (supposes centralises) sont excutes selon une certaine squence S Les oprations excutes par tout processus p figurent dans S dans le mme ordre que dans p La cohrence interne des donnes est respecte dans S Diffrence par rapport la linarisabilit : on ne contraint pas l!ordre relatif des oprations dans des processus diffrents, tant que la cohrence interne des donnes est respecte

12

Linarisabilit et cohrence squentielle


contrainte de temps : W(x)a prcde W(x)b p1 W(x)a p2 W(x)b Notation : p3 R(x)a R(x)b Ri(x)a : par pi, lecture de x, rsultat a Wi(x)a : criture de x, valeur a p R(x)a R(x)b
4

Autre exemple de cohrence squentielle


P1 x:=1 print(y, z) P2 y:=1 print(x, z) P3 z:=1 print(x, y)

3 processus

4 excutions possibles parmi les 90 qui respectent la cohrence squentielle


x:=1 print(y, z) y:=1 print(x, z) z:=1 print(x, y) x:=1 y:=1 print(x, z) print(y, z) z:=1 print(x, y) y:=1 z:=1 print(x, y) print(x, z) x:=1 print(y, z) x:=1 y:=1 z:=1 print(x, z) print(y, z) print(x, y)

S =W(x)a R3(x)a R4(x)a W(x)b R3(x)b R4(x)b linarisable p1 p2 p3 p4 W(x)b R(x)a R(x)b R(x)a R(x)b W(x)a p1 W(x)a p2 p3 p4 W(x)b R(x)b R(x)a R(x)a R(x)b

Impression ralise
001011 101011 010111 111111

S =W(x)a R3(x)a R4(x)a W(x)b R4(x)b R3(x)b squentiel, non linarisable non squentiel
13

Mais le rsultat 000000 est impossible obtenir en respectant la cohrence squentielle


14

Conclusion sur la cohrence squentielle


Modle moins strict que la linarisabilit, car il permet une classe plus large d!ordonnancements diffrents (grce au dcouplage entre processus) Nanmoins un protocole de cohrence squentielle reste encore coteux raliser. En effet, on peut montrer que : si t est le temps minimal de transfert d!un message lmentaire entre 2 sites r est la dure d!une lecture w est la dure d!une criture alors r+w"t Autrement dit, tout gain sur le temps de lecture entrane une perte sur le temps d!criture, et vice-versa
15

Cohrence causale (1)

Modle plus faible que la cohrence squentielle, car on ne considre que des vnements relis par une relation de causalit Soit deux vnements E1 et E2 tels que E1 ! E2 (prcdence causale). Alors tout processus doit voir E1 avant E2 Exemples : si E1: p crit x, puis E2: q lit x, alors E1 ! E2 si E1: p lit x, puis E2: p crit y, alors E1 ! E2 (car la valeur crite par p peut dpendre d!un calcul fait partir de x) si E1: p crit x, puis E2: q crit y (de manire indpendante), alors E1 || E2 La condition sur criture et lecture est dj incluse dans la cohrence interne des donnes Reste spcifier la condition sur les critures
16

Cohrence causale (2)


Dfinition : Des critures causalement lies (!) doivent tre vues par tous les processus dans leur ordre causal. Des critures causalement indpendantes (||) peuvent tre vues dans un ordre diffrent p1 p2 p3 p4 W(x)a R(x)a R(x)a R(x)a W(x)b R(x)c R(x)b R(x)b R(x)c W(x)c

Cohrence FIFO
La cohrence causale peut encore tre affaiblie, si on ne considre la causalit qu! l!intrieur d!un seul processus, non entre processus diffrents. Dans un processus unique, la causalit se rduit l!ordre FIFO Dfinition : Des critures ralises par un mme processus doivent tre vues par tous les processus dans leur ordre de ralisation. Des critures ralises par des processus diffrents peuvent tre vues dans un ordre diffrent p1 p2 p3 p4 W(x)a R(x)a W(x)b W(x)c R(x)b R(x)a R(x)c R(x)a R(x)b R(x)c R(b) prcde R(c) partout ; R(a) est indpendant Ralisation : il suffit d!un compteur (scalaire) par processus
17 18

Les lectures de p3 et p4 renvoient b et c dans des ordres diffrents. C!est possible car les critures sont causalement indpendantes Ce scnario est impossible avec la cohrence squentielle La dpendance causale peut tre dtecte avec des horloges vectorielles. Celles-ci peuvent donc servir raliser un protocole de cohrence causale (cf exemple plus loin, protocole de Ladin et al.)

Cohrence utilisant la synchronisation (1)

Cohrence utilisant la synchronisation (2)

En fait, il n!est pas toujours ncessaire d!assurer la cohrence tout instant. Par exemple, si un processus modifie les donnes l!intrieur d!une section critique, les autres processus ne peuvent pas voir les tats intermdiaires. Il n!est donc pas ncessaire d!imposer des contraintes sur les oprations internes une section critique D!o l!ide d!associer synchronisation et maintien de la cohrence, l!aide de variables et d!oprations de synchronisation. Une variable de synchronisation S est associe un ensemble de donnes. L!appel de l!opration synchronize(S) par un processus p provoque la mise en cohrence des donnes locales (vues par p). En dehors de ces oprations, la cohrence peut ne pas tre assure. Les modles diffrent selon le moment o la synchronisation est ralise.
19

La cohrence avec synchronisation (ou cohrence faible) est dfinie ainsi#: L!accs aux variables de synchronisation associes un ensemble de donnes respecte la cohrence squentielle [les oprations de synchronisation sont vues par tous les processus dans le mme ordre] Un processus ne peut pas excuter une opration sur une variable de synchronisation tant que toutes les critures antrieures n!ont pas t excutes sur les copies locales [la synchronisation force la mise en cohrence de toutes les copies locales] Un processus ne peut pas excuter une lecture ou une criture tant qu!il n!a pas excut toutes les oprations antrieures sur les variables de synchronisation [aprs synchronisation, un processus peut accder la version la plus rcente des donnes synchronises]

20

Cohrence utilisant la synchronisation (3) Exemples p1 W(x)a W(x)b S p2 R(x)a R(x)b S p3 R(x)b R(x)a S possible p1 p2 W(x)a W(x)b S S R(x)a impossible

Cohrence la sortie (release consistency) (1)

On peut protger une squence d!oprations sur des lments (ou variables) dans un processus en l!incluant entre acquire(V) et release(V), o V est une variable de synchronisation (verrou) Au moment de acquire : toutes les copies locales des variables protges sont mises jour pour tenir compte des critures non encore rpercutes Au moment de release : toutes valeurs des variables locales qui ont t modifies sont envoyes vers les copies distantes.
acquire(V) release(V)
21 22

Pour avoir un contrle encore plus fin sur la synchronisation, on peut spcifier le moment auquel la synchronisation (mise en cohrence) doit avoir lieu, dans le cas d!une suite d!oprations excutes en section critique Cohrence la sortie (release consistency) Cohrence l!entre (entry consistency)

Cohrence la sortie (release consistency) (2)


acquire(V) release(V)

Cohrence l!entre (entry consistency) La cohrence l!entre est voisine de la cohrence paresseuse la sortie. La diffrence est que toute variable modifie indpendamment doit tre associe un verrou spcifique. Au moment de acquire, seules les variables associes au verrou utilis sont mises jour p1 Acq(Vx) W(x)a Acq(Vy) W(y)b Rel(Vx) Rel(Vy) p2 Acq(Vx) R(x)a R(y)nil p3 Acq(Vy) R(y)b

Une variante : cohrence paresseuse la sortie (lazy release consistency) Les modifications ne sont pas propages la sortie. Elles sont seulement faites (pull) la prochaine entre (par le processus considr ou par un autre processus)
acquire(V) acquire(V) release(V) release(V)
23

24

Conclusion sur la cohrence avec synchronisation

Cohrence terme (1)


Dans beaucoup de situations pratiques La plupart des accs sont des lectures Les conflits d!criture sont trs rares (les donnes sont partitionnes en sous ensembles et un processus unique crit dans chaque sousensemble) Il est acceptable de lire une donne non jour Exemples : le DNS (Domain Naming System) ; le World Wide Web ; certaines bases de donnes Dans ce cas, on peut tolrer des donnes incohrentes pendant un certain temps, si on respecte la condition suivante : En l!absence de mises jour pendant un temps assez long, toutes les copies finiront par devenir cohrentes. C!est la cohrence terme (eventual consistency)

La cohrence avec synchronisation permet de spcifier de manire fine les variables protger, en utilisant des informations sur les accs prvus La motivation est de rduire le nombre d!oprations de mise en cohrence Cadre principal d!application : mmoire virtuelle rpartie Exemples Cohrence paresseuse la sortie : Treadmarks (Rice) Cohrence l!entre : Midway (CMU)
25

26

Cohrence terme (2)

Modles de cohrence centrs sur le client (1)


Lectures monotones Si un processus a lu la valeur d!une donne x, toute lecture ultrieure par ce mme processus doit rendre la mme valeur ou une valeur plus rcente Ce modle garantit qu!un client ne reviendra pas en arrire critures monotones Si un processus excute deux critures successives sur une mme donne x, la deuxime criture ne peut tre ralise que quand la premire a t termine Ce modle garantit qu!un client ne fera une modification sur une copie que quand cette copie sera jour des modifications antrieures par ce mme client. Ce modle est voisin du modle de cohrence FIFO, mais ne concerne que la vue d!un processus client unique et non celle de tous les processus
27 28

La cohrence terme est ralise par des protocoles qui propagent les modifications l!ensemble des copies, avec une proprit de convergence terme. Voir plus loin (algorithmes dits pidmiques) Les conflits en criture sont en principe peu frquents (par hypothse) et rgls au cas par cas Nanmoins ce type de cohrence peut poser un problme lorsqu!un client s!adresse successivement plusieurs copies diffrentes d!une donne. Exemples clients mobiles utilisation de caches D!o une classe de modles de cohrence dfinis partir de la vue du client

Modles de cohrence centrs sur le client (2)


Cohrence criture-lecture (Read Your Writes) Si un processus a modifi la valeur d!une donne x, cette modification doit tre visible par toute lecture ultrieure par ce mme processus Un exemple courant de violation de cette proprit

Modles de cohrence centrs sur le client (3)

Cohrence lecture-criture (Writes Follows Reads) Si un processus excute une criture sur une donne x aprs avoir lu cette donne, l!criture va modifier (partout) une valeur de la donne au moins aussi rcente que la valeur lue Un exemple de violation de cette proprit (donne = un newsgroup)

serveur Web

serveur Web

serveur Web

C x2
criture

x1
cache

C1 x2

Serveur de news (local)

C1 B A
C1 affiche B (raction A)

C2 B

x1
tat initial

lecture

A
C1 lit news A

Le problme vient de ce que le cache du navigateur n!est utilis que pour la lecture, pas pour l!criture. Dans la pratique, on rafrachit explicitement le cache
29

C2 lit B (et ne voit pas encore A)


30

Mise en uvre des modles de cohrence (1)


Objectif commun : propagation des critures aux diffrentes copies, en essayant d!liminer ou de rduire le nombre et le volume des transferts la taille de l!information conserve Problme 1 : Dfinition et placement des copies Solution 1 : copies permanentes. Ensemble de copies dfinies a priori Solution 2 : copies temporaires cres par le serveur. Exemple : copies cres par un serveur Web pour rsister un pic de demande. Le nombre de copies d!une information particulire peut tre li la demande constate pour cette information Solution 3 : copies cres par les clients. Exemple : diverses formes de cache lies un client ou un groupe de clients
31

Mise en uvre des modles de cohrence (2)


Problme 2 : Propagation des mises jour Mode de propagation. Soit X une donne en exemplaires multiples. Aprs modification d!une copie locale X1 de X par une certaine opration op(X),quelles informations vont-elles tre transmises pour propager cette modification ? Invalidation. On signale chaque serveur grant une copie distante que sa copie est maintenant invalide. Avantage : information minimale Recopie de donnes. On transfre une copie des donnes modifies. Avantage : mise jour rapide ; inconvnient : volume des donnes transmises Opration distance. On signale chaque serveur distant qu!il doit raliser la modification, en refaisant l!opration op(X). Avantage : peu d!informations transmises, mais peut occuper les serveurs si opration complexe
32

Mise en uvre des modles de cohrence (3)


Problme 2 : Propagation des mises jour (suite) Initiative de la propagation Initiative du serveur (push) En gnral ralis pour la propagation entre serveurs permanents, et lorsqu!on recherche un haut niveau de cohrence Plus compliqu raliser lorsqu!il y a un nombre variable de copies, et pour des copies temporaires telles que les caches (par exemple, pratiquement irralisable pour un serveur Web) Initiative du client (pull) Souvent ralise dans les systmes de caches. Le grant du cache vrifie que la copie en cache est toujours frache en la comparant la copie de rfrence. En fait il suffit de comparer les dates de dernire modification (estampilles)
Souvent, on impose au cache une frquence minimale de rafrachissement (par exemple caches clients des fichiers NFS : 3 secondes pour les fichiers, 30 secondes pour les catalogues)
33

Protocoles de cohrence (1)


La ralisation d!un protocole de cohrence dpend du modle de cohrence que l!on souhaite mettre en uvre. On a dj vu (pour les serveurs) qu!un modle de linarisabilit pouvait tre ralis de deux manires : serveur (ou copie) primaire et duplication active (si les horloges sont bien synchronises). Cela reste vrai pour la gestion de donnes rparties, avec les mmes algorithmes (dj vus) Deux variantes pour la copie primaire Serveur fixe. Le serveur primaire qui gre une copie de chaque donne est fix. Si la mise jour est faite sur un autre site, on fera un appel distance Serveur local. La mise jour est toujours faite localement. Pour cela, on transfre d!abord une copie du primaire sur le site local (le primaire initial se comporte comme un serveur de secours). Avantage quand on a une succesion de modifications par le mme client, et que les clients distants peuvent ventuellement lire des versions primes.
34

Protocoles de cohrence (2)

Votes et quorums pour la duplication (1)

Pour la duplication active, on rappelle qu!il faut raliser la diffusion totalement ordonne (atomique) des modifications. En gnral, on ralise cette diffusion par un algorithme base de squenceur (vu prcdemment). Les algorithmes de diffusion atomique ne passent pas bien l!chelle car ils ncessitent un nombre lev de messages pour tre tolrants aux fautes. Pour un grand nombre de copies, on utilise plutt un modle de cohrence terme (eventual consistency), et des algorithmes de diffusion pidmique, voir plus tard. Pour un nombre modr de copies, on peut rechercher une optimisation entre degr de duplication (pour rsister aux dfaillances) et efficacit. Pour cela, on utilise des techniques de vote.

Ide de base : un client doit avoir l!autorisation de plusieurs serveurs (quorum) avant de raliser une criture sur une donne Par exemple, si on a N serveurs, on peut spcifier qu!il faut l!autorisation de plus de N/2 d!entre eux (un serveur donne l!autorisation s!il est vivant). Ainsi la modification sera toujours faite sur une majorit de serveurs. Exemple : si N = 3, on ne peut crire que si 2 serveurs se disent prts accepter l!criture. Ensuite, on est certain que si on consulte 2 serveurs quelconques sur les 3, l!un au moins aura une copie jour de la dernire modification (il suffit de regarder les estampilles pour connatre la version la plus rcente) On peut gnraliser ce principe toutes les oprations de lecture ou d!criture.
35 36

Votes et quorums pour la duplication (2)


Quorums en lecture et criture N = nombre de copies nr = quorum de lecture, nw = quorum d!criture, nr + nw > N Cette condition garantit que l!on pourra toujours accder en lecture la version la plus rcente Les quorums en lecture et criture sont diffrents selon les proprits souhaites Exemple
N=5, nr = 2, nw = 4 N=5, nr = 3, nw = 3 N=5, nr = 4, nw =2

Votes et quorums pour la duplication (3)

! Principe
" Donner des poids diffrents aux copies selon leur importance prsume (raisons d!accessibilit, administration, etc.) " Utilit : partition de rseau (copies inaccessibles)

N = nombre de votes disponibles (et non plus nombre de copies) nr = quorum de lecture, nw = quorum d!criture nr + nw > N et 2w > N Exemple : N=7, nr = 4, nw = 4
S2

S1

4 votes

partition 1
37

Si S1 crit dans la la partition 1, on est sr que S2 ne peut pas crire dans la partition 2 (car elle ne peut pas avoir plus de 3 votes Il est galement impossible S2 de lire pendant que S1 crit (lectures et critures sont srialises)

partition 2
38

Un exemple de protocole de cohrence gr par les serveurs (Ladin et al.)


Serveur de donnes dupliques ralisant la cohrence terme, mais prservant la dpendance causale entre oprations
requtes en attente d!excution lectures critures

Protocole de cohrence de (Ladin et al.) : principe

Serveur de donnes dupliques ralisant la cohrence terme, mais prservant la dpendance causale entre oprations.

copie 1

rseau clients

copie 2

Pour raliser la dpendance causale : estampilles analogues aux horloges vectorielles. Une opration n!est ralise que si toutes les opration dont elle dpend causalement (potentiellement) ont t ralises. Donc on doit retarder certaines oprations (d!o les files d!oprations en attente) : analogie avec la diffusion causale avec horloges vectorielles

copie 3

R.Ladin, B. H. Liskov, L. Shrira, S. Ghemataw. Providing Availability Using Lazy Replication,ACM Trans. on Computer Systems (TOCS), vol. 10, 4, Nov. 1992
39

Pour raliser la cohrence terme : change priodique, entre les serveurs, d!informations sur les mises jour (protocole dit anti-entropie). terme, toute copie est au courant de toutes les modifications et cellesci peuvent tre ralises, en respectant la dpendance causale.

40

Protocole de (Ladin et al.) : donnes


Chaque copie locale Li maintient deux vecteurs VAL(i) et WORK(i) VAL(i)[j] : nombre de mises jour excutes sur Li depuis Lj (VAL(i)[i] : critures locales) WORK(i)[j] : nombre de mises jour totales (faites et faire) sur Li depuis Lj (WORK(i)[i] : critures locales) Chaque client C maintient un vecteur LOCAL(C) LOCAL(C)[i] : tat de Li vu par C (nombre de mises jour)
en retard

Protocole de (Ladin et al.) : lecture


Principe : on envoie la requte une copie (par exemple la plus proche du client). La requte sera excute lorsque toutes les oprations causalement antrieures auront t excutes Au retour, le vecteur LOCAL du client sera mis jour pour reflter sa nouvelle connaissance de l!tat des serveurs
excute si DEP(R) $ VAL(i)

C1

LOCAL : 2, 1
en retard

VAL : 3, 2 WORK : 4, 3 VAL : 2, 3 WORK : 4, 4

en retard

DEP(R) := LOCAL(C)

envoi requte de lecture

lecture

LOCAL(C) := max (VAL(i), LOCAL(C))

renvoie (valeur lue, VAL(i))

C2

LOCAL : 2, 2

client C
41

copie Li
42

Protocole de (Ladin et al.) : criture


Principe : comme pour la lecture, on envoie la requte une copie (par exemple la plus proche du client). La requte sera excute lorsque toutes les oprations causalement antrieures auront t excutes Au retour, le vecteur LOCAL du client sera mis jour pour reflter sa nouvelle connaissance de l!tat des serveurs
WORK(i)[ i ] := WORK(i)[ i ] +1 ts(W)[ i ] := WORK(i)[ i ] ts(W)[ j ] := DEP(W)[ j ] envoi requte d!criture

Protocole de (Ladin et al.) : mise en cohrence mutuelle


Principe : les diffrents serveurs excutent priodiquement un protocole d!anti-entropie (change mutuel des dernires modifications connues)
Opration de base : Li envoie Lj les requtes d!criture en attente dans sa file et son vecteur WORK(i) Lj met jour son propre vecteur WORK(j) (rgle du max.) et fusionne les requtes en critures de Li et Lj Lj examine sa nouvelle file de requtes en criture pour dterminer si une opration peut tre excute Pour cela, on utilise les estampilles DEP(W) attaches chaque requte W Une requte W1 peut tre excute si DEP(W1)$VAL(j) et si elle ne dpend d!aucune autre requte non excute : " W : (# k : DEP(W)[k] $ DEP(W1)[k]) Les requtes d!criture excutables sont successivement excutes et retires de la file Optimisation : lorsqu!une criture a t excute partout ( vrifier par changes), la requte correspondante est sortie des files W (pour limiter leur taille)

excute si DEP(W) $ VAL(i)

DEP(W) := LOCAL(C)

lecture
lors de l!excution

LOCAL(C) := max (ts(W), LOCAL(C))

renvoie estampille ts(W)

client C

copie Li

VAL(i)[j]:= max(VAL(i)[j, ts(W)[j]])


43

44

Implmentation de la cohrence centre sur le client (1)


Les donnes sont gres par un ensemble de serveurs. Chaque serveur contient une copie des donnes. Une opration locale a lieu sur un serveur particulier. Toute criture sur un serveur Si reoit un identificateur global d!criture WID, et une estampille ts(WID). Tout serveur Si gre un vecteur RCVDi, o RCVDi[k] est l!estampille de la dernire criture faite sur le serveur Sk, reue et traite par Si Quand un client doit faire une opration sur un serveur particulier, le serveur lui renvoie une estampille avec le rsultat L!ensemble de lecture d!un client est l!ensemble des identificateurs d!criture associs aux lectures (c!est--dire, pour toute lecture, l!identificateur global pour l!criture qui a engendr la valeur lue). L!ensemble d!criture d!un client est l!ensemble des identificateurs des critures faites par ce client
45

Implmentation de la cohrence centre sur le client (2)


Pour chacun des ensembles A de lecture et d!criture d!un client, on note VT(A) un vecteur tel que VT(A)[i] = l!estampille maximale de toutes les opration de A lances partir du serveur i. On peut alors dfinir des oprations sur ces ensembles union : VT(A+B) tel que VT(A+B)[i] = max(VT(A)[i], VT(B)[i]) inclusion : A inclus dans B si pour tout i, VT(A)[i] $ VT(B)[i] Ces estampilles peuvent servir raliser les modles ci-dessus. Exemple : lecture monotone. Soit RCVDi[k] l!estampille de la dernire criture faite sur le serveur Sk.Soit VT(RSet) l!estampille de l!ensemble de lecture pour un client C. Alors on excute, pour tout k : VT(RSet)[k] := max(VT(RSet)[k], RCVDi[k]). donc l!ensemble de lecture du client C reflte toutes les oprations d!criture vues par C. Avant de dlivrer la valeur lue au client, le serveur local doit vrifier que toutes les critures dcrites dans VT(RSet) ont t faites.
46

Mode dconnect

Exemple de systme en mode dconnect : Coda

! Motivations
" Gnralisation de l!usage des portables " Dveloppement des communications sans fil " La plupart du temps, les portables sont utiliss # soit en mode autonome # soit connects un rseau " On cherche assurer une transition facile entre les deux modes

! Historique
" Projet de recherche Carnegie Mellon Univ. (suite d!Andrew, 1990-...) Coda = Constant Data Availability " Actuellement : intgr dans Linux

! Objectifs
" Viser une disponibilit permanente de l!information chez le client, y compris dans les cas suivants # dconnexion volontaire # dconnexion accidentelle # faible connectivit
$ $ connexion intermittente (communications mobiles) connexion trs faible dbit

! Principe
" Ide de dpart : mcanisme AFS (mise en cache de fichiers entiers sur le poste client) " Problmes # choix des fichiers conserver lors de la dconnexion # mise en cohrence la reconnexion

! Principes
" Duplication des serveurs " Mode dconnect

47

48

Coda : principes de conception

Coda : tats du client

! Extension d!AFS
" sparation client-serveur " cache client sur disque " cache de fichiers entiers
Accumulation connexion forte connexion faible connexion mulation dconnexion Rintgration

! Duplication des serveurs AFS


" Un volume peut avoir des copies sur plusieurs serveurs " Augmente la probabilit qu!un volume soit accessible

dconnexion

! Modification du client AFS


" Pendant la connexion, cherche stocker en cache les fichiers potentiellement utiles " En mode dconnect, utilise les fichiers en cache " la reconnexion, processus de rintgration # automatiser autant que possible # stratgie optimiste

! Accumulation : mode pleinement connect"; le client collecte les fichiers conserver ! mulation : mode dconnect"; le client utilise les fichiers en cache ! Rintgration : tat intermdiaire"; le client rintgre les modifications effectues durant la dconnexion
49 50

Coda : mode accumulation (1)

Coda : mode accumulation (2)

! Ouverture d!un fichier


" Accs un fichier f d!un volume V : dterminer l!ensemble des serveurs (Volume Storage Group, VSG) stockant une copie de V " Parmi ces serveurs, dterminer ceux qui sont accessibles (Available VSG, AVSG), et en choisir un parmi ceux-ci (serveur favori) " Charger une copie du fichier (avec tmoin de rappel sur le serveur)

! Dtection d!incohrence
" Si tous les serveurs accessibles n!ont pas la mme version du fichier (dtection par estampilles) # le client charge la plus rcente # le client dclenche un protocole de mise niveau (excut par les serveurs) - intervention manuelle si ncessaire

! Fermeture d!un fichier


" Si modifi, renvoyer la copie tous les serveurs de l!AVSG " Si AVSG # VSG (certains serveurs non accessibles), protocole de remise jour entre serveurs " Si d!autres tmoins de rappel prsents, le serveur favori excute les rappels

! Chargement anticip des fichiers


" En mode accumulation, le client charge des fichiers en tche de fond pour prparer priode de dconnexion # selon une liste de prfrences fournie par l!utilisateur # selon un algorithme d!apprentissage (observation des accs)

51

52

Coda : mode accumulation (3)

Coda : mode mulation

! Le client surveille la disponibilit des serveurs


" Toutes les T units de temps (de l!ordre de 10 minutes), le client examine le VSG des fichiers qu!il a en cache " Si variation de l!AVSG (panne ou rinsertion d!un serveur), mise jour ventuelle des tmoins de rappel chez le client (invalidation des copies en cache) # rinsertion d!un serveur : invalider les fichiers dont ce serveur a une copie (car sa version est peut-tre plus rcente) # disparition d!un serveur favori pour un volume : invalider les fichiers de ce volume # disparition d!un autre serveur : rien faire

! En mode mulation (dconnect) le client utilise les

fichiers en cache local


" Les modifications sont journalises sur le disque pour tre rejoues ultrieurement " Erreur si dfaut de fichier dans le cache (en principe rare)

53

54

Coda : mode rintgration (2)

Coda : conclusion

! Restauration de la cohrence
" Les modifications effectues pendant la dconnexion sont rejoues et propages vers les serveurs " Si la connectivit est faible, propagation goutte goutte en tche de fond pour ne pas dgrader les performances

! Exprience utile pour le mode dconnect


" Plusieurs versions successives " Mesures et observations

! Conclusions pratiques
" Les conflits non rsolubles sont en fait trs rares # justifie a posteriori la stratgie optimiste " La disponibilit est satisfaisante # pas de pertes de donnes " Le cot de la rintgration est acceptable Pour en savoir plus : http://www.cs.cmu.edu/afs/cs/project/coda/Web/coda.html

! Rsolution des conflits


" Si un conflit est dtect (modifications pendant la dconnexion) # le systme tente une rsolution automatique
$ $ version dominante modifications permutables (ajouts dans catalogue)

# si impossible, alors rsolution manuelle

55

56