Das primäre Ziel von FEToL ist eine minimalinvasive und ressourcen- effiziente Erhöhung der Ausfallsicherheit von HEC-Systemen durch einen auf dem "divide-and-conquer"- Prinzip basierenden Softwareansatz, der system- und anwendungsübergreifende Methoden zur Behandlung unterschiedlicher Ausfallszenarien implementiert.
Der Einsatz von High-Performance-Computing (HPC) ist zum Standard in vielen Bereichen der Wirtschaft und Wissenschaft geworden. Die neuen Tendenzen und Herausforderungen, die sich bei den meist öffentlich finanzierten Installationen und Anwendungen im Spitzenleistungsbereich (High-End-Computing, HEC) abzeichnen, stellen die Weichen für die Techniken, die Softwarestruktur für die wirtschaftlichen und wissenschaftlichen Potentiale der breiten Anwendung von HPC. Das Projekt FEToL greift einen entscheidenden Bereich von Problemen auf, die sich bei peta-scale Systemen bereits abgezeichnet haben. Robuste und stabile HEC-Umgebungen stellen heutzutage eine wesentliche Grundlage zur Lösung der wichtigsten wissenschaftlichen und technischen Problemstellungen dar. Da die Größe und Komplexität solcher HEC-Systeme stetig ansteigt, werden die Auswirkungen von Fehlern und Ausfällen von Systemkomponenten immer gravierender. Diese Fehler treten bei komplexen Systeminteraktionen und durch Abhängigkeiten zwischen der Hardware und der Systemsoftware bedingt durch die zeitabhängige Arbeitslast und die technische Ausstattung auf. Daher ist es in den nächsten Jahren unabdingbar, dass in HEC-Systeme über entsprechend erweiterte System- und Anwendungssoftware Mechanismen zur Fehlertoleranz integriert werden und damit ihre Widerstandsfähigkeit (Resilienz) gegen eine Vielzahl von möglichen Teilversagensmechanismen nachhaltig erhöht wird. Jüngste Extrapolationen deuten klar darauf hin, dass die Herausforderungen der Integration großer komplexer heterogener Systeme im Multi-Petascale- und Exascale-Bereich in den nächsten Jahren zu einem Zustand führen, bei dem die Dauer der "Stabilisierung" einen signifikanten Anteil der Lebensdauer dieser Systeme beansprucht. Als Konsequenz dieser beunruhigenden Entwicklungen wird es für die HEC-Gemeinde notwendig sein, innovative Methoden zu entwickeln, um eine produktive Arbeit auf diesen Systemen effizient und bezahlbar gestalten zu können, auch wenn während des Produktionsbetriebes häufig (nur statistisch voraussagbare) Fehler auftreten, von denen nicht wenige von existierenden Überwachungssystemen unentdeckt bleiben.
Der grundlegende Ansatz basiert zum einen auf einer Gruppierung aller am Gesamtjob beteiligten Prozesse in sog. Prozess-Bündel (PB), von denen jedes einzelne auf einem oder mehreren Knoten des Systems läuft. Alle Prozesse eines PB kommunizieren untereinander mit nativem MPI über einen PB-spezifischen Kommunikator. Die Kommunikation zwischen einzelnen Prozessen zweier PB erfolgt durch Adaption eines an der TUBS entwickelten Multi-Agenten-Systems namens BOND. Diesen Cross-PB- Kommunikator bezeichnen wir mit xPB/BOND. Die Kommunikation zwischen den Prozessen zweier PB kann nicht komplett über den JM laufen, da dies nicht skalieren würde. Die Gesamtanwendung besteht aus (potentiell vielen) Jobinstanzen, welche PB-weise vom Scheduler (beispielsweise als Sub- request) gestartet werden können. Falls ein oder mehrere Prozesse eines PBs durch Hardware- oder Netzwerkfehler ausfallen, ist der Zustand des PB undefiniert und erfordert einen Neustart des PB basierend auf Checkpoint-Daten oder/und Daten der Prozessnachbarn, deren Generierung, Organisation und Verwendung weiter unten beschrieben wird. Um die Rekonstruktion eines PBs und seinen Neustart auf ggf. neuen Hardwareressourcen zu organisieren, bedarf es dreier zusätzlicher Softwareinstanzen. Diese sind der Job-Manager, der I/O-Manager und der Scheduler (SLURM ggf. in Verbindung mit Meta-Scheduler Software wie Moab Cluster Suite, MauiıCluster Scheduler oder Platform LSF). Der JM ist dabei hierarchisch im Sinne eines Baumes (nodes: root, parent, leafs) aufgebaut, um Redundanz bei Ausfall einer JM-Instanz zu ermöglichen, siehe folgende Abbildung.
Schematische Darstellung eines JM-Blattes: PB mit Anbindung an I/O-Manager, JM und Prozesse anderer PB
Um die Persistierung von Daten für das Checkpointing (CP) und interaktives Postprocessing zu ermöglichen, bündelt die ebenfalls hierarchisch organisierte I/O-Manager-Instanz des PB die (komprimierten) Anwendungsdaten, siehe folgende Abbildung.
Schematische Darstellung der Datenpersistierung
Der parallele Job insgesamt besteht aus einem hierarchischen Baum von PB, siehe unten stehende Abbildung. Diese werden von hierarchischen Instanzen des JM und I/O- Managers in Abstimmung mit dem Scheduler verwaltet, kontrolliert und ggf. neu gestartet.
Hierarchische Struktur des Gesamtjobs
Prof. Dr.-Ing. Manfred Krafczyk Inst. für rechnergestützte Modellierung im Bauingenieurwesen
Pockelsstr. 3
38106 Braunschweig
Förderkennzeichen: 01 IH11011
Förderdauer: 01.06.2011 - 31.05.2014