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

1. Einleitung

PUNCH4NFDI (Particles, Universe, NuClei and Hadrons for the National Research Data Infrastructure) ist ein bedeutendes deutsches Konsortium, das von der DFG (Deutsche Forschungsgemeinschaft) gefördert wird. Es repräsentiert etwa 9.000 Wissenschaftler:innen aus den Bereichen Teilchen-, Astro-, Astroteilchen-, Hadronen- und Kernphysik. Das vorrangige Ziel des Konsortiums ist die Etablierung einer föderierten, FAIR-konformen (Findable, Accessible, Interoperable, Reusable) Wissenschafts-Datenplattform. Dieser Beitrag erläutert im Speziellen die Architekturkonzepte – Compute4PUNCH und Storage4PUNCH –, die entwickelt wurden, um den Zugang zu den hochgradig heterogenen Rechen- (HPC, HTC, Cloud) und Speicherressourcen zu vereinheitlichen, die von Mitgliedsinstitutionen in ganz Deutschland als Naturalleistung beigesteuert werden.

2. Föderierte heterogene Recheninfrastruktur – Compute4PUNCH

Die Compute4PUNCH-Initiative adressiert die Herausforderung, einen nahtlosen Zugang zu einem diversen Pool bestehender Rechenressourcen zu bieten, ohne die Betriebsmodelle der Ressourcenanbieter wesentlich zu verändern.

2.1. Kernarchitektur & Technologien

Die Föderation basiert auf einem HTCondor-basierten Overlay-Batch-System. Die zentrale Innovation ist die Verwendung des COBalD/TARDIS-Ressourcen-Meta-Schedulers. TARDIS fungiert als dynamischer Broker, der abstrakte Ressourcenanfragen aus dem HTCondor-Pool in konkrete Bereitstellungsaktionen auf Backend-Systemen übersetzt (z.B. Starten von VMs auf OpenStack, Einreichen von Jobs an Slurm). Dies schafft eine dynamische und transparente Integrationsschicht. Eine tokenbasierte Authentifizierungs- und Autorisierungsinfrastruktur (AAI) bietet standardisierten Zugang.

2.2. Zugang & Benutzeroberfläche

Nutzer:innen interagieren mit dem föderierten System hauptsächlich über zwei Einstiegspunkte:

Traditionelle Login-Knoten: Bieten Shell-Zugang zu einer einheitlichen Umgebung.
JupyterHub: Bietet eine webbasierte, interaktive Rechenumgebung und senkt die Einstiegshürde für Datenanalysen erheblich.

Von diesen Einstiegspunkten aus können Nutzer:innen Jobs an den HTCondor-Pool übermitteln, die dann von COBalD/TARDIS über die heterogenen Backends hinweg verwaltet werden.

2.3. Verwaltung der Softwareumgebung

Um die unterschiedlichen Softwareanforderungen der Communities zu bewältigen, setzt das Projekt ein:

Container-Technologien (z.B. Docker, Singularity/Apptainer): Zur Kapselung von Anwendungsumgebungen.
CERN Virtual Machine File System (CVMFS): Ein schreibgeschütztes, global verteiltes Dateisystem zur skalierbaren Bereitstellung von Software-Stacks und Experimentdaten. Dies entkoppelt die Softwareverteilung von der zugrundeliegenden Infrastruktur.

3. Föderierte Speicherinfrastruktur – Storage4PUNCH

Storage4PUNCH zielt darauf ab, Community-Speichersysteme zu föderieren, die hauptsächlich auf den in der Hochenergiephysik (HEP) etablierten Technologien dCache und XRootD basieren.

3.1. Strategie zur Speicherföderation

Die Strategie besteht nicht darin, ein einzelnes monolithisches Speichersystem zu schaffen, sondern bestehende Systeme zu föderieren. Der Fokus liegt darauf, einen einheitlichen Namensraum und eine Zugriffsprotokollschicht bereitzustellen, die die Heterogenität der zugrundeliegenden Speicher abstrahiert. Dies ermöglicht es, die Datenlokalität zu erhalten und gleichzeitig globalen Zugriff zu gewährleisten.

3.2. Technologie-Stack & Integration

Die Föderation nutzt:

