RHEL9高可用Web集群：Keepalived+Nginx实战解析

1. 从一次半夜故障说起：为什么我需要给 Web 服务搭一套高可用集群

大概两年前，我们线上有一套访问量还不错的 Web 站点，部署在两台 RHEL 7 服务器上。当时觉得"有两台机器，一台挂了另一台顶上"就是高可用了，结果实际出了事根本不是那么回事。

那天凌晨 2 点左右，监控告警响起来，站点打不开了。我爬起来一看，第一台服务器宕机了，但问题在于——第二台服务器虽然活着，流量却不会自动切过去。因为域名解析指向的是第一台的外网 IP，那台机器没了，整个站点就废了。我手动改 DNS、等解析生效、然后祈祷运营商缓存尽快刷新，前后花了将近 40 分钟才恢复。那个晚上我基本没睡，就在想一个问题：难道就没有一种方案，能让故障发生时流量自动切换、用户几乎无感知吗？

后来我在 RHEL9 上重新设计了这套 Web 集群架构，核心思路就是两条：VIP 漂移 + 负载均衡探活。用 Keepalived 做虚拟 IP（VIP）的主备切换，用 Nginx 做后端 Web 服务器的负载均衡和健康检查。架构调整之后，我又做了多轮故障演练，单台 Web 节点宕机时，整个服务中断时间从原来的 40 分钟降到了 5 秒以内，而且完全不需要人工介入。

这篇文章就把这套"基于 RHEL9 的高可用 Web 集群架构"完整拆开来讲，包括为什么这样设计、每一步怎么做、踩过哪些坑，以及故障切换的实测数据。适合正在负责 Web 服务部署和运维的工程师、想系统学习 Linux 高可用集群的中级开发者，还有被"服务高可用"折腾过、想找个可靠方案的团队参考。

2. 架构总体设计：VIP、Keepalived 与 Nginx 各自扮演什么角色

2.1 双机热备的核心思想：不要让用户直接感知服务器 IP

高可用架构要解决的核心问题，是"当一台服务器不可用时，系统仍然对外提供服务"。很多人第一反应是"多加几台服务器不就行了"，但问题在于：服务器加了，用户访问请求怎么知道该往哪台发？

最原始的做法是改 DNS，但 DNS 生效有延迟，而且不可控。所以业内更通用的方案是引入一个虚拟 IP（VIP）。用户访问的始终是 VIP，而 VIP 本身不绑定在某台物理机器上，它由 Keepalived 协议动态管理：正常情况下 VIP 绑定在主节点上，一旦主节点出故障，VIP 自动漂移到备用节点上。用户侧完全无感——因为 IP 没变，变的只是背后处理请求的物理机。

整个架构可以分成三层：

需要说明的是，这套架构中 Keepalived 和 Nginx 可以部署在同一组机器上，也可以分层部署。我实际落地时用了"两台机器同时跑 Keepalived + Nginx"的模式：两台机器组成主备关系，VIP 在主节点上，Nginx 同时负责把请求转发给自身和后端的 Web 应用节点。这样节省了机器资源，也足够满足大部分中小规模业务的可用性需求。

2.2 为什么选型 Keepalived + Nginx，而不是其他方案

关于高可用负载均衡方案，业内选择其实不少。硬件上有 F5、A10，软件上有 Keepalived + Nginx、HAProxy、LVS，往上层走还有 Kubernetes Service 和各类云负载均衡产品。我最终在 RHEL9 上选择了 Keepalived + Nginx，核心原因是：

• Keepalived 实现的是 IP 层面的故障转移，原理简单、行为可控。 它基于 VRRP（虚拟路由冗余协议），本质上就是多台机器"抢"同一个虚拟 IP，抢到的就是主节点。出问题时 VIP 自动切走，背后逻辑不复杂，出了问题也好排查。
• Nginx 做七层负载均衡，灵活度最高。 可以按 URI、域名、请求头做转发规则，可以精细控制超时和重试逻辑，对 HTTP Web 服务支持非常成熟。
• 完全开源，而且 RHEL9 的软件源里直接有对应包，离线环境也好处理。 不像商业硬件那样有高昂成本，也不像某些云产品那样绑定特定平台。

