高可用-Keepalived全解析

最新推荐文章于 2026-08-17 14:20:55 发布

原创最新推荐文章于 2026-08-17 14:20:55 发布 · 898 阅读

4 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

高可用 - Keepalived 全解析

官网
https://www.keepalived.org
在这里插入图片描述

HA 集群能解决哪些问题？

当计划使用 HA 集群时候，有一个重要的问题需要回答：服务放到 HA 集群中，可用性是否会增加？

回答这个问题，需要弄清楚服务的能力和该服务的客户端如何配置。

取决于解决方案，例如 DNS 和 LDAP 自带故障转移或者负载均衡，放到 HA 集群中没什么好处。DNS 或者 LDAP 服务使用多个服务，具备 master/slave 角色，或者多个 master 关系。该服务可在多个服务器之间配置数据冗余。DNS 和 LDAP 的客户端也可以使用多个服务器，这里就没有故障转移，因此，这种服务放置到 HA 集群中不会增加服务的可用性。

那些未自带 Failover 或者 LB 的服务，如果配置为 HA 集群，将会有很多好处。例如在 Openstack 平台解决方案中，将 RabbitMQ 和 Galera 放置到 HA 集群中，可以带来很多好处。

并不是每个可用性问题都可以通过 HA 集群解决：

如果应用程序存因 bug 导致 crash，即使配置为 HA 集群，应用同样会 crash。这种情况下，服务将会转移到其他节点。但是其他节点上的应用也存在相同的 bug 问题，同样会导致 crash。
HA 集群同样不提供端到端的冗余。集群本身可以正常提供服务，但是网络架构存在问题，导致集群不可达，客户端仍然无法访问服务。因此需要慎重考虑集群架构，避免单点故障，包括集群中的任何组件。

Keepalived 介绍

Keepalived 是一个用 C 语言编写的路由软件。这个项目的主要目标是为 Linux 系统和基于 Linux 的基础设施的负载平衡和高可用性提供简单而健壮的设施。

Keepalived 起初是为 LVS 设计的，专门用来监控集群系统中各个服务节点的状态，它根据 TCP/IP 参考模型的第三、第四层、第五层机制检测每个服务节点的状态，如果某个服务器节点出现异常，或者工作出现故障，Keepalived 将检测到，并将出现的故障的服务器节点从集群系统中剔除，这些工作全部是自动完成的，不需要人工干涉，需要人工完成的只是修复出现故障的服务节点。

后来 Keepalived 又加入了 VRRP 的功能，VRRP（Virtual Router Redundancy Protocol，虚拟路由冗余协议）出现的目的是解决静态路由出现的单点故障问题，通过 VRRP 可以实现网络不间断稳定运行，因此 Keepalived 一方面具有服务器状态检测和故障隔离功能，另外一方面也有 HA cluster 功能。

注释： Keepalived 的核心价值在于"状态检测 + VRRP 故障切换"，它既可以做后端健康检查，也可以做网关高可用。

VRRP 原理

局域网中的用户终端通常采用配置一个默认网关的形式访问外部网络，如果默认网关设备发生故障，那么所有用户终端访问外部网络的流量将会中断。可以通过部署多个网关的方式来解决单点故障，但是需要解决多个网关之间的冲突问题。

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

单网关面临的问题

在这里插入图片描述

注释： 单网关是典型的单点故障场景，一旦网关宕机，整个局域网将无法访问外部网络。

VRRP 概述

在这里插入图片描述

通过把几台路由设备联合组成一台虚拟的"路由设备"，使用一定的机制保证当主机的下一跳路由设备出现故障时，及时将业务切换到备份路由设备，从而保持通讯的连续性和可靠性。

VRRP 的运行结果是在局域网上提供一个虚拟路由器。

本例中：

局域网中有两个路由器 R1 和 R2，R1 端口 IP 地址为 192.168.1.251/24，R2 端口 IP 地址为 192.168.1.252/24。
配置 R1 和 R2 关联到同一个虚拟路由器，该虚拟路由器使用 192.168.1.254 做为端口 IP 地址。
所有的 PC 使用 192.168.1.254 做为默认网关。

VRRP 基本概念

在这里插入图片描述

