GUIDA ALL'USO DI POSEIDON (CLUSTER OPTERON)

Poseidon (poseidon.caspur.it) è un cluster Linux basato su processori AMD Opteron single e dual core. Il cluster è composto da un front-end, aperto all'uso interattivo per le attività di sviluppo e preparazione dei job, e dai nodi di calcolo riservati all'elaborazione batch. I nodi di calcolo sono suddivisi in 3 partizioni: una con semplice interconnessione gigabit ethernet (nodi slacs), le altre due con interconnessione Infiniband ad alte prestazioni (nodi inode e dcore), dedicati a job paralleli. Nel dettaglio:

• slacs: composta da 24 nodi, ciascuno con 2 processori AMD Opteron 246 single-core e 4 GB RAM;
• inode: composta da 24 nodi, ciascuno con 2 processori AMD Opteron 250 single-core e 4 GB RAM;
• dcore: composta da 24 nodi, ciascuno con 2 processori AMD Opteron 280 dual-conre e 8 GB RAM;

A seconda delle risorse richieste, il sistema di code selezionerà la partizione del cluster su cui indirizzare il vostro job (maggiori dettagli in Modalità Batch e Sistema di Code). L'interprete di comandi di default è la tcsh. L'ambiente di questa shell è automaticamente configurato in modo opportuno per utilizzare il sistema.

L'ambiente di lavoro è gestito mediante moduli, come descritto nella sezione Moduli e Ambiente.

E' possibile consultare un breve help in linea del sistema, digitando il comando "ClusterHelp". Oltre alle informazioni riportate in questa guida, troverete anche un elenco di indirizzi utili per il supporto.

L'accesso interattivo al sistema è consentito sul front-end poseidon.caspur.it tramite connessione sicura ssh. E' possibile connettersi al sistema con il comando:

dove username corrisponde al vostro username fornitovi dal CASPUR. L'opzione -X consente di ridirigere eventuali applicazioni grafiche sullo schermo della vostra postazione di lavoro (da utilizzarsi in caso riceviate un errore del tipo "Error: Can't open display:".

Gli altri nodi del cluster sono chiusi all'accesso dell'utenza. L'uso interattivo è riservato alle attività ordinarie di sviluppo, di sottomissione di batch job, di controllo dell'andamento delle stesse, di visualizzazione e limitate elaborazioni dei dati prodotti. A tale scopo, e per evitare sovraccarichi del nodo, tutti i processi sono limitati ad un CPU time di 20 minuti. Un processo che raggiunga tale limite sarà automaticamente terminato. Il limite non impedisce lo svolgimento delle attività ordinarie, che consistono nell'uso di sequenze di processi brevi o di applicazioni che fanno uso molto limitato di CPU.

L'ambiente di lavoro (shell environment) è gestito mediante l'utilizzo di moduli. I moduli sono dei file contenenti istruzioni per la configurazione di un ambiente di lavoro, ossia per la definizione o la modifica di variabili di ambiente della shell (ad esempio le variabili PATH, LD_LIBRARY_PATH, ecc) su cui state lavorando. La gestione dei moduli avviene tramite il tool Environment-module.

Digitando il comando module, vi verranno elencati i possibili comandi (o azioni) che può intraprendere. Tra le principali, ricordiamo:

• per mostrare l'elenco dei moduli attualmente caricati e in uso nella vostra shell:

  module list

• per mostrare l'elenco dei moduli disponibili sul sistema:

  module avail 

• per caricare il modulo chiamato "nomemodulo"

  module load nomemodulo 

• per rimuovere il modulo chiamato "nomemodulo"

  module unload nomemodulo 

• per ottenere una descrizione e informazioni sul modulo chiamato "nomemodulo":

  module show nomemodul

Al login, nessuno dei moduli è caricato automaticamente. Per utilizzare i compilatori dovrete caricare i moduli corrispondenti.

Per maggiori informazioni sull'utilizzo dei moduli potete consultare le pagine man (module(1) e modulefile(4)).

Il front-end poseidon può essere utilizzato come piattaforma di sviluppo e debugging di applicazioni (solo serial o shared-memory, non MPI). Sul sistema sono disponibili i compilatori della suite GNU, Intel e PGI, sia per FORTRAN che C/C++, nonchè il TotalView debugger. Per utilizzare i compilatori disponibili dovrete caricare il modulo corrispondente.

Ogni applicazione compilata con i compilatori Intel o PGI dovrà essere eseguita in un ambiente con i moduli corrispettivi caricati.

Per compilare programmi paralleli basati su MPI, dovrete caricare, nell'ordine, uno dei compilatori e uno dei modulo MPI disponibili sul sistema. I moduli MPI renderanno disponibile alla linea di comando i compilatori paralleli mpicc e mpif90 e l'MPI starter mpiexec.

I comandi mpicc e mpif90 sono in realtà dei wrapper ai compilatori base prescelti, che contengono opzioni opportune per compilare e linkare il programma parallelo con lo specifico modulo MPI. Non sarà dunque necessario aggiungere o indicare in fase di compilazione e linking, riferimenti agli header o alle librerie mpi in uso.

