Linux服务器高可用集群搭建：从Corosync配置到故障自动切换实战

服务器高可用架构：为什么需要Corosync+Pacemaker

服务器运维中，单机故障是业务中断的首要原因。高可用集群通过多节点冗余和自动故障切换，将服务恢复时间从小时级压缩到秒级。Corosync负责集群节点间的心跳通信和成员管理，Pacemaker负责资源调度和故障切换决策，两者配合是目前Linux服务器高可用方案的事实标准。

一套双节点高可用集群的典型指标：检测故障耗时3-5秒，切换资源耗时10-30秒，业务总中断时间控制在40秒以内。这比人工介入快了两个数量级。

环境准备与服务器硬件性能测评基准

搭建前先确认各节点基础环境一致。以下是双节点集群的最小配置要求：

两台服务器必须配置独立的心跳网络，避免业务网络拥塞时心跳包丢失导致误切换。心跳链路建议做双网卡bonding，进一步提高可靠性。

在各节点执行基础配置：

# 配置hosts解析
cat >> /etc/hosts << EOF
192.168.10.11  node1
192.168.10.12  node2
192.168.20.11  node1-hb
192.168.20.12  node2-hb
EOF

# 关闭防火墙和SELinux（生产环境按需开放端口）
systemctl disable --now firewalld
setenforce 0
sed -i 's/SELINUX=enforcing/SELINUX=disabled/' /etc/selinux/config

# 配置时间同步
dnf install -y chrony
systemctl enable --now chronyd

Corosync集群通信层配置详解

Corosync是集群的通信基础设施，负责节点发现、心跳检测和消息组播。配置文件位于/etc/corosync/corosync.conf。

totem {
    version: 2
    cluster_name: ha-cluster
    transport: knet
    token: 3000
    join: 1000
    consensus: 5000
    token_retransmits_before_loss_const: 10
    crypto_cipher: aes256
    crypto_hash: sha256
    interface {
        ringnumber: 0
        bindnetaddr: 192.168.20.0
        mcastport: 5405
        ttl: 1
    }
}

nodelist {
    node {
        ring0_addr: node1-hb
        name: node1
        nodeid: 1
    }
    node {
        ring0_addr: node2-hb
        name: node2
        nodeid: 2
    }
}

quorum {
    provider: corosync_votequorum
    two_node: 1
    wait_for_all: 0
    last_man_standing: 1
    auto_tie_breaker: 1
}

logging {
    to_logfile: yes
    logfile: /var/log/corosync/corosync.log
    to_syslog: yes
    timestamp: on
}

关键参数解读：

• transport: knet：使用Kronosnet传输层，支持加密和多链路冗余
• two_node: 1：双节点集群特殊配置，允许在失去一半节点时仍维持仲裁
• auto_tie_breaker: 1：自动选择低nodeid节点作为仲裁决胜方，避免双节点脑裂
• token: 3000：3秒心跳超时，生产环境建议不低于2秒

Pacemaker资源调度与故障切换策略

Pacemaker在Corosync之上管理集群资源（VIP、服务进程、文件系统等）。资源调度策略决定了故障时哪个节点接管服务。

# 安装Pacemaker
dnf install -y pacemaker pcs

# 认证节点
echo "hacluster:your_password" | pcs cluster auth node1 node2

# 创建集群
pcs cluster setup ha-cluster node1 node2 --enable --start

# 禁用STONITH（测试阶段，生产必须启用）
pcs property set stonith-enabled=false

# 设置故障恢复策略：不让故障节点自动回迁
pcs property set default-resource-stickiness=100

# 配置浮动VIP
pcs resource create VirtualIP ocf:heartbeat:IPaddr2 \
  ip=192.168.10.100 cidr_netmask=24 \
  op monitor interval=30s

# 配置Nginx服务资源
pcs resource create WebServer systemd:nginx \
  op monitor interval=20s \
  op start timeout=40s \
  op stop timeout=30s

# 设置资源启动顺序和共置约束
pcs constraint colocation add WebServer with VirtualIP INFINITY
pcs constraint order VirtualIP then WebServer

default-resource-stickiness=100这个参数容易被忽略但至关重要。默认值为0意味着故障恢复后资源会自动迁回原节点，这在生产环境中是危险的——网络抖动可能导致资源在节点间反复迁移。设为100后，资源只在当前节点故障时才迁移。

服务器故障排查：心跳丢失的根因分析

高可用集群最棘手的故障是”误切换”——心跳正常但服务被迁移了，或者心跳丢失但没触发切换。诊断步骤：

场景1：节点被意外标记为offline

# 查看Corosync心跳状态
corosync-cfgtool -s

# 查看集群成员状态
pcs status nodes

# 查看Corosync日志
journalctl -u corosync --since "10 minutes ago" | grep -i "lost|error|token"

常见根因：心跳网络MTU不匹配、交换机端口STP协商延迟、knet加密握手超时。排查时用tcpdump抓心跳包：

tcpdump -i eth1 -nn port 5405 -c 100

场景2：资源切换失败或卡在Stopping状态

# 查看资源详细状态
pcs status resources --full
# 清理失败状态
pcs resource cleanup WebServer
# 强制重启资源
pcs resource restart WebServer

资源卡住多是因为stop操作超时。检查systemd:nginx的stop timeout是否配置过短——Nginx有长连接时graceful shutdown可能需要30秒以上。

算力资源规划：集群规模与资源配比

服务器高可用集群的算力资源规划核心原则：备节点必须能独立承载全部业务负载。常见错误是备节点配了缩水配置，切换后撑不住流量又挂了。

资源配比建议：

• CPU：备节点至少达到主节点80%的算力
• 内存：备节点与主节点完全一致
• 磁盘IO：共享存储方案下不需要额外考虑；DRBD方案下备节点磁盘性能不低于主节点
• 网络带宽：备节点出口带宽与主节点一致

成本优化方向：冷备场景下备节点可以运行低优先级批处理任务，故障时自动驱逐批处理任务、接管核心服务。Pacemaker支持资源优先级配置：

# 批处理任务优先级低于核心服务
pcs resource meta BatchJob resource-stickiness=0
pcs resource meta WebServer resource-stickiness=100

服务器安全加固：集群通信加密与访问控制

高可用集群的安全加固需要关注三个层面：

通信加密：Corosync knet传输层已经内置AES256加密。确认配置生效：

corosync-cfgtool -k
# 应输出：Knet compression: zlib, crypto: aes256-sha256

pcs访问控制：限制pcs命令的执行权限，禁止非root用户操作集群：

# 配置PCS ACL
pcs acl enable
pcs acl role create ClusterAdmin description="Cluster administrator"
pcs acl role add permissions ClusterAdmin read write
pcs acl user create hacluster ClusterAdmin

STONITH配置：生产环境必须启用STONITH（Shoot The Other Node In The Head），防止脑裂时两个节点同时写共享存储导致数据损坏。推荐使用IPMI fence agent：

pcs stonith create ipmi-fence-node1 fence_ipmilan \
  ipaddr=192.168.10.11 login=root passwd=ipmi_password \
  pcmk_hostlist=node1 op monitor interval=60s
pcs stonith create ipmi-fence-node2 fence_ipmilan \
  ipaddr=192.168.10.12 login=root passwd=ipmi_password \
  pcmk_hostlist=node2 op monitor interval=60s
pcs property set stonith-enabled=true

STONITH的工作逻辑：当Pacemaker判定某节点故障后，先通过IPMI强制关机/重启该节点，确认其彻底离线后，再在健康节点上启动资源。这避免了”僵尸节点”持续写入共享存储的风险。