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

Transcription

1 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 /09/2010 Tuteur entreprise : M. NEUFELD Niko Tuteur enseignant : M. BRAESCH Christian Réalisé par : PANEL Thierry Année universitaire

2 Sommaire Sommaire... 2 Table des figures et des illustrations... 4 Remerciements... 5 Présentation du CERN et de l'expérience LHCb Description et analyse du premier problème rencontré Description de l'environnement Description du premier problème rencontré par le LHCb Analyse du problème État de l'art Diagnostic du problème rencontré Description et analyse du second problème rencontré Description de l'environnement Description du second problème rencontré par le LHCb Analyse du problème État de l'art Diagnostic du problème rencontré Projet 1 : Réalisation d'un banc d'essai pour le réseau haut débit de l'expérience LHCb Objectifs Moyens Travaux réalisés Réalisation du banc de test Étude de l'existant Câblage du Force10 et "Snake test" Configuration du Force10 et câblage similaires au système en production Reproduction du problème de pertes de paquets et résolution du problème Outils de monitoring pour le banc de test Création d'un contrôleur de trafic/compteur de paquets Mise en place d'un outil de surveillance : Snort Projet 2 : Réalisation d'un tableau de bord / application de monitoring pour le système de stockage Objectifs Moyens Travaux réalisés Étude de l'existant Définition des données importantes à intégrer

3 Récolte des données Développement de l'application Développement d'une application avec Flex Développement de l'application autour de collectd Le logiciel libre collectd La création de plugins pour collectd L'interface graphique Jarmon Ajout du suivi de l'état des backups Réflexion critique du travail réalisé & Conclusion Réflexion critique du travail réalisé Conclusion Annexes Annexe 1 Système d'acquisition des données dans LHCb Annexe 2 Capacités des routeurs Force10 E1200 et E600i Annexe 3 Gantt projet Annexe 4 - Gantt projet Annexe 5 - Câblage du Snake test Annexe 6 - Configuration du Force10 pour le Snake test Annexe 7 - Résultats de tests iperf Annexe 8 - Configuration du commutateur HP pour le test principal Annexe 9 - Configuration du Force10 pour le test principal Annexe 10 - Photos du banc d'essai en configuration finale Annexe 11 - Résultats des tests de pertes de paquets avant et après le temps inter-trame passé à 32 octets Annexe 12 - Outil de monitoring : compteur de paquets Annexe 13 - Fichier de règles pour Snort et capture de boucle réseau avec wireshark Annexe 14 - Fichier de configuration de collectd 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 Annexe 16 - Plugin "df-used.sh" permettant de récupérer le pourcentage d'utilisation de différentes partitions Annexe 17 - Architecture des graphiques : jarmon_recipes.js (extrait) Annexe 18 - Agencement des éléments : index.html Annexe 19 - Script de vérification des "Hourly backups" : checkhourlybackups.py

4 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 Figure 5 : Force10 E600i Figure 6 : Linecard 90 ports connectique MRJ Figure 7 : Cartes TELL Figure 8 : Serveur DELL PowerEdge SC Figure 9 : Commutateur HP ProCurve 5412zl Figure 10 : Câble MRJ Figure 11 : Câble RJ Figure 12 : Panneau de brassage Figure 13 : IXIA 400T Générateur de trafic/analyseur de performance Figure 14 : Configuration finale du banc d'essai Figure 15 : Exemple de résultats affichés par le compteur Figure 16 : Résultats de tests de sécurité effectué avec Hping et Nmap Figure 17 : Présentation des données sur Munin Figure 18 : Exemple de graphique généré avec RRDTool Figure 19 : Application développée sous Flex (1) Figure 20 : Application développée sous Flex (2) Figure 21 : Interface graphique Jarmon

5 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

6 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 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 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

7 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

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

9 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

10 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

11 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 É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

12 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 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

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

14 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

15 2.3 Analyse du problème É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 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

16 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

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

18 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

19 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

20 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 Réalisation du banc de test Nous allons maintenant voir, comment a été réalisé le banc de test É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 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

21 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

22 Configuration du Force10 et câblage similaires au système en production Pour mettre le banc de test dans une configuration similaire au système de production (à notre échelle bien sûr), nous avons rajouté une linecard au Force10 et connecté huit câbles supplémentaires. Ainsi, nous avions trois linecards, soit un total de 270 ports disponibles. Nous avons rajouté un panneau de brassage pour pouvoir connecté les nouveaux ports. Les cartes TELL1 ont été intégrées afin qu'elles génèrent des évènements aléatoires. Nous avons également connecté un commutateur intelligent HP ProCurve 5412zl pour récupérer les données. Les deux serveurs DELL nous servaient désormais de "sondes", pour vérifier que tout fonctionnait comme nous le souhaitions. Figure 14 : Configuration finale du banc d'essai Après avoir mis en place cette configuration, j'ai configuré le Force10 et le commutateur HP (voir Annexes 8 et 9). Les configurations appliquées étaient similaires à celles utilisées dans le système en production. Pour des photos de la configuration finale, référez vous à l'annexe 10. Nous allions maintenant pouvoir nous concentrer sur les tests, pour déterminer d'où provenait les pertes de paquets et comment résoudre ce problème. 22

23 Reproduction du problème de pertes de paquets et résolution du problème Pour cette partie importante du projet, des ingénieurs de chez Force10 sont venus nous aider à déterminer la provenance des pertes de paquets. Les tests, avec les ingénieurs de chez Force10, ont été menés sur le système de production. J'ai seulement assisté à ces tests, je n'ai pas fait de manipulations. Suite à ces tests, les sources des pertes de paquets ont été identifiées par Guoming. Des pertes de paquets ont été relevées sur le Force10 et sur les serveurs, qui reçoivent les données envoyées par le Force10. La perte de paquets sur le Force10 est très rare puisqu'un paquet est perdu tous les milliards de paquets de reçus. En revanche, sur les serveurs qui sont directement reliés au Force10, les pertes de paquets sont plus fréquentes. En ce qui concerne le Force10, le problème semblait être interne au Force10 et non un problème de configuration. Guoming a donc envoyé les résultats et données récoltées aux Etats-Unis. Pour ce qui est des serveurs, le problème venait du fait que le Force10 envoyait les données trop rapidement et les serveurs n'arrivaient pas toujours à suivre son rythme. Deux solutions s'offraient alors à nous : augmenter le temps inter-trame (correspond au temps minimum de repos accordé aux équipement pour se préparer à recevoir la prochaine trame de données) faire du rate shaping (correspond au contrôle du trafic réseau pour optimiser les performances en augmentant la bande passante en fonction des paquets rencontrés) La deuxième option est contraignante à mettre en œuvre car elle consomme des ressources. Nous avons donc décidé d'augmenter le temps inter-trame. Nous avons donc augmenté ce paramètre sur le Force10 du banc de test, en le passant de 12 octets à 20 octets. Cela a eu pour conséquence de réduire considérablement les pertes de paquets. En effet, nous avions utilisé l'ixia 400T pour envoyer des trames de 1518 bits. Cependant des pertes de paquets apparaissaient lorsque nous envoyions des trames "Jumbo ". Ces paquets correspondent à des paquets ayant la taille maximale définie par le MTU (taille maximale que peut avoir un paquet) des cartes TELL1. Le MTU des cartes TELL1 est de 9000 bits. Pour prendre en compte ces paquets "Jumbo" nous avons augmenté le temps inter-trame à 32 octets. Nous ne relevions alors plus de pertes de paquets lors de nos tests (voir Annexe 11). Nous avons réussi a résoudre le problème des pertes de paquets sur le commutateur mais nous n'avons pas réussi à recréer le problème de perte de paquet sur le Force10, comme c'est le cas sur le système en production. Nous pensons que cela est dû au fait que nous n'avons pas assez de cartes TELL1 pour générer autant d'évènements que sur le système en production. Cette partie étant terminée, je pouvais maintenant passer à la création d'outils de monitoring pour le banc de test Outils de monitoring pour le banc de test Création d'un contrôleur de trafic/compteur de paquets Pour les futurs tests, nous avions besoins d'un outil qui nous permettrait d'afficher les paquets transmis par le Force10 sans avoir à aller chercher ces données sur le Force10. J'ai donc créé un script pour notre banc de test en partant d'un script existant. Ce script allait nous afficher le trafic sur le Force10 (voir Annexe 12). 23

24 Le script a été écrit en Python et permet de connaître le nombre de paquets qui sont entrés et sortis du Force10. Il recense également le nombre de paquets perdus. Figure 15 : Exemple de résultats affichés par le compteur Le compteur créé, il fallait réaliser ou mettre en place un outil de surveillance du réseau pour le banc de test, que ce soit pour le trafic ou les éventuelles intrusions Mise en place d'un outil de surveillance : Snort En accord avec Guoming, nous avons décidé de mettre en place le logiciel open source, Snort. C'est un système de détection d'intrusion qui permet également d'analyser, en temps réel, le trafic sur un réseau. Pour fonctionner, Snort se base sur des règles qui lui permettent de détecter les intrusions souhaitées ou de surveiller le trafic désiré. Des règles de base sont fournies avec le logiciel mais, j'ai dû créer des règles supplémentaires dont nous avions besoin. Afin d'avoir un affichage des résultats qui soit agréable, j'ai également ajouté une interface graphique se nommant BASE. Je l'ai couplé avec une base de données nommée ADODB. Ainsi, nous avions un logiciel tournant en tâche de fond avec un affichage des résultats enregistrés dans la base de données. Cela étant fait, j'ai modifié le fichier de configuration pour qu'il prenne en compte mon fichier de règles. Mon fichier de règles sert à détecter les trafic IP, ICMP, UDP et TCP. J'ai utilisé le fichier de règles de base pour détecter les attaques courantes comme le déni de service, les scans de ports, les dépassement de buffers. Pour tester si l'ensemble fonctionnait bien, j'ai utilisé des outils permettant de faire des attaques réseau courantes comme un déni de service ou un scan de ports. J'ai notamment utilisé hping et Nmap pour faire ces attaques. J'ai eu quelques problèmes pour faire fonctionner BASE mais après avoir changer la configuration de Snort l'interface graphique fonctionnait correctement. J'ai donc pu effectuer les tests et afficher des résultats avec BASE (voir Figure 16). Nous avons alors décidé avec Guoming de créer une règle pour repérer les boucles réseau. Lorsqu'une boucle se déclenche sur un réseau, il est certains que le réseau sera paralysé ou instable tant que la boucle ne sera pas supprimée, car elle crée un déni de service. Une boucle survient lorsqu'il y a une redondance qui est créé sur un équipement réseau. Dans ce cas, si une requête est faite sur le réseau elle tourne indéfiniment et se multiplie. Ces requêtes sont généralement des requêtes du protocole ARP. J'ai donc cherché à créer une règle qui permettent d'identifier ce type de trafic sur le réseau. Je n'ai pas réussi à identifier ce type de trafic bien que j'ai réussi à le faire pour les protocoles IP, ICMP, TCP et UDP. Après, des recherches approfondie j'ai trouvé que Snort ne gérait pas le protocole ARP. De ce 24

25 fait, il m'était impossible de voir le trafic ARP avec BASE lorsque je créais des boucles alors que je les voyais avec Wireshark (voir Annexe 13). Figure 16 : Résultats de tests de sécurité effectué avec Hping et Nmap Ne pouvant pas créer cette règle et ne trouvant de moyen alternatif pour détecter les boucles réseau avec Snort, nous nous sommes arrêtés là. Nous avions un banc de test qui fonctionnait comme nous le voulions, avec des métriques qui permettaient de surveiller le trafic et les attaques courantes. Nous allons maintenant nous intéresser au second projet que j'ai mené au cours de mon stage. 25

26 4 Projet 2 : Réalisation d'un tableau de bord / outil de monitoring pour le système de stockage 26

27 4 Projet 2 : Réalisation d'un tableau de bord / application de monitoring pour le système de stockage 4.1 Objectifs Ce second projet a pur but, l'élaboration d'un tableau de bord / application de monitoring pour le système distribué de stockage de l'expérience LHCb. Cette application devra afficher des indicateurs pour les différents composants du système de stockage. Ainsi, il devrait permettre de connaître l'état et l'espace des disques, l'état du système de fichiers, la charge réseau sur les serveurs, etc. Ces informations sont déjà disponibles mais, elles sont éparpillées dans plusieurs sources. L'idée est donc de les regrouper dans une interface unifiée, afin de surveiller le système de stockage dans sa globalité. Cela permettra de diagnostiquer les éventuels problèmes de manière centralisée. 4.2 Moyens Pour réaliser ce travail, les outils que j'avais à disposition étaient : un ordinateur des machines virtuelles Internet les sources de données à intégrer les langages de programmation existants Les sources de données m'ont permis de me faire une idée de ce qu'il fallait intégrer dans l'application. Internet m'a beaucoup servi pour faire des recherches sur les problèmes rencontrés. J'ai utilisé différents langages dans ce projet car, certains langages sont plus adaptés à certaines situations. Les machines virtuelles m'ont permis de faire mes tests dans un environnement n'affectant pas le système en production. Nous allons maintenant voir les différentes étapes et travaux réalisés pour concevoir cette application de monitoring. 4.3 Travaux réalisés Au cours de ce projet, l'ensemble de mes travaux a été supervisé par CAICEDO CARVAJAL Juan Manuel. Pour la planification du projet 2, voir le Gantt correspondant en Annexe Étude de l'existant Pour commencer le projet sur de bonnes bases j'ai commencé par étudier les sources de données. Les informations sont principalement concentrées dans une source, Munin. Munin est un logiciel open source permettant de faire de la surveillance système et de la surveillance réseau. Il se base sur RRDTool pour fonctionner. RRDTool lui permet de stocker sous forme de 27

