UNIDAD 4.

MIDDLEWARES

4.1 CLUSTER DE ALTA DISPONIBILIDAD

CONTENIDO
CONCEPTOS INICIALES........................................................................................................................2
RECONFIGURACIONES DE UN CLÚSTER DE ALTA DISPONIBILIDAD.......................................3
RECURSOS CON TOLERANCIA A FALLOS Y SU SOPORTE DE ALTA DISPONIBILIDAD EN
UN CLUSTER...........................................................................................................................................4
LINUX VIRTUAL SERVER.....................................................................................................................5
Configuraciones de LVS........................................................................................................................5
Algoritmos.............................................................................................................................................6
Interfaces para LVS...............................................................................................................................8
ARQUITECTURA DEL CLUSTER DE ALTA DISPONIBILIDAD (EJEMPLO) CON TOLERANCIA
A FALLOS MEDIANTE LVS...................................................................................................................9
KEEPALIVED EN MAQUINAS VIRTUALES (VIRTUALBOX)........................................................13
BIBLIOGRAFIA:....................................................................................................................................15
CONCEPTOS INICIALES

SISTEMAS TOLERANTES A FALLOS.

Son sistemas que saben que hacer cuando se presenta algun error para seguir dando
servicio. En el principio de la computación basada en cluster, la tolerancia a fallos era
proporcionada por los grandes fabricantes que mediante hardware muy caro y propietario
que garantizaban algunas situaciones de error (fallas eléctricas, fallas en algunos equipos
(cintas, discos), fallas en redes, etc).
Con el paso del tiempo y el empuje de la alta disponibilidad se fueron creando soluciones
mucho mas económicas y accesibles a la mayoría de las empresas.

ALTA DISPONIBILIDAD

La alta disponibilidad (HA, high availability) está basada en la duplicidad de elementos, que
resulta mucho más económico que un sólo elemento propietario tolerante a fallos . Si se
habla de replicar servidores, entonces nos referimos a un clúster de alta disponibilidad
En la actualidad el avance de los sistemas HA han incluido sin mucho problema
características de tolerancia a fallos, ya que va implícita en ella.
RECONFIGURACIONES DE UN CLÚSTER DE ALTA
DISPONIBILIDAD
Es la dinámica que seguirán los nodos de un clúster HA al responder a una falla

Failover
Es un término genérico que se usa cuando un nodo debe cubrir a otro nodo que ha fallado,
sin importar sus recursos y manteniendo el servicio activo. El failover es una situación
excepcional, para la cual se ha creado la alta disponibilidad. También se ha de entender que
el servicio de datos debe seguir levantado, que es el objetivo de la alta disponibilidad.

Takeover
Es un failover automático que se produce cuando un nodo de control nota un fallo en el
servicio. El takeover requiere monitorización en el servicio para detectar el fallo. El nodo que
se declara fallido es forzado a ceder el servicio y recursos, o simplemente eliminado.

Switchover o Giveaway
Es un failover manual, consiste en ceder los recursos de un servicio ( o el servicio mismo) a
otro nodo del clúster, mientras se realizan ciertas tareas administrativas. A este
procedimiento se le denomina “Node outage”.

Splitbrain
Para la administración de un clúster HA es necesario un mecanismo de comunicación y
verificación de los nodos que lo forman. Por este mecanismo, cada nodo debe administrar los
recursos que le corresponden, segun el estado del clúster. A su vez cada nodo debe hacer
chequeos o latidos (beats) a sus compañeros.

Un Splitbrain (división de cerebros) es un caso especial de failover, en el cual falla el

