一次系统扩容引起的elasticsearch故障及恢复

Posted 2023-04-19

参考技术A 在公司搭建了elk集群，集群配置如下：

由于m21p22服务器配置比较老旧，而且上面还有其他人部署的其他应用。硬盘写入性能比较差，因此考虑吧elasticsearch部署在另外两台配置高的服务器，而将kibana、redis等与硬盘关系不大的软件部署在m21p22服务器。考虑到部署的复杂性以及服务器的实际情况，选择了redis接收beats的日志数据，再通过logstash实现负载均衡。这是之前elk集群的配置情况。
随着业务的深入，上述集群已经越来越难以满足业务的需要，日志量大会在redis中出现堆积，另外服务器查询量大之后，节点的cpu和load会触发告警。因此，与运维部门商议，又申请了2台服务器，作为elasticsearch的扩展节点，以降低原有服务器的负载。
如下是增加服务器之后的配置信息：

在新增加服务器到位之后，第一件事情就是决定将elasticsearch扩容。每台服务器部署2个节点，将原有集群扩大一倍，由4个节点扩大到8个节点。

原有节点：

扩展节点：

按上述配置对新增节点进行扩展，只需要配置好参数：
discovery.zen.ping.unicast.hosts: ["192.168.21.23", "192.168.21.24","192.168.21.88","192.168.21.89"]
新增节点就可以加入集群进行水平扩容。当上述操作都完成之后，新节点已加入集群，开始同步数据。

考虑到系统并未设置索引分片，全部索引一律采用的是系统默认的5个分片，而每个索引的数据可能大小不一，结果检查，决定将数据量较大的索引，分片数增加一倍。
操作如下：

注意，在采取put操作时，先采用get操作，得到_template信息，之后对需要修改的部分进行增加或者修改操作，之后再进行put。这样保证其他不需要修改的数据不会被修改。

在做完上述这一切之后，已是晚上8点，因此打卡下班。

早上还没到单位，就被同事信息轰炸，elk集群已经不能用了！！
我赶到单位之后，连上服务器一看，新加入的节点全部处于假死状态。已经有大部分数据同步到新节点，而且服务器已无法连接。通知运维人员将elasticsearch进程干掉。
如下是恢复的过程中某个节点假死查到的状态：

对上述节点进行重启，集群状态恢复中。。

redis内存在迅速增加，已经达到10个G

查看logstash日志：

出现如下提示：

原来是宕机节点太多，导致部分节点的主分片未分配。这样日志在写入过程中会超时。这就导致logstash的写入速度下降。从而导致redis中数据增加。

至于节点假死的原因，查看了elasticsearch的日志：

发现一个关键的问题：/opt/elasticsearch/node6/data/nodes/0/indices/NP2tORUfSq6jl0lb5CzOVw/2/translog/translog.ckp: Too many open files in system
也就是说同时打开的文件数达到了系统的限制，这也就是无法登陆系统的原因。
不难理解上述问题的出现：一个服务器中配置了两个节点，这两个节点都运行在elastic用户下，该用户所在系统的limit.conf中对该用户同时打开的文件数有限制。而在集群同步数据的过程中，系统在大量的写文件，同时实时数据又在大量写入。这样就导致文件达到最大的阈值。因此导致elasticsearch假死。

查询elasticsearch节点状态：

当天需要写入数据的索引，也存在部分分片未分配状态：

通过kibana也可发现该问题：

考虑到redis缓存一直增加，当务之急是让数据可以写入。保证redis的数据被消费。否则会出现redis服务器内存溢出。
先不考虑elasticsearch是否能自动恢复，以及自动恢复所花费的时间。
查询API后，要用到命令：reroute
通过kibana分配一个主分片

命令格式参考 https://kibana.logstash.es/content/elasticsearch/principle/shard-allocate.html

需要注意的是，对于主分片执行reroute，一定需要所分配的节点上存在该索引的文件，否则会提示找不到索引：

在分配主分片的时候，一定要确认所分配的节点是否存在该索引的文件。

上述问题 虽然恢复，数据可以写入，但是还有几个地方需要优化：
1.redis作为负载均衡存在问题，在服务器节点充足之后，应该用kafka来替代redis，将数据放置在磁盘。避免redis内存溢出。
2.elasticsearch扩容时，如果有多个节点，尽量避免同时操作。如果一次性增加的节点比较多，就需要考虑文件是否达到最大limit配置的阈值。

光模块故障的主要原因及解决办法

客户在使用光模块时或多或少会遇到各种各样的故障问题，其中比较常见的故障就是链路不通和丢包，本文将重点讲解引起光模块故障的原因及解决办法。

一、不通
1、光口污染和损伤引起的光链路不通：光模块如果不使用的情况下必须盖好防尘帽，避免灰尘污染光口引起链路不通。
2、光纤连接器端面污染或故障：光纤连接器在网络的安装、调试及维护过程中，往往会经历多次的插拔过程。而在这一过程中，经常会由于操作人员不注意对连接器端面的防护，导致光纤端面受到污染，从而影响到光链路传输性能的下降，严重时会导致整个光纤链路的瘫痪
3、ESD损伤：静电会吸附灰尘，改变线路间的阻抗，影响光模块的功能与寿命。
4、使用劣质模块：劣质的光模块会存在不通、丢包、传输不稳定、光衰大等问题
5、对端光模块波长、模式不匹配：光模块的波长需要在每一端进行匹配，波长不匹配可能会导致数据在传输过程中丢失。另外，光模块的工作模式也应在两端匹配，全双工光模块应与全双工光模块配对
6、发射、接收光功率过高或过低：查看对端设备的光模块光功率是否正常，发射光功率值不得少于最小光功率值
7、光纤不匹配：在没有多余单模光纤的情况下，多模光纤可以配合单模光模块使用，但最好单模模块对应单模光纤，多模模块对应多模光纤。
8、光纤模块的金手指导电金属缺失：金手指的缺失会造成光纤模块无法正常使用。不合格光纤模块的金手指导电金属缺失,并且光泽明显不够。
二、丢包
1、光模块和设备的电子功能电路不匹配；
2、主芯片和设备不匹配；
3、物理线路故障；
4、设备故障；
5、路由信息错误；

综上所述，为了大大减少光模块在使用中故障发生的概率，最好选用性能可靠稳定且品质有保障的光模块，与此同时，也要懂得正确专业的操作方式，如网线或光纤跳线和其他相关设备等。