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:
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 submittedIl 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
Allo stato attuale sono state definite delle code di esecuzione alle quali si accede sulla base di appartenenza o meno ad un determinato gruppo unix.
La cosa e' importante: qualora si appartenga a piu' di un gruppo ed il gruppo primario non sia tra quelli ammessi sara' OBBLIGATORIO usare il comando newgrp nuovo_gruppo prima di lanciare qsub.
Esempio: l'utente 'mazzon' appartiene a piu' di un gruppo UNIX: lo si vede utilizzando il comando id (senza parametri mostra uid e gid dell'utente corrente):
> id mazzon uid=6912(mazzon) gid=14(sysadmin) groups=100(users),14(sysadmin),318(meladmin),325(wifi)
Il gruppo primario (quello che verra' utilizzato da SGE) e' quello indicato dopo la voce 'gid=', gli altri sono ovviamente indicati dalla lista 'groups='. Qualora il gruppo primario fosse impostato, ad esempio, a 'meladmin' si avrebbe il seguente risultato:
> newgrp meladmin > qsub mmfast.job Unable to run job: warning: mazzon your job is not allowed to run in any queue job rejected: no access to project '30_Ricerca' for user 'mazzon'. Exiting.
La lista dei gruppi che possono sottomettere un job al sistema SGE e' indicata nelle tabelle sottostanti.
Code
Il sistema SGE e' stato configurato sulla base dei concetti di 'code' (queue) e 'progetti' (projects). Ogni utente che abbia accesso ad una coda ha anche accesso anche a tutte le altre code che stanno "al di sotto" nella seguente tabella:
| NOME | gruppi ammessi | limitazioni |
|---|---|---|
| FULL | bio signet | Max Istanze: 16 per il progetto 10_Bio + 16 per il progetto 10_Signet |
| HIGH | telecom, tc-dott, tc-main, tc-stud | Max Istanze: 8 per il progetto 20_Telecom |
| MEDIUM | {gruppi della coda FULL} {gruppi della coda HIGH} assegni collab docenti dottor personale tesi | |
| LOW | {tutti i gruppi della coda MEDIUM} studenti | |
NOTE:
| ||
Progetti
Se da un lato le code differenziano i job presi in carico da SGE sulla base del gruppo di appartenenza, un controllo piu' fine del processo di schedulazione si puo' fare a livello di scelta del progetto (project). Questo puo' essere visto come una specificazione a livello 'semantico' del compito da eseguire sul server di calcolo.
Ogni utente cioe' puo' scegliere, in base ai progetti a cui ha accesso, se richiedere (anche all'interno della stessa coda di priorita') delle risorse di calcolo sulla base del progetto_A o del progetto_B. Il concetto di progetto consente inoltre allo scheduler di differenziare gli utenti che hanno accesso ad una stessa coda.
I progetti attualmente definiti, gli utenti che vi possono accedere e le code su cui possono essere eseguiti sono, al momento:
| NOME | gruppi ammessi | code ammesse |
|---|---|---|
| 10_Bio | bio | FULL, MEDIUM, LOW |
| 10_Signet | signet | FULL, MEDIUM, LOW |
| 20_Telecom | telecom, tc-dott, tc-main, tc-stud | HIGH, MEDIUM, LOW |
| 30_Ricerca | {gruppi progetto 10_Bio} {gruppi progetto 10_Signet} {gruppi progetto 20_Telecom} assegni collab docenti dottor personale tesi | MEDIUM, LOW |
| 40_Studenti | {tutti i gruppi precedenti} studenti | LOW |
| NOTE: qualora non venga specificato il progetto di default e' 40_Studenti. Non specificare un progetto al momento della sottomissione del job comportera' di conseguenza l'accesso alla sola coda LOW. | ||
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
| parametro | funzione |
|---|---|
| <nessun parametro> | mostra i job in coda |
| -f | stato 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
| parametro | funzione |
|---|---|
| <nessun parametro> | mostra una tabella degli host per l'esecuzione |
| -q | lista delle code disponibili sui vari host |
| -j | mostra 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
| parametro | funzione |
|---|---|
| -cwd | tutti i percorsi indicati sono relativi alla directory corrente |
| -o output.txt | redireziona lo standard output nel file output.txt. Se non specificato vengono generati file con suffisso .oXYZ, dove XYZ e' il job-ID |
| -e error.txt | redireziona 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|n | seleziona in che occasioni notificare via mail l'utente. DEFAULT: nessuna notifica. Le possibili opzioni (se ne possono specificare piu' di una) sono:
|
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
| parametro | funzione |
|---|---|
| -u MIALOGIN | cancella TUTTI i miei job (sia in esecuzione che in coda) |
| lista_di_job | cancella tutti e soli i job specificati in lista_di_job |
Supponiamo di voler eseguire con matlab lo script ScriptMatlab.m nella cartella devel/jobs della propria homedir. Decido di non sovrascrivere l'output (ed eventuali errori) ad ogni esecuzione utilizzando la direttiva -o (-e) ma di lasciare che il sistema crei automaticamente un file di output diverso ad ogni esecuzione, in modo da poter poi processare i vari files per fini statistici.
Creero' allora un 'job file' (mmfast.job) contenente i seguenti comandi: (notare che le righe che iniziano col solo carattere '#' introducono dei commenti, quelle che iniziano con '#$' introducono le direttive per lo scheduler) Il job file da sottomettere allo scheduler
#!/bin/bash # # Genera output ed errori nella cartella corrente. # Se non specificato diversamente output ed errori # vengono rediretti rispettivamente nei 2 file # mmfast.job.oJOBID e mmfast.job.eJOBID # #$ -cwd # # Voglio ricevere una mail quando il job termina # o in caso venga abortito # #$ -m ea # cd ~/devel/jobs matlab -r ScriptMatlab
Il file e' pronto per la sottomissione che avviene semplicemente con il comando:
> qsub mmfast.job
Your job 1571 ('mmfast.job') has been submitted
Posso controllare lo stato di avanzamento dei miei jobs: inizialmente saranno nello stato queued + waiting indicato dalle lettere 'qw' alla voce 'state':
> qstat job-ID prior name user state submit/start at queue slots ja-task-ID ----------------------------------------------------------------------------------------------------------------- 1571 0.00000 mmfast.job mazzon qw 02/27/2009 11:35:43
Appena il sistema trovera' delle risorse libere su cui eseguire il programma, il suo stato passera' a running (lettera 'r' dello 'state'):
> qstat job-ID prior name user state submit/start at queue slots ja-task-ID ----------------------------------------------------------------------------------------------------------------- 1571 0.75000 mmfast.job mazzon r 02/27/2009 11:35:53 Q@runner-06.dei.unipd.it 1
Un output piu' dettagliato si ottiene specificando l'opzione '-j' ed il numero di sequenza del job nel comando qstat:
> qstat -j 1571 ============================================================== job_number: 1571 exec_file: job_scripts/1571 submission_time: Fri Feb 27 11:35:43 2009 owner: mazzon uid: 6912 group: sysadmin gid: 14 sge_o_home: /home/mazzon sge_o_log_name: mazzon sge_o_path: /usr/share/gridengine/bin/lx26-x86:...:/home/mazzon/bin sge_o_shell: /bin/bash sge_o_workdir: /home/mazzon/devel/jobs sge_o_host: pcmazzon account: sge cwd: /home/mazzon/devel/jobs stderr_path_list: NONE:NONE:/dev/null mail_list: mazzon@pcmazzon.dei.unipd.it notify: FALSE job_name: mmfast.job jobshare: 0 env_list: script_file: mmfast.job project: Default scheduling info: There are no messages available
Quando l'esecuzione terminera' trovero' il file di output (se ho specificato la direttiva '-cwd') nella cartella dell'eseguibile:
> ls ScriptMatlab.m mmfast.job mmfast.job.o1569 mmfast.job.o1570 mmfast.job.o1571
Con l'intento di razionalizzare l'utilizzo del Parallel Computing Toolbox di Matlab si e' provveduto a restringere l'accesso al toolbox, per i job in esecuzione sul cluster Blade, ai soli runner-13 e runner-14 che sono stati di recente sostituiti con macchine piu' performanti (64 CPU e 256 GB RAM).
A tale scopo sono state riservate 4 licenze ad uso esclusivo di questi 2 host ed e' stata creata una coda di esecuzione che esiste solo in queste 2 lame.
Operativamente, per eseguire quindi un job matlab che utilizzasse il parallel toolbox sara' necessario specificare nel job file:
-q parallel
-l par_cpu=N
A chi è rivolto: tutti
Descrizione: in questa scheda vengono riportate le modalità per utilizzare il nuovo server di calcolo dipartimentale tramite il proprio account informatico.
Referente: Servizi Informatici