Condor inicia de manera exitosa manualmente, sin embargo no se inicia automáticamente durante el inicio del sistema operativo.

Los logs del nodo, tanto de Condor como del sistema operativo, no muestran ningún mensaje de error, sin embargo se muestra el siguiente mensaje durante el inicio de los servicios del sistema operativo.

Neither the enviroment variable CONDOR_CONFIG,
/etc/condor, ~condor/ contain a condor_config source.
Either set CONDOR_CONFIG to point to a valid config source,
or put a “condor_config” file /etc/condor or ~condor/

Explicación.

Condor durante su inicio automático no está encontrando su configuración básica.

Solución.

Especifique cual es el archivo de configuración básica de Condor mediante la especificación de la variable de ambiente CONDOR_CONFIG o mediante la ubicación (a través de un enlace) del archivo, ya sea en /etc/condor (ubicación especificada con el parámetro --local-dir durante la instalación) o en ~condor/.

Para este caso, el problema se resolverá mediante la segunda opción: creando un enlace al archivo de configuración desde ~condor/.

# ln -s /opt/condor/current/etc/condor_config ~condor/condor_config

Condor no inicia en un nodo específico.  En sus logs se encuentran mensajes como los siguientes.

CollectorLog

08/11 21:59:35 AUTHENTICATE: handshake failed!
08/11 21:59:35 ERROR: SECMAN:2004:Failed to create security session to <192.168.1.230:9180> with TCP.|AUTHENTICATE:1002:Failure performing handshake|AUTHENTICATE:1004:Failed to authenticate using PASSWORD

MasterLog

08/11 22:00:36 DC_AUTHENTICATE: authenticate failed: AUTHENTICATE:1002:Failure performing handshake|AUTHENTICATE:1004:Failed to authenticate using PASSWORD
08/11 22:00:36 condor_write(): Socket closed when trying to write 297 bytes to <192.168.1.230:45838>, fd is 10
08/11 22:00:36 Buf::write(): condor_write() failed
08/11 22:00:36 SECMAN: Error sending response classad!
08/11 22:00:36 error: SEC_PASSWORD_FILE must be owned by Condor’s real uid

Explicación.

El archivo donde se almacena la contraseña del cluster para la autenticación basada en las mismas, tiene un propietario o unos permisos incorrectos.

Solución.

Identificar la ubicación del archivo de contraseñas.

# condor_config_val SEC_PASSWORD_FILE

/etc/condor/condor_credential

Verificar sus permisos y propietario.

# ls -l /etc/condor/condor_credential

-rw-r--r-- 1 condor root 256 Aug 11 21:47 /etc/condor/condor_credential

Corregir sus permisos y propietario.

# chown root:root /etc/condor/condor_credential

# chmod 600 /etc/condor/condor_credential

# ls -l /etc/condor/condor_credential

-rw------- 1 root root 256 Aug 11 21:47 /etc/condor/condor_credential

Al intentar enlazar un programa en C/C++ con las librerías de Condor mediante condor_compile se obtiene el siguiente mensaje de error.

$ condor_compile gcc test.c -o test

LINKING FOR CONDOR : /usr/bin/ld -L/opt/condor/current/lib -Bstatic --eh-frame-hdr -m elf_x86_64 --hash-style=gnu -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o test /opt/condor/current/lib/condor_rt0.o /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/crti.o /usr/lib/gcc/x86_64-redhat-linux/4.1.2/crtbeginT.o -L/opt/condor/current/lib -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2 -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2 -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 /tmp/ccawslhh.o /opt/condor/current/lib/libcondorzsyscall.a /opt/condor/current/lib/libcondor_z.a /opt/condor/current/lib/libcomp_libstdc++.a /opt/condor/current/lib/libcomp_libgcc.a /opt/condor/current/lib/libcomp_libgcc_eh.a --as-needed --no-as-needed -lcondor_c -lcondor_nss_files -lcondor_nss_dns -lcondor_resolv -lcondor_c -lcondor_nss_files -lcondor_nss_dns -lcondor_resolv -lcondor_c /opt/condor/current/lib/libcomp_libgcc.a /opt/condor/current/lib/libcomp_libgcc_eh.a --as-needed --no-as-needed /usr/lib/gcc/x86_64-redhat-linux/4.1.2/crtend.o /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/crtn.o
/usr/bin/ld: skipping incompatible /opt/condor/current/lib/libcondor_c.a when searching for -lcondor_c
/usr/bin/ld: skipping incompatible /opt/condor/current/lib/libcondor_c.a when searching for -lcondor_c
/usr/bin/ld: cannot find -lcondor_c
collect2: ld returned 1 exit status

