Contribution à la gestion de la cohérence de répliques de ...

République Algérienne Démocratique et Populaire Ministère de l’Enseignement Supérieur et de la Recherche Scientifique

UNIVERSITE D’ORAN ES-SENIA Faculté des Sciences Département

Informatique

Thèse De

Doctorat d’Etat

Spécialité : Informatique

Présenté et soutenue publiquement Par

Ghalem BELALEM

Novembre 2007 Titre :

Contribution à la gestion de la cohérence de répliques de fichiers

dans les systèmes à large échelle

jury Président: Prof. Hafid Haffaf Université d’Oran – Es-Sénia Directeur:

Prof. Yahya Slimani Faculté des Sciences de Tunis

Examinateur: Prof. Bouziane Beldjilali Université d’Oran – Es-Sénia

Prof. Hafida Belbachir Université USTO – MB d’Oran

Prof. Abdelkader Benyettou Université USTO – MB d’Oran

Année Universitaire 2006-2007

Je dedie ce travail

A ma famille

A mes parents

i

Remerciements

Merci mon Dieu

Cette these n’aurait pu aboutir sans l’aide et le soutien de nombreuses personnes et je tiens

a les en remercier. Je prendrais donc quelques lignes pour leur temoigner ma gratitude, et que

tous ceux que j’oublie me pardonnent ...

Je voudrais tout d’abord remercier mon directeur de these, Monsieur Yahya Slimani, Pro-

fesseur a la Faculte des Sciences de Tunis, de m’avoir propose un sujet aussi passionnant, pour

son soutien et son aide permanente et surtout pour sa confiance. Merci d’avoir pris le temps de

m’expliquer ... J’ai beaucoup appris a tes cotes.

Mes respects et mes remerciements a mon jury. Je tiens a remercier Monsieur Hafid Haffaf,

Professeur a la Faculte des Sciences de l’Universite d’Es-Senia, pour m’avoir fait l’immense

honneur de presider le jury de ma soutenance.

Je remercie egalement Madame Hafida Belbachir, Professeur a la Faculte de l’Universite

USTO-MB d’Oran, Monsieur Bouziane Beldjilali, Professeur a la Faculte des Sciences de l’Uni-

versite d’Es-Senia, et Monsieur Abdelkader Benyettou, Professeur a la Faculte des Sciences de

l’Universite USTO-MB d’Oran pour avoir bien voulu consacrer une part de leurs temps a exa-

miner et a evaluer cette these.

J’ai eu la chance de participer, meme si c’est dans une periode relativement courte, aux

travaux de l’equipe de recherche du Professeur Yahya Slimani au sein du Departement des

Sciences de l’informatique de la Faculte des Sciences de Tunis. Je voudrais remercier tous ses

membres qui en font un environnement de travail exceptionnel, en particulier Cherif, Amir

et Moez pour leur aide et leurs encouragements. Je les remercie pour leur disponibilite, leur

reactivite a la lecture et a la correction de mes documents, et pour leur soutien constant.

Je tiens a exprimer mes sinceres remerciements a mon ami et collegue Belabbes Yagoubi

pour ses remarques et son soutien dans des moments difficiles, et surtout les aventures que nous

avons passe ensemble.

Enfin un grand merci a tous mes amis qui m’ont encourage de pres ou de loin durant la

preparation de cette these ; je pense particulierement a tous les membres de ma famille, a ma

femme et a ma petite fille a qui j’ai vole beaucoup de temps.

ii

Table des matieres

Introduction generale 1

Chapitre 1

Etat de l’art sur les grilles de calcul et de donnees

1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.2 Concept de grille de calcul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.3 Architecture d’une grille . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.4 Evolution des grilles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.4.1 Premiere generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.4.2 Deuxieme generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.4.3 Troisieme generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.5 Les differents types de grilles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.5.1 Les grilles d’information . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.5.2 Les grilles de stockage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.5.3 Les grilles de calcul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.6 Principaux enjeux des grilles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.6.1 Partage de ressources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.6.2 Acces securise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1.6.3 Utilisation efficace de ressources . . . . . . . . . . . . . . . . . . . . . . . 14

1.6.4 Abolition de la distance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1.6.5 Mise en place de normes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1.7 Domaines d’application des grilles . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1.7.1 Calcul distribue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1.7.2 Calcul a haut debit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1.7.3 Calcul a la demande . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

1.7.4 Traitement massif de donnees . . . . . . . . . . . . . . . . . . . . . . . . . 16

1.7.5 Travail collaboratif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

1.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

iii

Chapitre 2

Protocoles de replication et de coherence

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.2 Principe de replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.3 Les techniques de replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.3.1 Avantages de la replication . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.3.2 Inconvenients de la replication . . . . . . . . . . . . . . . . . . . . . . . . 21

2.4 Caracteristiques d’un protocole de replication . . . . . . . . . . . . . . . . . . . . 21

2.4.1 Nombre de copies concernees par une requete . . . . . . . . . . . . . . . . 22

2.4.2 Droits d’acces aux copies . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.4.3 Instant de synchronisation des repliques . . . . . . . . . . . . . . . . . . . 23

2.4.4 Initiative de l’operation de mise a jour . . . . . . . . . . . . . . . . . . . . 24

2.4.5 Nature des mises a jour . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.4.6 Cheminement des mises a jour . . . . . . . . . . . . . . . . . . . . . . . . 25

2.4.7 Capture des mises a jour . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.4.8 Gestion de la concurrence et transparence a la replication . . . . . . . . . 25

2.4.9 Gestion des conflits et des fautes . . . . . . . . . . . . . . . . . . . . . . . 26

2.5 Protocoles de replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.5.1 Protocole de replication passive . . . . . . . . . . . . . . . . . . . . . . . . 26

2.5.2 Protocole de replication active . . . . . . . . . . . . . . . . . . . . . . . . 27

2.5.3 Protocole de replication semi-active . . . . . . . . . . . . . . . . . . . . . 28

2.6 Protocoles de coherence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.6.1 Protocoles pessimistes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.6.2 Protocoles optimistes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.6.3 Etude comparative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Chapitre 3

Modele hybride pour la gestion de coherence

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.2 Concepts et terminologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.3 Pourquoi les clusters ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.4 Modele propose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.4.1 Modele de base pour la gestion de la coherence . . . . . . . . . . . . . . . 38

3.4.2 Modele general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.5 Flux de communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.6 Caracteristiques du modele propose . . . . . . . . . . . . . . . . . . . . . . . . . . 43

iv

3.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Chapitre 4

Approche hybride pour la gestion de la coherence

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.2 Gestion de coherence intra-site . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.2.1 Notations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.2.2 Gestion de coherence intra-site basee sur la strategie uni-maıtre . . . . . . 49

4.2.3 Gestion de coherence intra-site basee sur la strategie multi-maıtres . . . . 53

4.3 Gestion de la coherence inter-sites . . . . . . . . . . . . . . . . . . . . . . . . . . 61

4.4 Placement de repliques vs gestion de coherence . . . . . . . . . . . . . . . . . . . 62

4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Chapitre 5

Etude experimentale

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

5.2 Environnement d’experimentation . . . . . . . . . . . . . . . . . . . . . . . . . . 66

5.3 Metriques utilisees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

5.3.1 Notations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

5.3.2 Parametres de simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

5.4 Resultats experimentaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

5.4.1 Experience 1 : Impact du nombre de requetes . . . . . . . . . . . . . . . . 69

5.4.2 Experience 2 : Impact du type de requetes . . . . . . . . . . . . . . . . . . 73

5.4.3 Experience 3 : Impact du nombre de fichiers . . . . . . . . . . . . . . . . . 77

5.4.4 Experience 4 : Impact de la largeur de la bande passante . . . . . . . . . 81

5.4.5 Experience 5 : Impact du nombre de clusters . . . . . . . . . . . . . . . . 85

5.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Conclusion generale et perspectives

Bibliographie 94

v

Table des figures

1.1 Exemple d’une grille informatique . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.2 Architecture en couches d’une grille . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.3 Constituants des couches d’une grille . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.4 Fonctionnalites des couches d’une grille . . . . . . . . . . . . . . . . . . . . . . . 9

1.5 Evolution des grilles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.6 Courtier de ressources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.1 Compromis performance/fiabilite . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.2 Environnement d’utilisation de la technique de replication . . . . . . . . . . . . . 20

2.3 Approches maıtre-esclaves et copies identiques . . . . . . . . . . . . . . . . . . . 23

2.4 Exemple de protocole de replication passive . . . . . . . . . . . . . . . . . . . . . 27

2.5 Exemple de protocole de replication active . . . . . . . . . . . . . . . . . . . . . . 28

2.6 Exemple de protocole de replication semi-active . . . . . . . . . . . . . . . . . . . 29

2.7 Acces aux donnees repliquees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.1 Coherence vs Disponibilite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.2 Positionnement de l’approche proposee . . . . . . . . . . . . . . . . . . . . . . . . 36

3.3 Composants d’un site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.4 Modele de base pour la gestion de la coherence . . . . . . . . . . . . . . . . . . . 39

3.5 Principales fonctions d’un gestionnaire de repliques . . . . . . . . . . . . . . . . . 40

3.6 Modele hierarchique et distribue pour la gestion de coherence de repliques . . . . 41

3.7 Exemple d’une grille reelle representee par notre modele . . . . . . . . . . . . . . 42

3.8 Diagramme de classes du modele de coherence propose . . . . . . . . . . . . . . . 43

4.1 Architecture du service de gestion de coherence de repliques . . . . . . . . . . . . 46

4.2 Diagramme de l’approche hybride de gestion de la coherence de repliques . . . . 47

4.3 Cas de convergence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.4 Cas de divergence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.5 Cas de conflit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

vi

4.6 Diagramme des etats d’une replique . . . . . . . . . . . . . . . . . . . . . . . . . 58

4.7 Principales etapes du service de gestion de coherence inter-sites . . . . . . . . . . 61

5.1 Interface du simulateur RepSim . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

5.2 Variation du temps de reponse/#Requetes pour la strategie SSP . . . . . . . . . 70

5.3 Variation du temps de reponse/#Requetes pour la strategie ASP . . . . . . . . . 70

5.4 Courbe de variation du cout de communication relative au tableau 5.5 . . . . . . 71

5.5 Variation du temps de reponse/#Requetes pour la strategie SSP . . . . . . . . . 74

5.6 Variation du temps de reponse/#Requetes pour la strategie ASP . . . . . . . . . 74

5.7 Variation du nombre de divergences/#Requetes . . . . . . . . . . . . . . . . . . . 75

5.8 Variation du nombre de conflits/#Requetes . . . . . . . . . . . . . . . . . . . . . 76

5.9 Variation du temps de reponse/#Fichiers pour la strategie SSP . . . . . . . . . . 78

5.10 Variation du temps de reponse/#Fichiers pour la strategie ASP . . . . . . . . . . 78

5.11 Variation du cout de communication/#Fichiers pour l’approche hybride . . . . . 79

5.12 Variation du nombre de divergences/#Fichiers pour la strategie SSP . . . . . . . 80

5.13 Variation du nombre de divergences/#Fichiers pour la strategie ASP . . . . . . . 80

5.14 Variation du nombre de conflits/#Fichiers pour la strategie SSP . . . . . . . . . 81

5.15 Variation du nombre de conflits/#Fichiers pour la strategie ASP . . . . . . . . . 81

5.16 Variation du temps de reponse en fonction de la largeur de la bande passante

pour la strategie SSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

5.17 Variation du temps de reponse en fonction de la largeur de la bande passante

pour la strategie ASP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

5.18 Variation du nombre de conflits en fonction de la largeur de la bande passante . 85

5.19 Variation du temps de reponse/#Clusters pour la strategie SSP . . . . . . . . . . 86

5.20 Variation du temps de reponse/#Clusters pour la strategie ASP . . . . . . . . . 86

5.21 Variation du nombre de divergences/#Clusters . . . . . . . . . . . . . . . . . . . 88

5.22 Variation du nombre de conflits/#Clusters . . . . . . . . . . . . . . . . . . . . . 88

vii

Introduction generale

1

La connexion a grande echelle des ordinateurs aux reseaux de communication et les meca-

nismes qui permettent leur interoperabilite ont permis la mise en œuvre d’applications utilisant

de tres grandes masses de donnees [26, 27]. Les quantites de donnees utilisees par ces applications

s’echelonnement jusqu’a l’ordre du PetaOctet en stockage (ex : un million de machines stockant

chacune 1 Go de fichiers multimedia) ou du TeraOctet/seconde en debit agrege moyen (ex : un

million de machines transferant chacune 1Mb/s de fichiers multimedia) [7, 37].

A l’heure actuelle, les infrastructures logicielles utilisees pour stocker et traiter ces grandes masses

de donnees sont de deux types : les systemes de grilles (GRID) [24, 27] et les systemes Pair a

Pair (P2P) [27, 37]. Ces systemes possedent deux caracteristiques fondamentales [25, 27] :

– Echelle du nombre de ressources : des etudes ont montre qu’il existe un facteur 1000 par

rapport aux systemes distribues en terme de nombre de ressources [7, 37] ;

– Complexite des ressources : les ressources de ces nouveaux systemes sont constituees d’ordi-

nateurs capables d’executer des programmes complexes et possedant une forte autonomie.

Tous les grands projets scientifiques et industriels actuels essayent d’utiliser les infrastruc-

tures de type grille, pour tirer profit de leurs capacites en puissance de calcul et en stockage

de donnees [1, 43, 53]. Ce type d’infrastructure constitue un environnement privilegie pour le

partage de ressources et de services. Les techniques de partage, utilisees par les grilles de don-

nees, sont le plus souvent basees sur le principe de replication pour assurer une disponibilite tres

elevee des donnees et une reduction de la latence du reseau [53].

Dans ce contexte, un meme objet (fichier, base de donnees, service, programme, etc.) peut

etre replique en autant de copies que necessaire. Chaque copie etant detenue et accedee par un ou

plusieurs utilisateurs, leur gestion pose un probleme de nature complexe, a savoir le maintien de

leur coherence [21, 60]. La complexite de gestion de cette coherence est due a plusieurs facteurs,

parmi lesquels les plus importants sont [31, 38, 39] : (i) le nombre tres eleve de repliques ; (ii)

le passage a l’echelle ; (iii) l’espace de stockage des repliques qui est en general tres largement

distribue ; (iv) l’heterogeneite des systemes de gestion des repliques. De plus, l’utilisation de

techniques de replication pose des problemes particuliers, comme par exemple [4, 6] :

– Trouver le bon placement des repliques ;

– Decider, pour un objet donne, du nombre minimal (ou maximal) de repliques ;

– Choisir une replique lors d’une demande d’acces.

Les approches existantes pour la gestion de la coherence de repliques offrent un ensemble li-

mite de garanties d’un point de vue performance et qualite de service. Deux familles d’approches

sont actuellement utilisees pour maintenir la coherence de repliques [5, 50] : les approches pes-

simistes et les approches optimistes.

La replication basee sur des approches dites pessimistes [6, 36, 50] donne l’illusion a l’uti-

2

lisateur qu’il n’existe qu’une seule copie d’un objet donne. Les lectures peuvent etre faites sur

n’importe quelle copie tandis qu’une ecriture doit etre appliquee de maniere atomique sur toutes

les copies. Pour la replication basee sur des approches optimistes [50], il est generalement admis

que les copies d’un meme objet peuvent diverger, c’est-a-dire, qu’elles peuvent avoir des contenus

differents a un instant t.

De part leurs caracteristiques, les approches pessimistes ont montre leurs difficultes a s’ap-

pliquer aux systemes a large echelle, a l’inverse des approches optimistes qui ne propagent pas

les mises a jour d’une facon instantanee.

Dans le but de contribuer a la resolution du probleme de gestion de la coherence de repliques

dans les systemes a large echelle, nous avons propose, dans le cadre de cette these, un modele

a deux niveaux pour la gestion de la coherence des repliques dans les grilles de donnees, avec

comme objectif la necessite de trouver un compromis entre les performances des reseaux de com-

munication et une divergence controlee des repliques, qui facilitera la reconciliation en cas de

conflits. De plus, ce modele devrait permettre d’atteindre un degre de maintien de la coherence

independamment de la strategie de replication utilisee.

Contributions

Nos contributions consistent en la proposition d’un modele, pour la gestion de la coherence

de repliques dans les systemes a grande echelle, qui combine a la fois les approches pessimistes,

qui favorisent la qualite de service, et les approches optimistes qui se focalisent sur l’amelioration

des performances. Nous pouvons situer notre contribution sur deux aspects essentiels :

– D’un point de vue gestion de coherence, nous proposons une approche hybride, qui tire

profit des avantages des approches pessimiste et optimiste, afin de l’adapter aux applica-

tions de grande taille, ou la qualite de service rendue est plus au moins une contrainte

forte et ou le temps de reponse doit etre acceptable.

– D’un point de vue modele, notre approche est supportee par un modele hierarchique et

distribue a deux niveaux, qui lui permet de s’adapter au passage a l’echelle et d’etre flexible.

Plan du manuscrit

Les travaux que nous avons mene dans le cadre de la problematique de la gestion de la

coherence de repliques dans les systemes a large echelle, sont resumes dans ce manuscrit qui est

compose, en plus d’une introduction et d’une conclusion, de 5 chapitres.

Le Chapitre 1, intitule Etat de l’art sur les grilles de calcul et de donnees, definit le cadre

dans lequel se situent nos travaux et presente un etat de l’art sur les grilles de calcul et de

3

donnees ainsi que leurs evolutions.

Le Chapitre 2, intitule Protocoles de replication et de coherence, rappelle les fondements

des protocoles de replication de donnees et le probleme de gestion de la coherence de donnees

repliquees. Apres une description des protocoles de gestion de la coherence, nous presentons une

etude comparative entre les protocoles de replication et de coherence qui met en evidence les

avantages ainsi que les limites des protocoles existants.

Le Chapitre 3, intitule Modele hybride pour la gestion de coherence, est articule autour de

la presentation de notre modele de coherence, dont l’objectif est de supporter une gestion des

repliques pour les systemes a grande echelle.

Le Chapitre 4, intitule Approche hybride pour la gestion de coherence, est consacre a la

description detaillee de l’approche de gestion de coherence hybride proposee pour les grilles de

donnees. Notre proposition combine les approches optimistes et pessimistes dans le but d’ame-

liorer les performances et de controler la coherence entre les repliques d’un meme fichier, afin

d’augmenter la qualite de service d’un systeme de gestion de coherence de donnees repliquees.

Dans le but d’ameliorer d’avantage les performances de notre approche, nous l’avons etendu par

un modele economique base sur les encheres [35] pour le placement des repliques de fichiers dans

une grille.

L’experimentation et l’evaluation de notre approche sont discutees dans le Chapitre 5. A

travers une serie d’experimentations, nous essayons de montrer que l’approche proposee permet

d’obtenir un bon compromis entre qualite et performance.

Finalement, nous terminons ce manuscrit par une conclusion qui recapitule a la fois la pro-

blematique que nous avons traite dans cette these, ainsi que les resultats que nous avons obtenu.

Cette presentation est suivie de propositions d’un certain nombre de perspectives de recherche

pour poursuivre la reflexion sur le probleme de la gestion de la coherence de repliques dans les

systemes a large echelle.

4

Chapitre 1

Etat de l’art sur les grilles de calcul

et de donnees

5

1.1. Introduction

1.1 Introduction

Les applications modernes exigent des capacites de calcul et de stockage qui depassent celles

d’un individu ou d’une institution [25, 27]. En plus de cette exigence, l’acces a l’information

doit pouvoir etre accessible n’importe quand, n’importe ou et a partir de dispositifs physiques

tres diversifies (informatique pervasive) [46]. Pour repondre a de telles exigences, il est donc

necessaire de rechercher d’autres types d’architectures differentes des architectures classiques

(sequentielles, paralleles, distribuees et mobiles). Ainsi, l’accroissement constant de la puissance

des ressources et l’immense reserve disponible via Internet, ainsi que la banalisation du haut debit

et des technologies reseaux offrent l’opportunite de globaliser l’acces aux ressources informatiques

largement distribuees dans le monde, pour l’execution d’applications de tres grandes tailles

[7, 25, 27]. C’est cette opportunite qui a permis aux grilles de calcul et de donnees d’emerger

comme un important domaine du calcul parallele et distribue, qui se distingue par son orientation

vers le partage de ressources heterogenes a grande echelle [7, 25, 27].

1.2 Concept de grille de calcul

Le concept de grille de calcul (Grid Computing) a ete introduit, pour la premiere fois en

1999, par Foster et Kesselmann [26] qui l’ont defini par analogie a un reseau electrique. Il n’existe

pas actuellement de consensus sur la definition du concept de grille de calcul et l’on trouve plu-

sieurs definitions de ce concept dans la litterature [10, 24, 47]. Ainsi, Plaszczak et Wellner [47]

definissent une grille de calcul comme une technologie permettant la virtualisation de ressources

pour repondre a leur demande et a leur partage entre plusieurs organisations. La societe IBM

definit une grille de calcul comme une methode utilisant des protocoles standards pour faciliter

les acces aux applications et aux donnees, a la puissance de calcul et a la capacite de stockage

entre reseaux de machines a travers le reseau Internet [27]. Buyya, dans [10], definit une grille

comme un systeme parallele et distribue qui permet le partage, la selection et l’agregation de

ressources dynamiques geographiquement distribuees. Chacune de ces ressources a ses propres

caracteristiques, ses propres performances, ses propres politiques de gestion, d’acces, etc. Pour

le laboratoire europeen CERN (Conseil Europeen pour la Recherche Nucleaire), une grille re-

presente un service pour le partage de la puissance de calcul et les capacites de stockage d’un

ensemble de machines a travers le reseau Internet [53]. Malgre cette pluralite de definitions,

celle de Ian Foster [24] semble actuellement faire l’unanimite dans le domaine des grilles. Cette

definition presente une grille comme une infrastructure virtuelle constituee d’un ensemble de

ressources heterogenes, coordonnees et garantissant des qualites de service non-triviales (voir

Figure 1.1).

6

1.3. Architecture d’une grille

Fig. 1.1 – Exemple d’une grille informatique

Les ressources qui composent une grille ont un certain nombre de caracteristiques, que nous

pouvons resumer comme suit [27] :

1. Partagees : Elles sont mises a la disposition des differents utilisateurs de la grille et even-

tuellement pour differents usages applicatifs.

2. Distribuees : Les ressources d’une grille sont localisees dans des sites geographiques separes.

3. Heterogenes : L’heterogeneite des ressources d’une grille se retrouve a differents niveaux :

architectures, systemes d’exploitation, systemes de gestion de fichiers, systemes de gestion

de bases de donnees, reseaux, equipements specifiques, etc.

