脑裂问题与解决（keepalived脑裂的解决和预防）

Posted 2022-10-16 王大雏

脑裂问题与解决（keepalived脑裂的解决和预防）

• 一、keepalived脑裂
• 二、什么是裂脑？
• 三、keepalived脑裂产生的原因
• 四、常见的解决方案
• 五、解决keepalived脑裂问题
• 六、曾经碰到的一个keepalived脑裂的问题
• 七、预防keepalived脑裂问题
• 八、推荐自己写脚本

一、keepalived脑裂

Keepalived的作用是检测服务器的状态，如果有一台web服务器宕机，或工作出现故障，Keepalived将检测到，并将有故障的服务器从系统中剔除，同时使用其他服务器代替该服务器的工作，当服务器工作正常后Keepalived自动将服务器加入到服务器群中，这些工作全部自动完成，不需要人工干涉，需要人工做的只是修复故障的服务器。

二、什么是裂脑？

当两台高可用服务器在指定的时间内，无法互相检测到对方心跳而各自启动故障转移功能，取得了资源以及服务的所有权，而此时的两台高可用服务器对都还活着并作正常运行，这样就会导致同一个服务在两端同时启动而发生冲突的严重问题，最严重的就是两台主机同时占用一个VIP的地址（类似双端导入概念），当用户写入数据的时候可能会分别写入到两端，这样可能会导致服务器两端的数据不一致或造成数据的丢失，这种情况就称为裂脑，也有的人称之为分区集群或者大脑垂直分隔。

发生脑裂，导致互相竞争同一个IP资源，就如同我们局域网内常见的IP地址冲突一样，两个机器就会有一个或者两个不正常，影响用户正常访问服务器。如果是应用在数据库或者是存储服务这种极重要的高可用上，那就导致用户发布的数据间断的写在两台服务器上的恶果，最终数据恢复及困难或者是难已恢复。

脑裂（split-brain）：指在一个高可用（HA）系统中，当联系着的两个节点断开联系时，本来为一个整体的系统，分裂为两个独立节点，这时两个节点开始争抢共享资源，结果会导致系统混乱，数据损坏。

对于无状态服务的HA，无所谓脑裂不脑裂；但对有状态服务(比如mysql)的HA，必须要严格防止脑裂。

三、keepalived脑裂产生的原因

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

• 优先考虑心跳线路上的问题，在可能是心跳服务，软件层面的问题

• 1）高可用服务器对之间心跳线路故障，导致无法正常的通信。原因比如：

  1——心跳线本身就坏了（包括断了，老化）；

  2-——网卡以及相关驱动坏了,IP配置及冲突问题；

  3——心跳线间连接的设备故障（交换机的故障或者是网卡的故障）；

  4——仲裁的服务器出现问题。

• 2）高可用服务器对上开启了防火墙阻挡了心跳消息的传输；

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

• 4）其他服务配置不当等原因，如心跳的方式不同，心跳广播冲突，软件出现了BUG等。

• 5）Keepalived配置里同一 VRRP实例如果virtual_router_id两端参数配置不一致也会导致裂脑问题发生。

四、常见的解决方案

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

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

• 当检测到裂脑时强行关闭一个心跳节点（这个功能需特殊设备支持，如Stonith、feyce）。相当于备节点接收不到心跳消患，通过单独的线路发送关机命令关闭主节点的电源。

• 做好对裂脑的监控报警（如邮件及手机短信等或值班）.在问题发生时人为第一时间介入仲裁，降低损失。例如，百度的监控报警短倍就有上行和下行的区别。报警消息发送到管理员手机上，管理员可以通过手机回复对应数字或简单的字符串操作返回给服务器.让服务器根据指令自动处理相应故障，这样解决故障的时间更短.

• 当然，在实施高可用方案时，要根据业务实际需求确定是否能容忍这样的损失。对于一般的网站常规业务.这个损失是可容忍的。

• 多节点集群中，可以通过增加仲裁的机制，确定谁该获得资源，这里面有几个参考的思路：

  1——增加一个仲裁机制。例如设置参考的IP，当心跳完全断开的时候，2个节点各自都ping一下参考的IP，不同则表明断点就出现在本段，这样就主动放弃竞争，让能够ping通参考IP的一端去接管服务。

  2——通过第三方软件仲裁谁该获得资源，这个在阿里有类似的软件应用

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

• 报警报在服务器接管之前，给人员处理留足够的时间就是1分钟内报警了，但是服务器不接管，而是5分钟之后接管，接管的时间较长。数据不会丢失，但就是会导致用户无法写数据。报警后，不直接自动服务器接管，而是由人员接管。

五、解决keepalived脑裂问题

检测思路：正常情况下keepalived的VIP地址是在主节点上的，如果在从节点发现了VIP，就设置报警信息。脚本（在从节点上）如下：


vim split-brainc_check.sh
 
#!/bin/bash
 
# 检查脑裂的脚本，在备节点上进行部署
 
LB01_VIP=192.168.1.229
 
LB01_IP=192.168.1.129
 
LB02_IP=192.168.1.130
 
while true
 
do
 
  ping -c 2 -W 3 $LB01_VIP &>/dev/null
 
    if [ $? -eq 0 -a `ip add|grep "$LB01_VIP"|wc -l` -eq 1 ];then
 
        echo "ha is brain."
 
    else
 
        echo "ha is ok"
 
    fi
 
    sleep 5
 
done

六、曾经碰到的一个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协议的配置：

-A INPUT -i lo -j ACCEPT  

-----------------------------------------------------------------------------------------

自己添加了下面的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脑裂问题

（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里面。