En este artículo, te mostraremos un ejemplo de configuración que combina ambos tipos de VRRP, tanto a nivel global como individual, para lograr un equilibrio entre alta disponibilidad y escalabilidad en Nginx utilizando Keepalived.
1. VRRP entre Centros de Datos (CPDs)
1.1 ¿Qué es VRRP (Virtual Router Redundancy Protocol)?
VRRP (Virtual Router Redundancy Protocol) es un protocolo de red diseñado para proporcionar redundancia en los enrutadores dentro de una red. Se utiliza para garantizar que una dirección IP específica esté siempre disponible, incluso si ocurre algún problema con un enrutador o este falla. Para lograr esto, varios enrutadores trabajan juntos compartiendo la carga de enrutamiento y manteniéndose conectados en caso de que uno falle. Este protocolo de comunicación abierto sirve a las máquinas dentro de la misma subred, aumentando la disponibilidad de la puerta de enlace predeterminada.
Es crucial que la infraestructura cuente con Alta Disponibilidad. Así, nuestros servidores no dejarán de operar ni detendrán su rendimiento debido a problemas o causas externas.
1.2 Tipos de IP Virtual: Escenarios de configuración
Se pueden definir dos o más IPs virtuales para la misma máquina. Ahora veremos uno de los escenarios que desarrollamos con este tipo de configuración.
Todos los balanceadores de carga de cada entorno están incluidos en un VRRP global. Si hay una falla que afecta a uno de los balanceadores, el tráfico se redirigirá automáticamente a otro balanceador activo de cualquier entorno. Dado que el tráfico puede redirigirse a cualquier entorno activo independientemente del CPD en el que se encuentre, esta configuración proporciona un mayor nivel de tolerancia a fallos y capacidad de recuperación mejorada.
Una configuración de VRRP a nivel de entorno es similar a una configuración global, pero se limita a un entorno específico. En este caso, solo los dos balanceadores de carga de ese entorno se configurarán para trabajar juntos como un grupo de alta disponibilidad. Si uno de los balanceadores falla, el otro tomaría automáticamente el control y gestionaría la distribución del tráfico. Esta configuración es más limitada en términos de recuperación ante fallos, pero es adecuada para entornos con menor tráfico o menos requisitos estrictos de disponibilidad.
Ejemplo de Infraestructura con VRRP
En nuestro ejemplo, creamos dos escenarios de VRRP. En el primero, los balanceadores de carga están conectados por entorno, separando PRE y PRO, por lo que solo necesitamos apuntar a una única dirección IP y se nos redirige a la máquina que tiene una mayor prioridad activa.
En el segundo, creamos un VRRP por entorno y CPD. Una IP virtual de este grupo solo puede redirigirse al otro balanceador de carga del mismo entorno y CPD.
2. Instalación de Nginx
Instalamos Nginx y lo configuramos como un balanceador de carga, lo que permite distribuir las solicitudes entrantes entre varios servidores backend. Esto incrementa la escalabilidad y disponibilidad de nuestros servicios.
usuario@nginx:~$ apt install nginx
En el laboratorio, configuraremos un archivo index.html personalizado en ambos nodos, lo que facilita identificar qué servidor está manejando las solicitudes al acceder al sitio web a través de la dirección IP virtual.
Para personalizar el archivo html, ejecutaremos el siguiente comando en el nodo 1:
usuario@nginx1:~$ echo "<h1>Este es el Servidor Web NGINX del Nodo 1</h1>" | sudo tee /var/www/html/index.nginx-debian.html
Seguimos los mismos pasos en el segundo nodo para personalizar su archivo html:
usuario@nginx2:~$ echo "<h1>Este es el Servidor Web NGINX del Nodo 2</h1>" | sudo tee /var/www/html/index.nginx-debian.html
3. Instalación de Keepalived
3.1 ¿Qué es Keepalived?
Keepalived es una herramienta de software que nos permite implementar VRRP en una red. Facilita la comunicación entre los enrutadores participantes en VRRP para determinar cuál es el enrutador activo y cuál es el de respaldo. Si el enrutador activo falla o ocurre un error, el enrutador de respaldo toma el control y comienza a dirigir el tráfico de red.
3.2 Configuración de Keepalived
El siguiente paso es habilitar la configuración de alta disponibilidad mediante la instalación del paquete Keepalived en ambos nodos.
usuario@nginx:~$ apt install keepalived
Nodo 1
Los VRRPs se configuran en ambos nodos a través del archivo /etc/keepalived/keepalived.conf.
global_defs { vrrp_version 3 } vrrp_script chk_manual_failover { script "/usr/libexec/keepalived/nginx-ha-manual-failover" interval 10 weight 50 } vrrp_script check_nginx { script "/bin/check_nginx.sh" interval 2 weight 50 } vrrp_instance VI_1 { interface enp0s9 priority 100 virtual_router_id 51 advert_int 1 unicast_src_ip 192.168.100.10 unicast_peer { 192.168.100.20 } virtual_ipaddress { 192.168.100.99 } track_script { check_nginx chk_manual_failover } notify "/usr/libexec/keepalived/nginx-ha-notify" }
Es momento de explicar los parámetros esenciales que han sido configurados en el archivo.
Primero, hemos configurado un mecanismo de verificación para determinar si el servicio Nginx está activo. Si está inactivo, el servicio Keepalived redirige automáticamente el tráfico al nodo con mayor prioridad.
Este script de verificación se puede crear de varias formas, como construirlo manualmente o usar una librería existente como nginx-ha-check. Si optamos por hacerlo manualmente, podemos crear un pequeño script que devuelva el ID de proceso de Nginx.
usuario@nginx1:~$ sudo vi /bin/check_nginx.sh #!/bin/sh if [ -z "`pidof nginx`" ]; then exit 1 fi usuario@nginx1:~$ sudo chmod 755 /bin/check_nginx.sh
El siguiente paso es configurar las instancias VRRP. Cada una de ellas está asociada con una IP virtual diferente, con un nombre específico (por ejemplo, VI_1) para identificarlas fácilmente.
- Interface: El nombre de la interfaz de red donde tendremos la IP Virtual.
- Priority: La prioridad, siendo 100 la más alta. Cada máquina recibirá un número más bajo que la anterior, para que la IP virtual priorice las primeras máquinas. En caso de falla, elegirá la siguiente con la prioridad más alta (99) y así sucesivamente.
- Unicast_src_ip: La IP del nodo donde se está configurando Keepalived.
- Unicast_peer: La lista de IPs a las que redirigir el tráfico en caso de problemas.
- Virtual_ipaddress: Donde se agregará la nueva IP de la interfaz.
Nodo 2
Es momento de configurar el segundo nodo.
usuario@nginx2:~$ sudo cat /etc/keepalived/keepalived.conf global_defs { vrrp_version 3 } vrrp_script chk_manual_failover { script "/usr/libexec/keepalived/nginx-ha-manual-failover" interval 10 weight 50 } vrrp_script check_nginx { script "/bin/check_nginx.sh" interval 2 weight 50 } vrrp_instance VI_1 { interface enp0s9 priority 99 virtual_router_id 51 advert_int 1 unicast_src_ip 192.168.100.20 unicast_peer { 192.168.100.10 } virtual_ipaddress { 192.168.100.99 } track_script { check_nginx chk_manual_failover } notify "/usr/libexec/keepalived/nginx-ha-notify" }
La configuración del segundo nodo es similar a la anterior, pero algunos parámetros necesitan ser modificados.
- Es necesario establecer un número de prioridad más bajo que el del primer nodo en el clúster.
- Modificaremos la configuración de la opción unicast_src_ip, estableciendo la dirección IP de este nodo como su valor.
- Finalmente, ya que solo hay dos nodos, la lista de direcciones IP de la opción unicast_peer se actualizará añadiendo la dirección IP del primer nodo en el clúster. Si este nodo falla, el primer nodo del clúster tomará automáticamente el control si está activo.
4. Activación del servicio Keepalived y verificación del clúster
Una vez configurados ambos nodos, se debe activar el servicio Keepalived y ejecutar las verificaciones necesarias para asegurarse de que el clúster esté funcionando correctamente.
usuario@nginx1:~$ sudo systemctl start keepalived usuario@nginx2:~$ sudo systemctl start keepalived usuario@nginx1:~$ ip a
Cuando el servicio Keepalived esté activo, se realizarán las verificaciones necesarias para garantizar que el clúster esté funcionando correctamente. El comando ip a se ejecutará para verificar la lista de direcciones IP y asegurarse de que la dirección IP virtual se haya agregado correctamente a nuestra interfaz de red.
Como puedes ver, la dirección IP 192.168.100.99 se ha agregado exitosamente a la interfaz enp0s9 que configuramos. Realizaremos la misma verificación en el segundo nodo del clúster para confirmar que se ha añadido correctamente.
usuario@nginx2:~$ ip a
En este nodo, no se encontrará la dirección IP virtual, ya que solo puede existir en un único nodo, el nodo activo en el clúster. Hacer una solicitud web a la dirección IP virtual nos permite verificar que el primer nodo está respondiendo correctamente.
Prueba de Conmutación por Fallo
Detendremos el servicio Keepalived en el nodo 1 para mostrar cómo funciona la conmutación por fallo. Esto hará que la IP virtual se transfiera al segundo nodo y el tráfico se redirigirá a esta máquina.
usuario@nginx1:~$ sudo systemctl stop keepalived
La IP virtual se ha movido correctamente al segundo nodo, como se puede verificar. Realizar una comprobación web demostrará que el nodo 2 está respondiendo correctamente.
5. Habilitar/Deshabilitar Keepalived
Si necesitamos desactivar o activar Keepalived para que la IP Virtual pueda ser utilizada en otras máquinas, solo habrá que desactivar Keepalived. Esto se logra mediante el comando systemctl stop keepalived.service en la consola de los balanceadores de carga.
Además, este proceso puede automatizarse a través de una tarea de Jenkins configurando parámetros, lo que facilita realizar esta acción sin acceder manualmente a las máquinas.
De esta manera, es sencillo redirigir el tráfico a otro nodo con solo un clic, algo útil para realizar mantenimiento en uno de los nodos sin interrumpir ningún servicio. Esto se hace sin necesidad de reiniciar.
6. Conclusión
Keepalived es una plataforma muy poderosa para balancear cargas y mantener servicios de red en Alta Disponibilidad. Es fácil de configurar e instalar, ya que está compilada y empaquetada en los repositorios de la mayoría de las distribuciones de Linux.