4. Gestion coordonnee : La gestion des ressources d’une grille n’est pas centralisee. Elle est au

contraire assuree par plusieurs gestionnaires de ressources qui ont des politiques de gestion

differentes. Malgre cela, ils doivent neanmoins coordonner leurs actions pour assurer une

politique globale de gestion d’une grille.

5. Externalisees : Les ressources d’une grille sont accessibles a la demande chez un fournisseur

(serveur) externe.

1.3 Architecture d’une grille

L’architecture d’une grille est souvent representee comme un empilement de plusieurs couches

(voir Figure 1.2), dont chacune assure une fonction specifique [10, 25].

– La couche Fabrique (Fabric) designe l’ensemble de l’infrastructure physique d’une grille

(ordinateurs, systemes de stockage, bases de donnees, etc.). Ces ressources (physiques et

logiques) implementent un certain nombre de mecanismes de demandes d’informations

7

1.3. Architecture d’une grille

Fig. 1.2 – Architecture en couches d’une grille

permettant de les decouvrir, de connaıtre leurs etats, leurs capacites et les mecanismes de

gestion correspondants.

– La couche Connectivite (Connectivity) implemente les principaux protocoles de commu-

nication et de securite necessaires au bon fonctionnement d’une grille.

– La couche Ressource (Resource) utilise les services des deux couches precedentes pour

collecter les informations sur les ressources, pour les surveiller, pour les controler et pour

gerer une eventuelle facturation quant a leur utilisation, au cas ou elles sont payantes.

– La couche Collectif (Collective) se charge de la coordination des ressources. Par oppo-

sition a la couche Ressource, qui traite les ressources de maniere individuelle, la couche

Collectif permet de coordonner l’ensemble de ces ressources. Les services et les protocoles

decrits dans cette couche ne sont pas associes a une ressource specifique mais a un en-

semble de ressources. C’est ainsi que cette couche est responsable de l’ordonnancement

et de la co-allocation des ressources, lorsqu’un utilisateur fait appel a plusieurs ressources

simultanement. Elle est chargee egalement de la replication des donnees.

– La couche Application represente l’ensemble des applications des utilisateurs qui seront

executees sur une grille, afin de stocker et de recuperer des donnees ou pour y effectuer

des calculs. Dans de telles situations, les differentes couches d’une grille seront alors sol-

licitees. Par exemple, les couches Collectif et Ressource seront en charge de la recherche

des ressources pouvant heberger l’execution d’une application. Une fois celles-ci trouvees,

la couche Connectivite sera utilisee pour une authentification et, enfin, la couche Fabrique

sera en charge de l’acces physique a ces ressources.

En plus de la structure definie ci-dessus, il existe d’autres approches de description d’une

grille en couches [27]. Une premiere approche met l’emphase sur les constituants d’une grille du

point de vue infrastructure (voir Figure 1.3) [24, 25], alors qu’une deuxieme mettra l’accent sur

les services offerts par chaque couche (voir Figure 1.4) [7, 27].

8

1.4. Evolution des grilles

Fig. 1.3 – Constituants des couches d’une

grille

Fig. 1.4 – Fonctionnalites des couches d’une

grille

Une grille doit integrer un intergiciel (middleware) qui regroupe l’ensemble des services

logiciels pour sa mise en œuvre [10, 27]. Comme tout middleware, son principal role est d’assurer

une interface entre les differentes couches de la grille. Un intergiciel comprend notamment les

fonctions suivantes [27, 37] :

– Le partage et l’allocation des differentes ressources d’une grille ;

– L’execution, l’ordonnancement des travaux ainsi que l’administration d’une grille ;

– L’ensemble des procedures de securisation d’une grille ;

– Les outils collaboratifs permettant aux divers acteurs de travailler ensemble ;

– Les outils d’evaluation des performances et de mesure de qualite de service ;

– Les outils de developpement et les interfaces utilisateurs pour le deploiement d’applications.

Parmi les intergiciels les plus utilises dans le domaine des grilles, nous pouvons citer Globus,

Legion et Unicore [27].

1.4 Evolution des grilles

Les reseaux de communication sont devenus un element indispensable dans le monde infor-

matique moderne [7, 42, 47]. Ils permettent le partage d’informations et la collaboration entre les

personnes et leurs applications (voir Figure 1.5). Depuis la fin des annees 90, le developpement

des reseaux a permis a la technologie des grilles informatiques d’evoluer de maniere considerable.

Ainsi, nous pouvons distinguer trois generations des grilles selon leurs apparitions chronologiques

dans le temps [7, 42, 51].

9


Fig. 1.5 – Evolution des grilles

1.4.1 Premiere generation

Le Metacomputing, qui remonte a la fin des annees 90, est l’ancetre immediat des grilles.

Ce terme, appele aussi Metacalcul, a ete defini dans le cadre du projet CASA de la NCSA [27],

pour decrire le concept de passage a l’echelle massif de l’agregation des ressources d’un grand

nombre de machines individuellement connectees a Internet. Depuis, le metacomputing a ete

utilise pour designer des projets d’interconnexion de gros centres informatiques aux Etats-Unis,

visant a federer la puissance de multiples supercalculateurs [7], pour faire face a des problemes

necessitant de grandes puissances de calcul, comme dans le cas des projets FAFNER [26] et

I-WAY [27].

1.4.2 Deuxieme generation

Les evolutions technologiques realisees dans differents domaines, tels que les reseaux, les

systemes Peer-to-Peer, le haut debit et l’adoption de normes informatiques internationales, a

permis aux grilles de calcul d’etre percues comme une infrastructure distribuee viable et sure a

l’echelle de la planete, qui peut supporter diverses applications qui exigent de fortes densites de

calcul et de donnees.

Du point de vue gestion de ressources, la deuxieme generation a apporte un outil essentiel, appele

10


courtier de ressources (resources broker) [27, 35] schematise par la Figure 1.6.

JDL/Script,

Requête d’allocation

Tâches de terminaison

Statut des ressources

Annuaire ressources :

équipements, logiciels,Courtier de ressources

Réservation & Allocation

Ordonnancement & Chargement

Script de lancement

Application

Gestionnaire local

de ressources

3

5

4

1

2

Fig. 1.6 – Courtier de ressources

Ce gestionnaire dispose de l’etat de l’ensemble des ressources offertes par une grille, ce qui lui

permet de faire des allocations a travers des scripts de lancement de travaux, voire de les reserver

prealablement, avant ordonnancement puis execution. La deuxieme generation se caracterise par

trois principaux aspects [7, 27] :

1. Heterogeneite : Une grille implique une multitude de ressources de nature heterogene en

terme de materiels et de logiciels ;

2. Passage a l’echelle : Cet aspect definit la capacite pour une grille de calcul a rester perfor-

mante malgre une montee en charge des ressources utilisees et du nombre d’utilisateurs.

Le maintien de cette performance pose bien evidemment de nouvelles problematiques d’un

point de vue gestion des ressources et des utilisateurs ;

3. Dynamicite : Les grilles de calcul sont des systemes a large echelle et dynamiques. La

nature dynamique des grilles est a la fois un atout et un defi. Un atout, car elle permet

d’ajouter des ressources au fur et a mesure de leur disponibilite et/ou des besoins ou d’en

retirer pour effectuer des operations de maintenance par exemple. Un defi, car pour le

concepteur systeme cet aspect dynamique souleve de nombreux problemes de gestion [41].

1.4.3 Troisieme generation

Les principales caracteristiques de la troisieme generation des grilles de calcul peuvent se

resumer comme suit [7] :

11

1.5. Les differents types de grilles

1. Meilleure securite d’acces aux grilles et aux ressources par l’utilisation de certificats elec-

troniques ;

2. Une gestion des fichiers adaptee a la prise en charge de donnees massives sur grille, avec

decoupage et regroupement en entites logiques pouvant etre repliquees en cas de necessite

pour des traitements paralleles ;

3. La generalisation de la notion d’organisation virtuelle [25] permettant de definir des sous-

ensembles de ressources et leurs modalites d’usage par des communautes d’utilisateurs ;

4. L’introduction de modeles economiques [9] pour l’allocation de ressources ;

5. Le passage d’un mode acces a des ressources d’une grille vers la fourniture de services de

grilles (web et grid services) ;

6. L’interoperabilite via une normalisation des services web appliques aux grilles, tel que

OGSA (Open Grid Services Architecture) et WSRF (Web Services Resource Framework)

[27] ;

7. L’utilisation de services reseaux, tels que des protocoles plus performants pour le multicast,

les transferts massifs de donnees, l’utilisation de primitives de communication issues de la

bibliotheque MPI (Message Passing Interface) [27], l’allocation de bande passante a la

demande, etc. ;

8. L’utilisation d’approches basees sur les SLA (Service Level Agreement) [7] au niveau reseau

et au niveau grille ;

9. Une meilleure prise en compte des besoins industriels : administration simplifiee, securite,

facturation des services et business models, interoperabilite des grilles, fiabilisation des

services, connexion a la demande a une grille.

1.5 Les differents types de grilles

Il n’est parfois pas evident de reperer les systemes de grilles informatiques dans notre monde.

Pourtant, il en existe un certain nombre que nous pouvons classer en trois categories [7] :

1.5.1 Les grilles d’information

C’est sans aucun doute la premiere incarnation evidente du concept de grille. Elle permet

le partage de l’information a travers un reseau. L’exemple le plus caracteristique de ce type de

grille est le Web [7], qui permet l’acces a de grandes masses de donnees disseminees a travers le

monde.

12

1.6. Principaux enjeux des grilles

1.5.2 Les grilles de stockage

Cette categorie de grille permet le partage de donnees externalisees entre plusieurs nœuds.

Les cas les plus representatifs de cette categorie sont les reseaux d’echange Peer-to-Peer [7, 36].

Les grilles appartenant a cette categorie permettent l’acces a des donnees (fichiers, flux, etc.)

via un reseau de sites (ou serveurs) qui contiennent et partagent un index. Les donnees sont

referencees pour optimiser les recherches a travers un moteur de recherche. Les fichiers peuvent

se trouver sur des nœuds differents du reseau et en differents points du globe. Comme exemple

de cette categorie de grilles, nous pouvons citer notamment le reseau GNUTELLA [27] ou encore

KaZaA [7, 27].

1.5.3 Les grilles de calcul

Cette troisieme categorie est l’incarnation des grilles dans le monde informatique, dans le

sens ou les premieres grilles mises en place avaient pour objectif de repondre a des exigences

en puissance de calcul, qui ne pouvaient pas etre satisfaites par les ressources appartenant a

des individus ou a des institutions. Les premieres utilisations des grilles de cette categorie ont

consiste a recuperer les heures d’inactivite des processeurs a travers le monde, via le reseau

Internet. Cette approche s’est ensuite generalisee pour mettre en place le principe de regrou-

pement des capacites de calcul de milliers, voire de millions d’ordinateurs, pour repondre a un

interet commun. Comme exemple pratique de ce principe, nous pouvons signaler la participation

d’IBM avec son � World Grid Computing � [27], qui est un organisme mettant a la disposition

des laboratoires de recherche une tres grande puissance de calcul de l’ordre du TeraFlops.

1.6 Principaux enjeux des grilles

Les grilles de calcul tendent a devenir une technologie de besoins de type Business-to-Business

[27] et regroupe des personnes ayant un interet commun par l’agregation et l’unification de leurs

ressources [37]. Ce regroupement impose un certain nombre d’enjeux que les grilles de calcul

doivent etre en mesure de satisfaire. Ces enjeux peuvent se resumer sous la forme de cinq criteres

a satisfaire [27, 53] :

1.6.1 Partage de ressources

Ce critere permet d’acceder a une grille pour partager l’utilisation de ressources distantes.

Cette capacite de partage implique plus qu’un simple transfert de fichiers, dans la mesure ou elle

requiert un acces direct a differents logiciels, differents ordinateurs, differentes donnees, differents

equipements, etc. Malgre leur mise en commun, les ressources d’une grille restent la propriete

des personnes ou des institutions auxquelles elles appartiennent. Ceci signifie qu’elles relevent

13

1.6. Principaux enjeux des grilles

de domaines administratifs differents, qu’elles executent des logiciels differents et qu’elles sont

regies par des politiques de securite et de controle d’acces egalement differentes.

1.6.2 Acces securise

Une consequence du partage des ressources est le controle des acces a ces ressources pour

garantir un certain nombre de regles de securite [7, 27] :

– Politique concernant l’acces : les fournisseurs et les utilisateurs des ressources doivent

definir clairement et soigneusement ce qui est partage, qui est autorise a partager des

ressources ainsi que les conditions dans lesquelles aura lieu ce partage ;

– Authentification : afin d’eviter toute utilisation abusive et non autorisee de ressources

partagees, il est indispensable de definir un mecanisme permettant d’etablir, de maniere

precise, l’identite de l’utilisateur d’une ressource ;

– Autorisation : en plus d’une authentification, il faut egalement definir un mecanisme per-

mettant de determiner si une operation est conforme aux regles de partage qui ont ete

definies.

1.6.3 Utilisation efficace de ressources

Ce troisieme critere permet d’optimiser l’utilisation des ressources de la grille, meme si leur

nombre et leurs capacites depassent les besoins des utilisateurs. A cet effet, il est indispensable

non seulement d’assurer que les ressources sont utilisees de maniere efficace (exploitation de

leurs potentialites) mais egalement que la charge de travail est bien equilibree entre les res-

sources, afin d’eviter que des ressources soient surchargees alors que d’autres sont sous-utilisees

ou completement libres.

1.6.4 Abolition de la distance

Les connexions a haut debit entre ordinateurs rendent possible la mise en place d’une grille a

l’echelle mondiale [27]. Il s’agit en fait de donner l’impression que la distance qui separe un uti-

lisateur des ressources qu’il veut utiliser est pratiquement nulle. Ceci necessite bien evidemment

d’autres avancees au niveau des reseaux de communication.

1.6.5 Mise en place de normes

Les grilles de calcul ayant tendance a se generaliser, il devient important de standardiser

une architecture pour les grilles. Cette standardisation permettra de contribuer, de maniere

significative, a la resolution des problemes d’heterogeneite qui se posent au niveau des grilles

[37, 41]. Beaucoup de travaux sont menes actuellement dans ce sens, et des normes specifiques

aux grilles sont en cours d’elaboration par un organisme de normalisation, appele GGF (Global

14

1.7. Domaines d’application des grilles

Grid Forum) [27]. Federant plus de 5000 chercheurs et praticiens individuels, cet organisme

represente une force significative en matiere d’edition de normes et d’elaboration d’elements

permettant le travail en commun. Actuellement, une norme, connue sous le nom OGSA (Open

Grid Services Architecture) [27], a ete mise en place et elle est consideree comme une reference

cle pour les projets d’elaboration de grilles.

1.7 Domaines d’application des grilles

De part les potentialites qu’elle offre, une grille est un excellent moyen de partager des donnees

et de la puissance de calcul. Ce principe de mise en commun des ressources est utilise dans une

multitude de projets industriels et scientifiques [7]. Les domaines d’utilisation des grilles etant

tres diversifies, nous pouvons quand meme les regrouper en cinq grandes classes d’applications

dans lesquelles les grilles peuvent etre d’un apport tres substantiel.

1.7.1 Calcul distribue

Les applications de calcul distribue sont evidemment d’excellentes candidates pour etre ex-

ploitees sur une grille. Elles beneficient ainsi d’un nombre beaucoup plus important de ressources

de calcul leur permettant de resoudre des problemes qui leur etaient auparavant inaccessibles

[7, 26]. Pour certains types d’applications relevant de domaines tel que la physique nucleaire,

la recherche de sequence d’ADN, il est evidemment illusoire d’esperer disposer de la puissance

de calcul sur un seul et meme site. L’utilisation d’une grille se revele des lors indispensable

[27]. Parmi les principaux defis que doit relever une architecture de type grille pour de telles

applications, nous pouvons citer [37] :

– L’ordonnancement a grande echelle de travaux, de jobs et de processus ;

– La souplesse des algorithmes et protocoles qui doivent etre capables de gerer un nombre

de nœuds pouvant aller de la dizaine a des centaines voire des dizaines de milliers de

machines ;

– La tolerance des algorithmes aux temps de latence inherents a la taille d’une grille ;

– La possibilite d’atteindre et de maintenir un haut niveau de performance dans une infra-

structure tres heterogene.

1.7.2 Calcul a haut debit

Contrairement aux calculs distribues, les applications de calcul a haut debit necessitent la

resolution d’un tres grand nombre de calculs de maniere independante et parfois coordonnee.

Les ordinateurs, lorsqu’ils sont inutilises, peuvent ainsi contribuer a agreger une puissance de

calcul pour resoudre des applications tres exigeantes en matiere de puissance de calcul. Le

15

1.8. Conclusion

projet SETI@home [27] est un exemple d’infrastructure qui a permis d’agreger une puissance de

calcul tres importante uniquement a partir des periodes d’inactivite des processeurs de simples

ordinateurs de type PC.

1.7.3 Calcul a la demande

Ce type d’applications necessite de la puissance de calcul pour des besoins ponctuels. Plutot

que d’acheter des ressources qui ne seront utilisees qu’occasionnellement ou pour un objectif bien

precis, il serait plus judicieux de pouvoir utiliser, en cas de besoin, les ressources d’autres utili-

sateurs notamment pendant la periode de leur inactivite [24]. Pour rendre cette nouvelle forme

d’utilisation des ressources possible, il est primordial de developper des systemes performants et

securises d’utilisation des ressources, meme dans le cas ou elles sont payantes [27].

1.7.4 Traitement massif de donnees

Dans ce type d’applications, le but est d’extraire de nouvelles informations a partir de grandes

bases de donnees geographiquement distribuees (fouilles de donnees, bio-informatique, meteo-

rologie, etc.). Generalement, ces types de traitement sont egalement de grands consommateurs

de puissance de calcul et de bande passante [27]. Les principaux problemes a resoudre, pour ce

type d’application, sont l’acheminement et la configuration de flux de donnees tres importants

a travers les elements d’une grille.

1.7.5 Travail collaboratif

Les grilles de calcul permettent non seulement de regrouper (virtuellement) des ressources

informatiques heterogenes, mais aussi de federer des milliers de personnes reparties sur des en-

treprises et institutions differentes, dans le but d’un travail collaboratif [8]. Dans ce contexte, les

grilles, de part leurs caracteristiques, constituent une veritable plate-forme de travail collaboratif

a moindre cout.

1.8 Conclusion

L’un des objectifs essentiels des grilles de calcul est de donner l’impression, a un utilisateur,

d’utiliser un super-calculateur virtuel qui permet de connecter une tres large collection de sys-

temes heterogenes a travers le reseau Internet. Ainsi, une grille englobe un certain nombre de

ressources et de services qui sont necessaires a des applications qui exigent une forte puissance de

calcul, ou a celles qui exigent une masse tres importante de donnees distribuees. Ces ressources

et ces services sont utilises a travers un middleware qui assure une transparence totale de la

16

1.8. Conclusion

grille vis-a-vis de ses utilisateurs.

Dans les grilles de calcul, le partage de donnees est complexe. Cela est principalement du

a [18, 41] : (i) la grande echelle ; et, (ii) la nature dynamique des grilles de calcul. Ces deux

caracteristiques rendent impossible une connaissance globale de l’etat d’une grille, car le nombre

de nœuds peut etre tres important, et de plus, les nœuds sont susceptibles de quitter ou de

rejoindre la grille a tout instant. Ceci rend difficile la localisation des nœuds hebergeant une

copie d’une donnee partagee. En plus du probleme de localisation de donnees, pour lequel de

nombreux travaux existent [18, 34, 41], se pose celui du transfert de donnees : quelle copie trans-

ferer s’il en existe plusieurs, quel protocole utiliser, quel chemin reseau emprunter, etc.

Dans ce chapitre, nous avons mis en evidence les principales caracteristiques des grilles selon

leurs types, leurs domaines d’utilisation ainsi que les differentes problematiques qu’elles posent

pour leur mise en oeuvre. Comme ces infrastructures sont sujettes a des pannes, il est necessaire

d’assurer leur disponibilite afin de donner l’illusion a un utilisateur qu’une grille est toujours en

mesure d’assurer, de maniere continue, les services pour lesquels elle a ete definie. Pour assurer

une telle disponibilite, les grilles utilisent la technique de replication que nous discuterons dans

le chapitre suivant.

17

Chapitre 2

Protocoles de replication et de

coherence

18

2.1. Introduction

2.1 Introduction

Le partage de donnees a grande echelle n’est ni un probleme recent, ni un probleme spe-

cifique aux grilles, puisque nous le retrouvons dans les systemes sequentiels et les systemes

distribues [37]. Un systeme distribue, qu’il soit deploye sur un reseau dedie, sur un reseau d’en-

treprise, ou sur un reseau a grande echelle, est amene a patager des ressources entre ses differents

utilisateurs. Les techniques de partage qu’il utilise sont souvent basees sur la replication d’infor-

mations et/ou de services [16, 41]. En plus, pour garantir la continuite de service des applications

en cas de panne, il est indispensable de recourir aux techniques de replication [15, 22, 41]. La

replication est une strategie dans laquelle plusieurs copies de donnees, de programmes, de proces-

sus, de materiels physiques, etc., sont stockees sur divers nœuds [31]. Elle permet principalement

d’augmenter la disponibilite, d’offrir une meilleure performance et d’ameliorer la fiabilite [28].

Malheureusement, ces objectifs sont antagonistes (voir Figure 2.1). Pour garantir une fiabilite

d’un ensemble de repliques, il est necessaire d’avoir une coherence forte, ce qui peut deteriorer

les performances. A l’inverse, pour obtenir de bonnes performances, il est necessaire de relacher

la coherence, ce qui penalise la fiabilite.

Fig. 2.1 – Compromis performance/fiabilite

2.2 Principe de replication

La replication de donnees consiste a stocker des donnees sur plusieurs nœuds geographique-

ment distribues (voir Figure 2.2). L’interet premier de cette replication est que, si une donnee

n’est plus disponible, le systeme peut continuer a assurer ses fonctionnalites en utilisant une don-

nee repliquee, ce qui permet d’augmenter la disponibilite des donnees et la tolerance aux pannes

[22, 41]. D’un autre cote, puisque la donnee est repliquee sur plusieurs nœuds, deux contraintes

doivent etre satisfaites vis-a-vis de l’utilisateur : (i) une requete de lecture doit etre en mesure

de retourner une valeur qui soit correcte (valeur de la derniere ecriture) ; (ii) reduire le temps de

reponse d’une requete en accedant au nœud qui soit le plus proche possible de l’utilisateur, afin

d’augmenter les performances du systeme [31].

19

2.3. Les techniques de replication

Fig. 2.2 – Environnement d’utilisation de la technique de replication

2.3 Les techniques de replication

