Föderierte heterogene Rechen- und Speicherinfrastruktur für PUNCH4NFDI

1. Einführung

Particles, Universe, NuClei and Hadrons for the National Research Data Infrastructure (PUNCH4NFDI) ist ein großes, von der DFG (Deutsche Forschungsgemeinschaft) gefördertes deutsches Konsortium. Es repräsentiert etwa 9.000 Wissenschaftlerinnen und Wissenschaftler aus den Bereichen Teilchen-, Astro-, Astroteilchen-, Hadronen- und Kernphysik. Das primäre Ziel des Konsortiums ist der Aufbau einer föderierten, FAIR-konformen (Findable, Accessible, Interoperable, Reusable) Wissenschaftsdatenplattform. Diese Plattform soll einen nahtlosen Zugang zu den vielfältigen und heterogenen Rechen- und Speicherressourcen bieten, die über die teilnehmenden Einrichtungen verteilt sind, und so gemeinsame Herausforderungen wie massive Datenvolumina und komplexe, ressourcenintensive Algorithmen adressieren. Dieses Dokument konzentriert sich auf die architektonischen Konzepte – Compute4PUNCH und Storage4PUNCH –, die entwickelt wurden, um diese als Naturalleistung beigesteuerten Ressourcen zu föderieren.

2. Föderierte heterogene Recheninfrastruktur – Compute4PUNCH

Das Compute4PUNCH-Konzept adressiert die Herausforderung, einen einheitlichen Zugang zu einer breiten Palette bestehender High-Throughput-Compute (HTC)-, High-Performance-Compute (HPC)- und Cloud-Ressourcen zu bieten, die von verschiedenen Einrichtungen beigesteuert werden. Diese Ressourcen unterscheiden sich in Architektur, Betriebssystem, Software und Authentifizierung. Die zentrale Randbedingung ist die Minimierung von Änderungen an bestehenden, betriebenen Systemen, die von mehreren Communities gemeinsam genutzt werden.

2.1 Kernarchitektur & Integrationsstrategie

Die Strategie setzt auf ein föderiertes Overlay-Batch-System. Anstatt lokale Ressourcenmanager (wie SLURM, PBS) zu modifizieren, wird ein HTCondor-basierter Overlay-Pool erstellt. Der COBalD/TARDIS-Ressourcen-Meta-Scheduler integriert heterogene Backends (HPC-Cluster, HTC-Farmen, Cloud-VMs) dynamisch und transparent in diesen vereinheitlichten Pool. Er fungiert als ein "Pilot"-System, das Platzhalter-Jobs einreicht, um Ressourcen zu beanspruchen, und dann die eigentlichen Nutzer-Workloads darauf ausführt.

2.2 Nutzerzugang & Softwareumgebung

Der Zugang erfolgt über traditionelle Login-Knoten und einen JupyterHub-Dienst, die als zentrale Einstiegspunkte dienen. Eine tokenbasierte Authentifizierungs- und Autorisierungsinfrastruktur (AAI) standardisiert den Zugriff. Die Komplexität der Softwareumgebung wird durch Container-Technologien (Docker, Singularity/Apptainer) und das CERN Virtual Machine File System (CVMFS) bewältigt, das vorkonfigurierte, community-spezifische Software-Stacks auf skalierbare, schreibgeschützte Weise bereitstellt.

3. Föderierte Speicherinfrastruktur – Storage4PUNCH

Storage4PUNCH zielt darauf ab, von den Communities bereitgestellte Speichersysteme zu föderieren, die hauptsächlich auf dCache- oder XRootD-Technologien basieren, die in der Hochenergiephysik (HEP) etabliert sind. Die Föderation schafft einen gemeinsamen Namensraum und Zugangslayer. Das Konzept evaluiert auch bestehende Technologien für Caching (zur Reduzierung von Latenz und WAN-Datenverkehr) und Metadatenverwaltung, mit dem Ziel einer tieferen Integration, um die Datenermittlung und -verwaltung über den föderierten Speicher hinweg zu erleichtern.

4. Technische Umsetzung & Kernkomponenten

4.1 Rechenföderation: HTCondor & COBalD/TARDIS

