当前位置： 首页 > news >正文

华为云环境下LVS/DR架构的故障诊断优化

news 2025/6/26 11:47:49

本文作者：刘涛

文章目录

  • 前言
  • 1.LVS/DR集群的问题
  • 2.华为云环境
  • 3.问题排查
    • 3.1 检查LVS/DR模式配置
      • 3.1.1 RS服务器
      • 3.1.2 DS服务器
    • 3.2 继续分析抓包结果
      • 3.2.1 调整tcpdump抓包过滤条件
      • 3.2.2 client向集群VIP发包
      • 3.2.3 DS服务器arp消息
    • 3.3 查看丢包
      • 3.3.1 监控DS和RS服务器的收发包错误值
      • 3.3.2 查看网卡收发包错误
    • 3.4 Ping抓包
    • 3.5 client发包和DS发包比较
    • 3.6 分析总结
      • 3.6.1 由表中的二层链路可知：
      • 3.6.2 从表中涉及VIP地址可知：
  • 4.尝试LVS/TUN模式
    • 4.1 安装和配置tun模式
    • 4.2 抓包验证

前言

本文针对华为云环境的LVS/DR接收不到数据包的问题, 排查故障, 分析并验证云上二层网络的Ethernet数据包连通性; LVS/DR模式下, 基本确认ip伪装会被华为云物理网络丢弃。

1.LVS/DR集群的问题

问题:
华为云环境下部署LVS/DR后, 后端服务RS收不到数据包.

现象:

  1. client向集群VIP发包, RS服务器没有收到包; 同时tcpdump也没有抓到相应的包.
  2. client直接向RS发包, RS可以收到包.
  3. 在DS服务器上直接向RS发包, RS也可以收到包.

2.华为云环境

使用华为云作为LVS测试环境，四台服务器:

角色IPEIP功能
clientxxx.xxx.1.15xxx.xxx.25.28
DS：VIPxxx.xxx.1.60xxx.xxx.25.5
DS：DIPxxx.xxx.1.59xxx.xxx.25.196
RS1xxx.xxx.1.48xxx.xxx.25.181UDP程序
RS2xxx.xxx.1.98xxx.xxx.25.154UDP程序

其中:

  • DS：Director Server, 指的是前端负载均衡器节点；
  • RS：Real Server, 后端真实的工作服务器；
  • VIP：向外部直接面向用户请求, 作为用户请求的目标的IP地址；
  • DIP：Director Server IP, 主要用于和RS通讯的IP地址；
  • RIP：Real Server IP, 后端服务器RS的IP地址；
  • CIP：Client IP, 客户端的IP地址。

RS服务器上部署的是java udp程序。安装及配置前, DS和RS已经提前关闭防火墙, 以及iptables/selinux/firewalld等服务。

3.问题排查

3.1 检查LVS/DR模式配置

要点:

  1. 虚拟地址VIP配置在DS上；
  2. 虚拟地址VIP配置RS的lo网卡上；
  3. RS服务器上阻止arp应答。

3.1.1 RS服务器

在RS服务器上执行:

# sysctl -ar arp_ignore
net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.default.arp_ignore = 0
net.ipv4.conf.ens33.arp_ignore = 0
net.ipv4.conf.lo.arp_ignore = 1# sysctl -ar arp_announce
net.ipv4.conf.all.arp_announce = 2
net.ipv4.conf.default.arp_announce = 0
net.ipv4.conf.ens33.arp_announce = 0
net.ipv4.conf.lo.arp_announce = 2# sysctl -ar rp_filter | grep 1
net.ipv4.conf.all.rp_filter = 1# ip -4 a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000inet 127.0.0.1/8 scope host lovalid_lft forever preferred_lft foreverinet xxx.xxx.1.60/32 brd xxx.xxx.1.60 scope global lo:0valid_lft forever preferred_lft forever
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000inet xxx.xxx.1.48/24 brd xxx.xxx.1.255 scope global noprefixroute ens33valid_lft forever preferred_lft forever

RS1和RS2更新配置:

# echo "net.ipv4.conf.all.rp_filter = 0" >> /etc/sysctl.conf
# sysctl -p# sysctl -ar rp_filter | grep 1
<无输出>

3.1.2 DS服务器

在DS服务器上执行:

# sysctl -ar rp_filter | grep 1
<无输出># ip -4 a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000inet 127.0.0.1/8 scope host lovalid_lft forever preferred_lft forever
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000inet xxx.xxx.1.59/24 brd xxx.xxx.1.255 scope global noprefixroute ens33valid_lft forever preferred_lft foreverinet xxx.xxx.1.60/32 brd xxx.xxx.1.60 scope global ens33:0valid_lft forever preferred_lft forever

# LVS规则
# ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags-> RemoteAddress:Port           Forward Weight ActiveConn InActConn
UDP  xxx.xxx.1.60:52002 rr-> xxx.xxx.1.48:52002         Route   1      0          0-> xxx.xxx.1.98:52002         Route   1      0          0

