高可用集群Keepalived

技术文档

一、高可用集群

1.1 集群类型

高可用集群（High Availability Cluster, HA Cluster）的核心目标是通过冗余设计和故障自动转移机制，确保业务服务的连续性和可靠性。根据应用场景和技术实现，高可用集群主要分为以下三类：

1. 高可用性集群（High Availability Cluster, HA）

核心目标：消除单点故障（SPoF），保障服务在节点故障时仍能持续运行。
典型技术：
- 主备模式（Active/Passive）：
  - 主节点（Active）处理请求，备节点（Passive）实时监控主节点状态（通过心跳检测）。
  - 主节点故障时，备节点自动接管虚拟IP（VIP）和服务资源（如数据库、应用进程）。
  - 示例：MySQL主从复制+Keepalived实现数据库高可用。
- 双主模式（Active/Active）：
  - 所有节点同时处理请求，互为备份。
  - 节点故障时，负载均衡器将流量转移至健康节点。
关键机制：
- 心跳检测：节点间定期发送心跳包，超时则判定节点故障。
- 故障转移（Failover）：自动切换服务至备用节点，耗时通常小于1秒。
- 脑裂防护：通过仲裁机制（如Pacemaker的STONITH）避免多节点同时接管资源。
应用场景：数据库服务（如MySQL、Redis）、关键业务系统、金融交易平台。

2. 负载均衡集群（Load Balancing Cluster, LB）

核心目标：将用户请求分发到多个后端节点，避免单点过载，提升吞吐量和响应速度。
典型技术：
- 四层负载均衡：基于IP和端口分发流量（如LVS、F5）。
- 七层负载均衡：基于HTTP头部、URL等应用层信息分发流量（如Nginx、HAProxy）。
架构特点：
- 无状态节点：后端服务器不存储会话状态，便于水平扩展。
- 动态健康检查：实时监测节点健康状态，自动剔除故障节点。
应用场景：Web应用服务器集群、API网关、大规模并发访问（如电商大促）。

3. 高性能计算集群（High Performance Computing Cluster, HPC）

核心目标：通过并行计算处理大规模任务，提升整体计算能力。
关键技术：
- 任务分解：将大型计算任务拆分为子任务，分发给多个计算节点。
- 结果聚合：各节点完成计算后，汇总结果（如MPI库实现节点间通信）。
典型架构：
- Beowulf集群：基于Linux的廉价高性能方案，常用于科研领域。
- 网格计算（Grid Computing）：跨地域整合异构计算资源，适用于独立作业（如天文数据分析）。
应用场景：科学模拟（气候建模、基因测序）、大数据分析、渲染农场。

1.2 系统可用性

高可用集群的系统可用性是其设计的核心目标，通过冗余架构和自动化故障转移机制，最大限度减少服务中断时间。

可用性定义与量化标准

计算公式
系统可用性（A）由平均无故障时间（MTBF） 和平均修复时间（MTTR） 共同决定：
A=MTBF+MTTRMTBF×100%
- MTBF：反映系统可靠性（无故障运行时长）
- MTTR：反映故障恢复效率（含检测、切换、修复时间）
可用性等级与停机时间
可用性等级 年度停机时间 适用场景 99% （2个9） ≤87.6小时非关键业务（如内部系统） 99.9%（3个9） ≤8.8小时一般企业应用 99.99%（4个9） ≤53分钟 金融交易、电商平台（如淘宝） 99.999%（5个9） ≤5分钟 电信核心网、支付系统

1.3 系统故障

高可用集群的系统故障主要分为硬件故障和软件故障两大类，这两类故障均可能破坏服务的连续性。

1、硬件故障

硬件故障指物理设备因设计、损耗或外部不可抗力导致的失效，是集群单点故障（SPoF）的主要根源：

设计缺陷
- 典型表现：硬件选型或架构设计不合理（如散热不足、电源冗余缺失）。
- 案例：某服务器因散热设计缺陷导致CPU过热宕机，触发主备切换。
自然损耗（Wear Out）
- 典型表现：机械硬盘寿命到期（平均3-5年）、风扇轴承老化、电容鼓包等。
- 数据：机械硬盘年故障率约2%-5%，SSD因写入次数限制也存在寿命阈值。
非人为不可抗力
- 自然灾害：地震、洪水导致机房断电或设备损毁（如2015年支付宝因市政施工光纤被挖断）。
- 外部事件：战争、火灾等突发性破坏（需依赖异地容灾解决）。

2、软件故障

软件故障由程序逻辑错误或配置问题引发，常导致服务雪崩或数据不一致：

设计缺陷
- 架构问题：未考虑并发瓶颈或资源竞争（如线程死锁）。
- 案例：Redis主从复制中，主库缓冲区溢出导致从库全量同步失败。
代码缺陷（Bug）
- 典型场景：
  - 内存泄漏（进程持续占用内存直至崩溃）。
  - 边界条件未处理（如空指针引用、数组越界）。
- 影响：携程2015年因误删生产环境代码导致服务中断12小时。

3、硬件故障 vs 软件故障对比

故障类型 根本原因 影响范围 预防措施 硬件故障 物理设备老化/外部破坏单节点或局部硬件失效冗余设计（双电源、RAID）、异地容灾 软件故障 程序逻辑错误或配置失误服务级崩溃或数据污染代码审查、灰度发布、熔断机制

1.4 实现高可用

实现高可用性的核心在于通过冗余设计降低平均故障修复时间（MTTR），并结合自动化故障转移机制。以下基于主备（Active/Passive）和双主（Active/Active）两种冗余架构，详细说明实现方案及关键技术要点：

1、冗余机制：降低MTTR的核心策略

1. 主备模式（Active/Passive）