HTCondor: Bietet die Job-Management-Schicht, das Queuing und Scheduling innerhalb des föderierten Pools. Sein ClassAd-Mechanismus ermöglicht das Matching komplexer Job-Anforderungen mit dynamischen Ressourceneigenschaften.
COBalD/TARDIS: Sitzt zwischen HTCondor und den heterogenen Backends. TARDIS übersetzt HTCondor-"Piloten" in backend-spezifische Einreichungsbefehle (z.B. ein SLURM-Job-Skript). COBalD implementiert die Entscheidungslogik, wann und wo diese Piloten basierend auf Richtlinien, Kosten und Warteschlangenstatus gestartet werden sollen. Die Kernfunktion kann als Optimierungsproblem modelliert werden: $\text{Maximiere } U = \sum_{r \in R} (w_r \cdot u_r(\text{alloc}_r)) \text{ unter der Bedingung } \text{alloc}_r \leq \text{cap}_r, \forall r \in R$, wobei $U$ der Gesamtnutzen ist, $R$ die Menge der Ressourcentypen, $w_r$ ein Gewicht, $u_r$ eine Nutzenfunktion für Ressourcentyp $r$, $\text{alloc}_r$ die zugewiesene Kapazität und $\text{cap}_r$ die Gesamtkapazität ist.

4.2 Speicherföderation: dCache & XRootD

dCache: Ein hierarchisches Speicherverwaltungssystem, oft als Frontend für Tape-Archive verwendet. Es bietet POSIX-ähnliche Schnittstellen (NFS, WebDAV) und HEP-spezifische Protokolle (xrootd, gridftp).
XRootD: Ein Protokoll und eine Suite für skalierbaren, fehlertoleranten Datenzugriff. Seine "Redirector"-Komponente ermöglicht den Aufbau von Föderationen, bei denen eine Client-Anfrage zum entsprechenden Datenserver weitergeleitet wird.
Die Föderation schafft eine logische Schicht, die mehrere physische Instanzen als ein einziges System präsentiert, was für datenlokationsbewusstes Scheduling entscheidend ist.

4.3 Software- & Datenbereitstellung: Container & CVMFS

Container: Gewährleisten reproduzierbare Softwareumgebungen über verschiedene Hostsysteme hinweg. Sie kapseln komplexe Abhängigkeiten (z.B. spezifische Versionen von ROOT, Geant4).
CVMFS: Ein globales, verteiltes Dateisystem für die Softwareverteilung. Es nutzt HTTP und aggressives Caching. Sein Inhalt wird einmal veröffentlicht und ist überall verfügbar, was das Problem der Softwarebereitstellung in großem Maßstab löst. Der Veröffentlichungsprozess umfasst einen "Stratum 0"-Server und die Replikation auf "Stratum 1"-Spiegel.

5. Prototyp-Status & erste Erfahrungen

Der Beitrag berichtet, dass Prototypen sowohl für Compute4PUNCH als auch für Storage4PUNCH bereitgestellt wurden. Erste wissenschaftliche Anwendungen wurden erfolgreich auf den verfügbaren Prototypen ausgeführt, was die Machbarkeit der Konzepte demonstriert. Spezifische Leistungsmetriken oder detaillierte Fallstudien werden im Abstract nicht angegeben, aber die erfolgreiche Ausführung validiert den Integrationsansatz und den gewählten Technologie-Stack.

7. Originalanalyse: Kernaussage, logischer Ablauf, Stärken & Schwächen, umsetzbare Erkenntnisse

Kernaussage: PUNCH4NFDI baut keinen neuen Supercomputer; es orchestriert ein Symphonieorchester bestehender, disparater Instrumente. Seine wahre Innovation liegt in der Meta-Schicht – dem "Orchesterdirigenten", bestehend aus COBalD/TARDIS und Föderationsprotokollen –, der einen vereinheitlichten Ressourcenpool schafft, ohne Homogenität von den zugrundeliegenden Anbietern zu verlangen. Dies ist ein strategischer Meisterstreich für politisch komplexe, multi-institutionelle Kollaborationen, der an das Paradigma des föderierten Lernens in der KI erinnert (wie in Googles Arbeit zu Federated Averaging), bei dem Daten verteilt bleiben, aber Modelle aggregiert werden.

