Compute4PUNCH & Storage4PUNCH: Föderierte Infrastruktur für Teilchen-, Astro- und Kernphysik

1. Einleitung

Particles, Universe, NuClei and Hadrons for the National Research Data Infrastructure (PUNCH4NFDI) ist ein von der DFG (Deutsche Forschungsgemeinschaft) gefördertes deutsches Konsortium. Es repräsentiert etwa 9.000 Wissenschaftler:innen aus den Bereichen Teilchenphysik, Astrophysik, Astroteilchenphysik, Hadronen- und Kernphysik. Das primäre Ziel des Konsortiums ist der Aufbau einer föderierten und FAIR-konformen (Findable, Accessible, Interoperable, Reusable) Wissenschaftsdatenplattform. Diese Plattform soll einen einheitlichen Zugang zu den vielfältigen und heterogenen Rechen- und Speicherressourcen bieten, die von den Mitgliedsinstitutionen in ganz Deutschland bereitgestellt werden, und so die gemeinsame Herausforderung bewältigen, exponentiell wachsende Datenmengen mit komplexen Algorithmen zu analysieren.

2. Föderierte heterogene Recheninfrastruktur – Compute4PUNCH

Das Compute4PUNCH-Konzept adressiert die Herausforderung, einen nahtlosen Zugang zu einer breiten Palette von als Naturalleistung bereitgestellten High-Throughput-Computing (HTC)-, High-Performance-Computing (HPC)- und Cloud-Ressourcen zu ermöglichen. Diese Ressourcen unterscheiden sich in Architektur, Betriebssystem, Software und Authentifizierung und sind bereits betriebsbereit und geteilt, was einen nicht-invasiven Integrationsansatz erfordert.

3. Föderierte Speicherinfrastruktur – Storage4PUNCH

Parallel zur Recheninfrastruktur föderiert das Storage4PUNCH-Konzept von der Gemeinschaft bereitgestellte Speichersysteme, die hauptsächlich auf den in der Hochenergiephysik (HEP) etablierten Technologien dCache und XRootD basieren.

4. Technische Details & Mathematisches Framework

Die zentrale Scheduling-Herausforderung kann als Ressourcenoptimierungsproblem modelliert werden. Sei $R = \{r_1, r_2, ..., r_n\}$ die Menge der heterogenen Ressourcen, jeweils mit Attributen wie Architektur, verfügbare Kerne $c_i$, Arbeitsspeicher $m_i$ und Wartezeit in der Warteschlange $w_i$. Sei $J = \{j_1, j_2, ..., j_m\}$ die Menge der Jobs mit Anforderungen $\hat{c}_j, \hat{m}_j$.

Der Meta-Scheduler (COBalD/TARDIS) zielt darauf ab, den Gesamtnutzen oder Durchsatz zu maximieren. Eine vereinfachte Zielfunktion für die Job-Platzierung könnte sein, die Makespan zu minimieren oder die Ressourcennutzung zu maximieren, unter Berücksichtigung der Nebenbedingungen:

$\text{Minimiere } \max_{r \in R} (\text{completionTime}(r))$

unter den Bedingungen: $\sum_{j \in J_r} \hat{c}_j \leq c_r \quad \text{und} \quad \sum_{j \in J_r} \hat{m}_j \leq m_r \quad \forall r \in R$

wobei $J_r$ die Menge der der Ressource $r$ zugewiesenen Jobs ist. Die dynamische Natur wird von TARDIS behandelt, das HTCondor dazu bringt, entfernte Ressourcen als Teil seines lokalen Pools zu sehen.

5. Experimentelle Ergebnisse & Prototyp-Status

Das Papier berichtet über den aktuellen Status und erste Erfahrungen mit wissenschaftlichen Anwendungen auf verfügbaren Prototypen. Während spezifische Benchmark-Zahlen im vorliegenden Auszug nicht detailliert beschrieben werden, wird die erfolgreiche Ausführung realer wissenschaftlicher Workloads impliziert. Es wurde gezeigt, dass die Integration von HTCondor mit COBalD/TARDIS Ressourcen aus verschiedenen administrativen Domänen dynamisch integrieren kann. Der initiale Benutzerzugang über JupyterHub und tokenbasierte AAI wurde getestet und liefert einen Proof-of-Concept für den einheitlichen Einstiegspunkt. Die Nutzung von CVMFS für die Bereitstellung notwendiger Softwareumgebungen über die föderierte Infrastruktur hinweg wurde validiert.

6. Analyse-Framework: Eine konzeptionelle Fallstudie

