所以我在两台服务器上运行keepalived，我无法将其切换到另一台服务器。
下面我有我的configuration服务器之一。 两者之间唯一的区别在于优先号码是110，而后面是109。
但是当我用/etc/init.d/process停止我的进程时，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。 当我做我的脚本时，同样的问题也会发生。
!/bin/bash SERVICE='process' STATUS=$(ps ax | grep -v grep | grep $SERVICE) if [ "$STATUS" != "" ] then exit 0 else exit 1 fi
有没有人知道这个问题的解决办法？ 谢谢。
我有完全相同的问题，但是我的问题不是在防火墙，也不在我的以太网适配器，而是在检查脚本的“重量”设置。
这是我的configuration：
主：
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的原因是因为尽pipe脚本失败了，主服务器仍然拥有更高的优先级号码。 发生这种情况是因为check_script上的“weight”设置不足以覆盖优先级数字之间的“GAP”，这意味着将BACKUP服务器的优先级数字提高到MASTER服务器的优先级数字。 我会进一步解释：
根据keepalived手册，如果检查成功，则“权重”设置上的正数会将该数字添加到优先级。
如果检查失败，负数将从优先数减去该数。
所以，根据我的configuration：
服务器优先级脚本之前的失败：
主持人：152
备份：100
Failover_IP：MASTER
由于主服务器与备份服务器（152> 100）相比具有更高的优先级，因此主服务器正确“抓取”故障转移IP，
服务器优先级脚本失败后：
MASTER服务器：148
备份服务器：102
Failover_IP： 仍然在MASTER上
故障转移IP仍在主服务器上，因为与BACKUP（148> 102）相比，主设备具有更高的优先级。 MASTER服务器拒绝释放IP，因为他的优先级比其他服务器高。
解决我的情况是：
解决scheme-1：更改两个服务器的优先级数，使他们没有太多的“差距”。
例如：
优先级：150
备份优先级：149
Check_script重量：因为它是（2）。
通过上面的configuration，当脚本成功（意味着一切正常），优先级将是：
师父：152
备份：149
IP_Location：在主设备上（152> 149）
当脚本失败时：
师父：150
备份：151
IP_Location：在备份（151> 150）
解决scheme – 2：将脚本的权重编号从2更改为-60
我有同样的问题 – 两个CentOS 7.1服务器与track_script，并在MASTER上失败的vrrp_script只会导致孤独的日志消息“VRRP_Script（chk_script）失败”，而不是在故障转移。 然而，在BACKUP服务器上，只要我在MASTER服务器上的track_script失败，我就收到了很多keepalived的信息，试图接pipe虚拟IP。
在我的情况下的解决scheme：MASTER服务器上的防火墙（iptables）configuration不正确，以允许VRRP数据包/多播数据包，同时另一台服务器上的防火墙BACKUP正确configuration。
我已经在两台服务器上input了相同的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消息因为其他发言者的广告被防火墙阻挡，并且永远无法到达keepalived进程以使其意识到这一点）。 这就是为什么你不看到它释放贵宾。
然而，BACKUP服务器能够看到（现在失败的）MASTER的广告，发现这些数据包中的优先级降低到小于它自己的值，并且继续声明自己的MASTER并发送无偿ARP来要求VIP。 所以我们结束了两个服务器认为他们需要为MAS服务的VIP的情况。
结论： – 如果您遇到奇怪的行为（无故障切换，多个MASTER），请务必检查所有VRRP扬声器上的防火墙configuration。 Keepalived日志logging不是很有帮助（在“VRRP_Script（chk_script）失败”行之后，将极大地简化了故障排除之后的简单消息“VIP未发布，因为我仍然是最高的prio”。
我碰到了和你一样的情况，并且做了一些关于keepalived的研究。 让我们想想每个服务器中发生的事情。 假设您想要实现手动故障回复体系结构，
每当track_script失败次数下降时 ，它就会将广告发送到第二个BACKUP节点。 这里指的是广告内的优先权 。 在你的情况下，
129 （109 + 20）
被发送到第二个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
由于您已经启用了nopreempt并且正在接收更高优先级的vrrp，所以第二个BACKUP节点不会进入转换阶段。
所以如果你想在第二个节点上进行状态转换，你也可以，
在第一个BACKUP节点上将权重设置为0 。 这将发送优先级0广告到第二个BACKUP节点。 doc介绍更多关于权重0。
closures第二个BACKUP节点上的nopreempt 。
在第一个BACKUP节点上将重量设置为至less-2 。