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

1. Einleitung

Particles, Universe, NuClei and Hadrons for the National Research Data Infrastructure (PUNCH4NFDI) ist ein bedeutendes deutsches Konsortium, das von der DFG (Deutsche Forschungsgemeinschaft) gefördert wird. Es repräsentiert etwa 9.000 Wissenschaftlerinnen und Wissenschaftler aus den Bereichen Teilchen-, Astro-, Astroteilchen-, Hadronen- und Kernphysik. Das vorrangige Ziel des Konsortiums ist der Aufbau einer föderierten und FAIR-konformen (Findable, Accessible, Interoperable, Reusable) Wissenschaftsdatenplattform. Eine zentrale Herausforderung ist die Föderierung der hochgradig heterogenen Rechen- (HPC, HTC, Cloud) und Speicherressourcen, die von Mitgliedsinstitutionen in ganz Deutschland als "In-kind"-Beiträge bereitgestellt werden, um Forschenden einen nahtlosen, einheitlichen Zugang zu ermöglichen.

2. Föderierte heterogene Recheninfrastruktur – Compute4PUNCH

Das Compute4PUNCH-Konzept ist darauf ausgelegt, transparenten Zugang zu einem diversen Pool von Rechenressourcen zu bieten, ohne erhebliche Änderungen an den bestehenden, betrieblichen Systemen der Anbieterstandorte zu erzwingen.

3. Föderierte Speicherinfrastruktur – Storage4PUNCH

Storage4PUNCH konzentriert sich auf die Föderierung von Community-Speichersystemen, die hauptsächlich auf den dCache- und XRootD-Technologien basieren, die Standards in der Hochenergiephysik (HEP) sind. Die Föderierung zielt darauf ab, einen einheitlichen Namensraum und Zugriffsprotokoll bereitzustellen. Das Konzept bewertet eine tiefere Integration durch:

• Speicherföderierungsprotokolle (z.B. basierend auf XRootDs Redirector-Föderierung oder dCache's Pool Manager).
• Caching-Schichten zur Reduzierung von Latenz und WAN-Datenverkehr.
• Metadatenverwaltung zur Verbesserung der Datenauffindbarkeit innerhalb der Föderierung.

4. Technische Details & Mathematisches Rahmenwerk

Die Kern-Scheduling-Logik kann als Optimierungsproblem modelliert werden. Sei $R = \{r_1, r_2, ..., r_n\}$ die Menge heterogener Ressourcen, jede mit Attributen wie Architektur, verfügbare Kerne $c_i$, Arbeitsspeicher $m_i$ und Kosten-/Prioritätsfaktor $p_i$. Ein Job $J$ hat Anforderungen $J_{req} = (c_{req}, m_{req}, arch_{req}, t_{req})$. Das Ziel des Meta-Schedulers ist es, den Gesamtnutzen oder Durchsatz zu maximieren.

Eine vereinfachte Bewertungsfunktion für die Platzierung von Job $J$ auf Ressource $r_i$ könnte lauten: $$ S(J, r_i) = \begin{cases} 0 & \text{wenn } r_i \text{ nicht mit } J_{req} \text{ übereinstimmt} \\ \alpha \cdot \frac{c_i}{c_{req}} + \beta \cdot \frac{m_i}{m_{req}} - \gamma \cdot p_i & \text{sonst} \end{cases} $$ wobei $\alpha, \beta, \gamma$ Gewichtungskoeffizienten sind. Das COBalD/TARDIS-System implementiert Heuristiken und Echtzeit-Feedback-Schleifen, um eine solche Optimierung dynamisch anzunähern und sich an die Ressourcenverfügbarkeit und Job-Warteschlangenzustände anzupassen.

5. Prototypergebnisse & Leistung

Diagrammbeschreibung (Konzeptionell): Ein Liniendiagramm zeigt "Aggregierte, zugängliche Rechenkapazität über die Zeit". Die x-Achse ist die Zeit (Monate). Zwei Linien sind dargestellt: 1) "Individuelle Ressourcenpools (Getrennt)" – flache, gestaffelte Linien, die die statische Kapazität einzelner Standorte repräsentieren. 2) "Föderierter Pool via Compute4PUNCH" – eine höhere, dynamischere Linie, die ansteigt, je mehr Standorte integriert werden, und kleinere Schwankungen zeigt, was den Lastausgleich innerhalb der Föderierung demonstriert. Das Diagramm veranschaulicht das zentrale Ergebnis: Das föderierte System bietet Nutzern einen größeren, widerstandsfähigeren und effizienter genutzten virtuellen Ressourcenpool als die Summe seiner isolierten Teile.

