Accesso al cluster

Dopo aver richiesto ed ottenuto un account, e' possibile accedere al cluster via SSH attraverso i seguenti nodi di login

(definiti user interface dalla terminologia GRID):

ui1-cyb.dsf.unica.it / ui2-cyb.dsf.unica.it

Utenti UNICA:

ui1-cyb.unica.it / ui2-cyb.unica.it

NOTA BENE: per gli utenti connessi con il proprio computer direttamente alla rete di UNICA i server di cui sopra

sono assolutamente consigliati per l'accesso ed il trasferimento di files via SSH.

Modifica della password:

La modifica della password per il proprio account avviene lanciando il comando: passwd

E' possibile modificarla su una qualunque delle UI (le password sono sincronizzate).

Strumenti disponibili

Compilatori e librerie disponibili sul cluster sono visibili lanciando il comando: module avail

L'elenco degli strumenti a disposizione degli utenti compare sotto la riga indicata come:

/share/Modules/modulefiles

La descrizione di ogni modulo si ottiene lanciando: module whatis module_name

I compilatori disponibili sono: Intel, GNU e PGI. Vengono resi disponibili lanciando rispettivamente:

module load gnu

module load intel (il caricamento di questo modulo importa anche il PATH delle Intel MKL)

module load pgi

Si rimanda comunque alla pagina relativa agli strumenti disponibili sul cluster per una descrizione esaustiva:

http://twiki.ca.infn.it/cgi-bin/view/Cybersar/SoftwareInstalledOnTheCluster

Librerie MPI e supporto Infiniband:

Se si vuole utilizzare una libreria MPI e' necessario caricarla dopo aver selezionato un

compilatore. Le librerie disponibili sono:

• OpenMPI: consigliato per girare con Infiniband ma anche per job multicore su un solo nodo.
• MPICH,MPICH2: unicamente per elaborazioni che usano non piu' di 4 cores.
• MVAPICH2: dedicate ad Infiniband.

Quota disco

Ogni utente disporra' di una quota disco pari a 50 GBytes. E' possibile visualizzare la propria quota

disco lanciando il comando: myquota

Tipologia delle code

Le code sono suddivise per numero di cores disponibili e tempo massimo di esecuzione.

Ogni utente dispone di un numero massimo di cores impostato a 64. Per verificare

le caratteristiche del proprio account lanciare il comando: busers

NOTA BENE:

In fase di sottomissione e' possibile specificare unicamente il numero dei cores, lasciando

ad LSF la decisione sulla scelta della coda che piu' si adatta alle richieste. Solo nel caso si

abbiano richieste specifiche per il proprio job e' consigliabile impostare il tipo di coda.

Tabella delle code:

Scegliere il tipo di architettura per il proprio job (opzionale):

A partire dal 07 maggio 2009 il sistema di gestione delle code consente, in fase di sottomissione, di scegliere

su quale tipo di architettura hardware far girare il proprio job.

Questa opzione si deve specificare esplicitamente aggiungendo al proprio file di sottomissione un flag specifico.

Nota bene: l'aggiunta del flag che definisce l'architettura * *non e' obbligatorio **.

Al momento le scelte disponibili sono:

- host di tipo AMD Opteron (doppio dual core): aggiungere #BSUB -R "model=O2218"

- host di tipo Intel Xeon (doppio quad core):

aggiungere #BSUB -R "model=ib7d1" (per host da 101 a 120)

aggiungere #BSUB -R "model=ib7d2" (per host da 121 a 140)

Jobs MPI:

Tutti i jobs che necessitano di utilizzare piu' di 4 o 8 cores vengono considerati di tipo MPI e sfrutteranno

gli switch Infiniband, girando sulle code tra parallel8 e parallel128 comprese.

Nota: per usare la coda parallel128 gli utenti devono richiedere espressamente un aumento del limite dei cores

utilizzabili.

Express16 queue ( debug queue):

La coda express16 e' pensata specificatamente per i test su run di codice parallelo, con numero variabile di

cores (da 2 a 16).

Jobs ad elevato consumo di memoria:

Tutti i jobs, di tipo seriale, che richiedono piu' di 4 GBytes di memoria RAM devono girare sulla coda: himem

Jobs che richiedono un numero di cores dispari:

Non e' possibile richiedere esplicitamente un job con numero di cores dispari ma unicamente

con multipli di 4 o 8.

Panoramica dei comandi LSF

LSF e' il job manager utilizzato in questo cluster. Si occupa di ricevere e smistare le richieste

effettuate dagli utenti sulla base di specifici comandi.

Sottomissione di un job:

Per lanciare un job sul cluster e' necessario impostare un piccolo file di testo con la seguente struttura:

Job parallelo

#BSUB -n num_processori -----> (*per job MPI deve essere maggiore di 1*)
#BSUB -q parallel4 -----> (nome della coda: opzionale)
#BSUB -a openmpi -----> (tipologia MPI library)
#BSUB -J job_name -----> (nome scelto dall'utente)
#BSUB -o %J.out -----> (file di output: il nome e' composto dall'*ID* del job e dall'estensione)
#BSUB -e %J.err -----> (file di error)

. /etc/profile.d/modules.sh (questa riga carica la definizione dei moduli sui nodi di esecuzione.)

module load pgi
module load openmpi

