LVS Keepalived Ubuntu

Queremos implementar un cluster de servidores con balanceo de carga y alta disponibilidad. El sistema tendrá una sola IP, llamada IP Virtual, en esta caso 192.168.10.201. El requerimiento inicial lo atiende el director o balanceador de carga (192.168.10.11), pero redirecciona el paquete para que los servicios sean atendidos por N servidores reales. Para que este director no se convierta en un único punto de falla, creamos la alta disponibilidad con un director backup (192.168.10.12).

LVS.jpg

Software

El balanceo de carga se logra con LVS. La alta disponibilidad se puede configurar de varias formas: Heartbeat con Ldirector, Piranha, Ultramonkey o Keepalived (hay mas formas). Usaremos Keepalived ya que permite manejar el cluster con una sola herramienta.

Empecemos por el balanceo de carga: LVS, ipvsadm y keepalived.

Linux Virtual Server (LVS) viene integrado en el kernel de Ubuntu 8.04, por lo que no tenemos que recompilar. Sólo hay que instalar la herramienta ipvsadm para agregar reglas de balanceo de carga. Más adelante, cuando configuremos la alta disponibilidad, Keepalived instalará todo de un solo paso.

La red del cluster

Existen 3 técnicas para configurar la red de clusters con balanceo de carga: NAT, TUN y DR. Hay información en www.linuxvirtualserver.org.

