RS2.7 : un Canevas Adaptable de Services de Duplication

HAL Id: tel-00005205

https://tel.archives-ouvertes.fr/tel-00005205

Submitted on 4 Mar 2004

HAL is a multi-disciplinary open access

archive for the deposit and dissemination of

sci-entific research documents, whether they are

pub-lished or not. The documents may come from

teaching and research institutions in France or

L’archive ouverte pluridisciplinaire HAL, est

destinée au dépôt et à la diffusion de documents

scientifiques de niveau recherche, publiés ou non,

émanant des établissements d’enseignement et de

recherche français ou étrangers, des laboratoires

RS2.7 : un Canevas Adaptable de Services de

Duplication

Stéphane Drapeau

To cite this version:

Stéphane Drapeau. RS2.7 : un Canevas Adaptable de Services de Duplication. Réseaux et

télécommu-nications [cs.NI]. Institut National Polytechnique de Grenoble - INPG, 2003. Français. �tel-00005205�

No. attribuépar labibliothèque

THÈSE

pour obtenir legradede

Do teur de l'Institut National Polyte hnique de Grenoble

Spé ialité : Informatique : Systèmes et Communi ations

préparée auLaboratoireDTL/ASRde Fran eTélé om R&D et

au LaboratoireLogi iels,Systèmes et Réseaux (LSR)

dansle adrede l'E ole Do torale

Mathématiques,S ien eset te hnologies de l'information, Informatique

présentée etsoutenue publiquement

par Stéphane Drapeau le24 juin2003 RS2.7 : un Canevas Adaptable de Servi es de Dupli ation JURY :

M. GuyMazaré Président

M. Philippe Pu heral Rapporteur

M. Mi helRiveill Rapporteur

Mme.Christine Collet Dire teur dethèse

Mme.Claudia Lu ia Ron an io Co-en adrant

M. Pas al Dé hamboux Co-en adrant

Letravailprésentédans ettethèseaétéee tuéauseindudépartementAr hite turedes

SystèmesRépartisdelaDire tiondesTe hniquesLogi ielles (DTL/ASR)deFran eTélé om

R&D et du Laboratoire Logi iels, Systèmes et Réseaux (LSR) de l'Institut d'Informatique

et de Mathématiques Appliquées de Grenoble (IMAG). Je tiens à remer ier es deux

orga-nismes qui m'ont permis d'ee tuer mon travail dans les meilleures onditions matérielles,

s ientiques et te hniquesque l'onpuisseespérer.

Je remer ietrès sin èrementClaudiaLu íaRon an io,maîtrede onféren eàl'É ole

Na-tionaleSupérieured'InformatiqueetdeMathématiquesAppliquéesdeGrenoble(ENSIMAG),

pour lagrandedisponibilitédontelle atoujoursfaitpreuve,ainsiquepour ses onseilsavisés

qui m'ont permis d'avan er vers un résultat meilleur. Son en adrement m'aura été pré ieux

tout au long de es quatre années. Ce manus rit doit beau oup à ses suggestions et à ses

rele turesattentives.

Jeremer ieégalementPas alDé hamboux,ingénieurre her heetdéveloppementàFran e

Télé om R&D,pour lesdis ussions quenousavonseueset qui m'ont permisd'avan er.

Je tiens à remer ier Christine Collet, professeur à l'É ole Nationale Supérieure

d'Infor-matique et de Mathématiques Appliquées de Grenoble (ENSIMAG), responsable du projet

NODS, pour m'avoir a ueilli dans son équipe et pour la onan e qu'elle m'a toujours

té-moignée.

J'exprime maprofonde gratitudeà MonsieurGuy Mazaré, professeurà l'É ole Nationale

Supérieurd'InformatiqueetMathématiquesAppliquéesdeGrenoble,pourl'honneurqu'ilm'a

faitenprésidant monjurydethèse.Jesouhaiteremer ierMessieursMi helRiveill,professeur

àl'É oleSupérieureenS ien esInformatiques(ESSI)del'UniversitédeNi eSophiaAntipolis

etmembredel'équipeInformatiqueSignauxetSystèmesdeSophiaAntipolis(I3S),etPhilippe

Pu heralprofesseuràl'UniversitédeVersaillesetmembredulaboratoireParallélismeRéseaux

Systèmes Modélisation de Versailles (PRiSM), pour avoir a eptés la lourde harge d'être

rapporteur et pour leurs pré ieusesremarquesqui m'ont permisd'améliorer emanus rit.Je

remer ie aussi Madame Kathleen Milsted, responsable du laboratoire DTL/ASR de Fran e

Télé om R&D,d'avoir a eptée de faireparti de monjury.

dis ussions que nous avons eues et qui m'ont permis de omprendre bien des hoses. Ses

ritiques onstru tiveset sesen ouragements m'ont permis demener à bien ette thèse.

Mesremer iementsvontnaturellementàl'ensembledesgensquej'ai toyédurant estrois

annéesetquim'ontaidéoutoutsimplement renduledéroulement de ettethèseagréable.Je

iteraientreautres: Lu ianoGar iaBañuelospournoslonguesdis ussionssurladupli ation

et la persistan e maiségalement surtout et n'importe quoi, Patri ia Serrano Alvaradopour

m'avoir fait dé ouvrir l'informatique mobile, m'avoir laissé lui présenter à maintes reprises

mestravauxet surtoutm'avoirpermisdedé ouvrir sonmerveilleuxpays,leMexique,Mikaël

Beauvoispournosréexionssurla ompositionetlarele turede emanus rit,EdgardBenitez

pour m'avoir aidé à é rire mon premier arti le sur le pré hargement à l'aide de te hniques

d'extra tiondedonnées,AlexandreLefebvrepouravoirbienvoulu onsa rerdesontempsàla

rele ture demesarti leset de e manus rit, TanguyNedele pour letempsqu'il a onsa réà

larele turede emanus ritetpoursesremarquestoujourstrès onstru tives,Phuong-Quynh

Duongpournosdis ussionssurlatoléran eauxfautes,Tony,Khalid,RafaeletGennaropour

les fran hes rigolades que nous avons pu avoir et également tous les autres : Olivier, Caty,

Régine,Manuel, Lizbeth, A hraf,Trinh,Genoveva,JoseLuis,Christelle, Romain,Mouradet

la ommunautéMexi aine Grenobloise.

Mes pensées les plus hères vont à mes parents, mon frère Thierry et mes amis, dont

l'ae tion, la onan e et lesoutienne merent jamaisdéfaut.

Je ne saurai terminer sans adresser tous mes remer iements à Patri ia pour le pré ieux

soutien et ses onstants en ouragements qu'elle m'a apportés durant les quatre années de

ette thèse.

Le23 juin2003.

1 Introdu tion 17

1.1 Del'importan e et de ladi ulté de ladupli ation . . . 17

1.2 Unnouveau paradigmede programmation : laséparationdes préo upations 18 1.3 Delané essitéd'orir unsupport adaptable deladupli ation . . . 19

1.4 Démar he et ontributions de notretravail . . . 21

1.5 Plande lathèse . . . 25

I Comprendre le problème : état de l'art 27 2 Con epts et te hniques de dupli ation 29 2.1 Points remarquables desproto oles de dupli ation. . . 30

2.1.1 Nombre de opies on ernées par unele ture et uneé riture . . . 31

2.1.2 Droits d'a ésaux opies . . . 32

2.1.3 Moment de lasyn hronisation . . . 32

2.1.4 Initiative de lamiseàjour . . . 34

2.1.5 Nature desmisesà jour . . . 35

2.1.6 Topographie de lasyn hronisation . . . 35

2.1.7 Capturedesmises àjour . . . 36

2.1.8 Gestion des onits. . . 37

2.1.9 Intera tions ave leproto olede ommuni ation. . . 37

2.1.10 Gestion dela on urren e . . . 39

2.1.11 Gestion desfautes . . . 39

2.1.13 Transparen e à ladupli ation . . . 40

2.1.14 Grillede omparaison desproto oles dedupli ation . . . 40

2.2 Dupli ationà l'aidede systèmesde ommuni ation degroupe . . . 40

2.2.1 Quatre proto oles majeurs . . . 41

2.2.1.1 Dupli ationpassive . . . 42

2.2.1.2 Dupli ationa tive . . . 43

2.2.1.3 Dupli ationsemi-a tive . . . 45

2.2.1.4 Dupli ation oordinateur/ ohortes . . . 46

2.2.2 Présentation dediérentssystèmes . . . 46

2.2.2.1 Isis . . . 47 2.2.2.2 Psyn . . . 47 2.2.2.3 Grapevine. . . 48 2.2.2.4 Lazyrepli ation . . . 48 2.2.2.5 CODA . . . 49 2.2.3 Con lusion . . . 50

2.3 Dupli ationdansles systèmes degestionde bases dedonnées réparties . . . . 51

2.3.1 Contextetransa tionel . . . 52

2.3.1.1 Transa tion . . . 52

2.3.1.2 Stratégies depropagation desmises àjour . . . 52

2.3.1.3 Cohéren es . . . 53

2.3.2 Quatre appro hespourles proto oles de dupli ation . . . 55

2.3.2.1 Proto oles impatients . . . 55

2.3.2.2 Proto oles paresseux maître-es laves . . . 57

2.3.2.3 Proto oles paresseux ave miseàjour surn'importequel site 58 2.3.2.4 Proto oles impatients utilisant les primitives de ommuni a-tionde groupe . . . 59

