Infrastructure Fédérée de Calcul et de Stockage Hétérogène pour PUNCH4NFDI

1. Introduction

Particles, Universe, NuClei and Hadrons for the National Research Data Infrastructure (PUNCH4NFDI) est un consortium allemand majeur financé par la DFG (Deutsche Forschungsgemeinschaft). Il représente environ 9 000 scientifiques des communautés de la physique des particules, de l'astrophysique, de l'astroparticule, de la physique hadronique et de la physique nucléaire. L'objectif principal du consortium est d'établir une plateforme de données scientifiques fédérée et FAIR (Faciles à trouver, Accessibles, Interopérables, Réutilisables). Cette plateforme vise à fournir un accès transparent aux diverses ressources de calcul et de stockage hétérogènes réparties entre les institutions participantes, en répondant aux défis communs des volumes massifs de données et des algorithmes complexes et gourmands en ressources. Ce document se concentre sur les concepts architecturaux — Compute4PUNCH et Storage4PUNCH — développés pour fédérer ces ressources apportées en nature.

2. Infrastructure Fédérée de Calcul Hétérogène – Compute4PUNCH

Le concept Compute4PUNCH relève le défi de fournir un accès unifié à un large éventail de ressources de calcul existantes à haut débit (HTC), à haute performance (HPC) et de ressources cloud, contribuées par diverses institutions. Ces ressources diffèrent par leur architecture, leur système d'exploitation, leurs logiciels et leur authentification. La contrainte clé est de minimiser les modifications apportées aux systèmes opérationnels existants, partagés par plusieurs communautés.

2.1 Architecture de base & Stratégie d'intégration

La stratégie emploie un système de traitement par lots fédéré en surcouche. Au lieu de modifier les gestionnaires de ressources locaux (comme SLURM, PBS), un pool de surcouche basé sur HTCondor est créé. Le méta-ordonnanceur de ressources COBalD/TARDIS intègre de manière dynamique et transparente des backends hétérogènes (clusters HPC, fermes HTC, machines virtuelles cloud) dans ce pool unifié. Il agit comme un système « pilote », soumettant des travaux de substitution pour réserver des ressources, puis déployant les charges de travail réelles des utilisateurs.

2.2 Accès utilisateur & Environnement logiciel

L'accès est fourni via des nœuds de connexion traditionnels et un service JupyterHub, servant de points d'entrée centraux. Une infrastructure d'authentification et d'autorisation (AAI) basée sur des jetons standardise l'accès. La complexité de l'environnement logiciel est gérée grâce aux technologies de conteneurs (Docker, Singularity/Apptainer) et au CERN Virtual Machine File System (CVMFS), qui délivre des piles logicielles préconfigurées et spécifiques à chaque communauté de manière évolutive et en lecture seule.

3. Infrastructure Fédérée de Stockage – Storage4PUNCH

Storage4PUNCH vise à fédérer les systèmes de stockage fournis par les communautés, principalement basés sur les technologies dCache ou XRootD, bien établies en physique des hautes énergies (HEP). La fédération crée un espace de noms commun et une couche d'accès unifiée. Le concept évalue également les technologies existantes pour la mise en cache (pour réduire la latence et le trafic WAN) et la gestion des métadonnées, visant une intégration plus poussée pour faciliter la découverte et la gestion des données à travers le stockage fédéré.

4. Implémentation technique & Composants de base

4.1 Fédération de calcul : HTCondor & COBalD/TARDIS

HTCondor : Fournit la couche de gestion des travaux, la mise en file d'attente et l'ordonnancement au sein du pool fédéré. Son mécanisme ClassAd permet d'apparier des exigences de travail complexes avec les propriétés dynamiques des ressources.
COBalD/TARDIS : Se situe entre HTCondor et les backends hétérogènes. TARDIS traduit les « pilotes » HTCondor en commandes de soumission spécifiques au backend (par exemple, un script de travail SLURM). COBalD implémente la logique de décision pour déterminer quand et où lancer ces pilotes en fonction de la politique, du coût et de l'état des files d'attente. La fonction principale peut être modélisée comme un problème d'optimisation : $\text{Maximiser } U = \sum_{r \in R} (w_r \cdot u_r(\text{alloc}_r)) \text{ sous contrainte } \text{alloc}_r \leq \text{cap}_r, \forall r \in R$, où $U$ est l'utilité totale, $R$ est l'ensemble des types de ressources, $w_r$ est un poids, $u_r$ est une fonction d'utilité pour le type de ressource $r$, $\text{alloc}_r$ est la capacité allouée, et $\text{cap}_r$ est la capacité totale.

