企业官网建设流程全解析

《弦绝九章·高可用篇：Keepalived虚拟IP漂移秘术》

搞高可用的人，早晚都会撞上“虚拟IP漂移”这个词。我第一次接触Keepalived的时候，还以为“漂移”是什么玄之又玄的黑科技，后来真刀真枪在线上环境配完、压测、杀进程、看VIP切换，才明白这玩意儿说白了就一句话：让一组机器对外共用一个IP地址，谁活着谁就把它穿在身上。这篇文章不绕弯子，直接讲清楚Keepalived虚拟IP漂移的原理、配置、避坑和排障，适合正在搭Nginx高可用、Redis高可用、数据库读写分离入口，或者被领导要求“把单点干掉”的运维和后端同学。看完你不仅能自己搭一套能用的环境，还能跟人聊明白“漂移”到底在漂什么。

1. 虚拟IP漂移到底在解决什么问题

1.1 单点故障才是高可用的头号敌人

先别急着敲命令，想清楚“高可用”这三个字的含义。所谓高可用，不是说系统永远不会挂，而是说系统挂了之后，对外服务不能跟着一起挂。比如你有一个Nginx负载均衡器，业务全靠它转发流量，这时候机器宕机、网卡故障、机房断电，只要任何一件倒霉事发生，整个业务就断了。这种架构就是典型的单点故障，单点不解决，后面谈什么容灾、弹性都是空话。

最简单也最经典的解法，就是再加一台机器，组成一主一备。但加机器容易，有个麻烦事随之而来：客户端访问你的时候，总得有一个固定的地址吧？你要么让客户端感知到后端有两台机器，自己切来切去；要么就提供一个“看起来永远不变”的入口地址，谁提供服务谁就把这个地址“带”过去。前一种方案听着合理，但让所有调用方感知后端变化，在现实里就是灾难，尤其是老系统、第三方回调、白名单场景，根本改不动。后一种方案，就是虚拟IP（VIP）的核心思想：对外只暴露一个逻辑地址，内部谁接管它，由高可用软件说了算。

这个“谁接管它”的交接动作，就是所谓的漂移。Keepalived做的正是这件事——它让多台机器共享一个虚拟IP，正常情况下由Master节点持有，Master挂了，Backup节点检测不到它的心跳，立刻把VIP抢过来绑定到自己网卡上，对外继续提供服务。整个过程对客户端完全透明，客户端甚至不会察觉到网络层发生了什么。

1.2 漂移的本质：让“入口地址”跟着活着的节点走

把虚拟IP漂移拆开看，其实由三个动作组成：探测、抢占、通告。

探测的目的是搞清楚“当前持有VIP的那台机器还活着吗”。Keepalived默认用VRRP协议的心跳报文来做检测，主备节点之间周期性地互发报文。只要Backup能持续收到Master的通告，就说明Master还健在，自己老老实实待着就行。一旦一段时间内收不到，Backup就会认为Master挂了，进入抢占流程。

抢占不是简单地把IP配到网卡上就完事。这里有个特别容易被忽略的环节：ARP通告。整个局域网里的交换机、路由器、其他服务器，都维护着一张ARP缓存表，里面记录着“这个IP对应哪个MAC地址”。VIP从A机器漂到B机器，意味着持有VIP的MAC地址变了，但大家缓存里的老MAC还指向已经宕机的那台机器。如果不主动广播ARP更新，哪怕B机器已经把IP绑定到自己网卡，进来的流量还是会往坏掉的A机器上送，等于白漂移。

所以Keepalived在新节点抢占VIP之后，会主动发送 gratuitous ARP（免费ARP）报文，告诉整个广播域“这个IP的MAC已经换成我了，你们赶紧更新缓存”。这一步做得到不到位，直接决定了漂移是秒级完成还是半天切不过来。实际排障时遇到“VIP已经到备机了，但业务就是不通”，十有八九是ARP缓存或者交换机MAC表项在作怪。

1.3 不止Keepalived：k8s、Redis、Nginx里的同款思路

