Services auto-adaptatifs pour les grilles pair-à-pair

HAL Id: tel-02883206

https://hal.archives-ouvertes.fr/tel-02883206

Submitted on 28 Jun 2020

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

Bassirou Gueye

To cite this version:

Bassirou Gueye. Services auto-adaptatifs pour les grilles pair-à-pair. Informatique [cs]. Université de

Reims Champagne-Ardenne, 2016. Français. �tel-02883206�

ÉCOLE DOCTORALE SCIENCES TECHNOLOGIE SANTE (547)

THÈSE EN CO-TUTELLE

Pour obtenir le grade de

DOCTEUR DE L'UNIVERSITÉ CHEIKH ANTA DIOP DE DAKAR Discipline : INFORMATIQUE

Et

DOCTEUR DE L’UNIVERSITÉ DE REIMS CHAMPAGNE-ARDENNE Discipline : INFORMATIQUE

Présentée et soutenue publiquement par

Bassirou GUEYE

Le 26 mai 2016

SERVICES AUTO-ADAPTATIFS POUR LES GRILLES PAIR-À-PAIR

Thèse dirigée par M. Ibrahima NIANG, Maître de conférences , Université Cheikh Anta Diop Et par M. Olivier FLAUZAC, Professeur, Université de Reims Champagne-Ardenne

JURY

M. Michel MISSON, , Professeur, à l’Université de Clermont-Ferrand 2 Blaise Pas, , Président

M. Eddy CARON, , Professeur associé, Ens Lyon Ens Sciences, , Rapporteur

M. Ousmane THIARE, , Professeur, à l’Université Gaston Berger, Saint-Louis, , Rapporteur

M. Olivier FLAUZAC, , Professeur, à l’Université Reims Champagne-Ardenne, , Examinateur

M. Ibrahima NIANG, , Maître de Conférences, à l’Université Cheikh Anta Diop, Sénégal, , Examinateur

M. Cyril RABAT, , Maître de Conférences, à l’Université Reims Champagne-Ardenne, , Examinateur

Puisse Dieu, le tout puissant, vous avoir en sa sainte mis´ ericorde !

A ma femme `

A toute ma famille `

Je rend grˆ ace ` a Allah, le Tr` es Mis´ ericordieux, pour m’avoir illumin´ e et men´ e jusqu’ici.

Je tiens ` a exprimer mes tr` es sinc` eres remerciements et toute ma gratitude ` a mes direc- teurs de th` ese Olivier Flauzac, Professeur ` a l’Universit´ e de Reims Champagne-Ardenne et Ibrahima Niang, Maˆıtre de Conf´ erences HDR ` a l’Universit´ e Cheikh Anta Diop de Dakar, pour la confiance qu’ils m’ont accord´ ee en m’offrant l’opportunit´ e de faire une th` ese. Je les remercie ´ egalement de leur soutien, de leur conseils tout au long de ce travail et surtout de l’ind´ ependance qu’ils m’ont donn´ ee dans la r´ ealisation de ce projet tout en ´ etant exigeant pour un travail de qualit´ e. Enfin, je les remercie une nouvelle fois pour leur humanisme et toute l’aide qu’ils m’ont apport´ ee. Qu’ils trouvent dans ce travail l’expression de mon infinie reconnaissance.

J’adresse mes sinc` eres remerciements ` a l’Agence Universitaire de la Francophonie (AUF) pour avoir financ´ e et ainsi permettre la r´ ealisation de cette th` ese.

Je tiens ` a remercier vivement mon encadrant Cyril Rabat, Maˆıtre de Conf´ erences ` a l’Universit´ e de Reims Champagne-Ardenne, pour son aide ` a l’´ elaboration de ce travail.

Un grand merci pour les remarques constructives, les suggestions pointues, les discussions int´ eressantes et les relectures attentives.

J’adresse mes vives remerciements ` a Eddy Caron, Maˆıtre de Conf´ erences HDR ` a l’´ Ecole Normale Sup´ erieure de Lyon et Ousmane Thiar´ e, Professeur ` a l’Universit´ e Gaston Berger de Saint-Louis, pour m’avoir fait l’honneur d’accepter de rapporter cette th` ese et pour toutes les remarques et suggestions constructives pour am´ eliorer la qualit´ e du manuscrit.

Je remercie ´ egalement Michel Misson, Professeur ` a l’Universit´ e de Clermont-Ferrand, pour avoir accept´ e de participer au jury.

Je remercie tout le personnel de la Section Informatique et tout le personnel du Centre de Calcul de l’UCAD. J’associe ` a ces remerciements tous les membres du laboratoire LID.

Je remercie Bamba Gueye pour la lecture et les corrections du manuscrit malgr´ e son ca- lendrier charg´ e. Un grand merci ´ egalement ` a Mandicou Bˆ a pour nos diff´ erents ´ echanges.

Merci aux doctorants, Abel Diatta, Malick Gaye et mention sp´ eciale ` a Papa Dame Bˆ a.

Mahamat Charfadine,Carlos Gonzalez et un grand merci ` a Thierno Diallo. Je remercie

´ egalement les secr´ etaires du CReSTIC pour leur disponibilit´ e et leur sympathie.

Les encouragements de mes amis ´ etaient la bouff´ ee d’oxyg` ene qui me ressour¸cait dans les moments difficile o` u l’on a besoin d’un petit mot, d’un petit geste, aussi humble soit-il, de soutien moral. Je pense notamment ` a ..., je ne les citerai pas, ils se reconnaˆıtront.

J’exprime ma profonde reconnaissance ` a mon cher p` ere et ` a ma ch` ere m` ere. Je suis tr` es fi` ere de vous et je ne cesserai de vous remercier et de prier pour vous. Puisse Dieu, le tout puissant, vous avoir en sa sainte mis´ ericorde !

A tous les membres de ma famille, de pr` es ou de loin, ` a mes sœurs, ` a mon petit fr` ere,

`

a Cheikh Gueye, pour leurs pri` eres et leurs encouragements.

Enfin, je remercie tr` es sinc` erement ma femme Soda, pour son amour, sa tendresse, sa patience, ses encouragements, pour avoir ´ et´ e ` a mes cˆ ot´ es durant les moments difficile et avoir support´ e que je m’´ eloigne d’elle tr` es souvent afin de r´ ealiser ce projet.

MERCI...

La gestion de ressources distribu´ ees ` a l’´ echelle plan´ etaire dans plusieurs organisations virtuelles implique de nombreux d´ efis. Dans cette th` ese, nous proposons un mod` ele pour la gestion dynamique de services dans un environnement de grille pair-` a-pair ` a large

´

echelle. Ce mod` ele, nomm´ e P2P4GS, pr´ esente l’originalit´ e de ne pas lier l’infrastructure pair-` a-pair ` a la plate-forme d’ex´ ecution de services. De plus, il est g´ en´ erique, c’est-` a-dire applicable sur toute architecture pair-` a-pair. Pour garantir cette propri´ et´ e, vu que les syst` emes distribu´ es ` a large ´ echelle ont tendance ` a ´ evoluer en termes de ressources, d’en- tit´ es et d’utilisateurs, nous avons propos´ e de structurer le syst` eme de grille pair-` a-pair en communaut´ es virtuelles (clusters). L’approche de structuration est compl` etement dis- tribu´ ee et se base uniquement sur le voisinage des nœuds pour l’´ election des responsables de clusters appel´ es PSI (Proxy Syst` eme d’Information ). D’autre part, afin de bien orches- trer les communications au sein des diff´ erentes communaut´ es virtuelles et aussi permettre une recherche efficace et exhaustive de service, lors de la phase de structuration, un arbre couvrant constitu´ e uniquement des PSI est maintenu. Les requˆ etes de recherche vont ainsi ˆ

etre achemin´ ees le long de cet arbre. Outre la d´ ecouverte de services, nous avons propos´ e des m´ ecanismes de d´ eploiement, de publication et d’invocation de services. Enfin, nous avons impl´ ement´ e et analys´ e les performances de P2P4GS. Afin d’illustrer sa g´ en´ ericit´ e, nous l’avons impl´ ement´ e sur Gia, Pastry et Kademlia des protocoles pair-` a-pair op´ erant de mani` eres totalement diff´ erentes. Les tests de performances ont montr´ e que le P2P4GS fournit une bonne r´ esistance aux pannes et garantit un passage ` a l’´ echelle en termes de dimensionnement du r´ eseau et ´ egalement de coˆ ut de communications.

Mots-cl´ es : Syst` emes pair-` a-pair, Grilles de services, gestion de ressources, mod´ elisation,

structuration, tol´ erance aux pannes.

Resource management is a key issue for Grid systems which consist of several geogra- phically dispersed virtual organizations. In this thesis, we propose a model for dynamic services management in large-scale peer-to-peer Grid environments. This model named P2P4GS, presents originality not to link peer-to-peer infrastructure to the execution ser- vices platform. In addition, the middleware is generic and can be applied on any peer- to-peer architecture. Meanwhile, the increasing size of resources and users in large-scale distributed systems has lead to a scalability problem. To ensure scalability, we propose to organize the peer-to-peer Grid nodes in virtual communities so called clusters. The struc- turing approach is completely distributed, and only requires local knowledge about nodes neighborhood for election of cluster managers called ISP (Information System Proxy). On the other hand, in order orchestrate communications in the various virtual communities and also enable an efficient service discovery, during structuring process, a spanning tree only constituted of ISP is maintained. Therefore, search queries will be routed along the spanning tree. Besides the service discovery, we proposed service deployment, publica- tion and invocation mechanisms. Finally, we implemented and analyzed the performance of P2P4GS. To illustrate its genericity, we implemented it on protocols which operate in fully different way. These protocols are Gia, Pastry and Kademlia. Performance tests show that, on the one hand, the P2P4GS provides good fault tolerance and ensures the scalability in terms of the clusters distribution and communication cost.

Keywords : Peer-to-peer Systems, Grid services, resources management, modelisation,

clustering, Fault tolerance.

Remerciements i

R´ esum´ e iii

Abstract v

Table des mati` eres vii