Explicación.

La arquitectura de la distribución de Condor no coincide con la de la máquina en la cual se instaló.

Solución.

Identifique la arquitectura de la máquina en la cual se está instalando Condor de la siguiente manera.

# uname -i

x86_64

Verifique que esta coincida con la arquitectura del paquete de Condor que se descargó del sitio web.

condor-*-linux-x86-rhel5-dynamic.tar.gz
condor-*-linux-x86_64-rhel5-dynamic.tar.gz

Reinstale Condor con la arquitectura correcta.

Al curso asistieron 18 participantes quienes representaban a las principales instituciones educativas y de investigación del eje cafetero que están interesadas en la computación de alto desempeño.

Los temas tratados durante el curso fueron los siguientes.

1. Introducción al proyecto y conceptual.
2. Instalación del cluster.
   1. Instalación del sistema operativo Scientific Linux 5.5.
   2. Preparación básica del nodo cabeza y de los nodos trabajadores.
   3. Configuración del servicio de SSH.
   4. Configuración del servicio de NFS.
   5. Configuración de las cuentas de usuario.
3. Instalación de Condor en el nodo cabeza y en los nodos trabajadores.
4. Pruebas y uso básico del cluster.
5. Universos del cluster.
   1. Vanilla.
   2. Standard.
   3. Java.
6. Seguridad del cluster con firewall y host.allow/deny.

Se realizó también un práctica adicional que consistió en el cambio del hostname de los nodos, analizándolo desde la perspectiva de su implicación en la configuración del cluster.  La práctica final que consistía en la instalación individual de nodos en máquinas virtuales basadas en VirtualBox no pudo completarse satisfactoriamente debido a problemas con el hardware con que disponíamos en las salas de cómputo.

Participantes del curso de clusters y grids en julio de 2010 en la Universidad Autónoma de Manizales

Durante los tres días siguientes al curso de clusters contamos con la presencia del ingeniero Cesar Orlando Diaz quien en representación del proyecto Grid Colombia, complementó la jornada al dictarnos un curso práctico acerca de la conformación de la grid basada en los clusters que habíamos preparado previamente.

En este segundo curso se trataron los siguientes temas.

1. Introducción conceptual.
2. Instalación del cliente de la grid.
3. Tipos de certificados requeridos.
4. Instalación y configuración del computer element (CE).
5. Instalación y configuración del grid user management system (GUMS).

Participantes del curso de clusters y grids en julio de 2010 en la Universidad Autónoma de Manizales

En lo personal quiero agradecer a los participantes del curso por la asistencia al evento y felicitarlos por contar con la visión necesaria para aprovechar estas nuevas tecnologías, ya presentes en nuestra región: redes académicas de alta velocidad, computación de alto desempeño y mallas computacionales, a su quehacer diario, encontrando mejores formas de hacer las cosas, innovando y mejorando el progreso de nuestra región.

Los contenidos del curso y en general, del proyecto GridUAM pueden ser consultados en su Wiki, el cual está en constante complemento y actualización.  De igual manera recomiendo que sea consultado el Wiki de GridColombia para conocer mas información acerca de este proyecto.

Hay un detalle muy simple que debe tenerse en cuenta cuando se ejecutan en el cluster programas escritos en C y C++ con respecto al manejo de los parámetros de línea de comando que recibe el programa.  En estos lenguajes siempre el primer parámetro, es decir argv[0], recibe el nombre y ruta del archivo ejecutable del programa que se está corriendo.  Muchos desarrolladores utilizan este valor para conocer alguna información interesante como el directorio hogar del programa.

En Condor, debido a su arquitectura y método de ejecución de los procesos en los nodos trabajadores, esto tiene una variación que debe ser tenida en cuenta.  El primer parámetro de línea de comando de los trabajos que se ejecutan en el cluster no hará referencia al programa como tal sino al condor_exec quien es el proceso que efectivamente ejecuta el programa en el nodo trabajador.

When Condor starts up your job, it renames argv[0] (which usually contains the name of the program) to condor_exec. This is convenient when examining a machine’s processes with the Unix command ps; the process is easily identified as a Condor job.  Unfortunately, some programs read argv[0] expecting their own program name and get confused if they find something unexpected like condor_exec.
Tomado de la sección 2.15.1 del manual de Condor: Potencial problems, Renaming of argv[0].

Verificación.

Crear el programa de prueba.

$ vi argv0.c

#include <stdio.h>

