8 votos

keepalived no detecta la pérdida de IP virtual

Estoy usando keepalived para cambiar una IP flotante entre dos máquinas virtuales.

/etc/keepalived/keepalived.conf en VM 1:

vrrp_instance VI_1 {
    state MASTER
    interface ens160
    virtual_router_id 101
    priority 150
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass secret
    }
    virtual_ipaddress {
        1.2.3.4
    }
}

/etc/keepalived/keepalived.conf en VM 2:

vrrp_instance VI_1 {
    state MASTER
    interface ens160
    virtual_router_id 101
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass secret
    }
    virtual_ipaddress {
        1.2.3.4
    }
}

Básicamente, esto funciona bien, con una excepción: cada vez que systemd se actualiza (se está ejecutando Ubuntu 18.04) se vuelve a cargar el componente de red, lo que resulta en la caída del flotante IP, ya que no está configurado en el sistema. Ya que ambos keepalived casos todavía pueden hacer ping entre sí, ninguno de ellos se ve nada mal y ninguno de ellos reacciona de esta, lo que resulta en el flotante IP quedarse abajo.

He encontrado que se puede comprobar la IP con un simple script como este:

vrrp_script chk_proxyip {
    script "/sbin/ip addr |/bin/grep 1.2.3.4"
}

vrrp_instance VI_1 {
    # [...]
    track_script {
        chk_proxyip
    }
}

Pero no estoy seguro de si se trata de un enfoque de trabajo.

Si he entendido correctamente, pasaría lo siguiente, si puedo configurar esta secuencia de comandos en VM1:

  1. VM1 pierde la IP debido a un systemd reiniciar
  2. keepalived en VM1 detecta la pérdida de la IP
  3. keepalived cambia a FAULT estado y deja de radiodifusión paquetes vrrp
  4. keepalived en VM2 detecta la pérdida de keepalived en VM1 y pone la IP flotante hasta

En este punto, la IP es trabajar de nuevo en VM2, pero VM1 iba a permanecer en este estado debido a la IP nunca viene de nuevo en VM1. Si VM2 va hacia abajo (por cualquier razón) VM1 no se apoderan de él, ya que aún está en FAULT del estado.

Cómo puedo asegurarme de que el flotante IP es siempre una de las máquinas virtuales?

Más pruebas:

He probado a hacer ping a la IP flotante en lugar de comprobar si está activo en un host específico en un check_script:

vrrp_script chk_proxyip {
    script "/bin/ping -c 1 -w 1 1.2.3.4"
    interval 2
}

La configuración de esta secuencia de comandos en el nodo 2 resultaron los siguientes:

  1. quita la IP en el nodo 1 para las pruebas
  2. el nodo 2 se detecta la IP de la pérdida y cambiado de BACKUP a FAULT
  3. nodo 1 ignoran el cambio de estado y se quedó MASTER

El resultado: la IP se quedó abajo.

Configurar la secuencia de comandos en el nodo 1 dio como resultado el siguiente:

  1. quita la IP en el nodo 1
  2. el nodo 1 se detecta la IP de la pérdida y cambiado de MASTER a FAULT
  3. el nodo 2 se detecta el cambio de estado en el nodo 1 y cambiado de BACKUP a MASTER, la configuración de la IP flotante en el nodo 2

Bueno, y entonces ...

Feb 13 10:11:26 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Transition to MASTER STATE
Feb 13 10:11:27 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Entering MASTER STATE
Feb 13 10:11:29 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Received advert with higher priority 150, ours 100
Feb 13 10:11:29 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Entering BACKUP STATE
Feb 13 10:11:32 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Transition to MASTER STATE
Feb 13 10:11:33 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Entering MASTER STATE
Feb 13 10:11:36 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Received advert with higher priority 150, ours 100
Feb 13 10:11:36 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Entering BACKUP STATE
Feb 13 10:11:38 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Transition to MASTER STATE
Feb 13 10:11:39 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Entering MASTER STATE
Feb 13 10:11:41 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Received advert with higher priority 150, ours 100
Feb 13 10:11:41 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Entering BACKUP STATE
Feb 13 10:11:44 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Transition to MASTER STATE
Feb 13 10:11:45 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Entering MASTER STATE
Feb 13 10:11:47 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Received advert with higher priority 150, ours 100
...

Tuve que reiniciar keepalived en el nodo1 para detener el juego de ping pong entre los nodos.

0voto

clockworknet Puntos 144

Creo que su enfoque general está bien, pero que necesita repensar su condición de prueba. La condición de que le preocupa, es si systemd es el reinicio de la red de infraestructura (la consecuencia indirecta de que ser, si o no su VIP), así que eso es lo que usted necesita para comprobar.

No tengo un sistema que me puede probar fácilmente en mientras escribo esto, así que YMMV, sin embargo systemctl is-active network.service puede ser suficiente para cubrir esto. A falta de comprobar el estado de systemctl show network.service | grep 'ActiveState' para un estado de "activa" debe hacerlo.

Como un aparte, si uno de los nodos no ser configurado con el estado 'COPIA de seguridad', en lugar de tanto como 'MAESTRO'?

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: