elasticsearch如何設計集羣

本文爲博客園做者所寫： 一寸HUI，我的博客地址：https://www.cnblogs.com/zsql/

　　在寫本文時就在想，若是讓你負責一個elasticsearch集羣，從零開始，你會從哪些方面考慮？咱們也知道es基本都是開箱即用，並且也很好用，配置參數也用默認的就好，只是這麼簡單的用不難，可是要想更好的用好es集羣，那要怎麼去作設計呢？咱們知道想要用es集羣，首先要安裝es集羣，固然es安裝須要硬件，也就是服務器的支撐，若是安裝好了es集羣，也不能空跑吧，因此要有數據，因此要寫入數據，固然寫入數據是爲了後期有所用，好比查詢數據，作分析等。用是能夠了，若是數據量增大，業務更加複雜，還要考慮如何更好的用，怎麼用能夠提升效率？一個集羣也不可能只有一我的用呀，若是不少人用，就會存在不安全，須要考慮權限吧，想一想也算健全了，可是萬一哪天機器出問題了，數據丟失了怎麼辦？是否是須要作可靠的備份呢？若是整個集羣完完了，又怎麼辦呢？固然這樣的狀況基本不可見，可是是否是要考慮進來呢？就算從安全和容錯，以及性能方面都考慮清除了，集羣正常運行了，不少時候都不免天有不測風雲，是否是要常常關注整個集羣或者索引的一些狀態信息呢？不能時時刻刻盯着集羣的健康狀態吧，因此這裏須要監控一下集羣吧，固然到這裏位置整個集羣算是很好的運行起來了，可是後期隨着數據量的增長，業務的增加，運維難度就會愈來愈大，因此前期的設計很重要，規範化管理很重要。大概就想了這麼多，本文的內容也是圍繞着這些問題進行展開的。有興趣的請繼續往下讀。聲明：本文是elasticsearch的版本爲7.8.1

1、如何對機器進行選擇

一、內存

　　若是有一種資源是最早被耗盡的，它多是內存。排序和聚合都很耗內存，因此有足夠的堆空間來應付它們是很重要的。即便堆空間是比較小的時候， 也能爲操做系統文件緩存提供額外的內存。由於 Lucene 使用的許多數據結構是基於磁盤的格式，Elasticsearch 利用操做系統緩存能產生很大效果。

　　64 GB 內存的機器是很是理想的， 可是32 GB 和16 GB 機器也是很常見的。

二、磁盤

　　硬盤對全部的集羣都很重要，對大量寫入的集羣更是加倍重要（例如那些存儲日誌數據的）。硬盤是服務器上最慢的子系統，這意味着那些寫入量很大的集羣很容易讓硬盤飽和，使得它成爲集羣的瓶頸。

　　若是你負擔得起 SSD，它將遠遠超出任何旋轉介質（注：機械硬盤，磁帶等）。 基於 SSD 的節點，查詢和索引性能都有提高。若是你負擔得起，SSD 是一個好的選擇，若是使用了機械磁盤，使用 RAID 0 是提升硬盤速度的有效途徑，對機械硬盤和 SSD 來講都是如此。沒有必要使用鏡像或其它 RAID 變體，由於高可用已經經過 replicas 內建於 Elasticsearch 之中，再不濟，一臺機器也多弄幾個磁盤，這樣在配置的能夠指定多幾個目錄，這樣能下降一個磁盤的io壓力。

三、cpu

大多數 Elasticsearch 部署每每對 CPU 要求不高。所以，相對其它資源，具體配置多少個（CPU）不是那麼關鍵。可是仍是建議16核以上做爲生產環境，由於elasticsearch的thread pool和這個配置直接相關。若是你要在更快的 CPUs 和更多的核心之間選擇，選擇更多的核心更好。多個內核提供的額外併發遠賽過稍微快一點點的時鐘頻率。

四、網絡

　　快速可靠的網絡顯然對分佈式系統的性能是很重要的。 低延時能幫助確保節點間能容易的通信，大帶寬能幫助分片移動和恢復。現代數據中心網絡（1 GbE, 10 GbE）對絕大多數集羣都是足夠的。Elasticsearch 假定全部節點都是平等的—​並不會由於有一半的節點在150ms 外的另外一數據中心而有所不一樣。更大的延時會加劇分佈式系統中的問題並且使得調試和排錯更困難。

