分布式系统论文精读3：容错虚拟机

The Design of a Practical System for Fault-Tolerant Virtual Machines

0 摘要

我们实现了一个提供容错虚拟机的商业企业级系统，该系统基于**通过在另一台服务器上的备份虚拟机来复制主虚拟机(VM)的执行的方法。**我们在VMware vSphere 4.0中设计了一个完整的系统，该系统易于使用，在商用服务器上运行，通常会使实际应用程序的性能降低不到10%。此外，对于几个实际应用程序，保持主和辅助VM同步执行所需的数据带宽不到20 Mbit/s，这允许在更长距离内实施容错。一个易于使用的商业系统在故障后自动恢复冗余，除了复制的VM执行之外，还需要许多额外的组件。我们设计并实施了这些额外的组件，并解决了在支持运行企业应用程序的VM时遇到的许多实际问题。在本文中，我们描述了我们的基本设计，讨论了替代设计选择和一些实现细节，并提供了微基准测试和实际应用的性能结果。

1介绍

实现容错服务器的一种常见方法是主/备份方法[1]，在主服务器发生故障时，总是可以使用备份服务器进行接管。 备份服务器的状态必须始终保持与主服务器几乎相同，以便在主服务器发生故障时，备份服务器可以立即接管，并且以这种方式将故障隐藏在外部客户机中，不会丢失任何数据。 在备份服务器上复制状态的一种方法是几乎连续地将主服务器的所有状态(包括CPU、内存和I/O设备)的更改发送到备份。 然而，发送此状态(内存中的特定更改)所需的带宽可能非常大。

（状态转移:State Transfer）

另一种可以使用更少带宽的复制服务器的方法有时被称为statemachine方法[13]。 其思想是将服务器建模为确定性状态机，这些状态机从相同的初始状态启动，并确保它们以相同的顺序接收相同的输入请求，从而保持同步。 由于大多数服务器或服务具有一些不确定的操作，因此必须使用额外的协调来确保主服务器和备份保持同步。 但是，保持主服务器和备份同步所需的额外信息量远远小于主服务器中正在更改的状态量(主要是内存更新)。

（复制状态机：Replicated State Machine）

实现协调以确保物理服务器[14]的确定性执行是困难的，特别是在处理器频率增加的情况下。 相反，运行在管理程序之上的虚拟机(VM)是实现状态机方法的优秀平台。 VM可以被认为是定义良好的状态机，其操作是被虚拟化的机器的操作(包括它的所有设备)。 与物理服务器一样，vm也有一些不确定的操作(例如读取一个时钟时间或发送一个中断)，因此必须将额外的信息发送到备份，以确保其保持同步。 由于系统管理程序完全控制VM的执行，包括所有输入的交付，所以系统管理程序能够捕获主VM上关于不确定性操作的所有必要信息，并在备份VM上正确地重播这些操作。

因此，状态机方法可以在普通硬件上为虚拟机实现，而不需要修改硬件，允许对最新的微处理器立即实现容错。 此外，状态机方法所需的低带宽允许对主服务器和备份进行更大的物理分离。 例如，复制的虚拟机可以在跨校园分布的物理机器上运行，这比在同一建筑物中运行的vm提供了更高的可靠性。

我们在VMware vSphere 4.0平台上使用主/备份的方式实现了容错vm，该平台能够高效运行完全虚拟化的x86虚拟机。 因为VMware vSphere实现了一个完整的x86虚拟机，所以我们可以自动为任何x86操作系统和应用程序提供容错能力。 允许我们记录主服务器的执行并确保备份以相同方式执行的基本技术称为确定性重放[15]。 VMware vSphere容错(FT)是基于确定性重放的，但是增加了必要的额外协议和功能来构建一个完整的容错系统。 除了提供硬件容错之外，我们的系统还通过在本地集群中任何可用的服务器上启动一个新的备份虚拟机，在出现故障后自动恢复冗余。 此时，确定性回放和VMware FT的生产版本都只支持单处理器vm。 记录和回放多处理器VM的执行仍然在进行中，存在严重的性能问题，因为对共享内存的几乎每次访问都可能是不确定的操作。

Bressoud和Schneider[3]描述了一个原型imple- HP PA-RISC平台容错vm的配置。

