Distribution de données selon la méthode PBST

Distribution de données selon la méthode PBST* sur une grille
informatique
Amina Chikhaoui
Distribution de données selon la méthode PBST* sur
une grille informatique
Amina Chikhaoui, Djamel-Eddine Zegour, Walid-Khaled Hidouci
École nationale Supérieure d’Informatique, ESI
Alger, Algérie
{a_chikhaoui, d_zegour, w_hidouci}@esi.dz
Résumé— Les grilles informatiques impliquent le partage des
ressources hétérogènes de calcul et de stockage à l’échelle
planétaire. Récemment, l’utilisation des infrastructures de
grilles a été centrée sur les applications de distribution des
grands volumes de données. Les méthodes de gestion des
données modernes ne reposent plus sur des systèmes
centralisés. Pour offrir de meilleurs temps, il faut appliquer
des structures dédiées aux environnements distribués. PBST*
(Distributed Partitioned Binary Search Tree) est une structure
de données arborescente dédiée aux environnements
distribués. Cette méthode se caractérise particulièrement par
le partitionnement dynamique de données en vue de les
distribuer sur plusieurs ressources informatiques et de les
traiter en parallèle. Dans cet article, nous proposons un
protocole de distribution de données selon PBST* pour le
placement de données sur les grilles.
Mot_clés : Grille informatique ; SDDS.
I.
INTRODUCTION
La technologie dite "grille informatique" est une
architecture en plein expansion. La première apparition
du terme "grille" date de l'article de Ian Foster [1]. Il est né
par analogie avec la "grille de distribution de la puissance
électrique" qui permet d’obtenir une puissance électrique
sans se soucier de la provenance et la manière de
fabrication de cette énergie [2]. La grille reprend ce
principe. En effet plusieurs ressources alimentent un
réseau afin de fournir une puissance globale.
On définit une grille comme étant une infrastructure
virtuelle constituée d'un ensemble de ressources
informatiques potentiellement partagées, distribuées,
hétérogènes et sans administration centralisée. Les grilles
permettent de répondre aux besoins des applications
scientifiques caractérisées par un calcul intensif et des
volumes de données de l’ordre du Pétaoctet.
Les méthodes de gestion des données modernes ne
reposent plus sur des systèmes centralisés [3]. L’accès à
l’information devient alors un véritable problème du fait :
 de la répartition de grandes quantités de données
sur différents réseaux.
 de l’absence d’un index centralisé.
