问题现象和说明

真实的场景比较复杂，抽象起来可以用下面的图表示，

图示说明
server1 和server2 分别部署keepalived,有一个虚拟IP （VIP）.
Router和switch 是路由交换设备，这里用的功能都是一样的，并不做区别.

正常现象

正常情况下，client1 可以访问VIP，server3也可以访问VIP，这里访问采用ping方式，下同。
keepalived 切换情况下，client1 可以访问VIP，server3也可以访问VIP。

异常现象

server3 可以访问 VIP
client1 不能访问VIP，不做任何修改，大约20分钟后，client1又可以访问VIP了
异常前的keeplived日志(/var/log/message)有脑裂发生。

背景知识，Keepalived通过VRRP实现高可用性
keepalived基础入门可以参考一文带你浅入浅出Keepalived
VRRP协议了解可以VRRP简单概述
https://www.cnblogs.com/patrick-yeh/p/14428508.html
核心参考keepalived官网

问题复现

家里正好有几个ARM板子，一个TP-link交换机(二层)，一个华为AR路由器，一台服务器，可以实现如下的场景搭建。模拟脑裂到恢复的过程

背景说明

抓包主要在server3上进行
路由器Router的wan口配置的IP是192.168.1.3
路由器Router的lan口分别接入server1，server2,和server3
server1 和server2 的keepalived配置如下
server1 上keepalived.conf

! Configuration File for keepalived
global_defs {
        router_id swaram02
        script_user root
}
vrrp_script chk_http_port {
        script "/etc/keepalived/check.sh"
        interval 10
        user root
}
vrrp_sync_group VG1 {
    group {
          VI_1
    }
}
vrrp_instance VI_1 {
        state BACKUP
        interface eth0
        nopreempt #非抢占模式
        virtual_router_id 31  #通过vid参数识别同一个虚拟路由器，所以两者一定要一致
        priority 100
        advert_int 3  #通告时间
        authentication {
                auth_type PASS
                auth_pass 1111
        }
        virtual_ipaddress {
                172.16.22.31/26
        }
        track_script {
           chk_http_port
        }
        notify_master "/etc/keepalived/arp1.sh"  #当切换到MASTER时,运行的脚本
}

server2上keepalived.conf配置

! Configuration File for keepalived
global_defs {
        router_id swaram02
        script_user root
}
vrrp_script chk_http_port {
        script "/etc/keepalived/check.sh"
        interval 10
        user root
}
vrrp_sync_group VG1 {
    group {
          VI_1
    }
}
vrrp_instance VI_1 {
        state BACKUP
        interface eth0
        nopreempt #非抢占模式
        virtual_router_id 31 #通过vid参数识别同一个虚拟路由器，所以两者一定要一致
        priority 90 
        advert_int 3  # 通告周期
        authentication {
                auth_type PASS
                auth_pass 1111
        }
        virtual_ipaddress {
                172.16.22.31/26
        }
        track_script {
           chk_http_port
        }
        notify_master "/etc/keepalived/arp1.sh"  #当切换到MASTER时,运行的脚本
}

其中用到两个脚本，一个是check，检查后端程序，没有写，直接使用ls代替脚本内容
还有一个arp1.sh的脚本

#!/bin/bash
VIP=172.16.22.31
GATEWAY=172.16.22.1
/sbin/arping -I eth0 -c 5 -s $VIP $GATEWAY &>/dev/null

正常情况下在server3上抓包,可以看到只有maser节点146发的vrrp报文
在这里插入图片描述
client1 保证正常情况下的通信

server3保证正常情况下的通信

server1上IP 和虚拟IP情况
在这里插入图片描述
server2上的IP和虚拟IP情况

模拟故障

在server2上配置不接收VRRP报文，等待30秒中，此时可以查看keepalived变成master(此时发生了脑裂) ，并和172.16.22.31绑定
iptables -I INPUT -p vrrp -j REJECT 执行丢弃vrrp丢弃的报文节点并没有选择

此时从client1和server3上都可以ping 通172.16.22.31
删除不接受vrrp的规则(iptables -F) 系统脑裂
脑裂的直观体现就是两个真实的IP都和虚拟IP绑定了

脑裂恢复之后就从 client1 不能ping 通虚拟IP了，server3可以ping通

故障复现成功。
故障模拟脚本—test.sh
丢弃keepalived 之间确定

iptables -A INPUT -p vrrp -j REJECT;
iptables -A OUTPUT -p vrrp -j REJECT;
sleep 1 ;
ip a  |  grep  22;
sleep 12;
ip a |  grep  22;

echo "==========recover==============="
iptables -F;
iptables -X;
sleep 5
ip a  |  grep 22

必现条件

上面的模拟如果不是在特定状态，特定节点上的操作不一定会成功
初始状态下，keepalived的vip绑定节点必须是优先级高的那个节点

由于非keepalived设置的是非抢占模式，初始状态下，VIP也可以是优先级地的节点绑定，这种情况下脑裂恢复就不会中断。测试效果如下
在这里插入图片描述

问题分析

问题定界

server3 可以访问，说明VIP所在的节点至少是在提供服务的。
client1 不能访问，说明这个访问说明这个异常是和网络有关。