dCache: Wird sowohl als Speicher-Backend als auch für seine Föderationsfähigkeiten eingesetzt.
XRootD: Wird für seine effizienten Datenzugriffsprotokolle und Umleitungskapazitäten genutzt, die für den Aufbau von Datenföderationen entscheidend sind.
Evaluierung von Caching- & Metadaten-Technologien: Das Projekt evaluiert aktiv Technologien wie Rucio (für Datenmanagement) und Caching-Schichten, um Datenzugriffsmuster zu optimieren und eine intelligentere Datenplatzierung zu ermöglichen, was über eine einfache Föderation hinaus zu einer tieferen Integration führt.

4. Technische Details & Mathematisches Rahmenwerk

Die Kern-Scheduling-Logik in COBalD/TARDIS kann als Optimierungsproblem modelliert werden. Sei $R = \{r_1, r_2, ..., r_n\}$ die Menge der Ressourcenanfragen aus dem HTCondor-Pool und $B = \{b_1, b_2, ..., b_m\}$ die Menge der verfügbaren Backend-Ressourcentypen (z.B. HPC-Knoten, Cloud-VM). Jede Anfrage $r_i$ hat Anforderungen (Kerne, Arbeitsspeicher, Software). Jedes Backend $b_j$ hat eine Kostenfunktion $C_j(r_i)$ und eine Bereitstellungszeit $T_j(r_i)$.

Das Ziel des Meta-Schedulers ist es, eine Abbildung $M: R \rightarrow B$ zu finden, die eine Gesamtkostenfunktion minimiert, oft eine gewichtete Summe aus finanziellen Kosten und Fertigstellungszeit, unter Berücksichtigung von Nebenbedingungen wie Backend-Quoten und Softwareverfügbarkeit:

$$\min_{M} \sum_{r_i \in R} \left[ \alpha \cdot C_{M(r_i)}(r_i) + \beta \cdot T_{M(r_i)}(r_i) \right]$$

wobei $\alpha$ und $\beta$ Gewichtungsfaktoren sind. Dies formalisiert die Herausforderung der "dynamischen und transparenten" Integration.

5. Prototypergebnisse & Leistung

Das Papier berichtet über erste Erfahrungen mit wissenschaftlichen Anwendungen, die auf verfügbaren Prototypen laufen. Während spezifische quantitative Benchmarks im vorliegenden Auszug nicht detailliert beschrieben werden, impliziert die erfolgreiche Ausführung:

Funktionale Integration: Der HTCondor/COBalD/TARDIS-Stack leitete Jobs erfolgreich an verschiedene Backend-Systeme (HTC, HPC, Cloud) weiter.
Softwarebereitstellung: CVMFS und Container stellten die notwendigen Softwareumgebungen zuverlässig über heterogene Worker-Knoten hinweg bereit.
Nutzerzugang: JupyterHub und Login-Knoten erwiesen sich als effektive Einstiegspunkte für Forschende.

Konzeptdiagramm: Die Systemarchitektur kann als Drei-Schichten-Modell visualisiert werden:

Nutzerzugangsschicht: JupyterHub, Login-Knoten, Token-AAI.
Föderations- & Scheduling-Schicht: HTCondor-Pool + COBalD/TARDIS Meta-Scheduler.
Ressourcenschicht: Heterogene Backends (HPC-Cluster, HTC-Farmen, Cloud-VMs) und föderierter Speicher (dCache-, XRootD-Instanzen).

Daten und Jobs fließen von der obersten Schicht durch die intelligente Scheduling-Mittelschicht zur passenden Ressource in der untersten Schicht.

6. Analyse-Rahmenwerk: Ein Anwendungsfallszenario

Szenario: Ein Kernphysikforscher muss 10.000 Monte-Carlo-Simulationsaufgaben verarbeiten, die jeweils 4 CPU-Kerne, 16 GB RAM und einen spezifischen Software-Stack (Geant4, ROOT) benötigen.

