Metodi per la condivisione tra batch e interattivo

Metodi per la condivisione
tra batch e interattivo
Mirko Corosu (INFN-GENOVA)
Riunione CCR 07 Luglio 2010
Sommario
 Breve
descrizione della problematica
 Soluzioni di integrazione delle CPU
– Soluzione statica
– Soluzione mista
– Soluzione interactive-jobs
– Soluzione load-average based
– Soluzione UI on demand
Breve descrizione della
problematica
Attivita’ di calcolo su T3



Simulazioni di piccoli campioni di eventi di segnale e
di fondo per il processo di interesse
Analisi finale degli eventi reali selezionati da
preprocessing su T0,T1 e T2
Coesistenza di diversi modelli di calcolo:
– Interattivo:
 Sviluppo e test rapido di codice in maniera interattiva
– Batch:
 Test intensivo del codice via batch system locale
– Grid (come opzione)
 Test preliminare sul nodo GRID locale
 Invio di produzioni private o di gruppo sulla GRID
Obiettivi

Funzionalita’
– L’interattivo deve avere risorse disponibili in tempi
molto brevi

Flessibilita’ di utilizzo delle risorse
– Il rapporto tra le risorse utilizzate dal batch e quelle
utilizzate dall’interattivo cambia a seconda delle
necessita' contingenti degli utenti
– Il corretto dimensionamento preventivo di una facility
per l’interattivo e’ complicato

Ottimizzazione dell’efficienza:
– Massimizzazione dell’utilizzo delle CPU

Ottimizzazione del lavoro di gestione
– Omogeneizzione dei sistemi
Integrazione delle CPU
Soluzione statica




Le macchine per l’interattivo e quelle per il batch
sono distinte
Nessun meccanismo di trasferimento delle
risorse interattivo <-> batch
Soluzione percorribile quando il carico massimo
del lavoro interattivo e’ pianificabile
Pro:
– Semplicita’ di implementazione
– Funzionalita’ dell’interattivo garantita (dimensionando
le risorse sul massimo utilizzo teorico)

Contro:
– Probabilita’ di sottoutilizzo delle risorse
– Due cluster distinti da gestire (di norma le macchine
per l’interattivo hanno una configurazione differente)
Soluzione Statica – esempio di
implementazione
 Facility
di calcolo INFN-TRIESTE:
– Non e’ Tier3 “ufficiale” ma di fatto offre
risorse di calcolo batch e interattive
– 60 nodi di calcolo dei quali:
 51 nodi batch
 2 CE Grid
 1 LSF Master
 4 Nodi per l’interattivo dedicati a singoli esperimenti
 2 Nodi per l’interattivo generici
Soluzione Mista



I nodi per l’interattivo e quelli per il batch sono
distinti
Viene implementato un meccanismo che, sulla base
di necessita’ contingenti (pianificate con un certo
anticipo), sposta risorse verso l’una o l’altra
modalita’ di accesso
Pro:
–
–
–

Flessibilita’ maggiore rispetto al caso totalmente statico
Funzionalita’ dell’interattivo garantita
Si adatta meglio di altre soluzioni a Tier 3 stand-alone
(non integrati in facility piu’ grandi)
Contro:
– Intervento manuale necessario per traferire le risorse
– Necessaria l’implementazione del meccanismo che
modifica le configurazioni dei sistemi
Soluzione Mista – possibile
implementazione


Tutte le macchine di calcolo vengono installate e
configurate allo stesso modo, tutte entrano a far parte del
cluster batch
Alcune di esse vengono escluse dalla sottomissione di job
via batch system:
– Ad esempio: 1 UI public login PROOF/ROOT + Worker PROOF



Viene implementata una interfaccia Web che permette
(previa autenticazione) di cambiare le configurazioni di
PROOF e del batch system, assegnando macchine all’uno
o all’altro cluster
Lo spostamento di risorse avviene in un tempo tale da
permettere ai rispettivi task di terminare naturalmente
L’idea e’ quella di permettere l’utilizzo dell’interfaccia ad
un “responsabile” di gruppo che, previa pianificazione del
lavoro di analisi, decide l’assegnazione delle risorse
Soluzione Interactive-jobs


Si tratta di sfruttare la possibilita’ che viene
offerta da alcuni batch system (Torque/Maui ed
LSF sicuramente) di sottomettere sui WN un job
in modalita’ interattiva.
Pro
– Garantisce l’allocazione di una CPU riservata utente per
tutta la durata della sessione
– Permette una estrema flessibilita’ nell’allocazione delle
risorse
– Ottimizza il lavoro di gestione delle installazioni e
configurazioni (necessita’ di un solo cluster)

Contro
– Non e’ ovvio configurare il sistema in modo che il job
interattivo venga messo in esecuzione in un tempo
ragionevolmente breve
– Non si adatta alla perfezione ad un cluster di piccole
dimensioni, dove la percentuale di slot liberate
nell’unita’ di tempo e’ piu’ bassa
Soluzione Interactive-jobs – un
esempio (INFN-BARI)

La configurazione di Torque-Maui viene
modificata per permettere al job interattivo di
avere una alta priorita’
– Viene utilizzato un demone (scritto dagli
amministratori) per assicurare che il tempo di attesa in
coda di un job interattivo non raggiunga il minuto



I job interattivi possono essere sospesi con il
comando “screen”
Possono essere lanciati job interattivi “multi
CPU” (ad esempio PROOF)
Non e’ configurato un limite fisso per le sessioni
interattive
Soluzione Interactive-jobs – un
esempo (INFN-BARI)
UI on demand
 Sottomissione
automatica di una o piu’ UI
virtuali per la gestione dell’interattivo.
 Stessi pro e contro dell’interactive-job piu’:
 Pro:
– L’interattivo viene limitato sia in termini di
CPU che in termini di memoria
 Contro:
– Puo’ essere complicato gestire job interattivi
multicore
Conclusioni e spunti



Il lavoro da fare sull’integrazine tra batch e
interattivo e’ in molti casi appena all’inizio
La panoramica presentata non e’ esaustiva ed e’
largamente integrabile da esperienze o idee di
chi attualmente lavora su questo tema
Puo’ essere utile un confronto tecnico tra gli
addetti ai lavori (magari lasciando il tempo di
concretizzare almeno parzialmente i progetti di
chi ancora non ha implementato una soluzione)
Ringraziamenti
 Giacinto
Donvito (INFN-BARI)
 Lucio Strizzolo (INFN-TRIESTE)
Grazie dell’attenzione