• Aucun résultat trouvé

Lh*rs p2p : une nouvelle structure de données distribuée et scalable pour les environnements Pair à Pair

N/A
N/A
Protected

Academic year: 2021

Partager "Lh*rs p2p : une nouvelle structure de données distribuée et scalable pour les environnements Pair à Pair"

Copied!
108
0
0

Texte intégral

(1)

École Doctorale EDDIMO

LAMSADE

THÈSE

: Une Nouvelle Structure de Données

Distribuée et Scalable pour les Environnements

Pair à Pair

Pour l’obtention du titre de

Docteur en Informatique

(Arrêté du 25 avril 2002)

Présentée et soutenue le 14 Mai 2013

YAKOUBEN Hanafi

Composition du Jury

Directeur de Thèse : LITWIN Witold

Professeur à l’université Paris-Dauphine

Présidente du Jury : GRIGORI Daniela

Professeur à l’Université Paris-Dauphine

Rapporteurs : LONG Darrell Don Earl

Professeur à l’Université de Californie à Santa Cruz, USA

DU MOUZA Cédric

Maître de Conférences Habilité au Conservatoire National des Arts et Métiers

Examinateurs : PÂRIS Jehan-François

Professeur à l’Université de Houston, USA

RIGAUX Philippe

(2)

Dédicaces

(3)

Remerciements

Mes premiers remerciements vont à mon directeur de thèse, Monsieur Litwin, professeur à l’Université Paris-Dauphine. Sa rigueur et la pertinence de ses jugements ont été très constructives et m’ont permis d’achever cette thèse. Merci pour tous vos conseils et de m’avoir donné la possibilité d’préparer ma thèse. Je tiens à vous exprimer toute ma profonde gratitude.

Je remercie chaleureusement Monsieur Long, Professeur à l’Université de Californie à Santa Cruz et Monsieur Pâris, Professeur à l’Université de Houston pour le temps qu’ils m’ont consacré durant leur séjour à Paris, pour tous leurs conseils, corrections et commentaires. Un très grand merci de m’avoir fait l’honneur d’accepter de participer au jury.

Je remercie vivement Monsieur Rigaux, Professeur au CNAM et Monsieur Du Mouza, Maître de Conférences Habilité au CNAM de m’avoir fait l’honneur de juger mon travail.

Je remercie vivement Madame Grigori, Professeur à l’Université Paris-Dauphine d’avoir acceptée de présidé ce jury.

Je tiens à adresser mes remerciements à Monsieur Thomas Schwartz, Professeur à l’Université Santa Clara, pour ses conseils pertinents durant ces années de préparation de la thèse.

J’adresse aussi mes vifs remerciements à Madame Bazgan, Professeur à l’Université Paris-Dauphine et Directrice de l’École Doctorale, pour son soutien et d’avoir appuyé ma demande de réinscription au conseil doctoral connaissant ma situation professionnel.

J’adresse mes vifs remerciements à Madame Moussa, Maître de Conférences à l’Université de Carthage, Tunisie, pour son aide précieuse sur le prototype de base et les algorithmes qu’elle a implémentés.

Je remercie particulièrement Madame Sahri, Maître de conférences à l’Université Paris Descartes, pour tous ses conseils, ses encouragements et son amitié.

Merci à Wassila, Maître de conférences à Centrale Paris et Samir pour leurs encouragements. Je ne saurais remercier assez ma très chère épouse Émilie. Merci de m’avoir supporté tout au long de ces longues années d’études pour les weekends et soirée passés à rédiger ou à lire des papiers. Heureusement que tu étais à mes côtés.

(4)

Résumé

: Une nouvelle Structure de Données Distribuée et

Scalable pour les Environnements Pair à Pair

Cette Thèse propose une nouvelle structure de données distribuée et scalable (SDDS) appelée LH ∗ , dédiée à l’environnement pair à pair (P2P). Un fichier LH ∗ est un ensemble d’enregistrements contenant les données de l’application, chacun étant identifié par une clé. Ces enregistrements sont distribués dans des cases mémoire sur des pairs selon le principe du hachage linéaire (LH*). Tout fichier LH ∗ peut s’étndre dynamiquement par des éclatements de cases, en s’étalant potentiellement sur un nombre quelconque de pairs.

De tels fichiers répondent à trois exigences majeures. La première est l’efficacité d’une requête à clé. Une telle requête peut être une recherche, une insertion, une mise à jour ou une suppression de l’enregistrement identifié par la clé spécifiée. Une requête à clé s’adresse à une case. La seconde exigence est l’efficacité d’un scan, c.-à-d. d’une requête s’adressant à toutes les cases. Les scans sont aussi connus sous le nom de ‘Map/Reduce’. Enfin, la troisième exigence est la tolérance à l’indisponibilité de données d’un ou de plusieurs pairs. Le problème peut venir d’une panne d’un pair ou du réseau. Il peut aussi être dû à l’arrêt volontaire du service par le pair. Ce dernier peut d’ailleurs tenter de revenir au service plus tard, en offrant involontairement des données périmées, données qui auraient déjà été reconstruites ailleurs et mises à jour depuis. L’ensemble du problème est connu sous le nom de Churn.

LH ∗ répond à ces exigences comme suit. En premier lieu, une requête à clé subit au maximum un seul renvoi entre les pairs. Ensuite, un scan nécessite au maximum deux rounds de messages. Par ailleurs, pour pallier le Churn, LH ∗ utilise le calcul de parité hérité de la SDDS LH*RS. Le fichier supporte ainsi l’indisponibilité de n’importe quels k pairs, où k > 0. La valeur

de k est initialisée dès la création du fichier. Pour pallier l’accroissement de la probabilité d’indisponibilité de k pairs quand le fichier grandit, cette valeur peut également croitre dynamiquement, quel que soit k. Enfin, la structure offre un nouveau type de requêtes dites

sûres. Celles-ci protègent contre toute utilisation de données périmées d’un pair ‘revenant’.

L’ensemble de ces propriétés fait de LH ∗ une SDDS parmi les plus efficaces. À notre connaissance, la seule SDDS caractérisée par un seul renvoi au maximum est One Hope

Lookups, [GLR03]. Comme nous le discutons plus tard, elle est néanmoins bien plus couteuse en

nombre de messages de notification pour maintenir à jour les nœuds du réseau. Les autres variantes de LH* connues, notamment LH*RS, peuvent nécessiter deux renvois pour une requête

à clé et O(log N) rounds pour un scan, pour un fichier de N cases. D’autres SDDSs nécessitent davantage de messages. Notamment, celle dite Chord, particulièrement populaire malgré son coût de O(log N) d’une requête à clé, [SMK+01]. Enfin, nous ne connaissons actuellement aucune SDDS offrant les requêtes sûres.

(5)

La thèse est organisée en six chapitres. Nous commençons, dans le chapitre 1, par une introduction générale à notre travail. Le second chapitre contient l’état de l’art. Nous y présentons les principes fondamentaux des SDDSs et les différentes familles de celles-ci. Nous introduisons aussi les systèmes P2P ainsi que des SDDS dédiées. Nous nous limitons aux SDDSs ayant un intérêt pour notre travail. Le chapitre 3 présente la conception de LH ∗ , ses principaux algorithmes et propriétés que nous démontrons. Nous y définissons aussi une variante particulièrement importante de LH ∗ . Dans le chapitre 4, nous présentons notre prototype. Nous y définissons son architecture fonctionnelle globale et celles des pairs serveurs de données et des serveurs de parité. Nous donnons aussi la structure des divers protocoles spécifiques de

LH ∗ que nous avons introduit et de tout message échangé. Le chapitre 5 présente les mesures de performances validant notre conception et implémentation. Nous terminons par le chapitre 6, où nous présentons la synthèse de notre contribution et les perspectives des travaux futurs.

Notre travail a fait l’objet de quatre publications [YLS07, LYS08, Y08, YS10]. En particulier, l’article [Y08] publié dans ‘International Conference for Internet Technology and Secured Transactions (ICTST)’, a été jugé parmi les dix meilleures de cette conférence. Ces articles ont été sélectionnés pour être publié dans une version étendue dans ‘International Journal of Internet Technology and Secured Transactions’ (IJITST), [YS10].

Mots clés : Structure de données distribuée et scalable, SDDS, système pair à pair, P2P,