有意思的是，只要你理解了虚拟IP漂移，再看其他中间件的高可用方案，会发现都是同一个套路。Redis哨兵模式里，主节点挂了之后从节点被提升为新主，客户端需要重新感知到新的主节点地址，这和VIP漂移是同一个问题，只不过Redis用的是“通知机制”而不是网络层的VIP切换。Kubernetes里三台Master怎么保证高可用？从KubeVIP、MetalLB到云厂商的SLB，本质上仍然是在多个Master前面放一个漂移的虚拟IP，或者用负载均衡器把443/6443端口导到健康的那一台。

后端写代码的同学看到这里也别觉得与自己无关。在服务高可用场景下，后端代码需要注意的点往往比运维配置更细：比如VIP漂移瞬间，本机持有的长连接可能被RST重置，代码里要有重试机制；再比如用Java的Jedis连接Redis主从时，主从切换会导致部分连接失效，需要配置合理的连接池验证和重连逻辑。高可用从来不是某一个组件的事，从网络层到应用层都要配合好。

2. Keepalived核心原理：VRRP协议与优先级的博弈

2.1 VRRP是什么，为什么高可用场景偏爱它

VRRP全称是Virtual Router Redundancy Protocol，虚拟路由冗余协议。它最初是给路由器设计的，解决的是“默认网关挂了怎么办”的问题——一组路由器共享一个虚拟IP，Master路由器负责转发数据，Backup路由器在Master宕机后接替工作。Keepalived把VRRP的能力挪到了服务器上，让一组普通Linux机器也能具备这种“路由器级”的故障切换能力。

和另一类常见的高可用思路相比，VRRP有一个非常突出的优势：它工作在OSI模型第三层，不需要上层应用配合。像Heartbeat或Pacemaker这类方案，经常要监控进程、文件系统、数据库实例，切换逻辑复杂，配置项也多。而Keepalived只用VRRP报文就能完成主备选举和VIP漂移，链路非常短，故障切换通常在1到3秒内完成。对于大多数Web服务、负载均衡器、缓存入口来说，这个速度完全够用。

还有一个容易被忽略的点：VRRP本身设计时就考虑了多台设备共享一个虚拟IP的场景，支持多Master组，最大255个优先级。所以Keepalived不只是能做一主一备，还可以搞一主多备、多主多备的复杂拓扑。你甚至可以定义多个VRRP实例，让A机器在实例1里当Master、在实例2里当Backup，实现流量的双向负载，这就是后面要说的双主模式。

2.2 VIP漂移的完整过程：从选举失败到MAC地址切换

用一个具体场景把整个漂移过程走一遍。假设你有两台机器：

• node1：优先级150，配置成MASTER
• node2：优先级100，配置成BACKUP
• VIP：192.168.100.100

正常状态下，node1持有VIP，网卡上同时存在两个地址：真实IP（比如192.168.100.11）和虚拟IP（192.168.100.100）。node2持续监听VRRP组播报文，确认node1活着，自己保持沉默。

这时候node1因为内核panic宕机。node2在连续几个通告周期内（默认是3个，每个1秒）都没收到node1的VRRP报文，就会认定Master失联，进入MASTER状态。紧接着node2做三件事：第一，把VIP绑定到自己的网卡上；第二，调用脚本更新ARP表；第三，发送免费ARP报文通知局域网内所有设备“VIP的新MAC是我”。

这三步里，第二步最容易被忽视。Keepalived本身在切换VIP后会触发arp_gratuitous机制，但如果你用了自定义脚本管理IP，或者跑在云环境里、虚拟化平台上，MAC地址的广播可能会被交换机安全策略拦掉，结果就是VIP虽然绑上去了，但流量进不来。这也是我为什么在后面的排障章节里专门把ARP问题列出来的原因。

2.3 关键参数解读：priority、vrrp_interval、nopreempt

配置Keepalived其实不难，难的是理解每个参数背后的取舍。

priority是主备选举的核心依据，范围1到255，数值越大优先级越高。在同一个VRRP实例里，优先级最高的节点会成为Master。如果两台机器配置了相同的优先级，那么IP地址更大的那台获胜。这里有个实战经验：不要把Master的优先级设成255，也不要让备机的优先级低于50。255意味着即便你后来把一台更高配置的机器加进来，也永远无法通过正常选举机制成为主节点；低于50则可能在某些网络抖动场景下被其他实例误伤。

