做运维这些年被问得最多的需求就是“给几个服务做高可用”。尤其当流量开始起来、后端不再只有一台机器的时候前面总得放一个能承担入口流量的家伙。LVS做四层转发keepalived做VIP漂移和健康检查这两样东西搭在一起基本是开源生态里最经典、最能打的高可用组合之一。本文把这些年实际部署keepalivedLVS的经验整理出来重点讲清楚DR模式下数据怎么走、keepalived配置里哪些参数是命门以及一套可以直接抄写的Rocky Linux 9实操配置。如果你正准备给Nginx、给数据库读入口、甚至给K8s多master集群搭一个统一接入层这篇内容应该能帮你少踩一半的坑。1. 为什么是 keepalivedLVS而不是别的方案先说结论在高并发四层接入层这件事上LVS跑在内核态性能天花板远高于Nginx和HAProxy的用户态转发。Nginx的七层转发强在协议理解能读写HTTP头、能根据URL路径分发但每来一个连接都要建立完整TCP会话CPU开销不小。HAProxy同样优秀但性能表现还是受制于单进程事件循环的用户态开销。LVS则直接把转发规则放进内核的ipvs模块数据包到了网卡之后内核按规则直接改MAC、改IP、转发出去几乎不经过应用层。做运维这么多年我最直观的感受是普通物理机上LVS撑住几十万并发TCP连接是很稳的事而用Nginx或HAProxy跑到这个量级CPU会先拉警报。再看keepalived它解决的是高可用的另一半——VIP漂移。在keepalivedLVS架构里一台服务器作为入口承载所有流量还不够这本身就是一个单点。于是我们用两台机器跑同一个虚拟IPVIP正常情况下VIP落在主节点上主节点挂了之后VIP在几秒内切换到备节点由备节点接管转发工作。这个切换逻辑依赖VRRP协议keepalived就是VRRP协议在Linux下的标准实现。为什么选它而不是自己写脚本因为VRRP本身就是为这种场景设计的标准协议通告报文、优先级选举、故障探测都是现成的keepalived把这些封装成几行配置比手写一套心跳逻辑靠谱得多。那这个组合适合什么场景我常用的判断标准有三条后端是无状态服务或者状态已经外置session放Redis/数据库因为四层转发只认IP和端口不关心应用层内容。流量规模大QPS过万、连接数过十万需要在更靠近内核的地方完成分发。已经有一套七层负载均衡或应用网关只需要在前面再架一层四层入口做流量收口和高可用兜底。比如给K8s集群的多台master节点做统一接入用LVSkeepalived把VIP指给多个master的API Server端口比用云厂商负载均衡或者自建Nginx都更直接。K8s三台master的高可用本质就是让API Server不因为一台机器宕机而不可用keepalived在这里当虚拟入口背后三个master轮流接包就是一个非常典型的落地场景。当然这不代表Nginx和HAProxy没用七层场景里它们依然是最重要的组件但在四层高可用这一层keepalivedLVS是绕不开的选择。2. 核心原理拆解数据流、VIP漂移与健康检查2.1 LVS三种工作模式为什么DR模式最常用LVS有三种工作模式NAT模式、TUN模式、DR模式。NAT模式里LVS节点负责请求进和响应出后端机器把网关指向LVS所有流量都要过LVS这一关它自己很容易成为瓶颈。TUN模式通过IP隧道把包封给后端机器后端支持隧道协议并用VIP回包理论上扩展性很好但在常规内网环境里意义不大配置隧道两头也麻烦。DR模式是最常用的方案用户请求到达LVS节点后LVS只改目标MAC地址把包从物理网卡直接丢给后端真实服务器后端处理完后直接以VIP身份回包给客户端根本不再经过LVS节点。这带来的好处非常明显请求流量和响应流量是分开走的。LVS节点只需要处理进来的流量和一部分转发动作回包的大流量全部绕开它性能压力小了一大截。我做压测时对比过同样的后端服务、同样的VIP入口DR模式下LVS节点的CPU占用比NAT模式低一个数量级因为NAT模式还要负责把回包的源地址改成VIP这是一笔不小的处理负担。代价是DR模式要求后端服务器和LVS节点在同一个二层网络内且每台后端服务器都要在自己回环接口上绑定VIP并关闭对VIP的ARP响应。很多人栽在这一步后面实操部分我会详细展开。DR模式还有一个容易被忽略的细节它只做四层分发不修改TCP报文的源和目标IP。后端收到的包里源地址是客户端真实IP目的地址是VIP只是MAC帧的目标MAC被改成了后端服务器网卡的MAC。所以后端必须保证内核对待发往VIP的包不回ACK也不发RST否则前后端配合就会出现“握手失败”或“请求能到、响应回不了”的诡异故障。这里的关键就是sysctl的arp_ignore和arp_announce参数后面会给出具体数值。2.2 keepalived的VRRP机制主备怎么选VIP怎么漂keepalived在两台节点上跑VRRP实例两个节点通过组播或单播报文互相发通告。报文中带一个关键字段优先级priority优先级高的节点会成为MASTER持有VIP另一个节点处于BACKUP状态默默监听master的存活消息。默认通告间隔是1秒master每隔1秒发一次通告backup如果连续几个通告周期没收到master的消息就会认为master已经宕了立刻把VIP绑到自己网卡上对外表现就是VIP无缝漂移到了备机。配置里最需要理解的是虚拟路由IDvirtual_router_id。主备两台节点上的这个ID必须一致且最好在同一网段内唯一如果另一套keepalived也用同一个ID两个无关的集群会互相干扰甚至引发VIP争抢。同样认证密码也必须一致否则VRRP报文会被丢弃节点之间形同陌路。state字段虽然写着MASTER和BACKUP但真正决定谁是主人的是priority字段不是state字段。我曾经见过有人把state和priority写反结果备机priority比主机高重启后VIP直接落到备机上排查了很久才发现是优先级写错了。健康检查比VIP漂移更微妙。keepalived本身可以对LVS规则里的后端真实服务器做检查也可以对主机的服务或端口做检查。前者是调度层面的健康检查某台后端挂了LVS把它从转发列表里摘掉权重归零流量不再分给它后者是高可用层面的健康检查LVS节点自己的业务异常了配套脚本会触发节点降级VIP漂移过去。这两层检查要区分清楚配置时不要混为一谈。实际生产里很多“VIP没漂移”的故障报告其实质是健康检查配置不完整节点没宕机但服务已经不可用了keepalived却仍然把VIP握在自己手里。依赖这个逻辑K8s多master场景的接入口高可用应运而生VIP先指向master01的6443端口master01挂了keepalived检测到8443连不上VIP漂到master02Kube-apiserver继续被访问。整个集群对调用方而言始终是同一个VIP、同一个端口。3. 从零到一Rocky Linux 9 环境下的完整实操配置3.1 规划环境尽量用真实验证过的环境来写。我最近在一套Rocky Linux 9.3的环境里重新搭了一整个keepalivedLVS集群下面这份配置和命令都是从这套环境里摘出来的。拓扑如下角色主机名IP地址系统安装组件LVS主节点lvs01192.168.1.10Rocky Linux 9.3keepalived、ipvsadmLVS备节点lvs02192.168.1.11Rocky Linux 9.3keepalived、ipvsadmVIP虚拟IP—192.168.1.100——Nginx后端1web01192.168.1.20Rocky Linux 9.3nginxNginx后端2web02192.168.1.21Rocky Linux 9.3nginx这里强调一下DR模式下VIP不能和LVS节点IP、后端IP混淆它只是绑定在LVS节点网卡上的一个辅助地址。实际生产里VIP必须和LVS节点在同一个子网这样客户端通过二层直接访问VIP时ARP解析才能找到对应机器。此外我在web01和web02各跑了一个静态页面分别标注Web1、Web2方便后面验证轮询和权重切换。如果后端不是Nginx而是 MySQL 的读从库或API服务原理完全一样只要把虚拟服务器定义的端口和健康检查端口相应改掉即可。3.2 安装与内核参数调整两台LVS节点先安装组件yum install -y keepalived ipvsadmsystemd接管了两个服务开机自启动可以后面再统一打开。先装好就行重点在后端服务器的内核参数。DR模式下后端服务器必须放行目标地址为VIP的数据包同时禁止对VIP做ARP应答。否则局域网里所有后端的网卡都能收到VIP的ARP请求其中一台抢答了VIP的真实MAC地址就乱了LVS按调度规则把包发给某一台后端时客户端的后续TCP会话可能跑到另一台机器上连接必然诡异中断。所以web01和web02上要修改如下参数cat /etc/sysctl.conf EOF 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 EOF sysctl -p这几个参数的含义arp_ignore设为1表示本机只回答目标IP是本机接口IP的ARP请求arp_announce设为2表示ARP通告尽量使用能到达目标的最佳本地地址。之所以要同时调整lo和eth0是因为不同Linux发行版对网卡名处理有差异全接口设置最稳妥。然后给后端在回环接口上绑定VIPip addr add 192.168.1.100/32 dev lo label lo:0这里用/32掩码表示VIP只作为本机的一个标识地址不产生任何路由广播。用ip命令验证ip addr show lo如果看到lo:0上绑了192.168.1.100/32内核参数也生效了后端准备完毕。这个绑定每次重启都会丢需要在/etc/rc.local或systemd里做开机持久化或者用NetworkManager的脚本动态添加。最简单的方案是写一个oneshot的systemd服务或者直接把ip addr add命令追加到 /etc/rc.d/rc.local 并赋予执行权限。3.3 双节点keepalived配置主节点lvs01的 /etc/keepalived/keepalived.conf 我是这样写的global_defs { router_id LVS_DEVEL_01 enable_script_security } vrrp_instance VI_1 { state MASTER interface eth0 virtual_router_id 51 priority 150 advert_int 1 authentication { auth_type PASS auth_pass 851209 } virtual_ipaddress { 192.168.1.100/24 dev eth0 label eth0:0 } } virtual_server 192.168.1.100 80 { delay_loop 6 lb_algo wrr lb_kind DR persistence_timeout 0 protocol TCP real_server 192.168.1.20 80 { weight 1 TCP_CHECK { connect_port 80 connect_timeout 3 nb_get_retry 3 delay_before_retry 2 } } real_server 192.168.1.21 80 { weight 1 TCP_CHECK { connect_port 80 connect_timeout 3 nb_get_retry 3 delay_before_retry 2 } } }备节点lvs02的配置几乎一样只有三处不同router_id改成LVS_DEVEL_02state改成BACKUPpriority改成100。virtual_router_id保持51IP和端口规则一致这个ID在两个节点上必须完全一致千万不能写成不同值。逐段说明几个关键配置项lb_algo wrr表示加权轮询web01和web02权重都是1流量会各分一半。也可以换成lc最少连接但HTTP类的无状态服务用轮询即可会话更均匀。lb_kind DR是最核心的一行它决定LVS用哪种模式转发写NAT或TUN都会导致这台UBUNTU的架构完全不同。persistence_timeout是连接保持时间单位秒。四层负载均衡的“会话保持”和“粘滞会话”其实靠这个参数实现但很多高可用排查的坑也在这里。如果是无状态服务建议设成0让每个请求尽量均匀分摊。如果后端是有登录态且session没有外置的旧架构这个值可能要设成600甚至更长但严格来说这治标不治本后面会再说。TCP_CHECK是keepalived自带的健康检查方式它主动探测后端TCP端口connect_timeout是每次连接超时时间nb_get_retry是失败重试次数delay_before_retry是重试间隔。这套组合下只要后端Nginx还活着keepalived每6秒delay_loop检查一轮后端挂了就自动从ipvs规则里摘掉。我用一个自定义脚本做HTTP级别的检查在下一章展开生产里更推荐那种方式。配置完成后主备节点分别启动systemctl enable --now keepalived systemctl status keepalived启动后用ip addr看一眼主节点VIP应该已经落在eth0:0上ip addr show eth0再用ipvsadm确认LVS规则装载成功ipvsadm -L -n正常输出会列出VIP和两个后端IP Virtual Server version 1.2.1 (size4096) Prot LocalAddress:Port Scheduler Flags - RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 192.168.1.100:80 wrr - 192.168.1.20:80 Route 1 0 0 - 192.168.1.21:80 Route 1 0 0看到Forward那列为Route说明DR模式已生效。此时访问 http://192.168.1.100/ 应该在web01和web02之间来回切换。3.4 验证VIP漂移最直观的故障演练直接停掉主节点lvs01上的keepalived服务。systemctl stop keepalived正常情况下3到5秒之内lvs02上执行 ip addr show eth0 就能看到VIP出现在它自己的网卡上。这种验证方法在测试环境做一次就够了主要确认VRRP报文的通信、认证、优先级过滤都正常。我第一次做这个测试的时候因为两台机器开着firewalld没有放行VRRP协议协议号112VIP漂移等了十几秒都没动静。如果你也遇到同样情况记得两台机器都执行firewall-cmd --permanent --add-rich-rulerule protocol valuevrrp accept firewall-cmd --reload另外Rocky Linux 9默认SELinux是enforcing状态keepalived在DAL配置里执行外部脚本时会被SELinux拦日志会报permission denied。要么把脚本放在/usr/bin目录并设置合适的上下文要么临时用setsebool放行要么在开发环境里把SELinux调到permissive。生产建议用正确的SELinux策略测试环境直接放行即可。这类“配置明明没问题却起不来”的故障排查顺序永远是日志优先后面会专门讲。4. 健康检查脚本决定高可用好坏的隐形关键keepalived内置的TCP_CHECK只能探测端口通不通它能发现“Nginx进程挂了”却很难发现“Nginx进程还在但磁盘满了写不了日志返回的全是500”。这种半死不活的状态里服务还在监听端口TCP_CHECK照样返回成功流量继续引进来用户看到的就是莫名其妙的报错。想做到真正的服务级健康检查需要把检查方式换成MISC_CHECK通过自定义脚本来决定后端是否健康。我在生产里常写的脚本模板#!/bin/bash # 检查Nginx进程和健康检查接口 # 返回0表示健康返回1表示故障 if ! pgrep -x nginx /dev/null 21; then echo $(date %F %T) nginx process not found /var/log/keepalived_checks.log exit 1 fi code$(curl -s -o /dev/null -w %{http_code} --connect-timeout 3 --max-time 5 http://127.0.0.1/healthz) if [ $code ! 200 ]; then echo $(date %F %T) healthz return code $code /var/log/keepalived_checks.log exit 1 fi exit 0把这个脚本复制到两后端的 /etc/keepalived/check_nginx.sh然后注意给keepalived进程加执行权限chmod x /etc/keepalived/check_nginx.sh然后在双节点keepalived.conf的real_server段里把TCP_CHECK换成MISC_CHECKreal_server 192.168.1.20 80 { weight 1 MISC_CHECK { misc_path /etc/keepalived/check_nginx.sh misc_timeout 5 } }这样每次检查周期都会执行脚本脚本返回非0时该后端会被摘掉。有了这个基础几乎任何能想到的故障场景都能写进脚本检查磁盘inode、检查应用层接口状态码、检查SSL证书剩余天数、检查Redis内存命中率。健康检查脚本的想象力边界就是后端业务可观测性的边界。脚本还有一个关键用途——动态调整权重。keepalived并不支持直接按后端负载动态调节ipvs权重但你完全可以在脚本里根据负载计算权重再用ipvsadm命令实时修改# 比如当前连接数大于10000时权重从1降到0 cur$(cat /proc/net/ip_vs_conn | wc -l) if [ $cur -gt 10000 ]; then ipvsadm -e -t 192.168.1.100:80 -r 192.168.1.20:80 -w 0 else ipvsadm -e -t 192.168.1.100:80 -r 192.168.1.20:80 -w 1 fi注意这个思路必须配合一个定时脚本执行而不是放在健康检查脚本里因为MISC_CHECK的返回值才是keepalived用来判断移除/恢复后端的依据后端的权重如果被外部改掉keepalived下一轮检查后可能自己恢复。所以我的建议是权重调节单独写个cron或systemd timer不混入健康检查逻辑。高可用场景下后端代码要注意什么跟健康检查的关系很深。我见过太多团队把后端服务部署好以后完全没想过“如果我掉线再恢复LVS会不会重新把它加回来”。有的后端服务在启动时监听了一个IP和端口但绑定的是固定IP而非VIP结果VIP漂移后后端无法响应新VIP上的请求——这类问题本质上是代码对“服务发现”和“动态网络环境”的适应性不够。做后端开发时至少要保证服务不要绑定死某个IP监听0.0.0.0session要外置健康检查接口要独立于业务逻辑、不能被慢查询拖死服务优雅上下线要能配合健康检查窗口。5. 常见问题与排查技巧实录5.1 keepalived exited with permanent error config见过太多次keepalived服务启动失败systemctl status一查错误信息里写着 “exited with permanent error config”。翻译过来就是“配置永久性错误服务直接退出”。这时候别反复重启先去日志确认journalctl -u keepalived -n 50日志里通常会直接告诉你哪个配置块出了问题。最常见的几种错误是配置里多写了一个右花括号整个块的嵌套层级乱了。vrrp_instance或virtual_server里的字段名拼错了比如priority写成protity。认证密码超过8位VRRP的PASS认证只支持8位以内的密码超了就会启动报错。配置文件权限不对keepalived启动时读不了目录下的脚本。碰到这类问题最快的排查办法是把配置精简到最小可运行版本一段一段加回去。比如先只保留global_defs和vrrp_instance不加virtual_server确认VRRP能正常工作再把virtual_server加回来加上健康检查。这样能快速定位是哪一部分触发了permanent error。5.2 VIP在主备间乱跳忽略IP、防火墙与组播的坑有一种很隐蔽的故障主备两台机器上的VIP都绑定了但一会儿在主机、一会儿在备机客户端访问时好时坏。原因通常是VRRP报文被影响主备收不到彼此的通告各自都认为对方死了于是都进入MASTER状态抢VIP。排查这个问题要看两层第一层看防火墙。VRRP报文使用的协议号是112普通端口放行策略对它无效必须像前面那样放行协议。如果两台机器上防火墙配置不一致主机的报文备机收不到VIP必然乱跳。第二层看组播环境。某些交换机开启了组播过滤或IGMP snoopingVRRP的默认组播地址224.0.0.18可能被丢弃。这时可以把keepalived的VRRP通信改成单播模式在vrrp_instance里指定对端IPunicast_src_ip 192.168.1.10 unicast_peer { 192.168.1.11 }这样两节点之间用单播报文通信不再依赖组播能绕开一大类组播环境问题。还有keepalived配置文件里的vrrp_strict选项它会自动配置一套iptables规则拦掉非VRRP的组播流量严谨但容易和业务防火墙策略打架我默认从不开启。关于忽略IPkeepalived对VIP漂移的控制还有一个细节如果同一网段里已经有别的机器占用了同样的IP两台LVS节点绑定VIP时就会出现地址冲突。此时需要保证清理掉重复占用的地址同时让后端服务器对VIP彻底“失聪”也就是前面配置的arp_ignore参数。你经常看到“如何在LVS里忽略某个IP”的查询实际对应的就是这种冲突场景。无论是后端误绑VIP还是LVS节点网卡上有多个地址只要没有正确抑制ARP调度就会出问题。配置完这些后再用arping从LVS节点主动发一个带VIP的ARP通告arping -I eth0 -c 3 -s 192.168.1.100 192.168.1.1通过这个命令能让交换机快速刷新VIP和MAC的对应关系很多“VIP明明已经漂过来了但外面还是不通”的问题都能靠这个命令解决。5.3 后端收到请求但回不了包ARP和路由问题另一个高频故障是LVS转发正常后端Nginx日志里有请求记录但客户端就是一直连接超时。这不是LVS的问题是后端回包路径断了。DR模式的关键在于“后端直接回包给客户端”这要求后端认为自己拥有VIP这个地址同时要把对VIP的ARP请求全部忽略。如果arp_ignore和arp_announce配错了或者lo:0上的VIP没绑成功后端收到包后要么不发响应要么发出一个源IP是后端自身IP的响应包客户端根本不认连接自然建立不起来。排查时先检查后端ip addr show lo cat /proc/sys/net/ipv4/conf/all/arp_ignore再看LVS节点ipvsadm -L -n --stats如果转发统计里ActiveConn在涨但客户端仍然不通基本可以确定是后端回包路径的问题。此时在后端上抓包如果看到进来的SYN包但看不到出去的SYN-ACK包就是后端没有把自己当成VIP的owner检查lo:0是否还在。如果能看到出去的SYN-ACK包但客户端没收到可能是中间交换机的MAC表没刷新用arping强制通告一次即可。5.4 流量不均匀到底是谁的锅两台后端权重都是1但实际压测发现一台收到80%流量另一台只有20%。先别赖keepalived大概率是下面之一persistence_timeout设得太大同一个源IP的请求在一段时间内全部发给同一台后端压测机器的源IP往往就那一个看起来自然严重倾斜。把persistence_timeout设为0即可。另一个可能是TCP连接复用压测客户端建立了长连接长连接在生命周期内不会重新调度现象也是倾斜。高并发场景里这反而正常需要理解LVS对已建立的连接默认不做重新调度只有新连接才会被wrr算法分发。如果配置确实没问题流量还是歪的就看看连接表里是不是有异常条目ipvsadm -L -n --persistent-conn这个命令能列出持久连接。还有一点容易忽略keepalived的delay_loop是6秒健康检查切换后权重更新不是即时生效的。压测时应适当让连接短一点、发起源分散一点再看分发比例是否接近配置的权重。6. 写在最后的经验把keepalivedLVS玩到顺手之后你会发现高可用这件事的重心早就不在“配置怎么写”上而在“故障发生时怎么让人无感”。我个人的体会有几条比较重要。第一任何高可用方案都不能只验证“宕机后VIP能漂移”一定要演练“恢复后VIP能漂回来”。很多团队只做了前者结果主节点恢复后因为priority更高又把VIP抢回来刚好把正在处理的连接掐断。第二加缓存层和限流越早越好因为有了keepalivedLVS后迁移后端机器变得非常方便但后端被摘掉后如果直接冲垮了数据库高可用就成了一句空话。第三观察从VIP进来的流量分布永远比盯着各家监控面板更真实。舍得在服务器上装好netdata或Prometheus等到压测或故障演练时你能看到的东西会比预期多得多。还有个小技巧生产环境的keepalived配置文件最好纳入git管理改完配置先执行keepalived -t -f /etc/keepalived/keepalived.conf做语法校验再重启服务。这个-t参数能拦住绝大多数“exited with permanent error config”的尴尬事。多机环境里任何对主节点的操作都要想想会不会触发备机接管不要一边改配置一边线上压测否则你看到的可能是VRRP抢占带来的抖动而不是你的压测数据本身。