La replication met en oeuvre un processus qui est charge de la creation, du placement et de

la gestion de copies d’entites physiques et/ou logicielles. Les entites repliquees peuvent etre des

donnees, du code, des objets, des composants physiques ou une combinaison de tous ces elements

[22, 41, 48, 53].

La creation des copies ou repliques d’une entite consiste a reproduire la structure et l’etat des

entites repliquees. La copie d’un fichier est un autre fichier de meme contenu. La copie d’un

programme est un autre programme qui execute le meme code et dont l’etat d’execution est

celui du programme initial.

Le placement des copies ou des repliques consiste a choisir, en fonction des objectifs de replica-

tion, un environnement de stockage et/ou d’execution pour les copies. Par exemple, le placement

dans un environnement accessible localement assure le travail en mode deconnecte alors que le

placement de repliques sur plusieurs machines permet une distribution de charge [2, 29, 48, 59].

2.3.1 Avantages de la replication

L’utilisation de la technique de replication procure un certain nombre d’avantages que nous

pouvons resumer comme suit [22, 31, 33] :

1. Augmenter la disponibilite des donnees : L’un des principaux avantages de la replication est

que les donnees peuvent etre disponibles localement et non plus par le biais de connexions

potentiellement onereuses, souvent pas fiables et lentes. Si une copie tombe en panne, il est

toujours possible d’obtenir les donnees a partir d’autres copies, ce qui confere au systeme

une plus grande robustesse ;

2. Amelioration des performances : La replication permet d’ameliorer les temps de reponse des

20

2.4. Caracteristiques d’un protocole de replication

requetes d’acces aux donnees pour deux raisons essentielles : (i) les requetes sont traitees

sur un serveur local sans acces a un reseau etendu qui necessite de la communication ; (ii)

le traitement local allege la charge globale des serveurs.

2.3.2 Inconvenients de la replication

Malgre tous les avantages qu’elle procure, la technique de replication souleve un certain

nombre de problemes que nous allons aborder succinctement dans ce qui suit [33] :

– Placement des repliques : Ce probleme consiste a choisir, en fonction des objectifs des

applications et de la replication, des localisations physiques pour les repliques, qui reduisent

les couts de stockage et d’acces aux donnees [38, 48, 49, 58]. Pour trouver ces localisations,

un modele de cout est necessaire [40, 52] pour calculer le cout des differents placements ;

– Choix d’une replique : Il s’agit ici de selectionner, parmi toutes les repliques d’une donnee,

celle qui est la meilleure du point de vue de la consistance [48, 54] ;

– Degre de replication : Ce probleme concerne la recherche du nombre minimal de repliques

qu’il faut creer pour une donnee, sans reduire les performances des applications. Ce degre

peut etre determine d’une maniere predictive ou adaptative [15] ;

– Coherence des repliques : Parmi les problemes lies a la replication, le probleme de la cohe-

rence est sans doute celui qui est le plus complexe [33, 50]. Intrinsequement, les techniques

de replication n’assurent pas, systematiquement, une coherence des donnees de l’ensemble

des repliques. Ainsi, il est possible d’avoir, a un instant donne, des copies differentes d’un

meme ensemble de donnees sur differents nœuds [21, 50, 61]. Pour eviter de telles situa-

tions, il est donc necessaire de definir un protocole de coherence (ou par abus de langage un

protocole de replication) qui puisse garantir que toutes les repliques d’une meme donnee

sont coherentes [22, 36].

2.4 Caracteristiques d’un protocole de replication

Dans un systeme distribue, des lors qu’un objet O est replique, il est necessaire de definir

l’algorithme utilise pour gerer les differentes copies ou repliques de cet objet. Dans la litterature,

cet algorithme est designe par protocole de replication (ou politique de replication). Un protocole

de replication doit permettre de decrire les elements suivants [19] :

– Les interactions internes a O, c’est-a-dire les interactions entre les differentes copies de O ;

– Les interactions externes a O, c’est-a-dire les interactions entre les copies de O et les autres

composants du systeme.

Pour le bon fonctionnement d’un protocole de replication, quatre questions fondamentales se

posent et auxquelles doit repondre un protocole de replication [18, 48] :

21


1. Strategie du Quoi : Quelles sont les entites a repliquer ? Quel est leur type ?

2. Strategie du Comment : Comment une copie est-elle creee ? Quelles sont les informations

repliquees ? Le processus de creation de copie depend de la structure et de l’etat de l’entite

a repliquer. La structure de l’entite peut etre indivisible ou composee, alors que l’etat peut

etre constitue de donnees, de code et eventuellement d’un etat d’execution ;

3. Strategie du Quand : Quand une copie est-elle creee ? Est-elle creee statiquement avant

l’execution, ou dynamiquement en cours d’execution ? Dans le cas d’une replication sta-

tique, la replique est creee suite a la demande d’un client, alors que dans le cas de la

replication dynamique, les requetes sont creees independamment des requetes des clients

[11, 40, 48] ;

4. Strategie du Ou : Ou une copie s’execute-t-elle ? Comment le placement repond- il aux

objectifs de mise a l’echelle, de performances et de tolerance aux pannes ?

Les principales caracteristiques d’un protocole de replication se definissent comme suit : (i) le

nombre de copies concernees par une lecture ou une ecriture ; (ii) les droits d’acces ; (iii) l’instant

de synchronisation des repliques ; (iv) l’initiative de la mise a jour des repliques ; (v) la nature

des mises a jour ; (vi) le cheminement (ou la topographie) des mises a jour ; (vii) la capture des

mises a jour ; (viii) la gestion des conflits ; (ix) le type de protocole de communication ; (x) la

gestion de la concurrence ; (xi) la gestion de la tolerance aux fautes ; et, (xii) la transparence de

la replication [22].

2.4.1 Nombre de copies concernees par une requete

Certains protocoles ecrivent sur toutes les copies avant de repondre a une requete d’ecriture,

et ils n’ont besoin de consulter qu’une seule copie pour repondre a une requete de lecture [22].

D’autres protocoles, qui utilisent le principe du numero de version, ne repondent a une requete

d’ecriture que lorsque plus que 50% des copies sont mises a jour. Par contre, pour repondre a une

requete de lecture, il est suffisant de consulter que 50% des copies. Ce type de protocoles assure

une coherence mutuelle forte des copies [50]. En relachant cette coherence, lors d’une requete de

lecture ou d’ecriture, certains protocoles lisent et ecrivent sur une seule copie. La mise a jour

des differentes copies est alors effectuee de maniere asynchrone par rapport a la requete [44, 56].

2.4.2 Droits d’acces aux copies

Parmi les copies d’un objet, il peut en exister un certain nombre qui peuvent etre modi-

fiees par des requetes, et d’autres qui peuvent etre modifiees uniquement par le protocole de

replication. La determination de ces copies definit deux approches extremes [32, 50] : l’approche

maıtre-esclaves (master-slave) ou primaire-secondaire, et l’approche copies identiques (update

anywhere ou peer-to-peer) [29, 32, 50].

22


1. Approche maıtre-esclaves : Chaque objet replique possede une copie dite maıtresse, les

autres etant des copies esclaves. Le plus souvent, cette approche est appelee la strategie

de replication maıtre unique ou uni-maıtre. Une requete de mise a jour ne peut etre faite

que sur la copie maıtre. Cette mise a jour est ensuite diffusee aux copies esclaves. Dans la

Figure 2.3(a), la copie maıtresse (primaire) recoit les requetes d’ecriture, puis les diffuse aux

copies esclaves (secondaires) [6, 32, 50]. Les copies esclaves ne repondent qu’aux requetes

de lecture. Cette approche facilite le maintien de la coherence mais elle produit un goulet

d’etranglement sur la copie maıtresse. Des variantes de cette approche proposent qu’il y

ait plusieurs copies maıtres en meme temps pour eliminer ces goulets d’etranglement. Elles

permettent ainsi d’ameliorer les performances et la tolerance aux fautes [41].

2. Approche copies identiques : Dans cette approche, appelee aussi multi-maıtres, le compor-

tement de toutes les copies est identique ; elles ont en fait le meme comportement qu’une

copie maıtre. Toutes les copies peuvent repondre aux requetes de lecture et d’ecriture.

Chaque copie, qui traite une requete d’ecriture, diffuse les mises a jour aux autres copies.

Dans la Figure 2.3(b) les copies C1, C2, C3 et C4 traitent les requetes d’ecriture et diffusent

ensuite aux autres copies les mises a jour qu’elles ont effectue. En utilisant cette strategie,

la disponibilite est amelioree, alors que la complexite est augmentee a cause de l’existence

de conflits [50].

Fig. 2.3 – Approches maıtre-esclaves et copies identiques

2.4.3 Instant de synchronisation des repliques

Les mises a jour des differentes copies peuvent se faire simultanement sur toutes les copies

ou d’abord sur une copie et ensuite sur les autres. Dans [22, 56], les auteurs proposent, sous

le terme de conditions de coherence, une classification de sept instants de declenchement d’une

operation de synchronisation des repliques d’une donnee :

1. Conditions sur le delai : Ces conditions portent sur le temps. Elles expriment la duree

maximale que le protocole peut attendre avant la propagation d’une mise a jour. Par

23


exemple, un delai maximum de 60 secondes signifie que toutes les mises a jour d’une copie

doivent etre propagees vers une autre copie avant l’expiration de ce delai ;

2. Conditions sur la periodicite : Elles expriment qu’une copie d’un objet doit etre mise a

jour avec la derniere valeur de l’objet toutes les n unites de temps (periode), que l’objet

ait ete modifie ou non ;

3. Conditions sur le moment : Ces contraintes expriment le fait qu’une copie d’un objet doit

etre mise a jour avec la derniere valeur de l’objet a un instant donne ;

4. Conditions sur la version : Elles specifient le nombre de modifications pouvant avoir lieu

sur une copie avant de propager les mises a jour sur une autre copie ;

5. Conditions numeriques : Si la donnee est numerique, ces conditions permettent de limiter

l’ecart (δ ), entre les valeurs des differentes copies d’un objet.

6. Conditions sur les objets : Ces conditions portent sur la structure des objets. Il est possible

de specifier qu’une copie x′ d’un objet O doit etre mise a jour avec la derniere valeur de O

lorsque :

– Au moins m sous-objets de la copie x′ ont ete modifies ;

– Au moins m% des sous-objets de x′ ont ete modifies ;

– Un sous-objet o de x′ a ete modifie.

Les conditions sur les objets sont particulierement adaptees aux systemes a objets [2] et

peuvent aussi etre adaptees a d’autres modeles, comme par exemple les bases de donnees

relationnelles [22] ;

7. Conditions d’evenements : Ces conditions portent sur les evenements de declenchement

des mises a jour des copies.

2.4.4 Initiative de l’operation de mise a jour

Les copies possedant l’information permettant de faire une mise a jour sont appelees copies

sources, alors que les copies sur lesquelles doivent etre propagees les modifications sont appelees

copies cibles [12]. Deux approches pour le rafraıchissement des copies sont possibles [12, 14] :

1. Rafraıchissement de type � Push � : Dans cette approche, la propagation des mises a jour

est a l’initiative de la copie source. Des problemes de passage a l’echelle peuvent se poser

dans certains cas ou des messages inutiles de synchronisation peuvent etre envoyes a des

copies qui ne seront pas consultees.

2. Rafraıchissement de type � Pull � : Ici, la propagation des mises a jour est a l’initiative

de la copie cible. Cette approche permet de reduire la charge du reseau en ne propageant

que les dernieres modifications. En revanche, les copies cibles ne peuvent pas savoir si une

mise a jour est necessaire ou non.

24


2.4.5 Nature des mises a jour

La nature des mises a jour designe le type d’informations a propager aux differentes copies

lors de la synchronisation. Cette propagation peut etre effectuee de deux manieres [14, 22] :

1. Protocole a diffusion des ecritures : Un protocole a diffusion des ecritures envoie les modi-

fications faites sur une copie aux autres copies. Deux cas sont envisageables dans le cadre

de ce protocole :

– Transfert de l’etat de la source vers les autres copies ;

– L’operation executee sur la source est propagee vers les nœuds cibles pour y etre executee.

2. Protocole a invalidation : Lorsqu’une copie est modifiee, un protocole a invalidation censure

les acces aux autres copies en leur envoyant une notification les informant qu’elles sont

invalides. Les copies invalidees doivent etre re-synchronisees avant de pouvoir de nouveau

etre utilisees. Cette methode permet de limiter la taille des messages echanges entre les

differentes copies, mais limite les acces paralleles.

2.4.6 Cheminement des mises a jour

La propagation des mises a jour peut suivre plusieurs chemins. Le choix du chemin se justifie

soit par le fait que certaines copies doivent etre mises a jour avant d’autres, soit par la topologie

du reseau qu’elles utilisent. La propagation des mises a jour peut utiliser des protocoles de

communication des reseaux tels que Unicast, Multicast ou Broadcast [1, 15].

2.4.7 Capture des mises a jour

Le mecanisme utilise pour detecter et selectionner les changements sur une copie afin de les

propager aux autres copies est appele capture des mises a jour [12, 14, 22]. Ce mecanisme peut

etre implante de diverses facons, comme par exemple [14, 50] :

– A base de l’etat de la copie : Consulter la copie pour connaıtre son dernier etat ;

– A base d’un journal (log sniffing) : Enregistrer les modifications sur un journal ;

– A base de trigger ou de thread : Declenchement d’un trigger ou d’un thread suite a une

modification.

2.4.8 Gestion de la concurrence et transparence a la replication

Les objets partages sont, par definition, accessibles par plusieurs utilisateurs ou applications.

Il en est de meme pour les objets repliques et ces derniers peuvent etre accedes par [13, 50] :

– Plusieurs lecteurs ou un ecrivain (ecriture) a un moment donne ;

– Plusieurs lecteurs ou plusieurs ecrivains en meme temps sur des copies differentes ;

– Plusieurs lecteurs ou un ecrivain en meme temps sur une copie differente ;

25

2.5. Protocoles de replication

– Plusieurs lecteurs ou plusieurs ecrivains en meme temps sur des copies differentes ;

Le protocole de replication peut, selon les implementations, offrir plus ou moins de trans-

parence a l’application. Il y a transparence a la replication si l’application n’a pas conscience

du fait que les objets sont repliques [21, 39, 53]. L’objectif principal est de rendre la replication

totalement transparente aux utilisateurs et a leurs applications. Plus cette transparence est forte

plus le couplage entre les applications et le protocole de replication sera faible.

2.4.9 Gestion des conflits et des fautes

Dans certains protocoles, deux copies peuvent etre modifiees de maniere concurrente. Dans

ce cas, lorsque le protocole desire synchroniser les copies (pas forcement immediatement), il se

trouve face a un conflit qu’il faudra resoudre. Dans le processus de gestion des conflits, deux

actions sont necessaires [50, 56] :

1. Detection d’un conflit : Lors du fonctionnement normal du protocole de replication, la de-

tection des conflits consiste a detecter, a posteriori, des acces conflictuels sur les differentes

copies [45, 50] ;

2. Resolution d’un conflit : Suite a la detection d’un conflit, l’operation de resolution consiste

a l’eliminer en respectant la semantique definie par le protocole de replication [50].

Certains protocoles de replication peuvent supporter les fautes qui peuvent survenir sur les

copies (fautes par arret, par valeur, byzantines, etc.) [41]. Selon les fautes qui seront prises en

compte, des techniques appropriees de tolerance aux fautes seront alors mises en place [16].

2.5 Protocoles de replication

Plusieurs protocoles de replication ont ete proposes pour la gestion des repliques dans les

systemes distribues [16, 19, 20, 23]. Les trois principaux protocoles utilises sont : le protocole de

replication passive, le protocole de replication active et le protocole de replication semi-active.

2.5.1 Protocole de replication passive

Dans un protocole de replication passive, seule une copie recoit une requete d’un client et

l’execute. Cette copie est designee sous le nom de copie primaire (primary copy). Les autres co-

pies sont appelees copies secondaires (secondary copies). La copie primaire est la seule a effectuer

tous les traitements, alors que les copies secondaires ne font aucune action (voir Figure 2.4). En

cas de defaillance de la copie primaire, une copie secondaire devient (par un protocole d’election)

la nouvelle copie primaire. Pour assurer la coherence, la copie primaire diffuse regulierement son

nouvel etat a toutes les copies secondaires [16, 41].

26


Fig. 2.4 – Exemple de protocole de replication passive

Tolerance aux fautes : La tolerance aux fautes est realisee par detection et compensation

d’erreur [16, 41]. Quand une copie secondaire passe dans un etat de defaillance, aucun traitement

particulier n’est necessaire. Le seul effet de cette defaillance est la diminution du degre de

replication (une replique en moins). Par contre, quand une copie primaire devient defaillante,

un protocole d’election sera declenche pour designer la nouvelle copie primaire parmi les copies

secondaires. Si la copie primaire fait defaut lors d’une invocation par un client, alors celui-ci

n’obtient aucune reponse a sa requete. Il doit re-emettre sa requete en l’adressant a la nouvelle

copie primaire.

Cout du protocole passif : Dans le mode de communication synchrone, le canal de com-

munication entre le client et la copie primaire doit etre fiable et les messages doivent etre livres

atomiquement [16]. Par contre, dans un environnement asynchrone, les messages doivent au

moins respecter l’ordre causal [16]. En ce qui concerne le cout processeur, celui-ci est relative-

ment faible, puisque en l’absence de fautes, seule une copie execute la requete d’un client. Dans

un protocole passif, la sauvegarde de l’etat est un mecanisme couteux, ce qui peut degrader le

temps de reponse. De plus, la replication passive n’ameliore pas les performances par le fait que

la copie primaire peut, dans certains cas, etre surchargee.

2.5.2 Protocole de replication active

Dans un protocole de replication active, chaque copie joue un role identique a celui des

autres copies. Toutes les copies recoivent la meme sequence, totalement ordonnee, des requetes

des clients, les executent puis renvoient la meme sequence, totalement ordonnee, des reponses

(voir Figure 2.5).

27


Réponse

Requête

Requête

Serveu rs

Requête

C

S3

S2

S1

Traitemen t

Fig. 2.5 – Exemple de protocole de replication active

Tolerance aux fautes : Dans le protocole de replication active, quand une copie devient

defaillante, aucun mecanisme supplementaire n’est a mettre en œuvre [23]. La defaillance d’une

copie est masquee par le comportement des copies non defaillantes [22, 23]. Ainsi, la tolerance

aux fautes est realisee par le mecanisme de masquage d’erreur [41]. L’execution des requetes doit

etre deterministe, sinon des mecanismes de vote sont necessaires, apres la collecte des reponses

de toutes les differentes copies, pour decider de la reponse a restituer au client [31].

Cout du protocole actif : L’execution d’une requete se faisant sur toutes les copies, le cout

processeur global est donc proportionnel au nombre de copies. Le protocole actif est utilise pour

ameliorer les performances, puisqu’un client peut obtenir une reponse a partir du processeur qui

aura termine en premier l’execution de sa requete.

2.5.3 Protocole de replication semi-active

Le protocole de replication semi-active est une hybridation des replications active et passive

[19, 20, 23, 57]. Il s’apparente a la replication active dans le sens ou chaque copie execute la

requete, sauf que toutes les sources d’indeterminisme sont resolues par le choix d’une copie

maıtre qui renvoie le resultat au client (voir Figure 2.6). En l’absence de fautes, les autres copies

(les suiveuses) mettent a jour leurs etats internes en executant les requetes provenant du client

[19, 20].

28

2.6. Protocoles de coherence

Requête

Requête

RequêteRéponse

Serveurs

Client

S3

S2

S1

Traitemen t

(Maître)

Fig. 2.6 – Exemple de protocole de replication semi-active

Tolerance aux fautes : Dans la replication semi-active, quand une replique suiveuse fait

defaut aucun traitement particulier n’est necessaire [19, 20, 23]. Son seul effet est de diminuer

le degre de replication. Puisque toutes les copies recoivent la requete, le client n’a pas besoin de

re-emettre sa requete lorsque la copie maıtre devient defaillante. La nouvelle copie maıtre envoie

automatiquement la reponse au client.

Cout du protocole semi-actif : Le protocole semi-actif est deterministe par rapport au

protocole actif. L’execution d’une requete se faisant sur toutes les copies, le cout processeur

global est donc proportionnel au nombre de copies.

2.6 Protocoles de coherence

Les avantages de l’utilisation de la technique de replication sont contraints par un probleme

majeur de coherence mutuelle des copies [33]. La gestion des copies en terme de propagation

des mises a jour est ainsi necessaire. La charge induite par cette coherence peut avoir un impact

significatif sur le systeme notamment du point de vue performance [4]. Il s’agira donc de garantir

la coherence mutuelle d’un ensemble de repliques dans des delais acceptables [50].

Les diverses repliques d’un meme objet doivent etre coherentes, c’est-a-dire, apparaıtre comme

une copie unique vis-a-vis des utilisateurs (voir Figure 2.7).

La coherence est une relation qui definit le degre de similitude entre les copies d’une entite

repliquee [4]. Dans le cas ideal, cette relation caracterise des copies qui ont des comportements

identiques. Dans les cas reels, ou les copies evoluent de maniere differente, la coherence defi-

nit les limites de divergence autorisees entre copies. La relation de coherence est assuree par

synchronisation entre copies [14, 21]. Le terme protocole de coherence designe l’ensemble des

operations necessaires pour maintenir la coherence entre copies [4]. Dans un tel protocole, le

29


Fig. 2.7 – Acces aux donnees repliquees

modele de coherence decrit la maniere dont la coherence des differentes copies d’une donnee est

geree. C’est en effet ce modele qui va determiner comment les mises a jour d’une donnee par

un processus seront visibles par les autres processus [56]. Les modeles de coherence sont mis en

œuvre par des protocoles de coherence pour lesquels deux orientations sont possibles [6, 50] : les

protocoles de coherence forte appeles aussi protocoles pessimistes et les protocoles de coherence

faible ou encore protocoles optimistes.

1. Coherence forte : Une coherence de repliques est dite forte lorsque toute interrogation

d’une copie quelconque reflete le resultat de toutes les modifications anterieures [50] ;

2. Coherence faible : Une coherence de repliques est dite faible, si on tolere qu’une interroga-

tion ne reflete pas toutes les modifications anterieures, avec la garantie que celles-ci seront

toutes repercutees au bout d’un temps fini [5, 36, 50].

2.6.1 Protocoles pessimistes

L’approche qui utilise des protocoles pessimistes interdit tout acces a une replique a moins

qu’elle soit a jour, ce qui donne l’illusion aux utilisateurs qu’ils disposent d’une seule copie

consistante [13]. L’avantage principal de cette approche est que toutes les repliques convergent