4.2 Fédération de stockage : dCache & XRootD

dCache : Un système de gestion hiérarchique de stockage, souvent utilisé comme frontend pour les archives sur bande. Il fournit des interfaces de type POSIX (NFS, WebDAV) et des protocoles spécifiques à la HEP (xrootd, gridftp).
XRootD : Un protocole et une suite pour un accès aux données évolutif et tolérant aux pannes. Son composant « redirecteur » permet de construire des fédérations où une requête client est dirigée vers le serveur de données approprié.
La fédération crée une couche logique qui présente plusieurs instances physiques comme un système unique, cruciale pour un ordonnancement tenant compte de la localité des données.

4.3 Distribution des logiciels et des données : Conteneurs & CVMFS

Conteneurs : Garantissent des environnements logiciels reproductibles sur divers systèmes hôtes. Ils encapsulent des dépendances complexes (par exemple, des versions spécifiques de ROOT, Geant4).
CVMFS : Un système de fichiers distribué global pour la distribution de logiciels. Il utilise HTTP et une mise en cache agressive. Son contenu est publié une fois et devient disponible partout, résolvant le problème du déploiement logiciel à grande échelle. Le processus de publication implique un serveur « stratum 0 » et une réplication vers des miroirs « stratum 1 ».

5. État du prototype & Premières expériences

Le document rapporte que des prototypes pour Compute4PUNCH et Storage4PUNCH ont été déployés. Des applications scientifiques initiales ont été exécutées avec succès sur les prototypes disponibles, démontrant la faisabilité des concepts. Des métriques de performance spécifiques ou des études de cas détaillées ne sont pas fournies dans le résumé, mais l'exécution réussie valide l'approche d'intégration et la pile technologique choisie.

7. Analyse originale : Idée centrale, Enchaînement logique, Forces & Faiblesses, Perspectives d'action

Idée centrale : PUNCH4NFDI ne construit pas un nouveau supercalculateur ; il orchestre une symphonie d'instruments existants et disparates. Sa véritable innovation réside dans la méta-couche — le « chef d'orchestre » composé de COBalD/TARDIS et des protocoles de fédération — qui crée un pool de ressources unifié sans exiger d'homogénéité de la part des fournisseurs sous-jacents. C'est un coup de maître stratégique pour les collaborations politiquement complexes et multi-institutionnelles, rappelant le paradigme de l'apprentissage fédéré en IA (comme dans les travaux de Google sur Federated Averaging) où les données restent distribuées, mais les modèles sont agrégés.

Enchaînement logique : L'architecture suit une séparation claire des préoccupations. 1) Accès & Identité : L'AAI basée sur des jetons authentifie les utilisateurs. 2) Abstraction du calcul : L'utilisateur soumet un travail à HTCondor. COBalD/TARDIS surveille les files d'attente, décide quel backend (par exemple, un cluster HPC universitaire) a de la capacité, et déploie un travail pilote pour « réserver » ces ressources pour le pool HTCondor. Le travail réel de l'utilisateur s'exécute ensuite dans ce pilote. 3) Environnement logiciel : Le travail récupère sa pile logicielle spécifique via CVMFS ou depuis un registre de conteneurs. 4) Accès aux données : Le travail lit/écrit des données via la couche de stockage fédérée (dCache/XRootD), qui redirige les requêtes vers l'emplacement réel des données.

Forces & Faiblesses : La force est un pragmatisme indéniable. En encapsulant les systèmes existants, il atteint une déployabilité rapide et l'adhésion des propriétaires de ressources. L'utilisation d'une pile technologique éprouvée en HEP (validée par le succès du Worldwide LHC Computing Grid du CERN) est un atténuateur de risque majeur. Cependant, les faiblesses résident dans la complexité inhérente à la couche de méta-ordonnancement. COBalD/TARDIS doit prendre des décisions de provisionnement intelligentes à travers des systèmes hétérogènes avec des politiques, des coûts (par exemple, des crédits cloud) et des profils de performance différents. Une politique mal réglée pourrait conduire à une utilisation inefficace des ressources ou à une famine des travaux. De plus, bien que la fédération de stockage fournisse un accès unifié, des fonctionnalités avancées de gestion des données comme l'indexation d'un espace de noms global, la fédération de catalogues de métadonnées et le placement intelligent des données (semblables aux idées du système de fichiers parallèle Lustre ou aux recherches sur le nivellement automatisé des données) semblent être des éléments d'évaluation futurs, représentant une limitation actuelle.