mecanismo de comunicación y administración de los nodos en un clúster. Es una situación
en la cual cada nodo cree que es el único activo, y como no puede saber el estado de sus
nodos compañeros, tomará acciones en consecuencia, forzando un takeover.
Esta situación es peligrosa, ya que los nodos intentaran apropiarse de los recursos que
supone no atendidos. El peligro aumenta sobre todo cuando se tienen recursos delicados,
como almacenamiento, ya que cada nodo podría tomar y escribir por su cuenta, y
comprometer la integridad de los datos.
Para evitar este problema, cada nodo debe actuar de una forma prudente, y utilizar los
recursos compartidos como señal de que se esta vivo.
Después de que un nodo detecta este problema, tiene que reservar un recurso llamado
quorum. Un recurso quorum, es un recurso compartido, que se ha preestablecido en los
nodos. Este es un recurso exclusivo, sólo un nodo del cluster puede reservarlo. Como este
recurso sólo puede ser reservado por un nodo, el nodo que llegue tarde a la reserva del
recurso, entiende que debe abandonar el clúster y ceder todos sus recursos. El quórum es
utilizado simplemente como método de decisión cuando falla la comunicación.
Otra forma de evitar esta situación, un poco mas violenta, es que un nodo elimine a su
compañero; el primero que apague a su compañero se queda con todos los recursos. Es un
mecanismo muy brusco, pero muy eficaz.
RECURSOS CON TOLERANCIA A FALLOS Y SU
SOPORTE DE ALTA DISPONIBILIDAD EN UN CLUSTER

Los recursos que se pueden replicar son: Unidades de Procesamiento (CPU, Cores), equipos
de comunicaciones (red, NIC, switchs, router, etc) y almacenamiento (Cintas, DVD, disco
duro, RAID, almacenamiento en nube, etc).

Nivel Descripción SW en Linux

CPU. Consiste en la capacidad de Hay SW especial como Condor y
mover programas en OpenMosix que permiten la migración
funcionamiento entre nodos, se de tareas mediante el encapsulamiento
le llama tambien migración de al estilo java con su JVM. Sin embargo
procesos en caliente. el objetivo de estos software no es la
alta disponibilidad
Comunicaciones Las NIC junto con la pila de Linux cuenta con una variedad amplia
protocolos de red, deben ser de herramientas para configurar de
capaces de responder a varias diversas formas, las redes acorde a lo
direcciones de red con el fin de que el cliente requiere. Unas las
dar flexibilidad al servicio de herramientas mas usadas para este fin
transferencia de datos. es LVS con sus diferentes interfaces.
Almacenamiento Los servicios de almacenamien- Linux cuenta con dos categorías de
to son quizás uno de los puntos programas para este fin.
mas delicados de la alta Sistemas de disco:
disponibilidad. Pues en ellos • Redundant Array of
tendremos la aplicación junto Independent Disks (RAID)
con los datos que se usarán. • Logical Volume Management
(LVM)
Sistemas de archivo con registro:
• ext4
• Reiserfs
• JFS
• XFS
LINUX VIRTUAL SERVER
LVS permite crear un clúster de balanceo de carga, en el cual hay un nodo encargado de
gestionar y repartir las conexiones (nodo máster LVS) entre todos los nodos slave del clúster.
El servicio de datos debe residir en todos los nodos slave. LVS puede llegar a soportar sin
problemas hasta 200 nodos slave.

El balanceo de la carga es una técnica que se utiliza para repartir el trabajo entre varios
procesos, ordenadores, discos u otros recursos. El balanceo de carga se puede hacer
mediante diferentes algoritmos.

LVS ademas permite balancear la carga entre varios servidores. LVS está integrado dentro
del kernel de Linux con lo cual se consigue un mejor rendimiento. Aunado a esto existe gran
cantidad de documentación en la red. LVS también es la opción más genérica, con LVS se
puede balancear tanto HTTP ,FTP ,MySQL o cualquier otro protocolo de red.