Logischer Ablauf: Die Architektur folgt einer sauberen Trennung der Belange. 1) Zugang & Identität: Tokenbasierte AAI authentifiziert Nutzer. 2) Rechenabstraktion: Der Nutzer reicht einen Job bei HTCondor ein. COBalD/TARDIS überwacht die Warteschlangen, entscheidet, welches Backend (z.B. der HPC-Cluster einer Universität) Kapazität hat, und setzt einen Pilot-Job ein, um diese Ressourcen für den HTCondor-Pool zu "beanspruchen". Der eigentliche Nutzer-Job läuft dann innerhalb dieses Piloten. 3) Softwareumgebung: Der Job lädt seinen spezifischen Software-Stack über CVMFS oder aus einer Container-Registry. 4) Datenzugriff: Der Job liest/schreibt Daten über die föderierte Speicherschicht (dCache/XRootD), die Anfragen an den tatsächlichen Datenstandort weiterleitet.

Stärken & Schwächen: Die Stärke ist unbestreitbarer Pragmatismus. Durch das Einwickeln bestehender Systeme erreicht es schnelle Einsatzfähigkeit und Akzeptanz bei den Ressourcenbesitzern. Die Nutzung des HEP-erprobten Tech-Stacks (validiert durch den Erfolg des Worldwide LHC Computing Grid des CERN) ist ein wesentlicher Risikominderer. Die Schwächen liegen jedoch in der inhärenten Komplexität der Meta-Scheduling-Schicht. COBalD/TARDIS muss intelligente Bereitstellungsentscheidungen über heterogene Systeme mit unterschiedlichen Richtlinien, Kosten (z.B. Cloud-Guthaben) und Leistungsprofilen treffen. Eine schlecht abgestimmte Richtlinie könnte zu ineffizienter Ressourcennutzung oder Job-Verhungern führen. Darüber hinaus scheinen, während die Speicherföderation einen einheitlichen Zugang bietet, erweiterte Datenverwaltungsfunktionen wie globale Namensraum-Indizierung, Metadatenkatalog-Föderation und intelligente Datenplatzierung (ähnlich Ideen im Lustre-Parallel-Dateisystem oder Forschung zu automatischem Data Tiering) zukünftige Evaluierungspunkte zu sein, was eine aktuelle Einschränkung darstellt.

Umsetzbare Erkenntnisse: Für andere Konsortien (z.B. in der Bioinformatik oder Klimaforschung) ist die Erkenntnis, von Anfang an stark in das Design des Meta-Schedulers und der Abstraktionsschicht zu investieren. Der PUNCH-Ansatz legt nahe, mit einer minimalen, funktionsfähigen Föderation unter Verwendung einer stabilen Technologie wie HTCondor zu beginnen, anstatt einen Greenfield-Build zu versuchen. Ressourcenanbieter sollten mit klaren, minimalen API-ähnlichen Anforderungen eingebunden werden (z.B. "muss SSH oder einen bestimmten Batch-System-Befehl unterstützen"). Entscheidend ist, dass das Projekt robuste Monitoring- und Audit-Tools für die föderierte Schicht selbst entwickeln muss – das Verständnis der standortübergreifenden Nutzung und die Diagnose von Fehlern in dieser komplexen Kette werden von operativer Bedeutung sein. Der zukünftige Fahrplan sollte explizit die Integration von Workflow-Managern (wie Nextflow oder Apache Airflow) und die Entwicklung der evaluierten Caching- und Metadatendienste adressieren, um von einer einfachen Föderation zu einer intelligenten, leistungsoptimierten Datenlogistik überzugehen.

8. Technische Details & mathematisches Rahmenwerk

