1 Introduction

Revue d'article:
A NETWORK-AWARE DISTRIBUTED STORAGE CACHE FOR DATA
INTENSIVE ENVIRONMENTS
Auteurs: Brian L. TIERNEY, Jason LEE, Brian CROWLEY, Mason HOLDING
Computing Sciences Directorate – Lawrence Berkley National Laboratory
University of California, Berkley, CA, 94720
Tahiry RAZAFINDRALAMBO – DEA DISIC – 2003/2004
1 Introduction
Cet article [1] présente une architecture de stockage basée sur des caches distribués à
travers un réseau haut débit. Il décrit une implémentation d'un cache réseau et comment cette
implémentation a été adaptée pour être "network-aware", c'est à dire comment les opérations
de cette implémentation s'adaptent aux conditions du réseau. Cette implémentation à été mise
en place pour les data intensive grid (grille de données intensives)
2 Résume de l'article
2.1 Problématique
Les flux de données à grande vitesse résultant des opérations d'instruments tels que les
systèmes d'imagerie médicale, les capteurs de d'expérience en physique sont le quotidien des
scientifiques. L'avancé des réseaux à grande vitesse fournit de nouvelles approches pour la
collection, l'organisation, l'analyse, la visualisation… des données fournies par de tels
instruments. L'objectif étant de faire en sorte que les données et l'analyse soient aisément
disponibles. Cet article décrit comment les grilles de données peuvent permettre de résoudre
de tels problèmes et comment un cache réseau à grande vitesse est un composant
particulièrement important dans l'architecture des grilles de données intensives. Les auteurs
décrivent l'implémentation d'un cache réseau et comment ce cache réseau a été adapté pour
être "network-aware" c'est à dire s'adapter en fonction des conditions du réseau.
2.2 Description de l'approche
Du point de vue de l'application une grille est une collection de services middleware qui
fournissent aux applications une vue uniforme des composants, des ressources distribuées, et
des mécanismes pour les assembler en système. Du point de vue du système middleware, la
grille est un ensemble standardisé de services basic fournissant ordonnancement, découverte
de ressources, services de communications… Cependant du point de vue du concepteur de la
grille, ces services résultent et doivent interagir avec un ensemble hétérogène de possibilités,
et souvent impliquent de regarder dans les couches inférieures de calcul ou d'infrastructures
de communications. ( utilisation des grilles pour résoudre ces problèmes)

Notre modèle doit employer un cache de stockage de données distribué comme élément
commun pour toutes les sources de données impliquées. Un cache signifie que le stockage est
plus rapide que sur un disque local typique et qu’il est temporaire par nature. Dans les
environnements de données intensives, un cache haut débit permet de fournir une interface
standard de débit élevé pour les accès venant des sources de données, pour les accès dûs au
traitement des données, pour le système de stockage de masse, et pour l’interface utilisateur.
(architecture pour les données intensives).
Pour utiliser efficacement les réseaux étendus haut débit, les applications doivent être
« network-aware » c’est à dire que l’application essaie d’ajuster sa demande en fonction des
changements de disponibilité des ressources réseaux. Les applications network-aware vont
exiger un service qui fournit des informations sur le passé, le présent et le future état des liens
du réseaux qu’elles voudraient utiliser. Un système de surveillance est la première étape pour
fournir un tel service.(network aware application)
2.3 Implémentation
2.3.1 Le cache haut débit distribué
L’implémentation du cache haut débit distribué mis en place par les auteurs est DPSS
[2] Distributed-Parallel Storage System. Cette technologie a été testée ( projet DARPA
MAGIC )avec succès pour fournir une architecture de cache, fortement scalable, distribuée,
économique et de haute performance. L’implémentation typique d’un DPSS consiste en un
grand nombre de station à bas prix comme serveur de block DPSS, chacun avec plusieurs
contrôleurs de disque, et plusieurs disques sur chaque contrôleur.
L’architecture interne d’un DPSS est la suivante : La requête d’un bloc de données est
envoyée depuis une application client à un maître DPSS, qui trouve sur quels serveurs de
blocs DPSS sont situés les blocs, puis le maître transmet les requêtes directement vers le
client. Les serveurs peuvent être n’importe où sur le réseau.
La performance d’un DPSS, mesurée par le débit, est optimisée pour un nombre
relativement petit (quelques milliers) de fichier relativement grand (plus de 50MB). Les
performances sont les même pour des fichiers de plus de 50 MB.
Le DPSS est dynamiquement configurable, autorisant l’ajout ou le retrait de serveurs ou
de disque à la volé. Ceci est fait en conservant les informations concernant les ressources
hardware du DPSS dans une base de donnée formaté LDAP, qui peut être mise à jour
dynamiquement. Des systèmes agents sont utilisés pour surveiller le réseau, les hôtes, et la
disponibilité des disques, et stockent ces informations dans une base LDAP. Ces informations
peuvent être utilisées pour la tolérance aux fautes, et l’équilibrage de charge.
2.3.2 L’équilibrage de charge
Pour que le cache DPSS soit efficace dans un environnement de réseau étendu, il doit
avoir une connaissance suffisante du réseau pour s’ajuster à un grand nombre de condition de
performance du réseau, et qu’il soit capable de se reconfigurer automatiquement en face d’une
congestion ou d’une défaillance matériel.
La première étape pour l’équilibrage de charge est le monitoring du réseau. Les auteurs
ont implémenté un système nommé Java Agent for Monitoring Managment (JAMM). Ces