vrrp_interval（通告间隔）决定了Keepalived多久发一次VRRP报文。默认是1秒，配合默认的3次丢包判定，故障切换时间大约是3到4秒。想切得更快可以把间隔调到0.5秒，但代价是VRRP报文占用的组播网络流量翻倍。我的建议是：普通业务保持1秒，延迟敏感型业务可以调成0.2秒到0.5秒，但前提是你的交换机对组播洪泛不敏感，否则反而会引发网络风暴。

nopreempt是一个特别容易踩坑的选项。默认情况下，Keepalived开启了抢占模式，也就是说，如果node1（优先级150）恢复上线，它会立刻把VIP重新抢回来。听起来很合理对吧？但在生产环境里，这个行为可能导致VIP在短时间内来回漂移两次：node1宕机 -> node2接管 -> node1恢复 -> node1抢回VIP -> node2退出。每次漂移都伴随ARP广播，整个局域网的转发路径都要重新收敛。如果业务连接比较多，切来切去反而是灾难。设置nopreempt可以避免这种现象，但需要注意，nopreempt必须在配置文件的全局段配置，并且只对设置为BACKUP的节点生效，不是写在哪个实例里都行的。

3. 从零搭建Keepalived虚拟IP漂移环境（Rocky Linux 9实操）

3.1 环境规划与安装准备

理论部分聊得差不多了，开始动手。这里我选择Rocky Linux 9作为演示系统，一方面因为它是当前社区活跃度很高的RHEL兼容发行版，另一方面也符合热词里反复出现Rocky Linux 9的实际情况。无论你用CentOS Stream、AlmaLinux还是Ubuntu Server，核心配置思路完全一致，只是安装命令和网卡命名规则略有差异。

准备两台干净的主机，这是最低要求：

两台机器需要在同一广播域内，确保它们之间可以互相收到VRRP组播报文。如果中间隔着三层路由，VRRP默认的组播模式就行不通了，得改用单播模式（后面会说）。另外，建议在正式操作前先把两台机器的防火墙放行VRRP协议，Rocky Linux 9默认用的是firewalld，执行：

firewall-cmd --permanent --add-rich-rule='rule protocol value="vrrp" accept' firewall-cmd --reload

这里的rich rule比直接添加服务更准确。注意，VRRP在IP协议族里的协议号是112，而不是某个TCP/UDP端口。如果你用的是iptables，对应的规则是-p vrrp -j ACCEPT。

禁用SELinux或者放行相关域，看你的策略。测试环境我通常直接setenforce 0，生产环境建议还是按最小权限来放，别一刀切。

然后安装Keepalived：

dnf install -y keepalived

安装完先别急着改配置，默认的/etc/keepalived/keepalived.conf可以拿来当模板看，但生产环境一般都会重写成自己需要的格式。

3.2 配置文件逐行解读与部署

很多人喜欢从网上复制一段配置就往上贴，结果出问题了不知道从哪查。我这里把两份配置完整贴出来，逐段解释为什么这么写。

node1（MASTER）的/etc/keepalived/keepalived.conf：

global_defs { router_id node1 vrrp_skip_check_adv_addr vrrp_strict vrrp_garp_master_refresh 60 vrrp_garp_master_refresh_repeat 2 enable_script_security script_user root } vrrp_script chk_nginx { script "/etc/keepalived/check_nginx.sh" interval 2 timeout 3 weight 20 rise 2 fall 3 } vrrp_instance VI_1 { state MASTER interface ens192 virtual_router_id 51 priority 150 advert_int 1 authentication { auth_type PASS auth_pass 8f3A2k9Q } unicast_src_ip 192.168.100.11 unicast_peer { 192.168.100.12 } virtual_ipaddress { 192.168.100.100/24 dev ens192 label ens192:1 } track_script { chk_nginx } }

node2（BACKUP）的配置，只把state改成BACKUP、priority改成100、unicast_src_ip和unicast_peer对调即可。

逐项解释关键点：