Pour résoudre ce problème, on a recours à d’autres
modèles de distribution de données.
Les Structures de Données Distribuées et Scalables
(SDDS) sont une nouvelle classe de structures de données
introduites vers 1993 par le Litwin au CERIA (Centre de
Recherche en Informatique Appliquée) [4] spécifiquement
conçues pour la gestion de fichiers en mémoire centrale
distribuée d’un multiordinateur (un réseau de PCs ou
stations de travail interconnectés par un réseau informatique
(LAN, WAN, etc.) où chaque station a sa propre mémoire
locale.). Elles fournissent un mécanisme général d’accès à
des données réparties dynamiquement. Les SDDS sont
caractérisées par la scalabilité, la distribution et la
disponibilité.
Le fichier SDDS grandit de manière dynamique par
l’éclatement des serveurs suite à la surcharge de ces
derniers et se rétrécit par fusion de serveurs suite aux
suppressions d’articles. Son évolution est transparente pour
les applications. Celles-ci appellent les clients SDDS qui
gèrent l’accès aux serveurs comme s’il s’agissait de
structure de données classiques.
Les SDDS sont caractérisées aussi par l’absence d’un
index central.
Selon la stratégie de répartition des données on peut
distinguer deux grandes familles de SDDS. Les SDDS
basées sur la distribution par les arbres (RP* [9],
DRT*[10], etc) et les SDDS basées sur la distribution par
hachage (DDH [5], EH*[6], IH*[7], etc ).
PBST* (Distributed Partitioned Binary Search Tree)
proposé par Zegour est une structure de données
arborescente. Elle se caractérise particulièrement par le
partitionnement de données en vue de les distribuer sur
plusieurs ressources informatiques et de les traiter en
parallèle.
Dans
cet article, nous proposons un protocole
implémentant la distribution des données selon PBST* sur
une grille informatique.
La suite de l’article est organisée comme suit : dans la
deuxième section nous allons décrire la méthode PBST*.
Dans la troisième section, nous présenterons notre
protocole. Les tests seront présentés dans la quatrième
section. Enfin, la cinquième section conclut l’article.
Distribution de données selon la méthode PBST* sur une grille
informatique
II.
PBST*
A. Discription de PBST*
PBST* est une structure de données dédiée aux
environnements distribués. Elle consiste à distribuer un
grand fichier de données conformément au principe des
SDDS. Elle se base sur le modèle client/serveur.
Comme toutes les SDDS, PBST* est distribué sur
plusieurs serveurs. Chaque serveur S contient un ensemble
d’enregistrements "case" organisés sous forme d’un arbre
de recherche binaire équilibré et un intervalle [a, b].
Initialement le système contient un seul serveur
"serveur1" vide avec l’intervalle]-, + [, qui représente le
serveur racine du fichier.
Dans PBST* il existe deux types de serveur
 Serveur de données : il contient un arbre de
données et l’adresse de son serveur père.
 Serveur de données index : il contient un arbre de
données et l’adresse vers son serveur père ainsi que
toutes les adresses de ses serveurs fils.
Le client PBST* a une image partielle ou complète.
Cette image est un arbre de recherche binaire où chaque
nœud contient l’adresse et l’intervalle de clés des serveurs
qui sont déjà visités par ce client. Au départ cette image
contient un seul nœud qui représente le serveur racine avec
sa plage de clés ]-, +[. De nouveaux serveurs sont
rajoutés à cette image par le biais des messages correctifs
envoyés par les serveurs. Grace à cette image, le client peut
accéder directement à la partition sur laquelle il désire
réaliser des opérations sans passer par le serveur racine.
Amina Chikhaoui
inférieur à sint. Ceci implique que les deux cases peuvent
être incluses dans un seul serveur.
Une fusion entre trois serveurs est possible lorsque le
fichier est réparti uniquement sur trois serveurs qui sont le
serveur racine et ses deux fils.
3) Co-balancement
Lorsque la taille d’un serveur est inférieur à smin et la taille
de son frère est supérieure à sint. Le co-balancement vise à
équilibrer le chargement des deux serveurs frères en
déplaçant un nombre de nœuds de l’arbre du serveur dont le
taux de chargement est supérieur à sint vers celle de son
frère.
III.
PROTOCOLE PROPOSE
A. Architecture générale
Notre solution se base sur une architecture particulière
de grille à savoir la fédération de clusters [8, 11]. La figure
5 montre une telle architecture. Donc, selon cette
architecture une grille est composée d’un ensemble de
clusters connectés à travers un réseau global WAN. Chaque
cluster est composé d’un ensemble de nœuds qui se
communiquent à travers un réseau local LAN.
Nous pouvons représenter cette topologie par un modèle
arborescent à deux niveaux. Le niveau1 représente les
gestionnaires de clusters (coordinateurs) et le niveau2
représente les nœuds de calcul et de stockage (NCS).
Le modèle PBST* est défini par trois paramètres qui
sont :
 Le paramètre de partitionnement (n): un serveur
PBST* contient au maximum (n-1) enregistrements.
 Le seuil minimal (smin) : un serveur contient au
minimum smin enregistrements.
 Le seuil intermidiaire (sint) :sint=n-smin.
