Elasticsearch7版本新版改革

释放双眼,带上耳机,听听看~!

Elasticsearch如此广泛流行的原因之一是它从仅具有少量节点的小型集群到具有数百个节点的大型集群的扩展程度。其核心是集群协调子系统。Elasticsearch版本7包含一个新的集群协调子系统,与早期版本相比具有许多优势。本文介绍了Elasticsearch7版本中对此子系统的改进。它介绍了如何使用新的子系统,更改如何影响Elasticsearch6的升级,以及这些改进如何防止你无意中将数据置于风险之中。最后介绍了描述新子系统如何工作的原理。

什么是集群协调?

Elasticsearch集群可以执行许多需要多个节点系统工作的任务。例如:必须将每个搜索路由到所有正确的分片,以确保其结果准确无误。索引或删除某些文档时,必须更新每个副本。必须将每个客户端请求从接收它的节点转发到可以处理它的节点。每个节点都有自己的集群概述,以便它们可以执行搜索,索引和其它协调活动。此概述成为集群状态。集群状态确定每个索引的映射和设置,分配给每个节点的分片以及同步的副本分片等内容。在整个集群中保持此信息的一致性非常重要。许多新功能(包括基于序列号的复制和跨集群复制)只能正常工作,因为它们可以依赖于集群状态的一致性。

协调子系统通过选择特定节点作为集群的主节点来工作。此选定的主节点确保其集群中的所有节点都接收到集群状态的更新。这比最初听起来更难,因为像Elasticsearch这样的分布式系统必须准备好应对许多奇怪的情况。节点有时运行缓慢,Full GC导致的暂停垃圾回收或者突然断电。网络故障,数据包丢失、高延迟的时候,或者可能与发送顺序不同的顺序传递消息。一次可能存在多个这样的问题,并且它们可能间歇性的发生。尽管如此,集群协调子系统必须能够保证每个节点都具有一致的集群状态视图。

重要的是,Elasticsearch必须能够适应各个节点的故障。它通过考虑集群状态更新在法定数量法定数量的节点接受它们之后成功来实现这种弹性。法定节点数是一个被精心选择的所有候选主节点的子集。仅要求法定节点响应状态更新请求的优点是集群某些节点可能会在不影响集群可用性的情况下发生故障。必须仔细选择法定节点的集合,以确保集群不发生脑裂的情况,防止导致数据的丢失。

通常我们建议集群有三个候选主节点,以便其中一个节点出现故障时,其它两个节点仍能安全的达成更新的法定节点数。如果集群的候选节点少于3个,则无法安全地容忍丢失任何节点。相反,如果集群有多余的三个候选主节点,则选举和集群状态的更新可能需要更长的时间。

进化还是革命?

Elasticsearch6.x版本及更早的版本使用名为Zen Discovery的集群协调子系统。这个子系统多年来不断发展和成熟,并成功地为各类规模的集群服务。然后我们希望能对这个模块做进一步的改进,特别是一些设计分布式协调如何工作的基础方面的改造。

Zen Discovery允许用户使用discovery.zen.minimum_master_nodes来设置最少的集群节点数。在集群中的每个节点上正确设置此配置,并在集群节点数变幻时正确更新它的至关重要。系统无法检测用户是否错误配置了此设置,实际上在添加或删除节点后很容易忘记调整它。Zen Discovery试图通过延迟选举几秒钟的时间来防止各种各样的错误配置,并且通常对它超时也相当的保守。这意味着如果当前的主节点发生故障,在选举新的主节点之前,集群会有几秒钟不可用。而且如果集群最终不能选出主节点,也很难分析出原因。

从Elasticsearch7.0开始,我们重新设计并重写了集群协调子系统:

  • minimum_master_nodes配置被删除,有利于允许Elasticsearch自己选择由哪些节点组成法定选举节点。
  • 典型的主节点选举可以在1s内完成。
  • 增长和缩小集群变得更安全,更容易,并且错误配置导致数据丢失的机会变少了。
  • 节点增加更多的记录状态日志,帮助诊断无法加入集群或无法选举出主节点的原因。

在添加或者删除节点时,Elasticsearch会自动的通过更新集群的投票配置自动维持最佳的容错级别。投票配置是一组有资格参与投票的候选主节点。通常,投票配置包含集群中所有符合条件的候选主节点。所有集群状态的更新都需要有投票配置中的一半以上节点同意。由于现在交由系统来管理投票配置,即投票的法定数量节点,即使在添加或删除节点的时候也可以避免因人工错误配置而导致的数据丢失。如果节点无法发现当前主节点并且无法赢得选举,那么从7.0版本开始,Elasticsearch将定期记录一条告警日志,详细描述当前的状态,以帮助诊断更多常见问题,另外,老版本的Zen Discovery有一种非常罕见的故障模式,在Elasticsearch Resiliency Status页面上记录为“重复多次的网络分区故障可能导致集群状态更新丢失”,这个版本在新版本中已经解决。

