Fehlerverwaltung im neuen Sitzungsmodell von MPI angehen

Die neueste Version des Message Passing Interface (MPI) hat neue Features, wie das Sessionsmodell, aber sie sagt nichts darüber, wie man effektiv mit Fehlern umgeht. Frühere Arbeiten haben Tools und Erweiterungen wie ULFM entwickelt, die bei der Fehlerverwaltung helfen, aber diese Tools unterstützen die jüngsten Änderungen im MPI nicht vollständig.

In diesem Artikel geht es darum, die Fehlerverwaltungsfunktionen von ULFM mit dem neuen Sessionsmodell zu kombinieren. Wir schauen uns genau an, wie man Kommunikatoren erstellen kann, während man Fehler verwaltet, und schlagen eine Methode vor, um die auftretenden Herausforderungen anzugehen. Unsere Experimente zeigen, dass die vorgeschlagene Lösung die Laufzeit der Anwendungen nicht signifikant beeinflusst und die Skalierbarkeit besser aufrechterhält, während sie Fehler besser verwaltet.

#Hintergrund zu MPI und seinen Updates

Hochleistungsrechnen (HPC) entwickelt sich schnell weiter, und neuere Exascale-Cluster bringen neue Herausforderungen für Entwickler und Systemmanager mit sich. Ein wichtiges Tool im HPC ist MPI, das als Standard für die Kommunikation zwischen verschiedenen Prozessen dient. Die neueste Version, MPI 4.0, ändert, wie Anwendungen mit der Kommunikation umgehen.

Das Sessionsmodell in MPI erlaubt mehrere unabhängige Kommunikationsinstanzen, sodass verschiedene Teile einer Anwendung miteinander kommunizieren können, ohne jedes Mal einen globalen Kommunikator zu benötigen. Das kann zu weniger Overhead und schnelleren Ausführungen führen.

Mit der steigenden Anzahl von Knoten in HPC-Clustern steigt auch die Wahrscheinlichkeit von Fehlern. Der aktuelle MPI-Standard legt nicht klar fest, wie sich Anwendungen verhalten sollten, wenn ein Fehler auftritt. Das hat zur Entwicklung verschiedener Tools geführt, die Techniken zur Fehlerverwaltung einführen, wobei ULFM die bekannteste ist. ULFM fügt Funktionen hinzu, um Kommunikatoren, die von Fehlern betroffen sind, zu reparieren.

#Das MPI-Session-Modell

Das Problem bei traditionellen MPI-Kommunikationsmethoden ist, dass sie auf einem einzigen Initialisierungsaufruf basieren, was Probleme verursacht, wenn mehrere Teile einer Anwendung versuchen, die MPI Init-Funktion aufzurufen. Das macht es schwierig, dass verschiedene Komponenten unabhängig arbeiten können. Das Sessionsmodell greift diese Probleme auf, indem es jeder Komponente ermöglicht, ihre Kommunikation unabhängig zu verwalten, was die Modularität und Skalierbarkeit verbessert.

Im Sessionsmodell sind die meisten Funktionen lokal und erfordern keine Kommunikation, ausser für die MPI Comm create from group-Funktion, die Eingaben von allen beteiligten Prozessen benötigt. Sobald der Kommunikator erstellt ist, kann die Anwendung ähnlich wie im traditionellen World-Modell weiterlaufen.

#User Level Fault Mitigation (ULFM)

Der MPI-Standard gibt keine Anleitung dazu, was nach einem Fehler passiert, was die Fehlerverwaltung für Entwickler komplizierter macht. ULFM ist zwar eine Lösung, die es ermöglicht, die Ausführung fortzusetzen, obwohl ein oder mehrere Prozesse fehlerhaft sind, deckt aber nicht alle Arten von Fehlern ab. Zum Beispiel erfordern stille Datenkorruption oder Timing-Fehler spezifische Lösungen, die ULFM nicht anspricht.

ULFM konzentriert sich auf Fehler, die dazu führen, dass Prozesse abrupt stoppen. Es gibt jedoch keine Anleitungen dazu, was vor und während des MPI Init-Aufs haben. Das stellt Herausforderungen für das Sessionsmodell dar, da die Flexibilität undefiniertes Verhalten verursachen kann, wenn sie falsch gehandhabt wird. Unsere Arbeit zielt darauf ab, die anfängliche Phase des Sessionsmodells zu analysieren, um die Fehlerverwaltung zu verbessern.

