Tabla de contenido

 

 

INTROCUCCIÓN

 

1. Introducción. 2

 

1.1. Descripción del proyecto. 2

1.2. Justificación del proyecto. 2

1.3. Motivación personal 2

1.4. Organización del documento. 2

1.5. La doble utilidad del documento. 2

1.6. Convenciones y tipografía. 2

 

2. Análisis preliminar 2

 

2.1. Situación actual 2

2.2. Objetivos del proyecto. 2

2.3. Requerimientos del proyecto. 2

 

 

PRIMERA PARTE: SISTEMAS DE CLUSTERING

 

3. Clusters. 2

 

3.1. ¿Qué es un cluster?. 2

3.2. Un poco de historia. 2

3.3. Tipos de cluster 2

 

4. Cluster Filesystems. 2

 

4.1. Glosario. 2

4.2. Sistemas de ficheros distribuidos. 2

4.2.1. Network File System (NFS) 2

4.2.2. Samba. 2

4.3. Sistemas de ficheros paralelos. 2

4.3.2. Lustre. 2

4.3.3. GlusterFS. 2

 

5. Software de Clustering. 2

 

5.1. openMosix. 2

5.2. Condor 2

5.3. PBS. 2

5.4. Sun Grid Engine. 2

 

6. Alta disponibilidad. 2

 

6.1. Funcionamiento de un sistema HA.. 2

6.2. Soluciones de HA en entornos Linux. 2

 

 

SEGUNDA PARTE: DISEÑO E IMPLEMENTACIÓN

 

7. Estudio, análisis y diseño de una solución. 2

 

7.1. Análisis del sistema inicial 2

7.2. Revisión de objetivos y requisitos. 2

7.2.1. Requisitos funcionales. 2

7.2.2. Requisitos no funcionales. 2

7.3. El nuevo cluster 2

7.3.1. El sistema base. 2

7.3.2. Sistema de pruebas. 2

7.3.4. Sistema de ficheros. 2

7.3.5. Alta disponibilidad. 2

7.3.6. Sistema de imágenes. 2

7.3.7. Sistema de Monitorización. 2

7.3.8. Servicios auxiliares. 2

 

8. Implementación. 2

 

9. Lustre. 2

 

9.1. Arquitectura propuesta (versión 1.0) 2

9.2. Instalación (versión 1.0) 2

9.2.1.  DRBD.. 2

9.2.2. Lustre. 2

9.3. Configuración (versión 1.0) 2

9.3.1. Consideraciones previas. 2

9.3.2. DRBD.. 2

9.3.3. Lustre. 2

9.4. Pruebas (versión 1.0) 2

9.4.1. Test de estabilidad. 2

9.5. Revisión de la arquitectura (versión 1.1) 2

9.6. Pruebas del nuevo modelo (versión 1.1) 2

9.6.1. Test de estabilidad. 2

9.6.2. Pruebas de rendimiento. 2

9.6.2.1. Throughput máximo. 2

9.6.2.2. Test ad-hoc. 2

9.6.3. Pruebas de usabilidad. 2

 

10. GlusterFS. 2

 

10.1. Arquitectura propuesta (versión 2.0) 2

10.2. Instalación (versión 2.0) 2

10.3. Configuración (versión 2.0) 2

10.3.1 Servidores. 2

10.3.2. Namespace. 2

10.3.3. Clientes. 2

10.4. Pruebas. 2

10.4.1. Test de estabilidad. 2

10.4.2. Pruebas de rendimiento. 2

10.4.2.1. Throughput máximo. 2

10.4.2.2. Test ad-hoc. 2

10.4.3. Pruebas de usabilidad. 2

 

11. Sun Grid Engine. 2

 

11.1. Instalación. 2

11.1.1. Instalación del Master host 2

11.1.2. Instalación de un Execution host 2

11.2. Configuración. 2

11.2.1. Zona Spool de mater hosts. 2

11.2.2. Zona common. 2

11.2.3. Colas. 2

11.2.3. Usuarios. 2

11.2.4. Políticas. 2

 

12. Heartbeat 2

 

12.1. Instalación. 2

12.2. Configuración. 2

12.2.1. Cluster con GlusterFS (versión 2.0) 2

12.3. Split-Brain. 2

 

13. Tivoli 2

 

13.1. Instalación. 2

13.2. Configuración. 2

13.3. Creación de una imagen. 2

13.4. Personalización de imágenes. 2

 

14. Ganglia. 2

 

14.1. Instalación. 2

14.2. Configuración. 2

14.3. Personalización. 2

14.3.1. Trabajos en ejecución: 2

14.3.2. Trabajos encolados. 2

14.3.3. Sensor de temperatura. 2

14.3.4. Personalización web. 2

 

15. Nagios. 2

 

15.1. Instalación. 2

15.2. Configuración. 2

15.2.1. Configuración en cliente. 2

15.2.2. Configuración en servidor 2

 

16. Servicios auxiliares. 2

 

16.1. DHCP. 2

16.1.1. Instalación. 2

16.1.2. Configuración del servidor 2

16.1.3. Configuración de los clientes. 2

16.2. Exim.. 2

16.2.1. Instalación. 2

16.2.2. Configuración. 2

16.3. NTP. 2

16.3.1. Instalación. 2

16.3.2. Configuración. 2

16.4. Dsh. 2

16.4.1. Instalación. 2

16.4.2. Configuración. 2

16.5. Backup. 2

16.5.1. Instalación. 2

16.5.2. Configuración. 2

16.6. Estadísticas web. 2

16.6.1. Instalación. 2

16.6.2. Configuración. 2

16.7. Wake on LAN.. 2

16.8. NAT. 2

 

17. Tareas administrativas. 2

 

17.1. Alta de nodo. 2

17.2. Alta de usuario. 2

 

 

TERCERA PARTE: CONCLUSIONES

 

18. Conclusiones. 2

 

18.1. Objetivos y requisitos cumplidos. 2

18.1.1. El nuevo cluster 2

18.1.2. La documentación. 2

18.2. Planificación y estudios de costes. 2

18.2.1. Planificación temporal 2

18.2.2. Coste económico. 2

18.3. Mejoras y ampliaciones del sistema. 2

18.3.1. Infraestructura de red. 2

18.3.2. IP bonding. 2

18.3.3. Sistema de almacenamiento. 2

18.3.4. Tunning de Sun Grid. 2

18.3.5. Checkpointing (transparente) de procesos. 2

18.3.6. Nuevos nodos. 2

 

 

 

APÉNDICES

 

19. Apéndices. 2

 

19.1. Ficheros de configuración y scripts. 2

19.1.1. Fichero menu.lst 2

19.1.2. Fichero drbd.conf 2

19.1.3. Fichero glusterfs-server.vol 2

19.1.4. Fichero glusterfs-client.vol 2

19.1.5. Fichero ha.cf de master-cluster1. 2

19.1.6. Fichero ha.cf de master-cluster2. 2

19.1.7. Fichero haresources. 2

19.1.8. Script sungrid de heartbeat 2

19.1.9. Fichero drbd.conf de zona spool 2

19.1.10. Fichero glusterfs-server_sge-common.vol 2

19.1.11. Fichero glusterfs-client-sge.vol 2

19.1.12. Fichero bootnode-gluster.shtml 2

19.1.13. Script post_boot.sh. 2

19.1.14. Fichero gmond.conf 2

19.1.15. Fichero gmetad.conf 2

19.1.16. Script jobs_run.sh. 2

19.1.17. Script jobs_run-slave.sh. 2

19.1.18. Script jobs_queued.sh. 2

19.1.19. Script temp_max.sh. 2

19.1.20. Fichero cluster_extra.tpl 2

19.1.21. Fichero meta_view.tpl 2

19.1.22. Fichero graph.php. 2

19.1.23. Script check_sge.sh. 2

19.1.24. Fichero dhcp.conf 2

19.1.25. Fichero update.exim4.conf en master-cluster1. 2

19.1.26. Fichero update.exim4.conf en nodos de computación y servidores de disco. 2

19.1.27. Fichero ntp.conf en nodos master-cluster 2

19.1.28. Fichero ntp.conf en nodos de computación y servidores de disco. 2

19.1.29. Fichero /etc/exports. 2

19.1.30. Fichero awstats.conf 2

19.1.31. Fichero .htaccess. 2

19.1.32. Script wakeup-cluster.sh. 2

19.1.33. Script halt-cluster.sh. 2

19.1.34. Script alta_nodo.sh. 2

19.1.35. Script alta_usuario.sh. 2

19.1.36. Script build_users.sh. 2

19.1.37. Script build_homes.sh. 2

19.1.38. Script master_lectura.sh. 2

19.1.39. Script slave.sh. 2

19.1.40. Script test-disco_lectura.sh. 2

19.1.41. Script master_escritura.sh. 2

19.1.42. Script slave2.sh. 2

19.1.43. Script test-disco_escritura.sh. 2

19.1.44. Fichero resultado_lectura.sh. 2

19.1.45. Listado de paquetes de software instalado. 2

19.2. Índice de Figuras. 2

19.3. Juegos de pruebas. 2

19.3.1. Test de estabilidad. 2

19.3.2. Benchmarks sintéticos. 2

19.3.2.2. Test ad-hoc. 2

19.3.3. Test de usabilidad. 2

19.4. Referencias bibliográficas. 2

 


1. Introducción

 

De igual manera que en la década de los 70s el advenimiento de los miniordenadores dio un giro a la idea de computación masiva, relegando a los poderosos y caros mainframes a aplicaciones prácticas muy concretas, hoy en día cada vez son más las empresas e instituciones, públicas y privadas, que se decantan por utilizar clusters en detrimento de grandes máquinas.

 

La idea que hay detrás de los clusters de computación es simple. Si la potencia de los ordenadores personales de hoy en día es considerable, ¿por qué no utilizar la potencia conjunta de unas decenas, centenares o incluso miles de éstos para que, trabajando conjuntamente, puedan llevar a cabo tareas más complicadas en un menor tiempo y a un menor coste?

 

En los últimos años, paralelamente al crecimiento en potencia del hardware, ha aumentado la cantidad y calidad de las soluciones software que proveen el sistema necesario para hacer que un conjunto de máquinas interconectadas trabajen al unísono como una gran máquina. Los avances en redes de computadores y el abaratamiento del hardware han contribuido a universalizar el uso de clusters.

 

Si bien la mayoría de las grandes empresas del sector informático han desarrollado algún sistema de clustering propio, no hay que menospreciar el esfuerzo de la comunidad open source que, contando con una cantidad ingente de desarrolladores en todo el mundo, ofrecen soluciones totalmente válidas que de hecho, se utilizan en las universidades más prestigiosas del mundo amen de muchas empresas punteras.

           

Este proyecto, ubicado en Laboratorio de Cálculo del Departamento de Lenguajes y Sistemas Informáticos (LCLSI), está formado por distintos grupos de investigación en los que se llevan a cabo tareas que requieren de una gran potencia de cálculo. Está claro que el modelo “ejecuto mis simulaciones en mi PC”, a estos niveles, no es una solución válida. Para dar respuesta a estas necesidades se barajan tres posibles opciones, que pasan por disponer de:

 

·        Una máquina muy potente (muchas CPUs, mucha memoria)

·        Alquiler de recursos de un superordenador (Marenostrum)

·        Un cluster de computación propio, más escalable y económico.

 

Las dos primeras opciones pueden resultar prohibitivas para una sección de un Departamento como LSI, por exigir un fuerte desembolso inicial, de tal forma que la compra de un cluster parece lo más razonable. Y lo es más si tenemos en cuenta que la sección puede hacer un desembolso inicial, comenzar a explotar el hardware disponible e ir comprando más ordenadores (nodos) a medida que dispongan de los fondos necesarios.

 

 

 

1.1. Descripción del proyecto

 

El proyecto que nos ocupa consiste en la implantación de un nuevo sistema de clustering o computación masiva para el Departamento de Lenguajes y Sistemas Informáticos de la Universitat Politècnica de Catalunya.

 

Las principales actividades del departamento son la docencia y la investigación.  Es esta faceta la que requiere de una gran potencia de cálculo dada la complejidad y variedad de los proyectos que se tratan.

 

Durante este proyecto llevaremos a cabo un análisis de los requisitos para el nuevo sistema de clustering, estudiaremos las distintas opciones y realizaremos una propuesta que finalmente se implementará.

 

1.2. Justificación del proyecto

 

El Laboratorio de Cálculo de LSI, y por tanto el Departamento, viene utilizando clusters desde el año 2002. Actualmente hay principalmente tres grupos de investigación que utilizan clusters en LSI. Históricamente el primero de ellos se puso en marcha hace cinco años, dando servicio a unos pocos usuarios que hasta entonces ejecutaban sus trabajos en sus PCs de escritorio o en máquinas departamentales, carentes de la potencia necesaria.

 

En su día se optó por un sistema de clustering tipo SSI (Single System Image) bajo sistema operativo Linux. En este modelo todos los nodos del cluster cuentan con un kernel común modificado para que el conjunto del cluster se comporte como una sola máquina con tantas CPUs como nodos, donde las interconexiones de red sustituyen a las conexiones entre CPUs de un sistema multiprocesador. La gran ventaja de este modelo es la potente abstracción del hardware resultante: los usuarios del cluster pueden ejecutar sus procesos de la misma forma que lo hacen en su PC, despreocupándose del hardware subyacente. El middleware OpenMosix se encargaba de balancear la carga del cluster moviendo a discreción los procesos de un nodo a otro, buscando en cada momento la optimización de los recursos disponibles.

 

Esta solución, que ha funcionado bastante bien hasta la fecha, se topa con tres grandes problemas:

           

            1. El sistema no cuenta con ningún mecanismo de protección ante sobrecargas por exceso de trabajos en ejecución, de tal forma que podría llegar a colapsarse cuando se lanzan tantos procesos como para consumir toda la memoria disponible.

 

            2. El proyecto OpenMosix lleva años sin facilitar ninguna actualización, de tal manera que la versión más reciente sólo está disponible para un kernel antiguo que no soporta el hardware de los ordenadores más modernos, obligando a las secciones que quieren comprar nuevos nodos para su cluster a comprar hardware obsoleto.

 

            3. El número de usuarios que utilizan los clusters crece continuamente (actualmente disponemos de unos 100 usuarios), por lo que es imperativo un sistema de colas para que los procesos se ejecuten de forma ordenada, maximizando la utilización del hardware en el tiempo.

           

La gestión del espacio de disco dentro del cluster es otro punto de vital importancia. Este modelo no cuenta con servidores de disco dedicados, sino que los nodos dedicados a computación exportan su espacio de disco al resto de nodos.

 

Nuevamente observamos tres problemas:

           

  1. Es engorroso para el usuario, que cuenta con tantas zonas de disco como nodos tiene el cluster (más de 20 zonas en algún cluster).

 

  1. El sistema de ficheros en red utilizado (NFS) produce un gran overhead en la red.

 

  1. No es tolerable a fallos. En caso de que uno de los nodos falle, los datos que se encuentran en su zona dejan de estar disponibles.

 

Desde el Laboratorio de Cálculo la propuesta que se realiza apuesta por cambiar el paradigma de clustering por uno basado en colas, más escalable, seguro, moderno y con garantías de continuidad.

 

Dado que las soluciones hardware de almacenamiento de disco dedicados quedan fuera de nuestro alcance, optamos por aprovechar el espacio de disco disponible en los nodos de la mejor manera posible, utilizando un sistema de ficheros en red distribuido y paralelo.

 

Tanto el sistema de colas como el sistema de ficheros deben ser tolerables a fallos, de tal forma que la caída de un nodo no comprometa el funcionamiento del resto del cluster ni a nivel de  computación ni a nivel de disponibilidad de información.

 

1.3. Motivación personal

 

Durante nueve años he trabajado en el Laboratorio de Cálculo de LSI, primero como becario y más tarde como personal laboral. Durante este tiempo he desempeñando labores de administrador de sistemas, siempre ligado a entornos UNIX y a clusters de computación.

 

Mi motivación a la hora de encarar este proyecto no puede ser mayor, ya que se me presenta la oportunidad de continuar la labor comenzada seis años atrás cuando decidimos apostar por la tecnología cluster. Igualmente, qué mejor forma de corresponder el compromiso y agradecimiento recibido por parte de los usuarios que implementar un nuevo sistema, más potente y fiable que les permita obtener mayores cotas de productividad y satisfacción.

 

El desarrollo de este proyecto me ha permitido explorar el estado del arte de los distintos elementos que componen un cluster de computación. El punto de partida de cualquier proyecto de esta envergadura debe contemplar las soluciones ya implementadas.

 

En este sentido establecimos contacto con distintos departamentos de nuestra universidad como Arquitectura de Computadores, Matemática Aplicada I y administradores de sistemas del supercomputador Marenostrum, lo que nos permitió conocer de primera mano la forma de encarar la construcción de un cluster desde el punto de vista de departamentos similares al nuestro.

 

Una vez el cluster entró en funcionamiento decidimos compartir la experiencia adquirida con todos aquellos que nos abrieron sus puertas, así como todo aquel administrador de sistemas de la UPC interesado en clusters de computación, mediante la realización de una presentación en noviembre de 2008.

 

Por otra parte los conocimientos adquiridos en el desarrollo de este proyecto han servido como base para la presentación de la ponencia que llevó por título Sistemes de computació d’altes prestacions i programari lliure en las VII Jornades de programari Lliure, que tuvieron lugar en Junio de 2008. La documentación de la ponencia puede consultarse en:

 

http://gabriel.verdejo.alvarez.googlepages.com/cluster

 

1.4. Organización del documento

 

Un cluster de computación es un sistema complejo, formado por multitud de elementos hardware y software en cuya construcción se realiza una verdadera labor de ingeniería. La optimización de los recursos disponibles buscando el máximo rendimiento al menor coste implica un conocimiento exhaustivo de las tecnologías que utiliza; a saber: sistemas operativos, redes de datos, software de clustering, filesystems paralelos, alta disponibilidad, etc.

 

Este documento consta de cuatro partes:

 

·        Una primera parte de introducción donde se presentan los diferentes componentes de un cluster y se exploran diversas alternativas para cada componente

 

·        Una segunda parte donde se realiza el análisis técnico del proyecto, se analizan las distintas alternativas y propone una solución.

 

·        Una tercera parte que comprende la implementación de la solución propuesta, explicando el proceso de instalación y configuración de cada uno de los componentes y la implantación del nuevo cluster en sustitución del actual.

 

·        Finalmente un apartado de bibliografía y anexos. Por lo general toda referencia aparecerá en los anexos.

 

Este documento pretende servir como obra de referencia en la construcción y mantenimiento de un cluster de computación. Se asume un cierto conocimiento de informática en general y de  administración de sistemas UNIX en particular, ya que es imposible profundizar completamente en todos los temas tratados. De todas formas, el documento está redactado de forma que un lector menos experto, pero con interés, pueda seguir los procedimientos explicados obviando los detalles más técnicos.

1.5. La doble utilidad del documento

 

Este escrito, además de documentar este proyecto, pretende servir también como referencia a las personas encargadas de la administración del cluster.

 

En este sentido es interesante que, además de existir una copia en papel, exista una copia disponible en formato electrónico. Esto permitirá una mayor facilidad de consulta y abrirá la puerta a posibles correcciones y actualizaciones.

 

El cluster cuenta con su propio servidor web que, además de ofrecer servicios relacionados con la monitorización y administración del cluster sirve un repositorio de documentación propia:

 

http://master-cluster1.lsi.upc.edu/docu

 

En esta url, además de una copia de este documento, se encuentra información adicional como manuales y presentaciones.

 

1.6. Convenciones y tipografía

 

Para una mejor comprensión de este documento, dada la elevada naturaleza técnica de su contenido se seguirán una serie de convenciones tipográficas.

 

Convenciones tipográficas

 

Como ya se ha podido ver, los nombres propios de origen extranjero, así como los nombres de instituciones u organizaciones (como Departamento de Lenguajes y Sistemas Informáticos) aparecen en cursiva.

 

Igualmente, todos aquellos anglicismos que necesariamente aparecen en este texto, así como cualquier otro vocablo del ámbito de la informática, aparecerán también en cursiva la primera vez que se referencien. Lo mismo sucederá con palabras que, si bien son de origen foráneo, forman ya parte de nuestro lenguaje (como por ejemplo software).

 

Una parte importante de este proyecto consiste en código fuente de programas, contenido de ficheros datos y configuración, nombres de directorios, ficheros, etc. En estos casos el texto aparecerá en fuente de ancho fijo (como /etc/dhcp3), y los comandos o nombres de programas o scripts, además, en negrita (como check_sge.sh).

 

Convenciones no tipográficas

 

La ambigüedad propia del lenguaje también está presente, en gran medida, en los documentos de carácter técnico. De esta forma, a lo largo del documento, utilizamos indistintamente el término sistema de clustering para denotar tanto al hardware que conforma un cluster como al software que lo gobierna. Siempre que la utilización de estos términos pueda llevar a equívoco se aclarará su significado.

 

Siglas y acrónimos serán utilizados, previa introducción de su significado, para facilitar la lectura del texto.

 


2. Análisis preliminar

 

 

2.1. Situación actual

 

En el momento de comenzar este proyecto, el Departamento de Lenguajes y Sistemas Informáticos contaba con tres clusters de computación. Cada uno ellos propiedad de un grupo de investigación distinto.

 

El modelo HPC[1]  utilizado basado en openMosix que proporcionaba un entorno confortable y productivo para la cantidad inicial de usuarios, ha quedado obsoleto ante el continuo crecimiento tanto en número de usuarios como en necesidades de cálculo y espacio de disco.

 

Igualmente, el esquema lógico de la infraestructura hardware así como el sistema que sustenta los datos de usuario, no cuentan con ningún mecanismo que proporcione tolerancia a fallos (caída de un nodo, fallo de un disco) ni alta disponibilidad.

 

Más adelante, en apartado [7.1] dedicado al análisis del sistema actual, se detallará a nivel técnico las carencias del modelo actual.

 

2.2. Objetivos del proyecto

 

La finalidad de este proyecto es doble. Por una parte, la sustitución de los  clusters por uno nuevo que se adapte a las nuevas necesidades del Departamento y por otra, la creación de una documentación que sirva como  referencia técnica al Laboratorio de Cálculo.

 

El sistema debe proveer a los usuarios un entorno de trabajo sencillo, amigable y proporcionar una escalabilidad que permita afrontar el futuro sentando unas bases sólidas.

 

2.3. Requerimientos del proyecto

 

Una vez expuestos los objetivos del proyecto, enumeraré los requerimientos que tendremos en cuenta a la hora de llevar a cabo el diseño y la implementación:

 

·        La infraestructura hardware del nuevo cluster debe hacer uso del hardware existente (nodos, red y discos).

 

·        Debe soportar una carga de trabajo superior a la actual, dada la tendencia creciente en cuanto a número de usuarios y, por tanto, de volumen de trabajo.

 

·        Debe ser tolerable a fallos. El fallo de una parte del sistema no puede comprometer el funcionamiento del conjunto del cluster.

 

·        Debe ser escalable, tanto a nivel de software como a nivel de infraestructura hardware.

 

En cuanto a la documentación, debe ser clara, concisa y no omitir información básica pero necesaria para el entendimiento completo de conceptos más complejos. Al fin y al cabo esta documentación debe permitir a cualquier persona cualificada del Laboratorio de Cálculo entender el funcionamiento del cluster y poder actuar en caso de que se produzca cualquier incidencia.


PRIMERA PARTE

SISTEMAS DE CLUSTERING

 

 

 


3. Clusters

 