router_id是标识本机在VRRP域内唯一性的字符串，建议和主机名对应，方便日志排查。

vrrp_strict这个选项要特别小心。它会让Keepalived严格遵守VRRP RFC规范，比如禁止VIP和真实IP相同、不允许配置IPv6地址和IPv4地址混用等。好处是能避免很多合法性错误，坏处是某些场景下会拒绝不标准的配置。如果后面启动报错提示“Received an invalid advertisement”，多半就是vrrp_strict在较真。

vrrp_garp_master_refresh 60配合vrrp_garp_master_refresh_repeat 2，意思是当节点成为Master后，即使没有任何切换事件，每60秒也会主动发送2次免费ARP。这个参数是我强烈建议加上的。因为现实中的交换机、物理机、云平台的ARP表项都有老化时间，有的还不按标准走，主动刷新能避免“VIP明明在这台机器上，但流量总是绕到老地址”的诡异问题。

vrrp_script定义了一个健康检查脚本，用于追踪Nginx进程是否存活。这里的weight 20很关键：当脚本检查失败时，当前节点的优先级会减去20。对node1来说，优先级从150变成130，仍然大于node2的100，所以并不会触发切换；但如果你把node1的优先级只设为105，脚本一失败优先级就变成85，低于node2的100，VIP就会漂到备机。很多人不理解weight的作用，其实它让Keepalived从“网络层探测”升级到了“应用层探测”，这才是它真正有价值的地方。

advert_int 1就是前面说的通告间隔，单位是秒。virtual_router_id 51用来在一个局域网内区分不同的VRRP组，范围0到255，同一个组内的机器必须一致。两台交换机、两套Keepalived组如果id一样，就会互相干扰，这是个很容易犯的低级错误。

虚拟IP的写法192.168.100.100/24 dev ens192 label ens192:1，意思是将VIP绑定到ens192网卡上，并给它起一个子接口别名ens192:1。为什么要显式指定label？因为有些系统默认不给虚拟IP创建接口别名，后面你要抓包、看流量统计时会非常不方便。

3.3 启动、验证与手动触发漂移

配置文件写好后，先做语法检查：

keepalived --config-test -f /etc/keepalived/keepalived.conf

这条命令在Rocky Linux 9上如果配置正确，会输出类似Configuration file /etc/keepalived/keepalived.conf syntax: OK的结果。注意keepalived版本不同，输出格式有差异，只要没有ERROR字样就算过。

然后启动服务并设置开机自启：

systemctl enable --now keepalived

验证当前谁持有VIP：

ip addr show ens192

在node1上应该能看到192.168.100.100，在node2上则不应该看到。如果想验证漂移，在node1上直接停掉Keepalived：

systemctl stop keepalived

过大约3到4秒，到node2上再看ip addr，VIP应该已经出现在ens192接口上了。同时，用tcpdump抓包的话，能看到node2发出了免费ARP报文。

从node2上再执行：

ping -c 3 192.168.100.100

如果通，说明VIP漂移成功，流量已经能够打到这台新Master上。

这一步看似简单，其实已经涵盖了整个虚拟IP漂移闭环的核心：健康探测、状态切换、VIP绑定、ARP通告、业务连通。

4. 生产环境中的避坑指南与细节打磨

4.1 脑裂是最大风险：健康检查脚本必须认真写

前面提到用vrrp_script做应用层健康检查，这里必须展开讲。因为很多人配置完Keepalived，只依赖VRRP组播探测来判断对方是否存活，这在实际生产里远远不够。

设想一个场景：node1的Nginx进程突然挂掉，但操作系统还活着，网卡也正常，VRRP报文照发。此时node2收到的心跳一切正常，它就永远不会接管VIP。结果是什么？VIP还在node1上，但业务已经断了。这才是真正的“沉默故障”。

为了避免这种情况，你需要一个脚本，定期检查关键进程是否活着。我自己的/etc/keepalived/check_nginx.sh长这样：

#!/bin/bash if [ "$(ps -C nginx --no-header | wc -l)" -eq 0 ]; then exit 1 fi exit 0

更严格的场景，我还会加上TCP端口探测：

#!/bin/bash curl -sf -o /dev/null http://127.0.0.1/health_check || exit 1 exit 0

