VMware_FT_FAQ_Chinese.md

VMware FT FAQ

---

• 问题：介绍中说物理机服务器上保证确定性的执行比在虚拟机上难。为什么会这样？
  • 回答：在虚拟机上确保确定性简单点是因为 hypervisor 模拟并控制了硬件的很多可能会再主备之间执行有差异的方面，例如中断传递的精确时间
• 问题：什么是 hypervisor？
  • 回答：一个 hypervisor 是虚拟机系统的一部分，跟虚拟机监视器(VMM)一样。hypervisor 模拟一台计算机，和在模拟计算机内执行的客户操作系统(和应用)。客户经常运行的模拟器称为虚拟机。在本论文中，主备是运行在虚拟机中的客户，FT 是实现了每个虚拟机的hypervisor 的一部分
• 问题：GFS 和 VMware FT 都提供了容错。我们应该怎么考虑什么时候一个或者另外一个更好？
  • 回答：FT 复制计算，你可以用它来给任何已有的服务器透明地增加容错。FT 提供相当严格的一致性，对服务器和客户端是透明的。例如，你可能使用 FT 来使一个现有的邮件服务器容错。相反的，GFS只提供存储的容错。因为 GFS 是专门用于特定的简单服务(存储)，它的复制比 FT 更高效。例如，GFS 不需要在所有副本上完全相同的指令处导致中断。GFS 通常仅仅是一个实现完整的容错服务的大系统的一部分。例如，VMware FT 自己依赖一个由主备共享的容错存储服务(图1中的共享磁盘)，这你就可以使用一些像 GFS 的来实现(虽然在细节上 GFS 不是对 FT 合适的)
• 问题：3.4 章节中的弹跳缓冲是怎么帮助避免竞态的？
  • 回答：这个问题当一个网络包或者请求的磁盘块到达主机并且需要拷贝到主机的内存的时候会出现。没有 FT，相关硬件在软件执行的同时拷贝数据到内存。客户端指令可以在 DMA 过程中读到内存；取决于精确时间，客户端可能看到也可能看不到 DMA 的数据(这就是竞态)。如果主备同时这样操作就麻烦了，但是由于细微的时序差异，一个在 DMA 之后读取，而另一个在之前读取。这样它们会有差异
    FT 通过在主备还在执行的时候不拷贝进客户端内存来避免这个问题。FT 首先将网络包或者磁盘块考进一个私有的主机无法访问的“弹跳缓冲”。当第一步复制完成了，FT 的 hypervisor 中断不在执行的主机。FT 记录下中断主机的点(就跟任何中断一样)。然后 FT 将弹跳缓冲拷贝进主机内存，之后再允许主机继续执行。FT 通过日志通道发送数据给备机。备机的 FT 在备机不在执行的时候使用和主机中断相同的指令中断备机，然后恢复备机
    效果就是网络包或者磁盘块同时出现在主机和备机，所以不管它们何时读取数据，都看到一样的数据
• 问题：什么是共享存储中的“检查并设置”操作？
  • 回答：系统使用了一个网络磁盘服务器，通过主备共享(图1中的共享磁盘)。网络磁盘服务器拥有一个“检查并设置”服务。服务维护一个初始化为 false 的标志。如果主机或者备机认为对方已经宕机，因为需要自己去接管，它首先给磁盘服务器发送一个检查并设置的操作。服务操作大致跟下面代码相同：

    test-and-set() {
    acquire_lock()
    if flag == true:
     release_lock()
     return false
    else:
    flag = true
    release_lock()
    return true
    }

    主机(或者备机)只有在检查并设置返回 true 才会接管(上线)。
    更高层次的观点就是，如果主备丢失对彼此的网络连接，我们只希望其中一个上线。危险就是，如果同时在线并且网络失败了，两者可能都上线了并且导致闹裂。如果只有主机或者备机中的一个才能和磁盘服务器通信，那么那个服务器就上线。但是如果都能磁盘服务器通信会怎么样呢？那网络服务器充当决胜者，检查并设计操作只对第一个调用的返回 true
• 问题：遵循输出规则会损失多少性能？
  • 回答：表2提供了一些数据。通过遵循输出规则，传输速率有下降，但不大
• 问题：如果应用程序调用随机数生成器会怎么样？不会在主要和备份上产生不同的结果并导致执行的差异吗？
  • 回答：主备会从他们的随机数生成器得到相同的数。所有随机性的资源都由 hypervisor 控制。例如，应用可能使用当前时间，或者一个硬件循环计数器，或者精确的中断时间作为随机性的资源。在所有这三种情况下，hypervisor 都会拦截主备上的相关指令并确保它们产生相同的数值
• 问题：创建者如何确定捕获了所有可能的非确定形式？
  • 回答：下面是我的猜测。作者所在的公司很多人理解 VM hypervisor，微处理器，客户机的内部细节，并且了解其中的很多陷阱。特别对于 VM-FT，作者利用之前项目的日志和重播支持(确定性重播),必须已经处理过非确定性的问题。我假设确定性重放的设计者进行了广泛的测试，并获得了 VM-FT 作者的非确定性来源的丰富经验
• 问题：如果主机在发送输出给外界之后立刻宕机了会发生什么？
  • 回答：备机可能会在接管之后重复发送，因此生成了两次。重复对于网络和磁盘 I/O 来说不是问题。如果输出是网络包，接收客户端的 TCP 软件会自动丢弃重复消息。如果输出事件是磁盘 I/O，磁盘I/O 幂等(两个写操作都将相同的数据写入相同位置，而且没有干扰的 I/O)
• 问题：3.4章节讨论了主机磁盘 I/O 十分出色当故障发生；它提到“相反，我们在备机 VM 接管的过程中发起挂起的 I/O”。挂起的 I/O 位置/存储在哪里，重发需要多久才能完成？
  • 回答：论文是讨论有日志条目表示 I/O 开始但是没有条目表示完成的磁盘 I/O。是在备机上必须重新开始的指令。当一个 I/O 完成，I/O 设备产生一个 I/O完成的中断。所以，如果日志中缺少了 I/O 完成中断指令，备机重启 I/O。如果在日志中有了 I/O 完成中断，就不需要重启 I/O
• 问题：这个系统的安全性如何？
  • 回答：作者假设主备遵循协议且不是恶意的(例如，一个攻击者没有对 hypervisors 让步)。系统无法处理拖鞋的 hypervisors。另外，hypervisor 可能可以防御恶意或错误的客户操作系统和应用程序
• 问题：仅解决故障停止的故障是否合理？其他还有什么类型的故障？
  • 回答：这是合理的，既然许多真实的故障实际是故障停止，例如许多网络和电力故障。要想比这个做的好需要处理似乎正常运行但实际上计算错误结果的计算机；在最坏的情况下，可能故障是恶意攻击的结果。这种更大类的非故障停止故障通常被称为“拜占庭”。这里有方法应对拜占庭故障，我们会在课程最后遇到，但是6.824的绝大数是故障停止的故障