28 petites bases de données, les informations récoltées sur les équipements surveillés et de tracer des graphiques sous forme d'images. L'avantage des bases de données RRD est qu'elles ont une taille fixe. Cependant, le problème majeur de Munin est qu'il affiche une trop grande quantité de données et qu'il est difficile de trouver l'information que l'on recherche. Figure 17 : Présentation des données sur Munin Comme nous pouvons le voir sur la figure ci-dessus, il y a beaucoup de graphiques affichés sur la même page. Comme nous l'avions vu dans la partie traitant du problème rencontré, il est dit que l'homme ne peut analyser plus de 7 informations à la fois. De plus, l'on peut remarquer que les deux barres de scrolling sont importantes. Cela signifie qu'il y a encore beaucoup d'informations qui ne sont pas visibles. La majorité des données à récupérer se trouvent sur Munin mais, il faudra également récupérer l'état des disques partagés, des backups et des données des logs du système de fichiers CVFS, gérant le système de stockage. Ces informations en main, il fallait maintenant définir ce que nous voulions vraiment utiliser et trouver un moyen de récolter ces données et de créer un rendu graphique plus organisé. 28

29 Définition des données importantes à intégrer Comme nous avons pu le voir dans la partie précédente, si l'on ne prend que les données recueillies par Munin, l'on se rend vite compte qu'il y a énormément de données qui sont récoltées. Cependant, toutes les données affichées ne sont pas pertinentes dans le cadre de la surveillance du système de stockage. Nous nous sommes donc concertés pour établir une liste des informations primordiales à collecter. Nous sommes finalement arrivés à construire la liste suivante : Utilisation des disques partagés Utilisation du système de fichiers en réseau Charge réseau Utilisation des serveurs (CPU, espace disque, processus, mémoire et extension) Utilisation des interfaces réseau sur les serveurs Etat des backups Logs du système de contrôle de versioning des fichiers Cette liste supprimait une quantité importante de graphes affichés par Munin. Il fallait maintenant trouver un moyen de récolter ces données Récolte des données Munin utilisait un moyen intéressant de récolter les données puisque RRDTool crée des bases de données RRD de taille fixe, contrairement aux bases de données classiques qui augmentent continuellement. Il a donc fallu que j'étudie la documentation sur RRDTool pour comprendre comment il fonctionne. RRDTool est un outil qui permet, entre autres, de récupérer des informations sur l'état d'équipements réseau afin de les enregistrer dans des bases de données de taille fixe (289 ko dans notre cas). Il permet également de créer une représentation graphique de ces données sur une période donnée. Avec RRDTool, une simple commande permet de créer un graphique à partir d'une base de données RRD : rrdtool graph exemple.png --start end DEF:x1=exemple.rrd:x1:AVERAGE DEF:x2=exemple.rrd:x2:AVERAGE LINE2:x1#FF0000:x1 LINE1:x2#0000FF:x2 Cette commande permet de créer un graphique enregistré au format PNG (image numérique), l'image "exemple.png". Le graphique s'étend sur la période définie entre le "start" et le "end". On indique que l'on veut afficher la moyenne des données "x1" et "x2" contenu dans la base de données "exemple.rrd". Enfin, l'on indique le nom des légendes et la couleur qui leur est associée. Voici le résultat de la commande : 29

30 Maintenant que je savais comment créer les graphiques à partir de RRDTool, je pouvais maintenant m'intéresser à l'aspect développement de l'application à mettre en place Développement de l'application Figure 18 : Exemple de graphique généré avec RRDTool Nous verrons ici, les différentes étapes dans le développement de l'application Développement d'une application avec Flex Voulant créer une application graphique agréable, je me suis intéressé à la technologie Flex. C'est un logiciel développé par Adobe permettant de créer des applications Internet riches (RIA) grâce à la technologie Flash. J'ai donc suivi plusieurs tutoriels et me suis mis à développer une interface. Le développement a été assez laborieux, car la technologie n'est pas si simple à appréhender. Après deux semaines d'apprentissage et de tests, voici la base de l'interface graphique que j'ai créé : Figure 19 : Application développée sous Flex (1) Figure 20 : Application développée sous Flex (2) Après concertation avec Juan, nous avons décidé que je ne développerai pas l'application sous Flex car, c'est assez difficile et il faut que quelqu'un puisse maintenir l'application si besoin est. Nous avons donc décidé d'explorer une solution alternative autour de l'outil collectd Développement de l'application autour de collectd Le logiciel libre collectd Collectd est un logiciel libre similaire à Munin mais ne créant pas les graphiques des données récoltées. En effet, collectd peut utiliser RRDTool pour collecter les données des équipements. Seulement, 30

31 collectd ne possède pas d'interface graphique et ne peut donc afficher aucun graphique. Cependant, collectd est assez populaire et des projets d'interface graphique se greffant au logiciel, ont vu le jour. De plus, ce logiciel présente un certain nombre d'avantages qui nous ont orienté vers lui : c'est un logiciel libre la communauté autour du projet est importante le logiciel est très bien documenté et des exemples sont fournis le logiciel a 5 année d'existence sa structure en plugins est simple à appréhender la création de plugins supplémentaires est simple Ces éléments ont été déterminant dans notre choix. Après avoir étudié la documentation de collectd nous l'avons installé et j'ai commencé à le configurer pour qu'il ne récupère que les données que nous souhaitions. La configuration de collectd se fait dans un simple fichier. Il suffit d'y activer les plugins de son choix pour que le logiciel collecte les données correspondantes (voir Annexe 14). Même si collectd ne permet pas, dans sa configuration de base, de récupérer toutes les données souhaitées, il est assez simple de créer ses propres plugins pour le faire. Nous développerons ce point dans une autre partie. Dans un environnement distribué comme le système de stockage, comment récolter les données de tous les équipements sur lesquels collectd est installé? Ce n'est pas un problème car, il est possible de désigner une installation de collectd comme "serveur" et d'autres comme "clients". De ce fait, les clients vont envoyer leurs données au serveur. Ces déclarations se font simplement dans le fichier de configuration de collectd. Nous allons maintenant voir comment créer un plugin pour collectd La création de plugins pour collectd Nous l'avons dit précédemment, collectd ne possède pas tous les plugins dont nous avions besoin. Le plugin "Exec" permet d'ajouter des plugins créés par les utilisateurs. Les plugins créés par les utilisateurs sont en fait, des programmes pouvant être écrit dans différents langages. Ces programmes doivent être écrits d'une manière telle qu'ils renvoient des résultats qui seront utilisés via RRDTool pour être enregistrés dans des bases de données RRD. Ainsi, j'ai créé deux plugins que nous avons ajoutés à collectd. Pour créer ces deux plugins, j'ai utilisé le langage bash car il me permettait de récolter facilement les données recherchées. Dans notre cas, le principe était simple. Il me suffisait de récupérer les données souhaitées à l'aide de commandes systèmes puis, de renvoyer les résultats sous forme de commandes qui seront interprétées par RRDTool via collectd. Collectd utilisera RRDTool pour créer des bases de données RRD pour y enregistrer les valeurs renvoyées par les commandes. Voici le format que doit prendre le résultat qui doit être envoyé à collectd : 31

32 echo "PUTVAL NOM_HOTE/NOM_DOSSIER_ENREGISTREMENT/NOM_FICHIER_RRD interval=valeur_intervalle_entre_2_enregistrements HEURE_ACTUELLE:VALEUR_A_ENREGISTRER" exemple : echo "PUTVAL $HOSTNAME/exec-avg/gauge-idle interval=$intrval $time:$idleavg" Les deux plugins créés et commentés, peuvent être visualisés en Annexes 15 et 16. Ces plugins m'ont permis de récupérer des données sur le pourcentage d'utilisation des CPU et le pourcentage d'utilisation de partitions particulières. Nous allons maintenant nous intéresser à l'interface graphique couplée à collectd pour créer les graphiques L'interface graphique Jarmon J'ai testé plusieurs interfaces graphiques avant de choisir Jarmon. J'ai choisi d'utiliser l'interface graphique Jarmon pour les raisons suivantes : utilisation de l'html, du javascript et de la librairie jquery (librairie javascript très puissante en termes d'interaction et d'effets) les graphiques sont affichés en temps réel possibilité de se déplacer dans le temps sur le graphique possibilité de cacher des courbes en temps réel avec une remise à l'échelle possibilité d'ajouter des fonctionnalités/données personnelles facilité d'intégration des données pour créer les graphiques Jarmon s'articule principalement autour de quatre fichiers "jarmon.js", "index.html", "dependencies.js" et "jarmon_recipes.js". Le fichier "jarmon.js" définit l'ensemble des interactions possibles avec les utilisateurs et les fonctions pour effectuer les requêtes sur les fichiers RRD. Le fichier "dependencies.js", quant à lui, rassemble les librairies qui permettent à "jarmon.js" d'utiliser les interactions avec les utilisateurs. La page "index.html" définie l'agencement des éléments et ce qui doit être affiché à l'écran. Enfin, le fichier "jarmon_recipes.js" contient l'architecture des graphiques. C'est lui qui est responsable des données contenues dans les graphiques. Les seuls fichiers qu'il faut impérativement modifier sont "jarmon_recipes.js" et "index.html". J'ai donc créé la structure des différents graphiques à afficher dans "jarmon_recipes.js" et défini l'agencement de la page à afficher dans "index.html" (voir Annexes 17 et 18). Cependant, l'implémentation de l'interface ne s'est pas faite sans problèmes. Etant donné que l'interface utilise javascript, nous avons rencontré des problèmes de performances lorsqu'il a fallu afficher les 390 données dont nous disposions pour les graphiques. Pour résoudre ce problème, nous avons travaillé avec le créateur de l'application. Le problème était causé par un fichier conséquent qui était appelé continuellement et qui bloquait l'application. Cependant nous nous sommes rendus compte que ce 32

33 fichier n'était pas indispensable. Ainsi, nous avons pu résoudre le problème en modifiant le code de "jarmon.js" pour qu'il n'utilise plus ce fichier. Nous allons maintenant nous intéresser aux données personnelles ajoutées sur Jarmon Ajout du suivi de l'état des backups L'un des éléments qui devait être suivi par l'application est l'état des backups. Les backups sont les sauvegardes des données utilisateurs sur le système. Il existe deux types de backups dans notre cas, les backups journalières et les backups qui se font quatre fois par jour. Les premières sont appelées "daily backups" alors que les secondes sont appelées "hourly backups". J'ai créé deux scripts, un pour chaque type de backup. J'ai utilisé le langage python pour créer ces deux scripts. Le concept des scripts est simple, je vais vérifier que la date de modification des backups est admissible par rapport à une limite de validité. Si le test est valide, alors je vais vérifier que l'archive contient au moins fichiers (seuil minimal) et si c'est le cas, alors je considère que l'archive est valide sinon, je considère qu'il y a un problème. Si le test n'est pas valide dès le départ alors, je considère directement que l'archive n'est pas valide. En fonction de ce qui est retourné pout l'ensemble des tests, des tableaux HTML correspondants aux résultats sont créés. Le script de vérification des "hourly backups" est consultable en Annexe 19. Jarmon utilisant le langage HTML, il a été facile d'intégrer ces tableaux à l'interface. Voici à l'heure actuelle ce à quoi ressemble l'interface, sachant que quelques données vont encore être ajoutées : Figure 21 : Interface graphique Jarmon 33

34 5 Réflexion critique du travail réalisé & Conclusion 34

35 5 Réflexion critique du travail réalisé & Conclusion 5.1 Réflexion critique du travail réalisé En ce qui concerne la conception du banc de test et du monitoring de celui-ci, les objectifs ont globalement été atteints. En effet, le banc de test a été mis en place et a permis de reproduire l'un des problèmes rencontrés sur le système en production. Ainsi, nous avons pu résoudre le problème de pertes de paquets entre le Force10 et les serveurs en augmentant le temps inter-trame. Nous n'avons pas pu reproduire le problème de la perte d'un paquet tous les milliards de paquets reçus sur le Force10 car, nous ne disposions pas assez de matériel. D'ailleurs, il en est de même pour les ingénieurs de chez Force10, qui eux non plus ne peuvent reproduire le problème à cause d'un manque de matériel. De plus, l'ensemble des outils de monitoring pour le Force10 ont été implémentés sauf la détection des boucles réseau. Snort ne gérant pas le protocole ARP associé aux boucles réseau, je n'ai pas pu l'intégrer. Je pense que ce premier projet est une réussite dans l'ensemble. Le travail que nous avons fourni permet aujourd'hui à d'autres personnes, de profiter du banc de test pour effectuer des tests avant d'implémenter leur travail sur le système en production. En ce qui concerne le second projet, celui-ci n'est pas encore terminé à l'heure où j'écris ce rapport. Cependant, je peux affirmer après avoir fait une démonstration de l'application de monitoring, que mon tuteur en est satisfait. Les fonctionnalités majeures y sont intégrées et permettent de surveiller le système de stockage en temps réel. L'application est déjà fonctionnelle et il ne lui manque que deux fonctionnalités que je devrai avoir intégré, d'ici la fin de mon stage. Je pense que l'on peut dire que les objectifs concernant ce projet sont quasiment atteints. Lorsque l'application sera totalement terminée, je ferai une démonstration aux personnes qui l'utiliseront plus tard et je pense sincèrement qu'elle leur simplifiera la vie car, elles n'auront plus besoin de chercher les informations à plusieurs endroits différents. 5.2 Conclusion Ce stage a été une expérience professionnelle très riche pour moi et ce, à tous les niveaux. J'ai eu la chance d'intégrer un environnement multi-culturelle et qui plus est, à un tournant de l'expérience LHCb. En effet, j'ai acquis énormément de connaissances en travaillant avec des experts dans leur domaine, que ce soit en informatique ou en réseau. L'échange et l'apprentissage faisait partie de mon quotidien. Par exemple, j'ai créé des programmes dans des langages comme le Python ou le Perl, que je n'avais jamais pratiqué auparavant. De ce fait j'ai élargi mon champ de compétences. Cela m'a permis d'affirmer ma confiance en mes capacités, car j'ai la plupart du temps été libre dans les choix que j'ai eu à faire. Bien sûr, nous nous sommes toujours concertés pour les choix cruciaux mais, mon avis avait son importance. Ainsi, j'ai pu utiliser mes connaissances et les mettre en application pour gérer ces projets et les mener à bien, mêm si ça n'est pas encore tout à fait le cas pour le second projet. 35

