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