en meme temps, ce qui permet de garantir une coherence forte, evitant ainsi tout probleme

de divergence [13, 21, 50]. Ce type d’approche est bien adapte pour des systemes de petite et

moyenne echelle. Par contre, elle sera tres difficile a mettre en œuvre pour des systemes a large

echelle. Ainsi, nous pouvons relever quelques inconvenients majeurs de ce type d’approche [50] :

– Elle est tres mal adaptee a des environnements instables, tels que les systemes mobiles ou

les grilles a fort taux de changement ;

– Les protocoles pessimistes font face a un dilemme concernant la disponibilite et la per-

formance [4, 6]. En effet, si le nombre de repliques augmente le temps de lecture diminue

mais le temps d’ecriture augmente. Ainsi, ces approches ont la difficulte de supporter les

30


services qui deploient beaucoup de repliques dont les mises a jour sont frequentes. Mal-

heureusement, le protocole Internet et beaucoup de services mobiles [15, 17, 31] tombent

dans cette categorie.

Plusieurs protocoles pessimistes ont ete definis dans la litterature, parmi lesquels nous pou-

vons citer les protocoles RAWA, ROWA, ROWAA et Quorum [12, 31, 36, 45].

2.6.2 Protocoles optimistes

A la difference de l’approche pessimiste, les protocoles de l’approche optimiste autorisent l’ac-

ces a n’importe quelle replique et ce a tout instant [4, 50]. Dans ce cas, les copies peuvent diverger

et un utilisateur peut donc observer des copies d’un meme objet avec des valeurs differentes [13].

De cette maniere, il est alors possible d’acceder a une replique qui n’est pas necessairement co-

herente, ce qui fait que cette approche tolere une certaine divergence entre repliques [5, 13, 21].

Par contre, quand le systeme est en phase de repos pour une donnee, c’est-a-dire quand toutes

les operations auront ete propagees a toutes les copies, alors toutes les copies devront etre iden-

tiques [36, 50]. En presence de divergence, ce type d’approche necessite une phase de detection

de divergence entre repliques puis une phase de correction de cette divergence, pour ramener les

repliques vers un etat coherent. Bien qu’elle ne garantisse pas une coherence forte comme dans

le cas pessimiste, l’approche optimiste possede neanmoins un certain nombre d’avantages que

nous pouvons resumer comme suit [44, 50] :

– Disponibilite : Les protocoles optimistes fonctionnent bien dans les reseaux lents et incer-

tains, parce qu’ils peuvent propager des mises a jour sans bloquer les acces a toutes les

repliques ;

– Flexibilite de gestion du reseau : Les protocoles optimistes fonctionnent egalement bien

dans les reseaux dynamiques [17, 50]. Une telle propriete est essentielle dans les environne-

ments mobiles, dans lesquels les dispositifs peuvent etre synchronises seulement de temps

en temps [6] ;

– Scalabilite : Les protocoles optimistes peuvent soutenir un plus grand nombre de repliques,

parce que la propagation des mises a jour exige moins de coordination entre les copies

[14, 50].

La replication optimiste est utilisee dans plusieurs domaines d’application, y compris la

gestion de donnees a large echelle, les systemes d’informations et les environnements collaboratifs

[36, 44, 50].

2.6.3 Etude comparative

L’etude de ces deux approches (pessimiste et optimiste) nous a permis de les comparer sur

un certain nombre de criteres que nous avons resume dans le tableau suivant [4, 6] :

31

2.7. Conclusion

Approche Approche

Caracteristiques Pessimiste Optimiste

Synchronisation Immediate Retardee

Coherence Forte Faible

Performance Mauvaise Bonne

Qualite de service Bonne Mediocre

Conflit et resolution - Oui

Taille des applications Petite ou moyenne Grande echelle

Disponibilite Faible Forte

Tab. 2.1 – Comparaison des approches pessimiste et optimiste

L’approche pessimiste donne l’illusion a l’utilisateur qu’il n’existe qu’une seule copie d’une don-

nee. Les protocoles les plus connus de cette approche sont bases sur le principe ROWA [31, 32].

Les lectures peuvent etre faites sur n’importe quelle copie tandis qu’une ecriture doit etre ap-

pliquee de maniere atomique sur toutes les copies (a un instant donne un seul utilisateur peut

ecrire sur une copie). Etant donne que toutes les copies sont identiques a tout instant, l’approche

pessimiste fournit une tres bonne qualite de service. Neanmoins, elle engendre une mauvaise per-

formance du systeme suite a la non disponibilite des copies. C’est pour ces raisons qu’elle n’est

pas adaptee aux systemes a large echelle.

L’approche optimiste [4, 6, 50] est une approche qui est a priori plus adaptee aux systemes

a large echelle. Dans ce cas, les copies peuvent diverger et un utilisateur peut donc observer

des copies d’un meme objet avec des valeurs differentes. Comparee a l’approche pessimiste,

l’approche optimiste ne necessite pas une mise a jour systematique de toutes les copies, ce qui

la rend potentiellement plus performante.

2.7 Conclusion

Que les donnees soient repliquees ou non, garantir leur coherence est un probleme fondamen-

tal dans la gestion des donnees et ce quelque soit leur nature (donnees, code, services, etc.). A

chaque fois que des acces concurrents sont autorises sur des donnees partagees, il y a un risque

d’incoherence qu’il faudra soit eviter totalement soit controler. Lorsque ce partage de donnees

est accompagne de techniques de replication, le probleme de gestion des repliques et des acces

concurrents devient donc plus complexe. Ainsi, la mise en place d’une technique de replication

doit etre evaluee en amont afin de mesurer son cout de mise en œuvre et son efficacite du point

de vue des objectifs vises par sa mise en place. Dans ce processus de mise en place d’une tech-

32

2.7. Conclusion

nique de replication, le probleme de la gestion de la coherence est un probleme fondamental qui

necessite une etude assez fine afin de trouver le meilleur protocole de gestion de la coherence en

fonction des objets a repliquer et des benefices qu’on veut en tirer. A travers ce chapitre, nous

avons vu qu’il existe deux classes de protocoles de gestion de la coherence : la classe des proto-

coles optimistes et la classe des protocoles pessimistes. Apres une etude de ces deux classes, nous

avons mis en evidence leurs avantages et leurs inconvenients qui pourraient servir de criteres de

choix de l’une ou de l’autre classe dans le cadre des systemes a large echelle.

Dans le chapitre suivant, nous allons proposer un modele hierarchique de coherence a deux

niveaux. Plusieurs caracteristiques sont associees a ce modele, ce qui le rend tres interessant

pour supporter une politique de gestion de coherence des repliques dans les systemes a large

echelle.

33

Chapitre 3

Modele hybride pour la gestion de

coherence

34

3.1. Introduction

3.1 Introduction

Dans un systeme a large echelle, l’utilisation des techniques de replication permet d’ame-

liorer le degre de disponibilite des donnees ainsi que les performances d’acces a ces donnees

[4, 15]. Malheureusement, plus le degre de replication augmente plus le taux de divergence entre

les repliques a egalement tendance a augmenter. Pour eviter une telle situation, il est donc in-

dispensable d’assurer, ou plus exactement de maintenir, la coherence des repliques d’un meme

ensemble de donnees. Cette maintenance de la coherence sera d’autant plus compliquee lorsque

les operations de mise a jour seront frequentes. Nous avons etudie, dans le chapitre 2, deux

approches de gestion de la coherence de repliques, a savoir les approches pessimistes et opti-

mistes [28, 29]. Ces deux approches representent les cas extremes du rapport qui existe entre la

coherence et la disponibilite (voir Figure 3.1).

Fig. 3.1 – Coherence vs Disponibilite

L’approche pessimiste utilise le principe de la replication synchrone, dans laquelle la pro-

pagation des mises a jour vers les repliques intervient avant la validation des requetes. Cette

approche garantit la coherence des copies a tout instant, mais donne de faibles performances

[6, 40]. A l’inverse, l’approche optimiste utilise la replication asynchrone, dans laquelle la pro-

pagation des mises a jour vers les copies est differee. Le fait de differer ces mises a jour dans le

temps fait que les repliques peuvent diverger, ce qui aura pour consequence de reduire la qualite

de service vis-a-vis des clients [36, 50].

Comme nous l’avons deja mentionne dans le chapitre 2, les approches de coherence pessimiste

et optimiste possedent des limites soit par rapport a la disponibilite soit par rapport aux per-

formances. Partant de ces deux limites extremes, notre objectif est de definir une approche qui

puisse traiter le probleme de la coherence de repliques dans le cadre des grilles de donnees, mais

qui puisse egalement tirer profit des avantages combines des approches pessimistes et optimistes.

Ainsi, notre proposition vise a ameliorer la qualite de service offerte par l’approche optimiste et

35

3.2. Concepts et terminologie

a reduire le temps de reponse obtenu par l’approche pessimiste.

L’approche que nous proposons, et que nous avons appele approche hybride, tente de trouver

un compromis entre les approches pessimistes et optimistes. Pour cela, nous avons mis en œuvre

une demarche (voir Figure 3.2) [6], qui se base sur un modele hierarchique et distribue d’une

grille de donnees.

Fig. 3.2 – Positionnement de l’approche proposee

3.2 Concepts et terminologie

Dans cette section, nous allons introduire quelques concepts [1, 41, 49] qui sont necessaires

pour la comprehension du reste des sections de ce chapitre .

– Noms physique et logique : Un nom physique NPF definit chaque copie (replique) physique

d’un fichier et permet de specifier son emplacement dans un systeme de stockage. Le nom

logique NLF est un identifiant logique et unique dans l’espace de nommage de la grille de

donnees. Un nom logique peut regrouper une collection de noms physiques ;

– Replique : Copie d’un fichier ;

– Maıtre : Une replique est dite Maıtre, si elle recoit directement les operations de mises a

jour sur un fichier ;

– Esclave : Une replique est dite Esclave, si elle recoit les mises a jour par propagation a

partir de la replique maıtre ;

– ROWA (Read One Write All) : Definit un protocole de coherence forte, dans lequel les

lectures utilisent la technique de verrouillage et accedent a une seule copie, tandis que les

ecritures continuent a verrouiller [14, 16, 36] et a modifier toutes les copies. Toutes les

copies sont mises a jour de maniere synchrone, ce qui implique que toutes les copies sont

a jour. Ce protocole ne s’avere d’aucune utilite du point de vue de la tolerance aux fautes,

car une seule defaillance d’une copie peut bloquer tout le systeme jusqu’a ce que la panne

soit reparee [17, 31] ;

36

3.3. Pourquoi les clusters ?

– Quorum : C’est un protocole de coherence pessimiste, dans lequel les mises a jour se

font de maniere synchrone sur un sous-ensemble de copies [5]. Ce sous-ensemble forme ce

que l’on appelle un quorum en ecriture [16]. Pour les lectures, elles se font sur un autre

sous-ensemble, appele quorum de lecture [16]. La constitution des quorums de lecture et

d’ecriture permet d’eviter les conflits lecture-ecriture simultanees, et les ecritures simulta-

nees [33, 44] ;

– Timestamp (estampille) : C’est un indicateur de mise a jour qui est associe a une donnee.

Il est constitue de la date et de l’heure de la derniere modification de la donnee [16]. Dans

un modele de donnees qui utilise la replication, les timestamps sont utilises pour comparer

les versions de donnees provenant de differentes machines, ce qui permettra d’identifier la

donnee la plus recente [3]. Pour maintenir de tels indicateurs, il est necessaire de gerer une

horloge universelle commune a toutes les machines du systeme [16] ;

– Elements de calcul (EC) : Ce sont des ressources de type calcul dont la fonction est l’exe-

cution de programmes. Ce type de ressources peut aller d’un simple processeur d’un PC a

un supercalculateur ;

– Elements de stockage (ES) : Ces elements sont une abstraction de n’importe quelle unite

de stockage qui servira de support de stockage pour les repliques ;

– Grappe d’ordinateurs : Ensemble d’ordinateurs personnels ou de serveurs, relies par un

reseau ultra rapide, mutualisant diverses ressources (peripheriques, fichiers, bases de don-

nees, etc.) ;

– Meta-donnee : Une meta-donnee est un ensemble structure d’informations qui decrit une

replique, son contenu, ainsi que ses caracteristiques. Comme exemples d’informations, nous

pouvons citer : la date de creation, la date de la derniere mise a jour d’une replique, sa

taille, le nombre de mises a jour, le timestamp de la replique, etc.

3.3 Pourquoi les clusters ?

C’est dans les annees 90 que les clusters (ou grappes d’ordinateurs ou encore reseaux de

stations de travail) sont vraiment devenus populaires du fait de leur tres faible cout comparati-

vement aux supercalculateurs paralleles proprietaires qui restent tres chers, pour une puissance

de calcul quasiment equivalente [37].

Un autre avantage des clusters est leur grande extensibilite. Ils sont construits a partir de PCs

standard ou de stations de travail. Ainsi, a partir d’un budget relativement modeste, il est pos-

sible de construire une plate-forme qui peut convenir a une grande classe d’applications.

Un des facteurs importants qui a fait que les clusters sont devenus une alternative tres interes-

sante aux calculateurs paralleles est la standardisation de nombreux outils logiciels utilises par

les applications paralleles [27]. La liste suivante resume les differentes raisons qui font que les

37

3.4. Modele propose

clusters sont souvent preferes aux machines paralleles specialisees [37, 39] :

– Les stations de travail individuelles et les PCs standard sont de plus en plus puissants ;

– Les reseaux d’interconnexion des stations de travail (en particulier les reseaux haut de-

bit) sont devenus tres performants : la latence ne cesse de diminuer et le debit ne cesse

d’augmenter ;

– Les clusters sont plus faciles a integrer dans les reseaux existants que les supercalculateurs ;

– La standardisation des outils de developpement pour les clusters est un avantage compa-

rativement aux solutions proprietaires non standardisees ;

– Les clusters, a puissance de calcul egale, sont beaucoup moins chers que les machines

paralleles specialisees ;

– Un cluster peut evoluer tres facilement : ajout de nœuds de calcul, changement ou addition

de composants dans les nœuds de calcul (processeur, memoire) ;

Toutes ces caracteristiques, et bien d’autres, ont fait que nous avons choisi de travailler sur

des plates-formes de type cluster.

3.4 Modele propose

L’approche de gestion de la coherence de repliques, pour les systemes a large echelle, que

nous proposons dans cette these est basee sur une modelisation d’une grille sous la forme d’un

modele qui est a la fois hierarchique (hierarchie a deux niveaux) et distribue.

3.4.1 Modele de base pour la gestion de la coherence

Le modele de base represente une vue logique d’un site ou d’un cluster. Dans ce modele

de base, un site ou un cluster represente un ensemble de ressources informatiques homogenes

reliees par un reseau et localisees geographiquement dans une meme organisation (Campus

universitaire, Centre de calcul, Entreprise ou Personne individuelle). Cet ensemble forme un

domaine d’administration autonome, uniforme et coordonne [27, 37]. D’une facon generale, ces

ressources sont regroupees pour former ainsi les nœuds d’un site comme l’illustre la Figure 3.3.

38

3.4. Modele propose

Fig. 3.3 – Composants d’un site

Pour le processus de gestion de coherence des repliques, le modele de base est defini par

un arbre a deux niveaux : une racine pour la gestion des repliques et un ensemble nœuds. Ces

derniers representent les feuilles de l’arbre et elles contiennent les elements de calcul (EC) et de

stockage (ES) (voir Figure 3.4).

Dans ce modele, le Noeud js correspond au jieme nœud du site S. Ce nœud sera charge de gerer

Fig. 3.4 – Modele de base pour la gestion de la coherence

les repliques au sein du site S.

39

3.4. Modele propose

A. Premier niveau

Le premier niveau, ou niveau 0, de notre modele de base represente les composants d’un site,

a savoir un ensemble de nœuds. Chaque nœud est compose essentiellement de deux types de

ressources [39, 43] : des elements de calcul (EC) et des elements de stockage (ES). Le role de

l’element de calcul d’un nœud consiste a recevoir et a executer la requete soumise par un client

donne et concernant une replique stockee dans un element de stockage (ES) du nœud.

B. Deuxieme niveau

Le deuxieme niveau du modele de base (niveau 1) est constitue d’un seul nœud appele le

Gestionnaire de Repliques du site (GR).

i. Fonctions du gestionnaire de repliques : Deux principales fonctions sont associees au

gestionnaire de repliques (voir Figure 3.5) :

– Controler la coherence locale au sein du site auquel il est associe ;

– Collaborer avec les gestionnaires de repliques d’autres sites pour determiner une coherence

globale au niveau d’une grille.

Fig. 3.5 – Principales fonctions d’un gestionnaire de repliques

ii. Choix du nœud gestionnaire : La gestion des repliques d’un site sera assuree par un

nœud choisi parmi l’ensemble des nœuds qui constituent ce site. Le choix de ce nœud pourrait se

faire selon plusieurs methodes : choix aleatoire, election, par negociation, potentialites en terme

de ressources, fiabilite du nœud, etc. [5, 55].

40

3.4. Modele propose

3.4.2 Modele general

Le modele general que nous proposons pour la gestion de la coherence comporte deux niveaux

[4, 6] : (i) le niveau 0 qui est compose d’un ensemble de sites qui forment une grille ; et, (ii)

le niveau 1 qui represente un niveau de controle et de prise de decision en ce qui concerne la

gestion de la coherence (voir Figure 3.6).

Site SpSite S1

Cohérence Locale

Cohérence Globale

N iveau 0

N iveau 1

GR1

: Transfert de données : Transfert de méta-données

Noeud1r

§ § § § §

§ § §

Fig. 3.6 – Modele hierarchique et distribue pour la gestion de coherence de repliques

Le modele general propose dans cette these permet de representer une grille en agregeant

p modeles de base (voir paragraphe 3.4.1). Le schema de la Figure 3.7 correspond a ce modele

general.

A. Premier niveau

Le premier niveau, ou niveau 0, de notre modele est compose d’un ensemble de sites, ou

chaque site forme un modele de base. Les elements de ce niveau representent l’ensemble des

nœuds.

B. Deuxieme niveau

Dans notre modele, ce deuxieme niveau (niveau 1) est un niveau virtuel par rapport a

l’architecture physique d’une grille. Il est constitue de gestionnaires associes aux differents sites

du modele. Chaque gestionnaire est associe a un et un seul site S de la grille et nous l’appellerons

le gestionnaire de repliques GRS selon la Figure 3.6.

41

3.5. Flux de communication

Fig. 3.7 – Exemple d’une grille reelle representee par notre modele

Les principales fonctions d’un gestionnaire de repliques sont :

– Collaborer avec les differents gestionnaires de repliques pour faire converger les repliques

d’un meme fichier vers une replique de reference globale ;

– Diffuser les nouvelles informations de la replique de reference aux differents nœuds de son

site.

3.5 Flux de communication

Pour assurer la coherence entre repliques, trois flux de donnees sont necessaires entre les

differents elements du modele de coherence propose [4, 6] (voir Figure 3.6 ) :

1. Le premier flux se situe au niveau des nœuds de chaque site. Ce flux permet aux elements

de calcul des nœuds (EC’s) d’echanger deux types d’informations :

– Informations sur les repliques stockees dans leurs ES’s respectifs. Ces informations, de

type meta-donnees attachees aux repliques, permettent de decrire l’etat des repliques.

Parmi les informations qui decrivent cet etat, nous pouvons mentionner les vecteurs de

version [3, 4, 50] ;

– Les EC’s peuvent egalement s’echanger les ensembles contenant les operations de mises

a jour, pour permettre la convergence des repliques vers un etat coherent.

2. Le deuxieme flux concerne l’echange d’informations entre les couples (EC,ES) d’un nœud

et le nœud qui est charge de les gerer (gestionnaire de repliques). Rappelons que ce flux

concerne l’echange d’informations entre les deux niveaux du modele propose et permet

l’echange des meta-donnees sur les repliques. Grace a ce flux, le gestionnaire de repliques

d’un site pourra avoir une vue globale sur les repliques existantes dans ce site ;

3. Le dernier flux permet un echange horizontal entre nœuds gestionnaires de repliques des

42

3.6. Caracteristiques du modele propose

sites, qui se trouvent au deuxieme niveau du modele. Il permet d’obtenir une coherence

globale des repliques au niveau de toute la grille.

3.6 Caracteristiques du modele propose

Le modele de coherence, propose dans cette these, est une representation hierarchique qui

vise a distribuer les communications et les responsabilites administratives de la coherence entre

les gestionnaires de repliques Ceci a pour effet d’equilibrer la charge au niveau de grille et de

gerer un plus grand nombre de sites a la fois.

Notre modele presente un aspect cooperatif dans la mesure ou il se base sur l’echange des in-

formations entre entites qui presentent des interets communs telle que la coherence globale. La

cooperation consiste a echanger des informations entre les sites par l’intermediaire de leurs ges-

tionnaires de repliques respectifs. En outre, le modele est extensible etant donne qu’il est capable

d’integrer de nouveaux sites sans etre oblige de reformuler ou de redimensionner ses constituants.

Cette facilite de gestion favorise l’utilisation de ce modele dans les systemes a large echelle [4].

La representation structurelle du modele peut etre schematisee par le diagramme UML de

la Figure 3.8.

Fig. 3.8 – Diagramme de classes du modele de coherence propose

43

3.7. Conclusion

Les principales caracteristiques de notre modele peuvent se resumer comme suit :

1. Taille : Le modele propose est compose uniquement de deux niveaux, quelque soit la

complexite topologique d’une grille. De plus, un des niveaux de l’arbre (niveau 1) est

purement virtuel ;

2. Transparence : Un site est percu par un utilisateur comme etant une entite logique

unique a laquelle il s’adresse sans avoir besoin de connaıtre ni sa localisation dans la grille,

ni sa composition ;

3. Gestion hybride de la coherence : Par sa structure a deux niveaux, le modele general

propose facilite l’hybridation d’approches de coherence pessimistes et optimistes ;

4. Gestion incrementale de la coherence : Les incoherences entre repliques sont d’abord

traitees au niveau 0 puis au niveau 1. Si une incoherence persiste au niveau 0, le niveau 1

essaiera de la corriger en tenant compte des coherences trouvees au niveau 0 ;

5. Diversite des strategies : La separation des sites et leur gestion par des nœuds virtuels

permet de diversifier les strategies de replication au niveau des sites. Cette diversification

peut constituer une plus-value dans la gestion de la coherence ;

6. Passage a l’echelle : De part sa structure arborescente, le modele s’adapte tres facilement

au changement d’echelle : ajout et retrait de sites, augmentation ou diminution du nombre

de repliques ;

7. Fiabilite : Avec la dynamicite de la grille, le modele peut facilement s’adapter a cette

aspect en tolerant les pannes des nœuds ou des sites ;