Das von COBalD/TARDIS angegangene Ressourcenzuweisungsproblem kann als Online-Optimierung formuliert werden. Sei $Q(t)$ die Warteschlange ausstehender Jobs in HTCondor zum Zeitpunkt $t$, jeder mit geschätzter Laufzeit $\hat{r}_i$ und Ressourcenanforderungsvektor $\vec{c}_i$ (CPU, Speicher, GPU). Sei $B$ die Menge der Backends, jedes mit einer zeitvariablen verfügbaren Kapazität $\vec{C}_b(t)$ und einer Kostenfunktion $f_b(\vec{c}, \Delta t)$ für die Zuweisung von Ressourcen $\vec{c}$ für die Dauer $\Delta t$. Das Ziel des Meta-Schedulers ist es, die durchschnittliche Job-Durchlaufzeit $T_{ta}$ zu minimieren, während Backend-Richtlinien und eine Budgetbeschränkung eingehalten werden. Eine vereinfachte heuristische Entscheidungsregel für das Starten eines Piloten auf Backend $b$ könnte sein: $\text{Starte, wenn } \frac{|\{j \in Q(t): \vec{c}_j \preceq \vec{C}_b(t)\}|}{\text{Cost}_b} > \theta$, wobei $\preceq$ "passt in" bedeutet, $\text{Cost}_b$ eine normalisierte Kostenmetrik ist und $\theta$ ein Schwellenwert. Dies erfasst den Trade-off zwischen Nachfrage in der Warteschlange und Bereitstellungskosten.

9. Experimentelle Ergebnisse & Prototyp-Metriken

Während das bereitgestellte PDF-Abstract keine spezifischen quantitativen Ergebnisse enthält, impliziert ein erfolgreicher Prototyp wichtige qualitative und potenzielle quantitative Ergebnisse:

• Funktionaler Erfolg: Demonstrierte Fähigkeit, einen einzelnen Job über HTCondor/JupyterHub einzureichen und ihn transparent auf einer entfernten HPC- oder HTC-Ressource ausführen zu lassen, mit Software von CVMFS und Daten aus föderiertem Speicher.
• Wichtige zu verfolgende Metriken (Zukunft):
  • Job-Erfolgsrate: Prozentsatz der Jobs, die erfolgreich über die Föderation hinweg abgeschlossen werden.
  • Durchschnittliche Wartezeit: Zeit von der Einreichung bis zum Start, verglichen mit nativen Backend-Warteschlangen.
  • Ressourcennutzung: Gelieferte aggregierte CPU-Stunden über den föderierten Pool hinweg.
  • Datenübertragungseffizienz: Durchsatz und Latenz für Jobs, die über die Föderationsschicht auf entfernten Speicher zugreifen.
• Diagrammbeschreibung: Ein konzeptionelles Architekturdiagramm würde zeigen: Nutzer interagieren mit JupyterHub/Login-Knoten. Diese verbinden sich mit einem zentralen HTCondor Central Manager. Die COBalD/TARDIS-Komponente interagiert sowohl mit HTCondor als auch mit mehreren Resource Backends (HPC-Cluster A, HTC-Farm B, Cloud C). Jedes Backend hat ein lokales Batch-System (SLURM, PBS, etc.). Pfeile zeigen Job-Einreichung und Pilot-Bereitstellung an. Ein separater Abschnitt zeigt Föderierten Speicher (dCache-, XRootD-Instanzen), der mit den Backends verbunden und für Jobs zugänglich ist. CVMFS Stratum 1-Spiegel sind als eine von allen Backends zugängliche Schicht dargestellt.

10. Analyse-Framework: Konzeptionelles Workflow-Beispiel

Szenario: Ein Astroteilchenphysiker muss 1.000 Teleskopbilder mit einer komplexen, benutzerdefinierten Analyse-Pipeline (basierend auf Python/ROOT) verarbeiten.

1. Nutzereinstieg: Der Forscher meldet sich beim PUNCH JupyterHub an.
2. Umgebungseinrichtung: In einem Jupyter-Notebook wählt er einen vordefinierten Kernel aus, der von einem Singularity-Container unterstützt wird, der seinen spezifischen Software-Stack enthält (auf CVMFS veröffentlicht).
3. Job-Definition: Er schreibt ein Skript, das die Analyseaufgabe definiert, und verwendet eine PUNCH-Hilfsbibliothek, um eine HTCondor-Submit-Beschreibung zu erstellen, die benötigte CPUs, Speicher und Eingabedatenreferenzen angibt (z.B. `root://fed-storage.punch.org/pfad/zu/images_*.fits`).
4. Einreichung & Scheduling: Der Job wird an den HTCondor-Pool übermittelt. COBalD/TARDIS entscheidet, angesichts von 1.000 kurzen Jobs, mehrere Pilot-Jobs auf einer High-Throughput-Farm (Backend B) mit schnellem lokalem Speicher-Cache für die Eingabedaten zu starten.
5. Ausführung: Piloten beanspruchen Slots auf Backend B. Jeder Pilot lädt den Container, holt seine zugewiesenen Eingabedateien über die XRootD-Föderation (die möglicherweise auf einen lokalen Cache weiterleitet), führt die Analyse aus und schreibt Ergebnisse zurück in den föderierten Speicher.
6. Abschluss: HTCondor aggregiert den Job-Abschlussstatus. Das Notebook des Forschers kann nun die Ergebnisse vom Ausgabespeicherort abfragen und visualisieren.

