1. Einleitung
Das von der Deutschen Forschungsgemeinschaft (DFG) geförderte PUNCH4NFDI-Konsortium (Particles, Universe, NuClei and Hadrons for the National Research Data Infrastructure) repräsentiert etwa 9.000 Wissenschaftler:innen aus den deutschen Communities der Teilchen-, Astro-, Astroteilchen-, Hadronen- und Kernphysik. Eingebettet in die nationale NFDI-Initiative ist sein Hauptziel, eine föderierte und FAIR (Findable, Accessible, Interoperable, Reusable) Wissenschaftsdatenplattform zu etablieren. Diese Plattform soll einen nahtlosen Zugang zu den vielfältigen und heterogenen Rechen- und Speicherressourcen bieten, die von seinen Mitgliedsinstitutionen beigesteuert werden, und so die gemeinsame Herausforderung bewältigen, exponentiell wachsende Datenmengen mit komplexen Algorithmen zu analysieren. Dieses Dokument konzentriert sich auf die technischen Konzepte von Compute4PUNCH und Storage4PUNCH, die das Rückgrat dieser föderierten Infrastruktur bilden.
2. Föderierte heterogene Recheninfrastruktur – Compute4PUNCH
Compute4PUNCH adressiert die Herausforderung, eine breite Palette von in-kind beigesteuerten High-Throughput-Compute- (HTC), High-Performance-Compute- (HPC) und Cloud-Ressourcen, die über Deutschland verteilt sind, effektiv zu nutzen. Diese Ressourcen unterscheiden sich in Architektur, Betriebssystemen, Software-Stacks und Authentifizierungsmechanismen.
2.1. Kernarchitektur & Overlay-System
Der Grundstein von Compute4PUNCH ist die Schaffung eines föderierten Overlay-Batch-Systems auf Basis von HTCondor. Die zentrale Innovation ist die Verwendung des COBalD/TARDIS Resource Meta-Schedulers. TARDIS (TARDIS Acts as a Resource Dispatcher for In-place Scheduling) integriert externe, heterogene Ressourcen dynamisch und transparent in den HTCondor-Pool. Es fungiert als ein "Pilot"-System, das Platzhalter-Jobs an externe Cluster (wie Slurm-basierte HPC-Systeme) sendet, die dann tatsächliche Benutzer-Jobs aus der zentralen HTCondor-Warteschlange abrufen und ausführen. Dieser Ansatz minimiert den Eingriff in die bestehenden Betriebsumgebungen der Ressourcenanbieter, eine kritische Voraussetzung für die Akzeptanz.
Die Ressourcen-Zuordnungs- und Scheduling-Logik kann abstrakt durch eine Optimierungsfunktion dargestellt werden. Sei $R = \{r_1, r_2, ..., r_n\}$ die Menge der verfügbaren heterogenen Ressourcen, jeweils mit Attributen wie Architektur $arch(r_i)$, verfügbare Kerne $c(r_i)$, Arbeitsspeicher $m(r_i)$ und Wartezeit in der Warteschlange $w(r_i)$. Sei $J = \{j_1, j_2, ..., j_m\}$ die Menge der Benutzer-Jobs mit Anforderungen $req(j_k)$. Das Ziel des Meta-Schedulers ist es, eine Abbildung $M: J \rightarrow R$ zu finden, die eine Zielfunktion $F$ maximiert, oft eine gewichtete Summe aus Effizienz und Fairness:
$F(M) = \alpha \cdot \sum_{j_k} U(j_k, M(j_k)) - \beta \cdot \sum_{r_i} L(r_i, M^{-1}(r_i))$
wobei $U$ eine Nutzenfunktion ist, die misst, wie gut eine Ressource die Anforderungen eines Jobs erfüllt (unter Berücksichtigung der Softwareumgebungskompatibilität via CVMFS), und $L$ eine Lastfunktion ist, die die Überbuchung einer einzelnen Ressource bestraft. COBalD/TARDIS löst dieses dynamische, online Scheduling-Problem heuristisch.
2.2. Zugang & Softwareumgebung
Der Benutzerzugang wird durch eine token-basierte Authentifizierungs- und Autorisierungsinfrastruktur (AAI) standardisiert. Primäre Zugangspunkte sind traditionelle Login-Knoten und ein JupyterHub-Dienst, der eine vertraute webbasierte Oberfläche für interaktive Analysen und Prototyping bietet.
Um verschiedene Software-Abhängigkeiten zu handhaben, nutzt die Infrastruktur Container-Technologien (z.B. Docker, Singularity/Apptainer) und das CERN Virtual Machine File System (CVMFS). CVMFS liefert einen skalierbaren, schreibgeschützten und global verteilten Namensraum für Softwareinstallationen. Community-spezifische Software-Stacks werden in CVMFS-Repositories veröffentlicht, wodurch sichergestellt wird, dass jeder Rechenknoten, unabhängig von seinem physischen Standort, die erforderliche Softwareumgebung sofort und konsistent abrufen kann, was lokale Installationsaufwände eliminiert.
3. Föderierte Speicherinfrastruktur – Storage4PUNCH
Storage4PUNCH konzentriert sich auf die Föderierung von von den Communities bereitgestellten Speichersystemen, die überwiegend auf dCache oder XRootD Technologien basieren, beide in der Hochenergiephysik (HEP) etabliert.
3.1. Föderierungs- & Caching-Strategien
Die Föderierung schafft einen einheitlichen Namensraum, der es Benutzern ermöglicht, auf Daten über mehrere institutionelle Speicherelemente hinweg zuzugreifen, als wären sie ein einziges System. Technologien wie XRootDs Föderierungsprotokoll und dCache Frontend-Pooling werden eingesetzt, um dies zu erreichen. Das System führt eine intelligente Datenlokalisierung und -weiterleitung durch.
Eine kritische Komponente, die evaluiert wird, ist Caching. Eine globale oder regionale Cache-Schicht kann die Latenz und die Belastung des Weitverkehrsnetzes für häufig abgerufene Datensätze erheblich reduzieren. Die Trefferrate $H$ eines Caches der Größe $S$ für ein Datenzugriffsmuster kann modelliert werden. Wenn die Wahrscheinlichkeit, auf Datenelement $d_i$ zuzugreifen, einer Zipf-ähnlichen Verteilung $P(i) \sim 1 / i^{\alpha}$ folgt, ist die erwartete Trefferrate für einen LRU-Cache ungefähr:
$H(S) \approx \sum_{i=1}^{S} P(i)$
wobei $\alpha$ der Schiefeparameter ist. Für wissenschaftliche Workflows mit hoher Datenwiederverwendung (häufig in Analyseketten) können selbst mäßig große Caches eine hohe $H$ erzielen, was ihren Einsatz rechtfertigt. Das Projekt evaluiert auch Lösungen für die Metadatenverwaltung für eine tiefere Integration, mit dem Ziel, nicht nur Dateizugriff, sondern auch Datenentdeckungsfähigkeiten über die Föderierung hinweg bereitzustellen.
4. Technische Details & Mathematisches Rahmenwerk
Die Leistung der Föderierung hängt von einer effizienten Ressourcenermittlung und -planung ab. Der Systemzustand kann als Graph $G=(V,E)$ modelliert werden, wobei Knoten $V$ Ressourcen (Rechenknoten, Speicherendpunkte) und Kanten $E$ Netzwerkverbindungen mit Bandbreite $bw(e)$ und Latenz $lat(e)$ darstellen. Ein Workflow $W$ ist ein gerichteter azyklischer Graph (DAG) von Aufgaben $T$ mit Datenabhängigkeiten $D$.
Das Scheduling-Problem lautet: Platziere jede Aufgabe $t \in T$ auf einer Rechenressource $r_c \in V_c$ und leite ihre benötigten Eingabedaten von Speicherressourcen $r_s \in V_s$ so weiter, dass die Gesamtbearbeitungszeit (Workflow-Abschlusszeit) minimiert wird, unter den Nebenbedingungen:
$\text{minimiere } \max_{t \in T} (ft(t))$
unter den Nebenbedingungen:
$\forall r \in V_c, \sum_{t platziert\ auf\ r} c(t) \leq C(r)$ (CPU-Kapazität)
$\forall d \in D, \text{transfer\_time}(d) = \frac{size(d)}{\min\_bw(path)} + \sum_{e \in path} lat(e)$
Wobei $ft(t)$ die Endzeit der Aufgabe $t$, $c(t)$ ihre CPU-Anforderung und $C(r)$ die Kapazität der Ressource $r$ ist. Das föderierte System verwendet heuristische Algorithmen innerhalb von HTCondor und COBalD/TARDIS, um Lösungen für dieses NP-schwere Problem in Echtzeit anzunähern.
5. Experimentelle Ergebnisse & Prototypenleistung
Das Papier berichtet über erste Erfahrungen mit betriebsfähigen Prototypen. Während spezifische quantitative Benchmarks im bereitgestellten Auszug nicht detailliert beschrieben werden, impliziert der Text die erfolgreiche Ausführung wissenschaftlicher Anwendungen auf der föderierten Infrastruktur.
Diagrammbeschreibung (Abgeleitete Leistungsmetriken): Ein hypothetisches Leistungsdiagramm würde wahrscheinlich zwei Schlüsselmetriken über die Zeit zeigen: 1) Aggregierte Ressourcennutzung über den föderierten Pool hinweg, die demonstriert, wie das Overlay-System Kapazitätslücken zwischen verschiedenen beitragenden Zentren effektiv füllt. 2) Job-Durchlaufzeit im Vergleich eines föderierten Szenarios mit isolierter Ressourcennutzung. Das föderierte System würde eine niedrigere durchschnittliche Durchlaufzeit und Varianz zeigen, insbesondere für Jobs mit flexiblen Ressourcenanforderungen, da sie zu Ressourcen mit der kürzesten Warteschlange geleitet werden können. Die Integration von HPC-Ressourcen via TARDIS würde eine eigene Kurve zeigen, die anfänglich Latenz durch den Pilot-Job-Mechanismus hinzufügt, aber Zugang zu ansonsten nicht verfügbaren Hochkernzahl-Knoten für geeignete Workloads bietet.
Die Nutzung von CVMFS wird als erfolgreich bei der Bereitstellung einheitlicher Softwareumgebungen gemeldet, ein kritischer Erfolgsfaktor für die Benutzerakzeptanz. Die token-basierte AAI wurde implementiert und bietet die notwendige Grundlage für sicheren, multi-institutionellen Zugang.
6. Analyse-Framework: Eine konzeptionelle Fallstudie
Fall: Multi-Messenger-Astrophysik-Analyse. Ein Astroteilchenphysiker muss Daten eines von Fermi-LAT und IceCube detektierten Gammastrahlenausbruchs (GRB) analysieren und mit optischen Folgebeobachtungen von ASAS-SN korrelieren. Der Workflow umfasst: A) Verarbeitung von Terabytes an Rohphotonendaten (Fermi) auf einer für hohen I/O optimierten HTC-Farm. B) Ausführung von Monte-Carlo-Simulationen für Neutrino-Ereignisrekonstruktion (IceCube) auf einem HPC-Cluster mit vielen Kernen. C) Bildanalyse optischer Daten unter Verwendung von GPU-Knoten.
Föderierte Ausführung via Compute4PUNCH/Storage4PUNCH:
1. Der Benutzer reicht eine einzige, hochlevelige Workflow-Beschreibung (z.B. unter Verwendung der Common Workflow Language - CWL) über JupyterHub ein.
2. Das AAI-Token authentifiziert den Benutzer über alle Systeme hinweg.
3. Das HTCondor-Overlay, gesteuert von COBalD/TARDIS, analysiert den Workflow-DAG:
- Aufgabe A wird zugewiesen und an dCache-gestützte, speichernah gelegene HTC-Worker am DESY gesendet.
- Die Anforderung von Aufgabe B nach 10.000 CPU-Stunden veranlasst TARDIS, Slots auf einem Slurm-basierten HPC-Cluster am KIT bereitzustellen.
- Aufgabe C wird an eine GPU-Partition an der Universität Bonn gesendet.
4. Alle Aufgaben laden den identischen Analysesoftware-Stack (Python, spezifische Wissenschaftsbibliotheken) aus dem PUNCH-CVMFS-Repository.
5. Zwischendaten werden über den föderierten Storage4PUNCH-Namensraum ausgetauscht (z.B. unter Verwendung von XRootD), wobei häufig abgerufene Kalibrierungsdateien von einem regionalen Cache bereitgestellt werden.
6. Endergebnisse werden aggregiert und an den Benutzer zurückgegeben.
Dieser Fall demonstriert den Mehrwert: Der Physiker interagiert mit einer einzigen, logischen Infrastruktur, anstatt separate Logins, Softwareinstallationen und Datentransfers über drei verschiedene Systeme hinweg zu verwalten.
7. Kernaussage & Analystenperspektive
Kernaussage: PUNCH4NFDI baut nicht noch einen weiteren monolithischen Supercomputer; es entwickelt eine Föderierungsschicht – ein "Meta-Betriebssystem" für nationales, heterogenes Forschungsrechnen. Die eigentliche Innovation ist die pragmatische Orchestrierung bestehender, politisch abgeschotteter Ressourcen zu einem kohärenten Nutzen, wobei minimaler Eingriff über technologische Reinheit priorisiert wird. Dies ist weniger wie Googles Borg und mehr wie ein ausgeklügeltes EU-weites Flugverkehrskontrollsystem für Rechenjobs.
Logischer Ablauf: Die Logik ist elegant rekursiv. Begonnen wird mit der nicht verhandelbaren Randbedingung: Störe nicht den bestehenden Community-Betrieb. Dies erzwingt eine pull-basierte, Overlay-Architektur (HTCondor + TARDIS) anstelle eines push-basierten zentralisierten Schedulers. Dieses Overlay wiederum erfordert einen universellen Softwarebereitstellungsmechanismus (CVMFS/Container) und eine einheitliche Identitätsschicht (Token-AAI). Die Speicherföderierung folgt einem parallelen Pfad und nutzt erprobte HEP-Tools (dCache/XRootD). Der gesamte Ablauf ist ein Meisterwerk im randbedingungsgetriebenen Design, bei dem jede technische Wahl eine direkte Konsequenz der sozio-politischen Realität der multi-institutionellen Zusammenarbeit ist.
Stärken & Schwächen:
Stärken: Die Architektur ist brillant föderierbar. Sie skaliert die Governance horizontal durch Design und senkt die Eintrittsbarrieren für neue Ressourcenanbieter. Die Nutzung von HTCondor und CVMFS greift auf jahrzehntelanges Community-Vertrauen und Betriebserfahrung aus den LHC-Kollaborationen zurück und reduziert so das technische Risiko. Der Fokus auf "in-kind"-Ressourcen ist finanziell nachhaltig und verwandelt ein Fragmentierungsproblem in einen Diversitätsvorteil.
Schwächen: Der Elefant im Raum ist der Leistungs-Overhead. Das Doppel-Scheduling (Meta-Scheduler + lokales Batch-System) und das Pilot-Job-Modell fügen unweigerlich Latenz hinzu, was es für feinkörnige, eng gekoppelte MPI-Jobs ungeeignet macht – eine bedeutende Einschränkung für reine HPC-Workloads. Die Abhängigkeit von CVMFS, obwohl robust, schafft einen Single Point of Failure für die Softwarebereitstellung und könnte bei hochproprietären oder lizenzierten Codes an Grenzen stoßen. Darüber hinaus erfordert echte Interoperabilität, wie in den FAIR-Datenprinzipien festgestellt, reichhaltige Metadaten; die aktuelle Storage4PUNCH-Beschreibung scheint stark auf Byte-Level-Zugriff fokussiert, nicht auf semantische Entdeckung.
Umsetzbare Erkenntnisse:
1. Für das PUNCH-Team: Verstärkt die Leistungscharakterisierung. Veröffentlicht transparente Benchmarks, die den föderierten mit dem nativen Job-Durchsatz und der Latenz für kanonische Workflows vergleichen. Diese Daten sind entscheidend, um skeptische HPC-Zentrumsmanager und -nutzer zu überzeugen. Entwickelt proaktiv ein "Tier-1"-Support-Modell für die Föderierungsschicht selbst; ihre Komplexität wird zu einer kritischen Abhängigkeit.
2. Für andere Konsortien (z.B. in der Bioinformatik oder Klimawissenschaft): Kopiert nicht nur den Tech-Stack. Kopiert das Governance-Modell, das ihn ermöglicht hat. Die zentrale Lehre ist die "in-kind contribution"-Vereinbarung, die institutionelle Anreize in Einklang bringt. Beginnt mit der Föderierung von Authentifizierung und Softwareverteilung, wie PUNCH es tat; diese sind grundlegend.
3. Für Förderorganisationen (DFG, EU): Dieses Modell sollte die Blaupause für zukünftige nationale Forschungsinfrastrukturausschreibungen sein. Fördert den "Kleber" (Koordination, Core-DevOps für die Föderierungsschicht) und lasst die Institutionen die "Bausteine" (tatsächliche Rechen-/Speicherkapazität) finanzieren. Dies nutzt bestehende Kapitalinvestitionen effektiver als der Bau neuer, zentralisierter Einrichtungen, ein Prinzip, das auch in der strategischen Vision des European Open Science Cloud (EOSC) widerhallt.
Zusammenfassend repräsentieren Compute4PUNCH und Storage4PUNCH ein ausgereiftes, pragmatisches und hoch replizierbares Modell für die großskalige Wissenschaftsinfrastruktur des 21. Jahrhunderts. Es tauscht etwas theoretische Leistung gegen immense Gewinne in Zugänglichkeit, Resilienz und politischer Machbarkeit ein. Sein Erfolg wird nicht in FLOPS gemessen, sondern in der Anzahl der Doktorand:innen, die ihre Analyse abschließen können, ohne Experten-Systemadministratoren für fünf verschiedene Cluster zu werden.
8. Zukünftige Anwendungen & Entwicklungsfahrplan
Die PUNCH4NFDI-Infrastruktur legt eine Grundlage für mehrere zukünftige Weiterentwicklungen:
- Integration von Machine-Learning-Workflows: Die Föderierung kann erweitert werden, um spezialisierte KI/ML-Beschleuniger (z.B. NVIDIA DGX Pods, Google TPUs) als Ressourcentyp zu unterstützen. Frameworks wie Kubeflow könnten neben HTCondor integriert werden, wobei TARDIS hybride Job-Platzierungen über traditionelle HTC- und ML-fokussierte Ressourcen hinweg verwaltet.
- Proaktive Datenplatzierung & Workflow-bewusstes Scheduling: Über Caching hinaus könnte das System prädiktives Data Staging implementieren. Durch Analyse der von Benutzern eingereichten Workflow-DAGs könnte es benötigte Datensätze von entfernten Storage4PUNCH-Endpunkten zu lokalen Caches in der Nähe der geplanten Rechenressourcen vorab laden, bevor die Job-Ausführung beginnt, und so die Datentransferlatenz effektiv verbergen. Dies erfordert eine engere Integration zwischen dem Compute-Meta-Scheduler und dem Namensraum sowie den Monitoring-Daten der Speicherföderierung.
- Ausweitung auf Edge Computing: Für Bereiche wie Radioastronomie oder Neutrinophysik, in denen Sensoren riesige Datenströme erzeugen, könnte das Föderierungsmodell Edge-Computing-Standorte einbeziehen. Leichtgewichtige TARDIS-Agenten könnten an Observatorien laufen und Vorverarbeitungsaufgaben aus der zentralen Warteschlange abrufen, um Daten vor Ort zu filtern und zu reduzieren, bevor nur relevante Ereignisse an den zentralen Speicher übertragen werden.
- Green Computing & CO₂-bewusstes Scheduling: Der Meta-Scheduler könnte mit Daten zur CO₂-Intensität der Stromnetze in ganz Deutschland erweitert werden. Er könnte dann Jobs bevorzugt zu Rechenzentren in Regionen mit hohem Anteil erneuerbarer Energien (z.B. Windkraft im Norden) zu Zeiten der Spitzenproduktion leiten und so den CO₂-Fußabdruck großskaliger Berechnungen minimieren – eine aufkommende Priorität für Forschungsinfrastrukturen, wie sie von der Linux Foundation's Carbon Call initiative hervorgehoben wird.
- Inter-Föderierung mit internationalen Partnern: Der logische nächste Schritt ist die Verbindung der deutschen PUNCH-Föderierung mit ähnlichen Infrastrukturen im Ausland, wie dem Worldwide LHC Computing Grid (WLCG), dem Open Science Grid (OSG) oder der European Open Science Cloud (EOSC). Dies würde eine globale, multidisziplinäre Forschungsinfrastruktur schaffen, würde jedoch erhebliche Herausforderungen in Bezug auf Politikabstimmung, Sicherheit und Abrechnung aufwerfen.
9. Referenzen
- PUNCH4NFDI-Konsortium. "PUNCH4NFDI - Particles, Universe, NuClei and Hadrons for the NFDI." White Paper, 2021.
- Thain, D., Tannenbaum, T., & Livny, M. "Distributed computing in practice: the Condor experience." Concurrency - Practice and Experience, 17(2-4), 323-356, 2005. https://doi.org/10.1002/cpe.938
- Blomer, J., et al. "CernVM-FS: delivering scientific software to globally distributed computing resources." International Journal of High Performance Computing Applications, 28(2), 158-174, 2014. https://doi.org/10.1177/1094342013509700
- Giffels, M., et al. "COBalD/TARDIS – Dynamic, Pilot-based Resource Provisioning for a Federated HTCondor Pool." In Proceedings of CHEP 2018, 2018.
- Wilkinson, M. D., et al. "The FAIR Guiding Principles for scientific data management and stewardship." Scientific Data, 3:160018, 2016. https://doi.org/10.1038/sdata.2016.18
- European Commission. "European Open Science Cloud (EOSC) Strategic Implementation Roadmap." 2018.
- Linux Foundation. "Carbon Call: A Global Initiative for Reliable Carbon Accounting." 2022. https://www.linuxfoundation.org/research/carbon-call
- Zhu, J.-Y., Park, T., Isola, P., & Efros, A. A. "Unpaired Image-to-Image Translation using Cycle-Consistent Adversarial Networks." In Proceedings of the IEEE International Conference on Computer Vision (ICCV), 2017. (Zitiert als Beispiel einer komplexen Rechenlast, die von föderiertem, heterogenem Ressourcenzugang profitieren könnte).