Uso básico del cluster
Control de versiones
| Fecha | Actividad | Autor |
|---|---|---|
| 24/07/2010 | Publicación inicial | Jorge Iván Meza Martínez. |
| 03/11/2010 | Nueva sección: Determinar la finalización de los trabajos enviados | Jorge Iván Meza Martínez. |
Introducción
En este capítulo se ejecuta un proceso simple en el cluster para verificar su funcionamiento. También se muestran las herramientas principales para consultar el pool de servidores, enviar trabajos, consultar la cola de trabajos y remover trabajos de la misma.
El envío de los trabajos al cluster debe realizarse (por seguridad) por usuarios sin privilegios, con es el caso del usuario invitado creado anteriormente.
Tiempo estimado
40 minutos
Precondición
- Condor se encuentra instalado y funcionando correctamente en el nodo principal y en los nodos trabajadores.
Supuestos
- Los 3 nodos se encuentran activos.
Verificar el pool de servidores del cluster
El pool de servidores hace referencia a los nodos del cluster que se encuentran conectados al nodo prinicipal. En este caso, deberán estar conectados los dos nodos trabajadores: c-wn1 y c-wn2.
Para verificar el estado del pool de servidores se debe ejecutar el siguiente comando desde el nodo c-head.
$ condor_status
Name OpSys Arch State Activity LoadAv Mem ActvtyTime
c-wn1.micluster.co LINUX INTEL Unclaimed Idle 0.360 249 0+00:05:04
c-wn2.micluster.co LINUX INTEL Unclaimed Idle 0.300 249 0+00:05:04
Total Owner Claimed Unclaimed Matched Preempting Backfill
INTEL/LINUX 2 0 0 2 0 0 0
Total 2 0 0 2 0 0 0
Enviar un trabajo simple al cluster
La primera prueba de ejecución de trabajos que es interesante realizar, es el solicitar el hostname del equipo que atienda el trabajo ya que se lanza desde el nodo interactivo (en este caso es el mismo c-head) pero deberá ser atendido por uno de los nodos trabajadores, así que si el cluster funciona correctamente tendrá que devolver el hostname de c-wn1 o c-wn2 según cual de ellos haya atendido la solicitud del cluster.
El primer paso para enviar un trabajo al cluster es la creación del archivo de envío (submit) con la especificación de la solicitud. En este caso es la siguiente.
$ vi hostname.submit
- hostname.submit
executable = /bin/hostname universe = vanilla log = _hostname.log output = _hostname.out error = _hostname.err queue
En términos generales, se le está pidiendo al cluster que ejecute el proceso /bin/hostname y que genere los archivos log, out y err con la información de registro, salida estándar y salida de error respectivamente.
Para enviar el trabajo al cluster se ejecuta el siguiente comando.
$ condor_submit hostname.submit
Submitting job(s).
Logging submit event(s).
1 job(s) submitted to cluster 1.
Verificar la cola de trabajos del cluster
Es posible consultar el estado de la cola de trabajos del cluster con el siguiente comando, el cual si se ejecuta rápidamente podrá verificar la existencia del trabajo recién enviado y que no ha sido procesado aún.
$ condor_q
-- Submitter: c-head.micluster.com : <192.168.1.220:9593> : c-head.micluster.com
ID OWNER SUBMITTED RUN_TIME ST PRI SIZE CMD
1.0 invitado 7/23 14:23 0+00:00:00 I 0 0.0 hostname
1 jobs; 1 idle, 0 running, 0 held
Consultar el resultado de la ejecución del trabajo
La ejecución del trabajo genera los archivos solicitados en el archivo submit. Como se mencionó anteriormente, se solicitó se almacenara la información de errores (err), registro (log) y salida estándar (out).
$ ls -l total 28 -rw-rw-r-- 1 invitado invitado 0 jul 23 14:23 _hostname.err -rw-rw-r-- 1 invitado invitado 604 jul 23 14:23 _hostname.log -rw-rw-r-- 1 invitado invitado 131 jul 23 14:23 hostname.submit -rw-rw-r-- 1 invitado invitado 20 jul 23 14:23 _hostname.out
En este caso el archivo de errores (_hostname.err) se encuentra vacío ya que la ejecución del programa no escribió nada a través de stderr.
El contenido del archivo de registro (_hostname.log) muestra cuando el proceso fue recibido por la cola, inicio su ejecución y cuando esta finalizó.
$ cat _hostname.log 000 (001.000.000) 07/23 14:23:46 Job submitted from host: <192.168.1.220:9593> ... 001 (001.000.000) 07/23 14:23:58 Job executing on host: <192.168.1.221:9023> ... 005 (001.000.000) 07/23 14:23:58 Job terminated. (1) Normal termination (return value 0) Usr 0 00:00:00, Sys 0 00:00:00 - Run Remote Usage Usr 0 00:00:00, Sys 0 00:00:00 - Run Local Usage Usr 0 00:00:00, Sys 0 00:00:00 - Total Remote Usage Usr 0 00:00:00, Sys 0 00:00:00 - Total Local Usage 0 - Run Bytes Sent By Job 0 - Run Bytes Received By Job 0 - Total Bytes Sent By Job 0 - Total Bytes Received By Job ...
En el archivo de salida estándar (_hostname.out) deberá aparecer, en este caso específico, el hostname del nodo que efectivamente proceso el trabajo.
$ cat _hostname.out
c-wn1.micluster.com
Consultar la información de los trabajos completados
Para consultar la información histórica de los trabajos ya completados utilice el comando condor_history de la siguiente manera.
$ condor_history
ID OWNER SUBMITTED RUN_TIME ST COMPLETED CMD
1.0 invitado 7/23 14:23 0+00:00:01 C 7/23 14:23 /bin/hostname
2.0 invitado 7/23 14:56 0+00:00:00 C 7/23 14:56 /bin/hostname
3.0 invitado 7/23 14:56 0+00:00:00 X ??? /bin/hostname
4.0 invitado 7/23 16:25 0+00:00:02 C 7/23 16:25 /home/invitado/
Remover trabajos de la cola de trabajos
Para remover un trabajo de la cola del cluster es necesario identificar el ID específico del trabajo, esto se logra con la ejecución de condor_q.
$ condor_q
-- Submitter: c-head.micluster.com : <192.168.1.220:9593> : c-head.micluster.com
ID OWNER SUBMITTED RUN_TIME ST PRI SIZE CMD
3.0 invitado 7/23 14:56 0+00:00:00 I 0 0.0 hostname
1 jobs; 1 idle, 0 running, 0 held
Con el ID se invoca el comando condor_rm para eliminarlo de la cola.
$ condor_rm 3.0 Job 3.0 marked for removal
Determinar la finalización de los trabajos enviados
Conocer cuando un trabajo (junto con sus subtrabajos) ha finalizado es un elemento importante para la automatización de tareas en el cluster mediante scripts. Esto no es una tarea trivial ya que al enviarse la tarea al cluster (con condor_submit) la ejecución se envía al background y sólo es posible conocer el estado de la tarea mediante la consulta de la cola de trabajos (con condor_q).
Para esto se utiliza el comando condor_wait cuya función es la de esperar mientras se finaliza la ejecución de un trabajo, esto se implementa mediante la revisión del archivo de registro (log) asociado al trabajo específico.
Para determinar cuando ha terminado el trabajo propietario del archivo de registro trabajoLargo.log es necesario ejecutar el siguiente comando.
$ condor_wait trabajoLargo.log
De esta manera es posible medir cuantitativamente el tiempo que permanece la tarea en el clúster, sin embargo este tiempo no corresponde exactamente a la ejecución de la misma ya que incluye además los tiempos de transporte de la información en la red y los tiempos que permanece el trabajo en las colas del clúster.
$ time condor_wait trabajoLargo.log
