Le détecteur CMS du CERN souffrait de problèmes de cardinalité élevée
La grande image: L’Organisation européenne pour la recherche nucléaire (CERN) abrite l’un des projets d’ingénierie et scientifiques les plus ambitieux jamais entrepris par l’homme. Le Grand collisionneur de hadrons (LHC) est l’accélérateur de particules le plus grand et le plus énergétique au monde. Il est utilisé par les scientifiques pour analyser les preuves de la structure du monde subatomique. Dans ce processus, le LHC est capable de générer des dizaines de pétaoctets de données chaque année.
Le CERN a récemment dû mettre à niveau ses systèmes informatiques back-end en vue de la nouvelle phase expérimentale du Grand collisionneur de hadrons (LHC Run 3). Cette phase devrait générer 1 pétaoctet de données par jour jusqu’à fin 2025. Les systèmes de bases de données précédents n’étaient plus suffisants pour gérer les données à « haute cardinalité » produites par les principales expériences du collisionneur, comme CMS.
Le Solénoïde Compact à Muons (CMS) est le détecteur polyvalent du LHC doté d’un vaste programme de physique. Il englobe l’étude du modèle standard (y compris le boson de Higgs) et la recherche de dimensions et de particules supplémentaires pouvant constituer la matière noire. Le CERN décrit cette expérience comme l’une des plus grandes collaborations scientifiques de l’histoire, impliquant environ 5 500 personnes provenant de 241 instituts dans 54 pays différents.
CMS et d’autres expériences LHC ont connu une phase de mise à niveau importante de 2018 à 2022 et sont désormais prêtes à reprendre les collisions de particules subatomiques au cours de la période de collecte de données de trois ans « Run 3 ». Pendant l’arrêt, les experts du CERN ont également procédé à des mises à niveau substantielles des systèmes de détection et des infrastructures informatiques prenant en charge CMS.
Brij Kishor Jashal, un scientifique collaborant avec CMS, a mentionné que son équipe regroupait 30 téraoctets de données sur une période de 30 jours pour surveiller les performances de l’infrastructure. Il a expliqué que les opérations du Run 3 génèrent une luminosité plus élevée, ce qui entraîne une augmentation substantielle du volume de données. Le système de surveillance back-end précédent reposait sur la base de données de séries chronologiques open source (TSDB) InfluxDB, qui utilise des algorithmes de compression pour gérer efficacement ces données, ainsi que sur la base de données de surveillance Prometheus.
Cependant, InfluxDB et Prometheus ont rencontré des problèmes de performances, d’évolutivité et de fiabilité, en particulier lorsqu’ils traitaient des données à cardinalité élevée. Une cardinalité élevée fait référence à la prévalence de valeurs répétées et à la possibilité de redéployer les applications plusieurs fois sur de nouvelles instances. Pour relever ces défis, l’équipe de surveillance de CMS a choisi de remplacer InfluxDB et Prometheus par la base de données VictoriaMetrics TSDB.
VictoriaMetrics sert désormais à la fois de stockage back-end et de système de surveillance pour CMS, résolvant efficacement le problème de cardinalité rencontré auparavant. Jashal a noté que l’équipe CMS est actuellement satisfaite des performances des clusters et des services. Même s’il reste encore de la place pour l’évolutivité, les services fonctionnent en « mode haute disponibilité » au sein des clusters Kubernetes dédiés de CMS pour offrir des garanties de fiabilité améliorées. Le centre de données du CERN s’appuie sur un service OpenStack qui s’exécute sur un cluster de machines x86 robustes.
