RAPPORT DE STAGE. de 3 e année de la licence d'informatique parcours Informatique soutenu par. Marine Landrieux. le 1er septembre 2011

Dimension: px
Commencer à balayer dès la page:

Download "RAPPORT DE STAGE. de 3 e année de la licence d'informatique parcours Informatique soutenu par. Marine Landrieux. le 1er septembre 2011"

Transcription

1 UNIVERSITÉ D'ÉVRY VAL D'ESSONNE Département d'informatique RAPPORT DE STAGE de 3 e année de la licence d'informatique parcours Informatique soutenu par Marine Landrieux le 1er septembre 2011 Un outil de monitoring pour le Grid Observatory Directeur de stage Julien Nauroy Établissement d'accueil LRI Année universitaire

2 Table des matières 1 Le contexte de mon stage Présentation du LRI L'European Grid Initiative La tâche qui m'a été conée Réalisations Le fonctionnement du Grid Observatory Recherches sur le monitoring informatique Dénition Les divers outils de monitoring existants Les particularités de Shinken Mise en uvre de Shinken Création d'une conguration propre au Grid Observatory Création de sondes propres au Grid Observatory Réalisation d'une batterie de tests adaptée aux erreurs identiées dans le Grid Observatory Tests des vérications sur le système de chiers Tests des vérications de contenu de chiers Déploiement de Shinken sur la machine Grid Observatory

3 Introduction J'ai débuté mon stage au sein du LRI le 6 juin 2011 et il s'achèvera le 26 août. Au cours de ce stage, j'ai participé au projet de l'european Grid Initiative, plus particulièrement le Grid Observatory. Mon travail à consisté en l'étude des besoins de détection de panne du Grid Observatory, pour cela il m'a fallu évaluer les solutions existantes, concevoir et développer un outil adapté, principalement en Perl (langage que je ne connaissais pas avant ce stage) et m'assurer du bon fonctionnement de l'outil au sein d'un environnement de production. Ce stage s'est avéré être une expérience nouvelle pour moi. En eet, je connaissais le monde du travail en entreprise mais pas celui du travail en laboratoire de recherche. Même si mon projet n'était pas un projet de recherche, le fait qu'il soit à échelle européenne et qu'il servira pour la communauté de chercheurs m'a beaucoup impressionnée et m'a donné envie de faire un travail d'autant plus ecace. Le Grid Observatory m'a permis d'utiliser mes connaissances acquises durant mon parcours universitaire mais à une plus grande échelle. J'ai ainsi pu améliorer les compétences que j'avais déjà, en développer d'autres et en acquérir de nouvelles (notamment le langage Perl). Dans ce rapport, je commencerai par décrire le cadre de mon stage : je présenterai le LRI puis l'european Grid Initiative ainsi que la tâche qui m'a été conée. Puis j'exposerai comment j'ai rempli cette tâche en commençant par l'étude des besoins du Grid Observatory, puis mon travail de recherche en matière de surveillance informatique et comment j'ai intégré au Grid Observatory un outil de surveillance informatique déjà existant nommé Shinken. 3

4 1 Le contexte de mon stage 1.1 Présentation du LRI Le Laboratoire de Recherche en Informatique (LRI) a été créé il y a environ une trentaine d'années et est rattaché au Centre National de la Recherche Scientique (CNRS), à l'institut National de Recherche en Informatique et en Automatique (INRIA) et à l'université Paris-Sud-11. Actuellement, le LRI quitte progressivement le bâtiment 490 situé sur le Campus d'orsay pour emménager dans le Pôle Commun de Recherche en Informatique (PCRI) situé sur le plateau du Moulon. Plus de 260 personnes y travaillent, dont environ 115 permanents et 110 doctorants, le tout étant organisé en 12 équipes de recherche, une équipe administrative et une équipe technique. Les recherches du LRI abordent aussi bien des aspects fondamentaux (algorithmique, complexité, calcul quantique, optimisation combinatoire...) que des aspects appliqués (clusters et grilles de calcul, bioinformatique, systèmes d'inférence, programmation...). Le laboratoire est présent dans de nombreux projets nationaux et internationaux, notamment les projets nancés par l'agence Nationale de la Recherche (ANR) et ceux nancés par l'union Européenne. L'équipe Apprentissage et Optimisation (A&O) que j'ai rejointe dans le cadre de mon stage, travaille justement sur un de ces projets d'envergure européenne : L'European Grid Initiative. 1.2 L'European Grid Initiative L'European Grid Initiative (EGI) est une grille de calcul européenne de 100 Po de stockage et de c urs qui est le support des expériences du Large Hadron Collider (LHC). Chaque mois, l'infrastructure EGI permet la réalisation de 25 millions d'unités de calcul (ou jobs). Un job est un programme autonome traitant une sous-partie d'une expérience. L'utilisation de jobs de courte durée (typiquement 2 jours maximum, un seul c ur, quelques Go de mémoire, quelques Go d'espace disque) permet de répartir un calcul beaucoup plus important sur des milliers de machines en même temps sans avoir un besoin important de synchronicité. Un job peut concerner par exemple le traitement d'une partie des données du LHC. L'EGI est principalement utilisée pour les expériences du LHC mais est également le support de beaucoup d'autres expériences, notamment en biologie, médecine, cosmologie, etc. Le Grid Observatory est un fournisseur de services pour le projet EGI ayant pour partenaires le Laboratoire de Recherche en Informatique (LRI), l'imperial College London, l'università degli Studi del Piemonte Orientale Amedeo Avogadro et l'academia Sinica Grid Computing. D'autres institutions telles que le Laboratoire de l'accélérateur Linéaire (LAL), le GDR Architecture-Réseaux-Systèmes du CNRS, l'université Paris-Sud-11, la Région Île-de-France et la fondation Digiteo contribuent au projet du Grid Observatory. 4

5 L'objectif du Grid Observatory est de développer une vision scientique de la dynamique du comportement du réseau et de son utilisation : il réalise l'acquisition à partir de la grille des traces d'utilisation et de l'activité middleware, les anonymise et les publie sur la grille pour les rendre disponibles aux informaticiens. Ils sont publiés sous forme d'archive hebdomadaire par thème dont une copie (backup) est placée dans un espace de stockage au centre de calcul de Lyon. Le Grid Observatory comprend deux serveurs, bientôt trois, et 250 machines à partir desquelles il acquiert des données ; parmi ces 250 machines, il y en a une vingtaine sur lesquelles il a des accès plus importants. Il a une production de données de 100 à 150 Go par mois. Lorsque j'ai débuté mon stage, il n'y avait aucun moyen de détecter dans l'immédiat certains problèmes, ce qui pouvait entraîner de très grosses pertes de données, d'où la nécessité d'un outil de surveillance. Pour tenter de remédier à cela, des outils ad hoc ont été créés tels qu'une vérication de l'accessibilité du site et de surveillance d'une partie des données mais ces outils sont jugés insuisants par l'administrateur du Grid Observatory. Le système avait besoin d'un complément de surveillance manuel, ce qui nécessitait beaucoup de temps et cela pouvait générer des erreurs. 1.3 La tâche qui m'a été conée Dans le cadre de mon stage au LRI, il m'a été demandé d'étudier la faisabilité d'un outil permettant de surveiller le fonctionnement de la chaîne d'acquisition, traitement et publication du Grid Observatory, détecter les pannes et défaillances et déclencher des avertissements progressifs en fonction de la panne détectée (pouvant aller jusqu'à l'envoi d'alertes ). Les vérications doivent porter sur des informations susceptibles de trahir un problème dans le fonctionnement du système telles que l'espace disque utilisé, la date du dernier journal d'exécution, la quantité de chiers en attente de publication. Ce type d'outil est connu dans l'industrie sous le nom de monitoring informatique. 5

6 2 Réalisations Mon travail pour le Grid Observatory s'est déroulé en plusieurs étapes, que reprendra le plan de ce chapitre : tout d'abord, il a fallu analyser les besoins en surveillance spéciques à ce projet et étudier les solutions existantes an d'établir des préconisations quant au développement d'un outil adapté. Le résultat de l'analyse des besoins du Grid Observatory est présenté en section 3.1 ; l'étude des solutions existantes est présentée en section 3.2. la solution retenue a ensuite dû être développée pour répondre aux besoins du Grid Observatory puis une batterie de test adaptée aux erreurs identiées dans le Grid Observatory a été réalisée dans le but tester mon travail et de montrer le bon fonctionnement de l'outil. Les étapes du développement sont présentées en section 3.3 : la réalisation de la batterie de test est présentée en section 3.4. pour nir, la solution a été déployée sur la machine du Grid Observatory pour qu'il commence son travail de surveillance. La description du déploiement est présentée en section Le fonctionnement du Grid Observatory Figure 1 Architecture générale du Grid Observatory 6

7 Le Grid Observatory récupère régulièrement les traces d'utilisation et de l'activité middleware des diérents services de l'egi (Torque, BDII, RTM...), les anonymise et les publie une fois par semaine. La Figure 1 représente son architecture. Chaque publication est également conservée sous forme de backup. Pour chaque traitement, les scripts écrivent au fur et à mesure les actions qu'ils eectuent dans des chiers journaux (log) et les erreurs qu'ils rencontrent dans des chiers log d'erreur (err) pour permettre d'avoir un suivi de chaque traitement. Une sous partie du Grid Observatory, le Green Computing Observatory, surveille un sousensemble des machines de la grille, situées au LAL. Le Green Computing Observatory fonctionne avec les services IPMI et Ganglia : IPMI acquiert les données de la carte mère telles que la température du processeur, la consommation électrique, la vitesse des ventilateurs, etc. Ganglia permet de visualiser ces données, mais aussi de récupérer les données du système d'exploitation comme la quantité de mémoire utilisée, le débit réseau ou le nombre de programmes en exécution. La Figure 2 montre le processus d'acquision du Green Computing Observatory. Figure 2 Acquisition du Green Computing Observatory Le problème majeur du Grid Observatory est le fait qu'on ne puisse pas détecter rapidement les pannes ou les erreurs. Pour s'en rendre compte, il faut parcourir régulièrement les chiers log ainsi que les chiers produits ce qui est très coûteux en temps et peu pratique. Il est donc nécessaire de trouver ou créer un outil vériant et permettant de visualiser rapidement les états des divers services et composants du Grid Observatory. Mon premier travail a consisté à identier les sources d'informations susceptibles de poser problème sur lesquelles allaient porter les vérications : les chiers log : est-ce que le chier log existe et a un contenu, est-ce que son contenu est correct, est-ce un log récent, est-ce que le script est terminé, en cours d'exécution ou a eu un problème? 7

8 les chiers err : est-ce que le chier err existe et a un contenu, est-ce que son contenu contient des lignes qui ne sont pas reconnues comme étant des fausses erreurs? la présence de chier dans les répertoires de mise en ligne : est-ce qu'il y a bien au maximum un seul chier dans chaque répertoire, est-ce que ces chiers sont là depuis plus d'une semaine, est-ce que les chiers ont un nom correct et est-ce qu'ils ont une taille correcte? la présence de chiers dans les répertoires de backup : est-ce qu'il y a bien un seul et unique chier dans le répertoire de backup, est-ce que le chier backup a un nom correct et un contenu, est-il récent? les chiers de la grille : est-ce qu'il y a eu des chiers publiés sur la grille récemment et est-ce que ces chiers ont une taille correcte? disponibilité de l'espace disque local : est-ce qu'il reste susamment d'espace libre sur le disque et est-ce que les chiers locaux ne prennent pas trop de place sur le disque? charge CPU d'une machine : le CPU d'une machine est-il surchargé? l'accessibilité des machines via ssh : est-ce que l'on peut se connecter en ssh à toutes les machines ou à une machine gurant dans le chier de conguration? visibilité des machines sur le réseau : est-ce que les machines répondent à la commande ping? l'accessibilité de la base de données : est-ce que l'on peut se connecter à la base de données? 2.2 Recherches sur le monitoring informatique Mes recherches sur le monitoring informatique m'ont d'abord amenée à dénir ce qu'est le monitoring. J'ai ensuite fait une liste regroupant la plupart des outils de monitoring existant actuellement puis je me suis documentée sur le fonctionnement de l'un d'eux, celui qui paraissait être le plus adapté pour répondre aux besoins du Grid Observatory : Shinken Dénition Depuis l'essor de l'informatique dans les années 90, les systèmes d'information permettent de rendre de plus en plus de services. Il a donc fallu apprendre à superviser les services et les serveurs de façon plus précise. Avant, le monitoring était proposé par les opérateurs dans le cadre de leurs ores commerciales mais maintenant il peut être pris en charge par les entreprises à moindre coût grâce à des outils gratuits. Le monitoring permet notamment de surveiller ([Mon]) : l'état physique d'une machine (température, disques). la charge d'une machine (nombre d'utilisateurs, de requêtes, la CPU, débit réseau). la disponibilité applicative (présence de processus). les messages inscrits en log systèmes. les performances du réseau (débit, latence, taux d'erreur). la nature des protocoles d'un réseau et leur taux relatif (UDP, TCP, ICMP...). les attaques connues sur un Pare-feu. les réponses protocolaires (simulation partielle d'une session). les modications. 8

