keepalived VRRP_script无法故障转移

因此，我在两台服务器上运行keepalived，但无法将其故障转移到另一台服务器。

下面，我对其中一台服务器进行配置。两者之间的唯一区别是优先级数字主机为110，优先级为109。

但是，当我使用/etc/init.d/process stop停止我的进程时，keepalived不会故障转移。我只是得到了VRRP_Script（chk_script）失败而已。没有故障转移或什么都没有。

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
}
}

这是我的下面的chk_script。当我执行killall -0进程作为脚本时，也会发生相同的问题。

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

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

有谁知道解决办法？谢谢。

我遇到了完全相同的问题，但是我的问题不在防火墙或以太网适配器中，而是在检查脚本的“权重”设置中。

这是我的配置：

主：

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

备份：

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

}

主服务器拒绝释放VIP的原因是，尽管脚本失败，但主服务器仍具有来自BACKUP服务器的更高优先级编号。发生这种情况是因为check_script上的“ weight”设置不足以覆盖优先级编号之间的“ GAP”，这意味着将BACKUP服务器的优先级编号提高到MASTER Server的优先级。我将进一步解释：

根据管家的手册，如果检查成功，“权重”设置上的正数会将该数字添加到优先级。
如果检查失败，则负数将从优先级数中减去该数字。

因此，根据我的配置：

服务器优先级脚本的先前故障：
MASTER：152
BACKUP：100
Failover_IP：MASTER

由于主服务器的优先级比备份服务器的优先级高（152> 100），因此主服务器正确“捕获”了故障转移IP

脚本失败后的服务器优先级：
MASTER服务器：148
BACKUP服务器：102
Failover_IP：STILL ON MASTER

故障转移ip仍位于主服务器上，因为与备份相比，主服务器的优先级再次更高（148> 102）。MASTER服务器拒绝发布IP，因此他做的正确，因为他的优先级高于其他服务器。

我的情况的解决方案是：

解决方案-1：更改两个服务器的优先级号，以使它们没有太多的“ GAP”。
例如：
主优先级：150
备份优先级：149
Check_script权重：等于（2）。

使用上述配置，当脚本成功运行（意味着一切正常）时，优先级将为：
主服务器：152
备用服务器：149
IP_位置：在主服务器上（152> 149）

当脚本失败时：
主服务器：150
备份服务器：151
IP_位置：备份服务器上（151> 150）

解决方案-2：将脚本的权重数从2更改为-60

我遇到了同样的问题-两台具有track_script的CentOS 7.1服务器，并且在MASTER上使vrrp_script失败只会导致单独的日志消息“ VRRP_Script（chk_script）失败”，而不会导致故障转移。但是，在BACKUP服务器上，只要MASTER服务器上的track_script出现故障，我就会收到很多保持连接的消息，试图接管虚拟IP。

我的解决方案：未正确配置MASTER服务器上的防火墙（iptables）以允许VRRP数据包/多播数据包，而同时另一台服务器BACKUP上的防火墙已正确配置。

我已经在两个服务器中输入了相同的iptables规则，如下所示：

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

这可以在其中一台服务器（BACKUP VRRP服务器）上运行，但不能在MASTER服务器上运行，因为我忘记了在MASTER服务器上该接口未命名为“ eth0”，因此，这两个规则根本没有作用。

这解释了我观察到的行为：

如果keepalived在某个virtual_router_id上看不到任何其他VRRP发言者，则即使权重修改为负，它仍然认为自己是优先级最高的（因此是正确的MASTER），因为它从未收到优先级高于其自身的VRRP消息（因为其他发言人的广告已被防火墙阻止，并且永远无法进入保持活动状态以使其意识到）。这就是为什么您看不到它释放VIP的原因。

但是，BACKUP服务器能够看到（现在已失败）MASTER的广告，发现这些数据包中的优先级降低到小于其自身的值，然后继续声明自己为MASTER并发送免费的ARP来声明VIP。因此，我们最终陷入了两台服务器都认为它们需要将VIP作为MASTER的情况。

结论：- 如果您遇到奇怪的行为（没有故障转移，几个MASTER），请务必检查所有VRRP扬声器上的防火墙配置。Keepalived日志记录并没有提供任何有用的帮助（在“ VRRP_Script（chk_script）失败”行之后显示一条简单消息“ VIP未发布，因为我仍然是最高优先级”，这将极大地简化故障排除过程。

• track_script不是开关的开/关类型（“如果脚本正常：可以参加VIP选举；如果不能正常：完全不可以参加VIP选举”）-它只会增加/减少赢得选举的可能性，并且如果保持曾经将自己视为唯一的 VRRP演讲者，却从未收到其他演讲者的任何消息，因此选举的意义不大-您总是赢家。

我刚遇到与您相同的情况，并做了一些有关保持活力的研究。让我们考虑一下每台服务器中正在发生的事情。假设您要实施手动故障回复架构，

在第一个BACKUP节点上

每当track_script失败次数的时间秋天时候，它发送广告到第二备份节点。这里要点是广告内设置的优先级。就你而言

129（109 + 20）

发送到第二台BACKUP服务器。

在第二台BACKUP服务器上

接下来是第二个BACKUP节点。

根据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

由于没有启用预抢占功能，并且收到了更高优先级的vrrp，因此第二个BACKUP节点不会进入状态转换阶段。

解

因此，如果您想在第2个节点上进行状态转换，则可以，

1. 在第一个BACKUP节点上将权重设置为0。这会将优先级0广告发送到第二个BACKUP节点。doc详细介绍了权重0。

2. 关闭第二个BACKUP节点上的nopreempt。

3. 在第一个BACKUP节点上将权重至少设置为-2。