Métrologie réseau pour les grilles. Projet IGTMD a

Transcription

1 Métrologie réseau pour les grilles Projet IGTMD a Magì Sanchón Soler b Philippe d Anfray Philippe.d-Anfray@renater.fr GIP RENATER SIPA, Coordination grille version 1.0, 31 Juillet a Interopérabilité des grilles de calcul et transferts massifs de données en vue de l optimisation du traitement des données du LHC, Projet ANR-05-BLAN /NT b Magì Sanchón Soler a travaillé sur ce projet, au GIP 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 PARIS Tél. : Fax : Antenne : GIP RENATER c/o CINES 950 rue de Saint Priest Montpellier Cedex 5 Tél. : Fax : http ://

2

3 Table des matières 1 Motivations 7 2 Les Besoins Développeurs et utilisateurs Besoins des utilisateurs Besoins des développeurs Conséquences : que veut-on mesurer, comment? Synthèse Métriques réseau adaptées aux grilles Sources, terminologie Quelles métriques pour les applications? Données environnementales Métrologie et grilles Outils de surveillance pour les grilles Outils de surveillance du réseau (Grid5000) Métriques réseau versus métriques grille Approches possibles sur la plate-forme Grid Présentation de la plate-forme Grid Réutilisation des données SNMP Outils de flux backbone Outils de flux en périphérie Sondes Duplication de flux "mirroring" Adoption d un intergiciel Quelques points cruciaux Expériences de trafic sur Grid Description de l expérimentation Analyse des résultats Conclusions 39

4

5 Table des figures 3.1 Métriques réseau pour les grilles Outils de surveillance des grilles Outils réseau dans Grid Interconnexion Grid Résumé des expériences Mesures iperf courbe de type A (Nancy) Mesures iperf courbe de type B (Sophia) Mesures iperf courbe de type C (Toulouse) Interface vers Sophia Exemple de débit observé (sortie Nancy) Exemple de débit observé (sortie Sophia)

6

7 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 collaborations é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 différentes : coté prestataire, une vision hiérarchique : cœur de réseau, réseaux de collecte, 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écepteurs «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 comprendre 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 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 infrastructure. Pour répondre à cela, nous travaillerons essentiellement sur la plateforme Grid5000 [1] dont les sites sont interconnectés via l infrastructure fibres noires de RENATER [2] ; il s agit d une plate-forme expérimentale. Nous étudierons aussi les «retours» des projets de grille de production comme EGEE [3] et bien sûr IGTMD [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 (Chapitre 3) ; un petit état de l art de l opérationnel en métrologie sur les grilles expérimentales 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érimentale Grid5000 (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).

9 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 utilisateurs, la plus large possible qui soit représentative des «usagers des grilles». Pour cela nous nous sommes tournés vers le projet Grid5000 [1]. Le GIP 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 partenaires 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-forme Grid5000 ainsi que les questionnements et les attentes des développeurs et des utilisateurs vis à vis de l infrastructure réseau. Rappelons que l objectif du projet Grid5000 est avant tout de mettre à disposition 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 encore de la bioinformatique sur des grilles de production comme EGEE ou encore IGTMD qui nous intéressent plus particulièrement ici. En revanche, dans ce contexte, les usages de la grille sont plus facilement observables. Nous avons en outre affaire à une population de chercheurs en informa-

10 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 de Grid5000, 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 EGEE et é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 contexte Grid5000. 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 distribué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 connaî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.

11 2.3 Besoins des développeurs 11 Accès aux données (transferts, réplications) Les données utilisées par les applications 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, indé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 streaming", etc...). Surveillance des applications "monitoring" Le paramétrage et le dimensionnement 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 consommation CPU mais 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 applications qui sont conçues pour être déployées sur des calculateurs parallèles ou sur des grappes de PCs, c est le cas dans le domaine du calcul intensif. Les intergiciels proposent alors des extensions qui permettent d utiliser les outils de programmation 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 encore PVM[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 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 comportement du réseau. Si l on reprend l exemple du calcul intensif sur des supercalculateurs ou des grappes de PCs, 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 perturbations 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 application 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

13 2.4 Conséquences : que veut-on mesurer, comment? 13 Finalement, développeurs et utilisateurs se retrouvent lorsqu il s agit de traduire 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 utilisateur. 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éseau RENATER, les débits des interfaces sont mesurés et les données collectées sont accessibles sur le site du projet Grid5000 [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 utilisant le réseau, leurs dates de début et de fin, et à pouvoir les identifier selon les adresses IP 1 et les ports de la source et de la destination. Cela implique la mise en place sur les équipements, d outils logiciels d analyse 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 par RENATER sur la fibre noire pour les utilisateurs de Grid5000. En standard, sur les routeurs des nœuds RENATER ces 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 pouvoir détecter les variations ponctuelles qui pourraient perturber les résultats des expé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 type SNMP 2 effectuées sur les équipements ont une fréquence d échantillonnage de 5 minutes. On ne descend pas, en général, en dessous 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. 2 SNMP "Simple Network Management Protocol" est un protocole de communication qui permet aux administrateurs de superviser à distance les équipements du réseau.

14 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 protocoles 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 ordonnancement 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 uniquement 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 données des expériences ; étudier la reproductibilité ; construire des modèles de comparaison 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).

15 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 applications 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 proprié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 le NMWG "Network Measurement Working Group"[16] du GGF ainsi que la façon d obtenir les mesures correspondant à ces métriques ne sont pas toujours en accord avec les définitions publiées précédemment par le groupe de travail IPPM "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 et IPPM. 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 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 availability capacity achievable bandwidth delay variation connectivity link bandwidth capacity bulk transport capacity available bandwidth utilization pas d équivalent 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 disponible. 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 :

17 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 TCP 1 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 application 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 valeurs 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 unidirectionnel. 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 paquets 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 protocole IP) et la couche application.

