前言

個人感覺集群架構(gòu)其實都有點大同小異，看了這么多集群架構(gòu)之后，感覺無非要考慮的地方就幾點：

1. 使用何種通信協(xié)議去同步數(shù)據(jù)，互相通信
2. 采用何種策略同步數(shù)據(jù)（異步還是同步）
3. 如何保證一致性，保證到什么程度（【最終一致性】 or【實時一致性 / 強一致性】）
4. 使用何種算法去選舉主次節(jié)點（感覺這個比較隨意，通常為了快速恢復服務(wù)，選舉流程是怎么快怎么來，但是不能出現(xiàn)【腦裂問題】）

閱讀對象

有基本ES使用知識，需要使用集群架構(gòu)

閱讀導航

系列上一篇文章：《【ES專題】ElasticSearch搜索進階》
系列下一篇文章：《【ES專題】ElasticSearch功能詳解與原理剖析》

要點

ES要掌握什么：

1. 使用：搜索和聚合操作語法，理解分詞，倒排索引，相關(guān)性算分（文檔匹配度）
2. 優(yōu)化： 數(shù)據(jù)預處理，文檔建模，集群架構(gòu)優(yōu)化，讀寫性能優(yōu)化

筆記正文

一、ES集群架構(gòu)

1.1 為什么要使用ES集群架構(gòu)

為什么需要使用集群架構(gòu)？這就得提一下分布式系統(tǒng)的可用性與擴展性了。

• 高可用性：分為兩個點考慮
  • 服務(wù)高可用性：允許個別節(jié)點停止服務(wù)，個別節(jié)點停止服務(wù)不影響整體使用
  • 數(shù)據(jù)可用性：部分節(jié)點丟失，不會丟失數(shù)據(jù)（需要有備份策略）
• 可擴展性：
  • 請求量提升/數(shù)據(jù)的不斷增長(將數(shù)據(jù)分布到所有節(jié)點上)

上面所說的正是集群架構(gòu)的優(yōu)勢所在。對ES集群架構(gòu)來說，則體現(xiàn)在：

• 提高系統(tǒng)的可用性，部分節(jié)點停止服務(wù)，整個集群的服務(wù)不受影響
• 存儲的水平擴容

1.2 ES集群核心概念

ES集群中有2個比較核心的概念需要理解一下。分別是：節(jié)點、分片。在聊這些概念之前，我們先重新梳理一下，ES的集群是什么。
ES的集群，亦上圖所示，它通常由如下特征：

• 集群中有一個或者多個節(jié)點
• 不同的集群通過不同的名字來區(qū)分，默認名字【elasticsearch】

注意：ES在實際生產(chǎn)環(huán)境中，還會部署多個集群一起工作

• 通過配置文件修改，或者在命令行中 -E cluster.name=es-cluster進行設(shè)定

1.2.1 節(jié)點

ES中的節(jié)點本質(zhì)上是一個Elasticsearch的實例，一個Java進程。通常，我們建議生產(chǎn)環(huán)境中，一臺機器只運行一個ES實例。（一臺機器部署多個節(jié)點，其實是違背【高可用】原則的）
ES節(jié)點有如下特性：

• 每一個節(jié)點都有名字，通過配置文件配置，或者啟動時候 -E node.name=node1指定
• 每一個節(jié)點在啟動之后，會分配一個UID，保存在data目錄下
• 節(jié)點有多種角色（類型），不同角色通常有不同的功能，它們分別是：
  • Master Node：主節(jié)點，負責索引的刪除創(chuàng)建
  • Master eligible nodes：【直譯：符合條件的節(jié)點】。可以參與選舉的合格節(jié)點
  • Data Node：數(shù)據(jù)節(jié)點，負責文檔的寫入、讀取。節(jié)點保存數(shù)據(jù)并執(zhí)行與數(shù)據(jù)相關(guān)的操作，如CRUD、搜索和聚合
  • Coordinating Node：協(xié)調(diào)節(jié)點
  • 其他節(jié)點

通過ES多角色定義可以看的出來，ES的集群架構(gòu)非常成熟，它也是我目前見過的角色最豐富的架構(gòu)。如此豐富的角色定義，肯定是為了拓展集群架構(gòu)而生的，單一職責嘛。不過有一點我沒想通的是，如果節(jié)點太多了，做一次CRUD的速度能快嗎？會不會在通信上就花費了很多時間。

節(jié)點類型，可以通過如下配置參數(shù)禁用/啟用

關(guān)于Master eligible nodes和Master Node

