一、Keepalived 典型应用场景深度解析

1. Web 服务器集群：统一入口与故障容错

1.1 场景需求

• 核心目标：为多台 Web 服务器提供统一 VIP 入口，隐藏后端节点细节，实现故障透明切换。

• 挑战：

  • 确保用户请求在主节点故障时自动转发到备份节点。

  • 避免会话丢失（如用户登录状态），需结合会话共享（如 Redis）或粘性会话（Sticky Session）。

1.2 架构设计

• 组件说明：

  • Keepalived 节点：2 台服务器（MASTER/BACKUP）共享 VIP 192.168.1.254。

  • Web 服务器：Nginx 或 Tomcat 集群，部署相同应用程序，共享静态资源（如 NFS）或使用对象存储（如 S3）。

1.3 配置要点

vrrp_instance WEB_VIP {
  state MASTER
  interface eth0
  virtual_router_id 50
  priority 100
  virtual_ipaddress {
    192.168.1.254/24 dev eth0
  }
  track_script {
    check_web_service  # 检测 Web 服务端口（80/443）
  }
}

track_script {
  check_web_service {
    script "/etc/keepalived/check_nginx.sh"  # 检测 Nginx 进程
    interval 2
    weight -20
  }
}

1.4 优化方案

• 粘性会话实现：在 Nginx 中配置 ip_hash 策略，确保同一客户端 IP 的请求始终路由到同一后端服务器：

upstream web_backend {
  ip_hash;
  server 192.168.1.101:80;
  server 192.168.1.102:80;
}

• 静态资源优化：使用 CDN 缓存静态文件（如图片、CSS），减少后端服务器压力，提升故障切换时的响应速度。

2. 数据库集群：主从复制与故障切换

2.1 场景需求

• 核心目标：在 MySQL/PostgreSQL 主从集群中，通过 Keepalived 实现主库故障时的自动切换，确保业务连续性。

• 挑战：

  • 避免脑裂（Split-Brain）导致数据不一致。

  • 确保切换后从库已完成数据同步，避免数据丢失。

2.2 架构设计（以 PostgreSQL 为例）

• 组件说明：

  • 主库（MASTER）：提供读写服务，VIP 绑定在主库节点。

  • 从库（BACKUP）：实时复制主库数据，主库故障时提升为新主库。

  • repmgr：配合 Keepalived 实现主从切换逻辑（如流复制状态检测）。

2.3 配置要点

vrrp_instance DB_VIP {
  state MASTER
  interface eth0
  virtual_router_id 51
  priority 100
  virtual_ipaddress {
    192.168.1.254/24 dev eth0
  }
  track_script {
    check_postgres_master  # 检测主库复制状态
  }
}

track_script {
  check_postgres_master {
    script "/etc/keepalived/check_pg_master.sh"
    interval 2
    weight -50  # 优先级大幅降低，确保快速切换
  }
}

检测脚本示例（判断主库是否允许写入）：

#!/bin/bash
# /etc/keepalived/check_pg_master.sh
is_master=$(sudo -u postgres psql -tAc "SELECT pg_is_in_recovery();")
if [ "$is_master" = "f" ]; then
  exit 0  # 是主库，状态正常
else
  exit 1  # 非主库，触发故障转移
fi

2.4 最佳实践

• 切换流程优化：

1. Keepalived 检测到主库故障，降低优先级并触发选举。

2. 备份节点接管 VIP，通过 repmgr 提升为新主库。

3. 原主库恢复后，作为从库重新加入集群（非抢占模式）。

• 数据一致性保障：使用 synchronous_commit 确保主从数据强一致（适用于金融场景）：

# postgresql.conf
synchronous_commit = on
synchronous_standby_names = '*'

3. 负载均衡器高可用：保障流量入口稳定

3.1 场景需求

• 核心目标：为 HAProxy、Nginx 等负载均衡器节点提供高可用性，避免单点故障导致的流量中断。

• 挑战：

  • 确保负载均衡配置在节点间同步（如 HAProxy 的 config sync）。

  • 快速检测负载均衡器进程故障（如进程崩溃或配置错误）。

3.2 架构设计（以 HAProxy 为例）

• 组件说明：

  • 负载均衡节点：2 台服务器运行 HAProxy，共享 VIP 192.168.1.254。

  • 后端服务器：应用服务器集群，由 HAProxy 进行流量分发。

3.3 配置要点

vrrp_instance LB_VIP {
  state MASTER
  interface eth0
  virtual_router_id 52
  priority 100
  virtual_ipaddress {
    192.168.1.254/24 dev eth0
  }
  track_script {
    check_haproxy_process  # 检测 HAProxy 进程存活
  }
}

track_script {
  check_haproxy_process {
    script "/etc/keepalived/check_haproxy.sh"
    interval 1
    weight -30
  }
}

检测脚本示例（确保 HAProxy 主进程存在）：

#!/bin/bash
# /etc/keepalived/check_haproxy.sh
if ! pgrep -f "haproxy -f /etc/haproxy/haproxy.cfg" >/dev/null; then
  # 尝试重启 HAProxy
  systemctl restart haproxy
  sleep 2
  if ! pgrep -f "haproxy -f /etc/haproxy/haproxy.cfg" >/dev/null; then
    exit 1  # 重启失败，触发故障转移
  fi
fi
exit 0

3.4 高级特性应用

• 配置同步：使用 rsync 或 git 实时同步负载均衡配置文件：

# 主节点配置变更后自动同步到备份节点
rsync -avz /etc/haproxy/haproxy.cfg backup_node:/etc/haproxy/

• 动态后端管理：通过 HAProxy 的 stats socket 接口动态添加 / 删除后端服务器，配合 Keepalived 健康检查实现自动扩缩容。

二、跨场景通用最佳实践

1. 多数据中心容灾

• 场景：主数据中心与灾备中心通过专线连接，Keepalived 组跨中心部署。

• 配置要点：

  • 主中心节点优先级 100，灾备中心节点优先级 90。

  • 启用 nopreempt 模式，避免主中心网络波动导致频繁切换。

2. 云原生场景适配

• 容器化部署：使用 keepalived-vip 插件在 Kubernetes 中实现 VIP 动态分配，配合 StatefulSet 管理有状态节点。

• 公有云负载均衡：在 AWS/GCP 中，Keepalived 与弹性 IP（EIP）结合，实现虚拟机实例的高可用。

3. 性能与成本平衡

• 低成本方案：在测试环境或中小规模集群中，可将 Keepalived 与业务进程部署在同一节点，减少硬件成本。

• 性能监控：通过 Prometheus 采集 Keepalived 指标（如切换次数、延迟），设置告警阈值（如切换时间超过 5 秒）。

三、总结：选择 Keepalived 的核心场景

Keepalived 通过轻量级配置实现网络层高可用，尤其适合以下场景：

1. 需要统一入口的无状态服务：如 Web 服务器、API 网关，通过 VIP 提供稳定访问地址。

2. 主从架构的有状态服务：如数据库、缓存集群，结合复制机制实现故障切换。

3. 基础设施组件冗余：如负载均衡器、DNS 服务器，保障流量路由稳定。

与云原生方案（如 Kubernetes 服务）相比，Keepalived 在传统数据中心和混合云场景中仍具有部署简单、兼容性强的优势。通过合理设计配置与检测逻辑，可在不同场景下发挥其高可用性价值。