LVS DR模式与Keepalived高可用集群：原理、配置与避坑指南

聊一个生产环境里很常见的场景：集群规模上来了，流量大了，单台服务扛不住，自然要引入负载均衡。而负载均衡本身如果挂了，整个系统照样瘫。所以负载均衡器也得做高可用。我手上这套方案，核心就是LVS的DR模式，配合keepalived做健康检测和VIP自动漂移。这篇文章我打算把整个链路从原理到配置讲透，适合正在搭集群的运维同学，以及想搞明白LVS和keepalived到底怎么配合的开发朋友。

先说说我为什么选LVS DR模式。LVS有三种工作模式，NAT、TUN和DR。NAT模式最简单，但进出流量都走调度器，压力全在LVS上，带宽和性能容易成瓶颈。TUN模式要封包解包，对内核和网络环境要求高，普通场景有点过度设计。DR模式则完全不同，它只修改数据包的目标MAC地址，不碰IP层和传输层内容，请求进来由调度器分发，响应直接由后端服务器回给客户端。这种“请求走调度，响应走后端”的方式，让调度器只扛请求流量，响应流量不经过它，性能和吞吐量都高很多。我实测过，在同样的硬件条件下，DR模式比NAT模式的并发能力能高出一截，尤其适合视频、下载、API网关这类响应体量大的业务。

但DR模式有个著名的坑，就是ARP问题。后端服务器和调度器共享同一个VIP，如果不做特殊处理，后端服务器会认为自己才是VIP的主人，直接对外宣告自己持有VIP，这样调度器就收不到包了，整个集群就乱了。解决的办法是给后端服务器的回环接口或者别名接口绑定VIP，同时调整内核的ARP参数，让它在广播ARP时保持沉默，只处理数据包不响应ARP请求。这里具体怎么做，我在后面的章节详细拆。

接下来讲keepalived的角色。keepalived的核心功能有两个，一个是通过VRRP协议实现调度器的主备切换，也就是VIP漂移；另一个是健康检查，持续探测真实服务器的存活状态，一旦发现有RS掉线，自动从转发列表里摘掉，恢复后再加回来。这两个功能正好补上LVS单点故障和管理RS列表的短板。所以这套组合拳，才叫高可用集群下的负载均衡。

先说整体设计思路。标准拓扑是这样的：两台LVS调度器，一主一备，跑着keepalived，共享一个VIP。后端若干台真实服务器（RS），也绑定同一个VIP，但只配置在回环接口上，并禁止ARP响应。客户端访问VIP时，请求到达主调度器，主调度器根据自己维护的转发表，把请求发送到某个RS。RS处理完之后，直接把响应包发给客户端，不再经过调度器。

这里有个细节，为什么RS的VIP必须绑定在回环接口而不是物理接口？因为keepalived在调度器上通过VRRP周期宣告VIP，后端RS如果物理接口直接绑VIP，会不停发ARP响应，导致调度器收不到后续流量。而回环接口默认不对外广播ARP，配合内核参数抑制，就能既接收数据包又不暴露自己。我最早踩过这个坑，直接把VIP绑在RS的eth0上，结果整个集群调度器日志全是“neighbor solicitation”报错，客户端间歇性超时。

再说为什么健康检测要写脚本而不是用keepalived自带的状态检查。keepalived自带的有TCP检查、HTTP_GET检查，但只能探测端口通不通、URL返回码对不对。真实业务里，服务可能端口通但进程已经假死，或者依赖的数据库掉了，接口返回503。这时候端口检查完全没反应。我习惯在keepalived的real_server块里用MISC_CHECK调用自定义脚本，脚本去实际请求一次业务接口，或者检查进程状态文件，返回0就健康，非0就摘除。这个能力是keepalived的杀手锏，也是最容易被忽略的。

环境选择上，我用的是CentOS 7，内核版本3.10，LVS用ipvsadm管理，keepalived版本1.4。这套组合在现在的运维场景里依然很主流，而且CentOS 7的包管理直接可以装，不用编译。硬件方面，两台调度器配置不用太高，2核4G足够，后端RS看业务需求。网络必须二层互通，因为DR模式靠MAC地址转发，不能跨路由。

2.1 数据包流转的核心链路