9 D'après [Fau11], on peut subdiviser les outils de monitoring en deux catégories bien distinctes : la métrologie ([Met]) : correspond à de la prise de mesures et à une historisation de données à partir de ces mesures pour éventuellement en faire des graphiques, cela permet d'avoir une vision statistique du système informatique pour connaitre ses performances, son trac, détecter des situations de congestion, etc. la supervision ([Sup]) : correspond à l'analyse et au traitement des données ainsi que l'alerte en cas de situations critiques, cela permet de vérier l'état du système pour détecter des pannes ou mauvais fonctionnement Les divers outils de monitoring existants Les outils de monitoring sont très nombreux ; des recherches m'ont permis d'établir la liste des principaux outils utilisés actuellement. 1. Les outils de métrologie Cacti ([Cac]) : créé aux alentours de 2001 par The Cacti Group sous licence GNU GPL pour mesurer les performances réseau et serveur ; ses scripts sont codés en Bash, PHP, Perl, VBs... ; Cacti correspond à de la métrologie de réseau et de service, il permet de générer des alertes mais, seulement si le plugin spécique est installé et il donne la possibilité de créer ses propres scripts. Munin ([Mun]) : créé en 2004 sous licence GNU GPL pour surveiller les systèmes et les réseaux ; Munin en lui-même est codé en Perl mais ses plugins peuvent être écrits dans n'importe quel langage ; Munin correspond à de la métrologie de réseau et de service. Multi Router Trac Grapher (MRTG) ([MRT]) : créé en 2006 par Tobi Oetiker sous licence GNU GPL pour surveiller et mesurer la charge de trac sur les réseaux ; il est codé en Perl exclusivement ; MRTG correspond à de la métrologie de réseau. 2. Les outils de supervision Nagios ([Nag], [Wikb]) : créé en 1999 par Ethan Galstad sous licence GNU GPL pour assurer la surveillance des hôtes et des services en prévenant lorsqu'il y a des pannes ou des erreurs ; ses scripts sont codés en shell, C++, C#, Perl, Python, Ruby, PHP... ; Nagios correspond à de la supervision de réseau et de service, il permet de générer des alertes et il donne la possibilité de créer ses propres scripts. Voici son complément et ses forks : Centreon ([Cen]) : créé en 2005 par Merethis sous licence GNU GPL2 pour fournir à Nagios une interface d'apparence plus simple ; l'interface est codée en PHP ; Centreon correspond à de la supervision de réseau et de service, il permet de générer des alertes et il donne la possibilité de créer ses propres scripts. Icinga ([Ici]) : créé en 2009 par d'anciens développeurs de Nagios sous licence GNU GPL et a le même but que Nagios ; il est codé dans les mêmes langages que son parent Nagios ; Icinga correspond à de la supervision de réseau et de service, il permet de générer des alertes et donne la possibilité de créer ses propres scripts. Shinken ([Shi], [Wikd]) : créé en 2010 par Jean Gabès sous licence GNU GPL, car, selon son créateur, il n'y a eu aucune amélioration réelle de Nagios durant les trois dernières années, essentiellement des corrections de bugs ; il est codé en Python et ses 9