事实上，LVS 做四层负载均衡性能确实比 Nginx 高，但配置和调试复杂度也高一个量级。如果你的业务就是普通 Web 站点、API 服务，而不是千万级并发接入，Nginx 完全够用。再往上走，等业务量真的大到 Nginx 成为瓶颈了，再在前面加一层 LVS 或迁移到 Kubernetes 也不迟。

2.3 这套架构能解决什么、不能解决什么

必须坦白说，Keepalived + Nginx 解决的是入口高可用和流量分发两个问题，它不负责数据一致性。比如你的 Web 应用需要读写数据库，数据库挂了，这套架构一点办法都没有——你总不能让两台 Nginx 帮你把 MySQL 数据也变出来吧。所以这里需要区分清楚：

• 能解决的问题：单台 Nginx 节点宕机、单个 Web 节点宕机、VIP 所在机器网卡故障等场景下，服务访问不中断或中断时间极短。
• 不能解决的问题：后端数据库、缓存（Redis）、消息队列等有状态组件的故障。这些组件的高可用需要各自独立设计，比如数据库做主从复制 + 自动切换，缓存用 Redis Sentinel 或 Cluster。架构设计时一定要把这些层分开规划，不要指望一套 Web 集群把所有可用性都扛下来。

我用一句话总结这套架构的定位：它是 Web 服务层"无状态"部分的高可用方案，负责让用户请求在故障发生时仍然有节点可打、有路径可达。 有状态的部分，需要在这个架构之上另行设计。这也正是很多团队容易做混的地方——把高可用和负载均衡混为一谈，忽略了数据层的独立性。

3. 基础环境准备：三台 RHEL9 节点的初始化与网络规划

3.1 节点规划与选择

我实际搭建的时候用了三台 RHEL9 虚拟机，各自角色分配如下：

VIP 地址我规划为 192.168.10.100。这个 IP 不预先绑定在任何一张物理网卡上，而是由 Keepalived 动态管理。

这里有个规划细节值得注意：主备负载节点的硬件配置尽量一致，避免出现"主节点挂了，备节点因为性能差太多而撑不住"的尴尬情况。我见过有团队主备机器配置差了一半，演练的时候主节点一切过去，备节点直接 CPU 打满，比不切还糟糕。

3.2 主机名与 hosts 解析

集群内节点互相通信时，强烈建议用主机名而不是 IP 访问，尤其是 Nginx 配置 upstream 后端节点时，用主机名会让配置可读性和可维护性提升很多。先设置每台机器的主机名：

bash复制# lb01 上
hostnamectl set-hostname lb01
# lb02 上
hostnamectl set-hostname lb02
# web01 上
hostnamectl set-hostname web01
# web02 上
hostnamectl set-hostname web02

然后在所有节点上编辑 /etc/hosts，加入以下内容：

bash复制192.168.10.10 lb01
192.168.10.11 lb02
192.168.10.20 web01
192.168.10.21 web02

这步虽然简单，但很容易被忽略。特别是在 RHEL9 上，如果系统启用了 systemd-resolved 或 NetworkManager 的 DNS 覆盖，hosts 文件解析优先级可能不如预期，你会发现 ping 主机名偶尔能通偶尔不能通。所以配置完之后一定要用 getent hosts lb01 验证一下解析结果。

3.3 RHEL9 特有的初始化设置：防火墙、SELinux 与时钟同步

RHEL9 不像 CentOS 7 那样开箱即用，默认防火墙规则非常严格，而且 SELinux 默认是 enforcing 状态。这两个东西如果不处理好，你配置了半天，最后发现 VIP 漂移了但服务就是不通，会非常折磨人。

防火墙放行 VRRP 协议

