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

阿新 • • 發佈：2018-12-31

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

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 配置

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開頭索引的寫操作。