8. Complexite : L’analyse du modele, en terme de complexite en nombre de messages,

montre qu’il a une complexite lineaire. Ainsi, nous avons une complexite de O(n2) au

niveau 0 et de O(n) au niveau 1, de meme que pour les messages entre les deux niveaux,

n etant le nombre de repliques dans un site. Remarquons en plus que si la communication

au niveau 0 se fait selon une topologie anneau, alors la complexite est de l’ordre de O(n)

et ce, quelque soit le niveau.

3.7 Conclusion

Dans ce chapitre, nous avons propose un modele hierarchique et distribue pour la gestion de

la coherence de repliques dans les systemes a large echelle. Ce modele, compose de deux niveaux,

se trouve adapte aux systemes a large echelle et facilite une hybridation entre les approches de

coherence optimistes et pessimistes.

A partir de ce modele, nous allons decrire l’algorithmique associee a l’approche de gestion de

coherence que nous proposons dans cette these.

44

Chapitre 4

Approche hybride pour la gestion de

la coherence

45

4.1. Introduction

4.1 Introduction

Pour assurer la coherence de repliques, nous definissons un service de gestion de coherence,

qui represente le noyau du modele propose dans cette these [5, 6]. Ce service procede en deux

etapes (voir Figure 4.1) : la premiere se fait a l’interieur d’un site, et elle realise ce que nous

appelons le service de gestion de coherence intra-site ou encore le service de coherence locale.

Par contre, la deuxieme etape implique les differents sites d’une grille, et elle concerne le service

de gestion de coherence inter-sites ou encore le service de coherence globale.

Site1 Sitep

Service de Cohérence

Service de

Cohérence

Intra-site

Service de

Cohérence

Intra-site

ES11 … ES1k ESp1 … ESpr

Service de Cohérence

Inter-sites

. . . .

Fig. 4.1 – Architecture du service de gestion de coherence de repliques

Ces deux services sont complementaires [4, 6] et ont pour objectif principal de faire converger

l’ensemble des repliques vers une replique de reference globale.

Pour ameliorer encore plus l’approche de gestion de coherence hybride, nous l’avons etendu par

un modele economique pour le placement des repliques. Ce modele economique aura pour objectif

essentiel de determiner le placement des repliques dans les nœuds au sein des sites correspon-

dants (voir Figure 4.2). En effet, nous pensons qu’un bon placement des repliques contribuera a

ameliorer les performances de l’approche hybride proposee, notamment d’un point de vue temps

de reponse et cout de communication et pourra, dans une certaine mesure, permettre de reduire

le degre de divergences et de conflits entre repliques d’un meme fichier.

46

4.2. Gestion de coherence intra-site

Fig. 4.2 – Diagramme de l’approche hybride de gestion de la coherence de repliques

4.2 Gestion de coherence intra-site

Le but essentiel de la gestion de la coherence intra-site est de faire converger les repliques

d’une donnee, stockees dans un meme site, vers une replique de reference locale. Ce service de

gestion de coherence, inspire des approches optimistes [6, 50], favorise le temps de reponse par

rapport a la coherence. Partant de cet objectif, il est donc possible que les repliques d’un fichier

puissent diverger. Ainsi, a un instant donne, un utilisateur peut observer des copies d’un meme

fichier avec des valeurs differentes.

Le processus de gestion de coherence intra-site est compose des taches suivantes :

– Traitement de requetes : Cette tache a pour role d’executer une requete soumise par un

client ;

– Propagation : Etant donne que nous acceptons le fait que les repliques d’un fichier puissent

diverger, la tache de propagation consiste a faire un transfert des mises a jour au sein d’un

site donne vers les repliques qui ne sont pas a jour. Cette propagation assure, qu’au bout

d’un temps fini, les repliques convergeront vers une replique de reference locale ;

– Tolerance aux fautes : Cette tache a pour but de prendre en charge les defaillances de

nœuds d’un site donne et d’un site au niveau de toute la grille ;

– Mise a jour du modele : Cette tache realise les fonctions necessaires a la mise a jour du

modele, et notamment l’integration de nouveaux nœuds dans un site.

47


4.2.1 Notations

La table suivante liste un ensemble de notations qui seront utilisees par la suite dans cette

these.

Notation Description

Si Site i

Ni j Noeud j du site Si

Ok Objet ou fichier k

Rkp Replique p du fichier Ok

Rkp(i j) Replique p du fichier Ok stockee dans le nœud j du site i

GRi Gestionnaire de repliques du site Si

Reqi(k) Requete d’un client emise a partir du site Si

est relative au fichier k

V Rkp(i j)[] Vecteur a deux composantes associe a la replique p

du fichier Ok stockee dans le nœud Ni j

La premiere composante contient le nombre de mises a jour a faire et

la deuxieme composante contient le nombre de mises a jour effectuees

EMAJkp Ensemble des mises a jour de la replique p du fichier Ok

EMAJkp(i j) Ensemble des mises a jour de la replique p du fichier Ok

maintenues par le nœud j du site Si

EMAJGRi(kp) Ensemble des mises a jour de la replique p du fichier k

maintenues par le gestionnaire GRi du site Si

VVk[] Vecteur de versions contenant le numero de version

de toutes les repliques du fichier Ok ; sa taille correspond au nombre de repliques

VVkp(i)[] Vecteur de versions de la replique p du fichier Ok

stockee dans le site Si ; sa taille correspond au nombre de repliques

VVk(i j)[p] Numero de version de la replique p du fichier Ok

maintenue par le nœud N j du site Si

ENkp Ensemble de nœuds contenant une replique p du fichier Ok

IDkp(i) Ensemble des identites des nœuds du site Si, qui contiennent

une replique p du fichier Ok

Tab. 4.1 – Tableau de notations

48


4.2.2 Gestion de coherence intra-site basee sur la strategie uni-maıtre

Le processus de gestion de coherence intra-site, base sur la strategie uni-maıtre [32, 50],

commence par selectionner une replique maıtresse parmi l’ensemble des repliques stockees dans

les nœuds d’un site donne. Le nœud contenant cette replique sera appele le maıtre. Le maıtre

ainsi choisi joue le role de gestionnaire des repliques d’un fichier donne a l’interieur d’un site.

Les principales fonctions du gestionnaire des repliques d’un meme fichier, au sein d’un site, sont

definies comme suit :

– Mettre a jour, par un mecanisme de propagation, les differentes repliques d’un meme fichier

au sein du site auquel il est associe ;

– Cooperer avec les autres gestionnaires des sites pour obtenir une coherence globale du

systeme.

Dans la strategie uni-maıtre, une requete d’un client de type ecriture, concernant un fichier

donne, ne doit etre effectuee que sur ce maıtre, alors qu’une requete de lecture peut acceder a

n’importe quelle replique de ce fichier.

Dans ce qui suit, nous supposons qu’un fichier Ok est replique au plus � r � fois dans un meme

site (r > 0).

Traitement d’une requete

Une requete est composee d’un identifiant d’un site, d’un type d’acces (lecture ou ecriture),

et concerne un fichier particulier. Ce dernier est replique au plus r fois dans un site donne.

Lorsque un client soumet une requete, l’algorithme 1 est declenche pour executer cette requete.

Algorithm 1 Algorithme de Traitement d’une Requete Client avec la strategie

uni-maıtre

1: if Reqi(k) = Lecture then

2: Executer la requete sur n’importe quelle replique p du fichier Ok au sein du site Si

3: Envoyer reponse au client

4: else

5: Executer la requete sur la replique du maıtre (GRi)

6: EMAJGRi(kp)←{EMAJGRi(kp)}⋃{Reqi(k)}

7: end if

Le fonctionnement de l’algorithme 1 se resume comme suit :

1. Dans le cas d’une requete de lecture, il s’agit : (i) de choisir un nœud du site S i contenant

une replique, du fichier considere, sur laquelle sera executee la requete de lecture (ligne 2) ;

(ii) d’envoyer le resultat de cette requete de lecture au client qui la soumise (ligne 3).

49


2. Dans le cas d’une requete d’ecriture, toutes les operations liees a cette requete se feront sur

la replique stockee dans le nœud maıtre (ligne 5). Une fois la requete executee, il faudra

maintenir l’ensemble des mises a jour relatif a la replique sur laquelle a ete executee la

requete d’ecriture (ligne 6). Cet ensemble sera utilise par la suite pour rendre coherentes

les differentes repliques d’un meme fichier.

Cet algorithme etant tres simple, puisque ne comprenant aucune boucle, sa complexite est

egalement tres simple. Dans le cas d’une lecture ou d’une ecriture, la complexite est de l’ordre

de O(1) (lignes 2 ou 5 et 6). En terme de communication, la complexite est egalement de l’ordre

de O(1) (ligne 3).

Propagation des mises a jour

La tache de propagation consiste a transferer les operations de mises a jour, relatives a un

fichier, vers ses repliques qui ne sont pas encore a jour. Cette propagation peut etre declenchee

soit de maniere periodique, soit lorsque le taux d’operations d’ecriture aura depasse un seuil

predefini.

Pour effectuer cette propagation, nous avons defini deux algorithmes : le premier (voir Algo-

rithme 2) est execute par le nœud uni-maıtre pour propager l’ensemble des mises a jour vers les

autres nœuds appartenant au meme site que lui ; le deuxieme algorithme (voir Algorithme 3) est

execute par les nœuds d’un site donne, pour leur permettre de mettre a jour les repliques qui

sont stockees chez eux.

Algorithm 2 Algorithme de Propagation

1: Multicast(EMAJGRi(kp),{ENkp})

2: EMAJGRi(kp)← /0

Rappelons que le nœud uni-maıtre maintient un ensemble EMAJGRi(kp), contenant toutes

les mises a jour effectuees sur une replique p d’un fichier Ok. Pour obtenir une coherence entre

toutes les repliques d’un meme fichier, cet ensemble devra donc etre transmis a tous les nœuds

contenant une replique du fichier Ok. Ainsi, l’algorithme 2 sera execute par le nœud uni-maıtre

afin de propager les mises a jour d’une replique vers les nœuds de l’ensemble ENkp, qui represente

l’ensemble des nœuds contenant une replique p du fichier Ok (ligne 1). Une fois la propagation

terminee, l’ensemble sera vide (ligne 2).

Mis a part la partie communication (execution de l’operation Multicast), la complexite de

cet algorithme est de l’ordre de O(1).

L’algorithme 3 sera execute par tous les nœuds contenant une replique p d’un fichier Ok, une

fois qu’ils auront recu l’ensemble des mises a jour a partir du nœud uni-maıtre (voir algorithme

50


Algorithm 3 Algorithme de reception des MAJ d’un fichier Ok par un nœud

1: /* Soient Ni j le nœud j du site Si et Rkp(i j) la replique p du fichier Ok stockee dans Ni j */

2: EMAJkp←{EMAJkp}⋃{EMAJGRi(kp)}

3: V Rkp(i j)[1]←V Rkp(i j)[1]+ | {EMAJGRi(kp)} |

4: Executer les requetes de l’ensemble {EMAJkp}

5: Pour chaque requete traitee faire VRkp(i j)[1]- - et VRkp(i j)[2]++

2). Le fonctionnement de cet algorithme peut se resumer comme suit :

1. Rajouter l’ensemble des mises a jour, recu a partir du nœud uni-maıtre, a l’ensemble des

mises a jour propres a chaque replique locale par rapport a un nœud Ni j (ligne 2).

2. Mettre a jour la premiere composante du vecteur local des mises a jour (ligne 3), a savoir

le vecteur V Rkp(i j) (vecteur local par rapport au nœud j du site Si et relatif a la replique

p du fichier Ok). Cette composante contient le nombre de mises a jour a effectuer sur la

replique p du fichier Ok stockee dans le nœud Ni j.

3. Executer les mises a jour locales (ligne 4).

4. Mettre a jour les deux composantes du vecteur local V Rkp(i j). Pour la premiere composante,

il faut la diminuer d’une unite a chaque fois que l’on execute une operation de mise a jour

(ligne 5) ; par contre, pour la deuxieme composante qui contient le nombre d’operations

de mise a jour effectuees, il faudra l’augmenter d’une unite (ligne 5).

Au niveau de chaque nœud, la complexite de cet algorithme est de l’ordre de O(1). Si nous

considerons qu’un fichier est replique au plus r fois, alors la complexite de mise a jour de toutes

les repliques sera de l’ordre de O(r).

Tolerance aux fautes

Une defaillance de l’uni-maıtre provoque le declenchement d’un processus d’election pour

choisir un nouveau maıtre. Pour effectuer cette election, deux variantes sont possibles, selon que

nous privilegions la rapidite du processus d’election ou la coherence des repliques.

Pour la premiere variante, le maıtre est choisi sur la base du plus petit indice des nœuds

d’un site Si, contenant des repliques d’un fichier Ok (voir Algorithme 4).

Algorithm 4 Algorithme d’Election-Rapide

1: /* Soit {IDkp(i)} l’ensemble des identites des nœuds, du site Si, qui contiennent une replique

p du fichier Ok */

2: /* Le nouveau uni-maıtre sera le nœud qui aura le plus petit indice en terme d’identite */

3: GRi←Min({IDkp(i)})

51


Avec cette variante, l’uni-maıtre est elu rapidement. La complexite pour rechercher le nœud

qui a le plus petit indice necessite (n− 1) comparaisons, n etant la cardinalite de l’ensemble

IDkp(i). Cette election pourra etre encore acceleree si les elements de l’ensemble IDkp(i) sont

tries par ordre decroissant sur les identites ; dans ce cas, la complexite sera de l’ordre de O(1).

Par contre, cette variante pourra elire un nœud uni-maıtre qui n’a pas encore effectue l’ensemble

de ses mises a jour.

La deuxieme variante privilegie la coherence par rapport au temps d’election. Le choix de

cette variante se base sur le nombre de mises a jour effectuees (voir Algorithme 5), c’est-a-

dire que nous choisissons le nœud contenant la replique la plus a jour par rapport aux autres

repliques. Comparativement a la premiere variante, la recherche du nouveau nœud uni-maıtre

sera plus couteuse en terme de temps.

Algorithm 5 Algorithme d’Election basee sur la coherence

1: Terminer les operations d’ecriture en cours

2: Multicast(V Rkp(i j),{ENkp})

3: /* Soit Nim un element de ENkp */

4: if (V Rkp(im)[1]−VRkp(im)[2] = 0) then

5: GRi← Nim

6: else

7: Min(V Rkp(i j)[1]−V Rkp(i j)[2]), ∀ j ∈ {1.. | {ENkp} |}

8: /* Soit Niq le nœud q du site Si qui verifie ce minimum */

9: GRi← Niq

10: end if

L’election basee sur la coherence est une election distribuee. Ceci veut dire que tous les

nœuds vont declencher une operation d’election en s’echangeant leurs informations locales. Le

principe de cette election distribuee est defini par l’algorithme 5, dont nous allons expliquer le

fonctionnement a travers l’exemple d’un nœud Ni j. Soit ENkp l’ensemble des nœuds contenant

une replique p d’un fichier Ok. Le comportement de l’algorithme d’election basee sur la coherence

se decrit comme suit :

1. Le nœud Ni j commence par terminer, eventuellement, l’execution des operations de mises

a jour qui sont en cours de traitement (ligne 1).

2. Une fois les operations en cours terminees, le nœud Ni j diffuse son vecteur local aux ele-

ments de l’ensemble ENkp (ligne 2). Etant donne que les instructions des lignes 1 et 2 de

l’algorithme sont executees par tous les nœuds qui contiennent une replique p d’un fichier

Ok, chaque nœud pourra connaıtre, a un moment donne, l’etat de sa replique ainsi que

52


celui de toutes les autres repliques. A partir de cet instant, il sera possible de trouver, de

maniere parallele et distribuee, la replique qui est la plus a jour.

3. Pour le choix du nœud qui contient la replique la plus a jour, deux cas sont envisageables :

– Cas 1 : il existe un nœud qui a effectue l’ensemble des mises a jour (condition de la ligne

4 verifiee) ; dans ce cas, c’est ce nœud qui deviendra le nœud maıtre (ligne 5).

– Cas 2 : aucun noeud n’a effectue l’ensemble des mises a jour (cas false de la ligne 4) ; dans

ce cas, il faudra choisir comme nœud maıtre, celui qui aura effectue le plus d’operations

de mises a jour (lignes 7 et 9).

En terme de complexite deux cas sont a considerer : (i) dans le meilleur des cas, la complexite

sera de O(1) s’il existe un nœud qui a effectue l’ensemble des mises a jour ; (ii) dans le pire des

cas, aucun nœud n’aura effectue l’ensemble des mises a jour et auquel cas la recherche du maıtre

necessitera (n−1) comparaisons, n etant la cardinalite de l’ensemble ENkp.

Arrivee d’un nouveau nœud

Soit ENkp l’ensemble des nœuds contenant une replique p d’un fichier Ok et soit Nix un

nouveau nœud x qui integre le site Si. Deux scenarios sont possibles :

1. Si le nœud Nix n’a pas ete choisi pour contenir des repliques du fichier Ok, alors aucun

traitement particulier ne sera effectue vis-a-vis de la gestion des repliques ;

2. Si Nix a ete choisi pour contenir des repliques du fichier Ok, alors les operations suivantes

seront effectuees :

(a) ENkp←{ENkp}⋃{Nix} ;

(b) Creer le vecteur VRkp(ix) pour le nœud Nix ;

(c) Propager l’ensemble des mises a jour EMAJGRi vers EMAJkp(ix)

(d) VRkp(ix)[1]←VRkp(ix)[1]+ | {EMAJGRi} |

4.2.3 Gestion de coherence intra-site basee sur la strategie multi-maıtres

Pour la gestion de coherence intra-site utilisant la strategie multi-maıtres, une requete d’un

client, de type lecture ou ecriture, peut etre executee sur n’importe quel nœud contenant une

replique du fichier invoque par la requete.

Traitement d’une requete

Lorsque un client soumet une requete Reqi(k) a partir d’un site Si qui utilise la strategie

de replication multi-maıtres, alors cette requete pourra acceder a n’importe quelle replique p

du fichier Ok d’un nœud du site Si. La procedure de traitement d’une requete est decrite par

l’algorithme 6.

53


Algorithm 6 Algorithme de traitement d’une requete par un nœud Ni j

1: if Reqi(k) = Lecture then

2: Executer la requete sur une replique Rkp stockee dans le nœud Ni j

3: Envoyer reponse au client

4: else

5: /* Soit Rkp la replique p du fichier Ok choisie pour executer la requete du client */

6: Executer la requete Reqi(k)

7: EMAJkp(i j)← {EMAJkp(i j)}⋃{Reqi(k)}

8: VVk(i j)[p]++

9: end if

Cet algorithme etant tres simple, sa complexite est du meme ordre que celle de l’algorithme

1.

Theoremes de convergence

Nous allons enoncer, dans ce qui suit, trois theoremes pour definir la coherence entre repliques

d’un meme fichier. Soient deux vecteurs de versions VVkp(i) et VVkl(i), de taille r, des repliques

p et l stockees dans le site Si.

Theoreme 1. Deux repliques p et l sont dites convergentes si et seulement si

VVkp(i)[t] = VVkl(i)[t],∀t ∈ {1..r}.

Preuve 1. Soient deux repliques Rp et Rl d’un meme fichier Ok stockees dans le site Si.

Supposons que :

VVkp(i)[t] = VVkl(i)[t],∀t ∈ {1..r} (4.1)

L’equation (4.1) stipule que les deux vecteurs VVkp et VVkl sont identiques ; en consequence,

les deux repliques Rp et Rl ont recus les memes operations de mises a jour, ce qui permettra

a ces deux repliques de converger vers le meme etat.

Theoreme 2. Deux repliques p et l sont dites divergentes si et seulement si

∃!s ∈ {1..r}|VVkp(i)[s] 6= VVkl(i)[s].

Autrement dit, les vecteurs VVkp(i) et VVkl(i) ne different que par une seule composante.

Preuve 2. Soient deux repliques Rp et Rl d’un meme fichier Ok stockees dans le site Si et soient

les equations suivantes :

VVkp(i)[t] = VVkl(i)[t],∀t ∈ {1..(s−1)} (4.2)

VVkp(i)[s] 6= VVkl(i)[s] (4.3)

54


VVkp(i)[u] = VVkl(i)[u],∀u ∈ {(s+1)..r} (4.4)

A partir des equations (4.2), (4.3) et (4.4), les deux vecteurs VVkp et VVkl sont differents

uniquement par la composante s. Donc, les repliques Rp et Rl ne sont pas egales et divergent

sur une seule composante. Pour que ces deux repliques convergent, il faut qu’une replique,

parmi Rp et Rl et possedant la plus grande valeur de la composante s de leur vecteur de

versions, propage les operations manquantes a l’autre replique.

Theoreme 3. Deux repliques p et l sont dites conflictuelles ou en conflit si et seulement si les

vecteurs VVkp(i) et VVkl(i) different par au moins deux composantes.

Preuve 3. Soient deux repliques Rp et Rl d’un meme fichier Ok stockees dans le site Si.

Soient deux indices j et s avec j 6= s tel que :

VVkp(i)[ j] 6= VVkl(i)[ j] avec 1≤ j ≤ r (4.5)

VVkp(i)[s] 6= VVkl(i)[s] avec 1≤ s≤ r (4.6)

A partir de l’equation (4.5) et en utilisant le theoreme 2, nous dirons que R p et Rl sont

divergentes entre elles par rapport a la composante j de leurs vecteurs de versions.

A partir de l’equation (4.6) et en utilisant le theoreme 2, nous concluons que R p et Rl sont

divergentes entre elles par rapport a la composante s de leurs vecteurs de versions.

La resolution de cette double divergence ((4.5) et (4.6)) entre les deux repliques R p et Rl

necessite des propagations des mises a jour manquantes de l’une des repliques par rapport

a l’autre. Le processus de resolution de ce conflit peut se faire selon les solutions suivantes :

a) Soit le processus de resolution commence par regler la divergence de l’equation (4.5)

puis celle de (4.6) ;

b) Soit le processus de resolution commence par regler la divergence de l’equation (4.6)

puis celle de (4.5) ;

Exemple de construction du vecteur de versions

L’exemple ci-dessous permet d’illustrer la maniere de construire les vecteurs de versions de

repliques. Soit un systeme contenant trois repliques R1, R2 et R3 d’un meme fichier Ok et soient

VVk1, VVk2 et VVk3 les trois vecteurs de versions associes a ces repliques. Nous designons par

VREF le vecteur de reference de ces trois vecteurs de versions. Considerons le scenario defini par

le tableau 4.2 :

55


Instants Operations Contenu des vecteurs Vecteur de

effectuees de versions reference

VVk1(R1) VVk2(R2) VVk3(R3) VREF

