【分布式技术】KeepAlived高可用架构科普

KeepAlived高可用架构

- - Keepalived 架构详解
  - - 一、核心架构组件
    - 二、VRRP 协议详解
    - - 1. **VRRP 核心概念**
      - 2. **VRRP 工作流程**
      - 3. **VRRP 通信机制**
    - 三、高可用架构模型
    - 四、健康检查机制
    - 五、配置文件详解
    - - 配置文件关键参数说明：
    - 六、高可用实现流程
    - 七、脑裂问题与解决方案
    - - 1. **脑裂的常见原因**
      - 2. **脑裂的解决方案**
    - 八、应用场景与最佳实践
    - 九、总结

Keepalived 架构详解

Keepalived 是一个基于 VRRP（Virtual Router Redundancy Protocol） 的高可用性（High Availability, HA）解决方案，主要用于保障服务的持续性和可靠性。它的核心目标是通过自动故障转移（Failover）和健康检查机制，确保在服务器或服务出现故障时，能够无缝切换到备用节点，从而实现服务的不间断运行。

一、核心架构组件

Keepalived 的架构主要由以下三个核心模块组成：

Core 模块
- 功能：负责 Keepalived 的主进程启动、全局配置文件的加载与解析，以及基础服务的初始化。
- 作用：作为整个系统的控制中枢，管理其他模块的运行状态和生命周期。
Check 模块
- 功能：提供健康检查（Health Check）功能，支持对本地服务（如 Nginx、HAProxy）或远程服务（如 TCP/HTTP 端口）的监控。
- 作用：通过周期性检查服务的可用性，判断节点是否正常运行，并触发故障转移或通知机制。
VRRP 模块
- 功能：实现 VRRP 协议的核心逻辑，包括虚拟 IP（VIP）的分配、主备节点的选举、心跳检测等。
- 作用：通过 VRRP 协议动态管理主备节点的状态，确保虚拟 IP 的高可用性。

二、VRRP 协议详解

VRRP（Virtual Router Redundancy Protocol）是 Keepalived 实现高可用性的关键技术，其核心思想是通过多台设备共享一个虚拟 IP 地址，形成一个虚拟路由器组（Virtual Router Group），从而实现冗余和故障转移。

1. VRRP 核心概念

虚拟路由器（Virtual Router）：由一组物理路由器（或服务器）组成，共享同一个虚拟 IP 和 MAC 地址。
虚拟 IP（VIP）：对外提供服务的 IP 地址，客户端通过 VIP 访问服务。
Master（主节点）：当前负责处理流量的节点，定期发送 VRRP 广告报文（Advertisement）。
Backup（备份节点）：待命节点，监听 Master 的广告报文，若超时未收到则接管 VIP。
Priority（优先级）：节点的优先级（0-255），决定选举时的主备顺序。优先级越高，越容易成为 Master。
Advert Int（广告间隔）：Master 发送广告报文的时间间隔（默认 1 秒）。
Preempt（抢占模式）：若启用，Backup 在优先级高于当前 Master 时可强制接管；否则需等待 Master 失效。

2. VRRP 工作流程

初始化阶段：所有节点广播自己的优先级，选举出初始的 Master。
正常运行阶段：Master 定期发送广告报文（默认 1 秒），Backup 监听这些报文。
故障检测阶段：Backup 连续 3 次未收到 Master 的广告报文，判定 Master 失效。
故障转移阶段：Backup 通过优先级选举新的 Master，并绑定 VIP。
恢复阶段：原 Master 恢复后，根据抢占模式决定是否重新成为 Master。

3. VRRP 通信机制

组播地址：VRRP 使用组播地址 224.0.0.18（IPv4）或 FF02::12（IPv6）发送广告报文。
协议号：VRRP 的 IP 协议号为 112。
认证方式：
- 无认证：不加密，仅用于测试环境。
- 简单密码认证（PASS）：通过明文密码验证报文合法性。
- IPSEC 认证（AH）：通过 IPSEC 技术加密通信。

三、高可用架构模型

Keepalived 支持两种典型的高可用架构模型：

主备模式（Active-Passive）
- 特点：一个 Master 节点负责处理流量，Backup 节点处于待命状态。
- 适用场景：适用于对资源利用率要求较低的场景，如数据库主从复制。
- 优点：配置简单，故障转移快速。
- 缺点：Backup 节点资源闲置，资源利用率低。
双主模式（Active-Active）
- 特点：多个 Master 节点同时处理流量，彼此互为备份。
- 适用场景：适用于负载均衡场景（如 Nginx + Keepalived）。
- 优点：资源利用率高，可承载更高并发流量。
- 缺点：配置复杂，需额外处理资源冲突问题（如脑裂）。