En este apartado daremos una visión general de lo que es un cluster de cómputo, repasaremos brevemente su historia y los clasificaremos atendiendo a diversos criterios según la bibliografía existente.

 

3.1. ¿Qué es un cluster?

 

Cuando hablamos de Clusters en el ámbito de la computación nos referimos al conjunto de hardware y software que aglutina a grupos de ordenadores que, unidos mediante redes de alta velocidad, trabajan de forma conjunta en la resolución de problemas.

 

Los clusters se usan habitualmente para mejorar el rendimiento y/o la disponibilidad por encima de la que provee un solo ordenador, resultando mucho más económico que grandes ordenadores de velocidad y disponibilidad comparables.

 

Cualquier cluster ofrece uno o varios de los siguientes servicios:

 

·        Alto rendimiento: el conjunto del cluster ofrece una capacidad computacional por encima de la de cualquiera de los elementos que lo conforman.

 

·        Alta disponibilidad: la redundancia del hardware permite mantener el servicio que ofrecen aún y cuando falle alguno de los componentes del cluster.

 

·        Balanceo  de carga: la calidad de servicio mejora repartiendo el trabajo entre los nodos del cluster.

 

·        Escalabilidad: la adición de nuevos elementos al cluster provoca un aumento proporcional de su capacidad.

 

En general, un cluster necesita de varios componentes software y hardware para funcionar:

 

·        Nodos

·        Sistema de almacenamiento

·        Sistema Operativo

 

·        Conexión de red

·        Middleware

·        Protocolos de comunicación y servicios

·        Aplicaciones

 

Nodos

 

Pueden ser desde ordenadores corrientes hasta caros sistemas multiprocesador. En general, cuando hablamos de nodo dentro del ámbito de la computación nos referimos a cada uno de los ordenadores que lo conforman. Los nodos pueden ser dedicados si se dedican exclusivamente a labores del cluster o no dedicados si lo hacen de forma parcial o compartida con alguna otra tarea.

 

Sistema de almacenamiento

 

El sistema de almacenamiento en un cluster no es un tema baladí. En un cluster de tamaño medio puede haber cientos de nodos, cada uno ejecutando uno o varios trabajos que acceden simultáneamente  a datos. Si estos datos no son accesibles de forma eficiente, el rendimiento del cluster se verá afectado.

 

Los sistemas de almacenamiento típicos son:

 

·        NAS (Network Attached Storage): es un dispositivo dedicado al almacenamiento de datos y a su compartición en red. Cuenta con un sistema operativo optimizado que permite el acceso a los datos a través de diversos protocolos como CIFS y NFS.

 

·        SAN (Storage Area Network): son unidades de almacenamiento externo que se conectan a uno o varios servidores.

 

·        Discos locales: se utilizan los discos locales de los nodos, ya sean IDE, SATA, SCSI o SAS.

 

La elección de un sistema u otro depende en gran parte de la disponibilidad económica. Los discos duros locales siempre están disponibles en cualquier nodo que se adquiera y siempre pueden sustituirse por discos de mayor tamaño por poco dinero.

 

Los sistemas NAS y SAN son sistemas de un rendimiento superior pero que requieren de un desembolso inicial importante. Posteriormente estos sistemas pueden crecer añadiendo más discos.

 

Como lo habitual es que todos los nodos tengan acceso a los mismos datos, la información del sistema de almacenamiento disponible se exporta mediante algún sistema de ficheros distribuido como NFS (Network Filesystem) o distribuido paralelo como Lustre o GlusterFS.

 

Sistema operativo

 

El sistema operativo de un cluster debe ser  multiproceso y multiusuario. Existen distribuciones específicas que se componen de un sistema operativo y del software de clustering, si bien también es posible añadir la capacidad de clustering a casi cualquier sistema operativo.

 

Sin lugar a dudas es dentro del mundo UNIX donde encontramos la mayor oferta de sistemas de clustering. Más concretamente Linux, dado su carácter libre y su gran difusión es, en cualquiera de sus variantes, el sistema operativo más extendido para estos sistemas de cómputo.

 

Conexión de red

 

La interconexión de los nodos juega un papel muy importante dentro de la arquitectura de un cluster, siendo una parte crítica en determinados tipos de clusters. No en vano las conexiones de red en un cluster vienen a ser lo que las conexiones interprocesador son en un ordenador multiprocesador.

 

La tecnología de conexión puede ser desde la más barata y extendida ethernet hasta las más caras y avanzadas como Myrinet o Infiniband. Estas últimas cuentan con mayor ancho de banda y menor latencia, la cual cosa las hace ideales para clusters de tipo HPC.

 

Middleware

 

El middleware es una pieza de software que se sitúa entre el sistema operativo y las aplicaciones con el fin de proveer:

 

·        Abstracción del hardware: los usuarios ven el cluster como un único ordenador muy potente con el que interactúan, desentendiéndose de la arquitectura subyacente.

 

·        Herramientas de gestión del sistema: migración de procesos, checkpointing, balanceo de carga, tolerancia a fallos, etc.

 

·        Escalabilidad: detección e incorporación automática de nuevos nodos al cluster.

 

El middleware recoge los trabajos enviados al cluster por los usuarios y los distribuye entre los nodos de computación de la mejor manera posible, atendiendo a políticas más o menos sofisticadas de planificación.

 

Aplicaciones

 

Son las tareas que los usuarios envían al cluster. El sistema de clustering debe estar preparado para atender los requisitos de ejecución de las tareas, que pueden ser desde simples scripts a complejos programas paralelos. Estos últimos necesitan del apoyo de librerías de programación paralela como MPI o PVM, que deben integrarse adecuadamente en el sistema.

 

3.2. Un poco de historia

 

La bibliografía no fija una fecha concreta para el origen del término cluster pero es bien sabido que comenzó a utilizarse entre finales de los años 50s y principios de los 60s.

 

 La idea de la explotación de sistemas de ordenadores como un medio para acelerar el cálculo paralelo data de 1967 cuando Gene Amdahl de IBM, publicó su famosa ley, que describe matemáticamente la ganancia esperada al paralelizar tareas en una arquitectura paralela. El artículo define la base para la ingeniería multiprocesador, que es extrapolable a clusters de computación, donde la comunicación interprocesador es sustituida por conexiones de red.

 

La historia de los primeros clusters trascurre paralela a la historia de las primeras redes. Una de las principales motivaciones para el desarrollo de las redes de entonces era conectar recursos de cálculo, creando de hecho un gigantesco cluster.

 

Las redes de conmutación de paquetes fueron inventadas por la corporación RAND en 1962. Utilizando esta tecnología, en 1969, el proyecto ARPANET creó la primera red de computadoras, que unían los recursos de cuatro centros de cálculo. El proyecto ARPANET creció  hasta convertirse lo que hoy en día es Internet.

 

El desarrollo de PCs y clusters de grupos de investigación continuó de la mano con el de las redes y el sistema operativo Unix que a principios de los 1970s, ya incluía protocolos de comunicaciones de red como TCP/IP.

 

Pero no fue hasta 1983 cuando, gracias a los conceptos formalizados por BSD Unix e implementados por Sun Microsystems, el público contó con verdaderas herramientas que permitiesen la compartición  recursos, como ficheros gracias a la inclusión del sistema de ficheros distribuido NFS.

 

ARCnet, el primer cluster comercial desarrollado por Datapoint en 1977, no tuvo una gran acogida. Sin embargo en 1984 Digital introdujo con gran éxito el VAXcluster, acompañado del sistema operativo VAX/VMS. Ambos sistemas no permitían el procesamiento paralelo, pero sí la compartición de recursos como archivos y periféricos.

 

Otros productos pioneros fueron el Tandem Himalaya en 1994 como producto de alta disponibilidad  y el IBM S/390 Parallell Sysplex destinado a grandes empresas.

 

Cabe remarcar también el papel jugado por el software Parallel Virtual Machine (PVM), creado en 1989. Este proyecto open source basado en comunicaciones TCP/IP permitió la creación de superordenadores creados por cualquier cantidad de sistemas conectados por red. Rápidamente estos clusters superaron con creces la potencia de los grandes y caros superordenadores de la época.

 

Finalmente, en 1995 se creó el primer Beowulf, cluster con sistema operativo Linux caracterizado por utilizar ordenadores y redes convencionales con el fin único de procesar tareas paralelas con un gran throughput.

3.3. Tipos de cluster

 

El término cluster tiene diferentes connotaciones en función de los servicios que ofrecen. Si atendemos a una categorización según el fin para el que fueron concebidos, tenemos los siguientes tipos:

 

·        HPC (High Performance Clusters o Clusters de Alto Rendimiento): Llevan a cabo tareas de una gran capacidad computacional, que ejecutadas en ordenadores corrientes serían inabarcables, ya sea por sus altos requisitos de memoria, potencia de cálculo o de ambas.

 

·        HTC (High Throughput Clusters o Clusters de Alta Eficiencia): Están diseñados para llevar a cabo la mayor cantidad de tareas en el menor tiempo posible. Los datos de las tareas son individuales entre si y la latencia entre los nodos no es tan importante como en los clusters HPC. 

 

·        HA (High Availability Clusters o clusters de Alta Disponibilidad): También conocidos como clusters Failover, su principal cometido es mejorar la disponibilidad de los servicios que proporciona. Su arquitectura se compone de nodos redundantes que proveen el servicio cuando algún componente falla.

 

 Normalmente están formados por dos nodos, que es lo mínimo necesario para tener redundancia. La existencia de redundancia en el hardware evita tener un único punto de fallo, maximizando así la disponibilidad.

 

Parte del éxito de los clusters radica en su extrema flexibilidad desde el punto de vista de la arquitectura. En este sentido encontramos las siguientes categorías:

 

·        Clusters Homogéneos: Todos los nodos cuentan con el mismo hardware y sistema operativo.

 

·        Clusters Heterogéneos: Nodos con diferente hardware y sistema operativo.

 

·        Clusters Semihomogéneos: Hardware y sistemas operativos similares, pero con distinto rendimiento.

 


4. Cluster Filesystems

 

Cuando hablamos de un sistema de ficheros para un cluster se suele pensar en sistemas de ficheros complejos, extraños y alejados de los utilizados habitualmente en sistemas más convencionales. Nada más lejos de la realidad. Un cluster no tiene porqué contar con el filesystem más complejo ni con el que usan los clusters más potentes, ni siquiera con uno concebido a tal efecto. Para cada cluster, o mejor dicho, dependiendo del uso y de la exigencia que se vaya a dar, hay un abanico enorme de posibilidades que van desde filesystems distribuidos ordinarios a complejos filesystems paralelos.

 

4.1. Glosario

 

En este apartado estudiaremos algunos filesystems susceptibles de ser utilizados dentro de un cluster de computación como el que proyectamos. Antes es necesario dar algunas definiciones para facilitar su comprensión:

 

·        Filesystem: método de almacenamiento y organización de ficheros y los datos que permite su búsqueda y acceso.

 

·        Servidor: máquina que pone a disposición de otras máquinas (clientes) conectadas por red un sistema de ficheros.

 

·        Cliente: máquina que accede al sistema de ficheros de una máquina remota (servidor).

 

·        Daemon: o demonio es un programa que se ejecuta en segundo plano (background) de forma indefinida encargado de recibir y procesar peticiones.

 

·        Automounter: sistema que monta sistemas de ficheros bajo demanda, reduciendo así el overhead de mantener la conexión entre servidor y clientes cuando los clientes no están accediendo al filesystem remoto.

 

·        Bloqueo: o en inglés lock, es un mecanismo que permite asegurar la integridad de los datos cuando son accedidos de forma concurrente.

 

·        Stripe: aplicado a filesystems paralelos, cada una de las partes en que se divide un fichero y que son guardadas en servidores de datos distintos para aumentar el rendimiento de lectura y escritura.

 

·        Network filesystem o distributed filesystem: es un sistema de ficheros que soporta la compartición de ficheros, impresoras u otros recursos de forma persistente a través de una red.

 

·        Parallel filesystem: sistemas de ficheros distribuidos que distribuyen los datos en varios servidores para obtener un mayor rendimiento. Suelen utilizarse en clusters de alto rendimiento (HPC).

 

4.2. Sistemas de ficheros distribuidos

 

Un sistema de ficheros distribuido se muestra a los usuarios como un sistema de ficheros local convencional. La multiplicidad y la dispersión de los servidores y su almacenamiento queda oculto. De hecho, los programas que tratan con datos no distinguen si éstos son locales o no.

 

El rendimiento esperado de un sistema de ficheros distribuido es menor que el de un sistema de ficheros local, ya que al tiempo de acceso a disco y proceso de CPU hay que sumar el overhead producido por la comunicación por la red. Esto incluye el tiempo de realizar la petición al servidor y el tiempo en obtener la respuesta en ambas direcciones más el overhead de CPU que provoca el protocolo de comunicaciones.

4.2.1. Network File System (NFS)

 

NFS es un protocolo de nivel de aplicación según el modelo OSI que se utiliza en sistemas de archivos distribuidos en redes de área local. Permite que distintos sistemas conectados a una misma red tengan acceso a ficheros remotos como si fueran locales. Fue desarrollado en 1984 por Sun Microsystems con el objetivo de que fuera independiente de la máquina, el sistema operativo y el protocolo de transporte.

 

 

nfscomponents

Figura 4.1. El protocolo NFS en los modelos OSI y TCP/IP

 

 

El protocolo NFS está incluido por defecto en los sistemas operativos UNIX. NFS utiliza un esquema cliente-servidor, donde los clientes acceden de forma remota a los datos que se encuentran almacenados en el servidor.

 

Los clientes utilizan menos espacio de disco, ya que los datos están centralizados en un servidor, evitando así tener datos replicados. La centralización del home de usuarios es un uso habitual de NFS dentro de organizaciones.

 

Todas las operaciones sobre ficheros son síncronas. Esto quiere decir que la operación sólo retorna cuando se ha completado el trabajo asociado, que en el caso de una escritura será cuando el servidor escriba físicamente los datos en disco. De esta forma la integridad de los ficheros queda garantizada.

 

Actualmente hay tres versiones en uso:

 

·        Versión 2: originalmente desarrollada sobre UDP,  es la más antigua y está soportada por muchos sistemas operativos.

 

·        Versión 3: incluye soporte 64 bits que permite manejar ficheros de más de 4 GB, escrituras asíncronas para mejorar el rendimiento, atributos extendidos y en algunas implementaciones, soporte TCP como transporte.

 

·        Versión 4: influenciado por AFS y CIFS, incluye cambios orientados a mejorar el rendimiento y la seguridad como soporte Kerberos y ACLs.

4.2.2. Samba

 

Samba es un software opensource para sistemas UNIX que implementa el protocolo SMB (Server Message Protocol) de archivos compartidos de Microsoft Windows, que permite la compartición de ficheros e impresoras entre sistemas Windows y UNIX.

 

Samba implementa una docena de protocolos entre los que se encuentran NetBIOS, WINS la suit de protocolos de dominio NT, Active Directory y SMB, también conocido como CIFS.

 

Como hemos comentado, Samba permite la compartición de recursos en sistemas heterogéneos. Ahora bien, limitaciones como la incompatibilidad con los atributos de ficheros y los enlaces simbólicos de los sistemas de ficheros del mundo UNIX, lo desaconsejan como filesystem distribuido para clusters formados exclusivamente por máquinas UNIX.

 

4.3. Sistemas de ficheros paralelos

 

Los sistemas de ficheros distribuidos paralelos surgen de la necesidad de solucionar los problemas que nos encontramos al utilizar sistemas de ficheros distribuidos convencionales en clusters de computación.

 

Sistemas de ficheros distribuidos como NFS provocan un gran overhead de red que en condiciones de E/S intensiva llegan a saturar el acceso a los datos. Si imaginamos un escenario con un cluster de tamaño medio de unos pocos centenares de nodos es fácil hacerse a la idea de la cantidad ingente de peticiones de E/S que pueden generarse en un disco compartido.

 

Los sistemas de ficheros distribuidos paralelos solucionan este problema reduciendo el overhead de red y distribuyendo los datos entre varios servidores para paralelizar las lecturas y escrituras.

 

4.3.1. GPFS

 

General Parallel Filesystem (GPFS) es un sistema de ficheros distribuido paralelo desarrollado por IBM. Proporciona acceso compartido concurrente de alta velocidad a aplicaciones que se ejecutan en distintos nodos de un cluster.

 

Inicialmente fue diseñado para soportar las altas tasas de transferencia requeridas por las aplicaciones multimedia, pero su diseño resultó muy adecuado para la computación científica. Fue desarrollado en 1993, pero no vio la luz comercialmente hasta 1998 cuando fue publicado para el sistema operativo AIX. Desde 2001 también hay disponible una versión para Linux.

 

El principio de funcionamiento de GPFS es el mismo que el de cualquier sistema de ficheros paralelo. En un cluster de almacenamiento GPFS hay nodos servidores, que almacenan datos, y nodos clientes que acceden a ellos. Cuando se realiza una operación de escritura sobre este filesystem los datos se trocean  y se distribuyen en tiras (stripes) que son almacenadas en varias máquinas servidoras de disco. De esta forma se obtiene un mayor rendimiento al acceder a los distintos bloques en paralelo. Además GPFS permite alta disponibilidad, ya que los datos pueden guardarse replicados en varios servidores.

4.3.2. Lustre

 

Lustre es un sistema de ficheros distribuido paralelo para clusters escalable, robusto y con alta disponibilidad. Desarrollado y mantenido por Sun Microsystems, está disponible bajo licencia GNU GPL.

 

Proporciona  un sistema de almacenamiento que escala correctamente desde sistemas con decenas de nodos y terabytes de capacidad de almacenamiento hasta grandes clusters con decenas de miles de nodos con petabytes de información.

 

Lustre es considerado el mejor filesystem distribuido paralelo. De hecho 15 de los 30 mayores superordenadores del mundo[2] hacen uso de Lustre y su gran escalabilidad.

 

Durante la fase de pruebas/integración comprobaremos si, el que sobre el papel es el mejor sistema de ficheros distribuido paralelo, se adapta a nuestras necesidades. Nuestro sistema de cluster no llega al centenar de nodos y tiene algunas limitaciones hardware por lo que, como veremos, será necesario aunar distintas tecnologías para tener un sistema funcional.

 

 

kompass_lustre

Figura 4.2: Ejemplo de cluster Lustre

 

4.3.3. GlusterFS

 

GlusterFS es un sistema de ficheros paralelo distribuido, disponible bajo licencia GNU v3, capaz de escalar hasta varios petabytes. GlusterFS aglutina varias unidades de almacenamiento independientes en un gran sistema de ficheros paralelo sencillo y altamente escalable. Cada unidad de almacenamiento cuenta con su propia CPU, memoria, bus de E/S, almacenamiento RAID e interfaz de red. El rendimiento pico teórico sería el rendimento agregado de todas las unidades. GlusterFS está diseñado para escalar linealmente en clusters de gran tamaño.

 

El servidor GlusterFS permite exportar volúmenes sobre la red. El cliente GlusterFS monta los volúmenes del servidor en el kernel VFS. La mayor parte de la funcionalidad de GlusterFS está implementada mediante translators.

 

