Riepilogo Tecnico: Superare i Colli di Bottiglia dell'Orchestrazione all'Exascale

Definizione del Problema

Il calcolo scientifico sta transitando da applicazioni monolitiche verso workflow accoppiati di Simulazione-IA (Sim-AI). Questi workflow consistono in task altamente eterogenei, che spaziano dall'inferenza seriale a breve durata (sub-secondaria) a simulazioni MPI multi-nodo a lunga durata (migliaia di secondi). Man mano che questi workflow scalano verso sistemi exascale di classe leadership (es. Aurora, Frontier), generano dimensioni di ensemble estreme (milioni di task concorrenti) e un'elevata varianza nella durata dei task.

Gli attuali approcci di orchestrazione affrontano due colli di bottiglia primari:

1. Scheduler di Sistema: Strumenti come Slurm e PBSPro sono ottimizzati per grandi allocazioni, ma faticano con l'estremo throughput richiesto da milioni di piccoli task dinamici, portando spesso a colli di bottiglia nella pianificazione (scheduling).
2. Strumenti di Workflow in Spazio Utente: Gli esistenti framework si affidano spesso a piani di controllo centralizzati che creano colli di bottiglia di serializzazione su larga scala. Sebbene esistano strumenti decentralizzati, molti mancano di supporto nativo per applicazioni MPI multi-nodo o impongono curve di apprendimento ripide. Inoltre, la maggior parte degli strumenti manca di interfacce di scheduling programmabili, impedendo ai ricercatori del dominio di iniettare le policy di runtime personalizzate necessarie per affrontare specifici colli di bottiglia del workflow.

Metodologia: EnsembleLauncher

Per affrontare queste sfide, gli autori hanno sviluppato EnsembleLauncher, un orchestratore di workflow ricorsivamente gerarchico progettato per ensemble Sim-AI exascale.

Design Architetturale

EnsembleLauncher impiega un piano di controllo completamente decentralizzato strutturato come un albero ricorsivo:

• Manager: Gestiscono i sottotree (Global Manager come radice, Sub-Manager come nodi intermedi). Gestiscono il routing dei task a grana grossa e la partizione delle risorse.
• Launcher: Fungono da nodi foglia e motori di esecuzione primari. Gestiscono l'ordinamento e l'esecuzione dei task a grana fine.
• Modalità Ibrida Push-Pull: Il sistema supporta un'architettura ibrida in cui i livelli superiori utilizzano la Partizione Statica (Push) per minimizzare la comunicazione nel piano di controllo, mentre i livelli foglia utilizzano il Bilanciamento del Carico Dinamico (Pull) per mitigare la skew (distorsione) del tempo di esecuzione tramite work-stealing.

Componenti Core

• Interfaccia di Scheduling Programmabile: Il sistema espone interfacce di policy a due livelli:
  • Children Scheduler (Livello Manager): Determina il routing dei task e la partizione delle risorse ($S_{i+1} = f(S_i, T, N, d)$).
  • Task Scheduler (Livello Launcher): Determina l'ordinamento dei task nella coda di dispatch ($P = f(T, S)$).
  • Queste interfacce permettono agli utenti di implementare euristiche personalizzate (es. FIFO, Shortest First, Largest First) senza modificare l'orchestratore core.
• Astrazione dell'Executor: Uno strato stateless che decupla lo stato dell'orchestrazione dai meccanismi di esecuzione, supportando pool di processi Python, pool di thread e pool di processi MPI. Ciò consente il co-scheduling di task seriali e task MPI.
• Tolleranza ai Guasti: Ogni orchestratore mantiene un local checkpointer. I guasti attivano la demolizione e il riavvio localizzati del sottotree interessato, con meccanismi di heartbeat che rilevano i figli non rispondenti.

Setup di Valutazione

Gli esperimenti sono stati condotti sul supercomputer Aurora (10.624 nodi, Intel Xeon Max CPU, Intel Data Center GPU). La valutazione ha confrontato EnsembleLauncher con strumenti allo stato dell'arte (Dask, Parsl) e un baseline MPI nativo attraverso:

