node module，主要是用來處理各種不同類型的節點的，es有哪些類型的node，另外就是對這些類型的node有些什么特殊的參數，對于一個較大的集群來說，如何去規劃和配置各種各樣的node

1、node類型

如果我們啟動es的一個實例，那么就是啟動了一個es node，一些es node就可以組成一個es集群。如果僅僅運行了一個es node，那么也有一個es集群，只是節點數量就是1。

集群中的每個node都可以處理http和transport請求，其中transport層是用來處理節點間的通信的，http層是用來處理外部的客戶端rest請求的。

所有的node都知道集群中的其他node，并且可以將客戶端的請求轉發到適當的節點上去。

節點的類型包含以下幾種：

（1）master-eligible node：master候選節點，將node.master設置為true（默認），代表這個node就是master的候選節點，可以被選舉為master node，然后控制整個集群。

（2）data node：將node.data設置為true（默認），data node可以存儲數據，同時處理這些數據相關的操作，比如CRUD操作，搜索操作，聚合操作，等等。

（3）ingest node：將node.ingest設置為true（默認），ingest node是用來對document寫入索引文件之前進行預處理的。可以對每個document都執行一條ingest pipeline，在document寫入索引文件之前，先對其數據進行處理和轉化。但是如果要執行的ingest操作太過繁重，那么可以規劃單獨的一批ingest node出來，然后將node.master和node.data都設置為false即可。

（4）tribe node：tribe node可以通過tribe.*相關參數來設置，它是一種特殊的coordinate node，可以連接到多個es集群上去，然后對多個集群執行搜索等操作。

（5）默認情況下，每個node的node.master，node.data，node.ingest都是true，都是master候選節點，也可以作為data node存儲和操作數據，同時也可以作為ingest node對數據進行預處理。對于小于20個節點的小集群來說，這種架構是ok的，沒問題的。但是如果對于大于20個物理機的集群來說，最好是單獨規劃出master node、data node和ingest node來。

（6）coordinate node

搜索和bulk等請求可能會涉及到多個節點上的不同shard里的數據，比如一個search請求，就需要兩個階段執行，首先第一個階段就是一個coordinating node接收到這個客戶端的search request。接著，coordinating node會將這個請求轉發給存儲相關數據的node，每個data node都會在自己本地執行這個請求操作，同時返回結果給coordinating node，接著coordinating node會將返回過來的所有的請求結果進行縮減和合并，合并為一個global結果。

每個node都是一個coordinating node。這就意味著如果一個node，將node.master，node.data，node.ingest全部設置為false，那么它就是一個純粹的coordinating node，僅僅用于接收客戶端的請求，同時進行請求的轉發和合并。

如果真的是大集群的話，最好也是單獨規劃一批node出來，就作為coordinating node，然后讓es client全部往這些node上去發送請求。

如果真的是一個大于20個節點的生產集群的話，建議將4種node，master node，data node，ingest node，cooridating node，全部分離開來

集群中有30臺機器

master node：3個

ingest node：視具體情況而定，具體是看你的ingest預處理操作有多么的復雜，耗費多少資源，但是一般情況下來說，es ingest node用的比較少的，ingest node也可以不用單獨規劃一批出來

coordinate node：視具體情況而定，但是對于大集群來說，最好是單獨拆幾個節點出來，用于接收客戶端的請求，3個節點。主要是看你的并發訪問量有多大，比如說你的最大的QPS也就是10，或者是100，那么3個節點肯定夠了。如果你的QPS是1000，或者是10000，那么可能就要規劃，10個coordinate node，或者100個

data node：24個data node，data node肯定是分配的是最多的，主要用來存儲數據，執行各種對數據的操作么，資源耗費肯定是最多的

2、master eligible node

（1）master-eligible node的介紹以及配置

master node負責輕量級的集群管理工作，比如創建和刪除索引，追蹤集群中的每個node，決定如何將shards分配給各個node。對于集群來說，有一個穩定的master node，是非常關鍵的。然后master-eligible node都有機會被選舉為一個master node，同時master node必須有權限訪問path.data指定的data目錄，因為master node需要在data目錄中存儲cluster state。

對數據進行index和search操作，會耗費大量的cpu，內存，磁盤io，以及網絡io，耗費的是每個node的資源。因此我們必須要確保master node是非常穩定的，而且是壓力不大的，對于大集群來說，比較好的辦法是劃分出單獨的master node和data node。如果不拆開的話，一個node又要是data node，要復雜存儲數據，處理各種操作，同時又要負責管理集群，可能就會不穩定，出問題。

同時因為默認情況下，master node也能扮演coordinating node的角色，并且將search和index請求路由到對應的data node上去執行，最好是不要讓master node來執行這些coordinate操作。因為msater node的穩定運行對于整個集群來說非常重要，比你利用master node資源來執行一些coordinate操作要重要的多。

如果要設置一個node為專門的master-eligible node，需要做如下的設置：

