Sistema d'execució batch PBS Pro Sistema d'execució batch PBS Pro

03/06/2015 | SI
Compartir

Compartir

Facebook
X
Linkedin
Whatsapp
Gmail
Imprimir

Introducció

Es tracta d'un sistema d'execució de treballs batch que gestiona la distribució de la càrrega entre els nodes de càlcul de la granja de servidors Linux. Aquesta granja està formada per un node central amb processadors Intel Xeon (i686) anomenat api.uji.es, per un node de càlcul anomenat altix amb 48 processadors Intel Itanium2 (ia64), per 26 nodes de càlcul anomenats n001a n026 amb 2 processadors Intel Xeon i per 28 nodes de càlcul anomenats entre n101 i n134 amb dos processadors dual core Intel 5160 (quatre cores en total per node). Els nodes de càlcul es dediquen exclusivament a l'execució de treballs batch PBS. Per accedir a la granja cal connectar-se al servidor api, ja que la resta de nodes es troben en una xarxa privada no accessible des de la UJInet.

Api es dedica exclusivament a la gestió dels treballs PBS i a les sessions interactives; d'altra banda, també ofereix espai en disc permanent (Home) i temporal (Scratch). Des de api es pot accedir als nodes de càlcul mitjançant rlogin o ssh, d'aquesta manera es podrà fer un seguiment més adequat dels treballs (consultar arxius temporal, processos ...).

Pel que fa al servidor altix, com que es tracta de l'únic servidor amb processadors ia64, té accés al Home de Api (per mitjà de NFS), cosa que facilitarà el treball de compilació i depuració de programes que posteriorment s'executaran en aquest servidor, també disposa d'un Scratch local de 2 TB.

Des dels nodes de càlcul n001 a n030 cal accedir al Home per mitjà de rcp i disposen d'un Scratch local de 56 o 124 GB. Des dels nodes de càlcul n101 a n134 cal accedir al Home per mitjà de rcp o scp i disposen d'un Scratch local de 265GB.

Els treballs PBS crearan un directori de treball en el Scratch i faran la transferència d'arxius entre aquest directori de treball i el Home per mitjà de rcp (en el cas de altix espodria usar cp, però també suposaria la transferència d'arxius per la xarxa, de manera que, per uniformitat, millor usar rcp),d'aquesta manera els nodes de càlcul només necessitaran a api durant aquesta còpia d'arxius, que normalment es duu a terme en les fases inicial i final del treball.

Pots obtenir un llistat dels nodes que formen part de la granja amb 'pbsnodes -a' i 'pbsnodes2 -a', que proporciona una eixida similar a la següent:

altix     ntype = cluster     state = free     license = l     pcpus = 36     resources_available.arch = linux     resources_available.mem = 71009808kb     resources_available.ncpus = 36     resources_available.proc = ia64     resources_available.scr = 2047gb     resources_assigned.mem = 0kb     resources_assigned.ncpus = 0     resources_assigned.scr = 0kb     queue = workq     resv_enable = Truen001     ntype = cluster     state = free     license = l     pcpus = 2     resources_available.arch = linux     resources_available.mem = 2055460kb     resources_available.ncpus = 2     resources_available.proc = i686     resources_available.scr = 56gb     resources_assigned.mem = 0kb     resources_assigned.ncpus = 0     resources_assigned.scr = 0kb     queue = workq     resv_enable = True

Per a cada node de càlcul podem veure el seu estat (free,busy, down ...), el nombre de processadors, els recursos disponibles i els assignats ...

Recursos

Cada treball PBS té associats uns límits en els recursos que pot consumir, que en cas de ser excedits faran que el treball siga cancel·lat, així mateix, el sistema de cues usa aquests límits a l'hora de planificar l'execució dels treballs.

Els recursos més interessants són els següents:

  • Temps de CPU (-l cput=hh:mm:ss): Temps màxim de CPU que pot consumir un treball (és la suma de tots els processos que formen part del treball).
  • Nombre de processadors (-l ncpus=x): Quantitat de processadors que necessita el treball.
  • Memòria física (-l mem=xxxmb): Quantitat màxima de memòria que pot tenir assignada un treball (és la suma de tots els processos que formen part del treball).
  • Scratch (-l scr=xxxgb) (alternativament per a nodes de arquitectura x86_64:   -l file=xxxgb): Espai en disc en el Scratch que necessitarà el treball.
  • Tipus de processador (-l proc=ia64|i686) (alternativament per a nodes de arquitectura x86_64:   -l arch=x86_64): Especificarem ia64 si volem que el treball s'execute en altix, i686 si volem que s'execute en qualsevol node de 32 bits o x86_64 si volem que s'execute en qualsevol node de 64 bits. Cal tenir en compte que els executables són específics per a un tipus de processador. Es pot obtenir el tipus de processador d'un node amb uname -p.

Si no especifiquem algun dels recursos anteriors, els valors perdefecte seran els següents:

Recurs Valor defecte
Temps de CPU 01:00:00
Nombre de processadors 1
Memòria física 128mb
Scratch 1gb
Tipus de processador i686

Utilització

