企业级LVS负载均衡实战：架构选型、高可用部署与性能调优

1. 企业级流量入口的架构选型思考1.1 为什么负载均衡是绕不开的第一道坎做后端架构这些年我越来越觉得负载均衡是整个系统里最容易被低估、却又最不能出错的一环。业务代码写崩了大不了回滚一个版本数据库慢查询了加个索引还能救但负载均衡这一层要是出了问题那就是整个服务入口直接瘫痪所有下游节点全部失联用户端看到的就是白屏或者502。这种故障的杀伤力跟单点服务挂掉完全不是一个量级。LVSLinux Virtual Server在国内互联网公司的普及率非常高尤其是那些日活千万级以上的业务几乎都能看到它的身影。原因很直接它是基于内核态的四层转发性能损耗极低单台机器扛几十万并发连接是常规操作。相比Nginx这种七层代理LVS不解析应用层协议只做IP和端口的转发决策所以它的吞吐能力要高出好几个数量级。当然代价就是功能相对朴素不能做URL路由、不能改Header、不能做SSL卸载这些活儿得交给后端的七层代理或者应用本身去处理。这篇文章我想聊的是怎么把LVS真正用起来不是那种装个ipvsadm敲两条命令就完事的玩具级演示而是企业环境里需要考虑高可用、会话保持、健康检查、内核调优、故障切换的完整方案。适合已经有一定Linux基础、正在搭建或者优化自己服务入口的运维和后端同学。如果你还在用单台Nginx扛所有流量或者对四层和七层的区别只有模糊概念那这篇内容应该能帮你把思路理清楚。1.2 四层和七层到底差在哪里很多人一开始会纠结既然Nginx也能做负载均衡为什么还要多引入一层LVS这个问题我在不同团队里被问过不下十次。核心答案就一个字性能。但这个性能背后涉及的东西值得展开说。四层负载均衡工作在传输层它只看数据包的源IP、目标IP、源端口、目标端口然后根据调度算法决定把这个包转发给哪台后端服务器。整个过程在内核空间完成不需要把数据从内核态拷贝到用户态也不需要建立完整的TCP连接再转发。你可以把它想象成一个非常聪明的邮局分拣员只看信封上的地址就把信扔到对应的邮筒里根本不拆开看里面写了什么。七层负载均衡则工作在应用层它需要先和客户端建立完整的TCP连接然后解析HTTP请求根据URL、Header、Cookie等信息做转发决策。这个过程涉及大量的用户态和内核态之间的数据拷贝还要维护连接状态所以单机性能天花板要低得多。但它的优势在于灵活能做基于路径的路由、能做灰度发布、能改写请求内容。企业里的常见做法是两者配合LVS在最前面做四层转发把流量分给一组NginxNginx再做七层处理转发给真正的应用服务器。这样LVS扛住了海量连接和DDoS攻击的第一波冲击Nginx专注于业务层的灵活路由。这个架构在电商大促、直播活动这种流量尖峰场景下特别管用。1.3 三种转发模式的取舍逻辑LVS支持三种主要的转发模式NAT、DRDirect Routing和TUNIP Tunneling。这三种模式的选择直接决定了你的网络拓扑和性能上限必须在一开始就想清楚。NAT模式最简单但性能最差。它的原理是LVS修改请求包的目标IP为后端服务器IP后端处理完再把响应包发回LVS由LVS改回源IP返回给客户端。问题在于所有响应流量都要经过LVSLVS成了瓶颈而且后端服务器需要把网关指向LVS。这种模式适合小规模场景比如后端只有几台机器、流量不大的内部系统。DR模式是生产环境用得最多的。它的巧妙之处在于LVS只修改请求包的MAC地址把包转发给后端后端处理完后直接把响应包发给客户端不经过LVS。这样LVS只处理入站流量出站流量由后端自己搞定吞吐能力大幅提升。代价是LVS和后端必须在同一个二层网络里而且后端服务器需要在回环接口上配置VIP并且抑制ARP响应否则会跟LVS抢VIP。TUN模式适合跨机房场景LVS把请求包封装在IP隧道里发给后端后端解封装后处理响应直接返回客户端。这种模式支持后端和LVS不在同一网段但需要后端支持IP隧道协议而且多了一层封装解封装的开销。我个人的经验是同机房内优先用DR跨机房考虑TUNNAT只在测试环境或者极简场景下用。下面这张表可以帮你快速对比对比维度NAT模式DR模式TUN模式性能低高中网络要求后端网关指向LVS同一二层网络支持IP隧道响应路径经过LVS直接返回客户端直接返回客户端端口映射支持不支持支持适用场景小规模测试同机房生产跨机房部署2. 核心组件与调度算法深度拆解2.1 ipvsadm与内核模块的配合机制LVS的核心其实分两部分内核里的IPVS模块和用户空间的ipvsadm工具。IPVS模块负责实际的数据包处理和转发决策ipvsadm则是我们用来配置和管理转发规则的工具。理解这个分工很重要因为很多配置了不生效的问题根源就在于内核模块没加载或者版本不匹配。在开始配置之前第一件事是确认内核是否支持IPVS。大部分主流发行版的内核都默认编译了IPVS模块但有些精简版或者定制内核可能没有。你可以用modprobe ipvs尝试加载然后用lsmod | grep ip_vs确认。如果加载失败可能需要重新编译内核或者安装对应的内核模块包。ipvsadm的配置逻辑围绕三个概念展开虚拟服务Virtual Service、真实服务器Real Server和调度算法。虚拟服务就是你对外暴露的VIP和端口真实服务器就是后端实际处理请求的节点。一条典型的配置命令长这样ipvsadm -A -t 192.168.1.100:80 -s wrr ipvsadm -a -t 192.168.1.100:80 -r 192.168.1.101:80 -g -w 100 ipvsadm -a -t 192.168.1.100:80 -r 192.168.1.102:80 -g -w 100第一行是添加虚拟服务-t指定TCP协议和VIP端口-s wrr指定加权轮询算法。后面两行是添加真实服务器-g表示DR模式-w是权重。这些命令看起来简单但每一条背后都有讲究比如权重怎么定、算法怎么选后面会详细说。2.2 调度算法的选择不是拍脑袋LVS提供了十几种调度算法但实际生产环境常用的就那么几种。选错了算法轻则负载不均重则某些后端被打爆而其他后端闲着。我把常用的几种列出来结合场景说说怎么选。轮询RR是最简单的请求依次分给每台后端。适合后端配置完全一致、处理能力相同的场景。但现实中很少有完全一致的机器所以纯轮询用得不多。加权轮询WRR在轮询基础上加了权重权重高的分到的请求多。这个权重需要根据后端的CPU、内存、带宽来定。我一般会先给一个初始权重然后观察一段时间的实际负载再调整。比如两台机器配置是8核16G和4核8G权重可以设成2:1但实际可能设成3:1更合适因为性能不是线性关系。最少连接LC把新请求分给当前连接数最少的后端。这个算法在请求处理时间差异大的场景下表现很好因为它能动态感知后端的忙闲程度。但有个坑如果某台后端因为慢查询导致连接堆积LC会暂时不再给它新请求等它慢慢消化这其实是好事。但如果所有后端都堆积了LC也救不了。加权最少连接WLC是LC的加权版本也是我实际用得最多的算法。它在连接数的基础上除以权重相当于认为权重高的机器能承受更多连接。公式是(active_conns * 256 inactive_conns) / weight值最小的后端获得新请求。这个算法在异构集群里表现很稳。源地址哈希SH根据客户端IP做哈希同一个IP的请求总是落到同一台后端。这个算法主要用于会话保持但有个明显缺陷如果大量客户端经过同一个NAT网关出来它们的源IP相同就会全部落到同一台后端导致负载严重倾斜。所以SH只适合客户端IP分散的场景。目标地址哈希DH根据目标IP做哈希主要用于后端是缓存服务器的场景保证同一份缓存数据总是落在同一台机器上。算法适用场景注意事项RR后端配置完全一致实际很少用WRR后端配置有差异权重需动态调整LC请求处理时间差异大动态感知忙闲WLC异构集群通用生产首选SH需要会话保持NAT场景慎用DH缓存服务器集群保证缓存命中2.3 会话保持的几种实现路径会话保持是负载均衡里绕不开的话题。用户登录后后续请求必须落到同一台后端否则session丢了就得重新登录。LVS本身是四层转发它不理解HTTP协议所以不能像Nginx那样基于Cookie做会话保持。但LVS提供了几种替代方案。第一种是前面提到的源地址哈希SH算法。配置简单但NAT场景下会出问题。而且如果后端某台机器挂了那部分用户的session就丢了需要重新登录。第二种是会话共享把session存到Redis或者数据库里后端无状态。这是最彻底的方案也是我推荐的做法。虽然引入了一个新的依赖但它解决了会话保持的根本问题后端可以随意扩缩容不用担心session丢失。第三种是在LVS后面加一层Nginx由Nginx基于Cookie做会话保持。这样LVS只管四层转发Nginx处理七层的会话逻辑。这个方案兼顾了性能和灵活性但架构复杂度增加了。第四种是持久连接模板LVS可以配置在一定时间内同一源IP的请求都转发到同一台后端。这个跟SH类似但可以设置超时时间。配置命令是ipvsadm -p 600表示600秒内的同一源IP请求都走同一后端。提示会话保持方案的选择取决于你的业务对session丢失的容忍度。金融类业务通常要求session绝对不丢那就必须用共享存储方案普通资讯类业务偶尔重新登录用户也能接受用SH或者持久连接模板就够了。3. 高可用架构与实操部署全流程3.1 KeepalivedLVS的双机热备方案单台LVS本身就是单点它挂了整个服务就没了。所以生产环境必须做高可用最常见的方案是KeepalivedLVS双机热备。Keepalived通过VRRP协议实现VIP的漂移主节点正常时持有VIP主节点故障时备用节点接管VIP整个过程对客户端透明。这个方案的原理说起来简单但配置细节很多。首先是VRRP的优先级设置主节点优先级要高于备用节点比如主150备100。然后是抢占模式和非抢占模式的选择抢占模式下主节点恢复后会抢回VIP非抢占模式下主节点恢复后不抢VIP继续留在备用节点。我一般用非抢占模式避免VIP频繁漂移导致连接中断。Keepalived的配置文件主要分三块global_defs、vrrp_instance和virtual_server。global_defs里配置路由ID和通知脚本vrrp_instance定义VRRP实例包括状态、接口、优先级、认证方式virtual_server定义LVS的转发规则包括VIP、端口、调度算法和真实服务器列表。一个容易踩的坑是防火墙。VRRP协议用的是组播地址224.0.0.18如果防火墙没放行主备之间无法通信会导致双主两台都认为自己是主的严重问题。所以配置之前一定要确认防火墙规则或者直接关掉防火墙内网环境。另一个坑是Keepalived的健康检查。默认的健康检查是TCP连接检查但有些服务TCP端口开着但应用已经假死了这时候需要更精细的检查比如HTTP状态码检查或者自定义脚本检查。Keepalived支持配置MISC_CHECK来执行自定义脚本脚本返回0表示健康返回非0表示故障。3.2 DR模式后端服务器的ARP抑制配置DR模式有一个必须处理的细节后端服务器需要在回环接口上配置VIP但同时又不能让外界感知到这个VIP否则会跟LVS抢流量。解决办法是配置ARP抑制。具体来说需要修改两个内核参数# 忽略来自其他接口的ARP请求 echo 1 /proc/sys/net/ipv4/conf/all/arp_ignore # 使用最合适的源地址响应ARP请求 echo 2 /proc/sys/net/ipv4/conf/all/arp_announce然后在回环接口上配置VIPifconfig lo:0 192.168.1.100 netmask 255.255.255.255 up这里有个细节netmask必须设成255.255.255.255不能设成255.255.255.0。因为如果设成后者后端会认为VIP所在的网段是直连的可能会发出ARP请求导致网络混乱。这些配置需要持久化否则重启后就失效了。可以把它们写到/etc/sysctl.conf和网络配置脚本里。我见过不少团队在测试环境配好了上线后重启服务器发现VIP没了排查半天才发现是没做持久化。3.3 完整部署流程与验证方法下面我把DR模式LVSKeepalived的完整部署流程梳理一遍。假设你有两台LVS节点主备和两台后端服务器VIP是192.168.1.100。第一步LVS节点安装软件yum install -y ipvsadm keepalived第二步配置Keepalived主节点配置文件/etc/keepalived/keepalived.confglobal_defs { router_id LVS_MASTER } vrrp_instance VI_1 { state MASTER interface eth0 virtual_router_id 51 priority 150 advert_int 1 authentication { auth_type PASS auth_pass 1234 } virtual_ipaddress { 192.168.1.100 } } virtual_server 192.168.1.100 80 { delay_loop 6 lb_algo wlc lb_kind DR persistence_timeout 300 protocol TCP real_server 192.168.1.101 80 { weight 100 TCP_CHECK { connect_timeout 3 nb_get_retry 3 delay_before_retry 3 } } real_server 192.168.1.102 80 { weight 100 TCP_CHECK { connect_timeout 3 nb_get_retry 3 delay_before_retry 3 } } }备用节点的配置类似只需要改state为BACKUPpriority改为100router_id改为LVS_BACKUP。第三步后端服务器配置# 配置ARP抑制 echo 1 /proc/sys/net/ipv4/conf/all/arp_ignore echo 2 /proc/sys/net/ipv4/conf/all/arp_announce echo 1 /proc/sys/net/ipv4/conf/lo/arp_ignore echo 2 /proc/sys/net/ipv4/conf/lo/arp_announce # 配置VIP到回环接口 ifconfig lo:0 192.168.1.100 netmask 255.255.255.255 up第四步验证在主节点上执行ipvsadm -L -n应该能看到虚拟服务和真实服务器的列表。然后用curl访问VIP观察请求是否被分发到不同的后端。可以临时停掉一台后端看LVS是否自动把它剔除。注意测试的时候一定要用不同的客户端IP去访问否则因为持久连接的原因所有请求都会落到同一台后端你会误以为负载均衡没生效。4. 生产环境常见故障与排查实录4.1 后端服务器全部下线但服务正常这个问题听起来矛盾但确实发生过。现象是ipvsadm -L显示所有真实服务器都是inactive状态但用户访问却正常。排查后发现是健康检查的TCP_CHECK配置有问题检查端口写错了导致LVS认为后端都挂了但实际上后端服务是正常的。还有一种可能是健康检查频率太高后端服务器因为并发连接数限制拒绝了检查请求LVS误判为故障。解决办法是调整delay_loop和connect_timeout参数给后端足够的响应时间。4.2 VIP漂移后旧连接不释放Keepalived做VIP漂移时已经建立的连接不会立即断开而是会继续走原来的路径。如果主节点已经挂了这些连接就会超时。对于长连接业务比如WebSocket这个问题尤其明显。解决办法是在Keepalived的notify脚本里在节点变成BACKUP时主动清理IPVS的连接表#!/bin/bash if [ $3 BACKUP ]; then ipvsadm -C fi这个脚本在节点状态变为BACKUP时执行清空所有转发规则和连接表强制客户端重新建立连接。4.3 调度不均导致部分后端过载WRR和WLC算法都依赖权重配置如果权重设置不合理就会出现部分后端过载。我遇到过一个案例两台后端配置相同权重也相同但其中一台的负载明显高于另一台。排查后发现是持久连接导致的因为测试时用的同一个客户端IP所有请求都落到了同一台。生产环境里如果发现调度不均首先要确认是不是持久连接或者SH算法导致的。如果是考虑改用WLC算法并关闭持久连接。如果确实是权重问题根据实际负载调整权重。我一般会观察CPU使用率和连接数两个指标CPU高的降权重连接数多的降权重。4.4 常见问题速查表问题现象可能原因排查方法解决方案VIP无法访问Keepalived未启动检查进程和日志启动Keepalived后端全部inactive健康检查配置错误检查端口和超时修正检查配置负载不均持久连接或SH算法查看连接分布改用WLC算法双主现象VRRP通信失败检查防火墙和组播放行VRRP协议响应慢后端性能瓶颈查看后端负载调整权重或扩容VIP漂移后连接超时旧连接未清理检查notify脚本添加清理逻辑4.5 内核参数调优的几个关键点LVS的性能很大程度上取决于内核参数。默认参数适合通用场景但高并发下需要调整。以下几个参数我每次部署都会检查net.ipv4.ip_forward必须设为1否则LVS无法转发数据包。这个是最基础的但有时候系统默认是0忘了改就会导致转发失败。net.ipv4.vs.conn_reuse_mode控制连接复用模式。默认是1表示允许复用TIME_WAIT状态的连接。在高并发短连接场景下这个参数能显著提升性能。但如果遇到端口耗尽的问题可以尝试设为0。net.ipv4.vs.expire_nodest_conn设为1时如果后端服务器不可达LVS会立即把连接转发到其他后端而不是等待超时。这个参数能提升故障切换的速度。net.ipv4.vs.schedule_icmp_error控制是否响应ICMP错误。一般设为0避免ICMP错误影响转发决策。这些参数可以通过sysctl -w临时修改也可以写到/etc/sysctl.conf持久化。修改后需要重启IPVS或者重新加载配置才能生效。5. 性能压测与容量规划经验5.1 压测工具的选择与使用LVS的性能压测跟普通服务不太一样因为它本身不处理业务逻辑所以压测的重点是转发能力和连接建立速度。常用的工具有ab、wrk、hey但我更推荐用wrk因为它支持多线程和长连接能更好地模拟真实场景。压测的时候要注意几点一是压测客户端不能跟LVS在同一台机器上否则会互相影响二是要监控LVS的CPU和内存使用率找到瓶颈点三是要观察后端的负载是否均衡如果后端先扛不住了那瓶颈就不在LVS。我一般会做几轮压测第一轮用短连接测连接建立速度第二轮用长连接测吞吐量第三轮模拟故障测切换速度。每轮压测都要记录关键指标形成基线数据方便后续对比。5.2 容量估算的实用方法LVS的容量估算主要看两个指标并发连接数和每秒新建连接数。并发连接数取决于内存每个连接大约占用几百字节的内核内存。每秒新建连接数取决于CPU单核大约能处理几万到十几万的新建连接。假设你的业务峰值是每秒10万请求平均每个请求处理时间100毫秒那么并发连接数大约是1万。这个量级单台LVS轻松搞定。但如果每秒新建连接数是10万那就需要多核CPU因为新建连接是CPU密集型操作。我的经验是单台4核8G的LVS用DR模式大约能扛住50万并发连接和每秒20万新建连接。当然这个数字跟具体的业务场景和内核参数有关建议在实际环境中压测验证。5.3 扩容与缩容的操作要点扩容后端服务器时直接在后端配置好服务然后在LVS上执行ipvsadm -a添加即可。但要注意新加的后端需要先预热不要一上来就给满权重。我一般先给10%的权重观察几分钟确认没问题再逐步加到正常权重。缩容时先把要下线的后端权重设为0等现有连接处理完再执行ipvsadm -d删除。直接删除会导致正在处理的请求中断用户体验很差。LVS节点本身的扩容比较麻烦因为涉及到VIP的漂移和VRRP的重新选举。一般不建议频繁扩缩LVS节点而是通过增加后端来提升整体容量。如果LVS确实成了瓶颈可以考虑用DNS轮询做多组LVS的负载均衡。6. 个人实操体会与后续扩展方向6.1 踩过几次坑之后的几点体会第一配置文件一定要版本管理。Keepalived的配置文件改错了可能导致VIP漂移或者转发规则丢失。我现在的做法是把配置文件放到Git里每次修改都提交出问题了直接回滚。第二监控比配置更重要。LVS本身不产生日志出问题了很难排查。所以一定要配置监控监控VIP的可达性、后端服务器的健康状态、连接数的变化趋势。我一般会用脚本定期执行ipvsadm -L -n并把结果推送到监控系统。第三测试环境要尽量模拟生产。我见过太多团队在测试环境用NAT模式生产环境用DR模式结果上线后各种问题。测试环境应该跟生产环境保持一致的架构和配置哪怕规模小一点。第四不要忽视文档。LVS的配置涉及网络、内核、应用多个层面时间长了很容易忘记当初为什么这么配。我习惯在配置文件里写注释说明每个参数的含义和调整原因方便自己和同事后续维护。6.2 这个架构还能怎么扩展LVSKeepalived的方案已经能满足大部分场景但如果业务继续增长可以考虑几个扩展方向。一是引入ECMP等价多路径路由用多台LVS同时持有同一个VIP通过路由器的ECMP能力做负载均衡这样LVS层也能水平扩展。二是结合DPDK或者XDP技术把转发性能再提升一个数量级不过这个对技术栈要求比较高。三是把LVS容器化用Kubernetes的Service或者Ingress来管理不过容器网络跟LVS的配合还有一些细节需要处理。最后分享一个小技巧如果你不确定调度算法选哪个先用WLC跑一段时间观察后端的负载分布。如果发现某台后端明显偏忙再考虑调整权重或者换算法。不要一开始就追求完美配置实际运行数据比理论计算靠谱得多。