keepalived VRRP_script no falla

10

Así que estoy ejecutando keepalived en dos servidores y no puedo hacer que la conmutación por error al otro.

A continuación tengo mi configuración para uno de los servidores. La única diferencia entre los dos es que el número de prioridad principal es 110 y el posterior 109.

Pero cuando detengo mi proceso con /etc/init.d/process stop keepalived no falla. Acabo de fallar el VRRP_Script (chk_script) y nada más. Sin failovers ni nada.

vrrp_script chk_script {
script "/usr/local/bin/failover.sh"
interval 2
weight 2
}

vrrp_instance HAInstance {
state BACKUP
interface eth0
virtual_router_id 8
priority 109
advert_int 1
nopreempt
vrrp_unicast_bind 10.10.10.8
vrrp_unicast_peer 10.10.10.9
virtual_ipaddress {
  10.10.10.10/16 dev eth0
}
notify /usr/local/bin/keepalivednotify.sh
track_script {
  chk_script weight 20
}
}

Este es mi chk_script a continuación. El mismo problema también ocurre cuando hago el proceso killall -0 como mi script.

!/bin/bash
SERVICE='process'
STATUS=$(ps ax | grep -v grep | grep $SERVICE)

if [ "$STATUS" != "" ]
then
    exit 0
else
    exit 1
fi

¿Alguien sabe una solución para esto? Gracias.

Nvasion
fuente
¿Su instancia de respaldo nota el cambio de prioridad o registra algo? Los registros de ambos serían útiles.
Jim G.
No, no lo hace. La única vez que nota un cambio es cuando el maestro se va. Como cuando me detengo keepalived. Detener el proceso que estoy monitoreando solo muestra que VRRP_Script (chk_script) falló en el maestro. Sin nada sobre el esclavo.
Nvasion

Respuestas:

12

Tuve exactamente el mismo problema, sin embargo, mi problema no estaba en el firewall ni en mi adaptador Ethernet, sino en la configuración de "peso" del script de verificación.

Esta fue mi configuración:

MAESTRO:

