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

这篇具有很好参考价值的文章主要介绍了keepalived脑裂后,近20min不能访问虚拟IP问题分析。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

问题现象和说明

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

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

正常现象

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

异常现象

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

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

问题复现

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

背景说明

  1. 抓包主要在server3上进行
  2. 路由器Router的wan口配置的IP是192.168.1.3
  3. 路由器Router的lan口分别接入server1,server2,和server3
  4. 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报文
keepalived脑裂后,近20min不能访问虚拟IP问题分析
client1 保证正常情况下的通信
keepalived脑裂后,近20min不能访问虚拟IP问题分析

server3保证正常情况下的通信
keepalived脑裂后,近20min不能访问虚拟IP问题分析

server1上IP 和虚拟IP情况
keepalived脑裂后,近20min不能访问虚拟IP问题分析
server2上的IP和虚拟IP情况
keepalived脑裂后,近20min不能访问虚拟IP问题分析

模拟故障

  1. 在server2上配置不接收VRRP报文,等待30秒中,此时可以查看keepalived变成master(此时发生了脑裂) ,并和172.16.22.31绑定
    iptables -I INPUT -p vrrp -j REJECT 执行丢弃vrrp丢弃的报文节点并没有选择
    keepalived脑裂后,近20min不能访问虚拟IP问题分析
    此时从client1和server3上都可以ping 通172.16.22.31

  2. 删除 不接受vrrp的规则(iptables -F) 系统脑裂 keepalived脑裂后,近20min不能访问虚拟IP问题分析
    脑裂的直观体现就是两个真实的IP都和虚拟IP绑定了
    keepalived脑裂后,近20min不能访问虚拟IP问题分析

  1. 脑裂恢复之后就从 client1 不能ping 通虚拟IP了,server3可以ping通
    keepalived脑裂后,近20min不能访问虚拟IP问题分析
    故障复现成功。

  2. 故障模拟脚本—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也可以是优先级地的节点绑定,这种情况下脑裂恢复就不会中断。测试效果如下
keepalived脑裂后,近20min不能访问虚拟IP问题分析

问题分析

问题定界

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

client1 和server3 访问的差异

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

背景知识二三层转发原理

  1. 二层转发过程:IP和掩码与,属于同一网段,学习目的MAC,根据目的MAC转发。
  2. 三层转发过程:IP和掩码与,不属于同一网段,走三层转发,给下跳路由继续转发。
    参考二三层转发原理介绍, 网络之二三层转发
  1. client1到 VIP不通,整条链路不通的地方是在Router和vip之间,验证过程如下:

从client1不能ping 通虚拟IP(172.168.22.31),client1可以ping通 Router,Router 不能ping 通 VIP,可以ping通 server1和server2
keepalived脑裂后,近20min不能访问虚拟IP问题分析

Router为什么不能访问 VIP?

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

  1. keepalived脑裂前
    MAC表项如下: 虚拟IP 172.16.22.31 对应的MAC地址和 172.16.22.146保持一直
    keepalived脑裂后,近20min不能访问虚拟IP问题分析
    server1 的IP
    keepalived脑裂后,近20min不能访问虚拟IP问题分析
    server2的IP
    keepalived脑裂后,近20min不能访问虚拟IP问题分析

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

  1. keepalived脑裂中
    路由器的AR表项如下: VIP(172.16.22.31)对应的MAC地址是和server2的地址172.16.22.246的MAC一致,此时server2对应也有172.16.22.31的虚拟IP,所以此时也是可以ping通的。
    为什么ARP的表项会刷新,请看server2的分析。
    keepalived脑裂后,近20min不能访问虚拟IP问题分析
    server1 的IP
    keepalived脑裂后,近20min不能访问虚拟IP问题分析
    server2的IP
    keepalived脑裂后,近20min不能访问虚拟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


  1. 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的现象。

    keepalived脑裂后,近20min不能访问虚拟IP问题分析
    server1 的IP
    keepalived脑裂后,近20min不能访问虚拟IP问题分析
    server2的IP
    keepalived脑裂后,近20min不能访问虚拟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表项。

方案优点

  1. 自动刷新
  2. 配置简单

方案缺点

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

方案效果

这次实验有9秒中中断,正常是在 0-20秒之间
keepalived脑裂后,近20min不能访问虚拟IP问题分析

进阶方案

方案实现

在基础方案基础上

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

notify_stop “/etc/keepalived/arp1.sh”

  1. 同时在两个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报文最终生效。

方案优点

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

方案缺点

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

方案效果

keepalived脑裂后,近20min不能访问虚拟IP问题分析
网络条件差的情况下,还是大概率会中断两秒
keepalived脑裂后,近20min不能访问虚拟IP问题分析

系统方案

方案实现

在进阶方案基础上,修改路由器或者交换机上的设置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表项被刷新。

方案的优点

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

方案的劣势

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

方案效果

最终效果和进阶方案不中断的情况一致。
keepalived脑裂后,近20min不能访问虚拟IP问题分析

附属说明

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

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

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