我们的方法是类似的，但是由于性能的原因，我们做了一些基本的改变，并研究了一些设计方案。 此外，我们必须在系统中设计和实现许多额外的组件，并处理许多实际问题，以构建一个完整的系统，该系统对于运行企业应用程序的客户来说是高效和可用的。 与讨论的大多数其他实际系统类似，我们只尝试处理故障停止故障[12]，即在故障服务器导致错误的外部可见操作之前可以检测到的服务器故障。

论文的其余部分组织如下。 首先，我们描述了我们的基本设计和详细的基本协议，这些协议确保在主VM失败后，如果备份VM接管了主VM，不会丢失任何数据。 然后，我们详细描述了构建一个健壮、完整和自动化的系统必须解决的许多实际问题。 我们还描述了实现容错vm时出现的几种设计选择，并讨论了这些选择中的权衡。 接下来，我们将给出一些基准测试和一些实际企业应用程序实现的性能结果。 最后，对相关工作进行了描述和总结。

2基本的FT的设计

图1显示了我们的系统的基本设置。 对于我们希望为其提供容错的给定VM(主VM)，我们在不同的物理服务器上运行备份VM，该服务器保持同步并与主虚拟机执行相同，只是有一点时间延迟。 我们说这两个vm是同步的。 VM的虚拟磁盘位于共享存储上(例如Fibre Channel或iSCSI磁盘阵列)，因此主VM和备份VM可以访问它们的输入和输出。 (我们将在第4.1节中讨论主VM和备份VM具有独立的非共享虚拟磁盘的设计。) 只有主VM通知它在网络上的存在，因此所有网络输入都进入主VM。 类似地，所有其他输入(如键盘和鼠标)都只进入主VM。

（主虚拟机：Primary VM，简称为主机，Backup VM，简称为备机）

主VM接收的所有输入都通过一个称为日志通道的网络连接发送到备份VM。 对于服务器工作负载，主要的输入流量是网络和磁盘。 为了确保备份VM以与主VM相同的方式执行非确定性操作，需要传输额外的信息(如下面的2.1节所述)。 结果是备份VM总是与主VM执行相同。 但是，备份VM的输出会被系统管理程序删除，因此只有主VM产生返回给客户机的实际输出。 如第2.2节所述，主VM和备份VM遵循特定的协议，包括备份VM的显式确认，以确保在主VM失败时不会丢失任何数据。

（日志同道：logging channel）

为了检测主VM或备份VM是否失败，我们的系统使用相关服务器之间的心跳和日志通道上的流量监控的组合。 此外，我们必须确保主VM或备份VM中只有一个接管执行，即使出现主服务器和备份服务器彼此失去通信的splitbrain情况。

在下面的小节中，我们将提供几个重要领域的更多细节。 在第2.1节中，我们详细介绍了确定性重放技术，它确保主vm和备份vm通过日志通道发送的信息保持同步。 在第2.2节中，我们描述了我们的FT协议的一个基本规则，它确保在主节点失败时不会丢失数据。 在第2.3节中，我们描述了以正确的方式检测和响应故障的方法。

2.1确定性重放的实现

如前所述，复制服务器(或VM)的执行可以建模为确定性状态机的复制。 如果两个确定性状态机以相同的初始状态启动，并以相同的顺序提供完全相同的输入，那么它们将经历相同的状态序列并产生相同的输出。 虚拟机有一组广泛的输入，包括传入的网络数据包、磁盘读取以及键盘和鼠标输入。 非确定性事件(如虚拟中断)和非确定性操作(如读取处理器的时钟周期计数器)也会影响VM的状态。

**提出了三个挑战复制执行任何操作系统和虚拟机运行工作负载：**

(1)正确捕获所有必要的输入和非确定性,确保确定性执行备份虚拟机

(2)正确应用备份虚拟机的输入和非确定性

(3)这样的方式不会降低性能

此外，x86微处理器中的许多复杂操作都有不确定的副作用。 捕获这些未定义的副作用并将其重新播放以产生相同的状态是一个额外的挑战。

VMware replay[15]正是为VMware vSphere平台上的x86虚拟机提供了这一功能。 确定性重放记录VM的输入和与VM执行相关的所有可能的不确定性，记录在日志文件的日志条目流中。 稍后，通过从文件中读取日志条目，可以准确地重放VM执行。<