Difference between revisions of "Network Monitoring"

Un article de lcgwiki.
Jump to: navigation, search
(→‎PerfSONAR 3.2.2)
 
(69 intermediate revisions by 3 users not shown)
Ligne 1: Ligne 1:
  
−
Network Monitoring & Debugging  
+
'''Network Monitoring & Debugging'''
  
−
Page permettant de rassembler l'état d'avancement, les observations et éventuels problèmes observés
+
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  
−
en vue de la réunion technique LCG-France du 16 avril au LPNHE https://indico.in2p3.fr/conferenceDisplay.py?confId=9731
+
https://indico.in2p3.fr/conferenceDisplay.py?confId=9731
 
(et au delà si affinités)
 
(et au delà si affinités)
  
−
== PerfSONAR 3.2.2 ==
+
== Déploiement, MàJ & Configuration PerfSONAR ==
  
−
* GRIF
+
Tous les sites doivent avoir un service perfSONAR-PS opérationel en version 3.3.2 au le 1er avril 2014.
−
** GRIF-IRFU
+
−
** LPNHE
+
* [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]
−
** LAL
+
* [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]
−
** LLR
+
* 10 services, enregistrés dans la GOC DB en version 3.3.2
−
** IPNO
+
** GRIF : IRFU, LPNHE, LAL(+IPNO; les 2 sites partagent la même salle) 
−
* CC-IN2P3
+
** CC-IN2P3
−
* CPPM
+
** CPPM
−
* SUBATECH 
+
** LAPP 
−
* LPSC 
+
** LPC  
−
* LPC
+
** LPSC    
−
JC. Chevaleyre en version 3.3.2    
+
** IPHC   
−
* IPNL 
+
** SUBATECH
−
* IPHC   
+
* En cours ou à voir
−
* LAPP
+
** GRIF : LLR envisagé 
−
02/2014 - P.Seraphin Les serveurs PerfSonar du LAPP sont maintenant en version 3.3.2.
+
** IPNL
−
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
−
* http://maddash.aglt2.org/maddash-webui/
+
** 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
  
−
== Observations en vrac ==
+
== Dashboard : http://maddash.aglt2.org/maddash-webui/ ==
−
** 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...
+
''Ici les questions et observations issues des résultats du dashboard''
−
pb suivi par les experts réseau FR  
+
<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 =====
 +
 
 +
* 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 ([https://ggus.eu/index.php?mode=ticket_info&ticket_id=102924 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)
  
−
== Questions en vrac ==
 
 
== 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''
 +
* 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  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 ==
 +
* Wiki de la task force WLCG : https://twiki.cern.ch/twiki/bin/view/LCG/PerfsonarDeployment
 +
* Site PS-PS : http://psps.perfsonar.net/index.html
 +
* Déploiement via Quattor :
 +
** OK avec la dernière version des templates basé sur le déploiment yum
 +
** profil utilisant Quattor 14.2.1
 +
* 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
  
−
*
+
* 08/04/2014 P.Seraphin : Observation suite à une coupure brutale <br>
−
* 02/2014 (solved by ESNET) - BNL -> T2 FR / IT :  https://ggus.eu/index.php?mode=ticket_info&ticket_id=101637
+
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
Récupérée de « http://lcg.in2p3.fr/wiki/index.php?title=Network_Monitoring&oldid=7274 »