Métrologie réseau pour les grilles Projet IGTMD a
Magì Sanchón Solerb
Philippe d’Anfray
Philippe.d-Anfray@renater.fr
GIP RENATER
SIPA, Coordination grille
– version 1.0, 31 Juillet 2007.
aInteropérabilité des grilles de calcul et transferts massifs de données en vue de l’optimisation du traitement des données duLHC, Projet ANR-05-BLAN-0134-01/NT05-3 43786
bMagì Sanchón Soler a travaillé sur ce projet, auGIP RENATER, sous la direction de Bernard Tuy, en collaboration avec l’ENS Lyon et l’INRIA RESO, de Septembre 2006 à Mars 2007
Réseau National de télécommunications pour la Technologie, l’Enseignement et la Recherche
Siège : GIP RENATER c/o ENSAM 151 boulevard de l’Hôpital 75013 PARIS Tél. : 01.53.94.20.30 Fax : 01.53.94.20.31 Antenne : GIP RENATER c/o CINES 950 rue de Saint Priest 34097 Montpellier Cedex 5 Tél. : 04.67.16.38.25 Fax : 04.67.16.38.21
http ://www.renater.fr
Table des matières
1 Motivations 7
2 Les Besoins 9
2.1 Développeurs et utilisateurs . . . 9
2.2 Besoins des utilisateurs . . . 10
2.3 Besoins des développeurs . . . 11
2.4 Conséquences : que veut-on mesurer, comment ? . . . 12
2.5 Synthèse . . . 14
3 Métriques réseau adaptées aux grilles 15 3.1 Sources, terminologie . . . 15
3.2 Quelles métriques pour les applications ? . . . 16
3.3 Données environnementales . . . 18
4 Métrologie et grilles 19 4.1 Outils de surveillance pour les grilles . . . 20
4.2 Outils de surveillance du réseau (Grid5000) . . . 22
4.3 Métriques réseau versus métriques grille . . . 24
5 Approches possibles sur la plate-formeGrid5000 25 5.1 Présentation de la plate-formeGrid5000 . . . 25
5.2 Réutilisation des donnéesSNMP . . . 27
5.3 Outils de flux backbone . . . . 27
5.4 Outils de flux en périphérie . . . 28
5.5 Sondes . . . 28
5.6 Duplication de flux "mirroring" . . . 29
5.7 Adoption d’un intergiciel . . . 30
5.8 Quelques points cruciaux . . . 31
6 Expériences de trafic surGrid5000 33 6.1 Description de l’expérimentation . . . 33
6.2 Analyse des résultats . . . 36
7 Conclusions 39
Table des figures
3.1 Métriques réseau pour les grilles . . . 16
4.1 Outils de surveillance des grilles . . . 21
4.2 Outils réseau dansGrid5000 . . . 23
5.1 InterconnexionGrid5000. . . 26
6.1 Résumé des expériences . . . 34
6.2 MesuresiPerfcourbe de type A (Nancy) . . . 35
6.3 MesuresiPerfcourbe de type B (Sophia) . . . 36
6.4 MesuresiPerfcourbe de type C (Toulouse) . . . 36
6.5 Interface vers Sophia . . . 37
6.6 Exemple de débit observé (sortie Nancy) . . . 37
6.7 Exemple de débit observé (sortie Sophia) . . . 38
Chapitre 1
Motivations
Le développement des réseaux de télécommunication à haut débit a entraîné une utilisation de plus en plus large des applications distribuées. Ces applications impliquent le partage ou la mutualisation de ressources (au sens large : matérielles, logicielles, . . .) géographiquement distribuées. De nouvelles formes de collabora- tions émergent à travers de nouveaux usages de l’outil informatique ; tout cela se regroupant sous le vocable de «grilles».
Comme dans tous les domaines, il est important de comprendre dès le début que prestataires et utilisateurs ont des visions des choses -ici du réseau- assez dif- férentes :
– coté prestataire, une vision hiérarchique : cœur de réseau, réseaux de col- lecte, réseaux locaux, etc. . . ;
– coté utilisateurs (de grille) l’on s’intéresse plutôt à la connexion point à point de sites ou de ressources ; ainsi on parlera d’un émetteur et plusieurs récep- teurs «reliés par le réseau». Dans le monde des grilles le réseau est souvent considéré par les développeurs d’applications et les utilisateurs finals comme une boîte noire.
Ces deux visions finalement complémentaires se retrouvent dans de nombreux domaines connexes et plus particulièrement, ce qui nous intéresse ici, dès que l’on aborde les questions de métrologie :
– le réseau est bien connu et maîtrisé de bout en bout par l’exploitant qui peut procéder à de nombreuses mesures pour en superviser le fonctionnement ; – mais, encore une fois, dans le monde des grilles nous sommes habitués à
nous intéresser aux sites extrémités. Si les caractéristiques des sites sont bien connues (puissance de calcul ou de stockage installée, etc. . .), il n’en est pas de même des détails de l’interconnexion. Il est alors difficile pour com- prendre ou prédire le comportement des applications distribuées de choisir des métriques réseau pertinentes et d’interpréter correctement les mesures et les résultats obtenus.
8 Motivations
Ce projet cherche à déterminer quelles sont les métriques réseau utiles pour contrôler et comprendre l’exécution d’applications distribuées sur les grilles. Ces métriques doivent avoir un sens du point de vue de l’application et non de l’in- frastructure. Pour répondre à cela, nous travaillerons essentiellement sur la plate- formeGrid5000[1] dont les sites sont interconnectés via l’infrastructure fibres noires deRENATER[2] ; il s’agit d’une plate-forme expérimentale. Nous étudie- rons aussi les «retours» des projets de grille de production commeEGEE[3] et bien sûrIGTMD[4] auxquelles les conclusions de cette étude s’appliqueront.
Outre cette brève introduction, ce document est organisé de la façon suivante : – synthèse des besoins des utilisateurs et des applications (Chapitre 2) ; – définition des mesures réseaux utiles pour les applications distribuées (Cha-
pitre 3) ;
– un petit état de l’art de l’opérationnel en métrologie sur les grilles expéri- mentales ou de production existantes (Chapitre 4) ;
– nous présentons ensuite quelques approches possibles pour mettre en œuvre une métrologie applicative en prenant comme support la plate-forme expéri- mentaleGrid5000(Chapitre 5) ;
– enfin une présentation des expérimentations effectuées sur la plate-forme Grid5000(Chapitre 6). . .
– . . . précèdent la conclusion (Chapitre 7).
Chapitre 2
Les Besoins
Il s’agit de déterminer quelles sont les métriques réseau utiles pour comprendre, contrôler et prédire le déroulement des applications sur les grilles.
Afin d’être pertinentes pour les développeurs et les utilisateurs d’applications distribuées, ces métriques doivent avoir un sens du point de vue de l’application et non de l’infrastructure. Il est aussi nécessaire de préciser quels outils permettent d’effectuer ces mesures et dans quelles conditions ils doivent être utilisés.
2.1 Développeurs et utilisateurs
Notre premier travail fut d’identifier une population de développeurs et d’utili- sateurs, la plus large possible qui soit représentative des «usagers des grilles». Pour cela nous nous sommes tournés vers le projetGrid5000[1]. LeGIP RENATER est fortement impliqué dans ce projet pour lequel il fournit une infrastructure réseau spécifique. Les outils de communication déployés dans le cadre du projet (listes de diffusion, wiki,. . .) permettent un contact aisé avec les autres organismes parte- naires du projet ainsi que les administrateurs des sites concernés et les utilisateurs -plusieurs centaines- de la plate-forme.
Une enquête a été notamment diffusée sur les listes pour tenter de cerner les caractéristiques des applications déployées sur la plate-formeGrid5000ainsi que les questionnements et les attentes des développeurs et des utilisateurs vis à vis de l’infrastructure réseau.
Rappelons que l’objectif du projetGrid5000est avant tout de mettre à dis- position un grand instrument pour la recherche en informatique. Cette plate-forme sert de support à un grand nombre d’expériences très hétérogènes. Nous sommes parfois loin des problématiques applicatives de la physique fondamentale ou en- core de la bioinformatique sur des grilles de production comme EGEEou encore IGTMDqui nous intéressent plus particulièrement ici.
En revanche, dans ce contexte, les usages de la grille sont plus facilement ob- servables. Nous avons en outre affaire à une population de chercheurs en informa-
10 Les Besoins
tique plus à même d’expliciter leurs besoins vis-à-vis d’une infrastructure dont ils connaissent mieux les détails.
Dans le cadre deGrid5000, les expériences les plus courantes concernent – l’étude ou l’amélioration des protocoles de transport ;
– le développement d’outils système ou de simulateurs ;
– les adaptations et les portages de logiciels existants sur des infrastructures de grille.
Les paragraphes qui suivent présentent une synthèse des réponses collectées dans la communautéGrid5000. Pour avoir un point de vue plus large, et peut être plus «orienté applications», nous avons aussi contacté des utilisateurs d’EGEEet étudié les résultats d’enquêtes générales. Là, nos sources viennent principalement de l’Open Grid Forum (OGF) [5] et notamment des travaux effectués par le groupe SAGA-RG[6] pour développement d’une API, interface de programmation pour applications grille[7] et une étude sur le monitoring dans les grilles[8].
Ces études présentent une vision des «utilisateurs» assez différente de celle que nous avons pu dégager dans le contexteGrid5000. Là, les utilisateurs «voient»
en priorité les services offerts par l’infrastructure de la grille et par les sites. Ils s’intéressent peu à l’utilisation de la ressource réseau qui, pour eux, reste souvent transparente.
2.2 Besoins des utilisateurs
Découverte de ressources Soumission de tâches
Accès aux données (transferts, réplications) Surveillance des applications "monitoring"
L’utilisateur se connecte à la grille et souhaite lançer des applications distri- buées, il veut maximiser son efficacité (les bons outils au bon endroit. . .) tout en minimisant les «coûts» (temps d’attente, consommations de ressources, . . .).
Découverte de ressources C’est la possibilité d’interroger le système pour con- naître les ressources disponibles et vérifier l’adéquation de ces ressources avec les besoins de l’application avant de lancer des travaux dans un environnement de grille. Cela inclut bien sûr les besoins en terme de réseau.
Soumission de tâches Les applications distribuées sont le plus souvent basées sur des modèles de tâches. La soumission et la suppression de tâches sont les opé- rations de base mais d’autres sont présentées également comme indispensables ou très importantes : typiquement l’interruption, le redémarrage, la migration, . . . La topologie et les caractéristiques du réseau ont un impact important sur les stratégies de placement de tâches et de migration.
2.3 Besoins des développeurs 11
Accès aux données (transferts, réplications) Les données utilisées par les ap- plications sont le plus souvent distribuées et localisées sur des sites distants. Le coût d’accès aux données est non uniforme et il est important de pouvoir l’évaluer :
– ces données doivent pouvoir être être manipulées de façon transparente, in- dépendamment de leur localisation physique ; recherche, lecture, écriture, etc. . . (typiquement en utilisant un système de fichier distribué,. . .) ;
– il faut aussi pouvoir répondre aux besoins de réplications de données (copies, synchronisations) typiques de certaines applications grille ;
– enfin les transfers doivent se faire de façon automatique et, dans le cas de grandes masses de données, bénéficier d’optimisations (type "data strea- ming", etc. . .).
Surveillance des applications "monitoring" Le paramétrage et le dimension- nement des systèmes nécessitent de collecter des informations sur les applications elles-mêmes et sur le déroulement des exécutions, ce que nous regroupons sous le nom de données de surveillance ou "monitoring". Les outils généralement utilisés surveillent efficacement les tâches et la consommationCPUmais plus rarement le réseau.
2.3 Besoins des développeurs
Modèles d’exécution Configuration
Validation des observations Analyse des mesures
Les points qui suivent sont plutôt soulevés par les développeurs et nous citons ceux qui concernent plus spécifiquement des besoins précis des applications vis à vis du réseau .
Modèles d’exécution La grille doit pouvoir supporter les modèles d’exécution les plus courants des applications distribuées. En effet peu d’applications ont été conçues «directement pour la grille». Souvent l’on cherche à «grillifier» des appli- cations qui sont conçues pour être déployées sur des calculateurs parallèles ou sur des grappes dePCs, c’est le cas dans le domaine du calcul intensif. Les intergiciels proposent alors des extensions qui permettent d’utiliser les outils de programma- tion utilisés dans ces applications sur plusieurs machines sur plusieurs sites :
– l’échange de messages (fragments de données indépendants avec format indéfini) . Ce modèle est implémenté dans la bibliothèque MPI[9] ou en- corePVM[10], il est très utilisé dans les applications de la simulation numé- rique et il existe des extensions aux bibliothèques classiques, par exemple gridMPI[11] ;
12 Les Besoins
– d’une façon générale les différents schémas de communication : synchrone, asynchrone, gestion d’événements au niveau applicatif. Sur ce dernier point, de nombreuses études se sont intéressées aux mécanismes de l’appel distant de procédures "Remote Procedure Call" pour les grilles (gridRPC), voir par exemple [12].
Configuration Dans le cadre de déploiements applicatifs, il faut pouvoir ajuster au mieux certains paramètres des applications ou des environnements d’exécution (protocoles, . . .).
– l’aspect statique concerne le placement et l’ordonnancement des tâches pour tirer parti des caractéristiques des ressources réseau utilisées ou réservées pour une application (performances nominales, topologies, etc. . .) ;
– l’aspect dynamique où l’on s’intéresse à la redistribution des tâches et des flux d’une application distribuée nécessite d’observer et de prédire le com- portement du réseau.
Si l’on reprend l’exemple du calcul intensif sur des supercalculateurs ou des grappes dePCs, l’on voit que ces questions se posent déjà mais dans un environnement où l’on considère le réseau comme dédié et les coûts des transferts comme uniformes, ce qui n’est pas du tout le cas sur les grilles.
Validation des observations Il s’agit de justifier et d’interpréter correctement les résultats des mesures effectuées au niveau applicatif :
– en les complétant par des informations décrivant l’état de l’infrastructure au moment de l’exécution de l’application (typiquement la charge, etc. . .) ; – en expliquant les variations de performance -la sensibilité- dues à des per-
turbations hors-exécution (interférences).
Le problème plus général est celui de la reproductibilité. Les expérimentateurs ont besoin de connaître précisement le contexte dans lequel ils ont travaillé. Ce point est crucial pour la réalisation de suites de tests de mesures (benchmarks) notamment si ils sont de courte durée (2 à 15 minutes).
Analyse des mesures Les résultats observés lors de l’exécution d’une applica- tion doivent pouvoir être comparés aux résultats fournis par un modèle du réseau (et de la grille) utilisé pour l’expérience.
2.4 Conséquences : que veut-on mesurer, comment ?
Performances instantanées Performances moyennes Caractéristiques des flux
Haute fréquence d’échantillonnage
2.4 Conséquences : que veut-on mesurer, comment ? 13
Finalement, développeurs et utilisateurs se retrouvent lorsqu’il s’agit de tra- duire leurs besoins en terme d’observations et de mesures sur le réseau.
Performances instantanées Nous nous intéressons à la latence de site-à-site ainsi qu’à la bande passante, mesurées activement ou à la demande de l’utilisa- teur.
Performances moyennes De même, il s’agit de la latence de site-à-site ainsi que de la bande passante mais l’on s’intéresse cette fois-ci aux valeurs moyennes entre sites et aux écarts par rapport aux moyennes.
Pour le réseauRENATER, les débits des interfaces sont mesurés et les données collectées sont accessibles sur le site du projetGrid5000[1]. Actuellement (dé- but 2007), la latence n’est mesurée que sur l’infrastructure en liaisons louées, pas sur la fibre noire (cela est du à un problème de disponibilité des sondes).
Caractéristiques des flux Nous cherchons ici à identifier les flux de trafic uti- lisant le réseau, leurs dates de début et de fin, et à pouvoir les identifier selon les adressesIP1et les ports de la source et de la destination.
Cela implique la mise en place sur les équipements, d’outils logiciels d’ana- lyse des flux, cela se fait normalement sur les routeurs (niveau routage, service de transport de niveau 3) mais il est possible aussi de les utiliser au niveau des commutateurs (transport ethernet (de niveau 2). Cette possibilité est offerte parRENATERsur la fibre noire pour les utilisateurs deGrid5000. En standard, sur les routeurs des nœuds RENATERces données sont collectées via le logiciel Netflow[13]. Ces mesures ne sont pas publiques.
Haute fréquence d’échantillonnage La haute fréquence est demandée pour pou- voir détecter les variations ponctuelles qui pourraient perturber les résultats des ex- périences. Garantir qu’il n’y a pas eu de perturbations permet aussi d’envisager de diminuer la durée des expériences en extrapolant les résultats.
Notons que les requêtes de typeSNMP2effectuées sur les équipements ont une fréquence d’échantillonnage de 5 minutes. On ne descend pas, en général, en des- sous du seuil de 5 minutes pour des considérations opérationnelles. Typiquement, ces mesures sont utilisées par l’exploitant du réseau pour en estimer la charge.
1"Internet Protocol" utilisé pour le routage des paquets sur les réseaux.
2SNMP"Simple Network Management Protocol" est un protocole de communication qui permet aux administrateurs de superviser à distance les équipements du réseau.
14 Les Besoins
2.5 Synthèse
Observation Prédiction Modélisation Déploiement Validation
Comme nous l’avons écrit, Grid5000, en tant qu’instrument de recherche, accueille des expériences très hétérogènes. Toutes ne sont pas intéressés par la métrologie réseau. Néanmoins on peut scinder en deux catégories, selon la finalité, celles qui s’intéressent à la collecte de données de métrologie réseau :
Observation Il s’agit de l’observation du réseau et d’étudier les différents proto- coles de transport des données.
Prédiction Autre approche, où l’on cherche à comprendre, améliorer ou encore prédire le comportement et les performances des applications utilisant de façon intensive le réseau.
Ces deux groupes expriment des besoins communs en ce qui concerne les outils et la méthodologie à mettre en œuvre :
Modélisation La construction de modèles statiques et dynamiques de la grille permettrait de mieux connaître l’utilisation du réseau faite par les applications, en fonction de paramètres décrivant la ressource «brute» disponible et sa charge au moment de l’exécution des tâches.
Déploiement La ressource réseau doit être prise en compte pour l’ordonnance- ment statique et dynamique des applications distribuées sur plusieurs sites (tâches applicatives dans le cas d’une grille de production, expériences dans le cas de Grid5000). Dans beaucoup de systèmes, cette optimisation tient compte uni- quement de la charge des sites «extrémités» de la grille. Enfin une compréhension plus fine du comportement de la grille, prenant en compte le réseau, permettrait de mettre en œuvre de mécanismes d’auto-adaptation plus fins (redéploiement, etc. . .).
Validation Les résultats doivent être vérifiés pour corroborer la validité des don- nées des expériences ; étudier la reproductibilité ; construire des modèles de com- paraison et rectification ; chercher à donner une validité aux données en sortant du cadre de l’expérimentation (dimensionnement des applications, des équipements sur les sites voire même des infrastructures).
Chapitre 3
Métriques réseau adaptées aux grilles
3.1 Sources, terminologie
Plusieurs groupes de travail se sont intéressés aux mesures utiles pour les ap- plications grilles effectuées sur le réseau. Le GGF, "Global Grid Forum" [14] a notamment produit un document [15] où ces mesures sont étudiées selon la pro- priété traitée puis classées de façon hiérarchique. Ce document s’intéresse aussi à la façon d’obtenir les mesures et propose des standards dans le domaine de la métrologie réseau pour les applications et services sur les plates-formes de grille.
Il faut remarquer que la terminologie utilisée par leNMWG"Network Measure- ment Working Group"[16] duGGFainsi que la façon d’obtenir les mesures corres- pondant à ces métriques ne sont pas toujours en accord avec les définitions publiées précédemment par le groupe de travailIPPM"IP Performances Metrics" [17] qui, dans le cadre de l’"Internet Engineering Task Force" IETF[18] s’intéressait aux performances de l’internet.
Tout cela peut conduire à des confusions. Aussi nous donnons dans la table ci-dessous une comparaison des nomenclatures utilisées dans les groupes NMWG etIPPM. Ce tableau est tiré de [19], on y retrouve, la terminologie commune, les correspondances et enfin les termes «GGF» qui n’ont pas d’équivalent «IETF»
(Les termes anglais sont volontairement conservés).
16 Métriques réseau adaptées aux grilles
NMWG (GGF) IPPM (IETF)
one-way delay round trip delay one-way loss round trip loss
jitter delay variation
availability connectivity
capacity link bandwidth capacity achievable bandwidth bulk transport capacity
available bandwidth pas d’équivalent utilization pas d’équivalent
FIG. 3.1: Métriques réseau pour les grilles
3.2 Quelles métriques pour les applications ?
Disponibilité Bande passante Délai
Perte de paquets
Reclassement de paquets
Nous donnons ici une liste des caractéristiques du réseau qu’il est souhaitable de pouvoir mesurer ou estimer pour interprêter le comportement d’une application distribuée «grille».
Disponibilité Cette information permet de savoir quand le réseau est ou non dis- ponible. La mesure de cette disponibilité peut être un pourcentage qui représente, par exemple, la congestion. Cette notion s’applique au réseau tout entier (c’est-à- dire, vu des grilles, point à point) ou seulement à une partie de celui-ci.
Bande passante Cette notion recouvre plusieurs mesures possibles :
3.2 Quelles métriques pour les applications ? 17
– la capacité maximale de l’infrastructure réseau utilisée ;
– la bande passante disponible au niveau applicatif, qui dépend, en plus des caractéristiques des équipements installés sur les sites : grappes de PCs, systèmes d’exploitation, interfaces réseau, etc. . . ;
– ou. . . l’utilisation qui en est faite mesurée sur l’infrastructure ; – et de même la bande passante mesurée au niveau applicatif ;
Ces mesures peuvent servir à régler finement les paramètres des protocoles de transport comme TCP1 ou encore à construire des modèles de prédiction pour le comportement du réseau. Toutes sont importantes car la comparaison des mesures au niveau applicatif et au niveau infrastructure permet d’évaluer comment l’appli- cation tire parti des capacités de l’infrastructure. Notons enfin que la fiabilité de ces mesures peut dépendre de la fréquence d’échantillonnage utilisée.
Délai Le délai recouvre plusieurs mesures de la même manière que la bande passante :
– les délais théoriques et mesurés de l’infrastructure réseau utilisée ;
– le délai mesuré au niveau applicatif qui dépend, en plus des caractéristiques locales des sites de la grille ;
Les mesures peuvent varier notablement, on se basera dans les modèles sur des va- leurs moyennes mais on pourra s’intéresser aussi à la gigue (variation du délai). En outre le délai peut aussi être mesuré de façon unidirectionnelle ou en aller-retour.
Le deuxième n’étant pas, en général, le double exact du premier, car les chemins, traitements, et autres caractéristiques peuvent varier selon le sens de parcours entre deux sites (routage asymétrique). Obtenir le délai aller-retour ne nécessite qu’un point d’observation (et une horloge) ce qui plus simple que d’estimer le delai uni- directionnel. Il en est de même pour la variation de délai (gigue).
Perte de paquets La perte d’un seul paquet n’affecte pas trop les applications, mais les pertes fréquentes peuvent avoir des répercussions sérieuses. La sensibilité aux pertes dépend largement de l’application. La mesure pertinente est le taux de perte (pourcentage de paquets perdus.)
Reclassement de paquets Comme pour les pertes, le reordonnancement des pa- quets n’affecte les applications que s’il se produit fréquemment.
1"Transmission Control Protocol", protocole de transport fiable, se situe entre la couche de réseau (généralement le protocoleIP) et la couche application.
18 Métriques réseau adaptées aux grilles
3.3 Données environnementales
Liste de sauts Acheminement Queues
Nombre de sauts Il s’agit de la liste spécifique des sauts qui composent un che- min entre deux sites (en périphérie de réseau, au lieu d’interconnexion des sites de la grille). Cette liste peut être faite à plusieurs niveaux, un simple saut au niveau 3 peut consister en plusieurs sauts des niveaux inférieurs.
Transport Cette information concerne la façon dont sont acheminés les paquets.
Cela inclut les protocoles de transport et les politiques de gestion des files d’attente.
Files d’attente Le comportement des applications peuvent varier en fonction des caractéristiques des files d’attente (la politique de gestion des rejets "drops" en est un exemple). Les comportements statique et dynamique des queues servent à créer des modèles qui à leur tour vont servir à comprendre le comportement du réseau.
Chapitre 4
Métrologie et grilles
Du point de vue des applications, le réseau a longtemps été considéré comme une ressource transparente : «dès qu’il marche bien et ne pose pas trop de soucis, les utilisateurs ne regardent pas ce qui s’y passe». Toutefois si l’on s’y intéresse, on s’aperçoit rapidement que le problème peut être très complexe. Au contraire des réseaux d’interconnexion des machines parallèles ou des grappes dePC, il est rare que le réseau à longue distance soit «dédié» à l’application distribuée. Les sites (ou nœuds) de la grille sont interconnectés via un ou plusieurs réseaux dont on ignore en général la topologie exacte et qui sont controlés par d’autres organismes. Ces organismes n’ont éventuellement rien à voir avec les projets de grille concernés, c’est typiquement ce qui se passe si l’on pense à des sites connectés par internet.
Cependant la situation évolue et dans de nombreux projets, on considère main- tenant le réseau comme une des ressources nécessaires à l’application. Typique- ment de tels efforts sont faits dans le cadre du projetEGEE[20].
Ces changements de mentalité au sein des projets de grille nous font passer petit à petit, d’une vision stricte des sites (dans laquelle il ne fallait qu’instrumenter les nœuds sans s’occuper de l’interconnexion) à une vision plus globale. Le besoin d’outils pour analyser ce qui se passe dans la couche réseau va de pair avec le développement des intergiciels "middleware".
Le déploiement de ces intergiciels doit être aussi peu intrusif que possible, pour les applications qu’ils supporteront ("le software") et pour les matériels et systèmes d’exploitation ("l’hardware") qu’ils interconnectent. Pour les aspects métrologie, il s’agira donc de collecter l’information disponible au plus bas niveau pour la mettre en forme et la diffuser aux couches applicatives.
Dans le projetEGEEplusieurs interfaces entre l’intergicielg-Lite[21] et les couches basses sont prévues, elles s’appuient sur les outilsPerfSONAR[22][23]
ete2emonit[24].
Néanmoins aucun de ces outils ne propose de nouvelles métriques orientées applications.
Cela s’explique par les difficultés que l’on a, à caractériser les applications de grille du point de vue de l’utilisation du réseau et plus globalement à cerner les
20 Métrologie et grilles
besoins des utilisateurs.
On peut faire à ce propos un parallèle avec les benchmarks utilisés pour la si- mulation numérique. Il existe des suites de codes qui permettent de mesurer les performances des machines pour des domaines d’application donnés. Cela per- met de dimensionner les machines en fonction des besoins des applications qui s’exécuteront dessus. Notons que ces benchmarks, sauf pour les tests de charge, s’exécutent le plus souvent sur des machines dédiées.
Il n’y a pas l’équivalent dans le domaine des réseaux ce qui fait que les dé- veloppeurs d’application et les utilisateurs ont beaucoup de mal à exprimer leurs besoins et à interprêter les (éventuellement mauvaises) performances des applica- tions sur des plates-formes de grille. Rappelons encore une fois que le réseau est une ressource a priori partagée.
Pour avancer dans ce domaine, nous étudierons plus particulièrement la plate- formeGrid5000 qui supporte de nombreux outils plus «orientés réseau» pour surveiller le comportement des applications.
4.1 Outils de surveillance pour les grilles
Nous nous intéressons maintenant aux outils de surveillance installés sur les plates-formes de grille opérationnelles. Ce sont bien ceux dont nous parlions pré- cédemment et qui se situent «au niveau de l’intergiciel». Nous les qualifierons de
«publics» car il peuvent être installés sans interférer avec les couches basses (OS) auprès desquelles ils se contentent de collecter des informations.
Nous avons regardé quelques projets représentatifs des déploiements opéra- tionnels de grilles (il y en a beaucoup d’autres).
– EGEE[3], grille opérationnelle européenne ;
– BalticGrid[25], extension de la grille européenne aux pays baltes, proche d’EGEE;
– EUChinaGrid[26] extension de la grille européenne vers la chine, – LCG[27] qui est la grille de calcul pour le projetLHC"Large Hadron Colli-
der"[28] ;
– Naregi[29] initiative nationale de grille au Japon ;
– National Grid Service (NGS)[30] initiative nationale de grille au Royaume Uni ;
– NorduGRID [31], grille opérationnelle sur les pays du nord de l’europe mais aussi la Russie, l’Australie ; proche d’EGEE;
– PlanetLab[32] plateforme pour l’expérimentation des services grille à l’échelle mondiale, plutôt orientée réseau ;
– ScotGrid[33] initiative régionale de grille (Ecosse) ;
– GridPP[34] grille de calcul pour la physique (Royaume-Uni) ainsi que SouthGridqui est un projet interne àGridPP[35] ;
– TeraGrid[36] est un projet de grille de recherche à très hautes perfor- mances orientée calcul intensif (HPC) aux Etats-Unis.
4.1 Outils de surveillance pour les grilles 21
Notons que BalticGridetNorduGRIDsont basées un intergiciel spéci- fique ARC "Advanced Resource Connector"[37]. interopérable avec l’intergiciel g-Lited’EGEE.
Outils de supervision Projets Grille
e2emonit EGEE
Ganglia NGS
ScotGrid PlanetLab SouthGrid GITS (Grid Integration NGS
Test Script)
GVS (Grid Visualisation Naregi System)
GridICE EUChinagrid
LCG ScotGrid
Gstat GridPP
LCG
SouthGrid Monitoring Mat(nœuds) ScotGrid OCM-g (OMIS-Compliant BalticGrid Monitor for the Grid)
perfSONAR EGEE
SAM monitoring system LCG
SouthGrid Network Weather Service TeraGrid Outils spécifiques d’observation PlanetLab et de mesures réseau PlanetLab
FIG. 4.1: Outils de surveillance des grilles
Nous présentons les outils de supervisions installés sur ces plates-formes. Le tableau 4.1 indique plus précisement quel outil est associé à quel projet. La plupart des outils sont orientés «services» ou «contrôle des nœuds » à l’exception notable de e2emonit et de Network Weather Service. perfSONAR concerne bien sûr tout particulièrement le réseau mais ce dernier est un outil de plus bas niveau qui dans notre optique est plutôt utilisé comme source de données pour la supervision.
– e2emonit[24] outil de surveillance des performances du réseau développé dans le cadre du projetEGEE;
22 Métrologie et grilles
– Ganglia[38] système de surveillance des nœuds d’une grille ;
– GITS[39] ensemble de scripts qui permettent de tester les différents services d’une grille ;
– GVS[40] permet de visualiser l’état des ressources d’une grille (NAREGI) ; – GridICE[41] est un outil de surveillance distribué pour les grilles ; – Gstatest un système centralisé de surveillance de grille utilisé notamment
dansEGEE;
– MATtool[42] outil de supervision plutôt destiné aux grappes dePC; – OCM-g[43] Grid enabled OMIS1Compliant Monitoring s’intéresse plutôt à
la surveillance des applications parallèles (type MPI) ;
– perfSONAR[22] est une infrastructure pour la surveillance des performances du réseau à travers plusieurs domaines, c’est un outil plus orienté opérateur ; – SAM[44] SAM-Grid Information monitoring System, il s’agit du système de contrôle de la grille SAMqui est un projet du Fermi National Accelerator LaboratoryFNALaux Etats-Unis (du même type queLCG) ;
– Network Weather Service[45] est un système distribué de controle et de prédiction des performances du réseau et des ressources de calcul des sites.
Notons enfin que les participants au projetPlanetLabdisposent d’un certain nombre d’outils et de services propres au projet pour controler le trafic réseau (voir notamment "Network Measurement & Observation" dans [32]).
4.2 Outils de surveillance du réseau (Grid5000)
Pour avoir plus d’informations sur le comportement du réseau, il faut utiliser des outils de «plus bas niveau» mais ceux ci ne sont en général plus accessibles aux utilisateurs. Si l’on regarde plus particulièrement le cas deGrid5000, on s’aper- çoit que ces outils sont reservés aux «administrateurs» du projet ou à l’exploitant du réesau (RENATER).
Les outils disponibles sont :
– Argus[46], un logiciel permettant de superviser les différents équipements d’un réseau local ainsi que les applications associées ;
– Looking Glasscet outil permet un accès en temps réel aux informations concernant les les routeurs et les commutateurs du réseau à travers une in- terfaceWEB;
– Netflow[13] est un logiciel d’analyse des fluxIPdéveloppé parCISCO. – Sflow [47] est un standard industriel pour le contrôle du trafic sur les ré-
seaux.
Les outils de flux commeNetflowet Sflowdonnent une vision détaillée des flux qui circulent dans le réseau. Cela permet de comprendre le comportement d’une expérience a posteriori, grâce à la distinction (par origine, port, etc.) de ses paquets.
1"On Line Monitoring Interface Specification"http://www.lrr.in.tum.de/\~omis
4.2 Outils de surveillance du réseau (Grid5000) 23
– les sondes : les mesures actives sont faites par des sondes [48] placées sur les équipements et par lemulticast beacon[49]. Elles permettent de caractériser le comportement du chemin suivi par les paquets envoyés. Les mesures sont acquises soit par l’envoi de paquetsudp2 point à point (cas des sondes) soit à travers des groupesmulticast(cas du multicast beacon). Les valeurs fournies sont la latence, la gigue, les pertes de paquets et le nombre de sauts du chemin. Elles permettent ainsi de savoir comment se comporte le réseau sur un chemin donné.
– les outils SNMPpermettent de connaître le débit sur chaque interface des équipements en cœur de réseau, ainsi que la charge (cpu) des machine. Ils répondent aux besoins de vision de «connectivité» et de «débit utilisé».
– laWeather Map. Dérivés des outils SNMP, des outils de visualisation du réseau sont mis en place. Les weathermaps ne sont que des cartes du réseau.
Les liens sont présentés en différentes couleurs selon leur état (disponibilité, coupure, . . .) et leur charge, voir par exemple [50] pour le réseauRENATER.
– Tickets: les tickets d’incident permettent d’être au courant des problèmes (pannes, coupures, . . .) qui se sont produites ou qui sont prévues, par exemple dans le cadre des maintenances. Ils répondent aux besoins :
– de planification, en lancant les expériences dans des fenêtres a priori sans perturbation ;
– de validation, en vérifiant a posteriori si le réseau utilisé était disponible et en bon état quand l’expérience a eu lieu.
Le tableau suivant présente les outils utilisables dans le cadre deGrid5000 en précisant leur accessibilité.
Outils réseau Utilisés par
Argus RENATER
Looking Glass RENATER MIBs SNMP RENATER
Netflow Grid5000admin
RENATER(sauf fibre noire)
Sflow Grid5000admin
Sondes RENATER
Tickets RENATER
Weather Map RENATER
FIG. 4.2: Outils réseau dansGrid5000
2"User Datagram Protocol" protocole de télécommunication utilisé par Internet. Il fait partie de la couche transport deTCP/IP.
24 Métrologie et grilles
4.3 Métriques réseau versus métriques grille
Ce panorama des métriques vient conforter le point de vue de l’article du GGF[15] présenté plus haut (cf. 3.1). Les métriques utiles pour les grilles tant du point de vue des administrateurs que des développeurs et utilisateurs d’applications sont en fait identiques à celles utilisées par les opérateurs du réseau.
Seulement elles ne mesurent pas du tout la même chose. Les mesures point à point entre deux systèmes installés sur des sites distincts de la grille sont effectuées à travers plusieurs portions hétérogènes de réseau :
– le cœur de réseau (par exempleRENATER) ;
– les réseaux de collecte qui relient les sites de la grille aux nœudsRENATER; – les réseaux «de site» (typiquement de campus) qui connectent les machines
au réseau de collecte ;
– et enfin le réseau d’interconnexion des grappes dePC("clusters").
Elles sont sensibles aux équipements réseau, aux calculateurs installés sur les sites et aux logiciels applicatifs utilisés. La façon correcte de relever ces mesures et comment on doit les interpréter est encore largement du domaine de la recherche.
La priorité, comme nous l’avons déjà signalé devant être de se baser sur des suites de tests "benchmarks" pour aider le monde des applications à évaluer les besoins réseau et à effectuer des mesures de performances significatives.
Chapitre 5
Approches possibles sur la plate-forme Grid5000
D’après les informations que nous avons obtenues des usagers des grilles : uti- lisateurs et développeurs d’applications, nous présentons ci-dessous les approches possibles pour la mise en œuvre d’une métrologie orientée applications. Ces solu- tions ne s’excluent pas entre elles, nous verrons qu’elles sont plutôt complémen- taires. Pour chacune nous présentons les besoins couverts et les problèmes rencon- trés. La discussion est faite dans le cadre du projet Grid5000mais s’applique bien sûr à toute plate-forme opérationnelle.
5.1 Présentation de la plate-forme Grid5000
La plate-forme Grid5000comprend 9 sites qui seront à terme connectés à l’infrastructure projet de RENATER en fibres noires et reliés entre eux par des lambdas dédiés à 10 Gb/s. Le cœur du réseau d’interconnexion de la grille est donc fourni parRENATER. Mais si l’on s’intéresse aux applications donc aux performances «de bout en bout», il faut aussi prendre en compte (même si la plate- formeGrid5000est plus homogène que les grilles de production que nous avons étudiées) les réseaux et les équipements qui relient les machines installées sur les sites aux nœudsRENATERet même, comme nous l’avons dit plus haut, le réseau d’interconnexion des grappes dePC("clusters").
La figure 5.1 résume ces informations qui sont détaillées sur le site du projet [1]. Mais c’est seulement en possession de la topologie exacte de la grille et donc des chemins de données que l’on peut s’interroger sur les données à collecter et sur la façon de le faire dans le cadre d’une métrologie orientée applications.
26 Approches possibles sur la plate-formeGrid5000
FIG. 5.1: InterconnexionGrid5000
5.2 Réutilisation des donnéesSNMP 27
5.2 Réutilisation des données SNMP
Sur la plupart des sites, des mesures peuvent être faites (ou sont déjà faites) sur les commutateurs et les routeurs. Ces mesures sont consultables en utilisant le protocole SNMP. Cependant, les données collectées ne sont pas toujours visibles aux utilisateurs, elles sont réservées pour le contrôle des ressources effectué par les administrateurs du réseau ou du site. Il s’agit donc ici de proposer une vision
«utilisateur» du réseau. Une simple vision des débits aux interfaces des équipe- ments permettrait déjà aux usagers de décider s’ils doivent ou non lancer leurs expériences à un moment donné et aussi de valider a posteriori le déroulement des expériences.
Avantages :
⊲ ce service est déjà fourni aux usagers de la plate-formeGrid5000à travers une page web qui permet de visualiser la charge des interfaces (accessible sur le site du projet [1]). L’affichage est couplé à un service de téléchargement des données au cas où elles seraient utiles (statistiques, courbes, etc. . .) mais aussi pour «rejouer» les conditions d’une expérience ;
⊲ les outils visuels de charge du réseau (weather maps) sont aussi disponibles à partir de ces données.
5.3 Outils de flux backbone
Les outils de flux donnent une vision très détaillée des communications se pro- duisant à travers le réseau où ils sont installés. Dans cette idée, on envisage de les implanter sur les commutateurs de cœur de réseau qui relient les sites de la grille.
Plus concrètement il s’agit de faire en sorte que les commutateurs situés dans les nœudsRENATERauxquels sont connectés les sites de la grille, fassent une analyse des flux qui passent par leurs interfaces.
Avantages :
⊲ les commutateurs en cœur de réseau ont des caractéristiques très proches car ils sont choisis, gérés et installés par le même organisme. La compatibilité des équipements facilite la collecte des données1;
⊲ les données de flux fournissent des informations très concrètes sur les expé- riences qui ne peuvent être obtenues d’aucune autre façon ;
⊲ la vision donnée par les données collectées sur tous les commutateurs permet de suivre l’évolution des expériences sur les liens logiques du backbone.
Problème :
1la compatibilité doit être totale, dans notre cas, les deux versionsV5etV9du logicielNetflow posent des problèmes pour le collecteur.
28 Approches possibles sur la plate-formeGrid5000
◮ l’incompatibilité du type de service que les commutateurs fournissent aux projets (niveau 2) et du niveau requit par l’équipement pour activer l’outil Netflow(niveau 3). Changer le niveau de service fourni aurait un impact trop important sur les projets.
5.4 Outils de flux en périphérie
L’installation des outils de flux en périphérie nécessite leur mise en place dans les commutateurs situés en entrée sur chaque site de la grille et non plus en cœur de réseau. Il s’agit de les installer là où passent tous les trafics entrants et sortants du site. Dans le cas deGrid5000nous sortons du domaineRENATER.
Avantages :
⊲ même remarque que pour les outils "backbone", les flux donnent des in- formations très concrêtes sur les expériences qui ne peuvent être obtenues d’aucune autre façon ;
⊲ l’avantage principal, par rapport à la mise en place d’outils sur les commu- tateurs du backbone, est la facilité d’accès aux équipements qui ne sont pas partagés par plusieurs projets comme ceux qui se situent en cœur de réseau.
Problèmes :
◮ le problème dans ce cas est du surtout à l’hétérogénéité des matériels sur les sites qui constituent la grille. Ainsi, il est possible que les commutateurs d’entrée des sites soient différents les uns des autres, ce qui rend difficile la fusion des données collectées, parfois de natures différentes, en une base d’information cohérente.
◮ enfin, même si les données collectées ont la précision des outils de flux, cette solution masque la complexité de l’interconnexion : on ne voit que le lien logique entre les deux commutateurs.
5.5 Sondes
Les sondes permettent de caractériser le trafic de bout en bout. Les mesures ac- tives qu’elles fournissent permettent de voir le comportement des flux applicatifs utilisant un même chemin. Il est possible de les placer dans trois endroits diffé- rents :
1. Le nœudRENATERqui relie le site au backbone.
2. Le commutateur d’entrée du site.
3. Ou enfin, selon la configuration du site, «au même niveau que les machines», sur le même commutateur dans le réseau interne du site.
Ces trois options ont chacune des avantages et des inconvénients dus à la position de la sonde dans la topologie de la grille.
5.6 Duplication de flux "mirroring" 29
Avantages :
⊲ dans tous les cas la partie analysée du chemin est totalement caractérisée, permettant de voir précisement le comportement réseau des applications ;
⊲ si la sonde est située au nœudRENATER, la gestion est facile car elle est effectuée directement par RENATERqui a déjà mis en place des systèmes similaires.
Problèmes :
◮ en revanche, dans chacune des trois positions possibles pour les sondes, il y a des problèmes différents :
1. En les plaçant aux nœuds RENATER le chemin caractérisé par les sondes est seulement celui du réseau appartenant àRENATER, et pas les parties (réseau de collecte et réseau du site) qui restent en dehors.
On ne mesure que la traversée du backbone, celle qui pose probable- ment le moins de problèmes. . .
2. La deuxième solution, qui place les sondes aux commutateurs d’entrée des sites, permet d’avoir plus d’informations, car on inclut, dans le chemin instrumenté, les réseaux de collecte. Il manque encore la partie concernant les réseaux locaux.
3. Finalement, mettre des sondes «au même niveau» que les machines permet de caractériser la totalité du chemin (mais selon la configura- tion du site, on ne caractérise pas forcément tous les chemins possibles entre machines).
Notons aussi que dans les deux dernières solutions le placement des sondes sur les sites implique une gestion bien plus difficile pour la centralisation des données. Soit elle est effectuée parRENATERet les sites lui permettent l’accès, soit c’est l’ensemble des sites (neuf dans le cas deGrid5000) qui administre les sondes.
◮ en dernier point il faut noter l’aspect économique : le coût des sondes est bien supérieur à celui de la mise en place des autres options (qui elles sont logicielles).
5.6 Duplication de flux "mirroring"
Il s’agit d’offrir la possibilité de voir tout le trafic qui passe sur une interface.
L’usager choisit une interface d’un équipement quelconque dont tout le trafic sera répliqué. Il pourra le capturer et l’analyser avec les outils et les métriques qu’il désire.
Avantage :
⊲ les utilisateurs ont accès à toutes les données qu’ils pourraient désirer ; ils disposent ainsi de l’information «de base» et non pas des extractions (échan- tillonnages, ...) à partir de celle-ci.
30 Approches possibles sur la plate-formeGrid5000
Problèmes :
◮ l’architecture dont nous parlons dans le cas deGrid5000est une infra- structure en fibre noire avec un trafic maximal de 10Gb/s. Dans cette so- lution le principal problème est la grande quantité de données qui circulent chaque seconde dans le réseau, ce qui rend impossible le stockage pour une analyse ultérieure. Il faut mettre en place des techniques d’échantillonnage.
◮ il peut y avoir des problèmes de confidentialité si l’on donne la possibilité d’analyser tout le trafic.
5.7 Adoption d’un intergiciel
La plate-forme Grid5000est un peu particulière car il s’agit d’un outil de recherche en informatique sur lequel il n’y a pas a priori d’ intergiciel "middle- ware" de déployé. Installer un intergiciel sur la grille, dans le cadre des expériences, offre aux utilisateurs une façon de travailler avec la grille et aussi un ensemble de services associés. Jusqu’au présent les possibilités offertes dans le domaine de la métrologie étaient limitées voire nulles, mais certains intergiciels évoluent pour in- tégrer la possibilité d’acquérir des données de supervision du réseau(cf. le cas de g-Litedans le cadre d’EGEE[3]).
Avantage :
⊲ installer un intergiciel déjà pensé pour l’exploitation d’une grille opération- nelle permet de garder une certaine continuité dans la gestion de la grille sans se préoccuper des développements logiciels. Il faudra s’occuper princi- palement des installations et des mises à jour de l’intergiciel.
Problèmes :
◮ l’avantage devient inconvénient dans le cas deGrid5000qui est une plate- forme très ouverte où l’on ne peut pas se permettre de proposer une façon standardisée de fonctionner. L’installation d’un intergiciel déjà conçu et uti- lisé par d’autres organisations crée une dépendance vis à vis de l’organisme qui le développe. Ce point est ici très important, car on ne parle pas seule- ment de systèmes de mesure ou de visualisation de données, mais d’une façon de gérer la grille ;
◮ les intergiciels qui acquièrent des données pour la supervision du réseau de la grille le font par l’intermédiaires de logiciels de collecte qui doivent être installés sur les équipements en accord avec les organismes qui gèrent le réseau d’interconnexion de la grille.
5.8 Quelques points cruciaux 31
5.8 Quelques points cruciaux
Disponibilité des informations Confidentialité
Fréquence d’échantillonnage
Pendant l’étude des solutions, quelques problèmes ont été soulevés plusieurs fois. Ils viennent du fait que le réseau d’interconnexion des sites de la grille n’est pas dédié mais partagé par des autres entités ou projets. Dans le cadre deGrid5000, le coeur du réseau d’interconnexion est dédié à la plate-forme et partagé par les projets.
Disponibilité des informations En tant qu’opérateur réseau,RENATERrecueille des données qui concernent l’utilisation du réseau par les projets. Des discussions récurrentes ont porté sur la pertinence de rendre publiques ces informations aux utilisateurs des différents projets.
RENATERne fournit pas des équipements ou de la technologie mais un service.
Cela signifie, comme nous l’avons déjà indiqué, que les informations concernant le réseau : topologie, caractéristiques des liens, équipements matériels, etc. . . peuvent être modifiés pour des considérations de service.
Il est tout à fait justifié que l’opérateur ne communique pas toutes les infor- mations dont il dispose. Typiquement, les queues des équipements ainsi que leurs politiques internes ne sont pas disponibles pour les utilisateurs bien que certains en aient formulé la demande.
Confidentialité Le réseau est partagé entre différents projets et, à l’intérieur de chaque projet, entre plusieurs utilisateurs. Il peut être nécessaire de respecter des contraintes de confidentialité et les solutions à mettre en place peuvent impliquer de séparer les données concernant des projets distincts.
Dans le cadre deGrid5000, nous avons accès aux données collectées sur les interfaces dédiées des commutateurs du réseau en fibres noires deRENATER. Les valeurs collectées ne concernent pas le détail des usagers, en faisant l’agrégation de tout le trafic qui passe par l’interface.
Notons que ces problèmes de confidentialité se posent aussi pour les outils de flux que nous avions etudiés plus haut (5.3, 5.4 et surtout 5.6). Pour les contourner, il faut mettre en œuvre des techniques d’anonymisation des flux.
Fréquence d’échantillonnage Un dernier point concerne l’échantillonnage des mesures. Là, les utilisateurs et les fournisseurs du réseau ont des visions complè- tement différentes. Les usagers font souvent des expériences de très courte durée et ont besoin de pouvoir détecter des «perturbations» (expériences d’autres uti- lisateurs, . . .) qui ne durent que quelques instants, et qui risquent de fausser les
32 Approches possibles sur la plate-formeGrid5000
résultats. Ainsi l’utilisateur souhaite pouvoir obtenir des courbes d’utilisation des ressources réseau avec une fréquence d’échantillonnage très élevée. En revanche, le fournisseur, dans notre cas -RENATER-, sait qu’il est impossible d’utiliser une fréquence d’échantillonnage trop élevée car cela délivre des mesures qui sont trop fluctuantes pour pouvoir être utilisées pratiquement.
Chapitre 6
Expériences de trafic sur Grid5000
Un certain nombre d’expériences ont été conduites afin de vérifier le compor- tement des sites et du réseau sous certaines conditions de trafic. Dans ces expé- riences, nous observons la bande passante à deux niveaux : «applicatif» et «ré- seau».
6.1 Description de l’expérimentation
Le protocole Nous décrivons ici la nature de l’expérimentation : – les paquets envoyés sont des paquetsUDP;
– les machines s’envoient l’information par paires : 1 récepteur et 1 émetteur ; – tout le trafic est envoyé d’un site qui contient tous les émetteurs à un deuxième
site qui contient tous les récepteurs ;
– l’outil choisi pour la génération du trafic estiPerf[51] ;
– Les données seront extraites des récepteurs iPerfet des commutateurs de RENATER, en utilisant le protocoleSNMP.
Les pré-requis Il s’agit de la phase préparatoire (procédure propre àGrid5000) : – la réservation des ressources du côté émetteur (n machines) ;
– la réservation des ressources du côté récepteur (n machines) ; – la configuration des 2*n machines :
– le déploiement d’une imageDebian(ici debian4all) ; – l’installation du paquetageiPerfsur les machines
⇒ apt-get install iPerf
– enfin l’installation d’une clé publique pour permettre un accès facile aux nœuds.
34 Expériences de trafic surGrid5000
Le déroulement Toutes les actions présentées ci-dessous sont exécutées ou ini- tiées par une machine qui coordonne le déroulement de l’expérience :
– tous les nœuds du côté récepteur exécutentiPerfen mode serveur :
⇒iPerf -s -u -i10
– lesPIDsdes processusiPerfdes serveurs sont gardés ;
– chaque nœud du côté émetteur exécuteiPerfen mode client, en envoyant ybpspendant z secondes :
⇒ iPerf -cipaddress-u -by-tz
– après un temps d’attente de z secondes, chaque nœud récepteur tue le pro- cessus qui exécute le serveuriPerf;
– le coordonnateur collecte les données de chaque serveuriPerf. ;
– il effectue les traitement sur les sorties d’iPerf(sommes et moyennes des trafics envoyés par les n paires de machines) ;
– enfin les données des commutateurs des nœudsRENATERsont récupérés à travers une des pages de métrologie disponible sur le serveur internet ; ces données sont sous forme d’images.
Expériences La figure 6.1 résume les résultats des expériences menées entre les machines situées sur les différents sites deGrid5000.
FIG. 6.1: Résumé des expériences
6.1 Description de l’expérimentation 35
La partie gauche (Configuration Expérience) précise les données expérimen- tales choisies. Notons que les champs «Mbits par nœud» resp. «Gbits par nœud»
correspondent à des volumes1.
Dans la partie droite «Résultats», nous donnons la valeur maximale relevée sur le backboneRENATER(qui est constante pour tous les commutateurs utilisés dans une expérience), ainsi que les valeurs maximales et minimales et le comportement des données seloniPerf.
La case «GraphiPerf» caractérise le comportement dynamique :
– type Ale comportement ne présente pas de fortes variations comme sur la figure 6.2, qui présente les valeurs relevées sur le site de Nancy ;
– typeBle graphe passe d’un maximum à un minimum ; après être «tombé», il passe une autre fois par un maximum. C’est le cas dans la figure 6.3 qui concerne le site de Sophia ;
– typeCle graphe passe d’un maximum à un minimum puis reste au minimum comme sur la figure 6.4 qui correspond au site de Toulouse.
FIG. 6.2: MesuresiPerfcourbe de type A (Nancy)
1sans passer par les transformations données par la base binaire, ainsi 1Mbit = 1000000 bits et non pas 1024*1024bits, etc. . .
36 Expériences de trafic surGrid5000
FIG. 6.3: MesuresiPerfcourbe de type B (Sophia)
FIG. 6.4: MesuresiPerfcourbe de type C (Toulouse)
6.2 Analyse des résultats
Dans tous les tests qui ont été effectués, le comportement du backbone a été conforme à ce qui pouvait être attendu. Le trafic est passé par tous les commuta- teurs du chemin de chaque expérience sans variations visibles.
Les sites utilisés pour faire les tests sont ceux qui sont actuellement (début 2007) connectés à10 Gb/ssur la fibre noire à savoir : Nancy, Rennes, Sophia
6.2 Analyse des résultats 37
et Toulouse. En effet, cela permettait d’injecter facilement suffisamment de trafic pour saturer réseau.
Les seules pertes observées, l’ont été lors d’expériences injectant du trafic à plus de 10 Gb/s. Ces pertes se sont produites au niveau des réseaux des sites quand les liens qui les reliaient au backbone étaient déjà saturés.
Parmi ces sites, Nancy, Rennes et Toulouse n’ont pas eu de problèmes pour émettre des données à10 Gb/sde données, mais sur le quatrième, Sophia, il n’a pas été possible de dépasser les6 Gb/sen sortie de site . Comme cela peut se voir dans le tableau 6.1 et sur les figures 6.3 et 6.5 (où l’input sur l’interface correspond bien à ce qui sort du site).
FIG. 6.5: Interface vers Sophia
Au moment de la réception des données le site de Sophia persiste à montrer cette limitation de capacité (figure 6.7)
FIG. 6.6: Exemple de débit observé (sortie Nancy)
38 Expériences de trafic surGrid5000
FIG. 6.7: Exemple de débit observé (sortie Sophia)
Les outils utilisés pour mesurer le débit circulant sur le chemin de l’expérience sont les outilsSNMPdes commutateurs et l’outil de génération de trafic lui même : iPerf.
Il faut noter que le serveur iPerfne rapporte pas toujours correctement le trafic qu’il reçoit. Il semble que les valeurs ne soient plus fiables au delà de 1 Gbp/s. Néanmoins la valeur maximale reportée pariPerfest exacte et peut être conservée comme référence.
Les expériences sont très difficiles à mener car nous observons sur les sites une intolérance à la saturation des réseaux locaux. L’expérience se déroule nor- malement, mais finit par engendrer des anomalies de fonctionnement sur les outils généraux de gestion des sites (annuairesLDAP, etc. . .) entraînant un dysfonction- nement général de la plate-forme.
Chapitre 7
Conclusions
Il ressort des enquêtes réalisées lors de cette étude que tous les acteurs (admi- nistrateurs, développeurs, utilisateurs, . . .) de la grille considèrent le réseau comme une ressource essentielle. Néanmoins, le réseau est le plus souvent considéré aussi comme une ressource «transparente», ses caractéristiques sont mal connues (ainsi dansGrid5000les détails de l’interconnexion «machine à machine»). Le contrôle et la supervision du réseau sont la plupart du temps effectuées par les opérateurs pour leurs besoins propres alors que les usagers de la grille s’intéressent plutôt aux problèmes et aux besoins des sites.
L’utilisateur final qui voit et utilise les services proposés par la grille pour ses applications peut se contenter de cette vision «boîte noire» dès lors que la ressource n’a pas un caractère bloquant vis à vis de ses besoins.
Mais à un niveau «plus bas», les intergiciels proposent encore largement une vision «orientée sites» tant du point de vue des services que des outils de supervi- sion.
La première raison est que si le réseau local est administré par le site, le ré- seau d’interconnexion des sites est le plus souvent fourni en tant que service (et non matériel) par un opérateur. Cette différence rend impossible une gestion com- mune des différentes parties du réseau utilisés dans une grille et notamment en ce qui concerne la collecte d’informations puisque les équipements des opérateurs, mutualisés avec d’autres communautés d’utilisateurs, ne sont pas accessibles.
Nombre d’utilisateurs viennent du monde du calcul intensif. Ils sont habitués à estimer les besoins de leurs applications en termes de puissance de calcul sur des supercalculateurs ou des grappes ("clusters") munis de réseaux d’interconnexion rapides et dédiés aux applications qui s’y exécutent. Les caractéristiques de ces ré- seaux sont seulement utilisées pour minimiser le surcôut lié au découpage en tâches de l’application, c’est à dire optimiser le rapport «coût du calcul/coût des communi- cations». Les outils de programmation des supercalculateurs, typiquementMPI[9]
ont été adaptés aux grilles pour y déployer les applications existantes mais dans un contexte réseau beaucoup plus difficile à appréhender pour l’utilisateur.
Il est très difficile pour les utilisateurs mais aussi pour les développeurs d’ap-
40 Conclusions
plications «grillifiées» d’estimer leurs besoins en termes de ressources réseau : quelle est la bande passante dont l’application aurait besoin ou le temps de latence maximale supporté,. . .
Le monde des applications est de plus en plus «demandeur» de ressources. Pour la puissance de calcul ou de stockage, il existe des suites de test ("benchmarks") applicatifs qui permettent aux utilisateurs de quantifier leurs besoins et aux admi- nistrateurs des ressources correspondantes de dimentionner les matériels. Tout cela n’existe pas encore en ce qui concerne la ressource réseau longue distance (des grilles). Le bilan est finalement le suivant :
– les besoins «génériques» des utilisateurs sont satisfaits par une ressource largement surprovisionnée par les opérateurs ;
– il y a peu d’études sur le comportement des applications vis à vis des pa- ramètres réseau. Cela vient sans doute du fait qu’il y a aussi peu de plates- formes permettant d’accueillir ce type d’expérimentations ;
– ces expérimentations nécessitent de définir quelles sont les métriques réseau adaptées aux applications, et comment sont réalisées les mesures correspon- dantes ; en première approche, on utilise bien sûr les mêmes métriques que les opérateurs mais il est nécessaire comme nous l’avons vu de les interpréter différemment ou de les combiner comme dans [52]) ;
– les chemins empruntés par les données circulant entre deux tâches d’une ap- plication distribuée sont complexes et traversent plusieurs domaines admi- nistrés par des acteurs différents. Il est très difficile de collecter l’information pertinente du point de vue de l’application. Ainsi, dans le cas deGrid5000, les données qui peuvent être extraites du cœur de réseau sont du niveau 2 et inférieur, ce qui correspond au service délivré parRENATER. Il faut rajouter à cela les informations similaires collectées sur les autres parties du réseau d’interconnexion des sites puis des informations de niveaux supérieurs (ni- veau 3, et mesures «utilisateur», etc. . .). L’ensemble de ces données doit être proposé de façon cohérente à travers un service de la grille ;
– une difficulté supplémentaire vient de l’aspect dynamique des grilles. Si Grid5000propose une plate-forme «fixe», la topologie de la plupart des grilles de production varie en fonction des ressources qui s’y aggrègent ou au contraire ne sont plus disponibles.
Pourtant, une meilleure connaissance des besoins applicatifs et un meilleur controle
"monitoring" du réseau d’interconnexion des sites d’une grille est nécessaire pour optimiser l’utilisation des ressources informatiques :
– pour l’administration de la grille, en effectuant un meilleur ordonnancement des travaux qui prenne en compte les transferts de données, les caractéris- tiques et la disponibilité de la ressource réseau ;
– pour les développeurs d’applications adaptées aux grilles. Ces applications auront la capacité de se reconfigurer dynamiquement en fonction des infor- mations transmises par des «senseurs» réseau ;
– pour l’opérateur du réseau, cela permettrait aussi de dimentionner les res- sources allouées à la grille et de choisir le protocole le plus adapté à certains
41
types d’applications. Les expériences que nous avons faites surGrid5000 montrent que le réseau actuel peut être utilisé presque au maximum de sa capacité théorique. Cependant, les applications de grille qui y sont actuelle- ment déployées en font un usage bien plus restreint. La principale différence réside dans le protocole utilisé. Nous avons fait des expériences en utili- santUDP(sans contrôle), tandis que la pluspart des applications utilisent le protocoleTCP. Ce protocole ne semble pas forcément le plus adapté car il entraine, pour les utilisateur, une baisse de performances notable.
La première étape dans tout cela c’est, comme dans l’approcheEGEEde consi- dérer le réseau comme une ressource de la grille au même titre que la puissance de calcul, le stockage, les applications, . . . On peut alors mettre en œuvre des pro- cessus de contrôle du réseau «orientés applications» qui devient, pour l’utilisateur final une une ressource réservable par tranches et chemins en fonction de besoins applicatifs. Une priorité est alors de concevoir des suites de tests "benchmarks"
orientés reseau pour aider le monde des applications à quantifier ses besoins dans ce domaine et à effectuer des mesures de performances significatives.
42 Conclusions
