做后端服务的人迟早会遇到一个需求把一台服务器扛不住的流量拆到多台还希望某一台挂掉的时候流量自动被切走。很多人第一反应是买云上的负载均衡或者在用户态跑一个软件负载均衡但要追求极致的吞吐和可控性时Linux内核自带的IPVSIP Virtual ServerIP虚拟服务器几乎是绕不开的答案。它也是LVS集群方案的核心实现数据包从收到转发基本都在内核态完成不会频繁切到用户态所以转发延迟和并发处理能力都相当能打。这篇文章就把IPVS是什么、内核里干了什么事、转发模式怎么选、keepalived怎么配、压测和排障怎么做按我实际部署的顺序过一遍。无论你是刚接触负载均衡还是已经在用云LB但想理解底层原理都有可以直接抄作业的内容。1. 先搞清楚IPVS究竟在操作系统里做了什么1.1 数据包在内核里的几道关卡我第一次用IPVS的时候第一件事就是想弄明白它到底加在哪。IPVS不是一个跑在用户态的守护进程它是Linux内核里的一个模块注册在netfilter框架的LOCAL_IN、LOCAL_OUT、FORWARD等钩子上。当一个客户端发起的请求到达调度器时数据包会先在协议栈里走一遭到钩子点被IPVS捕获。这时候IPVS会根据连接调度表——其实就是一张大哈希表——查一下这个连接应该落到哪台后端然后直接执行对应的转发动作。这个过程用户态完全感知不到没有进程调度没有上下文切换没有数据包从内核拷贝到用户空间再拷回去的额外开销。对比一下假如你在用户态跑一个转发程序每个包都要经过系统调用、内存拷贝、业务逻辑判断代价是非常明显的。IPVS选择在内核里做转发就是把这些重复的操作全部省掉了这也是它能扛住大规模并发请求的根本原因。关于钩子点有一点要注意IPVS不是拦截所有的包。只有在调度器自己作为目标地址VIP接收入站连接、或者需要转发给后端时它才会介入。所以你的内核里装了IPVS模块不代表所有流量都会经过它只有用ipvsadm或keepalived显式创建了虚拟服务器规则的VIP/端口才会被接管。这个认知能帮你避免很多后面的误判。1.2 连接哈希表从连接怎么来、怎么去IPVS内部维护了一张连接表表项的组成跟iptables的conntrack有点类似但又有它自己的调度语义。对TCP来说一个客户端访问VIP:80IPVS会记下“这个五元组由谁发起、由我转发到了哪台后端”。后续这个连接上的所有报文都会直接命中同一张哈希表项不需要重新做调度决策。这里要展开说一个关键点IPVS的调度发生在“连接建立”那一刻而不是每个包。以TCP为例第一次SYN到达时IPVS按你配置的调度算法选一台RS建立连接表项之后同一连接的ACK、数据报文全部按表项原样转发不会再触发算法选择。这个设计极大降低了调度器的CPU开销但也带来一个隐含约束如果你改动了调度算法或权重只会影响新建立的连接存量长连接不会自动切换。正因为有这张连接表IPVS同时还能做很多上游负载均衡很难做的事会话保持、端口复用、RS状态标记全部是基于这张表快速判断的。生产环境我见过单台调度器维护几十万条连接表项还很稳定的场景前提是内核参数和连接表容量都没被默认配置卡死后面我会专门讲调优。1.3 和七层负载均衡本质上的差异很多新手会混淆“负载均衡”这个概念是不是装了IPVS就可以替代七层入口了当然不是。IPVS工作在四层它看得懂TCP/UDP的端口、IP地址但不会去解析HTTP报文里的URI、Header、Cookie这些东西。对比维度IPVS四层七层软件负载用户态工作位置Linux内核态用户态进程数据包处理查表、改写头后转发解包、重组、按业务策略分发单机性能很高适合百万并发连接依赖进程性能和CPU通常低于四层能做的策略IP、端口、连接调度、会话保持URL、Header、Cookie、灰度、限流等适用场景入口流量调度、数据库、Redis、长连接Web业务路由、鉴权、链路治理理解这个差异很重要。IPVS适合做统一流量的入口把客户端的连接分发到后端的多个实例七层软件负载则适合在业务逻辑层做更细粒度的路由。两者经常搭配使用外部请求先到四层IPVS再转发到后面的七层负载再由七层把请求送到具体业务服务。这种分层架构在生产里非常常见。2. 选型评估三种转发模式应该怎么选2.1 NAT模式省事后端的入门选择IPVS的NAT模式全称是网络地址转换模式理解起来很直观。调度器收到客户端请求后把目标地址改成后端RS的地址再转发出去后端处理完响应回包会回到调度器调度器再把源地址改回VIP还给客户端。这种模式的最大好处是对后端RS非常友好RS不需要有任何浮动IP也不用感知VIP的存在只要能和调度器通信就行。配置也简单适合业务刚起步、流量规模不大、后端不在一二层网络的场景。缺点是所有进出流量都压在调度器身上回程流量也要绕一圈吞吐量容易成为瓶颈。如果后端RS的数量很多或者下载类的回包流量特别大NAT模式的调度器网卡会先撑不住。我自己的经验NAT模式更适合内网小规模服务比如一套内部管理系统几个RS实例几十万的日常请求量完全够用。真要支撑大流量对外业务尽量别把回程也放在调度器上优先考虑DR模式。2.2 DR模式生产环境最常用的一匹快马DR模式全称Direct Routing直接路由模式。它的思路是调度器收到请求后并不修改IP层地址只是把数据链路层的目标MAC地址改成后端RS的MAC地址然后把帧放在局域网里后端RS收到后发现目标IP正是自己本机配置的VIP就正常接收处理回包则从RS的物理网卡直接发给客户端完全不需要再绕回调度器。这个“回程不再经过调度器”的设计是DR模式性能高的最大原因。相当于调度器只负责请求方向的转发回包走的是各后端自己的出路。生产环境里绝大多数高流量的LVS集群都用DR模式。DR模式有硬性要求调度器和所有RS必须处于同一个二层广播域也就是在同一个局域网内。RS上还要配置VIP地址但只能配置在回环口lo上并且要用32位掩码不能让它响应ARP广播否则局域网里的交换机和其他机器都会混乱。后面配置节我会写具体命令。2.3 TUN模式与FullNAT跨网段的代价如果你手头的RS分布在不同网段NAT模式可能不够用DR模式又要求同一二层这时候可以选择TUN模式。它把原始数据包封装进新的IP包调度器像一个封装点把数据包投递给处在不同网段的RSRS解封装后再处理。TUN模式能跨网络但每个包都多一层IPIP封装头MTU、性能、系统复杂度都会增加日常用得相对少。FullNAT则是在NAT基础上的改良版它同时做目标地址和源地址转换。客户端看到的源地址被改成了调度器的内网地址后端收到的请求没有真实客户端IP这在某些场景下是缺点。但它不要求RS和调度器在同一二层也不要求RS配置VIP部署灵活度高云环境里的很多LB服务其实内部就走类似技术。总结一句话追求性能和传统架构选DR追求部署灵活选NAT/FullNAT跨网段数据包发送场景才考虑TUN。我把三种模式的核心差异整理成了表格便于你选型时直接对照模式调度器回程压力是否要求同一二层RS需要配置VIP保留客户端源IPNAT大回程必经调度器不要求不需要保留DR小回程直连客户端要求需要保留TUN中回程可绕行但封装有开销不要求需要保留FullNAT小回程可优化不要求不需要不保留3. 实操用keepalivedIPVS组一个带漂移的高可用转发集群3.1 环境规划与内核参数先列一份典型的环境规划。假设我们要为一套对外Web服务做入口调度用两台调度器做一主一备三台RS承载实际请求。角色IP地址说明调度器A192.168.1.10keepalived MASTER管理VIP调度器B192.168.1.11keepalived BACKUP故障时接管VIP虚拟服务IP192.168.1.100对外公布的服务地址简称VIPRS1192.168.1.21承载业务进程RS2192.168.1.22承载业务进程RS3192.168.1.23承载业务进程生产环境里VIP可以跟调度器本身IP在同一个网段也可以是单独规划的一个地址段关键是各设备能正常路由。开始配置前我习惯先做两件事确认内核模块已经加载确认转发开关已打开。# 查看IPVS模块是否可用 modprobe ip_vs lsmod | grep ip_vs # 开启IP转发临时生效长期配置写到/etc/sysctl.conf sysctl -w net.ipv4.ip_forward1如果你用的发行版默认没有编译IPVS模块需要先安装内核模块或相关依赖包大多数主流发行版默认都有只是没加载手动modprobe一下就行。3.2 安装并用keepalived下发规则调度器上需要两个软件ipvsadm用来管理IPVS规则keepalived用来实现VIP漂移和后端健康检查。在常见发行版上直接用包管理器安装yum install -y ipvsadm keepalived安装完成后我建议先手工用ipvsadm把规则逻辑验证一遍再写进keepalived配置。这样做的好处是一旦keepalived配置有问题你至少知道手工规则能不能通排查范围会缩小很多。# 创建虚拟服务VIP 192.168.1.100 端口80调度算法用wrr加权轮询 ipvsadm -A -t 192.168.1.100:80 -s wrr # 添加两台RS-g表示DR模式-w是权重 ipvsadm -a -t 192.168.1.100:80 -r 192.168.1.21 -g -w 1 ipvsadm -a -t 192.168.1.100:80 -r 192.168.1.22 -g -w 2 ipvsadm -a -t 192.168.1.100:80 -r 192.168.1.23 -g -w 1 # 查看规则 ipvsadm -L -n这条命令里的-A是添加虚拟服务器-a是往虚拟服务器里添加RS-t指定TCP协议和端口-s指定调度算法-g指定DR模式。第一次执行完用ipvsadm -L -n看到三行RS记录说明规则建立成功。这一步做过以后再上keepalived心理有底得多。3.3 keepalived配置拆解keepalived的核心任务有两个一是通过VRRP协议让两台调度器共享一个VIP主挂了备自动顶上二是对RS做健康检查发现某台RS挂了就自动摘除恢复后自动加回来。下面是一份能直接改改用的配置写在/etc/keepalived/keepalived.confvrrp_instance VI_1 { state MASTER interface eth0 virtual_router_id 51 priority 100 advert_int 1 authentication { auth_type PASS auth_pass 你自定义的密码 } virtual_ipaddress { 192.168.1.100/24 dev eth0 label eth0:0 } } virtual_server 192.168.1.100 80 { delay_loop 5 lb_algo wrr lb_kind DR persistence_timeout 20 protocol TCP real_server 192.168.1.21 80 { weight 1 TCP_CHECK { connect_timeout 3 nb_get_retry 3 delay_before_retry 2 } } real_server 192.168.1.22 80 { weight 2 TCP_CHECK { connect_timeout 3 nb_get_retry 3 delay_before_retry 2 } } real_server 192.168.1.23 80 { weight 1 TCP_CHECK { connect_timeout 3 nb_get_retry 3 delay_before_retry 2 } } }备机的配置只需要把state改成BACKUP再把priority调低比如100改90其他vrrp_instance里的参数保持一致。尤其virtual_router_id必须一致否则两台调度器不在同一个虚拟路由器组里VIP漂移根本不会发生。配置里几个值得注意的点persistence_timeout 20表示来自同一个客户端IP的新连接在20秒内会被调度到同一台RS这是很实用的会话保持手段但不是越大越好后面我会讲陷阱。TCP_CHECK是每5秒探测一次RS的80端口三次连接失败就摘除RS恢复后自动加回。启动keepalived之前最好先停掉手工添加的IPVS规则比如执行ipvsadm -C清空。因为keepalived启动时会按照自己的配置重新生成规则两套规则叠加会出现一些莫名其妙的现象。清空之后启动keepalived再用ipvsadm -L -n确认规则是否自动生成。systemctl start keepalived systemctl enable keepalived ipvsadm -L -n3.4 后端RS的配置DR模式重点DR模式下RS才是最容易踩坑的地方。RS必须在自己的回环口上配置一个VIP地址这样它收到目标IP为VIP的数据包后才会收下处理同时必须抑制ARP响应否则局域网内会出现多个机器抢答VIP的ARP请求。以下是RS上需要执行的命令建议写成启动脚本开机执行# 配置VIP到回环口掩码必须是32位 ifconfig lo:0 192.168.1.100 netmask 255.255.255.255 up # 抑制ARP响应避免VIP被广播 echo 1 /proc/sys/net/ipv4/conf/all/arp_ignore echo 1 /proc/sys/net/ipv4/conf/lo/arp_ignore echo 2 /proc/sys/net/ipv4/conf/all/arp_announce echo 2 /proc/sys/net/ipv4/conf/lo/arp_announce关键点在于VIP地址只能配255.255.255.255也就是32位掩码。如果写成了常见的255.255.255.0回环口会把整个192.168.1.0网段都当成自己的直连路由后果就是RS对很多不该响应的IP也发起ARP响应轻则网络时断时续重则整个局域网广播风暴。这个坑我亲眼见过有人踩最后的排查结果就是一行ifconfig参数写错了。RS的业务进程监听地址不一定要改成VIP。很多服务默认监听0.0.0.0或者内网IP这都行只要它接收到目标地址为VIP的请求后能正常应答并且回包的源路由能到达客户端DR模式就跑得通。4. 性能参数、会话保持和调度算法怎么调4.1 调度算法快速盘点IPVS支持的调度算法种类比多数人想象的多但生产环境常用的其实就那么几个。我把主要算法的使用场景整理成表格算法英文全称/特点适用场景rr轮询简单平均后端性能差异不大时wrr加权轮询后端配置有差异、需要按权重分配lc最少连接长连接、连接时长差异大的场景wlc加权最少连接绝大多数业务首选的默认算法sh源地址哈希需要严格按客户端IP做会话保持dh目标地址哈希目标地址固定、需要缓存友好的场景lblc/r基于局部性的最少连接要求同目标IP尽量落到同一后端用我的经验来选型后端机器配置一样、连接时长都差不多用rr或wrr足够后端处理的请求耗时波动大用wlc会均衡得多Redis、Memcached、WebSocket这类长连接服务我倾向于用sh配合会话保持参数让同一客户端的连接尽量稳定地落在一台后台上。没有万能算法关键是理解业务连接的特征。4.2 会话保持的底牌和常见陷阱IPVS的会话保持不依赖后端的Cookie或者Session它靠的是IPVS连接表里的持久性机制。配置了persistence_timeout之后从同一个源IP到达VIP的请求在超时时间内会不断被映射到同一台RS这能在不改造应用的情况下解决Session共享问题。但这里有个很容易被忽视的陷阱persistence_timeout设置过大且某个客户端IP后面是公司出口或小区NAT那么一大批用户都会被分到同一台RS上形成热点。我见过一个案例persistence_timeout配了600秒某写字楼的出口IP下面几百个用户同时涌入结果某台RS被打满其他两台闲置。后来把超时降到了30秒配合wrr权重立刻缓解。另外要注意会话保持是按虚拟服务维度生效的。如果你对80端口配了保持那么同一源IP访问443端口时并不会自动保持需要分别配置。如果业务场景要求所有端口都保持可以考虑按端口段创建虚拟服务或者直接用源地址哈希算法逻辑上会更统一。4.3 内核参数与连接表调优IPVS本身的性能很强但操作系统默认参数不一定能撑住高并发。压测或者正式上线前我一般会检查这几项# 查看IPVS连接表相关参数 sysctl net.ipv4.vs.* | head -20 # 查看连接跟踪表容量 sysctl net.netfilter.nf_conntrack_max sysctl net.netfilter.nf_conntrack_buckets负载均衡调度器上最重要的就是别让连接跟踪表成为瓶颈。对于NAT模式来说每个经过的TCP连接都会占用一条nf_conntrack记录默认最大值通常写的是几万条高并发下很容易满满了之后新连接就会被丢弃表现就是时好时坏、偶尔超时。对这种情况要按实际并发量把nf_conntrack_max调大同时把nf_conntrack_buckets相应调大否则哈希冲突会很严重。DR模式下因为回包不经过调度器连接跟踪压力比NAT模式小很多但TCP连接状态仍然会占用资源。我还会关注net.ipv4.tcp_max_syn_backlog和net.core.somaxconn这两个值影响SYN队列长度和accept队列长度。压测时如果发现握手成功但连接很快被重置往往就是后端的accept队列满了并不一定是IPVS的问题。5. 压测验证和问题排查5.1 压测方案先单机再整体IPVS配完别急着切线上流量一定先压一轮。压测我有一个习惯先分别压单台RS确认每台后端的真实水位再压VIP确认调度器有没有成为瓶颈。如果只压VIP一旦整体性能不达标你很难分辨是调度器扛不住还是某台后端拖了后腿。压测工具我用过很多简单快速的是wrk适合做HTTP短连接压测# 模拟8个线程、2万连接、持续30秒 wrk -t 8 -c 20000 -d 30s http://192.168.1.100/压测过程中要用ipvsadm的统计功能实时观察转发情况# 查看实时转发统计 ipvsadm -L -n --stats # 查看速率统计 ipvsadm -L -n --rate # 查看连接超时时间 ipvsadm -L --timeout--stats会显示每台RS的累计连接数和进出流量。如果某台RS的InActConn长期很高但ActConn很低说明大量空闲连接堆在那边需要结合业务判断是长连接空闲还是后端处理不过来。压测结果也要和单机压测数据对比比如单机RS能扛1万QPS三台却只能扛2.2万而不是3万那大概率是调度器或者网络链路存在瓶颈要从网卡中断、连接表参数、收包队列去排查。5.2 常见问题速查表下面这些问题都是我实际遇到过的整理成速查表遇到现象可以直接对号入座现象可能原因处理建议客户端始终连不上VIPkeepalived没起来、VRRP状态异常先确认VIP是否在调度器网卡上ip addr主备同时抢占VIPVRRP配置不一致、优先级相同检查virtual_router_id和priority请求到了调度器但RS收不到DR模式下RS没有配置VIPRS上检查ip addr show lo有无VIPRS收到请求但回包失败RS默认路由指向调度器、或VIP配了非32位掩码DR模式回包必须走RS自己的出口不要经过调度器权重不起作用调度算法不是加权类或会话保持命中换wrr/wlc检查persistence_timeout某一台RS流量明显偏高会话保持时间过长、hash算法热点适当降低persistence_timeout压测时连接忽通忽断并发连接超过调度器或连接跟踪表容量调大nf_conntrack相关参数观察--stats新增RS后始终被摘除RS端口检查失败、防火墙拦截在调度器上telnet RS端口确认网络通5.3 我把坑总结成了一份排查清单每次接到IPVS相关的故障我不会一上来就怀疑调度器。我的排查顺序基本固定先看VIP在不在调度器上再看RS能不能自己访问到业务端口再看从调度器到RS的网络通不通最后才检查IPVS规则和内核参数。大多数“调度器转发不对”的问题其实都出在RS侧的网络配置上。另一个高频坑是防火墙。很多发行版默认firewalld是开着的如果调度器上的filter表规则放行条件不对VIP的数据包可能在iptables阶段就被丢了根本到不了IPVS的钩子点RS上的防火墙也可能拦截来自调度器的健康检查包导致keepalived不断把RS摘掉。遇到诡异现象先看防火墙再查SELinux这两步能排除掉大量环境因素。6. 这些经验值得长期记住回看这些年跟IPVS打交道的经历我最大的体会是它本身并不复杂真正的复杂度全在周边环境——网络二层规划、RS侧ARP、内核参数、keepalived的VRRP配合。你只要把转发模式想清楚把“调度器该管什么、RS该管什么”界定清楚绝大多数问题都能提前避免。给刚上手的读者一个建议第一次实验环境不要直接用生产网络用两台虚拟机加两台后端机把DR模式完整走一遍亲手敲一遍ifconfig和ipvsadm命令再故意把某台RS关掉看keepalived怎么摘除它这一套体验下来比看十篇文档都管用。IPVS到今天依然是很多大型系统的底层基石花一晚上把它吃透后面排查各类四层转发问题时你会感谢自己当初的投入。