我在每个三节点集群节点keepalived上都设置了（浮动 VIP） 。当我在任意给定节点上重新启动时，有时我会发现有两个节点在 MASTER 中运行（如下图所示）haproxygalerakeepalived/etc/keepalived/log_status.sh 通知脚本）：
# cat /etc/keepalived/log_status.sh
#!/bin/bash
echo $1 $2 is in $3 state > /var/run/keepalive.$1.$2.state
据我所知，“多个主服务器”是由于交换机上过滤了多播，但我可以在我的任何一个 galera 节点上运行 tcpdump，并看到 MC 流量到达网卡（这些是正在运行的 KVM 虚拟机）。我可以尝试更改为单播，但我想知道这是由于错误、功能还是我的配置造成的。
# cat /etc/keepalived/keepalived.conf
log "setting up keepalived"
global_defs {
router_id host1 # short hostname of each KA node (10.20.18.201-203)
}
vrrp_script check_haproxy {
script "pidof haproxy"
interval 2
weight 2
}
vrrp_instance 250 {
virtual_router_id 250
advert_int 1
nopreempt
priority 100
state BACKUP
interface eth0
notify /etc/keepalived/log_status.sh
virtual_ipaddress {
10.20.18.250 dev eth0
}
track_script {
check_haproxy
}
}
tcpdump 输出：
09:44:00.934942 IP 10.20.18.203 > 224.0.0.18: VRRPv2, Advertisement, vrid 250, prio 102, authtype none, intvl 1s, length 20
09:44:01.936054 IP 10.20.18.203 > 224.0.0.18: VRRPv2, Advertisement, vrid 250, prio 102, authtype none, intvl 1s, length 20
09:44:02.937315 IP 10.20.18.203 > 224.0.0.18: VRRPv2, Advertisement, vrid 250, prio 102, authtype none, intvl 1s, length 20
09:44:03.938444 IP 10.20.18.203 > 224.0.0.18: VRRPv2, Advertisement, vrid 250, prio 102, authtype none, intvl 1s, length 20
09:44:04.942302 IP 10.20.18.203 > 224.0.0.18: VRRPv2, Advertisement, vrid 250, prio 102, authtype none, intvl 1s, length 20
09:44:05.373224 IP 10.20.18.201 > 224.0.0.22: igmp v3 report, 1 group record(s)
09:44:05.943936 IP 10.20.18.203 > 224.0.0.18: VRRPv2, Advertisement, vrid 250, prio 102, authtype none, intvl 1s, length 20
09:44:06.029216 IP 10.20.18.201 > 224.0.0.22: igmp v3 report, 1 group record(s)
09:44:06.385127 IP 10.20.18.201 > 224.0.0.22: igmp v3 report, 1 group record(s)
09:44:06.945303 IP 10.20.18.203 > 224.0.0.18: VRRPv2, Advertisement, vrid 250, prio 102, authtype none, intvl 1s, length 20
09:44:07.333210 IP 10.20.18.201 > 224.0.0.22: igmp v3 report, 1 group record(s)
09:44:07.946098 IP 10.20.18.203 > 224.0.0.18: VRRPv2, Advertisement, vrid 250, prio 102, authtype none, intvl 1s, length 20
09:44:08.947228 IP 10.20.18.203 > 224.0.0.18: VRRPv2, Advertisement, vrid 250, prio 102, authtype none, intvl 1s, length 20
09:44:09.948507 IP 10.20.18.203 > 224.0.0.18: VRRPv2, Advertisement, vrid 250, prio 102, authtype none, intvl 1s, length 20
09:44:10.548023 IP 10.20.18.202 > 224.0.0.22: igmp v3 report, 1 group record(s)
09:44:10.663961 IP 10.20.18.202 > 224.0.0.22: igmp v3 report, 1 group record(s)
09:44:10.949633 IP 10.20.18.203 > 224.0.0.18: VRRPv2, Advertisement, vrid 250, prio 102, authtype none, intvl 1s, length 20
09:44:11.559970 IP 10.20.18.202 > 224.0.0.22: igmp v3 report, 1 group record(s)
09:44:11.587980 IP 10.20.18.202 > 224.0.0.22: igmp v3 report, 1 group record(s)
09:44:11.950795 IP 10.20.18.203 > 224.0.0.18: VRRPv2, Advertisement, vrid 250, prio 102, authtype none, intvl 1s, length 20
09:44:12.952124 IP 10.20.18.203 > 224.0.0.18: VRRPv2, Advertisement, vrid 250, prio 102, authtype none, intvl 1s, length 20
09:44:13.953075 IP 10.20.18.203 > 224.0.0.18: VRRPv2, Advertisement, vrid 250, prio 102, authtype none, intvl 1s, length 20
09:44:14.953543 IP 10.20.18.203 > 224.0.0.18: VRRPv2, Advertisement, vrid 250, prio 102, authtype none, intvl 1s, length 20
09:44:15.954703 IP 10.20.18.203 > 224.0.0.18: VRRPv2, Advertisement, vrid 250, prio 102, authtype none, intvl 1s, length 20
09:44:15.987641 IP 10.20.18.203 > 224.0.0.18: VRRPv2, Advertisement, vrid 250, prio 0, authtype none, intvl 1s, length 20
09:44:15.992698 IP 10.20.18.203 > 224.0.0.22: igmp v3 report, 1 group record(s)
09:44:16.008817 IP 10.20.18.203 > 224.0.0.22: igmp v3 report, 1 group record(s)
09:44:17.008829 IP 10.20.18.203 > 224.0.0.22: igmp v3 report, 1 group record(s)
09:44:17.036879 IP 10.20.18.203 > 224.0.0.22: igmp v3 report, 1 group record(s)
09:44:20.613407 IP 10.20.18.203 > 224.0.0.18: VRRPv2, Advertisement, vrid 250, prio 102, authtype none, intvl 1s, length 20
09:44:21.615616 IP 10.20.18.203 > 224.0.0.18: VRRPv2, Advertisement, vrid 250, prio 102, authtype none, intvl 1s, length 20
09:44:22.616909 IP 10.20.18.203 > 224.0.0.18: VRRPv2, Advertisement, vrid 250, prio 102, authtype none, intvl 1s, length 20
09:44:23.618155 IP 10.20.18.203 > 224.0.0.18: VRRPv2, Advertisement, vrid 250, prio 102, authtype none, intvl 1s, length 20
09:44:24.619607 IP 10.20.18.203 > 224.0.0.18: VRRPv2, Advertisement, vrid 250, prio 102, authtype none, intvl 1s, length 20
答案1
单词答案：iptables。
我正在运行两个 keepalived 实例 - 一个允许从内部网络访问，另一个支持外部访问。
我复制了内部配置以创建外部 keepalived 实例。虽然 keepalived 在第一个接口（内部接口，eth0）上正常工作，但我复制的配置在两个主机上都生成了 VIP。
我对 tcpdump 的检查表明，bcast VRRP 流量在网络中是允许的，并且对两个 keepalived 实例都是可见的。我检查了内部和外部接口 (eth0 内部 / eth1 外部) 上的 tcp 流量。
必须允许 VRRP 流量。我发现我可以成功嗅探流量，并且看到来自两个 keepalived 实例的 VRRP 流量具有正确（且不同）的优先级。但是，我的 iptables 配置仅允许 eth1 上的流量。
/etc/sysconfig/iptabes 中的相关行：
之前（eth1 上的 keepalived 出现问题，但 eth0 正常）：
###Allow multicast for KeepAlived
-A INPUT -i eth0 -d 224.0.0.18/32 -p vrrp -j ACCEPT
-I OUTPUT -o eth0 -d 224.0.0.18/32 -p vrrp -j ACCEPT
之后（一切顺利）：
###Allow multicast for KeepAlived
-A INPUT -i eth0 -d 224.0.0.18/32 -p vrrp -j ACCEPT
-I OUTPUT -o eth0 -d 224.0.0.18/32 -p vrrp -j ACCEPT
-A INPUT -i eth1 -d 224.0.0.18/32 -p vrrp -j ACCEPT
-I OUTPUT -o eth1 -d 224.0.0.18/32 -p vrrp -j ACCEPT
答案2
我有一个类似的配置，在 Vagrant 本地环境中运行良好，但是在云提供商服务器中配置时，BACKUP 始终自我提升，并且我会同时拥有 2 个 MASTERS。
我尝试更改防火墙规则，但我所做的是在字段中输入私有网络接口vrrp_instance interface，并添加unicast_src_ip和unicast_peer阻止。unicast_src_ip拥有服务器自己的 IP 地址和unicast_peer其余 Keepalived 节点的地址。