现象
ES集群,状态持续Yellow。出现部分replica一直在追primary的索引数据,追不上。线上提供服务出现慢查询,导致499量增大。
固定的几个ES节点(10.10.24.X网段),出现间歇性被踢出Cluster,随后又加入Cluster。这是导致出现yellow原因,并且一直不能恢复到Green状态。由于Master节点在10.10.19.X网段, 感觉起来就是2个网段之间不通了。
日志排查
1 | [2018-12-08T19:25:29,993][WARN ][o.e.x.s.t.n.SecurityNetty4Transport] [es35-search.mars.ljnode.com] write and flush on the network layer failed (channel: [id: 0x0e6ac038, L:0.0.0.0/0.0.0.0:8309 ! R:/10.200.24.96:46802]) |
提示信息是底层的netty channel关闭,导致节点状态不可达,抛出ReceiveTimeoutTransportException,因此被踢出集群。
网络情况排查
以上的情况,怀疑连接有问题,可能存在脑裂。找运维同学排查,查看网络状况。
通过监控图,首先可以排除网络断开。而整体的io吞吐,最高才只有150Mb(此处为bit),网络流量也不大。
线上复现
由于线上的集群规模较大,复现集群搭建了3台ES,并分布在2个不同的网段。
那如何模拟高IO呢?
选择了iperf命令,来模拟网络流量,其实iperf主要是用来测试网络带宽以及丢包测试用的,也许有其他更好的工具。
具体使用方式参考iperf命令。
果然在网络带宽被占满的时候,复现了上面的问题。但是当时线上并不高,这是什么原因。
在测试的时候,调试调用dstat命令,来观察真实的带宽。
可以看到,net带宽达到了117MB/s,已经把网络打满,这时我们在看运维的统计监控图:
观察19:00左右的值,当时已经达到了117MB,但是统计出来值是很低的。和运维沟通后,确认采样是30s的平均值,所以在5~10秒短时间带宽打满,并不会体现出来。一切都可以解释了,happy。
原因&解决
网络是千兆的网卡,这在高并发,高吞吐的系统中,带宽100MB/s是不能满足需求的,瓶颈找到,那就更换为万兆网卡。
网络拓扑图如上,其中交换机和机器直连的网卡进行升级来解决。
有没有优化的空间
假如,机器硬件资源有限,有没有一些办法来尽可能规避。
ElasticSearch针对recovery有速度限制,默认是40MB。如果一台机器部署多台(实际上,我们就是这样部署的),那这个值可能是倍增的,很容易打满。1
indices.recovery.max_bytes_per_sec: 10MB
减小上面的这个值,能够一定程度上缓解,由于recovery导致的持续带宽打满,并引起连锁反应。带宽满->节点掉->节点加入->recovery->带宽满->…
总结
网络带宽,应该在部署之前就进行充分的考虑和论证。根据不同的业务场景,选择不同的硬件配置。