本文為部落格園作者所寫： 一寸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 機器也是很常見的。
2、磁碟
硬碟對所有的叢集都很重要，對大量寫入的叢集更是加倍重要（例如那些儲存日誌資料的）。硬碟是伺服器上最慢的子系統，這意味著那些寫入量很大的叢集很容易讓硬碟飽和，使得它成為叢集的瓶頸。
如果你負擔得起 SSD，它將遠遠超出任何旋轉介質（注：機械硬碟，磁帶等）。 基於 SSD 的節點，查詢和索引效能都有提升。如果你負擔得起，SSD 是一個好的選擇，如果使用了機械磁碟，使用 RAID 0 是提高硬碟速度的有效途徑，對機械硬碟和 SSD 來說都是如此。沒有必要使用映象或其它 RAID 變體，因為高可用已經通過 replicas 內建於 Elasticsearch 之中，再不濟，一臺機器也多弄幾個磁碟，這樣在配置的可以指定多幾個目錄，這樣能降低一個磁碟的io壓力。
3、cpu
大多數 Elasticsearch 部署往往對 CPU 要求不高。因此，相對其它資源，具體配置多少個（CPU）不是那麼關鍵。但是還是建議16核以上作為生產環境，因為elasticsearch的thread pool和這個配置直接相關。如果你要在更快的 CPUs 和更多的核心之間選擇，選擇更多的核心更好。多個核心提供的額外併發遠勝過稍微快一點點的時脈頻率。
4、網路
快速可靠的網路顯然對分散式系統的效能是很重要的。 低延時能幫助確保節點間能容易的通訊，大頻寬能幫助分片移動和恢復。現代資料中心網路（1 GbE, 10 GbE）對絕大多數叢集都是足夠的。Elasticsearch 假定所有節點都是平等的—並不會因為有一半的節點在150ms 外的另一資料中心而有所不同。更大的延時會加重分散式系統中的問題而且使得除錯和排錯更困難。
參考《ES權威指南》：https://www.elastic.co/guide/cn/elasticsearch/guide/current/hardware.html
二、叢集安裝要怎麼配置和設計
2.1、系統設定
官網：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.2、基本安裝配置
節點設計：
預設情況下，所有的節點都是master節點，data節點，ingest節點，ml節點（如果為true），資料節點也是transform節點
節點的型別：
- Master-eligible node 候選主節點node.master: true，主節點負責建立或刪除索引，跟蹤哪些節點是叢集的一部分，以及決定將哪些碎片分配給哪些節點。所有的候選主節點在沒有配置node.voting_only: true的情況下，都可以通過選舉稱為主節點。主節點必須能夠訪問data資料目錄，也可以設定專用的主節點，一般至少選用3臺，把其他的角色設定為false即可。
- Data node 用於資料的儲存，CRUD，搜尋，聚合等,node.data: true，資料節點儲存包含已建立索引的文件的分片。資料節點處理與資料相關的操作，如CRUD、搜尋和聚合。這些操作是I/O密集型、記憶體密集型和cpu密集型，也可以設定專用的資料節點
- Ingest node 用於資料前期的預處理，類似logstash，node node.ingest: true
- Machine learning node 用於執行作業和處理機器學習API請求
- Transform node 用於資料轉換node.transform: true，如果是資料節點，則預設為true，否則false
- 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.3、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.4、相關外掛配置
1、ik分詞外掛配置
下載地址：https://github.com/medcl/elasticsearch-analysis-ik/releases
需要下載對應的版本，然後解壓在plugins目錄下，然後重啟叢集即可
2、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/ |
3、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的叢集
三、索引要怎麼設計
首先索引建立後，索引的分片只能通過_split和_shrink介面對其進行成倍的增加和縮減，主要是因為es的資料是通過_routing分配到各個分片上面的，所以本質上是不推薦去改變索引的分片數量的，因為這樣都會對資料進行重新的移動。還有就是索引只能新增欄位，不能對欄位進行修改和刪除，缺乏靈活性，所以每次都只能通過_reindex重建索引了。還有就是一個分片的大小以及所以分片數量的多少嚴重影響到了索引的查詢和寫入效能。所以可想而知，設計一個好的索引能夠減少後期的運維管理和提高不少效能。所以前期對索引的設計是相當的重要的。
- 好的索引設計在整個叢集規劃中佔據舉足輕重的作用，索引的設計直接影響叢集設計的好壞和複雜度。
- 好的索引設計應該是充分結合業務場景的時間維度和空間維度，結合業務場景充分考量增、刪、改、查等全維度設計的。
- 好的索引設計是完全基於“設計先行，編碼在後”的原則，前期會花很長時間，為的是後期工作更加順暢，避免不必要的返工
索引的設計詳情見我的另外一篇文章：elasticsearch如何設計索引
四、讀寫效能要怎麼提升
讀寫就是插入和查詢嘛，寫的話可能有併發寫，還有就是是否寫完要立馬可見，查的話還是和需求有關係，還有就是對查詢一個語法的使用，還有就是查詢資料會不會在記憶體中命中，這樣的就減少去訪問磁碟了，這裡不說查詢的一些語法和怎麼查詢更優，因為個人覺得這是屬於應用級別的，和叢集相關性不強，這裡大概例舉幾個配置。
首先這裡說一句，當併發寫入的時候，必定涉及到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的型別，可以提升效能，但是可能會犧牲資料的一致性。優化這種事情還是根據實際情況進行鍼對性的優化和取捨比較好。
五、許可權要怎麼控制
許可權這個東西真的很重要，畢竟不是所有人操作起來都很小心，也不是所有人的技術都很牛逼，也不是所有人都不會偷偷的搞事情，所以這麼重要的資料當然需要管控起來撒。
直接參考我的另外一篇部落格吧，更加詳細：elasticsearch7.8許可權控制和規劃
六、要怎麼備份和還原
現在很多叢集都是有多個副本，當然也是把容錯機制看的很重要，在這種分散式的系統裡面，資料的容錯是非常重要的，比如elasticsearch，kafka，hdfs等，elasticsearch作為一個高速度的查詢分散式叢集，通過副本來進行容錯，但是一般推薦副本為1，雖然大部分情況下是不會丟資料，但是難免會存在特殊情況。副本設定太多會影響效能，設定為1比較合適，但是如果一個分片的主分片和副分片所在的磁碟同時出問題呢，或者兩臺機器同時出問題呢，或者這幾天操作異常，導致資料不正確，想恢復到幾天前的索引呢，所以備份就顯得尤為的重要了。
具體的備份還原詳細文件請參考我的另一篇文章：elasticsearch備份和還原（基於hdfs）
七、怎麼監控叢集
叢集正常執行了，我們需要經常關注叢集的一些狀態，或者節點級別，索引級別的一些狀態，這些都是根據需求進行選擇，比如對於我來說，關心叢集的粒度既可以了。
這裡監控可以選很多種，比如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