Keepalived 的 VRRP 协议不走 TCP/UDP 端口，它直接基于 IP 协议号 112 通信。如果用 firewalld，需要放行 vrrp 协议：

bash复制firewall-cmd --permanent --add-protocol=vrrp
firewall-cmd --reload

如果后端 Web 节点和负载层之间还有防火墙，也要放行 Nginx 转发用的端口（通常是 80/443）。我习惯把这条规则写在所有节点上，避免后续加节点时忘记配置。

SELinux 处理思路

关于 SELinux，我的态度是：不要无脑关闭，但也不要让它成为排查问题的黑洞。如果只是内网环境搭建集群做技术验证，可以把 SELinux 设为 permissive 来降低初期配置复杂度；如果是生产环境，建议保持 enforcing，但要确保 Nginx、Keepalived 相关的 boolean 值设置正确。

bash复制# 临时查看 SELinux 状态
getenforce
# 临时设为 permissive（重启失效）
setenforce 0
# 永久修改
sed -i 's/^SELINUX=enforcing/SELINUX=permissive/' /etc/selinux/config

之所以建议 permissive 而不是 disabled，是因为完全关闭 SELinux 在某些安全扫描和等保测评里会比较扎眼，而 permissive 只记录不拦截，既能快速定位问题，又不会影响服务运行。

时钟同步

高可用集群对时间同步要求很高，特别是日志排查的时候，两个节点时间差超过 30 秒，你看着日志完全对不上号，非常痛苦。RHEL9 默认安装了 chrony：

bash复制systemctl enable --now chronyd
chronyc sources -v

这一步没太多技术含量，但属于"不做后面必坑"的典型。两台机器时间差太大会导致 VRRP 报文计算和日志分析出问题，千万别忽略。

4. Keepalived 配置核心：VRRP 协议、健康检查脚本与优先级设计

4.1 安装 Keepalived 并理解 VRRP 的工作机制

RHEL9 的软件源里自带了 Keepalived，安装很简单：

bash复制dnf install -y keepalived nginx

在配置之前，必须先理解 VRRP 协议的基本行为，不然配置出错你都不知道该查哪里。

VRRP 的核心是一个"抢 VIP"的过程。集群中多台 Keepalived 节点会定期互相发送 VRRP 广播报文，报文中携带各自的优先级（priority）。优先级最高的节点会成为 Master，负责绑定 VIP 并对外提供服务；其他节点是 Backup，处于监听状态，一旦在一段时间内（master_down 间隔）没有收到 Master 的广播报文，就会自动接管 VIP。

这个机制有几个关键参数：

需要特别注意的是，state 参数只是初始状态，真正决定谁是 Master 的是 priority 数值。即使你两台机器都配置成 MASTER，只要 priority 不同，最终也会由 priority 高的获胜。这个机制设计得很好，因为它允许你在主节点恢复后决定是让它自动回切，还是继续保持当前的主备关系。

4.2 主节点 lb01 的 Keepalived 配置

主节点 /etc/keepalived/keepalived.conf 内容如下：

bash复制global_defs {
    router_id LB01
    enable_script_security
}

vrrp_script check_nginx {
    script "/etc/keepalived/check_nginx.sh"
    interval 2
    weight -20
    fall 2
    rise 1
}

vrrp_instance VI_WEB {
    state MASTER
    interface ens192
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 123456
    }
    virtual_ipaddress {
        192.168.10.100/24 dev ens192 label ens192:0
    }
    track_script {
        check_nginx
    }
}

这里最核心的是 vrrp_script 部分。它的作用是持续监控 Nginx 进程状态，如果 Nginx 挂了，就降低本机优先级，让 VIP 自动切换到备用节点。这个设计比你想象的重要得多——如果不做进程健康检查，Keepalived 只会在整机宕机时才切换，而 Nginx 进程意外退出时 VIP 不会动，用户照样无法访问。

健康检查脚本 /etc/keepalived/check_nginx.sh 我这样写的：

bash复制#!/bin/bash
if systemctl status nginx --no-pager > /dev/null 2>&1; then
    exit 0
