GUIDA ALL'USO DEL CLUSTER POWER 5

Il cluster IBM Power 5 è composto di 21 nodi. Un nodo è aperto all'uso interattivo per attività di sviluppo, due nodi svolgono le funzioni di server del file system GPFS, i restanti diciotto nodi sono riservati all'elaborazione batch.
Tutti i nodi sono dotati di 8 processori Power 5 ad 1.9 GHz. Quattro nodi (tra i quali quello aperto all'uso interattivo) sono dotati di 32 GB di RAM, i restanti di 16 GB di RAM. La quantità di RAM effettivamente disponibile ai processi utente è rispettivamente di 30 e 14 GB circa.
I nodi sono interconnessi, per il calcolo parallelo, da una rete ad alta velocità basata su uno switch IBM HPS.

L'accesso interattivo al sistema è consentito sul nodo man.caspur.it (alias del nodo pwr503). L'accesso è consentito esclusivamente tramite ssh. Gli altri nodi del cluster sono chiusi all'accesso dell'utenza.
L'interprete di comandi di default è la tcsh. L'ambiente di questa shell è automaticamente configurato in modo opportuno per utilizzare il sistema. È sempre possibile utilizzare altre shell richiamandole da quella di default in modo che ereditino una configurazione corretta dell'ambiente.
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.

La home directory è su un file system distribuito AFS, accessibile anche dagli altri sistemi CASPUR. Per informazioni sulle funzionalità ed implicazioni dell'uso di AFS (tra cui in particolare le modalità di cambio della password), si rimanda alla documentazione relativa.
L'area AFS 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 I/O intensivo.

La directory /data contiene una sottodirectory per ogni gruppo UNIX definito sui sistemi di calcolo CASPUR. Tali directory si trovano su file server NFS e sono visibili da tutti i nodi interattivi e di calcolo. Ogni utente può creare una o più sottodirectory sotto quella corrispondente al proprio gruppo UNIX.
È il file system più idoneo ad ospitare file di grandi dimensioni ai quali si voglia accedere da differenti piattaforme.

Sotto la directory /gpfs, tutti i nodi del cluster hanno accesso ad un file system condiviso ad alta velocità, di tipo IBM GPFS (General Parallel File System). Questo file system, concepito per I/O intensivo da applicazioni parallele, è il più indicato per ospitare file di grosse dimensioni, e come area di lavoro per applicazioni.parallele che debbano condividere i dati tra più nodi.

Su ogni nodo è disponibile un file system locale, sotto la directory /scratch, utilizzabile come area di lavoro per applicazioni seriali, o per applicazioni parallele che non richiedano la condivisione di dati tra più nodi.
ATTENZIONE: le aree /scratch devono essere liberate al termine dell'applicazione, sia nel caso di attività interattiva che di batch job. I file abbandonati in tali aree potranno essere rimossi, manualmente o automaticamente, senza preavviso. I dati che si desidera conservare vanno spostati sotto uno degli altri file system.

Il file system /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.

Sul sistema sono disponibili i compilatori Fortran 77 (xlf), Fortran 90 (xlf90), Fortran 95 (xlf95), C (xlc) e C++ (xlC).
Per ottenere livelli di prestazione adeguati, si consiglia di includere tra le opzioni di compilazione, oltre al livello di ottimizzazione opportuno (-On), le opzioni -qarch=pwr5 -qtune=pwr5.
Per default, compilazione e linking avvengono in modalità 64 bit. Se per ragioni di portabilità di un sorgente o di compatibilità con librerie da utilizzare è necessario compilare e linkare in modalità a 32 bit, sarà necessario specificare rispettivamente le opzioni -q32 e -b32.

La compilazione di applicazioni parallele MPI va effettuata con i comandi mpxlf, mpxlf90, mpxlf95, mpcc, mpCC, che automatizzano il linking delle librerie pertinenti.
La compilazione di applicazioni parallele OpenMP va effettuata utilizzando i compilatori seriali, specificando l'opzione -qsmp=omp.
La compilazione di applicazioni miste MPI+OpenMP va effettuata utilizzando dei compilatori per MPI, specificando l'opzione -qsmp=omp.

Digitando il comando di compilazione senza opzioni verrà visualizzata la man page relativa. Per informazioni più dettagliate si rimanda alla documentazione in linea.

L'elaborazione batch avviene tramite il sistema di code SGE (Sun Grid Engine) della Sun Microsystems.

Ogni job deve essere sottomesso al sistema di code SGE sotto forma di uno shell script:

#!/bin/tcsh
cd myproject/mybinaries
./myprogram -input mydata.dat -output myjob.out

La directory di lavoro di un job è normalmente quella di sottomissione, ma può essere cambiata a piacimento all'interno dello script.
Standard output e standard error del job saranno riportati in appositi file nella directory di sottomissione dello stesso. Due email avviseranno dell'avvio e del completamento del job.

I job devono essere sottomessi con il comando qsub:

<user@pwr503 ~>qsub -l h_rt=9:00:00 myjob.csh
your job 13 ("myjob.csh") has been submitted

Sul cluster sono definiti alcuni ambienti di esecuzione (parallel environment), utilizzati per specificare correttamente il tipo di esecuzione desiderata:

La durata standard dei job è di 10 ore. Alcuni nodi (per un massimo di 40 CPU) consentono l'esecuzione di job di durata massima pari a 20 ore. È possibile sottomettere job di durata massima pari a 48 ore, ma questi saranno eseguibili solo nel fine settimana.

ATTENZIONE:
È importante specificare la durata del job con l'opzione -l h_rt=HH:MM:SS per definire il tempo solare necessario all'esecuzione, altrimenti verrà aggiunta implicitamente l'opzione -l h_rt=10:00:00. In particolare, i job nell'ambiente test non saranno eseguibili se non si specifica una durata massima di 30 minuti.
È necessario per la corretta esecuzione dei job che non vengano eseguiti comandi di manipolazione del terminale, come stty. Se tali comandi fossero presenti nei file personali di configurazione della shell (come .cshrc o .tcshrc), è necessario inibirne l'esecuzione sotto code batch con un test:

if ( ! $?ENVIRONMENT ) then
comandi
endif.

Per maggiori dettagli sui comandi di sottomissione e controllo si rimanda alle man page in linea, accessibili tramite man nome_del_comando.

Elaborazioni sottomesse senza specificare nessun ambiente parallelo di esecuzione saranno eseguite serialmente su una CPU. L'esecuzione di job seriali è limitata alle ore serali e notturne (dalle 18 in poi) ed al fine settimana. Il numero massimo di job seriali eseguibili contemporaneamente è limitato.

Job OpenMP o shared memory vanno sottomessi specificando l'ambiente sm (o smlarge per richieste complessive di memoria superiori a 14 GB).
È disponibile uno script di utilità per configurare correttamente l'ambiente di esecuzione OpenMP nel modo più comunemente usato. La configurazione della dimensione degli stack associati ai vari thread è responsabilità dell'utente.
Lo script di sottomissione:

#!/bin/tcsh -f
#automatic OpenMP configuration
source /sge/sp5/common/sge_ompsetup.csh
#OpenMP per thread stack size
setenv XLSMPOPTS 'stack=64000000'
#my settings
setenv MY_VARIABLE my_value
./myOpenMPprogram -my_options ...

può essere sottomesso col comando:

<user@pwr503 ~>qsub -pe sm 6 -l h_rt=9:00:00 myjob.csh
your job 13 ("myjob.csh") has been submitted

Nel caso si renda necessario configurare diversamente l'ambiente di esecuzione OpenMP, è possibile modificare i valori delle variabili relative, dopo l'inclusione di sge_ompsetup.csh.

Job MPI vanno sottomessi specificando l'ambiente mp. La memoria massima utilizzabile per ogni singolo processo MPI è di circa 1.7 GB.
I job MPI che richiedano più di 8 CPU devono obbligatoriamente richiederle in multipli di 8, altrimenti verranno rifiutati dal sistema.
È disponibile uno script di utilità per configurare correttamente l'ambiente di esecuzione MPI nel modo più comunemente usato. In particolare, tale script utilizza l'host-file automaticamente generato dal sistema di code.
Lo script di sottomissione:

#!/bin/tcsh -f
#automatic MPI configuration
source /sge/sp5/common/sge_mpisetup.csh
#my settings
setenv MY_VARIABLE my_value
poe myMPIprogram -my_options ...

può essere sottomesso col comando:

<user@pwr503 ~>qsub -pe mp 32 -l h_rt=40:00:00 myjob.csh
your job 13 ("myjob.csh") has been submitted

Nel caso si renda necessario configurare diversamente l'ambiente di esecuzione MPI, è possibile modificare i valori delle variabili relative, dopo l'inclusione di sge_mpisetup.csh. Per esempio, per utilizzare un numero di processori superiore ad 8 ma non multiplo di 8, ad esempio 20, sarà necessario richiedere l'uso di 24 CPU e nello script di esecuzione modificare a 20 il valore della variabile di ambiente MP_PROCS prima dell'esecuzione del programma parallelo. Analoghe modifiche si renderanno necessarie per applicazioni miste MPI+OpenMP, che richiedono una combinazione opportuna delle configurazioni dei due sistemi di parallelismo.

ATTENZIONE:
Per nessun motivo si deve specificare un host-file differente da quello fornito automaticamente dal sistema di code. Job che facciano questo verranno rimossi dal sistema senza preavviso.
Il limite teorico di processi utilizzabili in un singolo job MPI è pari al numero di CPU disponibili al sistema di code batch. Ovviamente, maggiore il numero di CPU richieste, maggiore sarà la difficoltà che il sistema incontrerà nello scheduling del job.
È possibile che la sottomissione di job MPI sul cluster provochi la comparsa, nel file di output o di standard error, di uno o più messaggi di questo tipo:

ERROR: 0031-123 Retrying allocation .... press control-C to terminate

Il messaggio è generato dal Resource Manager dello switch HPS, ed è causato da un ritardo nella liberazione delle risorse associate ad un job precedente. Nella maggior parte dei casi può essere ignorato.

Il controllo dei job si effettua per mezzo del comando qstat. L'opzione -f offre una visione globale delle code del cluster.

<utente@pwr503 ~>qstat
job-ID prior name     user    state submit/start at     queue   master
----------------------------------------------------------------------
13     0     myjob.sh utente  t     05/08/2006 17:10:39 p511    MASTER

Per default SGE è configurato in modo tale da rifiutare un job sottomesso se questo possiede delle caratteristiche tali da non poter essere sottomesso su nessun nodo.
Per controllare in anticipo se un job può essere sottomesso, occorre usare l'opzione -w v di qsub.
Maggiori informazioni sui job mandati in esecuzione si possono ottenere tramite l'opzione -r di qsub.

Per cancellare un job si utilizza il comando qdel job_id.

Quando un job va in errore, questo viene rimesso in coda (si può rilevare lo stato di errore dalla "E" che appare nei flag di stato). Se il problema che ha causato lo stato di errore viene risolto, il job può essere tolto dallo stato di errore con il comando qmod -c job_id.