jueves, 26 de marzo de 2009

Squid alta disponibilidad, LVS + Heartbeat

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;

  • Ipvsadm va controlar un IP virtual 172.95.69.100.

  • ldirectord va a controlar la existencia de un servicio de proxy en los servidores reales consultando la disponibilidad del puerto 3128, y a redirigir desde esta IP virtual el tráfico en el puerto 3128 a los servidores reales mediante una distribución de carga uniforme con el algoritmo Round Robin.

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?

4 comentarios:

Anónimo dijo...

Hola Axier:

viendo tu configuración, no se si conoces el problema ARP que tiene este escenario (LVS-Direct Routing)

Si no me equivoco aunque configures todos los interfaces como subinterfaces de loopback no se soluciona del todo.Es decir tal y como está esto configurado no tendría el problema de ARP ? Esto lo has montado en algun entorno de produccion o de pruebas ?

Josep Pi dijo...

Disculpa,

Soy yo el usuario anónimo anterior, que se me paso logarme :) .

Aqui tienes explicado el problema ARP:

http://www.linuxvirtualserver.org/docs/arp.html


Si te fijas, la primera solución que dan en este entorno no creo que funcionaría por que si haces invisibles a los mensajes arp los subinterfaces loopback de los que en el momento hacen de "Real Servers" cuando haya un failover en el Heartbeat y pasen los servicios a uno de esos nodos tenemos un problema al estar el subinterfaz de loopback en modo "silenciado" para ARP ya que los clientes en principio no deberían poder conectarse al nuevo Ldirector..

Aunque bueno.. quiza con un script que levante el propio hearbeat en el nodo activo, con dicho script podríamos quitar el modo "silencioso" de arp en el subinterfaz de loopback...

Que opinas ?

Unknown dijo...

Hola,

He cuando estaba probando configuraciones para montar este servicio si que leí algo a cerca, pero no he tenido problemas, y el cluster funciona muy bien, es más de un cluster he pasado a montar dos, uno en cada datacenter que tiene mi empresa y cada uno con una salida de un ISP diferente, asi que puedo balancear a través DNS interno la salida de los usuarios, esto lo tengo montado y en total estoy dando servicio proxy a unos 3000 host entre los dos cluster;

============
Last updated: Thu Dec 10 11:57:52 2009
Current DC: a4 (dafdbf13-aa9e-4dce-96c0-d7b7a996ddc5)
3 Nodes configured.
1 Resources configured.
============

Node: a6 (c687be88-2b5c-411a-a430-a20c22ce63e9): online
Node: a5 (b2c1719f-11be-4d8d-bc90-90c0a1c879d8): online
Node: a4 (dafdbf13-aa9e-4dce-96c0-d7b7a996ddc5): online

Resource Group: group_proxy
resource_vIP (heartbeat::ocf:IPaddr2): Started a6
resource_ldirectord (lsb:ldirectord): Started a6


Y el balanceo funciona muy bien;

A6:~# ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 172.15.2.3:3128 rr persistent 20
-> 172.15.2.5:3128 Route 1 231 3211
-> 172.15.2.6:3128 Local 1 147 169
-> 172.15.2.4:3128 Route 1 237 685
A6:~#


He tenido incluso la caída durante unos días de una maquina de uno de los clusters y hertbeat levanta tanto la ip virtual como el balanceador en la máquina que asuma el DC y hemos estado funcionando sin problemas.

Te sugiero que lo pruebes con tres máquinas virtualizadas, se monta bastante rápido... a mi me funciona...

Josep Pi dijo...

Gracias por tu respuesta:

Pues si tienes un entorno con 3.000 usuarios y no te da problemas.. esta bastante claro.Entiendo que el problema ARP es más bien un problema hipotético/teórico que puede llegar a ocurrir en caso de que la petición ARP la responda uno de los real servers en vez del Ldirector.

Yo voy a montarlo en un entorno de 3 servidores dedicados por exigencias del guion :)

Cuando lo monte te contare que tal si quieres, seguro que algo de guerra me dará, lo montaré en Suse ES seguramente.

Gracias y un saludo