ES 8.x的多实例集群搭建与角色规划

ES 8 多实例集群搭建与角色规划

ES 8版本与之前版本存在较大改变，第一个区别就是启动时默认开启了安全模式，也就是即便是测试环境也需要用户名密码和https传输层安全证书。此外，集群节点的角色也与之前不同，除了新增角色外在配置方式上也有所不同，而这些都与生产和业务息息相关，必须对此有清晰的认识，掌握使用方法。

集群节点发现

集群互连，重中之重！

在大多数情况下，发现和选举过程会迅速完成，并且主节点会长时间保持当选状态。

如果集群没有稳定的主节点，其许多功能将无法正常工作，并且Elasticsearch将会向客户端报告错误并在日志中记录。必须先修复主节点的不稳定问题，才能解决其他相关问题。在没有选出主节点或当前选出的主节点不稳定的情况下，解决任何其他问题都是不可能的。

如果集群有一个稳定的主节点，但部分节点无法发现或加入该主节点，那么这些节点将会向客户端报告错误并在它们的日志中记录。必须首先解决阻碍这些节点加入集群的问题，然后才能着手处理其他问题。在这些节点无法成功加入集群的情况下，解决它们所报告的任何其他问题是不可能的。

启动第一个节点

第一个节点很重要，不能设置这个节点的角色，否则很可能启动不了安全模式，也不能设置它的端口号之类的，否则启动不了https。最后只改了节点name和集群名称（官方文档给的提示是不做任何更改解压后可直接启动，显然，我们至少需要改个名字）。

以下全部是我进行的参数组合测试的情况（首次启动）：

如果继续设置了角色master，端口号以及初始master节点列表，就不会自动开启ssl模式了，但此时多节点无法互联成集群，密码无法更新：ERROR: Failed to determine the health of the cluster. Unexpected http status [503]。

上述6个值以外如果还额外指定了Transport Host的值，比如4个0，启动就会直接报错： node validation exception，Transport SSL must be enabled。

如果指定了集群名，节点名以及角色这3个配置，节点可以启动，密码修改失败：ERROR: Failed to reset password for the [elastic] user, with exit code 75。

如果仅指定两个名称和Transport Host的这3个参数值，测试了也可以完全正常启动！

如果仅指定两个名和两个端口号共4个参数值，正常！

如果指定两个名和两个端口号和Transport host这5个参数，正常！

综上，不可以指定的是角色和初始化列表！

正常启动后，这个节点是主节点（它是一个集11种角色于一身的全能高手）：

[node-1-master] This node is a fully-formed single-node cluster with cluster UUID [Ysiu2anmSp2kO13Wb0jAcw],  but it is configured as if to discover other nodes and form a multi-node cluster via the [discovery.seed_hosts=[10.11.22.33:9300]] setting.  Fully-formed clusters do not attempt to discover other nodes, and nodes with different cluster UUIDs cannot belong to the same cluster.  The cluster UUID persists across restarts and can only be changed by deleting the contents of the node's data path(s).  Remove the discovery configuration to suppress this message. 

[node-1-master] 这个节点已经形成了一个完整的单节点集群，集群UUID为[Ysiu2anmSp2kO13Wb0jAcw]，但是其配置却表明它试图通过[discovery.seed_hosts=[10.11.22.33:9300]]设置去发现其他节点并形成一个多节点集群。完整形成的单节点集群不会尝试去发现其他节点，并且具有不同集群UUID的节点不能属于同一集群。集群UUID在重启后会持久存在，只能通过删除节点数据路径的内容来更改。要消除这个警告消息，请移除关于发现节点的相关配置。

节点发现配置迷局

反复在本地各种改配置，删除数据，重启，无奈本地的多个节点就是无法形成集群。

• 后面发现将发现配置中使用的hostname改为ip地址可以成功互联互通。关于这一点，官方文档提示的是应该使用node.name。

• 以下全部配置项的前提是多实例的文件都是从本机master服务拷贝来的，也就是https证书在本机上是一样（跨机器行不通，见不识别SSL证书问题的处理）。

在处理其他机器上的服务加入集群时发现直接带证书拷贝过去时无法完成ssl校验的，这也可能与双网有关，不过根据ES 7版本的经验，跨节点的证书需要自行生成，不能直接复制使用。