Per eseguire un programma parallelo si usa il comando:

mpiexec -n N /path/to/your/parallel/executable/my_parallel.x args

dove con -n N si indica il numero N di processi paralleli. Se non indicato, il programma verrà eseguito automaticamente facendo uso di tutti i processori disponibili assegnati dal sistema di code.

• openmpi: adatto per interconnessione InfiniBand e gigabit ethernet;
• mvapich: solo InfiniBand;
• mpich: solo gigabit ethernet.

L'utilizzo del modulo openmpi garantisce che il proprio eseguibile potrà girare senza problemi sia sulla partizione slacs (rete gigabit ethernet) sia sulle partizioni inode e dcode (rete alte prestazioni InfiniBand): in questo modo il driver di comunicazione appropiato verrà scelto a runtime.

Con l'utilizzo dei moduli mvapich o mpich non sarà possibile eseguire il codice, rispettivamente, nella partizione con interconnessione gigabit o Infiniband: per ovviare a questo problema, potete usare il modulo openmpi oppure compilare due eseguibili (uno con mvapich, l'altro con mpich ed utilizzare lo script di sottomissione in /opt//PBSSampleScripts/parallel-dynamic.sh che selezionerà l'eseguibile da girare a seconda della partizione in cui il sistema di code ha allocato il job).

Una volta compilato il codice parallelo, per eseguirlo, dovranno essere sempre cariti gli stessi moduli del compilatore e di MPI utilizzati per la compilazione. Ricordarsi quindi di inserire le opportune istruzioni module load compiler_mod mpi_mod negli script di sottomissione dei job in modalità batch (vedi Modalità Batch e Sistema di Code).

Nella directory /opt/ sono presenti varie librerie matematiche, tra cui le FFTW3, le ScaLAPACK, le GotoBLAS, le ACML (AMD) e MKL (Intel) che forniscono versioni ottimizzate delle librerie BLAS, LAPACK, FFT, etc... Per maggiori informazioni, fate riferimento ai manuali contenuti nella sottodirectory doc/ di ciascuna libreria.

Ogni libreria è stata compilata per ognuno dei compilatori disponibili e va quindi selezionata la libreria dalla sottodirectory con il nome del compilatore in uso. Ad esempio, se si sta utilizzando il compilatore pgi, per linkare le ACML bisognerà fare riferimento alla directory /opt/acml/pgi64/lib e usare le seguenti opzioni di linking -L/opt/acml/pgi64/lib -lacml -lacml_mv oppure, per se si sta utilizzando il compilatore intel e si vuole linkare le FFTW3 si farà riferimento alla directory /opt/fftw3/intel/lib/, utilizzando le seguenti opzioni di linking -L/opt/fftw3/intel/lib/ -lfftw3 .

L'accesso alle risorse di calcolo del cluster avviente tramite un sistema di code. L'utente dovrà preparare uno script che descrive il lavoro (job) che dovrà essere eseguito in automatico dai nodi di calcolo (modalità batch).

L'utente dovrà sottomettere lo script al sistema di code che, a seconda delle risorse richieste dall'utente (numero di CPU, tempo di calcolo richiesto dal job, etc), riserverà le risorse di calcolo in modo opportuno per essere eseguito.

Per sottomettere al sistema di code lo script myscript.sh si usa il comando:

qsub -l risorse myscript.sh

Se la sottomissione è corretta, il sistema assegna un numero, detto job_id, alla vostra richiesta. Questa numero identificativo può essere utilizzato per controllare lo stato del job (vedi Controllo dei Job).

Nella directory /opt/PBSSampleScripts/ abbiamo raccolto alcuni esempi di script di sottomissione per job di tipo seriali e paralleli.

Le "risorse" possono essere di tipo hardware (ad esempio il numero o tipologia dei nodi, numero di CPU, tipo di interconnessione) oppure di tipo temporale (ad esempio, quanto tempo di calcolo serve per terminare il vostro job). E' possibile specificare combinazioni di più risorse hardware (separate da ":") e temporali (separate da ","), ad esempio il comando:

Di seguito riportiamo un elenco delle sintassi per le richieste di risorse più comuni:

• nodes=N in questa formulazione il numero N corrisponde al numero di CPUs totali richieste per il vostro lavoro, e si lascia al sistema di code di scegliere su quali nodi attingere queste CPU;
• nodes=N:ppn=m in questa formulazione invece si richiede un numero N di nodi ciascuno con m CPU, per un totale di Nxm CPUs. Se si specifica m=4 si forza il sistema di code a chiedere accesso alla partizione dcore, avente nodi con 4 core;
• nodes=N:ppn=m:ib in questo modo, oltre al numero di nodi e processori per nodo, si specifica che si vuole utilizzare nodi interconnessi con tecnologia InfiniBand. In tal modo il lavoro verrà indirizzato nelle partizioni inode o dcore;
• walltime=hh:mm:ss: serve a specificare il tempo di calcolo da riservare al vostro job. Se non specificato, verrà assegnata 1 sola ora;

