Mise en évidence, analyse et monitoring de problèmes de performances sur un système d'acquisition de données

M2 Management et Technologies de l Information Mise en évidence, analyse et monitoring de problèmes de performances sur un système d'acquisition de données Stage de fin d'études M2 TM CERN-THESIS-2010-104 06/09/2010 Tuteur entreprise : M. NEUFELD Niko Tuteur enseignant : M. BRAESCH Christian Réalisé par : PANEL Thierry Année universitaire 2009-2010 1

Sommaire Sommaire... 2 Table des figures et des illustrations... 4 Remerciements... 5 Présentation du CERN et de l'expérience LHCb... 6 1 Description et analyse du premier problème rencontré... 9 1.1 Description de l'environnement... 9 1.2 Description du premier problème rencontré par le LHCb... 10 1.3 Analyse du problème... 11 1.3.1 État de l'art... 11 1.3.2 Diagnostic du problème rencontré... 12 2 Description et analyse du second problème rencontré... 14 2.1 Description de l'environnement... 14 2.2 Description du second problème rencontré par le LHCb... 14 2.3 Analyse du problème... 15 2.3.1 État de l'art... 15 2.3.2 Diagnostic du problème rencontré... 15 3 Projet 1 : Réalisation d'un banc d'essai pour le réseau haut débit de l'expérience LHCb... 18 3.1 Objectifs... 18 3.2 Moyens... 18 3.3 Travaux réalisés... 20 3.3.1 Réalisation du banc de test... 20 3.3.1.1 Étude de l'existant... 20 3.3.1.2 Câblage du Force10 et "Snake test"... 20 3.3.1.3 Configuration du Force10 et câblage similaires au système en production... 22 3.3.1.4 Reproduction du problème de pertes de paquets et résolution du problème... 23 3.3.2 Outils de monitoring pour le banc de test... 23 3.3.2.1 Création d'un contrôleur de trafic/compteur de paquets... 23 3.3.2.2 Mise en place d'un outil de surveillance : Snort... 24 4 Projet 2 : Réalisation d'un tableau de bord / application de monitoring pour le système de stockage. 27 4.1 Objectifs... 27 4.2 Moyens... 27 4.3 Travaux réalisés... 27 4.3.1 Étude de l'existant... 27 4.3.1.1 Définition des données importantes à intégrer... 29 2

4.3.1.2 Récolte des données... 29 4.3.2 Développement de l'application... 30 4.3.2.1 Développement d'une application avec Flex... 30 4.3.2.2 Développement de l'application autour de collectd... 30 4.3.2.2.1 Le logiciel libre collectd... 30 4.3.2.2.2 La création de plugins pour collectd... 31 4.3.2.2.3 L'interface graphique Jarmon... 32 4.3.2.2.4 Ajout du suivi de l'état des backups... 33 5 Réflexion critique du travail réalisé & Conclusion... 35 5.1 Réflexion critique du travail réalisé... 35 5.2 Conclusion... 35 6 Annexes... 40 6.1 Annexe 1 Système d'acquisition des données dans LHCb... 40 6.2 Annexe 2 Capacités des routeurs Force10 E1200 et E600i... 41 6.3 Annexe 3 Gantt projet 1... 42 6.4 Annexe 4 - Gantt projet 2... 44 6.5 Annexe 5 - Câblage du Snake test... 45 6.6 Annexe 6 - Configuration du Force10 pour le Snake test... 46 6.7 Annexe 7 - Résultats de tests iperf... 50 6.8 Annexe 8 - Configuration du commutateur HP pour le test principal... 52 6.9 Annexe 9 - Configuration du Force10 pour le test principal... 54 6.10 Annexe 10 - Photos du banc d'essai en configuration finale... 61 6.11 Annexe 11 - Résultats des tests de pertes de paquets avant et après le temps inter-trame passé à 32 octets... 62 6.12 Annexe 12 - Outil de monitoring : compteur de paquets... 64 6.13 Annexe 13 - Fichier de règles pour Snort et capture de boucle réseau avec wireshark... 67 6.14 Annexe 14 - Fichier de configuration de collectd... 69 6.15 Annexe 15 - Plugin "cpu-avg.sh" permettant de récupérer la moyenne du pourcentage d'utilisation de l'ensemble des processeurs d'un serveur... 77 6.16 Annexe 16 - Plugin "df-used.sh" permettant de récupérer le pourcentage d'utilisation de différentes partitions... 78 6.17 Annexe 17 - Architecture des graphiques : jarmon_recipes.js (extrait)... 79 6.18 Annexe 18 - Agencement des éléments : index.html... 82 6.19 Annexe 19 - Script de vérification des "Hourly backups" : checkhourlybackups.py... 88 3