Liste des figures x

Liste des algorithmes xi

Liste des tableaux xii

Introduction 1

1 Etat de l’art sur les syst` emes distribu´ es 7

1.1 G´ en´ eralit´ es sur les syst` emes distribu´ es . . . . 8

1.1.1 D´ efinitions . . . . 8

1.1.2 Mod´ elisation d’un syst` eme distribu´ e . . . . 8

1.1.3 Mod` eles de communication . . . . 11

1.1.4 Algorithmes distribu´ es . . . . 13

1.1.5 Notions de panne et de tol´ erance aux pannes . . . . 14

1.1.6 Les mod` eles d’architecture . . . . 17

1.2 Les syst` emes pair-` a-pair . . . . 19

1.2.1 D´ efinition et terminologies . . . . 19

1.2.2 Caract´ eristiques du pair-` a-pair . . . . 20

1.2.3 Architectures de r´ eseaux pair-` a-pair . . . . 22

1.3 Conclusion . . . . 28

2 Les services dans les syst` emes distribu´ es 31

2.1 G´ en´ eralit´ es sur les services . . . . 32

2.1.1 Notion de service . . . . 32

2.1.2 Approche conceptuelle orient´ ee service (SOA) . . . . 33

2.2 Services Web . . . . 36

2.2.1 Contexte . . . . 36

2.2.2 D´ efinitions de la notion de Service Web . . . . 37

2.2.3 Les technologies des Services Web . . . . 38

2.3 Services de grilles informatiques . . . . 44

2.3.1 Concept de grille informatique . . . . 44

2.3.2 Architecture d’une grille . . . . 47

2.3.3 Topologies de grilles . . . . 49

2.3.4 Les services de grille . . . . 50

2.4 Gestion de services dans un environnement de grille informatique ` a large ´ echelle . . . . 52

2.4.1 Objectifs et motivations . . . . 53

2.4.2 M´ ecanismes de d´ ecouverte de services dans les grilles . . . . 54

2.5 Conclusion . . . . 61

3 Sp´ ecifications de services dans un environnement de grille P2P ` a large ´ echelle 63 3.1 Motivations et objectifs . . . . 64

3.2 Sp´ ecifications de P2P4GS . . . . 65

3.2.1 Concepts de bases . . . . 65

3.2.2 Mod` ele d’architecture . . . . 68

3.3 Approche de structuration du syst` eme en communaut´ es . . . . 72

3.3.1 Pr´ esentation de la solution de structuration . . . . 72

3.3.2 Algorithme de structuration . . . . 75

3.3.3 M´ ecanismes d’adaptation ` a la dynamique du syst` eme . . . . 78

3.4 Synth` ese . . . . 80

4 Gestion des services dans P2P4GS 83 4.1 Motivations . . . . 84

4.2 Primitives de gestion de services . . . . 85

4.2.1 Formalisme de notations . . . . 85

4.2.2 Service de d´ eploiement : deploy . . . . 86

4.2.3 Enregistrement d’un service : save . . . . 90

4.2.4 Service de d´ ecouverte : lookup . . . . 91

4.2.5 Invocation et ex´ ecution de service : invoke et exec . . . . 94

4.3 Synth` ese . . . . 95

5 Exp´ erimentation et ´ evaluation de la sp´ ecification P2P4GS 97 5.1 Environnement de simulation . . . . 98

5.2 Description des overlays impl´ ement´ es . . . . 99

5.2.1 Le protocole Gia . . . 100

5.2.2 Le protocole Pastry . . . 101

5.2.3 Le protocole Kademlia . . . 102

5.3 Mesures de performances . . . 104

5.3.1 M´ etriques de performance et param` etres de simulations . . . 104

5.3.2 Performances de la premi` ere approche de structuration . . . 105

5.3.3 Impact du degr´ e minimal requis sur les performances du syst` eme . . 106

5.3.4 Impact des pannes sur la d´ ecouverte de services . . . 114

5.4 Synth` ese . . . 115

Conclusion 117

Bibliographie 121

1.1 Graphe non-orient´ e et graphe orient´ e . . . . 9

1.2 Quelques topologies classiques des syst` emes distribu´ es . . . . 11

1.3 Illustration d’un arbre couvrant du graphe (a) . . . . 12

1.4 La chaˆıne fondamentale des entraves . . . . 15

1.5 Mod` ele client-serveur et mod` ele pair-` a-pair . . . . 17

1.6 Taxonomie des architectures P2P . . . . 22

1.7 Un exemple d’architecture pair-` a-pair d´ ecentralis´ ee structur´ ee [SMK ⁺ 01]. . 26

1.8 Architecture pair-` a-pair hybride . . . . 28

2.1 Mod` ele d’interaction SOA . . . . 35

2.2 Structure d’un document WSDL . . . . 40

2.3 Structure d’un annuaire UDDI . . . . 41

2.4 Structure d’un message SOAP . . . . 42

2.5 Quelques grilles populaires ` a travers le monde . . . . 45

2.6 Architecture d’une grille informatique . . . . 47

2.7 Convergence Grille et Service Web . . . . 52

2.8 M´ ecanismes de d´ ecouverte de services dans un environnement de grille . . . 54

2.9 Architecture de DIET . . . . 56

3.1 Architecture du r´ eseau de recouvrement . . . . 66

3.2 Architecture du syst` eme P2P4GS . . . . 68

3.3 Connexion d’un nœud dans le syst` eme . . . . 73

3.4 Evolution de la structuration et choix d’un PSI passerelle . . . . 74

4.1 Sc´ enario d’ex´ ecution du service S ₆ . . . . 95

4.2 Sc´ enario d’ex´ ecution du service S ₁₀ . . . . 96

5.1 Structure des modules du simulateur OMNeT++ . . . . 99

5.2 Pourcentage de PSI en fonction du protocole P2P et de la taille du r´ eseau . 106

5.3 Protocole Gia : Pourcentage de PSI form´ es en fonction du degr´ e minimal requis (∆ RequiredM inDegree ) et de la taille du r´ eseau . . . 107 5.4 Protocole Pastry : Pourcentage de PSI form´ es en fonction du degr´ e minimal

requis (∆ RequiredM inDegree ) et de la taille du r´ eseau . . . 108 5.5 Protocole Kademlia : Pourcentage de PSI form´ es en fonction du degr´ e mi-

nimal requis (∆ RequiredM inDegree ) et de la taille du r´ eseau . . . 108 5.6 Protocole Gia : Diam` etre de l’arbre couvrant en fonction du degr´ e minimal

requis (∆ RequiredM inDegree ) et de la taille du r´ eseau . . . 110 5.7 Protocole Pastry : Diam` etre de l’arbre couvrant en fonction du degr´ e mi-

nimal requis (∆ RequiredM inDegree ) et de la taille du r´ eseau . . . 110 5.8 Protocole Kademlia : Diam` etre de l’arbre couvrant en fonction du degr´ e

minimal requis (∆ RequiredM inDegree ) et de la taille du r´ eseau . . . 111 5.9 Nombre total de messages ´ echang´ es en fonction du ∆ RequiredM inDegree id´ eal

du protocole P2P sous-jacent et de la taille du r´ eseau . . . 112 5.10 Diam` etre de l’arbre couvrant, en fonction du ∆ RequiredM inDegree id´ eal du

protocole P2P sous-jacent et de la taille du r´ eseau . . . 113 5.11 Taux de succ` es d’une recherche de service en fonction du pourcentage de

nœuds en panne . . . 114

1 A la r´ ^{`</sup> eception d’un message responseStatus(id v , status v ) du nœud v . . . . 76 2 A la r´ <sup>`} eception d’un message updateStatus(id v , status v ) du nœud v . . . . 77 3 A la r´ <sup>`</sup> eception d’un clusterManagement(serviceList v , neighList v ) ou ` a l’expira-

tion de T _timeout . . . . 77 4 A la r´ ^{`</sup> eception d’un message masterRouteManagement(id v ) du nœud v . . . . 78 5 A la r´ <sup>`} eception d’un message responseElection(id v , degree v ) ou ` a l’expiration du