La idea de translator está basada en el sistema operativo GNU/Hurd (http://hurd.gnu.org). Los Translators son un mecanismo muy potente que permite a GlusterFS extender sus capacidades a través de un interfaz bien definido. Los translators del lado cliente y servidor son compatibles, por lo que se pueden cargar indiferentemente en cada parte. Son objetos binarios compartidos (.so) que se cargan en tiempo de ejecución según el ficheros de especificación del volumen.

 

Glusterfs-cluster

Figura 4.3: Ejemplo de configuración de GlusterFS con 4 nodos de almacenamiento y 1 nodo cliente


5. Software de Clustering

 

Como hemos visto en el capítulo [3] no basta con conectar una serie de ordenadores en red para tener un cluster. Es necesario un software o middleware que se encargue de distribuir los trabajos de los usuarios entre los nodos disponibles de forma óptima.

 

A continuación veremos varios ejemplos de sistemas de clustering, profundizando especialmente en openMosix por ser el middleware de los tres clusters en producción. Más adelante, en el análisis del sistema actual (apartado [7.1]), volveremos a hablar de openMosix y expondremos las limitaciones que nos han llevado a su sustitución.

 

5.1. openMosix

 

openMosix tiene su origen en Mosix, un sistema de clustering SSI (Single System Image), cuyo desarrollo comenzó en 1981 en la Hebrew University of Jerusalem. Tras diversas encarnaciones en diferentes sistemas UNIX, Mosix es portado a Linux en 1999.

 

A finales de 2001 Mosix deja de distribuirse bajo licencia GPL, y es entonces cuando nace openMosix, la versión abierta de Mosix, bajo licencia full GPL2. Esto permitió que el proyecto openMosix contase con una amplia comunidad respaldándolo y contribuyendo a su desarrollo.

 

OpenMosix es un software que permite que ordenadores conectados en red funcionando bajo GNU/Linux trabajen de forma cooperativa. Es capaz de balancear automáticamente  la carga entre los diferentes nodos del cluster y permite la adición o sustracción de nodos en caliente sin necesidad de interrumpir el servicio.

 

La carga se distribuye entre los distintos nodos atendiendo a parámetros como tipo de conexión, memoria disponible y velocidad de CPU.

 

Dado que openMosix forma parte del kernel y mantiene total compatibilidad con Linux, los programas de usuario, ficheros y otros recursos funcionarán igualmente sin cambio alguno. El usuario final no notan diferencia alguna entre ejecutar sus aplicaciones en su sistema Linux o en un cluster openMosix. Para ellos, la totalidad del cluster se presenta como un gran sistema multiprocesador.

 

OpenMosix consta de un parche de kernel Linux compatible con plataformas IA32. Este parche introduce las modificaciones necesarias en el kernel que permiten la comunicación entre los nodos del cluster. Todos los nodos de un cluster openMosix cuentan con el mismo kernel modificado, de ahí el nombre de cluster Single System Image (SSI).

 

El algoritmo de balanceo de carga migra los procesos entre los distintos nodos de forma transparente, intentando optimizar su utilización en todo momento, si bien el administrador puede modificar manualmente este algoritmo.

 

El hecho de que la migración de procesos se haga de forma transparente hace que el conjunto del cluster se muestre como un gran sistema multiprocesador (SMP) con tantos procesadores disponibles como el sumatorio de los procesadores de todos los nodos.

 

 

 

Figura 5.1: Arquitectura de un cluster tipo SSI

 

 

Características de openMosix

 

·        Alta escalabilidad.

·        Algoritmo adaptativo de balanceo de carga.

·        Migración dinámica de procesos.

·        Middleware de clustering en kernel, por lo que no son necesarias librerías externas.

·        Totalmente transparente a usuario y aplicaciones.

·        Fácil instalación y administración.

·        Posibilidad de añadir y eliminar nodos en caliente.

·        Integración con librerías de paralelización MPI/PVM.

 

Funcionamiento de openMosix

 

OpenMosix consta de una parte de sistema (kernel space) y otra de usuario (user space):

 

La parte de usuario dispone de una serie de herramientas que permiten monitorizar el cluster y la modificación del comportamiento por defecto de openMosix.

 

La parte de sistema consiste en un parche de kernel que a su vez consta de cuatro subsistemas:

 

  1. Migración de procesos: Cada proceso tiene su nodo raíz (UHN, Unique Home Node) que se corresponde con el nodo que lo ha creado. El concepto de migración implica la división del proceso en dos partes: la parte de sistema y la de usuario. La parte de sistema (deputy) permanece en su UHN durante toda la vida del proceso, mientras que la parte de usuario puede moverse libremente por todos los nodos del cluster.

 

 

 

Figura 5.2: División de procesos en openMosix

 

 

El sistema de migración utiliza algoritmos del campo de la economía para decidir cuándo migrar un proceso. A cada recurso  (CPU, memoria, E/S) de cada nodo se le da un coste.

 

Estos costes son unificados en un GFC (global cost function). El valor del CFG de un nodo no se publicita a todo el cluster, sino a un subconjunto aleatorio de sus vecinos.

 

Los procesos son migrados al nodo donde tienen el menor coste: se obtiene así la distribución más “económica” posible. Cada proceso puede migrar cuantas veces sea necesario.

 

  1. Memory ushering: Este subsistema se encarga de migrar las tareas que superan la memoria disponible en el nodo en el que se ejecutan. Las tareas que superan este límite son migradas forzosamente a otros nodos con la suficiente memoria como para ejecutar el proceso sin necesidad de hacer swap a disco, evitando así una gran pérdida de rendimiento.

 

  1. Mosix File System (MFS): MFS permite que sistemas de ficheros de nodos remotos sea accesibles localmente. Si se habilita esta opción en el kernel, el sistema de ficheros del nodo local y los demás aparecerán montados en /mfs.

 

  1. Direct File System Access (DFSA): esta opción permite a los procesos hacer operaciones de E/S de forma local en nodos remotos. Sin DFSA, cada operación de E/S que se produzca en un nodo “migrado” será enviada al UHN, donde se resolverá.

 

5.2. Condor

 

Condor es un software que crea un entorno de computación HTC formado por estaciones de trabajo UNIX conectadas en red. Fue creado por la University of Winsconsin-Madison (UW-Madison) a principios de los años 90s. Como otros sistemas de colas, Condor provee un sistema de encolado de trabajos, políticas de planificación, prioridades, monitorización y control de recursos. Los usuarios envían sus trabajos al planificador, que les asigna una cola y elije cuándo y dónde ejecutarlos en base a una política preestablecida, monitoriza su progreso y finalmente informa a los usuarios de su finalización. Como todo sistema HTC lo que se busca es obtener un gran rendimiento a largo plazo.

 

Condor puede configurarse para utilizar los ciclos libres en máquinas conectadas a la red y que no están pensadas como máquinas de computación, como de PCs de escritorio. En este caso, en momentos en los que estas máquinas no son utilizadas pasan a formar parte del cluster. Cualquier evento de usuario como un input de teclado o ratón, provoca que la máquina salga del cluster.

 

Este modelo es especialmente interesante para organizaciones que cuentan con una gran número de PCs de usuario con muchos ciclos libres; por ejemplo, durante las noches o fuera del horario laboral. Durante estos espacios de tiempo, el cluster Condor crecería considerablemente, incrementando notablemente el thoughput de cómputo.

 

5.3. PBS

 

PBS (Portable Batch System) es un sistema de trabajos batch y un sistema de gestión de recursos. Fue desarrollado por la NASA a principios de los años 90s conforme al estándar POSIX 1300.2d Batch Environment Standard . Como tal acepta trabajos batch en forma de shellscript con atributos de control, preserva y protege el trabajo hasta que está listo para ser ejecutado, lo ejecuta y, finalmente, devuelve la salida al usuario.

 

PBS consta de cuatro componentes:

 

·        Commands: PBS proporciona una serie de comandos en línea así como un interfaz gráfico, ambos conforme al estándar POSIX 1003.2d. Estos comandos permiten enviar, monitorizar, modificar y borrar trabajos.

 

·        Job Server: es la parte central de PBS. Todos los comandos y daemons se comunican con el servidor. La principal función de éste es proveer los servicios batch básicos como recibir y crear un trabajo, modificarlo, protegerlo de posibles caídas del sistema y ponerlo en ejecución.

 

·        Job Executor: es el daemon que realmente pone el trabajo en ejecución. Su nombre, mom, se debe a que es la madre de todos los procesos en ejecución. Mom pone en ejecución el trabajo cuando recibe una copia del servidor. También reproduce la sesión del usuario propietario del trabajo  (shell, .login, .csh, etc). Finalmente, al acabar el trabajo, devuelve la salida al usuario.

 

·        Job Scheduler: este daemon contiene las políticas que controlan qué trabajo, cuándo u dónde se ejecutan los trabajos.

 

5.4. Sun Grid Engine

 

Sun Grid Engine (SGE) es un sistema de gestión de colas open source desarrollado por Sun Microsystems.

 

En el año 2000 Sun adquirió Gridware, empresa especializada en sistemas de gestión de resursos de computación para ofrecer una versión free de Gridware para Solaris y Linux a la que llamó Sun Grid Engine.

 

En 2001, liberó el código y adoptó el modelo de desarrollo open source, tras lo que surgieron ports para otros sistemas UNIX.

 

Es un sistema altamente configurable, sencillo de de administrar y de utilizar por parte de los usuarios. Su escalabilidad lo ha llevado a ser el sistema de clustering de mayor éxito entre los mayores clusters de supercomputación.

 

Como sistema de gestión de colas, SGE se encarga de aceptar, planificar y ejecutar grandes cantidades de trabajos. También se encarga de la gestión y planificación de recursos distribuidos como procesadores, memoria, disco y licencias de software.

 

Un cluster Sun Grid se compone de un master host y uno o más execution host. Además pueden configurarse múltiples shadow hosts como hot spares capaces de tomar el control del master host cuando falle, proporcionando alta disponibilidad.

 

Al igual que Condor y PBS, Sun Grid trabaja con shellscripts que definen los requisitos de los trabajos de los usuarios, pero además puede tratar directamente con binarios e incluso ejecutar trabajos interactivos.

 

Se trata, sin lugar a dudas, del producto más completo disponible en el mercado, tanto por rendimiento como por facilidad de uso y capacidad de configuración. A todo esto hay que sumar el hecho de que se trata de un proyecto opensource con una comunidad de desarrolladores y administradores ingente y, algo de lo que pecan otros proyectos, el respaldo de una empresa del prestigio como Sun Microsystems.

 

 

 

 


6. Alta disponibilidad

 

 

En el apartado [3.3] hemos visto que los clusters HA o de alta disponibilidad son un tipo de clusters con nodos redundantes encargados de mantener un servicio en caso de fallo hardware. En este capítulo explicaremos los principios básicos de la alta disponibilidad.

 

En servicios críticos suelen implementarse sistemas tolerables a fallos (fault tolerant o FT) en los que el servicio siempre está disponible. Estos sistemas son extremadamente caros, por lo que suelen quedar fuera del abasto de empresas e instituciones de tamaño medio.

 

Los sistemas de alta disponibilidad intentan obtener prestaciones cercanas a la tolerancia a fallos a un precio mucho menor. La alta disponibilidad está basada en la replicación de elementos, lo que resulta mucho más barato que contar con un solo elemento tolerable a fallos.

 

A efectos prácticos, la diferencia entre los sistemas tolerables a fallos y los de alta disponibilidad es el periodo de tiempo en el cual el servicio no está disponible (downtime). En sistemas tolerables a fallos este tiempo no existe, mientras que en los sistemas de alta disponibilidad se intenta minimizar pero existen, pudiendo ser de unos segundos a varios minutos, dependiendo del timeout que decide si el sistema ha fallado.

 

Un sistema de alta disponibilidad se basa en la replicación de elementos, ya sean piezas hardware concretas o servidores completos, tomando como modelo los RAID (Redundant Array of Independent Disks). El objetivo de la replicación es eliminar los puntos de fallo únicos (SPOF, Single Point of Failure). Cualquier elemento no replicado es susceptible de fallar y producir un corte en el servicio. Cuando lo que se replica es un servidor completo hablamos de un cluster HA.

 

6.1. Funcionamiento de un sistema HA

 

A continuación definiremos una serie de conceptos básicos para la alta disponibilidad:

 

Failover

 

Es el nombre genérico que se da a un nodo que puede asumir la responsabilidad de otro, importar sus recursos y levantar sus servicios. Cuando se da esta situación, en el caso de servicios con nodos duplicados, nos encontramos temporalmente en un escenario de SPOF hasta que el administrador restaure el nodo caído.

 

Takeover

 

Es un failover automático que se produce cuando un nodo detecta el fallo de otro. Para ello es necesario mecanismos de monitorización del servicio. Debe haber mecanismos que obliguen al nodo fallado a ceder sus servicios para evitar inconsistencias de funcionamiento.

 

Switchover o Giveaway

 

Es un failover manual que consiste en ceder los servicios del nodo que ha fallado a otro nodo mientras se llevan a cabo las actuaciones administrativas pertinentes.

 

Splitbrain

 

Para la gestión de un cluster HA es necesario un mecanismo de comunicación y verificación de los nodos que lo integran. Cada nodo debe gestionar sus propios recursos según el estado del cluster a la vez que chequea el estado de los otros nodos y servicios.

 

Se produce un splitbrain cuando la comunicación entre los nodos falla. En esta situación cada nodo cree que es el único activo y como no puede saber el estado de su compañero considera que ha fallado y fuerza un takeover.

 

Esta situación es peligrosa, ya que los dos nodos intentan apropiarse de los recursos. El peligro es aún mayor cuando el servicio es, por ejemplo, un sistema de almacenamiento de datos, en el que cada nodo podría escribir por su cuenta y provocar corrupción de datos.

 

Para solucionar este tipo de situaciones, cuando un nodo detecta un fallo reserva un recurso compartido llamado quórum. El quórum es un recurso exclusivo, que sólo puede ser reservado por un nodo. El nodo que intente reservarlo y no pueda entiende que debe abandonar el cluster y ceder sus servicios.

 

6.2. Soluciones de HA en entornos Linux

 

A continuación analizamos algunas soluciones que implementan mecanismos de alta disponibilidad en entornos Linux:

 

Heartbeat

 

Heartbeat es considerado como el estándar de facto de la alta disponibilidad en entornos Linux. Se engloba dentro del proyecto Linux-HA (Linux High Availability) y es ampliamente adoptado por miles de clusters en todo el mundo que proveen servicios críticos.

 

Heartbeat forma parte de la mayoría de las distribuciones Linux, si bien se trata de un software altamente portable que corre sin problemas en sistemas FreeBSD, Solaris, OpenBSD y MacOS/X. Cuenta con licencia GPL. Sus principales características son:

 

·        No hay limitación en el  número de nodos que puede monitorizar. Puede utilizarse para monitorizar desde clusters sencillos hasta clusters muy grandes.

 

·        Monitorización de recursos: los recursos pueden relanzarse o moverse a otro nodo en caso de fallo.

 

·        Dispone de sofisticadas políticas de gestión de recursos.

 

·        Permite definir distintas políticas en función del tiempo.

 

·        Incluye scripts para la gestión de recursos como BBDD, servidores web, filesystems, siendo fácil crear scripts personalizados para nuevo servicios.

 

LVS

 

LVS (Linux Virtual Server) permite crear clusters de balanceo de carga, en los que un nodo master se encarga de gestionar y repartir las conexiones entre varios nodos slave. LVS puede llegar a gestionar hasta 200 nodos slave.

 

Ldirectord es un daemon que se ejecuta en el nodo master LVS que se encarga de comprobar el servicio en los nodos slave y eliminarlos e insertarlos en el cluster dinámicamente.

 

En la práctica resulta un producto menos versátil que heartbeat.

 

Piranha

 

Es el nombre de la solución de RedHat basada en LVS, a la que se ha añadido una interfaz de usuario que facilita su configuración.

 

UltraMonkey

 

Es una variante de LVS creada por VA Linux que utiliza Heartbeat para ofrecer clusters de alta disponibilidad con balanceo de carga. En este tipo de clusters se añade un segundo nodo master para eliminar el SPOF de los clusters LVS.


SEGUNDA PARTE

DISEÑO E IMPLEMENTACIÓN

 

 


7. Estudio, análisis y diseño de una solución

 

Una vez explicados los distintos componentes que forman un cluster, estamos en disposición de revisar las especificaciones y concretar los requisitos de nuestro proyecto.

 

El análisis de los requisitos nos llevará a lo largo del proyecto a plantear varios diseños y arquitecturas[3] posibles para el nuevo cluster, que tras implementarlos y llevar a cabo las pertinentes pruebas de integración, estabilidad y rendimiento nos conducirán a la propuesta final.

 

7.1. Análisis del sistema inicial

 

En el apartado [2.1] hemos introducido los clusters existentes en el Departamento de LSI. A continuación realizaremos un análisis en profundidad de sus componentes y su funcionamiento.

 

El Departamento de LSI tiene tres clusters de computación. Cada uno de ellos era independiente de los otros, tanto a nivel físico como lógico. Se trata de tres clusters del mismo del mismo tipo, diferenciándose sólo en el número de nodos que lo conforman.

 

A nivel hardware, cada cluster está compuesto de una serie de máquinas (PCs enracables) conectados a una red privada mediante  un switch gigabit ethernet. Una de las máquinas está conectada a la red de LSI y a la red privada del cluster, sirviendo de puerta de acceso al mismo.

 

A nivel software todas las máquinas que pertenecen a un mismo cluster cuentan con el mismo sistema operativo y la misma imagen de kernel, requisito imprescindible al tratarse de máquinas con un sistema de clustering tipo SSI.

 

Cada máquina cuenta con uno o dos discos duros, en cuyo caso se configuran en modo RAID1[4], en los que se crea una partición para datos de usuario. Esta partición se exporta al resto de máquinas del cluster por NFS, de tal forma, que en cada nodo del cluster tenemos N zonas NFS montadas, una por cada una de las N máquinas que componen el cluster.

 

La figura [7.1] muestra el esquema de los clusters actuales, con un nodo de acceso y N máquinas dedicadas a cómputo y a servidor disco.

 

Los motivos que nos llevan a abandonar este modelo de cluster son los siguientes:

 

·        openMosix

 

o       No tiene ningún mecanismo de limitación de recursos: cualquier usuario puede, en un momento dado, lanzar tantos procesos como quiera y saturar un nodo o el cluster completo.

 

o       Presenta problemas con varios tipos de aplicaciones: el mecanismo de migración automática de openMosix no funciona con aplicaciones que hacen uso de threads o memoria compartida.

 

o       Estrechamente ligado al kernel: openMosix impone el kernel de los nodos, siendo el más reciente de la rama 2.4, sin soporte para el hardware de los nuevos nodos.

 

o       Proyecto cancelado el 1/4/2008.

 

 

 

 

Figura 7.1: Esquema de cluster openMosix de LSI

 

 

·        Sistema de zonas de disco NFS

 

o       N zonas: Cada usuario tiene tantas zonas como nodos hay en el cluster. Se hace difícil controlar dónde están los datos.

 

o       Fragmentación del espacio: no se aprovecha correctamente todo el espacio disponible.

 

o       Rendimiento de NFS: bajo situaciones de estrés con multitud de accesos concurrentes las zonas exportadas por NFS tienen un rendimiento mediocre.

 

7.2. Revisión de objetivos y requisitos  

 

Recordemos que este proyecto tiene dos objetivos:

 

  1. La implantación de un nuevo sistema de cluster para el Departamento de LSI.

 

  1. La creación de una documentación de referencia y administración para el Laboratorio de Cálculo de LSI.

 

Tras exponer los conceptos necesarios para entender el funcionamiento de las partes que conforman un cluster de computación, procedemos a realizar el análisis de los requisitos del nuevo sistema.

7.2.1. Requisitos funcionales                  

 

Veamos qué servicios debe prestar el nuevo cluster.

 

  • En primer lugar, el nuevo cluster debe ofrecer un servicio igual al que ofrece el sistema actual, es decir, debe ser capaz de procesar los trabajos de los usuarios y debe disponer de un espacio de disco para albergar sus datos y programas en un sistema de disco centralizado.

 

  • El middleware elegido debe ser personalizable a nivel de gestión de colas, proyectos, grupos de usuarios, etc.

 

  • Además debe contar con un software de gestión de imágenes de sistema que permita instalar y modificar fácilmente el sistema en los nodos que la componen, de forma que la instalación y posterior mantenimiento de los nodos (más de 50) sea asumible.

 

  • El cluster debe ser monitorizable, es decir, el administrador debe tener las herramientas necesarias para controlar el estado de sus componentes y percatarse de cualquier fallo.

 

7.2.2. Requisitos no funcionales   

 

  • El nuevo cluster también debe cumplir ciertos requerimientos de eficacia y seguridad. Concretamente debe ser capaz de soportar una mayor carga de trabajo y debe ser capaz de mantener el servicio a pesar del fallo de cualquiera de sus componentes.

 

  • Como hemos comentado, el número de usuarios de los clusters ha crecido considerablemente los últimos años y con ellos el volumen de trabajo que el cluster debe procesar. El nuevo sistema debe ser capaz de procesar el volumen actual y futuro de trabajo haciendo uso del hardware disponible. En este sentido, el aumento del volumen de trabajo por encima de cierto umbral nunca debe llevar a un fallo en el cluster.

 

  • El incremento del número de usuarios trae consigo una mayor necesidad de capacidad de almacenamiento de datos. El nuevo cluster debe contar con un sistema rápido, no fragmentado, transparente y escalable, que pueda crecer cuando sea necesario.

 

  • Se establece una batería de pruebas o benchmarks (ver apartado  [19.3]) encaminados a probar la estabilidad, el rendimiento y la usabilidad de los sistemas propuestos.

 

7.3. El nuevo cluster

 

Una vez introducidos los conceptos necesarios y descritos los distintos componentes del nuevo sistema estamos en disposición de explicitar y analizar la solución propuesta.

 

En primer lugar describiremos el sistema base, es decir, la infraestructura hardware y software que sustentará el sistema de clustering. Los siguientes puntos detallarán cada uno de los componentes y servicios un cluster de computación.

7.3.1. El sistema base

 

Uno de los requerimientos no funcionales del proyecto es que debemos reutilizar el hardware que conforman los tres clusters existentes.

 

Contamos, inicialmente, con el hardware de los tres clusters de LSI:

 

·        20 nodos de eixam

·        10 nodos de tenada

·        10 nodos de nozomi

·        1 switch 3Com gigabit de 48 puertos

·        2 switches 3Com gigabit de 16 puertos

·        3 Multiplexadores de puertos KVM

 

Además de estos nodos, cada grupo había comprado nodos que aún no habían sido instalados porque su hardware no era compatible con el kernel de openMosix:

 

 

·        6 nodos de eixam

·        4 nodos de tenada

·        6 nodos de nozomi

 

Algunos de estos nodos cuentan con discos de gran capacidad (750GB) que utilizaremos para crear el filesystem distribuido.

 

 

CPD1.jpg

 

Figura 7.2: El CPD de UPC en el edificio Omega

 

 

El nuevo cluster estará ubicado en el CPD de UPC (Edificio Omega en el Campus Nord), donde se encuentran todos los servidores del Departamento de LSI. Por cuestiones de limitación de espacio llegamos a un acuerdo con los responsables de los clusters para liberar espacio retirando las máquinas más obsoletas. Se retiran máquinas Pentium IV con chasis de 2U, que además son poco eficientes desde el punto de vista energético.

 

Los nodos de entrada de los tres clusters antiguos también se retiraron. Se trata de máquinas  menos potentes  ya que, por la naturaleza descentralizada de openMosix, su única función era proveer acceso a la red del cluster.

 

Además se llega al acuerdo con los distintos grupos de investigación de comprar dos máquinas que correrán los servicios principales  del cluster, que proporcionarán alta disponibilidad y servirán como punto de entrada al cluster. Ambos servidores son idénticos, y cuentan con las siguientes características:

 

  • Dell PowerEdge R200
  • Procesador Intel Xeon E3110 a 3 Ghz, 6 MB de cache
  • 8 GB de memoria RAM
  • 2 tarjetas de red gigabyte Ethernet
  • 2 discos SAS de 450 GB
  • Chasis enrackable de 1U

 

Todos los nodos cuentan con sistema operativo Linux Debian. La elección de esta distribución viene dada por ser el sistema operativo utilizado en todos los servidores y estaciones de trabajo Linux del Departamento de LSI. Debian es una distribución con gran tradición dentro del mundo Linux, estable, con un repositorio de software importante y muy enfocado hacia el segmento de los servidores. Concretamente se ha escogido la versión Etch por ser la versión estable en el momento de desarrollar este proyecto.

 

La instalación del sistema operativo es igual en todas las máquinas, con la única diferencia de los servicios que ejecutan, que se personalizan mediante scripts creados a tal efecto.

 

Siempre que ha sido posible se ha instalado el software vía el repositorio oficial de Debian. El listado completo de los paquetes instalados puede encontrarse en los apéndices [19.1.34].

7.3.2. Sistema de pruebas

 

A excepción de las máquinas compradas más recientemente, que no pueden correr openMosix, el resto del hardware pertenece a alguno de los tres clusters existentes. Así pues, para hacer las pruebas de los distintos subsistemas del nuevo cluster crearemos una réplica a escala de lo que será el futuro cluster. El diseño modular nos permitirá abstraernos del número y tipo de máquinas instaladas.

 

El cluster de pruebas está formado por:

 

  • 16 nodos Dell con procesadores Intel Xeon de doble o cuádrule núcleo y 4 u 8 GB de memoria RAM.
  • 1 switch 3Com gigabit de 16 puertos
  • 1 multiplexador de puertos KVM

 

7.3.3. Software de clustering

 

Como sistema de gestión para el nuevo cluster hemos elegido Sun Grid Engine, que es quizás el sistema de colas más utilizado, tanto en ámbitos empresariales como en centros de investigación.

 

Se trata de un producto estable, maduro, con gran tradición dentro del ámbito de la supercomputación y que cuenta con una numerosísima comunidad de usuarios y administradores. Se trata, en fin, de uno de los proyectos de clustering más vivos que además es de código abierto.

7.3.4. Sistema de ficheros

 

Nuestra primera opción como filesystem fue Lustre, de SunMicrosystems. Se trata del sistema de ficheros distribuido paralelo más potente y escalable disponible y se adapta perfectamente a entornos de clustering. Como veremos, las peculiaridades y limitaciones de nuestro hardware harán que el filesystem no rinda como se esperaba y nos veremos obligados a revisar nuestra elección. El overhead del sistema software de sincronización de discos castiga el rendimiento en exceso, motivo por el que desechamos Lustre en nuestra solución. Más adelante se explica con detenimiento los problemas que nos encontramos.

 

La segunda opción fue GlusterFS, un filesystem más modesto, no tan escalable pero que en entornos medianos como el nuestro, y con hardware no tan dedicado, puede dar un rendimiento adecuado.

7.3.5. Alta disponibilidad

 

Como software de alta disponibilidad elegimos Heartbeat, que forma parte del proyecto Linux-HA y que es el sistema de alta disponibilidad más extendido en el mundo Linux.

 

Se trata de un sistema de monitorización sencillo capaz de comprobar el status de dos hosts unidos por una conexión dedicada. Su funcionamiento es simple: si la conexión de uno de los hosts se interrumpe, el host que queda en funcionamiento toma el control de los servicios que han caído.

 

Este mecanismo de monitorización nos proporcionará alta disponibilidad de los servicios de clustering y de sistema de ficheros, protegiéndonos ante el fallo de uno de los nodos master o de cualquiera de los nodos servidores de disco.

7.3.6. Sistema de imágenes

 

Desde que pusimos en marcha el primer cluster, vimos que era necesario disponer de un sistema de replicación de imágenes de sistema que permitiese automatizar la gestión del software de las máquinas del cluster. Instalar un nodo manualmente es un proceso tedioso que consume un tiempo, instalar N nodos de esta forma no es práctico. La elección en su día fue Rembo. Se trata de un software que permite una gran personalización de las imágenes gracias a su sistema de scripts y con un amplio soporte de tarjetas ethernet. Además contamos con licencia de campus UPC.

 

En 2006 IBM adquirió Rembo, incorporándolo dentro de su suite Tivoli. Dadas las buenas experiencias obtenidas con Rembo nos decidimos a utilizar Tivoli, que también cuenta con licencia UPC.

7.3.7. Sistema de Monitorización

 

El interés de monitorización es doble. Por una parte queremos un sistema que nos informe del estatus del cluster y que sea capaz de aglutinar toda la información generada por la gran cantidad de elementos que lo conforman. La información mostrada debe adaptarse tanto a las necesidades de los administradores del sistema como a los usuarios. En este sentido ganglia proporciona un interfaz web perfectamente adaptado a la idiosincrasia de los clusters, y que con algunas modificaciones se adapta perfectamente a nuestra infraestructura.

 

Por otra parte, como administradores de sistemas, necesitamos saber el estatus de los componentes del cluster. De poco sirve tener un sistema de alta disponibilidad con dos hosts si al caer uno de ellos no somos informados. En el Laboratorio de Cálculo todos los servicios críticos se monitorizan con el sistema operativo (so), así que lo que haremos será incluir los servicios del cluster dentro del sistema de monitorización nagios de LCLSI.

7.3.8. Servicios auxiliares

 

Además de los componentes propios del cluster, son necesarios una serie de servicios complementarios para el correcto funcionamiento del sistema. Servicios como:

 

·        Servicio de nombres, que se encarga de la correspondencia entre las direcciones IPs de los nodos y sus nombres.

 

·        Servicio de correo, que permite la gestión de los emails administrativos generados por los nodos de computación dentro de SunGrid.

 

·        Servicio de tiempo. Configuraremos nuestro propio servidor de tiempo que mantendrá la hora de todos los nodos sincronizada.

 

·        Servicio de backup. Incorporamos el espacio de disco compartido del cluster al sistema de backups departamentales.

 


8. Implementación

 

 

Una vez diseñado el nuevo sistema, describiremos la implementación del diseño propuesto.

 

Primero nos centraremos en el proceso de instalación y configuración de cada uno de los servicios que conformarán el Cluster:

 

·        Lustre o GlusterFS como sistema de ficheros.

·        SunGrid como sistema de clustering.

·        Heratbeat como sistema de alta disponibilidad.

·        Tivoli como sistema de replicación de imágenes.

·        Ganglia y Nagios como sistemas de monitorización.

·        Otros servicios (DHCP, correo, tiempo, etc).

 

Cabe notar que tanto en la instalación como en la configuración de cada uno de estos componentes seguiremos una serie de reglas:

 

·        Siempre que sea posible utilizaremos el software proporcionado por el sistema operativo, lo que nos permitirá mantener el software actualizado fácilmente.

 

·        Todo el software adicional común se instalará en un directorio dentro de /usr/local, accesible en cada nodo para todos los usuarios.

 

·        Los distintos componentes del cluster se instalarán de forma independiente y lo más aislados posibles del resto del sistema operativo. Esto nos permitirá actuar en cada uno de ellos sin afectar al resto.

 

·        Se tratará de independizar el cluster, en la medida de lo posible, del resto de servicios del Departamento, lo que nos proporcionará una robustez añadida.

 


9. Lustre

 

9.1. Arquitectura propuesta (versión 1.0)

 

Uno de los objetivos del nuevo cluster es proporcionar  a los usuarios un espacio de disco unificado, solucionando el problema de zonas de usuario fragmentadas en el modelo de los clusters anteriores. En este volumen único, que será visible desde todos los nodos del cluster, los usuarios guardarán sus programas, datos, salidas de procesos, etc.

 

Todas las máquinas del cluster cuentan con un espacio de disco libre que va desde los 60 GB en las máquinas más antiguas con discos de 80 GB hasta más de 700 GB en las máquinas más modernas. El espacio total resultante de sumar todos estos volúmenes da como resultado una cantidad de disco considerable.

 

Lustre como sistema de ficheros paralelo permite crear un volumen unificado a partir de diferentes espacios de disco heterogéneo accesible por conexiones TCP/IP. Estos espacios de disco pueden ser NAS, SAN o, como en nuestro caso, hosts con discos locales.

 

Un sistema Lustre cuenta con tres unidades funcionales principales:

 

1.      Un metadata target (MDT) por filesystem que almacena metadatos, como nombres de ficheros, directorios, permisos y file layout en el metadata server (MDS).

 

2.      Uno o más object store targets (OSTs) que guardan los datos de los ficheros en uno o más object storage servers (OSSs). Dependiendo del hardware de los servidores, un OSS normalmente sirve entre dos y ocho targets, con cada target un sistema de ficheros en disco local con hasta 8 terabytyes de tamaño. La capacidad de un sistema Lustre es la suma de las capacidades de los targets.

 

3.      Cliente(s) que acceden y usan los datos.

 

MDT, OST y cliente pueden estar en distintos nodos o en el mismo. En general estas funciones se separan en nodos distintos, de dos a cuatro OSTs por nodo OSS. Lustre soporta varios tipos de redes, incluyendo Infiniband, TCP/IP en ethernet, Myrinet, Quadrics y otras tecnologías propietarias.

 

El MDT y los OSTs pueden contar con un nodo configurado como failover que es capaz de acceder a sus datos en caso de que el nodo servidor falle.

 

La figura [4.2] en el apartado [4.3.2] muestra el esquema de un cluster Lustre complejo, con diversos OSSs con OSTs albergados en SANs, sistemas de failover, etc.

 

La alta disponibilidad es uno de los objetivos que nos hemos marcado a la hora de diseñar el nuevo espacio de disco. Aprovechando las facilidades que proporciona Lustre, dotaremos de alta disponibilidad tanto al MDT como a los distintos OSTs. En nuestro caso esto implica tener dos hosts sirviendo el MDT y otros dos por cada OST. El segundo host, configurado como failover, debe ver el mismo disco que el host primario para ser capaz, en caso de fallo de éste, de tomar el control y continuar sirviendo disco.

 

Lo más habitual en sistemas de alto rendimiento es disponer de un SAN (Storage Area Network) conectado a dos hosts. El SAN en estos casos cuenta con varias controladoras que permiten su conexión a distintos hosts. Los hosts se configuran como primary y failover. El nodo primary es el que sirve el disco a la zona Lustre. En caso de caída del nodo primary, Lustre se dará cuenta y automáticamente comenzará a utilizar el nodo failover.

 

En nuestro caso utilizaremos los discos locales de las máquinas como espacio de disco compartido. Agruparemos las máquinas del cluster  por parejas. Habrá una pareja que sirva el MDT y el resto de parejas servirán OSTs. La Suma del espacio de los OSTs dará como resultado el espacio total del disco. Las máquinas que conforman una pareja deben contar con discos del mismo tamaño.

 

drbd-sepinterface

Figura 9.1: Esquema de dos hosts con replicación de datos vía conexión de red dedicada

 

 

Cada uno de los hosts tienen acceso solamente a su disco local, y Lustre sólo "habla" con el host que actúa como primario. Es necesario algún mecanismo adicional que replique los datos que se escriben en el host primario al failover. Es más, esos datos deben mantenerse estrictamente sincronizados para evitar problemas de incoherencia de datos. En este sentido DRBD (Distributed Replicated Block Device) nos proporciona un mecanismo transparente de replicación de bloques entre dispositivos, particiones de discos duros en este caso, que se encuentran en hosts conectados por red. Algunas características de DRBD son:

           

·        Trabaja en tiempo real. La replicación de datos es continua, mientras las aplicaciones modifican el contenido del dispositivo.

 

·        Es transparente. Las aplicaciones que trabajan en el dispositivo replicado no son conscientes de que los datos están en varios servidores.

 

·        La replicación puede ser síncrona o asíncona.  Trabajando de forma síncrona, las escrituras por parte de aplicaciones se consideran finalizadas sólo cuando la escritura se ha realizado en los dos servidores que conforman el dispositivo replicado. La replicación asíncrona implica que las escrituras se consideran finalizadas cuando se han completado de forma local, antes de que se hayan propagado al peer.

 

Dos hosts compartiendo un dispositivo de bloques DRBD juegan roles primary y secondary. El host primary  es el host que monta el dispositivo DRBD y es sobre su disco físico local sobre el que se realizan las lecturas. Las escrituras se realizan en primer lugar en el disco del host primary y posteriormente en el host secondary. En nuestro caso configuraremos DRBD en modo síncrono, de tal forma que una escritura no se considerará realizada hasta que no se haya realizado en los discos de los hosts primary y secondary.

 

Los roles primary y secondary se corresponden con los roles primary y failover de Lustre.

 

 

Figura 9.2: Arquitectura del cluster con Lustre (versión 1.0)

 

 

La replicación de datos entre parejas de hosts se realizará utilizando una conexión de red dedicada, tal y como se muestra en la figura [9.2]. Todos los nodos del cluster cuentan con al menos 2 interfaces de red gigabit ethernet. La interconexión de los hosts de cada pareja mediante una conexión de este tipo permite que la sincronización de datos se realice de forma óptima, sin ocupar el ancho de banda de la red privada del cluster.

 

Como hemos comentado anteriormente, Lustre es capaz de detectar el fallo de un servidor, ya sea de un MDT o de un OST, y utilizar en su lugar un host configurado como failover. En el caso por ejemplo de un OST formado por dos hosts en configuración failover sirviendo el disco de un SAN, si fallase el host primary, el host failover tendría acceso de forma "automática" al SAN y Lustre pasaría a comunicarse con él. En nuestro caso, con las zonas replicadas con DRBD, necesitamos un mecanismo extra que nos permita detectar el fallo del host primary y que, en caso de fallo, configure el host seconday como primary y monte la zona DRBD. Heartbeat, tratado en el capítulo [12], permite monitorizar el estatus de servicios de alta disponibilidad y ejecutar scripts que los activen/desactiven.

 

9.2. Instalación (versión 1.0)

9.2.1.  DRBD

 

La funcionalidad principal de DRBD está implementada como módulo del kernel. Concretamente, DRBD proporciona un driver para un dispositivo de bloques especial.

La última versión disponible es la 8.2.6, que podemos descargar de la url:

 

http://oss.linbit.com/drbd/8.2/drbd-8.2.6.tar.gz

 

Como con todo el software que instalamos y que no viene con la distribución de software del sistema operativo, dejamos copia en /root/files.

Compilamos e instalamos el software:

 

master-cluster1> tar xvfz drbd-8.2.6.tar.gz

master-cluster1> cd drbd-8.2.6/drbd

master-cluster1> make && make install

 

El módulo de kernel queda instalado en el directorio correspondiente a dispositivos de bloques en /lib/modules y las utilidades de administración en /sbin.

 

Comprobamos que el módulo carga correctamente:

 

master-cluster1> modprobe drbd

 

El siguiente mensaje indica que el módulo se ha cargado:

 

drbd: initialised. Version: 8.2.6 (api:88/proto:86-88)

 

Para automatizar el proceso de carga del módulo drbd al iniciar el sistema, lo incluimos en el fichero /etc/modules.

 

 

 

9.2.2. Lustre

 

Lustre está dividido en tres partes:

 

  1. Parches de kernel
  2. Módulo de kernel
  3. Utilidades de espacio de usuario

 

El primer paso es disponer de un kernel con los parches necesarios para Lustre. Sun nos ofrece la posibilidad de instalar alguno de sus kernels precompilados o  modificar nuestro kernel con sus parches. En nuestro caso preferimos adecuar nuestro kernel3 (2.6.18-5) a Lustre en lugar de instalar un nuevo kernel, la cual  cosa nos dará más juego en caso de tener que realizar futuros ajustes en el mismo.

 

El software necesario está disponible en la web de Sun:

 

https://cds.sun.com/is-bin/INTERSHOP.enfinity/WFS/CDS-CDS_SMI-Site/en_US/-/USD/ViewProductDetail-Start?ProductRef=LUSTRE-1651-G-F@CDS-CDS_SMI

 

Como queremos parchear nuestro propio kernel, seleccionamos la plataforma Source y descargamos el fichero "Lustre source code - lustre-1.6.5.1.tar.gz".

 

Descomprimimos el código fuente de Lustre:

 

master-cluster1> tar xvfz lustre-1.6.5.1.tar.gz -C /tmp

 

Los parches Lustre se instalan con la herramienta de gestión de parches quilt. La instalamos:

 

master-cluster1> apt-get install quilt

 

Copiamos el fichero con la configuración del kernel[5] (versión 2.6.18) en nuestra estructura de kernel:

 

master-cluster1> cp lustre/kernel_patches/kernel_configs/kernel-2.6.18-2.6-vanilla-i686.config /usr/src/linux/

 

Creamos sendos soft-links que utilizará quilt para parchear nuestro kernel:

 

master-cluster1> cd /usr/src/linux

master-cluster1> ln -s /tmp/lustre-

1.6.5.1/lustre/kernel_patches/series/2.6.18-vanilla.series series

master-cluster1> ln -s /tmp/lustre-1.6.5.1/lustre/kernel_patches/patches patches

 

Ahora aplicamos los parches indicados en el fichero series:

 

master-cluster1> quilt push -av

 

Una vez aplicados los parches debemos recompilar el kernel:

 

master-cluster1> make && make modules_install

 

Generamos el ramdisk del kernel que acabamos de compilar:

 

master-cluster1> mkinitramfs -o /boot/linux-2.6.18-lustre-1.6.5.1

 

Por último hacemos este sea el kernel de arranque por defecto. Añadimos una nueva entrada en el gestor de arranque GRUB. El fichero de configuración /boot/grub/menu.lst puede encontrarse en los apéndices [19.1.1].

 

Rebotamos la máquina y comprobamos que el nuevo kernel se carga correctamente y que todos los dispositivos se reconocen.

 

El siguiente paso es compilar el módulo Lustre y las utilidades de gestión:

 

master-cluster1> cd/tmp/lustre-1.6.5.1

master-cluster1> ./configure --prefix=/

master-cluster1> make && make install

 

Para hacer que el módulo Lustre se cargue automáticamente, creamos un fichero lustre en /etc/modutils con el fin de que la herramienta update-modules cree la información necesaria en /etc/modules.conf:

 

options lnet networks="tcp"

options ost oss_num_threads=4

options mds mds_num_threads=10

 

En este fichero debemos indicar el tipo de red que utilizará lnet para comunicar los hosts Lustre:

 

options lnet networks="tcp"

 

Para comprobar que el fichero modules.conf incluye correctamente la información de los módulos Lustre ejecutamos el comando update-modules, que se ejecuta cada vez que se inicia el sistema:

 

master-cluster1> update-modules.modutils

 

9.3. Configuración (versión 1.0)

9.3.1. Consideraciones previas

 

Una vez instalado el módulo de kernel y las utilidades, debemos configurar el recurso DRBD. En primer lugar, debemos asegurarnos de que la replicación se realizará sobre dispositivos de idéntico tamaño. El sistema de distribución de imágenes Tivoli junto con el script de personalización de imagen nos asegura contar con parejas de nodos con una partición home del mismo tamaño (ver capítulo [13]).

 

También contamos con un interfaz de red dedicado a la sincronización de datos del dispositivo DRBD. El script de personalización de sistema se encarga de configurar este interfaz en cada máquina asignándole la dirección IP correspondiente según juegue el rol primary o secondary.

9.3.2. DRBD

 

La configuración de DRBD reside en /etc/drbd.conf. Este fichero cuenta con varias secciones a configurar: global, common y resources, en las que se definen los recursos a replicar. Este fichero puede encontrarse en los apéndices [19.1.2].

 

En la sección resource definimos un recurso denominado r0 que está formado por la partición RAID1 /dev/md2 de los nodos 1 y 2. La comunicación entre los nodos se establece por el interfaz dedicado y el puerto especificado.

 

Tras configurar el recurso correctamente, procedemos a crear e inicializar el dispositivo drbd. Para ello, debemos seguir los siguientes pasos en todos los nodos:

 

1.      Creamos el dispositivo:

 

nodei> drbdadm create-md r0

 

2.      Asociamos el recurso DRBD con su dispositivo físico:

 

nodei> drbdadm attach r0

 

3.      Conectamos el recurso DRBD con su compañero:

 

nodei> drbdadm connect r0

 

Comprobamos en /proc/drbd el estatus del recurso r0:

 

nodei> cat /proc/drbd

version: 8.2.4 (api:88/proto:86-88)GIT-hash: fc00c6e00a1b6039bfcebe37afa3e7e28dbd92fa build by buildsystem@linbit, 2008-01-11 12:44:36

 0: cs:Connected st:Secondary/Secondary ds:Inconsistent/Inconsistent C r---

    ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0

        resync: used:0/31 hits:0 misses:0 starving:0 dirty:0 changed:0

        act_log: used:0/257 hits:0 misses:0 starving:0 dirty:0 changed:0

 

Como vemos en los logs ambos dispositivos del recuso están configurados como secondary. El siguiente paso establece el nodo que jugará el rol de primary en la pareja DRBD e inicia la sincronización entre ellos. Debe ejecutarse sólamente en los nodos primary:

 

nodei> dbdadm -- --overwrite-data-of-peer primary r0

 

 

Tras ejecutar este comando comienza la sincronización, que puede ser monitorizada vía /proc/drbd:

 

nodei> cat /proc/drbd

version: 8.2.6 (api:88/proto:86-88)

GIT-hash: 3e69822d3bb4920a8c1bfdf7d647169eba7d2eb4 build by root@master-cluster1, 2008-10-01 10:56:55

 1: cs:Connected st:Primary/Secondary ds:UpToDate/UpToDate C r---

ns:14596512 nr:0 dw:14351652 dr:887881 al:59 bm:39 lo:0 pe:0 ua:0 ap:0 oos:0

 

Después de ejecutar este comando el dispositivo drbd ya es completamente funcional, eso sí, con un rendimiento reducido mientras dura la sincronización. El siguiente paso es formatear el dispositivo para crear el filesystem; en nuestro caso Lustre.

9.3.3. Lustre

 

Debido al requisito de alta disponibilidad en todos los puntos del filesystem, el MDT estará formado por dos MDS, master-cluster1 y master-cluster2.

 

En primer lugar formateamos el MDT desde el MDS activo (master-cluster1):

 

master-cluster1> mkfs.lustre --fsname=lustrefs --mdt --mgs --failnode=master-cluster2 /dev/drbd0

 

Una vez la zona está formateada, montamos la zona MDT:

 

mastercluster1> mount -t lustre /dev/drbd0 /mnt/lustrefs/mdt

 

Para cada uno de los 7 OSTs procedemos de forma análoga. En primer lugar formateamos el dispositivo DRBD de los nodos primary (node1, node3, node5 y node7) y posteriormente montaremos la zona:

 

nodei> mkfs.lustre --fsname=lustrefs --mgsnode=master-cluster1,master-cluster2 --ost --failnode=node2 /dev/drbd0

nodei> mount -t lustre /dev/drbd0 /mnt/lustrefs/ost

 

Cada vez que se monta un nuevo OST, el MDT lo reconoce como propio (mismo fsname) y lo agrega al filesystem. Desde el momento que formateamos el primer OST estamos en disposición de montar la zona lustre en los nodos cliente.

 

9.4. Pruebas (versión 1.0)

 

Una vez nuestro filesystem paralelo es funcional, procedemos a realizar las pruebas pertinentes, tal y como está descritas en el apartado [19.3].


9.4.1. Test de estabilidad

 

Durante la fase de pruebas del filesystem nos encontramos con importantes problemas de estabilidad que provocaban la pérdida del control sobre el filesystem, obligando a reiniciar los servicios Lustre, y en ocasiones la totalidad del sistema a las 24 horas aproximadamente de funcionamiento intensivo.

 

Los problemas eran fácilmente reproducibles mediante el acceso concurrente de lectura y escritura a los datos por parte de varias decenas de procesos. Iniciada la situación de estrés era cuestión de horas que el filesystem se quedase inestable.

 

Probamos varias versiones de kernel y de utilidades Lustre, pero el problema persistía. Finalmente, tras consultar extensivamente los foros oficiales, encontramos un artículo sobre Lustre que indicaba que la combinación servidor OST y cliente en un mismo nodo no es una configuración estable. Los nodos cliente, que montan el filesystem, no pueden realizar funciones de OSS.

 

Esto nos hizo  replantearnos la arquitectura de nuestro sistema de pruebas, puesto que la estabilidad es un requisito fundamental.

 

Por otra parte como pudimos comprobar, el hecho de disponer los nodos de computación como máquinas servidoras de disco Lustre, añade un overhead de uso de CPU, memoria y red que perjudicaría el rendimiento del trabajo de los usuarios en un entorno de computación.

 

9.5. Revisión de la arquitectura (versión 1.1)

 

Los graves problemas de estabilidad descritos en el apartado anterior nos obligan a replantearnos la arquitectura de nuestro filesystem paralelo. Los nodos servidores de disco deben ser nodos dedicados.

 

A tal efecto configuramos seis máquinas provenientes del antiguo cluster eixam que iban a ser retiradas. Se trata de máquinas con unos 5 años de antigüedad, con prestaciones a nivel de cómputo muy inferiores a las últimas adquiridas, pero que pueden jugar un papel correcto como servidoras de disco.

 

Las seis máquinas son idénticas y cuentan con las siguientes características:

 

·        Procesador: Intel Pentium IV 3.0 Ghz

·        Memoria: 4 GB RAM

·        Disco: 2 discos SATA de 750 GBytes

·        Red: 2 tarjetas de red gigabyte Ethernet

·        Chasis: Enracable 2U

 

Así pues todos los nodos con los que contábamos anteriormente dejan de servir disco y pasan a ser exclusivamente clientes de la zona de disco paralela formada por las 6 máquinas dedicadas.

 

El nuevo modelo se muestra en la figura [9.3].

 

 

 

Figura 9.3: Arquitectura revisada del cluster con Lustre  (versión 1.1)

 

9.6. Pruebas del nuevo modelo (versión 1.1)

9.6.1. Test de estabilidad

 

Una vez separados los nodos servidores de disco de los nodos cliente, los problemas de estabilidad desaparecieron. El nuevo modelo se mostró estable ejecutando el test de estrés por periodos de tiempo de una semana. De esta forma pudimos centrarnos en las pruebas de rendimiento y usabilidad.

9.6.2. Pruebas de rendimiento

 

Las pruebas de rendimiento se basaron, por una parte, en una serie de tests sintéticos de rendimiento teórico, que nos proporcionaría el rendimiento pico máximo. Por otra parte realizamos pruebas de estrés basadas en la ejecución masiva de procesos con lecturas y escrituras concurrentes. Los detalles de las distintas pruebas de rendimiento se explican en el apartado [19.3.2].

 

9.6.2.1. Throughput máximo

 

En primer lugar mostramos el throughput máximo arrojado por la pruebas de lecturas y escrituras sobre el filesystem Lustre:

 

 

Número de instancias

MB/s en lectura

MB/s en escritura

1

45.5

18.7

2

90.3

36.1

3

135.1

54.2

4

133.0

49.5

5

129.2

46.4

 

 

Como era de esperar las pruebas de rendimiento con Lustre arrojan resultados muy buenos, superando a partir de 2 instancias concurrentes el rendimiento de un disco local. El througput escala linealmente con el número de OSTs. Dado que disponemos de 3 OSTs las lecturas y escrituras se realizan en 3 nodos (parejas de nodos) en paralelo.

 

 

Lecturas

 

 

 

Escrituras

 

Figura 9.4: Throughput de lectura y escritura del filesystem Lustre

 

 

Podemos estimar que el máximo throughput teórico sería la velocidad de  un OST multiplicado por el número de OSTs, que en nuestro caso serían 135.5 MB/s para las lecturas y 56.1 MB/s para las escrituras. Como podemos ver, los resultados con distintas concurrencias se aproximan a los máximos teóricos, confirmando la excelente escalabilidad de Lustre.

 

Las escrituras están penalizadas, sin duda alguna, por el sistema de replicación utilizado. Recordemos que los datos escritos en un OST se envían al nodo primary y éste los reenvía a su vez al nodo secondary de forma síncrona mediante DRBD. De todas formas las tasas de escritura son más que correctas y superan con creces las que puede ofrecer un sistema tipo NFS.

 

9.6.2.2. Test ad-hoc

 

El siguiente test consiste en la ejecución concurrente de procesos con un alto uso de E/S. La descripción de la batería de pruebas puede consultarse en los apéndices [19.3.2.2].

 

A continuación mostramos los resultados obtenidos correspondientes a ejecutar un determinado número de procesos de lectura:

 

 

Concurrencia

Tiempo

Throughput agregado (MB/s)

MB/s por proceso

1

47.0’’

104.5

104.5

2

47.6”

206.4

103.2

3

48.5”

303.9

101.3

6

1’ 38”

300.0

50.0

9

2’ 32”

292.5

32.5

18

5’ 37”

264.3

14.6

36

12’ 14”

215.2

5.9

 

 

Las cifras de throughput agregado demuestran la alta escalabilidad del filesystem Lustre. Dado que contamos con 3 OSTs el rendimiento máximo esperado seria de 104.5 * 3 = 313.5 MB/s. Cuando la concurencia aumenta  las cifras de throughput agregado se siguen manteniendo bastante estables.

 

 

Throughput agregado

 

 

 

Throughput por proceso

 

Figura 9.5: Throughput del filesystem Lustre en lecturas

 

 

Las pruebas de escritura arrojan los siguientes resultados:

 

 

Concurrencia

Tiempo

Throughput agregado (MB/s)

MB/s por proceso

1

3’ 11’’

19.0

19.0

2

4’ 25”

37.3

18.6

3

4’ 30”

54.7

18.2

6

6’ 12’’

52.3

8.71

9

14’ 19”

51.5

5.72

18

29’ 40’’

49.7

2.76

36

1h 3’

46.8

1.3

 

 

De nuevo tenemos resultados muy estables a lo largo de todas las pruebas. El throughput agregado se mantiene estable cerca del máximo teórico, limitado por el sistema de replicación DRBD.

 

 

Throughput agregado

 

 

 

Throughput por proceso

 

Figura 9.6: Throughput del filesystem Lustre en escrituras

 

9.6.3. Pruebas de usabilidad

 

Por último las pruebas de usabilidad sirvieron para medir el grado de interactividad de los usuarios con la zona de disco compartido mientras el sistema estaba sometido a distintos niveles de carga de trabajo.

 

El uso conjunto del sistema de replicación de bloques DRBD y Lustre hacen crecer el tiempo de proceso y la latencia de ciertas llamadas al sistema sobre ficheros a niveles no asumibles.

 

Concretamente, un sistema como el nuestro sometido a una carga de 36 procesos simultáneos leyendo y escribiendo, tarda del orden de 10 segundos en procesar el comando ls sobre la zona compartida y entre 10 y 20 segundos en hacer un close de un fichero.

 

Esta falta de interactividad nos lleva a desechar la solución Lustre+DRBD. De todas maneras, en caso de incorporar algún día un SAN al cluster, liberados de la necesidad de utilizar DRBD, volveríamos a evaluar la posibilidad de utilizar Lustre como filesystem. Esta mejora se ha planteado en el apartado [18.3.3].

 

 


10. GlusterFS

 

10.1. Arquitectura propuesta (versión 2.0)

 

Los problemas de rendimiento de la solución Lustre + DRBD nos obligaron a revisar nuestra elección de filesystem. Tras analizar varias opciones nos decantamos por GlusterFS, por tratarse de un sistema de ficheros paralelo con una característica muy interesante: AFR (Automatic File Replication). Así como Lustre es un filesystem de un rendimiento y una escalabilidad de primer nivel, la inclusión del sistema de replicación de bloques DRBD hacía que el filesystem en su conjunto adoleciese de latencias altas en escenarios de estrés de disco y en operaciones de apertura/cierre de fichero.

 

 

Figura 10.1: Arquitectura del cluster con GlusterFS (versión 2.0)

 

 

AFR es un translator que permite que un brick[6] o unidad de almacenamiento esté compuesto por más de un disco (en hosts distintos, por supuesto). La replicación de datos se hace de forma transparente, iniciada por los nodos clientes, que configurando volúmenes AFR, indican de forma explícita sobre qué nodos se va a realizar la replicación de datos.

 

Los datos se escriben a la vez en los dos nodos que conforman un AFR, al contrario de lo que sucedía con DRBD, donde los datos se enviaban al nodo primario y este los reenviaba al secundario.

 

GlusterFS tiene la misma limitación que Lustre en cuanto a montar el filesystem en un host servidor de disco. Los problemas de estabilidad nos llevan a decantarnos una vez más por una solución con nodos dedicados a servir disco, similar al modelo de cluster versión 1.1.

 

Con este fin, al igual que en la revisión del sistema Lustre, contamos con 6 máquinas dedicadas en exclusiva a servir disco. La figura [10.1] muestra el esquema del cluster con GlusterFS (versión 2.0).

 

Además de las máquinas servidoras de disco, GlustrerFS necesita una máquina que se encargue de almacenar el namespace del filesystem. Guardaremos el namespace en las máquinas master-cluster, replicado utilizando AFR.

 

Las máquinas servidoras de disco se agruparán por parejas, replicando por AFR la zona de disco que exportan. Los nodos clientes configurarán el filesystem global unificando el sumatorio de las tres zonas AFR y utilizando el namespace del AFR de las máquinas master-cluster.

 

10.2. Instalación (versión 2.0)

 

Obtenemos la última versión[7] de GlusterFS de su web:

 

http://ftp.zresearch.com/pub/gluster/glusterfs/CURRENT/

 

Descomprimimos y compilamos el código fuente:

 

master-cluster1> tar xfz glusterfs-1.3.9.tar.gz -C /tmp

 

master-cluster1> cd /tmp

 

master-cluster1> ./configure --prefix=/

 

master-cluster1> make && make install

 

Las utilidades quedan instaladas en /sbin, los ficheros de configuración en /etc y los logs en /var/log/glusterfs.

 

GlusterFS utiliza FUSE (Filesystem in Userspace) para montar las zonas, por lo que es necesario contar con soporte en el kernel. La configuración por defecto de Debian soporta FUSE, por lo que no son necesarias instalaciones adicionales.

10.3. Configuración (versión 2.0)

10.3.1 Servidores

 

Cada uno de los seis nodos servidores de disco cuenta con dos discos de 750 GB, que tras instalar sistema y swap nos dejan una partición  exportable de unos 700GB. Lo habitual en nuestros servidores es utilizar una configuración RAID1 que permita el fallo de un disco sin pérdida de datos. En el caso del sistema GlusterFS con AFR los datos de cada nodo ya están replicados en su peer, por lo que optamos por una configuración RAID0[8]. De esta manera no se pierde espacio y el acceso al volumen resultante es más rápido.

 

Creamos el raid en cada nodo servidor:

 

node1> mdadm --create /dev/md2 --level=0 --raid-devices=2 /dev/sda3 /dev/sdb3

 

Comprobamos que el raid se ha creado correctamente:

 

node1> cat /proc/mdstat

Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]

