Compute4PUNCH & Storage4PUNCH: Föderierte Infrastruktur für PUNCH4NFDI

1. Einführung & Überblick

Das von der Deutschen Forschungsgemeinschaft (DFG) geförderte Konsortium PUNCH4NFDI (Particles, Universe, NuClei and Hadrons for the National Research Data Infrastructure) repräsentiert etwa 9.000 Wissenschaftler:innen aus den Bereichen Teilchen-, Astro-, Astroteilchen-, Hadronen- und Kernphysik in Deutschland. Seine Hauptaufgabe ist der Aufbau einer föderierten, FAIR-konformen (Findable, Accessible, Interoperable, Reusable) Wissenschaftsdatenplattform. Eine zentrale Herausforderung ist die nahtlose Integration und der einheitliche Zugriff auf die umfangreichen, heterogenen Rechen- (HPC, HTC, Cloud) und Speicherressourcen, die von Mitgliedsinstitutionen in ganz Deutschland als Naturalleistung bereitgestellt werden. Dieses Dokument erläutert die Compute4PUNCH- und Storage4PUNCH-Konzepte, die entwickelt wurden, um diese Integrationshürden zu überwinden.

2. Föderierte heterogene Recheninfrastruktur (Compute4PUNCH)

Compute4PUNCH zielt darauf ab, ein bundesweites föderiertes Overlay-Batch-System zu schaffen, das transparenten Zugang zu verschiedenen Rechenressourcen bietet, ohne wesentliche Änderungen an den bestehenden, betriebenen Systemen zu erzwingen, die von mehreren Communities genutzt werden.

2.1 Kernarchitektur & Komponenten

Die Architektur basiert auf einem föderierten HTCondor-Batch-System. Der COBalD/TARDIS-Ressourcen-Meta-Scheduler integriert heterogene Ressourcen (HPC-Cluster, HTC-Farmen, Cloud-Instanzen) dynamisch in diesen vereinheitlichten Pool. Einstiegspunkte für Nutzer:innen sind traditionelle Login-Knoten und ein JupyterHub-Service, die flexible Schnittstellen zur gesamten Ressourcenlandschaft bieten.

2.2 Zugang & Authentifizierung (AAI)

Eine tokenbasierte Authentifizierungs- und Autorisierungsinfrastruktur (AAI) bietet standardisierten, sicheren Zugang zu allen föderierten Ressourcen, vereinfacht die Nutzererfahrung und erhöht die Sicherheit.

2.3 Bereitstellung der Softwareumgebung

Um die vielfältigen Softwareanforderungen zu bewältigen, nutzt die Infrastruktur Container-Technologien (z.B. Docker, Singularity/Apptainer) und das CERN Virtual Machine File System (CVMFS). CVMFS ermöglicht die skalierbare, verteilte Bereitstellung von Community-spezifischen Software-Stacks und Experimentdaten, gewährleistet Konsistenz und reduziert die lokale Speicherlast auf den Rechenknoten.

3. Föderierte Speicherinfrastruktur (Storage4PUNCH)

Storage4PUNCH konzentriert sich auf die Föderierung von von den Communities bereitgestellten Speichersystemen, die hauptsächlich auf den in der Hochenergiephysik (HEP) etablierten Technologien dCache und XRootD basieren.

3.1 Speicher-Föderierungstechnologie

Die Föderierung erzeugt einen einheitlichen Namensraum, der es Nutzer:innen ermöglicht, auf Daten über mehrere institutionelle Speichersysteme hinweg zuzugreifen, als handele es sich um eine einzige Ressource. Dabei werden Protokolle und Konzepte genutzt, die sich in groß angelegten Kollaborationen wie dem Worldwide LHC Computing Grid (WLCG) bewährt haben.

3.2 Caching- & Metadatenstrategien

Das Projekt evaluiert bestehende Technologien für intelligentes Daten-Caching und die Metadatenverwaltung. Ziel ist eine tiefere Integration, um die Datenplatzierung zu optimieren, Latenzzeiten zu reduzieren und die Datenfindung basierend auf FAIR-Prinzipien zu verbessern.

4. Technische Implementierung & Details

4.1 Mathematisches Modell für die Ressourcenplanung

Der COBalD/TARDIS-Scheduler kann konzeptionell als Lösung eines Optimierungsproblems betrachtet werden. Sei $R = \{r_1, r_2, ..., r_n\}$ die Menge der heterogenen Ressourcen, jede mit Attributen wie Architektur, verfügbare Kerne, Speicher und Kosten. Sei $J = \{j_1, j_2, ..., j_m\}$ die Menge der Jobs mit ihren Anforderungen. Der Scheduler zielt darauf ab, eine Nutzenfunktion $U$ (z.B. Gesamtdurchsatz, Fairness) unter Einhaltung von Nebenbedingungen zu maximieren:

$$\text{Maximiere } U(\text{Allokation}(R, J))$$

$$\text{unter den Nebenbedingungen: } \forall r_i \in R, \text{Nutzung}(r_i) \leq \text{Kapazität}(r_i)$$