else
    exit 1
fi

给脚本加执行权限：

bash复制chmod +x /etc/keepalived/check_nginx.sh

关于 weight -20 这个参数，解释一下：当脚本检查失败时，本机优先级从 100 降到 80，而此时备节点优先级为 90，备节点自然胜出，VIP 漂移过去。这里要注意 weight 的绝对值必须大于主备 priority 差值（100-90=10），否则降权后主节点优先级仍然比备节点高，VIP 不会切换。我最开始配置的时候 weight 只设了 -5，结果 Nginx 挂了 VIP 一动不动，排查了半天才发现是这个原因。

4.3 备用节点 lb02 的 Keepalived 配置

备用节点配置基本一样，只是在三处有区别：router_id 不同、state 为 BACKUP、priority 为 90。virtual_router_id 必须保持一致，否则两台机器各自维护各自的 VIP，就变成"双主"了，实际效果和没配一样。

bash复制global_defs {
    router_id LB02
    enable_script_security
}

vrrp_script check_nginx {
    script "/etc/keepalived/check_nginx.sh"
    interval 2
    weight -20
    fall 2
    rise 1
}

vrrp_instance VI_WEB {
    state BACKUP
    interface ens192
    virtual_router_id 51
    priority 90
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 123456
    }
    virtual_ipaddress {
        192.168.10.100/24 dev ens192 label ens192:0
    }
    track_script {
        check_nginx
    }
}

这里再提一个容易踩的坑：authentication 的 auth_pass 在 Keepalived 高版本里默认要求至少 8 位，但位数过多也会导致部分版本解析异常。我建议统一用 8 位纯数字或字母组合，主备两端的 auth_type 和 auth_pass 必须完全一致，一旦不匹配，VPPR 报文会被丢弃，两台机器都会认为自己是主，VIP 就飘在两边了。

4.4 启动与验证：VIP 是否正确绑定

配置完成后启动服务：

bash复制systemctl enable --now keepalived
systemctl start nginx

这时在 lb01 上执行 ip addr show ens192，应该能看到 VIP 192.168.10.100 已经绑定在 ens192:0 上。在 lb02 上执行同样的命令，应该看不到这个 VIP。这就是主备模式的标准状态。

查看 Keepalived 日志确认状态：

bash复制journalctl -u keepalived -f

正常会看到 Entering MASTER STATE 或 Entering BACKUP STATE 的日志。如果你看到两台都是 MASTER，别慌，先检查防火墙是否放行了 vrrp 协议，再看 auth_pass 是否一致，最后看 virtual_router_id 有没有写错。这几个问题几乎覆盖了 90% 的 Keepalived 无法正常工作的情况。

5. Nginx 负载均衡层配置：upstream 健康探测与转发规则

5.1 upstream 配置：负载均衡策略怎么选

Keepalived 解决了 VIP 的可用性问题，但用户请求到达 VIP 之后，Nginx 还得知道往哪些后端节点转发。这里就是 Nginx upstream 模块发挥作用的地方。

我在 /etc/nginx/conf.d/web_cluster.conf 中做了如下配置：

nginx复制upstream web_backend {
    zone backend 64k;
    least_conn;
    server web01:80 weight=1 max_fails=2 fail_timeout=10s;
    server web02:80 weight=1 max_fails=2 fail_timeout=10s;
}

server {
    listen 80;
    server_name www.example.com;

    access_log /var/log/nginx/web_access.log main;
    error_log /var/log/nginx/web_error.log warn;

    location / {
        proxy_pass http://web_backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_connect_timeout 5s;
        proxy_read_timeout 30s;
    }
}

负载均衡策略我选的是 least_conn（最少连接数），而不是默认的轮询。原因很简单：我们后端接口中有些请求耗时较长（比如导出、批量查询），用轮询算法很容易把长耗时请求扎堆分配到同一台机器上，导致负载不均。最少连接数算法会把新请求转发给当前活跃连接数最少的节点，在这种场景下负载分配明显更均衡。