int main(int argc, char* argv[])
{
 int i = 0;

 printf("\nParameters count: %d.\n\n", argc);

 for(i=0; i<argc; i++)
 {
    printf("\tParameter '%d': %s.\n", i, argv[i]);
 }

 printf("\nDone!\n\n");

 return 0;
}

Compilarlo (de una vez con soporte para el Cluster).

$ condor_compile gcc argv0.c -o argv0

Ejecución local.

$ ./argv0 p1 p2 p3 p4

Condor: Notice: Will checkpoint to ./argv0.ckpt
Condor: Notice: Remote system calls disabled.

Parameters count: 5.

Parameter ’0′: ./argv0.
Parameter ’1′: p1.
Parameter ’2′: p2.
Parameter ’3′: p3.
Parameter ’4′: p4.

Done!

Creación del archivo de envío de trabajos al cluster.

$ vi argv0.submit

executable = argv0
universe   = vanilla
output     = argv0.out
error      = argv0.error
log        = argv0.log
arguments  = p1 p2 p3 p4

Enviar el trabajo al cluster.

$ condor_submit argv0.submit

Verificar la salida estándar del trabajo ejecutado.

$ cat argv0.out

Parameters count: 5.

Parameter ’0′: condor_exec.exe.
Parameter ’1′: p1.
Parameter ’2′: p2.
Parameter ’3′: p3.
Parameter ’4′: p4.

Done!

En el presente artículo se trata el tema de crear dos nuevos nodos trabajadores (c-wn3 y c-wn4) también virtualizados con KVM y agregarlos al cluster para aumentar su capacidad de cómputo.

Clonar las nuevas máquinas virtuales.

Gracias a las facilidades que provee la virtualización es posible evitar la necesidad de repetir la gran mayoría de tareas de instalación y configuración de los nodos al clonar a uno de ellos, en este caso crearemos los nuevos nodos a partir del c-wn1.

Desde el servidor de máquinas virtuales ejecutar los siguientes comandos.

ADVERTENCIA: para que la clonación se pueda realizar, la máquina virtual de orígen, en este caso c-wn1 deberá estar apagado.

$ virt-clone --connect=qemu:///system  \
-o c-wn1 \
-n c-wn3 \
-f /u/vms/c-wn3.img

$ virt-clone --connect=qemu:///system  \
-o c-wn1 \
-n c-wn4 \
-f /u/vms/c-wn4.img

Iniciar las máquinas virtuales.

Nuevamente desde el servidor es necesario ejecutar los siguientes comandos para iniciar las máquinas virtuales de los nodos trabajadores para su posterior configuración.

$ virsh start c-wn3

$ virsh start c-wn4

Conectarse a las máquinas virtuales.

Desde el equipo cliente que se utiliza para la administración de las máquinas virtuales ejecute los siguientes comandos.

$ virt-viewer -c qemu+ssh://ivy/system c-wn3

$ virt-viewer -c qemu+ssh://ivy/system c-wn4

Actualizar el hostname.

Editar el archivo /etc/sysconfig/network de cada uno de los nuevos nodos y actualizarlo con su información específica.  Para el nodo c-wn3 utilizar el siguiente contenido.

NETWORKING=yes
NETWORKING_IPV6=no
GATEWAY=192.168.1.1
HOSTNAME=c-wn3.jorgeivanmeza.com

Para c-wn4 utilizar el siguiente contenido.

NETWORKING=yes
NETWORKING_IPV6=no
GATEWAY=192.168.1.1
HOSTNAME=c-wn4.jorgeivanmeza.com

Actualizar la dirección IP.

Editar el archivo /etc/sysconfig/network-scripts/ifcfg-eth0 de cada uno de los nuevos nodos y actualizarlo con su información específica.  Para el nodo c-wn3 utilizar el siguiente contenido.

DEVICE=eth0
BOOTPROTO=static
TYPE=Ethernet
ONBOOT=yes
HWADDR=<dejar la existente>
NETMASK=255.255.255.0
IPADDR=192.168.1.213

Para c-wn4 utilizar la siguiente información.

DEVICE=eth0
BOOTPROTO=static
TYPE=Ethernet
ONBOOT=yes
HWADDR=<dejar la existente>
NETMASK=255.255.255.0
IPADDR=192.168.1.214

Reiniciar las máquinas c-wn3 y c-wn4 para que los cambios en la configuración recién realizados tengan efecto.

Actualizar la configuración de hosts.

Editar el archivo /etc/hosts del servidor c-head y actualizarlo con la información específica de cada uno de los nodos.

# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1    localhost.localdomain localhost
::1          localhost6.localdomain6 localhost6