(6)

Abstract

: A new Scalable and Distributed Data Structure

for Peer to Peer System.

This Thesis presents a new scalable and distributed data structure (SDDS) for peer to peer environment (P2P) termed LH ∗ . A LH ∗ file is a set of records that contains data. Each record is identified by its primary key. A SDDS distributes its data records in memory buckets spread over the nodes of the P2P network. This distribution follows the linear hashing (LH*) principles. Each LH ∗ may scale dynamically with a split process and my spread over an unlimited number of nodes.

A SDDS file must deal with three major issues in P2P system. The first one is the efficiency of a key-based query. This may be an insert, search, update or delete of data record, each record has its own primary key. Each key-based query is sent to an identified data bucket. The second one is the efficiency of a scan. This type of query is sent to all nodes and known as ‘Map/Reduce’ query. The last one is fault-tolerance. The failure of node may happen because of network failure or failure of node. It may also happen by a voluntary of departure of the peer. This one may decide to back and give an out dated data. Thus, the data may be recovered and updated in meantime. This problem is known as a Churn.

LH ∗ insures that a key-based query needs one forward at maximum when an addressing error occurs. The scan query needs at maximum two rounds. LH ∗ copes with the Churn through the LH*RS management of unavailable data and parity buckets. As the result, the file

transparently supports unavailability or withdrawal of up to any k ≥ 1 peers, where k is a parameter that can scale dynamically with the file. LH ∗ gives a new query termed sure query. This protects against using outdated data.

LH ∗ properties make our structure one of the most efficient SDDS. Only One Hop

Lookups gives one forward of the key-based query [GLR03]. This structure needs a large number

of notification massages and implies a larger delay in propagating the notification. LH* and its variants like LH*RS may need two forward for a key-based query and O(log N) for a scan, N is a

number of nodes. Others structures may need more forward and messages like Chord. This is one of the most popular P2P structure, it needs O(log N) [SMK+01]. There is no known structure that gives sure queries.

The Thesis is structured in six chapters. We start by an introduction of our work. In the second chapter we present a state of the art that contains a presentation of the SDDS principals. Also, we introduce the P2P systems and well known P2P structures. In the third chapter, we present the LH ∗ algorithms, properties and a proof of each property. Also we give a new declustering schema of LH ∗ . In the fourth chapter, we present the functional architecture of our structure. The fifth chapter gives the performance measurements of LH ∗ prototype. Finally we conclude the Thesis and give some perspectives of research.

(7)

We have published four papers [YLS07, LYS08, Y08, YS10]. The [Y08] paper is published in international conference ‘International Conference for Internet Technology and Secured Transactions (ICTST)’. The paper is selected in the top ten best papers to be published in the International Journal of Internet Technology and Secured Transactions (IJITST) [YS10].

Key words: Scalable and distributed data structure, P2P system, distributed linear hashing

(8)

CHAPITRE I : Introduction

1. Motivation ... 1

2. Contribution ... 3

3. Plan de la Thèse ... 3

CHAPITRE II : les Structures de Données Distribuées et Scalables (SDDS) 1. Introduction ... 5

2. Architecture des Systèmes Informatiques ... 6

2.1. Architecture Client/serveur... 6

2.2. Architecture Pair-à-Pair ... 8

3. Les Structure de Données Distribuées et Scalables ... 11

3.1. Les Multi-Ordinateurs ... 11

3.2. Les Principes Architecturaux d’une SDDS ... 12

3.3. Caractéristiques d’une SDDS ... 13

3.3.1. La Scalabilité ... 13

3.3.2. La Disponibilité ... 14

3.4. Classification des SDDS ... 15

3.4.1. SDDS Basées sur les Arbres ... 15

3.4.2. SDDS Basées sur le Hachage : ... 17

3.5. Adaptation des Structures de Données aux Environnements Pair à Pair ... 17

3.6. RAM-Clouds ... 24

4. Résumé ... 25

CHAPITRE III : LH* Hachage Linéaire Scalable et Distribué Pair à Pair 1. Introduction ... 26

2. Terminologie de base de LH ∗ ... 27

3. Structure du Fichier LH ∗ ... 30

4. Adressage dans un Fichier LH ∗ ... 32

4.1. Expansion d’un Fichier ... 32

4.2. Adressage Global d’un Enregistrement à Clé... 34

4.3. Adressage sur le Composant Client ... 34

4.4. Adressage sur le Composant Serveur ... 35

(9)

5. La Recherche Scan ... 37

6. La Requête Sûre... 38

7. Expansion d’un fichier LH ∗ ... 40

7.1. Adjonction d’un pair ... 40

7.2. Éclatement d’une case LH ∗ ... 41

8. Propriétés de LH ∗ ... 45

9. Variante de LH ∗ ... 49

10. Résumé ... 53

CHAPITRE IV : Architecture Fonctionnel de LH* 1. Introduction ... 54

2. Architecture Fonctionnelle d’un Nœud LH ∗ ... 55

2.1. Pair LH ∗ ... 55

2.1.1. Application ... 57

2.1.2. Client LH ∗ ... 57

2.1.3. Serveur de Données LH ∗ ... 59

2.2. Serveur de Parité LH ∗ ... 60

2.3. Communication avec les Pairs Candidats ... 62

2.4. Architecture Interne d’un Pair LH ∗ ... 62

2.4.1. Client LH ∗ ... 63

2.4.2. Serveur de Données/Parité LH ∗ ... 64

3. Tables d’Adressage... 65

3.1. Adressage d’un Nœud LH ∗ ... 65

3.2. Table d’Adressage du Coordinateur ... 66

3.3. Table d’Adressage de la Recherche Sûre du Serveur de Parité ... 67

3.4. Table d’Adressage du Pair Pupille ... 67

3.5. Table d’Adressage du Pair de données ... 68

4. Structure de Messages ... 69

4.1. Déclaration de Candidature ... 69

4.2. Message du Coordinateur au Tuteur ... 69

4.3. Message du Tuteur au Pair Candidat ... 70

4.4. Message de Notification d’Éclatement ... 70

(10)

4.6. Message de la Recherche Sûre ... 71

4.7. Message d’Insertion d’Enregistrement de Tutorat ... 71

4.8. Message Recherche Scan... 72

5. Protocoles d’Échange de Messages de LH ∗ ... 72

5.1. Enregistrement de Pairs Candidats ... 72

5.2. Insertion d’Enregistrement de Tutorat ... 74

5.3. Recherche Scan... 75

5.4. Éclatement de Pair ... 76

5.5. Rechercher sûre ... 78

6. Résumé ... 79

CHAPITRE V : Mesures de Performances de LH* 1. Introduction ... 80

2. Configuration de l’Environnement Expérimental ... 81

3. Lancement du prototype ... 81

4. Création du Fichier par un Flux d’Insertions... 82

5. Requête de Recherche ... 83

6. Requête de Recherche Sûre ... 85

7. Résumé ... 87

CHAPITRE VI : Conclusion et Travaux Futurs 1. Conclusion ... 88

2. Perspective ... 89

2.1. Vulnérabilité du Coordinateur ... 89

2.1.1. Réplication du Coordinateur ... 89

2.1.2. Schéma LH ∗ sans coordinateur ... 89

2.2. Requêtes Sûres ... 89

2.3. Haute Disponibilité ... 89

2.4. Implémentation Réelle ... 90

(11)

Table des Figures

Figure 1. Prévision des lois de Moore et Gilder, [A01] ... 2

Figure 2. Architecture Client/Serveur ... 6

Figure 3. Vu d’un Cloud Computing ... 7

Figure 4. Architecture Générale d’un Système P2P ... 9

Figure 5. Architecture générale d’un système à base de SDDS ... 12

Figure 6. Facteur d’échelle ... 14

Figure 7. Facteur de rapidité ... 14

Figure 8. Classification des SDDS ... 15

Figure 9. Architecture de Chord, [SMK+01] ... 18

Figure 10. Tables de routages dans Chord, [SMK+01] ... 19

Figure 11. Découpage statique de l’anneau en Tranches, [GLR03] ... 21

Figure 12. Découpage d’un Tranche en Units ... 21

Figure 13. Diffusion d’un message de notification, [GLR03] ... 22

Figure 14. Structure de BATON, [JOV05] ... 23