t1 R1 a subi une mise a jour 1 | 0 | 0 0 | 0 | 0 0 | 0 | 0 1 | 0 | 0



t4 R1 propage ses MAJ a R2 1 | 0 | 0 1 | 2 | 0 0 | 0 | 0 1 | 2 | 0







Tab. 4.2 – Exemples de construction d’un vecteur de reference

Le vecteur ainsi construit joue un role referentiel pour chaque replique. La phase de propa-

gation des operations des mises a jour, entre les differentes repliques, est declenchee a la suite

des comparaisons entre le vecteur de reference des repliques et le vecteur de versions de chaque

replique.

Trois situations peuvent etre rencontrees pour une replique R j :

1. Si le vecteur de version de la replique R j est identique au vecteur de reference VREF, alors

la replique R j a recu toutes les operations de mises a jour et aucune propagation n’est

necessaire. Nous sommes en presence d’une situation de convergence (voir Figure 4.3) ;

Vecteur deversion de Rj

Vecteur de

ré férence VREF

S ituation Convergente (aucune propagation n’est nécessaire)

1 2 0 1 1 1 2 0 1 1

Fig. 4.3 – Cas de convergence

2. Si le vecteur de versions de la replique R j differe d’une seule position (par exemple s) par

56


rapport au vecteur V REF, alors la replique Rs doit propager ses operations manquantes de

mises a jour a la replique R j, c’est-a-dire que l’ensemble des operations manquantes a la

replique R j, definit par {EMAJs}−{EMAJ j}, doit etre envoye a R j, avec respect de l’ordre

des operations de mises a jour. Nous sommes en presence d’une situation de divergence ou

la replique Rk domine la replique R j (voir Figure 4.4) ;

1 2 3 4 5 1 2 3 4 5

Vecteur deversion de Rj

Vecteur de

ré férence VREF

1 2 0 1 1

Situation Divergente

Puisque VREF diffère de Rj par la posit ion 2

qui correspond à la réplique R2, a lors R2

propage les opéra tions de mises à jour

manquantes à la réplique Rj.

EMAJj ¬ {EMAJ j} È { EMAJ2 - EMA Jj }

1 3 0 1 1

Fig. 4.4 – Cas de divergence

3. Si le vecteur de versions de la replique R j differe sur deux ou plusieurs positions par

rapport au vecteur VREF, alors la replique doit recevoir les operations des mises a jour

de plusieurs repliques. Nous sommes en presence d’une situation de conflit entre repliques

pour R j (voir Figure 4.5). Dans ce cas, la resolution des conflits utilise le principe de fusion

des operations non recues par la replique R j. Ce principe necessite que chaque replique

doit echanger mutuellement les operations manquantes avec l’autre replique.

Soit D l’ensemble des positions differentes du vecteur de versions de la replique R j par

rapport au vecteur V REF ; alors pour

∀k ∈ D faire EMAJ j←{EMAJ j}⋃{{EMAJk}−{EMAJ j}}

ou : {EMAJk}−{EMAJ j} represente l’ensemble des operations manquantes a la replique j.

57


Fig. 4.5 – Cas de conflit

Etat d’une replique

L’etat d’une replique peut changer au cours du temps a partir de l’execution d’operations de

mises a jour locales et/ou a travers la reception d’operations de mises a jour transmises par le

mecanisme de propagation (voir Figure 4.6). L’etat d’une replique peut ainsi avoir trois valeurs :

1. Il est dit convergent si cette replique est identique au vecteur de reference.

2. Il est dit divergent si son vecteur de version differe du vecteur de reference par une seule

composante.

3. Il est dit en conflit si la difference entre le vecteur de version de la replique et le vecteur

de reference porte sur plus de deux composantes.

Créat ion

réplique

Après un temps fin i les

répliques convergent

Convergence

Divergence

Conflit

Fig. 4.6 – Diagramme des etats d’une replique

58


Instants de propagation

Dans la strategie multi-maıtres, l’instant de declenchement de la procedure de propagation

se fera dans les memes conditions que pour la strategie uni-maıtre, a savoir soit de maniere

periodique soit apres un certain taux d’operations d’ecriture. Selon la politique de propagation

choisie, les repliques diffusent leurs vecteurs de versions aux autres repliques. Partant du fait que

chaque replique dispose d’un ensemble ordonne d’operations de mises a jour qu’elle a effectue,

l’algorithme de propagation, utilise dans le cadre de la strategie multi-maıtres, commence par

construire un vecteur de reference, appele V REF, contenant le nombre maximum de mises a jour

pour chaque replique Rkp (voir Algorithme 7).

Algorithm 7 Algorithme de propagation

1: Multicast(VVkp(i),{ENkp}) ;

2: V REF[l]←VVkp(i)[l], ∀l ∈ {1..r}

3: if Convergent(VVkp(i),V REF) then

4: Etat de coherence (Pas de propagation)

5: else

6: if Divergent(VVkp(i),V REF) then

7: /* Soit m l’indice de la composante dont la valeur est differente entre le vecteur de

versions et le vecteur de reference */

8: DIF← {Operations de mise a jour manquantes pour la composante m }

9: EMAJkl(i)←{EMAJkl(i)}⋃{DIF}

10: else

11: if Con f lit(VVkp(i),V REF) then

12: /* Conflit entre le vecteur de versions et le vecteur de reference sur plusieurs compo-

santes */

13: /* Echange mutuel des operations de mises a jour manquantes entre les repliques qui

sont en conflit */

14: end if

15: end if

16: end if

Le principe de fonctionnement de l’algorithme de propagation pour la strategie multi-maıtres

(voir algorithme 7), qui sera execute par chaque maıtre, est defini comme suit : Soient ENkp

l’ensemble des nœuds contenant une replique p d’un fichier Ok, et r le nombre de repliques du

fichier Ok stockees dans le site Si.

1. Chaque maıtre diffuse a tous les autres son vecteur de versions (ligne 1).

2. Une fois les vecteurs de versions recus, chaque maıtre construit son vecteur de reference

59


VREF (ligne 2).

3. A partir de ce vecteur de reference, l’algorithme determine l’etat de coherence des repliques

et en fonction de cet etat, il effectue les corrections necessaires. Trois types d’etats sont

envisageables (lignes 3-15) :

(a) Etat de convergence : les repliques etant coherentes, aucune action n’est effectuee

(lignes 3-4).

(b) Etat de divergence : ici nous sommes dans le cas ou une replique est differente par

rapport au vecteur de reference, mais cette difference porte sur une et une seule

composante. Ceci veut dire que le vecteur de reference domine le vecteur de version.

Autrement dit, il existe un certain nombre d’operations de mises a jour, repertoriees

par le vecteur de reference, qui ne sont pas connues par le vecteur de versions de la

replique. Il faudra donc les rajouter a l’ensemble des mises a jour de la replique (lignes

6-9).

(c) Etat de conflit : ce dernier cas illustre le fait que les differences entre la replique

et le vecteur de reference portent sur deux ou plusieurs composantes (operations de

mises a jour manquantes). Pour resoudre ce conflit, les nœuds doivent s’echanger,

mutuellement l’un par rapport a l’autre, les operations de mises a jour manquantes,

pour chacune des composantes pour lesquelles il y a conflit (lignes 11-15).

Tolerance aux fautes

Rappelons que, contrairement a la strategie uni-maıtre, dans la strategie multi-maıtres, tous

les nœuds sont equivalents du point de vue de la gestion de la coherence. De ce fait, la gestion

de la defaillance d’un nœud se fait de maniere differente. Supposons que le nœud Ni j soit devenu

defaillant. Pour que cette information soit prise en compte, il faut que tous les autres nœuds

soient informes de cette defaillance a l’aide d’un message. Nous supposerons que cette fonction

est assuree par le systeme de gestion du reseau de la grille. A la reception d’un tel message,

chaque nœud devra invalider la case correspondante a ce nœud defaillant dans tous les vecteurs

de versions des repliques qui etaient stockees dans ce nœud.

Insertion d’un nouveau nœud dans un site

Supposons qu’un nouveau nœud Nx soit integre dans un site Si. Deux scenarios sont alors

possibles :

1. Ou bien le nouveau nœud Nx ne contiendra pas de repliques d’un fichier Ok ; dans ce cas,

aucune operation particuliere ne sera realisee vis-a-vis de la gestion de la coherence des

repliques.

60

4.3. Gestion de la coherence inter-sites

2. Ou bien le nœud Nx a ete choisi pour contenir des repliques d’un fichier Ok ; dans ce cas,

les operations suivantes seront declenchees pour preserver la coherence du processus de

gestion des coherences :

(a) Creer une replique p du fichier Ok dans le nœud Nix ;

(b) Creer le vecteur de version associe a cette nouvelle replique, VVkp(i), ainsi que son

ensemble de mises a jour EMAJkp(ix) ;

(c) Mettre a jour les vecteurs de versions des autres repliques au sein du site S i.

4.3 Gestion de la coherence inter-sites

La Figure 4.7 met en evidence les principales etapes du service de gestion de coherence inter-

sites. L’objectif de ces etapes est d’obtenir une coherence globale, qui consiste a faire converger

les repliques d’un fichier Ok, stockees dans differents sites de la grille, vers une replique de

reference globale. Cette coherence inter-sites est inspiree de l’approche pessimiste [4, 50]. Ainsi,

les requetes des clients seront bloquees momentanement, le temps d’effectuer cette coherence

inter-sites. Comme pour les autres coherences traitees ci-dessus, l’instant de declenchement de

St ratégie

Site ?

GRiß Election(Nœudk) GRiß Nœud maître

Diffusion des

méta-données desGRi

Phase de comparaison et mise à

niveau des GR i

Détect ion et résolut iondes conflits

Chaque GRi diffuse ses

nouvelles informat ions aux

rép liques de son site

Exécution en paral lèle

par l’ensemble des

sites

Exécution en paral lèle

par l’ensemble des

sites

Exécution centralis ée

de l’ensemb le des GRi

de la g rille

Uni-maîtreMult i-maîtres

Fig. 4.7 – Principales etapes du service de gestion de coherence inter-sites

la coherence globale peut se faire selon deux strategies : soit par periode, soit par rapport a

61

4.4. Placement de repliques vs gestion de coherence

un taux d’operations d’ecriture predefini. Dans le cadre de notre these, nous avons choisi une

strategie de type periodique.

Les principales etapes du processus de coherence inter-sites sont definies comme suit :

1. Choix des gestionnaires des repliques : Chaque site Si designe un gestionnaire de repliques

pour l’ensemble des repliques d’un meme fichier Ok, stockees dans le site Si, selon la strategie

utilisee :

– Si la strategie utilisee au sein d’un site Si est de type uni-maıtre, alors le gestionnaire

de coherence du site est deja designe ; il correspondant au nœud contenant la replique

maıtresse de l’ensemble des repliques d’un meme fichier Ok (voir section 4.2.2) ;

– Si la strategie utilisee est de type multi-maıtres, alors le choix du gestionnaire des re-

pliques se fait sur la base d’un algorithme d’election (voir section 4.2.3) pour representer

son site ;

2. Diffusion : Chaque gestionnaire des repliques, designe lors de l’etape precedente, diffuse

son vecteur de versions aux autres gestionnaires des repliques du niveau 1 du modele de

gestion de coherence propose dans cette these (voir Chapitre 3) ;

3. Comparaison et mise a niveau : Cette etape peut etre decomposee comme suit :

– Construction d’un vecteur de reference VREF ;

– Detection des convergences, des divergences et des conflits eventuels entre les gestion-

naires des repliques sur la base du vecteur V REF ;

– Resolution des conflits et mise a niveau des gestionnaires des repliques ;

4. Diffusion locale : Cette etape consiste a diffuser les nouvelles informations (vecteur de

versions, ensemble des mises a jour) de chaque gestionnaire des repliques aux repliques

d’un meme fichier Ok stockees dans un site Si.

4.4 Placement de repliques vs gestion de coherence

Le cout d’execution d’une requete d’un client, dans une grille, depend de plusieurs facteurs

tels que [35] : le site a partir duquel est soumise la requete, le type de requete, la replique sur la-

quelle sera executee la requete, sa localisation, la largeur de bande passante, etc. Un des facteurs

qui peut influencer ce cout est le nœud de stockage d’une replique par rapport au site emetteur

d’une requete d’acces a cette replique.

Des etudes [34, 35, 58] ont montre qu’une strategie de placement de repliques peut ameliorer

les temps d’execution des requetes en essayant de reduire la distance entre les requetes et les

repliques.

Pour cela, plusieurs techniques de placement de fichiers ont ete proposees [34, 58]. Parmi ces

techniques, certaines se basent sur la notion de modele economique qui est largement utilise dans

62

4.5. Conclusion

les grilles [9, 35].

L’objectif des modeles economiques est de permettre aux fournisseurs (proprietaires des res-

sources) et aux consommateurs (utilisateurs des ressources) d’atteindre leurs objectifs a savoir

un taux d’utilisation pour les fournisseurs et le rapport qualite/prix pour les consommateurs [9].

Plusieurs modeles inspires du monde d’economie du marche sont utilises dans la gestion de

ressources dans les grilles, parmi lesquels nous pouvons citer [9, 35] :

– Le modele de marche : Dans ce modele, les fournisseurs de ressources fixent un prix, et

les utilisateurs sont factures a ce prix, proportionnellement a la quantite de ressources

consommees ;

– Le modele des negociations : Ce modele permet a l’utilisateur d’agir sur le prix des res-

sources qu’il desire consommer. Ici, les producteurs et les consommateurs auront leurs

propres objectifs, et devront negocier pour les atteindre ;

– Le modele de l’appel d’offres : Ce modele est inspire des mecanismes mis en place dans le

monde des affaires pour gouverner les echanges de biens et de services. Il permet au client

de trouver le fournisseur de service approprie en fonction de ses besoins ;

– Le modele de la vente aux encheres : Ce modele permet d’avoir une negociation entre un

fournisseur et plusieurs consommateurs potentiels, afin d’aboutir a l’etablissement d’un

prix et au choix d’un consommateur ;

– Le modele du partage proportionnel des ressources : Dans ce modele, une ressource peut

etre partagee entre plusieurs utilisateurs. La part de ressource allouee a chaque utilisateur

par rapport aux autres est alors proportionnelle a son offre par rapport a celles des autres

utilisateurs.

Dans le cadre de cette these, nous nous proposons de definir un modele economique pour le

placement de repliques dans les grilles, etant donne l’importance de ce placement dans la gestion

de la coherence de repliques.

Le modele propose est une adaptation du modele de Haddad et Slimani defini dans [35]. Partant

de ce modele, nous avons effectue un certain nombre d’experiences pour montrer l’effet du

placement sur 4 metriques : le temps de d’execution des requetes, le cout de communication,

le nombre de divergences et le nombre de conflits. L’ensemble de ces experimentations seront

presentees et discutees dans le Chapitre 5.

4.5 Conclusion

Dans ce chapitre, nous avons presente les differentes etapes de notre approche de gestion de

coherence de repliques dans le cadre des systemes a grande echelle. L’approche proposee combine

l’approche optimiste et l’approche pessimiste. Grace a cette combinaison, nous avons pu traiter

63

4.5. Conclusion

deux types de coherence complementaires : (i) une coherence a l’interieur des sites d’une grille, ce

qui a l’avantage de declencher plusieurs operations de coherence en parallele, en tenant compte

uniquement des informations locales d’un site. L’avantage majeur de ce type d’approche est

l’absence totale de communication entre sites pour aboutir a une coherence locale de repliques ;

(ii) une coherence globale, dans le cas ou le processus de coherence local echoue. Contrairement

au premier type de coherence, nous avons besoin, dans le cas de la coherence globale, de recourir

aux communications pour resoudre d’eventuels problemes d’incoherence entre repliques. Dans un

but d’ameliorer encore d’avantage notre approche de gestion de coherence, nous avons utilise un

modele economique pour le placement des repliques dans une grille de donnees. Dans le chapitre

suivant, nous allons presenter et discuter les resultats de quelques experimentations que nous

avons realise pour analyser l’efficacite de l’approche de coherence proposee dans cette these.

64

Chapitre 5

Etude experimentale

65

5.1. Introduction

5.1 Introduction

Afin de valider et d’evaluer notre approche de gestion de la coherence de repliques par

rapport aux approches classiques (pessimiste et optimiste), nous avons effectue une serie d’ex-

perimentations dont les resultats et les interpretations font l’objet du present chapitre. Nous

commencerons d’abord par fixer l’environnement dans lequel nous avons realise nos experimen-

tations, par la suite nous definirons les metriques et les notations que nous avons utilise, et enfin

nous discuterons et analyserons les resultats que nous avons obtenu.

5.2 Environnement d’experimentation

L’environnement dans lequel nous avons realise nos differentes experimentations est defini

par les elements suivants :

1. Environnement materiel et logiciel : Pour l’ensemble de nos tests, nous avons utilise un

ensemble de PCs, fonctionnant sous le systeme Windows XP, avec les caracteristiques

suivantes : Intel Centrino Core Duo, 1.73MHZ avec 1Go de RAM et 120Go de disque ;

2. Environnement de developpement : Visual Basic, SQL server.

3. Simulateur : Nous avons utilise le simulateur RepSim Version 1.0 (voir interface schematisee

par la Figure 5.1), qui est une adaptation d’un simulateur de grilles developpe par l’equipe

du Professeur Y. Slimani du Departement des Sciences de l’Informatique de la Faculte des

Sciences de Tunis ;

4. Nombre d’experimentations : Pour chaque serie d’experimentations, et afin d’obtenir des

resultats viables, nous avons repete chaque experience 11 fois, puis nous avons pris la

moyenne des resultats obtenus.

66

5.3. Metriques utilisees

Fig. 5.1 – Interface du simulateur RepSim

5.3 Metriques utilisees

Afin d’analyser les resultats relatifs a l’experimentation de notre approche, nous avons utilise

quatre metriques a savoir le temps de reponse (TR), le cout de communication (CC), le nombre de

divergences (ND) et le nombre de conflits (NC) entre repliques. Ces metriques ont ete utilisees

pour evaluer notre approche par rapport aux approches optimistes et pessimistes selon deux

strategies : l’une qui utilise un placement initial des repliques et l’autre qui n’utilise aucune

strategie de placement des repliques (placement aleatoire).

1. Temps de reponse : Cette metrique permet de mesurer le temps de reponse relatif a l’exe-

cution d’une requete ;

2. Cout de communication : Cette metrique est interessante pour evaluer le cout de recherche

d’une replique d’un fichier stockee dans un nœud d’un site donne ;

3. Nombre de divergences : Nous rappelons que deux repliques d’un meme fichier sont dites

divergentes si leurs numeros de versions sont differents par une et une seule composante.

A l’aide de cette metrique, nous essayons de monter la dispersion des repliques d’un meme

fichier a un moment donne sur la grille ;

4. Nombre de conflits : Un des problemes majeurs, rencontre dans la phase de propagation

des mises a jour, concerne la detection de conflits. Controler et resoudre ce phenomene est

essentiel pour la gestion de coherence.

67

5.3. Metriques utilisees

5.3.1 Notations

Dans le reste de ce chapitre, nous allons utiliser un certain nombre de notations que nous

avons resume dans le tableau 5.1.

Notation Signification

SSP Sans Strategie de Placement

ASP Avec Strategie de Placement

AP Approche Proposee

OP Approche Optimiste

PE Approche Pessimiste

TR Temps de Reponse

CC Cout de Communication

NC Nombre de Conflits

ND Nombre de Divergences

Tab. 5.1 – Notations utilisees

5.3.2 Parametres de simulation

Pour effectuer les differentes experimentations de notre approche, nous avons fixe un certain

nombre de parametres de simulation dont les valeurs sont definies dans le tableau 5.2. Ces

parametres sont communs a l’ensemble des simulations.

Parametres de simulation Intervalle

#Sites (Clusters) [1..10]

#Nœuds 50

#(EC,ES) [1..1000]

Largeur de la bande passante inter-sites [100..1000] Mb/s

Largeur de le bande passante intra-site [100..1000] Mb/s

#Fichiers [100..800]

#Taille des fichiers [100..100000]MB

#Repliques [1..1000]

#Requetes [20..100]

Degre d’importance d’une requete [1..10]

Tab. 5.2 – Parametres de simulation

68

5.4. Resultats experimentaux

Notons que pour toutes nos experimentations dans le cas inter-sites, le choix de la largeur

de la bande passante est calcule d’une maniere aleatoire entre les valeurs 100Mb/s et 1000Mb/s.

Pour la cas intra-site, nous avons fait varier cette largeur de 100Mb/s a 1000Mb/s par pas de

100.

5.4 Resultats experimentaux

Dans cette section nous allons presente les resultats des differentes experimentations que

nous avons effectue sur le simulateur RepSim.

5.4.1 Experience 1 : Impact du nombre de requetes

Dans cette premiere serie d’experiences, nous avons voulu mesurer l’impact du nombre de

requetes sur les differentes metriques definies dans la section 5.3.

Ces experimentations ont ete realisees avec les parametres de simulation suivants : 1 site,

50 nœuds, 10 fichiers et 10 repliques par fichier. En ce qui concerne les requetes, nous avons

considere un nombre de requetes allant de 20 a 100 par pas 20, avec un taux de 70% de requetes

de lecture et 30% de requetes d’ecriture. Les resultats de ces experimentations sont synthetises

dans les tableaux 5.3, 5.4, 5.5, 5.6 et 5.7 et les figures qui leur sont respectivement associees.

#Requetes SSP ASP

AP OP PE AP OP PE

20 94 94 96 75 74 76

40 144 137 147 131 124 134

60 468 444 473 440 416 445

80 1384 1249 1390 1240 1195 1334

100 2153 1665 2163 2019 1605 2026

Moyenne 848.6 717.8 853.8 781 682.8 803

Tab. 5.3 – Variation du temps de reponse/#Requetes

Effets sur le temps de reponse : L’analyse des resultats du tableau 5.3 montre que les

trois approches evoluent avec des valeurs voisines, avec ou sans placement initial de repliques.

Toutefois, l’approche hybride apporte une legere amelioration par rapport a l’approche pessimiste

lorsque l’on compare les moyennes des temps de reponse (848.6 contre 853.8 et 781 contre 805).

En ce qui concerne l’utilisation d’une strategie de placement des repliques, le tableau 5.3 (colonne

69


ASP) montre une diminution du temps de reponse et ce pour les 3 approches. Ceci montre que

le placement a des incidences positives sur le temps de reponse.

Fig. 5.2 – Variation du temps de re-

ponse/#Requetes pour la strategie SSP


ponse/#Requetes pour la strategie ASP

Les deux Figures 5.2 et 5.3 montrent que les courbes associees aux approches hybride (couleur

bleue) et pessimiste (couleur jaune) sont confondues jusqu’a un nombre de requetes egal a 80.

