ElasticSearch學習總結（六）：集羣管理總結

本文主要總結和集羣管理的相關內容。

1. 發現和恢復模塊

節點的啓動主要包括兩個過程:（1）發現 （2）恢復

1.1 發現(discovery)

當啓動ES節點的時候，最先做的事情就是查找一個擁有相同集羣名稱且網絡上可見的主節點，如果找到，這個新啓動的節點就加入那個已經存在的集羣，如果沒有找到，這個節點就將自己選舉爲主節點(前提是配置允許)。

負責上述過程的就是發現模塊，該模塊主要有兩個作用:
1. 選主節點
2. 發現新節點

1.1.1 發現模塊

發現模塊在默認情況下，ES假定配置了相同集羣名稱且可以使用組播來相互通信的節點可自動組成集羣。

發現模塊可以有多種實現，Zen爲默認的實現，它默認使用組播來發現節點。該方式雖然方便，但是在生產環境下可能也會帶來一些問題：
1. 可能會有意外節點的加入
2. 組播會產生大量不必要的通

處於以上問題，Zen允許使用單播模式。當使用單播時，集羣外的節點會發送一個Ping到所有配置中指定的地址。通過該中方式，其通知集羣中的所有節點，最後的結果是要麼加入一個集羣，要麼組件一個新的集羣。

1.1.2 主節點

發現模塊除了提供了發現節點的功能外，選擇主節點也是發現模塊的主要功能之一。
默認情況下，所有節點都可以成爲主節點,數據節點以及查詢節點，但是某些情況下，可能只希望一些節點只能擔任部分角色，此時可以通過如下的方式進行配置

• node.master:true|false,表明該節點是否可以爲主節點
• node.data:true|false,表明該節點是否可以爲數據節點
• node.ingest:true|false,表明該節點是否可以爲聚合節點

對於一個大規模的ES集羣，在網絡出現故障的時候，很容易出現腦裂的情況(假如有是10節點，在某次網絡出現故障時，3個節點脫離了網絡，此時脫離的三個節點有可能它們自己選了一個主節點，此時便出現兩個主節點，產生腦裂)。爲了降低腦裂出現的概率，ES提供了discovery.zen.minium_master_nodes參數來定義了“想要組件集羣至少需要的候選主節點（node.master=true的節點）數量”.

在ES集羣中,主節點是唯一可以改變集羣狀態的節點，當它每次處理完一個狀態更新請求，都會現在本地更新，然後發送給其他的節點，發送後會在一個指定的時間內等待其他節點的響應，對於一個繁忙的集羣，可能需要增加主節點的等待時間(discovery.zen.publish_timeout)

1.1.3 故障檢測

ES在運行的過程中會運行兩個檢測進程：
1. 主節點發送Ping請求到其他節點，檢測其餘節點的情況
2. 其他節點發送Ping到主節點，檢測主節點是否可用

對於網絡環境不穩定的情況，可能需要對檢測的相關參數做適當的調整，參數如下（都以 discovery.zen.fd 爲前綴）：

Setting	Description
ping_interval	How often a node gets pinged. Defaults to 1s.
ping_timeout	How long to wait for a ping response, defaults to 30s.
ping_retries	How many ping failures / timeouts cause a node to be considered failed. Defaults to 3.

1.1.4 發現模塊的實現

除了zen模塊外，還支持一下集中發現模塊
1. Azure 發現模塊
2. Ec2發現模塊
3. Google Compute Engine 發現模塊

如有需要，可參考:https://www.elastic.co/guide/en/elasticsearch/reference/5.2/modules-discovery.html 瞭解各發現模塊對應的配置

1.2 恢復（recovery）

集羣建立後，就開始了恢復的操作,在恢復的過程中，ES從網關(gateway:負責存儲ES集羣正常運行所有數據的組件)讀取元數據和索引，並準備需要使用的分片。主分片恢復完成後，ES就可以對外提供服務了，如果還有副本則繼續對副本進行恢復。

1.2.1 網關模塊(Gateway)

gateway模塊用於存儲es集羣的元數據信息。這部分信息主要包括所有的索引連同索引設置和顯式的mapping信息。集羣元數據的每一次改變（比如增加刪除索引等），這些信息都要通過gateway模塊進行持久化。當集羣第一次啓動的時候，這些信息就會從gateway模塊中讀出並應用。

設置在node級別上的gateway會自動控制索引所用的gateway。比如設置了local gataway，則每一個在這個node上創建的index都會應用他們在索引級別的local gateway。如果索引不需要持久化狀態，需要顯式的設置爲none（這也是唯一可以設置的值）。默認的gateway設置是local gateway。

1.2.1.1 Gateway 配置

