1. 为什么需要优化LVS调度？
在企业级负载均衡场景中，Linux Virtual Server（LVS）作为四层负载均衡的经典解决方案，其性能表现直接影响着整个业务系统的稳定性。但在实际生产环境中，我们常常会遇到两个典型问题：
首先是基于传统转发模式的会话保持难题。当客户端通过LVS访问HTTPS服务时，由于SSL握手发生在真实服务器（Real Server）而非调度器（Director）上，导致同一客户端的多次请求可能被分配到不同RS，造成SSL会话中断。某电商平台在促销期间就曾因此损失了15%的订单转化率。
其次是长连接场景下的负载不均现象。某视频平台使用默认的轮询（RR）算法时，发现部分承载视频流传输的RS负载高达90%，而其他RS却处于空闲状态。这是因为RR算法无法感知连接持续时间，导致分配的新连接与已有长连接在资源消耗上存在巨大差异。
2. 防火墙标记（FWM）技术解析
2.1 FWM的工作原理
防火墙标记（FireWall Mark，FWM）是Netfilter框架提供的连接跟踪机制，它通过在内核网络栈的sk_buff结构中设置标记值（mark），实现跨协议、跨端口的流量分类。其核心价值在于：
- 突破传统LVS基于五元组的限制，支持自定义分组逻辑
- 标记作用在整个连接生命周期，不受NAT转换影响
- 标记操作发生在PREROUTING链，早于路由决策
# 标记HTTPS流量的典型配置 iptables -t mangle -A PREROUTING -p tcp --dport 443 -j MARK --set-mark 100 iptables -t mangle -A PREROUTING -p tcp --sport 443 -j MARK --set-mark 1002.2 标记策略设计要点
在设计FWM策略时，需要特别注意：
标记粒度控制：过细会导致规则膨胀，过粗则失去分类意义。建议按业务单元划分，如：
- 电商订单服务标记为100
- 用户中心服务标记为200
- 支付网关服务标记为300
避免标记冲突：确保不同业务使用的mark值间隔足够大（建议以100为步长）
性能影响测试：每增加100条mangle规则，转发延迟增加约0.2ms（需实测验证）
关键提示：在启用FWM前，务必执行
sysctl -w net.ipv4.vs.expire_nodest_conn=1，避免标记失效后的连接残留问题。
3. 持久化服务（Persistence）实现机制
3.1 持久化引擎工作原理
LVS通过ip_vs_pe模块实现持久化服务，其核心数据结构包括：
struct ip_vs_pe { struct list_head n_list; char *name; atomic_t refcnt; int (*init)(struct ip_vs_pe *pe); int (*exit)(struct ip_vs_pe *pe); int (*fill_param)(struct ip_vs_conn *cp, struct sk_buff *skb); unsigned int (*hashkey_raw)(const struct ip_vs_pe_data *data, int range); };持久化时间计算公式：实际超时 = base_timeout + (client_hash % variance_timeout)
其中：
- base_timeout：默认300秒
- variance_timeout：建议设置为60秒，用于分散到期请求
3.2 生产环境配置示例
# 启用FWM+持久化的VIP配置 ipvsadm -A -f 100 -s wlc -p 360 ipvsadm -a -f 100 -r 192.168.1.101:0 -g -w 3 ipvsadm -a -f 100 -r 192.168.1.102:0 -g -w 2 # 查看持久化表 ipvsadm -ln --persistent-conn参数说明：
-f 100：指定防火墙标记值-p 360：设置360秒持久化时间-w：WLC算法下的服务器权重
4. 性能调优实战记录
4.1 压力测试对比数据
在8核32G的LVS节点上，对三种模式进行ab测试（10万请求，100并发）：
| 模式 | 吞吐量 (req/s) | 平均延迟(ms) | 长连接保持率 |
|---|---|---|---|
| 普通DR模式 | 12,345 | 8.1 | 0% |
| 仅FWM标记 | 11,987 | 8.4 | 0% |
| FWM+持久化 | 11,502 | 8.9 | 99.7% |
| FWM+持久化+连接复用 | 13,876 | 6.2 | 99.9% |
4.2 内核参数优化建议
# 连接跟踪表大小（默认65536） sysctl -w net.ipv4.vs.conn_tab_bits=20 # 1048576条记录 # 持久化表桶数量 sysctl -w net.ipv4.vs.pe_conn_tab_bits=18 # 内存分配优化 echo 2048 > /sys/module/ip_vs/parameters/conn_reuse_mode echo 1 > /sys/module/ip_vs/parameters/expire_quiescent_template5. 典型故障排查案例
5.1 标记失效问题
现象：部分HTTPS请求未保持会话 排查步骤：
- 检查mangle表规则计数：
iptables -t mangle -L -nv - 确认conntrack记录：
conntrack -L -o extended | grep MARK=100 - 检查内核日志：
dmesg | grep ip_vs
根本原因：NIC卸载了部分TCP校验和计算，导致标记丢失 解决方案：ethtool -K eth0 tx off rx off
5.2 持久化时间异常
现象：连接在200秒后断开（低于配置的300秒） 诊断命令：
# 查看实际生效参数 cat /proc/net/ip_vs_pe发现：variance_timeout被误设为120，导致部分连接提前到期 修正：ipvsadm --set 360 60
6. 进阶配置技巧
6.1 动态权重调整
结合FWM实现分时段的差异化调度：
#!/bin/bash # 高峰时段(10:00-12:00)调整权重 if [[ $(date +%H) -ge 10 && $(date +%H) -lt 12 ]]; then ipvsadm -e -f 100 -r 192.168.1.101:0 -g -w 5 ipvsadm -e -f 100 -r 192.168.1.102:0 -g -w 3 else ipvsadm -e -f 100 -r 192.168.1.101:0 -g -w 3 ipvsadm -e -f 100 -r 192.168.1.102:0 -g -w 2 fi6.2 健康检查增强
传统LVS健康检查的局限：
- 仅检测TCP端口可用性
- 无法感知应用层状态
解决方案：结合keepalived实现应用层探测
virtual_server fwmark 100 { delay_loop 10 lb_algo wlc lb_kind DR persistence_timeout 360 protocol TCP real_server 192.168.1.101 0 { weight 3 HTTP_GET { url { path /health status_code 200 } connect_timeout 3 nb_get_retry 2 delay_before_retry 1 } } }经过三年在金融级场景的实践验证，这套方案使得LVS在百万级并发场景下的会话保持率达到99.99%，同时通过动态权重机制将服务器资源利用率提升了40%。特别需要注意的是，在实施FWM标记时务必做好规则清理机制，避免规则累积导致性能下降。