36 Au final, les personnes avec qui j'ai travaillé ont su me faire confiance et j'ai su le leur rendre en répondant à leurs attentes. Ce stage m'a apporté autant sur le plan professionnel que sur le plan personnel. Il a également conforté mes choix en termes de formation, et m'a rassuré pour mon projet professionnel, car j'ai aimé faire ce que j'ai fait durant ce stage. L'expérience humaine dans ce stage a été très enrichissante et j'espère avoir apporté quelque chose aux personnes avec qui j'ai travaillé durant ces cinq mois. 36

37 A Bibliographie 37

38 SPURGEON Charles. Ethernet The Definitive Guide. Sebastopol, United States : O'Reilly, 2000, 522 p. AIROLDI Edoardo, BLEI David, FIENBERG Stephen, GOLDENBERG Anna, XING Eric, and ZHENG Alice. Statistical network Analysis : Models, Issues, and New Directions. Berlin, Germany : Springer, 2007, 197 p. SEBA Djillali. CISCO Interconnexiondes réseaux à l'aide des routeurs et commutateurs. Nantes, France : ENI, 2003, 500 p. PIGNET François. Réseaux Informatiques Supervision et Administration. St Herblain, France : ENI, 2007, 274 p. RAHOUAL Malek, et SIARRY Patrick. Réseaux informatiques : conception et optimisation. Paris, France : Technip, 2006, 346 p. CARPENTIER Jean-François. La sécurité informatique dans la petite entreprise : état de l'art et bonnes pratiques.st Herblain, France : ENI, 2009, 278 p. VOYER Pierre. Tableaux de bord de gestion et indicateurs de performance.2è éd. Sainte-Foy, Canada : Presses de l'université du Québec, 1999, 446 p. MENTHONNEX Jean - CERSSI. Sécurité et qualité informatiques : nouvelles orientations. Lausanne, Suisse : Presses Polytechniques et Universitaires Romandes, 1995, 77 p. EKERSON Wayne. Performance Dashboards : Measuring, Monitoring, and Managing your Business. Hokoben, United States : Wiley, 2006, 321 p. JQUERY COMMUNITY EXPERTS. jquery Cookbook. Sebastopol, United States : O'Reilly, 2009, 480 p. NOBLE Joshua, ANDERSON Todd, BRAITHWAITE Garth, CASARIO Marco, and TRETOLA Rich. Flex 4 Cookbook. Sebastopol, United States : O'Reilly, 2010, 768 p. 38

39 B Annexes 39

40 6 Annexes 6.1 Annexe 1 Système d'acquisition des données dans LHCb 40

41 6.2 Annexe 2 Capacités des routeurs Force10 E1200 et E600i 41

42 6.3 Annexe 3 Gantt projet 1 42

43 43

44 6.4 Annexe 4 - Gantt projet 2 44

45 6.5 Annexe 5 - Câblage du Snake test 45

46 6.6 Annexe 6 - Configuration du Force10 pour le Snake test Manipulations d'activation des ports (les 90 ports sur la première linecard et les 6 premiers ports sur la seconde) : sdaq2(conf-if-gi-0/1)#show config! interface GigabitEthernet 0/1 no ip address switchport no shutdown sdaq2(conf-if-gi-0/1)#exit sdaq2(conf)#interface gi 0/2 sdaq2(conf-if-gi-0/2)#show config! interface GigabitEthernet 0/2 no ip address switchport no shutdown sdaq2(conf-if-gi-0/2)#exit sdaq2(conf)#interface gi 0/3 sdaq2(conf-if-gi-0/3)#show config! interface GigabitEthernet 0/3 no ip address switchport no shutdown sdaq2(conf-if-gi-0/3)#exit sdaq2(conf)#interface gi 0/4 sdaq2(conf-if-gi-0/4)#show config! interface GigabitEthernet 0/4 no ip address switchport no shutdown sdaq2(conf-if-gi-0/4)#exit sdaq2(conf)#interface gi 0/5 sdaq2(conf-if-gi-0/5)#show config! interface GigabitEthernet 0/5 no ip address switchport no shutdown sdaq2(conf-if-gi-0/5)#exit sdaq2(conf)#interface gi 0/6 sdaq2(conf-if-gi-0/6)#show config! interface GigabitEthernet 0/6 no ip address shutdown sdaq2(conf-if-gi-0/6)#switchport 46

47 sdaq2(conf-if-gi-0/6)#no shutdown sdaq2(conf-if-gi-0/6)#exit sdaq2(conf)#interface gi 0/7 sdaq2(conf-if-gi-0/7)#switchport sdaq2(conf-if-gi-0/7)#no shutdown sdaq2(conf-if-gi-0/7)#show config! interface GigabitEthernet 0/7 no ip address switchport no shutdown sdaq2(conf-if-gi-0/7)#exit sdaq2(conf)#interface gi 0/8 sdaq2(conf-if-gi-0/8)#switchport sdaq2(conf-if-gi-0/8)#no shutdown sdaq2(conf-if-gi-0/8)#exit sdaq2(conf)#interface gi 0/9 sdaq2(conf-if-gi-0/9)#switchport sdaq2(conf-if-gi-0/9)#no shutdown sdaq2(conf-if-gi-0/9)#exit sdaq2(conf)#interface gi 0/10 sdaq2(conf-if-gi-0/10)#switchport sdaq2(conf-if-gi-0/10)#no shutdown sdaq2(conf-if-gi-0/10)#exit sdaq2(conf)#interface gi 0/11 sdaq2(conf-if-gi-0/11)#switchport sdaq2(conf-if-gi-0/11)#no shutdown sdaq2(conf-if-gi-0/11)#exit sdaq2(conf)#interface gi 0/12 sdaq2(conf-if-gi-0/12)#switchport sdaq2(conf-if-gi-0/12)#no shutdown sdaq2(conf-if-gi-0/12)#exit sdaq2(conf)#interface gi 0/13 sdaq2(conf-if-gi-0/13)#switchport sdaq2(conf-if-gi-0/13)#no shutdown sdaq2(conf-if-gi-0/13)#exit Affection des ports à des vlan (on ajoute les ports deux à deux dans un vlan différent) : sdaq2(conf-if-vl-1)#show config! interface Vlan 1 description vlan1!untagged GigabitEthernet 0/0-89!untagged GigabitEthernet 1/0-5 sdaq2(conf-if-vl-1)#no shutdown ^ % Error: Invalid input at "^" marker. sdaq2(conf-if-vl-1)#no? description Interface description mtu Unconfigure interface MTU name Unconfigure vlan name 47

48 restrict-flooding Configure Restricted Vlan Flooding sdaq2(conf-if-vl-1)#exit sdaq2(conf)#interface vlan 2 sdaq2(conf-if-vl-2)#show config! interface Vlan 2 no ip address shutdown sdaq2(conf-if-vl-2)#no shutdown sdaq2(conf-if-vl-2)#untagged gi 0/2-3 sdaq2(conf-if-vl-2)#show config! interface Vlan 2 no ip address untagged GigabitEthernet 0/2-3 no shutdown sdaq2(conf-if-vl-2)#exit sdaq2(conf)# interface vlan 1 sdaq2(conf-if-vl-1)#show config! interface Vlan 1 description vlan1!untagged GigabitEthernet 0/0-1,4-89!untagged GigabitEthernet 1/0-5 sdaq2(conf-if-vl-1)#exit sdaq2(conf)#interface vlan 34 sdaq2(conf-if-vl-34)#no shutdown sdaq2(conf-if-vl-34)#untagged gi 0/66-67 sdaq2(conf-if-vl-34)#exit sdaq2(conf)#interface vlan 35 sdaq2(conf-if-vl-35)#no shutdown sdaq2(conf-if-vl-35)#untagged gi 0/68-69 sdaq2(conf-if-vl-35)#exit sdaq2(conf)#interface vlan 36 sdaq2(conf-if-vl-36)#no shutdown sdaq2(conf-if-vl-36)#untagged gi 0/70-71 sdaq2(conf-if-vl-36)#exit sdaq2(conf)#interface vlan 37 sdaq2(conf-if-vl-37)#no shutdown sdaq2(conf-if-vl-37)#untagged gi 0/72-73 sdaq2(conf-if-vl-37)#exit sdaq2(conf)#interface vlan 38 sdaq2(conf-if-vl-38)#no shutdown sdaq2(conf-if-vl-38)#untagged gi 0/74-75 sdaq2(conf-if-vl-38)#exit sdaq2(conf)#interface vlan 39 sdaq2(conf-if-vl-39)#no shutdown sdaq2(conf-if-vl-39)#untagged gi 0/76-77 sdaq2(conf-if-vl-39)#exit sdaq2(conf)#interface vlan 40 sdaq2(conf-if-vl-40)#no shutdown 48

49 sdaq2(conf-if-vl-40)#untagged gi 0/78-79 sdaq2(conf-if-vl-40)#exit sdaq2(conf)#interface vlan 41 sdaq2(conf-if-vl-41)#no shutdown sdaq2(conf-if-vl-41)#untagged gi 0/80-81 sdaq2(conf-if-vl-41)#exit sdaq2(conf)#interface vlan 42 sdaq2(conf-if-vl-42)#no shutdown sdaq2(conf-if-vl-42)#untagged gi 0/82-83 sdaq2(conf-if-vl-42)#exit sdaq2(conf)#interface vlan 43 sdaq2(conf-if-vl-43)#no shutdown sdaq2(conf-if-vl-43)#untagged gi 0/84-85 sdaq2(conf-if-vl-43)#exit sdaq2(conf)#interface vlan 44 sdaq2(conf-if-vl-44)#no shutdown sdaq2(conf-if-vl-44)#untagged gi 0/86-87 sdaq2(conf-if-vl-44)#exit sdaq2(conf)#interface vlan 45 sdaq2(conf-if-vl-45)#no shutdown sdaq2(conf-if-vl-45)#untagged gi 0/88-89 sdaq2(conf-if-vl-45)#exit sdaq2(conf)#interface vlan 46 sdaq2(conf-if-vl-46)#no shutdown sdaq2(conf-if-vl-46)#untagged gi 1/0-1 sdaq2(conf-if-vl-46)#exit sdaq2(conf)#interface vlan 47 sdaq2(conf-if-vl-47)#no shutdown sdaq2(conf-if-vl-47)#untagged gi 1/2-3 sdaq2(conf-if-vl-47)#exit sdaq2(conf)#interface vlan 48 sdaq2(conf-if-vl-48)#no shutdown sdaq2(conf-if-vl-48)#untagged gi 1/4-5 sdaq2(conf-if-vl-48)#exit sdaq2(conf)# 49

