文章目录
高可用-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（Vritrual Router Redundancy Protocol,虚拟路由冗余 协议)出现的目的是解决静态路由出现的单点故障问题，通过VRRP可以实现网络不间断稳定运行，因此 Keepalvied 一方面具有服务器状态检测和故障隔离功能，另外一方面也有HA cluster功能。
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地址大小，大者优先。
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
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。
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将把对应的服务器从服务器集 群中剔除。
VRRP 脑裂
脑裂的定义
在 keepalived 高可用集群中，脑裂（Split-Brain） 是指主从节点（或双主节点）之间因通信中断，导 致各自认为对方故障，从而同时争抢资源（如虚拟 IP），引发集群状态混乱的现象。
脑裂产生的原因
脑裂的核心是节点间心跳检测失败，但实际节点均正常运行，常见情况可能导致:
- 网络问题：主从节点间的心跳线路（如专用网线、交换机）故障、断网或延迟过高。
- 防火墙规则：节点间的 VRRP 协议端口（默认 112 端口，UDP 协议）被防火墙屏蔽。
- 资源耗尽：某节点因 CPU、内存耗尽或负载过高，无法响应心跳请求。
- 配置错误： keepalived 配置中 vrrp_instance 的state 、 priority 或 authentication 等参数不一致，导致节点间无法正常协商。
脑裂的危害
- 双节点同时持有虚拟 IP（VIP），导致客户端请求混乱（部分请求成功，部分失败）。
- 若集群管理的是数据库、存储等资源，可能引发数据不一致（如双写冲突）。
- 集群失去高可用意义，甚至因资源竞争导致服务崩溃。
如何避免脑裂？
通过 多重检测机制 和 资源隔离策略 预防脑裂，常用方案如下：
- 增加心跳检测线路
除了主网络，添加备用通信线路（如独立网卡、交叉网线），避免单线路故障导致心跳中断。
在 keepalived.conf中指定多网卡检测
bash
vrrp_instance VI_1 {
state MASTER
interface eth0 # 主网卡
virtual_router_id 51
priority 100
advert_int 1
# 同时检测备用网卡（如eth1）
track_interface {
eth0
eth1
}
}- 启用 VRRP 认证
配置节点间的认证机制，防止非法节点干扰集群，同时确保心跳信息的可靠性。
bash
vrrp_instance VI_1 {
# ... 其他配置
authentication {
auth_type PASS # 认证类型（PASS或AH）
auth_pass 123456 # 密码（所有节点必须一致）
}
}- 配置防火墙规则
允许节点间通过 VRRP协议通信（开放 UDP 112 端口）：
bash
# 允许VRRP协议（CentOS示例）
firewall-cmd --add-protocol=vrrp --permanent
firewall-cmd --reload- 部署第三方检测工具
使用 fe nce 机制（如 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、端口检测等方式确认对方状态，若脑裂则执行
bash
kill或
bash
reboot操作。
- 降低脑裂影响范围
-
结合业务层设计，如数据库使用主从复制 + 读写分离，避免双写冲突；存储使用分布式锁（如 Redis）控制资源独占。
-
限制虚拟 IP 的使用场景，仅在确认集群状态正常时对外提供服务。
- 监控与告警
通过 z abbix 、 prometheus 等工具监控keepalived 状态（如 vrrp_script 检测），当发现双 主节点同时存在时及时告警。
总结
脑裂的本质是节点通信失效与状态判断不一致，预防核心在于 "多重检测 + 自动隔离"：通过多线路心 跳、认证机制降低误判概率，结合脚本和第三方工具在脑裂发生时快速隔离异常节点，同时配合监控及 时干预，保障集群稳定。
Keepalived高可用技术实践
网络拓扑
| 主机名 | IP 地址 | 服务器角色 |
|---|---|---|
| client1.mrj.cloud | 10.1.8.21 | 客户端 |
| web1.mrj.cloud | 10.1.8.11 | Web 服务器 |
| web2.mrj.cloud | 10.1.8.12 | Web 服务器 |
基础配置
主机名、IP地址、网关
bash
# client1
hostnamectl set-hostname client1.mrj.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.mrj.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.mrj.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
bash
[root@web1-2 ~]#
# 部署 web
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.mrj.cloud
[root@client1 ~]# curl 10.1.8.12
Welcome to web2.mrj.cloud配置 keepalived
配置 web2
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 mrj@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。
bash
# 启动 keepalived 服务
[root@web2 ~]# systemctl enable keepalived.service --now
# 查看 IP
[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配置 web1
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 xiaoma@123
}
virtual_ipaddress {
10.1.8.100/24
}
}
bash
# 启动服务
[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高可用验证
bash
# 访问 web
[root@client1 ~]# curl 10.1.8.100
Welcome to web1.mrj.cloud
[root@client2 ~]# curl 10.1.8.100
Welcome to web1.mrj.cloud
# 关闭 web1 的 keepalive服务，再次访问
[root@web1 ~]# systemctl stop keepalived.service
[root@client1 ~]# curl 10.1.8.100
Welcome to web2.mrj.cloud
# 再次启动 web1 的keepalive服务，再次访问
[root@web1 ~]# systemctl start keepalived.service
[root@client1 ~]# curl 10.1.8.100
Welcome to web1.mrj.cloudkeepalived 配置文件
配置文件位置：/etc/keepalived/keepalived.conf
配置文件主要包括三部分：
- GLOBAL，全局配置部分
- VRRPD ，VRRP协议配置部分
- 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通告中的所有地址是很耗时的。设置这个标志意味着，如果这个通告和之前接收到的通告
来自同一个主路由器，则不会执行检查。
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 日志
bash
# 以下步骤在 web1 和 web2 节点完成
[root@web1,web2 ~]# vim /etc/sysconfig/keepalived
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。
[root@web1,web2 ~]# vim /etc/rsyslog.d/keepalived.conf
local0.* /var/log/keepalived.log #把keepalived 日志单独输出到 /var/log/keepalived.log，不再混在 /var/log/messages。
# 重启日志服务
[root@web1,web2 ~]# systemctl restart rsyslog
# 重启 keepalived,观察日志
[root@web1,web2 ~]# systemctl restart keepalived.service
# 监控日志
[root@web1,web2 ~]# tail -f /var/log/keepalived.logKeepalived 心跳
参数：mcast_src_ip。
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 mrj@123
}
virtual_ipaddress {
10.1.1.10/24
}
}生产实践
配置keepalived配置文件
初始web1是master,web2是backup
web1挂了，web2成为master，web1又恢复了为了保持稳定性不抢占维持backup身份，当web2挂了， web1成为master
bash
# 配置web1
[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 xiaoma@124
}
virtual_ipaddress {
10.1.8.100/24
}
}
[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
# 配置web2
[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 xiaoma@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
#将web1 keepalived服务恢复，观察现象
[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
# 把web2 keepalived关掉，观察web1
[root@web1 ~]# ip -br a
lo UNKNOWN 127.0.0.1/8 ::1/128
ens33 UP 10.1.8.11/24 总结
Keepalived 基于 VRRP 协议实现高可用，核心通过虚拟 IP（VIP）对外提供统一访问入口，支持主从、双 主两种部署模式。
它通过优先级配置确定主节点，主节点故障时，备节点自动接管 VIP 与服务，实现无缝切换；还可搭配 健康检查脚本，实时监测后端服务状态。常与 LVS、Nginx 等负载均衡工具联动，解决单点故障问题，为 Web、数据库等服务构建稳定的高可用架构