Cas Utilisateur

Surveillance de la Grille au CERN avec Elastic

English version available here.

WLCG-logo.pngLe projet de Grille de calcul mondiale pour le LHC (WLCG) [1] est une collaboration au niveau mondial de plus de 170 centres de calcul répartis dans 42 pays, utilisant plus d'un demi-million de coeurs de processeur et reliant les infrastructures de grilles nationales et internationales. Ce projet permet à plus de 10 000 physiciens d'accéder presque en temps réel aux données du Grand collisionneur de hadrons (LHC), avec une moyenne de deux millions de tâches par jour.

Mission & contexte

La mission du projet WLCG est de fournir des ressources de calcul au niveau mondial afin de stocker, distribuer et analyser les quelques 30 pétaoctets de données générés tous les ans par le Grand collisionneur de hadrons (LHC) du CERN, situé à la frontière franco-suisse. Cette mission nécessite actuellement plus de 300 pétaoctets de disque et 200 pétaoctets de bande magnétique.


L'équipe de Surveillance de la Grille WLCG au CERN est chargée de fournir des outils et des services permettant de surveiller et de comprendre l'infrastructure complexe du WLCG. Sans cette compréhension, il serait impossible d'utiliser efficacement le système. L'équipe a créé de nombreuses applications visant à récupérer, afficher et analyser les données de surveillance. Les différentes applications sont adaptées au public ciblé : vues d’ensemble pour la direction, vues détaillées pour les administrateurs de service et les utilisateurs individuels et illustrations pour le grand public. La plupart de ces applications se basent sur des serveurs web en plus des bases de données relationnelles. Récemment, le volume et la complexité croissants des données de surveillance ont nécessité une évolution vers des technologies de pointe modernes.


La section suivante décrit les trois tâches de surveillance dont nous nous servons comme applications pilotes pour notre évaluation d’Elasticsearch. Ces tâches couvrent plusieurs domaines des activités de calcul de l'infrastructure WLCG : accès et distribution des données, traitement des données et santé et performance des services. Des tableaux de bord dédiés sont affectés à chacun de ces domaines.


La collecte de données du WLCG

Les données recueillies dans le cadre de l'expérience WLCG sont répliquées sur plusieurs sites. Cela permet d'accroître leur rapidité de traitement et de fournir un mécanisme de basculement au cas où l’un des sites serait temporairement indisponible. En moyenne, 25 millions de fichiers sont transférés chaque jour, à une vitesse moyenne de 10 Go/s. Le Tableau de bord des transferts WLCG, illustré en Figure 1, utilise plusieurs filtres (par heure, expérience, pays et site) afin de créer des vues détaillées des mouvements de données.


WLCG Transfers Dashboard.png 

Figure 1. Tableau de bord des transferts WLCG [2]


Les données brutes recueillies par les détecteurs du LHC doivent être traitées. Elles sont ensuite mises à disposition des physiciens afin qu'ils les étudient. De plus, beaucoup de simulations sont créées afin de les comparer avec les données obtenues par les détecteurs du LHC. Toutes les données sont redistribuées au sein de l'infrastructure WLCG. L'application Tableau de bord de surveillance des tâches, illustrée en Figure 2, suit le statut du traitement, de l'analyse et des simulations des données. On compte en moyenne plus de 2 millions de tâches par jour, dont 250 000 tâches simultanées à tout moment donné, réparties entre plus de 170 sites.


CMS Job Monitoring App.png

Figure 2. Application de surveillance des tâches CMS [3]

Chaque site fournit des services différents qui sont testés en continu afin de détecter tout problème le plus rapidement possible. Au total, ce sont plus d'un millier de statistiques qui sont utilisées pour déterminer si les services et les sites fonctionnent comme il se doit. Le Tableau de statut des sites, illustré en Figure 3, stocke, affiche et combine toutes ces statistiques. Les statistiques ont une granularité différente, de quelques minutes à des années. Par exemple, une des statistiques montre si un fichier peut être gravé dans le service de stockage toutes les 60 minutes. Une autre statistique indique le niveau de stockage annuel auquel s'est engagé un site dans le cadre de la collaboration.