50 6.7 Annexe 7 - Résultats de tests iperf Test iperf en UDP côté serveur : [tpanel@netctrlux02 ~]$ iperf -s -u -m -w 200K -i Server listening on UDP port 5001 Receiving 1470 byte datagrams UDP buffer size: 256 KByte (WARNING: requested 200 KByte) [ 3] local port 5001 connected with port [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [ 3] sec 383 KBytes 1.05 Mbits/sec ms 0/ 267 (0%) [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [ 3] sec 385 KBytes 1.05 Mbits/sec ms 0/ 268 (0%) [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [ 3] sec 383 KBytes 1.05 Mbits/sec ms 0/ 267 (0%) [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [ 3] sec 1.25 MBytes 1.05 Mbits/sec ms 0/ 893 (0%) Test iperf en UDP côté client : [tpanel@netctrlux03 iperf-2.0.4]$ iperf -c u -b 3000M -m -w 200K -i3 -t Client connecting to , UDP port 5001 Sending 1470 byte datagrams UDP buffer size: 256 KByte (WARNING: requested 200 KByte) [ 3] local port connected with port 5001 [ ID] Interval Transfer Bandwidth [ 3] sec 342 MBytes 957 Mbits/sec [ ID] Interval Transfer Bandwidth [ 3] sec 342 MBytes 957 Mbits/sec [ ID] Interval Transfer Bandwidth [ 3] sec 342 MBytes 957 Mbits/sec [ ID] Interval Transfer Bandwidth [ 3] sec 1.11 GBytes 957 Mbits/sec [ 3] Sent datagrams [ 3] Server Report: [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [ 3] sec 1.11 GBytes 957 Mbits/sec ms 118/ (0.014%) Test iperf en TCP côté serveur : [tpanel@netctrlux02 ~]$ iperf -s -p Server listening on TCP port 4662 TCP window size: 85.3 KByte (default)

51 [ 4] local port 4662 connected with port [ ID] Interval Transfer Bandwidth [ 4] sec 961 MBytes 804 Mbits/sec Test iperf en TCP côté client : [tpanel@netctrlux03 ~]$ iperf -c i2 -t10 -p Client connecting to , TCP port 4662 TCP window size: 27.7 KByte (default) [ 3] local port connected with port 4662 [ ID] Interval Transfer Bandwidth [ 3] sec 188 MBytes 790 Mbits/sec [ ID] Interval Transfer Bandwidth [ 3] sec 194 MBytes 813 Mbits/sec [ ID] Interval Transfer Bandwidth [ 3] sec 192 MBytes 807 Mbits/sec [ ID] Interval Transfer Bandwidth [ 3] sec 193 MBytes 811 Mbits/sec [ ID] Interval Transfer Bandwidth [ 3] sec 193 MBytes 810 Mbits/sec [ ID] Interval Transfer Bandwidth [ 3] sec 961 MBytes 805 Mbits/sec 51

52 6.8 Annexe 8 - Configuration du commutateur HP pour le test principal Activation du protocole LACP sur les 24 ports du module A : shp(config)# interface A1-A24 shp(eth-a1-a24)# lacp active shp(eth-a1-a24)# enable Association de 8 ports à trois "trunk" différents avec le protocole LACP et activation des ports: shp(config)# trunk a1-a8 trk1 lacp shp(config)# trunk a9-a16 trk2 lacp shp(config)# trunk a17-a24 trk3 lacp shp(config)# int a1-a24 enable Assignation de chaque "trunk" à un vlan tout en lui affectant une adresse IP avec autorisation des "Jumbo packets" : shp(vlan-101)# vl 101 untagged trk1 shp(vlan-101)# show vlans Status and Counters - VLAN Information Maximum VLANs to support : 32 Primary VLAN : ECS Management VLAN : ECS VLAN ID Name Status Voice Jumbo ECS Port-based No No 10 DATA_10 Port-based No Yes 11 DATA_11 Port-based No Yes 12 DATA_12 Port-based No Yes 13 DATA_13 Port-based No Yes 14 DATA_14 Port-based No Yes 15 DATA_15 Port-based No Yes 16 DATA_16 Port-based No Yes 17 DATA_17 Port-based No Yes 98 PORTMIRROR Port-based No Yes 99 SPARE Port-based No No 101 VLAN101 Port-based No Yes shp(vlan-101)# ip address /23 shp(vlan-101)# jumbo shp(config)# vlan 102 untagged trk2 shp(config)# vlan 103 untagged trk3 shp(config)# show vlans Status and Counters - VLAN Information Maximum VLANs to support : 32 Primary VLAN : ECS Management VLAN : ECS VLAN ID Name Status Voice Jumbo ECS Port-based No No 52

53 10 DATA_10 Port-based No Yes 11 DATA_11 Port-based No Yes 12 DATA_12 Port-based No Yes 13 DATA_13 Port-based No Yes 14 DATA_14 Port-based No Yes 15 DATA_15 Port-based No Yes 16 DATA_16 Port-based No Yes 17 DATA_17 Port-based No Yes 98 PORTMIRROR Port-based No Yes 99 SPARE Port-based No No 101 VLAN101 Port-based No Yes 102 VLAN102 Port-based No No 103 VLAN103 Port-based No No shp(config)# vlan 102 shp(vlan-102)# ip address /23 shp(vlan-102)# jumbo shp(vlan-102)# vlan 103 shp(vlan-103)# ip address /23 shp(vlan-103)# jumbo shp(vlan-103)# exit 53

54 6.9 Annexe 9 - Configuration du Force10 pour le test principal Configuration du MTU et IP MTU sur les port-channel : sdaq2(conf)#interface port-channel 1 sdaq2(conf-if-po-1)#mtu 9252 sdaq2(conf-if-po-1)#ip mtu 9234 sdaq2(conf-if-po-1)#show config! interface Port-channel 1 ip address /23 mtu 9252 ip mtu 9234 no shutdown sdaq2(conf-if-po-1)#interface port-channel 2 sdaq2(conf-if-po-2)#mtu 9252 sdaq2(conf-if-po-2)#ip mtu 9234 sdaq2(conf-if-po-2)#interface port-channel 3 sdaq2(conf-if-po-3)#mtu 9252 sdaq2(conf-if-po-3)#ip mtu 9234 sdaq2(conf-if-po-3)#show config! interface Port-channel 3 ip address /23 mtu 9252 ip mtu 9234 no shutdown Vérification de l'établissement de connexion avec le HP : sdaq2#con sdaq2(conf)#protocol lldp sdaq2(conf-lldp)#? advertise Advertise TLVs disable Disable LLDP protocol globally end Exit from configuration mode exit Exit from LLDP configuration mode hello LLDP hello configuration mode LLDP mode configuration (default = rx and tx) multiplier LLDP multiplier configuration no Negate a command or set its defaults show Show LLDP configuration sdaq2(conf-lldp)#show config! protocol lldp sdaq2(conf-lldp)#no disable sdaq2(conf-lldp)#exit sdaq2(conf)#end sdaq2#show lldp neighbors sdaq2#show lldp neighbors sdaq2#show lldp neighbors sdaq2#show lldp neighbors 54

55 sdaq2#show lldp neighbors sdaq2#show lldp neighbors Loc PortID Rem Host Name Rem Port Id Rem Chassis Id Gi 0/24 - GigabitEthernet 0/29 00:01:e8:5d:e1:dc Gi 3/6 shp 1 00:17:a4:c1:c6:00 Gi 3/7 shp 2 00:17:a4:c1:c6:00 Gi 3/8 shp 3 00:17:a4:c1:c6:00 Gi 3/9 shp 4 00:17:a4:c1:c6:00 Gi 3/10 shp 5 00:17:a4:c1:c6:00 Gi 3/11 shp 6 00:17:a4:c1:c6:00 Gi 3/12 shp 7 00:17:a4:c1:c6:00 Gi 3/13 shp 8 00:17:a4:c1:c6:00 Gi 3/14 shp 9 00:17:a4:c1:c6:00 Gi 3/15 shp 10 00:17:a4:c1:c6:00 Gi 3/16 shp 11 00:17:a4:c1:c6:00 Gi 3/17 shp 12 00:17:a4:c1:c6:00 Gi 3/18 shp 13 00:17:a4:c1:c6:00 Gi 3/19 shp 14 00:17:a4:c1:c6:00 Gi 3/20 shp 15 00:17:a4:c1:c6:00 Gi 3/21 shp 16 00:17:a4:c1:c6:00 Gi 3/22 shp 17 00:17:a4:c1:c6:00 Gi 3/23 shp 18 00:17:a4:c1:c6:00 Gi 3/24 shp 19 00:17:a4:c1:c6:00 Gi 3/25 shp 20 00:17:a4:c1:c6:00 Gi 3/26 shp 21 00:17:a4:c1:c6:00 Gi 3/27 shp 22 00:17:a4:c1:c6:00 Gi 3/28 shp 23 00:17:a4:c1:c6:00 Gi 3/29 shp 24 00:17:a4:c1:c6:00 sdaq2#show lldp neighbors Loc PortID Rem Host Name Rem Port Id Rem Chassis Id Gi 0/24 - GigabitEthernet 0/29 00:01:e8:5d:e1:dc Gi 3/6 shp 1 00:17:a4:c1:c6:00 Gi 3/7 shp 2 00:17:a4:c1:c6:00 Gi 3/8 shp 3 00:17:a4:c1:c6:00 Gi 3/9 shp 4 00:17:a4:c1:c6:00 Gi 3/10 shp 5 00:17:a4:c1:c6:00 Gi 3/11 shp 6 00:17:a4:c1:c6:00 Gi 3/12 shp 7 00:17:a4:c1:c6:00 Gi 3/13 shp 8 00:17:a4:c1:c6:00 Gi 3/14 shp 9 00:17:a4:c1:c6:00 Gi 3/15 shp 10 00:17:a4:c1:c6:00 Gi 3/16 shp 11 00:17:a4:c1:c6:00 Gi 3/17 shp 12 00:17:a4:c1:c6:00 Gi 3/18 shp 13 00:17:a4:c1:c6:00 Gi 3/19 shp 14 00:17:a4:c1:c6:00 Gi 3/20 shp 15 00:17:a4:c1:c6:00 Gi 3/21 shp 16 00:17:a4:c1:c6:00 Gi 3/22 shp 17 00:17:a4:c1:c6:00 Gi 3/23 shp 18 00:17:a4:c1:c6:00 Gi 3/24 shp 19 00:17:a4:c1:c6:00 55

56 Gi 3/25 shp 20 00:17:a4:c1:c6:00 Gi 3/26 shp 21 00:17:a4:c1:c6:00 Gi 3/27 shp 22 00:17:a4:c1:c6:00 Gi 3/28 shp 23 00:17:a4:c1:c6:00 Gi 3/29 shp 24 00:17:a4:c1:c6:00 sdaq2#show lldp neighbors Loc PortID Rem Host Name Rem Port Id Rem Chassis Id Gi 0/24 - GigabitEthernet 0/29 00:01:e8:5d:e1:dc Gi 3/6 shp 1 00:17:a4:c1:c6:00 Gi 3/7 shp 2 00:17:a4:c1:c6:00 Gi 3/8 shp 3 00:17:a4:c1:c6:00 Gi 3/9 shp 4 00:17:a4:c1:c6:00 Gi 3/10 shp 5 00:17:a4:c1:c6:00 Gi 3/11 shp 6 00:17:a4:c1:c6:00 Gi 3/12 shp 7 00:17:a4:c1:c6:00 Gi 3/13 shp 8 00:17:a4:c1:c6:00 Gi 3/14 shp 9 00:17:a4:c1:c6:00 Gi 3/15 shp 10 00:17:a4:c1:c6:00 Gi 3/16 shp 11 00:17:a4:c1:c6:00 Gi 3/17 shp 12 00:17:a4:c1:c6:00 Gi 3/18 shp 13 00:17:a4:c1:c6:00 Gi 3/19 shp 14 00:17:a4:c1:c6:00 Gi 3/20 shp 15 00:17:a4:c1:c6:00 Gi 3/21 shp 16 00:17:a4:c1:c6:00 Gi 3/22 shp 17 00:17:a4:c1:c6:00 Gi 3/23 shp 18 00:17:a4:c1:c6:00 Gi 3/24 shp 19 00:17:a4:c1:c6:00 Gi 3/25 shp 20 00:17:a4:c1:c6:00 Gi 3/26 shp 21 00:17:a4:c1:c6:00 Gi 3/27 shp 22 00:17:a4:c1:c6:00 Gi 3/28 shp 23 00:17:a4:c1:c6:00 Gi 3/29 shp 24 00:17:a4:c1:c6:00 Configuration des entrées statiques de la table ARP du Force10 pour router les paquets : Exemple afin de vérifier quelle adresse MAC est utilisée par le HP pour communiquer : sdaq2#ping Type Ctrl-C to abort. Sending 5, 100-byte ICMP Echos to , timeout is 2 seconds:!!!!! Success rate is percent (5/5), round-trip min/avg/max = 0/0/0 (ms) sdaq2#ping Type Ctrl-C to abort. Sending 5, 100-byte ICMP Echos to , timeout is 2 seconds:!!!!! Success rate is percent (5/5), round-trip min/avg/max = 0/0/0 (ms) sdaq2#ping Type Ctrl-C to abort. Sending 5, 100-byte ICMP Echos to , timeout is 2 seconds:!!!!! 56

57 Success rate is percent (5/5), round-trip min/avg/max = 0/0/0 (ms) sdaq2#show arp Protocol Address Age(min) Hardware Address Interface VLAN CPU Internet :01:e8:12:b1:a7 Ma 0/0 - CP Internet :01:e8:12:b1:a7 Ma 0/0 - CP Internet :30:48:7e:78:38 Ma 0/0 - CP Internet :14:0b:60:17:2d Ma 0/0 - CP Internet :01:e8:12:b1:a7 Ma 0/0 - CP Internet :17:a4:c1:c6:00 Po 1 - CP Internet :01:e8:74:32:13 Po 1 - CP Internet :17:a4:c1:c6:00 Po 2 - CP Internet :01:e8:74:32:14 Po 2 - CP Internet :17:a4:c1:c6:00 Po 3 - CP Internet :01:e8:74:32:15 Po 3 - CP Internet :01:e8:74:32:12 - Vl 2 CP L'on voit que le HP utilise l'adresse MAC 00:17:a4:c1:c6:00 pour communiquer. C'est celle que l'on va utiliser pour créer les entrées statiques dans la table ARP : sdaq2#conf sdaq2(conf)#arp :17:a4:c1:c6:00 port-channel 1 sdaq2(conf)#arp :17:a4:c1:c6:00 port-channel 1 sdaq2(conf)#arp :17:a4:c1:c6:00 port-channel 1 sdaq2(conf)#arp :17:a4:c1:c6:00 port-channel 1 sdaq2(conf)#arp :17:a4:c1:c6:00 port-channel 1 sdaq2(conf)#arp :17:a4:c1:c6:00 port-channel 1 sdaq2(conf)#arp :17:a4:c1:c6:00 port-channel 1 sdaq2(conf)#arp :17:a4:c1:c6:00 port-channel 1 sdaq2(conf)#arp :17:a4:c1:c6:00 port-channel 1 sdaq2(conf)#arp :17:a4:c1:c6:00 port-channel 1 sdaq2(conf)#arp :17:a4:c1:c6:00 port-channel 1 sdaq2(conf)#arp :17:a4:c1:c6:00 port-channel 1 sdaq2(conf)#arp :17:a4:c1:c6:00 port-channel 1 sdaq2(conf)#arp :17:a4:c1:c6:00 port-channel 1 sdaq2(conf)#arp :17:a4:c1:c6:00 port-channel 1 sdaq2(conf)#arp :17:a4:c1:c6:00 port-channel 1 sdaq2(conf)#arp :17:a4:c1:c6:00 port-channel 1 sdaq2(conf)#arp :17:a4:c1:c6:00 port-channel 1 sdaq2(conf)#arp :17:a4:c1:c6:00 port-channel 1 sdaq2(conf)#arp :17:a4:c1:c6:00 port-channel 1 sdaq2(conf)#arp :17:a4:c1:c6:00 port-channel 2 sdaq2(conf)#arp :17:a4:c1:c6:00 port-channel 2 sdaq2(conf)#arp :17:a4:c1:c6:00 port-channel 2 sdaq2(conf)#arp :17:a4:c1:c6:00 port-channel 2 sdaq2(conf)#arp :17:a4:c1:c6:00 port-channel 2 sdaq2(conf)#arp :17:a4:c1:c6:00 port-channel 2 sdaq2(conf)#arp :17:a4:c1:c6:00 port-channel 2 sdaq2(conf)#arp :17:a4:c1:c6:00 port-channel 2 sdaq2(conf)#arp :17:a4:c1:c6:00 port-channel 2 sdaq2(conf)#arp :17:a4:c1:c6:00 port-channel 2 57

58 sdaq2(conf)#arp :17:a4:c1:c6:00 port-channel 2 sdaq2(conf)#arp :17:a4:c1:c6:00 port-channel 2 sdaq2(conf)#arp :17:a4:c1:c6:00 port-channel 2 sdaq2(conf)#arp :17:a4:c1:c6:00 port-channel 2 sdaq2(conf)#arp :17:a4:c1:c6:00 port-channel 2 sdaq2(conf)#arp :17:a4:c1:c6:00 port-channel 2 sdaq2(conf)#arp :17:a4:c1:c6:00 port-channel 2 sdaq2(conf)#arp :17:a4:c1:c6:00 port-channel 2 sdaq2(conf)#arp :17:a4:c1:c6:00 port-channel 2 sdaq2(conf)#arp :17:a4:c1:c6:00 port-channel 2 sdaq2(conf)#arp :17:a4:c1:c6:00 port-channel 3 sdaq2(conf)#arp :17:a4:c1:c6:00 port-channel 3 sdaq2(conf)#arp :17:a4:c1:c6:00 port-channel 3 sdaq2(conf)#arp :17:a4:c1:c6:00 port-channel 3 sdaq2(conf)#arp :17:a4:c1:c6:00 port-channel 3 sdaq2(conf)#arp :17:a4:c1:c6:00 port-channel 3 sdaq2(conf)#arp :17:a4:c1:c6:00 port-channel 3 sdaq2(conf)#arp :17:a4:c1:c6:00 port-channel 3 sdaq2(conf)#arp :17:a4:c1:c6:00 port-channel 3 sdaq2(conf)#arp :17:a4:c1:c6:00 port-channel 3 sdaq2(conf)#arp :17:a4:c1:c6:00 port-channel 3 sdaq2(conf)#arp :17:a4:c1:c6:00 port-channel 3 sdaq2(conf)#arp :17:a4:c1:c6:00 port-channel 3 sdaq2(conf)#arp :17:a4:c1:c6:00 port-channel 3 sdaq2(conf)#arp :17:a4:c1:c6:00 port-channel 3 sdaq2(conf)#arp :17:a4:c1:c6:00 port-channel 3 sdaq2(conf)#arp :17:a4:c1:c6:00 port-channel 3 sdaq2(conf)#arp :17:a4:c1:c6:00 port-channel 3 sdaq2(conf)#arp :17:a4:c1:c6:00 port-channel 3 sdaq2(conf)#arp :17:a4:c1:c6:00 port-channel 3 sdaq2(conf)#exit sdaq2#show arp Protocol Address Age(min) Hardware Address Interface VLAN CPU Internet :01:e8:12:b1:a7 Ma 0/0 - CP Internet :01:e8:12:b1:a7 Ma 0/0 - CP Internet :30:48:7e:78:38 Ma 0/0 - CP Internet :14:0b:60:17:2d Ma 0/0 - CP Internet :01:e8:12:b1:a7 Ma 0/0 - CP Internet :17:a4:c1:c6:00 Po 1 - CP Internet :17:a4:c1:c6:00 Po 1 - CP Internet :17:a4:c1:c6:00 Po 1 - CP Internet :17:a4:c1:c6:00 Po 1 - CP Internet :17:a4:c1:c6:00 Po 1 - CP Internet :17:a4:c1:c6:00 Po 1 - CP Internet :17:a4:c1:c6:00 Po 1 - CP Internet :17:a4:c1:c6:00 Po 1 - CP Internet :17:a4:c1:c6:00 Po 1 - CP Internet :17:a4:c1:c6:00 Po 1 - CP Internet :17:a4:c1:c6:00 Po 1 - CP Internet :01:e8:74:32:13 Po 1 - CP Internet :17:a4:c1:c6:00 Po 1 - CP 58

59 Internet :17:a4:c1:c6:00 Po 1 - CP Internet :17:a4:c1:c6:00 Po 1 - CP Internet :17:a4:c1:c6:00 Po 1 - CP Internet :17:a4:c1:c6:00 Po 1 - CP Internet :17:a4:c1:c6:00 Po 1 - CP Internet :17:a4:c1:c6:00 Po 1 - CP Internet :17:a4:c1:c6:00 Po 1 - CP Internet :17:a4:c1:c6:00 Po 1 - CP Internet :17:a4:c1:c6:00 Po 1 - CP Internet :17:a4:c1:c6:00 Po 2 - CP Internet :17:a4:c1:c6:00 Po 2 - CP Internet :17:a4:c1:c6:00 Po 2 - CP Internet :17:a4:c1:c6:00 Po 2 - CP Internet :17:a4:c1:c6:00 Po 2 - CP Internet :17:a4:c1:c6:00 Po 2 - CP Internet :17:a4:c1:c6:00 Po 2 - CP Internet :17:a4:c1:c6:00 Po 2 - CP Internet :17:a4:c1:c6:00 Po 2 - CP Internet :17:a4:c1:c6:00 Po 2 - CP Internet :17:a4:c1:c6:00 Po 2 - CP Internet :01:e8:74:32:14 Po 2 - CP Internet :17:a4:c1:c6:00 Po 2 - CP Internet :17:a4:c1:c6:00 Po 2 - CP Internet :17:a4:c1:c6:00 Po 2 - CP Internet :17:a4:c1:c6:00 Po 2 - CP Internet :17:a4:c1:c6:00 Po 2 - CP Internet :17:a4:c1:c6:00 Po 2 - CP Internet :17:a4:c1:c6:00 Po 2 - CP Internet :17:a4:c1:c6:00 Po 2 - CP Internet :17:a4:c1:c6:00 Po 2 - CP Internet :17:a4:c1:c6:00 Po 2 - CP Internet :17:a4:c1:c6:00 Po 3 - CP Internet :17:a4:c1:c6:00 Po 3 - CP Internet :17:a4:c1:c6:00 Po 3 - CP Internet :17:a4:c1:c6:00 Po 3 - CP Internet :17:a4:c1:c6:00 Po 3 - CP Internet :17:a4:c1:c6:00 Po 3 - CP Internet :17:a4:c1:c6:00 Po 3 - CP Internet :17:a4:c1:c6:00 Po 3 - CP Internet :17:a4:c1:c6:00 Po 3 - CP Internet :17:a4:c1:c6:00 Po 3 - CP Internet :17:a4:c1:c6:00 Po 3 - CP Internet :01:e8:74:32:15 Po 3 - CP Internet :17:a4:c1:c6:00 Po 3 - CP Internet :17:a4:c1:c6:00 Po 3 - CP Internet :17:a4:c1:c6:00 Po 3 - CP Internet :17:a4:c1:c6:00 Po 3 - CP Internet :17:a4:c1:c6:00 Po 3 - CP Internet :17:a4:c1:c6:00 Po 3 - CP Internet :17:a4:c1:c6:00 Po 3 - CP Internet :17:a4:c1:c6:00 Po 3 - CP Internet :17:a4:c1:c6:00 Po 3 - CP 59

60 Internet :17:a4:c1:c6:00 Po 3 - CP Internet :01:e8:74:32:12 - Vl 2 CP Configuration des access-list (ACL) sur le Force10 pour n'autoriser que le trafic voulu vers le HP : sdaq2#con sdaq2(conf)#ip access-list extended test-in sdaq2(config-ext-nacl)#show config! ip access-list extended test-in seq 5 permit ip /24 host count seq 10 deny ip any any count sdaq2(config-ext-nacl)#no seq 5 //On enlève les règles utilisées pour les tests précédents sdaq2(config-ext-nacl)#no seq 10 //On enléve les règles utilisées pour les tests précédents sdaq2(config-ext-nacl)#permit ip / /23 count? bytes Count bytes monitor Monitor packets order QoS order of priority <cr> sdaq2(config-ext-nacl)#permit ip / /23 count sdaq2(config-ext-nacl)#permit ip / /23 count sdaq2(config-ext-nacl)#permit ip / /23 count sdaq2(config-ext-nacl)#show config! ip access-list extended test-in seq 5 permit ip / /23 count seq 10 permit ip / /23 count seq 15 permit ip / /23 count sdaq2(config-ext-nacl)#seq deny ip any any sdaq2(config-ext-nacl)#exit sdaq2(conf)#ip access-list extended test-out sdaq2(config-ext-nacl)#show config! ip access-list extended test-out seq 5 permit ip /24 host count seq 10 deny ip any any count sdaq2(config-ext-nacl)#no seq 5 //pareil que précédemment sdaq2(config-ext-nacl)#no seq 10 //pareil que précédemment sdaq2(config-ext-nacl)#permit ip / /23 count sdaq2(config-ext-nacl)#permit ip / /23 count sdaq2(config-ext-nacl)#permit ip / /23 count sdaq2(config-ext-nacl)#seq deny ip any any 60

61 6.10 Annexe 10 - Photos du banc d'essai en configuration finale 61

62 6.11 Annexe 11 - Résultats des tests de pertes de paquets avant et après le temps inter-trame passé à 32 octets Résultats avant : 62

63 Résultats après : 63

64 6.12 Annexe 12 - Outil de monitoring : compteur de paquets #!/usr/bin/python import os import re import time import sys from swconfig import switchf10 from getch import TerminalFile def istoresetcounters(): print "" while(1): text = raw_input("do you want to reset the counters before you start(y/n?): ") text = text.upper() if(text == "Y"): return True elif (text == "N"): return False else: print "y or n???" continue def resetcounters(sw_obj): sw_obj.child.sendline("end", sw_obj.linesep) sw_obj.child.expect(sw_obj.prompt) sw_obj.child.sendline("conf", sw_obj.linesep) sw_obj.child.expect(sw_obj.prompt) # TELL1/UKL1 sw_obj.child.sendline("interface vlan 2", sw_obj.linesep) sw_obj.child.expect(sw_obj.prompt) sw_obj.child.sendline("no ip access-group test-in in implicitpermit", sw_obj.linesep) sw_obj.child.expect(sw_obj.prompt) sw_obj.child.sendline("ip access-group test-in in implicit-permit", sw_obj.linesep) sw_obj.child.expect(sw_obj.prompt) # HP SWITCH sw_obj.child.sendline("interface range port-channel 1-3", sw_obj.linesep) sw_obj.child.expect(sw_obj.prompt) sw_obj.child.sendline("no ip access-group test-out out implicitpermit", sw_obj.linesep) sw_obj.child.expect(sw_obj.prompt) sw_obj.child.sendline("ip access-group test-out out implicit-permit", sw_obj.linesep) sw_obj.child.expect(sw_obj.prompt) sw_obj.child.sendline("end", sw_obj.linesep) sw_obj.child.expect(sw_obj.prompt) 64

65 def get_acl_counter(sw_obj, acl): ret = "" sw_obj.child.sendline("show ip accounting access-list "+acl + " no", sw_obj.linesep) sw_obj.child.expect(sw_obj.prompt) ret = sw_obj.child.before + sw_obj.child.after return ret def display_counter(sw_obj, resetcounter): destfarm = ["224", "226", "228"] s = TerminalFile(sys.stdin) pat_test = [] for dest in destfarm: pat_test.append(re.compile("192\.168\." + dest + "\.0/23 count \((\d+) packets\)" )) pat_blackholein = re.compile(" count \((\d+) packets\)") pat_denyany = re.compile("deny ip any any count \((\d+) packets\)") sw_obj.child.sendline("end", sw_obj.linesep) sw_obj.child.expect(sw_obj.prompt) if resetcounter: resetcounters(sw_obj) cnt_testin = [0]*len(destFarm) cnt_testout = [0]*len(destFarm) cnt_blackholein = 0 cnt_denyin = 0 init = 1 while(not s.getch()): ret_testin = get_acl_counter(sw_obj, "test-in") ret_testout = get_acl_counter(sw_obj, "test-out") # mep in for TELL1/UKL1 and out for HP SWITCH for i in range(len(destfarm)): ret = pat_test[i].findall(ret_testin) if(len(ret)): cnt = 0 for pkt in ret: cnt += int(pkt) cnt_testin[i] = cnt else: print "counter not found for TEST_IN!" sys.exit(-1) ret = pat_test[i].findall(ret_testout) if(len(ret)): cnt = 0 for pkt in ret: cnt += int(pkt) cnt_testout[i] = cnt else: print "counter not found for TEST_OUT!" sys.exit(-1) 65

66 # for blachhole in ret = pat_blackholein.findall(ret_testin) if(len(ret)): cnt = 0 for pkt in ret: cnt += int(pkt) cnt_blackholein = cnt else: print "counter not found for BLACKHOLE_IN!" sys.exit(-1) # deny illegal input packets ret = pat_denyany.findall(ret_testin) if(len(ret)): cnt = 0 for pkt in ret: cnt += int(pkt) cnt_denyin = cnt else: print "counter not found for DENY_ANY_ANY!" sys.exit(-1) os.system("clear") print "" print "" print "" print "Counters of TEST in & out" print "%-15s%15s%15s%20s"%("System", "TEST_IN", "TEST_OUT","Packet Loss") print "-"*70 for i in range(len(destfarm)): print "%-15s%15d%15d%20d" % (destfarm[i], cnt_testin[i], cnt_testout[i], cnt_testin[i]-cnt_testout[i]) print "-"*70 print "" # blackhole print "%-15s%15d%15d" % ("BLACKHOLE", cnt_blackholein, 0) print "%-15s%15d%15d" % ("DENY_OTHERS", cnt_denyin, 0) print "-"*70 print "Press any key to quit" time.sleep(1) if name == " main ": reset = istoresetcounters() sw_obj = switchf10("sw-daq-02") if (not sw_obj.telnetlogin()): print "Login fail!" sys.exit(-1) if (sw_obj): display_counter(sw_obj, reset) else: print "Init. of sw-daq-02 failed!" 66

67 6.13 Annexe 13 - Fichier de règles pour Snort et capture de boucle réseau avec wireshark Règles permettant de surveiller les activités les protocoles les plus courants : # Be forwarned, this is our testing ground. We put new signatures here for # testing before incorporating them into the default signature set. This is # for bleeding edge stuff only. # alert TCP any any <> any any (msg: "TCP suspicious loop detected (TCP)"; flow: stateless; threshold: type both, track b y_src, count 2000, seconds 3; sid: ;) alert TCP any any <> any any (msg: " TCP suspicious loop detected (TCP)"; flow: stateless; threshold: type both, track b y_dst, count 2000, seconds 3; sid: ;) alert IP any any <> any any (msg: "IP suspicious loop detected (IP)"; flow: stateless; threshold: type both, track by_ src, count 2000, seconds 4; sid: ;) alert IP any any <> any any (msg: "IP suspicious loop detected (IP)"; flow: stateless; threshold: type both, track by_ dst, count 2000, seconds 4; sid: ;) alert ICMP any any <> any (msg: "ICMP suspicious loop detected (ICMP)"; threshold: type both, track by_s rc, count 2, seconds 5; sid: ;) alert ICMP any any <> any (msg: "ICMP suspicious loop detected (ICMP)"; threshold: type both, track by_ds t, count 2000, seconds 1; sid: ;) alert UDP any any <> any any (msg: "UDP suspicious loop detected (UDP)"; flow: stateless; threshold: type both, track b y_src, count 2000, seconds 3; sid: ;) alert UDP any any <> any any (msg: "UDP suspicious loop detected (UDP)"; flow: stateless; threshold: type both, track b y_dst, count 1000, seconds 3; sid: ;) alert ICMP any any <> any any (msg: "ICMP Packet detected"; sid: ;) alert TCP any any <> any any (msg: "TCP Packet detected"; sid: ;) alert UDP any any <> any any (msg: "UDP Packet detected"; sid: ;) Capture en ligne de commande d'une boucle réseau avec Wireshark : sudo tshark -i eth0 Running as user "root" and group "root". This could be dangerous. Capturing on eth HewlettP_c1:d6:ba -> LLDP_Multicast LLDP Chassis Id = 00:17:a4:c1:c6:00 Port Id = 70 TTL = Dell_b0:c4:dd -> Broadcast ARP Who has ? Tell Dell_b0:c4:dd -> Broadcast ARP Who has ? Tell Dell_b0:c4:dd -> Broadcast ARP Who has ? Tell Dell_b0:c4:dd -> Broadcast ARP Who has ? Tell Dell_b0:c4:dd -> Broadcast ARP Who has ? Tell Dell_b0:c4:dd -> Broadcast ARP Who has ? Tell

68 Dell_b0:c4:dd -> Broadcast ARP Who has ? Tell Dell_b0:c4:dd -> Broadcast ARP Who has ? Tell Dell_b0:c4:dd -> Broadcast ARP Who has ? Tell Dell_b0:c4:dd -> Broadcast ARP Who has ? Tell Dell_b0:c4:dd -> Broadcast ARP Who has ? Tell Dell_b0:c4:dd -> Broadcast ARP Who has ? Tell Dell_b0:c4:dd -> Broadcast ARP Who has ? Tell Dell_b0:c4:dd -> Broadcast ARP Who has ? Tell Dell_b0:c4:dd -> Broadcast ARP Who has ? Tell Dell_b0:c4:dd -> Broadcast ARP Who has ? Tell Dell_b0:c4:dd -> Broadcast ARP Who has ? Tell Dell_b0:c4:dd -> Broadcast ARP Who has ? Tell Dell_b0:c4:dd -> Broadcast ARP Who has ? Tell Dell_b0:c4:dd -> Broadcast ARP Who has ? Tell Dell_b0:c4:dd -> Broadcast ARP Who has ? Tell Dell_b0:c4:dd -> Broadcast ARP Who has ? Tell Dell_b0:c4:dd -> Broadcast ARP Who has ? Tell Dell_b0:c4:dd -> Broadcast ARP Who has ? Tell Dell_b0:c4:dd -> Broadcast ARP Who has ? Tell Dell_b0:c4:dd -> Broadcast ARP Who has ? Tell Dell_b0:c4:dd -> Broadcast ARP Who has ? Tell Dell_b0:c4:dd -> Broadcast ARP Who has ? Tell Dell_b0:c4:dd -> Broadcast ARP Who has ? Tell Dell_b0:c4:dd -> Broadcast ARP Who has ? Tell Dell_b0:c4:dd -> Broadcast ARP Who has ? Tell

69 6.14 Annexe 14 - Fichier de configuration de collectd # # Config file for collectd(1). # Please read collectd.conf(5) for a list of options. # # #Hostname "localhost" FQDNLookup true #BaseDir "/usr/var/lib/collectd" PIDFile "/home/tpanel/collectd/run/collectd.pid" #PluginDir "/usr/lib/collectd" #TypesDB "/usr/lib/collectd/types.db" #TypesDB "/home/tpanel/collectd/etc/types.db" #Interval 10 #ReadThreads 5 LoadPlugin logfile #LoadPlugin syslog <Plugin logfile> LogLevel info File STDOUT Timestamp true </Plugin> #<Plugin syslog> # LogLevel info #</Plugin> #These are the plugins we are using right now LoadPlugin cpu LoadPlugin df LoadPlugin exec LoadPlugin interface LoadPlugin load LoadPlugin memory LoadPlugin network LoadPlugin nfs LoadPlugin processes LoadPlugin rrdtool LoadPlugin swap #These are the plugins which might be used in the future #LoadPlugin tcpconns #These are the default plugins included with collectd #LoadPlugin apcups #LoadPlugin apple_sensors #LoadPlugin ascent #LoadPlugin battery #LoadPlugin cpufreq #LoadPlugin csv #LoadPlugin disk #LoadPlugin entropy #LoadPlugin filecount #LoadPlugin hddtemp 69

70 #LoadPlugin iptables #LoadPlugin ipvs #LoadPlugin irq #LoadPlugin mbmon #LoadPlugin memcached #LoadPlugin multimeter #LoadPlugin netlink #LoadPlugin notify_desktop #LoadPlugin notify_ #LoadPlugin ntpd #LoadPlugin onewire #LoadPlugin ping #LoadPlugin powerdns #LoadPlugin serial #LoadPlugin tail #LoadPlugin tape #LoadPlugin teamspeak2 #LoadPlugin thermal #LoadPlugin unixsock #LoadPlugin users #LoadPlugin uuid #LoadPlugin vmem #LoadPlugin vserver #LoadPlugin wireless #LoadPlugin xmms #<Plugin apache> # URL " # User "www-user" # Password "secret" # CACert "/etc/ssl/ca.crt" #</Plugin> #<Plugin apcups> # Host "localhost" # Port "3551" #</Plugin> #<Plugin ascent> # URL " # User "www-user" # Password "secret" # CACert "/etc/ssl/ca.crt" #</Plugin> #<Plugin csv> #DataDir "/home/tpanel/collectd/csv" #DataDir "/usr/var/lib/collectd/csv" #StoreRates false #</Plugin> #<Plugin df> # Device "/dev/hda1" # Device " :/mnt/nfs" # MountPoint "/localdisk" # MountPoint "/scratch" # MountPoint "/home" # MountPoint "/group" 70

71 # MountPoint "/sw" # MountPoint "/daqarea" # MountPoint "/userbackup" # FSType "ext3" # IgnoreSelected false #</Plugin> #<Plugin disk> # Disk "/^[hs]d[a-f][0-9]?$/" # IgnoreSelected false #</Plugin> #<Plugin dns> # Interface "eth0" # IgnoreSource " " #</Plugin> #<Plugin > # SocketFile "/usr/var/run/collectd- " # SocketGroup "collectd" # SocketPerms "0770" # MaxConns 5 #</Plugin> <Plugin exec> # Exec "user:group" "/path/to/exec" # NotificationExec "user:group" "/path/to/exec" Exec tpanel "/home/tpanel/collectd/etc/df-used.sh" # Exec tpanel "/home/tpanel/collectd/etc/cpu-avg.sh" </Plugin> #<Plugin filecount> # <Directory "/path/to/dir"> # Instance "foodir" # Name "*.conf" # MTime "-5m" # Size "+10k" # </Directory> #</Plugin> #<Plugin hddtemp> # Host " " # Port "7634" # TranslateDevicename false #</Plugin> #<Plugin interface> # Interface "eth0" # Interface "eth1" # IgnoreSelected false #</Plugin> #<Plugin iptables> # Chain table chain #</Plugin> #<Plugin irq> # Irq 7 71

72 # Irq 8 # Irq 9 # IgnoreSelected true #</Plugin> #<Plugin libvirt> # Connection "xen:///" # RefreshInterval 60 # Domain "name" # BlockDevice "name:device" # InterfaceDevice "name:device" # IgnoreSelected false # HostnameFormat name #</Plugin> #<Plugin mbmon> # Host " " # Port "411" #</Plugin> #<Plugin memcached> # Host " " # Port "11211" #</Plugin> #<Plugin mysql> # Host "database.serv.er" # User "db_user" # Password "secret" # Database "db_name" #</Plugin> #<Plugin netlink> # Interface "eth0" # Interface "eth1" # Interface "All" # VerboseInterface "eth0" # VerboseInterface "eth1" # QDisc "eth0" "pfifo_fast-1:0" # Class "ppp0" "htb-1:10" # Filter "ppp0" "u32-1:0" # IgnoreSelected false #</Plugin> <Plugin network> Listen " " # Server "ff18::efc0:4a42" "25826" # Server " " "25826" # Listen "ff18::efc0:4a42" "25826" # Listen " " "25826" TimeToLive "128" # Forward false # CacheFlush 1800 </Plugin> #<Plugin nginx> # URL " # User "www-user" 72

73 # Password "secret" # CACert "/etc/ssl/ca.crt" #</Plugin> #<Plugin notify_desktop> # OkayTimeout 1000 # WarningTimeout 5000 # FailureTimeout 0 #</Plugin> #<Plugin notify_ > # SMTPServer "localhost" # SMTPPort 25 # SMTPUser "my-username" # SMTPPassword "my-password" # From "[email protected]" # # <WARNING/FAILURE/OK> on <hostname>. beware! do not use not more than two %s in this string!!! # Subject "Aaaaaa!! %s on %s!!!!!" # Recipient " [email protected]" # Recipient " [email protected]" #</Plugin> #<Plugin ntpd> # Host "localhost" # Port 123 # ReverseLookups false #</Plugin> #<Plugin nut> # UPS "upsname@hostname:port" #</Plugin> #<Plugin onewire> # Device "-s localhost:4304" # Sensor "F10FCA000800" # IgnoreSelected false #</Plugin> #<Plugin perl> # IncludeDir "/my/include/path" # BaseName "Collectd::Plugin" # EnableDebugger "" # LoadPlugin foo # # <Plugin foo> # Foo "Bar" # Qux "Baz" # </Plugin> #</Plugin> #<Plugin ping> # Host "host.foo.bar" # TTL 255 #</Plugin> #<Plugin postgresql> # <Query magic> 73

74 # Query "SELECT magic, spells FROM wizard WHERE host = $1;" # Param hostname # Column gauge magic # Column counter spells # </Query> # # <Database foo> # Host "hostname" # Port 5432 # User "username" # Password "secret" # # SSLMode "prefer" # KRBSrvName "kerberos_service_name" # # Query magic # </Database> # # <Database bar> # Service "service_name" # </Database> #</Plugin> #<Plugin powerdns> # <Server "server_name"> # Collect "latency" # Collect "udp-answers" "udp-queries" # Socket "/var/run/pdns.controlsocket" # </Server> # <Recursor "recursor_name"> # Collect "questions" # Collect "cache-hits" "cache-misses" # Socket "/var/run/pdns_recursor.controlsocket" # </Recursor> # LocalSocket "/opt/collectd/var/run/collectd-powerdns" #</Plugin> #<Plugin processes> # Process "name" #</Plugin> <Plugin rrdtool> DataDir "/home/tpanel/collectd/rrd" CacheTimeout 120 CacheFlush 900 </Plugin> #<Plugin sensors> # Sensor "it8712-isa-0290/temperature-temp1" # Sensor "it8712-isa-0290/fanspeed-fan3" # Sensor "it8712-isa-0290/voltage-in8" # IgnoreSelected false #</Plugin> #<Plugin snmp> # <Data "powerplus_voltge_input"> # Type "voltage" # Table false 74

75 # Instance "input_line1" # Values "SNMPv2-SMI::enterprises " # </Data> # <Data "hr_users"> # Type "users" # Table false # Instance "" # Values "HOST-RESOURCES-MIB::hrSystemNumUsers.0" # </Data> # <Data "std_traffic"> # Type "if_octets" # Table true # Instance "IF-MIB::ifDescr" # Values "IF-MIB::ifInOctets" "IF-MIB::ifOutOctets" # </Data> # # <Host "some.switch.mydomain.org"> # Address " " # Version 1 # Community "community_string" # Collect "std_traffic" # Inverval 120 # </Host> # <Host "some.server.mydomain.org"> # Address " " # Version 2 # Community "another_string" # Collect "std_traffic" "hr_users" # </Host> # <Host "some.ups.mydomain.org"> # Address " " # Version 1 # Community "more_communities" # Collect "powerplus_voltge_input" # Interval 300 # </Host> #</Plugin> #<Plugin "tail"> # <File "/var/log/exim4/mainlog"> # Instance "exim" # <Match> # Regex "S=([1-9][0-9]*)" # DSType "CounterAdd" # Type "ipt_bytes" # Instance "total" # </Match> # <Match> # Regex "\\<R=local_user\\>" # DSType "CounterInc" # Type "counter" # Instance "local_user" # </Match> # </File> #</Plugin> #<Plugin tcpconns> # ListeningPorts false 75

76 # LocalPort "25" # RemotePort "25" #</Plugin> #<Plugin teamspeak2> # Host " " # Port "51234" # Server "8767" #</Plugin> #<Plugin thermal> # ForceUseProcfs false # Device "THRM" # IgnoreSelected false #</Plugin> #<Plugin unixsock> # SocketFile "/home/tpanel/collectd/collectd-unixsock" # SocketGroup "collectd" # SocketPerms "0666" #</Plugin> #<Plugin uuid> # UUIDFile "/etc/uuid" #</Plugin> #<Plugin vmem> # Verbose false #</Plugin> Include "/etc/collectd.d" 76

77 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 #!/bin/bash #Récupération du nom de l'hôte HOSTNAME="${COLLECTD_HOSTNAME:-`hostname -f`}" #Définition de l'intervalle entre chaque exécution du script INTERVAL="${COLLECTD_INTERVAL:-10}" while sleep "$INTERVAL" do #Récupération de la date actuelle timestamp="`date +%s`" #Récupération dans un tableau, des statistiques voulues res=(`mpstat sed '1,3d'`) #Affectation des valeurs du tableau aux variables IdleAvg=${res[10]} InterruptAvg=${res[7]} NiceAvg=${res[4]} SoftIRQAvg=${res[8]} StealAvg=${res[9]} SysAvg=${res[5]} UserAvg=${res[3]} IOWaitAvg=${res[6]} #Renvoie d'une phrase qui sera interprétée comme une commande de telle #manière que les résultats soient enregistrés dans des fichiers RRD echo "PUTVAL $HOSTNAME/exec-avg/gauge-idle interval=$interval $timestamp:$idleavg" echo "PUTVAL $HOSTNAME/exec-avg/gauge-interrupt interval=$interval $timestamp:$interruptavg" echo "PUTVAL $HOSTNAME/exec-avg/gauge-nice interval=$interval $timestamp:$niceavg" echo "PUTVAL $HOSTNAME/exec-avg/gauge-softirq interval=$interval $timestamp:$softirqavg" echo "PUTVAL $HOSTNAME/exec-avg/gauge-steal interval=$interval $timestamp:$stealavg" echo "PUTVAL $HOSTNAME/exec-avg/gauge-system interval=$interval $timestamp:$sysavg" echo "PUTVAL $HOSTNAME/exec-avg/gauge-user interval=$interval $timestamp:$useravg" echo "PUTVAL $HOSTNAME/exec-avg/gauge-wait interval=$interval $timestamp:$iowaitavg" done 77

78 6.16 Annexe 16 - Plugin "df-used.sh" permettant de récupérer le pourcentage d'utilisation de différentes partitions #!/bin/bash #Récupération du nom de l'hôte HOSTNAME="${COLLECTD_HOSTNAME:-`hostname -f`}" #Définition de l'intervalle entre chaque exécution du script INTERVAL="${COLLECTD_INTERVAL:-10}" while sleep "$INTERVAL" do #Récupération de la date actuelle timestamp="`date +%s`" #Récupération des statistiques voulues dans les différentes variables DAQAreaUsed=$(df -h /daqarea awk '{print $5}' egrep ^[0-9]\{1,3\} sed -e s/%//); GroupUsed=$(df -h /group awk '{print $4}' egrep ^[0-9]\{1,3\} sed - e s/%//); HomeUsed=$(df -h /home awk '{print $4}' egrep ^[0-9]\{1,3\} sed -e s/%//); ScratchUsed=$(df -h /scratch awk '{print $4}' egrep ^[0-9]\{1,3\} sed -e s/%//); SWUsed=$(df -h /sw awk '{print $4}' egrep ^[0-9]\{1,3\} sed -e s/%//); UserBackupUsed=$(df -h /userbackup awk '{print $4}' egrep ^[0-9]\{1,3\} sed -e s/%//); #Renvoie d'une phrase qui sera interprétée comme une commande de telle #manière que les résultats soient enregistrés dans des fichiers RRD echo "PUTVAL $HOSTNAME/df-used/df-used-daqarea interval=$interval $timestamp:$daqareaused" #echo "PUTVAL $HOSTNAME/df-used/df-used-daqarea interval=$interval $timestamp:0:$daqareaused" #echo "PUTVAL $HOSTNAME/df-used/df-used-group interval=$interval $timestamp:0:$groupused" #echo "PUTVAL $HOSTNAME/df-used/df-used-home interval=$interval $timestamp:0:$homeused" #echo "PUTVAL $HOSTNAME/df-used/df-used-scratch interval=$interval $timestamp:0:$scratchused" #echo "PUTVAL $HOSTNAME/df-used/df-used-sw interval=$interval $timestamp:0:$swused" #echo "PUTVAL $HOSTNAME/df-used/df-used-userbackup interval=$interval $timestamp:0:$userbackupused" done 78

79 6.17 Annexe 17 - Architecture des graphiques : jarmon_recipes.js (extrait) /* Copyright (c) 2010 Richard Wall <richard (at) the-moon.net> * See LICENSE for details. * * Some example recipes for Collectd RRD data - you *will* need to modify this * based on the RRD data available on your system. */ if(typeof jarmon == 'undefined') { var jarmon = {}; } jarmon.collectd_recipes = { // Here we put all the shared metrics 'df_shared': [ { title: 'df % used', data: [ ['data/vmstudent05.lbdaq.cern.ch/df-used/df-useddaqarea.rrd', 'free', '/daqarea', '%'], ['data/vmstudent05.lbdaq.cern.ch/df-used/df-usedgroup.rrd', 'free', '/group', '%'], ['data/vmstudent05.lbdaq.cern.ch/df-used/df-usedhome.rrd', 'free', '/home', '%'], ['data/vmstudent05.lbdaq.cern.ch/df-used/df-usedscratch.rrd', 'free', '/scratch', '%'], ['data/vmstudent05.lbdaq.cern.ch/df-used/df-used-sw.rrd', 'free', '/sw', '%'], ['data/vmstudent05.lbdaq.cern.ch/df-used/df-useduserbackup.rrd', 'free', '/userbackup', '%'] ], options: jquery.extend(true, {}, jarmon.chart.base_options) } ], // Here we put all the metrics by category for all the hosts //CPU : 'cpu': [ { title: 'Store01 CPU Usage', data: [ ['data/st01/exec-avg/gauge-idle.rrd', 0, 'Idle', 'Jiffies'], ['data/st01/exec-avg/gauge-interrupt.rrd', 0, 'Interrupt', 'Jiffies'], ['data/st01/exec-avg/gauge-nice.rrd', 0, 'Nice', 'Jiffies'], ['data/st01/exec-avg/gauge-softirq.rrd', 0, 'SoftIRQ', 'Jiffies'], ['data/st01/exec-avg/gauge-steal.rrd', 0, 'Steal', 'Jiffies'], ['data/st01/exec-avg/gauge-system.rrd', 0, 'System', 'Jiffies'], 79

80 'Jiffies'], 'Jiffies'] }, ['data/st01/exec-avg/gauge-user.rrd', 0, 'User', ['data/st01/exec-avg/gauge-wait.rrd', 0, 'Wait', ], options: jquery.extend(true, {}, jarmon.chart.base_options, jarmon.chart.stacked_options) { title: 'Store02 CPU Usage', data: [ ['data/st02/exec-avg/gauge-idle.rrd', 0, 'Idle', 'Jiffies'], ['data/st02/exec-avg/gauge-interrupt.rrd', 0, 'Interrupt', 'Jiffies'], ['data/st02/exec-avg/gauge-nice.rrd', 0, 'Nice', 'Jiffies'], ['data/st02/exec-avg/gauge-softirq.rrd', 0, 'SoftIRQ', 'Jiffies'], ['data/st02/exec-avg/gauge-steal.rrd', 0, 'Steal', 'Jiffies'], ['data/st02/exec-avg/gauge-system.rrd', 0, 'System', 'Jiffies'], ['data/st02/exec-avg/gauge-user.rrd', 0, 'User', 'Jiffies'], ['data/st02/exec-avg/gauge-wait.rrd', 0, 'Wait', 'Jiffies'] ], options: jquery.extend(true, {}, jarmon.chart.base_options, jarmon.chart.stacked_options) }, { title: 'Store03 CPU Usage', data: [ ['data/st03/exec-avg/gauge-idle.rrd', 0, 'Idle', 'Jiffies'], ['data/st03/exec-avg/gauge-interrupt.rrd', 0, 'Interrupt', 'Jiffies'], ['data/st03/exec-avg/gauge-nice.rrd', 0, 'Nice', 'Jiffies'], ['data/st03/exec-avg/gauge-softirq.rrd', 0, 'SoftIRQ', 'Jiffies'], ['data/st03/exec-avg/gauge-steal.rrd', 0, 'Steal', 'Jiffies'], ['data/st03/exec-avg/gauge-system.rrd', 0, 'System', 'Jiffies'], ['data/st03/exec-avg/gauge-user.rrd', 0, 'User', 'Jiffies'], ['data/st03/exec-avg/gauge-wait.rrd', 0, 'Wait', 'Jiffies'] ], options: jquery.extend(true, {}, jarmon.chart.base_options, jarmon.chart.stacked_options) }, { 80

81 title: 'Store04 CPU Usage', data: [ ['data/st04/exec-avg/gauge-idle.rrd', 0, 'Idle', 'Jiffies'], ['data/st04/exec-avg/gauge-interrupt.rrd', 0, 'Interrupt', 'Jiffies'], ['data/st04/exec-avg/gauge-nice.rrd', 0, 'Nice', 'Jiffies'], ['data/st04/exec-avg/gauge-softirq.rrd', 0, 'SoftIRQ', 'Jiffies'], ['data/st04/exec-avg/gauge-steal.rrd', 0, 'Steal', 'Jiffies'], ['data/st04/exec-avg/gauge-system.rrd', 0, 'System', 'Jiffies'], ['data/st04/exec-avg/gauge-user.rrd', 0, 'User', 'Jiffies'], ['data/st04/exec-avg/gauge-wait.rrd', 0, 'Wait', 'Jiffies'] ], options: jquery.extend(true, {}, jarmon.chart.base_options, jarmon.chart.stacked_options) }, { title: 'Store05 CPU Usage', data: [ ['data/st05/exec-avg/gauge-idle.rrd', 0, 'Idle', 'Jiffies'], ['data/st05/exec-avg/gauge-interrupt.rrd', 0, 'Interrupt', 'Jiffies'], ['data/st05/exec-avg/gauge-nice.rrd', 0, 'Nice', 'Jiffies'], ['data/st05/exec-avg/gauge-softirq.rrd', 0, 'SoftIRQ', 'Jiffies'], ['data/st05/exec-avg/gauge-steal.rrd', 0, 'Steal', 'Jiffies'], ['data/st05/exec-avg/gauge-system.rrd', 0, 'System', 'Jiffies'], ['data/st05/exec-avg/gauge-user.rrd', 0, 'User', 'Jiffies'], ['data/st05/exec-avg/gauge-wait.rrd', 0, 'Wait', 'Jiffies'] ], options: jquery.extend(true, {}, jarmon.chart.base_options, jarmon.chart.stacked_options) } ], (Fin de l'extrait du fichier) 81

82 6.18 Annexe 18 - Agencement des éléments : index.html <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" " <html xmlns=" xml:lang="en" lang="en"> <head> <meta http-equiv="content-type" content="text/html;charset=utf-8" /> <title>jarmon - LHCb Monitoring</title> <link rel="stylesheet" type="text/css" href="assets/css/style.css" /> <link rel="stylesheet" type="text/css" href="assets/css/tabs-noimages.css" /> <link rel="stylesheet" type="text/css" href="assets/css/jquerytools.dateinput.skin1.css" /> <script type="text/javascript" src="assets/js/dependencies.js"></script> <script type="text/javascript" src="jarmon.js"></script> <script type="text/javascript" src="docs/jarmon_recipes.js"></script> <script type="text/javascript"> // Recipes for the charts on this page function initialisecharts() { /** * Setup chart date range controls and all charts **/ var p = new jarmon.parallimiter(1); function serialdownloader(url) { return p.addcallable(jarmon.downloadbinary, [url]); } // Extract the chart template from the page var charttemplate = $('.chart-container').remove(); early, so function templatefactory(parentel) { return function() { // The chart template must be appended to the page } } // that flot can calculate chart dimensions etc. return charttemplate.clone().appendto(parentel); var cc = new jarmon.chartcoordinator($('.chartrangecontrol')); var t; // Initialise tabs and update charts when tab is clicked $(".css-tabs:first").bind('click', function(i) { // XXX: Hack to give the tab just enough time to become visible // so that flot can calculate chart dimensions. window.cleartimeout(t); 82

83 }); t = window.settimeout(function() { cc.update(); }, 100); cc.charts = [].concat( jarmon.chart.fromrecipe( jarmon.collectd_recipes.df_shared, templatefactory('.shared-charts'), serialdownloader), jarmon.chart.fromrecipe( jarmon.collectd_recipes.cpu, templatefactory('.cpu-charts'), serialdownloader), jarmon.chart.fromrecipe( jarmon.collectd_recipes.df_local, templatefactory('.df-charts'), serialdownloader), jarmon.chart.fromrecipe( jarmon.collectd_recipes.iftraffic, templatefactory('.if_traffic-charts'), serialdownloader), jarmon.chart.fromrecipe( jarmon.collectd_recipes.ifpkts, templatefactory('.if_pkts-charts'), serialdownloader), jarmon.chart.fromrecipe( jarmon.collectd_recipes.iferrs, templatefactory('.if_errs-charts'), serialdownloader), jarmon.chart.fromrecipe( jarmon.collectd_recipes.sysload, templatefactory('.load-charts'), serialdownloader), jarmon.chart.fromrecipe( jarmon.collectd_recipes.memory, templatefactory('.memory-charts'), serialdownloader), jarmon.chart.fromrecipe( jarmon.collectd_recipes.nfsv3, templatefactory('.nfs-charts'), serialdownloader), jarmon.chart.fromrecipe( jarmon.collectd_recipes.processes, templatefactory('.processes-charts'), serialdownloader), jarmon.chart.fromrecipe( jarmon.collectd_recipes.swap, templatefactory('.swap-charts'), serialdownloader) ); } // Initialise all the charts cc.init(); $(function() { // Add dhtml calendars to the date input fields $(".timerange_control img").dateinput({ 'format': 'dd mmm yyyy 00:00:00', 'max': +1, 'css': {'input': 'jquerytools_date'}}).bind('onbeforeshow', function(e) { var classes = $(this).attr('class').split(' '); var currentdate, input_selector; for(var i=0; i<=classes.length; i++) { 83

84 name matches the date.gettime input_selector = '[name="' + classes[i] + '"]'; // Look for a neighboring input element whose // class name of this calendar // Parse the value as a date if the returned // returns NaN we know it's an invalid date // XXX: is there a better way to check for valid date? currentdate = new Date($(this).siblings(input_selector).val()); if(currentdate.gettime()!= NaN) { $(this).data('dateinput')._input_selector = input_selector; $(this).data('dateinput')._initial_val = currentdate.gettime(); $(this).data('dateinput').setvalue(currentdate); break; } } }).bind('onhide', function(e) { // Called after a calendar date has been chosen by the user. // Use the sibling selector that we generated above before opening // the calendar var input_selector = $(this).data('dateinput')._input_selector; var oldstamp = $(this).data('dateinput')._initial_val; var newdate = $(this).data('dateinput').getvalue(); // Only update the form field if the date has changed. if(oldstamp!= newdate.gettime()) { $(this).siblings(input_selector).val( newdate.tostring().split(' ').slice(1,5).join(' ')); // Trigger a change event which should automatically update the // graphs and change the timerange drop down selector to // "custom" $(this).siblings(input_selector).trigger('change'); } }); // Avoid overlaps between the calendars // XXX: This is a bit of hack, what if there's more than one set of calendar // controls on a page? $(".timerange_control img.from_custom").bind('onbeforeshow', function() { var otherval = new Date( 84

85 $('.timerange_control [name="to_custom"]').val()); $(this).data('dateinput').setmax(otherval); } ); $(".timerange_control img.to_custom").bind('onbeforeshow', function() { var otherval = new Date( $('.timerange_control [name="from_custom"]').val()); ); } $(this).data('dateinput').setmin(otherval); // Setup dhtml tabs $(".css-tabs").tabs(".css-panes > div", {history: true}); initialisecharts(); }); </script> </head> <body> <div class="chartrangecontrol"> <div> <h1>jarmon - LHCb Monitoring</h1> </div> <ul class="css-tabs"> <li><a href="#shared_metrics">shared</a></li> <li><a href="#cpu">cpu</a></li> <li><a href="#df">local disks</a></li> <li><a href="#iftraffic">if-traffic</a></li> <li><a href="#ifpkts">if-packets</a></li> <li><a href="#iferrs">if-errors</a></li> <li><a href="#load">load</a></li> <li><a href="#memory">memory</a></li> <li><a href="#nfs">nfs</a></li> <li><a href="#processes">processes</a></li> <li><a href="#swap">swap</a></li> </ul> <div class="css-panes charts"> <div class="shared-charts"> <h2>backups<h2> <div> <table class="backup"> <tr> <td id="dailybackup" class="bcktd"></td> <td id="hourlybackup" class="bcktd"></td> </tr> </table> </div> <script> $('#dailybackup').load('assets/ajax/dbackupdata.txt'); </script> 85

