虚拟机中的HA（高可用）核心原理就是“心跳检测+故障转移”：主备虚拟机通过心跳线互相监视状态，一旦主节点异常，备用节点自动接管资源并继续提供服务。这套机制在物理服务器时代已经成熟，到了虚拟化环境里，由于多了VMware vSphere、KVM、Hyper-V这一层抽象，HA的实现方式和排查难度都发生了变化，接下来从原理、配置步骤、方案选型三个维度拆解，重点说清“虚拟机高可用原理是什么”和“怎么落地”。
虚拟机高可用原理是什么？心跳、脑裂与Fencing机制
心跳检测：HA的第一道防线
虚拟机高可用原理的核心是心跳（Heartbeat），主备节点之间通过专用网络定期发送“我活着”的信号，频率通常在1秒到5秒一次，如果备用节点连续多次没有收到主节点的心跳包，就会判定主节点故障，触发切换流程，这里的判定阈值很关键设得太短容易误判，设得太长会导致业务中断时间拉长，行业共识认为，生产环境推荐连续丢失3次心跳再触发切换,既兼顾灵敏度又避免网络抖动造成误杀。
脑裂问题：HA最大的坑
当主备节点之间的心跳网络完全断开，但两个节点都还在运行，就会发生脑裂（Split-Brain），此时两个节点都认为自己是主节点，同时争抢同一份共享存储的写入权限，轻则数据损坏，重则整个集群瘫痪，为了解决脑裂，HA机制引入了仲裁机制（Quorum）和隔离机制（Fencing），仲裁需要多数派投票，若集群只有两个节点，则必须引入第三个仲裁节点或仲裁盘；Fencing则是在确定故障后，直接强制断电或隔离故障节点,确保它无法继续访问共享资源。
存储层的高可用：共享存储是前提
多数虚拟化HA方案都要求共享存储（如FC SAN、iSCSI、NFS），因为虚拟机切换后，新节点必须能挂载同一份虚拟机磁盘文件才能恢复运行，没有共享存储的话，数据同步就成了另一个大问题，那属于容灾（DR）范畴，复杂度更高，对于预算有限的场景，可以考虑使用分布式存储（如Ceph、vSAN）来替代传统SAN,但要注意性能损耗和网络带宽要求。
虚拟机高可用怎么配置？两种主流方案对比
虚拟机高可用配置步骤因方案而异，但总体分为两种流派：依赖虚拟化平台自带功能 和
在虚拟机内部自建集群。
| 对比维度 | 平台自带HA（如vSphere HA） | 自建集群（Keepalived/Pacemaker） |
|---|---|---|
| 故障检测范围 | 宿主机的宕机、网络分区 | 虚拟机内部进程、业务状态 |
| 切换粒度 | 整个虚拟机重启或迁移 | 虚拟IP漂移、单服务切换 |
| 对共享存储需求 | 必须 | 不一定需要 |
| 配置复杂度 | 低 | 较高 |
| 适用场景 | 虚拟化集群整体保障 | 对特定业务连续性要求极高 |
vSphere HA配置实操
在VMware vSphere环境中,配置HA的步骤如下：
- 准备至少两台ESXi主机,配置共享存储并创建标准交换机或分布式交换机。
- 在vCenter中创建集群（Cluster），开启vSphere HA功能。
- 设置主机监控状态：启用“主机监控”后，ESXi主机间会建立心跳网络，特别注意，vSphere HA默认使用管理网络做心跳，若管理网络故障会误判，建议配置额外的心跳网络（如专用VMkernel网卡）。
- 配置接入控制策略，预留足够资源，确保一台宿主机宕机后,其余主机能承载所有虚拟机。
- 设置虚拟机监控偏好：可选择“仅监控主机”或“监控虚拟机及主机”（后者会检测客户机系统心跳，若客户机卡死也会触发重启）。
虚拟机内自建Keepalived方案
对于不想依赖商业版虚拟化平台、或者跑在混合云环境里的虚拟机，用Keepalived做VIP漂移是常见做法,这里给出一套可直接操作的配置流程：
环境准备：两台CentOS 7虚拟机，IP分别为192.168.1.10（主）和192.168.1.11（备），虚拟IP为192.168.1.100。
主节点配置（/etc/keepalived/keepalived.conf）：
vrrp_instance VI_1 {
state MASTER
interface ens192
virtual_router_id 51
priority 150
advert_int 1
authentication {
auth_type PASS
auth_pass 123456
}
virtual_ipaddress {
192.168.1.100/24
}
}备节点配置：基本同上，仅将state改为BACKUP,priority改为100。
配置完成后分别重启keepalived服务，用ip addr show检查VIP是否已绑到主节点，然后模拟故障直接
systemctl stop keepalived，正常情况下VIP会自动漂移到备节点，业务无感知，这套方案对“虚拟机高可用哪个方案好”的问题给出的答案是：看你对检测粒度要求多高。
Keepalived虚拟机高可用配置步骤的关键细节
脚本检测业务健康状态
Keepalived默认只能检测自身进程是否存活，无法判断业务是否卡死,需要编写自定义脚本来检测业务端口或进程，
vrrp_script check_nginx {
script "/usr/local/scripts/check_nginx.sh"
interval 2
fall 2
rise 2
}check_nginx.sh内容：
#!/bin/bash
if systemctl is-active nginx &>/dev/null; then
exit 0
else
exit 1
fi然后在vrrp_instance中关联该脚本：
track_script {
check_nginx
}这样如果Nginx挂掉，Keepalived会主动降级，让备节点接管VIP，关键要点是：脚本执行时间不能超过interval设定值，否则会产生僵尸进程累积,导致检测失效。
组播与单播的问题
默认keepalived使用组播224.0.0.18实现节点间通信，但部分公有云环境禁用了组播,此时必须改用单播：
unicast_src_ip 192.168.1.10
unicast_peer {
192.168.1.11
}这一项在云服务器上配置HA时几乎必踩，很多用户配置半天发现两台机器互不感知,就是组播被云平台安全组挡掉了。
虚拟机HA需要多大配置？资源估算与成本平衡
虚拟机高可用多少钱、需要多大配置，这是企业选型时绕不开的问题，这里给一个经验参考：HA方案整体需要的资源是传统方案数的5到2倍,举例说明：
- 业务虚拟机日常使用4核8G，为了在物理节点故障后仍能保持性能,集群内每台宿主机必须有至少一台虚拟机的空余资源。
- 如果集群有三台宿主机，每台承载10台虚拟机，N+1冗余意味着单台主机资源至少预留约33%的容量。
- 更稳妥的做法是N+2甚至N+M冗余，但硬件成本随之上升，统计数据显示，多数中等规模企业选择N+1，因为云平台宕机概率较低,额外资源长期闲置也是一种浪费。
对于访问量波动大的业务，可以做出差异化成本方案：核心数据库用Pacemaker+共享存储，普通Web服务用Keepalived+双机热备，数据备份用异步复制，三个层级成本差异明显,整体费用可比全量SAN方案节省约三成。
虚拟机高可用使用场景典型故障排查
VIP漂移后业务无法访问
先看ARP缓存更新是否生效，VIP切换后，交换机或客户端的ARP表可能还指向旧MAC地址，执行arping -I ens192 -c 3 -U 192.168.1.100发送免费ARP更新,这在物理交换机环境尤其常见。
共享文件系统损坏
如果有多个节点同时挂载了同一块共享存储，且发生过脑裂，文件系统元数据可能损坏，此时先停机所有节点，用fsck从冗余副本修复，再去排查脑裂的根因。检查心跳网络是否独立于业务网络是预防复发的关键。
虚拟机高可用有哪些常见问题？
双节点集群必须要配置仲裁吗？
是的，双节点集群没有多数派可言，若不配置仲裁，心跳故障会导致两个节点都尝试接管服务，极端情况下会同时操作存储导致数据错乱，解决方式有两种：一是引入票票仲裁盘（一个小的共享LUN，谁拿到了仲裁权，谁才能接管业务）；二是在公有云上可以引入一个轻量级的第三方仲裁节点。
HA能防止虚拟机内部的操作系统蓝屏或业务进程崩溃吗？
平台自带HA一般不能，vSphere HA默认只检测主机层面的故障，虚拟机内的系统蓝屏不会触发切换；但若启用了“虚拟机监控”功能，VMware Tools心跳停止时会尝试重启虚拟机，Keepalived虽然能检测业务进程，但前提是你得把检测脚本写对检测脚本本身挂了，HA就形同虚设。
快照和备份能替代HA吗？
不能，快照和备份是为了应对逻辑错误（误删除、勒索病毒加密），它们解决的是“数据有时间点回放”的问题，恢复需要人工介入和分钟级以上的停机，而HA解决的是“物理或系统故障时自动恢复”的问题，恢复时间通常以秒为单位，生产环境理想状态是两者搭配使用：HA保障可用性,备份保障可恢复性。
虚拟机中的HA从来不是玄学，说穿了就是一台挂了另一台顶上的工程实现，但真正决定切换成不成功的，往往不是那几行配置，而是你有没有提前想清楚网络、存储和仲裁这三个环节，从Keepalived这样轻量级的方案起步，跑通一个最小化验证集群，再去理解vSphere HA和商业容灾软件的设计思路，你会发现自己已经抓住了高可用的核心骨架剩下的细节,交给需求和预算去打磨即可。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/760634.html
