HPC Containers for EBRAINS: Towards Portable Cross-Domain Software Environment

Cet article présente une méthode hybride basée sur Apptainer au sein de l'infrastructure EBRAINS qui permet de déployer des environnements logiciels scientifiques portables et performants sur des clusters HPC variés, en encapsulant des piles MPI et CUDA tout en préservant les performances natives grâce à l'utilisation dynamique des ressources matérielles hôtes.

L'essentiel

🏠 Le Problème : La "Maison" qui ne rentre pas dans le camion

Imaginez que vous êtes un chercheur en neurosciences (vous étudiez le cerveau). Vous avez construit une maison scientifique (votre logiciel de simulation) qui est très complexe. Elle contient des milliers de meubles, des circuits électriques spéciaux et des machines de haute technologie (des supercalculateurs).

Le problème ? Chaque ville (chaque centre de supercalculateurs) a ses propres règles de construction, ses propres électriciens et ses propres normes de sécurité.

• Si vous essayez de construire votre maison sur place à chaque fois, vous devez engager un architecte local, acheter des matériaux spécifiques et passer des mois à tout adapter.
• Souvent, ça ne marche pas du tout, ou ça marche mal, et vos résultats changent selon l'endroit où vous êtes. C'est le "chaos logiciel".

📦 La Solution : Le Conteneur "Tout-en-un" (Apptainer)

Les auteurs de ce papier ont eu une idée géniale : au lieu de construire la maison sur place, on la met dans un conteneur de transport étanche.

