Gestion de trabajos

Gestión de trabajos con gLite

Comandos básicos

En primer lugar, supongamos que nuestro archivo JDL es script.jdl, que nuestro identificador proxy es dID y que el archivo jobId va a almacenar los identificadores de nuestros trabajos enviados. Después de esto, podemos usar una serie de comandos gLite para enviar, consultar, recoger, etc... dicho trabajo:

Delegación del certificado

Este comando delega tus credenciales (proxy) al Workload Management System (WMS), y asigna y mantine un nombre de identificación (automático o no), que será usado en las subsiguientes invocaciones de los comandos glite-wms-job-list-match y glite-wms-job-submit mediante dicho nombre delegado.

Sintaxis: glite-wms-job-delegate-proxy -d dID

Opciones:
-a Asigna un identificador automático a tu certificado.
-d dID Asigna a tu certificado el identificador dID.

Ten en cuenta que cuando usas la opción -a, tienes que especificar la opción -a para cada uso de los comandos glite-wms-job-submit y glite-wms-job-list-match. Sin embargo, utilizaciones masivas de esta opción no es muy recomendada, ya que cada vez se delega un nuevo proxy, y la delegación es una operación que consume recursos (y por consiguiente, tiempo), por lo que es mejor delegar el proxy una sóla vez con glite-wms-job-delegate-proxy -d dID y reusarla.

Identificación de CEs óptimos para tus trabajos

Sintaxis: glite-wms-job-list-match script.jdl

Opciones:
-a Delegación automática.
-d dID Usa una delegación explícita anterior.
Una de estas opciones debe de ser utilizada.
-o file Almacena la lista de los CEs en el archivo file.

Este comando chequea y lista cuales son los CEs que cumplen los requisitos de nuestro JDL para poder ejecutar con éxito nuestro trabajo.

Envio de trabajos

Sintaxis: glite-wms-job-submit script.jdl

Opciones:
-a Delegación automática.
-d dID Usa una delegación explícita anterior.
Una de estas opciones debe de ser utilizada.
-o jobId Añade el identificador del trabajo en el archivo jobId (lo crea si no existe).
-r CE Envía el trabajo directamente a un CE en particular. Con esta opción no se chequea la disponibilidad del CE en cuestión. Tampoco crea un archivo BrokerInfo.

Este comando manda trabajos al GRID. Al enviar el trabajo se genera un identificador para ese trabajo, que será único y que se tendrá que utilizar tanto para consultar el estado de dicho trabajo como para recoger los resultados. El formato es https://Lbserver_address[:port]/unique_string (ojo que no es una dirección web)

Consulta del estado de los trabajos

Sintaxis: glite-wms-job-status jobId1 ... jobIdN

Opciones:
-i jobId Lee el fichero donde se encuentran los identificadores de los trabajos.
-o file Guarda la salida en un fichero.
-v n Configura el nivel de información (0, 1 o 2).

Este comando devuelve la información del estado del trabajo (o trabajos).

Los posibles estados del trabajo son:

Estado	Definición
SUBMITTED	El trabajo enviado por el usuario pero no procesado por el Network Server (NS).
WAITING	El trabajo ha sido aceptado por el NS pero no procesado por el WMS. Se realiza un chequeo de recursos.
READY	El trabajo ha sido asignado a un CE pero aún no ha sido transferido.
SCHEDULED	El trabajo está en la cola de ejecución en el CE.
RUNNING	El trabajo está corriendo en un WN de la cola del CE seleccionado.
DONE	El trabajo ha finalizado sin errores Grid.
ABORTED	El trabajo ha sido abortado por el WMS (por ejemplo, porque era demasiado largo para la cola en la que corria, porque ha expirado el certificado, etc...).
CANCELLED	El trabajo ha sido cancelado por el usuario.
CLEARED	El "OutputSandbox" ha sido transferido a un User Interface.

Información del registro de trabajos

Este comando aporta información del progreso de uno o más trabajos. La salida típica es:

Sintaxis: glite-wms-job-logging-info jobId1 ... jobIdN

Opciones:
-i jobId Lee el fichero donde se encuentran los identificadores de los trabajos.
-o file Guarda la salida en un fichero.
-v n Configura el nivel de información (0, 1 o 2).

