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 ...
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:
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 |
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:
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.
