Keepalived 脑裂问题的起因与解决

21 12月

作者:admin|分类:应用管理

Keepalived脑裂

脑裂（split-brain）：指在一个高可用（HA）系统中，当联系着的两个节点断开联系时，本来为一个整体的系统，分裂为两个独立节点，这时两个节点开始争抢共享资源，结果会导致系统混乱，数据损坏。对于无状态服务的HA，无所谓脑裂不脑裂；但对有状态服务(比如MySQL)的HA，必须要严格防止脑裂。

在高可用HA系统中，当联系2个节点的“心跳线”断开时，本来为一整体，一个VRRP协议组，动作协调的HA系统，就分裂为两个独立的个体。由于相互失去了联系，都以为对方出了故障；两个节点的HA软件像“连体人”一样，有共同的身体却拥有两个脑袋，争抢“共享资源”身体，争抢服务器里的应用服务，就会发送严重后果，或者共享资源被瓜分，两边服务都起不来或者都起来都为Master，假如两端服务器发生了脑裂现象就会成为各自的Master，会同时读写“共享存储”，导致数据损坏（常见的如数据库轮询着的联机日志出错）对付HA系统“裂脑”的对策，目前达成共识的的大概有以下几条：　　　　

1）添加冗余的心跳线，例如：双线条线（心跳线也HA），尽量减少“裂脑”发生几率；　　　　

2）启用磁盘锁。正在服务一方锁住共享磁盘，“裂脑”发生时，让对方完全“抢不走”共享磁盘资源。但使用锁磁盘也会有一个不小的问题，如果占用共享盘的一方不主动“解锁”，另一方就永远得不到共享磁盘。现实中假如服务节点突然死机或崩溃，就不可能执行解锁命令。后备节点也就接管不了共享资源和应用服务。于是有人在HA中设计了“智能”锁。即：正在服务的一方只在发现心跳线全部断开（察觉不到对端）时才启用磁盘锁。平时就不上锁了。　　　　

3）设置仲裁机制。例如设置参考IP（如网关IP），当心跳线完全断开时，2个节点都各自ping一下参考IP，不通则表明断点就出在本端。不仅“心跳”、还兼对外“服务”的本端网络链路断了，即使启动（或继续）应用服务也没有用了，那就主动放弃竞争，让能够ping通参考IP的一端去起服务。更保险一些，ping不通参考IP的一方干脆就自我重启，以彻底释放有可能还占用着的那些共享资源。

脑裂产生的原因

一般来说，裂脑的发生，有以下几种原因：

1）高可用服务器对之间心跳线链路发生故障，导致无法正常通信

2）因心跳线坏了（包括断了，老化）

3）因网卡及相关驱动坏了，ip配置及冲突问题（网卡直连）

4）因心跳线间连接的设备故障（网卡及交换机）

5）因仲裁的机器出问题（采用仲裁的方案）

6）高可用服务器上开启了 iptables防火墙阻挡了心跳消息传输

7）高可用服务器上心跳网卡地址等信息配置不正确，导致发送心跳失败

8）其他服务配置不当等原因，如心跳方式不同，心跳广插冲突、软件Bug等提示：Keepalived配置里同一 VRRP实例如果 virtual_router_id两端参数配置不一致也会导致裂脑问题发生

iptables导致keepalived脑裂的问题

曾经碰到的一个keepalived脑裂的问题（如果启用了iptables，不设置"系统接收VRRP协议"的规则，就会出现脑裂）

曾经在做keepalived+Nginx主备架构的环境时，当重启了备用机器后，发现两台机器都拿到了VIP。这也就是意味着出现了keepalived的脑裂现象，检查了两台主机的网络连通状态，发现网络是好的。然后在备机上抓包：

# tcpdump -i eth0|grep VRRP 
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode 
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 

22:10:17.146322 IP 192.168.1.54 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 160, authtype simple, intvl 1s, length 20 
22:10:17.146577 IP 192.168.1.96 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 50, authtype simple, intvl 1s, length 20 
22:10:17.146972 IP 192.168.1.54 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 160, authtype simple, intvl 1s, length 20 
22:10:18.147136 IP 192.168.1.96 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 50, authtype simple, intvl 1s, length 20

抓包发现备机能接收到master发过来的VRRP广播，那为什么还会有脑裂现象？

接着发现iptables开启着，检查了防火墙配置。发现系统不接收VRRP协议。于是修改iptables，添加允许系统接收VRRP协议的配置：自己添加了下面的iptables规则：

-A INPUT -s 192.168.1.0/24 -d 224.0.0.18 -j ACCEPT       #允许组播地址通信
-A INPUT -s 192.168.1.0/24 -p vrrp -j ACCEPT             #允许VRRP（虚拟路由器冗余协）通信

最后重启iptables，发现备机上的VIP没了。虽然问题解决了，但备机明明能抓到master发来的VRRP广播包，却无法改变自身状态。只能说明网卡接收到数据包是在iptables处理数据包之前。

预防keepalived脑裂问题

在实际生产环境中，我们可以从以下几个方面来防止裂脑问题的发生：　　

（0）同时使用串行电缆和以太网电缆连接，同时用两条心跳线路，这样一条线路坏了，另一个还是好的，依然能传送心跳消息。　

（1）可以采用第三方仲裁的方法。由于keepalived体系中主备两台机器所处的状态与对方有关。如果主备机器之间的通信出了网题，就会发生脑裂，此时keepalived体系中会出现双主的情况，产生资源竞争。

（2）一般可以引入仲裁来解决这个问题，即每个节点必须判断自身的状态。最简单的一种操作方法是，在主备的keepalived的配置文件中增加check配置，服务器周期性地ping一下网关，如果ping不通则认为自身有问题。

（3）最容易的是借助keepalived提供的vrrp_script及track_script实现。如下所示：

#vim /etc/keepalived/keepalived.conf

   ......

   vrrp_script check_local {

    script "/root/check_gateway.sh"

    interval 5

    }

   ...... 

   track_script {    

   check_local                  

   }

脚本内容：

# cat /root/check_gateway.sh
#!/bin/sh

VIP=$1
GATEWAY=192.168.1.1
/sbin/arping -I em1 -c 5 -s $VIP $GATEWAY &>/dev/null

check_gateway.sh 就是我们的仲裁逻辑，发现ping不通网关，则关闭keepalived。

推荐自己写脚本，写一个while循环，每轮ping网关，累计连续失败的次数，当连续失败达到一定次数则运行service keepalived stop关闭keepalived服务。

如果发现又能够ping通网关，再重启keepalived服务。最后在脚本开头再加上脚本是否已经运行的判断逻辑，将该脚本加到crontab里面。

Keepalived 脑裂问题的起因与解决