Compute4PUNCH & Storage4PUNCH : Infrastructure fédérée pour la physique des particules, l'astrophysique et la physique nucléaire

1. Introduction

Le consortium PUNCH4NFDI (Particles, Universe, NuClei and Hadrons for the National Research Data Infrastructure), financé par la Fondation allemande pour la recherche (DFG), représente environ 9 000 scientifiques des communautés de la physique des particules, de l'astrophysique, de l'astroparticule, des hadrons et de la physique nucléaire en Allemagne. Intégré dans l'initiative nationale NFDI, son objectif principal 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 ressources de calcul et de stockage diverses et hétérogènes fournies par ses institutions membres, répondant au défi commun d'analyser des volumes de données en croissance exponentielle avec des algorithmes complexes. Ce document se concentre sur les concepts techniques de Compute4PUNCH et Storage4PUNCH, qui constituent l'épine dorsale de cette infrastructure fédérée.

2. Infrastructure de calcul hétérogène fédérée – Compute4PUNCH

Compute4PUNCH relève le défi d'utiliser efficacement un large éventail de ressources de calcul à haut débit (HTC), de calcul haute performance (HPC) et de cloud, fournies en nature et réparties à travers l'Allemagne. Ces ressources varient en architecture, systèmes d'exploitation, piles logicielles et mécanismes d'authentification.

2.1. Architecture centrale & Système de superposition

La pierre angulaire de Compute4PUNCH est la création d'un système de traitement par lots en superposition fédéré basé sur HTCondor. L'innovation clé est l'utilisation du métascheduleur de ressources COBalD/TARDIS. TARDIS (TARDIS Acts as a Resource Dispatcher for In-place Scheduling) intègre de manière dynamique et transparente des ressources externes hétérogènes dans le pool HTCondor. Il agit comme un système « pilote », soumettant des travaux de substitution à des grappes externes (comme des systèmes HPC basés sur Slurm) qui extraient et exécutent ensuite les travaux réels des utilisateurs depuis la file d'attente centrale HTCondor. Cette approche minimise l'intrusion sur les configurations opérationnelles existantes des fournisseurs de ressources, une exigence critique pour l'adoption.

La logique d'appariement et d'ordonnancement des ressources peut être représentée de manière abstraite par une fonction d'optimisation. Soit $R = \{r_1, r_2, ..., r_n\}$ l'ensemble des ressources hétérogènes disponibles, chacune avec des attributs comme l'architecture $arch(r_i)$, les cœurs disponibles $c(r_i)$, la mémoire $m(r_i)$ et le temps d'attente dans la file $w(r_i)$. Soit $J = \{j_1, j_2, ..., j_m\}$ l'ensemble des travaux utilisateur avec des exigences $req(j_k)$. L'objectif du métascheduleur est de trouver un mappage $M: J \rightarrow R$ qui maximise une fonction objectif $F$, souvent une somme pondérée d'efficacité et d'équité :

$F(M) = \alpha \cdot \sum_{j_k} U(j_k, M(j_k)) - \beta \cdot \sum_{r_i} L(r_i, M^{-1}(r_i))$