第二种方式连应用是否真的能响应请求都验证了，比单纯数进程可靠得多。代价是每2秒多一次HTTP请求，对本地来说压力可以忽略不计。

脚本写好后要赋予可执行权限，并确保脚本里的路径和命令能在非交互shell中执行。经常有人脚本单独跑没问题，放进Keepalived里就不生效，多半是因为脚本依赖了某个环境变量或PATH路径，而Keepalived调用脚本时环境极其精简。

还有一个容易被忽略的点：脚本运行超时时间必须小于advert_int与interval的乘积。比如interval 2、timeout 3意味着每2秒跑一次，单次最多跑3秒。如果脚本卡住了3秒还没返回结果，Keepalived会杀掉它并视为检查失败。所以脚本里千万别写sleep 10这种操作。

4.2 preempt与nopreempt的选择，别让VIP来回跳

上一节说过nopreempt的作用，这里用实际场景再补一刀。

默认配置下，如果node1宕机后快速恢复，VIP会经历“node1 -> node2 -> node1”的两次漂移。第二次漂移是完全没必要的，甚至可能造成服务中断。因为当node1重新上线并抢回VIP时，node2上的连接状态（特别是长连接）全部要重置。

解决方案有两种：

方案一：在全局段加nopreempt，并同时将两台机器的state都设为BACKUP。是的，你没看错，nopreempt生效的前提是所有节点都不是MASTER，或者说是“靠优先级和选举结果来决定最终状态，而不是靠配置里的state硬性指定”。这样配置后，Master节点出故障被Backup接管，即使Master恢复了，它也会延迟一段时间（默认是advert_int的三倍）再抢回VIP，避免频繁切换。

方案二：合理利用weight。给node1的检测脚本设置一个负权重，让脚本失败时优先级降到比node2低，触发切换。当脚本恢复时，node1的优先级自动恢复，若仍然高于node2，VIP又会漂回来。这种方案适合“进程故障后能自动恢复”的业务，比如systemd自动拉起Nginx的场景。

没有绝对的银弹，关键是想清楚你的业务是“故障恢复后希望立刻回到原来的机器”（比如为了保持数据本地性），还是“尽量不要动，谁活着谁干”（比如避免连接重置）。我个人的习惯是：能保持稳定就不折腾，nopreempt是默认选项。

4.3 虚拟化环境下的MAC地址与ARP缓存问题

跑在虚拟机、云主机、容器平台上的Keepalived，经常遇到一个诡异问题：VIP明明漂移成功了，但外部访问还是不通，或者时通时不通。

原因多半出在虚拟化平台的MAC地址机制上。以VMware为例，虚拟机网卡的MAC地址是固定的，但VIP漂移仅仅是把IP地址绑定到另一台机器的网卡上，源MAC地址自然就变成了另一张网卡的MAC。某些虚拟交换机开启了端口安全或MAC地址限制，会拒绝接收源MAC变化的数据包。解决办法是在虚拟交换机或者宿主机层面做调整，让对应端口允许MAC地址变化，或者直接把VIP所在的子网划分到一个VLAN里，减少跨交换机的ARP泛洪问题。

云环境里更要注意。云平台一般不允许你随意配VIP，因为整个网络是SDN软件定义出来的，经典Keepalived的上行ARP广播可能直接被拦截。在AWS、阿里云这类环境里，用云厂商自带的SLB/浮动IP服务才是正道，而不是硬上Keepalived。这跟热词里那些k8s高可用方案思路完全一致——顺势而为，选对工具比炫技重要。

其实Windows环境下也能用到类似的思路。热词里提到“Windows网卡顺序漂移错乱”，实际上就是在网卡重启或者系统恢复后，网卡绑定顺序变了，导致服务监听在错误的接口上。处理办法通常是写脚本固定网卡绑定顺序，或者用netsh命令重置网络配置，核心思路也是“把动态变化收敛成确定性状态”。

4.4 日志、抓包与排障三板斧

生产环境出了问题，第一步必然是看日志。Keepalived的日志在Rocky Linux 9上默认交给journald管理：

journalctl -u keepalived -f

