所以我在两台服务器上运行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
有谁知道解决这个问题？谢谢。
gio*_*nda 14
我遇到了完全相同的问题，但是我的问题不在防火墙也不在我的以太网适配器中，而是在检查脚本的“权重”设置中。
这是我的配置：
掌握：
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
检查脚本：
vrrp_script chk_haproxy {
script "python /root/ha_check.py"
interval 2 # check every 2 seconds
weight 2
rise 2
fall 2
}
master 拒绝释放 VIP 的原因是尽管脚本失败了，但 master 仍然具有来自 BACKUP 服务器的更高优先级编号。发生这种情况是因为 check_script 上的“权重”设置不足以覆盖优先级编号之间的“GAP”，这意味着将 BACKUP 服务器的优先级编号提高到 MASTER Server 的优先级编号。我将进一步解释：
根据keepalived的手册，如果检查成功，“权重”设置上的正数将将该数字添加到优先级。
如果检查失败，负数将从优先级数字中减去该数字。
所以，根据我的配置：
服务器优先级脚本的先前失败：
MASTER：152
BACKUP：100
Failover_IP：MASTER
故障转移 ip 被主服务器正确“抓取”，因为与备份服务器相比，主服务器具有更高的优先级 (152 > 100)
脚本失败后的服务器优先级：
MASTER 服务器：148
BACKUP 服务器：102
Failover_IP：STILL ON MASTER
故障转移 ip 仍在主服务器上，因为与 BACKUP (148 > 102) 相比，Master 再次具有更高的优先级。MASTER服务器拒绝释放IP并且他这样做了，因为他的优先级高于其他服务器。
我的情况的解决方案是：
解决方案-1：更改两台服务器的优先级编号，使它们没有太多“GAP”。
例如：
Master Priority: 150
Backup Priority: 149
Check_script weight: As it is (2)。
使用上述配置，当脚本成功（意味着一切正常）时，优先级将是：
Master: 152
Backup: 149
IP_Location: On Master (152 > 149)
当脚本失败时：
Master: 150
Backup: 151
IP_Location: On Backup (151 > 150)
解决方案 - 2：将脚本的权重数从 2 改为 -60
我遇到了同样的问题 - 两台带有 track_script 的 CentOS 7.1 服务器，并且 MASTER 上的 vrrp_script 失败只会导致单独的日志消息“VRRP_Script(chk_script) failed”，而不是故障转移。然而，在 BACKUP 服务器上，只要主服务器上的 track_script 失败，我就会收到大量 keepalived 尝试接管虚拟 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
这适用于其中一台服务器（备份 VRRP 服务器），但不适用于主服务器，因为我忘记了主服务器上的接口未命名为“eth0”，因此这两条规则根本没有效果。
这解释了我观察到的行为：
如果keepalived无法看到某个virtual_router_id的任何其他VRRP发言者，即使在负权重修改之后，它仍然相信自己是具有最高优先级的发言者（因此是合法的MASTER），因为它永远不会收到优先级高于自己的VRRP消息（因为其他发言者的广告被防火墙阻止，并且永远无法到达 keepalived 进程以使其意识到它们）。这就是为什么你看不到它释放 VIP。
然而，BACKUP 服务器能够看到（现已失败的）MASTER 的广告，发现这些数据包中的优先级降低到低于其自身的值，并继续声明自己为 MASTER 并发送免费 ARP 来声明 VIP。所以我们最终遇到了这样的情况：两台服务器都认为它们需要为 VIP 作为 MASTER 提供服务。
结论： -如果您遇到奇怪的行为（无故障转移，多个 MASTER），请务必检查所有 VRRP 扬声器上的防火墙配置。Keepalived 日志记录并没有它应有的那么有用（在“VRRP_Script(chk_script) failed”行之后显示一条简单的消息“VIP 未释放，因为我仍然是最高优先级”，这将极大地简化故障排除。