1

Un protocole de cohérence des données tolérant aux fautes

Jean-Francois DevergeEncadrants : Gabriel Antoniu, Luc Bougé

Réunion GDS

IRISA – Projet PARISDEA Informatique - 05/2004

2

Plan

● Introduction● Quel modèle de cohérence pour les données ?● Un protocole pour le partage des données● Le support de la tolérance aux fautes

3

Partage de données pour la grille

● Fédération de grappes● Hétérogène● Hiérarchique

● Approche classique● Partage explicite● GridFTP, IBP, etc

4

La plate-forme JuxMem● Service de partage

de données pour la grille

● Données modifiables● Environnement dynamique

● Plate-forme d’expérimentations

● Protocoles de cohérence ● Stratégies de tolérance aux fautes

Architecture physique

Architecture logique

juxmem

Groupe grappe A Groupe grappe B

Groupe grappe C

Groupe g

http://www.irisa.fr/paris/Juxmem

5

Le modèle choisi :la cohérence d’entrée

● Accès ordinaires (read/write)● Accès spéciaux synchronisés

– acquire : accès exclusif– acquireR : accès en lecture– release : libération du verrou

● Association explicite d'un verrou avec une ou plusieurs variables partagées– Granularité de partage = ensemble des données

protégées par le verrou● Plusieurs lecteurs concurrents

– MRSW : Multiple Reader Single Writer

6

Exemple (1/2)

● acquire(L)● A = 12;● B = 99;● release(L)

● var A, B shared(L)

● B = 3

● acquireR(L)● c = A;● d = B;

● acquireR(L)● e = A;● f = B;

7

Exemple (2/2)

● acquire(L)● A = 12;● B = 99;● release(L)

● var A, B shared(L)

● B = 3

● acquireR(L)● c = A;● d = B;

● acquireR(L)● e = A;● f = B;

c = e = A = 12;d = f = B = 99;

8

API visée● interface JuxMemService

– ID alloc( size, attrib )– ECMemory map( ID )

● interface ECMemory– void read(buffer, offset, length)– void write(buffer, offset, length)– void acquire()– void acquireR()– void release()– void flush()

9

Quel protocole pour la gestion de ces données ?

● Une copie de référence (« home ») persistante [HBRC]

– Utilisation d’un group membership pour réaliser la réplication du home

● Gestion des accès à la donnée (obtention du verrou)

Home

req_acquire

req_acquire

req_updatereq_release

access

10

Ou placer ces données ?● Persistance :

– Dissémination statistique [PAST]

– Répartition sur plusieurs grappes

● Efficacité : – Copies primaires choisies

dans une partie rapide du réseau [OceanStore]

– Copies choisies dans des grappes proches

● Communication inter-grappes pour toutes requêtes

req_acquire

11

Un début de solution :Les caches hiérarchiques

● Utilisation d'un cache de données au niveau de chaque grappe [CLRC]

● Plusieurs politiques de cohérence des caches

● Communication inter-grappes pour les requêtes d’acquisition du verrou et les mises a jour

home

*

req_acquire

req_read

Cache

12

Un deuxième pas :Les verrous hiérarchiques [H2BRC]

Home

req_acquirereq_readreq_writereq_release

Home local

req_acquirereq_readreq_writereq_release

B CA B

GDG

Home localC A

Home global

13

Idee : superposer les caches et verrous hierarchiques

● Gestion des accès aux nœuds locaux

● Possibilité de relâchement de la cohérence en repoussant l'application des mises à jour sur le home global

● Mécanisme d'allocation du home local

GDG

req_acquirereq_readreq_release

allocate_home

Home global

Home local

14

Persistance des home locaux

● Réplication des home locaux par l’utilisation de group membership– LDG : Local Data Group

● Home global– GDG : Global Data

Group● Multiplication des

copies dans le système

GDG

req_acquirereq_readreq_release

allocate_ldg

LDG

LDG

15

Assimilation des LDG en membres du GDG

✔ Diminution du nombre de copies

✔ Amélioration de la persistance du GDG

16

Le support de la tolérance aux fautes

● Fautes au niveau– GDG– LDG– Client

● Utilisation d'un group membership proactif

✗ Coût

GDG

LDG LDG

LDG

17

L'objet version

• Associe a chaque verrou• (X, Y, Z) =

– X : un compteur de fautes de LDG– Y : compteur de fautes de client– Z : Un compteur de mises à jour

• Un historique des versions valides

18

Scenario 0 : un exemple d’execution sans fautes

19

Scenario 1 : La faute d'un client

20

Scenario 2 : La reprise d'un client

21

Scenario 3 : La faute d'un LDG (1/2)

22

Scenario 3 : La faute d'un LDG (2/2)

23

Prochaines étapes

● Terminer l’implémentation● Évaluation expérimentale sur plusieurs grappes● Autres modèles et protocoles :

– Protocoles par invalidation– Modèles de cohérence stricte ou séquentielle– Modèle de cohérence de portée (MRMW)– Multi-modèles (couches LDG différentes)

24

---Copie

req_acquire

[C; A]

A

req_acquire

lock_access data

req_read

req_writereq_read

data

B

C

req_release

lock_access

[] [C; A]

[A] [A]

req_read

Fig 1 :A et C demandent l'acces exclusif

Fig 2 :C obtient une donnee coherente

Fig 3 :B lit la donnee etC met a jour la donnee

Fig 4 :C relache le verrou et A obtient l'acces exclusif

Fig 5 : A lit une donnee coherente

data