thor雷神项目VMware FT解析主备份复制如何实现容错【免费下载链接】thor项目地址: https://gitcode.com/gh_mirrors/thor3/thorVMware FTFault Tolerance容错是分布式系统课程 MIT 6.824 中最经典的论文之一它用主备份复制Primary-Backup Replication在虚拟机层面实现了透明容错即使主服务器整机崩溃服务也能无缝切换到备份机器客户端几乎无感知。thor 雷神项目完整翻译了这门课程的字幕与讲稿本文就基于 Lec4-3.zh.txt、Lec4-4.zh.txt 等翻译资料用最通俗的语言拆解 VMware FT 的主备份复制到底是如何实现容错的。为什么需要主备份复制从单机故障说起在分布式系统里硬件故障是常态电源被拔、内存损坏、网线松动……一台服务器随时可能说走就走。想要继续稳定提供服务最朴素的思路就是复制Replication——准备一台一模一样的备用机器一旦主机器挂掉备用机器立刻顶上。课程开篇 primary_backup_replication.en.srt 首先区分了停止-失败Fail-Stop模型机器出问题时只是停止执行而不会给出错误结果。VMware FT 要对抗的正是这种故障而它的武器就是主备份复制。有意思的是大多数系统比如 GFS都在应用层面做复制只同步应用程序关心的数据块。而 VMware FT 走了一条完全不同的路——它在机器级别复制连内存、寄存器、CPU 状态都保持一致因此它根本不关心你跑的是什么软件任何操作系统、任何应用都能直接获得容错能力。VMware FT 的核心思想让两台虚拟机长得一模一样VMware FT 的架构可以画成下面这张图客户端 ──请求──▶ ┌─────────────────────┐ │ 物理机 A主 │ │ ┌─────────────────┐ │──日志通道──▶ ┌─────────────────────┐ │ │ 主虚拟机 │ │ │ 物理机 B备份 │ │ │ 内存寄存器CPU │ │ │ ┌─────────────────┐ │ │ └─────────────────┘ │ │ │ 备份虚拟机 │ │ │ VMM 虚拟机监视器 │ │ │ 内存寄存器CPU │ │ └─────────────────────┘ │ └─────────────────┘ │ │ VMM 虚拟机监视器 │ └─────────────────────┘两个物理机上各跑一台内容完全相同的虚拟机分别称为主虚拟机Primary和备份虚拟机Backup。中间通过一条高速网络日志通道连接。关键点在于两台虚拟机执行完全相同的指令序列内存状态始终一致。如果主节点崩溃备份节点就顶替它继续运行——这就是主备份复制实现容错的基本盘。输入日志通道主备份复制同步的关键机制那么问题来了两台机器如何保持同步答案是日志通道Logging Channel。课程讲稿 Lec4-3.zh.txt 详细描述了整个流程客户端发送数据包给主虚拟机数据包到达产生中断虚拟机监视器VMM拦截到这个输入VMM 做两件事把中断模拟给主虚拟机处理同时把数据包通过网络转发给备份虚拟机备份虚拟机收到后也在完全相同的指令位置注入中断两台虚拟机基于相同输入、执行相同指令状态自然保持一致。这台服务唯一的输入输出方式就是网络数据包所以输入事件 数据包内容 中断时序。只要把这些输入按顺序喂给两台虚拟机它们就能像双胞胎一样同步演化。主备份复制如何应对非确定性难题如果一切都确定主备份复制就太简单了。但现实中存在大量**非确定性Non-determinism**操作会让两台机器分叉随机数生成指令主节点算出的随机数备份节点必须得到同一个值读取时钟/当前时间的指令不同时刻执行结果不同网络中断的到达时序中断插在哪条指令之间执行直接影响结果多核并发两个核抢锁的顺序不可预测这是论文直接禁止的场景论文假设单核。解决方案是备份节点遇到这类指令时不真正执行而是截获它、等待日志通道上传来的标准答案直接用主节点产生的结果。这样即使是非确定性操作两台机器也能保持一致。细节可对照 Lec4-4.zh.txt 中关于中断时序与指令执行次序的讨论。故障切换备份节点如何接管服务当主节点挂掉VMware FT 的故障切换Failover流程非常清晰备份节点的 VMM 发现超过一秒没收到日志通道数据判定主节点已死备份节点停止等待输入事件开始自由执行VMM 修改网络配置把原主节点的网卡身份如 48 位 Ethernet ID收归自己对外声明我才是这个 IP 的主人之后的客户端请求全部路由到备份节点服务无缝继续。反过来如果备份节点先挂主节点只需停止发送日志、退化为单机运行即可。这套切换机制在 primary_backup_replication.en.srt 的后半段有完整讲解。主备份复制的局限了解容错方案的代价VMware FT 用简单粗暴换来了通用性但也必须接受代价局限说明性能开销大每条输入都要经日志通道复制主备份都要执行全部指令禁止多核多核并发会引入不可复现的执行顺序论文直接排除该场景依赖网络日志通道本身要可靠且主备间延迟影响吞吐效率低于应用级复制相比 GFS 这类只复制关键数据的方案机器级复制成本高得多这也解释了为什么现实中大多数系统选择应用级复制——性价比更高。理解 VMware FT 的取舍才能真正理解容错系统设计的本质。在雷神项目中如何系统学习 VMware FTthor 雷神项目为 MIT 6.824 提供了高质量的中文翻译建议按以下顺序学习先看 Lec4.en.txt 了解第四讲整体脉络精读 Lec4-3.zh.txt 掌握架构与主备份思想研读 Lec4-4.zh.txt 理解非确定性事件与日志通道配合 primary_backup_replication.en.srt 的英文原声校对细节遇到术语混淆时查阅 glossary.md 术语对照表如 Fault Tolerance→容错、Replication→复制。总结VMware FT 用主备份复制实现了系统级的透明容错两台虚拟机通过日志通道同步输入事件用确定性重放化解非确定性难题靠故障切换保证服务不中断。它的思路——让两台机器执行完全相同的指令——虽然简单却深刻揭示了容错系统的核心权衡。想在实战层面吃透它不妨从雷神项目的中文讲稿开始一步步走进分布式容错的精彩世界。【免费下载链接】thor项目地址: https://gitcode.com/gh_mirrors/thor3/thor创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考