Cluster 集羣
一個 Elasticsearch 集羣由一個或多個節點（Node）組成，每個集羣都有一個共同的集羣名稱作爲標識。
Node 節點
一個 Elasticsearch 實例即一個 Node，一臺機器可以有多個實例，正常使用下每個實例應該會部署在不同的機器上。Elasticsearch 的配置文件中可以通過 node.master、node.data 來設置節點類型。
node.master：表示節點是否具有成爲主節點的資格
node.data：表示節點是否存儲數據
注意：此屬性的值爲true，並不意味着這個節點就是主節點。
因爲真正的主節點，是由多個具有主節點資格的節點進行選舉產生的。
所以，這個屬性只是代表這個節點是不是具有主節點選舉資格。
主節點+數據節點（默認）
node.master: true
node.data: true
節點即有成爲主節點的資格，又存儲數據。這個時候如果某個節點被選舉成爲了真正的主節點，那麼他還要存儲數據，這樣對於這個節點的壓力就比較大了。Elasticsearch 默認每個節點都是這樣的配置，在測試環境下這樣做沒問題。實際工作中建議不要這樣設置，這樣相當於主節點和數據節點的角色混合到一塊了。
數據節點
node.master: false
node.data: true
節點沒有成爲主節點的資格，不參與選舉，只會存儲數據。在集羣中需要單獨設置幾個這樣的節點負責存儲數據，後期提供存儲和查詢服務。主要消耗磁盤，內存。
主節點
node.master: true
node.data: false
不會存儲數據，有成爲主節點的資格，可以參與選舉，有可能成爲真正的主節點。普通服務器即可(CPU、內存消耗一般)。
客戶端節點
node.master: false
node.data: false
不會成爲主節點，也不會存儲數據，主要是針對海量請求的時候可以進行負載均衡。普通服務器即可（如果要進行分組聚合操作的話，建議這個節點內存也分配多一點）
在生產環境下，如果不修改 Elasticsearch 節點的角色信息，在高數據量，高併發的場景下集羣容易出現腦裂等問題。
Index 索引
一個集羣下可以有多個索引，每個索引是一系列相同格式文檔的集合（Elasticsearch 6.x 已不支持一個索引下多個Type）。
Shard 分片
每個索引有一個或多個分片，每個分片存儲不同的數據。分片可分爲主分片（ primary shard）和複製分片（replica shard），複製分片是主分片的拷貝。默認每個主分片有一個複製分片（默認一個索引創建後會有5個主分片，即：5主+5複製=10個分片），一個索引的複製分片的數量可以動態地調整，複製分片從不與它的主分片在同一個節點上（防止單點故障）。
複製分片有兩個作用：
- 提高恢復能力：當主分片掛掉時，某個複製分片可以變成主分片；
- 提高性能：get 和 search 請求既可以由主分片又可以由複製分片處理；
集羣健康值
- green：所有主要分片和複製分片都可用
- yellow：所有主要分片可用，但不是所有複製分片都可用
- red：不是所有的主要分片都可用
當集羣狀態爲 red，它仍然正常提供服務，它會在現有存活分片中執行請求，我們需要儘快修復故障分片，防止查詢數據的丟失；
Windows 環境搭建集羣（3個Node，全部是主節點+數據節點）
下載安裝包
解壓後複製3份（每份啓動一個實例）
編輯每個文件下的 config/elasticsearch.yml
根據以下說明調整 elasticsearch.yml 對應參數配置，node2、node3 其他配置與node1一致。
node1
# 集羣名稱，默認是 elasticsearch
cluster.name: es
# 節點名稱
node.name: node1
# 是否作爲集羣的主節點 ，默認 true
node.master: true
# 是否作爲集羣的數據節點 ，默認 true
node.data: true
# 數據存儲位置，默認是es根目錄下的data文件夾
path.data: E:\elasticsearch\node1\data
# 日誌存儲位置，默認是es根目錄下的logs文件夾
path.logs: E:\elasticsearch\node1\logs
# 配置訪問本節點的地址
network.host: 0.0.0.0
# 設置對外服務的http端口，默認爲9200
http.port: 9200
# 設置節點間交互的tcp端口,默認是9300
transport.tcp.port: 9300
# 配置所有用來組建集羣的機器的IP地址
discovery.zen.ping.unicast.hosts: ["127.0.0.1:9300", "127.0.0.1:9301","127.0.0.1:9302"]
# 配置當前集羣中最少具有 master 資格節點數，對於多於兩個節點的集羣環境，建議配置大於1
discovery.zen.minimum_master_nodes: 2
node2
path.data: E:\elasticsearch\node2\data
path.logs: E:\elasticsearch\node2\logs
http.port: 9201
transport.tcp.port: 9301
node3
path.data: E:\elasticsearch\node3\data
path.logs: E:\elasticsearch\node3\logs
http.port: 9202
transport.tcp.port: 9302
到目前位置，集羣的配置就完成了，下面我們分別啓動每個實例。
根據配置文件中的註釋：
Prevent the "split brain" by configuring the majority of nodes (total number of master-eligible nodes / 2 + 1)
所以我們配置了 discovery.zen.minimum_master_nodes: 2 ，所以必須有兩個主節點啓動成功，集羣纔算生效。
測試
進入目錄 elasticsearch-6.2.1-1 啓動第一個節點，執行命令：bin\elasticsearch.bat。從日誌中可以看出並沒有成功，因爲沒發現足夠的master節點。
當第二個master節點啓動成功時，整個集羣狀態變爲正常。
3個節點全部啓動成功，通過 elasticsearch-head 插件查看集羣狀態，通過集羣健康值：green，表示集羣一切正常。目前集羣內沒有任何數據，所以看不出索引與分片的情況。
Elasticsearch 一般會配合 Kibana + X-Pack 對集羣數據分析、監控等，官方標配。這裏使用了 elasticsearch-head 插件，一個比較小巧的工具。插件的安裝方法請看：elasticsearch-head 安裝介紹
添加測試數據：
從截圖可以看出，目前一共3個節點，一個索引 test，test 索引有5個主分片（邊框加粗），5個複製分片（邊框不加粗），分片會別均勻的分佈到每個節點中。
我們嘗試幹掉node3，node3 從集羣退出之後，集羣在短時間內會對分片進行重新分佈，當然依賴遵循主、複製分片不會在同一個Node。
如果我們繼續把node2幹掉，那麼整個集羣就掛了，集羣健康值：未連接。因爲當前可用的主節點數 1 < discovery.zen.minimum_master_nodes 設置的 2。
我們嘗試把 discovery.zen.minimum_master_nodes 設置成 1，然後重啓啓動一個節點，會發現有一個 Unassigned 的節點，集羣健康值：yellow (5 of 10)。這種情況下代表主分片全部可用，存在不可用的複製分片，5個複製分片沒有分配到節點上，不過此時的集羣是可用的，我們任何請求都能處理，只是所有的操作都落到主分片上，而且可能引發單點故障。當我們把第二個節點啓動後，一切就恢復正常了，主分片的數據會同步到複製分片。
實際生產環境，每個節點可能設置不同的節點類型，我們在3個節點的基礎上再增加兩個節點，然後調整 node.master 和node.data 的值，最終設置爲2個主節點，2個數據節點，1個客戶端節點。
node1 和 node2 是具有主節點選舉權限的節點，這裏 node1 被選舉爲master節點。node3 和 node4 是數據節點，所以數據分片只會分配在這兩個節點上。node5 是客戶端節點，最終是對請求起到負載均衡的作用。
如果是Linux環境下，啓動可能沒有這麼順利，可以參考 Linux 環境下安裝 elasticsearch 5.x、6.x 問題彙總 。