https://developer.aliyun.com/topic/elasticstack/playbook

Elasticsearch集群天然支持橫向水平擴展，因此當業務規模擴大、對集群產生讀寫壓力時，增加節點總是運維人員的“懶人選擇”。但隨著節點數增多，集群主節點要維護的meta信息也隨之增多，這會導致集群更新壓力增大甚至無法提供正常服務。 另外每個企業的數據中心都需要有災備方案在集群間同步數據，因為單點集群會存在隱患。
鑒于此，Elastic官方提供了跨集群操作。主要包括：
（1）跨集群搜索（CCS）：允許配置多個遠程集群并且在所有已配置的集群中實現聯合搜索。
（2）跨集群復制（CCR）：允許跨多個集群復制索引，適合于做災備方案和數據本地化場景。

跨集群配置

跨集群操作有兩種配置模式連接遠程的集群：使用嗅探模式（Sniff mode）或者代理模式（Proxy mode）將本地集群連接到遠程集群中的節點。
在嗅探模式下，我們使用集群名稱和種子節點列表注冊遠程集群。注冊后，集群狀態將被種子節點獲取并且最多選擇三個網關節點作為遠程集群的請求。該模式要求本地群集可以訪問網關節點的發布地址。
在代理模式下，使用集群名稱和單個代理地址注冊遠程集群。注冊遠程集群時，將打開可配置數量的套接字連接到代理地址。需要代理才能將這些連接路由到遠程群集。代理模式不需要遠程群集節點具有可訪問的發布地址。
我們可以在kibana上動態配置遠程集群，也可以在各個節點的elasticsearch.yml文件的上配置。

動態配置遠程集群

我們在kibana上使用cluster update settings API 為每個節點動態配置遠程集群。例如：

PUT _cluster/settings {"persistent": {"cluster": {"remote": {"cluster_one": {"seeds": ["127.0.0.1:9300"],"transport.ping_schedule": "30s"},"cluster_two": {"mode": "sniff","seeds": ["127.0.0.1:9301"],"transport.compress": true,"skip_unavailable": true},"cluster_three": {"mode": "proxy","proxy_address": "127.0.0.1:9302"}}}} }

當前集群是cluster_one，一起聯合遠程訪問的集群cluster_two、cluster_three。其中和cluster_two連接方式是嗅探模式而與cluster_three的連接方式是代理模式使用的代理地址proxy_address是"127.0.0.1:9302"。其中網絡傳輸的壓縮參數（compression）和tcp訪問頻率（ping_schedule）是可以動態調整的但必須要包括seed列表或者代理地址，我們如果想關閉壓縮、將ping_schedule由30s改成60s，示例如下：

PUT _cluster/settings {"persistent": {"cluster": {"remote": {"cluster_one": {"seeds": ["127.0.0.1:9300"],"transport.ping_schedule": "60s"},"cluster_two": {"mode": "sniff","seeds": ["127.0.0.1:9301"],"transport.compress": false},"cluster_three": {"mode": "proxy","proxy_address": "127.0.0.1:9302","transport.compress": true}}}} }

靜態配置遠程集群

在節點的elasticsearch.yml中配置遠程連接，只有在YAML文件中設置的節點才能連接到遠程集群并處理遠程集群請求。舉例：

cluster:remote:cluster_one: seeds: 127.0.0.1:9300 transport.ping_schedule: 30s cluster_two: mode: sniff seeds: 127.0.0.1:9301 transport.compress: true skip_unavailable: true cluster_three: mode: proxy proxy_address: 127.0.0.1:9302

其中：cluster_one，cluster_two和cluster_three是表示與每個集群的連接的集群別名用于區分本地索引和遠程索引。

跨集群搜索

跨集群搜索可以針對一個或多個遠程集群運行單個搜索請求。例如，我們可以使用跨集群搜索來過濾和分析存儲在不同數據中心的集群中的日志數據。
在5.3.0之前的版本，Elastic官方提供了使用Tribe Node實現多集群訪問的解決方案：Tribe Node以Client Node的角色添加到集群中。但是由于不保留集群的meta信息，每次重啟需要重新加載初始化。因此，在5.3版本中Elastic官方提供了CCS的功能，允許集群中的任何節點可以聯合查詢。

快速入門

下面以兩個集群的跨集群搜索為例。我們預先啟動了兩個集群：cluster1、cluster2，當前集群是cluster1，現在的任務是聯合遠程訪問的集群 cluter2進行跨集群搜索。

• 在cluster1 中插入數據

PUT esfighttogether/_doc/1 {"teamname":"team 10" }

• 在cluster2 中插入數據