$$\text{und } \forall j_k \in J, \text{Anforderungen}(j_k) \subseteq \text{Attribute}(\text{ZugewieseneRessource}(j_k))$$

Dieser dynamische, policy-gesteuerte Ansatz ist flexibler als traditionelle statische Queue-Systeme.

4.2 Prototypergebnisse & Leistung

Erste Prototypen haben die Föderierung von Ressourcen von Institutionen wie dem KIT, DESY und der Universität Bielefeld erfolgreich demonstriert. Beobachtete wichtige Leistungskennzahlen umfassen:

Job-Submission-Latenz: Das Overlay-System fügt minimalen Overhead hinzu, die Job-Submission in den zentralen HTCondor-Pool dauert typischerweise unter 2 Sekunden.
Ressourcennutzung: Der durch TARDIS ermöglichte dynamische Pooling zeigte ein Potenzial zur Steigerung der Gesamtressourcennutzung, indem „Lücken“ in den individuellen Cluster-Zeitplänen gefüllt werden.
Datenzugriff über CVMFS: Die Software-Startzeiten von CVMFS waren nach dem initialen Caching vergleichbar mit lokalen Installationen, was dessen Einsatz für skalierbare Softwareverteilung validiert.
Nutzererfahrung: Frühes Feedback deutet darauf hin, dass die JupyterHub-Oberfläche und die tokenbasierte AAI die Einstiegshürde für Nutzer:innen, die mit Kommandozeilen-Batch-Systemen nicht vertraut sind, deutlich senken.

Hinweis: Umfassende quantitative Benchmarks, die föderierten mit isoliertem Betrieb vergleichen, sind Teil der laufenden Arbeiten.

5. Analyseframework & Fallstudie

Fallstudie: Multi-Messenger-Astrophysik-Analyse

Betrachten Sie eine Astroteilchenphysikerin, die ein Gammastrahlenausbruch-Ereignis analysiert. Der Workflow umfasst:

Datenfindung: Nutzung des föderierten Speicher-Namensraums, um relevante Datensätze aus Gammastrahlen- (Fermi-LAT), optischen (LSST) und Gravitationswellen-Archiven (LIGO/Virgo) zu lokalisieren, alle über einen einheitlichen Pfad zugänglich (z.B. /punche/data/events/GRB221009A).
Workflow-Submission: Die Forscherin nutzt das JupyterHub-Portal, um ein mehrstufiges Analysescript zu erstellen. Das Script spezifiziert Bedarf sowohl für GPU-beschleunigte Bildverarbeitung (für optische Daten) als auch für speicherintensive CPU-Aufgaben (für Spektralanpassung).
Dynamische Ausführung: Die Compute4PUNCH-Föderierung leitet über COBalD/TARDIS den GPU-Job automatisch an einen Universitätscluster mit verfügbaren V100/A100-Knoten und den speicherintensiven Job an ein HPC-Zentrum mit großen Speicherknoten weiter, ohne Nutzerintervention.
Softwareumgebung: Alle Jobs laden eine konsistente containerisierte Umgebung mit spezifischen Astronomie-Toolkits (z.B. Astropy, Gammapy) von CVMFS.
Ergebnisaggregation: Zwischenergebnisse werden zurück in den föderierten Speicher geschrieben und finale Grafiken werden erzeugt, alles innerhalb derselben authentifizierten Sitzung verwaltet.

Diese Fallstudie zeigt, wie die Föderierung die infrastrukturelle Komplexität abstrahiert und es der Wissenschaftlerin ermöglicht, sich auf das wissenschaftliche Problem zu konzentrieren.

6. Kritische Analyse & Branchenperspektive

Kernerkenntnis: PUNCH4NFDI baut keine weitere monolithische Cloud; es entwickelt eine Föderierungsschicht – ein „Meta-Betriebssystem“ für national verteilte, souveräne Forschungsinfrastruktur. Dies ist eine pragmatische und wirkungsvolle Antwort auf die fragmentierte europäische E-Science-Landschaft, die Integration vor Ersatz stellt. Es spiegelt die Architekturphilosophie erfolgreicher großskaliger Systeme wie Kubernetes für die Container-Orchestrierung wider, jedoch auf der Ebene ganzer Rechenzentren angewendet.

Logischer Ablauf: Die Logik ist einwandfrei: 1) Heterogenität und bestehende Investitionen als unveränderliche Randbedingungen anerkennen. 2) Eine minimale, nicht-invasive Abstraktionsschicht (HTCondor + TARDIS) für Rechenleistung und Namensraum-Föderierung für Speicher einführen. 3) Bewährte, community-getriebene Middleware (CVMFS, dCache, XRootD) als Bausteine nutzen, um Stabilität zu gewährleisten und bestehende Expertise zu nutzen. 4) Moderne, nutzerzentrierte Einstiegspunkte (JupyterHub, token-AAI) bereitstellen. Dieser Ablauf minimiert politische und technische Reibung für Ressourcenanbieter, was für die Akzeptanz entscheidend ist.