********************************************************************** 
LOGGING INFORMATION: 
 
Printing info for the Job: https://lxshare0310.cern.ch:9000/C_CBUJKqc6Zqd4clQaCUTQ 
 
        - - - 
 Event: RegJob 
- source               =    UserInterface 
- timestamp            =    Fri Feb 20 10:30:16 2004 
        - - - 
 Event: Transfer 
- destination          =    NetworkServer 
- result               =    START 
- source               =    UserInterface 
- timestamp            =    Fri Feb 20 10:30:16 2004 
        - - - 
 Event: Transfer 
- destination          =    NetworkServer 
- result               =    OK 
- source               =    UserInterface 
- timestamp            =    Fri Feb 20 10:30:19 2004 
        - - - 
 Event: Accepted 
- source               =    NetworkServer 
- timestamp            =    Fri Feb 20 10:29:17 2004 
        - - - 
 Event: EnQueued 
- result               =    OK 
- source               =    NetworkServer 
- timestamp            =    Fri Feb 20 10:29:18 2004 
[...]

Seguimiento de trabajos

El seguimiento de trabajos permite ver el "output" del trabajo mientras éste está corriendo. Para poder habilitar esta característica hay que añadir los atributos PerusalFileEnable y PerusalTimeInterval al script JDL antes de mandar el trabajo. Por ejemplo:

  PerusalFileEnable = true;
  PerusalTimeInterval = 120;

Esto hace que el WN suba regularmente (el intervalo de tiempo se define con PerusalTimeInterval en segundos) una copia del "output" del trabajo al WMS cuando se usa el comando glite-wms-job-perusal -set. De modo que para habilitar la consulta tenemos:

Sintaxis: glite-wms-job-perusal --set -f file_1 ...  -f file_n -i jobId1 ... jobIdn

Opciones:
-f Especifica el nombre de fichero a recuperar.

y para recuperar el fichero o los ficheros (¡usar un comando por fichero!):

Sintaxis: glite-wms-job-perusal --get -f file ...  -i jobId

Opciones:
-all Recupera el fichero entero y no sólo una parte (que es lo que se hace por defecto).
--dir directory Guarda el "output" en el directory directory. Por defecto, lo hace bajo /tmp.

Nota: Obviamente esta capacidad tiene sus consecuencias a nivel de rendimiento. Es una opción para depurar ciertos aspectos de tus trabajos y no es recomendable para producción ya que tener cientos de trabajos mandando regularmente archivos de seguimiento pueden saturar el WMS.

Una vez que el trabajo ha sido enviado, los archivos que pueden seguirse son los especificados con la opción --set.

Por último, el seguimiento de trabajos puede deshabilitarse con la opción -unset.

Sintaxis: glite-wms-job-perusal --unset jobId

Es posible utilizar el comando glite-wms-job-perusal para examinar el estado final de los archivos una vez el trabajo haya finalizado. Si se quiere usar esta característica "post-mortem", se debe de habilitar el seguimiento en el JDL activar el seguimiento con glite-wms-job-perusal --set pero dejar la recuperación de los archivos hasta que el trabajo haya finalizado.

Cancelación de trabajos

Sintaxis: glite-wms-job-cancel jobId1 ... jobIdN

Opciones:
-i jobId Lee el fichero donde se encuentran los identificadores de los trabajos.

Este comando cancela el trabajo (o trabajos) especificados en el jobId

Nota: Si el trabajo no ha llegado aún al CE (es decir, está en WAITING o READY), la petición puede ser ignorada y el trabajo puede llegar a correr aun cuando el mensaje de "successful cancellation" aparezca. En estos casos, simplemente hay que volver a pedir su cancelación cuando esté en SCHEDULED o RUNNING.

Recuperación de trabajos

Sintaxis: glite-wms-job-output jobId1 ... jobIdN

Opciones:
-i jobId Lee el fichero donde se encuentran los identificadores de los trabajos.
--dir directory Guarda el "output" en el directory directory. Por defecto, lo hace bajo /tmp.

Este comando recupera el "output" del trabajo, obviamente para trabajos con estado DONE al UI. Si no se recupera el "output", éste se borra del WMS aproximadamente una semana después de la finalización del trabajo.

-- CarlosEscobar - 27 May 2010