10 scripts sont en Perl ou en Python ; Shinken correspond à de la supervision de réseau et de service, il permet de générer des alertes et il donne la possibilité de créer ses propres scripts. Xymon ([Xym], [Wika]) : créé en 2002 par Henrik Storner sous licence libre pour surveiller les serveurs, applications et réseaux ; il est codé en C ; Xymon correspond à de la supervision de réseau et de service, il permet de générer des alertes. Monit ([Mmo]) : créé aux alentours de 2007 par Tildeslash Ltd sous licence GNU GPL pour surveiller des services locaux installés sur une machine Unix ; il est codé en C ; Monit correspond à de la supervision de réseau et de service, il permet de générer des alertes et l'automatisation d'action. NetCrunch ([Net]) : créé en 2007 par AdRem Software sous licence shareware pour gérer et surveiller des réseaux de plusieurs milliers de n uds ; NetCrunch correspond à de la supervision de réseau, il permet de générer des alertes. OpenNMS ([Ope]) : créé aux alentours de 2008 par The OpenNMS Group sous licence GNU GPL dans le but de servir de plate-forme applicative de gestion de réseau ; il est codé en Java ; OpenNMS correspond à de la supervision de réseau et de service, il permet de générer des alertes et il donne la possibilité de créer ses propres scripts. Vericoh ([NG10]) : créé en 2009 par Philippe Gauron pour vérier le comportement pour l'acquisition et la publication de l'ensemble des données du Grid Observatory selon les besoins de l'époque ; il est codé en en Python ; Vericoh correspond à de la supervision de service. 3. Les outils de supervision et de métrologie Zabbix ([Zab]) : créé en 2006 par Alexei Vladishev sous licence GNU GPL pour surveiller le statut de divers services réseau, serveurs et autres matériels réseau ; Zabbix correspond à du monitoring de réseau et de service. Server Monitor ([Ser]) : créé en 2008 par Kalimoni sous licence commerciale pour surveiller et monitorer un serveur en mode hébergé ; Server Monitor correspond à du monitoring de réseau et de service. BoardVisor ([Boa]) : créé par IDCWARE sous licence commerciale pour apporter un reporting réel de la qualité de service, un tableau de bord permettant de visualiser immédiatement l'activité de l'entreprise et d'en déduire les tendances à moyen et long termes ; BoardVisor correspond à du monitoring de service, il permet de générer des alertes, de corréler des données, mais il ne traite pas avec les événements terminés et demande la participation de l'utilisateur pour éviter les ruptures de service. Le Grid Observatory n'a pas besoin d'un outil de métrologie mais d'un outil de supervision. En eet, les graphiques et l'historisation ne correspondent pas aux besoins qu'a le Grid Observatory, contrairement à l'analyse et au traitement des données et les alertes en cas de problème. La supervision de réseau ne convient pas pour le Grid Observatory, il faut un outil de supervision de service qui soit facilement adaptable pour qu'il soit possible de rajouter les vérications dont le Grid Observatory a besoin (si elles ne sont pas déjà dans l'outil). De part sa capacité à eectuer une surveillance aussi bien passive qu'active ainsi que de part la possibilité d'y ajouter ses propres scripts, Shinken semble être le candidat idéal pour monitorer 10

11 le Grid Observatory Les particularités de Shinken L'idée principale de Shinken est de découpler les diérents rôles de Nagios. J'ai étudié son fonctionnement pour savoir s'il est vraiment l'outil idéal pour le Grid Observatory. Shinken est composé de six parties selon [Val11] : l'arbiter : il est chargé de lire la conguration, de la découper en autant de parties qu'il y a de Schedulers dans l'architecture et de l'envoyer aux éléments de l'architecture. Il est également garant de la haute disponibilité : si un élément tombe, il envoie la conguration qu'il avait en charge à un élément non actif déni par l'administrateur. Enn, son dernier rôle est de lire les ordres des administrateurs et de les transmettre aux Schedulers concernés. les Schedulers : ils ont pour tâche la programmation des contrôles, l'analyse des résultats et le suivi des actions en conséquence. Ils ne lancent pas directement les vérications ni les alertes. Ils ne font que proposer un ordre de lancement. les Pollers : ils ont pour rôle de lancer les sondes demandées par les Schedulers au moment où les Schedulers les y autorisent. Une fois par seconde, ils vont retourner les résultats aux Schedulers pour que ces derniers puissent eectuer des actions supplémentaires si besoin (comme une alerte) et réordonnancer les tests. Ils sont en première ligne pour les performances et on peut en avoir autant que l'on a besoin. les Reactionners : ils sont responsables du lancement des vérications et des actions correctrices. Ils sont découplés des Pollers car il est plus pratique d'avoir un unique Reactionner (avec un élément non actif) pour n'avoir qu'un seul lieu où se remplissent les ux d'information d'alerte. les Brokers : ils doivent récupérer les informations d'état des Schedulers et les traiter. Ces traitements sont faits par des modules. Diérents modules existent : un pour l'export en base MySQL, un pour l'export en base Oracle ou encore pour l'export en base CouchDB. les sondes : codées principalement en Perl, elles sont chargées d'eectuer des vérications ou des traitements sur les diérents services à contrôler et renvoyer leur état aux Pollers. Comme dans Nagios, les sondes ont les codes retour suivants : 0 : OK, 1 : WARNING, 2 : CRITICAL et 3 : UNKNOWN. Chaque démon a un chier de conguration et un port sur lequel écouter. L'architecture une tâche, un outil donne à Shinken une exibilité bien supérieure au Nagios originel, on a ainsi une mise en place et une conguration beaucoup plus faciles. La visualisation de Shinken peut se faire grâce à plusieurs outils, parmi lesquels les Interfaces Homme-Machine (IHM) web Ninja et Thruk ; c'est cette dernière que j'ai utilisé durant mon stage (voir Figure 3). 11

12 Figure 3 Capture d'écran de Thruk Shinken est donc l'outil idéal pour répondre au besoin de surveillance du Grid Observatory de part son installation simple et rapide, la facilité avec laquelle on peut créer et ajouter de nouvelles sondes, la possibilité d'envoyer des alertes et son IHM qui permet de visualiser uniquement ce dont on a besoin. Il a été proposé de reprendre et d'améliorer Vericoh mais, Vericoh étant une ébauche d'outil de supervision, tout ceci revenait quelque peu à recréer un outil de supervision à partir de Vericoh (faire une IHM web aurait été comme refaire Thruk, développer un analyseur revenait à refaire les Brokers et Reactionners de Shinken...) alors qu'il y en a déjà un bon nombre qui existe et que Shinken répondait à nos besoins. Une autre solution a également été proposée : développer un autre outil, tout à fait diérent de Shinken et d'une évolution de Vericoh. Cependant, j'ai montré que les besoins du Grid Observatory correspondaient tout à fait à un outil de supervision et Vericoh a montré les limites de la création d'un outil ad hoc, donc créer un outil spécique revenait à créer un outil de supervision là où nous aurions pu nous appuyer sur un outil déjà existant. Faire évoluer Shinken est donc apparu comme le choix le plus pertinent pour répondre à ce besoin d'un outil de surveillance. 2.3 Mise en uvre de Shinken Pour adapter Shinken aux besoins du Grid Observatory, je l'ai d'abord installé sur ma machine en suivant les instructions de [Gab10]. Alors, j'ai pu lui créer une conguration puis des sondes 12

13 spéciques au Grid Observatory. Il m'a ensuite fallu réaliser une batterie de tests adaptée aux erreurs identiées dans le Grid Observatory et, pour nir, j'ai déployé Shinken sur la machine du Grid Observatory Création d'une conguration propre au Grid Observatory Pour créer une conguration pour le Grid Observatory, j'ai dû ajouter ou modier les chiers suivants : /etc/shinken/conf-gridobs/gridobs-commands.cf g pour contenir les commandes pour lancer les sondes que j'allais créer par la suite. /etc/shinken/nagios.cfg pour qu'il sache où aller chercher les commandes pour lancer les sondes du Grid Observatory. /etc/shinken/resource.cf g pour qu'il sache où se situent les sondes en question. /etc/shinken/conf-gridobs/shinken-conf iguration.xml qui servira de référence pour les diérentes sondes du Grid Observatory. J'ai également créé le répertoire /usr/lib/nagios/plugins/gridobs/ pour contenir les sondes du Grid Observatory que j'ai créées an de les dissocier de celles qui sont de base dans Shinken Création de sondes propres au Grid Observatory Cette section présente les sondes en Perl que j'ai créées durant mon stage. Les sondes suivantes seront présentées : check_ssh pour vérier l'accessibilité en ssh. check_f ile_up pour vérier la présence de chiers dans les répertoires d'upload. check_service pour vérier si tout va bien pour un service du Grid Observatory. check_upload pour vérier la présence d'erreurs dans les log d'upload (un couple de chier log et de chier err). check_log pour vérier les autres chiers log. check_err pour vérier les autres chiers log d'erreurs. check_disk pour vérier l'espace disque. check_backup pour vérier la présence de chiers backup. 1. check_ssh Pour fonctionner, cette sonde a besoin qu'on lui donne soit l'option -m suivie du nom d'une machine, soit l'option --all. Elle écrit ses actions dans le chier /data/log/shinken/check_ssh.log. Si on lui donne l'option --all, elle parcourt toutes les machines gurant dans le chier xml de conguration et tente de se connecter en ssh à chaque machine. Son code retour est OK si elle a réussi à se connecter à toutes les machines, sinon son code retour est CRITICAL et elle écrit les noms des machines auxquelles elle n'a pas pu se connecter dans son chier log. 13

14 Si on lui donne l'option -m suivie d'un nom de machine, elle commence par regarder si les informations de connexion de la machine gurent dans le chier xml, si ce n'est pas le cas, son code retour est CRITICAL. Ensuite, elle essaye de se connecter en ssh à la machine. Si elle ne réussi pas, le code retour est CRITICAL sinon le code retour est OK. 2. check_f ile_up Cette sonde écrit ses actions dans le chier /data/log/shinken/check_f ile_up.log. Elle débute en vériant que chaque répertoire contenu dans le répertoire /data/up/ ait au maximum un chier (à part pour le répertoire /data/up/buggy/). Si ce n'est pas le cas, son code retour est CRITICAL. Ensuite elle vérie depuis combien de temps chaque chier est présent ici (sauf pour ceux du répertoire /date/up/buggy/). Si cela fait plus de sept jours qu'ils sont ici, son code retour est CRITICAL et elle écrit dans son chier log les chiers concernés, si cela fait plus d'un jour, son code retour est WARNING et elle écrit également dans son chier log les chiers concernés. Puis elle regarde si le répertoire /data/up/buggy/ ne contient pas de chier de moins de sept jours. S'il y en a, son code retour est CRITICAL et elle écrit dans son chier log les chiers concernés. Après cela, elle vérie le nom de chaque chier (hormis ceux du répertoire /data/up/buggy/). S'ils ne sont pas de ce type ganglia2011w 25.tar.gz, son code retour est CRITICAL. Pour nir, elle vérie la taille de chaque chier : elle parcourt les répertoires gurant dans le chier xml de conguration et pour chaque répertoire, elle récupère les bornes critiques et les bornes warning sur la taille de leur chier. S'il y a des chiers dont le répertoire ne gure pas dans le chier xml, le code retour est CRITICAL et elle écrit les chiers concernés dans son chier log. S'il y a des chiers qui ont une taille hors de bornes critiques, le code retour est CRITICAL et elle écrit dans son chier log les chiers concernés, s'il y en a qui ont une taille hors des bornes warning, le code retour est WARNING et elle écrit dans son chier log les chiers concernés. Sinon elle retourne OK. 3. check_service Pour fonctionner, cette sonde a besoin qu'on lui donne l'option -s suivie du nom d'un service du Grid Observatory. Elle écrit ses actions dans le chier /data/log/shinken/check_service.log. Elle commence par vérier que le service passé en paramètre fait bien partie de la liste des services du Grid Observatory stockée dans le chier xml de conguration. Si ce n'est pas le cas, son code retour est CRITICAL, sinon on récupère les noms des chiers log, des chiers log d'erreur et des chiers d'upload correspondant à ce service. Ensuite, pour chacun des chiers log, la sonde lance la sonde check_log et récupère les codes retour. Si le service n'a pas de chier log, alors le code retour est WARNING. Puis pour chacun des chiers log d'erreur, la sonde lance la sonde check_err et récupère les codes retour. Si le service n'a pas de chier log d'erreur, alors le code retour est WARNING. 14

15 Et pour chaque couple de chier d'upload (un chier log et un chier log d'erreur), la sonde lance la sonde check_upload et récupère les codes retour. Si le service n'a pas de couple de chier d'upload, alors le code retour est WARNING. Pour nir, la sonde a pour code retour CRITICAL si, parmi tous les codes retour récupérés il y a au moins un CRITICAL, elle retourne WARNING s'il y a au moins un WARNING et aucun CRITICAL et elle retourne OK s'il n'y a ni WARNING ni CRITICAL. 4. check_upload Pour fonctionner, cette sonde a besoin qu'on lui donne deux fois l'option -f suivie de chiers (le chier log d'upload et le chier log d'erreur correspondant). Elle écrit ses actions dans le chier /data/log/shinken/check_upload.log. Elle commence par tester l'existence du chier log. Si ce n'est pas le cas, son code retour est CRITICAL, si c'est le cas mais qu'il n'a pas de contenu, son code retour est WARNING. Elle fait les mêmes vérications pour le chier log d'erreur. Ensuite elle récupère le dernier log du chier log. Un log doit commencer par la ligne Running : nom du script. S'il n'y a pas un seul "Running : " dans le chier, alors le code retour est CRITICAL, s'il y a des "Running : " mais que leur syntaxe n'est pas correcte, alors le code retour est WARNING et elle écrit dans son chier log les lignes en question. La sonde fait le même traitement pour le chier log d'erreur. Puis elle vérie les lignes du log. Si le log a des lignes ne correspondant pas aux lignes types d'un chier log d'upload, alors le code retour est CRITICAL. Si le log a des lignes correspondant aux lignes types d'un chier log d'upload mais qu'elles ne sont pas dans le bon ordre, alors le code retour est WARNING. Elle regarde ensuite si le log d'erreur contient la ligne Using grid catalog : (null) ou non. Si oui alors son code retour est WARNING. Pour nir, elle regarde si le log contient la ligne prouvant que le chier a bien été mis en ligne. S'il ne la contient pas, son code retour est WARNING et elle écrit dans son chier log le contenu du chier log d'erreur pour expliquer pourquoi la mise en ligne a échoué. Sinon son code retour est OK. Si le premier chier passé en paramètre n'a pas une extension.log, le code retour de la sonde est UNKNOWN et si le deuxième chier passé en paramètre n'a pas une extension.err, le code retour de la sonde est UNKNOWN. 5. check_log Pour fonctionner, cette sonde a besoin qu'on lui donne l'option -f suivie du nom d'un chier log. Elle écrit ses actions dans le chier /data/log/shinken/check_log.log. Elle commence par tester l'existence du chier. S'il n'existe pas, son code retour est CRIT- ICAL, s'il existe mais qu'il n'a pas de contenu, son code retour est WARNING. Ensuite, elle cherche le dernier log : celui-ci doit débuter par la ligne Running : nom du script. 15