mpirun.lsf -np 4 /u/myuser/MySRC/binary > output.file

NOTA BENE:

L'utilizzo di software compilato con librerie MPI richiede obbligatoriamente

di essere lanciato tramite il wrapper script: mpirun.lsf

Job multi-thread

I job che fanno uso di multithreading devono essere lanciati obbligatoriamente solo sulle

code multi4 o multi8 e devono specificare la seguente dicitura, all'interno dello script utilizzato

per la sottomissione:

[...]

export OMP_NUM_THREADS=4; ./my_multithread_prg (per jobs su coda multi4)

oppure: export OMP_NUM_THREADS=8; ./my_multithread_prg (per jobs su coda multi8)

Job seriale

#BSUB -n 1
#BSUB -q short
#BSUB -J job_name -----> (nome scelto dall'utente)
#BSUB -o %J.out -----> (file di output: il nome e' composto dall'*ID* del job e dall'estensione)
#BSUB -e %J.err -----> (file di error)

. /etc/profile.d/modules.sh (questa riga carica la definizione dei moduli sui nodi di esecuzione.)

cd /u/myuser

./myprg > output.file

Code seriali: le code seriali disponibili sono quattro ( express, himem, short, long). Se il tipo di coda non viene

esplicitamente richiesto viene usata la coda long (14 days). Nel caso sia necessario un tempo di esecuzione

minore si puo' optare per la coda short (1 day) mentre nel caso di un run di test si puo' utilizzare la coda

express (per soli 30 minuti). La coda himem ( 9 days) e' pensata per job che richiedono un elevata quantita'

di memoria RAM (oltre 4 GBytes).

In entrambi i casi la sottomissione avviene con il comando bsub:

bsub < myjob.sh

Uso della /scratch:

NOTA BENE: le aree /scratch presenti su ui1 e ui2 non sono visibili dai worker nodes.

Inoltre, tutte le aree /scratch presenti sui worker nodes sono locali al nodo e non

sono disponibili globalmente su tutto il cluster, differentemente dalla propria home directory.

Aree scratch sui worker nodes:

NOTA BENE: se il proprio job (seriale o parallelo) necessita di effettuare un certo I/O su disco

e' necessario modificare il proprio script di sottomissione aggiungendo (prima dell'mpirun o

della linea di comando del job seriale):

(...)

. /share/scripts/lsf_utils

# Set up scratch directory on all nodes scheduled
# for the execution:
hosts=`clean_LSBHOSTS $LSB_HOSTS`
for hostname in $hosts; do
ssh $hostname /bin/rm -rf /scratch/$USER
ssh $hostname /bin/mkdir /scratch/$USER
done

(...)

Scaricare i files dalle aree di scratch:

Per scaricare i propri files dalle locali aree scratch sui worker nodes e' possibile

utilizzare il client ftp presente sulle user interfaces (ui1 oppure ui2).

Di seguito la trascrizione di una sessione di lavoro nella quale si intendono trasferire

dei files dalla /scratch area di un generico worker node:

[sysadm@ui2 $]ftp wn098

Connected to wn098.cyb.unica.it.
220 Welcome to WN FTP service.
530 Please login with USER and PASS.
530 Please login with USER and PASS.
KERBEROS_V4 rejected as an authentication type
Name (wn098:sysadm):

Si puo' evitare di inserire il nome e procedere con invio.

Subito dopo vi verra' richiesta la password:

331 Please specify the password.
Password:

La password da inserire sara' la stessa utilizzata per fare login su ui1/ui2.

NOTA BENE: il login avverra' con sucesso esclusivamente nel caso esista una

subdirectory di /scratch/ con il vostro username (ad esempio: /scratch/sysadm).

In caso contrario la sessione verra' automaticamente chiusa.

A login avvenuto si arrivera' alla shell del server FTP:

230 Login successful.

Remote system type is UNIX.

Using binary mode to transfer files.

ftp>

Da questo punto in poi e' possibile lanciare un ristretto numero di comandi: ls, get, mget, ecc.

Non e' consentito in alcun modo caricare i propri files sulle aree scratch dei nodi via ftp (il comando

put e' disabilitato). Maggiori info sui comandi disponibili si possono ottenere lanciando il comando help

una volta effettuato il login sul server ftp.

Prototype submission script:

Nella directory /share/scripts e' presente uno script prototipo per la sottmissione

di un job denominato: proto_sub_script.jdl

Stato del cluster:

Tramite i comandi di LSF e' possibile interrogare lo stato del cluster.

bqueues: mostra le code disponibile sul cluster ed il loro utilizzo.

bjobs: mostra i jobs in stato PENDing/RUN/SSUSP del proprio utente.

bjobs -u all: nel caso si voglia conoscere lo stato di occupazione del cluster

e verificare l'elenco dei jobs di tutti gli utenti ed il loro stato(sia RUN che PEND).

bjobs -l myjobID: si puo' ottenere lo stato dettagliato del proprio job in RUN

mentre nel caso si trovi in stato PEND verra' mostrata una riga con la dicitura

"PENDING REASON".

bjobs -q nome_coda: per vedere l'elenco dei propri jobs su una coda specifica.

Aggiungendo -u all alla fine del comando si ottiene l'elenco di tutti i jobs attualmente

in stato di RUN o PEND su quella coda.

-- MatteoDessalvi - 29 Aug 2008