期间有ES集群不识别节点SSL证书的问题处理，参考我其他文章。

ES节点SSL问题处理-链接

实例自有配置

以下配置要与其他节点不同（名称、数据和日志路径，两个端口号），每个ES服务实例都是独一份。

node.name: node-1-node2  path.data: /path/to/data2 path.logs: /path/to/logs  http.port: 9202 transport.port: 9302 

master节点特有配置

cluster.initial_master_nodes: ["10.11.22.33:9300"] node.roles: [ master，ingest ] 

data类节点特有配置

discovery.seed_hosts: ["10.11.22.33:9300"] node.roles: [ data, ingest ] 

终于理清了，理的令人烦躁，软件能够开箱即用真是很强大的优势。

角色的变更

如果我修改了节点的角色，再次启动时就会报错。如下是从master、data等角色的一个实例修改为仅master节点的启动失败信息：

fatal exception while booting Elasticsearchjava.lang.IllegalStateException:  node does not have the data role but has shard data: [/opt/es811/master/data/indices/_eWDGVvGTM2aqNjcYBvK5w/0].  Use 'elasticsearch-node repurpose' tool to clean up 

提示说使用elasticsearch-node repurpose工具进行清理。

执行该命令，返回确认信息：

... Node is being re-purposed as master and no-data. Clean-up of shard data will be performed. Do you want to proceed? Confirm [y/N] y Node successfully repurposed to master and no-data. 

警告：这会删除本实例持有的全部数据。

然后再次启动该节点，启动成功，节点已经改变为纯master节点，不再保存数据。

{   "cluster_name" : "my-app-es",   "status" : "green",   "timed_out" : false,   "number_of_nodes" : 3,   "number_of_data_nodes" : 2,   "active_primary_shards" : 1,   "active_shards" : 2,   "relocating_shards" : 0,   "initializing_shards" : 0,   "unassigned_shards" : 0,   "delayed_unassigned_shards" : 0,   "number_of_pending_tasks" : 0,   "number_of_in_flight_fetch" : 0,   "task_max_waiting_in_queue_millis" : 0,   "active_shards_percent_as_number" : 100.0 } 

如下图，目前集群为3个节点，1个master，2个data节点，均可作为ingest节点：

第二行的master节点的role为im，也就是ingest和master。

关于master的HA注意事项

另外注意：如果设置了2个master的话，其中一个挂掉，另一个无法被选举为master。当我安装了3个master时，可以自动切换。

官方说法是为了确保集群始终保持可用状态，必须确保不同时停止投票配置中一半或更多的节点。只要超过半数的投票节点在线，集群就能正常运作。这意味着，如果有三个或四个候选主节点，集群就能够容忍其中一个节点不可用；而如果只有两个或更少的候选主节点，则所有节点都必须保持可用状态。

在测试主节点切换时发现cluster.initial_master_nodes这个参数不能防止脑裂，或者值设置不对，关闭后单独启动ES master服务时这个服务没有加入集群，修改加入seed_hosts后才正常加入了原集群。

集群自动化启动流程（ES 8）

1. 启动第一个主节点，不能包含任何发现信息安全配置，可以指定端口和ip（会成为独立集群，获得UUID）；
2. 其他服务不要修改安全及发现相关配置，只改名称、角色、端口，ip这些；
3. 在主节点生成node token；
4. 其他服务启动时指定token加入集群（仅首次启动有效）；
5. 上述步骤会在服务config中自动生成证书、创建安全及seeds相关的配置；
6. 全部启动完毕后检查集群健康状态；
7. 根据需要，将master节点的配置统一格式；
8. 根据需要，将data节点的配置统一格式（discovery.seed_hosts）；
9. 最后，集群节点全部重启！

启动流程优化?

上面的优势是你不需要再处理CA、https证书以及xpack相关的配置了，集群节点全都会自动配置，否则自己配置也是不少差事。

但是否可以先启动一个主节点，然后其他索引节点均设置好静态配置，待主节点启动完成，获取token后再全部批量启动？

试了不奏效，token方式启动需要比较干净的配置文件，不能改太多配置。

在处理之前SSL相关问题时也发现证书有效期只有2年左右，这是需要注意的点！