Übermittlung: Der Forscher meldet sich am PUNCH-JupyterHub an, schreibt ein Analysescript und übermittelt 10.000 Jobs an den lokalen HTCondor-Scheduler.
Meta-Scheduling: COBalD/TARDIS überwacht die HTCondor-Warteschlange. Es bewertet verfügbare Backends: Die HTC-Farm der Universität A (geringe Kosten, lange Wartezeit), der HPC-Cluster des Instituts B (moderate Kosten, spezialisierte Hardware) und eine kommerzielle Cloud (hohe Kosten, sofortige Verfügbarkeit).
Entscheidung & Ausführung: Basierend auf seinem Kostenmodell könnte TARDIS entscheiden, 2.000 Jobs sofort in die Cloud auszulagern, um schnell zu starten, während der Rest kontinuierlich auf der kostengünstigeren HTC-Farm abgearbeitet wird. Es nutzt die Token-AAI zur Authentifizierung auf allen Systemen.
Software & Daten: Jeder Job zieht seine Geant4/ROOT-Umgebung unabhängig vom Backend aus CVMFS. Eingabedaten werden aus dem föderierten Storage4PUNCH-Namensraum abgerufen (z.B. via XRootD), und die Ausgabe wird an einen festgelegten Speicherendpunkt zurückgeschrieben.
Abschluss: Der Forscher überwacht und aggregiert die Ergebnisse aus der einzelnen HTCondor-Job-Warteschlange, ohne Kenntnis der zugrundeliegenden Multi-Infrastruktur-Ausführung.

Dieses Szenario demonstriert die Transparenz, Effizienz und nutzerzentrierte Gestaltung der föderierten Infrastruktur.

7. Kritische Analyse & Expertenperspektive

Kernerkenntnis: PUNCH4NFDI baut keine weitere Cloud; es konstruiert eine Föderationsschicht von bemerkenswerter politischer und technischer Pragmatik. Seine wahre Innovation liegt im COBalD/TARDIS-Meta-Scheduler, der als "diplomatischer Übersetzer" für die Ressourcenteilung fungiert, nicht als erobernder Vereinheitlicher. Dies anerkennt die Souveränität bestehender institutioneller Cluster – eine nicht verhandelbare Realität in der deutschen Wissenschaftslandschaft – und schafft dennoch eine funktionale Supra-Ressource.

Logischer Ablauf: Die Logik ist einwandfrei: Beginne beim Nutzer (JupyterHub/Login), abstrahiere das Chaos über einen erprobten Scheduler (HTCondor), nutze dann einen intelligenten Broker (TARDIS), um abstrakte Anfragen auf konkrete, politisch machbare Backends abzubilden. Die Abhängigkeit von CVMFS und Containern für Software ist ein Meisterstreich, der das "Dependency Hell"-Problem löst, das die meisten Föderationen plagt. Die Speicherstrategie ist weise konservativ, baut auf dem bewährten dCache/XRootD-Duo aus der HEP auf und vermeidet den Sumpf, eine einzelne neue Technologie erzwingen zu wollen.

Stärken & Schwächen:

Stärken: Minimale Invasion ist seine Superkraft. Es erfordert keine Änderungen der lokalen Richtlinien durch die Anbieter. Die Nutzung ausgereifter, community-getriebener Tools (HTCondor, CVMFS, dCache) reduziert das Risiko drastisch und erhöht die Nachhaltigkeit im Vergleich zu Projekten, die auf maßgeschneiderten Frameworks basieren. Der Fokus auf FAIR-Prinzipien stimmt perfekt mit modernen Förderauflagen überein.
Schwächen & Risiken: Der Meta-Scheduler-Ansatz führt eine zentrale Stelle der Komplexität und potenziellen Fehleranfälligkeit ein. COBalD/TARDIS ist, obwohl vielversprechend, nicht so erprobt wie die anderen Komponenten. Die "Evaluierung" von Caching-/Metadaten-Technologien (wie Rucio) deutet darauf hin, dass der schwierigste Teil noch bevorsteht: intelligentes Datenmanagement. Ohne dies ist es eine Rechenföderation mit einem angehängten Speicherverzeichnis, keine kohärente datenzentrierte Plattform. Es besteht auch ein lauerndes Risiko der Leistungsunvorhersehbarkeit für Nutzer, da ihre Jobs zwischen grundlegend verschiedenen Architekturen wechseln.

Umsetzbare Erkenntnisse:

