如何在Linux上实现高可用性架构与故障自动切换

在Linux环境中构建高可用性系统，本质目标是让服务在硬件损坏、网络异常或进程崩溃时仍可持续对外提供能力。高可用并不是简单地多买几台机器，而是依靠软件层的协调，使多个节点表现为一个逻辑整体，当个体失效时用户几乎无感知。常见的实现路径分为网络层负载与资源级集群两类，前者以虚拟IP配合健康检查实现流量重定向，后者通过资源代理管理具体服务生命周期。

基于Keepalived的VIP漂移方案

Keepalived最初为LVS设计，后来演变为通用的高可用组件。它使用VRRP协议在多个节点间协商虚拟路由器身份，拥有最高优先级的节点成为Master并持有VIP。当Master节点心跳超时，Backup节点自动晋升并绑定VIP，客户端连接因此被引到新节点。该方案轻量，不感知具体业务进程，只保证网络入口不中断。

配置Keepalived时，需要定义vrrp_instance与virtual_ipaddress。下面是一段最小可用配置，展示了两个节点如何通过优先级区分角色，并借助脚本做应用级健康检查而非仅看网络连通：

vrrp_script chk_nginx {
    script "/usr/bin/pgrep nginx"
    interval 2
    weight -20
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 150
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass ipipp_pass
    }
    virtual_ipaddress {
        192.168.0.100
    }
    track_script {
        chk_nginx
    }
}

这种方案的优点在于部署简单、故障切换在一秒内完成，适合无状态Web服务。缺点是它只管IP不管数据，如果后端涉及本地文件或会话，需要额外用共享存储或同步工具。另外，若健康检查脚本写错，可能频繁触发切换造成抖动。

使用Pacemaker与Corosync管理资源

当服务本身有状态，例如数据库或分布式队列，就需要Pacemaker加Corosync这类资源级集群。Corosync负责节点间成员关系与消息可靠传输，Pacemaker作为资源管理器，决定某个资源在哪一节点运行，并在异常时按约束重新排布。它能管理浮动IP、文件系统挂载、systemd服务等多种资源类型。

与Keepalived不同，Pacemaker通过资源代理（RA）理解服务语义。例如配置一个VIP资源与Nginx资源，并设定它们必须同节点启动，可以用如下命令片段描述逻辑关系：

pcs resource create vip ocf:heartbeat:IPaddr2 ip=192.168.0.100 cidr_netmask=24 op monitor interval=10s
pcs resource create nginx systemd:nginx op monitor interval=5s
pcs constraint colocation add nginx with vip INFINITY
pcs constraint order vip then nginx

该架构的强项是可以表达复杂拓扑，比如主备、多活、地理位置亲和。代价是学习曲线陡，配置文件与约束规则容易出错。运维时建议用pcs status定期查看资源分布，并结合fence设备处理脑裂，避免双节点同时写同一块存储。

脑裂防护与数据一致性保障

高可用集群最危险的状况是脑裂：由于网络分区，两个节点都认为自己该持有VIP或服务主控权，造成重复写入或外部请求被撕扯。单纯依赖超时判断不够，必须引入仲裁机制。常见做法包括使用第三方仲裁节点、磁盘锁或云厂商的元数据接口，当本节点无法获得多数票时主动降级。

对于数据层，若采用主备复制数据库，应开启半同步复制减少丢失窗口；若用共享存储，务必配置STONITH（ shoot the other node in the head）让失联节点断电而非继续服务。下面示例展示在Corosync中启用两个仲裁链路的思路，防止单网络抖动误判：

totem {
    interface {
        ringnumber: 0
        bindnetaddr: 192.168.0.0
        mcastaddr: 239.255.1.1
    }
    interface {
        ringnumber: 1
        bindnetaddr: 10.0.0.0
        mcastaddr: 239.255.2.2
    }
}

此外，任何高可用方案上线前都应做混沌测试：随机杀进程、拔网线、断电，观察VIP是否漂移、请求成功率是否掉底。只有经过真实破坏演练的系统，才敢称具备Linux高可用性。很多故障源于忽略监控，因此把集群状态接进Prometheus并设告警，和架构本身同等重要。

Linux高可用KeepalivedCorosync修改时间：2026-08-13 17:36:56