Aug 11

Problema.

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

Tagged with:



En August 11 de 2010, Jorge Iván Meza Martínez escribió acerca de No es posible encontrar condor_config durante el inicio automático.
Aug 11

Problema.

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

Tagged with:



En August 11 de 2010, Jorge Iván Meza Martínez escribió acerca de SEC_PASSWORD_FILE must be owned by Condor’s real uid.
Aug 11

Problema.

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.

Tagged with:



En August 11 de 2010, Jorge Iván Meza Martínez escribió acerca de Instalación de Condor en una arquitectura incorrecta.
Aug 11

Durante tres días de la última semana del mes de junio estuve dictando un curso práctico acerca de la instalación, configuración y uso de un cluster utilizando Condor y software libre como parte de la difusión de los conocimientos que he adquirido durante el desarrollo del proyecto GridUAM.

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.

Tagged with:



En August 11 de 2010, Jorge Iván Meza Martínez escribió acerca de Curso de clusters en la Universidad Autónoma de Manizales, julio de 2010.
Jul 15

Introducción.

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!

Tagged with:



En July 15 de 2010, Jorge Iván Meza Martínez escribió acerca de Cuidado sobre el manejo de argv[0] en las aplicaciones escritas en C/C++.
Jul 14

Introducción.

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

Tagged with:



En July 14 de 2010, Jorge Iván Meza Martínez escribió acerca de Cluster-C: clonar dos nuevos nodos virtualizados con KVM al cluster.
Jul 13

Introducción.

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.

Tagged with:



En July 13 de 2010, Jorge Iván Meza Martínez escribió acerca de Enviando al cluster varios trabajos basados en el mismo ejecutable.
Jul 12

Introducción.

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.

Tagged with:



En July 12 de 2010, Jorge Iván Meza Martínez escribió acerca de C-Cluster: reparando el soporte de SUN Java en Condor.
Jul 08

Introducción.

En este artículo se agregarán algunas mejoras en la configuración del cluster para fortalecer su seguridad mediante el establecimiento de restricciones de acceso, tanto a nivel de puertos con el firewall como a nivel de ubicaciones con los archivos hosts.

Configurando el acceso a los servicios en el firewall.

En el nodo servidor de archivos (c-nfs que es el mismo c-head) del cluster.

Es necesario configurar el servicio de NFS para que utilice siempre un conjunto conocido de puertos, de lo contrario utilizará valores aleatorios lo que hace muy difícil establecer los parámetros para el firewall.  Para hacer esto se deben remover los comentarios de las siguientes líneas en el archivo de configuración mencionado.

# vi /etc/sysconfig/nfs

# TCP port rpc.lockd should listen on.
LOCKD_TCPPORT=32803
# UDP port rpc.lockd should listen on.
LOCKD_UDPPORT=32769
# Port rpc.mountd should listen on.
MOUNTD_PORT=892
# Port rpc.statd should listen on.
STATD_PORT=662

Ajustar la configuración de iptables para permitir las conexiones de NFS agregando las nuevas líneas resaltadas.

# vi /etc/sysconfig/iptables

# Firewall configuration written by system-config-securitylevel
# Manual customization of this file is not recommended.
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -j RH-Firewall-1-INPUT
-A FORWARD -j RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT
-A RH-Firewall-1-INPUT -p 50 -j ACCEPT
-A RH-Firewall-1-INPUT -p 51 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp --dport 5353 -d 224.0.0.251 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m tcp --dport 631 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT

## NFS
# portmap/sunrpc
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 111 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 111 -j ACCEPT
# statd
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 662 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 662 -j ACCEPT
# mountd
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 892 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 892 -j ACCEPT
# nfs
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 2049 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 2049 -j ACCEPT
# lockd_tcp
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 32803 -j ACCEPT
# lockd_udp
-A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 32769 -j ACCEPT
## /NFS

## Condor
-A RH-Firewall-1-INPUT -s 192.168.1.0/24 -m state --state ESTABLISHED,NEW -p tcp -m tcp --dport 9000:9999 -j ACCEPT
-A RH-Firewall-1-INPUT -s 192.168.1.0/24 -m state --state ESTABLISHED,NEW -p udp -m udp --dport 9000:9999 -j ACCEPT
## /Condor

-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
COMMIT

Importante (1): el parámetro -s permite restringir la fuente válida de los paquetes, para este cluster es cualquier equipo de la red 192.168.1.x.   En caso de que el cluster tenga nodos por fuera de su propia red es necesario omitir este parámetro, de lo contrario, estos nodos externos no podrán conectarse con el cluster.