配置无误

3.2 继续分析抓包结果

Ip地址 + Mac地址:

角色IPMAC地址功能
clientxxx.xxx.1.15fa:16:xx:xx:xx:8c
DS：VIPxxx.xxx.1.60fa:16:xx:xx:xx:8d
DS：DIPxxx.xxx.1.59fa:16:xx:xx:xx:8d
RS1xxx.xxx.1.48fa:16:xx:xx:xx:9audp程序
RS2xxx.xxx.1.98fa:16:xx:xx:xx:d3udp程序

3.2.1 调整tcpdump抓包过滤条件

DS机器上:

tcpdump ether src fa:16:xx:xx:xx:8c
改为:
tcpdump '(udp or arp or icmp)' -en -v -w ds.cap

RS机器上:

tcpdump ether src fa:16:xx:xx:xx:8d
改为:
tcpdump '(udp or arp or icmp)' -en -v -w rs.cap

3.2.2 client向集群VIP发包

DS上tcpdump抓包结果, 这是client向集群VIP发包时的记录:
在这里插入图片描述

Frame-351，mac地址xx:8c ------> xx:8d，即: 1.15 —> 1.59
下一个包：
Mac地址xx:8d ------> xx:9a, 即: 1.59 —> 1.48, 如下图:
在这里插入图片描述
上面两张图中, 标识码都是0x704d, 是同一个包; TTL先是64, 再到63, 过了一跳。表明lvs/DR生效了, 包的mac地址更改成了rs-1.48的， 包也发出了。

3.2.3 DS服务器arp消息

DS服务器上抓包, arp请求和应答:
在这里插入图片描述

1.48收到的arp请求:
在这里插入图片描述
说明DS(1.59/1.60) 到 RS(1.48/1.98) 在二层网络上是通的。

3.3 查看丢包

3.3.1 监控DS和RS服务器的收发包错误值

# udp收发包
watch -d netstat -su
# 链路层收发包
watch -d netstat -i
# 网卡收发包
watch -d ifconfig

没有发现异常信息！

3.3.2 查看网卡收发包错误

1.59网卡:

# ethtool -S ens33 | grep errorrx_errors: 0tx_errors: 0rx_length_errors: 0rx_over_errors: 0rx_crc_errors: 0rx_frame_errors: 0rx_missed_errors: 0tx_aborted_errors: 0tx_carrier_errors: 0tx_fifo_errors: 0tx_heartbeat_errors: 0tx_window_errors: 0rx_long_length_errors: 0rx_short_length_errors: 0rx_align_errors: 0rx_csum_offload_errors: 0
# ethtool -S ens33 | grep droptx_dropped: 0dropped_smbus: 0

1.48和1.98同样没有错误和丢包

3.4 Ping抓包

从DS上ping RS服务器, 查看通讯过程:
在这里插入图片描述

发出的icmp包, 源mac地址和ip地址对应DS服务器, 而目的mac地址和ip地址对应RS1服务器;
在这里插入图片描述
Ping reply包,源mac地址和ip地址对应RS1服务器,目的mac地址和ip地址对应DS服务器。

3.5 client发包和DS发包比较

  1. client发包链路: 1.15 —> 1.59/1.60 —> 1.98
  2. DS直接发包链路: 1.59/1.60 —> 1.98

Client发包, DS上收到的包: 1.15 —> 1.59
在这里插入图片描述

3.6 分析总结

汇总测试和抓包结果:

场景源目的是否通过viprs1结果
ping1.59rs1服务器通、tcpdump有数据
arp1.59rs1服务器通、tcpdump有数据
nc发udp包1.151.60是rs1收不到包、tcpdump无数据
1.601.60是rs1收不到包、tcpdump有数据
1.591.60是rs1收到包、tcpdump有数据
1.59rs1服务器rs1收到包、tcpdump有数据
1.60rs1服务器rs1收到包、tcpdump有数据

DS服务器到RS的ethernet数据包情况:

场景源ip目的ip源mac目的macrs结果
Pingds-iprs1-ipds-macrs1-mac通、tcpdump有数据
Arpds-iprs1-ipds-macrs1-mac通、tcpdump有数据
nc发udp包client-ipVIPds-macrs1-macrs收不到包、tcpdump无数据
VIPVIPds-macrs1-macrs收不到包、tcpdump有数据
ds-ipVIPds-macrs1-macrs收到包、tcpdump有数据
ds-iprs1-ipds-macrs1-macrs收到包、tcpdump有数据
VIPrs1-ipds-macrs1-macrs收到包、tcpdump有数据

3.6.1 由表中的二层链路可知：

  1. 从ds-mac到rs-mac, 大部分通, 少部分不通；
  2. arp和ping的结果, 表明DS和RS之间二层链路是通的；
  3. DS和RS上协议栈及网卡没有错误和丢包, 表明DS和RS上发包成功, 从二层链路可以接收到的数据包也都成功入栈。