client1 和server3 访问的差异

server3 和VIP是在同一网段，根据二三层转发可以知, server3 是通过MAC学习得知VIP(172.16.22.31的所在)，所以一直访问没有问题。
client1和VIP不在同一网段，会经过Route，此时在client1上ping server1 或者server2 也是正常的，有问题的只是虚拟IP 的访问

背景知识二三层转发原理

二层转发过程：IP和掩码与，属于同一网段，学习目的MAC，根据目的MAC转发。
三层转发过程：IP和掩码与，不属于同一网段，走三层转发，给下跳路由继续转发。
参考二三层转发原理介绍, 网络之二三层转发

client1到 VIP不通，整条链路不通的地方是在Router和vip之间，验证过程如下：

从client1不能ping 通虚拟IP(172.168.22.31)，client1可以ping通 Router，Router 不能ping 通 VIP，可以ping通 server1和server2
在这里插入图片描述

Router为什么不能访问 VIP？

对于Router来书访问VIP，和PC是一样的，先比较 VIP和是否和接口上的某一网段是否相同，和VLAN1上面的IP网段相同，走二层转发，二层转发需要目的MAC，先查自己有没有已经学习此IP对应的MAC，有则把这个MAC作为目的MAC封装成报文发送出去，如果没有则发送ARP请求，学习此VIP对应的MAC，然后记录到ARP表项中，同上把这个VIP对应的MAC，封装成报文发送出去。所以很有必要看一下路由器的MAC表项。

keepalived脑裂前
MAC表项如下：虚拟IP 172.16.22.31 对应的MAC地址和 172.16.22.146保持一直

server1 的IP

server2的IP

路由器中VIP（172.16.22.31）对应的MAC是2ae1-6096-7886 ，和实际的绑定关系一致，所以从client1 可以正常ping通

keepalived脑裂中
路由器的AR表项如下： VIP（172.16.22.31）对应的MAC地址是和server2的地址172.16.22.246的MAC一致，此时server2对应也有172.16.22.31的虚拟IP，所以此时也是可以ping通的。
为什么ARP的表项会刷新，请看server2的分析。

server1 的IP

server2的IP

脑裂后server2的状态由backup变成master，这时候会发送免费ARP报文（gratuitous ARP ,对于IPV6是发送NA message），从配置中看到还会通过脚本方式刷新网关，其实这两种方式都可以刷新网关的ARP表项，最终的效果就是ARP表项被刷新，和server2的MAC地址保持一致

可以参考keepalived官网关于vrrp_min_garp 参数的描述
# By default keepalived sends 5 gratuitions ARP/NA messages at a
# time, and after transitioning to MASTER sends a second block of
# 5 messages 5 seconds later.
# With modern switches this is unnecessary, so setting vrrp_min_garp
# causes only one ARP/NA message to be sent, with no repeat 5 seconds
# later.
vrrp_min_garp

keepalived脑裂恢复后
路由器中的ARP表项，并未刷新，VIP(172.16.22.31)还是和server2 (172.16.22.246)的MAC 一致。
但是此时 server2 的keepalived状态由master变成了backup,这个过程中会删除掉VIP(172.16.22.31)。
路由器发送，目的IP地址是172.16.22.31，MAC地址是e207-22f4-0eb6的报文后，server2收到了，发现和自己的IP地址不一致，丢弃了报文。所以出现了脑裂恢复后client1不能访问VIP的现象。

server1 的IP

server2的IP

解决方案

手工方案

1. 手工恢复方案1----让节点去适配路由交换设备

由于异常来于ARP表项没有刷新，重启keepalived,就会触发VIP飘逸。
在模拟的场景中，重启server1中的keepalived就可以恢复。
实际过程中有可以使用两个VIP，所以两个节点都要重启。

2. 手工恢复方案2—刷新路由交换设备的ARP表项

使用arping工具，在优先级高节点上面发送免费ARP，具体命令如下

arping -I [IP设备名称] -c [个数] -U [虚拟机IP]

实验环境中的实例
`/sbin/arping -I eth0  -c 5  -U  172.16.22.31`

基础方案

方案实现

在 keepalived的全局配置里面添加 vrrp_garp_master_refresh 20

global_defs {
router_id swaram02
script_user root
vrrp_garp_master_refresh 20
}

两个节点都添加，重启keepalived.
此方案的效果是在设定的时间范围内，可以保证client1可以访问VIP

方案说明

vrrp_garp_master_refresh 是指当节点变成master 节点后，循环发送免费ARP报文，此报文可以刷新网关的ARP表项，虽然keep脑裂的时候，两个节点都会刷新ARP表项，等脑裂结束后，由于一个节点变成了backup,只有真正的master才会刷新ARP表项。

方案优点

自动刷新
配置简单

方案缺点

刷新频率不能太高，因为这是在同一网段内发的广播报文
会有可以明显感知的中断

方案效果

这次实验有9秒中中断，正常是在 0-20秒之间
在这里插入图片描述

进阶方案

方案实现

在基础方案基础上

仅且仅在优先级更高的节点上，添加如下配置

