SeigRobotics1. DR模式的核心概念与适用场景
DR（Direct Routing）模式是负载均衡领域中的一种经典实现方式，它通过直接修改数据包的目标MAC地址来实现流量转发，避免了传统NAT模式下的性能瓶颈。我第一次在生产环境接触DR模式是在2018年，当时我们电商平台的支付网关在高峰期频繁出现连接超时，切换到DR模式后性能直接提升了3倍。
与NAT模式相比，DR模式的核心特点在于：
- 真实服务器直接响应客户端，不经过负载均衡器
- 负载均衡器仅处理入站请求，响应流量走独立路径
- 必须保证真实服务器与负载均衡器在同一二层网络
- 需要配置VIP（Virtual IP）和ARP抑制
这种架构特别适合：
- 高吞吐量场景：如视频流媒体、CDN边缘节点
- 低延迟要求服务：金融交易系统、实时竞价平台
- 大规模静态资源分发：软件下载站、镜像仓库
关键提示：DR模式要求所有真实服务器必须禁用对VIP的ARP响应，这是新手最容易忽略的配置点。我曾见过因为漏配ARP规则导致整个集群出现IP冲突的案例。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 环境准备与网络拓扑设计
2.1 基础网络架构
典型的DR模式部署需要以下组件：
- 负载均衡器：运行LVS（Linux Virtual Server）的主机
- 真实服务器集群：至少2台业务服务器
- 虚拟IP（VIP）：如192.168.1.100
- 真实IP（RIP）：服务器实际IP地址
网络拓扑示例：
code复制客户端
|
| (目标IP=VIP)
↓
[ LVS负载均衡器 ]
| (修改目标MAC)
↓
[ 真实服务器1 ] [ 真实服务器2 ]
(都绑定VIP但禁用ARP)
2.2 系统配置要点
在CentOS 7上配置基础环境：
bash复制# 所有节点关闭防火墙和SELinux
systemctl stop firewalld
systemctl disable firewalld
setenforce 0
sed -i 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/selinux/config
# 加载LVS内核模块
modprobe ip_vs
modprobe ip_vs_rr
modprobe ip_vs_wrr
modprobe ip_vs_sh
3. LVS-DR模式详细配置
3.1 负载均衡器配置
在Director节点（假设IP为192.168.1.10）上：
bash复制# 安装管理工具
yum install ipvsadm -y
# 配置VIP
ip addr add 192.168.1.100/32 dev ens33
# 设置LVS规则
ipvsadm -A -t 192.168.1.100:80 -s rr
ipvsadm -a -t 192.168.1.100:80 -r 192.168.1.20 -g
ipvsadm -a -t 192.168.1.100:80 -r 192.168.1.21 -g
# 查看规则
ipvsadm -Ln
3.2 真实服务器配置
在所有RealServer节点上（以192.168.1.20为例）：
bash复制# 配置VIP（关键步骤）
ip addr add 192.168.1.100/32 dev lo:1
# 设置ARP抑制
echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce
# 验证配置
ip addr show lo:1
cat /proc/sys/net/ipv4/conf/all/arp_ignore
避坑指南：如果发现真实服务器无法收到请求，99%的情况是ARP抑制没生效。可以用
tcpdump -i ens33 arp命令观察ARP请求是否被正确处理。
4. 高级调优与监控方案
4.1 会话保持实现
DR模式默认是无状态的，需要会话保持时可以：
bash复制# 使用源地址哈希算法
ipvsadm -E -t 192.168.1.100:80 -s sh
# 或设置持久化服务（300秒超时）
ipvsadm -A -t 192.168.1.100:80 -p 300
4.2 健康检查机制
原生LVS只有简单的四层检测，建议补充应用层检查：
bash复制# 安装keepalived
yum install keepalived -y
# 配置样例（/etc/keepalived/keepalived.conf）
vrrp_instance VI_1 {
state MASTER
interface ens33
virtual_router_id 51
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.1.100
}
}
virtual_server 192.168.1.100 80 {
delay_loop 6
lb_algo rr
lb_kind DR
persistence_timeout 50
protocol TCP
real_server 192.168.1.20 80 {
weight 1
HTTP_GET {
url {
path /health
status_code 200
}
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
}
}
}
4.3 性能监控指标
关键监控项及采集方法：
bash复制# 查看连接分布
watch -n 1 ipvsadm -lnc
# 统计每秒请求数
ipvsadm -ln --rate | awk 'NR>2 {print $3}'
# 内核参数调优（/etc/sysctl.conf）
net.ipv4.vs.expire_nodest_conn = 1
net.ipv4.vs.conn_reuse_mode = 1
net.ipv4.vs.expire_quiescent_template = 1
5. 生产环境常见问题排查
5.1 MAC地址漂移问题
现象：部分请求无法到达真实服务器
排查步骤：
- 在Director上抓包：
tcpdump -i ens33 host 192.168.1.100 - 检查RealServer的VIP是否配置在lo接口
- 确认所有RealServer的arp_ignore/arp_announce设置
- 检查交换机端口安全策略是否阻止了MAC变化
5.2 负载不均问题
案例：两台服务器CPU使用率差异超过40%
解决方案：
- 检查调度算法：
ipvsadm -Ln - 考虑改用wrr加权轮询：
bash复制
ipvsadm -E -t 192.168.1.100:80 -s wrr ipvsadm -e -t 192.168.1.100:80 -r 192.168.1.20 -g -w 3 ipvsadm -e -t 192.168.1.100:80 -r 192.168.1.21 -g -w 1 - 检查是否开启SYN Cookie：
sysctl net.ipv4.vs.syncookies
5.3 高并发下的连接丢失
优化方案：
bash复制# 调整内核参数
echo 100000 > /proc/sys/net/ipv4/vs/max_conns
echo 1 > /proc/sys/net/ipv4/vs/conntrack
# 增加LVS哈希表大小
ipvsadm --set 2097152 262144 1048576
6. 与传统方案的对比测试
我们在测试环境对比了三种方案（测试工具：wrk，1000并发连接）：
| 方案类型 | 吞吐量 (req/s) | 平均延迟(ms) | CPU使用率 |
|---|---|---|---|
| Nginx反向代理 | 12,000 | 8.2 | 75% |
| LVS-NAT模式 | 28,000 | 3.5 | 62% |
| LVS-DR模式 | 45,000 | 1.2 | 38% |
测试中发现DR模式的两个关键优势：
- 响应流量不经过Director，网络带宽减半
- 内核态转发比应用层代理节省约40%的CPU开销
7. 云环境下的特殊考量
现代云平台（如AWS、阿里云）通常需要特殊处理：
-
禁用源/目标检查：
bash复制# AWS EC2实例属性 aws ec2 modify-instance-attribute --instance-id i-xxx --no-source-dest-check -
使用Secondary IP代替VIP：
bash复制# 阿里云示例 ip addr add 192.168.1.100/32 dev eth0 -
云负载均衡器兼容方案：
- 通过VxLAN隧道封装DR流量
- 使用BGP协议宣告VIP路由
我在迁移到阿里云时发现，他们的共享带宽实例与DR模式存在兼容性问题，最终解决方案是在ECS前挂载NLB四层负载均衡，后端仍保持DR架构。