PUT esfighttogether/_doc/1 {"teamname":"team 1" } PUT esfighttogether/_doc/2 {"teamname":"team 7" }

• 在兩個集群上分別驗證數據。因為寫入時ES自帶的默認分詞器會對數據進行分詞，我們通過team就可以查詢到所有數據。查詢語句如下：

GET esfighttogether/_search {"query": {"match": {"teamname": "team"}} }

• 分別在兩個集群上動態配置remote cluster。注意這里的cluster_one、cluster_two僅僅是別名，用來區別不同的集群。在seeds列表中填寫的是集群節點間通信的TCP端口而不是HTTP端口。

• 執行跨集群搜索

如上圖所示，通過CCS查詢到3條數據：cluster_one的一條數據team 10以及cluster_two的兩條數據team 1 和 team 7，和之前寫入的數據一致。

跨集群復制

跨集群索引復制需要使用到Elastic官方的白金認證，你可以在官網申請試用，官方會很快的回復郵件。根據不同版本的ES集群下載json文件然后導入到集群即可。
跨集群復制是將特定索引從一個 ElasticSearch 集群復制到另外的集群。一般用于以下場景：

• 災備：數據中心服務中斷時，可以繼續響應用戶的搜索請求
• 防止用戶大的查詢影響到寫入吞吐
• 數據本地化：將數據復制到更靠近用戶的位置以降低搜索延遲

跨集群復制使用主動-被動模型：我們將索引寫入領導者索引，數據會被復制到一個或多個只讀跟隨者索引。在將跟隨者索引添加到集群之前，我們需要配置包含領導者索引的遠程集群。
當領導者索引有寫入請求時，跟隨者索引從遠程集群上的領導者索引中拉取增量數據。我們可以手動創建跟隨者索引或配置自動跟隨模式（auto-follow patterns）創建跟隨者索引。

我們可以單向或雙向配置CCR：

• 在單向配置中，一個集群僅包含領導者索引，而另一個集群僅包含跟隨者索引。
  

• 在雙向配置中，每個集群都包含領導者索引和跟隨者索引
  

快速入門

我們在服務器上啟動兩個集群來模擬不同地區數據中心的集群：
“cluster1”：在端口 9200 上運行。我們會將文檔從cluster1復制到cluster2。
“cluster2”：在端口 9400 上運行。cluster2將維護一個來自cluster1的復制索引。

• 配置遠程集群

我們選擇CCR的單向配置，CCR 是基于拉取模式的所以我們只需要確保cluster2連接到cluster1，不需要指定從“cluster2”到“cluster1”的連接。
下面讓我們通過cluster2上的 API 調用來定義cluster1:

Kibana 中遠程集群管理的UI，單擊左側導航面板中的“Management”（齒輪圖標），然后點擊“Stack Management” 導航到 Elasticsearch 部分中的“Remote Clusters”（遠程集群）。

• 創建要復制的索引

PUT esfightalone {"settings": {"index": {"number_of_shards": 1,"number_of_replicas": 0,"soft_deletes": {"enabled": true}}},"mappings": {"properties": {"name": {"type": "keyword"}}} }

CCR 的 Leader 索引需要使用軟刪除（soft_deletes），無論何時刪除或更新現有文檔都可以將操作歷史記錄保留在領導者分片上，等重新操作歷史記錄時供追隨者分片任務使用。當追隨者分片從領導者復制數據時會在領導者分片上留下標記，這樣領導者就知道追隨者在歷史記錄中的所在位置。基于這些標記，領導者分片將會保留這些操作，直到分片歷史記錄保留到設定時間結束（默認為 12 個小時）。

• 開啟復制
  我們已經為遠程集群創建了一個別名，并創建了一個我們要復制的索引，接下來我們啟動復制。在“cluster2”上，執行：

PUT /esfightalone-copy/_ccr/follow {"remote_cluster" : "cluster1","leader_index" : "esfightalone" }

注意，復制索引是只讀的，不能接受寫操作。至此，我們已配置了要從一個 Elasticsearch 集群復制到另一個集群的索引。

• 測試ccr復制

  我們在cluster1上寫入數據：

  POST /esfightalone/_doc {"name" :"team 1" }

然后在cluster2上查詢，驗證索引數據是否同步，此時數據已經實時同步到cluster2中了： GET /products-copy/_search CCR屬于Elastic官方的白金付費（platinum license）的功能，一般企業還是會選擇自研數據同步工具來同步集群間的數據。不過，需要體驗的小伙伴可以在Elastic官網申請30天免費的使用。

總結

以上是生活随笔為你收集整理的跨集群操作的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。