SGE

i2basque(e)tik

Hona jo: nabigazioa, bilatu

Edukiak

Sun Grid-ren bidez erabilgarriak diren klusterren azalpena

Klusterrak Gasteizen, Donostiaren eta Leioaren artean banaturik daude. Kluster guztiak Hyperthreading duten Xeon makinekin osaturik daude, eta horrela, prozesadore fisiko bakoitzean bi prozesu exekutatu ahal dira.

Donostian don klusterra osatzen duten makinak eta multi0 prozesadore anitza daude. Bestalde, don-en makinak 32 biteko 8 Xeon biprozesadore dira, eta nodo bakoitzean 2GBko memoria dute. Halaber, multi0 32 biteko 4 Xeon prozesadoreko SMP bat da, eta 16GBko memoria dauka; 8 slot erabiltzen dituzten prozesu paraleloak exekutatzeko gauza da, prozesadoreek Hyperthreading edukitzeari esker, baina hobe da prozesadore bakoitzeko prozesu bat exekutatzea (guztira aldi bereko 4 prozesu) eta aldi bereko 8 prozesu exekutatzea, Hyperthreading beharrezko kasuetarako eta esperimentaziorako bakarrik erabiliz, kaltegarria izan daitekeelako errendimenduaren aldetik, exekutaturiko aplikazio motaren arabera.

Leioan lej klusterra dago; 64 biteko 8 Xeon biprozesadorek osatzen dute (EM64T), eta horien memoria 4 GBkoa da nodo bakoitzeko.

Gasteizen vit klusterra dago; 64 biteko 8 Xeon biprozesadorek osatzen dute (EM64T), eta horien memoria 4 GBkoa da nodo bakoitzeko.

Sun Grid Engine-en (SGE) ilarak, kluster hauei buruzkoak, honako hauek dira:

don don klusterreko makinekin osatuta, frontend izan ezik (don1-don7). 32 biteko lanak.

lej lej klusterreko makinekin osatuta (lej1-lej8). 64 biteko lanak.

vit vit klusterreko makinekin osatuta (vit1-vit8). 64 biteko lanak.

multi multi0 makinak osatuta. 32 biteko lanak.

32 frontend eta don klusterreko makinekin osatuta (don1-don7, fe). 32 biteko lanak.

64 lej eta vit klusterreko makinekin osatuta (lej1-lej8, vit1-vit8). 64 biteko lanak.

Sun Grid Engine-rako (SGE) sarrera

Sun Grid Engine ilara sistemak aukera ematen du lanen bidalketa, exekuzio ordena eta erabilera arauak kudeatzeko, ordenagailu edo kluster multzo batean. Gainera, batch lanen (korrontekako prozesuak) edo lan elkarreragileak urrunetik exekutatzea ahalbidetzen du, baita bidalitako lanen oraingo egoera ikustea ere, eta lanok aldatzea edo ezabatzea ere bai.

Ilaren sistema kontrolatzeko oinarrizko komandoak honako hauek dira:

  • qconf: administratzaileari SGEren konfigurazioa gehitzeko, ezabatzeko eta aldatzeko aukera ematen dio; horren barruan, ilaren, hosten, sistemako aldaeren eta erabiltzaileen kudeaketa sartzen da. Halaber, ilaren konfigurazioa ikusteko aukera ere ematen du.
qconf -sql        #Muestra una lista de las colas configuradas.
qconf -sq {queue} #Muestra la configuración de la cola indicada


Hasieraren konfigurazioa sistemaren erabiltzaileentzat

Ilaren sistemako aldaerak ondo hasteko, SGEri dagokion edozein komando erabili baino lehen honako script hau exekutatu behar da (Grid-en erabiltzaileen abioan sartutakoa).

source /opt/sge/default/common/settings.sh

Halaber, ilaren sistemaren monitorizazioaren eta kudeaketaren interfaze grafikoa exekutatzeko (qmon), ondoren adierazitakoaren arabera jardun behar da:

env LD_LIBRARY_PATH=/opt/sge/libmotif2/usr/X11R6/lib/:$SGE_ROOT/lib/lx24-amd64 qmon

Aldaketa hau erabiltzaileen sesioaren hasierako script-en artean ere aurreikusita dago, eta horrela, exekutatzeko nahikoa da qmon egitea.

Lanen bidalketa ilaren sistemara

Lanak ilaren sistemara bidaltzeko, qsub komandoa erabil daiteke (ohikoena), edo bestela, sistemako interfaze grafikoa erabili ahal da (qmon). Esate baterako:

