keepalived案例

案例一：Web 服务器高可用集群

场景：为 Nginx 构建双节点热备，确保服务连续性

• 架构图

  Client → VIP(192.168.1.100)
           ↓
  +----------------+      +----------------+
  | Master(1.10)   |      | Backup(1.11)   |
  | Keepalived     |<---->| Keepalived     |
  | Nginx          |      | Nginx          |
  +----------------+      +----------------+
  

• 关键配置：

主节点（1.10）配置：

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.1.100
    }
}

备节点（1.11）配置：

vrrp_instance VI_1 {
    state BACKUP
    priority 90  # 低于主节点
    # 其他配置与主节点相同
}

验证步骤：

1. 启动服务

   systemctl start keepalived nginx
   

2. 检查 VIP 状态

   # 主节点应显示 VIP
   ip addr show eth0 | grep 192.168.1.100
   
   # 客户端测试访问
   curl http://192.168.1.100
   

3. 模拟故障切换

   # 主节点停止 Keepalived
   systemctl stop keepalived
   
   # 检查 VIP 是否漂移到备节点
   ip addr show eth0  # 在备节点执行
   

案例二：LVS+Keepalived 负载均衡集群

场景：构建高性能 Web 负载均衡系统

• 架构图

  Client → VIP(192.168.1.100:80)
           ↓
  +----------------+
  | Load Balancer  |
  | Keepalived+LVS |
  +----------------+
           ↓
  +----------------+    +----------------+
  | Web Server 1   |    | Web Server 2   |
  | (192.168.1.20) |    | (192.168.1.21) |
  +----------------+    +----------------+
  

• 关键配置：

负载均衡器配置：

virtual_server 192.168.1.100 80 {
    delay_loop 6
    lb_algo rr  # 轮询算法
    lb_kind DR  # 直接路由模式
    persistence_timeout 50  # 会话保持

    real_server 192.168.1.20 80 {
        weight 1
        SSL_GET {
            url { path "/" digest ff20ad2481f97b1754ef3e12ecd3a9cc }
            connect_timeout 3
            retry 3
        }
    }
    real_server 192.168.1.21 80 {
        weight 1
        # 配置同上
    }
}

Web 服务器配置（DR 模式）：

# 绑定 VIP 到 lo 接口，禁用 ARP 响应
echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce
ifconfig lo:0 192.168.1.100 netmask 255.255.255.255 up

验证步骤：

1. 查看 LVS 规则

   ipvsadm -L -n
   

2. 压力测试

   ab -c 100 -n 10000 http://192.168.1.100/
   

3. 模拟节点故障

   # 在 Web Server 1 上停止 Nginx
   systemctl stop nginx
   
   # 检查流量是否自动切换到 Web Server 2
   

案例三：MySQL 高可用集群

场景：实现数据库主从自动切换

• 架构图

  Applications → VIP(192.168.1.100:3306)
                 ↓
  +----------------+      +----------------+
  | Master MySQL   |      | Slave MySQL    |
  | Keepalived     |<---->| Keepalived     |
  | (192.168.1.30) |      | (192.168.1.31) |
  +----------------+      +----------------+
  

• 关键配置：

MySQL 主节点配置：

vrrp_script chk_mysql {
    script "/etc/keepalived/check_mysql.sh"
    interval 2
    weight -20
}

vrrp_instance VI_1 {
    state MASTER
    priority 100
    track_script {
        chk_mysql
    }
    virtual_ipaddress {
        192.168.1.100
    }
}

健康检查脚本（check_mysql.sh）：

#!/bin/bash
mysql -h 127.0.0.1 -u monitor -pPASSWORD -e "SELECT 1;" >/dev/null 2>&1
if [ $? -ne 0 ]; then
    exit 1
fi
exit 0

验证步骤：

1. 测试主从复制

   # 在主库创建测试表
   mysql -e "CREATE DATABASE test; USE test; CREATE TABLE t1 (id INT); INSERT INTO t1 VALUES (1);"
   
   # 在从库验证数据同步
   mysql -e "USE test; SELECT * FROM t1;"
   