Figure 15. Restructuration suite à un départ d’un nœud, [JOV05]... 24

Figure 16. Serveurs de stockage et de reprise, [OAE+10] ... 25

Figure 17. Terminologie de base de LH ∗ ... 27

Figure 18. Architecture d’un pair ... 28

Figure 19. Différents états d’un pair LH ∗ ... 29

Figure 20. Structure d’un Fichier LH ∗ en Groupe de Parité ... 30

Figure 21. Un groupe de parité avec m = 4 et k = 2 ... 31

Figure 22. Enregistrement du fichier LH ∗ ... 31

Figure 23. Paramètre d’Adressage d’un pair LH ∗ ... 35

Figure 24. Éclatement dansLH ∗ { = = }, (a) avant (b) après ... 42

Figure 25. État initial du fichier... 44

Figure 26. Fichier à deux cases de données... 44

Figure 27. Fichier à trois cases de données ... 45

Figure 28. Fichier à quatre cases de données ... 45

Figure 29. Régions d’adressages sans renvois ... 46

(12)

Table des Figures

Figure 31. Régions d’adressage avec la possibilité de renvoi ... 48

Figure 32. Schéma de distribution de parités (m=4, k=2) ... 52

Figure 33. Architecture fonctionnelle d’un pair de données LH ∗ ... 56

Figure 34. Organisation d’une case de données LH ∗ versus LH ∗ ... 59

Figure 35. Architecture fonctionnelle d’un pair de parité LH ∗ ... 60

Figure 36. Architecture d’un pair LH ∗ pour la variante de distribution de parité ... 61

Figure 37. Architecture du client ... 63

Figure 38. Architecture du serveur de données versus serveur de parité [M04] ... 64

Figure 39. Table des Adresses des Entités (TAE) ... 66

Figure 40. Table des Cases de Données (TCD)... 66

Figure 41. Table des Tuteurs et Pupilles (TTP)... 67

Figure 42. Table des Cases Reconstruites (RP) ... 67

Figure 43. Table d’Adressage Pupille (TAP) ... 68

Figure 44. Protocole d’adjonction d’un pair candidat ... 73

Figure 45. Insertion d’un enregistrement de données... 74

Figure 46. Insertion d’un enregistrement de tutorat ... 75

Figure 47. Recherche scan ... 76

Figure 48. Éclatement dans LH ∗ ... 77

Figure 49. Recherche Sûre... 78

Figure 50. Création de fichier k-disponible (k=0, k=1, k=2), [M04] ... 83

Figure 51. Recherche à clé ... 85

Figure 52. Temps total de réponse pour la recherche sûre et simple... 86

(13)

Chapitre

I

Introduction

1.

Motivation

La décennie 2000 a été dominée par le développement et la vulgarisation du concept de multi ordinateur qui s’est décliné en plusieurs architectures : grille (Anglais : Grid), pair à pair et récemment nuage (Anglais : Cloud). Les politiques de gestion des systèmes d’informations des organisations se sont mises à intégrer ces architectures à tous les niveaux, que ce soit dans l’administration, le commercial et bien d’autres domaines organisationnels.

Les besoins de ces organisations sont devenus de plus en plus demandeurs d'espace de stockage. Le stockage physique de données n’était pas un problème et ne l’est toujours pas de nos jours. La loi de Moore [M65] [M03] annonçait en effet :

• Chaque nouveau circuit contient deux fois plus de transistors que sa version précédente. La densité de transistors pour une surface donnée croit d'un facteur 2 tous les 12 mois

• Une nouvelle génération de microprocesseurs est lancée en moyenne tous les dix-huit mois.

Cette loi a toujours été vérifiée et continue de l’être. De plus un multi-ordinateur constitue un espace de stockage très étendu.

La loi de Gilder annonçait [G97] également que pour les vingt-cinq années à venir la bande passante des réseaux triplerait, à prix égal tous les ans, et que le débit de transmission quadruplerait tous les trois ans.

La Figure 1 ci-après montre les prévisions des lois de Moore et de Glider. Celles-ci ont toujours été vérifiées au fil des années.

Les multi-ordinateurs, toutes architectures confondues, exigent de nouvelles organisations de données, qui doivent répondre à de nombreux impératifs, tels que le stockage de grands volumes, l’adressage décentralisé, la scalabilité, la haute disponibilité et la sécurité accrue. Pour répondre à ces exigences, Litwin et al. ont proposé et développé une nouvelle classe de structures de données dite Structures de Données Distribuées et Scalables (SDDSs) [LSN93].

Les recherches sur les SDDSs ont concerné divers types de projets informatiques tels que les prototypes de systèmes de fichiers distribués (SFD) ainsi que les systèmes de gestion de bases de données (SGBD).

(14)

Figure 1. Prévision des lois de Moore et Gilder, [A01]

Les données d’une SDDS et notamment d’un fichier SDDS, sont supposées être réparties sur les sites de stockage du multi-ordinateur que sont les serveurs. Pour leur traitement les données sont rangées dans les mémoires vives de ces serveurs. Elles sont alors dix à cent fois plus rapidement accessibles qu’à partir de disques. Ces données peuvent être manipulées par différentes applications à partir de sites appelés clients. Ces clients gèrent ainsi l’accès mais ne stockent pas de données de la SDDS. Certains sites assurent tout de même les deux fonctions à la fois, ils sont dits sites pairs. Les SDDS doivent pouvoir s’adapter dynamiquement à l’accroissement du volume des données. Le fichier devra donc s’étendre de manière progressive d’un seul site serveur ou pair à, théoriquement, un nombre illimité de tels sites. Le placement de données d’une SDDS et son évolution doivent rester transparents pour les applications. Les utilisateurs peuvent ainsi manipuler les données d’une SDDS, via une interface offerte par un client. Comme pour un fichier centralisé les opérations de manipulation sont ; la création, la recherche, l’insertion, la mise à jour et la suppression.

Parmi les SDDS les plus connues, citons LH* [LSN93] et RP ∗ [LSN94] qui ont été parmi

les premières à être déployées sur les architectures Client/Serveur. LH*RS [LMS02] est quant

à elle connue pour la haute disponibilité des données. Elle est parmi les implémentations les plus récentes. Chord [SMK+01], BATON [JOV05], VBI-Tree [JOV06] et OHL pour ‘One Hop Lookups’ [GLR03] pour les architectures pair à pair.

Une propriété générale de toutes les SDDS est que l’adressage à partir d’une clé peut nécessiter des messages de renvois entre les serveurs/pairs. LH* garantit un coût de deux renvois au maximum, quel que soit le nombre de serveurs de la SDDS. Aucun autre système n’a, jusqu’ici, réalisé un coût plus bas.

(15)

Cependant, le nombre de ces renvois est de l’ordre O(Log N) pour les autres SDDS pair à pair citées, N étant le nombre de nœuds du réseau, à l’exception de la SDDS OHL [GLR03] qui est de O(1).

2.

Contribution

Dans cette thèse, nous nous intéressons plus particulièrement aux problèmes qui guettent les architectures pair-à-pair, ‘Grid’ et ‘Cloud’. La recherche de données devient de plus en plus rapide vu le haut débit des réseaux sur Internet. Néanmoins, un problème majeur continue d’affecter les recherches à clé, celui du nombre de renvois générés suite à une erreur d’adressage d’une requête à clé. Nous basons notre solution sur la structure LH*RS que nous

adaptons aux environnements pair à pair. Ce nouvel algorithme, appelé LH ∗ , garantit un

seul renvoi pour rester plus simple que l’algorithme OHL [GLR03]. Ce résultat est impossible à améliorer dans la mesure où la borne de ‘zéro renvoi’ conduirait nécessairement à une architecture centralisée. Rigaux et al. ont dressé un constat sur la gestion des données dans le web [AMR+11]. Les auteurs n’ont pas manqué de citer les SDDS les plus connues dont celle sur lequel notre travail est basé, LH*.

Notre démarche est simple. Nous utilisons l’expansion du fichier SDDS et les erreurs d’adressage pour mettre à jour l’image d’adressage des pairs impliqués dans le processus. À chaque fois qu’un pair, avec une case de données d’une capacité ‘b’ atteint sa limite de stockage il éclate et transfert la moitié de ses données vers un nouveau pair. Lors de cet éclatement, nous mettons à jour son image d’adressage ainsi que l’image des pairs qui sont à sa charge, appelés pupilles, s’ils existent.

