作为做了好几年负载均衡和集群运维的人我前后在不同的业务环境里折腾过不少次LVS-DR模式的部署。第一次配置的时候确实被ARP那套机制搞得头大VIP来回漂移、real server反复丢包、回包路径错乱这些坑基本都踩了一遍。LVS-DR模式在生产环境用得相当广泛很多高并发业务的前端入口就是靠它扛住的。这篇内容我打算直接把LVS-DR模式配置这件事从头到尾拆开讲包括方案选型、原理、具体配置步骤、以及我实际排障过程中沉淀下来的经验希望能帮你在部署的时候少走弯路。1. LVS-DR模式配置前的基本认知1.1 为什么生产环境普遍选LVS-DR做负载均衡方案选型的时候常见的无非是Nginx、HAProxy、LVS这几类。Nginx和HAProxy工作在七层或四层性能瓶颈受限于进程模型和CPU核心数扛高并发时单机承受能力有限。而LVS工作在内核态直接挂在netfilter框架上转发效率非常高特别适合用来做入口流量分发。LVS本身支持NAT、DR、Tunnel三种模式。NAT模式配置相对简单但进出流量都经过director比较容易成为瓶颈。Tunnel模式要封装IP包对网络环境要求高日常用得不多。DR模式的核心思路是让director只负责入站请求的分发real server直接把响应包回给客户端这样回程流量根本不经过director从架构上避开了NAT模式的转发压力。正因为这个特性DR模式成了高并发场景下的主流选择。当然LVS-DR模式配置也不是没有代价。它要求director和real server必须在同一个二层网络内VIP需要绑定在真实服务器的loopback口上还要做ARP抑制。这些配置动作本身不难关键是理解背后的网络通信逻辑否则出了问题很难定位。1.2 理解DR模式转发流程中的关键角色先说清楚DR模式里几个名词。Director是负载均衡器VIP是提供给客户端访问的虚拟IPRIP是后端真实服务器的IPDIP是director与后端通信用的IP。客户端请求到达director的VIP后director会根据调度算法挑选一台real server然后通过改写数据帧的目标MAC地址把请求转发给对应的RS。因为源和目标IP没有变化RS处理完请求后可以直接把响应包发送给客户端不再绕回director。这里有个关键点RS必须配置VIP在自己的loopback口上才能正常接收和响应目标地址为VIP的请求。如果不做ARP抑制RS会认为自己是VIP的拥有者网络中会出现多台机器都回应VIP的ARP请求流量就直接打到某台RS上去了负载均衡的效果就全乱了。所以LVS-DR模式配置的核心往往是ARP策略的调优而不是IPVS规则的堆砌。提示刚接触DR模式的人容易忽略“回包不经过Director”这个特性导致排查问题时思路完全走偏。记住一个原则DR模式下真正的流量瓶颈转移到了RS侧和交换机链路而Director只处理入站请求压力远比你想象的小。2. 网络规划与参数取舍2.1 设计LVS-DR模式的网络拓扑与VIP分配动手配置前先把网络拓扑规划好这一步偷懒后面全得还债。DR模式要求director和所有real server在同一个物理二层广播域里通常就是同一台交换机下或同一个VLAN内。我见过有人把RS放到不同的网段结果LVS转发过去根本没有响应折腾了半天才发现二层不通。VIP的划分有个细节值得注意。VIP和RIP、DIP不一定非要同一个网段但建议放在同一个网段来省心。多数场景下VIP会选用业务对外提供服务的IP比如公网入口IP或网关的浮动IP。如果VIP是公网地址RS的loopback上绑定公网VIP会涉及安全策略和路由问题此时需要把公网VIP映射成内部routing别名来处理。规划时我把参与节点分为三类。第一类是director节点至少两台生产环境必须做双机热备通常结合keepalived来实现VIP漂移。第二类是RS节点一台到几十台不等按业务量评估。第三类是网络设备主要是交换机上的ARP表项和端口配置有些交换机开启了端口安全或MAC漂移检测可能导致director在切换VIP时被交换机丢弃报文这是很多隐性故障的来源。2.2 RS端网络参数改动的必要性前面说了DR模式要求RS在自己的loopback接口上绑定VIP同时抑制对外ARP响应。这里牵扯到Linux内核参数arp_ignore和arp_announce。这两个参数分别控制“是否忽略外部对本机地址的ARP请求”和“发送ARP响应时如何选择源地址”。简单理解就是当外部设备问“谁是VIP”时如果RS没有正确配置arp_ignore它会抢着回答“我是VIP”导致客户端或交换机直接把请求发给了某台RSdirector反而收不到流量。arp_announce则管控RS用哪个IP去回应ARP请求配置不当会让交换机学习到错误的MAC地址产生回包异常。这两个参数在不同的内核版本上默认值不太一样。我曾经在处理某个新版内核服务器时以为默认参数就足够抑制ARP结果测试时VIP一会儿在A机器上响应一会儿又在B机器上响应实际上是默认值变了导致的。所以每次安装完系统都要主动检查参数不要依赖默认值。注意修改arp_ignore和arp_announce是全局内核参数会影响所有网络接口。如果这台机器上还跑着其他业务并依赖正常ARP响应就要特别注意或者用接口级别规则做细粒度控制。3. LVS-DR模式配置实操过程3.1 环境准备与IPVS管理工具安装开始配置之前先确认操作系统环境。我以常见的企业级Linux发行版为例使用ipvsadm作为管理工具使用keepalived作为高可用组件。centOS/RHEL系列安装命令如下yum install -y ipvsadm keepalived如果是Ubuntu/Debian系列则使用apt-get install -y ipvsadm keepalived有些精简版系统默认没有加载IPVS相关内核模块使用ipvsadm前需要确认。我遇到过几次安装完ipvsadm后执行命令提示“cant initialize ipvs: No such file or directory”基本都是内核模块没加载导致的。可以运行modprobe ip_vs确认生产环境建议把需要的调度器模块也一起加载比如ip_vs_rr、ip_vs_wrr、ip_vs_sh等。内核模块加载完毕执行以下命令验证ipvsadm -L -n如果清楚列出一张空列表说明IPVS模块运行正常接下来就可以正式开始配置。3.2 Director端的IPVS规则配置假设我们规划如下网络参数角色IP地址说明Director(DIP)192.168.1.10负载均衡器内网IPVIP192.168.1.100业务虚拟IPRealServer1(RIP)192.168.1.11后端业务机RealServer2(RIP)192.168.1.12后端业务机先给Director配置VIPip addr add 192.168.1.100/32 dev eth0这里使用/32掩码比较常见也有用/24的。使用/32可以让VIP在本地作为一个独立地址存在避免广播行为干扰。实际部署中如果director和RS的VIP配置成非/32有时会触发额外的ARP通告让交换机学到错误端口所以建议大家统一使用/32。接下来配置IPVS规则ipvsadm -A -t 192.168.1.100:80 -s rr ipvsadm -a -t 192.168.1.100:80 -r 192.168.1.11:80 -g ipvsadm -a -t 192.168.1.100:80 -r 192.168.1.12:80 -g第一条命令创建一个虚拟服务器规则使用轮询调度算法。第二条和第三条分别添加两台RS并指定使用-g也就是DR模式的direct routing转发方式。这里-r后面的端口要和RS实际服务端口一致如果RS的web服务跑在8080而VIP对外暴露80需要在RS本地做DNAT或用iptables规则把目标端口改掉。确认配置结果ipvsadm -L -n输出如下信息IP Virtual Server version 1.2.1 Prot LocalAddress:Port Scheduler Flags - RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 192.168.1.100:80 rr - 192.168.1.11:80 Route 1 0 0 - 192.168.1.12:80 Route 1 0 0从输出可以看到转发方式为Route正是DR模式。3.3 real server端的loopback口配置与ARP抑制RS端的核心动作有两个一是把VIP绑定到lo接口的别名上二是修改ARP内核参数。绑定lo别名执行ip addr add 192.168.1.100/32 dev lo这里有一个很多人容易踩的坑RS所有节点都配置了同一个VIP地址初次接触DR模式的人会觉得IP冲突了。实际上正是因为DR模式的特殊设计所有RS都必须配置VIP但这个VIP只用来接收和响应请求并不会引起真正的地址冲突前提是ARP抑制做好。如果不做ARP抑制IP地址冲突就会变成真实问题。接下来修改ARP参数编辑/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然后执行sysctl -p使参数生效。生产环境中建议还要考虑所有网卡接口比如eth0、eth1等可以把all和特定接口都设置一遍避免某个接口漏掉导致ARP异常响应。这些参数的具体含义再次强调一下。arp_ignore设置为1表示只回答目标IP是本接口IP的ARP请求。因为RS上绑定了VIP在lo口外部请求VIP的ARP时如果lo被设置成忽略外来ARP请求RS就不会响应这个VIP的ARP。arp_announce设置为2表示始终使用最佳本地IP地址来回应ARP请求避免使用VIP地址来响应其他网段的ARP查询。捞干的说设置了这两个参数后RS只会在收到的报文目标IP确实是自己的VIP时才在本地处理但不会主动对外广播自己是VIP。Client或交换机询问VIP的MAC地址时只会收到director的响应这就保证了客户端请求能准确到达director。3.4 用脚本固化LVS-DR配置实现重启生效手工执行的配置在机器重启后会全部丢失生产环境的部署一定脱离不了脚本化。我在实践中通常将以上配置写进启动脚本放到/etc/init.d/或systemd的unit中也可以直接写成rc.local里的一段逻辑。一个基本的配置脚本长这样#!/bin/bash # Director配置脚本 VIP192.168.1.100 RIP1192.168.1.11 RIP2192.168.1.12 ip addr add $VIP/32 dev eth0 ipvsadm -C ipvsadm -A -t $VIP:80 -s rr ipvsadm -a -t $VIP:80 -r $RIP1:80 -g ipvsadm -a -t $VIP:80 -r $RIP2:80 -g对应的RS启动脚本#!/bin/bash # RealServer配置脚本 VIP192.168.1.100 ip addr add $VIP/32 dev lo sysctl -w net.ipv4.conf.all.arp_ignore1 sysctl -w net.ipv4.conf.all.arp_announce2 sysctl -w net.ipv4.conf.lo.arp_ignore1 sysctl -w net.ipv4.conf.lo.arp_announce2写进rc.local时注意执行权限并确认rc.local在大版本系统上默认是否启用。systemd系统下建议写一个简单的service文件指定ExecStart执行脚本这样能够统一管理启停顺序。这里有个细节RS的loopback上VIP不建议让它在系统启动阶段自动执行而是要等到网络就绪后再做否则有可能因为网络初始化未完成导致绑定失败。systemd的多用户模式下执行比较合适。4. 常见问题与排查技巧实录4.1 VIP在director上却不响应请求这是配置完最容易遇到的故障。执行ipvsadm -L -n看规则都在VIP也已经在director的eth0上可客户端请求就是不通。遇到这个情况先不要怀疑IPVS规则先在director本机执行curl访问VIP试试。如果本机可以通说明director本身没问题问题大概率出在ARP或RS端。如果本机不通检查防火墙。很多发行版默认开启了firewalld或iptables入站流量到了INPUT链就被丢掉了IPVS处理流量是在更早的hook点但本机访问VIP时会走本地回环路径同样受防火墙影响。再有一种情况是director的两块网卡都配置了VIP导致路由选择混乱。我调试时常用ip route get 192.168.1.100来看本地路由表选路发现流量有概率走了错误的出口网卡。每个网卡配置明确的IP段范围尤其在多网卡环境中这是LVS-DR模式配置时需要额外注意的事情。4.2 部分请求直接到达RS导致负载不均衡典型现象用压测工具打流量发现某台RS的CPU占用率特别高而其他RS很空闲。抓包时能看到director和目标RS之间发生了ARP交互而正常情况下客户端应只请求director的ARP。这个现象几乎可以断定是ARP抑制没生效。检查RS上sysctl的参数是否真正应用有时候改完/etc/sysctl.conf后忘记执行sysctl -p参数还是旧的。也有的情况是参数all.*设置了但具体接口单独覆盖导致生效不了比如eth0上显式设置过arp_ignore为0即使all为1eth0还是会用自己的值。另外确认RS上是否还启用了NetworkManager这类网络管理服务。有些版本里NetworkManager会在接口重启时重置sysctl配置或路由规则导致你手工配置的VIP和ARP参数丢失。生产环境用RS节点建议关闭或配置NetworkManager的托管策略尽量用传统的network.service来管理。4.3 直连路由与VIP网段冲突问题如果RS上有多个网卡或配置了多条路由很可能出现数据包从错误接口发出。DR模式下RS收到请求后根据目标IP即客户端的IP查询本地路由表并发回响应。一旦RS上存在默认路由指向另一个网段而客户端地址又被路由到该接口响应包就发错地方了。调试RS上网卡和路由配置时我一般会先做一次简化操作只保留一个默认路由确保流向客户端的包从绑定VIP的网卡出去。对于多网卡服务器如果业务必须使用多个网络接口可以在路由表中添加精确路由来指定到业务网段的下一跳。还有一个很隐蔽的问题RS的loopback上绑定了VIP后某些软件会使用VIP作为源地址发起连接导致源地址变成了VIP而不是RS的真实IP。这会让客户端或后端服务记录到错误的来源还会影响安全策略。遇到这种情况需要单独设置路由规则让RS出站的流量强制使用RIP作为源地址。4.4 keepalived双机热备带来的VIP漂移问题生产环境不可能只用一台director它挂了整个业务入口就断了。我通常用keepalived结合LVS-DR模式配置来实现双机热备。keepalived通过VRRP协议在多个director之间监控和漂移VIP。正常情况下master上的VIP会响应ARPbackup节点处于Standby状态一旦master挂了backup会接管VIP并主动发送免费ARP通知交换机更新MAC表。这个机制本身很成熟但实际运行中有个坑容易忽略交换机上的MAC地址老化时间。如果交换机的MAC学习时间比较长VIP漂移后交换机可能还保留旧的MAC地址表项新的ARP请求到了交换机却被转发到旧的端口导致业务短暂中断。预防手段是在配置keepalived的优先级和检测脚本时调低切换延迟同时适当缩短交换机MAC地址表老化时间。keepalived里需要配置vrrp_instance、vrrp_script、virtual_ipaddress、virtual_server等字段与此同时ipvsadm的规则最好通过keepalived的virtual_server块来定义而不是手动命令行配置。这样当keepalived切换时IPVS规则能够自动加载到新的master上。注意keepalived和ipvsadm同时存在时避免手动修改ipvs规则。keepalived检测到配置变化会强制刷新规则手动添加的规则可能被清掉。统一以keepalived的配置文件管理RS和调度算法是更稳妥的做法。5. 从配置到底层原理的深度复盘5.1 请求与响应链路的一次完整数据流追溯配置完成后我习惯用抓包来确认整个数据链路确实符合预期。在director上执行tcpdump截获客户端访问VIP的流量命令如下tcpdump -i eth0 host 192.168.1.100 and port 80观察首包源IP是客户端目标IP是VIP目标MAC是director的MAC这说明ARP解析正常。随后director通过IPVS改写目标MAC把包转发给RS的MAC地址。这里要注意源IP始终是客户端的IP目的IP也始终是VIP只有MAC被修改了。在RS上抓包能看到进包的目标MAC是RS的MAC目标IP依然是VIP于是RS本地的lo口绑定VIP就派上了用场内核正常收包处理。响应包从RS发出时源IP是VIP目标IP是客户端的IP源MAC是RS的MAC。因为RS设置了arp_announce2发出响应不会造成ARP广播异常客户端收到响应后只知道是和VIP对话完全不知道director的存在。这整条链路验证下来DR模式的高效性就一目了然director只做了二层转发和调度几乎不占用CPU来分析包内容响应路径更是不参与所以单台director的能力上限比NAT模式高出很多倍。5.2 调度算法选择对业务的影响LVS-DR模式配置的另一个重要环节是选择调度算法。默认的rr轮询是平均分配请求到每台RS适合后端处理能力一致的集群。wrr加权轮询则适合RS性能有差异的场景权重高的RS分配更多请求。lc最少连接算法会将新请求发给当前连接数最少的节点这个在长连接类型的业务比如WebSocket、数据库代理场景中更适用。我之前有两组RS节点配置差别比较大第一组是双路CPU、大内存第二组是普通虚拟机。同时接入流量后如果使用rr算法第二组节点明显压力更大响应时间恶化。改成wrr并给第一组设高权重后整体吞吐量提升近半。这个细节说明LVS-DR模式配置绝不是把IPVS规则写上去就行调度策略直接决定集群资源的利用水平。会话保持也是不得不提的问题。LVS默认不保存客户端与后端节点的绑定关系如果业务依赖session需要开启持久连接功能。ipvsadm支持在虚拟服务上设置超时时间命令如下ipvsadm -A -t 192.168.1.100:80 -s rr -p 600-p 600表示客户端在600秒内发起的请求都会被调度到同一台RS上。这个配置非常简单但能解决大量的登录状态掉线问题。要注意持久连接会降低负载均衡效果因为同一IP的所有请求始终落在同一节点所以需要根据用户的来源分布做权衡。5.3 健康检查与故障摘除机制LVS本身不提供内置健康检查IPVS规则只会按算法把包转发给RS哪怕RS上的nginx进程已经挂掉它依然会把请求转过去最终客户端得到一个502或连接超时。生产环境一般借助keepalived来弥补。keepalived可以配置一个HTTP GET健康检查定期请求RS上的健康检查路径比如/health.html。如果连续几个周期返回非200状态码keepalived会把这台RS从IPVS规则中摘除等恢复后再自动加回来。这样一来后端即使发生进程崩溃前端服务依然正常。实际配置中健康检查路径要选一个访问频率极低的接口同时保证该接口能够真实反映业务进程状态不要只检查到nginx进程存活却忽略了后端数据库连接池异常这种更隐蔽的问题。我遇到过一次比较特殊的故障某台RS的web进程假死端口还处于监听状态但实际处理能力已经下降到极低。默认TCP健康检查完全无法发现这个问题客户端延迟飙升。后来我改成HTTP健康检查并设置较短的超时时间才做到及时摘除故障节点。6. LVS-DR模式配置的性能调优与扩展建议6.1 内核网络参数优化应用刚上线时性能还算正常流量增大后出现TCP连接建立慢、丢弃等问题多数情况下不是LVS本身不行而是内核网络参数没有做相应调整。director面对大量并发新建连接时需要及时回收TIME_WAIT状态的socket可以通过调整以下参数来优化net.ipv4.tcp_tw_reuse 1 net.ipv4.tcp_fin_timeout 30 net.ipv4.ip_local_port_range 1024 65535RS端也要考虑并发连接的文件描述符限制适当调高进程的nofile参数。遇到SYN Flood攻击或瞬间高并发可以把net.core.somaxconn调大同时设置半连接队列长度避免握手包在队列溢出时被直接丢弃。不过要注意tcp_tw_reuse要求连接使用了时间戳选项才能生效部分旧客户端不支持时效果会打折扣。这类优化参数需要结合业务流量模型小步调整不要照搬网上的“嫂子配置”否则可能触发更复杂的副作用。提示网络参数的调整建议先在压测环境验证。把流量打到正常值的2到3倍观察director的CPU、内存、丢包率和TCP重传率再逐步调整应用到生产。6.2 横向扩展与异构后端接入LVS-DR模式很容易横向扩容。新增一台RS时只需在director添加一条ipvsadm规则再在RS上完成VIP绑定和ARP抑制即可无缝接入流量。整个操作可以在业务高峰期执行而不中断现有服务这也是对比其他负载均衡方案的一大优势。如果后端服务不仅限于HTTP比如需要负载均衡MySQL协议、Redis协议或自定义TCP协议LVS也能搞定只需要修改端口号即可。我用LVS转发过MySQL流量注意的一点是MySQL主从复制要求固定的源IP而LVS会保留源IP因为DR模式只改MAC不改IP所以这一点比NAT模式有天然优势。对于HTTPS流量LVS不做SSL卸载只是透明转发加密流量到RSRS需要自己处理证书和加解密。这样反而省掉了证书统一管理的复杂度也让每一台RS的能力都能被充分利用。6.3 与云环境的适配经验如今不少企业把业务放到了云上。传统数据中心里LVS-DR模式配置起来得心应手但云环境里有一道坎多数云平台的VPC网络不支持自定义二层协议组播也被限制广播域被隔离LVS-DR模式部署会碰到很多限制。有些云平台提供私网负载均衡服务直接使用SLB往往更合适。如果一定要在云主机上采用DR模式需要看云平台是否支持配置“弹性网卡主辅IP”或者“VIP白名单”有些云平台可以在安全组层面做放行但ARP抑制和VIP绑定的方式仍然和物理机有差异。我的建议是如果云平台本身提供了LB能力优先使用云LB将精力放在RS节点的健康检查和弹性伸缩上而不是硬啃LVS。云LB在高可用、安全组编排和监控告警方面远比自建方案省心。当然在物理机自建机房、IDC托管或者网络环境完全可控的私有云中LVS-DR模式依然是性价比极高的选择。7. 我的几点实操体会用了这么久的LVS-DR模式配置我最大的体会是把原理吃透再动手远比照着教程敲命令重要。很多人配置失败都失败在不懂ARP不理解为什么所有RS都要绑定VIP又不让RS响应ARP。一旦把这个逻辑理清再回头看IPVS配置和内核参数就都是顺理成章的事情了。第二个体会是生产环境一定要把配置脚本化和版本化。手工命令行配置适合实验不适合生产。我会把director和RS的初始化脚本放到配置管理仓库里统一管理每次变更都走评审。这样即使节点重装也能在几分钟内恢复整个集群的能力。最后再分享一个小经验上线后一定要做常态化巡检。LVS规则的状态、VIP的归属、ARP参数是否被篡改、RS的健康状态这些数据最好接入监控系统。我经历过几次半夜流量异常靠的就是监控平台上IPVS连接数的突增告警才提前发现问题的。LVS-DR模式配置完只是开始真正的功夫在后续的运维保障里。