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

結束