Table des figures et des illustrations Figure 1 : Vue aérienne du site principal du CERN... 6 Figure 2 : Répartition des expériences autour du LHC... 7 Figure 3 : Détecteur de l'expérience LHCb... 7 Figure 4 : Schéma simplifié du flux de données dans LHCb... 10 Figure 5 : Force10 E600i... 18 Figure 6 : Linecard 90 ports connectique MRJ-21... 18 Figure 7 : Cartes TELL1... 19 Figure 8 : Serveur DELL PowerEdge SC1425... 19 Figure 9 : Commutateur HP ProCurve 5412zl... 19 Figure 10 : Câble MRJ-21... 19 Figure 11 : Câble RJ-45... 19 Figure 12 : Panneau de brassage... 20 Figure 13 : IXIA 400T Générateur de trafic/analyseur de performance... 21 Figure 14 : Configuration finale du banc d'essai... 22 Figure 15 : Exemple de résultats affichés par le compteur... 24 Figure 16 : Résultats de tests de sécurité effectué avec Hping et Nmap... 25 Figure 17 : Présentation des données sur Munin... 28 Figure 18 : Exemple de graphique généré avec RRDTool... 30 Figure 19 : Application développée sous Flex (1)... 30 Figure 20 : Application développée sous Flex (2)... 30 Figure 21 : Interface graphique Jarmon... 33 4

Remerciements Pour commencer ce rapport, je souhaite tout d'abord remercier le CERN et son administration pour m'avoir permis d'effectuer mon stage au sein de leur structure. Mes remerciements vont tout particulièrement vers NEUFELD Niko, mon tuteur entreprise, sans qui ce stage n'aurait pas pu avoir lieu, et qui m'a permis de participer à un moment important de la vie du CERN. Je tiens à remercier LIU Guoming qui m'a énormément aidé et appris lors de la partie réseau de mon projet. Je remercie aussi CAICEDO CARVAJAL Juan Manuel, qui m'a permis de mener à bien la seconde partie de mon projet grâce à ces conseils avisés. Enfin, je voulais dire un grand merci à BONACCORSI Enrico, GARNIER Jean-Christophe et BRARDA Loïc qui ont facilité mon insertion au sein de l'équipe et qui m'ont permis de réaliser mon stage dans de bonnes conditions. 5

