Keepalive y alta disponibilidad: temas avanzados

Si leyó mi primer artículo sobre el uso de Keepalived para administrar la conmutación por error simple en clústeres, recordará que VRRP utiliza el concepto de prioridad para determinar qué servidor será el maestro activo. El servidor con la prioridad más alta "gana" y actuará como maestro, conservando el VIP y las solicitudes de servicio. Keepalived proporciona varios métodos útiles para ajustar la prioridad según el estado de su sistema. En este artículo, explorará varios de estos mecanismos, así como Keepalivedla capacidad de ejecutar scripts cuando cambia el estado de un servidor.

Solo mostraré la configuración en el servidor 1 para estos ejemplos. En este punto, probablemente se sienta cómodo con la configuración necesaria en el servidor 2 si ha leído toda la serie. De lo contrario, tómese un momento para revisar el primer y segundo artículo de esta serie antes de continuar.

Keepalived hace un gran trabajo al desencadenar una conmutación por error cuando no se reciben anuncios, como cuando el maestro activo muere por completo o no se puede contactar por alguna otra razón. Sin embargo, a menudo encontrará que se requieren mecanismos de disparo más finos. Por ejemplo, su aplicación puede ejecutar sus propias comprobaciones de estado para determinar la capacidad de la aplicación para responder a las solicitudes de los clientes. No querría que un servidor de aplicaciones en mal estado siguiera siendo el maestro activo solo porque estaba activo y enviando VRRP anuncio publicitario.

Nota: encontré que la versión de Keepalived disponible a través de los repositorios de paquetes estándar contenía errores que impedían que algunos de los ejemplos a continuación funcionaran correctamente. Si tiene algún problema, puede instalar Keepalived de la fuente, como se describe en el artículo anterior.

Índice

Proceso de seguimiento

Uno de los más comunes Keepalived Las configuraciones implican monitorear un proceso en el servidor para determinar la salud del host. Por ejemplo, puede configurar un par de servidores web de alta disponibilidad y activar la conmutación por error si Apache deja de ejecutarse en uno de ellos.

Keepalived te lo pone fácil con su track_process instrucciones de configuración. En el siguiente ejemplo, he configurado Keepalived mira el httpd proceso con un peso de 10. Mientras httpd se está ejecutando, la prioridad anunciada será 254 (244 + 10 = 254). sí httpd se detiene, la prioridad cambia a 244 y desencadena una conmutación por error (suponiendo que exista una configuración similar en el servidor 2).

server1# cat keepalived.conf
vrrp_track_process track_apache {
      process httpd
      weight 10
}

vrrp_instance VI_1 {
      state MASTER
      interface eth0
      virtual_router_id 51
      priority 244
      advert_int 1
      authentication {
         auth_type PASS
         auth_pass 12345
      }
      virtual_ipaddress {
         192.168.122.200/24
      }
      track_process {
         track_apache
      }
}

Con esta configuración en su lugar (y Apache instalado y ejecutándose en ambos servidores), puede probar un escenario de conmutación por error apagando Apache y observando el cambio de VIP del servidor 1 al servidor 2:

server1# ip -br a
lo               UNKNOWN        127.0.0.1/8 ::1/128
eth0             UP             192.168.122.101/24 192.168.122.200/24 fe80::5054:ff:fe82:d66e/64

server1# systemctl stop httpd

server1# ip -br a
lo               UNKNOWN        127.0.0.1/8 ::1/128
eth0             UP             192.168.122.101/24 fe80::5054:ff:fe82:d66e/64
server2# ip -br a
lo               UNKNOWN        127.0.0.1/8 ::1/128
eth0             UP             192.168.122.102/24 192.168.122.200/24 fe80::5054:ff:fe04:2c5d/64

Archivos de rastreo

