Compute4PUNCH & Storage4PUNCH : Infrastructure fédérée pour PUNCH4NFDI

1. Introduction & Aperçu

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, de la physique hadronique et de la physique nucléaire en Allemagne. Sa mission principale est d'établir une plateforme de données scientifiques fédérée et FAIR (Faciles à trouver, Accessibles, Interopérables, Réutilisables). Un défi central abordé est l'intégration transparente et l'accès unifié au vaste paysage hétérogène des ressources de calcul (HPC, HTC, Cloud) et de stockage apportées en nature par les institutions membres à travers l'Allemagne. Ce document détaille les concepts Compute4PUNCH et Storage4PUNCH conçus pour surmonter ces obstacles d'intégration.

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

Compute4PUNCH vise à créer un système batch fédéré national superposé, fournissant un accès transparent à des ressources de calcul diverses sans imposer de changements significatifs aux systèmes opérationnels existants, partagés par plusieurs communautés.

2.1 Architecture centrale & Composants

L'architecture est construite autour d'un système batch fédéré HTCondor. Le méta-ordonnanceur de ressources COBalD/TARDIS intègre dynamiquement des ressources hétérogènes (clusters HPC, fermes HTC, instances cloud) dans ce pool unifié. Les points d'entrée pour les utilisateurs incluent des nœuds de connexion traditionnels et un service JupyterHub, offrant des interfaces flexibles à l'ensemble du paysage des ressources.

2.2 Accès & Authentification (AAI)

Une infrastructure d'authentification et d'autorisation (AAI) basée sur des jetons fournit un accès standardisé et sécurisé à toutes les ressources fédérées, simplifiant l'expérience utilisateur et renforçant la sécurité.

2.3 Provisionnement de l'environnement logiciel

Pour gérer les besoins logiciels diversifiés, l'infrastructure exploite les technologies de conteneurs (par ex., Docker, Singularity/Apptainer) et le CERN Virtual Machine File System (CVMFS). CVMFS permet la distribution distribuée et évolutive de piles logicielles spécifiques aux communautés et de données d'expérience, garantissant la cohérence et réduisant la charge de stockage local sur les nœuds de calcul.

3. Infrastructure de stockage fédérée (Storage4PUNCH)

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

3.1 Technologie de fédération de stockage

La fédération crée un espace de noms unifié, permettant aux utilisateurs d'accéder aux données à travers plusieurs systèmes de stockage institutionnels comme s'il s'agissait d'une ressource unique. Cela s'appuie sur des protocoles et concepts éprouvés dans des collaborations à grande échelle comme le Worldwide LHC Computing Grid (WLCG).

3.2 Stratégies de mise en cache & de métadonnées

Le projet évalue les technologies existantes pour la mise en cache intelligente des données et la gestion des métadonnées. L'objectif est une intégration plus profonde pour optimiser le placement des données, réduire la latence et améliorer la découverte des données sur la base des principes FAIR.

4. Mise en œuvre technique & Détails

4.1 Modèle mathématique pour l'ordonnancement des ressources

