1. 程式人生 > >elasticsearch生產叢集部署-3個節點叢集部署

elasticsearch生產叢集部署-3個節點叢集部署

1、在三個節點上都下載es

es安裝包的目錄結構大致如下:

bin:存放es的一些可執行指令碼,比如用於啟動程序的elasticsearch命令,以及用於安裝外掛的elasticsearch-plugin外掛
conf:用於存放es的配置檔案,比如elasticsearch.yml
data:用於存放es的資料檔案,就是每個索引的shard的資料檔案
logs:用於存放es的日誌檔案
plugins:用於存放es的外掛
script:用於存放一些指令碼檔案

2、zen discovery叢集發現機制

你會在多臺機器上,每臺機器部署一個es程序,每臺機器都啟動一個es程序,你怎麼讓多臺機器上的多個es程序,互相發現對方,然後完美的組成一個生產環境的es叢集呢???。。。。

預設情況下,es程序會繫結在自己的迴環地址上,也就是127.0.0.1,然後掃描本機上的9300~9305埠號,嘗試跟那些埠上啟動的其他es程序進行通訊,然後組成一個叢集。這對於在本機上搭建es叢集的開發環境是很方便的。但是對於生產環境下的叢集是不行的,需要將每臺es程序繫結在一個非迴環的ip地址上,才能跟其他節點進行通訊,同時需要使用叢集發現機制來跟其他節點上的es node進行通訊。

大家還記不記得,我們如果在windows上自己玩兒的話,是不是說,你直接啟動多個es程序,他們自己就會組成一個叢集

在生產環境中的多臺機器上部署es叢集,就涉及到了es的discovery機制,也就是叢集中各個節點互相發現然後組成一個叢集的機制,同時discovery機制也負責es叢集的master選舉,關於master,一會兒會講解s

master node和data node兩種角色

es是一種peer to peer,也就是p2p點對點的分散式系統架構,不是hadoop生態普遍採用的那種master-slave主從架構的分散式系統。叢集中的每個node是直接跟其他節點進行通訊的,而不是hadoop生態系統中的那種master-slave分散式系統架構。幾乎所有的API操作,比如index,delete,search,等等,都不是說client跟master通訊,而是client跟任何一個node進行通訊,那個node再將請求轉發給對應的node來進行執行。這塊的原理,路由,讀寫原理,在入門篇都講解過了。

兩個角色,master node,data node。正常情況下,就只有一個master node。master node的責任就是負責維護整個叢集的狀態資訊,也就是一些叢集元資料資訊,同時在node加入叢集或者從叢集中下限覅按時,重新分配shard,或者是建立或刪除了一個索引。包括每次cluster state如果有改變的化,那麼master都會負責將叢集狀態同步給所有的node。

master node負責接收所有的cluster state相關的變化資訊,然後將這個改變後的最新的cluster state推動給叢集中所有的data node,叢集中所有的node都有一份完整的cluster state。只不過master node負責維護而已。其他的node,除了master之外的node,就是負責資料的儲存和讀寫的,寫入索引,搜尋資料,data node。

如果要讓多個node組成一個es叢集,首先第一個要設定的引數,就是cluster.name,多個node的cluster.name如果一樣,才滿足組成一個叢集的基本條件。

這個cluster.name的預設值是elasticsearch,在生產環境中,一定要修改這個值,否則可能會導致未知的node無端加入叢集,造成叢集執行異常。

而es中預設的discovery機制,就是zen discovery機制

zen discovery機制提供了unicast discovery叢集發現機制,叢集發現時的節點間通訊是依賴的transport module,也就是es底層的網路通訊模組和協議。

es預設配置為使用unicast叢集發現機制,以讓經過特殊配置的節點可以組成一個叢集,而不是隨便哪個節點都可以組成一個叢集。但是預設配置下,unicast是本機,也就是localhost,因此只能在一臺機器上啟動多個node來組成一個叢集。雖然es還是會提供multicast plugin作為一個發現機制,但是已經不建議在生產環境中使用了。雖然我們可能想要multicast的簡單性,就是所有的node可以再接收到一條multicast ping之後就立即自動加入叢集。但是multicast機制有很多的問題,而且很脆弱,比如網路有輕微的調整,就可能導致節點無法發現對方。因此現在建議在生產環境中用unicast機制,提供一個es種子node作為中轉路由節點就可以了。

(0)master node、data node、network.host

給叢集規劃出專門的master eligible node和data node

master node,master eligible node,data node

你配置的時候,是配置多個node變成master eligible node,但是隻是說,從這些master eligible node選舉一個node出來作為master node,其他master eligible node只是接下來有那個master node故障的時候,接替他的資格,但是還是作為data node去使用的

一般建議master eligible node給3個即可:node.master: true,node.data: false
剩下的node都設定為data node:node.master: false,node.data: true

但是如果一個小叢集,就10個以內的節點,那就所有節點都可以作為master eligible node以及data node即可,超過10個node的叢集再單獨拆分master和data node吧

如果你的節點數量小於10個,小叢集,那所有的node,就不要做額外的配置了,master eligible node,同時也是data node

預設情況下,es會將自己繫結到127.0.0.1上,對於執行一個單節點的開發模式下的es是ok的。但是為了讓節點間可以互相通訊以組成一個叢集,需要讓節點繫結到一個ip地址上,非會換的地址,一般會配置:network.host: 192.168.1.10。一旦我們配置了network.host,那麼es就會認為我們從開發模式遷移到生產模式,同時會啟用一系列的bootstrap check。

(1)ping

ping是一個node用discovery機制來發現其他node的一個過程