Keepalived también tiene la capacidad de tomar decisiones de prioridad basadas en el contenido de un archivo, lo que puede ser útil si está ejecutando una aplicación que puede escribir valores en ese archivo. Por ejemplo, es posible que tenga un proceso en segundo plano en su aplicación que verifique periódicamente el estado y escriba un valor en un archivo según el estado general de la aplicación.

el Keepalived hombre explica que el seguimiento de archivos se basa en el peso configurado para el archivo:

Lo mantendré simple y usaré un peso de 1 para el archivo de seguimiento en este ejemplo. Esta configuración tomará el valor numérico en el archivo para /var/run/my_app/vrrp_track_file y lo multiplicas por 1.

server1# cat keepalived.conf
vrrp_track_file track_app_file {
      file /var/run/my_app/vrrp_track_file
}

vrrp_instance VI_1 {
      state MASTER
      interface eth0
      virtual_router_id 51
      priority 244
      advert_int 1
      authentication {
         auth_type PASS
         auth_pass 12345
      }
      virtual_ipaddress {
         192.168.122.200/24
      }
      track_file {
         track_app_file weight 1
   }
}

Ahora puede crear el archivo con un valor inicial y reiniciar Keepalived. La prioridad se puede ver en tcpdump salida, como se analiza en el segundo artículo de esta serie.

server1# mkdir /var/run/my_app
server1# echo 5 > /var/run/my_app/vrrp_track_file
server1# systemctl restart keepalived
server1# tcpdump proto 112
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
16:19:32.191562 IP server1 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 249, authtype simple, intvl 1s, length 20

Puede ver que la prioridad anunciada es 249, que es el valor en el archivo (5) multiplicado por el peso (1) y sumado a la prioridad base (244). Del mismo modo, ajustar la prioridad a 6 aumentará la prioridad:

server1# echo 6 > /var/run/my_app/vrrp_track_file
server1# tcpdump proto 112
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
16:20:43.214940 IP server1 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 250, authtype simple, intvl 1s, length 20

Interfaz de seguimiento

Para servidores con múltiples interfaces, puede ser útil ajustar la prioridad de Keepalived instancia dependiendo del estado de una interfaz. Por ejemplo, un equilibrador de carga con una dirección IP virtual de front-end y una conexión de back-end a una red interna podría querer activar una Keepalived conmutación por error si falla la conexión a la red principal. Esto se puede lograr con la configuración track_interface:

server1# cat keepalived.conf
vrrp_instance VI_1 {
      state MASTER
      interface eth0
      virtual_router_id 51
      priority 244
      advert_int 1
      authentication {
         auth_type PASS
         auth_pass 12345
      }
      virtual_ipaddress {
         192.168.122.200/24
      }
      track_interface {
         ens9 weight 5
      }
}

La configuración anterior asigna un peso de 5 al estado de la interfaz ens9. Esto hará que server1 asuma una prioridad de 249 (244 + 5 = 249) siempre que ens9 esté activo. Si ens9 falla, la prioridad se reducirá a 244 (y desencadenará una conmutación por error, suponiendo que el servidor 2 esté configurado de la misma manera). Puede probar esto en un servidor multi-interfaz deshabilitando una interfaz y observando el movimiento VIP entre hosts:

server1# ip -br a
lo               UNKNOWN        127.0.0.1/8 ::1/128
eth0             UP             192.168.122.101/24 192.168.122.200/24 fe80::5054:ff:fe82:d66e/64
ens9             UP             192.168.122.15/24 fe80::7444:5ec4:8015:722f/64

server1# ip link set ens9 down

server1# ip -br a
lo               UNKNOWN        127.0.0.1/8 ::1/128
eth0             UP             192.168.122.101/24 fe80::5054:ff:fe82:d66e/64
ens9             DOWN   
server2# ip -br a
lo               UNKNOWN        127.0.0.1/8 ::1/128
ens9             UP             192.168.122.119/24 fe80::fc9f:8999:b93e:d491/64
eth0             UP             192.168.122.102/24 192.168.122.200/24 fe80::5054:ff:fe04:2c5d/64