86 <script> $('#hourlybackup').load('assets/ajax/hbackupdata.txt'); </script> </div> <div class="cpu-charts"></div> <div class="df-charts"></div> <div class="if_traffic-charts"></div> <div class="if_pkts-charts"></div> <div class="if_errs-charts"></div> <div class="load-charts"></div> <div class="memory-charts"></div> <div class="nfs-charts"></div> <div class="processes-charts"></div> <div class="swap-charts"></div> </div> <div class="chart-container"> <h2 class="title"></h2> <div class="chart"></div> <div class="graph-legend"></div> </div> <div class="timeselection"> <form> <div> <span class="timerange_control custom"> <img src="assets/icons/calendar.png" width="16" height="16" alt="calendar" class="from_custom" title="click to choose a custom start date" /> <input name="from_custom" type="text" readonly="readonly" title="time range start" /> <img src="assets/icons/calendar.png" width="16" height="16" alt="calendar" class="to_custom" title="click to choose a custom end date" /> <input name="to_custom" type="text" readonly="readonly" title="time range end" /> </span> <span class="timerange_control standard"> <select name="from_standard" title="time range shortcuts - click to select an alternative time range" > </select> </span> <input name="from" type="hidden" /> <input name="to" type="hidden" /> <input name="action" value="update" type="button" title="graph update - click to update all graphs" /> <select name="tzoffset" style="visibility:hidden"; title="timezone offset - click to choose a custom timezone offset" ></select> </div> <div class="range-preview" 86