où $U$ est une fonction d'utilité mesurant dans quelle mesure une ressource satisfait les exigences d'un travail (en tenant compte de la compatibilité de l'environnement logiciel via CVMFS), et $L$ est une fonction de charge pénalisant la sursouscription de toute ressource unique. COBalD/TARDIS résout de manière heuristique ce problème d'ordonnancement dynamique en ligne.

2.2. Accès & Environnement logiciel

L'accès utilisateur est standardisé via une infrastructure d'authentification et d'autorisation (AAI) basée sur des jetons. Les points d'entrée principaux sont des nœuds de connexion traditionnels et un service JupyterHub, fournissant une interface web familière pour l'analyse interactive et le prototypage.

Pour gérer les diverses dépendances logicielles, l'infrastructure exploite les technologies de conteneurs (par ex., Docker, Singularity/Apptainer) et le CERN Virtual Machine File System (CVMFS). CVMFS fournit un espace de noms évolutif, en lecture seule et distribué mondialement pour les installations logicielles. Les piles logicielles spécifiques aux communautés sont publiées dans des dépôts CVMFS, garantissant que tout nœud de calcul, quel que soit son emplacement physique, peut accéder instantanément et de manière cohérente à l'environnement logiciel requis, éliminant ainsi la surcharge d'installation locale.

3. Infrastructure de stockage fédérée – Storage4PUNCH

Storage4PUNCH se concentre sur la fédération des systèmes de stockage fournis par la communauté, qui sont principalement basés sur les technologies dCache ou XRootD, toutes deux bien établies en physique des hautes énergies (HEP).

3.1. Stratégies de fédération et de mise en cache

La fédération crée un espace de noms unifié, permettant aux utilisateurs d'accéder aux données à travers plusieurs éléments de stockage institutionnels comme s'il s'agissait d'un système unique. Des technologies comme le protocole de fédération d'XRootD et le regroupement frontal (frontend pooling) de dCache sont employées pour y parvenir. Le système effectue une localisation et un routage intelligents des données.

Un composant critique en cours d'évaluation est la mise en cache. Une couche de cache globale ou régionale peut réduire considérablement la latence et la charge du réseau étendu pour les jeux de données fréquemment consultés. Le taux de succès $H$ d'un cache de taille $S$ pour un modèle d'accès aux données peut être modélisé. Si la probabilité d'accéder à l'élément de données $d_i$ suit une distribution de type Zipf $P(i) \sim 1 / i^{\alpha}$, le taux de succès attendu pour un cache LRU est approximativement :

$H(S) \approx \sum_{i=1}^{S} P(i)$

où $\alpha$ est le paramètre d'asymétrie. Pour les workflows scientifiques avec une réutilisation élevée des données (courante dans les chaînes d'analyse), même des caches de taille modeste peuvent produire un $H$ élevé, justifiant leur déploiement. Le projet évalue également des solutions de gestion des métadonnées pour une intégration plus profonde, visant à fournir non seulement un accès aux fichiers mais aussi des capacités de découverte de données à travers la fédération.

4. Détails techniques & Cadre mathématique

La performance de la fédération dépend d'une découverte et d'un ordonnancement efficaces des ressources. L'état du système peut être modélisé comme un graphe $G=(V,E)$, où les sommets $V$ représentent les ressources (nœuds de calcul, points de terminaison de stockage) et les arêtes $E$ représentent les liens réseau avec une bande passante $bw(e)$ et une latence $lat(e)$. Un workflow $W$ est un graphe orienté acyclique (DAG) de tâches $T$ avec des dépendances de données $D$.

