Cx als Service für nachhaltige HPC-Forschungssoftware Entwicklung

Einleitung

Viele wissenschaftliche Anwendungscodes sind über viele Jahre oder auch Jahrzehnte gewachsen. Altlasten wie veraltete Programmiertechniken, ein "monolitischer" Aufbau oder fehlende Automatisierung erschweren die Weiterentwicklung und erhöhen stetig den Aufwand für die Validierung neuer Programmversionen. Zudem ist die Portierung auf neue und innovative Hardwarearchitekturen - die unter Umständen eine sehr viel höhere Rechenleistung als etablierte Architekturen ermöglichen könnten - nur eingeschränkt möglich.

Um die bereits erfolgten Investitionen in die existierenden Codebasen zu erhalten und deren Zukunftssicherheit zu sichern, gewinnt der Bereich der nachhaltigen Softwareentwicklung daher zunehmend an Bedeutung. Insbesondere die Automatisierung in Form von Continuous Integration, Continuous Testing und Continuous Deployment - kurz CI/CT/CD oder Cx - ist dabei von hoher Bedeutung.

Projektbeschreibung

Software ist ein integraler Bestandteil der modernen Forschung und hat in den letzten Jahren erheblich an Bedeutung gewonnen. Die meisten Softwareprojekte in einem wissenschaftlichen Umfeld lassen sich in eine von zwei Kategorien einordnen: große Softwareprojekte, die über einen langen Zeitraum entwickelt werden, oder kleine, kurzlebige Projekte. Erstere werden von einer Gruppe von Forschern über einen langen Zeitraum hinweg geschrieben und gepflegt, wobei die Mitglieder, die zu dem Projekt beitragen, in der Regel im Laufe der Zeit wechseln. Bei dieser Art von Software handelt es sich in der Regel um ein großes Projekt, das möglicherweise Millionen von Codezeilen umfasst und als integraler Bestandteil eines oder mehrerer wissenschaftlicher Bereiche dient. Bei letzteren handelt es sich um kleine Softwareprojekte, die oft nur von einer sehr kleinen Gruppe von Personen geschrieben und gewartet werden, z. B. von einem Doktoranden und einem Postdoktoranden. Diese Projekte werden typischerweise nur während der Dauer der zugehörigen Dissertation aktiv entwickelt und danach für einige Jahre genutzt, ohne weiter verwendet oder an nachfolgende Doktoranden übergeben zu werden. Typischerweise konzentrieren sich die meisten wissenschaftlichen Softwareprojekte nur auf einen einzigen Typ von Rechencluster mit einer bestimmten Architektur, z. B. einen Cluster mit vielen x86-CPUs und einer schnellen Verbindung zwischen den Knoten. Aufgrund des damit verbundenen Bedarfs an Rechenleistung, insbesondere bei großen Projekten, wird die Portierung oder Anpassung an zusätzliche Cluster in der Regel so weit wie möglich vermieden und nur bei Bedarf durchgeführt. Dies hat zur Folge, dass diese Projekte nur in begrenztem Umfang eingesetzt werden können und die Forscher einen erheblichen Zeitaufwand betreiben müssen, wenn sie sie auf verschiedenen bestehenden oder zukünftigen Clustern durchführen wollen.

Continuous Integration, Testing, Deployment und Benchmarking, CI, CT, CD und CB oder kurz Cx, können einerseits bei der Entwicklung und andererseits bei der Softwarepflege und nachhaltigen Nutzung dieser Codes erheblich helfen. Der konsequente Einsatz von CI und CT kann dazu beitragen, das Vertrauen in den Code eines Projektes zu fördern und sicherzustellen, dass Änderungen am Code und neue Features oder Überarbeitungen nicht bereits funktionierende Teile der Software zerstören. Darüber hinaus helfen definierte Verfahren beim Onboarding neuer Forscher, da diese die für den Cx-Prozess definierten Rezepte und Anweisungen zum Erstellen und Testen der Software befolgen können. Diese können als implizite Dokumentation dienen und die bestehende Dokumentation ergänzen. Daher kann Cx dazu beitragen, eine größere Zusammenarbeit rund um ein Projekt zu fördern. Während diese Art von Tests auch von Hand durchgeführt werden können, helfen CI und CT dabei, die für das Testen benötigte Zeit erheblich zu reduzieren und ermöglichen das Testen auf einer viel breiteren Palette von Systemen und Architekturen, wodurch eine nachhaltige Softwareentwicklung erleichtert wird, wenn man die Verwendung der Software auf verschiedenen bestehenden und zukünftigen Clustern in Betracht zieht. CB reichert die Informationen, die den Entwicklern von CT und CI zur Verfügung gestellt werden, mit zusätzlichen Laufzeitinformationen an, wie z. B. der Zeit, die zur Lösung eines bestimmten Problems benötigt wird, oder dem zugehörigen Speicherprofil. CB ermöglicht es Entwicklern zu beurteilen, ob Ergänzungen zu einem Projekt unerwünschte Auswirkungen auf die Leistung eines Projekts haben. CB hilft insbesondere dabei, sicherzustellen, dass Refactoring oder Überarbeitung von Code keine negativen Auswirkungen auf die Leistung des Softwareprojekts hat.