Un second problème découle du Churn, qui concerne toutes les architectures pair à pair, compte tenu leur propriété dynamique. Un pair quelconque peut rejoindre un réseau pair à pair et le quitter sans prévenir à la suite d’une panne ou déconnexion volontaire. Nous proposons ici le concept de requêtes sûres pour pallier ce problème. Ces requêtes sûres peuvent être des recherches, des insertions, des mises à jour ou des suppressions d’enregistrement de données. Elles permettent d’identifier si un pair portant une case de données a été reconstruit suite à son indisponibilité. Si tel est le cas, le pair qui était indisponible obtient la nouvelle mise à jour corrective. Grâce à cela, les requêtes sûres peuvent ainsi garantir l’exécution correcte de toutes les requêtes en toutes circonstances.

3.

Plan de la Thèse

La suite de cette thèse est organisée en six chapitres. Après avoir introduit notre travail, nous faisons l’état de l’art dans chapitre 2. Nous y présentons les principes fondamentaux des SDDSs et différentes familles de celles-ci. Nous présentons aussi les systèmes P2P ainsi que des SDDS dédiées, les plus connues ou étant d’intérêt pour notre travail. Le Chapitre 3 présente la conception de LH ∗ , les principaux algorithmes et ses propriétés. Dans ce chapitre nous démontrons chaque propriété. Nous y définissons aussi une variante particulièrement importante de LH ∗ . Dans le quatrième chapitre, nous présentons notre prototype. Nous y définissons son architecture fonctionnelle globale et celles de pairs serveurs de données et de serveurs de parité. Nous donnons aussi la structure des divers protocoles

(16)

spécifiques de LH ∗ que nous avons introduit et de tout message échangé notamment. Le Chapitre 5 présente les mesures de performances validant notre conception et implémentation. Nous terminons par le Chapitre 6 où nous présentons la synthèse de notre contribution et ses perspectives.

(17)

Chapitre

II

Les Structures de Données

Distribuées et Scalable (SDDS)

1.

Introduction

La performance des réseaux a connu des améliorations importantes ces dernières années avec des débits de plus en plus élevés, conséquence de l'augmentation de la vitesse des CPU, de la taille des RAM et la performance des réseaux de télécommunication. Cependant, les disques durs, limités par des contraintes mécaniques n'ont pas atteint le même succès du point de vue temps d’accès (lecture/écriture) aux données stockées. Dans le but d’améliorer les temps d’accès et assurer la disponibilité des données en cas de panne plusieurs projets informatiques ont été lancés. De là, vient l’idée d’exploiter les performances des multi-ordinateurs et en particulier les structures de données distribuées pour l’organisation des données stockées.

En effet, les multi-ordinateurs constituent la solution idéale pour garantir le partage des données et leurs disponibilités en cas de panne. Cependant le problème d’accès aux données stockées sur disque et leurs disponibilités se pose toujours. Les Structures de Données Scalables et Distribuées ou SDDS (Anglais : Scalable and Distributed Data Structures) ont été introduites comme solution pour organiser ces données et garantir leurs disponibilités en cas de panne d’un ou plusieurs nœuds. Les SDDSs utilisent la RAM de chaque nœud constituant le multi-ordinateur pour le stockage des données. Les premières SDDSs ont été présenté dans [LNS93a, LNS93b].

Les SDDS assurent des temps d’accès aux données beaucoup plus courts que les disques durs du fait du stockage sur la mémoire vive, RAM. De plus ces nouvelles structures disposent :

• De plus du traitement parallèle, car les requêtes peuvent s’exécuter sur chaque

nœud du multi-ordinateur sans avoir un goulot d’étranglement.

• D’une capacité de stockage potentiellement illimitée car il suffit de connecter de nouveaux ordinateurs au réseau.

Ces caractéristiques assurent aux SDDS des performances de traitement largement supérieures à celles des structures de données traditionnelles.

(18)

Nous présentons ci-après la typologie générale des réseaux puis des multi-ordinateurs. Ensuite, nous décrivons les SDDS et leurs caractéristiques. Nous nous intéresserons particulièrement à une SDDS appelée LH*RS [LMS04], sur laquelle repose en partie notre

travail.

2.

Architecture des Systèmes Informatiques

Avant de présenter les principes généraux des structures de données et distribuées nous allons faire la présentation des différentes typologies des réseaux information. Ces architectures principales sont utilisées dans les systèmes de gestion de base de données [GG96] [G97].

2.1.

Architecture Client/serveur

Cette architecture se présente en un modèle qui met en jeu une répartition de rôles entre serveurs et clients. Les clients constituent un support pour les applications et les interfaces utilisateurs. Ils envoient leurs requêtes aux serveurs. Les serveurs gèrent les données, gèrent les transactions, l’optimisation et sécurité des données. Ils effectuent le traitement des requêtes émises par les clients et retournent les réponses. La Figure 2 ci-après présente l’exemple d’une telle architecture.

Figure 2. Architecture Client/Serveur

Plusieurs variantes de cette architecture peuvent être mises en évidence :

• L’architecture mono-tâche : Un serveur exécute les requêtes une par une. L’inconvénient majeur de cette architecture ne diffère pas trop de celui des bases de

Client

Client

Client

Client

Client

Client

Client

Client

S er v eu r ce n tr a l

(19)

données centralisées puisque la base est stockée sur seulement une machine (le serveur).

• L’architecture multitâche. Un serveur est capable de traiter plusieurs requêtes clients en parallèle. Une telle architecture permet de meilleures performances en présence d’un nombre important d’utilisateurs. Cependant, elle peut conduire à un client lourd si chaque client gère ses propres connexions à son serveur plus les traitements des données ou à un client léger si les traitements de gestion sont concentrés sur les serveurs.

Ces architectures ont été les premières à être utilisées pour la généralisation et la distribution des structures de données classiques dont Internet était le précurseur.

En effet, Internet a permis le développement des applications client/serveur. Toutefois, ces dernières années, Nous avons vu la démocratisation du concept du Cloud Computing (Nuage). Il s’agit d’un concept de déportation, sur des serveurs distants, des traitements et services informatiques usuellement localiser sur le poste de l’utilisateur. L’utilisateur peut être une personne physique ou une entreprise qui utilisera ces traitements et services en ligne via Internet de manière évolutive et sans s’occuper de la gestion de l’infrastructure qui représente des coûts financiers souvent importants.

Les données et les applications dont l’utilisateur se sert ne sont plus sur sa machine locale mais sur des serveurs distants interconnectés via une excellente bande passante. On dit que les données et applications sont sur un Cloud. Plusieurs acteurs et promoteurs de ce concept se sont déjà lancés dans cette nouvelle technologie de traitement de données, tel que Google, Amazon, Microsoft et tant d’autres. Exemple en Figure 3, ci-après.

Figure 3. Vu d’un Cloud Computing Google

Amazon

Microsoft Salesforce

(20)

Le Cloud Computing peut également libérer l’utilisateur des contraintes de capacité de mémoire vives. C’est le cas du RAM-Clouds [OAE+10] proposé par Ousterhout et son équipe de l’université Stanford. Leur solution permet d’étendre au Cloud toutes les techniques de mémoire distribuée telle que LH* [LNS93], RP* [LNS94], CTH* [Z04] dont nous reparlerons plus tard.

2.2.

Architecture Pair-à-Pair

Le Pair-à-Pair [S01] (Anglais : Peer to Peer noté P2P) est un réseau de nœuds, où chaque nœud joue le rôle d’un Client et d’un Serveur en même temps, voir Figure 4. Cette architecture P2P de réseau s’est imposée comme technologie de référence pour le partage de ressources multimédia. Nous pouvons classifier les réseaux P2P en 3 types :

• L’architecture non structurée : tous les nœuds sont au même niveau sur le réseau logique. Il n’y a pas de hiérarchie. La recherche de données s’effectue par diffusion aux nœuds voisins de la requête (Anglais : Flooding). Le temps de recherche est difficile à évaluer.

