一．現象

安裝有keepalived的兩節點伺服器10.11.4.186/187，主要做高可用，設定VIP10.11.4.185。

1. 首先啟動10.11.4.186的keepalived服務，服務啟動正常，VIP生成正常；
2. 但在啟動10.11.4.187的keepalived服務後，也能獲得VIP；
3. 外部訪問VIP正常，從arp的效果看，對外提供服務仍是10.11.4.186節點。

二．問題原因 

1. 查看日誌 

查看10.11.4.187的日誌發現，其上keepalived服務剛啟動後不久就進入master模式，獲得VIP；同時查看10.11.4.186的日誌，並沒有任何異常。

初步判斷是兩邊的協商機制出問題（vrrp），10.11.4.187 backup節點與10.11.4.186 主節點協商不成功，認為主節點故障，切換升主。

2. 驗證分析

驗證

# 採用tcpdump抓包定位問題，以下是在10.11.4.186 主節點的抓包結果
[root@psql_master ~]# tcpdump -i eth0 vrrp -n

# 以下是在10.11.4.187 備節點的抓包結果
[root@psql_standby ~]# tcpdump -i eth0 vrrp -n

分析

1. 10.11.4.186/187 主/備節點輪流在對外發佈vrrp通告(vrrp通告地址224.0.0.18)，理論上備節點如果收到主節點的通告，通告中優先順序高於自己，就不會主動對外發送通告；
2. 查看iptables，預設沒有允許vrrp或者組播流量，導致備節點收不到主節點的通告，認為主節點故障，切換狀態，發佈VIP。 

三．解決方案

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通告。

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
    }