md2 : active raid0 sda3[1] sdb3[0]

1417045248 blocks 64k chunks

 

El siguiente paso es formatear y montar la partición que exportaremos:

 

node1> mke2fs -j /dev/md2

node1> mount /dev/md2 /mnt/glusterfs/home

 

Una vez disponemos de la zona de disco que queremos exportar, configuramos el lado servidor de GlusterFS, que será idéntico en todos los nodos servidores de disco. La estructura del fichero de configuración es la siguiente:

 

Recurso a exportar

Translator 1

Translator 2

Translator n

Definición del volumen servidor

 

El fichero de configuración de los nodos servidores de GlusterFS se puede encontrar en los apéndices [19.1.3].

 

La primera declaración en el fichero de configuración indica sobre qué directorio vamos a trabajar. Las siguientes declaraciones son distintos translators[9] que aportan soporte para bloqueo de ficheros (posix-locks) e introducen mejoras de rendimiento (iothreads, wb, ra). La declaración server indica qué zona se va a exportar, el transporte utilizado y las restricciones de acceso.

 

Por último sólo queda lanzar el demonio GlusterFS con la configuración que hemos creado:

 

node1> /sbin/glusterfsd -f /etc/glusterfs/glusterfs-server.vol

10.3.2. Namespace

 

A continuación guardaremos el namespace de la zona de usuario GlusterFS en los dos nodos master. Ambos nodos contarán con una partición idéntica en la que, por AFR, se replicará el namespace.

 