參考《ES權威指南》：https://www.elastic.co/guide/cn/elasticsearch/guide/current/hardware.html

2、集羣安裝要怎麼配置和設計

2.一、系統設置

官網：https://www.elastic.co/guide/en/elasticsearch/reference/7.8/system-config.html

1、設置系統配置 ulimit #暫時修改，切換到該用戶es，ulimit -n 65535 
/etc/security/limits.conf #永久修改 es -  nofile  65535 ulimit -a #查看當前用戶的資源限制 2、禁用sawpping 方式一： swapoff -a #臨時禁用全部的swap文件 vim /etc/fstab #註釋掉全部的swap相關的行，永久禁用 方式二： cat /proc/sys/vm/swappiness #查看該值 sysctl vm.swappiness=1 #臨時修改該值爲1 vim /etc/sysctl.conf #修改文件 永久生效 vm.swappiness = 1 #若是有該值，則修改該值，若沒有，則追加該選項，sysctl -p生效命令 方式三： 配置elasticsearch.yml文件，添加以下配置： bootstrap.memory_lock: true GET _nodes?filter_path=**.mlockall #檢查如上配置是否成功 注意：若是試圖分配比可用內存更多的內存，mlockall可能會致使JVM或shell會話退出!

3、配置文件描述符 ulimit -n 65535 #臨時修改 vim /etc/security/limits.conf #永久修改 es soft nproc 65535 es hard nproc 65535

4、配置虛擬內存 sysctl -w vm.max_map_count=262144 #臨時修改該值 vim /etc/sysctl.conf #永久修改 vm.max_map_count=262144

5、配置線程數 ulimit -u 4096 #臨時修改 vim /etc/security/limits.conf #永久修改

2.二、基本安裝配置

節點設計：

默認狀況下，全部的節點都是master節點，data節點，ingest節點，ml節點（若是爲true），數據節點也是transform節點

 節點的類型：

1. Master-eligible node 候選主節點node.master: true，主節點負責建立或刪除索引，跟蹤哪些節點是集羣的一部分，以及決定將哪些碎片分配給哪些節點。全部的候選主節點在沒有配置node.voting_only: true的狀況下，均可以經過選舉稱爲主節點。主節點必須可以訪問data數據目錄，也能夠設置專用的主節點，通常至少選用3臺，把其餘的角色設置爲false便可。
2. Data node 用於數據的存儲，CRUD，搜索，聚合等,node.data: true，數據節點保存包含已創建索引的文檔的分片。數據節點處理與數據相關的操做，如CRUD、搜索和聚合。這些操做是I/O密集型、內存密集型和cpu密集型，也能夠設置專用的數據節點
3. Ingest node 用於數據前期的預處理，相似logstash，node node.ingest: true
4. Machine learning node 用於運行做業和處理機器學習API請求
5. Transform node 用於數據轉換node.transform: true，若是是數據節點，則默認爲true，不然false
6. Coordinating node  協調節點，每一個節點都是協調節點，不可關閉，協調節點將請求轉發給持有數據的數據節點。每一個數據節點在本地執行請求，並將其結果返回給協調節點。在收集階段，協調節點將每一個數據節點的結果減小爲單個全局結果集

 　　 若是集羣很小，機器不夠用的狀況下，能夠把數據節點和主節點公用，若是想要主節點高可用的話，就要至少在3臺機器上配置node.master：true，固然還能夠更多，奇數就行了，若是機器不少，能夠把主節點和數據節點分離，這樣配置更加單一原則，主節點更加穩定，因此集羣也會更加穩定。具體怎麼配置見官網：https://www.elastic.co/guide/en/elasticsearch/reference/7.8/modules-node.html

再看看elasticsearch幾個重要的配置：https://www.elastic.co/guide/en/elasticsearch/reference/7.8/important-settings.html

1、數據目錄配置 path: data: - /mnt/elasticsearch_1 - /mnt/elasticsearch_2 - /mnt/elasticsearch_3 或者path.data: /data/es/es_cluster 2、log日誌目錄配置 path.logs: /data/es/es_cluster/elasticsearch-7.8.1/logs 3、集羣名配置 cluster.name: es1304、節點名配置 node.name: prod-data-2

