怎么解析大規模Elasticsearch集群管理

這篇文章將為大家詳細講解有關怎么解析大規模Elasticsearch集群管理，文章內容質量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

ElasticSearch目前在互聯網公司主要用于兩種應用場景，其一是用于構建業務的搜索功能模塊且多是垂直領域的搜索，數據量級一般在千萬至數十億這個級別;其二用于大規模數據的實時OLAP，經典的如ELKStack，數據規模可能達到千億或更多。  這兩種場景的數據索引和應用訪問模式上差異較大，在硬件選型和集群優化方面側重點也會有所不同。一般來說后一種場景屬于大數據范疇，數據量級和集群規模更大，在管理方面也更有挑戰。

目前我們最大的日志單集群有120個data node，運行于70臺物理服務器上。數據規模如下:

• 單日索引數據條數600億，新增索引文件25TB (含一個復制片則為50TB)

• 業務高峰期峰值索引速率維持在百萬條/秒

• 歷史數據保留時長根據業務需求制定，從10天 – 90天不等

• 集群共3441個索引、17000個分片、數據總量約9300億, 磁盤總消耗1PB

• Kibana用戶600多人, 每日來自Kibana和第三方的API調用共63萬次

• 查詢響應時間百分位 75%:0.160s 90%:1.640s 95%:6.691s 99%:14.0039s

運維這樣大規模的ES集群，有哪些值得注意的地方?

一. 必不可少的工具

工欲善其事必先利其器，從一開始，哪怕就只有幾個node，就應該使用分布式配置管理工具來做集群的部署。隨著應用的成熟，集群規模的逐步擴大，效率的提升會凸顯。  官方提供了ES Puppet Module和Chef Cookbook，熟悉這兩個工具的同學可以直接拿過來用。  我們自己則是采用的Ansible，編寫了一套Playbook來達到類似的效果。  用熟這類工具，對于集群的初始部署，配置批量更改，集群版本升級，重啟故障結點都會快捷和安全許多。

第二個必備利器就是sense插件。通過這個插件直接調用集群的restful  API，在做集群和索引的狀態查看，索引配置更改的時候非常方便。語法提示和自動補全功能更是實用，減少了翻看文檔的頻率。在Kibana5里面，sense已經成為一個內置的控制臺，無需額外安裝。

二. 硬件配置

我們采用的是32vcoreCPU + 128GB RAM的服務器，磁盤配置大部分服務器是12塊4TB  SATA機械磁盤做的Raid0，少部分機器是剛上了不久的6塊800GB SSD  raid0，主要目的是想做冷熱數據分離，后面談到集群架構的時候，再進一步解釋一下如何利用硬件資源。

三. 集群的管理

1. 首先很有必要對ES的結點做角色劃分和隔離。大家知道ES的data  node除了放數據以外，也可以兼任master和client的角色，多數同學會將這些角色混入到data  node。然而對于一個規模較大，用戶較多的集群，master和client在一些極端使用情況下可能會有性能瓶頸甚至內存溢出，從而使得共存的data  node故障。data  node的故障恢復涉及到數據的遷移，對集群資源有一定消耗，容易造成數據寫入延遲或者查詢減慢。如果將master和client獨立出來，一旦出現問題，重啟后幾乎是瞬間就恢復的，對用戶幾乎沒有任何影響。另外將這些角色獨立出來的以后，也將對應的計算資源消耗從data  node剝離出來，更容易掌握data node資源消耗與寫入量和查詢量之間的聯系，便于做容量管理和規劃。

2. 避免過高的并發，包括控制shard數量和threadpool的數量。在寫入量和查詢性能能夠滿足的前提下，為索引分配盡量少的分片。分片過多會帶來諸多負面影響，例如：每次查詢后需要匯總排序的數據更多;過多的并發帶來的線程切換造成過多的CPU損耗;索引的刪除和配置更新更慢Issue#18776;  過多的shard也帶來更多小的segment，而過多的小segment會帶來非常顯著的heap內存消耗，特別是如果查詢線程配置得很多的情況下。  配置過大的threadpool更是會產生很多詭異的性能問題Issue#18161里所描述的問題就是我們所經歷過的。  默認的Theadpool大小一般來說工作得很不錯了。

3. 冷熱數據最好做分離。對于日志型應用來說，一般是每天建立一個新索引，當天的熱索引在寫入的同時也會有較多的查詢。如果上面還存有比較長時間之前的冷數據，那么當用戶做大跨度的歷史數據查詢的時候，過多的磁盤IO和CPU消耗很容易拖慢寫入，造成數據的延遲。所以我們用了一部分機器來做冷數據的存儲，利用ES可以給結點配置自定義屬性的功能，為冷結點加上”boxtype”:”weak”的標識，每晚通過維護腳本更新冷數據的索引路由設置index.routing.allocation.{require|include|exclude}，讓數據自動向冷結點遷移。  冷數據的特性是不再寫入，用戶查的頻率較低，但量級可能很大。比如我們有個索引每天2TB，并且用戶要求保持過去90天數據隨時可查。保持這么大量的索引為open狀態，并非只消耗磁盤空間。ES為了快速訪問磁盤上的索引文件，需要在內存里駐留一些數據(索引文件的索引)，也就是所謂的segment  memory。稍微熟悉ES的同學知道，JVM heap分配不能超過32GB，對于我們128GB RAM,  48TB磁盤空間的機器而言，如果只跑一個ES實例，只能利用到32GB不到的heap，當heap快用飽和的時候，磁盤上保存的索引文件還不到10TB，這樣顯然是不經濟的。  因此我們決定在冷結點上跑3個ES實例，每個分配31GB heap空間，從而可以在一臺物理服務器上存儲30多TB的索引數據并保持open狀態，供用戶隨時搜索。  實際使用下來，由于冷數據搜索頻率不高，也沒有寫入，即時只剩余35GB內存給os做文件系統緩存，查詢性能還是可以滿足需求的。

