Balanceador de carga con LVS y Piranha

En este artículo veremos cómo configurar un balanceador de carga con LVS y Piranha, en un servidor CentOS, con un único router LVS. Hay muchos artículos por Internet que explican cómo hacerlo con 2 routers, para conseguir así tener alta disponibilidad en el balanceador, pero no siempre se disponen de dos máquinas para conseguir la alta disponibilidad. Como añadido, el servicio a balancear será MySQL, no Apache como suele ser habitual.

Para el test, los sevidores tienen las siguientes características, además de selinux deshabilitado e iptables configurado:

Hostname: balancer
IP: (eth0) 192.168.2.228. Default gw: 192.168.2.1

Hostname: mysql1
IP: (eth0) 192.168.2.241. Default gw: 192.168.2.1

Hostname: mysql2
IP: (eth1) 192.168.2.242. Default gw: 192.168.2.1

1- BALANCEADOR- Instalación

$ yum install ipvsadm
$ yum install piranha

2- BALANCEADOR- Inicio de servicios

$ vi /etc/hosts -> Confirmar que el hostname está en el fichero de hosts
$ service piranha-gui start
$ chkconfig piranha-gui on
$ chkconfig pulse on

3- BALANCEADOR- Configuración

$ piranha-passwd -> Introducir el password que servirá para acceder a la web Piranha
$ vi /etc/sysctl.conf -> Poner a «1» el parámetro «net.ipv4.ip_forward = 1»
$ sysctl -p -> Para activar la conf del ip forward

4- CLIENTE – Acceso web y configuración

Desde un PC cliente, accederemos a la interfaz web de Piranha (será importante restringir el acceso a esta web, únicamente a nuestras direcciones IP)
http://192.168.2.228:3636/
user: piranha
pass: el indicado en el punto 3

A continuación, nos moveremos por la web de configuración de piranha, modificando convenientemente los valores siguientes:

• Pestaña «Global Settings»
  • Primary server public IP: La IP del pública del servidor (192.168.2.228 en el ejemplo)
  • Use network type: Direct. Este punto es crucial, y cambiará toda la configuración y la forma de trabajar de la solución final. Direct Routing proporciona mayor rendimiento que el resto de configuraciones, permitiéndo a los Real Servers devolver las respuestas directamente a los clientes, sin pasar por el router LVS. Por esta razón, al usar Direct Routing, los Real Servers no han de configurar su red para usar el router LVS como default gateway (cosa que sí se debería hacer al configurar este punto como NAT, que no es nuestor caso).

  

• Pestaña «Redundancy«.
  • En esta pestaña podríamos configurar la alta disponibilidad del balanceador de carga. En este ejemplo, como se ha comentado, no la configuraremos.

  

• Pestaña «Virtual Servers«:
  • En esta sección, se configurará un virtual server con una nueva IP para referirnos al conjunto de nodos tras el balanceador. En el ejemplo, usaremos la dirección 192.168.2.240, que estaba sin asignar. Por defecto, nos Piranha nos marcará el Device eth0:1, lo cual, efectivamente, nos creará de forma automática un alias para nuestra interfaz de red, con la IP que le indicamos.

  

  NOTA: Pulsa en la imágen para verla a tamaño completo.

  • Posteriormente se configurará una entrada «Real Server» por cada uno de los servidores tras el balanceador. Únicamente bastará con indicar la IP del servidor y el servicio que estamos balanceando. En nuestro ejemplo añadiremos 2 Real Servers.

  

  • Una vez añadido el servidor virtual, y los servidores reales, deberemos activarlos. Esta parte no es demasiado intuitiva, pero es necesaria. Para activar los Real Servers, deberemos ir a la pestaña principal «Virtual Servers» > Nos Aparecerá el servidor virtual que hemos creado > Pulsaremos «Edit» > Seleccionaremos la nueva pestaña «Real Servers». Aquí aparecerán nuestros real servers. Deberemos marcar uno y pinchar en «(de)activate». Veremos como el servidor cambia su estado a «UP». Marcaremos el resto de servidores uno a uno, activándolos (en el ejemplo sólo tenemos 2).

  

  NOTA: Pulsa en la imágen para verla a tamaño completo.

  • Finalmente, habilitaremos el virtual server, desde la pestaña principal «Virtual Servers» > Nos Aparecerá el servidor virtual que hemos creado > nos aseguraremos de tenerlo marcado y pulsaremos en «(de)activate».

  

  NOTA: Pulsa en la imágen para verla a tamaño completo.

5- Monitorización de MySQL