Au dela de ce nombre, les performances de l’approche optimiste sont meilleures que celles des

deux autres approches. Ceci se justifie par le fait que cette approche ne bloque pas les requetes

d’ecriture, ce qui a pour effet de reduire le temps d’execution d’une requete.

Effets sur le cout de communication : En utilisant les memes parametres de simulation,

le tableau 5.4 donne la variation du cout de communication pour les 3 approches (AP, OP et

PE) et ce pour les deux strategies de placement (SSP et ASP).

Ce tableau montre que la strategie ASP apporte des ameliorations plus ou moins importantes

selon le nombre de requetes.

#Requetes SSP ASP

AP OP PE AP OP PE

20 29 29 29 14 14 14

40 22 22 22 16 16 16

60 28 28 28 21 21 21

80 31 31 31 28 27 27

100 30 30 30 27 27 27

Tab. 5.4 – Variation du cout de communication/#Requetes

70


Dans le tableau 5.5, nous nous sommes interesses specifiquement au cout de communication

relatif a notre approche, selon que l’on utilise ou pas une strategie de placement initial des

repliques. Ainsi, nous comparons le cout de communication, selon les deux strategies, en faisant

varier le nombre de requetes. A travers cette comparaison, nous avons essaye de mettre en

valeur le gain obtenu par l’utilisation d’une strategie de placement des repliques. La lecture

de ce tableau montre que la strategie de placement a permis de reduire, parfois de maniere

tres sensible (52%), les couts de communication. L’analyse de cette reduction montre que le gain

apporte par les replications est une fonction decroissante du nombre de requetes. La contribution

de la strategie de placement a tendance a se reduire au fur et a mesure que le nombre de requetes

augmente.

#Requetes SSP ASP Gain %

20 29 14 52%

40 22 16 27%

60 28 21 25%

80 31 28 10%

100 30 27 10%

Tab. 5.5 – Variation du cout de communication pour l’approche proposee

La Figure 5.4 met en evidence l’apport du placement quant a la reduction du cout de com-

munication lors de l’execution de requetes.

Fig. 5.4 – Courbe de variation du cout de communication relative au tableau 5.5

Effets sur le nombre de divergences : Le tableau 5.6 illustre l’evolution du nombre de

divergences en fonction du nombre de requetes pour les approches optimiste et hybride, avec et

71


sans placement de repliques. Nous remarquons ici une tres nette diminution du nombre de diver-

gences pour l’approche hybride comparativement a l’approche optimiste (facteur de reduction

de 2.5). Toutefois, il est a remarquer que la strategie de placement n’a pas permis de diminuer

le nombre de divergences.

#Requetes SSP ASP

AP OP AP OP

20 1 5 1 4

40 14 51 15 49

60 34 102 34 100

80 79 204 81 208

100 184 423 187 418

Moyenne 62.4 157 63.6 155.8

Tab. 5.6 – Variation du nombre de divergences/#Requetes

Effets sur le nombre de conflits : Dans le tableau 5.7, nous nous sommes interesses a

l’evolution du nombre de conflits par rapport au nombre de requetes, selon que l’on utilise

ou pas une strategie de placement initial des repliques. L’analyse des resultats contenus dans

ce tableau montre une diminution significative du nombre de conflits avec l’approche hybride.

Quand nous comparons les moyennes du nombre de conflits entre l’approche optimiste et celle

que nous proposons, nous relevons que cette derniere permet d’avoir une amelioration avec

rapport qui avoisine la valeur 4. signalons egalement que les approches hybride et optimiste ont

un comportement identique pour un nombre de requetes inferieur ou egal a 40. Comme pour le

cas des divergences, nous notons le fait que la strategie de placement n’a pas d’incidence positive

sur le nombre de conflits.

#Requetes SSP ASP

AP OP AP OP

20 0 0 0 0

40 0 14 0 13

60 3 31 3 33

80 18 87 20 88

100 68 212 59 207

Moyenne 17.8 68.8 16.4 68.2

Tab. 5.7 – Variation du nombre de conflits/#Requetes

72


5.4.2 Experience 2 : Impact du type de requetes

Dans la section 5.4.1, nous avons etudie l’impact du nombre de requetes sur les metriques

definies dans la section 5.3, dans le cas ou les requetes de lecture etaient dominantes par rapport

a celles d’ecriture. Dans cette deuxieme serie d’experiences, nous avons voulu tester l’impact

du type de requetes en considerant un taux de requetes d’ecriture superieur a celui de lecture

(20% de lecture et 80% d’ecriture). Pour cela, nous avons utilise les parametres de simulation

suivants : 1 site, 50 nœuds, 10 fichiers et 10 repliques par fichier. En ce qui concerne les requetes,

nous avons considere un nombre de requetes allant de 20 a 100 par pas 20. Les resultats de ces

experimentations sont illustres dans les tableaux et les figures ci-dessous.

Effets sur le temps de reponse : L’analyse des resultats du tableau 5.8 montre que les trois

approches evoluent avec des valeurs voisines, avec ou sans strategie de placement. Toutefois,

l’approche hybride donne des resultats qui sont au meme niveau que les autres approches et

notamment l’optimiste.

#Requetes SSP ASP

AP OP PE AP OP PE

20 39 39 39 22 22 22

40 44 44 45 25 24 26

60 40 40 42 25 24 26

80 50 48 52 28 27 31

100 47 46 50 29 27 32

Tab. 5.8 – Variation du temps de reponse/#Requetes

Les Figures 5.5 et 5.6 montrent que les courbes sont quasiment confondues et que les trois

approches se comportent de maniere identique. Nous pouvons aussi remarquer une legere baisse

du temps de reponse pour les experiences avec 80 requetes avec et sans placement.

73



ponse/#Requetes pour la strategie SSP


ponse/#Requetes pour la strategie ASP

Effets sur le cout de communication : L’analyse des resultats des couts de communication

(voir tableau 5.9) montre que les trois approches ont eu le meme cout de communication selon le

type de de strategie. Cependant, l’utilisation d’une strategie de placement permet d’obtenir une

reduction sensible de ce cout, voire de le rendre nul. Nous avons pu remarquer egalement que le

cout de communication est presque negligeable malgre le taux eleve des requetes d’ecriture.

#Requetes SSP ASP

AP OP PE AP OP PE

20 16 16 16 0 0 0

40 18 18 18 0 0 0

60 15 15 15 0 0 0

80 21 21 21 1 1 1

100 18 18 18 1 1 1

Tab. 5.9 – Variation du cout de communication/#Requetes

74


Effets sur le nombre de divergences : Les experiences relatives au nombre de divergences

en fonction du nombre de requetes sont resumees dans le tableau 5.10. Les valeurs contenues

dans ce tableau mettent en evidence une diminution significative du nombre de conflits avec

l’approche hybride. Nous obtenons une amelioration d’un facteur qui depasse la valeur 4, par

rapport a l’approche optimiste. Notons toutefois que l’utilisation d’une strategie de placement

n’apporte pas de reduction significative du nombre de divergences.

#Requetes SSP ASP

AP OP AP OP

20 0 0 0 0

40 0 9 0 8

60 3 25 3 26

80 15 64 15 63

100 30 113 30 110

Moyenne 9.6 42.2 9.6 41.4

Tab. 5.10 – Variation du nombre de divergences/#Requetes

La Figure 5.7, qui est une illustration graphique du tableau 5.10, montre l’apport de l’ap-

proche hybride par rapport au nombre de divergences. Elle montre egalement l’absence d’effet

du placement sur ce nombre (les courbes jaune et noire sont confondues). A partir de 40 re-

quetes, nous constatons une evolution differente des courbes relatives aux approches optimiste

et hybride, avec un avantage tres sensible a l’approche hybride.

Fig. 5.7 – Variation du nombre de divergences/#Requetes

75


Effets sur le nombre de conflits : Dans le tableau 5.11, nous nous interessons a l’evolution

du nombre de conflits en fonction de la variation du nombre de requetes. La lecture des valeurs

de ce tableau permet de constater que l’approche hybride a pu diminuer de maniere substan-

tielle le nombre de conflits. Quand nous comparons les valeurs des differentes approches, nous

remarquons que notre approche permet d’obtenir un facteur d’amelioration qui depasse 12.5 en

moyenne pour les strategies SSP et ASP. Comme dans le cas de la metrique relative au nombre

de divergences, nous notons que la strategie de placement n’a pas d’effets tres significatifs sur le

nombre de conflits malgre que ce nombre a ete reduit parfois a 0.

#Requetes SSP ASP

AP OP AP OP

20 0 0 0 0

40 0 0 0 0

60 0 8 0 8

80 1 23 0 24

100 4 44 6 45

Tab. 5.11 – Variation du nombre de conflits/#Requetes

La Figure 5.8 est une representation schematique de l’evolution du nombre de conflits, dont

les valeurs sont resumees dans le tableau 5.11. Cette figure illustre clairement les remarques que

nous avons faites au sujet de tableau 5.11.

Fig. 5.8 – Variation du nombre de conflits/#Requetes

76


5.4.3 Experience 3 : Impact du nombre de fichiers

Pour cette troisieme serie d’experiences, nous nous interessons a l’evaluation de notre ap-

proche par rapport a la variation du nombre de fichiers et du nombre de repliques. L’evaluation

portera sur les differentes metriques definies dans la section 5.3 et avec les parametres de simu-

lation suivants : 1 site, 50 nœuds, 50 requetes avec un taux de 50% de requetes de lecture et

50% de requetes d’ecriture. Nous avons fait varier le nombre de fichiers de 100 a 800 par pas de

100. Notons aussi que nous avons choisi comme nombre de repliques, la moitie du nombre de

fichiers. Les resultats de ces experimentations sont synthetises dans les tableaux 5.12, 5.13, 5.14

et 5.15.

Effets sur le temps de reponse : Une analyse des valeurs du tableau 5.12 montre les

ameliorations obtenues grace a l’utilisation d’une strategie de placement. Par rapport a cette

metrique, les differentes approches peuvent etre classees par ordre decroissant, du point de vue

performance, comme suit : approche optimiste, approche hybride et l’approche pessimiste. Si

nous nous interessons a notre approche, nous pouvons noter que l’utilisation d’une strategie de

placement ameliore considerablement le temps de reponse. Ceci confirme l’hypothese qu’un bon

placement peut contribuer a l’amelioration des temps d’execution des requetes.

Les Figures 5.9 et 5.10 permettent de constater que la courbe de l’approche hybride (couleur

bleue) se positionne entre les courbes des approches pessimistes et optimistes, dans le cas des deux

strategies (avec et sans placement). Nous remarquons egalement que l’evolution des approches

sans placement se fait en deux paliers : le premier se situe entre 100 et 400 fichiers, alors que le

deuxieme se situe entre 500 et 700 fichiers. Nous avons aussi releve que dans la plage de 600-700

fichiers, la strategie sans placement tend a reduire le temps de reponse. Ceci peut s’expliquer par

le fait que les repliques sont assez proches des sites qui ont emis des requetes et ce de maniere

tout a fait aleatoire.

77


#Fichiers SSP ASP

AP OP PE AP OP PE

100 440 356 526 324 239 409

200 1328 877 1791 1010 558 1485

300 2020 1105 2939 1593 683 2518

400 3073 1403 4747 2651 928 4276

500 5858 2231 8075 4590 1366 7821

600 6787 3417 10192 4776 1339 8156

700 5931 1727 10218 5494 1292 9933

800 11535 3458 19697 10366 2304 18581

Moyenne 4621.5 1821.75 7273.12 3850.5 1088.62 6647.37

Tab. 5.12 – Variation du temps de reponse/#Fichiers


ponse/#Fichiers pour la strategie SSP


ponse/#Fichiers pour la strategie ASP

Effets sur le cout de communication : Le tableau 5.13 resume les resultats relatifs a

l’evolution du cout de communication de notre approche, selon que l’on utilise ou pas une

strategie de placement de repliques. La lecture des valeurs contenues dans ce tableau illustre

clairement la diminution du cout de communication quand notre approche utilise une strategie de

placement. Ainsi, la contribution de la replication dans la diminution des couts de communication

est tres significative, puisque le gain minimal obtenu est de 79%. Ceci peut s’expliquer par le fait

que la strategie de placement a contribue, dans une certaine mesure, a rapprocher les repliques

des requetes des clients (memes nœuds ou nœuds avoisinants).

78


#Fichiers SSP ASP Gain %

100 132 28 79%

200 367 46 87%

300 474 52 89%

400 475 2 100%

500 1343 81 94%

600 2119 129 94%

700 448 13 97%

800 1153 0 100%

Tab. 5.13 – Evolution du cout de communication pour l’approche hybride

Les resultats du tableau 5.13 sont schematises dans la Figure 5.11, qui illustre, de maniere

beaucoup plus claire, la diminution du cout de communication, quand nous utilisons une strategie

de placement de repliques.

Fig. 5.11 – Variation du cout de communication/#Fichiers pour l’approche hybride

Effets sur le nombre de divergences : A travers cette experience, notre objectif etait de

voir comment l’augmentation du nombre de fichiers (et du nombre de repliques) pouvait avoir

un effet sur la metrique relative au nombre de divergences. Les resultats que nous avons obtenu,

et qui sont synthetises dans le tableau 5.14, montrent une tres nette diminution du nombre de

divergences avec l’approche hybride. La comparaison des moyennes du nombre de divergences,

obtenues avec les approches optimiste et hybride, revele une amelioration de l’approche hybride

avec un facteur de 2, que l’on utilise ou pas une strategie de placement. Nous pouvons toutefois

signaler que l’utilisation d’une strategie de placement n’est pas tres fructueuse, du moins pour

cette metrique.

79


#Fichiers SSP ASP

AP OP AP OP

100 1226 2654 1231 2712

200 7276 14830 7157 15129

300 14549 29713 14674 29982

400 26331 55261 27777 54992

500 52142 96923 52366 108026

600 56483 114692 54875 111603

700 70404 141635 69272 141359

800 133242 270390 133841 269959

Moyenne 45206.62 90762.25 45149.12 91720.25

Tab. 5.14 – Variation du nombre de divergences/#Fichiers

Fig. 5.12 – Variation du nombre de diver-

gences/#Fichiers pour la strategie SSP

Fig. 5.13 – Variation du nombre de diver-

gences/#Fichiers pour la strategie ASP

Effets sur le nombre de conflits : Rappelons que cette metrique permet de renseigner sur le

degre de coherence entre les repliques d’un fichier. Dans le cas d’un conflit, ceci veut dire qu’une

ou plusieurs repliques presentent au moins deux differences entre leurs contenus et celui d’une

replique de reference. Plus ce nombre est grand, plus la resolution des conflits sera couteuse.

Pour cela, nous avons voulu etudier la variation de cette metrique en fonction du nombre de

fichiers. Le tableau 5.15 resume cette variation pour les approches optimiste et hybride, dans

le cas de l’utilisation ou non d’une strategie de placement. L’analyse de cette variation montre

une diminution significative du nombre de conflits, quand nous utilisons l’approche hybride

(amelioration avec un facteur qui depasse la valeur 2). Par contre, nous pouvons remarquer que

80


la strategie de placement a fait augmenter le nombre de conflits.

#Fichiers SSP ASP

AP OP AP OP

100 638 1516 642 1534

200 4122 8696 4015 8733

300 8343 17514 8289 17730

400 15636 32128 15781 32307

500 30829 57346 31120 62967

600 31983 66712 32712 67817

700 40945 83006 41023 82324

800 79230 159634 80313 157544

Moyenne 26465.75 53319 26736.87 53869.5

Tab. 5.15 – Variation du nombre de conflits/#Fichiers

Fig. 5.14 – Variation du nombre de

conflits/#Fichiers pour la strategie SSP

Fig. 5.15 – Variation du nombre de

conflits/#Fichiers pour la strategie ASP

5.4.4 Experience 4 : Impact de la largeur de la bande passante

Dans cette quatrieme serie d’experimentation, nous nous sommes interesses a l’impact de la

largeur de la bande passante sur les differentes metriques que nous avons defini. Pour effectuer

cette serie d’experiences, nous avons utilise les parametres de simulation suivants : 1 site, 50

nœuds, 50 requetes, 10 fichiers et 10 repliques par fichier. En ce qui concerne la bande passante,

nous avons considere des bandes passantes allant de 100 a 1000Mb/s par pas 100Mb/s ; pour

les requetes, nous avons pris comme hypothese un taux de 70% de requetes de lecture et 30%

81


de requetes d’ecriture. Les tableaux 5.16, 5.17, 5.18 et 5.19 ainsi que les figures correspondantes

synthetisent l’ensemble des resultats de cette serie d’experimentations.

Effets sur le temps de reponse : L’analyse du tableau 5.16 montre que l’approche hybride

apporte une amelioration significative par rapport a l’approche pessimiste. Quand nous nous

interessons uniquement l’approche hybride, nous constatons que l’utilisation d’une strategie de

placement permet d’avoir une amelioration constante du temps de reponse (voir colonne contri-

bution du tableau 5.16), avec un taux qui est de l’ordre de 20%. Comme pour toutes experiences

relatives au temps de reponse, nous relevons le fait que l’utilisation d’une strategie de placement

permet de reduire ce temps.

#Bande Passante (Mb/s) SSP ASP

AP OP PE AP OP PE Contribution

100 1859 911 3540 1500 502 2556 19.31%

200 1572 778 3010 1264 427 2159 19.59%

300 1299 649 2498 1040 355 1781 19.94%

400 1108 559 2136 885 306 1516 20.13%

500 967 491 1867 771 269 1321 20.27%

600 858 439 1659 684 241 1171 20.28%

700 773 397 1493 615 218 1053 20.44%

800 703 364 1358 559 200 956 20.48%

900 645 335 1242 513 185 876 20.47%

1000 596 311 1151 474 172 809 20.47%

Moyenne 10380 5234 19954 8305 2875 14198 19.99%

Tab. 5.16 – Variation du temps de reponse en fonction de la largeur de la bande passante

Les Figures 5.16 et 5.17 illustrent l’evolution du temps de reponse en fonction de la variation

de la largeur de la bande passante. Dans ces deux figures, nous notons que la courbe relative a

notre approche (couleur bleue) se situe toujours entre celles des approches optimiste et pessi-

miste. Nous pouvons egalement remarquer que plus la largeur de la bande passante augmente

plus le temps de reponse diminue, avec une tendance a la stabilisation a partir d’une largeur de

bande passante egale a 700 pour les approches sans placement et a partir de 600 pour celles avec

placement.

82


Fig. 5.16 – Variation du temps de reponse en

fonction de la largeur de la bande passante

pour la strategie SSP

Fig. 5.17 – Variation du temps de reponse en

fonction de la largeur de la bande passante

pour la strategie ASP

Effets sur le cout de communication : Le tableau 5.17 montre l’effet de la variation de

taille de la bande passante sur l’evolution du cout de communication pour les trois approches

avec et sans placement. Nous remarquons que l’approche hybride permet de diminuer le cout

de communication selon que l’on utilise ou pas une strategie de placement. La contribution la

plus significative se voit a travers l’uilisation d’une strategie de placement. La gain entre les

approches avec et sans placement est de l’ordre de 10.


AP OP PE AP OP PE

100 359 372 372 23 23 23

200 303 317 317 20 19 19

300 250 263 263 16 16 16

400 213 225 225 14 14 14

500 186 197 197 12 12 12

600 165 175 175 11 10 10

700 149 158 158 10 9 9

800 135 144 144 9 9 9

900 124 132 132 8 8 8

1000 115 122 122 7 7 7

Tab. 5.17 – Variation du cout de communication en fonction de la largeur de la bande passante

83


Effets sur le nombre de divergences : Le tableau 5.18 presente l’evolution du nombre

de divergences en fonction de la variation du nombre de requetes, pour les approches hybride

et optimiste, avec utilisation ou non d’une strategie de placement. A ce niveau, nous avons

remarque une reduction du taux de divergence, notamment dans le cas de notre approche qui

donne un facteur de 2.5 quand on n’utilise pas de strategie de placement et un facteur de 2 dans

le cas contraire.


AP OP AP OP

100 16484 43496 16350 33734

200 13898 36933 13734 28444

300 11433 30587 11257 23400

400 9710 26103 9537 19876

500 8438 22765 8273 17275

600 7461 20185 7305 15276

700 6687 18130 6540 13692

800 6058 16456 5920 12406

900 5538 15064 5407 11340

1000 5099 13890 4976 10444

Tab. 5.18 – Variation du nombre de divergences en fonction de la largeur de la bande passante

Effets sur le nombre de conflits : En ce qui concerne la metrique relative au nombre de

conflits (voir tableau 5.19), nous constatons que l’approche hybride a permis de diminuer le

nombre de conflits. La comparaison des valeurs ainsi que des moyennes du nombre de conflits

montre une amelioration avec un facteur de 2.5 et 2, respectivement pour les strategies sans

placement et avec placement. Toutefois, la contribution du placement pour l’approche hybride

n’est pas tres importante.

La Figure 5.18 illustre, de maniere graphique, les remarques que nous avons faites lors de

l’analyse du tableau 5.19. Toutefois les courbes associees a l’approche hybride (couleurs bleu et

jaune) sont clairement au dessous de celles relatives a l’approche optimiste.

En conclusion de cette quatrieme serie d’experiences, nous pouvons dire que :

– L’approche optimiste donne de meilleurs resultats que les autres approches du point de vue

temps de reponse. Ceci s’explique aisement par le fait que l’approche optimiste ne bloque

pas les requetes lors de l’execution alors que les autres approches creent un overhead du

precisement au blocage ;

84



AP OP AP OP

100 9702 25558 9592 19925

200 8180 21701 8057 16799

300 6728 17971 6604 13819

400 5714 15335 5595 11737

500 4966 13374 4854 10200

600 4391 11858 4286 9019

700 3935 10650 3837 8084

800 3565 9666 3473 7324

900 3259 8848 3172 6694

1000 3001 8158 2919 6165

Moyenne 5344.1 14311.9 5238.9 10976.6

Tab. 5.19 – Variation du nombre de conflits en fonction de la largeur de la bande passante

Fig. 5.18 – Variation du nombre de conflits en fonction de la largeur de la bande passante

– Pour les metriques cout de communication, nombre de divergences et nombre de conflits,

notre approche s’avere etre la plus performante.

5.4.5 Experience 5 : Impact du nombre de clusters

La derniere serie d’experiences sera consacree a l’evaluation de l’impact du nombre de clusters

sur les metriques que nous avons defini dans la section 5.3. Pour cela, nous avons utilise les

parametres de simulation suivants : 50 nœuds, 50 requetes, une bande passante de 100Mb/s,

10 fichiers et 10 repliques par fichier. En ce qui concerne les clusters, nous avons considere un

85