4. 不同數據量級的shard最好隔離到不同組別的結點。  大家知道ES會自己平衡shard在集群的分布，這個自動平衡的邏輯主要考量三個因素。其一同一索引下的shard盡量分散到不同的結點;其二每個結點上的shard數量盡量接近;其三結點的磁盤有足夠的剩余空間。這個策略只能保證shard數量分布均勻，而并不能保證數據大小分布均勻。  實際應用中，我們有200多種索引，數據量級差別很大，大的一天幾個TB，小的一個月才幾個GB，并且每種類型的數據保留時長又千差萬別。拋出的問題，就是如何能比較平衡并充分的利用所有節點的資源。  針對這個問題，我們還是通過對結點添加屬性標簽來做分組，結合index  routing控制的方式來做一些精細化的控制。盡量讓不同量級的數據使用不同組別的結點，使得每個組內結點上的數據量比較容易自動平衡。

5. 定期做索引的force merge，并且最好是每個shard  merge成一個segment。前面提到過，heap消耗與segment數量也有關系，force merge可以顯著降低這種消耗。  如果merge成一個segment還有一個好處，就是對于terms aggregation，搜索時無需構造Global  Ordinals，可以提升聚合速度。

四. 版本選擇

我們在2.4版本上穩定跑了很長時間，比較保守的同學可以上2.4，激進有精力折騰的可以考慮最新的5.0。  我們集群兩周前從v2.4.0升級到了v5.0.0這個版本，除了升級第一周遇到一個不穩定的問題以外，感覺新版本帶來的以下特性還是非常值得去升級的:

• 結點啟動的Bootstrap過程加入了很多關鍵系統參數設置的核驗，比如Max File Descriptors, Memory Lock, Virtual  Memory設置等等，如果設置不正確會拒絕啟動并拋出異常。 與其帶著錯誤的系統參數啟動，并在日后造成性能問題，不如啟動失敗告知用戶問題，是個很好的設計!

• 索引性能提升。升級后在同樣索引速率下，我們看到cpu消耗下降非常明顯，除了對索引速率提升有幫助，也會一定程度提升搜索速率。

• 新的數值型數據結構，存儲空間更小，Range和地理位置計算更快速

• Instant Aggregation對于類似now-7d to  now這樣的范圍查詢聚合能夠做cache了，實際使用下來，效果明顯，用戶在Kibana上跑個過去一周數據的聚合，頭2次刷新慢點，之后有cache了幾乎就瞬間刷出!

• 更多的保護措施保證集群的穩定，比如對一次搜索hit的shard數量做了限制，增強了circuit  breaker的特性，更好的防護集群資源被壞查詢耗盡。

升級第一周，我們的冷數據結點出現間歇性不響應問題，從而刨出3個issue提交給官方:

Issue#21595 Issue#21612 Issue#21611

第一個問題確認為Bug，將在5.0.2修復，其他兩個目前還不清楚根源，看起來也只在我們的應用場景里遇到了。所幸問題都找到了了規避措施，實施這些措施以后，最近一周我們的集群重新回到以前2.4版本時期的穩定狀態。

五. 監控

不差錢沒空折騰的建議還是買官方的xpack省心，有精力折騰的，利用ES各種豐富的stats api，用自己熟悉的監控工具采集數據，可視化出來就好了。  那么多監控指標，最最關鍵的還是以下幾類:

• 各類Thread pool的使用情況，active/queue/reject可視化出來。  判斷集群是否有性能瓶頸了，看看業務高峰期各類queue是不是很高，reject是不是經常發生，基本可以做到心里有數。

• JVM的heap used%以及old GC的頻率，如果old GC頻率很高，并且多次GC過后heap  used%幾乎下不來，說明heap壓力太大，要考慮擴容了。(也有可能是有問題的查詢或者聚合造成的，需要結合用戶訪問記錄來判斷)。

• Segment memory大小和Segment的數量。節點上存放的索引較多的時候，這兩個指標就值得關注，要知道segment  memory是常駐heap不會被GC回收的，因此當heap壓力太大的時候，可以結合這個指標判斷是否是因為節點上存放的數據過多，需要擴容。Segement的數量也是比較關鍵的，如果小的segment非常多，比如有幾千，即使segment  memory本身不多，但是在搜索線程很多的情況下，依然會吃掉相當多的heap，原因是lucene為每個segment會在thread  local里記錄狀態信息，這塊的heap內存開銷和(segment數量* thread數量)相關。

• 很有必要記錄用戶的訪問記錄。我們只開放了http api給用戶，前置了一個nginx做http代理，將用戶第三方api的訪問記錄通過access  log全部記錄下來。通過分析訪問記錄，可以在集群出現性能問題時，快速找到問題根源，對于問題排查和性能優化都很有幫助。

關于怎么解析大規模Elasticsearch集群管理就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。