DO NOT EDIT THIS PAGE USING WYSIWYG EDITOR - CSS AND PHP CODE AHOY! PRESS CANCEL BUTTON.

Farm per il calcolo general purpose

Il Servizio Calcolo mantiene una farm per il calcolo scientifico seriale, basata su architettura Intel/linux che raggruppa le risorse centrali e di diversi gruppi di ricerca. La farm e' gestita tramite il batch system LSF, le cui licenze sono state acquistate centralmente dalla Commissione Calcolo e Reti dell'INFN. L'accesso diretto ai nodi della farm non è consentito. Per utilizzare la farm e' necessario accedere ai nodi di front-end via ssh. I job possono essere sottomessi da qualunque front end su qualunque architettura. La disponibilità di front end per le diverse architetture è finalizzata a permettere la compilazione interattiva sulla architettura desiderata.

Nodi di front-end

Sono disponibili nodi di front-end per ciascuna architettura supportata. I nodi di front end non devono essere utilizzati per l'esecuzione interattiva di job, se non per run molto brevi a scopo di test. Attualmente i front-end disponibili sono:

  • farmuisl7.ge.infn.it per architettura CentOS 7

Nodi di calcolo

La farm e' attualmente costituita da 32 nodi di calcolo biprocessori Intel a 64 bit, per un totale di circa 712 core.
I nodi di calcolo sono suddivisi per architettura e per gruppo sperimentale di proprietà, ma la configurazione utilizza un meccanismo di sharing delle risorse che permette agli utenti di utilizzare le risorse di altri gruppi sperimentali in caso si necessità e di disponibilita' di slot libere.

Storage

Ciascun nodo dispone di un'area locale di almeno 50 GB, accessibile in /scratch. Tale area non è visibile da altri nodi.
Tutti i nodi della farm, compresi i front end, hanno visibilita' delle seguenti aree dati condivise:

  • home directory: /home/<username>
  • disco general purpose: /farmdisk1
  • aree dati di gruppo: /project/<gruppo>/...
    l'accesso a queste aree e' limitato solo agli utenti afferenti al gruppo

Le home directory hanno un controllo di quota che per default è limitato ad 20 GB per utente.
Le aree dati di farm e di gruppo non hanno quota abilitata.
Si invitano gli utenti a non utilizzare le home directory per contenere dati o pacchetti software.

Software disponibile

Sui nodi di front-end e di calcolo sono disponibili i seguenti pacchetti software:

Compilatore gcc

Sono disponibili versioni del compilatore gcc/g++/gfortran per le diverse distribuzioni, in aggiunta alla versione distribuita per default con il sistema operativo.
Queste si trovano in /project/software/gcc/<versione>/<distrib>/, dove:

  • versione: ${M}.${m}.${r} (Major, minor, release). Usualmente M.m -> M.m.<last-release>
  • distrib: ${arch}-${os} (arch: x86_64, os: centos7/cc7/slc6/sl6)
    e' anche disponibile la nomenclatura del tipo ${arch}-${os}-${gccvers}-opt, standard del CERN

Per poter utilizzare una particolare versione del compilatore si deve esesguire il relativo script di setup:

  • source /project/software/gcc/${versione}/${distrib}/setup.sh (per la bash)
  • source /project/software/gcc/${versione}/${distrib}/setup.csh (per la csh/tcsh)
Ad esempio: source /project/software/gcc/4.9.3/x86_64-sl6/setup.sh per utilizzare il gcc 4.9.3 su Scientific Linux 6.

Compilatore Intel

Sono disponibili alcune versioni non aggiornate di compilatore Intel. Per utilizzare e' necessario fare il source del relativo script di setup:

  • Versione 12.1.13 (2011, comp. gcc 4.4.7): source /opt/intel/composer_xe_2011_sp1/bin/compilervars.sh intel64
  • Versione 13.1.13 (2013, comp. gcc 4.4.7): source /opt/intel/composer_xe_2013.5.192/bin/compilervars.sh intel64

ROOT

Sono disponibili alcune versioni di ROOT, per diverse distribuzioni e versioni di compilatore. Le diverse versioni sono installate in /project/software/root/<versione>/<distrib>/root/..., dove:

  • versione: ${M}.${m}.${r} (Major, minor, release); es: 6.08.06
  • distrib: ${arch}-${os}-${gccversion}-opt (arch: x86_64, os: centos7/cc7/slc6/sl6,gccversion: gcc${M}${m}); es: x86_64-sl6-gcc48-opt
secondo la nomenclatura usuale del CERN.
Per utilizzare una particolare versione di root, si deve fare il source del relativo script di setup.
Attenzione: per utilizzare una certa versione di ROOT si deve eseguire il setup anche per la corrispondente versione del compilatore. Ad esempio, per usare ROOT 6.08.06 compilata per gcc 4.8 su Scientific Linux (Cern) 6:

source /project/software/gcc/4.8/x86_64-slc6/setup.sh
source /project/software/root/6.06.08/x86_64-slc6-gcc48-opt/root/bin/thisroot.sh

Mathematica

Tutti i nodi della farm dispongono di una installazione di mathematica, che puo' essere utlizzato via batch.
La sezione dispone di un numero limitato di licenze (10), condivise tra interattivo e batch.
Non serve un setup particolare per l'utilizzo di mathematica, se non la presenza di /usr/local/bin nel PATH.

Configurazione delle code

Sulla farm sono definite le seguenti code:

  • coda medium:
    accesso: tutti gli utenti
    CPU limit: CPU time max 4 ore (normalizzato sulla CPU più veloce)
    memory limit: max 1 TB, default: 1 GB
    nodi accessibili: tutti
  • coda long:
    accesso: tutti gli utenti
    CPU limit: CPU time max 48 ore (normalizzato sulla CPU più veloce)
    memory limit: max 1 TB, default: 1 GB
    nodi accessibili: tutti, con un limite dell'80% sull'utilizzo di nodi non proprietari
  • coda extralong:
    accesso: tutti gli utenti
    CPU limit: CPU time max 14 giorni (normalizzato sulla CPU più veloce)
    memory limit: max 1 TB, default: 1 GB
    nodi accessibili: tutti, con un limite di massimo 20 job sull'utilizzo di nodi non proprietari
  • code di gruppo (aiace, g2, geant4, infne, lhcb, teo, totem):
    accesso: limitato agli utenti appartenenti al gruppo sperimentale
    limiti: nessuno
    nodi accessibili: i soli nodi di proprietà del gruppo sperimentale

Sottomissione di job

La sottomissione di un job si effettua tramite il comando bsub.
Si può sottomettere un eseguibile, ma è opportuno sottomettere uno shell script che inizializzi l'environment e faccia partire l'eseguibile.

  • esempio 1: sottomissione del comando "sleep 100"

    # bsub sleep 100

    Nota: se un comando o uno script richiede parametri, questi devono essere indicati in coda al nome del comando o dello script, in modo analogo alla esecuzione interattiva.
  • esempio 2: sottomissione di uno script sulla coda long

    # bsub -q long ./esempio.sh

    In assenza di indicazione della coda, la coda utilizzata e' la medium.
    NOTA: usualmente la current working directory non e' compresa nel PATH, quindi il nome dello script deve essere indicato con il path relativo (./<script>) o eventualmente assoluto (/home/<user>/<script>).
  • esempio 3: sottomissione su un nodo di architettura sl6_64

    # bsub -q teo -P sl6_64 ./esempio.sh

    L'esecuzione su una particolare architettura viene effettuata utilizzando lo switch "-P <project-name>", ed indicando come project name l'architettura desiderata (disponibili: sl6_64,c7). In assenza di una richiesta specifica, il job verrà eseguito sul primo nodo disponibile indipendentemente dalla sua architettura.
  • esempio 4: redirezione di standard output e standard error

    # bsub -q medium -o <outfile> -e <errfile> ./esempio.sh

    In questo modo lo standard output e lo standard error conseguente alla esecuzione dello script verranno collocati nei file indicati, in modalità "append". Se i file non esistono, vengono creati.
    Per default, in assenza di redirezione, LSF invia una mail alla fine del job, contenente standard output, standard error, ed un report sul job.
    Gli switch "-oo" e "-eo" hanno la stessa funzione, ma in modalita' "truncate": se i file non esistono vengono creati, altrimenti vengono sovrascritti.
    Se si specifica la redirezione dello standard output e dello standard error, la mail non viene inviata. Per forzare LSF ad inviare una mail con il solo report del job si deve utilizzazre lo switch "-N".
  • esempio 5: richiesta di risorse

    # bsub -R "select[mem>6000] rusage[mem=6000]" ...

    Lo switch "-R" permette di indicare ad LSF un insieme di risorse che il nodo di esecuzione debba soddisfare (oltre a quella di architettura eventualmente specificata come già visto) affinche' il job possa essere eseguito su quel nodo. Nell'esempio si richiede che il nodo abbia a disposizione almeno 6 GB di RAM al momento della esecuzione del job (selsect) e che poi siano considerati allocati sul nodo 6 GB per tutta la durata del job (rusage), anche se in un dato momento il job non la stesse utilizzando effettivamente.
    E' possibile porre condizioni su diversi tipi di risorse in modo molto flessibile (si veda il manuale lsf_admin.pdf nella sezione "Job Scheduling Policies", paragrafo "Specifying Resources Requirements").
  • esempio 6: specificare l'occupazione di memoria

    # bsub ... -M 3000
    I job sulle code medium e long hanno un memory limit per default posto ad 1 GB. Se un job eccede quel limite viene interrotto dal batch system.
    Per indicare esigenze diverse dal default va utilizzata l'opzione -M seguito dalla quantita' di RAM espressa in MB (nell'esempio si richiede di uccidere il job solo se va a occupare piu' di 3 GB).
    Per una corretta esecuzione di un job sarebbe necessario specificare la stessa quantita' di memoria necessaria come risorsa richiesta e come limite di occupazione:
    # bsub ... -M 8192 -R "select[mem>8192] rusage[mem=8192]"

