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

1. Introduction

PUNCH4NFDI (Particles, Universe, NuClei and Hadrons for the National Research Data Infrastructure) 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 contribution détaille spécifiquement les concepts architecturaux — Compute4PUNCH et Storage4PUNCH — conçus pour unifier l'accès aux 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.

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

L'initiative Compute4PUNCH relève le défi de fournir un accès transparent à un ensemble diversifié de ressources de calcul existantes sans imposer de changements majeurs aux modèles opérationnels des fournisseurs de ressources.

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

Storage4PUNCH vise à fédérer les systèmes de stockage communautaires, principalement basés sur les technologies dCache et XRootD, bien établies en physique des hautes énergies (HEP).

4. Détails Techniques & Cadre Mathématique

La logique d'ordonnancement centrale de COBalD/TARDIS peut être modélisée comme un problème d'optimisation. Soit $R = \{r_1, r_2, ..., r_n\}$ l'ensemble des requêtes de ressources provenant du pool HTCondor, et $B = \{b_1, b_2, ..., b_m\}$ l'ensemble des types de ressources backend disponibles (par ex., nœud HPC, VM Cloud). Chaque requête $r_i$ a des exigences (cœurs, mémoire, logiciel). Chaque backend $b_j$ a une fonction de coût $C_j(r_i)$ et un temps de provisionnement $T_j(r_i)$.

L'objectif du méta-ordonnanceur est de trouver un mappage $M: R \rightarrow B$ qui minimise une fonction de coût totale, souvent une somme pondérée du coût financier et du temps d'exécution, sous des contraintes comme les quotas backend et la disponibilité logicielle :

$$\min_{M} \sum_{r_i \in R} \left[ \alpha \cdot C_{M(r_i)}(r_i) + \beta \cdot T_{M(r_i)}(r_i) \right]$$

où $\alpha$ et $\beta$ sont des facteurs de pondération. Cela formalise le défi d'intégration « dynamique et transparente ».

5. Résultats du Prototype & Performances

L'article rend compte des premières expériences avec des applications scientifiques exécutées sur les prototypes disponibles. Bien que des benchmarks quantitatifs spécifiques ne soient pas détaillés dans l'extrait fourni, l'exécution réussie implique :

• Intégration Fonctionnelle : La pile HTCondor/COBalD/TARDIS a acheminé avec succès des travaux vers différents systèmes backend (HTC, HPC, Cloud).
• Livraison Logicielle : CVMFS et les conteneurs ont fourni de manière fiable les environnements logiciels nécessaires sur les nœuds de travail hétérogènes.
• Accès Utilisateur : JupyterHub et les nœuds de connexion ont servi de points d'entrée efficaces pour les chercheurs.

Diagramme Conceptuel : L'architecture du système peut être visualisée comme un modèle à trois couches :

1. Couche d'Accès Utilisateur : JupyterHub, Nœuds de Connexion, AAI à jetons.
2. Couche de Fédération & Ordonnancement : Pool HTCondor + Méta-ordonnanceur COBalD/TARDIS.
3. Couche de Ressources : Backends hétérogènes (clusters HPC, fermes HTC, VMs Cloud) et stockage fédéré (instances dCache, XRootD).

6. Cadre d'Analyse : Un Scénario d'Utilisation

Scénario : Un chercheur en physique nucléaire doit traiter 10 000 tâches de simulation Monte Carlo, chacune nécessitant 4 cœurs CPU, 16 Go de RAM et une pile logicielle spécifique (Geant4, ROOT).