工作原理：
- 主节点（Active） 处理所有请求，备节点（Passive） 通过心跳检测（如Keepalived的VRRP协议）实时监控主节点状态。
- 主节点故障时，备节点自动接管虚拟IP（VIP）和服务资源（如数据库连接、进程），切换时间通常<1秒。
关键技术：
- 心跳检测：周期性发送心跳包（如Corosync），超时则判定节点失效。
- VIP漂移：通过Keepalived实现IP地址无缝迁移，客户端无感知。
- 数据同步：共享存储（SAN/NAS）或实时复制（如DRBD），确保主备数据强一致。
适用场景：数据库（MySQL+Keepalived）、关键业务系统。

2. 双主模式（Active/Active）

工作原理：
- 所有节点同时处理请求，互为备份。负载均衡器（如Nginx/LVS）分发流量，单节点故障时自动剔除故障节点。
关键技术：
- 负载均衡：基于轮询、最少连接等算法分发请求，支持健康检查（如HTTP_GET）。
- 会话保持：通过一致性哈希（如hash-type consistent）绑定用户会话至固定节点，避免切换时会话丢失。
- 数据一致性：分布式数据库（如MySQL Cluster、Cassandra）或多主复制协议。
适用场景：高并发Web服务、无状态应用集群。

2、降低MTTR的实践方案

1. 自动化故障转移流程

故障检测：
- 心跳网络：专用冗余链路（如RS232/TCP/IP）传输状态信号，避免公网干扰。
- 多层检测：TCP端口检查 + 应用层探针（如MySQL的SELECT 1），避免误判。
切换机制：
- Pacemaker：定义资源约束（如顺序约束、位置约束），控制服务启动次序和依赖关系。
- MHA（MySQL高可用）：自动从宕机主节点提取binlog，在备用节点回放以最小化数据丢失。

2. 脑裂防护与仲裁机制

法定票数（Quorum）：要求多数节点（>N/2）达成共识才允许切换，防止网络分区导致多主冲突。
STONITH（Shoot The Other Node）：通过电源交换机强制关闭故障节点，彻底消除资源争用。

3. 数据同步优化

强一致性方案：
- 半同步复制：确保主节点提交事务前至少一个备节点确认（如MySQL semi-sync）。
- 分布式共识协议：etcd使用Raft协议保证多节点数据一致性。
最终一致性方案：异步复制+冲突解决（如Couchbase），适用容忍短暂不一致的场景。

3、架构对比与选型建议

架构类型 切换时间 资源利用率 数据一致性 适用场景 Active/Passive 秒级（<1s）低（备节点闲置）强一致（共享存储）数据库、金融核心系统 Active/Active 毫秒级高（无闲置资源）最终一致/强一致 Web应用、API服务、无状态集群

1.5.VRRP：Virtual Router Redundancy Protocol（虚拟路由冗余协议）

1、VRRP核心原理

1. 解决静态网关单点故障

问题背景：传统静态网关一旦故障，整个网络将中断。VRRP通过将多台物理设备（路由器/三层交换机）虚拟成单一逻辑网关（虚拟路由器），对外提供统一虚拟IP（VIP） 作为终端设备的默认网关。
冗余机制：
- 主备选举：基于优先级（1-254，默认100）选举主设备（Master），优先级最高者（或IP地址拥有者，优先级固定255）成为Master。
- 故障切换：Master周期性（默认1秒）发送VRRP通告报文，若Backup超时（默认3秒）未收到，则触发选举新Master，切换时间通常<1秒。
透明切换：新Master发送免费ARP报文更新下游设备MAC表，终端无感知。

2. 关键概念

虚拟路由器（Virtual Router）：逻辑实体，绑定VIP和虚拟MAC（格式：00-00-5E-00-01-{VRID}）。
虚拟IP（VIP）：管理员配置的网关地址，局域网内主机将其设为默认网关（如192.168.1.254）。
虚拟MAC（VMAC）：固定格式为00-00-5E-00-01-XX（XX为VRID的十六进制值），用于ARP响应与数据包转发。
VRID（虚拟路由器ID）：标识VRRP组（范围0-255），同一组内设备共享VIP。
物理路由器角色：
- Master（主设备）
- Backup（备用设备）
- 优先级（Priority）
  - 优先级范围：0-255，值越高越优先。
  - 特殊值说明：
    优先级 含义 应用场景 255 IP地址拥有者（Owner）自动获得强制指定某设备永久为Master 0 Master主动弃权（如维护时手动降级）避免切换冲突 1-254 可配置优先级（默认100）根据设备性能或链路质量动态调整
抢占模式：高优先级Backup可主动抢占Master角色（默认开启）。

2、物理层实现：路由器与三层交换机

1. 部署场景

路由器：企业出口网关冗余（如主备路由器组）。
三层交换机：局域网核心层网关冗余（如VLANif接口配置VRRP）。

2. 配置示例（以三层交换机为例）

# 主设备配置（优先级120，抢占延迟20秒） interface Vlanif10 ip address 192.168.10.253 24 # 真实IP vrrp vrid 1 virtual-ip 192.168.10.254 # VIP vrrp vrid 1 priority 120 vrrp vrid 1 preempt-mode timer delay 20 # 备设备配置（优先级110） interface Vlanif10 ip address 192.168.10.252 24 vrrp vrid 1 virtual-ip 192.168.10.254 vrrp vrid 1 priority 110

上行链路监控：vrrp vrid 1 track interface GigabitEthernet0/0/1 reduced 30（上行接口故障时降优先级触发切换）。

3、软件层实现：Keepalived

1. Keepalived与VRRP的关系

Keepalived是基于VRRP协议的开源高可用框架，通过管理VIP实现服务冗余。
扩展功能：
- 负载均衡：集成LVS（Linux Virtual Server）实现四层流量分发。
- 健康检查：监控后端服务（如HTTP/MySQL），故障时触发VIP漂移。

2. 配置核心（Keepalived.conf）

