Featured image of post Nginx + Keepalived 双机热备与 VRRP 原理
个人随笔

Nginx + Keepalived 双机热备与 VRRP 原理

早期 LVS 三层负载方案 Nginx + Keepalived 双机热备实战，VRRP 协议原理、健康检查脚本、VIP 漂移机制

本文写于 2014 年 12 月——彼时 Nginx 反代 + Keepalived 是中小公司做"高可用"的标配，比上硬件 F5 便宜，比 DNS 切换快。

一、为什么需要双机热备

单点 Nginx 一旦宕机，整个网站瞬间 503。在没有云 SLB 的年代，IDC 机房做"对外服务的入口高可用"几乎只有两条路：

  1. 硬件 F5 / A10 负载均衡：贵，动辄几十万
  2. 软件 VRRP 协议 + 两台 Nginx：Nginx 本身免费，Keepalived 同样免费

Nginx + Keepalived 方案的核心是虚拟 IP（VIP）漂移：两台机器共享一个 VIP，正常情况下 VIP 在主节点，一旦主节点 Nginx 挂了，VIP 自动漂到备节点，对外几乎无感。

二、Keepalived 工作原理

Keepalived 是基于 VRRP（Virtual Router Redundancy Protocol，虚拟路由冗余协议） 实现的高可用服务软件，主要功能是真机故障隔离 + 负载均衡器间失败切换，防止单点故障。

VRRP 协议保证：当主机的下一跳路由器出现故障时，由另一台路由器代替故障路由器工作，从而保持网络通信的连续性和可靠性。

关键点：VRRP 虚拟出来的是"路由"——本质是一组路由器（物理机）共享一个虚拟 IP，对外只暴露 VIP，内部选举谁持有 VIP。

三、Nginx + Keepalived 双机热备部署

3.1 拓扑结构

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

        ┌──────────────┐
        │   VIP        │   <- 对外服务的虚拟 IP（如 192.168.6.100）
        │ 192.168.6.100│
        └──────┬───────┘
               │ VRRP 心跳
       ┌───────┴───────┐
       │               │
┌──────┴──────┐  ┌─────┴───────┐
│  Master     │  │  Backup     │
│ 192.168.6.29│  │192.168.6.30 │
│ Nginx+Keep  │  │ Nginx+Keep  │
└─────────────┘  └─────────────┘

3.2 安装 Keepalived

两台机器都装：

1

yum install keepalived -y

3.3 配置 keepalived.conf

主节点（/etc/keepalived/keepalived.conf）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

vrrp_script check_nginx {
    script "/usr/local/src/check_nginx.sh"
    interval 2          # 每 2 秒检查一次
    weight -20          # 失败时优先级减 20
    fall 3              # 连续 3 次失败才认为真挂了
    rise 2              # 连续 2 次成功才认为恢复
}

vrrp_instance VI_1 {
    state MASTER        # 本机初始状态
    interface eth0      # 绑定的网卡
    virtual_router_id 51
    priority 100        # 主节点优先级（备节点配 90）
    advert_int 1        # VRRP 通告间隔（秒）
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.6.100/24   # VIP
    }
    track_script {
        check_nginx
    }
}

备节点唯一区别：state BACKUP + priority 90。

3.4 健康检查脚本

Keepalived 不仅能检查自己心跳，更强大的是通过脚本检查 Nginx 是否活着——/usr/local/src/check_nginx.sh：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

#!/bin/bash
# Nginx 健康检查：HTTP 200 才算健康
A=`ps -C nginx --no-header | wc -l`
if [ $A -eq 0 ]; then
    # Nginx 挂了，尝试拉起
    /usr/local/nginx/sbin/nginx
    sleep 2
    if [ `ps -C nginx --no-header | wc -l` -eq 0 ]; then
        # 拉起失败，关闭 Keepalived，让 VIP 漂到备机
        killall keepalived
    fi
fi

加执行权限：chmod +x /usr/local/src/check_nginx.sh。

3.5 启动

1
2

nginx                        # 先启动 Nginx
systemctl start keepalived   # 再启动 Keepalived

查看 VIP 是否在主节点：ip addr show eth0，应能看到 inet 192.168.6.100/24 出现在主节点。

四、模拟故障测试

1
2
3
4
5
6
7

# 1. 在主节点停掉 Nginx
nginx -s stop

# 2. 检查脚本会拉起 Nginx（如果起不来，则杀掉 Keepalived）
# 3. 观察 VIP 漂移到备节点
ip addr show eth0
# 备节点上应出现 192.168.6.100

