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

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

news 来源：原创 2025/5/17 10:34:14

本文作者：刘涛

文章目录

前言
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收不到数据包.

现象:

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

2.华为云环境

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

角色	IP	EIP	功能
client	xxx.xxx.1.15	xxx.xxx.25.28
DS：VIP	xxx.xxx.1.60	xxx.xxx.25.5
DS：DIP	xxx.xxx.1.59	xxx.xxx.25.196
RS1	xxx.xxx.1.48	xxx.xxx.25.181	UDP程序
RS2	xxx.xxx.1.98	xxx.xxx.25.154	UDP程序

其中:

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模式配置

要点:

虚拟地址VIP配置在DS上；
虚拟地址VIP配置RS的lo网卡上；
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地址:

角色	IP	MAC地址	功能
client	xxx.xxx.1.15	fa:16:xx:xx:xx:8c
DS：VIP	xxx.xxx.1.60	fa:16:xx:xx:xx:8d
DS：DIP	xxx.xxx.1.59	fa:16:xx:xx:xx:8d
RS1	xxx.xxx.1.48	fa:16:xx:xx:xx:9a	udp程序
RS2	xxx.xxx.1.98	fa:16:xx:xx:xx:d3	udp程序

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发包比较

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

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

3.6 分析总结

汇总测试和抓包结果:

场景	源	目的	是否通过vip	rs1结果
ping	1.59	rs1服务器		通、tcpdump有数据
arp	1.59	rs1服务器		通、tcpdump有数据
nc发udp包	1.15	1.60	是	rs1收不到包、tcpdump无数据
	1.60	1.60	是	rs1收不到包、tcpdump有数据
	1.59	1.60	是	rs1收到包、tcpdump有数据
	1.59	rs1服务器		rs1收到包、tcpdump有数据
	1.60	rs1服务器		rs1收到包、tcpdump有数据

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

场景	源ip	目的ip	源mac	目的mac	rs结果
Ping	ds-ip	rs1-ip	ds-mac	rs1-mac	通、tcpdump有数据
Arp	ds-ip	rs1-ip	ds-mac	rs1-mac	通、tcpdump有数据
nc发udp包	client-ip	VIP	ds-mac	rs1-mac	rs收不到包、tcpdump无数据
	VIP	VIP	ds-mac	rs1-mac	rs收不到包、tcpdump有数据
	ds-ip	VIP	ds-mac	rs1-mac	rs收到包、tcpdump有数据
	ds-ip	rs1-ip	ds-mac	rs1-mac	rs收到包、tcpdump有数据
	VIP	rs1-ip	ds-mac	rs1-mac	rs收到包、tcpdump有数据

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

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

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

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

源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

源IP是CIP,目的IP是VIP:

RS收不到包, tcpdump抓不到包,而且DS/RS协议栈和网卡没有收发包错误和丢包；表明包成功发送出DS,但是没有到达RS,说明包在DS和RS之间丢失。
结论：
考虑到华为云环境下, 网络是虚拟网络, 比如构建于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模块解封后:
在这里插入图片描述