Die Projektpartner haben Erfahrung mit der Einrichtung und dem Betrieb von Cx-Setups auf ihren jeweiligen HPC-Clustern und nutzen Cx auch für ihre Forschungssoftwareprojekte. In Anlehnung an das Projektlayout des Vorgängerprojekts 2021 lassen sich die für dieses Projekt vorgesehenen Arbeiten im Wesentlichen in zwei Teile aufteilen. Einerseits werden wir die Cx-Einrichtungen in den beteiligten NHR-Zentren weiterentwickeln und verbessern und auf eine einheitliche Lösung für Cx im Kontext von HPC-Zentren hinarbeiten. Im vorangegangenen Projekt wurden erste Schritte unternommen, um Gemeinsamkeiten bei Cx-Einsätzen im Zentrum zu identifizieren und gemeinsame Ansätze für die Einrichtung abzuleiten. Und erste Schritte in Richtung eines einheitlichen Cx-Setups. Die nächsten Schritte in diesem Projekt werden darin bestehen, diese Art von Setups in weiteren Zentren bereitzustellen und die Nutzung zusätzlicher Arten von Ressourcen, wie FPGAs, GPUs und verschiedene CPU-Architekturen für Cx zu ermöglichen. Ein wichtiger Teil dieses Projekts wird die Arbeit an einem möglichst einheitlichen Ansatz zur Benutzerauthentifizierung und -autorisierung im Rahmen der Cx-Setups sein. Derzeit folgen die Zentren unterschiedlichen Protokollen, die von Forschern, die ihre persönlichen Konten verwenden müssen, über projektspezifische Dienstkonten bis hin zu allgemeinen Dienstkonten für Cx reichen. Darüber hinaus wollen wir eine Umfrage unter den Nutzern in den NHR-Zentren und in ihrem Umfeld durchführen, um Einblicke in die Erfahrungen und Fähigkeiten der Nutzer mit Cx-Einrichtungen zu gewinnen. Dies wird als Grundlage für die Bereitstellung eines angemessenen Niveaus an Dokumentation und Schulung dienen, um den Anforderungen der Benutzer gerecht zu werden. Es wird auch Informationen über die Anforderungen und Erwartungen der Nutzer an die angebotenen Cx-Dienste liefern und helfen, fehlende Funktionen zu identifizieren.

Zum anderen werden wir den Bereich des kontinuierlichen Benchmarking (CB) weiterentwickeln. Aufbauend auf der letzten Anwendung soll das Konzept der automatischen Erstellung von Benchmarks mit Autotester erweitert werden: Anstatt wie bisher die von Autotester zu interpretierenden Ausführungsregeln für die Erzeugung von Benchmarks in XML zu beschreiben, sollen visuell darstellbare Workflows als Ausführungsregeln verwendet werden. Zu diesem Zweck ist geplant, die bereits bestehende Workflow-Lösung von Kadi4Mat zu nutzen, die umfangreiche Möglichkeiten zur visuellen Erstellung, Speicherung und Ausführung von Workflows bietet. Die Workflows stellen Prozesse dar, die aus ausführbaren Komponenten frei zusammengestellt werden können. Die Verwendung der Workflows für die Generierung der Benchmarks zielt darauf ab, die Verifikation der Tests zu erleichtern. Vorteilhaft ist die übersichtliche Darstellung der Workflows sowie eine Einschränkung der Auswahl an erlaubten Komponenten. Dieser Ansatz erlaubt die einfache Integration von inhomogenen Softwarekomponenten in den Ablauf zur Erstellung der Benchmarks. Die Workflows können entweder direkt im Webinterface von Kadi4Mat oder mit einer spezialisierten Desktop-Anwendung erstellt und anschließend in das Kadi4Mat-Datenrepository hochgeladen werden. Innerhalb der CI-Pipeline können bereits gespeicherte und freigegebene Workflows über eine REST-Schnittstelle auf verschiedenen HPC-Systemen gestartet werden, um die gewünschten Benchmarks zu erzeugen. Die Benchmark-Ergebnisse sollen zunächst im Kadi4Mat-Datenrepository gespeichert werden und sind über das Kadi4Mat-Webinterface direkt zugänglich.

Andererseits ist auch eine automatisierte Abfrage über die REST-Schnittstelle von Kadi4Mat innerhalb der CI-Pipeline möglich. Zusammenfassend bietet die Speicherung in einer vollwertigen FDM-Lösung wie Kadi4Mat eine Vielzahl von Möglichkeiten zur weiteren Auswertung und Veröffentlichung der Benchmark-Ergebnisse. Für beide Teile des Projekts spielt die Containerisierung eine wichtige Rolle und ist der De-facto-Standard bei Cx-Diensten, die außerhalb der HPC-Umgebung angeboten werden, wie GitHub Actions oder GitLab CI. Wir müssen daher die Nutzung von Containern weiter untersuchen und ermöglichen. Zu diesem Zweck sehen wir eine enge Interaktion mit dem entsprechenden zentralen NHR-Projekt vor, um (1) deren etablierte Vorschläge und Lösungen für die Bereitstellung von Containern für die Nutzer unserer Cx-Dienste und auch (2) die Erkenntnisse aus z. B. der Nutzerumfrage an das Container-Projekt weiterzuleiten.