Stärken & Schwächen: Die größte Stärke des Projekts ist die pragmatische Wiederverwendung ausgereifter Technologien aus der HEP-Community, was das Entwicklungsrisiko reduziert. Der Fokus auf ein nicht-invasives Overlay ist politisch klug. Jedoch birgt der Ansatz inhärente technische Schulden. Die Komplexität der Fehlerbehebung bei Leistungsproblemen oder Ausfällen über mehrere unabhängige Verwaltungsdomänen, unterschiedliche Netzwerkrichtlinien und geschichtete Scheduler (lokal + föderiert) hinweg wird enorm sein – eine Herausforderung, die in der Grid-Computing-Literatur gut dokumentiert ist. Die Abhängigkeit von HTCondor, obwohl robust, ist möglicherweise nicht optimal für alle HPC-Workload-Muster, was bei eng gekoppelten MPI-Jobs potenziell Leistung ungenutzt lässt. Darüber hinaus scheint die konkrete Implementierung umfangreicher, community-übergreifender Metadatenkataloge – eine monumentale Herausforderung – trotz Erwähnung der FAIR-Prinzipien auf zukünftige Evaluationen verschoben.

Umsetzbare Erkenntnisse: Für andere Konsortien ist die zentrale Erkenntnis die „Overlay-First“-Strategie. Bevor versucht wird, gemeinsame Hardware zu bauen oder vorzuschreiben, sollte in die Software-„Klebstoffschicht“ investiert werden. Der PUNCH4NFDI-Stack (HTCondor/TARDIS + CVMFS + Föderierter Speicher) stellt ein überzeugendes Open-Source-Toolkit für nationale Forschungscloud-Initiativen dar. Sie müssen jedoch proaktiv in domänenübergreifende Beobachtbarkeitstools investieren – vergleichbar mit OpenTelemetry für verteiltes wissenschaftliches Rechnen – um die von ihnen geschaffene Komplexität zu managen. Sie sollten auch hybride Scheduling-Modelle erkunden, etwa die Integration von Elementen der HPC-zentrierten SLURM-Föderierungsarbeit oder Cloud-nativer Scheduler für eine breitere Anwendbarkeit über HTC hinaus. Der Erfolg dieser Föderierung wird nicht an Spitzen-FLOPS gemessen, sondern an der Verkürzung der „Time to Insight“ für ihre 9.000 Wissenschaftler:innen.

7. Zukünftige Anwendungen & Entwicklungsfahrplan

Die PUNCH4NFDI-Infrastruktur legt den Grundstein für mehrere fortgeschrittene Anwendungen:

KI/ML-Training im großen Maßstab: Der föderierte Ressourcenpool kann dynamisch Cluster von GPU-Knoten für das Training großer Modelle auf verteilten wissenschaftlichen Datensätzen bereitstellen, ähnlich den Paradigmen, die von den MLPerf HPC Benchmarks untersucht werden.
Interaktive & Echtzeit-Analyse: Verbesserte Unterstützung für interaktive Sitzungen und Services, die sich mit Echtzeit-Datenströmen von Teleskopen oder Teilchendetektoren verbinden, ermöglicht „Live“-Analyse von Beobachtungsdaten.
Föderiertes Lernen für sensible Daten: Die Infrastruktur könnte angepasst werden, um datenschutzbewahrende föderierte Lern-Workflows zu unterstützen, bei denen KI-Modelle über mehrere Institutionen hinweg trainiert werden, ohne Rohdaten auszutauschen – eine Technik, die in der medizinischen Bildgebung und anderen Feldern an Bedeutung gewinnt.
Integration mit der European Open Science Cloud (EOSC): Als leistungsstarker nationaler Knoten könnte die PUNCH4NFDI-Föderierung nahtlosen Zugang zu EOSC-Diensten und -Ressourcen bieten und umgekehrt, wodurch ihre Wirkung verstärkt wird.
Quanten-Hybrid-Workflows: Sobald Quantencomputing-Testumgebungen verfügbar werden, könnte die Föderierung klassische Vor-/Nachverarbeitungsjobs neben Quanten-Co-Prozessor-Aufgaben planen und den gesamten Hybrid-Workflow managen.

Der Entwicklungsfahrplan wird sich voraussichtlich auf die Stabilisierung des Produktionsdienstes, die Erweiterung des Ressourcenpools, die Implementierung fortschrittlicher Datenmanagementrichtlinien und die Vertiefung der Integration zwischen Rechen- und Speicherschichten konzentrieren.

8. Referenzen

PUNCH4NFDI-Konsortium. (2024). PUNCH4NFDI White Paper. [Internes Konsortiumsdokument].
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). (Zitiert als Beispiel für einen komplexen, ressourcenintensiven Algorithmus, der die Rechennachfrage antreibt).
MLCommons Association. (2023). MLPerf HPC Benchmark. https://mlcommons.org/benchmarks/hpc/ (Zitiert als Referenz für KI/ML-Workloads auf HPC-Systemen).
European Commission. (2024). European Open Science Cloud (EOSC). https://eosc-portal.eu/