• Micro-benchmark: Throughput e latenza su singolo nodo.
• Test di Scalabilità: Weak scaling (carico di lavoro proporzionale ai nodi) e strong scaling (carico di lavoro fisso, aumento dei nodi) fino a 8.192 nodi.
• Sensibilità della Policy: Analisi dell'impatto della topologia del piano di controllo e dell'effetto delle policy di scheduling su carichi di lavoro eterogenei.

Risultati Chiave

1. Scalabilità e Throughput

• Scalabilità Exascale: EnsembleLauncher è riuscito a scalare fino a 8.192 nodi con 8 milioni di task seriali.
• Guadagno di Performance: Ha superato gli strumenti allo stato dell'arte (Parsl e Dask) di oltre 4 volte a 2.048 nodi, anche per task di lunga durata (60s).
• Topologia vs Implementazione: Esperimenti controllati hanno dimostrato che la topologia del piano di controllo è il determinante primario del throughput, non l'implementazione specifica del framework. Quando Dask e Parsl sono stati configurati con la stessa gerarchia a singolo livello, hanno mostrato un comportamento di scalabilità e punti di fallimento quasi identici.
• Vantaggio Gerarchico: Una gerarchia a due livelli (Depth=2) in EnsembleLauncher ha eliminato la saturazione del piano di controllo che affamava i worker nelle configurazioni a singolo livello, mantenendo una scalabilità forte quasi ideale.

2. Latenza

• Latenza di Dispatch: Nei test su singolo nodo, EnsembleLauncher ha raggiunto una latenza round-trip mediana di 3ms (solo Launcher) e 4ms (Manager-Launcher). Questo è significativamente inferiore a Dask (10ms) e rimane ben al di sotto della durata dei tipici task di inferenza Sim-AI (decine o centinaia di millisecondi).
• Overhead: Sebbene ogni livello gerarchico aggiunga circa 1ms di latenza, questo overhead è trascurabile rispetto al tempo di esecuzione dei task scientifici.

3. Impatto delle Policy di Scheduling

• Workload Eterogenei: In esperimenti con un "bag-of-tasks" caratterizzato da un'alta varianza in durata e requisiti di risorse, le policy Largest First e Longest First hanno ridotto significativamente il tempo totale di esecuzione rispetto a FIFO all'aumentare della varianza.
• Pipeline Sim-AI: In un prototipo di workflow MOFA, una policy di routing Adattiva (instradamento dinamico verso i figli meno carichi) ha ottenuto un utilizzo della GPU 2 volte superiore e tempi di esecuzione più brevi rispetto alle policy a partizione statica o uniforme. La partizione statica ha causato colli di bottiglia in cui i task seriali saturavano nodi specifici, bloccando le fasi successive della pipeline.

Significato e Claim

Il paper sostiene che EnsembleLauncher supera efficacemente i colli di bottiglia dell'orchestrazione nei workflow Sim-AI exascale spostando il paradigma architettonico da un controllo centralizzato a un modello decentralizzato, ricorsivamente gerarchico.

I contributi chiave includono:

1. Dimostrazione della Dominanza della Topologia: Dimostrare che la topologia del piano di controllo è il fattore critico per la scalabilità, non il linguaggio di implementazione sottostante o l'algoritmo specifico dello scheduler.
2. Scalabilità: Raggiungere un throughput su 8.192 nodi che supera di un fattore quattro gli strumenti allo stato dell'arte, consentendo l'esecuzione di ensemble fino a 8 milioni di task.
3. Programmabilità: Fornire un'interfaccia programmabile che permette ai ricercatori del dominio di personalizzare le policy di scheduling e routing in base alle caratteristiche del carico di lavoro (es. alta varianza, task misti MPI/seriali) senza modificare il codice dell'orchestratore.
4. Co-Scheduling: Integrare con successo l'esecuzione di task di inferenza seriali granulari e massicce simulazioni MPI multi-nodo all'interno di un singolo workflow.

Gli autori concludono che, sebbene 8.192 nodi rappresenti l'allocazione massima su Aurora, il design del sistema suggerisce che questa non sia il limite di scalabilità di EnsembleLauncher. Il lavoro futuro mira a integrare interfacce Model Context Protocol (MCP) per workflow agentici guidati da LLM ed esplorare policy di scheduling basate su IA che adattino le euristiche a runtime.