Prácticas WMS
17º Tutorial de Usuarios
Antonio Gómez Iglesias
17º Tutorial EELA
Oviedo | 19-20 de Noviembre de 2007
Ideas


Middleware LCG

La carga de trabajo es gestionada por el Resource Broker

No soporta trabajos paramétricos ni DAGs

Funciona
gLite

Soporta trabajos paramétricos y DAGs

En desarrollo (próximamente disponible)

Usa WMProxy para gestionar la carga de trabajo
17º Tutorial EELA
Oviedo | 19-20 de Noviembre de 2007
WMS

En la Grid LCG-2 un usuario puede enviar y cancelar trabajos, consultar
su estado y obtener el resultado de la ejecución de los trabajos. Todas
estas tareas están incluidas dentro de lo que se denomina Workload
Management. El LCG-2 ofrece dos UI para poder realizar estas tareas:


CLI.

Graphical User Interface.
Independientemente del interfaz, hay que proporcionar una descripción
de las características y requisitos del trabajo. El lenguaje que se utiliza
para esto se denomina Job Description Language (JDL).
17º Tutorial EELA
Oviedo | 19-20 de Noviembre de 2007
JDL

Los ficheros JDL se utilizan para describir los trabajos que se van a
ejecutar en la Grid. El JDL que se utiliza en LCG-2 es el lenguaje
Classified Advertisement (ClassAd), definido por el proyecto Condor.


Modelo de datos de ClassAd:

Flexible.

Extensible.

Puede representar servicios y restriciones de esos servicios.
El JDL se utiliza en LCG-2 para especificar las características y
restricciones de los trabajos. Esto es empleado posteriormente por el
proceso de match-making para seleccionar los recursos que utilizará el
trabajo.
17º Tutorial EELA
Oviedo | 19-20 de Noviembre de 2007
JDL

La sintaxis JDL consiste en instrucciones del tipo:


atributo = valor;
Las cadenas literales (para los valores) se encierran entre dobles comillas. En
general, presenta las mismas características que la sintaxis de C++:

“\”hola\” 1”

Los comentarios pueden empezar por # o por //, o /* y */ en caso de varias
líneas comentadas.

El JDL es sensible a espacios en blanco y tabulaciones, por lo que no puede
haber este tipo de elementos después de un ';' al final de una línea.
17º Tutorial EELA
Oviedo | 19-20 de Noviembre de 2007
JDL


Algunos atributos son obligatorios, mientras otros son opcionales.
Como es lógico, se debe indicar, al menos, el nombre del ejecutable, el nombre
del fichero en el que se guarda el resultado y un fichero de error (que puede ser el
mismo que el de resultado).
Executable = "test.sh";
StdOutput = "std.out";
StdError = "std.err";

Si se necesitan, se pueden pasar argumentos al ejecutable:
Arguments = "hello 10";

Para el caso de una entrada estandar (no obligatorio) se puede especificar:
StdInput = "std.in";

Si existen ficheros que deben ser enviados de la UI a los Wns, o viceversa, se
especifican:
InputSandbox = {"test.sh","std.in"};
OutputSandbox = {"std.out","std.err"};
17º Tutorial EELA
Oviedo | 19-20 de Noviembre de 2007
JDL

En este ejemplo el ejemplo test.sh también se transfiere a los WNs. Esto
no es necesario en los casos en los que el ejecutable ya se encuentre en
los WNs.

Se pueden utilizar comodines únicamente en el atributo InputSandbox.

La lista de ficheros se refiere al directorio actual de trabajo.

En el atributo OutputSandBox se pueden definir paths.

Ni el InputSandbox ni el OutputSandbox pueden contener dos ficheros
con el mismo nombre (aunque sean de paths diferentes) ya que en la
trasferencia se sobreescribirían.
17º Tutorial EELA
Oviedo | 19-20 de Noviembre de 2007
JDL

Si alguno de los ficheros que se incluyen en el InputSandbox tiene que ser
ejecutado, hay que ejecutar chmod +x en el WN sobre ese fichero antes de
poder ejecutarlo. Esto no es necesario para el fichero indicado en Executable.