Imaginez un grand conteneur de camion (comme ceux qu'on voit dans les ports). À l'intérieur, il y a :

1. Votre maison complète (le logiciel).
2. Tous vos meubles, vos outils et vos manuels d'instructions (les dépendances logicielles).
3. Votre propre électricien et votre propre plombier (les bibliothèques logicielles).

Ce conteneur est conçu pour être portable. Vous pouvez le charger dans un camion, le conduire à Berlin, à Prague ou à Athènes, et le décharger. La maison à l'intérieur reste exactement la même, peu importe où vous êtes.

C'est ce qu'on appelle Apptainer (un type de conteneur conçu pour les supercalculateurs).

⚡ Le Défi Spécial : Garder la vitesse "Super"

Le vrai défi avec les supercalculateurs, c'est la vitesse.

• Le problème : Si vous mettez votre maison dans un conteneur, elle risque de devenir plus lente. Pourquoi ? Parce que le conteneur doit parfois "parler" avec le système de la ville (le supercalculateur) pour utiliser les câbles ultra-rapides (réseau) ou les machines à GPU (cartes graphiques).
• L'analogie : C'est comme si votre maison avait besoin de brancher son électricité sur le réseau de la ville. Si le conteneur est mal conçu, il faut passer par un transformateur lent, et vos lumières clignotent.

Les chercheurs voulaient savoir : Peut-on mettre tout ça dans un conteneur sans perdre de vitesse ?

🔍 L'Expérience : Le Test de Course

Pour vérifier cela, ils ont pris deux centres de supercalculateurs très différents (Karolina en République tchèque et JURECA en Allemagne) et ont fait courir deux types de courses :

1. Les courses de fond (Micro-benchmarks) : Ils ont testé la vitesse pure de communication entre les ordinateurs (comme tester la vitesse d'une voiture sur un circuit vide).
   • Résultat : Le conteneur est aussi rapide que la voiture qui roule directement sur la route. La différence est infime, presque invisible.
2. Les marathons réels (Simulations de cerveau) : Ils ont fait tourner de vraies simulations de neurones (Arbor et NEURON).
   • Résultat : Pour les processeurs classiques (CPU), c'est parfait. Le conteneur est aussi rapide que l'installation directe.
   • Petite nuance : Pour les puces graphiques (GPU), il y a un petit ralentissement constant (environ 15-18 %). C'est comme si le conteneur ajoutait un petit poids sur la voiture, mais elle arrive toujours à destination très vite. C'est un compromis acceptable pour la facilité de transport.

🛠️ La Méthode Magique : Le "Pont" (PMIx)

Comment font-ils pour que le conteneur utilise les câbles ultra-rapides du centre de calcul sans les installer à l'intérieur ?
Ils utilisent une astuce appelée PMIx.

• L'analogie : Imaginez que votre conteneur a un interphone. Au lieu d'essayer de recâbler toute la maison, il appelle le concierge du bâtiment (le système du supercalculateur) et lui dit : "Hé, je veux utiliser ton câble ultra-rapide". Le concierge ouvre la porte et connecte le câble directement.
• Cela permet au conteneur d'utiliser la puissance brute du site sans avoir besoin de tout installer dedans.

🌟 Pourquoi c'est important pour tout le monde ?

1. La Portabilité : Un chercheur peut créer son logiciel une seule fois, le mettre dans le conteneur, et l'envoyer à n'importe quel supercalculateur dans le monde. Fini les nuits blanches à réinstaller des logiciels !
2. La Confiance : Comme le conteneur est toujours le même, les résultats sont reproductibles. Si vous faites une expérience en France et que votre collègue la refait en Grèce, vous obtiendrez exactement le même résultat.
3. L'Automatisation : À l'avenir, les chercheurs n'auront plus besoin d'être des experts en informatique. Ils pourront simplement "télécharger" le conteneur prêt à l'emploi, comme on télécharge une application sur son téléphone.

En résumé

Ce papier dit : "Oui, on peut emballer des logiciels scientifiques complexes dans des boîtes étanches et les envoyer partout dans le monde sans qu'ils perdent leur vitesse."

C'est comme passer d'une construction artisanale, fragile et unique à chaque fois, à une usine de préfabrication où chaque maison est parfaite, rapide et prête à être installée n'importe où. C'est une révolution pour la science du cerveau ! 🧠🚀

Résumé technique

1. Problématique

Le déploiement de flux de travail scientifiques complexes et distribués sur des sites de Calcul Haute Performance (HPC) hétérogènes se heurte à des défis majeurs de portabilité et de reproductibilité. Les chercheurs font souvent face à des conflits de versions, des chaînes d'outils incompatibles et des configurations de compilation spécifiques à chaque site. Bien que la conteneurisation (notamment avec Apptainer) offre une solution pour encapsuler les environnements logiciels, il reste un obstacle critique à surmonter : garantir que les applications intensives utilisant MPI (Message Passing Interface) et CUDA (pour les GPU) puissent fonctionner dans un conteneur sans sacrifier les performances du matériel nu (bare-metal).

Le défi spécifique réside dans la nature des infrastructures HPC : les conteneurs ne peuvent pas encapsuler les noyaux hôtes, les pilotes propriétaires (GPU) ou les interconnexions haute vitesse (InfiniBand). Une mauvaise gestion de ces dépendances peut entraîner des goulots d'étranglement de communication, une dégradation des performances ou une incompatibilité des pilotes.

2. Méthodologie

Les auteurs ont évalué la faisabilité et les performances d'images conteneurisées portables pour un sous-ensemble représentatif de la Distribution Logicielle EBRAINS (ESD), un écosystème basé sur Spack contenant environ 80 packages principaux.

• Stratégie d'Hybridation PMIx : L'approche repose sur une stratégie de conteneurisation hybride basée sur PMIx (Process Management Interface).
  • Le conteneur contient une pile MPI complète (Open MPI 5) compilée avec ses propres bibliothèques internes (UCX, PRRTE, etc.), rendant le conteneur autonome vis-à-vis des installations MPI de l'hôte.
  • Cependant, pour la communication réseau, le conteneur utilise l'interface PMIx de l'hôte (via Slurm) pour découvrir les points de terminaison et gérer les ressources. Cela permet de contourner la nécessité de builds spécifiques au site tout en exploitant les interconnexions matérielles (InfiniBand) et les GPU de l'hôte.
• Environnements de test : Les benchmarks ont été réalisés sur deux clusters de production européens : Karolina (République tchèque) et JURECA-DC (Allemagne).
• Outils de Benchmarking :
  • Micro-benchmarks : OSU (initialisation MPI, latence point-à-point) et NCCL (tests de communication GPU) pour quantifier la surcharge de communication.
  • Applications réelles : Les simulateurs de neurosciences Arbor (CPU et GPU) et NEURON (CPU) pour évaluer le passage à l'échelle (scaling) et les performances réelles.
• Comparaison : Une comparaison rigoureuse a été effectuée entre l'exécution native (bare-metal) et l'exécution dans des conteneurs Apptainer, en variant les tailles de messages, le nombre de nœuds et les configurations matérielles (CPU/GPU).

3. Contributions Clés

1. Validation de la Portabilité MPI/CUDA : Démonstration qu'il est possible de créer des images conteneurisées portables qui exploitent correctement les pilotes et le matériel spécifiques à l'hôte (InfiniBand, NVLink) sans recompilation, en utilisant une stratégie PMIx.
2. Flux de Construction Automatisé (CI/CD) : Proposition d'un flux de travail intégré dans l'outil dedal (basé sur Spack) permettant de construire des images sur des nœuds de calcul HPC en utilisant des systèmes de fichiers locaux pour éviter les goulots d'étranglement des systèmes de fichiers partagés (problème d'inodes).
3. Méthodologie de Débogage Avancée : Au-delà des mesures de performance brutes, l'article met en avant l'analyse des journaux de débogage (debug logs) pour détecter activement les comportements sous-optimaux (ex: utilisation de transports réseau non optimaux) qui pourraient passer inaperçus lors des tests standards.
4. Intégration dans l'Infrastructure EBRAINS : Les résultats servent de fondation pour intégrer la génération de conteneurs HPC portables directement dans le pipeline CI de l'ESD, permettant aux chercheurs de déployer des environnements identiques et vérifiés sur n'importe quel système HPC.

4. Résultats

Les résultats montrent une performance globalement excellente, avec des nuances selon le type de charge de travail :

• Initialisation MPI (OSU Init) : Les résultats sont contrastés. Sur Karolina, le conteneur présente une surcharge d'initialisation croissante avec le nombre de nœuds. Sur JURECA, le conteneur est même 50 % plus rapide que l'exécution native, suggérant que la configuration MPI conteneurisée évite certaines étapes de découverte coûteuses de l'hôte.
• Latence de Communication (OSU Latency) : La surcharge est négligeable (< 0,5 µs) pour toutes les tailles de messages, tant en intra-nœud qu'en inter-nœud. La conteneurisation n'introduit pas de pénalité pour les applications sensibles à la latence.
• Communication GPU (NCCL) : Les tests de bande passante (AllReduce) montrent une indistinguabilité quasi totale entre le natif et le conteneur. Les écarts sont inférieurs à 1,3 %, confirmant que l'accès direct aux GPU (GPUDirect RDMA, NVLink) fonctionne correctement à l'intérieur d'Apptainer.
• Applications Neurosciences (CPU) : Pour Arbor et NEURON sur CPU, l'efficacité du parallélisme est comparable entre le natif et le conteneur. Aucune dégradation systématique n'est observée, même à grande échelle (jusqu'à 256 nœuds).
• Applications Neurosciences (GPU) : Une surcharge relative constante de 12 % à 19 % est observée pour les simulations Arbor sur GPU. Cette surcharge est fixe (liée au démarrage ou à l'initialisation par nœud) et ne s'aggrave pas avec le nombre de nœuds. Elle est attribuée à des mécanismes d'initialisation spécifiques (potentiellement liés aux versions CUDA ou à l'I/O du conteneur) qui nécessitent une investigation future, mais ne compromet pas la scalabilité.

5. Signification et Impact

Cette étude démontre la viabilité d'une méthodologie simple et reproductible pour découpler les environnements logiciels des infrastructures sous-jacentes dans le domaine du HPC.

• Pour la communauté scientifique : Elle permet aux chercheurs de déployer des environnements de simulation complexes (comme l'ESD) sur n'importe quel cluster HPC sans expertise technique approfondie en compilation ou en configuration système.
• Pour l'infrastructure EBRAINS : Cela ouvre la voie à des pipelines automatisés garantissant l'exécution optimisée et vérifiée des performances sur des architectures variées.
• Pour la fiabilité des systèmes : L'approche de benchmarking double (natif vs conteneur) s'est révélée être un outil de diagnostic puissant, capable de révéler des malconfigurations matérielles ou logicielles sur les systèmes de production qui échappaient aux surveillances conventionnelles.
• Avenir : Le travail pave la voie vers des "flux logiciels" (software streaming) et des sous-ensembles de conteneurs sécurisés pour le traitement de données sensibles (cliniques), tout en maintenant une reproductibilité scientifique stricte.

En résumé, bien qu'une légère surcharge persiste sur les charges de travail GPU spécifiques, la conteneurisation HPC basée sur Apptainer et PMIx est validée comme une solution robuste pour la portabilité et la reproductibilité des workflows de neurosciences à grande échelle.