五、VRRP 选举细节

  • 优先级（priority）：数值越大越优先成为 Master，Master 范围 1-254（0 和 255 有特殊用途）
  • 不抢占模式（nopreempt）：默认是抢占的（备机升级为主机后，原主机恢复会再抢回 VIP），但实际生产中建议配不抢占——避免抖动
  • 认证（authentication）：PASS 认证要求主备密码一致，否则收不到通告
  • virtual_router_id：同一 VRRP 实例内必须相同，不同实例必须不同

六、Nginx + Keepalived 的局限

  1. VIP 漂移有秒级延迟：默认 advert_int 1 + 脚本 interval 2 + fall 3，最坏 5-6 秒才完成漂移
  2. 脑裂问题：主备之间心跳断了但都还活着，会出现两个 VIP 抢同一资源——解法：① 双心跳线（串口线 + 网线）；② 监控脚本探测对端
  3. 单点配置不统一：两台机器的 Nginx 配置必须同步——解法：用 rsync + inotify 自动同步，或上配置中心（Nacos/Consul）

七、后续演进

随着云时代到来，这套方案在 2017 年后逐渐被替代：

  • 云厂商 SLB（阿里云 SLB / AWS ELB）：开箱即用，自带高可用
  • LVS + Keepalived：Nginx 退到 7 层，LVS 在 4 层做入口，更稳
  • Nginx + UPScript + Consul：服务发现 + 健康检查 + 动态 upstream，比静态 VIP 更灵活

但理解 VRRP 原理是面试高频题——它不仅能解释 Keepalived，也能解释 LVS、HAProxy、Cisco HSRP、华为 VRRP，本质都是同一个协议家族。

八、面试常问

Q：Keepalived 和 Heartbeat 有什么区别？ A：都是高可用集群管理软件，但 Keepalived 基于 VRRP 协议工作在网络层，主要做 IP 漂移；Heartbeat 更老，做资源接管和消息心跳。Keepalived 配置简单 + 自带健康检查脚本，是现在的事实标准。

Q：脑裂怎么解？ A：三招——① 双心跳线（网线 + 串口）物理防脑裂；② 监控脚本（监控对端 VIP 是否存在）；③ 业务层幂等设计兜底（即使双写也保证最终一致）。

Q：Nginx + Keepalived 和 LVS + Keepalived 怎么选？ A：LVS 工作在 4 层（传输层），性能更高（百万级并发），但配置复杂；Nginx 工作在 7 层（应用层），可以做按 URL / Header 灰度，但性能低一档（10 万级并发）。实际生产两者经常配合：LVS 做入口 → Nginx 7 层分流 → 后端应用。

九、小结

  • 核心思想：VRRP 协议 + 共享 VIP + 健康检查 + 自动漂移
  • 部署关键：两台机器 + 同样 Nginx 配置 + 同样 Keepalived 配置（priority 不同）
  • 健康检查脚本：让 Keepalived 不只检查自己，更检查 Nginx 进程
  • 演进方向：云 SLB / LVS 4 层 / Consul 服务发现

十、2024+ 视角：10 年后回望，VRRP 仍不过时

本文写于 2014 年 12 月。10 年后的 2024-2026，Nginx + Keepalived 这套方案依然没死——只是从"主力"变成"基础设施"。

10.1 Keepalived 10 年未变：协议层的"长寿"

2014 年的 Keepalived 配置和 2024 年的 Keepalived 配置核心语法几乎一样——这是协议层（VRRP RFC 5798）稳定的胜利。

2024-2026 行业里 Keepalived 仍在用的场景：

  1. 传统行业（银行 / 政企 / 制造）—— 上 K8s 太重，传统 IDC 还在用 Keepalived
  2. 私有云 / 混合云—— 自建机房 + 公有云的混合架构，Keepalived 比云 SLB 更灵活
  3. 数据库双主 / 主备—— MySQL / PostgreSQL 高可用方案里 Keepalived 仍是标配
  4. 国产化替代—— 信创场景（国产化软硬件替代）里，Keepalived 是少数没被卡脖子的 HA 方案

关键认知：VRRP 协议"够简单、够稳定"是 10 年长寿的根本——AI 时代到来时，最朴素的技术反而最难被淘汰。

10.2 云原生时代的 HA 演进

2014 年我们用 Keepalived 做"主备 + VIP 漂移"。2024-2026 主流 HA 方案：

场景2014 主流2024+ 主流
公有云入口Nginx + Keepalived阿里云 SLB / AWS ALB / Cloudflare
私有云入口Nginx + KeepalivedNginx Ingress + K8s Service
数据库高可用MySQL + Keepalived + VIPMHA / Orchestrator / Patroni / Galera
Redis 高可用Redis Sentinel + KeepalivedRedis Sentinel + Cluster + K8s Operator
消息队列 HARabbitMQ + KeepalivedRabbitMQ Cluster + K8s Operator
全局负载DNS 轮询 + F5DNS + 全球 Anycast（Cloudflare / AWS Global Accelerator）