Las variables de entorno del trabajo se pueden modificar mediante el atributo
Environment:
Environment = {"CMS_PATH=$HOME/cms", "CMS_DB=$CMS_PATH/cmdb"};

Algunos atributos JDL permiten especificar requisitos sobre los datos de
entrada que empleará el trabajo y también expresar como se generará la
información de salida. Estos atributos son:

InputData, DataAccessProtocol, OutputSE, OutputData, OutputFile,
LogicalFileName, StorageElement and ReplicaCatalog.
17º Tutorial EELA
Oviedo | 19-20 de Noviembre de 2007
JDL

El atributo Requirements se puede usar para expresar cualquier tipo de
restricción de los recursos en los que se ejecutará el trabajo.

Su valor es una expresión booleana que debe ser true para que el trabajo
se pueda ejecutar.

Sólo se puede especificar un atributo Requirements, de forma que si se
deben cumplir varias condiciones, todas ellas se deben anidar mediante
expresiones booleanas.
17º Tutorial EELA
Oviedo | 19-20 de Noviembre de 2007
JDL

Supongamos que queremos ejecutar un trabajo en un CE, usando PBS, y sólo en
aquellos WNs que tengan al menos dos CPUs. Esto se espcifica:

Requirements = other.GlueCEInfoLRMSType == "PBS" && other.GlueCEInfoTotalCPUs >
1;

donde el prefijo other. se usa para indicar que el atribut se refiere a
características del CE, no del trabajo.
Para enviar un trabajo a un CE específico:

Requirements = other.GlueCEUniqueID == "lxshare0286.cern.ch:2119/jobmanager-pbsshort";

Si se necesita que el trabajo se ejecute sobre un CE que tenga instalado un
software específico, se puede utilizar:

Requirements = Member("CMSIM-133",
other.GlueHostApplicationSoftwareRunTimeEnvironment);


Nota: El operador Member se usa para comprobar si el primer argumento es un
miembro del segundo.
Como regla general, los requisitos de un CE se inidcan mediante other.
17º Tutorial EELA
Oviedo | 19-20 de Noviembre de 2007
JDL
También se pueden utilizar expresiones regulares para especificar los requisitos.
Supongamos que un usuario quiere que todos sus trabajos se ejecuten en CEs que
estén bajo el dominio cern.ch. Esto se especificaría:
Requirements = RegExp("cern.ch", other.GlueCEUniqueId);
Lo contrario se haría:
Requirements = (!RegExp("cern.ch", other.GlueCEUniqueId));

Si necesitamos especificar requisitos que afecten a más de dos entidades (por ejemplo, el
trabajo, el CE y un SE), el RB utiliza un mecanismo de matchmaking especial, llamado
gangmatching. Esto es soportado por algunas funciones JDL: anyMatch, whichMatch,
allMatch. Un ejemplo de esto:

Supongamos que queremos ejecutar un trabajo en un CE con, al menos, 200 MB de
espacio disponible en un SE. La expresión JDL sería:
– Requirements = anyMatch(other.storage.CloseSEs,target.GlueSAStateAvailableSpace >
204800);

El atribute VirtualOrganisation representa otro medio de especificar la VO del usuario:
– VirtualOrganisation = “eumed“;
17º Tutorial EELA
Oviedo | 19-20 de Noviembre de 2007
JDL



El atributo RetryCount se utiliza para especificar cuántas veces va a intentar el
WMS reenviar un trabajo en caso de que se produzca un fallo en algún componente
de la Grid. El valor por defecto está indicado en el fichero:
$EDG_WL_LOCATION/etc/edg_wl_ui_cmd_var.conf.
El atributo MyProxyServer indica el Proxy Server que contiene el proxy de usuario
que utilizará WMS para renovar el proxy. Si no se incluye, será automáticamente
añadido cuando se envíe el trabajo, utilizando el Proxy Server por defecto del UI
para la VO del usuario.
La elección del CE en el que ejecutar el trabajo, además de basarse en los
requisitos indicados, se base en un ranking de CE. El CE con mayor ranking será el
seleccionado.