把数据流转拆开看，整个过程分四步。第一步，客户端发送请求，目标IP是VIP，MAC地址是主调度器的网卡MAC。第二步，调度器收到包之后，ipvs模块根据虚拟服务规则，选出一台RS，然后把包的目标MAC改成RS网卡的MAC，源IP、目标IP都不动，直接发出去。第三步，RS收到这个包，发现目标IP是VIP，而VIP正绑在自己的lo:0接口上，于是正常接收并处理。第四步，RS处理完业务，直接把响应包经自己的默认路由发回客户端。客户端看到的就是一个IP对应了多台服务器，完全透明的。

这里有个关键点，数据包到达RS后，RS的内核必须认为这个包是发给自己的，所以VIP必须绑定在RS本地。但绑定在回环接口上有个问题，回环接口的IP在正常情况下不会响应外部ARP，因为回环接口一般不做对外通信。可是如果不做任何配置，RS的lo:0绑了VIP后，它会默认对这个VIP做ARP宣告，导致所有客户端直连VIP时，响应被RS抢走。所以必须调整两个内核参数，arp_ignore和arp_announce。

2.2 arp_ignore和arp_announce的配置逻辑

arp_ignore控制的是本机收到ARP请求时，什么情况下才回应。默认值是0，意思是本机只要任意接口有目标IP，就立即响应。这显然不行，因为RS上挂着VIP，客户端一查VIP的MAC，RS就跳出来说“我在这儿”，可实际流量应该走调度器。所以RS上要把arp_ignore设为1，含义是只响应那些目标IP正好落在请求到达的这个网卡上的ARP请求。但VIP在lo:0上，外部请求到达的是eth0，所以RS对VIP能做到“听而不答”。

arp_announce控制的是本机发ARP请求时，用什么源IP去宣告。默认是0，本机就用自己的IP直出。但RS的eth0上没有VIP，而业务响应会走eth0出去，如果它发ARP请求询问网关的MAC，源地址用了VIP，网关就会把VIP的MAC学成RS，调度器就废了。所以要设为2，意思是只用主网卡上的IP作为ARP源地址，完全忽略VIP。

配置位置在/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

这里有一个细节，光改all还不够，还必须单独指定lo接口。我第一次配置时只改了all，结果lo上的VIP还是照常回ARP，折腾了半天才意识到问题出在这。改完之后执行sysctl -p生效。RS上的VIP绑定，我通常用ip命令，而不是传统的ifconfig，因为ifcfg文件在后续服务器重启时顺序不稳定，容易被NetworkManager干扰。

ip addr add 192.168.1.100/32 dev lo

注意这里掩码是32，不是24。因为VIP是一个单主机地址，不需要和物理网段有从属关系。这个地址只用来接收数据，不做路由宣告。

keepalived的配置文件通常放在/etc/keepalived/keepalived.conf。整个文件分三段，global_defs定义全局日志和通知参数，vrrp_instance定义VRRP协议的VIP和优先级，virtual_server定义LVS后端和健康检测。先看我常用的一套模板。

global_defs { notification_email { ops@example.com } notification_email_from lvs@example.com smtp_server 192.168.1.10 smtp_connect_timeout 30 router_id LVS_MASTER } vrrp_instance VI_1 { state MASTER interface eth0 virtual_router_id 51 priority 100 advert_int 1 authentication { auth_type PASS auth_pass 1a2b3c4d } 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 protocol TCP persistence_timeout 600 real_server 192.168.1.11 80 { weight 1 TCP_CHECK { connect_timeout 3 nb_get_retry 3 delay_before_retry 2 } } real_server 192.168.1.12 80 { weight 2 MISC_CHECK { misc_path /etc/keepalived/check_rs.sh misc_timeout 5 } } }

在vrrp_instance里，state MASTER只是初始状态，真正决定主备的是priority值。主节点priority要大于备节点，这样VRRP选举才会一直选主。virtual_router_id两机必须一致，否则VRRP报文不互通，两边都会认为自己是主，造成VIP冲突。我见过几回因为router_id不一致导致业务中断的事故，所以每次搭集群我都会先在两机上执行ip addr compare，确认没有同时出现VIP。

virtual_server这一段定义的是调度器上ipvsadm的规则。lb_algo wrr表示加权轮询，lb_kind DR表示DR模式。protocol基本都走TCP。persistence_timeout表示会话保持时间，比如电商场景用户要登录保持，600秒是常用值。这个值不能设太大，不然后端扩容后，流量还是压在一两台机器上，负载均衡效果就打折扣。