Erste Prototypen demonstrierten erfolgreich die Job-Einreichung von einem einzigen Zugangspunkt (JupyterHub) an mehrere Backend-HTCondor-Pools und HPC-Cluster (z.B. am KIT, DESY). Jobs, die Container-Umgebungen über CVMFS nutzten, wurden transparent auf verschiedenen Architekturen ausgeführt. Frühe Metriken deuten auf eine Verringerung der Job-Wartezeit für Nutzer hin, indem ungenutzte Kapazitäten innerhalb der Föderierung genutzt werden, obwohl die Datenübertragungslatenz zwischen Standorten für datenintensive Workloads ein kritischer Faktor bleibt.

6. Analyse-Rahmenwerk: Eine konzeptionelle Fallstudie

Szenario: Eine Multi-Messenger-Astrophysik-Analyse, die Daten eines Neutrinoteleskops (IceCube) und eines Gammastrahlen-Observatoriums (CTA) korreliert.

Workflow ohne Föderierung: Die Forschenden müssen: 1. Separate Rechenkontingente auf einem HPC-Cluster für Simulationen und einer HTC-Farm für Ereignisverarbeitung beantragen. 2. Große Datensätze (im TB-Bereich) manuell zwischen Speichersystemen verschiedener Institute transferieren. 3. Unterschiedliche Softwareumgebungen und Authentifizierungsmethoden verwalten.

Workflow mit Compute4PUNCH/Storage4PUNCH: 1. Die Forschenden loggen sich mit einem einzigen Token in den PUNCH JupyterHub ein. 2. Der Analyse-Workflow wird definiert (z.B. mit Snakemake oder ähnlichem). Simulationstasks (für HPC geeignet) werden automatisch über TARDIS an geeignete HPC-Ressourcen geleitet. Hochdurchsatz-Ereignisverarbeitungstasks werden an HTC-Farmen gesendet. 3. Der Workflow referenziert Daten über den föderierten Speicher-Namensraum (z.B. `punch://data/icecube/run_xyz.root`). Die zugrundeliegende XRootD/dCache-Föderierung übernimmt Ortung und Transfer. 4. Alle Jobs beziehen eine konsistente Softwareumgebung von CVMFS. Diese Fallstudie demonstriert das transformative Potenzial: Die Forschenden konzentrieren sich auf die Wissenschaft, nicht auf Infrastrukturlogistik.

7. Zukünftige Anwendungen & Entwicklungsfahrplan

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

• Föderiertes Maschinelles Lernen (Training): Nutzung heterogener GPUs über Standorte hinweg für das Training großer Modelle, möglicherweise mit Frameworks wie PyTorch oder TensorFlow und für das HTCondor/TARDIS-Backend adaptierten föderierten Lernalgorithmen.
• Dynamische, policy-gesteuerte Workload-Platzierung: Integration von CO2-bewusstem Scheduling, bei dem Jobs an Standorte mit hoher Verfügbarkeit erneuerbarer Energien geleitet werden, ähnlich den Konzepten der Initiative Green Algorithms.
• Inter-Konsortien-Föderierung: Als Blaupause für die Verbindung mit anderen NFDI-Konsortien oder europäischen Initiativen wie der European Open Science Cloud (EOSC) dienen, um eine paneuropäische Forschungsinfrastruktur zu schaffen.
• Intelligentes Daten-Caching & Pre-fetching: Nutzung von Workflow-Provenance und prädiktiver Analytik, um Datensätze proaktiv an Rechenstandorten zu cachen und so WAN-Latenz zu mindern – eine Herausforderung, die auch für Projekte wie IRIS-HEP zentral ist.

8. Analystenperspektive: Kernaussage, Logischer Ablauf, Stärken & Schwächen, Handlungsempfehlungen

Kernaussage: PUNCH4NFDI baut keinen neuen Supercomputer; es baut eine Virtualisierungs- und Orchestrierungsschicht, die die fragmentierte, zersplitterte deutsche Forschungsrechenlandschaft in einen kohärenten, nutzerzentrierten Dienst verwandelt. Dies ist eine klassische "Föderierungs-über-Ersetzungs"-Strategie, die Adoption und inkrementellen Wandel über revolutionären Umbau stellt – ein pragmatisch brillanter Zug angesichts der politischen und operativen Realitäten öffentlich finanzierter Institutionen.

