做运维这些年，被问得最多的需求就是“给几个服务做高可用”。尤其当流量开始起来、后端不再只有一台机器的时候，前面总得放一个能承担入口流量的家伙。LVS做四层转发，keepalived做VIP漂移和健康检查，这两样东西搭在一起，基本是开源生态里最经典、最能打的高可用组合之一。本文把这些年实际部署keepalived+LVS的经验整理出来，重点讲清楚DR模式下数据怎么走、keepalived配置里哪些参数是命门，以及一套可以直接抄写的Rocky Linux 9实操配置。如果你正准备给Nginx、给数据库读入口、甚至给K8s多master集群搭一个统一接入层，这篇内容应该能帮你少踩一半的坑。
1. 为什么是 keepalived+LVS，而不是别的方案？
先说结论：在高并发四层接入层这件事上，LVS跑在内核态，性能天花板远高于Nginx和HAProxy的用户态转发。Nginx的七层转发强在协议理解，能读写HTTP头、能根据URL路径分发，但每来一个连接都要建立完整TCP会话，CPU开销不小。HAProxy同样优秀，但性能表现还是受制于单进程事件循环的用户态开销。LVS则直接把转发规则放进内核的ipvs模块，数据包到了网卡之后，内核按规则直接改MAC、改IP、转发出去，几乎不经过应用层。做运维这么多年，我最直观的感受是：普通物理机上，LVS撑住几十万并发TCP连接是很稳的事，而用Nginx或HAProxy跑到这个量级，CPU会先拉警报。
再看keepalived，它解决的是高可用的另一半——VIP漂移。在keepalived+LVS架构里，一台服务器作为入口承载所有流量还不够，这本身就是一个单点。于是我们用两台机器跑同一个虚拟IP（VIP），正常情况下VIP落在主节点上，主节点挂了之后VIP在几秒内切换到备节点，由备节点接管转发工作。这个切换逻辑依赖VRRP协议，keepalived就是VRRP协议在Linux下的标准实现。为什么选它而不是自己写脚本？因为VRRP本身就是为这种场景设计的标准协议，通告报文、优先级选举、故障探测都是现成的，keepalived把这些封装成几行配置，比手写一套心跳逻辑靠谱得多。
那这个组合适合什么场景？我常用的判断标准有三条：
- 后端是无状态服务或者状态已经外置（session放Redis/数据库），因为四层转发只认IP和端口，不关心应用层内容。
- 流量规模大，QPS过万、连接数过十万，需要在更靠近内核的地方完成分发。
- 已经有一套七层负载均衡或应用网关，只需要在前面再架一层四层入口，做流量收口和高可用兜底。
比如给K8s集群的多台master节点做统一接入，用LVS+keepalived把VIP指给多个master的API Server端口，比用云厂商负载均衡或者自建Nginx都更直接。K8s三台master的高可用，本质就是让API Server不因为一台机器宕机而不可用，keepalived在这里当虚拟入口，背后三个master轮流接包，就是一个非常典型的落地场景。当然，这不代表Nginx和HAProxy没用，七层场景里它们依然是最重要的组件，但在四层高可用这一层，keepalived+LVS是绕不开的选择。
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无缝漂移到了备机。
配置里最需要理解的是虚拟路由ID（virtual_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漂到master02，Kube-apiserver继续被访问。整个集群对调用方而言，始终是同一个VIP、同一个端口。
3. 从零到一：Rocky Linux 9 环境下的完整实操配置
3.1 规划环境
尽量用真实验证过的环境来写。我最近在一套Rocky Linux 9.3的环境里重新搭了一整个keepalived+LVS集群，下面这份配置和命令都是从这套环境里摘出来的。拓扑如下：
| 角色 | 主机名 | IP地址 | 系统 | 安装组件 |
|---|---|---|---|---|
| LVS主节点 | lvs01 | 192.168.1.10 | Rocky Linux 9.3 | keepalived、ipvsadm |
| LVS备节点 | lvs02 | 192.168.1.11 | Rocky Linux 9.3 | keepalived、ipvsadm |
| VIP（虚拟IP） | — | 192.168.1.100 | — | — |
| Nginx后端1 | web01 | 192.168.1.20 | Rocky Linux 9.3 | nginx |
| Nginx后端2 | web02 | 192.168.1.21 | Rocky Linux 9.3 | nginx |
这里强调一下，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发行版对网卡名处理有差异，全接口设置最稳妥。
然后给后端在回环接口上绑定VIP：
ip 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_02，state改成BACKUP，priority改成100。virtual_router_id保持51，IP和端口规则一致，这个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 (size=4096) 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协议（协议号112），VIP漂移等了十几秒都没动静。如果你也遇到同样情况，记得两台机器都执行：
firewall-cmd --permanent --add-rich-rule='rule protocol value="vrrp" 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 2>&1; 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_CHECK：
real_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.0；session要外置；健康检查接口要独立于业务逻辑、不能被慢查询拖死；服务优雅上下线要能配合健康检查窗口。
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 snooping，VRRP的默认组播地址224.0.0.18可能被丢弃。这时可以把keepalived的VRRP通信改成单播模式，在vrrp_instance里指定对端IP：
unicast_src_ip 192.168.1.10 unicast_peer { 192.168.1.11 }这样两节点之间用单播报文通信，不再依赖组播，能绕开一大类组播环境问题。还有keepalived配置文件里的vrrp_strict选项，它会自动配置一套iptables规则拦掉非VRRP的组播流量，严谨但容易和业务防火墙策略打架，我默认从不开启。
关于忽略IP，keepalived对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. 写在最后的经验
把keepalived+LVS玩到顺手之后，你会发现高可用这件事的重心早就不在“配置怎么写”上，而在“故障发生时怎么让人无感”。我个人的体会有几条比较重要。第一，任何高可用方案都不能只验证“宕机后VIP能漂移”，一定要演练“恢复后VIP能漂回来”。很多团队只做了前者，结果主节点恢复后因为priority更高，又把VIP抢回来，刚好把正在处理的连接掐断。第二，加缓存层和限流越早越好，因为有了keepalived+LVS后，迁移后端机器变得非常方便，但后端被摘掉后如果直接冲垮了数据库，高可用就成了一句空话。第三，观察从VIP进来的流量分布，永远比盯着各家监控面板更真实。舍得在服务器上装好netdata或Prometheus，等到压测或故障演练时，你能看到的东西会比预期多得多。
还有个小技巧：生产环境的keepalived配置文件最好纳入git管理，改完配置先执行keepalived -t -f /etc/keepalived/keepalived.conf做语法校验，再重启服务。这个-t参数能拦住绝大多数“exited with permanent error config”的尴尬事。多机环境里，任何对主节点的操作都要想想会不会触发备机接管，不要一边改配置一边线上压测，否则你看到的可能是VRRP抢占带来的抖动，而不是你的压测数据本身。
