如何通过调优 Keepalived 的 lvs_method 优化四层负载均衡转发性能

Keepalived的lvs_method应优先选DR模式，因其性能最优；次选NAT（需优化conntrack）；TUN仅作兜底。三者分别对应IPVS的DR、NAT、TUN模型，差异在于转发路径、网络约束与开销。 Keepalived 本身不直接处理四层流量转发，真正执行 LVS 转发的是 Linux 内核的 IPVS 模块； lvs_method 是 Keepalived 配置中用于指定 IPVS 工作模式的关键参数，它的选择直接影响转发路径长度、连接保持能力、NAT 开销和后端服务器网络拓扑适配性。调优它不是“改个值就变快”，而是根据实际网络结构和业务特征匹配最轻量、最直接的转发路径。 明确 lvs_method 的三种取值与核心差异 Keepalived 的 lvs_method 实际对应 IPVS 的三种工作模型：DR（Direct Routing）、NAT（Network Address Translation）、TUN（IP Tunneling）。它们在数据包处理层面有本质区别： DR 模式 ：负载均衡器仅修改请求报文的目标 MAC 地址为真实服务器的 MAC，IP 不变；响应由真实服务器直接返回客户端（绕过负载均衡器）。性能最高，但要求所有节点在同一物理网段，且真实服务器需配置 VIP 的 lo 接口并禁用 ARP 响应。 NAT 模式 ：负载均衡器同时修改请求报文的目标 IP 和端口（DNAT），并将响应报文的源 IP 和端口做反向转换（SNAT）。所有流量双向经过负载均衡器，适合跨网段部署，但会成为带宽和连接跟踪（conntrack）瓶颈。 TUN 模式 ：负载均衡器将原始 IP 包封装进新的 IP 包（隧道），发往真实服务器；服务器解封装后响应直回客户端。无需同网段，但增加封装/解封装开销，且需内核支持 IPIP 模块，运维复杂度高。 优先选用 DR 模式提升吞吐与并发 在满足前提条件下，DR 是四层转发性能最优解。它避免了 NAT 的地址转换和连接状态维护，内核路径最短，单机可轻松支撑 10 万+ 并发连接。启用前必须确认： 所有 LVS 节点（Master/Backup）与 RealServer 在同一二层广播域（如 VLAN 或物理交换机直连）； RealServer 上已配置 VIP 到 loopback 接口（如 ）； RealServer 禁用对 VIP 的 ARP 响应（ 和 ）； Keepalived 配置中明确指定 ，并在 virtual_server 块中正确设置 real_server 的 IP 和端口。 慎用 NAT 模式，规避 conntrack 性能陷阱 若网络结构强制使用 NAT（如 RealServer 分布在不同子网），需重点优化内核 conntrack 行为，否则高并发下易出现丢包或新建连接延迟： 增大连接跟踪表上限： ； 缩短超时时间以快速释放空闲连接： ； 关闭对非 SYN 包的连接跟踪（适用于纯转发场景）： ； 确保负载均衡器 CPU 核心数充足，conntrack 是强 CPU 密集型操作。 避免无谓封装，TUN 模式仅作兜底方案 TUN 模式因额外 IP 封装带来约 20–30μs 延迟，且隧道 MTU 易引发分片，实际生产中极少作为首选。仅在以下情况考虑： RealServer 完全无法调整网络配置（如云厂商托管实例，不允许配置 lo:VIP 或禁用 ARP）； DR 和 NAT 均不可行，且对延迟不敏感（如后台批处理接口）； 已启用内核 模块并验证隧道连通性（ + ）。 选对 lvs_method 是四层性能调优的第一步，它决定了流量是否绕过内核协议栈冗余处理。DR 最快但约束多，NAT 最通用但需防 conntrack 瓶颈，TUN 最灵活但代价明确。没有“万能模式”，只有“最适合当前网络拓扑的模式”。