四、健康检查机制

Keepalived 的健康检查模块（Check 模块）通过以下方式确保服务的可用性：

本地服务检查
- 脚本检查：通过自定义脚本（如 check_nginx.sh）检查本地服务的运行状态。
- 进程检查：检查关键进程（如 Nginx、HAProxy）是否存活。
远程服务检查
- TCP 检查：通过 TCP 连接检测目标端口是否开放。
- HTTP 检查：发送 HTTP 请求并验证响应码（如 200 OK）。
- SMTP 检查：检查邮件服务器的可用性。
权重调整
- Weight（权重）：根据检查结果动态调整节点的优先级。例如，检查失败时降低节点的优先级，避免其被选为 Master。

五、配置文件详解

Keepalived 的配置文件（/etc/keepalived/keepalived.conf）通常包含以下部分：

global_defs {
    notification_email {
        admin@example.com
    }
    notification_email_from keepalived@example.com
    smtp_server 127.0.0.1
    smtp_connect_timeout 30
    router_id LVS_MASTER  # 本节点的唯一标识
}

vrrp_instance VI_1 {
    state MASTER          # 初始角色：MASTER 或 BACKUP
    interface eth0        # 监听的网络接口
    virtual_router_id 51  # 虚拟路由器 ID（0-255）
    priority 100          # 优先级（100 > 90）
    advert_int 1          # 广告间隔（秒）
    
    authentication {
        auth_type PASS    # 认证类型
        auth_pass 1234    # 认证密码
    }

    virtual_ipaddress {
        192.168.1.100/24  # 虚拟 IP 地址
    }

    track_script {
        chk_nginx         # 引用健康检查脚本
    }
}

vrrp_script chk_nginx {
    script "/etc/keepalived/check_nginx.sh"  # 健康检查脚本路径
    interval 2           # 检查间隔（秒）
    weight -20           # 检查失败时优先级降低的值
    fall 2               # 连续失败 2 次判定故障
    rise 1               # 连续成功 1 次判定恢复
}

配置文件关键参数说明：

state：初始角色（MASTER/BACKUP）。
virtual_router_id：虚拟路由器的唯一标识符，主备节点需相同。
priority：节点优先级，数值越大越容易成为 Master。
advert_int：广告报文发送间隔，单位为秒。
virtual_ipaddress：虚拟 IP 地址，客户端通过此 IP 访问服务。
track_script：引用健康检查脚本，用于动态调整节点状态。

六、高可用实现流程

初始化阶段
- 所有节点启动 Keepalived，广播自己的优先级。
- 根据优先级选举出初始的 Master。
正常运行阶段
- Master 定期发送 VRRP 广告报文（默认 1 秒）。
- Backup 监听广告报文，确认 Master 的状态。
故障检测阶段
- Backup 连续 3 次未收到广告报文，判定 Master 失效。
- Backup 通过优先级选举新的 Master，并绑定 VIP。
故障恢复阶段
- 原 Master 恢复后，根据抢占模式（Preempt）决定是否重新成为 Master。
- 如果启用抢占模式，高优先级节点会重新接管 VIP。

七、脑裂问题与解决方案

脑裂（Split-Brain） 是 Keepalived 高可用架构中最严重的故障之一，指主备节点因网络分区或配置错误同时认为对方失效，导致两个节点都尝试接管 VIP，造成服务冲突。

1. 脑裂的常见原因

网络分区：主备节点之间的网络中断，导致通信失败。
优先级配置错误：多个节点优先级相同，无法正确选举 Master。
系统资源不足：节点因资源耗尽无法处理 VRRP 报文。

2. 脑裂的解决方案

网络冗余：通过多网卡、多路由等方式提高网络可靠性。
仲裁机制：引入第三方仲裁节点（如共享存储或数据库）判断主备状态。
合理配置优先级：确保每个节点的优先级唯一，避免平票。
设置抢占模式：根据业务需求选择是否启用抢占模式。

八、应用场景与最佳实践

Web 服务高可用
- 配合 Nginx 或 HAProxy 实现负载均衡和故障转移。
- 示例配置：两台 Nginx 服务器 + Keepalived 实现双主模式。
数据库高可用
- 与 MySQL 主从复制结合，通过 Keepalived 实现主从切换。
- 注意：需确保数据同步机制完善，避免脑裂导致数据不一致。
云原生环境集成
- 在 Kubernetes 中通过 Keepalived 实现 Ingress 控制器的高可用。
- 示例：使用 MetalLB + Keepalived 提供稳定的外部 IP。
性能监控与调优
- 定期检查 VRRP 广告报文的频率和延迟。
- 优化健康检查脚本的执行效率，避免误判。