Figure 1. Un cas particulier de grille: les fédérations de clusters.
Donc, un fichier PBST* est distribué sur un ensemble
des NCS de la grille (Figure 2). Chaque NCS contient une
case de ce fichier.
Ces paramètres agissent sur le taux de chargement des
serveurs et permettent la réorganisation du fichier. Suite
aux opérations d’insertions et de suppressions sur le fichier,
des éclatements, des fusions et des co-balancements des
serveurs peuvent avoir lieu.
1) Eclatement
Lorsque le taux de chargement d’une case atteint n (le
paramètre de partitionnement). On dit que le serveur est
saturé.
Si c’est le serveur racine est saturé, deux nouveaux
serveurs seront créés pour recevoir le sous arbre gauche et
le sous arbre droit. Le serveur racine ne garde que le nœud
racine. Sinon un seul serveur est alloué. Ce nouveau serveur
reçoit le sous arbre gauche ou droit selon le cas.
2) Fusion
Lorsque le taux de chargement d’un serveur diminue au
dessous de smin et la taille de la case de son frère est
Case de fichier1.
Case de fichier2.
Case de fichier3.
Figure 2. Architecture globale de la plate forme.
Distribution de données selon la méthode PBST* sur une grille
informatique
B. Description de l’architecture des composants de notre
système
Nous décrivons ci-après les différents composants de notre
système.
1) NCS :
Chaque NCS peut être un serveur ou un client PBST*.
Décrivons ci-après ces deux composants :
 Serveur :
C’est l’entité responsable de la gestion des données et
d’exécution des requêtes du client. Il se charge de
sauvegarder un fragment (case) du fichier pour pouvoir
exécuter les requêtes émises par les clients. Ces fragments
sont sous forme d’arbres de recherche binaire équilibrés.
Un serveur peut sauvegarder plusieurs cases de plusieurs
fichiers.

Client :
C’est l’interface entre l’application de l’utilisateur et les
serveurs. La localisation des serveurs reste invisible aux
applications. En effet, celles-ci ignorent totalement la
structure de la répartition du fichier. Le client peut
supporter plusieurs images pour pouvoir accéder à plusieurs
fichiers SDDS. Ces images sont sous forme d’arbres
binaires, dont chaque nœud contient des informations sur
un serveur déjà référencé (son adresse et son intervalle).
Le client achemine les requêtes de l’application vers les
serveurs puis il se bloque en attente d’une réponse ou des
messages correctifs (IAMs : Image Ajustement Message)
en provenance de ces derniers. Ces IAMs serviront pour
l’amélioration de l’image du client.
2) Coordinateur
Les coordinateurs se chargent de gérer toutes les
demandes envoyées par les clients et les serveurs. Pour
cela, il dispose de deux tables FAT et PAT.


