Keepalived 高可用全解析

本文深入剖析 Keepalived 高可用架构的核心原理与实战部署，涵盖 VRRP 协议机制、脑裂防护策略以及生产环境最佳实践，帮助读者构建稳定可靠的双机热备系统。

文章目录

- [一、HA 集群概述](#一、HA 集群概述)
- - [1. HA 集群能解决哪些问题？](#1. HA 集群能解决哪些问题？)
  - [2. HA 集群的局限性](#2. HA 集群的局限性)
- [二、Keepalived 介绍](#二、Keepalived 介绍)
- [三、VRRP 原理](#三、VRRP 原理)
- - [1. 单网关面临的问题](#1. 单网关面临的问题)
  - [2. VRRP 概述](#2. VRRP 概述)
  - [3. VRRP 基本概念](#3. VRRP 基本概念)
  - [4. VRRP 报文格式](#4. VRRP 报文格式)
  - [5. VRRP 定时器](#5. VRRP 定时器)
  - [6. VRRP 协议状态](#6. VRRP 协议状态)
  - [7. VRRP 主备选举](#7. VRRP 主备选举)
  - [8. VRRP 主备切换](#8. VRRP 主备切换)
- [四、Keepalived VRRP 工作原理](#四、Keepalived VRRP 工作原理)
- - [1. 网络层（第三层）](#1. 网络层（第三层）)
  - [2. 传输层（第四层）](#2. 传输层（第四层）)
  - [3. 应用层（第七层）](#3. 应用层（第七层）)
- [五、VRRP 脑裂](#五、VRRP 脑裂)
- - [1. 脑裂的定义](#1. 脑裂的定义)
  - [2. 脑裂产生的原因](#2. 脑裂产生的原因)
  - [3. 脑裂的危害](#3. 脑裂的危害)
  - [4. 脑裂防护方案](#4. 脑裂防护方案)
  - - 方案一：增加心跳检测线路
    - [方案二：启用 VRRP 认证](#方案二：启用 VRRP 认证)
    - 方案三：配置防火墙规则
    - 方案四：部署第三方检测工具
    - 方案五：降低脑裂影响范围
    - 方案六：监控与告警
    - 总结
- [六、Keepalived 高可用技术实践](#六、Keepalived 高可用技术实践)
- - [1. 网络拓扑规划](#1. 网络拓扑规划)
  - [2. 基础配置](#2. 基础配置)
  - [3. 部署 Web 服务](#3. 部署 Web 服务)
  - [4. 配置 Keepalived](#4. 配置 Keepalived)
  - - [配置 Backup 节点（web2）](#配置 Backup 节点（web2）)
    - [配置 Master 节点（web1）](#配置 Master 节点（web1）)
  - [5. 高可用验证](#5. 高可用验证)
- [七、Keepalived 配置文件详解](#七、Keepalived 配置文件详解)
- [八、Keepalived 日志配置](#八、Keepalived 日志配置)
- [九、Keepalived 心跳配置](#九、Keepalived 心跳配置)
- 十、生产实践：非抢占模式
- - [1. 配置 Master 节点（web1）](#1. 配置 Master 节点（web1）)
  - [2. 配置 Backup 节点（web2）](#2. 配置 Backup 节点（web2）)
  - [3. 故障切换测试](#3. 故障切换测试)
- 总结

一、HA 集群概述

Keepalived官网

1. HA 集群能解决哪些问题？

在规划高可用（HA）集群时，一个关键问题需要明确：将服务部署到 HA 集群中，是否真正提升了可用性？

回答这一问题，需要深入理解服务自身的能力以及客户端的配置方式。

自带故障转移或负载均衡的服务：例如 DNS 和 LDAP，其原生架构已具备 Master/Slave 角色切换或多 Master 数据冗余机制，客户端也可配置多个服务器地址。这类服务部署到 HA 集群中，并不会带来额外的可用性提升。
不自带故障转移的服务：例如 OpenStack 平台中的 RabbitMQ 和 Galera，将其纳入 HA 集群后，可显著增强服务的容灾能力。

2. HA 集群的局限性

并非所有的可用性问题都能通过 HA 集群解决：

应用程序级缺陷：若应用因 Bug 导致崩溃，即使配置了 HA 集群，服务同样会崩溃。故障节点切换至其他节点后，若其他节点存在相同缺陷，崩溃将再次发生。
端到端冗余缺失：HA 集群本身可以正常运行，但如果网络架构存在单点故障，导致集群不可达，客户端依然无法访问服务。因此，在集群架构设计中，必须全面审视并消除所有潜在的单点故障。

二、Keepalived 介绍

Keepalived 是一款基于 C 语言开发的路由软件，其核心目标是为 Linux 系统及基于 Linux 的基础设施提供简洁而健壮的负载均衡与高可用解决方案。

Keepalived 最初为 LVS 集群设计，专门用于监控集群中各服务节点的状态。它基于 TCP/IP 参考模型的网络层、传输层及应用层机制，自动检测每个服务节点的健康状态。当某节点出现异常或故障时，Keepalived 会自动将其从集群中剔除，整个过程无需人工干预------人工仅需修复故障节点即可。

后续版本引入了 VRRP 协议支持。 VRRP（Virtual Router Redundancy Protocol，虚拟路由器冗余协议）旨在解决静态路由场景下的单点故障问题，通过 VRRP 可实现网络服务的持续稳定运行。因此，Keepalived 兼具两大核心能力：

服务器状态检测与故障隔离
HA 集群管理功能

官网地址：https://www.keepalived.org/

三、VRRP 原理

1. 单网关面临的问题

局域网中的终端设备通常配置一个默认网关来访问外部网络。当该网关设备发生故障时，所有终端的外部网络访问将被中断。虽然可以通过部署多个网关来解决单点故障，但随之而来的多网关冲突问题需要妥善解决。

2. VRRP 概述

VRRP（Virtual Router Redundancy Protocol，虚拟路由器冗余协议）既能实现网关备份，又能解决多网关间的冲突问题，从而显著提升网络可靠性。

其核心思想是：将多台路由设备联合组建为一台虚拟的"路由设备"，通过特定的故障切换机制，当主路由设备出现故障时，业务能够自动、快速地切换到备份路由设备，从而保证通信的连续性和可靠性。

3. VRRP 基本概念

概念	说明
VRRP 路由器	运行 VRRP 协议的路由器。VRRP 配置在路由器接口上，基于接口工作
VRID	虚拟路由器标识符（Virtual Router Identifier），用于标识一个 VRRP 组。同一组的路由器通过相同的 VRID 交互协议报文，生成一台虚拟路由器。一个 VRRP 组中只能有一台 Master 路由器
虚拟路由器	VRRP 为每个组抽象出一台虚拟路由器，它并非真实物理设备，而是由协议虚拟出的逻辑设备。一个 VRRP 组仅产生一台虚拟路由器
虚拟 IP 地址	虚拟路由器拥有自己的 IP 地址，由管理员配置，用户通常以此地址作为网关
虚拟 MAC 地址	格式为 `0000-5e00-01xx`，其中 `xx` 为 VRID
Master 路由器	承担报文转发任务，响应虚拟 IP 的 ARP 请求，并周期性发送 VRRP 通告报文
Backup 路由器	监听 Master 发送的 VRRP 报文，随时准备接管 Master 的工作
Priority	优先级，取值范围 0-255，值越大越优先。值相等时比较接口 IP 地址大小

4. VRRP 报文格式

VRRP 仅定义了一种报文类型------Advertisement 报文 ，基于组播方式发送，仅在同一个广播域内传递。组播地址为 224.0.0.18。

VRRP 报文字段说明：

字段	说明
Ver	VRRP 版本，VRRPv2 仅适用于 IPv4，VRRPv3 同时支持 IPv4 和 IPv6
Virtual Rtr ID	虚拟路由器标识符
Priority	发送该报文的 VRRP 路由器优先级
Count IP Addrs	报文中包含的虚拟 IP 地址数量
Auth Type	认证类型：0（不认证）、1（纯文本密码）、2（MD5）
Adver Int	发送 VRRP 通告报文的间隔，默认 1 秒
IP Address	虚拟路由器的虚拟 IP 地址，可配置多个
Authentication Data	认证密码信息

5. VRRP 定时器

VRRP 协议定义了两种定时器：

定时器	说明
ADVER_INTERVAL	Master 发送 VRRP 通告报文的时间周期，默认 1 秒
MASTER_DOWN	Backup 监听定时器，超时后 Backup 切换为 Master 状态

MASTER_DOWN 定时器计算公式：

bash 复制代码

MASTER_DOWN = (3 × ADVER_INTERVAL) + Skew_time

其中：

bash 复制代码

Skew_Time = (256 - Priority) / 256

6. VRRP 协议状态

VRRP 路由器的工作状态包括：

Initialize：初始状态
Backup：备份状态，监听 Master 通告
Master：主状态，负责转发报文和发送通告
Fault ：故障状态

7. VRRP 主备选举

初始创建的 VRRP 设备工作在 Initialize 状态，收到接口 Up 消息后，若优先级小于 255，先切换至 Backup 状态，等待 MASTER_DOWN 定时器超时后再切换为 Master。
高优先级先启动：高优先级设备先进入 Master 状态，低优先级设备收到通告后保持 Backup。
低优先级先启动 ：低优先级设备先由 Backup 切换为 Master，高优先级设备收到通告后重新选举，将自身提升为 Master。

特殊场景：当某台路由器的接口 IP 地址被用作虚拟路由器 IP 时，该路由器优先级自动变为 255，无条件成为 Master。接口 IP 拥有者的优先级无法手动配置为 255。

8. VRRP 主备切换

主动切换：当 Master 主动放弃 Master 地位时，发送优先级为 0 的通告报文，Backup 设备可立即切换为 Master，无需等待 MASTER_DOWN 超时。切换延迟为 Skew_Time。
故障切换：当 Master 因网络故障无法发送通告时，Backup 需等待 MASTER_DOWN 定时器超时后才会切换为 Master。

四、Keepalived VRRP 工作原理

Keepalived 通过 VRRP 协议实现高可用性，同时具备对集群中服务器运行状态的监控及故障隔离能力。其工作层次覆盖 TCP/IP 参考模型的网络层、传输层和应用层。

1. 网络层（第三层）

网络层提供 IP、ICMP、ARP、RARP 等核心协议。Keepalived 在网络层采用 ICMP 探测机制，向集群中每个节点发送 ICMP 数据包（类似 Ping），若某节点无响应，则判定其故障并从集群中剔除。

2. 传输层（第四层）

传输层提供 TCP 和 UDP 协议。Keepalived 利用 TCP 端口连接与扫描技术 判断集群节点的端口健康状态。例如对 Web 服务器的 80 端口、SSH 的 22 端口进行探测，一旦端口无响应，即将对应节点从集群中移除。

3. 应用层（第七层）

应用层支持 FTP、Telnet、SMTP、DNS 等各类高层协议。Keepalived 允许用户通过自定义脚本或程序来检测服务运行状态，当检测结果与预期不符时，自动将对应服务器从集群中剔除。

五、VRRP 脑裂

1. 脑裂的定义

在 Keepalived 高可用集群中，脑裂（Split-Brain） 是指主从节点之间因通信中断，导致双方均认为对方已故障，从而同时争抢虚拟 IP（VIP）等资源，引发集群状态混乱的严重故障。

2. 脑裂产生的原因

脑裂的核心是节点间心跳检测失败，但实际节点均正常运行。常见诱因包括：

网络问题：主从节点间心跳线路（专用网卡、交换机）故障、断网或延迟过高
防火墙规则：节点间 VRRP 协议端口（默认 UDP 112）被防火墙拦截
资源耗尽：某节点 CPU、内存耗尽或负载过高，无法响应心跳请求
配置错误 ：keepalived 配置中 vrrp_instance 的 state、priority 或 authentication 等参数不一致

3. 脑裂的危害

双主冲突：两个节点同时持有 VIP，导致客户端请求混乱（部分成功、部分失败）
数据不一致：若集群管理数据库或存储资源，可能引发双写冲突
服务崩溃：集群失去高可用意义，资源竞争可能导致服务整体崩溃

4. 脑裂防护方案

方案一：增加心跳检测线路

除主网络外，添加备用通信线路（独立网卡），并在配置中指定多网卡检测：

bash 复制代码

vrrp_instance VI_1 {
    state MASTER
    interface eth0          # 主网卡
    virtual_router_id 51
    priority 100
    advert_int 1
    # 同时检测备用网卡
    track_interface {
        eth0
        eth1
    }
}

方案二：启用 VRRP 认证

配置节点间认证机制，确保心跳信息可靠性：

bash 复制代码

vrrp_instance VI_1 {
    # 其他配置...
    authentication {
        auth_type PASS      # 认证类型（PASS 或 AH）
        auth_pass 123456    # 密码（所有节点必须一致）
    }
}

方案三：配置防火墙规则

允许节点间 VRRP 协议通信（CentOS 示例）：

bash 复制代码

# 允许VRRP协议
firewall-cmd --add-protocol=vrrp --permanent
firewall-cmd --reload

方案四：部署第三方检测工具

使用 fence 机制（如 fence_virsh、fence_ipmilan）或自定义脚本，在检测到脑裂时强制隔离异常节点。

在 keepalived.conf 中配置 notify 脚本：

bash 复制代码

vrrp_instance VI_1 {
    # 其他配置...
    notify_master "/etc/keepalived/check_split_brain.sh master"
    notify_backup "/etc/keepalived/check_split_brain.sh backup"
}

脚本逻辑：通过 ping、端口检测等方式确认对端状态，若判定脑裂则执行 kill 或 reboot 操作。

方案五：降低脑裂影响范围

结合业务层设计，如数据库采用主从复制 + 读写分离，避免双写冲突
存储层使用分布式锁（如 Redis）控制资源独占
限制 VIP 使用场景，仅在确认集群状态正常时对外提供服务

方案六：监控与告警

通过 Zabbix、Prometheus 等工具监控 Keepalived 状态（如 vrrp_script 检测），当发现双主节点共存时及时告警。

总结

脑裂的本质是节点通信失效与状态判断不一致，预防核心在于 "多重检测 + 自动隔离" ：通过多线路心跳、认证机制降低误判概率，结合脚本和第三方工具在脑裂发生时快速隔离异常节点，同时配合监控及时干预，保障集群稳定。

六、Keepalived 高可用技术实践

1. 网络拓扑规划

主机名	IP 地址	服务器角色
client1.csh.cloud	10.1.8.21	客户端
web1.csh.cloud	10.1.8.11	Web 服务器（Master）
web2.csh.cloud	10.1.8.12	Web 服务器（Backup）

2. 基础配置

配置各节点的主机名、IP 地址和网关：

复制代码

# client1 配置
hostnamectl set-hostname client1.csh.cloud
nmcli connection modify ens33 ipv4.method manual ipv4.addresses 10.1.8.21/24 ipv4.gateway 10.1.8.2 ipv4.dns 10.1.8.2 autoconnect yes
nmcli connection up ens33

# web1 配置
hostnamectl set-hostname web1.csh.cloud
nmcli connection modify ens33 ipv4.method manual ipv4.addresses 10.1.8.11/24 ipv4.gateway 10.1.8.2 ipv4.dns 10.1.8.2 autoconnect yes
nmcli connection up ens33

# web2 配置
hostnamectl set-hostname web2.csh.cloud
nmcli connection modify ens33 ipv4.method manual ipv4.addresses 10.1.8.12/24 ipv4.gateway 10.1.8.2 ipv4.dns 10.1.8.2 autoconnect yes
nmcli connection up ens33

3. 部署 Web 服务

在 web1 和 web2 上部署 Nginx：

bash 复制代码

[root@web1-2 ~]# wget -O /etc/yum.repos.d/epel.repo http://mirrors.aliyun.com/repo/epel-7.repo
[root@web1-2 ~]# yum install -y nginx
[root@web1-2 ~]# echo "Welcome to $(hostname)" > /usr/share/nginx/html/index.html
[root@web1-2 ~]# systemctl enable nginx.service --now

验证后端 Nginx 服务：

bash 复制代码

[root@client1 ~]# curl 10.1.8.11
Welcome to web1.csh.cloud

[root@client1 ~]# curl 10.1.8.12
Welcome to web2.csh.cloud

4. 配置 Keepalived

配置 Backup 节点（web2）

bash 复制代码

[root@web2 ~]# yum install -y keepalived
[root@web2 ~]# cp /etc/keepalived/keepalived.conf{,.ori}
[root@web2 ~]# vim /etc/keepalived/keepalived.conf

配置文件内容：

bash 复制代码

! Configuration File for keepalived
global_defs {
    router_id web2
}
vrrp_instance nginx {
    state BACKUP
    interface ens33
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass csh@123    # 密码长度不能超过8位（超过则只取前8位）
    }
    virtual_ipaddress {
        10.1.8.100/24
    }
}

配置参数说明：

参数	说明
router_id	路由器名称标识，每个节点需唯一
state	节点初始角色（MASTER/BACKUP），实际角色由 priority 决定
interface	VIP 绑定的网络接口
virtual_router_id	虚拟路由器 ID（1-255），同一集群所有节点必须一致
priority	节点优先级，值越大越优先
authentication	心跳认证配置
virtual_ipaddress	虚拟 IP 地址

启动服务并验证 VIP 绑定：

bash 复制代码

[root@web2 ~]# systemctl enable keepalived.service --now
[root@web2 ~]# ip -br a show ens33
ens33           UP             10.1.8.12/24 10.1.8.100/24
fe80::20c:29ff:fe83:619c/64

配置 Master 节点（web1）

bash 复制代码

[root@web1 ~]# yum install -y keepalived
[root@web1 ~]# cp /etc/keepalived/keepalived.conf{,.ori}
[root@web1 ~]# vim /etc/keepalived/keepalived.conf

配置文件内容：

bash 复制代码

! Configuration File for keepalived
global_defs {
    router_id web1
}
vrrp_instance nginx {
    state MASTER
    interface ens33
    virtual_router_id 51
    priority 110                  # Master 节点优先级须高于 Backup 节点
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass csh@123
    }
    virtual_ipaddress {
        10.1.8.100/24
    }
}

启动服务并验证：

bash 复制代码

[root@web1 ~]# systemctl enable keepalived.service --now
[root@web1 ~]# ip -br a show ens33
ens33           UP             10.1.8.11/24 10.1.8.100/24
fe80::20c:29ff:fe16:ad99/64

# 确认 web2 上 VIP 已漂移
[root@web2 ~]# ip -br a show ens33
ens33           UP             10.1.8.12/24
fe80::20c:29ff:fe83:619c/64

5. 高可用验证

bash 复制代码

# 通过 VIP 访问 Web 服务
[root@client1 ~]# curl 10.1.8.100
Welcome to web1.csh.cloud

# 停止 Master 节点（web1）的 Keepalived 服务，模拟故障
[root@web1 ~]# systemctl stop keepalived.service

# 再次通过 VIP 访问，流量自动切换到 Backup
[root@client1 ~]# curl 10.1.8.100
Welcome to web2.csh.cloud

# 恢复 Master 节点，Master 将重新抢占 VIP
[root@web1 ~]# systemctl start keepalived.service
[root@client1 ~]# curl 10.1.8.100
Welcome to web1.csh.cloud

七、Keepalived 配置文件详解

配置文件路径：/etc/keepalived/keepalived.conf，主要包含三大部分：

配置块	说明
GLOBAL	全局配置，定义路由器标识、邮件通知等
VRRPD	VRRP 协议配置，定义实例、优先级、VIP 等
LVS	LVS 负载均衡服务管理配置

完整配置示例：

bash 复制代码

! Configuration File for keepalived

# 全局配置
global_defs {
    # 邮件接收者清单
    notification_email {
        acassen@firewall.loc
        failover@firewall.loc
        sysadmin@firewall.loc
    }
    # 邮件发送者
    notification_email_from Alexandre.Cassen@firewall.loc
    # 邮件发送服务器
    smtp_server 192.168.200.1
    # 连接邮件服务器超时时间
    smtp_connect_timeout 30
    # 本机标识，集群中不可重复
    router_id LVS_DEVEL
    # 优化：跳过重复通告的地址检查
    vrrp_skip_check_adv_addr
    # 严格遵守 VRRP 协议
    vrrp_strict
    # 免费 ARP 消息发送延迟（毫秒）
    vrrp_garp_interval 0
    # 未请求 NA 消息发送延迟（毫秒）
    vrrp_gna_interval 0
}

# VRRP 协议配置
vrrp_instance VI_1 {
    # 初始角色（MASTER/BACKUP），实际由 priority 竞选决定
    state MASTER
    # VIP 绑定接口
    interface eth0
    # 虚拟路由器 ID（0-255），同一集群必须一致
    virtual_router_id 51
    # 优先级（高于其他节点 50 将成为 Master）
    priority 100
    # VRRP 通告间隔（秒）
    advert_int 1
    # 心跳认证
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    # 虚拟 IP 列表（可配置多个）
    virtual_ipaddress {
        192.168.200.16
        192.168.200.17
        192.168.200.18
    }
}

# LVS 服务管理配置
virtual_server 192.168.200.100 443 {
    # 服务轮询延迟（秒）
    delay_loop 6
    # LVS 调度算法：rr|wrr|lc|wlc|lblc|sh|dh
    lb_algo rr
    # LVS 转发方式：NAT|DR|TUN
    lb_kind NAT
    # 持久连接超时（秒），默认 6 分钟
    persistence_timeout 50
    # 传输协议：TCP|UDP|SCTP
    protocol TCP
    # 真实服务器
    real_server 192.168.201.100 443 {
        weight 1
    }
}

更多配置参数请参考 keepalived.conf(5) 手册页。

八、Keepalived 日志配置

在 web1 和 web2 节点上配置独立日志输出：

bash 复制代码

# 1. 修改 Keepalived 启动参数
[root@web1,web2 ~]# vim /etc/sysconfig/keepalived
# 第14行：KEEPALIVED_OPTIONS="-D -d -S 0"
# -D：后台守护进程模式（Daemon），默认必带
# -d：开启 debug 调试日志，记录更多 VRRP 细节
# -S 0：syslog facility 0，使用 LOG_SYSLOG 设施输出
# ⚠ 生产环境不建议长期开启 -d，日志量极大，会刷爆 messages 文件
#    排查问题时临时开启，问题解决后移除 -d 参数

# 2. 配置 rsyslog 独立日志输出
[root@web1,web2 ~]# vim /etc/rsyslog.d/keepalived.conf
local0.*                  /var/log/keepalived.log
# 将 Keepalived 日志单独输出到 /var/log/keepalived.log，避免与 messages 混杂

# 3. 重启服务
[root@web1,web2 ~]# systemctl restart rsyslog
[root@web1,web2 ~]# systemctl restart keepalived.service

# 4. 实时监控日志
[root@web1,web2 ~]# tail -f /var/log/keepalived.log

九、Keepalived 心跳配置

在多网卡环境中，必须通过 mcast_src_ip 参数指定心跳组播报文的源 IP，防止 Keepalived 随机选择网卡发送心跳，导致备节点收不到 VRRP 报文而产生双主故障。

bash 复制代码

! Configuration File for keepalived
global_defs {
    router_id Cluster1
}
vrrp_instance Nginx {
    state MASTER
    interface ens36
    mcast_src_ip 20.0.0.11    # 指定心跳组播报文的源 IP（ens36 网卡 IP）
    # 多网卡环境必须配置，否则 Keepalived 可能随机选网卡发心跳
    # 备机收不到 VRRP 包，两台机器都抢 VIP，产生双主故障
    virtual_router_id 51
    priority 110
    advert_int 1              # 心跳报文发送间隔（秒），Master 每 1s 发一次
    authentication {
        auth_type PASS
        auth_pass csh@123
    }
    virtual_ipaddress {
        10.1.1.10/24
    }
}

十、生产实践：非抢占模式

在生产环境中，为避免 Master 恢复后频繁抢占导致服务抖动，推荐采用 非抢占模式（nopreempt）：所有节点初始角色均为 BACKUP，优先级高的节点自然成为 Master；当 Master 故障恢复后，不主动抢占，维持 Backup 身份，确保服务稳定性。

1. 配置 Master 节点（web1）

bash 复制代码

[root@web1 ~]# vim /etc/keepalived/keepalived.conf

bash 复制代码

! Configuration File for keepalived
global_defs {
    router_id web1
}
vrrp_instance nginx {
    state BACKUP                  # 所有节点均配置为 BACKUP
    nopreempt                     # 不抢占，保持稳定性
    interface ens33
    virtual_router_id 51
    priority 110
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass csh@124
    }
    virtual_ipaddress {
        10.1.8.100/24
    }
}

bash 复制代码

[root@web1 ~]# systemctl restart keepalived.service
[root@web1 ~]# ip -br a                    # 此时 web1 为 Master
lo               UNKNOWN        127.0.0.1/8 ::1/128
ens33            UP             10.1.8.11/24 10.1.8.100/24
fe80::3aac:87e5:fa52:e87b/64 fe80::6d0e:a95:db7a:2d31/64

2. 配置 Backup 节点（web2）

bash 复制代码

[root@web2 ~]# vim /etc/keepalived/keepalived.conf

bash 复制代码

! Configuration File for keepalived
global_defs {
    router_id web2
}
vrrp_instance nginx {
    state BACKUP
    interface ens33
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass csh@123
    }
    virtual_ipaddress {
        10.1.8.100/24
    }
}

bash 复制代码

[root@web2 ~]# systemctl restart keepalived.service

3. 故障切换测试

bash 复制代码

# 模拟 Master 故障
[root@web1 ~]# systemctl stop keepalived.service

# 确认 web2 接管 VIP
[root@web2 ~]# ip -br a
lo               UNKNOWN        127.0.0.1/8 ::1/128
ens33            UP             10.1.8.12/24 10.1.8.100/24

# 恢复 web1
[root@web1 ~]# systemctl start keepalived.service

# 验证：Master 仍为 web2（非抢占模式）
[root@web2 ~]# ip -br a
lo               UNKNOWN        127.0.0.1/8 ::1/128
ens33            UP             10.1.8.12/24 10.1.8.100/24

# 关闭 web2，确认 web1 接管
[root@web1 ~]# ip -br a
lo               UNKNOWN        127.0.0.1/8 ::1/128
ens33            UP             10.1.8.11/24 10.1.8.100/24

总结

Keepalived 基于 VRRP 协议构建高可用架构，核心通过虚拟 IP（VIP）对外提供统一的访问入口，支持主从和双主两种部署模式。

其工作原理可概括为：通过优先级选举确定 Master 节点，Master 负责转发流量并周期性发送 VRRP 通告；当 Master 故障时，Backup 节点在 MASTER_DOWN 定时器超时后自动接管 VIP 与服务，实现无缝切换。

在生产实践中，建议采用非抢占模式（nopreempt）避免节点恢复后的频繁切换抖动，同时配合多重脑裂防护策略------包括多网卡心跳检测、VRRP 认证、防火墙规则放行以及第三方 fence 机制，确保集群在极端场景下的稳定性。Keepalived 常与 Nginx、LVS 等负载均衡组件联动，为 Web 服务、数据库等核心业务构建坚实的高可用基础设施，是保障业务连续性的关键技术选型之一。