本课讨论容错（Fault-Tolerance）和复制（Replication）的问题，主要研究VMwareFT的论文——TheDesignofaPracticalSystem复制的方法forFault-TolerantVirtualMachines主要通过两种方式在集群中实现复制：StateTransfer：主节点（Primary）将自身的所有状态复制并发送给备份节点（Backup）。定量备份；复制状态机（ReplicatedStateMachine）：把备机当作一个确定的状态机——客户端向主控机发送操作，主控机按顺序向备机发送操作，所有备机执行所有操作。在初始状态下，相同的操作以相同的顺序被赋予相同的输入，它们的输出将是相同的。VMwareFT使用复制状态机方法。状态传输可能在内存中，而复制的状态机则传输来自客户端或其他外部事件的操作。人们倾向于使用复制状态机的原因是外部操作或事件通常小于服务的内存状态。比如如果是数据库，它的内存状态可能达到GB级别。复制挑战需要考虑的几个大问题：我们想要复制什么状态？master是否必须等待备份完成？什么时候切换到备份？需要重新添加一个新副本，这可能是一个代价高昂的行为，因为副本可能非常大，如何提高添加新副本的速度？且看虚拟化巨头VMware是怎么做的。VMwareFT论文摘要概览如图1所示，约定主虚拟机（PrimaryVM）简称host，BackupVM简称backupmachine。VMwareFT需要两台物理服务器，主备同步，虚拟机的虚拟磁盘在共享存储上。所有的输入（如网络、鼠标、键盘等）都会先输入到主机，再通过Logging通道转发到备机。对于非确定性操作，将发送附加信息以确保备用机器以确定性方式执行这些操作。操作。两台虚拟机都会进行输入操作，但只有主机的输出会返回给客户端，备机的输出会被hypervisor丢弃。虚拟中断等确定性重放（Non-Deterministic）事件，以及从处理器读取时钟周期计数器等非确定性操作，都可能导致主备运行结果不同。这带来了三个挑战：正确捕获所有输入和必要的确定性输入，以确保备用机的确定性执行；在备用机器上正确执行非确定性输入；不降低系统性能；VMware确定性重放（deterministicreplay））捕获所有输入和可能的非确定性输入并将其写入日志文件。通过读取日志文件，可以准确地重放虚拟机的执行过程。对于不确定的输入，必须记录足够的信息用于重放，但论文中没有描述具体的日志格式。罗伯特教授猜测可能有三种记录：事件发生时的指令序号；日志类型。可能是正常的网络数据输入，也可能是奇怪的指令；数据。FT协议（FTProtocol）VMwareFT通过deterministicreplay产生相关的日志条目，但不将日志写入磁盘，而是通过loggingchannel发送给备机。备用机器实时重播日志条目。为了容错，必须在loggin通道上实现严格的容错协议，有如下要求：与主机向外界发送输出的方式完全相同。最简单的方法是为每个输出操作创建一个特殊的日志条目。但是有一种情况，假设虚拟机跑的是数据库，主机和备机的数据都是10，现在client发自增请求，host做+1，回复11的client，然后马上宕机，更糟糕的是host发给standby机器的+1操作也丢包。此时备机还是10台，已经接管了主机的工作。客户端再次请求+1，将收到11的回复。客户端将得到一个奇怪的结果（递增两次或11）。因此需求如下：输出规则：主机在备机收到并确认与输出相关的日志后，才向外界发送输出。这样做的目的是只要备机已经收到了所有的日志条目，即使主机宕机了，备机仍然可以重放到客户端最后看到的状态。如图2所示，对外界的输出被延迟，直到主服务器收到来自备用服务器的确认。几乎每个复制系统都有这个问题：在某个时刻，master不得不停下来等待standby，这肯定会限制性能。注意：因为没有两阶段提交事务，所以不能保证所有输出都恰好生成一次。备机无法判断最后一次输出是主机在死机前还是死机后发出的，备机可能会重新执行输出操作。但是，VMware使用其网络基础架构来检测重复数据包并防止将输出重新传输到客户端。故障发现和处理主机和备机必须快速知道对方的故障，并通过udp心跳包和监控日志通道上的流量相结合来检测。如果心跳超时或日志记录通道流量停止，则表示出现故障。如果备机出现故障，主机会停止向日志通道发送日志，继续正常运行。在此之后备份机如何赶上主机？VMware有一个叫做VMotion的工具，可以最小化虚拟机的执行，克隆一个虚拟机。如果主数据库发生故障，备用数据库必须重播，直到最后一个日志条目被消耗掉。然后备用机器接管主机并开始向客户端产生输出。为确保一次只有一个VM是主机并避免脑裂，VMware在共享存储上执行原子测试和设置锁。该操作一次只能返回其中一台机器成功，这在master和standby机器因为网络分区都想接管的时候很有用。但如果由于网络问题无法访问共享存储，则无论如何都无法使用。当其中一个虚拟机出现故障时，VMwareFT会自动在另一台物理机上启动一个新的备份虚拟机来恢复冗余。FT的实际实现细节上一节描述了容错的基本设计和协议，但还需要设计和实现许多其他组件，以创建一个可用的、健壮的自动化系统。启动和重启FTVM的挑战之一是如何在主机运行时以与主机相同的状态启动备用机？为了解决这个问题，VMware提供了一个名为VMwareVMotion的工具，它允许将正在运行的虚拟机从一台服务器迁移到另一台服务器。对于容错，该工具已被重新设计为FTVMotion，允许将虚拟机克隆到远程主机而不会中断主机超过1秒。管理日志通道上图3展示了日志从主机产生到备机消费的过程。虚拟机管理程序维护了一个很大的日志缓冲区（logbuffer）来保存主机和备机的日志。主机会产生日志项到日志缓冲区，备机从日志缓冲区中消费日志。如果备机读到一个空的日志缓冲区，它会暂停操作，直到日志缓冲区有日志；如果主机写入日志后发现日志缓冲区已满，它也会暂停操作，直到日志项被清除——这种暂停会影响到虚拟机客户端。因此，我们的实现必须尽量减少主机日志缓冲区被填满的可能性。通常主机日志缓冲区满的原因：带宽太小，日志通道带宽建议1Gbit/s；备机执行速度太慢，所以当日志消费太慢时，宿主机的日志缓冲区也可能被填满；在VMwareFT中实现了一种机制，当standby远远落后（根据论文超过1秒）时，可以减慢master的执行速度。通过减少主机的CPU资源来减慢速度。请注意，主机速度变慢的情况很少见，通常只会在系统承受极大压力时才会发生。磁盘IO实施问题有一些与磁盘IO相关的微妙实施问题。问题1：非阻塞磁盘操作可以并行执行，因此同时访问同一磁盘位置会导致不确定性。解决方案：检测所有此类IO争用，然后强制这些竞争磁盘操作以相同的方式在主备上顺序执行。如何检测？论文没说。问题二：虚拟机上应用程序（或操作系统）的磁盘操作也可能造成内存竞争。解决方案：通过Bouncebuffer解决——一个与磁盘操作访问的内存大小相同的临时缓冲区。磁盘读操作修改为读取bouncebuffer中的特定数据，只有在IO操作完成，传输完成后才将数据复制到虚拟机内存中。同理，对于磁盘写操作，会先将要发送的数据复制到bouncebuffer，磁盘写操作修改为将数据写入bouncebuffer。反弹缓冲区的使用减慢了磁盘操作，但该论文称它没有发现任何明显的性能差异。问题三：主机故障导致主机磁盘IO未完成，备份接管后怎么办？解决方法：发送错误提示IO失败，然后重试错误的IO。备选方案本节讨论一些备选方案，以及它们做出的权衡。共享磁盘与非共享磁盘：VMwareFT使用主计算机和备用计算机均可访问的共享存储。另一种方法是使用单独的（非共享的）虚拟磁盘，主计算机和备用计算机分别写入这些磁盘。当主备机不能同时访问共享存储，或者共享存储过于昂贵时，可以采用这种设计。缺点是它需要额外的工作并且必须同步磁盘状态。在备用数据库上执行磁盘读取：在当前实现中，备用数据库从不从磁盘读取，磁盘操作被视为输入。另一种设计是备用机器可以执行磁盘读取，这有助于在磁盘读取工作负载繁重时减少日志通道流量。然而，这种方法有两个主要挑战：它可能会减慢备用数据库的执行速度，因为备用数据库必须执行所有磁盘读取；如果读取在主数据库上成功但在备用数据库上失败（反之亦然）怎么办？必须做一些额外的工作来处理失败的磁盘读取。VMware的性能评估表明，在备用机上执行磁盘读取会降低吞吐量1-4%，但也会降低日志带宽。FAQ来自：https://pdos.csail.mit.edu/6.824/papers/vm-ft-faq.txtQ：GFS和VMwareFT都提供容错功能，哪个更好？FT提供了计算容错，你可以使用它为任何现有的web服务器提供容错。FT提供了相当严格的一致性，并且对客户端和服务器都是透明的。例如，您可以将FT应用于现有的邮件服务器并为其提供容错能力。GFS只提供存储容错，因为GFS只对特定的简单服务（存储）提供容错，其备份策略会比FT更高效。例如，GFS不要求中断在所有具有完全相同指令的副本上发生。GFS通常只用于系统的一部分，对外提供完整的容错服务。比如VMwareFT本身也依赖于一个主备机共享的容错存储服务，你可以使用类似GFS的东西来实现这个共享存储（虽然详细来说GFS并不适合FT）。问：共享存储上的原子测试和设置指令是什么？对于共享存储上的服务，初始状态为false。发送一个test-and-set操作，伪代码为：test-and-set(){acquire_lock()ifflag==true:release_lock()returnfalseelse:flag=truerelease_lock()returntrue只有当它接管主机时返回真。主要目的是避免主备机有网络分区，都想接管时出现脑裂（即同时有两台主机）。这有点像分布式锁。问题是：伪代码不显示何时将标志设置为false！老师解释：论文中没有提到什么时候将flag重置为false，可能是管理员手动操作，也可能是交给机器清理。小结本节讨论主从复制这个经典的分布式话题。主从模式几乎是最常见的数据库系统高可用方案。这篇论文扩展了我对主从复制的理解。但论文也提到了该系统的一个局限性：仅支持单处理器，多核并行所涉及的不确定性将使系统的实现更具挑战性。实际上，VMware支持多核，但是VMwareFT的论文根本没有讨论，这需要更多的信息。参考TheDesignofaPracticalSystemforFault-TolerantVirtualMachines：https://pdos.csail.mit.edu/6.824/papers/vm-ft.pdf第4讲：主/备份复制：https://pdos.csail。mit.edu/6.824/notes/l-vm-ft.txtVMwareFT常见问题解答：https://pdos.csail.mit.edu/6.824/papers/vm-ft-faq.txtVMotion：https://www.vmware。com/pdf/vmotion_datasheet.pdf确定性回放：http://www-mount.ece.umn.edu/~jjyi/MoBS/2007/program/01C-Xu.pdf本文转载自微信公众号“多糖”，您可以通过下方二维码关注。转载本文请联系多歌堂公众号。