L'ordonnanceur COBalD/TARDIS peut être conceptualisé comme résolvant 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, la mémoire et le coût. Soit $J = \{j_1, j_2, ..., j_m\}$ l'ensemble des tâches avec leurs exigences. L'ordonnanceur vise à maximiser une fonction d'utilité $U$ (par ex., le débit global, l'équité) sous contraintes :

$$\text{Maximiser } U(\text{Allocation}(R, J))$$

$$\text{sous contraintes : } \forall r_i \in R, \text{Utilisation}(r_i) \leq \text{Capacité}(r_i)$$

$$\text{et } \forall j_k \in J, \text{Exigences}(j_k) \subseteq \text{Attributs}(\text{RessourceAssignée}(j_k))$$

Cette approche dynamique et pilotée par des politiques est plus flexible que les systèmes de file d'attente statiques traditionnels.

4.2 Résultats du prototype & Performances

Les premiers prototypes ont démontré avec succès la fédération de ressources provenant d'institutions comme le KIT, le DESY et l'Université de Bielefeld. Les principales métriques de performance observées incluent :

Latence de soumission des tâches : Le système superposé ajoute une surcharge minimale, la soumission de tâches au pool HTCondor central étant généralement inférieure à 2 secondes.
Utilisation des ressources : Le regroupement dynamique permis par TARDIS a montré une augmentation potentielle de l'utilisation globale des ressources en comblant les « trous » dans les plannings des clusters individuels.
Accès aux données via CVMFS : Les temps de démarrage des logiciels depuis CVMFS étaient comparables aux installations locales après la mise en cache initiale, validant son utilisation pour une distribution logicielle évolutive.
Expérience utilisateur : Les premiers retours indiquent que l'interface JupyterHub et l'AAI basée sur des jetons abaissent significativement la barrière d'entrée pour les utilisateurs non familiers avec les systèmes batch en ligne de commande.

Note : Des benchmarks quantitatifs complets comparant le fonctionnement fédéré au fonctionnement isolé font partie des travaux en cours.

5. Cadre d'analyse & Étude de cas

Étude de cas : Analyse en astrophysique multi-messagers

Considérons un physicien des astroparticules analysant un événement de sursaut gamma. Le flux de travail implique :

Découverte des données : Utiliser l'espace de noms de stockage fédéré pour localiser les ensembles de données pertinents provenant des archives des rayons gamma (Fermi-LAT), optiques (LSST) et des ondes gravitationnelles (LIGO/Virgo), tous accessibles via un chemin unifié (par ex., /punche/data/events/GRB221009A).
Soumission du flux de travail : Le chercheur utilise le portail JupyterHub pour composer un script d'analyse multi-étapes. Le script spécifie les besoins à la fois pour le traitement d'image accéléré par GPU (pour les données optiques) et pour les tâches CPU à haute mémoire (pour l'ajustement spectral).
Exécution dynamique : La fédération Compute4PUNCH, via COBalD/TARDIS, achemine automatiquement la tâche GPU vers un cluster universitaire avec des nœuds V100/A100 disponibles et la tâche à haute mémoire vers un centre HPC avec des nœuds à grande mémoire, sans intervention de l'utilisateur.
Environnement logiciel : Toutes les tâches récupèrent un environnement conteneurisé cohérent avec des boîtes à outils d'astronomie spécifiques (par ex., Astropy, Gammapy) depuis CVMFS.
Agrégation des résultats : Les résultats intermédiaires sont réécrits dans le stockage fédéré, et les graphiques finaux sont générés, le tout géré dans la même session authentifiée.

Cette étude de cas démontre comment la fédération abstrait la complexité infrastructurelle, permettant au scientifique de se concentrer sur le problème scientifique.

6. Analyse critique & Perspective industrielle

Idée centrale : PUNCH4NFDI ne construit pas un autre cloud monolithique ; il conçoit une couche de fédération — un « méta-système d'exploitation » pour une infrastructure de recherche nationale distribuée et souveraine. C'est une réponse pragmatique et puissante au paysage fragmenté de l'e-science en Europe, privilégiant l'intégration au remplacement. Cela reflète la philosophie architecturale derrière des systèmes à grande échelle réussis comme Kubernetes pour l'orchestration de conteneurs, mais appliquée au niveau de centres de données entiers.

Logique : La logique est impeccable : 1) Reconnaître l'hétérogénéité et les investissements existants comme des contraintes immuables. 2) Introduire une couche d'abstraction minimale et non invasive (HTCondor + TARDIS) pour le calcul, et une fédération d'espace de noms pour le stockage. 3) Utiliser des intergiciels éprouvés et pilotés par la communauté (CVMFS, dCache, XRootD) comme blocs de construction pour garantir la stabilité et tirer parti de l'expertise existante. 4) Fournir des points d'entrée modernes et centrés sur l'utilisateur (JupyterHub, AAI à jetons). Cette logique minimise les frictions politiques et techniques pour les fournisseurs de ressources, ce qui est crucial pour l'adoption.

