OSDI2020:Delos中的虚拟共识

Delos中的虚拟共识

个人博客：
https://www.huixinyixiao.xn–6qq986b3xl/

Abstract

​ 我们建议通过虚拟化共享日志API来实现虚拟化共识，从而允许服务在不停机的情况下更改共识协议。虚拟化将一致的逻辑分解为虚拟日志，一个通用的、可重用的重构层;还有称为loglet的可插入排序协议。日志很简单，因为它们不需要支持重新配置或领导人选举;多样的，由不同的协议、代码库甚至部署模式组成;并可通过RAID-like的堆叠和条带进行组合。

​ 我们描述了一个名为Delos的生产数据库，它利用虚拟共识来实现快速、增量的开发和部署。Delos在8个月内投入生产，4个月后升级了consensus协议，没有停机，延迟提高了10倍。Delos可以通过改变一致协议来动态地改变其性能属性:通过切换到一个分解的Loglet，我们可以将吞吐量扩展到10倍，并在不牺牲吞吐量的情况下通过striped Loglet将实例的故障阈值提高一倍。

1 Introduction

​ 使用共识复制状态的系统是单一的、复杂的，并且很难发展。

​ 在本文中，我们通过虚拟化共享日志API来虚拟化共识。我们提出了虚拟化共享日志(VirtualLog)的新概念。

​ 虚拟日志中的不同日志可以是具有不同参数、领导权限或成员关系的相同排序协议的实例(例如，MultiPaxos[45]的不同实例);

​ 它们可以是完全不同的日志实现(例如，Raft[39]，LogDevice [3]， Scalog[16]，或CORFU [7]);或者它们可以是外部存储系统上的简单日志垫片(例如，ZooKeeper[20]或HDFS[43])。虚拟化支持异构重新配置:单个虚拟日志可以跨越不同类型的日志，并在它们之间动态切换。

​ Delos是一个共享日志数据库[7,8,33];它通过在VirtualLog上追加和回放命令，跨服务器复制状态。Delos支持多个面向应用程序的api;我们有一个表API在生产中，而第二个ZooKeeper API正在开发中。

​ Delos中的Virtual consensus简化了consensus实现的部署和操作。虚拟化大大缩短了部署时间，因为我们能够通过初始Loglet实现快速部署系统，并在以后升级系统时无需停机。

​ Virtual consensus还简化了新consensus实现的开发。虚拟化将consensus的复杂功能分解为单独的层:提供通用的重新配置功能的控制平面(VirtualLog);以及提供关键路径排序的数据平面(Loglet)。虽然VirtualLog的重新配置机制可以仅用于在完全不同的Loglet实现之间迁移，但它也可以在相同Loglet协议的不同实例之间切换，更改领导权、角色、参数和成员关系。

虚拟共识有一些局限性。

1. 虚拟日志驱动的重新配置的可重用性带来了某些类型的重新配置(如计划中的leader更改)的延迟。loglet可以通过依赖于它们自己的带内重新配置而不是VirtualLog来优化特定的情况。

2. 第二个限制与通用性有关:由于我们虚拟化了捕获命令总顺序的共识的特定API，我们目前不支持基于操作可交换性构建部分顺序的协议。

在未来的工作中，我们计划将虚拟共识扩展到部分有序共享日志

2 The Path to Virtual Consensus

​ 提出一种由异构日志实现组成的虚拟化共享日志。

**虚拟化实现更快的部署。**驱动这个系统设计和开发的两个实际需求:快速部署(它必须在6-9个月内达到生产)和增量演进(它必须随着时间的推移支持更好的性能)。

​ 当时，Facebook已经运行了四种不同的存储系统:

a ZooKeeper service; a shared log service based on LogDevice [3]; a key-value service called ZippyDB [5]; and a replicated MySQL service [13].

它们都是一个整体:数据库API不能轻易更改，底层共识协议也不能重用。

我们的解决方案是将共识虚拟化。在本文的其余部分中，我们将描述虚拟共识如何使我们能够使用现有的共识实现快速到达生产环境，然后无需停机即可迁移到新的实现。

虚拟化加速开发。

​ 虚拟化共享日志将共识协议进一步划分为两个层:一个控制平面，包含用于重新配置的逻辑，另一个数据平面，在关键路径上命令命令。

3 Abstractions for Virtual Consensus（虚拟共识概要）