agents basés sur Java et RMI peuvent lancer une grande variété d’outils et de système de
monitoring de réseau, en extraire les résultats, et les publier dans une base LDAP. Ces agents
peuvent de manière sécurisée démarrer n’importe quel programme. Les agents exécutent par
exemple netperf [3] ou ping pour le monitoring du réseau…, les résultats sont alors publiés
dans une base LDAP à des intervalles réguliers (quelques minutes). Ces agents sont exécutés
sur tous les hôtes du système distribué, incluant les clients et tous les serveurs.
Le DPSS utilise TCP pour le transfert de données. Pour que TCP fonctionne bien sur
des réseaux haut débit, il est important qu’il y ait un buffer assez grand pour que le contrôle
de congestion fonctionne correctement. La taille du buffer dépend du produit délai-bande
passante du réseau, mais le produit délai-bande passante peut avoir un ordre de grandeur de 4
ou 5 sur internet. Il est donc pratiquement impossible de configurer pour un hôte un
paramètre de TCP qui soit optimal pour chaque connexion. Pour résoudre ce problème la
librairie cliente DPSS détermine automatiquement le produit délai-bande passante pour
chaque connexion à un serveur DPSS et met le buffer TCP à la taille optimal. La bande
passante et le délai sont obtenus dans la base LDAP.
Le DPSS peut exécuter un équilibrage de charge si des blocs de données sont répliqués
sur plusieurs serveurs. Le DPSS master utilise les informations d’état dans la base LDAP pour
déterminer comment expédier un requête cliente de bloc vers un serveur qui peut donner la
réponse la plus rapide. Les auteurs abordent le problème du Load balancing comme un
problème combinatoire, il y a un certain nombre de client et un certain nombre de serveur;
chaque client doit être assigné à un ou plusieurs serveurs sans qu'aucun serveur ne soit
surchargé. L'approche le l'algorithme à coût minimum de flots est une bonne méthode pour
résoudre ce problème de type combinatoire. Le problème est que cet algorithme est off-line
donc implique un prédictibilité au niveau de la demande de blocs par les clients, alors que les
départs et les arrivées de clients sont aléatoires, les quantités de données demandées aussi…
La solution proposée par les auteurs est d'exécuter l'algorithme chaque fois qu'une requête
client arrive, l'algorithme lui même est assez rapide (1ms pour un modèle de graphe typique).
Les auteurs ont modélisé l'équilibrage de charge de DPSS comme un problème de transport,
le réseau est présenté comme un graphe bipartite avec des nœuds et chaque nœud est un client
ou un serveur, et chaque arête est un chemin réseau du serveur vers le client. Chaque arête a
un coût par blocs et une capacité maximum. L'algorithme trouve le flots de blocs du serveur
vers le client qui minimise le coût total. Les coûts et les capacités sont assignés par rapport à
la latence réseau qui est selon les auteurs le facteur dominant affectant les performances. Cette
latence est divisée en trois latence, le délai du lien entre le client et le master, délai
d'exécution du serveur et du master DPSS, et délai de transmission entre le serveur et le client.
Ces délais sont obtenus dans la base LDAP. Le problème de cette approche est que les
chiffres obtenus ne sont pas forcément à jour et que plusieurs arêtes peuvent partager le même
lien, ce qui n'apparaît pas dans le graphe.
La capacité des arêtes est la bande passante obtenu de la base LDAP. Cette capacité peut
être réduite en fonction du degré des réplication des données. Quand des données sont
chargées dans le DPSS, les blocs sont distribués à travers n serveurs, et chaque blocs est
répliqué m fois (m<=n). Si nous supposons que les blocs sont uniformément distribués, il est
peu probable qu'un serveur stocke plus de m/n pourcent des blocs demandés. La capacité
assignée de l'arête est le minimum, soit de la bande passante soit de m/n pourcent des données
demandées par le client.
L'implémentaion du load balancing, maintient une structure de graphe de données qui
est modifiée chaque fois qu'un client part ou arrive. Le coût des arêtes est recalculé toutes les
3 minutes d'après les données de la base LDAP.

