LVS负载均衡集群与LVS+Keepalived集群

一、DR模式LVS负载均衡群集

1.1 企业群集应用概述

① 群集的含义

Cluster，集群、群集 由多台主机构成，但对外只表现为一个整体，只提供一个访问入口（域名与IP地址），相当于一台大型计算机。

② 问题

互联网应用中，随着站点对硬件性能、响应速度、服务稳定性、数据可靠性等要求越来越高，单台服务器已经无法满足负载均衡及高可用的要求

③ 解决方法

使用价格昂贵的小型机、大型机 使用普通服务器构建服务群集 通过整合多台服务器，使用LVS来达到服务器的高可用和负载均衡，并以同一个 IP地址对外提供相同的服务。

在企业中常用的一种群集技术------LVS (Linux Virtual Server，Linux虚拟服务器)

1.2 企业群集分类

根据群集所针对的目标差异，可分为三种类型 ：负载均衡群集、高可用群集、高性能运算群集

① 负载均衡群集（Load Balance Cluster）

提高应用系统的响应能力、尽可能处理更多的访问请求、减少延迟为目标，获得高并发、高负载（LB）的整体性能

LB的负载分配依赖于主节点的分流算法：访问请求分担给多个服务器节点，从而缓解整个系统的负载压力。例如，"DNS轮询""反向代理"等

② 高可用群集（High Availability Cluster）

提高应用系统的可靠性、尽可能地减少中断时间为目标，确保服务的连续性，达到高可用（HA）的容错效果

HA的工作方式包括双工和主从两种模式

③ 高性能运算群集（High Performance Computer Cluster）

提高应用系统的CPU运算速度、扩展硬件资源和分析能力为目标，获得相当于大型、超级计算机的高性能运算（HPC）能力

高性能依赖于"分布式运算"、"并行计算"，通过专用硬件和软件将多个服务器的CPU、内存等资源整合在一起，实现只有大型、超级计算机才具备的计算能力

1.3 负载均衡群集架构

1.3.1 负载均衡的结构

第一层，负载调度器（Load Balancer或Director）

访问整个群集系统的唯一入口，对外使用所有服务器共有的VIP地址，也称为群集IР地址。通常会配置主、备两台调度器实现热备份，当主调度器失效以后能够平滑替换至备用调度器，确保高可用性。

第二层，服务器池（Server Pool）

