En un post anterior vimos un pequeño ejemplo de un balanceo de carga web con el módulo mod_proxy_server de Apache. Esta vez vamos a ver también balanceo en un sentido más amplio (es decir, sin ceñirnos a un entorno en concreto, como podría ser el web). Al contrario, LVS (Linux Virtual Server) nos va a servir para balancear muchos tipos de servicio.

El mismo gráfico que usamos para definir los clientes, el frontend y los backends del mod_proxy_server de Apache serviría, pero como la configuración no es tan sencilla como en el caso de mod_proxy_server (dónde definíamos los nodos del balanceador como urls), veamos una imagen de lo que vamos a montar.

En el gráfico se muestran los elementos imprescindibles que necesitaremos para la infraestructura unidos por lineas negras, mientras que los opcionales (aunque recomendables y que aquí usaremos) son los unidos por lineas discontinuas naranjas. Así pues, será necesario disponer de una máquina que hará de LVS DIRECTOR y otra (como mínimo una) que hará de REALSERVER (REALSERVER1). Usaré un portátil para lo primero y un sobremesa para lo segundo. Además, una tercera máquina hará las funciones de REALSERVER2 para poder ver realmente la tarea de balanceo; un ROUTER ADSL será el gateway (GW) del LVS DIRECTOR, permitiendo ofrecer el servicio balanceado públicamente, y un smartphone me hará las veces de cliente, pudiendo usarse bien para realizar los requests web desde dentro de la propia LAN o bien desde Internet (pero en cualquier caso siempre a través del router, dado que es el GW del LVS DIRECTOR).

En cuanto a la estructura de red del gráfico es importante hacer notar que como usaremos la modalidad NAT de LVS (LVS NAT), vamos a trabajar con 2 rangos de red: 192.168.2.x (donde se halla la Virtual Interface (VIF) del LVS DIRECTOR o frontend, donde éste recibirá las pecitiones que reenviará a los REALSERVERS, nodos o backends) y 192.168.1.x (para la estructura interna del balanceo o comunicación entre LVS DIRECTOR y REALSERVERS). Asimismo, comentar que si bien es recomendable que el LVS DIRECTOR disponga de 2 interfaces de red físicos, no es imprescindible. En este ejemplo y a modo de prueba usaremos únicamente un interfaz de red con 2 direcciones ip (eth0 y eth0.110, a la que llaman VIF).

Instalación, configuración y prueba

1. En el LVS DIRECTOR instalamos ipvsadm, habilitamos el forwarding de paquetes, ignoramos las solicitudes ping a direcciones de broadcast, configuramos las 2 interfaces de red y definimos cuál será su GW:

apt-get install ipvsadm
echo "1" > /proc/sys/net/ipv4/ip_forward
# (O editar /etc/sysctl.conf, net.ipv4.ip_forward = 1 y sysctl -p)
cat /proc/sys/net/ipv4/ip_forward
echo "0" > /proc/sys/net/ipv4/conf/all/send_redirects
cat /proc/sys/net/ipv4/conf/all/send_redirects
echo "0" > /proc/sys/net/ipv4/conf/default/send_redirects
cat /proc/sys/net/ipv4/conf/default/send_redirects
echo "0" > /proc/sys/net/ipv4/conf/eth0/send_redirects
cat /proc/sys/net/ipv4/conf/eth0/send_redirects
ifconfig eth0 192.168.1.9 broadcast 192.168.1.255 netmask 255.255.255.0
ifconfig eth0:110 192.168.2.110 broadcast 192.168.2.255 netmask 255.255.255.0 # VIF
route add default gw 192.168.2.1 netmask 0.0.0.0 metric 1

2. En el REALSERVER1 instalaremos Apache2 (puede ser cualquier servidor web u otro servicio), modificamos el index para identificar el nodo a simple vista, configuramos su interfaz de red y su GW (que será el LVS DIRECTOR) y comprobamos que haya visibilidad hacia las 2 direcciones ip del LVS DIRECTOR:

apt-get install apache2
echo "Realserver1" > /var/www/index.html
ifconfig eth0 192.168.1.11 broadcast 192.168.1.255 netmask 255.255.255.0
route add default gw 192.168.1.9
ping 192.168.1.9 # Ve el GW? Seguimos...
ping 192.168.2.110 # Ve el VIF? Seguimos...

