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
