Télécharger la présentation
La présentation est en train de télécharger. S'il vous plaît, attendez
Publié parMireio Courtin Modifié depuis plus de 9 années
1
1 Un protocole de cohérence des données tolérant aux fautes Jean-Francois Deverge Encadrants : Gabriel Antoniu, Luc Bougé Réunion GDS IRISA – Projet PARIS DEA Informatique - 05/2004
2
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
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
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
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
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
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
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
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_update req_release access
10
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
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
12
12 Un deuxième pas : Les verrous hiérarchiques [H2BRC] Home req_acquire req_read req_write req_release Home local req_acquire req_read req_write req_release B C A B GDG Home local C A Home global
13
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_acquire req_read req_release allocate_home Home global Home local
14
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_acquire req_read req_release allocate_ldg LDG
15
15 Assimilation des LDG en membres du GDG ✔ Diminution du nombre de copies ✔ Amélioration de la persistance du GDG
16
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
17
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
18 Scenario 0 : un exemple d’execution sans fautes
19
19 Scenario 1 : La faute d'un client
20
20 Scenario 2 : La reprise d'un client
21
21 Scenario 3 : La faute d'un LDG (1/2)
22
22 Scenario 3 : La faute d'un LDG (2/2)
23
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
24 --- Copie req_acquire [C; A] A req_acquire lock_access data req_read req_write req_read data B C req_release lock_access [] [C; 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 et C 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
Présentations similaires
© 2024 SlidePlayer.fr Inc.
All rights reserved.