qsub trabajo1.sh

Ilaren sistemara ondo bidaliz gero, sistemak mezu hau emango du:

your job 1 (``trabajo1.sh) has been submitted.

Bidaltzen diren lanak lanari buruzko aukera desberdinak dituzten script-ak dira beti. Ondoren, sisteman exekutatzen diren benetako lanen adibideak jarri eta azaldu egingo ditugu.

Lan paraleloak (MPI)

Adibide hau baliozkoa da 64 biteko CPMD programa (dinamika molekularraren kalkulua) abiatzeko; horrek MPI eta OpenMP erabiltzen du, bakoitzak exekutatzeko hari bat duten 16 prozesutan (16 MPI prozesu eta OpenMP prozesu bat), 64 biteko ilaran.

#!/bin/bash

# SGE variables

# Shell used to run the task on SGE
#$ -S /bin/bash 

# Name of the job
#$ -N cpmd64-al.5

# Specifies whether or not the standard error stream of the job 
# is merged into the standard output stream
#$ -j y

# SGE Environment Variables:
# HOME  Home directory on execution machine
# USER  User ID of job owner
# JOB_ID  Current job ID
# JOB_NAME  Current job name; see the -N option
# HOSTNAME  Name of the execution host
# TASK_ID  Array job task index number 

# Path where will be stored output (-o option)
# and error files (opcion -e)
#$ -o $JOB_NAME.$JOB_ID.$TASK_ID

# With this option error and output files are stored in the 
# directory from where the job is submitted using qsub
#$ -cwd

# E-mail address where the status of the job will be send
#$ -M franciscojavier.ridruejo@ehu.es

# When an email is sent to inform the user about the status of
# a job: -m e (end of a job), -m b (before of a job)
#$ -m be

# If the job is parallel, we indicate what kind of environment
# we use mpich for MPICH jobs or openmp for OPENMP jobs
# and the number of processes to use
#$ -pe mpich 16

# Request a maximum of 12 hours of execution time
# This parameter is commented because a real execution of CPMD lasts much more
##$ -l h_rt=12:00:00 

# Request 1GB of RAM memory for the execution
#$ -l vf=1G

# Multiple jobs to execute from-to:step
# In this example only one job
#$ -t 1-1:1

# Which queues to use?
# There are multiple queues in the system:
# 32: queue for 32 bit jobs
# 64: queue for 64 bit jobs
# don: queue of Donostia (32 bit cluster)
# lej: queue of Lejona (64 bit cluster)
# vit: queue of Vitoria (64 bit cluster)
# multi: queue of Multi (4-way 32 bit SMP) 
#$ -q vit

# With the -V option all environment variables are exported
# to SGE but using -v only the specified variable is exported
#$ -v OMP_NUM_THREADS=1
echo Running on host $HOSTNAME
echo Directory is `pwd`
ORIG_DIR=`pwd`

# create temporary directory to copy input and support files later
TEMP_DIR=/var/tmp/`whoami`.$$
echo TEMP_DIR es $TEMP_DIR
mkdir $TEMP_DIR
cat $TMPDIR

# Variables needed to run the job 
MPIRUN=/opt/mpich-cpmd64/bin/mpirun
MACHINEFILE=./machines.LINUX.vit
INPUT_FILE=./alcl3.64ur-H-d_ur-growth.in
OUTPUT_FILE=./alcl3.64ur-H-d_ur-growth.out
AUXILIAR_FILES="*.uspp RESTART* LATEST"
PPDIR=$TEMP_DIR
BINDIR=/opt/mpich-cpmd64/bin

# copy input and support files to a temporary directory on compute node
cp $INPUT_FILE $AUXILIAR_FILES $MACHINEFILE $TEMP_DIR
cd $TEMP_DIR
#source /opt/intel64/fce/9.0/bin/ifortvars.sh
echo This job has allocated $NSLOTS processors
echo Init time is `date`

$MPIRUN -v -machinefile $TMPDIR/machines -np $NSLOTS \
	$BINDIR/cpmd64.x $INPUT_FILE > $OUTPUT_FILE

echo End time is `date`

# copy files back and clean up
cp * $ORIG_DIR
rm -rf $TEMP_DIR