Présentation du CERN et de l'expérience LHCb Le CERN (Organisation Européenne pour la Recherche Nucléaire) a été fondé en 1954, par douze États européens. Elle compte aujourd'hui vingt États membres dont, notamment, la France et la Suisse. Cette organisation constitue l'un des plus grands et importants laboratoires de recherches en physique des particules, dans le monde. Les missions du CERN sont clairement définies par la convention qui a instituée l'organisation en 1954. En effet, il a pour buts de rassembler les États européens autour de la recherche nucléaire, exclusivement scientifique et fondamentale. Pour effectuer ses recherches, le CERN dispose d'instruments scientifiques extrêmement pointus, qui permettent d'étudier les particules fondamentales constituant la matière. Les instruments utilisés par le CERN pour ses recherches sont des accélérateurs de particules ainsi que des détecteurs. Des faisceaux de particules sont portés, par les accélérateurs, à des énergies élevées afin de créer des collisions avec d'autres faisceaux ou des cibles fixes. Les résultats de ces collisions sont examinés à l'aide des enregistrements des détecteurs. Le CERN se situe à la frontière franco-suisse près de Genève. Figure 1 : Vue aérienne du site principal du CERN Le plus puissant et dernier accélérateur du CERN a avoir été mis en place est le LHC (Grand Collisionneur de Hadrons). Ce dernier a remplacé le LEP (Grand Collisionneur Électrons-Positrons) et a été mis en service pour la première fois, le 10 septembre 2008. Le LHC a été construit dans un tunnel de 27 kilomètres de circonférence, à 100 mètres sous terre. Quatre expériences majeures s'articulent autour du LHC afin d'y étudier les collisions qui s'y produisent grâce à des détecteurs. Ces expériences sont connues sous les noms de ALICE, ATLAS, CMS et LHCb. Chacune des expériences explore un ou plusieurs domaines de la physique. 6

Figure 2 : Répartition des expériences autour du LHC Nous vivons dans un univers qui semble essentiellement constitué de matière, sans présence d'antimatière. L'expérience LHCb (Grand Collisionneur de Hadrons beauté) cherche à déterminer les disparités entre la matière et l'antimatière, en analysant un certain type de particules. Ce type de particules est appelé "quark beauté" ou encore "quark b". Le LHC reproduit les moments suivant le Big Bang, durant lesquels les paires de quarks b et d'antiquarks b sont censées avoir été produites. Le détecteur de l'expérience LHCb, traque les quarks b à l'aide de trajectographes mobiles, avoisinant la trajectoire des faisceaux. Figure 3 : Détecteur de l'expérience LHCb 7

1 Description et analyse du premier problème rencontré 8