1. recovery after nodes/time:在一些場景下，集羣的元數據信息只有在集羣中一些節點啓動之後或者一段時間間隔之後才能夠恢復。這在集羣重啓的時候非常有用，而且可以充分利用節點的本地存儲來從gateway模塊中恢復數據（這將會大大縮短集羣的恢復時間）。下邊給出一些配額項的說明：

   • gateway.recovery_after_nodes：集羣啓動恢復進程需要多少個節點啓動（包括master 和 data）

   • gateway.recovery_after_data_nodes：集羣啓動恢復進程需要多少個數據節點啓動

   • gateway.recovery_after_master_nodes：集羣啓動恢復進程需要多少個master節點啓動

   • gateway.recovery_after_time：在recovery_after_*_nodes個節點啓動後，需要等到多長時間，再啓動集羣恢復進程。

   • gateway.expected_nodes：期望多少個節點（包括master和data）進入集羣后，啓動恢復。一旦滿足，gateway.recovery_after_time參數將忽略。

   • gateway.expected_data_nodes：期望多少個數據節點進入集羣后，啓動恢復。

   • gateway.expected_master_nodes：期望多少個master節點進入集羣后，啓動恢復。

給出一個配置例子：

gateway:
    recover_after_time: 5m
    expected_nodes: 2

上述配置表明：集羣啓動後5分鐘啓動恢復，但是一旦節點數目達到2，立刻啓動回覆。
注意：一旦元數據已經從gateway模塊中恢復，這些配置將不再有效，直至下次集羣全部重啓。

在恢復元數據過程中，所有操作都將堵塞，爲了避免和集羣真實的元數據產生衝突。

1.2.1.2 本地網關(local gateway）

local gateway從每個節點的本地存儲中恢復集羣狀態和索引，不需要節點之間的共享存儲。local gateway的持久化是同步的，一旦一個操作執行了，數據就馬上會持久化，供集羣恢復使用。

配置gateway.recovery_after_nodes使其在絕大多數節點啓動後再進行恢復是非常重要的。這將會確保恢復到最近的集羣狀態。，例如

gateway:
    recover_after_nodes: 3
    expected_nodes: 5

2. 使用cat管理集羣

_cat用於查看集羣當前狀態,涉及到shard/node/cluster幾個層次

2.1 基本參數

verbose: 顯示列名, 請求參數爲v
示例: curl localhost:9200/_cat/master?v

help: 顯示當前命令的各列含義, 請求參數爲help. 某些命令部分列默認不顯示,可通過help該命令可顯示的所有列
示例: curl localhost:9200/_cat/master?help

bytes: 數值列還原爲原始值. 如diskSize, 默認轉爲以kb/mb/gb表示, 打開後還原爲原始值
示例: curl localhost:9200/_cat/indices?bytes=b

header: 顯示指定列的信息, 請求參數爲h
示例: curl localhost:9200/_cat/indices?h=i,tm(顯示集羣各索引的內存使用)

2.2. 功能列表

_cat 支持的命令如下：

/_cat/allocation
/_cat/shards
/_cat/shards/{index}
/_cat/master
/_cat/nodes
/_cat/indices
/_cat/indices/{index}
/_cat/segments
/_cat/segments/{index}
/_cat/count
/_cat/count/{index}
/_cat/recovery
/_cat/recovery/{index}
/_cat/health
/_cat/pending_tasks
/_cat/aliases
/_cat/aliases/{alias}
/_cat/thread_pool
/_cat/plugins
/_cat/fielddata
/_cat/fielddata/{fields}
/_cat/nodeattrs
/_cat/repositories
/_cat/snapshots/{repository}

詳細說明可參考：https://www.elastic.co/guide/en/elasticsearch/reference/5.2/cat.html

3. 快照和恢復

雖然ES集羣本身已經提供了一套完美的數據管理方案，但是當面對網絡分割或是網絡分區時還是可能會存在數據損壞和丟失的情況，此時可以通過ES提供的快照和恢復模塊來解決該問題。

快照和恢復 模塊允許創建單個索引或者整個集羣的快照到遠程倉庫. 在初始版本里只支持共享文件系統的倉庫，但是現在通過官方的倉庫插件可以支持各種各樣的後臺倉庫。

3.1 倉庫

在進行任何快照或者恢復操作之前必須有一個快照倉庫註冊在Elasticsearch裏。下面的這個命令註冊了 一個名爲my_backup 的共享文件系統倉庫，快照將會存儲在 /mount/backups/my_backup 這個目錄。

$ curl -XPUT 'http://localhost:9200/_snapshot/my_backup' -d '{
    "type": "fs",
    "settings": {
        "location": "/mount/backups/my_backup",
        "compress": true
    }
}'

一旦倉庫被註冊了，就可以只用下面的命令去獲取這個倉庫的信息

$ curl -XGET 'http://localhost:9200/_snapshot/my_backup?pretty'
{
  "my_backup" : {
    "type" : "fs",
    "settings" : {
      "compress" : "true",
      "location" : "/mount/backups/my_backup"
    }
  }
}

目前支持的倉庫類型主要包括：
- repository-s3 ：for S3 repository support
- repository-hdfs： for HDFS repository support in Hadoop environments
- repository-azure： for Azure storage repositories
- repository-gcs ：for Google Cloud Storage repositories

倉庫的詳細配置，可參考對應的文檔

3.2 快照