• L’architecture structurée : les nœuds sont organisés suivant une structure de données telle que le Table de Hachage Distribuée, de Hachage Linaire, des arbres de recherches binaires ou tant d’autres que nous citerons par la suite. Les données sont stockées sur les nœuds. Le temps de recherche est estimé à O(log N), où N est le nombre de nœuds du réseau. Nous verrons que la structure de données que nous traitons dans cette thèse permet de garantir un temps de recherche de O(1).

L’architecture hybride : certains nœuds sont dits Super-Pair. Ils gèrent les index des données des autres nœuds et le routage du réseau. Le temps de recherche est partiellement garanti.

Pourquoi l’utilisation des systèmes P2P? Pour plusieurs raison les réseaux P2P se sont généralisés et ce malgré leurs inconvénients :

• Avantages :

o Alternative du Client/Serveur

o Autonomie des nœuds

o Rapidité de mise en place à moindre coût (finance)

o Échange de données rapide en profitant de bande passante

o Équilibrage de charge

• Inconvénients :

o Sécurité des accès, que nous ne traiterons pas dans notre travail.

o Churn, un phénomène non déterministe d’arrivée et de départ de pairs du réseau. Nous traitons ce problème dans le chapitre suivant.

o Absence d’applications pour la gestion de données dans un tel environnement.

(21)

Figure 4. Architecture Générale d’un Système P2P

La suite de notre développement de la thèse s’intéresse plus particulièrement à l’architecture P2P structurée. Avant cela nous rappelons le concept des SDDS qui constitue le fondement de notre travail.

2.2.1.1.Le Churn

L’une des caractéristiques d’un environnement pair à pair est la dynamique de l’adjonction et départ de pairs. Ce phénomène est connu en anglais comme le Churn. Farsite [DH06] [BDH07] offre un bon exemple de Churn dans le contexte d’un système pair à pair de fichiers distribués. Farsite range tous ses fichiers et répertoires sur des pairs, qui peuvent donc se déconnecter à tout moment du réseau. Ces déconnexions apparaissent à Farsite comme des pannes et doivent être traitées comme telles. Toute application pair à pair réelle (ex. Gnutella [KM02], FastTrack [KAZ03], BitTorrent [B02]), (indépendamment de la conception théorique de l’application) est confrontée au Churn. Des études de mesures du Churn ont été réalisées pour mesurer la durée de vie d’un pair sur le réseau [RGRK04] [SR06].

Par définition le temps de session est le temps qui s’écoule entre le moment où un pair se connecte au réseau et le temps de sa déconnexion. La durée de vie d’un pair est l’intervalle de temps entre sa première connexion au réseau et l’instant où le pair quitte définitivement le réseau. Idéalement, un pair devrait rester toujours connecté durant sa durée de vie. Ce n’est pas le cas toujours le cas pour des raisons de panne du pair, d’indisponibilités du réseau ou de déconnexions volontaires. La disponibilité d’un pair est donc la somme des temps de sessions divisée par la durée de vie du pair [RGRK04]. La Table 1, ci-après, présente le temps de session des pairs dans différents systèmes pair-à-pair, qui sont tous des systèmes de distribution de fichier où chaque fichier réside sur un seul pair. Comme nous le constatons, Table 1, ces temps de session varient de système en système. Gnutella et Napster offrent un

(22)

temps de disponibilité inférieur à 60 minutes pour 50% des pairs initialement connectés au réseau. FastTrack offre un temps de session inférieur ou égal à une minute pour 50% de ses pairs, ce qui est très court. Kazaa [KAZ03], lui aussi offre des temps de session très courts parce qu’il utilise le même protocole de partage que FastTrack. Ainsi, le temps de session est variable selon le profil de l’utilisateur utilisant son pair pour la recherche de fichier ou son téléchargement.

Auteur Système observé Temps de session Saroiu [SGG02] Gnutella, Napster 50% ≤ 60 min Chu [CLL02] Gnutella, Napster 31% ≤ 10 min Sen [SW02] FastTrack 50 % ≤ 1 min Bhagwan [BSV03] Overnet 50 % ≤ 60 min Gummadi [GDS+03] Kazaa 50 % ≤ 2,4 min

Table 1. Temps de Session par système Pair-à-Pair, [RGRK04]

Une étude plus poussée du Churn est présenté par Godfrey, Shenker et Stoica [GSS06] comme le montre la Table 2. Cette étude se base sur l’analyse des traces d’exécution (Anglais : Traces) de cinq systèmes. La colonne durée représente le temps de mesure pendant lequel la disponibilité de chaque machine est testée par l’envoi d’un ‘Ping’. La seconde colonne représente le nombre moyen de nœuds en marche. La dernière représente le temps moyen d’une session par nœud. Ainsi, pour PlanetLab [BBC+04], environ 50% des nœuds présentent un temps moyen d’indisponibilité de 3,9 jours. Plus de détails sont présentés dans [GSS06] quant à la simulation faite avec les traces de disponibilité (Anglais : Availability Traces).

L’efficacité d’une application pair à pair dépend de la manière dont celle-ci gère le Churn pour garantir la disponibilité des données après le départ ou panne d’un pair.

Trace Durée (jours) Moyenne de nœuds en marche ‘modes up’

Moyenne temps de session par nœud

PlanetLab 527 303 3,9 jours

Web sites 210 113 29 heures

Microsoft PCs 35 41970 5,8 jours

Skype 25 710 11,5 heures

Gnutella 2,5 1846 1,8 heure

(23)

3.

Les Structure de Données Distribuées et Scalables

Une SDDS se base sur une structure de données classique. C’est la généralisation de celle-ci sur un multi-ordinateur qui en fait d’elle une structure scalable et distribué. Cette section présente la définition d’un multi-ordinateur, les principes généraux et caractéristique d’une SDDS, enfin la classification des SDDS.

3.1.

Les Multi-Ordinateurs

Un multi-ordinateur est une collection d'ordinateurs sans mémoire partagée. Ces ordinateurs sont reliés par un réseau de type LAN ou WAN (Anglais : Local Area Network, Wide Area Network) ou encore par un bus [T85]. La puissance théorique cumulée des ressources en calcul et en mémoire d’un multi-ordinateur est impossible à atteindre par un ordinateur traditionnel. Cette perspective a permis de favoriser l'apparition de plusieurs projets de recherche autour de la conception et la mise en œuvre d’un multi-ordinateur. L'un des axes de recherche majeur a été la construction de systèmes de gestion de fichiers scalables et distribués dont le traitement est entièrement en RAM distribuée du multi-ordinateur. Grâce à l’amélioration de la vitesse des réseaux, les temps d’accès à une mémoire vive distante est aujourd’hui plus court que le temps d’accès à un disque local comme le montre la Table 3. Ainsi l’accès à un enregistrement sur RAM d’un ordinateur en local nécessite 100 nanosecondes contre 10 à 100 microsecondes pour un enregistrement stocké en RAM distante connectée en réseau et enfin de 10 millisecondes pour un enregistrement stocké sur le disque local d’un ordinateur.

Gray et Garcia-Molina ont présenté les avantages et l’intérêt de l’utilisation des RAM comme support de stockage par rapport aux disques dures, [G78] et [GLV84]. Aujourd’hui l’utilisation de nouveaux supports tels que les disques de type SDD (Solide-State-Drive) est chose faite offrant un temps d’accès entre 35 et 100 microsecondes contre 500 et 10000 microsecondes pour les disques durs classiques. Sachant que le temps de lecture est plus rapide que le temps d’écriture sur les deux supports et que ces temps dépendent de la technologie des constructeurs. La nouvelle génération de stockage de données sera sans doute les RAM qui ne cessent de se développer avec une capacité de stockage de plus en plus grande et une rapidité d’accès de plus en plus performante.

Toutefois, la conception d’un multi-ordinateur nécessite la réfection de logiciels système. Ils sont à faire ou à refaire, notamment les systèmes de gestion de fichiers, les systèmes de gestion de base de données et autres applications Web.

Ressource RAM locale

RAM distante (réseau gigabit) RAM distante (Ethernet) Disque local

Temps d’accès 100 nsecs 1 µsecs 100 µsecs 10 msec Table 3. Estimation des temps d'accès aux données.

(24)

3.2.

Les Principes Architecturaux d’une SDDS

