Execució de diferents tipus de treballs

En aquest punt s'inclouen diferents exemples de fitxers de descripció que il·lustren algunes de les situacions més habituals.

Execució de treballs que utilitzen arguments d'entrada i fitxers de dades

El fitxer de descripció pot ser d'aquest estil:


	# Inici del fitxer (aquesta línea és un comentari)
	Universe   = vanilla
	Executable = /usr1/USER_A/condor/hello
	Output     = hello.out
	Error	   = hello.err
	Log        = hello.log
	InitialDir = /usr1/USER_A/condor
	Arguments  = -1 -n
	Transfer_input _files = fitxer1 fitxer2
	Should_transfer_files = YES
	When_to_transfer_output = ON_EXIT
	Queue
	#final del fitxer

En aquest exemple s'han afegit camps que indiquen els arguments que cal passar-li al programa en el moment de la seva execució (camp Arguments) i els fitxers de dades d'entrada que cal enviar amb el treball (camp Transfer_input_files). El camp Should_transfer_files amb valor YES indica que Condor sempre mogui els fitxers (això és necessari per a les aules de la UAB però seria innecessari si es disposa d'un sistema d'arxius compartit). Si el treball genera fitxers de sortida, aquests seran enviats de tornada quan el treball acabi (indicat pel camp When_to_tranfer_output).

Execució de treballs que fan càlculs paramètrics

En aquest exemple es vol executar 10 instàncies d'un mateix programa hello. El resultat de cada execució es guardarà en un subdirectori diferent. Els subdirectoris han d'estar prèviament creats i en aquest exemple tenen nom dir_0, dir_1, ...dir_10. L'ordre Queue 10 és la que indica quantes instàncies s'enviaran. La macro $(Process) és la que serveix per "personalitzar" cada instància. Condor fa que $(Process) prengui automàticament 10 valors diferents: de 0 a 9. En l'exemple, aquest valor s'utilitza afegit al nom dels subdirectoris i dels fitxers de sortida. Així es diferenciaran els noms del directoris i es crearan fitxers de sortida amb noms diferents (els fitxers hello.err i hello.log tindran el mateix nom dins de cada subdirectori). El valor de $(Process) també se li passa com un argument al programa. Lògicament, si cada execució hagués de fer servir fitxers d'entrada diferents, aquests es podrien posar en els subdirectoris pertinents o usar noms diferents aprofitant la macro $(Process).


	# Inici del fitxer (aquesta línea és un comentari)
	Universe   = vanilla
	Executable = hello
	Output     = hello.out.$(Process)
	Error	   = hello.err
	Log        = hello.log
	Arguments  = -1 -n -$(Process)
	InitialDir = dir_$(Process)
	Queue 10
	#final del fitxer

Altres arguments útils per a descriure treballs

En el fitxer de descripció del treball es poden especificar força opcions per controlar l'execució dels treballs. La llista completa es pot consultar a la part del manual dedicada a la comanda condor_submit. En aquest apartat es comenten uns pocs arguments que poden ser útils en les primeres fases d'aprenentatge del sistema.

A) Especificar Requeriments especials mitjançant el camp Requirements

Aquest argument serveix per indicar alguna necessitat particular del nostre treball. Per exemple, posar això al fitxer de descripció

Requirements = (machine == condor_2.siee.uab.es)

indica que volem executar el treball només a la màquina condor_2.siee.uab.es

Per defecte, Condor acostuma a insertar una quants requeriments per defecte. Es poden veure si fem un condor_submit -v. Per l'exemple 1 de la pàgina 5, els requeriments introduïts per Condor serien:


Requirements = (OpSys == "LINUX") && (Arch == "INTEL") && (Disk >= DiskUsage)
               && ((Memory * 1024) >= ImageSize) && (HasFileTransfer)

Bàsicament, s'indica quin ha de ser el Sistema Operatiu de la màquina que executi el treball, el tipus de CPU, l'espai mínim de disc disponible, la mida de la seva memòria principal i que el dimoni Condor d'aquella màquina tingui capacitat de transferir fitxers remots.

B) Especificar preferències mitjançant el camp Rank

Aquest argument serveix per indicar-li a Condor algun criteri perquè intenti executar el nostre treball en alguna màquina que tingui alguna característica concreta. Per exemple, posar això al fitxer de descripció