Configuraciones de LVS.
LVS nos permite diferentes configuraciones de red. Las configuraciones que disponemos
son:
• NAT: Con esta técnica se modifica el datagrama IP. En esta técnica hay un dispositivo
intermedio actuando como puerta de enlace. Este dispositivo recibe un paquete,
modifica el datagrama, y lo envía a uno de los servidores que tenga asignado para ese
servicio. El servidor procesa esa petición y se la envía a la puerta de enlace de nuevo.
La puerta de enlace vuelve a cambiar el datagrama y se lo envía al cliente. La
configuración de un servidor virtual mediante NAT es muy transparente, ya que no
requiere modificaciones ni configuraciones especiales en los sistemas operativos de
los servidores reales, lo cual facilita su implementación. Una de las principales
desventajas de esta técnica es que los servidores deben de encontrarse en la misma
red que el balanceador pero esto no es un gran impedimento.
La principal desventaja de esta técnica es el cuello de botella que puede causar el
tener que pasar todos los paquetes tanto de ida como de vuelta por la puerta de
enlace. En este caso el balanceador tiene que cambiar tanto la dirección IP como la
MAC de los paquetes de los clientes y de los servidores reales.
• Direct Routing(Enrutamiento directo): En este caso el balanceador de carga sigue
siendo el que recibe las peticiones pero son los servidores los que envían la
respuesta. El balanceador y los servidores deben de estar conectados por una LAN.
En esta técnica el principal inconveniente es el Protocolo de Resolución de
Direcciones (ARP), ya que todos los servidores reales tienen que saber que la ip
virtual es suya, pero si lo ponemos en una interfaz física con ARP, todos dirán que la
dirección virtual es la suya. Para arreglar esto hay dos métodos, unos es desactivar el
ARP de los servidores, por lo que ya solo el balanceador contestará y otra es
asignarle la dirección a la interfaz loopback, por lo que el servidor real sabrá que
pertenece a él pero no contestará a las peticiones arp ya que son en otra red. Para
que funcione bien, los servidores no deben responder a los mensajes ARP. En este
caso el balanceador de carga solo tiene que cambiar la dirección MAC para
direccionar las peticiones al servidor real.
 • IP Tunneling(Encapsulación IP): En el IP Tunneling, los servidores no tienen que estar
conectados directamente a una red donde se encuentre el balanceador. En este caso
el balanceador recibe el datagrama del cliente con destino el servicio virtual. El
datagrama lo reenvía con dirección Ip del cliente como origen y dirección IP del
servicio virtual como destino, este datagrama va metido dentro de otro datagrama con
dirección Ip del balanceador como origen y dirección Ip del servidor como destino. El
paquete pueden ser enviados por dispositivos intermedios como routers.

Algoritmos.
Estas configuraciones de red pueden utilizar diferentes algoritmos para balancear las cargas.
Los algoritmos que podemos utilizar son:

Round-Robin (rr):
La clásica cola Round Robin o FIFO: cada petición se envía a un servidor, y la siguiente
petición al siguiente servidor de la lista, hasta llegar al último tras lo cual se vuelve a enviar al
primero.
Es la solución más sencilla y que menos recursos consume, a pesar de que no es la más
justa, es posible que toda la carga “pesada” vaya a parar al mismo servidor mientras que el
resto sólo reciban peticiones triviales.
Un problema de este método es que todos los servidores recibirán el mismo número de
peticiones, independientemente de si su potencia de cálculo es la misma o no.

Weighted Round-Robin (wrr):

Este algoritmo es igual que el anterior, pero añadiendo un “peso” a cada servidor. Este peso
no es mas que un entero que indica la potencia de cálculo del servidor, de forma que la cola
Round Robin se modificará para que aquellos servidores con mayor potencia de calculo
reciban peticiones más a menudo que el resto. Por ejemplo, si tenemos tres servidores A, B y
C, con una cola Round Robin normal la secuencia de distribución tendrá tres pasos y será
ABC. Si usamos una Round Robin Ponderada y asignamos pesos 4, 3 y 2 respectivamente a
cada servidor, la cola ahora distribuirá en nueve pasos (4+3+2) y una posible planificación de
acuerdo a estos pesos sería AABABCABC.
El problema de este método es que, si bien asegura que los servidores más capaces reciban
mas carga, también por probabilidad acabarán recibiendo más peticiones “pesadas”, con lo
que a pesar de todo podrían llegar a sobrecargarse.

