PAXOS性能建模-3

头图源自 xp

现在越来越多的人把 Paxos 应用到了广域网 比如Google Spanner and CockroachDB

这篇文章中,我们将研究EPaxos and wPaxos 。这里将跳过一些如何达到模型的解释,它们都依赖于排队论的近似处理开销和k阶统计量来计算群体大小的影响。(queuing theory approximations for processing overheads and k-order statistics )

尽管广域网的模型设计方法比在本地操作中更难实现。这个困难主要来自于我需要考虑的无数附加参数。例如,对于广域网中的Paxos,我需要查看集群中每个节点之间的延迟,因为广域网在区域间的延迟方面并不完全一致。对于EPaxos,我有多个leader要建模,这意味着我还必须考虑到每个节点在某些时隙中跟随其他节点的角色所带来的处理开销。wPaxos更进一步:为了建模其性能,我需要考虑访问局部性和“对象窃取”等。

今天我只关注5个区域模型。特别是,我获得了5个AWS区域之间的平均延迟:日本(JP)、加利福尼亚(CA)、俄勒冈州(OR)、弗吉尼亚州(VA)和爱尔兰(IR)。图1显示了这些区域之间的延迟。

图1:AWS的一些区域和它们之间的延迟。(ms)

Paxos in WAN

将paxos模型从LAN转换为WAN相当简单;我需要做的就是修改paxos模型,使节点之间的距离不均匀。我还需要设置哪个节点将成为我的 multi-paxos rounds 的领导者。有了这些小的改变,我可以和paxos玩一玩,看看WAN是如何影响它的。

图2:WAN中的 Paxos,不同地区的 leader。

图2(上图)显示了5个区域中5个节点的模型运行(每个区域1个节点)。从我的上一篇文章,我知道系统的 最大吞吐量不依赖于网络延迟,所以广域网中的paxos 在这方面与本地网中的 paxos 相似是合理的。然而,我有点惊讶地发现WAN部署中的延迟几乎一直保持到饱和点。然而,这是非常有意义的,因为广域网RTT控制了延迟,并且由于排队成本而增加的小延迟在很大程度上被大的网络延迟所掩盖。这也可以解释为什么 Spanner、CockroachDB 和其他人在数据库中使用paxos;在整个负载条件范围内具有可预测的性能,这使得向客户端提供稳定的性能和更容易实现负载平衡的工作更为理想。

然而,并不是这里的一切都那么美好。leader 节点的地理位置对决定paxos 集群的延迟起着至关重要的作用。如果 leader 节点离 majority quorum nodes 太远,将导致高延迟。我们在日本和爱尔兰地区看到了这一点,因为它们看起来远离系统中的所有其他节点,并导致非常高的操作延迟。

EPaxos

EPaxos 协议试图解决paxos的一些缺点。特别是,EPaxos不再只有一个leader节点,任何节点都可以引导一些命令。如果命令是独立的,那么EPaxos可以使用 fast quorum 在一个阶段快速提交它们。但是,如果命令有依赖关系,EPaxos需要在 majority quorum 上运行另一个阶段(此时它几乎变成 Paxos,有两个阶段用于领导人选举和提交操作)。在某些情况下,fast quorum 可能大于majority quorum ,但在我今天描述的 5 节点模型中,fast quorum 与 majority quorm(3个节点)相同。

当然,命令之间的冲突会对性能产生很大的影响:没有冲突,所有操作都可以在一个阶段内决定,而100%冲突时,所有操作都需要两个阶段。由于运行两个阶段需要更多的消息,所以我不得不更改模型,以考虑运行两个阶段的概率。此外,该模型现在分别查看每个节点的性能,并考虑到在某些插槽 slot 中领先而在另一个插槽之后的节点。

图3:命令冲突为2%的每个节点上的 EPaxos吞吐量。

图4:50%命令冲突时每个节点的EPaxos吞吐量。

图3和图4(上图)显示了在2%和50%冲突情况下每个节点的EPaxos性能。请注意,集群的总吞吐量是所有5个节点的总和。对于2%的冲突,最大吞吐量是Paxos的2.7倍。随着命令之间的冲突增加,EPaxos将失去其容量,其最大吞吐量也会降低,如图5(下图)所示。这种不断变化的容量可能会增加在生产环境中使用EPaxos的难度。毕竟,在整个系统的生命周期中,工作负载特性可能会波动,EPaxos集群可能会或可能无法承受相同强度(相同数量的请求/秒)但会产生不同的冲突的工作负载。

图 5: EPaxos汇总了不同冲突级别的最大吞吐量。

wPaxos

