1小時ElasticSearch求生指南

先給出葵花寶典心法口訣：

    節點發現很重要，避免腦裂保平安；出現問題快踢掉，不然查詢好不了

    自動恢復要慎重，過於倉促反很差，分片移動成本高，可以避免是最好

    副本開銷也挺高，流量大時可去掉，等到夜裏靜悄悄，定時任務來生成

    拆分索引很靠譜，保留天數按須要，數據採集設拆分，定時刪除有腳本

    多節點，是個寶，物理資源利用高，擴容縮容需規範，不能直接(節點)上下線

    寫入參數能夠調，注意觀察看療效，段合併調整是猛藥，慎重避免反作用

1、陷阱的產生

 1.ES的節點類型以下圖:

2. 默認的配置有問題：

3. a.ES默認安裝後默認的節點類型：Maser-Eligible & Data & Ingest，三合一

4. b.默認設置裏「minimum_master_nodes： 1」，只要看見一個節點，便可成立集羣,異常狀況下容易發生腦

5. c.原則：minimum_master_nodes應設置爲 (master_eligible_nodes / 2) + 1

 2.Master節點存儲信息多

    

    爲管理ES集羣，須要有一些元數據標明集羣狀態、索引/分片位置、in-sync shards …，這些信息被稱爲集羣的Meta Data。

    集羣的Meta data的變動都由Master節點完成，並通知到集羣中的其它節點。因此Master穩定對集羣很重要。

    默認Master同時做爲Data節點，當負載較重時，容易致使穩定性問題

3.高成本的寫過程

     

    a. 客戶端向Node1 發送寫請求

    b.Node1 算出文檔屬於分片0，因而將寫請求轉給分片0主分片P0所在的Node3

    c. Node3寫成功後，繼續將寫請求並行轉發到Node1和Node2的副本分片上，一旦副本分片報告成功（根據配置不一樣可選擇1個報告成功，多數報告成功，或全部報告成功），

       Node3向協調節點Node1報告成功

    d.Node1向客戶端報告成功

  

  一些解釋說明：

     a. 寫請求到達分片後，先寫Lucene文索引，再寫Translog

     b.寫Lucene索引時，新記錄首先被寫入緩存，經過定時刷新生成段文件，定時刷新的頻率由「refresh_interval」參數控制，默認1s

     c.ES本身控制什麼時候將生成的段文件持久化到磁盤

     d.Translog也是首先寫到內存裏，並在知足必定條件時flush到磁盤持久化。

       flush到磁盤的時機由兩個參數定義：「flush_threshold_size」: 「1024mb」；"sync_interval": "60s"

  

    關於段合併：Segments/段太多會給ES帶來很大負擔，嚴重影響搜索性能並帶來大量文件句柄的消耗，因此ES會自動進行段合併以優化性能。

    可是段合併過程消耗大量I/O和CPU資源，而且ES會對段合併作節流控制，這個過程甚至會引起其它問題

4.高成本的搜索

  過程描述： 

        a. 默認搜索分爲兩個階段，查詢階段與取回階段

        b. 在查詢階段，客戶端將Search請求發送給Node3，Node3將做爲本次查詢的協調節點。Node3將查詢請求轉發到每一個主分片或副本分片中，如圖中的P1和R0，每一個主分片或副本分片搜索自身包含的符合查詢條件的記錄。

        c. 各分片返回本身符合條件，並已排好序的結果給協調節點Node3，由Node3合併各節點返回的結果並過濾出全局符合條件的結果。接下來進入取回階段。

        d. 在取回階段，協調節點Node3已在第三步知道全局結果裏各記錄分別屬於哪一個分片，並向相應的分片發送取回請求。

        e. 相應分片響應取回請求，並將結果返回給Node3

        f. Node3將合併後的結果返回給客戶端，搜索完成

   搜索的開銷：

        爲保證搜索性能，ES須要將大量段數據保存在內存中，帶來至關大的內存開銷；同時，排序、聚合等操做也會消耗大量CPU資源。縱觀整個搜索過程，能夠發現它須要付出高CPU、高I/O的代價。

   查詢膨脹問題：

        在查詢階段，會帶來搜索膨脹的問題。即協調節點要知道全局結果，必須彙總每一個分片的查詢結果。

   Example：某索引有30個分片，要查詢符合某個條件的第10000筆記錄，其過程是什麼？

        查詢請求發到ES集羣中某個節點，該節點充當協調節點並將查詢轉發到30個分片上

        每一個分片返回本身符合結果的前10000筆記錄給協調節點，協調節點對總共30w筆記錄排序，並肯定全局排序結果裏第10000筆記錄在分片N上

        向該分片N發送get請求，取回該筆記錄

        將記錄返回給客戶端