Los nodos master cuentan con dos discos de 500GB. Creamos una partición de 200 GB[10] en cada uno de los discos para, posteriormente crear un volumen RAID0 en las dos máquinas master:

 

master-cluster1> mdadm --create /dev/md2 --level=0 --raid-devices=2 /dev/sda3 /dev/sdb3

 

Formateamos y montamos el dispositivo, utilizando ext3 por ser un filesystem con journaling y ampliamente soportado por herramientas de recuperación de datos.

 

master-cluster1> mke2fs -j /dev/md2

master-cluster1> mount /dev/md2 /mnt/glusterfs/home-ns

 

Configuramos el servidor GlusterFS en los nodos master-cluster. La configuración será idéntica en los dos nodos:

 

volume brick-ns

type storage/posix

option directory /mnt/glusterfs/home-ns

end-volume

 

volume server

type protocol/server

subvolumes brick-ns

option transport-type tcp/server

option auth.ip.brick-ns.allow *

end-volume

 

Arrancamos el servidor GlusterFS en los dos nodos master-cluster:

 

master-cluster1> /sbin/glusterfsd -f /etc/glusterfs/glusterfs-server.vol

 

Después de estos pasos ya tenemos el lado servidor de la zona GlusterFS configurado.

10.3.3. Clientes

 

En un sistema GlusterFS los servidores exportan recursos, ya sea zonas de disco o namespace, sin saber el destino que se les va a dar o qué exportan el resto de servidores. La comunicación inter-servidor no existe. Son los clientes los que agregan  los recursos que exportan los servidores para crear volúmenes grandes.

 

En nuestro caso la configuración de todos los nodos clientes será idéntica. Se creará un volumen formado por tres AFRs, que serán parejas de nodos servidores: disc1+disc2, disc3+disc4 y disc5+disc6. El namespace será el AFR formado por la zona exportada por master-cluster1+master-cluster2.

 

El fichero de configuración de los nodos clientes puede consultarse en los apéndices [19.1.4].

 

En primer lugar describimos todos los recursos que vamos a utilizar, definidos como client0-ns y client1-ns (namespaces) y client1,..,client6 (servidores de disco). Posteriormente definimos los volúmenes AFRs y su composición. Finalmente creamos un volumen que unifica los tres AFRs y el namespace. Este volumen será la zona de disco que verán todos los clientes que monten la zona GlusterFS.

 

En la definición indicamos que la política de escritura será round-robin, que establece el orden de escritura de los ficheros de forma cíclica entre los AFRs (AFR1→AFR2→AFR3→AFR1→…), además dejamos un mínimo de un 1% de espacio libre en cada AFR.

 

Ya estamos en disposición de lanzar el cliente GlusterFS, que montará el volumen recién configurado. Como segundo parámetro indicamos el punto de montaje del volumen:

 

master-cluster1> /sbin/glusterfs -f /etc/glusterfs/glusterfs-client.vol /home

 

10.4. Pruebas

10.4.1. Test de estabilidad

 

Una vez separados los nodos servidores de disco de los nodos cliente, los problemas de estabilidad desaparecieron. El nuevo modelo se mostró estable ejecutando el test de estrés por periodos de tiempo de una semana. De esta forma pudimos centrarnos en las pruebas de rendimiento y usabilidad del nuevo modelo.

 

10.4.2. Pruebas de rendimiento

 

Las pruebas de rendimiento se basaron, por una parte, en una serie de tests sintéticos de rendimiento teórico, que nos proporcionaría el rendimiento pico máximo. Por otra parte realizamos pruebas de estrés basadas en la ejecución masiva de procesos con lecturas y escrituras concurrentes. Los detalles de las distintas pruebas de rendimiento se explican en el apartado [19.3.2].

10.4.2.1. Throughput máximo

 

En primer lugar, mostramos las cifras de throughput máximo arrojado por la pruebas de lecturas y escrituras concurrentes con el comando dd:

 

 

Número de instancias

MB/s en lectura

MB/s en escritura

1

42.3

39.3

2

83.2

59.7

3

118.9

80.9

4

119.2

77.9

5

119.1

73.6

 

 

Como podemos ver los resultados de las pruebas de lectura son muy buenos. El filesystem escala linealmente con el número de AFRs.

 

En el caso de las escrituras, el throughput máximo teórico puede enviar cada nodo cliente es de 62 MB/s, que corresponde a la mitad de la capacidad de nuestra red. Recordemos que nuestro filesystem hace uso del translator AFR como mecanismo de replicación de datos. Con AFR los nodos clientes envían los datos duplicados por la red, una copia para cada uno de los nodos de cada AFR.

 

 

Lecturas

 

 

 

Escrituras

 

Figura 10.2: Throughput de lectura y escritura con GlusterFS

 

 

AFR proporciona por un lado un mecanismo sencillo de alta disponibilidad, pero por otro lado limita la tasa de escritura de cada nodo cliente a la mitad. De todas formas 62 MB/s es una cifra muy buena, cercana a la capacidad de escritura máxima de un disco local.

 

El uso de la red por parte de Lustre es mucho más racional. Los datos que se escriben en el filesystem se envía por la red una sola vez, y se delega la posible replicación al backend de almacenamiento, en nuestro caso la pareja de nodos con replicación DRBD.

10.4.2.2. Test ad-hoc

 

El siguiente test consiste en la ejecución concurrente de procesos con un alto uso de E/S. La descripción de la batería de pruebas puede consultarse en los apéndices [19.3.2.2].

 

A continuación mostramos los resultados obtenidos correspondientes a ejecutar un determinado número de procesos de lectura:

 

Concurrencia

Tiempo

Throughput agregado (MB/s)

MB/s por proceso

1

48.5’’

101.3

101.3

2

49.2”

199.8

99.9

3

51.7”

285.2

95.0

6

1’ 50”

267.4

44.5

9

3’ 32”

243.3

27.0

18

6’ 44”

219.0

12.16

36

17’ 25”

171.6

4.7

 

 

Los resultados no distan mucho de los obtenidos con el fielsystem Lustre. GlusterFS también demuestra ser un filesystem altamente escalable a tenor de los valores  de throughput agregado obtenido. Si bien las cifras se quedan un poco por debajo de las obtenidas con Lustre, no dejan de ser muy buenas.

 

 

Throughput agregado

 

 

 

Throughput por proceso

 

Figura 10.3: Throughput del filesystem GlusterFS en lecturas

 

 

De nuevo observamos una escalabilidad lineal con el número de elementos que componen el filesystem. En este caso contamos con 3 AFRs, por lo que es con 3 lecturas concurrentes cuando obtenemos el throughput máximo, cercano a los 300 MB/s.

 

Según se incrementa el número de procesos de lectura concurrentes el throughput del filesystem cae ligeramente, debido en parte al mayor estrés de los díscos físicos de cada AFR, y en parte también a la saturación en los nodos clientes, que deben procesar más instancias de nuestro benchmark, que requiere de cierta capacidad de proceso.

 

Además como hemos comentado previamente, con AFR los datos se envían dos veces por la red, una copia para cada nodo de la pareja. Este hecho limita la cantidad de información que puede enviar un nodo cliente a la mitad.

 

Las pruebas de escritura arrojan los siguientes resultados:

 

Concurrencia

Tiempo

Throughput agregado (MB/s)

MB/s por proceso

1

2’ 28”

33.1

33.1

2

2’ 49”

58.0

29.0

3

3’ 12”

76.7

25.5

6

7’ 0’’

70.2

11.7

9

11’ 13”

66.5

7.3

18

24’ 49’’

60.1

3.3

36

52’ 30”

56.3

1.56

 

En esta ocasión los resultados obtenidos son netamente superiores a los del filesystem Lustre, lastrado por el sistema de replicación DRBD. Nuevamente el throughput agregado se mantiene bastante estable a lo largo de todas las pruebas.

 

 

Throughput agregado

 

 

 

Throughput por proceso

 

Figura 10.4: Throughput del filesystem GlusterFS en escrituras

10.4.3. Pruebas de usabilidad

 

Por último las pruebas de usabilidad sirvieron para medir el grado de interactividad del usuario con la zona de disco compartido mientras el sistema estaba sometido a distintos niveles de carga de trabajo.

 

En esta ocasión y al contrario de lo que sucedía con el modelo de cluster versión 1.1, todas las pruebas de usabilidad resultaron un éxito. Incluso a niveles de carga altísimos el tiempo de respuesta apreciado por los distintos beta testers fue similar al de un filesystem local.

 

El éxito de esta prueba junto con el de la prueba de estabilidad y los buenos resultados cosechados en las pruebas de rendimiento nos lleva a elegir este modelo.

 


11. Sun Grid Engine

 

11.1. Instalación

 

Obtenemos la última versión[11] de Sun Grid Engine (en adelante Sun Grid) de la página web de Sun. El software está empaquetado en dos archivos, una parte común y otra con binarios y librerías dependiente de la arquitectura, lx24-x86 en nuestro caso. Las descargamos y descomprimimos los archivos en /usr/local/sge:

 

master-cluster1> tar xfz sge-6.1u2-common.tar.gz -C /usr/local/sge

master-cluster1> tar xfz sge-6.1u2-bin-lx24-x86.tar.gz -C /usr/local/sge

 

Como paso previo a la instalación es necesario definir los servicios de red que utiliza SunGrid. Los añadimos a todas las máquinas del cluster en el fichero /etc/services:

 

# Sun grid ports

sge_qmaster     536/tcp

sge_execd       537/tcp

 

También es necesario identificar los distintos roles que juegan los nodos de un sistema Sun Grid y asignarlos a nuestros nodos:

 

·        Master host: controla el sistema Sun Grid. Este host ejecuta los daemons sge_master y sge_sched. El host que actúa como master debe ser estable, no estar excesivamente cargado con otros procesos y disponer de al menos 1 GB de memoria libre.

 

·        Shadow master hosts: actúan como backup de la funcionalidad ofrecida por el master host en caso de que éste falle. Los hosts que actúan como shadow master deben ejecutar el daemon sge_shadowd, encargado de monitorizar al master host y compartir el status y la configuración del master host, por  lo que la zona sge-root/cell/common debe ser una zona común.

 

·        Administration hosts: son hosts desde los que se pueden llevar a cabo tareas administrativas como reconfigurar colas, añadir usuarios, etc. Los hosts master lo son por defecto.

 

·        Submit hosts: los trabajos sólo pueden ser enviados al sistema desde estos hosts. Por defecto el nodo master es submit host. En nuestro caso, los dos nodos master-cluster.

 

·        Execution host: ejecutan los trabajos que los usuarios envían al sistema Sun Grid. Un nodo de ejecución debe estar configurado previamente como nodo administrativo.

 

En nuestro cluster contamos con dos tipos de nodos diferenciados: los nodos master y los nodos de cómputo. Los nodos master, desde el punto de vista del sistema Sun Grid serán master hosts, administrative hosts y submit hosts. Los nodos de cómputo serán execution hosts y administrative hosts.

 

Cabe destacar que pese a tener dos hosts que potencialmente pueden actuar como master hosts, no configuramos uno de ellos como shadow_master. En lugar de esto configuramos SunGrid como un servicio más de alta disponibilidad monitorizado por heartbeat (ver apartado [12]). De esta manera, cuando el nodo master que actúa como master host cae, heartbeat lo detecta y activa el servicio en el failnode.

11.1.1. Instalación del Master host

 

La instalación se hace de forma interactiva, ejecutando el script install_qmaster de /usr/local/sge.

 

Checking $SGE_ROOT directory

 

The Grid Engine root directory is not set!

Please enter a correct path for SGE_ROOT.

 

If this directory is not correct (e.g. it may contain an automounter

prefix) enter the correct path to this directory or hit <RETURN>

to use default [/usr/local/sge] >>

 

Grid Engine TCP/IP service >sge_qmaster<

 

Using the service

 

sge_qmaster

 

for communication with Grid Engine.

 

Hit <RETURN> to continue >>

 

A continuación configuramos el nombre de nuestro cluster o cell, útil en caso de contra con varias instancias de cluster.

 

Grid Engine cells

 

Grid Engine supports multiple cells.

 

If you are not planning to run multiple Grid Engine clusters or if you don't

know yet what is a Grid Engine cell it is safe to keep the default cell name

 

default

 

If you want to install multiple cells you can enter a cell name now.

 

The environment variable

 

   $SGE_CELL=<your_cell_name>

 

will be set for all further Grid Engine commands.

 

Enter cell name [default] >>

 

En la siguiente pantalla configuramos la localización del directorio spool.

 

 

Grid Engine qmaster spool directory

 

The qmaster spool directory is the place where the qmaster daemon stores

the configuration and the state of the queuing system.

 

Your account on this host must have read/write access

to the qmaster spool directory.

 

If you will install shadow master hosts or if you want to be able to start

the qmaster daemon on other hosts (see the corresponding section in the

Grid Engine Installation and Administration Manual for details) the account

on the shadow master hosts also needs read/write access to this directory.

 

The following directory

 

[/tmp/sge/default/spool/qmaster]

 

will be used as qmaster spool directory by default!

 

Do you want to select another qmaster spool directory (y/n) [n] >>n

 

Sun Grid permite la ejecución de trabajos en máquinas Windows. En nuestro caso no lo nenesitamos.

 

Windows Execution Host Support

 

Are you going to install Windows Execution Hosts? (y/n) [n] >>n

 

Select default Grid Engine hostname resolving method

 

Are all hosts of your cluster in one DNS domain? If this is

the case the hostnames

 

>hostA< and >hostA.foo.com<

 

would be treated as equal, because the DNS domain name >foo.com<

is ignored when comparing hostnames.

 

Are all hosts of your cluster in a single DNS domain (y/n) [y] >>y

 

Making directories

 

Hit <RETURN> to continue >>

 

La siguiente pantalla permite configurar el modelo de base de datos utilizado para guardar la información de spool.

 

Setup spooling

 

Your SGE binaries are compiled to link the spooling libraries

during runtime (dynamically). So you can choose between Berkeley DB

spooling and Classic spooling method.

Please choose a spooling method (berkeleydb|classic) [berkeleydb] >>berkeleydb

 

The Berkeley DB spooling method provides two configurations!

 

Local spooling:

The Berkeley DB spools into a local directory on this host (qmaster host)

This setup is faster, but you can't setup a shadow master host

 

Berkeley DB Spooling Server:

If you want to setup a shadow master host, you need to use

Berkeley DB Spooling Server!

In this case you have to choose a host with a configured RPC service.

The qmaster host connects via RPC to the Berkeley DB. This setup is more

failsafe, but results in a clear potential security hole. RPC communication

(as used by Berkeley DB) can be easily compromised. Please only use this

alternative if your site is secure or if you are not concerned about

security. Check the installation guide for further advice on how to achieve