Site Status Board.png

Figure 3. Application Tableau de statut des sites (SSB) pour l’une des expériences du WLCG [4]

Base de données relationnelle → Elasticsearch

Les applications actuelles dans ces trois domaines se servent du Cadre du tableau de bord d'expérience (Experiment Dashboard Framework) [5]. Les frontaux web utilisent des bibliothèques Javascript open source, comme jQuery, DataTables et Highcharts ; côté serveur, il s'agit d'Apache et de Python, en plus des bases de données relationnelles. Pour faire face à l'augmentation de l'échelle et de la complexité, nous sommes en train d'évaluer Elasticsearch comme alternative aux bases de données relationnelles.


L'équipe a déjà expérimenté Elasticsearch en terme de production. Le service Messagerie [6] notamment, utilise Elasticsearch pour surveiller le statut de ses services. À l'heure actuelle, il comporte plus de deux millions de documents. Un tableau de bord Kibana a été déployé. Pour des raisons de sécurité, seuls les responsables du service y ont accès. L'information alimente également le moteur Esper [7] chargé de générer des alarmes en cas de problème.


Nous avons débuté notre expérimentation d'Elasticsearch par une évaluation d'Elasticsearch 0.90.0 en 2013. La durée d'insertion et de requête était prometteuse. Parallèlement, l'absence de regroupement de plusieurs champs a empêché une migration complète [8].


L'évaluation s'est poursuivie avec Elasticsearch 1.x afin d'étendre l'utilisation d'Elasticsearch aux trois domaines suivants :

  • Mouvements de transfert de données entre les sites 
  • Traitement des tâches
  • Statut des sites et des services.

Prochains projets Elastic avec le CERN

Nous sommes actuellement en train d'évaluer les autres avantages que nous pouvons tirer des composants Elasticsearch. L'évaluation en cours porte sur plusieurs aspects indépendants :

  • Adopter Logstash afin d'insérer des données dans le cluster
  • Utiliser un seul cluster Elasticsearch pour tous les différents cas d'utilisation, tout en s'assurant que l'autorisation de chaque propriétaire peut être respectée
  • Décrire les différents types de documents et d'index nécessaires pour chacune des applications
  • Évaluer Kibana concernant la visualisation. Ce domaine précis a une priorité plus faible car l'équipe a déjà mis en oeuvre les interfaces web nécessaires ; nos efforts sont centrés sur la modification des interfaces web pour qu’elles lisent les données depuis Elasticsearch.

Même s'il est encore trop tôt pour dresser un bilan définitif, l'expérience avec Elasticsearch s'est avérée très positive jusqu'à maintenant, et nous continuerons d'étendre notre évaluation.


REFERENCES

1. http://wlcg.web.cern.ch

2. http://dashb-wlcg-transfers.cern.ch

3. http://dashb-cms-job.cern.ch/dashboard/templates/web-job2

4. http://dashb-ssb.cern.ch

5. http://dashboard.cern.ch

6. http://mig.web.cern.ch/mig

7. http://www.espertech.com/esper

8. http://iopscience.iop.org/article/10.1088/1742-6596/513/3/032048

Pablo Saiz.png

Pablo Saiz est un informaticien espagnol qui a passé ces quinze dernières années au service du CERN. Il y a travaillé sur plusieurs domaines liés au calcul distribué pour le WLCG (Grille de calcul mondiale du LHC). Il était le principal développeur et le responsable du projet AliEn, l'environnement ALICE de la Grille. AliEn est le système utilisé par ALICE (l’une des expériences du LHC) visant à distribuer les données et la charge de travail aux plus de soixante-dix sites participant à l'expérience. À l'heure actuelle, il dirige une équipe chargée de surveiller les applications utilisées par le WLCG. L'équipe fournit des applications qui permettent de surveiller la distribution des données, le traitement des tâches et le statut du service. Pablo est le principal concepteur des outils tels que le Tableau de statut des sites (SSB) et la Surveillance de disponibilité du service (SAM3).