1 Description et analyse du premier problème rencontré 1.1 Description de l'environnement Comme nous avons pu le voir dans la présentation de l'expérience LHCb, le détecteur utilisé va permettre d'étudier la création, la désintégration et la trajectoire de quarks b et d'antiquarks b. Lorsque l'expérience est en état de fonctionnement, le détecteur va enregistrer environ 10 millions de collisions de protons par seconde. Enregistrer l'ensemble de ces "évènements" est pratiquement impossible en raison de capacités de stockage qui sont limitées. De ce fait, pour trier sur le volet les meilleurs de ces "évènements", le LHCb utilise un système électronique appelé "trigger" (déclencheur en français). Le système de déclenchement du LHCb fonctionne sur deux niveaux. Le premier niveau utilise les informations récupérées du détecteur en temps réel - en particulier les informations du sous-détecteur VELO, du calorimètre et du système à muons. Le système de déclenchement sélectionne environ 1 million d'évènements par secondes pour un traitement ultérieur, tout en écartant les informations des 9 millions d'évènements restants. Le premier niveau de déclenchement travail incroyablement vite, en prenant ses décisions en seulement quatre millionièmes de seconde. Le premier filtrage terminé, les données sont envoyées sur le réseau DAQ (réseau d'acquisition de données). C'est un switch Force 10 qui va distribuer les données au travers de ses 1280 ports Gigabit Ethernet, établissant la connexion entre le premier et le second niveau de déclenchement. Le trafic total commuté dans ce réseau est d'environ 35 Giga-octets/seconde. Après le filtrage du premier niveau de déclenchement, une très grande quantité de données demeure. Ce sont 35 Giga-octets - l'équivalent de 8 DVDs contenant d' importantes informations - qui vont alimenter des fermes de serveurs (environ 550 serveurs à 8 cœurs), situées sous terre sur le site du LHCb. Ces équipements vont sélectionner les évènements intéressants à conserver pour analyse. Cela revient à couper le million d'évènements par secondes en un échantillon de 2000 évènements plus gérable. Ce second niveau de déclenchement dispose de plus de temps, que son homologue du premier niveau, pour conserver les évènements intéressants. Par la suite, ces 2000 évènements sont envoyés dans un cluster de stockage. Ce sont des serveurs appelés "Writers" qui vont écrire à des débits élevés, ces évènements dans un système de fichiers partagés. Pour finir le cycle, les fichiers écrits par les "Writers" sont également écrits sur bande pour un stockage à long terme, au centre de stockage sur bande du CERN. Voici un schéma simplifié des précédentes explications, pour le schéma complet voir Annexe 1 : 9

Figure 4 : Schéma simplifié du flux de données dans LHCb La description de l'environnement et ce schéma vont me permettre de décrire, de manière compréhensible, le problème rencontré par le LHCb. 1.2 Description du premier problème rencontré par le LHCb Nous avons pu le constater dans la partie précédente, le système d'acquisition de données est basé sur un réseau à haut-débit. Effectivement, étant donné la quantité impressionnante de données qui transite dans ce réseau, il est nécessaire d'avoir une architecture qui soit capable de suivre le rythme imposé par les collisions au sein du LHC. Afin de transférer cette importante quantité de données à vitesse élevée et dans un environnement particulier (radiations dues aux collisions), tous les équipements doivent être adaptés, de qualité et bien entendu, fiables. C'est là que surgit le problème rencontré par le LHCb. 10

En effet, même si ils sont minimes, le réseau de l'expérience rencontre des problèmes de performances. Ces problèmes de performances se manifestent sous forme de pertes de paquets. Ces dernières surgissent très rarement, mais elles sont gênantes. Imaginons que le paquet perdu contienne l'information qui pourrait permettre aux scientifiques, qui étudient les résultats des collisions, de faire une découverte importante. Sans ce paquet, il n'est pas possible de reconstruire fidèlement le phénomène qui s'est produit lors d'une collision. L'on comprend vite que, même infimes, ces pertes de données ne sont pas tolérables sur le long terme. La reconstitution des évènements, recueillis par le détecteur, est fondamentale pour comprendre ce qui s'est réellement produit. 1.3 Analyse du problème 1.3.1 État de l'art Dans le monde des réseaux informatiques, les problèmes de performances sont reconnus comme étant les plus difficiles à résoudre, tant les sources probables de ces problèmes sont multiples. La qualité d'un réseau se définit selon trois paramètres essentiels : Le taux de pertes de paquets Le délai La gigue (variation de délai) En ce qui nous concerne, c'est le taux de pertes de paquets qui nous intéresse. Effectivement, des pertes de paquets ont été détectées au sein du réseau d'acquisition de données de l'expérience LHCb. Bien qu'étant simple à mettre en évidence, diagnostiquer la cause exacte et identifier la ou les sources de pertes de paquets restent un exercice compliqué. Il faut également noter qu'il est quasiment impossible d'éradiquer totalement les pertes de paquets. La RFC 2680 "Taux de pertes unidirectionnel de paquets" est la base des travaux sur le taux de perte de paquets et les causes probables de ce dernier. Elle définit le taux de perte de paquets de la manière suivante : "Soit T un intervalle de temps T = [t 1, t 2 ] et S = {P 1,..., P n } la séquence des paquets émis pendant l'intervalle T. Un paquet est considéré comme correctement reçu, s'il arrive sans erreurs et après un délai de transit maximum OWD max défini. Le taux de perte unidirectionnel de paquets, mesuré sur l'intervalle T, est défini comme le rapport entre le nombre de paquets correctement reçus." Des géants dans le domaine de l'informatique tels que Cisco ou encore Microsoft, distinguent quatre facteurs courants, provocants des pertes de paquets : Congestion du réseau local : intervient lorsque le trafic est plus important que la charge pouvant être supportée par les équipements réseau (switchs, routeurs...). Les équipements réseau sont alors surchargés. Interférences sur le réseau sans fil : apparaît lorsqu'il y a trop d'équipements connectés au réseau sans fil. Ce problème peut également se produire si des équipements émettant des ondes (four à micro ondes, téléphones portables,...) se trouvent à proximité. Défaillance logicielle du matériel réseau : ce problème se présente lorsqu'un équipement réseau est mal configuré. 11

Défaillance des connexions réseau : cette défaillance survient quand un câble est détérioré ou déficient. Ces éléments en main, il m'est possible de fournir un diagnostic. 1.3.2 Diagnostic du problème rencontré Comme nous avons pu le voir sur la figure 4, le réseau de l'expérience LHCb est un réseau local filaire. De ce fait, nous pouvons d'office écarter le problème d'interférences sur les réseaux sans fil. Ainsi, il nous reste trois possibilités. Voyons laquelle ou lesquelles sont les plus probables : Congestion réseau : étant donné la quantité importante de données qui transite au sein du réseau (35 Giga-octets/seconde), la congestion réseau a de fortes chances d'être à l'origine des pertes de paquets. Défaillance logicielle du matériel réseau : ce problème a également une forte probabilité d'être à l'origine de la perte de paquets. En effet, il suffit parfois d'un seul paramètre mal configuré sur un équipement pour que le réseau entier, devienne instable. Cependant, pour s'en assurer, il faudra étudier la configuration de chaque équipement réseau où se produisent les pertes de paquets. Défaillance des connexions réseau : ce problème a une très infime probabilité d'être à l'origine des pertes de paquets. Effectivement, les câbles de l'expérience ont été testés par les fournisseurs et avant leur installation. De plus, lorsqu'un câble est mis en cause dans des pertes de paquets il est assez facile de l'identifier grâce aux équipements qu'ils relient (s'ils le permettent). Enfin, lorsqu'un câble est défectueux, les pertes de paquets sont beaucoup plus importantes que celles observées dans l'expérience. D'après le diagnostic émis, je devrai donc me concentrer sur la configuration du matériel et le débit des données. Nous verrons, dans le chapitre 3, les travaux réalisés, relatifs à cette partie. 12

2 Description et analyse du second problème rencontré 13

2 Description et analyse du second problème rencontré 2.1 Description de l'environnement Lorsque l'on possède énormément de matériel informatique et d'applications critiques, il est primordial d'en connaître l'état général. Prenons l'exemple d'un système de sauvegarde centralisé dans une multinationale. Si celui-ci venait à tomber en panne, sans penser au fait qu'un multinationale avertie aurait bien entendu mis en place de la redondance, quels seraient les impacts de cette panne si elle n'était pas détectée dans la minute qui suit? Nous n'allons pas entrer dans les détails mais, les conséquences seraient plus que dramatiques. Elles le seraient encore plus si la redondance n'avait pas été mise en place. Dans ce cas là, on peut légitimement penser que l'entreprise disparaîtrait dans les mois à venir. L'on comprend aisément que l'aspect "monitoring" (surveillance) de l'environnement informatique, dans une quelconque entreprise ou organisation, est plus qu'indispensable. De ce fait, le CERN et l'expérience LHCb ne dérogent pas à la règle. En effet, l'expérience du LHCb met en œuvre du matériel informatique et des applications critiques. Ceux-ci servent notamment à enregistrer les données du détecteur, suivre l'activité de ce dernier et du LHC ou encore, vérifier l'état des backups. Plusieurs outils de monitoring sont utilisés pour vérifier l'état de ces éléments critiques. C'est évidemment le cas du système de stockage de l'expérience. Au vu de l'importance qu'ont les données récupérées par le détecteur, l'on se doute bien que le LHCb ne peut pas se permettre de ne pas faire de monitoring de son système de stockage. Comme nous l'avons vu avec l'exemple de la multinationale, cela aurait des conséquences désastreuses. Effectivement, si des données non encore analysées venaient à disparaître, les chercheurs pourraient passer à côté d'une découverte sans précédent. Cependant, même si des outils de monitoring sont bien présents, cela ne veut pas dire qu'en avoir un nombre important est un bonne chose. C'est ce que nous allons voir dans la partie qui suit. 2.2 Description du second problème rencontré par le LHCb Dans la partie précédente, nous avons mis en évidence qu'il était important pour le LHCb de posséder des outils qui lui permettent de suivre l'état des équipements et applications impliqués dans l'expérience. Le LHCb possède effectivement les informations nécessaires pour effectuer le monitoring cependant, les sources sont multiples et sont disséminées un peu partout. De ce fait, il est difficile d'avoir une vue d'ensemble des principaux éléments dont on veut effectuer le suivi. C'est également le cas du système de stockage de l'expérience. Ainsi, le problème qui se pose pour l'expérience du LHCb, est que le monitoring du système de stockage doit être effectué en utilisant plusieurs outils. Il n'existe pas d'outil qui présente l'état du système de stockage dans sa globalité. Le problème étant identifié, nous allons pouvoir l'analyser pour évaluer la situation. 14

2.3 Analyse du problème 2.3.1 État de l'art De nos jours, l'information est devenue incontournable au bon fonctionnement de tout organisme quelque soit sa taille, son activité ou sa localisation. Elle se déplace partout et à des vitesses de plus en plus élevées. Les frontières sont repoussées pour que l'information soit accessible instantanément et de n'importe où, car c'est elle qui permet de prendre la décision la plus adéquate en fonction de la situation. Si l'information n'est pas disponible, il est difficile de prendre des décisions et nous savons que cela peut avoir des conséquences indésirables. C'est pourquoi il est indispensable d'assurer la supervision des points névralgiques d'un réseau. Cela permet de connaître les performances de son infrastructure en temps réel et de pouvoir réagir rapidement. Ainsi, l'on rassemble deux domaines, celui de la sécurité informatique et celui de la gestion. En effet, la sécurité informatique vise à protéger les données et la gestion vise à suivre l'évolution de l'environnement et de ses données. De ce constat, l'on comprend l'intérêt de la supervision et des tableaux de bord de performance. Il est même difficile de dissocier supervision et tableaux de bord de performance. Les adages, "L'on ne peut pas gérer ce que l'on ne mesure pas." et "Ce qui est surveillé est fait.", permettent de comprendre la puissance des tableaux de bord de performance. Actuellement, les constructeurs mettent en œuvre des solutions dans leurs équipements réseau qui permettent de surveiller leur état, de comprendre les incidents qui surviennent et d'être parfois proactif. Il existe des solutions payantes et des solutions libres qui donnent la possibilité d'exploiter les informations recueillies sur les équipements. Voyons alors plus en détails, de quoi relève le problème du LHCb. 2.3.2 Diagnostic du problème rencontré Nous savons que le LHCb dispose des informations nécessaires pour effectuer le suivi de son système de stockage. Cependant, nous savons aussi que les sources sont multiples et éparpillées au sein du système. De plus, ces sources d'informations sont parfois très exhaustives. J'ai identifié trois raisons principales qui pourraient rendre le monitoring du système de stockage relativement difficile si : Plusieurs outils doivent être utilisés pour effectuer le suivi. Le fait d'utiliser plusieurs outils oblige une multiplication des affichages et une hétérogénéité dans la présentation. Dans ce cas, les utilisateurs ne savent pas toujours où rechercher l'information désirée. Les informations fournies ne sont pas pertinentes. Une information qui n'est pas pertinente ne doit pas apparaître, car elle peut parfois porter à confusion. Le nombre d'informations utilisé dans le tableau de bord est trop important. Trop d'informations diminue la lisibilité d'un tableau de bord. Lors de la création d'un tableau de bord, il est conseillé de ne pas afficher plus de sept informations sur une même vue car, l'homme n'est pas capable de traiter plus de sept informations à la fois. 15

Au vu des éléments qui m'ont été donnés, les sources d'informations sont multiples et le logiciel principalement utilisé, pour effectuer le monitoring du système de stockage, présentent trop d'informations à la fois. De plus, certaines informations affichées ne sont pas pertinentes pour le LHCb. Ainsi, j'ai dû travailler sur ces trois éléments dans la seconde partie du projet. Nous verrons cela dans le chapitre 4. 16

3 Projet 1 : Réalisation d'un banc d'essai pour le réseau haut débit de l'expérience LHCb 17

3 Projet 1 : Réalisation d'un banc d'essai pour le réseau haut débit de l'expérience LHCb 3.1 Objectifs Les objectifs de ce premier projet consistent principalement, à réaliser un banc d'essai pour le réseau haut débit de l'expérience LHCb. Ce réseau sera une reproduction à petite échelle du système d'acquisition de données de l'expérience. Il nous permettra d'effectuer toute une panoplie des tests, pour essayer de reproduire les problèmes de performances rencontrés sur le système en production. Ces tests devront nous permettre de comprendre précisément, d'où provient le problème. Ainsi, en connaissant l'origine du problème provocant les pertes de paquets, nous serons en mesure de proposer une solution pour limiter au maximum celles-ci. Enfin, je devrai également mettre en place des éléments de monitoring pour surveiller le trafic, ainsi que les tentatives d'intrusion ou évènements suspects sur le réseau. Nous allons maintenant voir de quels moyens nous avons disposé pour réaliser ces tâches. 3.2 Moyens Un réseau haut débit est constitué d'éléments actifs et de câbles pour connecter les différents équipements. Pour réaliser le banc d'essai j'ai disposé d'un routeur haut de gamme, de "patterngenerators", d'un commutateur intelligent, de serveurs, de deux types câbles et de panneaux de brassage. Le routeur utilisé est un routeur Force10 E600i avec des linecards à connectique MRJ-21. Ce routeur est plus petit que celui utilisé en production (modèle Force10 E1200), avec des capacités un peu moins importantes mais, il était plus que suffisant pour effectuer les tests prévus. Figure 5 : Force10 E600i Figure 6 : Linecard 90 ports connectique MRJ-21 Pour illustrer les capacités de ce type de routeur, le routeur Force10 E1200 en production est capable à lui tout seul, de connecter simultanément l'ensemble des français au réseau téléphonique. Pour un détail des capacités de ces deux types de routeur, voir l'annexe 2. 18

Les "pattern-generators" sont des cartes TELL1 qui vont générer aléatoirement, des évènements semblables aux évènements détectés par le détecteur du LHCb. Figure 7 : Cartes TELL1 Les serveurs utilisés sont deux DELL PowerEdge SC1425. Ils nous ont servi à récupérer les données envoyées par les cartes TELL1. Le commutateur que nous avons utilisé est un HP ProCurve 5412zl. Figure 8 : Serveur DELL PowerEdge SC1425 Figure 9 : Commutateur HP ProCurve 5412zl En ce qui concerne les câbles, nous avons utilisés des câbles RJ-45 (aussi appelés câbles Ethernet) de catégorie 6 et des câbles MRJ-21 de catégorie 5e, supportant des débits allant jusqu'à 1 Gbit/s. Figure 10 : Câble MRJ-21 Figure 11 : Câble RJ-45 19

Les câbles MRJ-21 sont des câbles propriétaires de la société Tyco Electronics, qui permettent de regrouper 6 connexions RJ-45 dans un seul câble, grâce à leur connecteur haute densité. Les panneaux de brassage sont des équipements créés par la société Tyco Electronics qui permettent de relier les câbles MRJ-21 aux câbles RJ-45. Enfin, pour ce qui est de l'outil de monitoring, nous avons utilisé des logiciels libres existants ou développé les éléments nécessaires nous-mêmes. Nous allons maintenant voir en détail ce qui a été réalisé. 3.3 Travaux réalisés Dans la réalisation de ce projet, mon travail a été supervisé par l'ingénieur réseau, LIU Guoming. Pour la planification du projet 1, voir le Gantt correspondant à l'annexe 3. 3.3.1 Réalisation du banc de test Nous allons maintenant voir, comment a été réalisé le banc de test. 3.3.1.1 Étude de l'existant Au commencement du projet, j'ai tout d'abord pris connaissance et lu les documents disponibles sur les différents éléments qui composent le système de stockage. Par la suite, j'ai visité les lieux de l'installation technique, tout en examinant le chemin parcouru par les données dans le système d'acquisition en production. Cela m'a permis de comprendre comment fonctionne le système d'acquisition de données et de savoir de quoi sont responsables, les différents équipements le composant. J'avais alors une idée plus concrète de ce que je devais produire, dans cette première partie de projet, pour découvrir d'où proviennent les pertes de paquets. Ces données clés en tête, je pouvais alors me concentrer sur la prochaine étape, qui était la mise en place du câblage, la configuration du Force10 et la vérification des connexions. 3.3.1.2 Câblage du Force10 et "Snake test" Figure 12 : Panneau de brassage Lorsque l'on fait un câblage, il faut penser au chemin de câbles que l'on va créer. En effet, il faut savoir si l'on fait un câblage supérieur ou un câblage passant par le faux plancher. Il faut prendre en considération les éventuels futurs câblages et par conséquent, l'espace nécessaire. Le câblage doit également être propre, de manière à identifier facilement les câbles si une intervention doit être faite. Cela implique d'étiqueter tous les câbles qui participent à l'interconnexion. 20

Ayant pris tous ces paramètres en considération, j'ai pensé qu'il était plus judicieux de faire un câblage passant sous le faux plancher, afin de faire une installation la plus propre possible. J'ai donc commencer par faire l'étiquetage de tous les câbles et des équipements impliqués. Pour effectuer ce travail, un stagiaire était à ma charge. Il devait m'aider à faire le câblage et l'étiquetage des câbles. De mon côté, je lui expliquais ce que nous devions faire et à quoi servaient les différents équipements que nous utilisions. Durant cette étape, nous avons relié le Force10 au panneau de brassage avec les câbles MRJ-21. Nous avons installé deux serveur DELL PowerEdge SC1425 qui nous ont servi à tester l'installation (voir Annexe 5). Le Force10 a été configuré pour effectuer le "Snake test" (voir Annexe 6). Ensuite, nous avons câblé le panneau de brassage de telle sorte que le premier et le dernier ports soient chacun, reliés à l'un des deux serveurs. Les autres ports ont été reliés entre eux pour créer un circuit fermé. Le premier serveur servira à envoyer des données dans le circuit et le second à les recevoir. Nous pourrons alors savoir si l'installation et la configuration fonctionne correctement. Après avoir reconfiguré plusieurs fois le Force10, j'ai finalement réussi à faire le test et à voir le trafic entre les deux serveurs. Pour voir le trafic, j'ai utilisé un logiciel se nommant Wireshark. Ce logiciel est un analyseur de protocole qui permet, entre autres, de faire de la capture de paquets sur un réseau. Cela étant fait, Guoming et moi-même, avons procédé à des tests de performance, après avoir configuré le Force10 avec des paramètres similaires au Force10 qui est en production. Pour effectuer les tests de performance, nous avons utilisé un logiciel s'appelant iperf. Ce logiciel permet de tester les débits d'un réseau, notamment en utilisant les protocoles TCP et UDP. Après plusieurs heures de tests, nous n'avons pas rencontré de pertes de paquets. Vous pouvez voir un exemple de résultats de tests effectués avec iperf en Annexe 7. Nous avons également effectué des tests de bande passante à l'aide d'un générateur et analyseur de trafic, un IXIA 400T. Figure 13 : IXIA 400T Générateur de trafic/analyseur de performance Les tests ont montré que la vitesse de transfert d'un flux continu de données au travers du Force10 était de 767 MBits/s. Ce résultat correspondait à ce que l'on attendait au vu de la configuration du Force10. Ayant eu la preuve que tout fonctionnait normalement nous avons pu passer à la phase suivante. 21