timeout . . . . 80 6 A la r´ ^` eception de la description des contraintes de d´ eploiement depuis le nœud

nodeRequester . . . . 88 7 A la r´ ^` eception d’un message serviceDiscovery(keyReq, constraints, entryP oint,

T T L) depuis le nœud v . . . . 89 8 A la r´ ^{`</sup> eception d’une requˆ ete de recherche serviceQuery depuis le nœud nodeRequester 92 9 A la r´ <sup>`} eception d’un message discoveryRequest(keyReq, serviceQuery, entryP oint,

distance) depuis le nœud v . . . . 93 10 A la r´ ^` eception d’un message discoveryResponse(keyQuery, serviceF indList, distance)

ou ` a l’expiration du temps de recherche . . . . 94

2.1 Synth` ese des diff´ erentes approches de d´ ecouverte de services dans un envi-

ronnement de grille . . . . 60

3.1 Param` etres, variables et structure des messages de P2P4GS . . . . 75

4.1 Param` etres, variables et structure des messages de gestion de P2P4GS . . . 86

5.1 Table de routage d’un pair d’identifiant 10233102 (extrait de Pastry [RD01])102

5.2 Param` etres de simulation pour l’´ evaluation de la sp´ ecification P2P4GS . . 105

Contexte et motivations

Depuis son av` enement, l’Internet a acc´ el´ er´ e le d´ eveloppement d’applications dans tous les domaines. L’´ evolution des syst` emes informatiques a pour effet le d´ eveloppement de nombreuses ressources informationnelles, mat´ erielles et logicielles distribu´ ees, telles que les ressources de calcul et de stockage, les bases de donn´ ees, les divers types d’applications et d’utilitaires, etc.

Parall` element ` a ce d´ eveloppement, les besoins en termes de puissance de calcul, de capacit´ e de stockage, etc. sont de plus en plus grands. Face ` a cette demande croissante de puissance, la communaut´ e informatique s’est int´ eress´ ee aux architectures distribu´ ees

`

a large ´ echelle de type grilles, afin d’offrir des solutions pour le stockage de donn´ ees et le calcul r´ eparti ` a un plus grand nombre d’applications et d’utilisateurs. Le principe des grilles est de mettre en commun des ressources partag´ ees, distribu´ ees et h´ et´ erog` enes [FKT01]. Par le biais des grilles, les utilisateurs ont la possibilit´ e d’acc´ eder ` a des ressources distantes de calcul et de stockage, de lancer des applications qui demandent des ressources inexistantes ou non disponibles localement.

D’autre part, cette ´ evolution des syst` emes informatiques a apport´ e une modification profonde dans la mani` ere d’utiliser les ressources informatiques. En effet, avec l’´ emergence de l’architecture orient´ ee service pour r´ epondre aux probl` emes d’interop´ erabilit´ e, les res- sources informatiques sont de plus en plus expos´ ees sous la forme de services. Cette tendance de l’orient´ ee service s’est manifest´ ee dans le cadre du Web avec notamment les Services Web [CDK <sup>+</sup> 02] mais aussi dans le cadre des grilles informatiques avec les grilles de services. Ces grilles de services visent ainsi ` a d´ efinir des m´ ecanismes pour virtualiser les ressources et les restituer sous forme de services, afin de pouvoir les assembler et les d´ esassembler en fonction des besoins des utilisateurs [FKNT02a].

D` es lors, avec cette d´ emocratisation des grilles, la gestion de ressources g´ eographique-

ment dispers´ ees et disponibles dans plusieurs organisations virtuelles (Universit´ es, insti-

tuts, entreprises, etc.) implique de nombreux d´ efis. En effet, les ressources sont de nature tr` es h´ et´ erog` enes et dynamiques. Une gestion int´ egrale et transparente des ressources est donc n´ ecessaire pour conserver la consistance d’un tel syst` eme. De plus, les demandes en puissance de calcul et en capacit´ e de stockage sont de plus en plus ´ enormes. Le syst` eme doit ainsi ˆ etre en mesure de passer ` a l’´ echelle tout en limitant les coˆ uts de gestion et de communication.

Pour r´ epondre ` a ces exigences, les grilles n’ont pas cess´ e d’´ evoluer en termes d’ar- chitectures qui guident le d´ eveloppement de tous les composants d’une application. En effet, les syst` emes de grilles traditionnelles pr´ esentent des architectures centralis´ ees ou hi´ erarchiques. De telles architectures sont sensibles aux pannes et g´ en´ eralement inaptes ` a passer ` a l’´ echelle [NRNH14, TTP ⁺ 07].

La conception des grilles s’est par la suite orient´ ee vers une approche Pair-` a-Pair (abr´ eg´ e P2P) [FI03, IFN02]. Dans un tel mod` ele o` u chaque entit´ e est ` a la fois client et serveur, les services sont r´ epartis sur l’ensemble des acteurs du syst` eme. De plus, les syst` emes pair-` a-pair offrent de nombreux avantages grˆ ace ` a leurs propri´ et´ es fondamentales et inh´ erentes telles que l’auto-organisation, la tol´ erance aux pannes, le passage ` a l’´ echelle, le changement dynamique de topologie, etc. [ATS04].

On distingue plusieurs mod` eles d’architectures de grille pair-` a-pair ` a savoir, le mod` ele d´ ecentralis´ e structur´ e, le mod` ele d´ ecentralis´ e non-structur´ e et le mod` ele hybride ou super- pair. Chacun de ces mod` eles b´ en´ eficie de plusieurs avantages qu’offrent les syst` emes pair-` a- pair. En effet, suivant l’environnement o` u ces mod` eles s’ex´ ecutent (peu ou tr` es dynamique, homog` ene ou h´ et´ erog` ene, large ´ echelle ou ´ echelle moyenne, etc.), certaines architectures sont plus adapt´ ees que d’autres.

Soulignons que la d´ ecouverte de ressources constitue un des d´ efis essentiels dans un environnement de grille ` a large ´ echelle [NRNH14, TTP <sup>+</sup> 07]. En effet, les ressources d’une grille pouvant ˆ etre distribu´ ees ` a l’´ echelle plan´ etaire, rechercher et localiser un service r´ esolvant un besoin sp´ ecifique devient un enjeu majeur. Il est donc important de tenir en compte les caract´ eristiques de l’environnement des grilles lors du choix du mod` ele d’architecture. Afin d’´ eviter de saturer le r´ eseau, la recherche doit induire le moins de messages possible tout en restant exhaustive. En outre, le m´ ecanisme de recherche doit ˆ etre flexible pour permettre une grande expressivit´ e des requˆ etes utilisateurs.

Contributions

En consid´ erant toutes les motivations ´ enonc´ ees ci-dessus, nous proposons dans cette

th` ese un mod` ele nomm´ e P2P4GS (Peer-To-Peer For Grid Services ), pour la gestion dy-

namique de services dans un environnement de grille pair-` a-pair ` a large ´ echelle.

Ce mod` ele pr´ esente l’originalit´ e de ne pas lier l’infrastructure pair-` a-pair ` a la plate- forme d’ex´ ecution de services. En fait, la couche de gestion de la grille pair-` a-pair est s´ epar´ ee de celle de la localisation et d’invocation de services. Nous faisons dans le cadre de la mod´ elisation le choix de ne pas nous figer sur une architecture pair-` a-pair typique d’ex´ ecution ; mais nous sp´ ecifions les op´ erations de mani` ere d´ etach´ ee. Nous proposons ainsi un mod` ele d’architecture constitu´ e de quatre couches d’abstraction. Ces couches superpos´ ees mettent en ´ evidence les diff´ erents m´ ecanismes sous-jacents ` a l’environnement de grille pair-` a-pair ainsi que les interactions entre les diff´ erentes entit´ es du syst` eme.

De plus, soulignons que le mod` ele P2P4GS est g´ en´ erique, c’est-` a-dire qu’il est ap- plicable sur toute architecture pair-` a-pair. Pour garantir cette propri´ et´ e, ´ etant donn´ e que les syst` emes distribu´ es ` a large ´ echelle ont tendance ` a ´ evoluer en termes de res- sources, d’entit´ es et d’utilisateurs, nous proposons de structurer le syst` eme de grille pair-

`

a-pair en communaut´ es virtuelles aussi appel´ ees groupes virtuels ou simplement clusters.

Cette structuration pr´ esente deux caract´ eristiques int´ eressantes ` a savoir la limitation des communications et le passage ` a l’´ echelle. En effet, comme le soulignent les auteurs de [Bas99, MSC ⁺ 12, SM04], une structuration efficace d’un r´ eseau permet de garder les per- formances satisfaisantes mˆ eme avec l’augmentation de la taille du syst` eme.