Importante (2): el rango de puertos permitido por el firewall -9000:9999- deberá corresponder con las variables IN_LOWPORT e IN_HIGHPORT especificadas en el archivo /nfs/condor/condor-etc/condor_config.cluster durante la instalación y configuración de Condor.

Reiniciar los servicios para que tenga efecto la configuración del firewall recién realizada.

# /etc/init.d/iptables restart

# /etc/init.d/nfs restart

# /etc/init.d/nfslock restart

Verificar desde otro equipo la visibilidad de los puertos en el nodo servidor de archivos del cluster (opcional).

# nmap -sS c-nfs

Starting Nmap 5.00 ( http://nmap.org ) at 2010-07-07 23:09 COT
Interesting ports on c-nfs (192.168.1.210):
Not shown: 946 filtered ports, 50 closed ports
PORT     STATE SERVICE
22/tcp   open  ssh
111/tcp  open  rpcbind
2049/tcp open  nfs

9618/tcp open  unknown*

# nmap -sU c-nfs

Starting Nmap 5.00 ( http://nmap.org ) at 2010-07-07 23:09 COT
Interesting ports on c-nfs (192.168.1.210):
Not shown: 985 filtered ports
PORT      STATE         SERVICE
111/udp   open|filtered rpcbind
631/udp   open|filtered ipp
2049/udp  open|filtered nfs
9000/udp  closed        cslistener
9001/udp  closed        unknown
9020/udp  closed        unknown
9103/udp  closed        unknown
9199/udp  open|filtered unknown
9200/udp  closed        wap-wsp
9370/udp  closed        unknown
9876/udp  closed        sd
9877/udp  closed        unknown
9950/udp  closed        unknown
10000/udp closed        unknown
32769/udp open|filtered unknown

En los nodos trabajadores (c-wn1 y c-wn2) del cluster.

Ajustar la configuración de iptables para permitir las conexiones de Condor agregando las nuevas líneas resaltadas.

# vi /etc/sysconfig/iptables

# Firewall configuration written by system-config-securitylevel
# Manual customization of this file is not recommended.
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -j RH-Firewall-1-INPUT
-A FORWARD -j RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT
-A RH-Firewall-1-INPUT -p 50 -j ACCEPT
-A RH-Firewall-1-INPUT -p 51 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp --dport 5353 -d 224.0.0.251 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m tcp --dport 631 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT

## Condor
-A RH-Firewall-1-INPUT -s 192.168.1.0/24 -m state --state ESTABLISHED,NEW -p tcp -m tcp --dport 9000:9999 -j ACCEPT
-A RH-Firewall-1-INPUT -s 192.168.1.0/24 -m state --state ESTABLISHED,NEW -p udp -m udp --dport 9000:9999 -j ACCEPT
## /Condor

-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
COMMIT

Revisar las anotaciones importantes (1 y 2) hechas en la configuración del firewall del nodo c-nfs con respecto al parámetro -s y el rango de puertos.

Reiniciar el servicio para que tenga efecto la configuración del firewall recién realizada.

# /etc/init.d/iptables restart

Verificar desde otro equipo la visibilidad de los puertos en los nodos trabajadores del cluster (opcional).

# sudo nmap -sS c-wn1

Starting Nmap 5.00 ( http://nmap.org ) at 2010-07-07 23:20 COT
Interesting ports on c-wn1 (192.168.1.211):
Not shown: 948 filtered ports, 51 closed ports
PORT     STATE SERVICE
22/tcp   open  ssh
9898/tcp open  unknown*

# nmap -sU c-wn1

Starting Nmap 5.00 ( http://nmap.org ) at 2010-07-07 23:20 COT
Stats: 0:16:12 elapsed; 0 hosts completed (1 up), 1 undergoing UDP Scan
UDP Scan Timing: About 94.24% done; ETC: 23:37 (0:00:59 remaining)
Interesting ports on c-wn1 (192.168.1.211):
Not shown: 988 filtered ports
PORT      STATE         SERVICE
631/udp   open|filtered ipp
9000/udp  closed        cslistener
9001/udp  closed        unknown
9020/udp  closed        unknown
9103/udp  closed        unknown
9199/udp  closed        unknown
9200/udp  closed        wap-wsp
9370/udp  closed        unknown
9876/udp  closed        sd
9877/udp  closed        unknown
9950/udp  closed        unknown
10000/udp closed        unknown

En todos los nodos (c-head, c-wn1 y c-wn2) del cluster.

Configurar al firewall del nodo para que inicie automáticamente con el sistema operativo.

# chkconfig iptables on

# chkconfig --list iptables

iptables           0:off    1:off    2:on    3:on    4:on    5:on    6:off

Configurando el acceso a los servicios según su orígen.

Servicio de SSH.

En cada uno de los nodos (c-head, c-wn1 y c-wn2) realizar los siguientes ajustes a la configuración de TCP Wrappers para especificar el filtro de las conexiones.

# vi /etc/hosts.allow

sshd: 192.168.1.

# vi /etc/hosts.deny

sshd: all

Servicio de NFS.

En el nodo servidor de archivos (c-nfs) realizar los siguientes ajustes a la configuración de TCP Wrappers para especificar el filtro de las conexiones.

# vi /etc/hosts.allow

## NFS
portmap: 192.168.1.
lockd:   192.168.1.
rquotad: 192.168.1.
mountd:  192.168.1.
statd:   192.168.1.

# vi /etc/hosts.deny

## NFS
portmap:ALL
lockd:ALL
mountd:ALL
rquotad:ALL
statd:ALL

Estas configuraciones propuestas permiten que se realicen conexiones a los nodos del cluster desde cualquier ubicación de la red 192.168.1.0 y que se nieguen los intentos de conexión desde cualquier otra ubicación.  Si se desea un nivel de granularidad mas preciso en la selección de ubicaciones es posible especificar las direcciones IP en una lista separada por comas.  Consulte mas información acerca de las opciones de sintáxis de este archivo en la Red Hat Linux Reference Guide: Chapter 15. TCP Wrappers and xinetd.

Servicio de Condor.

La configuración del acceso a Condor se realiza a través de sus propios ajustes de configuración, especialmente en /nfs/condor/condor-etc/condor_config.cluster.  Este tema específico será objeto de una revisión posterior.  Para mas información consultar el capítulo acerca de Seguridad del manual de Condor.

Enlaces.

Tagged with:



En July 8 de 2010, Jorge Iván Meza Martínez escribió acerca de C-Cluster: Asegurando las conexiones al cluster.
Jun 19




El día de hoy la ingeniera Ana Lorena Uribe y yo realizamos la separación de segmentos para ambos clusters simulando las condiciones de configuración y direccionamiento que se tendrán cuando se realice el despliegue final en las dos universidades.  Para esto se utilizaron dos routers Cisco de la serie 1800 los cuales fueron configurados con enrrutamiento estático y se les asignaron a los servidores direcciones IP bajo RENATA.

El direccionamiento elegido obedece al siguiente esquema.

Esquema de segmentación de la red

Para su configuración fue necesario realizar en maestro el siguiente ajuste en su configuración de red para especificar la ruta para acceder a los nodos del cluster en el nuevo segmento.

# vi /etc/sysconfig/network-scripts/route-eth1

190.X.Y.224/27 via 190.X.Y.204

De esta manera se configura la siguiente tabla de enrrutamiento en maestro.  Nótese como este servidor tiene además acceso a su propio segmento a través del 190.X.Y.192 y a Internet a través de la interfaz eth0.

# route

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
190.X.Y.192     *               255.255.255.224 U     0      0        0 eth1
190.X.Y.224     190.X.Y.204     255.255.255.224 UG    0      0        0 eth1
192.168.122.0   *               255.255.255.0   U     0      0        0 virbr0
192.168.0.0     *               255.255.254.0   U     0      0        0 eth0
169.254.0.0     *               255.255.0.0     U     0      0        0 eth1
default         192.168.1.1     0.0.0.0         UG    0      0        0 eth0

En su contraparte, el nodo4, se realizó la siguiente especificación de rutas.

# vi /etc/sysconfig/network-scripts/route-eth1

190.X.Y.192/27 via 190.X.Y.229

Su tabla de enrrutamiento es entonces la siguiente.

# route

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
190.X.Y.192     190.X.Y.229     255.255.255.224 UG    0      0        0 eth1
190.X.Y.224     *               255.255.255.224 U     0      0        0 eth1
192.168.122.0   *               255.255.255.0   U     0      0        0 virbr0
169.254.0.0     *               255.255.0.0     U     0      0        0 eth1
default         190.X.Y.229     0.0.0.0         UG    0      0        0 eth1

Tagged with:



En June 19 de 2010, Jorge Iván Meza Martínez escribió acerca de Separación de clusters en segmentos de red diferentes.