elasticsearch集羣擴容和容災

時間 2019-11-14

原文原文鏈接

elasticsearch專欄：https://www.cnblogs.com/hello-shf/category/1550315.htmlhtml

1、集羣健康

Elasticsearch 的集羣監控信息中包含了許多的統計數據，其中最爲重要的一項就是集羣健康，它在 status 字段中展現爲 green 、 yellow 或者 red。node

在kibana中執行：GET /_cat/health?vmysql

1 epoch      timestamp cluster        status node.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent
2 1568794410 08:13:30  my-application yellow          1         1     47  47    0    0       40             0                  -                 54.0%

其中咱們能夠看到當前我本地的集羣健康狀態是yellow ，但這裏問題來了，集羣的健康情況是如何進行判斷的呢？sql

green（很健康）
    全部的主分片和副本分片都正常運行。
yellow（亞健康）
    全部的主分片都正常運行，但不是全部的副本分片都正常運行。
red（不健康）
    有主分片沒能正常運行。

注意：服務器

我本地只配置了一個單節點的elasticsearch，由於primary shard和replica shard是不能分配到一個節點上的因此，在我本地的elasticsearch中是不存在replica shard的，因此健康情況爲yellow。架構

2、shard和replica

爲了將數據添加到Elasticsearch，咱們須要索引(index)——一個存儲關聯數據的地方。實際上，索引只是一個用來指向一個或多個分片(shards)的「邏輯命名空間(logical namespace)」. 一個分片(shard)是一個最小級別「工做單元(worker unit)」,它只是保存了索引中全部數據的一部分。道分片就是一個Lucene實例，而且它自己就是一個完整的搜索引擎。咱們的文檔存儲在分片中，而且在分片中被索引，可是咱們的應用程序不會直接與它們通訊，取而代之的是，直接與索引通訊。分片是Elasticsearch在集羣中分發數據的關鍵。把分片想象成數據的容器。文檔存儲在分片中，而後分片分配到你集羣中的節點上。當你的集羣擴容或縮小，Elasticsearch將會自動在你的節點間遷移分片，以使集羣保持平衡。分片能夠是主分片(primary shard)或者是複製分片(replica shard)。app

你索引中的每一個文檔屬於一個單獨的主分片，因此主分片的數量決定了索引最多能存儲多少數據。理論上主分片能存儲的數據大小是沒有限制的，限制取決於你實際的使用狀況。分片的最大容量徹底取決於你的使用情況：硬件存儲的大小、文檔的大小和複雜度、如何索引和查詢你的文檔，以及你指望的響應時間。負載均衡

複製分片只是主分片的一個副本，它能夠防止硬件故障致使的數據丟失，同時能夠提供讀請求，好比搜索或者從別的shard取回文檔。當索引建立完成的時候，主分片的數量就固定了，可是複製分片的數量能夠隨時調整。讓咱們在集羣中惟一一個空節點上建立一個叫作 blogs 的索引。默認狀況下，一個索引被分配5個主分片，一個主分片默認只有一個複製分片。elasticsearch

重點：
shard分爲兩種：
    1，primary shard --- 主分片 2，replica shard --- 複製分片（或者稱爲備份分片或者副本分片）

須要注意的是，在業界有一個約定俗稱的東西，單說一個單詞shard通常指的是primary shard，而單說一個單詞replica就是指的replica shard。分佈式

另一個須要注意的是replica shard是相對於索引而言的，若是說當前index有一個複製分片，那麼相對於主分片來講就是每個主分片都有一個複製分片，即若是有5個主分片就有5個複製分片，而且主分片和複製分片之間是一一對應的關係。

很重要的一點：primary shard不能和replica shard在同一個節點上。重要的事情說三遍：

primary shard不能和replica shard在同一個節點上

因此es最小的高可用配置爲兩臺服務器。

3、master節點、協調節點和節點對等特性

elasticsearch同大多數的分佈式架構，也會進行主節點的選舉，elasticsearch選舉出來的主節點主要承擔一下工做：

1 集羣層面的設置
2 集羣內的節點維護
3 集羣內的索引、映射（mapping）、分詞器的維護
4 集羣內的分片維護

不一樣於hadoop、mysql等的主節點，elasticsearch的master將不會成爲整個集羣環境的流量入口，即其並不獨自承擔文檔級別的變動和搜索（curd），也就意味着當流量暴增，主節點的性能將不會成爲整個集羣環境的性能瓶頸。這就是elasticsearch的節點對等特性。

節點對等：

所謂的節點對等就是在集羣中每一個節點扮演的角色都是平等的，也就意味着每一個節點都能成爲集羣的流量入口，當請求進入到某個節點，該節點就會暫時充當協調節點的角色，對請求進行路由和處理。這是一個區別於其餘分佈式中間件的很重要的特性。節點對等的特性讓elasticsearch具有了負載均衡的特性。在後面對document的寫入和搜索會詳細介紹該牛叉的特性。

協調節點：

經過上面的分析，咱們能夠得出一個結論，協調節點其實就是請求命中的那個節點。該節點將承擔當前請求的路由工做。

