Mar 08

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

Tagged with:



En March 8 de 2011, Jorge Iván Meza Martínez escribió acerca de Avances del proyecto – 20110308.
Feb 18

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

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.

Tagged with:



En February 18 de 2011, Jorge Iván Meza Martínez escribió acerca de Avances del proyecto en el mes de febrero de 2011.
Feb 08

Durante el mes de enero y los primeros días del mes de febrero se realizaron los siguientes avances en el proyecto los cuales fueron documentados en su sitio wiki.

Tagged with:



En February 8 de 2011, Jorge Iván Meza Martínez escribió acerca de Avances del proyecto en el mes de enero de 2011.
Jan 25
Asistentes reunión Grid Colombia, Enero 2011.

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.

Tagged with:



En January 25 de 2011, Jorge Iván Meza Martínez escribió acerca de Reunión con Grid Colombia en enero de 2011.
Dec 05

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.

Tagged with:



En December 5 de 2010, Jorge Iván Meza Martínez escribió acerca de Instalación de nodos submitter + acceso a Internet a través del nodo principal.
Dec 05

Introducción.

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

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

Tagged with:



En December 5 de 2010, Jorge Iván Meza Martínez escribió acerca de Permitir el acceso de los nodos del cluster a Internet a través del nodo principal.
Nov 29

La semana pasada asistimos a un curso de capacitación en la Universidad Autónoma de Manizales dictado por la empresa española MaatG enfocado al uso y desarrollo de su plataforma grid, haciendo un principal énfasis en su módulo de e-learning que es utilizado ampliamente por el proyecto de Colciencias que venimos desarrollando.

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

Tagged with:



En November 29 de 2010, Jorge Iván Meza Martínez escribió acerca de Curso de MaatG en la Universidad Autónoma de Manizales, noviembre de 2010.
Nov 04

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.

Tagged with:



En November 4 de 2010, Jorge Iván Meza Martínez escribió acerca de Avances del proyecto en los meses de septiembre y octubre de 2010.
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.