FAT (File Allocation Table) : cette table permet
de gérer l’attribution des noms des fichiers et
d’assurer leurs unicités. Chaque case de cette table
contient toutes les informations nécessaires au
déroulement des différentes opérations relatives à
un fichier (création, ouverture, fermeture et
suppression).
PAT (Physical Allocation Table): Cette table
contient des informations relatives au déroulement
des opérations d’allocations et de libérations des
serveurs.
C. Opérations sur les fichiers
Les opérations sur les fichiers sont la création d’un
fichier, l’ouverture d’un fichier, la fermeture d’un fichier et
la suppression d’un fichier. Dans ce qui suit, nous allons
illustrer les protocoles correspondants à la création et la
suppression d’un fichier.
1) Création d’un fichier
Lors de la création d’un nouveau fichier, le client
envoie une requête à son chef de cluster. Celui-ci vérifie
qu’aucun fichier avec le même nom n’existe dans sa table
Amina Chikhaoui
FAT. Si c’est le cas, il alloue un serveur racine pour ce
fichier s’il y a un nœud qui contient au moins une case libre
dans son cluster sinon il envoie une requête en multicast
pour allouer un descripteur pour ce fichier. A la fin de cette
opération il duplique le nom, numéro et le descripteur de ce
fichier dans toutes les FATs des autres coordinateurs afin
d’assurer l’unicité des noms de fichiers. La figure 7 illustre
cette opération.
2) Suppression d’un fichier
Lorsqu’un coordinateur reçoit une requête de
suppression d’un fichier, il vérifier d’abord l’existence de
ce fichier dans sa table FAT. Si le fichier n’existe pas, il
répond au client qui a demandé la suppression de ce fichier
en envoyant un message d’erreur. Si le fichier existe et il
est en cour d’utilisation, le coordinateur envoie au client un
message lui indiquant que le fichier est ouvert par d’autres
utilisateurs. Dans l’autre cas, le coordinateur envoie un
message de suppression de ce fichier en multicast à tous les
autres coordinateurs. Ensuite, chaque coordinateur envoie
un message à tous les serveurs contenant les fragments de
ce fichier afin de supprimer ces classes de données et à la
fin les coordinateurs libèrent tous les serveurs concernés
par ce fichier.
D. Opérations sur les enregistrements
1) La recherche
Conformément à la spécification de PBST, l’opération
de recherche d’un enregistrement se déroule selon le
scénario suivant :
Soit Cl le client qui veut chercher un enregistrement de
clé donnée. Tout d’abord, ce client fait une recherche dans
son image. Soit Sk le serveur qui est susceptible d’inclure
l’enregistrement.
A la réception de la requête, Sk vérifie si la clé est dans
son intervalle de données. Si c’est le cas, il cherche cette clé
dans sa case. Si la clé existe il envoie une réponse au Cl
sinon il redirige cette requête vers un autre serveur et
parallèlement il envoie un IAM à Cl pour que ce dernier
corriger son image.
A la fin le client Cl est acquitté par le serveur Sj qui
contient cette clé, si cette clé existe. Sinon, Cl est acquitté
par un serveur de données.
2) L’insertion
L’opération d’insertion d’un nouvel enregistrement
commence par la recherche du serveur où la clé de cet
enregistrement appartient à son intervalle. Pour cela, le
client Cl qui veut insérer un nouvel enregistrement envoie
la requête d’insertion vers le serveur Sk retourné par son
image. Cette requête contient le nom du fichier dans lequel
l’enregistrement doit être inséré ainsi que l’enregistrement
qu’on veut insérer avec sa clé primaire. A la réception de
cette requête, Sk peut rediriger cette dernière vers d’autres
serveurs. A la fin de cette opération, Cl est acquitté soit par
le serveur qui contient cette clé (si la clé existe déjà) soit
par le serveur où on a inséré la clé.
Distribution de données selon la méthode PBST* sur une grille
informatique
Amina Chikhaoui
L’insertion peut invoquer des traitements sur les
serveurs données-index en cas d’éclatement du serveur de
données qui a exécuté la requête. Dans ce cas, le
coordinateur local sera sollicité pour l’allocation d’un
nouveau serveur.
L’allocation d’un nouveau serveur se fait comme suit :
Si le cluster local possède un serveur Sh qui a une case
libre, il donne l’adresse de Sh au Sc. Après, on équilibre la
charge entre ces deux serveurs en envoyant un sous arbre
de Sc vers Sh. Dans l’autre cas, le coordinateur envoie une
requête en multicast vers tous les autres chefs de clusters
afin d’allouer un serveur qui contient une case vide.
IV.
LES TESTS
Nous présentons dans cette section les tests de
simulation qu’on a effectués sur notre prototype afin de
tester sa validité, d’évaluer ces performances et d’étudier sa
scalabilité.
Notre grille est composée de 5 clusters. Chaque cluster
contient 10 nœuds de calcul et stockage.
Noter qu’on dans nos tests, on s’intéresse au nombre
d’éclatements des serveurs. Noter aussi que les tailles des
cases qu’on va utiliser sont très inférieures de celles
utilisées dans la pratique, mais ce choix nous permet
d’avoir un grand nombre d’éclatements et d’observer ainsi
le comportement de notre prototype.
A. Taux de chargement des cases des serveurs alloués
pour un fichier
Le facteur de chargement est égal à l’espace occupé par
les enregistrements divisé par la taille des cases allouées. Il
reflète la bonne utilisation de l’espace mémoire. La figure3
montre le taux de chargement moyen des cases allouées
pour un fichier.
Figure 3.
Taux de chargement moyen des cases.
On peut remarquer que le taux de chargement est
toujours supérieur à 50% ce qui s’explique par le
fonctionnement de PBST*. En effet, lorsqu’une case d’un
serveur atteint sa capacité maximale, une nouvelle case
d’un autre serveur est allouée et la moitié de la charge lui
est transmis.
B. Disponibilité
Dans ce test, nous commençons par créer 4 fichiers
avec un paramètre de partitionnement =100. Le fichier1
(respectivement fichier2, fichier3 et fichier4) est distribué
sur 9 serveurs (respectivement 16 serveurs, 22 serveurs et
31 serveurs). Pour chaque fichier créé, on suppose qu’un
coordinateur tombe en panne. A ce moment, un client se
connecte à la grille avec une image vide et essaie d’accéder
à tous les enregistrements du fichier. Nous mesurons le taux
d’informations que ce client peut trouver. (figure4)
Figure 4. Taux d’informations trouvées et perdues en cas de panne.
On remarque que le taux d’informations perdues
diminue si le fichier est distribué sur plusieurs clusters.
Ceci est justifiable car le faite de distribuer les données sur
plusieurs clusters réduit le pourcentage des données
stockées sur le cluster qui contient le coordinateur
endommagé.
V.
CONCLUSION
Nous avons proposé dans cet article un protocole de
distribution de données sur une grille informatique basé sur
PBST*.
Les tests effectués nous ont montré que le croisement
des deux domaines SDDS et "grilles informatiques " peut
être considéré comme un axe de recherche important. Deux
résultats rendent le nouveau système attractif. D’une part, il
assure une répartition équitable des données sur l’ensemble
des serveurs alloués pour un fichier. D’autre part, il assure
la disponibilité de la plupart des données même si un
coordinateur tombe en panne, et ceci sans l’utilisation
d’aucune stratégie de disponibilité des données.
REFERENCES
I.Foster and C.Kesselman, “The Grid: Blueprint for a New
Computing Infrastructure,” Morgan-kaufmann,1999.
[2] R. Buyya and S. Venugopal, “A Gentle Introduction to Grid
Computing and Technologies”, CSI Communications, Vol.29,
Computer Society of India (CSI), Mumbai, India, pp 9-19, 2005.
[3] P. Tadepalli, “Grid-based distributed search structure”, In
Proceedings of the ACM SouthEast Conférnece, Melbourne,
Florida, pp 752-753, 2006.
[4] W. Litwin, M.A. Neimat and D. Schneider, “LH*: Linear Hashing
for Distributed Files”, ACM-SIGMOD International Conference On
management of Data, 1993.
[5] D. Devin, “Design and implementation of DDH: A distributed
dynamic hashing algorithme”, In Proceessing of the 4th Foundation
of Data Ortanization and Algorithms (FODO), 1993.
[6] V. Hilford, F.B. Bastani and B. Cukic, “EH*: Extendible Hashing
distributed”, 1997.
[7] D.E. Zegour and D. Boukhelef, “IH*: Hachage Linéaire
Multidimensionnel Distribué et Scalable”, Conférence Africaine de
Recherche en Informatique, CARI 2002, Yaoundé (Cameroun),
Octobre 2002.
[8] S. Monnet, “Gestion des données dans les grilles de calcul: support
pour la tolérance aux fautes et la cohérence des données”, These de
Doctorat, Université de Rennes1, 2006.
[9] W.Litwin, M.A. Schneider, “RP*: A family of Order-Preserved
Scalable Distributed Data Structure”, 20th International Conference,
On Very Large Data Bases (VLDB), 1994.
[10] B. Kroll and P. Widmayer, “Distributing a Search Tree Among a
Growing”, In ACM-SIGMOD International Conference On
Management of Data, pp 265-276, 1994.
[11] G. Antoniu, L. Bougé and M. Jan. JuxMem : An Adaptive
Supportive Platform for Data Sharing on the Grid, IN Scalable
Computing : Practice and Experience, pp 45-55, September 2005.
[1]