Notre approche de structuration est, d’une part, compl` etement distribu´ ee et se base uniquement sur le voisinage des nœuds pour l’´ election des responsables de clusters appel´ es PSI (Proxy Syst` eme d’Information ). En vue de ne pas surcharger les PSI, nous proposons de r´ epartir certaines tˆ aches sur d’autres types de nœuds distingu´ es. Ainsi, lorsqu’un pro- cessus de d´ ecouverte d’un service aboutit, le nœud ayant d´ eclench´ e ce processus devient temporairement, en fonction de ses capacit´ es (CPU, RAM, etc.), PI (Proxy Invoquant ) ou PL (Proxy Localisant ) pour ce service. De cette mani` ere, les nœuds proxys vont assurer collectivement la gestion des ressources partag´ ees.

D’autre part, afin de bien orchestrer les communications au sein des diff´ erentes com- munaut´ es virtuelles et aussi permettre une recherche efficace de services dans le syst` eme, un arbre couvrant constitu´ e uniquement des PSI est maintenu. La particularit´ e de la so- lution est que le processus de structuration du syst` eme P2P4GS et la construction de l’arbre couvrant se font simultan´ ement. Ce qui permet de minimiser le coˆ ut des commu- nications en termes de messages de gestion du r´ eseau overlay. Par ailleurs, les requˆ etes de recherche vont ˆ etre achemin´ ees le long de cet arbre. Ceci permet une recherche exhaustive puisque tous les services partag´ es dans le syst` eme sont index´ es au niveau des diff´ erents PSI constituant l’arbre couvrant.

Outre le m´ ecanisme de d´ ecouverte de services, nous proposons des m´ ecanismes de

d´ eploiement, de publication et d’invocation de services.

Enfin, par le biais de simulations sous OverSim [BHK07], nous avons analys´ e les per- formances du syst` eme P2P4GS. Afin d’illustrer sa g´ en´ ericit´ e, nous l’avons impl´ ement´ e sur des protocoles P2P op´ erant de mani` ere totalement diff´ erentes, ` a savoir Gia [CRB ⁺ 03] (qui construit un overlay non structur´ e), Pastry [RD01] (qui construit un overlay structur´ e en anneau) et Kademlia [MM02] (qui construit un overlay structur´ e en hypercube bien que souvent mod´ elis´ e en arbre).

Les r´ esultats de simulations ont montr´ e, d’une part, que notre solution garantit un passage ` a l’´ echelle en termes de dimensionnement du r´ eseau et aussi de coˆ ut communi- cations. D’autre part, parmi ces trois protocoles P2P impl´ ement´ es, l’intergiciel P2P4GS fournit une meilleure r´ esistance aux pannes lorsqu’il exploite Gia ou Kademlia en tant que protocole P2P sous-jacent.

Organisation du manuscrit

Ce manuscrit est structur´ e en cinq chapitres.

Dans le chapitre 1, nous pr´ esentons le contexte g´ en´ eral dans lequel se place nos travaux,

`

a savoir les syst` emes distribu´ es. Nous d´ ecrivons ainsi les concepts qui les sp´ ecifient. Par la suite, nous pr´ esentons les syst` emes pair-` a-pair qui constituent un mod` ele sp´ ecifique des syst` emes distribu´ es.

Le chapitre 2 est consacr´ e ` a l’´ etude des services ainsi que leurs environnements d’ex´ ecution.

Apr` es avoir d´ efini la notion de service et pr´ esent´ e l’Architecture Orient´ ee Service (SOA), nous mettrons l’accent sur le mod` ele des services Web ; puis celui des services de grilles.

Ensuite, nous faisons un ´ etat de l’art sur les m´ ecanismes de gestion de services dans un environnement de grille. Une synth` ese de ces m´ ecanismes nous permet d’exposer notre probl´ ematique de recherche.

Dans le chapitre 3, nous pr´ esentons les sp´ ecifications de P2P4GS. Nous d´ efinissons les principaux concepts de base sur lesquels s’appuient le syst` eme P2P4GS. Par la suite, nous d´ ecrivons le mod` ele d’architecture et pr´ esentons notre approche de structuration d’un syst` eme de grille pair-` a-pair ` a large ´ echelle. Finalement, nous d´ ecrivons ensuite le principe d’ex´ ecution de P2P4GS ainsi que son comportement face aux pannes dans un tel environnement.

Le chapitre 4 est consacr´ e ` a la description des diff´ erents m´ ecanismes de gestion de

services qu’offre le syst` eme P2P4GS. Les diff´ erentes primitives qui entrent en jeu dans le

cycle de vie d’un service, ` a savoir le d´ eploiement, l’enregistrement (ou la publication), la

localisation et l’invocation ainsi que l’ex´ ecution sont d´ ecrites dans cette partie.

Dans le chapitre 5, nous pr´ esentons une s´ erie de simulations en vue d’analyser les performances du syst` eme P2P4GS. Nous d´ ecrivons notre environnement de simulation ainsi que les protocoles impl´ ement´ es ` a savoir Gia, Pastry et Kademlia. Ensuite, nous d´ efinissons les diff´ erentes m´ etriques d’´ evaluation de performances de notre syst` eme. Puis, nous pr´ esentons les r´ esultats de simulations obtenus.

Finalement, nous clˆ oturons ce manuscrit par une synth` ese g´ en´ erale. Nous r´ esumons

ainsi les principales contributions faites dans ce travail et soulevons en guise de perspec-

tives, des pistes de r´ eflexions futures.

Etat de l’art sur les syst` emes distribu´ es

R´ esum´ e. Ce chapitre pr´ esente le contexte dans lequel se place nos travaux, ` a savoir les syst` emes distribu´ es et en particulier les r´ eseaux pair-` a-pair. Dans la premi` ere partie, nous pr´ esentons les syst` emes distribu´ es, ainsi que leurs propri´ et´ es inh´ erentes. De plus, nous d´ etaillons ses mod` eles de communication ainsi que quelques algorithmes classiques.

Par la suite, nous d´ efinissons les notions de pannes et la tol´ erance aux pannes. Dans un deuxi` eme temps, nous pr´ esentons le mod` ele des syst` emes pair-` a-pair qui est un mod` ele de syst` emes distribu´ es auquel nous nous sommes int´ eress´ es dans cette th` ese. Nous proposons ainsi un ensemble de d´ efinitions et de terminologies qui le sp´ ecifient. Puis, nous pr´ esentons les caract´ eristiques ainsi que les propri´ et´ es qu’elles lui conf` erent. Enfin, nous passons en revue les diff´ erentes architectures de syst` emes pair-` a-pair.

Sommaire

1.1 G´ en´ eralit´ es sur les syst` emes distribu´ es . . . . 8

1.1.1 D´ efinitions . . . . 8

1.1.2 Mod´ elisation d’un syst` eme distribu´ e . . . . 8

1.1.3 Mod` eles de communication . . . . 11

1.1.4 Algorithmes distribu´ es . . . . 13

1.1.5 Notions de panne et de tol´ erance aux pannes . . . . 14

1.1.6 Les mod` eles d’architecture . . . . 17

1.2 Les syst` emes pair-` a-pair . . . . 19

1.2.1 D´ efinition et terminologies . . . . 19

1.2.2 Caract´ eristiques du pair-` a-pair . . . . 20

1.2.3 Architectures de r´ eseaux pair-` a-pair . . . . 22

1.3 Conclusion . . . . 28

1.1 G´ en´ eralit´ es sur les syst` emes distribu´ es

1.1.1 D´ efinitions

Un syst` eme distribu´ e est d´ efini comme ´ etant une collection d’entit´ es de traitement et de stockage qui sont autonomes, interconnect´ ees ` a l’aide d’un r´ eseau de communication et pouvant s’´ echanger des informations les unes avec les autres [Tel94].

Les entit´ es peuvent ˆ etre des machines (ordinateurs), des processus, des processeurs, etc. et sont g´ en´ eralement appel´ ees nœuds ou sites du syst` eme distribu´ e. Pour ˆ etre qualifi´ e d’autonome, chaque nœud doit avoir son propre syst` eme de contrˆ ole local ind´ ependant des autres nœuds.

L’objectif d’un syst` eme distribu´ e est de fournir un service qui ne pourrait pas ˆ etre r´ ealis´ e par une seule entit´ e en termes de fonctionnalit´ e, disponibilit´ e, puissance de trai- tement, capacit´ e de stockage, temps de r´ eponse, fiabilit´ e, etc. Pour ce faire, les nœuds coop` erent ` a l’aide d’un mod` ele de communication afin d’accomplir la tˆ ache globale du syst` eme dont le d´ eroulement est induit par un algorithme distribu´ e.

Un algorithme distribu´ e d´ efinit les r` egles de fonctionnement d’un syst` eme distribu´ e [Lyn96]. Il est compos´ e d’une collection d’algorithmes locaux. Au niveau de chaque nœud, l’ex´ ecution d’un algorithme local est d´ eclench´ ee par un ´ ev´ enement qui peut ˆ etre de type r´ eception de message ou ´ epuisement d’un temps pr´ ed´ efini (compte-` a-rebours ou timeout).

Les syst` emes distribu´ es offrent plusieurs utilisations qui ont favoris´ e leur d´ eveloppement massif. Ils peuvent permettre le partage de ressources, l’augmentation de la fiabilit´ e des donn´ ees par le biais de r´ eplications, la haute disponibilit´ e, l’am´ elioration des performances par le parall´ elisme, la simplification de la conception d’un syst` eme par une structuration modulaire, etc.