1. Soumission : Le chercheur se connecte au JupyterHub PUNCH, écrit un script d'analyse et soumet 10 000 travaux à l'ordonnanceur HTCondor local.
2. Méta-Ordonnancement : COBalD/TARDIS surveille la file d'attente HTCondor. Il évalue les backends disponibles : la ferme HTC de l'Université A (faible coût, temps d'attente élevé), le cluster HPC de l'Institut B (coût modéré, matériel spécialisé) et un cloud commercial (coût élevé, disponibilité immédiate).
3. Décision & Exécution : En utilisant son modèle de coût, TARDIS pourrait décider de déverser 2 000 travaux immédiats sur le cloud pour démarrer rapidement, tout en traitant régulièrement le reste sur la ferme HTC moins chère. Il utilise l'AAI à jetons pour l'authentification sur tous les systèmes.
4. Logiciel & Données : Chaque travail, quel que soit le backend, récupère son environnement Geant4/ROOT depuis CVMFS. Les données d'entrée sont récupérées depuis l'espace de noms fédéré Storage4PUNCH (par ex., via XRootD), et la sortie est réécrite vers un point de terminaison de stockage désigné.
5. Achèvement : Le chercheur surveille et agrège les résultats depuis la file d'attente de travaux HTCondor unique, sans se soucier de l'exécution sous-jacente multi-infrastructure.

7. Analyse Critique & Perspective d'Expert

Idée Maîtresse : PUNCH4NFDI ne construit pas un autre cloud ; il conçoit une couche de fédération d'un pragmatisme politique et technique remarquable. Sa véritable innovation réside dans le méta-ordonnanceur COBalD/TARDIS, qui agit comme un « traducteur diplomatique » pour le partage des ressources, et non comme un unificateur conquérant. Cela reconnaît la souveraineté des clusters institutionnels existants — une réalité non négociable dans le milieu académique allemand — tout en créant une super-ressource fonctionnelle.

Enchaînement Logique : La logique est impeccable : commencer par l'utilisateur (JupyterHub/connexion), abstraire le chaos via un ordonnanceur éprouvé (HTCondor), puis utiliser un courtier intelligent (TARDIS) pour mapper des requêtes abstraites sur des backends concrets et politiquement réalisables. Le recours à CVMFS et aux conteneurs pour le logiciel est un coup de maître, résolvant le problème de « l'enfer des dépendances » qui afflige la plupart des fédérations. La stratégie de stockage est sagement conservatrice, s'appuyant sur le duo éprouvé dCache/XRootD de la HEP, évitant l'enlisement d'imposer une nouvelle technologie unique.

Points Forts & Faiblesses :

• Points Forts : L'invasion minimale est son super-pouvoir. Il n'exige pas des fournisseurs qu'ils changent leurs politiques locales. L'utilisation d'outils matures, pilotés par la communauté (HTCondor, CVMFS, dCache) réduit drastiquement les risques et augmente la durabilité, contrairement aux projets construits sur des frameworks sur mesure. L'accent sur les principes FAIR s'aligne parfaitement avec les mandats de financement modernes.
• Faiblesses & Risques : L'approche par méta-ordonnanceur introduit un point unique de complexité et de défaillance potentielle. COBalD/TARDIS, bien que prometteur, n'est pas aussi éprouvé que les autres composants. « L'évaluation » des technologies de cache/métadonnées (comme Rucio) laisse entrevoir que la partie la plus difficile est à venir : la gestion intelligente des données. Sans cela, il s'agit d'une fédération de calcul avec un répertoire de stockage attaché, et non d'une plateforme cohérente centrée sur les données. Il existe également un risque latent d'imprévisibilité des performances pour les utilisateurs, car leurs travaux sautent entre des architectures fondamentalement différentes.

Perspectives Actionnables :

1. Pour les Architectes de PUNCH : Renforcez la robustesse et l'observabilité de TARDIS. Ses métriques et journaux de décision sont cruciaux pour l'optimisation et l'établissement de la confiance. Priorisez ensuite l'intégration d'une couche de gestion des données (comme Rucio) ; le calcul sans données intelligentes n'est qu'une demi-solution.
2. Pour les Autres Consortiums : C'est un modèle à suivre, en particulier la philosophie « intégration plutôt que remplacement ». Cependant, évaluez si votre communauté dispose d'un équivalent à CVMFS — sinon, c'est votre première décision de construction/achat.
3. Pour les Fournisseurs de Ressources : Ce modèle est à faible risque pour vous. Engagez-vous. L'AAI à jetons est un moyen propre d'offrir un accès sans compromettre la sécurité locale. C'est un gain net pour la visibilité et l'utilisation.

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

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

• Flux de Travail Transversaux : Permettre des pipelines d'analyse complexes et multi-étapes qui se déplacent de manière transparente entre la simulation (HPC), le traitement d'événements à haut débit (HTC) et l'entraînement de modèles d'apprentissage automatique (GPU Cloud).
• Ordonnancement Centré sur les Données : Intégrer plus profondément la fédération de stockage avec l'ordonnanceur de calcul. Les futures versions de COBalD/TARDIS pourraient intégrer la localité des données (minimisant les transferts WAN) et le pré-positionnement dans sa fonction de coût, évoluant vers un ordonnancement conscient des données.
• Intégration avec les Dépôts de Données FAIR : Servir de colonne vertébrale de calcul haute performance pour les dépôts de données FAIR nationaux, permettant aux chercheurs d'analyser de grands ensembles de données directement là où ils sont stockés, suivant le paradigme « calcul vers les données ».
• IA/ML en tant que Service : L'interface JupyterHub et le backend évolutif pourraient être étendus avec des environnements organisés pour des frameworks IA/ML spécialisés (PyTorch, TensorFlow) et l'accès aux ressources GPU, démocratisant l'IA pour les sciences physiques.
• Extension aux Ressources Internationales : Le modèle de fédération pourrait être étendu pour incorporer des ressources d'initiatives européennes comme le European Open Science Cloud (EOSC) ou les sites de la grille de calcul du LHC (WLCG), créant une infrastructure de recherche véritablement paneuropéenne.

La feuille de route implique probablement de consolider le prototype actuel, d'augmenter le nombre de ressources intégrées, de mettre en œuvre les solutions de métadonnées/cache évaluées, et de développer des mécanismes de politique et de comptabilité plus sophistiqués pour une utilisation équitable des ressources au sein du consortium.

9. Références

1. Consortium PUNCH4NFDI. (2024). Livre Blanc PUNCH4NFDI. [Document Interne 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.
3. Blomer, J., et al. (2011). The CernVM file system. Journal of Physics: Conference Series, 331(5), 052004.
4. Documentation COBalD/TARDIS. (s.d.). Consulté sur https://tardis.readthedocs.io/
5. Collaboration dCache. (s.d.). dCache : Un système de stockage distribué. https://www.dcache.org/
6. Collaboration XRootD. (s.d.). XRootD : Accès aux données haute performance, évolutif et tolérant aux pannes. http://xrootd.org/
7. Wilkinson, M. D., et al. (2016). The FAIR Guiding Principles for scientific data management and stewardship. Scientific data, 3(1), 1-9.
8. European Open Science Cloud (EOSC). (s.d.). https://eosc-portal.eu/
9. Worldwide LHC Computing Grid (WLCG). (s.d.). https://wlcg.web.cern.ch/