☰

为什么我在 keepalived 中遇到脑裂问题？

tag-icon • tag-icon keepalived
为什么我在 keepalived 中遇到脑裂问题？

当我启动我的 BACKUP keepalived 实例时，它也会假定 MASTER 状态，如下所示：

Mar 28 02:38:05 localhost Keepalived_vrrp[23527]: VRRP_Instance(VI_01) Entering BACKUP STATE
Mar 28 02:38:05 localhost Keepalived_vrrp[23527]: VRRP sockpool: [ifindex(2), proto(112), unicast(1), fd(10,11)]
Mar 28 02:38:05 localhost Keepalived_vrrp[23527]: VRRP_Script(check_haproxy) succeeded
Mar 28 02:38:17 localhost Keepalived_vrrp[23527]: VRRP_Instance(VI_01) Transition to MASTER STATE
Mar 28 02:38:21 localhost Keepalived_vrrp[23527]: VRRP_Instance(VI_01) Entering MASTER STATE

主配置：

# Script used to check if HAProxy is running
vrrp_script check_haproxy {
script "/usr/sbin/pidof haproxy"
interval 2
}
# Virtual interface
# The priority specifies the order in which the assigned interface to take over in a failover
vrrp_instance VI_01 {
state MASTER
interface eth0
advert_int 4
unicast_src_ip 10.1.2.50
unicast_peer {
        10.1.2.51
    }
virtual_router_id 51
priority 150
# The virtual ip address shared between the two loadbalancers
virtual_ipaddress {
    10.1.2.100
}
track_script {
check_haproxy
}

备份配置：

# Script used to check if HAProxy is running
vrrp_script check_haproxy {
script "/usr/sbin/pidof haproxy"
interval 2
}
# Virtual interface
# The priority specifies the order in which the assigned interface to take over in a failover
vrrp_instance VI_01 {
state BACKUP
advert_int 4
interface eth0
unicast_src_ip 10.1.2.51
unicast_peer {
        10.1.2.50
    }
virtual_router_id 51
priority 100
# The virtual ip address shared between the two loadbalancers
virtual_ipaddress {
    10.1.2.100
}
track_script {
check_haproxy
}
}

然后我检查这两个实例是否在互相通信：

掌握

$ tcpdump -i eth0 'ip proto 112'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
02:48:33.557462 IP host1.novalocal > 10.1.2.51: VRRPv2, Advertisement, vrid 51, prio 101, authtype none, intvl 4s, length 20
02:48:37.558487 IP host1.novalocal > 10.1.2.51: VRRPv2, Advertisement, vrid 51, prio 101, authtype none, intvl 4s, length 20
02:48:41.559496 IP host1.novalocal > 10.1.2.51: VRRPv2, Advertisement, vrid 51, prio 101, authtype none, intvl 4s, length 20

备份

$ tcpdump -i eth0 'ip proto 112'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
02:49:38.269751 IP host2.novalocal > 10.1.2.50: VRRPv2, Advertisement, vrid 51, prio 100, authtype none, intvl 1s, length 20
02:49:39.270461 IP host2.novalocal > 10.1.2.50: VRRPv2, Advertisement, vrid 51, prio 100, authtype none, intvl 1s, length 20
02:49:40.271197 IP host2.novalocal > 10.1.2.50: VRRPv2, Advertisement, vrid 51, prio 100, authtype none, intvl 1s, length 20

有什么提示可以解释为什么 BACKUP 实例无法识别 MASTER 吗？

更新 1：

iptables 结果：

掌握

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

备份

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

解决方案

原来是防火墙问题。我通过tcpdump在目标主机上执行操作来验证是否收到了广告，从而验证了这一点。修复防火墙问题后，我现在收到了之前没有的 vrrp 广告。在备份主机上运行了以下内容：

tcpdump -i eth0 src host 10.1.2.50
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
01:06:42.709813 IP 10.1.2.50 > sntstsvmrla2a02.novalocal: VRRPv2, Advertisement, vrid 51, prio 101, authtype none, intvl 1s, length 20
01:06:43.709901 IP 10.1.2.50 > sntstsvmrla2a02.novalocal: VRRPv2, Advertisement, vrid 51, prio 101, authtype none, intvl 1s, length 20

答案1

正如您的 tcpdump 所示，两个系统都尝试相互通信，但没有收到任何答复。因此，两个系统都认为对方系统已关闭，而备份系统则按计划运行。您需要找出阻碍通信的原因。

答案2

仅就我的环境而言（作为通用用途值得怀疑），当 SPT 算法重新计算路由（最多 30 秒）时，仅在瞬时核心交换机故障转移时才出现错误的大脑分裂，这可能在核心交换机固件升级期间发生。

#MASTER
    track_script {
        chk_haproxy # 20 points
    }

#BACKUP
        track_script {
            chk_haproxy             # 10 points
            chk_ping_core_switch    # 10 points
            # if not core switch -> brain splitted
        }

使用此配置，备份节点没有资格成为主节点，直到核心交换机恢复正常。

相关内容