• 每個節(jié)點啟動后，默認就是一個Master eligible節(jié)點，即都可以參與集群選舉，成為Master節(jié)點。可以通過node.mater=false禁止
• 當?shù)谝粋€節(jié)點啟動時候，它會將自己選舉成Master節(jié)點
• 每個節(jié)點上都保存了集群的狀態(tài)，但是只有Master節(jié)點才能修改集群的狀態(tài)信息。集群狀態(tài)信息(Cluster State) 維護了一個集群中所有必要的信息。比如：
  • 所有節(jié)點信息
  • 所有的索引和其他相關(guān)的Mapping與Setting信息
  • 分片的路由信息

關(guān)于Data Node 和 Coordinating Node

• Data Node：
  • 可以保存數(shù)據(jù)的節(jié)點，叫做Data Node，負責保存分片數(shù)據(jù)。在數(shù)據(jù)擴展上起到了至關(guān)重要的作用
  • 節(jié)點啟動后，默認就是數(shù)據(jù)節(jié)點?？梢栽O(shè)置node.data: false禁止
  • 由Master Node決定如何把分片分發(fā)到數(shù)據(jù)節(jié)點上
  • 通過增加數(shù)據(jù)節(jié)點可以解決數(shù)據(jù)水平擴展和解決數(shù)據(jù)單點問題
• Coordinating Node：
  • 負責接受Client的請求， 將請求分發(fā)到合適的節(jié)點，最終把結(jié)果匯集到一起
  • 每個節(jié)點默認都起到了Coordinating Node的職責

其他節(jié)點類型

• Hot & Warm Node：冷熱節(jié)點。不同硬件配置 的Data Node，用來實現(xiàn)Hot & Warm架構(gòu)，降低集群部署的成本

不同硬件配置，通常是CPU跟硬盤。硬盤根據(jù)冷熱數(shù)據(jù)類型，可以選擇固態(tài)或者機械硬盤

• Ingest Node：數(shù)據(jù)前置處理轉(zhuǎn)換節(jié)點，支持pipeline管道設(shè)置，可以使用ingest對數(shù)據(jù)進行過濾、轉(zhuǎn)換等操作
• Machine Learning Node：負責跑機器學習的Job，用來做異常檢測
• Tribe Node：Tribe Node連接到不同的Elasticsearch集群，并且支持將這些集群當成一個單獨的集群處理

以下是一個多集群業(yè)務(wù)架構(gòu)圖：

1.2.1.1 Master Node主節(jié)點的功能

Master節(jié)點主要功能:：

1. 管理索引和分片的創(chuàng)建、刪除和重新分配
2. 監(jiān)測節(jié)點的狀態(tài)，并在需要時進行重分配
3. 協(xié)調(diào)節(jié)點之間的數(shù)據(jù)復制和同步工作
4. 處理集群級別操作，如創(chuàng)建或刪除索引、添加或刪除節(jié)點等
5. 維護集群的狀態(tài)

1.2.1.2 Data Node數(shù)據(jù)節(jié)點的功能

Data Node數(shù)據(jù)節(jié)點的功能：

1. 存儲和索引數(shù)據(jù)：Data Node 節(jié)點會將索引分片存儲在本地磁盤上，并對查詢請求進行響應(yīng)
2. 復制和同步數(shù)據(jù)：為了確保數(shù)據(jù)的可靠性和高可用性，ElasticSearch 會將每個原始分片的多個副本存儲在不同的 Data Node 節(jié)點上，并定期將各節(jié)點上的數(shù)據(jù)進行同步
3. 參與搜索和聚合操作：當客戶端提交搜索請求時，Data Node 節(jié)點會使用本地緩存和分片數(shù)據(jù)完成搜索和聚合操作
4. 執(zhí)行數(shù)據(jù)維護操作：例如，清理過期數(shù)據(jù)和壓縮分片等

官方定義：
數(shù)據(jù)節(jié)點保存包含您已索引的文檔的分片。數(shù)據(jù)節(jié)點處理數(shù)據(jù)相關(guān)操作，例如 CRUD、搜索和聚合。這些操作是 I/O、內(nèi)存和 CPU 密集型操作。監(jiān)視這些資源并在過載時添加更多數(shù)據(jù)節(jié)點非常重要。
擁有專用數(shù)據(jù)節(jié)點的主要好處是主角色和數(shù)據(jù)角色的分離。
要創(chuàng)建專用數(shù)據(jù)節(jié)點，請設(shè)置：node.roles: [ data ]
在多層部署體系結(jié)構(gòu)中，您可以使用專門的數(shù)據(jù)角色將數(shù)據(jù)節(jié)點分配到特定層：data_content、data_hot、data_warm、 data_cold或data_frozen。一個節(jié)點可以屬于多個層，但具有專用數(shù)據(jù)角色之一的節(jié)點不能具有通用data角色。

