Difference between revisions of "Network Monitoring"

Un article de lcgwiki.
Jump to: navigation, search
(Déploiement et MàJ PerfSONAR)
 
(36 intermediate revisions by 2 users not shown)
Ligne 6: Ligne 6:
 
(et au delà si affinités)
 
(et au delà si affinités)
  
== Déploiement et MàJ PerfSONAR  ==
+
== Déploiement, MàJ & Configuration PerfSONAR  ==
  
 
Tous les sites doivent avoir un service perfSONAR-PS opérationel en version 3.3.2 au le 1er avril 2014.  
 
Tous les sites doivent avoir un service perfSONAR-PS opérationel en version 3.3.2 au le 1er avril 2014.  
Les 2 instances perfSONAR (pour les tests de latency et de bandwith) doivent par ailleurs '''être enregistrées dans la GOC DB'''.
+
Services BWTCL déclarés : https://goc.egi.eu/portal/index.php?Page_Type=Services&serviceType=net.perfSONAR.Bandwidth&serviceTypeSearch=&ngi=NGI_FRANCE
+
* [https://goc.egi.eu/portal/index.php?Page_Type=Services&serviceType=net.perfSONAR.Bandwidth&serviceTypeSearch=&ngi=NGI_FRANCE Instances perfSONAR BWTCL déclarés dans la GOCDB]
Services OWAMP :https://goc.egi.eu/portal/index.php?Page_Type=Services&serviceType=net.perfSONAR.Latency&serviceTypeSearch=&ngi=NGI_FRANCE
+
* [https://goc.egi.eu/portal/index.php?Page_Type=Services&serviceType=net.perfSONAR.Latency&serviceTypeSearch=&ngi=NGI_FRANCE Instances perfSONAR OWAMP déclarés dans la GOCDB]
* GRIF
+
* 10 services, enregistrés dans la GOC DB en version 3.3.2
** GRIF-IRFU
+
** GRIF : IRFU, LPNHE, LAL(+IPNO; les 2 sites partagent la même salle) 
** LPNHE
+
** CC-IN2P3 
** LAL
+
** CPPM
** LLR
+
** LAPP 
** IPNO
+
** LPC   
* CC-IN2P3
+
** LPSC 
* CPPM  
+
** IPHC  
* SUBATECH
+
** SUBATECH  
* LPSC 
+
* En cours ou à voir
* LPC en version 3.3.2
+
** GRIF : LLR envisagé 
* IPNL 
+
** IPNL
* IPHC en version 3.3.2 
 
Les tests de latences fonctionnent à peu près, la bandwidth, c'est beaucoup moins bon. Pas mal de soucis avec les démons (remplissent les logs, prennent 100% de CPU, etc.).
 
* LAPP en version 3.3.2
 
P.Seraphin
 
lapp-ps01.in2p3.fr pour les mesures de bande passante
 
lapp-ps02.in2p3.fr pour les mesures de latence.
 
  
== Dashboard ==
+
* Jérôme Bernier : Reconfiguration des Access-list (Ouvertures des ports standard) de tous les serveurs PerfSONAR des labos IN2P3 du [https://grid-deployment.web.cern.ch/grid-deployment/wlcg-ops/perfsonar/conf/central/testdefs/jsons/ mesh FR] par Jérôme Bernier
 +
** Veiller à conserver la configuration par défaut des services
 +
** cf http://fasterdata.es.net/performance-testing/perfsonar/ps-howto/perfsonar-firewall-requirements/
 +
** Guillaume Philippon : Correction des ports par défaut dans les templates standard Quattor.
 +
** Augmentation du range OWAMP ports selon recommandation - testports 8760-9960
 +
 
 +
== Dashboard : http://maddash.aglt2.org/maddash-webui/ ==
 
''Ici les questions et observations issues des résultats du dashboard''  
 
''Ici les questions et observations issues des résultats du dashboard''  
cf http://maddash.aglt2.org/maddash-webui/ <br>
+
<br>
 +
=====[https://indico.in2p3.fr/getFile.py/access?contribId=5&resId=1&materialId=slides&confId=9731 16/04/2014 Présentation F.Schaer] =====
 +
 
 +
===== Observations & Problèmes divers =====
  
===== BWCTL No throughput data =====
+
* Tests bi-directionnels OWAMP (tests de latence) - BWCTL (tests de bande passante)
  
* pas de data pour les tests à destination du LPC et du LAL --[[User:Chollet|Chollet]] 11:38, 2 avril 2014 (CEST)
+
* IPHC : Les tests de latences fonctionnent à peu près, la bandwidth, c'est beaucoup moins bon. Pas mal de soucis avec les démons (remplissent les logs, prennent 100% de CPU, etc.). Le service perfSONAR-BUOY n'est pas démarré 'Not running' http://sbgperfps2.in2p3.fr/toolkit/  
Message For Current Status: No throughput data returned for direction where src=lpnhe-psb.in2p3.fr dst=clrperf-bwctl.in2p3.fr
 
[http://maddash.aglt2.org/serviceTest/bandwidthGraph.cgi?url=http://lapp-ps01.in2p3.fr:8085/perfSONAR_PS/services/pSB&dst=clrperf-bwctl.in2p3.fr&src=lapp-ps01.in2p3.fr&length=2592000  Graph BWCTL LAPP=>LPC] par intermittence ??? pas de résultats depuis le 23 mars
 
  
 
== Observations avec perfSONAR ==
 
== Observations avec perfSONAR ==
Ligne 56: Ligne 57:
 
== GGUS en cours ou récents en rapport ==
 
== GGUS en cours ou récents en rapport ==
 
''Ici les tickets GGUS ouverts, récents en lien avec le réseau''
 
''Ici les tickets GGUS ouverts, récents en lien avec le réseau''
 
+
* 04/2014 BNL -> LPC  (timeout & FTS transfer rate ~300-400 kB/s - dégradation depuis février 2014)redémarrage des serveurs côté LPC : https://ggus.eu/index.php?mode=ticket_info&ticket_id=102924
* 02/2014 (solved by ESNET) - BNL -> T2 FR / IT :  https://ggus.eu/index.php?mode=ticket_info&ticket_id=101637
+
* 02/2014 BNL -> FR / IT T2s (solved by ESNET Pb de perte de paquest sur un lien LHCONE STARLIGHT entre ESnet et GEANT) :  https://ggus.eu/index.php?mode=ticket_info&ticket_id=101637
  
 
== Infos diverses ==
 
== Infos diverses ==
Ligne 65: Ligne 66:
 
** OK avec la dernière version des templates basé sur le déploiment yum
 
** OK avec la dernière version des templates basé sur le déploiment yum
 
** profil utilisant Quattor 14.2.1  
 
** profil utilisant Quattor 14.2.1  
* 28/02/14 F.SChaer :Pour information : si et **quand** vous mettrez vos perfsonar à jour vers la dernière version 3.3.2 ( => yum upgrade) : vous devrez soit rebooter les machines, soit lancer la commande suivante :
+
* 28/02/14 F.Schaer : Observation lors de la mise à jour vers la version 3.3.2 ( => yum upgrade)<br>
 +
Les scripts init n'étant pas en mesure de relancer les archives perfsonar, il est nécessaire soit de rebooter les machines, soit de lancer la commande suivante :
 
  /opt/perfsonar_ps/toolkit/scripts/discover_external_address --restart_services
 
  /opt/perfsonar_ps/toolkit/scripts/discover_external_address --restart_services
Les scripts init ne seront pas en mesure de relancer les archives perfsonar
+
 
 +
* 08/04/2014 P.Seraphin : Observation suite à une coupure brutale <br>
 +
Les serveurs perfsonar (v3.3.2) du LAPP acceptent les requêtes entrantes mais n'interrogent plus les serveurs distants. La situation est revenue à la normale moyennant les manipulations suivantes
 +
cd /opt/perfsonar_ps/perfsonarbuoy_ma/etc
 +
mv owmesh.conf owmesh.conf.old
 +
wget  http://anonsvn.internet2.edu/svn/perfSONAR-PS/trunk/perfSONAR_PS-perfSONARBUOY/etc/owmesh.conf
 +
/opt/perfsonar_ps/mesh_config/bin/generate_configuration
 +
chown perfsonar:perfsonar owmesh.conf
 +
/etc/init.d/perfsonarbuoy_owp_collector restart  # ou /etc/init.d/perfsonarbuoy_bw_collector restart
 +
/etc/init.d/perfsonarbuoy_owp_master restart      # ou /etc/init.d/perfsonarbuoy_bw_master restart
 +
/etc/init.d/perfsonarbuoy_ma restart

Latest revision as of 16:41, 10 juin 2014

Network Monitoring & Debugging

Page permettant de rassembler l'état d'avancement, les observations et éventuels problèmes observésen vue de la réunion technique LCG-France du 16 avril au LPNHE https://indico.in2p3.fr/conferenceDisplay.py?confId=9731 (et au delà si affinités)

Déploiement, MàJ & Configuration PerfSONAR

Tous les sites doivent avoir un service perfSONAR-PS opérationel en version 3.3.2 au le 1er avril 2014.

Dashboard : http://maddash.aglt2.org/maddash-webui/

Ici les questions et observations issues des résultats du dashboard

16/04/2014 Présentation F.Schaer
Observations & Problèmes divers
  • Tests bi-directionnels OWAMP (tests de latence) - BWCTL (tests de bande passante)
  • IPHC : Les tests de latences fonctionnent à peu près, la bandwidth, c'est beaucoup moins bon. Pas mal de soucis avec les démons (remplissent les logs, prennent 100% de CPU, etc.). Le service perfSONAR-BUOY n'est pas démarré 'Not running' http://sbgperfps2.in2p3.fr/toolkit/

Observations avec perfSONAR

Ici les observations faites avec le monitoring perfSONAR susceptibles d'être relayées au niveau des experts réseau

  • 03/2014 IRFU - F.Schaer : Forte asymétrie des flux constatée avec perfSONAR avec un débit sortant vers LHCONE extrêmement dégradé depuis l'IRFU : 20mbits vers Strasbourg par exemple...

pb suivi par les experts réseau FR

Observations avec FTS par les VOs

Ici les observations faites par les expériences

  • ATLAS S.Jézéquel
    • LPC -> BNL/TRIUMF (GGUS: 102924) : Low transfer rate (300-400 kB/s) for all transfers
    • IRFU -> BNL/TRIUMF : Low transfer rate : Frederic Shaer is working on it with Renater (issue pointed with Perfsonar)
    • LAL -> TOKYO : Issue raised few years ago and never solved. It is still visible with current FTS transfers (~100 kB/s)

GGUS en cours ou récents en rapport

Ici les tickets GGUS ouverts, récents en lien avec le réseau

Infos diverses

Les scripts init n'étant pas en mesure de relancer les archives perfsonar, il est nécessaire soit de rebooter les machines, soit de lancer la commande suivante :

/opt/perfsonar_ps/toolkit/scripts/discover_external_address --restart_services
  • 08/04/2014 P.Seraphin : Observation suite à une coupure brutale

Les serveurs perfsonar (v3.3.2) du LAPP acceptent les requêtes entrantes mais n'interrogent plus les serveurs distants. La situation est revenue à la normale moyennant les manipulations suivantes

cd /opt/perfsonar_ps/perfsonarbuoy_ma/etc
mv owmesh.conf owmesh.conf.old
wget  http://anonsvn.internet2.edu/svn/perfSONAR-PS/trunk/perfSONAR_PS-perfSONARBUOY/etc/owmesh.conf
/opt/perfsonar_ps/mesh_config/bin/generate_configuration
chown perfsonar:perfsonar owmesh.conf
/etc/init.d/perfsonarbuoy_owp_collector restart   # ou /etc/init.d/perfsonarbuoy_bw_collector restart
/etc/init.d/perfsonarbuoy_owp_master restart      # ou /etc/init.d/perfsonarbuoy_bw_master restart
/etc/init.d/perfsonarbuoy_ma restart