ATTENZIONE: se non viene specificata l'interconnessione InfiniBand con la specifica di risorsa :ib, il sistema di code si riserva di decidere in quale partizione far girare il vostro lavoro e non sarà dunque garantito l'uso della rete ad alte prestazioni.

Le risorse del sistema sono organizzate in code di esecuzione, o brevemente code, a seconda della tipologia di utilizzo che se ne vuole fare. Sul sistema sono definite le seguenti code:

• mpp_ib: questa coda è riservata a job paralleli con un numero minimo di 8 CPUs in tecnologia di interconnessione ad alte prestazioni Infiniband. Su questa coda c'è un limite di risorse tale per cui il prodotto tra il numero di CPU richieste e il tempo richiesto deve essere minore o uguale a 128 ore: ad esempio, sarà possibile utilizzare questa coda chiedendo 32 CPUs per 4 ore, oppure 16 CPUs per 8 ore o ancora 8 CPUs per 16 ore;
• mpp: questa coda è riservata per job paralleli con un numero di CPUs compreso tra 2 e 8. Se non viene specificata la tipologia di interconnessione, il sistema di code potrà indirizzare il job a girare sia nella partizione slacs (in gigabit ethernet) o sulle partizioni inode e dcore in tecnologia Infiniband;
• smp: questa coda è dedicata a job serial o shared memory;
• debug: questa coda è dedicata al debugging di applicazioni seriali o parallele (max 8 CPUs) per un tempo massimo di 1 ora;

E' possibile specificare in quale coda si desidera indirizzare il proprio lavoro, tramite l'opzione di qsub "-q nome_coda". Se la coda non viene specificata, il sistema indirizzerà il vostro job sulla coda che soddisfa al minimo le vostre richieste di risorse. Ad esempio, facendo riferimento alla tabella riassuntiva, con il comando:

qsub -l nodes=2:ppn=2 myscript.sh

non specificando il tempo richiesto per il job, il sistema di code assegna al job 1 ora di esecuzione (vedi specifica di risorsa walltime) e indirizzerà il job sulla coda debug.

Il controllo dei job si effettua per mezzo del comando qstat. L'opzione -u username consente di mostrare lo stato dei job relativi all'utenza desiderata. Per maggiori informazioni e opzioni si consiglia di leggere il manuale di qstat, con il comado man qstat.

Job id              Name             User            Time Use S Queue
------------------- ---------------- --------------- -------- - -----
94986.poseidon      csp8Gb.sh        utente          0        Q smp
100621.poseidon     dmc_F-17         utente          28:46:44 R mpp_ib

Nell'esempio riportato si vede che l'utente "utente" ha sottomesso 2 job, il primo con identificativo 94986 e nome "csp8Gb.sh" attualmente in attesa di partire nella coda smp, il secondo con identivicativo 100621 e nome "dmc_F-17" che sta girando sulla coda mpp_ib.

E' possibile avere una visione globale dello stato dell'intero cluster e dei vostri job, tramite il comando pbstop: si tratta di un tool molto simile a top e mostra in dettaglio lo stato di occupazione dei nodi, nonché fornisce un controllo sui propri job (vedi il manuale di pbstop tramite man pbstop o accedendo all'help premendo il tasto "h" da dentro il programma).

Per avere informazioni sullo stato di un job, ad esempio capire a quale coda verrà assegnato o tra quanto tempo si prevede possa essere eseguito, si usano i comandi checkjob job_id e showstart job_id.

Per cancellare un job si utilizza il comando qdel job_id.

La directory /home è su un file system distribuito NFS, visibile e accessibile a tutti i nodi di calcolo del cluster. Si presta primariamente alle attività che coinvolgono file di dimensioni contenute, come le normali attività di sviluppo, ma non si presta ad ospitare file di grandi dimensioni, né ad attività di input/output (I/O) intensivo.

Su ogni nodo è disponibile un file system /scratch, utilizzabile come area di lavoro temporanea. Tale area è locale ad ogni singolo nodo del sistema, quindi ogni nodo ha la sua area e non sono visibili e condivise tra loro. Queste aree di lavoro possono essere utilizzate per job che fanno input/output (I/O) intensivo su job seriali o su job paralleli per i quali ogni processo deve scrivere file indipendenti. Le aree /scratch locali ad ogni nodo sono accessibili dal front-end (in sola lettura) attraverso la directory /cluster.scratch, suddivisa per ogni partizione e nodo. Le aree /scratch sono soggette a pulizia periodica dei file più vecchi, perciò si consiglia di recuperare i file di interesse ed eventualmente (se importanti o di grosse dimensioni) salvarli nell'area /stage.

La directory /stage è in realtà un sistema di archiviazione su nastro di dati che al momento non sono necessari in linea, utile allo scopo di liberare la proprie aree disco per far spazio a dati da produrre con nuove elaborazioni. Per l'uso di tale area si rimanda alla documentazione relativa.