Les SDDS constituent une nouvelle famille de structures de données, basées sur le modèle client/serveur. Elles stockent les données dans des cases (Anglais : Bucket) sur des sites appelés serveurs, d’autres sites appelés clients y accèdent. Les sites clients gardent des paramètres pour le calcul de l'adresse des fichiers sur les sites serveurs. Ces paramètres constituent l'image du client sur le fichier SDDS. Le client fournit une application pour les utilisateurs pour se connecter au réseau, c’est l’interface Client/Utilisateurs. Ainsi ils pourront accéder aux données sauvegardées dans les cases de données (Anglais : Data Buckets) logées sur les serveurs. Il faut noter que l’accès aux données est fait de manière transparente pour l’utilisateur. La Figure 5 montre l’architecture d’un système à base d’une SDDS. Plusieurs schémas et d’architectures sont définis selon la structure de données utilisée pour gérer les données sur le réseau. Cependant le principe est le même, Client/Server. Dans ce qui suit, nous distinguerons l’évolution de cette architecture et la généralisation des structures de données aux systèmes Pair-à-Pair.

Un fichier SDDS contient des données typiquement sous la forme d'enregistrements ou bien d'articles identifiés par une clé primaire ou par plusieurs clés. Le stockage de ces données débute sur un serveur et peut être étendu par des insertions, théoriquement à un nombre quelconque de ceux-ci. Ce qui rend la capacité de stockage d’une SDDS potentiellement illimitée. Cette nouvelle structure dispose aussi du traitement parallèle, ce qui fait que l'augmentation de la taille des données ne détériore pas les performances d’accès.

Il est utile que les données d'une SDDS résident pour le traitement en mémoire vive distribuée du multi-ordinateur. Comme nous venons de le voir, le temps d'accès aux données en mémoire vive distribuée est bien plus court que celui des données stockées sur disque. Plusieurs SDDS ont été conçu sur ce principe, nous les présentons dans la Section 3.4.

Figure 5. Architecture générale d’un système à base de SDDS

A p p li ca ti o n Client 0 A p p li ca ti o n Client 1 A p p li ca ti o n Client M Réseau Ca se 0 Ca se 1 Ca se N U ti li sa te u rs Serveur 0 Serveur 1 Serveur N

(25)

Plusieurs prototypes ont montré que toutes ces caractéristiques peuvent assurer à une SDDS des performances supérieures à celles des structures de données classiques. L’architecture de toute SDDS se base également sur les principes suivants, [LNS94, KLR94] : Un fichier SDDS n’a pas de répertoire central d’accès, ce qui évite d’avoir des points d’accumulation, qui engendreraient des goulots d’étranglement et dégraderaient les temps d’accès aux données du fichier.

Les fichiers SDDS croissent et s’étendent suite à des insertions d’une manière incrémentale et transparente pour l’application (client). Il débute généralement sur un seul site (serveur) initial de stockage jusqu'à la surcharge de ce dernier. Le fichier est alors étendu par un éclatement qui transfert la moitié des données vers un autre site de stockage. Ainsi le fichier peut s’étendre progressivement à un nombre théoriquement illimité de sites (serveurs).

Les serveurs constituant le fichier SDDS interagissent avec des applications autonomes appelées ‘clients’. Chaque client supporte le logiciel propre aux SDDS et gère notamment sa propre image de la structure du fichier SDDS. Puisque les modifications du schéma de la structure du fichier SDDS, dues aux éclatements, ne sont pas diffusées d’une manière synchrone aux clients, cette image peut être inexacte. De ce fait, un client est susceptible de faire des erreurs d’adressage et d’envoyer une requête à un serveur incorrect.

Chaque serveur est capable de détecter une erreur d’adressage le concernant. Lorsqu’une erreur est détectée alors la requête est redirigée vers un autre serveur. Si le nouveau serveur n’est toujours pas le bon alors d’autres redirections peuvent survenir. Toute bonne SDDS doit à la fois minimiser le nombre de redirections et corriger toute erreur de routage. Le bon serveur participant au processus de redirection doit, pour cela, envoyer un message correctif noté IAM (Anglais :

Image Adjustment Message) au client ayant fait l’erreur d’adressage. Lui

permettant d’ajuster son image.

3.3.

Caractéristiques d’une SDDS

Une SDDS peut posséder plusieurs caractéristiques qui découlent essentiellement des systèmes distribués [LNS96, L97]. Il s’agit principalement de scalabilité et la disponibilité.

3.3.1.

La Scalabilité

Un système est dit scalable lorsqu’il s’adapte à la taille des fichiers qu’il gère de telle manière que ses temps de réponse puissent restés constants [G93]. Deux facteurs principaux caractérisent la scalabilité d’un système [G93] [G99]. Ce sont :

Le facteur d’échelle (Anglais : Scale-up factor) est le ratio entre le temps de réponse d’une application et le nombre de serveurs alloués à cette application. Idéalement, ce facteur devrait être constant, ce qui est le cas lorsqu’il y a une relation linéaire entre le nombre de serveurs alloués à une application et son temps de réponse. Ce n’est pas toujours le cas comme le montre la Figure 6. Il y a des cas où une augmentation du nombre des serveurs proportionnelle à la charge ne suffit

(26)

pas à maintenir le temps de réponse. Nous nous trouvons alors en présence d’un système sous-linéaire.

Figure 6. Facteur d’échelle

Le facteur de rapidité (Anglais : Speed-up factor) : mesure la diminution possible du temps de réponse à charge constante lorsqu’on augmente le nombre de serveurs. Idéalement ce facteur de rapidité est linaire ; si nous multiplions par un facteur n le nombre des serveurs, le nombre total d’opérations par seconde exécutées par le système devrait être multiplié par le même facteur n. Comme la Figure 7 nous le montre, ce n’est pas toujours le cas. Nous nous trouvons alors en présence d’un facteur de rapidité sous linéaire.

Figure 7. Facteur de rapidité

3.3.2.

La Disponibilité

Lorsqu’une structure de données (ou un fichier) s’étend sur plusieurs serveurs, la probabilité qu'elle ne soit pas entièrement disponible à un moment donné augmente. Par exemple, si n est le nombre de serveurs, et p la probabilité pour qu'un serveur soit en service, alors la probabilité p(n) pour que la structure entièrement soit disponible est . Si = 0.98

et $ = 10, alors ($) = 0.81. Si $ = 100 alors ($) = 0.00000000168, environ zéro

Quantité de Données Linéaire(idéal) sous-linéaire (usuelle) Scale-up Lin éair e (id éal)

(27)

[LRR97]. Un moyen de résoudre le problème de la disponibilité est d'ajouter des serveurs de parité à la structure distribuée [LS00]. Ce problème de disponibilité concerne aussi les architectures P2P.

3.4.

Classification des SDDS

La plus part des travaux dans le domaine des SDDS consistent à partir d’une structure de données classique et de tenter de l’adapter aux environnements distribués. C’est le cas, pratiquement de toutes les SDDS proposées jusqu’à présent.

Selon l’organisation interne des données et le mécanisme qui permet d’y accéder, les SDDS peuvent être classées en plusieurs catégories, comme le montre la Figure 8 ci-après. Nous allons détailler ces catégories maintenant.

Figure 8. Classification des SDDS

3.4.1.

SDDS Basées sur les Arbres

Les structures de données ordonnées telles que les B-arbres [B71] sont les plus utilisé lorsque le fichier doit supporter des requêtes par intervalle sur des données uni-dimensionnelles, des parcours transversaux des enregistrements ou des recherches d’enregistrements les plus proches (Anglais : Nearest,Neighborsearch). Litwin, Neima et Schneider ont proposé une famille de SDDS pour les fichiers (mono-clés) ordonnés, appelée RP* pour ‘Distributed and Scalable RangePartitioning’ [LNS94], dite aussi partitionnement par intervalle. Cette famille comprend plusieurs variantes [LNS94] telles que : RP*N (No

index), RP*C (Client index) et RP*S (Server index). Le but majeur de RP* et ses variantes est

Structures de données Classiques SDDS (1993) Arbres Hachages • Unidimensionnelle (RP*, BATON) • Multidimensionnelle (k-RP*, DRT et DRT*, VBI-Tree) • Unidimensionnelle : o (LH*, LH*LH, DDH, EH*), o (LH*M, LH*G, LH*S, LH*SA, LH*RS) • Multidimensionnelle (IH*)

(28)