Como se querrá balancear un MySQL, será necesario que el balanceador pueda comprobar la disponibilidad del servicio MySQL en los Real Servers. Para ello, deberemos hacer algo de trabajo adicional. Éste apartado está sacado de aquí.

Balanceador

En el balanceador, instalaremos el cliente de mysql para poder conectarnos con los Real Servers:

yum install mysql

A continuación, crearemos un script de monitorización, que conectará con los Real Servers. Podremos dejar este script en /root, para que otros usuarios del sistema no puedan leerlo:

vi /root/mysql_mon.sh

#!/bin/sh
USER=monitor
PASS=MiPass123
####################################################################
CMD=/usr/bin/mysqladmin

IS_ALIVE=`$CMD -h $1 -u $USER -p$PASS ping | grep -c «alive»`

if [ «$IS_ALIVE» = «1» ]; then
echo «UP»
else
echo «DOWN»
fi

chmod 755 /root/mysql_mon.sh

Cliente

Una vez configurado el script de monitorización, volveremos a loguearnos desde un cliente, a la interfaz web de administración de Piranha, e iremos a la pestaña principal «Virtual Servers» > Nos Aparecerá el servidor virtual que hemos creado > Pulsaremos «Edit» > Seleccionaremos la nueva pestaña «Monitoring Scripts». Aquí modificaremos la configuración para usar el nuevo script:

• Sending program: «/root/mysql_mon.sh %h» (no hace falta poner las comillas)
• Send: <Blank>
• Expect: «UP» (no hace falta poner las comillas)
• Treat expect string as a regular expression: marcado

Pulsaremos «Accept». Tras pulsarlo, veremos la configuración que hemos salvado:

NOTA: Pulsa en la imágen para verla a tamaño completo.

Real Servers

En el script de monitorización, se ha definido un usuario y password que se usará para conectar contra el MySQL de los Real Servers, y comprobar así la salud del servicio. Se deberá, pues, en cada Real Server, crear este usuario. Para ello, en cada Real Server, se dará de alta un usuario MySQL:

mysql> GRANT USAGE ON *.* TO monitor@’%’ IDENTIFIED BY ‘MiPass123’;
mysql> flush privileges;

6- BALANCEADOR- Inicio de servicios

Una vez realizada la configuración a través de la interficie web de Piranha, pasaremos a iniciar los servicios:

$ service pulse restart

Tras ello, se podrá verificar el estado del balanceador con:

[root@balancer log]# ipvsadm
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.2.240:mysql lc
-> 192.168.2.242:mysql Route 1 0 0
-> 192.168.2.241:mysql Route 1 0 0

7- REAL SERVERS – Red

En cada uno de los nodos que irán tras el balanceador (los 2 servidores reales en el ejemplo) deberemos crear un alias en la tarjeta de red, con la IP virtual que hemos indicado para el virtual server:

mysql1$ ip addr add 192.168.2.240 dev eth0:1
mysql2$ ip addr add 192.168.2.240 dev eth1:1

En cada server, además, deberemos incluir la correspondiente sentencia en el /etc/rc.local para asegurarnos de crear el alias tras cada reinicio del servidor. Si lo hubieramos preferido, tal y como indica la documentación oficial de Red Hat, también podríamos haber usado ifconfig para crear los alias (NOTA: ésto no será necesario, si ya hemos ejecutado las anteriores instrucciones con «ip addr»):

mysql1$ ifconfig eth0:1 192.168.2.240 netmask 255.255.252.0 broadcast 192.168.2.255 up
mysql2$ ifconfig eth1:1 192.168.2.240 netmask 255.255.252.0 broadcast 192.168.2.255 up

Una vez creado el alias y configurado en el rc.local, instalaremos y configuraremos arptables en cada uno de los real servers:

mysql1$ yum install arptables_jf
mysql1$ arptables -A IN -d 192.168.2.240 -j DROP
mysql1$ arptables -A IN -d 192.168.2.240 -j mangle –mangle-ip-s 192.168.2.241

mysql2$ yum install arptables_jf
mysql2$ arptables -A IN -d 192.168.2.240 -j DROP
mysql2$ arptables -A IN -d 192.168.2.240 -j mangle –mangle-ip-s 192.168.2.242

NOTA: En la documentación oficial de Red Hat, las reglas arptables están definidas de forma ligeramente diferente:

arptables -A IN -d <virtual_ip> -j DROP
arptables -A OUT -s <virtual_ip> -j mangle –mangle-ip-s <real_ip>

Una vez configurado, ejecutaremos las dos siguientes sentencias en cada Real Server para guardarlo y asegurarnos de ejecutarlo al inicio:

service arptables_jf save
chkconfig –level 2345 arptables_jf on

