做负载均衡这一块LVS 的 DR 模式Direct Routing绝对是最绕不开的经典方案之一。很多人翻遍了网上的帖子要么只给了命令没有原理要么把数据流转讲得玄之又玄。这篇文章我尽量用大白话把 LVS DR 模式从原理到配置、从选型到排障一次讲透。不论你是刚接触负载均衡的运维实习生还是准备优化公司现有集群的架构师只要你需要处理高并发流量分发这篇内容都值得你花十分钟仔细看完。1. DR 模式到底解决了什么问题1.1 三种模式一句话对比LVS 官方提供三种工作模式很多人一开始就卡在选型上。其实拿一句话就能说明白NAT 模式请求和响应都走调度器调度器像公司前台所有信都要经手简单但最容易成为瓶颈DR 模式Direct Routing请求进调度器响应直接从后端服务器回给客户端调度器只负责分发性能最好生产环境里用得最多TUN 模式把原始报文封装成隧道报文发给后端RS 解封装后处理适合跨机房跨网段的场景但封装解封装有额外开销。DR 模式之所以被广泛应用核心就一个字省。省掉了一半流量的转发压力调度器只需要处理入站请求不用扛响应流量。在高并发场景下响应流量往往比请求流量大得多这一点直接决定了 DR 模式可以扛住很大的吞吐量。1.2 一个包从客户端到 RS 再到客户端完整走一遍要理解 DR 模式关键是把数据包流转过程看一遍。假设客户端 IP 是 203.0.113.5VIP虚拟 IP是 192.168.1.100后端 RS 是 192.168.1.11 和 192.168.1.12调度器 Director 的物理 IP 是 192.168.1.10。第一步客户端发起访问目的 IP 是 VIP 192.168.1.100。这个包正常走路由到达交换机然后交换机广播 ARP 请求问“谁有 192.168.1.100 这个地址”。整个局域网里只有调度器 Director 会回答这个 ARP 请求后端 RS 的 ARP 被专门抑制了所以交换机学到的是 VIP 对应 Director 的 MAC 地址。数据包最终到达 Director 的物理网卡。第二步Director 收到包后根据负载均衡算法选出一台 RS比如 192.168.1.11。注意关键操作来了Director 会改写数据链路层的目标 MAC 地址把目标 MAC 改成 192.168.1.11 的网卡 MAC然后把数据包重新从网卡发出去。IP 层的源 IP 和目标 IP 完全不动依旧是客户端的 IP 和 VIP。这就是“直接路由”名字的由来它只动 MAC不动 IP。第三步交换机根据 MAC 地址把数据包送到 192.168.1.11 这台 RS 上。RS 发现数据包目标 IP 是 VIP 192.168.1.100而它自己的 lo:0 接口上恰好绑定了这个 VIP于是认为这个包确实是给自己的正常收下交给 nginx 或者 Tomcat 之类的 Web 服务处理。第四步RS 处理完请求后直接构造响应数据包源 IP 是 VIP 192.168.1.100目标 IP 是客户端 203.0.113.5。它不把响应回传给 Director而是按自己机器的路由表走从网卡发给交换机交换机再一路转回客户端。客户端看到的响应源 IP 就是 VIP完全感知不到后端是哪台机器处理的。这个流程里最核心的一句话就是进站流量只改 MAC出站流量完全绕开调度器。这也是 DR 模式高性能的根本原因。1.3 为什么必须绑定 VIP 和压制 ARP理解了数据流转你会发现一个隐藏问题RS 收到目标 IP 是 VIP 的包凭什么认为这是自己的包如果 RS 压根没绑定 VIP内核会直接把这个包丢掉因为本机没有哪个接口配置了 192.168.1.100 这个地址。所以在每台 RS 上都要把 VIP 配置到 loopback 接口上通常是 lo:0掩码必须写成 255.255.255.255也就是 /32。为什么要弄在 loopback 上因为把 VIP 放在 eth0 这种物理接口上很容易和实际 IP 互相干扰而且掩码广播可能产生额外的 ARP 响应。放在 lo 上单纯让内核认这个地址不占物理接口。但问题又来了如果每台 RS 的 lo 上都绑定了同一个 VIP当交换机广播“谁有 192.168.1.100”时所有 RS 默认都会回答“我有”。这样 ARP 缓存就乱了交换机一会儿把包发给这台机器的 MAC一会儿发给那台整个集群直接抽风。所以必须设置两个核心内核参数arp_ignore 1只回答目标 IP 是本接口 IP 的 ARP 请求。RS 的 eth0 接口 IP 是 192.168.1.11当收到“谁有 192.168.1.100”的请求时目标 IP 不是 eth0 的地址于是不回应。arp_announce 2发起 ARP 请求时尽量使用最合适的本机地址作为源 IP避免把 VIP 这种虚拟地址作为 ARP 包的源地址广播出去。这两个参数缺一不可只配 arp_ignore 不配 arp_announce 也勉强能跑但生产环境一定要把两个都配上而且要持久化不然机器一重启就前功尽弃。2. 动手前的环境与设计别急着敲命令2.1 网络拓扑标准形态DR 模式的一个硬性前提是Director 和所有 RS 必须在同一个二层网络里。为什么因为 Director 转发数据包时只改目标 MAC 地址不改 IP这个包必须在同一个广播域内才能送到 RS。如果 RS 在另一个网段交换机一看目标 IP 根本不是本网段的直接就按路由走了Director 改的 MAC 地址毫无意义。典型拓扑是这样一台或者两台 Director配合 keepalived 做高可用下面挂 N 台 RS所有机器接在同一台交换机或者同一个 VLAN 内VIP 配置在 Director 的网卡上通常是一块独立网卡或子接口后端 RS 的 lo:0 上也绑定 VIP但 ARP 被抑制。有一点要提前说清楚RS 的默认网关一定要指向上游路由器或交换机而不是指向 Director。很多人在这里被坑过RS 的网关写了 Director 的 IP结果响应包回传又绕回 Director等于把 DR 模式硬生生改成了低配版 NAT而且乱七八糟的转发路径让排查变成噩梦。2.2 角色分工与系统准备按照一个标准集群来规划假设我有两台 Director 做高可用三台 RS 跑 Web 服务角色主机名IP 地址VIP说明Director-Masterlvs-master192.168.1.10192.168.1.100keepalived MASTERDirector-Backuplvs-backup192.168.1.20192.168.1.100keepalived BACKUPRealServer-1rs-1192.168.1.11192.168.1.100 (lo:0)nginxRealServer-2rs-2192.168.1.12192.168.1.100 (lo:0)nginxRealServer-3rs-3192.168.1.13192.168.1.100 (lo:0)nginx软件层面Director 需要安装 ipvsadm 用来配置 LVS 规则另外再装 keepalived 实现 VIP 漂移和健康检查。RS 只需要正常的 Web 服务环境不需要安装 LVS 相关的任何东西只需要改内核参数和绑 VIP。系统我建议直接用 CentOS/Rocky 这类发行版内核自带 ip_vs 模块不需要额外编译。Ubuntu/Debian 也没问题配置方法完全一致。2.3 三个必须提前确认的内核开关在动手之前有几件事一定要确认不然后面全是坑。第一件确认 ip_vs 模块可用。运行modprobe ip_vs然后lsmod | grep ip_vs如果没有输出说明内核没加载成功可能要检查内核版本或者安装对应包。这一步不通过后续 ipvsadm 全白搭。第二件DR 模式不需要开启 IP 转发。NAT 模式才需要net.ipv4.ip_forward1DR 模式改了 MAC 直接在同一二层网段转发根本不需要路由转发。网上很多教程一刀切地让你开 IP 转发DR 模式下开不开都行但没必要建议保持默认值减少攻击面。第三件RS 侧的 rp_filter反向路径过滤最好设为宽松模式或者关闭具体做法是echo 0 /proc/sys/net/ipv4/conf/all/rp_filter echo 0 /proc/sys/net/ipv4/conf/eth0/rp_filter为什么要动它rp_filter 的作用是检查进入的数据包源 IP 是否可从收到包的接口返回如果不对称就丢弃。DR 模式下 RS 收到的包源 IP 是客户端地址目标 IP 是 VIP包从 eth0 进来但本机对客户端地址的回应路径可能不完全符合 rp_filter 的校验逻辑在个别内核版本和网络环境下会产生丢包。提前把它关了能省掉后面很多莫名的连接超时问题。3. 实操配置按这个顺序来就行3.1 RS 侧三步配置绑定 VIP、抑制 ARP、持久化RS 侧的配置是整个 DR 模式最容易出错的地方也是最关键的环节。我给出一套完整步骤每台 RS 都要执行一遍。第一步绑定 VIP 到 lo:0ip addr add 192.168.1.100/32 dev lo:0注意这里掩码是 /32这个细节很关键。如果你写成 /24即使其他配置都对也容易出现 ARP 响应异常。第二步立即生效 ARP 抑制参数echo 1 /proc/sys/net/ipv4/conf/all/arp_ignore echo 1 /proc/sys/net/ipv4/conf/lo/arp_ignore echo 1 /proc/sys/net/ipv4/conf/eth0/arp_ignore echo 2 /proc/sys/net/ipv4/conf/all/arp_announce echo 2 /proc/sys/net/ipv4/conf/lo/arp_announce echo 2 /proc/sys/net/ipv4/conf/eth0/arp_announce很多人只写了 all 的配置实际内核在判断 arp_ignore 时取的是 max(conf/all, conf/eth0) 这类取大值逻辑而 arp_announce 取的是 min 逻辑。理论上只配 all 也行但为了防止云平台、虚拟化层对参数进行干扰我习惯把所有实际生效的接口都配一遍图个稳妥。第三步写入 /etc/sysctl.conf 持久化net.ipv4.conf.all.arp_ignore 1 net.ipv4.conf.all.arp_announce 2 net.ipv4.conf.lo.arp_ignore 1 net.ipv4.conf.lo.arp_announce 2 net.ipv4.conf.eth0.arp_ignore 1 net.ipv4.conf.eth0.arp_announce 2 net.ipv4.conf.all.rp_filter 0 net.ipv4.conf.eth0.rp_filter 0改完之后运行sysctl -p让配置生效再用sysctl -a | grep arp_ignore确认你期望的值都写进去了。这里有个容易迷糊的地方/proc/sys/net/ipv4/conf/all/下的值不是单独限制某个网卡它是一个全局模板最终每个接口的生效值由接口自己的配置和 all 组合决定。所以当你发现 eth0 上的值不对时别惊讶检查 all 的配置和 eth0 自己的配置是否一致。另外RS 上 web 服务绑定的地址要注意。很多 nginx 配置成监听某个具体物理 IP比如listen 192.168.1.11:80这就糟糕了因为请求目标 IP 是 VIPnginx 根本不监听 VIP。正确做法要么监听0.0.0.0:80要么干脆监听192.168.1.100:80。我推荐统一监听 0.0.0.0后面换 VIP 时不用一台一台改 nginx 配置。3.2 LVS 调度器配置ipvsadm 命令实战接下来配置 Director。假设我已经在 Director 上装了 ipvsadm。第一步加载模块并确认modprobe ip_vs modprobe ip_vs_wrr modprobe ip_vs_sh lsmod | grep ip_vs第二步在 Director 的 eth0 上绑定 VIPip addr add 192.168.1.100/24 dev eth0有的人习惯用eth0:0子接口本质上没区别。只要 Director 的这个接口能响应 VIP 的 ARP 请求即可。注意这里掩码用的是 /24需要让 Director 认为 VIP 和自己同网段能正常对外通信和 RS 的 /32 是两个概念。第三步配置 LVS 虚拟服务ipvsadm -A -t 192.168.1.100:80 -s wrr -p 300 ipvsadm -a -t 192.168.1.100:80 -r 192.168.1.11:80 -g -w 2 ipvsadm -a -t 192.168.1.100:80 -r 192.168.1.12:80 -g -w 1 ipvsadm -a -t 192.168.1.100:80 -r 192.168.1.13:80 -g -w 1解释一下每个参数-A表示添加一个虚拟服务-t指定协议为 TCP 和 VIP 端口-s wrr指定调度算法为加权轮询-p 300表示持久连接超时时间 300 秒来自同一客户端的连接在这个时间内都会转发到同一台 RS可以理解为一种会话保持-a表示往虚拟服务里添加 RS-r指定 RS 地址和端口-g是关键它表示使用网关模式也就是 DR 模式如果你是 NAT 模式这里要改成-mTUN 模式用-i记不住这三个参数等于白配-w是权重weight 越大接收的请求比例越高适用于后端机器性能不均匀的场景。配置完用ipvsadm -Ln查看规则用ipvsadm -Ln --stats看统计。如果看到 TCP 192.168.1.100:80 下面列着三台 RS每台 RS 后面标注的 Route 类型是 Local说明配置正确。这里有个很重要的细节Director 不需要开启 IP 转发也不要对 VIP 的包做 iptables 的 DNAT因为 LVS 是在内核 IPVS 层面处理根本不走 iptables 的 NAT 链。如果你额外加了 iptables 规则反而可能把数据包改得乱七八糟。3.3 keepalived 高可用配置单台 Director 一旦故障整个负载均衡就废了。生产环境一定会用 keepalived 做高可用核心就是 VRRP 漂移 VIP。keepalived 的作用有两个一是让两台 Director 组成主备VIP 默认在 Master 上Master 挂掉后 VIP 漂移到 Backup二是定期检查后端 RS 的健康状态发现 RS 故障自动从 LVS 规则里摘掉。主节点配置的核心片段vrrp_instance VI_1 { state MASTER interface eth0 virtual_router_id 51 priority 120 advert_int 1 authentication { auth_type PASS auth_pass 123456 } virtual_ipaddress { 192.168.1.100/24 dev eth0 } } virtual_server 192.168.1.100 80 { delay_loop 6 lb_algo wrr lb_kind DR protocol TCP real_server 192.168.1.11 80 { weight 2 TCP_CHECK { connect_timeout 3 nb_get_retry 3 delay_before_retry 3 } } real_server 192.168.1.12 80 { weight 1 TCP_CHECK { connect_timeout 3 nb_get_retry 3 delay_before_retry 3 } } real_server 192.168.1.13 80 { weight 1 TCP_CHECK { connect_timeout 3 nb_get_retry 3 delay_before_retry 3 } } }备份节点的配置只有两处不一样state BACKUPpriority 100。virtual_router_id必须和主节点完全一致否则 VRRP 不认对方auth_pass也要一致否则认证失败。主备的lb_algo、lb_kind、real_server 列表必须一致不然 VIP 切换到备份节点后负载策略就变了。这里我推荐把健康检查从 TCP_CHECK 升级成 HTTP_GET因为 TCP_CHECK 只能确认端口通不通如果后端应用卡死了但端口还开着TCP_CHECK 是查不出来的。用 HTTP_GET 检查一个具体的健康检查 URL 或者首页更接近用户真实访问效果real_server 192.168.1.11 80 { weight 2 HTTP_GET { url { path /healthz status_code 200 } connect_timeout 3 nb_get_retry 3 delay_before_retry 3 } }keepalived 启动后确认 VIP 落在 Master 节点上可以用ip addr show eth0检查。测试高可用时直接停掉 Master 上的 keepalived 或直接关机VIP 应该在几秒内漂移到 Backup 上整个过程中 Web 服务不中断。3.4 上线前的验证清单所有配置完成后不要急着把流量切过来先按下面的清单过一遍在 Director 上执行ipvsadm -Ln确认三条 RS 记录都在在每台 RS 上执行ip addr show lo确认 lo:0 上绑定了 VIP掩码是 /32在每台 RS 上执行cat /proc/sys/net/ipv4/conf/eth0/arp_ignore确认输出是 1从客户端机器ping VIP确认能通并且arp -a看到的 VIP 对应 MAC 是 Director 的 MAC而不是任何一台 RS 的 MAC连续多次访问http://VIP在每台 RS 上tail -f /var/log/nginx/access.log确认请求被分发到了多台机器把其中一台 RS 的 nginx 停掉等 keepalived 健康检查周期结束delay_loop 时间确认ipvsadm -Ln里这台 RS 被标记为不可用或直接被移除。这套验证流程走完基本可以放心上线。4. 常见问题与排查经验4.1 连不通时按这七个点逐层排查DR 模式配置完后连不通是每个人都会遇到的事。我总结了七个排查点按顺序查效率最高第一确认 VIP 能不能在 Director 上 ping 通。如果不能检查 Director 的 VIP 绑定有没有生效以及网络是否连通。第二检查 RS 的 lo:0 上是否绑定了 VIP。命令是ip addr show lo很多人在 RS 上忘了执行这一步RS 收到包后直接丢弃表现为 Director 上能看到连接统计在增长但 RS 上抓包一点请求都没有。第三检查 RS 的 ARP 抑制是否生效。这里要特别注意很多发行版的 network 服务重启后会重置 sysctl 配置你得确认/etc/sysctl.conf写对了。一个简单的测试方法在第三方机器上arp -d 192.168.1.100清缓存然后ping VIP再arp -a看 MAC 是不是 Director 的。如果看到 RS 的 MAC说明 ARP 抑制没起作用。第四检查 RS 上的 Web 服务监听地址。用netstat -tlnp看 80 端口是不是监听 0.0.0.0 或 VIP如果只监听自己的物理 IP请求到了也进不了应用。第五检查 RS 的默认路由。ip route show确认默认网关指向真正的路由器而不是 Director。这个错误非常隐蔽配置完一开始可能能通一旦 Director 重启或者 VIP 漂移流量就全乱了。第六检查防火墙。RS 本机 iptables 如果开了注意要放行目标 IP 为 VIP 的流量因为 RS 认为 VIP 是自己的地址防火墙规则也会对 VIP 流量生效。这个坑我见过太多次了服务器上明明有-A INPUT -p tcp --dport 80 -j ACCEPT但那是针对物理 IP 的目标 IP 是 VIP 的数据包可能被 DROP。第七抓包确认数据路径。在 RS 上执行tcpdump -i eth0 host 192.168.1.100然后客户端访问 VIP。如果 RS 上能抓到请求包但客户端访问失败问题基本在回包路由或者 RS 的应用层如果 RS 上什么都抓不到问题就在 Director 的转发或者二层链路。4.2 三个经典翻车场景第一个经典场景刚配置完是好的重启后全部失效。原因基本确定是 sysctl.conf 没有持久化或者 VIP 绑定没有写成开机自启。RS 重启后 lo:0 上的 VIP 消失arp_ignore恢复默认 0整个集群瞬间爆炸。解决办法是把绑定命令写到/etc/rc.local或者用 network-scripts 的 ifcfg-lo:0 文件管理。用 systemd 环境写一个简单的 service 单元也行。第二个经典场景时好时坏一会能通一会不通。这种大概率是 ARP 缓存错乱。局域网内可能有别的机器也绑了相同的 VIP或者某台 RS 的 arp_ignore 没设置成功在响应 VIP 的 ARP。你可以连续ping VIP十几次观察arp -a的 MAC 是否有变化。一旦发现变来变去把所有 RS 的 ARP 配置检查一遍。第三个经典场景VIP 能通LVS 规则也在但就是没有流量进来。这时候看ipvsadm -Ln --stats如果 InActConn 一直增长但 ActiveConn 归零说明 TCP 连接没有真正建立起来往往是 RS 回包路径不对或者 RS 应用层根本没响应。重点查 RS 的默认网关和应用监听地址。4.3 压力视角的几点调优DR 模式虽然很能扛但该调的地方还是得调。我列几个实际项目中生效明显的优化点第一件合理设置后端权重。不要让所有 RS 都设置 weight 1根据 CPU 核数、内存大小做加权让强机器多分担流量弱机器少承担。这个不是 LVS 本身性能问题但直接影响整体吞吐。第二件注意 Director 的软中断压力。DR 模式虽然响应不回 Director但入站流量依然不少高并发时 Director 的 CPU 软中断会飙升。建议在 Director 上启用网卡多队列RSS配合 irqbalance 把中断分散到多个 CPU 核心。第三件关闭不必要的 conntrack 跟踪。如果 Director 上没有复杂的防火墙需求尽量不要启用大量 conntrack因为连接跟踪表一旦满了新连接会直接丢包。可以在 raw 表里对 VIP 流量设置 NOTRACK让 LVS 分发的数据包不走 conntrack。第四件调整内核 TCP 参数。比如提高net.core.somaxconn和net.ipv4.tcp_max_syn_backlog防止高并发瞬间握手队列打满。net.core.somaxconn 65535 net.ipv4.tcp_max_syn_backlog 65535 net.ipv4.tcp_tw_reuse 1 net.ipv4.tcp_fin_timeout 30这些参数不是 LVS 特有但对整个负载均衡链路都有帮助。5. 调度算法与会话保持的补充说明5.1 生产环境里调度算法到底怎么选LVS 支持的调度算法很多但生产环境值得重点用的就那么几个。轮询rr和加权轮询wrr适合后端机器规格一样或性能差异明确的场景。特点是简单、均匀、无状态。最少连接lc和加权最少连接wlc会把新请求分给当前活跃连接最少的 RS适合请求处理时间波动比较大的业务。比如一个请求耗时 1 毫秒另一个请求耗时 3 秒轮询模式下很难保证均衡最少连接能拉平负载。wlc 是默认推荐的算法也是很多生产集群的首选。源地址哈希sh按客户端 IP 哈希到固定 RS天然实现会话保持。适合那些不想额外开持久连接的场景但缺点是如果某台 RS 下线哈希到它上面的客户端全部受影响。我的建议很直接后端机器配置一样就选 wrr处理时间波动大就选 wlc需要会话保持就用 sh 或开持久连接。5.2 持久连接和 SH 算法的区别这两个东西经常有人混在一起。持久连接-p 300不是一种算法它是在 LVS 虚拟服务上开启的一个功能同一来源 IP 的请求在指定时间内都被调度到同一台 RS。即使你的算法是 rr只要开了 -pRR 就只在第一次连接时发生之后相同来源都固定到同一台。适合登录态保存在本机内存的应用。SH 算法呢是直接从哈希上保证同一个源 IP 一定会命中同一台 RS不需要额外维护超时状态。它的前提是源 IP 集合足够分散否则可能造成倾斜。在实际使用中如果应用无状态直接搞轮询健康检查就完了如果应用不能在多节点共享 Session优先考虑 SH 算法或持久连接。但话说回来现在的主流架构基本都做无状态设计了Session 外移到 Redis 之类的缓存层这比依赖 LVS 做会话保持要可靠得多。6. 结尾我在实际项目里被 LVS DR 模式折磨过很多次最后发现绝大多数事故都不是 LVS 本身的问题而是出在 ARP 和路由这两件小事上。每当你觉得“集群很诡异”的时候放下那些复杂的调度算法和性能参数先去检查 RS 的arp_ignore和默认网关。把这两件事吃透DR 模式其实就像一层窗户纸。另外一个小建议每台 RS 的配置都尽量做成脚本管理不要手工敲毕竟人总有手滑的时候脚本还能在初始化新节点时自动把所有的坑都填平。