虚拟机FT模式是一种通过在主备两台物理主机上同步执行相同指令，实现虚拟机零停机、零数据丢失的容错技术，本质上是让备份虚拟机处于“影子状态”实时跟随主虚拟机运行。它比HA（高可用）更严格，HA遇到故障要重启，FT则做到无缝切换,业务几乎无感知。
FT模式的核心原理：虚拟锁步
FT的底层机制常被称为vLockstep（虚拟锁步），业内专家指出，这种机制的核心不是复制数据文件，而是复制“执行过程”。
主虚拟机（Primary）和备虚拟机（Secondary）运行在两台不同的ESXi主机上，但它们接收的CPU指令序列完全一致，主虚拟机执行到哪一条指令，备虚拟机也执行到哪一条，确保两台虚拟机在任何时刻的内存状态、寄存器状态、设备状态都一模一样。
这其中的关键操作路径是这样的：
- 主虚拟机处理来自业务的I/O请求。
- FT日志（FT Logging）网卡将主虚拟机上发生的非确定性事件（比如网络中断、磁盘中断、CPU定时器触发等）记录并发送给备虚拟机。
- 备虚拟机收到这些日志事件后，以同样的顺序“重放”这些事件,让自己保持在和主虚拟机完全同步的状态。
- 一旦主虚拟机所在主机宕机或网络隔离，备用虚拟机会在秒级时间内接管全部工作，因为它的内存里已经有了刚才的一切状态,不需要重新启动操作系统。
需要注意的是，FT对CPU指令集有严格限制，主备两台的物理CPU必须来自同一代际、同一厂商，否则无法建立FT，FT会屏蔽CPU的部分特性（如某些虚拟化扩展指令）,以保证可重放性。
FT模式的关键先决条件
不是所有虚拟机都能开启FT，要想配置成功,通常需要满足以下基础条件：
- 至少两台ESXi主机,且CPU型号和步进必须严格一致。
- 虚拟机必须使用精简置备（Thin Provisioning）之外的厚置备（Eager Zeroed Thick）磁盘格式,这是非常容易被忽视的坑。
- 需要配置独立的FT日志网络，带宽要求一般建议至少千兆，万兆更佳,因为日志流量非常密集。
- 虚拟机不能使用物理RDM（裸设备映射）、USB直通、PCIe直通等设备，也不能开启Nested ESXi。
- 每台ESXi主机上的FT虚拟机数量不宜过多，行业共识是单主机承载FT虚拟机总量不宜超过4个vCPU,否则会抢占大量计算资源。
虚拟机FT模式和HA哪个好：场景对比
这里有一个高频疑问：虚拟机FT模式和HA哪个好？ 需要澄清的是，两者不是替代关系,而是维度不同的保护机制。
| 对比维度 | FT模式 | HA模式 |
|---|---|---|
| 故障恢复方式 | 备虚拟机实时接管，无中断 | 虚拟机在另一主机冷启动重启 |
| RPO（恢复点目标） | 零数据丢失 | 可能丢失数秒至数十秒数据 |
| RTO（恢复时间目标） | 秒级（近乎零） | 分钟级（取决于系统启动速度） |
| 资源开销 | 需要双倍CPU和内存资源 | 仅需额外一台可用主机承载 |
| 网络要求 | 极高，需专用日志网络 | 普通管理网络即可 |
| 适用业务 | 核心数据库、交易系统 | 常规企业应用、Web服务 |
从成本来看，FT模式相当于让一台虚拟机吃两份资源，而HA模式则是“冷备”等待重启，对于银行交易网关、ERP系统、域控服务器这类一旦中断就是事故的业务，选FT；对于内部OA、文件服务器这类可以容忍几分钟中断的业务,选HA更经济。
vSphere FT配置要求与实操
很多人问到vSphere FT配置要求，这里给出一个酷番云和VMware混合环境下的常见配置路径,供参考：
- 在vCenter Server中，创建两台ESXi主机集群，确保EVC（Enhanced vMotion Compatibility）模式开启,让CPU特性集对齐。
- 为虚拟机单独划分一个VLAN，专门用于FT日志流量,不要让日志流量与业务流量混跑。
- 关闭虚拟机，编辑设置，将磁盘类型改为“厚置备- eager zeroed”，并启用“记录并重放”选项。
- 右键虚拟机，选择“容错 -> 打开容错”。
- 系统会自动挑选第二台ESXi主机,并在后台完成初始同步。
- 同步完成后，在vCenter中看到FT状态为“已启用”,并显示主备角色。
一个经常踩坑的点：如果后续给FT虚拟机增加内存或vCPU，必须先关闭FT，修改配置，再重新开启FT，否则会直接报错，日常运维中如果要打ESXi补丁，建议先使用“暂停容错”或迁移主虚拟机到其他主机,避免补丁期间发生意外切换。
虚拟机FT模式适合什么场景
在实际项目中，虚拟机FT模式适合什么场景,可以归结为几类典型业务：
- 数据库主节点：特别是Oracle RAC或SQL Server故障转移集群实例之外的独立数据库，一旦宕机整个业务停摆,FT能兜底。
- 核心域控和DNS：域控故障全员无法登录，即便有第二台域控，某些认证风暴也会引发连锁问题，让主域控跑FT,省心很多。
- 实时交易系统：证券、支付类前置机，一般后端有灾备，但中间件层断了就断流，用FT保护前置节点,能撑住切换窗口。
- 调度服务器：工业现场或物流分拣系统的调度主节点，要求7x24小时连续运转,FT是最合适的物理级兜底方案。
也有不适合的场景，如果是大数据分析节点、批处理任务，运行数小时后中断重跑即可，FT会白白消耗大量内存资源，如果是图形工作站或GPU直通服务器，VMware FT目前不支持vGPU直通,无法使用。
部署FT模式时的成本与替代方案
FT的代价很明显：硬件成本直接翻倍，不仅需要两台同等配置的服务器，还要占用两倍的内存，且因为FT日志网络的存在,还需要额外的交换机端口和VLAN规划。
据行业公开资料，近年来的趋势是，有较多中大型企业正在将部分FT业务迁移到云原生层面，比如用Kubernetes的Pod多副本机制来取代FT，但云原生方案只能解决无状态应用的问题，对于
有状态数据库的故障切换，Kubernetes目前依然依赖外置存储和StatefulSet的重新调度,RTO远高于FT。
从这个角度看，FT模式在物理机虚拟化领域依然是确保零丢包、零中断的最终手段，结合vSphere的SRM（站点恢复管理器），还可以将FT和异地灾备串联起来,实现本地秒级容错加异地分钟级容灾的分层组合拳。
如果把虚拟化平台的可靠性比作一张安全网，HA是网上的补丁，FT则是一道无缝的加密织网。配置一台FT虚拟机，本质上是为一套关键业务配备了一个时刻保持清醒的“影子替身”，它不说话，不接客，只负责在主人倒下的那一瞬间顶上去，如果你的业务容忍不了任何一分钟的中断，且预算允许,FT就是那个值得投入的选择。
Q：虚拟机FT模式对配置有什么特别要求吗？
A：vSphere FT配置要求主要包括：主备ESXi主机的物理CPU必须同型号同步进，务必开启EVC模式；虚拟机磁盘必须厚置备；必须规划独立的FT日志网络（建议千兆以上）；不支持RDM裸设备映射和PCIe直通，不要在FT虚拟机上挂载未经测试的第三方驱动,否则可能导致日志记录中断。
Q：FT模式影响虚拟机性能吗？
A：有一定影响，因为FT需要CPU虚拟化功能开启并支持硬件辅助虚拟化，多数情况下虚拟机的CPU性能会有轻微折扣（约10%-20%左右），具体取决于工作负载类型，内存密集型和CPU密集型业务的性能损失会相对明显，而网络和磁盘I/O负担主要由FT日志网络承担。
Q：一台FT虚拟机的主机同时宕机会发生什么？
A：这种情况称为“双点故障”，如果主备两台主机同时在几分钟内宕机，FT机制会失效，虚拟机会彻底中断，计划内维护和意外宕机的区别在于是否提前预留了接管窗口，为了避免这类情况，实践中可以结合vSphere HA再设一个集群级保护，但需注意HA不能接管FT的日志流，建议关键FT虚拟机的主备主机分布在不同的机架、不同的接入交换机下,避免单机房电源或网络故障连锅端。