NOTA: benche' bsub permetta di specificare l'host o gli host su cui eseguire il job (switch "-m"), questa opzione in genere non dovrebbe essere utilizzata in quanto e' il batch system che si deve occupare di trovare il nodo libero più opportuno per l'esecuzione. La richiesta esplicita di un nodo fa si che il tempo in cui il job rimarrà pending sara almeno uguale, ma in generale superiore, che nell'altro caso.

Per ulteriori informazioni, vedere la man page di bsub (# man bsub)

Controllo dei job e del batch system


Per visualizzare lo stato di LSF, degli host, delle code e dei job esistono opportuni comandi disponibili su tutti i nodi della farm:

  • visualizzazione dello stato del job: bjobs e bhist (quest'ultimo per visualizzare lo stato di job gia' terminati).
  • controllo del job: bkill (eliminazione del job), bstop e bresume (sospensione e riattivazione del job), bmod (modifica dei parametri del job), ed altri
  • stato delle code: bqueues
  • stato degli host: bhosts, bmgroup (quest'ultimo per visualizzare gli host group).
    Nota: gli host sono divisi in gruppi per architettura (type_<arch>) e per proprieta' (grp_<owner-group>), ma usualmente queste informazioni hanno una utilità per la gestione del batch system e non per il suo utilizzo.

Per tutti i comandi citati e non, si rimanda alle pagine di manuale ed alla documentazione dettagliata (lsf_command_ref.pdf).

Condivisione delle risorse

La configurazione del batch system è fatta in modo da permettere agli utenti di accedere a risorse non proprietarie quando queste siano libere.
Questo viene fatto utilizzando il meccanismo di queue-level fairsharing di LSF, che tiene conto delle risorse utilizzate nel recente passato da un utente o da un gruppo per calcolare dinamicamente la priorità dei job in coda.
La struttura delle code è fatta in modo tale che un utente possa sfruttare tutte le risorse di calcolo disponibili con job di media lunghezza (coda medium), e parzialmente con job medio-lunghi (coda long).
Le risorse proprietarie verranno quindi rese disponibili in breve tempo qualora l'utenza proprietaria le richieda (con job pending).
La gestione del fairsharing fa si che in media ciascun utente abbia la sua parte di risorse in funzione degli investimenti dei diversi gruppi sperimentali. Gli utenti afferenti a gruppi sperimentali che non hanno risorse proprie utilizzeranno quelle messe a disposizione dalla Sezione in comproprietà con tutti gli altri.

Va osservato che questo meccanismo si applica in modo statistico e non puntuale: può quindi capitare che in un certo momento un utente consumi una percentuale di risorse maggiore di quelle spettanti anche in presenza di job pending. Il riaggiustamento dinamico delle priorita' si occupa di riportare le percentuali al loro valore corretto nelle ore o giorni seguenti.
In questa ottica, tutti i nodi della farm sono da considerarsi equivalenti, in quanto e' la percentuale di utilizzo di risorse che conta. In questo senso sarà usuale trovare su nodi di un certo gruppo job di utenze non afferenti a quel gruppo: anche in questo caso il problema viene affrontato considerando essenzialmente la percentuale di utilizzo delle risorse in funzione degli investimenti più che assegnare rigidamente diritti di esecuzione su host di proprietà.

Si può in qualunque momento visualizzare la priorità dinamica dei diversi gruppi sperimentali operando il comando "# bqueues -l -q master" (o su una qualsiasi coda di gruppo, medium o long).

Documentazione


Sono disponibili i seguenti manuali distribuiti da Platform:

Monitoraggio dello stato della farm

Lo stato delle singole macchine (occupazione delle slot, uso di RAM, disco e rete...) può essere visualizzato grazie a ganglia attraverso questa URL.

Calcolo parallelo: farm HPC

Il Servizio Calcolo gestisce queste tre farm di calcolo parallelo:

Calcolo distribuito: GRID

CPU e accesso alle risorse

La sezione di Genova è Tier3 di Atlas, e sito di Grid (INFN-GE), e mantiene un certo numero di macchine per la VO di ATLAS. Sono attive 17 macchine per il calcolo (per un totale di 256 slot) e 3 macchine per il frontend (atlasui01, atlasui02 e atlasui03). Sono inoltre mantenuti i server di sito, CE, SE, bdii, squid e apel.

Il gruppo Atlas ha accesso ai frontend e può sottomettere i job sia localmente, tramite i comandi LSF, che attraverso la GRID.

Monitoraggio delle risorse

Lo stato delle singole macchine (occupazione delle slot, uso di RAM, disco e rete...) può essere visualizzato grazie a ganglia attraverso questa URL.