8- Comprobaciones

Para comprobar el alias de la tarjeta de red, con la ip virtual, creada con «ip addr» tanto en los real servers como en el router LVS, se podrá ejecutar el comando siguiente (cualquiera de los servidores dará una respuesta similar). Si se ha creado el alias con ifconfig, se deberá ejecutar «ifconfig» para realizar la comprobación:

[root@balancer ~]# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:15:b7:f5:07:55 brd ff:ff:ff:ff:ff:ff
inet 192.168.2.228/24 brd 192.168.2.255 scope global eth0
inet 192.168.2.240/24 brd 192.168.2.255 scope global secondary eth0:1
3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
link/ether 00:18:de:ce:e8:31 brd ff:ff:ff:ff:ff:ff

En los Real Servers, se podrá ver la tabla de arptables_jf, con el siguiente comando:

[root@mysql1 ~]# /etc/init.d/arptables_jf status
Tabla: filter
Chain IN (policy ACCEPT)
target source-ip destination-ip source-hw destination-hw hlen op hrd pro
DROP anywhere 192.168.2.240 anywhere anywhere any any any any
mangle anywhere 192.168.2.240 anywhere anywhere any any any any –mangle-ip-s 192.168.2.241

Chain OUT (policy ACCEPT)
target source-ip destination-ip source-hw destination-hw hlen op hrd pro

Chain FORWARD (policy ACCEPT)
target source-ip destination-ip source-hw destination-hw hlen op hrd pro

Unos segundos tras configurar todo el sistema, pero antes de haber iniciado ninguna conexión contra el balanceador para testearlo, el balanceador devolverá una tabla de conexiones como la siguiente:

[root@balancer log]# ipvsadm
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.2.240:mysql lc
-> 192.168.2.242:mysql Route 1 0 0
-> 192.168.2.241:mysql Route 1 0 0

Sin embargo, si se inicia desde un cliente, una conexión mysql contra la IP Virtual del balanceador (192.168.2.240 en el ejemplo), se verá como se incrementa el número de conexiones activas de entrada:

[root@balancer log]# ipvsadm
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.2.240:mysql lc
-> 192.168.2.242:mysql Route 1 0 1
-> 192.168.2.241:mysql Route 1 1 0

NOTAS DE INTERÉS

Como último apunte, seguramente sea interesante saber más sobre los servicios que intervienen en la solución de balanceo que hemos montado. En la documentación oficial de Red Hat describen perfectamente estos servicios:

• Pulse: el proceso encargado de iniciar todos los otros procesos relacionados con el router LVS. En caso de contar con más de un router LVS para alta disponibilidad, pulse se encarga de determinar cual ha de ser el router activo y cuales los pasivos, iniciando convenientemente los servicios LVS en cada uno de ellos.
• LVS: el router LVS activo (en caso de tener más de un router LVS) tendrá corriendo el servicio LVS, que se habrá iniciado mediante Pulse. Éste servicio lee la configuración descrita en /etc/sysconfig/ha/lvs.cf (configurada automáticamente a través de Piranha) llama a «ipvsadm», y levanta un proceso «nanny» por cada uno de los Real Servers configurados.

[root@balancer log]# ps -ef | grep nanny
root 31605 31596 0 11:54 ? 00:00:00 /usr/sbin/nanny -c -h 192.168.2.241 -p 3306 -r 3306 -s GET / HTTP/1.0\r\n\r\n -x HTTP -a 15 -I /sbin/ipvsadm -t 6 -w 1 -V 192.168.2.240 -M g -U none –lvs
root 31606 31596 0 11:54 ? 00:00:00 /usr/sbin/nanny -c -h 192.168.2.242 -p 3306 -r 3306 -s GET / HTTP/1.0\r\n\r\n -x HTTP -a 15 -I /sbin/ipvsadm -t 6 -w 1 -V 192.168.2.240 -M g -U none –lvs

• Ipvsadm: LVS llama a ipvsadm para que éste añada, cambie o elimine entradas en la tabla de routing IPVS.
• Nanny: Sólo el router LVS activo tendrá servicios nanny corriendo. Mediante estos demonios, el balanceador determina la salud de los Real Servers.
• Piranha: La herramienta web que nos permite configurar todo el sistema sin apenas tocar ficheros de configuración.

Fuentes:

http://dak1n1.com/blog/13-load-balancing-lvs
http://blog.secaserver.com/2012/11/high-availability-configure-piranha-http-https-mysql/
http://blog.secaserver.com/2012/07/centos-configure-piranha-load-balancer-direct-routing-method/
https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Load_Balancer_Administration/index.html

Foto por karindalziel