192.168.1.210    c-head.jorgeivanmeza.com c-head c-nfs.jorgeivanmeza.com c-nfs
192.168.1.211    c-wn1.jorgeivanmeza.com c-wn1
192.168.1.212    c-wn2.jorgeivanmeza.com c-wn2
192.168.1.213    c-wn3.jorgeivanmeza.com c-wn3
192.168.1.214    c-wn4.jorgeivanmeza.com c-wn4

Posteriormente es necesario replicar esta nueva especificación de los hosts a los demás nodos del cluster, para esto es necesario que todos se encuentren en ejecución.

# scp /etc/hosts c-wn1:/etc/hosts

# scp /etc/hosts c-wn2:/etc/hosts

# scp /etc/hosts c-wn3:/etc/hosts

# scp /etc/hosts c-wn4:/etc/hosts

Configurar la autenticación basada en el huésped para root.

En el nodo cabeza (c-head) ejecutar los siguientes comandos para listar las llaves de los hosts conocidos en el cluster.

# cd /root

# ssh-keyscan -t rsa,dsa c-head c-head.jorgeivanmeza.com c-nfs c-nfs.jorgeivanmeza.com c-wn1 c-wn1.jorgeivanmeza.com c-wn2 c-wn2.jorgeivanmeza.com c-wn3 c-wn3.jorgeivanmeza.com c-wn4 c-wn4.jorgeivanmeza.com > ssh_known_hosts

# mv ssh_known_hosts /etc/ssh/ssh_known_hosts

# chown root:root /etc/ssh/ssh_known_hosts

# chmod 644 /etc/ssh/ssh_known_hosts

Propagar el archivo ssh_known_hosts a los nodos trabajadores.

# scp /etc/ssh/ssh_known_hosts c-wn1:/etc/ssh/ssh_known_hosts

# scp /etc/ssh/ssh_known_hosts c-wn2:/etc/ssh/ssh_known_hosts

# scp /etc/ssh/ssh_known_hosts c-wn3:/etc/ssh/ssh_known_hosts

# scp /etc/ssh/ssh_known_hosts c-wn4:/etc/ssh/ssh_known_hosts

Creación del archivo de .shosts.

En el nodo cabeza (c-head) ejecutar los siguientes comandos.

# cut -d’ ‘ -f1 < /etc/ssh/ssh_known_hosts|sort -u | grep -v , > shosts

# mv shosts /root/.shosts

# chown root:root /root/.shosts

# chmod 600 /root/.shosts

Propagar el archivo .shosts a los nodos trabajadores.

# scp /root/.shosts c-wn1:/root/.shosts

# scp /root/.shosts c-wn2:/root/.shosts

# scp /root/.shosts c-wn3:/root/.shosts

# scp /root/.shosts c-wn4:/root/.shosts

Definir los archivos de configuración de Condor para los nuevos nodos del cluster.

En el nodo cabeza (c-head) ejecutar los siguientes comandos para especificar archivos de configuración según los hostnames de los nuevos nodos.

# cd /nfs/condor/condor-etc/

# ln -s condor_config.worker condor_config.c-wn3

# ln -s condor_config.worker condor_config.c-wn4

Establecer las ubicaciones locales necesarias para almacenar la información de registros y colas para los nuevos nodos.

# cd ~condor/hosts

# mkdir -p c-wn3/execute c-wn3/log c-wn3/spool

# mkdir -p c-wn4/execute c-wn4/log c-wn4/spool

# chmod a+rwx c-wn3/execute c-wn4/execute

# chmod +t c-wn3/execute c-wn4/execute

# chown -R condor:condor ~condor/hosts/c-wn3 ~condor/hosts/c-wn4

Se recomienda reiniciar el servicio de Condor o la máquina completa para garantizar que todos las modificaciones recién realizadas sean tenidos en cuenta.

Verificar la inclusión de los nuevos nodos al cluster.

Desde el nodo cabeza del cluster (c-head) ejecutar los siguientes comandos para verificar su pool de nodos.

# condor_status

Name               OpSys      Arch   State     Activity LoadAv Mem   ActvtyTime

c-wn1.jorgeivanmez LINUX      X86_64 Unclaimed Idle     1.780   246  0+00:00:04
c-wn2.jorgeivanmez LINUX      X86_64 Unclaimed Idle     2.410   246  0+00:00:04
c-wn3 .jorgeivanmez LINUX      X86_64 Unclaimed Idle     1.830   246  0+00:00:04
c-wn4 .jorgeivanmez LINUX      X86_64 Unclaimed Idle     2.240   246  0+00:00:04
Total Owner Claimed Unclaimed Matched Preempting Backfill