Un treball PBS és un script amb les accions que ha de dur a terme el treball. Cal recordar que el directori Home no és accessible directament des de tots el nodes de càlcul, i que cal usar rcp o scp ( en funció del tipus de node) per a transferir els arxius.

Un script com el següent (que anomenarem prova.sh )pot ser fàcilment adaptat per a executar qualsevol aplicació:

#!/bin/bash
#
# ID del treballID="$(echo $PBS_JOBID | cut -d . -f 1)"
#
# Arxius d'entrada, d'eixida i temporals

MAIN="api:prova"
IN="in1 in2 prova"
OUT="out1 out2"
TMP="tmp1 tmp2"

#
# Definicio del directori de scratch
SCR="/scratch1/$USER/scr-$ID"

#
# Ens possicionem en el directori de SCRATCH
mkdir -p $SCR && cd $SCR
if [ $? -ne 0 ] ; then        
        echo "No puc situar-me en el directori de scratch"
        exit 1
fi

#
# Transferim els arxius d'entrada
for arxiu in $IN ; do
        rcp $MAIN/$arxiu .        
        if [ $? -ne 0 ] ; then
                echo "No he pogut copiar l'arxiu d'entrada '$arxiu'"
                exit 1
        fi
done

#
# Executar programa
./prova

#
# Transferim arxius eixida
for arxiu in $OUT ; do
        rcp $arxiu $MAIN/$arxiu-$ID
        if [ $? -ne 0 ] ; then
                echo "No he pogut copiar l'arxiu d'eixida '$arxiu'"
                exit 1
        fi
done

#
# Eliminar directori temporal
rm $IN $OUT $TMP && cd && rmdir $SCR
if [ $? -ne 0 ] ; then
        echo "No he pogut eliminar el directori de scratch"
        echo
        ls -la $SCR
        exit 1
fi
exit 0

Aquest script, s'encarrega de: crear un directori de treballen el Scratch ($SCR), transferir els arxius d'entrada necessaris des del Home ($MAIN), executar l'aplicació,retornar al Home els arxius d'eixida (usant com a sufix el ID del treball per a no sobreescriure els arxius d'eixida corresponents a diferents instàncies del mateix treball) i eliminar els arxius en el directori de treball.

Una vegada tenim el script, hem de fer una estimació dels recursos que necessita el nostre treball. Si suposem que aquest treballnecessita 20 hores de CPU, 256 Mb de memòria, 10 GB en el Scratch i processadors i686, les opcions corresponents seran:

Recurs

Valor defecte

20 h cpu -l cput=20:00:00
256 MB memòria -l mem=256mb
10 GB de Scratch -l scr=10gb
processadors ia64 -l proc=ia64

 

Per a enviar el treball utilitzarem la instrucció qsub,a la qual li passarem les opcions corresponents als recursos, seguides del nom del script.

Continuant amb l'exemple anterior hauríem d'executar:

$ qsub -l cput=20:00:00 -l mem=256mb -l scr=10gb -l proc=ia64 prova.sh

Per a una major comoditat, els recursos també poden especificar-se dins del mateix script amb comentaris especials. La instrucció qsub interpreta les línies que comencen per #PBS com a directives especials per a especificar opcions.

D'aquesta manera, si en el script anterior afegim aquestes línies (cal afegir-les a partir de la segona línia del script):

#PBS -l cput=20:00:00
#PBS -l mem=256mb
#PBS -l scr=10g
#PBS -l proc=ia64

podríem enviar el treball al sistema batch amb:

$ qsub prova.sh

En ambdós casos, al executar qsub obtindrem l'identificador del nostre treball, que té el format ID.api, on ID és un número que el sistema assigna seqüencialment a cada treball.

Una vegada enviat el treball, podem comprovar el seu estat amb la instrucció qstat -s, que ens mostra un llistat similar al següent:

                                                                 Req'd    Req'd        Elap
Job ID          Username   Queue    Jobname    SessID NDS TSK    Memory   Time     S   Time
--------------- -------- --------  ----------  ------ --- ---    ------   -----    -   -----
2724.api       traverj     workq    m1_400       2409  --   1     512mb    1800:   R    1352:

D'aquest llistat, les columnes més interessants són:

  • Job ID: Identificador del treball.
  • SessID: Identificador del grup de processos que formen part del nostre treball. Pot resultar útil junt amb la instrucció ps -g sessid.
  • S: Estat del treball, R=en execució, Q=en cua.
  • Flap Time: Temps real transcorregut des de l'inici del treball.

La segona línia conté un comentari que depèn de l'estat del treball,en aquest cas ens indica el node i la data en què es va iniciarl'execució. Si el treball estiguera en cua indicaria el motiu.

Amb la instrucció rsh altix ps -fg 2409 podríem veure quins són els processos associats al nostre treball.

Podem usar qstat -f 2724 per a veure tota la informació sobreaquest treball.

Quan el treball acabe la seua execució, obtindrem dos arxius, un amb l'eixida per pantalla del nostre treball i l'altre amb l'eixida d'error, amb el format nom_treball.oID i nom_treball.eID.

Si volem cancel·lar un treball que ja s'ha enviat, utilitzarem la instrucció qdel ID.

Informació proporcionada per: Servei d'Informàtica