关于 Elasticsearch 集群核心配置，腾讯大佬的灵魂9问，你能接住

题记

这是一位腾讯大佬 2020年4月份在死磕 Elasticsearch技术交流微信群里发起讨论的问题，之前初步讨论了答案，但是不够细或者说讲解不透，所以一直没有成文。

 

这一次，加上了实践验证，说透。

 

1、上问题

还是没太搞懂 seed_hosts 和 cluster.initial_master_nodes 的区别。

 

 •  1、 seed_hosts里面一定是配置 master eligible节点吗?

 •  2、还是说data节点也可以配置到 master eligible

 •  3、是如何发现潜在机器的呢?

 •  4、initial_master一定是master eligible节点吧?

 •  5、集群初始启动时, 这几个节点一定都要在是吗?

 •  6 、初始的时候是不是可以配置一个, 然后集群初始化后, 再加master eligible节点也可以的是吗?

 •  7 、多加几个以后, 把initial_master里的几个去掉是不是也可以了?

 •  8、如果一个集群当前master为7，那他的quorum是4。es 是支持慢慢去掉节点，quorum慢慢降低的吗？

 

 •  9、 那假如慢慢去掉了3个节点，原集群正常工作，那这三个节点重启后网络分区在一起了，那会不会自己形成集群啊？

 

希望大佬们点拨一下... ...

 

2、拆解一把

问题的核心是：seed_host 和 cluster.initial_master_nodes 的区别？

 

2.0 认知前提

为避免认知偏差，将常用英文词汇做基础释义：

 

 •  Discovery ：发现是节点间在形成集群之前发现其他节点的过程。当你启动Elasticsearch节点时，或者当节点认为主节点发生故障时，此过程将运行，并持续到找到主节点或选择新的主节点为止。

 

 •  master-eligible nodes：候选主节点

 

 •  master-ineligible nodes：非候选主节点

 

 •  coordinating-only nodes：仅协调节点

 

 •  data-only nodes：仅数据节点

 

 •  seed hosts providers：种子主机列表

 

 •  voting configuration：投票配置

 

 •  split brain：脑裂

 

 •  initial quorum：初始仲裁——仅在整个集群首次启动时才需要初始仲裁

2.1 主节点职责

主节点负责集群范围内的轻量级操作，例如：

 

 •  创建或删除索引

 •  跟踪哪些节点是集群的一部分

 •  确定将哪些分片分配给哪些节点。

拥有稳定的主节点对于集群健康非常重要。

 

候选主节点通过主选举过程成为主节点。

 

一个集群中：选举后只有一个主节点。

 

2.2 脑裂

以下脑裂是我的通俗解释：

 

假设在 2.1 选举主节点过程中，一个集群中出现了 2个或者2个以上的主节点，也就是说一个集群形式上划分为两个或两个以上的孤立集群，这就被称为脑裂。

 

2.3 候选主节点两大基本任务

候选主节点必须合力完成的两个基本任务：

 

 •  选举主节点

 •  更改集群状态

即时某些节点故障，也要保住以上两活动正常运行。

 

2.4 投票配置

每个 Elasticsearch 集群都有一组投票配置，这是一组候选主节点的集合。

 

什么时候使用呢？

 

 •  第一：选举主节点；

 •  第二：提交新的集群状态。

什么时候做决策？——仅在投票配置中超过一半节点做出响应后才做决策。

 

通常：投票配置和集群中所有候选主节点集合相同。但，某些情况下可以不同。

 

以下是要强调的也是被问最多的问题之一：

 

 •  为确保集群仍然可用，请勿同时停止投票配置中的一半或更多节点。

 •  只要有一半以上的投票节点可用，集群就可以正常工作。

例如：

 

 •  如果有三个或四个候选主机节点，则集群可以容忍一个候选主节点不可用。

 •  如果有两个或更少的候选主节点，则它们必须全部保持可用。

