Giuseppe Andronico 1 Marzo 2010 Riunione CCR Report Workshop MPI Giuseppe Andronico 1 Marzo 2010 Riunione CCR

Introduzione Message Passing Interface (MPI) è un modello di calcolo parallelo basato sulla comunicazione di nodi su una rete Più importante la latenza di rete che la larghezza di banda Molte comunità nel tempo hanno richiesto esplicitamente l’uso di MPI in GRID Principale richiesta INFN in CSN4, che dispone già di alcuni cluster MPI, alcuni integrati in grid tramite la VO theophys Nuovo cluster a Pisa, integrato in grid Wiki tecnico a Parma (http://www.fis.unipr.it/dokuwiki/doku.php?id=grid:mpi-theophys)

Survey Amministratori MPI-WG Survey utenti L’uso di MPI è in aumento in varie discipline ed ambiti Utilizzati: mpi-2, opnMP, mpi-1 Poche risorse su grid, mancanza di documentazione Survey Amministratori MPI sul BDII:EGEE 27%, Italia 50% (S. Pardi) Rete: Ethernet 70%, Infiniband 23% (EGEE) In Italia 3978 core collegati con Infiniband sugli 8048 Europei MPICH preponderante rispetto a MPI-2, maggiormente richiesto Installazione e configurazione semplice ma mal documentata Job MPI < 10%

GRID side Nuovi attributi per MPI SMPGranularity: numeri di core per nodo richiesti WholeNodes: logico, permette di riservare i nodi per intero JobType = MPICH viene sconsigliato I siti che supportano MPI pubblicano “Parallel” in GlueHostApplicationSoftwareRunTimeEnvironment Type = “Job” ; JobType = “Normal” ; CpuNumber = 8 ; MPIGranularity = 4 ;

Soluzioni: COMETA Soluzioni per l’ottimizzazione del supporto MPI a livello di MiddleWare (gLite) gestione integrata di flavour MPI e compilatori differenti controllo sull’allocazione dei cores tuning dell’environment sul WN pre/post execution per application Integrazione in EGEE supporto ufficiale in gLite, WMS 3.3 patch #2876 soluzioni di scheduling a livello di LRMS pre-emption core reservation backfill

Soluzioni: Mpi-start Incluso in gLite dalla 3.1 Individua e usa I batch scheduler presenti I flavour MPI presenti La distribuzione dei file, se le home non sono condivise (non molto testato) Pre e post esecuzione Configurazione demandata all’utente MPI-START e COMETA possono coesistere, sceglie l’utente

Altre raccomandazioni Ulteriori informazioni pubblicate nel sistema informativo (MPI flavour, version, path, home condivise, ssh, rete). P. es. il 57% dei siti che supportano MPI non hanno home condivise e i tag sul BDII non sono uniformi (S. Pardi) Anche i tag per INFINIBAND non uniformi Pacchettizzare e distribuire i vari pacchetti necessari SAM test per verificare piena funzionalità di MPI (corretta configurazione MPI-START, compilazione ed esecuzione su 2 CPU con OPENMPI, MPICH, MPICH2) Risolvere problema con CPU-time limit

LSF: Ottimizzazione dello scheduling Applicazioni HPC possono richiedere una frazione significativa di tutti i cores disponibili usando le classiche policy di scheduling FIFO l’attesa della disponibilità di cores nella maggior parte dei casi dura ben oltre la validità della proxy delegation registrazione a myproxyserver per renewal In COMETA sono state studiate e implementate soluzioni per LRMS (LSF) queue: pre-emption job a priorità inferiore posso essere sospesi temporaneamente saturazione della memoria checkpointing su context/switching coda emergency frequenza di sottomissione bassa e durata ragionevolmente breve sorveglianza/analisi inquinamento da cenere vulcanica

LSF: Ottimizzazione dello scheduling core reservation se non vi sono risorse sufficienti per eseguire un certo job parallello i cores disponibili al momento vengono riservati i cores riservati sono accumulati finchè non si soddisfano le richieste del job al fine di limitare il sottoutilizzo dei cores il periodo di reservation può essere limitato utilizzando MAX_RESERVE_TIME la coda HPC in COMETA è configurata con un valore pari a 30h i cores reserved da un job non possono essere utilizzati da nessun altro job degrado dell’utilizzo dei cores non significativo in uno scenario per cui | { jobs short} | >> | {jobs HPC} |

LSF: Ottimizzazione dello scheduling backfill i cores riservati da un job possono essere utilizzati solo per jobs aventi un run limit che scade prima dell’esecuzione (start-time) del job iniziale LSF calcola lo start time basandosi sui run limits dei jobs che girano sui cores reserved LSF non utilizza il backfill se un job attende le risorse di un job per cui non è stato definito alcun runlimit run limit generalmente assegnato dalla tipologia di coda short (15m), long (12h), infinite (21d), hpc (21d) Incremento dell’utilizzo dei cores significativo diversificare la coda HPC in base a run-limits differenti HPC_short, HPC_long, etc… etc… Monitoring dell’infrastruttura e tuning dinamico statistiche periodiche sulla distribuzione dei jobs

Politiche di sottomissione La scelta ed il tuning delle regole di sottomissione cruciale per il corretto uso delle risorse I due estremi: massimizzare l’uso (molti job sequenziali) precedenza assoluta a grossi job MPI (molti core liberi in attesa di un grosso job MPI) Non si può prescindere dall’analisi della comunità di riferimento. Soggetta a variazioni nel tempo: come ci si adatta?

Conclusioni La richiesta di MPI su GRID è ampia La comunità CSN4 con le sue richieste può aiutarci a rendere pienamente fruibile la soluzione Ancora diversi punti da sistemare Potremmo sviluppare una soluzione matura basata su use case concreti da proporre in ambito europeo