failsafety without compromising security.

 

Do you want to use a Berkeley DB Spooling Server? (y/n) [n] >>n

 

Berkeley Database spooling parameters

 

Please enter the Database Directory now, even if you want to spool locally,

it is necessary to enter this Database Directory.

 

Default: [/usr/local/sge/default/spool/spooldb] >> /usr/local/sge/default/spool/spooldb

 

Cada trabajo ejecutado desde Sun Grid es un procso de sistema más. Como tal tendrán un pid asociado. En la siguiente pantalla se configura el rango de pids reservados para los procesos de Sun Grid.

 

Grid Engine group id range

 

When jobs are started under the control of Grid Engine an additional group id

is set on platforms which do not support jobs. This is done to provide maximum

control for Grid Engine jobs.

 

This additional UNIX group id range must be unused group id's in your system.

Each job will be assigned a unique id during the time it is running.

Therefore you need to provide a range of id's which will be assigned

dynamically for jobs.

 

The range must be big enough to provide enough numbers for the maximum numberof Grid Engine jobs running at a single moment on a single host. E.g. a rangelike >20000-20100< means, that Grid Engine will use the group ids from20000-20100 and provides a range for 100 Grid Engine jobs at the same timeon a single host.

 

You can change at any time the group id range in your cluster configuration.

 

Please enter a range >>20000-25000

 

Seguidamente indicamos la dirección de correo del administrador del cluster, tras lo cual se crea una primera configuración del sistema.

 

Grid Engine cluster configuration

 

Please give the basic configuration parameters of your Grid Engine

installation:

 

<execd_spool_dir>

 

The pathname of the spool directory of the execution hosts. User >ivanc<

must have the right to create this directory and to write into it.

 

Default: [/usr/local/sge/default/spool] >>/usr/local/sge/default/spool

 

Grid Engine cluster configuration (continued)

 

<administrator_mail>

 

The email address of the administrator to whom problem reports are sent.

 

It's is recommended to configure this parameter. You may use >none<

if you do not wish to receive administrator mail.

 

Please enter an email address in the form >user@foo.com<.

 

Default: [none] >>cluster@lsi.upc.edu

 

The following parameters for the cluster configuration were configured:

 

execd_spool_dir        /usr/local/sge/default/spool

administrator_mail     cluster@lsi.upc.edu

 

Do you want to change the configuration parameters (y/n) [n] >>n

 

Creating local configuration

 

Creating >act_qmaster< file

Adding default complex attributes

Reading in complex attributes.

Adding default parallel environments (PE)

Reading in parallel environments:

        PE "make".

PE "make.sge_pqs_api".

Adding SGE default usersets

Reading in usersets:

Userset "defaultdepartment".

Userset "deadlineusers".

Adding >sge_aliases< path aliases file

Adding >qtask< qtcsh sample default request file

Adding >sge_request< default submit options file

Creating >sgemaster< script

Creating >sgeexecd< script

Creating settings files for >.profile/.cshrc<

 

Hit <RETURN> to continue >>

 

Una vez configurado, el sistema se inicia el servicio qmaster por primera vez, tras lo cual introducimos la lista de los hosts de ejecución.

 

Grid Engine qmaster and scheduler startup

 

Starting qmaster and scheduler daemon. Please wait ...

starting sge_qmaster

starting sge_schedd

starting up GE 6.1u2 (lx24-x86)

Hit <RETURN> to continue >>

 

Adding Grid Engine hosts

 

Please now add the list of hosts, where you will later install your execution

daemons. These hosts will be also added as valid submit hosts.

 

Please enter a blank separated list of your execution hosts. You may

press<RETURN> if the line is getting too long. Once you are finished

simply press <RETURN> without entering a name.

 

You also may prepare a file with the hostnames of the machines where you plan

to install Grid Engine. This may be convenient if you are installing Grid

Engine on many hosts.

 

Do you want to use a file which contains the list of hosts (y/n) [n] >>n

 

Adding admin and submit hosts

 

Please enter a blank seperated list of hosts.

 

Stop by entering <RETURN>. You may repeat this step until you are

entering an empty list. You will see messages from Grid Engine

when the hosts are added.

 

Sun Grid permite tener una configuración de alta disponibilidad del master host mediante el uso de un shadow master host. Nosotros utilizaremos nuestra propia configuración HA, por lo que no configuramos ningún shadow master.

 

Host(s):

If you want to use a shadow host, it is recommended to add this host

to the list of administrative hosts.

 

If you are not sure, it is also possible to add or remove hosts after the

installation with <qconf -ah hostname> for adding and <qconf -dh hostname>

for removing this host

 

Attention: This is not the shadow host installationprocedure.

You still have to install the shadow host separately

 

Do you want to add your shadow host(s) now? (y/n) [y] >>n

 

SGE_ROOT directory: /usr/local/sge

Cell name: default

Grid Engine qmaster spool directory: /usr/local/sge/default/spool/qmaster

Windows Execution Host Support: no

Setup spooling: berkeleydb

Use Berkeley DB Spooling Server: no

Berkeley Database spooling directory: /usr/local/sge/default/spool/spooldb

Grid Engine group id range: 20000-25000

Grid Engine spool directory on execution hosts: /usr/local/sge/default/spool

Administration email address: cluster@lsi.upc.edu

 

Tras estos pasos se inician los daemons qmaster y schedd.

 

Grid Engine qmaster and scheduler startup

 

Starting qmaster and scheduler daemon. Please wait ...

starting sge_qmaster

starting sge_schedd

starting up GE 6.1u2 (lx24-x86)

Hit <RETURN> to continue >>

 

 

A continuación podemos indicar al sistema qué hosts seran nodos de ejecución.

 

Adding Grid Engine hosts

 

Please now add the list of hosts, where you will later install your execution

daemons. These hosts will be also added as valid submit hosts.

 

Please enter a blank separated list of your execution hosts. You may

press<RETURN> if the line is getting too long. Once you are finished

simply press <RETURN> without entering a name.

 

You also may prepare a file with the hostnames of the machines where you plan

to install Grid Engine. This may be convenient if you are installing Grid

Engine on many hosts.

 

Do you want to use a file which contains the list of hosts (y/n) [n] >>n

 

En la siguiente pantalla se configuran los hosts desde los que se enviarán los trabajos y aquellos con permisos administrativos.

 

Adding admin and submit hosts

 

Please enter a blank seperated list of hosts.

 

Stop by entering <RETURN>. You may repeat this step until you are

entering an empty list. You will see messages from Grid Engine

when the hosts are added.

 

Host(s):

If you want to use a shadow host, it is recommended to add this host

to the list of administrative hosts.

 

If you are not sure, it is also possible to add or remove hosts after the

installation with <qconf -ah hostname> for adding and <qconf -dh hostname>

for removing this host

 

Attention: This is not the shadow host installationprocedure.

You still have to install the shadow host separately

 

Do you want to add your shadow host(s) now? (y/n) [y] >>n

Creating the default <all.q> queue and <allhosts> hostgroup

 

root@master-cluster1 "@allhosts" to host group list

root@master-cluster2 "all.q" to cluster queue list

 

Hit <RETURN> to continue >>

 

En la siguiente pantalla seleccionamos el nivel logs generado por el shceduler. Lo dejamos en Normal.

 

Scheduler Tuning

 

The details on the different options are described in the manual.

 

Configurations

 

1) Normal

          Fixed interval scheduling, report scheduling information,

actual + assumed load

 

2) High

          Fixed interval scheduling, report limited scheduling information,

actual load

 

3) Max

          Immediate Scheduling, report no scheduling information,

actual load

 

Enter the number of your prefered configuration and hit <RETURN>!

Default configuration is [1] >>1

 

We're configuring the scheduler with >Normal< settings!

Do you agree? (y/n) [y] >>y

 

El master host ya está  configurado. La sieguiente pantalla muestra información sobre la definición de variables de entorno necesarias para que Sun Grid funcione correctamente.

 

Using Grid Engine

 

You should now enter the command:

 

source /usr/local/sge/default/common/settings.csh

 

if you are a csh/tcsh user or

 

   # /usr/local/sge/default/common/settings.sh

 

if you are a sh/ksh user.

 

