DCS : Distance Computation Service un outil de calcul de distances

DCS : Distance Computation Service
un outil de calcul de distances réseau nœud à nœud
- Résumé Julien Gossa, Jean-Marc Pierson, Lionel Brunie
LIRIS - INSA Lyon
Bât. Blaise Pascal 69 621 Villeurbanne, France
[email protected]
5 décembre 2005
1
Introduction
Il s’agit de mettre en place un système permettant d’évaluer les distances machine à machine
sur un réseau étendu tel qu’une grille et ce de façon flexible (i.e. : adaptée à la tâche envisagée
et au contexte d’utilisation). Nous appelons distance une valeur réelle attribuée à un couple de
ressources de calcul ou de stockage pouvant communiquer. Cette valeur représente l’efficacité de
ce couple lors d’une interaction particulière. Nous verrons dans le developpement que de telles
distances ne sont pas soumises aux propriétés classiques des distances mathématiques. Ce terme
doit donc être compris de façon intuitive.
A l’heure actuelle, les infrastructures de grilles sont en passe de devenir efficaces d’un point de
vue fonctionnel. En effet des intergiciels tel que globus[1], profitant des efforts récents de standardisations relatifs aux services web, permettent la mise ne place d’une grille comportant (plus ou moins
bien) toutes les caractéristiques requises : référencement des ressources, distribution de tâches, gestion des données disponibles et répliquées, etc... Les efforts actuels sont encore concentrés sous
le point de vue fonctionnel avec le développement des architectures et des protocoles nécessaires.
Ainsi, d’un point de vue donnée, une grille peut aujourd’hui supporter un très grand nombre de
données distribuées. Ces dernières peuvent être de tailles très variées, et souvent conséquentes, et
peuvent être répliquées à échelles très variées, et potentiellement très grandes. A ce jour, les grilles
permettent de stocker et référencer ces données et leurs copies [3], mais aucun outil ne permet
encore d’effectuer une sélection de façon uniforme, simple et flexible parmi toutes ces copies. Ce
choix est pour l’instant laissé à la discrétion de l’utilisateur qui est contraint, la plupart du temps,
à se limiter à une sélection hasardeuse ou à développer lui même un système spécifique.
Or, la réplication des données est une réponse à de nombreuses problématiques : disponibilité,
persistance, performance... Et la phase de sélection parmi plusieurs copies d’une même donnée est
une phase critique. Non seulement pour son consommateur puisqu’elle conditionne le temps de
rapatriement et le taux d’échec (copie supprimée, ressource indisponible,...). Mais aussi pour le
fonctionnement du réseau en lui-même puisqu’elle conditionne la saturation ou la non utilisation
de toutes ses ressources (de stockage et communication).
2
Court Etat de l’Art
De tels choix sont intimement liés à l’aspect monitoring, qui est actuellement en pleine exploration. En effet, de nombreux travaux sont en cours sur le sujet vaste des métriques. Cette
notion peut être assez difficile à appréhender, comme l’indique [6], mais nous pouvons la résumer
intuitivement comme “des façons d’évaluer l’état courant des différentes ressources d’un réseau”.
1
Alors que certains travaux [6][10] s’intéressent au problème plus fondamental de l’identification des
métriques appropriées à certains environnements et leur différents moyens d’observations, d’autres
[9][5] s’intéressent au problème plus architectural de la collecte des différentes observations pour
les intégrer dans des catalogues et les rendre disponibles aux applications.
Le fait est que les catalogues de grille actuels [2] intègrent assez bien les métriques relatives
aux machines, mais très mal les métriques relatives aux communications. En effet, les services
de monitoring s’intéressant aux machines et aux communications, tels que [5] et [7], sont peu ou
pas intégrés à l’intergiciel proprement dit, et restent donc au stade d’outil additionnel. Or, cette
intégration est d’une réelle importance puisqu’elle est indispensable à l’utilisation des métriques
pour optimiser le fonctionnement de la grille dans son activité quotidienne et à tous les niveaux
de son fonctionnement.
Une autre observation est que nous n’avons pu trouver qu’un seul travail [4] proposant une
méthode de combinaison de différentes métriques afin de comparer différentes ressources. Les
auteurs exposent une fonction dite de “proximité” combinant le Round Trip Time (RTT) maximum
et actuel avec le débit (throughput) maximum et actuel d’un lien pour évaluer la distance entre
deux nœuds. Nous pouvons faire trois observations :
– La mise en œuvre de cette combinaison reste à définir.
– Une méthode générique permettant de déclarer de nouvelles combinaisons est nécessaire.
– Les caractéristiques de la tâche envisagée ne sont pas pris en compte dans le calcul de cette
“proximité” : elle sera la même que l’on veuille rapatrier un fichier de 10 Go, ou bien stocker
un fichier de 1 ko ou encore soumettre une tâche.
3
Présentation résumée de notre proposition
Notre proposition concerne précisément ces trois derniers points. Nous proposons un outil
générique permettant à son utilisateur d’accéder aux observations des différentes métriques disponibles (sur les machines, mais aussi sur les liens réseaux), de définir les caractéristiques d’une
tâche et enfin de définir la fonction permettant la combinaison de toutes ces dernières informations. Cet outil permet de calculer une distance entre des ressources clientes potentielles et chacune
des ressources fournisseuses potentielles, relativement au service attendu. Plus cette distance est
faible, meilleures sont les conditions dans lesquelles la ressource fournisseuse concernée est propice
à rendre ce servir à la ressource client concernée. Cet outil a donc pour but d’aider un utilisateur dans le processus de sélection de la (ou les) meilleure(s) ressources parmi les nombreuses
possibilités qui s’offre à lui. Par exemple, il permettra de sélectionner la copie d’une donnée la
plus appropriée au rapatriement sur une certaine machine en fonction des capacités et de l’état
actuel des différentes ressources impliquées et des caractéristiques de cette donnée (sa taille, si
elle supporte l’accès par flux, etc...). Sous un point de vue logique, notre outil permet de rajouter
aux catalogues de grilles (de machines[2], de réplicas[3] ou autre...) les informations de pertinence
relatives au contexte et à la tâche envisagée.
Notre optique n’est pas de nous arrêter à la sélection d’une copie de donnée pour le rapatriement, mais de l’étendre à toutes les tâches possibles où cette notion de distance peut s’averer utile :
sélection d’un lieu de stockage, soumission de tâche, ordonnancement... notre but final étant de
mettre en place un service de “cartographie” des ressources d’un système distribué grande échelle
flexible, c.a.d. adaptable aux intentions de son utilisateurs.
Dans la version étendue de notre article, nous abordons les points suivants. Nous présentons
une formalisation de notre concept de distance et des concepts connexes. Nous présentons les
interfaces de cet outil qui, conformément au standard actuel, est implémenté sous forme de web
service fortement corrélé à [2],[3] et [7]. Son évaluation sera faite dans le cadre de la sélection
des copies de données avec des caractéristiques différentes dans le but de les rapatrier et de les
stocker. Un tel outil peut entrer en conflit avec le concept fondamental de “transparence” cher
aux grilles, nous discutons cet aspect ainsi que le cadre applicatif dans lequel son utilisation est
2
préconisée. Nous présentons également un cadre réel d’application d’extraction de connaissances
[8] dans lequel il intervient à plusieurs niveaux.
Références
[1] Globus Alliance. Globus. http ://www.globus.org/.
[2] Globus Alliance. Monitoring and discovery service. http ://www.globus.org/mds/.
[3] Globus Alliance. Replica location service. http ://www.globus.org/rls/.
[4] Tiziana Ferrari and Francesco Giacomini. Network monitoring for grid performance optimization. Computer Communications, 27(14) :1357–1363, 2004.
[5] Mark Leese, Rik Tyer, and Robin Tasker. Network performance monitoring for the grid. UK
e-Science, 2005.
[6] Bruce Lowekamp, Brian Tierney, Les Cottrell, Richard Hughes-Jones, Thilo Kielmann, and
Martin Swany. A hierarchy of network performance characteristics for grid applications and
services. Global grid Forum, june 2004.
[7] Graziano Obertelli and Rich Wolski. Network weather service. http ://nws.cs.ucsb.edu/.
[8] Jean-Marc Pierson, Lionel Brunie, Maryvonne Miquel, Anne Tchounikine, Clarisse Dhaenens,
Nouredine Melab, Talbi El ghazali, Abdelkader Hameurlain, and Franck Morvan. Grid for
geno-medicine : A glimpse on the project. BioGrid’05.
[9] Junfeng Wang and Mingtian Zhou. Provinding network monitoring service for grid computing.
FTDCS’04.
[10] Artur Ziviani and Bruno Schulze. Combining grid computing and internet measurements.
WCGA’05.
3