1、集羣規劃html
搭建一個集羣咱們須要考慮以下幾個問題:node
1. 咱們須要多大規模的集羣?安全
2. 集羣中的節點角色如何分配?服務器
3. 如何避免腦裂問題?網絡
4. 索引應該設置多少個分片?併發
5. 分片應該設置幾個副本?elasticsearch
下面咱們就來分析和回答這幾個問題tcp
須要從如下兩個方面考慮:ide
1.1 當前的數據量有多大?數據增加狀況如何?
1.2 你的機器配置如何?cpu、多大內存、多大硬盤容量?高併發
推算的依據:
ES JVM heap 最大能夠設置32G 。
30G heap 大概能處理的數據量 10 T。若是內存很大如128G,可在一臺機器上運行多個ES節點實例。
備註:集羣規劃知足當前數據規模+適量增加規模便可,後續可按需擴展。
兩類應用場景:
A. 用於構建業務搜索功能模塊,且可能是垂直領域的搜索。數據量級幾千萬到數十億級別。通常2-4臺機器的規模。
B. 用於大規模數據的實時OLAP(聯機處理分析),經典的如ELK Stack,數據規模可能達到千億或更多。幾十到上百節點的規模。
2.1 節點角色:
Master
node.master: true 節點能夠做爲主節點
DataNode
node.data: true 默認是數據節點。
Coordinate node 協調節點
若是僅擔任協調節點,將上兩個配置設爲false。
說明:
一個節點能夠充當一個或多個角色,默認三個角色都有
協調節點:一個節點只做爲接收請求、轉發請求到其餘節點、彙總各個節點返回數據等功能的節點。就叫協調節點
2.2 如何分配:
A. 小規模集羣,不需嚴格區分。
B. 中大規模集羣(十個以上節點),應考慮單獨的角色充當。特別併發查詢量大,查詢的合併量大,能夠增長獨立的協調節點。角色分開的好處是分工分開,不互影響。如不會因協調角色負載太高而影響數據節點的能力。
3.1 腦裂問題:
一個集羣中只有一個A主節點,A主節點由於須要處理的東西太多或者網絡過於繁忙,從而致使其餘從節點ping不通A主節點,這樣其餘從節點就會認爲A主節點不可用了,就會從新選出一個新的主節點B。過了一會A主節點恢復正常了,這樣就出現了兩個主節點,致使一部分數據來源於A主節點,另一部分數據來源於B主節點,出現數據不一致問題,這就是腦裂。
3.2 儘可能避免腦裂,須要添加最小數量的主節點配置:
discovery.zen.minimum_master_nodes: (有master資格節點數/2) + 1
這個參數控制的是,選舉主節點時須要看到最少多少個具備master資格的活節點,才能進行選舉。官方的推薦值是(N/2)+1,其中N是具備master資格的節點的數量。
3.3 經常使用作法(中大規模集羣):
1. Master 和 dataNode 角色分開,配置奇數個master,如3
2. 單播發現機制,配置master資格節點:
discovery.zen.ping.multicast.enabled: false —— 關閉多播發現機制,默認是關閉的
discovery.zen.ping.unicast.hosts: ["master1", "master2", "master3"] —— 配置單播發現的主節點ip地址,其餘從節點要加入進來,就得去詢問單播發現機制裏面配置的主節點我要加入到集羣裏面了,主節點贊成之後才能加入,而後主節點再通知集羣中的其餘節點有新節點加入
3. 配置選舉發現數,及延長ping master的等待時長
discovery.zen.ping_timeout: 30(默認值是3秒)——其餘節點ping主節點多久時間沒有響應就認爲主節點不可用了
discovery.zen.minimum_master_nodes: 2 —— 選舉主節點時須要看到最少多少個具備master資格的活節點,才能進行選舉
說明:分片數指定後不可變,除非重索引。
思考:
分片對應的存儲實體是什麼?
存儲的實體是索引
分片是否是越多越好?
不是
分片多有什麼影響?
分片多浪費存儲空間、佔用資源、影響性能
每一個分片本質上就是一個Lucene索引, 所以會消耗相應的文件句柄, 內存和CPU資源。
每一個搜索請求會調度到索引的每一個分片中. 若是分片分散在不一樣的節點卻是問題不太. 但當分片開始競爭相同的硬件資源時, 性能便會逐步降低。
ES使用詞頻統計來計算相關性. 固然這些統計也會分配到各個分片上. 若是在大量分片上只維護了不多的數據, 則將致使最終的文檔相關性較差。
ElasticSearch推薦的最大JVM堆空間是30~32G, 因此把你的分片最大容量限制爲30GB, 而後再對分片數量作合理估算. 例如, 你認爲你的數據能達到200GB, 推薦你最多分配7到8個分片。
在開始階段, 一個好的方案是根據你的節點數量按照1.5~3倍的原則來建立分片. 例如,若是你有3個節點, 則推薦你建立的分片數最多不超過9(3x3)個。當性能降低時,增長節點,ES會平衡分片的放置。
對於基於日期的索引需求, 而且對索引數據的搜索場景很是少. 也許這些索引量將達到成百上千, 但每一個索引的數據量只有1GB甚至更小. 對於這種相似場景, 建議只須要爲索引分配1個分片。如日誌管理就是一個日期的索引需求,日期索引會不少,但每一個索引存放的日誌數據量就不多。
說明:副本數是能夠隨時調整的!
思考:
副本的用途是什麼?
備份數據保證高可用數據不丟失,高併發的時候參與數據查詢
針對它的用途,咱們該如何設置它的副本數?
通常一個分片有1-2個副本便可保證高可用
集羣規模沒變的狀況下副本過多會有什麼影響?
副本多浪費存儲空間、佔用資源、影響性能
爲保證高可用,副本數設置爲2便可。要求集羣至少要有3個節點,來分開存放主分片、副本。
如發現併發量大時,查詢性能會降低,可增長副本數,來提高併發查詢能力。
注意:新增副本時主節點會自動協調,而後拷貝數據到新增的副本節點
192.168.152.128 、192.168.152.12九、192.168.152.130
安裝教程參考我以前寫的文章的ES的安裝和配置部分:
https://www.cnblogs.com/leeSmall/p/9189078.html
進入elasticsearch的config目錄,修改elasticsearch.yml的配置
這裏有兩個須要提醒下,第一個就是IP訪問限制,第二個就是es實例的默認端口號9200。IP訪問限制能夠限定具體的IP訪問服務器,這有必定的安全過濾做用。
# Set the bind address to a specific IP (IPv4 or IPv6):
#
network.host: 192.168.152.128
若是設置成0.0.0.0則是不限制任何IP訪問。通常在生產的服務器可能會限定幾臺IP,一般用於管理使用。
默認的端口9200在通常狀況下也有點風險,能夠將默認的端口修改爲另一個,這還有一個緣由就是怕開發人員誤操做,鏈接上集羣。固然,若是你的公司網絡隔離作的很好也無所謂。
#
# Set a custom port for HTTP:
#
http.port: 9200 transport.tcp.port: 9300
這裏的9300是集羣內部通信使用的端口,這個也能夠修改掉。由於鏈接集羣的方式有兩種,經過扮演集羣node也是能夠進入集羣的,因此仍是安全起見,修改掉默認的端口。
說明:記得修改安裝了ES的3臺虛擬機(三個節點)的相同配置,要否則節點之間沒法創建鏈接工做,也會報錯。
緊接着修改集羣節點IP地址,這樣可讓集羣在規定的幾個節點之間工做。elasticsearch,默認是使用自動發現IP機制。就是在當前網段內,只要能被自動感知到的IP就能自動加入到集羣中。這有好處也有壞處。好處就是自動化了,當你的es集羣須要雲化的時候就會很是方便。可是也會帶來一些不穩定的狀況,如,master的選舉問題、數據複製問題。
致使master選舉的因素之一就是集羣有節點進入。當數據複製發生的時候也會影響集羣,由於要作數據平衡複製和冗餘。這裏面能夠獨立master集羣,剔除master集羣的數據節點能力。
固定列表的IP發現有兩種配置方式,一種是互相依賴發現,一種是全量發現。各有優點吧,我是使用的依賴發現來作的。這有個很重要的參考標準,就是你的集羣擴展速度有多快。由於這有個問題就是,當全量發現的時候,若是是初始化集羣會有很大的問題,就是master全局會很長,而後節點之間的啓動速度各不同。因此我採用了靠譜點的依賴發現。
你須要在192.168.152.128的elasticsearch中配置成:
# --------------------------------- Discovery ----------------------------------
#
# Pass an initial list of hosts to perform discovery when new node is started:
# The default list of hosts is ["127.0.0.1", "[::1]"]
#
discovery.zen.ping.unicast.hosts: [ "192.168.152.129:9300","192.168.152.130:9300" ]
讓他去發現129,130的機器,以此內推,完成剩下的129和130機器的配置。
而後你須要配置下集羣名稱,就是你當前節點所在集羣的名稱,這有助於你規劃你的集羣。集羣中的全部節點的集羣名稱必須同樣,只有集羣名稱同樣才能組成一個邏輯集羣。
# ---------------------------------- Cluster -----------------------------------
#
# Use a descriptive name for your cluster:
#
cluster.name: mycluster
配置你當前節點的名稱
#
# ------------------------------------ Node ------------------------------------
#
# Use a descriptive name for the node:
#
node.name: node-1
以此類推,完成另外兩個節點的配置。cluster.name的名稱必須保持同樣。而後分別設置node.name。
說明:
這裏搭建的是一個簡單的集羣,沒有作集羣節點角色的區分,因此3個節點默認的角色有主節點、數據節點、協調節點
選舉ES主節點的邏輯:
選舉的大概邏輯,它會根據分片的數據的先後新鮮程度來做爲選舉的一個重要邏輯。(日誌、數據、時間都會做爲集羣master全局的重要指標)
由於考慮到數據一致性問題,固然是用最新的數據節點做爲master,而後進行新數據的複製和刷新其餘node。
http://localhost:9200/_cat
GET /_cat /_cat/health /_cat/nodes /_cat/master /_cat/indices /_cat/allocation /_cat/shards /_cat/shards/{index} /_cat/thread_pool /_cat/segments /_cat/segments/{index}
爲集羣提供安全防禦、監控、告警、報告等功能的收費組件;
部分免費:https://www.elastic.co/subscriptions
6.3開始已開源,並併入了elasticsearch核心中。
官網安裝介紹:
https://www.elastic.co/guide/en/elasticsearch/reference/6.2/installing-xpack-es.html
參考文章:
集羣搭建一:https://www.cnblogs.com/wangiqngpei557/p/5967377.html
集羣搭建二:https://www.cnblogs.com/jstarseven/p/6803054.html 這一篇文章寫得比較詳細,同時還總結了搭建過程當中遇到的問題,搭建ES集羣的話強烈推薦