Prácticas WMS

1. Prácticas WMS 17º Tutorial de Usuarios Antonio Gómez Iglesias

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

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

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

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

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

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

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

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

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

11. 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“;

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

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

14. ¡¡¡¡Comandos!!!! voms-proxy-init –vomsgilda edg-job-list-match --vogildafile.jdl edg-job-submit --vogilda -o file.idfile.jdl edg-job-status <job_id> edg-job-get-output <job_id> edg-job-cancel <job_id>

15. Un primer ejemplino [ Type = "job"; JobType = "normal"; Executable = "/bin/ls"; Arguments = "-la"; StdOutput = "sim.out"; StdError = "sim.err"; OutputSandbox = {"sim.out","sim.err"}; ]

16. Vamos a enviarlo Para enviarlo: edg-job-submit --vogilda -o mi_fichero.idmi_fichero.jdl Para consultar el estado: edg-job-status -imi_fichero.id Cuandohayaacabado: edg-job-get-output -imi_fichero.id --dir .

17. Un segundo ejemplino • Vamos a ejecutar un script en la grid (puedes inventarte el tuyo) • Un ejemplo helloworld.sh

18. 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; ]

19. Repetimos Para enviarlo: edg-job-submit --vogilda -o mi_fichero.idmi_fichero.jdl Para consultar el estado: edg-job-status -imi_fichero.id Cuandohayaacabado: edg-job-get-output -imi_fichero.id --dir .

20. 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` \|

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

22. GRACIAS¿Preguntas?