Logischer Ablauf: Die Logik ist schlüssig: 1) Heterogenität und Eigentumsverhältnisse anerkennen (Ressourcen bleiben bei den Instituten). 2) Minimale neue Anforderungen stellen (Tokens, Container nutzen). 3) Eine intelligente, adaptive Middleware-Schicht (COBalD/TARDIS) einfügen, um Komplexität zu abstrahieren. 4) Einfache, moderne Nutzerschnittstellen (JupyterHub) bereitstellen. 5) Daten analog föderieren, um den Kreis zu schließen. Es ist ein Bottom-up-Integrationsleitfaden, den andere Konsortien studieren sollten.

Stärken & Schwächen: Stärken: Der Einsatz erprobter Komponenten (HTCondor, dCache, CVMFS) aus der HEP-Community reduziert das technische Risiko drastisch. Der Fokus auf AAI und Container adressiert die beiden größten Adoptionshürden: Zugang und Software. Die Wahl von COBalD/TARDIS ist inspiriert – es ist ein schlanker, Python-basierter Scheduler, der genau für dieses Hybrid-Cloud, opportunistische Szenario konzipiert ist. Kritische Schwächen: Der Elefant im Raum ist die Datenmobilität. Rechenressourcen zu föderieren ist einfacher als Speicher. Das Papier erwähnt Caching und Metadatenbewertung, aber die schwierigen Probleme der konsistenten globalen Namespace-Leistung, der WAN-Datenübertragungskosten und der standortübergreifenden Durchsetzung von Datenrichtlinien werden nur angedeutet. Ohne eine robuste Lösung hierfür wird der föderierte Rechenpool für datenintensive Workloads eingeschränkt sein. Darüber hinaus hängt der Erfolg vollständig von nachhaltigen "In-kind"-Beiträgen der Mitglieder ab – ein potenziell fragiles Wirtschaftsmodell.

Handlungsempfehlungen: 1. Für PUNCH4NFDI: Verstärkter Fokus auf die Datenschicht. Aktive Partnerschaften mit Projekten wie Rucio für Datenmanagement und dem Open Science Grid für Betriebserfahrung. Klare SLAs mit Ressourcenanbietern entwickeln, insbesondere bezüglich Datenausgangskosten. 2. Für Wettbewerber/Nachahmer: Nicht nur die Architektur kopieren. Die eigentliche Lektion liegt im Governance- und schlanken Integrationsmodell. Mit einem funktionierenden Prototypen an einigen willigen Standorten beginnen und organisch wachsen. 3. Für Anbieter & Förderorganisationen: Dieses Modell zeigt, dass zukünftige Investitionen in Forschungsrechnen Integrations-Middleware und Software-Nachhaltigkeit (wie COBalD) genauso fördern sollten wie, wenn nicht sogar mehr als, reine Hardware. Die "Klebstoff"-Software fördern.

Zusammenfassend ist der Ansatz von PUNCH4NFDI ein Meisterstück pragmatischer Cyberinfrastruktur-Entwicklung. Er erkennt, dass der größte Engpass im wissenschaftlichen Rechnen oft nicht FLOPS sind, sondern Benutzerfreundlichkeit und Zugang. Wenn sie die föderierte Daten-Nuss knacken können, werden sie ein Modell geschaffen haben, das das Potenzial hat, nicht nur das deutsche, sondern das europäische Forschungsrechnen neu zu gestalten.

9. Referenzen

1. PUNCH4NFDI Consortium. (2024). PUNCH4NFDI White Paper. NFDI.
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.
3. Giffels, M., et al. (2023). COBalD/TARDIS - A dynamic resource overlay for opportunistic computing. Journal of Physics: Conference Series.
4. Blomer, J., et al. (2011). The CernVM File System. Journal of Physics: Conference Series, 331(5), 052004.
5. 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 einer transformativen Rechenmethodik, die eine solche föderierte Infrastruktur nutzen könnte).
6. dCache Collaboration. (2023). dCache: A distributed storage system. https://www.dcache.org.
7. XRootD Collaboration. (2023). XRootD: High performance, scalable fault tolerant access to data. https://xrootd.slac.stanford.edu.
8. European Open Science Cloud (EOSC). (2024). https://eosc-portal.eu.