oracle脑裂的判断机制,Keepalived两节点出现双VIP的情况（脑裂）

安装有keepalived的两节点服务器133.96.54.111/112，设定VIP133.96.54.110。

首先启动133.96.54.111的keepalived服务，服务启动正常，VIP生成正常；

但在启动133.96.54.112的keepalived服务后，也能获得VIP；

外部访问VIP正常，从arp的效果看，对外提供服务仍是133.96.54.111节点。

查看112的日志发现，其上keepalived服务刚启动后不久就进入master模式，获得VIP；同时查看111的日志，并没有任何异常。

初步判断是两边的协商机制出问题(vrrp)，112 backup节点与111 主节点协商不成功，认为主节点故障，切换升主。

采用tcpdump抓包定位问题

111

112

分析

111/112 主/备节点轮流在对外发布vrrp通告(vrrp通告地址224.0.0.18)，理论上备节点如果收到主节点的通告，通告中优先级高于自己，就不会主动对外发送通告；

查看iptables，默认没有允许vrrp或者组播流量，导致备节点收不到主节点的通告，认为主节点故障，切换状态，发布VIP。

三．解决方案

1. 配置iptables

-A INPUT -p vrrp -j ACCEPT

放开iptables策略后，tcpdump抓包发现：备节点112收到更高级的通告，已不再主动向外发vrrp通告。

2. 设置vrrp单播通告(未验证)

# 如果两节点的上联交换机禁用了组播，则只能采用vrrp单播通告的方式

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

priority 100

unicast_src_ip *.*.*.111 ##source ip

unicast_peer {

*.*.*.112 ##dest ip

}

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

priority 90

unicast_src_ip *.*.*.112 ##source ip

unicast_peer {

*.*.*.111 ##dest ip

}