2.3.3 Con lusion . . . 59

2.4 Dupli ationdansles mémoirespartagées réparties. . . 61

2.4.1 La notionde modèlede ohéren e . . . 61

2.4.2 Modèlesde ohéren e sans syn hronisation. . . 62

2.4.2.1 Cohéren eatomique . . . 63

2.4.2.3 Cohéren e ausale . . . 64

2.4.2.4 Cohéren ePRAM . . . 65

2.4.2.5 Cohéren eobjet . . . 66

2.4.2.6 Cohéren e"à lalongue" . . . 66

2.4.3 Modèles de ohéren e ave syn hronisation . . . 66

2.4.3.1 Cohéren efaible . . . 66

2.4.3.2 Cohéren eau relâ hement . . . 67

2.4.3.3 Cohéren eà l'entrée . . . 68

2.4.4 Con lusion . . . 69

2.5 Con lusion. . . 69

3 Supportsde dupli ation adaptables 73 3.1 Delané essitéde l'adaptabilitépour êtreadaptable . . . 73

3.1.1 Adaptable,adaptation et adaptabilité . . . 74

3.1.2 Appro hespour obtenir l'adaptabilité . . . 75

3.2 Adaptabilité dansles mémoirespartagéesréparties . . . 76

3.2.1 Munin . . . 76

3.2.2 Un anevasexible pour lagestionde la ohéren e dansles MPR . . . 78

3.3 Adaptabilité dansles systèmesà objetsrépartis . . . 81

3.3.1 GARF . . . 81

3.3.2 Core . . . 83

3.3.3 Globe . . . 85

3.4 Adaptabilité dansle ontexteCORBA . . . 87

3.4.1 Eternal . . . 88

3.4.2 OGS . . . 90

3.5 Con lusion. . . 92

II Eléments de solution 95 4 Un anevas adaptable de servi es de dupli ation 97 4.1 RS2.7: Un anevasadaptable de servi esde dupli ation . . . 98

4.1.1 Le projetNODS . . . 98

4.1.3 Un anevasadaptable . . . 100

4.2 Noyauminimal d'un servi ededupli ation . . . 102

4.3 La notionde politique dedupli ation . . . 103

4.4 Collaboration ave d'autres aspe ts . . . 104

4.5 Con lusion. . . 105

5 Modélisation des servi es : les modèles de ohéren e lo ale 107 5.1 Dénitions préliminaires . . . 108

5.1.1 Ordre total,ordre partiel . . . 109

5.1.2 Extension linéaire. . . 109

5.1.3 Modélisationd'uneexe ution répartie . . . 110

5.1.4 Le ture légale . . . 110

5.1.5 Modélisationd'uneexé ution surun objetdupliqué . . . 111

5.2 Quatre typesde modèlede ohéren e lo ale . . . 111

5.2.1 Modèlesà opieunique . . . 112

5.2.2 Modèlesà opies divergentes . . . 114

5.2.3 Modèlesà opies onvergentes ave le turesurles opies divergentes . 117 5.2.4 Modèlesà opies onvergentes ave é rituresurles opies divergentes . 119 5.2.5 Con lusion . . . 121

5.3 Modèle de ohéren e lo aleet séparation des onsidérations . . . 122

5.3.1 Contrleur de on urren e . . . 123

5.3.2 Contrleur defautes . . . 126

5.4 Con lusion. . . 127

6 Adaptabilité de RS2.7 au ontexte non fon tionnel 129 6.1 Delané essitéde séparer ohéren e globale et lo ale . . . 130

6.1.1 Modèlede ohéren e globale . . . 130

6.1.2 Delané essitéd'isolerladupli ation . . . 131

6.2 Dé ompositiond'un proto olede ohéren e globale . . . 132

6.2.1 Composant proto ole de ohéren e globale . . . 133

6.2.2 Composant gestionde la on urren e . . . 136

6.2.4 Composant proto ole de ommuni ation . . . 137

6.2.5 Composant proto ole de ohéren e lo ale . . . 137

6.3 Séparationdes onsidérations lo ales et globales . . . 138

6.3.1 Modèles de ohéren e globale sans syn hronisation pour MPR . . . 138

6.3.1.1 Prin ipes . . . 138

6.3.1.2 Miseen ÷uvre . . . 140

6.3.2 Modèles de ohéren e globale ave syn honisationpour MPR . . . 141

6.3.2.1 Prin ipes . . . 141

6.3.2.2 Miseen ÷uvre . . . 144

6.3.3 Modèles de ohéren e globale pour SGBDR . . . 145

6.3.3.1 Prin ipes . . . 145

6.3.3.2 Miseen ÷uvre . . . 148

6.4 Con lusion. . . 148

7 Adaptabilité des proto oles de ohéren e lo ale 151 7.1 Proto ole abstrait de ohéren e lo ale . . . 152

7.1.1 Cinqphases pour le proto oleabstrait de ohéren e lo ale . . . 152

7.1.2 Cinqpatrons d'ordonnan ement. . . 154

7.1.3 Constru tion duproto oleabstrait de ohéren e lo ale . . . 156

7.2 Ar hite ture fon tionnelledesproto oles de ohéren e lo ale . . . 162

7.2.1 Composants ommuns auxmodèles . . . 164

7.2.1.1 Phased'a ès . . . 164

7.2.1.2 Phasede oordination . . . 164

7.2.1.3 Phased'exe ution . . . 166

7.2.1.4 Phasede réponse. . . 167

7.2.2 Composantsdépendantsdu modèlede ohéren e lo ale. . . 167

7.2.2.1 Phased'a ès . . . 167

7.2.2.2 Phasede validation . . . 168

7.2.3 Composantsdépendantsdesproto oles . . . 169

7.2.3.1 Phased'a ès . . . 169

7.2.3.2 Phasede oordination . . . 170

7.3 Con lusion. . . 171

III Mise en ÷uvre et validation 173 8 Mise en ÷uvre et validation de RS2.7 175 8.1 Miseen ÷uvrede RS2.7 . . . 175

8.1.1 Prin ipesd'ar hite ture . . . 176

8.1.2 Constru tion d'un proto ole de ohéren e lo ale. . . 179

8.1.3 Liaisonave l'appli ation . . . 180

8.2 Adaptabilité desproto oles de ohéren e lo ale . . . 182

8.2.1 Un proto olede ohéren e lo ale maître/es lavesparesseux . . . 182

8.2.1.1 Miseen ÷uvre . . . 182

8.2.1.2 Adaptation du proto ole. . . 186

8.2.2 Le proto ole de ohéren e lo aleROWA . . . 188

8.2.2.1 Miseen ÷uvre . . . 188

8.2.2.2 Adaptation du proto ole. . . 189

8.3 Adaptabilité au ontexte nonfon tionnel . . . 189

8.3.1 Utilisation de RS2.7 dans le ontexte des plateformes pour mondes virtuels . . . 190

8.3.2 Dis ussion autoursde la onstru tion de modèles de ohéren e globale 192 8.4 Con lusion. . . 194

9 Con lusion et perspe tives de re her he 197 9.1 Bilandu travail ee tué . . . 197

9.1.1 Taxonomie desproto oles dedupli ation . . . 198

9.1.2 Dénition d'un anevasadaptable de servi esde dupli ation . . . 199

9.1.3 Dénition formelledes servi esde dupli ation . . . 200

9.1.4 Adaptabilité de RS2.7au ontextenon fon tionnel . . . 200

9.1.5 Adaptabilité danstoutou partie desproto oles de ohéren e lo ale . . 201

9.1.6 Miseen ÷uvreet expérimentation . . . 201

9.2 Perspe tivesde re her he . . . 202

Bibliographie 209

1.1 Développement de servi esde dupli ation à partir d'un anevas . . . 20

2.1 Compromis performan e/abilité et réper ussionssur la ohéren e . . . 31

2.2 Appro hemaître-es lavesversus opies identiques . . . 33

2.3 Rafraî hissement de type push et pull . . . 34

2.4 Diérentes topographiesde propagationdes misesà jour . . . 36

2.5 Cara téristiques desproto oles de dupli ation . . . 41

2.6 Exemplede dupli ation passive . . . 43

2.7 Exemplede dupli ation a tive . . . 44

2.8 Exemplede dupli ation semi-a tive . . . 45

2.9 Prin ipe deladupli ation oordinateur/ ohortes . . . 46

2.10 Comparaisondes proto oles de dupli ation utilisantles SGC . . . 50

2.11 Stratégies de propagationdansles SGBDR . . . 53

2.12 Classi ationdes proto oles de dupli ation utilisésdansles SGBDR . . . 60

2.13 Relationmodèle de ohéren e/dupli ation . . . 65

2.14 Classi ationdes proto oles de dupli ation utilisésdansles MVP . . . 70

3.1 Correspondan e annotations/paramètresdesproto oles Munin . . . 77

3.2 Vued'ensembleet hiérar hie de lasses du anevasFFCM . . . 79

3.3 Vued'ensembledu proto ole de ohéren e dansFFCM . . . 80

3.4 Invo ation d'uneméthode dansGarf . . . 82

3.5 Ar hite ture Core . . . 83

3.6 Con eptsde Globe . . . 85

3.8 Dupli ationa tive/passive dansEternal . . . 89

3.9 ComposantsOGS . . . 91

3.10 Adaptabilité et proto oles fournis par quelquessystèmes . . . 92

4.1 L'appro he NODS . . . 98

4.2 Choixd'un proto olede dupli ation approprié . . . 99

