Elasticsearch天生就支持分佈式部署，通過集羣部署可以提高系統的可用性。本文重點談一談Elasticsearch的集羣節點相關問題，搞清楚這些是進行Elasticsearch集羣部署和拓撲結構設計的前提。關於如何配置集羣的配置文件不會在本文中提及。（本文寫作背景是Elasticsearch 2.3）
節點類型
1. 候選主節點（Master-eligible node）
一個節點啓動後，就會使用Zen Discovery機制去尋找集羣中的其他節點，並與之建立連接。集羣中會從候選主節點中選舉出一個主節點，主節點負責創建索引、刪除索引、分配分片、追蹤集羣中的節點狀態等工作。Elasticsearch中的主節點的工作量相對較輕，用戶的請求可以發往任何一個節點，由該節點負責分發和返回結果，而不需要經過主節點轉發。
正常情況下，集羣中的所有節點，應該對主節點的選擇是一致的，即一個集羣中只有一個選舉出來的主節點。然而，在某些情況下，比如網絡通信出現問題、主節點因爲負載過大停止響應等等，就會導致重新選舉主節點，此時可能會出現集羣中有多個主節點的現象，即節點對集羣狀態的認知不一致，稱之爲腦裂現象。爲了儘量避免此種情況的出現，可以通過discovery.zen.minimum_master_nodes來設置最少可工作的候選主節點個數，建議設置爲(候選主節點數 / 2) + 1, 比如，當有三個候選主節點時，該配置項的值爲(3/2)+1=2，也就是保證集羣中有半數以上的候選主節點。
候選主節點的設置方法是設置node.mater爲true，默認情況下，node.mater和node.data的值都爲true，即該節點既可以做候選主節點也可以做數據節點。由於數據節點承載了數據的操作，負載通常都很高，所以隨着集羣的擴大，建議將二者分離，設置專用的候選主節點。當我們設置node.data爲false，就將節點設置爲專用的候選主節點了。
node.master = true
node.data = false
2. 數據節點（Data node）
數據節點負責數據的存儲和相關具體操作，比如CRUD、搜索、聚合。所以，數據節點對機器配置要求比較高，首先需要有足夠的磁盤空間來存儲數據，其次數據操作對系統CPU、Memory和IO的性能消耗都很大。通常隨着集羣的擴大，需要增加更多的數據節點來提高可用性。
前面提到默認情況下節點既可以做候選主節點也可以做數據節點，但是數據節點的負載較重，所以需要考慮將二者分離開，設置專用的數據節點，避免因數據節點負載重導致主節點不響應。
node.master = false
node.data = true
3. 客戶端節點（Client node）
按照官方的介紹，客戶端節點就是既不做候選主節點也不做數據節點的節點，只負責請求的分發、彙總等等，也就是下面要說到的協調節點的角色。這樣的工作，其實任何一個節點都可以完成，單獨增加這樣的節點更多是爲了負載均衡。
node.master = false
node.data = false
4. 協調節點（Coordinating node）
協調節點，是一種角色，而不是真實的Elasticsearch的節點，你沒有辦法通過配置項來配置哪個節點爲協調節點。集羣中的任何節點，都可以充當協調節點的角色。當一個節點A收到用戶的查詢請求後，會把查詢子句分發到其它的節點，然後合併各個節點返回的查詢結果，最後返回一個完整的數據集給用戶。在這個過程中，節點A扮演的就是協調節點的角色。毫無疑問，協調節點會對CPU、Memory要求比較高。
分片與集羣狀態
分片（Shard），是Elasticsearch中的最小存儲單元。一個索引（Index）中的數據通常會分散存儲在多個分片中，而這些分片可能在同一臺機器，也可能分散在多臺機器中。這樣做的優勢是有利於水平擴展，解決單臺機器磁盤空間和性能有限的問題，試想一下如果有幾十TB的數據都存儲同一臺機器，那麼存儲空間和訪問時的性能消耗都是問題。
默認情況下，Elasticsearch會爲每個索引分配5個分片，但是這並不代表你必須使用5個分片，同時也不說分片越多性能就越好。一切都取決對你的數據量的評估和權衡。雖然跨分片查詢是並行的，但是請求分發、結果合併都是需要消耗性能和時間的，所以在數據量較小的情況下，將數據分散到多個分片中反而會降低效率。如果說一定要給一個數據的話，筆者現在的每個分片數據量大概在20GB左右。
關於多分片與多索引的問題。一個索引可以有多個分片來完成存儲，但是主分片的數量是在索引創建時就指定好的，且無法修改，所以儘量不要只爲數據存儲建立一個索引，否則後面數據膨脹時就無法調整了。筆者的建議是對於同一類型的數據，根據時間來分拆索引，比如一週建一個索引，具體取決於數據增長速度。
上面說的是主分片（Primary Shard），爲了提高服務可靠性和容災能力，通常還會分配複製分片（Replica Shard）來增加數據冗餘性。比如設置複製分片的數量爲1時，就會對每個主分片做一個備份。
通過API（ http://localhost:9200/_cluster/health?pretty ）可以查看集羣的狀態，通常集羣的狀態分爲三種：
- Red，表示有主分片沒有分配，某些數據不可用。
- Yellow，表示主分片都已分配，數據都可用，但是有複製分片沒有分配。
- Green，表示主分片和複製分片都已分配，一切正常。
部署拓撲
最後，來看兩個集羣部署的拓撲圖，這裏我們不考慮單個節點的調優。拓撲圖一是一個簡單的集羣部署，適用於數據量較小的場景。集羣中有三個節點，三個都是候選主節點，因此我們可以設置最少可工作候選主節點個數爲2。節點1和2同時作爲數據節點，兩個節點的數據相互備份。這樣的部署結構在擴展過程中，通常是先根據需要逐步加入專用的數據節點，最後考慮將數據節點和候選主節點分離，也就發展爲了拓撲圖二的結構。在拓撲圖二中，有三個專用的候選主節點，用來做集羣狀態維護，數據節點根據需要進行增加，注意只增加專用的數據節點即可。
（全文完，本文地址：http://blog.csdn.net/zwgdft/article/details/54585644 ）
Bruce，2017/01/18