real_server里TCP_CHECK直接探测后端的80端口，weight是按权重分配请求。MISC_CHECK是调用外部脚本做更细的健康检测。备节点上同样部署这套配置，只需要把state改成BACKUP，priority改成90，其他不变。

3.2 健康检测脚本的关键写法

前面提到MISC_CHECK，现在把脚本写详细。这个脚本的核心逻辑是请求一次业务接口，看响应码和响应时间。我写了一个可复用的例子，放在/etc/keepalived/check_rs.sh。

#!/bin/bash CHECK_URL="http://192.168.1.11:80/healthz" RESULT=$(curl -s -o /dev/null -w "%{http_code}" --connect-timeout 3 --max-time 5 "$CHECK_URL") if [ "$RESULT" -eq 200 ]; then exit 0 else exit 1 fi

这里有几个注意点。curl的--connect-timeout和--max-time必须设，否则后端假死时，脚本会被卡住，keepalived会认为脚本超时，然后误判RS健康。Response code的判断不能只写200，有的接口会返回301或302，需要按业务设计。我习惯在脚本里记录日志，方便排查：

echo "$(date +%F_%T) check_rs result=$RESULT" >> /var/log/check_rs.log

然后给脚本可执行权限，keepalived的进程用户需要能访问。如果脚本需要访问外部依赖，比如数据库或redis，就得更仔细，因为一旦依赖服务整体抖动，可能所有RS都瞬间被摘除，等于把调度器也拖垮。这时我会做“连续N次失败才摘除”的逻辑，比如用临时文件记录失败次数，连续3次才返回非0，避免抖动引发的大面积摘除。

3.3 主备切换的触发机制

keepalived的主备切换靠VRRP报文。主节点默认每1秒发一个VRRP组播包，备节点会持续监听。如果备节点在advert_int的3倍时间内（默认3秒）没收到主节点的报文，就会认为主挂了，然后立即提升自己为主，绑上VIP，接管流量。这个机制很快，正常情况下3秒内切换完成。

但这里有个盲区，如果主节点的keepalived进程活着，网络也通，但ipvs规则被清了，或者后端服务全挂了，VRRP报文照发，备节点永远不会接管。所以高可用不能只靠VRRP，还得在vrrp_instance里配置nopreempt和notify脚本。我的习惯是加一个nopreempt选项，否则主节点恢复后又会把自己切回去，引起二次抖动。同时在global_defs里配置notify，当切换时调用脚本，发出短信或者钉钉通知。

配置如下：

vrrp_instance VI_1 { state BACKUP nopreempt ... notify_master /etc/keepalived/master.sh notify_backup /etc/keepalived/backup.sh notify_fault /etc/keepalived/fault.sh }

nopreempt的含义是即使节点恢复，也不会自动夺回主角色，直到当前主节点再次故障。这个对于双活场景很友好，能减少频繁切换。通知脚本里我一般会记录时间戳和节点hostname，然后调用企业微信或飞书webhook。生产环境里，靠人工发现切换已经晚了，一定要有告警。

实操部分，我直接演示一遍完整流程。先在两台调度机上安装keepalived和ipvsadm，CentOS下的命令：

yum install -y keepalived ipvsadm

后端RS机器只需配置内核参数和绑VIP，不需要装keepalived或ipvsadm。RS上需要开启IP转发吗？不需要，因为响应是直接发出去的，不走本机转发逻辑。唯一要确保的是后端服务的默认网关能指向物理路由器，否则响应包出不去。

然后按顺序操作：

• 第一台调度器，写配置文件，state MASTER，priority 100，启动keepalived。
• 第二台调度器，state BACKUP，priority 90，启动keepalived。
• 检查master上是否有VIP和IPVS规则，执行ip addr show eth0，再执行ipvsadm -L -n。
• 把两台RS绑上lo:0的VIP和ARP参数。
• 从客户端curl VIP，验证业务。

我在实际搭建时，发现按顺序检查的窍门是：先用ipvsadm -L -n看规则，再用tcpdump看RS的ICMP有没有通，最后再验证业务。如果直接curl，遇到超时会误以为配置有问题，浪费时间排查ARP。

