使用Lifeguard让Gossip变得更加健壮
Making Gossip More Robust with Lifeguard
[1707.00788] Lifeguard: Local Health Awareness for More Accurate Failure Detection
今天我们很自豪的宣布HashiCorp的第一份research报告（这是consul的开发公司） "Lifeguard: SWIM-ing with Situational Awareness"。这篇论文详细的列出了一些新颖的改动到Serf，Consul和node让他们的gossip协议变得更加健壮。这些扩展成为救生员，这些扩展将故障检测器的误报减少了50倍，允许我们更快的检测到真正的故障。
分布式系统比如bittorrent，apache Cassandra，Microsoft Orleans，HashiCorp Consul通常使用Gossip协议。它们通常被嵌入以提供诸如集群成员（谁在及群众的特性），故障探测（哪个成员存活）事件广播。它们点对点通信特性通常使它们比集中式的方法更具可靠性。然而，通信量的减少使让他们对信息处理的缓慢很敏感。
我们许多工作都利用了学术界的工作成功，我们希望通过HashiCorp Research做出贡献。我们的重点是关于我们在实践中使用算法和系统设计的新颖白皮书。救生员是我们的第一个出版物，我们用户在生产环境中操作这些工具推动了这些改进的重点。
救生员
HashiCorp工具嵌入了我们的成员列表库，该库实现了SWIM（可扩展的弱一致感染风格成员）协议。原来的协议提供了集群成员关系和故障探测，由Serf扩展提供事件广播。Serf作为库嵌入到Consul和Nomad中，同时也是一个独立的工具。总的来说，这些系统在数百万台机器上运行，每个数据中心运行着超过10K个八卦协议参与者。
我们在支持这样系统的经历导致我们发现了一些原来协议中的缺点。特别是由于CPU耗尽。这可能会产生高傲代价的影响，这可能会产生代价高昂的影响，例如不必要地从健康成员转移网络流量，并处罚不必要的数据副本再平衡。
Lifeguard的成立是为了减少误报，避免对数据中心中相对常见的条件敏感。我们在原有SWIM作者的工作基础上，添加了三个新的扩展，共同构成了Lifeguard。我们交这些扩展Self-Awareness，Dogpile和Buddy系统。下面将详细探讨这些扩展。
Self-Awareness
第一个扩展叫做Self-Awareness，因为我们试图将多个信息来源结合起来，对本地成员的健康状况进行估计，实际上，这让成员对自己的状态有了自我意识，Gossip协议依赖于所有成员合作来确定哪些成员是健康的，哪些成员是不健康的。原始的SWIM论文假设了故障终止模型，意味着成员要么运行，要么失败，中间没有灰色，成员可以运行但会降级（例如CPU耗尽）。由于gossip合作的性质，这些退化的节点可能无意中影响其他健康成员的稳定性。
self-warreness允许成员确定，当前是否降级，并减少对集群其他成员产生的影响。每个节点维护Node Self Awareness计数器，通过与其他成员的各种互动来更新。随着集群的增长，成员在声明其他节点不健康时变得保守。这种反馈循环允许不健康的成员迅速对其集群的其他成员影响最小化，直到情况好转，一旦他们与其他成员的互动表明他们已经康复，它们就会回复正常行为。
Dogpile
Dogpile是第二个扩展，因为多个成员会在宣布另一个成员失败时dogpile。在最初的SWIM论文中，单个成员可以怀疑另一个成员的失败，被怀疑失败的成员可以在固定时间内进行反驳。当成员是健康的时候这个机制是健壮的，但是当节点经历CPU耗尽它可能不发送消息，以及标记消息，健康的成员看起来是故障了。
Gogpile用动态的时间框架替代了固定的时间国家来反驳失败，当独立成员确认某个成员失败时，对数减少。当降级的成员有怀疑时，它将不会收到任何确认，并且有更多的时间来处理反驳，因为它的计时器没有减少。如果一个成员确实失败了，它将很快被其他成员确认，并且不会增加健康成员将该成员标记为失败所需的时间。
Buddy 系统
Buddy 系统是最后的扩展，因为成员会通知自己有嫌疑的对等节点，因此他们就可以更快地反驳自己失败。在成员之间有几个类型的沟通，包括健康检查和状态广播。通常当一个节点加入集群，或者可以节点疑似失败，或者离开集群，它将广播协议最后被所有的成员收到。广播序列包括将消息转发给几个对等节点，然后将这些对等节点发送给其他几个对等节点，以此类推，直到所有成员都收到该消息。
广播机制是有效的，但是需要几轮的gossip来通知所有成员。因为俩个成员将直接通信以检查是否活跃。Buddy系统重写这个戒指，以直接通知成员它被怀疑有故障，而不是等待广播机制到达该成员。这种方式允许成员立即反驳故障判断，因为当另一个成员探测它时，它会了解到自己在集群中的状态。
结果
论文详细介绍了每个 Lifeguard 扩展，并分析了它们各自的和综合影响。下图提供了 Lifeguard 效果的高级快照：
相对于基线（即 Lifeguard 之前的实施），我们将误报率降低了 50 倍以上。这也不会影响将成员检测为失败所需的时间。Lifeguard 中的参数或 “旋钮” 之一是 alpha，它让我们控制成员有多少时间来反驳失败。通过调低此旋钮，我们可以更快地检测到故障，但代价是会增加误报。在 Lifeguard 之前，这会导致不可接受的误报数量，但使用 Lifeguard 和 alpha=2，我们可以在几乎一半的时间内检测到故障，误报减少 7 倍。
我们已将 memberlist 中的默认值更改为 alpha=4，以便现在检测失败的速度提高了 20%，误报率减少了 20 倍。由于 Lifeguard，最终用户将感知到更快、更强大的系统。其中许多改进已于 2016 年 9 月纳入，并已在生产环境中大规模运行了数月。对于那些对细节感兴趣的人，全文是现已在 Arxiv 上推出.非常感谢帮助测试和提供反馈的用户，感谢 Armon Dadgar 提供建议，感谢 James Phillips 对 Consul 的指导。
在 HashiCorp，我们坚信研究的价值。我们的许多工具都利用学术著作来提高其性能、可扩展性或安全性。以这种方式使用研究使最终用户可以访问最先进的技术。Lifeguard 是我们推进技术水平和回馈社区的方式。随着我们继续与用户和客户合作，了解他们面临的挑战，这有助于为我们的研究提供信息，并帮助我们专注于解决问题的前沿。我们期待着在未来分享我们下一步的工作。