1.2.1.3 Coordinate Node協(xié)調(diào)節(jié)點的功能

官方定義：
諸如搜索請求或批量索引請求之類的請求，它們可能涉及不同數(shù)據(jù)節(jié)點上保存的數(shù)據(jù)。例如，搜索請求分兩個階段執(zhí)行，這兩個階段由接收客戶端請求的節(jié)點（協(xié)調(diào)節(jié)點）協(xié)調(diào)。

1. 在分散階段，協(xié)調(diào)節(jié)點將請求轉(zhuǎn)發(fā)到保存數(shù)據(jù)的數(shù)據(jù)節(jié)點。每個數(shù)據(jù)節(jié)點在本地執(zhí)行請求并將其結(jié)果返回給協(xié)調(diào)節(jié)點
2. 在收集階段，協(xié)調(diào)節(jié)點將每個數(shù)據(jù)節(jié)點的結(jié)果縮減為單個全局結(jié)果集

每個節(jié)點都是隱式的協(xié)調(diào)節(jié)點。這意味著具有顯式空角色列表的節(jié)點node.roles將僅充當協(xié)調(diào)節(jié)點，無法禁用。因此，這樣的節(jié)點需要有足夠的內(nèi)存和 CPU 才能處理收集階段。

1.2.1.4 Ingest Node協(xié)調(diào)節(jié)點的功能

官方定義：
在實際的文檔索引發(fā)生之前，使用攝取節(jié)點對文檔進行預處理。攝取節(jié)點攔截批量和索引請求，應(yīng)用轉(zhuǎn)換，然后將文檔傳遞回索引或批量api。

默認情況下，所有節(jié)點都啟用攝取，因此任何節(jié)點都可以處理攝取任務(wù)。您還可以創(chuàng)建專用的攝取節(jié)點。如果要禁用節(jié)點的攝取，請在elasticsearch. conf中配置以下配置。yml文件：node.ingest: false

要在索引之前對文檔進行預處理，請定義一個指定一系列處理器的管道。每個處理器都以某種特定的方式轉(zhuǎn)換文檔。例如，管道可能有一個處理程序從文檔中刪除字段，然后有另一個處理程序重命名字段。然后，集群狀態(tài)存儲配置的管道。

要使用管道，只需在索引或批量請求上指定pipeline參數(shù)。這樣，攝取節(jié)點就知道要使用哪個管道。例如：

PUT my-index/my-type/my-id?pipeline=my_pipeline_id
{"foo": "bar"
}

1.2.1.5 其他節(jié)點功能

其他節(jié)點相對來說使用的比較少，不做介紹了

1.2.1.6 Master Node主節(jié)點選舉流程

ES的選舉流程也很簡單，如下：

1. 通常集群啟動時，第一個啟動的節(jié)點會被選為主節(jié)點。當主節(jié)點掛了的時候，進行下一步
2. 互相Ping對方，Node ld 低的會成為被選舉的節(jié)點
3. 其他節(jié)點會加入集群，但是不承擔Master節(jié)點的角色。一旦發(fā)現(xiàn)被選中的主節(jié)點丟失，就會重新選舉出新的Master節(jié)點

在我們的生產(chǎn)過程中，Master Node的最佳實踐方案

• Master節(jié)點非常重要，在部署上需要考慮解決單點的問題
• 為一個集群設(shè)置多個Master節(jié)點，每個節(jié)點只承擔Master 的單一角色

1.2.2 分片

分片是ES中一個比較重要的概念。ElasticSearch是一個分布式的搜索引擎，索引可以分成一份或多份，多份分布在不同節(jié)點的分片當中。ElasticSearch會自動管理分片，如果發(fā)現(xiàn)分片分布不均衡，就會自動遷移。

分片又有【主分片】、【副本分片】之分。它們的區(qū)別如下：

• 主分片（Primary Shard）
  • 用以解決數(shù)據(jù)水平擴展的問題。通過主分片，可以將數(shù)據(jù)分布到集群內(nèi)的所有節(jié)點之上
  • 一個分片是一個運行的Lucene的實例
  • 主分片數(shù)在索引創(chuàng)建時指定，后續(xù)不允許修改，除非Reindex
