HAProxy – Balanceador en alta disponibilidad

La alta disponibilidad es esencial en los servicios ofrecidos en internet. Cuando prestamos un servicio a nuestros clientes la indisponibilidad de este servicio no es una posibilidad. En esta entrada vamos a realizar la típica configuración de dos HAProxy trabajando en modo activo pasivo.

Utilizaremos 3 máquinas con Debian 10 y el kernel 4.19.0-14-amd64 con la siguiente configuración de red.

• haproxy01.sysadm.local 192.168.1.51/24 (IP flotante 192.168.1.50)
• haproxy02.sysadm.local 192.168.1.52/24 (IP flotante 192.168.1.50)
• docker01.sysadm.local 192.168.1.141/24

Realizaremos la configuración de red en ambos servidores, en el siguiente fichero /etc/network/interfaces

#haproxy01.sysadm.local
allow-hotplug ens192
iface ens192 inet static
        address 192.168.1.51
        netmask 255.255.255.0
        broadcast 192.168.1.255
        gateway 192.168.1.1
        nameservers 192.168.1.1

#haproxy02.sysadm.local
allow-hotplug ens192
iface ens192 inet static
        address 192.168.1.52
        netmask 255.255.255.0
        broadcast 192.168.1.255
        gateway 192.168.1.1
        nameservers 192.168.1.1

El siguiente paso es instalar keepalived, haproxy y postfix, con la configuración que viene por defecto:

apt-get install keepalived haproxy psmisc && touch /etc/keepalived/keepalived.conf

El tiempo de indisponibilidad cuando hace failover es de apenas unos segundos.

Añadimos la siguiente configuración al fichero keepalived.conf creado anteriormente en nuestro servidor haproxy01.sysadm.local:

#haproxy01.sysadm.local
global_defs {
        enable_script_security
        script_user haproxy
        notification_email {
                [email protected]
        }
        notification_email_from [email protected]
        smtp_server 127.0.0.1
        router_id haproxy01
}

vrrp_script haproxy {
        script "/usr/bin/killall -0 haproxy"
        interval 2
        timeout 1
}

vrrp_instance ELB {
        state MASTER
        interface ens192
        virtual_router_id 51
        priority 255
        advert_int 1
        authentication {
                auth_type PASS
                auth_pass powerpassword@
        }
        virtual_ipaddress {
                192.168.1.50 dev ens192
        }
        smtp_alert
        track_script {
                haproxy
        }
}

#haproxy02.sysadm.local
global_defs {
        enable_script_security
        script_user haproxy
        notification_email {
                [email protected]
        }
        notification_email_from [email protected]
        smtp_server 127.0.0.1
        router_id haproxy01
}

vrrp_script haproxy {
        script "/usr/bin/killall -0 haproxy"
        interval 2
        timeout 1
}

vrrp_instance ELB {
        state BACKUP
        interface ens192
        virtual_router_id 51
        priority 205
        advert_int 1
        authentication {
                auth_type PASS
                auth_pass powerpassword@
        }
        virtual_ipaddress {
                192.168.1.50 dev ens192
        }
        smtp_alert
        track_script {
                haproxy
        }
}

Aquí os detallo que hace concretamente cada parámetro, podéis ver todos los parámetros disponibles en la propia man page de la web de keepalived.org. Los campos de email los ignoro pues son evidentes su función.

• router_id: aquí añadimos el hostname de la máquina.
• state: MASTER para el activo y BACKUP para el pasivo.
• interface: El nombre de nuestra interfaz de red, podemos poner varias con el formato interfaces { … }
• virtual_router_id: Es un número identificativo único por cada instancia vrrp.
• priority: Un número entre 1 y 255, lo ideal es que el master tenga una diferencia de 50 respecto al primer pasivo.
• advert_int: El intervalo en segundos del VRRP.
• authentication: Autentificación para sincronizar el failover.
• virtual_ipaddress: La IP flotante del cluster.
• smtp_alert: Activa la notificación por emails para esa instancia de vrrp.

La parte de script no es más que un killall -0 para identificar si el proceso de haproxy está corriendo o no y realizar el failover en caso de que no esté corriendo.

Ahora añadiremos la siguiente configuración al final del fichero /etc/haproxy/haproxy.conf

frontend http-in
        bind *:80
        acl host_app_sysadm hdr(host) -i app.sysadm.local
        use_backend app if host_app_sysadm

backend app
        balance leastconn
        option httpclose
        option forwardfor
        server docker01.sysadm.local 192.168.1.141:80

Para finalizar lo único que tenemos que hacer son las pruebas de apagar alguna de nuestras máquinas para comprobar que el servicio en todo momento sigue funcionado y lo que recibimos es un timeout de unos 5 o 10 segundos sin llegar a recibir ningún error. Evidentemente en nuestro servidor destino, tenemos que tener corriendo algún servicio escuchando en el puerto 80. En la siguiente entrada te dejo como añadir una seguridad extra a tu servidor de WordPress, no te la pierdas.

¡Hasta la próxima!