87 title="time range preview - click and drag to select a custom timerange" ></div> </form> </div> </div> </body> </html> 87

88 6.19 Annexe 19 - Script de vérification des "Hourly backups" : checkhourlybackups.py import os import glob import stat import time import datetime rawdatafile = open("/home/tpanel/collectd/web/jarmon/assets/ajax/hbackupdata.txt", "w") def f_count(dir_name): file_count = 0 for root, dirs, files in os.walk(dir_name): file_count += (len(files) + len(dirs)) if file_count >= : print "This backup seems to be ok (more than files here)." rawdatafile.write("\t\t<td><img src=\"assets/icons/ok.png\" title=\"backup ok, more than files...\" alt=\"the backup is ok\"></td>\n") print " \n\n" break if file_count < : print "There might be a problem : there are less than files in this backup" print "This backup contains %d fles." % (file_count) rawdatafile.write("\t\t<td><img src=\"assets/icons/check.png\" title=\"backup needs to be checked, less than files...\" alt=\"the backup needs to be checked\"></td>\n") print " \n\n" def checkhourlybackup(path): hourly_list = glob.glob1(path,"hourly.*") hourly_list.sort() if hourly_list == []: print "No hourly-backup here...\n" rawdatafile.write("\t\t<td><img src=\"assets/icons/notfound.png\" title=\"backup not found...\" alt=\"backup not found\"></td>\n\t\t<td><img src=\"assets/icons/notfound.png\" title=\"backup not found...\" alt=\"backup not found\"></td>\n\t\t<td><img src=\"assets/icons/notfound.png\" title=\"backup not found...\" alt=\"backup not found\"></td>\n\t\t<td><img src=\"assets/icons/notfound.png\" title=\"backup not found...\" alt=\"backup not found\"></td>\n") elif len(hourly_list) < 4: print "Some backup directories are missing because the backup is in progress...\n" rawdatafile.write("\t\t<td><img src=\"assets/icons/progress.png\" title=\"backup in progress...\" alt=\"backup in progress\"></td>\n\t\t<td><img src=\"assets/icons/progress.png\" title=\"backup in progress...\" alt=\"backup in 88

89 progress\"></td>\n\t\t<td><img src=\"assets/icons/progress.png\" title=\"backup in progress...\" alt=\"backup in progress\"></td>\n\t\t<td><img src=\"assets/icons/progress.png\" title=\"backup in progress...\" alt=\"backup in progress\"></td>\n") else: for file in hourly_list: fullpath = os.path.join(path,file) if os.path.isdir(fullpath): file_stats = os.stat(fullpath) file_info = { 'fname': file, 'f_lm': time.strftime("%m/%d/%y %I:%M:%S %p",time.localtime(file_stats[stat.st_mtime])), 'f_la': time.strftime("%m/%d/%y %I:%M:%S %p",time.localtime(file_stats[stat.st_atime])) } fi_na = "%(fname)s \n" % file_info lmodf = "Last modified = %(f_lm)s \n" % file_info laccs = "Last accessed = %(f_la)s \n" % file_info resul = fi_na + lmodf + laccs if file == "hourly.0": " print " print "Info on : " + resul h0comp = datetime.datetime.now() h0str1 = h0comp.strftime("%y%m%d%i%m%s") h0compint1 = int(h0str1) # 7000 coressponds to 7 hours h0str2 = time.strftime("%y%m%d%i%m%s",time.localtime(file_stats[stat.st_mtime])) h0compint2 = int(h0str2) than 6 hours ago." be ok..." if h0compint1 < h0compint2: print "This hourly-backup has been modified less print "Checking if the backup's content seems to f_count(fullpath) else: print "This hourly-backup has been modified more than 6 hours ago.\nit should be checked." rawdatafile.write("\t\t<td><img src=\"assets/icons/nok.png\" title=\"backup has not been made\" alt=\"backup has not been made\"></td>\n") print " \n\n" elif file == "hourly.1": " print "

