安装有keepalived的两节点服务器10.11.4.186/187,主要做高可用,设定VIP10.11.4.185。
首先启动10.11.4.186的keepalived服务,服务启动正常,VIP生成正常;
但在启动10.11.4.187的keepalived服务后,也能获得VIP;
外部访问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
分析
10.11.4.186/187 主/备节点轮流在对外发布vrrp通告(vrrp通告地址224.0.0.18),理论上备节点如果收到主节点的通告,通告中优先级高于自己,就不会主动对外发送通告;
查看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 }
一些关于Keepalived相关教程集合:
CentOS 7下Keepalived + HAProxy 搭建配置详解