怎么解析大規(guī)模Elasticsearch集群管理

這篇文章將為大家詳細(xì)講解有關(guān)怎么解析大規(guī)模Elasticsearch集群管理，文章內(nèi)容質(zhì)量較高，因此小編分享給大家做個(gè)參考，希望大家閱讀完這篇文章后對(duì)相關(guān)知識(shí)有一定的了解。

ElasticSearch目前在互聯(lián)網(wǎng)公司主要用于兩種應(yīng)用場景，其一是用于構(gòu)建業(yè)務(wù)的搜索功能模塊且多是垂直領(lǐng)域的搜索，數(shù)據(jù)量級(jí)一般在千萬至數(shù)十億這個(gè)級(jí)別;其二用于大規(guī)模數(shù)據(jù)的實(shí)時(shí)OLAP，經(jīng)典的如ELKStack，數(shù)據(jù)規(guī)模可能達(dá)到千億或更多。  這兩種場景的數(shù)據(jù)索引和應(yīng)用訪問模式上差異較大，在硬件選型和集群優(yōu)化方面?zhèn)戎攸c(diǎn)也會(huì)有所不同。一般來說后一種場景屬于大數(shù)據(jù)范疇，數(shù)據(jù)量級(jí)和集群規(guī)模更大，在管理方面也更有挑戰(zhàn)。

目前我們最大的日志單集群有120個(gè)data node，運(yùn)行于70臺(tái)物理服務(wù)器上。數(shù)據(jù)規(guī)模如下:

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

• 業(yè)務(wù)高峰期峰值索引速率維持在百萬條/秒

• 歷史數(shù)據(jù)保留時(shí)長根據(jù)業(yè)務(wù)需求制定，從10天 – 90天不等

• 集群共3441個(gè)索引、17000個(gè)分片、數(shù)據(jù)總量約9300億, 磁盤總消耗1PB

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

• 查詢響應(yīng)時(shí)間百分位 75%:0.160s 90%:1.640s 95%:6.691s 99%:14.0039s

運(yùn)維這樣大規(guī)模的ES集群，有哪些值得注意的地方?

一. 必不可少的工具

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

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

二. 硬件配置

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

三. 集群的管理

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

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

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

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

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

四. 版本選擇

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

• 結(jié)點(diǎn)啟動(dòng)的Bootstrap過程加入了很多關(guān)鍵系統(tǒng)參數(shù)設(shè)置的核驗(yàn)，比如Max File Descriptors, Memory Lock, Virtual  Memory設(shè)置等等，如果設(shè)置不正確會(huì)拒絕啟動(dòng)并拋出異常。 與其帶著錯(cuò)誤的系統(tǒng)參數(shù)啟動(dòng)，并在日后造成性能問題，不如啟動(dòng)失敗告知用戶問題，是個(gè)很好的設(shè)計(jì)!

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

• 新的數(shù)值型數(shù)據(jù)結(jié)構(gòu)，存儲(chǔ)空間更小，Range和地理位置計(jì)算更快速

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

• 更多的保護(hù)措施保證集群的穩(wěn)定，比如對(duì)一次搜索hit的shard數(shù)量做了限制，增強(qiáng)了circuit  breaker的特性，更好的防護(hù)集群資源被壞查詢耗盡。

升級(jí)第一周，我們的冷數(shù)據(jù)結(jié)點(diǎn)出現(xiàn)間歇性不響應(yīng)問題，從而刨出3個(gè)issue提交給官方:

Issue#21595 Issue#21612 Issue#21611

第一個(gè)問題確認(rèn)為Bug，將在5.0.2修復(fù)，其他兩個(gè)目前還不清楚根源，看起來也只在我們的應(yīng)用場景里遇到了。所幸問題都找到了了規(guī)避措施，實(shí)施這些措施以后，最近一周我們的集群重新回到以前2.4版本時(shí)期的穩(wěn)定狀態(tài)。

五. 監(jiān)控

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

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

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

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

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

關(guān)于怎么解析大規(guī)模Elasticsearch集群管理就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，可以學(xué)到更多知識(shí)。如果覺得文章不錯(cuò)，可以把它分享出去讓更多的人看到。