后面的实战验证举例，你会进一步看到结论。

 

2.5 集群规划时设置奇数个候选主节点

集群中通常应有奇数个候选主节点。

 

如果有偶数个，Elasticsearch将其中一个排除在投票配置之外，以确保其大小为奇数。

 

换种通俗说法：

 

4个候选主节点和3个候选主节点本质一样，只容许一个候选主节点失效。

 

2.6 discovery.seed_hosts  和 initial_master_nodes 作用

 •  discovery.seed_hosts 的来龙去脉

6.X 5.X对应名字：discovery.zen.ping.unicast.hosts。

 

看如下截图，对比：除了名称不同，释义部分一模一样。

如果多节点集群，discovery.seed_hosts 应该配置为候选主节点。

 

 •  cluster.initial_master_nodes

这也是7.X的特性，区别于之前设置min_master_count候选主节点的个数。

 

白话文：设置候选主机节点的主机名称列表。

 

在7.x节点上，discovery.zen.minimum_master_nodes设置是允许的，但被忽略。

 

集群首次启动的时候，cluster.initial_master_nodes 必须设置为执行集群引导。

 

在集群初始化阶段，cluster.initial_master_nodes 应该包含候选主节点的名称，并在集群中每个候选主节点上进行定义。

 

本质区别：

 

 •  cluster.initial_master_nodes：仅在集群首次启动会使用。
 •  discovery.seed_hosts：每次启动都需要。

2.7 Discovery 过程解读

Discovery 过程从一个或多个种子主机列表以及集群中已知的任何一个候选主节点地址开始。

 

该过程分两个阶段进行：

 

 •  首先，探测种子地址。

每个节点通过连接到每个地址并尝试识别其连接的节点是否是候选主节点来探测种子地址。

 

 •  其次，如果成功，它将与远程节点共享其所有已知的候选主机节点列表，并且远程节点将依次与其做对等回应。

然后，该节点将探测刚刚发现的所有新节点，请求其对等节点，依此类推。

 

如果该节点不是候选主节点，则它将继续此 Discovery 过程，直到发现了选举的主节点为止。如果未发现选择的主节点，则该节点将在默认值为 1s 之后重试。

 

如果该节点是候选主节点，则它将继续此 Discovery 过程，直到它找到了选举的主节点，或者它找到了足够的候选主节点来完成选举。同样的，如果这两种方法都没有很快的进行，则该节点将在 1s 后重试。

 

这里有点绕，需要结合英文文档多读几遍，加深 Discovery 理解。

 

2.8 elasticsearch.yml 配置注意
现在，7.X Elasticsearch 的生产部署需要至少在 elasticsearch.yml 配置文件中指定以下设置之一：

 

 •  discovery.seed_hosts
 •  discovery.seed_providers
 •  cluster.initial_master_nodes
 •  discovery.zen.ping.unicast.hosts
 •  discovery.zen.hosts_provider

2.9  非候选主节点在 discovery  阶段被忽略

在 7.X 之前早期版本中，有可能在 discovery 过程中使用非候选主节点作为种子节点或在符合条件的主机之间间接传输信息。

 

像这样的依赖非候选主节点的集群非常脆弱，无法自动从某些故障中恢复。

 

7.X 版本之后，discovery 仅涉及集群中候选主节点，不会像早期版本一样依赖于非候选主节点。

 

如何在7.X 中配置呢？应该在配置中将  discovery.seed_hosts 或者  discovery.seed_providers 设置为所有候选主节点的地址。

 

2.10 关于故障检测超时时间

7.X 默认情况下，如果集群节点未能响应 3 个连续的 ping（每个 ping 在 10 秒后超时），则集群故障检测子系统现在将其视为故障节点。

 

因此，响应时间超过 30 秒 的节点可能会从集群中删除。

 

7.X 以前，每个ping的默认超时为 30 秒，因此，无响应的节点可能会在集群中保留 90 秒以上。

 

