Linux服务器高可用集群搭建与Keepalived故障自动切换配置详解

高可用集群的核心问题与架构选型

服务器单点故障是生产环境最不能容忍的风险。一台物理机或云服务器的硬件故障、内核崩溃、网络中断，都可能导致业务长时间不可用。高可用集群的目标不是消除故障，而是将故障恢复时间从分钟级压缩到秒级甚至毫秒级。

Keepalived是Linux下最成熟的VRRP（虚拟路由冗余协议）实现，专门解决IP漂移和故障自动切换问题。相比Pacemaker+Corosync的全功能集群管理方案，Keepalived更轻量、配置更简单，适合大部分Web服务、数据库主从切换、负载均衡器高可用等场景。

核心原理：两台服务器组成主备对，共享一个虚拟IP（VIP）。主节点持续发送VRRP心跳广播，备节点监听。主节点故障时，备节点在秒级时间内接管VIP，客户端几乎无感知。

Keepalived安装与基础配置

以CentOS Stream 9/Ubuntu 24.04为例：

# CentOS
yum install -y keepalived

# Ubuntu
apt install -y keepalived

# 开启内核IP转发
sysctl -w net.ipv4.ip_forward=1
echo 'net.ipv4.ip_forward=1' >> /etc/sysctl.conf
sysctl -p

主节点配置 /etc/keepalived/keepalived.conf：

global_defs {
    router_id MASTER_NODE
    vrrp_skip_check_adv_addr
    vrrp_garp_interval 0
    vrrp_gna_interval 0
}

vrrp_instance VI_1 {
    state MASTER          # 主节点
    interface eth0        # 绑定网卡
    virtual_router_id 51  # 虚拟路由ID，主备必须一致
    priority 100          # 优先级，主节点高于备节点
    advert_int 1          # 心跳间隔1秒
    authentication {
        auth_type PASS
        auth_pass MyStr0ngP@ss  # 主备必须一致
    }
    virtual_ipaddress {
        192.168.1.100/24 dev eth0  # VIP地址
    }
    track_script {
        chk_nginx          # 关联健康检查脚本
    }
}

备节点配置仅三处不同：

vrrp_instance VI_1 {
    state BACKUP          # 备节点
    priority 90           # 优先级低于主节点
    # 其余配置与主节点完全一致
}

应用层健康检查与故障检测脚本

Keepalived本身的VRRP心跳只检测网络层可达性。如果主节点网络正常但Nginx/MySQL等服务挂了，VIP不会漂移。必须配置应用层健康检查，让Keepalived在服务异常时主动降低优先级或触发切换。

#!/bin/bash
# /etc/keepalived/check_nginx.sh

# 检查Nginx进程是否存活
if ! pidof nginx > /dev/null; then
    exit 1
fi

# 检查Nginx是否能正常响应
HTTP_CODE=$(curl -s -o /dev/null -w '%{http_code}' http://127.0.0.1:80/health)
if [ "$HTTP_CODE" != "200" ]; then
    exit 1
fi

exit 0

在keepalived.conf中注册检查脚本：

vrrp_script chk_nginx {
    script "/etc/keepalived/check_nginx.sh"
    interval 2       # 每2秒检查一次
    weight -20       # 检查失败时降低优先级20
    fall 2           # 连续失败2次才判定异常
    rise 1           # 恢复1次即判定正常
}

weight -20的机制：主节点优先级100，检查失败后降至80，低于备节点的90，触发VIP漂移。这比直接杀掉Keepalived进程更优雅，因为服务恢复后优先级回升，VIP可以回切（如果不设置nopreempt）。

脑裂问题防护与仲裁机制

脑裂（Split Brain）是高可用集群最危险的状态：主备之间的网络中断，但双方都认为自己应该持有VIP，导致两台服务器同时绑定同一IP，引发网络混乱。

防护方案一：增加仲裁节点。三节点集群中，只有获得多数票（2票）的节点才能持有VIP。Keepalived原生不支持投票机制，但可以通过脚本实现：

#!/bin/bash
# /etc/keepalived/check_peer.sh

# 尝试ping仲裁节点
PEER_IP=192.168.1.200  # 仲裁节点IP

if ! ping -c 1 -W 1 $PEER_IP > /dev/null 2>&1; then
    # 无法到达仲裁节点，降低优先级
    exit 1
fi
exit 0

防护方案二：使用preempt和nopreempt策略控制回切行为：

vrrp_instance VI_1 {
    state BACKUP           # 两台都设为BACKUP
    priority 100           # 初始主节点优先级高
    nopreempt              # 故障恢复后不自动回切
    # ...
}

两台都设为BACKUP且主节点配置nopreempt，意味着只有当前主节点真正宕机时才会切换，恢复后不会争抢VIP。回切需要人工介入或写脚本触发。

Keepalived日志排错与状态监控

Keepalived日志默认输出到/var/log/messages（CentOS）或/var/log/syslog（Ubuntu）。关键日志事件：

# 主节点接管VIP
Entering MASTER STATE
VRRP_Instance(VI_1) Transition to MASTER STATE
VRRP_Instance(VI_1) Entering MASTER STATE

# 备节点检测到主节点故障
VRRP_Instance(VI_1) Entering MASTER STATE (from BACKUP)

# 健康检查触发优先级变更
VRRP_Script(chk_nginx) failed
VRRP_Instance(VI_1) Changing effective priority from 100 to 80

实时监控VIP状态：

# 查看当前VIP绑定在哪个网卡上
ip addr show eth0 | grep 192.168.1.100

# 查看VRRP广播
tcpdump -i eth0 vrrp

# 查看Keepalived进程状态
systemctl status keepalived

多VIP与多实例配置实战

实际生产中常需要多个VIP（比如Web服务和数据库服务分别使用不同VIP），可以在同一keepalived.conf中配置多个VRRP实例：

vrrp_instance VI_WEB {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 100
    virtual_ipaddress {
        192.168.1.100/24 dev eth0
    }
    track_script { chk_nginx }
}

vrrp_instance VI_DB {
    state BACKUP         # DB实例主备角色可以与Web实例相反
    interface eth0
    virtual_router_id 52  # 不同的virtual_router_id
    priority 90
    virtual_ipaddress {
        192.168.1.101/24 dev eth0
    }
    track_script { chk_mysql }
}

这种配置让两台服务器互为主备——A节点承担Web服务VIP，B节点承担数据库VIP，资源利用率翻倍。任一节点故障，另一节点同时接管两个VIP。

云服务器环境下的特殊处理

云厂商的网络底层通常不允许ARP欺骗，Keepalived的VIP漂移依赖ARP广播宣告新MAC地址，在云环境中可能不生效。主流云厂商提供高可用VIP产品替代方案：

• 阿里云：使用HAVIP（高可用虚拟IP）产品，绑定到ECS实例
• 腾讯云：使用HAVIP或绑定时自动切换EIP
• AWS：使用ENI（弹性网卡）附加，脚本中调用EC2 API实现IP切换

自建机房或物理服务器环境不存在此限制，Keepalived可以正常工作。

Keepalived配置完成后，建议用killall -9 nginx模拟服务故障，观察VIP是否在2-4秒内完成漂移；用ifdown eth0模拟网络故障，验证脑裂防护是否生效。这两项验证通过后，方可投入生产使用。