vrrp_instance VI_1 { state MASTER  # 初始状态 interface eth0  # 绑定网卡 virtual_router_id 51 # VRID（组内一致） priority 100  # 优先级 advert_int 1  # 通告间隔 authentication { # 认证 auth_type PASS auth_pass 1111 } virtual_ipaddress { # VIP 192.168.1.100/24 } }

故障切换：Backup节点收不到VRRP组播报文时，自动升为Master。

4、VRRP进阶特性

1. 负载分担模式

创建多个VRRP组（不同VRID），各设备在不同组中分别担任Master，分流网关流量。
示例：
- Device A：VRID 1的Master（VIP 1）
- Device B：VRID 2的Master（VIP 2）
- 终端按VIP分组访问，实现负载均衡与冗余并存。

2. 快速故障检测（BFD联动）

传统VRRP检测需3秒，绑定BFD会话后可在毫秒级感知链路故障，切换时间<1秒。

3. 跨网段部署（单播VRRP）

传统VRRP依赖二层组播（224.0.0.18），单播模式支持三层网络传输，适用于广域网冗余。

总结：VRRP的价值与适用场景

场景 实现方式 技术优势 企业网关冗余 路由器主备组 + VIP 消除单点故障，切换透明 数据中心核心层 三层交换机VRRP + MSTP 网关与生成树协议冗余联动 高可用Web服务 Keepalived + LVS + VIP 服务冗余 & 负载均衡一体化

核心公式：网络高可用 = 物理冗余（路由器/交换机） + 协议层容错（VRRP） + 软件层扩展（Keepalived）。
最佳实践：

避免脑裂：配置不同优先级 + 抢占延迟；

云环境适配：使用单播模式替代组播（如AWS不支持组播）。

二、Keepalived 的部署

2.1 Keepalived 简介

Keepalived 是一款基于 VRRP（虚拟路由冗余协议） 的开源高可用性解决方案，主要用于消除网络服务中的单点故障，保障业务连续性。其核心设计理念是通过冗余架构 + 自动化故障转移实现服务的高可用性。

Keepalived官网：http://keepalived.org/

Keepalived 核心功能

高可用（HA）
- 故障转移：通过 VRRP 协议管理虚拟 IP（VIP）。当主节点（Master）故障时，备用节点（Backup）自动接管 VIP 和服务，切换时间通常 <1秒。
- 角色选举：基于优先级（1-254）竞选主节点，优先级最高者成为 Master（优先级 255 为 IP 地址拥有者）。
健康检查
- Layer3（网络层）：发送 ICMP 包检测服务器 IP 是否可达（类似 Ping）。
- Layer4（传输层）：检查 TCP 端口状态（如检测 Nginx 的 80 端口）。
- Layer5/7（应用层）：
  - 执行 HTTP GET 请求，用 MD5 算法校验响应内容。
  - 支持自定义脚本（MISC_CHECK）检测特定服务状态。
负载均衡（需结合 LVS）
- 管理 LVS（Linux Virtual Server） 规则，实现四层流量分发（如轮询、最小连接算法）。

2.2 Keepalived 架构

用户空间核心组件功能详解

VRRP Stack
- 功能：实现 VRRP 协议，通过组播（默认 224.0.0.18）在主备节点间同步状态，管理虚拟 IP（VIP）的绑定与释放。
- 工作流程：主节点（Master）周期性发送心跳报文；备节点（Backup）超时未收到心跳则接管 VIP。
Checkers
- 功能：对后端 Real Server 进行健康检查，支持三层（ICMP）、四层（TCP 端口）、五层（HTTP/SSL）检测。
- 作用：故障节点自动从 IPVS 规则中移除，恢复后重新加入。
IPVS Wrapper
- 功能：根据配置生成 IPVS 负载均衡规则，并同步到内核的 IPVS 模块，实现流量分发。
- 典型场景：与 LVS 集成，定义调度算法（如轮询、加权最少连接）。
Netlink Reflector
- 功能：管理网络接口，在故障切换时绑定/解绑 VIP，并通过 ARP 广播更新交换机 MAC 表。
WatchDog
- 功能：监控 VRRP Stack 和 Checkers 进程的存活状态，异常时触发重启或告警。
- 机制：计数器超时未重置则判定进程故障。
SMTP
- 功能：在状态切换（如 Master→Backup）或服务异常时，发送邮件告警。
System Call
- 功能：在 VRRP 状态转换（如主备切换）时，调用自定义脚本（如重启 Nginx、更新路由）。
- 示例：
```
vrrp_script chk_nginx { script \"/etc/keepalived/check_nginx.sh\" }
```
控制组件
- 功能：解析 keepalived.conf 配置文件，按需加载各模块（如仅配置 VRRP 时不加载 IPVS 规则）。
I/O 复用器 & 内存管理
- I/O 复用器：优化网络线程调度，高效处理 VRRP 报文和健康检查请求。
- 内存管理：统一管理组件的内存分配/释放，避免资源泄漏。

内核空间组件

IPVS (Linux Virtual Server)
- 功能：内核态四层负载均衡，高性能转发流量至后端 Real Server。
- 支持模式：NAT、DR（推荐）、TUN。
NETLINK
- 功能：提供高级路由功能，配合 Netlink Reflector 实现 VIP 的绑定和路由更新。

2.3 Keepalived 环境准备

根据Keepalived的高可用集群部署要求，环境准备需满足以下核心条件及注意事项，结合实践建议整理如下：

1. 各节点时间必须同步

重要性：
Keepalived依赖VRRP协议进行主备状态决策，若节点间时间差过大（通常超过1秒），会导致心跳报文超时误判，触发主备切换异常。

2. 关闭防火墙及SELinux

必要性：
防火墙可能阻断VRRP组播报文（默认组播地址224.0.0.18）或健康检查流量，导致主备通信失败。

3. 主机名通信与/etc/hosts配置（非必须但建议）

作用：
简化配置时的主机标识，如keepalived.conf中的router_id通常建议用主机名（需确保唯一性）。

4. SSH密钥认证（非必须但场景化推荐）

使用场景：
主备切换时需执行远程节点脚本（如通知备节点接管VIP），或批量配置时简化操作。

5. 其他关键注意事项

服务启动顺序：
若Keepalived托管Nginx等应用，需确保应用先于Keepalived启动（如通过systemctl enable nginx keepalived调整）。

内核参数调整（DR模式必做）：
后端Real Server需配置ARP抑制：

echo \"net.ipv4.conf.all.arp_ignore = 1\" >> /etc/sysctl.conf echo \"net.ipv4.conf.lo.arp_ignore = 1\" >> /etc/sysctl.conf sysctl -p

日志排查：
启用Keepalived日志便于故障定位：

# 修改/etc/sysconfig/keepalived KEEPALIVED_OPTIONS=\"-D -d -S 0\" # 在/etc/rsyslog.conf中添加 local0.* /var/log/keepalived.log systemctl restart rsyslog

2.4 Keepalived 相关文件

Keepalived 的核心文件主要分布在 /etc/keepalived/、/usr/sbin/ 和系统服务目录中，以下是关键文件及其功能的分类说明：

1、核心配置文件

主配置文件
- 路径：/etc/keepalived/keepalived.conf
- 功能：定义全局参数、VRRP实例、虚拟服务器（IPVS规则）、健康检查脚本等。配置文件分为三部分：
  - global_defs：全局设置（邮件通知、路由标识 router_id）
  - vrrp_instance：定义虚拟路由器（主备状态、VIP、优先级等）
  - virtual_server：配置LVS负载均衡规则（后端Real Server、调度算法）。
- 语法检查：
  
  keepalived -t # 检查配置文件语法
环境配置文件
- 路径：/etc/sysconfig/keepalived
- 功能：设置服务启动参数（如 --vrrp 仅启用VRRP模块）。
- 示例：
```
KEEPALIVED_OPTIONS=\"-D -S 0\" # 启用调试模式并指定日志设备
```

2、系统服务与可执行文件

服务单元文件
- 路径：/usr/lib/systemd/system/keepalived.service
- 功能：管理系统服务启停，支持命令：
```
systemctl restart keepalived # 重启服务（注意：RHEL7可能存在重启失效的Bug） systemctl status keepalived # 查看服务状态
```
  注意：部分系统需通过 kill 强制停止进程。
主程序文件
- 路径：/usr/sbin/keepalived
- 功能：Keepalived 守护进程的入口程序。

3、日志与辅助文件

日志文件
- 默认路径：/var/log/messages
- 自定义配置：
  1. 在 /etc/sysconfig/keepalived 添加 -S 0
  2. 在 /etc/rsyslog.conf 添加：
```
local0.* /var/log/keepalived.log # 独立日志路径
```
  3. 重启服务：
```
systemctl restart rsyslog keepalived
```
配置示例与工具
- 示例目录：/usr/share/doc/keepalived/
  - 包含模板如 keepalived.conf.vrrp.localcheck（健康检查示例）。
- 辅助工具：
  - /usr/bin/genhash：生成Real Server健康检查的摘要（用于HTTP/SSL检测）。

4、其他支持文件

脚本目录：/etc/keepalived/scripts/
存放自定义脚本（如 chk_nginx.sh），通过 vrrp_script 或 notify_master 调用。
子配置文件
支持通过 include 拆分配置（如将VRRP实例独立为 conf.d/vrrp.conf）。

2.5 Keepalived 安装

[root@KA1 ~]# dnf install keepalived -y[root@KA1 ~]# systemctl start keepalived[root@KA1 ~]# ps axf | grep keepalived2385 pts/0 S+ 0:00 \\_ grep --color=auto keepalived2326 ? Ss 0:00 /usr/sbin/keepalived -D2327 ? S 0:00 \\_ /usr/sbin/keepalived -D

2.6 Keepalived 配置说明

2.6.1 配置文件组成部分

Keepalived 的配置文件 /etc/keepalived/keepalived.conf 采用模块化设计，分为三大核心部分：全局配置（GLOBAL CONFIGURATION）、VRRP 配置（VRRP CONFIGURATION）和 LVS 配置（LVS CONFIGURATION）。

1. 全局配置（GLOBAL CONFIGURATION）

作用：定义 Keepalived 的全局行为，包括通知机制、路由标识和网络参数。
配置块：global_defs { ... }
关键参数：

router_id：唯一标识节点（如 LVS_MASTER），用于日志和邮件通知。
notification_email：故障时接收告警的邮箱列表（可选）。
smtp_server：SMTP 服务器地址（需系统支持邮件服务）。
vrrp_strict：严格模式，禁止非 VRRP 主机接收报文（生产环境慎用，可能阻断合法流量）。
vrrp_garp_interval：GARP 包发送间隔（更新 ARP 表），默认 0（关闭）。
script_user：运行脚本的用户（如 keepalived_script 或 root）。

注意：邮件通知依赖系统邮件服务，建议用第三方监控（如 Nagios）替代。

2. VRRP 配置（VRRP CONFIGURATION）

作用：管理虚拟路由器实例（VIP 漂移和主备切换）。
配置块：

vrrp_script：定义健康检查脚本（如检测 Nginx 进程）。

vrrp_script chk_nginx { script \"/etc/keepalived/chk_nginx.sh\" # 脚本路径 interval 2 # 检查间隔（秒） weight -20 # 失败时优先级降低值 fall 2 # 失败次数判定阈值 rise 1 # 成功次数判定阈值 }

vrrp_instance：定义虚拟路由器实例。

vrrp_instance VI_1 { state MASTER # 初始状态（MASTER/BACKUP） interface eth0  # 绑定网卡 virtual_router_id 51 # 虚拟路由ID（集群内唯一） priority 100 # 优先级（MASTER > BACKUP） advert_int 1 # VRRP 报文发送间隔（秒） authentication { # 认证配置 auth_type PASS auth_pass 1111 # 密码（仅前8位有效） } virtual_ipaddress { # VIP 列表 192.168.200.100/24 dev eth0 label eth0:1 #label eth0:1中的eth0:1 是逻辑子接口的名称，表示在 eth0 上创建的第一个虚拟接口。 } track_script { # 关联健康检查脚本 chk_nginx } notify_master \"/etc/keepalived/to_master.sh\" # 状态切换脚本 }

高级参数：

nopreempt：非抢占模式（BACKUP 节点不主动夺权）。
preempt_delay 300：抢占延迟（防止频繁切换）。
track_interface：监控网卡状态（任一网卡故障触发切换）。

3. LVS 配置（LVS CONFIGURATION）

作用：定义负载均衡规则（需与 VRRP 结合使用）。
配置块：virtual_server { ... }
关键参数：

virtual_server：指定 VIP 和端口（如 192.168.200.100 80）。
delay_loop：后端服务检查间隔（秒）。
lb_algo：调度算法（常用 rr、wlc）。
lb_kind：转发模式（DR、NAT、TUN）。
persistence_timeout：会话保持时间（秒）。

后端服务器配置（real_server）：

real_server 192.168.201.2 80 { weight 1 # 权重（越高优先级越高） TCP_CHECK { # TCP 健康检查 connect_port 80 # 检查端口 connect_timeout 3 # 超时时间（秒） retry 3  # 重试次数 } HTTP_GET { # HTTP 健康检查 url { path /health digest 9a3a466... # 页面摘要（genhash 生成） } } }

2.6.2 配置语法说明

使用man keepalived.conf命令可以查看命令帮助

2.6.2.1 全局配置

! Configuration File for keepalivedglobal_defs { notification_email { timiniglee-zln@163.com #keepalived 发生故障切换时邮件发送的目标邮箱，可以按行区分写多个 } notification_email_from keepalived@KA1.timinglee.org #发邮件的地址 smtp_server 127.0.0.1 #邮件服务器地址 smtp_connect_timeout 30 #邮件服务器连接timeout router_id KA1.timinglee.org #每个keepalived主机唯一标识 #建议使用当前主机名，但多节点重名不影响 vrrp_skip_check_adv_addr #对所有通告报文都检查，会比较消耗性能 #启用此配置后，如果收到的通告报文和上一个报文是同一个路由器，则跳过检查，默认值为全检查 vrrp_strict #严格遵循vrrp协议 #启用此项后以下状况将无法启动服务: #1.无VIP地址 #2.配置了单播邻居 #3.在VRRP版本2中有IPv6地址 #建议不加此项配置 vrrp_garp_interval 1 #免费 ARP（Gratuitous ARP）报文时间间隔 #免费 ARP用于通知网络中其他设备，某 IP地址对应的 MAC 地址发生了变化 #帮助网络设备更新 ARP 缓存，确保数据能正确转发到新的主节点 vrrp_gna_interval 1 #用于配置发送 Gratuitous NA（免费邻居通告）报文的时间间隔 #通知网络中其他设备，某 IPv6 地址对应的链路层地址（MAC 地址）发生了变化 #帮助网络设备更新邻居缓存（NeighborCache） #确保 IPv6 数据包能正确转发到新的主节点 vrrp_mcast_group4 224.0.0.44 #指定组播IP地址范围：}

2.6.2.2 配置虚拟路由器

vrrp_instance VI_1 { state MASTER interface eth0 #绑定为当前虚拟路由器使用的物理接口，如：eth0,可以和VIP不在一个网卡 virtual_router_id 51 #每个虚拟路由器惟一标识,范围：0-255，每个虚拟路由器此值必须唯一 #否则服务无法启动 #同属一个虚拟路由器的多个keepalived节点必须相同 #务必要确认在同一网络中此值必须唯一 priority 100 #当前物理节点在此虚拟路由器的优先级，范围：1-254 #值越大优先级越高,每个keepalived主机节点此值不同 advert_int 1 #vrrp通告的时间间隔，默认1s authentication { #认证机制 auth_type AH|PASS #AH为IPSEC认证(不推荐),PASS为简单密码(建议使用) uth_pass 1111 #预共享密钥，仅前8位有效 #同一个虚拟路由器的多个keepalived节点必须一样 } virtual_ipaddress { #虚拟IP,生产环境可能指定上百个IP地址 / brd  dev  scope  label  #以下为虚拟IP示例： 172.25.254.100 #指定VIP，不指定网卡，默认为eth0,注意：不指定/prefix,默认32 172.25.254.101/24 dev eth1 172.25.254.102/24 dev eth2 label eth2:1 } accept #开启vip 对外响应ping包，注意此处功能需要关闭vrrp_strict #默认使用nftab策略禁用ping包响应，nft list ruleset 显示策略中即可看到}

注意：修改完keepalived配置文件后，要重启服务才能生效，重启服务前可以执行下列命令来检测配置文件的语法有没有出错！！

#检测配置文件语法

[root@KA1 ~]# keepalived -t -f /etc/keepalived/keepalived.conf

2.6.2.3 启用keepalived日志功能

2.6.2.4 实现独立子配置文件

编写子配置文件

然后重启服务就行了。

三、Keepalived 企业应用示例

3.1 实现 master/slave 的 Keepalived 单主架构

3.1.1 MASTER配置

3.1.2 BACKUP配置

做完MASTER和BACKUP配置后进行抓包观察：

发现全是KA1的IP就说明配置成功了，因为KA1作为master主机的优先级比作为backup主机的KA2高。

3.2 抢占模式和非抢占模式

默认设置为抢占模式preempt，即当高优先级的主机恢复在线后，会抢占低先级的主机的master角色，这样会使vip在KA主机中来回漂移，造成网络抖动，建议设置为非抢占模式 nopreempt ，即高优先级主机恢复后，并不会抢占低优先级主机的master角色。

非抢占模块下,如果原主机down机, VIP迁移至的新主机, 后续也发生down时,仍会将VIP迁移回原主机。

！！注意：要关闭VIP抢占的话，必须将各个keepalived服务器的state（状态）配置为BACKUP

3.2.1 非抢占模式 nopreempt

进行抓包测试：

先在KA2上进行抓包观察，然后将KA1的keepalived服务关闭后，再次在KA2上进行抓包观察，然后重启KA1的keepalived服务，看看KA1是否会将VIP抢占回去。

发现KA1不会将VIP抢占回去，说明非强制模式配置成功。

3.2.2 抢占延迟模式 preempt_delay

抢占延迟模式，即优先级高的主机恢复后，不会立即抢回VIP，而是延迟一段时间（默认300s）再抢回VIP。

配置选项：preempt_delay # 指定抢占延迟时间为#s，默认延迟300s

！！注意：需要各keepalived服务器state为BACKUP，并且不要启用 vrrp_strict

抓包测试：

先进行抓包测试，然后关闭KA1的keepalived服务，再次进行抓包测试，发现KA2已经将VIP抢占过去了，然后重启KA1的keepalived服务后立马进行抓包测试，发现KA1还没有将VIP抢占回去，等过了10秒之后再进行抓包测试，发现KA1已经将VIP抢占回去了。

3.3 VIP单播配置

默认keepalived主机之间利用多播相互通告消息，会造成网络拥塞，可以替换成单播，减少网络流量。

！！！注意：启用 vrrp_strict 时，不能启用单播，否则服务无法启动，并在messages文件中记录下面信息
Jun 16 17:50:06 centos8 Keepalived_vrrp[23180]: (m44) Strict mode does not
support authentication. Ignoring.
Jun 16 17:50:06 centos8 Keepalived_vrrp[23180]: (m44) Unicast peers are not
supported in strict mode
Jun 16 17:50:06 centos8 Keepalived_vrrp[23180]: Stopped - used 0.000606 user
time, 0.000000 system time
Jun 16 17:50:06 centos8 Keepalived[23179]: Keepalived_vrrp exited with permanent
error CONFIG. Terminating
Jun 16 17:50:06 centos8 systemd[1]: keepalived.service: Succeeded.
Jun 16 17:50:06 centos8 Keepalived[23179]: Stopped Keepalived v2.0.10
(11/12,2018)

在所有节点vrrp_instance语句块中设置对方主机的IP，建议设置为专用于对应心跳线网络的地址，而非使用业务网络。

如果有多个keepalived主机IP，那么再在unicast_peer中添加其它节点keepalived主机的IP。

抓包测试：

开启了单播后，只有抢占了VIP的master主机作为src源地址抓包目标主机才能成功，不然使用没有抢占到VIP的backup主机作为src源地址的话会卡住。

3.4 Keepalived 通知脚本配置

当keepalived的状态变化时，可以自动触发脚本的执行，比如：发邮件通知用户。

默认以用户keepalived_script身份执行脚本。

如果此用户不存在，以root执行脚本可以用下面指令指定脚本执行用户的身份。
global_defs { ...... script_user  ......}

3.4.1 通知脚本类型

当前节点成为主节点时触发的脚本：
notify_master |
当前节点转为备节点时触发的脚本：
notify_backup |
当前节点转为“失败”状态时触发的脚本：
notify_fault |<QUOTED-STRING

3.4.2 脚本的调用方法

在 vrrp_instance VI_1 语句块的末尾加指定的脚本

示例：
notify_master \"/etc/keepalived/mail.sh master\"notify_backup \"/etc/keepalived/mail.sh backup\"notify_fault \"/etc/keepalived/mail.sh fault\"

3.4.3 创建通知脚本

3.4.4 邮件配置

参数 值 作用 set smtp smtp.163.com 指定SMTP服务器地址（网易163邮箱） set smtp-auth login 认证方式为登录认证 set smtp-auth-user xxxxxxxx@163.com 邮箱账号（需与发件人一致） set smtp-auth-password MYbaFFiuK4PF6Z9K（这个在网易官网开通SMTP服务就能得到） 授权码（非邮箱登录密码，需在邮箱设置中生成） set from xxxxxxxx@163.com 发件人地址（需与认证账号一致） set ssl-verify ignore 忽略SSL证书验证（测试环境建议启用，生产环境建议配置有效证书）

发送测试邮件：

启动sendmail服务后，发送包含test message这个信息的测试邮件到邮箱中。

3.4.5 示例：实现 Keepalived 状态切换的通知脚本

KA1和KA2的脚本配置相同。

测试：

杀死keeplived进程进行测试，发现邮箱收到了状态变化的邮件，说明实验成功。

使用killall keepalived强制终止系统中所有 keepalived 进程，KA1的keepalived进程被杀死后，KA2抢占了VIP变为了MASTER主机。

KA1重启后，KA2变为了BACKUP。

3.5 实现 master/master 的 Keepalived 双主架构

master/slave的单主架构，同一时间只有一个Keepalived对外提供服务，此主机繁忙，而另一台主机却很空闲，利用率低下，可以使用master/master的双主架构，解决此问题。

master/master 的双主架构：

即将两个或以上VIP分别运行在不同的keepalived服务器，以实现服务器并行提供web访问的目的，提高服务器资源利用率。

例如下图的KA1和KA2配置

示例：三个节点的三主架构实现

#第一个节点ka1配置：Vrrp instance 1：MASTER，优先级100Vrrp instance 2：BACKUP，优先级80Vrrp instance 3：BACKUP，优先级60#第二个节点ka2配置：Vrrp instance 1：BACKUP，优先级60Vrrp instance 2：MASTER，优先级100Vrrp instance 3：BACKUP，优先级80#第三个节点ka3配置：Vrrp instance 1：BACKUP，优先级80Vrrp instance 2：BACKUP，优先级60Vrrp instance 3：MASTER，优先级100

3.6 实现IPVS的高可用性

3.6.1 IPVS相关配置

3.6.1.1 虚拟服务器配置结构

#配置结构virtual_server IP port { ... real_server { ... } real_server { ... } ...}

3.6.1.2 virtual server （虚拟服务器）的定义格式

virtual_server IP port #定义虚拟主机IP地址及其端口virtual_server fwmark int #ipvs的防火墙打标，实现基于防火墙的负载均衡集群virtual_server group string #使用虚拟服务器组

3.6.1.3 虚拟服务器配置

virtual_server IP port { #VIP和PORT delay_loop   #检查后端服务器的时间间隔 lb_algo rr|wrr|lc|wlc|lblc|sh|dh #定义调度方法 lb_kind NAT|DR|TUN  #集群的类型,注意要大写 persistence_timeout  #持久连接时长 protocol TCP|UDP|SCTP #指定服务协议,一般为TCP sorry_server   #所有RS故障时，备用服务器地址 real_server   { #RS的IP和PORT weight  #RS权重 notify_up | #RS上线通知脚本 notify_down | #RS下线通知脚本 HTTP_GET|SSL_GET|TCP_CHECK|SMTP_CHECK|MISC_CHECK { #定义当前主机健康状态检测方法 ... } }}#注意:括号必须分行写,两个括号写在同一行,如: }} 会出错

3.6.1.4 应用层监测

应用层监测分为：HTTP_GET（普通 HTTP 检查） | SSL_GET（HTTPS 检查）

HTTP_GET|SSL_GET { url { path  #定义要监控的URL status_code  #判断上述检测机制为健康状态的响应码，一般为 200 } connect_timeout  #客户端请求的超时时长, 相当于haproxy的timeout server nb_get_retry  #重试次数 delay_before_retry  #重试之前的延迟时长 connect_ip  #向当前RS哪个IP地址发起健康状态检测请求 connect_port  #向当前RS的哪个PORT发起健康状态检测请求 bindto  #向当前RS发出健康状态检测请求时使用的源地址 bind_port  #向当前RS发出健康状态检测请求时使用的源端口}

3.6.1.5 TCP监测

传输层监测：TCP_CHECK

TCP_CHECK { connect_ip  #向当前RS的哪个IP地址发起健康状态检测请求 connect_port  #向当前RS的哪个PORT发起健康状态检测请求 bindto  #发出健康状态检测请求时使用的源地址 bind_port  #发出健康状态检测请求时使用的源端口 connect_timeout  #客户端请求的超时时长，等于haproxy的timeout server}

3.6.2 实战案例

3.6.2.1 实战案例：实现单主的 LVS-DR 模式

在所有的后端服务器（即Real Server）上都要做以下配置！！！

我们的实验环境要在RS1和RS2上做以下配置。

这四个配置是 Linux 系统中针对 ARP（地址解析协议）行为的关键内核参数设置，主要用于 多网卡、VIP（虚拟 IP）或高可用集群环境（如 LVS、Keepalived 等架构），核心目的是 避免 ARP 广播导致的 IP 地址冲突、网络流量混乱或高可用切换异常。

sysctl -p是应用配置的命令

在所有后端服务器上要下载httpd，然后往发布文件中写入测试内容，然后重启服务保证服务处于运行。

所有后端服务器都要临时添加172.25.254.100这个VIP来进行实验。

在KA1和KA2中都要进行以下配置，因为配置相同，所以配置图就不重复放了。

在两个Keepalive路由器上要下载ipvsadm软件。

进行测试：

发现Keepalived上自动生成了负载均衡策略

模拟故障：

模拟RS1故障后停止服务

全部流量被重定向到RS2中

然后再次查看负载均衡策略，发现RS1被踢出了策略，而RS2保留了下来。

3.6.2.2 企业示例: 双主分别实现httpd和mysql服务的调度

注意：此示例的配置含有上面的示例的配置，所以一步步来，做完上面的示例再做这个会比较好，不然的话可能会出错。

所有后端服务器中都添加172.25.254.200这个VIP，并且下载mariadb数据库。

给后端服务器的mysql服务设置一下server-id，方便我们后续实验查询使用的是哪台RS的mysql服务。

设置mariadb开机自启动，然后创建lee用户，再授予lee用户全部权限，最后刷新权限。

查看对应主机的server_id是否正确。

如果下面的设置lee用户权限的mysql语句错误，可以使用下面的代码分离操作。
创建用户：mysql -e \"CREATE USER \'lee\'@\'%\' IDENTIFIED BY \'lee\';\"授予权限：mysql -e \"GRANT ALL PRIVILEGES ON *.* TO \'lee\'@\'%\';\"刷新权限：mysql -e \"FLUSH PRIVILEGES;\"
在所有后端服务器中还需要添加172.25.254.100这个VIP，用来实现http服务。

指定172.25.254.200这个VIP指向的是数据库服务。

指定172.25.254.100这个VIP访问的是http服务。

重启keepalived服务后，就会看到自动生成的ipvsadm策略中包含了对http服务80端口和对数据库服务3306端口的策略。

最后进行测试：

发现两个服务都进行了轮询，并且和设想的一样，VIP172.25.254.100指向了http服务，VIP172.25.254.200指向了mysql服务。

3.7 实现其它应用的高可用性 VRRP Script

keepalived利用 VRRP Script 技术，可以调用外部的辅助脚本进行资源监控，并根据监控的结果实现优先动态调整，从而实现其它应用的高可用性功能

参考配置文件：/usr/share/doc/keepalived/keepalived.conf.vrrp.localcheck

3.7.1 VRRP Script 配置

分两步实现：

定义脚本

vrrp_script：自定义资源监控脚本，vrrp实例根据脚本返回值，公共定义，可被多个实例调用，定义在vrrp实例之外的独立配置块，一般放在global_defs设置块之后。

通常此脚本用于监控指定应用的状态。一旦发现应用的状态异常，则触发对MASTER节点的权重减至低于SLAVE节点，从而实现 VIP 切换到 SLAVE 节点。

vrrp_script  { script | #此脚本返回值为非0时，会触发下面OPTIONS执行 OPTIONS}

调用脚本

track_script：调用vrrp_script定义的脚本去监控资源，定义在VRRP实例之内，调用事先定义的vrrp_script。

track_script { SCRIPT_NAME_1 SCRIPT_NAME_2}

3.7.1.1 定义 VRRP script

vrrp_script  { #定义一个检测脚本，在global_defs 之外配置 script | #shell命令或脚本路径 interval   #间隔时间，单位为秒，默认1秒 timeout   #超时时间 weight  #默认为0,如果设置此值为负数，  #当上面脚本返回值为非0时  #会将此值与本节点权重相加可以降低本节点权重，  #即表示fall.  #如果是正数，当脚本返回值为0，  #会将此值与本节点权重相加可以提高本节点权重  #即表示 rise.通常使用负值 fall #执行脚本连续几次都失败,则转换为失败，建议设为2以上 rise #执行脚本连续几次都成功，把服务器从失败标记为成功 user USERNAME [GROUPNAME]  #执行监测脚本的用户或组 init_fail #设置默认标记为失败状态，监测成功之后再转换为成功状态}

3.7.1.2 调用 VRRP script

vrrp_instance test { ... ... track_script {  }}#在vrrp_instance块中加入track_script块来跟踪vrrp_script，是vrrp_script块的名字，track_script块中配置的是。

3.7.2 实战案例：可以利用脚本实现主从角色切换

返回值为0说明执行成功，根据脚本执行的命令，说明/mnt/lee文件不存在。

创建文件后脚本返回值为1，说明执行错误。

结果测试：

KA1优先级变为70时可以抓包应该是因为配置的抢占延迟为10S，抓包的时候VIP还没被KA2抢占过去。

3.7.3 实战案例：实现HAProxy高可用（注意：此架构不能使用非抢占模式）

首先，在两台KA中下载haproxy软件。

下载了HAproxy后，负载均衡就不需要keepalived中的virtual_server块来进行配置了，所以将这些keepalived配置文件中的virtual_server块注释掉。

将keepalived配置文件中关于四层TCP负载均衡的配置注释掉后，再修改HAProxy的配置。

在HAProxy配置文件中新添加一个listen块进行负载均衡的配置。

可以看到KA1和KA2中的VIP一个是172.25.254.100，另一个是172.25.254.200，是不相同的，所以这时候我们就需要启用一个内核参数。

net.ipv4.ip_nonlocal_bind = 1 是 Linux 内核的一个关键参数，用于允许进程绑定（bind）到非本地 IP 地址。

net.ipv4.ip_nonlocal_bind的作用：

突破本地 IP 限制：
- 默认行为（值为 0）：进程只能绑定到本机已配置的 IP 地址（如 eth0 的 IP 或 127.0.0.1）。若尝试绑定未配置的 IP（如未分配的虚拟 IP），系统会拒绝并报错 Cannot assign requested address。
- 启用后（值为 1）：进程可绑定任意 IP 地址（即使该 IP 未配置在本机网卡上）。这一行为对高可用集群中的 VIP（虚拟 IP） 场景至关重要。

在两台KA中开启haproxy服务。

检查haproxy服务是否启动并且监听80端口。

问题呈现：

当KA1运行haproxy服务时，我们可以通过172.25.254.100这个VIP来进行访问。

但是当KA1的haproxy服务被停止后，我们就不能通过172.25.254.100进行访问了，因为172.25.254.100这个VIP没有进行漂移，即172.25.254.100这个VIP还在KA1身上，只不过因为KA1的haproxy服务被关闭导致我们无法访问。

为了解决上面的问题，我们应该在KA1的haproxy服务关闭时将172.25.254.100这个VIP漂移到还在运行haproxy服务的KA2身上。

下面我们通过写一个监控haproxy的脚本文件来达到VIP漂移的目的，其实就是使用VRRP Script配置和脚本来达到我们的一个监控程序运行的目的。

注意：以下配置在KA1和KA2中都要进行，这里就只放KA1的配置图片了，免得眼花！！！

killall -0 haproxy的作用

killall：通过进程名管理进程的命令工具。
-0：发送信号 0（空信号），仅检查进程是否存在，不终止进程：
- 若 haproxy 进程存在，返回状态码 0（成功）。
- 若不存在，返回状态码 1（失败）。

测试脚本是否起作用，下图说明脚本成功起作用了。

修改keepalived的配置文件，让这个脚本文件来对监控haproxy。

然后重启keepalived服务，让配置生效。

最后进行测试：

先对172.25.254.100进行访问，然后查看ip，发现172.25.254.100在KA1的身上。

然后暂停KA1的haproxy服务，再次查看ip，发现此时172.25.254.100漂移到KA2身上了，KA1身上已经没有VIP了，并且客户端client仍然能够访问172.25.254.100，说明实验成功，达到了VIP漂移。

值得注意的是：此架构不能使用非抢占模式，实现VIP漂移的本质就是监控haproxy进程的运行来进行优先级的升高和降低，从而让另一个KA服务器将VIP抢占过去。

高可用集群Keepalived

一、高可用集群

1.1 集群类型

​​1. 高可用性集群（High Availability Cluster, HA）​​

​​2. 负载均衡集群（Load Balancing Cluster, LB）​​

1.2 系统可用性

可用性定义与量化标准​​

1.3 系统故障

1、硬件故障​​

2、软件故障​​

3、硬件故障 vs 软件故障对比​​

1.4 实现高可用

1、冗余机制：降低MTTR的核心策略​​

1. ​​主备模式（Active/Passive）​​

2. ​​双主模式（Active/Active）​​

2、降低MTTR的实践方案​​

1. ​​自动化故障转移流程​​

2. ​​脑裂防护与仲裁机制​​

3. ​​数据同步优化​​

3、架构对比与选型建议​​