本文爲博客園作者所寫： 一寸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