16 S'il n'y en a pas, son code retour est CRITICAL, s'il y en a mais que leur syntaxe n'est pas correcte, son code retour est WARNING et elle écrit les lignes concernées dans son chier log. Après cela, elle regarde si chaque ligne du dernier log commence par un TimeStamp correct ( T14 :11 :11Z par exemple), sinon, elle retourne CRITICAL et écrit dans son chier log les lignes concernées. Puis elle vérie la date du dernier log. Pour cela elle commence par chercher les informations relatives au chier dans le chier xml de conguration. Si ses informations ne sont pas dans le chier, son code retour est CRITICAL. Ensuite, elle compare la date d'aujourd'hui à la date du log. Si la diérence est négative, alors le log est daté dans le futur et le code retour est CRITICAL, si la diérence est positive mais supérieure à la durée critique récupérée dans le chier xml, alors le code retour est CRITICAL et si la diérence est positive mais supérieure à la durée warning, alors le code retour est WARNING. Elle vérie alors si le script est terminé en regardant si la dernière ligne du log est All done.. Si le script n'est pas terminé, elle regarde la date de la dernière ligne et la compare à la date d'aujourd'hui, si la diérence est supérieure à une heure, son code retour est CRITICAL, sinon son code retour est WARNING. Pour nir, elle regarde le temps de traitement du script. Si le temps de traitement est supérieur au temps critique récupéré dans le chier xml, alors le code retour est CRITICAL, s'il est supérieur au temps warning, alors le code retour est WARNING et sinon le code retour est OK. Si le chier passé en paramètre n'a pas une extension.log, le code retour de la sonde est UNKNOWN. 6. check_err Pour fonctionner, cette sonde a besoin qu'on lui donne l'option -f suivie du nom d'un chier log d'erreur. Elle écrit ses actions dans le chier /data/log/shinken/check_log.log. Pour commencer, elle vérie si le chier existe bien et s'il a un contenu. S'il n'existe pas, son code retour est CRITICAL. S'il existe mais qu'il n'a pas de contenu, son code retour est WARNING. Ensuite, elle vérie que chacun des log d'erreur commence bien par la ligne Running : nom du script. S'il n'y a aucun "Running : " dans tout le chier alors le code retour est CRITICAL. S'il y a des "Running : " mais mal orthographiés alors le code retour est WARNING. Pour nir, elle parcourt chacune des lignes du dernier log d'erreur et les compare aux expressions régulières des lignes considérées comme étant des fausses erreurs (elles sont stockées dans le chier xml de conguration). Si le dernier log d'erreur contient des lignes autres que des fausses erreurs, le code retour est CRITICAL, sinon le code retour est OK. Si l'extension du chier n'est pas.err alors le code retour de la sonde est UNKNOWN. 7. check_disk Cette sonde écrit ses actions dans le chier /data/log/shinken/check_disk.log. 16

17 Elle commence par lancer la commande df et elle récupère le résultat. Elle compare ensuite l'espace disque libre récupéré grâce à la commande à l'espace disque libre critique et à l'espace disque libre warning stockés dans le chier xml de conguration. Si l'espace disque libre est inférieur à l'espace disque libre critique alors le code retour est CRITICAL, s'il est inférieur à l'espace disque libre warning alors le code retour est WARNING. Enn elle compare l'espace disque utilisé récupéré grâce à la commande à l'espace disque utilisé critique et à l'espace disque utilisé warning. Si l'espace disque utilisé est supérieur à l'espace disque utilisé critique alors le code retour est WARNING, s'il est supérieur à l'espace disque utilisé warning alors le code retour est WARNING, sinon le code retour est OK. 8. check_backup Cette sonde écrit ses actions dans le chier /data/log/shinken/check_backup.log. Elle commence par parcourir le dossier /data/backup/ et elle regarde s'il y a bien un seul et unique chier dedans sinon, son code retour est CRITICAL. Ensuite, elle regarde si le nom du chier correspond bien à un nom de chier backup (backup2011w tar.gz), si ce n'est pas le cas, son code retour est CRITICAL. Puis, elle regarde s'il a un contenu ou non. S'il est vide, son code retour est CRITICAL. Pour nir, elle regarde l'âge du chier. S'il est âgé de plus de 28 jours (ou plus de 35 jours s'il s'agit du chier backup de la semaine 53 si elle existe), son code retour est CRITICAL, sinon son code retour est OK. 2.4 Réalisation d'une batterie de tests adaptée aux erreurs identiées dans le Grid Observatory Au cours de la création des sondes, il a fallu tester chaque cas et, pour chaque modication, s'assurer que la sonde fonctionne bien pour le nouveau cas et que la modication n'altère en rien les vérications des cas précédents : j'ai dû eectuer aussi bien des tests fonctionnels que des tests de non régression ([Evr10], [Wikc]). La batterie de tests que j'ai réalisée peut se décomposer en deux parties : les tests des vérications sur le système de chiers. les tests des vérications de contenu de chiers Tests des vérications sur le système de chiers Les tests sur les sondes eectuant des vérications sur le système de chiers ont nécessité des changements fréquents sur le système de chiers. Ce genre de tests a dû être fait sur les sondes check_backup, check_disk, check_f ile_up, check_service et check_ssh. check_backup : pour cette sonde, j'ai testé les cas suivants : la présence d'un seul chier dans le répertoire /data/backup/. si le nom du chier backup est correct. 17

18 si le chier backup n'est pas vide. l'âge du chier backup. check_disk : pour cette sonde, j'ai testé les cas suivants : la présence d'espace libre sur le disque. si les chiers ne prennent pas trop d'espace sur le disque. check_file_up : pour cette sonde, j'ai testé les cas suivants : la présence d'un chier au maximum dans chaque répertoire contenu dans le répertoire /data/up/. si chaque chier est âgé de moins d'une semaine. si les chiers du répertoire /data/up/buggy/ sont âgés de plus d'une semaine. si chaque chier a un nom correct. si chaque chier a une taille correcte. check_service : pour cette sonde, j'ai testé les cas suivants : si le service est bien dans le chier xml. si les codes retour des sondes lancées sur les chiers du service sont "OK". check_ssh : pour cette sonde, j'ai testé les cas suivants : si toutes les machines sont accessibles en ssh dans le cas de l'option --all. si les informations de la machine gurent dans le chier xml et que la machine est accessible en ssh dans le cas de l'option -m Tests des vérications de contenu de chiers Les tests sur les sondes vériant le contenu de chiers ont nécessité la création d'un chier pour tester chaque cas de gure. Pour tester un cas de gure, le chier créé doit bien évidemment passer avec succès tous les tests précédents. Ce genre de tests a dû être fait sur les sondes check_log, check_err et check_upload. check_log : pour cette sonde, j'ai un ensemble de chiers testant : si l'extension du chier est correcte. l'existence du chier. si le chier n'est pas vide. si la syntaxe interne au chier est correcte (chaque log commence par la ligne Running : nom du script ). la présence d'un TimeStamp correct en début de chaque ligne. si le chier gure dans le chier xml. si la date du dernier log est récente. si le script s'est correctement terminé (la dernière ligne est All done. ) ou s'il est encore en cours d'exécution ou s'il s'est anormalement arrêté. si le temps de traitement du script n'est pas trop long. check_err : pour cette sonde, j'ai un ensemble de chiers testant : si l'extension du chier est correcte. l'existence du chier. si le chier n'est pas vide. si la syntaxe interne au chier est correcte (chaque log commence par la ligne Running : nom du script ). si le dernier log d'erreur ne contient que des lignes recensées comme étant des fausses 18

19 erreurs. check_upload : pour cette sonde, j'ai un ensemble de chiers testant : si les extensions des deux chiers sont correctes. l'existence des deux chiers. si les chiers ne sont pas vides. si les syntaxes interne aux chiers sont correctes (chaque log commence par la ligne Running : nom du script ). si les lignes du chier log sont dans le bon ordre. s'il n'y a pas de problème de catalogue dans le dernier log du chier err. si le dernier log du chier log contient la ligne attestant que le chier a été mis en ligne. 2.5 Déploiement de Shinken sur la machine Grid Observatory Un essai de déploiement a été eectué sur une machine de test sur laquelle le système fonctionne parfaitement avec une installation "standard" de Shinken possédant la conguration personnalisée pour le Grid Observatory. Shinken doit prochainement être déployé sur une machine du Grid Observatory au LAL mais un gros problème de climatisation de la salle machine du LAL a engendré un grand retard dans leur calendrier de déploiement, ce qui fait qu'au moment de la nalisation de ce rapport le logiciel n'a pas encore pu être mis en production. Le déploiement est néanmoins prévu dans les prochains jours. 19