notify_stop “/etc/keepalived/arp1.sh”

同时在两个keepalived 节点上
- 在全局区域增加如下配置
vrrp_garp_master_refresh 20
vrrp_garp_master_repeat 2
- 删除 notify_master的配置

在配置中的位置
master节点：

root@server1:/etc/keepalived# cat keepalived.conf 
! Configuration File for keepalived
global_defs {
        router_id swaram02
        script_user root
        vrrp_garp_master_refresh 20
        vrrp_garp_master_repeat 2
}
vrrp_script chk_http_port {
        script "/etc/keepalived/check.sh"
        interval 10
        user root
}
vrrp_sync_group VG1 {
    group {
          VI_1
    }
}
vrrp_instance VI_1 {
        state BACKUP
        interface eth0
        nopreempt
        virtual_router_id 31
        priority 100
        advert_int 3
        authentication {
                auth_type PASS
                auth_pass 1111
        }
        virtual_ipaddress {
                172.16.22.31/26
        }
        track_script {
           chk_http_port
        }
        notify_stop "/etc/keepalived/arp1.sh"  #当vrrp 停止的时候，执行通知脚本
}

backup 节点

global_defs {
        router_id swaram02
        script_user root
        vrrp_garp_master_refresh 20
        vrrp_garp_master_repeat 2
        
}
vrrp_script chk_http_port {
        script "/etc/keepalived/check.sh"
        interval 10
        user root
}
vrrp_sync_group VG1 {
    group {
          VI_1
    }
}
vrrp_instance VI_1 {
        state BACKUP
        interface eth0
        nopreempt
        virtual_router_id 31
        priority 90
        advert_int 3
        authentication {
                auth_type PASS
                auth_pass 1111
        }
        virtual_ipaddress {
                172.16.22.31/26
        }
        track_script {
           chk_http_port
        }
        #debug 1
        #notify_master "/etc/keepalived/arp1.sh"  #当切换到MASTER时,运行的脚本
}

修改完配置之后，分别重启两个节点上的keepalived服务

方案说明

脑裂之后恢复的master节点一定是优先级更高的那一个
所以在脑裂之后，优先级更高的那一个去刷新ARP表项，恢复的时间会更短，甚至不会中断。
vrrp_garp_master_repeat 2 这个参数的含义是backup节点变成master节点之后，发几个免费ARP报文，默认是5个，因为notify_stop 也会去发，这里设置比 notify_stop中少三个，目的是让notify_stop中发送的免费ARP报文最终生效。

方案优点

中断时间在5秒内，网络条件好的情况下，无中断
实现相对简单

方案缺点

概率性的还是会有小于5秒的中断

方案效果

在这里插入图片描述
网络条件差的情况下，还是大概率会中断两秒

系统方案

方案实现

在进阶方案基础上，修改路由器或者交换机上的设置ARP表项固化，确认后才更新ARP表项：
对于华为系列的路由器或者交换机是：

arp anti-attack entry-check send-ack enable
un arp anti-attack entry-check  enable

对于H3C 系列的交换机和路由器是：

arp active-ack enable

其他系列的交换和路由器待补充。

方案说明

路由器或者交换机中有防止ARP表项被攻击者修改的功能，keepalived脑裂的情况和攻击类似，可以使能表项确认的开关，确认原节点不可访问后再更新表项，这样就可以防止脑裂时候ARP表项被刷新。

方案的优点

可以防止脑裂的时候出现不可访问的中断。

方案的劣势

如果开始的ARP表是错误的，刷新就要等到老化时间到了。
需要交换机或者路由器支持，不同厂商的配置不同，而且不一定都实现了此功能。

方案效果

最终效果和进阶方案不中断的情况一致。

附属说明

脑裂引起的问题首先要排除脑裂发生的原因，除了网络异常抖动，之外的其他常见原因，同事已经排除，所以这里并未赘述。
脑裂的网络原因目前只是猜测，没有实锤，根据真实的网络拓扑如下，

这个概率很低一年才出现一次，根据网络拓扑，如果出现宿主机上的虚拟机不走同一个交互机，经过其他网络设置，tll值就会小于255.

按照RFC 2338的规定，系统对收到的VRRP报文的TTL值进行检测，如果TTL值不等于255，则丢弃这个报文，并打印出VRRP报文错误的日志信息。

华为系列可以配置不丢弃 vrrp check ttl disable 参考手册来自：https://support.huawei.com/enterprise/zh/doc/EDOC1000017951/217b12b7

keepalived脑裂后，近20min不能访问虚拟IP问题分析

问题现象和说明

正常现象

异常现象

问题复现

背景说明

模拟故障

必现条件

问题分析

问题定界

client1 和server3 访问的差异

Router为什么不能访问 VIP？

解决方案

手工方案

1. 手工恢复方案1----让节点去适配路由交换设备

2. 手工恢复方案2—刷新路由交换设备的ARP表项

基础方案

方案实现

方案说明

方案优点

方案缺点

方案效果

进阶方案

方案实现

方案说明

方案优点

方案缺点

方案效果

系统方案

方案实现

方案说明

方案的优点

方案的劣势

方案效果

附属说明

相关文章