一個倉庫可以包含同一個集羣的多個快照。快照根據集羣中的唯一名字進行區分。 在倉庫 my_backup 裏創建一個名爲snapshot_1 的快照可以通過下面的命令:

$ curl -XPUT "localhost:9200/_snapshot/my_backup/snapshot_1?wait_for_completion=true"

wait_for_completion 參數指定創建snapshot的請求是否等待快照創建完成再返回。 默認情況下，集羣中所有打開和啓動的索引是自動創建快照的。可以通過在快照請求裏列出需要創建快照的索引.

索引創建快照的過程是增量的。在給索引創建快照的過程中，Elasticsearch會分析存儲在倉庫中的索引文件並且只會複製那些自從上次快照 之後新建或有所更新的文件。這使得多個快照以一種緊湊的方式存儲在同一個倉庫裏。創建快照的過程是以非阻塞方式執行的。一個索引在創 建快照的同時能夠被檢索和查詢。儘管如此，快照保存的是在開始進行創建快照的那個時間點的索引的視圖。所以，在開始創建快照之後的記 錄不會出現在這個快照裏。在主分片啓動之後創建快照的過程就會立即開始，並且之後不會改變位置。在1.2.0版本之前如果集羣重新定位或者 新加入快照的索引初始化主分片會導致快照操作失敗。從1.2.0版本開始，Elasticsearch會等待重新定位和初始化分片然後再創建快照。

任何時候在集羣裏只能有一個創建快照的操作在執行。當一個分片正在創建快照的時候，這個分片就不能被遷移到別的節點，因爲這會影響重 新平衡和分配過濾的過程。一旦這個分片的快照建立完成，這個分片就可以根據現有的分配過濾和重新平衡算法被遷移到別的節點上。

如果快照已經建立，我們可以通過如下的命令去獲得快照的信息：

$ curl -XGET "localhost:9200/_snapshot/my_backup/snapshot_1"

通過如下的命令可以把倉庫裏所有的快照列出來：

$ curl -XGET "localhost:9200/_snapshot/my_backup/_all"

可以通過如下的命令將倉庫裏的某個快照刪除：

$ curl -XDELETE "localhost:9200/_snapshot/my_backup/snapshot_1"

當一個快照從倉庫裏刪除之後，Elasticsearch會把所有和這個快照相關並且不被其它快照使用的文件刪除。如果對正在創建的某個快照執行 刪除操作，則創建快照的過程會被取消，並且會把創建過程中所有已經創建的文件刪除。因此，刪除操作可以用來取消那些由於誤操作引起的 長時間運行的快照操作。

3.3 恢復

快照可以使用如下的操作來恢復：

$ curl -XPOST "localhost:9200/_snapshot/my_backup/snapshot_1/_restore"

恢復操作可以在正在運行的集羣上操作。儘管如此，已經存在的index只有在關閉之後才能被恢復。恢復操作會自動打開關閉的恢復的索引， 並且如果索引不存在將會創建新的索引。

關於快照與恢復的詳細說明與配置，可參考：https://www.elastic.co/guide/en/elasticsearch/reference/5.2/modules-snapshots.html

4. 部落節點（Tribe node）

部落節點可以跨越多個集羣，它可以接收每個集羣的狀態，然後合併成一個全局集羣的狀態，它可以讀寫所有節點上的數據，部落節點在elasticsearch.yml中的配置如下：

tribe:
    t1: 
        cluster.name:   cluster_one
    t2: 
        cluster.name:   cluster_two

T1和T2是任意的名字代表連接到每個集羣。上面的示例配置兩集羣連接，名稱分別是T1和T2。默認情況下部落節點通過廣播可以做爲客戶端連接每一個集羣。大多數情況下，部落節點可以像單節點一樣對集羣進行操作。

4.1 通過部落節點讀取數據

當從部落節點讀取數據時，相同的操作會在說有的集羣上執行，合併後的結果會返回給客戶端。除了基本的查詢外，還可以通過部落節點執行過濾，suggestor等複雜的操作。

除了讀取索引數據外，還可以通過部門節點讀取集羣的健康狀態等數據。

4.2 通過部落節點寫入數據

可以通過部落節點將數據寫到已經存在的索引上，但是不可以通過部落節點執行類似於“創建索引”這樣的主節點級別的寫操作。

4.3 索引衝突

當部落節點連接的多個集羣出現名稱相同的索引時，部落節點會不知所措，默認情況下，將只有一個集羣的數據會被返回。

針對衝突，ES提供了三種策略：
- Any：默認值，ES會從集羣中選擇一個索引
- drop:ES將會忽略同名索引，換句話說同名的索引將會被屏蔽
- prefer_XXX:出現衝突時，從XXX集羣上選擇數據。

4.4 屏蔽寫操作

部落節點可以設置屏蔽所有的寫操作和所有修改元數據的請求

4.4.1 全局設置

tribe:
    blocks:
        write:    true
        metadata: true

上述配置使部落節點只能執行查詢的操作。

4.4.2 索引級別

tribe:
    blocks:
        write.indices:    hk*
        metadata.indices: hk*

上述配置屏蔽了所有以hk開頭索引的寫操作。