3.6.2 从表中涉及VIP地址可知：

有问题的包都是涉及VIP的源地址或者目的地址:

  1. 源IP是VIP,目的IP也是VIP:

    RS可以收到包，因为VIP地址在RS上是loopback环回接口，从网卡上收到本身发出去的包，RS默认情况下会拒收，即会丢弃该数据包。

# RS修改内核参数
sysctl -w net.ipv4.conf.all.accept_local=1
# 或者
# echo "net.ipv4.conf.all.accept_local = 1" >> /etc/sysctl.conf
# sysctl -p

  1. 源IP是CIP,目的IP是VIP:

    RS收不到包, tcpdump抓不到包,而且DS/RS协议栈和网卡没有收发包错误和丢包；表明包成功发送出DS,但是没有到达RS,说明包在DS和RS之间丢失。

  2. 结论：
    考虑到华为云环境下, 网络是虚拟网络, 比如构建于vxLan之上的二层链路网络; DS和RS之间还有物理网络设备, 如: VTEP入口。
    考察云环境下的链路:

源VTEP目的/源VTEP目的
client发包client-ip通过VIP
client发包client-mac通过ds-mac
DS转发client-ip拒绝VIP
DS转发ds-mac拒绝rs-mac

VTEP入口启用了rp_filter[功能是防止ip伪装和欺骗]。

4.尝试LVS/TUN模式

4.1 安装和配置tun模式

安装和配置tun模式, 并且在RS服务器上关闭rp_filter功能:

# echo "net.ipv4.conf.all.rp_filter = 0" >> /etc/sysctl.conf
# sysctl -p

从client向集群VIP发包, RS上正常收到udp包。
考察云环境下的链路:

源VTEP目的/源VTEP目的
client发包client-ip通过VIP
client发包client-mac通过ds-mac
DS转发ds-ip通过rs-ip、 内含ip包: client-ip —> VIP
DS转发ds-mac通过rs-mac、内含ip包: client-ip —> VIP

VTEP设备看到的数据包, 是ds-ip/ds-mac发送到rs-ip/rs-mac的, 符合rp_filter的验证。
RS服务器接收到数据包后, tunl0网卡及内核ipip模块解封数据包后, 内核协议栈看到的数据包是client-ip发送到VIP的, 而VIP是本地tunl0网卡的IP地址, 并且本地已经关闭rp-filter功能, 可以顺利通过内核ip路由的校验, 进入协议栈及应用层。

4.2 抓包验证

从101.43发包, 链路是:
101.43 —> 101.60/101.41 —> 101.42

在101.60/101.41上抓包, 收到的包:
Frame-53, 2d:d7 —> ce:54, 即101.43至101.60/101.41:
在这里插入图片描述
Frame-54, ce:54 —> 9f:4b, 即101.41至101.42:
在这里插入图片描述
可以看到这个Frame做了IP-over-IP. ip协议层上, ip地址和mac地址一一对应, 可以通过rp-filter检查。

至101.42, 内核IPIP模块解封后:
在这里插入图片描述

http://www.lryc.cn/news/508515.html

相关文章：

  • leetcode hot100除自身以外的数组的乘积
  • SQL server学习09-数据库编程（上）
  • 什么？Flutter 可能会被 SwiftUI/ArkUI 化？全新的 Flutter Roadmap
  • java全栈day19--Web后端实战(java操作数据库3)
  • 【YashanDB知识库】Mybatis-Plus调用YashanDB怎么设置分页
  • Ansible 批量管理华为 CE 交换机
  • 基于自定义注解与 AOP 切面实现接口日志全面数据库存储
  • GraalVM完全指南：云原生时代下使用GraalVM将Spring Boot 3应用转换为高效Linux可执行文件
  • 单片机：实现驱动超声波（附带源码）
  • 2025.01.15python商业数据分析top2
  • 信息系统项目管理-绩效考核
  • 【Linux】数据呈现
  • oracle 加字段和字段注释 sql
  • 计算机网络压缩版
  • 一文了解 gis 相关服务=》及前端地图服务相关总结
  • Brocade G610 配置
  • DuetWebControl 开源项目常见问题解决方案
  • 亚信安全举办“判大势 悟思想 强实践”主题党日活动
  • Go怎么做性能优化工具篇之基准测试
  • vue3国际化，主题切换
  • Linux Shell 脚本编程基础
  • vuex如何进行状态管理？
  • 嵌入式Linux QT+OpenCV基于人脸识别的考勤系统 项目
  • 通过阿里云 Milvus 与 PAI 搭建高效的检索增强对话系统
  • 评估大语言模型在药物基因组学问答任务中的表现：PGxQA
  • 在本地和远程转储域控制器哈希
  • 基于SSM+Vue的心理咨询问诊系统+LW示例参考
  • 基于TMS320X281X/F28335的DSP入门到精通01_如何开始DSP的学习与开发
  • Java爬虫获取1688 item_search_img接口详细解析
  • Java 连接 FTP 服务器全解析