nombre de clusters allant de 2 a 10 par pas 2. Pour les requetes, nous avons utilise un taux de

50% de requetes de lecture et 50% de requetes d’ecriture. Les resultats de ces experimentations

sont synthetises dans les tableaux 5.20, 5.21, 5.22 et 5.23 avec leurs figures associees.

Effets sur le temps de reponse : L’etude du tableau 5.20 montre que le temps de reponse

se situe entre 117 et 157 si la strategie est sans placement et entre 92 et 118 si la strategie est

avec placement, ce qui donne un ecart de 40 pour SSP et de 20 pour ASP et ceci quelque soit

le nombre de clusters mis en jeu, ce qui temoigne de la robustesse de l’approche proposee vis a

vis du critere de scalabilite (passage a l’echelle).

#Clusters SSP ASP

AP OP PE AP OP PE

2 131 124 139 100 93 108

4 147 140 156 107 101 116

6 143 135 151 109 102 118

8 124 117 132 99 92 107

10 150 143 157 104 98 111

Tab. 5.20 – Variation du temps de reponse/#Clusters

Les Figures 5.19 et 5.20 sont une illustration graphique du tableau 5.20.


ponse/#Clusters pour la strategie SSP


ponse/#Clusters pour la strategie ASP

86


Effets sur le cout de communication : Le tableau 5.21 resume l’effet de l’augmentation

du nombre de clusters sur le cout de communication. Dans ce tableau, nous avons remarque

une uniformite des valeurs pour les strategies avec et sans placement. Ces resultats confirment

encore une fois le gain qui peut etre obtenu lorsque nous utilisons une strategie de placement de

repliques (gain avec un facteur qui avoisine la valeur 3).

#Clusters SSP ASP

AP OP PE AP OP PE

2 39 39 39 14 14 14

4 47 47 47 15 15 15

6 41 41 41 14 14 14

8 32 32 32 11 11 11

10 59 59 59 22 22 22

Tab. 5.21 – Variation du cout de communication/#Clusters

Effets sur le nombre de divergences : Le tableau 5.22 ainsi que la Figure 5.21 montrent,

de maniere evidente, la superiorite de notre approche par rapport a l’approche optimiste en ce

qui concerne le nombre de divergences, que l’on utilise ou pas une strategie de placement.

#Clusters SSP ASP

AP OP AP OP

2 72 207 76 210

4 70 207 73 202

6 79 219 80 220

8 72 193 69 185

10 60 182 66 184

Tab. 5.22 – Variation du nombre de divergences/#Clusters

87


Fig. 5.21 – Variation du nombre de divergences/#Clusters

Effets sur le nombre de conflits : Comme dans le cas du nombre de divergences, nous

avons constate que l’augmentation du nombre de clusters avait un effet positif sur le nombre de

conflits. Par ailleurs, notre approche donne des resultats qui sont tres largement superieurs a

l’approche optimiste (voir tableau 5.23 et Figure 5.22).

#Clusters SSP ASP

AP OP AP OP

2 22 95 23 96

4 20 92 21 93

6 23 103 26 98

8 20 85 18 85

10 19 86 20 83

Tab. 5.23 – Variation du nombre de conflits/#Clusters

Fig. 5.22 – Variation du nombre de conflits/#Clusters

88

5.5. Conclusion

5.5 Conclusion

Dans ce chapitre, nous avons presente et analyse un certain nombre d’experimentations pour

d’une part, mettre en evidence la faisabilite de notre approche, et comparer ses performances

avec les autres approches, d’autre part. L’analyse des resultats obtenus, nous a permis de relever

deux points qui nous semblent tres importants : (i) le premier est que notre approche apporte

des gains substantiels en ce qui concerne les metriques d’evaluation que nous avons defini ; ceci

confirme que le choix de rendre hybride notre approche etait un choix judicieux ; (ii) le deuxieme

element est que l’utilisation d’une strategie de placement contribue, dans beaucoup de cas, a

ameliorer les performances des differentes approches que nous avons teste et notamment dans le

cas de notre approche.

89

Conclusion generale et perspectives

90

Bilan

Les acces aux donnees, dans les systemes a large echelle telles que les grilles de donnees,

posent des problemes de performance et de qualite de service, qui sont essentiellement dus a la

complexite inherente a ces systemes, comme par exemple les larges distances entre sites d’une

grille, la masse importante de donnees, la forte dynamicite des ressources et leur heterogeneite.

L’utilisation de techniques de replication de donnees permet de mettre en place des solutions,

avec plus ou moins d’efficacite, a certains de ces problemes. Ainsi, la replication peut contribuer

a reduire la latence, a tolerer des fautes et a ameliorer les performances. Cependant, malgre les

benefices qu’elle peut procurer, la replication pose de nombreux problemes quant a sa mise en

oeuvre : placement, recherche et acces aux repliques, gestion de la coherence, etc.

Plusieurs travaux de recherches ont essaye de proposer des solutions pour ces problemes

[11, 13, 14, 15, 18, 21, 31, 32, 58]. Par exemple, pour le maintien de la coherence des repliques,

un certain nombre d’approches de gestion de la coherence ont ete proposees [?, 13, 14]. Ces

approches peuvent se diviser en deux grandes familles : la famille des approches optimistes et la

famille des approches pessimistes. Une etude synthetique et detaillee de ces deux familles nous a

permis de mettre en evidence leurs benefices et leurs limites dans le cadre des systemes a grande

echelle.

A partir de ces limites, nous nous sommes fixes comme objectif de proposer un modele de

gestion de la coherence de repliques pour les systemes a large echelle. Ce modele devrait avoir

deux caracteristiques principales : ameliorer les performances et obtenir une bonne qualite de

service [6, 44]. La question du compromis entre qualite de service et performances a fait l’ob-

jet de nombreux travaux. Certains privilegient les performances sur la qualite en optimisant le

temps de reponse, mais sans offrir de garantie sur la qualite des copies accedees [30]. D’autres

controlent la qualite, mais au detriment de la performance [36, 44].

En ce qui nous concerne, nous avons tente, a travers cette these, de chercher un equilibre entre

la performance et la qualite de service. Ceci nous a conduit a proposer une approche de gestion

de coherence hybride, qui vise a ameliorer les performances des acces a des donnees repliquees,

tout en maintenant une certaine qualite de services (reduction des divergences et des conflits).

En plus de ces deux facteurs, notre proposition reduit les couts de communication inter-sites en

privilegiant une coherence locale au sein d’un meme site. L’approche proposee s’articule autour

d’un modele hierarchique et distribue qui permet a la fois d’assurer une coherence verticale

(coherence locale pour chaque site d’une grille) et une coherence horizontale (coherence au niveau

91

de toute la grille). A partir de ce modele, nous avons defini une algorithmique de gestion de la

coherence que nous avons evalue a travers un certain nombre d’experimentations. Les resultats

de ces experimentations sont assez encourageants et ont montre que l’objectif de compromis

entre qualite de service et performance a ete atteint.

En plus, l’utilisation d’un modele economique, pour le placement des repliques, nous a permis

d’ameliorer d’avantage notre approche par rapport a plusieurs parametres, tels que le cout de

communication, le temps de reponse et le nombre de conflits entre contenus de repliques.

Perspectives

Les travaux de recherche que nous avons mene dans le cadre de la problematique de la gestion

de la coherence de repliques de donnees dans les systemes a large echelle, ainsi que les resultats

que nous avons obtenu ont montre que nos propositions ont permis d’obtenir effectivement des

resultats meilleurs que ceux des approches existantes. Neanmoins, un certain nombre de pistes

de recherche sont envisageables pour poursuivre ces travaux. Parmi ces pistes de recherche, nous

pouvons mentionner ce qui suit :

– Validation sur des simulateurs : Comme perspective a tres court terme, nous nous pro-

posons d’experimenter notre approche sur un simulateur de grille, tel que OptorSim [11].

Les etudes qui ont ete menees dans [5], montrent que le simulateur OptorSim est tres bien

adapte pour supporter notre approche ;

– Developpement d’un service web pour la gestion de la coherence de repliques : Nous nous

proposons d’integrer notre approche sous forme de service web dans l’environnement Glo-

bus en utilisant la technologie WSDL [27] ;

– Mise en place d’un annuaire des repliques : Cet annuaire correspondrait, dans un certain

sens, au fichier profile d’une base de donnees. Les informations de cet annuaire seront

ensuite analysees, a l’aide de techniques de datamining, pour fournir des connaissances

sur les repliques : repliques les plus utilisees, correlation entre repliques, taux d’acces a ces

repliques, etc. Ces differentes connaissances pourraient servir de criteres de placement des

repliques pour ameliorer encore plus les couts de traitement des repliques ;

– Placement de repliques : Dans la version actuelle, notre approche utilise un placement

initial (statique) qui a permis d’ameliorer les performances d’acces aux repliques et de

reduire les problemes de divergences et de conflits entre repliques. Il nous semble interessant

d’etudier la possibilite de faire un placement dynamique en fonction de l’evolution des

repliques dans une grille ;

– Equilibrage de charge : Dans cette perspective, et dans un but d’ameliorer encore plus les

performances et la qualite de service de notre approche, nous proposons de l’etendre par un

service d’equilibrage de charge [59], qui permet d’equilibrer les requetes sur les differents

92

sites d’une grille.

– Resolution des divergences et des conflits : A l’etat actuel de sa definition, notre approche

se limite a compter le nombre de divergences et de conflits entre repliques, sans s’interesser

a leur complexite. Il est en effet possible, qu’un petit nombre de divergences ou de conflits

peut neanmoins engendrer un cout de resolution eleve, alors qu’au contraire un grand

nombre de conflits ou de divergences peut ne pas etre complexe a resoudre au niveau

pratique. Il nous semble donc interessant d’etudier, en plus de ce nombre, la complexite

de resolution de ces divergences ou de ces conflits.

93

Bibliographie

[1] W. E. Allcock, J. Bester, J. Bresnahan, A. L. Chervenak, I. T. Foster, C. Kesselman,

S. Meder, V. Nefedova, D. Quesnel, and S. Tuecke. Data management and transfer in

high-performance computational grid environments. Parallel Computing, 28(5) :749–771,

2002.

[2] E. Badidi. Architectures et Services pour la Distribution de Charge dans les Systemes

Distribues Objet. PhD thesis, Departement d’Informatique et de Recherche Operationnelle,

Universite de Montreal, Canada, Mai 2000.

[3] J. Barreto and P. Ferreira. Optimistic consistency with version vector weighted voting.

Technical Report RT/004/2004, Distributed Systems Group, Lisboa, Distributed Systems

Group Rua Alves Redol N 9, 1000-029 Lisboa, May 2004.

[4] G. Belalem and Y. Slimani. A hybrid approach for consistency management in large scale

systems. In IEEE Computer Society, editor, International Conference on Networking and

Services (ICNS’06), pages 71–71, Silicon Valley, USA, 16-19 July 2006.

[5] G. Belalem and Y. Slimani. Consistency management for data grid in optorsim simulator.

In IEEE Computer Society, editor, International Conference on Multimedia and Ubiquitous

Engineering (MUE’07), pages 554–560, Korean Bible University, Seoul, Korea, 26-28 April

2007.

[6] G. Belalem and Y. Slimani. A hybrid approach to replica management in data grids.

International Journal of Web and Grid Services (IJGWS), 3(1) :2–18, 2007.

[7] F. Berman, A. J. C. Hey, and G. C. Fox. Grid Computing : Making the Global Infrastructure

a Reality. Wiley Sons, 2003.

[8] A-G. Bosser. Replications Distribuees pour la Definition des Interactions de Jeux Massive-

ment Multi-Joueurs. PhD thesis, Universite de Paris 7, France, Novembre 2005.

[9] R. Buyya. Economic-based Distributed Resource Management and Scheduling for Grid Com-

puting. PhD thesis, Monash University, Melbourne, Australia, April 2002.

[10] R. Buyya and S. Venugopal. A gentle introduction to grid computing and technologies. CSI

Communications : Computer Science of India, 29(1) :9–19, July 2005.

94

[11] D. G. Cameron, A. Paul Millar, C. Nicholson, R. Carvajal-Schiaffino, K. Stockinger, and

F. Zini. Analysis of scheduling and replica optimization strategies for data grids using

optorsim. Journal of Grid Computing, 2(1) :57–69, 2004.

[12] S. Ceri, M. A. W. Houtsma, A. M. Keller, and P. Samarati. A classification of update

methods for replicated databases. Technical report, Stanford, CA, USA, 1991.

[13] R-S. Chang and J-S. Chang. Adaptable replica consistency service for data grids. In Third

International Conference on Information Technology : New Generations (ITNG’06), pages

646–651, Las Vegas, Nevada, USA, 2006.

[14] M. Ciglan and L. Hluchy. Replica update propagation for grid data resources. In IEEE Com-

puter Society, editor, 15th IEEE International Workshops on Enabling Technologies : Infra-

structure for Collaborative Enterprises (WETICE’06), pages 222–226, Manchester, United

Kingdom, 26-28 June 2006.

[15] E. Cohen and S. Shenker. Replication strategies in unstructured peer-to-peer networks.

In Proceedings of the 2002 Conference on Applications, Technologies, Architectures, and

Protocols for Computer Communications (SIGCOMM), pages 177–190, Pittsburgh, PA,

USA, August 2002.

[16] G. Coulouris, J. Dollimore, and T. Kindberg. Distributed Systems : Concepts and Design.

International Computer Science Series. Addison-Wesley, 2000.

[17] S.B. Davidson, H. Gracia-Molina, and D. Skeen. Consistency in partioned networks. ACM

Computing Surveys, 17(3) :341–370, 1985.

[18] B. Del-Fabbro. Contribution a la Gestion des Donnees dans les Grilles de Calcul a la

Demande : de la Conception a la Normalisation. PhD thesis, Universite de Franche-Comte,

France, Novembre 2005.

[19] X. Defago. Agreement-Related Problems : From Semi-Passive Replication to Totally Ordered

Broadcast. PhD thesis, Ecole Polytechnique Federale de Lausanne, Switzerland, August

2000.

[20] X. Defago and A. Schiper. Semi-passive replication and lazy consensus. Journal of Parallel

and Distributed Computing, 64(12) :1380–1398, December 2004.

[21] A. Domenici, F. Donno, G. Pucciani, H. Stockinger, and K. Stockinger. Replica consistency

in a data grid. Nuclear Instruments and Methods in Physics Research A, 534 :24–28, 2004.

[22] S. Drapeau. RS2.7 : Un Canevas Adaptable de Services de Duplication. PhD thesis, Institut

National Polytechnique de Grenoble, France, Juin 2003.

[23] P. Felber, X. Defago, P. Eugster, and A. Schiper. Replicating corba objects : a marriage

between active and passive replication. In Second IFIP WG6.1 : International Working

95

Conference on Distributed Applications and Interoperable Systems (DAIS’99), pages 375–

388, Helsinki, Finland, June 28 - July 1 1999.

[24] I. Foster. What is the grid ? a three point checklist. GRIDtoday, 1(6), 22 July 2002.

http ://www.gridtoday.com/02/0722/100136.html.

[25] I. Foster, C. Kesselman, and S. Tuecke. The anatomy of the grid : Enabling scalable virtual

organizations. International J. Supercomputing Applications, 15(3) :200–222, August 2001.

[26] I. Foster and C. Kesselmann. The Grid : Blueprint for Future Computing Infrastructure.

Morgan Kaufmann, San Francisco, 1999.

[27] I. Foster and C. Kesselmann. The Grid 2 : Blueprint for a New Computing Infrastructure.

Elsevier Series in Grid Computing, 2004.

[28] L. Gao, M. Dahlin, J. Zheng, and A. Iyengar. Improving availability and performance with

application-specific data replication. IEEE Transactions on Knowledge and Data Enginee-

ring, 17(1) :106–120, January 2005.

[29] J. Garmany and R. Freeman. Multi-master replication conflict avoidance and resolution.

Select Journal, independent Oracle Users Group, 11(4) :9–15, December 2004.

[30] V. Getov, M. Gerndt, A. Hoisie, A. Malony, and B. Miller. Performance Analysis and Grid

Computing. Springer, 2003.

[31] S. Goel and R. Buyya. Data replication strategies in wide area distributed systems. In

Robin G. Qiu, editor, Enterprise Service Computing : From Concept to Deployment, pages

211–241. Idea Group Inc., Hershey, PA, USA, 2006.

[32] S. Goel, H. Sharda, and D. Taniar. Replica synchronisation in grid databases. Int. J. Web

and Grid Services, 1(1) :87–112, 2005.

[33] J. Gray, P. Helland, P.E. O’Neil, and D. Shasha. The dangers of replication and a solu-

tion. In ACM SIGMOD International Conference on Management of Data, pages 173–182,

Montreal, Quebec, Canada, 4-5 June 1996. ACM Press.

[34] C. Haddad and F.B. Charrada. Database placement on large-scale systems. International

Journal of Information Technology, 3(4) :251–256, July 2006.

[35] C. Haddad and Y. Slimani. Economic model for replicated database placement in grid.

In 7th IEEE International Symposium on Cluster Computing and the Grid (CCGrid’07),

pages 283–289, Rio de Janeiro, Brazil, 14-17 May 2007. IEEE Computer Society.

[36] A. Imine. Conception Formelle d’Algorithmes de Replication Optimiste Vers l’Edition Col-

laborative dans les Reseaux Pair-a-Pair. PhD thesis, Doctorat de l’universite Henri Poincare

Nancy 1, France, Novembre 2006.

[37] Z. Juhasz, P. Kacsuk, and D. Kranzlmuller. Distributed and Parallel Systems : Cluster and

Grid Computing. Springer, Boston, USA, 2005.

96

[38] M. Karlsson, C. Karamanolis, and M. Mahalingam. A framework for evaluating replica

placement algorithms. Technical report, HP Labs, 2002.

[39] W. Lahmaidi. Protocole de placement initial de repliques de fichiers dans une grille de

type beowulf. Master’s thesis, Universite de Tunis El Manar, Faculte des Sciences de Tunis,

Tunisie, Fevrier 2005.

[40] H. Lamehamedi, Z. Shentu, B. Szymanski, and E. Deelman. Simulation of dynamic data

replication strategies in data grids. In 12th Heterogeneous Computing Workshop (HCW’03),

Nice, France, April 2003. IEEE Computer Science Press.

[41] S. Monnet. Gestion des Donnees dans les Grilles de Calcul : Support pour la Tolerance aux

Fautes et la Coherence des Donnees. PhD thesis, Universite de Rennes, France, Novembre

2006.

[42] R. Moore. Evolution of data grid concepts. The Future of Grid Data Environments : Global

Grid Forum Data Area Workshop (GGF10), Berlin, Germany, March 2004.

[43] C. M. M. Nicholson. File Management for HEP Data Grids. PhD thesis, Department of

Physics and Astronomy, University of Glasgow, UK, March 2006.

[44] G. Oster. Replication Optimiste et Coherence des Donnees dans les Environnements Col-

laboratifs Repartis. PhD thesis, Universite Henri Poincare, Nancy 1, France, Novembre

2005.

[45] C. Le Pape. Controle de Qualite des Donnees Repliquees dans un Cluster. PhD thesis,

Universite Pierre et Marie Curie (Paris VI), France, Decembre 2005.

[46] J-M. Pierson. Une Grille Pervasive Vue du Cote des Donnees. PhD thesis, Universite

Claude Bernard - Lyon I, France, Novembre 2005.

[47] P. Plaszczak and R. Jr. Wellner. Grid Computing : The Savvy Manager’s Guide. Morgan

Kaufmann, San Francisco, 2005.

[48] K. Ranganathan and I. Foster. Identifying dynamic replication strategies for a high-

performance data grid. In Springer Berlin, editor, Grid : Second International Workshop,

volume 2242, pages 75–86, 12 November 2001.

[49] M. Ripeanu and I. Foster. A decentralized, adaptive replica location mechanism. In

IEEE Computer Society, editor, HPDC-11 ’02, pages 24–34, Los Alamitos, CA, USA, 23-26

July 2002.

[50] Y. Saito and M. Shapiro. Optimistic replication. ACM Computing Surveys, 37(1) :42–81,

2005.

[51] L. Simoncini. Grid computing evolution and challenges for resilience, performance and

scalability. Workshop on Grid Computing and Dependability, 48th Meeting of the IFIP

Working Group 10.4, Hakone, Japan, July 1-5 2005.

97

[52] Y. Slimani, F. Najjar, and N. Mami. An adaptive cost model for distributed query op-

timization on the grid. In Lecture Notes in Computer Science (LNCS), editor, Category

Workshop on Grid Computing and Its Application to Data Analysis (GADA’04) OTM 2004

Workshops, volume 3292/2004, pages 79–87, Agia Napa, Cyprus, October 25-29 2004.

[53] H. Stockinger. Database Replication in World-Wide Distributed Data Grids. PhD thesis,

CERN (European Organization for Nuclear Research), Genf, Schweiz, November 2001.

[54] S. Vazhkudai, S. Tuecke, and I. Foster. Replica selection in the globus data grid. In

CCGRID’01 : Proceedings of the 1st International Symposium on Cluster Computing and

the Grid, pages 106–113. IEEE Computer Society, 2001.

[55] M-H. Verrons. GeNCA : Un Modele General de Negociation de Contracts entre Agents.

PhD thesis, Universite des Sciences et Technologies de Lille, France, Novembre 2004.

[56] G. Weiderhold and X. Qian. Consistency control of replicated data in federated databases.

In Proceedings of the 1st Workshop on the Management of Replicated Data, pages 130–132,

Houston, USA, November 1990.

[57] M. Wiesmann, F. Pedone, A. Schiper, B. Kemme, and G. Alonso. Understanding replication

in databases and distributed systems. In ICDCS ’00 : Proceedings of the 20th Internatio-

nal Conference on Distributed Computing Systems (ICDCS 2000), pages 264–274. IEEE

Computer Society, 2000.

[58] J. Xu, B. Li, and D. J. Lee. Placement problems for transparent data replication proxy

services. IEEE Journal on Selected Areas in Communications, 7(20) :1383–1398, 2002.

[59] B. Yagoubi and Y. Slimani. Load balancing strategy in grid environment. Journal of

Information Technology and Applications (JITA), 1(4) :285–296, March 2007.

[60] H. Yu and A. Vahdat. The costs and limits of availability for replicated services. In

SOSP’01 : Proceedings of the Eighteenth ACM Symposium on Operating Systems Principles,

pages 29–42. ACM Press, 2001.

[61] H. Yu and A. Vahdat. Design and evaluation of a conit-based continuous consistency model

for replicated services. ACM Transactions on Computer Systems, 20(3) :239–282, August

2002.

98

Contribution à la gestion de la cohérence de répliques de ...

Documents

Transcript of Contribution à la gestion de la cohérence de répliques de ...