Rank = KFLOPS

faria que Condor ordenés les màquines en ordre de preferència d'acord al seu valor en KFLOPS i, per tant, que el nostre treball s'executés en la màquina de major potència de càlcul disponible en aquell moment.

C) Rebre notificacions amb els camps Notification i Notify_user.

Aquests camps permeten controlar la recepció de missatges que Condor envia per informar del progrés dels treball.


Notify_user  = joan.ningu@uab.es
Notification = Error

Això faria que Condor enviés un missatge si el treball acabés erròniament (per defecte, Condor envia un missatge quan el treball acaba; això es pot desactivar posant la notification a never).

Execució de treballs amb capacitat d'interrupció/rearrencada

L'univers vanilla és el més bàsic perquè permet executar qualsevol tipus de treball. Per a treballs seqüencials Condor disposa d'un altre univers que proporciona funcionalitats superiors: és l'univers standard.

Un dels avantatges d'aquest univers són la possibilitat de que l'execució d'un treball sigui suspesa en una màquina i que pugui continuar en una màquina diferent en un instant de temps posterior com si no hagués hagut interrupció. Això es coneix com a checkpoint. L'altra avantatge és que el treball no necessita que els seus fitxers d'entrada i sortida es moguin. El treball els utilitza fent un accés remot i, per tant, el treball depèn menys de les limitacions d'espai de la màquina remota on s'executa el treball.

Val a dir que l'opció de checkpoint té algunes limitacions i que no totes les aplicacions se'n poden beneficiar. Per exemple, les aplicacions lo poden usar crides fork() o exec(), no poden tenir fitxers ni comunicacions TCP/IP oberts, etc (al manual hi ha la llista completa de limitacions).

Per utilitzar aquest univers el que cal fer primer és enllaçar la nostra aplicació amb les llibreries de Condor encarregades de fer el checkpoint i l'accés remot a fitxers. La comanda per fer això és la condor_compile.


condor_compile gcc -O -o my_program my_program.c       (per a programes C)
condor_compile pgf77 -O -o my_program my_program.f (per a programes    Fortran)
condor_compile ld -o my_program my_program.o      (per a programes objecte)
condor_compile make -f MyMakefile         (per a programes compilats amb make)

Un cop fet això, cal crear un fitxer de descripció on canvien alguns dels atributs. L'univers ha de ser standard i, en aquest cas no cal especificar que es moguin els fitxers perquè es llegiran i escriuran directament a la màquina des de la que s'envia el treball. Posteriorment, el treball s'envia de la mateixa forma que els treballs que s'han vist anteriorment.

Exemple: per enviar una aplicació hello.c en aquest univers, primer l'enllacem:

$ condor_compile gcc -O -o hello.std hello.c
LINKING FOR CONDOR : /usr/bin/ld -L/usr2/condor/lib -Bstatic -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o hello.std /usr2/condor/lib/condor_rt0.o /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crti.o /usr/lib/gcc-lib/i386-redhat-linu x/2.96/crtbegin.o -L/usr2/condor/lib -L/usr/lib/gcc-lib/i386-redhat-linux/2.96 -L/usr/lib/gcc-lib/i386-redhat-linux/2.96/../../.. /tmp/ccJwYS1A.o /usr2/condor/lib/libcondorzsyscall.a /usr2/condor/lib/libz.a -lgcc -lc -lnss_files -lnss_dns -lresolv -lc -lnss_files -lnss_dns -lresolv -lc -lgcc /usr/lib/gcc-lib/i386-redhat-linux/2.96/crtend.o /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crtn.o /usr2/condor/lib/libcondorc++support.a
/usr2/condor/lib/libcondorzsyscall.a(condor_file_agent.o): In function `CondorFileAgent::open(char const *, int, int)':
/scratch/cbuild/build/src/condor_ckpt/condor_file_agent.C:77: the use of `tmpnam' is dangerous, better use `mkstemp'
gcc: file path prefix `/usr2/condor/lib/' never used

I el fitxer de descripció seria de la forma:


	# Inici del fitxer (aquesta línea és un comentari)
	Universe   = standard
	Executable = hello.std
	Output     = hello.out.
	Error	     = hello.err
	Log        = hello.log
	Queue 
	#final del fitxer