Least-Connection (lc):
Este mecanismo de distribución consulta a los servidores para ver en cada momento cuántas
conexiones abiertas tiene cada uno con los clientes, y envía cada petición al servidor que
menos conexiones tenga en ese momento. Es una forma de distribuir las peticiones hacia los
servidores con menos carga.
A pesar de que sobre el papel parece que este método si que será capaz de repartir la carga
sobre todos los servidores de una forma equitativa. En la práctica falla cuando la potencia de
los servidores no es la misma: si todos tienen más o menos las mismas características, este
algoritmo funciona como se espera, si hay diferencias en las prestaciones de los equipos, lo
que ocurre en la práctica es que debido a la espera en TIME_WAIT de las conexiones
perdidas (alrededor de 2 minutos por lo general), los servidores rápidos tendrán en un
momento dado una gran cantidad de conexiones activas siendo atendidas, y otra cantidad
también grande de conexiones realmente inactivas, pero aún abiertas en TIME_WAIT,
mientras que los servidores lentos tendrán muchas menos conexiones tanto activas como en
TIME_WAIT, de forma que se enviará más carga a los servidores lentos.

Weighted Least-Connection (wlc):

Al igual que la estrategia Round Robin Ponderada, en este algoritmo se coge el anterior y se
le añaden unos pesos a los servidores que de alguna forma midan su capacidad de cálculo,
para modificar la preferencia a la hora de escoger uno u otro según este peso.

Locality-Bassed Least-Connection (lblc):

Este algoritmo intenta asignar conexiones a la misma IP hacia un servidor real. Este método
es frecuentemente empleado en compañía de proxys http.

Locality-Bassed Least-Connection with Replication (lblcr):

Se trata de una variante de Locality-Bassed Least-Connection la cual permite a un grupo de
servidores mantener una dirección IP dada en situaciones con mucha carga.

Source-Hashing/Destination-Hashing (sh/dh):
En estos dos últimos métodos se dispone de una tabla de asignaciones fijas, en las que bien
por la IP de origen o de destino, se indica qué servidor deberá atender la petición.
El balanceador compara las direcciones de los paquetes TCP/IP que reciba con estas tablas
y actúa en consecuencia.

Shortest Expected Delay (sed):

Dirige las conexiones al servidor real cuya respuesta sea la más rápida.

Never Queue (nq):

Dirige una conexión al servidor real que esté libre si es que hay alguno, si esto no fuese
posible emplea el algoritmo Shortest Expected Delay altgorithm.
Interfaces para LVS
KeepAlived
El objetivo principal del proyecto es el de proporcionar alta disponibilidad al proyecto Linux
Virtual Server.
KeepAlived es un servicio que monitoriza el estado del cluster LVS para que en caso de fallo
el cluster siga en funcionamiento.

UltraMonkey
Es una solución que se basa en LVS y Heartbeat para ofrecer clústers de alta disponibilidad y
balanceo de carga. El nodo máster LVS se pone en alta disponibilidad. Además incorpora
una interfaz para configurar el clúster.

Pirahna
Es el nombre que Red Hat ha dado a su solución basada en LVS, el añadido es una interfaz
para configurarlo.

Kimberlite
Es considerado un proyecto único ya que es una completa infraestructura de alta
disponibilidad de código abierto que incluye incluso garantía sobre la integridad de los datos.
Es una solución que soporta un clúster de 2 nodos. Permite fácilmente, definir un dispositivo
de quórum, monitorizar los servicios de datos, así como gestionarlo.
ARQUITECTURA DEL CLUSTER DE ALTA
DISPONIBILIDAD (EJEMPLO) CON TOLERANCIA A
FALLOS MEDIANTE LVS