VRRP 路由器： 运行 VRRP 协议的路由器，如 R1 和 R2。VRRP 是配置在路由器的接口上的，而且也是基于接口来工作的。
VRID： 一个 VRRP 组（VRRP Group）由多台协同工作的路由器（的接口）组成，使用相同的 VRID（Virtual Router Identifier，虚拟路由器标识符）进行标识。属于同一个 VRRP 组的路由器之间交互 VRRP 协议报文并产生一台虚拟"路由器"。一个 VRRP 组中只能出现一台 Master 路由器。
虚拟路由器： VRRP 为每一个组抽象出一台虚拟"路由器"（Virtual Router），该路由器并非真实存在的物理设备，而是由 VRRP 虚拟出来的逻辑设备。一个 VRRP 组只会产生一台虚拟路由器。
虚拟 IP 地址及虚拟 MAC 地址： 虚拟路由器拥有自己的 IP 地址以及 MAC 地址，其中 IP 地址由网络管理员在配置 VRRP 时指定，一台虚拟路由器可以有一个或多个 IP 地址，通常情况下用户使用该地址作为网关地址。而虚拟 MAC 地址的格式是"0000-5e00-01xx"，其中 xx 为 VRID。
Master 路由器： "Master 路由器"在一个 VRRP 组中承担报文转发任务。在每一个 VRRP 组中，只有 Master 路由器才会响应针对虚拟 IP 地址的 ARP Request。Master 路由器会以一定的时间间隔周期性地发送 VRRP 报文，以便通知同一个 VRRP 组中的 Backup 路由器关于自己的存活情况。
Backup 路由器： 也被称为备份路由器。Backup 路由器将会实时侦听 Master 路由器发送出来的 VRRP 报文，它随时准备接替 Master 路由器的工作。
Priority： 优先级值是选举 Master 路由器和 Backup 路由器的依据，优先级取值范围 0-255，值越大越优先，值相等则比较接口 IP 地址大小，大者优先。

注释： VRID 相同是同一组的前提条件，Master 负责转发流量，Backup 静默监听。优先级 255 是特殊值，表示"IP 地址拥有者"，无条件成为 Master。

VRRP 报文格式

在这里插入图片描述

VRRP 只有一种报文，即 Advertisement 报文，基于组播方式发送，因此只能在同一个广播域传递。

Advertisement 报文的目的组播地址为 224.0.0.18。

VRRP 报文字段含义如下：

Ver： VRRP 目前有两个版本，其中 VRRPv2 仅适用于 IPv4 网络，VRRPv3 适用于 IPv4 和 IPv6 两种网络。
Virtual Rtr ID： 该报文所关联的虚拟路由器的标识。
Priority： 发送该报文的 VRRP 路由器的优先级。
Count IP Addrs： 该 VRRP 报文中所包含的虚拟 IP 地址的数量。
Auth Type： VRRP 支持三种认证类型：不认证、纯文本密码认证、MD5 方式认证，对应值分别为 0、1、2。
Adver Int： 发送 VRRP 通告消息的间隔。默认为 1 秒。
IP Address： 所关联的虚拟路由器的虚拟 IP 地址，可以为多个。
Authentication Data： 验证所需要的密码信息。

VRRP 定时器

在 VRRP 协议工作过程中，VRRP 定义了两个定时器：

ADVER_INTERVAL 定时器： Master 发送 VRRP 通告报文时间周期，缺省值为 1 秒。
MASTER_DOWN 定时器： Backup 设备监听该定时器超时后，会变为 Master 状态。

MASTER_DOWN 定时器计算公式如下：

MASTER_DOWN =（3 * ADVER_INTERVAL）+ Skew_time（偏移时间）

其中，Skew_Time =（256 – Priority）/ 256

注释： Skew_Time 的作用是确保高优先级节点在启动时有足够的时间抢占 Master 角色。优先级越高，Skew_Time 越小，抢占越快。

VRRP 协议状态

在这里插入图片描述

VRRP 主备选举

在这里插入图片描述

初始创建 VRRP 的设备工作在 Initialize 状态，收到接口 Up 的消息后，若此设备的优先级小于 255，则会先切换至 Backup 状态，等待 MASTER_DOWN 定时器超时后再切换至 Master 状态。

如果优先级高的设备先启动，优先级低的设备后启动，则优先级高的设备先进入 Master 状态，优先级低的设备收到高优先级的 VRRP 通告报文，自己仍处于 Backup 状态。

如果优先级低的先启动，优先级高的后启动，则优先级低的先由 Backup 状态切换为 Master 状态，优先级高的设备收到优先级低的 VRRP 通告报文，重新进行选举，将优先级高的设备切换为 Master 状态。

通常情况下，VRRP 路由器的接口 IP 地址不会与虚拟路由器的 IP 地址重叠，也就是说我们会为虚拟路由器单独规划一个 IP 地址，而不会使用某台路由器的接口 IP 地址。当然也存在一个特殊的情况，例如在某些网络中 IP 地址资源比较紧缺，那么也有可能会将某台路由器的接口 IP 地址用于虚拟路由器，此时该路由器将无条件成为 Master。

