Keepalived两节点出现双VIP的情事

验证

# 采用tcpdump抓包定位问题,以下是在10.11.4.186 主节点的抓包结果
[root@psql_master ~]# tcpdump -i eth0 vrrp -n

图片 1

# 以下是在10.11.4.187 备节点的抓包结果
[root@psql_standby ~]# tcpdump -i eth0 vrrp -n

图片 2

图片 3

2. 认证剖析

三.缓和方案

1. 配置iptables 

# 配置iptables,允许vrrp流量,或者允许组播流量
[root@psql_standby ~]# vim /etc/sysconfig/iptables
-A INPUT -p vrrp -j ACCEPT
# 或者:-A INPUT -m pkttype --pkt-type multicast -j ACCEPT

# 重启iptables:
[root@psql_standby ~]# service iptables restart

推广iptables攻略后,tcpdump抓包发掘:备节点10.11.4.187接收越来越高等的布告,已不再主动向外发vrrp文告。

图片 4

2. 安装vrrp单播通知(未注明)

# 如果两节点的上联交换机禁用了组播,则只能采用vrrp单播通告的方式
[root@psql_master ~]# vim /etc/keepalived/keepalived.conf

   priority 100
    unicast_src_ip  10.11.4.186         ##source ip
    unicast_peer {
            10.11.4.187               ##dest ip
    }

[root@psql_standby ~]# vim /etc/keepalived/keepalived.conf

   priority 90
    unicast_src_ip  10.11.4.187         ##source ip
    unicast_peer {
            10.11.4.186               ##dest ip
    }

安装有keepalived的两节点服务器10.11.4.186/187,重要做高可用,设定VIP10.11.4.185。

图片 5

1. 查看日志 

翻看10.11.4.187的日记发掘,其上keepalived服务刚运转后尽快就进来master方式,获得VIP;同不平日间查看10.11.4.186的日记,并未此外极度。

初阶决断是两边的研究机制出标题(vrrp),10.11.4.187
backup节点与10.11.4.186
主节点协商不成事,认为主节点故障,切换升主。

图片 6

二.难题原因 

分析

  1. 10.11.4.186/187
    主/备节点轮流在对外发表vrrp通告(vrrp布告地址224.0.0.18),理论上备节点即便接到主节点的公告,通知中优先级高于自个儿,就不会主动对外发送通告;
  2. 查看iptables,暗中同意没有同意vrrp大概组播流量,导致备节点收不到主节点的通报,感到主节点故障,切换状态,宣布VIP。 
  1. 第一运行10.11.4.186的keepalived服务,服务运转健康,VIP生成正规;
  2. 但在起步10.11.4.187的keepalived服务后,也能博取VIP;
  3. 外表访问VIP平常,从arp的功用看,对外提供劳务仍是10.11.4.186节点。

一.现象

图片 7