华为系列可以配置不丢弃 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模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • mysql双主互从通过KeepAlived虚拟IP实现高可用

    在mysql 双主互从的基础上, 架构图: Keepalived有两个主要的功能: 提供虚拟IP,实现双机热备 通过LVS,实现负载均衡 修改 keepalived 配置文件 keepalived.conf 检测xxx.sh check_mysql_port.sh 安装killall 命令 安装netstat 修改脚本xxx.sh权限 keepalived.conf 启动keepalived master slave 停止容器,使v

    2024年02月07日
    浏览(40)
  • windos 服务器设置指定ip访问指定端口,其他ip不能访问

    需求:设置指定ip访问指定端口,其他ip不能访问 一,禁止所有ip访问 需要打开IP安全策略 或者win+R 输入secpol.msc  1.先创建一个ip安全策略 2.点击添加,不使用添加向导,建一个安全策略  继续点添加 二,放开需要访问的ip   1.设置需要放开的ip地址  2.自定义名称,继续添加

    2024年02月04日
    浏览(58)
  • IP改变导致Zabbix不能访问的解决办法

    目录 解决方式一 1.关闭防火墙和selinux 2.查看ip地址 3.修改zabbix-php的配置文件 4.重启mysqld 5.访问页面 6.修改zabbix-agent.conf 的配置 7.重启zabbix-agent 验证zabbix-agent是否启动 解决方式二 更改ip地址 1.首先查看网卡名称和ip 2.修改网络的配置文件固定ip 博主推荐使用第二种方式,可以

    2024年02月08日
    浏览(50)
  • 物理机不能访问虚拟机kali的web服务解决方案记录

    目录 环境 问题描述 解决方案 知识补充 效果测试 其他思路 环境 kali(nat模式),物理机,可互ping 问题描述 kali的web服务器不能在物理机上访问。 1.本机能ping通虚拟机 2.虚拟机也能ping通本机 3.虚拟机能访问自己的web 4.虚拟机也能访问物理机的web 5.物理机无法访问虚拟机的

    2024年02月04日
    浏览(50)
  • iis网站localhost(127.0.0.1)可以访问,使用本机局域网IP(192.168.4.*)不能访问

    在项目服务器上,用IIS发布网站之后,使用地址 http://localhost:10022/可以正常访问,换成http://127.0.0.1:10022/也可以正常访问,但把localhost改成服务器IP地址 http://192.168.4.64:10022/,却显示无法打开此地址 检查防火墙状态,如果防火墙处于开启状态,需要将网站对应端口进行入栈,

    2024年02月02日
    浏览(60)
  • 虚拟机修改完ip之后能ping通主机,但不能ping通百度

    ping 主机ip 这样就是通的 进入配置文件查看网关地址是否一致,不一致要进行修改 vim /etc/sysconfig/network-scripts/ifcfg-ens33 然后修改这些东西 BOOTPROTO=static #IP地址 IPADDR=192.168.200.130 #网关 GATEWAY=192.168.200.2 #域名解析器 DNSI=192.168.200.2 在虚拟机上打开虚拟网络编辑器,在编辑里面 在主

    2024年01月23日
    浏览(48)
  • Ubuntu 20配置虚拟IP和多网卡

    1台云服务器 系统版本:Ubuntu 20 目前的IP信息如下:主网卡IP为192.168.10.111,需要添加的虚拟IP地址为:192.168.10.37 使用云服务器添加虚拟IP,也需要手动在控制台-也可以说是后台添加对应虚拟IP并绑定到主机上 网卡文件路径在:/etc/netplan/ 修改网卡文件:在addresses里把您的主网

    2024年02月04日
    浏览(40)
  • SpringBoot服务启动了,但通过http://ip:port/不能访问 (windows、linux)

    无法启动首先确认一下对应的端口有没有开放。正常服务器上需要开启防火墙的情况下,需要通过开放对应端口来实现项目访问。 systemctl status firewalld   #查询防火墙状态 firewall-cmd --query-port=1986/tcp  #查询某端口的TCP协议是否开放 防火墙处于Active状态即表示防火墙是开启

    2024年02月16日
    浏览(32)
  • 解决github有时能访问有时不能访问的问题

    在国内访问github的时候,有时候能访问,有时候不能访问。 原因是,github.com这个域名对应的IP地址有很多个,有些在我国允许访问的范围内,有些不在。当你的计算机通过DNS解析的github.com对应的地址恰好在我国允许访问的范围内,你就可以访问,反之不能。 通常情况下,多

    2024年02月07日
    浏览(97)
  • 虚拟机与主机之间不能复制粘贴问题

    1. 查看vmware Tools是否安装 打开虚拟机 ,点击上方导航栏 ‘虚拟机’ 查看 VMware Tools 是否安装,如果未安装,安装即可 2. 命令行解决 如果第一种方法不行,可以试试第二种方法 输入命令 切换到 /usr/bin 目录下 输入命令 3.重新安装组件 如果前两种方法都不行,那就试试第三种

    2024年02月11日
    浏览(59)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包