现场通过ifdown下载网卡的方式测试 keepalived部署的集群；

脚本大概如下：

#禁用网卡和启用网卡时间间隔，单位为秒
times=30
#操作网卡的名字
ethname="eth0"        
ifdown $ethname
if [ $? -eq 0 ]; then
	 echo "ifdown $ethname succeed"
fi

for i in `seq 1 ${times}`
do
	sleep 1
done
ifup $ethname

发现备机运行的keepalived一直拿不到VIP；

排查

keepalive配置不正确

通过比较发现配置皆正确

! Configuration File for keepalived

global_defs {
   router_id NGINX1
}
vrrp_script chk_nginx {
    script "pidof nginx"
    interval 2
}

vrrp_instance VI_1 {
    state BACKUP
    interface eth0
    virtual_router_id 51
    priority 90
    advert_int 1
    nopreempt
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    unicast_src_ip 192.168.2.6
    unicast_peer {
        192.168.2.7
    }
    virtual_ipaddress {
        192.168.2.8
    }

    track_script {
        chk_nginx
    }
}

ip被占用

ping 主机IP和ping VIP 都不通，说明IP未被占用

备机kp程序有问题

进入容器发现容器正常运行

网络白名单问题

添加过白名单IP，且后续测试时发现可正常切换

查看kp日志

vlanif1是什么意思down_vlanif1是什么意思down

当kp在容器中运行时，默认输出到docker容器的控制台日志中，并未在系统日志产生

通日志获取到：
发现备机处于SLAVE状态，且一起保持，可能说明他自己还收到ARRP的协议

问题解析

发现备机处于SLAVE状态，且一起保持，可能说明他自己还收到ARRP的协议
顺着这条思路查询

  • 以前确实遇到过一次，手动ifdown网卡，竟然发现VIP有时候脑裂，有时候并没有迁移；
  • 搜索的结果1

《虚拟机环境中Keepalived虚拟IP自动漂移的研究》
当我们使用ifdownens192命令关闭网络接口时，异常情况发生了：ens192接口被禁用后，在Backup节点仍然可以正常、持续收到Master节点发送的VRRP心跳包（prio值非0），但此时Master节点的IP地址已经不可用（ens192上的两条IP192.168.2.5、192.168.2.6均已丢失），而Master节点的Keepalived服务也因为获取不到IP信息进入inactive（dead）状态。由于Backup节点仍能持续收到Master节点发来的VRRP心跳包，因此Backup节点此时仍认为Master节点工作正常，导致虚拟IP不能漂移至Backup节点，故障转移失效。

  • 搜索结果2

《执行ifdown命令后，为什么无法完全停止物理网卡？》
因为环境中部署了FusionInsight，假设FusionInsight的浮动ip eth*:0 启动在eth1上，此时执行ifdown eth1后，eth1网卡不会停止，因为FusionInsight会自动拉起eth1:0自己的浮动IP，导致eht1不会完全down掉。

结果2也是第一次发现时，就已经给出的一个答案，现在看下，越来越真实；
现场的问题也与这现象一致，果断重启主机keepalived，不再保留案发现场，问题结果