Cluster di calcolo 'Blade'

---- ENGLISH VERSION HERE ----

Concetti fondamentali

Il server 'blade' installato presso il nostro Dipartimento è configurato per soddisfare le richieste di risorse di calcolo da parte degli utenti in modalita' non interattiva o 'batch'.

E' possibile eseguire sul cluster qualsisasi applicazione a 32 o 64 bit che eseguireste abitualmente da uno dei PC Linux della rete DEI (ad esempio Matlab) o qualsiasi programma abbiate ricompilato da voi.

Le varie richieste vengono prese in carico dal programma di gestione del server, accodate in base ad un sistema di priorità ed eseguite dalla risorsa di calcolo più adeguata in quel momento.

I risultati della computazione che normalmente comparirebbero a video vengono salvati in un file di output.

Il programma di gestione adottato è Sun Grid Engine. Come altri sistemi di gestione simili il meccanismo di interazione principale consiste nel creare un file di testo (job file) contenente le richieste di risorse di calcolo ed il precorso (almeno) del programma da eseguire, del file da usare come input e di quello da scrivere come output. Una volta creato il job file un apposito comando (qsub) viene usato per accodare la richiesta.

Il cluster e' composto da 14 'lame' di calcolo variamente dimensionate. Alla data odierna (21 Settembre 2018) sono presenti:

  • 3 server (runner-04, runner-18 e runner-19) equipaggiati con:
    • 2 Processori 4-Core Intel Xeon E5450 @3.00 GHz
    • 32 GB RAM
  • 2 server (runner-16 e runner-17) equipaggiati con:
    • 4 Processori 6-Core AMD Opteron 8431 @2.4GHz
    • 80 GB RAM
  • 2 server (runner-13 e runner-14) equipaggiati con:
    • 4 Processori 16-Core AMD Opteron 6378 @2.4GHz
    • 256 GB RAM
  • 1 server (runner-15) equipaggiato con:
    • 4 Processori 6-Core Intel Xeon X5690 @3.47GHz
    • 96 GB RAM
  • 2 server (runner-06 e runner-07) equipaggiati con:
    • 4 Processori 6-Core Intel Xeon X5670 @2.93GHz
    • 144 GB RAM
  • 3 server (runner-01, runner-02 e runner-03) equipaggiati con:
    • 8 Processori 12-Core Intel Xeon Gold 5118 @2.30GHz
    • 1.5 TB RAM
  • 1 server (gpu1) equipaggiato con:
    • 4 Processori 12-Core Intel Xeon Gold 5118 @2.30GHz
    • 1 TB RAM
    • 7 GPU NVIDIA GTX 1080 Ti
  • Il sistema operativo installato sui server e' - alla data del 21 Settembre 2018 - Fedora Linux 25, ad eccezione del server equipaggiato con GPU che ha invece Ubuntu Linux 16.04.
  • La macchina che fa da frontend al cluster di calcolo, alla qualle ci si deve obbligatoriamente collegare per poter sottomettere dei job al sistema, e' login.dei.unipd.it.
  • Tutti i server di calcolo hanno accesso alla cartella home dell'utente ed a tutti gli shares (ad esempio /nfsd/android, /nfsd/biopetmri ecc. ecc.) a cui l'utente ha accesso.

Code, Job, Slot

Le richieste inoltrate dagli utenti (Job) vengono presi in carico dal sistema di gestione e messi in coda. Normalmente ogni Job occupa uno slot (idealmente pari ad una CPU) a meno che non ne vengano richiesti piu' di uno mediante l'utilizzo di un parallel environment (si veda il capitolo relativo al Sistema di Code)

Quindi, normalmente:

1 Job == 1 slot == 1 istanza della coda che consuma 1 CPU

Se si richiedono N processori attraverso il parallel environment invece

1 Job == N slot == 1 istanza della coda che consuma N CPU

Progetti

Il concetto di Progetto e' stato di fatto dismesso. Esiste un unico progetto Default: la richiesta esplicita di uno dei progetti configurati inizialmente (10_Bio, 10_Signet, 20_Telecom, 30_Ricerca o 40_Studenti) non generera' errori ma non avra' nessun effetto.

Limiti di utilizzo

Ogni utente puo' avere ul massimo 32 slot in esecuzione contemporaneamente. NON c'e' invece un limite ai job che possono essere accodati, cioe' in coda in attesa di essere eseguiti.

Questo significa che come utente potrei avere in esecuzione contemporaneamente:

  • 32 job sequenziali
  • 2 job paralleli che occupano 16 slot ciascuno
  • 2 job paralleli da 8 slot e 16 job sequenziali
  • ...qualsiasi combinazione intermedia la cui somma sia 32.

Allo stato attuale sono state definite:

  • La coda universale alla quale accedono tutti gli utenti;
  • La coda speciale gpu per accedere al server equipaggiato con le GPU;
  • Il parallel environment parallel per l'utilizzo di programmi paralleli (ad esempio Parallel Computing Toolbox di MATLAB o programmi multithread).

Code speciali 