注意观察这几类信息：

• Entering MASTER state：本机成为主节点
• Entering BACKUP state：本机退居备节点
• VRRP_Instance(VI_1) removing protocol VIP：VIP被移除
• VRRP_Instance(VI_1) sending gratuitous ARP on ens192：正在发送免费ARP

如果日志里频繁出现received an invalid advertisement，说明两个节点之间的VRRP报文内容不一致，通常是virtual_router_id、authentication密码或者advert_int配置不同。

第二板斧是抓包。VRRP报文在组播地址224.0.0.18上传输，协议号112。用tcpdump直接过滤：

tcpdump -i ens192 vrrp -nn

正常状态下，Master每1秒发一次通告。如果你在备机上完全抓不到任何VRRP包，先查防火墙，再查交换机的组播配置，最后确认网卡是否丢弃了组播包。

第三板斧是看ARP表。在业务侧的机器上执行：

ip neigh show | grep 192.168.100.100

查一下这个IP对应的MAC地址是不是当前Master节点的MAC。如果不是，说明ARP缓存没有刷新，可以用ip neigh flush 192.168.100.100手动刷新，同时排查为什么免费ARP没起作用。这条命令在手，能解决一半的“漂移后不通”问题。

5. 常见问题与排查技巧实录

下面这组问题，全部来自真实运维场景。我按“现象 - 原因 - 处理思路”的格式整理成一张速查表，方便你现场对照。

这几类问题里，出现频率最高的是前三个。说穿了还是对原理的理解不到位。比如两台机器同时持有VIP，其实就是VRRP报文被网络隔离了，两边都认为自己才是唯一的Master，这就是经典的脑裂场景。解决办法不是去抢VIP，而是把网络层修好，让两边能正常看到彼此的通告。

5.1 一次“健康检查脚本不生效”的排查实录

有一次在客户现场，Keepalived配置好之后，我故意把Nginx停掉，等了30秒，VIP纹丝不动。按照配置，脚本应该在2秒内检测到进程消失，然后触发降权、漂移。

排查过程是这样的：先手动执行脚本，输出正常，exit code为1，说明逻辑没错。再看看Keepalived日志，发现脚本压根没被调用。最后把脚本权限翻出来一看，原来从Windows编辑过的文件带上了CRLF换行符，shell执行时把\r当成命令的一部分，导致找不到命令。

解决方法是重新用vi保存成LF格式，然后chmod +x，重启Keepalived，一切正常。从那以后，我对所有从外部编辑器拷贝过来的脚本都会先跑一遍file命令，确认换行符没问题。

这类小坑，比复杂的架构设计更能消耗你的时间。

5.2 别忘了给“漂移过程”加点可观测性

最后说一个很多人不重视但实际非常关键的点：漂移本身也需要监控和告警。

VIP切了，说明发生了故障。无论最终业务有没有恢复，这个事件都值得被记录下来，最好还能自动通知到人。我自己习惯在Keepalived配置里加一个notify脚本，在状态切换时触发，把事件写入日志并推送告警：

notify_master "/etc/keepalived/notify.sh master" notify_backup "/etc/keepalived/notify.sh backup" notify_fault "/etc/keepalived/notify.sh fault"

notify.sh内部可以做三件事：写一条带时间戳的日志；通过curl调用企业微信/钉钉机器人的webhook；更新一个状态文件供监控系统读取。这样每次漂移都有据可查，不用等到用户报障才知道发生了什么。

我把这段脚本当作Keepalived配置的一部分，每次搭建新环境都直接带过去，算是个人项目的必备组件之一。

根据我个人实际操作中的体会，Keepalived虚拟IP漂移真正难的地方从来不是配置文件怎么写，而是你能不能把“网络层的心跳”和“应用层的健康”挂上钩，能不能在切换发生后让整个数据链路快速收敛。脑子里装着VRRP报文、ARP缓存、交换机MAC表这几张图，再复杂的故障也有清晰的排查路径。小技巧方面，建议你搭好环境之后，先做一次完整的“杀进程-看切换-验流量-查日志”演练，把每个步骤的预期输出记下来，后面再出事就能一步到位了。