​ 在本文中，我们提出通过虚拟化共享日志抽象来虚拟化共识。虚拟化有三个设计目标。首先，虚拟化对应用程序应该是透明的，应用程序不应该被修改，并且不应该注意日志的虚拟化特性。第二，虚拟化应该允许底层日志简单而多样，降低新的日志实现的障碍。第三，虚拟化应该允许在没有停机的情况下在实现之间进行迁移。我们通过两个核心抽象来获得这些属性。

​ 在虚拟共识中，我们分而行之:VirtualLog中的共识是简单和容错的(但不一定快，因为它只在重新配置时调用)，而Loglet中的共识是简单和快速的(但不一定容错)。现在我们将详细描述这些抽象及其交互。

3.2 VirtualLog design

​ VirtualLog通过链接底层日志集来实现逻辑共享日志。

VirtualLog由两个不同的组件组成:一个暴露共享日志API的客户端层，它基于链结构映射将操作路由到底层日志;以及持久存储链的逻辑集中元数据组件(MetaStore)。每个客户端维护一个本地(可能过时)缓存的链副本。MetaStore组件有一个简单的API:它是一个支持条件写入的单版本寄存器。读取MetaStore返回一个带有附加版本的值。

VirtualLog的主要技术挑战是为客户端提供一个共享的、高度一致的、高度可用的虚拟地址空间。在稳定状态下，当链保持不变时，这个任务很简单:客户端层可以使用链的本地缓存副本来路由操作。

​ 重新配置包括三个步骤:密封旧链，在元存储上安装新链，以及从元存储中获取新链。

1. 通过冻结当前链的最后一个日志来冻结当前链
2. 在元存储中安装新的链
3. 从元存储中获取新链

​ 并发性:在步骤1中，当一个客户端冻结了一个链后，其他客户端可能会继续在其中运行。使用seal链的VirtualLog的一个附件将被路由到它的最后一个日志，该日志现在被seal在新链中。因此，在旧链中发出追加的客户端将获得一个错误代码，指示日志文件已被seal；然后，它将从元存储中获取最新的链，并重试。

​ 失败原子性:当一个客户端遇到一个seal链时，它可能在元存储中找不到新的链。如果重新配置客户端(seal了链)在seal步骤之后但在安装新链之前失败或延迟，就会发生这种情况。【rolls forward 回滚】

​ 重新配置策略:上面的协议提供了一个通用的重新配置机制

3.3虚拟元存储

​ VirtualLog元存储是我们架构中容错一致性的必要和充分的来源。元存储必须对写操作高度可用；因此，它需要像Paxos这样的容错一致性协议。

3.4日志摘要

​ Loglet是虚拟共识中的数据平面抽象:一个被设计为作为VirtualLog的一部分进行操作的共享日志。对Loglet的需求是最小的：它通过共享日志API提供完全有序、持久的存储。值得注意的是，Loglet可以在静态配置中操作；它不必为角色或成员更改提供支持。它也不必支持领导人选举；也就是说，它不需要为追加调用提供高可用性。相反，Loglet提供了一个高度可用的seal命令，防止新的附加程序被成功地确认。 正如本节前面所描述的，虚拟日志使用这样的seal功能来通过重新配置支持高度可用的append调用。

​ 除了支持seal之外，Loglet还提供了一个增强的checktail，以返回其seal状态以及当前的tail(即，checktail返回一个(tailpos，密sealbit)元组，而不是单个tail的位置)。

​ 为了降低在每个Loglet上实现这个额外调用的负担，它被设计为具有弱语义:**不需要原子检查tail位置和seal状态。**相反，为了提高效率，checkTail调用组合在一个调用中,相当于并行执行的常规checkTail和checkSeal。【并行执行】。

​ Loglet API为不同的日志实现提供了一个通用接口。这种实现可以通过内部领导人选举协议为追加提供可用性;它们甚至可以支持自己的重新配置协议来添加和删除存储服务器

​ 换句话说，虽然VirtualLog提供了重新配置的机制，但loglet对重新配置策略负有部分责任。

4 Delos: Design and Implementation

​ Delos是一个用于控制平面服务的复制存储系统。Delos的设计是由一系列控制plane服务的独特需求驱动的:**对其他服务的依赖程度低;强大的耐用性、可用性和一致性保证;以及丰富而灵活的存储api。**Delos是一个完全复制的ACID数据库，提供严格的可序列化性。它不实现透明的分片或多分片交易，但可以在提供这些功能的其他系统下分层。