5、network.host配置 network.host: 192.168.88.130 #默認爲迴環地址127.0.0.1，生產環境須要修改 6、集羣節點發現配置 discovery.seed_hosts: ["192.168.88.130","192.168.88.131","192.18.88.132] #例如集羣三個節點 cluster.initial_master_nodes: ["es130","es131","es132"] #配置集羣初始化首次啓動符合主節點的列表

2.三、jdk相關配置

推薦使用elasticsearch自帶的jdk，elasticsearch7.8.1默認的是openjdk 14，因此配置好jdk相關的JAVA_HOME就好

export JAVA_HOME=/data/es/elasticsearch-7.8.1/jdk export PATH=$JAVA_HOME/bin:$PATH

　　還有一個重點配置就是java堆大小的配置，這個參數影響到太多的性能，若是內存容許的話，直接配上20-30G就行了，這裏要注意堆的最大值和最小值要同樣，否則啓動的時候會檢查這兩個不同就會報錯。

參考官網：https://www.elastic.co/guide/en/elasticsearch/reference/7.8/heap-size.html

配置jvm.options 文件或者配置ES_JAVA_OPTS變量

配置文件config/jvm.options 

自定義的jvm選項能夠配置在config/jvm.options.d/文件夾下，必須以.options結尾的文件，這裏只例舉了一小部分配置，具體還有垃圾回收等相關配置

-Xms2g -Xmx2g 8 ：-Xmx2g #java8 8 -：- Xmx2g #大於java8 8 - 9 ： - Xmx2g #java8到java9

export ES_JAVA_OPTS="$ES_JAVA_OPTS -Djava.io.tmpdir=/path/to/temp/dir"

設置Xmx和Xms你的物理內存不超過50％。Elasticsearch出於JVM堆之外的目的須要內存，所以爲此留出空間很重要。

設置Xmx而且Xms不超過JVM用於壓縮對象指針（JVM compressed oops）的閾值；確切的閾值有所不一樣，但接近32 GB（4-32G則啓用UseCompressedOop；）

3.四、相關插件配置

一、ik分詞插件配置

下載地址：https://github.com/medcl/elasticsearch-analysis-ik/releases

須要下載對應的版本，而後解壓在plugins目錄下，而後重啓集羣便可

 

二、head插件安裝

header插件上手

https://github.com/mobz/elasticsearch-head

https://nodejs.org/zh-cn/download/

第一種：使用谷歌瀏覽器head插件

第二種：使用head服務

#Running with built in server git clone git://github.com/mobz/elasticsearch-head.git cd elasticsearch-head npm install npm run start open http://localhost:9100/

三、hdfs插件（用於備份還原）

下載：https://artifacts.elastic.co/downloads/elasticsearch-plugins/repository-hdfs/repository-hdfs-7.8.1.zip

安裝文檔：https://www.elastic.co/guide/en/elasticsearch/plugins/7.9/plugin-management-custom-url.html  #7.9的文檔不影響哈

 具體執行：./bin/elasticsearch-plugin install file:///data/hd07/car/repository-hdfs-7.8.1.zip   #這裏不要忘記加file:///

而後須要重啓ES的集羣

3、索引要怎麼設計

　　首先索引建立後，索引的分片只能經過_split和_shrink接口對其進行成倍的增長和縮減，主要是由於es的數據是經過_routing分配到各個分片上面的，因此本質上是不推薦去改變索引的分片數量的，由於這樣都會對數據進行從新的移動。還有就是索引只能新增字段，不能對字段進行修改和刪除，缺少靈活性，因此每次都只能經過_reindex重建索引了。還有就是一個分片的大小以及因此分片數量的多少嚴重影響到了索引的查詢和寫入性能。因此可想而知，設計一個好的索引可以減小後期的運維管理和提升很多性能。因此前期對索引的設計是至關的重要的。

• 好的索引設計在整個集羣規劃中佔據舉足輕重的做用，索引的設計直接影響集羣設計的好壞和複雜度。
• 好的索引設計應該是充分結合業務場景的時間維度和空間維度，結合業務場景充分考量增、刪、改、查等全維度設計的。
• 好的索引設計是徹底基於「設計先行，編碼在後」的原則，前期會花很長時間，爲的是後期工做更加順暢，避免沒必要要的返工

索引的設計詳情見個人另一篇文章：elasticsearch如何設計索引

4、讀寫性能要怎麼提高

