ES集群协调

ES集群协调

Elasticsearch 之所以变得如此广泛流行，其中一个原因是，它可以很好地从只有几个节点的小集群扩展为拥有数百个节点的大集群。它的核心就是集群协调子系统。Elasticsearch 7 版本包含了一个新集群协调子系统，与早期版本相比，它提供了很多优点。

什么是集群协调

Elasticsearch 集群可以执行需要多个节点协同工作的很多任务。例如，每个搜索必须路由到所有正确的分片，以确保结果的准确性。在索引或删除某些文档时，必须更新每个副本。每个客户端请求都必须从接收它的节点转发到能处理它的节点。这些节点对集群概况分别有各自的认识，并据此来执行搜索、索引和其他协调活动。这个集群概况就是指集群状态。集群状态决定了每个索引的映射和设置、分配给每个节点的分片，以及同步的分片副本。在集群中保持该信息的一致性十分重要。最近推出的很多功能（包括基于序号的复制和跨集群复制）只有在群集状态一致的情况下才能正常运行。

协调子系统的运行方式是选择一个特定节点作为集群的主节点。这个选举出的主节点需要确保其集群中的所有节点都能够接收集群状态的更新。这比开始听起来要困难得多，因为类似 Elasticsearch 这样的分布式系统必须为各种奇怪的情况做好准备。例如，节点有时运行缓慢，有时垃圾回收会导致停顿，或者突然断电。 网络会出现分区、包丢失、高延迟时段，或者可能提交乱序消息。有时可能会同时出现多个这样的问题，而且可能间歇性地发生。尽管如此，集群协调子系统必须能够保证每个节点具有集群状态的一致性视图。

重要的是，Elasticsearch 必须有足够的弹性来应对各个节点的故障。通过只有在法定数量的节点接受集群状态更新时，才将更新视为成功，Elasticsearch 实现了这种弹性。法定数量是从集群里符合主节点条件的节点中精心选出的一部分节点的数量。仅要求部分节点进行响应的优势在于，某些节点可能会失败，但不会影响集群的可用性。在选择法定数量节点时要十分小心，这样集群就无法选举出两个独立的主节点，从而避免两个主节点作出不一致的决策而最终导致数据丢失。

通常，我们建议集群设置三个符合主节点条件的节点，这样如果其中的一个节点失败，其他两个节点仍然可以安全地形成法定数量，并继续提供服务。如果一个集群少于三个符合主节点条件的节点，那它将无法安全地容忍其中任何一个节点发生故障。相反，如果一个集群中符合主节点条件的节点远多于三个，则节点选举和集群状态更新可能需要更长的时间。

工作原理

如果您熟悉分布式系统理论，则可能会将集群协调看作是可使用分布式共识来解决的一个问题示例。 在 Elasticsearch 的开发之初，分布式共识并未得到广泛理解，不过最近几年，这项技术已经有了长足的发展。

Zen Discovery 采用了很多分布式共识算法中的想法，但只是有机地采用，并没有严格按照理论所规定的那个模型。而且，它还有一个非常保守的超时机制，使得它有时在出现故障后恢复非常慢。7.0 中引入的新集群协调子系统使我们有机会更紧密地遵循这个理论模型。

分布式协调被认为是一个难以解决好的问题。我们曾经严重依赖形式化的方法来预先验证我们的设计，自动化工具在正确性和安全性方面都提供强有力的保证。您可以在公共 Elasticsearch 形式化模型资料库中找到 Elasticsearch 新集群协调算法的形式化规范。这个算法的核心安全模块简单明了。在 Elasticsearch 资料库中，形式化模型与生产代码之间存在直接的一一对应关系。

如果您熟悉 Paxos、Raft、Zab 和 Viewstamped Replication (VR) 等系列分布式共识算法，那么也该熟悉核心安全模块。该模块模拟了一个可重写寄存器，并使用了主节点的概念，这个概念与 Paxos 投票、Raft 条款和 VR 的视图特别类似。该核心安全模块及其形式化模型还包括集群引导、跨节点重启的持续性和动态重配置。所有这些功能对于确保系统能够在所有环境中都正常运行十分重要。

围绕这一理论强健的核心，我们构建了一个活动层，用来确保无论集群发生什么故障，一旦网络恢复并且有足够的节点在线，就会选举出一个主节点，并且该主节点可以发布集群状态更新。这个活动层使用了大量的前沿技术来避免许多常见问题。选举调度程序具有适应性，可以根据网络状况改变自身行为，以避免出现过多的争议选举。Raft 形式的预投票阶段可以在选举开始之前就抑制无法取胜的选举，从而避免恶意节点的干扰。延迟检测可以防止节点在远远落后于主节点时破坏集群。主动双向故障检测可以确保集群中的节点始终能够互相通信。大部分集群状态更新都能够以小的 diffs 高效发布出去，从而避免在节点之间复制整个集群状态。被优雅终止的领导节点将明确让位给它们选择的继承者，通过避免全面选举，减少在有计划的故障转移期间的中断时间。我们开发了测试基础架构来有效模拟可能会持续几秒、几分钟或几小时的非正常中断所带来的影响，从而验证一旦中断得到解决后集群是否可以始终快速地恢复。

为什么不选择 Raft

我们经常被问到的一个问题是，为什么不简单地“插入”像 Raft 一样的标准分布式共识算法。有很多公认的算法，每种算法都有不同的利弊权衡。我们仔细评估了所有可以找到的文献，并从中汲取灵感。在我们早期的概念验证中，有一个概念便使用了非常接近 Raft 的协议。我们从这一经验中了解到，将其与 Elasticsearch 完全集成，需要做出非常巨大的改变。此外，许多标准算法还规定了一些对于 Elasticsearch 来说不是最佳选择的设计决策。例如：

标准算法通常是围绕操作日志构建的，而 Elasticsearch 的集群协调更多的是直接基于集群状态本身。相比基于操作可能达到的优化来说，集群协调可以更简单地对批处理（将相关操作合并到单个广播中）之类的操作进行重大优化。
标准算法在集群伸缩能力方面都相当受限，需要一系列步骤来完成许多维护任务，而 Elasticsearch 的集群协调可以在一个步骤中安全地执行任意的重配置。这通过避免不确定的中间状态简化了周围的系统。
标准算法通常过于关注安全性，而忽略了如何保证活动性的细节，也没有描述如果发现某个节点不健康时，集群该如何反应。Elasticsearch 的健康检测机制非常复杂，已经在该领域经过了多年的使用和优化，对于我们来说，维持其现在的运行状况十分重要。事实上，与保证系统的活动性相比，实现系统的安全性所需付出的成本要少得多。大多数的实现工作都集中在系统的活动性上。
项目的目标之一是，支持从运行 Zen Discovery 的 6.7 集群零中断滚动升级到运行新协调子系统的版本 7 集群。将任何标准算法调整为允许这种滚动升级的算法似乎都不可行。
开发一个完整的、以工业级强度实现的分布式共识算法需要大量的投入，并且必须超越学术文献所概述的范围。在实践中，定制是不可避免的，但是协调协议十分复杂，任何定制都存在引入错误的风险。从工程角度来看，将这些定制视为开发新协议可能更有意义。