El usuario puede definir las condiciones del ranking con el atributo Rank. Por
ejemplo:

Rank = other.GlueCEStateFreeCPUs;

Rank = ( other.GlueCEStateWaitingJobs == 0 ? other.GlueCEStateFreeCPUs : other.GlueCEStateWaitingJobs);

En este último caso, el número de trabajos a la espera sólo se utiliza si no es nulo. El signo
'-' indica que el ranking disminuye a medida que aumenta el número de trabajos en espera.
Si no hay trabajos esperando, se utiliza como ranking el número de CPUs libres.
17º Tutorial EELA
Oviedo | 19-20 de Noviembre de 2007
JDL

Puedes ver todos los atributos, características, ejemplos,..., en la
documentación oficial de JDL.

Un ejemplo práctico:
https://grid.ct.infn.it/twiki/bin/view/GILDA/SimpleJobSubmissionWithRB
17º Tutorial EELA
Oviedo | 19-20 de Noviembre de 2007
¡¡¡¡Comandos!!!!
voms-proxy-init –voms gilda
edg-job-list-match --vo gilda file.jdl
edg-job-submit --vo gilda -o file.id file.jdl
edg-job-status <job_id>
edg-job-get-output <job_id>
edg-job-cancel <job_id>
17º Tutorial EELA
Oviedo | 19-20 de Noviembre de 2007
Un primer ejemplino
[
Type = "job";
JobType
= "normal";
Executable = "/bin/ls";
Arguments = "-la";
StdOutput = "sim.out";
StdError = "sim.err";
OutputSandbox = {"sim.out","sim.err"};
]
17º Tutorial EELA
Oviedo | 19-20 de Noviembre de 2007
Vamos a enviarlo
Para enviarlo:
edg-job-submit --vo gilda -o mi_fichero.id mi_fichero.jdl
Para consultar el estado:
edg-job-status -i mi_fichero.id
Cuando haya acabado:
edg-job-get-output -i mi_fichero.id --dir .
17º Tutorial EELA
Oviedo | 19-20 de Noviembre de 2007
Un segundo ejemplino

Vamos a ejecutar un script en la grid (puedes inventarte
el tuyo)

Un ejemplo
helloworld.sh
#!/bin/sh
/bin/echo "Hello World From Script"
17º Tutorial EELA
Oviedo | 19-20 de Noviembre de 2007
El JDL
[
Type = "job";
JobType = "normal";
Executable = "helloworld.sh";
StdOutput = "std.out";
StdError = "std.err";
InputSandbox = {"helloworld.sh"};
OutputSandbox = {"std.out","std.err"};
Rank = other.GlueCEStateFreeCPUs;
RetryCount = 7;
]
17º Tutorial EELA
Oviedo | 19-20 de Noviembre de 2007
Repetimos
Para enviarlo:
edg-job-submit --vo gilda -o mi_fichero.id mi_fichero.jdl
Para consultar el estado:
edg-job-status -i mi_fichero.id
Cuando haya acabado:
edg-job-get-output -i mi_fichero.id --dir .
17º Tutorial EELA
Oviedo | 19-20 de Noviembre de 2007
Un script un poco más complicado
echo \| Execution start: `date` \| Host: `hostname` \|
mkdir ./midir
lcg-cp --vo mi_VO lfn:/lfn_del_fichero_al_que_quiero_acceder file://donde_lo_quiero
chmod u+x ejecutables/ejecutable1
./ejecutable1
tar cvfz resultados.tgz ./*.out
echo \| Execution end: `date` \|
17º Tutorial EELA
Oviedo | 19-20 de Noviembre de 2007
Y de aquí, al infinito y más allá.
17º Tutorial EELA
Oviedo | 19-20 de Noviembre de 2007
GRACIAS
¿Preguntas?
17º Tutorial EELA
Oviedo | 19-20 de Noviembre de 2007