RS上绑VIP的命令是临时的，重启就没了。正式环境得把命令写进rc.local或者systemd unit。我用的是/etc/rc.d/rc.local，然后chmod +x这个文件。注意现在系统里rc.local默认没有可执行权限，要手动加。

ip addr add 192.168.1.100/32 dev lo

同时把sysctl的参数持久化在/etc/sysctl.conf里。

接着验证健康检查。我先停掉RS1上的nginx，然后观察master调度器上的ipvsadm规则输出，看到RS1的条目被标红或者直接消失，就说明健康检查生效了。手动恢复nginx，等delay_loop周期过后，RS1重新出现。MISC_CHECK脚本的周期由delay_loop控制，我设的是6秒，所以观察时要有点耐心。

生产里遇到最多的问题，我整理成一张速查表。

对于ARP缓存问题，我在切换后会在客户端机器上执行arp -d，强制重查，但生产环境里不能每台机器手刷，所以要靠交换机的动态ARP学习。把交换机相应VLAN的MAC地址表老化时间调短，比如调到60秒，能减少切换期间的丢包窗口。

还有一个容易忽略的问题，就是RS和LVS之间的时间同步。虽然DR不影响数据内容，但健康检测脚本里如果用了时间戳，或者后端接口校验签名，时间不一致会导致检测失败。我习惯在两台调度机和所有RS上统一部署chrony，同源同步。后来几回线上排查，发现告警都是单机时间偏差导致的误报，所以同步服务必须纳入基础监控。

演示一个故障模拟。我在主调度器上执行systemctl stop keepalived，然后立刻看备机的日志，应该能看到VRRP状态从BACKUP变成MASTER。然后在备机上点击ip addr show eth0，看到VIP已经绑上了，再访问VIP，业务正常。整个切换过程大概2秒到3秒，因为我设了advert_int 1，备机监听到停止后立即接管。如果把advert_int改成0.5，切换会更敏感，但要保证网络延迟小于300毫秒，否则会频繁误判。我一般还是用1秒，稳妥。

故障模拟里最刺激的一次是我在直播活动前夜做演练，把主调度器直接宕机，结果备机5秒没接管，原因是我在VIP绑定时用了eth0:0标签，但备机的eth0接口名在某些云环境里叫ens33，标签没匹配上。这个教训就是，不同环境网卡命名不一致，配置文件写死了interface名就会出事，所以我后来全部改用dev eth0 label的方式，并且每次部署前先ip link确认接口名。

健康检测脚本还有另一个进阶玩法，就是用健康检测结果动态调整权重，而不是简单摘除。我早期做过一套自定义脚本，后端响应时间超过800毫秒就给权重减半，超过2秒就摘除。效果比固定weight好很多，因为服务端性能劣化到挂了之间有很长一段“亚健康”区间，固定检查根本察觉不到。但这里有个复杂度必须提醒，就是避免抖动。如果脚本判断权重的依据太敏感，瞬时高并发会把所有后端权重削到0，然后集群雪崩。所以脚本里要做滑动窗口统计，至少基于最近5分钟的平均值。

我在实际配置vrrp_instance时，也喜欢加一个track_interface，也就是跟踪网卡状态。如果eth0网卡冒烟或link down，keepalived会立即进入FAULT状态，而不是等VRRP超时。这个对于物理网卡故障特别有用。

track_interface { eth0 }

再补一点安全设计。在有防火墙的环境里，VRRP协议使用的是IP协议号112，组播地址是224.0.0.18。如果防火墙策略没放行这个，两边的keepalived根本没法通信，看起来配置都对，但备机就是不管机。另外keepalived配置文件里的auth_pass不要用太简单的，虽然它不是加密协议，只是明文密码用于认证，但太简单的容易被同网段机器干扰。

关于VIP的网段选择，我建议用和物理网段同一个网段，比如我的eth0是192.168.1.0/24，VIP就配192.168.1.100/24。因为DR模式要求调度器和RS在同一个二层网络，VIP若跨网段，交换机路由规则会很麻烦。有些云环境不支持这种“IP漂移但MAC不漂移”的方式，这时候就得改走云厂商的SLB或者四层代理。