但这不代表轮询不好。如果你的后端服务每个请求的处理时间都差不多，轮询有天然的无状态均衡优势。选择合适的策略，前提是你足够了解自己的业务流量模型——这是很多配置教程不会告诉你的。

5.2 健康检查参数详解：max_fails 与 fail_timeout 的配合

很多人在配 Nginx upstream 时都忽略了健康检查参数，其实这两个参数直接决定了故障节点从转发列表中被剔除的速度。

• max_fails：在 fail_timeout 时间内允许的最大失败次数。默认值为 1。
• fail_timeout：统计失败次数的窗口时间，同时也是节点被标记为不可用后的冷却时间。默认值为 10 秒。

举个例子，配置 max_fails=2 fail_timeout=10s 的含义是：如果某个后端节点在 10 秒内有 2 次请求失败，Nginx 会认为该节点不可用，并在接下来的 10 秒内不再向它转发请求。10 秒后 Nginx 会再尝试发一次请求去探测，如果成功则恢复节点，失败则继续冷却。

这个参数组合的权衡点在于：max_fails 设置过小容易误判（网络抖动一下就被摘掉），设置过大又导致故障感知太慢。我在生产环境中普遍使用 2 次失败、10 秒窗口，配合后端服务自身的优雅停机，效果比较理想。

5.3 配置 Nginx 的 proxy 超时参数，防止"卡死"假象

Nginx 默认的 proxy_read_timeout 是 60 秒。这意味着如果后端处理请求超过了 60 秒，Nginx 会主动断开连接，返回 504。这个默认值对于大多数业务来说足够，但对于一些特殊接口（比如报表导出、大批量数据下载）可能不够。

我习惯显式地设置超时参数，避免依赖默认值：

nginx复制proxy_connect_timeout 5s;
proxy_send_timeout 30s;
proxy_read_timeout 30s;

proxy_connect_timeout 设置的是 Nginx 与后端建立 TCP 连接的超时时间，5 秒已经足够；proxy_read_timeout 是两次读操作之间的间隔超时，不是总超时时间，所以 30 秒并不意味着一个耗时 1 分钟的请求一定会被切断——只要后端持续在返回数据，连接就不会断。这一点很多人理解有偏差，导致盲目调大超时时间，反而让异常请求长时间占用连接池。

5.4 Web 节点本身的配置：最小化对外暴露面

Nginx 负责负载均衡之后，后端 Web 节点就不需要直接暴露公网了。为了安全，后端节点的防火墙只允许来自 lb01 和 lb02 的流量访问 80 端口。在 web01 和 web02 上执行：

bash复制firewall-cmd --permanent --add-rich-rule='rule family=ipv4 source address=192.168.10.10 port port=80 protocol=tcp accept'
firewall-cmd --permanent --add-rich-rule='rule family=ipv4 source address=192.168.10.11 port port=80 protocol=tcp accept'
firewall-cmd --reload

这一步是很多人忽略的安全细节：把后端节点完全隐藏在负载层后面，即使有人扫描到后端 IP，也无法直接访问 Web 端口。同时，这也能避免后端节点绕过负载均衡直接对外提供服务的"旁路"风险。

6. 故障切换实测：三类故障场景下的行为与日志验证

6.1 场景一：整机宕机（模拟主节点断电）

高可用架构搭建完之后，真正检验成果的时刻就是故障演练。我说一下实测的完整过程。

我模拟的第一种故障是最极端的：直接对 lb01 执行 systemctl stop keepalived（模拟 keepalived 进程停止），然后观察 VIP 漂移情况。

执行后，我立即在 lb02 上查看 Keepalived 日志：

bash复制journalctl -u keepalived --since "1 minute ago"

日志中出现了关键行：

code复制Keepalived_vrrp: VRRP_Script(check_nginx) succeeded
Keepalived_vrrp: (VI_WEB) Backup: +10.1.2.250 from 192.168.10.10
Keepalived_vrrp: (VI_WEB) Entering MASTER STATE
Keepalived_vrrp: (VI_WEB) Sending gratuitous ARP on ens192