vrrp_instance haproxy {
state MASTER
interface eth0
virtual_router_id 51
priority 150
advert_int 1

APOYO:

vrrp_instance haproxy {
state BACKUP
interface eth0
virtual_router_id 51
priority 100
advert_int 1

Check_script:

vrrp_script chk_haproxy {
   script "python /root/ha_check.py"
   interval 2     # check every 2 seconds
   weight 2
   rise 2
   fall 2

}

La razón por la que el maestro se negaba a liberar el VIP fue porque, a pesar del hecho de que el script había fallado, el maestro aún tenía un número de prioridad más alto del servidor BACKUP. Esto sucedió porque la configuración de "peso" en check_script no fue suficiente para cubrir el "GAP" entre el número de prioridad, lo que significa aumentar el número de prioridad del servidor de RESPALDO mayor al del servidor MASTER. Explicaré más a fondo:

De acuerdo con el manual de keepalived, un número positivo en la configuración de "peso" agregará ese número a la prioridad si la verificación tiene éxito.
Un número negativo restará ese número del número de prioridad si la verificación falla.

Entonces, de acuerdo con mi configuración:

Prioridades del servidor Fallo previo de la secuencia de comandos:
MAESTRO: 152
COPIA DE SEGURIDAD: 100
Failover_IP: MASTER

La IP de conmutación por error es "capturada" correctamente por el servidor maestro ya que el Maestro tiene mayor prioridad en comparación con el servidor de Copia de seguridad (152> 100)

Prioridades del servidor DESPUÉS de la falla de la secuencia de comandos:
servidor MAESTRO: 148
servidor de COPIA DE SEGURIDAD: 102
Failover_IP: TODAVÍA EN EL MAESTRO

La IP de conmutación por error todavía está en el servidor maestro porque el Maestro tiene nuevamente una prioridad más alta en comparación con el RESPALDO (148> 102). El servidor MASTER se negaba a liberar la IP y lo hizo correctamente, ya que su prioridad era mayor que la del otro servidor.

La solución a mi situación fue:

Solución -1: cambie el número de prioridad de ambos servidores para que no tengan mucho "GAP".
Por ejemplo:
Prioridad maestra: 150
Prioridad de copia de seguridad: 149
Peso de Check_script: Tal como está (2).

Con la configuración anterior, cuando el script tiene éxito (lo que significa que todo está bien) las prioridades serían:
Maestro: 152
Copia de seguridad: 149
Ubicación_IP: En maestro (152> 149)

Cuando el script falla:
Maestro: 150
Copia de seguridad: 151
Ubicación_IP: En Copia de seguridad (151> 150)

Solución - 2: cambie el número de peso del script de 2 a -60

giomanda
fuente
También parece que no especificar un peso en absoluto significa que un track_script fallido activará el estado de falla directamente
Oscar
@Nvasion: amablemente acepte esta respuesta ya que yo también resolví mi problema.
Ankur Soni
4

He tenido el mismo problema: dos servidores CentOS 7.1 con track_script, y fallar el vrrp_script en el MASTER solo provocaría el mensaje de registro solitario "VRRP_Script (chk_script) falló", no en una conmutación por error. Sin embargo, en el servidor BACKUP, recibí muchos mensajes de keepalived tratando de tomar el control de la IP virtual durante todo el tiempo que fallaba el track_script en el servidor MASTER.

Solución en mi caso: el firewall (iptables) en el servidor MASTER no se configuró correctamente para permitir paquetes VRRP / paquetes de multidifusión, mientras que al mismo tiempo el firewall en el otro servidor, el BACKUP, se configuró correctamente.

Ingresé las mismas reglas de iptables en ambos servidores de la siguiente manera:

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

Esto funcionó en uno de los servidores (el servidor BACKUP VRRP) pero no en el MASTER porque había olvidado que la interfaz no se llamaba 'eth0' en el servidor MASTER, por lo que las dos reglas no tuvieron ningún efecto.

Esto explicaba el comportamiento que había observado:

Si keepalived no puede ver ningún otro altavoz VRRP para un cierto virtual_router_id, todavía cree que es el que tiene la prioridad más alta (por lo tanto, el MAESTRO legítimo) incluso después de una modificación de peso negativa, ya que nunca recibe mensajes VRRP con una prioridad superior a la suya ( porque los cortafuegos bloquean los anuncios de otros oradores y nunca pueden acceder al proceso keepalived para avisarles). Es por eso que no lo ves lanzar el VIP.

Sin embargo, el servidor BACKUP pudo ver los anuncios del MASTER (ahora fallido), encontró que la prioridad en esos paquetes se redujo a un valor menor que el suyo y procedió a declararse MASTER y enviar ARP gratuitos para reclamar el VIP. Así que terminamos en una situación en la que ambos servidores pensaron que tendrían que servir al VIP como MAESTRO.

Conclusiones: - Compruebe siempre la configuración del firewall en todos los altavoces VRRP si experimenta un comportamiento extraño (sin conmutación por error, varios MASTER). El registro de Keepalived no es tan útil como podría ser (un simple mensaje "VIP no publicado porque todavía soy el prio más alto" después de que la línea "VRRP_Script (chk_script) falló" hubiera aliviado enormemente la solución de problemas.

  • Un track_script no es un tipo de interruptor de encendido / apagado ("si el script está bien: es elegible para la elección VIP; si NO está bien: no es elegible para la elección VIP"), simplemente aumenta / disminuye la probabilidad de ganar las elecciones, y si se mantiene solo siempre se observa a sí mismo como el único orador de VRRP y nunca recibe ningún mensaje de otros oradores, realmente no hay muchas elecciones, siempre se gana.
Patrick Wagner
fuente
0

Me encontré con la misma situación que tú e hice algunos estudios sobre keepalived. Pensemos lo que está sucediendo en cada servidor. Suponiendo que desea implementar la arquitectura de recuperación manual,

En el 1er nodo BACKUP

Cada vez que el track_script falla el número de veces de caída , envía el anuncio al segundo nodo BACKUP. El punto aquí es la Prioridad establecida dentro del anuncio. En tu caso,

129 (109 + 20)

se envía al segundo servidor BACKUP.

En el segundo servidor BACKUP

El siguiente es en el segundo nodo BACKUP.

De acuerdo con RFC ,

If the Priority in the ADVERTISEMENT is Zero, then:

  o  Set the Master_Down_Timer to Skew_Time
else:

  If Preempt_Mode is False, or If the Priority in the
  ADVERTISEMENT is greater than or equal to the local
  Priority, then:

    o Reset the Master_Down_Timer to Master_Down_Interval
  else:

    o Discard the ADVERTISEMENT
  endif
endif

Como no tiene habilitado el preamplificador y recibe vrrp de mayor prioridad, el segundo nodo BACKUP no pasará a la fase de transición de estado.

Solución

Entonces, si desea que la transición de estado suceda en el segundo nodo, puede,

  1. Establezca el peso en 0 en el 1er nodo BACKUP. Esto enviará un anuncio de Prioridad 0 al segundo nodo BACKUP. doc describe más sobre el peso 0.

  2. Apague el nopreempt en el segundo nodo BACKUP.

  3. Establezca el peso en al menos -2 en el primer nodo BACKUP.

Yu Watanabe
fuente