Monnet06 Thesis

Numro dordre : 3462
THSE
prsente devant
LUNIVERSIT DE RENNES 1
pour obtenir le grade de
DOCTEUR DE LUNIVERSIT DE RENNES 1

Mention INFORMATIQUE
tel-00411447, version 1 - 27 Aug 2009
PAR
Monsieur Sbastien Monnet

quipe daccueil : projet PARIS, I RISA, Rennes cole doctorale MATISSE Composante universitaire : I FSIC
Gestion des donnes dans les grilles de calcul : support pour la tolrance aux fautes et la cohrence des donnes.
soutenue le 30 novembre 2006 devant la commission dexamen
Composition du jury
Monsieur Gabriel ANTONIU, charg de recherche, INRIA directeur de thse Monsieur Roberto BALDONI, professeur, Universit di Roma examinateur Monsieur Luc BOUG, professeur, ENS Cachan/Antenne de Bretagne directeur de thse Monsieur Frdric DESPREZ, directeur de recherche, INRIA rapporteur Monsieur Philippe PUCHERAL, Professeur, Universit de Versailles examinateur Monsieur Pierre SENS, professeur, Universit Paris 6 rapporteur
tel-00411447, version 1 - 27 Aug 2009
Remerciements
Trois ans cest long, mais cest galement horriblement court ! Je souhaite ici remercier ceux qui mont aid, soutenu, support. . . Je remercie tout dabord les six membres de mon jury pour avoir relu et valu mon travail ainsi que pour leurs questions lors de la soutenance. Je remercie en particulier Pierre et Frdric qui ont eu la patience de lire mon manuscrit, de rdiger des rapports dtaills et de faire des remarques qui mont permis damliorer ce document. Je souhaite galement remercier Thierry pour son accueil au sein de lquipe PARIS dont je remercie au passage tous les membres qui en font une quipe dynamique et sympathique. Un grand merci mes directeurs de thse Luc et Gabriel. Gabriel merci davoir cru en moi ds le dbut et davoir pris le temps de mexpliquer... Jai beaucoup appris tes cts. Luc merci de mavoir fait dcouvrir les plaisirs du travail bien fait. Je tiens galement te remercier pour ton coute et pour tous les conseils que tu mas donns sur bien des sujets. . . Jai eu la chance de faire ma thse au sein de lIRISA. Je voudrais remercier toutes les personnes qui en font un environnement de travail exceptionnel ! En particulier, Christiane et lodie du service mission qui nous permettent de voyager lesprit tranquille, merci lodie de mavoir sorti du ptrin quand jtais Chicago en 2004 ! Merci Maryse de toccuper de nous comme tu le fais. Je souhaite aussi remercier Christine Morin, Anne-Marie Kermarrec, Pierre Sens, Marin Bertier, Etienne Rivire, Christian Perez, Yvon Jegou, Franoise Andr, Indy Gupta, Ccile Le Pape, Landry Breuil, Loc Cudennec et videmment toi Mathieu ! Je vous remercie pour toute laide que vous mavez apporte, pour nos discussions, vos relectures et commentaires. . . La liste est longue ! Je remercie galement tous mes amis davoir compris quune thse ctait une passion et demandait beaucoup de disponibilit. Je pense en particulier Nathalie, Joris et Lise-Marie. Ces remerciements vont galement ma famille, en particulier toi Sophie, merci pour tous tes petits messages dencouragement sur la n, cela ma vraiment aid... Mathieu, tu mas dit lorsque jai commenc ma thse : je suis content que tu fasses ta thse avec nous. De mon ct, je suis ravi davoir fait ma thse tes cts, tes qualits font de toi un bon collgue, mais aussi plus que a ;-). Un merci tout particulier pour Caroline. Merci simplement dtre l, de mavoir soutenu, encourag, aid. Merci pour tes relectures bien sr, mais surtout merci davoir accept dtre ma femme ! Enn je remercie mes parents. Claude, tu as toujours t l pour nous, jai toujours su que je pouvais compter sur toi en toute occasion, merci, merci dtre toi. Mon dernier remerciement, cest pour toi Dominique. . .
tel-00411447, version 1 - 27 Aug 2009
tel-00411447, version 1 - 27 Aug 2009
Table des matires
Liste des dnitions 1 Introduction 1.1 Objectifs de la thse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Contributions et publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Organisation du manuscrit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ix 1 2 3 5
tel-00411447, version 1 - 27 Aug 2009
Partie I Contexte dtude : gestion des donnes dans les grilles de calcul
2 Les donnes dans les grilles de calcul 2.1 Les grilles de calcul . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 Historique et dnition . . . . . . . . . . . . . . . . . . . 2.1.2 Les fdrations de grappes . . . . . . . . . . . . . . . . . 2.1.3 Un exemple de grille : Grid5000 . . . . . . . . . . . . . . 2.2 Les applications de couplage de codes . . . . . . . . . . . . . . . 2.2.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.2 Exemple dapplication . . . . . . . . . . . . . . . . . . . . 2.2.3 Les grilles de calcul : une solution pour les applications de codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Approches pour le partage de donnes dans les grilles . . . . . . 2.3.1 Le partage de donnes dans les grilles de calcul . . . . . 2.3.2 Systmes existants . . . . . . . . . . . . . . . . . . . . . . 2.3.3 Limites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4 Problmes induits par la dynamicit de la grille . . . . . . . . . . 2.5 Tolrance aux fautes et gestion de la cohrence dans les grilles . 3 Approches pour la gestion de la tolrance aux fautes 3.1 Notion de faute . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 Dfaillances, erreurs et fautes . . . . . . . . . . . . 3.1.2 Types de dfaillance . . . . . . . . . . . . . . . . . 3.1.3 Quel modle de fautes pour les grilles de calcul ? 3.1.4 Comment faire face aux fautes ? . . . . . . . . . . 3.2 Dtection de dfaillances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . de . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . couplage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
9 10 10 11 12 13 13 14 15 17 17 17 19 20 21 23 24 24 25 26 28 28
vi
Table des matires 3.2.1 Principes gnraux . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.2 Classication des dtecteurs de dfaillances . . . . . . . . . . 3.2.3 Mise en uvre de dtecteurs de dfaillances . . . . . . . . . . 3.2.4 Passage lchelle . . . . . . . . . . . . . . . . . . . . . . . . . Techniques de rplication . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.1 Gestion des groupes de copies . . . . . . . . . . . . . . . . . . 3.3.2 Propagation des mises jour . . . . . . . . . . . . . . . . . . . 3.3.3 Utilisation de groupes de copies . . . . . . . . . . . . . . . . . Sauvegarde de points de reprise . . . . . . . . . . . . . . . . . . . . . . 3.4.1 Principe de base . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.2 Points de reprise coordonns . . . . . . . . . . . . . . . . . . . 3.4.3 Points de reprise non-coordonns . . . . . . . . . . . . . . . . Tolrance aux fautes dans les grilles : vers une approche hirarchique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 29 30 31 32 32 33 34 34 35 36 36 37 39 40 40 41 41 42 44 44 45 46 48 48 49 50 50
3.3
3.4
3.5
tel-00411447, version 1 - 27 Aug 2009
4 Approches pour la gestion de la cohrence de donnes 4.1 Modles et protocoles de cohrence dans les systmes mmoire virtuellement partage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.1 Notion de cohrence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.2 Modles de cohrence forte . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.3 Modles de cohrence relche . . . . . . . . . . . . . . . . . . . . . . . 4.1.4 Approches pour la localisation des donnes . . . . . . . . . . . . . . . 4.2 Modles et protocoles de cohrence dans les systmes pair--pair . . . . . . . 4.2.1 Les systmes pair--pair . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.2 Approches pour la localisation des donnes . . . . . . . . . . . . . . . 4.2.3 Cohrence des donnes dans les systmes pair--pair . . . . . . . . . . 4.3 Modles et protocoles de cohrence dans les bases de donnes . . . . . . . . . 4.3.1 Particularit des donnes . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.2 Notion de transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.3 Cohrence de donnes rpliques : divergence et rconciliation . . . . 4.4 Cohrence de donnes dans les grilles : vers une approche hirarchique . . .
Partie II Notre contribution : une approche hirarchique conjointe pour la tolrance aux fautes et la cohrence des donnes 53
5 tude de cas : vers un protocole de cohrence des donnes tolrant aux fautes pour la grille 5.1 Le partage de donnes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Un exemple de protocole non tolrant aux fautes . . . . . . . . . . . . . . . . . 5.2.1 Le modle de cohrence lentre . . . . . . . . . . . . . . . . . . . . . 5.2.2 Un protocole bas sur une copie de rfrence . . . . . . . . . . . . . . . 5.2.3 Fonctionnement du protocole de cohrence . . . . . . . . . . . . . . . . 5.3 Un protocole de cohrence hirarchique . . . . . . . . . . . . . . . . . . . . . . 5.3.1 Limites dun protocole plat . . . . . . . . . . . . . . . . . . . . . . . . 5.3.2 Solution : un protocole hirarchique . . . . . . . . . . . . . . . . . . . . 5.4 Un protocole de cohrence tolrant aux fautes . . . . . . . . . . . . . . . . . . 55 56 57 57 58 58 62 62 62 65
Table des matires 5.4.1 Ncessit de tolrer les fautes . . . . . . . . . . . . . . . . . . . . . . . . 5.4.2 Utilisation de techniques de rplication . . . . . . . . . . . . . . . . . . Vers un protocole hirarchique tolrant aux fautes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . de . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . tolrance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
vii 65 66 68 69 70 70 72 74 75 75 79 80 80 81 82
5.5
tel-00411447, version 1 - 27 Aug 2009
6 Une approche conjointe 6.1 Cadre : le service de partage de donnes J UX M EM . . . . . . . . 6.1.1 Notion de service de partage de donnes pour la grille . 6.1.2 Architecture gnrale . . . . . . . . . . . . . . . . . . . . 6.1.3 Le noyau JuxMem . . . . . . . . . . . . . . . . . . . . . . 6.2 Proposition : une architecture en couches . . . . . . . . . . . . . 6.2.1 Un double besoin de rplication . . . . . . . . . . . . . . 6.2.2 La couche de communication de groupe . . . . . . . . . . 6.2.3 La couche dadaptation aux fautes . . . . . . . . . . . . . 6.2.4 Les protocoles de cohrence . . . . . . . . . . . . . . . . . 6.3 Interactions entre le protocole de cohrence et les mcanismes aux fautes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4 Vers une approche gnrique . . . . . . . . . . . . . . . . . . . .
7 Gestion hirarchique de la rplication et de la cohrence des donnes 7.1 Gestion hirarchique de la cohrence . . . . . . . . . . . . . . . . . . 7.1.1 Limites dun protocole non-hirarchique . . . . . . . . . . . 7.1.2 Une vision hirarchique . . . . . . . . . . . . . . . . . . . . . 7.1.3 Des protocoles de cohrence hirarchiques . . . . . . . . . . 7.2 Gestion hirarchique de la tolrance aux fautes . . . . . . . . . . . . 7.2.1 Dtecteurs de fautes bass sur une approche hirarchique . 7.2.2 Protocole hirarchique de composition de groupe . . . . . . 7.2.3 Propagation des messages . . . . . . . . . . . . . . . . . . . . 7.3 Un exemple de scnario . . . . . . . . . . . . . . . . . . . . . . . . . 7.4 Mcanismes complmentaires . . . . . . . . . . . . . . . . . . . . . . 7.5 La hirarchie : une solution gnrique pour les grilles ? . . . . . . .
85 . 86 . 86 . 86 . 87 . 89 . 89 . 92 . 93 . 95 . 98 . 100
Partie III Mise en uvre et valuation

8 Exemple de mise en uvre dun protocole de cohrence tolrant aux fautes 8.1 Mise en uvre de larchitecture en couches . . . . . . . . . . . . . . . . . 8.1.1 Architecture logicielle gnrale . . . . . . . . . . . . . . . . . . . . 8.1.2 Les protocoles de cohrence . . . . . . . . . . . . . . . . . . . . . . 8.1.3 Les mcanismes de tolrance aux fautes . . . . . . . . . . . . . . . 8.2 Mise en uvre dun protocole de cohrence hirarchique . . . . . . . . . 8.2.1 Mise en uvre sur le client . . . . . . . . . . . . . . . . . . . . . . 8.2.2 Mise en uvre sur les fournisseurs . . . . . . . . . . . . . . . . . . 8.2.3 Fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3 Mise en uvre des groupes auto-organisants . . . . . . . . . . . . . . . . 8.3.1 Mise en place de la rplication . . . . . . . . . . . . . . . . . . . . 8.3.2 Auto-organisation des groupes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
101
103 104 104 106 108 109 110 111 112 113 113 115
viii 8.4 Un protocole tendu pour une visualisation efcace 8.4.1 La lecture relche . . . . . . . . . . . . . . . 8.4.2 Fentre de lecture . . . . . . . . . . . . . . . . 8.4.3 Analyse de la smantique des paramtres . . Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table des matires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 116 117 117 118 119 120 120 121 121 122 126 129 130 132
8.5
tel-00411447, version 1 - 27 Aug 2009
9 valuation 9.1 Mthodologie dexprimentation . . . . . . . . . . 9.1.1 Exprimentations sur architectures relles . 9.1.2 Injection de fautes de type panne franche . 9.2 Exprimentations avec J UX M EM . . . . . . . . . . 9.2.1 Cot d la rplication . . . . . . . . . . . 9.2.2 Bnce de lapproche hirarchique . . . . 9.2.3 valuations multi-protocole . . . . . . . . . 9.2.4 Impact des fautes sur les performances . . 9.3 Discussion . . . . . . . . . . . . . . . . . . . . . . .
Partie IV Conclusion et perspectives

10 Conclusion et perspectives Rfrences
135
137 143
Partie V Annexes
A.1 Prise en compte des applications au niveau dun rseau logique pair--pair A.1.1 Un rseau logique mallable . . . . . . . . . . . . . . . . . . . . . . . A.1.2 Exemples de scnarios . . . . . . . . . . . . . . . . . . . . . . . . . . . A.2 Conception dun rseau logique pair--pair mallable . . . . . . . . . . . . . A.2.1 Conserver la connectivit du rseau . . . . . . . . . . . . . . . . . . . A.2.2 Communication de groupe . . . . . . . . . . . . . . . . . . . . . . . . A.3 valuation du rseau logique pair--pair MO VE . . . . . . . . . . . . . . . . A.3.1 Simulation par vnements discrets . . . . . . . . . . . . . . . . . . . A.3.2 Adaptation du rseau logique. . . . . . . . . . . . . . . . . . . . . . . A.3.3 Partage de liens applicatifs. . . . . . . . . . . . . . . . . . . . . . . . . A.3.4 Connectivit au sein des groupes. . . . . . . . . . . . . . . . . . . . . A.3.5 Tolrance aux fautes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.4 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . .
153
155 155 157 158 160 161 162 163 164 164 165 166 166
ix
Liste des dnitions

2.1 2.2 2.3 2.4 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 4.1 4.2 4.3 7.1 7.2 A.1 Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Grille informatique . . . . . . . . . . . . . . . . . . . . . . Grappe de calculateurs . . . . . . . . . . . . . . . . . . . . Temps moyen interfaute (Mean Time Between Failures) . . Dfaillance (failure) . . . . . . . . . . . . . . . . . . . . . . Erreur (error) . . . . . . . . . . . . . . . . . . . . . . . . . . Faute (fault) . . . . . . . . . . . . . . . . . . . . . . . . . . Dfaillance franche ou crash (fail-stop) . . . . . . . . . . . Dfaillance par omission (omission failure) . . . . . . . . . Dfaillance byzantine (byzantine failure) . . . . . . . . . . Canaux de communication quitables (fair lossy channels) Systme asynchrone . . . . . . . . . . . . . . . . . . . . . Compltude (completeness) . . . . . . . . . . . . . . . . . . Justesse (accuracy) . . . . . . . . . . . . . . . . . . . . . . . Diffusion atomique . . . . . . . . . . . . . . . . . . . . . . Dpendance fonctionnelle . . . . . . . . . . . . . . . . . . Dpendance dinclusion . . . . . . . . . . . . . . . . . . . Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . Local Data Group . . . . . . . . . . . . . . . . . . . . . . . . Global Data Group . . . . . . . . . . . . . . . . . . . . . . . Rseau logique mallable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 . 11 . 11 . 20 . 24 . 24 . 24 . 25 . 25 . 26 . 27 . 28 . 30 . 30 . 34 . 48 . 48 . 49 . 93 . 93 . 156
tel-00411447, version 1 - 27 Aug 2009
tel-00411447, version 1 - 27 Aug 2009
Chapitre
1
2 3 5
Introduction
tel-00411447, version 1 - 27 Aug 2009
Sommaire
1.1 1.2 1.3 Objectifs de la thse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Contributions et publications . . . . . . . . . . . . . . . . . . . . . . . . . . Organisation du manuscrit . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Homme a soif de connatre son avenir et de comprendre ce qui lentoure. cette n, de nombreux instruments de mesure ont t invents. Actuellement, ces instruments devenus trs prcis gnrent de grandes quantits de donnes. Pour mieux apprhender le monde qui lentoure, lHomme utilise ces donnes pour modliser son environnement. En analysant les modles et en simulant leur volution, il devient possible de comprendre des phnomnes et systmes complexes ou den inventer de nouveaux, et mme de prvoir leurs possibles volutions. Cependant, les instruments de mesure, trs prcis, peuvent gnrer quotidiennement de grandes masses de donnes. Les modles deviennent galement de plus en plus complexes et prennent en compte un nombre de paramtres sans cesse grandissant. Simuler lvolution de tels modles demande donc une puissance de calcul et de stockage de plus en plus grande. Par exemple, en Californie, dans le cadre du projet TeraShake [127], la simulation de tremblements de terre servant prvoir les consquences de secousses dans cette rgion doit prendre en compte une masse considrable dinformations sur la topologie et la structure des terrains ainsi que sur les forces physiques entrant en jeu. Ce genre de simulation manipule de gigantesques quantits de donnes : au sein du projet TeraShake, les simulations prennent en entre des centaines de gigaoctets et gnrent des rsultats de lordre de plusieurs dizaines de traoctets. Les chercheurs ont donc besoin dun instrument pouvant stocker et exploiter une masse dinformation considrable. Face cette demande croissante de puissance, les grilles de calcul apparaissent de plus en plus comme la solution de demain. En effet, ces architectures permettent dadditionner les
Chapitre 1 Introduction ressources matrielles pour former un ensemble offrant une capacit de stockage et de calcul virtuellement innie. Cependant une grille de calcul est un instrument particulirement complexe car il est compos de milliers de machines souvent htrognes et rparties gographiquement dans des institutions qui mettent en commun leurs ressources. De plus, de nouvelles ressources peuvent tre ajoutes tout moment, de mme que des ressources prsentes peuvent disparatre (pannes, arrts volontaires). Par consquent, les concepteurs dapplication sappuient sur des services logiciels permettant de simplier lexploitation des grilles de calcul, dabstraire une partie de cette complexit et de masquer partiellement lhtrognit des ressources utilises. Les dix dernires annes ont ainsi vu natre des services ddis certains de ces aspects. Il existe notamment des services permettant de dployer des applications sur une grille, de rechercher des ressources disponibles (matrielles ou logicielles), etc. Pourtant la conception dapplications distribues pour les grilles de calcul reste complexe. En effet, le partage de donnes reste un problme difcile : si les applications sont distribues, cest galement le cas des donnes auxquelles elles accdent. Celles-ci se trouvent souvent rpliques sur plusieurs machines et le concepteur dapplication doit prendre en compte ces multiples copies : il doit pouvoir les localiser, les transfrer et maintenir leur cohrence alors que de multiples processus rpartis dans la grille sont susceptibles de les modier. Cette tche est dautant plus dure si lon considre que les fautes et dconnexions de machines sont courantes dans les grilles de calcul et quelles peuvent entraner une perte de donnes : si toutes les machines qui stockent une mme donne tombent en panne ou se dconnectent, la donne nest plus accessible.
tel-00411447, version 1 - 27 Aug 2009
1.1 Objectifs de la thse

Cette thse sinscrit dans le cadre de la conception du service de partage de donnes pour la grille J UX M EM [129] (pour langlais juxtaposed memory). Ce service est dvelopp au sein de lquipe PARIS [123], dans le cadre du projet Grid Data Service (GDS [111]) de lACI Masse de Donnes, qui a dbut en 2003. J UX M EM se propose de rpondre aux besoins mentionns ci-dessus. En particulier son objectif est doffrir les proprits suivantes. Persistance. Le stockage au sein de la grille doit tre persistant, cest--dire quune donne dont la gestion est cone un service de gestion de donnes doit rester disponible au cours du temps. Les grilles de calcul tant des systmes dynamiques composs de machines susceptibles de tomber en panne ou de se dconnecter, assurer la persistance des donnes implique la mise en place de mcanismes de tolrance aux fautes. Localisation et transfert transparents. Les problmes lis la localisation des donnes ainsi qu leur transfert peuvent tre traits au sein du service de gestion de donnes pour la grille. Ceci a pour but de simplier le partage de donnes au niveau des applications. Ainsi, les applications peuvent accder aux donnes partages via des identicateurs globaux qui rendent transparents la localisation et le transfert des donnes. Cohrence. La cohrence des donnes partages rpliques doit tre prserve. Ceci peut tre ralis par la mise en place de mcanismes de synchronisation an de traiter les mises jour concurrentes ainsi que par des mcanismes de propagations des mises jour entre les copies dune mme donne. L encore, il est ncessaire de prendre
1.2 Contributions et publications en compte la nature dynamique des grilles, les diffrentes copies dune donne tant susceptibles de disparatre tout moment. Dans ce contexte, cette thse sintresse particulirement aux problmes lis la tolrance aux fautes et la gestion de la cohrence des donnes. Nous proposons des solutions pour grer conjointement ces deux problmes. La section suivante dtaille nos contributions.
1.2 Contributions et publications

Architecture dcouple gnrique. Les problmes lis la tolrance aux fautes et ceux lis la gestion de la cohrence des donnes sont en troite relation. Aussi avonsnous conu une architecture en couches permettant de dcoupler ces deux problmatiques [ADM06]. Cette architecture permet de mettre en uvre des protocoles de cohrence indpendamment des mcanismes de tolrance aux fautes et rciproquement. De plus, sa mise en uvre permet linstanciation de diffrentes combinaisons protocoles de cohrence/mcanismes de tolrance aux fautes, offrant ainsi aux applications utilisatrices du service le choix de la combinaison la mieux adapte. Protocoles de cohrences hirarchiques. Les grilles de calcul prsentent une architecture particulire : nous verrons au chapitre suivant quelles ont souvent des topologies rseaux hirarchiques. Les protocoles de cohrence classiques sont mal adapts de telles architectures (ils sont gnralement peu performants). Nous proposons une approche hirarchique qui permet dadapter de nombreux protocoles de cohrence existants aux grilles de calcul [ADM06, ACM06, ACM06b]. Mcanismes de rplication hirarchiques. Les mcanismes de rplication tudis dans la littrature reposent souvent sur des synchronisations entre les diffrents acteurs or certains liens rseau des grilles de calcul prsentent des latences leves rendant ces synchronisations trs coteuses en terme de performance. De mme que pour les protocoles de cohrence, nous proposons une approche hirarchique pour les mcanismes de rplication [ADM06]. Cette approche consiste exploiter la structure hirarchique des rseaux des grilles pour offrir des mcanismes adapts aux grilles de calcul. Mcanismes de points de reprise pour les grilles. Les applications distribues sexcutant sur les grilles de calcul peuvent avoir des temps dexcution longs, de lordre de plusieurs jours, voire plusieurs semaines. Si une ressource sur laquelle sexcute une partie dune application tombe en panne, il peut tre intressant de reprendre lexcution de lapplication au niveau dun tat pralablement sauvegard, et non de la relancer compltement lapplication. Nous proposons dans [MMB04a] et [MMB04b] des mcanismes hirarchiques de sauvegarde de points de reprise pour les grilles. Ces mcanismes peuvent tre employs par les applications utilisant notre service de partage de donnes. Rseau logique mallable. Aprs avoir tudi une approche hirarchique pour la gestion des groupes de rplication au sein des grilles, nous nous sommes intresss une approche permettant de viser une plus grande chelle. Cette approche, prsente en annexe, se base sur des mcanismes probabilistes offrant une maintenance plus aise, mais des garanties restreintes. Nous avons introduit le concept de rseau logique mallable [MMAG06]. Il sagit dun rseau logique pair--pair qui peut sadapter aux applications an de mettre en place des mcanismes de rplication efcaces.
tel-00411447, version 1 - 27 Aug 2009
Chapitre 1 Introduction
Articles dans des revues internationales

[ADM06] Gabriel Antoniu, Jean-Franois Deverge, and Sbastien Monnet. How to bring together fault tolerance and data consistency to enable grid data sharing. Concurrency and Computation : Practice and Experience, 18(13) :17051723, November 2006. Extended and revised version of [ADM04].
Chapitres de livres
[ABC+ 06] Gabriel Antoniu, Marin Bertier, Eddy Caron, Frdric Desprez, Luc Boug, Mathieu Jan, Sbastien Monnet, and Pierre Sens. GDS : An architecture proposal for a grid data-sharing service. In V. Getov, D. Laforenza, and A. Reinefeld, editors, Future Generation Grids, CoreGRID series, pages 133152. Springer, 2006.
Confrences internationales avec comit de lecture
tel-00411447, version 1 - 27 Aug 2009
[MMAG06] Sbastien Monnet, Ramss Morales, Gabriel Antoniu, and Indranil Gupta. MOve : Design of An Application-Malleable Overlay. In Symposium on Reliable Distributed Systems 2006 (SRDS 2006), pages 355364, Leeds, UK, October 2006. [ACM06] Gabriel Antoniu, Loc Cudennec, and Sbastien Monnet. Extending the entry consistency model to enable efcient visualization for code-coupling grid applications. In 6th IEEE/ACM International Symposium on Cluster Computing and the Grid (CCGrid 2006), pages 552555, Singapore, May 2006. Sbastien Monnet and Marin Bertier. Using failure injection mechanisms to experiment and evaluate a grid failure detector. In Workshop on Computational Grids and Clusters (WCGC 2006), Rio de Janeiro, Brazil, July 2006. Held in conjunction with VECPAR06. Selected for publication in the post-conference book.
[MB06]
[ACM06b] Gabriel Antoniu, Loc Cudennec, and Sbastien Monnet. A practical evaluation of a data consistency protocol for efcient visualization in grid applications. In International Workshop on High-Performance Data Management in Grid Environment (HPDGrid 2006), Rio de Janeiro, Brazil, July 2006. Held in conjunction with VECPAR06. Selected for publication in the post-conference book. [ABJM04] Gabriel Antoniu, Luc Boug, Mathieu Jan, and Sbastien Monnet. Large-scale deployment in P2P experiments using the JXTA distributed framework. In EuroPar 2004 : Parallel Processing, number 3149 in Lect. Notes in Comp. Science, pages 10381047, Pisa, Italy, August 2004. Springer-Verlag. [MMB04a] Sbastien Monnet, Christine Morin, and Ramamurthy Badrinath. A hierarchical checkpointing protocol for parallel applications in cluster federations. In 9th IEEE Workshop on Fault-Tolerant Parallel Distributed and Network-Centric Systems, page 211, Santa Fe, New Mexico, April 2004. Held in conjunction with IPDPS 2004, IEEE. [ADM04] Gabriel Antoniu, Jean-Franois Deverge, and Sbastien Monnet. Building faulttolerant consistency protocols for an adaptive grid data-sharing service. In Proc. ACM Workshop on Adaptive Grid Middleware (AGridM 2004), Antibes Juan-lesPins, France, September 2004. Available as INRIA Research Report RR-5309.
1.3 Organisation du manuscrit [MMB04b] Sbastien Monnet, Christine Morin, and Ramamurthy Badrinath. Hybrid checkpoi nting for parallel applications in cluster federations. In 4th IEEE/ACM International Symposium on Cluster Computing and the Grid (CCGrid 2004), Chicago, IL, USA, April 2004. Poster, electronic version.
Confrences nationales avec comit de lecture

[CM05] Loc Cudennec and Sbastien Monnet. Extension du modle de cohrence lentre pour la visualisation dans les applications de couplage de code sur grilles. In Actes des Journes francophones sur la Cohrence des Donnes en Univers Rparti, Paris, November 2005. Jean-Franois Deverge and Sbastien Monnet. Cohrence et volatilit dans un service de partage de donnes dans les grilles de calcul. In Actes des Rencontres francophones du paralllisme (RenPar 16), pages 4755, Le Croisic, April 2005.
[DM05]
tel-00411447, version 1 - 27 Aug 2009
1.3 Organisation du manuscrit

Dans la premire partie de ce manuscrit, nous prsentons le contexte de nos travaux et les travaux existants. Le chapitre 2 prsente le cadre dans lequel se situe notre travail. Il dcrit les grilles de calcul ainsi que les contraintes imposes par ces architectures et les applications de couplage de codes vises par notre service de partage de donnes. Le chapitre 3 donne la dnition et la description des diffrents types de faute qui peuvent survenir dans les grilles de calcul. Il propose galement un aperu de ltat de lart des mcanismes de tolrance aux fautes. Le chapitre 4 dnit la cohrence des donnes et propose un tour dhorizon de la gestion de la cohrence des donnes dans les grappes de calculateurs, les bases de donnes et les systmes pair--pair. La deuxime partie prsente notre contribution pour la gestion conjointe de la tolrance aux fautes et de la cohrence des donnes au sein dun service de partage de donnes pour la grille. Nous commenons par une tude de cas au chapitre 5 an de mettre en vidence les problmatiques de tolrance aux fautes et de gestion de la cohrence des donnes dans les grilles. Une solution est esquisse sur un exemple. Le chapitre 6 dcrit notre architecture logicielle permettant de grer conjointement les aspects lis la tolrance aux fautes et ceux lis la gestion de la cohrence des donnes. Au chapitre 7, nous gnralisons les ides de solutions prsentes au chapitre 5 et proposons une mthode pour rendre des protocoles de cohrence existants tolrants aux fautes et adapts aux grilles de calcul. Dans la troisime partie, nous prsentons des lments de mise en uvre de nos travaux ainsi quune valuation des solutions proposes. La mise en uvre de larchitecture prsente au chapitre 6 ainsi quun exemple de protocole hirarchique tolrant aux fautes sont prsents au chapitre 8. Le chapitre 9 dcrit une valuation de notre contribution.
Chapitre 1 Introduction Le chapitre 10 conclut ce manuscrit et prsente les perspectives offertes par nos travaux. Enn, une annexe propose une approche alternative permettant la gestion de donnes partages en environnement volatil, lchelle des systmes pair--pair. Il correspond un travail effectu lors dune collaboration et sort du cadre proprement dit du service de partage de donnes pour la grille.
tel-00411447, version 1 - 27 Aug 2009
Premire partie
tel-00411447, version 1 - 27 Aug 2009
Contexte dtude : gestion des donnes dans les grilles de calcul
tel-00411447, version 1 - 27 Aug 2009
Chapitre
2
10 10 11 12 13 13 14 15 17 17 17 19 20 21
Les donnes dans les grilles de calcul

tel-00411447, version 1 - 27 Aug 2009
Sommaire
2.1 Les grilles de calcul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 Historique et dnition . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.2 Les fdrations de grappes . . . . . . . . . . . . . . . . . . . . . . . . 2.1.3 Un exemple de grille : Grid5000 . . . . . . . . . . . . . . . . . . . . . Les applications de couplage de codes . . . . . . . . . . . . . . . . . . . . . 2.2.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.2 Exemple dapplication . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.3 Les grilles de calcul : une solution pour les applications de couplage de codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Approches pour le partage de donnes dans les grilles . . . . . . . . . . . . 2.3.1 Le partage de donnes dans les grilles de calcul . . . . . . . . . . . . 2.3.2 Systmes existants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.3 Limites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Problmes induits par la dynamicit de la grille . . . . . . . . . . . . . . . . Tolrance aux fautes et gestion de la cohrence dans les grilles . . . . . . .
2.2
2.3
2.4 2.5
Les grilles de calcul sont de plus en plus utilises, aussi bien dans le monde de la recherche que dans celui de lindustrie. Il sagit en effet dun instrument puissant, permettant de traiter des problmes difciles faisant appel de nombreuses donnes de taille importante. Cependant, la conception dapplications pour ce type de systme est complexe. Les applications sont composes de processus distribus gographiquement sexcutant sur les nuds appartenant aux grilles. Lors de lexcution dune application distribue, les processus qui la composent cooprent notamment en partageant des donnes. Nous allons montrer que la gestion des donnes partages entre plusieurs processus au sein dune grille de calcul reprsente un facteur limitant dans la conception dapplications pour la grille. Les
10
Chapitre 2 Les donnes dans les grilles de calcul
donnes partages doivent en effet pouvoir tre localises, transfres et modies de manire concurrente par de multiples processus. Cette tche est dautant plus complexe que les nuds dune grille de calcul peuvent tomber en panne ou se dconnecter. Dans ce chapitre, nous dcrivons le cadre de notre travail : le partage de donnes pour les applications distribues sexcutant sur des grilles de calcul. Dans un premier temps, nous prsentons notre vision des architectures de type grille de calcul et en donnons une dnition (section 2.1). Les besoins en terme de partage de donnes ne sont pas les mmes pour tous les types dapplications distribues. Dans notre tude, nous nous concentrons sur un type dapplication distribue particulier : les applications de couplage de codes. Nous prsentons en dtail ce type dapplication la section 2.2. Ensuite, nous proposons un aperu des mcanismes actuellement utiliss pour le partage de donnes au sein des grilles et mettons en vidence leurs limites. Dans ce manuscrit, nous nous intressons plus particulirement aux problmes lis la gestion de la cohrence des donnes en prsence de fautes, cest pourquoi ces problmes sont mis en vidence dans la section 2.4. Enn, la section 2.5 conclut ce chapitre sur une discussion autour de la gestion de la cohrence des donnes partages et la tolrance aux fautes dans les environnements de type grille.
tel-00411447, version 1 - 27 Aug 2009
2.1 Les grilles de calcul

Lobjectif de cette section est de dnir ce que nous entendons par grille de calcul. La recherche autour des grilles de calcul est trs intense, il existe de multiples approches. Nous allons ici prsenter notre approche des grilles de calcul.
2.1.1
Historique et dnition
Le mot grille vient de langlais grid qui a t choisi par analogie avec le systme de distribution dlectricit amricain (electric power grid), ce terme t rpandu en 1998 par louvrage de Ian Foster et Carl Kesselman [70]. En effet, une grille peut tre vue comme un instrument qui fournit de la puissance de calcul et/ou de la capacit de stockage de la mme manire que le rseau lectrique fournit de la puissance lectrique. La vision des inventeurs de ce terme est quil sera possible, terme, de se brancher sur une grille informatique pour obtenir de la puissance de calcul et/ou de stockage de donnes sans savoir ni o ni comment cette puissance est fournie, limage de ce qui se passe pour llectricit. Lanalogie avec le systme de distribution dlectricit permet de cerner la vision dune grille dun point de vue utilisateur. Notre travail se situe au sein mme des grilles, nous avons donc besoin de dnir comment cette puissance est fournie. Nous commenons par dnir ce quest un site dune grille, pour cela nous reprenons la dnition de [74]. Dnition 2.1 : site Un site est un ensemble de ressources informatiques localises gographiquement dans une mme organisation (campus universitaire, centre de calcul, entreprise ou chez un individu) et qui forment un domaine dadministration autonome, uniforme et coordonn.
2.1 Les grilles de calcul
11
Les ressources informatiques sont aussi bien des liens rseau (cbles, routeurs ou switchs) des machines (simples PC ou calculateurs parallles) ou des lments logiciels. Nous pouvons maintenant dnir une grille informatique. Dnition 2.2 : grille informatique Une grille informatique mutualise un ensemble de ressources informatiques gographiquement distribues dans diffrents sites. Il est important de noter que les grilles informatiques sont, par nature, dynamiques : 1) les sites peuvent quitter ou rejoindre la grille tout moment ; 2) de mme, au sein de chaque site, de nouvelles ressources peuvent tre ajoutes, dautres peuvent tomber en panne ou tre dconnectes. Il existe diffrents types de grille informatique. On distingue notamment les grilles de donnes et les grilles de calcul.
tel-00411447, version 1 - 27 Aug 2009
Les grilles de donnes (data grid) sont principalement utilises pour le stockage de grandes masses de donnes. Elles sont gnralement composes de ressources offrant une grande capacit de stockage, en mmoire et sur disque. Les grilles de calcul (computational grid) sont ddies aux calculs intensifs. Une grande importance est alors donne la puissance des processeurs des nuds qui la composent. Dans ce manuscrit, bien que nous nous intressions la gestion de donnes dans les grilles, nous parlons de grilles de calcul. En effet, nous nous focalisons sur la gestion de donnes partages par des applications scientiques distribues effectuant des calculs sur des grilles de calcul.
2.1.2
Les fdrations de grappes
Les ressources mises en commun par les sites tant souvent des grappes de calculateurs, nous allons nous concentrer sur un type particulier de grille : les fdrations de grappes. Dnition 2.3 : grappe de calculateurs Une grappe de calculateurs est un ensemble de nuds (typiquement des PC) interconnects par un rseau trs faible latence et haut dbit de type SAN (System Area Network) ou LAN (Local Area Network). Gnralement, les nuds dune grappe se situent dans une mme pice et sont relis entre eux par des switchs. Lorsque les ressources partages par tous les sites dune grille sont des grappes de calculateurs, on obtient une fdration de grappes. On remarque que la topologie rseau de cette architecture, reprsente sur la gure 2.1, est hirarchique : tous les nuds dun site sont interconnects entre eux, alors que les diffrents sites sont gnralement connects par un seul lien rseau. De plus, les liens rseau reliant les nuds dune grappe (en traits pleins sur la gure) ont de trs faibles latences1 compars aux liens rseau reliant les sites entre eux (en pointills sur la gure) .
1
Au sein dune grappe, il ny a pas de routeur, le seul quipement traverser entre deux nuds est un switch.
12
Calculateur
tel-00411447, version 1 - 27 Aug 2009
Switch Lien rseau intragrappe Lien rseau intergrappe
F IG . 2.1 Un cas particulier de grilles : les fdrations de grappes.
2.1.3
Un exemple de grille : Grid5000
En France, un important projet de grille de calcul a t lanc en 2003 : le projet Grid5000 [113, 26]. Son but est de fdrer des grappes de calculateurs rparties dans 9 diffrents sites gographiques en France : Bordeaux, Grenoble, Lille, Lyon, Nancy, Orsay, Rennes, Sophia-Antipolis et Toulouse. La gure 2.2 reprsente les 9 sites interconnects par le rseau Renater [125] (correspondant aux traits reliant les sites sur la carte de la gure 2.2). Ce rseau est en cours de transition2 et va offrir un dbit de 10 Gb/s pour des latences allant de 3 14 ms3 . terme, Grid5000 devrait comporter 5000 processeurs rpartis dans ces 9 sites. Au sein des sites, les nuds sont interconnects par des rseaux trs faible latence comme Myrinet [119] (pour lequel la latence entre deux nuds est de lordre de 2 s). Il y a donc un rapport de latence de lordre dun facteur 10.000 entre les liens intergrappe et les liens intragrappe. Ce type de grille de calcul correspond ce que nous visons : cest sur cette plate-forme que nous avons expriment nos contributions. Dans le monde, il existe de nombreux autres projets de grille comme TeraGrid aux tats Unis [126] ou EUROGRID en Europe [109].
Actuellement, certains liens offrent des dbits de 10 Gb/s et dautres des dbits de 1 Gb/secondes, ces derniers sont en cours de remplacement. 3 La variation est essentiellement due la distance gographique.
2.2 Les applications de couplage de codes
13
tel-00411447, version 1 - 27 Aug 2009
F IG . 2.2 Carte des sites du projet Grid5000.

Nous venons de dnir les grilles de calcul et plus particulirement les fdrations de grappes de calculateurs. Les applications sexcutant sur ce type darchitecture sont distribues : elles sont dcomposes en sous-tches, appeles processus, qui sexcutent sur des nuds de la grille. Les applications distribues, composes de multiples processus, peuvent donc effectuer des tches en parallle : cest ce qui permet dobtenir une grande puissance de calcul. Lors de lexcution de lapplication, ces processus vont accder aux donnes de lapplication. Certaines donnes seront donc partages par plusieurs processus. Nous nous concentrons sur un type particulier dapplications pour lesquelles les grilles sont bien adaptes : les applications de couplage de codes.
2.2.1
Description
Une application dite de couplage de codes est une application distribue particulire. Elle est compose de plusieurs codes ventuellement parallles qui cooprent une mme n. Les changes entre les nuds hbergeant une application de couplage de codes prsentent par consquent une structure hirarchique : ils seront plus frquents entre les nuds hbergeant un mme code quentre les nuds hbergeant deux codes diffrents, faiblement coupls. Les applications de couplage de codes prsentent donc une topologie de partage de donnes hirarchique deux niveaux : au niveau des codes parallles et au niveau de lapplication compose des codes parallles.
14
Optique
Thermodynamique
Mcanique
Code parallle
tel-00411447, version 1 - 27 Aug 2009
Interactions entre les codes parallles (couplage)
F IG . 2.3 Une application de couplage de codes : des codes parallles qui interagissent.
2.2.2
Exemple dapplication
La gure 2.3 illustre un exemple dapplication de couplage de codes. Cette application consiste en la simulation dun satellite. Un tel objet fait intervenir plusieurs physiques telles que la thermodynamique, loptique ou encore la mcanique. Chacune de ces physiques peut tre simule par un code parallle au sein dune grappe, et de temps en temps, ltat global de la simulation reprsentant le satellite dans son ensemble peut tre mis jour au sein des diffrents codes parallles. Les applications de couplage de codes font intervenir plusieurs codes de simulation numrique (souvent parallles) sexcutant chacun sur une grappe de calculateurs et changeant de temps en temps des informations (via des donnes partages par exemple) an de simuler un systme complexe. Lapplication HydroGrid [128] est un autre exemple concret. Son but est de simuler des transferts de uides et de transport de soluts dans des milieux gologiques souterrains. Ces simulations ont pour but dapprhender des phnomnes lis la contamination des aquifres par des polluants, lintrusion deau sale dans les aquifres ou le stockage profond de dchets nuclaires. Ces problmes font appel diffrents phnomnes physico-chimiques, chacun dentre eux tant simul par un code spcique. Les diffrents codes, sexcutant chacun au sein dune institution (notamment pour des raisons de disponibilits de bibliothques logicielles) sont coupls entre eux. Un exemple dapplication reprsent par la gure 2.4 simule lintrusion deau sale. Elle fait intervenir deux codes parallles, coulement et transport, et un code squentiel : contrleur. Chacun des codes parallles sexcute an de simuler lcoulement dune part et le transport dautre part. De plus, comme illustr sur la gure 2.4, les deux codes parallles schangent itrativement des matrices contenant des vitesses, pressions, densits et concentrations an de simuler lintrusion deau sale dans son ensemble. Le code contrleur change des donnes scalaires avec chacun des codes parallles
15
Contrleur
contrle (scalaires) vitesse pression
contrle (scalaires)
coulement
densit concentration
Transport
tel-00411447, version 1 - 27 Aug 2009
F IG . 2.4 changes entre diffrents codes pour la simulation dintrusion deau sale.
an de piloter la simulation.
2.2.3
Les grilles de calcul : une solution pour les applications de couplage de codes
Nous avons remarqu la section 2.1 que les grilles de calcul, et en particulier les fdrations de grappes, prsentaient une topologie rseau hirarchique avec des liens trs faible latence au sein des grappes et des liens plus forte latence entre les grappes. Les applications de couplage de codes dcrites la section prcdente prsentent galement une structure hirarchique. Les codes parallles font intervenir en gnral de nombreuses communications et peuvent tirer avantage dun rseau haute performance. Les communications entre les diffrents codes parallles sont moins frquentes et peuvent se satisfaire de plus grandes latences. De plus, il est frquent quun code parallle doive sexcuter dans une grappe de calcul particulire. Cela peut tre d la prsence de bibliothques logicielles disponibles au sein dune seule grappe, ou des contraintes daccs des donnes scurises places dans une grappe particulire. Par consquent, les architectures de type grille de calcul sont particulirement bien adaptes pour lexcution dapplications de couplage de codes. En effet, en plaant les processus dun mme code parallle dune application de couplage de codes au sein dune mme grappe de calculateurs4 , comme reprsent sur la gure 2.5, ces processus qui partagent de nombreuses donnes bncieront des rseaux haute performance prsents au sein de la grappe. Les diffrents codes parallles tant faiblement coupls, les liens intergrappe, plus forte latence, seront utiliss moins frquemment.
Ce positionnement des diffrents processus est dautant plus naturel que les diffrentes institutions qui collaborent ont en gnral chacune une spcialit.
4
16
Optique
tel-00411447, version 1 - 27 Aug 2009
Thermodynamique
Mcanique
Application de couplage de codes Fdration de grappes
F IG . 2.5 Les fdrations de grappes : une solution naturelle pour les applications de couplage de codes.
2.3 Approches pour le partage de donnes dans les grilles
17

Les applications de couplage de codes dcrites la section prcdente peuvent partager des donnes. Nous avons vu au chapitre 1 que la quantit de donnes peut tre trs importante dans la cas dapplications comme TeraShake [127]. De plus, lorsque ces donnes sont partages, elles peuvent tre accdes de manire concurrente par plusieurs processus applicatifs. Nous dressons ici un panorama des systmes existants pour le partage de donnes dans les grilles de calcul et nous montrons leurs limites.
2.3.1
Le partage de donnes dans les grilles de calcul
tel-00411447, version 1 - 27 Aug 2009
Dans les grilles de calcul, le partage de donnes est complexe. Cela est principalement d : 1) la grande chelle, et 2) la nature dynamique des grilles de calcul. Ces deux caractristiques rendent impossible une connaissance globale de la plate-forme car le nombre de nuds peut tre trs important, et de plus, les nuds sont susceptibles de quitter ou de rejoindre la grille tout instant. Cela rend difcile la localisation des nuds hbergeant une copie dune donne partage. En plus du problme de localisation de la donne, pour lequel de nombreux travaux existent [96, 118], se pose celui du transfert de la donne : quelle copie transfrer sil en existe plusieurs, quel protocole utiliser, quel chemin rseau emprunter, etc.
2.3.2
Systmes existants
Depuis lavnement des grilles de calcul, de nombreux travaux de recherche se sont intresss aux problmes poss par le partage des donnes pour les applications. Des solutions ont t proposes pour faciliter la localisation des donnes, pour amliorer et faciliter laccs aux donnes et leur transfert, et galement pour le stockage des donnes. Localisation des donnes : utilisation de catalogues. Globus [112] est lenvironnement de gestion de grille le plus utilis. Il consiste en une collection de bibliothques logicielles et doutils en ligne de commande permettant dexploiter les grilles informatiques. Pour la localisation des donnes, Globus sappuie sur la notion de catalogue. Les catalogues sont gnralement implments au-dessus de systmes existants comme Lightweight Directory Access Protocol (LDAP [59]) ou de systmes de gestion de bases de donnes. Un service de catalogues de mta-donnes (Metadata Catalog Service, MCS) est utilis pour stocker des informations dcrivant les donnes. Pour la localisation des copies des donnes rpliques, Globus propose un catalogue de copies (Globus Replica Catalog, GRC) et un service de localisation des copies (Replica Location Service, RLS [96]). Cependant, la gestion de ces catalogues reste manuelle : les applications doivent y enregistrer explicitement chaque nouvelle copie de la donne. De plus, ces services noffrent quune aide la localisation et ne grent pas la cohrence des diffrentes copies. Cette solution a t utilise par le projet europen DataGrid [44]. Il existe dans la littrature dautres projets exploitant lapproche de catalogues de copies pour faciliter la localisation de donnes. On peut citer le Metadata Catalog (MCAT) [118] utilis au sein du Storage Resource Broker (SRB) de la grille de donne du centre de calcul de San Diego [91]. SRB offre une interface de programmation uniforme sur un ensemble de
18
ressources de stockage htrognes. Cependant, l encore, la gestion des diffrentes copies et de leur cohrence reste la charge de lapplication. Dans les projets bass sur lutilisation de catalogues, la gestion de ces catalogues nest pas automatise et la cohrence des donnes partages nest pas gre. Aussi, cette solution est bien adapte pour des donnes peu frquemment modies, ou en lecture seule. Il existe de nombreux catalogues rfrenant des donnes non modiables : BIRN [7] qui rfrence des donnes biomdicales, DPOSS [43] qui est un catalogue de donnes dastronomie, GAMESS [110] qui est ddi aux chimistes, etc. Accs aux donnes et transferts. Globus propose des mcanismes daccs aux donnes : Globus Access to Secondary Storage [19] (GASS). Ce systme permet aux processus applicatifs daccder aux donnes distantes de manire transparente, cest--dire comme si elles taient prsentes localement sur les machines sur lesquelles ils excutent. GASS agit donc comme un cache local. Cependant, pour accder aux donnes, lapplication doit appeler des primitives spciques (de type ouvrir/fermer) avant et aprs les accs. Ces primitives permettent au systme deffectuer les transferts de donnes ncessaires. Ce type de mcanisme sapparente aux mcanismes mis en place par les protocoles de cohrence des systmes mmoire virtuellement partage (MVP) que nous dcrivons dans la section 4.1. Le projet Storage Resource Broker (SRB [91]) se focalise galement sur les accs aux donnes. Il a pour but doffrir un accs uniforme diffrents systmes de stockage, quil sagisse de bases de donnes, de systmes darchivage ou de systmes de gestion de chiers. SRB fournit une interface de programmation permettant aux applications daccder aux donnes stockes par ces diffrents systmes. De plus, nous avons vu au paragraphe prcdent que SRB utilise des catalogues de mta-donnes pour localiser les donnes. Cela permet doffrir aux applications un accs transparent et uniforme des donnes prsentes dans des systmes de stockage htrognes. Pour le transfert des donnes, lenvironnement Globus propose un protocole : Grid File Transfer Protocol [1] (GridFTP), ainsi que des bibliothques limplmentant. GridFTP enrichit le protocole classique File Transfer Protocol (FTP) an de ladapter aux grilles. Il offre en effet un moyen de transfert de donnes efcace, scuris et able. GridFTP propose des fonctionnalits telles que : 1) les transferts parallles, an daugmenter le dbit ; 2) des mcanismes de reprise en cas derreur, an de tolrer des fautes ; et 3) des mcanismes dauthentication ou encore la vrication de lintgrit des donnes, an de abiliser les transferts. Ces fonctionnalits sont absentes des protocoles classiques de transfert de donnes comme FTP ou HTTP. Les fonctionnalits apportes par GridFTP le rendent bien adapt aux grilles informatiques. Cependant, lors de lutilisation dun outil utilisant le protocole GridFTP, le dclenchement des transferts des donnes, ainsi que la localisation de la source et de la cible de ces transferts restent la charge des applications. Il ny a galement aucune gestion de cohrence de donnes rpliques. Stockage. Le projet Internet Backplane Protocol (IBP) [11] de luniversit du Tennessee se focalise sur le problme du stockage de donnes grande chelle (Internet). Ce projet met en uvre un rseau de stockage sur des nuds rpartis dans le monde. Cette approche sinspire des rseaux logistiques (Logistical Network [13, 12, 14]). Dans de tels rseaux, les
tel-00411447, version 1 - 27 Aug 2009
19
donnes transitent entre les nuds source et destination via des nuds intermdiaires en utilisant souvent des techniques dordonnancement de transfert. IBP permet ainsi de grer un ensemble de nuds, appels serveurs de stockages, rpartis sur Internet. Il propose une interface de programmation qui permet dallouer des tampons sur un ensemble de serveurs. Les clients peuvent lire et crire des donnes dans ces tampons. Ils peuvent galement effectuer des transferts et des copies entre diffrents serveurs de stockage. IBP noffre que des garanties du type au mieux (best effort), limage dIP (Internet Protocol). Comme prcdemment, le dclenchement des transferts et la gestion de la cohrence des donnes restent la charge des applications. Les systmes pair--pair. Certains systmes pair--pair comme OceanStore [73], Ivy [85], ou Pastis [23] proposent des solutions pour le partage de chiers modiables grande chelle. Ces systmes sont dcrits en dtail la section 4.2. Ils utilisent des mcanismes pair-pair pour localiser, transfrer et stocker les donnes. Nous verrons au chapitre 4 que ces systmes visent des chelles plus grandes que celles des grilles de calcul et offrent une gestion de la cohrence trs relche.
tel-00411447, version 1 - 27 Aug 2009
2.3.3
Limites
Les solutions que nous venons de dcrire permettent aux applications de partager des donnes sur les grilles de calcul. Cependant, les applications doivent grer elles-mmes ce partage. En effet, mme si des solutions ont t proposes pour faciliter la localisation, laccs, le transfert et le stockage des donnes, leur utilisation ne permet pas un partage de donnes modiables transparent pour les applications. Cest en effet lapplication qui doit initier explicitement la localisation et le transfert des donnes partages. Cette gestion explicite du partage de donnes par les applications pose un rel problme, surtout en ce qui concerne la gestion de la cohrence des donnes. Lorsquun processus accde une donne, il va la localiser, puis la transfrer ou la copier sur le nud sur lequel il sexcute, ce qui engendre de multiples copies de la donne. Un effet positif est de crer de multiples copies dune mme donne, permettant ainsi des accs en parallle sur une mme donne partage. Mais que se passe-t-il lorsque lune des copies dune donne partage est modie par un processus ? Plusieurs solutions soffrent alors au programmeur de lapplication : invalider les copies rendues obsoltes par la mise jour, propager les mises jour en mettant en place un mcanisme de verrouillage pour prvenir les modications qui pourraient intervenir avant la propagation des mises jour, etc. Ces mcanismes sont difciles mettre en uvre, dautant plus dans un environnement dynamique et grande chelle comme les grilles de calcul. Des fautes pouvant survenir tout moment au sein des grilles de calcul, les applications ne peuvent pas faire lhypothse quun nud restera disponible tout au long de leur excution pour fournir les donnes quil gre. Par consquent, les applications doivent soit 1) sassurer en permanence quil existe dans le systme plusieurs exemplaires jour de la donne an que celle-ci reste disponible (rplication active) ; soit 2) effectuer des sauvegardes rgulires et tre en mesure de retourner en arrire5 . La prsence de multiples copies dune
Les mcanismes de tolrance aux fautes bass sur la rplication ou sur la sauvegarde de points de reprise sont dtaills au chapitre suivant.
5
20
donne permet de tolrer des fautes mais repose le problme de la gestion de leur cohrence. Malgr laide apporte par les lments existants dcrits la section 2.3.2, cette gestion explicite de la cohrence de donnes partages en prsence de fautes est un des facteurs limitant lors de la conception dapplications pour les grilles de calcul. Ce qui serait souhaitable, cest lexternalisation de la gestion du partage de donnes an de pouvoir nutiliser quun seul et mme service partag par toutes les applications. Les concepteurs dapplication pourraient alors se concentrer sur lapplication elle-mme en dlguant la gestion du partage de donnes, de la cohrence et de la tolrance aux fautes ce service. Il existe, notamment dans le cadre des systmes mmoire virtuellement partage, des travaux permettant de partager des donnes de manire transparente, cest--dire sans avoir connatre la localisation des donnes, ni la faon dont elles sont transfres ou dont la cohrence est maintenue. Ces systmes sont dcrits en dtail la section 4.1. Nous verrons cependant que leur approche ne peut pas sappliquer directement sur une architecture dynamique grande chelle.
tel-00411447, version 1 - 27 Aug 2009
2.4 Problmes induits par la dynamicit de la grille

Les grilles de calcul sont des systmes grande chelle, dynamiques. La nature dynamique des grilles est la fois un atout, et un d. Un atout car elle permet dajouter des ressources au fur et mesure de leur disponibilit ou den retirer pour effectuer des oprations de maintenance par exemple. Un d, car pour le concepteur systme cette nature dynamique soulve de nombreux problmes. Causes. Les causes de la nature dynamique des grilles de calcul sont multiples. La premire est directement lie une caractristique des grilles : la grande chelle. Plus le nombre de nuds est grand, plus la probabilit doccurrence dune panne est importante. Par exemple, si le temps moyen interfaute (ou MTBF pour langlais Mean Time Between Failures) dun nud est dune semaine et que lon considre une grille de 10.000 nuds, on peut prvoir quil y aura approximativement6 une panne de nud toutes les minutes 7 jours24 heures60 minutes ( = 1 minute) dans le systme ! 10.000 Dnition 2.4 : temps moyen interfaute (mean time between failures) Le temps moyen interfaute (MTBF) est le temps moyen qui scoule entre deux occurrences de fautes dans un systme donn. La dynamicit peut galement tre induite par les administrateurs de la grille de calcul. Ils peuvent avoir redmarrer un ou plusieurs nuds, en connecter de nouveaux, voire dconnecter totalement le site de leur institution de la grille. Cette dynamicit peut avoir les mmes consquences que les pannes. Cependant, il est gnralement possible de traiter ces cas de manire plus efcace. En effet, ces interventions peuvent tre prvues et les dconnexions peuvent donc tre faites proprement (en prvenant les autres sites ou nuds).
Approximativement car il faut alors faire lhypothse que les pannes sont indpendantes les unes des autres, ce qui nest pas toujours le cas, et que chaque nud en panne est remplac an de conserver 10.000 nuds en permanence dans le systme.
6
2.5 Tolrance aux fautes et gestion de la cohrence dans les grilles
21
Notons toutefois quun systme qui tolre les pannes tolrera galement les dconnexions volontaires. Enn, les quipements rseaux comme des routeurs, des serveurs de noms ou des serveurs de chiers peuvent galement tomber en pannes, rendant ainsi des nuds temporairement inaccessibles. Consquences. Du fait de la nature dynamique des grilles de calcul, il nest plus possible davoir une connaissance globale du systme car il est susceptible dvoluer tout moment. Cela implique de mettre en place des mcanismes de dcouverte et de surveillance an davoir une vue approximative, partielle du systme. Cette vue doit tre rafrachie pour prendre en compte les changements (ajout ou retrait de nouveaux nuds ou de nouveaux sites). Leslie Lamport a dnit les systmes distribus ainsi : A distributed system is one in which the failure of a computer you didnt even know existed can render your own computer unusable. Dans un cadre gnral, quand on prend en compte la nature dynamique dun systme distribu, on ne peut plus mettre lhypothse quun nud puisse rester indniment fonctionnel. Lorsquun nud sarrte ( cause dune panne ou dun arrt volontaire), il ne joue plus son rle dans le systme. En particulier, les donnes quil stockait ne sont plus accessibles, les chemins rseau qui passaient par lui sont coups, les nuds qui communiquaient avec lui risquent dtre bloqus, etc. Il est donc ncessaire de prendre des prcautions an que le systme puisse continuer dvoluer malgr la dynamicit. Il nexiste pas de solution gnrique pour faire face tout degr de dynamicit. Les solutions classiques consistent en lutilisation de redondance (au niveau des liens rseau an davoir plusieurs routes possibles, au niveau des donnes an de pouvoir conserver une copie dans le systme, etc.) ou de sauvegardes priodiques. Ces mcanismes sont des mcanismes de tolrance aux fautes, certains dentre eux sont dtaills dans ce manuscrit.
tel-00411447, version 1 - 27 Aug 2009
2.5 Tolrance aux fautes et gestion de la cohrence dans les grilles

Dans ce chapitre, nous avons dcrit les architectures de type grille de calcul ainsi que les applications distribues qui les exploitent. Les grilles de calculs sont particulirement bien adaptes aux applications de type couplage de codes. Ces architectures tant dynamiques et grande chelle, le partage de donnes par les applications est un problme difcile rsoudre. De plus, bien que de nombreux outils pour localiser les donnes ou les transfrer existent, la gestion du partage et de la cohrence de ces donnes restent aujourdhui la charge de lapplication. Dans ce contexte, il semble important doffrir aux applications la possibilit daccder aux donnes de manire transparente, cest--dire sans avoir grer les problmes lis la localisation, au transfert, la cohrence des donnes ou la nature dynamique de la grille. Le chapitre suivant prsente un panorama des mcanismes permettant de faire face aux problmes lis aux fautes et le chapitre 4 un panorama sur la gestion de la cohrence des donnes.
tel-00411447, version 1 - 27 Aug 2009
23
Chapitre
Approches pour la gestion de la tolrance aux fautes

tel-00411447, version 1 - 27 Aug 2009
Sommaire
3.1 Notion de faute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 Dfaillances, erreurs et fautes . . . . . . . . . . . . . . . . . . . . . 3.1.2 Types de dfaillance . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.3 Quel modle de fautes pour les grilles de calcul ? . . . . . . . . . 3.1.4 Comment faire face aux fautes ? . . . . . . . . . . . . . . . . . . . Dtection de dfaillances . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Principes gnraux . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.2 Classication des dtecteurs de dfaillances . . . . . . . . . . . . 3.2.3 Mise en uvre de dtecteurs de dfaillances . . . . . . . . . . . . 3.2.4 Passage lchelle . . . . . . . . . . . . . . . . . . . . . . . . . . . Techniques de rplication . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.1 Gestion des groupes de copies . . . . . . . . . . . . . . . . . . . . 3.3.2 Propagation des mises jour . . . . . . . . . . . . . . . . . . . . . 3.3.3 Utilisation de groupes de copies . . . . . . . . . . . . . . . . . . . Sauvegarde de points de reprise . . . . . . . . . . . . . . . . . . . . . . . 3.4.1 Principe de base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.2 Points de reprise coordonns . . . . . . . . . . . . . . . . . . . . . 3.4.3 Points de reprise non-coordonns . . . . . . . . . . . . . . . . . . Tolrance aux fautes dans les grilles : vers une approche hirarchique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 24 25 26 28 28 29 29 30 31 32 32 33 34 34 35 36 36 37
3.2
3.3
3.4
3.5
Dans le chapitre prcdent, nous avons prsent les architectures de type grille de calcul ainsi que les applications de couplage de code qui les utilisent. Nous avons soulign que ces architectures ont une nature dynamique, cest--dire que des nuds ou des groupes de
24
Chapitre 3 Approches pour la gestion de la tolrance aux fautes
tel-00411447, version 1 - 27 Aug 2009
nuds (lensemble des nuds dune grappe par exemple), sont susceptibles de rejoindre ou de quitter la grille de calcul tout moment. Dans ce chapitre, nous allons nous intresser aux approches permettant de faire face une partie de cette nature dynamique : les approches dites de tolrance aux fautes. La tolrance des fautes est la partie la plus difcile dans la gestion de la dynamicit 1 : il sagit de tolrer les dparts intempestifs de nuds ou de groupes de nuds de la grille. Tout dabord, nous allons dcrire la notion de faute et dtailler quels types de faute il est judicieux de tolrer dans les grilles de calcul (section 3.1). La tolrance aux fautes exige comme prrequis des informations sur les occurrences de fautes dans le systme. Elle ncessite la mise en uvre des mcanismes de surveillance du systme que nous avons voqus la section 2.4 du chapitre prcdent. La section 3.2 dcrit les principes de la dtection de fautes et met laccent sur des dtecteurs de fautes adapts aux architectures de type grille de calcul. Les sections 3.3 et 3.4 dcrivent les deux principales familles dapproches utilises pour faire face aux fautes : les approches bases sur la rplication (section 3.3) et celles bases sur les points de reprises des applications (section 3.4). Enn, nous concluons ce chapitre par une analyse portant sur ladaptation de ces approches aux grilles de calcul.
3.1 Notion de faute

Il existe diffrents types de faute [77]. Toutes nont pas les mmes consquences et toutes ne sont pas susceptibles de se produire au sein dune grille. Nous commenons par dcrire ce quest une faute, puis nous donnons une classication des diffrents types de faute en analysant celles auxquelles il faut faire face au sein dune grille de calcul.
3.1.1
Dfaillances, erreurs et fautes
Dnition 3.1 : dfaillance (failure) Un lment2 est dit dfaillant lorsquil ne se comporte pas conformment sa spcication. Une dfaillance est souvent appele panne. Dnition 3.2 : erreur (error) Une erreur est un tat anormal dun lment, susceptible de causer une dfaillance, mais cette dernire nest pas encore dclare. Dnition 3.3 : faute (fault) Une faute peut tre une action, un vnement ou une circonstance qui peut entraner une erreur. On remarque quil y a des relations de causalits entre les fautes, les erreurs et les dfaillances. Par exemple, pour un serveur de chier, dbrancher la carte rseau peut tre une action constituant une faute. Cette faute a pour consquence lerreur : le serveur de chiers nest plus accessible. Si un client essaye daccder un chier du serveur via le rseau, cela sera impossible. Le serveur de chier nest donc plus conforme sa spcication, il sagit donc dune dfaillance. La gure 3.1 illustre la chane de dpendances entre les fautes, les erreurs et les dfaillances.
An de grer compltement la dynamicit, il est ncessaire de prendre en compte galement les arrives de nouveaux nuds. 2 Ici, un lment peut tre un composant dun systme ou un systme dans son ensemble.
1
3.1 Notion de faute
25
Faute
Erreur
Dfaillance
F IG . 3.1 Dpendances entre fautes, erreurs et dfaillances.
Faute : Dfaillance du noeud hbergeant la donne x
Erreur : "La donne x nest plus disponible"
Dfaillance du service de partage de donnes
Accs la donne x
F IG . 3.2 Exemple de dfaillance du service de partage de donnes cause par la dfaillance dun nud.
tel-00411447, version 1 - 27 Aug 2009
Par ailleurs, selon le niveau auquel un systme est observ, une dfaillance dun lment du systme peut tre lorigine dune erreur dun autre lment et donc constituer une faute pour cet autre lment. Par exemple, dans un service de partage de donnes pour la grille, la dfaillance dun nud hbergeant la seule et unique copie dune donne constitue une faute pour le service. Cette faute entrane une erreur pour le service : la donne est alors perdue. Lorsque le service de partage de donnes ne satisfera pas une requte concernant la donne perdue, le service de partage de donnes sera dfaillant. Ceci est illustr par la gure 3.2. Dans ce manuscrit, notre but est de tolrer les fautes qui surviennent au sein du service, ceci an dassurer que son comportement soit conforme sa spcication, cest--dire que le service ne soit pas dfaillant. Les fautes du service tant les dfaillances de ses composants, tolrer les fautes du service est quivalent tolrer les dfaillances de ses composants. Nous parlerons donc de fautes et de dfaillances selon le niveau auquel nous nous situons, mais cela correspondra toujours aux dfaillances des composants (nuds, liens rseau). Sur la gure 3.2, cela correspond la case grise reprsentant une faute du service de partage de donnes/une dfaillance dun nud.
3.1.2
Types de dfaillance
Les composants des grilles de calcul, les nuds et les liens rseau, sont susceptibles dtre dfaillants. Il existe plusieurs types de dfaillance. Les trois principales familles sont : les dfaillances franches, les dfaillances par omission et les dfaillances byzantines. Dnition 3.4 : dfaillance franche ou crash (fail-stop) Le composant se comporte conformment sa spcication jusqu ce quil subisse une dfaillance franche. partir de celle-ci, il cesse dnitivement toute activit. Dnition 3.5 : dfaillance par omission (omission failure) Le composant cesse momentanment son activit puis reprend son activit normale. Typiquement, cela peut correspondre une perte de message.
26
Dfaillances franches
Dfaillances par omission
tel-00411447, version 1 - 27 Aug 2009
Dfaillances byzantines
F IG . 3.3 Imbrication des types de dfaillance.
Dnition 3.6 : dfaillance byzantine (byzantine failure) Un composant prsentant ce type de dfaillance agit de manire compltement imprvisible pour lobservateur extrieur. Cest le type de dfaillance le plus gnral, aucune hypothse ne peut tre faite sur le comportement dun composant byzantin. Ltude de ce type de dfaillance est trs utile pour la conception dun systme scuris : un systme tolrant un ou plusieurs composants prsentant un comportement byzantin tolre alors nimporte quel comportement de la part de ces composants, notamment des comportements malicieux. Ces diffrents types de dfaillance sont imbriqus les uns dans les autres, comme illustr par la gure 3.3. En effet, si un systme peut tolrer que des composants agissent de manire totalement imprvisible (dfaillance byzantine), il peut alors galement tolrer un composant qui agit selon sa spcication mais qui omet des parties de son activit (dfaillance par omission). De mme, la dfaillance franche est un cas particulier de dfaillance par omission : lomission concerne alors tout ce qui se passe aprs la dfaillance.
3.1.3
Quel modle de fautes pour les grilles de calcul ?
Dans les grilles de calcul, les composants sont les nuds et les liens rseau. Rappelons que la dfaillance dun de ses composants est une faute pour le service. Plus le type de faute tolrer est gnral, plus les mcanismes de tolrance aux fautes pour y faire face sont complexes et coteux en terme de performance : tolrer les dfaillances byzantines sera ainsi plus coteux que de tolrer les dfaillances franches. Il est donc ncessaire dvaluer
3.1 Notion de faute
27
les possibilits doccurrence de dfaillances pour les diffrents types. En effet, il ne serait pas judicieux de mettre en place de coteux mcanismes servant tolrer des dfaillances peu probables. Dfaillances franches dans les grilles de calcul. Le grand nombre de nuds prsents dans une grille de calcul implique une ventualit non ngligeable de pannes (dfaillances franches) de ces nuds. Des pannes simultanes sont galement envisageables. Lors dune panne lectrique dans une institution, toutes les ressources partages par cette institution risquent de subir des dfaillances franches simultanment, on parle alors de dfaillances corrles. Dfaillances par omission dans les grilles de calcul. La prsence de certains quipements rseau tels des routeurs, notamment entre les diffrentes institutions composant une grille de calcul, rend possibles certaines dfaillances par omission. Lorsque le rseau est congestionn, les routeurs ignorent en effet volontairement des messages pour limiter la congestion. Des pertes de messages peuvent galement avoir lieu lorsquun nud reoit des paquets rseau plus vite quil ne peut les traiter (rappelons que les ressources dune grille de calcul sont htrognes). Nous limitons donc les dfaillances par omission dans les grilles aux pertes de messages. Nous considrons que les canaux de communication sont quitables (voir ci-dessous). Dnition 3.7 : canaux de communication quitables (fair lossy channels) Si un processus correct p envoie un message m une innit de fois un processus correct q via un canal quitable, alors q reoit ultimement (eventually) le message m. Moins formellement, des messages peuvent tre perdus mais, en les rmettant, ils nissent par arriver. Il est donc possible de transformer des canaux quitables en canaux ables en mettant en uvre des mcanismes de rmission. Dfaillances byzantines dans les grilles de calcul. Les grilles de calcul sont le rsultat de la mise en commun des ressources dinstituts qui saccordent mutuellement une certaine conance et qui mettent en place des mcanismes coordonns de contrle daccs. Les grilles de calcul sont par consquent des environnement relativement clos et scuris. Nous avons choisi de ne pas traiter dans notre travail les problmes lis la scurit. Si les applications qui sexcutent sur les grilles sont correctement implmentes, il est peu probable, dans tel environnement, que des composants se comportent de manire imprvisible. Il ne semble donc pas ncessaire de mettre en uvre des mcanismes pour tolrer les dfaillances byzantines. De plus, la tolrance des dfaillances byzantines requiert la mise en place de mcanismes rellement coteux, engendrant de nombreuses communications. Lors de la mise en place de mcanismes de tolrance aux dfaillances, il est ncessaire de prendre en compte aussi bien les cots des diffrents mcanismes de tolrance aux dfaillances que les possibilits doccurrence des diffrents types de dfaillance. Au sein des grilles de calcul, il semble judicieux doffrir des mcanismes permettant de supporter des dfaillances de type franche ainsi que des pertes de messages. En effet, ces dfaillances sont trs courantes. En revanche, des mcanismes coteux permettant de supporter des dfaillances
tel-00411447, version 1 - 27 Aug 2009
28
byzantines ne doivent tre mis en place que lorsque cela est vraiment ncessaire. Nous avons fait le choix de ne pas prendre les dfaillances byzantines en compte.
3.1.4
Comment faire face aux fautes ?
Si des fautes peuvent survenir, il est alors ncessaire de les prendre en compte et de mettre en uvre des mcanismes permettant de les grer pour permettre aux applications de continuer leur excution. Il est possible de relancer une application en cas de faute. Cependant, cette technique devient de moins en moins efcace au fur et mesure que le temps moyen entre les fautes (MTBF pour Mean Time Between Failures) se rapproche du temps dexcution. Pour des applications dont la dure dexcution est longue (en heures, en jours, voire en semaines) il devient presque impossible de terminer lexcution.
tel-00411447, version 1 - 27 Aug 2009
Dans le cas dun service pour la grille, le temps dexcution des applications est trs variable et souvent imprvisible. Le service ne doit donc pas sarrter loccurrence dune faute et il doit rester conforme sa spcication. Par exemple, un service offrant un stockage persistant de donnes doit conserver les donnes y compris en prsence de fautes, invitables sur une grille. Prendre en compte les fautes de manire maintenir les services et permettre aux applications de sexcuter entirement exige la mise en place de mcanismes de surveillance du systme an de pouvoir dtecter les dfaillances de ses composants. La dtection des dfaillances est un problme complexe qui a fait lobjet de nombreux travaux de recherche, la section suivante traite de ce problme. Pour la tolrance aux fautes, les mcanismes mettre en place peuvent se classier en deux grandes familles : 1) la prvention des fautes, et 2) la raction aux fautes. Les mcanismes de prvention des fautes sont en gnral ncessaires au fonctionnement des mcanismes de raction aux fautes. Prvention des fautes. Le systme est prpar subir une ou plusieurs fautes par la cration de sauvegardes (comme des points de reprise pour les applications, voir section 3.4) ou par lutilisation de la redondance (via des mcanismes de rplication comme ceux dtaills la section 3.3). Raction aux fautes. En cas de faute, le systme ragit et sadapte en sappuyant sur les sauvegardes ou la redondance prsente an de rester oprationnel.
3.2 Dtection de dfaillances

La dtection des dfaillances dans un systme est un problme complexe. Cette complexit vient de lasynchronisme des systmes. Dnition 3.8 : systme asynchrone Un systme asynchrone est un systme pour lequel il nest fait aucune hypothse temporelle sur les temps de transmission des messages ou sur les temps de calcul des processeurs.
29
Fischer, Lynch et Paterson ont prouv [49] que dans un tel systme sans hypothse temporelle, en prsence de fautes, il est impossible dobtenir un consensus de manire dterministe entre plusieurs nuds. En effet, lorsquun nud ne communique plus avec les autres, il est impossible de dterminer sil est dfaillant ou sil est simplement lent et que ses messages seront reus plus tard. Il est donc impossible de mettre en uvre un service de dtection de dfaillances able sans faire plus dhypothses sur le systme. Dans [32], Chandra et Toueg ont propos la notion de dtecteurs non ables de dfaillances (unreliable failure detectors).
3.2.1
Principes gnraux
tel-00411447, version 1 - 27 Aug 2009
Du point de vue de lutilisateur, le service de dtection de dfaillances permet de sabstraire des hypothses temporelles. En effet, Chandra et Toueg ont propos de concevoir un systme sans hypothses temporelles mais utilisant un oracle (un service de dtection de dfaillances) dont le rle est de signaler, sur chaque nud, les nuds suspects susceptibles dtre dfaillants [32]. De nombreux algorithmes, comme les algorithmes permettant dtablir un consensus entre plusieurs nuds, peuvent sexcuter avec de telles listes de suspects [32]. En revanche, au niveau du service de dtection, il est ncessaire de faire des hypothses temporelles. La notion de systmes partiellement synchrones (partial synchrony) est dcrite dans [45]. Un systme partiellement synchrone est un systme asynchrone vriant certaines hypothses temporelles, comme lexistence de bornes temporelles sur les temps de calcul et/ou sur les temps de transmission de messages. Les systmes rels sont rarement totalement synchrones, ni totalement asynchrones. Au sein grilles de calcul notamment, les temps de calcul ainsi que les temps de transmission des messages sont borns, mais les bornes sont ne sont pas connues avec prcision. Fausses suspicions. Au sein des systmes partiellement synchrones, les bornes temporelles exactes ne sont pas connues. Il nest donc pas possible de dterminer de faon certaine la dfaillance dun nud. Cest pourquoi les dtecteurs de dfaillances sont dits nonables. Ils ne fournissent pas des listes de nuds dfaillants, mais des listes de nuds suspects dtre dfaillants. Il est donc possible quun nud dfaillant ne soit pas suspect durant un certain temps ou quun nud non-dfaillant soit suspect tort. Ce dernier cas sappelle une fausse suspicion. Pour le systme utilisateur du service de dtection, les fausses suspicions peuvent avoir de lourdes consquences : il faut alors grer la prsence dun nud que lon a considr pendant un certain temps comme en panne. Le nud faussement suspect nest plus jour par rapport au reste du systme qui lavait considr comme absent. Il est donc ncessaire dans ces cas-l de rparer le systme, ce qui peut savrer dlicat selon le rle que joue le nud suspect.
3.2.2
Classication des dtecteurs de dfaillances
La mesure de la qualit dun dtecteur de dfaillances dpend de lutilisation qui en est faite. En effet, tous les dtecteurs de dfaillances ne sont pas comparables. Les deux prin-
30
cipaux critres de qualit pour des dtecteurs de dfaillances sont : 1) la compltude, et 2) la justesse. Dnition 3.9 : compltude (completeness) Un nud dfaillant doit tre dtect comme tant dfaillant. Dnition 3.10 : justesse (accuracy) Un nud non-dfaillant (correct) ne doit pas tre considr comme tant dfaillant. La compltude se drive en deux catgories : 1) forte : ultimement3 , tous les processus corrects suspecteront tous les nuds dfaillants de faon permanente ; 2) faible : ultimement, chaque nud dfaillant est suspect par au moins un processus correct. De mme, la justesse se drive en quatre catgories : 1) forte, les nuds corrects ne sont jamais suspects (cest--dire quil ny a pas de fausses suspicions) ; 2) faible, il existe au moins un nud correct qui nest jamais suspect ; 3) ultimement forte ; et 4) ultimement faible.
tel-00411447, version 1 - 27 Aug 2009
Ces critres permettent de rpartir les dtecteurs de dfaillances en 8 grandes classes rsumes par le tableau ci-dessous. Ces diffrentes classes de dtecteurs ne sont pas toutes comparables entre elles. Selon la classe vise, la ralisation dun dtecteur de dfaillance ncessite : 1) un plus ou moins grand nombre de messages, et 2) des hypothses sur le synchronisme du systme plus ou moins fortes, par exemple la conception dun dtecteur de dfaillance parfait (P) impose de formuler de fortes hypothses de synchronisme sur le systme. Justesse forte Parfait P Q Justesse faible Fort S Faible W Justesse ultimement forte Ultimement parfait P Q Justesse ultimement faible Ultimement fort S Ultimement faible W
Compltude forte Compltude faible
Sur le plan pratique, [36] propose dvaluer les dtecteurs de dfaillances en prenant galement en compte le temps de dtection ainsi que le nombre et la dure des fausses suspicions.
3.2.3
Mise en uvre de dtecteurs de dfaillances
Il existe deux grandes techniques pour la mise en uvre de dtecteurs de dfaillances : celle base sur des changes priodiques de messages de vie, et celle base sur des allersretours ping/pong. changes de messages de vie (heartbeats). Chaque nud envoie priodiquement un message de vie tous les autres et attend donc, chaque priode, un message de vie de chacun dentre eux. Lorsquun nud ne reoit pas de message de vie dun autre nud, il le considre comme suspect. De nombreux projets de recherche se sont concentrs
3
Ici ultimement signie il existe un moment partir duquel... (eventually).
31
sur la abilisation de la suspicion, en prenant en compte le nombre de fausses suspicions ou la variation de latence dans larrive des messages de vie dun nud particulier [36, 42, 62, 55]. Cette technique a t employe pour mettre en uvre les dtecteurs de dfaillances prsents dans [17]. Le principal inconvnient de cette technique rside dans lutilisation de communications de type tous-vers-tous, qui ne sont pas adaptes lchelle des grilles de calcul, en raison du grand nombre de nuds. Messages ping/pong. De manire priodique ou la demande, les nuds envoient un message ping tous les autres nuds ou une partie dentre eux. Cette technique peut permettre une dtection plus cible : elle permet de ne surveiller quun sous-ensemble des nuds. En revanche, pour obtenir autant dinformations quavec la technique dchange de messages de vie, deux fois plus de messages sont ncessaires (chaque message de vie pong tant rclam explicitement par un message ping). Le systme de composition de groupe grande chelle SWIM (pour Scalable Weaklyconsistent Infection-style process group Membership [41]) utilise ce type de mcanisme pour dtecter les nuds dfaillants.
tel-00411447, version 1 - 27 Aug 2009
3.2.4
Passage lchelle
Les dtecteurs de dfaillances imposant que chaque nud surveille directement tous les autres nuds ne sont pas adapts lchelle des grilles de calcul. Nous distinguons trois approches pour le passage lchelle des dtecteurs de dfaillances : lapproche hirarchique, lapproche base sur un anneau logique et lapproche probabiliste. Approche hirarchique. Les auteurs de [17] proposent une version hirarchique de dtecteurs de dfaillances utilisant des changes de messages de vie [18, 16]. Lensemble des nuds est partitionn en sous-ensembles et les changes de messages de vie de type tous-vers-tous sont restreints chaque sous-ensemble. Chaque sous-ensemble choisit un reprsentant et les diffrents reprsentants des sous-ensembles schangent des messages de vie. Cette approche permet dobtenir des dtecteurs de dfaillances adapts aux systmes grande chelle comme les grilles. Approche base sur un anneau logique. Lutilisation dun anneau logique dterminant les schmas dchanges de messages de vie et de propagation de linformation est propose par [78]. De mme que pour lapproche hirarchique, cela permet de limiter le nombre de messages de vie mis sur le rseau et doffrir de bonnes proprits de passage lchelle. Approche probabiliste. Une autre approche permettant de concevoir des dtecteurs de dfaillances pour les systmes grande chelle est lutilisation de techniques probabilistes. Dans SWIM [41], les nuds envoient des messages de type ping priodiquement un ensemble alatoire de nuds. De plus, les messages ping et pong contiennent les informations sur les nuds suspects permettant ainsi de propager les dtections. Les mcanismes probabilistes nutilisent pas de notion de reprsentant ni de topologie spcique. Leur maintenance est donc plus aise, ce qui les rend bien adapts aux systmes trs grande chelle. En revanche, les dfaillances sont dtectes avec une forte probabilit mais non avec certitude. loppos, les dtecteurs bass sur une approche hirarchique
32
ou sappuyant sur une topologie en anneau offrent une bonne ractivit. De plus les dtecteurs hirarchiques prsents dans [18, 16] sadaptent bien la topologie des fdrations de grappes. Ils nous semblent donc les mieux adapts aux grilles de calcul.
3.3 Techniques de rplication

La dtection des dfaillances est un prrequis pour la tolrance aux fautes. En cas de faute, le systme doit avoir prvu des moyens de permettre aux services de continuer son fonctionnement. La rplication consiste conserver en permanence dans le systme plusieurs copies. Ainsi, en cas de fautes, les copies restantes peuvent continuer assurer le service. Pour mettre en place des mcanismes de rplication, il est ncessaire de pouvoir : 1) grer des groupes de nuds qui hbergent les diffrentes copies, et 2) mettre en place des communications de groupe an dassurer les mises jour des diffrentes copies. Ces deux points sont lis car il est possible de grer des groupes laide de mcanismes de communication de groupe.
tel-00411447, version 1 - 27 Aug 2009
3.3.1
Gestion des groupes de copies
La gestion des groupes de copies se fait par des protocoles de composition de groupe aussi appels protocoles dappartenance (group membership en anglais). Le rle de ces protocoles est de grer des listes de membres de groupes. Ils permettent de nouveaux nuds de rejoindre un groupe, ou des nuds membres dun groupe de le quitter. Ils peuvent utiliser des mcanismes de dtection de dfaillances an dvincer un nud dfaillant de son groupe. Au sein dun groupe, chaque nud possde une liste des membres de ce groupe. Un protocole de composition de groupe fait voluer ces listes au gr des arrives et dparts de nuds. Ces listes doivent rester cohrentes entre elles, cest pourquoi le protocole harmonise les listes des diffrents membres, on parle de vue du groupe. Cette harmonisation est rendue ncessaire par la dynamicit des groupes de copies. Un dpart (volontaire ou d une dfaillance) ou une arrive de nud doit tre ret sur chacun des autres membres, cela correspond un changement de vue. De nombreux travaux de recherche [37, 54, 30, 82] associent donc la composition de groupes aux problmes daccord dans les systmes distribus. En effet, le problme de composition de groupe peut tre rsolu en mettant en place des mcanismes permettant aux membres de se mettre daccord sur la composition de leur groupe. Un protocole de composition de groupe bas sur des mcanismes daccord gnriques est dcrit dans [54]. Une pile de protocoles est propose par [82]. Au sein de cette pile, un protocole de consensus est utilis pour grer la composition des groupes. Une notion de composition de groupe existe galement dans le domaine des systmes pair--pair [41]. Il sagit alors de construire des rseaux logiques au-dessus des rseaux physiques, en reliant les pairs appartenant un mme groupe. Cependant, la gestion de ces groupes est faite au mieux (best effort) et noffre en gnral pas les garanties qui seront ncessaires la gestion de donnes modiables partages par des applications scientiques, par exemple la possibilit de raliser une diffusion efcace et able.
3.3 Techniques de rplication
33
3 ack
ack 2
ack 2
ack 2 1
ack 2
ack 4
Rplication active (a)
Rplication passive (b)
Rplication semiactive (c)
F IG . 3.4 Diffrents types de mcanisme de rplication.
tel-00411447, version 1 - 27 Aug 2009
3.3.2
Propagation des mises jour
Lorsquune entit est rplique, la mise jour dune copie doit tre propage aux autres copies. Il est donc ncessaire de mettre en uvre des mcanismes de communication de groupe au sein des groupes de copies. Selon la frquence des mises jour, des hypothses sur la abilit du systme et des contraintes sur les garanties de fracheur des copies, les besoins en terme de communication de groupe sont trs variables. Aussi, existe-t-il de nombreuses approches permettant dappliquer des mises jour un ensemble de copies. On distingue notamment la rplication active, la rplication passive et la rplication semi-active. Certains systmes (comme DARX [81], une plate-forme pour des applications multi-agent) proposent diffrents mcanismes de rplication an de pouvoir sadapter au cas dutilisation. La gure 3.4 illustre ces diffrents types de mcanisme de rplication. Rplication active. Toutes les copies reoivent et traitent les messages de manire concurrente (partie a de la gure 3.4). Avec ce type de rplication, les mises jour sont envoyes toutes les copies par le nud effectuant la mise jour. Ce dernier attend ensuite des acquittements des copies mises jour. Cette technique implique que pour communiquer avec un groupe il est ncessaire de connatre (ou de pouvoir localiser) lensemble des membres du groupe. Rplication passive. La rplication passive (partie b de la gure 3.4) est une technique optimiste car seule une copie est mise jour. Depuis cette copie (appele copie primaire) les mises jour sont propages priodiquement aux autres membres du groupe. Pour communiquer avec le groupe il suft alors de communiquer avec la copie primaire. La mise jour peut tre perdue si le nud hbergeant la copie primaire subit une dfaillance avant de la transmettre aux copies de sauvegarde. Rplication semi-active. Dans le cas de la rplication semi-active (partie c de la gure 3.4), les mises jour ne sont envoyes qu une copie. Cette dernire met jour lensemble du groupe avant de retourner un acquittement au nud initiateur de la mise jour. Les garanties offertes ici sont les mmes quavec la rplication active mais il suft de connatre la copie primaire du groupe pour pouvoir envoyer une mise jour. Cest en revanche la technique qui induit le plus de latence lors des mises jour (4 phases de communication contre 2 pour les autres types de rplication).
34
Mises jour concurrentes. Dans le cadre gnral, plusieurs nuds peuvent envoyer des mises jour un groupe de copies de manire concurrente. An de conserver la cohrence des diffrentes copies, il est ncessaire que ces mises jour soient appliques dans le mme ordre sur chacune des copies. Ceci peut tre ralis laide de mcanismes de diffusion atomique. Dnition 3.11 : diffusion atomique La proprit de diffusion atomique au sein dun groupe assure que chaque membre du groupe prend en considration les mmes messages, dans le mme ordre. De nombreuses approches pour concevoir des protocoles de communication de groupe offrant la proprit de diffusion atomique sont prsentes dans [46]. La diffusion atomiques peut tre ralise par lutilisation dun nud srialisateur par lequel toutes les mises jour transitent. Ce nud joue alors un rle critique et doit pouvoir tre remplacer en cas de dfaillance. Une approche alternative [82, 53] consiste utiliser des mcanismes daccord au sein des groupes pour dterminer lordre dans lequel les messages doivent tre pris en compte. Dans ce cas, des changes de messages supplmentaires permettent aux nuds rcepteurs de la diffusion de saccorder sur lordre de prise en compte des messages diffuss.
tel-00411447, version 1 - 27 Aug 2009
3.3.3
Utilisation de groupes de copies
Les groupes de copies (et donc la rplication) sont utiliss dans de nombreux systmes [81, 105, 20, 101], an de abiliser des donnes, des chiers ou encore des processus. La plate-forme pour applications multi-agent DARX [81] utilise la rplication an de abiliser des agents logiciels. Ce systme propose diffrents mcanismes de rplication (active, passive et semi-active). Il propose dadapter le mcanisme de rplication ainsi que le nombre de copies en fonction : 1) des agents rpliqus, et 2) de lestimation du niveau de risque de fautes. Le systme de chier LegionFS [105] repose sur la rplication offerte dans Legion [34] an de proposer un systme de chiers able dont le but est de permettre la collaboration grande chelle. Les donnes des chiers sont rpliques an dassurer leur persistance au sein du systme. Les mcanismes de rplication utiliss peuvent tre spcis par lutilisateur. Horus [101] et Isis [20] sont des systmes offrant des mcanismes de communication de groupe permettant de mettre en place des mcanismes de rplication. De nombreuses applications sont construites au-dessus de ces systmes. Par exemple, des applications nancires et de courtage utilisent le systme Isis. Les chapitres 6 et 7 dtaillent notre utilisation de la rplication an de abiliser un service de partage de donnes.
3.4 Sauvegarde de points de reprise

Les approches bases sur la rplication sont bien adaptes la tolrance aux fautes pour prserver des donnes. Elles ncessitent en revanche lutilisation dun grand nombre de
3.4 Sauvegarde de points de reprise
35
nuds et sont difciles mettre en place lorsquil sagit de rpliquer des processus applicatifs communicants et non ncessairement dterministes. Dans ce cas, des solutions bases sur des sauvegardes de points de reprise semblent plus judicieuses.
3.4.1
Principe de base
Un point de reprise pour un processus applicatif est un ensemble dlments (ltat de la mmoire par exemple) permettant de relancer ce processus en cas de dfaillance dun nud. Il peut tre tabli de manire incrmentale : seules les donnes modies depuis le dernier point de reprise sont alors sauvegardes. Certains systmes permettent la duplication de processus (fork), ce qui autorise la cration du point de reprise en arrire-plan, sans bloquer le processus. Dans le cas dune application distribue compose de plusieurs processus, un point de reprise est compos dun ensemble de points de reprise des processus de lapplication. Les communications interprocessus entranent alors des dpendances. An dexprimer ces dpendances, Leslie Lamport a dni la relation de causalit entre deux vnements (happened before) [76]. Au sein dun mme processus, un vnement en prcde un autre sil se produit avant dans le temps. Pour deux processus communicants, lmission dun message par un processus prcde la rception de ce message par son destinataire. Par ailleurs, la relation de causalit est transitive. Une excution rpartie peut donc tre vue comme un treillis dvnements. La principale difcult rencontre lors de la mise en place de mcanismes de points de reprise pour une application distribue consiste trouver un ensemble valide dtats, cest--dire sans dpendance entre les tats qui le composent. Cet ensemble est appel un tat global cohrent. Le calcul dun tat global cohrent a donn lieu de nombreuses recherches. Une solution lgante a t propose par K.M. Chandy et L. Lamport [33]. Cette solution utilise un systme de marqueurs envoys par le nud initiateur du calcul de ltat global cohrent puis retransmis par les nuds le recevant (aprs avoir sauvegard leur tat local). En supposant les canaux de communication FIFO (First In First Out, premier entr, premier sorti), les marqueurs permettent aux processus de journaliser les messages reus des nuds nayant pas encore transmis de marqueur. Cette technique ajoute cependant des donnes aux messages lors de la cration dun point de reprise. De plus, elle ncessite la journalisation de messages reus. En effet, dans ltat restaur, certains messages ont t envoys mais non reus. Le processus destinataire doit donc les rejouer. Le systme de tolrance aux fautes dcrit dans [93] utilise un procd semblable celui-ci. Dans ce dernier, les processus conrment le point de reprise au processus initiateur qui envoie une conrmation tous les processus lorsque la dnition du point de reprise est complte. Dans les solutions proposes pour les modles de sauvegarde/reprise, on distingue deux grandes familles. La premire famille, pessimiste, consiste calculer un tat global cohrent lors de la sauvegarde du point de reprise. Ce type de technique est dit coordonn. En effet, cela consiste synchroniser les processus lors de la sauvegarde. Les protocoles de la deuxime famille, optimiste, ne calculent ltat global cohrent que lors de la reprise aprs une dfaillance. Les points de reprise sont sauvegards pour chacun des processus indpendamment les uns des autres. Cela vite le surcot d la synchronisation mais rend les techniques de reprise plus complexes. La grande diversit des solutions proposes sexplique par lhtrognit des systmes qui vont les exploiter : par exemple, certaines sont conues pour
tel-00411447, version 1 - 27 Aug 2009
36
des systmes trs grande chelle [22], dans lesquels une synchronisation des processus serait trs coteuse (voir impraticable), dautres sont adaptes aux grappes de calculateurs petite chelle utilisant un rseau trs haut dbit et faible latence [100, 9, 39, 93, 69, 84].
3.4.2
Points de reprise coordonns
tel-00411447, version 1 - 27 Aug 2009
tablir un point de reprise coordonn consiste synchroniser les processus lors de la sauvegarde des tats locaux an de garantir que ltat global obtenu laide de lensemble de ces tats locaux soit cohrent. Une ligne de recouvrement est ainsi cre lors de ltablissement du point de reprise. De ce fait, lapplication peut tre relance en relanant chacun des processus (ou seulement les fautifs si un systme de journalisation est mis en place) au niveau de son dernier point de reprise : aucun autre calcul supplmentaire nest ncessaire. On remarque quil suft alors de conserver le dernier point de reprise de chaque processus. En effet, tous les tats sauvegards antrieurement deviennent obsoltes. En revanche cette technique prsente un inconvnient majeur : elle ncessite la synchronisation de tous les processus, ce qui engendre un surcot qui peut tre lev, surtout dans des systmes grande chelle. Il existe de nombreuses amliorations possibles pour limiter le surcot d la synchronisation des processus [83, 47]. En premier lieu, il nest pas ncessaire que tous les processus se synchronisent. En effet, seuls les processus ayant des dpendances doivent le faire. Koo et Toueg [71] proposent un algorithme ne synchronisant quun nombre minimal de processus. Ensuite, la quantit de donnes sauvegarder peut tre grandement diminue en utilisant une technique de points de reprise incrmentale. Les auteurs de [93] proposent dutiliser les services de GENESIS, un systme pour les grappes de PC fournissant un modle de mmoire partage, an de ne bloquer les processus que si cela est ncessaire (cest--dire si leur excution nentrane pas de dpendances, comme lenvoi de messages). Une autre optimisation consiste proter des barrires de synchronisation de lapplication pour effectuer les points de reprise. Des mcanismes implments sur TreadMarks [3] sauvegardent des points de reprise coordonns (entre autres), et protent de la synchronisation du systme lors du lancement dun ramasse miettes pour effectuer ce type de point de reprise [39]. Une solution apporte dans [84] pour les systmes mmoire virtuellement partage exploite la rplication des donnes inhrente ces systmes pour la sauvegarde des points de reprise. La prsence de rpliques sur diffrents sites permet de minimiser les transferts de donnes. De plus, le fait que les donnes soient conserves dans la mmoire de plusieurs nuds et non sur disque permet des accs rapides aux donnes de reprise. De surcrot, les donnes utiles pour la tolrance aux fautes peuvent tre exploites par le systme de mmoire partage ce qui permet de compenser en partie le surcot d aux mcanismes de tolrance aux fautes.
3.4.3
Points de reprise non-coordonns
Points de reprise indpendants. Contrairement aux points de reprise coordonns, les points de reprise indpendants ne ncessitent pas de synchronisation interprocessus au moment de la sauvegarde des points de reprise. Les processus sauvegardent leur tat de temps en temps de manire indpendante, le surcot d la synchronisation est ainsi vit. De plus, chaque processus peut ainsi choisir un moment propice la sauvegarde de son tat,
3.5 Tolrance aux fautes dans les grilles : vers une approche hirarchique
37
par exemple quand il y a peu de donnes sauvegarder. Ceci rend cette technique intressante lors des excutions sans faute. Cependant, les tats sauvegards nappartenant pas ncessairement un tat global cohrent, le nombre dtats conserver pour la reprise peut tre trs important introduisant ainsi un surcot en terme despace de stockage. La mise en place dun ramasse-miettes est galement ncessaire pour supprimer les tats devenus inutiles. De plus, an dviter des successions de retours en arrire, appeles effet domino, des mcanismes de journalisation doivent tre mis en place, apportant galement un surcot y compris lors des excutions sans faute. Enn, la reprise aprs faute est complexie car il faut calculer la ligne de recouvrement, cest--dire jusquo les processus doivent revenir en arrire an de redmarrer sur un tat global cohrent. Points de reprise induits par les communications. La technique des points de reprise induits par les communications peut tre vue comme une variante de celle des points de reprise indpendants [47]. Il sagit de sauvegarder des points de reprise indpendants comme dcrit ci-dessus, mais, an de limiter lampleur du retour en arrire potentiel, les processus sont contraints de temps en temps de sauvegarder leur tat. En effet, si lon force un processus sauvegarder son tat chaque rception de message, cela limine leffet domino. Cependant, cet avantage est acquis au prix de nombreux points de reprise inutiles. Des solutions permettent de limiter ce nombre grce lutilisation de donnes supplmentaires portes par les messages de lapplication, par exemple des graphes ou parties de graphes de dpendances. Alors que les mcanismes de rplication vus la section 3.3 sont bien adaptes pour amliorer la disponibilit des donnes, les mcanismes de sauvegarde de points de reprises sont plus adapts pour la tolrance aux fautes des applications. Nous proposons la section 7.4 des mcanismes de sauvegarde de points de reprises hirarchiques hybrides, alliant des sauvegardes de points de reprises coordonns au sein des sites des grilles et des sauvegardes de points de reprise induits par les communications entre les sites. Ces mcanismes peuvent tre mis en place an de tolrer les dfaillances des clients du service de partage de donnes.
tel-00411447, version 1 - 27 Aug 2009
3.5 Tolrance aux fautes dans les grilles : vers une approche hirarchique
La nature dynamique des grilles de calcul est en grande partie due la prsence de fautes. Ces fautes sont essentiellement les dfaillances franches des nuds qui la composent. Il existe de nombreux travaux de recherche, aussi bien sur la dtection que sur la tolrance de ce type de dfaillance. Nous avons notamment vu des approches bases sur des techniques de rplication et sur des mcanismes de points de reprise. Cependant, ces tudes ont souvent t menes de manire thorique ou dans des systmes distribus petite chelle. De plus, lexception de [18], ces tudes ne prennent gnralement pas en compte la topologie rseau des grilles de calcul. Aussi, de nombreuses solutions proposes reposent-elles sur des synchronisations entre groupes de nuds. Ds lors que lon souhaite adapter ce type de solution aux grilles de calcul, il semble judicieux de prendre en compte la topologie du rseau utilis. En effet la diffrence de latence, dun facteur 10.000, entre les rseaux internes des grappes de calculateurs et celle des rseaux externes reliant ces grappes entre elles rend les
38
synchronisations intragrappe bien moins coteuses que les synchronisations faisant intervenir des nuds localiss dans des grappes diffrentes. Le chapitre 7 dcrit notre approche hirarchique pour la gestion de la tolrance aux fautes, prenant en compte cette diffrence.
tel-00411447, version 1 - 27 Aug 2009
39
Chapitre
Approches pour la gestion de la cohrence de donnes

tel-00411447, version 1 - 27 Aug 2009
Sommaire
4.1 Modles et protocoles de cohrence dans les systmes mmoire virtuellement partage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.1 Notion de cohrence . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.2 Modles de cohrence forte . . . . . . . . . . . . . . . . . . . . . . . . 4.1.3 Modles de cohrence relche . . . . . . . . . . . . . . . . . . . . . . 4.1.4 Approches pour la localisation des donnes . . . . . . . . . . . . . . Modles et protocoles de cohrence dans les systmes pair--pair . . . . . 4.2.1 Les systmes pair--pair . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.2 Approches pour la localisation des donnes . . . . . . . . . . . . . . 4.2.3 Cohrence des donnes dans les systmes pair--pair . . . . . . . . . Modles et protocoles de cohrence dans les bases de donnes . . . . . . . 4.3.1 Particularit des donnes . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.2 Notion de transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.3 Cohrence de donnes rpliques : divergence et rconciliation . . . Cohrence de donnes dans les grilles : vers une approche hirarchique . 40 40 41 41 42 44 44 45 46 48 48 49 50 50
4.2
4.3
4.4
Les applications distribues permettent de faire des oprations en parallle sur plusieurs nuds. Pour ce faire, les donnes partages accdes par diffrents nuds se retrouvent souvent dupliques an de permettre des accs en parallle et de limiter le nombre de transferts. Dans le chapitre 2, nous avons montr que cette gestion de la cohrence devenait un facteur limitant lors de la conception dapplications pour les grilles de calcul. Nous proposons donc dexternaliser cette gestion vers de notre service de partage de donnes. Ainsi, toute application qui utilisera notre service de partage de donnes en bnciera.
40
Chapitre 4 Approches pour la gestion de la cohrence de donnes
Dans ce chapitre, nous nous focalisons sur la gestion de la cohrence de donnes. Nous prsentons dans la section 4.1 les approches qui ont t conues pour les systmes mmoire virtuellement partage (MVP). Ces approches prsentent lintrt doffrir des modles de cohrence efcaces, adapts au calcul haute performance et donc aux applications que nous visons, les applications de couplage de codes dcrites la section 2.2. En revanche, elles ne prennent gnralement en compte ni les aspects lis la grande chelle, ni ceux lis la prsence de fautes. Des solutions prenant en compte ces aspects ont t dveloppes dans le cadre des systmes pair--pair (P2P) dcrits dans la section 4.2. Enn, nous dcrirons la gestion de la cohrence au sein des systmes de bases de donnes rpliques dans la section 4.3.
4.1 Modles et protocoles de cohrence dans les systmes mmoire virtuellement partage
tel-00411447, version 1 - 27 Aug 2009
Les systmes mmoire virtuellement partage ont t conus pour des architectures de type grappe de calculateurs. Ils ont pour but doffrir lillusion dune mmoire unique avec un seul espace dadressage. Les systmes mmoire virtuellement partage permettent ainsi de programmer des applications distribues pour des grappes de calculateurs de la mme manire que lon programme les calculateurs multi-processeurs mmoire partage. La gestion de la mmoire est totalement dlgue au systme et les programmeurs dapplications accdent la mmoire sans avoir localiser ou transfrer explicitement les donnes.
4.1.1
Notion de cohrence
Un systme mmoire virtuellement partage est responsable de la gestion de la cohrence des donnes. Le systme propose aux programmeurs un modle de cohrence. Le modle de cohrence dcrit la manire dont la cohrence des diffrentes copies des donnes est gre. Cest le modle de cohrence qui va dterminer comment les mises jour dune donne par un processus seront visibles par les autres processus. Les modles de cohrence sont mis en uvre par des protocoles de cohrence. Il existe de nombreux modles de cohrence. Tous noffrent pas les mme performances et nimposent pas les mmes contraintes aux programmeurs dapplications. Nous distinguons deux grandes familles de modles1 : les modles cohrence forte et les modles cohrence relche (ou faible). Cette classication discrimine les modles de cohrence en fonction des contraintes quils imposent aux programmeurs : les modles de cohrence imposant aux applications lutilisation doprations autres que les oprations daccs aux donnes (comme des oprations de synchronisation) sont des modles de cohrence relche, ils sont galement appels modles de cohrence avec synchronisation, les autres sont des modles de cohrence forte, ou modles de cohrence sans synchronisation.
1
Il existe dautres manires de classier les modles de cohrence, celle choisie correspond notre vision.
4.1 Cohrence dans les systmes mmoire virtuellement partage
41
4.1.2
Modles de cohrence forte
Les modles de cohrence forte nimpliquent pas lutilisation doprations spciques. Les applications accdent aux donnes et le systme gre les transferts et copies de manire compltement transparente. Les modles de cohrence forte se distinguent les uns des autres par les garanties offertes en terme de cohrence de donnes. Cohrence stricte (atomic consistency). La cohrence stricte correspond lintuition naturelle de la notion de cohrence. Dans ce modle, toute lecture retournera la dernire valeur qui a t crite. Cest le modle de cohrence qui est gnralement mis en uvre au niveau des units de gestion mmoire dans les systmes mono-processeurs. La mise en uvre dun tel modle au sein dune MVP savre cependant trs coteuse : lors de chaque accs la mmoire partage, une synchronisation globale est ncessaire an de satisfaire les garanties. Cohrence squentielle (sequential consistency). La cohrence squentielle a t formalise par Leslie Lamport en 1979 [75]. Ce modle est moins restrictif, il garantit que chaque processus voit toutes les oprations dans le mme ordre, mais il ne garantit pas quune lecture retournera la dernire valeur affecte par une criture. Avec ce modle de cohrence, le rsultat de toutes les excutions est le mme que si les oprations de tous les processus avaient t excutes dans un ordre squentiel donn dans lequel toutes les oprations de chaque processus suivent lordre du programme. Les premiers systmes mmoire virtuellement partage utilisent ce modle de cohrence. Cohrence causale (causal consistency). Le modle de cohrence causale [60] relche les contraintes par rapport au modle de cohrence squentiel. Il nest en effet pas toujours ncessaire dobtenir un ordre total unique vu par chacun des processus. Ce modle se base sur la relation de causalit (happened before) dcrite dans [76] pour dterminer lordre des critures. La relation happened before permet de lier entre eux certains vnements par un ordre partiel bien dni et de relcher les contraintes sur les vnements indpendants. La plus grande partie des applications tolrent en effet que deux critures indpendantes ne soient pas vues dans le mme ordre par tous les processus.
tel-00411447, version 1 - 27 Aug 2009
4.1.3
Modles de cohrence relche
Les modles de cohrence relche imposent aux programmeurs lutilisation de primitives supplmentaires, gnralement des primitives de synchronisation. Les informations fournies par ces primitives permettent aux protocoles de cohrence implmentant ces modles dtre plus efcaces en diminuant le nombre de messages sur le rseau. Aussi, ces modles sont souvent utiliss par les applications de calcul scientique haute performance. Nous prsentons ici diffrents modles de cohrence relche. Cohrence faible (weak consistency). Ce modle propose deux types daccs : les accs ordinaires (lectures/critures) et les accs de synchronisation (accs aux objets de synchronisation). Les critures ne sont pas propages lors des accs ordinaires. En revanche, lors des accs de synchronisation, toutes les informations sont mises jour. Le modle garantit que lensemble de la mmoire est cohrent chaque point de synchronisation, cest--dire : 1) que les toutes les modication locales sont propages aux autres processus ; et 2) que toutes les modications des autres processus sont visibles localement.
42
Cohrence la libration (release consistency). Le modle de cohrence la libration amliore le modle de cohrence faible en relchant les garanties de cohrence : contrairement au modle de cohrence faible, lensemble de la mmoire nest pas ncessairement cohrent chaque opration de synchronisation. Avec ce modle, deux types daccs de synchronisation sont distingus : acquire et release. Ces deux oprations permettent de dlimiter une section critique au sein de laquelle une partie de la mmoire partage sera accde. Ainsi, lors dun accs de type acquire plac en entre de section critique, le modle garantit que toute les critures des autres processus sont visibles localement ; et lors dun accs de type release en sortie de section critique, le modle garantit que toutes les critures locales sont propages aux autres processus. Cohrence la libration paresseuse (lazy release consistency). La cohrence la libration paresseuse relche encore plus les contraintes et rduit encore le nombre de communications. Le modle de cohrence la libration propage toutes les critures locales lors des accs synchroniss de type release. Or certaines de ces propagations sont inutiles car les processus concerns neffectuerons pas ncessairement des accs aux donnes mises jour. La cohrence la libration paresseuse rduit encore le nombre de communications en ne propageant les critures quaux processus qui dclarent leur intention daccder aux donnes, en effectuant un accs synchronis de type acquire. Cette cohrence a t implmente dans le systme MVP TreadMarks [3]. Une implmentation consiste coner la gestion des accs aux donnes un nud particulier. Cette technique sappelle : home-based lazy release consistency (HLRC) [107]. Cohrence lentre (entry consistency). Le systme MVP Midway [15] a introduit le modle de cohrence lentre. Ce modle associe chaque variable partage un objet de synchronisation spcique. Cette association variable/objet de synchronisation permet de ne transfrer que les mises jour des variables ncessaires, et non plus de toute la mmoire. De plus, il est alors possible davoir des critures concurrentes sur des variables diffrentes. Le modle de cohrence lentre introduit galement une nouvelle opration de synchronisation : acquire_read. Le modle diffrencie ainsi les accs en mode exclusif (acquire) des accs en mode non-exclusif (acquire_read). Cette distinction permet dautoriser des lectures concurrentes dune mme variable. Cependant, les lectures concurrentes des critures ne sont pas possibles. Cohrence de porte (scope consistency). Le modles de cohrence de porte [61] est proche du modle de cohrence lentre. Le modle de cohrence lentre impose au programmeur dassocier explicitement un verrou chaque donne. Le modle de cohrence de porte quant lui utilise les oprations de synchronisation dj prsentes dans le programme. Dans ce cas, lassociation verrou/donne est ralise implicitement par analyse du programme.
tel-00411447, version 1 - 27 Aug 2009
4.1.4
Approches pour la localisation des donnes
Un protocole de cohrence mettant en uvre un modle de cohrence doit pouvoir localiser les donnes. La localisation dune donne revient trouver le nud stockant la copie la plus jour2 , cest--dire celui hbergeant le processus ayant effectu la dernire criture. Ce nud est appel propritaire de la donne. On appelle nud gestionnaire dune donne le
2
Ou satisfait un critre de fracheur propre au modle de cohrence.
4.1 Cohrence dans les systmes mmoire virtuellement partage
43
nud qui est charg de localiser son propritaire. On distingue des gestionnaires distribus et des gestionnaires centraliss. 4.1.4.1 Gestionnaires centraliss Dans le cas dun gestionnaire centralis, toutes les requtes daccs une donne, les lectures comme les critures, sont adresses au nud gestionnaire, choisi. Ce nud est responsable de la gestion de lensemble des donnes. Cette gestion centralise est bien adapte de petites architectures possdant des rseaux dinterconnexion performants comme les grappes de calculateurs. En revanche, elle prsente des limites en terme de passage lchelle. Au sein des systmes grande chelle, les latences des communications entre les nuds peuvent tre grandes. Lorsque des nuds loigns en terme de latence du nud gestionnaire accdent une donne partage, les changes rseau entre ces diffrents nuds risquent de ralentir lapplication dans son ensemble. En plus des limites lies au passage lchelle, ces protocoles sont sensibles aux fautes. Si le nud gestionnaire tombe en panne, lensemble des donnes partages devient inaccessible. 4.1.4.2 Gestionnaires distribus Les approches bases sur un gestionnaire distribu permettent une dcentralisation du gestionnaire. Nous distinguons trois types de gestionnaire distribu : 1) gestionnaire distribu xe, 2) gestionnaire distribu diffusion, et 3) gestionnaire distribu dynamique. Gestionnaire distribu xe. Cette approche permet un meilleur quilibrage de charge grce lutilisation de plusieurs nuds gestionnaires. Chaque nud gestionnaire est responsable dun sous-ensemble des donnes partages. Cette approche ne rsout cependant en rien les problmes lis au passage lchelle et la tolrance aux fautes mentionns ci-dessus. Gestionnaire distribu diffusion. Cette approche consiste diffuser les requtes de localisation tous les nuds du systme. Le gestionnaire se trouve donc distribu sur lensemble des nuds. Ceci implique de nombreuses diffusions globales, ce qui est trs coteux en terme de communication. Cette approche est conue pour des systmes de petite taille et devient impraticable ds que la taille du systme augmente. En revanche la localisation des donnes reste possible en cas de fautes. Gestionnaire distribu dynamique. Cette approche a t propose par Li et Hudak [79]. Elle reprend le principe de celle du gestionnaire distribu xe, ceci prs que tous les nuds grent la localisation de toutes les donnes. Cependant, cette localisation nest pas exacte : les nuds connaissent seulement un propritaire probable. En cas de changement de propritaire dune donne lors dun accs en criture, lancien propritaire transmet la donne au nouveau et le considre comme le nouveau propritaire probable. Il pourra ainsi lui retransmettre les requtes daccs la donne. Ce mcanisme permet de mettre en place un chanage an de pouvoir systmatiquement retrouver la donne. Ces mcanismes sophistiqus permettent une localisation efcace des donnes au sein des systmes MVP sexcutant sur des grappes de calculateurs. En revanche, l encore, les problmes lis au passage lchelle ainsi qu la tolrance aux fautes
tel-00411447, version 1 - 27 Aug 2009
44
Chapitre 4 Approches pour la gestion de la cohrence de donnes ne sont pas rsolus. Au contraire, le mcanisme de chanage accentue des problmes. Le chemin rseau emprunter pour suivre le chanage peut exploiter des liens forte latence. De plus, la localisation dune donne devient impossible ds quun maillon de la chane, cest--dire un nud, est en panne.
4.2 Modles et protocoles de cohrence dans les systmes pair-pair

Les protocoles de cohrence pour les MVP, conus pour des grappes de calculateurs, font implicitement lhypothse que la taille du systme est restreinte (quelques centaines de nuds au maximum) et que les fautes sont exceptionnelles. Il est vrai cependant que certains systmes mmoire virtuellement partage prennent en compte les dfaillances franches de nuds [69, 67, 9]. En revanche, les systmes pair--pair ont dmontr dexcellentes proprits de passage lchelle et de tolrance aux fautes. Des systmes comme KaZaA [116], Gnutella [86] ou eDonkey [108] runissent des millions de nuds qui se connectent et se dconnectent avec une frquence leve. Cependant, la majeure partie de ces systmes [116, 86, 108] est ddie des applications de partage de chiers et ne gre que des donnes non modiables, cest--dire en lecture seule. Il sagit gnralement dune gestion au mieux (best effort en anglais). Ils ne proposent par consquent aucun support pour la gestion de la cohrence des donnes. Rcemment, quelques systmes pair--pair proposant la gestion de donnes modiables ont vu le jour [73, 85, 23, 40]. Nous les dcrivons brivement dans cette section.
tel-00411447, version 1 - 27 Aug 2009
4.2.1
Les systmes pair--pair
Les systmes pair--pair sont par nature compltement distribus. Dans ces systmes, chaque pair peut tre la fois client et serveur. Plus gnralement, chaque pair peut mme jouer lensemble des rles existants dans le systme. Il en rsulte que les communications au sein de ces systmes sont bien distribues et quils sont trs bien adapts aux grandes chelles. De plus, ces systmes prsentent une bonne tolrance la volatilit (connexions et dconnexions de nuds). An de pouvoir sexcuter trs grande chelle, les systmes pair--pair reposent sur la notion de rseau logique (overlay en anglais). Un rseau logique pair--pair dnit les liaisons logiques entre les diffrents pairs du systme, cest--dire quel pair connat quel pair. Ceci permet chaque pair de navoir grer quune vision partielle du systme, et non le systme dans sa totalit. Cest principalement cette vision partielle qui confre aux systmes pair--pair leurs proprits de passage lchelle et de tolrance la dynamicit. Les systmes pair--pair sont gnralement classs en deux familles en fonction du rseau logique quils utilisent : nous distinguons les systmes pair--pair non-structurs des systmes pair--pair structurs. Systmes pair--pair non-structurs. Au sein des systmes pair--pair non-structurs, chaque pair connat un sous-ensemble de pairs. Ce sous-ensemble est gnralement dtermin de manire alatoire mais il existe cependant de nombreux travaux de
4.2 Modles et protocoles de cohrence dans les systmes pair--pair
45
recherche visant rapprocher au sein du rseau logique les pairs ayant des afnits [102, 95, 57, 103] ou prendre en compte la distance en latence entre les pairs [41]. Ces rseaux logiques permettent en gnral de supporter une grande dynamicit. Gnutella [86] est bas sur un tel rseau. Systmes pair--pair structurs. Les systmes pair--pair structurs sappuient sur une structure distribue, en gnral une table de hachage (DHT pour langlais Distributed Hash Table). Chaque pair se voit attribuer un identiant rsultat de lapplication dune fonction de hachage sur son adresse IP (par exemple SHA1 ou MD5). Les pairs peuvent ainsi tre classs selon leur identiant au sein dune table de hachage distribue. Chaque pair possde alors un index contenant un certain nombre dautres pairs rpartis sur la DHT. Le contenu de cet index varie selon limplmentation. En utilisant cette approche, des systmes pair--pair comme Chord [99], Pastry [94] ou Tapestry [106] obtiennent une couche de routage trs performante. Systmes pair--pair hybrides. Certains systmes pair--pair sinspirent la fois des systmes structurs et des systmes non-structurs. Des systmes comme KaZaA [116] utilisent la notion de super-pair : les pairs classiques sont lis des super-pairs qui eux-mme sont relis entre eux. Les implmentations actuelles de la spcication JXTA [115] proposent une table de hachage distribue entre les super-pairs appels pairs de rendez-vous.
tel-00411447, version 1 - 27 Aug 2009
4.2.2
Approches pour la localisation des donnes
Les systmes pair--pair utilisent le rseau logique sous-jacent pour la localisation des donnes et le routage. Les systmes non-structurs utilisent des mcanismes dinondation pour localiser les donnes. Pour cela, un pair envoie une requte chacun de ses voisins dans le rseau logique puis chacun des voisins la retransmet chacun de ses voisins, et ainsi de suite. Des mcanismes sont gnralement mis en place pour limiter linondation : le nombre de retransmissions est limit ; de plus, chaque retransmission, le nombre de voisins contacter peut tre rduit grce des ltres de Bloom. Enn de nombreux travaux de recherche visent acclrer la localisation des donnes conservant en cache les rsultats des recherches antrieures. Les mcanismes de recherche des systmes non-structurs offrent une localisation incertaine : des donnes prsentes dans le systme peuvent ne pas tre trouves lors dune recherche. Les systmes structurs attribuent des identiants aux donnes dans le mme espace que celui des identiants des nuds. Le pair dont lidentiant est numriquement le plus proche de celui dune donne est responsable de cette donne. Cela signie quil connat lemplacement de cette donne, limage des nuds gestionnaires des MVP. Ainsi, la localisation dune donne revient acheminer une requte vers le pair dont lidentiant est le plus proche. La DHT au sein de laquelle sont rpartis les pair permet de le faire de manire efcace, gnralement en log(n) sauts logiques3 , o n est le nombre de pairs dans le systme. De surcrot, la localisation dans ces systmes est certaine.
3
Un saut logique correspond au chemin physique sparant deux voisins dans le rseau logique.
46

Primary tier
critures
Clients
Propagation des mises jour lectures
tel-00411447, version 1 - 27 Aug 2009
Serveurs secondaires
(propagation "au mieux" entre les serveurs)
F IG . 4.1 Communications au sein du systmes Oceanstore.
4.2.3
Cohrence des donnes dans les systmes pair--pair
La majorit des systmes pair--pair sont conus pour partager des chiers en lecture seule [116, 86, 108]. Dans ce cas-l, les problmes de cohrence des donnes sont inexistants : les donnes sont places et rpliques dans le systme puis ne sont jamais modies. La principale problmatique laquelle font face ces systmes consiste donc en la recherche de donnes prsentes dans le systme. Toutefois, certains systmes pair--pair comme OceanStore [73], Ivy [85] et Pastis [23] sintressent au partage de donnes modiables. Ce sont trois systmes de gestion de chiers. OceanStore [73] est illustr sur la gure 4.1. Il permet de partager des donnes modiables. Ce systme utilise un ensemble de pairs jouant un rle particulier appel primary tier. Il est responsable de la gestion des modications apportes aux donnes. Cest le primary tier qui reoit les requtes de modication. Il est en charge de la rsolution des conits en dcidant de lordre dapplication des modications. Cette dcision est ensuite transmise lensemble des pairs possdant une copie. Lensemble de pairs composant le primary tier est suppos stable et possdant un bon rseau dinterconnexion. Ce systme se rapproche donc du modle client/serveur o le serveur est mis en uvre par un ensemble de pairs particuliers. Ivy [85] est un systme exploitant la notion de journaux (logs) pour permettre plusieurs nuds deffectuer des critures concurrentes. Comme lillustre la gure 4.2, chaque
4.2 Modles et protocoles de cohrence dans les systmes pair--pair
47
Utilisateur 1
Dbut de journal
Enregistrement n1
Enregistrement n11
Enregistrement n12
Utilisateur 2
Dbut de journal
Enregistrement n2
Enregistrement n21
Enregistrement n22
tel-00411447, version 1 - 27 Aug 2009
Utilisateur p
Dbut de journal
Enregistrement np
Enregistrement np1
Enregistrement np2
F IG . 4.2 Ivy utilise un journal par utilisateur pour stocker les critures.
utilisateur possde un journal dans lequel il crit les modications apportes chaque donne partage. Ivy, bas sur Chord, utilise la DHT pour stocker les journaux des diffrents utilisateurs. La lecture dun chier ncessite donc le parcours de multiples journaux. De plus, ds quun chier est partag par plusieurs utilisateurs, des conits peuvent apparatre. Ivy propose des outils permettant leur rsolution manuelle. Le modle de cohrence implment par ce systme est de type relch. Pastis [23] est conu comme un vritable systme de gestion de chiers. Il sappuie sur la notion de descripteur de chiers (en anglais i-node). Les descripteurs de chiers sont stocks dans une DHT (PAST) sous forme de blocs modiables ; ces blocs sont appels UCB pour langlais User Certicate Block. Ils contiennent en effet des donnes permettant de vrier lintgrit du bloc ainsi que son propritaire. Les descripteurs de chiers contiennent des pointeurs sur des blocs de contenu : les CHB pour langlais Content Hash Block. Les CHB sont des blocs non-modiables. Les modications de chiers entranent donc des suppressions/ajouts de CHB et des modications dUCB. La gure 4.3 illustre les relations entre ces diffrents blocs. Le systme Pastis met en uvre des mcanismes complexes de signature an dassurer lintgrit et lauthenticit des chiers. Il propose deux modles de cohrence relche : 1) le modle close-toopen, dans lequel que les critures ne sont propages quaprs la fermeture du chier et les critures distantes ne sont visibles qu louverture du chier ; et 2) le modle plus relch read your writes qui garantit que chaque lecture rete toutes les critures locales prcdentes.
48

Contenu dun rpertoire
Nom 1 Nom 2 Nom 3 Cl inode 1 Cl inode 2 Cl inode 3
Descripteur de fichier (inode)

Attributs Cl bloc 1 Cl bloc 2 Cl bloc 3
Contenu de fichier
CHB UCB
Les cls reprsentent des identifiants permettant la localisation au sein de la DHT.
CHB
F IG . 4.3 Le systme de chier Pastis.
tel-00411447, version 1 - 27 Aug 2009
Bien que ces systmes pair--pair permettent le partage de chiers modiables grande chelle, ils ont t conus comme des systmes de gestion de chiers et proposent des modles de cohrence trs relchs qui ne conviennent gnralement pas pour le partage des donnes des applications de calcul scientique.
4.3 Modles et protocoles de cohrence dans les bases de donnes

La gestion des donnes dans les bases de donnes sloigne quelque peu des approches dcrites jusquici. Cette diffrence est principalement due au fait que les systmes de gestion de bases de donnes (SGBD) prennent en compte le type des donnes ainsi que des dpendances interdonne. On rencontre cependant les mmes problmatiques lies la cohrence des donnes : prsence de multiples copies pour amliorer la localit des accs, propagation des mises jour, accs concurrents aux donnes, etc.
4.3.1
Particularit des donnes
Au sein des systmes de bases de donnes, les donnes sont rparties dans des tables et chaque ligne dune table forme un ensemble dattributs appel tuple. Un schma relationnel dcrit les tables ainsi que les relations entre les donnes. Il existe des dpendances intratuple, cest--dire entre les attributs dun mme tuple, appeles dpendances fonctionnelles (df ) et des dpendances entre les attributs de tables diffrentes appeles dpendances dinclusion (di). Dnition 4.1 : dpendance fonctionnelle Il y a une dpendance fonctionnelle lorsque la valeur dun attribut (ou dun groupe dattributs) dtermine de faon unique celle dautres attributs. Dnition 4.2 : dpendance dinclusion Il y a une dpendance dinclusion lorsque les valeurs dun attribut dune table doivent appartenir lensemble des valeurs dun attribut dune autre table.
4.3 Modles et protocoles de cohrence dans les bases de donnes
49
La gestion de la cohrence au sein des systmes de bases de donnes intervient deux niveaux : 1) entre les donnes (les attributs), ce qui est spcique aux bases de donnes ; et 2) entre les copies des donnes rpliques. Cohrence interdonne. Le premier niveau, spcique aux bases de donnes, vient de la gestion des dpendances interdonne par les systmes de gestion de bases de donnes. Les SGBD utilisant des schmas relationnels pour dcrire les relations entre les donnes doivent prendre en compte les dpendances entre les diffrentes donnes. En consquence, la mise jour dune donne doit se faire de manire cohrente avec celles qui lui sont lies. Il peut donc tre ncessaire de mettre jour de manire atomique un ensemble de donnes. On parle alors de transaction. Cohrence de donnes rpliques. De la mme manire que pour les systmes mmoire virtuellement partage ou les systmes pair--pair, les systmes de bases de donnes utilisent la rplication an damliorer les performances des accs aux donnes. Elle favorise en effet la localit des accs dune part, et la rpartition de la charge dautre part. Des mcanismes pour propager les mises jour entre les multiples copies sont alors ncessaires. Les deux sous-sections suivantes dtaillent ces deux niveaux de cohrence.
tel-00411447, version 1 - 27 Aug 2009
4.3.2
Notion de transaction
La cohrence interdonne est assure par la notion de transaction. Nous reprenons la dnition donne dans [88]. Dnition 4.3 : transaction Une transaction est une suite doprations dcritures ou de lectures sur des donnes qui se termine en tant soit valide, soit abandonne. Les transactions doivent prsenter les proprits suivantes : 1) atomicit, 2) cohrence, 3) isolation, et 4) durabilit. Atomicit. Une transaction doit permettre de mettre jour de manire atomique un ensemble de donnes dpendantes les unes des autres. Cohrence. La base de donne doit reste cohrente aprs une transaction. Isolation. Une transaction na pas deffet visible tant quelle na pas t valide. Durabilit. Une transaction valide verra ses effets perdurer. Ces proprits sont gnralement appeles ACID pour Atomicit, Cohrence, Isolation et Durabilit. Cependant, les SGBD peuvent relcher la proprit disolation an damliorer le paralllisme et donc les performances des accs (transactions optimistes). Dans ces casl, certains accs peuvent tre effectus sur des donnes dont la valeur est obsolte, ou non encore valide. Ces donnes peuvent dailleurs ne jamais tre valides et on parle alors de divergence de transaction. Autoriser les divergences des transactions en criture peut savrer trs dangereux, les dpendances interdonne pouvant se retrouver non-satisfaites et la base de donne serait alors dans un tat corrompu. En revanche, certaines transactions de lecture peuvent se satisfaire de donnes lgrement obsoltes. Dans ce cas, il est possible damliorer fortement les performances [88] en relchant les contraintes sur la fracheur des donnes lues.
50
4.3.3
Cohrence de donnes rpliques : divergence et rconciliation
Lors de lutilisation des bases de donnes, les requtes daccs aux donnes peuvent tre coteuses : elles ncessitent souvent le parcours de tables entires. La rplication des donnes permet dans ce cas non seulement damliorer la localit des accs, mais galement de rpartir la charge engendre par les requtes entre plusieurs nuds. Les mcanismes de rplication responsables de la propagation des mises jour entre les diffrentes copies se dclinent en plusieurs catgories. On distingue la rplication synchrone et la rplication asynchrone. Cette dernire catgorie se dcline en deux sous-catgories, la rplication asynchrone optimiste et la rplication asynchrone pessimiste. Ces diffrentes catgories de rplication sont dcrites ci-dessous. Rplication synchrone. Ces mcanismes sont similaires ceux vus la section 3.3.2, il sagit en gnral de rplication semi-active. Toute modication se fait avec des proprits datomicit, toutes les copies dune mme donne sont isoles an de valider chaque modication [35]. Les transactions ne sont donc valides que lorsque que toutes les copies sont cohrentes. Rplication asynchrone optimiste. Ces mcanismes diffrent la propagation des mises jour. Des modications concurrentes peuvent avoir lieu sur des copies diffrentes. Dans ces cas-l, il est ncessaire de rconcilier les copies, gnralement en rordonnanant et r-excutant les transactions ou en abandonnant lune (ou certaines) dentre elles. Les rconciliations tant trs coteuses, ce type de rplication est gnralement utilis lorsquil est possible de faire lhypothse que les cas de conits sont rares [2, 52]. Rplication asynchrone pessimiste. La rplication asynchrone pessimiste garantit la cohrence des copies en ordonnanant les transactions a priori an dviter les conits [87]. Ce type de rplication peut mener des copies temporairement divergentes, le temps de la propagation des mises jour, mais ne ncessite pas la mise en place de mcanismes de rconciliation : les diffrentes copies voluent de la mme manire et donc convergent ultimement. Les systmes de gestion de bases de donnes rpliques font face une double problmatique de cohrence de donnes. Ils doivent non seulement prendre en compte les diffrentes copies de chaque donne, mais galement maintenir la cohrence interne de la base de donnes. Nous proposons au chapitre 8 un mcanisme permettant des lectures relches rapprocher du relchement induit par les techniques de rplication asynchrone pessimiste.
tel-00411447, version 1 - 27 Aug 2009
4.4 Cohrence de donnes dans les grilles : vers une approche hirarchique
Comme prsent dans les sections prcdentes, la gestion de la cohrence de donnes a fait lobjet de recherches dans diffrents domaines. Dans chacun de ces domaines, des solutions spciques ont t proposes. Le tableau ci-dessous rsume les caractristiques des solutions dcrites dans ce manuscrit. Les systmes mmoire virtuellement partage, conus pour des applications scientiques haute performance et petite chelle (en gnral quelques dizaines, et au maximum quelques centaines de nuds), offrent la proprit de transparence et permettent la mise
4.4 Cohrence de donnes dans les grilles : vers une approche hirarchique Systmes MVP Non Non Nombreux Systmes P2P Trs bon Trs bonne Exceptionnels (lecture seule en gnral) Bases de donnes rpliques Bon Bonne Spciques aux bases de donnes
51
Passage lchelle Tolrance aux fautes Modles et protocoles de cohrence
tel-00411447, version 1 - 27 Aug 2009
en uvre de nombreux modles et protocoles de cohrence. En revanche, ils ne prennent gnralement pas les fautes en compte, ou considrent alors quelles sont exceptionnelles. Les systmes pair--pair, quant eux, prsentent des mcanismes permettant un bon support de la volatilit et sadaptent bien aux architectures grande chelle, mais offrent peu de mcanismes pour la gestion de la cohrence des donnes modiables. Enn, des travaux de recherche dans le cadre des bases de donnes proposent des mcanismes varis de rplication ainsi que des solutions lgantes permettant de rconcilier des donnes divergentes. Cependant la gestion des donnes par les SGBD est trs spcique et ne sadapte pas directement aux applications scientiques que nous visons. Dans le cadre des grilles de calcul, il semble important doffrir : 1) les proprits de passage lchelle ; 2) des modles et protocoles de cohrence pour des applications scientiques distribues ; et galement 3) un support pour la volatilit. Bien que dans le cadre des grilles de calcul la volatilit soit bien moins importante que dans le cadre des systmes pair-pair, les dconnexions de nuds ne peuvent plus tre considres comme des exceptions comme cest le cas pour les systmes mmoire virtuellement partage. Dans la partie suivante, nous dcrivons notre contribution qui consiste offrir une gestion de la cohrence tolrante aux fautes, en sinspirant la fois des mcanismes de gestion de la cohrence des donnes vus dans ce chapitre et des mcanismes de rplication vus dans le chapitre prcdent.
tel-00411447, version 1 - 27 Aug 2009
53
Deuxime partie
tel-00411447, version 1 - 27 Aug 2009
Notre contribution : une approche hirarchique conjointe pour la tolrance aux fautes et la cohrence des donnes
tel-00411447, version 1 - 27 Aug 2009
55
Chapitre
tel-00411447, version 1 - 27 Aug 2009
tude de cas : vers un protocole de cohrence des donnes tolrant aux fautes pour la grille
Sommaire
5.1 5.2 Le partage de donnes . . . . . . . . . . . . . . . . . Un exemple de protocole non tolrant aux fautes . 5.2.1 Le modle de cohrence lentre . . . . . . 5.2.2 Un protocole bas sur une copie de rfrence 5.2.3 Fonctionnement du protocole de cohrence . Un protocole de cohrence hirarchique . . . . . . 5.3.1 Limites dun protocole plat . . . . . . . . . 5.3.2 Solution : un protocole hirarchique . . . . . Un protocole de cohrence tolrant aux fautes . . . 5.4.1 Ncessit de tolrer les fautes . . . . . . . . . 5.4.2 Utilisation de techniques de rplication . . . Vers un protocole hirarchique tolrant aux fautes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 57 57 58 58 62 62 62 65 65 66 68
5.3
5.4
5.5
Dans le chapitre 4, nous avons vu quil existait plusieurs approches pour la gestion du partage de donnes. Nous nous intressons plus particulirement au partage de donnes pour des applications de type calcul scientique, comme les applications de couplage de code dcrites la section 2.2. Les modles de cohrence tudis dans le cadre des systmes mmoire virtuellement partage (MVP) ont t conus puis optimiss pour ce type dapplication. Cest en effet gnralement pour des applications scientiques (par exemple des simulations numriques distribues) qui sexcutent au sein des grappes de calculateurs que les systmes mmoire
56
Chapitre 5 tude de cas
virtuellement partage ont t conus. Pour cette raison, dans ce chapitre, nous prenons un exemple particulier de protocole de cohrence dvelopp dans le cadre des MVP. Le protocole choisi implmente le modle de cohrence lentre et a t propos par les auteurs du systme mmoire virtuellement partage Midway [15]. Nous allons montrer que ce modle convient bien aux applications vises. Cependant, les protocoles utiliss dans les systmes MVP pour implmenter ce modle de cohrence prsentent des limites lorsque lon essaie de les appliquer directement une architecture de type grille, comme celle dcrite la section 2.1. Ces limites sont lies dune part au passage lchelle des protocoles de cohrence et dautre part la nature dynamique des grilles de calcul. Sur cet exemple, nous esquissons des ides de solutions pour faire face ces limites. Ces solutions permettent dadapter le protocole de cohrence aux architectures grande chelle et dynamiques, que sont les grilles de calcul. Les chapitres suivants dcrivent comment ces solutions ont t gnralises et intgres lors de la conception du service de partage de donnes sur grille J UX M EM (pour Juxtaposed Memory).
tel-00411447, version 1 - 27 Aug 2009
5.1 Le partage de donnes

Dans un premier temps, nous dcrivons notre vision du partage de donnes an de mieux cerner les besoins. Les applications distribues auxquelles nous nous intressons sont les applications de type couplage de codes dcrites la section 2.2. Les processus de ces applications communiquent en partageant des donnes. Ce partage peut tre gr soit de manire explicite, cest--dire par lapplication elle-mme, soit par un systme de partage de donnes extrieur lapplication, comme par exemple les systmes MVP vus la section 4.1 ou les systmes pair--pair vus la section 4.2. Nous ntudions ici que le cas o le partage de donnes se fait via un systme extrieur lapplication. En effet, nous avons montr dans la section 2.3 quil tait prfrable dviter la gestion explicite du partage de donnes par les applications, ceci devenant un facteur limitant lors du dveloppement dapplications distribues grande chelle. Il nous faut commencer par dnir ce quest une donne partage. Donne partage. Une donne partage est un espace mmoire auquel peuvent accder plusieurs processus dune mme application distribue. Cela peut tre une page mmoire, une variable, etc. Nous considrons dans ce manuscrit quune donne partage est une variable partage, accde par diffrents processus dune application distribue. Accs une donne partage. Lors de leur excution, les processus ont besoin daccder aux variables partages. Les accs une variable partage peuvent tre de deux types : en lecture ou en criture. Les lectures correspondent une simple consultation de la valeur de la variable partage. Les critures quant elles entranent une mise jour de la valeur de la variable. Dans une application distribue, les variables partages permettent aux processus de prendre en compte les calculs effectus par les autres processus de lapplication. La perception de ces variables par chacun des processus doit donc rester cohrente. Certaines questions se posent alors concernant la dnition de la cohrence. Autorise-t-on les critures concurrentes ?
5.2 Un exemple de protocole non tolrant aux fautes
57
Quelle est la valeur nalement attribue la donne en cas dcritures concurrentes ? Autorise-t-on les lectures concurrentes une criture ? Quelle est la valeur retourne par une lecture dune donne lorsque quil y a une criture concurrente ? Autorise-t-on les lectures concurrentes ? Les applications qui partagent les donnes doivent savoir quelles garanties sont offertes en terme de cohrence. Par exemple : la valeur retourne par une lecture prend-elle toujours en compte toutes les critures qui ont t effectues auparavant ? Ou encore : un processus est-il seul accder la donne pendant une priode de temps donne ? Souvent, un processus doit pouvoir effectuer une lecture et une criture sur une donne partage de manire atomique. Ce sera le cas notamment si un processus doit incrmenter la valeur dune variable : x := x + 1. Pour rester cohrente, la valeur de la donne ne doit pas tre modie (cest--dire quil ne doit pas y avoir dcriture) entre la lecture (partie droite de laffectation) et lcriture (affectation).
tel-00411447, version 1 - 27 Aug 2009
Un contrat avec les applications. Les garanties de cohrence font lobjet dun contrat entre les applications distribues et le systme qui gre le partage de donnes. Comme dtaill au chapitre 4, ce contrat est appel modle de cohrence. Dans ce chapitre, nous nous concentrons sur un exemple de protocole de cohrence implmentant le modle de cohrence lentre introduit par le systme mmoire virtuellement partage Midway [15]. Ce modle permet doffrir des accs aux donnes performants, il convient particulirement aux applications de calcul scientique.

Les tudes de la cohrence des donnes dans les systmes mmoire virtuellement partage ont montr que les modles de cohrence relche pouvaient tre implments par des protocoles efcaces. En revanche, les garanties de cohrence des donnes sont plus restreintes. Par exemple, les applications accdant aux donnes partages doivent utiliser des oprations de synchronisation comme acquire ou release. Lopration acquire permet de sassurer que les accs la donne qui suivront respecteront les garanties de cohrence. Lopration release permet quant elle de garantir la propagation, ventuellement paresseuse, des mises jours locales dans le systme. Comme dcrit dans la section 4.1.2, ceci est vrai pour des modles comme la cohrence la libration [51], la cohrence lentre [15] et la cohrence de porte [61].
5.2.1
Le modle de cohrence lentre
Nous choisissons le modle de cohrence lentre pour cet exemple. Il prsente la particularit dassocier explicitement un objet de synchronisation spcique chaque donne. Cette particularit permet un gain de performance au niveau du protocole de cohrence. En effet, lorsquun processus entre en section critique1 pour accder une donne, par exemple pour
Une section critique correspond une portion de code manipulant des ressources communes ne devant tre accdes que par un seul processus la fois.
1
58
tel-00411447, version 1 - 27 Aug 2009
lire la valeur de la donne avant de la mettre jour, il doit le faire via lobjet de synchronisation associ cette donne. Ainsi, sur un nud, le protocole de cohrence na garantir que la cohrence des donnes accdes au sein de la section critique associe. Cela permet dviter des mises jour non ncessaires : seuls les processus qui dclarent quils vont accder aux donnes seront concerns. De plus ne seront mises jour que les donnes qui seront effectivement accdes. An dutiliser le modle de cohrence lentre, les programmeurs dapplications doivent respecter deux contraintes. Premirement, chaque donne partage doit tre associe un objet de synchronisation spcique. Deuximement, les accs non-exclusifs ou en lecture seule (cest--dire sans mise jour de la valeur de la donne) doivent tre distingus des accs exclusifs (cest--dire avec mise jour de la valeur de la donne). La distinction entre les deux types daccs est faite en utilisant des primitives diffrentes : acquire_read pour entrer dans une section de code o lon effectue des accs non-exclusifs, et acquire pour entrer dans une section critique comprenant des accs de type exclusif. Ceci permet au protocole de cohrence dautoriser des accs concurrents en lecture : plusieurs processus peuvent accder en lecture, de manire concurrente, une mme donne.
5.2.2
Un protocole bas sur une copie de rfrence
Comme point de dpart pour cet exemple, nous choisissons un protocole implmentant le modle de cohrence lentre. Le protocole choisi est fond sur la notion de copie de rfrence (home based) associe chaque donne partage. Le nud sur lequel lunique copie de rfrence est place (home node) est galement responsable de la gestion de lobjet de synchronisation associ la donne. Lorsquun processus accde la donne, il le dclare en verrouillant lobjet de synchronisation par lintermdiaire dune des primitives de synchronisation : acquire ou acquire_read. Lors de lappel lune de ces primitives, la copie locale, situe sur le mme nud que le processus, est mise jour si ncessaire. De la mme manire, lorsque le processus quitte la section au sein de laquelle il accdait la donne, il relche lobjet de synchronisation par lintermdiaire de la primitive release. Si la donne a t modie par le processus durant la section critique, les mises jour locales sont alors propages la copie de rfrence. Il apparat donc que de nombreuses communications sont ncessaires entre les nuds sur lesquels sexcutent les processus accdant une donne partage et le nud hbergeant la copie de rfrence associe cette donne. La gure 5.1 illustre les communications qui ont lieu entre le nud hbergeant la copie de rfrence et celui sur lequel sexcute un processus accdant la donne, appel aussi nud client.
5.2.3
Fonctionnement du protocole de cohrence
La gure 5.1 illustre le fonctionnement du protocole de cohrence lorsque les interactions sont limites un seul client. Il ny a donc pas, dans cet exemple, de mise en attente au niveau du nud hbergeant la copie de rfrence entre la rception dune requte de synchronisation et lenvoi de lautorisation daccs : lattente du processus client est limite la somme des temps de communications et du temps de traitement de la requte. Cependant, le protocole de cohrence gre aussi laccs une donne partage accde par de multiples processus potentiellement de manire concurrente. Lorsque plusieurs processus accdent

Noeud client Noeud hbergeant la copie de rfrence
59
acquire(d) Attente
requte Envoi de la donne d d
read(d) Accs locaux write(d) release(d) Attente acquittement d Mise jour de d Temps
tel-00411447, version 1 - 27 Aug 2009
Mise jour propage
F IG . 5.1 Communications entre un nud client et un nud hbergeant une copie de rfrence pour une donne d.
de manire concurrente la donne le protocole met en attente certains processus an de garantir la cohrence des accs. Ce comportement est reprsent par lautomate tats de la gure 5.2 qui dcrit le fonctionnement simpli du protocole de cohrence au niveau de la copie de rfrence. Cet automate est compos de trois tats principaux : NO_LOCK, ON_LOCK et ON_LOCK_R. Ils correspondent respectivement aux cas o : 1) lobjet de synchronisation associ la donne est libre ; 2) un processus a acquis lobjet de synchronisation en mode exclusif ; et 3) un ou plusieurs processus ont acquis lobjet de synchronisation en mode non-exclusif. En plus de ces trois tats principaux, le protocole de cohrence gre trois listes : 1) L (pour Lock) qui contient les identiants des processus en attente pour un accs exclusif la donne ; 2) LR (pour Lock Read) qui contient les identiants des processus en attente pour un accs nonexclusif ; et 3) OLR (pour On Lock Read) qui contient les identiants des processus possdant lobjet de synchronisation en mode non-exclusif. On remarque notamment que le protocole ne permet un accs exclusif qu un seul processus client un moment donn. En effet, quand il se trouve dans ltat ON_LOCK, il ne redistribue pas cet accs et il ne sort de cet tat qu la rception dun message de relchement de lobjet de synchronisation. Lautomate tats reprsent par la gure 5.3 dcrit le fonctionnement du protocole de cohrence au niveau du nud client. A ce niveau, le protocole ne gre pas de liste. En effet, pour une donne, le client ne communique quavec la copie de rfrence associe. Il est intressant de remarquer que certains tats (ceux griss sur la gure) sont bloquants pour lapplication. Cela permet par exemple de garantir que le processus possde bien lobjet de synchronisation associ et que la copie locale de la donne soit bien mise jour avant de laisser lapplication accder la donne.
60
NO_LOCK
tel-00411447, version 1 - 27 Aug 2009
release & L & LR vides
release & OLR & L vides acquire acquire_read
release & L non vide
ON_LOCK
release & L vide & LR non vide
ON_LOCK_R
release & OLR vide
release & OLR vide & L non vide acquire_read acquire acquire_read acquire
L, LR et OLR sont des listes
F IG . 5.2 Automate tats reprsentant le protocole de cohrence au niveau de la copie de rfrence.
61
NO_LOCK acquire acquire_read
tel-00411447, version 1 - 27 Aug 2009
ATTENTE LOCK
acquitement reu
ATTENTE LOCK_R
ATTENTE acquitement reu UNLOCK acquitement reu
release ON_LOCK
release
ON_LOCK_R
F IG . 5.3 Automate tats reprsentant le protocole de cohrence au niveau du nud client. Les tats non griss ne bloquent pas lapplication alors que les tats griss correspondent des primitives synchrones.
62
Le protocole dcrit ici nest pas adapt une architecture de type grille : 1) il est centralis autour du nud hbergeant la copie de rfrence et ne prend pas en compte la topologie rseau des grilles ; 2) il ne prend pas en compte la possibilit dapparition de fautes. Les sections suivantes dtaillent ces limites et proposent des solutions pour y faire face.
5.3 Un protocole de cohrence hirarchique

5.3.1 Limites dun protocole plat
Comme lillustrent les automates reprsents par les gures 5.3 et 5.2, de multiples clients sont susceptibles daccder une mme donne partage. Les diffrents processus accdant une mme donne partage peuvent tre situs dans des grappes diffrentes. Si lon se rfre larchitecture de grille considre comme une fdration de grappes prsente dans la section 2.1, les liens intergrappe prsentent des latences rseau bien plus leves que les liens intragrappe. Il en rsulte que les processus clients qui sexcutent sur un nud situ dans une grappe diffrente de celle o se situe le nud hbergeant la copie de rfrence bncieront daccs bien moins performants que ceux sexcutant sur des nuds situs dans la mme grappe. Le point central quest la copie de rfrence constitue donc une limite lefcacit du protocole. La gure 5.4 illustre les communications entre deux processus clients, situs dans des grappes diffrentes, accdant une donne partage. Le protocole ne fait aucune diffrence entre lutilisation des liens intragrappe entre le client A et le nud hbergeant la copie de rfrence et les liens intergrappe entre le client B et le nud hbergeant la copie de rfrence. De plus, comme le montre lautomate 5.3, certains tats du protocole de cohrence sont bloquants. Cela implique que la dgradation de performance concernera lapplication distribue toute entire, y compris les processus sexcutant sur des nuds situs dans la mme grappe que la copie de rfrence, comme illustr par la gure 5.4.
tel-00411447, version 1 - 27 Aug 2009
5.3.2
Solution : un protocole hirarchique
De manire amliorer lefcacit du protocole de cohrence, une approche consiste minimiser les communications entre les grappes. Cette ide a t utilise dans certains systmes mmoire virtuellement partage et elle a conduit la conception de protocoles de cohrence hirarchiques. Dans Clustered Lazy Release Consistency (CLRC [6]), des caches locaux sont crs dans chaque grappe an doptimiser la localit des accs conscutifs la donne. Les auteurs de [5] proposent dappliquer une approche hirarchique la gestion distribue dobjets de synchronisation en rordonnanant les requtes de verrouillage (par exemple acquire) : les requtes provenant de la grappe courante sont servies avant les requtes distantes. En nous inspirant de ces deux contributions, nous construisons une version hirarchique du protocole de cohrence dcrit la section 5.5. Cette version, illustre par la gure 5.5, est inspire par le protocole de synchronisation hirarchique dcrit dans [5]. Lide est dutiliser une hirarchie deux niveaux de copies de rfrence. Au sein de chaque grappe dans laquelle la donne est accde, une copie de rfrence locale est place sur un nud responsable des accs locaux, cest--dire provenant dun nud de la mme grappe. Une copie de rfrence globale est responsable des accs effectus par les copies de rfrences locales.
5.3 Un protocole de cohrence hirarchique
63
Lien WAN
Lien SAN Client B Client A Copie de rfrence
Grappe A
Grappe B
tel-00411447, version 1 - 27 Aug 2009
Client A
Copie de rfrence requte Envoi de la donne Mise en attente (A) d
Client B acquire(d)
acquire(d)
requte
Attente
read(d) write(d) Attente d release(d) Accs locaux
Temps
d Accs locaux read(d)
Mise jour de d Envoi de la donne
Attente
ack Mise jour propage
Grappe A
Grappe B
F IG . 5.4 Fonctionnement du protocole de cohrence lentre pour une donne accde dans des grappes diffrentes.
64
Lien WAN
Copie de rfrence globale
Lien WAN
Lien SAN Copie de rfrence locale B Client B
Client A
Copie de rfrence locale A
Grappe A
Grappe B
F IG . 5.5 Version hirarchique du protocole de cohrence.
tel-00411447, version 1 - 27 Aug 2009
Lorsquun client accde la donne, il doit dabord acqurir lobjet de synchronisation correspondant auprs du nud hbergeant la copie de rfrence locale. Sil possde lobjet de synchronisation, il peut autoriser laccs. Si ce nest pas le cas, une demande dacquisition est envoye au nud hbergeant la copie de rfrence globale. La copie de rfrence globale ne sert donc que les accs des copies de rfrence locales qui distribuent ensuite les accs au sein de leur grappe. Cependant, an de minimiser les communications entre les grappes, plus forte latence, les copies de rfrences locales servent en priorit les demandes daccs des clients de leur grappe par rapport aux requtes distantes provenant des autres copies de rfrence locales et transmises via la copie de rfrence globale. Cette rgle, a priori, peut aboutir une situation de famine ; aussi une limite est-elle impose sur le nombre maximal de redistributions locales de lobjet de synchronisation qui peuvent tre effectues par le nud hbergeant une copie de rfrence locale. Cela permet dassurer que les requtes distantes seront ultimement satisfaites. Lautomate du protocole de cohrence au niveau des copies de rfrence locales est une combinaison des deux automates de la version non hirarchique du protocole de cohrence. Les copies de rfrence locales jouent en effet le rle de copie de rfrence vis--vis des clients locaux, et le rle de client vis--vis de la copie de rfrence globale. Lautomate de la copie de rfrence globale est identique celui de la copie de rfrence unique prsent lors de la description de la version non hirarchique du protocole de cohrence (gure 5.2). Cela est d au fait que la copie de rfrence globale de la version hirarchique joue, vis--vis des copies de rfrence locales, le mme rle que la copie de rfrence du protocole en version non hirarchique jouait vis--vis des clients. De mme, au niveau du client, lautomate est identique celui de la version non hirarchique (voir gure 5.3). En effet, du point de vue du client, la hirarchisation du protocole est transparente : tout se passe comme si la copie de rfrence locale, laquelle il accde, tait la seule copie de rfrence du systme. Le nouveau rle cr par la hirarchisation du protocole de cohrence est celui de copie de rfrence locale, qui, en jouant le rle dintermdiaire, permet de limiter lutilisation des liens rseau forte latence entre les grappes et ainsi damliorer les performances globales des accs la donne partage. La copie de rfrence globale peut tre localise au sein de lune des grappes contenant des nuds accdant la donne, ou dans une grappe tierce. La question de la localisation de la copie globale est discute plus en
5.4 Un protocole de cohrence tolrant aux fautes dtails dans le chapitre 7.
65
Cette version du protocole de cohrence est donc mieux adapte aux grilles de calcul. Cependant, nous avons vu la section 2.1 que la possibilit doccurrence de fautes dans les grilles de calcul nest pas ngligeable. Dans la section suivante, nous montrons comment il est possible de rendre le protocole de cohrence tolrant aux fautes.
5.4 Un protocole de cohrence tolrant aux fautes

5.4.1 Ncessit de tolrer les fautes
tel-00411447, version 1 - 27 Aug 2009
Le protocole de cohrence lentre que nous avons dcrit la section 5.2 a t mis au point pour des systmes mmoire virtuellement partage. Ces systmes sexcutant gnralement sur des grappes de calculateurs ddis de taille restreinte (quelques dizaines, voire quelques centaines de nuds), les fautes y sont considres comme exceptionnelles. De ce fait, lors de la conception de ce protocole, le nud hbergeant la copie de rfrence peut tre considr comme stable (cest--dire correct ou non fautif ). Or nous visons lchelle de la grille et la gestion de nombreuses donnes partages, ce qui implique que de nombreux nuds (des milliers) soient impliqus dans la gestion des donnes. cette chelle, comme expliqu dans la section 2.1, les fautes ne peuvent plus tre considres comme exceptionnelles : elle sont partie intgrante des proprits de la grille. Il nest donc plus possible de considrer quun nud hbergeant une copie de rfrence pour une donne soit stable. En effet, tant donn le nombre de donnes que nous allons grer au sein de la grille, le nombre de copies de rfrence sera sufsamment important pour que lapparition dune faute sur un des nuds jouant ce rle pour une donne particulire soit un vnement non ngligeable. Nous reprenons ici le protocole non hirarchique et non tolrant aux fautes dcrit la section 5.2. Le rle de copie de rfrence peut tre considr comme critique car chaque donne partage se voit associer une seule et unique copie de rfrence. Si le nud hbergeant cette copie de rfrence est fautif, alors la donne associe est perdue et les clients ne peuvent plus y accder. Assurer la persistance de la copie de rfrence dans le systme permet dassurer la persistance de la donne en cas de fautes. Modle de faute. Nous nous intressons aux deux types de faute qui doivent tre pris en compte dans les environnements de type grille : 1) les pannes franches (ou crashs) 2 ; et 2) les pertes de messages (canaux de communication non ables). Ces types de faute sont reprsentatifs dans le cas des grilles de calcul comme expliqu dans la section 3.1.1. Modle de temps. Nous considrons que des bornes sur les temps de communications et les temps de calculs existent, mais ne sont pas connues. Nos algorithmes sont donc conus pour un environnement partiellement asynchrone et utilisent des informations provenant dun service de dtection de fautes. Un tel service fournit sur chaque nud une liste de nuds suspects dtre fautifs. Cette hypothse dasynchronisme est classique dans les systmes distribus tolrants aux fautes. Elle est galement raliste dans le cas des grilles de calcul (voir section 2.1).
2
Les nuds qui rejoignent le systme aprs une faute sont traits comme de nouveaux nuds
66
5.4.2
Utilisation de techniques de rplication
An quune copie de rfrence puisse rester disponible en prsence de pannes franches de nuds, nous nous appuyons sur les solutions bases sur la rplication prsentes la section 3.3. Rpliquer la copie de rfrence associe une donne permet dassurer sa persistance en prsence de fautes. Le nombre de fautes (de type panne franche) tolres dpend de : 1) la technique de rplication employe ; et 2) du degr de rplication (le nombre de copies). An de tolrer les fautes nous proposons donc de remplacer la copie de rfrence unique par un groupe de copies de rfrences. Nous allons donc rpliquer, sur diffrents nuds du groupe, non seulement la donne mais galement le protocole de cohrence (lautomate tats). An que les automates et la valeur de la donne voluent de la mme manire sur chacun des automates, les algorithmes utiliss doivent assurer la diffusion atomique des messages au sein du groupe. Ces mcanismes sont coteux mais permettent doffrir de bonnes garanties de tolrance aux fautes. Larchitecture que nous proposons au chapitre suivant permet de choisir le type de rplication et donc le compromis cot/garanties de la tolrance aux fautes. Pour raliser la rplication de la copie de rfrence dcrite ci-dessus, nous utilisons des concepts tudis dans le cadre des systmes distribus tolrants aux fautes. Protocole de composition de groupe. Un protocole de composition de groupe (group membership en anglais) [37] permet de grer un ensemble (un groupe) de nuds ayant un intrt commun. Chaque nud appartenant un groupe maintient jour la liste de membres de ce groupe. La composition de ces listes volue quand de nouveaux nuds joignent ou quittent le groupe, lors dune panne franche par exemple. Les protocoles de composition de groupe ont pour objectif de maintenir la cohrence de ces diffrentes listes en les synchronisant. Entre deux synchronisations, les mmes ensembles de messages doivent tre pris en compte par chacun des membres du groupe. Dans notre cas, nous utilisons ce type de protocole pour grer les groupes de nuds hbergeant les copies de rfrence des donnes. Diffusion atomique. Dans la version tolrante aux fautes du protocole de cohrence, la copie de rfrence associe une donne est reprsente par un groupe de nuds. tant donn que des nuds peuvent tre fautifs, nous utilisons un mcanisme de rplication pessimiste an dassurer quune copie jour reste disponible dans le systme. Chaque mise jour entrane donc une mise jour de tous les membres du groupe. An de raliser cela, tous les messages envoys un groupe doivent tre pris en compte dans le mme ordre par chacun des membres du groupe. Les membres du groupe saccordent sur lordre de distribution des messages en utilisant un protocole classique de consensus, comme celui dcrit dans [32]. Protocole de consensus. Un protocole de consensus permet un groupe de nuds potentiellement fautifs de saccorder sur une valeur commune : chaque nud propose une valeur et le protocole de consensus assure que : 1) ultimement, tous les nuds non fautifs dciderons dune valeur de manire dterministe ; 2) la valeur dcide est lune des valeurs propose ; et 3) la valeur dcide est la mme pour tous les nuds non fautifs. Dans notre cas, la dcision porte sur lordre dans lequel les messages doivent tre pris en compte. Le problme du consensus dans les systmes asynchrones peut tre
tel-00411447, version 1 - 27 Aug 2009
5.4 Un protocole de cohrence tolrant aux fautes

join/leave/getview/send/receive Composition de groupe multicast/receive Diffusion atomique
67
propose/decide Consensus
get suspect list
tel-00411447, version 1 - 27 Aug 2009
Dtecteurs de fautes send/receive Canaux de communication non fiables
F IG . 5.6 Architecture en couches pour limplmentation du protocole de composition et de communication de groupe.
rsolu grce des dtecteurs de fautes non ables [32], comme ceux prsents dans la section 3.2.
Pour raliser une version tolrante aux fautes du protocole de cohrence prsent la section 5.2, nous combinons des blocs de base implmentant les concepts dcrits ci-dessus. La combinaison en couches illustre par la gure 5.6 est inspire par [82]. La mise en uvre de larchitecture illustre par la gure 5.6 pour rpliquer la copie de rfrence associe une donne permet de supporter n1 fautes simultanes, o n est le nombre de nuds sur 2 lesquels la copie de rfrence est rplique. Cette limite est impose par notre mise en uvre du protocole de consensus propos par Chandra et Toueg [32]. Notons que le protocole de cohrence reste inchang aussi bien pour les clients que pour la copie de rfrence. Les clients utilisent une couche de communication de groupe pour communiquer avec la copie de rfrence rplique, de la mme manire quils le faisaient lorsque cette dernire ntait hberge que par un seul nud. Le protocole de communication de groupe permet chaque nud hbergeant un rplicat de la copie de rfrence de sabstraire de la rplication : chacun dentre eux sexcute comme sil hbergeait la seule copie de rfrence. Les automates du protocole de cohrence sont donc les mmes que dans la version non tolrante aux fautes prsente la section 5.2 (gures 5.2 et 5.3).
68
5.5 Vers un protocole hirarchique tolrant aux fautes

La section 5.3 a montr comment hirarchiser le protocole de cohrence prsent la section 5.2 an que celui-ci prenne en compte la topologie rseau des grilles de calcul pour amliorer les performances des accs aux donnes partages. Ensuite, la section 5.4 explique comment, en utilisant des concepts connus des systmes distribus tolrants aux fautes, il est possible de rendre ce protocole tolrant aux fautes en rpliquant les copies de rfrence. Ltape nale est de coupler les deux solutions prsentes dans les deux prcdentes sections an dobtenir un protocole de cohrence la fois hirarchique et tolrant aux fautes. Cela permet de sabstraire des limites du protocole de cohrence dorigine : 1) les problmes lis au passage lchelle, et 2) le manque de support pour la tolrance aux fautes. Une premire ide pour combiner ces deux solutions consiste utiliser les mcanismes de rplication dcrits la section 5.4 an de rendre tolrante aux fautes la copie de rfrence globale du protocole de cohrence hirarchique dcrit la section 5.3. Cependant, la faute dun nud hbergeant une copie de rfrence locale (susceptible de possder lobjet de synchronisation et la dernire version de la donne) doit galement tre tolre. Il convient donc dutiliser les mcanismes de rplication pour chacune des copies de rfrence (les copies locales et la copie globale). Les mcanismes de tolrance aux fautes (comme la rplication) sont coteux. An de limiter ce cot, il est important de limiter le nombre de nuds que ces mcanismes font intervenir et de prendre en compte la nature des liens rseau utiliss (intergrappe ou intragrappe). Aussi, le couplage entre le protocole de cohrence et les mcanismes de tolrance aux fautes est un problme non trivial. Cette difcult est encore augmente si lon souhaite concevoir une architecture permettant la mise en place de plusieurs protocoles de cohrence et de plusieurs mcanismes de tolrance aux fautes. Le chapitre suivant dcrit notre architecture logicielle permettant une gestion conjointe de la cohrence des donnes et de la tolrance aux fautes.
tel-00411447, version 1 - 27 Aug 2009
69
Chapitre
6
70 70 72 74 75 75 79 80 80 81 82
Une approche conjointe

tel-00411447, version 1 - 27 Aug 2009
Sommaire
6.1 Cadre : le service de partage de donnes J UX M EM . . . . . . . . . . . . . . 6.1.1 Notion de service de partage de donnes pour la grille . . . . . . . . 6.1.2 Architecture gnrale . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1.3 Le noyau JuxMem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Proposition : une architecture en couches . . . . . . . . . . . . . . . . . . . . 6.2.1 Un double besoin de rplication . . . . . . . . . . . . . . . . . . . . . 6.2.2 La couche de communication de groupe . . . . . . . . . . . . . . . . . 6.2.3 La couche dadaptation aux fautes . . . . . . . . . . . . . . . . . . . . 6.2.4 Les protocoles de cohrence . . . . . . . . . . . . . . . . . . . . . . . . Interactions entre le protocole de cohrence et les mcanismes de tolrance aux fautes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Vers une approche gnrique . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2
6.3 6.4
Dans les chapitres 3 et 4, nous avons vu que plusieurs approches ont t proposes sparment, aussi bien pour la gestion de la tolrance aux fautes que pour la gestion de la cohrence des donnes. Dans le chapitre 5, nous avons montr sur un exemple des solutions pour adapter certaines de ces approches la grille. Dans le cadre dun service de partage de donnes pour les grilles de calcul, il est ncessaire doffrir un support pour la tolrance aux fautes et pour la gestion de la cohrence des donnes. Ce chapitre dcrit une architecture dont le but est de permettre une gestion conjointe de la tolrance aux fautes et de la cohrence des donnes au sein dun service de partage de donnes pour la grille. Avant de dtailler notre solution, nous dcrivons le cadre dans lequel sinscrit notre contribution : le service de partage de donnes J UX M EM. Notre approche pour faire face aux problmes lis au passage lchelle sera aborde dans le chapitre suivant.
70
Chapitre 6 Une approche conjointe
6.1 Cadre : le service de partage de donnes J UX M EM

Comme nous lavons vu la section 2.2, les applications scientiques utilisent des quantits de donnes distribues de plus en plus grandes. La gestion de la localisation, du transfert et de la cohrence de ces donnes est devenue un facteur limitant lors de la conception de telles applications. Or il nexiste actuellement aucun systme permettant un partage de donnes modiables offrant un accs transparent et des garanties de cohrence pour les grilles de calculs. Ces besoins ainsi que les lacunes des mcanismes de partage de donnes pour les grilles existants sont dtaills dans la section 2.3. Une nouvelle approche consiste externaliser la gestion des donnes partages par les applications sexcutant sur la grille. Le concept de service de partage de donnes pour la grille a t introduit par [4], la section suivante en donne notre vision.
6.1.1
Notion de service de partage de donnes pour la grille
tel-00411447, version 1 - 27 Aug 2009
Au vu des problmes soulevs par la section 2.3, il apparat que les proprits recherches pour le partage de donnes pour les grilles de calcul sont : 1) la persistance des donnes, 2) la cohrence des donnes, et 3) la transparence daccs aux donnes. Persistance des donnes. Les donnes partages entre diffrentes entits doivent tre persistantes. En effet, dans un systme distribu, les oprations peuvent tre asynchrones. Cela implique quune donne utilise par une entit dune application distribue pourra tre utilise nouveau, plus tard, par une autre entit. La donne, ainsi que les ventuelles modications qui lui ont t apportes, doit rester disponible au cours du temps, jusqu ce quelle soit explicitement supprime. Or, dans un environnement de type grille, les occurrences de fautes sont courantes. Le service de partage de donnes doit donc mettre en place des mcanismes de tolrance aux fautes an dassurer que les donnes ne seront pas perdues en cas de fautes. Considrons lexemple de DIET (pour Distributed Interactive Engineering Toolbox [28]) qui est une plate-forme de calcul dveloppe lENS Lyon au sein du projet de recherche GRAAL. Une donne (une matrice par exemple) utilise ou produite par un calcul peut tre utilise nouveau par des calculs qui sexcuteront plus tard. Entre temps, la donne doit persister (rester disponible) dans le systme an de permettre aux calculs ultrieurs utilisant cette donne de sexcuter correctement. Si le service de partage de donnes noffre pas cette proprit, cest aux clients que revient le rle de conserver les donnes, de se les transmettre et donc de maintenir la cohrence entre les diffrentes copies ainsi cres. Cohrence de donnes. Une donne partage va, par dnition, tre accde par de multiples entits dune application distribue et ce la fois en lecture et en criture (les critures peuvent notamment tre concurrentes). Un service de partage de donnes pour la grille doit prendre en compte cette possibilit et mettre en uvre des protocoles de cohrence implmentant des modles de cohrence, limage de ce qui a t fait dans les systmes mmoire virtuellement partage (voir section 4.1). Cela signie que le service doit assurer la cohrence des diffrentes copies de chaque donne partage par les clients (ordonner et propager les mises jour, mettre en attente les processus lorsque cela est ncessaire, etc.).
71
Accs transparent. Un des facteurs limitant dans le dveloppement dapplications scientiques distribues lchelle de la grille est la gestion explicite de la localisation et du transfert des donnes (et par consquence, de leur cohrence). limage de ce qui existe dans les systmes mmoire virtuellement partage et dans les systmes pair-pair (P2P pour langlais peer-to-peer), un service de partage de donne pour la grille se doit doffrir un accs transparent aux donnes, par exemple en associant chaque donne un identiant global unique. Cet identiant peut tre utilis pour accder la donne par chacune des entits de lapplication sans avoir connatre la localisation de la donne, ni le mode de transfert utilis. la frontire entre deux mondes. Larchitecture physique vise par notre service de partage de donnes est celle des grilles de calcul et plus particulirement celle des fdrations de grappes. Nous visons donc une chelle de lordre de quelques milliers de nuds regroups en grappes interconnectes. Il est intressant de noter que cette architecture se situe la frontire entre deux mondes : celui des systmes mmoire virtuellement partage (MVP) dune part et celui des systmes pair--pair dautre part. Ceci vaut en terme dchelle, de volatilit, de degr de conance et dhomognit, comme rsum sur le tableau 6.1. En effet, lchelle que nous visons se situe entre les chelles gnralement vises par ces deux mondes. De mme le degr de volatilit, considr comme nul dans les MVP et comme trs lev dans les systmes pair--pair, est dans notre cas intermdiaire. Les nuds sur lesquels sexcute notre service font partie de grappes de calculateurs ddis et sont moins volatiles que ceux considrs dans les systmes pair--pair. En revanche, lchelle vise implique tout de mme un certain degr de volatilit, comme expliqu dans la section 3.1. Le degr de conance (et par consquence le niveau de contrle des ressources) se situe galement mi-chemin : une fdration de grappe correspond gnralement la mise en commun de ressources entre diffrentes institutions qui se font conance. Les principales diffrences avec les systmes mmoire virtuellement partage sont : 1) la prsence de fautes, et 2) la structure hirarchique du rseau. Ceci implique quil nest plus possible de considrer des nuds comme tant stables ni de supposer lexistence dune connaissance globale de la plate-forme. La principale diffrence avec les systmes pair--pair classiques de partage de chiers en lecture seule est que les donnes gres par notre service de partage sont modiables. Ce dernier point induit une grande complexit. En effet, il ne sagit plus seulement de stocker de multiples copies en lecture seule puis de pouvoir en localiser au moins une. Il devient ncessaire de grer la cohrence de ces donnes, cest--dire de toutes les copies de chaque donne. Nous ne cherchons pas concevoir un systme pair--pair pour la grille, ni un systme MVP passant lchelle. Notre service de partage de donnes se situe au niveau intermdiaire. Il sagit dun service de grille sinspirant : 1. des MVP pour leurs modles et protocoles de cohrence de donnes ; 2. des systmes pair--pair pour leurs proprits de passage lchelle, notamment en terme de support de la volatilit et de localisation des ressources. Dans la conception de notre service de partage de donnes pour la grille, nous avons exploit laspect hirarchique des fdrations de grappes an de faire le lien entre les deux mondes. Nous nous sommes galement appuys sur des rsultats thoriques provenant de
tel-00411447, version 1 - 27 Aug 2009
72 MVP chelle (nombre de nuds) Degr de volatilit Contrle des ressources et Degr de conance Homognit des ressources Type de donnes gres Applications typiques 101 102
Chapitre 6 Une approche conjointe Service de donnes pour la grille 103 Moyen Moyen P2P 104 106
Nul Fort
Fort Nul
Homognes (grappes) Modiables Calcul numrique
Hirarchique (fdrations de grappes) Modiables Calcul numrique et stockage de donnes
Htrognes (Internet) Non modiables Partage et stockage de chiers
tel-00411447, version 1 - 27 Aug 2009
TAB . 6.1 Caractristiques dun service de partage de donnes inspir des MVP et du P2P.
la recherche sur les systmes distribus tolrants aux fautes, notamment pour la conception de mcanismes de rplications.
6.1.2
Architecture gnrale
Larchitecture gnrale de notre service de partage de donnes pour la grille J UX M EM a t conue en collaboration avec Mathieu Jan [64], dans le cadre de nos travaux de doctorat au sein de lquipe PARIS de lIRISA. Une architecture hirarchique. J UX M EM utilise la notion de groupes de pairs an de prendre en compte larchitecture physique sous-jacente. Ceci est illustr par la gure 6.1. Larchitecture vise tant de type fdration de grappes, les pairs localiss dans une mme grappe sont regroups dans un groupe cluster. Il y a par consquent autant de groupes cluster que de grappes utilises au sein de la fdration. Lensemble des groupes cluster forme un groupe de plus haut niveau appel le groupe J UX M EM. Ce groupe rassemble tous les pairs participant au service. J UX M EM prsente donc une architecture hirarchique deux niveaux : le niveau global et le niveau local (aussi appel niveau grappe). Rles des pairs J UX M EM. Les pairs, entits constituantes des groupes, peuvent avoir jouer diffrents rles. Nous en distinguons trois : 1) les pairs gestionnaires qui jouent notamment le rle de pairs de rendez-vous du rseau logique pair--pair bas sur JXTA [115] ; 2) les pairs fournisseurs sur lesquels les copies des donnes gres par le service vont effectivement tre stockes ; et 3) les pairs clients qui ont la capacit daccder aux donnes. Cest exclusivement avec ces derniers que les applications utilisant J UX M EM interagissent. tant

Groupe JuxMem
73
Groupe data Groupe cluster A
Groupe cluster C
Groupe cluster B
Rseau virtuel Reseau physique
Grappe de machines A
Grappe de machines C
tel-00411447, version 1 - 27 Aug 2009
Client Gestionnaire Fournisseur Machine Grappe de machines B
F IG . 6.1 J UX M EM : une proposition darchitecture pour un service de partage de donnes pour la grille.
dans un monde pair--pair, un pair peut jouer un ou plusieurs rles simultanment. Par exemple, un pair peut jouer la fois le rle de gestionnaire et de fournisseur de donnes. Par la suite, des ns de clart, nous ne considrerons que les cas o chaque pair ne joue quun seul rle ; de plus nous considrons que chaque nud physique hberge un seul pair1 . Les groupes data. Nous allons nous intresser plus particulirement aux pairs de type fournisseur qui seront les membres des groupes data. Un groupe data est associ chaque donne gre par J UX M EM. Il est constitu de lensemble des pairs fournisseurs possdant une copie de cette mme donne. Comme lillustre la gure 6.1, un groupe data peut stendre sur plusieurs groupes cluster. Ces groupes ne sont pas des groupes au mme sens que les groupes cluster ou le groupe J UX M EM. En effet, les garanties requises pour la gestion de la cohrence des copies dune mme donne ncessite une gestion spcique des groupes data pour assurer justement la gestion conjointe de la tolrance aux fautes et de la cohrence des donnes au sein de ces groupes. La description dtaille de la gestion de ces groupes constitue donc le coeur de ce manuscrit. Principe dutilisation de J UX M EM. Les groupes data jouent un rle important dans lutilisation de J UX M EM. Les applications utilisant J UX M EM sont lies un client J UX M EM : chaque processus applicatif accdant des donnes partages interagit avec un pair client J UX M EM sexcutant sur le mme nud. Lorsquun espace de stockage est allou dans J UX M EM, un
1
Dans la ralit un nud peut hberger plusieurs pairs jouant chacun plusieurs rles.
74
ensemble de pairs fournisseurs est slectionn an de former un nouveau groupe data. Par la suite, les accs (en lecture ou criture) la donne prsente dans lespace de stockage impliquent des interactions entre le pair client et le groupe de pairs fournisseurs (cest--dire le groupe data). La gestion des groupes data ainsi que les interactions entre ces groupes et les pairs clients sont dtailles par la suite.
6.1.3
Le noyau JuxMem
Dans la section suivante, nous allons dcrire notre architecture logicielle pour la gestion des groupe data. Celle-ci sappuie sur le noyau du systme J UX M EM appel juk. La ralisation de juk a t effectue dans le cadre du doctorat de Mathieu Jan [64]. Cest le noyau qui gre notamment le groupe J UX M EM et les groupes cluster. Il est galement responsable des interactions avec les applications.
tel-00411447, version 1 - 27 Aug 2009
Ce noyau sert de base aux mcanismes de tolrance aux fautes et de cohrence de donnes. Il offre aux couches suprieures la notion de pairs identis par des identiants uniques2 , des mcanismes de communication, de stockage et de publication/recherche. Ces diffrents mcanismes sappuient sur JXTA [115]. Au niveau des couches suprieures dcrites dans ce manuscrit, ce noyau permet de sabstraire compltement de JXTA. Son interface est dtaille ci-dessous. Communication. Le noyau permet denvoyer des messages dun pair un autre selon le modle point--point. An de pouvoir recevoir des messages, les algorithmes doivent enregistrer auprs du noyau une fonction et une tiquette associe (simple chane de caractres). La fonction sera appele lors de larrive dun message tiquet avec ltiquette associe. Pour envoyer un message, il faut fournir lidentiant du pair destinataire ainsi que ltiquette (send(identiant, message, etiquette)). La couche de communication gre la localisation du pair destinataire. Il est important de noter que cette couche est asynchrone et non-able : la mthode denvoi de message rendra la main (non bloquante) sans garantir que le message envoy sera reu par le pair destinataire. Nous faisons cependant lhypothse quelle est quitable (voir section 3.1) : un message r-mis sufsamment souvent nira par tre reu. Stockage. Cest galement le noyau qui gre le stockage physique sur le nud (en mmoire ou sur disque) en offrant des primitives comme malloc pour allouer de lespace sur le nud, data_to_message pour placer la copie de la donne stocke sur le nud dans un message, data_from_message pour stocker sur le nud une donne reue dans le corps dun message. Les algorithmes de rplication ainsi que ceux de cohrence nauront donc pas se proccuper du stockage effectif de la donne. Publication/recherche. Les fonctionnalits de publication/recherche offertes permettent de publier des annonces et den rechercher. La publication/recherche seffectue au sein dun groupe. Il est ainsi possible deffectuer une publication ou une recherche soit au niveau dun groupe cluster (locale), soit au niveau du groupe juxmem (globale). Ceci peut tre par exemple exploit pour retrouver les copies dune donne. Cest galement
Lunicit des identiants nest pas totalement garantie. Une fonction de hachage gnre des identiants qui ont une trs grande probabilit dtre uniques. Par la suite, nous faisons lhypothse habituelle que la proprit dunicit des identiants est vrie.
2
6.2 Proposition : une architecture en couches
75
cette possibilit de recherche locale ou globale qui nous permet de prendre en compte la hirarchie physique sous-jacente. Recherche de pairs fournisseurs. Le noyau offre galement un mcanisme de recherche particulier qui est utilis lors de lallocation. Chaque pair de type fournisseur, lors de son initialisation, publie la quantit de mmoire disponible quil offre. Il est par la suite possible de rechercher des pairs J UX M EM fournisseurs pouvant allouer une quantit de mmoire donne. Cette recherche peut tre paramtre plus nement : il est en effet possible de stipuler que lon souhaite trouver des pairs fournisseurs prsents dans le groupe cluster dans lequel se trouve le pair (gnralement de type client) ayant lanc la requte dallocation, ou, au contraire, situs dans dautres groupes cluster. Il est galement possible de rechercher des fournisseurs situs dans un nombre donn de groupes cluster distincts. Le noyau neffectue pas les requtes dallocation proprement dites, il cherche des identiants de pairs fournisseurs satisfaisant la requte et retourne la liste des identiants trouvs. Cest le protocole de cohrence ct client qui, lors de son initialisation, envoie les requtes dallocation aux pairs fournisseurs retourns an de crer un nouveau groupe data. Interface avec les applications. Le noyau J UX M EM est galement responsable des interactions avec les applications utilisant le service de partage de donnes. Cest lui qui appelle les primitives des protocoles de cohrence lorsque lapplication accde la donne. La gure 6.2 illustre larchitecture logicielle de J UX M EM. Notre contribution, dcrite en dtail dans les sections suivantes, se situe entre la partie du noyau responsable des interactions avec les applications et celle offrant les primitives de base dcrites ci-dessus.
tel-00411447, version 1 - 27 Aug 2009

Au-dessus du noyau J UX M EM prsent ci-dessus, nous proposons une architecture en couches dont le rle est dassurer la persistance des donnes en prsence de fautes ainsi que leur cohrence. Cette architecture est prsente au niveau des pairs de type fournisseur et au niveau des pairs de type client. En effet, le rle de larchitecture logicielle prsente ci-dessous est la gestion des groupes data et les interactions entre les groupes data et les pairs client J UX M EM. Lensemble des couches est conu pour grer une donne partage, il peut donc tre instanci sur un pair fournisseur autant de fois que le nombre de donnes diffrentes stockes par ce dernier (le nombre de groupes data auxquels il appartient). De mme, sur les pairs de type client, ces couches sont instancies autant de fois que le nombre de donnes partages auxquelles accde le client.
6.2.1
Un double besoin de rplication
Notre architecture doit grer la fois la tolrance aux fautes et la cohrence des donnes. Pour la tolrance aux fautes, la rplication permet damliorer la disponibilit des donnes. Dans le cas des protocoles de cohrence, la rplication est employe an damliorer la localit des donnes.
76
Interface JuxMem
tel-00411447, version 1 - 27 Aug 2009
Notre contribution : Gestion de la cohrence et de la tolrance aux fautes
Communications
Stockage
Publication Recherche
Noyau JuxMem bas niveau
F IG . 6.2 Le noyau du systme J UX M EM et notre contribution.
77
Interface JuxMem
Protocole de cohrence
tel-00411447, version 1 - 27 Aug 2009
Couche de jonction Groupe autoorganisant (SOG) Couche dadaptation aux fautes
Couche de communication de groupe
Communications
Stockage
Publication Recherche
Noyau JuxMem bas niveau
F IG . 6.3 Une architecture en couches pour la gestion conjointe de la tolrance aux fautes et la cohrence des donnes.
78
La rplication employe pour amliorer la disponibilit. De nombreux mcanismes de tolrance aux fautes utilisent la rplication [98] pour supporter les dfaillances des nuds. Ainsi malgr la dfaillance dun des nuds hbergeant une copie dune donne, cette donne reste disponible grce lexistence des autres copies. Plusieurs techniques de rplication ont t tudies et sont dcrites en dtail en section 3.3. Ces techniques prsentent de diffrents compromis entre lefcacit et les garanties. La rplication employe pour amliorer la localit. Dans le cadre de la mise en uvre de protocoles de cohrence, la rplication des donnes est utilise pour amliorer les performances des accs aux donnes. De nombreux protocoles de cohrence utilisent la rplication an de pouvoir placer des copies des donnes proches des processus qui y accdent (voir chapitre 4). Elle permet plusieurs processus de lire une mme donne concurremment en nutilisant que des accs locaux. Cependant, lors de la mise jour dune donne, le protocole doit actualiser ou invalider les autres copies de la donne prsentes dans le systme de manire maintenir la cohrence des diffrentes copies. Dans les systmes distribus, la rplication peut tre employe la fois des ns de localit et de disponibilit. La question est de faire ou non la distinction entre les deux types de copies : celles cres pour amliorer la disponibilit et celles cres pour amliorer la localit. Il existe donc deux grandes familles de solutions : 1) une gestion dcouple, et 2) une gestion intgre. Une gestion dcouple. Il sagit ici de faire une distinction stricte entre les copies cres pour la tolrance aux fautes et celles cres par le protocole de cohrence. Cette sparation permet un dveloppement et une maintenance plus aiss mais sous-utilise le potentiel : le protocole de cohrence na pas connaissance des copies cres pour la tolrance aux fautes, ce qui implique quil ne peut pas les exploiter et rciproquement. En revanche, avec cette solution, il est possible dajouter un protocole de cohrence sans avoir se proccuper des problmes lis la tolrance aux fautes. De mme, de nouveaux mcanismes de rplication des ns de tolrance aux fautes peuvent tre mis en place sans avoir tenir compte du protocole de cohrence. Une gestion intgre. Cette approche consiste grer au mme niveau les problmes de la disponibilit et de la cohrence des donnes, aucune distinction nest faite entre les diffrentes copies. Un seul ensemble de copies pour une donne sert alors la fois amliorer sa localit et sa disponibilit. Par exemple, une copie cre sous le contrle du protocole de cohrence des ns de localit peut servir de sauvegarde en cas de fautes. De mme, des copies cres par les mcanismes de tolrance aux fautes peuvent tre utilises par le protocole de cohrence. Notamment employe pour la conception de systmes MVP tolrants aux fautes, cette approche a pour principal avantage de permettre la mise en uvre de protocoles efcaces [68] au prix dun fonctionnement plus complexe. Le principal inconvnient de cette solution est que la maintenance et lvolution du code sont dlicates. La mise en place dun nouveau protocole de cohrence, par exemple, ncessite de prendre en compte nement les mcanismes de tolrance aux fautes manipulant eux aussi les copies. Nous souhaitons privilgier une gestion dcouple an de pouvoir : 1) implanter facilement de nouveaux protocoles de cohrence et aussi pouvoir rpondre aux exigences dun grand nombre dapplications ; 2) implanter de nouveaux mcanismes de rplication et aussi
tel-00411447, version 1 - 27 Aug 2009
79
pouvoir offrir divers compromis garanties offertes/performances ; et 3) avoir la possibilit de comparer des protocoles de cohrence en utilisant les mmes mcanismes de tolrance aux fautes, ou de comparer diffrents mcanismes de tolrance aux fautes en mesurant les performances dun mme protocole de cohrence. Cependant, nous souhaitons galement proter des copies prsentes au sein du systme, que cela soit au niveau des protocoles de cohrence ou au niveau des mcanismes de tolrance aux fautes. Malgr notre architecture dcouple, nous verrons que certaines copies cres par le protocole de cohrence peuvent tre exploites par les mcanismes de tolrance aux fautes. De mme certaines copies cres par les mcanismes de rplication des ns de tolrance aux fautes peuvent tre utilises par le protocole de cohrence si elles se trouvent bien places par rapport un processus applicatif utilisateur. Par exemple, au sein dun groupe cluster, les mcanismes de tolrance aux fautes peuvent dcider de crer une copie dans un groupe cluster distant an de garantir la persistance de la donne en cas de dfaillance du groupe cluster entier. Cette dfaillance peut tre provoque par exemple par une panne de courant de la grappe, les groupes cluster logiques reprsentant des grappes physiques. Un pair client situ justement dans le groupe cluster distant dans lequel a t rplique la donne pourra utiliser, via le protocole de cohrence, cette copie qui lui est proche. Pour offrir ces proprits, nous proposons larchitecture en couches reprsente par la gure 6.3, et dcrite ci-dessous.
tel-00411447, version 1 - 27 Aug 2009
6.2.2
La couche de communication de groupe
Cette couche est directement en relation avec le noyau J UX M EM. Son rle est doffrir un mcanisme de rplication able. Elle sappuie la fois sur les primitives de communication et celles de publication/recherche du noyau J UX M EM. Les primitives de communication sont utilises pour changer les messages entre les diffrents acteurs, pairs clients et pairs fournisseurs ; les primitives de publication/recherche, quant elles, sont utilises des ns de localisation, par exemple pour retrouver les pairs fournisseurs. Cette couche est compose de deux modules logiciels : un qui sexcute sur les pairs de type fournisseur, et un qui sexcute sur les pairs de type client. Ct fournisseur, cette couche est responsable de la gestion de la composition de groupe. Elle peut, par exemple, tre instancie par la pile logicielle prsente dans le chapitre prcdent en section 5.4. Un groupe se voit attribuer un identiant unique semblable ceux donns aux pairs, et cest cet identiant qui permet au client de communiquer avec le groupe. Ct client, cette couche offre une interface qui permet de communiquer avec un groupe de pairs de la mme manire que lon communiquerait avec un seul pair. La composition du groupe, cest--dire le nombre et lidentit de chaque pair membre, est cache aux couches suprieures ct client. Linterface offerte par cette couche permet donc aux pairs clients de communiquer avec un groupe de pairs, en loccurrence un groupe de fournisseurs, de manire transparente, comme sil ny avait quun seul pair.
80
6.2.3
La couche dadaptation aux fautes
tel-00411447, version 1 - 27 Aug 2009
La couche dadaptation aux fautes offre la possibilit davoir des groupes autoorganisants. Cette couche est situe juste au-dessus de la couche de communication de groupe et elle utilise des dtecteurs de fautes du type dcrit la section 3.2.4 (rductibles des dtecteurs de fautes de classe P ). Son rle est de grer ladaptation aux fautes du groupe. Lorsque lun des membres du groupe est suspect dtre dfaillant par les dtecteurs de fautes, cette couche va ragir en fonction 1) du rle jou par le membre fautif (tous les membres dun groupe ne jouent pas ncessairement le mme rle, voir chapitre 8) ; et 2) de la politique dadaptation. Par exemple, il existe des mcanismes de communication de groupe bass sur la notion de leader ; si le leader est suspect dtre fautif, une lection sera dclenche an de le remplacer. Les politiques dadaptation peuvent tre varies. Elles peuvent simplement consister remplacer la copie suspecte an de conserver un degr de rplication constant, mais elles peuvent galement tre plus complexes et par exemple tenir compte dune estimation du Mean Time Between Failures (MTBF) courant an de dcider ou non de remplacer la copie suspecte. La couche dadaptation aux fautes nest prsente que sur les pairs de type fournisseur. Les couches vues jusquici permettent la gestion de groupes de pairs qui vont recevoir les mmes messages. Ceci nous offre des groupes de copies qui vont pouvoir tre considrs comme stables sous certaines conditions de fautes. Les conditions varient selon limplmentation de ces couches, et nous verrons au chapitre 8 quil en existe plusieurs. Ces groupes sont appels par la suite des groupes auto-organisants ou SOG (pour langlais Self-Organizing Group). En effet, grce la couche dadaptation aux fautes, les SOG vont continuer dexister en prsence de fautes, en se rorganisant.
6.2.4
Les protocoles de cohrence
Nous avons montr quil existe pour les systmes mmoire virtuellement partage de nombreux modles de cohrence implments par des protocoles de cohrence (voir section 4.1). limage du protocole de cohrence pris comme exemple dans notre tude de cas au chapitre 5, ces protocoles reposent souvent sur des entits implicitement supposes stables (comme un gestionnaire de page par exemple). Nous proposons de gnraliser la solution vue la section 5.4 et dutiliser ces protocoles dans notre service de partage de donnes pour la grille en implmentant les entits supposes stables grce des groupes de copies auto-organisants (SOG). En effet, ces groupes peuvent tre considrs comme stables si certaines conditions sont remplies. Nous avons vu que ces conditions varient selon limplmentation choisie pour la couche de communication de groupe et selon la cardinalit du groupe. Par exemple pour notre tude de cas de la section 5.4, un nud responsable dune copie de rfrence est implment par un groupe auto-organisant. Ainsi lautomate reprsentant ltat du protocole de cohrence (objet de synchronisation, tat des listes dattentes, etc.) se trouve rpliqu sur un ensemble de pairs. La pile logicielle propose dans la section 5.4 pour mettre en uvre la rplication permet de supporter n1 fautes simultanes 2 au sein dun groupe, o n est la cardinalit du groupe. Sur les pairs de type fournisseur, cette couche se situe au-dessus de la couche de communication de groupe. Elle se trouve donc rplique. Cependant, cette rplication est invisible ce niveau : pour chaque copie tout se passe comme si elle tait le seul et unique exemplaire.
6.2 Interactions
81
La couche de communication de groupe permet aux diffrentes copies de traiter les mmes messages, dans le mme ordre ; les copies voluent donc de la mme faon. Sur les pairs de type client, le protocole de cohrence est en relation avec lapplication par lintermdiaire de la couche du noyau J UX M EM responsable des interactions avec lapplication. Elle interagit avec les pairs fournisseurs (cest--dire le groupe data) en utilisant la couche de communication de groupe.
6.3 Interactions entre le protocole de cohrence et les mcanismes de tolrance aux fautes
Larchitecture dcrite ci-dessus permet une gestion conjointe de la tolrance aux fautes et du protocole de cohrence. Cette architecture est dcouple, permettant ainsi de sparer les problmes lis la tolrance aux fautes de ceux lis la cohrence des donnes. Cependant, il apparat que les connaissances du systme ne sont pas les mmes au sein des diffrentes couches. Au niveau du protocole de cohrence, la connaissance de larchitecture physique sous-jacente est trs limite. En effet, cest au niveau des mcanismes de composition de groupe que lon connat individuellement les diffrents nuds hbergeant une copie. En revanche, cest le protocole de cohrence qui possde la meilleure connaissance de lapplication car cest ce niveau que lon prend en compte les diffrents pairs qui accdent ou vont accder la donne. Nous souhaitons donc que ces deux couches interagissent an dutiliser au mieux le potentiel offert par les ressources physiques utilises par exemple lors de la cration dune nouvelle copie.
tel-00411447, version 1 - 27 Aug 2009
Cration dune nouvelle copie. En cas de faute, les mcanismes de rplication peuvent avoir remplacer une copie suspecte. De mme, lintervention dun nouvel utilisateur (pair accdant la donne) peut ncessiter la mise en place dune nouvelle copie, voire dun nouveau groupe de copies par le protocole de cohrence. Selon le cas, la cration dune nouvelle copie peut donc tre dcide soit par les mcanismes de tolrance aux fautes, soit sous le contrle du protocole de cohrence an damliorer la localit pour un nouvel utilisateur. Dans tous les cas, les mcanismes de rplication doivent en tre informs. En effet, cest leur niveau que sont gres les diffrentes copies. En revanche, le protocole de cohrence, plus proche de lapplication, possdant notamment des listes dattentes sur des verrous, est plus mme de choisir le pair devant hberger la nouvelle copie. De plus, la cration dune nouvelle copie ncessite un transfert dtat du protocole de cohrence. En effet, le nouveau pair doit recevoir une copie de la donne mais galement ltat complet du protocole de cohrence : par exemple, un numro de version attribu la donne, ltat de la donne (verrouille ou non), une ou plusieurs listes dattente sur la donne, etc. Nous avons donc introduit une couche intermdiaire, appele couche de jonction, responsable des interactions entre la couche contenant le protocole de cohrence et celles responsables de la tolrance aux fautes (SOG). Cest ce niveau que lon peut ajuster le degr dinteraction entre les deux. Le rle de cette couche est dcrit plus en dtail au chapitre 8.
82
6.4 Vers une approche gnrique

Notre service de partage de donnes pour la grille, J UX M EM, doit tre utilisable par un grand nombre dapplications, sur des plates-formes physiques potentiellement varies. Cela implique que les diffrentes donnes gres par J UX M EM doivent pouvoir tre gres selon diffrents compromis. En effet, les schmas daccs aux donnes peuvent varier dune donne lautre, et certaines donnes sont plus critiques que dautres. Schmas daccs aux donnes. J UX M EM est appel stocker diffrents types de donnes dont certaines ne seront accdes quen lecture. Par exemple, une matrice gnre par un instrument de mesure sera en gnral stocke puis utilise comme donne dentre de nombreux calculs, mais non modie. En revanche, dautres donnes seront accdes presque uniquement en criture, comme des points de reprises sauvegards par exemple. Ces derniers sont remplacs au fur et mesure quils deviennent obsoltes et ne sont accds en lecture quen cas de retour en arrire de lapplication qui les a gnrs, ce qui est gnralement peu frquent. La majorit des donnes nont pas des schmas daccs aussi simples. Elles sont accdes aussi bien en lecture quen criture. Les accs peuvent galement tre concurrents. Il est alors important de mettre la disposition des applications des protocoles de cohrence leur permettant de faire de manire efcaces les accs aux donnes. Selon le schmas daccs aux donnes dune application, certains modles et protocoles de cohrence seront plus efcaces que dautres. Par exemple, dans le cas du modle de cohrence lentre dcrit dans la section 5.2, lassociation dun objet de synchronisation chaque donne partage an de mettre en place des accs exclusifs la donne nest daucune utilit pour le partage dune donne en lecture seule. De plus, les applications sont toutes implmentes en supposant un certain modle de cohrence. J UX M EM doit donc offrir une palette de protocoles de cohrence implmentant les divers modles supposs par les applications qui vont lutiliser. Cela permet de limiter limpact de lutilisation de notre service de partage de donnes au niveau du code des applications car limplmentation des accs aux donnes peut varier selon le modle de cohrence. Mais cela permet galement de conserver le modle de cohrence initialement choisi par les concepteurs des applications. Criticit des donnes. Les donnes se diffrencient galement par leur niveau de criticit. En effet, certaines donnes peuvent tre considres comme trs critiques alors que dautres peuvent ventuellement tre perdues, par exemple parce quil est facile de les rgnrer. Des donnes gnres par un instrument de mesure, par exemple, ne doivent pas tre perdues. En effet, leur rgnration peut savrer trs coteuse, voire impossible. En revanche certaines donnes sont des donnes temporaires qui sont gnres partir dalgorithmes simples, comme le rsultat du dcoupage dune matrice. Si une sous-matrice est perdue, elle pourra facilement tre rgnre par lalgorithme de dcoupage. De ce fait, il nous semble important de prendre en compte le niveau de criticit des donnes : garantir la persistance dune donne a un cot en termes de performance daccs. Plus les hypothses sur les fautes sont pessimistes, plus le cot des mcanismes de rplication
tel-00411447, version 1 - 27 Aug 2009
6.4 Vers une approche gnrique
83
rpercut sur les temps daccs la donne va tre important. Lapplication doit pouvoir choisir le compromis niveau de risque/performance quelle accepte pour chaque donne gre par le service. Des blocs interchangeables. J UX M EM doit sadapter aux exigences des applications en termes de performance et de garantie ainsi quaux contraintes physiques, notamment en terme de probabilit doccurrence de fautes, pour chacune des donnes gres par le service. Chacune des couches dcrites ci-dessus doit donc prsenter plusieurs implmentations. Cela signie que les interfaces entre les couches doivent supporter un grand nombre de combinaisons protocoles de cohrence/mcanismes de tolrance aux fautes. De plus, le choix de la combinaison optimale doit pouvoir tre fait pour chaque donne. Des mcanismes dinstantiation dynamiques ont donc t mis en place. Ces interfaces, ainsi que cette architecture en couches, permettent de pouvoir implmenter facilement de nouveaux protocoles de cohrence, de nouveaux mcanismes de rplication, et dexprimenter les diffrentes combinaisons. De plus cela permet aux applications de pouvoir elles-mmes, pour chaque donne partage, choisir le compromis qui convient le mieux en fonction du niveau de risque estim ainsi que des performances attendues. Des valeurs par dfaut sont bien entendu fournies de manire permettre une utilisation aise. La conception du cur des couches doit prendre en compte les contraintes imposes par larchitecture physique des grilles de calcul an doffrir aux applications des temps daccs aux donnes partages performants. Cest lobjet du chapitre suivant.
tel-00411447, version 1 - 27 Aug 2009
tel-00411447, version 1 - 27 Aug 2009
85
Chapitre
Gestion hirarchique de la rplication et de la cohrence des donnes

tel-00411447, version 1 - 27 Aug 2009
Sommaire
7.1 Gestion hirarchique de la cohrence . . . . . . . . . . . . . . . . 7.1.1 Limites dun protocole non-hirarchique . . . . . . . . . . 7.1.2 Une vision hirarchique . . . . . . . . . . . . . . . . . . . . 7.1.3 Des protocoles de cohrence hirarchiques . . . . . . . . . Gestion hirarchique de la tolrance aux fautes . . . . . . . . . . 7.2.1 Dtecteurs de fautes bass sur une approche hirarchique 7.2.2 Protocole hirarchique de composition de groupe . . . . . 7.2.3 Propagation des messages . . . . . . . . . . . . . . . . . . . Un exemple de scnario . . . . . . . . . . . . . . . . . . . . . . . . Mcanismes complmentaires . . . . . . . . . . . . . . . . . . . . La hirarchie : une solution gnrique pour les grilles ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 . 86 . 86 . 87 . 89 . 89 . 92 . 93 . 95 . 98 . 100
7.2
7.3 7.4 7.5
Le chapitre prcdent dcrit notre proposition darchitecture en couches pour une gestion conjointe de la tolrance aux fautes et de la cohrence des donnes. Le principal but de cette architecture est de faciliter la mise en uvre de nouveaux protocoles de cohrence ainsi que de nouveaux mcanismes de tolrance aux fautes. Lors de la mise en uvre de protocoles de cohrence et de mcanismes de tolrance aux fautes il est important de prendre en compte les caractristiques physiques des grilles de calcul pour offrir des accs performants aux donnes partages. Ce chapitre dcrit comment il est possible concevoir les couches de notre architecture de manire construire des protocoles de cohrence et des mcanismes de tolrance aux fautes prenant en compte les caractristiques des grilles. Nous gnralisons ici les solutions abordes au chapitre 5 pour faire face aux problmes lis au passage lchelle : nous proposons
86
Chapitre 7 Gestion hirarchique de la rplication et de la cohrence des donnes
une approche hirarchique pour la conception des diffrentes couches dcrites au chapitre prcdent.
7.1 Gestion hirarchique de la cohrence

Au chapitre 5, nous avons montr sur un exemple de protocole de cohrence quune conception hirarchique du protocole permet dadapter ce protocole la topologie rseau de la grille telle que dcrite la section 2.1. Nous gnralisons ici cette solution.
7.1.1
Limites dun protocole non-hirarchique
Lorsque lon tudie les protocoles de cohrence existants, par exemple dans le cadre des mmoires virtuellement partages, on saperoit quils ne conviennent pas la topologie des grilles de calcul. En effet, la plupart dentre eux se base sur une topologie suppose plate. De plus, comme dtaill dans la section 4.1, de nombreux protocoles exploitent les notions de gestionnaire de donne, de copie de rfrence dune donne, etc. Il en rsulte que chaque accs une donne ncessite des communications avec un nud particulier (avec le nud hbergeant la copie de rfrence dans lexemple du chapitre 5). Au sein dune architecture de type grille, tous les liens rseau ne prsentent pas les mmes caractristiques. Si lon reprend la description des grilles de calcul vues comme des fdrations de grappes du chapitre 2.1, on peut observer une diffrence notable (de lordre dun facteur 1.000, voire 10.000) entre la latence des liens au sein dune grappe et celle des liens reliant les grappes entre elles. Par exemple, au sein de grappes quipes de rseaux de type Myrinet [119], la latence entre deux nuds sera de lordre de 2 s, alors que la latence entre deux nuds situs dans chacune de ces grappes sera de lordre de quelques dizaines de millimes de secondes si lon utilise un rseau comme Renater [125] voire plusieurs centaines de millimes de secondes si elles sont relies par Internet. De plus, dans le cas de grappes relies par un rseau tel Internet, cette diffrence concerne galement le dbit des liens rseau et non seulement la latence. Nous avons vu au chapitre 5 que si des nuds gographiquement loigns partagent une mme donne, de nombreuses communications vont utiliser des liens longue distance (intergrappe). Un protocole de cohrence non-hirarchique risque dtre inefcace tant donn la topologie rseau, il nous semble judicieux dadapter le protocole de cohrence an de tenir compte de la structure hirarchique sous-jacente. En effet il est souhaitable de limiter lutilisation des liens intergrappe plus forte latence.
tel-00411447, version 1 - 27 Aug 2009
7.1.2
Une vision hirarchique
Il est difcile denvisager une application scientique trs grande chelle impliquant plusieurs milliers de processus pour laquelle chaque processus communique indiffremment avec nimporte quel autre processus. Dans le cas des applications de couplage de codes auxquelles nous nous intressons (voir section 2.2), lensemble des processus impliqus est partitionnable naturellement en sous-groupes. Les processus membres dun mme sous-groupe excutent gnralement un code parallle et les diffrents codes sexcutant sur les diffrents sous-groupes sont coupls, cest--dire quils changent de temps en temps des
7.1 Gestion hirarchique de la cohrence
87
informations. Il en rsulte quil existe de nombreuses communications aux sein de chaque sous-groupe dans lesquels les processus sont fortement lis et seulement quelques-unes entre les sous-groupes cooprants. Dploiement des applications. Lors du dploiement de telles applications, des ns defcacit, il est judicieux de placer les processus appartement un mme groupe sur des nuds proches les uns des autres. Ici, la distance se mesure en latence rseau entre les nuds. Typiquement chaque groupe de processus dune application de type couplage de codes va tre plac sur une mme grappe. Ainsi, les entits fortement lies (cest--dire partageant de nombreuses donnes) vont bncier de communications efcaces alors que les liens reliant entre eux les diffrents groupes de nuds, sur lesquels sexcutent les groupes de lapplication de couplage de code, prsenteront gnralement des latences plus leves (voir section 2.2).
7.1.3
Des protocoles de cohrence hirarchiques
tel-00411447, version 1 - 27 Aug 2009
Lors de notre tude de cas, au chapitre 5, nous avons montr les faiblesses dun exemple de protocole de cohrence plat. En nous inspirant de Clustered Lazy Release Consistency (CLRC [6]) qui propose damliorer la localit en crant des caches locaux et de [5] qui propose une approche hirarchique pour la gestion distribue dobjets de synchronisation, nous avons propos une solution. Elle consiste hirarchiser le protocole de cohrence an damliorer ses performances en limitant lutilisation des liens intergrappe. cette n nous avons introduit la notion de copie de rfrence locale. Le protocole de cohrence tudi dans le chapitre 5 prsente une caractristique commune de nombreux protocoles de cohrence : un nud joue un rle central et est responsable des accs la donne. Cette caractristique se retrouve au niveau de tous les protocoles dits home-based ou ceux utilisant un gestionnaire de page. Notre solution dcrite sur un exemple au chapitre 5 est gnralisable tous les protocoles prsentant cette caractristique. Le principal intrt de la construction hirarchique du protocole de cohrence est de permettre une diffrenciation des accs selon les grappes et ainsi de pouvoir favoriser certains accs. Par exemple si une donne est partage par plusieurs processus rpartis dans des grappes diffrentes, le protocole de cohrence va chercher favoriser les accs locaux par rapport aux accs externes (provenant dune autre grappe). Cela va permettre de limiter le cas o la donne est accde dans une grappe A, puis dans une grappe B pour revenir la grappe A et ainsi de suite. Dans les cas o cela est possible, les accs se feront ainsi dabord dans la grappe A puis dans la grappe B, limitant ainsi lutilisation des liens intergrappe dont la latence est coteuse pour propager les mises jour de la donne partage. Cependant, il est possible quau niveau applicatif, ces allers-retours de la dernire version de la donne soient obligatoires. Dans ce cas ils se feront naturellement grce aux synchronisations prsentes au niveau applicatif. De plus, an dviter une famine, il est ncessaire de borner le nombre de fois o les accs locaux sont privilgis. Sinon, il serait possible quune grappe (ou un ensemble de nuds au sein dune grappe) soit bloque et il en rsulterait une squentialisation de lapplication dont le cot pourrait tre suprieur au gain offert par la hirarchisation du protocole de cohrence. Il existe un deuxime avantage offert par la hirarchisation du protocole de cohrence. Cela permet davoir une vision restreinte : mme si une donne est accde par de trs nom-
88
Lien WAN
Reprsentant global
Lien WAN
Lien SAN Reprsentant local Client B
Client A
Reprsentant local
Grappe A
Grappe B
F IG . 7.1 Un protocole de cohrence hirarchique.
tel-00411447, version 1 - 27 Aug 2009
breux nuds, une copie de rfrence locale ninteragira quavec un sous-ensemble limit, lensemble des nuds de la grappe partageant la donne associe la copie de rfrence. De mme, la copie de rfrence globale dune donne ne sera accde que par les copies de rfrences locales de cette donne situes dans les grappe dans lesquelles se sexcutent des clients partageant cette donne. La hirarchie permet donc de limiter le nombre de clients potentiels dune copie de rfrence, locale ou globale. Il en rsulte une diminution des accs sur les copies de rfrence ainsi quune rduction de la taille des listes dattente. Cela permet un meilleur passage lchelle du protocole de cohrence. De la mme manire que nous avons introduit la notion de copie de rfrence locale la section 5.3, il est possible de gnraliser en introduisant la notion de reprsentant local. Nous avons remarqu dans la section 4.1 que de nombreux protocoles de cohrence sont fonds sur des entits xes jouant un rle central, les nuds gestionnaires par exemple. Les reprsentants locaux peuvent jouer ce rle vis--vis des clients situs dans le mme groupe cluster. Au sein de chaque groupe cluster contenant des nuds partageant une donne d, le protocole de cohrence place un reprsentant local pour cette donne d (une copie de rfrence locale par exemple). Chaque fois que le protocole de cohrence sexcutant sur un nud client doit accder lentit jouant le rle central du protocole, il contacte le reprsentant local pour cette donne au sein de sa grappe. Ainsi, les protocoles de cohrence client nont pas de vision hirarchique. De leur point de vue, tout se passe comme si le reprsentant local auquel ils accdent tait lentit jouant le rle central du protocole de cohrence. Cependant les donnes peuvent tre partages par des nuds nappartenant pas une mme grappe. Les modications des uns doivent pouvoir tre vues par tous les autres. Aussi pour chaque donne partage, le protocole de cohrence doit galement grer la cohrence entre les diffrents reprsentants locaux rpartis dans plusieurs grappes dune fdration. Nous aboutissons un protocole de cohrence hirarchique deux niveaux illustr par la gure 7.1. Au niveau local, les nuds dune mme grappe accdent une donne partage via un reprsentant local situ dans cette mme grappe. Au niveau global, les reprsentants locaux accdent un reprsentant global qui joue le rle central du protocole de cohrence vis--vis des reprsentants locaux. Les reprsentants locaux se comportent comme des clients vis--vis du reprsentant global. Ainsi lorsquun nud a besoin daccder une donne partage, il contacte le reprsen-
7.2 Gestion hirarchique de la tolrance aux fautes
89
tant local qui peut soit permettre laccs directement, soit avoir contacter le reprsentant global an de se mettre jour ou de demander un accs exclusif la donne par exemple. La hirarchisation du protocole permet damliorer les performances des accs aux donnes partages sur les architectures de type grille cependant cela ne permet pas de supporter les fautes. En effet, la faute dun nud jouant le rle de reprsentant (local ou global) du protocole de cohrence peut entraner la perte de la donne1 . La section suivante prsente des mcanismes de tolrance aux fautes adapts la grille et aux protocoles de cohrence hirarchiques dcrits dans cette section.

De mme que pour la gestion de la cohrence des donnes, les mcanismes de tolrance aux fautes doivent prendre en compte les diffrences de latence entre les liens intergrappe et intragrappe. Nous proposons donc une approche hirarchique pour la gestion de la tolrance aux fautes. Nous utilisons les dtecteurs de fautes bass sur une approche hirarchique qui ont t conus au cours de la thse de Marin Bertier [16]. Ces dtecteurs sont dcrits dans la section 3.2.4. Nous avons galement mis en place des mcanismes de rplication hirarchiques.
tel-00411447, version 1 - 27 Aug 2009
7.2.1
Dtecteurs de fautes bass sur une approche hirarchique
Les mcanismes de tolrance aux fautes que nous avons conus utilisent des dtecteurs de fautes. Ils sont en effet ncessaires aussi bien pour la prvention des fautes (la rplication) que pour la raction aux fautes (rle de la couche dadaptation aux fautes). Accord. Les mcanismes de prvention de fautes comme la rplication peuvent utiliser des algorithmes daccord an doffrir les garanties ncessaires en cas de fautes, comme permettre une mise jour atomique de plusieurs copies pour quil reste des copies jour en cas de fautes. Les dtecteurs de fautes permettent de rsoudre des problmes daccord en prsence de fautes. Attente innie. De manire plus gnrale, les dtecteurs de fautes permettent dviter dattendre inniment la rponse dun nud fautif. Par exemple, nous avons vu au chapitre 5 que les mcanismes de rplication peuvent utiliser des algorithmes de consensus. Ces derniers doivent tre prvenus en cas de fautes an de pouvoir prendre une dcision sans attendre les nuds fautifs. Raction/adaptation aux fautes. Il est ncessaire de prendre en compte les fautes qui surviennent et de ragir an de pouvoir supporter de nouvelles fautes dans le futur. Cest le rle jou par la couche dadaptation aux fautes, permettant de mettre en place les groupes autoorganisants. cette n, les dtecteurs vont permettre de signaler aux algorithmes dadaptation aux fautes quun nud est suspect dtre dfaillant.
Nous considrons ici que la perte de la dernire version de la donne, qui peut tre dtenue par un des reprsentants locaux, est quivalente la perte de la donne.
1
90
Les dtecteurs de fautes utiliss permettent denregistrer une fonction qui sera appele en cas de suspicion. Lors de lenregistrement de cette fonction il est possible de stipuler le niveau de qualit de service que lon souhaite en terme de compromis entre la ractivit des dtecteurs et le taux de fausses dtections (suspicion dun nud non fautif). Parmi les caractristiques de ces dtecteurs de fautes, celles qui nous intressent particulirement sont : le passage lchelle, ladaptabilit, le paramtrage du niveau de qualit de service. Le passage lchelle. Comme dtaill au chapitre 3.2.4, ces dtecteurs sont hirarchiques et sadaptent donc trs bien une architecture de type grille. Dautant mieux une fdration de grappes. Ces dtecteurs sont bass sur des mcanismes dmissions rgulires de messages de vie. En associant les groupes locaux des dtecteurs aux groupes cluster J UX M EM comme illustr par la gure 7.2, on obtient des changes de messages de vies de type tous-vers-tous aux sein de chaque groupe cluster et des changes de messages de vie entre reprsentant de grappes. Ladaptabilit. Les architectures de type grille sont dynamiques par nature. La charge des diffrents nuds, des passerelles, des switches peut varier au cours du temps. Cela est notamment d au fait que les grilles de calcul sont gnralement multi-utilisateur. Les dtecteurs de fautes utiliss prennent en compte ces variations dans le calcul des estimations des prochaines arrives de messages de vie et offrent donc une bonne prcision. Le paramtrage du niveau de qualit de service. Les dtecteurs de fautes vont tre utiliss de multiples niveaux de notre architecture en couche. Notamment 1) au niveau des mcanismes de rplication, pour de leur viter dattendre indniment des messages de nuds fautifs ; et 2) au niveau de la couche dadaptation aux fautes, an de ragir en cas de faute (en remplaant les nuds fautifs par exemple). Ces diffrents cas dutilisation ne ncessitent pas les mmes niveaux de qualit de service de la part des dtecteurs. En effet, au niveau des couches basses, il va tre important davoir une dtection de faute ractive pour permettre un algorithme de consensus de progresser. Ici, un cas de fausse dtection nest pas critique. En revanche au niveau des couches hautes, comme par exemple la couche dadaptation aux fautes, la ractivit semble moins importante que le risque de fausse dtection. Une dtection de faute remonte ce niveau va effectivement dclencher un lourd processus de rparation. Dans le cas o la politique dadaptation est de conserver le degr de rplication, cela va automatiquement dclencher la recherche dun nud remplaant ainsi que linsertion de ce nud dans le groupe de copies et linitialisation de cette nouvelle copie (transfert dtat)2 . Nous utilisons donc la possibilit de rgler la qualit de service des dtecteurs de fautes an davoir chaque niveau une dtection adapte. Les dtecteurs de fautes proposent un service de dtection deux niveaux : local et global. La dtection au niveau global se fait par lintermdiaire de mandataires slectionns au sein de chaque groupe local.
2
tel-00411447, version 1 - 27 Aug 2009
Un exemple de mcanisme de rparation est donn au chapitre 9.
91
Groupe JuxMem
Groupe data Groupe cluster A
Groupe cluster C
tel-00411447, version 1 - 27 Aug 2009
Groupe cluster B
Groupe local A
Groupe local C
Groupe local B Client Gestionnaire / mandataire Fournisseur / nonmandataire
F IG . 7.2 Correspondance entre les groupes de dtection de fautes et les groupes cluster J UX M EM.
92
Notre architecture a t conue de manire pouvoir intgrer les dtecteurs de fautes en faisant correspondre les groupes locaux des dtecteurs avec les groupes cluster de J UX M EM. Dans chaque groupe local/groupe cluster le mandataire initial est le pair gestionnaire du groupe cluster. La gure 7.2 illustre cette correspondance. Nous allons voir dans la suite de cette section que cette correspondance permet de ne grer, au niveau de chaque groupe cluster, que les dfaillances des pairs situs au sein du mme groupe cluster ; et au niveau du groupe J UX M EM, de ne grer que les dfaillances des groupes cluster (cest--dire les dfaillances de grappes).
7.2.2
Protocole hirarchique de composition de groupe
tel-00411447, version 1 - 27 Aug 2009
Il existe de multiples travaux sur les mcanismes de composition de groupe, il sont dcrits la section 3.3. Cependant, la gestion de ces groupes se base gnralement sur des mcanismes utilisant des synchronisations globales. La taille de ces groupes doit donc tre restreinte. De plus, il est prfrable que les dlais de communication entre les membres dun mme groupe soient courts car si les temps de synchronisation se rapprochent des temps interfaute, les synchronisations vont souvent chouer. Les mcanismes de composition de groupe pair--pair passent lchelle tout en relchant les contraintes. Ils noffrent gnralement pas de garanties : ils sont dits best effort. Or, pour la rplication des entits des protocoles de cohrence, il est ncessaire doffrir des garanties. Sans cela, diffrentes copies du protocole de cohrence volueraient de manire diffrente, aboutissant une incohrence au niveau du partage de donne, par exemple la lecture dune valeur obsolte. Le groupe que nous souhaitons grer est le le groupe data, qui stend potentiellement sur plusieurs grappes. Nous souhaitons galement pouvoir offrir des garanties strictes dun point de vue tolrance aux fautes et cohrence de donnes. Nous proposons donc une solution permettant dallier passage lchelle et garanties pour la rplication des entits du protocole de cohrence. Une hirarchie impose. Le but de la rplication est de ne pas perdre la donne ni ltat du protocole de cohrence, y compris en cas de fautes. Le chapitre 5 dcrit comment il est possible datteindre ce but sur un exemple de protocole de cohrence lentre en mettant en place des mcanismes pour rpliquer la copie de rfrence. Cette solution est gnralisable tous les protocoles prsentant la caractristique davoir un nud jouant un rle central (voir section 7.1.3). Dans le cas dun protocole de cohrence hirarchique, comme dcrit la section 7.1.3, il est ncessaire galement de rpliquer des reprsentants locaux. En effet, un reprsentant local peut tre un moment donn le seul hberger la dernire version de la donne (dans le cas par exemple o un accs en criture vient de se produire dans la grappe dans laquelle il se situe). Les entits que nous souhaitons rpliquer sont les entits critiques du protocole de cohrence : chaque reprsentant local et le reprsentant global de chaque donne. Au sein dune grappe, les algorithmes de rplication peuvent bncier dun rseau performant prsentant une faible latence et un haut dbit. Les mcanismes de rplication ba-
93
ss sur des synchronisations globales, comme ceux utiliss dans lexemple du chapitre 5, semblent donc appropris pour la rplication des reprsentants locaux. Le reprsentant global (la copie de rfrence globale dans lexemple du chapitre 5) est une entit particulirement critique. Cest notamment ce niveau que les accs aux grappes sont distribus. En cas de perte de cette entit, les reprsentants locaux associs se retrouveraient bloqus ainsi que leurs clients. De plus, pour chaque donne il est ncessaire de tolrer la faute dune grappe complte car ce genre de faute est possible au sein dune grille de calcul, comme expliqu la section 2.4. Il est donc ncessaire que le reprsentant global du protocole de cohrence soit rpliqu sur plusieurs grappes. An de limiter le nombre de nuds impliqus dans la gestion de chaque donne, la copie de rfrence globale est reprsente par lensemble des pairs fournisseurs fournissant une copie de la donne au sein du groupe J UX M EM. Dnition 7.1 : local data group (LDG). Un LDG est un groupe de pairs de type fournisseur situs dans un mme groupe cluster et possdant une copie dune mme donne. Il est le reprsentant local du protocole de cohrence grant la donne au sein du groupe cluster dans lequel il se trouve (par exemple, la copie de rfrence locale pour un protocole de cohrence home-based). Il correspond lintersection du groupe data dune donne et dun groupe cluster. Dnition 7.2 : global data group (GDG). Un GDG est un groupe dont les membres sont les LDG reprsentant une mme donne. Chaque donne partage alloue au sein de J UX M EM se voit donc associer un GDG contenant un ou plusieurs LDG. Le protocole de cohrence hirarchique est implant au-dessus de la hirarchie LDG/GDG comme illustr par la gure 7.3. Si une donne nest accde que dans un seul groupe cluster, lunique LDG associ est confondu avec le GDG. Il est galement possible dans ce cas de placer des copies dans un autre groupe cluster, crant ainsi un deuxime LDG an de pouvoir tolrer la panne de la grappe.
tel-00411447, version 1 - 27 Aug 2009
7.2.3
Propagation des messages
Nous venons de voir que nous utilisons les groupes pour rpliquer des entits des protocoles de cohrence. Les protocoles de cohrence sexcutant sur les clients doivent pouvoir communiquer avec ces entits. En effet, cela est ncessaire lors des accs la donne, comme cest le cas pour le protocole de cohrence dcrit au chapitre 5. Les pairs de type client communiquent avec le LDG prsent dans leur grappe. De mme, les LDG (reprsentants locaux des protocoles de cohrence) communiquent avec le GDG (le reprsentant global du protocole de cohrence). Par exemple lorsquun client souhaite obtenir un accs la donne alors que cet accs est dj autoris dans un groupe cluster diffrent, cela va engendrer des communications : 1) entre le client et son LDG 3 ; et 2) entre les LDG et le GDG an que lautorisation daccder la donne puisse changer de groupe cluster. Ces communications sont dtailles ci-dessous.
3
Son LDG reprsente le LDG situ dans le mme groupe cluster.
94

GDG: Global Data Group LDG: Local Data Group C: Client RG: Reprsentant Global RL: Reprsentant Local RG LDG RL RL RL GDG LDG LDG
C C C C C (a)
C C
C C C C C (b)
C C
F IG . 7.3 Rplication des entits critiques du protocole de cohrence hirarchique.
tel-00411447, version 1 - 27 Aug 2009
Communication avec un LDG. Le protocole de cohrence client communique avec le LDG travers la couche de communication de groupe client. Cette dernire est en charge de localiser4 le LDG. Selon limplmentation, il peut sagir de localiser un reprsentant non fautif du groupe, plusieurs membres ou tous les membre du LDG. Quand le LDG est localis, le message est envoy. Sil sagit dune communication de groupe, la couche de jonction ajoute ltiquette GRP_COMM et le message est transmis tous les membres du LDG en utilisant un mcanisme de diffusion atomique. Dans le cas contraire, un seul membre est contact. Cest le cas pour des oprations nimpliquant pas de mise jour de ltat du protocole de cohrence des donnes. Communication avec un GDG. Le protocole de cohrence serveur de niveau local (LDG) communique avec le protocole de cohrence de niveau global (GDG) de la mme manire que les clients le font avec les LDG. Ceci implique que sur chaque pair de type fournisseur et pour chaque donne stocke, sont instancis : 1. les couches de communication de groupe ; 2. le protocole de cohrence local reprsentant le LDG ; 3. le protocole de cohrence global reprsentant le GDG. Lorsquun message est envoy au GDG, par exemple une demande daccs exclusif (verrouillage), le message est retransmis lensemble de ses membres (cest--dire les LDG). Les LDG recevant le message le retransmettent lensemble de leur membres (les pairs fournisseurs). Cependant, il ne sagit l pas dun simple mcanisme de diffusion hirarchique. En effet de manire maintenir la cohrence des copies, les messages impliquant une mise jour (ici une mise jour de la liste dattente pour un accs exclusif) doivent tre ordonns. Il ne faut pas que des mises jour concurrentes soient appliques dans des ordres diffrents. Cela permet dassurer que laccs exclusif ne sera accorde qu un seul client la fois. Le
Ici localiser signie trouver un identiant. La localisation au sens rseau (adresse IP, port) est effectue par les mcanismes JXTA via le noyau J UX M EM.
4
7.3 Un exemple de scnario

Client Fournisseur
95
Protocole de cohrence client
Protocole de cohrence LDG
Protocole de cohrence GDG
Couche de jonction
Couche de jonction
Client SOG
Groupe autoorganisant (SOG) Couche dadaptation aux fautes
tel-00411447, version 1 - 27 Aug 2009
F IG . 7.4 Architecture en couches hirarchique.
chapitre 8 dtaille des mcanismes permettant de garantir une diffusion atomique au sein des GDG et LDG.

Nous illustrons ici le fonctionnement des diffrentes couches prsentes au chapitre 6 implmentes de manire hirarchique (gure 7.4). Un exemple dtaill de mise en uvre se trouve au chapitre 8. Fonctionnement sans fautes. Un client alloue une donne, le noyau J UX M EM instancie le protocole de cohrence client en lui transmettant la liste des fournisseurs quil a slectionns. Avant de sinstancier, le protocole client envoie des messages contenant des requtes dallocation aux pairs fournisseurs contenant une liste de listes de fournisseurs (une liste par groupe cluster). la rception de cette requte les pairs fournisseurs instancient les protocoles de cohrence de niveau LDG et GDG, la couche de jonction et la couche de groupe auto-organisant pour cette donne. Lorsque les diffrentes couches sont instancies et prtes fonctionner, elles publient des annonces la fois dans leur groupe cluster et dans le groupe J UX M EM. Ces annonces permettront aux clients de faire lassociation groupe data /donne. Elles contiennent en effet lidentiant de la donne ainsi que lidentiant (ou les identiants selon le type de rplication utilis) utiliser pour communiquer avec le groupe. Pour nir, un acquittement est retourn au client. Lorsque le client a reu les acquittements de la part des fournisseurs, les couches de jonction et de communication de groupe clientes sont instancies, puis lappel la mthode
96
Chapitre 7 Gestion hirarchique de la rplication et de la cohrence des donnes dallocation se termine en retournant lidentiant de la donne5 .
Par la suite, le protocole de cohrence client interagit avec le protocole de cohrence de niveau LDG via la couche de communication de groupe. De mme, le protocole de cohrence de niveau LDG communique avec le protocole de cohrence de niveau GDG via la couche de communication de groupe. An de partager la donne avec dautres clients, lidentiant de la donne doit tre connu. Larchitecture en couches client peut donc galement tre instancie sans quil y ait interaction avec des pairs fournisseurs. Dans ce cas, la couche client de communication de groupe est responsable de localiser le LDG avec lequel elle doit communiquer. Pour cela elle recherche les annonces publies par les groupes auto-organisants (SOG pour Self-Organizing Group) dans le groupe cluster ce qui lui permet de trouver le LDG prsent dans le mme groupe cluster. Si la recherche choue, une nouvelle recherche est effectue au niveau du groupe J UX M EM an de trouver le GDG.
tel-00411447, version 1 - 27 Aug 2009
Rle de linterface entre protocole de cohrence et couche de tolrance aux fautes. Lorsquil est ncessaire de crer une nouvelle copie, pour conserver le degr de rplication aprs loccurrence dune faute par exemple, une interaction entre les couches de communication de groupe et celles du protocole de cohrence est ncessaire an dinitialiser cette nouvelle copie. Mais le rle de cette interface nest pas limit cela. Cest ce niveau que lon peut notamment optimiser les performances : on souhaite dune part que la rplication soit invisible au niveau des protocoles de cohrence et dautre part que les mcanismes de communication de groupe soient indpendants du protocole de cohrence. La couche de jonction au niveau du client est responsable de dterminer si un message doit tre envoy au groupe ou un seul de ses membres. En effet, certains messages des protocoles de cohrence ne ncessitent pas de modication de ltat du protocole de cohrence ct fournisseur et peuvent donc tre traits par nimporte quel membre du groupe. Ce cas est dtaill dans lexemple dcrit au chapitre 8. Ainsi, la couche de jonction permet dviter des communication de groupe coteuses et inutiles. Gestion des fautes. Notre vision hirarchique permet de distinguer deux types de faute : les pannes franches de nuds au sein dun groupe cluster, et les pannes franches de grappes (groupes cluster). Cela permet de ne pas se proccuper au sein dun groupe cluster des dfaillances de nuds pouvant intervenir au sein des autres groupes cluster du groupe J UX M EM. En cas de suspicion de la part des dtecteurs de fautes ct fournisseur, la suspicion est remonte au niveau de la couche dadaptation aux fautes. Elle est ltre (seules les dfaillances des membres du groupe sont pertinentes ce niveau) puis prise en compte. La prise en compte peut consister en la cration dune nouvelle copie en cas de faute dun pair fournisseur ou en lallocation dun nouveau LDG en cas de faute dune grappe entire. De nouvelles publications dannonces sont galement faites an de signaler la nouvelle situation. Cot client, au niveau de la couche de communication de groupe, lorsquun dlai de garde signale que le groupe contact ne rpond plus, une nouvelle recherche permet de mettre jour lassociation identiant de la donne/localisation du LDG. En effet, au gr des occurrences de fautes et des crations de nouvelles copies, les groupes sont susceptibles de se
De mme que pour les identiants de nuds et de GDG LDG, lidentiant de la donne est gnre au niveau JXTA et est considr comme tant unique.
5
97
dplacer sur les nuds physiques. Ainsi les fautes sont invisibles au niveau des couches suprieures. Gestion des fausses suspicions. Sans faire dhypothse de synchronisme, il nest jamais possible dtre sr quun nud a subit une faute : il est peut-tre simplement trs lent [49]. Aussi les informations remontes par les dtecteurs de fautes ne sont que des suspicions. Il est possible quun nud soit suspect dtre fautif alors quil ne lest pas. Cest ce que lon appelle, une fausse suspicion. Dans les cas o un fournisseur membre dun groupe est suspect, tous les groupes auxquels il appartient (un groupe par donne stocke) pour lesquels au moins un des membres va le suspecter6 vont le considrer comme fautif et lliminer des listes de membres et ventuellement le remplacer. Sil sagit dune fausse suspicion, cela signie que le nud suspect continue de sexcuter et ceci indpendamment du reste du groupe dont il a t vinc. Une telle situation peut mener une incohrence : pour chaque donne stocke par ce fournisseur suspect, ltat du protocole de cohrence ainsi que la donne stocke, nvoluent plus comme le reste du groupe dorigine. Pour remdier cela deux solutions sont possibles : la rparation ou le suicide. La rparation consiste rintgrer le fournisseur faussement suspect au sein du groupe. Cest une solution complique et coteuse : le fournisseur peut appartenir de nombreux groupes et qui plus est de nouvelles suspicions peuvent survenir lors du processus de rparation. Il est donc plus simple et moins coteux dutiliser le suicide, cest--dire considrer le nud faussement suspect comme rellement fautif, car les diffrents groupes suspectant le fournisseur ont dj dclench le processus dadaptation aux fautes. En revanche, le suicide ne concerne que les architectures en couches instancies pour les donnes pour lesquelles le fournisseur a t suspect. En effet, il est possible que le fournisseur participe encore activement des groupes par lesquels il na pas t suspect. Un avantage de cette politique est que si le nud sur lequel sexcute le fournisseur a t suspect, cest peut-tre parce quil est surcharg. Le suicide pour certains groupes va alors permettre dallger la charge du nud suspect. Dfaillances des clients. Nous ne traitons pas ici des dfaillances des clients. En effet si un client J UX M EM est dfaillant, le processus client applicatif associ lest galement : ils sexcutent sur le mme nud et nous considrons les dfaillances de type panne franche (voir section 3.1.1). Les politiques de raction aux dfaillances des clients vont dpendre des mcanismes de tolrance aux fautes de lapplication. Lapplication peut-elle continuer son excution alors quun processus sarrte ? Si cest le cas, le protocole de cohrence doit vincer ce client des utilisateurs potentiels de la donne et si ncessaire rgnrer lobjet de synchronisation dtenu par ce client. Cependant, que se passe-t-il en cas de fausse suspicion dun client si un objet de synchronisation a t redistribu tort ? La rponse ces questions est difcile, elle dpend notamment du degr dinteraction entre le service de partage de donnes et les applications. Supporter les dfaillances des clients ncessite une interaction trs pousse entre le service de partage de donnes et les applications. De plus, cela exige que les applications ellesmmes supportent les fautes car les clients du service de partage de donnes sont les processus de lapplication distribue. Il existe de nombreux mcanismes qui permettent aux
Dans la pratique, les communications intragrappe des dtecteurs de fautes tant bases sur IP-multicast, un nud suspect par un membre le sera trs vite par tous les membres.
6
tel-00411447, version 1 - 27 Aug 2009
98
applications distribues de tolrer les fautes, ils sont dtailles dans la section 3.4. Cependant ils sont gnralement conus soit pour des grappes de calculateurs et ne passent pas lchelle [47], soit pour une trs grande chelle (Internet) et ne tirent pas avantage de la topologie hirarchique des grilles de calcul [22]. Dans la section suivante nous prsentons un mcanisme de sauvegarde de points de reprise pour applications parallles hirarchiques (comme les applications de couplage de code), adapt aux fdrations de grappes et en particuliers notre service de partage de donnes J UX M EM. Un tel mcanisme permet la gestion des dfaillances des clients.
7.4 Mcanismes complmentaires

Les dfaillances des clients ne peuvent pas tre prises en compte par le service de partage de donnes sans mcanismes complmentaires. En effet, les processus de lapplication distribue sexcutent sur les nuds clients, et en cas de faute, le processus fautif peut tre relanc partir dun tat prcdemment sauvegard. Mais, il existe des dpendances entre ces processus. Lorsquun processus retourne en arrire dans un tat sauvegard, il est ncessaire de prendre en compte ces dpendances an dviter les incohrences qui peuvent tre introduites par les messages quil va r-mettre, ou ceux quil avait dj reus et quil risque dattendre indniment. La solution consiste sauvegarder un tat global cohrent, un point de reprise, cest--dire un ensemble compos des tats locaux de tous les processus applicatifs tels quil nexiste pas de dpendance entre ces tats. La section 3.4 prsente plusieurs travaux de recherche sur la sauvegarde dtats globaux cohrents. Le service de partage de donnes peut servir sauvegarder les points de reprise. Il doit collaborer avec le mcanisme de sauvegarde de point de reprise an que, en cas de retour en arrire de lapplication distribue, les donnes partages et les tats des protocoles de cohrence puissent tre eux aussi restaurs pour viter une incohrence. Cette coopration permet de mettre en place au niveau du service de partage de donnes des mcanismes de rplication trs optimistes : en cas de perte de la dernire version de la donne, il devient possible deffectuer un retour arrire dans un tat cohrent pour lequel il existe une sauvegarde de la donne perdue. Des mcanismes de sauvegarde de points de reprises hirarchiques. Malgr le grand nombre de mcanismes de points de reprises, il en existe trs peu qui soient adapts la grille. En effet, ils sont en gnral conus soit pour des petites chelles et impliquent des synchronisations globales qui ne sont pas adaptes aux grilles de calcul, soit pour des trs grandes chelles et ne permettent pas de tirer avantage des rseaux haute performance prsents au sein des grappes. Nous avons donc conu un protocole de points de reprise pour les applications parallles sexcutant sur des grilles de calcul. Ce protocole utilise une technique hirarchique hybride, mettant en place des sauvegardes de points de reprise coordonnes au sein des grappes, induites par les communications entre les grappes. Au niveau intergrappe, les grappes sont vues comme des super-nuds par le protocole de sauvegarde de points de reprise induit par les communications. Cela est rendu possible par le protocole de sauvegarde de points de reprise intragrappe qui sauve des points de reprises cohrents grce une synchronisation des processus sexcutant au sein de la grappe. La suite de cette section dtaille ce mcanisme.
tel-00411447, version 1 - 27 Aug 2009
7.4 Mcanismes complmentaires
99
Points de reprise coordonns au sein des grappes. Au sein dune grappe de calculateurs, un mcanisme de sauvegarde de points de reprise coordonns semble tre raisonnable. En effet le surcot induit par une synchronisation est relativement faible grce aux performances des rseaux de type SAN (System Area Network, rseau faible latence et dbit lev). Priodiquement, un des nuds de la grappe devient linitiateur dun point de reprise coordonn intragrappe. Il envoie tous les nuds de la grappe une requte dtablissement de point de reprise. Lorsquun nud reoit une telle requte il sauvegarde son tat local. Une fois que ltat local est sauvegard sur un espace de stockage stable (par exemple le service de partage de donnes pour la grille J UX M EM) il envoie un acquittement lmetteur. Lorsque linitiateur a reu un acquittement de la part de tous les autres nuds de sa grappe, il valide son propre tat local et envoie un message de validation tous les autres nuds an quils fassent de mme. Il est possible que deux nuds dcident de dclencher la sauvegarde dun point de reprise coordonn de manire concurrente. Dans ce cas, lidentiant unique du nud est utilis pour dterminer lequel est considr comme linitiateur. Ces points de reprise sont estampills et sauvegards en mmoire stable.
tel-00411447, version 1 - 27 Aug 2009
Points de reprise induits par les communications entre les grappes. Les latences intergrappe pouvant tre leves, un mcanisme de points de reprise coordonn impliquant une synchronisation globale sur la grille nest pas satisfaisant. Les points de reprise coordonns dcrits au paragraphe prcdent sont sauvegards pour chaque grappe de manire indpendante. Nous avons vu la section 3.4 que dans le cas de points de reprise indpendant, il pouvait y avoir un effet domino (important retour en arrire des processus la recherche dun tat global cohrent). Leffet domino peut tre limin en forant la sauvegarde de certains points de reprise lors des communications en fonction dinformations ajoutes aux messages. Ce sont en effet les communications qui impliquent des dpendances : dans un tat global cohrent, tout message reu doit avoir t mis. Lors dune communication intergrappe, la grappe dans laquelle se situe le nud rcepteur peut tre conduite la sauvegarde dun point de reprise coordonn. Les techniques de points de reprise induits par les communications ont t classies dans [80]. Cette classication tient essentiellement compte du nombre de points de reprise forcs inutiles. Forcer un point de reprise avant chaque rception de message, par exemple, empche bien leffet domino mais ajoute un surcot important et inutile. Nous nous intressons donc aux conditions permettant de prendre un nombre minimum de points de reprise forcs. Nous proposons dutiliser un vecteur de dpendance directe (Direct Dependancy Vector ou DDV) comme dcrit dans [8] an de dtecter les dpendances entre les grappes et de forcer la sauvegarde de points de reprise de manire approprie. Nous proposons galement de journaliser les messages en transit. La gestion des DDV implique que chaque grappe gre un numro de squence pour estampiller ses points de reprise, ce numro est incrment chaque fois quun point de reprise est tabli. Le DDV dune grappe est un vecteur dont chaque entre est le dernier numro de squence de la grappe voisine correspondante. Ce numro de squence (not SN) est ajout chaque message intergrappe. Lors de la rception dun message provenant dune autre grappe, le numro de squence quil contient est compar avec lentre du DDV correspondante. Sil est suprieur, un point de reprise est forc avant de prendre le message en compte. Retour en arrire des applications. Quand un nud de type client dans une grappe est fautif (panne franche), les nuds clients de la mme application sexcutant dans la mme
100
grappe effectuent un retour arrire et alertent les nuds clients des autres grappes. Lorsquun nud client reoit une telle alerte (contenant le numro de squence du point de reprise restaur sur le site metteur) le DDV est utilis an de calculer sil est ncessaire deffectuer un retour en arrire dans la grappe rceptrice : cest le cas si et seulement si elle possde un point de reprise pour lequel lentre du DDV correspondant au site ayant envoy lalerte est suprieure ou gale au numro de squence reu. Un tel mcanisme, ainsi que sa coopration avec le service de partage de donnes, est complexe a mettre en uvre, mais cest ce prix que les dfaillances des clients peuvent tre prisent en compte.
7.5 La hirarchie : une solution gnrique pour les grilles ?

Dans ce chapitre nous avons montr comment de nombreux protocoles de cohrence peuvent tre adapts aux grilles en les concevant de manire hirarchique. Nous avons galement dcrit notre hirarchie de groupes auto-organisants permettant de mettre en place des mcanismes de rplication adapts aux grilles. Enn nous avons tudi comment il est possible de mettre en place des mcanismes de sauvegarde de points de reprise pour les applications distribues sexcutant sur les grilles en employant une technique hirarchique. Le point commun entre ces diffrentes solutions rside dans leur conception hirarchique. Pour chacune de ses solutions, la motivation dune conception hirarchique est la mme : limiter lutilisation des liens intergrappe forte latence et tirer prot des rseaux haute performance au sein des grappes. En effet, si lon considre les grilles comme des fdrations de grappes, la topologie du rseau dinterconnexion (dcrite dans la section 2.1) est clairement hirarchique. Limites de lapproche hirarchique. Bien quil semble que les approches hirarchiques soient bien adaptes aux grilles, elles prsentent certains inconvnients. En premier lieu, toutes les grilles de calcul ne sont pas des fdrations de grappes, comme expliqu dans la section 2.1 et leur topologie nest alors pas aussi simple. Il est alors possible de gnraliser notre solution en utilisant des approches mettant en place des hirarchies plus de deux niveaux. De telles solutions seraient cependant trs complexes. En deuxime lieu, la mise en place de solutions hirarchiques savre complexe. Il est ncessaire de 1) dtecter la hirarchie physique, 2) faire correspondre la hirarchie logicielle avec la hirarchie physique, et surtout 3) maintenir les mcanismes hirarchiques en prsence de fautes. Enn, une approche hirarchique implique souvent un plus grand nombre de sauts dans le rseau. Sur lexemple du protocole de cohrence hirarchique du chapitre 5 on observe en effet que dans certains cas le client communique avec la copie de rfrence locale qui contacte la copie de rfrence globale avant de rpondre au client. Dans le cas de la version non hirarchique les communications sont restreintes celles entre le client et la copie de rfrence globale. Il apparat donc quune approche hirarchique rduit la dure moyenne des sauts (en favorisant lutilisation des liens faible latence) mais peut galement en augmenter le nombre.
tel-00411447, version 1 - 27 Aug 2009
101
Troisime partie
tel-00411447, version 1 - 27 Aug 2009
Mise en uvre et valuation
tel-00411447, version 1 - 27 Aug 2009
103
Chapitre
tel-00411447, version 1 - 27 Aug 2009
Exemple de mise en uvre dun protocole de cohrence tolrant aux fautes

Sommaire
8.1 Mise en uvre de larchitecture en couches . . . . . . . . 8.1.1 Architecture logicielle gnrale . . . . . . . . . . . . 8.1.2 Les protocoles de cohrence . . . . . . . . . . . . . . 8.1.3 Les mcanismes de tolrance aux fautes . . . . . . . Mise en uvre dun protocole de cohrence hirarchique 8.2.1 Mise en uvre sur le client . . . . . . . . . . . . . . 8.2.2 Mise en uvre sur les fournisseurs . . . . . . . . . . 8.2.3 Fonctionnement . . . . . . . . . . . . . . . . . . . . . Mise en uvre des groupes auto-organisants . . . . . . . 8.3.1 Mise en place de la rplication . . . . . . . . . . . . 8.3.2 Auto-organisation des groupes . . . . . . . . . . . . Un protocole tendu pour une visualisation efcace . . . 8.4.1 La lecture relche . . . . . . . . . . . . . . . . . . . 8.4.2 Fentre de lecture . . . . . . . . . . . . . . . . . . . . 8.4.3 Analyse de la smantique des paramtres . . . . . . Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 104 106 108 109 110 111 112 113 113 115 116 116 117 117 118
8.2
8.3
8.4
8.5
Larchitecture en couches permettant une gestion conjointe de la tolrance aux fautes et de la cohrence des donnes prsente dans le chapitre 6 a t mise en uvre au sein du service de partage de donnes J UX M EM [129]. Une mise en uvre de protocoles de cohrence hirarchiques tolrants aux fautes suivant le modle dcrit au chapitre 7 a galement t ralise au sein de cette architecture.
104
Chapitre 8 Exemple de mise en uvre
Deux thses (celle de Mathieu Jan et celle-ci) ainsi que trois stages de master recherche deuxime anne ont contribu au dveloppement du service de partage de donnes J UX M EM. Le prototype mettant en uvre J UX M EM correspond plus de 16 700 lignes de code Java et plus de 13 500 lignes de code C, dont environ 7 300 lignes de code Java et 6 100 lignes de code C pour la gestion de la cohrence des donnes et de la tolrance aux fautes. Dans ce chapitre, nous nous focalisons sur la mise en uvre de notre contribution. La section 8.1 dcrit la mise en uvre de larchitecture en couches prsente dans le chapitre 6 et les sections 8.2 et 8.3 prsentent respectivement un exemple de mise en uvre dun protocole de cohrence et un exemple de mise en uvre de la couche de tolrance aux fautes au sein de cette architecture. Enn dans la section 8.4, nous nous intressons une extension du protocole de cohrence prsent dans la section 8.2 offrant aux applications la possibilit deffectuer des observations efcaces dune donne partage.
8.1 Mise en uvre de larchitecture en couches

tel-00411447, version 1 - 27 Aug 2009
Le rle de larchitecture en couches est de dcoupler la gestion de la tolrance aux fautes de la gestion de la cohrence des donnes. Cela permet dune part de pouvoir se concentrer sur un problme unique lors de la mise en uvre des diffrentes couches et dautre part doffrir diffrentes implmentations de chacune des couches. Grce ce dernier point, notre prototype peut offrir aux applications le choix parmi un ventail de combinaisons.
8.1.1
Architecture logicielle gnrale
Pour clarier notre prsentation, nous considrons que chaque nud physique hberge un seul pair J UX M EM. Nous considrons galement que chaque pair J UX M EM ne joue quun seul rle au sein de la plate-forme, cest--dire que chaque pair est soit client, soit fournisseur, soit gestionnaire1 . Ces diffrents rles sont dcrits en dtail dans la section 6.1. Les pairs clients sont lis aux processus applicatifs et permettent daccder aux donnes partages prsentes au sein du service J UX M EM. Les pairs fournisseurs sont quant eux responsables du stockage des copies des donnes partages. Toujours des ns de clart, nous nous focalisons ici sur une seule donne, mme si les clients peuvent accder plusieurs donnes partages, et que les fournisseurs peuvent stocker des copies de plusieurs donnes diffrentes. Instantiation des couches sur les pairs J UX M EM. Pour chaque donne partage laquelle il accde, un client doit instancier la partie client du protocole de cohrence choisi ainsi quune couche de tolrance aux fautes, cest--dire la pile logicielle reprsente par la gure 8.1. Le rle de chacune des couches de cette pile logicielle est dcrit au chapitre 6. Le protocole de cohrence utilise la couche de tolrance aux fautes via la couche de jonction an de communiquer avec la copie de rfrence rplique sur des pairs fournisseurs. Chaque donne stocke au sein du service J UX M EM est rplique, cest--dire quelle est prsente en plusieurs exemplaires. Nous avons dcrit au chapitre 7 notre architecture hirarchique pour la rplication et la gestion de la cohrence. Chaque donne fait donc intervenir
Notre implmentation permet cependant dexcuter plusieurs pairs sur un mme nud physique, et chaque pair peut jouer chacun des rles, simultanment, ou tour de rle.
1
105
Protocole de cohrence (client)
Couche de jonction
Client SOG (couche de tolrance aux fautes)
F IG . 8.1 Pile logicielle instancie sur les pairs clients pour chaque donne partage laquelle le client accde.
tel-00411447, version 1 - 27 Aug 2009
plusieurs pairs fournisseurs. Les pair fournisseurs hbergeant des copies dune mme donne et appartenant une mme grappe (groupe cluster J UX M EM) forment un Local Data Group (LDG) qui est responsable dune copie de rfrence locale. Lensemble des LDG forme le Global Data Group (GDG) qui est responsable de la copie de rfrence globale (voir chapitre 7). Le LDG est un groupe dont les membres sont eux-mmes des groupes, cest donc un groupe de groupes. Chaque pair fournisseur hbergeant une copie dune donne appartient un LDG et chaque LDG appartient un GDG. Pour chaque donne, les deux piles logicielles reprsentes par la gure 8.2 doivent tre instancies sur tous les pairs fournisseurs qui en hbergent une copie. Un exemple de groupe hirarchique de fournisseurs formant un GDG comprenant deux LDG est illustr par la gure 8.3.
GDG LDG
Protocole de cohrence niveau GDG (copie de rfrence globale)
Protocole de cohrence niveau LDG (copie de rfrence locale)
Couche de jonction
Couche de jonction
Groupe autoorganisant (SOG) global Couche dadaptation aux fautes
Groupe autoorganisant (SOG) local Couche dadaptation aux fautes
F IG . 8.2 Piles logicielle instancie sur les pairs fournisseurs pour chaque donne quils hbergent.
106
LDG B
L LDG A
Grappe B
tel-00411447, version 1 - 27 Aug 2009
Client
GDG
Grappe A c Pile logocielle cot client G L Piles logicielles des fournisseurs GDG (G) et LDG (L)
F IG . 8.3 Aperu de larchitecture logicielle : un client et un GDG compos de deux LDG eux-mmes composs de 2 3 pairs fournisseurs.
8.1.2
Les protocoles de cohrence
Les processus applicatifs utilisent linterface de J UX M EM lors des accs aux donnes partages. Cette dernire utilise alors linterface offerte par les protocoles de cohrence 2 , reprsente par le listing 8.1. Listing 8.1 Interface des protocoles de cohrence des clients J UX M EM.
1 2 3 4 5 6 7 8 9 10 11 12
... /* lobjet peer est utilis pour accder aux fonctions du noyau JuxMem */ Jxta_id* cp_alloc(JuxMem_peer* peer, Jxta_vector* local_provider_ids, Jxta_vector* remote_provider_ids, Jxta_id** provider_comm_id, long size, int cp_type, int sog_type); consistency_protocol* consistency_protocol_open(JuxMem_peer* peer, Jxta_id* data_id, Jxta_id* provider_comm_id, long size, char* localkey, void* attributes); /* self reprsent le protocole de cohrence */ Pour une donne particulire, un seul protocole de cohrence est employ. Cependant, pour un mme client, des protocoles de cohrence diffrents peuvent tre utiliss pour des donnes diffrentes.
2

13 14 15 16 17 18 19 20 21 22 23
107
void consistency_protocol_close(consistency_protocol* self); int cp_flush(consistency_protocol* self, void* ptr, size_t size, Jxta_message_element* msg_element_localkey); int cp_acquire(consistency_protocol* self, void* ptr, size_t size, Jxta_message_element* msg_element_localkey); int cp_release(consistency_protocol* self, void* ptr, size_t size, Jxta_message_element* msg_element_localkey); int cp_acquire_read(consistency_protocol* self, void* ptr, size_t size, Jxta_message_element* msg_element_localkey); int cp_get_state(consistency_protocol* self); ...
tel-00411447, version 1 - 27 Aug 2009
Les protocoles de cohrence doivent donc dnir ces diffrentes primitives. Les primitives cp_acquire et cp_acquire_read sont appeles avant chaque entre dans une section de code contenant des accs la donne : cp_acquire lorsque les accs sont en lecture/criture et cp_ acquire_read lorsquils sont en lecture seule. La primitive cp_release est appele la sortie des sections de code contenant des accs la donne. Les autres primitives sont utilises par linterface de J UX M EM pour propager les critures la copie de rfrence locale (cp_ush) ou pour connatre ltat du protocole de cohrence (cp_get_state). Pour mettre en uvre ces primitives, les protocoles de cohrence utilisent les fonctions de linterface de la couche de jonction dont un extrait est prsent dans le listing 8.2. Listing 8.2 Interface de communication offerte par la couche de jonction.
1 2 3 4 5 6 7 8 9 10 11
... /* self reprsente ici la couche de jonction */ int send_lock_request(client_grp_comm* self, Jxta_message* message); int send_lock_read_request(client_grp_comm* self, Jxta_message* message); int send_unlock_request(client_grp_comm* self, Jxta_message* message); int send_unlock_read_request(client_grp_comm* self, Jxta_message* message); int send_read_request(client_grp_comm* self, Jxta_message* message); int send_update_request(client_grp_comm* self, Jxta_message* message); int send_reset_ack(client_grp_comm* self, Jxta_message* message); int set_cp_handler(client_grp_comm* self, consistency_protocol* cp); ...
Il est intressant de remarquer que ces fonctions ne prennent pas en paramtre lidentiant du destinataire du message. En effet, le destinataire est un groupe de copies dont les membres sont susceptibles de changer au cours du temps, lors doccurrences de fautes. Lidentiant du groupe est inconnu au niveau de cette couche. La localisation du groupe et les communications avec ce groupe sont donc la charge de la couche de tolrance aux fautes dont un exemple de mise en uvre est dcrit la section 8.3. Il nest par consquent pas ncessaire de connatre ni la localisation, ni la composition du LDG/GDG au niveau du protocole de cohrence. Le protocole de cohrence client doit galement dnir la manire dont il ragit aux rponses du LDG. Pour ce faire, il doit mettre en uvre les fonctions du listing 8.3 appeles par la couche de jonction lors de la rception dun message de ce dernier. Listing 8.3 Fonctions du protocole de cohrence client appeles lors de la rception dun message de la copie de rfrence locale.
1 2 3
... /* self reprsente ici le protocole de cohrence */ void recv_lock_ack(consistency_protocol* self, Jxta_id* sender,
108
4 5 6 7 8 9 10 11 12 13 14 15 16 17
Jxta_message* message); void recv_lock_read_ack(consistency_protocol* self, Jxta_id* sender, Jxta_message* message); void recv_unlock_ack(consistency_protocol* self, Jxta_id* sender, Jxta_message* message); void recv_unlock_read_ack(consistency_protocol* self, Jxta_id* sender, Jxta_message* message); void recv_update_ack(consistency_protocol* self, Jxta_id* sender, Jxta_message* message); void recv_read_ack(consistency_protocol* self, Jxta_id* sender, Jxta_message* message); void recv_reset_request(consistency_protocol* self, Jxta_id* sender, Jxta_message* message); ...
tel-00411447, version 1 - 27 Aug 2009
La partie des protocoles de cohrence mise en uvre au niveau de la copie de rfrence locale, sur les pairs fournisseurs doit implmenter les fonctions miroirs (recv_ pour chacun des send_) qui seront appeles par la couche de jonction. Elle utilise de plus une interface semblable celle du listing 8.2 an dmettre des requtes la copie de rfrence globale. De la mme manire, la copie de rfrence globale doit implmenter les fonctions recv_ pour chacune des requtes mises par les copies de rfrence locales. ce niveau galement, la couche de jonction propose des fonctions du type send_ permettant la copie de rfrence globale de rpondre aux requtes des copies de rfrence locales. Au niveau de limplmentation dun protocole de cohrence, la tolrance aux fautes est rendue invisible grce ces interfaces. En effet, le protocole de cohrence utilise les fonctions send_ et recv_ de la couche de jonction, masquant la localisation et la composition des groupes pour les communications entre les clients, les copies de rfrences locales et la copie de rfrence globale. Ces trois entits dun protocole de cohrence implmentent le protocole de cohrence hirarchique en mettant en uvre des automates tats semblables ceux prsents dans le chapitre 5. Un exemple de mise en uvre est donne la section 8.2.
8.1.3
Les mcanismes de tolrance aux fautes
La couche de tolrance aux fautes est responsable de la mise en uvre des groupes autoorganisants (SOG, pour langlais Self-Organizing Group). La partie instancie du ct client est responsable de la localisation et de la communication avec le LDG prsent dans la mme grappe, voire de linstanciation dun nouveau LDG sil nen existe pas au sein de la grappe du client. Cest ce niveau que lidentiant du groupe est conserv. La partie instancie au niveau LDG des pairs fournisseurs est responsable de la rplication au sein des LDG, de lauto-organisation des LDG, ainsi que de la localisation et des communications avec le GDG. Enn, la partie instancie au niveau GDG des pairs fournisseurs est responsable de la rplication au niveau global (cest--dire interLDG), ainsi que de lauto-organisation du GDG qui peut entraner lajout et/ou le retrait de LDG. Localisation et communication. Linterface de communication offerte la couche de jonction est simple : elle permet cette dernire denvoyer des messages un groupe et denregistrer une fonction permettant de recevoir et de traiter les messages envoys au groupe. Ces fonctions sont donnes dans le listing ci-dessous.
8.2 Mise en uvre dun protocole de cohrence hirarchique
109
Listing 8.4 Interface de communication offerte par la couche de tolrance aux fautes la couche de jonction.
1 2 3 4
... int grp_send(sog_client_stub* self, Jxta_message* message); int set_msg_evt_handler(sog_client_stub* self, client_grp_comm* handler); ...
tel-00411447, version 1 - 27 Aug 2009
En plus de ces fonctions, des tiquettes ajoutes aux messages permettent la couche de jonction dinuer sur le comportement de la couche de tolrance aux fautes. Par exemple, si ltiquette GRP_COMM est ajoute par la couche de jonction, le message sera distribu aux membres du groupe en utilisant un mcanisme de diffusion atomique. Cette tiquette est donc ajoute chacun des messages modiant ltat du protocole de cohrence (requte de verrouillage, de dverrouillage ou de mise jour de la donne). Ceci assure que tous les membres dun mme groupe appliqueront les mmes mises jour, et ce dans le mme ordre. En revanche, en labsence de cette tiquette, le message ne sera transmis qu lun des membres du groupe. Une requte de lecture de la donne dun client son LDG nengendrera ainsi pas de communication de groupe, mais seulement une communication entre le client et un des pairs fournisseurs appartenant au LDG associ prsent dans la mme grappe. Lajout ou non de cette tiquette se dcide au niveau de la couche de jonction an de prserver la transparence de la rplication au niveau du protocole de cohrence. Les groupes auto-organisants utilisent les interfaces de publication/recherche et de communication du noyau J UX M EM prsente la section 6.1.3. Linterface de publication/ recherche permet de localiser les groupes grce lidentiant de la donne : les clients doivent pouvoir localiser le LDG prsent au sein de leur grappe et les LDG doivent pouvoir localiser le GDG. Linterface de communication du noyau permet au SOG denregistrer une fonction qui sera appele chaque fois quun message concernant la donne pour laquelle il a t instanci est reu.
Auto-organisation des groupes. Les SOG senregistrent galement auprs du service hirarchique de dtection de fautes dont lintgration au service de partage de donnes J UX M EM est prsente la section 7.2.1. En cas de faute dtecte, la fonction int repair(Jxta_id* faulty_peer_id) est appele. Cette fonction a pour rle : 1) dvincer le fournisseur fautif des listes de membres auxquelles il appartient ; 2) de dcider si le fournisseur doit tre remplac ou non ; 3) de le remplacer si cela est ncessaire ; et 4) de mettre jour les informations publies an que le groupe reste localisable par lintermdiaire de linterface de publication/recherche du noyau.

Pour mettre en uvre un protocole de cohrence hirarchique au sein de notre architecture en couche, il est ncessaire de mettre en uvre diffrentes entits : 1) la partie client, 2) la copie de rfrence locale, et 3) la copie de rfrence globale. Nous reprenons ici lexemple du chapitre 5 implmentant le modle de cohrence lentre (dcrit au chapitre 4).
110
NO_LOCK acquire acquire_read
ATTENTE LOCK
acquitement reu
ATTENTE LOCK_R
ATTENTE acquitement reu UNLOCK acquitement reu
tel-00411447, version 1 - 27 Aug 2009
release ON_LOCK
release
ON_LOCK_R
F IG . 8.4 Automate tats reprsentant le protocole de cohrence lentre au niveau du client. Les tats non griss ne bloquent pas lapplication alors que les tats griss correspondent des primitives synchrones.
8.2.1
Mise en uvre sur le client
La partie client du protocole de cohrence doit mettre en uvre la fois linterface prsente J UX M EM, illustre par le listing 8.1, et linterface susceptible dtre appele par la couche de jonction prsente sur le listing 8.3. Un exemple de mise en uvre consiste conserver un tat (possession ou non du verrou en criture/en lecture, tmoin de modication de la donne, version de la donne prsente localement, etc.) et, lorsque lune des fonctions est appele, effectuer une action puis mettre ltat jour. Laction dpend de ltat ainsi que de la fonction appele. Cela permet de mettre en place un automate tats (gure 8.4). Certaines actions (ou transitions de lautomate tats) ncessitent des communications avec la copie de rfrence locale. Celles-ci sont ralises via linterface de communication de la couche de jonction prsente par le listing 8.2. Le listing 8.5 ci-dessous montre un exemple dimplmentation de la fonction appele lorsquun client souhaite acqurir le verrou permettant un accs exclusif la donne. Listing 8.5 Code simpli de lacquisition dun verrou exclusif par le protocole de cohrence client.
1 2 3
int ec_acquire(consistency_protocol* self, void *ptr, size_t size, Jxta_message_element* msg_element_localkey) {

4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
111
tel-00411447, version 1 - 27 Aug 2009
... if (self->impl->state == NO_LOCK) { msg = jxta_message_new(); /* le numro de version est ajout au message */ status = consistency_version_to_msg(self->impl->data_version, msg); /* la requte est envoye la couche de jonction */ send_lock_request(self->impl->comm, msg); ... /* un acquitement est attendu */ jxta_listener_wait_for_event(self->impl->lock_listener, TIME_TO_WAIT, JXTA_OBJECT_PPTR(&obj)); ... /* la donne contenue dans lacquitement est rcupre */ juxmem_to_user_memory_from_message(self->impl->peer, self->impl->data_id, ptr, size, obj); ... /* ltat est mis jour */ self->impl->state = ON_LOCK; } ... }
Si le protocole est dans ltat NO_LOCK (ligne 5), une requte dobtention de verrou est mise au LDG (ligne 10) via la couche de jonction, puis un acquittement du LDG est attendu (lignes 13 et 14) avant de mettre la donne et ltat jour (lignes 17 et 22). Les autres transitions sont implmentes selon le mme principe. Lautomate tats reprsent par la gure 8.4 montre que, lors de la mise en uvre du protocole de cohrence lentre sur le client, il nest pas ncessaire davoir connaissance ni de la rplication, ni de la mise en uvre hirarchique du protocole de cohrence. Nous avons remarqu la section prcdente que la couche jonction rendait la rplication transparente au niveau du protocole de cohrence. Cela permet notamment de pouvoir remplacer facilement la couche de tolrance aux fautes et de conserver le protocole de cohrence intact. La hirarchie est galement transparente pour le protocole de cohrence sur le client : tout se passe comme si la copie de rfrence locale laquelle il accde tait la seule et unique copie de rfrence.
8.2.2
Mise en uvre sur les fournisseurs
Nous avons mentionn la section 8.1 que notre implmentation hirarchique exige que chaque fournisseur possdant une copie dune donne instancie la fois la partie du protocole de cohrence implmentant la copie de rfrence locale et celle implmentant la copie de rfrence globale. Copie de rfrence locale. La mise en uvre dune copie de rfrence locale ncessite limplmentation des fonctions susceptibles dtre appeles par la partie communication de la couche de jonction, cest--dire les fonctions correspondant la rception de messages dun client ou de la copie de rfrence globale. Une copie de rfrence locale se comporte comme un automate tats, semblable celui reprsentant le comportement de la copie de rfrence du protocole de cohrence lentre
112
prsent au chapitre 5. De mme que pour la partie client du protocole de cohrence, sa ralisation peut tre effectue en maintenant un tat et en effectuant des actions chaque fois quun message provenant de la copie de cohrence globale ou dun client est reu. Dans le cas de la copie de rfrence locale, ltat de lautomate est cependant plus complexe, il contient notamment lidentiant du client possdant le verrou, et les listes suivantes : 1) une liste de clients en attente du verrou exclusif (L pour Lock) ; 2) une liste de clients en attente du verrou en lecture (LR pour Lock Read) ; 3) une liste de clients possdant le verrou en lecture (OLR pour On Lock Read). Linterface de communication de la couche de jonction permet la copie de rfrence locale denvoyer des messages aux clients (par exemple des acquittements de requtes de demandes de verrous) ou la copie de rfrence globale (par exemple une demande de verrou).
tel-00411447, version 1 - 27 Aug 2009
Copie de rfrence globale. La mise en uvre dune copie de rfrence globale seffectue en implmentant les fonctions susceptibles dtre appeles par la couche de jonction. Elles correspondent larrive de diffrents types de message mis par une copie de rfrence locale. Dans notre mise en uvre du protocole de cohrence lentre, la copie de rfrence globale se comporte comme une copie de rfrence locale deux diffrences prs : 1) la copie de rfrence globale communique avec des copies de rfrence locales, et non avec des clients ; et 2) la copie de rfrence globale tant au dernier niveau de la hirarchie, elle ne communique pas avec un niveau suprieur.
8.2.3
Fonctionnement
La gure 8.5 illustre le fonctionnement du protocole de cohrence hirarchique. Deux clients accdent une mme donne partage via leur copie de rfrence locale. On remarque que certaines actions ne font intervenir que la partie client du protocole de cohrence (1a). Cela peut tre par exemple la lecture dune donne prsente localement. Dautres actions, comme lacquisition dun verrou, font intervenir la copie de rfrence locale (1b et 2b). Il est possible que la copie de rfrence locale doive contacter la copie de rfrence globale pour satisfaire certaines requtes (1c, 2c, 3c et 4c). Cela peut tre le cas lors dune demande de verrou par le client (1c), si la copie de rfrence locale ne possde pas ce verrou. Dans ce cas, elle le demande la copie de rfrence globale (2c) qui soit le possde, soit attend quune autre copie de rfrence locale le libre. Quand le verrou est en possession de la copie de rfrence globale, elle le retourne la copie de rfrence locale (3c) qui le transmet son tour au client qui en avait fait la demande (4c). Pour cet exemple, nous navons pas pris en compte la rplication engendre par les mcanismes de tolrance aux fautes. La copie de rfrence globale peut se situer sur le mme nud que lune des copies de rfrence locales, ou sur un nud diffrent au sein dune des deux grappes ou encore dans une grappe tierce. Avec notre mise en uvre de groupes hirarchiques, dtaille la section suivante, la copie de rfrence globale est rplique sur tous les nuds du systme hbergeant une copie de rfrence locale.
8.3 Mise en uvre des groupes auto-organisants
113
2c 3c
Copie de rfrence globale 3c
2c
Copie de rfrence locale 2b 1b Client 4c 1c
Copie de rfrence locale 1c 4c 1b Client 2b
1a
1a
F IG . 8.5 Fonctionnement du protocole de cohrence hirarchique.

Copie de rfrence globale rplique
tel-00411447, version 1 - 27 Aug 2009
Copie de rfrence locale rplique
Copie de rfrence locale rplique
LDG1
LDG2
GDG Client 1 Client 2
F IG . 8.6 Correspondance entre les copies de rfrence locales/globale et des groupes autoorganisants LDG/GDG.

Les copies de rfrences locales et globales sont rpliques. Chaque LDG hberge une copie de rfrence locale rplique, et chaque GDG hberge une copie de rfrence globale rplique. La gure 8.6 illustre cette correspondance. Le rle des groupes auto-organisants, ou SOG, est dassurer la persistance des copies de rfrence en prsence de fautes.
8.3.1
Mise en place de la rplication
Les groupes de copies sont initialement crs lors de lallocation dune nouvelle donne au sein de J UX M EM. Les messages envoys aux groupes sont alors traits de manire conserver les diffrentes copies cohrentes. Allocation. Lorsquun processus applicatif souhaite allouer de lespace pour une donne au sein de J UX M EM, il doit fournir le degr de rplication souhait : dans combien de grappes la donne doit tre prsente, et, dans chacune de ces grappes, combien il doit y avoir de
114
copies de la donne. Il est possible de demander ce quil ny ait quune copie dans la grappe du processus, dans ce cas aucune garantie de tolrance aux fautes nest offerte. Le noyau J UX M EM cherche alors autant de pairs fournisseurs que ncessaire. Les mcanismes mettant en uvre cette recherche sont dtaills dans [64]. Quand les pairs fournisseurs ont t trouvs, avant dinstancier la pile logicielle cot client, des requtes dallocation sont envoyes chacun des fournisseurs slectionns. Chaque requte contient la liste des fournisseurs slectionns sous forme dune liste contenant les listes des fournisseurs de chaque groupe. Ces listes sont utilises pour initialiser les listes de membres des groupes. Dans la mise en uvre prsente ici, un nud appel nud srialisateur ordonnance les messages pour son groupe. linitialisation, pour chaque groupe, le fournisseur apparaissant en premier sur la liste reue est considr comme nud srialisateur. Quand les piles logicielles ont t instancies sur les fournisseurs, ceux-ci retournent des acquittements au client ayant effectu la requte dallocation. Le client reste bloqu dans lattente de tous les acquittements3 . Quand tous les acquittements attendus ont t reus, la pile logicielle client pour cette donne est instancie et le processus applicatif ayant appel la primitive dallocation est dbloqu.
tel-00411447, version 1 - 27 Aug 2009
Communication de groupe. Conserver la cohrence des diffrentes copies dun groupe alors que des accs concurrents sont effectus ncessite dordonnancer les accs. En effet, si toutes les copies sont modies par les mmes actions, et ce dans le mme ordre, elles volueront toutes de la mme manire. La diffusion atomique des messages dnie la section 3.3.2 garantit que tous les messages envoys un groupe seront pris en compte par chacun des membres de ce groupe dans le mme ordre. Plusieurs implmentations de la diffusion atomique existent. Au chapitre 5, nous avons dcrit un mcanisme de diffusion atomique sappuyant sur un algorithme de consensus utilis pour dcider de lordre de prise en compte des messages. Nous prsentons ici une autre mise en uvre consistant utiliser un nud srialisateur qui a la responsabilit de dterminer cet ordre pour les autres nuds en numrotant tous les messages de diffusion. Ainsi, pour chaque groupe, un nud srialisateur est choisi. Tous les messages destins au groupe lui sont adresss. Il a en charge de les diffuser au groupe de manire ce que chacun des membres les traitent dans le mme ordre. Avant dacquitter le message lmetteur, le nud srialisateur attend quune majorit des membres de son groupe en ait acquitt la diffusion. En cas de dfaillance du nud srialisateur, au moins la moiti des autres membres ont une copie jour. De plus, dans notre mise en uvre, les listes de membres sont ordonnes de la mme manire sur chacun des membres4 : cela permet de choisir le prochain membre non-dfaillant dans la liste comme nouveau nud srialisateur. Le nouveau nud srialisateur diffuse alors un message pour rcuprer les numros de version de chaque copie an de pouvoir re-propager la ou les mises jour ncessaires. Durant un changement de nud srialisateur, le groupe est inaccessible. Quand les ventuelles mises jour ncessaires ont t propages, le nud srialisateur publie son identiant rendant ainsi le groupe nouveau accessible.
Un mcanisme de dlai de garde est utilis an de supporter les fautes lors de lallocation. lallocation elles sont initialises dans le mme ordre, et chaque ajout/retrait seffectue via une diffusion atomique.
4 3
115
4
G mission dun message au GDG acquittement du message L
4 3 3
LDG B
2 4 5
Grappe B
L LDG A L
5 4
G
3 2 4 6
GDG
tel-00411447, version 1 - 27 Aug 2009
Grappe A
F IG . 8.7 Diffusion des messages envoys aux GDG.
La gure 8.7 reprsente la diffusion au sein des GDG. Les membres de ces groupes sont eux-mmes des groupes : les LDG. Le mcanisme de diffusion des messages au sein des GDG est le mme que celui des LDG, la diffusion au sein dun GDG est donc hirarchique. 1. Le nud srialisateur du GDG (qui est le nud srialisateur du LDG srialisateur du GDG) diffuse les messages tous ses membres, cest--dire les LDG, donc les nuds srialisateurs des LDG (2) ; 2. les nuds srialisateurs des LDG diffusent les messages leurs membres (3) et attendent des acquittements, comme dcrit ci-dessus (4) ; 3. les nuds srialisateurs des LDG acquittent les messages ds quils ont reus sufsamment dacquittements (5) ; 4. le GDG peut alors considrer le message comme diffus, et lacquitter (6).
8.3.2
Auto-organisation des groupes
En cas de faute, les groupes doivent se r-organiser an de pouvoir continuer assurer les mmes garanties de tolrance aux fautes. De nouveaux fournisseurs peuvent alors remplacer les fournisseurs dfaillants. Comme expliqu la section 8.1.3, les groupes sont prvenus des fautes par lintermdiaire de dtecteurs de fautes. Lorsquune faute est dtecte, le nud srialisateur (ou le nouveau nud srialisateur en cas de dfaillance du nud srialisateur lui-mme) diffuse de manire atomique la dcision dvincer le nud fautif tout le groupe. Cela permet dassurer le changement de vue. Une recherche est ensuite lance an de remplacer le fournisseur dfaillant. Entre temps, le groupe continue son fonctionnement avec un membre en
116
moins. Quand le nouveau fournisseur est trouv, le nud srialisateur gle les communications du groupe le temps dintroduire le nouveau membre. Les requtes arrivant sont alors mises en attente sur chacun des membres du groupe, le temps que la rparation se termine. Celle-ci comprend le transfert de ltat du protocole de cohrence ainsi que de la donne sur le nouveau membre, et la diffusion de la nouvelle liste de membres lensemble du groupe. Il est ainsi possible de tolrer un trs grand nombre de fautes, suprieur la taille initiale des groupes, condition que les occurrences de fautes ne soient pas trop frquentes et que les groupes aient le temps de se recongurer.
8.4 Un protocole tendu pour une visualisation efcace

Larchitecture en couches que nous avons dnie permet au service J UX M EM de proposer plusieurs protocoles de cohrence ainsi que plusieurs mcanismes de tolrance aux fautes. Les clients peuvent alors slectionner la combinaison de leur choix pour chaque donne partage. An dillustrer ceci, nous prsentons ici un nouveau protocole de cohrence, qui constitue une extension de celui prsent la section 8.2. Ce protocole a t conu et mis en uvre en collaboration avec Loc Cudennec lors de son stage de master recherche que nous avons co-encadr. Le but de ce nouveau protocole est de permettre lobservation des donnes partages en cours dexcution de lapplication les utilisant. Les application scientiques sexcutant sur les grilles de calcul peuvent durer des jours, voire des semaines, et il nest pas souhaitable den attendre la n pour vrier que tout sest bien pass. Des donnes peuvent tre partages entre les codes an de renseigner sur ltat davancement du calcul. Lobservation dun calcul doit seffectuer avec des temps daccs courts tout en causant le moins dinteractions possibles avec les autres sites pour minimiser les perturbations. Plus spciquement, nous nous intressons lobservation des donnes intermdiaires dans une application base de couplage de codes. Nous proposons donc une extension du protocole de cohrence prsent la section 8.2 qui introduit la possibilit deffectuer des lectures en parallle dune criture en relchant les garanties de cohrence pour ces lectures dun genre particulier (dtailles ci-dessous). Ceci est possible si lobservateur accepte dexploiter des donnes dont la version est considre comme ancienne. Cette extension du protocole a pour consquence une extension du modle de cohrence utilis. Une mise en uvre de cette stratgie a t effectue au sein du service J UX M EM.
tel-00411447, version 1 - 27 Aug 2009
8.4.1
La lecture relche
Le scnario considr met en uvre un nud observateur dont le rle est de lire la donne partage avec des temps daccs courts sans pour autant dgrader les performances des nuds effectuant les calculs. La premire ide consiste utiliser des copies de la donne ventuellement anciennes, dtenues par le client ou son LDG. Cette stratgie permet dexploiter des donnes dj prsentes sur le client ou trs proches en terme de distance rseau (au sein de la mme grappe). La deuxime ide vise diminuer les temps dattente lis la contention impose par le protocole de cohrence en ne prenant plus le verrou en lecture. Une consquence directe est dautoriser ces lectures dun genre particulier en mme temps
8.4 Un protocole tendu pour une visualisation efcace
117
que les critures. Nous appelons ces oprations des lectures relches, et la primitive associe rlxRead. Le modle de cohrence lentre ne garantit quune donne soit jour que lors de lacquisition de son verrou. Dans ce modle, pour un observateur qui nacquiert pas le verrou, le fait dutiliser la donne contenue dans son propre cache ou celle disponible sur son LDG ne peut garantir que la donne soit jour. Lapproche que nous considrons propose dautoriser ce type de lecture non-synchronise tout en contrlant la fracheur de la donne. Ceci est possible en bornant lcart entre la version retourne et la version la plus rcente. Ainsi pour chaque lecture relche, lapplication spcie le nombre de versions de retard autorises avant quune donne ne soit considre comme prime.
8.4.2
Fentre de lecture
Pour exprimer le retard entre la version la plus rcente et celle retourne par la lecture relche, nous introduisons deux paramtres qui prennent en compte les deux niveaux de hirarchie du protocole de cohrence. La constante D, propre chaque donne, exprime le nombre de fois que le LDG peut transmettre successivement le verrou en criture, sans effectuer de mise jour du GDG. Si D = 0 alors le LDG doit propager les modications aprs chaque relchement du verrou en criture. Dans ce cas, tous les LDG ont la mme version de la donne. Le paramtre w est spci par le client lors de chaque appel la primitive de lecture relche rlxRead. Cest la taille de la fentre de lecture. Il exprime lcart tolr entre la version la plus rcente et celle retourne par la lecture relche au niveau des LDGs. Les distances D et w sont positives ou nulles et respectent le fait que w soit suprieur ou gal D. La diffrence w D correspond la distance maximale entre la version dtenue par le LDG du client et celle retourne par la lecture relche. A titre dexemple, si D = 3 alors un LDG pourra distribuer successivement le verrou en criture au plus 3 fois sans propager les modications tous les membres du GDG. Si w = 4, la version de la donne lue par un client effectuant une lecture relche retourne soit la dernire version de la donne dtenue par son LDG, soit la version prcdente. La notion de dernire version fait rfrence la dernire version propage par le LDG ayant le verrou en criture, cest--dire quelle peut dj tre ancienne de D versions.
tel-00411447, version 1 - 27 Aug 2009
8.4.3
Analyse de la smantique des paramtres
Considrer w = D implique que le client lise la mme version que celle dtenue par son LDG. Notons que xer D = 0 et w = 0 ne revient pas pour autant effectuer une lecture avec prise du verrou et ce, pour deux raisons. 1) lors de la lecture relche, le verrou en criture peut de nouveau tre distribu et la donne tre en cours de modication. Ceci nest pas autoris dans le modle de cohrence lentre. 2) Entre le moment o le LDG rpond une requte de lecture relche et celui o le client utilise effectivement la donne, un nombre non contrl de versions a pu tre produit. Cette approche convient des applications de type visualisation mais noffre pas de garanties strictes sur la fracheur des donnes, le contrle de la fracheur est fait au mieux (best effort). Lorsquun LDG (dont la version de la donne est note VLDG ) reoit une demande de lecture relche (de fentre w) de la part dun client C (dont la version de la donne est V c ), la formule permettant de dcider si le client peut utiliser sa version de la donne (Vc ) est :
118
Vc VLDG (w D). Lutilisation de la donne dtenue par le client rduit le cot rseau de la lecture. Dans le cas contraire, la donne du LDG est transfre au client. La lecture relche donne lieu une extension du modle de cohrence : le modle de cohrence lentre y est toujours respect et garantit daccder la version la plus rcente de la donne lorsque le verrou est acquis. La lecture relche apporte des garanties supplmentaires l o la cohrence lentre nen donne pas. Ainsi la lecture dune valeur sans la prise du verrou nest-elle plus compltement incontrle. Les valuations de performances que nous avons menes (voir 9.2.3) montrent que lextension propose ici permet damliorer signicativement les latences des accs lors des observations dune donne partage tout amliorant dans une moindre mesure celles des accs des nuds effectuant les calculs.
8.5 Analyse
La plate-forme logicielle J UX M EM est un prototype de recherche en cours de mise en uvre, une thse tant en cours sur lvolution de J UX M EM. Grce notre architecture logicielle, cette plate-forme permet la mise en place aise de nouveaux protocoles de cohrence et de nouveaux mcanismes de tolrance aux fautes. Elle peut donc tre utilise comme une plate-forme exprimentale pour tester de nouveaux mcanismes et les comparer entre eux. Dans ce chapitre nous avons donn un aperu de la mise en uvre de larchitecture en couches et de la manire dont il est possible de mettre en uvre de nouveaux protocoles de cohrence et de nouveaux mcanismes de tolrance aux fautes. En utilisant limplmentation actuelle, il est possible pour une application de choisir diffrents protocoles de cohrences pour des donnes diffrentes, la cohrence lentre ou la cohrence lentre tendue par exemple. Dans le chapitre suivant, nous montrons une valuation comparative de ces deux protocoles dans le cas particulier de la visualisation dune donne partage. La description des mcanismes de diffusion utiliss pour la rplication des copies de rfrence met en vidence le cot, en terme de latence, que peuvent avoir de tels mcanismes. Les mcanismes de tolrance aux fautes risquent donc de ralentir lapplication. Cependant, en prsence de fautes, ces mcanismes lui permettent de continuer son excution. Il semble important de trouver le bon compromis entre le cot des mcanismes utiliss et le risque dapparition de fautes durant lexcution de lapplication. Cest pourquoi notre prototype permet de choisir les mcanismes utiliss ainsi que le degr de rplication. Le chapitre suivant apporte un dbut de rponse la recherche de ce compromis en donnant une valuation du cot des mcanismes de tolrance aux fautes de la plate-forme J UX M EM.
tel-00411447, version 1 - 27 Aug 2009
119
Chapitre
valuation
tel-00411447, version 1 - 27 Aug 2009
Sommaire
9.1 Mthodologie dexprimentation . . . . . . . . . . . . . . . . . . . . . . . . 120 9.1.1 9.1.2 9.2 9.2.1 9.2.2 9.2.3 9.2.4 9.3 Exprimentations sur architectures relles . . . . . . . . . . . . . . . . 120 Injection de fautes de type panne franche . . . . . . . . . . . . . . . . 121 Cot d la rplication . . . . . . . . . . . . . . . . . . . . . . . . . . 122 Bnce de lapproche hirarchique . . . . . . . . . . . . . . . . . . . 126 valuations multi-protocole . . . . . . . . . . . . . . . . . . . . . . . . 129 Impact des fautes sur les performances . . . . . . . . . . . . . . . . . 130
Exprimentations avec J UX M EM . . . . . . . . . . . . . . . . . . . . . . . . . 121
Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Nos approches pour la gestion conjointe de la tolrance aux fautes et de la cohrence des donnes au sein des grilles de calcul prsentes dans ce manuscrit ont fait lobjet dune mise en uvre dont un aperu est donn au chapitre 8. Dans ce chapitre, nous donnons une valuation de cette mise en uvre. Dans un premier temps nous discutons de notre mthodologie dexprimentation. En effet, lvaluation de systmes tolrants aux fautes pose certains problmes, comme la difcult deffectuer des mesures reproductibles en prsence de fautes. Nous prsentons dans la section 9.2 une valuation de notre contribution au sein de la plate-forme J UX M EM. Nous mesurons notamment le cot engendr par les mcanismes de tolrance aux fautes en absence de fautes, mais aussi le gain ralis grce notre approche hirarchique pour la mise en place de protocoles de cohrence tolrants aux fautes. Une valuation comparative de deux protocoles de cohrence illustre lintrt dune plate-forme multi-protocole. Enn, nous mesurons le surcot engendr en cas doccurrences de fautes.
120
Chapitre 9 valuation
9.1 Mthodologie dexprimentation

Il existe de multiples mthodes permettant dvaluer des systmes : les preuves formelles, les simulations et enn les exprimentations. Ces mthodes ne prsentent pas toutes les mmes avantages et inconvnients.
Preuves formelles et simulations. Ces deux mthodes prsentent linconvnient dvaluer un modle du systme et non le systme lui-mme1 . Les modles de systmes sont une simplication des systmes rels et leur valuation ne donne quune ide du comportement du systme rel. En revanche, les preuves formelles permettent souvent de prendre en compte tous les cas, ce qui est rarement le cas pour les simulations ou les exprimentations sur les systmes rels. Les simulations quant elles prsentent lavantage non ngligeable de pouvoir tre ralises assez rapidement.
tel-00411447, version 1 - 27 Aug 2009
9.1.1
Exprimentations sur architectures relles
Les exprimentations de systmes sur des architectures relles permettent dvaluer le comportement du systme dans des conditions relles. De plus, elles permettent aux dveloppeurs de mettre au point les systmes et de les optimiser. Ce type dvaluation est nanmoins plus difcile et plus long mettre en uvre. Dans le cas des exprimentations sur des plates-formes distribues telles que les grilles de calcul, il est gnralement ncessaire dutiliser des outils de rservation de ressources (nuds), de dployer le systme sur les nuds obtenus, de lancer le systme et enn de rcuprer les rsultats rpartis sur lensemble des nuds utiliss. Dans ce contexte, exprimenter des mcanismes de tolrance aux fautes ajoute la difcult : il devient alors ncessaire de pouvoir contrler les fautes an dvaluer les mcanismes mis en place pour y faire face. Nous avons expriment notre service de partage de donnes pour la grille J UX M EM sur la plate-forme Grid5000 [113, 26]. Pour ce faire, nous avons utilis des prototypes de recherche pour les rservations de nuds (OAR [121] et OARGRID [122]) ainsi que pour le dploiement (ADAGE [74]). OAR et OARGRID. OAR est un outil de gestion de ressources fond sur MySQL [120]. Il permet de rserver des nuds et de lancer des excutions au sein dune grappe. Cet outil est prsent sur chacune des grappes de Grid5000. OARGRID utilise OAR sur plusieurs grappes an doffrir une gestion de ressources au niveau de la grille. ADAGE est un outil de dploiement gnrique dapplications distribues et/ou parallles sexcutant sur les grilles de calcul. ADAGE dispose dun greffon (en anglais plugin) pour le dploiement dapplications bases sur JXTA [64]. Nous avons mis en uvre un outil dinjection de fautes permettant dvaluer la raction aux fautes de notre mise en uvre. Cet outil est prsent la section suivante.
Mme si certains simulateurs permettent dexcuter le code du systme exprimenter, larchitecture matrielle utilise est modlise et simule.
1
9.2 Exprimentations avec J UX M EM
121
9.1.2
Injection de fautes de type panne franche
Lvaluation des mcanismes de tolrance aux fautes requiert des exprimentations en prsence de fautes. En effet, des excutions sans fautes permettent uniquement de mesurer le surcot ventuel que ces mcanismes engendrent. Notre but est donc de pouvoir engendrer et contrler les fautes survenant dans le systme. Nous considrons que la plate-forme de test est stable (sans fautes). En cas de faute relle (non contrle/injecte), le test est considr comme avort et doit tre relanc. Nous avons mis au point un outil permettant dinjecter des dfaillances franches de nuds. Les proprits offertes par cet outil sont la reproductibilit, la prcision et le passage lchelle. Reproductibilit. Comparer des mcanismes de tolrance aux fautes dans des conditions similaires ncessite de pouvoir galement reproduire les conditions de fautes. Il semble donc judicieux quun injecteur de fautes offre la proprit de reproductibilit. Cela peut galement permettre deffectuer de multiples fois le mme test an dobtenir une valeur moyenne, un cart-type, etc. Notre outil calcule un calendrier de fautes avant le dploiement du systme. Ce calendrier peut ainsi tre utilis de multiples fois par la suite. Prcision. Au sein dun systme distribu, tous les nuds ne jouent pas ncessairement le mme rle. Nous avons notamment dcrit notre mcanisme de rplication bas sur un nud srialisateur au chapitre 8. La dfaillance dun nud srialisateur nest pas gre de la mme manire que la dfaillance dun nud non-srialisateur : la premire entrane notamment le choix dun nouveau nud srialisateur pour le groupe de rplication. Un injecteur de fautes doit pouvoir permettre de dterminer nement quels nuds vont tre dfaillants et quand. Notre outil est intgr dans lenvironnement de test JDF (JXTA Distributed Framework [114]) qui utilise la notion de prol (reprsentant des nuds ou groupes de nuds) an de dcrire efcacement lensemble des nuds intervenant lors du test. Nous avons tendu le langage de description de cet environnement an de permettre la description de dpendances, entre prols. Cela offre la possibilit dinjecter des fautes corrles. Par exemple tous les nuds dun mme prol peuvent tre dfaillant simultanment. Le calendrier calcul peut ensuite tre rafn nud par nud. Passage lchelle. Dnir une date de dfaillance pour chaque nud, un par un, peut savrer long lorsque le nombre de nuds est grand. An de pouvoir gnrer un calendrier de fautes pour de nombreux nuds, notre injecteur de fautes peut sappuyer sur des distributions statistiques, typiquement, une distribution exponentielle paramtre par un temps interfaute moyen (MTBF pour Mean Time Between Failures). Notons que lutilisation dune telle distribution ne nuit en rien la proprit de reproductibilit : le calendrier est calcul en utilisant la distribution puis peut tre utilis volont. Plus de dtails sur notre dans [MB06] et [ABJM04]. outil dinjection de fautes peuvent tre trouvs
tel-00411447, version 1 - 27 Aug 2009

Lensemble des exprimentations dcrites ci-dessous a t ralis sur la plate-forme Grid5000 [113, 26], notamment sur les grappes de Nancy (G1), Orsay (G2) et Rennes (G3).
122
Dans lensemble de ces grappes, les machines utilises sont quipes de bi-processeurs Opteron dAMD cadencs 2,0 GHz, munis de 2 Go de mmoire vive et excutant la version 2.6 du noyau Linux. Le rseau utilis au sein de chacune de ces grappe est Gigabit Ethernet. Les grappes sont relies entre elles par le rseau Renater [125]. Les latences entre ces diffrentes grappes sont reprsentes par le tableau 9.1. Rennes - Nancy 6 s Rennes - Orsay 4.5 s Nancy - Orsay 3 s
TAB . 9.1 Latence entre les grappes utilises. Toutes les exprimentations ont t ralises avec la version C de J UX M EM lexception de celles de la section 9.2.3 qui ont t ralises avec la version Java pour des raisons de disponibilit de code. Pour ces exprimentations, chaque nud hberge un seul pair J UX M EM. Bien que J UX M EM soit un service prvu pour tre utilis par des applications partageant de nombreuses donnes sur de nombreux nuds, pour toutes les valuations prsentes ici, nous observons le comportement de J UX M EM au niveau dune donne partage. Le nombre de nuds intervenant dans les exprimentations est donc limit.
tel-00411447, version 1 - 27 Aug 2009
9.2.1
Cot d la rplication
Le but de cette premire srie dexprimentations est dvaluer le surcot d la tolrance aux fautes tel quobserv par les applications (les clients J UX M EM). Nous mesurons donc les cots des accs une donne partage pour diffrents degrs de rplication et diffrentes tailles de donnes. Le type de rplication utilis est semi-actif, il correspond celui fond sur un nud srialisateur dcrit au chapitre prcdent. Description. Nous utilisons ici 3 grappes dans lesquelles nous crons 3 groupes cluster J UX M EM. Chacun des groupes cluster contient 1 pair gestionnaire et 7 pairs fournisseurs. Le groupe cluster correspondant la grappe G3 localise Rennes hberge de plus 1 pair client. An dviter le bruit qui serait introduit dans nos mesures par des attentes sur des verrous, ce pair est le seul a accder la donne, squentiellement, alternant lectures et critures. An que les lectures engendrent les transferts de donnes, ce client projette (map) 2 fois la donne dans sa mmoire locale : une fois pour les lectures et une fois pour les critures. Tout se passe donc comme sil y avait 2 clients parfaitement synchroniss effectuant des lectures et critures tour de rle. Une lecture correspond la prise du verrou en lecture (acquire_read), la rcupration de la valeur de la donne et la libration du verrou (release). Une criture correspond la prise du verrou en criture (acquire), lcriture de la donne (memset) et la libration du verrou avec propagation de la donne (release). Nous mesurons les performances des lectures et critures avec des donnes de taille comprise entre 1 ko et 64 Mo (1 Mo dans la majorit des cas) en faisant varier la taille du GDG (Global Data Group) de 1 3 LDG (Local Data Group), et la taille des LDG de 1 7 fournisseurs (gures 9.1, 9.2, 9.3, 9.4, 9.5 et 9.6). Chaque courbe reprsente les latences pour un degr de rplication, not sous la forme nombre de grappes nombre de fournisseurs par grappe.

1000 Latence des oprations (en ms) 1x1 1x2 1x3 1x5 1x7
123
100
10
1 1 ko
4 ko
16 ko
64 ko 256 ko 1 Mo Taille de la donne
4 Mo
16 Mo
64 Mo
tel-00411447, version 1 - 27 Aug 2009
F IG . 9.1 Latences des oprations de lecture en fonction de la taille de la donne et du nombre de fournisseurs dans une grappe.
60 50 40 30 20 10 2x1 2x2 2x3 2x5
Latence des oprations (en ms)
1 ko
4 ko
16 ko 64 ko Taille de la donne
256 ko
1 Mo
F IG . 9.2 Latences des oprations de lecture en fonction de la taille de la donne et du nombre de fournisseurs rpartis dans 2 grappes. Lectures. Les gures 9.1, 9.2 et 9.3 prsentent les latences des lectures dune donne rplique dans respectivement 1, 2 et 3 grappes. Ces gures montrent que le surcot de la rplication au sein des grappes (LDG) sur les oprations de lecture de donnes de grande taille est restreint : il est infrieur 3% ds que la taille de la donne dpasse 1 Mo. Pour les donnes de petites taille, ce surcot est toutefois important : 4 ms pour une donne de 1 ko. Ces rsultats sexpliquent par le fait que les oprations de lecture ne font intervenir les mcanismes de rplication que pour les oprations de synchronisation acquire_read et release. La donne est transfre partir dun seul nud fournisseur. Aussi, plus la donne est grande, plus le surcot introduit par la rplication lors des oprations de synchronisation est ngligeable par rapport au temps de transfert de la donne du fournisseur au client. En revanche pour les donnes de petite taille, le cot engendr par les changes entre les
124
60 50 40 30 20 10
3x1 3x2 3x3 3x5
1 ko
4 ko
256 ko
1 Mo
tel-00411447, version 1 - 27 Aug 2009
F IG . 9.3 Latences des oprations de lecture en fonction de la taille de la donne et du nombre de fournisseurs rpartis dans 3 grappes. fournisseurs lors des oprations de synchronisation est non ngligeable. Les oprations de synchronisation acquire_read et release engendrent des communications de groupe comme dcrit la section 8.3.
1x1 1x2 1x3 1x5 1x7
1000
100
10
1 1 ko
4 ko
16 ko
64 ko 256 ko 1 Mo Taille de la donne
4 Mo
16 Mo
64 Mo
F IG . 9.4 Latences des oprations dcriture en fonction de la taille de la donne et du nombre de fournisseurs dans une grappe.
critures. Les gures 9.4, 9.5 et 9.6 prsentent les latences des critures dune donne rplique dans respectivement 1, 2 et 3 grappes. Pour les oprations dcriture, le cot de la rplication au sein dune grappe est lev : le simple ajout dune copie fait plus que doubler les temps dcriture de la donne (gure 9.4, courbes 11 et 12). Ce surcot est essentiellement d au temps de transfert de la donne sur le deuxime fournisseur et lattente de son acquittement : la donne est dabord transfre du client vers le fournisseur jouant le rle de

100 90 Latence des oprations (en ms) 80 70 60 50 40 30 20 10 1 ko 4 ko 16 ko 64 ko Taille de la donne 256 ko 1 Mo
125
2x1 2x2 2x3 2x5 1x5 (pour comparaison)
tel-00411447, version 1 - 27 Aug 2009
F IG . 9.5 Latences des oprations dcriture en fonction de la taille de la donne et du nombre de fournisseurs rpartis dans 2 grappes.
3x1 3x2 3x3 3x5 1x5 (pour comparaison)
100 Latence des oprations (en ms) 80 60 40 20
1 ko
4 ko
256 ko
1 Mo
F IG . 9.6 Latences des oprations dcriture en fonction de la taille de la donne et du nombre de fournisseurs rpartis dans 3 grappes. srialisateur, puis de ce premier fournisseur vers le deuxime. En revanche, lajout de copies supplmentaires est bien moins coteux. Le nud srialisateur nattend pas dacquittement de tous les membres, mais seulement dune majorit dentre eux. Ainsi, dans le cas 1 3, un acquittement peut-tre retourn au client avant que la donne nest t transfre compltement sur le troisime fournisseur. Lors de nos exprimentations, nous avons observ une diffrence de lordre de 5% pour des donnes de 1 Mo entre lutilisation de n et de n + 1 fournisseurs, pour n > 1. Les gures 9.5 et 9.6 montrent que le surcot de la rplication intragrappe est ngligeable par rapport au surcot de la rplication intergrappe. En effet, les mcanismes de rplication intergrappe utilisent les liens rseau reliant les grappes entre elles. Ces liens ont une latence bien plus leve que ceux prsents au sein des grappes. Cependant, la srie dexprimenta-
126
tion suivante montre lintrt de la prsence de copies de la donne dans chaque grappe o des clients sont susceptibles dy accder.
9.2.2
Bnce de lapproche hirarchique
Notre approche hirarchique prsente au chapitre 7 permet de limiter lutilisation des liens rseau intergrappe au prot des liens rseau intragrappe de plus faible latence. Elle permet chaque client davoir accs une copie de rfrence locale situe dans la mme grappe. Le but de cette srie dexprimentations est dvaluer le bnce dune telle approche. Pour raliser ces tests, nous faisons correspondre un groupe cluster J UX M EM lensemble des trois grappes an de masquer la hirarchie de la grille au niveau de notre architecture en couches. Intrt des copies de rfrence locales. Cette exprimentation pour but de mettre en vidence lintrt de la prsence dune copie de rfrence locale dans la grappe dun client accdant la donne hberge par cette copie. Nous supprimons donc les fournisseurs situs dans la mme grappe que le client (G3) et mesurons le cot des lectures et critures du client lorsque le GDG ne contient quun LDG lui mme compos dun seul fournisseur. Le client accde donc une copie de rfrence non rplique et non hirarchique situe dans une grappe distante (G1 lors de ces tests). Les mesures sont prsentes par la gure 9.7.
100 90 80 Latence des oprations (en ms) 70 60 50 40 30 20 10 1 ko 4 ko 16 ko 64 ko Taille de la donne 256 ko 1 Mo Lectures critures
tel-00411447, version 1 - 27 Aug 2009
F IG . 9.7 Latences des oprations faisant intervenir un fournisseur distant en fonction de la taille de la donne. Si lon compare ces rsultats avec ceux obtenus lors de la srie de test prcdente lorsquun fournisseur unique (cas 1 1) prsent dans la grappe G3 hbergeait la copie de rfrence, on saperoit que la latence des accs aussi bien en lecture quen criture est augmente. Le tableau 9.2.2 reprend les temps de lecture et dcriture pour ces deux cas. Les latences des critures et celles des lectures tant semblables dans les deux cas, nous prsentons ici une moyenne.
9.2 Exprimentations avec J UX M EM Taille de la donne en ko Temps moyen daccs en ms (cas local) Temps moyen daccs en ms (cas distant) 1 1.72 25.12 4 1.80 25.13 16 2.02 44.76 64 3.01 52.04 256 4.72 58.74 1024 13.54 88.35
127
TAB . 9.2 Comparaison des temps daccs lorsque la copie de rfrence est locale (1 1) ou distante.
tel-00411447, version 1 - 27 Aug 2009
Cette diffrence est due laugmentation de la latence rseau entre le client et le fournisseur hbergeant la copie de rfrence (6 ms entre Rennes et Nancy hbergeant respectivement G3 et G1). Les oprations de lecture ou dcriture requirent 2 changes entre le client et la copie de rfrence : 1) une requte et son acquittement pour la prise de verrou ; et 2) une requte et son acquittement pour la libration du verrou (la donne est encapsule dans les requtes et/ou acquittements lorsque cela est ncessaire). Ces 4 changes sur un lien rseau de latence 6 ms impliquent une latence des oprations au moins suprieure 6 ms 4 = 24 ms. Si lon ajoute une copie de rfrence locale dans la grappe du client en conservant la copie prsente dans la grappe distante et en utilisant notre approche hirarchique, on obtient les rsultats du cas 2 1 (gures 9.2 et 9.5), rappels dans le tableau 9.2.2. Taille de la donne en ko Lectures en ms (cas 2 1) critures en ms (cas 2 1) Temps moyen daccs en ms (cas distant) 1 18.29 38.29 25.12 4 18.36 41.47 25.13 16 26.31 50.21 44.76 64 31.69 55.55 52.04 256 38.00 61.63 58.74 1024 50.58 95.25 88.35
TAB . 9.3 Comparaisons des temps daccs lorsquil y a un seul fournisseur distant ou un fournisseur distant et un local. En plaant une copie de rfrence locale proche du client, en utilisant notre approche hirarchique, les performances des lectures se retrouvent amliores au dtriment de celles des critures. La copie de rfrence locale permet en effet des lectures de la donne sur un fournisseur proche en terme de latence, cependant la mise en service des mcanismes de rplication entre les deux grappes, par la prsence de deux copies de la donne, ralentie lgrement les critures. En effet, chaque criture entrane ici une mise jour de la copie distante. Notons que la prsence de plusieurs copies de rfrence permet par ailleurs doffrir de meilleures garanties de tolrance aux fautes. Intrt des groupes hirarchiques. Le but de cette srie dexpriences est de mettre en vidence lintrt de lapproche hirarchique des groupes. Nous mesurons le cot des accs une donne partage par plusieurs clients, rpartis dans 2 sites diffrents : 2 sexcutent dans la grappe G1 Nancy et 2 sexcutent dans la grappe G3 localise Rennes. Chacun de ces clients effectue des itrations au sein desquelles il lit la donne partage, opre une phase de calcul puis modie compltement la donne partage. Lors de ces mesures la donne est rplique sur 6 fournisseurs, 3 dans G1 et 3 dans G3. Nous observons alors deux cas : 1) avec hirarchie, cest--dire que G1 et G3 hbergent chacune un LDG form de 3 fournisseurs et composant un GDG ; et 2) sans hirarchie, cest--dire que lensemble des 6 fournisseurs
128
forme un unique LDG. Pour ce deuxime cas nous cachons la topologie physique en congurant nos tests de manire ne crer quun seul groupe cluster compos de lensemble des nuds des 2 grappes. La gure 9.8 illustre ces deux congurations.
M1 P1 P4 P2 P5
M2
C1
LDG1
P3 C2
LDG2
P6 C4
C3
Grappe G3
GDG
Grappe G1
Configuration hirarchique Configuration non hirarchique
tel-00411447, version 1 - 27 Aug 2009
M P1 P2 P3 C2 P4
C1
LDG
P5 P6 C4
C3
Grappe G3
M C P
Grappe G1
Pair gestionnaire Pair client Pair fournisseur
F IG . 9.8 Quatre clients rpartis dans deux grappes accdent une donnes rplique sur six fournisseurs. La gure 9.9 prsente les latences des lectures et des critures dans les 2 cas, en fonction de la taille de la donne. Les latences donnes sont les moyennes des temps daccs de chacun des clients. Ces rsultats montrent que dans le cas o lon utilise pas lapproche hirarchique, les latences des oprations dcriture et de lecture sont nettement dtriores par rapport au cas o lon utilise cette approche. Cette dtrioration des performances provient : 1) de la rplication plat entre les deux grappes ; et 2) de la distance entre certains clients et le fournisseur jouant le rle de srialisateur. La rplication plat est moins performante car le nud srialisateur du LDG attend quune majorit de ses membres ait acquitt la diffusion. Dans le cas prsent il attend 3 acquittements, donc au moins un en provenance dun fournisseur prsent dans la deuxime grappe. De plus la moiti des clients sont situs dans une grappe diffrente de celle contenant le fournisseur srialisateur. Les accs la donne par ces clients vont donc engendrer des communications plus forte latence et dtriorer les performances, comme nous lavons remarqu lors du test prcdent. Au vu de ces rsultats, lapproche hirarchique pour la conception de protocoles de cohrence tolrants aux fautes semble bien adapte aux architectures de type fdration de grappes.

Lectures (cas hirarchique) critures (cas hirarchique) Lectures (cas nonhirarchique) critures (cas nonhirarchique)
129
140 120 100 80 60 40 20
1 ko
4 ko
256 ko
1 Mo
tel-00411447, version 1 - 27 Aug 2009
F IG . 9.9 Comparaison des latences des oprations avec et sans notre approche hirarchique.
9.2.3
valuations multi-protocole
J UX M EM est une plate-forme multi-protocole, cest--dire quil est possible lexcution de choisir entre diffrents protocoles de cohrence ou mcanismes de tolrance aux fautes, et ceci pour chaque donne partage. Les exprimentations prsentes ici ont pour but dillustrer le bnce quil est possible de tirer de cette possibilit. Ces exprimentations ont t effectues avec la version Java de J UX M EM pour laquelle ces deux protocoles sont disponibles. Pour ces exprimentations, nous avons utilis les grappes du projet Grid5000 localises Orsay (G2), Rennes (G3) et Toulouse (G4). Nous reprenons le protocole de cohrence lentre, prsent dans la section 8.2 et le protocole tendu pour une visualisation efcace prsent dans la section 8.4. Le but de ces exprimentations est dvaluer les bnces apports par lextension du modle de cohrence lentre. Une valuation dtaille de cette extension est prsente dans [ACM06b], nous prsentons ici celles mettant en vidence les bnces de cette extension pour les oprations dobservations de donnes partages. Description. Nous considrons une application synthtique de type couplage de codes sexcutant sur deux grappes diffrentes : une Rennes et une Toulouse. Au sein de la grappe G3 (Rennes), un client met jour la valeur dune donne partage de manire itrative. La grappe G4 (Toulouse) hberge un client effectuant des oprations de lecture de cette mme donne. Au sein de la troisime grappe localise Orsay, un processus observateur est en charge dobserver lvolution de la valeur de la donne partage. Comme nous lavons soulign la section 8.4, lobservateur ne requiert pas ncessairement les mmes garanties de cohrence que les processus de lapplication-mme : il peut se contenter de versions lgrement obsoltes de la donne. Pour raliser ce test nous avons utilis 3 copies de la donne : une copie dans chacune des grappes. La gure 9.10 prsente les latences des oprations dobservation effectues par lobservateur localis Orsay. Pour 3 tailles de donnes, les latences des observations sont mesures
130
1400 1300 1200 1100 1000 900 800 700 600 500 400 300 200 100 0
F IG . 9.10 Comparaison de deux protocoles de cohrence lors doprations dobservation.
tel-00411447, version 1 - 27 Aug 2009
avec le protocole implmentant la cohrence lentre et avec le protocole implmentant lextension du modle de cohrence lentre prsente la section 8.4. Les paramtres w (nombre maximal de versions de retard acceptes par lobservateur) et D (nombre maximal de redistribution du verrou dans une grappe sans mise jour de la donne dans les autres grappes) sont tous deux gal 0. Comme dtaill la section 8.4 cela signie que que le client observe la version de la donne dtenue par son LDG au moment o il effectue la requte, et que le LDG est mis jour chaque fois quun verrou en criture est relch dans le systme. Les latences des oprations rlxRead du protocole tendu sont 4 6 fois plus rapides que les observations du protocole sans extension, utilisant les oprations acquire_read et release. Ce gain en performance sexplique par le fait que les oprations rlxRead ne sont jamais bloques par les prises de verrou des autres clients, la donne peut tre observe alors que des critures sont en cours. De plus, lors de ces expriences, nous avons mesur un gain pouvant atteindre 30% sur les oprations effectues par les clients de lapplication. Lopration rlxRead ne ncessite en effet pas de prise de verrou et ne bloque donc jamais les oprations des clients des autres grappes. En revanche le verrou est indisponible pour les autres clients entre les oprations acquire_read et release. Des valuation plus dtailles [ACM06b] montrent quil est encore possible damliorer les performances des observations en relchant les paramtres D et w, cest--dire en acceptant des valeurs plus anciennes de la donne.
9.2.4
Impact des fautes sur les performances
Au chapitre 8, nous avons dcrit le comportement des SOG (groupes auto-organisants) face aux fautes. Il faut noter quau moment de loccurrence dune faute, les performances ne sont pas dgrades : le groupe continue tre disponible avec les membres restants. Quand une faute est dtecte, un nouveau fournisseur est recherch. Cest seulement lorsque le nouveau fournisseur a t trouv que le groupe gle ses communications et que les performances des accs se trouvent affectes. Lobjectif des ces exprimentations est dvaluer : 1) le temps pendant lequel un groupe
6 4 9@ 87 4 1 1 ( ( ### 0 0 7 5 3 )) % ( ' & $ $ $ 79@ 887 22 & 887 56 34 111 ) '( &% #$ 7 55 )0 6 6 3 '' % 7 12 7 88877 2 78877 2 2 887 8877 77 7 87 ! " !" !"
Sans lextension Avec lextension RlxRead 1Ko 512Ko 1Mo Taille de la donne et protocole de cohrence utilis
Temps dobservation (en ms)
131
est en sous-nombre aprs loccurrence dune faute ; et 2) le temps pendant lequel un groupe gle ses communications. Description. Nous mesurons trois temps : 1) le temps de dtection dune faute ; 2) le temps de recherche dun nouveau fournisseur ; et 3) le temps de gel du groupe, cest--dire le temps de rparation qui consiste mettre jour ltat du nouveau fournisseur (comprenant le transfert de la donne) et les listes de membres de lensemble du groupe. Ce troisime temps correspond la dure durant laquelle le groupe ne rpondra pas aux messages qui lui sont envoys (il sont stocks sur le nud srialisateur en attente de la n de la rparation). La somme de ces trois temps reprsente la dure de vulnrabilit du groupe : temps pendant lequel le groupe possde un nombre de membres restreint.
1600 1400 Temps de dtection dune dfaillance
tel-00411447, version 1 - 27 Aug 2009
Temps de dtection (en ms)
1200 1000 800 600 400 200 500
1000
1500 2000 Intervalle entre les messages de vie (ms)
2500
3000
F IG . 9.11 Temps de dtection en fonction de lintervalle entre les messages de vie. Dtection de fautes. Nous avons valu le dtecteur de fautes hirarchique [16] prsent la section 3.2 grce notre outil dinjection de fautes. Le temps de dtection est valu sur 64 nuds uniformment rpartis dans 4 grappes du projet Grid5000 : Rennes, Lyon, Grenoble et Sophia Antipolis. Pour cette exprimentation nous avons utilis la version Java de J UX M EM. Le temps de dtection dune faute dpend du rglage du dtecteur. Le principal paramtre est lintervalle sparant lmission de deux messages de vies. La gure 9.11 prsente les temps de dtection au sein dune grappe en fonction de cet intervalle. Il sont en moyenne gaux la moiti du temps coul entre deux message de vie. Nous avons galement utilis la possibilit dinjecter des fautes corrles an dvaluer la dtection de fautes entre les grappes. Nous obtenons des rsultats similaires. La gure 9.11 peut tre utilise pour choisir le bon compromis entre vitesse de dtection et nombre de messages utiliss. Une description approfondie de ces exprimentations ainsi que des rsultats dtaills sont prsent dans [MB06]. Recherche dun nouveau fournisseur. Les exprimentions ont t effectues au sein de la grappe de Rennes, en utilisant la version C de J UX M EM. La conguration utilise met en
132
uvre un gestionnaire, 4 fournisseurs et un client. Le client alloue une donne rplique sur trois fournisseurs, aprs un laps de temps, un des fournisseurs est considr comme dfaillant, il est remplac par un appel la fonction int repair(Jxta_id *faulty_peer_id), fonction normalement appele par le dtecteur de fautes. Pour la recherche du nouveau fournisseur, nous nous appuyons sur le noyau de J UX M EM. Les mcanismes mis en uvre lors de cette recherche sont dtaills dans [64]. An de trouver un fournisseur diffrent de ceux dj prsent dans le groupe, nous recherchons 4 fournisseurs. Lors de nos exprimentations nous avons mesur un temps de recherche de 4.6 ms. Ce temps est indpendant de la taille de la donne.
50 45 40 Temps de gel (en ms) 35 30 25 20 15 10 5 0 1 ko 4 ko 16 ko 64 ko 256 ko Taille de la donne hberge par le groupe 1 Mo 4 Mo Temps dinsersion dun troisime membre
tel-00411447, version 1 - 27 Aug 2009
F IG . 9.12 Temps de gel dun groupe lors de linsertion dun nouveau membre.
Insertion du nouveau fournisseur dans le groupe. Pour mesurer le temps dinsertion du nouveau fournisseur dans le groupe, nous reprenons la conguration du test prcdent. La gure 9.12 prsente les temps dinsertion dun nouveau fournisseur dans un groupe de 2 fournisseurs en fonction de la taille de la donne. Ce temps comprend lenvoi de la donne et de ltat du protocole de cohrence au nouveau membre, ainsi que lenvoi de la nouvelle liste de membres lensemble des membres du groupe. Le protocole de cohrence reste gel jusqu rception des acquittements des membres du nouveau groupe. On remarque que ce temps est directement li au temps de transfert de la donne, donc sa taille.
9.3 Discussion
Les valuations prsentes ici montrent que les mcanismes de tolrance aux fautes ont un cot important lorsque lon considre une donne accde au sein dune seule grappe. Cependant, elles ont galement montr que lorsque des clients situs dans des grappes diffrentes accdent une mme donne partage, la prsence dune copie de rfrence locale dans chaque grappe pouvait amliorer signicativement les performances des accs des diffrents clients. De plus dans ces cas-l, la rplication les copies de rfrence locales au sein
9.3 Discussion
133
de leur grappe prsente un cot relativement bas. Les exprimentations comparant une approche non-hirarchique avec notre approche hirarchique mettent en vidence lintrt de lapproche hirarchique pour les performances des accs aux donnes partages sur les grilles de type fdration de grappes. Enn, J UX M EM est une plate-forme multi-protocole permettant notamment de comparer diffrents protocoles de cohrence. Ainsi, nous avons pu valuer les bnces apports par lextension du protocole de cohrence prsente dans la section 8.4.
tel-00411447, version 1 - 27 Aug 2009
tel-00411447, version 1 - 27 Aug 2009
135
Quatrime partie
tel-00411447, version 1 - 27 Aug 2009
Conclusion et perspectives
tel-00411447, version 1 - 27 Aug 2009
137
Chapitre
10
Conclusion et perspectives
tel-00411447, version 1 - 27 Aug 2009
Conclusion
Contexte dtude
Les travaux prsents dans ce manuscrit sinscrivent dans le contexte des grilles de calcul. Les grilles de calcul simposent comme une solution trs intressante face la demande croissante de puissance de stockage et de calcul des applications scientiques. Elles permettent en effet dagrger des ressources informatiques an dadditionner leur espace de stockage et leur puissance de calcul. Pour obtenir une grille plus puissante, il suft donc dajouter des ressources, cest--dire des nuds, des grappes de nuds ou des calculateurs parallles. La vision ultime est que lutilisation de la puissance offerte par toutes ces ressources agrges sera terme aussi simple que lutilisation de la puissance lectrique fournie en branchant une prise. Toutefois, les grilles de calcul ne sont pas encore arrives ce niveau de maturit. ce jour, lutilisation dune grille reste complexe et rserve des spcialistes. Les principales difcults proviennent de la nature mme des grilles de calcul : ce sont des architectures htrognes, grande chelle et dynamiques. Htrognit. Les grilles permettent dagrger des ressources de diffrentes organisations, mais ces ressources ne sont gnralement pas homognes. Les nuds peuvent avoir des architectures matrielles diffrentes (par exemple 32 bits/64 bits), les systmes dexploitation des nuds ainsi que les diffrentes bibliothques logicielles ou outils disponibles peuvent varier. Enn, les quipements rseaux sont eux galement trs htrognes (Ethernet, Gigabit-Ethernet, Myrinet, etc.). Cette htrognit rend complexe lutilisation des grilles de calcul. Grande chelle. Le nombre de ressources composant une grille de calcul peut savrer trs grand, Les projets actuels de grilles de calculs comme Grid5000 [113, 26], TeraGrid [126] ou EUROGRID [109] sont composs de milliers voire de dizaines de milliers de nuds. De surcrot, ces ressources sont distribues gographiquement lchelle de pays, voire de continents.
138
Chapitre 10 Conclusion et perspectives
Dynamicit. Cette difcult dcoule en partie de la grande chelle. Plus le nombre de ressources utilises est grand, plus la possibilit doccurrence de fautes est importante. lchelle des grilles de calcul, les fautes sont donc frquentes. De plus, la complexit des rseaux utiliss peut aboutir des fautes mettant en pril la connectivit, une grille pouvant alors se retrouver partitionne. Une partie de la dynamicit est engendre par des oprations de maintenance sur des nuds ou sur lensemble des ressources dune organisation. Ces proprits rendent difcile la mise en uvre et le dploiement dapplications sur les grilles de calcul. De nombreux travaux de recherche ont propos des solutions permettant de faire face une partie de ces difcults et de dautres sont encore en cours. Des projets comme Globus [112] proposent un ensemble doutils facilitant lexploitation des grilles, notamment pour la dcouverte et la localisation de ressources, le transfert de donnes et le dploiement dapplications. Cependant, la conception dapplications pour les grilles de calcul reste complexe. Mme si des solutions ont t apportes pour les transferts de donnes (GridFTP [1]) ou leur stockage (Internet Backplane Protocol, IBP [11]). Nous avons vu au chapitre 2 que les solutions existantes ne permettaient pas doffrir aux applications un service fournissant un accs transparent aux donnes partages en garantissant la fois leur persistance et leur cohrence.
tel-00411447, version 1 - 27 Aug 2009
Contributions
Notre travail se situe dans le cadre du service de partage de donnes J UX M EM. Ce service offre aux applications la possibilit de partager des donnes de manire transparente. Il gre de manire transparente le stockage persistant, la localisation, le transfert et la cohrence des donnes. La conception du service de partage de donnes J UX M EM sinspire la fois de solutions proposes 1) dans le cadre des systmes pair--pair (P2P) pour la localisation des ressources et des donnes ; 2) dans le cadre des systmes mmoire virtuellement partage (MVP) pour les modles et protocoles de cohrence ; et 3) dans le cadre des systmes distribus tolrants aux fautes pour la conception de nos mcanismes garantissant la persistance des donnes. Le service de partage de donnes J UX M EM a fait lobjet dun dpt lAgence pour la Protection des Programmes (APP) et est disponible en tlchargement [129]. Au sein de ce service, nous nous somme focaliss sur la gestion de la cohrence des donnes et le support pour la tolrance aux fautes. Nous proposons une architecture permettant une gestion conjointe de la cohrence des donnes et de la tolrance aux fautes. Les solutions proposes suivent une approche hirarchique an de sadapter aux grilles de calcul. La section 9.2.2 montre les bnces quoffre une telle approche. Gestion conjointe de la cohrence des donnes et la tolrance aux fautes. Nous proposons une architecture logicielle en couches permettant de dcoupler la gestion de la cohrence des donnes de celle de la tolrance aux fautes. Des interfaces gnrales ont t mises en place entre ces couches. Nous avons montr au chapitre 8 que cette approche permet de concevoir des protocoles de cohrence sans avoir prendre en compte les mcanismes de tolrance aux fautes sous-jacents. Il est ainsi possible dutiliser diffrentes mises en uvre des
139 couches de tolrance aux fautes avec une mme mise en uvre de protocole de cohrence1 . Pour chaque donne partage, il est possible de choisir la mise en uvre de la couche de tolrance aux fautes ainsi que le protocole de cohrence utilis. Le choix seffectue lallocation de chaque donne. Cet aspect multi-protocole permet aux applications de choisir la combinaison la mieux adapte pour chaque donne. Nous avons illustr la section 9.2.3 lintrt doffrir une telle possibilit dans le cas particulier de la visualisation dune donne partage. Approche hirarchique pour la gestion de la cohrence. De nombreux protocoles de cohrence sont bass sur la notion de copie de rfrence ou utilisent un nud jouant un rle particulier, comme un nud gestionnaire dune donne, charg de localiser la copie jour. Ces protocoles sont mal adapts la topologie rseau hirarchique intraorganisation/interorganisation des grilles de calcul : si des clients accdent une donne dont la copie de rfrence est situe au sein dune organisation diffrente, les liens interorganisation vont tre utiliss pour chaque accs la copie de rfrence. Notre approche consiste placer un reprsentant local de la copie de rfrence dune donne au sein de chaque organisation dans laquelle se trouvent des clients accdant cette donne. Ces reprsentants locaux, appels copies de rfrence locales, agissent comme des caches et permettent de rduire lutilisation des liens interorganisation. La prsence des copies de rfrence locales apporte des bnces signicatifs lors des accs aux donnes (section 9.2.2). Approche hirarchique pour la gestion de la tolrance aux fautes. Les copies de rfrence locales et globales des protocoles de cohrence reprsentent des entits critiques quil semble judicieux de prserver. Nous proposons des groupes auto-organisants hirarchiques : chaque copie de rfrence locale au sein dune organisation est rplique sur un groupe de fournisseurs appel Local Data Group (LDG) ; la copie de rfrence globale est rplique dans un groupe dont les membres sont les copies de rfrence locales, ce groupe est appel Global Data Group (GDG). Chaque donne se voit ainsi associer un GDG comprenant plusieurs LDG eux-mmes composs de nuds fournisseurs hbergeant une copie de la donne. En annexe, nous prsentons une approche probabiliste visant une plus grande chelle ainsi quune plus forte dynamicit. Cette approche met en uvre un rseau logique pairpair mallable. Rseau logique pair--pair mallable. Nous nous sommes intress la rplication dans des environnements de type pair--pair. Les mcanismes de rplication ncessitent lutilisation de communication de groupe, notamment la diffusion. Dans les systmes pair--pair, les communications suivent les chemins entre les pair voisins dans le rseau logique. Le rseau logique que nous proposons est mallable, cest--dire quil rapproche les pairs appartenant un mme groupe. Cela permet damliorer les communications entre ces pairs et par consquent damliorer les diffusions au sein des groupes.
Ceci suppose cependant que la mise en uvre de la couche de tolrance aux fautes offre des proprits de diffusions atomiques.
1
tel-00411447, version 1 - 27 Aug 2009
140
Perspectives
Les travaux que nous avons prsents dans ce manuscrit dbouchent sur des perspectives prsentes ci-dessous.
quilibrage de charge
Dans la version actuelle, les protocoles de cohrence client accdent aux donnes par lintermdiaire de la copie de rfrence locale. Les requtes modiant ltat de cette copie de rfrence sont diffuses sur chaque nud du LDG sur lequel cette copie est rplique. Les requtes ne modiant pas ltat sont transmises un seul membre de ce groupe. De plus, de manire masquer la rplication du ct client, nous avons choisi que les clients ne connaissent quun reprsentant du groupe. En cas de dfaillance de celui-ci, un nouveau reprsentant est recherch. Une nouvelle approche pourrait consister permettre au client de connatre tous les membres du groupe (LDG) ou seulement un sous-ensemble. Il deviendrait ainsi possible de mettre en place des politiques dquilibrage de charge lors des requtes ne modiant pas ltat de la copie de rfrence locale. Plusieurs clients pourraient par exemple rcuprer une copie de la donne en parallle sur des nuds fournisseurs diffrents. Grce cette approche, les copies mises en place par les mcanismes de rplication des ns de tolrance aux fautes pourraient tre exploites pour amliorer les performances des lectures.
tel-00411447, version 1 - 27 Aug 2009
Utilisation de codes correcteurs

Les mcanismes de tolrance aux fautes prsents dans ce manuscrit rpliquent chaque donne dans son intgralit sur plusieurs nuds fournisseurs an de pourvoir supporter la perte de certains dentre eux. Ces mcanismes sont cependant coteux en terme despace de stockage, dautant plus pour les donnes de grande taille. Nous navons pas explor des mcanismes de tolrance aux fautes utilisant des codes correcteurs. Un code correcteur est une technique de codage fonde la redondance dinformation et utilise an de pouvoir corriger des dfaillances des transmission de donnes mais aussi des supports de stockage. Au sein dun service de partage de donnes pour la grille, cela consisterait dcouper les donnes en blocs, calculer des blocs de redondance et rpartir les diffrents blocs sur plusieurs fournisseurs. Les codes correcteurs peuvent ainsi offrir un bon quilibrage de charge, notamment lors des lectures. Cependant, chaque criture implique le calcul des nouveaux blocs de redondance. Il serait intressant de mener une tude comparative de ces deux types dapproche. Notons que lutilisation de codes correcteurs pour le stockage de la donne nest pas incompatible avec lutilisation de nos mcanismes de rplication qui serviraient alors rpliquer ltat du protocole de cohrence (identit du dtenteur du verrou, listes dattentes, etc.) alors que les codes correcteurs pourraient tre utiliss pour le stockage de la donne proprement dite.
141
Tolrance aux fautes adaptative

Actuellement, les clients du service de partage de donnes J UX M EM doivent prciser eux-mmes les mcanismes de tolrance aux fautes utiliser, ainsi que le degr de rplication. De plus, la couche dadaptation aux fautes ne possde quune politique : remplacer les fournisseurs dfaillants. Le degr de rplication dune donne ne varie donc jamais. Le type de mcanisme de tolrance aux fautes utiliser ainsi que le degr de rplication devraient pouvoir tre dtermins en fonction du niveau de criticit de la donne et du degr de risque. Lapplication pourrait alors fournir un niveau de criticit de la donne en fonction des garanties souhaites en terme de tolrance aux fautes. Par exemple le niveau de criticit pourrait tre : trs critique, ne doit pas tre perdue, critique, non critique, etc. Le degr de risque peut tre estim par un module dobservation du systme, par exemple en prenant en compte les fautes survenues rcemment, la temprature des machines, la charge rseau, etc. Ce degr de risque tant susceptible de changer au cours du temps, la couche dadaptation aux fautes pourrait dans certains cas dcider de ne pas remplacer un nud dfaillants, ou au contraire de le remplacer par plusieurs nuds en prvision de pannes futures.
tel-00411447, version 1 - 27 Aug 2009
Dfaillances des clients

Dans notre travail, nous nous sommes focaliss sur les fautes du service de partage de donnes, cest--dire sur les dfaillances des nuds hbergeant les donnes, les nuds fournisseurs. Pour tolrer les dfaillances des nuds clients, nous avons propos de mettre en uvre des mcanismes de points de reprise hirarchiques. Lintgration des deux solutions nest pas triviale. Si les applications utilisant le service de partage de donnes sont susceptibles deffectuer des retours en arrire au niveau dun point de reprise sauvegard, le service doit tre en mesure de restaurer ltat du protocole de cohrence ainsi que la version de la donne qui correspond au moment de la sauvegarde du point de reprise. Ceci implique que le service conserve plusieurs versions de la donne et soit inform des sauvegardes de points de reprise. Le service de partage de donne peut en revanche tirer avantage de la possibilit de retour en arrire des applications : des mcanismes de rplication optimistes peuvent tre mis en place et le service peut alors forcer un retour en arrire de lapplication en cas de perte de la dernire version de la donne.
Vers les fdrations de grilles

De nombreux projets de grilles sont raliss travers le monde. De plus en plus dinitiatives visant relier des grilles entre elles voient le jour. On peut donc penser quil existera, dici quelques annes, des fdrations de grilles. Notre approche hirarchique pour la gestion de la cohrence des donnes et de la tolrance aux fautes a t conue pour une hirarchie deux niveaux : intraorganisation et interorganisation. Il semble raisonnable de penser que deux grilles seront interconnectes, ajoutant ainsi un niveau de hirarchie dans la topologie rseau. Une approche base sur une hirarchie deux niveaux sera alors insufsante. Ce cas peut galement se prsenter au sein dune grille si lune des organisations est compose de deux sous-organisations possdant chacune une grappe de calculateurs. Il semble
142
intressant de gnraliser notre approche hirarchique deux niveaux en une approche hirarchique n niveaux.
tel-00411447, version 1 - 27 Aug 2009
143
Rfrences
Les premires rfrences bibliographiques correspondent nos propres publications. Elles sont listes la page 3.
tel-00411447, version 1 - 27 Aug 2009
[1] Bill Allcock, Joe Bester, John Bresnahan, Ann L. Chervenak, Ian Foster, Carl Kesselman, Sam Meder, Veronika Nefedova, Darcy Quesnel, and Steven Tuecke. Data management and transfer in high-performance computational grid environments. Parallel Computing, 28(5):749771, 2002. [2] Yair Amir and Ciprian Tutu. From total order to database replication. In Proceedings of the 22nd International Conference on Distributed Computing Systems (ICDCS 02), page 494, Washington, DC, 2002. IEEE Computer Society. [3] Cristiana Amza, Alan L. Cox, Sandhya Dwarkadas, Pete Keleher, Honghui Lu, Ramakrishnan Rajamony, Weimin Yu, and Willy Zwaenepoel. TreadMarks: Shared memory computing on networks of workstations. IEEE Computer, 29(2):1828, February 1996. [4] Gabriel Antoniu, Luc Boug, and Mathieu Jan. JuxMem : Weaving together the P2P and DSM paradigms to enable a Grid Data-sharing Service. Kluwer Journal of Supercomputing, 2005. To appear. Preliminary electronic version available as INRIA Research Report RR-5082. [5] Gabriel Antoniu, Luc Boug, and Sbastien Lacour. Making a DSM consistency protocol hierarchy-aware: An efcient synchronization scheme. In Proceedings of the 3rd IEEE/ACM International Conference on Cluster Computing and the Grid (CCGrid 03), pages 516523, Tokyo, Japan, May 2003. IEEE. [6] Luciana Bezerra Arantes, Pierre Sens, and Bertil Folliot. An Effective Logical Cache for a Clustered LRC-Based DSM System. Cluster Computing Journal, 5(1):1931, January 2002. [7] Vadim Astakhov, Amarnath Gupta, Simone Santini, and Jeffrey S. Grethe. Data Integration in the Biomedical Informatics Research Network (BIRN). In Data Integration in the Life Sciences (DILS 05), pages 317320, 2005. [8] Morin Christine Badrinath Ramamurthy. Common Mechanisms for Supporting Fault Tolerance in DSM and Message Passing Systems. Research Report RR-4613, INRIA, IRISA, Rennes, France, November 2002.
144
Rfrences
[9] R. Baldoni, J. M. Hlary, A. Mostefaoui, and M. Raynal. Consistent State Restoration in Shared Memory Systems. In Proc. of the Int. IEEE Conference on Advances in Parallel and Distributed Computing (APDC 97), pages 330337, Shangai, 1997. [10] A.-L. Barabasi. LINKED: The New Science of Networks. Perseus Books Group, 2002. [11] Alessandro Bassi, Micah Beck, Graham Fagg, Terry Moore, James Plank, Martin Swany, and Rich Wolski. The Internet Backplane Protocol: A study in resource sharing. In Proceedings of the 2nd IEEE/ACM International Symposium on Cluster Computing and the Grid (CCGrid 02), pages 194201, Berlin, Germany, May 2002. IEEE. [12] Micah Beck, Ying Ding, Terry Moore, and James S. Plank. Transnet Architecture and Logistical Networking for Distributed Storage. In Workshop on Scalable File Systems and Storage Technologies (SFSST), San Francisco, CA, September 2004. Held in conjunction with the 17th International Conference on Parallel and Distributed Computing Systems (PDCS-2004).
tel-00411447, version 1 - 27 Aug 2009
[13] Micah Beck, Terry Moore, and James S. Plank. An end-to-end approach to globally scalable network storage. In Proceedings of the 2002 Conference on applications, technologies, architectures, and protocols for computer communications (SIGCOMM 02), pages 339 346. ACM Press, 2002. [14] Micah Beck, Terry Moore, James S. Plank, and Martin Swany. Logistical Networking: Sharing More Than the Wires. In Proceedings of 2nd Annual Workshop on Active Middleware Services, volume 583 of The Kluwer International Series in Engineering and Computer Science. Kluwer Academic Publishers, August 2000. [15] Brian N. Bershad, Mattew J. Zekauskas, and Wayne A. Sawdon. The Midway distributed shared memory system. In Proceedings of the 38th IEEE International Computer Conference (COMPCON 93), pages 528537, Los Alamitos, CA, February 1993. [16] Marin Bertier. Service de dtection de dfaillances hirarchique. Thse de doctorat, Universit de Paris 6, LIP6, Paris, France, 2004. [17] Marin Bertier, Olivier Marin, and Pierre Sens. Implementation and performance evaluation of an adaptable failure detector. In Proceedings of the International Conference on Dependable Systems and Networks (DSN 02), pages 354363, Washington, DC, June 2002. [18] Marin Bertier, Olivier Marin, and Pierre Sens. Performance analysis of a hierarchical failure detector. In Proceedings of the International Conference on Dependable Systems and Networks (DSN 03), pages 635644, San Francisco, CA, june 2003. [19] Joseph Bester, Ian Foster, Carl Kesselman, Jean Tedesco, and Steven Tuecke. GASS: a data movement and access service for wide area computing systems. In Proceedings of the sixth workshop on I/O in parallel and distributed systems (IOPADS 99), pages 7888, New York, NY, may 1999. ACM Press. [20] Kenneth Birman and Robert Cooper. The ISIS project: real experience with a fault tolerant programming system. SIGOPS Oper. Syst. Rev., 25(2):103107, 1991.
Rfrences
145
[21] Bela Bollobas. Random Graphs, Second Edition. Cambride University Press, United Kingdom, 2001. [22] George Bosilca, Aurlien Bouteiller, Franck Cappello, Samir Djilali, Gilles Fedak, Cecile Germain, Thomas Hrault, Pierre Lemarinier, Oleg Lodygensky, Frederic Magniette, Vincent Nri, and Anton Selikhov. MPICH-V: toward a scalable fault tolerant MPI for volatile nodes. In Proceedings of the 2002 ACM/IEEE conference on Supercomputing (SC 02), pages 118, Baltimore, Maryland, November 2002. IEEE Computer Society. [23] Jean-Michel Busca, Fabio Picconi, and Pierre Sens. Pastis: A Highly-Scalable Multiuser Peer-to-Peer File System. In Proceedings of the 11th International Euro-Par Conference (Euro-Par 05), volume 3648 of Lecture Notes in Computer Science, pages 11731182, Lisbon, Portugal, August 2005. Springer. [24] Sidney Cadot, Frits Kuijlman, Koen Langendoen, Kees van Reeuwijk, and Henk Sips. ENSEMBLE: A communication layer for embedded multi-processor systems. In Proceedings of the ACM SIGPLAN workshop on Languages, compilers and tools for embedded systems (LCTES 01), pages 5663, New York, NY, 2001. ACM Press. [25] Kenneth L. Calvert, Matthew B. Doar, and Ellen W. Zegura. Modeling Internet topology. IEEE Communications Magazine, 35(6):160163, June 1997. [26] Franck Cappello, Eddy Caron, Michel Dayde, Frdric Desprez, Emmanuel Jeannot, Yvon Jegou, Stphane Lanteri, Julien Leduc, Nouredine Melab, Guillaume Mornet, Raymond Namyst, Pascale Primet, and Olivier Richard. Grid5000: A Large Scale, Recongurable, Controlable and Monitorable Grid Platform. In Proceedings of the 6th IEEE/ACM International Workshop on Grid Computing (Grid 05), Seattle, Washington, November 2005. [27] Gianni Di Caro and Marco Dorigo. AntNet: Distributed stigmergetic control for communications networks. Journal of Articial Intelligence Research, 9:317365, 1998. [28] Eddy Caron and Frdric Desprez. DIET: A Scalable Toolbox to Build Network Enabled Servers on the Grid. International Journal of High Performance Computing Applications, 20(3):335352, 2006. [29] Mark Carson and Darrin Santay. Nist net: a Linux-based network emulation tool. SIGCOMM Computing Communication Review, 33(3):111126, 2003. [30] Miguel Castro and Barbara Liskov. Practical byzantine fault tolerance. In Proceedings of the 3rd Symposium on Operating Systems Design and Implementation: (OSDI 99), volume 32(5) of Operating Systems Review, pages 173186, New Orleans, LA, February 1999. Usenix Association. [31] Miguel Castro and Barbara Liskov. Practical Byzantine Fault Tolerance and Proactive Recovery. ACM Transactions on Computer Systems, 20(4):398461, November 2002. [32] Tushar Deepak Chandra and Sam Toueg. Unreliable failure detectors for reliable distributed systems. Journal of the ACM, 43(2):225267, March 1996.
tel-00411447, version 1 - 27 Aug 2009
146
Rfrences
[33] K.M. Chandy and L. Lamport. Distributed Snapshots: Determining Global States of Distributed Systems. ACM Trans. Computer Systems, 3(1):6375, February 1985. [34] Steve Chapin, Dimitrios Katramatos, John Karpovich, and Andrew Grimshaw. The Legion Resource Management System. In 5th Workshop on Job Scheduling Strategies for Parallel Processing (JSSPP 99), volume 1659 of Lecture Notes in Computer Science, pages 162178, San Juan, Puerto Rico, April 1999. Springer. [35] Shu-Wie F. Chen and Calton Pu. An analysis of replica control. In Proceedings of the 2nd Workshop on the Management of Replicated Data, pages 2225, Monterey, CA, November 1992. [36] Wei Chen, Sam Toueg, and Marcos Kawazoe Aguilera. On the quality of service of failure detectors. IEEE Transactions on Computers, 51(1):1332, 2002. [37] Gregory V. Chockler, Idit Keidar, and Roman Vitenberg. Group communication specications: a comprehensive study. ACM Computing Surveys, 33(4):427469, December 2001. [38] Ian Clarke, Oskar Sandberg, Brandon Wiley, and Theodore W. Hong. Freenet: A distributed anonymous information storage and retrieval system. In Proceedings of the International Workshop on Design Issues in Anonymity and Unobservability, number 2009, pages 4666, Berkeley, CA, July 2000. [39] Manuel Costa, Paulo Guedes, Manuel Sequeira, Nuno Neves, and Miguel Castro. Lightweight Logging for Lazy Release Consistent Distributed Shared Memory. In Proceedings of the Second Symposium on Operating Systems Design and Implementations (OSDI 96), pages 5973, Seattle, WA, October 1996. [40] Frank Dabek, Frans Kaashoek, David Karger, Robert Morris, and Ion Stoica. Widearea cooperative storage with CFS. In 18th ACM Symposium on Operating Systems Principles (SOSP 01), pages 202215, Chateau Lake Louise, Banff, Alberta, Canada, October 2001. [41] Abhinandan Das, Indranil Gupta, and Ashish Motivala. SWIM: Scalable Weaklyconsistent Infection-style Process Group Membership Protocol. In Proceedings of the International Conference on Dependable Systems and Networks (DSN 02), Washington, DC, June 2002. [42] B. Devianov and S. Toueg. Failure detector service for dependable computing. In Proceedings of the First International Conference on Dependable Systems and Networks, pages 1415, New York, NY, Juin 2000. [43] S. G. Djorgovski, R. R. Gal, S. C. Odewahn, R. R. de Carvalho, R. Brunner, G. Longo, and R. Scaramella. The Palomar Digital Sky Survey (DPOSS), 1998. http://astro.ncsa. uiuc.edu/catalogs/dposs/. [44] F. Dunno, L. Gaido, A. Gishelli, F. Prelz, and M. Sgaravatoo. DataGrid Prototype 1. EU-DataGrid Collaboration. In Proceedings of the TERENA Networking Conference, Limerick, Ireland, June 2002.
tel-00411447, version 1 - 27 Aug 2009
Rfrences
147
[45] C. Dwork, N. Lynch, and L. Stockmeyer. Consensus in the presence of partial synchrony. Journal of the ACM, 35(2):288323, 1988. [46] Xavier Dfago, Andr Schiper, and Pter Urban. Totally ordered broadcast and multicast algorithms: a comprehensive survey. Technical Report TR DSC/2000/036, Dept. of Communication Systems, EPFL, Switzerland, October 2000. [47] M. Elnozahy, L. Alvisi, Y.-M. Wang, and D.B. Johnson. A survey of rollback-recovery protocols in message-passing systems. Technical Report CMU-CS-99-148, Carnegie Mellon University, June 1999. [48] P. Erds and A. Rnyi. On the evolution of random graphs. Publication of the Mathemathic Institue of the Hungarian Academy of Sciences, 5:1761, 1960. [49] Michael J. Fischer, Nancy A. Lynch, and Michael S. Paterson. Impossibility of distributed consensus with one faulty process. Journal of the ACM, 32(2):374382, April 1985. [50] Michael J. Freedman, Karthik Lakshminarayanan, Sean Rhea, and Ion Stoica. Nontransitive connectivity and DHTs. In Proceedings 2nd Workshop on Real, Large, Distributed Systems (WORLDS 05), pages 5560, San Francisco, CA, December 2005. [51] Kourosh Gharachorloo, Daniel Lenoski, James Laudon, Phillip Gibbons, Anoop Gupta, and John Hennessy. Memory consistency and event ordering in scalable shared-memory multiprocessors. In Proceedings of the 17th International Symposium on Computer Architecture (ISCA 90), pages 1526, Seattle, WA, June 1990. [52] Jim Gray, Pat Helland, Patrick ONeil, and Dennis Shasha. The dangers of replication and a solution. In Proceedings of the 1996 ACM SIGMOD international conference on Management of data (SIGMOD 96), pages 173182, Montreal, Canada, 1996. ACM Press. [53] F. Greve, M. Hurn, M. Raynal, and F. Tronel. Primary component asynchronous group membership as an instance of a generic agreement framework. In Proceedings of the IEEE International Symposium on Autonomous Decentralized Systems (ISADS 01), pages 93100, Dallas, Texas, March 2001. [54] Fabola Gonalves Pereira Greve. Rponses efcaces au besoin daccord dans un groupe. Thse de doctorat, Universit de Rennes 1, IRISA, Rennes, France, Novembre 2002. [55] Network Working Group. RFC 2988: Computing TCPs retransmission, 2000. [56] Rachid Guerraoui and Andr Schiper. Software-based replication for fault tolerance. IEEE Computer, 30(4):6874, 1997. [57] Sidath Handurukande, Anne-Marie Kermarrec, Fabrice Le Fessant, and Laurent Massouli. Exploiting semantic clustering in the eDonkey P2P network. In Proceedings of SIGOPS European Workshop, pages 109114, Leuven, Belgium, September 2004. [58] William Hoarau and Sbastien Tixeuil. A language-driven tool for fault injection in distributed system. Research report 1399, Laboratoire de Recherche en Informatique (LRI), University Paris-Sud, France, February 2005.
tel-00411447, version 1 - 27 Aug 2009
148
Rfrences
[59] Jeff Hodges and Robert Morgan. Lightweight Directory Access Protocol (v3): Technical Specication. IETF Request For Comment 3377, Network Working Group, 2002. [60] P. Hutto and M. Ahamad. Slow memory: Weakening consistency to enhance concurrency in distributed shared memories. In Proceedings of the 10th International Conference on Distributed Computing Systems (ICDCS 90), pages 302311, May. [61] Liviu Iftode, Jaswinder Pal Singh, and Kai Li. Scope consistency: A bridge between release consistency and entry consistency. In Proceedings of the 8th ACM Annual Symposium on Parallel Algorithms and Architectures (SPAA 96), pages 277287, Padova, Italy, June 1996. [62] Van Jacobson. Congestion avoidance and control. In Proceedings of the Symposium on Communications Architectures and Protocols (SIGCOMM 88), pages 314329, Stanford, CA, August 1988.
tel-00411447, version 1 - 27 Aug 2009
[63] Neel K. Jain. Group formation mechanisms for transactions in ISIS. In Proceedings of the third international conference on Information and knowledge management (CIKM 94), pages 203210, New York, NY, 1994. ACM Press. [64] Mathieu Jan. JuxMem: un service de partage transparent de donnes pour grilles de calculs fond sur une approche pair--pair. Thse de doctorat, Universit de Rennes 1, IRISA, Rennes, France, November 2006. [65] Mrk Jelasity and Ozalp Babaoglu. T-Man: Fast Gossip-based Contruction of LargeScale Overlay Topologies. Technical Report UBLCS-2004-7, University of Bologna, May 2004. [66] Mark Jelasity, Rachid Guerraoui, Anne-Marie Kermarrec, and Maarten van Steen. The peer sampling service: experimental evaluation of unstructured gossip-based implementations. In Proceedings of the 5th ACM/IFIP/USENIX international conference on Middleware (Middleware 04), pages 7998, New York, NY, 2004. Springer. [67] Yvon Jgou. Implementation of Page Management in Mome, a User-Level DSM. In Proceedings of the 3rd IEEE International Symposium on Cluster Computing and the Grid (CCGrid 03), pages 479486, Tokyo, Japan, May 2003. IEEE Computer Society. [68] Anne-Marie Kermarrec, Gilbert Cabillic, Alain Gefaut, Christine Morin, and Isabelle Puaut. A recoverable distributed shared memory integrating coherence and recoverability. In Proceedings of the 25th International Symposium on Fault-Tolerant Computing Systems (FTCS 95), pages 289298, Pasadena, CA, June 1995. [69] Anne-Marie Kermarrec and Christine Morin. Smooth and efcient integration of highavailability in a parallel single level store system. In Proceedings of the 7th International Euro-Par Conference on Parallel Processing (Euro-Par 01), volume 2150 of Lecture Notes in Computer Science, pages 752763, Manchester, UK, 2001. Springer. [70] Carl Kesselman and Ian Foster. The Grid: Blueprint for a New Computing Infrastructure. Morgan Kaufmann Publishers, November 1998. [71] Richard Koo and Sam Toueg. Checkpointing and rollback-recovery for distributed systems. IEEE Transactions on Software Engineering, 13(1):2331, January 1987.
Rfrences
149
[72] Dionysios Kostoulas, Dimitrios Psaltoulis, Indranil Gupta, Ken Birman, and Al Demers. Decentralized schemes for size estimation in large and dynamic groups. In Proceedings of the Fourth IEEE International Symposium on Network Computing and Applications (NCA 05), pages 4148, Washington, DC, July 2005. IEEE Computer Society. [73] John Kubiatowicz, David Bindel, Yan Chen, Patrick Eaton, Dennis Geels, Ramakrishna Gummadi, Sean Rhea, Hakim Weatherspoon, Westly Weimer, Christopher Wells, and Ben Zhao. OceanStore: An architecture for global-scale persistent storage. In Proceedings of the 9th International Conference on Architecture Support for Programming Languages and Operating Systems (ASPLOS 2000), volume 2218 of Lecture Notes in Computer Science, pages 190201, Cambridge, MA, 2000. Springer. [74] Sbastien Lacour. Contribution lautomatisation du dploiement dapplications sur les grilles de calcul. Thse de doctorat, Universit de Rennes 1, IRISA, Rennes, France, December 2005.
tel-00411447, version 1 - 27 Aug 2009
[75] L. Lamport. How to make a multiprocessor computer that correctly executes multiprocess programs. IEEE Transactions on Computers, C-28(9):690691, September 1979. [76] Leslie Lamport. Time, clocks, and the ordering of events in a distributed system. Commun. ACM, 21(7):558565, 1978. [77] J.-C. Laprie. Dependable computing and fault tolerance : concepts and terminology. In Proceedings of the 15th International Symposium on Fault-Tolerant Computing (FTCS 85), pages 211, Ann Arbor, MI, June 1985. [78] Mikel Larrea, Sergio Arvalo, and Antonio Fernndez. Efcient algorithms to implement unreliable failure detectors in partially synchronous systems. In Proceedings of Distributed Computing, 13th International Symposium 1999 (DISC 99), volume 1693 of Lecture Notes in Computer Science, pages 3448, Bratislava, Slavak Republic, September 1999. Springer. [79] K. Li and P. Hudak. Memory coherence in shared virtual memory systems. ACM Transactions on Computer Systems, 7(4):321359, November 1989. [80] D. Manivannan and Mukesh Singhal. Quasi-Synchronous Checkpointing: Models, Characterization, and Classication. IEEE Transaction on Parallel and Distributed Systems, 10(7):703713, July 1999. [81] Olivier Marin, Marin Bertier, and Pierre Sens. DARX - A Framework for the FaultTolerant Support of Agent Software. In 14th IEEE International Symposium on Software Reliability Engineering (ISSRE 03), page 406, Denver, CO, November 2003. [82] Sergio Mena, Andr Schiper, and Pawel Wojciechowski. A step towards a new generation of group communication systems. In Proceedings of the 4th International Middleware Conference (Middleware 03), volume 2672 of Lecture Notes in Computer Science, pages 414432, Rio de Janeiro, Brazil, June 2003. Springer. [83] C. Morin and I. Puaut. A Survey of Recoverable Distributed Shared Virtual Memory Systems. IEEE Transaction on Parallel and Distributed Systems, 8(9):959969, September 1997.
150
Rfrences
[84] Christine Morin, Anne-Marie Kermarrec, Michel Bantre, and A. Gefaut. An efcient and scalable approach for implementing fault tolerant DSM architectures. IEEE Transactions on Computers, 49(5):414430, May 2000. [85] Athicha Muthitacharoen, Robert Morris, Thomer M. Gil, and Benjie Chen. Ivy: A read/write peer-to-peer le system. In Proceedings of the 5th Symposium on Operating Systems Design and Implementation (OSDI 02), Boston, MA, 2002. [86] Andy Oram. Peer-to-Peer: Harnessing the Power of Disruptive Technologies, chapter Gnutella, pages 94122. OReilly, May 2001. [87] Esther Pacitti, Pascale Minet, and Eric Simon. Fast algorithms for maintaining replica consistency in lazy master replicated databases. In Proceedings of the 25th International Conference on Very Large Data Base (VLDB 99), pages 126137, San Francisco, CA, 1999. Morgan Kaufmann Publishers Inc.
tel-00411447, version 1 - 27 Aug 2009
[88] Ccile Le Pape. Contrle de Qualit des Donnes Rpliques dans un Cluster. Thse de doctorat, Universit Pierre et Marie Curie, LIP6, Paris, France, December 2005. [89] James Plank, Micah Beck, Wael Elwasif, Terence Moore, Martin Swany, and Rich Wolski. The Internet Backplane Protocol: Storage in the network. In Network Storage Symposium (NetStore 99), Seattle, WA, October 1999. [90] Jelica Proti , Milo Tomasevi , and Veljko Milutinovi . Distributed Shared Memory: Conc c c cepts and Systems. IEEE, August 1997. [91] A. Rajasekar, M. Wan, R.W. Moore, W. Schroeder, G. Kremenek, A. Jagatheesan, C. Cowart, B. Zhu, S.Y. Chen, and R. Olschanowsky. Storage resource broker - managing distributed data in a grid. Computer Society of India Journal, 33(4):4254, 2003. special issue on SAN. [92] Michel Raynal, Matthieu Roy, and Ciprian Tutu. Merging atomic consistency and sequential consistency. Technical Report 1629, IRISA, June 2004. [93] J. Rough and A. Goscinski. Exploiting operating system services to efciently checkpoint parallel applications in GENESIS. In Proceedings of the 5th IEEE International Conference on Algorithms and Architectures for Parallel Processing, pages 261268, October 2002. [94] Antony I. T. Rowstron and Peter Druschel. Pastry: Scalable, Decentralized Object Location, and Routing for Large-Scale Peer-to-Peer Systems. In Proceedings of the 18th IFIP/ACM International Conference on Distributed Systems Platforms (Middleware 01), volume 2218 of Lecture Notes in Computer Science, pages 329250, Heidelberg, Germany, November 2001. Springer. [95] Antony I. T. Rowstron, Anne-Marie Kermarrec, Miguel Castro, and Peter Druschel. SCRIBE: The design of a large-scale event notication infrastructure. In In Proceedings of Networked Group Communication (NGC 01), pages 3043, London, UK, 2001. [96] Ian Foster S. Vazhkudai, Steven Tuecke. Replica selection in the Globus data grid. In 1st IEEE/ACM International Conference on Cluster Computing and the Grid (CCGrid 01), pages 106113, Brisbane, Australia, May 2001. IEEE.
Rfrences
151
[97] Stefan Saroiu, P. Krishna Gummadi, and Steven D. Gribble. A measurement study of peer-to-peer le sharing systems. In Proceedings of Multimedia Computing and Networking 2002 (MMCN 02), San Jose, CA, January 2002. [98] Fred B. Schneider. Implementing Fault-Tolerant Services Using the State Machine Approach: A Tutorial. ACM Computing Surveys, 22(4):299319, December 1990. [99] Ion Stoica, Robert Morris, David Karger, Frans Kaashoek, and Hari Balakrishnan. Chord: A scalable peer-to-peer lookup service for Internet applications. In Proceedings of the Symposium on Communications Architectures and Protocols (SIGCOMM 01), pages 149160, San Diego, CA, August 2001. [100] F. Sultan, T. D. Nguyen, and L. Iftode. Lazy garbage collection of recovery state for fault-tolerant distributed shared memory. 13(7):673686, July 2002. [101] Robbert van Renesse, Kenneth P. Birman, and Silvano Maffeis. Horus: a exible group communication system. Communications of the ACM, 39(4):7683, 1996. [102] Spyros Voulgaris, Daniela Gavida, and Maarten Van Steen. CYCLON: Inexpensive membership management for unstructured P2P overlays. Journal of Network and Systems Management, 13(2), June 2005. [103] Spyros Voulgaris and Maarten van Steen. Epidemic-style management of semantic overlays for content-based searching. In Proceedings of the 11th International Euro-Par Conference (Euro-Par 2005), volume 3648 of Lecture Notes in Computer Science, pages 11431152, Lisboa, Portugal, August 2005. Springer. [104] D. J. Watts and S. H. Strogatz. Collective dynamics of small world networks. Nature, 393:440442, 1998. [105] Brian S. White, Michael Walker, Marty Humphrey, and Andrew S. Grimshaw. LegionFS: a secure and scalable le system supporting cross-domain high-performance applications. In Proceedings of the 2001 ACM/IEEE conference on Supercomputing (Supercomputing 01), page 59, New York, NY, 2001. ACM Press. [106] Ben Yanbin Zhao, John Kubiatowicz, and Anthony Joseph. Tapestry: An infrastructure for fault-tolerant wide-area location and routing. Technical Report UCB/CSD-011141, Computer Science Division (EECS), Univeristy of California, Berkeley, CA, April 2001. [107] Y. Zhou, L. Iftode, and K. Li. Performance evaluation of two home-based lazy release consistency protocols for shared virtual memory systems (OSDI 96). In Proceedings of the Operating Systems Design and Implementation Symposium, pages 7588, Seattle, WA, October 1996. [108] eDonkey. http://www.edonkey2000.com/. [109] The EUROGRID project. http://www.eurogrid.org/. [110] The general atomic and molecular electronic structure system (GAMESS). //www.msg.ameslab.gov/GAMESS/GAMESS.html. http:
tel-00411447, version 1 - 27 Aug 2009
152 [111] The GDS project: A Grid Data Service. http://www.irisa.fr/GDS/. [112] The Globus project. http://www.globus.org/. [113] Grid5000 Project. http://www.grid5000.org/. [114] JXTA Distributed Framework. http://jdf.jxta.org/, 2003. [115] JXTA specication project. http://spec.jxta.org/. [116] KaZaA. http://www.kazaa.com/.
Rfrences
[117] Legion - the worldwide virtual computer. http://www.cs.virginia.edu/legion/. [118] MCAT - "the metadata catalog". http://www.npaci.caltech.edu/2mass/. [119] Myrinet performance measurements. http://www.myrinet.com/myrinet/performance/.
tel-00411447, version 1 - 27 Aug 2009
[120] MySQL. http://www.mysql.com/. [121] OAR. http://oar.imag.fr/. [122] OARGRID. http://oargrid.gforge.inria.fr/. [123] The PARIS research group: Programming distributed parallel systems for large scale numerical simulation. http://www.inria.fr/recherche/equipes/paris.en.html. [124] PlanetLab website. http://www.planet-lab.org/. [125] Renater : Le Rseau National de Tlcommunications pour la Technologie, lEnseignement et la Recherche. http://www.renater.fr/. [126] The TeraGrid project. http://www.teragrid.org/. [127] The TeraShake project. http://sceclib.sdsc.edu/TeraShake/. [128] Le projet HydroGrid. http://www-rocq.inria.fr/kern/HydroGrid/HydroGrid.html. [129] The JuxMem Project: Juxtaposed Memory. http://juxmem.gforge.inria.fr/.
tel-00411447, version 1 - 27 Aug 2009
Cinquime partie
Annexes
153
tel-00411447, version 1 - 27 Aug 2009
A.1 Prise en compte des applications au niveau dun rseau logique pair--pair
155
Nous prsentons ici un travail effectu dans le cadre dune collaboration avec Indranil Gupta et Ramss Morales de luniversit de lIllinois Urbana-Champaign (University of Illinois at Urbana-Champaign ou UIUC) aux tats-Unis. Dans le cadre de cette collaboration, jai effectu un sjour dun mois Urbana et nous avons reu Rennes Ramss Morales durant un mois ainsi que Indranil Gupta durant 15 jours. Le travail prsent ici sort donc du cadre du service de partage de donnes pour la grille J UX M EM. Jusque-l, nous nous sommes intress la gestion de la tolrance aux fautes et de la cohrence des donnes dans un cadre trs prcis (J UX M EM) pour une architecture physique de type grille et des applications scientiques. Ceci implique de nombreuses contraintes, comme la prsence dun protocole de cohrence de donnes offrant des garanties de cohrence aux applications scientiques. Il existe des cadres dans lesquels les besoins des applications en terme de garantie et de performance ne sont pas aussi forts. Cest notamment le cas des applications pair--pair collaboratives. En revanche, pour ces dernires, supporter la volatilit des nuds est crucial, les nuds ntant plus forcment des calculateurs ddis mais des ordinateurs personnels par exemple. Nous avons donc tudi comment offrir ce type dapplication la possibilit davoir des mcanismes de communication de groupe efcaces partir du rseau logique pair--pair. Les rseaux logiques pair--pair permettent aux applications distribues de sexcuter grande chelle de manire compltement distribue et tolrante aux fautes. Cependant la plupart des rseaux logiques prsents dans la littrature, structurs et non-structurs, sont inexibles du point de vue de lapplication. En dautres termes, lapplication na pas de contrle sur la structure du rseau logique quelle utilise. Nous proposons le concept dun rseau logique mallable et la conception du premier rseau logique mallable que nous appelons MO VE (pour langlais Malleable Overlay). Les caractristiques des schmas de communications dune application distribue utilisant MO VE peuvent inuencer la structure mme du rseau logique. Ceci avec un double but : 1) optimiser les performances des applications en adaptant le rseau logique, tout en 2) conservant les proprits de passage lchelle et de tolrance aux fautes des rseaux logiques pair--pair. Cette inuence peut tre spcie explicitement par lapplication ou glane par nos algorithmes. En plus de grer des listes de voisins (constituant le rseau) MO VE propose des algorithmes de dcouverte de ressources, de propagation des mises jour et de rsistance la volatilit. Quand lapplication a peu de besoins de communication, la plupart des liens du rseau logique conservent leur conguration par dfaut ; par contre, quand les schmas de communication de lapplication deviennent plus exigeants, le rseau logique sadapte de lui-mme en favorisant les liens entre les entits communicantes.
tel-00411447, version 1 - 27 Aug 2009
A.1.1 Un rseau logique mallable
Il existe deux grandes familles de rseaux logiques pair--pair : les rseaux dits structurs, fonds sur des tables de hachage distribues, comme Pastry et Chord [94, 99] et ceux dits non-structurs, construits sur des protocoles pidmiques ou dinondation, comme Freenet, Gnutella, KaZaA [38, 86, 116]. Ces rseaux logiques pair--pair sont bien adapts la vola-
156 tilit, arrives et dparts de nuds, et supportent galement les grandes chelles de lordre de millions de nuds. Cependant, les rseaux logiques structurs ou non structurs, prsentent linconvnient dtre inexibles du point de vue des applications. Les rgles et invariants qui servent au choix et au maintien des nuds voisins dans le rseau logique sont dicts de manire rigide : par exemple le choix des voisins est souvent guid par le rsultat dune fonction de hachage. Ceci implique que les dveloppeurs dapplications distribues pair--pair doivent soit se contenter du rseau logique propos, soit en concevoir un ddi leur application. An de rpondre ce problme, nous proposons le concept de rseau logique mallable. Dnition A.1 : rseau logique mallable. Un rseau logique mallable est dni comme un rseau logique pair--pair au sein duquel les caractristiques des applications distribues lutilisant peuvent inuencer la structure mme du rseau logique. Le double but poursuivi par un rseau logique mallable est : 1) optimiser les performances des applications utilisatrices partir du rseau logique, tout en 2) conservant les proprits de passage lchelle et de tolrance la volatilit de lapproche rseau logique pair--pair. An de raliser et dvaluer le concept de rseau logique mallable, nous avons construit un rseau logique mallable spcique que nous avons appel MO VE. MO VE combine des lments dun rseau logique non structur avec les caractristiques des applications. La structure et le comportement du rseau sont inuencs la fois par le rseau logique non structur sous-jacent et par les caractristiques des applications. Cette inuence peut tre 1) explicitement spcie par les applications, ou 2) due aux caractristiques dtectes automatiquement par nos algorithmes. Dans les rseaux logiques pair--pair, chaque nud maintient une liste de nuds voisins. Lensemble de ces listes dtermine la relation qui connat qui. Les listes de nuds voisins ne contiennent pas tous les nuds du systme mais seulement quelques-uns [41, 27, 99]. MO VE propose des algorithmes pour la maintenance des listes de voisins, la propagation de mises jour, et la rsistance la volatilit. Lorsque les applications ont peu de communications, le rseau logique maintenu par MO VE ressemble un rseau logique non-structur classique. Par contre, au fur et mesure que les caractristiques des applications sont dtectables, il sadapte lapplication tout en conservant une partie de sa structure par dfaut. Les applications pair--pair collaboratives, comme un tableau blanc distribu, un service de confrence audio et vido, un service de gestion de donnes rpliques ou une plateforme de jeux distribue sont des applications motivantes pour un rseau logique pair-pair comme MO VE. En effet, elles prsentent le point commun de reposer sur une notion de groupe applicatif. Chaque processus applicatif appartient un ou plusieurs groupes et interagit avec les autres processus des mmes groupes. Par exemple, les membres dun mme groupe peuvent partager un tat qui doit tre mis jour (le tableau blanc, le tableau de jeu, les copies dune donne rplique, etc.). Prendre en compte cette notion de groupe au niveau du rseau logique permet de faire proter toute application de cette optimisation sans quelle ait le prendre en compte de manire spcique. MO VE permet de telles applications reposant sur la notion de groupe dinuencer le rseau logique qui peut tre utilis conjointement par de multiples applications collaboratives. Le but du rseau logique MO VE est triple.
tel-00411447, version 1 - 27 Aug 2009
157
Jeu B
Noeuds
Jeu A Plateforme de jeux
F IG . A.1 Une plate-forme de jeux collaborative.
tel-00411447, version 1 - 27 Aug 2009
La connectivit. Le diamtre du graphe du rseau logique doit rester petit an de permettre aux requtes dtre propages rapidement. Mises jour. Les mises jour au sein des groupes applicatifs doivent tre efcaces. Tolrance la volatilit. Le rseau doit conserver ses proprits en prsence de volatilit. Lide de dpart de notre approche est de maintenir sur chaque nud des listes de voisins qui par dfaut ne contiennent que des liens non-applicatifs, cest--dire des voisins choisis alatoirement. Ensuite, lorsque des groupes applicatifs se forment, certains des voisins nonapplicatifs sont automatiquement remplacs par des voisins qui se situent dans le mme groupe applicatif. Un voisin non-applicatif peut soit devenir un voisin applicatif si les voisins appartiennent au mme groupe ou tre remplac par un voisin applicatif.
A.1.2
Exemples de scnarios
Considrons la plate-forme de jeux collaborative grande chelle reprsente par la gure A.1 comme exemple dapplication. Des dizaines de milliers de nuds rpartis sur tout Internet peuvent participer cette application. Pour des raisons de performances la taille des listes de voisins sur chaque nud doit tre borne. En effet, chaque entre dans ces listes correspond un voisin qui doit tre surveill et dont ltat doit tre maintenu jour. Par consquence, chaque nud na quune vision partielle de la plate-forme complte. Ceci ne doit pas avoir un impact ngatif sur les proprits recherches par lapplication comme la connectivit, lefcacit de la propagation des mises jour et la tolrance la volatilit. Connectivit. Un rseau logique est dit connect sil existe un chemin (succession dartes ou liens) entre chaque paire de nuds. Cette proprit est trs importante car elle apporte la garantie que tout nud peut communiquer avec tout autre nud dans le rseau. Un nud particulier, par exemple le noir sur la gure A.1, peut avoir rechercher une partie de jeu spcique au sein de la plate-forme, par exemple le jeu A. Seulement un sousensemble des nuds participe ce jeu, disons quelques dizaines. Il est tout fait possible quaucun des voisins contenus dans la liste de voisins du nud noir ne participe cette
158 partie-l. Il faut que lensemble de la plate-forme de jeu soit connecte an de donner un moyen tout nud datteindre nimporte quel autre nud, ventuellement via un long chemin. La recherche dun nud participant au jeu A dpend de lapplication : dans la pratique, cela peut consister visiter une page sur Internet, consulter un outil de recherche spcialis ou encore a envoyer une recherche de type inondation travers le rseau logique. des ns de performance, le diamtre du rseau doit tre aussi petit que possible mme si les listes de voisins sont partielles. Notons cependant quil suft un nouveau joueur de localiser un des joueurs dune partie pour tre en mesure de joindre tous les autres nuds de la partie. Mises jour efcaces. Au cours dune partie de jeu, les joueurs possdent chacun la rplique dun objet reprsentant ltat courant de la partie : selon lapplication, cela peut tre un tableau blanc, une donne rplique, etc. Chaque fois quun joueur joue, il met jour sa rplique de lobjet. An que les autres joueurs puissent jouer, ils doivent voir les modications apportes par le joueur qui vient de jouer. Pour cela, les mises jour doivent tre propages de manire efcace au sein dun groupe applicatif, par exemple le jeu A ou le jeu B sur la gure A.1. Au niveau du rseau logique, le moyen doptimiser la vitesse de propagation de ces mises jour est de limiter le nombre de sauts dans le rseau logique entre deux nuds appartenant au mme groupe applicatif. Tolrance la volatilit. Parmi plusieurs milliers de nuds rpartis travers Internet, il est trs probable que quelques-uns subissent une faute ou se retrouvent dconnects [97]. Au niveau de la plate-forme entire, cela ne doit pas mener rompre la connectivit du rseau logique. Au niveau des groupes applicatifs, de tels vnements ne doivent pas stopper les communications : les nuds restants doivent rests connects entre eux. Dautre part, le dpart soudain dun nud peut supprimer quelques chemins dans le graphe du groupe applicatif ce qui implique que le diamtre du graphe du groupe risque daugmenter. Cependant, les mcanismes de propagation des mises jours doivent rester efcaces.
tel-00411447, version 1 - 27 Aug 2009
A.2 Conception dun rseau logique pair--pair mallable

Le premier but dun rseau logique est de connecter entre eux les diffrents nuds. La premire proprit remplir est donc la connectivit du rseau. De plus, nous avons soulign, dans la section prcdente, limportance de fournir un support pour des propagations de mise jour efcaces au sein des groupes applicatifs. Ceci peut tre favoris en introduisant un peu de regroupement (clustering) au sein du rseau logique. Il est ncessaire de prserver la fois la connectivit et le regroupement lorsque lon prend en compte la nature dynamique de lenvironnement. Proprits des graphes alatoires. Les graphes alatoires prsentent de bonnes proprits en terme de connectivit et de distribution de degrs [48, 10]. Par exemple, si chaque sommet dun graphe alatoire de taille N (N grand) a au moins log(N ) sommets voisins choisis alatoirement (selon une distribution uniforme) alors le graphe alatoire aura une trs grande
159
(taille de la liste de voisins)
Liens nonapplicatifs
Frontire
Liens applicatifs
F IG . A.2 La liste de voisins sur chaque nud. probabilit dtre connexe [21]. Lestimation de la taille (N ) dun systme distribu, grande chelle, dynamique a fait lobjet de recherches [72]. Cependant, nous visons des chelles de quelques milliers quelques dizaines de milliers de nuds, aussi pouvons-nous prendre une borne suprieure : 50 liens par nuds, par exemple, laissent une grande marge de scurit pour connecter thoriquement jusqu 51021 nuds. Les graphes alatoires prsentent galement une bonne distribution des degrs. Un rseau logique bas sur un graphe alatoire peut bncier de cela pour offrir une bonne distribution de charge. Pour toutes ces raisons, les algorithmes de MO VE essayent de conserver une partie du rseau logique proche dun graphe alatoire. Les nuds maintiennent des listes de voisins composes de structures contenant notamment lidentiant de chaque voisin. Nous appelons ces structures liens car elles reprsentent les liens logique reliant deux voisins entre eux. Pour chaque nud, une limite suprieure (l) est impose sur la taille de la liste de voisins. Cette limite est dabord initialise en fonction dune estimation de la taille du rseau (elle doit tre suprieure au logarithme du nombre de nuds prsents dans le rseau). Ensuite, pendant lexcution, cette limite peut tre repousse si les ressources physiques du nud le permettent. Les listes de voisins sont composes de deux types de lien : les liens non-applicatifs et les liens applicatifs. La gure A.2 reprsente la liste de voisins dun nud. Liens non-applicatifs. Les liens non-applicatifs sont responsables de maintenir le rseau logique global proche dun graphe alatoire avec un faible degr de regroupement (clustering degree en anglais). Si lapplication est dans un tat qui ne ncessite pas de regroupement, par exemple lors de son initialisation, les listes de voisins ne vont contenir que des liens de type non-applicatif. Rappelons que les nuds nont pas besoin dune connaissance globale et que le nombre de liens non-applicatifs peut varier dun nud lautre, par exemple en fonction de leur ressources. Liens applicatifs. An de regrouper ensemble les nuds qui appartiennent un groupe i, chaque membre du groupe i cre ki liens applicatifs vers dautres membres du groupe i choisis de manire alatoire. Ce regroupement favorisera les propagations de mises jour entre les membres du groupe. Cela va galement favoriser la diffusion efcace de messages au niveau
tel-00411447, version 1 - 27 Aug 2009
160
A B D C E
F IG . A.3 Mcanisme de connexion. applicatif. Le paramtre ki est dtermin par lapplication et il doit tre au moins log(Ri ) , o Ri est le nombre de membres du groupe i. Le but est de crer un graphe fortement connect spcique au groupe i, cest--dire avec une petite longueur de chemin caractristique (characteristic path length). La longueur de chemin caractristique dun groupe est la moyenne des longueurs de plus court chemin entre chaque paire de nuds du groupe.
tel-00411447, version 1 - 27 Aug 2009
Politique de remplacement. Quand un lien applicatif pour le groupe i pointant sur le nud n doit tre cr, il sera ajout la liste de voisins selon quatre manires diffrentes. 1. Si la liste de voisins na pas atteint la limite suprieure l, et quil nexiste pas dj de lien non-applicatif pointant vers n, un nouveau lien sera ajout la liste. 2. Si la limite suprieure de la liste de voisins a t atteinte mais que le nud a sufsamment de ressources disponibles pour maintenir une liste de voisins plus grande, il peut augmenter la limite suprieure l an de pouvoir ajouter le lien. 3. Si le nud ne peut pas augmenter la taille de sa liste, dans ce cas un lien non-applicatif choisi alatoirement sera supprim et le lien applicatif ajout. 4. Enn, sil existe un lien non-applicatif pointant vers n, dans ce cas il est transform en lien applicatif.
A.2.1
Conserver la connectivit du rseau
Le compromis entre les bonnes proprits des graphes alatoires et celles apportes en favorisant le regroupement de nuds peut tre rgl en ajustant certains paramtres. Le premier est la taille maximale de la liste de voisins l sur chaque nud, qui est maintenue comme expliqu ci-dessus. La deuxime est ki , qui limite le nombre de liens applicatifs qui participent au groupe i. Si l i ki est sufsamment grand (en pratique quelques dizaines pour lchelle que nous visons), cest--dire que la liste de voisins contient sufsamment de liens non-applicatifs, les bonnes proprits des graphes alatoires sont maintenues malgr les regroupements de nuds crs en prenant lapplication en compte. Dune autre ct, il est important de remarquer que i ki peut-tre plus grand que le nombre de liens applicatifs. Cela est d au fait que certains liens applicatifs peuvent tre partags par de multiples groupes quand les intersections des groupes sont non vides.
161
Un nouveau nud se connecte sur le rseau logique (par exemple le nud noir sur la gure A.3) en contactant un des membres du rseau. Si le nud qui reoit la requte de connexion a sufsamment despace libre dans sa liste de voisins, il va rpondre en envoyant sa liste de voisins courante et ajoutera un lien non-applicatif pointant sur le nouveau nud. Si la taille de sa liste de voisins a atteint la limite suprieure (ce qui est le cas pour les nuds A et B sur la gure A.3), la requte de connexion est retransmise un voisin choisi alatoirement. La retransmission de la requte de connexion est associe une dure de vie maximum en nombre de saut (Time To Live ou TTL). Si tous les nuds qui reoivent la requte de connexion ont une liste de voisins pleine, le TTL va atteindre 0 et le dernier nud ayant reu la requte de connexion sera forc dajouter un lien non-applicatif vers le nouveau nud (en remplaant un lien non-applicatif). Le nud acceptant la requte rpond en envoyant sa liste de voisins (le nud C sur la gure A.3). Le nouveau nud utilise ensuite la liste de voisins reue pour crer sa propre liste. Le protocole de dtection de fautes est bas sur les protocoles de SWIM (pour Scalable Weakly-consistent Infection-style process group Membership [41]). Le temps est divis en priodes de dure T secondes. Chaque nud envoie chaque priode un message ping lun de ses voisins. Le nud cible est choisi en parcourant un tableau reprsentant une permutation alatoire de la liste de voisins. Chaque fois que le tableau est parcouru compltement, une nouvelle permutation alatoire est calcule. Le nud attend une rponse au message ping avec un dlai de garde de t (< T ) secondes. Si la rponse nest pas reue temps, un message ping indirect est envoy y nuds. Ces y nuds vont envoyer un message ping au nud initialement slectionn et sils reoivent une rponse, cette dernire est retransmise au nud initiateur du message ping. Les messages ping indirects peuvent permettre de contourner des problmes rseaux temporaires. En revanche, si aucune rponse nest reue avant la n de la prochaine priode du protocole, le nud cible est suspect dtre dfaillant. Au dbut de chaque priode, tous les nuds qui ont t suspects sont supprims de la liste de voisins. De manire obtenir un rseau logique avec un faible coefcient de regroupement et une bonne distribution des degrs entrant sur les nuds, toutes les U priodes de protocole chaque nud vrie si la liste de ses liens non-applicatifs a t modie. Sil ny a pas eu de modications aprs U priodes, il envoie un message de connexion un nud choisi alatoirement. Avec la liste de voisins reue en rponse, le nud va essayer de remplacer une fraction2 choisie alatoirement de sa liste de voisins. Remarquons que plus U est petit, plus le remplacement sera signicatif et plus vite le rseau logique tendra vers un coefcient de regroupement faible et stable.
tel-00411447, version 1 - 27 Aug 2009
A.2.2
Communication de groupe
Comme expliqu prcdemment, quand un nouveau lien applicatif est cr, il en rsulte une suppression dun lien non-applicatif except si le nud a sufsamment de ressources pour agrandir la taille de sa liste de voisins. De cette manire, nous gardons sur chaque nud presque constant le cot de la maintenance des listes de voisin. De plus, un lien applicatif peut tre partag. Par exemple, considrons un nud a qui appartient au groupes i et j.
2
f = 50% dans nos valuations.
162
req (1) req fwd (2)
Initiateur
accepte (4)
New link
Transit
Transit req fwd (3) Acceptation
F IG . A.4 Le mcanisme de marche alatoire. Si le nud b se connecte aux groupes i et j, un seul lien applicatif est cr avec le nud a sachant que ce lien est partag. Un compte du nombre de partages est tenu jour pour les liens partags.
tel-00411447, version 1 - 27 Aug 2009
Marche alatoire pour les liens applicatifs. An de faire face la nature dynamique de linfrastructure et pour viter des topologies pathologiques (chane, anneau, toile, etc.) qui peuvent tre induites par les occurrences de fautes, il est important de rafrachir les liens priodiquement. Cest galement utile an de garantir un court chemin entre deux nuds dun groupe donn. Ajouter O(n) liens non-applicatifs un graphe possdant n sommets rduit le diamtre du graphe O(log(n)) [21, 104]. Ce rsultat ne sapplique qu des graphes bidirectionnels. Aussi nous imposons que tous les liens applicatifs soient bidirectionnels. Quand un lien est cr de a b, b ajoute galement un lien vers a. Si le nud b supprime le lien alors le nud a le supprime galement. Quand un lien applicatif est partag, il est maintenu tant que le nombre de partages est strictement positif. Quand un lien applicatif cesse dtre utilis en tant que tel, il se transforme en lien non-applicatif. Le graphe est rafrachi priodiquement par lexcution des points suivants par chaque nud dun groupe applicatif : 1. lancer une marche alatoire pour dcouvrir un nouveau voisin. La marche alatoire ne traverse pas plus de TTL nuds en utilisant les liens applicatifs associs au groupe ; 2. supprimer un ancien lien quand le nouveau est cr. Bien que le dlai de garde entre chaque marche alatoire soit un paramtre de lapplication, il est important de noter que les nuds appartenant un groupe ne sont pas synchroniss.
A.3 valuation du rseau logique pair--pair MO VE

Nous avons utilis un simulateur vnements discrets dcrit la section A.3.1 an dvaluer notre rseau pair--pair mallable.
163
A.3.1
Simulation par vnements discrets
An dvaluer le rseau pair--pair mallable MO VE (pour langlais Malleable OVEerlay), nous avons choisi de mettre en uvre un simulateur vnements discrets : MO VE S IM. Ce simulateur comprend 5000 lignes de code Java. Ralisme du simulateur. MO VE S IM peut prendre en paramtre des topologies rseaux gnres par GT-ITM [25], un gnrateur reconnu pour sa capacit de produire des topologies ralistes. Des traces dapplications peuvent galement tre prises en compte. Ces deux points permettent daugmenter le ralisme du modle simul et ainsi de rendre les simulations plus dles la ralit. But du simulateur. Le but est de simuler le comportement dun rseau logique pair-pair. Nous nous focalisons sur la gestion des listes de voisins. Le but est de rapprocher les nuds susceptibles davoir de nombreuses communications en rduisant le nombre de sauts qui les sparent. Les groupes de nuds communicant frquemment sont appels groupes applicatifs. Ce simulateur reproduit donc le comportement de chacun des nuds en excutant nos algorithmes de gestion de listes de voisins. En sortie, une trace dexcution est gnre ainsi que les matrices reprsentant les liens entre les nuds pour chacun des groupes applicatifs grs par le rseau mallable. Cela permet dvaluer la connectivit de chaque groupe applicatif, en prsence ou non de fautes. Fonctionnement. linitialisation : 1) une matrice dcrivant les latences/dbits rseau entre les nuds est cre partir de la topologie ; 2) une matrice contenant ltat initial de chacun des nuds est galement calcule ; et 3) des chiers de conguration et des chiers de traces sont utiliss pour gnrer les vnements applicatifs. Ces vnements correspondent aux arrives et aux dparts de nuds dans le rseau pair--pair, aux crations par des nuds de groupes applicatifs, aux arrives et aux dparts de nuds de groupes applicatifs, aux diffusions de messages au sein des groupes applicatifs, et aux dclenchements de dlais de garde. Tous ces vnements sont composs : 1) dune action excuter, 2) de lidentiant du nud devant excuter laction, et 3) dune date dexcution. Ils sont insrs dans une le dvnements trie selon la date. Le simulateur itre ensuite en traitant un vnement de la le chaque itration. Pour chaque vnement, le traitement est le suivant. 1. La date de simulation est avance la date de lvnement courant. 2. Le simulateur charge ltat du nud contenu dans lvnement. 3. Laction de lvnement est excute. Chaque action excute peut modier ltat du nud (sa liste de voisins par exemple) et gnrer de nouveaux vnements dans la le. Les vnements gnrs en cours dexcution sont des rceptions de messages ou des dclenchements de dlais de garde. Quand le temps allou la simulation sest coul3 , les listes de voisins sont analyses an de calculer les matrices de voisinage et les longueurs de chemin caractristiques de chaque groupe applicatif.
3
tel-00411447, version 1 - 27 Aug 2009
La dure de simulation est donne en paramtre.
164 Lensemble des valuations prsentes ici ont t ralises avec ce simulateur vnements discrets. Le but de ces simulations est dillustrer comment le rseau logique MO VE sadapte aux applications, de mesurer la connectivit entre les nuds appartenant un mme groupe applicatif, et enn dvaluer la rsistance du rseau logique face aux fautes. Les simulations effectues avec moins de 2000 nuds utilisent des topologies gnres par le gnrateur GT-ITM, celles utilisant 2000 nuds sont ralises avec une topologie plate, cest--dire une latence et un dbit identique entre chaque nud.
A.3.2
Adaptation du rseau logique.
tel-00411447, version 1 - 27 Aug 2009
Pour analyser comment le rseau logique ragit face aux besoins des applications, nous lanons des simulations sur un rseau de 520 nuds en variant le nombre de groupes crs par les applications. Le paramtre k, correspondant au nombre de liens applicatifs quun nud essaye de conserver pour chaque groupe, est x 5 pour chacun des groupes sur chacun des membres. Nous observons sur la gure A.5 que le nombre de liens total ne change
30 25 20 15 10 5 0 Nombre total de liens Nombre de liens nonapplicatifs Nombre de liens applicatifs
Nombre de liens
10
20
30 40 Nombre de groupes (de taille 100)
50
60
F IG . A.5 Nombre de liens applicatifs et non-applicatifs dans le rseau logique en fonction du nombre de groupes. pas mais que les liens non-applicatifs sont progressivement remplacs par des liens applicatifs. MO VE est donc bien un rseau mallable qui adapte sa structure aux applications.
A.3.3
Partage de liens applicatifs.
La transformation de liens non-applicatifs en liens applicatifs illustre la section prcdente augmente le coefcient de groupement du rseau. Les liens non-applicatifs sont responsables du maintient du rseau global, cest--dire de la connectivit entre les nuds indpendamment de leur appartenance un groupe applicatif. An de conserver un nombre maximal de liens non-applicatifs, les liens applicatifs sont partags lorsque les intersections des groupes sont non-vides. Nous simulons un rseau de 520 nuds dans lequel nous crons 60 groupes applicatifs de taille 100 et de paramtre k gal 5. des n de lisibilit, seuls
165
100 nuds sont illustrs sur la gure A.6. Chaque point de laxe des abscisses reprsente un nud et la diffrence entre les deux courbes reprsente le gain ralis grce au partage.
100 90 80 Nombre de liens 70 60 50 40 30 20 10 400 410 420 430 440 450 460 Identifiants des pairs 470 480 490 500 Liens applicatifs (thorique) Liens applicatifs (rel)
tel-00411447, version 1 - 27 Aug 2009
F IG . A.6 Nombre de liens applicatifs sur chaque nud.
A.3.4
Connectivit au sein des groupes.
Le but premier de notre approche est de permettre aux nuds communiquant frquemment dtre proches au sein du rseau logique. An dvaluer cette connectivit nous simulons un rseau de 2000 nuds au sein duquel sont crs 50 groupes dont les tailles correspondent des slices4 de PlanetLab [124]. Pour chaque groupe, le paramtre k est gal au logarithme de la taille du groupe. La gure A.7 prsente les mesures de longueur de chemin
3.5 3 2.5 2 1.5 1 0.5 0 log(x)/log(7)
Longeur de chemin caractristique
50
100
150 200 250 Taille des groupes
300
350
400
F IG . A.7 Longueur de chemin caractristique pour 50 Groupes PlanetLab. caractristique en fonction de la taille des groupes. Ici, cette longueur reste limite, elle reste infrieure 3.5 pour des groupes de 400 membres. Des simulations effectues avec des tailles de groupes alatoires donnent des rsultats quivalents.
4
une slice correspond un ensemble de nuds virtuels utilis par une application ou un service.
166
A.3.5
Tolrance aux fautes.
Malgr les groupements de nuds raliss pour amliorer les communications des applications, le rseau logique doit rester connect. Pour valuer la tolrance un grand nombre de fautes simultanes, nous avons congur les nuds pour tre dfaillants (dfaillance franche, ou crash) avec une probabilit p aprs 2 heures de temps de simulation. Les simulations ont t effectues sur un rseau de 2000 nuds comprenant 50 groupes dont les tailles sont distribues exponentiellement, et dont les paramtres k sont gaux aux logarithmes des tailles. Avec cette conguration, le rseau logique reste connect tant que la probabilit p est infrieure 0.5, il supporte donc bien un grand nombre de fautes simultanes. Dautres valuations de MO VE sont prsentes dans [MMAG06].
A.4 Analyse
Le rseau logique est trs important pour les applications qui lutilisent. Toutes leur communications seront achemines par lui. Il nous semble donc important que ce rseau prenne en compte les besoins des applications en terme de communication. Au cours de cette collaboration, nous avons conu le rseau logique MO VE que les applications peuvent inuencer an quil sadapte aux schmas de communications et ainsi obtenir des communications performantes. Lvaluation de ce rseau logique montre notamment quil est possible damliorer les communications au sein des groupes applicatifs tout en offrant une bonne tolrance la volatilit. Il est intressant de remarquer que lon peu utiliser la notion de groupes applicatifs dcrite dans cette annexe pour implmenter des groupes de rplication dune donne. Alors que J UX M EM offre des modles de cohrence forte en sappuyant sur la hirarchie, MO VE peut offrir des modles de cohrence plus relchs en se basant sur une approche probabiliste. Il est difcile de dire quune approche est meilleure que lautre, en effet il semble quune approche de type MO VE peut viser une chelle un peu plus grande sur des rseaux de performance moindre, cependant le prix payer est un relchement des contraintes de cohrence des donnes, les applications vises ne sont donc pas les mmes. J UX M EM est adapt des applications de type scientique (comme du calcul matriciel), sur des grilles de calcul. MO VE semble plus adapt des applications collaboratives sur un rseau de type Internet.
tel-00411447, version 1 - 27 Aug 2009
tel-00411447, version 1 - 27 Aug 2009
Sbastien M ONNET
Gestion des donnes dans les grilles de calcul : Support pour la tolrance aux fautes et la cohrence des donnes.
Mots-clefs : Grille de calcul, gestion de donnes, tolrance aux fautes, cohrence de donnes, approche pair--pair, protocoles hirarchiques.
tel-00411447, version 1 - 27 Aug 2009
Les applications scientiques daujourdhui, telles les simulations de grands phnomnes naturels, requirent une grande puissance de calcul ainsi quune importante capacit de stockage. Les grilles de calcul apparaissent comme une solution permettant datteindre cette puissance par la mise en commun de ressources de diffrentes organisations. Ces architectures prsentent en revanche des caractristiques rendant leur programmation complexe: elles sont dynamiques, htrognes, rparties grande chelle. Cette thse sintresse aux problmatiques lies la conception dun service de partage de donnes pour les grilles de calcul. Lobjectif est de permettre un accs transparent aux donnes, en automatisant la localisation, le transfert, la gestion de la persistance et de la cohrence des donnes partages. Nous nous sommes plus particulirement concentrs sur la gestion de la cohrence et de la persistance des donnes en environnement dynamique. Dans un tel contexte, assurer la persistance ncessite la mise en place de mcanismes de tolrance aux fautes. Nous proposons une approche pour grer conjointement ces deux aspects via une architecture logicielle multiprotocole permettant de coupler diffrents protocoles de cohrence avec diffrents mcanismes de tolrance aux fautes. Nous proposons une conception hirarchique de cette architecture, adapte la topologie rseau des grilles de calcul. Ces contributions ont t mises en uvre au sein du service de partage de donnes pour grilles J UX M EM. Les exprimentations menes sur la grille exprimentale Grid5000 montrent que notre conception hirarchique permet damliorer les performances des accs aux donnes partages.

Monnet06 Thesis

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Monnet06 Thesis

Încărcat de

Drepturi de autor:

Formate disponibile

Numro dordre : 3462

DOCTEUR DE LUNIVERSIT DE RENNES 1

tel-00411447, version 1 - 27 Aug 2009

Monsieur Sbastien Monnet

tel-00411447, version 1 - 27 Aug 2009

tel-00411447, version 1 - 27 Aug 2009

tel-00411447, version 1 - 27 Aug 2009

Table des matires

tel-00411447, version 1 - 27 Aug 2009

tel-00411447, version 1 - 27 Aug 2009

tel-00411447, version 1 - 27 Aug 2009

Partie III Mise en uvre et valuation

tel-00411447, version 1 - 27 Aug 2009

Partie IV Conclusion et perspectives

Liste des dnitions

tel-00411447, version 1 - 27 Aug 2009

tel-00411447, version 1 - 27 Aug 2009

tel-00411447, version 1 - 27 Aug 2009

1.1 Objectifs de la thse

1.2 Contributions et publications

tel-00411447, version 1 - 27 Aug 2009

Articles dans des revues internationales

Confrences internationales avec comit de lecture

tel-00411447, version 1 - 27 Aug 2009

Confrences nationales avec comit de lecture

tel-00411447, version 1 - 27 Aug 2009

1.3 Organisation du manuscrit

tel-00411447, version 1 - 27 Aug 2009

Contexte dtude : gestion des donnes dans les grilles de calcul

tel-00411447, version 1 - 27 Aug 2009

Les donnes dans les grilles de calcul

Chapitre 2 Les donnes dans les grilles de calcul

tel-00411447, version 1 - 27 Aug 2009

2.1 Les grilles de calcul

2.1 Les grilles de calcul

tel-00411447, version 1 - 27 Aug 2009

Les fdrations de grappes

Chapitre 2 Les donnes dans les grilles de calcul

tel-00411447, version 1 - 27 Aug 2009

Switch Lien rseau intragrappe Lien rseau intergrappe

F IG . 2.1 Un cas particulier de grilles : les fdrations de grappes.

Un exemple de grille : Grid5000

2.2 Les applications de couplage de codes

tel-00411447, version 1 - 27 Aug 2009

F IG . 2.2 Carte des sites du projet Grid5000.

2.2 Les applications de couplage de codes

Chapitre 2 Les donnes dans les grilles de calcul

tel-00411447, version 1 - 27 Aug 2009

Interactions entre les codes parallles (couplage)

2.2 Les applications de couplage de codes

contrle (scalaires) vitesse pression

tel-00411447, version 1 - 27 Aug 2009

Chapitre 2 Les donnes dans les grilles de calcul

tel-00411447, version 1 - 27 Aug 2009

Application de couplage de codes Fdration de grappes

2.3 Approches pour le partage de donnes dans les grilles

2.3 Approches pour le partage de donnes dans les grilles

Le partage de donnes dans les grilles de calcul

tel-00411447, version 1 - 27 Aug 2009

Chapitre 2 Les donnes dans les grilles de calcul

tel-00411447, version 1 - 27 Aug 2009

2.3 Approches pour le partage de donnes dans les grilles

tel-00411447, version 1 - 27 Aug 2009

Chapitre 2 Les donnes dans les grilles de calcul