90 print "Info on : " + resul h1comp = datetime.datetime.now() h1str1 = h1comp.strftime("%y%m%d%i%m%s") h1compint1 = int(h1str1) # corresponds to 13 hours h1str2 = time.strftime("%y%m%d%i%m%s",time.localtime(file_stats[stat.st_mtime])) h1compint2 = int(h1str2) than 12 hours ago." be ok..." if h1compint1 < h1compint2: print "This hourly-backup has been modified less print "Checking if the backup's content seems to f_count(fullpath) else: print "This hourly-backup has been modified more than 12 hours ago.\nit should be checked." rawdatafile.write("\t\t<td><img src=\"assets/icons/nok.png\" title=\"backup has not been made\" alt=\"backup has not been made\"></td>\n") print " \n\n" elif file == "hourly.2": " print " print "Info on : " + resul h2comp = datetime.datetime.now() h2str1 = h2comp.strftime("%y%m%d%i%m%s") h2compint1 = int(h2str1) # corresponds to 19 hours h2str2 = time.strftime("%y%m%d%i%m%s",time.localtime(file_stats[stat.st_mtime])) h2compint2 = int(h2str2) than 18 hours ago." be ok..." if h2compint1 < h2compint2: print "This hourly-backup has been modified less print "Checking if the backup's content seems to f_count(fullpath) else: print "This hourly-backup has been modified more than 18 hours ago.\nit should be checked." rawdatafile.write("\t\t<td><img src=\"assets/icons/nok.png\" title=\"backup has not been made\" alt=\"backup has not been made\"></td>\n") print " \n\n" elif file == "hourly.3": 90