A
Instalar dos maquinas con servidor web Apache
Poner en cada una una pagina diferente
Configurar IP y GW como se indica en el diagrama

Instalar y configurar LVS con keepalived en dos maquinas que funcionaran como routers:
$sudo apt-get update
$sudo apt-get upgrade
$sudo apt-get install keepalived
$sudo nano /etc/keepalived/keepalived.conf (ver la siguiente pagina para conf. de c/u)
Configurar en cada maquina las ips reales que se indican en el diagrama

Algunos comandos necesarios:

• Desabilitar firewall de ubuntu

$ufw disable

• Activar que demonio de keepalived se active al encender maquina y prueba de que se

quedo activado.
$sudo systemctl enable keepalived
$modprobe ip_vs

• Para que Keepalived sea capaz de rastrear las conexiones entre los servidores y
volver a asignar las direcciones IP flotantes entre los routers según sea necesario,se
necesita hacer los siguientes ajustes al nf_conntrack (que rastrea las conexiones entre
servidores)
$modprobe nf_conntrack //Verifica modulo
$nano /etc/sysctl.conf
Ajustes al final del archivo:
net.ipv4.ip_forward = 1
net.ipv4.ip_nonlocal_bind = 1
net.nf_conntrack_max = 1000000
$sudo sysctl -p

• Iniciar keepalived
$sudo systemctl start keepalived

• Detener keepalived
$sudo systemctl stop keepalived

• Verificar si las direcciones virtuales estan asignadas a las direcciones fisicas.

$ip addr show
Monstrara lo siguiente:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP
group default qlen 1000
link/ether 54:ab:3a:3a:b8:c0 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.120/24 brd 192.168.1.255 scope global enp2s0
valid_lft forever preferred_lft forever
inet 192.168.1.200/32 scope global enp2s0
valid_lft forever preferred_lft forever
inet6 fe80::1487:a046:3494:e775/64 scope link
valid_lft forever preferred_lft forever
3: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group
default qlen 1000
link/ether a8:a7:95:20:13:53 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.110/24 brd 192.168.1.255 scope global wlp3s0
valid_lft forever preferred_lft forever
inet 192.168.1.100/32 scope global wlp3s0
valid_lft forever preferred_lft forever
inet6 fe80::de03:38c4:b8d3:96b7/64 scope link
valid_lft forever preferred_lft forever
CONFIGURACIONES DEL ARCHIVO /etc/keepalive/keepalive.conf
LVS-1 LVS-2
vrrp_instance IPVirtualDentro { vrrp_instance IPVirtualDentro {
state MASTER state BACKUP
interface enp2s0 interface enp3s0
virtual_router_id 51 virtual_router_id 51
priority 150 priority 150
advert_int 1 advert_int 1

virtual_ipaddress { 192.168.1.200 } virtual_ipaddress { 192.168.1.200 }

track_interface { enp2s0 wlp3s0 } track_interface { enp3s0 wlo1 }
} }

vrrp_instance IPVirtualFuera { vrrp_instance IPVirtualFuera {

state MASTER state BACKUP
interface wlp3s0 interface wlo1
virtual_router_id 52 virtual_router_id 52
priority 150 priority 150
advert_int 1 advert_int 1

virtual_ipaddress { 192.168.1.100 } virtual_ipaddress { 192.168.1.100 }

track_interface { enp2s0 wlp3s0 } track_interface { enp3s0 wlo1 }
} }