wPaxos是最近针对WAN优化的paxos。它的主要前提是将针对不同实体(对象) entities (objects) 的命令分离给不同的领导者,并在地理位置上接近客户端所要求的实体的位置处理这些命令。与大多数Paxos风格不同,wPaxos需要大型群集,但是由于 flexoble quorums,每个操作仅使用群集中节点的子集。这使我们能够同时实现多领导能力和低平均延迟。

但是,wPaxos具有许多可配置的参数,这些参数都会影响性能。例如,可以将容错降低到系统不能容忍区域故障,但是仍然可以容忍该区域内节点的故障的程度。在这种情况下(下面的图6),wPaxos可以通过所有区域的总吞吐量(每个区域3个节点,总共15个节点)达到每秒153000个请求的最佳性能。

图 6 : wPaxos没有区域容错,70%的区域本地操作 region-local operation 和 1%的对象迁移几率 object migration 。

由于地理位置的不同,我们仍然观察到延迟的巨大差异,因为来自一个区域的某些请求必须经过窃取阶段 stealing phase ,或者在另一个区域得到解决。但是,请求的平均延迟比EPaxos或Paxos要小。当然,直接比较wPaxos和EPaxos是困难的,因为wPaxos(至少在这个模型配置中)没有EPaxos那么容错。与我上次的FPaxos模型不同的是,wPaxos模型还将第2阶段的通信减少到第2阶段的 quorum only 。这使得它能够比“与所有节点通信”方法更充分地利用Flexible Quorum。因此,拥有更多节点有助于 wPaxos 提供比 EPaxos 更高的吞吐量。

一些EPaxos问题仍然出现在wPaxos中。例如,随着访问局部性的降低(the access locality decreases)和对象迁移速率的增加,集群可以提供的最大吞吐量也会降低。例如,图7(下图)显示了wPaxos模型,其中 locality 缩小到50%,对象迁移扩展到所有请求的3%。

图7:wPaxos,无区域容错能力, region-local operations 50%,对象迁移几率3%。

模型有多好?

LAN和WAN的模型似乎与我们在Paxi框架中观察到的研究各种共识形式的结果非常吻合。但是,总会有改进的空间,因为可以考虑更多的参数以建立更准确的模型。例如,WAN RTT 并没有真正遵循单一的正态分布,因为数据包可以采用从一个区域到另一区域的许多路由中的一条(下面的图8)。与相当理想的模型相比,这可能会使真实的性能波动和“抖动”更多。

图 8:VA 和 OR之间的WAN延迟。

我也没有考虑一些处理开销。在EPaxos中,节点必须找出每个请求的依赖关系图,对于高冲突的工作负载,这些图可能会变得很大,需要更多的处理能力。我的模型很简单,并假设此开销可以忽略不计。

结束语

在一系列paxos性能建模文章中,研究了影响其性能的各种算法和参数。我认为这确实比以前进行了这项工作之前帮助我更好地了解了Paxos。我证明了网络波动对paxos性能几乎没有影响(k阶统计有助于弄清楚这一点)。我展示了节点的处理能力如何限制性能(我知道这是微不足道的和显而易见的),但是显而易见的是,但仍然有一点有趣的是,paxos节点处理了大约一半不再起作用的消息。一旦达到多数定额,一轮的所有其他消息将对系统造成沉重的处理负担。

与其他更复杂的Paxos口味(EPaxos,wPaxos)相比,Paxos的稳定性似乎也很有趣,并且可能解释了为什么生产级系统经常使用Paxos。尽管容量较小,但是paxos非常稳定,因为其延迟在吞吐量水平上几乎没有变化。此外,paxos的 最大吞吐量 不受诸如 冲突或局部性 之类的工作负载特征的影响。这种可预测性对于必须计划和分配资源的生产系统很重要。不管工作负载特性如何,为系统提供稳定的性能进行规划都更加容易。

地理因素在WAN paxos性能中起着重要作用。尽管群集具有相同的最大吞吐量,但是客户端将根据 leader 区域观察到的性能有很大不同。EPaxos 和 wPaxos 也是如此,因为不同的区域与quorum 通信有不同的成本,这意味着一个区域中的客户端可能会观察到与其他区域中的对等方非常不同的延迟。我认为这可能会使向生产系统中所有客户端的操作延迟提供相同的强有力保证(SLA?)变得更加困难。

任何有兴趣的人都可以在GitHub获得模型。

给TA打赏
共{{data.count}}人
人已打赏
科学人论文速递

PAXOS性能建模-2

2021-3-17 18:54:00

科学人

Making a Scalable and Fault-Tolerant Database System: Partitioning and Replication

2021-4-2 15:31:00

0 条回复 A文章作者 M管理员
    暂无讨论,说说你的看法吧
个人中心
购物车
优惠劵
今日签到
有新私信 私信列表
搜索