无法手动将 VRRP 接口优先级配置为 255，当接口 IP 地址为 IP 地址拥有者时，优先级自动成为 255。
在这里插入图片描述

VRRP 主备切换

在这里插入图片描述

当 Master 设备主动放弃 Master 地位（如 Master 设备退出备份组）时，会发送优先级为 0 的通告报文，用来使 Backup 设备快速切换成 Master 设备，而不用等到 MASTER_DOWN 定时器超时。这个切换的时间称为 Skew_time。

当 Master 设备发生网络故障而不能发送通告报文的时候，Backup 设备并不能立即知道其工作状况。等到 MASTER_DOWN 定时器超时后，才会认为 Master 设备无法正常工作，从而将状态切换为 Master。

注释： 主动切换（优先级 0）比故障切换（等 MASTER_DOWN 超时）快得多，因为主动切换不需要等待超时，而故障切换至少要等 3 秒（3 × 1 秒广告间隔）。

Keepalived VRRP 工作原理

Keepalived 通过 VRRP 实现高可用性，它还能实现对集群中服务器运行状态的监控以及故障隔离。

Keepalived 工作在 TCP/IP 参考模型的 三层、四层、七层，也就是分别为：网络层、传输层和应用层。

根据 TCP/IP 参数模型隔层所能实现的功能，Keepalived 运行机制如下：

网络层： 提供四个重要的协议，互联网络 IP 协议、互联网络可控制报文协议 ICMP、地址转换协议 ARP、反向地址转换协议 RARP。Keepalived 在网络层采用最常见的工作方式是通过 ICMP 协议向服务器集群中的每一个节点发送一个 ICMP 数据包（有点类似与 Ping 的功能），如果某个节点没有返回响应数据包，那么认为该节点发生了故障，Keepalived 将报告这个节点失效，并从服务器集群中剔除故障节点。
传输层： 提供两个主要的协议：传输控制协议 TCP 和用户数据协议 UDP。传输控制协议 TCP 可以提供可靠的数据输出服务、IP 地址和端口，代表 TCP 的一个连接端，要获得 TCP 服务，需要在发送机的一个端口和接收机的一个端口上建立连接。Keepalived 在传输层里利用了 TCP 协议的端口连接和扫描技术来判断集群节点的端口是否正常，比如对于常见的 WEB 服务器 80 端口。或者 SSH 服务 22 端口，Keepalived 一旦在传输层探测到这些端口号没有数据响应和数据返回，就认为这些端口发生异常，然后强制将这些端口所对应的节点从服务器集群中剔除掉。
应用层： 可以运行 FTP，TELNET，SMTP，DNS 等各种不同类型的高层协议，Keepalived 的运行方式也更加全面化和复杂化，用户可以通过自定义 Keepalived 工作方式，例如：可以通过编写程序或者脚本来运行 Keepalived，而 Keepalived 将根据用户的设定参数检测各种程序或者服务是否允许正常，如果 Keepalived 的检测结果和用户设定的不一致时，Keepalived 将把对应的服务器从服务器集群中剔除。

注释： Keepalived 的多层健康检查能力是其核心优势——网络层 Ping、传输层端口探测、应用层脚本检测，层层递进，确保故障及时发现。

VRRP 脑裂

脑裂的定义

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

脑裂产生的原因

脑裂的核心是节点间心跳检测失败，但实际节点均正常运行，常见情况可能导致：

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

脑裂的危害

双节点同时持有虚拟 IP（VIP），导致客户端请求混乱（部分请求成功，部分失败）。
若集群管理的是数据库、存储等资源，可能引发数据不一致（如双写冲突）。
集群失去高可用意义，甚至因资源竞争导致服务崩溃。

如何避免脑裂？

通过 多重检测机制 和 资源隔离策略 预防脑裂，常用方案如下：

1. 增加心跳检测线路

除了主网络，添加备用通信线路（如独立网卡、交叉网线），避免单线路故障导致心跳中断。

在 keepalived.conf 中指定多网卡检测：

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

2. 启用 VRRP 认证

配置节点间的认证机制，防止非法节点干扰集群，同时确保心跳信息的可靠性。

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

3. 配置防火墙规则

允许节点间通过 VRRP 协议通信（开放 UDP 112 端口）：

# 允许VRRP协议（CentOS示例）
firewall-cmd --add-protocol=vrrp --permanent
firewall-cmd --reload

4. 部署第三方检测工具

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

示例：在 keepalived.conf 中配置 notify 脚本，检测到节点成为主节点后，检查对方是否存活，若存活则强制关闭对方服务：

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 操作。

