Professional Documents
Culture Documents
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.
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.
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:
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 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.
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.
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.
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
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.
Ejecutar el comando ipvsadm -L –stats para mostrar la cantidad de bytes enviados por cada uno de los
real servers.
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
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.
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.
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
172.22.200.28 activo.fcld.local
172.22.200.29 pasivo.fcld.local
[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.