• 副本分片
  • 用以解決數(shù)據(jù)高可用的問題。 副本分片是主分片的拷貝（備份）
  • 副本分片數(shù)，可以動態(tài)調(diào)整
  • 增加副本數(shù)，還可以在一定程度上提高服務(wù)的可用性（讀取的吞吐）

# 指定索引的主分片和副本分片數(shù)
PUT /csdn_blogs
{"settings": {"number_of_shards": 3,"number_of_replicas": 1}
}

分片架構(gòu)

如上圖是某個集群的分片架構(gòu)，它有如下特征：

1. 集群中有3個節(jié)點

通常都是奇數(shù)，所謂【集群奇數(shù)法則】。但其實只是名字很唬人，本質(zhì)上也沒那么神奇。你自己想想，如果是偶數(shù)的話，是不是很有可能出現(xiàn)選舉平票的時候？根據(jù)我的經(jīng)驗，選舉算法通常都希望快速選舉一個master或者leader出來，以便能夠快速提供服務(wù)，所以沒空扯皮

2. 每個節(jié)點各有一個主副分片

高可用之——故障轉(zhuǎn)移

3. 主副分片之間交叉存儲（node1的副本放在node3，node2放在node1，node3放在node2）

使用【cat API查看集群信息】

• GET /_cat/nodes?v #查看節(jié)點信息
• GET /_cat/health?v #查看集群當前狀態(tài)：紅、黃、綠
• GET /_cat/shards?v #查看各shard的詳細情況
• GET /_cat/shards/{index}?v #查看指定分片的詳細情況
• GET /_cat/master?v #查看master節(jié)點信息
• GET /_cat/indices?v #查看集群中所有index的詳細信息
• GET /_cat/indices/{index}?v #查看集群中指定index的詳細信息 `

1.3 搭建三節(jié)點ES集群

1.3.1 ES集群搭建步驟

下面是在Linux環(huán)境，centos7下面的集群搭建步驟：
1）系統(tǒng)環(huán)境準備
首先創(chuàng)建用戶，因為es不允許root賬號啟動

adduser es
passwd es

安裝版本：elasticsearch-7.17.3。接著切換到root用戶，修改/etc/hosts：

vim  /etc/hosts
192.168.66.150 es-node1  
192.168.66.151 es-node2  
192.168.66.152 es-node3  

2）修改elasticsearch.yml
注意配置里面的注釋，里面有一些細節(jié)。比如：

1. 注意集群的名字，3個節(jié)點的集群名稱必須一直
2. 給每個節(jié)點指定名字，比如這里是node1/2/3
3. 是否要開啟外網(wǎng)訪問，跟redis的配置差不多

# 指定集群名稱3個節(jié)點必須一致
cluster.name: es-cluster
#指定節(jié)點名稱，每個節(jié)點名字唯一
node.name: node-1
#是否有資格為master節(jié)點，默認為true
node.master: true
#是否為data節(jié)點，默認為true
node.data: true
# 綁定ip,開啟遠程訪問,可以配置0.0.0.0
network.host: 0.0.0.0
#用于節(jié)點發(fā)現(xiàn)
discovery.seed_hosts: ["es-node1", "es-node2", "es-node3"]
#7.0新引入的配置項,初始仲裁，僅在整個集群首次啟動時才需要初始仲裁。
#該選項配置為node.name的值，指定可以初始化集群節(jié)點的名稱
cluster.initial_master_nodes: ["node-1","node-2","node-3"]
#解決跨域問題
http.cors.enabled: true
http.cors.allow-origin: "*"

三個節(jié)點配置很簡單，按照上面的模板，依次修改node.name就行了

3) 啟動每個節(jié)點的ES服務(wù)

# 注意：如果運行過單節(jié)點模式，需要刪除data目錄， 否則會導致無法加入集群
rm -rf data
# 啟動ES服務(wù)
bin/elasticsearch -d 

4）驗證集群
正常來說，如果我們先啟動了192.168.66.150，那么它就是這個集群當中的主節(jié)點，所以我們驗證集群的話，只需要訪問http://192.168.66.150:9200即可看到如下界面：

1.3.2 安裝客戶端

介紹完了ES的集群部署，我們再來看看ES客戶端的部署。這里有兩個可選方案，它們分別是Cerebro和Kibana，它們的區(qū)別與聯(lián)系如下：

Cerebro和Kibana都是用于Elasticsearch的開源工具，但它們在功能和使用場景上存在一些區(qū)別。