Dieses Beispiel hebt die vollständige Abstraktion hervor: Der Nutzer musste nie etwas über SLURM-Befehle auf Backend B wissen, wie ROOT dort installiert wird oder den physischen Standort der Datendateien.

11. Zukünftige Anwendungen & Entwicklungsfahrplan

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

• Multi-Messenger-Astrophysik-Workflows: Echtzeit-Korrelationsanalysen zwischen Gravitationswellen- (LIGO/Virgo), Neutrino- (IceCube) und elektromagnetischen Observatoriumsdaten, die dringende Rechenleistung über geografisch verteilte Ressourcen hinweg erfordern.
• KI/ML-Modelltraining im großen Maßstab: Experimente zum föderierten Lernen, bei denen der Trainingsprozess selbst über die Rechenföderation verteilt ist und Modelle zentral aggregiert werden – eine Rechenparallele zur Datenföderation.
• Digitale Zwillinge komplexer Experimente: Ausführung massiver Simulations-Ensembles, um digitale Gegenstücke von Teilchendetektoren oder Teleskop-Arrays zu erstellen, wobei HPC für Simulationen und HTC für Parameterscans genutzt wird.

Entwicklungsfahrplan:

1. Kurzfristig (1-2 Jahre): Produktionsreife Bereitstellung der Compute4PUNCH- und Storage4PUNCH-Kerndienste festigen. Erweiterte Monitoring- (Prometheus/Grafana) und Abrechnungs-/Accounting-Tools integrieren.
2. Mittelfristig (3-4 Jahre): Die evaluierten Caching- und globalen Metadatenkatalogdienste implementieren und integrieren. Engere Integration mit Workflow-Management-Systemen entwickeln. "Bursting" in kommerzielle Clouds bei Spitzenlast explorieren.
3. Langfristig (5+ Jahre): Entwicklung hin zu einem "intelligenten Data Lakehouse" für die PUNCH-Wissenschaft, das Datenermittlung, Provenance-Tracking und automatisierte Datenlebenszyklusverwaltung, angetrieben durch die föderierten Metadaten, integriert. Als Blaupause für andere NFDI-Konsortien und internationale Kollaborationen dienen.

12. Referenzen

1. PUNCH4NFDI-Konsortium. (2024). PUNCH4NFDI White Paper. [Offizielle Konsortiumsdokumentation].
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. https://doi.org/10.1002/cpe.938
3. Krebs, K., et al. (2022). COBalD/TARDIS – A dynamic resource provisioning framework for heterogeneous computing environments. Journal of Physics: Conference Series, 2438(1), 012045. (Referenz für den Meta-Scheduler).
4. 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
5. dCache Collaboration. (2023). dCache.org [Software und Dokumentation]. https://www.dcache.org
6. XRootD Collaboration. (2023). XRootD Documentation. http://xrootd.org/docs.html
7. McMahan, B., Moore, E., Ramage, D., Hampson, S., & y Arcas, B. A. (2017). Communication-Efficient Learning of Deep Networks from Decentralized Data. Proceedings of the 20th International Conference on Artificial Intelligence and Statistics (AISTATS). (Zitiert für die Analogie zum föderierten Lernen).
8. European Organization for Nuclear Research (CERN). (2023). Worldwide LHC Computing Grid (WLCG). https://wlcg.web.cern.ch (Zitiert als Präzedenzfall für großskalige Föderation).