两年前我第一次在一套双网段机房环境里部署LVS-DR方案评审时被问了一个问题“DR模式要求RS和负载均衡器在同一个二层网络你这两个业务网段之间三层可达怎么办”当时差点被问住。后来硬着头皮把拓扑、VIP归属、路由策略重新捋了一遍才真正理解“DR能否多网段部署”这个问题的本质——不是能不能而是你怎么规划、怎么让回程路径不绕路。这篇文章就是基于那次实际项目总结出来的围绕“dr多网段案例部署和规划”这个主题展开。我会从DR模式原理、多网段下的选型逻辑、VIP与网段规划、完整部署步骤、以及我在实际环境中踩过的三个典型故障讲起最后补充日常运维和扩展时要注意的点。适合正在从单网段LVS往多网段过渡的运维也适合准备用LVS-DR做多租户负载均衡、但还没想清楚网段怎么切分的人参考。1. 多网段场景下选DR而不是NAT/TUN回程路径才是考量重点1.1 DR模式一句话原理只改MAC不改IP回程不经过入口LVS有三种工作模式NAT、DR、TUN。DR模式Direct Routing直接路由的核心特点是负载均衡器Director在转发请求时只改写数据链路层的目标MAC地址IP层的源IP、目标IP完全不动然后通过二层网络把报文直接送给选中的真实服务器RS。RS处理完请求后响应报文直接以自己的物理网卡、按自己的路由表发送给客户端。这个设计和NAT模式最大的区别在于回程流量不需要再绕回Director。NAT模式下请求进Director、响应也要出Director当并发量一上来Director的网卡和CPU就成了瓶颈。DR模式把这部分压力消解掉了所以单台Director能支撑的吞吐量可以比NAT模式高出一个量级尤其适合大流量、长连接、响应包体积大的业务。但代价是Director和RS必须在同一个二层广播域内否则Director改写完MAC地址之后报文根本送不到RS的网卡。这是DR模式的硬约束也是多网段部署里第一个要面对的边界条件。1.2 三种模式在多网段下的适用性对比很多同事一开始都会纠结“多网段到底能不能用DR”我的建议是先拉一张对比表把三种模式在网段隔离场景下的表现列清楚。对比维度NAT模式DR模式TUN模式二层广播域要求无特殊要求Director与RS同广播域无特殊要求回程路径是否经过Director是进出都过否RS直回客户端否RS直回客户端跨网段/跨机房支持三层可达即可同网段或同VLAN三层可达即可支持跨机房性能瓶颈Director网卡/CPU基本无回程瓶颈需要RS支持隧道封装配置复杂度低中ARP抑制是重点高需要IPIP隧道配置从表格能直接看出来如果两个网段之间只是三层路由可达、但二层完全隔离DR模式确实不适用这时候要么每个网段单独部署一套Director要么换TUN模式做跨网段隧道。但如果“多网段”指的是同一台Director通过多块网卡分别接入多个业务网段在每个网段内都有一组RS那么DR完全可行而且比每个网段都架一套NAT网关更省设备、更易于维护。我在实际项目里遇到的就是后者一台双网卡Directoreth0接入网段Aeth1接入网段B两个网段各自有VIP各自有一组RS。整个架构相当于在一台负载均衡器上跑了两套独立的LVS服务互不干扰。1.3 什么时候多网段还能用DR什么时候必须放弃判断标准其实就三条实测下来非常管用RS的VIP所在网段必须和Director对应网卡的网段在同一个广播域内。不管是直连二层交换机还是通过VLAN透传只要广播域通DR就能跑。各网段的RS不能共用同一个VIP。哪怕VIP的IP地址在不同网段恰好相同也要避免这种设计否则ARP宣告会互相污染调试起来极其痛苦。如果两个网段之间需要互相访问对方网段的RS且二层不通就要考虑TUN或者干脆每个网段独立部署不要强行在Director上做三层转发来补DR的链路那会引入额外的复杂度。2. 部署前的网段与VIP规划先把拓扑画对再动手2.1 业务网段、管理网段、VIP网段的划分原则DR多网段部署的规划第一步永远不是敲命令而是画拓扑。我在这次部署里把整个网络分成了三类划分原则可以复用业务网段承载RS业务流量的网段也就是RS物理网卡所在的网段。每个网段建议单独规划C段地址避免不同业务间的广播报文相互影响。管理网段Director和RS的SSH、监控、Agent通信单独走一个网段不要和业务VIP混在一起。管理流量和业务流量混跑时一旦某个RS被打满连上去排查都费劲。VIP网段VIP地址在规划时单独预留一段连续IP不分配给任何物理设备作为主地址只作为lo:0上的辅助地址存在。这样做的好处是后续加RS时不需要重新规划地址而且遇到ARP问题时定位范围更小。以这次部署为例三个网段是这么分的网段用途网段地址VIP规划说明业务网段A10.10.1.0/2410.10.1.100承载业务A的RS网关10.10.1.254业务网段B10.10.2.0/2410.10.2.100承载业务B的RS网关10.10.2.254管理网段192.168.100.0/24无Director和4台RS的SSH/监控专用2.2 VIP归属与网关约束不要在VIP上配网关多网段DR最容易出问题的地方其实是“VIP地址的归属”和“网关配置”。我见过有人为了方便把VIP直接写在RS的物理网卡上比如eth0上配置10.10.1.100/24这就直接踩了DR的雷。VIP在DR模式里是一个“虚地址”它存在的意义是让外部请求能够到达所有的RS而它的ARP应答必须由所有RS一起承担这就是后面要说的ARP抑制问题。如果你把VIP当作物理网卡的主IP配置网卡对外宣告ARP时就会以VIP作为源地址多个RS同时宣告同一个VIP交换机MAC表会左右横跳整个网段的通信都会变得断断续续。正确的做法是VIP只配置在RS的lo回环接口上并且子网掩码是32位/32不参与任何路由协议不配置网关。RS的默认网关仍然走物理网卡本地产生的回包路由靠的是物理网卡的主IP地址而不是VIP。另外Director上承载VIP的网卡IP不能和VIP处于同一子网并开启ARP响应这会和RS形成VIP争抢我在后面故障部分会详细展开。2.3 网口、IP、路由三张表的设计示例规划阶段我习惯用三张表把所有关键信息固定下来一旦环境复杂这三张表就是排查问题的地图。网口规划表角色物理网卡所属网段主IP附加VIPDirectoreth010.10.1.0/2410.10.1.1010.10.1.100Directoreth110.10.2.0/2410.10.2.1010.10.2.100RS-A1eth010.10.1.0/2410.10.1.1110.10.1.100在lo上RS-A2eth010.10.1.0/2410.10.1.1210.10.1.100在lo上RS-B1eth010.10.2.0/2410.10.2.2110.10.2.100在lo上RS-B2eth010.10.2.0/2410.10.2.2210.10.2.100在lo上IP地址规划表地址类型IP掩码绑定位置说明业务A网关10.10.1.254255.255.255.0交换机/路由器RS-A的默认网关业务B网关10.10.2.254255.255.255.0交换机/路由器RS-B的默认网关业务A VIP10.10.1.100255.255.255.255Director eth0 RS lo对外提供A业务入口业务B VIP10.10.2.100255.255.255.255Director eth1 RS lo对外提供B业务入口路由规划表源网段目的网段下一跳走哪个接口Director本机10.10.1.0/24直连eth0Director本机10.10.2.0/24直连eth1RS-A的默认路由0.0.0.0/010.10.1.254eth0RS-B的默认路由0.0.0.0/010.10.2.254eth0把这三张表填完基本就能回答“VIP配哪里、网关怎么走、报文从哪个口进出”这三个核心问题。很多配置事故都是这三张表没想清楚随手敲了IP导致的。3. 从Director到RS的完整部署过程3.1 环境清单与假设拓扑为了让步骤具备可复现性我先说明这次部署的假设环境Director一台双网卡Linux服务器两个网卡分别接入两个网段系统为Ubuntu Server或CentOS均可本次以CentOS 7/RHEL系列命令为例。RS4台Linux服务器分别位于网段A和网段B每台RS上运行Nginx作为后端服务。两台交换机网段A和网段B各自二层隔离Director的两个网卡分别接入对应交换机。客户端来自外网访问业务A使用10.10.1.100访问业务B使用10.10.2.100。整体逻辑是每个业务网段内的RS通过VIP对外呈现Director针对每个VIP各创建一套IPVS调度规则报文到达Director对应网卡后直接改写MAC经交换机二层转发给同网段内的RS。3.2 Director端配置网卡、VIP、调度规则和路由Director端的配置分为四步。第一步是确认两个网卡都正确识别IP已经配置好。建议用以下命令检查ip addr show eth0 ip addr show eth1 ping -c 2 10.10.1.11 # 确认与RS-A网络连通 ping -c 2 10.10.2.21 # 确认与RS-B网络连通第二步把两个VIP分别绑定到对应网卡上。注意VIP的掩码必须是32位这样它不会产生网段路由也就不会干扰本机其他网卡的路由判断ip addr add 10.10.1.100/32 dev eth0 ip addr add 10.10.2.100/32 dev eth1第三步开启IP转发。虽然DR模式本身不需要Director做三层转发但在多网卡环境下开启转发能让Director在向RS转发报文时更安全地处理路由查找也方便后续扩展其他功能echo 1 /proc/sys/net/ipv4/ip_forward第四步配置IPVS调度规则。这里有个多网段部署的关键细节一台Director上多组VIP要分别添加虚拟服务和RSRS必须使用-g参数Gatewaying也就是DR模式。权重可以根据后端机器配置来定比如两台同样规格的RS权重相同如果有差异则按处理器核数和带宽折算# 业务A的IPVS规则 ipvsadm -A -t 10.10.1.100:80 -s wrr ipvsadm -a -t 10.10.1.100:80 -r 10.10.1.11:80 -g -w 100 ipvsadm -a -t 10.10.1.100:80 -r 10.10.1.12:80 -g -w 100 # 业务B的IPVS规则 ipvsadm -A -t 10.10.2.100:80 -s wrr ipvsadm -a -t 10.10.2.100:80 -r 10.10.2.21:80 -g -w 100 ipvsadm -a -t 10.10.2.100:80 -r 10.10.2.22:80 -g -w 100配置完用ipvsadm -L -n查看能看到两个虚拟服务各自挂着两个RS转发方式都是Route即DR模式。还有一个容易被忽略的点Director到RS的报文虽然目标IP是RS的物理IP但Director在查找路由时会优先找与目标IP直连的接口。因为RS-A在eth0网段、RS-B在eth1网段默认路由表就能正确处理不用额外加静态路由。但如果你的RS和Director之间还隔着三层设备那就必须显式加一条到对应网段的路由指向正确的接口或下一跳否则报文会走错口。3.3 RS端配置lo与ARP抑制参数RS端的配置是整个DR多网段方案里最核心、也最容易出错的部分。总体分两步。第一步把VIP绑定到lo接口。很多网上的教程喜欢写lo:0但我更推荐直接绑定到lo上这样后续管理脚本更统一ip addr add 10.10.1.100/32 dev lo然后必须设置ARP抑制参数否则多个RS同时宣告VIP会引发ARP风暴。以RS-A1为例需要把arp_ignore和arp_announce这两个内核参数调整到合理的值。关键是注意不仅要设置all还要把default和lo也一并设置只改all在某些内核版本上不会对所有接口生效这算是个隐藏坑cat /etc/sysctl.conf EOF net.ipv4.conf.all.arp_ignore 1 net.ipv4.conf.all.arp_announce 2 net.ipv4.conf.default.arp_ignore 1 net.ipv4.conf.default.arp_announce 2 net.ipv4.conf.lo.arp_ignore 1 net.ipv4.conf.lo.arp_announce 2 EOF sysctl -p解释一下这两个参数的作用arp_ignore1代表只回答目标IP是本接口IP的ARP请求不会替其他接口上的IP回应arp_announce2代表ARP请求中的源IP始终使用发送网卡上的主IP而不是lo上的VIP。配合使用后RS的物理网卡对外宣告的是自己的物理IPVIP不会被宣告出去外部请求也就只会把报文送到Director再由Director转发给RS。第二步检查RS的默认路由是否正常。RS回包给客户端时源IP是VIP但出接口是物理网卡默认路由必须指向自己网段的网关。如果RS上不小心加了一条以VIP为源的路由规则回包就可能走错路径。检查命令ip route show # 确认存在默认路由 # 对于RS-A默认路由应该是 default via 10.10.1.254 dev eth0四台RS按同样的方式配置区别只在于VIP地址与默认网关不同。3.4 配置完成后第一轮验证判断DR模式是否真正生效配置不是敲完就结束必须验证链路每一步都对了。我的验证顺序是第一步Director上确认IPVS规则和连接状态ipvsadm -L -n --stats看到每个RS的ActiveConn或InActConn有数字增长说明调度器在正常工作。第二步在RS上用tcpdump抓包看转发后的报文。这是判断DR是否生效最直接的办法。在RS-A1上执行tcpdump -i eth0 host 10.10.1.100 -nn从客户端请求业务A的VIP在RS-A1上应该能抓到目标IP是10.10.1.100、目标MAC是Director的eth0 MAC地址的HTTP请求报文。如果目标MAC是RS自己的MAC说明请求不是Director转发过来的而是直接到了RS那很可能VIP被RS宣告出去了ARP抑制没生效。第三步在客户端侧确认回程不经过Director。可以在Director上用tcpdump -i eth0 tcp port 80抓包正常情况下只看到SYN和少量ACK大流量响应应该直接绕过Director。如果Director上抓到大量响应包说明RS回包走了Director路由或反向路径有了问题。做完这三步一套正常的多网段DR链路就基本宣告打通了。4. 多网段部署中容易翻车的三个典型故障4.1 故障一VIP写在物理网卡上多网段ARP抢答这次部署里第一轮测试时就出现了诡异现象访问10.10.1.100有时能通有时立刻超时偶尔还会跳到网段B的某个RS上响应内容都是错的。查了很久最后在交换机上tcpdump发现VLAN A和VLAN B里同时有设备在回ARP请求目标IP就是10.10.1.100。原因很快定位我在给RS-B配置时图省事把10.10.1.100这个VIP也写到了RS-B1的eth0上而没有用lo。由于网段B的RS物理网卡在二层也能收到广播报文它就响应了网段A的ARP请求导致AB两个网段里同时存在“VIP的应答者”交换机的MAC表直接崩了。修复方法是把所有RS的VIP全部移到lo接口只保留主IP在物理网卡上然后重启网络或重新加载sysctl让ARP抑制参数生效。这之后现象立刻消失。这个故障给多网段部署提了个醒VIP管理必须集中统一不要跨网段复用也不要随手绑在物理网卡上。每个网段的VIP像“户口”一样只能落在本网段RS的lo上。4.2 故障二RS回包绕路连接建立后几秒钟就断另一个坑出现在验证阶段客户端访问VIP能建立TCP连接但传输数据到一半就卡死超时后连接被重置。在RS上抓包能看到请求进来了应用也处理了但回包发出后客户端一直没收到。用traceroute从RS追踪回程路径发现回包居然先经过默认网关10.10.2.254再绕到网段A的网关最终才回到客户端。原因是RS-B那台机器的/etc/hosts和路由表里被人为加了一条“到10.10.1.100走10.10.2.1”的静态路由导致回包没有走正确的默认路由。本质上是回程路径被“带偏”了而DR模式的回程路径完全由RS本机的路由表决定Director管不了。解决方法是把RS上所有业务网段无关的静态路由清理干净只保留一条默认路由并在路由表里明确VIP的源路由不使用特殊策略ip rule show ip route show table all确认没有任何针对VIP的异常路由策略后把多余路由删除连接立刻恢复正常。这之后我养成了一个习惯所有RS只装必要软件路由表保持最简越乱的路由表在多网段DR里越容易出诡异故障。4.3 故障三Director报文从错误网卡发出RS侧根本收不到第三个问题发生在扩充网段B的RS时。新增的RS-B2在网段B里和Director的eth1同网段但接入后一直没流量。在RS-B2上抓包连ARP广播都看不到。排查后发现Director在转发到10.10.2.22的报文时主路由表认为这个IP应该走eth0因为eth0有一个更具体的路由条目导致报文从错误网卡发出根本到达不了网段B的二层。实际上eth1才是连接网段B的物理接口需要手动加一条精确路由强制指向eth1ip route add 10.10.2.22/32 dev eth1稍作验证流量立刻恢复正常。这个问题的根源在于多网卡机器的路由判定Linux会按照最长前缀匹配选择路由在主路由表中如果出现了不精确的历史路由就会抢走正确路径。解决方法是把Director上所有非必要的静态路由清理干净并为每个业务网段的RS段加上精确的直连接口路由ip route add 10.10.1.0/24 dev eth0 src 10.10.1.10 ip route add 10.10.2.0/24 dev eth1 src 10.10.2.10同时建议把这些路由写入启动脚本或network-scripts配置避免重启后丢失。5. 多网段DR的日常运维健康检查、高可用与扩展方向5.1 轻量级健康检查脚本端口探测加自动摘除DR模式里Director不会自动感知后端RS的存活状态。业务量小的时候可以手动管理但规模一大就必须上健康检查。我用过最轻量的方法是shell脚本加ipvsadm实现思路是周期性探测各RS的对应端口探测失败超过阈值就把RS从IPVS规则里摘除恢复后再添加回来。以业务A的两台RS为例脚本核心逻辑如下#!/bin/bash VIP10.10.1.100 RS110.10.1.11 RS210.10.1.12 PORTS(80) for RS in $RS1 $RS2; do if nc -z -w 2 $RS ${PORTS[0]} /dev/null 21; then ipvsadm -a -t $VIP:${PORTS[0]} -r $RS:${PORTS[0]} -g -w 100 2/dev/null || true else ipvsadm -d -t $VIP:${PORTS[0]} -r $RS:${PORTS[0]} 2/dev/null || true fi done注意ipvsadm -a在RS已存在时会报错所以加了|| true避免脚本因错误退出同理-d删除不存在的RS也会报错也要容错。脚本放在crontab里每分钟跑一次实际运行下来很稳。如果要更精细的判断例如检测应用层响应而不只是端口存活可以用curl检查特定URL但这需要后台服务配合返回探测路径建议按业务情况定制。5.2 keepalived做主备高可用多VIP时vrrp_instance必须隔离单台Director挂了整个业务的入口就没了。多网段部署一般都会配双Director做主备。用Keepalived做VRRP时有一个关键点不同网段的VIP不能放在同一个vrrp_instance里哪怕你认为“反正主备逻辑一样放一起省事”。因为不同VIP对应不同网卡和不同网段VRRP通告报文必须在各自网段的二层网络里发送放在同一个实例里会导致保护组逻辑混乱主备切换的时候网络判断会受影响。标准做法是每个网段一个vrrp_instance每个实例绑定自己的网卡和VIP。以业务A的VIP为例配置片段大致如下vrrp_instance VI_A { state BACKUP interface eth0 virtual_router_id 51 priority 150 nopreempt virtual_ipaddress { 10.10.1.100/32 dev eth0 } }业务B对应的实例使用interface eth1、不同的virtual_router_id和不同的virtual_ipaddress。主备两台Director的配置除了state和priority不同其余保持一致。这样任何一个网段的网络异常只影响该网段的VIP不至于全网入口一起抖动。5.3 往其他网段扩展时哪些东西必须重新评估多网段DR的扩展不像NAT模式“拉一根线就能接入”每新增一个网段都要重新评估三层要素二层边界是否清晰新增网段的交换机是否和Director的对应网卡处于同一广播域有没有VLAN隔离、端口隔离之类的策略。DR要求二层可达这个前提一旦不满足整个方案推倒重来。VIP地址是否重复新网段的VIP不能和其他既有网段共用同一个IP建议在总IP规划表里全局排重避免出现地址冲突。Director是否有空闲网卡如果新增网段的物理接口不够用可以考虑在交换机上做VLAN子接口用Linux的vlan子接口接入多个网段但要确保各子接口的ARP抑制和路由规则也一并适配。健康检查脚本是否需要扩展不同的业务可能对应不同的VIP和端口脚本要支持循环遍历多组VIP而不是为每组VIP单独写一份脚本否则维护成本会失控。我在项目中新增第三个网段时只花了半天就完成因为规划表的框架是现成的只是往表里补了一行。真正耗时的是确认新网段的二层隔离策略——部分交换机默认开启了动态ARP检测或端口安全这些特性会拦截DR模式依赖的“目标MAC为Director、目标IP为VIP”的转发报文必须在交换机上提前放行。最后再说一点个人体会多网段DR部署80%的困难发生在规划阶段而不是敲命令的阶段。把二层广播域的边界画清楚、把VIP归属定准、把每台RS的默认路由约束好后面所有步骤都是机械操作。反过来如果这些前置条件没想透配置过程中就会出现ARP抢答、回包绕路、报文发错网卡这类靠“试错调参”很难处理的故障。换句话说DR模式本身并不复杂复杂的是你对网络路径的理解有没有跟上它的设计思路。