18 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 chemin 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.

19 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 de PC, 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 maintenant le réseau comme une des ressources nécessaires à l application. Typiquement de tels efforts sont faits dans le cadre du projet EGEE [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 projet EGEE plusieurs interfaces entre l intergiciel g-lite [21] et les couches basses sont prévues, elles s appuient sur les outils PerfSONAR [22][23] et e2emonit [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 20 Métrologie et grilles besoins des utilisateurs. On peut faire à ce propos un parallèle avec les benchmarks utilisés pour la simulation numérique. Il existe des suites de codes qui permettent de mesurer les performances des machines pour des domaines d application donnés. Cela permet 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 applications 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 plateforme Grid5000 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érationnels 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 projet LHC "Large Hadron Collider"[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 SouthGrid qui est un projet interne à GridPP[35] ; TeraGrid[36] est un projet de grille de recherche à très hautes performances orientée calcul intensif (HPC) aux Etats-Unis.

21 4.1 Outils de surveillance pour les grilles 21 Notons que BalticGrid et NorduGRID sont basées un intergiciel spécifique ARC "Advanced Resource Connector"[37]. interopérable avec l intergiciel g-lite d EGEE. Outils de supervision e2emonit Ganglia GITS (Grid Integration Test Script) GVS (Grid Visualisation System) GridICE Gstat Monitoring Mat (nœuds) OCM-g (OMIS-Compliant Monitor for the Grid) perfsonar SAM monitoring system Network Weather Service Outils spécifiques d observation et de mesures réseau Projets Grille EGEE NGS ScotGrid PlanetLab SouthGrid NGS Naregi EUChinagrid LCG ScotGrid GridPP LCG SouthGrid ScotGrid BalticGrid EGEE LCG SouthGrid TeraGrid PlanetLab 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 projet EGEE ;

22 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 ; Gstat est un système centralisé de surveillance de grille utilisé notamment dans EGEE ; MATtool[42] outil de supervision plutôt destiné aux grappes de PC ; OCM-g[43] Grid enabled OMIS 1 Compliant 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 SAM qui est un projet du Fermi National Accelerator Laboratory FNAL aux Etats-Unis (du même type que LCG) ; 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 projet PlanetLab disposent 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 de Grid5000, 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 Glass cet outil permet un accès en temps réel aux informations concernant les les routeurs et les commutateurs du réseau à travers une interface WEB ; Netflow [13] est un logiciel d analyse des flux IP développé par CISCO. Sflow [47] est un standard industriel pour le contrôle du trafic sur les réseaux. Les outils de flux comme Netflow et Sflow donnent 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"

23 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 le multicast 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 paquets udp 2 point à point (cas des sondes) soit à travers des groupes multicast (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 SNMP permettent 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é». la Weather 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éseau RENATER. 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 de Grid5000 en précisant leur accessibilité. Outils réseau Argus Looking Glass MIBs SNMP Netflow Sflow Sondes Tickets Weather Map Utilisés par RENATER RENATER RENATER Grid5000 admin RENATER (sauf fibre noire) Grid5000 admin RENATER RENATER RENATER FIG. 4.2: Outils réseau dans Grid "User Datagram Protocol" protocole de télécommunication utilisé par Internet. Il fait partie de la couche transport de TCP/IP.

24 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 exemple RENATER) ; les réseaux de collecte qui relient les sites de la grille aux nœuds RENATER ; 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 de PC ("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.

25 Chapitre 5 Approches possibles sur la plate-forme Grid5000 D après les informations que nous avons obtenues des usagers des grilles : utilisateurs 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 solutions ne s excluent pas entre elles, nous verrons qu elles sont plutôt complémentaires. Pour chacune nous présentons les besoins couverts et les problèmes rencontrés. La discussion est faite dans le cadre du projet Grid5000 mais s applique bien sûr à toute plate-forme opérationnelle. 5.1 Présentation de la plate-forme Grid5000 La plate-forme Grid5000 comprend 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 par RENATER. 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 plateforme Grid5000 est 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œuds RENATER et même, comme nous l avons dit plus haut, le réseau d interconnexion des grappes de PC ("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 26 Approches possibles sur la plate-forme Grid5000 FIG. 5.1: Interconnexion Grid5000

27 5.2 Réutilisation des données SNMP 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 équipements 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-forme Grid5000 à 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 produisant à 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œuds RENATER auxquels 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ées 1 ; 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 : 1 la compatibilité doit être totale, dans notre cas, les deux versions V5 et V9 du logiciel Netflow posent des problèmes pour le collecteur.

28 28 Approches possibles sur la plate-forme Grid5000 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 de Grid5000 nous sortons du domaine RENATER. Avantages : même remarque que pour les outils "backbone", les flux donnent des informations 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 commutateurs 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 actives 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œud RENATER qui 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.

29 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œud RENATER, la gestion est facile car elle est effectuée directement par RENATER qui 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 probablement le moins de problèmes 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 configuration 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 par RENATER et les sites lui permettent l accès, soit c est l ensemble des sites (neuf dans le cas de Grid5000) 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 (échantillonnages,...) à partir de celle-ci.

30 30 Approches possibles sur la plate-forme Grid5000 Problèmes : l architecture dont nous parlons dans le cas de Grid5000 est une infrastructure en fibre noire avec un trafic maximal de 10 Gb/s. Dans cette solution 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 Grid5000 est 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 "middleware" 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 intégrer la possibilité d acquérir des données de supervision du réseau(cf. le cas de g-lite dans le cadre d EGEE [3]). Avantage : installer un intergiciel déjà pensé pour l exploitation d une grille opérationnelle permet de garder une certaine continuité dans la gestion de la grille sans se préoccuper des développements logiciels. Il faudra s occuper principalement des installations et des mises à jour de l intergiciel. Problèmes : l avantage devient inconvénient dans le cas de Grid5000 qui est une plateforme 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 utilisé 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 seulement 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.

31 5.8 Quelques points cruciaux 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 de Grid5000, 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, RENATER recueille 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. RENATER ne 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 informations 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 de Grid5000, nous avons accès aux données collectées sur les interfaces dédiées des commutateurs du réseau en fibres noires de RENATER. 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 utilisateurs,...) qui ne durent que quelques instants, et qui risquent de fausser les

32 32 Approches possibles sur la plate-forme Grid5000 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.

33 Chapitre 6 Expériences de trafic sur Grid5000 Un certain nombre d expériences ont été conduites afin de vérifier le comportement 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 paquets UDP ; 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 est iperf [51] ; Les données seront extraites des récepteurs iperf et des commutateurs de RENATER, en utilisant le protocole SNMP. 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 image Debian (ici debian4all) ; l installation du paquetage iperf sur les machines apt-get install iperf enfin l installation d une clé publique pour permettre un accès facile aux nœuds.

34 34 Expériences de trafic sur Grid5000 Le déroulement Toutes les actions présentées ci-dessous sont exécutées ou initiées par une machine qui coordonne le déroulement de l expérience : tous les nœuds du côté récepteur exécutent iperf en mode serveur : iperf -s -u -i 10 les PIDs des processus iperf des serveurs sont gardés ; chaque nœud du côté émetteur exécute iperf en mode client, en envoyant y bps pendant z secondes : iperf -c ipaddress -u -b y -t z après un temps d attente de z secondes, chaque nœud récepteur tue le processus qui exécute le serveur iperf ; le coordonnateur collecte les données de chaque serveur iperf. ; 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œuds RENATER sont 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 de Grid5000. FIG. 6.1: Résumé des expériences

35 6.1 Description de l expérimentation 35 La partie gauche (Configuration Expérience) précise les données expérimentales choisies. Notons que les champs «Mbits par nœud» resp. «Gbits par nœud» correspondent à des volumes 1. Dans la partie droite «Résultats», nous donnons la valeur maximale relevée sur le backbone RENATER (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 selon iperf. La case «Graph iperf» caractérise le comportement dynamique : type A le 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 ; type B le 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 ; type C le 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: Mesures iperf courbe de type A (Nancy) 1 sans passer par les transformations données par la base binaire, ainsi 1Mbit = bits et non pas 1024*1024bits, etc...

36 36 Expériences de trafic sur Grid5000 FIG. 6.3: Mesures iperf courbe de type B (Sophia) FIG. 6.4: Mesures iperf courbe 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 commutateurs 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/s sur la fibre noire à savoir : Nancy, Rennes, Sophia