群集所提供的应用服务、由服务器池承担，其中每个节点具有独立的RIP地址(真实IP），只处理调度器分发过来的客户机请求。当某个节点暂时失效时，负载调度器的容错机制会将其隔离，等待错误排除以后再重新纳入服务器池。

第三层，共享存储（Share Storage）

为服务器池中的所有节点提供稳定、一致的文件存取服务，确保整个群集的统一性。共享存储可以使用NAS设备，或者提供NFS共享服务的专用服务器。

1.3.2 负载均衡群集工作模式

负载均衡群集是目前企业用得最多的群集类型

群集的负载调度技术有三种工作模式 ：地址转换 、IP隧道 、直接路由

① NAT模式---地址转换（Network Address Translation，简称NAT模式）

类似于防火墙的私有网络结构，负载调度器作为所有服务器节点的网关，即作为客户机的访问入口，也是各节点回应客户机的访问出口；服务器节点使用私有IP地址，与负载调度器位于同一个物理网络，安全性要优于其他两种方式。

② TUN模式 ---IP隧道 （IP Tunnel，简称TUN模式）

采用开放式的网络结构，负载调度器仅作为客户机的访问入口，各节点通过各自的Internet连接直接回应客户机，而不再经过负载调度器；服务器节点分散在互联网中的不同位置，具有独立的公网IP地址，通过专用IP隧道与负载调度器相互通信。

③ DR模式 ---直接路由 （Direct Routing，简称DR模式）

采用半开放式的网络结构，与TUN模式的结构类似，但各节点并不是分散在各地，而是与调度器位于同一个物理网络； 负载调度器与各节点服务器通过本地网络连接，不需要建立专用的IP隧道。

④ 三种工作模式的对比

|-------------|---------------------------------------------|--------------------------------------|
| 模式 | 原理 | 优缺点 |
| NAT（VS/NAT） | Director 改变数据包目标IP并转发， RS响应包回到Director再发客户端 | 优点：节点可任意OS； 缺点：Director是瓶颈 |
| DR（VS/DR） | Director 改变目标MAC地址，RS直接 响应客户端 | 优点：Director不处理响应； 缺点：节点需与Director同网段 |
| TUN（VS/TUN） | Director 封装IP包到隧道，RS解封直 接响应客户端 | 优点：Director不处理响应； 缺点：节点需支持IP隧道 |

⑤ 关键差异说明：

nat：通过地址转换实现，配置简单但存在单点瓶颈。

tun：基于IP隧道封装，跨越复杂网络但需额外开销。

DR：直接路由模式，性能最优但依赖二层互通。

1.3.3 LVS****调度算法

固定调度：rr、wrr、dh、sh
动态调度：lc、wlc、lblc

|--------|--------------|
| 算法 | 描述 |
| rr | 轮询，每个RS均摊 |
| wrr | 加权轮询，权重高的分配多 |
| dh | 目的地址哈希分配 |
| sh | 源地址哈希分配 |
| lc | 最少连接数 |
| wlc | 加权最少连接 |
| lblc | 基于地址的最少连接 |

1.3.4 Nginx vs LVS vs HAProxy****区别

|---------------------------|------------------------------------------|----------------------------------------------|--------------------------------------|
| 特性 | Nginx | LVS（Linux Virtual Server） | HAProxy |
| 定位 | Web 服务器 + 反向代理 + 负载均衡 | 内核级四层负载均衡 | 专业负载均衡器（四层 +七层） |
| 工****作 层****级 | 四层（TCP）+ 七层 （HTTP/HTTPS） | 四层（TCP/UDP，传输层） | 四层 + 七层 |
| 性****能 | 高（软件级，单机可达 十万级并发） | 极高（内核态，百万级并发） | 高（接近 Nginx，但更专注负载均衡） |
| 功****能 特****点 | - 静态资源服务- 反向代 理- 缓存- 支持 HTTP/HTTPS 负载均衡 | - 高性能转发- 调度算法丰富 （RR、LC、SH...）- 内核态转发，几乎无性能损耗 | - 专注于负载均衡- 健康检查更强大- 支持会话保持、SSL 卸载等 |
| 健****康 检****查 | 简单（TCP/HTTP） | 依赖 Keepalived 或其他工具 | 强大（多协议、多方式） |
| 配置复杂度 | 简单 | 较复杂（需 ipvsadm/keepalived 配合） | 中等（配置文件灵活） |
| 适****用 场****景 | Web 代理、动静分离、 中小型集群 | 超大规模集群、核心四层调度 | 高可用集群、对健康检查要求高的业务 |
| 优缺点 | 优点：功能多，易上手 缺点：七层性能不如 LVS/HAProxy | 优点：性能最强，稳定 缺点：只能四层，配置偏复杂 | 优点：专业负载均衡，健康检查强 缺点：不自带Web 服务 |

一句话总结：
Nginx：轻量、全能，适合 Web 服务和中小型负载均衡。
LVS：极致性能，适合四层超大规模集群，但功能单一。
HAProxy：专业负载均衡器，四层+七层都行，健康检查能力最强。

1.4 LVS DR****模式详解

LVS-DR（Direct Routing）模式是 LVS 集群中性能最高的一种工作模式。其核心思想是通过修改数据包的 MAC 地址，将请求转发到后端的真实服务器（Real Server），而真实服务器处理完请求后，直接响应客户端，不再经过调度器（Director）。这样可以极大减轻调度器的网络负载，提高系统吞吐量。

1.1.1****数据包流向分析

① 客户端**→Director（负载均衡器）**
客户端发送请求到 VIP（虚拟IP），数据包到达 Director Server 内核空间。
② Director**→Real Server（真实服务器）**
Director 判断数据包目标IP为VIP，是集群服务请求，修改：
目标MAC：Real Server MAC
源MAC：Director Server MAC
IP地址保持不变，发送到 Real Server。
③ Real Server****处理请求
接收报文（目标MAC为自身），通过 lo 接口配置 VIP 处理请求。
响应报文源IP为 VIP，目标IP为客户端（CIP），直接发送给客户端。
④ 客户端接收响应
响应报文不经过 Director Server。

1.1.2 DR****模式特点

Director Server 与 Real Server 必须在同一物理网络。
Real Server 可以使用私有或公网地址。
Director 仅作为请求入口，不作为网关。
所有请求经过 Director，响应直接由 Real Server 发送。
Real Server 的网关不能指向 Director Server。
Real Server 的 lo 接口配置 VIP。

1.4DR模式部署步骤

1.4.0****环境规划

①****服务器规划

DR 服务器：192.168.186.20
Web 服务器1：192.168.186.19
Web 服务器2：192.168.186.23
vip：192.168.186.180 （虚拟IP，再DR服务器上配置）

② 环境架构

1.4.1****配置负载调度器（Director Server）

环境部署
IP： 192.168.186.20
VIP： 192.168.186.180
**(1)**系统配置

systemctl stop firewalld.service
setenforce 0
modprobe ip_vs
yum -y install ipvsadm

(2)配置虚拟IP

cd /etc/sysconfig/network-scripts/
cp ifcfg-ens33 ifcfg-ens33:0

vim ifcfg-ens33:0
# 内容
DEVICE=ens33:0
ONBOOT=yes
IPADDR=192.168.186.180
NETMASK=255.255.255.255

# 启动新网卡
ifup ens33:0
# 查看新网卡
ifconfig ens33:0

**(3)**调整内核参数

vim /etc/sysctl.conf
# 添加
net.ipv4.ip_forward = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.ens33.send_redirects = 0

# 查看已调整参数
sysctl -p

(4)配置LVS****服务及调度

ipvsadm -C
ipvsadm -A -t 192.168.186.180:80 -s rr
ipvsadm -a -t 192.168.186.180:80 -r 192.168.186.19:80 -g
ipvsadm -a -t 192.168.186.180:80 -r 192.168.186.23:80 -g
ipvsadm -ln # 查看节点状态，Route代表DR模式

1.4.2****配置节点服务器（Real Server）

IP： 192.168.186.19 、 192.168.186.23
(1)配置VIP****到lo 接口

cd /etc/sysconfig/network-scripts/
cp ifcfg-lo ifcfg-lo:0
vim ifcfg-lo:0
# 内容
DEVICE=lo:0
ONBOOT=yes
IPADDR=192.168.186.180
NETMASK=255.255.255.255


ifup lo:0
ifconfig lo:0
route add -host 192.168.186.180 dev lo:0

(2) ARP参数调整，避免MAC****冲突

vim /etc/sysctl.conf
net.ipv4.conf.lo.arp_ignore = 1
net.ipv4.conf.lo.arp_announce = 2
net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.all.arp_announce = 2

sysctl -p

(3)安装Web****服务（以httpd为例，yum安装即可）

# 192.168.186.19
echo 'this is 192.168.186.19 web01!' > /var/www/html/index.html

# 192.168.186.23
echo 'this is 192.168.186.23 web02!' > /var/www/html/index.html

节点服务器启动httpd
调度服务器启动ipvsadm

(4) 启动并测试web服务

1.4.3测试LVS****群集

在客户端浏览器访问： http://192.168.10.180/
应轮询显示不同节点页面内容。
注意：LVS-DR用户访问http://192.168.10.180/ 下次刷新时 延迟50秒

二、LVS+Keepalived群集

Keepalived 是一个基于VRRP协议来实现的LVS服务高可用方案，可以解决静态路由出现的单点故障问题。

2.1 Keepalive概述

Keepalived软件起初是专为 LVS负载均衡软件设计的，用来管理并监控LVS集群中各个服务节点的状态，后来又加入了可以实现高可用的 VRRP 功能。因此，Keepalived除了能够管理LVS集群外，还可以为其他服务（例如：Nginx、Haproxy、MySQL等）实现高可用。

keepalived 软件主要是通过 VRRP 协议实现高可用功能的。VRRP 是 Virtual Router Redundancy Protocol（虚拟路由器冗余协议）的缩写，VRRP出现的目的就是为了解决静态路由单点故障的问题，它能够保证当个别节点宕机时，整个网络可以不间断地运行。

在一个LVS服务集群中通常有主服务器（MASTER）和备份服务器（BACKUP）两种角色的服务器，但是对外表现为一个虚拟IP，主服务器会发送VRRP通告信息给备份服务器，当备份服务器收不到VRRP消息的时候，即主服务器异常的时候，备份服务器就会接管虚拟IP，继续提供服务，从而保证了高可用性。

官方地址：www.keepalive.org

2.2 Keepalived体系主要模块及其作用

keepalived体系架构中主要有三个模块，分别是core、check和vrrp。
core模块：为keepalived的核心，负责主进程的启动、维护及全局配置文件的加载和解析。
vrrp模块：是来实现VRRP协议的。 主备问题
check模块：负责健康检查，常见的方式有端口检查及URL检查。 检查后端服务

2.3 keepalive 服务重要功能

2.3.1.管理 LVS 负载均衡软件

Keepalive可以通过读取自身的配置文件，实现通过更底层的接口直接管理LVS的配置以及控制服务的启动，停止功能。

2.3.2 支持故障自动切换（Failover）

Keepalive可以实现任意两台主机之间，例如Master和Backup主机之间的故障转移和自动切换，这个主机可以是普通的不能停机的业务服务器，也可以是LVS负载均衡，Nginx反向代理这样的服务器。

Keepalive高可用功能实现的简单原理为，两台主机同时安装好Keepalive软件并启动服务，开始正常工作时，由角色为Master的主机获得所有资源并对用户提供服务，角色为Backup的主机作为Master主机的热备；当角色为Master的主机失效或出现故障时，角色为Backup的主机将自动接管Master主机的所有工作，包括接管VIP资源及相应资源服务；而当角色为Master的主机故障修复后，又会自动接管回它原来处理的工作，角色为Backup的主机则同时释放Master主机失效时它接管的工作，此时，两台主机将恢复到最初启动时各自的原始角色及工作状态。

2.3.3 实现 LVS 集群中节点的健康检查（Health Checking）

Keepalive可以通过在自身的Keepalive.conf文件里配置LVS的节点IP和相关参数实现对LVS的直接管理；除此之外，当LVS集群中的某一个甚至是几个节点服务器同时发生故障无法提供服务时，Keepalive服务会自动将失效的节点服务器从LVS的正常转发队列中清除出去，并将请求调度到别的正常节点服务器上，从而保证最终用户的访问不受影响；当故障的节点服务器被修复以后，Keepalive服务又会自动地把它们加入到正常转发队列中，对客户提供服务。

2.3.4 实现 LVS 负载调度器、节点服务器的高可用性（HA）

一般企业集群需要满足的三个特点：负载均衡、健康检查、故障切换，使用 LVS + Keepalive完全可以满足需求。

2.3.5 keepalive高可用故障切换转移原理

keepalive 高可用服务对集群之间的故障切换转移，是通过 VRRP（虚拟路由器冗余协议）来实现的。

在keepalive服务正常工作时，主（Master）节点会不断地向备（Backup）节点发送（多播的方式）心跳消息，用以告诉备节点自己还活看，当主节点发生故障时，就无法发送心跳消息，备节点也就因此无法继续检测到来自主节点的心跳了，于是调用自身的接管程序，接管主节点的IP资源及服务。而当主节点恢复时，备节点又会释放主节点故障时自身接管的 IP 资源及服务，恢复到原来的备用角色。

2.4****VRRP 介绍

① VRRP 通信原理

VRRP也就是虚拟路由冗余协议，它的出现就是为了解决静态路由的单点故障。
VRRP是通过一种竞选协议机制来将路由任务交给某台VRRP路由器的。
VRRP用IP多播的方式（默认多播地址（224.0.0.18））实现高可用之间通信。
工作时主节点发包，备节点接包，当备节点接收不到主节点发的数据包的时候，就启动接管程序接管主节点的资源。备节点可以有多个，通过优先级竞选，但一般Keepalived系统运维工作中都是一对。
VRRP使用了加密协议加密数据，但Keepalive官方目前还是推荐用明文的方式配置认证类型和密码。

② VRRP****工作原理
MASTER 节点发送心跳（通告）给 BACKUP 节点。
BACKUP 节点收不到心跳时，接管 VIP。
MASTER 恢复时，可抢回 VIP（抢占模式）或不抢回（非抢占模式）。
默认多播地址：224.0.0.18
优先级决定 MASTER 节点（数值越大优先）。

2.5****脑裂问题与防护

2.5.1 keepalived****脑裂（Split Brain）

两个节点失去心跳连接，均认为对方挂掉。
后果：
共享资源冲突
数据损坏（如数据库）

|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 在高可用（HA）系统中，当联系2个节点的"心跳线"断开时，本来为一整体、动作协调的HA系统，就分裂成为2个独立的个体。由于相互失去了联系，都以为是对方出了故障。两个节点上的HA软件像"裂脑人"一样，争抢"共享资源"、争起"应用服务"，就会发生严重后果------或者共享资源被瓜分、2边"服务"都起不来了；或者2边"服务"都起来了，但同时读写"共享存储"，导致数据损坏（常见如数据库轮询着的联机日志出错）。 |

2.5.2 脑裂的****原因

① 心跳线故障（断线、老化）
高可用服务器对之间心跳线链路发生故障，导致无法正常通信。如心跳线坏了（包括断了，老化）。
② 网卡/驱动故障
因网卡及相关驱动坏了，ip配置及冲突问题（网卡直连）。
③ 心跳网络设备故障
因心跳线间连接的设备故障（网卡及交换机）。
④ 仲裁机器异常
因仲裁的机器出问题
⑤ 防火墙阻挡 VRRP
高可用服务器上开启了 iptables防火墙阻挡了心跳消息传输。
⑥ 配置不一致（virtual_router_id、优先级、实例名）
Keepalive配置里同一 VRRP实例如果 virtual_router_id两端参数配置不一致也会导致裂脑问题发生。
⑦ vrrp实例名字不一致、优先级一致。

**2.5.3.**防护策略

**·**双心跳线冗余：
添加冗余的心跳线，例如：双线条线（心跳线也HA），尽量减少"裂脑"发生几率。
· 磁盘锁（锁定共享资源）
正在服务一方锁住共享磁盘，"裂脑"发生时，让对方完全"抢不走"共享磁盘资源。但使用锁磁盘也会有一个不小的问题，如果占用共享盘的一方不主动"解锁"，另一方就永远得不到共享磁盘。现实中假如服务节点突然死机或崩溃，就不可能执行解锁命令。后备节点也就接管不了共享资源和应用服务。于是有人在HA中设计了"智能"锁。即：正在服务的一方只在发现心跳线全部断开（察觉不到对端）时才启用磁盘锁。平时就不上锁了。
· 仲裁机制（Ping 参考 IP）
例如设置参考IP（如网关IP），当心跳线完全断开时，2个节点都各自ping一下参考IP，不通则表明断点就出在本端。不仅"心跳"、还兼对外"服务"的本端网络链路断了，即使启动（或继续）应用服务也没有用了，那就主动放弃竞争，让能够ping通参考IP的一端去起服务。更保险一些，ping不通参考IP的一方干脆就自我重启，以彻底释放有可能还占用着的那些共享资源。
· 脚本监控报警

2.5****部署步骤

2.5.1****环境准备

主 DR：192.168.186.20（MASTER）
备 DR：192.168.186.21（BACKUP）
VIP：192.168.186.180
Web 节点：
192.168.186.19
192.168.186.23
客户端：192.168.186.199

2.5.2安装与配置LVS + Keepalived

① DR****服务器操作

systemctl stop firewalld
setenforce 0
yum -y install ipvsadm keepalived
modprobe ip_vs
cat /proc/net/ip_vs # 检查模块

②配置Keepalived
文件： /etc/keepalived/keepalived.conf
主DR 关键配置：

global_defs {
   notification_email {
     acassen@firewall.loc
     failover@firewall.loc
     sysadmin@firewall.loc
   }
   notification_email_from Alexandre.Cassen@firewall.loc
   smtp_server 127.0.0.1
   smtp_connect_timeout 30
   router_id LVS_01
   vrrp_skip_check_adv_addr
#   vrrp_strict   # 不关闭VIP无法连接
   vrrp_garp_interval 0
   vrrp_gna_interval 0
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.186.180
    }
}
virtual_server 192.168.186.180 80 {
    delay_loop 6
    lb_algo rr
    lb_kind DR   #轮询
    persistence_timeout 50
    protocol TCP

    real_server 192.168.186.19 80 {
        weight 1
        SSL_GET {
            TCP_CHECK {
            connect_port 80
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }
    real_server 192.168.186.23 80 {
        weight 1
        SSL_GET {
            TCP_CHECK {
            connect_port 80
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }
}

备 DR关键配置：

global_defs {
   notification_email {
     acassen@firewall.loc
     failover@firewall.loc
     sysadmin@firewall.loc
   }
   notification_email_from Alexandre.Cassen@firewall.loc
   smtp_server 127.0.0.1
   smtp_connect_timeout 30
   router_id LVS_02   # 主备节点需要区分开
   vrrp_skip_check_adv_addr
#   vrrp_strict   # 不关闭VIP无法连接
   vrrp_garp_interval 0
   vrrp_gna_interval 0
}

vrrp_instance VI_1 {
    state BACKUP    # 备
    interface eth0
    virtual_router_id 51
    priority 90    # 这里要低于主的设置
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111   # 主备的密码设置的要一致
    }
    virtual_ipaddress {
        192.168.186.180   # VIP 节点
    }
}
virtual_server 192.168.186.180 80 {
    delay_loop 6
    lb_algo rr
    lb_kind DR  # 设置DR轮询模式
    persistence_timeout 50
    protocol TCP

    real_server 192.168.186.19 80 {
        weight 1
        SSL_GET {
            TCP_CHECK {
            connect_port 80
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }
    real_server 192.168.186.23 80 {
        weight 1
        SSL_GET {
            TCP_CHECK {
            connect_port 80
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }
}

VIP 配置：

vim /etc/sysconfig/network-scripts/ifcfg-ens33:0
DEVICE=ens33:0
ONBOOT=yes
IPADDR=192.168.186.180
NETMASK=255.255.255.255

重启网络：

systemctl restart network
ifup ens33:0

2.5.3****内核参数优化

vim /etc/sysctl.conf
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.ens33.send_redirects = 0
sysctl -p

2.5.4****启动服务

systemctl start keepalived
ip addr # 查看 VIP 是否生效
ipvsadm-save > /etc/sysconfig/ipvsadm
systemctl start ipvsadm
ipvsadm -ln # 查看 LVS 配置

2.6配置Web****节点（httpd）

systemctl stop firewalld
setenforce 0

yum -y install httpd
systemctl start httpd

echo 'this is kgc web!' > /var/www/html/index.html # 192.168.10.16
echo 'this is benet web!' > /var/www/html/index.html # 192.168.10.17

vim /etc/sysconfig/network-scripts/ifcfg-lo:0
DEVICE=lo:0
ONBOOT=yes
IPADDR=192.168.10.180
NETMASK=255.255.255.255

service network restart
ifup lo:0
route add -host 192.168.10.180 dev lo:0

vim /etc/sysctl.conf
net.ipv4.conf.lo.arp_ignore = 1
net.ipv4.conf.lo.arp_announce = 2
net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.all.arp_announce = 2
sysctl -p

2.7****测试

① 客户端访问 VIP：

http://192.168.10.180

② 停掉 MASTER Keepalived：

systemctl stop keepalived

观察 BACKUP 节点接管 VIP 是否成功。
再启动 MASTER，观察 VIP 是否回归（抢占或非抢占模式）。

2.8****小结与注意事项

|--------|--------------------------------------|
| 项目 | 注意点 |
| VIP | DR 节点配置 VIP 网卡 ens33:0，Web 节点配置 lo:0 |
| 抢占模式 | MASTER 恢复会抢回 VIP，非抢占模式需配置 nopreempt |
| 健康检查 | Keepalived 支持 TCP/HTTP 检查，可防止故障节点被调度 |
| 防火墙 | Firewalld 需关闭，确保 VRRP 心跳消息畅通 |
| 脑裂防护 | 双心跳线、磁盘锁、仲裁 IP、脚本监控 |