#Herausforderungen bei Initialisierungsflüssen

Wir bewerten, wie Fehler den Initialisierungsprozess sowohl im Sessions- als auch im World-Modell beeinflussen. Im World-Modell kann ein Fehler während der Initialisierung zu einer Deadlock-Situation führen, in der die Anwendung unendlich auf einen Prozess wartet, der niemals beitritt. Aufgrund der Struktur des Sessionsmodells können jedoch die meisten Anfangsaufrufe lokal erfolgen und auch dann erfolgreich sein, wenn einige Prozesse fehlschlagen, ausser beim MPI Comm create from group-Aufruf.

Das Potenzial für Deadlocks im Sessionsmodell ist ein erhebliches Anliegen, zumal die anfänglichen Aufrufe zu verschiedenen Zeitpunkten während der Ausführung erfolgen können. Daher ist es entscheidend, die Risiken von Deadlocks zu minimieren und gleichzeitig die Anwendungsleistung aufrechtzuerhalten.

#Einführung von Horizon Sets

Um das Problem mit Deadlocks zu lösen, schlagen wir die Verwendung von Horizon Sets vor. Diese Sets sind dazu gedacht, vorhandene Kommunikatoren im Auge zu behalten, damit immer mindestens ein Kommunikator für den Liveness Discovery Algorithm (LDA) zur Verfügung steht, um Fehler effektiv zu verwalten.

Der LDA hilft dabei, Fehler während der Erstellung von Kommunikatoren zu erkennen und zu verwalten. Durch sorgfältige Definition der Horizon Sets können wir die Wahrscheinlichkeit von Deadlocks verringern. Das erreichen wir, indem wir sicherstellen, dass ein Kommunikatorset erstellt wird, bevor wir neue Kommunikatoren initialisieren.

Während ein naiver Ansatz einen globalen Kommunikator erstellen würde, was dem Zweck der Flexibilität des Sessionsmodells widerspricht, schlägt unsere Methode einen effizienteren Weg vor, die Kommunikatoren zu verwalten, ohne die Vorteile des Sessionsmodells zu opfern.

#Experimentelle Ergebnisse

Um unsere vorgeschlagene Lösung zu testen, haben wir sie in die Legio-Bibliothek integriert, die bereits den LDA implementiert. Unsere Experimente bewerteten die Auswirkungen auf Leistung und Skalierbarkeit anhand von realistischen Benchmarks auf einem Cluster.

Wir führten verschiedene Tests durch, um drei Szenarien zu vergleichen: die naive Lösung, die Unterstützung von Horizon Sets und Konfigurationen ohne Fehlerverwaltung. Die Ergebnisse zeigten, dass der naive Ansatz konsequent mehr Overhead verursachte, insbesondere wenn die Netzwergrössen zunahmen. Im Gegensatz dazu hielt die Horizon Set-Lösung die Skalierbarkeit der Anwendung aufrecht, ohne dass unnötige globale Kommunikatorinitialisierungen erforderlich waren.

Zusätzlich führten wir Funktionstests durch, um die Robustheit unseres Ansatzes gegen Fehler zu demonstrieren. Anwendungen, die unsere Lösung nutzten, konnten erfolgreich abgeschlossen werden, selbst wenn während der Ausführung Fehler auftraten.

#Fazit und zukünftige Arbeiten

Durch unsere Analyse und Implementierung haben wir gezeigt, dass es möglich ist, die Auswirkungen von Fehlern in MPI-Anwendungen unter Verwendung des Sessionsmodells effektiv zu verwalten. Die Einführung von Horizon Sets hat sich als vorteilhaft erwiesen, um die Risiken von Deadlocks zu reduzieren und die Skalierbarkeit zu verbessern.

Zukünftige Bemühungen werden wahrscheinlich darin bestehen, unseren Ansatz mit anderen MPI-Vorschlägen, wie dem Bubbles-Konzept, zu integrieren und neue Benchmarks zu testen, um die Fähigkeiten des Sessionsmodells unter verschiedenen Szenarien weiter zu untersuchen. Diese laufende Arbeit zielt darauf ab, sicherzustellen, dass Anwendungen auch angesichts von Fehlern robust und effizient bleiben.