2. 模拟主库故障

   # 停止主库 MySQL
   systemctl stop mysqld
   
   # 检查 VIP 是否漂移到从库
   

3. 故障恢复后

   # 将原主库设置为新主库的从库
   CHANGE MASTER TO ...
   

案例四：脑裂问题排查与解决

场景：网络分区导致双主节点同时持有 VIP

排查步骤：

1. 检查日志

   tail -f /var/log/keepalived.log
   # 查找 VRRP 通告失败记录
   

2. 网络连通性测试

   ping -c 5 192.168.1.10  # 检查主备节点间通信
   

3. 查看 VIP 状态

   # 在所有节点执行，若多个节点显示 VIP，则发生脑裂
   ip addr show eth0 | grep 192.168.1.100
   

解决方案：

1. 增加冗余心跳链路

   track_interface {
       eth0  # 主网卡
       eth1  # 备用网卡
   }
   

2. 启用抢占延迟

   preempt_delay 30  # 故障恢复后延迟30秒再抢占
   

3. 仲裁机制

   vrrp_script chk_gateway {
       script "ping -c 3 192.168.1.1 || exit 1"
       interval 5
       weight -30
   }
   

案例五：Kubernetes API Server 高可用

场景：为 K8S 控制平面构建高可用入口

• 架构图

  Kubelet/Controller → VIP(192.168.1.100:6443)
                        ↓
  +----------------+      +----------------+
  | Keepalived     |      | Keepalived     |
  | HAProxy        |      | HAProxy        |
  | (192.168.1.40) |      | (192.168.1.41) |
  +----------------+      +----------------+
           ↓                       ↓
  +----------------+      +----------------+
  | kube-apiserver |      | kube-apiserver |
  | (master-1)     |      | (master-2)     |
  +----------------+      +----------------+
  

• 关键配置：

HAProxy 配置：

frontend kubernetes-frontend
    bind *:6443
    mode tcp
    option tcplog
    default_backend kubernetes-backend

backend kubernetes-backend
    mode tcp
    option tcplog
    balance roundrobin
    server master-1 192.168.1.50:6443 check
    server master-2 192.168.1.51:6443 check

Keepalived 配置：

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 100
    virtual_ipaddress {
        192.168.1.100
    }
    track_process {
        haproxy
    }
}

验证步骤：

1. 检查 API Server 健康状态

   curl -k https://192.168.1.100:6443/healthz
   

2. 模拟负载均衡器故障

   # 停止主节点 Keepalived
   systemctl stop keepalived
   
   # 验证 K8S 组件是否仍能正常通信
   kubectl get nodes
   

案例六：多 VIP 配置实现服务隔离

场景：为不同业务提供独立的高可用 VIP

• 配置示例：

# Web 服务 VIP
vrrp_instance VI_WEB {
    virtual_router_id 51
    virtual_ipaddress { 192.168.1.100 }
}

# 数据库服务 VIP
vrrp_instance VI_DB {
    virtual_router_id 52
    virtual_ipaddress { 192.168.1.101 }
}

# 监控服务 VIP
vrrp_instance VI_MONITOR {
    virtual_router_id 53
    virtual_ipaddress { 192.168.1.102 }
}

优势：

• 不同业务隔离，避免单点故障影响全部服务。
• 可根据业务重要性设置不同优先级和监控策略。

最佳实践总结

1. 网络配置：
   • 使用单播代替多播（unicast_peer），避免网络干扰。
   • 确保所有节点间网络互通，特别是心跳链路。
2. 健康检查：
   • 结合进程监控和服务状态检查（如 MySQL 查询、HTTP 请求）。
   • 设置合理的检测间隔（2-5 秒）和重试次数。
3. 参数调优：
   • advert_int：VRRP 通告间隔，建议 1-2 秒。
   • preempt_delay：故障恢复后延迟抢占，避免频繁切换。
   • garp_master_delay：成为 Master 后延迟发送 ARP 通告。
4. 运维建议：
   • 定期演练故障切换流程。
   • 配置日志集中管理（ELK/Splunk）。
   • 使用 Prometheus+Grafana 监控 Keepalived 状态。