Betrachten Sie eine Multi-Messenger-Astrophysik-Analyse, die nach Neutrinogegenstücken zu Gammastrahlenausbrüchen sucht. Der Workflow umfasst:

1. Datendiscovery: Ein Forscher nutzt den föderierten Metadatenkatalog (in Storage4PUNCH in Evaluierung), um relevante Neutrino-Ereignisdaten von IceCube und Gammastrahlendaten von Fermi-LAT zu lokalisieren, die in dCache-Instanzen bei DESY und Bielefeld gespeichert sind.
2. Workflow-Einreichung: Über die JupyterHub-Oberfläche definiert der Forscher eine Parameter-Sweep-Analyse. Die Job-Anforderungen (Software: Python, IceCube-Software-Suite über CVMFS; Rechenleistung: 1000 CPU-Stunden) werden spezifiziert.
3. Orchestrierung: Das HTCondor-Overlay, gesteuert von COBalD/TARDIS, matcht und verteilt dynamisch hunderte Jobs auf verfügbare Slots über HPC-Ressourcen des KIT, HTC-Ressourcen in Bonn und Cloud-Ressourcen. Die Token-AAI handhabt die Authentifizierung nahtlos.
4. Ausführung & Datenzugriff: Jobs laden Software von CVMFS, lesen Eingabedaten direkt über XRootD-Doors aus dem föderierten Speicher und schreiben Zwischenergebnisse in einen temporären Speicherbereich.
5. Ergebnisaggregation: Endergebnisse werden aggregiert und zurück in ein persistentes, FAIR-konformes Repository innerhalb der Storage4PUNCH-Föderation geschrieben.

Diese Fallstudie demonstriert den Mehrwert: Ein Wissenschaftler interagiert mit einem einzigen, kohärenten System, um national verteilte, heterogene Ressourcen zu nutzen, ohne die zugrundeliegende Komplexität verwalten zu müssen.

7. Anwendungsausblick & Zukünftige Richtungen

Die kombinierte Compute4PUNCH- und Storage4PUNCH-Infrastruktur hat erhebliches Potenzial über die initialen PUNCH-Gemeinschaften hinaus:

• Domänenübergreifende Föderation: Das Modell könnte auf andere NFDI-Konsortien oder Initiativen wie die European Open Science Cloud (EOSC) ausgeweitet werden, um eine echte paneuropäische föderierte Infrastruktur zu schaffen.
• Integration von Edge Computing: Für Bereiche wie Radioastronomie oder Detektorüberwachung könnte die Integration von Edge-Computing-Ressourcen in der Nähe von Sensoren ein logischer nächster Schritt sein.
• Unterstützung für KI/ML-Workloads: Erweiterung des Schedulers zur nativen Unterstützung von GPU/Accelerator-Ressourcen und Frameworks wie Kubernetes für großskalige ML-Trainingsjobs.
• Fortschrittliches Datenmanagement: Tiefere Integration von intelligentem Datenplacement, Lifecycle-Management und aktiven Metadatenkatalogen zur Optimierung datenintensiver Workflows.
• Quantencomputing-Hybrid: Mit der Reife des Quantencomputings könnte die Föderation Quantenprozessoren als spezialisierte Ressourcen für bestimmte Algorithmusschritte integrieren.

Der Erfolg dieser Föderation wird von nachhaltiger Finanzierung, betrieblicher Robustheit und anhaltender Akzeptanz des föderierten Modells gegenüber lokaler Optimierung abhängen.

8. Referenzen

1. PUNCH4NFDI-Konsortium. "PUNCH4NFDI – Particles, Universe, NuClei and Hadrons for the NFDI." White Paper, 2021.
2. Thain, D., Tannenbaum, T., & Livny, M. "Distributed computing in practice: the Condor experience." Concurrency and Computation: Practice and Experience, 17(2-4), 323-356, 2005.
3. Blomer, J., et al. "CernVM-FS: delivering scientific software to globally distributed computing resources." Journal of Physics: Conference Series, 396(5), 052018, 2012.
4. Fuhrmann, P., & Gulzow, V. "dCache, storage system for the future." In European Conference on Parallel Processing (pp. 1106-1113). Springer, Berlin, Heidelberg, 2006.
5. XRootD Collaboration. "XRootD – A highly scalable architecture for data access." WSEAS Transactions on Computers, 10(11), 2011.
6. Isard, M., et al. "Quincy: fair scheduling for distributed computing clusters." In Proceedings of the ACM SIGOPS 22nd symposium on Operating systems principles (pp. 261-276), 2009. (Für Scheduling-Theorie-Kontext).
7. Wilkinson, M. D., et al. "The FAIR Guiding Principles for scientific data management and stewardship." Scientific data, 3(1), 1-9, 2016.