我还遇到过一个看起来像玄学的问题，流量大的时候LVS转发正常，但偶尔有几条请求超时。后来排查出来是后端RS的网卡收到了大量arp请求，因为客户端的网关不停地广播查询VIP，而RS上sysctl只改了all但没改lo，导致lo上的VIP偶尔回包。我改完lo的参数后，这个问题再没出现。所以参数配置不是改完就算了，要一行行核对。

继续讲扩展。这套负载均衡架构可以水平扩展，后面加RS只需要在keepalived配置文件增加real_server块，然后reload服务。但注意，keepalived的reload不是热加载，它会短暂释放VRRP角色，造成VIP抖动。我通常的做法是修改完配置文件后，先执行keepalived -t确认语法，再重启服务。重启的窗口非常短，大约几百毫秒，一般业务能扛得住，但核心交易系统就不行了，那样就得用更平滑的架构，比如将规则下发到ipvsadm而不动keepalived进程。

说到ipvsadm，keepalived实际上是把virtual_server配置翻译成ipvsadm规则，所以你可以直接手工执行ipvsadm来调试。比如查看当前连接数：

ipvsadm -L -n --stats

看实时连接：

ipvsadm -L -n --rate

删除某条规则：

ipvsadm -D -t 192.168.1.100:80

这些命令在排查问题时很有用，因为keepalived的规则是动态管理的，手工改规则可能被自动纠正，所以调试最好是直接改配置文件。

关于会话保持的细节，persistence_timeout不只在同一个连接内生效，它会把同一个源IP的请求在一定时间内都发给同一台RS，这本来是好事，但代价是后端RS之间如果没做session共享，用户在切换RS时登录态就丢了。我常用的做法是把它设成600秒，然后后端用redis存session。但如果你后端是无状态接口，可以设成0，让负载更均匀。

再分享一个我几次调整后的经验总结：DR模式只适合流量的入方向需要负载均衡的场景，如果客户端和服务器之间有NAT穿越，或者涉及SSL卸载，那DR模式就不适用了，得走NAT或直连。SSL卸载一般放在后端做，LVS不做七层处理。

关于监控，除了keepalived自身的日志，我还会单独部署一个探针，从外部每分钟访问一次VIP的healthz接口，判断整个集群的“入口健康”。因为keepalived只关心调度器和后端，不关心客户端到VIP的链路。这个外部探针可以从同机房的另一台空跑机器发起，也可以从监控系统直接拉取。我在某平台迁移时就是靠这个外部探针发现了公网路由异常，那个问题keepalived根本感知不到。

还要说一个关于合规和安全的常识，整个集群里所有IP必须规划清楚，我见过有些团队把VIP写在业务配置文件里写死了，结果VIP发生漂移后，业务还在连旧地址，等了半天才发现。这种低级错误其实最好防，把VIP做成一个DNS记录，业务只认域名，不认IP。

最后聊聊工具链。这套架构里，调度器的日志默认在/var/log/messages，里面会记录VRRP状态和健康检查失败信息。为了便于检索，我会在global_defs里配置log facility，然后单独让rsyslog把kern.*和local0.*写到/var/log/keepalived.log，避免和系统日志混在一起。这个做法在后续排障时效率高很多。

再补一个细节，keepalived的virtual_server里可以配置fallback和quorum。比如我的集群只有两台RS，如果一台挂掉，keepalived默认还能继续带流量，但如果你设置了quorum为2，那么RS数不足2时，LVS整体会停止转发。这个功能要谨慎使用，除非你确定两台都挂了宁可不服务也不要只服务一台，否则很容易造成雪崩。

我这套方案已经在线稳定跑了一年多，期间经历了几次接近事故的抖动，每次靠健康检测脚本自动摘除故障RS，以及VRRP秒级切换，业务影响控制在一次连接超时范围内。我自己的体会是，LVS加keepalived这套组合，难点不在装和配，而在细节。尤其是ARP抑制、脚本超时、VIP漂移这些细节点，一旦理解透了，后面所有场景都能举一反三。

如果你正准备在测试环境验证，有个最快捷的方式，就是先起三台虚拟机，一台当调度器，两台当RS，网络都在同一个vlan，按我上面的配置一步步来。第一次跑通后再加第二台调度器，感受一下主备切换的丝滑。整个过程一两个小时能搞定，但踩过的坑能省下线上事故时的一整夜。