2、如何被陷入

兩大陷阱 -- 穩定性 & 性能

1. 穩定性

   
   

    a.穩定性陷阱 Example #1：分片丟失，集羣變紅

    

       問題現象：有分片丟失，集羣進入Yellow/Red狀態

       廣泛程度：很是廣泛，我估計大家全部項目均碰見過

       緣由 & 解決辦法：幾乎都是因爲節點失聯致使分片丟失。節點失聯的緣由常見是gc，較少見的緣由包括「系統問題」和「網絡不通」。

       如是gc致使問題，常見應對手段如關閉索引和部署多節點避免gc；如是其它環境因素，一般排除相關 因素後可解決問題

       有用的命令：

          查看未分片的緣由：curl -XGET ‘http://<es-ip>:9200/_cat/shards?h=index,shard,prirep,state,unassigned.reason

          查看gc的命令： jstat -gc <es-pid> 2000

    b.穩定性陷阱 Example #2：腦裂沒法恢復

        問題現象：某個節點被踢出集羣，並再也沒法加入進來，集羣隨後進入分片恢復，當該丟失節點被手動加回集羣后，

        廣泛程度：較爲廣泛

        解決辦法：合理設置參數，避免集羣腦裂

        假設有3個Master Eligible節點：node.master: true

            至少看見2個Master Eligible纔可組建集羣：discovery.zen.minimum_master_nodes：2

    c.穩定性陷阱 Example #3：再平衡對性能的惡化

        問題現象：發現集羣長時間處於黃色狀態，大量分片處於分配中或待分配狀態，每每伴隨着一些節點處於高負載狀態的現象。

        廣泛程度：廣泛

        緣由分析：

        當節點因爲各類緣由失聯一段事件後，主節點會：

        1）將失聯節點上的每一個主分片的一個副本提高爲新的主分片；

        2）從新在其它節點上分配副本；

        3）進行分片恢復動做；

        4）如此時失聯節點從新加入，主節點將對集羣作平衡，將一些分片移動到失聯節點上，狀況進一步變差

        以上恢復/再平衡過程是CPU、network-io、disk-io都很重的操做！

        如何緩解：合理設置分片恢復延遲，給系統更高的容錯度

        「index.unassigned.node_left.delayed_timeout」: 「5m「     （默認1分鐘）

     d.穩定性陷阱 Example #4：查詢響應慢

        問題現象：從ES里加載數據失敗

        廣泛程度：較爲廣泛

        緣由分析：

        ES集羣有數據節點處於異常狀態 (如長時間GC)，該節點未能被及時踢出集羣，致使集羣認爲該節點仍存活，轉發到該節點的查詢長時間不能返回，致使頁面的查詢超時失敗。

        在這種狀況下，寫入數據也會受到影響，如觀察採集器狀態和日誌，很大概率會發現有數據寫失敗的狀況。

        很多項目的ES集羣會優化節點的心跳檢測參數設置，以下降集羣變紅的機率和觸發自平衡帶來的影響，但這種優化在節點異常時，將加劇查詢響應慢的問題

        如何應對：

        合理規劃部署並優化配置，下降節點異常的機率

        非不得已應避免將心跳檢測參數設置的過於激進，默認參數在大多數狀況下適用，須要調整的狀況下也不建議超過下面的值：

        「discovery.zen.ping_interval」: 「10s「 

        「discovery.zen.ping_timeout」: 「5s」

        「discovery.zen.ping_retries」: 3

        穩定性陷阱的日誌表現

        

    穩定性陷阱的總結:

    表現：ES節點掉出集羣，或一段時間沒有響應

    誘因

      jvm gc 【常見緣由】

      系統問題 【少見】

      網絡緣由 【極少見】

    危害

      分片丟失，集羣變紅/黃

      腦裂

      再平衡致使集羣性能惡化

      查詢響應時間很長/超時

 2.性能陷阱：短板效應很明顯

  a.性能陷阱 Example #1：I/O慢致使集羣性能差

    問題現象：集羣表現不穩定，採集器大量丟日誌；查看ES日誌常常出現長時間gc (> 30秒)；在監控頁面中觀察會發現多數節點CPU、load常常飆紅，CPU使用率超過硬件能力的70%

    廣泛程度：較少見

    緣由分析：ES爲提升性能，作了不少優化，包括經過輪詢操做替代睡眠、等待通知等阻塞操做（特別是段合併的節流控制處理邏輯）。

    當磁盤寫速度跟不上時，段合併邏輯會不斷重試合併，直到能夠寫入，表現爲檢測到磁盤I/O寫入不高，但CPU，load很是高。

    如何解決：

        有條件採用RAID5 （很是有效，推薦）

        使用高性能磁盤 （有效）

    沒有RAID5的狀況下，部署多節點，給不一樣節點分片的data目錄分配不一樣的磁盤以隔離I/O    （通常） 

    補充：評判硬盤性能是否知足數據量要求的條件不等式 (僅用於評估IO可否知足)

    (eps × 每條日誌大小 × (1 + 副本數) × 2[1] × 1.5[2]) ÷ data節點數 < 磁盤寫速度 × 0.4[3]

    其中[1]爲ES寫段和寫Translog的影響因子；[2]爲段合併的影響因子；

    3]爲考慮兩重影響因素的調整因子：

       1）ES data節點因爲段合併有大量讀操做，影響寫入性能；

       2）ES的段落磁盤時不是順序寫文件 （均爲經驗參數，可根據實際狀況調整）

      Example: 1w eps，日誌平均1.5KB/條，1份副本，2個data節點，機器配置速度爲180MB的硬盤，可否知足性能要求？

  答：不等式左邊：10000 * 1.5K * 2 * 2 * 1.5 ÷ 2 ≈ 45MB；不等式右邊：180 * 0.4 =72MB。能夠知足