功能：

• Cerebro：Cerebro是Elasticsearch的圖形管理工具，可以查看分片分配和執(zhí)行常見的索引操作，功能集中管理alias和index template，十分快捷。此外，Cerebro還具有實時監(jiān)控數(shù)據(jù)的功能。
• Kibana：Kibana是一個強大的可視化工具，可以用于Elasticsearch數(shù)據(jù)的探索、分析和展示。它提供了豐富的圖表類型，包括折線圖、直方圖、餅圖等，可以方便地展示基于時間序列的數(shù)據(jù)。此外，Kibana還提供了日志管理、分析和展示的功能

使用場景：

• Cerebro：Cerebro適合用于生產(chǎn)和測試環(huán)境的Elasticsearch集群管理，尤其適用于需要快速查看和執(zhí)行索引操作的情況。由于Cerebro輕量且適用于實時監(jiān)控，它可能更適用于較小的集群和實時監(jiān)控的場景。
• Kibana：Kibana適合對Elasticsearch數(shù)據(jù)進行深入的分析和探索，以及對日志進行管理和分析。它提供了豐富的可視化功能和靈活的數(shù)據(jù)展示方式，適用于各種規(guī)模的數(shù)據(jù)分析和監(jiān)控場景。

Cerebro安裝
Cerebro 可以查看分片分配和通過圖形界面執(zhí)行常見的索引操作，完全開源，并且它允許添加用戶，密碼或 LDAP 身份驗證問網(wǎng)絡(luò)界面。Cerebro 基于 Scala 的Play 框架編寫，用于后端 REST 和 Elasticsearch 通信。 它使用通過 AngularJS 編寫的單頁應(yīng)用程序（SPA）前端。
安裝包下載地址如下：https://github.com/lmenezes/cerebro/releases/download/v0.9.4/cerebro-0.9.4.zip

下載安裝之后，用以下命令啟動即可：

cerebro-0.9.4/bin/cerebro#后臺啟動
nohup bin/cerebro > cerebro.log &

訪問：http://192.168.66.150:9000/

輸入ES集群節(jié)點：http://192.168.66.150:9200，建立連接。然后會出現(xiàn)以下界面：

kibana安裝
1）修改kibana配置

vim config/kibana.ymlserver.port: 5601
server.host: "192.168.66.150" 
elasticsearch.hosts: ["http://192.168.66.150:9200","http://192.168.66.151:9200","http://192.168.66.152:9200"]  
i18n.locale: "zh-CN"   

2）運行Kibana

#后臺啟動
nohup  bin/kibana &

3）訪問
訪問http://192.168.66.150:5601/驗證

二、生產(chǎn)環(huán)境最佳實踐

2.1 一個節(jié)點只承擔一個角色的配置

我們在上面的介紹中知道，節(jié)點有多種不同的類型（角色），有：Master eligible / Data / Ingest / Coordinating /Machine Learning等。不過跟之前學習的各種集群架構(gòu)不同的是，ES一個節(jié)點可承擔多種角色。
不過，在生產(chǎn)環(huán)境中盡量還是一個節(jié)點一種角色比較好，優(yōu)點是：極致的高可用；缺點是：可能有點費錢
想要一個節(jié)點只承擔一個角色，只需要修改如下配置：

#Master節(jié)點
node.master: true
node.ingest: false
node.data: false#data節(jié)點
node.master: false
node.ingest: false
node.data: true#ingest 節(jié)點
node.master: false
node.ingest: true
node.data: false#coordinate節(jié)點
node.master: false
node.ingest: false
node.data: false

2.2 增加節(jié)點水平擴展場景

在實際生產(chǎn)中，我們可能會遇到需要水平擴展容量的場景，通常來說，以下是幾個常見的場景：

• 當磁盤容量無法滿足需求時，可以增加數(shù)據(jù)節(jié)點
• 磁盤讀寫壓力大時，增加數(shù)據(jù)節(jié)點
• 當系統(tǒng)中有大量的復雜查詢及聚合時候，增加Coordinating節(jié)點，增加查詢的性能

2.3 異地多活架構(gòu)

下面是一個多集群架構(gòu)。集群處在三個數(shù)據(jù)中心，數(shù)據(jù)三寫，使用GTM分發(fā)讀請求