​ 每个Delos服务器在RocksDB中维护一个状态的本地副本，并通过状态机复制(SMR)在VirtualLog上保持此状态的同步。当服务器接收到读写交易时，它将序列化并将其附加到VirtualLog，而不执行它。然后服务器与VirtualLog同步;当它在日志中遇到一个事务(不管是它自己附加的还是其他服务器附加的)时，它在单个线程中作为一个故障原子事务在它的本地RocksDB上执行该操作。当附加服务器在VirtualLog中遇到事务并将其应用到本地RocksDB存储时，事务返回。

​ 要执行只读事务，服务器首先检查VirtualLog的当前尾部(获得线性化位置);然后，它将本地状态与VirtualLog同步，直到该位置。然后在本地RocksDB快照上执行只读事务。为了提高效率，Delos借用了Tango的一项技术，将多个只读事务排在VirtualLog的一个未完成同步之后。

1. Log-Structured Merge Tree（LSM存储引擎）
2. state machine replication (SMR状态机复制)

Delos设计:多个api可以运行在一个核心平台上，该平台可以在多个Loglet实现之间动态切换

​ 上面描述的逻辑在每个Delos服务器上分为三层:顶部是一个api特定的包装器;一个由运行时组成的公共核心，该运行时公开SMR接口，并与VirtualLog和VirtualLog下的单个日志交互。

​ 这种分层设计提供了两个维度的可扩展性。

1. 首先，Delos可以在VirtualLog下支持多个loglet，这是本文的重点。
2. 其次，Delos可以在一个平台上支持多个面向应用程序的api。

4.1 The Delos VirturalLog

​ 在Delos中，VirtualLog是通过客户端库和MetaStore实现的组合来实现的。

​ 每个API包装器都是与Delos运行时交互并针对RocksDB提供序列化逻辑的薄代码层。我们在产品中支持表API，支持事务、范围查询和二级索引;我们目前正在部署第二个与ZooKeeper相同的API。在一个公共基础上支持多个api的能力并不新奇:大多数状态机复制库都将应用程序视为黑盒。然而，Delos在公共核心中提供了更大的与应用程序无关的功能子集，包括本地持久存储、备份和新服务器加入时的状态传输。

4.2 The Delos Loglet(s)

​ Loglet(s) 可以聚合，运行在Delos数据库服务器上;或分解，如访问附加在外部服务的Delos服务器上。每种部署模型都有其优点:聚合日志(converg log)允许Delos在不依赖于关键路径服务的情况下运行，并且不会导致访问外部服务的额外延迟。通过将日志放在一个存储层上，可以独立伸缩，并与数据库服务器隔离I/ o，分解可以实现更高的吞吐量。

​ Delos目前支持三种分类日志(参见图5):ZKLoglet在ZooKeeper名称空间中存储日志条目;LogDeviceLoglet是LogDevice服务的透传包装器;在用于冷存储的类似于hdfs的文件系统服务上进行反向上载。

​ 所有三种后台系统——ZooKeeper、LogDevice和类似hdfs的文件系统——内部实现故障处理一致性，包括leader选举和重新配置;Delos只使用VirtualLog来切换它们。

​ 术语

Statement	Description
locally committed	将在特定日志服务器上，命令已经写入并同步到其本地日志；
Local tail	对于特定的日志服务器，他是第一个在本地日志中没有被写入的位置；
Globally committed	一旦它在大多数日志服务器上本地提交，并且之前的所有命令都已全局提交，就称为Globally committed。
Global tail	在Native Loglet中第一个全局未提交日志位置。
append:	为了向NativeLoglet追加命令，Delos服务器会向sequencer发送请求。sequencer排序器为每个命令分配一个位置，并将请求转发给所有日志服务器。一旦从大多数未seal的日志服务器收到成功的响应，它就认为追加是全局提交的(并向客户端确认)
sequencer	为每个日志服务器维护一个传出的附加队列，如果它知道命令已经全局提交，就会忽略向特定日志服务器发送命令的过程。因此，慢速logServers不会阻止追加操作在其他日志服务器上完成，并且尾随的日志服务器可以更容易地赶上，因为它允许省略已经全局提交的存储命令。
seal	任何客户端都可以通过联系每个日志服务器来设置它的 seal 位来密封NativeLoglet。如果seal成功完成—即，大多数日志服务器响应—以后的追加将保证返回一个错误代码，表明NativeLoglet已被seal。注意，成功的seal操作可能会使不同的日志服务器具有不同的本地尾部。
checkTail	这个调用既返回NativeLoglet的当前global tail，也返回它的当前 seal 状态。任何客户端都可以通过向所有日志服务器发送命令并等待大多数日志服务器响应来发出检查尾巴。

