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