b.性能陷阱 Example #2：節點慢致使集羣性能差

    問題現象：採集器丟日誌，但經過監控頁面觀察，ES節點大多數時間正常，消耗資源較低，但長時間觀察，能看到CPU，load飆紅的狀況，持續一段時間後消失，過段時間再出現，… …

    廣泛程度：較少見

    緣由分析：當ES集羣中存在配置較低，或速度較慢的節點時，該節點將拉慢其它正常節點的寫速度，並觸發段合併的節流機制，致使CPU、load飆升；

                     事實上，查詢也會受到影響，會表現出有時查詢慢的現象。

    如何解決：找出存在瓶頸的節點，並予以解決。

    問題排查的有效命令：

        curl –XGET 「http://es-ip:9200/_cat/thread_pool?v&h=ip,bulk*」

     

  性能陷阱的總結：

    表現：ES集羣性能差 -- 丟數據；CPU & load持續高位；採集器報錯並陷入異常

    誘因

       磁盤I/O速度慢 【常見緣由】

       gc致使節點速度慢 【常見緣由】

       低配節點速度慢 【較少見】

    危害

        丟日誌

        機器性能用不滿、上不去

        CPU & load短期飆升，集羣穩定性變差

3、如何避坑

    避坑的技術：調整部署 & 優化配置

 1.部署優化之加強穩定性

    節點的設置建議（4個以上數據節點，> 1.5w eps）：

    a. 主節點必須由master-only節點承擔，Master-only節點配置8G內存

    b. 條件容許則部署單獨的coordinate節點負責查詢，coordinate節點內存16GB。Coordinate節點配置後，模塊裏鏈接ES的配置改成coordinate節點。

    c. 同物理機部署多Data節點，Data節點內存最大31G

        切記給每一個節點分配不一樣的data路徑以免異常狀況（如因數據未能加載而形成的分片丟失），特別是在未使用RAID的狀況下，讓不一樣的節點的data path在不一樣硬盤上能夠隔離I/O、提高性能

    d. 數據量< 1.5w eps時，物理機<4臺，一般不需特殊配置，確保節點發現參數正確。原則：保證超半數master eligible節點被看見纔可創建集羣。

        原則：保證超半數master eligible節點被看見纔可創建集羣。

        例如3個Master Eligible節點：node.master：true

        至少看見2個Master Eligible才容許組成集羣： discovery.zen.minimum_master_nodes：2

        在節點發現配置裏配上全部的Master-Eligible節點：discovery.zen.ping.unicast.hosts: ["x.x.x.x", "x.x.x.y", "x.x.x.z"]

 2.部署優化之增長data節點

    Data節點的配置爲：

        conf/elasticsearch.yml:    

        node.master: false    

        node.data: true

    設置好節點發現，將Master-Eligible節點放入配置

        conf/elasticsearch.yml:    

        cluster.name: hansihgt-enterprise    

        node.name: node_N    

        discovery.zen.ping.unicast.hosts: ["x.x.x.x", "x.x.x.y", "x.x.x.z"]

     等待集羣自動平衡

  3.部署優化之減小data節點

        將分片遷移到其它節點：

        PUT _cluster/settings{  "transient" : {    "cluster.routing.allocation.exclude._ip" : 「x.x.x.x"  }}

        待數據遷移完成，將節點下線

  4.部署優化之增長&減小Master節點

        增長Master節點：

        首先將‘minimum_master_nodes’參考變動到當前的「quorum/過半數「值，如，以前爲3個Master-Eligible，如今要增長到4個，則quorum要由2提高到3：

        curl -XPUT localhost:9200/_cluster/settings -d '{    "persistent" : {  "discovery.zen.minimum_master_nodes" : 3    }}'

        再部署新的Master節點，並在配置文件裏設置正確的發現參數

   5.部署優化充分利用硬件資源

        通常採用單臺物理機上部署多節點的方式以充分利用內存，以及分散磁盤I/O

        數據節點的內存磁盤比

        給全部ES數據節點啓動參數配置的內存之和記爲M（注意不是機器的物理內存），天天的索引所佔存儲記爲S，索引打開天數記爲N，它們之間的關係應知足：

        M * δ > S * N

        δ爲經驗參數，取值在96 ~ 128之間 （根據現場經驗，該值能夠適當激進一些）

        Example：某集羣7個數據節點，每一個節點配置31GB內存，天天數據量約2.5TB（含副本）， δ取100，則最大可打開的索引天數爲：

            N < 31 * 7 * 100 ÷ (2.5 * 1024) ≈ 8天

   6.部署優化之合理選擇硬件

        磁盤使用：I/O性能對ES性能有很大影響，建議

        有條件應儘可能上RAID5

        不能上RAID5儘量選擇高性能硬盤

        網卡選擇：數據量大時應使用萬兆網卡，

        網絡存儲：最好都不用！

        無可奈何，惟一的選擇：SAN

        因爲寫入延遲大，不要用NAS

        關於虛擬機：最好不用虛擬機 ，無可奈何，應儘可能保證硬件資源不被其它虛擬機競爭

    7.優化配置之使用方法優化

        流量高峯時不寫副本，設置定時任務生成

       拆分索引，便於不一樣業務數據源的數據保存不一樣的時間週期。

    8.優化配置之ES參數優化

       a. 提高穩定性：

          正確設置節點發現參數，避免腦裂

         延遲遷移分片：「index.unassigned.node_left.delayed_timeout」: 「5m「

       b.優化寫性能 ： 

        下降段刷新頻率："index.refresh_interval": "60s「

       c.下降IO阻塞：

            "index.merge.scheduler.max_thread_count": "1「

             action.wait_for_active_shards: 1  （ES 5.x之後）

             action.write_consistency: one (ES 2.x)

       d.段合併參數配置，減小段合併（慎重，有反作用！）

          "index.merge.scheduler.max_merge_count": 16

           "index.merge.policy.floor_segment": "128mb"

           "index.merge.policy.segments_per_tier": 128

           "index.merge.policy.max_merge_at_once」: 32

哈哈：方法千萬條，穩定第一條，規劃不完善，上線滿頭汗！