91 " print " print "Info on : " + resul h3comp = datetime.datetime.now() h3str1 = h3comp.strftime("%y%m%d%i%m%s") h3compint1 = int(h3str1) # corresponds to 1 day and 1 hour h3str2 = time.strftime("%y%m%d%i%m%s",time.localtime(file_stats[stat.st_mtime])) h3compint2 = int(h3str2) than 1 day ago." be ok..." if h3compint1 < h3compint2: print "This hourly-backup has been modified less print "Checking if the backup's content seems to f_count(fullpath) else: print "This hourly-backup has been modified more than 1 day ago.\nit should be checked." rawdatafile.write("\t\t<td><img src=\"assets/icons/nok.png\" title=\"backup has not been made\" alt=\"backup has not been made\"></td>\n") print " \n\n" if name == ' main ': path1 = '/userbackup/group/' path2 = '/userbackup/home/' print " " print " " print " Checking in \"%s\" " % (path1) print " " print " " print "" rawdatafile.write("<table cellspacing=\"1\">\n\t<tr>\n\t\t<td class=\"toprow\">hourlybackups</td>\n\t\t<td>hourly.0</td>\n\t\t<td>hourl y.1</td>\n\t\t<td>hourly.2</td>\n\t\t<td>hourly.3</td>\n\t</tr>\n\t<tr>\n \t\t<td class=\"grhm\">/group</td>\n") checkhourlybackup(path1) rawdatafile.write("\t</tr>\n") print " " print " " print " Checking in \"%s\" " % (path2) print " " print " " print "" rawdatafile.write("\t<tr>\n\t\t<td class=\"grhm\">/home</td>\n") 91

92 checkhourlybackup(path2) rawdatafile.write("\t</tr>\n</table>") rawdatafile.close() print " " print " The checkup for the hourly-backups is now finished. " print " " 92

93 L'entreprise : Le CERN (Organisation Européenne pour la Recherche Nucléaire) a été fondé en 1954, par douze États européens. Cette organisation constitue l'un des plus grands et importants laboratoires de recherches en physique des particules, dans le monde. 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 tuteur : Mr. NEUFELD Niko est chef adjoint du projet Online de l expérience LHCb. Il est, entre autres, responsable de l acquisition des données et de l ensemble de l infrastructure informatique de l expérience LHCb. Résumé Ce rapport vise à exposer les travaux que j'ai réalisés pour l'expérience LHCb, durant mes cinq mois de stage au CERN. Les deux projets que j'ai eu à mener y sont détaillés. Le premier projet consistait en la mise en place d'un banc de test, afin de reproduire des problèmes de pertes de paquets rencontrés sur le système en production et de les résoudre. Vous trouverez ici, les différentes étapes de la réalisation de ce banc de test ainsi que, les solutions apportées pour résoudre les problèmes de pertes de paquets. Le second projet consistait à mettre en place un outil de supervision centralisé, afin de faciliter et d'améliorer la surveillance de l'ensemble du système de stockage. Ce rapport vous présentera la solution qui a été mise en place, ainsi que les avantages qu'elle présente. Abstract This report aims to present the work I have done for the LHCb experiment, during my fivemonth internship at CERN. The two projects I have conducted are detailed here. The first project involved the establishment of a bench test to, reproduce the packet loss problems encountered on the production system and fix them. You will find here, the various stages of completion of this bench test and the solutions to solve these packet loss problems. The second project's aim was to implement a centralized monitoring tool, in order to facilitate and improve the monitoring of the storage system. This report will present the solution that has been implemented, and its benefits. Mots-clés : Informatique Réseau Monitoring Sécurité Perte de paquets Banc de test Supervision Routeur Tableau de bord Système de stockage