5. 降低脑裂影响范围

结合业务层设计，如数据库使用主从复制 + 读写分离，避免双写冲突；存储使用分布式锁（如 Redis）控制资源独占。

限制虚拟 IP 的使用场景，仅在确认集群状态正常时对外提供服务。

6. 监控与告警

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

注释： 脑裂是分布式系统中最危险的问题之一。"多重检测 + 自动隔离"是核心思路——多线路心跳降低误判概率，脚本和第三方工具在脑裂发生时快速隔离异常节点。

总结

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

Keepalived 高可用技术实践

网络拓扑

在这里插入图片描述

注释： 以下实验环境包含 3 台服务器：1 台客户端 + 2 台 Web 服务器（主备部署 Keepalived）。

基础配置

服务器规划

主机名	IP 地址	服务器角色
client1.hyc.cloud	10.1.8.21	客户端
web1.hyc.cloud	10.1.8.11	Web 服务器
web2.hyc.cloud	10.1.8.12	Web 服务器

主机名、IP 地址、网关

# client1
hostnamectl set-hostname client1.hyc.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.hyc.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.hyc.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

注释： 所有节点的基础网络配置需一致，确保节点间可以互相通信。

配置 Web

# 在 web1 和 web2 上部署 Nginx
wget -O /etc/yum.repos.d/epel.repo http://mirrors.aliyun.com/repo/epel-7.repo
yum install -y nginx
echo "Welcome to $(hostname)" > /usr/share/nginx/html/index.html
systemctl enable nginx.service --now

验证后端 Nginx：

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

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

配置 Keepalived

配置 web2（备节点）

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

! 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 hyc@123          # 密码长度不能超过8位(超过则只取前8位)
    }
    virtual_ipaddress {
        10.1.8.100/24
    }
}

注释： 各配置项说明：

router_id web2 — 定义路由器名称，每个节点使用不同的名称。
state BACKUP — 定义节点角色为备节点，MASTER 则代表主节点。
interface ens33 — 定义 VIP 配置到该接口。
virtual_router_id 51 — 定义虚拟路由器 ID，范围 1-255，每个节点使用相同值。
priority 100 — 定义节点优先级，值越大优先级越高。
authentication — 定义心跳认证。
virtual_ipaddress — 定义虚拟 VIP。

配置 web1（主节点）

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

! 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 hyc@123
    }
    virtual_ipaddress {
        10.1.8.100/24
    }
}

注释： web1 的 priority 为 110，高于 web2 的 100，因此 web1 将竞选为 Master。

高可用验证

# 在 web1 上启动 keepalived
[root@web1 ~]# systemctl enable keepalived.service --now

# 查看 IP，VIP 切换到 web1
[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

[root@web2 ~]# ip -br a show ens33
ens33           UP              10.1.8.12/24 fe80::20c:29ff:fe83:619c/64

访问 Web：

[root@client1 ~]# curl 10.1.8.100
Welcome to web1.hyc.cloud

关闭 web1 的 Keepalived 服务，测试故障切换：

[root@web1 ~]# systemctl stop keepalived.service

[root@client1 ~]# curl 10.1.8.100
Welcome to web2.hyc.cloud

再次启动 web1 的 Keepalived 服务，测试主节点抢占：

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

[root@client1 ~]# curl 10.1.8.100
Welcome to web1.hyc.cloud

注释： 以上验证了 Keepalived 的高可用切换能力：主节点故障时备节点自动接管 VIP，主节点恢复后重新抢占（因为 priority 更高）。

Keepalived 配置文件

配置文件位置：/etc/keepalived/keepalived.conf

配置文件主要包括三部分：

GLOBAL： 全局配置部分
VRRPD： VRRP 协议配置部分
LVS： LVS 服务管理配置部分

完整示例

! 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通告中的所有地址是很耗时的。设置这个标志意味着，
    # 如果这个通告和之前接收到的通告来自同一个主路由器，则不会执行检查。
    vrrp_skip_check_adv_addr

    # 严格遵守VRRP协议。
    vrrp_strict

    # 接口发送免费ARP消息的延迟毫秒数
    vrrp_garp_interval 0

    # 接口发送未经请求的NA消息的延迟毫秒数
    vrrp_gna_interval 0
}