Aquí implementaremos Direct Routing (http://docs.redhat.com/docs/es-ES/Red_Hat_Enterprise_Linux/5/html/Virtual_Server_Administration/s1-lvs-direct-VSA.html), porque es el más sencillo y rápido. Tiene la limitación de que los servidores reales y los balanceadores deben estar en el mismo segmento de red. El paquete es enviado a la IP Virtual y es atendido por el director. Este reenvía a los servidores reales de acuerdo a un algoritmo de balanceo de carga (hay 7 disponibles). El servidor real contesta directamente al cliente, sin pasar por el director.

La IP Virtual debe estar configurada tanto en el director como en los servidores reales.

El problema ARP

Una situación a resolver en esta configuración es el "Problema ARP". Como varios servidores tienen la misma IP, si la publican ante un requerimiento ARP habrá una
competencia por el paquete, llamado "Race Condition". Para evitar eso, debemos asegurarnos que el único que publica la dirección IP Virtual es el director, por lo que
debemos deshabilitar la publicación ARP en los servidores reales.

Algoritmos de balanceo de carga

Hay disponibles 7 algoritmos. Podemos empezar por Round Robin hasta ver que funcione y después pasar a Weighted Least-Connection. Podemos probar con todos:

  • rr: Robin Robin: distribuye la carga en forma equitativa entre los servidores, una petición a cada uno.
  • wrr: Weighted Round Robin: proporcional a su peso. Servidores con mas peso reciben mas carga. A igual peso, igual carga.
  • lc: Least-Connection: más carga a servidores con menos conexiones.
  • wlc: Weighted Least-Connection: mas carga a servidores con menos conexiones y relativo al peso.

Otros:

  • lblc: Locality-Based Least-Connection
  • dh: Destination Hashing
  • sh: Source Hashing

Implementación

Vamos a implementar el cluster: un web server. Asumiremos que los servidores reales tienen Apache funcionando con el mismo sitio, ya sea con un storage centralizado, mirror a través de red (DRDB) o NFS.

Los directores master y backup deben tener keepalived instalado y configurado, la IP virtual configurada y habilitado el forwarding IP.

Los servidores reales deben tener el servicio andando corriendo, la IP virtual configurada en lo:0, deshabilitada la publicación ARP y configurada una ruta estática.

Instalamos Keepalived en los directores, el cual instalará ipvsadm como dependencia.

apt-get install keepalived

Creamos el archivo de configuración:

vi /etc/keepalived/keepalived.conf

######### /etc/keepalived/keepalived.conf ####################
global_defs {
    notification_email {
       root@dominio.com
    }
    notification_email_from root@dominio.com
    smtp_server 127.0.0.1
    smtp_connect_timeout 30
    lvs_id LVS1
}
virtual_server 192.168.10.201 80 {
    delay_loop 30
    lb_algo rr
    lb_kind DR
    persistence_timeout 50
    protocol TCP
    real_server 192.168.10.101 80 {
        weight 1
        TCP_CHECK {
            connect_port 80
            connect_timeout 3
        }
    }
    real_server 192.168.10.102 80 {
        weight 2
        TCP_CHECK {
            connect_port 80
            connect_timeout 3
        }
    }
}
vrrp_instance VI_1 {
    state MASTER
    interface eth0
    lvs_sync_daemon_inteface eth0
    virtual_router_id 51
    priority 150
    advert_int 1
    smtp_alert
    authentication {
        auth_type PASS
        auth_pass 1234
    }
    virtual_ipaddress {
        192.168.10.201
    }
}
####### fin /etc/keepalived/keepalived.conf ############

Habilitamos ip forwarding: esto sí hay que hacerlo manualmente

echo 1 > /proc/sys/net/ipv4/ip_forward

Arrancamos keepalived

/etc/init.d/keepalived start
Starting Keepalived for LVS:        [ OK ]

Comprobamos la IP virtual:

ip addr sh eth0

#Debemos ver algo así:
inet 192.168.10.12/24 brd 192.168.6.255 scope global eth0
inet 192.168.10.201/32 scope global eth0

Comprobamos el cluster:

ipvsadm -L -n
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags

-> RemoteAddress:Port         Forward Weight ActiveConn InActConn
TCP 192.168.10.201:80 wrr
-> 192.168.10.101:80           Route     1   0    0
-> 192.168.10.102:80           Route     2   0    0

Esto es lo que hace keepalived:

# ipvsadm -A -t 192.168.10.201:80 -s wrr
# ipvsadm -a -t 192.168.10.201:80 -r 192.168.10.101 -g
# ipvsadm -a -t 192.168.10.201:80 -r 192.168.10.102 -g

El primer comando agrega un servicio con ip virtual y puerto (-A) protocolo TCP (-t) y algoritmo (-s) Weighted Round Robin.
El segundo y el tercero agregan un server real al servicio (-a) con ip real (-r) y balanceo tipo direct routing.

En el server real (servidores web) configuramos la IP Virtual y la ruta estática:

ifconfig lo:0 192.168.10.201 netmask 255.255.255.255 broadcast 192.168.10.201 up
route add -host 192.168.10.201 dev lo:0

Para hacer la configuración permanente, creamos un script:

vi /etc/network/if-up.d/lvs

#!/bin/sh
/sbin/ifconfig lo:0 192.168.10.201 netmask 255.255.255.255 broadcast 192.168.10.201 up
/sbin/route add -host 192.168.10.201 dev lo:0

#Y lo hacemos ejecutable:
chmod 755 /etc/network/if-up.d/static-routes

Deshabilitamos la publicación ARP en /etc/sysctl.conf:

echo "net/ipv4/conf/all/arp_ignore = 1" >> /etc/sysctl.conf
echo "net/ipv4/conf/all/arp_announce = 2" >> /etc/sysctl.conf
sysctl -p

Simular el fallo del director master:

/etc/init.d/keepalived stop

Simular el fallo en algun servidor real:

/etc/init.d/apache2 stop

Comentarios

El archivo /etc/keepalived/keepalived.conf tiene 3 partes:

global_defs: Definiciones globales.

global_defs {
     notification_email {
          root@dominio.com
     }
     notification_email_from root@dominio.com
     smtp_server 127.0.0.1
     smtp_connect_timeout 30
     lvs_id LVS1
}

notification_email: quién recibe el email de alerta.
notification_email_from: remite del email de alerta.
lvs_id: identificador del director.

virtual_server: directivas de cada servidor virtual.

Por ejemplo, para un servidor web en la IP virtual 192.168.10.201, puerto 80:

virtual_server 192.168.10.201 80 {
        delay_loop 15
        lb_algo rr
        lb_kind DR
        persistence_timeout 50
        protocol TCP
        real_server 192.168.10.101 80 {
                weight 1
                TCP_CHECK {
                       connect_port 80
                       connect_timeout 3
                }
        }
        real_server 192.168.10.102 80 {
                weight 2
                TCP_CHECK {
                       connect_port 80
                       connect_timeout 3
                }
        }
}

Lo importante es:

lb_algo: algoritmo de balanceo de carga: rr|wrr|lc|wlc|lblc|sh|dh
lb_kind: tipo de balanceo: NAT|DR|TUN
real_server: servidor real perteneciente al pool.
weight: peso relativo del servidor para balancear la carga.
TCP_CHECK: método para chequear la disponibilidad del servidor.

Si tenemos más IPs virtuales o servicios agregamos otras secciones virtual_server: porejemplo, en la misma IP virtual 192.168.10.201 un servidor de correo en el puerto 25:

virtual_server 192.168.10.201 25 {
        delay_loop 15
        lb_algo wlc
        lb_kind DR
        persistence_timeout 50
        protocol TCP
        sorry_server 192.168.10.11 25
        real_server 192.168.10.103 25 {
                weight 1
                TCP_CHECK {
                       connect_port 25
                       connect_timeout 3
                }
             }
       real_server 192.168.10.104 25 {
               weight 2
               TCP_CHECK {
                       connect_port 25
                       connect_timeout 3
               }
       }
}

vrrp_instance: directivas para monitorizar los directores:

vrrp_instance VI_1 {
       state MASTER
       interface eth0
       lvs_sync_daemon_inteface eth0
       virtual_router_id 51
       priority 150
       advert_int 1
       smtp_alert
       authentication {
               auth_type PASS
               auth_pass 1234
       }
       virtual_ipaddress {
               192.168.10.201
       }
}

state: MASTER o BACKUP.
priority: el master debe tener mayor prioridad.

El archivo de configuración de Keepalived en el backup es casi igual al del master, sólo sediferencia en tres líneas:
lvs_id: LVS2, el id debe ser distinto.
priority: 100, inferior a la prioridad del master.
state: BACKUP.

Fuente:
http://mmc.geofisica.unam.mx/LuCAS/Manuales-LuCAS/doc-curso-salamanca-clustering/html/ch03s04.html

Habilitar Shorewall:
http://www.squashedfrog.net/article.php?story=20071109224421634

« Linux

Si no se indica lo contrario, el contenido de esta página se ofrece bajo Creative Commons Attribution-ShareAlike 3.0 License