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, de la physique hadronique et de la physique nucléaire. Intégré dans l'initiative plus large de l'NFDI, son objectif principal est d'établir une plateforme de données scientifiques fédérée et FAIR (Facile à trouver, Accessible, Interopérable, Réutilisable). Cette plateforme vise à fournir un accès transparent aux diverses ressources de calcul et de stockage des institutions impliquées, en relevant les défis communs posés par des volumes de données en croissance exponentielle et des algorithmes d'analyse intensifs en calcul. Ce document se concentre sur les concepts architecturaux — Compute4PUNCH et Storage4PUNCH — conçus pour fédérer l'infrastructure de recherche hétérogène de l'Allemagne.
2. Infrastructure Fédérée de Calcul Hétérogène – Compute4PUNCH
Compute4PUNCH relève le défi d'utiliser efficacement un large éventail de ressources apportées en nature, incluant des systèmes de Calcul à Haut Débit (HTC), de Calcul Haute Performance (HPC) et de Cloud, répartis à travers l'Allemagne. Ces ressources varient en architecture, systèmes d'exploitation, piles logicielles et politiques d'accès. Le principe de conception fondamental est de créer un système de superposition unifié avec une intrusion minimale sur les fournisseurs de ressources existants et opérationnels.
2.1. Architecture Principale & Intégration
La fédération est construite autour de HTCondor en tant que système batch de superposition central. Les ressources hétérogènes sont intégrées dynamiquement à l'aide du méta-ordonnanceur de ressources COBalD/TARDIS. COBalD/TARDIS agit comme un courtier intelligent, pilotant les tâches vers des backends appropriés (par exemple, clusters Slurm, Kubernetes) en fonction de la disponibilité des ressources, des exigences des tâches et des politiques. Cela crée un pool de ressources logique unique à partir de systèmes physiquement disparates.
2.2. Accès Utilisateur & Environnement Logiciel
Les points d'entrée utilisateur sont fournis via des nœuds de connexion traditionnels et un service JupyterHub. 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 via les technologies de conteneurs (par exemple, Docker, Singularity/Apptainer) et le Système de Fichiers de Machine Virtuelle du CERN (CVMFS), qui distribue des distributions logicielles scalables et en lecture seule aux nœuds de calcul à l'échelle mondiale.
3. Infrastructure Fédérée de Stockage – Storage4PUNCH
Storage4PUNCH vise à fédérer les systèmes de stockage fournis par la communauté, principalement basés sur les technologies dCache et XRootD, bien établies en physique des hautes énergies (HEP). La fédération utilise des espaces de noms et des protocoles communs (comme xrootd, WebDAV) pour présenter une couche d'accès aux données unifiée. Le concept évalue également l'intégration de solutions de mise en cache et de services de gestion des métadonnées pour améliorer la localité et la découvrabilité des données à travers la fédération.
4. Mise en Œuvre Technique & Composants
4.1. Authentification & Autorisation (AAI)
Une AAI basée sur des jetons (utilisant probablement les standards OAuth 2.0/OpenID Connect, similaires à WLCG IAM ou INDIGO IAM) offre une expérience d'authentification unique. Elle mappe les identités de la communauté aux autorisations locales sur les ressources, masquant ainsi l'hétérogénéité des systèmes d'authentification locaux (par exemple, Kerberos, clés SSH).
4.2. Méta-Ordonnancement des Ressources : COBalD/TARDIS
COBalD (le Coordinateur) et TARDIS (le Transparent Adaptive Resource Dynamic Integration System) fonctionnent en tandem. COBalD prend des décisions d'ordonnancement de haut niveau, tandis que TARDIS gère le cycle de vie des « pilotes » ou « tâches de substitution » sur les ressources cibles. Cette dissociation permet une application flexible des politiques (par exemple, coût, équité, priorité) et une adaptation dynamique aux états fluctuants des ressources. L'ordonnancement peut être modélisé comme un problème d'optimisation, minimisant une fonction de coût $C_{total} = \sum_{i}(w_i \cdot T_i) + \lambda \cdot R$, où $T_i$ est le temps de traitement de la tâche $i$, $w_i$ est son poids de priorité, $R$ représente le coût d'utilisation des ressources, et $\lambda$ est un paramètre d'équilibrage.
4.3. Couche Données & Logiciel
CVMFS est essentiel pour la distribution logicielle. Il utilise un modèle de stockage adressable par contenu et une mise en cache agressive (avec des serveurs Stratum 0/1 et des caches locaux Squid) pour délivrer efficacement les dépôts logiciels. La fédération emploie probablement une hiérarchie de strates CVMFS, avec un stratum 0 central du dépôt PUNCH et des miroirs stratum 1 institutionnels. L'accès aux données suit un modèle fédéré similaire, les éléments de stockage (SE) publiant leurs points de terminaison dans un annuaire global (comme Rucio ou un simple service REST), permettant aux clients de résoudre les emplacements des données de manière transparente.
5. État du Prototype & Premières Expériences
Le document indique que les prototypes de Compute4PUNCH et Storage4PUNCH sont opérationnels. Des applications scientifiques initiales ont été exécutées, fournissant des retours précieux sur les performances, la facilité d'utilisation et les points de friction d'intégration. Bien que des chiffres de benchmark spécifiques ne soient pas fournis dans l'extrait, l'exécution réussie implique que la fonctionnalité de base du système batch de superposition, l'intégration de l'AAI et la distribution logicielle via CVMFS ont été validées. Ces expériences guident les améliorations dans la configuration des politiques, la gestion des erreurs et la documentation utilisateur.
6. Principaux Enseignements & Analyse Stratégique
Enseignement Clé : PUNCH4NFDI ne construit pas un nouveau supercalculateur ; il conçoit un « tissu de fédération » qui assemble de manière pragmatique des ressources existantes et fragmentées. Il s'agit d'un changement stratégique d'une infrastructure monolithique vers une agrégation de ressources agile et définie par logiciel, reflétant les tendances du cloud commercial mais adaptée aux contraintes et à la culture du milieu académique financé par des fonds publics.
Logique de Flux : L'architecture suit une logique claire, basée sur les dépendances : 1) Unifier l'Identité (AAI) pour résoudre le problème du « qui », 2) Abstraire les Ressources (COBalD/TARDIS + HTCondor) pour résoudre le problème du « où », et 3) Découpler l'Environnement (Conteneurs + CVMFS) pour résoudre le problème du « avec quoi ». Cette abstraction en couches est de l'ingénierie système classique, rappelant le succès du Worldwide LHC Computing Grid (WLCG), mais appliquée à un ensemble de ressources plus diversifié.
Forces & Faiblesses : La force majeure est son modèle d'adoption non perturbateur. En utilisant des technologies de superposition et en respectant l'autonomie des sites, il abaisse la barrière pour les fournisseurs de ressources — un facteur de succès crucial pour les consortiums. Cependant, c'est aussi son talon d'Achille. La surcharge de performance du méta-ordonnancement et la complexité inhérente du débogage à travers des systèmes hétérogènes et administrés indépendamment peuvent être significatives. Le mandat de « perturbation minimale » peut limiter la capacité à mettre en œuvre des fonctionnalités avancées comme un couplage profond stockage-calcul ou une provision dynamique du réseau, limitant potentiellement les gains d'efficacité. Comparé à un système centralisé et conçu sur mesure comme Borg de Google ou un cluster Kubernetes, la fédération aura toujours une latence plus élevée et une prévisibilité d'utilisation plus faible.
Enseignements Actionnables : Pour d'autres consortiums envisageant cette voie : 1) Investissez massivement dans la surveillance et l'observabilité dès le premier jour. Des outils comme Grafana/Prometheus pour l'infrastructure et l'APM (Application Performance Monitoring) pour les tâches utilisateur sont non négociables pour gérer la complexité. 2) Standardisez sur un ensemble restreint d'images de base de conteneurs pour réduire la charge de maintenance de CVMFS. 3) Développez un modèle de support clair et hiérarchisé qui distingue les problèmes au niveau de la fédération des problèmes locaux des sites. Le vrai test ne sera pas la faisabilité technique — la communauté HEP l'a prouvée — mais la durabilité opérationnelle et la satisfaction des utilisateurs à grande échelle.
7. Plongée Technique Approfondie
Modèle Mathématique pour l'Ordonnancement des Ressources : Le système COBalD/TARDIS peut être conceptualisé comme résolvant un problème d'optimisation sous contraintes. Soit $J$ l'ensemble des tâches, $R$ l'ensemble des ressources, et $S$ l'ensemble des états des ressources (par exemple, inactif, occupé, drainé). L'ordonnanceur vise à maximiser une fonction d'utilité $U$ qui considère la priorité de la tâche $p_j$, l'efficacité de la ressource $e_{j,r}$, et le coût $c_r$ : $$\max \sum_{j \in J} \sum_{r \in R} x_{j,r} \cdot U(p_j, e_{j,r}, c_r)$$ sous les contraintes : $$\sum_{j} x_{j,r} \leq C_r \quad \forall r \in R \quad \text{(Capacité de la Ressource)}$$ $$\sum_{r} x_{j,r} \leq 1 \quad \forall j \in J \quad \text{(Affectation de la Tâche)}$$ $$x_{j,r} \in \{0,1\} \quad \text{(Variable de Décision Binaire)}$$ où $x_{j,r}=1$ si la tâche $j$ est affectée à la ressource $r$. TARDIS gère dynamiquement la faisabilité des affectations en fonction de l'état en temps réel $S$.
Résultats Expérimentaux & Description des Diagrammes : Bien que l'extrait PDF fourni ne contienne pas de graphiques de performance spécifiques, une évaluation typique inclurait des diagrammes comparant :
1. Débit des Tâches dans le Temps : Un graphique linéaire montrant le nombre de tâches terminées par heure dans le pool fédéré par rapport aux clusters de ressources individuels, démontrant l'avantage de l'agrégation.
2. Carte de Chaleur de l'Utilisation des Ressources : Une visualisation en grille montrant le pourcentage de CPU/GPU utilisés chez différents fournisseurs de ressources (KIT, DESY, Bielefeld, etc.) sur une semaine, mettant en évidence l'efficacité de l'équilibrage de charge.
3. CDF de la Latence de Démarrage des Tâches : Un graphique de fonction de distribution cumulative comparant le temps entre la soumission d'une tâche et le début de son exécution dans le système fédéré par rapport à une soumission directe à un système batch local, révélant la surcharge du méta-ordonnancement.
4. Performance d'Accès aux Données : Un diagramme à barres comparant les vitesses de lecture/écriture pour des données accessibles localement, depuis un élément de stockage fédéré dans la même région, et depuis un élément fédéré distant, illustrant l'impact de la mise en cache et du réseau.
8. Cadre d'Analyse & Modèle Conceptuel
Étude de Cas : Analyse Fédérée de Données de Sondage Astronomique
Scénario : Un groupe de recherche à la Thüringer Landessternwarte Tautenburg doit traiter 1 Po de données d'imagerie du Sloan Digital Sky Survey (SDSS) pour identifier des amas de galaxies, une tâche intensive en calcul nécessitant ~100 000 heures-CPU.
Processus via Compute4PUNCH/Storage4PUNCH :
1. Authentification : Le chercheur se connecte au JupyterHub PUNCH en utilisant ses identifiants institutionnels (via l'AAI basée sur jetons).
2. Environnement Logiciel : Le noyau de son notebook Jupyter s'exécute à partir d'une image conteneur hébergée sur CVMFS, contenant tous les packages d'astronomie nécessaires (Astropy, SExtractor, etc.).
3. Définition & Soumission de la Tâche : Il définit une tâche de balayage de paramètres dans le notebook. Le notebook utilise une bibliothèque cliente PUNCH pour soumettre celles-ci sous forme de DAG HTCondor (Graphe Orienté Acyclique) au pool fédéré.
4. Appariement des Ressources & Exécution : COBalD/TARDIS évalue les exigences de la tâche (CPU, mémoire, éventuellement GPU) et les pilote vers des emplacements disponibles à travers, par exemple, des pools HTC au KIT, des files d'attente HPC à l'Université de Bielefeld et des nœuds cloud au DESY. Les tâches lisent les données d'entrée via l'espace de noms XRootD fédéré depuis l'emplacement de stockage le plus proche, en tirant potentiellement parti d'un cache.
5. Agrégation des Résultats : Les fichiers de sortie sont réécrits dans le stockage fédéré. Le chercheur surveille la progression via un tableau de bord web unifié et agrège finalement les résultats dans son notebook pour analyse.
Ce cas démontre l'intégration transparente de l'identité, du calcul, du stockage et de la gestion logicielle.
9. Applications Futures & Feuille de Route de Développement
L'infrastructure PUNCH4NFDI jette les bases de plusieurs applications avancées :
1. Entraînement Fédéré d'Apprentissage Automatique : Le pool de ressources hétérogènes, incluant de potentiels clusters GPU, pourrait supporter des frameworks d'entraînement ML distribués comme PyTorch ou TensorFlow au-delà des frontières institutionnelles, répondant aux besoins d'entraînement préservant la confidentialité où les données ne peuvent être centralisées.
2. Analyse Interactive & Visualisation : Améliorer le service JupyterHub avec des outils de visualisation interactive évolutifs et alimentés par un backend (par exemple, des widgets Jupyter connectés à des clusters Dask sur la fédération) pour l'exploration de grands ensembles de données.
3. Intégration avec des Clouds Externes & Centres HPC : Étendre le modèle de fédération pour incorporer des crédits cloud commerciaux (par exemple, AWS, GCP) ou des centres nationaux de supercalcul (par exemple, JUWELS au JSC) via une couche commune de facturation/comptabilité, créant un véritable cloud hybride pour la science.
4. Intégration des Métadonnées et Data Lake : Aller au-delà de la simple fédération de fichiers vers une architecture de data lake intégrée, où la couche de stockage est couplée à un catalogue de métadonnées unifié (par exemple, basé sur Rucio ou iRODS), permettant la découverte de données et le suivi de la provenance à travers les communautés.
5. Workflow-as-a-Service : Offrir des services de plateforme de plus haut niveau comme REANA (Reproducible Analysis Platform) ou Apache Airflow au-dessus de l'infrastructure fédérée, permettant aux scientifiques de définir et d'exécuter des pipelines d'analyse complexes et reproductibles sans gérer l'infrastructure sous-jacente.
La feuille de route de développement se concentrera probablement sur le durcissement du service de production, l'expansion du pool de ressources, l'intégration d'outils de gestion de données plus sophistiqués et le développement d'API et de SDK conviviaux pour abaisser la barrière d'adoption pour les utilisateurs non experts.
10. 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 - Practice and Experience, 17(2-4), 323-356. https://doi.org/10.1002/cpe.938
- Blomer, J., et al. (2011). Distribution of software in the CernVM file system with Parrot. Journal of Physics: Conference Series, 331(4), 042009. https://doi.org/10.1088/1742-6596/331/4/042009
- Giffels, M., et al. (2022). COBalD and TARDIS – Dynamic resource overlay for opportunistic computing. EPJ Web of Conferences, 251, 02009. https://doi.org/10.1051/epjconf/202225102009
- Collaboration dCache. (2023). dCache : Un système de mise en cache de données de stockage distribué. Récupéré de https://www.dcache.org/
- Collaboration XRootD. (2023). XRootD : Accès aux données haute performance, évolutif et tolérant aux pannes. Récupéré de http://xrootd.org/
- Wilkinson, M. D., et al. (2016). The FAIR Guiding Principles for scientific data management and stewardship. Scientific Data, 3, 160018. https://doi.org/10.1038/sdata.2016.18
- Verma, A., et al. (2015). Large-scale cluster management at Google with Borg. Proceedings of the Tenth European Conference on Computer Systems (EuroSys '15). https://doi.org/10.1145/2741948.2741964