2.11  删除候选主节点有时需要做排除投票

 

如果你希望从集群中删除一半或更多的候选主节点，则必须首先使用投票配置排除API从投票配置中排除受影响的节点。

 

排除 API 如下：

如果你同时删除少于一半的候选主节点，则不需要做投票排除。

 

如果仅删除非候选主节点（例如仅数据节点或仅协调节点），则不需要做投票排除。

 

同样，如果将节点添加到集群，也不需要投票排除。

 

3、实践一把

3.1 场景1：一主节点、一仅数据节点

数据节点配置：

 •  seed host 和  initial_master_nodes 只设置主节点配置。

结果如下：

3.2 场景二：一主节点、二仅数据节点
两个数据节点配置：

 
3.3 场景三：三个节点都是主节点同时也是数据节点

三节点相同配置如下：

注意，这时候，我把node-1 强制杀掉？大家猜会发生什么？

 

如果说宕机，你错了！集群进行了重新选主：

结果如下：节点2 成为主节点。

实际业务场景不建议这么做，数据节点在没有设置主节点角色：node.master: true 的前提下，成为了主节点。

 

3.4 场景四：三个节点都是主节点同时也是数据节点

三节点相同配置如下：

逐个kill 掉 节点2、节点 1 看看结果？

 

先干掉节点2：节点1成为了主节点。

这个时候，错误日志如下：

 

核心错误说明：候选主节点要求至少 2个节点。

 

an election requires at least 2 nodes  .....  which is not a quorum.

 

详细报错如下：

正如官方文档所示：

 

为确保集群仍然可用，你不得同时停止投票配置中的一半或更多节点。只要有一半以上的投票节点可用，集群可以正常工作。

如前所述：投票配置中配置的就是候选主节点！

 

3.5 场景五：三个节点都是主节点同时也是数据节点

在老配置基础上修改，注释掉：initial_master_nodes 的配置。配置如下：

集群也能正常启动。结合 2.6 小节看能更好理解一些。

 

4、再回答腾讯大佬的问题

 •  1、 seed_hosts里面一定是配置 master eligible节点吗?

是的，必须候选主节点。

 

 •  2、还是说data节点也可以配置到 master eligible

理论可以，实际不推荐。

 

 •  3、是如何发现潜在机器的呢?

Discovery 过程就是发现过程。

 

 •  4、initial_master一定是master eligible节点吧?

是的。

 

 •  5、集群初始启动时, 这几个节点一定都要在是吗?

大规模集群要注意：集群规划阶段要考虑设置：奇数个候选主节点。

 

集群初始启动阶段之前候选主节点配置要设置合理。

 

 •  6 、初始的时候是不是可以配置一个, 然后集群初始化后, 再加master eligible节点也可以的是吗?

可以，但不推荐。

 

如果多节点集群，建议一步到位。

 

 •  7 、多加几个以后, 把initial_master里的几个去掉是不是也可以了?

仅在集群首次启动会使用，其他阶段可以去掉。详见案例五。

 

不过，规范管理起见，配置上不用动就可以了。

 

 •  8、如果一个集群当前master为7，那他的quorum是4。es 是支持慢慢去掉节点，quorum慢慢降低的吗？

换个思维理解，这里如果有 7 个候选主节点，意味着至少要一半以上有效集群才能存活。

 

也就是干掉3个候选主节点，集群依然是存活状态的。

 

 •  9、 那假如慢慢去掉了3个节点，原集群正常工作，那这三个节点重启后网络分区在一起了，那会不会自己形成集群啊？

 

不会，去掉的3个节点，还会继续加入原来的集群啊！

 

5、小结

类似概念的确单纯看文档不好理解，甚至你看完本文还是有点糊涂。

 

不要为了区分概念而区分概念，实践一把，把理论概念转成实践、再结合理论，就好理解了。