1. Einleitung
Der 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. Eingebettet in die breitere 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 Rechen- und Speicherressourcen der beteiligten Einrichtungen bieten und so gemeinsame Herausforderungen durch exponentiell wachsende Datenmengen und rechenintensive Analysealgorithmen adressieren. Dieses Dokument konzentriert sich auf die Architekturkonzepte – Compute4PUNCH und Storage4PUNCH –, die entwickelt wurden, um Deutschlands heterogene Forschungsinfrastruktur zu föderieren.
2. Föderierte heterogene Recheninfrastruktur – Compute4PUNCH
Compute4PUNCH adressiert die Herausforderung, eine breite Palette von als Sachleistung beigesteuerten Ressourcen effektiv zu nutzen, darunter High-Throughput-Computing (HTC), High-Performance-Computing (HPC) und Cloud-Systeme, die über ganz Deutschland verteilt sind. Diese Ressourcen unterscheiden sich in Architektur, Betriebssystemen, Software-Stacks und Zugangsrichtlinien. Das zentrale Designprinzip ist die Schaffung eines einheitlichen Overlay-Systems mit minimalem Eingriff in bestehende, betriebsbereite Ressourcenanbieter.
2.1. Kernarchitektur & Integration
Die Föderierung basiert auf HTCondor als zentralem Batch-System-Overlay. Heterogene Ressourcen werden dynamisch mit dem COBalD/TARDIS-Ressourcen-Meta-Scheduler integriert. COBalD/TARDIS fungiert als intelligenter Broker, der Jobs basierend auf Ressourcenverfügbarkeit, Job-Anforderungen und Richtlinien zu geeigneten Backends (z.B. Slurm-, Kubernetes-Cluster) pilotiert. Dadurch entsteht aus physisch unterschiedlichen Systemen ein einziger, logischer Ressourcenpool.
2.2. Nutzerzugang & Softwareumgebung
Nutzerzugangspunkte werden über traditionelle Login-Knoten und einen JupyterHub-Dienst bereitgestellt. Eine tokenbasierte Authentifizierungs- und Autorisierungsinfrastruktur (AAI) standardisiert den Zugang. Die Komplexität der Softwareumgebung wird durch Container-Technologien (z.B. Docker, Singularity/Apptainer) und das CERN Virtual Machine File System (CVMFS) verwaltet, das skalierbare, schreibgeschützte Software-Distributionen global an Rechenknoten liefert.
3. Föderierte Speicherinfrastruktur – Storage4PUNCH
Storage4PUNCH zielt darauf ab, von der Community bereitgestellte Speichersysteme zu föderieren, die hauptsächlich auf den in der Hochenergiephysik (HEP) etablierten Technologien dCache und XRootD basieren. Die Föderierung nutzt gemeinsame Namensräume und Protokolle (wie xrootd, WebDAV), um eine einheitliche Datenzugriffsschicht zu präsentieren. Das Konzept bewertet auch die Integration von Caching-Lösungen und Metadatenverwaltungsdiensten, um die Datenlokalität und Auffindbarkeit innerhalb der Föderierung zu verbessern.
4. Technische Umsetzung & Komponenten
4.1. Authentifizierung & Autorisierung (AAI)
Eine tokenbasierte AAI (wahrscheinlich basierend auf OAuth 2.0/OpenID Connect Standards, ähnlich WLCG IAM oder INDIGO IAM) bietet ein Single-Sign-On-Erlebnis. Sie bildet Community-Identitäten auf lokale Ressourcenberechtigungen ab und abstrahiert so von heterogenen lokalen Authentifizierungssystemen (z.B. Kerberos, SSH-Schlüssel).
4.2. Ressourcen-Meta-Scheduling: COBalD/TARDIS
COBalD (der Koordinator) und TARDIS (das Transparent Adaptive Resource Dynamic Integration System) arbeiten Hand in Hand. COBalD trifft übergeordnete Scheduling-Entscheidungen, während TARDIS den Lebenszyklus von "Piloten" oder "Platzhalter-Jobs" auf Zielressourcen verwaltet. Diese Entkopplung ermöglicht eine flexible Durchsetzung von Richtlinien (z.B. Kosten, Fairness, Priorität) und eine dynamische Anpassung an schwankende Ressourcenzustände. Das Scheduling kann als Optimierungsproblem modelliert werden, das eine Kostenfunktion $C_{total} = \sum_{i}(w_i \cdot T_i) + \lambda \cdot R$ minimiert, wobei $T_i$ die Durchlaufzeit für Job $i$ ist, $w_i$ sein Prioritätsgewicht, $R$ die Ressourcennutzungskosten darstellt und $\lambda$ ein Ausgleichsparameter ist.
4.3. Daten- & Software-Schicht
CVMFS ist entscheidend für die Softwareverteilung. Es verwendet ein inhaltsadressierbares Speichermodell und aggressives Caching (mit Stratum 0/1 Servern und lokalen Squid-Caches), um Software-Repositories effizient bereitzustellen. Die Föderierung nutzt wahrscheinlich eine Hierarchie von CVMFS-Strata, mit einem zentralen PUNCH-Repository-Stratum 0 und institutionellen Stratum 1-Mirrors. Der Datenzugriff folgt einem ähnlichen föderierten Modell, wobei Speicherelemente (SEs) ihre Endpunkte in einem globalen Verzeichnis (wie Rucio oder einem einfachen REST-Dienst) veröffentlichen, sodass Clients Datenstandorte transparent auflösen können.
5. Prototyp-Status & Erste Erfahrungen
Das Dokument zeigt, dass Prototypen sowohl von Compute4PUNCH als auch von Storage4PUNCH betriebsbereit sind. Erste wissenschaftliche Anwendungen wurden ausgeführt und liefern wertvolles Feedback zu Leistung, Benutzerfreundlichkeit und Integrationsschwierigkeiten. Obwohl im Auszug keine spezifischen Benchmark-Zahlen angegeben sind, impliziert die erfolgreiche Ausführung, dass die grundlegende Funktionalität des Overlay-Batch-Systems, die AAI-Integration und die Softwarebereitstellung via CVMFS validiert wurden. Die Erfahrungen leiten Verfeinerungen in der Richtlinienkonfiguration, Fehlerbehandlung und Nutzerdokumentation.
6. Zentrale Erkenntnisse & Strategische Analyse
Kernerkenntnis: PUNCH4NFDI baut keinen neuen Supercomputer; es konstruiert ein "Föderierungsgewebe", das pragmatisch bestehende, fragmentierte Ressourcen zusammennäht. Dies ist ein strategischer Wechsel von monolithischer Infrastruktur hin zu aggreger, softwaredefinierter Ressourcenaggregation, der Trends im kommerziellen Cloud-Bereich spiegelt, aber auf die Beschränkungen und Kultur der öffentlich finanzierten Wissenschaft zugeschnitten ist.
Logischer Ablauf: Die Architektur folgt einer klaren, abhängigkeitsgetriebenen Logik: 1) Identität vereinheitlichen (AAI), um das "Wer"-Problem zu lösen, 2) Ressourcen abstrahieren (COBalD/TARDIS + HTCondor), um das "Wo"-Problem zu lösen, und 3) Umgebung entkoppeln (Container + CVMFS), um das "Womit"-Problem zu lösen. Diese geschichtete Abstraktion ist klassische Systemtechnik, erinnert an den Erfolg des Worldwide LHC Computing Grid (WLCG), aber angewendet auf eine diversere Ressourcenbasis.
Stärken & Schwächen: Die größte Stärke ist das nicht-disruptive Einführungsmodell. Durch die Nutzung von Overlay-Technologien und die Wahrung der Standortautonomie senkt es die Einstiegshürde für Ressourcenanbieter – ein entscheidender Erfolgsfaktor für Konsortien. Dies ist jedoch auch seine Achillesferse. Der Leistungs-Overhead des Meta-Schedulings und die inhärente Komplexität der Fehlersuche über heterogene, unabhängig verwaltete Systeme hinweg können erheblich sein. Das "Minimale Störung"-Mandat kann die Fähigkeit einschränken, fortschrittliche Funktionen wie tiefe Speicher-Rechen-Kopplung oder dynamische Netzwerkbereitstellung zu implementieren, was möglicherweise Effizienzgewinne begrenzt. Im Vergleich zu einem maßgeschneiderten, zentralisierten System wie Googles Borg oder einem Kubernetes-Cluster wird die Föderierung immer eine höhere Latenz und eine geringere Vorhersagbarkeit der Auslastung haben.
Umsetzbare Erkenntnisse: Für andere Konsortien, die diesen Weg erwägen: 1) Von Anfang an stark in Monitoring und Observability investieren. Tools wie Grafana/Prometheus für die Infrastruktur und APM (Application Performance Monitoring) für Nutzer-Jobs sind unverzichtbar für das Management der Komplexität. 2) Auf einen engen Satz von Container-Basis-Images standardisieren, um den CVMFS-Wartungsaufwand zu reduzieren. 3) Ein klares, gestuftes Support-Modell entwickeln, das föderierungsweite Probleme von lokalen Standortproblemen unterscheidet. Die eigentliche Bewährungsprobe wird nicht die technische Machbarkeit sein – die HEP-Community hat diese bewiesen –, sondern die operative Nachhaltigkeit und Nutzerzufriedenheit im großen Maßstab.
7. Technische Vertiefung
Mathematisches Modell für Ressourcen-Scheduling: Das COBalD/TARDIS-System kann als Lösung eines eingeschränkten Optimierungsproblems konzeptualisiert werden. Sei $J$ die Menge der Jobs, $R$ die Menge der Ressourcen und $S$ die Menge der Ressourcenzustände (z.B. Leerlauf, beschäftigt, abgeschaltet). Der Scheduler zielt darauf ab, eine Nutzenfunktion $U$ zu maximieren, die Job-Priorität $p_j$, Ressourceneffizienz $e_{j,r}$ und Kosten $c_r$ berücksichtigt: $$\max \sum_{j \in J} \sum_{r \in R} x_{j,r} \cdot U(p_j, e_{j,r}, c_r)$$ unter den Nebenbedingungen: $$\sum_{j} x_{j,r} \leq C_r \quad \forall r \in R \quad \text{(Ressourcenkapazität)}$$ $$\sum_{r} x_{j,r} \leq 1 \quad \forall j \in J \quad \text{(Jobzuweisung)}$$ $$x_{j,r} \in \{0,1\} \quad \text{(Binäre Entscheidungsvariable)}$$ wobei $x_{j,r}=1$, wenn Job $j$ der Ressource $r$ zugewiesen ist. TARDIS verwaltet die Machbarkeit von Zuweisungen dynamisch basierend auf dem Echtzeitzustand $S$.
Experimentelle Ergebnisse & Diagrammbeschreibung: Während der bereitgestellte PDF-Auszug keine spezifischen Leistungsdiagramme enthält, würde eine typische Evaluierung Diagramme umfassen, die vergleichen:
1. Job-Durchsatz über die Zeit: Ein Liniendiagramm, das die Anzahl der pro Stunde abgeschlossenen Jobs im föderierten Pool gegenüber einzelnen Ressourcen-Clustern zeigt und so den Aggregationsvorteil demonstriert.
2. Ressourcennutzungs-Heatmap: Eine Rastervisualisierung, die den Prozentsatz der genutzten CPUs/GPUs über verschiedene Ressourcenanbieter (KIT, DESY, Bielefeld, etc.) über eine Woche hinweg zeigt und die Effektivität des Lastausgleichs hervorhebt.
3. Job-Startlatenz-CDF: Ein kumulatives Verteilungsfunktions-Diagramm, das die Zeit von der Job-Einreichung bis zum Ausführungsstart im föderierten System gegenüber der direkten Einreichung in ein lokales Batch-System vergleicht und den Meta-Scheduling-Overhead offenbart.
4. Datenzugriffsleistung: Ein Balkendiagramm, das Lese-/Schreibgeschwindigkeiten für lokal, von einem föderierten Speicherelement innerhalb derselben Region und von einem entfernten föderierten Element abgerufene Daten vergleicht und die Auswirkungen von Caching und Netzwerk veranschaulicht.
8. Analyse-Rahmenwerk & Konzeptmodell
Fallstudie: Föderierte Analyse astronomischer Survey-Daten
Szenario: Eine Forschungsgruppe an der Thüringer Landessternwarte Tautenburg muss 1 PB an Bilddaten des Sloan Digital Sky Survey (SDSS) verarbeiten, um Galaxienhaufen zu identifizieren – eine rechenintensive Aufgabe, die ~100.000 CPU-Stunden erfordert.
Prozess via Compute4PUNCH/Storage4PUNCH:
1. Authentifizierung: Der Forscher meldet sich mit seinen institutionellen Zugangsdaten (über die tokenbasierte AAI) am PUNCH JupyterHub an.
2. Softwareumgebung: Sein Jupyter-Notebook-Kernel läuft von einem Container-Image auf CVMFS, das alle notwendigen Astronomie-Pakete (Astropy, SExtractor, etc.) enthält.
3. Job-Definition & Einreichung: Er definiert einen Parameter-Sweep-Job im Notebook. Das Notebook verwendet eine PUNCH-Client-Bibliothek, um diese als HTCondor DAG (Directed Acyclic Graph) an den föderierten Pool zu übermitteln.
4. Ressourcen-Matching & Ausführung: COBalD/TARDIS bewertet die Job-Anforderungen (CPU, Speicher, ggf. GPU) und pilotiert sie zu verfügbaren Slots z.B. in HTC-Pools am KIT, HPC-Warteschlangen der Universität Bielefeld und Cloud-Knoten am DESY. Die Jobs lesen Eingabedaten über den föderierten XRootD-Namensraum vom nächstgelegenen Speicherort, möglicherweise unter Nutzung eines Caches.
5. Ergebnisaggregation: Ausgabedateien werden zurück in den föderierten Speicher geschrieben. Der Forscher überwacht den Fortschritt über ein einheitliches Web-Dashboard und aggregiert schließlich die Ergebnisse in seinem Notebook zur Analyse.
Dieser Fall demonstriert die nahtlose Integration von Identität, Rechenleistung, Speicher und Softwaremanagement.
9. Zukünftige Anwendungen & Entwicklungs-Roadmap
Die PUNCH4NFDI-Infrastruktur legt den Grundstein für mehrere fortgeschrittene Anwendungen:
1. Föderiertes Maschinelles Lernen (Training): Der heterogene Ressourcenpool, einschließlich potenzieller GPU-Cluster, könnte verteilte ML-Trainings-Frameworks wie PyTorch oder TensorFlow über Institutionsgrenzen hinweg unterstützen und so Bedürfnisse nach datenschutzerhaltendem Training adressieren, bei dem Daten nicht zentralisiert werden können.
2. Interaktive Analyse & Visualisierung: Erweiterung des JupyterHub-Dienstes um skalierbare, backend-gestützte interaktive Visualisierungstools (z.B. Jupyter-Widgets, die mit Dask-Clustern in der Föderierung verbunden sind) für die Exploration großer Datensätze.
3. Integration externer Clouds & HPC-Zentren: Erweiterung des Föderierungsmodells, um kommerzielle Cloud-Guthaben (z.B. AWS, GCP) oder nationale Supercomputing-Zentren (z.B. JUWELS am JSC) über eine gemeinsame Abrechnungs-/Kontenschicht einzubinden und so eine echte Hybrid-Cloud für die Wissenschaft zu schaffen.
4. Metadaten- und Data-Lake-Integration: Über die einfache Dateiföderierung hinaus zu einer integrierten Data-Lake-Architektur, bei der die Speicherschicht mit einem einheitlichen Metadatenkatalog (z.B. basierend auf Rucio oder iRODS) gekoppelt ist, um Datenentdeckung und Provenienzverfolgung über Communities hinweg zu ermöglichen.
5. Workflow-as-a-Service: Bereitstellung höherwertiger Plattformdienste wie REANA (Reproducible Analysis Platform) oder Apache Airflow auf Basis der föderierten Infrastruktur, die es Wissenschaftlern ermöglichen, komplexe, reproduzierbare Analyse-Pipelines zu definieren und auszuführen, ohne die zugrundeliegende Infrastruktur verwalten zu müssen.
Die Entwicklungs-Roadmap wird sich voraussichtlich auf die Stabilisierung des Produktivdienstes, die Erweiterung des Ressourcenpools, die Integration ausgefeilterer Datenmanagement-Tools und die Entwicklung benutzerfreundlicher APIs und SDKs konzentrieren, um die Einstiegshürde für nicht-expert:innen zu senken.
10. Referenzen
- PUNCH4NFDI-Konsortium. (2024). PUNCH4NFDI White Paper. [Internes Konsortialdokument].
- 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
- dCache Collaboration. (2023). dCache: A distributed storage data caching system. Abgerufen von https://www.dcache.org/
- XRootD Collaboration. (2023). XRootD: High performance, scalable fault tolerant access to data. Abgerufen von 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