关键变化：Keepalived 的角色从"主备入口"变成"K8s / 数据库内部"—— 它没有消失，只是下沉了。

10.3 K8s 时代的 VIP 替代方案

2014 年的"VIP 漂移"在 K8s 时代有了新解法：

  1. K8s Service (ClusterIP)：内部自动负载均衡 + 健康检查——VIP 概念被抽象
  2. MetalLB（2024-2026 稳定）：K8s 集群内的"LoadBalancer"实现——给 bare-metal 集群提供 VIP 能力
  3. Ingress-Nginx + ExternalDNS：把 K8s 服务暴露到公网，VIP 概念被 DNS 替代
  4. Cilium + BGP：基于 eBPF 的网络方案，VIP 通过 BGP 协议声明
1
2
3
4
5
6
7
8
9

# MetalLB 2024 主流配置（替代 Keepalived 在 K8s 中的角色）
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: production
  namespace: metallb-system
spec:
  addresses:
    - 192.168.6.100-192.168.6.110  # VIP 池

2024 主流选择：新项目直接上 K8s + MetalLB；老项目继续 Keepalived 不动——两者并不冲突。

10.4 现代 HA 方案的"5 个特性"对比

方案自动漂移健康检查跨地域与服务发现集成复杂度
Nginx + Keepalived✅✅（脚本）❌❌低
HAProxy + Keepalived✅✅（内置）❌❌低
LVS + Keepalived✅✅❌❌中
K8s Service + MetalLB✅✅弱✅（K8s 原生）中
云 SLB（阿里/AWS）✅✅✅✅极低
Istio / Service Mesh✅✅✅✅高
Cloudflare Load Balancer✅✅✅✅极低

2024+ 选型经验：小团队用云 SLB / Cloudflare；中等规模 K8s + MetalLB；大规模 Istio / Linkerd；政企 / 信创 Keepalived + 国密 SSL。

10.5 面试题补充（2024+ 视角）

Q：Keepalived 的 VRRP 协议在 IPv6 时代还有用吗？ A：有用。VRRPv3（RFC 5798） 同时支持 IPv4 和 IPv6，2024+ 国产化 IPv6 改造里 Keepalived 仍是首选 HA 方案。

Q：脑裂问题在 K8s 时代怎么解决？ A：K8s 通过 etcd + Raft 协议避免脑裂——集群状态写入 etcd，多数节点同意才算"主"。这是分布式系统层面的"反脑裂"。

Q：为什么云厂商几乎不用 Keepalived？ A：云厂商用底层网络设备的 Anycast + ECMP 实现 LB，Keepalived 是"用户态方案"，在大规模下性能 / 可观测性都比不上硬件方案。但对中小企业，Keepalived 仍然是性价比最高的选择。

Q：Nginx + Keepalived 在 AI 时代还能用吗？ A：能。 AI 服务的入口（推理 API 网关）本质上还是 HTTP，Nginx + Keepalived 一样能跑。区别是 Nginx 需要装 ngx_http_auth_request_module 之类的模块对接 AI 鉴权。

10.6 个人总结：10 年技术演进的"启示"

写这篇文章时我刚毕业 1 年，Keepalived 是我接触的第一个"高可用"方案。10 年后再看：

  1. 协议层的稳定性 > 框架的时髦度——VRRP 10 年没变，Spring Cloud / Dubbo 换了 3 套
  2. “够用"比"更好"更重要——Keepalived 不是最优解，但 10 年后仍是"够用” 的方案
  3. 云时代不等于"传统方案已死"——Keepalived 仍在政企 / 信创 / 数据库 HA 场景下活得很好
  4. 架构选型要"看 10 年"——2014 年选 Keepalived 的项目，2024 年大多还在用

2024+ 给后辈的建议：

  • 面试要会 VRRP 原理——它是 Keepalived / LVS / HSRP 的共同基础
  • 生产要懂 K8s Service——新项目都用这个
  • 架构要懂 BGP / Anycast——云时代的 HA 底层
  • 传统行业要会用 Keepalived——政企 / 银行 / 信创 仍是主力

10 年后，VRRP 协议可能还是不会变——这就是"基础设施"的浪漫。

参考资料（2024+ 补充）

© 2006 - 2026 Liangweidong's blog
使用 Hugo 构建
主题 Stack 由 Jimmy 设计