• 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.

• 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.

• Con respecto a los certificados se documentaron los procedimientos para solicitar, obtener, instalar y registrar los certificados de los usuarios; y solicitar e instalar los certificados de las máquinas.
• Con respecto al CE (Compute Element) se realizó su instalación y configuración general, la cual incluye además la configuración del uso del gridmap-file y las pruebas locales para verificar su funcionamiento.
• Se formalizó la documentación del hardware de los servidores involucrados en los nodos Grid del proyecto.
• Se agregó un nuevo nodo (nodo9) al nodo de la Universidad Autónoma de Manizales en el cual se realizó la configuración para anexarlo al cluster.
• Se realizaron mejoras a la configuración del nodo8 que tenía problemas de autenticación con el cluster y por esto no estaba siendo tenido en cuenta por Condor.

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.

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.

Es muy común que debido al alto tráfico que se genera entre los nodos trabajadores de un clúster y su nodo principal, estos se separen en una red independiente y el nodo principal, con dos interfaces de red, actúe como puente entre los clientes en la red LAN y los nodos trabajadores en la red finalmente oculta.

La configuración de esto es tan simple como la simple conexión física de los dispositivos y la configuración de direcciones IP estáticas para los nodos trabajadores si es que no se desea instalar un servidor DHCP en el nodo principal para que realice esta tarea a través de la interfaz de red específica.  El problema surge cuando es necesario actualizar los nodos trabajadores o en general, que estos accedan a Internet.  Como estos se encuentran en un red diferente de la LAN, no hay nada que los enrrute hacia la WAN, quedando completamente aislados.

La solución a este problema es muy fácil de implementar gracias a las características intrínsecas de enrrutamiento de Linux (y en general de los sistemas operativos *nix).  Simplemente es necesario indicarle al nodo principal que actúe como enrrutador entre sus interfaces de red: red LAN y red de nodos trabajadores, pudiéndose aplicar los controles que se consideren necesarios a través del uso de iptables.

El panorama.

Estructura general del cluster

El nodo principal del cluster cuenta con dos interfaces de red: eth0 que se comunica con la red LAN de la organización y eth1 que se conecta con los nodos trabajadores, los cuales sólo cuentan con una única interfaz de red eth0.  Estos últimos se encuentran aislados del exterior ya que no son enrrutados inicialmente hacía la red LAN y eventualmente hacia Internet.

Implementación del enrrutamiento.

Configuración en el nodo principal del cluster.

Este actuará como enrrutador para la información enviada desde los nodos trabajadores y permitirles entonces acceder a las redes exteriores.  Para es necesario implementar en él las siguientes modificaciones de configuración.

Activar el envío de paquetes del kernel.

Esto se puede implementar de manera temporal, es decir, esta modificación no perdurará al reinicio del sistema, mediante la ejecución del siguiente comando.

# echo 1 > /proc/sys/net/ipv4/ip_forward

O puede implementarse de manera permanente mediante la edición de los parámetros del kernel de la siguiente manera.

# vi /etc/sysctl.conf

net.ipv4.ip_forward = 1

Esta último método puede verifcarse mediante la ejecución del siguiente comando en el shell.

# sysctl -p | grep ipv4

net.ipv4.ip_forward = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.tcp_syncookies = 1

Establecer la regla de filtrado.

# iptables -t nat -A POSTROUTING -o eth0 -s 192.168.56.0/24 -j MASQUERADE

Esta instrucción le indica al nodo principal que permita el paso de los paquetes que vienen desde la red de los nodos trabajadores (192.168.56.0/24) hacía la otra red, en este caso la LAN (192.168.1.0), que se accede a través de la interfaz de red eth0.

Esta modificación desde la línea de comando no es persistente, por lo cual se deberá configurar en alguno de los archivos que se ejecutan al inicio.  Probablemente el mejor sitio sea en /etc/sysconfig/iptables, sin embargo debe tenerse cuidado si se utiliza system-config-securitylevel para administrar el firewall ya que este puede sobreescribir el archivo y olvidar los cambios.

Permitir el acceso al servicio DNS.

Este paso es opcional, pero probablemente si no se lleva a cabo el enrrutamiento sea exitoso si se utilizan direcciones IP directamente mas no si se intenta acceder utilizando nombres FQDN ya que los intentos de acceso al DNS son filtrados por el nodo principal.

Para permitir el acceso al servicio DNS es necesario permitir el paso de paquetes UDP cuyo destino sea el puerto 53 de la siguiente manera.

# iptables -A INPUT -m state --state NEW -m udp -p udp --dport 53 -j ACCEPT

Igual que en el paso anterior, para hacer persistente esta modificación es necesario incluírla en un archivo como /etc/sysconfig/iptables o realizarla con el system-config-securitylevel si se utiliza.

Configuración de los nodos trabajadores.

Es necesario finalmente indicarle a los nodos trabajadores que el nodo principal del cluster será a partir de ahora su nueva puerta de enlace.  Para hacer esto es necesario modificar el siguiente parámetro de su configuración con la dirección IP del servidor principal configurado anteriormente.

GATEWAY = 192.168.56.100

Esta modificación puede realizarse uno de los siguientes puntos de configuración de los nodos trabajadores.

1. El archivo /etc/sysconfig/network.
2. El archivo /etc/sysconfig/network-scripts/ifcfg-eth0.

Si el cambio se aplica en el primero de ellos, la modificación tiene un alcance global sobre todas las interfaces de red.  Si se aplica sobre el segundo archivo, la modificación será específica para la interfaz de red eth0.  En el caso de los nodos trabajadores, estos sólo tienen una única interfaz de red así que ambas opciones tienen igual implicación.

Finalmente es necesario reiniciar el servicio de red para garantizar que los cambios realizados tengan efecto.

# /etc/init.d/network restart

echo 1 > /proc/sys/net/ipv4/ip_forward

Se aprovechó también para realizar la instalación del OSG Client en el servidor principal del cluster de la Autónoma e iniciar la instalación del Computer Element (CE) de su próximamente nodo Grid.  De este último se realizó la instalación de los certificados de máquina, los servicios adicionales requeridos y el gestor de paquetes de OSG.  Al respecto estamos listos para continuar con la instalación del CE previa verificación del funcionamiento del cliente cuando se obtengan certificados de usuario para realizar las pruebas por parte de Grid Colombia.

Adicionalmente se realizó la instalación y configuración inicial del software de bioinformática InterProScan en el cluster que es requerido por los compañeros de Cenicafé.

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.

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