注意 Sending gratuitous ARP 这一行，它表示新主节点已经在网络上广播了免费 ARP，通知交换机更新 VIP 对应的 MAC 地址。这是 VIP 切换生效的关键一步。

大概 3 秒后，我在客户端机器上持续 ping VIP 192.168.10.100，发现只丢了 1-2 个包，然后恢复。Web 页面刷新直接可用。

6.2 场景二：Nginx 进程崩溃（Keepalived 正常存活）

第二种故障更隐蔽：Nginx 进程意外停止，但整机没问题、Keepalived 也没问题。这也是我在前文强调必须配置 vrrp_script 的原因。

在 lb01 上执行：

bash复制systemctl stop nginx

此时 check_nginx.sh 检测到 Nginx 未运行，连续两次检查失败（fall 2），触发优先级降权，lb01 的 priority 从 100 降到 80。lb02 的 priority 90 成为最高，于是 VIP 漂移到 lb02。

我实测的结果是：从 Nginx 停止到 VIP 完成漂移，耗时约 5-6 秒。其中 interval 2 乘以 fall 2 是检测时间，加上 VRRP 广播间隔和切换时间，整体在可接受范围内。这个切换时间可以通过调小 interval 和 fall 来缩短，但代价是误判概率上升。比如网络短暂拥塞导致探测失败，就会发生不必要的主备切换。我建议保持 2 秒间隔、2 次失败确认的配置，不要过度追求极短切换时间。

6.3 场景三：后端 Web 节点故障（Nginx 健康检查剔除）

第三种故障发生在后端 Web 节点。比如 web01 的 Web 服务挂了，但 lb01 和 Keepalived 都正常。

这个场景下，Nginx 的 upstream 健康检查会发挥作用。我故意在 web01 上停止 httpd 服务（假设 Web 应用由 httpd 承载），然后观察 Nginx 日志和访问情况。

Nginx 日志中会周期性出现类似这样的错误记录：

code复制2024/XX/XX 10:15:02 [error] 12345#0: *678 connect() failed (111: Connection refused) while connecting to upstream, client: 192.168.10.100, server: www.example.com, upstream: "http://web01:80"

出现 2 次之后，Nginx 会将 web01 标记为不可用，后续请求全部转发到 web02。用户访问几乎没有任何感知，最多偶发一次 502 或请求变慢（取决于失败请求的响应速度）。

这里有一个体验细节：如果后端某个节点上还有未处理完的请求，比如正在下载一个文件，这时候节点崩溃，连接会中断，用户需要重新发起请求。但已经通过负载均衡器转发到正常节点的请求不受影响。高可用不是零丢失，而是最小化不可用时间，这个预期要在方案设计时对业务方讲清楚。

6.4 故障切换的完整时间线对比

我整理了一次完整故障演练的时间线，方便你直观对比：

这个量级的切换时间，对于绝大多数 Web 业务场景来说是完全可以接受的。如果你的业务对中断容忍度极低（比如支付接口），那可能需要引入更复杂的双活甚至三活方案，但成本和复杂度也会呈指数级上升。架构设计从来不是追求极致，而是在投入和收益之间找平衡。

7. 边界情况与优化：脑裂、半开连接、回切策略与后续演进

7.1 脑裂问题：两台机器同时持有 VIP 怎么办

脑裂是高可用集群中最危险的一种情况。它指的是主备节点之间的 VRRP 通信完全中断，导致两台机器都无法感知对方状态，各自认为自己是主节点，于是 VIP 同时出现在两台机器上。

脑裂的典型后果是：用户请求被分散到两个"主节点"，尤其是当后端有状态数据时，会造成严重的数据不一致。即使 Web 服务是无状态的，VIP 冲突也会导致网络层面的路由混乱。

脑裂在我们这套纯软件方案中的主要成因有两种：

