本文轉載自:ES分佈式集羣
個人覺得本章非常重要，特轉載本章；
前言
本章我們解釋一些通用的術語，例如集羣(cluster)、節點(node)和分片(shard)，Elasticsearch的擴展機制，以及它如何處理硬件故障。我們在使用Elasticsearch的時候可以長時間甚至永遠都不必擔心分片、複製和故障轉移——但是它會幫助你理解Elasticsearch內部的工作流程。
Elasticsearch用於構建高可用和可擴展的系統。擴展的方式可以是購買更好的服務器(縱向擴展(vertical scale or scaling up))或者購買更多的服務器（橫向擴展(horizontal scale or scaling out)）。
Elasticsearch雖然能從更強大的硬件中獲得更好的性能，但是縱向擴展有它的侷限性。真正的擴展應該是橫向的，它通過增加節點來均攤負載和增加可靠性。
對於大多數數據庫而言，橫向擴展意味着你的程序將做非常大的改動才能利用這些新添加的設備。對比來說，Elasticsearch天生就是分佈式的：它知道如何管理節點來提供高擴展和高可用。這意味着你的程序不需要關心這些。
在這章我們將探索如何創建你的集羣(cluster)、節點(node)和分片(shards)，使其按照你的需求進行擴展，並保證在硬件故障時數據依舊安全。
一、空集羣
如果我們啓動一個單獨的節點，它還沒有數據和索引，這個集羣看起來就像圖1
圖1：只有一個空節點的集羣
一個節點(node)就是一個Elasticsearch實例，而一個集羣(cluster)由一個或多個節點組成，它們具有相同的cluster.name，它們協同工作，分享數據和負載。當加入新的節點或者刪除一個節點時，集羣就會感知到並平衡數據。
集羣中一個節點會被選舉爲主節點(master),它將臨時管理集羣級別的一些變更，例如新建或刪除索引、增加或移除節點等。主節點不參與文檔級別的變更或搜索，這意味着在流量增長的時候，該主節點不會成爲集羣的瓶頸。任何節點都可以成爲主節點。我們例子中的集羣只有一個節點，所以它會充當主節點的角色。
做爲用戶，我們能夠與集羣中的任何節點通信，包括主節點。每一個節點都知道文檔存在於哪個節點上，它們可以轉發請求到相應的節點上。我們訪問的節點負責收集各節點返回的數據，最後一起返回給客戶端。這一切都由Elasticsearch處理。
二、集羣健康
在Elasticsearch集羣中可以監控統計很多信息，但是隻有一個是最重要的：集羣健康(cluster health)。集羣健康有三種狀態：green、yellow或red。
GET /_cluster/health
在一個沒有索引的空集羣中運行如上查詢，將返回這些信息：
{
"cluster_name": "elasticsearch",
"status": "green", <1>
"timed_out": false,
"number_of_nodes": 1,
"number_of_data_nodes": 1,
"active_primary_shards": 0,
"active_shards": 0,
"relocating_shards": 0,
"initializing_shards": 0,
"unassigned_shards": 0
}
status字段提供一個綜合的指標來表示集羣的的服務狀況。三種顏色各自的含義：
| 顏色 | 意義 |
|---|---|
| green | 所有主要分片和複製分片都可用 |
| yellow | 所有主要分片可用，但不是所有複製分片都可用 |
| red | 不是所有的主要分片都可用 |
在接下來的章節，我們將說明什麼是主要分片(primary shard)和複製分片(replica shard)，並說明這些顏色（狀態）在實際環境中的意義。
爲了將數據添加到Elasticsearch，我們需要索引(index)——一個存儲關聯數據的地方。實際上，索引只是一個用來指向一個或多個分片(shards)的“邏輯命名空間(logical namespace)”。
一個分片(shard)是一個最小級別“工作單元(worker unit)”,它只是保存了索引中所有數據的一部分。在接下來的《深入分片》一章，我們將詳細說明分片的工作原理，但是現在我們只要知道分片就是一個Lucene實例，並且它本身就是一個完整的搜索引擎。我們的文檔存儲在分片中，並且在分片中被索引，但是我們的應用程序不會直接與它們通信，取而代之的是，直接與索引通信。
分片是Elasticsearch在集羣中分發數據的關鍵。把分片想象成數據的容器。文檔存儲在分片中，然後分片分配到你集羣中的節點上。當你的集羣擴容或縮小，Elasticsearch將會自動在你的節點間遷移分片，以使集羣保持平衡。
分片可以是主分片(primary shard)或者是複製分片(replica shard)。你索引中的每個文檔屬於一個單獨的主分片，所以主分片的數量決定了索引最多能存儲多少數據。
三、添加索引
爲了將數據添加到Elasticsearch，我們需要索引(index)——一個存儲關聯數據的地方。實際上，索引只是一個用來指向一個或多個分片(shards)的“邏輯命名空間(logical namespace)”。
一個分片(shard)是一個最小級別“工作單元(worker unit)”,它只是保存了索引中所有數據的一部分。在接下來的《深入分片》一章，我們將詳細說明分片的工作原理，但是現在我們只要知道分片就是一個Lucene實例，並且它本身就是一個完整的搜索引擎。我們的文檔存儲在分片中，並且在分片中被索引，但是我們的應用程序不會直接與它們通信，取而代之的是，直接與索引通信。
分片是Elasticsearch在集羣中分發數據的關鍵。把分片想象成數據的容器。文檔存儲在分片中，然後分片分配到你集羣中的節點上。當你的集羣擴容或縮小，Elasticsearch將會自動在你的節點間遷移分片，以使集羣保持平衡。
分片可以是主分片(primary shard)或者是複製分片(replica shard)。你索引中的每個文檔屬於一個單獨的主分片，所以主分片的數量決定了索引最多能存儲多少數據。
理論上主分片能存儲的數據大小是沒有限制的，限制取決於你實際的使用情況。分片的最大容量完全取決於你的使用狀況：硬件存儲的大小、文檔的大小和複雜度、如何索引和查詢你的文檔，以及你期望的響應時間。
複製分片只是主分片的一個副本，它可以防止硬件故障導致的數據丟失，同時可以提供讀請求，比如搜索或者從別的shard取回文檔。
當索引創建完成的時候，主分片的數量就固定了，但是複製分片的數量可以隨時調整。
讓我們在集羣中唯一一個空節點上創建一個叫做blogs的索引。默認情況下，一個索引被分配5個主分片，但是爲了演示的目的，我們只分配3個主分片和一個複製分片（每個主分片都有一個複製分片）：
PUT /blogs
{
"settings" : {
"number_of_shards" : 3,
"number_of_replicas" : 1
}
}
附帶索引的單一節點集羣：
我們的集羣現在看起來就像上圖——三個主分片都被分配到Node 1。如果我們現在檢查集羣健康(cluster-health)，我們將見到以下信息：
{
"cluster_name": "elasticsearch",
"status": "yellow", <1>
"timed_out": false,
"number_of_nodes": 1,
"number_of_data_nodes": 1,
"active_primary_shards": 3,
"active_shards": 3,
"relocating_shards": 0,
"initializing_shards": 0,
"unassigned_shards": 3 <2>
}
集羣的健康狀態yellow表示所有的主分片(primary shards)啓動並且正常運行了——集羣已經可以正常處理任何請求——但是複製分片(replica shards)還沒有全部可用。事實上所有的三個複製分片現在都是unassigned狀態——它們還未被分配給節點。在同一個節點上保存相同的數據副本是沒有必要的，如果這個節點故障了，那所有的數據副本也會丟失。
現在我們的集羣已經功能完備，但是依舊存在因硬件故障而導致數據丟失的風險。
四、增加故障轉移
在單一節點上運行意味着有單點故障的風險——沒有數據備份。幸運的是，要防止單點故障，我們唯一需要做的就是啓動另一個節點。
啓動第二個節點
爲了測試在增加第二個節點後發生了什麼，你可以使用與第一個節點相同的方式啓動第二個節點（《運行Elasticsearch》一章），而且命令行在同一個目錄——一個節點可以啓動多個Elasticsearch實例。
只要第二個節點與第一個節點有相同的cluster.name（請看./config/elasticsearch.yml文件），它就能自動發現並加入第一個節點所在的集羣。如果沒有，檢查日誌找出哪裏出了問題。這可能是網絡廣播被禁用，或者防火牆阻止了節點通信。
如果我們啓動了第二個節點，這個集羣看起來就像下圖。
雙節點集羣——所有的主分片和複製分片都已分配:
第二個節點已經加入集羣，三個複製分片(replica shards)也已經被分配了——分別對應三個主分片，這意味着在丟失任意一個節點的情況下依舊可以保證數據的完整性。
文檔的索引將首先被存儲在主分片中，然後併發複製到對應的複製節點上。這可以確保我們的數據在主節點和複製節點上都可以被檢索。
cluster-health現在的狀態是green，這意味着所有的6個分片（三個主分片和三個複製分片）都已可用：
{
"cluster_name": "elasticsearch",
"status": "green", <1>
"timed_out": false,
"number_of_nodes": 2,
"number_of_data_nodes": 2,
"active_primary_shards": 3,
"active_shards": 6,
"relocating_shards": 0,
"initializing_shards": 0,
"unassigned_shards": 0
}
集羣的狀態是green
我們的集羣不僅是功能完備的，而且是高可用的。
五、橫向擴展
隨着應用需求的增長，我們該如何擴展？如果我們啓動第三個節點，我們的集羣會重新組織自己，就像圖4：
圖4：包含3個節點的集羣——分片已經被重新分配以平衡負載：
Node3包含了分別來自Node 1和Node 2的一個分片，這樣每個節點就有兩個分片，和之前相比少了一個，這意味着每個節點上的分片將獲得更多的硬件資源（CPU、RAM、I/O）。
分片本身就是一個完整的搜索引擎，它可以使用單一節點的所有資源。我們擁有6個分片（3個主分片和三個複製分片），最多可以擴展到6個節點，每個節點上有一個分片，每個分片可以100%使用這個節點的資源。
六、繼續擴展
如果我們要擴展到6個以上的節點，要怎麼做？
主分片的數量在創建索引時已經確定。實際上，這個數量定義了能存儲到索引裏數據的最大數量（實際的數量取決於你的數據、硬件和應用場景）。然而，主分片或者複製分片都可以處理讀請求——搜索或文檔檢索，所以數據的冗餘越多，我們能處理的搜索吞吐量就越大。
複製分片的數量可以在運行中的集羣中動態地變更，這允許我們可以根據需求擴大或者縮小規模。讓我們把複製分片的數量從原來的1增加到2：
PUT /blogs/_settings
{
"number_of_replicas" : 2
}
圖5：增加number_of_replicas到2：
從圖中可以看出，blogs索引現在有9個分片：3個主分片和6個複製分片。這意味着我們能夠擴展到9個節點，再次變成每個節點一個分片。這樣使我們的搜索性能相比原始的三節點集羣增加三倍。
當然，在同樣數量的節點上增加更多的複製分片並不能提高性能，因爲這樣做的話平均每個分片的所佔有的硬件資源就減少了（譯者注：大部分請求都聚集到了分片少的節點，導致一個節點吞吐量太大，反而降低性能），你需要增加硬件來提高吞吐量。
不過這些額外的複製節點使我們有更多的冗餘：通過以上對節點的設置，我們能夠承受兩個節點故障而不丟失數據。
七、應對故障
我們已經說過Elasticsearch可以應對節點失效，所以讓我們繼續嘗試。如果我們殺掉第一個節點的進程（以下簡稱殺掉節點），我們的集羣看起來就像這樣：
圖5：殺掉第一個節點後的集羣
我們殺掉的節點是一個主節點。一個集羣必須要有一個主節點才能使其功能正常，所以集羣做的第一件事就是各節點選舉了一個新的主節點：Node 2。
主分片1和2在我們殺掉Node 1時已經丟失，我們的索引在丟失主分片時不能正常工作。如果此時我們檢查集羣健康，我們將看到狀態red：不是所有主分片都可用！
幸運的是丟失的兩個主分片的完整拷貝存在於其他節點上，所以新主節點做的第一件事是把這些在Node 2和Node 3上的複製分片升級爲主分片，這時集羣健康回到yellow狀態。這個提升是瞬間完成的，就好像按了一下開關。
爲什麼集羣健康狀態是yellow而不是green？我們有三個主分片，但是我們指定了每個主分片對應兩個複製分片，當前卻只有一個複製分片被分配，這就是集羣狀態無法達到green的原因，不過不用太擔心這個：當我們殺掉Node 2，我們的程序依然可以在沒有丟失數據的情況下繼續運行，因爲Node 3還有每個分片的拷貝。
如果我們重啓Node 1，集羣將能夠重新分配丟失的複製分片，集羣狀況與上一節的 圖5：增加number_of_replicas到2 類似。如果Node 1依舊有舊分片的拷貝，它將會嘗試再利用它們，它只會從主分片上覆制在故障期間有數據變更的那一部分。
現在你應該對分片如何使Elasticsearch可以水平擴展並保證數據安全有了一個清晰的認識。
本文轉載自:ES分佈式集羣