全局流量管理（GTM）和負載均衡（SLB）的區(qū)別：
GTM 是通過DNS將域名解析到多個IP地址，不同用戶訪問不同的IP地址，來實現(xiàn)應(yīng)用服務(wù)流量的分配。同時通過健康檢查動態(tài)更新DNS解析IP列表，實現(xiàn)故障隔離以及故障切換。最終用戶的訪問直接連接服務(wù)的IP地址，并不通過GTM。
而 SLB 是通過代理用戶訪問請求的形式將用戶訪問請求實時分發(fā)到不同的服務(wù)器，最終用戶的訪問流量必須要經(jīng)過SLB。 一般來說，相同Region使用SLB進行負載均衡，不同region的多個SLB地址時，則可以使用GTM進行負載均衡。

2.4 Hot & Warm 架構(gòu)

熱節(jié)點存放用戶最關(guān)心的熱數(shù)據(jù)；溫節(jié)點或者冷節(jié)點存放用戶不太關(guān)心或者關(guān)心優(yōu)先級低的冷數(shù)據(jù)或者暖數(shù)據(jù)。
它的典型的應(yīng)用場景如下：
在成本有限的前提下，讓客戶關(guān)注的實時數(shù)據(jù)和歷史數(shù)據(jù)硬件隔離，最大化解決客戶反應(yīng)的響應(yīng)時間慢的問題。業(yè)務(wù)場景描述：每日增量6TB日志數(shù)據(jù)，高峰時段寫入及查詢頻率都較高，集群壓力較大，查詢ES時，常出現(xiàn)查詢緩慢問題。

• ES集群的索引寫入及查詢速度主要依賴于磁盤的IO速度，冷熱數(shù)據(jù)分離的關(guān)鍵為使用SSD磁盤存儲熱數(shù)據(jù)，提升查詢效率。
• 若全部使用SSD，成本過高，且存放冷數(shù)據(jù)較為浪費，因而使用普通SATA磁盤與SSD磁盤混搭，可做到資源充分利用，性能大幅提升的目標。

ES為什么要設(shè)計Hot & Warm 架構(gòu)呢？

• ES數(shù)據(jù)通常不會有 Update操作;
• 適用于Time based索引數(shù)據(jù)，同時數(shù)據(jù)量比較大的場景。
• 引入 Warm節(jié)點，低配置大容量的機器存放老數(shù)據(jù)，以降低部署成本

兩類數(shù)據(jù)節(jié)點，不同的硬件配置：

• Hot節(jié)點(通常使用SSD)︰索引不斷有新文檔寫入。
• Warm 節(jié)點（通常使用HDD)︰索引不存在新數(shù)據(jù)的寫入，同時也不存在大量的數(shù)據(jù)查詢

Hot Nodes：用于數(shù)據(jù)的寫入

• lndexing 對 CPU和IO都有很高的要求，所以需要使用高配置的機器
• 存儲的性能要好，建議使用SSD
  

Warm Nodes
用于保存只讀的索引，比較舊的數(shù)據(jù)。通常使用大容量的磁盤

配置Hot & Warm 架構(gòu)
使用Shard Filtering實現(xiàn)Hot&Warm node間的數(shù)據(jù)遷移

• node.attr來指定node屬性：hot或是warm。
• 在index的settings里通過index.routing.allocation來指定索引（index)到一個滿足要求的node
  
  使用 Shard Filtering，步驟分為以下幾步：
• 標記節(jié)點(Tagging)
• 配置索引到Hot Node
• 配置索引到 Warm節(jié)點

1）標記節(jié)點
需要通過“node.attr”來標記一個節(jié)點

• 節(jié)點的attribute可以是任何的key/value
• 可以通過elasticsearch.yml 或者通過-E命令指定

# 標記一個 Hot 節(jié)點
elasticsearch.bat  -E node.name=hotnode -E cluster.name=tulingESCluster -E http.port=9200 -E path.data=hot_data -E node.attr.my_node_type=hot# 標記一個 warm 節(jié)點
elasticsearch.bat  -E node.name=warmnode -E cluster.name=tulingESCluster -E http.port=9201 -E path.data=warm_data -E node.attr.my_node_type=warm# 查看節(jié)點
GET /_cat/nodeattrs?v

2）配置Hot數(shù)據(jù)
創(chuàng)建索引時候，指定將其創(chuàng)建在hot節(jié)點上

# 配置到 Hot節(jié)點
PUT /index-2022-05
{"settings":{"number_of_shards":2,"number_of_replicas":0,"index.routing.allocation.require.my_node_type":"hot"}
}POST /index-2022-05/_doc
{"create_time":"2022-05-27"
}#查看索引文檔的分布
GET _cat/shards/index-2022-05?v