Le problème d'ordonnancement devient : Placer chaque tâche $t \in T$ sur une ressource de calcul $r_c \in V_c$ et acheminer ses données d'entrée requises depuis les ressources de stockage $r_s \in V_s$ de telle sorte que le makespan total (temps d'achèvement du workflow) soit minimisé, sous contraintes :

$\text{minimiser } \max_{t \in T} (ft(t))$
sous contraintes :
$\forall r \in V_c, \sum_{t plac\'ee\ sur\ r} c(t) \leq C(r)$ (capacité CPU)
$\forall d \in D, \text{transfer\_time}(d) = \frac{size(d)}{\min\_bw(path)} + \sum_{e \in path} lat(e)$

Où $ft(t)$ est le temps de fin de la tâche $t$, $c(t)$ sa demande en CPU, et $C(r)$ la capacité de la ressource $r$. Le système fédéré utilise des algorithmes heuristiques au sein d'HTCondor et de COBalD/TARDIS pour approximer des solutions à ce problème NP-difficile en temps réel.

5. Résultats expérimentaux & Performance du prototype

Le document rend compte des premières expériences avec des prototypes opérationnels. Bien que des benchmarks quantitatifs spécifiques ne soient pas détaillés dans l'extrait fourni, le texte implique l'exécution réussie d'applications scientifiques sur l'infrastructure fédérée.

Description du graphique (métriques de performance inférées) : Un graphique de performance hypothétique montrerait probablement deux métriques clés au fil du temps : 1) L'utilisation agrégée des ressources à travers le pool fédéré, démontrant comment le système de superposition comble efficacement les écarts de capacité entre les différents centres contributeurs. 2) Le temps de traitement des travaux comparant un scénario fédéré à l'utilisation isolée des ressources. Le système fédéré montrerait une moyenne et une variance plus faibles du temps de traitement, en particulier pour les travaux ayant des exigences de ressources flexibles, car ils peuvent être acheminés vers les ressources avec la file d'attente la plus courte. L'intégration des ressources HPC via TARDIS montrerait une courbe distincte, ajoutant initialement de la latence en raison du mécanisme de travail pilote mais fournissant un accès à des nœuds à grand nombre de cœurs autrement indisponibles pour les charges de travail appropriées.

L'utilisation de CVMFS est rapportée comme fournissant avec succès des environnements logiciels uniformes, un facteur de succès critique pour l'adoption par les utilisateurs. L'AAI basée sur des jetons a été implémentée, fournissant la base nécessaire pour un accès sécurisé et multi-institutionnel.

6. Cadre d'analyse : Une étude de cas conceptuelle

Cas : Analyse d'astrophysique multi-messagers. Un astrophysicien des particules doit analyser les données d'un sursaut gamma (GRB) détecté par Fermi-LAT et IceCube, en le corrélant avec un suivi optique d'ASAS-SN. Le workflow implique : A) Le traitement de téraoctets de données de photons brutes (Fermi) sur une ferme HTC optimisée pour les E/S élevées. B) L'exécution de simulations Monte Carlo pour la reconstruction d'événements de neutrinos (IceCube) sur un cluster HPC avec de nombreux cœurs. C) L'exécution d'une analyse d'image sur les données optiques en utilisant des nœuds GPU.

Exécution fédérée via Compute4PUNCH/Storage4PUNCH :
1. L'utilisateur soumet une description de workflow unique de haut niveau (par ex., en utilisant le Common Workflow Language - CWL) via JupyterHub.
2. Le jeton AAI authentifie l'utilisateur sur tous les systèmes.
3. La superposition HTCondor, guidée par COBalD/TARDIS, analyse le DAG du workflow :
- La tâche A est appariée et envoyée à des workers HTC proches du stockage basé sur dCache au DESY.
- L'exigence de la tâche B pour 10 000 heures-CPU déclenche TARDIS pour provisionner des emplacements sur un cluster HPC basé sur Slurm au KIT.
- La tâche C est envoyée à une partition GPU à l'Université de Bonn.
4. Toutes les tâches extraient la même pile logicielle d'analyse (Python, bibliothèques scientifiques spécifiques) depuis le dépôt PUNCH CVMFS.
5. Les données intermédiaires sont échangées via l'espace de noms fédéré Storage4PUNCH (par ex., en utilisant XRootD), les fichiers d'étalonnage fréquemment consultés étant servis depuis un cache régional.
6. Les résultats finaux sont agrégés et renvoyés à l'utilisateur.

Ce cas démontre la proposition de valeur : le physicien interagit avec une infrastructure logique unique plutôt que de gérer des connexions séparées, des installations logicielles et des transferts de données à travers trois systèmes distincts.

7. Idée centrale & Perspective de l'analyste

Idée centrale : PUNCH4NFDI ne construit pas un autre supercalculateur monolithique ; il conçoit une couche de fédération — un « méta-système d'exploitation » pour le calcul de recherche hétérogène à l'échelle nationale. Sa véritable innovation est l'orchestration pragmatique de ressources existantes, cloisonnées politiquement, en une utilité cohérente, privilégiant l'intrusion minimale par rapport à la pureté technologique. Cela ressemble moins au Borg de Google et plus à un système sophistiqué de contrôle du trafic aérien à l'échelle de l'UE pour les travaux de calcul.

Flux logique : La logique est élégamment récursive. Commencez par la contrainte non négociable : ne pas perturber les opérations communautaires existantes. Cela impose une architecture de superposition basée sur l'extraction (pull-based) (HTCondor + TARDIS) au lieu d'un ordonnanceur centralisé basé sur la poussée (push-based). Cette superposition, à son tour, nécessite un mécanisme universel de distribution logicielle (CVMFS/Conteneurs) et une couche d'identité unifiée (AAI à jeton). La fédération de stockage suit une voie parallèle, exploitant des outils HEP éprouvés (dCache/XRootD). L'ensemble du flux est une leçon de maîtrise en conception pilotée par les contraintes, où chaque choix technique est une conséquence directe de la réalité socio-politique de la collaboration multi-institutionnelle.

Points forts & Faiblesses :
Points forts : L'architecture est brillamment fédérable. Elle fait évoluer la gouvernance horizontalement par conception, abaissant les barrières pour les nouveaux fournisseurs de ressources. L'utilisation d'HTCondor et de CVMFS puise dans des décennies de confiance communautaire et d'expertise opérationnelle des collaborations du LHC, réduisant le risque technique. L'accent mis sur les ressources « en nature » est financièrement durable, transformant un problème de fragmentation en un avantage de diversité.
Faiblesses : L'éléphant dans la pièce est la surcharge de performance. La double ordonnancement (métascheduleur + système de lots local) et le modèle de travail pilote ajoutent inévitablement de la latence, le rendant inadapté aux travaux MPI à grain fin et fortement couplés — une limitation significative pour les charges de travail HPC pures. La dépendance à CVMFS, bien que robuste, crée un point de défaillance unique pour la distribution logicielle et peut avoir des difficultés avec les codes hautement propriétaires ou sous licence. De plus, comme noté dans les principes de données FAIR, une véritable interopérabilité nécessite des métadonnées riches ; la description actuelle de Storage4PUNCH semble fortement axée sur l'accès au niveau des octets, et non sur la découverte sémantique.

Perspectives actionnables :
1. Pour l'équipe PUNCH : Redoubler d'efforts sur la caractérisation des performances. Publier des benchmarks transparents comparant le débit et la latence des travaux fédérés par rapport aux natifs pour les workflows canoniques. Ces données sont cruciales pour convaincre les gestionnaires et utilisateurs sceptiques des centres HPC. Développer de manière proactive un modèle de support « Tier-1 » pour la couche de fédération elle-même ; sa complexité devient une dépendance critique.
2. Pour les autres consortiums (par ex., en bio-informatique ou sciences du climat) : Ne vous contentez pas de copier la pile technologique. Copiez le modèle de gouvernance qui l'a permis. La leçon clé est l'accord de « contribution en nature » qui aligne les incitations institutionnelles. Commencez par fédérer l'authentification et la distribution logicielle, comme PUNCH l'a fait ; ce sont des fondations.
3. Pour les agences de financement (DFG, UE) : Ce modèle devrait être le plan directeur pour les futurs appels à infrastructures de recherche nationales. Financez la « colle » (coordination, devops de base pour la couche de fédération) et laissez les institutions financer les « briques » (le calcul/stockage réel). Cela tire parti des investissements en capital existants plus efficacement que la construction de nouvelles installations centralisées, un principe repris dans la vision stratégique du European Open Science Cloud (EOSC).

En conclusion, Compute4PUNCH et Storage4PUNCH représentent un modèle mature, pragmatique et hautement reproductible pour l'infrastructure scientifique à grande échelle du 21e siècle. Il échange une partie de la performance théorique contre des gains immenses en accessibilité, résilience et faisabilité politique. Son succès ne se mesurera pas en FLOPS, mais au nombre d'étudiants en doctorat qui peuvent terminer leur analyse sans devenir des administrateurs système experts pour cinq clusters différents.

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

L'infrastructure PUNCH4NFDI jette les bases de plusieurs avancées futures :

Intégration avec les workflows d'apprentissage automatique : La fédération peut être étendue pour prendre en charge des accélérateurs IA/ML spécialisés (par ex., pods NVIDIA DGX, TPU de Google) en tant que type de ressource. Des frameworks comme Kubeflow pourraient être intégrés aux côtés d'HTCondor, avec TARDIS gérant les placements de travaux hybrides entre les ressources HTC traditionnelles et celles axées sur le ML.
Placement proactif des données & Ordonnancement conscient du workflow : Allant au-delà de la mise en cache, le système pourrait mettre en œuvre une préparation prédictive des données. En analysant les DAG de workflows soumis par les utilisateurs, il pourrait pré-charger les jeux de données requis depuis les points de terminaison Storage4PUNCH distants vers des caches locaux proches des ressources de calcul planifiées avant le début de l'exécution du travail, masquant ainsi efficacement la latence de transfert de données. Cela nécessite une intégration plus étroite entre le métascheduleur de calcul et l'espace de noms et les données de surveillance de la fédération de stockage.
Extension au calcul en périphérie (edge computing) : Pour des domaines comme la radioastronomie ou la physique des neutrinos, où les capteurs génèrent de vastes flux de données, le modèle de fédération pourrait incorporer des sites de calcul en périphérie. Des agents TARDIS légers pourraient fonctionner dans les observatoires, extrayant les tâches de prétraitement de la file d'attente centrale pour filtrer et réduire les données sur site avant de transmettre uniquement les événements pertinents au stockage central.
Informatique verte & Ordonnancement sensible au carbone : Le métascheduleur pourrait être amélioré avec des données d'intensité carbone des réseaux électriques à travers l'Allemagne. Il pourrait alors acheminer préférentiellement les travaux vers les centres de données situés dans des régions à forte pénétration d'énergies renouvelables (par ex., l'énergie éolienne dans le nord) aux heures de production de pointe, minimisant ainsi l'empreinte carbone des calculs à grande échelle — une priorité émergente pour les infrastructures de recherche, comme le souligne l'initiative Carbon Call de la Linux Foundation.
Inter-fédération avec des partenaires internationaux : La prochaine étape logique est de connecter la fédération allemande PUNCH avec des infrastructures similaires à l'étranger, telles que le Worldwide LHC Computing Grid (WLCG), l'Open Science Grid (OSG) ou le European Open Science Cloud (EOSC). Cela créerait une infrastructure de recherche mondiale et multidisciplinaire, bien que cela soulèverait des défis significatifs en matière d'alignement des politiques, de sécurité et de comptabilité.