4.3 Développement de servi es dedupli ation à partir d'un anevas . . . 101

4.4 Inter eption desa ès à unobjetdupliquépar un servi ede dupli ation . . . 103

4.5 Politique dedupli ation / servi ede dupli ation . . . 104

4.6 Intéra tions ave leservi ede dupli ation . . . 105

5.1 Notationsutilisées pour modéliserune exé ution répartie . . . 108

5.2 Notationsutilisées pour modéliserune exé ution surun objetdupliqué . . . . 109

5.3 Modèle de ohéren e lo aleà opieunique séquentiel . . . 113

5.4 Modèle de ohéren e lo aleà opies divergentes ausale. . . 114

5.5 Modèle de ohéren e lo aleà opies divergentesFIFO . . . 116

5.6 Modèle à opies onvergentes ave le turesur les opies divergentes . . . 118

5.7 Modèle à opies onvergentes ave é riture surles opies divergentes . . . 120

5.8 Modèles de ohéren e lo ale pour ontextemobile . . . 122

5.9 Modèle de ohéren e lo aleet séparation desaspe ts . . . 123

5.10 Rledugestionnairede ontrle de on urren eduproto ole de ohéren e lo ale125 6.1 Isolationde ladupli ation au seinde la ohéren e globale . . . 132

6.2 Dé ompositiondu proto ole de ohéren e globale . . . 133

6.3 Intéra tions entre les omposantsdu proto ole de ohéren e globale . . . 137

6.4 Notationsutilisées pour modéliserl'histoire sur lesvariables desyn hronisation 142 6.5 Notationsutilisées pour modéliserles MPRave syn hronisations . . . 142

6.6 Notationsutilisées pour lesvariables desyn hronisation d'un objetdupliqué . 143 7.1 Proto ole de ohéren e lo aleet ordonnan ement desphases . . . 153

7.2 Ordonnan ements possiblesdes inq phases . . . 155

7.3 Stru turedesproto oles de ohéren e lo ale . . . 162

8.1 Chaînesde liaison entre opies . . . 176

8.2 Code pour la réation d'un objetdupliquable . . . 177

8.3 Création d'un objetdupliquable . . . 178

8.4 Code pour la réation d'une opie . . . 178

8.5 Création d'une opie . . . 179

8.6 DTDXML dedes ription desobjetsappli atifs . . . 180

8.7 Objetpour a èder àl'objetappli atif Personne . . . 181

8.8 Le ture surlemaître ousurles es laves . . . 183

8.9 E rituresur lemaître. . . 183

8.10 Pro essusde syn hronisation surlemaître . . . 184

8.11 Pro essusde syn hronisation surunes lave . . . 184

8.12 Le ture sur un es lave dans un proto ole paresseux maître/eslaves de type demande/diusion . . . 187

Introdu tion

Sommaire

1.1 De l'importan eetde ladi ulté de la dupli ation . . . 17

1.2 Un nouveau paradigme de programmation : la séparation des

préo upations . . . 18

1.3 De la né essitéd'orir un support adaptablede ladupli ation . 19

1.4 Démar he et ontributions de notretravail . . . 21

1.5 Plan de la thèse . . . 25

C

e premier hapitre situe brièvement le ontexte de e travail de thèse (se tion 1.1), en

donne laproblématique (se tion1.2), énon elesobje tifsvisés(se tion1.3), présentela

démar he et les prin ipales ontributions apportées(se tion 1.4)et nalement donne

l'orga-nisation de e do ument (se tion 1.5).

1.1 De l'importan e et de la di ulté de la dupli ation

L'évolution dessystèmes informatiques pendant es dernières années est ara térisée par

une tendan e très forte à la dé entralisation et les ongurations réparties sont de plus en

plus répandues.Cette tendan e entraîne desbesoins en mé anismesassurant la disponibilité

et la abilité des données pour fournir la toléran e aux fautes et/ou le passage à l'é helle.

La dupli ation d'informations et/ou de servi es est un de es mé anismes, ar elle apporte

essentiellement deux béné es :

 D'une part, une amélioration des performan es. Si les données se trouvent en un seul

lieu, la ma hine qui les gère ainsi que le réseau pour y a éder onstituent un goulot

à augmenter les performan es et diminuer les oûts d'a ès aux données pour ha un des lients.

 Et d'autre part, une meilleure sûreté de fon tionnement. On peut distinguer deux

as-pe ts :

 La disponibilitédesdonnées. Pluslenombre de ma hines indépendantesdupoint de

vue des pannes et possédant une opie d'une donnée est important, plus le temps

pendant lequel ette donnée esta essible seragrand.

 La abilité des données. La dupli ation permet d'éviter de perdre desmodi ations

dedonnéeslorsd'unepanneet permetdenepasperdredesdonnéesen asdepannes

dénitives. Cettenotion est diérente de la disponibilité et est même parfois

in om-patiblelorsqu'on yajoute lesproblèmes de ohéren e entre opies.

Malheureusement, malgrétous esavantages,ladupli ation aun oût arilestné essaire

de maintenir une  ertaine ohéren e entre les opies.En eet,la dupli ation ren ontre une

ontradi tion majeure : assurerla ohéren e des opies tout en onservant desperforman es

a eptables.Unproto oleassurantune ohéren eforteestsimplemaisnepassepasàl'é helle,

d'où des re her hes a tives sur des ohéren es aaiblies. Dans tous les as de gure, étant

donné que haque opie est indépendante, des proto oles sont né essaires an d'assurer la

miseen ohéren e des opies.Ilsdoivent également garantir queles a ès on urrents surles

diérentes opies sedéroulent onvenablement.

Cinq grands domaines de l'informatique sesont parti ulièrement intéressés à la

dupli a-tion:les systèmesà ommuni ationdegroupe,lesmémoiresvirtuellesréparties,lessystèmes

de gestiondebases de donnéesréparties,les systèmesde  hiers répartis,ainsiqueles

plate-formesàobjets.Malheureusement, nouspouvonsremarquerquemalgrélenombre important