1.1.2 Mod´ elisation d’un syst` eme distribu´ e

Dans cette section, nous d´ ecrivons dans un premier temps le mod` ele classiquement uti- lis´ e pour repr´ esenter un syst` eme distribu´ e. Par la suite, nous donnons quelques d´ efinitions li´ ees ` a ce mod` ele. Enfin, nous pr´ esentons les topologies de graphes les plus couramment rencontr´ ees dans la litt´ erature.

D´ efinitions

Un syst` eme distribu´ e est mod´ elis´ e sous la forme d’un graphe G = (V, E) o` u V

repr´ esente l’ensemble des nœuds du syst` eme et E l’ensemble des liens de communica-

tion entre les diff´ erents nœuds.

D´ efinition 1.1. Lien de communication

Lorsque deux noeuds u et v du graphe sont reli´ es, il existe un lien (u, v) ∈ E.

Si le graphe est non-orient´ e, alors nous avons (u, v) ∈ E ⇔ (v, u) ∈ E. Dans ce cas, le lien est appel´ e arˆ ete. La Figure1.1(a) illustre un exemple de graphe non-orient´ e.

Si par contre (u, v) ∈ E < (v, u) ∈ E, on dit alors que le graphe est orient´ e. Dans ce cas, le lien est appel´ e arc et est symbolis´ e par une fl` eche. La Figure1.1(b) illustre un exemple de graphe orient´ e.

(a) Graphe non-orient´ e (b) Graphe orient´ e

Figure 1.1 – Graphe non-orient´ e et graphe orient´ e D´ efinition 1.2. Chemin

Soit u et v deux nœuds du graphe. Un chemin existe entre u et v, s’il existe une suite finie de liens cons´ ecutifs reliant u ` a v.

D´ efinition 1.3. Voisin

Soient u et v deux nœuds du graphe. On dit que v est voisin de u si et seulement si (u, v)

∈ E. En d’autres termes, le nœud u peut communiquer directement avec le nœud v.

D´ efinition 1.4. Voisinage

Le voisinage d’un nœud u, not´ e N eigh _u , repr´ esente l’ensemble de tous les nœuds qui sont voisins de u. En d’autres termes, c’est l’ensemble des nœuds avec lesquels u peut communiquer directement.

D´ efinition 1.5. Degr´ e

Le degr´ e d’un nœud u, not´ e ∆ _u , repr´ esente le nombre de nœuds dans le voisinage de u.

D’o` u, ∆ _u = |N eigh _u |.

D´ efinition 1.6. Graphe connexe

Le graphe G est connexe si et seulement s’il existe un chemin entre tout couple de nœuds

(u, v) de E. C’est-` a-dire que le r´ eseau d’interconnexion permet le dialogue entre deux sites

arbitrairement choisis qui ne sont pas n´ ecessairement voisins.

Dans nos travaux de recherche, nous consid´ erons des syst` emes distribu´ es repr´ esent´ es par des graphes connexes. Toutefois, les solutions que nous proposons tol` erent la non- connexit´ e du syst` eme durant un temps relativement court ` a la suite de changements topologiques. Au-del` a d’un temps born´ e, un nœud non-atteignable est consid´ er´ e comme d´ econnect´ e.

Topologies classiques

Le graphe d’un syst` eme distribu´ e peut ˆ etre al´ eatoire ou r´ egulier. Dans le premier cas, on dit que la topologie du syst` eme distribu´ e suit un graphe quelconque ; c’est-` a-dire que les interconnexions entre les diff´ erents nœuds du syst` eme ne respectent aucune r` egle particuli` ere. Dans le second cas, on dit que la topologie ob´ eit ` a un graphe r´ egulier ; c’est-

`

a-dire que les interconnexions entre les diff´ erents nœuds du syst` eme respectent certaines r` egles de structuration.

Dans la suite, nous d´ etaillons les topologies classiques des syst` emes distribu´ es.

D´ efinition 1.7. Graphe complet

C’est un r´ eseau o` u pour tout couple de nœuds (u, v), u est voisin de v. Dans ce mod` ele, chaque nœud peut ainsi communiquer directement avec tous les autres nœuds du syt` eme.

La Figure1.2(a) est un exemple de graphe complet constitu´ e de 6 nœuds.

D´ efinition 1.8. Chaˆ ıne

Une chaˆıne de N nœuds, est un graphe connexe o` u les N – 2 nœuds ont un degr´ e ´ egal ` a 2 et les deux autres nœuds (qui sont en extr´ emit´ es) ont un degr´ e ´ egal ` a 1. La Figure1.2(b) est un exemple de chaˆıne constitu´ e de 6 nœuds.

D´ efinition 1.9. Anneau

Un anneau est un cas particulier d’une chaˆıne o` u les deux nœuds ` a l’extr´ emit´ e sont reli´ es.

L’anneau peut ˆ etre orient´ e ou non-orient´ e. La Figure1.2(c) est un exemple d’anneau constitu´ e de 6 nœuds.

D´ efinition 1.10. Arbre

Un arbre de N nœuds est un graphe connexe contenant exactement N – 1 liens de commu- nication. Sa particularit´ e est qu’il ne contient pas de cycle. Donc, il existe qu’un unique chemin entre deux nœuds u et v quelconques. La Figure1.2(d) est un exemple d’arbre constitu´ e de 6 nœuds.

L’un des nœuds de l’arbre est appel´ e la racine. Si u est plus proche que v de la racine,

alors u est dit p` ere de v et v est un fils de u. Ainsi, le nœud racine n’a pas de p` ere. Un

nœud qui ne poss` ede pas de fils est appel´ e une feuille. Son degr´ e est alors ´ egal ` a 1.

(a) Graphe complet (b) Chaˆıne

(c) Anneau (d) Arbre

Figure 1.2 – Quelques topologies classiques des syst` emes distribu´ es

Remarque 1.1. Il est possible de construire un arbre couvrant [Epp99, G¨ ar03, Kru56]

sur tout graphe quelconque connexe.

D´ efinition 1.11. Arbre couvrant

Soit G = (V, E), un graphe non orient´ e et connexe. Un arbre couvrant de G est un arbre inclu dans ce graphe et qui pr´ esente les propri´ et´ es suivantes :

• il connecte tous les sommets du graphe ;

• il existe exactement un unique chemin entre tout couple nœuds (u, v) : E _AC ⊆ E _G . Le fait qu’il soit un arbre lui conf` ere sa propri´ et´ e d’acyclit´ e. La Figure 1.3(b) illustre un exemple d’arbre couvrant (les liens sont repr´ esent´ es en pointill´ es) d’un graphe quelconque illustr´ e ` a gauche (Figure 1.3(a)).

1.1.3 Mod` eles de communication

Un syst` eme distribu´ e est constitu´ e d’un ensemble d’entit´ es qui coop` erent ` a l’aide d’un

mod` ele de communication afin d’accomplir la tˆ ache globale du syst` eme. Nous distinguons

dans la litt´ erature le mod` ele de communication ` a m´ emoire partag´ ee et celui ` a passage de

messages [WA99].

(a) Graphe quelconque (b) Arbre couvrant

Figure 1.3 – Illustration d’un arbre couvrant du graphe (a)

La communication dans le mod` ele ` a m´ emoire partag´ ee est implicite. L’information est transmise lors de l’´ ecriture dans une zone de la m´ emoire partag´ ee, et r´ ecup´ er´ ee quand un autre processus vient lire cette zone.

Dans le mod` ele ` a passage de messages, chaque nœud poss` ede donc sa propre m´ emoire priv´ ee et est le seul ` a y avoir acc` es. De ce fait, les nœuds communiquent entre eux par

´ emission et r´ eception de messages via des canaux de communication.

On parle de transmissions en mode FIFO (First-In First-Out ) lorsque les canaux de communication d´ elivrent les messages suivant l’ordre d’´ emission de ceux-ci. Toutefois, l’ordre des messages re¸cus peut ´ eventuellement ˆ etre diff´ erent de l’ordre des messages transmis ; dans ce cas on dit qu’il y a d´ es´ equencement des messages.

Dans nos travaux de recherche, nous nous int´ eressons au mod` ele ` a passage de messages car il est plus r´ ealiste. En effet, comme nous l’avons d´ ecrit plus haut, pour que les nœuds d’un syst` eme distribu´ e soient qualifi´ es d’autonomes, l’auteur de [Tel94] pr´ ecise que chacun d’eux doit avoir son propre syst` eme de contrˆ ole local (donc propre m´ emoire priv´ ee), ind´ ependant des autres nœuds.

Soulignons que les communications dans un mod` ele ` a passage de messages peuvent ˆ etre synchrones ou asynchrones. On parle de communications synchrones quand le transfert d’informations n’est possible qu’apr` es une synchronisation globale des nœuds ´ emetteurs et r´ ecepteurs. Par contre, lorsque les temps de communication entre nœuds r´ epartis du syst` eme ne peuvent ˆ etre pr´ evus de fa¸con pr´ ecise et absolue, on dit alors que le syst` eme fonctionne en mode asynchrone. Dans ce cas de figure, les d´ elais d’acheminement des messages le long des canaux de communication sont finis mais non born´ es.

Nous pouvons ainsi conclure que le mod` ele de communication synchrone semble ˆ etre

plus contraignant que le mod` ele de communication asynchrone. En cons´ equence, pour

nous rapprocher le plus possible des conditions r´ eelles, nous nous alignons dans ce travail

au mod` ele de communication asynchrone ` a passage de messages.