9. Références

Consortium PUNCH4NFDI. « PUNCH4NFDI - Particles, Universe, NuClei and Hadrons for the NFDI. » Livre blanc, 2021.
Thain, D., Tannenbaum, T., & Livny, M. « Distributed computing in practice: the Condor experience. » Concurrency - Practice and Experience, 17(2-4), 323-356, 2005. https://doi.org/10.1002/cpe.938
Blomer, J., et al. « CernVM-FS: delivering scientific software to globally distributed computing resources. » International Journal of High Performance Computing Applications, 28(2), 158-174, 2014. https://doi.org/10.1177/1094342013509700
Giffels, M., et al. « COBalD/TARDIS – Dynamic, Pilot-based Resource Provisioning for a Federated HTCondor Pool. » In Proceedings of CHEP 2018, 2018.
Wilkinson, M. D., et al. « The FAIR Guiding Principles for scientific data management and stewardship. » Scientific Data, 3:160018, 2016. https://doi.org/10.1038/sdata.2016.18
Commission européenne. « European Open Science Cloud (EOSC) Strategic Implementation Roadmap. » 2018.
Linux Foundation. « Carbon Call: A Global Initiative for Reliable Carbon Accounting. » 2022. https://www.linuxfoundation.org/research/carbon-call
Zhu, J.-Y., Park, T., Isola, P., & Efros, A. A. « Unpaired Image-to-Image Translation using Cycle-Consistent Adversarial Networks. » In Proceedings of the IEEE International Conference on Computer Vision (ICCV), 2017. (Cité comme exemple d'une charge de travail computationnelle complexe qui pourrait bénéficier d'un accès fédéré et hétérogène aux ressources).