　　讀寫就是插入和查詢嘛，寫的話可能有併發寫，還有就是是否寫完要立馬可見，查的話仍是和需求有關係，還有就是對查詢一個語法的使用，還有就是查詢數據會不會在內存中命中，這樣的就減小去訪問磁盤了，這裏不說查詢的一些語法和怎麼查詢更優，由於我的以爲這是屬於應用級別的，和集羣相關性不強，這裏大概例舉幾個配置。

首先這裏說一句，當併發寫入的時候，一定涉及到thread pool的配置，這些配置不建議修改，可是實在不行，也能夠提升到cpu核數的兩倍，因此涉及到併發的，和計算的，固然cpu越好性能就會也好。

寫和查詢的時候會涉及到一些參數，能夠根據實際狀況調整提高性能：（下面的都不是默認值了，能夠在官網去查詢）

#能夠配置在elasticsearch.yml文件中
indices.memory.index_buffer_size: 20% indices.memory.min_index_buffer_size: 96mb indices.queries.cache.size: 20% indices.requests.cache.size: 2% 
#這裏是索引級別的配置，須要配置在索引裏面 index.merge.scheduler.max_thread_count: 1 #這個若是是ssd，使用默認的配置就好，這裏配置爲機械磁盤 index.refresh_interval: 60s index.store.type: hybridfs index.translog.sync_interval: 10s index.translog.flush_threshold_size: 1024mb

固然還有不少的配置，好比有配置translog的類型，能夠提高性能，可是可能會犧牲數據的一致性。優化這種事情仍是根據實際狀況進行鍼對性的優化和取捨比較好。

5、權限要怎麼控制

　　權限這個東西真的很重要，畢竟不是全部人操做起來都很當心，也不是全部人的技術都很牛逼，也不是全部人都不會偷偷的搞事情，因此這麼重要的數據固然須要管控起來撒。

直接參考個人另一篇博客吧，更加詳細：elasticsearch7.8權限控制和規劃

6、要怎麼備份和還原

　　如今不少集羣都是有多個副本，固然也是把容錯機制看的很重要，在這種分佈式的系統裏面，數據的容錯是很是重要的，好比elasticsearch，kafka，hdfs等，elasticsearch做爲一個高速度的查詢分佈式集羣，經過副原本進行容錯，可是通常推薦副本爲1，雖然大部分狀況下是不會丟數據，可是不免會存在特殊狀況。副本設置太多會影響性能，設置爲1比較合適，可是若是一個分片的主分片和副分片所在的磁盤同時出問題呢，或者兩臺機器同時出問題呢，或者這幾天操做異常，致使數據不正確，想恢復到幾天前的索引呢，因此備份就顯得尤其的重要了。

具體的備份還原詳細文檔請參考個人另外一篇文章：elasticsearch備份和還原（基於hdfs）

7、怎麼監控集羣

　　集羣正常運行了，咱們須要常常關注集羣的一些狀態，或者節點級別，索引級別的一些狀態，這些都是根據需求進行選擇，好比對於我來講，關心集羣的粒度既能夠了。

這裏監控能夠選不少種，好比elk，zabbix，prometheus等，固然看本身熟悉什麼了，就能夠選用什麼組件，不過elasticsearch這麼特別的集羣可使用elk，畢竟ES也是elk中的一員。

看看elk監控的官方架構：（還須要一個es集羣，不過節約點也能夠一個集羣，可是這樣不穩妥）

官網：https://www.elastic.co/guide/en/elasticsearch/reference/7.8/monitoring-overview.html

 

 固然我是沒有使用elk這樣的監控，由於對zabbix比較數據，需求也不高，經過zabbix的web監控就搞定了，複雜點的可使用elasticsearch的_cat API獲取集羣的相關狀態信息，結合zabbix監控也很簡單。

本文純屬我的的思考和想法，沒有具體去實踐（查詢理論。。。），固然理論是可靠的。固然目前的思考可能也不會很全面，也不知道給博友有沒有更好的建議呢？

 

參考：https://mp.weixin.qq.com/s?__biz=MzI2NDY1MTA3OQ%3D%3D&chksm=eaa82cfcdddfa5eacfcddb0cf54edcecb3ad86ca2cafd6f4f2d90cf8a4033d83eb16cb2a56f0&idx=1&mid=2247484628&scene=21&sn=666e416ae28b93e42c26f26b208dea84#wechat_redirect