La coda gpu da' accesso al server di calcolo gpu1.dei.unipd.it che, oltre a 48 core di calcolo ed 1TB di RAM, e' equipaggiato con 7 GPU NVIDIA Titan 1080i. Per avere accesso a questa coda e' necessario:

  • Avere dei job da eseguire che utilizzano le GPU attraverso le librerie NVIDIA CUDA;
  • Specificare l'uso della coda nel job file aggiungendo una riga del tipo
    #$ -q gpu

Parallel environment

Per poter utilizzare al meglio il cluster di calcolo con programmi che utilizzano piu' di una CPU (thread) e' necessario richiedere esplicitamente l'uso del parallel environment aggiungendo l'opzione -pe parallel N al comando qsub oppure aggiungendo al job file una riga del tipo

#$ -pe parallel N

dove N e' il numero di processori / thread che il programma utilizzera'.

Il parallel environment e' disponibile su tutti i nodi di calcolo ad eccezione di quelli con meno CPU (runner-04, runner-18 e runner-19).

La fonte principale di documentazione per tutto il sistema di gestione Sun Grid Engine sono le pagine di manuale accessibili dalla linea di comando (ad esempio: man qstat). Un veloce riassunto delle principali opzioni di ciascun comando si puo' ottenere usando lo switch '-help'.

qstat
mostra lo stato dei job e delle code

parametrofunzione
<nessun parametro>mostra i job in coda
-fstato di tutte le code
-j [JOBID]stato dettagliato [del job numero JOBID]

Esempio:

$ qstat
job-ID    prior     name   user     state  submit/start at       queue                        slots ja-task-ID 
----------------------------------------------------------------------------------------------------------------
1852431   0.00124   test   mazzon   r      09/17/2018 11:29:25   Q@runner-04.dei.unipd.it     1 
1852432   0.00062   test   mazzon   r      09/17/2018 11:29:25   Q@runner-18.dei.unipd.it     1 
1852433   0.00000   test   mazzon   qw     09/17/2018 11:29:25

Esempio 2:

$ qstat -j 1852439
==============================================================
job_number:                 1852439
exec_file:                  job_scripts/1852439
submission_time:            Mon Sep 17 11:33:58 2018
owner:                      mazzon
uid:                        6912
group:                      sysadmin
gid:                        444
sge_o_home:                 /home/mazzon
sge_o_log_name:             mazzon
sge_o_path:                 ..../usr/sbin:/nfsd/local/common/bin:/nfsd/opt/mrtrix3/release/bin:/nfsd/opt/mrtrix3/scripts:/home/mazzon/bin
sge_o_shell:                /bin/bash
sge_o_workdir:              /home/mazzon/devel/jobs
sge_o_host:                 login
account:                    sge
cwd:                        /home/mazzon/devel/jobs
stderr_path_list:           NONE:NONE:/dev/null
mail_list:                  mazzon@login.dei.unipd.it
notify:                     FALSE
job_name:                   parallel.job
stdout_path_list:           NONE:NONE:/dev/null
jobshare:                   0
env_list:                   
script_file:                parallel.job
parallel environment:  parallel range: 16
project:                    Default
scheduling info:            (no project) does not have the correct project to run in cluster queue "am.q"
                            (no project) does not have the correct project to run in cluster queue "ax.q"
                            (no project) does not have the correct project to run in cluster queue "m-all.q"
                            (no project) does not have the correct project to run in cluster queue "m.q"
                            (no project) does not have the correct project to run in cluster queue "x-all.q"
                            (no project) does not have the correct project to run in cluster queue "x.q"
                            (no project) does not have the correct project to run in cluster queue "FULL"
                            (no project) does not have the correct project to run in cluster queue "MEDIUM"
                            (no project) does not have the correct project to run in cluster queue "HIGH"
                            cannot run in PE "parallel" because it only offers 0 slots

qhost
mostra lo stato degli host per l'esecuzione

parametrofunzione
<nessun parametro>mostra una tabella degli host per l'esecuzione
-qlista delle code disponibili sui vari host
-jmostra i job in esecuzione sui vari host

Esempio:

$ qhost
HOSTNAME ARCH NCPU LOAD MEMTOT MEMUSE SWAPTO SWAPUS ------------------------------------------------------------------------------- global - - - - - - - bella linux-x64 2 - 1.9G - 2.4G - gpu1 lx26-amd64 48 0.00 1007.3G 2.7G 15.3G 0.0 runner-01 linux-x64 96 0.01 1511.6G 1.4G 16.0G 0.0 runner-02 linux-x64 96 0.00 1511.6G 1023.9M 16.0G 0.0 runner-03 linux-x64 96 46.96 1511.6G 2.4G 16.0G 0.0 runner-04 linux-x64 8 0.31 31.4G 2.0G 16.0G 38.0M runner-06 linux-x64 24 11.31 141.5G 3.5G 16.0G 40.4M runner-07 linux-x64 24 12.91 137.7G 2.2G 16.0G 73.8M runner-13 linux-x64 64 17.01 251.9G 22.2G 16.0G 35.7M runner-14 linux-x64 64 62.11 251.9G 3.2G 16.0G 0.0 runner-15 linux-x64 24 11.92 94.4G 16.2G 16.0G 0.0 runner-16 linux-x64 24 20.93 78.7G 4.4G 16.0G 742.9M runner-17 linux-x64 24 22.96 78.7G 4.2G 16.0G 51.3M runner-18 linux-x64 8 0.00 31.4G 360.4M 16.0G 60.8M runner-19 linux-x64 8 23.30 31.4G 6.7G 16.0G 40.2M

