Cluster para Alta disponibilidad y balanceo de carga

El término cluster se aplica a los conjuntos o conglomerados de computadoras construidos mediante la

utilización de componentes de hardware comunes y que se comportan como si fuesen una única
computadora. Hoy en día juegan un papel importante en la solución de problemas de las ciencias, las
ingenierías y del comercio moderno.

La tecnología de clusters ha evolucionado en apoyo de actividades que van desde aplicaciones de

supercómputo y software de misiones críticas, servidores Web y comercio electrónico, hasta bases de
datos de alto rendimiento, entre otros usos.

Simplemente, cluster es un grupo de múltiples ordenadores unidos mediante una red de alta velocidad,
de tal forma que el conjunto es visto como un único ordenador, más potente que los comunes de
escritorio.

Clusters son usualmente empleados para mejorar el rendimiento y/o la disponibilidad por encima de la
que es provista por un solo computador tipicamente siendo mas económico que computadores
individuales de rapidez y disponibilidad comparables.

De un cluster se espera que presente combinaciones de los siguientes servicios:

1.Alto rendimiento (High Performance)

2.Alta disponibilidad (High Availability)
3.Equilibrio de carga (Load Balancing)
4.Escalabilidad (Scalability)

La construcción de los ordenadores del cluster es más fácil y económica debido a su flexibilidad:
pueden tener todos la misma configuración de hardware y sistema operativo (cluster homogéneo),
diferente rendimiento pero con arquitecturas y sistemas operativos similares (cluster semi-homogéneo),
o tener diferente hardware y sistema operativo (cluster heterogéneo)., lo que hace más fácil y
económica su construcción.

Para que un cluster funcione como tal, no basta solo con conectar entre sí los ordenadores, sino que es
necesario proveer un sistema de manejo del cluster, el cual se encargue de interactuar con el usuario y
los procesos que corren en él para optimizar el funcionamiento.

Clasificacion de los Clusters

Alto Rendimiento

Un cluster de alto rendimiento es un conjunto de ordenadores que está diseñado para dar altas
prestaciones en cuanto a capacidad de cálculo. Los motivos para utilizar un cluster de alto rendimiento
son:

el tamaño del problema por resolver y

el precio de la máquina necesaria para resolverlo.

Por medio de un cluster se pueden conseguir capacidades de cálculo superiores a las de un ordenador
más caro que el costo conjunto de los ordenadores del cluster.
Alta disponibilidad

Un cluster de alta disponibilidad es un conjunto de dos o más máquinas que se caracterizan por
mantener una serie de servicios compartidos y por estar constantemente monitorizándose entre sí.
Podemos dividirlo en dos clases:

Alta disponibilidad de infraestructura: Si se produce un fallo de hardware en alguna de las máquinas

del cluster, el software de alta disponibilidad es capaz de arrancar automáticamente los servicios en
cualquiera de las otras máquinas del cluster (failover). Y cuando la máquina que ha fallado se recupera,
los servicios son nuevamente migrados a la máquina original (failback). Esta capacidad de
recuperación automática de servicios nos garantiza la alta disponibilidad de los servicios ofrecidos por
el cluster, minimizando así la percepción del fallo por parte de los usuarios.

Alta disponibilidad de aplicación: Si se produce un fallo del hardware o de las aplicaciones de alguna
de las máquinas del cluster, el software de alta disponibilidad es capaz de arrancar automáticamente los
servicios que han fallado en cualquiera de las otras máquinas del cluster. Y cuando la máquina que ha
fallado se recupera, los servicios son nuevamente migrados a la máquina original. Esta capacidad de
recuperación automática de servicios nos garantiza la integridad de la información, ya que no hay
pérdida de datos, y además evita molestias a los usuarios, que no tienen por qué notar que se ha
producido un problema.

Equilibrio de Carga

Un cluster de balanceo de carga o de cómputo adaptativo está compuesto por uno o más ordenadores
(llamados nodos) que actúan como frontend del cluster, y que se ocupan de repartir las peticiones de
servicio que reciba el cluster, a otros ordenadores del cluster que forman el back-end de éste.

Las características más destacadas de este tipo de cluster son:

Se puede ampliar su capacidad fácilmente añadiendo más ordenadores al cluster.