​ append: 为了向NativeLoglet追加命令，Delos服务器会向sequencer发送请求。sequencer排序器为每个命令分配一个位置，并将请求转发给所有日志服务器。一旦从大多数未seal的日志服务器收到成功的响应，它就认为追加是全局提交的(并向客户端确认)

​ 如果大多数日志服务器报告它们已被seal，则返回一个错误，表明NativeLoglet已被sealed。在大多数日志服务器响应消极或在超时之前未能响应的所有其他情况下，排序器将重新尝试( retries )追加。Retries 是幂等的(即，同一个命令被写入到相同的位置)，序列器继续重试，直到追加成功或 NativeLoglet 被seal为止。

​ sequencer :为每个日志服务器维护一个传出的附加队列，如果它知道命令已经全局提交，就会忽略向特定日志服务器发送命令的过程。因此，慢速logServers不会阻止追加操作在其他日志服务器上完成，并且尾随的日志服务器可以更容易地赶上，因为它允许省略已经全局提交的存储命令。

​ seal :任何客户端都可以通过联系每个日志服务器来设置它的 seal 位来密封NativeLoglet。如果seal成功完成—即，大多数日志服务器响应—以后的追加将保证返回一个错误代码，表明NativeLoglet已被seal。注意，成功的seal操作可能会使不同的日志服务器具有不同的本地尾部。

​ checkTail :这个调用既返回NativeLoglet的当前global tail，也返回它的当前 seal 状态。任何客户端都可以通过向所有日志服务器发送命令并等待大多数日志服务器响应来发出检查尾巴。

4.2.1 Loglets sans consensus: NativeLoglet

​ Seal bits 三种可能

1. all-sealed:在所有响应的logserver都被seal并且它们都返回相同的本地尾部X的情况下，返回值是(X, true)。但是，日志服务器可能具有不同的local tail(例如，在进行追加时，如果一个seal到达)。在这种情况下，客户端将响应的logserver“修复”到最大返回位置Xmax，从拥有它们的logserver复制条目(并绕过seal位)。
2. some-sealed:在响应日志服务器同时拥有seal和未seal状态位的情况下，客户端先发出一个seal，然后重新发出checkTail。
3. none-sealed:在没有任何响应日志服务器被seal的情况下，客户端选择最大位置Xmax，然后等待它自己的knownTail到达这个位置。

​ 在非seal的情况下，checkTail的延迟取决于客户机的knownTail更新的速度，以及它对大多数日志服务器的seal状态的了解。

​ 客户机通过每个日志服务器公开的额外API快速而有效地发现这些信息，这允许它们在本地尾部到达特定位置或日志服务器被密封时请求通知。

**readNext:**Loglet语义规定，readNextbehavior只定义在来自同一客户端的前一个checkTailcall返回值之前的日志位置。这简化了readNext实现:客户端首先检查本地并置的LogServer以找到条目。如果它在本地找不到条目，它就向其他一些日志服务器发出一个读取。注意，读操作不需要quorum，因为我们已经知道条目已经提交;我们只要找到副本就行了。

4.2.2 通过组合的Loglets: StripedLoglet

​ StripedLoglet跨多个底层loglet划分一个逻辑地址空间。地址空间之间的映射是一个简单而确定的条带:逻辑位置L0映射到条带a上的位置a0;l1映射到位置B0;L2 toC0;L3to A1;依此类推(参见图7)。

​ Sharded acceptors: StripedLoglet可以在多个分解的loglet上分层，实现类似CORFU[7]或Scalog[16]的吞吐量线性缩放，尽管这种设计不需要一个集中的排序器或单独的排序层。

5 Evaluation

​ 两个用于评估Delos的硬件设置。

目前主流的SSD大致有两种接口，分别是M.2和SATA两种类型。

NVMe（Non-Volatile Memory Express）/SATA有啥区别

SATA接口的SSD执行的AHCI协议标准，是目前较为成熟、常见的SSD接口。采用SATA接口的SSD价格相对来说比较低，较为适合入门级以及对SSD性能要求较低的用户群体，传输带宽限制为6Gbps，采用AHCI协议。M.2接口分为NVMe协议以及AHCI协议，根据协议不同M.2接口的SSD在性能上也会有着一些差异，NVMe协议最高理论速度为32Gbps。

5.1 The Benefit of Virtualization

