PDF de programación - Pasos para crear un cluster

Pasos para crear un cluster

Sergio GonzÆlez GonzÆlez

[email protected]

Documento en el que se explican los pasos necesarios, sin entrar en profundidad, para montar dos tipos
de clusters: de alta disponibilidad (HA) y de alto rendimiento (HP).

1. Introduccin

La nalidad de este documento es explicar de forma breve cmo montar dos tipos de clusters: aquellos
destinados a la alta disponibilidad y los destinados al alto rendimiento. El primer tipo utilizarÆ las tecnologas:
Ultra Monkey (http://www.ultramonkey.org/): (HeartBeat (http://www.linux-ha.org/heartbeat/), LVS
(http://www.linuxvirtualserver.org/), Ldirectord (http://www.vergenet.net/linux/ldirectord/), MON
(http://www.kernel.org/software/mon/)) y NTP (http://www.ntp.org/), entre otras; y el segundo: OpenMosix
(http://openmosix.sf.net/).

Este documento estÆ basado en la rama de desarrollo de la distribucin Debian GNU/Linux
(http://www.debian.org/), mÆs conocida como Sid (http://www.debian.org/releases/sid/). Aunque los pasos que
aqu se detallan son fÆcilmente adaptables a otras distribuciones de GNU/Linux.

TambiØn se destaca que para leer este documento se han de poseer unos conocimientos avanzados en
administracin de sistemas GNU/Linux, ya sean para congurar aspectos como la red, el nœcleo Linux
(http://www.kernel.org/) o distintas partes del sistema. Aspectos que no entran dentro de este artculo y de los
cuales existe una documentacin muy extensa, como la que se lista en el apartado:
Documentacin general sobre GNU/Linux de la Bibliografa.

1.1. Tipos de clusters: conceptos bÆsicos

Normalmente, al diseæar un cluster se piensa en solucionar alguno de los siguientes problemas:

Mejora de rendimiento
Abaratamiento del coste
Distribucin de factores de riesgo del sistema
Escalabilidad

Para solucionar este tipo de problemas, se han implementado distintas soluciones. Aqu veremos dos de ellas:
cluster de alta disponibilidad y de alto rendimiento.

1

Nota: Los clusters de alta disponibilidad son bastante ortogonales a los clusters de alto rendimiento, en lo
relativo a funcionalidad. Los clusters de alta disponibilidad pretenden dar servicios 24*7, de cualquier tipo,
son clusters donde la principal funcionalidad es estar controlando y actuando para que un servicio, o varios,
se encuentren activos durante el mÆximo perodo de tiempo posible.

Pasos para crear un cluster

Nota: Los clusters de alto rendimiento han sido creados para compartir el recurso mÆs valioso de un
ordenador: el tiempo de proceso. Generalmente se utilizan en ambientes cientcos o en grandes empresas,
donde se utilizan para la compilacin o renderizacin. Cualquier operacin que necesite altos tiempos de
CPU y millones de operaciones, puede ser utilizada en un cluster de alto rendimiento, siempre que se
encuentre un algoritmo que sea paralelizable. Existen clusters que pueden ser denominados de alto
rendimiento tanto a nivel de sistema como a nivel de aplicacin. A nivel de sistema tenemos openMosix (el
que trataremos en esta documentacin), mientras que a nivel de aplicacin se encuentran otros como MPI,
PVM, Beowulf y otros muchos. En cualquier caso, estos clusters hacen uso de la capacidad de
procesamiento que pueden tener varias mÆquinas.

2. Cluster de alta disponibilidad, Ultra Monkey

Actualmente existen muchos proyectos destinados a proveer de alta disponibilidad a un sistema, uno de ellos es
Ultra Monkey (http://www.ultramonkey.org/) (es el que se ha utilizado como base para esta documentacin).
Ultra Monkey es un proyecto que integra distintas herramientas de Software Libre para conseguir balanceo de
carga y alta disponibilidad en redes de Ærea local. Estas herramientas son: LVS, HearBeat, Ldirectord y MON,
que se denirÆn en los siguientes apartados.

2.1. Componentes de Ultra Monkey

2.1.1. LVS (Linux Virtual Server)

LVS se implementa como un conjunto de parches al kernel Linux y un programa de espacio de usuario
denominado ipvsadm. El sistema que tiene instalado LVS es denominado director o balanceador de carga, cuya
funcin no es otra que balancear las peticiones de red que recibe entre un conjunto de servidores reales que se
encuentran detrÆs de Øl.

LVS funciona a nivel TCP/IP, lo que se conoce como un conmutador de nivel 4. Lo que ve LVS son direcciones y
puertos de origen y destino, y toma decisiones para balancear la carga con esta informacin. LVS toma las
decisiones cuando se abre una conexin (SYN), manteniendo una tabla de conexiones, para saber a que servidor
real1 enviar un paquete perteneciente a una conexin ya establecida. Por lo tanto, el balanceo de carga que realiza
LVS tiene, en principio, granularidad2 a nivel de conexin.

LVS permite balancear muchos protocolos distintos, en principio puede balancear cualquier protocolo que
trabaje en un solo puerto, y puede trabajar con protocolos que usen varios puertos, mediante persistencia o
marcas de rewall.

2

Pasos para crear un cluster

Cuando se usan servicios persistentes, cada entrada en la tabla de LVS ya no corresponde a una conexin TCP
(direcciones y puertos de origen y destino), sino que slo usa las direcciones para identicar una conexin (se
pierde granularidad).

Se puede usar iptables (http://www.iptables.org/) o ipchains para marcar los paquetes pertenecientes a un
servicio virtual (con una marca de rewall) y usar esa marca para que LVS identique los paquetes
pertenecientes al servicio virtual.

LVS se ha usado con HTTP, HTTPS, Telnet, FTP, Squid, servidores de streaming QT, Real y Windows Media,
incluso se ha empezado a aæadirle soporte para IPSec (FreeSWAN (http://www.freeswan.org/)).

LVS realiza balanceo de carga y facilita la alta disponibilidad entre los servidores reales (si alguno deja de
funcionar, se elimina del cluster mediante ipvsadm; cuando vuelva a estar operativo, se aæade de nuevo con
ipvsadm). Sin embargo, el balanceador de carga pasa a ser un SPOF3, si se quiere alta disponibilidad se tiene que
aæadir un balanceador de respaldo y usar software de alta disponibilidad que le permita tomar el papel del
balanceador de carga principal, esto lo conseguimos con HearBeat.

2.1.2. HearBeat

Esta tecnologa implementa heartbeats, cuya traduccin directa sera: «latidos de corazn». Funciona enviando
peridicamente un paquete, que si no llegara, indicara que un servidor no estÆ disponible, por lo tanto se sabe
que el servidor ha cado y se toman las medidas necesarias.

Dichos latidos se pueden enviar por una linea serie, por UDP o por PPP/UDP. De hecho los desarrolladores de
HeartBeat recomiendan el uso de puertos serie por varias razones, entre las que destacan que estÆn aislados de
las tarjetas de red.

TambiØn incluye toma de una direccin IP y un modelo de recursos, incluyendo grupos de recursos. Soporta
mœltiples direcciones IP y un modelo servidor primario/secundario. Se ha probado satisfactoriamente en varias
aplicaciones, como son: servidores DNS, servidores proxy de cachØ, servidores web y servidores directores de
LVS. El proyecto LVS recomienda HeartBeat para aumentar la disponibilidad de su solucin, pero no es parte de
LVS.

En Linux-HA (http://www.linux-ha.org/) Heartbeat es un servicio de bajo nivel. Cuando un ordenador se une al
cluster, se considera que el ordenador se ha unido al canal de comunicaciones, por lo tanto «late»; cuando sale,
implica que ha dejado el canal de comunicaciones.

Cuando un ordenador deja de «latir» y se considera muerto, se hace una transicin en el cluster. La mayora de
los mensajes de manejo del cluster que no son heartbeats se realizan durante estas transiciones.

Los mensajes de Heartbeat se envan por todas las lineas de comunicacin a la vez, de esta manera, si una linea
de apoyo cae, se avisarÆ de ese problema antes de que la linea principal caiga y no haya una lnea secundaria
para continuar el servicio.

Heartbeat tambiØn se preocupa por la seguridad, permitiendo rmar los paquetes con CRC de 32 bits, MD5 y

3

Pasos para crear un cluster

SHA1. Esto puede evitar el desastre que podra provocarse si un nodo no miembro se enmascarase como nodo
miembro del cluster. El problema es que el entorno donde se ejecuta Heartbeat no debe parar nunca y con suerte
ese entorno se mantendrÆ comunicado y funcionando durante aæos.

Hay varias operaciones de mantenimiento de seguridad que necesitan ser efectuadas en ese tiempo, como pueden
ser cambio de claves y de protocolos de autenticacin. Heartbeat estÆ preparado para esos cambios disponiendo
de cheros para la conguracin.

Heartbeat tiene el problema, si no se dispone de una lnea dedicada, aunque Østa sea una lnea serie, al tener un
trÆco que aunque pequeæo es constante, suele dar muchas colisiones con otros trÆcos que puedan ir por la
misma red. Por ejemplo, openMosix y Heartbeat en una misma red que no tenga gran ancho de banda no
funcionan bien, sobre todo si hay bastantes nodos, pues los heartbeats se envan de cualquier nodo a cualquier
nodo, por lo que podran llegar a ser un trÆco voluminoso.

2.1.3. Ldirectord

Pensado especialmente para ser usado junto con LVS, utiliza Heartbeat. Monitoriza que los servidores reales
sigan funcionando peridicamente, enviando una peticin a una url conocida y comprobando que la respuesta
contenga una cadena concreta. Si un servidor real falla, entonces el servidor es quitado del conjunto de
servidores reales y serÆ reinsertado cuando vuelva a funcionar correctamente. Si todos los