问题现象和说明
真实的场景比较复杂,抽象起来可以用下面的图表示,
图示说明
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报文错误的日志信息。文章来源:https://www.toymoban.com/news/detail-470874.html
华为系列可以配置不丢弃 vrrp check ttl disable
参考手册来自:https://support.huawei.com/enterprise/zh/doc/EDOC1000017951/217b12b7文章来源地址https://www.toymoban.com/news/detail-470874.html
到了这里,关于keepalived脑裂后,近20min不能访问虚拟IP问题分析的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!