20 Conclusion Grâce au travail que j'ai réalisé dans le cadre de mon stage, le Grid Observatory dispose maintenant d'un outil de surveillance rapide, clair et ecace. L'administrateur n'a plus besoin de vérier manuellement si tout fonctionne, un simple coup d' il à Thruk sut pour vérier l'état de l'ensemble des services et composants du Grid Observatory. Durant mes douze semaines de stage, j'ai créé les sondes véricatrices les plus vitales pour le Grid Observatory, ce qui correspond aux 3/4 des vérications dont il a besoin actuellement. Le quart restant peut être créé et ajouté simplement de part la exibilité de Shinken ; de même, si les besoins de surveillance venaient à évoluer, la création de nouvelles sondes serait tout aussi aisée. Ce stage en laboratoire a été pour moi une expérience professionnelle intéressante et enrichissante. Il m'a permis de mettre en pratique mes connaissances théoriques acquises durant ma formation universitaire et d'en acquérir de nouvelles telles que le langage Perl et le monitoring. Cette expérience m'ore une préparation solide et valorisante pour mon insertion professionnelle. 20

ZABBIX est distribué sous licence GNU General Public License Version 2 (GPL v.2).

ZABBIX est distribué sous licence GNU General Public License Version 2 (GPL v.2). Nom du projet : Zabbix Description : ZABBIX est un logiciel open source créé par Alexei Vladishev. Zabbix permet de surveiller le statut de divers services réseau, serveurs et autres matériels réseau.

Plus en détail

Rapport Technique. Étude de solutions libres alternatives au système de supervision Nagios à L IUEM - Brest

Rapport Technique. Étude de solutions libres alternatives au système de supervision Nagios à L IUEM - Brest Rapport Technique Étude de solutions libres alternatives au système de supervision Nagios à L IUEM - Brest Auteur(s) : Robin Guennoc Titre projet : Étude solutions libres systèmes supervision Type de projet

Plus en détail

Compte-rendu de projet de Système de gestion de base de données

Compte-rendu de projet de Système de gestion de base de données Compte-rendu de projet de Système de gestion de base de données Création et utilisation d'un index de jointure LAMBERT VELLER Sylvain M1 STIC Université de Bourgogne 2010-2011 Reponsable : Mr Thierry Grison

Plus en détail

Contribution à la mise en service d'une ferme de serveurs connectée à une grille de calcul pour la physique des hautes énergies

Contribution à la mise en service d'une ferme de serveurs connectée à une grille de calcul pour la physique des hautes énergies Contribution à la mise en service d'une ferme de serveurs connectée à une grille de calcul pour la physique des hautes énergies Charlier Fabrice 2è licence en informatique Année Académique 2005-2006 Plan

Plus en détail

TER Master 1 (FMIN 200) Cahier des charges: Oracle Lexical

TER Master 1 (FMIN 200) Cahier des charges: Oracle Lexical TER Master 1 (FMIN 200) Cahier des charges: Oracle Lexical VEYSSIER Julien, BISQUERT Pierre PAIVA LIMA DA SILVA Bruno, BELMONTE Remy - Encadrant : Mathieu Lafourcade 6 février 2009 Université Montpellier

Plus en détail

PPE 5 SUPERVISION D UN PARC INFORMATIQUE AVEC NAGIOS + CENTREON

PPE 5 SUPERVISION D UN PARC INFORMATIQUE AVEC NAGIOS + CENTREON PPE 5 SUPERVISION D UN PARC INFORMATIQUE AVEC NAGIOS + CENTREON Antoine CAMBIEN BTS SIO Option SISR Session 2015 BTS SIO Services Informatiques aux Organisations Session 2014 2015 Nom du candidat : Antoine

Plus en détail

Travail de Fin d Etudes

Travail de Fin d Etudes 4ème Informatique 27 juin 2005 Travail de Fin d Etudes Supervision Centralisée d Infrastructures Distantes en Réseaux avec Gestion des Alarmes et Notification des Alertes TFE réalisé au sein de la société

Plus en détail

Télécom Nancy Année 2013-2014

Télécom Nancy Année 2013-2014 Télécom Nancy Année 2013-2014 Rapport 1A Ajout du langage C dans la Programmer's Learning Machine GIANNINI Valentin Loria 615, rue du Jardin Botanique 54600, Villers-Lès-Nancy Maître de stage : QUINSON

Plus en détail

NACIRI Mehdi. Rapport de stage : Mise en place d un moyen pour anticiper les pannes des serveurs de l IUT. Promotion 2011-2013 BTS SIO Option SISR

NACIRI Mehdi. Rapport de stage : Mise en place d un moyen pour anticiper les pannes des serveurs de l IUT. Promotion 2011-2013 BTS SIO Option SISR NACIRI Mehdi Rapport de stage : Mise en place d un moyen pour anticiper les pannes des serveurs de l IUT Promotion 2011-2013 BTS SIO Option SISR 1 Remerciements Je tiens particulièrement à remercier le

Plus en détail

Supervision avec Shinken

Supervision avec Shinken Supervision avec Benoit Métrot benoit.metrot@math.univ-poitiers.fr UMR 7348 - Laboratoire de Mathématiques et Applications (Poitiers) Rencontres Mathrice Caen, Mars 2013 Rencontres Mathrice Caen, Mars

Plus en détail

SUPERVISION. Centreon 5.9

SUPERVISION. Centreon 5.9 SUPERVISION Centreon 5.9 Steven DELAPRUNE BTS SIO 11/03/2015 Sommaire CAHIER DES CHARGES... 3 INTRODUCTION... 3 PRINCIPES GENERAUX... 3 Définition... 3 Problématique... 3 Description du besoin... 3 Solution...

Plus en détail

Zabbix. Outil de supervision réseau. Vincent Bernat Vincent.Bernat@wallix.com. July 13, 2007. Zabbix. V. Bernat. Supervision.

Zabbix. Outil de supervision réseau. Vincent Bernat Vincent.Bernat@wallix.com. July 13, 2007. Zabbix. V. Bernat. Supervision. Outil de supervision réseau Vincent Bernat Vincent.Bernat@wallix.com July 13, 2007 Plan 1 La supervision 2 3 Un exemple de Plan 1 La supervision 2 3 Un exemple de Pourquoi superviser? détecter les pannes

Plus en détail

Supervision Réseau Avec

Supervision Réseau Avec Supervision Réseau Avec Réalisé par : Encadré par ; Hajar SEBTI Reda GHANEMI Mme BOUBAKRI Mohamed QOBAYLI Introduction... 4 I. Cahier des charges... 5 1. Réseau à superviser... 5 2. Règles sur le réseau...

Plus en détail

Sauf mention contraire, le contenu de cet ouvrage est publié sous la licence : Creative Commons BY-NC-SA 2.0 La copie de cet ouvrage est autorisée

Sauf mention contraire, le contenu de cet ouvrage est publié sous la licence : Creative Commons BY-NC-SA 2.0 La copie de cet ouvrage est autorisée Sauf mention contraire, le contenu de cet ouvrage est publié sous la licence : Creative Commons BY-NC-SA 2.0 La copie de cet ouvrage est autorisée sous réserve du respect des conditions de la licence Texte

Plus en détail

Nagios 3 pour la supervision et la métrologie

Nagios 3 pour la supervision et la métrologie Nagios 3 pour la supervision et la métrologie A Propos : - la connexion au reseau se fais de la maniére suivante : Se conecter sur le Vlan DSI : -Port 21,22 du commutateur, sur une machine debian en bridged

Plus en détail

Supervision / Architecture Réseau

Supervision / Architecture Réseau Supervision / Architecture Réseau I. Supervision Qu est- ce que la supervision et la métrologie? Pour commencer il ne faut bien distinguer les différents termes. Il y a la supervision qui s attache aux

Plus en détail

TPC#9 : Client & Serveur!

TPC#9 : Client & Serveur! TPC#9 : Client & Serveur! Table des matières 1 Structure du rendu 1 2 Introduction 2 3 Sockets et Threads 2 3.1 Les sockets............................................ 2 3.1.1 Cours et exemples....................................

Plus en détail

E-MediatE, documentation pour l'utilisateur

E-MediatE, documentation pour l'utilisateur E-MediatE, documentation pour l'utilisateur 21 novembre 2011 Résumé Documentation à l'intention des utilisateurs du logiciel. Ce document présente, dans ses grandes lignes le fonctionnement du client E-MediatE.

Plus en détail

Programmation parallèle CPU / GPU

Programmation parallèle CPU / GPU Pré-rapport de stage de Master 2 Professionnel Mention Informatique Spécalité Systèmes et Applications Répartis Parcours Systèmes répartis embarqués ou temps-réel Programmation parallèle CPU / GPU Auteur

Plus en détail

Le client/serveur repose sur une communication d égal à égal entre les applications.

Le client/serveur repose sur une communication d égal à égal entre les applications. Table des matières LES PRINCIPES DE BASE... 1 Présentation distribuée-revamping...2 Présentation distante...3 Traitements distribués...3 données distantes-rd...4 données distribuées-rda distribué...4 L'ARCHITECTURE

Plus en détail

Notice du LiveCD Spécialité Réseaux

Notice du LiveCD Spécialité Réseaux Notice du LiveCD Spécialité Réseaux 21 2 Ethereal : Ethereal est un sniffer de réseau, il capture les trames circulant sur le réseau, en permet l'analyse et sépare suivant l'encapsulation les différnetes

Plus en détail

Informations sur le 2e semestre L3 Informatique tout parcours

Informations sur le 2e semestre L3 Informatique tout parcours Informations sur le 2e semestre L3 Informatique tout parcours (année universitaire 20152016) Francesco Belardinelli L'objectif de ce document est de présenter les principales informations concernant le

Plus en détail

TP n 2: Mise en place d'un serveur Web avec PHP et MySQL

