ELK 性能(2) — 如何在大业务量下保持 Elasticsearch 集群的稳定

ELK 性能(2) — 如何在大业务量下保持 Elasticsearch 集群的稳定

介绍

如何在大业务量下保持 Elasticsearch 集群的稳定？

内容

当我们使用 Elasticsearch 时，期望获得的是

集群的问题

快速的搜索

设想我们有一个论坛的数据需要索引存储到 Elasticsearch 里

每个用户的个人信息

讨论与评论

以及用户形成的组与圈子

Server 1	Server 2	Server 3
C-D-(M)	C-D-M*	C-D-(M)

对于以上每个服务器 1、2、3：

CPU:	10 phyical cores @ 2.80GHz
RAM:	256GB or more ...
Disques:	SSD 300GB or more ...

C  = Client
D  = Data
M* = Elected Master
M  = Eligible as Master

峰值出现在下午 5 点，有 75% 的用户同时在线，操作包括：

发布与评论

搜索讨论与文件

个人信息的更新

创建与加入新的组或圈子

加入感兴趣的话题并讨论

下午 5 点发生了什么？

堆内存骤然升高

由于 CPU 的占用提升，GC 增加

为了解决这样类似的问题，我们需要改变底层的架构以及请求方式。

多米诺效应

Server 1	Server 2	Server 3
C-D-(M)	C-D-M* (不可用)	C-D-(M)

如果当前节点是主节点，当 JVM 在几秒内无法响应时，会发生新的选举。而相同的问题在新的主节点选举完成后立即会发生，这会导致集群不稳定。

解决方案

分而治之


虚拟化

不要为堆分配

设置

cluster.routing.allocation.same_shard.host

如何组织这些节点？

主节点：

主节点管理并反映一个集群的真实状态。

客户端节点：（只为客户端节点开放 HTTP）

客户端节点将数据节点保护在防火墙之后，只有客户端节点可以被外部访问。

客户端节点知道数据存储的位置，并且可以查询正确的片（shard）归并结果并返回。

数据节点：

只有数据节点存储数据，用它们来索引并搜索。

小技巧

将最小节点的数量（minimum number of eligible nodes）设置为 2 ，这样当节点丢失一个主节点时，整个集群还可以正常工作。

为了让 Elasticsearch 能够平滑的运作，不要将所有的系统内存都分配给 JVM ：需要可用的内存让文件系统缓存使用，这样磁盘存取会更快。

为特定的主节点分配较小的堆（例如，1GB 可能就足够了），这样它们就不会因为 GC 的停顿受到很大影响。

如何计算分片（shard）大小？

由场景决定。

保持分片（shard）的平衡

在以上的场景中，我们会保持每个分片（shard）大小在 1 到 4GB ，这样查询速度会比较快，在重启或者节点宕掉的时候分片重排也会比较快。



当分片增长到很大时，我么可以选择为 Elasticsearch 重建整个索引并设置更多的分片，可以进行横向扩展，或者根据（时间段，用户）拆分索引。

参考

参考来源:

2016.4 Camilo Sierra - How to get a stable Elasticsearch cluster in high traffic website

结束