Lana exekutatu ondoren, bi fitxategi lortuko dira: bata lana exekutatzearen ondoriozkoa, ./alcl3.64ur-H-d_ur-growth.out ($OUTPUT_FILE); bestea cpmd64-al.5.700.1, eta izen hori $JOB_NAME.$JOB_ID.$TASK_ID adierazpidearen emaitza da, -N aukeratzat adierazitako lanaren izena, lanaren identifikatzailea sisteman (kasu honetan ondoz ondoko 700 zenbakia), eta 1 lanaren zenbakia, -t aukeraren bidez emandako lanaren barruan, eta, kasu honetan, (-t l-l:l) bakarra dagoenez, fitxategi bakarra idazten du, exekuzioaren emaitzatzat. N lan balego, N fitxategi egongo litzateke emaitzatzat, lan bakoitzeko bat, eta atzizkia l-tik N-ra bitartekoa izango litzateke.

Ondoriozko fitxategia (cpmd64-al.5.700.1) irteera estandarraren eta akatsen irteeraren nahastearen eraginezkoa da; izan ere, -j aukera adierazi eta bi irteerak nahasten direla esaten da.

Bestalde, script honetan lana exekutatzeko behar diren fitxategi guztiak kopiatzen dira direktorio batean, hori exekutatzen den makinan, ez irakurtzeko eta NFS erabiliz idazteko (lanak erabiltzaileen direktorioetatik jaurtikitzen dira, direktorio horiek NFSren bidez muntaturiko ilaren zerbitzari batean daudenean), horrela, sarean informazio asko ibiltzen da eta, beraz, errendimenduak behera egiten du. Lana amaitu ondoren, sarrerako fitxategiak eta emaitza fitxategian (lana jaurtikitzeko fitxategia) kopiatzen dira berriro.

Gainera, script hau txantiloitzat gordeta dago direktorioan /opt/sge/examples/jobs/paralelo_MPI.sh

Lan paralelo mistoak (MPI eta OpenMP)

Lehengo script-ean MPI lan bera exekutatzeko (baina exekutatzeko bi OpenMP harirekin), nahikoa da lerro bat aldatzea:

#$ -v OMP_NUM_THREADS=1 por  #$ -v OMP_NUM_THREADS=2 

Lan paraleloak (OpenMP)

Script hori multi0 prozesadore anitzean exekutatu nahi izanez gero, MPI barik eta 8 prozesadorerekin, 8 exekuzio hariko OpenMP erabiliz, aldatu egin behar da MPI lana dela adierazten duen lerroa:

#$ -pe mpich 16 por #$ -pe openmp 8

Aldatu threads OpenMP-ren zenbakia adierazten duen lerroa:

#$ -v OMP_NUM_THREADS=1 por  #$ -v OMP_NUM_THREADS=8

Aldatu exekuzioaren ilara, multi0-k bere ilara baitauka, multi izenekoa:

#$ -q multi

Eta, azkenik, aldatu erabili beharreko exekutagarriak, eta, horien ordez, erabili 32 biterako nodoetarakoak, multi0 32 biteko SMPa baita.

Paraleloak ez dira lan anitzak

Adibide hau lan bera jaurtikitzean oinarritzen da, baina 10 parametro desberdinekin, hau da, lan bera egiteko 10 eginkizun. Lana java programa da eta 64 biteko ilara jaurtikitzen da; halaber, 10 eginkizun direla adierazteko, -t 1-10:1 parametroa erabiltzen da

Adibide honetan MPIren erabilerari buruzko lerroak komentatu dira, ez baita lan paraleloa. 64 biteko java erabiltzen du.

Script hau txantiloitzat gordeta dago /opt/sge/examples/jobs/no_paralelo_multiple.sh direktorioan

#!/bin/bash

# SGE variables

# Shell used to run the task on SGE
#$ -S /bin/bash

# Name of the job
#$ -N java_vehicle_0_5_10I

# Specifies whether or not the standard error stream of the job 
# is merged into the standard output stream
#$ -j y

# SGE Environment Variables:
# HOME  Home directory on execution machine
# USER  User ID of job owner
# JOB_ID  Current job ID
# JOB_NAME  Current job name; see the -N option
# HOSTNAME  Name of the execution host
# TASK_ID  Array job task index number


# Path where will be stored output (-o option)
# and error files (opcion -e)
#$ -o $JOB_NAME.$JOB_ID.$TASK_ID

# With this option error and output files are stored in the 
# directory from where the job is submitted using qsub
#$ -cwd