This will set or expand the following environment variables:

 

   - $SGE_ROOT         (always necessary)

   - $SGE_CELL         (if you are using a cell other than >default<)

   - $SGE_QMASTER_PORT (if you haven't added the service >sge_qmaster<)

   - $SGE_EXECD_PORT   (if you haven't added the service >sge_execd<)

   - $PATH/$path       (to find the Grid Engine binaries)

   - $MANPATH          (to access the manual pages)

 

Hit <RETURN> to see where Grid Engine logs messages >>

 

La siguiente pantalla informa de la localización de  scripts de inicio.

 

Grid Engine messages

 

Grid Engine messages can be found at:

 

   /tmp/qmaster_messages (during qmaster startup)

   /tmp/execd_messages   (during execution daemon startup)

 

After startup the daemons log their messages in their spool directories.

 

   Qmaster:     /usr/local/sge/default/spool/qmaster/messages

   Exec daemon: <execd_spool_dir>/<hostname>/messages

 

 

Grid Engine startup scripts

 

Grid Engine startup scripts can be found at:

 

   /usr/local/sge/default/common/sgemaster (qmaster and scheduler)

   /usr/local/sge/default/common/sgeexecd (execd)

 

Do you want to see previous screen about using Grid Engine again (y/n) [n] >>n

 

Finalmente se informa de la correcta instalación del sistema Sun Grid.

 

Your Grid Engine qmaster installation is now completed

 

Please now login to all hosts where you want to run an execution daemon

and start the execution host installation procedure.

 

If you want to run an execution daemon on this host, please do not forget

to make the execution host installation in this host as well.

 

All execution hosts must be administrative hosts during the installation.

All hosts which you added to the list of administrative hosts during this

installation procedure can now be installed.

 

You may verify your administrative hosts with the command

 

   # qconf -sh

 

and you may add new administrative hosts with the command

 

   # qconf -ah <hostname>

 

Please hit <RETURN>>>

11.1.2. Instalación de un Execution host

 

A continuación ejecutamos el script de instalación install_execd. Como requisito previo, es necesario que haya un master host con los servicios qmaster y qschedd corriendo.

 

Checking $SGE_ROOT directory

 

The Grid Engine root directory is:

 

   $SGE_ROOT = /usr/local/sge

 

If this directory is not correct (e.g. it may contain an automounter

prefix) enter the correct path to this directory or hit <RETURN>

to use default [/tmp/sge] >>

 

En primer lugar indicarmos en qué cell o cluster podrá ejecutar trabajos el execution host que estamos configurando. En nuestro caso en el cell por defecto default.

 

Grid Engine cells

 

Please enter cell name which you used for the qmaster

installation or press <RETURN> to use [default] >>

 

En la siguiente pantalla configuramos la localización del directorio de spool del execution host.

 

Local execd spool directory configuration

 

During the qmaster installation you've already entered a global

execd spool directory. This is used, if no local spool directory is configured.

 

Now you can configure a local spool directory for this host.

ATTENTION: The local spool directory doesn't have to be located on a local

drive. It is specific to the <local> host and can be located on network drives,

too. But for performance reasons, spooling to a local drive is recommended.

 

FOR WINDOWS USER: On Windows systems the local spool directory MUST be set

to a local harddisk directory.

Installing an execd without local spool directory makes the host unuseable.

Local spooling on local harddisk is mandatory for Windows systems.

 

Do you want to configure a local spool directory

for this host (y/n) [n] >>y

 

Please enter the local spool directory now! >>/usr/local/sge/default/spool/node1

 

Por defecto todo sistema Sun Grid dispone de una cola llamada all.q, que incluye todos los nodos de ejecución.

 

Adding a queue for this host

 

We can now add a queue instance for this host:

 

   - it is added to the >allhosts< hostgroup

   - the queue provides 2 slot(s) for jobs in all queues

referencing the >allhosts< hostgroup

 

You do not need to add this host now, but before running jobs on this host

it must be added to at least one queue.

 

Do you want to add a default queue instance for this host (y/n) [y] >>y

 

node1 modified "@allhosts" in host group list

node1 "all.q" in cluster queue list

 

Los servicios Sun Grid ya están instalados correctamente en este host. La siguiente pantalla muestra variables de entorno necesarias para el correcto funcionamiento de Sun Grid.

 

Using Grid Engine

 

You should now enter the command:

 

source /tmp/sge/default/common/settings.csh

 

if you are a csh/tcsh user or

 

# . /tmp/sge/default/common/settings.sh

 

if you are a sh/ksh user.

 

This will set or expand the following environment variables:

 

   - $SGE_ROOT         (always necessary)

   - $SGE_CELL         (if you are using a cell other than >default<)

   - $SGE_QMASTER_PORT (if you haven't added the service >sge_qmaster<)

   - $SGE_EXECD_PORT   (if you haven't added the service >sge_execd<)

   - $PATH/$path       (to find the Grid Engine binaries)

   - $MANPATH          (to access the manual pages)

 

Hit <RETURN> to see where Grid Engine logs messages >>

 

Por ultimo se indica la localización de los logs y los scripts necesarios para iniciar Sun Grid en los execution hosts.

 

Grid Engine messages

 

Grid Engine messages can be found at:

 

   /tmp/qmaster_messages (during qmaster startup)

   /tmp/execd_messages   (during execution daemon startup)

 

After startup the daemons log their messages in their spool directories.

 

   Qmaster:     /tmp/sge/default/spool/qmaster/messages

   Exec daemon: <execd_spool_dir>/<hostname>/messages

 

 

Grid Engine startup scripts

 

Grid Engine startup scripts can be found at:

 

   /tmp/sge/default/common/sgemaster (qmaster and scheduler)

   /tmp/sge/default/common/sgeexecd (execd)

 

Do you want to see previous screen about using Grid Engine again (y/n) [n] >>n

 

Your execution daemon installation is now completed.

 

11.2. Configuración

 

Hemos instalado un master host y un execution host. Durante la instalación del master host se nos ha preguntado por diversos paths donde almacenar información de configuración del cluster, scheduling de procesos, etc.

 

En los siguientes pasos aprovecharemos los conocimientos adquiridos en filesystems paralelos y HA para integrar este servicio en nuestro sistema de heartbeat y dotarlo de  alta disponibilidad.

 

Asumimos que partimos de la arquitectura versión 2.0, con GlusterFS instalado.

11.2.1. Zona Spool de mater hosts

 

En el apartado de configuración del master host hemos indicado la ruta donde residirá el spool del nodo master (/usr/local/sge/default/spool/qmaster). Este directorio contiene la información de scheduling de procesos que necesita el daemon sge_qmaster para funcionar. Si queremos tener un master host alternativo que tome el control del grid en caso de fallo del master host "primario", ambas máquinas deben tener acceso a la zona referida.

 

Nuevamente, lo ideal sería disponer de un SAN conectado a los dos nodos master, pero no disponemos de estos recursos. En cambio, hemos visto una solución que ya utilizamos como sistema de replicación de bloques en el sistema de ficheros Lustre. DRBD permite crear un dispositivo de bloques virtual formado por los discos locales de dos máquinas conectadas por red.

 

En la figura [11.1] se muestra un esquema con las zonas que albergan los nodos master-cluster, incluyendo la zona common de Sun Grid.

 

En un esquema DRBD los nodos que contienen los discos juegan los roles de primary y secondary. El nodo primary tiene pleno acceso al disco, mientras que el secondary se limita a recibir la replicación de datos desde primary. En el caso que nos toca, el nodo primary será el nodo que esté configurado como master host Sun Grid en ese momento, mientras que el otro nodo master será el nodo secondary. En caso de fallo del nodo primary, el nodo configurado como secondary se dará cuenta y se configurará como primary.

 

Para configurar esta zona DRBD, en primer lugar debemos crear dos particiones idénticas en ambos nodos master. Como contamos con dos discos por máquina, hacemos un RAID1:

 

master-cluster1> mdadm --create /dev/md3 --level=1 --raid-devices=2 /dev/sda5 /dev/sdb5

 

La configuración DRBD será la misma en ambas máquinas. El fichero drbd.conf se encuentra en el apéndice [19.1.9].

 

En primer lugar es necesario incializar el dispositivo DRBD. Para ello se deben seguir los pasos detallados en el apartado [9.3.2]. Nótese que la sincronización se realiza por una conexión dedicada entre ambos nodos master.

 

Ya disponemos de la zona DRBD funcional:

 

version: 8.2.6 (api:88/proto:86-88)

GIT-hash: 3e69822d3bb4920a8c1bfdf7d647169eba7d2eb4 build by root@master-cluster1, 2008-10-01 10:56:55

 

 1: cs:Connected st:Primary/Secondary ds:UpToDate/UpToDate C r---

ns:9710768 nr:0 dw:9465908 dr:819917 al:59 bm:39 lo:0 pe:0 ua:0 ap:0 oos:0

 

Paramos el daemon sge_qmaster y movemos el contenido del directorio spool a la zona DRBD:

 

master-cluster1> /etc/init.d/sge_qmaster stop

master-cluster1> mount /dev/drbd1 /mnt/sge/default/spool

master-cluster1> cd /usr/local/sge/default/spool

master-cluster1> tar cf - * | (cd /mnt/sge/default/spool;tar xf - )

master-cluster1> cd ..

master-cluster1> rm -rf spool

master-cluster1> ln -s /mnt/sge/default/spool spool

master-cluster1> /etc/init.d/sge_qmaster start

11.2.2. Zona common

 

La zona common contiene información acerca de la configuración del cluster, accounting, etc. De cara a nuestro objetivo de alta disponibilidad, nos resulta interesante el fichero act_qmaster, que contiene el hostname de la máquina que actúa como master host en un momento dado. Todos los nodos del cluster se basan en la información de este fichero para contactar con el master host.

 

En nuestra configuración, si el nodo que actúa como master host falla, hay otro nodo preparado para tomar el control. Para ello es necesario que previa ejecución del daemon sge_qmaster modifique el fichero act_qmaster escribiendo su hostname. Sólo tras hacer esto le será posible lanzar el daemon sge_qmaster.

 

Hemos comentado que todos los nodos del cluster saben quién es el master host gracias al fichero act_qmaster. Si hacemos cambios en este fichero, estos cambios deben ser visibles para los nodos del cluster de forma inmediata. Para ello alojaremos el directorio common en una nueva zona compartida. Además de ser visible por todos los nodos del cluster, debe estar accesible a pesar de la caída de alguno de los nodos master. La solución adoptada consiste en crear una zona GlusterFS con un AFR formado por sendas particiones en los nodos de entrada al sistema (master-cluster1 y master-cluster2). De esta manera en caso de caer una de las dos máquinas master, la otra seguirá teniendo acceso a la zona y ésta en ningún caso dejará de ser visible por el resto de nodos.

 

En la figura [11.1] se muestran las distintas zonas que albergan los nodos master-cluster, entre ellas la zona common.

 

 

Ilustración 11.1: Esquema de las zonas albergadas en los nodos master-cluster

 

 

Nuevamente, habilitamos una partición RAID en cada una de las máquinas master:

 

master-cluster1> mdadm --create /dev/md4 --level=1 --raid-devices=2 /dev/sda6 /dev/sdb6

master-cluster1> mke2fs -j /dev/md4

master-cluster1> mount /dev/md4 /mnt/glusterfs/sge-common

 

Configuramos un nuevo servidor GlusterFS en ambas máquinas master. El correspondiente fichero de configuración glusterfs-server_sge-common.vol se encuentra en los apéndices [19.1.10].

 

Lanzamos el daemon GlusterFS:

 

master-cluster1> /sbin/glusterfsd -f /etc/glusterfs/glusterfs-server_sge-common.vol

 

Creamos una configuración cliente gluster para esta nueva zona. Esta configuración, guardada en /etc/glusterfs/glusterfs-client-sge.vol (ver apéndices [19.1.11]), debe estar en todas las máquinas del cluster, ya que contendrá la zona common necesaria tanto por sge_qmaster como por sge_execd.

 

Montamos esta zona en todas las máquinas del cluster en un directorio habilitado a tal efecto:

 

master-cluster1> /sbin/glusterfs -f /etc/glusterfs/glusterfs-client-sge.vol /mnt/sge/default/common

 

De la misma forma que hicimos con la zona spool, movemos el contenido de la zona common y paramos el daemon sge_execd en todas los execution host, en caso de estar corriendo:

 

node1> /etc/init.d/sge_execd stop

...

 

Movemos lo datos common a la nueva zona compartida:

 

master-cluster1> /etc/init.d/sge_qmaster stop

master-cluster1> cd /usr/local/sge/default/common

master-cluster1> tar cf - * | (cd /mnt/sge/default/common;tar xf -)

master-cluster1> cd ..

master-cluster1> rm -rf common

master-cluster1> /etc/init.d/sge_qmaster start

 

Volvemos a lanzar el daemon sge_execd en todos los execution hosts:

 

node1> /etc/init.d/sge_execd start

...

 

Tras estos pasos el sistema Sun Grid es plenamente operativo con tolerancia a fallos en los nodos master. Queda pendiente la automatización del proceso de inicio de servicios en nodo failover, que veremos el capítulo [12].

11.2.3. Colas

 

La antigua estructura con tres clusters separados tiene su correspondencia en el nuevo cluster en forma de colas. Definiremos tres colas: eixam, nozomi y tenada, que estarán formadas por las máquinas que conformaban los respectivos clusters más las máquinas nuevas que estaban pendientes de instalación.

 

Cuando hablamos de colas en un entorno HTC se da un abuso de lenguaje que puede llevar a equívocos. Una cola Sun Grid realmente es una cola de ejecución, lo que no es más que un conjunto de máquinas que ejecutan los procesos que les envía el planificador o scheduler. No se debe confundir con la cola de espera, que es el espacio “virtual”, donde los trabajos encolados por los usuarios esperan a ser enviados por el scheduler a alguna cola de ejecución.

 

La figura [11.2] muestra el esquema con las tres colas de ejecución de nuestro cluster y la cola de espera. Nótese que hay una única cola de espera en la que conviven los trabajos destinados a cualquiera de las tres colas de ejecución.

 

Figura 11.2: Esquema de cluster con colas de ejecución y de espera

 

 

Sun Grid permite definir tantas colas (de ejecución) como sean necesarias, pudiendo personalizar multitud de aspectos. En cambio, en un cluster, existe una única cola de espera.

 

La idea es que, a pesar de existir un único cluster, los usuarios de cada grupo ejecuten su trabajo en las máquinas que les pertenecen. Las colas pueden crearse desde consola o mediante el frontend gráfico qmon , como muestra la figura [11.3].

 

Si bien inicialmente los usuarios de una cola no pueden utilizar los recursos de las otras, se abre la posibilidad a futuras colaboraciones mediante la creación de colas nice. Estas colas permiten el aprovechamiento de las máquinas desocupadas por parte de los usuarios de los otros grupos. Este mecanismo ha sido probado con éxito en el cluster de pruebas, pero permanecerá desactivado hasta que se produzca un acuerdo de colaboración entre los distintos grupos de investigación.

 

 

Figura11.3: Ventana de creación de colas desde qmon

 

 

Como hemos comentado antes existe una única cola de espera. En esta cola conviven los trabajos de todos los usuarios ordenados en función de una prioridad que se explica en el apartado [11.2.4]. Como los usuarios de cada grupo trabajan solamente en la cola que tienen asignada, los trabajos de usuarios de distintos grupos no interferirán entre sí a la hora de salir de la cola de espera. Por decirlo de alguna manera, en la cola de espera, los trabajos de un usuario dado sólo compiten con trabajos de usuarios de su mismo grupo.

11.2.3. Usuarios

 

Se procedió a dar de alta a todos los usuarios del cluster como usuarios del sistema Sun Grid con el mismo username. Sun Grid permite la gestión de usuarios, grupos, proyectos, etc.

 

Igualmente creamos tres grupos que se corresponden con los tres clusters antiguos y con las tres colas y se establecieron los permisos de acceso a cada una de las colas según estos grupos, de tal forma que en la cola eixam sólo podrán trabajar los usuarios del grupo eixam, en nozomi los del grupo nozomi, etc. La figura [11.4] muestra la ventana de administración de grupos de qmon.

 

A nivel administrativo los grupos facilitan la gestión de los usuarios. Dado que los permisos de las colas se establecen por grupos, si damos de alta o de baja un usuario, no es necesario realizar ninguna modificación en el control de acceso de las colas; el cambio queda reflejado en su grupo y las colas son conscientes inmediatamente.

 

 

Figura 11.4: Ventana de administración de grupos en qmon

11.2.4. Políticas

 

Al hablar de la cola de espera, hemos hecho notar que los trabajos que contiene se ordenan atendiendo a un valor numérico que expresa una prioridad. Junto con los responsables de los tres grupos que trabajan en el cluster, acordamos que, en principio, todos los usuarios contasen con el mismo peso en el sistema, es decir, que los trabajos de cada uno de ellos fuesen igual de prioritario que los del resto de usuarios.

 

Para llevar a cabo esta política “igualitaria”, definimos lo que Sun Grid llama una política funcional. En dicha política a cada usuario se le da un porcentaje o share de los recursos, definidos en forma de tikets. A mayor share mayor prioridad.

 

Como queremos que todos los usuarios tengan el mismo peso, damos a todos los usuarios el mismo share. El resultado de esta política es que, los trabajos en cola de espera de los usuarios con menor número de trabajos en ejecución tendrán mayor prioridad que los trabajos de los usuarios con más trabajos ejecutándose.

 

Para mantener un ratio óptimo entre procesos de usuario y número de CPUs, limitaremos el valor slots de las instancias de cada cola al número de procesadores (o cores) físico de cada nodo. Así un nodo con 4 cores tendrá 4 slots disponibles, lo que limitará el número de trabajos en ejecución de forma simultánea.

 

El planificador de Sun Grid repasa las colas a intervalos de tiempo preestablecidos y ordena los trabajos de usuario en función de sus prioridades. Esta tarea puede llegar a requerir una cantidad de cálculo nada desdeñable en el caso de contar con políticas de scheduling complejas y miles de procesos encolados.

 

Si bien nuestra política de scheduling es convencional, limitamos la ventana de trabajos que entran dentro de la planificación de la cola a 10.000. Igualmente limitamos a 500 el número máximo de trabajos encolados por un solo usuario con el fin de evitar que un solo usuario acapare toda la cola.

 

Finalmente limitamos el número máximo de trabajos en ejecución simultáneos de usuario a 25. El objetivo es evitar la inanición de los trabajos encolados porque un usuario del mismo grupo haya ocupado la totalidad de su cola.

 

La figura [11.5] muestra la ventana que da acceso a las políticas del cluster. Permite variar aspectos como el numero máximo de trabajos funcionales, de tickets, etc.

 

 

 

Figura 11.5: Ventana de control de políticas del cluster desde qmon

 

 

La figura [11.6] muestra la ventana que permite variar la configuración funcional. Nuestra configuración asigna el mismo número de share (100) a todos los usuarios,  para que de esta forma los trabajos de todos los usuarios tengan, a igual número de jobs en el sistema, la misma prioridad.

 

Figura 11.6: Ventana de gestión de la política funcional desde qmon


12. Heartbeat

 

Utilizaremos Heartbeat para proporcionar alta disponibilidad a los principales servicios del cluster, que son Sun Grid y el sistema de ficheros paralelo.

 

12.1. Instalación

 

Heartbeat está disponible dentro del repositorio de software de Debian, por lo que la instalación es la misma que la de cualquier otro programa:

 

master-cluster1> apt-get install heartbeat

 

Los ficheros de configuración, así como los scripts de gestión de servicios que quedan en los directorios /etc/ha.d y en /etc/ha.d/resources.d respectivamente.

 

La instalación configura el arranque de heartbeat automáticamente al inicio del sistema.

 

12.2. Configuración

12.2.1. Cluster con GlusterFS (versión 2.0)

 

Como vimos en el capítulo [10] cuando hablamos de la instalación y configuración de GlusterFS, el propio filesystem incorpora mecanismos de protección ante el fallo de un servidor de disco. El sistema de replicación de datos AFR se encarga de escribir los datos en varios servidores al mismo tiempo, por lo que no es necesario, al contrario de los que sucedía en los modelo con Lustre y DRBD (cluster versiones 1.0 y 1.1), el uso de un sistema de replicación de datos. Así pues, el único servicio que debemos configurar en HA es Sun Grid.

 

Tal y como expusimos en el apartado [11.2] al hablar de la configuración de Sun Grid, hay dos zonas con datos vitales para su correcto funcionamiento. Por una parte el directorio common, encargado de mantener la información de la configuración del sistema, y por otro spool, con información sobre el scheduling de procesos. El directorio common está hospedado en la zona GlusterFS, por lo que queda salvaguardado ante posibles fallos. En cambio el directorio spool se encuentra en una zona DRBD compartida entre los dos nodos master.

 

El funcionamiento de DRBD se explica detalladamente en el apartado [9.1].

 

En caso de que se produzca un fallo hardware en la máquina master, nuestro sistema de alta disponibilidad debe ser capaz de darse cuenta y realizar los pasos que acabamos de describir. En este escenario el nodo que ha fallado habría quedado totalmente invalidado para continuar ofreciendo los servicios de Sun Grid master.

 

El siguiente paso es garantizar que, una vez el failnode tiene control sobre la zona common, se convierta en Sun Grid master. En primer lugar hay que cambiar la identidad de la máquina master Sun Grid en la configuración del sistema de clustering para que todos los nodos sepan que tienen que tratar con una nueva máquina. Después de esto bastará con iniciar los servicios de Sun Grid master.

 

Heartbeat se configura desde dos ficheros: ha.cf y haresources9. En ha.cf se define cómo y cada cuánto tiempo monitorizaremos el peer node, mientras que en haresources definiremos los procedimientos a seguir en caso de fallo del peer node.

 

En estos ficheros de configuración indicamos que el chequeo o heartbeat se realiza vía red (ethernet) unicast a la dirección del interfaz eth0 del peer node. Asumimos que si la red de uno de los dos nodos no responde en 120 segundos, se puede considerar que el nodo ha fallado y debemos tomar las medidas oportunas.

 

Los procedimientos a seguir en caso de fallo se definen en haresources:

 

master-cluster1 Filesystem.drbd::/dev/drbd1::/mnt/sge/default/spool::ext3 sungrid MailTo::cluster@lsi.upc.edu

 

Este fichero es idéntico en ambos nodos. El primer campo indica el nodo que actúa como master normalmente, mientras que los siguientes dos nodos definen acciones concretas:

 

Filesystem::/dev/drbd1::/mnt/sge/default/spool::ext3

 

Ejecuta el script Filesystem, encargado de montar el dispositivo /dev/drbd1, que contiene la zona spool de Sun Grid en /mnt/sge/default/spool.

 

El cambio de rol secondary por primary necesario previo al montaje lo realiza el propio sistema DRBD.

 

Sungrid

 

Este script cambia la configuración del sistema SunGrid indicando el hostname de la nueva máquina master. El script completo se encuentra en el apéndice [19.1.8].

 

Finalmente indicamos la dirección de correo a la que llegarán los avisos en caso de fallo y recuperación.

 


12.3. Split-Brain

 

Al hablar de sistemas de alta disponibilidad debemos tener en cuenta el fenómeno llamado split-brain, que se produce cuando la comunicación entre los dos nodos se interrumpe y ambos intentan ser propietarios del mismo recurso.

 

De los dos recursos que tratamos, sólo la zona DRBD es susceptible de sufrir problemas por split-brain. Imaginemos que master-cluster1 es el nodo master y se queda sin conexión de red (eth0) aunque sigue funcionando. Master-cluster2 lo detectaría por heartbeat, asumiría que ha fallado e intentaría montar el dispositivo DRBD, pero no podría ya que no es un nodo primary. Master-cluster1 seguiría siendo primary porque la replicación DRBD se realiza vía un interfaz dedicado (eth1) que seguiría funcionando. Así pues, en este escenario no nos veríamos afectados por split-brain.

 

Supongamos ahora que falla la conexión dedicada (eth1), pero no la conexión de red (eth0). En este caso sería el sistema DRBD el que detectaría un fallo en los nodos e intentaría cambiar los roles. En este caso, muy poco probable, sí que podría producirse split-brain, ya que podríamos tener ambos nodos master configurados como primary, si bien no llegaría a producirse corrupción de datos porque el nodo configurado inicialmente como secondary nunca llegaría a montar el dispositivo DRBD (recordemos que como eth0 no ha fallado heartbeat no detecta fallo alguno).

 

Otro caso en el que se produciría split-brain sería aquel en el que ambas conexiones de red se interrumpieran pero los nodos siguiesen funcionando. En este caso en el nodo secondary el sistema DRBD dectaría el fallo en eth1 y se configuraría como primary. Algo más tarde (recordemos, 120 segundos) heartbeat montaría el dispositivo DRBD e intentaría configurarse como Sun Grid master, pero no lo conseguiría porque no hay conexión de red.

 

Así pues ambos nodos master tienen el control sobre la zona DRBD, pero sólo uno de ellos, en el que sigue ejecutándose los daemons de Sun Grid master, es susceptible de escribir en la zona, evitando así corrupción de datos.

 

Al volver la conexión de red DRBD detectaría la situación anómala con los dos nodos primary. Llegados a este punto DRBD cuenta con distintas estrategias de recuperación de split-brain, pero dado lo poco probable y delicado del tema preferimos ser avisados vía email y actuar manualmente.

 


13. Tivoli

 

Utilizaremos Tivoli como software de gestión de  las imágenes de sistema de los nodos del cluster. Este software nos permitirá instalar por red una imagen limpia del sistema cada vez que una máquina arranca. Por otro lado el realizar nuevas versiones de la imagen o instalar nuevo software es trivial con este mecanismo.

 

Además de la instalación del sistema en sí, Tivoli permite realizar operaciones previas sobre la máquina utilizando un lenguaje de programación propio denominada Rembo-C. Gracias a ello, podremos añadir nuevas máquinas al cluster inicializando los discos y el sistema de forma desatendida.

 

13.1. Instalación

 

Uno de los motivos de la elección de Tivoli como software de gestión de imágenes es, además de su potencia y versatilidad, la disponibilidad de licencia. El software puede encontrarse en la intranet de distribución de software de la UPC. Por otra parte no existe ninguna otra herramienta libre (Brutalix,…) que permita la flexibilidad que necesitamos.

 

Desde la adquisición de Rembo por parte de IBM en 2006, parte de las funcionalidades que nos interesan (scripts en Rembo-C) han dejado de estar disponibles. Para poder trabajar con Tivoli en modo Rembo es necesario instalar un parche. Descargamos Tivoli de la distribución de software y el parche de la web de IBM.

 

Descomprimimos en /usr/local los paquetes con Tivoli y el parche:

 

master-cluster1> cd /usr/local

master-cluster1> tar xfz  TPMfOSd-Full-5.1.1.0-build-051.39-linux.tar.gz

master-cluster1> tar xfz  TPMfOSd-TKIT-Fix-5.1.1.0-build-053.11-

linux.tar.gz

master-cluster1> cd /usr/local

master-cluster1> tar xfz TPMfOSd-Full-5.1.1.0-build-051.39-linux.tar.gz

master-cluster1> apt-get install mysql-server

 

Ejecutamos el programa de instalación:

 

master-cluster1> cd /usr/local/tpmfos

master-cluster1> ./setup

 

      1. Enter the installation directory [/usr/local/tpmfos]:

              This software requires a large amount of disk space to store client images.

              Please enter the directory where to store these data.

              Data directory [/usr/local/tpmfos/files]:

 

       2. This software can be managed from a web-based console.

              You can choose to use a secure link (HTTPS) to the server console.

              You can also change the default ports. You must also choose the administrator name

              Do you want to use SSL to access the Web interface? [y/n (default y)]:

              Enter the HTTP console port [8080]:

              Enter the HTTPS console port [443]:

              Enter the administrator name [admin]:

 

Configuramos el entorno web de gestión de Tivoli.

 

       3. ln: creando el enlace simbólico «mysql.jar» a «mysql-connector-java-*/mysql-connector-java-*-bin.jar»

      

El enlace lo hemos creado con anterioridad y apunta a nuestro conector mysql ubicado en /usr/java/j2sdk1.4.2_18/jre/lib/ext/mysql-connector-java-3.1.14-bin.jar.

 

       4. This software requires a third party database to store deployment objects.

              Can you provide a MySQL database? [y/n (default y)]:

              Enter the IP address of your MySQL server [127.0.0.1]:

              Enter the port used by your MySQL server on 127.0.0.1 [3306]:

              Enter the name of an existing (empty) database [AutoDeploy]:

              If the database AutoDeploy on server 127.0.0.1 does not exist, please create it now!

              Press return to continue...

              Enter the user name to access the database [root]:

              Enter the password to access the database:

 

Debemos crear una bbdd con el nombre AutoDeploy, aunque en otra versión se llama tpmfosddb.

 

       5. The installation program will now create the configuration file and initialize the server.

              Please wait...

              IBM Tivoli Provisioning Manager for OS Deployment server v.5.1 (000.32)

              Licensed Materials - Property of IBM. L-DDAC-6RLW3E

              (C) Copyright IBM Corporation 1998, 2006.

              All Rights Reserved. IBM, the IBM logo, and Tivoli are trademarks

              of IBM Corporation in the United States, other countries or both.

              ** Rembo server has successfully stopped

              OS deployment server initialized successfully.

              File /opt/tpmfos-5.1/files/global/rad/radb.ini created successfully.

              URL to access database: mysql://127.0.0.1:3306/AutoDeploy?useUnicode=true&characterEncoding=UTF-8

              Username to access the database: root

              Password to access the database: hidden

              Do you want to create startup scripts? [y/n (default y)]:

 

Se crean los scripts de inicio.

     

       6.     File /home/tpmfos/files/global/rad/radb.ini created successfully.

              URL to access database: mysql://127.0.0.1:3306/AutoDeploy?useUnicode=true&characterEncoding=UTF-8

              Username to access the database: root

              Password to access the database: hidden

              Do you want to create startup scripts? [y/n (default y)]:

              ln: creando el enlace simbólico «/etc/rc2.d/S91rembo» a «/etc/init.d/rembo»: El fichero existe

              ln: creando el enlace simbólico «/etc/rc2.d/S92rbagent» a «/etc/init.d/rbagent»: El fichero existe

              ln: el destí «/etc/rc2.d/S90dbgw» no és un directori

              ln: creando el enlace simbólico «/etc/rc5.d/S91rembo» a «/etc/init.d/rembo»: El fichero existe

              ln: creando el enlace simbólico «/etc/rc5.d/S92rbagent» a «/etc/init.d/rbagent»: El fichero existe

              ln: creando el enlace simbólico «/etc/rc5.d/S90dbgw» a «/etc/init.d/dbgw»: El fichero existe

              Startup scripts (rembo, dbgw, rbagent) have been created in /etc/init.d.

              Do you want to start all the services ? [y/n (default y)]:

              Starting Rembo JDBC to ODBC gateway: dbgw.

              Starting IBM Tivoli Provisioning Manager for OS Deployment server: remboStarting IBM Tivoli Provisioning               Manager for OS Deployment Web interface extension: rbagentIBM Tivoli Provisioning Manager for OS Deployment                 Web interface extension v.5.1 (000.32)

              Licensed Materials - Property of IBM. L-DDAC-6RLW3E

              (C) Copyright IBM Corporation 1998, 2006.

              All Rights Reserved. IBM, the IBM logo, and Tivoli are trademarks

              of IBM Corporation in the United States, other countries or both.

              .

              Goodbye!

 

 

Tras responder estas preguntas Tivoli queda instalado con una configuración preliminar.

 

Copiamos el script de inicio en /etc/init.d/ y hacemos que el servicio Tivoli se inicie al arrancar el sistema:

 

master-cluster1> cp /usr/local/tmpfos/scripts/linux/redhat/rembo /etc/init.d/tivoli

master-cluster1> ln -s /etc/init.d/tivoli /etc/rc2.d/S91tivoli

 

Tivoli instala un servidor web que corre en el puerto 8080. En adelante toda interacción con el sistema de imágenes se realizará vía web:

 

http://master-cluster1.lsi.upc.edu:8080

 

Tivoli utiliza el protocolo PXE (Preboot eXecution Environment) para arrancar e instalar los sistemas de las máquinas que gestiona. Este sistema funciona conjuntamente con el protocolo de red DHCP. En las máquinas master contamos con sendos servidores DHCP (ver apartado [16.1]) que se encargan de asignar las direcciones IP a cada una de las máquinas del cluster.

 

Para que Tivoli funcione correctamente con nuestros servidores DHCP es necesario indicar lo siguiente en su fichero de configuración (/etc/dhcp3/dhcpd.conf):

 

option vendor-class-identifier "PXEClient";

 

 

 

 

 

13.2. Configuración

 

Agruparemos las máquinas por "clusters/colas", creando  3 grupos administrativos, eixam, nozomi y tenada, más un grupo con las máquinas servidoras de disco denominado storage. Cada una de las máquinas del cluster debe darse de alta en Tivoli en alguno de estos grupos. Posteriormente podremos personalizar el proceso de instalación de imágenes por grupos si es necesario.

 

El alta de una máquina se hace desde el menú Toolkit®Toolkit Hosts®Register new hosts.

 

Los datos solicitados son la dirección IP y la dirección MAC de la tarjeta de red. Es necesario dar de alta previamente cada máquina en el servidor DHCP con los mismos datos.

 

Una vez dada de alta, se debe configurar la máquina para arrancar por red vía PXE. Esta funcionalidad se configura en la BIOS y varía dependiendo del modelo de ordenador.

 

Tras estos pasos, la máquina está lista para arrancar vía PXE. Durante el arranque de Tivoli, en primer lugar el nodo obtiene una dirección IP por DHCP y posteriormente se establece comunicación entre el nodo y el servidor Tivoli. La figura [13.1] muestra este proceso.

 

 

PXE

 

Figura 13.1: Pantalla de nodo arrancando por PXE

 

 

Por defecto todas las máquinas dadas de alta en Tivoli ejecutan el interfaz de administración, que cuenta con una consola que nos permitirá crear imágenes del sistema en el servidor. En la figura [13.2] se muestra la pantalla con el interfaz de administración de Tivoli.

 

La idea es configurar una máquina tipo para  una vez que sea estable y cuente con todos los servicios necesarios, arrancar vía PXE el interfaz de administrador y crear una imagen de sistema. Posteriormente esta imagen de sistema se instalará por red en todas las máquinas del cluster en el momento de arrancar. Tras finalizar el proceso de copia del sistema, la máquina arrancará y personalizará el sistema en función de su rol dentro del cluster, como se detalla en el apartado [13.4].

 

 

Tivoli

 

Figura 13.2: Interfaz de administración de Tivoli

 

 

Este mecanismo nos permite actualizar el sistema de los nodos de computación simplemente reiniciándolos cuando no tengan trabajos asignados. Los nodos servidores de disco también se actualizan reiniciándolos, teniendo la precaución de no reiniciar al mismo tiempo los dos nodos de un mismo AFR, lo cual provocaría la pérdida de acceso a la parte de datos que sirviesen. Una estrategia válida podría ser rebotar en primer lugar los nodos servidores de disco pares (disc2, disc4  y disc6) y una vez éstos hubiesen arrancado con el nuevo sistema reiniciar los impares (disc1, disc3 y disc5).

 

13.3. Creación de una imagen

 

Desde la consola en el interfaz de administración de Tivoli en la máquina de referencia copiamos en el servidor una copia de la partición que incluye el sistema operativo y dos ficheros, el kernel y el initial ramdisk, que nos permitirán arrancar la máquina una vez finalice el volcado del sistema:

 

BuildDiskImage(0,1,"net://global/hdimages/node.img");

CopyFile("disk://0:1/boot/vmlinuz-2.6.18","net://global/hdimages/vmlinuz-2.6.18-gluster");

CopyFile("disk://0:1:/boot/initrd.img-2.6.18","net://global/hdimages/initrd.img-2.6.18-gluster");

 

Tivoli cuenta con un potente lenguaje de programación que permite realizar muchas más operaciones además de crear y volcar imágenes. Utilizaremos Rembo-C para particionar de forma inteligente las máquinas antes de volcar el sistema. Estos scripts se guardan en el servidor y son invocados en lugar del interfaz de administrador cuando se indica explícitamente. Pueden consultarse en los apéndices [19.1.12].

 

13.4. Personalización de imágenes

 

En los capítulos anteriores hemos explicado cómo instalar y configurar los servicios necesarios para el correcto funcionamiento del cluster. En este apartado veremos los mecanismos necesarios para automatizar el proceso de configuración de nodos.

 

El script de arranque de Tivoli detecta el número de discos, si bien utilizamos como máximo 2 de ellos (en RAID) y comprueba si se trata de discos inicializados. Una máquina con discos inicializados es una máquina que ya forma parte del cluster y en la que no hay que tocar el particionamiento pues se podrían perder datos.

 

Tivoli, al detectar una máquina nueva (ningún disco inicializado), particiona sus discos de la siguiente manera:

 

partición 1: EXT2       20 GB
partición 2: SWAP        4 GB
particion 3: RAID       TAMAÑO TOTAL - TAMAÑO particion1 - TAMAÑO

particion2 - 1MB

 

Se crean un total de 3 particiones. Al arrancar el sistema operativo, el script de personalización de imagen post_boot.sh creará una cuarta en cada uno de sus discos que los marcará como "inicializados". En posteriores arranques, la existencia de esta cuarta partición hará que Tivoli se limite a restaurar la imagen de sistema sin más.

 

La casuística que se contempla a la hora de restaurar la imagen en una máquina es la siguiente:

 

1. Nodo nuevo (ningún disco inicializado)

 1.1. Con 1 disco

      * InicializarDisco(0)

 1.2. Con > 1 disco

    1.2.1. Discos de mismo tamaño

           * InicializarDisco(0)

           * InicializarDisco(1)

           * RestaurarSistema

           * ArrancarLinux

    1.2.2. Discos de distinto tamaño

           * ObtenerDiscoDeMenorTamaño

           // inicializamos los discos con el particionamiento del disco

           // de menor tamaño

           * InicializarDisco(0)

           * InizializarDisco(1)

           * RestaurarSistema

           * ArrancarLinux

 

2. Nodo del cluster (algún disco inicializado)

 2.1. Con 1 disco

          * RestaurarSistema

           * ArrancarLinux

 2.2. Con > 1 disco

   2.2.1. Dos discos inicializados

           * RestaurarSistema

           * ArrancarLinux

   2.2.2. Un disco no inicizaliado

     2.2.2.1. Tamaño(disco no inicializado) < Tamaño(disco inicializado)

              * ERROR, el disco nuevo debe ser mayor o igual que el disco inicializado

     2.2.2.2. Tamaño(disco no inicializado) >= Tamaño(disco inicializado)

              * InicializarDisco(disco no inicializado)

 

InicializarDisco(IdDisco) {

 

  * ObtenerTamañodiscoMenor

  * ParticionarDisco(IdDisco)

 

}

 

DiscoInicializado?(IdDisco) retorna BOOL {

 

  si (NumParticiones(IdDisco)<4)

     retorna FALSO;

  sino

     si (TipoPartition(IdDisco,4) == "f0")

         retorna TRUE;

     sino

         retorna FALSE;

     fsi

 fsi

 

}

 

El script rembo que controla la instalación de imágenes en los nodos bootnode-gluster.shtml se encuentra en los apéndices [19.1.12].

 

Una vez el sistema operativo se restaura en un nodo y éste arranca, se lleva a cabo la personalización del sistema en función de la identidad del nodo y su rol dentro del cluster, que llevará a cabo el script /etc/init.d/post_boot.sh. Para ello se basará en la información almacenada en fichero /root/files/nodes/nodes de los nodos master, que es una pequeña base de datos con la información de todos los nodos dados de alta.

 

Este formato del fichero de nodos es el siguiente:

 

# Listado de nodos

#

# Indica, para cada nodo, si forma parte de un OST y, en tal caso, si se

# trata de un nodo (P)rimario o (S)ecundario y quién es su pareja.

#

# Atención: Dar de alta primero a nodo primario y, posteriormente, una vez

# exporten el OST, a su secundario

#

#

# HOSTNAME   OST?   (P)ri/(S)ec   PAIRNODE        CLUSTER     MCAST_CHANNEL

# --------   ----   -----------   --------        -------     -------------

disc1      SI          P         disc2          storage      239.2.11.75

disc2      SI          S         disc1          storage      239.2.11.75

disc3      SI          P         disc4          storage      239.2.11.75

disc4      SI          S         disc3          storage      239.2.11.75

disc5      SI          P         disc6          storage      239.2.11.75

disc6      SI          S         disc5          storage      239.2.11.75

node200    NO          -         -              tenada       239.2.11.74

node102    NO          -         -              eixam        239.2.11.72

node301    NO          -         -              nozomi       239.2.11.73

node303    NO          -         -              nozomi       239.2.11.73

node104    NO          -         -              eixam        239.2.11.72

node105    NO          -         -              eixam        239.2.11.72

 

 

Tras el hostname, el campo OST? indica si el nodo en cuestión es servidor de disco. De ser "SI" el siguiente campo indicará si es un nodo primario o secundario. El siguiente campo indica qué nodo es su pairnode, es decir, el nodo con el que mantiene sus datos replicados.

 

Los dos últimos campos sirven al sistema de monitorización Ganglia para incluir el nodo en uno de los grupos y para establecer el canal multicast de comunicación con el resto de sus compañeros.

 

El script post_boot.sh copia información actualizada de los nodos master (fichero nodos, configuración de GlusterFS, usuarios, ganglia, crons, etc) y personaliza el sistema en función de la información almacenada el el fichero nodes. La casuística es la siguiente:

 

1. Ningún disco inicializado.

    1.1. Dos discos no inicializados

           1.1.1. Nodo no es servidor de disco

                     // nodo es cliente glusterFS

                    * Montamos zona common de SunGrid

                    * Montamos HOME glusterFS

           1.1.2. Nodo es servidor de disco

                     // nodo es servidor glusterFS

                    * Creamos array HOME

                    * Marcamos los discos como inicializados

                    * Montamos zona common de SunGrid

                    * Montamos HOME glusterFS

                    * Lanzamos daemon glustrerFS

    1.2. Nodo con un disco

          // nodo es cliente glusterFS

          * Montamos zona common de SunGrid

          * Montamos HOME glusterFS

    1.3. Nodo sin discos

           * ERROR

2. Dos discos inicializados

     2.1. Nodo no es servidor de disco

            // nodo es cliente glusterFS

           * Montamos zona common de SunGrid

           * Montamos HOME glusterFS

     2.2. Nodo es servidor de disco

            // nodo es servidor glusterFS

            * Lanzamos daemon glusterFS

 

Por último, en caso de tratarse de un nodo nuevo, el script lo añade a la cola correspondiente en Sun Grid con tantos slots como cores tenga la máquina. El script post_boot.sh se encuentra en los apéndices [19.1.13].

 


14. Ganglia

 

 

Ganglia es un sistema de monitorización de clusters vía web. Utiliza tecnologías como XML para la representación de los datos, XDR para compactar y mover los datos y RRDTool para el almacenamiento y la visualización. Como está pensado para trabajar con clusters formados por una gran cantidad de nodos, utiliza algoritmos y estructuras de datos que generan overheads muy pequeños entre nodos y proporcionan una alta concurrencia. Ganglia es altamente escalable, siendo capaz de monitorizar sin problemas clusters con miles de nodos.

 

Está formado por 5 componentes:

 

ganglia-dataflow

 

Figura 14.1: Daemons y flujo de datos en un sistema Ganglia

 

 

·        gmond: Es el demonio de monitorización. Se trata de un servicio ligero que se instala en todas las máquinas que queremos monitorizar. Este demonio utiliza el protocolo XDR para recoger información del estado y enviarla vía XML sobre TCP.

 

·        gmetad: Este daemon es el encargado de recolectar información servida por otros gmetad y gmond y almacena su estado en bases de datos indexadas de tipo round-robin (rrd). Gmetad provee un mecanismo sencillo para disponer de información histórica de un conjunto de máquinas.

 

·        gmetric: La Ganglia metric tool es una aplicación tipo línea de comandos que permite inyectar métricas personalizadas sobre hosts que son monitorizados por ganglia.

 

·        gstat: Es una aplicación que permite interactuar con Ganglia directamente y obtener información sobre las métricas almacenadas.

 

·        web: El frontend web expresa la información almacenada por gmetad en un interfaz web gráfico usando PHP.

 

La figura [14.1] muestra los daemons anteriormente descritos así como otros subsistemas involucrados y el flujo de datos entre ellos.

 

14.1. Instalación

 

Ganglia está disponible como paquete de software del repositorio oficial de Debian. En la distribución el software Ganglia viene separado en dos partes: ganglia-monitor, que incluye el núcleo de monitorización y el daemon encargado de recolectar de forma local los datos en cada nodo,  y gmetad, el daemon que comunica los distintos nodos.

 

Los instalamos del repositorio oficial Debian:

 

master-cluster1> apt-get install ganglia-monitor gmetad

 

Ganglia utiliza la web como medio para mostrar la información del estatus del cluster, por lo que es necesario contar con un servidor web. Instalamos el servidor web Apache[12], por ser el servidor web de uso más común en entornos UNIX y la preferencia en el Laboratorio de Cálculo.

 

Instalamos apache y los paquetes adicionales necesarios:

 

master-cluster1> apt-get install apache2 libapache2-mod-php5

 

La instalación de apache deja un servidor web operativo corriendo en el puerto 80, con los ficheros de configuración en /etc/apache2 y el repositorio web en /var/www.

 

Hacemos visible ganglia para nuestro servidor web. Para ello creamos el fichero /etc/apache2/sites-available/ganglia:

 

DocumentRoot /var/www/

 

<Directory /var/www/ganglia>

Options FollowSymLinks MultiViews

       AllowOverride None

       Order allow,deny

allow from all

</Directory>

 

Y creamos el link simbólico desde /etc/apache2/sites-enabled/ganglia. Por último hacemos un reload del servidor para que lea la nueva configuración:

 

master-cluster1> /etc/init.d/apache2 reload

 

14.2. Configuración

 

Hay dos daemons que controlan la recogida y almacenamiento de datos generados por los nodos del cluster: gmond y gmetad. Como hemos explicado, gmond es el encargado de recolectar la información local del host y compartirla vía TCP, mientras que gmetad recoge la información exportada por otros hosts y la almacena en una base de datos rrd.

 

 

Figura 14.2: Pantalla principal de  la web Ganglia

 

Configuramos las distintas colas, los nodos de almacenamiento y los nodos master como grupos segregados que se monitorizan de forma independiente. Cada uno de estos grupos comparte la información generada por gmond con el resto de máquinas de su grupo y con los nodos master. La comunicación de cada grupo se realiza por canales multicast, lo que garantiza un menor overhead de tráfico de red.

 

En los nodos de entrada master-cluster1 y master-cluster2, hay sendos demonios gmetad que recogen información de cada grupo. Igualmente, cada grupo cuenta con dos daemons gmetad que recogen la información de los nodos de su grupo. Instalamos el gmetad en dos máquinas para poder disponer de la información del grupo si uno de los dos nodos con gmetad caen.

 

La siguiente tabla muestra los distintos grupos multicast con sus direcciones de red:

 

Master nodes            239.2.11.71

eixam                   239.2.11.72

nozomi                  239.2.11.73

tenada                  239.2.11.74

storage                 239.2.11.75

 

Los ficheros gmond.conf y gmetad.conf que controlan los daemons gmond y gmetad respectivamente se encuentran en los apéndices [19.1.4] y [19.1.15].

 

14.3. Personalización

 

La información que proporciona Ganglia por defecto es enorme, pero echamos en falta información específica del sistema de colas. Por ello crearemos algunas métricas que mediante shellscripts permitan conocer el estatus del cluster: trabajos en ejecución y trabajos encolados.

 

Una métrica de Ganglia no es más que un valor numérico con una etiqueta enviado por TCP a una canal multicast mediante el comando gmetric. Este valor es recogido por el daemon gmetad y almacenado en una base de datos rrd. Posteriormente el motor Ganglia transformará los valores numéricos almacenados en información gráfica, si así lo configuramos.

14.3.1. Trabajos en ejecución:

 

Obtenemos el número de trabajos en ejecución en cada nodo mediante el script jobs_run.sh, que puede consultarse en los apéndices [19.1.16].

 

Incorporaremos el comando gmetric a un cron de root que irá enviando la información a intervalos regulares de 1 minuto:

 

# JOBS en cola prioritaria

* * * * *       /usr/bin/gmetric --name sge_jobs_run --value `/root/scripts/jobs_run.sh 2> /dev/null` -tint16 --units=procs --mcast_channel=239.2.11.72 --mcast_port=8649 --mcast_if=eth0 2> /dev/null

 

En cada cluster habrá que cambiar el canal muticast por el que corresponda. Además de monitorizar los trabajos en ejecución, monitorizamos los trabajos que se ejecutan en colas "nice", que obtenemos con el script jobs_run-slave.sh, disponible en los apéndices [19.1.17].

 

Asimismo añadimos un cron que envíe el número de trabajos en el nodo cada minuto:

 

# JOBS en cola subordinada

* * * * *       /usr/bin/gmetric --name sge_jobs_run-slave --value `/root/scripts/jobs_run-slave.sh 2> /dev/null` -tint16 --units=procs --mcast_channel=239.2.11.72 --mcast_port=8649 --mcast_if=eth0 2> /dev/null

 

El resultado es el que se muestra en la figura [ 14.3].

 

 

jobs_running

 

Figura 14.3:Gráfica de la métrica jobs_running

 

14.3.2. Trabajos encolados

                                                                                                                                       

Otra métrica interesante asociada al sistema de colas es el número de trabajos encolados. Este valor lo calcularemos en los nodos master mediante el script jobs_queued.sh. Puede encontrarse en los apéndices [19.1.18].

 

De la misma forma que hacíamos con los trabajos en ejecución, creamos una entrada en el cron de root que envíe el número de trabajos en colados al gmetad cada minuto:

 

* * * * *       /usr/bin/gmetric --name jobs_queued --value `/root/scripts/jobs_queued.sh` -tint16 --units=procs

 

 

jobs_queued

 

Figura 14.4: Gráfica de la métrica jobs_queued

 

14.3.3. Sensor de temperatura

 

La temperatura de la CPU debe mantenerse dentro de unos valores nominales. Superar cierto límite provocará de manera irremediable el fallo del nodo.

 

Creamos una nueva métrica con el valor de la temperatura de la CPU de cada nodo. Esto nos permitirá adelantarnos a posibles fallos por sobrecalentamiento cuando por ejemplo, un ventilador falle.

 

A tal efecto creamos el script temp_max.sh que devuelve la temperatura del core con el valor más alto. Su contenido puede consultarse en los apéndices [19.1.19]. Previamente el script carga el módulo de monitorización de sensores adecuado en función del tipo de CPU y del chipset detectado.

 

temperature_max.jpg

 

Figura 14.5: Gáfica de la métrica temperature_max

 

El siguiente paso es añadir el valor obtenido por esta métrica a la base de datos rrd. Como con el resto de métricas personalizadas lo hacemos utilizando el comando gmetric a intervalos de 1 minuto mediante la programación de un cron:

 

 

# Sensors

* * * * *       /usr/bin/gmetric --name temperature_max --value `/root/scripts/temp_max.sh 2> /dev/null` -tint16 --units=degrees --mcast_channel=239.2.11.72 --mcast_port=8649 --mcast_if=eth0 2> /dev/null

 

Como resultado tendremos una nueva métrica llamada temperature_max dentro de la web ganglia disponible para cada nodo del cluster.

14.3.4. Personalización web

 

El siguiente paso es procesar y mostrar en la web de Ganglia la información de las métricas que hemos creado y que se encuentran almacenadas en las bases de datos rrd. El frontend de Ganglia está programado en PHP y es fácilmente modificable.

 

En el directorio /var/www/ganglia está el código PHP con las funciones de procesamiento y visualización de los datos y en /var/www/ganglia/template los perfiles que dan forma a la web.

 

En primer lugar creamos un nuevo perfil "LSI" basado en el perfil por defecto, añadiendo la información extra que queremos mostrar. El perfil está formado por ficheros HTML con la disposición de los distintos elementos que aparecen en cada una de las páginas web de Ganglia. Modificamos los siguientes ficheros:

 

·        cluster_extra.tpl: Añadimos código que invoca a la función php que muestra el número de trabajos en ejecución del grupo en el caso de colas y el número de trabajos encolados en el caso del grupo Master nodes.

 

·        meta_view.tpl: Añadimos información acerca del volumen GlusterFS en la página principal.

 

El contenido íntegro de ambos ficheros está en los apéndices [19.1.20] y [19.1.21].

 

La función php que dibuja en pantalla las gráficas se encuentra en el archivo graph.php. Añadimos el código necesario para dibujar en pantalla las gráficas que representan los datos generados por nuestras métricas. El fichero graph.php se encuentra en los apéndices [19.1.22].

 

La figura [14.6] muestra la vista general del cluster, con una fila para cada grupo de máquinas: nodos master, colas eixam, nozomi y tenada y servidores de disco. La fila superior es un sumatorio de los recursos de todos los grupos.

 

 

 

 

Figura 14.6: Vista general del cluster

 

 

Las cuatro columnas de gráficas  muestran diferentes recursos de las colas: la carga de CPU, la utilización de la memoria, el tráfico de red e información acerca de los trabajos del sistema de colas.

 

Para cada cola se muestra el número de trabajos en ejecución  (color azul) y en ejecución en modo nice (color verde). La línea roja marca el número máximo de slots disponibles y por tanto el número máximo de trabajos concurrentes en ejecución.

 

El grupo de nodos master en el campo dedicado al sistema de colas muestra el número de trabajos en la cola de espera.

 

Adicionalmente, se muestra, en la fila correspondiente a cada cola, el espacio total y el espacio libre de la zona de disco compartida.

 

La figura [14.7] muestra el estado de una cola, con un resumen de los principales recursos: carga del sistema, uso de CPU, utilización de memoria y de red en la parte superior y el estado de los diferentes nodos que componen el cluster a continuación.

 

 

 

 

 

Cada nodo aparece coloreado según su carga. De esta forma podemos advertir estados altos de carga (color rojo) rápidamente, sin entrar a comprobar el valor numérico concreto.

 

 

 

ganglia-cluster.tiff

 

Figura 14.7: Vista de una cola

 

 

La gráfica de cada nodo muestra una métrica seleccionable desde el menú Metric de la cabecera. Por defecto se muestra la carga del sistema, pero pueden seleccionarse multitud de otras métricas, entre ellas las que hemos creado ad-hoc, como sge_jobs_run, sge_jobs_run-slave o temperature_max.

 

En la parte izquierda aparece la gráfica de trabajos en ejecución, así como información porcentual de la carga del sistema.

 

 

 

 

 

 

La figura [14.8] muestra la información de tallada de un nodo, con un resumen textual y las consabidas gráficas de carga, uso de CPU, uso de memoria y tráfico de red en la parte derecha.

 

En la parte inferior se despliegan las gráficas de todas las métricas.

 

 

ganglia-nodo.tiff

 

Figura 14.8: Vista de un nodo

 

 


15. Nagios

 

Nagios es un sistema de monitorización de redes para entornos UNIX. Examina periódicamente hosts y servicios, avisándonos cuando se produce algún comportamiento inesperado y volviendo a avisarnos cuando el servicio vuelve a la normalidad. Está especialmente indicado en la monitorización de redes con gran cantidad de componentes.

 

Nagios es la herramienta que utiliza el Laboratorio de Cálculo de LSI para monitorizar todos sus servidores y servicios.

 

En los clientes Nagios el daemon nrpe recoge las peticiones enviadas desde el servidor e invoca el plugin apropiado para obtener el valor asociado al estatus del recurso monitorizado. Cuando se produce un fallo en alguno de los servicios monitorizados el sistema nagios envía un aviso al administrador.

15.1. Instalación

 

Es necesario instalar el cliente nagios en cada uno de los hosts que queremos monitorizar. En nuestro caso lo instalamos en las dos máquinas master-cluster. De esta manera si se produce el fallo de una de las dos máquinas seguiremos pudiendo monitorizar el cluster.

 

Master-cluster1> apt-get install nagios-nrpe-server

 

15.2. Configuración

 

Monitorizaremos por una parte el estatus del servicio Sun Grid en las máquinas master (sge_master) y en los nodos de cómputo (sge_execd) y por otra la conectividad de red de los nodos servidores de disco. Esto último se hace mediante el plugin nrpe_ping, que forma parte del paquete nagios.

 

15.2.1. Configuración en cliente

 

En primer lugar es necesario configurar el cliente nagios indicando la dirección IP del servidor. Además, dado que utilizaremos un plugin que acepta parámetros, debemos indicar que queremos aceptar este tipo de plugins.También configuramos un nuevo comando que nos permitirá conocer el estatus del servicio Sun Grid mediante el script check_sge.sh.

 

Monitorizamos el servicio Sun Grid mediante el plugin check_sge.sh. Puede consultarse en los apéndices [19.1.23].

 

 

 

Los plugins nagios son scripts que deben acabar con uno de los siguientes exit status:

 

·        0: El servicio funciona correctamente.

·        1: Warning. El servicio presenta algún tipo de anomalía.

·        2: Error. El servicio no funciona.

 

La salida estándar puede ser utilizada como un medio para obtener información extra sobre el estatus del servicio, por ejemplo el motivo del fallo.

 

El plugin check_sge.sh acepta como parámetro el hostname del nodo que queremos chequear.

 

En función del hostname comprobaremos si el servicio sge_master o el servicio sge_execd está corriendo.

15.2.2. Configuración en servidor

 

La configuración del servidor nagios está formada por una serie de ficheros donde se definen los recursos a monitorizar, los comandos que se utilizarán para ello y los administradores responsables de los servicios a los que se avisará en caso de fallo.

 

El servidor Nagios departamental es la máquina karpov.lsi.upc.edu. Se trata de una máquina con sistema Linux Debian en la que se ha instalado el software nagios de Debian. Así pues, encontramos los ficheros de configuración en /etc/nagios.

 

En primer lugar definimos el cluster como un servicio a monitorizar. Para ello añadimos la información de las dos máquinas master-cluster a los ficheros hostgroup.cfg y hosts.cfg:

 

hostgroup.cfg:

 

define hostgroup{

hostgroup_name  cluster

alias           Cluster Servers

members         master-cluster1,master-cluster2

contact_groups  admins,cluster-admins

        }

 

hosts.cfg:

 

define host{

use                     generic-host

host_name               master-cluster1

alias                   master-cluster1

address                 147.83.20.221

check_command           check-host-alive

max_check_attempts      10

notification_interval   120

notification_period     24x7

notification_options    d,r

        }

 

define host{

use                     generic-host

host_name               master-cluster2

alias                   master-cluster2

address                 147.83.20.222

check_command           check-host-alive

max_check_attempts      10

notification_interval   120

notification_period     24x7

notification_options    d,r

}

 

Monitorizamos el estado de cada uno de los nodos de computación del cluster y de los propios nodos master mediante el comando check_sge. Para ello creamos tantos servicios como nodos hay en el cluster. Lo hacemos en el fichero services.cfg:

 

define service{

use                             generic-service         ; Name of service template to use

host_name                       master-cluster1,master-cluster2

service_description             node100

is_volatile                     0

check_period                    24x7

max_check_attempts              4

normal_check_interval           5

retry_check_interval            1

contact_groups                  admins,cluster-admins

notification_interval           960

notification_period             24x7

check_command                   check_nrpe_param2!check_sge!node100

}

 

Repetimos esta configuración para todos los nodos de computación del cluster. A destacar que el comando de chequeo tiene dos parámetros: el nombre del plugin y el parámetro de éste que indica el nodo que se está examinando. Debemos definir un nuevo comando de chequeo que acepte dos parámetros, ya que por defecto nagios no lo incluye. Lo definimos en el fichero de configuración checkcommands.cfg:

 

define command{

command_name    check_nrpe_param2

command_line    $USER1$/check_nrpe -H $HOSTADDRESS$ -c $ARG1$ -a $ARG2$ $ARG3$ $ARG4$

}

 

Para los nodos de disco creamos un servicio de monitorización de conectividad mediante el plugin check_ping:

 

define service{

use                             generic-service         ; Name of service template to use

host_name                       master-cluster1,master-cluster2

service_description             Disc1

is_volatile                     0

check_period                    24x7

max_check_attempts              4

normal_check_interval           5

retry_check_interval            1

contact_groups                  admins,cluster-admins

notification_interval           960

notification_period             24x7

check_command                   check_nrpe_param2!check_ping!disc2!99,99%!100,100%

}

 

Repetimos esta configuración para todos los nodos servidores de disco del cluster.

 

El Laboratorio de Cálculo dispone del un frontend web, que permite una fácil gestión de la información generada por nagios. También permite gestionar los avisos, deshabilitar chequeos, etc. Todos los servicios configurados en nagios quedan reflejados automáticamente en la web, accesible desde http://karpov.lsi.upc.edu/nagios.

 

La figura [15.1] muestra el estatus de los servicios del cluster en la web Nagios.

 

 

 

Figura 15.1: Vista de la web Nagios


16. Servicios auxiliares

 

Una vez vistos los servicios propios del cluster, vamos a tratar una serie servicios auxiliares necesarios para su correcto funcionamiento.

 

Queda fuera del objetivo de este proyecto tratar en profundidad la configuración de estos servicios, con los que se asume cierta familiaridad como administrador de sistemas, por lo que nos limitaremos a concretar las particularidades de nuestra configuración.

 

16.1. DHCP

 

DHCP (Dynamic Host Configuration Protocol) es un protocolo de red que permite a las máquinas de una red obtener la configuración de red automáticamente.

 

En el cluster los nodos se identifican por su dirección IP, que determina el rol que juegan, servidor de disco o nodo de computación. La dirección IP de un nodo es siempre la misma desde el momento en que se fija al darlo de alta. Por ello utilizamos asignación de IPs manual (o estática), que asigna la siempre la misma dirección IP en función de la dirección MAC de la tarjeta de red.

16.1.1. Instalación

 

Instalamos el servidor DHCP en las máquinas master-cluster y el cliente  en el resto de nodos:

 

master-cluster1> apt-get install dhcp3-server

 

node100> apt-get installl dhcp-client

16.1.2. Configuración del servidor

 

La configuración del servidor DHCP