1.1.4 Algorithmes distribu´ es

Nous avons vu que les nœuds du syst` eme distribu´ e coop` erent par ´ echange d’informa- tions afin de r´ ealiser un objectif commun. Les ´ etapes de calcul qui caract´ erisent cette collaboration sont d´ ecrites par des algorithmes distribu´ es.

Un algorithme distribu´ e d´ efinit les r` egles de fonctionnement d’un syst` eme distribu´ e [Lyn96, Ray85, Tel94]. Il est compos´ e d’une collection d’algorithmes locaux. Au niveau de chaque nœud, l’ex´ ecution d’un algorithme local est d´ eclench´ ee par un ´ ev´ enement qui peut ˆ etre de type r´ eception de message ou ´ ech´ eance d’un timeout.

Nous allons dans ce qui suit pr´ esenter quelques algorithmes distribu´ es classiques qui constituent des primitives de base pour la mise en œuvre d’un syst` eme distribu´ e.

Algorithmes ` a vagues

Les algorithmes ` a vagues [Cha82] sont utilis´ es pour la diffusion d’une information dans le r´ eseau. Cette information peut ˆ etre de type synchronisation, envoi d’un ordre, calculs locaux (calcul d’une fonction dont chaque nœud poss` ede une partie des entr´ ees), demande d’´ etat, etc. Apr` es la diffusion d’une information, chaque site peut ´ eventuellement prendre localement une d´ ecision.

Un cas particulier des algorithmes ` a vagues est l’algorithme PIF (Propogation of Infor- mation with Feedback ) [Seg83] qui signifie litt´ eralement propagation d’informations avec retour. L’objectif de cet algorithme est de propager une information et d’en faire le retour jusqu’au site initiateur.

Algorithmes d’exclusion mutuelle

L’objectif des algorithmes d’exclusion mutuelle est d’´ eviter que des ressources par- tag´ ees d’un syst` eme ne soient utilis´ ees en mˆ eme temps par plusieurs nœuds du syst` eme.

Ce paradigme, introduit par Edsger Dijkstra [Dij65], permet d’assurer que l’ex´ ecution d’une portion de code manipulant une ressource partag´ ee (commun´ ement appel´ ee section critique) se fera toujours de mani` ere exclusive (propri´ et´ e de suret´ e). De plus, tout nœud souhaitant la ressource partag´ ee y acc´ edera en temps fini (propri´ et´ e de vivacit´ e).

Pour ce faire, trois ´ etats sont d´ efinis dans le comportement de chaque nœud :

• ´ etat demande de section critique ;

• ´ etat en section critique ;

• ´ etat sortie de section critique.

Plusieurs solutions pour la r´ esolution du probl` eme d’exclusion mutuelle ont ´ et´ e propos´ ees

dans la litt´ erature. Parmi celles-ci, on peut citer [Lam78, LL77, Ray91, RA81].

Algorithmes d’´ election

Ces algorithmes ont pour but d’´ elire un nœud du syst` eme parmi d’autres [LL77]. Donc,

`

a partir d’une configuration initiale o` u tous les nœuds actifs sont candidats, le syst` eme atteint une configuration o` u un nœud est d´ eclar´ e ´ elu et les autres candidats sont d´ eclar´ es battus. Le nœud ´ elu est appel´ e leader et il sera dot´ e d’un certain nombre de privil` eges d´ ependant des objectifs pr´ ed´ efinis pour le fonctionnement global du syst` eme.

L’algorithme d’´ election poss` ede ainsi les propri´ et´ es de suret´ e et de vivacit´ e :

• parmi tous les candidats, un seul nœud ´ elu (suret´ e ) ;

• parmi tous les candidats, un nœud doit ˆ etre ´ elu en temps fini (vivacit´ e).

Le processus ou l’algorithme d’´ election peut ˆ etre d´ eclench´ e par un nœud quelconque mais aussi ´ eventuellement par plusieurs nœuds.

Algorithmes de d´ etection de terminaison

Dans un environnement distribu´ e d´ epourvu de structures de contrˆ ole centrales, com- ment un nœud peut-il prendre conscience de la terminaison de l’application d’un algo- rithme sur le syst` eme ? L’objectif des algorithmes de d´ etection de terminaison consiste ` a v´ erifier une propri´ et´ e de stabilit´ e globale (la terminaison). Pour ce faire, deux conditions doivent ˆ etre remplies :

• d´ etecter que chacun des processus est ` a l’arrˆ et ;

• v´ erifier que le travail accompli soit conforme au calcul voulu.

Une solution classique ` a ce probl` eme de d´ etection de terminaison consiste ` a construire une structure particuli` ere et de d´ eterminer un type de parcours sur cette structure. Par exemple dans [DFvG83], un anneau unidirectionnel est utilis´ e avec un jeton circulant pour parcourir la structure ; tandis que les auteurs de [DS80] proposent d’utiliser un arbre couvrant pour la v´ erification de la propri´ et´ e de terminaison.

1.1.5 Notions de panne et de tol´ erance aux pannes

Dans cette section, nous d´ ecrivons les notions de pannes et de tol´ erance aux pannes dans les syst` emes distribu´ es.

Les syst` emes informatiques, comme probablement tous les syst` emes physiques, peuvent

ˆ etre victimes de d´ efaillances. En particulier, les syst` emes distribu´ es peuvent ˆ etre constitu´ es

d’un nombre important de composants collaborant pour l’accomplissement de la tˆ ache

globale d’un syst` eme. De ce fait, il existe une probabilit´ e que certains de ces composants

soient sujets ` a des dysfonctionnements. En effet, un composant peut tomber en panne

suite ` a une d´ efaillance mat´ erielle ou logicielle (un bug par exemple). De plus, avec la nature dynamique de certains syst` emes distribu´ es, des nœuds peuvent se connecter et se d´ econnecter du syst` eme ` a tout moment. En outre, les canaux de communication peuvent

´

egalement ˆ etre non fonctionnels sur une p´ eriode donn´ ee.

Tous ces aspects peuvent occasionner des perturbations ou dysfonctionnements appel´ es aussi pannes du syst` eme.

D´ efinition 1.12. Panne

Une panne est d´ efinie comme ´ etant une d´ efaillance temporaire ou permanente d’un ou de plusieurs composants d’un syst` eme [ALR04, Lap88]. Un composant est d´ efaillant lorsqu’il ne remplit plus ses sp´ ecifications requises.

La panne est temporaire ou encore transitoire ou intermittente lorsqu’elle est pr´ esente pour une dur´ ee limit´ ee, c’est-` a-dire sa dur´ ee est inf´ erieure au temps d’ex´ ecution de l’algo- rithme. Par contre, une panne est permanente ou d´ efinitive lorsque sa dur´ ee est sup´ erieure au temps d’ex´ ecution de l’algorithme.

Une panne ou d´ efaillance est ainsi l’´ ev` enement qui survient lorsque le comportement du syst` eme d´ evie de sa fonction. L’´ etat du syst` eme qui est susceptible d’entrainer une d´ efaillance est appel´ e erreur. Un ´ etat d’erreur d´ esigne un ´ etat anormal du syst` eme et r´ esultant de l’activation d’une faute. La chaˆıne qui lie ces diff´ erents m´ ecanismes est illustr´ ee sur la Figure 1.4 [ALR04, Lap88].

Faute ^activation propagation

Défaillance conséquence Faute Erreur

Figure 1.4 – La chaˆıne fondamentale des entraves

Les fl` eches de la chaˆıne expriment la relation causale entre fautes, erreurs et d´ efaillances.

Elles doivent ˆ etre interpr´ et´ ees de fa¸con g´ en´ erique : par propagation, plusieurs erreurs sont g´ en´ eralement g´ en´ er´ ees avant qu’une d´ efaillance ne survienne.

Ces notions (faute, erreur et d´ efaillance) sont toutefois tributaires du syst` eme consid´ er´ e.

En effet, un mˆ eme ´ ev´ enement pourra ˆ etre d´ efini comme une d´ efaillance, une erreur ou une faute suivant le point de vue fonctionnel consid´ er´ e.

Il est ` a noter ´ egalement que nombre d’erreurs n’affectent pas l’´ etat externe du syst` eme, et donc ne causent pas de d´ efaillance (panne) [Lap88].

Etant donn´ ´ e que les environnements distribu´ es sont sujets ` a des pannes, il est n´ ecessaire

de mettre en place des m´ ecanismes de r´ esistance ` a d’´ eventuels dysfonctionnements pouvant

survenir au cours de l’accomplissement de la tˆ ache globale du syst` eme. On introduit ainsi

la notion de tol´ erance aux pannes.

D´ efinition 1.13. Tol´ erance aux pannes

La tol´ erance aux pannes est un m´ ecanisme permettant d’assurer le bon fonctionnement du syst` eme et de remplir les sp´ ecifications requises malgr´ e la pr´ esence de dysfonctionnement dans ses composants [ALR04, Lap88, LA12].