TP n 2: Mise en place d'un serveur Web avec PHP et MySQL TP n 2: Mise en place d'un serveur Web avec PHP et MySQL Le but de ce TP est de vous apprendre comment installer et congurer un serveur Web avec PHP et MySQL sous Linux. Cela requiert plusieurs étapes

Plus en détail

ORACLE DIAGNOSTIC PACK 11G

ORACLE DIAGNOSTIC PACK 11G ORACLE DIAGNOSTIC PACK 11G PRINCIPALES CARACTÉRISTIQUES : Surveillance automatique des diagnostics (ADDM Automatic Database Diagnostic Monitor) Référentiel automatique de la charge (AWR Automatic Workload

Plus en détail

Projet d approfondissement. Schaub Lionel

Projet d approfondissement. Schaub Lionel HES-SO/MASTER MRU: hepia Projet d approfondissement Schaub Lionel Sous la direction de M. Gérald Litzistorf Printemps 2012 Plan État de l art Besoins opérationnels en mesure de disponibilité Notions temporelles

Plus en détail

Table des matières 1. Chapitre 1 Introduction à Nagios et la supervision

Table des matières 1. Chapitre 1 Introduction à Nagios et la supervision Table des matières 1 Les exemples cités tout au long de cet ouvrage sont téléchargeables à l'adresse suivante : http://www.editions-eni.fr Saisissez la référence ENI de l'ouvrage EP3NAG dans la zone de

Plus en détail

1 Exercice 1 Question de cours (4 points)

1 Exercice 1 Question de cours (4 points) Info32B Systèmes d'exploitation année 2013-2014 Examen (1ère session) 16 décembre 2014 N. Sabouret L'épreuve dure 2h30. Tous les documents sont autorisés. Les exercices sont indépendants. 1 Exercice 1

Plus en détail

NICOLAS JAMIN Administrateur Système DSI de l Académie de LILLE

NICOLAS JAMIN Administrateur Système DSI de l Académie de LILLE Supervision Utilisation de Check-MK Réseau Min2Rien Journée Thématique «retour d expériences» - 13/02/2014 NICOLAS JAMIN Administrateur Système DSI de l Académie de LILLE Nicolas JAMIN DSI de l Académie

Plus en détail

Utilisation de PostgreSQL Cas d'utilisation et retour d'expérience. Société Elma, Jean Samuel Reynaud reynaud@elma.fr 1

Utilisation de PostgreSQL Cas d'utilisation et retour d'expérience. Société Elma, Jean Samuel Reynaud reynaud@elma.fr 1 Utilisation de PostgreSQL Cas d'utilisation et retour d'expérience Société Elma, Jean Samuel Reynaud reynaud@elma.fr 1 Qui sommes nous? Jean Samuel Reynaud, Administrateur systèmes et réseaux Société Elma,

Plus en détail

Cahier de charges Projet 24

Cahier de charges Projet 24 Cahier de charges Projet 24 Répartition automatique de surcharge sur serveur web virtualisé Etudiants : KAOUACHI Youssef ELFELLAH Amine Encadré par : M. HAYEL Yezekael Année universitaire : 2008/2009 I-

Plus en détail

SophiaConf 2012. Jean Gabès

SophiaConf 2012. Jean Gabès SophiaConf 2012 Jean Gabès Qui suis-je? Jean Gabès Administrateur système sur Bordeaux, auteur du livre Nagios3 aux éditions Eyrolles et de Shinken Pourquoi superviser? Quand l'it va mal, le business va

Plus en détail

Hébergement WeboCube. Un système performant et sécurisé. Hébergement géré par une équipe de techniciens

Hébergement WeboCube. Un système performant et sécurisé. Hébergement géré par une équipe de techniciens Hébergement WeboCube Le service d'hébergement WeboCube a pour but de sécuriser la présence internet grâce à un suivi personnalisé et une maintenance active de votre serveur internet. Un espace de gestion

Plus en détail

Présentation : Aurelien.Bompard@c-s.fr Contact Commercial : Frederic.Murbach@c-s.fr Responsable Offre Logiciels Libres : Gilles.Lehmann@c-s.

Présentation : Aurelien.Bompard@c-s.fr Contact Commercial : Frederic.Murbach@c-s.fr Responsable Offre Logiciels Libres : Gilles.Lehmann@c-s. Présentation : Aurelien.Bompard@c-s.fr Contact Commercial : Frederic.Murbach@c-s.fr Responsable Offre Logiciels Libres : Gilles.Lehmann@c-s.fr Plan Présentation de Vigilo Architecture globale Composants

Plus en détail

Projet Storebox. Livre blanc Swisscom (Suisse) SA

Projet Storebox. Livre blanc Swisscom (Suisse) SA Projet Storebox Livre blanc Swisscom (Suisse) SA Sommaire Sommaire... 2 Introduction... 3 Différence entre synchronisation et sauvegarde... 3 Quelle méthode utiliser?... 3 Situation initiale... 4 Enjeux...

Plus en détail

Projet Personnalisé Encadré PPE 2

Projet Personnalisé Encadré PPE 2 BTS Services Informatiques aux Organisations Session 2014 Projet Personnalisé Encadré PPE 2. GESTION D'UTILISATEURS SYSTÈMES ET BASE DE DONNÉES, INSTALLATION ET CONFIGURATION D'OUTILS DE SUPERVISION ET

Plus en détail

TCSMP - Time-Cost Stamped Mail Protocol

TCSMP - Time-Cost Stamped Mail Protocol Projet de Master Informatique M1 Université Paris-Est Marne-la-Vallée Session TCSMP Time-Cost Stamped Mail Protocol TCSMP - Time-Cost Stamped Mail Protocol Documentation utilisateur,,, Introduction...

Plus en détail

Installation du SLIS 4.1

Installation du SLIS 4.1 Documentation SLIS 4.1 Installation du SLIS 4.1 1.3RC2 CARMI PÉDAGOGIQUE - ÉQUIPE «INTERNET» DE L'ACADÉMIE DE GRENOBLE juillet 2013 Table des matières Objectifs 5 I - Prérequis 7 A. Préconisations matérielles...7

Plus en détail

PPE 2-1 Support Systeme. Partie Support Système

PPE 2-1 Support Systeme. Partie Support Système PPE 2-1 Support Systeme Partie Support Système Sébastien MASSON 24/04/2013 0 Sommaire 1. DMZ 2 2. Serveurs Web 3 3. Logiciel d'inventaire 6 1 1. DMZ (Zone démilitarisée) Une DMZ est une zone tampon d'un

Plus en détail

SUPERVISION SYSTÈME D INFORMATION

SUPERVISION SYSTÈME D INFORMATION 1 SUPERVISION SYSTÈME D INFORMATION SOMMAIRE I. Contexte II. III. IV. Cahier des charges Analyse Conception V. Test de la maquette L entreprise Réseau existant Définition des besoins Calendrier Prévisionnel

Plus en détail

Communauté francophone de la supervision. http://www.monitoring-fr.org. J eudis du libre B ruxelles 02 septembre 2010

Communauté francophone de la supervision. http://www.monitoring-fr.org. J eudis du libre B ruxelles 02 septembre 2010 Communauté francophone de la supervision http://www.monitoring-fr.org J eudis du libre B ruxelles 02 septembre 2010 La communauté Historique 2007 : Olivier J A N publie ses notes de recherche autour de

Plus en détail

Rapport de stage. Simulation d'algorithmes auto-stabilisants

Rapport de stage. Simulation d'algorithmes auto-stabilisants Université Joseph Fourier Département Licence Sciences & Technologies Rapport de stage Simulation d'algorithmes auto-stabilisants DIAKITE Moussa Laboratoire d'accueil : Verimag Directeur du laboratoire

Plus en détail

Sauvegardes sous Windows c 2003 serveur

Sauvegardes sous Windows c 2003 serveur Sauvegardes sous Windows c 2003 serveur Louis-Maurice De Sousa ~ Fabrice Lemoine ~ Jackie Daon 27 mars 2006 Table des matières 1 Introduction 3 2 NTbackup 3 2.1 La sauvegarde...........................

Plus en détail

SOAP OU REST, QUE CHOISIR?

SOAP OU REST, QUE CHOISIR? SOAP OU REST, QUE CHOISIR? Eric van der Vlist (vdv@dyomedea.com) SOAP ou REST, que choisir? Web Services Convention Juin 2004 Eric van der Vlist (vdv@dyomedea.com) SOAP-- WS Convention 2004 -- Page 1 COMPARER

Plus en détail

Projet Equadex techno 2008

Projet Equadex techno 2008 Création d une étape d imprimante Projet Equadex Techno 2008 Jeremy TYRIAUX Sommaire Introduction... 3 Problématique... 4 Trouvée... 4 Contrôle d accès à l imprimante... 8 Archivage des documents imprimés...

Plus en détail

Méthodologie Scientifique

Méthodologie Scientifique Haute Ecole de la Communaut é Française du Hainaut INSTITUT SUPERIEUR INDUSTRIEL MONS Département technique type long BA1 PROJET Méthodologie Scientifique Prototypage d' une application logicielle Veterinar

Plus en détail

1 Mise en forme des SELECT

1 Mise en forme des SELECT Table des matières Utilitaire SQL*PLUS 1 Mise en forme des SELECT 1 2 Commandes utilitaires de SQL*PLUS 2 2.1 Éditeur de la machine hôte.................... 2 2.2 Commande RUN, commande /.................

Plus en détail

FazaANGEL supervision pro-active

FazaANGEL supervision pro-active presentation FazaAngel - page 1/7 FazaANGEL supervision pro-active FazaAngel : supervision pro-active fazaangel surveille tous les «éléments de votre infrastructure : télécom, réseau, serveur, site web

Plus en détail

et Groupe Eyrolles, 2006, ISBN : 2-212-11747-7

et Groupe Eyrolles, 2006, ISBN : 2-212-11747-7 Tsoft et Groupe Eyrolles, 2006, ISBN : 2-212-11747-7 OEM Console Java OEM Console HTTP OEM Database Control Oracle Net Manager 6 Module 6 : Oracle Enterprise Manager Objectifs Contenu A la fin de ce module,

Plus en détail

Impact du choix du SGBD et de l architecture client-serveur pour garantir le service d un SGBD mis sous forte charge concurrente

Impact du choix du SGBD et de l architecture client-serveur pour garantir le service d un SGBD mis sous forte charge concurrente Impact du choix du SGBD et de l architecture client-serveur pour garantir le service d un SGBD mis sous forte charge Travail de diplôme réalisé en vue de l obtention du diplôme HES par : Muhammad Maqbool

Plus en détail

Exemple de projet. «Gestion de contacts»

Exemple de projet. «Gestion de contacts» Université Paul Valéry Montpellier 3 Antenne universitaire de Béziers L3 AES parcours MISASHS ECUE «Logiciels spécialisés» Exemple de projet «Gestion de contacts» G. Richomme Table des matières 1. Introduction...

Plus en détail

PARAGON SYSTEM BACKUP 2010

PARAGON SYSTEM BACKUP 2010 PARAGON SYSTEM BACKUP 2010 Paragon System Backup 2010 2 Manuel d'utilisation SOMMAIRE 1 Introduction...3 1.1 Comment System Backup protège mon ordinateur?...3 1.1.1 Emplacement du stockage des clichés...

Plus en détail

TP : Shell Scripts. 1 Remarque générale. 2 Mise en jambe. 3 Avec des si. Systèmes et scripts

TP : Shell Scripts. 1 Remarque générale. 2 Mise en jambe. 3 Avec des si. Systèmes et scripts E3FI ESIEE Paris Systèmes et scripts B. Perret TP : Shell Scripts 1 Remarque générale Lorsque vous cherchez des informations sur Internet, n'oubliez pas que langage de shell script que nous avons vu correspond

Plus en détail

Cloud public d Ikoula Documentation de prise en main 2.0

Cloud public d Ikoula Documentation de prise en main 2.0 Cloud public d Ikoula Documentation de prise en main 2.0 PREMIERS PAS AVEC LE CLOUD PUBLIC D IKOULA Déployez vos premières instances depuis l interface web ou grâce à l API. V2.0 Mai 2015 Siège Social

Plus en détail

Déploiement & Supervision. Université de Marne-la-Vallée 2/61 Laurent Wargon

Déploiement & Supervision. Université de Marne-la-Vallée 2/61 Laurent Wargon Déploiement & Supervision de Marne-la-Vallée 2/61 Laurent Wargon Déploiement de Marne-la-Vallée 3/61 Laurent Wargon Déploiement L'exploitation reçoit du développement Un code Une documentation? L'exploitation

Plus en détail

Manuel d utilisation de la plate-forme de gestion de parc UCOPIA. La mobilité à la hauteur des exigences professionnelles

Manuel d utilisation de la plate-forme de gestion de parc UCOPIA. La mobilité à la hauteur des exigences professionnelles Manuel d utilisation de la plate-forme de gestion de parc UCOPIA La mobilité à la hauteur des exigences professionnelles 2 Manuel d utilisation de la plate-forme de gestion de parc UCOPIA 1 Table des matières

Plus en détail

TP4-5 : Authentication Java

TP4-5 : Authentication Java TP4-5 : Authentication Java V. Danjean V. Marangozova-Martin Résumé Le but de ce TP est double : se familiariser avec le mécanisme classique d'authentication en Java ; apprendre à utiliser la documentation

Plus en détail

Gestion d'un entrepôt

Gestion d'un entrepôt Gestion d'un entrepôt Épreuve pratique d'algorithmique et de programmation Concours commun des écoles normales supérieures Durée de l'épreuve: 3 heures 30 minutes Juin/Juillet 2010 ATTENTION! N oubliez

Plus en détail

2 Spécicités SVN. 3 Verrouiller ou copier-modier-fusionner. 4 Commandes SVN. 5 Références

2 Spécicités SVN. 3 Verrouiller ou copier-modier-fusionner. 4 Commandes SVN. 5 Références Table des matières Apache Subversion (SVN) 1 Michel Meynard UM2 2 Spécicités SVN 3 Verrouiller ou copier-modier-fusionner Univ. Montpellier 2 4 5 Références Michel Meynard (UM2) Apache Subversion (SVN)

Plus en détail

LES FONCTIONS DE SURVEILLANCE DES FICHIERS

LES FONCTIONS DE SURVEILLANCE DES FICHIERS SYSLOG and APPLICATION LOGS Knowledge Module for PATROL - Data Sheet Version 1.5 Développé par http://www.axivia.com/ PRESENTATION DU PRODUIT SYSLOG and APPLICATION LOGS Knowledge Module for PATROL est

Plus en détail

Rapport de stage. LARRIEU Robin Promotion X2011 7 ème compagnie Section Tennis

Rapport de stage. LARRIEU Robin Promotion X2011 7 ème compagnie Section Tennis Rapport de stage LARRIEU Robin Promotion X2011 7 ème compagnie Section Tennis Météo France Projet VORTEX La Météopole, Toulouse Du 15 juillet au 30 Août 2013 Remerciements Je tiens à remercier particulièrement

Plus en détail

CHAPITRE 1. Introduction aux web services. 1.1 Définition. Contenu du chapitre : Env. De dev. Langage Visual Studio Java EE Qt Creator C#

CHAPITRE 1. Introduction aux web services. 1.1 Définition. Contenu du chapitre : Env. De dev. Langage Visual Studio Java EE Qt Creator C# CHAPITRE 1 Introduction aux web services Contenu du chapitre : Env. De dev. Langage Visual Studio Java EE Qt Creator C# NetBeans JavaScript Eclipse Objective C Xcode PHP HTML Objectifs du chapitre : Ce

Plus en détail

Distribution d'une interface de modélisation pour ns-2

Distribution d'une interface de modélisation pour ns-2 UFR Sciences et Technologies Université de la Réunion Distribution d'une interface de modélisation pour ns-2 Master 1 Sciences et Technologies de l'information et de la Communication (STIC) LAROSE Cedrik

Plus en détail

DataTraveler 410. Manuel d'utilisation de SecureTraveler

DataTraveler 410. Manuel d'utilisation de SecureTraveler Manuel d'utilisation de SecureTraveler SecureTraveler est l'utilitaire de configuration DataTraveler permettant aux utilisateurs en entreprise et aux utilisateurs privés d'établir des zones publiques et

Plus en détail

Pourquoi ai-je besoin de recompiler apache? Comment recompiler apache? Comment récupérer les entêtes eid en PHP?

Pourquoi ai-je besoin de recompiler apache? Comment recompiler apache? Comment récupérer les entêtes eid en PHP? 1 Généralité Qu'elle est l'architecture générale d'une application eid en ligne? Client / PC-SC / Reverse Proxy / Serveur applicatif TODO gure architecture JPG A quel niveau se fait/font la/les vérication(s)

Plus en détail

Rapport d'audit. «Librairie Informatique»

Rapport d'audit. «Librairie Informatique» GL51 Rapport d'audit «Librairie Informatique» Code : BATSPETA-000 Maîtrise d'oeuvre Maîtrise d'ouvrage Responsables de l'audit M. Fischer M. Petrequin Melle Bats, M. Petazzoni Date rédaction : 05/01/04

Plus en détail

TP2 - Conguration réseau et commandes utiles. 1 Généralités. 2 Conguration de la machine. 2.1 Commande hostname

TP2 - Conguration réseau et commandes utiles. 1 Généralités. 2 Conguration de la machine. 2.1 Commande hostname Département d'informatique Architecture des réseaux TP2 - Conguration réseau et commandes utiles L'objectif de ce TP est d'une part de vous présenter la conguration réseau d'une machine dans l'environnement

Plus en détail

SISR5 SUPERVISION DES RESEAUX. TP5 Mise en place d un outil de supervision

SISR5 SUPERVISION DES RESEAUX. TP5 Mise en place d un outil de supervision SISR5 SUPERVISION DES RESEAUX TP5 Mise en place d un outil de supervision GERSON YOULOU LOIC GLOAGUEN BTS SIO2 22/11/2013 SOMMAIRE Introduction... 2 Mise en place de l architecture réseau... 3 Configuration

Plus en détail

Load Balancing. Table des matières. Gatien, Julien, Rémi, Vincent. 2 mars 2009. 1 Le projet 2. 2 L'équilibrage de charge 2.

Load Balancing. Table des matières. Gatien, Julien, Rémi, Vincent. 2 mars 2009. 1 Le projet 2. 2 L'équilibrage de charge 2. Load Balancing Gatien, Julien, Rémi, Vincent 2 mars 2009 Table des matières 1 Le projet 2 2 L'équilibrage de charge 2 3 Algorithmes 2 4 État de l'art 3 4.1 LVS..........................................

Plus en détail

CONFIGURER VOTRE HEBERGEMENT LINUX

CONFIGURER VOTRE HEBERGEMENT LINUX CONFIGURER VOTRE HEBERGEMENT LINUX Ref : FP. P858 V 6.0 Ce document vous indique comment utiliser votre hébergement Linux à travers votre espace abonné. A - Accéder à la gestion de votre Hébergement...

Plus en détail

Initiation au Web et à l'html

Initiation au Web et à l'html Initiation au Web et à l'html Mathieu LACROIX, François RÉVERET, Antoine VACAVANT mathieu.lacroix@isima.fr françois.reveret@univ-bpclermont.fr antoine.vacavant@liris.cnrs.fr 2 et 3 Avril 2007 /1 Mathieu

Plus en détail

Java - TP3. Nicolas Baudru, Carine Guivier-Curien, Laurent Vallet. Année 2008-2009

Java - TP3. Nicolas Baudru, Carine Guivier-Curien, Laurent Vallet. Année 2008-2009 Java - TP3 Nicolas Baudru, Carine Guivier-Curien, Laurent Vallet Année 2008-2009 Le but de ce TD est d'écrire une application client/serveur de type msn : 1. Des clients se connectent à un serveur 2. Un

Plus en détail

Le monitoring de flux réseaux à l'in2p3 avec EXTRA

Le monitoring de flux réseaux à l'in2p3 avec EXTRA Le monitoring de flux réseaux à l'in2p3 avec EXTRA Journée JoSy «Supervision systèmes et réseaux dans un laboratoire de recherche» 27 mars 2008, ENS Paris Denis Pugnère, CNRS / IN2P3 / IPNL basé sur une

Plus en détail

Serveur de travail collaboratif Michaël Hoste -

Serveur de travail collaboratif Michaël Hoste - Serveur de travail collaboratif Michaël Hoste - Table des matières 1. Qu'est ce qu'un serveur de travail collaboratif?...2 2. Pourquoi ce projet?...2 3. Possibilités d'utilisation dans le cadre de l'université...3

Plus en détail

TecLocal 4.0. Manuel d'installation: Mode acheteur & multiutilisateurs

TecLocal 4.0. Manuel d'installation: Mode acheteur & multiutilisateurs Tec Local 4.0 Manuel d'installation : Mode acheteur & multi-utilisateurs (client) TecLocal 4.0 Manuel d'installation: Mode acheteur & multiutilisateurs (client) Version: 1.0 Auteur: TecCom Solution Management

Plus en détail

GIR Titan-Hyperion Prérequis du système

GIR Titan-Hyperion Prérequis du système GIR Titan-Hyperion Prérequis du système www.gir.fr info@gir.fr Version 1.0-9, mai 2011 2 Copyright c 2004-2011 klervi. All rights reserved. La reproduction et la traduction de tout ou partie de ce manuel

Plus en détail

Desktop Manager 2.8 Guide de mise à jour. Janvier 2014

Desktop Manager 2.8 Guide de mise à jour. Janvier 2014 Desktop Manager 2.8 Guide de mise à jour Janvier 2014 Ce document d'aide présente une méthodologie pour migrer d'une ancienne version de Desktop Manager vers la nouvelle version 2.8. Elle comporte deux

Plus en détail

Logiciels libres et sécurité

Logiciels libres et sécurité Logiciels libres et sécurité Frédéric Schütz, PhD schutz@mathgen.ch Groupe romand des Utilisateurs de Linux et Logiciels Libres http://www.linux gull.ch/ Une image négative reste liée à Linux, celle des

Plus en détail

Gestion du parc informatique matériel et logiciel de l Ensicaen. Rapport de projet. Spécialité Informatique 2 e année. SAKHI Taoufik SIFAOUI Mohammed

Gestion du parc informatique matériel et logiciel de l Ensicaen. Rapport de projet. Spécialité Informatique 2 e année. SAKHI Taoufik SIFAOUI Mohammed 6, bd maréchal Juin F-14050 Caen cedex 4 Spécialité Informatique 2 e année Rapport de projet Gestion du parc informatique matériel et logiciel de l Ensicaen SAKHI Taoufik SIFAOUI Mohammed Suivi ENSICAEN

Plus en détail

La Gestion Électronique des Documents avec Open ERP

La Gestion Électronique des Documents avec Open ERP La Gestion Électronique des Documents avec Open ERP La Gestion Électronique des Documents avec Open ERP V e r s i o n d u d o c u m e n t V1.0 Introduction...4 I Installer la GED dans Open ERP...5 1 Les

Plus en détail

Vérification d'un fonctionnement attendu Supervision

Vérification d'un fonctionnement attendu Supervision Cédric TEMPLE Supervision? Vérification d'un fonctionnement attendu Supervision Physiques: Disques, CPU, DIMM,... OS: CPU, RAM, SWAP, users connectés,... Applicatifs: processus, nombre, messages dans les

Plus en détail

Explication des statistiques

Explication des statistiques Explication des statistiques Sources : http://www.eolas.fr/8-conseil/65-interpreter-vos-statistiques-webalizer.htm http://support.sherweb.com/faqdetails.php?idarticle=68 Un site web est un ensemble de

Plus en détail

Guide d'installation

Guide d'installation 1/7 The-Excalibur.com The Excalibur "hors ligne" : La poker-clock sans connection Internet Guide d'installation 2/7 Sommaire 1 Important... 3 2 Présentation... 3 3 Pré-requis... 3 4 Installation du serveur

Plus en détail

Microsoft OSQL OSQL ou l'outil de base pour gérer SQL Server

Microsoft OSQL OSQL ou l'outil de base pour gérer SQL Server Microsoft OSQL OSQL ou l'outil de base pour gérer SQL Server Suite à mon précédent article concernant MSDE, je me suis rendu compte à partir des commentaires que de nombreux utilisateurs avaient des problèmes

Plus en détail

Guide rapide GFI LANguard

Guide rapide GFI LANguard Guide rapide GFI LANguard INTRODUCTION Bienvenue dans GFI LANguard : Votre solution tout en un pour la gestion de correctifs, l'analyse de vulnérabilités et l'audit réseau. GFI LANguard (ou "LANguard")

Plus en détail

Windows 8 Installation et configuration

Windows 8 Installation et configuration Editions ENI Windows 8 Installation et configuration Collection Ressources Informatiques Extrait 112 Windows 8 Installation et configuration Pour terminer l'application de l'image, nous devons configurer

Plus en détail

BTS Services Informatiques aux Organisations CECI Session 2013. Projet Personnalisé Encadré PPE 3.

BTS Services Informatiques aux Organisations CECI Session 2013. Projet Personnalisé Encadré PPE 3. BTS Services Informatiques aux Organisations CECI Session 2013 Projet Personnalisé Encadré PPE 3. MISE EN OEUVRE DE SERVEURS APPLICATIFS, D'UNE CONNEXION SANS FIL ET DE VLANS Le contexte Le département

Plus en détail

Interactions audio sur le site web du LIA Documentation Technique

Interactions audio sur le site web du LIA Documentation Technique 2007 Interactions audio sur le site web du LIA Documentation Technique Projet 13 - IUP Avignon Master1 TAIM 28/05/2007 2 Projet 13 : Interactions audio sur le site web du LIA Sommaire Composants de l'application...

Plus en détail

OAR Cloud - Une infrastructure légère de Cloud Computing basée sur OAR

OAR Cloud - Une infrastructure légère de Cloud Computing basée sur OAR OAR Cloud - Une infrastructure légère de Cloud Computing basée sur OAR Polytech Grenoble, INRIA 2013 1 / 21 1 2 Plan 3 4 5 2 / 21 1 2 Plan 3 4 5 3 / 21 OAR Cloud Les objectifs du projet Dénition plus précise

Plus en détail

PostgreSQL, le cœur d un système critique

PostgreSQL, le cœur d un système critique PostgreSQL, le cœur d un système critique Jean-Christophe Arnu PostgreSQLFr Rencontres Mondiales du Logiciel Libre 2005 2005-07-06 Licence Creative Commons Paternité - Pas d utilisation commerciale - Partage

Plus en détail

Conduite et Gestion de Projet - Cahier des charges

Conduite et Gestion de Projet - Cahier des charges Conduite et Gestion de Projet - Cahier des charges 1 Introduction Sophie Toulouse LIPN - Université Paris 13 +33.1.49.40.40.73 99 av. Jean-Baptiste Clément toulouse@lipn.univ-paris13.fr 93430 Villetaneuse

Plus en détail

LANDPARK NETWORK IP LANDPARK NETWORK IP VOUS PERMET D'INVENTORIER FACILEMENT VOS POSTES EN RÉSEAU

LANDPARK NETWORK IP LANDPARK NETWORK IP VOUS PERMET D'INVENTORIER FACILEMENT VOS POSTES EN RÉSEAU LANDPARK NETWORK IP Avril 2014 LANDPARK NETWORK IP VOUS PERMET D'INVENTORIER FACILEMENT VOS POSTES EN RÉSEAU Landpark NetworkIP est composé de trois modules : Un module Serveur, que l'on installe sur n'importe

Plus en détail

RapidMiner. Data Mining. 1 Introduction. 2 Prise en main. Master Maths Finances 2010/2011. 1.1 Présentation. 1.2 Ressources

RapidMiner. Data Mining. 1 Introduction. 2 Prise en main. Master Maths Finances 2010/2011. 1.1 Présentation. 1.2 Ressources Master Maths Finances 2010/2011 Data Mining janvier 2011 RapidMiner 1 Introduction 1.1 Présentation RapidMiner est un logiciel open source et gratuit dédié au data mining. Il contient de nombreux outils

Plus en détail

RAPPORT DE STAGE GENERATION DE TESTS POUR AMELIORER DES OUTILS DE CALCUL DE TEMPS D'EXECUTION PIRE CAS

RAPPORT DE STAGE GENERATION DE TESTS POUR AMELIORER DES OUTILS DE CALCUL DE TEMPS D'EXECUTION PIRE CAS Université Joseph Fourier Département Licence Sciences & Technologie RAPPORT DE STAGE GENERATION DE TESTS POUR AMELIORER DES OUTILS DE CALCUL DE TEMPS D'EXECUTION PIRE CAS Laboratoire d'accueil : Verimag

Plus en détail

Une mosaïque de photos

Une mosaïque de photos Département IMA / 3A (S5) Programmation Structurée 2011/2012 Sujet proposé par J. Dequidt http://laure.gonnord.org/pro/teaching/ Une mosaïque de photos Premier Projet de Développement Logiciel en C Lire

Plus en détail

Présentation de l outil d administration de réseau Nagios

Présentation de l outil d administration de réseau Nagios Date Date Marque Brand Ecrit par Written by Destinataires Recipients Copie Copy jeudi 16 octobre 2003 M. Grégory Bernard Objet - Subject Présentation de l outil d administration de réseau Nagios Très chers,

Plus en détail

Rapport de projet : Construction d'un simulateur pour la gestion de conteneurs sur une plateforme portuaire

Rapport de projet : Construction d'un simulateur pour la gestion de conteneurs sur une plateforme portuaire Rapport de projet : Construction d'un simulateur pour la gestion de conteneurs sur une plateforme portuaire Bouvier Matias - Chaouche Mohamed - Délye Serge - Mommers Alexandre 25 janvier 2011 Master 2

Plus en détail