Hasta la fecha se han realizado los siguientes avances con respecto a la implementación del proyecto.

• Se incluyó un apartado acerca del envío de trabajos al cluster Condor cuando no se cuenta con un sistema de archivos compartido.
• Se documentó un problema que sucede cuando se envían scripts con el universo Vanilla sin el correspondiente shebang.
• Se documentó el error de GSS authentication failure que sucede cuando el hostname del servidor no coincide con el certificado de máquina.
• Se documentó el error que impide la ejecución del servidor GAHP y que a su vez evita el envío de trabajos al nodo Grid.
• Se complementó el procedimiento de instalación del cliente Grid y se realizó en (Nodo9@UAM).
• Se realizó la documentación del error que sucede cuando un usuario no autorizado en el gridmap-file intenta enviar trabajos al nodo Grid.
• Se realizaron múltiples pruebas de instalación del nodo Grid con sistemas operativos de 32 y 64 bits para verificar el envío de trabajos con las herramientas de Globus desde el CE y el Cliente, mientras que el envío de trabajos con CondorG sólo puede ser realizado desde el Cliente.  Se envió correo a Grid Colombia para confirmar este hallazago.
• Se realizó la instalación de Octave 3.2.4 a partir de fuentes (en UR) tanto en el nodo principal como en los nodos trabajadores.  Así mismo se documentó el problema de instalación en cluster encontrado.
• Se documentó el envío de trabajos al cluster Condor con Octave mediante el universo Vanilla.

Durante las últimas dos semanas se realizaron los siguientes avances con respecto a la implementación del proyecto.

• Se documento el procedimiento de instalación del cliente OSG.
• Se realizaron algunos ajustes a las pruebas locales del CE (Compute Element).
• Se determinó que los mensajes informativos relacionados con el paquete Globus-Base-Info recibidos durante la instalación del CE no revisten mayor gravedad y pueden ignorarse.
• En el cluster de la Universidad del Rosario se realizaron los siguientes avances.
  • Se actualizaron los paquetes del sistema operativo en todos los nodos.
  • Se corrigió el hostname del CE.
  • Se realizó la instalación y configuración de Condor de acuerdo a los estándares y procedimientos del proyecto.  Se realizaron algunos ajustes a la documentación de estos.  Tanto el head como los worker nodes fueron modificados.
  • Se realizó la instalación del Cliente OSG en el nodo 7.
  • Se realizó la instalación y configuración del CE (nodo 4).
  • Se corrigió el soporte para el universo Java en todos los nodos del cluster.
  • Se reiniciaron los nodos del cluster y se verificó el correcto funcionamiento de los servicios (NFS y SSH) y de Condor (nodos y Java).
• En el cluster de la Universidad Autónoma de Manizales se realizaron los siguientes avances.
  • Se realizó la instalación del Cliente OSG en el nodo 9.
  • Se corrigió el soporte para el universo Java en todos los nodos del cluster.

Entre las universidades del eje cafetero aparentemente persisten los problemas de conectividad los cuales actualmente impiden la posibilidad de realizar pruebas de conectividad entre los nodos de la Grid con la Universidad Autónoma de Manizales.

Continúa pendiente verificar la integración entre Condor y Globus ya que las pruebas locales al respecto no han sido satisfactorias aún.

Asistentes reunión Grid Colombia, Enero 2011.

Durante los días 20 y 21 de enero de 2011 se realizó una reunión técnica con los integrantes de Grid Colombia en las instalaciones de la Universidad Javeriana de Bogotá para tratar los siguientes temas directamente relacionados con el proyecto.

• Montaje de clusters basados en Condor sobre CentOS.
• Breve descripción acerca del uso y administración de los clusters Condor.
• Solicitud y registro de los certificados de usuario.
• Instalación y configuración del Computer Element (CE).
• Instalación y configuración del OSG Client.
• Instalación y configuración del Grid User Management System (GUMS).
• Verificación y envío de tareas a la grid.

Después de convenidos los criterios y conceptos necesarios para la conexión de la grid de las Universidades con Grid Colombia, se espera continuar durante la presente semana con el proceso de implementación de los nodos grid.

Durante la presente semana se formalizó en la documentación del wiki del proyecto la instalación y configuración de equipos externos que tendrán Condor única y exclusivamente para el envío de trabajos al cluster (nodos submitter).  Esta tarea se analizó desde las siguientes distribuciones: convertir un nodo trabajador a nodo submitter, Ubuntu desde paquetes .tgz y paquetes .deb, y Scientific Linux desde paquetes .tgz.  Se determinó el método para restringir los equipos que pueden conectarse al pool del cluster, esto incluye a los nodos trabajadores y a los emisores de trabajos.

Se realizaron pruebas con Condor para Windows pero por ahora en esa plataforma no fue posible configurar la autenticación basada en contraseña que requiere el cluster.

También se documentó el procedimiento para permitirle a los nodos trabajadores acceder a las redes externas como Internet utilizando al nodo principal del cluster como puerta de enlace utilizando iptables y las facilidades nativas de Linux.

Se realizaron ajustes a los permisos y propietarios de la instalación de InterProScan para permitir que este pudiera ser ejecutado por usuarios no administradores del sistema operativo.

Durante estas últimas semanas se ha trabajado en el documento del anteproyecto el cual está pendiente de una revisión final por parte de las asesoras técnicas y metodológicas para su visto bueno.

Se modificó la distribución de la información en el wiki para facilitar su acceso rápdio, además se agregaron las siguientes secciones nuevas en el Wiki del proyecto.

1. Envío de múltiples trabajos al clúster.
   1. Utilizando múltiples argumentos.
   2. Utilizando diferentes directorios de trabajo.
2. Como determinar la finalización de los trabajos enviados al clúster.
3. Determinar el estado y los problemas de los trabajos enviados al clúster.

Se agregaron dos nuevas secciones en el wiki bajo Clúster con las actividades por hacer en la cual se relacionan las tareas pendientes y los temas que sería bueno profundizar pero que en este momento no hacen parte de los intereses principales del proyecto.  Una segunda sección se encarga de listar otras herramientas de clusterización que puede ser interesante incluír en el clúster pero que también, en este momento no hacen parte directa de los intereses del proyecto.

Se actualizaron los sistemas operativos de los nodos (máquinas virtualizadas con KVM) del clúster de desarrollo con las actualizaciones de octubre sin que se presentaran problemas aparentes.

Se realiza la planeación incial para la instalación de los elementos del nodo grid local: GUMS, Compute Element y Grid Client.  De igual manera se consideró necesario investigar acerca del Storage Element.

En la presente semana se espera realizar el contacto con los ingenieros de Grid Colombia para coordinar las actividades.

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

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

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.

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.

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!