9. Originalanalyse: Kernaussage, Logischer Ablauf, Stärken & Schwächen, Handlungsempfehlungen

Kernaussage: PUNCH4NFDI baut keinen neuen Supercomputer; es entwickelt eine Föderationsschicht mit minimal notwendigem Eingriff. Dies ist eine pragmatische, politisch kluge Antwort auf die realweltliche Beschränkung der fragmentierten, gemeinschaftseigenen Forschungsrechenlandschaft in Deutschland. Die wahre Innovation liegt nicht in den einzelnen Technologien – HTCondor, dCache, CVMFS sind erprobt – sondern in ihrer Orchestrierung zu einem kohärenten nationalen System mit einer tokenbasierten AAI als Kitt. Es ist eine klassische "Overlay-Netzwerk"-Strategie, angewendet auf die Cyberinfrastruktur, ähnlich wie das Internet selbst auf diversen physischen Netzen aufgebaut wurde. Während die European Open Science Cloud (EOSC) mit ähnlichen Föderationsherausforderungen ringt, bietet PUNCHs Ansatz einen konkreten, operationalen Bauplan.

Logischer Ablauf: Die Logik ist überzeugend einfach: 1) Heterogenität als permanenten Zustand akzeptieren, nicht als zu lösendes Problem. 2) Leichtgewichtiges Meta-Scheduling (COBalD/TARDIS) nutzen, um einen virtuellen Pool zu schaffen und Änderungen an etablierten lokalen Schedulern (SLURM, PBS, etc.) zu vermeiden. 3) Identitäts- und Zugriffsmanagement über Tokens entkoppeln, um den Albtraum der Abstimmung institutioneller Konten zu umgehen. 4) Software über CVMFS/Container von der Infrastruktur entkoppeln. 5) Dieselbe Föderationslogik auf den Speicher anwenden. Der Fluss geht von benutzerfreundlicher Einfachheit (JupyterHub) durch Abstraktionsschichten hinunter zur zugrundeliegenden Komplexität.

Stärken & Schwächen: Die überwältigende Stärke ist die praktische Umsetzbarkeit. Durch die Forderung minimaler Änderungen seitens der Ressourcenanbieter senkt sie die Einstiegshürde für die Teilnahme, was für das Bootstrapping eines Konsortiums entscheidend ist. Die Nutzung erprobter HEP-Werkzeuge gewährleistet Zuverlässigkeit und reduziert Entwicklungsrisiken. Die Schwächen liegen jedoch in den Kompromissen. Das Overlay-Modell kann im Vergleich zu einem eng integrierten System Leistungseinbußen bei der Jobverteilung und dem Datenzugriff einführen. Die "kleinste gemeinsame Nenner"-Abstraktion könnte den Zugang zu einzigartigen Features spezifischer HPC-Systeme einschränken. Am kritischsten ist, dass das langfristige Nachhaltigkeitsmodell unbewiesen ist – wer bezahlt für die zentrale Koordination, die Wartung des Meta-Schedulers und den Benutzersupport? Das Projekt riskiert, einen brillanten Prototypen zu bauen, der nach der anfänglichen 5-jährigen DFG-Finanzierung verkümmert.

Handlungsempfehlungen: Für andere Konsortien ist die zentrale Erkenntnis, mit Governance und leichtgewichtiger Integration zu beginnen, nicht mit einem groß angelegten technischen Redesign. 1) Sofort eine tokenbasierte AAI einführen; sie ist der grundlegende Ermöglicher. 2) Die Benutzererfahrung (JupyterHub) priorisieren, um die Akzeptanz zu fördern; Wissenschaftler nutzen kein umständliches System. 3) Von Anfang an alles instrumentieren. Um zukünftige Finanzierung zu sichern, müssen überzeugende Metriken zu erhöhter Ressourcennutzung, institutionsübergreifender Zusammenarbeit und wissenschaftlichem Durchsatz generiert werden. 4) Planung für die "zweite Föderation" – wie die Verbindung mit anderen NFDI-Konsortien oder EOSC. Die technische Architektur sollte explizit für verschachtelte Föderationen ausgelegt sein. Schließlich müssen sie ein klares Kostenverteilungsmodell für die zentralen Dienste entwickeln, weg von Projektförderungen hin zu einem kooperativen Betriebsfinanzierungsmodell ähnlich dem WLCG (Worldwide LHC Computing Grid). Die Technologie ist bereit; die dauerhafte Herausforderung ist sozio-technischer Natur.