ES7.17由于IP变化导致的故障及恢复

背景 

1. k8s 升级,导致环境中的ES集群(7.17版本)重启

2. 集群由于在公有云环境,IP不固定(重启后IP可能发生变化),通过 svc 进行访问

curl xxx-master-svc:9200/_cat/health

3. 由多个sts一起维护一个ES集群(非operator的模式)

xxx-master

xxx-ingest

xxx-data

注:一般开源的ES,无论在虚拟机还是容器中部署,最佳实践还是固定IP;

4. 集群重启之后,状态变成了 red

分析

1. 初步发现是掉了2个节点(_cat/nodes),元信息还可以访问,总体表现为red

2. 发现data节点无法加入集群,新扩出来的节点也无法加入集群

    - 排除网络影响,节点之间都是通的

    - 无法加入的节点 local:9200/ 发现节点活着,但是 cluster_uuid: "_na_"(空)

    - 对节点进行 unsafe的 detach 操作,脱离集群,重启(依然无法加入集群)

3.  日志(异常的data节点)表现为 `master not discovered or elected yet, an election requires at least 2 nodes with ids from`,以及各种访问master超时;

日志中打印的IP地址是先有master节点的IP(不存在IP错误)

4. 发现data节点存在readinessProbe策略(sts),要求_cluster/health=yellow才可以存活,将其改成red,依然无法加入集群

5. data节点无法加入集群,这里尝试修改data节点的配置,强行指定master的地址。结果data节点重启后依然无法加入集群。

cluster.initial_master_nodes: "xxx-master-1, xxx-master-2, ..."

注:

## 为了保证安全,对sts进行如下操作,对sts管理的部分节点生效(此处表示 pod 编号大于等于2 的才会执行操作,如果要sts管理的全部节点生效,改成0即可,或者去掉该配置)

updateStrategy:
 rollingUpdate:
   partition: 2
type: RollingUpdate

6. 发现“正常”节点(master/ingest)的_cat/nodes命令的结果中包含个别data节点

    - 反复确认过,在全部的data节点,都无法访问集群元信息(没加入集群)

    - 怀疑元数据异常,整个集群已经挂了(没有形成集群)

7. 节点无法形成集群,一般有2种方法

    - 方案1: (unsafe)detach

su elasticsearch -g root

./bin/elasticsearch-node unsafe-bootstrap

./bin/elasticsearch-node detach-cluster

    - 方案2: 对全部master候选节点的配置进行修改,重启,重新形成集群

Bootstrapping a cluster | Elasticsearch Guide [7.17] | Elastic

cluster.initial_master_nodes: "xxx-master-1, xxx-master-2, ..."

解决方案

使用上面描述的方案2;

具体流程如下:

1. (容器环境才需要考虑)修改 readinessProbe,_cluster/health 需要访问元数据信息,集群已经挂掉的情况下不合理(由于集群已经挂了,所以会一直阻塞),这里改成 check 9200 端口(只需要访问本地进程/端口)。

2. 修改master节点的 initial_master_nodes 配置,指定master节点的节点name列表。

注:容器环境中滚动重启即可,不需要同时重启

疑惑

1.  如果是滚动重启,即使IP发生变化,ES也可以感知到,除非是一次重启多个节点(修改多个IP),比如超过一半的master节点,那么无法形成集群(k8s升级工艺已经无法追溯......)

2.  如果短时间太多节点变化IP,无法形成集群,为什么有些节点可以访问元数据( _cat/health,_cat/nodes 等),而不是全部节点访问ES集群元数据都是503.

(可能极端情况触发了ES的bug,该现象对前期排障造成巨大干扰。)


 

你可能感兴趣的:(java,docker,kubernetes,elasticsearch,排障)