4、擴容

通常的擴容模式分爲兩種，一種是水平擴容，一種是垂直擴容。

4.一、垂直擴容：

所謂的垂直擴容就是升級服務器，買性能更好的，更貴的而後替換原來的服務器，這種擴容方式不推薦使用。由於單臺服務器的性能老是有瓶頸的。

4.二、水平擴容：

水平擴容也稱爲橫向擴展，很簡單就是增長服務器的數量，這種擴容方式可持續性強，將衆多普通服務器組織到一塊兒就能造成強大的計算能力。水平擴容 VS 垂直擴容用一句俗語來講再合適不過了：三個臭皮匠勝過諸葛亮。

4.三、垂直擴容的過程分析

上面咱們詳細介紹了分片，master和協調節點，接下來咱們經過畫圖的方式一步步帶你們看看橫向擴容的過程。

首先呢須要鋪墊一點關於自定義索引shard數量的操做

1 PUT /student
2 {
3    "settings" : {
4       "number_of_shards" : 3,
5       "number_of_replicas" : 1
6    }
7 }

以上代碼意味着咱們建立的索引student將會分配三個primary shard和三個replica shard（至於上面爲何是1，那是相對於索引來講的，前面解釋過）。

4.3.一、一臺服務器

當咱們只有一臺服務器的時候，shard是怎麼分佈的呢？

注：P表明primary shard， R表明replica shard。明確一點在後面的描述中默認一個es節點在一臺服務器上。

分析一下上面的過程，首先須要明確的兩點：

1，primary shard和replica shard不能再同一臺機器上，由於replica和shard在同一個節點上就起不到副本的做用了。

2，當集羣中只有一個節點的時候，node1節點將成爲主節點。它將臨時管理集羣級別的一些變動，例如新建或刪除索引、增長或移除節點等。

明確了上面兩點也就很簡單了，由於集羣中只有一個節點，該節點將直接被選舉爲master節點。其次咱們爲student索引分配了三個shard，因爲只有一個節點，因此三個primary shard都被分配到該節點，replica shard將不會被分配。此時集羣的健康情況爲yellow。

4.3.二、增長一臺服務器

接着上面繼續，咱們增長一臺服務器，此時shard是如何分配的呢？

Rebalance（再平衡），當集羣中節點數量發生變化時，將會觸發es集羣的rebalance，即從新分配shard。Rebalance的原則就是儘可能使shard在節點中分佈均勻，達到負載均衡的目的。

原先node1節點上有p0、p一、p2三個primary shard，另外三個replica shard還未分配，當集羣新增節點node2，觸發集羣的Rebalance，另外三個replica shard將被分配到node2上，即如上圖所示。

此時集羣中全部的primary shard和replica shard都是active（可用）狀態的因此此時集羣的健康情況爲yellow。可見es集羣的最小高可用配置就是兩太服務器。

4.3.三、繼續新增服務器

繼續新增服務器，集羣將再次進行Rebalance，在primary shard和replica shard不能分配到一個節點上的原則，此次rebalance一樣本着使shard均勻分佈的原則，將會從node1上將P1，P2兩個primary shard分配到node1，node2上面，而後將node2在primary shard和replica shard不能分配到一臺機器上的原則上將另外兩個replica shard分配到node1和node2上面。

注意：具體的分配方式上，多是P0在node2上面也有可能在node3上面，可是隻要本着Rebalance的原則將shard均勻分佈達到負載均衡便可。

5、集羣容災

分佈式的集羣是必定要具有容災能力的，對於es集羣一樣如此，那es集羣是如何進行容災的呢？接下來聽我娓娓道來。

在前文咱們詳細講解了primary shard和replica shard。replica shard做爲primary shard的副本當集羣中的節點發生故障，replica shard將被提高爲primary shard。具體的演示以下

集羣中有三臺服務器，其中node1節點爲master節點，primary shard 和 replica shard的分佈如上圖所示。此時假設node1發生宕機，也就是master節點發生宕機。此時集羣的健康狀態爲red，爲何呢？由於不是全部的primary shard都是active的。

具體的容災過程以下：

1，從新選舉master節點，當es集羣中的master節點發生故障，此時es集羣將再次進行master的選舉，選舉出一個新的master節點。假設此時新的主節點爲node2。

2，node2被選舉爲新的master節點，node2將做爲master行駛其分片分配的任務。

3，replica shard升級，此時master節點會尋找node1節點上的P0分片的replica shard，發現其副本在node2節點上，而後將R0提高爲primary shard。這個升級過程是瞬間完成的，就像按下一個開關同樣。由於每個shard其實都是lucene的實例。此時集羣以下所示，集羣的健康狀態爲yellow，由於不是每個replica shard都是active的。

容災的過程如上所示，其實這也是通常分佈式中間件容災備份的通常手段。若是你很瞭解kafka的話，這個就很容易理解了。

　　參考文獻：

　　《elasticsearch-權威指南》

　　若有錯誤的地方還請留言指正。

　　原創不易，轉載請註明原文地址：http://www.javashuo.com/article/p-agwjugrf-cx.html