2.4 Résultats
Les expérimentations réalisées par les auteurs ont montrées que la réplication de
données et le load balancing augmentent le débit en sortie du DPSS par un facteur de 2.17
comparé a l'utilisation sans réplication. En utilisant la réplication de données, le load
balancing augmente de 33% le débit de sortie total par rapport à la "greedy strategy" employé
jusqu'ici dans les systèmes DPSS.
Les expériences ont été faites avec load balancing et réplication de données sur 4
configurations différentes, avec un réseau comme présenté dans le schéma suivant.
Globalement, l'équilibrage de charge et la réplication de données, augmentent la bande
passante délivrée aux applications. La réplication autorise l'utilisation de plusieurs serveurs
par un clients, mais sans l'équilibrage de charge, les clients restent limités par la vitesse du
serveur le plus lent. L'approche du flot à coût minimum pour l'équilibrage de charge augmente
le débit total du système et s'adaptant à la demande client.
2.5 Future works
Les travaux sur le DPSS sont encore nombreux et dans de nombreux domaines. Les
auteurs prévoient de tester le DPSS dans une banc d'essai plus large, avec plus de clients. Ceci
permettra de mieux évaluer l'approche du flot à coût minimum, et de mieux monter les
impacts de l'équilibrage de charge.
2.6 Conclusions
Les auteurs ont décrit une architecture de données pour les applications générant des
flux intensifs de données, centrée sur l'utilisation d'un cache haut débit et network-aware. Les
auteurs pensent que ce type de cache deviendra un composant essentiel pour les architectures
de grilles de données.
Les auteurs ont aussi montré que l'ajout d'un système prenant en compte l'état du réseau
sur un système distribué peu largement augmenté les performances. Cependant plus de tests

doivent être réalisés pour valider l'utilité de l'algorithme d'équilibrage de charge sur des
environnements réseaux plus généraux.
La réplication de données est aussi l'un des facteurs d'augmentation de performance sur
un système DPSS. Malgré le fait que la réplication à un coût, elle permet aussi une meilleure
tolérance aux fautes.
3 Evaluation
Les résultats présentés dans cet article montre une architecture pour les applications de
données intensives qui est centrée sur un cache haut débit et qui peut s'adapter aux conditions
du réseau. Les auteurs pensent que ce type de cache sera un composant très important pour
construire des grille de données intensives.
Les résultats décrits après l'expérimentation montrent aussi que l'ajout de la composante
permettant d'adapter les requêtes de la grilles aux conditions réseaux augmente
considérablement les performances de l'architecture, de plus le load balancing effectué grâce a
une réplication des données permet d'utiliser la grille et les serveurs de données de manière
relativement optimal malgré le fait que la réplication ait un coût.
Cet article est assez difficile à lire, le plan n'est pas très clair, les auteurs dans
l'introduction propose de présenter un système de cache distribué qui soit network aware, et
pourtant le gros de l'article se base sur l'optimisation de ce cache qu'il suppose comme acquis,
toutes les expérimentations se basent sur l'optimisation de ce cache, les auteurs comparent les
performances du cache avant et après optimisations. Il y a très peu de descriptions du système
lui même, les auteurs en font seulement une description sommaire et renvoient pour plus de
détails vers des références bibliographiques pour une description complète du système. Ceci
est peut être dû à la longueur de l'article qui doit être restreinte. Les auteurs ne parlent pas non
plus ou très peu pour ne pas dire pas du tout des systèmes concurrents aux leurs, et ne font
aucune comparaison entre leur architecture et les architectures concurrentes. D'autres articles
des mêmes auteurs concernant une implémentation du DPSS pour des applications telles que
High Energy Physics (HEP) ont été publiées et ont permis aussi de voir d'autres résultats de
test concernant le DPSS.
Les derniers travaux des auteurs concernant le sujet se sont basés surtout sur les
améliorations des performances de ce cache que ce soit au niveau de l'algorithme de load
balancing, au niveau du monitoring du réseau lui même pour voir une vue assez proche de la
réalité du réseau…
BIBLIOGRAPHIE
[1] B. Tierney, J. Lee, B. Crowley, M. Holding, J. Hylton, F. Drake, "A Network-Aware
Distributed Storage Cache for Data Intensive Environments", Proc. of IEEE High
Performance Distributed Computing Conference (HPDC-8), August 1999.
[2] DPSS: http://www-didc.lbl.gov/DPSS
[3] Netperf: http://www.netperf.org/