Affrontare la gestione dei guasti nel nuovo modello di sessione di MPI

L'ultima versione dell'Interfaccia di Passaggio Messaggi (MPI) include nuove funzionalità, come il modello di Sessione. Tuttavia, non affronta come gestire i guasti in modo efficace. Lavori precedenti avevano sviluppato strumenti e estensioni per aiutare nella gestione dei guasti, come ULFM, ma questi strumenti non supportano completamente le recenti modifiche in MPI.

Questo articolo si concentra sul combinare le funzionalità di gestione dei guasti di ULFM con il nuovo modello di Sessione. Analizziamo attentamente come creare comunicatori mentre gestiamo i guasti e suggeriamo un metodo per affrontare le sfide che si presentano. I nostri esperimenti indicano che la soluzione proposta non influisce significativamente sul tempo necessario per eseguire le applicazioni e mantiene la scalabilità mentre gestisce meglio i guasti.

#Contesto su MPI e i suoi Aggiornamenti

Il Calcolo Ad Alte Prestazioni (HPC) sta evolvendo rapidamente e i nuovi cluster exascale presentano nuove sfide per sviluppatori e gestori di sistema. Uno strumento fondamentale nell'HPC è MPI, che funge da standard per la comunicazione tra diversi processi. L'ultima versione, MPI 4.0, cambia il modo in cui le applicazioni gestiscono la comunicazione.

Il modello di Sessione in MPI consente a più istanze di comunicazione indipendenti, consentendo a diverse parti di un'applicazione di comunicare senza bisogno di un comunicatore globale ogni volta. Questo può portare a una riduzione del sovraccarico e a un'esecuzione più veloce.

Con l'aumento del numero di nodi nei cluster HPC, aumenta anche la possibilità di guasti. Lo standard MPI attuale non specifica chiaramente come dovrebbero comportarsi le applicazioni quando si verifica un guasto. Questo ha portato a vari strumenti che introducono tecniche di gestione dei guasti, con ULFM che è il più prominente. ULFM aggiunge funzionalità per aiutare a riparare i comunicatori colpiti da guasti.

#Il Modello di Sessione MPI

La sfida con i metodi di comunicazione tradizionali di MPI è che si basano su una singola chiamata di inizializzazione, che può creare problemi se diverse parti di un'applicazione cercano di chiamare la funzione MPI Init. Questo rende difficile per i diversi componenti operare in modo indipendente. Il modello di Sessione affronta questi problemi consentendo a ciascun componente di gestire la propria comunicazione in modo indipendente, migliorando modularità e scalabilità.

Nel modello di Sessione, la maggior parte delle funzioni è locale e non richiede alcuna comunicazione, eccetto per la funzione MPI Comm create from group, che ha bisogno di input da tutti i processi coinvolti. Una volta creato il comunicatore, l'applicazione può continuare a funzionare in modo simile al modello World tradizionale.

#Mitigazione dei Guasti a Livello Utente (ULFM)

Lo standard MPI non fornisce indicazioni su cosa fare dopo che si è verificato un guasto, il che complica la gestione dei guasti per gli sviluppatori. Sebbene ULFM sia una soluzione che consente di continuare l'esecuzione nonostante uno o più processi in fase di fallimento, non copre tutti i tipi di guasti. Ad esempio, la corruzione silenziosa dei dati o gli errori temporali richiedono soluzioni specifiche che ULFM non affronta.

ULFM si concentra sui guasti che causano l'arresto improvviso dei processi. Tuttavia, non fornisce indicazioni su cosa accade prima e durante la chiamata MPI Init. Questo presenta sfide per il modello di Sessione, dove la flessibilità può causare comportamenti indefiniti se non gestita correttamente. Il nostro lavoro mira ad analizzare la fase iniziale del modello di Sessione per migliorare la gestione dei guasti.

#Sfide nei Flussi di Inizializzazione

Valutiamo come i guasti impattino il processo di inizializzazione sia nei modelli di Sessione che World. Nel modello World, un guasto durante l'inizializzazione può portare a una situazione di deadlock, dove l'applicazione aspetta indefinitamente un processo che non si unisce mai. Tuttavia, a causa della struttura del modello di Sessione, la maggior parte delle chiamate iniziali è locale e può ancora avere successo anche se alcuni processi falliscono, tranne per la chiamata MPI Comm create from group.

Il potenziale di deadlock nel modello di Sessione è una preoccupazione significativa, specialmente dato che le chiamate iniziali possono avvenire in vari punti durante l'esecuzione. Quindi, è cruciale minimizzare i rischi di deadlock mantenendo le prestazioni dell'applicazione.

#Introduzione ai Set di Orizzonte

Per affrontare il problema del deadlock, suggeriamo di utilizzare i Set di Orizzonte. Questi set sono progettati per tenere traccia dei comunicatori esistenti, assicurando che almeno un comunicatore sia sempre disponibile per l'Algoritmo di Scoperta della Vitalità (LDA) per gestire i guasti in modo efficace.

L'LDA aiuta a rilevare e gestire i guasti durante la creazione della comunicazione. Definendo attentamente i Set di Orizzonte, possiamo ridurre la possibilità di deadlock. Possiamo ottenere questo assicurandoci che un insieme di comunicatori venga creato prima di inizializzare nuovi comunicatori.

Sebbene un approccio naive creerebbe un comunicatore globale, il che vanificherebbe il senso della flessibilità del modello di Sessione, il nostro metodo propone un modo più efficiente per gestire i comunicatori senza sacrificare i vantaggi del modello di Sessione.

#Risultati Sperimentali

Per testare la nostra soluzione proposta, l'abbiamo integrata nella libreria Legio, che già implementa l'LDA. I nostri esperimenti hanno valutato l'impatto sulle prestazioni e sulla scalabilità utilizzando benchmark del mondo reale su un cluster.

Abbiamo eseguito vari test per confrontare tre scenari: la soluzione naive, il supporto dei Set di Orizzonte e configurazioni senza alcuna gestione dei guasti. I risultati hanno mostrato che l'approccio naive comportava costantemente più sovraccarico, specialmente man mano che aumentava la dimensione della rete. Al contrario, la soluzione dei Set di Orizzonte manteneva la scalabilità dell'applicazione senza richiedere l'inizializzazione globale di comunicatori non necessari.

Inoltre, abbiamo condotto test funzionali per dimostrare la resilienza del nostro approccio contro i guasti. Le applicazioni che hanno utilizzato la nostra soluzione sono riuscite a completare con successo, anche quando si sono verificati guasti durante l'esecuzione.

#Conclusione e Lavori Futuri

Attraverso la nostra analisi e implementazione, abbiamo dimostrato che è possibile gestire in modo efficace l'impatto dei guasti nelle applicazioni MPI utilizzando il modello di Sessione. L'introduzione dei Set di Orizzonte si è rivelata utile per ridurre i rischi di deadlock e migliorare la scalabilità.

Gli sforzi futuri probabilmente comporteranno l'integrazione del nostro approccio con altre proposte MPI, come il concetto di Bolle, e testare nuovi benchmark per esaminare ulteriormente le capacità del modello di Sessione in scenari variabili. Questo lavoro continuo mira a garantire che le applicazioni rimangano robuste ed efficienti, anche di fronte ai guasti.