Perspectives d'action : Pour d'autres consortiums (par exemple, en bio-informatique ou en sciences du climat), la leçon à retenir est d'investir massivement dès le premier jour dans la conception du méta-ordonnanceur et de la couche d'abstraction. L'approche PUNCH suggère de commencer par une fédération minimale viable utilisant une technologie stable comme HTCondor, plutôt que de tenter une construction ex nihilo. Les fournisseurs de ressources doivent être engagés avec des exigences claires et minimales de type API (par exemple, « doit supporter SSH ou une commande spécifique de système de traitement par lots »). Il est crucial que le projet développe des outils de surveillance et d'audit robustes pour la couche fédérée elle-même — comprendre l'utilisation inter-sites et diagnostiquer les défaillances dans cette chaîne complexe sera d'une importance opérationnelle primordiale. La feuille de route future devrait explicitement aborder l'intégration des gestionnaires de flux de travail (comme Nextflow ou Apache Airflow) et le développement des services de mise en cache et de métadonnées évalués pour passer d'une simple fédération à une logistique de données intelligente et optimisée pour la performance.

8. Détails techniques & Cadre mathématique

Le problème d'allocation des ressources abordé par COBalD/TARDIS peut être formulé comme une optimisation en ligne. Soit $Q(t)$ la file d'attente des travaux en attente dans HTCondor au temps $t$, chacun avec un temps d'exécution estimé $\hat{r}_i$ et un vecteur de demande de ressources $\vec{c}_i$ (CPU, mémoire, GPU). Soit $B$ l'ensemble des backends, chacun avec une capacité disponible variable dans le temps $\vec{C}_b(t)$ et une fonction de coût $f_b(\vec{c}, \Delta t)$ pour allouer des ressources $\vec{c}$ pour une durée $\Delta t$. L'objectif du méta-ordonnanceur est de minimiser le temps moyen de traitement des travaux $T_{ta}$ tout en respectant les politiques des backends et une contrainte budgétaire. Une règle de décision heuristique simplifiée pour lancer un pilote sur le backend $b$ pourrait être : $\text{Lancer si } \frac{|\{j \in Q(t): \vec{c}_j \preceq \vec{C}_b(t)\}|}{\text{Coût}_b} > \theta$, où $\preceq$ dénote « tient dans », $\text{Coût}_b$ est un coût normalisé, et $\theta$ est un seuil. Cela capture le compromis entre la demande de la file d'attente et le coût de provisionnement.

9. Résultats expérimentaux & Métriques du prototype

Bien que le résumé PDF fourni n'inclue pas de résultats quantitatifs spécifiques, un prototype réussi implique des résultats qualitatifs clés et potentiellement quantitatifs :

• Succès fonctionnel : Capacité démontrée à soumettre un travail unique via HTCondor/JupyterHub et à l'exécuter de manière transparente sur une ressource HPC ou HTC distante, avec des logiciels provenant de CVMFS et des données provenant du stockage fédéré.
• Métriques clés à suivre (futur) :
  • Taux de réussite des travaux : Pourcentage de travaux qui se terminent avec succès à travers la fédération.
  • Temps d'attente moyen : Temps entre la soumission et le début, comparé aux files d'attente natives des backends.
  • Utilisation des ressources : Nombre total d'heures-CPU délivrées à travers le pool fédéré.
  • Efficacité du transfert de données : Débit et latence pour les travaux accédant au stockage distant via la couche de fédération.
• Description du diagramme : Un diagramme d'architecture conceptuel montrerait : Les utilisateurs interagissant avec JupyterHub/Nœuds de connexion. Ceux-ci se connectent à un Gestionnaire Central HTCondor. Le composant COBalD/TARDIS interagit à la fois avec HTCondor et plusieurs Backends de Ressources (Cluster HPC A, Ferme HTC B, Cloud C). Chaque backend a son système de traitement par lots local (SLURM, PBS, etc.). Des flèches indiquent la soumission des travaux et le déploiement des pilotes. Une section séparée montre le Stockage Fédéré (instances dCache, XRootD) connecté aux backends et accessible par les travaux. Les miroirs CVMFS Stratum 1 sont représentés comme une couche accessible par tous les backends.

10. Cadre d'analyse : Exemple de flux de travail conceptuel

Scénario : Un physicien en astroparticules doit traiter 1 000 images de télescope en utilisant un pipeline d'analyse complexe et personnalisé (basé sur Python/ROOT).