# VRRP协议配置
# VI_1是虚拟实例名称，可自定义
vrrp_instance VI_1 {
    # 指定当前节点角色，可以值为MASTER和BACKUP，这里的值不重要。
    # 配置文件的 state 只是启动初始状态，实际会根据 priority 优先级竞选。
    state MASTER

    # VIP使用的接口
    interface eth0

    # 从0到255的任意唯一数字，用于区分VRRPD的多个实例，
    # 同一个高可用集群使用相同的id
    virtual_router_id 51

    # 用于选举为MASTER，高于其他节点50，将成为MASTER
    priority 100

    # VRRP通告之间间隔，1s
    advert_int 1

    # VRRP通告认证凭据
    authentication {
        auth_type PASS
        auth_pass 1111
    }

    # 提供的VIP列表，还可以通过<IPADDR>/<MASK>指定多个地址
    virtual_ipaddress {
        192.168.200.16
        192.168.200.17
        192.168.200.18
    }
}

# LVS服务管理配置
# 虚拟服务器是 192.168.200.100 443
virtual_server 192.168.200.100 443 {
    # delay timer for service polling
    delay_loop 6

    # LVS scheduler，支持lb_algo rr|wrr|lc|wlc|lblc|sh|dh
    lb_algo rr

    # LVS forwarding method，支持NAT|DR|TUN
    lb_kind NAT

    # LVS persistence timeout in seconds, default 6 minutes
    persistence_timeout 50

    # L4 protocol，支持TCP|UDP|SCTP
    protocol TCP

    # one entry for each realserver
    real_server 192.168.201.100 443 {
        # relative weight to use, default: 1
        weight 1
    }
}

注释： 以上是一个完整的 Keepalived 配置示例，包含了全局配置、VRRP 实例配置和 LVS 负载均衡配置。实际使用时根据需求裁剪。详细信息可参考 keepalived.conf(5) 手册。

Keepalived 日志

配置 Keepalived 心跳日志

# 在 web1 和 web2 节点上编辑
[root@web1,web2 ~]# vim /etc/sysconfig/keepalived
# 第14行修改为：
14 KEEPALIVED_OPTIONS="-D -d -S 0"

参数含义：

-D：后台守护进程模式（Daemon），默认必带
-d：开启 debug 调试日志，日志会打印更多 VRRP 细节，会打大量日志到 /var/log/messages
-S 0：syslog facility 0，使用 LOG_SYSLOG 设施输出日志

注释： ⚠️ -d debug 模式生产环境不建议长期开，日志量非常大，会刷爆 messages。排查问题临时打开，问题解决后要删掉 -d。

将 Keepalived 日志单独输出

[root@web1,web2 ~]# vim /etc/rsyslog.d/keepalived.conf
# 添加以下内容：
local0.*                /var/log/keepalived.log  # 把keepalived日志单独输出到
                                                # /var/log/keepalived.log，不再混在/var/log/messages

重启日志服务和 Keepalived：

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

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

生产实践

场景描述

初始 web1 是 Master，web2 是 Backup。web1 挂了，web2 成为 Master；web1 又恢复了，为了保持稳定性不抢占，维持 Backup 身份。当 web2 挂了，web1 成为 Master。

注释： 这是生产环境推荐的双主模式——两个节点都配置为 BACKUP + nopreempt，避免主节点恢复后频繁切换导致业务抖动。

配置 web1（nopreempt 模式）

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

! 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 hyc@124
    }
    virtual_ipaddress {
        10.1.8.100/24
    }
}

注释： nopreempt 是关键配置——即使当前节点优先级更高，也不会主动抢占 Master 角色，只有当 Master 故障时才会接管。这避免了主节点恢复后 VIP 来回切换导致的业务抖动。

启动并验证：

[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

配置 web2（nopreempt 模式）

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

! 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 hyc@123
    }
    virtual_ipaddress {
        10.1.8.100/24
    }
}

启动并验证：

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

测试故障切换

将 web1 Master 关掉，web2 成为 Master：

[root@web1 ~]# systemctl stop keepalived.service

# web2成为master
[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 Keepalived 服务恢复，观察现象（master 还是 web2，因为 nopreempt）：

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

[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 Keepalived 关掉，观察 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

注释： 在 nopreempt 模式下，一旦 web2 接管了 Master，即使 web1 恢复也不会抢回 VIP，直到 web2 再次故障。这种模式适合对稳定性要求高的生产环境。

总结

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

它通过优先级配置确定主节点，主节点故障时，备节点自动接管 VIP 与服务，实现无缝切换；还可搭配健康检查脚本，实时监测后端服务状态。常与 LVS、Nginx 等负载均衡工具联动，解决单点故障问题，为 Web、数据库等服务构建稳定的高可用架构。

注释： 本文从 VRRP 协议原理出发，到 Keepalived 的配置实践，覆盖了从理论到生产的核心知识点。脑裂防范、nopreempt 模式、日志排查等生产级话题也一并涵盖

标签

#云计算