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

结束