X86_64/LINUX     4     0       0         4       0          0        0

Total     4     0       0         4       0          0        0

# condor_status -java

Name               JavaVendor Ver    State     Activity LoadAv Mem   ActvtyTime

c-wn1.jorgeivanmez Sun Micros 1.6.0_ Unclaimed Idle     1.780   246  0+00:00:04
c-wn2.jorgeivanmez Sun Micros 1.6.0_ Unclaimed Idle     2.410   246  0+00:00:04
c-wn3 .jorgeivanmez Sun Micros 1.6.0_ Unclaimed Idle     1.830   246  0+00:00:04
c-wn4 .jorgeivanmez Sun Micros 1.6.0_ Unclaimed Idle     2.240   246  0+00:00:04
Total Owner Claimed Unclaimed Matched Preempting Backfill

X86_64/LINUX     4     0       0         4       0          0        0

Total     4     0       0         4       0          0        0

Frecuentemente será necesario enviar múltiples trabajos al cluster que se encuentren basados en el mismo ejecutable, esto es especialmente útil cuando una misma tarea se debe ejecutar en varias ocasiones de manera concurrente o cuando se necesita procesar de manera concurrente una gran cantidad de información dispersa en múltiples archivos.

Ejecutar varios trabajos.

Para indicarle a Condor que se desea ejecutar varias instancias del mismo trabajo sólo es necesario indicarle la cantidad a través de la instrucción Queue del archivo de lanzamiento.

Para evitar la confusión que puede generar el registro de n trabajos volcado sobre los tres únicos archivos de error, salida y log, es posible indicarle a Condor que los diferencie para cada una de las instancias del trabajo ejecutado, utilizando la seudovariable $(Process).

Otra variable del archivo de lanzamiento que cobra especial importancia en este contexto es Input la cual permite especificar la información que se ingresaría al programa a través de la entrada estándar (stdin).  Esto permite que se personalice la ejecución de cada uno de los trabajos a pesar de que se basan en el mismo ejecutable.

Executable  = MyJob
Universe    = standard
Input       = MyJob-$(Process).in
Output      = _MyJob-$(Process).out
Error       = _MyJob-$(Process).err
Log         = _MyJob-$(Process).log

Queue 3

Si se consulta la cola de trabajos del cluster inmediatamente después de lanzar el trabajo podrán apreciarse los 3 trabajos lanzados efectivamente, todos bajo el mismo identificador (38 en este caso) y diferentes subidentificadores (los representados finalmente por $(Process)).

$ condor_q

-- Submitter: c-head.jorgeivanmeza.com : <192.168.1.210:9293> : c-head.jorgeivanmeza.com
ID      OWNER            SUBMITTED     RUN_TIME ST PRI SIZE CMD
38.0   jimezam         7/12 23:51   0+00:00:01 R  0   7.3  MyJob
38.1   jimezam         7/12 23:51   0+00:00:01 R  0   7.3  MyJob
38.2   jimezam         7/12 23:51   0+00:00:00 I  0   7.3  MyJob

3 jobs; 1 idle, 2 running, 0 held

La ejecución del archivo de lanzamiento anterior ejecutaría tres procesos basados en el programa MyJob el cual se deberá encontrar recompilado para el universo estándar, tomará la entrada estándar para cada una de las instancias de los archivos MyJob-#.in (que por obvias razones deberán existir previamente) y generará los archivos individuales de salida estándar, error y registro para cada una de las instancias ejecutadas con los nombres de _MyJob-#.out, _MyJob-#.err y _MyJob-#.log respectivamente.  El caracter # será reemplazado por el subidentificador interno del trabajo que empezará en cero y aumentará consecutivamente según la cantidad de trabajos que se haya solicitado encolar.

Después de la ejecución del trabajo propuesto como ejemplo este podría ser el contenido del directorio de trabajo.

-rw-rw-r-- 1 jimezam jimezam       0 Jul 12 23:32 _MyJob-0.err
-rw-rw-r-- 1 jimezam jimezam       4 Jul 12 23:40 MyJob-0.in
-rw-rw-r-- 1 jimezam jimezam     622 Jul 12 23:32 _MyJob-0.log
-rw-rw-r-- 1 jimezam jimezam     101 Jul 12 23:32 _MyJob-0.out

