别再为KVM虚拟机宕机发愁了！手把手教你用Pacemaker+Corosync搭建双机热备集群（CentOS 8实战）

KVM高可用实战从零构建PacemakerCorosync双机热备集群当关键业务运行在KVM虚拟机上时宿主机宕机可能导致灾难性后果。我曾亲眼见证某企业因单点故障导致核心数据库中断8小时直接损失超百万。本文将手把手带你在CentOS 8上搭建生产级高可用集群用PacemakerCorosync实现虚拟机自动故障转移。不同于理论概述我们聚焦实战中那些手册不会告诉你的细节——比如如何绕过STONITH的坑、为什么你的集群总是分裂以及怎样用pcs命令真正掌控集群行为。1. 环境准备与避坑指南在开始敲命令前正确的环境配置能避免80%的后期问题。我们的目标架构很简单两台配置相同的CentOS 8服务器node1和node2通过专用心跳网络互联共享存储采用最普遍的NFS方案。硬件配置建议至少2个物理网卡1个用于业务网络1个用于心跳禁用所有节点的节能模式BIOS中关闭C-states/P-states确保NTP时间同步误差小于50ms# 在所有节点执行的基础配置 sudo dnf install -y chrony sudo systemctl enable --now chronyd sudo chronyc sources # 验证时间同步状态网络配置的魔鬼细节心跳网络必须使用独立物理接口这是我踩过的第一个坑。曾经将心跳流量与业务流量混在同一个bond接口上结果网络拥塞导致误判节点离线。正确的配置应该是# /etc/sysconfig/network-scripts/ifcfg-eth1 (心跳网卡) DEVICEeth1 TYPEEthernet BOOTPROTOnone ONBOOTyes IPADDR192.168.100.1 # node1用.1node2用.2 NETMASK255.255.255.0共享存储的三种方案对比方案类型配置复杂度性能表现适用场景NFSv4★★☆★★☆中小规模预算有限iSCSI★★★★★★☆需要块级访问DRBD★★★★★★★★无共享存储环境我们选择NFS仅因其实验成本最低生产环境建议考虑iSCSI或DRBD。挂载时务必添加这些参数# /etc/fstab 配置示例 nas01:/kvm_ha /mnt/nfs nfs rw,hard,timeo600,retrans2,_netdev 0 0关键提示hard挂载选项是必须的否则网络闪断可能导致虚拟机磁盘损坏。_netdev确保网络就绪后才挂载。2. 集群软件安装与初始化现在进入核心环节——安装集群套件。CentOS 8的AppStream仓库提供了最新稳定版软件包sudo dnf module install -y pcs sudo dnf install -y pacemaker corosync fence-agents-all为什么需要fence-agents这是新手最常忽略的部分。没有STONITHShoot The Other Node In The Head的集群就像没有保险栓的枪——当网络分区时两个节点可能同时认为对方宕机而接管资源导致脑裂灾难。我们使用IPMI作为隔离设备# 查看IPMI设备是否就绪 sudo ipmitool lan print初始化集群的五个关键步骤设置hacluster用户密码所有节点相同echo mypassword | passwd --stdin hacluster启用并启动pcsd服务sudo systemctl enable --now pcsd认证节点在任一节点执行sudo pcs host auth node1 node2 -u hacluster -p mypassword创建集群并配置Corosyncsudo pcs cluster setup my_cluster \ --transport knet \ --link0 192.168.100.1 \ --link1 192.168.100.2 \ --rrpmode active \ node1 node2启动集群sudo pcs cluster start --all sudo pcs cluster enable --all验证集群状态时别被简单的Online提示迷惑。真正健康的集群应该这样检查sudo pcs status | grep -E Cluster|Current sudo corosync-cmapctl | grep members sudo pcs stonith show3. 配置虚拟机高可用假设我们已有名为prod_db的KVM虚拟机其磁盘存储在NFS共享的/mnt/nfs/prod_db.qcow2。现在要将其纳入集群管理。创建Pacemaker资源的完整流程首先定义VirtualDomain资源代理sudo pcs resource create vm_prod_db ocf:heartbeat:VirtualDomain \ config/etc/libvirt/qemu/prod_db.xml \ hypervisorqemu:///system \ migration_transportssh \ meta allow-migratetrue \ op start timeout120s \ op stop timeout120s \ op monitor interval30s添加关联的NFS挂载点资源sudo pcs resource create nfs_mount Filesystem \ devicenas01:/kvm_ha \ directory/mnt/nfs \ fstypenfs \ op monitor interval60s设置资源约束sudo pcs constraint colocation add vm_prod_db with nfs_mount INFINITY sudo pcs constraint order nfs_mount then vm_prod_db故障转移测试的三种方法测试类型执行命令预期结果优雅关机pcs cluster stop node1VM在node2自动启动模拟崩溃echo c /proc/sysrq-trigger30秒内完成转移网络隔离iptables -A INPUT -s node2 -j DROP触发STONITH隔离node1重要提醒永远先在测试环境验证故障转移我曾见过因未正确配置STONITH导致两个节点同时启动VM造成数据库损坏。4. 生产环境调优与监控基础集群搭建只是开始要让其真正可靠还需要以下优化Corosync关键参数调整# /etc/corosync/corosync.conf 的knet配置段 knet { transport: udp link_mode: passive link_priority: 10 link0 { linknumber: 0 mtu: 1400 ping_interval: 500 ping_precision: 100 ping_timeout: 1500 } }Pacemaker资源监控增强sudo pcs resource op add vm_prod_db monitor interval10s timeout30s \ on-failrestart必须配置的警报策略集群节点状态变化资源故障重启事件STONITH操作触发记录脑裂风险警告可以用以下命令获取集群事件日志sudo pcs status --full | grep -A 10 Failed Actions性能基准测试方法# 测量故障转移时间 time pcs cluster stop node1 \ while ! virsh list --all | grep prod_db; do sleep 1; done在我的测试环境中经过优化的配置可以实现节点故障检测时间5秒虚拟机自动启动时间15秒完整服务恢复时间30秒记住这些数字会随虚拟机磁盘大小和内存占用而变化。一个加载了200GB数据的MySQL实例显然比空转的测试VM需要更长的启动时间。