1. Point d'entrée utilisateur : Le chercheur se connecte au JupyterHub PUNCH.
2. Configuration de l'environnement : Dans un notebook Jupyter, il sélectionne un noyau prédéfini supporté par un conteneur Singularity qui contient sa pile logicielle spécifique (publiée sur CVMFS).
3. Définition du travail : Il écrit un script qui définit la tâche d'analyse et utilise une bibliothèque d'aide PUNCH pour créer une description de soumission HTCondor, spécifiant les CPU, la mémoire nécessaires et les références aux données d'entrée (par exemple, `root://fed-storage.punch.org/path/to/images_*.fits`).
4. Soumission & Ordonnancement : Le travail est soumis au pool HTCondor. COBalD/TARDIS, voyant 1 000 travaux courts, décide de lancer plusieurs travaux pilotes sur une ferme à haut débit (Backend B) avec un cache de stockage local rapide pour les données d'entrée.
5. Exécution : Les pilotes réservent des emplacements sur le Backend B. Chaque pilote extrait le conteneur, récupère ses fichiers d'entrée assignés via la fédération XRootD (qui peut rediriger vers un cache local), exécute l'analyse et écrit les résultats dans le stockage fédéré.
6. Achèvement : HTCondor agrège l'état d'achèvement des travaux. Le notebook du chercheur peut maintenant interroger et visualiser les résultats depuis l'emplacement de stockage de sortie.

Cet exemple met en évidence l'abstraction complète : l'utilisateur n'a jamais eu besoin de connaître les commandes SLURM sur le Backend B, comment installer ROOT là-bas, ou l'emplacement physique des fichiers de données.

11. Applications futures & Feuille de route de développement

L'infrastructure PUNCH4NFDI jette les bases d'applications transformatrices :

• Flux de travail d'astrophysique multi-messagers : Analyses de corrélation en temps réel entre les données d'observatoires d'ondes gravitationnelles (LIGO/Virgo), de neutrinos (IceCube) et électromagnétiques, nécessitant un calcul urgent à travers des ressources géographiquement distribuées.
• Entraînement de modèles IA/ML à grande échelle : Expériences d'apprentissage fédéré où le processus d'entraînement lui-même est distribué à travers la fédération de calcul, avec des modèles agrégés centralement — un parallèle de calcul avec la fédération de données.
• Jumeaux numériques d'expériences complexes : Exécution d'ensembles massifs de simulations pour créer des contreparties numériques de détecteurs de particules ou de réseaux de télescopes, tirant parti du HPC pour la simulation et du HTC pour les scans de paramètres.

Feuille de route de développement :

1. Court terme (1-2 ans) : Consolider le déploiement en qualité de production des services de base de Compute4PUNCH et Storage4PUNCH. Intégrer une surveillance avancée (Prometheus/Grafana) et des outils de facturation/comptabilité.
2. Moyen terme (3-4 ans) : Implémenter et intégrer les services de mise en cache et de catalogue de métadonnées global évalués. Développer une intégration plus étroite avec les systèmes de gestion de flux de travail. Explorer le « débordement » vers des clouds commerciaux pendant les pics de demande.
3. Long terme (5+ ans) : Évoluer vers un « data lakehouse intelligent » pour la science PUNCH, incorporant la découverte de données, le suivi de la provenance et la gestion automatisée du cycle de vie des données alimentée par les métadonnées fédérées. Servir de modèle pour d'autres consortiums NFDI et collaborations internationales.

12. Références

1. Consortium PUNCH4NFDI. (2024). Livre blanc PUNCH4NFDI. [Documentation officielle du consortium].
2. Thain, D., Tannenbaum, T., & Livny, M. (2005). Distributed computing in practice: the Condor experience. Concurrency and Computation: Practice and Experience, 17(2-4), 323-356. https://doi.org/10.1002/cpe.938
3. Krebs, K., et al. (2022). COBalD/TARDIS – A dynamic resource provisioning framework for heterogeneous computing environments. Journal of Physics: Conference Series, 2438(1), 012045. (Référence pour le méta-ordonnanceur).
4. Blomer, J., et al. (2011). The CernVM File System. Journal of Physics: Conference Series, 331(5), 052004. https://doi.org/10.1088/1742-6596/331/5/052004
5. Collaboration dCache. (2023). dCache.org [Logiciel et Documentation]. https://www.dcache.org
6. Collaboration XRootD. (2023). Documentation XRootD. http://xrootd.org/docs.html
7. McMahan, B., Moore, E., Ramage, D., Hampson, S., & y Arcas, B. A. (2017). Communication-Efficient Learning of Deep Networks from Decentralized Data. Proceedings of the 20th International Conference on Artificial Intelligence and Statistics (AISTATS). (Cité pour l'analogie avec l'apprentissage fédéré).
8. Organisation européenne pour la recherche nucléaire (CERN). (2023). Worldwide LHC Computing Grid (WLCG). https://wlcg.web.cern.ch (Cité comme précédent pour une fédération à grande échelle).