Seguimiento de escenario

Viste eso Keepalived ofrece muchos métodos de verificación incorporados útiles para determinar el estado de salud y los resultados posteriores VRRP prioridad de un anfitrión. Sin embargo, a veces, los entornos más complejos requieren el uso de herramientas personalizadas, como secuencias de comandos de verificación de estado, para satisfacer sus necesidades. Por suerte, Keepalived también tiene la capacidad de ejecutar un script arbitrario para determinar la salud de un host. Puede ajustar el peso de la secuencia de comandos, pero lo mantendré simple para este ejemplo: una secuencia de comandos que devuelve 0 indicará éxito, mientras que una secuencia de comandos que devuelve otra cosa indicará que el Keepalived la instancia debe entrar en el estado de error.

El guión es un simple ping al favorito de todos. 8.8.8.8 El servidor DNS de Google, como se muestra a continuación. En su entorno, probablemente utilizará un script más complejo para realizar las comprobaciones de estado que necesita.

server1# cat /usr/local/bin/keepalived_check.sh
#!/bin/bash

/usr/bin/ping -c 1 -W 1 8.8.8.8 > /dev/null 2>&1

Notarás que usé un tiempo de espera de 1 segundo para ping (-W 1). Cuando se escribe Keepalived revise los guiones, es una buena idea mantenerlos ligeros y rápidos. No desea que un servidor inactivo sea el maestro durante mucho tiempo porque su secuencia de comandos es lenta.

el Keepalived la configuración de un script de verificación se muestra a continuación:

server1# cat keepalived.conf
vrrp_script keepalived_check {
      script "/usr/local/bin/keepalived_check.sh"
      interval 1
      timeout 5
      rise 3
      fall 3
}

vrrp_instance VI_1 {
      state MASTER
      interface eth0
      virtual_router_id 51
      priority 244
      advert_int 1
      authentication {
         auth_type PASS
         auth_pass 12345
      }
      virtual_ipaddress {
         192.168.122.200/24
      }
      track_script {
         keepalived_check
      }
}

Esto se parece mucho a la configuración con la que trabajó, pero el vrrp_script block tiene algunas directivas únicas:

  • interval: frecuencia de ejecución del script (1 segundo).
  • timeout: cuánto tiempo esperar para que regrese el script (5 segundos).
  • rise: cuántas veces la secuencia de comandos debe regresar con éxito para que el host se considere "saludable". En este ejemplo, el script debería tener éxito 3 veces. Esto evita una condición de "golpe" en la que un solo fallo (o éxito) hace que el Keepalived estado de mecerse rápidamente hacia adelante y hacia atrás.
  • fall: cuántas veces debe fallar la secuencia de comandos (o expirar el tiempo de espera) para que el host se considere "no saludable". Funciona como el reverso de la directiva rise.

Puede probar esta configuración forzando el error del script. En el siguiente ejemplo, agregué un iptables norma que impide la comunicación con 8.8.8.8. Esto provocó que la comprobación de estado fallara y el VIP desapareciera después de unos segundos. Luego puedo eliminar la regla y ver reaparecer el VIP.

server1# iptables -I OUTPUT -d 8.8.8.8 -j DROP
server1# ip -br a
lo               UNKNOWN        127.0.0.1/8 ::1/128
eth0             UP             192.168.122.101/24 fe80::5054:ff:fe82:d66e/64

server1# iptables -D OUTPUT -d 8.8.8.8 -j DROP
server1# ip -br a
lo               UNKNOWN        127.0.0.1/8 ::1/128
eth0             UP             192.168.122.101/24 192.168.122.200/24 fe80::5054:ff:fe82:d66e/64

