本文源自于MIT6.824 Lec4的阅读笔记。原文是VMware vSphere 4.0的实现细节，DeepL Pro翻译 人工校正
5. PERFORMANCE EVALUATION
在本节中，我们对VMware FT在一些应用工作负载和网络基准方面的性能做了基本评估。对于这些结果，我们在相同的服务器上运行主虚拟机和备份虚拟机，每台服务器有8个英特尔至强2.8Ghz CPU和8G字节的内存。这些服务器通过一个10Gbit/s的交叉网络连接，尽管在所有情况下都会看到，使用的网络带宽远低于1Gbit/s。两台服务器通过一个标准的4Gbit/s光纤通道网络连接的EMC Clariion访问它们的共享虚拟磁盘。用于驱动一些工作负载的客户端通过1 Gbit/s网络与服务器相连。
我们在性能结果中评估的应用如下。SPECJbb2005是一个行业标准的Java应用基准，它对CPU和内存的要求很高，并且很少做IO。内核编译是一个运行Linux内核编译的工作负载。这个工作负载进行一些磁盘读写，并且由于许多编译过程的创建和销毁，CPU和MMU非常密集。Oracle Swingbench是一个工作负载，其中Oracle 11g数据库由Swingbench OLTP（在线交易处理）工作负载驱动。这个工作负载做了大量的磁盘和网络IO，并且有80个同步的数据库会话。MS-SQL DVD Store是一个工作负载，其中一个Microsoft SQL Server 2005数据库由DVD Store基准驱动，它有16个同步客户端。
5.1 Basic Performance Results
表1给出了基本性能结果。对于列出的每个应用，第二栏给出了在运行服务器工作负载的虚拟机上启用FT时该应用的性能与在同一虚拟机上未启用FT时的性能的比率。性能比的计算方法是，数值小于1表示FT工作负载的速度较慢。显然，在这些代表性工作负载上启用FT的开销低于10%。SPECJbb2005是完全计算的，没有空闲时间，但表现良好，因为它除了定时器中断外，非确定性事件极少。其他工作负载做磁盘IO，有一些空闲时间，所以一些FT的开销可能被FT虚拟机的空闲时间较少的事实所掩盖。然而，总的结论是，VMware FT能够以相当低的性能开销支持容错虚拟机。
在表格的第三列，我们给出了这些应用运行时在日志通道上发送的数据的平均带宽。对于这些应用来说，日志带宽是相当合理的，1 Gbit/s的网络可以轻松满足。事实上，低带宽要求表明，多个FT工作负载可以共享同一个1 Gbit/s网络，而不会对性能产生任何负面影响。
对于运行Linux和Windows等常见客户操作系统的虚拟机，我们发现，客户操作系统空闲时的典型日志带宽为0.5-1.5 Mbits/s。这个 "空闲 "带宽主要是记录定时器中断交付的结果。对于一个有活动工作负载的虚拟机来说，日志带宽被必须发送到备份的网络和磁盘输入所支配--接收的网络数据包和从磁盘上读取的磁盘块。因此，对于那些具有非常高的网络接收或磁盘读取带宽的应用，日志带宽可能远远高于表1中测量的带宽。对于这类应用，日志通道的带宽可能是一个瓶颈，特别是当日志通道还有其他用途时。
许多实际应用在日志通道上所需的带宽相对较低，这使得基于重放的容错对于使用非共享磁盘的长距离配置非常有吸引力。对于主用和备用可能相隔1-100公里的长距离配置，光纤可以很容易地支持100-1000Mbit/s的带宽，延迟小于10毫秒。对于表1中的应用，100-1000Mbit/s的带宽应该足以实现良好的性能。但是，请注意，主备之间的额外往返延迟可能会导致网络和磁盘输出延迟达20毫秒。长途配置只适合于那些客户能够容忍每个请求的额外延迟的应用。
对于两个磁盘密集型的应用，我们测量了在备份虚拟机上执行磁盘读取（如第4.2节所述）与通过日志通道发送磁盘读取数据的性能影响。对于Oracle Swingbench来说，在备份虚拟机上执行磁盘读取时，吞吐量降低了大约4%；对于MS-SQL DVD Store来说，吞吐量降低了大约1%。同时，Oracle Swingbench的日志带宽从12Mbits/sec下降到3Mbits/sec，而MS-SQL DVD Store的日志带宽从18Mbits/sec下降到8Mbits/sec。显然，对于具有更大磁盘读取带宽的应用来说，节省的带宽可能要大得多。如第4.2节所述，当磁盘读取在备份虚拟机上执行时，预计性能可能会差一些。然而，对于日志通道带宽有限的情况（例如，长距离配置），在备份虚拟机上执行磁盘读取可能是有用的。
5.2 Network Benchmarks
由于一些原因，网络基准测试对我们的系统来说是相当具有挑战性的。首先，高速网络会有非常高的中断率，这就要求以非常高的速率记录和重放异步事件。第二，以高速度接收数据包的基准将导致高速度的日志流量，因为所有这些数据包必须通过日志通道发送到备份。第三，发送数据包的基准将受制于输出规则，该规则将延迟网络数据包的发送，直到收到来自备份的适当确认。这种延迟将增加对客户端的测量延迟。这种延迟也可能减少客户端的网络带宽，因为网络协议（如TCP）可能不得不随着往返延迟的增加而降低网络传输速率。
表2给出了我们对标准netperf基准的一些测量结果。在所有这些测量中，客户虚拟机和主虚拟机通过1 Gbit/s网络连接。前两行给出了主用和备用主机通过1Gbit/s的记录通道连接时的发送和接收性能。第三行和第四行给出了主服务器和备份服务器通过10日志通道连接时的发送和接收性能，该通道不仅有更高的带宽，而且比1Gbit/s网络的延迟更低。作为一个粗略的衡量标准，1Gbit/s连接的管理程序之间的ping时间约为150微秒，而10Gbit/s连接的ping时间约为90微秒。
当未启用FT时，主虚拟机可以实现接近（940 Mbit/s）的1 Gbit/s线路速率的传输和接收。当为接收工作负载启用FT时，日志带宽非常大，因为所有进入的网络数据包都必须在日志通道上发送。因此，日志通道可能成为一个瓶颈，如1 Gbit/s日志网络的结果所示。对于10Gbit/s的日志网络，这种影响要小得多。当FT为传输工作负载启用时，传输数据包的数据不被记录，但网络中断仍然必须被记录。记录带宽要低得多，所以可实现的网络传输带宽要高于网络接收带宽。总的来说，我们看到FT可以在非常高的发送和接收速率下大大限制网络带宽，但高的绝对速率仍然可以实现。
6. RELATED WORK
Bressoud和Schneider[3]描述了通过完全包含在管理程序级别的软件来实现虚拟机的容错的最初想法。他们通过HP PA-RISC处理器的服务器原型，证明了使备份虚拟机与主虚拟机保持同步的可行性。然而，由于PA-RISC架构的限制，他们无法实现完全安全、隔离的虚拟机。而且，他们没有实现任何故障检测方法，也没有试图解决第3节中描述的任何实际问题。更重要的是，他们对其FT协议施加了一些不必要的限制。首先，他们强加了一个纪元的概念，即异步事件被延迟到一个设定的时间间隔结束。纪元的概念是不必要的--他们强加这个概念可能是因为他们无法足够有效地重放单个异步事件。其次，他们要求主虚拟机基本上停止执行，直到备份收到并确认所有先前的日志条目。然而，只有输出本身（如网络数据包）必须被延迟 - 主虚拟机本身可以继续执行。
Bressoud[4]描述了一个在操作系统（Unixware）中实现容错的系统，因此为运行在该操作系统上的所有应用程序提供了容错。系统调用接口成为必须确定地复制的操作集。这项工作与基于管理程序的工作有类似的限制和设计选择。
Napper等人[9]和Friedman和Kama[7]描述了容错的Java虚拟机的实现。他们遵循与我们类似的设计，在日志通道上发送关于输入和非确定性操作的信息。与Bressoud一样，他们似乎没有把重点放在检测故障和故障后重新建立容错上。此外，他们的实现仅限于为运行在Java虚拟机中的应用程序提供容错。这些系统试图处理多线程的Java应用程序的问题，但要求所有的数据都被锁正确保护，或者在访问共享内存时强制执行序列化。
Dunlap等人[6]描述了一个针对在准虚拟化系统上调试应用软件的确定性重放的实现。我们的工作支持在虚拟机内运行的任意操作系统，并为这些虚拟机实现容错支持，这需要更高水平的稳定性和性能。
Cully等人[5]描述了支持容错虚拟机的另一种方法及其在一个名为Remus的项目中的实现。通过这种方法，主虚拟机的状态在执行过程中被反复检查，并被发送到一个备份服务器，该服务器收集检查点信息。检查点必须非常频繁地执行（每秒多次），因为外部输出必须延迟到下一个检查点被发送和确认。这种方法的优点是，它同样适用于单处理器和多处理器的虚拟机。主要问题是，这种方法对网络带宽的要求非常高，以便在每个检查点发送内存状态的增量变化。在[5]中介绍的Remus的结果显示，当试图使用1Gbit/s的网络连接来传输内存状态的变化时，内核编译和SPECweb基准测试的速度降低了100%到225%。有一些优化措施可能有助于减少所需的网络带宽，但目前还不清楚是否可以用1Gbit/s的连接实现合理的性能。相比之下，我们基于确定性重放的方法可以实现不到10%的开销，在几个实际应用中，主主机和备份主机之间需要的带宽不到20Mbit/s。
7. CONCLUSION AND FUTURE WORK
我们在VMware vSphere中设计并实现了一个高效、完整的系统，为集群中服务器上运行的虚拟机提供了容错（FT）。我们的设计是基于使用VMware确定性重放，通过另一台主机上的备份虚拟机来复制主虚拟机的执行。如果运行主虚拟机的服务器发生故障，备份虚拟机会立即接管，不会出现中断或数据丢失。
总的来说，在商品硬件上的VMware FT下的容错虚拟机的性能是非常好的，对于一些典型的应用，显示出不到10%的开销。VMware FT的大部分性能成本来自于使用VMware确定性重放以保持主用和备用虚拟机同步的开销。因此，VMware FT的低开销来自于VMware确定性重放的效率。此外，保持主备同步所需的日志带宽通常相当小，通常低于20 Mbit/s。因为在大多数情况下，日志带宽相当小，所以实现主用和备用虚拟机相隔很远（1-100公里）的配置似乎是可行的。因此，VMware FT可用于同时保护整个站点发生故障的灾难的场景中。值得注意的是，日志流通常是相当可压缩的，简单的压缩技术可以在少量的额外CPU开销下大大降低日志带宽。
我们对VMware FT的研究结果表明，容错虚拟机的有效实施可以建立在确定性的重放之上。这样的系统可以以最小的开销为运行任何操作系统和应用程序的虚拟机透明地提供容错。然而，为了使容错虚拟机系统对客户有用，它还必须是强大的、易于使用的和高度自动化的。一个可用的系统除了虚拟机的复制执行外，还需要许多其他组件。特别是，VMware FT在发生故障后会自动恢复冗余，方法是在本地集群中找到一个合适的服务器，并在该服务器上创建一个新的备份虚拟机。通过解决所有必要的问题，我们已经展示了一个可用于客户数据中心的实际应用的系统。
通过确定性重放实现容错的一个权衡因素是，目前确定性重放只在单处理器虚拟机上有效实现。然而，单处理器虚拟机对于各种工作负载来说是绰绰有余的，尤其是在物理处理器不断增强的情况下。此外，许多工作负载可以通过使用许多单处理器虚拟机来扩展，而不是通过使用一个更大的多处理器虚拟机来扩大规模。多处理器虚拟机的高性能重放是一个活跃的研究领域，有可能通过微处理器的一些额外硬件支持实现。一个有趣的方向可能是扩展事务性内存模型以促进多处理器重放。
在未来，我们也有兴趣扩展我们的系统以处理部分硬件故障。所谓部分硬件故障，我们指的是服务器中部分功能或冗余的损失，但不会导致数据的损坏或丢失。一个例子是虚拟机的所有网络连接的损失，或者物理服务器中的冗余电源的损失。如果运行主虚拟机的服务器发生部分硬件故障，在许多情况下（但不是全部），立即故障转移到备份虚拟机是有利的。这样的故障切换可以立即恢复关键虚拟机的全部服务，并确保虚拟机迅速从可能不可靠的服务器上移开。