​ 虚拟共识允许Delos在不停机的情况下升级其生产中的共识协议。

切换到不同的日志实现可以大大降低生产工作负载的延迟。

该图显示了四类表操作的p99延迟:我们看到多获取和索引查询的延迟提高了10倍，多放置的延迟提高了5倍。

Delos可以通过运行一个分列的Loglet来扩展吞吐量。

在图9中，我们在x轴上绘制吞吐量，在y轴上绘制p99延迟，这是基于90% get和10% puts的合成工作负载。我们比较了聚合的NativeLoglet和分解的LDLoglet。

在上面两个图中，Delos数据库运行在生产HW上，共享ssd;

这10倍的改进部分是由于更多的HW(机器的两倍);更好的日志HW (LDLoglet运行在专用的NVMe ssd上);更少的I/O争用(数据库和日志在不同的机器上)。OPS 即operation per second 每秒操作次数

在下面两张图中，Delos运行在带有专用ssd的基准HW上;由于日志和数据库之间要共享更多的IOPS，聚合后的NativeLoglet的性能影响不那么明显，两个put的延迟都在增加，大约达到139K ops/s。

Delos可以在聚合和分解模式之间动态切换，无需停机。

left figure

​ 在前180秒，我们运行恒定的低工作负载(100 puts/sec);之后，我们将工作量增加到2500 puts/sec。Delos最初运行的是NativeLoglet，它满足15ms SLA的低工作负载要求。但是，当工作负载切换时，由于ssd的I/O争用，Delos+NativeLoglet不再能够跟上，p99延迟降低到1秒以上。在530秒左右，我们重新配置使用LDLoglet;这减少了本地ssd上的I/O压力，允许p99延迟降至15ms以下(由于1分钟滑动窗口导致的60秒延迟之后)

Middle figure

如果我们在2个NativeLoglets上使用StripedLoglet(每个logserver都有一组相同的logserver，但顺序不同)，我们将排序负载在两个服务器上轮换。如图10(中间)所示，当基准测试HW上有9个节点时，Delos+StripedLoglet的运行速度比Delos+NativeLoglet快25%。

right figure

我们还使用StripedLoglet运行了只写日志的实验，如图10所示(右)。我们在多个3节点NativeLoglets上创建了一个StripedLoglet，并从20个VirtualLog客户端追加了1KB的负载。当我们从1条带(3个日志服务器)到30条带(即90个日志服务器)时，我们看到吞吐量的线性扩展;除此之外，我们的客户成为了瓶颈。日志服务器运行在共享的NVMe ssd上，提供30K IOPS, p99为75ms;我们报告了每个配置的最大吞吐量，p99延迟小于75ms。我们在4KB有效负载下得到了类似的结果(750K追加/s, 30个分片);这是在非模拟实验中报告的最高单日志吞吐量，超过CORFU (570K/s)和Scalog (255K/s)。Delos不能利用这样的高吞吐量日志，因为它的日志回放瓶颈;我们计划探索选择性回放[8]，并与Scalog更高的模拟数字进行比较。

5.2 The Cost of Virtualization

Virtualization is inexpensive in terms of critical path latency。虚拟化并不昂贵。在大多数情况下，VirtualLog充当一个简单的透传层。图11(左)显示了VirtualLog和NativeLoglet操作的p99延迟;这些数据是在一个运行在NativeLoglet上的生产集群上以一小时为周期测量的。

重组发生在ms的10秒内。 在图11(中间)中，我们展示了生产集群上一个月内所有重新配置的柱状图。

虚拟化不会影响峰值吞吐量。我们在基准HW上对Delos和ZooKeeper进行了完全的比较。

8 Conclusion

​ 虚拟共识支持更快地部署和开发复制系统。重新配置和leader选举被封装在一个控制平面(VirtualLog)中，可以跨任何数据平面(loglet)重用。Delos是第一个支持异构重配置的系统，不仅允许对系统中的leader或服务器集进行更改，还允许对共识子系统的协议、代码库和部署模型进行更改。因此，新系统可以快速开发和部署(例如，Delos利用外部服务为其Loglet在8个月内投入生产);并且在不停机的情况下进行升级，以提供显著不同的性能和容错特性(例如，我们在生产中热交换loglet，以减少10倍的延迟)。

Vocabulary

1. monolithic : [建]整体的；巨石的，庞大的；完全统一的

2. serializability:可串行性.

参考文章

1. 分布式系列文章——Paxos算法原理与推导 https://www.cnblogs.com/linbingdong/p/6253479.html