Un consejo rápido sobre secuencias de comandos en Keepalived: Se pueden ejecutar como un usuario que no sea root. Aunque no he demostrado esto en estos ejemplos, eche un vistazo a la página del manual y asegúrese de que está usando el usuario con menos privilegios posible para evitar implicaciones de seguridad negativas para su secuencia de comandos de verificación.

Notificar secuencias de comandos

Discutí formas de desencadenar Keepalived respuestas basadas en condiciones externas. Sin embargo, probablemente también desee activar acciones cuando Keepalived transiciones de un estado a otro. Por ejemplo, es posible que desee detener un servicio cuando Keepalived ingresa al estado de guardado, o puede enviar un correo electrónico a un administrador. Keepalived le permite hacer esto con scripts de notificación.

Keepalived proporciona varias directivas de notificación para llamar solo a scripts en estados particulares (notify_master, notify_backup, etc.), pero me centraré en el desnudo notify Directiva porque es la más flexible. Cuando un guión en el notify es llamado, recibe cuatro argumentos adicionales (después de todos los argumentos pasados ​​al propio script).

Enumerados en orden, son:

  • Grupo o instancia: Indica si la notificación es provocada por un VRRP grupo (no cubierto en esta serie) o un individuo VRRP ejemplo.
  • Nombre de grupo o instancia
  • Indicar que el grupo o instancia está en transición a
  • La prioridad

Echando un vistazo a un ejemplo hace esto más claro. El escenario y Keepalived la configuración se ve así:

server1# cat /usr/local/bin/keepalived_notify.sh
#!/bin/bash

echo "$1 $2 has transitioned to the $3 state with a priority of $4" > /var/run/keepalived_status

server1# cat keepalived.conf
vrrp_script keepalived_check {
      script "/usr/local/bin/keepalived_check.sh"
      interval 1
      timeout 5
      rise 3
      fall 3
}

vrrp_instance VI_1 {
      state MASTER
      interface eth0
      virtual_router_id 51
      priority 244
      advert_int 1
      authentication {
         auth_type PASS
         auth_pass 12345
      }
      virtual_ipaddress {
         192.168.122.200/24
      }
      track_script {
         keepalived_check
      }
      notify "/usr/local/bin/keepalived_notify.sh"
}

La configuración anterior llamará al /usr/local/bin/keepalived_notify.sh guión cada vez que un Keepalived se produce la transición de estado. Dado que existe el mismo script de verificación, puede inspeccionar fácilmente el estado inicial y luego activar una transición:

server1# cat /var/run/keepalived_status
INSTANCE VI_1 has transitioned to the MASTER state with a priority of 244

server1# iptables -A OUTPUT -d 8.8.8.8 -j DROP
server1# cat /var/run/keepalived_status
INSTANCE VI_1 has transitioned to the FAULT state with a priority of 244

server1# iptables -D OUTPUT -d 8.8.8.8 -j DROP
server1# cat /var/run/keepalived_status
INSTANCE VI_1 has transitioned to the MASTER state with a priority of 244

Puede ver que los argumentos de la línea de comando corresponden a los que describí al principio de esta sección. Obviamente, este es un ejemplo simple, pero los scripts de notificación pueden realizar muchas acciones complejas, como ajustar las reglas de enrutamiento o activar otros scripts. Son una forma útil de emprender acciones externas basadas en Keepalived cambios de estado.

Envoltura

Este artículo concluye un estudio fundamental Keepalived serie con algunos conceptos avanzados. Aprendiste a disparar Keepalived cambios de prioridad y estado basados ​​en eventos externos, como el estado del proceso, cambios en la interfaz e incluso los resultados de scripts externos. También aprendió a activar secuencias de comandos de notificación en respuesta a Keepalived cambios de estado. Puede combinar dos o más de estos enfoques para crear un par de servidores Linux de alta disponibilidad que respondan a múltiples estímulos externos y garanticen que el tráfico siempre llegue a una dirección IP saludable que pueda satisfacer las solicitudes de los clientes.

Artículos de interés

Subir