Elasticsearch 運維實踐
點擊上方“IT那活兒”公眾號，關注后了解更多內容，不管IT什么活兒，干就完了！！！
對于Elasticsearch的學習，需要清楚的明白它的每個核心概念，由淺入深的了解，才能更好的掌握這門技術。下面先簡單羅列下Elasticsearch的核心概念：
如下圖所示，Elasticsearch使用index和doc_type來組織數據。doc_type中的每條數據稱為一個document，是一個JSON Object，相關的schema信息通過mapping來定義。mapping不僅僅包括數據類型的定義，還有很多其他元信息的設置，它們共同決定了數據如何被存儲和索引。這四個概念實現了Elasticsearch的邏輯數據組織，假設有一批結構化或半結構化數據需要存儲，我們會先對數據進行分類，設計相應的index與doc_type，再為每個doc_type設置相關的mapping信息。如果不指定mapping，Elasticsearch會使用默認值，并自動為你推導每個字段的類型，即支持schema free的特性。但是，這種靈活性也會帶來一些問題，一方面會失去對數據的控制，即會越來越不清楚你的數據結構，另一方面，自動推導出來數據類型可能不是預期的，會帶來寫入和查詢問題。所以，筆者建議，盡最大可能對schema加以約束。通常情況下，我們都會拿Elasticsearch的這些概念跟關系型數據庫Mysql來做對比以便更好的理解，比如index等價于database，doc_type等價于table，mapping等價于db schema。但是需要注意的是：對于關系型數據庫而言，table與table之間是完全獨立的，不同table的schema是完全隔離的，而Elasticsearch中的doc_type則不是。同一個index下不同doc_type中的字段在底層是合并在一起存儲的，意味著假設兩個doc_type中都有一個叫name的字段，那么這兩個字段的mapping必須一樣。基于這個原因，Elasticsearch官方從6.0開始淡化doc_type的概念，推薦一個index只擁有一個doc_type，并計劃在8.x完全廢棄doc_type。因此，在當前的index設計中，最好能遵循這個規則。Elasticsearch是一個分布式系統，其數據會分散存儲到不同的節點上。為了實現這一點，需要將每個index中的數據劃分到不同的塊中，然后將這些數據塊分配到不同的節點上存儲。這里的數據塊，就是shard。通過"分"的思想，可以突破單機在存儲空間和處理性能上的限制，這是分布式系統的核心目的。而對于分布式存儲而言，還有一個重要特性是"冗余"，因為分布式的前提是：接受系統中某個節點因為某些故障退出。為了保證在故障節點退出后數據不丟失，同一份數據需要拷貝多份存在不同節點上。因此，shard從角色上劃分為primary shard和replica shard兩種，數據會首先寫入primary shard，然后同步到replica shard中。shard是Elasticsearch中最小的數據分配單位，即一個shard總是作為一個整體被分配到某個節點，而不會只分配其中一部分。答案是segment。一個shard包含一組segment，segment是最小的數據單元，Elasticsearch每隔一段時間產生一個新的segment，里面包含了新寫入的數據。segment是immutable的，即不可改變，這樣設計的考量是：一方面，不支持修改就不用對讀寫操作加鎖，省去了相關開銷；另一方面，因為文件內容不會修改，可以更好的利用filesystem cache進行緩存，提高查詢性能。但是，任何設計都不是完美的，伴隨而來的問題是：如果segment不可修改，怎么實現數據的更新與刪除呢？這個問題將在文中Elasticsearch的"數據寫入"內容中說到。 上面說到Elasticsearch將每個index中的數據劃分到不同的shard中，然后將shard分配到不同的節點上，實現分布式存儲。這里面涉及到兩個概念：一個是數據到shard的映射（route），另一個是shard到節點的映射（shard allocate）。一方面：插入一條數據時，Elasticsearch會根據指定的key來計算應該落到哪個shard上。默認key是自動分配的id，可以自定義，比如在業務中采用CompanyID作為key。因為primary shard的個數是不允許改變的，所以同一個key每次算出來的shard是一樣的，從而保證了準確定位。
shard_num = hash(_routing) % num_primary_shards
另一方面：master節點會為每個shard分配相應的data節點進行存儲，并維護相關元信息。通過route計算出來的shard序號，在元信息中找到對應的存儲節點，便可完成數據分布。shard allocate的映射關系并不是完全不變的，當檢測到數據分布不均勻、有新節點加入或者有節點掛掉等情況時就會進行調整，稱為relocate。
一個分布式系統，是由多個節點各司其職、相互協作完成整體服務的，從架構上可以分為有中心管理節點和無中心管理節點兩種，Elasticsearch屬于前者。中心管理節點負責維護整個系統的狀態和元信息，為了保證高可用性，通常是從一組候選節點中選舉出來的，而非直接指定。按照職責，Elasticsearch將節點分為三種：master-eligible節點
data節點
ingest節點
master-eligible節點就是中心節點的候選人，通過選舉算法從這些候選人中推選出大家公認的中心節點。data節點負責數據存儲、查詢，也是整個系統中負載最重的部分。ingest節點是針對Elasticsearch一個特定功能而設定的，Elasticsearch支持在數據寫入前對數據進行相關的轉換、處理，而這類節點就是負責這樣的工作，從筆者遇到的實踐來看，使用這類節點的并不多。這三種角色是通過配置來設定的，可以同時設置到同一個節點上，即一個節點可以同時具備這三種功能。但是這種做法只適用于數據量小、業務較輕的場景，因為不同角色承擔的功能所帶來的負載是不同的，很可能因為數據寫入/查詢負載較重導致master節點通信受到影響，從而導致系統不穩定。所以，推薦將不同角色分離開，某個節點只負責其中一個功能，通常會設置dedicated master-eligible節點、data/ingest節點。前者負載很輕，只需要分配較低配置的機器，而后者對CPU、IO、Memory要求較高，需要配置更好的機器，實踐中根據性能測試結果來調整。前面說到，中心節點(master)是從一組候選人(master-eligible)中選舉出來的，那設置多少個候選人是合理的？原則是要保證任何時候系統只有一個確定的master節點。考慮到一致性，只有被半數以上候選節點都認可的節點才能成為master節點，否則就會出現多主的情況。只有1個候選節點顯然不能保證高可用；有2個時，半數以上（n/2+1）的個數也是2，任何一個出現故障就無法繼續工作了；有3個時，半數以上的值仍然是2，恰好可以保證master故障或網絡故障時系統可以繼續工作。因此，3個dedicated master-eligible節點是最小配置，也是目前業界標配。Elasticsearch以REST API形式對外提供服務，數據寫入與查詢都會發送HTTP(S)請求到服務端，由負載均衡將請求分發到集群中的某個節點上（任何非dedicated master-eligible節點）。如下圖所示，節點1收到請求后，會根據相關的元信息將請求分發到shard所在的節點（2和3）上進行處理，處理完成后，節點2和3會將結果返回給節點1，由節點1合并整理后返回給客戶端。這里的節點1扮演著協調者的角色，稱為coordinate節點，任何節點在收到請求后就開始發揮協調者的角色，直到請求結束。在實際使用中，可以根據需要增加一些專用的coordinate節點，用于性能調優。通過上面的整理可知，Elasticsearch數據寫入的大致過程為：當有數據寫入時，請求會先到達集群中的某個節點上，由該節點根據routing信息和元信息將相應的數據分發到對應的shard所在的節點上，可能是一個也可能是多個節點，取決于寫入的數據。這些節點在收到分發出來的請求后，會經過一系列過程，最終將數據以segment的形式落地到磁盤上。Elasticsearch數據寫入過程包含同步與異步兩個過程，如下圖所示：同步過程：是指在請求返回前做的事情，即包含在一個HTTP請求的過程中，客戶端需要等其做完才能拿到結果。簡單來看，這個過程需要完成三件事：第一，將操作記錄寫入到translog中，我們后面再來談它的作用；
第二，根據數據生成相應的數據結構，并寫入到in-memory buffer，注意是寫入到一個內存buffer中，不是磁盤；
第三，將數據同步到所有replica shard中。完成這些之后，就會生成相應的結果返回給coordinate節點了。
異步過程：一般來說，寫磁盤很慢，且非常耗費CPU與IO，在同步過程中，為了讓請求盡快返回，并沒有將數據直接落盤。Elasticsearch的最小數據單元是segment，而此時數據還在in-memory buffer中，因此這部分數據是不能被查詢請求訪問到的。只有當發生refresh動作，才會產生一個新的segment，將內存buffer中的數據寫入到里面，同時清空buffer。默認refresh的時間間隔是1秒，可以配置，需要在實時性與性能之間進行權衡。此時雖然已經生成了新的segment文件，但是只是停留在filesystem cache中，并沒有真正的落到磁盤中。這些動作的目的都是為了將"寫磁盤"這件事盡可能的延后并變得低頻，但是數據一直留在內存中始終是不安全的，很容易因為斷電等原因導致數據丟失，因此每隔一段時間，Elasticsearch會真正做一次磁盤flush，完成數據的持久化。從寫入請求過來到數據最終落盤，中間很長一段時間數據是停留在內存中的，那么如果在此期間機器斷電豈不是會丟失數據？為了解決這個問題，就要用到上面所述的translog了。在請求返回前，必須要將操作記錄寫入到translog中并落盤，保證機器重啟后可以恢復數據。顯然這件事本身是會消耗性能的，但這也是保證數據不丟失的一個犧牲了，必須要做的。segment是由refresh動作產生的，因此隨著時間推移，會產生很多小segment，而每個segment都需要占用一定的資源，比如文件句柄、緩存等等，過多的segment勢必會導致性能下降。因此每隔一段時間，Elasticsearch會做一次segment merge，將多個小的segment合并成一個大的segment。最后再來看下前面提到的一個問題：因為segment是不可改變的，如何實現數據更新與刪除？以刪除為例，Elasticsearch將要刪除的數據記錄到一個叫.del文件中，每次查詢時會將匹配到的數據跟這個文件中的數據做一次對比，去掉被刪除的數據。直到segment merge時，會將.del文件和相應的segment文件一起加載進行合并，這時才真正刪除了數據。在介紹Elasticsearch存儲結構之前，先來看看兩種常見的查詢需求：一種是精確匹配，比如查找作者姓名為"Bruce"的信息；一種是全文檢索，比如從1000個文章的標題中搜索出包含"分布式"的文章。對于第一個需求，只需要將每個名字作為一個term即可，"是"或"不是"；對于第二個，如果想知道標題中是否包含"分布式"，就需要提前將每個標題分解為多個term，比如"淺談分布式存儲系統"，可能會產生"淺談"、"分布式"、"存儲"、"系統"等多個term，具體取決于使用了哪一種分析器。不管哪種情況，最后都是產生一組term，問題是用一個什么樣的存儲結構可以實現快速檢索。這就是Elasticsearch的核心：inverted index。inverted index是一個二維結構，如下所示，包含一組排好序的term，每個term都關聯有一些信息，這些信息指出哪些document包含了這個term。當需要查詢包含關鍵詞"分布式"的數據時，系統會先從inverted index中找出對應的term，獲取到其對應的document id，然后就可以根據document id找出其信息了。
sample data：
1. {"author": "Bruce", "title": "淺談分布式存儲系統"}
2. {"author": "Bruce", "title": "常見的分布式系統"}
3. {"author": "David", "title": "分布式存儲原理"}
inverted index for field "author":
-------------------------------
term | doc id
-------------------------------
Bruce | 1, 2
David | 3
-------------------------------
inverted index for field "title":
-------------------------------
term | doc id
-------------------------------
常見 | 3
存儲 | 1, 3
分布式 | 1, 2, 3
淺談 | 1
系統 | 1, 2
原理 | 3
-------------------------------
通過inverted index，就可以根據關鍵詞快速搜索出相關的document。除了這種查詢，還有一種常見的需求是求聚合，即關系型數據庫中的GROUP BY功能。比如查看寫"分布式"相關的文章最多的10位作者，首先根據上述方法通過inverted index找到與"分布式"相關的所有document，然后需要對這些document的作者進行歸類并計數，最后再排序取出TOP10。在"歸類"時，我們需要知道每個document的作者名字，但是通過inverted index是無法直接查找到的，因為他是term-to-doc_id形式的，而我們這里需要的是doc_id-to-term形式的數據，只有通過循環迭代才能知道某個document的作者姓名是什么，這樣做的效率無疑是很低的。
為了解決聚合的效率問題，Elasticsearch建立了一個與invaerted index反向的數據結構：doc values，如下所示：
-------------------------------
doc id | terms
-------------------------------
1 | Bruce
2 | Bruce
3 | David
-------------------------------
inverted index和doc values都是在數據寫入時建立的，即上述的同步過程第二步中完成的。它們都是針對per segment而言的，數據最終以文件的形式存儲，并且是immutable不可改變的。數據查詢時，如果每次都去讀取磁盤文件，其效率顯然是無法接受的，Elasticsearch將這些文件內容映射到內存中，通過充分利用文件系統緩存來提高查詢性能，因此在實踐中建議保留足夠的memory給系統。elasticsearch的基礎配置信息在elasticsearch.yml中，下面列出一些重要的配置。默認情況下elasticsearch的集群名稱是elasticsearch，在實際應用中應該設置一個有意義的集群名稱：
cluster.name: elasticsearch-cluster-demo
7.2 節點信息
elasticsearch節點是elasticsearch集群中的某一個節點，可由基本的三個信息描述，節點名稱（node.name）,是否為主節點（node.master）,是否為數據節點（node.data）。默認情況下，節點名稱在每次啟動的時候會隨機生成，所以應該為節點設置一個有意義的名稱，以方便排查問題。而節點又分為主節點、數據節點、客戶端節點、部落節點，下面是一個節點（只為主節點）的配置樣例：
node.name: node-master-one
node.master: true
node.data: false
7.3 數據存儲路徑/日志路徑
默認情況下，elasticsearch數據和日志的存儲路徑是在安裝目錄下，為了防止被誤刪掉，應該重新設置路徑。配置樣例如下：
# Path to directory where to store the data (separate multiple locations by comma):
# es data 存儲路徑（多個路徑可用,隔開）
path.data: /data/elasticsearch-cluster/elasticsearch-master-one/data
#
# Path to log files:
# log存儲路徑
path.logs: /data/elasticsearch-cluster/elasticsearch-master-one/logs
在搭建elasticsearch的時候，也應該去修改其監聽的主機IP，至于端口可以用默認的：
# Set the bind address to a specific IP (IPv4 or IPv6):
# 網路監聽
network.host: 0.0.0.0
http.port: 9200
transport.tcp.port: 9300
如果是搭建elasticsearch集群，那么應該設置最小主節點這個設置，以便防止腦裂現象：多個主節點同時存在與一個集群（一個集群只允許有一個主節點）。集群的主節點是集群的最高統治者，控制著索引的創建和分片的移動策略等；如果一個集群出現多個主節點，那么就好比一個團隊出現兩個leader一樣，原本的一個整體被劃分，對于elasticsearch集群來講就是原本的分片（數據）被分開，這樣數據就可能出現不完整性。集群的主節點是靠所有有資格競選主節點的節點（即節點信息設置node.master為true）投票選舉出來的，所以現在獲得的投票數量應該大于總票數半。所以在elasticsearch中，是設定當候選的master節點達到設定的法定個數的時候才進行主節點選舉：法定個數 = master-eligible nodes / 2 + 1
# Prevent the "split brain" by configuring the majority of nodes (total number of master-eligible nodes / 2 + 1):
# 最小主節點個數
discovery.zen.minimum_master_nodes: 2
因為elasticsearch節點是可以動態刪除和添加的，所以這個設置是可以通過API動態設置的。elasticsearch集群在啟動的時候，會做數據平衡操作。比如，一個10個節點5/1分片策略（5個分片，5個副本分片）的集群，平衡下來是每個節點一個分片，如果集群在重啟的時候，有5個節點因為網絡原因一段時間內未啟動成功，可能會出現一種情況：啟動的5個節點中有3個主分片，2個副分片。這時候就會出現主分片數據不完整和不均勻分布，此時集群會自動做數據的平衡操作。若一段時間后，另外的5個節點重新上線了，發現本身的數據在集群中已存在，則又會做平衡操作。這樣，兩次數據平衡移動操作，會占用磁盤和帶寬，若數據量大則影響可想而知。所以可以做如下控制，來保障集群重啟時數據恢復花費時間盡可能短：gateway.recover_after_nodes: 8
2）設置集群數據恢復條件：等待多少分鐘，或這有多少個節點上線（具體取決與條件的先達性）。
gateway.expected_nodes: 10
gateway.recover_after_time: 5m
使用單播方式，為節點提供其應該去嘗試連接的節點列表，連接成功，得到集群的狀態信息，便加入集群。節點列表中可以不是全部節點，只要能保障能進入集群即可（可以選用部分候選主節點）。
# Pass an initial list of hosts to perform discovery when new node is started:
# The default list of hosts is ["XXX.X.0.1", "[::1]"]
# 候選主節點ip:port
discovery.zen.ping.unicast.hosts: ["XXX.X.0.1:9300"]
elasticsearch集群在運行的時候，當有節點加入或離開的時候，會進行分片均衡操作，這個過程有些像集群重啟時的數據恢復過程，可能會導致出現多次分片在均衡的過程，所以需要設置延遲分片分配，以盡量避免該情形出現。
# 延遲5min
delayed_timeout: 5m
該設置同樣可以通過API的形式動態設置。
內存交換會影響性能，elasticsearch官方推薦允許JVM鎖住內存，禁止出現內存交換的情況：
elasticsearch默認的安裝內存是1g，這個可以根據需要來設置，在elasticsearch的config目錄中的jvm.options中：
# Xms represents the initial size of total heap space
# Xmx represents the maximum size of total heap space
-Xms1g
-Xmx1g
當然，這個內存不是隨便設置的，推薦的是最大值和最小值一樣，以避免堆內存改變時浪費系統資源。其次是即便硬件資源足購大，也不要分配超過32G（具體原因可參考Elasticsearch權威指南：不要超過32GB），可以多給底層lucenen多分點。elasticsearch在節點在通信時會產生大量套接字，以及elasticsearch底層的lucene使用了大量文件，所以需要足夠的文件描述符，而linux中一般都是做有限制的，所以應該修改為大一點的值。可以修改文件/etc/security/limits.conf，添加如下配置,配置值設為需要的值即可：
#
#四個元素的意義在該文件中均有詳細描述
elasticsearch soft nofile 65536
elasticsearch hard nofile 65536
elasticsearch對文件混合使用了NioFs（非阻塞文件系統）和 MMapFs （ 內存映射文件系統），所以要保障有足夠的虛擬內存用于映射。可以直接修改/etc/sysctl.conf文件添加如下配置，配置值設為需要的值。下面內容添加到sysctl.conf文件中后，執行"sysctl -p"命令使配置生效即可。
這兩項如果在啟動elasticsearch之前不進行設置的話，在啟動elasticsearch的時候也可能會直接報相關的error以致無法啟動成功。這兩個配置，es官方強烈建議不要做修改，具體原因可參考：Elasticsearch權威指南：不要觸碰這些配置隨著業務的增長與發展，不同的Elasticsearch集群承擔著多厚多樣的功能需求。尤其是當集群規模增長、業務龐大時，需要耗費大量的精力運維集群。最壞的情況，Elasticsearch集群崩潰，無法正常承擔各項業務。導致ES集群崩潰的大多數原因是master節點、數據節點的宕機。下面總結節點：以Elasticsearch集群的數據節點與master節點為例，當有任何一個節點負載過高，都可能導致單節點宕機從而挑戰集群的可用性。master節點負載高會嚴重影響到集群穩定性，可能發生master漂移，節點上下線，分片丟失，負載增高，甚至阻塞讀寫等。應對措施：可以確認下是否有大量頻繁的修改，創建，刪除索引操作，并盡量避免這種行為。可以考慮使用更高配置的節點用增加系統高穩定性。因此，我們需要檢測過去一段時間內Elasticsearch節點負載情況（腳本方式等），提前獲知并拯救集群于崩潰邊緣。索引的副本一方面是保證數據的可靠性，保證在數據丟失的狀態下依舊可以恢復如初；一方面副本數的增加可提高查詢的性能。在存儲空間占用過滿時，極有可能導致索引副本丟失。因此檢查副本的存在狀態，可幫助提高數據的可靠性。在Elasticsearch集群重啟的過程中，只有在副本數量完整時才能保證服務的持續進行。應對措施：監控Elasticsearch集群基本顏色狀態，檢查shard分片是否丟失。顏色不正常的索引會影響數據讀寫。索引副本丟失（YELLOW）會影響到數據的可靠性和讀寫性能；索引主分片丟失（RED）會導致數據丟失。所以要極度重視和關注Elasticsearch集群顏色狀態的監控，遇到異常，及時處理！在寫操作進行的過程中，可能會因Elasticsearch集群壓力，導致讀寫任務堆積過多。如果在此情況下繼續增加寫入，則可能會引起集群的崩潰。檢查集群寫數據是否有堆積，如果寫入存在堆積，則會造成RulkReject異常，可能會導致數據丟失，且會造成系統資源消耗嚴重。應對措施：通過調用線程池查看實際成功、失敗任務情況，使用分批寫入的方式解決寫入堆積困境，給集群減壓。可以通過ES_API查看隊列情況，GET _cat/thread_pool/bulk?v，建議增加更多的數據解讀或降低bulk寫入頻率和大小。 如何在固定配置的情況下更大程度發揮集群可用性能，是我們最關心的問題。從Elasticsearch內部邏輯與架構，數據節點是任務載體與執行依托，shard是索引與搜索的主要承擔者，副本是提升性能的重要抓手，分批寫入與防止稀疏是必備方式。如何提升集群性能，下面從數據節點負載、shard合理性兩方面簡單做下說明。在各數據節點負載均衡的條件下，性能會趨向于最優的實踐。如果發生單節點負載過高，與其他節點產生較大差異，則高負載節點可能成為"拖油瓶"，拉低整體集群數據節點任務執行，甚至存在脫離集群的風險。監控Elasticsearch集群當天的節點負載偏差是否過大，節點間負載不一致會使得某個節點成為系統瓶頸，影響集群穩定性。應嘗試調整shard分片數或數據節點數，盡可能保證兩者均衡。9.2 shard、segment合理性評估，升性能調負載不同的Elasticsearch集群應用場景對性能承載著不同的需求。索引的載體就是shard，搜索結果的返回也是多個shard共同的返回結果。Shard數與節點間的負載均衡、查詢性能和存儲空間利用均有著非常重要的關系。shard數和大小不合理會極大的影響索引讀寫性能，shatd過少會影響索引讀寫性能，shard過多會占用較多系統資源。通過讀取索引shard、節點shard，檢查判斷是否因索引segment過多導致碎片化，引發離線數據寫入過慢，從而在適當的時間執行段合并操作，即調整部分索引的shard數，提升離線數據的寫入速度，均衡負責，提升性能，節省空間。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/129509.html