de construire des fichiers distribués qui préservent l’ordre des enregistrements. RP* partitionne ses fichiers en intervalles définis par les valeurs d’une clé et assigne à chaque serveur un intervalle [Clémin, Clémax] différent.

A)RP*N (No index)

En l’absence d’index, tout client envoie ses requêtes par messages multicast car ils s’adressent à ensemble des serveurs qui appartiennent à un même groupe de réseau donné. Tout serveur ayant reçu le message vérifie si la clé de l’enregistrement demandé appartient à son intervalle. Si oui, l’enregistrement est retourné au client sinon la requête est négligée.

B)RP*C (Client index)

Dans cette variante chaque client possède un index explicitant quel nœud a chaque intervalle de clés. Grâce à cet index, les clients peuvent envoyer leurs requêtes par messages unicast (message point à point destiné à un seul serveur). Un client peut faire une erreur d’adressage par suite d’une image inadéquate. Dans ce cas, le serveur recevant la requête la redirige par multicast. Celui qui exécute la requête du client lui répond et lui adresse un IAM.

C)RP*S (Server index)

Cette dernière variante introduit une image du fichier SDDS au niveau même des serveurs. La redirection en cas d’erreur se fait par messages unicast. L’image sur les serveurs est construite sous la forme d’un index B-arbre distribué sur le réseau [AWD01]. L’index est construit sur la distribution des clés des enregistrements de données. Cet index est paginé et chaque page est stocké sur un serveur séparé. Nous distinguons, les serveurs d’index des serveurs de cases de données.

Une extension RP* aux fichiers multi-attributs a donné naissance à la famille k-RP*S qui

est donc une version multidimensionnelle de RP* [LN95]. Dans cette SDDS, nous trouvons des serveurs pour le stockage de données (Anglais : Bucket Servers) et des serveurs d’index (Anglais : Index Servers).

Une autre SDDS pour les fichiers ordonnés, appelée DRT (Anglais : Distributed Random Search Tree), a été proposée par Kröll et Widmayer [KW94]. DRT utilise une version distribuée des arbres binaires de recherche (Anglais : Binary Search Tree) pour l’accès aux données à partir des clients et des serveurs. DRT* est une amélioration du DRT.

Litwin, Neimat, Schneider ont montré que DRT et RP* permettent toutes les deux de construire des fichiers plus larges et plus rapides par rapport aux structures de données traditionnelles [LNS96].

RP* est utilisé pour implémenter le système de fichiers distribués et scalables ‘SDDS 2005’ [LMS03]. Litwin et Sahri ont utilisé ces même principes pour l’implémentation du nouveau système de gestion de bases de données SD-SQL Server (Anglais : Scalable and Distributed SQL Server) [LS02]. Le partitionnement de la famille de RP* est utilisé par les chercheurs de Google dans leur système Google File System (GFS) [GGL03] et Bigtable [CDG+08].

(29)

3.4.2.

SDDS Basées sur le Hachage :

Elles constituent une extension des schémas de hachage classiques sur les multi-ordinateurs. Nous avons :

LH* (Scalable and Distibuted Linear Hashing) [LNS93] : premier schéma

proposé en 1993. C’est une adaptation du hachage linéaire (Linear Hashing) [L80] aux environnements distribués. C’est la plus connue et qui inspira plusieurs travaux dont le nôtre.

LH*LH [KLR96] : est une variante de LH*. Ce schéma utilise un premier

niveau d’index correspondant à LH*, permettant aux clients d’accéder aux serveurs. Le deuxième niveau d’index correspond à l’organisation interne des cases de données suivant l’algorithme LH.

DDH (Distributed Dynamic Hashing) [D93] : c’est une version distribuée du

hachage dynamique.DDH permet plus d’autonomie d’éclatement, par l’éclatement immédiat des cases en débordement donc nous n’avons pas besoin de site coordinateur, ce qui peut être un avantage. Le coordinateur est un serveur particulier chargé de gérer les éclatements et de garder une trace des paramètres réel du fichier SDDS. La DDH a introduit la notion populaire de table de hachage dynamique dite en anglais Distributed Hash Table (DHT).

EH* (Distributed Extensible hashing) [HBC97] : c’est une version scalable et

distribuée du hachage extensible. EH* permet une bonne utilisation de l’espace de stockage et offre un mécanisme de traitement de requêtes très efficace.

IH* (DistributedInterpolation-based hashing) [BZ02] : Elle constitue, à la

fois, une adaptation du hachage par interpolation proposé par W. Burkhard dans [B83] aux environnements distribués et une introduction de la notion d’ordre et de l’aspect multidimensionnel à la SDDS LH*.

D’autres variantes de LH* ont été proposées pour assurer la haute disponibilité. Celle-ci assure à une SDDS la continuité de fonctionnement de manière transparente, quand un ou plusieurs de ses sites serveurs tombent en panne.

Ces SDDS font généralement appel à certains principes de redondance et de récupération de données. Il s’agit de : Miroring pour LH*M [LN96], la fragmentation (Anglais : Striping)

LH*S [LN96] et le groupement d’enregistrements (Anglais : Grouping) LH*G [L97]

[LMR98], la k-disponibilité tels que LH*RS utilisant Reed-Solomon Code [LS99] et LH*SA

(SA pour dire ‘Scalable Availability’) [LMR98]. RAID6 aussi utilise les mêmes principes que LH*RS. Nous nous intéresserons particulièrement à LH*RS que nous allons décrire un peu plus

dans ce qui suit.

3.5.

Adaptation des Structures de Données aux Environnements Pair à Pair

Ces dernières années, nous assistons à un retour aux origines de l’Internet car cet Internet a été originalement conçu comme un système pair à pair. Il existe plusieurs applications de partage de fichiers sur Internet tels que Gnutella et Kazaa. Le mauvais fonctionnement de ces systèmes lorsque la taille des fichiers qu’ils gèrent augmente a également montré l’utilité de la

(30)

distribution de structures de données pour construire des fichiers scalables. Nous citons à titre d’exemple Chord [SMK+01], BATON [JOV05], OHL [GLR03].

A)Chord

Ce système est une adaptation des tables de hachages dynamiques, notées DHT (Anglais : Distributed Hash Table) [D93], aux environnements pair à pair. Comme le montre la Figure 9 Chord organise chaque système pair à pair en un anneau où chaque pair gère une partie de la DHT. Chaque pair tient une table de routage dite ‘Finger Table’, voir Figure 10. La Figure 9 montre un exemple où les carrés représentent les clés, les petits disques sur l’anneau représentent les identifiants.

Chord est basé sur un espace de recherche de m bits, ce qui permet d’avoir jusqu’à 2* clés. Il assigne à chaque pair ou nœud une clé et les organise en un anneau dans l’ordre de leurs clés. Les clés et les pairs sont hachés sur le même anneau. La ‘Finger Table’ d’un nœud contient les adresses des nœuds situés à différents positions relatives dans l’anneau. Parmi ces nœuds se trouve le nœud à 180° dans l’anneau, les nœuds forment des ongles droits et ainsi de suite. Toutefois, chaque nœud connait les adresses correspondantes à toutes les clés des intervalles entre sa propre clé et la clé de son prédécesseur.

Figure 9. Architecture de Chord, [SMK+01]

La force de Chord provient de sa simplicité et de son efficacité. Ses principes fondamentaux sont :

• Adressage aléatoire : une requête de recherche est envoyée à un nœud quelconque. Le nœud ayant reçu la requête répond dans le cas où il détient la réponse, sinon il renvoie la requête à son nœud successeur et ainsi de suite.

Afin d’éviter une recherche linéaire, Chord utilise la ‘Finger Table’ de chaque nœud pour localiser le nœud dont la clé est immédiatement inférieure à celle de la clé recherchée.

(31)

• Si un nouveau nœud connait l’adresse associée à la clé recherchée, la recherche s’arrête avec succès. Dans le cas contraire, il consulte sa ‘Finger Table’ et répète le processus.

Cette organisation permet d’effectuer chaque recherche en O(log N) étapes, N étant le nombre de nœuds de l’anneau.

Afin de garantir l’efficacité de la recherche de clés dans le réseau, Chord contrôle l’adjonction et le départ de nœuds. En particulier il veille à ce que les tables de routages soient mises à jours périodiquement