-rw-rw-r-- 1 jimezam jimezam       0 Jul 12 23:32 _MyJob-1.err
-rw-rw-r-- 1 jimezam jimezam       4 Jul 12 23:40 MyJob-1.in
-rw-rw-r-- 1 jimezam jimezam     622 Jul 12 23:32 _MyJob-1.log
-rw-rw-r-- 1 jimezam jimezam     101 Jul 12 23:32 _MyJob-1.out

-rw-rw-r-- 1 jimezam jimezam       0 Jul 12 23:32 _MyJob-2.err
-rw-rw-r-- 1 jimezam jimezam       4 Jul 12 23:40 MyJob-2.in
-rw-rw-r-- 1 jimezam jimezam     622 Jul 12 23:32 _MyJob-2.log
-rw-rw-r-- 1 jimezam jimezam     101 Jul 12 23:32 _MyJob-2.out

-rwxrwxr-x 1 jimezam jimezam 5461004 Jul 12 23:07 MyJob
-rw-rw-r-- 1 jimezam jimezam     384 Jul 12 23:06 MyJob.c
-rw-rw-r-- 1 jimezam jimezam     211 Jul 12 23:32 MyJob.submit

Utilizar directorios de inicio diferentes.

Otra facilidad que provee la sintáxis del archivo de lanzamiento de trabajos es la posibilidad de ejecutar los diferentes trabajos basados en el mismo ejecutable pero ubicados en diferentes directorios.  Esto evita las colisiones con los nombres de los archivos (solventadas inicialmente con el uso de $(Process)) y brinda un mayor orden a los archivos de datos.

Executable     = MyJob
Universe       = standard
Input          = MyJob.in
Output         = _MyJob.out
Error          = _MyJob.err
Log            = _MyJob.log           
initialdir     = job_$(Process)

Queue 3

Para lanzar este trabajo será necesario que existan los directorios iniciales de trabajo (job_0, job_1 y job_2) previamente y en cada uno de ellos exista el archivo MyJob.in cuyo contenido se utilizará como entrada estándar para cada una de las instancias.  Nótese como no habrá colisiones entre los nombres de los archivos (in, out, err y log) entre los diferentes trabajos aunque no se utilizó la seudovariable $(Process) para diferenciarlos ya que se ubicarán en diferentes directorios.

Después de la ejecución del trabajo propuesto como ejemplo este podría ser el contenido de los directorios de trabajo.

-rw-rw-r-- 1 jimezam jimezam   0 Jul 12 23:51 job_0/_MyJob.err
-rw-rw-r-- 1 jimezam jimezam   4 Jul 12 23:51 job_0/MyJob.in
-rw-rw-r-- 1 jimezam jimezam 622 Jul 12 23:51 job_0/_MyJob.log
-rw-rw-r-- 1 jimezam jimezam 107 Jul 12 23:51 job_0/_MyJob.out

-rw-rw-r-- 1 jimezam jimezam   0 Jul 12 23:51 job_1/_MyJob.err
-rw-rw-r-- 1 jimezam jimezam   4 Jul 12 23:51 job_1/MyJob.in
-rw-rw-r-- 1 jimezam jimezam 622 Jul 12 23:51 job_1/_MyJob.log
-rw-rw-r-- 1 jimezam jimezam 107 Jul 12 23:51 job_1/_MyJob.out

-rw-rw-r-- 1 jimezam jimezam   0 Jul 12 23:51 job_2/_MyJob.err
-rw-rw-r-- 1 jimezam jimezam   4 Jul 12 23:51 job_2/MyJob.in
-rw-rw-r-- 1 jimezam jimezam 622 Jul 12 23:51 job_2/_MyJob.log
-rw-rw-r-- 1 jimezam jimezam 107 Jul 12 23:51 job_2/_MyJob.out

Enlaces.

• Examples for Submit Description Files.
  http://www.cs.wisc.edu/condor/quick-start.html

Este universo permite el acceso uniforme a las máquinas virtuales de los nodos que dispongan de este servicio de manera independiente a la arquitectura de la máquina física o de su sistema operativo formando un ambiente de cómputo distribuido y homogéneo basado en la plataforma Java.

Verificar los nodos con soporte Java.

$ condor_status -java

Name               JavaVendor Ver    State     Activity LoadAv Mem   ActvtyTime

c-wn1.jorgeivanmez Sun Micros 1.6.0_ Unclaimed Idle     0.030   246  0+00:03:01
c-wn2.jorgeivanmez Sun Micros 1.6.0_ Unclaimed Idle     0.000   246  0+00:10:04
Total Owner Claimed Unclaimed Matched Preempting Backfill

X86_64/LINUX     2     0       0         2       0          0        0

