Keepalived: configuración de alta disponibilidad con conmutación por error de IP en CentOS / RHEL

En este artículo, consideraremos una configuración de conmutación por error de alta disponibilidad de dos servidores proxy squid (Linux) para acceder a Internet desde una LAN corporativa. Para crear una configuración de conmutación por error, crearemos un clúster de alta disponibilidad utilizando mantener vivo.
Un clúster de alta disponibilidad es un grupo de servidores con redundancia incorporada para minimizar el tiempo de inactividad de la aplicación en caso de problemas de hardware o software de cualquiera de los servidores del grupo. De acuerdo con esta definición, se debe implementar lo siguiente para el correcto funcionamiento de un clúster HA:

• La verificación del estado del servidor;
• El cambio automático de recursos en caso de falla del servidor.

Keepalived habilita ambos. Keepalived es un demonio del sistema en los sistemas Linux que permite la conmutación por error del servicio y el equilibrio de carga. La conmutación por error se proporciona mediante una dirección IP flotante que se cambia a otro servidor si falla el principal. Para cambiar automáticamente la dirección IP entre los servidores, keepalived está utilizando el VRRP (Protocolo de redundancia de enrutador virtual: https://www.ietf.org/rfc/rfc2338.txt).

Principios de VRRP

En primer lugar, consideremos algunas teorías y las principales definiciones de VRRP.

• VIP: IP virtual, una dirección IP virtual capaz de cambiar automáticamente entre los servidores en caso de falla;
• Maestro: un servidor en el que el VIP está activo actualmente;
• Respaldo: servidores a los que el VIP cambiará en caso de falla del Maestro;
• VRID: ID de enrutador virtual, los servidores que comparten una IP virtual (VIP) forman un llamado enrutador virtual y su identificador único puede tener un valor entre 1 y 255. Un servidor puede pertenecer a varios VRID a la vez, pero cada VRID debe tener una dirección IP virtual única.

Algoritmo de funcionamiento básico:

Instalar y configurar keepalived en CentOS

Instalaremos y configuraremos keepalived en dos servidores Linux (proxy-serv01 y proxy-serv02) que ejecutan CentOS 7 con Squid instalado. En nuestro esquema, usaremos el método más simple de balanceo de carga: DNS de Round Robin. Este método sugiere que un solo nombre DNS tiene varias direcciones IP registradas y los clientes obtienen estas direcciones una por una. Por lo tanto, necesitaremos dos direcciones IP virtuales registradas para un nombre DNS (proxy-serv). Aquí está el diagrama de red:

Cada servidor Linux tiene dos interfaces de red físicas: eth1 con la dirección IP pública (blanca) y eth0 en la red local.

Las siguientes direcciones IP de servidor se utilizan como reales:

192.168.2.251 — for proxy-server01
192.168.2.252 — for proxy-server02

Las siguientes direcciones IP se utilizarán como virtuales que se cambian automáticamente entre servidores en caso de falla:

192.168.2.101
192.168.2.102

Importante. Cuando configure VRRP, nunca use la dirección IP del servidor real como una virtual, ya que en caso de que un servidor falle, su dirección se moverá al siguiente servidor, y después de la conmutación por recuperación, el primer servidor puede quedar aislado de la red. El asunto es que para recuperar la dirección IP, un servidor tiene que enviar paquetes VRRP a la red, pero no tiene una dirección IP desde la que hacerlo.

Puede instalar keepalived en ambos servidores usando el administrador de paquetes yum (o dnf en CentOS 8):

# yum install keepalived

Una vez completada la instalación en ambos servidores, cambie el archivo de configuración keepalived en ambos servidores:

# nano /etc/keepalived/keepalived.conf

Se resaltan las líneas con diferentes parámetros:

proxy-serv01	proxy-serv02
1	2

Describamos las opciones con más detalle:

1. vrrp_instance : es la sección que define una instancia de VRRP;
2. state - es el estado inicial del nodo al inicio;
3. interface : es la interfaz en la que se ejecuta VRRP;
4. virtual_router_id : es el identificador único de instancia de VRRP, debe ser el mismo en todos los servidores;
5. prioridad : establece la prioridad del servidor, un servidor con una prioridad más alta se convierte en MAESTRO;
6. virtual_ipaddress - es un bloque de direcciones IP virtuales activas en un servidor en el estado MASTER. Deben ser iguales en todos los servidores dentro de la instancia VRRP

Nota. Puede encontrar muchos ejemplos cuando autenticación La opción se utiliza en la configuración de VRRP. sin embargo, el mantener vivo La documentación menciona que la autenticación se eliminó de VRRPv2 en la especificación RFC3768 (https://tools.ietf.org/html/rfc3768) en 2004, ya que no había proporcionado seguridad real. No se recomienda utilizar esta opción de configuración.

Si la configuración de red actual no permite el uso de multidifusión, keepalived proporciona una opción de unidifusión, es decir, los paquetes de latido VRRP se enviarán a los servidores directamente de acuerdo con la lista. Para usar unidifusión, necesitará las siguientes opciones:

• unicast_src_ip: es la dirección de origen de los paquetes VRRP
• unicast_peer: es el bloque de direcciones IP del servidor al que se enviarán los paquetes VRRP.

Por lo tanto, nuestra configuración define dos instancias de VRRP, proxy_ip1 y proxy_ip2. En la operación regular, proxy-serv01 será el MASTER para la IP virtual 192.168.2.101 y el BACKUP para 192.168.2.102, y viceversa, proxy-serv02 será el MASTER para la IP virtual 192.168.2.102, y el BACKUP para 192.168.2.101.

Si se activa un firewall en un servidor, deberá agregar reglas de autorización para el tráfico de multidifusión y VRRP mediante iptables:

# iptables -A INPUT -i eth0 -d 224.0.0.0/8 -j ACCEPT
# iptables -A INPUT -p vrrp -i eth0 -j ACCEPT

Habilite el servicio keepalived para el inicio automático en el arranque del sistema y ejecútelo en ambos servidores

# systemctl enable keepalived
# systemctl start keepalived

Después de que se haya iniciado keepalived, las direcciones IP virtuales se asignarán a las interfaces desde su archivo de configuración. Veamos las direcciones IP eth0 actuales de los servidores:

# ip a show eth0

En proxy-serv01:

En proxy-serv02:

¿Cómo realizar una verificación de estado de la aplicación o interfaz con Keepalived?

El protocolo VRRP proporciona la supervisión del estado del servidor. Por ejemplo, esto es útil en caso de una falla del servidor físico o del puerto NIC del conmutador / servidor. Sin embargo, también pueden ocurrir otros problemas:

• Un error del servidor proxy (u otra aplicación) - los clientes que accedan a la dirección virtual del servidor recibirán un mensaje de error en sus navegadores de que el servidor proxy no está disponible;
• La falla de acceso a Internet de la segunda interfaz. - Los clientes que accedan a la dirección virtual del servidor recibirán un mensaje de error en sus navegadores de que no se pudo establecer la conexión.

Para manejar las situaciones descritas anteriormente, use las siguientes opciones:

• track_interface - supervisa el estado de la interfaz y establece el estado FALLO para una instancia de VRRP si una de las interfaces enumeradas está en ABAJO;
• track_script - realiza una verificación de estado de su aplicación HA utilizando un script que devuelve 0 si la verificación ha sido exitosa, o 1 si la verificación falló.

Actualice la configuración agregando la supervisión de la interfaz eth1 (de forma predeterminada, la instancia de VRRP verificará la interfaz a la que está vinculada: es eth0 en la configuración actual).

track_interface {
  eth1
}

La directiva track_script ejecuta un script con los parámetros determinados por el bloque vrrp_script en el siguiente formato:

vrrp_script <name> {
 script <"path to the executable file">
 interval <number, seconds> - the periodicity of running the script, 1 second by default
 fall <number> - the number of times when the script has returned a value different from zero to switch to the FAULT state
 rise <number> - the number of times when the script has returned a zero value to get out of the FAULT state (failback)
 timeout <number> - the time to wait till the script returns the result ( if time is up, the script returns a non-zero value_
 weight <number> - the value, by which the server priority will be decreased in case it gets the FAULT state. The default value is 0, which means that the server gets the FAULT state after the script has failed for a number of times set in the fall parameter
}

Configuremos la verificación de estado del proxy Squid. Con este comando, puede verificar si el proceso de calamar está activo:

# squid -k check

Cree vrrp_script que se ejecuta cada 3 segundos. Este bloque se define fuera de los bloques vrrp_instance.

vrrp_script chk_squid_service {
 script "/usr/sbin/squid -k check"
 interval 3
}

Agregue este script a la supervisión en ambos bloques vrrp_instance:

track_script {
 chk_squid_service
}

Si Squid falla, la dirección IP virtual se cambiará a otro servidor.

Puede especificar cualquier acciones adicionales debe hacerse si cambia el estado del servidor.

Si Squid está configurado para aceptar conexiones desde cualquier interfaz, es decir http_port 0.0.0.0:3128, no ocurrirán problemas cuando se cambie la dirección IP virtual, y Squid aceptará conexiones a la nueva dirección. Sin embargo, si se configuran las direcciones IP específicas, por ejemplo:

http_port 192.168.2.101:3128
http_port 192.168.2.102:3128

Squid no sabrá que ha aparecido una nueva dirección en el sistema para escuchar las solicitudes de los clientes. Para manejar las situaciones en las que son necesarias algunas acciones adicionales cuando se ha cambiado la dirección IP virtual, keepalived permite ejecutar un script si el estado del servidor cambia, por ejemplo, de MASTER a BACKUP, o viceversa. Se implementa usando esta opción:

notify "path to the executable file"

Prueba de la conmutación por error de Keepalived en caso de una falla

Una vez que haya configurado las direcciones IP virtuales, asegúrese de que las fallas se manejen correctamente. La primera comprobación es una simulación de fallo del servidor. Desactive eth0 en proxy-serv01 y dejará de enviar paquetes de latido VRRP. El proxy-serv02 debe activar la dirección IP virtual 192.168.2.101. Compruébalo con este comando:

# ip a show eth0

En proxy-serv01:

En proxy-serv02:

Como se esperaba, proxy-serv02 activó la dirección IP virtual 192.168.2.101. Veamos qué se ha escrito en los registros usando el siguiente comando:

cat /var/log/messages | grep -i keepalived

Keepalived_vrrp[xxxxx]:

Kernel is reporting: interface eth0 DOWN
Keepalived_vrrp[xxxxx]:
VRRP_Instance(proxy_ip1) Entering FAULT STATE
Keepalived_vrrp[xxxxx]:
VRRP_Instance(proxy_ip1) removing protocol VIPs.
Keepalived_vrrp[xxxxx]:
VRRP_Instance(proxy_ip1) Now in FAULT state

Keepalived_vrrp[xxxxx]:
VRRP_Instance(proxy_ip1) Transition to MASTER STATE

Y asegúrese de que cuando habilite eth0 en proxy-serv01 nuevamente, la dirección IP virtual 192.168.2.101 vuelva a cambiar.

Keepalived_vrrp[xxxxx]:
VRRP_Instance(proxy_ip1) forcing a new MASTER election
Keepalived_vrrp[xxxxx]:
VRRP_Instance(proxy_ip1) Transition to MASTER STATE
Keepalived_vrrp[xxxxx]:
VRRP_Instance(proxy_ip1) Entering MASTER STATE
Keepalived_vrrp[xxxxx]:
VRRP_Instance(proxy_ip1) setting protocol VIPs.
Keepalived_vrrp[xxxxx]:
Sending gratuitous ARP on eth0 for 192.168.2.101

Keepalived_vrrp[xxxxx]:
VRRP_Instance(proxy_ip1) Received advert with higher priority 255, ours 100
Keepalived_vrrp[xxxxx]:
VRRP_Instance(proxy_ip1) Entering BACKUP STATE
Keepalived_vrrp[xxxxx]:
VRRP_Instance(proxy_ip1) removing protocol VIPs.

La segunda comprobación es la simulación del fallo de la interfaz de red externa. Para hacerlo, desactive la interfaz de red externa eth1 en proxy-serv01. Vea los resultados en los registros.

Keepalived_vrrp[xxxxx]:
Kernel is reporting: interface eth1 DOWN
Keepalived_vrrp[xxxxx]:
VRRP_Instance(proxy_ip1) Entering FAULT STATE
Keepalived_vrrp[xxxxx]:
VRRP_Instance(proxy_ip1) removing protocol VIPs.
Keepalived_vrrp[xxxxx]:
VRRP_Instance(proxy_ip1) Now in FAULT state

Keepalived_vrrp[xxxxx]:
VRRP_Instance(proxy_ip1) Transition to MASTER STATE
Keepalived_vrrp[xxxxx]:
VRRP_Instance(proxy_ip1) Entering MASTER STATE
Keepalived_vrrp[xxxxx]:
VRRP_Instance(proxy_ip1) setting protocol VIPs.
Keepalived_vrrp[xxxxx]:
Sending gratuitous ARP on eth0 for 192.168.2.101

La tercera comprobación es la simulación de una falla de Squid. Para hacerlo, detenga el servicio manualmente usando este comando:

# systemctl stop squid

Ver los resultados en los registros:

Keepalived_vrrp[xxxxx]:
VRRP_Script(chk_squid_service) failed
Keepalived_vrrp[xxxxx]:
VRRP_Instance(proxy_ip1) Entering FAULT STATE
Keepalived_vrrp[xxxxx]:
VRRP_Instance(proxy_ip1) removing protocol VIPs.
Keepalived_vrrp[xxxxx]:
VRRP_Instance(proxy_ip1) Now in FAULT state

Keepalived_vrrp[xxxxx]:
VRRP_Instance(proxy_ip1) Transition to MASTER STATE
Keepalived_vrrp[xxxxx]:
VRRP_Instance(proxy_ip1) Entering MASTER STATE
Keepalived_vrrp[xxxxx]:
VRRP_Instance(proxy_ip1) setting protocol VIPs.
Keepalived_vrrp[xxxxx]:
Sending gratuitous ARP on eth0 for 192.168.2.101

Las tres comprobaciones se aprobaron correctamente y keepalived está configurado correctamente. Más adelante, configuraremos un clúster de alta disponibilidad con Pacemaker y describiremos sus características.

El archivo de configuración final /etc/keepalived/keepalived.conf por proxy-serv01:

vrrp_script chk_squid_service {
 script "/usr/sbin/squid -k check"
 interval 3
}
 vrrp_instance proxy_ip1 {
 state MASTER
 interface eth0
 virtual_router_id 1
 priority 255
 virtual_ipaddress {
  192.168.2.101/24 dev eth0 label eth0:1
 }
 track_interface {
  eth1
 }
 track_script {
  chk_squid_service
 }
}
vrrp_instance proxy_ip2 {
 state BACKUP
 interface eth0
 virtual_router_id 2
 priority 100
 virtual_ipaddress {
  192.168.2.102/24 dev eth0 label eth0:2
 }
 track_interface {
  eth1
 }
 track_script {
  chk_squid_service
 }
}

The final configuration file /etc/keepalived/keepalived.conf for proxy-serv02:

vrrp_script chk_squid_service {
 script "/usr/sbin/squid -k check"
 interval 3
}
vrrp_instance proxy_ip1 {
 state BACKUP
 interface eth0
 virtual_router_id 1
 priority 100
 virtual_ipaddress {
  192.168.2.101/24 dev eth0 label eth0:1
 }
 track_interface {
  eth1
 }
 track_script {
  chk_squid_service
 }
}
vrrp_instance proxy_ip2 {
 state MASTER
 interface eth0
 virtual_router_id 2
 priority 255
 virtual_ipaddress {
  192.168.2.102/24 dev eth0 label eth0:2
}
 track_interface {
  eth1
 }
 track_script {
  chk_squid_service
 }
}