Infrastructure Fédérée de Calcul Hétérogène et de Stockage 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 (Facile à trouver, Accessible, Interopérable, Réutilisable). Un défi central abordé est la fédération des ressources de calcul (HPC, HTC, Cloud) et de stockage hautement hétérogènes, apportées « en nature » par les institutions membres à travers l'Allemagne, permettant un accès unifié et transparent aux chercheurs.

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

Le concept Compute4PUNCH est conçu pour fournir un accès transparent à un ensemble diversifié de ressources de calcul sans imposer de changements significatifs aux systèmes opérationnels existants sur les sites fournisseurs.

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

Storage4PUNCH se concentre sur la fédération des systèmes de stockage communautaires, principalement basés sur les technologies dCache et XRootD, qui sont des standards en physique des hautes énergies (HEP). La fédération vise à fournir un espace de noms et un protocole d'accès unifiés. Le concept évalue une intégration plus poussée via :

• Des protocoles de fédération de stockage (par ex., basés sur la fédération de redirecteurs XRootD ou le gestionnaire de pools dCache).
• Des couches de cache pour réduire la latence et le trafic sur les réseaux étendus (WAN).
• La gestion des métadonnées pour améliorer la découvrabilité des données à travers la fédération.

4. Détails Techniques & Cadre Mathématique

La logique d'ordonnancement centrale peut être modélisée comme un problème d'optimisation. Soit $R = \{r_1, r_2, ..., r_n\}$ l'ensemble des ressources hétérogènes, chacune avec des attributs comme l'architecture, les cœurs disponibles $c_i$, la mémoire $m_i$, et un facteur de coût/priorité $p_i$. Un travail $J$ a des exigences $J_{req} = (c_{req}, m_{req}, arch_{req}, t_{req})$. L'objectif du méta-ordonnanceur est de maximiser l'utilité ou le débit global.

Une fonction de score simplifiée pour placer le travail $J$ sur la ressource $r_i$ pourrait être : $$ S(J, r_i) = \begin{cases} 0 & \text{si } r_i \text{ ne correspond pas à } J_{req} \\ \alpha \cdot \frac{c_i}{c_{req}} + \beta \cdot \frac{m_i}{m_{req}} - \gamma \cdot p_i & \text{sinon} \end{cases} $$ où $\alpha, \beta, \gamma$ sont des coefficients de pondération. Le système COBalD/TARDIS implémente des heuristiques et des boucles de rétroaction en temps réel pour approximer dynamiquement une telle optimisation, en s'adaptant à la disponibilité des ressources et à l'état des files d'attente de travaux.

5. Résultats du Prototype & Performances

Description du graphique (conceptuel) : Un graphique linéaire montrant « La capacité de calcul agrégée accessible au fil du temps ». L'axe des x représente le temps (mois). Deux lignes sont affichées : 1) « Pools de ressources individuels (déconnectés) » – des lignes plates et décalées représentant la capacité statique des sites individuels. 2) « Pool fédéré via Compute4PUNCH » – une ligne plus haute et plus dynamique qui augmente à mesure que plus de sites sont intégrés et montre de plus petites fluctuations, démontrant l'équilibrage de charge à travers la fédération. Le graphique illustre le résultat clé : le système fédéré fournit aux utilisateurs un pool de ressources virtuel plus grand, plus résilient et plus efficacement utilisé que la somme de ses parties isolées.

Les premiers prototypes ont démontré avec succès la soumission de travaux depuis un point d'entrée unique (JupyterHub) vers plusieurs pools HTCondor et clusters HPC en backend (par ex., au KIT, DESY). Les travaux utilisant des environnements conteneurisés via CVMFS ont été exécutés de manière transparente sur différentes architectures. Les premières métriques indiquent une réduction du temps d'attente des travaux pour les utilisateurs en exploitant les cycles sous-utilisés à travers la fédération, bien que la latence de transfert de données inter-sites reste un facteur critique pour les charges de travail intensives en données.

6. Cadre d'Analyse : Une Étude de Cas Conceptuelle

Scénario : Une analyse d'astrophysique multi-messagers corrélant les données d'un télescope à neutrinos (IceCube) et d'un observatoire de rayons gamma (CTA).

