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

结束

posted @ 2016-11-30 11:39  Richaaaard  阅读(2277)  评论(0编辑  收藏  举报