Total     2     0       0         2       0          0        0

Se puede apreciar que los nodos c-wn1 y c-wn2 del cluster tienen soporte para la ejecución de trabajos Java, ambos tienen las máquinas virtuales de Sun Microsystems 1.6.0.

Ejemplo.

El código fuente.

$ vi HelloClusterJava.java

public class HelloClusterJava
{
 public static void main(String args[])
 {
   String hostname = "*** desconocido *** ";

   try
   {
     java.net.InetAddress localMachine = java.net.InetAddress.getLocalHost();
     hostname = localMachine.getHostName();
   }
   catch (java.net.UnknownHostException e)
   {
     hostname = e.getMessage();
   }

   System.out.println("Hello cluster, my name is: " + hostname + ".\n\n");
 }
}

La compilación.

$ javac HelloClusterJava.java

El archivo de envío del trabajo.

$ vi HelloClusterJava.submit

executable = HelloClusterJava.class
arguments  = HelloClusterJava
universe   = java
log        = _HelloClusterJava.log
output     = _HelloClusterJava.out
error      = _HelloClusterJava.err
queue

Debe notarse como el nombre del archivo de la clase principal se referencia por la variable executable mientras que en la variable arguments debe referenciarse el nombre de la clase principal.

El envío del trabajo al cluster.

$ condor_submit HelloClusterJava.submit

La obtención de los resultados.

$ cat _HelloClusterJava.log

000 (028.000.000) 07/12 18:16:47 Job submitted from host: <192.168.1.210:9362>
...
001 (028.000.000) 07/12 18:16:50 Job executing on host: <192.168.1.211:9335>
...
005 (028.000.000) 07/12 18:16:51 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
...

$ cat _HelloClusterJava.err

(vacío)

$ cat _HelloClusterJava.out

Hello cluster, my name is: c-wn1.jorgeivanmeza.com.

Otros parámetros interesantes del archivo de envío de trabajos.

Uso de archivos JAR.

executable = MyMain.jar
jar_files  = One.jar, Two.jar, Three.jar

Uso de archivos JAR ejecutables.

executable = MyMain.jar
jar_files  = One.jar, Two.jar, Three.jar
arguments  = my.package.MyClass

Versión específica y características de la VM.

requirements = (JavaVersion=="6.0")

Velocidad mínima.

Cuando se agrega un nodo con soporte de Java al cluster se determina cual es su velocidad en términos de JavaMFlops utilizando los algoritmos de benchmark de SciMark2.  Este parámetro permite filtrar los nodos en los que se podrá ejecutar el trabajo de acuerdo a su velocidad, tomando a la velocidad especificada como mínima requerida.

requirements = (JavaMFlops>500)

Opciones específicas de la VM.

java_vm_args = -DMyProperty=Value -verbose:gc

Enlaces.

• Java Applications, Condor Manual.
  http://www.cs.wisc.edu/condor/manual/v7.4/2_8Java_Applications.html

Después de realizado el proceso de instalación de SUN Java en los diferentes nodos del cluster la configuración de Java debería funcionar inmediatamente sin embargo al verificar la lista de cuales nodos soportan trabajos Java aparece vacía.

# condor_status -java

Realizar verificaciones (1).

Se verifican los valores básicos de la configuración de Java y su correspondencia con la realidad del cluster.

Ubicación de Java.

# condor_config_val JAVA

/usr/bin/java

# ls -l /usr/bin/java

lrwxrwxrwx 1 root root 26 Jun 13 11:43 /usr/bin/java -> /usr/java/default/bin/java

# /usr/bin/java -version

java version “1.6.0_20″
Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed mode)

Tamaño máximo de la memoria del heap.

# condor_config_val JAVA_MAXHEAP_ARGUMENT

-Xmx1024m

Diagnosticar el problema.

# condor_starter -classad

CondorVersion = “$CondorVersion: 7.4.2 Mar 29 2010 BuildID: 227044 $”
IsDaemonCore = True
HasFileTransfer = True
HasPerFileEncryption = True
HasReconnect = True
HasMPI = True
HasTDP = True
HasJobDeferral = True
HasJICLocalConfig = True
HasJICLocalStdin = True
Invalid maximum heap size: -Xmx1024m246m
Could not create the Java virtual machine.
HasVM = True

Según se interpreta lo anterior, Condor está detectando correctamente la ubicación de la máquina virtual de Java, sin embargo está fallando en su creación debido a un valor inválido en la cantidad máxima de memoria para el heap.  Según el manual de Condor esto puede estar sucediendo cuando se utiliza la máquina virtual de SUN Microsystems.