# If the job is parallel, we indicate what kind of environment
# we use mpich for MPICH jobs or openmp for OPENMP jobs
# and the number of processes to use
# This parameter is comented because this is not a parallel job
##$ -pe mpich 16

# Request a maximum of 25 hours of execution time
#$ -l h_rt=25:00:00

# Request 1GB of RAM memory for the execution
#$ -l vf=256M

# Multiple jobs to execute from-to:step
# In this example ten jobs
#$ -t 1-10:1

# Which queues to use?
# There are multiple queues in the system:
# 32: queue for 32 bit jobs
# 64: queue for 64 bit jobs
# don: queue of Donostia (32 bit cluster)
# lej: queue of Lejona (64 bit cluster)
# vit: queue of Vitoria (64 bit cluster)
# multi: queue of Multi (4-way 32 bit SMP) 
#$ -q lej

# With the -V option all environment variables are exported
# to SGE but using -v only the specified variable is exported
# This job is not OpenMP
##$ -v OMP_NUM_THREADS=1

echo Running on host $HOSTNAME
echo Directory is `pwd`
ORIG_DIR=`pwd`

# create temporary directory to copy input and support files later
TEMP_DIR=/var/tmp/`whoami`.$$
echo TEMP_DIR es $TEMP_DIR
mkdir $TEMP_DIR
echo TMPDIR es $TMPDIR

# Variables needed to run the job 
DATA_FILE="vehicle_TRAIN_0_5.dbc vehicle_TEST_0_5.dbc"
BIN_FILES="elvira/ weka/"
INPUT_FILE="vehicle_TRAIN_0_5.dbc vehicle_TRAIN_0_5D.dbc"
OUTPUT_FILE="vehicle_0_5_01.log"
AUXILIAR_FILES="vehicle_TEST_0_5.dbc vehicle_TEST_0_5D.dbc"
BIN=/opt/java64/bin/java

# copy input and support files to a temporary directory on compute node
cp -R $BIN_FILES $DATA_FILE $TEMP_DIR
cd $TEMP_DIR

echo Init time is `date`

$BIN elvira.learning.preprocessing.Discretization $INPUT_FILE  5 2 true $AUXILIAR_FILES > vehicle_0_5_$SGE_TASK_ID.log

echo End time is `date`

# copy files back and clean up
cp * $ORIG_DIR
rm -rf $TEMP_DIR

Beste adibide honetan ikusten denez, parametroak aldatu egiten dira laneko 3 eginkizunetariko bakoitzerako, lanak parametro desberdinak baititu bakoitzarentzat. Adibidean kendu egin dira garrantzitsuak ez diren aldaera guztiak, eta ez dira sarrerako fitxategiak makinaren direktorio batean kopiatzen, lanak ez baitu disko gogorraren erabilera trinkorik egiten.

Lan hau 32 eta 64 biteko ilaretan jaurtikitzen da; izan ere, 32 biteko eta 64 biteko plataformetan dabilen 32 biteko programa erabiltzen du.

#!/bin/bash
#$ -S /bin/bash
#$ -t 1-3:1
#$ -cwd
#$ -j y
#$ -o uniform.$TASK_ID
#$ -q 64,32
args=(0 "bub_to_adap=0 intransit_pr=0" "bub_to_adap=3 intransit_pr=0" 
"bub_to_adap=0 intransit_pr=1")
./fsin ${args[$SGE_TASK_ID]} tpattern=uniform shotmode=1

Script hau txantiloitzat gordeta dago /opt/sge/examples/jobs/no_paralelo_multiple_array_argumentos.sh

Lanaren kontrola

Lanaren kontrolaren barruan, erabiltzaileak laneko SGE parametroren bal aldatzea, ezabatzea eta eskuliburua etetea edota berriro hastea sartzen dira. Lan bat aldatzeko, “egiteko” egoeran egon behar da, exekuzio fasera igaro barik. Horretara, hauxe exekutatu behar da:

qalter <id-trabajo> <parametro-a-modificar> ...

Hor id-lana lanaren zenbakia da, qsub-k bidaltzean emandako informazioaren arabera, edo, emaitza kontsultatzean, qstat-k emandako informazioaren arabera. Informazio gehiago lortzeko, lortu qalter-en eskuliburua (man).

Exekuzioan-etenda dagoen lana eteteko edota berriro hasteko, hauxe exekutatuko dugu:

Suspensión: qmod -sj <id-trabajo>
Reanudación: qmod -usj <id-trabajo>