1. Lors de l’adjonction d’un nœud n dans l’anneau Chord :

Le nouveau nœud n se voit affecter comme successeur s l’ancien successeur de son prédécesseur p dans l’ordre numérique de l’anneau.

Ce prédécesseur à pour nouveau successeur le nouveau nœud n.

• Toutes les clés dans l’intervalle + , $+ qui étaient jusqu’alors gérées par s se voient

affectées au nouveau nœud n.

Figure 10. Tables de routages dans Chord, [SMK+01]

2. Lors du départ d’un nœud n de l’anneau Chord :

Toutes les clés du nœud n qui quitte le réseau sont déplacées sur le successeur de n.

Le pointeur du prédécesseur de n est mis à jour au successeur de n. 3. Lors d’une panne d’un nœud n :

Tous les nœuds de l’anneau ayant n dans leurs tables de routage ‘Finger table’ doivent retrouver le successeur de n car le prédécesseur de n n’a plus de successeur valide (n en panne). Pour pallier ce problème une liste des r successeurs

(successor-list) les plus proches est maintenue sur chaque nœud. Cette liste active est toujours

maintenue à jour grâce à des mises à jour d’un nœud périodiques effectuées lors du départ volontaire.

(32)

La liste des r successeurs permet de trouver la clé et l’adresse du successeur de nœud n défaillant.

Si le nombre de successeurs de chaque nœud est O(log N) et la probabilité de panne d’un nœud est 1/2 , les auteurs de Chord ont montré qu’il y avait une forte probabilité que la recherche d’un nouveau successeur pour un nœud n après une panne renvoie le plus proche successeur disponible de n. De plus, l’exécution de cette recherche est d’ordre de O(log N)

Il faut noter que pour maintenir à jour les tables de routages, Chord nécessite O(log2N)

messages, ce qui est plutôt couteux. Observons aussi que Chord ne préserve pas les données en cas de panne permanente ou de départ inopiné d’un nœud ; toutes les clés associées au nœud disparu sont perdues.

La question de la recherche à clé de données et du renvoi de messages en cas d’erreur constituent un domaine de recherche en base de données et systèmes répartis. Liskov et al du MIT ont présenté une nouvelle méthode d’organisation de l’anneau Chord pour garantir un seul renvoi en cas d’erreur d’adressage [GLR03].

B)Recherche en Un Saut ‘One Hop Lookups’

La recherche en un saut (OHL) [GLR03] est basée sur le système de référence Chord. Il s’agit d’une nouvelle organisation du l’anneau Chord maintient la ‘Finger Table’ de Chord complète et à jour. Pour atteindre le but d’un seul renvoi en cas d’erreur d’adressage, OHL envoie à chaque nœud un nouveau message lors de chaque adjonction ou départ de nœud et garantit que ce message arrivera là tous les nœuds de l’anneau dans un délai raisonnable sans nécessiter une bande passante excessive (sans inonder le réseau).

Les principes généraux de la solution de OHL sont les suivants:

• L’anneau est réorganisé en une arborescence, ce qui permettra une recherche en un seul renvoi.

• Tous les nœuds de l’anneau ont des clés de 128 bits.

• Comme le montre la Figure 11, l’espace des 128 bits des identifiants de l’anneau est devisé en k intervalles réguliers et contigus appelés Tranches (Anglais : Slices).

La ième Tranche contient tous les nœuds dont l’identifiant est dans l’intervalle :

[- ∗ ./0

1 , &- + 1' ∗

./0

1 ], [GLR03]

Chaque Tranche a le même nombre de nœuds à tout moment, pour autant que la distribution des identifiants soit uniforme et aléatoire.

Chaque Tranche a un leader qui est le successeur du nœud médian des identifiants de la Tranche. Tout Changement dans la composition de ces identifiants est susceptible de changer ce leader.

Chaque Tranche est divisée à son tour en parties contiguës appelées Units, voir la Figure 12. Chacun de ces Units a également un leader choisi dynamiquement de la même manière que les leaders des Tranches.

(33)

Figure 11. Découpage statique de l’anneau en Tranches, [GLR03]

Figure 12. Découpage d’un Tranche en Units

1. Départ et Adjonction de Nœud

Avec cette nouvelle hiérarchisation de l’anneau Chord, chaque départ et adjonction de nœud est notifié par l’envoi d’un événement. Comme le montre la Figure 13, chaque nœud n ayant détecté un changement de son successeur (départ, panne ou arrivée d’un nouveau successeur), envoie un événement leader de sa tranche. Ce dernier collecte tous les événements de notifications d’adjonctions ou de départs de nœuds. Il prépare aussi un message de notification et l’envoie à tous les leaders des tranches de l’anneau. Chaque leader

de tranche diffuse le message à ses Units Leaders et celui-ci le propage à son tour à ses

nœuds prédécesseurs et successeurs. À la fin, tous les nœuds de l’anneau reçoivent le message de notification et mettent à jour leur Finger Table. Quand la composition d’une tranche évolue, il se peut que certains messages soient en doubles. Pour éviter les erreurs possibles, les nœuds devront rejeter tous les messages de notifications qui ne viennent pas du nœud voisin le plus proche.

Malheureusement, ce découpage en plusieurs Tranches et Units implique un allongement du temps de diffusion des messages de notification. En contrepartie la diffusion de ces messages est asynchrone pour mieux exploiter la bande passante du réseau

. S li ce 1 Slice 4 S li ce 3 Slice 2 Nœud

(34)

Figure 13. Diffusion d’un message de notification, [GLR03]

2. Panne d’un nœud

L’échec d’une requête ne renvoie pas d’erreur. Si un nœud n1 envoie une requête de

recherche au nœud cible n2 et ce dernier ne répond pas alors le nœud n1 transmet sa requête

pour le successeur de n2.

En cas de panne d’un nœud leader son successeur deviendra le nouveau leader. Dans ce cas le nouveau leader utilise des messages de diffusion dans sa Tranche ou son Unit pour obtenir les informations dont il a besoin.

Nous observons que OHL ne peut pas faire la reconstruction de données après une panne et se limite à la reconstruction de ses Fingers Tables.

C)BATON (A Balanced Tree Overlay Networks)

BATON [JOV05] est la généralisation des arbres de recherches binaires équilibrés aux environnements pairs à pairs. Nous rappelons qu’un arbre binaire équilibré est un arbre binaire tel que les hauteurs des deux sous arbres de même niveau de tout l’arbre différent de 1 au plus, i.e. : | hauteur (arbre gauche) – hauteur (arbre droit) | ≤ 1.

Pour un tel arbre, le coût de l’opération de mise à jour lorsqu’un nœud quitte le réseau est de O(log N) messages. Le coût d’une opération d’insertion, de recherche, et de suppression d’article est de O(log N) messages dans le pire des cas.

Nœuds ordinaire Leader de tranche

Figure

Table 2. Temps de disponibilité [GSS06]
Figure 5. Architecture générale d’un système à base de SDDS
Figure 8. Classification des SDDS
Figure 14. Structure de BATON, [JOV05]
+7

Références

Documents relatifs

60 jours après la fin du traitement, 4 boucs, logés à 300 m des femelles et soumis au même traitement photopériodique, ont été introduits parmi les chèvres (J0) à raison de

Mem- oryless knowledge is based only on the current state of a process, knowledge of perfect recall can take into account the local history of a process, and causal knowledge depends

Dans cette section, nous allons présenter notre modèle (Cabani et al., 2005b) pour distribuer un système multiagent sur une architecture pair-à-pair... proposons

des recherches relevant des conventions CIFRE, qui se limitent généralement à un partenariat institutionnel, sur la base d’un intérêt mutuel.. praticiens, qu’il s’agisse

Access and use of this website and the material on it are subject to the Terms and Conditions set forth at Methods for evaluating the moisture management of wood-frame wall

Ces nouveaux dérivés chiraux calix-salen ont été complexés avec des sels de chrome et cobalt pour être testés comme catalyseurs hétérogènes dans les réactions

Dans cet article, nous présentons les intercon- nexions qui peuvent se faire entre, d’une part, la modélisation et simulation multi-agents, et le domaine des réseaux pair-à-pair

Then we present a structural translation of a TPN into a synchronized product of timed automata that preserves the seman- tics (in the sense of timed bisimilarity) of the TPN.