Afin de tol´ erer les pannes qui peuvent survenir dans un syst` eme distribu´ e, deux ap- proches sont propos´ ees : les algorithmes robustes et les algorithmes auto-stabilisants.

Les algorithmes robustes sont l’une des cat´ egories de solutions apport´ ees au probl` eme de pannes dans les syst` emes distribu´ es.

D´ efinition 1.14. Algorithme robuste

Un algorithme robuste est un algorithme qui est capable de garantir le respect des sp´ ecifica- tions du syst` eme malgr´ e l’occurrence de pannes.

Dans [MW87], les auteurs ont montr´ e que l’´ etude des algorithmes robustes peut se r´ eduire ` a l’´ etude du probl` eme de d´ ecision commune connu aussi sous le nom de probl` eme du consensus : tous les processus d’un syst` eme doivent tomber d’accord sur le choix d’une valeur binaire, celle-ci devant ˆ etre la valeur initiale d’au moins un processus.

Les auteurs de [FLP85] ont toutefois prouv´ e que le consensus est impossible dans le cas d’un syst` eme asynchrone. En effet, ils d´ emontrent que sans hypoth` ese suppl´ ementaire sur le mod` ele, le probl` eme du consensus n’admet aucune solution d´ eterministe lorsqu’une panne sur un composant peut survenir. Ainsi, ces auteurs ([FLP85]) supposent qu’un protocole fiable termine en un nombre fini d’´ etapes. Toutefois, dans [BT85], les auteurs rejettent cette hypoth` ese en proposant deux algorithmes qui peuvent ne jamais se termi- ner.

D’autres part, des solutions bas´ ees sur la d´ etection des pannes pouvant apparaˆıtre dans le syst` eme ont ´ et´ e propos´ ees. C’est le cas par exemple dans [CT91] o` u les auteurs proposent la notion de d´ etecteurs de pannes non fiables afin de r´ esoudre le probl` eme du consensus.

Les algorithmes auto-stabilisants constituent l’autre cat´ egorie de solutions apport´ ees au probl` eme de pannes dans les syst` emes distribu´ es.

D´ efinition 1.15. Algorithme auto-stabilisant

Un algorithme auto-stabilisant est un algorithme qui est capable de converger, au bout d’un temps fini, vers un ´ etat stable et l´ egitime quel que soit son ´ etat initial consid´ er´ e.

Le concept d’auto-stabilisation a ´ et´ e pr´ esent´ e par Dijkstra en 1974 dans [Dij74]. Il

consid` ere un syst` eme comme ´ etant auto-stabilisant, si quel que soit son ´ etat, il est capable

de retrouver un ´etat l´egal, ou l´egitime, sans intervention ext´erieure en un nombre fini d’´etapes.

L’auto-stabilisation a ´et´e d´evelopp´ee pour permettre aux syst`emes distribu´es de r´esister aux pannes transitoires. Celles-ci peuvent ˆetre provoqu´ees par des ruptures de liens de communication ou aussi par des corruptions de donn´ees locales. Le principe de l’auto- stabilisation est d’assurer qu’un syst`eme finira par adopter un comportement qui respecte les sp´ecifications du probl`eme, apr`es avoir subit une d´efaillance transitoire.

Un algorithme est ainsi qualifi´e d’auto-stabilisant, s’il pr´esente les deux propri´et´es suivantes [AG94, Gou95] :

• La convergence qui garantit qu’`a partir d’un ´etat quelconque, le syst`eme retrouvera au bout d’un temps fini un comportement correct ;

• La clˆ oture qui garantit qu’`a partir d’un ´etat correct atteint, le syst`eme restera dans cet ´etat correct si aucune panne n’apparaˆıt dans le syst`eme.

1.1.6 Les mod` eles d’architecture

Le mod`ele architecture d´ecrit la mani`ere dont les composants d’un syst`eme sont inter- connect´es et communiquent pour r´ealiser un objectif commun. Les mod`eles d’architecture couramment utilis´es dans les syst`emes distribu´es sont le mod`ele client-serveur et le mod`ele pair-`a-pair [CDK05].

(a) Mod`ele client-serveur (b) Mod`ele pair-`a-pair

Figure 1.5 – Mod`ele client-serveur et mod`ele pair-`a-pair

Le mod` ele client-serveur

Le mod` ele client/serveur est un mod` ele constitu´ e essentiellement de deux types d’en- tit´ es : l’entit´ e centrale, qualifi´ ee de passive appel´ ee serveur et l’entit´ e p´ eriph´ erique, qua- lifi´ ee d’active appel´ ee client (Figure 1.5(a)).

Les clients se connectent au serveur afin d’acc´ eder aux services offerts par ce dernier.

Le serveur est en g´ en´ eral dot´ e de capacit´ es sup´ erieures ` a celles des clients en termes de puissance de calcul, de ressources m´ emoires, etc.

La nature centralis´ ee des ressources fait que mod` ele client/serveur est tr` es sensible aux pannes et g´ en´ eralement inapte ` a passer ` a l’´ echelle. En effet, l’´ el´ ement central (le serveur) est un point critique car s’il tombe en panne, l’ensemble de son service devient inaccessible. D’autre part, le serveur doit ˆ etre en mesure d’accepter un grand nombre de connexions simultan´ ement, ce qui implique un d´ ebit important. De plus, pour traiter toutes les demandes, le serveur doit avoir une puissance de calcul suffisamment importante.

Tous ces param` etres rendent le passage ` a l’´ echelle plus difficile.

Le mod` ele pair-` a-pair

Le mod` ele pair-` a-pair connu ´ egalement sous le nom de mod` ele poste-` a-poste ou d’´ egal-

`

a-´ egal est un mod` ele o` u chaque entit´ e du syst` eme peut ` a la fois jouer le rˆ ole de client et de serveur d’o` u l’appellation de servent ou simplement pair (Figure 1.5(b)).

Contrairement au mod` ele client-serveur, le mod` ele pair-` a-pair pr´ esente une infrastruc- ture d´ ecentralis´ ee. En effet, il permet aux nœuds du syst` eme de communiquer, de colla- borer et de partager des ressources entre eux.

Ce mod` ele pair-` a-pair connait un tr` es grand succ` es depuis la fin des ann´ ees 90, ´ epoque

`

a laquelle Napster [SGG01], un syst` eme pair-` a-pair de partage de fichiers permit ` a des mil- lions d’usagers connect´ es ` a Internet de t´ el´ echarger et de partager des fichiers multim´ edias.

Les premi` eres applications de ce mod` ele ´ etaient exclusivement li´ ees au partage de fichiers dont certains ´ etaient soumis ` a des droits d’auteur. Par la suite, ce mod` ele s’est ouvert ` a d’autres horizons tels que :

• Le stockage de donn´ ees o` u l’on trouve des plateformes qui proposent ` a des usagers une infrastructure robuste pour le stockage et l’acc` es ` a leurs donn´ ees personnelles depuis n’importe quel point d’acc` es ` a Internet. Parmi ces plateformes on peut citer OceanStore [KBC ⁺ 00] qui est l’un des premiers travaux d´ ecrivant une architecture compl` ete de stockage persistant en pair-` a-pair d´ eploy´ ee ` a l’´ echelle d’Internet. Plus r´ ecemment, la plateforme Wuala [MBM12] a ´ et´ e aussi d´ eploy´ ee ` a l’´ echelle d’Internet.

• La communication o` u des solutions de communication et de voix sur IP qui per-

mettent ` a chacun d’´ echanger et de dialoguer avec ses connaissances ind´ ependamment

de tout op´ erateur t´ el´ ephonique et quel que soit son emplacement. Skype [BS06] est une des applications offrant ce type de services.

• Le calcul distribu´ e o` u la puissance de calcul r´ esultant de l’agr´ egation des proces- seurs de machines connect´ ees repousse les limites des super-calculateurs actuels. On peut notamment citer l’exemple d’Ourgrid [ACGC05] qui est une plateforme pair-

`

a-pair pour partager les cycles de calcul ` a travers diverses soci´ et´ es ou organismes.

Le mod` ele pair-` a-pair se trouve actuellement de plus en plus utilis´ e. En effet, permet- tant de d´ ecentraliser la r´ ealisation des services et de mettre ` a disposition des ressources partag´ ees dans un r´ eseau, ce mod` ele pr´ esente de nombreux avantages tels que l’auto- organisation, la tol´ erance aux pannes, le passage ` a l’´ echelle, etc.. Effectivement, l’absence d’´ el´ ement de stockage central permet de mieux pallier aux pannes. De plus, la r´ epartition des ressources entre les nœuds du syst` eme favorise un meilleur ´ equilibrage du trafic sous- jacent. Enfin, la mutualisation des ressources induit une r´ eduction des coˆ uts li´ es ` a l’achat et ` a la maintenance des ´ equipements.

En raison de toutes ces propri´ et´ es, nous nous int´ eressons dans nos travaux de recherche

`

a ce mod` ele pour les nombreux avantages qu’il offre. Ainsi, la deuxi` eme partie de ce chapitre sera consacr´ ee enti` erement ` a l’´ etude des syst` emes pair-` a-pair.

1.2 Les syst` emes pair-` a-pair

Dans cette section, nous donnons d’abord un ensemble de d´ efinitions et de terminolo- gies qui sp´ ecifient les syst` emes pair-` a-pair. Ensuite, nous pr´ esentons leurs caract´ eristiques.

