prácticas wms

17º Tutorial EELAOviedo | 19-20 de Noviembre de 2007

Prácticas WMS

17º Tutorial de Usuarios

Antonio Gómez Iglesias


Ideas

Middleware LCG

La carga de trabajo es gestionada por el Resource Broker

No soporta trabajos paramétricos ni DAGsNo soporta trabajos paramétricos ni DAGs

Funciona

gLite

Soporta trabajos paramétricos y DAGsSoporta trabajos paramétricos y DAGs

En desarrollo (próximamente disponible)

Usa WMProxy para gestionar la carga de trabajo


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


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.


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.


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"};


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.


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.


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.


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-

pbs-short";

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.


JDLTambié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“;


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.


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


¡¡¡¡Comandos!!!!

voms-proxy-init –voms gildavoms-proxy-init –voms gilda

edg-job-list-match --vo gilda file.jdledg-job-list-match --vo gilda file.jdl

edg-job-submit --vo gilda -o file.id file.jdl edg-job-submit --vo gilda -o file.id file.jdl

edg-job-status <job_id>edg-job-status <job_id>

edg-job-get-output <job_id>edg-job-get-output <job_id>

edg-job-cancel <job_id>edg-job-cancel <job_id>


Un primer ejemplino[

Type = "job";

JobType = "normal";

Executable = "/bin/ls";

Arguments = "-la";

StdOutput = "sim.out";

StdError = "sim.err";

OutputSandbox = {"sim.out","sim.err"};

]


Vamos a enviarlo

Para enviarlo:Para enviarlo:

edg-job-submit --vo gilda -o mi_fichero.id mi_fichero.jdledg-job-submit --vo gilda -o mi_fichero.id mi_fichero.jdl

Para consultar el estado:Para consultar el estado:

edg-job-status -i mi_fichero.idedg-job-status -i mi_fichero.id

Cuando haya acabado:Cuando haya acabado:

edg-job-get-output -i mi_fichero.id --dir .edg-job-get-output -i mi_fichero.id --dir .


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"


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;

]


Repetimos

Para enviarlo:Para enviarlo:

edg-job-submit --vo gilda -o mi_fichero.id mi_fichero.jdledg-job-submit --vo gilda -o mi_fichero.id mi_fichero.jdl

Para consultar el estado:Para consultar el estado:

edg-job-status -i mi_fichero.idedg-job-status -i mi_fichero.id

Cuando haya acabado:Cuando haya acabado:

edg-job-get-output -i mi_fichero.id --diredg-job-get-output -i mi_fichero.id --dir . .


Un script un poco más complicadoecho \| 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` \|


Y de aquí, al infinito y más allá.Y de aquí, al infinito y más allá.


GRACIAS

¿Preguntas?

prácticas wms

Documents