Für PUNCH-Architekten: Verstärkt die Robustheit und Beobachtbarkeit von TARDIS. Seine Metriken und Entscheidungsprotokolle sind Gold wert für Optimierung und Vertrauensbildung. Priorisiert als nächstes die Integration einer Datenmanagementschicht (wie Rucio); Rechenleistung ohne intelligente Daten ist nur eine halbe Lösung.
Für andere Konsortien: Dies ist eine Blaupause, die es wert ist, nachgeahmt zu werden, insbesondere die Philosophie "Integration statt Ersetzung". Bewertet jedoch, ob eure Community ein Äquivalent zu CVMFS hat – wenn nicht, ist das eure erste Bau-/Kaufentscheidung.
Für Ressourcenanbieter: Dieses Modell ist für euch risikoarm. Engagiert euch. Die tokenbasierte AAI ist eine saubere Möglichkeit, Zugang zu bieten, ohne die lokale Sicherheit zu gefährden. Es ist ein Netto-Gewinn für Sichtbarkeit und Auslastung.

Der Erfolg des Projekts wird nicht an Spitzen-FLOPS gemessen, sondern daran, wie unsichtbar es einer Doktorandin in Tautenburg ermöglicht, nahtlos Rechenzyklen in Bonn und Daten in Karlsruhe zu nutzen. Das ist ein weitaus ehrgeizigeres – und wertvolleres – Ziel.

8. Zukünftige Anwendungen & Entwicklungsfahrplan

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

Domänenübergreifende Workflows: Ermöglicht komplexe, mehrstufige Analyse-Pipelines, die nahtlos zwischen Simulation (HPC), Hochdurchsatz-Ereignisverarbeitung (HTC) und maschinellem Lernen (Cloud-GPUs) wechseln.
Datenzentriertes Scheduling: Tiefere Integration der Speicherföderation mit dem Compute-Scheduler. Zukünftige Versionen von COBald/TARDIS könnten Datenlokalität (Minimierung von WAN-Transfers) und Vorstufung in ihre Kostenfunktion einbeziehen und sich so in Richtung datenbewussten Scheduling bewegen.
Integration mit FAIR-Datenrepositorien: Dient als Hochleistungs-Rechen-Backbone für nationale FAIR-Datenrepositorien und ermöglicht Forschenden, große Datensätze direkt dort zu analysieren, wo sie gespeichert sind, gemäß dem "Compute-to-Data"-Paradigma.
KI/ML als Dienst: Die JupyterHub-Oberfläche und das skalierbare Backend könnten um kuratierte Umgebungen für spezialisierte KI/ML-Frameworks (PyTorch, TensorFlow) und Zugang zu GPU-Ressourcen erweitert werden, um KI für die physikalischen Wissenschaften zu demokratisieren.
Ausweitung auf internationale Ressourcen: Das Föderationsmodell könnte erweitert werden, um Ressourcen aus europäischen Initiativen wie der European Open Science Cloud (EOSC) oder LHC-Computing-Grid (WLCG)-Standorten einzubeziehen und eine wirklich paneuropäische Forschungsinfrastruktur zu schaffen.

Der Fahrplan umfasst voraussichtlich die Verfestigung des aktuellen Prototyps, die Skalierung der Anzahl integrierter Ressourcen, die Implementierung der evaluierten Metadaten-/Caching-Lösungen und die Entwicklung ausgefeilterer Richtlinien- und Abrechnungsmechanismen für eine faire Ressourcennutzung im Konsortium.

9. Literaturverzeichnis

PUNCH4NFDI-Konsortium. (2024). PUNCH4NFDI White Paper. [Internes Konsortiumsdokument].
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.
Blomer, J., et al. (2011). The CernVM file system. Journal of Physics: Conference Series, 331(5), 052004.
COBalD/TARDIS-Dokumentation. (o.D.). Abgerufen von https://tardis.readthedocs.io/
dCache-Kollaboration. (o.D.). dCache: A distributed storage system. https://www.dcache.org/
XRootD-Kollaboration. (o.D.). XRootD: High performance, scalable fault tolerant access to data. http://xrootd.org/
Wilkinson, M. D., et al. (2016). The FAIR Guiding Principles for scientific data management and stewardship. Scientific data, 3(1), 1-9.
European Open Science Cloud (EOSC). (o.D.). https://eosc-portal.eu/
Worldwide LHC Computing Grid (WLCG). (o.D.). https://wlcg.web.cern.ch/