virtual_server 192.168.1.100 80 { virtual_server 192.168.1.100 80 {

delay_loop 30 delay_loop 30
lb_algo rr lb_algo rr
lb_kind NAT lb_kind NAT
protocol TCP protocol TCP

# web server#1 # web server#1

real_server 192.168.1.231 80 { real_server 192.168.1.231 80 {
weight 1 weight 1
TCP_CHECK { TCP_CHECK {
connect_port 80 connect_port 80
connect_timeout 3 connect_timeout 3
} }
} }
# web server#2 # web server#2
real_server 192.168.1.232 80 { real_server 192.168.1.232 80 {
weight 1 weight 1
TCP_CHECK { TCP_CHECK {
connect_port 80 connect_port 80
connect_timeout 3 connect_timeout 3
} }
} }
} }
KEEPALIVED EN MAQUINAS VIRTUALES (VIRTUALBOX)
Crear 1 VM con lubuntu 16.04 y Guest Additions
sudo apt-get update
sudo apt-get upgrade
sudo apt-get install make gcc
Carga CD de Guest Additions en la VM
Ejecutar del CD $sudo ./VboxLinuxAdditions.run

Clonar 3 copias mas de la MV

Para cada una no olvidar crear nueva mac. Sino en configuracion
Dos VM como routers para proporcionar alta disponibilidad
Dos VM como servidores web replicados con alta disponibilidad y con balance de carga

Configurar IP fija en Routers para que funcione en VirtualBox

Cambiar nombre del hostname a router1VBox o router2VBox con: $sudo gedit
/etc/hostname

Configurar el archivo de interfaces, definiendo ip,address,netmask,broadcast,gateway y dns

así como el modo estático con : $ sudo gedit /etc/network/interfaces

Dentro de interfaces poner:

# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto enp0s3
iface enp0s3 inet static
address 192.168.1.101
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
gateway 192.168.1.1
dns-nameservers 8.8.8.8 8.8.4.4

Modificar el archivo resolv.conf con: $ sudo gedit /etc/resolv.conf

Añadimos las dns y buscamos nuestro equipo local para resolver las dns.
nameserver 8.8.8.8
nameserver 8.8.4.4
search router1VBox

Lo siguiente es añadir a nuestro archivo hosts nuestra ip con : $ sudo gedit /etc/hosts
Y le agregamos lo siguiente:
127.0.1.1 router1VBox
192.168.1.101 vmtest01.router1VBox vmtest01

Por último reiniciar para que tenga efecto la configuración:

sudo ifdown eth0
sudo ifup eth0
sudo /etc/init.d/networking restart

Recordar que en la configuración de la máquina virtual, el adaptador de red tiene que estar
en “Adaptador Puente”.
BIBLIOGRAFIA:
Manual sobre “Alta disponibilidad para Linux” de Juan Pedro Paredes en
https://www.google.com.mx/url?
sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwjUy8bx-
obTAhVO42MKHZ8oDcYQFggcMAA&url=http%3A%2F%2Fwww.othlo.com%2Fhtecnologia
%2Fdocumentacion
%2Fhispalinux04%2F11disponibilidad.pdf&usg=AFQjCNHMZSLjknZvPAFmzUptiOfc2FX12w
&sig2=4uIeWRjflEhXnoTioFH7oQ
Comentarios: Da buena teoria sobre sistemas tolerantes a fallos con redundancia y sistemas
alta disponibilidad, sin embargo es algo viejo el documento.

Tutorial sobre instalacion sobre virtualbox :

https://www.youtube.com/watch?v=9NHGNDZB5iE
Comentarios: Da un ejemplo muy didactico de entender , pero no da detalle de como
configurar la red dentro de las maquinas virtuales de virtualbox, cosa que no es trivial, sino
sumamente compleja.

Manual “Cluster Web en Alta Disponibilidad con LVS” de Juan Luis Sanchez Crespo. En
http://informatica.gonzalonazareno.org/proyectos/2011-12/jlsc.pdf
Comentarios: Manual detallado sobre la instalacion del web server HA pero ademas incluye
los demas recursos necesarios para publicar web mas profesionalmente.

Tutorial sobre la instalación en una configuracion un poco compleja:

https://www.globo.tech/learning-center/ha-load-balancing-keepalived-ubuntu-16/
Comentarios: Tiene buenos detalles explicando algunos puntos finos de ajuste de la red y
sobre el arranque y paro del keepalived