de travaux [GHOS96 , KA00a, Kin99 , DR01℄, il n'y a que très peu de rappro hement entre

lesprojetsmenés dans esdiérentsdomaines. Ainsi,denombreusessolutionssont proposées

autravers desystèmesdivers, ha un ayant faitsespropres hoix,leplussouvent demanière

dénitive. Certaines solutions sont orientées vers une atégorie d'appli ations pré ise, d'où,

nalement, le nombre et la variété des systèmes disponibles. Ces hoix parti uliers

ondi-tionnententreautrela ohéren e entreles opies,lesperforman es,latoléran eauxfautes,la

transparen eoubienen oreladi ultédeprogrammation.Ainsi,le hoixetlamiseen÷uvre

deladupli ationpouruneappli ationparti ulièreestunetâ hedi ilepourleprogrammeur.

1.2 Un nouveau paradigme de programmation : la séparation

des préo upations

L'étude des te hniques de développement lassiques omme les méthodes itératives font

apparaîtrequ'unedesgrandesdi ultésdel'informatiquevientd'unproblèmeorganisationnel

lié à unentrela ement desaspe ts métiers ou fon tionnels (le ode appli atif) et des aspe ts

te hniques ounon fon tionnels (notamment ladupli ation) d'uneappli ation.

a tuel-lement des outils ou des infrastru tures permettant de séparer es aspe ts an que le

déve-loppeur d'appli ations puisse se on entrer surle ode fon tionnel plutt que sur destâ hes

non-spé iques à une appli ation. Les intergi iels (middlewares) omme CORBA [OMG97 ,

OMG98 ℄,EJB[DYK01 ℄,COM/DCOM[Mi 95 ℄,.net[Mi 02℄),et ,ensontdesbonsexemples.

Un intergi iel estune ou he logi ielle qui se situe entre le système d'exploitation et les

ap-pli ations.L'obje tif d'unintergi iel estdefournir lesaspe tsnon fon tionnelssous formede

servi es (servi es n'existant pas à l'origine dans le système) et également d'être une ou he

d'abstra tion pour la programmation d'appli ations. Le premier servi e fourni est

générale-ment, unsystème de ommuni ation (dit aussi"buslogi iel") entreles appli ations utilisant

l'intergi iel. On peut également trouver, selon les intergi iels, un servi ede gestionde

tran-sa tions,un servi edepersistan eou en oreun servi ededupli ation.

Cependant, la séparation des préo upations n'est pas hose aisée. Par exemple, dans

CORBA, les servi es doivent être expli itement utilisés par le programmeur d'appli ation.

La spé i ation EJB, qui gère les aspe ts non fon tionnels de persistan e et de transa tion,

permet unegestion impli ite de esaspe ts. Cependant,le programmeur estobligé d'utiliser

equiestproposéparlaplate-forme.Pourunmêmeaspe tnon-fon tionnelle hoixestlimité.

Les travaux ités i-dessus, que l'on peut qualier d'empiriques, se font en parallèle de

travaux théoriques plus généraux. Ainsi, depuis quelques années, l'intérêt de la

ommu-nauté s ientique pour la séparation des préo upations s'est a ru de manière

onsidé-rable et de nombreuses tendan es et te hniques visant à la résoudre ont vu le jour. Parmi

les prin ipales, on peut iter la programmation orientée aspe ts (aspe t-oriented

program-ming) [KLM

+

97, BS99 , ASP01 ℄, la programmation par omposants aspe tuels (ou

ollabo-rations aspe tuelles) [LLM99 , LOML01℄, la programmation orientée sujets (subje t-oriented

Programming) [MHO96, OKK

+

96, HOT97 ℄ ou la programmation par intention (intentional

programming)[Sim95℄. Toutes esappro hesvisent àappliquer auxlangages de

programma-tion le prin ipe bien onnu en génie logi iel de séparation des préo upations (separation of

on erns) [CE99℄. Ces appro hessuggèrent de on evoir desentités logi ielles indépendantes

et fournissentdes moyenspourles assembler.

En on lusion,la séparationdes préo upationset l'appro he par servi es permettent au

développeur d'appli ations de s'abstraire de l'aspe t dupli ation lors de ses développements

an de lui fa iliter la tâ he. Cependant, elle soure d'une limitation majeure. En eet, il

semble très di ile, voir impossible, de fournir un servi e/aspe t générique de dupli ation

pouvant être paramètré an d'être utilisé dansdiérents ontextes d'exé ution ou ouvrant

l'ensembledesproto oles existants.

1.3 De la né essité d'orir un support adaptable de la

dupli a-tion

L'appro headaptableprnéeparlessupportsouvertssembleplusprometteusean

l'en-Application

Application

Contexte non fonctionnel B

Contexte non fonctionnel A

Canevas

de services de duplication

Duplication impatiente

Service de duplication

Duplication paresseuse

Service de duplication

Fig. 1.1 Développement de servi esde dupli ation à partir d'un anevas

sembledesproto oles existants.Eneet,à l'inversedessupports monolithiques, lessupports

ouverts présentent une ar hite ture qui permet leur modi ation en vue de répondre à des

besoinsparti uliers.Ceux- i peuvent seprésentersous diversesformes [Lob00 ℄:

 Unsupportestextensible,s'ilorelapossibilitéd'étendrelesservi esqu'ilmetà dispo-sitiondesutilisateurs.Lesfon tionsdéjà existantesnesont pasae téespar l'extension

dusystèmeet leur omportement ne peut pasêtremodié.

 Un support est ongurable, s'il permet de spé ier l'utilisation d'une fon tion

par-ti ulière parmi un ensemble de fon tions disponibles dans le système. Il est possible

d'iné hirle omportement dusystèmesanstoutefoispouvoirdénirdenouveaux

om-portements.

 Unsupportestadaptablesilesfon tionsinternesdéjàprésentesdanslesystèmepeuvent

êtrerempla ées par de nouvellesfon tions. Il est possible de modier le omportement

dusystèmean de supporter denouveaux besoins.

Ainsi, selon nous, un support adaptable de la dupli ation doit permettre d'obtenir des

servi esde dupli ation appropriés auxressour esoertes,au ontextenon fon tionnel

(tran-sa tionnel, tolérant aux fautes, persistant, et ) et prendre en ompte les ontraintes et les

ré-parties, et ). Pour ela, notre obje tif est de dénir un anevas 1

de servi es de dupli ation,

'està dire lastru ture générale d'un servi ede dupli ation, pouvant ensuite êtreinstan iée

dediversesfaçonsand'obtenirleservi ededupli ationadéquateauxressour es,au ontexte

non fon tionnelet au domaine (gure 1.1).

L'intérêtd'unsupportadaptabledeladupli ationnoussembleimportantsil'on onsidère

l'évolution a tuelle dessystèmes informatiques.Eneet,les systèmesinformatiquesàgrande

é helle ou mobiles ont introduit de nouvelles problématiques qu'un support adaptable peut

aiderà résoudre.Ces environnements présentent une grandehétérogénéité,variabilitéet

évo-lution, aussi bien au niveau des moyens d'exé ution qu'au niveau des besoins à un moment

donné. Les ressour esoertes peuvent être extrêmement diérentes selon que l'on utilise un

assistant personnel, unordinateurportable,une stationdetravailou unserveur.Deplus, les

éléments onstitutifs du systèmeet le systèmemême sont soumis à d'importantes variations

au ours du temps. Lesperforman es du réseau peuvent également varier.Dans les

environ-nements lassiques ledéveloppement et l'exé ution d'appli ationss'ee tuent ensupposant

que le support d'exé ution est onnu à l'avan e. Dans les environnements où de nombreux

hangements peuvent intervenir, eux- i doivent être pris en ompte. Pour ela, un support

adaptable de la dupli ation pouvant êtreadapté dynamiquement selon les hangements

sur-venant dansl'environnement semble toutà faitapproprié.

En on lusion,notre obje tif estde donnerlapropriété d'adaptabilité à l'aspe t

dupli a-tion, souslaformed'un anevasadaptable deservi esdedupli ation.Parlasuite, e anevas

pourraêtreutilisédemanièrestatiqueoudynamiqueand'adapteretde onstruireunservi e

de dupli ation approprié.

1.4 Démar he et ontributions de notre travail

Classi ation des proto oles de dupli ation.

Lesproto olesdedupli ationexistantsdanslalittératuresontnombreuxet variés.Ils

dié-rent suivant leniveau de ohéren e souhaitéentre les opies ( ohéren e forte, ohéren e plus

ou moins aaiblie), l'environnement (dupli ation de serveurs, dupli ation dans un ontexte

mobile omposé d'assistants personnels, et ) et le domaine (systèmes de ommuni ation de

groupe, systèmes de gestion de bases de données réparties, mémoires partagées réparties).

Cependant, nous avons dégagé leurs points ommuns an de pouvoir les omparer. Ainsi,

nous proposons une grille de lassi ation des diérents proto oles de dupli ation existant

danslalittérature.

Nous avons également dégagé les spé i ités propres à haque domaine : par exemple

lestransa tionspourles systèmesdegestionde basesdedonnéeset lesmodèles de ohéren e

1

Un anevasdénitlastru turegénéraled'uneappli ationgénérique[Joh97 ,Rog97 ℄.Ilpermetdespé ier desdé isionsde on eptionetildoits'adapteràtoutesles appli ationsd'undomainedonné.Ilestinstan ié and'obteniruneappli ationparti ulièrerépondantauxbesoins.

pourles mémoirespartagées réparties.

RS2.7, un anevas de servi es de dupli ation.

Etant donné la di ulté de mettre en ÷uvre la dupli ation, des travaux proposent déjà

des supports adaptablesde dupli ation. Nousavons mis en lumière ertaines limites de es

supports :

 D'unepart, l'isolationde ladupli ation par rapportauxaspe ts nonfon tionnels n'est

pas laire. Il enrésulte, biensouvent,unmanque d'adaptabilité dusupportde

dupli a-tionpar rapportà esaspe ts.Il estdi ile,voir impossible,d'utiliser lesupportdela

dupli ation dansdivers ontextesnon fon tionels ( ontextetransa tionel, ontextedes

mémoirespartagéesréparties, et ).

 D'autre part, on remarque le manque d'adaptabilité du support dans tout ou partie

des proto oles de dupli ation oerts. Bien souvent, il n'est pas possible de hanger

uniquement ertaines fon tionnalités du proto ole an d'en obtenir de nouvelles plus

appropriées.

Ces onstatations nousont onduitvers ladénitiond'un anevasdeservi esde

dupli a-tion, nommé RS2.7

2

. Nos ontributions portent surtroisaxes : lamodélisation desservi es

dedupli ation pouvantêtre obtenusàpartir deRS2.7,l'adaptabilitédu anevasparrapport

au ontextenonfon tionneletl'adaptabilitédanstoutoupartiedesproto olesdedupli ation.

Au vu de l'état de l'artsur les supports adaptablesde la dupli ation, on noteégalement

qu'iln'y apas onsensussurleur rleet leservi equ'ilsdoivent rendre. Ainsi,nousretenons

omme noyau minimal d'un servi ede dupli ation deux tâ hes : lagestion du y le de vie

desdiérentes opiesd'unmêmeobjetetlagestiondelamiseen ohéren e de elles- ilorsque

'estné essaire(nousappelons edeuxièmepointproto olede ohéren elo aledanslasuite).

Toute autretâ he n'est pasdu ressortd'un servi ede dupli ation.

Modélisation des servi es de dupli ation.

RS2.7 permet d'obtenir des proto oles de ohéren e lo ale variés orrespondant à divers

besoins. Par exemple, pour mettre en ÷uvre la toléran e aux fautes il est né essaire d'avoir

une ohéren e forte entre les diérentes opies, alors que pour améliorer les performan es il

peutêtre a eptabledelaisserdivergerlégèrement elles- i.Ande ara tériserles diérents

types de servi es pouvant être oerts par RS2.7 nous dénissons la notion de modèle de

ohéren e lo ale. Un modèle de ohéren e lo aleest la dénitionde omment l'utilisateur

perçoitles diérentes opies d'un même objet.Nous avons formaliséquatre typesde modèle

représentant, à notre avis, l'ensemble des situations envisageables. Ces quatre typesde

mo-dèle sont : les modèles à opie unique, les modèles à opies divergentes, les modèles à opies

2

RSsontles initialesdelatradu tion anglaise deServi esdeDupli ation (Repli ationServi es). RSest égalementlenomd'unmodèledePors he911appeléaussiRS2.7(voirannexeA).

onvergentes ave le turesurles opies divergenteset lesmodèles à opies onvergentes ave é riture surles opies divergentes.

Cha un de es modèles fait ressortir desbesoins parti uliers en e qui on erne d'autres

aspe tsnon fon tionnels.C'est lepremierniveau d'intera tionentreladupli ation et les

autresaspe tsnonfon tionnels.Parexemple,pourlemodèleà opieunique,ilestné essairede

garantirquelesmisesàjourentrelesdiérentes opies peuventsefairedemanièreatomique.

Ainsi,nousavons lairementdénitlerlede ha undesaspe tsintervenantlorsdelagestion

de la ohéren e des opies d'un objet logique, ainsi que les intera tions existant entre eux,

an depouvoir lesadapter lesuns par rapportaux autres selonles besoins.

Adaptabilité de RS2.7 par rapport au ontexte non fon tionnel.

Traditionnellement, le développeur d'une appli ation s'appuie sur un modèle de

ohé-ren e globalespé iantplusoumoinsformellementlamanièredontse omportelamémoire

ou les données suivant le ontexte. Ces modèles sont implantés par des proto oles gérant les

objets en prenant en ompte la on urren e, latoléran e auxfautes ou bienen ore la

dupli- ation.Cependant onpeut remarquerque es diérentsaspe ts non fon tionnels setrouvent

mélangés dans leproto ole de ohéren e globale. Ce i limite l'évolution du ode et sa

réuti-lisabilité. En eet, un proto ole de ohéren e globale doit être repensé si la dupli ation est

introduite et ré iproquement, par exemple, la partie gérant ladupli ation doit être revue si

le ontrle de on urren e hange.

Notreobje tif étantlaséparation despréo upations, nousavonsisolé ha undesaspe ts

non fon tionnels et plus parti ulièrement l'aspe t dupli ation à l'intérieur des proto oles de

ohéren e globale. Ainsi,en présen ede donnéesdupliquées, noussoutenonsqu'un proto ole

de ohéren e globale est onstitué, entre autre, d'un proto ole de ohéren e lo ale.

Cepen-dant, il est né essaire de dénir les intera tions possibles entre un proto ole de ohéren e

lo ale et les autres aspe ts non fon tionnels parti ipant à la onstru tion du proto ole de

ohéren e globale.Enfaisant ainsi,ildevient possibled'adapter leproto ole de ohéren e

lo- ale auproto olede ohéren e globale. Ainsi, notreappro he permet d'adapter un proto ole

de ohéren e lo ale an qu'ilpuisseêtre utilisé dansun ontextetransa tionnel, demémoire

partagées réparties,et . De plus, nousproposons une formalisation de la ohéren e entre les

opies.Cetteformalisationnouspermetdemontrerqu'unmêmeproto olede ohéren elo ale

peut êtreréutilisé pour mettre en÷uvrediérentsproto oles de ohéren e globale.

Cettepositionestnovatri e ardanslesdiérentsdomainesutilisantladupli ationilexiste

lanotiondemodèlede ohéren e globale(séquentiel, ausale,PRAM,paresseusedansles

mé-moirespartagéesréparties,sérialisabilitésurune opiedanslesSGBDrépartis),mais ellede

ohéren elo alen'apasétémiseenéviden e.Ainsi,danslespropositionsa tuelles,lagestion

de la dupli ation n'apparaît que dans les proto oles de ohéren e globale. Elle se retrouve

englobée danslagestionde données ( on urren e, répartition, et ) limitant l'adaptabilité de

Adaptabilité dans tout ou partie des proto oles de dupli ation.

Notre analyse de l'état de l'art sur les te hniques de dupli ation nous a permis d'extraire

diérentes phasesque l'onretrouve dansde nombreux proto oles. Ainsi,nousproposons une

dé omposition stru turellesouslaformed'un proto oleabstraitde ohéren e lo ale

om-posé de inq phases : une phase d'a ès, de oordination, d'exé ution, de validation et de

réponse.Ladiéren eentrelesproto oles estdue àlamanièredont haquephaseest

implan-tée et l'ordre dans lequel elles apparaissent. Dans ertains as, desphases sont inexistantes,

ou ilpeut yavoir desbou les, ou bienen oreelles peuvent agir enparallèle.

Apartir delagrillede lassi ationdesproto olesdedupli ation,onremarqueégalement

que les diérents proto oles proposés dans la littérature ont en ommun ertaines

fon tion-nalités: momentde dé len hement delasyn hronisation,déte tion etrésolution des onits,

gestionnaire de rle des opies, et . Ainsi nousproposons une ar hite ture fon tionnelle

isolant les diérents omposantsintervenant dansun proto ole.

Ces fa torisations stru turelle et fon tionnelle des proto oles de ohéren e lo ale, nous

permettent d'obtenir l'adaptabilitéet laréutilisabilité dansles proto oles.

Enrésumé,notretravailportesurla ompréhensiondel'aspe tdupli ationetdelaproposition

depointsd'adaptabilitépour elui- i.Nousproposonsl'aspe tdupli ationsousformedeboîtes

blan hes.Ainsi,notretravailpeutêtrevu ommelepointdedépartdetravauxplusgénéraux

dudomaine delaséparationdespréo upationsportantsurla ompositiond'aspe ts.Depart

le fait que nous ouvrons l'aspe t dupli ation, il devient possible de omposer plus nement

les diérentsaspe ts non fon tionnels et d'optimiser ette omposition.

RS2.7 a été mis en ÷uvre. Le prin ipe essentiel de la mise en ÷uvre est la onstru tion

de haînes de liaison entre les diérentes opies d'un même objet. Ces haînes de liaison

implantent un ertain proto ole de ohéren e lo ale et une ertaine gestion du y le de vie.

Une haînedeliaisonimplantedon uneinstan edeRS2.7,etdon unservi ededupli ation.

Ellessont onstruites enprenant en ompte :

 Lesintera tions ave lesautres aspe tsnon fon tionnelsan degarantir lesmodèles de

ohéren e lo ale.

 Lesintera tions ave les autresaspe tsnon fon tionnels an departi iper à lamiseen

÷uvredesmodèles de ohéren e globale.

 La dé omposition stru turelle et ladé omposition fon tionnelleproposées.

Notrevalidationportesurladémonstrationdes ara téristiquesd'adaptabilitéoertespar

RS2.7.Notreobje tifn'estpasd'obteniruneimplantationperformante, arnousdé omposons

aumaximumlesproto oles de ohéren elo ale. Nous her honsàmontrerqueRS2.7permet

d'obtenir des servi es très variés et onvenant pour divers ontextes non fon tionnels. Nous

avonsutilisé desservi esde dupli ationobtenus àpartirde RS2.7dansle ontexteduprojet

1.5 Plan de la thèse

Ce do ument estorganisé selontrois parties:

1. La première partie assoit la problématique de ette thèse. Elle est omposée de deux

hapitres.Dansunpremier hapitre ( hapitre 2),nousprésentonslesdivers on epts et

te hniques dedupli ation existants. L'état de l'artembrasse troisprin ipaux domaines

de l'informatique répartie : les mémoires partagées réparties, les systèmes répartis à

ommuni ation de groupe et les systèmes transa tionnels. Dans un se ond hapitre

( hapitre 3), nous présentons quelques travaux proposant ertaines formes

d'adapta-bilité dans lesupport de la dupli ation. Ce inous permet de mettre en éviden e leurs

points positifs, mais surtout leurs limites : le manque d'adaptabilité au ontexte non

fon tionnelet dansleservi erendu.

2. La deuxième partie présente noséléments de solution. Elle omporte quatre hapitres.

Tout d'abord, dans un premier hapitre ( hapitre 4) nous dénissons le rle de notre

anevasadaptablededupli ation.Dansunse ond hapitre( hapitre5),nousdénissons

les diérents types de servi es pouvant être obtenus à partir de RS2.7. Puis, dans le

hapitre suivant ( hapitre 6), nousprésentons de quelle manièreRS2.7 peut s'adapter

à diérents ontextes non fon tionnels. Ensuite ( hapitre 7), nous montrons omment

nousproposonsde fa toriserlafon tionnalitédupli ation an quenotre anevaspuisse

orirl'adaptabilité danstoutou partie desservi esrendus.

3. La troisièmepartie traite dela validation de nospropositions.Cette partie se ompose

d'un hapitre ( hapitre 8).Tout d'abord, nousprésentons lamiseen ÷uvredu anevas

proposé, puis nous mettons en valeur le gain obtenu par rapport à l'existant an de

validernospropositions.

Le dernier hapitre ( hapitre 9) dresse un bilan du travail réalisé et évoque un ertain

nombre de perspe tives.

Inventer en toute hose, 'est vouloir mourir à petitfeu; opier, 'estvivre.

Con epts et te hniques de dupli ation

Sommaire

2.1 Points remarquablesdes proto oles de dupli ation . . . 30

2.2 Dupli ation à l'aide de systèmesde ommuni ation de groupe . 40

2.3 Dupli ation dans les systèmes de gestion de bases de données

réparties . . . 51

2.4 Dupli ation dans lesmémoires partagées réparties . . . 61

2.5 Con lusion . . . 69

U

nsystèmeréparti,qu'ilsoitdéployésurunréseaudédié(" lusters",serveursparallèles), surun réseau d'entreprise (support au "workow"), ou sur le réseau mondial (support

auxsystèmes de réservationou auxjeuxsur Internet)né essitedu partage deressour espar

ses diérents omposants. Les te hniques de partage qu'il utilise sont souvent basées sur la

dupli ation d'informations et/ou de servi es. Dans e ontexte, un même objet

1

peut être

dupliqué en autant de opies que né essaire, haque opie étant détenue et a édée par un

ou plusieurs pro essuss'exé utant danslesystème. Cependant, si ladupli ation améliore les

performan es et latoléran eauxfautes,lemaintien dela ohéren e entre les opies n'estpas

hoseaisée.Desproto olessedoiventdegarantirune ertaine ohéren eentreles opies selon

l'obje tif re her hé.

Trois grands domaines de l'informatique se sont parti ulièrement intéressés à la

dupli- ation : les systèmes de ommuni ation de groupe (SCG), les systèmes de gestion de bases

de données répartis (SGBDR) et les mémoires partagéesréparties (MPR). Cependant, nous

pouvonsremarquerquemalgré lenombre important de travauxil n'ya quetrès peude

rap-pro hement entreeux.Ainsi, l'obje tifde e hapitre estdefaireunesynthèsedesprin ipaux

1

Nous entendonsobjet ausens large, un objet peut être unepagemémoire, une relationd'une base de données,unserveurdenoms,et .

résultats obtenus dans es domaines en matière de support à la dupli ation, an de mieux

dégager les on epts sous-ja ents essentiels. Cette étude nous permet de voir quels sont les

points ommuns des diérents proto oles, ainsique les spé i itésde haquedomaine. Nous

ne traitons pas les systèmes à objets répartis (SOR) dans etétat de l'art, ar biensouvent

onyretrouvelanotiond'a tionatomiqueéquivalente auxtransa tionsetnouspréféronsnous

fo aliser sur les SGBDR. Cependant, nousles traitons dans le hapitre suivant ( hapitre 3)

pourl'adaptabilité qu'ilsorent.

Le hapitreestorganisédelamanièresuivante.Nous ommençons(se tion2.1)par

présen-terlesprin ipales ara téristiquesdesproto oles dedupli ation nousparaissant importantes.

La mise en éviden e de es ara téristiques nous ore des points de omparaison entre les

proto oles proposés dans les diérents domaines de la littérature. Ensuite, nous présentons

la dupli ation dansles SCG (se tion 2.2), dans lesSGBDR (se tion 2.3) puis dansles MPR

(se tion 2.4). Ce hapitre setermine par nos on lusions(se tion2.5).

2.1 Points remarquables des proto oles de dupli ation

Unproto olededupli ationgèrela ohéren e entrelesdiérentes opies d'unmêmeobjet

tout en ayant pour obje tif d'améliorer la abilité des donnéeset/ou les performan es (tant

ené riture qu'enle ture) dusystème. Malheureusement, esdeuxobje tifssont antagonistes

(gure2.1).Pourobtenirunebonneabilité,ilestné essaired'avoirune ohéren eforte equi

pénaliselesperforman es.Al'inversepourobtenirdebonnesperforman esilestné essairede

relâ herla ohéren e, equipénaliselaabilité.Celaestd'autantplusvraiquel'onaugmente

le nombre de opies. En eet, dans le as de la ohéren e forte, un site a ède toujours au

dernier élément de laséquen e globale des é ritures. Ce i peut être réalisé par un proto ole

basé, par exemple,sur unediusion atomique desvaleurs, oupar leverrouillage global dela

donnée avant l'ajout d'un élément à la séquen e. Ces méthodes se basent sur un ordre total

surles é ritures. Par ontre dansle as de la ohéren e faible,on n'assure plus quelavaleur

lue sur un site (la dernière valeur de la séquen e lo ale) est bien la dernière de la séquen e

globale. Cela estgénéralement réalisé par la onstru tion d'un ordrepartiel surles é ritures.

Il estdon né essairede faire des ompromis.

Dénition 2.1 : Cohéren e forte pourobjet dupliqué

Ilya ohéren e forteentreles opiesd'un même objets'ilya ordretotalsurles é ritures faitessur es opies.

Dénition 2.2 : Cohéren e faible pour objet dupliqué

Il ya ohéren e faible entre les opies d'un mêmeobjet s'ilya ordrepartiel sur

Faible

Forte

Elevée

Inexistante

Fiabilité

Totale

Performance

Cohérence

Médiocre

Fig. 2.1Compromis performan e/abilité et réper ussionssurla ohéren e

De e ompromisperforman e/abilitérésultedenombreuxproto olesdedupli ation

met-tant en ÷uvre une ohéren e plus ou moins forte entre les opies que e soit dans les SCG,

lesSGBDRoulesMPR. Ande pouvoir omparerlessolutions proposéesdans esdiérents

domaines, nous présentons dans ette se tion les prin ipales ara téristiques des proto oles

de dupli ationnousparaissantimportantes : nombre de opies on ernéespar une le tureou

uneé riture (se tion2.1.1),droitsd'a ès(se tion2.1.2),moment delasyn hronisation

(se -tion2.1.3), initiativede lamiseàjour (se tion2.1.4), naturedesmisesà jour(se tion 2.1.5), topographiedelasyn hronisation(se tion2.1.6), apturedesmisesàjour(se tion2.1.7),

ges-tion des onits (se tion 2.1.8), prérequis sur leproto ole de ommuni ation (se tion 2.1.9),

gestionde la on urren e(se tion 2.1.10), gestionde latoléran eaux fautes(se tion 2.1.11),

notion de opie (se tion 2.1.12) et transparen e à la dupli ation (se tion 2.1.13). En n de

se tion,nousrésumonsl'ensembledes ara téristiquesprésentéessousformed'unegrille

(se -tion2.1.14).

2.1.1 Nombre de opies on ernées par une le ture et une é riture

Chaqueproto olededupli ationasespropres ontraintessurlenombrede opiesà

onsul-ter avant de pouvoir répondre à une requête externe de le ture ou d'é riture. Par exemple,

ertainsproto oles fontune é rituresurtoutesles opies avantdevaliderunerequêteexterne

d'é riture.Dans e as,ilsn'ontbesoinde onsulterqu'une opiepourrépondreàunerequête

externede le ture.D'autres proto oles valident unerequête externed'é riture lorsquen/2+1

opies sont mises à jour (n est le nombre total de opies). Lors d'une requête externe de

le ture, il est alors né essaire de onsulter n/2 opies pour pouvoir répondre au demandeur.

Lesproto oles implantant esdeuxappro hesontpourobje tif d'assurerune ohéren e forte

entreles opies.Desproto olesrelâ hantla ohéren e peuventé rire(respe tivement lire)sur

une opie lors d'une requête externe d'é riture (respe tivement de le ture). La mise à jour

desdiérentes opies sefaitde manièreasyn hroneparrapportauxrequêtes externes.Ainsi,

suivant leproto ole elui- i peut onsulter une,plusieursou toutesles opiesselon letype de

larequête externe.Deplus leproto ole n'interroge pasfor ément des opies auhasard, mais

2.1.2 Droits d'a és aux opies

La détermination des opies pouvant être modiées par des requêtes externes et elles

pouvantêtreuniquementmodiéesparleproto olededupli ationestunpointessentiel.Deux

appro hes extrêmes existent [GHOS96℄ : l'appro he maître-es laves ou primaire-se ondaire

(master-slave ou primary-se ondary), et l'appro he opies identiques (update anywhere ou

peer to peer).L'appro he maître-es lavesse dénie omme suit :

Dénition 2.3 : Droits demises à jour maître-es lave

Chaque objet dupliqué possède une opie dite maîtresse, les autres étant des

opies es laves. Une requête externe de mise à jour (une é riture) ne peut être

faite que sur le maître, elui- i diusant ensuite les modi ations aux opies

es laves.

Dans la gure2.2(a) la opie maîtresse C1 reçoit les requêtes d'é riture, puis les diuse

aux opies es laves C2, C3 et C4. Les opies es laves ne peuvent re evoir que des requêtes

externes dele ture. Cetteappro he simpliele ontrle de la on urren emaiselle introduit

des en ombrements sur la opie maîtresse et fragilise le système. Des variantes où la opie

maîtressepeuttransférersonrleàuneautre opieau oursdutempspermettentd'améliorer

les performan es (élimination du goulot d'étranglement) ou la toléran e aux fautes (dans le

as où la opie maîtresse est suspe tée de mal se omporter). La politique de transfert de

la maîtrise peut être dé idée de manière déterministe ou indéterministe par des proto oles

de vote par exemple. D'autres variantes proposent qu'il y ait plusieurs opies maîtresses en

même temps.

L'appro he à opies identiques sedénie omme suit :

Dénition 2.4 : Droits demises à jour à opies identiques

Chaque opie d'un objetdupliquépeut traiterdesrequêtes externes d'é riture.

Ave ette appro he, toutes les opies a eptent les requêtes externes d'é riture et de

le ture. Ellesont toutesun omportementde opiemaîtresse.Danslagure2.2(b)les opies

C1, C2, C3 et C4 traitent les requêtes externes d'é riture et diusent ensuite aux autres

opies les mises à jour. Les onits pouvant survenir suite à deux é ritures simultanées sur

deux opies diérentes est leprin ipal point négatif de ette appro he.

2.1.3 Moment de la syn hronisation

Lesmisesàjourdesdiérentes opies peuvent sefairesimultanément surtoutes les opies

ou d'abord sur une et ensuite sur les autres.[GN95 ℄ propose une lassi ation des diérents

Mises

à jour

à jour

Mises

à jour

_Mises

Mises

à jour

Mises

Mises à jour

à jour

Mises

à jour

Mises à jour

(a) Droits mise à jour maitre−esclave

Copie C2

(b) Droits mise à jour n’importe où

Copie

secondaire

Copie

primaire

Copie C1

Copie C3

Copie

Copie C4

secondaire

Copie

secondaire

Fig.2.2 Appro he maître-es laves versus opies identiques

lasses de onditionde ohéren e sont dénies :

Conditions sur le délai.Ces onditions portent sur letemps. Ellesexpriment ladurée

maximalequeleproto olepeutattendreavantlapropagationd'unemiseàjour.Parexemple,

pour un délai maximum de 60 se ondes, toutes les mises à jour d'une opie x doivent être

propagées versla opiex' avant l'expirationde elui- i.Ave ette appro he,seule ladernière

valeurde xpeut êtrepropagée versx'.

Conditions sur la périodi ité. Ces onditions portent également sur le temps. Elles

spé ient qu'une opiex' de xdoitêtre miseà jour ave ladernièrevaleur de xtoutes les m

unités de temps,quexaitété modiéeou non.L'avantage de ette appro he surlapremière

est que les pertes de messages de mise à jour dues au réseau ou aux pannes de site sont

é artées.

Conditions sur le moment. Ces onditions, introduites par [WQ87 , WQ90 ℄, sont un

as parti ulier des onditions de périodi ité. Elles spé ient qu'une opie x' de x doit être

miseàjour àun moment donné ave ladernièrevaleurde x,par exemple touslesjoursà8h.

Conditionssurlaversion.Ces onditionsspé ientlenombredemodi ationspouvant

avoirlieu surla opie xavant quela opie x'soit miseà jour.

Conditions numériques. Si la valeur d'un objet est numérique, es onditions

per-mettent de borner la déviation entre les valeurs des diérentes opies. Il est possible de

onsidérer des diéren es absolues, relatives ou exprimées en pour entage. Pour vérier es

onditions ilfaut onnaître lavaleur desdeux opies.

Conditions sur les objets. Ces onditions portent sur la stru ture des objets. Trois

typesde onditions sontdénies :x' doitêtremiseàjourave ladernièrevaleur dexlorsque

(a) au moins i sous objets de la opie x ont été modiés, (b) au moins q pour ent des sous

objets dexont étémodiés ou( ) lesousobjeta dexa étémodié, depuis ladernièremise

àjour dex'.Ces onditions sontparti ulièrement adaptéesauxsystèmes àobjets,maisaussi

Copie C4

(a) Rafraichissement de type push

Copie C1

Copie C3

Copie C3

Copie C2

Copie C4

Copie C2

Copie C1

(b) Rafraichissement de type pull

Fig. 2.3 Rafraî hissement de type push et pull

objets sous objets existent aussi entre les relations et les attributs, entre les relations et les

n-uplets ou en ore entreles n-uplets et les attributs. Par exemple, pour une opie x' qui est

une relation en le ture seule servant pour faire des al uls statistiques, il est raisonnable de

ne mettreà jour x'quesi plusde q% desn-upletsde xont hangé.

Conditions événements. Finalement, le dé len hement des mises à jour des opies

peuvent être dirigées par des événements. Cette lasse de onditions est la plus générale.

Un modèled'événementsassez ri he permettrait d'exprimerles onditions pré édentes.

2.1.4 Initiative de la mise à jour

Les opies possédant l'information permettant de faire une mise à jour sont appelées

opies sour es,alorsqueles opiessurlesquellesdoiventêtre propagéeslesmodi ations sont

appelées opies ibles. Deux appro hes pour le rafraî hissement des opies sont possibles.

Soit la opie sour e est l'initiatri e des propagations (gure 2.3 (a)), soit les opies ibles

demandent lesmises àjour à une(aux) opie(s) sour e(s) (gure2.3 (b)).

Dénition 2.5 : Rafraî hissement de type push

Propagationdesmisesàjouràl'initiativedela opiesour eversles opies ibles.

Dénition 2.6 : Rafraî hissement de type pull

Propagationdesmises à jourà l'initiative dela opie ible.

Ave la première appro he, la opie sour e diuse à toutes les opies ibles les mises à

jour. Dans ertains as, ela peut poser des problèmes de passage à l'é helle. Des messages

inutiles de syn hronisation peuvent être envoyés à des opies qui ne seront pas onsultées.

modi ations ou en les regroupant. Par ontre, les opies ibles ne savent pas si une mise à

jour est né essaire. De plus, si elles interrogent trop souvent la opie sour e ette appro he

peut s'avérer inintéressante.

2.1.5 Nature des mises à jour

La naturedesmisesàjourdésigne letyped'information envoyéauxdiérentes opies lors

de la syn hronisation. On distingue deux appro hes: les proto oles à diusion desé ritures

et les proto oles àinvalidation [EK89 ℄.

Dénition 2.7 : Proto ole à diusion des é ritures

Unproto oleàdiusiondesé rituresenvoielesmodi ationsfaitessurune opie

auxautres opies.

Dénition 2.8 : Proto ole à invalidation

Suiteàlamodi ationd'une opie,unproto oleàinvalidationenvoieauxautres

opiesunenoti ationlesinformantqu'ellessontinvalidesetnedoiventplusêtre

a édées.Avant depouvoirdenouveau êtreutilisée,les opiesinvalidées doivent

êtreresyn hronisées.

Pour les proto oles à diusion des é ritures, deux as sont envisageables : soit il y a

transfertdesétats(oud'un delta),soit lapro édureexé utéesurlasour epeutêtrepropagée

vers le site ible pour y être exé utée (dupli ation des opérations). Dans ertains as, la

deuxième appro heévite letransfert d'importantsvolumes dedonnées.

Les proto oles à invalidation permettent de limiter la taille des messagesé hangés entre

les diérentes opies, alors que les proto oles à diusion des é ritures augmentent le tra

et les risques d'engorgement sur le médium de ommuni ation. De plus, le travail que doit

fournir haque opieestplusimportant, elles- idevant installerlesmisesàjour.Cependant,

elles- i sont moinsen retardque dansle asdesproto oles à invalidation.

2.1.6 Topographie de la syn hronisation

Bien souvent, la opie devant propager une mise à jour le fait par diusion à toutes

les opies (gure 2.4 (a)). D'autres proto oles propagent les mises à jour de opie en opie

(gure2.4(b))ouversunensemblede opies où ha uned'elles lespropagentàleurtourvers

un autre ensemble (gure 2.4 ( )). Certains proto oles onstruisent des heminsparti uliers

entre les opies que doivent suivre les mises à jour (gure 2.4 (d)). On peut ainsi imaginer

(d)

(c)

Copie C4

Copie C1

Copie C2

Copie C3

Copie C6

Copie C1

Copie C4

Copie C3

Copie C6

Copie C1

Copie C2

Copie C3

Copie C4

Copie C5

Copie C2

Copie C3

Copie C1

Copie C4

Copie C5

Copie C6

Copie C5

Copie C5

Copie C2

Copie C6

(a)

(b)

Fig. 2.4Diérentes topographiesde propagationdesmises àjour

Ces diérentsproto oles sejustient quanddes opies (ou desgroupes de opies)doivent

être mises à jour avant d'autres ou qu'il est avantageux de s'appuyer sur latopographie du

réseau.

2.1.7 Capture des mises à jour

Le mé anismeutilisé pour déte teret séle tionner les hangements sur une opie an de

les propager aux autres opies est appelé la apture. Il peut s'implanter de diverses façons.

Une manière de faire onsiste simplement à onsulter la opie an de onnaître son dernier

état.

Une deuxième façon defaire onsiste àenregistrer lesmodi ations surunsupport

parti- ulier:unjournal(logsning)ouune opieombre(shadow).Danslepremier ason onsigne

dansunjournal lesrequêtes modiant une opie oulanouvellevaleur dela opie.

L'in onvé-nient est qu'ilfaut modier lagestion dujournal pour qu'il tienne ompte de ladupli ation.

Une opie ombre est une  opie de la opie. Elle permet degarder une tra e de lavaleur de

la opieavant lesmodi ations. Cetteappro he estsurtout utiliséepour fairede latoléran e

auxfautes(pourpouvoirrevenirenarrièresiunproblèmesurvient),maisellepeutaussiêtre

utiliséepour déte teret séle tionner lesdernières modi ations.

Unetroisièmeappro he onsisteàdé len herunmé anismeparti ulier:untrigger

dupliquée dé len he un trigger. C'est un mé anisme général et extensible. Ave la deuxième

te hnique, un appel expli ite à une API parti ulière permet d'informer de l'exé ution d'une

modi ation.

2.1.8 Gestion des onits

Dans ertains proto oles deux opies peuvent être modiées de manière on urrente.

Lorsqueleproto oledésiresyn hroniserles opies(pasfor émentimmédiatement),ilsetrouve

fa e à un onit. Dans e as de gure, il doit être à même de déte ter le onit et de

ré- on ilier les diérentes opies an de ne pas perdre de modi ation ou de ompromettre sa

sémantique.

Dénition 2.9 : Déte tion d'un onit

Lors du fon tionnement normal du proto ole de dupli ation, la déte tion des

onits estl'a tion de déte ter à posteriori desa ès oni tuels sur diérentes

opies

Dénition 2.10 : Ré on iliation d'un onit

Suite à la déte tion d'un onit, la ré on iliation est l'a tion de supprimer un

onit ande rendre sasémantique auproto olede dupli ation.

Ondistinguedeuxappro hespourladéte tionetlaré on iliation :l'appro hesyntaxique

et l'appro he sémantique [DGMS85 ℄.

2.1.9 Intera tions ave le proto ole de ommuni ation

Il existe divers proto oles de ommuni ation orant diérentes garanties (ordre,abilité,

et .) dontles proto oles dedupli ation peuvent tirerparti.Si leproto olede ommuni ation

ne fournit pasune garantie susante, leproto ole de dupli ation doiten tenir ompte.

Le passage de message point à point. Le passage de message repose sur deux

pri-mitives : envoyer (send) et re evoir (re eive), sur lesquelles il est possible d'avoir ertaines

garanties de abilité ou d'ordre. Laabilité est un ritère dé rivant lafaçon dont lesystème

réagiten asdedéfaillan ed'un analde ommuni ationoud'unpro esseur(tamponspleins,

perte de messages, ...). Dans le as non able, le système ne fournit au une garantie sur le

bona heminementdumessage.Dansle asable,lesystèmegarantit lalivraisondumessage

(s'il y a perte de message, il signal une erreur). Il existe plusieurs types d'ordre de livraison

desmessages : sans ordre, ordre FIFO(First In, First Out) et l'ordre ausal.Sans ordre, un

P2aprèslemessagem2.L'ordre FIFO onserve l'ordred'émissiondepuis unmêmeémetteur.

Cependant, iln'yaau une garantie surl'ordredesmessagestransitant parun troisième

pro- essus. L'ordre ausalpermet d'ordonner lalivraison desmessagesen fon tion d'unerelation

de ausalité. Informellement, ela signie que si un évènement E' est ausé ou inuen é par

un évènement E, alorstout lesystèmedoitobserver l'évènement Eavant l'évènement E'.

Passage de messages de un vers plusieurs ( ommuni ations de groupe). Un

pro essus peut également envoyer un message à un groupe onstitué de n destinataires (les

membres).Uneprimitiveréalisantl'envoid'unmessageàungroupeestappeléemulti ast.On

peutdénirdemanièreinformelleunediusionable ommesuit:lesdestinataires orre ts

re-çoiventlemêmeensembledemessages(propriétéd'a ord), etensembledemessages ontient

touslesmessagesprovenant d'émetteurs orre ts(propriétédevalidité)etenniln'existepas

dans etensembledesmessagesnonémis(propriétéd'intégrité).Desvariantes uniformesdes

propriétés d'a ord et d'intégrité dénissent le omportement des pro essus quand ertains

messagessontdélivrésàdespro essusfautifs[HT93 ℄.Laabilitéétantdi ilementréalisable

dansle asde la ommuni ation degroupe, beau oup desystèmes fournissent desprimitives

de ommuni ationnonables.L'envoidemessagesversungroupedepro essusajouteune

di-mensionsupplémentaire àl'ordredelivraisondesmessages: l'ordredelivraisondesmessages

surunmembre dugroupepar rapportà l'ordredelivraisonsur haquemembre.L'ordre total

estunordreoùtouslesdestinatairesreçoivent lesmessagesdanslemême ordre.C'estune

di-mensionsupplémentaire, arunordretotal negarantitpasfor ément l'ordreFIFOoul'ordre

ausal.Ainsi,ilexistedesdiusionsFIFOtotalesetdesdiusions ausalestotales[HT93℄.Une

diusion able respe tant un ordre total est appelée une diusion atomique. La sémantique

de livraison détermine quand la diusion d'un message est onsidérée omme réussie pour

l'émetteur. Il en existe prin ipalement trois : quand k destinataires l'ont reçue (k-delivery),

quandunemajoritédesmembresdugroupel'ontreçue(quorums) ouquandtouslesmembres

nonfautifsont reçulemessage(dansle as ontraire, au und'entreeuxnedoitl'avoirreçu 2

).

Appel de pro édures à distan e. Dans un système réparti asyn hrone il n'est pas

possible de diéren ier une ma hine lente d'une défaillan e. Si l'appelant réémet pensant à

unedéfaillan e,alors quelama hineestseulementlente, lapro éduresera exé utédeux fois.

[Nel81 ℄ envisage trois sémantiques pour les RPC : au moins une fois, au plus une fois ou

exa tementune fois.Tout ommeilexiste des ommuni ations degroupe,ilexiste desappels

de pro édures à distan e qui provoquent n exé utions sur diérentes ma hines. L'appelant

est soit bloqué jusqu'à e que les n réponses lui parviennent (MultiRPC [SS90 ℄), soit il a la

possibilitéd'exé uter du ode entre haqueréponse(PARPC [MBBP89 ℄).

L'invo ation de méthodes à distan e (Remote Method Invo ation, RMI) est un appel

de pro édures à distan e dans un ontexte objet. Les mêmes ara téristiques, remarques,

avantages et in onvénients que pour les appels de pro édures à distan e s'appliquent aux

invo ationsde méthodes àdistan e.

2

2.1.10 Gestion de la on urren e

Unobjetdupliquépeutêtrea édésimultanémentparl'intermédiairedediérentes opies.

Suivant le proto ole de dupli ation, diérentes situations sont possibles. Un objet dupliqué

peut êtrea édé par :

 Plusieurs le teursou un é rivain àun moment donné.

 Plusieurs le teursou plusieurs é rivains enmême temps sur des opies diérentes.

 Plusieurs le teurset uné rivainen même temps surune opiediérente.

 Plusieurs le teurset plusieursé rivains en même temps surdes opies diérentes.

2.1.11 Gestion des fautes

Certains proto oles de dupli ation sont à même de supporter les fautes survenant surles

opies et d'autres non.Quatre typesde fautessurles opies peuvent survenir :

 lesfautes par arrêt : la opies'arrête prématurément de façon dénitive.

 les partitions réseau : les opies onstituant l'objet dupliqué se retrouvent dans deux

sousgroupesne pouvant plus ommuniquer entre eux.

 lesfautes par valeur : une valeurn'appartient plusau domaine desvaleursattendues.

 lesfautes byzantines : la opie aun omportement imprévisible.

Généralement la toléran e aux fautes dans un proto ole de dupli ation omporte deux

aspe ts : la déte tion des fautes et la ré upération. Bien souvent, pour les fautes par arrêt

ou les partitionsréseau, ladéte tion se faitquand une opie ne répond plus. Pour les fautes

par valeur oubyzantine, ellesefaitpar desalgorithmesdevote.Dans e as,ilestné essaire

de dupliquerles traitements. Une foislafaute déte tée,la opiein riminée estsupprimée du

groupe des opies géré par leproto ole jusqu'à e qu'elleretrouveun omportement normal.

Des traitements peuvent alors être né essaires an de retrouver une onguration normale

pour le proto ole (éle tion d'un nouveau maître, ré-exé ution de traitements sauvegardés et

non exé uté sur toutes les opies, et .). Avant de réintégrer une opie ayant à nouveau un

omportement normal au groupe, il est né essaire qu'elle rattrape son retard sur les autres

opies.

Rappelonsqueladupli ation permet également derendretolérantauxfautesunsystème.

Dans e as, elle estun mé anismepour assurerlatoléran e auxfautes.

2.1.12 Notion de opie

Suivant les proto oles, la notion de opie peut être diérente. Certains proto oles de

dupli ation ne savent pas e qu'est une opie. Ils s'en remettent à l'appli ation pour réer

et détruire les opies. De plus, un objet peut référen er d'autres objets. Suivant les as, il

Diérentsmodèlesde donnéessontégalement à onsidérer :orienté objet,relationnel,  hier,

autre ou ouvert. Le terme ouvert signie que le proto ole supporte diérents modèles. Il

estégalement né essairede dé ider ombiende opies danslesystèmesontné essaires,oùles

mettre,àquelsmomentsen réerdenouvelles.Cetteallo ationdes opiespeutêtredynamique

ou statique.

2.1.13 Transparen e à la dupli ation

Le proto ole de dupli ation peut orir plus ou moins de transparen e à l'appli ation. Il

y a transparen e à la dupli ation si l'appli ation n'a pas ons ien e du fait que les objets

sont dupliqués. L'appli ation manipuleles objets dupliqués omme des objets lassiques; on

parle d'objets logiques. S'il n'y a pas transparen e à la dupli ation, l'appli ation manipule

expli itement haque opie. Onparle alorsd'objets physiques.

Dénition 2.11 : Objetlogique

Un objet logique est une abstra tion représentant l'ensemble des opies d'un

même objetdupliqué. Cette abstra tion permet deréféren er l'ensembledes

o-pies sousune seule désignation.

2.1.14 Grille de omparaison des proto oles de dupli ation

Le tableau2.5résumelesdiérentes ara téristiquesdesproto olesdedupli ation

présen-tées dans ette se tion.

Dans lesse tionssuivantes,nousprésentonsles proto oles dedupli ation utilisésdansles

SCG, lesSGBDR et les MPR. La grilleproposée nouspermet de omparerles proto oles de

ha un de es domaines. De plus, nous montrons que haque domaine introduit ses propres

spé i ités.Nous n'abordonspassi es proto oles peuvent réer des opies, e qu'ilsfontdes

référen es, le modèle de données et si la réation des opies est dynamiqueou statique. Ces

pointsne nousintéressent pasdire tement danslasuite de e do ument.

2.2 Dupli ation àl'aide desystèmesde ommuni ation degroupe

Cette se tion présente omment mettre en ÷uvreladupli ation àl'aide d'un système de

ommuni ationdegroupe.Unsystèmede ommuni ationdegroupeproposedesprimitivesde

ommuni ationpermettantdediuserdesmessagesversdesgroupesave diérentesgaranties

deabilitéetd'ordre.Lesproto oles dedupli ationtirentpartidespropriétésoertespar es