Forces & Faiblesses : La plus grande force du projet est sa réutilisation pragmatique de technologies matures de la communauté HEP, réduisant le risque de développement. L'accent mis sur une superposition non invasive est politiquement avisé. Cependant, l'approche comporte une dette technique inhérente. La complexité du débogage des problèmes de performance ou des pannes à travers plusieurs domaines administratifs indépendants, différentes politiques réseau et des ordonnanceurs superposés (local + fédéré) sera redoutable — un défi bien documenté dans la littérature du calcul en grille. La dépendance à HTCondor, bien que robuste, peut ne pas être optimale pour tous les modèles de charge de travail HPC, laissant potentiellement des performances sur la table pour les tâches MPI fortement couplées. De plus, bien que le document mentionne les principes FAIR, la mise en œuvre concrète de catalogues de métadonnées riches et intercommunautaires — un défi monumental — semble reportée à une évaluation future.

Perspectives actionnables : Pour les autres consortiums, le principal enseignement est la stratégie « superposition d'abord ». Avant de tenter de construire ou d'imposer un matériel commun, investissez dans le logiciel de liaison. La pile PUNCH4NFDI (HTCondor/TARDIS + CVMFS + Stockage Fédéré) représente une boîte à outils open-source convaincante pour les initiatives de cloud de recherche national. Cependant, ils doivent investir de manière proactive dans des outils d'observabilité inter-domaines — pensez à OpenTelemetry pour le calcul scientifique distribué — pour gérer la complexité qu'ils créent. Ils devraient également explorer des modèles d'ordonnancement hybrides, intégrant peut-être des éléments des travaux de fédération centrés sur le HPC comme SLURM ou des ordonnanceurs cloud-natifs pour une applicabilité plus large au-delà du HTC. Le succès de cette fédération se mesurera non pas en flops de pointe, mais par la réduction du « temps d'obtention d'un insight » pour ses 9 000 scientifiques.

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

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

Entraînement IA/ML à grande échelle : Le pool de ressources fédéré peut provisionner dynamiquement des clusters de nœuds GPU pour l'entraînement de grands modèles sur des ensembles de données scientifiques distribués, suivant des paradigmes similaires à ceux explorés par les benchmarks MLPerf HPC.
Analyse interactive & en temps réel : Un support amélioré pour les sessions interactives et les services se connectant aux flux de données en temps réel des télescopes ou détecteurs de particules, permettant une analyse « en direct » des données d'observation.
Apprentissage fédéré pour données sensibles : L'infrastructure pourrait être adaptée pour supporter des flux de travail d'apprentissage fédéré préservant la vie privée, où des modèles d'IA sont entraînés à travers plusieurs institutions sans partager les données brutes — une technique qui gagne du terrain en imagerie médicale et autres domaines.
Intégration avec le European Open Science Cloud (EOSC) : Agissant comme un puissant nœud national, la fédération PUNCH4NFDI pourrait fournir un accès transparent aux services et ressources de l'EOSC, et vice-versa, amplifiant son impact.
Flux de travail quantique-hybrides : À mesure que les bancs d'essai de calcul quantique deviennent disponibles, la fédération pourrait ordonnancer des tâches de pré-/post-traitement classiques parallèlement à des tâches de co-processeurs quantiques, gérant l'ensemble du flux de travail hybride.

La feuille de route de développement se concentrera probablement sur le durcissement du service de production, l'expansion du pool de ressources, la mise en œuvre de politiques avancées de gestion des données et l'approfondissement de l'intégration entre les couches de calcul et de stockage.

8. Références

Consortium PUNCH4NFDI. (2024). Livre blanc PUNCH4NFDI. [Document interne du consortium].
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
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
Fuhrmann, P., & Gulzow, V. (2006). dCache, the system for the storage of large amounts of data. 22nd IEEE Conference on Mass Storage Systems and Technologies (MSST'05). https://doi.org/10.1109/MSST.2005.47
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'algorithme complexe et gourmand en ressources entraînant la demande de calcul).
MLCommons Association. (2023). MLPerf HPC Benchmark. https://mlcommons.org/benchmarks/hpc/ (Cité comme référence pour les charges de travail IA/ML sur les systèmes HPC).
Commission européenne. (2024). European Open Science Cloud (EOSC). https://eosc-portal.eu/