One identified difficulty occurs when the machine has a large quantity of physical RAM, and this quantity exceeds the Java limitations. This is a known problem for the Sun JVM. Condor appends the maximum amount of system RAM to the Java Maxheap Argument, and sometimes this value is larger than the JVM allows. The end result is that Condor believes that the JVM on the machine is faulty, resulting in nothing showing up as a result of executing the command condor_status -java.

Implementar la solución.

Reemplazar la definión de la variable JAVA_MAXHEAP_ARGUMENT con las siguientes variables.

# vi /opt/condor/condor/etc/condor_config.local

# First set JAVA_MAXHEAP_ARGUMENT to null, to disable the default of max RAM
JAVA_MAXHEAP_ARGUMENT =
# Now set the argument with the Sun-specific maximum allowable value
JAVA_EXTRA_ARGUMENTS = -Xmx1024m

Ajuste según sus requerimientos, el valor de memoria (MB) a asignársele al heap en el parámetro JAVA_EXTRA_ARGUMENTS.

# condor_reconfig c-head c-wn1 c-wn2

Sent “Reconfig” command to master c-head.jorgeivanmeza.com
Sent “Reconfig” command to master c-wn1.jorgeivanmeza.com
Sent “Reconfig” command to master c-wn2.jorgeivanmeza.com

Realizar verificaciones (2).

Estado de la configuración de Java.

# condor_starter -classad

CondorVersion = “$CondorVersion: 7.4.2 Mar 29 2010 BuildID: 227044 $”
IsDaemonCore = True
HasFileTransfer = True
HasPerFileEncryption = True
HasReconnect = True
HasMPI = True
HasTDP = True
HasJobDeferral = True
HasJICLocalConfig = True
HasJICLocalStdin = True
JavaVendor = “Sun Microsystems Inc.”
JavaVersion = “1.6.0_20″
JavaSpecificationVersion = “1.6″
JavaMFlops = 495.500641
HasJava = True
HasVM = True

Nodos con soporte para Java.

# condor_status -java

Name               JavaVendor Ver    State     Activity LoadAv Mem   ActvtyTime

c-wn1.jorgeivanmez Sun Micros 1.6.0_ Unclaimed Idle     0.230   246  0+00:00:04
c-wn2.jorgeivanmez Sun Micros 1.6.0_ Unclaimed Idle     0.080   246  0+00:00:04
Total Owner Claimed Unclaimed Matched Preempting Backfill

X86_64/LINUX     2     0       0         2       0          0        0

Total            2     0       0         2       0          0        0

Enlaces.

• Java Support Installation, Condor Manual.
  http://www.cs.wisc.edu/condor/manual/v7.4/3_14Java_Support.html#sec:java-install

Este universo se utiliza para ejecutar los trabajos que no pueden ser reenlazados con las librerías de Condor, un caso importante de estos trabajos son los scripts del shell.

En este universo no se cuenta con puntos de chequeo ni con llamados al sistema remoto, por este motivo se hace necesario controlar la entrada y la salida de los trabajos, para lo cual se puede utilizar un sistema de archivos compartido (como NFS o AFS) o utilizar el mecanismo de Condor de transferir archivos.

Ejemplo.

El archivo de envío del trabajo.

$ vi hostname.submit

executable = /bin/hostname
universe   = vanilla
log        = _hostname.log
output     = _hostname.out
error      = _hostname.err
queue

El envío del trabajo al cluster.

$ condor_submit hostname.submit

La obtención de los resultados.

$ cat _hostname.log

000 (025.000.000) 07/12 10:51:26 Job submitted from host: <192.168.1.210:9204>
...
001 (025.000.000) 07/12 10:51:42 Job executing on host: <192.168.1.212:9875>
...
005 (025.000.000) 07/12 10:51:43 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
...

$ cat _hostname.err

(vacío)

$ cat _hostname.out

c-wn2.jorgeivanmeza.com

Enlaces.

• Road-map for running jobs.
  http://www.cs.wisc.edu/condor/manual/v7.4/2_4Road_map_Running.html
• Submitting a job.
  http://www.cs.wisc.edu/condor/manual/v7.4/2_5Submitting_Job.html
• Submitting Jobs Using a Shared File System.
  http://www.cs.wisc.edu/condor/manual/v7.4/2_5Submitting_Job.html#sec:shared-fs
• Submitting Jobs Without a Shared File System: Condor’s File Transfer Mechanism.
  http://www.cs.wisc.edu/condor/manual/v7.4/2_5Submitting_Job.html#sec:file-transfer