Enfin, nous passons en revue les diff´ erentes architectures des syst` emes pair-` a-pair.

1.2.1 D´ efinition et terminologies

D´ efinition

Plusieurs d´ efinitions du mod` ele pair-` a-pair ont ´ et´ e propos´ ees dans la litt´ erature [ATS04, LCP ⁺ 05, MKL ⁺ 02, Sch01]. Nous r´ esumons ces d´ efinitions comme suit :

D´ efinition 1.16. Syst` eme pair-` a-pair

Un syst` eme P2P (pair-` a-pair) est un mod` ele syst` eme distribu´ e collaboratif constitu´ e d’un ensemble de participants appel´ es pairs. Un pair est une entit´ e ou nœud du syst` eme pair-` a- pair qui peut prendre successivement ou simultan´ ement le rˆ ole de client (lorsqu’il demande une ressource dans le syst` eme) et de serveur (lorsqu’il offre une ressource dans le syst` eme).

Le pair partage ainsi des ressources informatiques accessibles de mani` ere directe par les

autres pairs du syst` eme, dans le but d’´ etablir un service collaboratif. Cette d´ ecentralisation des ressources du syst` eme permet de mieux r´ esister aux pannes et favorise ´ egalement le passage ` a l’´ echelle.

Terminologies

Dans ce qui suit, les notations relatives aux syst` emes pair-` a-pair et utilis´ ees dans ce m´ emoire sont d´ etaill´ ees dans la terminologie suivante.

Dans un syst` eme pair-` a-pair, chaque pair cr´ ee des connexions vers un ensemble de pairs, en utilisant les services de t´ el´ ecommunications disponibles localement. Les pairs vont donc ´ etablir des connexions entre eux en utilisant les protocoles du syst` eme P2P pour former ce que l’on appelle un r´ eseau pair-` a-pair.

Le r´ eseau P2P ainsi form´ e poss` ede ses m´ ecanismes de nommage, d’adressage, de communication, de routage, etc. Ces m´ ecanismes sont en g´ en´ eral distincts du r´ eseau de t´ el´ ecommunication utilis´ e. On parle ` a cet effet de r´ eseau logique en superposition (appel´ e par analogie en anglais : overlay ) pour insister sur le fait que le r´ eseau pair-` a-pair devient alors distinct du r´ eseau physique de t´ el´ ecommunication en-dessous (appel´ e par analogie en anglais : underlay).

Un r´ eseau logique est donc l’interconnexion qui relie virtuellement les nœuds d’un syst` eme P2P au-dessus d’un r´ eseau physique. C’est alors l’appartenance ` a ce r´ eseau logique qui d´ efinit les limites d’un syst` eme pair-` a-pair.

Un lien entre deux pairs du syst` eme P2P symbolise une connexion virtuelle permettant la communication entre ces deux noeuds. Ce lien est souvent appel´ e lien virtuel ou logique.

La communication entre deux pairs peut passer par un ou plusieurs liens physiques du r´ eseau de t´ el´ ecommunications sous-jacent. Ainsi, analogiquement, les liens dans le r´ eseau de t´ el´ ecommunication sont appel´ es liens r´ eels ou physiques.

Les r´ eseaux pair-` a-pair sont dynamiques, c’est-` a-dire caract´ eris´ es par l’arriv´ ee et le d´ epart continu de nœuds au sein du syst` eme. Le terme churn d´ esigne la dynamique d’un environnement pair-` a-pair. Il est caract´ eris´ e par le taux d’arriv´ ee et de d´ epart de nœuds au sein du syst` eme pendant une p´ eriode donn´ ee.

1.2.2 Caract´ eristiques du pair-` a-pair

Dans cette section, nous passons en revue les caract´ eristiques g´ en´ erales des syst` emes pair-` a-pair. La synth` ese des travaux d´ efinis dans [RD10, JEB05, MKL <sup>+</sup> 02], nous permet ainsi de caract´ eriser les syst` emes pair-` a-pair comme des syst` emes distribu´ es pr´ esentant les propri´ et´ es suivantes :

D´ ecentralisation. Les pairs prennent le rˆ ole de client et de serveur, et la majeure

partie de l’´ etat du syst` eme et des tˆ aches sont dynamiquement distribu´ es parmi les pairs.

L’ensemble des besoins de calcul, de stockage et de communication li´ es ` a l’ex´ ecution du syst` eme est alors fourni de fa¸con collaborative par les membres du syst` eme pair-` a- pair. Toutefois, selon l’architecture consid´ er´ ee, certains nœuds peuvent poss´ eder un ´ etat centralis´ e en jouant un rˆ ole d’annuaire, mais, dans tous les cas, les ressources restent toujours distribu´ ees entre les pairs du syst` eme.

Auto-organisation. Elle d´ efinit le processus dans lequel l’organisation d’un syst` eme

´

evolue spontan´ ement sans pour autant que cela soit contrˆ ol´ e par un syst` eme ext´ erieur [MKL <sup>+</sup> 02]. Dans un syst` eme P2P, les pairs peuvent s’organiser et se regrouper, selon les activit´ es dont ils se chargent, leurs int´ erˆ ets communs ou encore la topologie du r´ eseau, comme par exemple, l’´ etablissement d’un r´ eseau logique virtuel structur´ e ou non-structur´ e ou hi´ erarchique.

Dynamicit´ e. Les syst` emes P2P sont de nature dynamique. Un pair peut se connecter et de se d´ econnecter du r´ eseau ` a n’importe quel moment. Les d´ eparts de nœuds peuvent ˆ

etre volontaires, dans le cas par exemple d’un service accompli ou bien involontaires, quant il s’agit de nœuds d´ efaillants ou de nœuds mobiles quittant une zone de couverture ou le cluster. Rappelons que la dynamique des environnements pair-` a-pair est aussi d´ esign´ ee sous le terme de churn.

R´ eseau virtuel. Les nœuds d’un syst` eme pair-` a-pair forment souvent un r´ eseau vir- tuel ou logique. Ce r´ eseau pr´ esente g´ en´ eralement des propri´ et´ es de transparence vis-` a-vis des nœuds du syst` eme. En effet, les nœuds sont vus comme des pairs dans l’overlay alors qu’ils peuvent ˆ etre de types diff´ erents sur le plan mat´ eriel, par exemple des ordinateurs portables, des stations de travail, des clusters, etc.

Large ´ echelle. Un syst` eme pair-` a-pair est dit large ´ echelle ou grande ´ echelle s’il est compos´ e d’un tr` es grand nombre de nœuds. En effet, un syst` eme pair-` a-pair peut atteindre une taille tr` es importante de participants, de l’ordre de plusieurs milliers de nœuds. G´ en´ eralement, ces nœuds sont g´ eographiquement r´ epartis.

Passage ` a l’´ echelle. Le fait d’augmenter de mani` ere importante le nombre de nœuds dans un syst` eme pair-` a-pair n’affecte g´ en´ eralement pas le fonctionnement de l’ensemble du syst` eme. De plus, la r´ epartition des ressources entre les nœuds du syst` eme favorise un meilleur ´ equilibrage du trafic sous-jacent.

Tol´ erance aux pannes. Les syst` emes pair-` a-pair sont g´ en´ eralement r´ esistants aux

pannes, car il existe peu, ou pas, de nœuds dont la pr´ esence est critique pour l’ex´ ecution

du service associ´ e.

1.2.3 Architectures de r´ eseaux pair-` a-pair

Depuis leur ´ emergence ` a la fin des ann´ ees 90, les syst` emes pair-` a-pair ont beaucoup

´ evolu´ es et se sont diversifi´ es dans leurs architectures. Ces architectures reposent sur la construction d’un r´ eseau virtuel sur le r´ eseau physique (typiquement Internet).

Plusieurs propositions de classification d’architectures P2P ont ´ et´ e faites dans la litt´ erature [AH01, MKL ⁺ 02, Ora01, Sch01]. D’ordinaire, c’est le degr´ e de d´ ecentralisation qui est retenu pour la classification des architectures P2P. Tout comme les propositions faites dans [AH01, Ora01], nous distinguons aussi, en fonction du degr´ e de d´ ecentralisation, trois mod` eles d’architectures P2P ` a savoir le mod` ele centralis´ e, le mod` ele pur ou d´ ecentralis´ e et le mod` ele hybride ou hi´ erarchique.

En outre, en fonction du mode d’organisation des pairs, le mod` ele d’architecture P2P d´ ecentralis´ e peut ˆ etre scind´ e en deux classes : le mod` ele d´ ecentralis´ e non-structur´ e et le mod` ele d´ ecentralis´ e structur´ e.

La Figure1.6 pr´ esente la taxonomie des architectures P2P.

structuré Système P2P

décentralisé

centralisé hybride

non−structuré

Figure 1.6 – Taxonomie des architectures P2P

Nous classifions ces mod` eles d’architectures principalement en trois g´ en´ erations.

• Premi` ere g´ en´ eration qui correspond ` a la d´ efinition du mod` ele d’architecture P2P centralis´ e.

• Deuxi` eme g´ en´ eration qui correspond ` a la d´ efinition du mod` ele d’architecture P2P

d´ ecentralis´ e. Dans cette g´ en´ eration on distingue :