node.master: true node.data: false node.ingest: false

（2）通過minimum_master_nodes來避免腦裂問題

要預防數據的丟失，我們就必須設置discovery.zen.minimum_master_nodes參數為一個合理的值，這樣的話，每個master-eligible node才知道至少需要多少個master-eligible node才能組成一個集群。

比如說，我們現在有一個集群，其中包含兩個master-eligible nodes。然后一個網絡故障發生了，這兩個節點之間丟失了聯絡。每個節點都認為當前只有一個master-eligible node，就是它們自己。此時如果discovery.zen.minimum_master_nodes參數的默認值是1，那么每個node就可以讓自己組成一個集群，選舉自己為master node即可。結果就會導致出現了兩個es集群，這就是腦裂現象。即使網絡故障解決了，但是這兩個master node是不可能重新組成一個集群了。除非某個master eligible node重啟，然后自動加入另外一個集群，但是此時寫入這個節點的數據就會徹底丟失。

那么如果現在我們有3個master-eligible node，同時將discovery.zen.minimum_master_nodes設置為2.如果網絡故障發生了，此時一個網絡分區有1個node，另外一個網絡分區有2個node，只有一個node的那個網絡分區，沒法檢測到足夠數量的master-eligible node，那么此時它就不能選舉一個master node出來組成一個新集群。但是有兩個node的那個網絡分區，它們會發現這里有足夠數量的master-eligible node，那么就選舉出一個新的master，然后組成一個集群。當網絡故障解除之后，那個落單的node就會重新加入集群中。

discovery.zen.minimum_master_nodes，必須設置為master-eligible nodes的quorum，quorum的公式為：(master_eligible_nodes / 2) + 1。

換句話來說，如果有3個master-eligible nodes，那么那個參數就必須設置為(3 / 2) + 1 = 2，比如下面這樣：

discovery.zen.minimum_master_nodes: 2

隨著集群節點的上線和下限，這個參數都是要重新設置的，可以通過api來設置

PUT_cluster/settings
{
"transient":{
"discovery.zen.minimum_master_nodes":2
}
}

此時將master node和data node分離的好處就出來了，一般如果單獨規劃一個master nodes的話，只要規劃固定的3個node是master-eligible node就可以了，那么data node無論上線和下限多少個，都無所謂的。

3、data node

data node負責存儲shard的數據，也就是那些document。data node可以處理各種操作，比如CRUD，搜索，聚合。這些操作全都是很耗費IO，內存和cpu資源的。因此監控這些資源的使用是很重要的，同時如果資源過載了，那么就要添加更多的data node。

如果要設置一個專門的data node，需要做出如下的設置：

node.master: false node.data: true node.ingest: false

4、ingest node

nigest node可以執行預處理pipeline，包含了多個ingest processors。不同的ingest processor執行的操作類型是不同的，那么對資源的需求也是不同的，不過還是最好是規劃一批單獨的ingest node出來，不要跟master node和data node混合在一起。

如果要配置一個單獨的ingest node：

node.master: false node.data: false node.ingest: true search.remote.connect: false

5、cooridnating only node

如果我們規劃了一批專門的master node，data node以及ingest node，那么此時還遺留下來了一種node，那就是coordinating node，這些node專門用來接收客戶端的請求，同時對請求進行路由和轉發，并對請求的結果進行合并。

coordinating only nodes對于大集群來說，可以使用專門的node來負載coordinate操作，而不是讓coordinate操作的工作負載集中到master node和data node上去。coordinating node也會加入cluster，同時可以獲取到完整的cluster state，它們主要是用cluster state中包含的node info來進行請求轉發。

如果在一個集群中規劃太多的coordinating node可能會加重整個集群的負擔，因為被選舉出來的master node必須要從所有的node上得到cluster state update的ack，如果coordinating nodes過多，那么可能會加重master node的負擔。

如果要設置coordinating only node的話：

node.master: false node.data: false node.ingest: false search.remote.connect: false

6、node data path設置

（1）path.data

每個data和master-eligible node都需要能夠訪問data目錄，在那里存儲了每個shard的數據，包括cluster state也存儲在那里。path.data默認是指向$ES_HOME/data目錄的，但是在生產環境中，肯定是不能這樣設置的，因為在升級es的時候，可能會導致數據被清空或者覆蓋。

此時一般需要在elasticsearch.yml中設置path.data：

path.data: /var/elasticsearch/data

（2）node.max_local_storage_nodes

data目錄可以被多個node共享，即使是不同集群中的es node，也許他們在一個物理機上啟動了。這個共享的方式對于我們測試failover是很有用的，以及在開發機上測試不同的配置。但是在生產環境下，絕對不用這么做，一個data目錄就給一個es node使用即可。默認情況下，es被配置成阻止超過一個node共享data目錄中的數據，如果要允許多個node共享一個data目錄，需要設置node.max_local_storage_nodes為一個超過1的數字。

編輯：黃飛