En un post anterior hable de como tener un servicio de Proxy en alta disponibilidad en un cluster de tres elementos con Heartbeat, esta configuración nos permite tener estrictamente un servicio en alta disponibilidad, pero tiene un par de pegas importantes; es un esquema activo-pasivo-pasivo, por lo que dos máquinas están en el banquillo a la espera de que el Heartbeat les llame a jugar, y por lo que tampoco estamos usando la capacidad de respuesta de las tres tarjetas de red des esos servidores, tenemos tolerancia a fallos pero no optimizamos el uso de recursos. Esto es lo que voy a mejorar con esta configuración de cluster activo-activo-activo mediante LVS y Heartbeat.
Este cluster lo instalaremos en el segmento DMZi detrás de la seguridad perimetral, la única regla que daremos de alta será la conexión al puerto 3128 en la ip virtual de nuestro cluster 172.95.69.100
El sistema operativo que usaremos será Debian 5.0 partiendo de la instalación por red, instalamos el sistema base sin seleccionar nada en tasksel, una vez finalizada sera necesario que se vean los servidores entre si, por lo que haremos las oportunas entradas en el fichero /etc/network/interfaces con una particularidad, la de añadir una dirección de loopback virtual;
M30:~# cat /etc/network/interfaces
auto lo
iface lo inet loopback
auto lo:0
iface lo:0 inet static
address 172.95.69.100
netmask 255.255.255.255
network 172.95.69.0
broadcast 172.95.69.255
# The primary network interface
auto eth0
iface eth0 inet static
address 172.95.69.30
netmask 255.255.255.0
network 172.95.69.0
broadcast 172.95.69.255
gateway 172.95.69.1
# dns-* options are implemented by the resolvconf package, if installed
dns-nameservers 80.58.0.33
M30:~# cat /etc/hosts
127.0.0.1 localhost
127.0.1.1 M30
172.95.69.40 M40
172.95.69.50 M50
M40:~# cat /etc/network/interfaces
auto lo
iface lo inet loopback
auto lo:0
iface lo:0 inet static
address 172.95.69.100
netmask 255.255.255.255
network 172.95.69.0
broadcast 172.95.69.255
# The primary network interface
auto eth0
iface eth0 inet static
address 172.95.69.40
netmask 255.255.255.0
network 172.95.69.0
broadcast 172.95.69.255
gateway 172.95.69.1
# dns-* options are implemented by the resolvconf package, if installed
dns-nameservers 80.58.0.33
M40:~# cat /etc/hosts
127.0.0.1 localhost
127.0.1.1 M40
172.95.69.30 M30
172.95.69.50 M50
M50:~# cat /etc/network/interfaces
auto lo
iface lo inet loopback
auto lo:0
iface lo:0 inet static
address 172.95.69.100
netmask 255.255.255.255
network 172.95.69.0
broadcast 172.95.69.255
# The primary network interface
auto eth0
iface eth0 inet static
address 172.95.69.50
netmask 255.255.255.0
network 172.95.69.0
broadcast 172.95.69.255
gateway 172.95.69.1
# dns-* options are implemented by the resolvconf package, if installed
dns-nameservers 80.58.0.33
M50:~# cat /etc/hosts
127.0.0.1 localhost
127.0.1.1 M50
172.95.69.30 M30
172.95.69.40 M40
Instalamos los paquetes de heartbeat, ipvsadm y sus dependencias en las tres máquinas;
#aptitude install heartbeat ipvsadm ldirectord
Con ipvsadm, si no nos lo pide el debconf durante la instalación tendremos que reconfigurarlo usando el siguiente comando, configurando que arranque las reglas en el arranque y seleccionando both en la siguiente pregunta para que el equipo pueda actuar tanto como master y como backup.
# dpkg-reconfigure ipvsadm
Instalamos squid y realizamos las configuraciones necesarias para que el
servicio este disponible a los clientes;
#aptitude install squid
Lo que vamos a configurar es un cluster de tres miembros, en los que cada uno ofrezca servicio de proxy (squid), y a demás vamos a crear dos servicios en alta disponibilidad;
Configuramos el kernel de los servidores para que soporte la retrasmision de paquetes, editando el fichero
M30:~# vim /etc/sysctl.conf
Y descomentamos la linea siguiente;
# Uncomment the next line to enable packet forwarding for IPv4
net.ipv4.ip_forward = 1
Aplicamos los cambios en las tres máquinas con el comando;
M30:~# sysctl -p
net.ipv4.ip_forward = 1
¿Que es todo esto? Pues es tener un cluster en el que los tres miembros están activos, por que comparten una IP virtual y un servicio de director que reparte la carga de peticiones de clientes al puerto 3128 homogéneamente entre todos los miembros, en cristiano es tener tres proxys que se ven como uno solo, y que a demás ofrecen el servicio en alta disponibilidad por que si uno de ellos cae el servicio sigue funcionando.
Empezamos por la configuración del ldirectord, editamos el fichero en las tres máquinas para definir el funcionamiento;
M30:~# vim /etc/ha.d/ldirectord.cf
# /etc/ha.d/ldirectord.cf
checktimeout=3
checkinterval=5
autoreload=yes
logfile="/var/log/ldirectord.log"
emailalert = "email@gmail.com"
virtual=172.95.69.100:3128
fallback=127.0.0.1:3128
real=172.95.69.30:3128 gate 1
real=172.95.69.40:3128 gate 1
real=172.95.69.50:3128 gate 1
protocol = tcp
checktype = connect
scheduler = rr
persistent = 20
En este fichero se definen los parámetros de funcionamiento del demonio que va a dirigir el servicio de proxy entre los servidores reales, se puede configurar también un mail para el envío de alertas, se define la IP y el puerto de nuestro servicio virtual y las IP y puertos de los servidores reales. Los siguientes parámetros definen el tipo de chequeo que va a realizar el demonio para comprobar que los servidores reales están vivos, que es en este caso una prueba de conexión TCP, el scheduler es el tipo de reparto de carga que se va a usar, en este caso Round Robin.
Inicializamos los demonios en las tres máquinas;
M30:~# /etc/init.d/ldirectord start
Podemos comprobar que esta funcionando con el siguiente comando, en el que podemos ver los miembros que comprarten la IP virtual y el weight es igual 1,lo que quiere decir que ldorector ha comprobado que esas máquinas tienen conectividad en el puerto 3128.
M30:~# ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 172.95.69.100:3128 rr persistent 20
-> 172.95.69.50:3128 Route 1 0 1
-> 172.95.69.40:3128 Route 1 0 0
-> 172.95.69.30:3128 Local 1 0 0
Para configurar los servicios en alta disponibilidad con heartbeat, lo más sencillo es instalar la utilidad gráfica;
asier@asier-desktop:~$ aptitude install hb_gui
Lo primero que tenemos que hacer para conectarnos es ponerle una password al usuario hacluster;
M30:~# passwd hacluster
Y conectarnos a través de la aplicación, donde deberíamos ver ya los tres miembros de nuestro cluster vivos y en verde, hay que crear un grupo para nuestros servicios, lo he llamado load_balancer y hay que crearlo con los atributos target_role started, ordered true y collocated true.
Una vez creado el grupo hay que crear los dos servicios la ip virtual y el director, añadimos un recurso nativo “ipaddr2” dentro de nuestro grupo load_balancer con las siguientes parámetros; ip 172.95.69.100, lvs_support true.
Creamos otro recurso nativo dentro también del grupo load_balancer ldirector con los siguientes parámetros; config_file /etc/ha.d/ldirectord.cf
Si reiniciamos los servicios en las tres máquinas el resultado debería de ser el siguiente; tres nodos activos (running), uno de ellos como dc (domain controller), en uno de los nodos heartbeat arrancara los servicios de ldirector y ipaddr2, con esto estarían terminadas las configuraciones, ahora vamos a ver que pasa...
Desde un cliente se debería de poder hacer ping a nuestra ip virtual.
Si hacemos un nmap a la IP virtual deberíamos de ver el puerto 3128 abierto.
Si hacemos ssh a la ip virtual para conectarnos deberíamos conectarnos a cualquiera de las tres máquinas.
Si configuramos el proxy en un cliente, por supuesto, deberíamos navegar por que sino menudo manual de mierda, pero lo interesante es que nos debería de servir internet el squid de uno de los equipos del cluster, podemos comprobar cual haciendo; M30:~# tail -f /var/log/squid/access.log y viendo en cual de las tres máquinas nuestra actividad.
Pero lo más interesante viene ahora, si conectamos un segundo cliente podremos observar como el servicio de ldirectord le asigna esta conexión a otra de las máquinas, y si conectamos otro cliente, asignará la conexión a otra y así sucesivamente, por lo que comprobamos que ldirectod mediante el algoritmo de Round Robin reparte uniformemente la carga entre todos los miembros.
!Y aún hay algo aún mejor! ¿Que pasa si tiramos del cable de una de las máquinas?
Si tiramos de una de las que no es ni dc ni tiene los servicios corriendo, el ldirector detectará en 20 segundos que el servicio de proxy en ese miembro no esta disponible y dejara de repartirle trabajo.
Si tiramos la maquina que es dc, pasará lo de arriba y a demás heartbeat acordará a alguno de los otros miembros como nuevo dc.
Y lo mejor, que pasa si tiramos la máquina que tiene corriendo los servicios? Que el servicio de proxy se caerá hasta que heartbeat detecte que el cluster se ha degradado y una de los dos nodos restantes se anime a volver a ejecutar los servicios y restablecer asi todo.
Genial, no es verdad?