(2)unicast

unicast discovery叢集發現機制是要求配置一個主機列表,用來作為gossip(流言式)通訊協議的路由器。這些機器如果通過hostname來指定,那麼在ping的時候會被解析為ip地址。unicast discovery機制最重要的兩個配置如下所示:

hosts:用逗號分割的主機列表
hosts.resolve_timeout:hostname被DNS解析為ip地址的timeout等待時長

簡單來說,如果要讓多個節點發現對方並且組成一個叢集,那麼就得有一箇中間的公共節點,然後不同的節點就傳送請求到這些公共節點,接著通過這些公共節點交換各自的資訊,進而讓所有的node感知到其他的node存在,並且進行通訊,最後組成一個叢集。這就是基於gossip流言式通訊協議的unicast叢集發現機制。

當一個node與unicast node list中的一個成員通訊之後,就會接收到一份完整的叢集狀態,這裡會列出叢集中所有的node。接著那個node再通過cluster state跟master通訊,並且加入叢集中。這就意味著,我們的unicast list node是不需要列出叢集中的所有節點的。只要提供少數幾個node,比如3個,讓新的node可以連線上即可。如果我們給叢集中分配了幾個節點作為專門的master節點,那麼只要列出我們那三個專門的master節點即可。用如下的配置即可:discovery.zen.ping.unicast.hosts: ["host1", "host2:port"]。

cluster.name
node.name
network.host
discovery.zen.ping.unicast.hosts

(1)已經初步配置好了,各個節點,首先通過network.host繫結到了非迴環的ip地址,從而可以跟其他節點通訊
(2)通過discovery.zen.ping.unicast.hosts配置了一批unicast中間路由的node
(3)所有node都可以傳送ping訊息到路由node,再從路由node獲取cluster state回來
(4)接著所有node會選舉出一個master
(5)所有node都會跟master進行通訊,然後加入master的叢集
(6)要求cluster.name必須一樣,才能組成一個叢集
(7)node.name就標識出了每個node我們自己設定的一個名稱

(3)master選舉

在ping發現過程中,為叢集選舉出一個master也是很重要的,es叢集會自動完成這個操作。這裡建議設定discovery.zen.ping_timeout引數(預設是3s),如果因為網路慢或者擁塞,導致master選舉超時,那麼可以增加這個引數,確保叢集啟動的穩定性。

在完成一個叢集的master選舉之後,每次一個新的node加入叢集,都會發送一個join request到master node,可以設定discovery.zen.join_timeout保證node穩定加入叢集,增加join的timeout等待時長,如果一次join不上,預設會重試20次。

如果master node被停止了,或者自己宕機了,那麼叢集中的node會再次進行一次ping過程,並且選舉出一個新的master。如果discovery.zen.master_election.ignore_non_master_pings設定為了true,那麼會強制區分master候選節點,如果node的node.master設定為了false,還來發送ping請求參與master選舉,那麼這些node會被忽略掉,因為他們沒有資格參與。

discovery.zen.minimum_master_nodes引數用於設定對於一個新選舉的master,要求必須有多少個master候選node去連線那個新選舉的master。而且還用於設定一個叢集中必須擁有的master候選node。如果這些要求沒有被滿足,那麼master node就會被停止,然後會重新選舉一個新的master。這個引數必須設定為我們的master候選node的quorum數量。一般避免說只有兩個master候選node,因為2的quorum還是2。如果在那個情況下,任何一個master候選節點宕機了,叢集就無法正常運作了。

(4)叢集故障的探查

es有兩種叢集故障探查機制,第一種是通過master進行的,master會ping叢集中所有的其他node,確保它們是否是存活著的。第二種,每個node都會去ping master node來確保master node是存活的,否則就會發起一個選舉過程。

有下面三個引數用來配置叢集故障的探查過程:

ping_interval:每隔多長時間會ping一次node,預設是1s
ping_timeout:每次ping的timeout等待時長是多長時間,預設是30s
ping_retries:如果一個node被ping多少次都失敗了,就會認為node故障,預設是3次

(5)叢集狀態更新

master node是叢集中唯一一個可以對cluster state進行更新的node。master node每次會處理一個叢集狀態的更新事件,應用這次狀態更新,然後將更新後的狀態釋出到叢集中所有的node上去。每個node都會接收publish message,ack這個message,但是不會應用這個更新。如果master沒有在discovery.zen.commit_timeout指定的時間內(預設是30s),從至少discovery.zen.minimum_master_nodes個節點獲取ack響應,那麼這次cluster state change事件就會被reject,不會應用。

但是一旦在指定時間內,指定數量的node都返回了ack訊息,那麼cluster state就會被commit,然後一個message會被髮送給所有的node。所有的node接收到那個commit message之後,接著才會將之前接收到的叢集狀態應用到自己本地的狀態副本中去。接著master會等待所有節點再次響應是否更新自己本地副本狀態成功,在一個等待超時時長內,如果接收到了響應,那麼就會繼續處理記憶體queue中儲存的下一個更新狀態。discovery.zen.publish_timeout預設是30s,這個超時等待時長是從plublish cluster state開始計算的。

(6)不因為master宕機阻塞叢集操作

如果要讓叢集正常運轉,那麼必須有一個master,還有discovery.zen.minimum_master_nodes指定數量的master候選node,都在執行。discovery.zen.no_master_block可以控制當master當即時,什麼樣的操作應該被拒絕。有下面兩個選項:

all:一旦master當即,那麼所有的操作都會被拒絕
write:這是預設的選項,所有的寫操作都會被拒絕,但是讀操作是被允許的