Flux de travail sans fédération : Le chercheur doit : 1. Demander des allocations de calcul séparées sur un cluster HPC pour la simulation et sur une ferme HTC pour le traitement des événements. 2. Transférer manuellement de grands ensembles de données (à l'échelle du téraoctet) entre les systèmes de stockage de différents instituts. 3. Gérer des environnements logiciels et des méthodes d'authentification disparates.

Flux de travail avec Compute4PUNCH/Storage4PUNCH : 1. Le chercheur se connecte au JupyterHub PUNCH avec un seul jeton. 2. Le flux de travail d'analyse est défini (par ex., en utilisant Snakemake ou similaire). Les tâches de simulation (adaptées au HPC) sont automatiquement acheminées via TARDIS vers les ressources HPC appropriées. Les tâches de traitement d'événements à haut débit sont envoyées vers les fermes HTC. 3. Le flux de travail référence les données via l'espace de noms de stockage fédéré (par ex., `punch://data/icecube/run_xyz.root`). La fédération sous-jacente XRootD/dCache gère la localisation et le transfert. 4. Tous les travaux récupèrent un environnement logiciel cohérent depuis CVMFS. Cette étude de cas démontre le potentiel transformateur : le chercheur se concentre sur la science, et non sur la logistique de l'infrastructure.

7. Applications Futures & Feuille de Route de Développement

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

• Entraînement Fédéré d'Apprentissage Automatique : Exploiter les GPU hétérogènes sur plusieurs sites pour l'entraînement de modèles à grande échelle, en utilisant potentiellement des frameworks comme PyTorch ou TensorFlow avec des algorithmes d'apprentissage fédéré adaptés au backend HTCondor/TARDIS.
• Placement Dynamique des Charges de Travail Guidé par des Politiques : Intégrer un ordonnancement sensible au carbone, où les travaux sont acheminés vers les sites avec une forte disponibilité d'énergie renouvelable, similaire aux concepts explorés par l'initiative Green Algorithms.
• Fédération Inter-Consortiums : Servir de modèle pour la connexion avec d'autres consortiums NFDI ou des initiatives européennes comme le European Open Science Cloud (EOSC), créant une infrastructure de recherche paneuropéenne.
• Cache et Pré-chargement Intelligents des Données : Utiliser la provenance des flux de travail et l'analyse prédictive pour mettre en cache de manière proactive les ensembles de données sur les sites de calcul, atténuant la latence WAN, un défi également central pour des projets comme IRIS-HEP.

8. Perspective de l'Analyste : Idée Maîtresse, Enchaînement Logique, Forces & Faiblesses, Recommandations Concrètes

Idée Maîtresse : PUNCH4NFDI ne construit pas un nouveau supercalculateur ; il construit une couche de virtualisation et d'orchestration qui transforme le paysage fragmenté et balkanisé du calcul de recherche allemand en une utilisateur-centrique et cohésive. C'est une stratégie classique de « fédération plutôt que remplacement », privilégiant l'adoption et l'incrémentalisme par rapport au changement révolutionnaire – un choix pragmatiquement brillant compte tenu des réalités politiques et opérationnelles des institutions financées par des fonds publics.

Enchaînement Logique : La logique est solide : 1) Reconnaître l'hétérogénéité et la propriété (les ressources restent aux instituts). 2) Imposer des exigences nouvelles minimales (utiliser des jetons, des conteneurs). 3) Insérer une couche middleware intelligente et adaptative (COBalD/TARDIS) pour abstraire la complexité. 4) Fournir des interfaces utilisateur simples et modernes (JupyterHub). 5) Fédérer les données de manière similaire pour boucler la boucle. C'est un manuel d'intégration ascendant que d'autres consortiums devraient étudier.

Forces & Faiblesses : Forces : L'utilisation de composants éprouvés (HTCondor, dCache, CVMFS) de la communauté HEP réduit considérablement le risque technique. L'accent mis sur l'AAI et les conteneurs aborde les deux plus grands obstacles à l'adoption : l'accès et le logiciel. Le choix de COBalD/TARDIS est inspiré – c'est un ordonnanceur léger, basé sur Python, conçu pour ce scénario exact d'hybride cloud opportuniste. Faiblesses Critiques : Le problème majeur est la mobilité des données. Fédérer le calcul est plus facile que fédérer le stockage. Le document mentionne l'évaluation du cache et des métadonnées, mais les problèmes difficiles de la performance d'un espace de noms global cohérent, des coûts de transfert de données WAN et de l'application des politiques de données inter-sites sont simplement évoqués. Sans une solution robuste à ce niveau, le pool de calcul fédéré sera entravé pour les charges de travail intensives en données. De plus, le succès dépend entièrement des contributions « en nature » soutenues des membres – un modèle économique potentiellement fragile.

Recommandations Concrètes : 1. Pour PUNCH4NFDI : Renforcer la couche données. Partenarier activement avec des projets comme Rucio pour la gestion des données et l'Open Science Grid pour l'expérience opérationnelle. Développer des accords de niveau de service (SLA) clairs avec les fournisseurs de ressources, notamment concernant les coûts de sortie des données. 2. Pour les Concurrents/Imitateurs : Ne vous contentez pas de copier l'architecture. La véritable leçon réside dans la gouvernance et le modèle d'intégration léger. Commencez par un prototype fonctionnel sur quelques sites volontaires et développez-vous organiquement. 3. Pour les Fournisseurs & Agences de Financement : Ce modèle démontre que les futurs investissements en calcul de recherche devraient financer le middleware d'intégration et la pérennité logicielle (comme COBalD) autant, sinon plus, que le matériel brut. Financez la « colle ».

En conclusion, l'approche de PUNCH4NFDI est une leçon de maître en ingénierie pragmatique de cyberinfrastructure. Elle reconnaît que le plus grand goulot d'étranglement du calcul scientifique n'est souvent pas les FLOPS, mais l'utilisabilité et l'accès. S'ils parviennent à résoudre le problème du stockage de données fédéré, ils auront créé un modèle ayant un véritable potentiel pour remodeler non seulement le calcul de recherche allemand, mais aussi européen.

9. Références

1. Consortium PUNCH4NFDI. (2024). Livre Blanc PUNCH4NFDI. NFDI.
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.
3. Giffels, M., et al. (2023). COBalD/TARDIS - A dynamic resource overlay for opportunistic computing. Journal of Physics: Conference Series.
4. Blomer, J., et al. (2011). The CernVM File System. Journal of Physics: Conference Series, 331(5), 052004.
5. Zhu, J. Y., Park, T., Isola, P., & Efros, A. A. (2017). Unpaired Image-to-Image Translation using Cycle-Consistent Adversarial Networks. Proceedings of the IEEE International Conference on Computer Vision (ICCV). (Cité comme exemple d'une méthodologie de calcul transformative qui pourrait tirer parti d'une telle infrastructure fédérée).
6. Collaboration dCache. (2023). dCache: A distributed storage system. https://www.dcache.org.
7. Collaboration XRootD. (2023). XRootD: High performance, scalable fault tolerant access to data. https://xrootd.slac.stanford.edu.
8. European Open Science Cloud (EOSC). (2024). https://eosc-portal.eu.