1. 防火墙误拦了 VRRP 协议，或者交换机端口隔离导致广播报文无法互通。
2. 网络抖动导致 VRRP 报文丢失超过超时时间。

预防脑裂的几道防线：

• 在 Keepalived 配置里为 vrrp_instance 添加 unicast_peer 配置，使用单播方式通信，而不是依赖广播。RHEL9 上配置多播有时会遇到交换机 IGMP snooping 问题，单播更可靠：

bash复制vrrp_instance VI_WEB {
    unicast_src_ip 192.168.10.10
    unicast_peer {
        192.168.10.11
    }
    ...
}

• 添加第三方仲裁机制。比如通过访问对端 IP 是否可达来判断"我该不该持有 VIP"，如果检测到对端也持有 VIP，就主动释放自己的 VIP。这个逻辑可以用脚本集成到 vrrp_script 里，但复杂度较高，一般场景下不建议轻易使用。
• 运维巡检中定期检查两台机器上 IP 地址的状态，用脚本或监控工具盯住"VIP 同时出现在多台机器上"的异常。

脑裂问题没有 100% 的解决方案，但通过单播替代多播、合理的防火墙配置和定期巡检，可以把风险降到很低。

7.2 主节点恢复后的回切策略：nopreempt 与手动切回

默认情况下，Keepalived 有抢占机制：主节点 lb01 恢复后，因为 priority 为 100，高于 lb02 的 90，VIP 会自动切回 lb01。这在很多场景下是好事，但也可能带来问题。

比如主节点恢复初期系统负载较高、缓存未预热，此时如果立即把全部流量切回来，用户会感知到明显的性能下降。我在生产实践中更推荐关闭自动抢占，让 VIP 保持在当前正在服务的节点上，等主节点完全稳定后再手动切回，或者等下次维护窗口再人为触发切换。

关闭自动抢占的方式，是在 master 和 backup 的 vrrp_instance 中都加上：

bash复制nopreempt

注意 nopreempt 必须配合 state 为 BACKUP 使用才有效。这里有个细节：在两台机器上都配置 state BACKUP，通过 priority 高者当选，配合 nopreempt，能实现"初始主节点优先但故障恢复后不自动回切"的效果。

需要手动回切时，可以这样操作：

bash复制# 在 lb01 上先启动 keepalived，确认从 BACKUP 变 MASTER 后，再重启 lb02 的 keepalived
systemctl restart keepalived

如果没有 nopreempt，主节点启动后 VIP 会自动切回来；有 nopreempt 的情况下，可以通过临时提高 priority 或停止备节点 Keepalived 来触发回切。这需要根据你实际业务的偏好来决定。

7.3 连接会话保持：sticky session 与无状态化改造

Web 应用如果使用本地 Session 存储用户登录状态，那么在负载均衡环境中会面临一个经典问题：用户第一次请求打到 web01，登录状态存在 web01 本地；第二次请求被 Nginx 转发到 web02，web02 没有这个 Session，用户就被迫重新登录了。

解决这个问题通常有两条路：

• 方案一：sticky session。在 Nginx upstream 中配置 ip_hash 或 sticky cookie，让同一个用户的请求始终转发到同一台后端节点。配置简单，也能解决问题，但一旦这台节点挂了，该节点上的所有用户 Session 都失效，等于把用户的可用性和单节点绑定在一起，与高可用的初衷相悖。

• 方案二：Session 外置。把 Session 存储从 Web 应用本地搬到独立的 Redis 或数据库中，Web 节点完全无状态，任意请求打到任意节点都能正确处理。这才是真正符合高可用架构的做法。

我强烈建议团队尽量走方案二。虽然改造需要一定成本，但它带来的好处是后续扩容缩容都变得非常轻松，新节点随时加入，旧节点随时摘除，对用户完全透明。如果业务是传统单体应用，短期做不了大改造，可以先做 sticky session 过渡，但一定要把"Session 外置"列入技术债务清单，尽早还掉。

7.4 安全加固的几点补充