3）舊數(shù)據(jù)移動到Warm節(jié)點
Index.routing.allocation是一個索引級的dynamic setting，可以通過API在后期進行設(shè)定

# 配置到 warm 節(jié)點
PUT /index-2022-05/_settings
{  "index.routing.allocation.require.my_node_type":"warm"
}
GET _cat/shards/index-2022-05?v

2.5 如何對集群的容量進行規(guī)劃

一個集群總共需要多少個節(jié)點?一個索引需要設(shè)置幾個分片？規(guī)劃上需要保持一定的余量，當負載出現(xiàn)波動，節(jié)點出現(xiàn)丟失時，還能正常運行。做容量規(guī)劃時，一些需要考慮的因素：

• 機器的軟硬件配置
• 單條文檔的大小│文檔的總數(shù)據(jù)量│索引的總數(shù)據(jù)量（(Time base數(shù)據(jù)保留的時間)|副本分片數(shù)
• 文檔是如何寫入的(Bulk的大小)
• 文檔的復雜度，文檔是如何進行讀取的(怎么樣的查詢和聚合)

評估業(yè)務(wù)的性能需求：

• 數(shù)據(jù)吞吐及性能需求
  • 數(shù)據(jù)寫入的吞吐量，每秒要求寫入多少數(shù)據(jù)?
  • 查詢的吞吐量?
• 單條查詢可接受的最大返回時間?
  • 了解你的數(shù)據(jù)
  • 數(shù)據(jù)的格式和數(shù)據(jù)的Mapping
  • 實際的查詢和聚合長的是什么樣的

ES集群常見應(yīng)用場景：

• 搜索: 固定大小的數(shù)據(jù)集
  • 搜索的數(shù)據(jù)集增長相對比較緩慢
• 日志: 基于時間序列的數(shù)據(jù)
  • 使用ES存放日志與性能指標。數(shù)據(jù)每天不斷寫入，增長速度較快
  • 結(jié)合Warm Node 做數(shù)據(jù)的老化處理

硬件配置：

• 選擇合理的硬件，數(shù)據(jù)節(jié)點盡可能使用SSD
• 搜索等性能要求高的場景，建議SSD
  • 按照1∶10-20的比例配置內(nèi)存和硬盤
• 日志類和查詢并發(fā)低的場景，可以考慮使用機械硬盤存儲
  • 按照1:50的比例配置內(nèi)存和硬盤
• 單節(jié)點數(shù)據(jù)建議控制在2TB以內(nèi)，最大不建議超過5TB
• JVM配置機器內(nèi)存的一半，JVM內(nèi)存配置不建議超過32G
• 不建議在一臺服務(wù)器上運行多個節(jié)點

內(nèi)存大小要根據(jù)Node 需要存儲的數(shù)據(jù)來進行估算

• 搜索類的比例建議: 1:16
• 日志類: 1:48——1:96之間

假設(shè)總數(shù)據(jù)量1T，設(shè)置一個副本就是2T總數(shù)據(jù)量

• 如果搜索類的項目，每個節(jié)點31*16 = 496 G，加上預留空間。所以每個節(jié)點最多400G數(shù)據(jù)，至少需要5個數(shù)據(jù)節(jié)點
• 如果是日志類項目，每個節(jié)點31*50= 1550 GB，2個數(shù)據(jù)節(jié)點即可

部署方式：

• 按需選擇合理的部署方式
• 如果需要考慮可靠性高可用，建議部署3臺單一的Master節(jié)點
• 如果有復雜的查詢和聚合，建議設(shè)置Coordinating節(jié)點

集群擴容：

• 增加Coordinating / Ingest Node
• 解決CPU和內(nèi)存開銷的問題
• 增加數(shù)據(jù)節(jié)點
• 解決存儲的容量的問題
• 為避免分片分布不均的問題，要提前監(jiān)控磁盤空間，提前清理數(shù)據(jù)或增加節(jié)點

2.6 如何設(shè)計和管理分片

單個分片

• 7.0開始，新創(chuàng)建一個索引時，默認只有一個主分片。單個分片，查詢算分，聚合不準的問題都可以得以避免
• 單個索引，單個分片時候，集群無法實現(xiàn)水平擴展。即使增加新的節(jié)點，無法實現(xiàn)水平擴展

兩個分片
集群增加一個節(jié)點后，Elasticsearch 會自動進行分片的移動，也叫 Shard Rebalancing