Lana berriro planifikatzeko, exekutatu hauxe: qmod –rj<id-lana> (administratzaile pribilegioak behar dira). Lanen bat sistematik ezabatzeko (horren prozesuak hilda), qdel<id-lana> exekutatu behar da

Lanaren monitorizazioa

Ilaren sisteman ditugun lanen egoerak, kontsumitzen dituzten baliabideak eta makinen egoera monitorizatzeko aukera daukagu; gainera, kasu batzuetan, lana ez exekutatzearen edo hiltzearen zergatiak ere jakin ditzakegu. Horretarako, qstat komandoa erabili behar da eta horren erabilera nagusiak honako hauek dira:

qstat: Muestra el estado de todos los trabajos sin tener en cuenta el estado de las colas.
qstat -u <nombre-usuario>: Monitorización del estado de los trabajos de un usuario.
qstat -f: Lista toda la información sobre trabajos y colas para todos los usuarios.
qstat -F: Muestra el estado de todos los parámetros de todas las colas, por ejemplo, la carga, uso de memoria, swap, etc.
qstat -j <id-trabajo>: Da la razón de por qué un trabajo pendiente no ha sido planificado.

Komando horri buruzko informazio gehiago lortzeko, kontsultatu eskuliburuko orrialdeak (man qstat).

Kontrol politikak

Ondoren, ilaren kudeatzailean inplementaturik dauden erabilera-politikak azalduko ditugu. Politika horiek edozein unetan alda daitezke. Gaurkotzeak egiaztatzeko, kontsultatu orrialde honetan.

  • Gaur egun ilaretan ez dago denbora mugarik lanak exekutatzeko, gutxienez erabiltzaile batek asteak behar izaten baititu lan bat amaitzeko. Hori agian aldatu egingo da etorkizunean, unean uneko beharrizanen arabera. Nolanahi ere, komenigarria da lana exekutatzeko behar den denborarik dugun adieraztea, planifikatzaileari baliabide erabilgarriak eta exekuzio bikaina kalkulatzen laguntzeko:
#$ -l h_rt=12:00:00

Horrela, 12 exekuzio ordu erreserbatzen dira.

  • Ez dago mugarik erabili beharreko prozesadore kopuruan; hala eta guztiz ere, lehen esan dugunez, Grid-ek zenbait kluster dituenez, ez da komeni kluster desberdinak aldi berean erabiltzea, lan paraleloetan; izan ere, komunikazio paraleloa botila-lepo garrantzitsua izango da, klustera batetik bestera batez beste 100 km-ko distantzia baitago.
  • Memoriaren muga 2GBkoa da, don ilarara doazen lanetarako, eta 4GBkoa lej eta vit ilarara doazen lanetarako; multi-rako, berriz, 16GBkoa da. Lanak behar duen memoria zehazteko, hauxe erabili behar da:
#$ -l vf=256M (Este trabajo necesita 256MB)
  • Prozesu paraleloek berezko lehentasun handiagoa dute, serieko lanek baino, lan paraleloen bidalketa (klusterretara) sustatzeko. Nodo bakoitzeko memoria erabilgarria egiaztatzeko, komando hauxe erabili behar da:
qhost -F mem_free

1G behar duen lan batean laguntza eman dezaketen nodoen zerrenda ikusteko, hauxe egin behar da:

qhost -l mem_free=1G
  • Kluster bat edo guztiak erreserba daitezke lan jakinetarako, berariazko eskaria eginez gero, baldin eta i2BASQUE-en berariazko onespenarekin egiten bada. Erreserba bat eskatzeko, jarri kontaktuan i2BASQUE-ekin.
  • Une honetan, lej ilara publikoa da, baina isg erabiltzaileak egindako erreserba dauka. Horrela, norbait ilara hori erabiltzen badago, eta erabiltzaile horrek bertara lanen bat bidaltzen badu, ilara horretan exekutatzen ari diren lanak etenda geldituko dira berez, eta isg erabiltzailearen lana hasiko da exekutatzen. Lana amaitu ondoren, etenda gelditu diren lanen exekuzioarekin jarraituko da.

Bestalde, isg erabiltzaileak pribilegio hori edukitzeko, hau da, ilaran exekutatzen ari diren lanak etenda gelditzeko, ondoren adierazitakoaren arabera bidali beharko du bere lana:

qsub -l im trabajo.sh

Erreferentziak


Itzuli i2BASQUE-en GRID eskuliburura

Tresna pertsonalak
Beste hizkuntzetan