qsub
lancia un job

parametrofunzione
-cwdtutti i percorsi indicati sono relativi alla directory corrente
-o output.txtredireziona lo standard output nel file output.txt. Se non specificato vengono generati file con suffisso .oXYZ, dove XYZ e' il job-ID
-e error.txtredireziona lo standard error nel file error.txt. Se non specificato vengono generati file con suffisso .eXYZ, dove XYZ e' il job-ID
-m b|e|a|s|nseleziona in che occasioni notificare via mail l'utente. DEFAULT: nessuna notifica. Le possibili opzioni (se ne possono specificare piu' di una) sono:
  • b (beginning): notifica all'avvio del job;
  • e (end): notifica alla fine del job;
  • a (abort): notifica se il job viene abortito o rischedulato;
  • s (suspend): notifica se il job viene sospeso;
  • n (none): non notificare mai (default).

N.B.: Tutti i parametri della linea di comando possono essere messi in un job file anteponendo all'opzione (una o piu' per riga) i due caratteri '#$'.

qdel
elimina un job in coda

parametrofunzione
-u MIALOGINcancella TUTTI i miei job (sia in esecuzione che in coda)
lista_di_jobcancella tutti e soli i job specificati in lista_di_job

Per poter usare il cluster di calcolo è OBBLIGATORIO connettersi via SSH al server login.dei.unipd.it

Per prima cosa, quindi, collegatevi al server login: i comandi indicati dopo il carattere '$' sono quelli che dovete scrivere da tastiera.

$ ssh LoginDEI@login.dei.unipd.it

La password che viene chiesta è quella relativa alla vostra login del DEI.


ESEMPIO 1: 
sottomettere come semplice 'job' al sistema la stampa della lista dei files nella cartella corrente.

Lanciando semplicemente il comando 'ls' da terminale questo verrebbe eseguito sulla macchina dove siamo collegati in quel momento: vogliamo invece che l'esecuzione avvenga su uno dei nodi di calcolo. Per far ciò usiamo il comando 'qsub'.

$ qsub -cwd -m ea     (...premete INVIO)
ls

( premete ora CTRL + d )

Your job 1598 ('STDIN') has been submitted

Il job viene accodato (preso in carico) dal sistema: inizialmente lo stato (colonna 'state') sara' 'qw' (queued, waiting):

$ qstat

job-ID  prior   name       user         state submit/start at       queue                        slots ja-task-ID 
-----------------------------------------------------------------------------------------------------------------
1598    0.00000 STDIN      mazzon       qw    03/03/2009 11:50:51                                    1

Ad un certo punto il job passerà dallo stato 'qw' allo stato 'r' (running):

$ qstat

job-ID  prior   name       user         state submit/start at       queue                        slots ja-task-ID
-----------------------------------------------------------------------------------------------------------------
1598    0.75000 STDIN      mazzon       r     03/03/2009 12:32:22   Q@runner-01.dei.unipd.it     1

Al termine della computazione l'output del programma si trova nel file STDIN.o1598 (dove 1598 è il JOBID: si veda il comando precedente).
In questa modalità di interazione dovete riscrivere ogni volta tutti i comandi!

ESEMPIO 2: avvio di uno script Matlab

1) Create un job file (ad esempio test.job) contenente:

#!/bin/bash
#
# Imposta il valore 'name' di qstat
#$ -N test
#
# Tutti i percorsi sono relativi alla cartella corrente (-cwd)
# Genera output ed errori nella cartella corrente.
#$ -cwd
#
# Non redirigo l'output: ogni esecuzione generera' un file diverso.
# Il file di output sara' test.job.oJOBID
# Il file degli errori sara' test.job.eJOBID
#
# Voglio ricevere una mail quando il job termina
# o in caso venga abortito
#
#$ -m ea

matlab -r ScriptDaEseguire

2) Spostatevi nella cartella contenente il job file e sottoponetelo al sistema di gestione:

$ cd path/to/my/files
$ qsub test.job

3) Per vedere l'avanzamento del lavoro è sufficiente digitare il comando qstat. L'output del comando indica lo stato del lavoro (colonna 'state'), e soprattutto il jobid (job-ID) assegnato.

job-ID  prior   name       user         state submit/start at       queue                        slots ja-task-ID
-----------------------------------------------------------------------------------------------------------------
1698    0.75000 test       mazzon       r     03/03/2009 12:32:22   Q@runner-01.dei.unipd.it     1

4) Eventuali file di output si trovano nella cartella contenente tutti i file MATLAB ed il job file

In questa modalita' di interazione per ripetere il job e' sufficiente rieseguire il qsub