Robustez. Ante la caída de alguno de los ordenadores del cluster el servicio se puede ver mermado,
pero mientras haya ordenadores en funcionamiento, éstos seguirán dando servicio.

Cabe destacar que los 2 tipos de cluster a implementar en esta seccion son: Alta disponibilidad y
Equilibrio de carga

Equilibrio de Carga:

Esta seccion abarcara como hacer un balanceo de carga con LVS (linux virtual server). Como obtener e
instalar lvs y como configurar sus diferentes modos de operacion.

Equipamiento Logico Necesario

Centos 5
ipvsadm

Terminologias
Linux Director: Host con linux instalado quien recibe los paquetes provenientes desde los usuarios
finales o clientes y hace forward a los real servers.
Usuario final: Host o equipo que origina la conexion
Direccion IP Virtual: La direccion ip asignada al servicio que manejara linux director
Direccion IP Real: La direccion del servidor real.

LVS posee tres modos distintos de reenviar los paquetes, por lo tanto se plantean 3 escenarios
diferentes:

Network Address Translation: Este metodo aplica un simple nat donde el servidor con la ip virtual
quien se encarga de realizar el reenvio de los paquetes a los real servers detras de este. En este metodo,
los real servers deben tener como gateway por defecto el servidor con la ip virtual que esta haciendo el
nat.

Direct Routing: Los real servers le responden directamente al cliente.

1er Escenario: NAT

Como puede apreciarse, lo clientes hacen solicitud al servidor con la ip publica y este se encarga de
reenviar y mantener un balanceo de carga a los real servers ubicados detras de este.

Lvs Nat es la manera mas simple para configurar LVS. Los paquetes de los real servers son recibidos
por linux director y su direccion ip reescrita para poder responder a la consulta por parte de los clientes.

Procedimientos

Asumiendo vamos a hacer load equilibrio de carga a nuestro Website debido al gran trafico del portal
www.codigolibre.org. Nuestro servidor que esta haciendo linux director (Active Load Balancer como
muestra la grafica anterior) posee 2 interfaces de red: 1 publica (eth1) con la direccion 200.89.88.100 y
1 privada (eth0) con la direcciones 192.168.100.100.
Instalar el paquete ipvsadm

yum -y install ipvsadm

Habilitar Ip forwarding en /etc/sysctl.conf

net.ipv4.ip_forward = 1
Configurar LVS en el linux director
ipvsadm -A -t 200.89.88.100:80
ipvsadm -a -t 200.89.88.100:80 -r 192.168.100.11:80 -m
ipvsadm -a -t 200.89.88.100:80 -r 192.168.100.11:80 -m

Donde se indica claramente que todas las consultas enviadas a la ip 200.89.88.100 por el puerto 80
seran redireccionadas y balanceadas entre los 2 servidores con las ip privadas 192.168.100.10 y
192.168.100.11 respectivamente.

Asegurarse que los real servers (192.168.100.10 y 192.168.100.11) reenvien los paquetes a traves del
linux director (192.168.100.100), es decir, los real servers deben tener como default gw a linux
director.

Finalmente asegurarse tambien que los demonios de apache esten corriendo en todos los equipos.

Pruebas
Acceder desde el navegador a la ip 200.89.88.100 y al mismo tiempo correr un tcpdump en el linux
director de la para constatar como se balancea la carga a los real servers.

Tcpdump -i eth1 port 80

Ejecutar el comando ipvsadm -L –stats para mostrar la cantidad de bytes enviados por cada uno de los
real servers.

Ipvsadm -L -n muestra la cantidad de conexiones activas en los real servers.

2do Escenario: Direct Routing

LVS Direct Routing trabaja reenviando los paquetes sin cambiar el encabezado ip. A diferencia de de
NAT quienes responden las solicitudes directamente son los real servers.

Como los paquetes entrantes no son modificados por linux director, por lo tanto no necesitan pasar a
traves de este de regreso al cliente.

Procedimientos

Habilitar Ip forwarding en /etc/sysctl.conf

net.ipv4.ip_forward = 1
Configurar LVS en el linux director
ipvsadm -A -t 200.89.88.100:80
ipvsadm -a -t 200.89.88.100:80 -r 192.168.100.11:80 -g
ipvsadm -a -t 200.89.88.100:80 -r 192.168.100.11:80 -g
ipvsadm -a -t 200.89.88.100:80 -r 192.168.100.11:80 -g