3. Haremos -casi- exactamente lo mismo con el REALSERVER2:

apt-get install apache2
echo "Realserver2" > /var/www/index.html
ifconfig eth0 192.168.1.12 broadcast 192.168.1.255 netmask 255.255.255.0
route add default gw 192.168.1.9
ping 192.168.1.9 # Ve el GW? Seguimos...
ping 192.168.2.110 # Ve el VIF? Seguimos...

4. Hecho esto, vamos a por lo interesante en el LVS DIRECTOR: limpiamos las reglas de ipvsadm que pudieran haber y empezamos la configuración del balanceo propiamente. Primero añadimos un servicio virtual (-A) con el scheduler round robin (-s rr) que debe ser ofrecido desde la VIF (eth0.110). A continuación, añadimos (-a) los REALSERVERS o nodos del balanceador (-r) indicando el packet-forwarding-method, que en nuestro caso ya dijimos que iba a ser NAT/masquerading (-m), seguido (opcionalmente) del weight (-w 1) o capacidad de un nodo de servir más o menos peticiones en relación al resto. Finalmente invocamos ipvsadm sin parámetros para que nos muestre la tabla de balanceo:

ipvsadm -C
ipvsadm -A -t 192.168.2.110:80 -s rr
ipvsadm -a -t 192.168.2.110:80 -r 192.168.1.11:80 -m -w 1
ipvsadm -a -t 192.168.2.110:80 -r 192.168.1.12:80 -m -w 1
ipvsadm

IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  plas.local:http rr
  -> 192.168.1.11:http            Masq    1      0          0         
  -> 192.168.1.12:http            Masq    1      0          0         

5. Suponiendo que tenemos todo como toca, es hora de hacer la primera prueba: usar un cliente que haga peticiones desde la LAN. En mi caso, con el smartphone asociado vía Wifi al AP del ROUTER ADSL (ip del rango 192.168.2.X) hago varios requests web con un navegador o wget a la dirección http://192.168.2.110/. Lo que deberíamos ver es que en los sucesivos requests, el balanceador va repartiendo la carga -más o menos- equitativamente, mostrando el index de un u otro servidor web.
6. Podríamos hacer la misma prueba pero con un cliente que haga las peticiones desde Internet. Para ello, en mi caso habilito en el router un Virtual Server (NAT) del puerto 8080 del router a 192.168.2.110:80 (ip del DIRECTOR) para que no se solape con la interfaz web de administración del primero. Del mismo modo que antes, en el cliente, con un navegador o wget obtenemos http://nuestra_ip_publica/.

Y básicamente sería esto: achievement unlocked!

Notas adicionales

• Podemos monitorizar los requests de diversas formas: el mod-status de Apache, tail -f /var/log/access.log, la propia tabla de balanceo de ipvadm...
• Hemos usado el algoritmo de balanceo rr (round robin) estandar para ayudarnos a verificar que en las pruebas se usan todos los nodos del balanceador, aunque hay otros interesantes como el wrr (rr ponderado), el lc (least connected) para cuando es frecuente añadir o quitar nodos, lblc o dh (destination hash) para cachés, o sh (source hash) destinado a carritos de compra para garantizar persistencia o sesiones SSL (para que un cliente siempre se conecte al mismo realserver).
• El weight es un ratio que define la la importancia de cada nodo (por encima/debajo de los demás). Si se define a 0, significa que no recibe nuevas peticiones y sólo conserva las que tenga (hasta que terminen/expiren). Esto puede resultar útil para retirar del servicio un nodo de un modo graceful. Por defecto es 1. Con el mismo hardware, conviene que todos los nodos tengan el mismo para no sobrecargar innecesariamente uno y liberar demasiado de carga otros.
• En la tabla de balanceo que muestra ipvsadm, ActiveConn son las conexiones en estado ESTABLISHED, y InActConn todos los demás. No es fácil ver ActiveConn a no ser que tengamos muchos requests simultáneos, éstos vayan lentos (p.ej. por sobrecarga) o se hayan quedado colgados.
• Al igual que con iptables, existen los scripts ipvsadm-save y ipvsadm-restore para guardar o restaurar configuraciones, respectivamente.

Referencias

http://www.ultramonkey.org/papers/lvs_tutorial/html/
http://www.austintek.com/#LVS-HOWTOs