Balanceo de carga con LVS (II)

Una vez expuesta la teoría acerca del balanceo de carga con LVS, vamos a continuar desarrollando las configuraciones que nos permitirán implementar esta funcionalidad en el Sistema de Alta Disponibilidad y Balanceo de Carga que estamos desarrollando.

Para monitorizar y controlar los servidores reales del cluster LVS, así como para llevar a cabo la administración de las tablas de forwarding del kernel, emplearemos el demonio ldirectord, el cual será arrancado y detenido cuando sea necesario por Hearbeat.

Ldirectord comprobará el estado de los servidores reales (LB1 y LB2) en intervalos de tiempo predeterminados, con el objetivo de mantener actualizada la tabla de conexiones del servidor virtual (HA1 o HA2).

Ldirectord genera reglas ipvsadm para gestionar el cluster LVS. Si alguno de los nodos traseros deja de atender peticiones de alguno de los servicios configurados por el LVS, ldirectord creará una llamada a ipvsadm que hará que el balanceador deje de enviarle paquetes a dicho nodo y servicio que no responde.

Lo primero que vamos a hacer va a ser instalar el paquete ldirectord en los dos nodos frontales, HA1 y HA2.

~# aptitude install ldirectord

A continuación vamos a editar el fichero de configuración (/etc/ha.d/conf/ldirectord.cf) para establecer los servicios a controlar (Apache, MySQL y vsftpd). Dentro de cada uno de los servicios a monitorizar, indicaremos la dirección IP virtual que recibirá los paquetes (192.168.1.20) y las direcciones IP de los servidores reales a los cuales se les repartirá la carga (10.0.0.12 y 10.0.0.13). Este fichero será idéntico en ambos nodos frontales.

~# cat /etc/ha.d/conf/ldirectord.cf
# Tiempo máximo para comprobar el estado del servicio (segundos)
checktimeout=2

# Periodo de comprobación (segundos)
checkinterval=30

# Apache
virtual=192.168.1.20:80
 real=10.0.0.12:80 masq 
 real=10.0.0.13:80 masq 
 service=http 
 protocol=tcp 
 scheduler=lc 
 checktype=negotiate 
 request="index.html" 
 receive="It works!"

# MySQL
virtual=192.168.1.20:3306 
 real=10.0.0.12:3306 masq 
 real=10.0.0.13:3306 masq 
 service=mysql 
 protocol=tcp 
 scheduler=lc 
 checktype=connect

# Vsftpd
virtual=192.168.1.20:21 
 real=10.0.0.12:21 masq 
 real=10.0.0.13:21 masq 
 service=ftp 
 protocol=tcp 
 persistent=600 
 scheduler=lc 
 checktype=connect

Como ha podido observarse, el fichero está formado por distintas secciones, una para cada tipo de servicio gestionado. Cada uno de estos bloques comienza por la dirección IP virtual del cluster por la que se atenderán las peticiones, y el puerto al que corresponde la clase de servicio especificado (virtual=X.X.X.X:Y). Es muy importante acordarse de tabular cada uno de los elementos que componen el bloque.

El primer elemento que aparece en cada una de las sección es la dirección o direcciones IP de los servidores reales, definidas a través de la etiqueta masq, mediante la cual estaremos indicando que se emplee un modelo LVS-NAT.

Otra de las etiquetas a destacar es la de scheduler, mediante la cual se señala el tipo de algoritmo a emplear de cara al balanceo de carga. En nuestro caso se va a emplear un Least Connection (lc), que lo que hace es asignar más trabajos a aquellos servidores que presentan menos carga de trabajo (para consultar el resto de algoritmos soportados se puede recurrir a la ayuda de ipvsadm).

También cabe mencionar el parámetro checktype, que cuando tenga el valor connect indicará a ldirectord que únicamente compruebe cada intervalo de tiempo definido (checkinterval) si el puerto está abierto (para ello enviará un paquete SYN al puerto configurado). Si dicho parámetro toma el valor negotiate, tendrá que negociar el estado de la conexión. Por ejemplo para el caso de HTTP, ldirectord solicitará a Apache la página web index.html (request) y comprobará su contenido (receive).

Para el caso del protocolo FTP configuraremos la opción de la persistencia. Debido a que este protocolo utiliza dos puertos (20 para datos y 21 para control), es necesario que todas las peticiones pertenecientes a una misma sesión vayan dirigidas siempre al mismo nodo (LB1 o LB2). De esta forma si por ejemplo una máquina con dirección IP 192.168.1.150 inicia una sesión FTP contra la dirección IP virtual 192.168.1.20, y este balanceador redirecciona la conexión hacia el nodo LB1, el resto de conexiones que tengan como origen la dirección IP 192.168.1.150 y servicio FTP, siempre irán al nodo LB1.

A través de la etiqueta persist=600 se configurará el tiempo de vida para dichas sesiones persistentes. Si no hay actividad durante ese periodo de tiempo, la sesión se considerará cerrada. Este parámetro también lo declarararíamos en caso de definir una sección para el protocolo HTTPS (tiene también el problema de la persistencia - ver el artículo anterior -).

Además, decir también que para el caso del protocolo FTP no es suficiente con declarar la etiqueta persist, también es necesario cargar un módulo (ip_vs_ftp) durante el arranque del sistema. Para ello incluiremos este módulo dentro del archivo /etc/modules (en ambos nodos frontales).

~# cat /etc/modules
...
ip_vs_ftp

Otro aspecto que hay que tener en cuenta es el de la sincronización de la tabla de conexiones. En un momento dado, el nodo activo puede tener abiertas varias conexiones HTTP. Todas estas conexiones serán almacenadas por ipvsadm en una tabla de estados (/proc/net/ip_vs_conn_sync). Para ello, el nodo activo enviará periódicamente mensajes multicast con los cambios de estado acaecidos en su tabla de conexiones. El balanceador pasivo recibirá estos mensajes e irá actualizando sus tablas

Si en un momento dado el nodo HA1 se cae y HA2 asume el papel de activo, este último tendrá registradas la mayoría de las conexiones establecidas contra el cluster, con lo que la mayor parte de las sesiones iniciadas podrán seguir accediendo a los mismos servicios que tenían abiertos con total normalidad.

Para realizar esta tarea, tendremos que arrancar el demonio de sincronización al inicio del sistema en ambos nodos, pero con la diferencia de que en el nodo configurado por defecto como activo tendrá el estado master, y en el pasivo, backup. Esta acción la ejecutaremos añadiendo la siguiente línea en el script de arranque /etc/rc.local.

root@ha1:~# cat /etc/rc.local
...
ipvsadm --start-daemon master
exit 0

root@ha2:~# cat /etc/rc.local
...
ipvsadm --start-daemon backup
exit 0

Y ya por último, si recordamos el archivo /etc/ha.d/haresources empleado por Hearbeat, podremos ver que este demonio era el encargado de detener e iniciar a ldirectord (estará arrancado en el nodo activo y parado en el pasivo).

~# cat /etc/ha.d/haresources
ha1 IPaddr2::192.168.1.20 IPaddr2::10.0.0.20 mysql-ndb-mgm ldirectord::ldirectord.cf LVSSyncDaemonSwap::master mon

Por este motivo será necesario que el proceso init no levante a ldirectord cuando arranque el sistema. Para ello, tendremos que ejecutar el siguiente comando en los dos nodos frontales.

~# update-rc.d -f ldirectord remove