Donde: la opcion -g

Los real servers pueden responder los paquetes directamente a los clientes sin necesidad de ser
alterados por linux director. Linux director no necesita ser gateway de los real servers.

Asegurarse que los demonios solicitados estan corriendo.

Agregar una ip virtual al loopback de los real server
ifconfig lo:0 200.89.88.100 netmask 255.255.255.255
Pruebas

Realizar las mismas pruebas que con el escenario del nat.

Alta Disponibilidad

Esta seccion indica como realizar un escenario de alta disponibilidad donde 2 equipos conectados, uno
en modo activo y otro en modo pasivo compartiendo una misma direccion ip de manera virtual. La idea
es que cuando el servidor activo falle, el pasivo asume toda la responsabilidad mientras el activo vuelve
y se recupera.

Equipamiento Logico Necesario

Centos 5
heartbeat

Escenario:

Como podemos apreciar en el grafico anterior. El escenario se compone de 2 equipos, uno en estado
activo y el otro en estado pasivo y compartiendo una direccion ip en comun. Cuando el servidor con la
direccion ip 172.22.200.28 falle entonces la ip en comun 172.22.200.1 es trasladada al servidor
172.22.200.29 que se encontraba en modo pasivo para cualquier eventualidad.

Procedimientos

yum -y install heartbeat heartbeat-pils heartbeat-stonith heartbeat-ldirectord

Editar /etc/hosts en ambos equipos y agregar las direcciones y nombres de cada uno
vim /etc/hosts

172.22.200.28 activo.fcld.local
172.22.200.29 pasivo.fcld.local

Copiamos los archivos ha.cf haresources y authkeys desde /usr/share/docs/heartbeat{version} al

directorio de configuracion de heartbeat /etc/ha.d.

Editamos ha.cf y agregamos o descomentamos si ya existen las siguientes opciones:

debugfile /var/log/ha-debug #Esta opcion es para el proceso de depuracion de errores

logfile /var/log/ha-log #Esta opcion es para genera el directorio de los log de heartbeat
logfacility local0 #Servicio de syslog
keepalive 2 #Pulsacion cada 2 segundo
deadtime 30#Tiempo de control de fallos
warntime 10#Segundos antes de publicar el ultimo latidos, advierte a los registros
initdead 120 #para que no empiece a funcionar apenas arranque la PC, esto es depende cuanto se
demore para cargar todos los servicios al arrancar, recomendable 3 veces o mas del deadtime.

watchdog /dev/watchdog #por si queremos usar watchdog en conjunto con heartbeat"recomendado"

udpport 694 #puerto que usa para el latido

ucast eth0 172.22.200.28 (En el otro equipo pasivo.fcld.local esta opcion seria entonces la interfaz
172.22.200.29) #Que interfaz vamos a usar para el latido
auto_failback on #si queremos o no restablecer el orden de nodo1 "Primario" y nodo2 "Secundario"
node activo.fcld.local #Debe de ser el mismo del siguiente comando uname -n
node pasivo.fcld.local
ping 172.22.200.1 #Dirección del Router
respawn hacluster /usr/lib/heartbeat/ipfail
deadping 30 #Declara el nodo muerto despues 30 segundo si no responde

Editamos el archivo /etc/ha.d/haresources para indicarle los recursos que va a monitorear

Agregamos al final la interfaz + el servicio
activo.fcld.local 172.22.200.1 httpd

Aqui le decimos que el servicio a monitorear es apache por esa direccion ip

[root@asterisk ~]#( echo -ne "auth 1\n1 sha1 "; dd if=/dev/urandom bs=512 count=1 | openssl md5 )
> /etc/ha.d/authkeys; chmod 0600 /etc/ha.d/authkeys
Con este comando generamos una clave aleatoria con sha1 y es escrita en el archivo /etc/ha.d/authkeys.
Nota: Este archivo debe ser el mismo para ambos nodos
Finalmente reiniciamos el servicio heartbeat
/etc/init.d/heartbeat restart
Pruebas

Tratar de acceder por la interfaz 172.22.200.1 via web y en ese momento reiniciar el equipo
activo.fcld.local y vera a traves de /var/log/messages como pasivo.fcld.local adquiere la ip virtual
172.22.200.1.