如何使用Zen?

如果你是完全使用ES默认配置启动一些新安装的Elasticserch节点,那么它们将自动寻找同一主机上运行的其它实例,并在几秒钟形成一个集群。如果在同一台主机上启动更多的ES实例,则默认情况下它们也会发现并加入此集群。使用Elasticsearch7.0版本可以和早期版本一样轻松部署多个节点。

这种全自动的集群发现机制在单个物理主机上运行良好,但它不够强大,无法在生成患者其它分布式环境中使用。存在风险,节点可能不会及时发现彼此,并且可能形成两个或者更多个独立集群。从7.0版本开始,如果要在多个主机上启动一个全新的集群,必须制定第一次投票选举的候选主节点。这个过程称为集群启动引导,仅在集群第一次启动才需要。已加入集群的节点将会投票存储在数据文件中,并在重启后使用这份配置。如果一个老的ES集群突然要新增一个节点,可以从集群的当前主节点上接收这个配置。

启动集群时设置以下这个参数来指定一个或多个符合称为主节点的设备,参数可以为主机名或者IP地址,此参数可以在elasticsearch.yml中设定或者启动Elasticsearch时来指定此配置。

cluster.initial_master_nodes: ["10.150.55.94:9301", "10.150.55.95:9301"]

如果cluster.initial_master_nodes此参数未设置,则一个全新的集群启动时,则会一直定期每隔几秒钟给你一个警告信息,警告信息如下,提示你“master not discovered yet”,未发现master节点

master not discovered yet, this node has not previously joined a bootstrapped (v7+) cluster,
and [cluster.initial_master_nodes] is empty on this node

cluster.initial_master_nodes此参数设置后,我们还需要设置发现子系统,发现子系统就是我们在之前版本定义用到的Zen Discovery模块,但是它在Elasticsearch7.x版本中发生了变化,参数变化如下:

旧名字 新名字 含义
discovery.zen.ping.unicast.hosts discovery.seed_hosts 设置集群中master节点的初始列表
discovery.zen.hosts_provider  discovery.seed_providers 指定master节点的初始主机列表文件,它是可以指定文件路径来动态包含此文件内的主节点
discovery.zen.no_master_block cluster.no_master_block

cluster.no_master_block:指定当群集中没有活动主服务器时拒绝哪些操作。此设置有两个有效值:
all:节点上的所有操作(读取和写入操作)都将被拒绝。这也适用于API集群状态读取或写入操作,如get index设置,put映射和集群状态API
write:(默认)拒绝写入操作。基于上一个已知的群集配置,读取操作成功。这种情况可能导致部分读取陈旧数据,因为该节点可能与群集的其余部分隔离。
该cluster.no_master_block设置不适用于基于节点的API(例如,群集统计信息,节点信息和节点统计信息API)。不会阻止对这些API的请求,并且可以在任何可用节点上运行。
要使群集完全正常运行,它必须具有活动主服务器。

如果从Elasticsearch6.x升级至7.x?

有两种将Elasticsearch6.x升级至7.x,分别为滚动升级或者完全重启升级。官方建议是滚动升级,因为这样可以让你整个集群在保持可用的情况下逐个节点执行升级,在执行滚动升级到7.x之前,必须将6.x版本的集群升级至6.7。完全重启方式允许你从6.x的任意版本升级至7.x版本,但需要关闭整个集群。7.x版本相比6.x版本增加了很多改动,不仅仅是集群协调的改进。为了确保集群能够顺利升级,建议你查看官方的详细升级文档:https://www.elastic.co/guide/en/elasticsearch/reference/7.0/setup-upgrade.html

如果使用滚动升级,则会根据集群中的节点数和现有的老版本指定的minimum_master_nodes候选主节点数,自动执行集群初次启动引导。这意味着在开始升级前要正确配置这个配置项,此处无需设置cluster.initial_master_nodes,因为集群执行滚动升级时会执行初次引导,7.0版本的候选主节点会优先投票给6.7版本的节点,因此升级过程中6.7版本的主节点还是会成为7.0版本的主节点,直到集群中所有的节点都升级为7.0版本。

如果要使用完全重启升级,则必须按照上述方法设置启动引导,在重新启动集群前,必须将cluster.initial_master_nodes设置为所有候选主节点的名字或IP地址。

新的集群协调子系统包含一个新的故障检测机制,这意味着老版本的集群子协调系统的 discovery.zen.fd.*所有故障检测设置不再具有任何效果。大多数用户应该使用7.0版本及更高版本的默认故障检测配置 cluster.fault_detection.*
我们在老版本中经常用到的三个检测机制为:

discovery.zen.fd.ping_timeout: 120s
discovery.zen.fd.ping_retries: 6
discovery.zen.fd.ping_interval: 15s

详细内容请看官网:https://www.elastic.co/cn/blog/a-new-era-for-cluster-coordination-in-elasticsearch

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