算分不準的原因
相關(guān)性算分在分片之間是相互獨立的，每個分片都基于自己的分片上的數(shù)據(jù)進行相關(guān)度計算。這會導致打分偏離的情況，特別是數(shù)據(jù)量很少時。當文檔總數(shù)很少的情況下，如果主分片大于1，主分片數(shù)越多，相關(guān)性算分會越不準
一個示例如下：

PUT /blogs
{"settings":{"number_of_shards" : "3"}
}POST /blogs/_doc/1?routing=fox
{"content":"Cross Cluster elasticsearch Search"
}POST /blogs/_doc/2?routing=fox2
{"content":"elasticsearch Search"
}POST /blogs/_doc/3?routing=fox3
{"content":"elasticsearch"
}GET /blogs/_search
{"query": {"match": {"content": "elasticsearch"}}
}#解決算分不準的問題
GET /blogs/_search?search_type=dfs_query_then_fetch
{"query": {"match": {"content": "elasticsearch"}}
}

解決算分不準的方法：

• 數(shù)據(jù)量不大的時候，可以將主分片數(shù)設(shè)置為1。當數(shù)據(jù)量足夠大時候，只要保證文檔均勻分散在各個分片上，結(jié)果一般就不會出現(xiàn)偏差
• 使用DFS Query Then Fetch
  • 搜索的URL中指定參數(shù)“_search?search_type=dfs_query_then_fetch"
  • 到每個分片把各分片的詞頻和文檔頻率進行搜集，然后完整的進行一次相關(guān)性算分

但是這樣耗費更加多的CPU和內(nèi)存，執(zhí)行性能低下，一般不建議使用

如何設(shè)計分片數(shù)
當分片數(shù)>節(jié)點數(shù)時

• 一旦集群中有新的數(shù)據(jù)節(jié)點加入，分片就可以自動進行分配
• 分片在重新分配時，系統(tǒng)不會有downtime

多分片的好處: 一個索引如果分布在不同的節(jié)點，多個節(jié)點可以并行執(zhí)行

• 查詢可以并行執(zhí)行
• 數(shù)據(jù)寫入可以分散到多個機器

分片過多所帶來的副作用
Shard是Elasticsearch 實現(xiàn)集群水平擴展的最小單位。過多設(shè)置分片數(shù)會帶來一些潛在的問題：

• 每個分片是一個Lucene的索引，會使用機器的資源。過多的分片會導致額外的性能開銷。
• 每次搜索的請求,需要從每個分片上獲取數(shù)據(jù)
• 分片的Meta 信息由Master節(jié)點維護。過多，會增加管理的負擔。經(jīng)驗值，控制分片總數(shù)在10W以內(nèi)

如何確定主分片數(shù)
從存儲的物理角度看：

• 搜索類應(yīng)用，單個分片不要超過20 GB
• 日志類應(yīng)用，單個分片不要大于50 GB

為什么要控制分片存儲大小：

• 提高Update 的性能
• 進行Merge 時，減少所需的資源
• 丟失節(jié)點后，具備更快的恢復速度
• 便于分片在集群內(nèi) Rebalancing

如何確定副本分片數(shù)
副本是主分片的拷貝：

• 提高系統(tǒng)可用性︰響應(yīng)查詢請求，防止數(shù)據(jù)丟失
• 需要占用和主分片一樣的資源

對性能的影響：

• 副本會降低數(shù)據(jù)的索引速度: 有幾份副本就會有幾倍的CPU資源消耗在索引上
• 會減緩對主分片的查詢壓力，但是會消耗同樣的內(nèi)存資源。如果機器資源充分，提高副本數(shù)，可以提高整體的查詢QPS

ES的分片策略會盡量保證節(jié)點上的分片數(shù)大致相同，但是有些場景下會導致分配不均勻：

• 擴容的新節(jié)點沒有數(shù)據(jù)，導致新索引集中在新的節(jié)點
• 熱點數(shù)據(jù)過于集中，可能會產(chǎn)生性能問題

可以通過調(diào)整分片總數(shù)，避免分配不均衡

• index.routing.allocation.total_shards_per_node，index級別的，表示這個index每個Node總共允許存在多少個shard，默認值是-1表示無窮多個；
• cluster.routing.allocation.total_shards_per_node，cluster級別，表示集群范圍內(nèi)每個Node允許存在有多少個shard。默認值是-1表示無窮多個。

如果目標Node的Shard數(shù)超過了配置的上限，則不允許分配Shard到該Node上。注意：index級別的配置會覆蓋cluster級別的配置