高可用通常和 Web 安全绑定在一起讨论，因为一旦流量入口高可用了，安全防护的入口也应该同步高可用。我这里只讲几个基础但重要的点：

• Nginx 隐藏版本号，避免暴露具体版本信息被针对性攻击：

nginx复制server_tokens off;

• 通过 Nginx 限制请求体大小，防止大文件上传导致后端资源耗尽：

nginx复制client_max_body_size 10m;

• 对上游响应做缓存，减轻后端压力（根据业务实际情况决定是否开启）。

这条单纯作为运维层面的补充，不展开讲复杂 WAF 部署。安全是高可用的另一半，只做冗余不做防护，等于敞开大门让人来打。

7.5 架构可以怎么演进：从 Keepalived + Nginx 到更高阶方案

如果你将来业务量变大，或者要求更大规模的横向扩展，这套架构的演进路线大致如下：

1. 在 Nginx 前面再叠加一层四层负载均衡（如 LVS 或云厂商的负载均衡产品），解决 Nginx 本身的性能瓶颈和单点问题，形成"LVS + Nginx + Web节点"的三层架构。
2. 把 Web 应用容器化，用 Kubernetes 管理调度，由 K8s Service 自身承担负载均衡和健康检查。Keepalived 方案此时可以退居到负责接入层 VIP 的角色，或者直接由云平台负载均衡替代。
3. 数据库、缓存等有状态组件，分别引入各自的高可用方案。比如 Redis 使用 Sentinel 或 Cluster，MySQL 使用主从复制 + MHA/Orchestrator。这个时候整套系统的架构图就会从"入口高可用"扩展为"全链路高可用"。

我在实际项目中就看到过一个很典型的演进案例：团队一开始用 Keepalived + Nginx 跑跑了两年，后来容器化改造后换了 K8s，但 Keepalived 那层 VIP 反而保留了下来，用来给云上不能直接暴露的入口做一层稳定的对外 VIP。这说明架构演进不是"替换"而是"叠加"，运维人员对底层原理的理解是永远不会过时的。

8. 最后分享一点实际运维体会

这套基于 RHEL9 的高可用 Web 集群架构，我前后在不同环境中部署过多次，踩过的坑基本都集中在几个没想到的角落。我把最有价值的几条总结出来，算是对前面所有配置的一个补丁说明。

第一，健康检查脚本一定要写得极其保守。vrrp_script 每次执行都会 fork 一个子进程，如果脚本过于复杂（比如调用了网络请求、数据库查询），可能导致 Keepalived 进程阻塞，甚至出现主节点误降级。保持脚本功能单一：检测进程在不在、端口通不通，就够了。

第二，不要用 systemctl status 的返回值做健康检查判断依据。我踩过这个坑：RHEL9 上如果 Nginx 配置文件写错，systemctl status nginx 会返回非退出码，但进程可能还活着，此时健康检查会误报。更可靠的判断方式是结合端口探测：

bash复制#!/bin/bash
if systemctl is-active --quiet nginx && ss -tlnp | grep -q ':80 '; then
    exit 0
else
    exit 1
fi

第三，日志一定不要只保留在本地。主备节点各自的 journald 日志、Nginx access/error 日志，建议用 rsyslog 或者日志采集工具统一集中存储。故障发生时你要先看的是整体时间线，而不是在单台机器上翻来找去。

第四，高可用不是配完就完事的，一定频率的故障演练才是真正让方案"可信"的保障。我现在的习惯是每个月做一次 Nginx 进程 kill 演练，每季度做一次整机宕机演练，每次演练完会记录切换耗时和日志输出，形成一份持续更新的运维档案。有了这份档案，出了故障时你手上有的是数据问题，而不是靠猜。

架构设计说到底是一门平衡的艺术。Keepalived + Nginx 这套组合不是最复杂的方案，但它在可靠性、可维护性和成本之间取得了很好的平衡。如果你正在规划 Web 层的高可用改造，从这套方案开始，我认为是一条很务实的路。