1. 为什么你需要一个KVM高可用集群想象一下这个场景你负责维护公司里那台跑着核心数据库的虚拟机。它可能承载着订单系统或者客户数据。某个深夜这台虚拟机所在的物理服务器突然宕机了——也许是电源故障也许是内存条挂了。结果就是业务中断电话被打爆损失惨重。这种单点故障的噩梦是每个运维工程师都想避免的。这就是高可用High Availability, HA要解决的问题。简单说高可用就是让你的服务在遇到硬件或软件故障时能自动、快速地切换到备用资源上把停机时间降到最低甚至让用户毫无感知。对于KVM虚拟化环境实现高可用意味着当一台宿主机物理服务器挂掉时运行在上面的关键虚拟机VM能自动在另一台健康的宿主机上重新启动继续提供服务。那么怎么实现呢市面上方案不少但Pacemaker Corosync这套经典组合可以说是开源世界里最成熟、最灵活、也最“硬核”的选择。它不依赖于任何特定的云管理平台比如OpenStack直接在操作系统层面工作给你最底层的控制力。你可以把它理解为一个超级智能的“看门狗”和“调度员”组合Corosync负责时刻盯着集群里各个节点的“心跳”是否活着Pacemaker则负责管理所有资源比如虚拟机、IP地址、存储服务并在故障发生时做出决策指挥资源转移到健康节点上。我经历过从手动恢复切换到搭建自动化集群的整个过程实测下来这套方案虽然前期配置需要花些心思但一旦跑起来心里就踏实多了。接下来我就带你从零开始用两台最普通的物理服务器亲手搭建一个属于你自己的KVM高可用集群。我们会一步步走过环境准备、软件安装、集群配置、资源定义和故障测试过程中我会分享我踩过的坑和总结的最佳实践保证你跟着做就能成功。2. 实战前的环境与思想准备在动手敲命令之前有两件事比技术细节更重要一是理清架构二是准备好环境。磨刀不误砍柴工这一步做好了后面能省去无数麻烦。2.1 我们的目标架构长什么样我们这次要构建的是一个典型的两节点主动-被动Active-Passive高可用集群。假设我们有两台配置差不多的服务器分别叫kvm-node01和kvm-node02。共享存储是基石这是最关键的一点。两台服务器必须能访问到同一份虚拟机磁盘镜像文件。否则节点A挂了节点B启动虚拟机时找不到磁盘一切白搭。共享存储的实现方式有很多NFS最简单找一台服务器开个NFS共享目录两台KVM节点都挂载它。iSCSI性能更好可以将一个SAN存储或一台服务器上的LUN逻辑单元同时挂载给两个节点。分布式存储如Ceph更高级扩展性好但部署复杂些。DRBD在两台服务器间同步镜像块设备相当于网络RAID 1无需第三方存储服务器。 为了简化我们假设你已经配置好了一个NFS共享路径是192.168.1.100:/nfs_share/vm_disks并且两台KVM节点都已经将其挂载到了/mnt/nfs_vm目录下。你的虚拟机磁盘文件比如db_server.qcow2就放在这个目录里。网络规划强烈建议为集群心跳通信配置一个独立的网络比如用一根网线直连两台服务器的第二张网卡eth1IP地址设为10.0.0.1/24和10.0.0.2/24。这能避免业务网络流量干扰心跳防止误判。业务网络eth0则用于虚拟机对外通信。隔离机制Fencing/STONITH这是生产环境必须考虑的一环目的是防止“脑裂”Split-Brain。简单说就是当两个节点因为网络问题无法感知对方都认为自己是“主节点”并试图启动同一个虚拟机时会导致数据损坏。隔离机制就是通过硬件如IPMI、iDRAC或软件方法强制关闭被认定故障的节点。我们会在配置中涉及但鉴于测试环境可能没有带外管理我们会先配置一个简单的软件隔离代理作为演示生产环境请务必使用可靠的硬件隔离。2.2 基础环境配置清单在开始安装集群软件前请确保两台服务器满足以下条件。我会给出具体的检查和配置命令你最好逐条执行。系统与主机名我使用的是 CentOS 7 或 Rocky Linux 8其他RHEL系发行版也类似。确保主机名正确且固定。# 查看并设置主机名重启后生效 hostnamectl set-hostname kvm-node01 # 在第一台执行 hostnamectl set-hostname kvm-node02 # 在第二台执行 # 编辑 /etc/hosts 文件在两台服务器上做相同的配置 # 添加以下行将主机名解析到业务网络IP 192.168.1.101 kvm-node01 192.168.1.102 kvm-node02 # 如果配置了心跳网络也可以加上 10.0.0.1 kvm-node01-hb 10.0.0.2 kvm-node02-hb时间同步集群节点间时间必须高度一致否则日志和仲裁都会出问题。# 安装并启动 chronyd yum install -y chrony systemctl enable --now chronyd chronyc sources -v # 查看同步状态防火墙与SELinux我们需要开放集群通信所需的端口。最简单的方式是在测试环境暂时关闭防火墙和SELinux但生产环境建议精细配置。# 临时关闭防火墙重启失效 systemctl stop firewalld systemctl disable firewalld # 或开放必要端口推荐 firewall-cmd --permanent --add-servicehigh-availability firewall-cmd --reload # 设置SELinux为permissive模式重启生效 setenforce 0 sed -i s/^SELINUX.*/SELINUXpermissive/ /etc/selinux/configSSH互信方便后续使用pcs命令跨节点配置。在其中一个节点生成密钥并分发。ssh-keygen -t rsa # 一路回车 ssh-copy-id rootkvm-node01 ssh-copy-id rootkvm-node02完成后测试从kvm-node01ssh rootkvm-node02能否无密码登录。3. 安装与初始化集群核心软件基础环境搞定后我们就可以安装集群的“大脑”和“神经”了——也就是Pacemaker和Corosync。3.1 安装必要的软件包在两台服务器上执行相同的安装命令。除了核心组件我们还会安装pcs这是一个非常方便的命令行工具用于配置和管理Pacemaker/Corosync集群比直接编辑配置文件友好得多。# 对于 CentOS 7 / Rocky Linux 8 yum install -y pacemaker corosync pcs psmisc policycoreutils-python # 启动 pcsd 服务并设置开机自启这个服务用于节点间的认证和通信 systemctl enable --now pcsd.service安装完成后我们需要为pcs管理设置一个密码。这个密码用于集群节点间的认证。# 在两台节点上执行设置hacluster用户的密码集群内部通信使用 echo 你的密码 | passwd --stdin hacluster # 例如echo MySecureClusterPass123 | passwd --stdin hacluster3.2 创建并启动集群现在我们以其中一台节点比如kvm-node01作为配置点来创建整个集群。认证节点首先让pcs知道集群里有哪些节点并进行身份认证。# 在 kvm-node01 上执行 pcs host auth kvm-node01 kvm-node02 -u hacluster -p 你的密码 # 系统会提示输入本地hacluster用户的密码进行确认这个命令会在节点间交换证书建立信任关系。创建集群使用pcs cluster setup命令初始化集群。这里我们给集群起个名字叫my_kvm_cluster并指定节点列表。--force参数会覆盖已有的配置。pcs cluster setup my_kvm_cluster kvm-node01 kvm-node02 --force这个命令会自动生成 Corosync 的配置文件/etc/corosync/corosync.conf并分发到所有节点。你可以查看这个文件会发现它定义了集群名称、节点列表、心跳传输协议等。默认会使用多播multicast进行通信如果你的网络不支持多播可能需要配置单播ucast这个我们后面遇到问题再说。启用并启动集群服务# 启用集群服务使其开机自启 pcs cluster enable --all # 启动集群服务 pcs cluster start --all执行后Pacemaker 和 Corosync 服务会在两个节点上启动。验证集群状态这是令人兴奋的一步看看我们的集群是否成功组建。pcs status如果一切正常你会看到类似下面的输出显示两个节点都是Online并且集群资源管理器pacemaker已经启动。Cluster name: my_kvm_cluster Stack: corosync Current DC: kvm-node01 (version 2.0.5-9.el8_4.1-ba59be7122) - partition with quorum Last updated: Tue Oct 26 10:00:00 2023 Last change: Tue Oct 26 09:58:22 2023 by root via cibadmin on kvm-node01 2 nodes configured 0 resources configured Online: [ kvm-node01 kvm-node02 ] No resources看到Online: [ kvm-node01 kvm-node02 ]就成功了一半目前还没有配置任何资源虚拟机、IP等所以资源列表是空的。你还可以用pcs cluster status或corosync-cmapctl | grep members来查看更详细的心跳成员信息。4. 配置集群属性与隔离STONITH集群跑起来了但还处于“裸奔”状态。我们需要设置一些全局属性并配置至关重要的隔离设备才能让它真正可靠地工作。4.1 设置关键的集群属性Pacemaker 有很多默认行为我们需要调整几个以适应高可用虚拟机的场景。这些命令在任一节点执行即可配置会自动同步。# 禁用无关紧要的 quorum法定票数策略。对于两节点集群quorum通常无法达成需要超过半数节点在线即至少2票但只有2个节点一票对一票无法形成多数。我们更关心资源本身。 pcs property set stonith-enabledtrue # 注意我们先设为true但还没配置STONITH设备所以集群会报错。这是预期中的我们下一步就配置。 # 设置当资源故障时不自动尝试迁移回原来的节点。这可以避免资源在故障恢复后在节点间“飘来飘去”。 pcs property set default-resource-stickiness100 # 关闭资源平衡器避免集群因为一些无关紧要的原因比如节点负载轻微差异而移动我们的虚拟机。 pcs property set no-quorum-policyignore # 再次强调两节点集群忽略quorum是常见做法但必须配合可靠的STONITH否则脑裂风险极高。4.2 配置STONITH设备模拟环境与生产环境STONITHShoot The Other Node In The Head是集群的“保险丝”。对于测试环境如果没有IPMI/iDRAC等带外管理卡我们可以先配置一个“假”的隔离代理让集群逻辑上通过但实际不执行任何操作。生产环境绝对不要这样做测试环境使用“假”隔离pcs stonith create my-fence fence_xvm \ pcmk_host_listkvm-node01 kvm-node02 \ meta providesunfencingfence_xvm是一个特殊的代理通常用于Xen环境在这里我们只是用它来“欺骗”集群让它认为隔离设备已就位。配置后记得用pcs property set stonith-enabledtrue启用如果之前没启用的话。生产环境使用IPMI隔离示例 假设你的服务器IPMI地址是192.168.1.201和.202用户密码是admin/secret。# 为 kvm-node01 配置隔离设备目标是 kvm-node02 pcs stonith create fence-node01 fence_ipmilan \ ipaddr192.168.1.202 loginadmin passwdsecret \ lanplustrue pcmk_host_listkvm-node02 \ op monitor interval60s # 为 kvm-node02 配置隔离设备目标是 kvm-node01 pcs stonith create fence-node02 fence_ipmilan \ ipaddr192.168.1.201 loginadmin passwdsecret \ lanplustrue pcmk_host_listkvm-node01 \ op monitor interval60s配置完成后务必进行测试pcs stonith fence kvm-node02这条命令会尝试远程关闭kvm-node02的电源。执行前请确保虚拟机已迁移或关闭数据已保存配置好STONITH后再次检查状态pcs status应该能看到隔离资源并且集群告警会减少。5. 定义与管理高可用资源好了集群框架和安保措施都到位了现在该请出我们的主角——需要被保护的KVM虚拟机了。在Pacemaker里一切虚拟机、IP地址、文件系统、服务都被抽象为“资源”。5.1 创建虚拟IPVIP资源为了让客户端始终能访问到服务无论虚拟机在哪台物理机上运行我们需要一个“浮动”的IP地址即虚拟IPVIP。# 假设我们的业务网段是 192.168.1.0/24我们分配一个未被使用的IP 192.168.1.200 作为VIP pcs resource create ClusterVIP ocf:heartbeat:IPaddr2 \ ip192.168.1.200 cidr_netmask24 \ op monitor interval30socf:heartbeat:IPaddr2这是一个标准的资源代理Resource Agent, RA用于管理IP地址。ip和cidr_netmask定义了VIP的地址和子网掩码。op monitor interval30s每30秒检查一次这个IP资源是否健康。创建后用pcs status查看你会看到ClusterVIP资源被启动在其中一个节点上比如kvm-node01。尝试 ping 一下192.168.1.200应该是通的。5.2 创建共享文件系统资源我们的虚拟机磁盘在NFS共享上我们需要确保在启动虚拟机之前这个NFS目录已经被挂载到了正确的节点上。Pacemaker可以帮我们管理这个挂载点。# 假设NFS共享是 192.168.1.100:/nfs_share/vm_disks我们要挂载到 /mnt/nfs_vm pcs resource create NFShare ocf:heartbeat:Filesystem \ device192.168.1.100:/nfs_share/vm_disks \ directory/mnt/nfs_vm fstypenfs \ op monitor interval20s timeout40s \ op start timeout60s op stop timeout60s这个资源会确保/mnt/nfs_vm目录被NFS挂载。同样用pcs status确认它运行正常。5.3 创建KVM虚拟机资源核心步骤这是最关键的一步。我们需要告诉Pacemaker如何管理我们的KVM虚拟机。Pacemaker有一个专门的资源代理ocf:heartbeat:VirtualDomain它通过libvirt来管理虚拟机的生命周期。首先确保你的虚拟机已经在共享存储上创建好了并且没有在任一节点上自动启动即virsh autostart VM名称应该是禁用的。假设我们的虚拟机在libvirt中的名字是prod_db_vm。pcs resource create VM_prod_db ocf:heartbeat:VirtualDomain \ config/etc/libvirt/qemu/prod_db_vm.xml \ hypervisorqemu:///system \ migration_transportssh \ meta allow-migratetrue \ op monitor interval30s timeout30s \ op start timeout120s op stop timeout120sconfig指定虚拟机XML配置文件的位置。重要这个文件必须在两个节点上路径一致并且里面的磁盘路径指向共享存储如/mnt/nfs_vm/prod_db_vm.qcow2。hypervisor连接libvirt的URI。migration_transport和allow-migrate允许Pacemaker在必要时比如资源平衡或节点维护对虚拟机进行在线迁移Live Migration而不是简单的关闭、启动。op操作定义了监控、启动、停止的超时时间。启动虚拟机可能需要较长时间等待系统引导所以start timeout设得大一些。创建资源后Pacemaker会自动尝试启动这个虚拟机资源。使用pcs status和virsh list命令确认虚拟机已经在某个节点比如kvm-node01上运行起来了。5.4 用资源组和约束理顺启动顺序现在我们有三个资源VIP、NFS共享、VM。它们之间有依赖关系VM依赖NFS共享因为磁盘在上面VIP最好和VM在同一个节点这样客户端才能通过VIP访问到VM。我们需要用“约束Constraint”来告诉Pacemaker这些规则。一个更简单的方法是使用资源组Resource Group。组内的资源会按顺序启动按逆序停止并且总是运行在同一个节点上。# 创建一个资源组将VIP、NFS共享、VM按顺序放进去 pcs resource group add WebServiceGroup ClusterVIP NFShare VM_prod_db这条命令创建了一个名为WebServiceGroup的组并添加了三个资源添加的顺序就是启动顺序先启动ClusterVIP然后NFShare最后VM_prod_db。停止时则相反。它们会被绑定在一起在集群中作为一个整体进行故障转移。除了组内顺序我们可能还有其他约束。例如如果我们有另一个资源比如一个数据库服务希望它和VM运行在不同的节点以实现负载分担就可以使用“位置约束Location Constraint”或“反亲和性Anti-Affinity约束”。# 示例禁止两个资源运行在同一节点反亲和性 # pcs constraint colocation add VM_prod_db with AnotherResource -INFINITY不过在我们的简单双机热备场景中资源组已经足够清晰和方便了。6. 模拟故障与切换测试配置完成不是终点经过充分测试的方案才值得信赖。我们现在就来模拟几种常见的故障看看集群如何反应。6.1 测试1虚拟机进程意外终止这是比较轻微的故障。我们登录到运行虚拟机的节点比如kvm-node01手动杀死虚拟机进程。# 在 kvm-node01 上找到虚拟机的进程ID并杀死 virsh list # 假设虚拟机名字是 prod_db_vm virsh destroy prod_db_vm # 注意这是强制关闭相当于断电然后迅速在任意节点执行pcs status。你应该会看到Pacemaker监控到VM_prod_db资源失败failed。几秒后Pacemaker会尝试在当前节点重启该资源。如果重启失败或者我们设置了失败阈值它可能会决定将整个WebServiceGroup资源组迁移到另一个节点kvm-node02去启动。观察pcs status的输出看资源是否在另一个节点上变成Started。同时用virsh list在kvm-node02上检查虚拟机是否已启动。6.2 测试2宿主机节点崩溃模拟这是更严苛的测试模拟整台物理机宕机。我们可以在运行资源的节点上直接重启或关闭Pacemaker服务来模拟。# 在 kvm-node01 上执行 systemctl stop pacemaker # 或者更狠一点reboot然后观察kvm-node02上的情况Corosync 会检测到kvm-node01的心跳丢失。经过预定的时间默认几秒kvm-node01被标记为OFFLINE。由于我们配置了STONITH即使是假的集群会尝试隔离kvm-node01。在假隔离的情况下这一步会很快“完成”。然后Pacemaker 会开始计算资源的最佳位置。由于kvm-node01离线它会把WebServiceGroup分配到唯一在线的节点kvm-node02上。在kvm-node02上Pacemaker 会按顺序启动资源组先挂载NFS如果还没挂载然后启动虚拟机。使用pcs status和virsh list确认虚拟机已在kvm-node02上运行。同时尝试 ping 一下VIP192.168.1.200网络连通性应该很快恢复IP地址会漂移到kvm-node02的网卡上。注意如果虚拟机启动很慢比如要等待操作系统引导pcs status可能会显示资源处于starting状态一段时间这是正常的。你可以通过pcs resource debug-start VM_prod_db来手动触发启动并查看详细日志。6.3 测试3恢复与回切故障节点修复后我们希望它能重新加入集群。启动kvm-node01的pacemaker服务。# 在 kvm-node01 上执行 systemctl start pacemaker pcs cluster start kvm-node01节点会重新加入集群并变为Online状态。由于我们之前设置了default-resource-stickiness100粘性值资源会倾向于留在当前节点kvm-node02而不会自动漂移回去。这通常是我们期望的避免不必要的切换。如果你需要手动将资源移回原节点可以使用迁移命令pcs resource move WebServiceGroup kvm-node01这条命令会给资源在kvm-node01上添加一个临时的高粘性约束使其迁移过去。7. 生产环境进阶考量与避坑指南通过上面的步骤一个基本可用的KVM高可用集群就搭建完成了。但要想在生产环境稳稳落地还有一些细节和坑需要注意。7.1 监控与日志排查集群不能配置完就撒手不管必须纳入监控。集群状态监控最简单的是定期用pcs status做成Zabbix或Prometheus的监控项检查节点是否全部Online资源是否有failed。日志位置出问题时日志是你的第一手资料。Corosync 日志/var/log/cluster/corosync.logPacemaker 日志/var/log/pacemaker.log(旧版本可能在/var/log/pacemaker/pacemaker.log)pcs命令日志/var/log/pcsd.log系统日志journalctl -u pacemaker -u corosync -f可以实时跟踪。常见错误资源启动失败检查资源代理的路径、参数是否正确检查依赖条件是否满足如NFS是否可挂载查看pcs resource debug-start [资源名]的输出。脑裂警告如果没配置STONITH或STONITH失败日志中会出现脑裂警告。务必解决STONITH问题。网络分区心跳网络不稳定会导致节点互相认为对方离线。检查网络连接、交换机配置并考虑配置冗余心跳链路。7.2 性能调优与资源限制资源监控间隔op monitor interval不是越短越好。太频繁的检查会增加系统负载。对于虚拟机30-60秒的监控间隔通常是合理的。启动/停止超时op start/stop timeout要根据虚拟机的实际启动/关闭时间来设置。大型虚拟机启动可能需要2-3分钟设置过短会导致Pacemaker误判为失败。资源粘性Stickiness我们之前设置的default-resource-stickiness100可以防止资源在节点间“抖动”。你也可以为单个资源设置meta resource-stickiness200。迁移参数如果使用Live Migration需要确保节点间SSH免密互通并且网络带宽足够建议万兆。可以在虚拟机资源定义中调整migration_transport和migration_network等参数。7.3 备份与灾难恢复配置备份定期备份 Pacemaker 的集群信息库CIB。pcs cluster cib /path/to/backup/cib.xml。恢复时可以用pcs cluster cib-push /path/to/backup/cib.xml。虚拟机配置备份确保/etc/libvirt/qemu/目录下的虚拟机XML文件在所有节点同步。可以使用rsync或配置管理工具如Ansible来维护。灾难演练定期比如每季度执行一次完整的故障切换演练包括断电、断网等场景并记录切换时间和业务影响。这是验证HA有效性的唯一方法。7.4 与我踩过的坑共享存储的权限与锁这是我早期踩过的一个大坑。当两个节点同时挂载同一个NFS共享并尝试启动同一个虚拟机时可能会因为文件锁冲突导致启动失败。确保你的共享存储支持正确的锁机制NFSv4 比 v3 更好。或者更稳妥的方法是让Pacemaker管理的文件系统资源来负责挂载确保同一时间只有一个节点挂载了共享存储。我们之前创建的NFShare资源正是做了这件事。另一个坑是虚拟机磁盘格式。对于高可用环境强烈建议使用raw格式或qcow2格式并避免使用那些依赖本地主机缓存的高级特性如cachewriteback在某些情况下可能导致数据不一致。在虚拟机XML中使用相对简单的驱动配置往往更可靠。搭建这样一个集群从无到有看着虚拟机在服务器故障时自动“跳”到另一台服务器上继续奔跑那种成就感是实实在在的。它带来的不仅仅是技术的提升更是对业务连续性的坚实保障。希望这份详细的指南能帮你少走弯路顺利构建出属于自己的高可用KVM环境。记住多测试多监控你的集群就会越来越稳。