乾貨 | Elasticsearch 冷熱集羣架構實戰

0、題記
Elasticsearch實戰數據量級少的時候，單節點就能玩的很6，可是隨着數據量的增加，多節點分佈式橫向擴展集羣是大勢所趨。
以前分享過基於時間建立索引及Curator實現索引生命週期管理。
當集羣硬件資源有限，尤爲SSD磁盤更緊俏的業務場景下，最大化集羣的性能，如何讓用戶最關心的「熱」數據分佈到SSD磁盤對應的節點上，讓用戶關注程度弱的「冷」數據分散到普通磁盤對應節點上？也就是說「冷熱」數據分離是本文討論的內容。
提到冷熱集羣架構，一般咱們關注的問題以下：
什麼是冷熱集羣架構，Elasticsearch支持嗎？
Elasticsearch集羣如何設置冷熱節點？
Elasticsearch集羣如何根據數據冷熱度寫入到不一樣的節點？
當數據不「熱」時，如何將數據遷移到「冷」節點？
本文在Elasticsearch7.3版本上一 一給出解答。
一、什麼是冷熱架構？
官方叫法：熱暖架構——「Hot-Warm」 Architecture。
通俗解讀：熱節點存放用戶最關心的熱數據；溫節點或者冷節點存放用戶不太關心或者關心優先級低的冷數據或者暖數據。

圖片來源cnblog 毛臺的博客
1.1 官方解讀冷熱架構
冷熱架構是一項十分強大的功能，可以讓您將 Elasticsearch 部署劃分爲「熱」數據節點和「冷」數據節點。
熱數據節點處理全部新輸入的數據，而且存儲速度也較快，以便確保快速地採集和檢索數據。
冷節點的存儲密度則較大，如需在較長保留期限內保留日誌數據，不失爲一種具備成本效益的方法。
將這兩種類型的數據節點結合到一塊兒後，您便可以有效地處理輸入數據，並將其用於查詢，同時還能在節省成本的前提下在較長時間內保留數據。
此架構對日誌用例來講尤爲大有幫助，由於在日誌用例中，人們的大部分精力都會專一於近期的日誌（例如最近兩週），而較早的日誌（因爲合規性或者其餘緣由仍須要保留）則能夠接受較慢的查詢時間。
1.2 典型應用場景
一句話：在成本有限的前提下，讓客戶關注的實時數據和歷史數據硬件隔離，最大化解決客戶反應的響應時間慢的問題。
業務場景描述：
每日增量6TB日誌數據，高峯時段寫入及查詢頻率都較高，集羣壓力較大，查詢ES時，常出現查詢緩慢問題。
ES集羣的索引寫入及查詢速度主要依賴於磁盤的IO速度，冷熱數據分離的關鍵爲使用SSD磁盤存儲熱數據，提高查詢效率。
若所有使用SSD，成本太高，且存放冷數據較爲浪費，於是使用普通SATA磁盤與SSD磁盤混搭，可作到資源充分利用，性能大幅提高的目標。
二、最最核心的實現原理
藉助 Elasticsearch的分片分配策略，確切的說是：
第一：集羣節點層面支持規劃節點類型，這是劃分熱暖節點的前提。
第二：索引層面支持將數據路由到給定節點，這爲數據寫入冷、熱節點作了保障。
Shard allocation awareness
https://www.elastic.co/guide/en/elasticsearch/reference/current/allocation-awareness.html
Index-level shard allocation filtering
https://www.elastic.co/guide/en/elasticsearch/reference/current/shard-allocation-filtering.html#
三、7.X版本ES實踐一把
第一：搭建一個兩個節點的集羣，劃分熱、熱節點用。
節點層面設置節點類型。
熱節點指定：
1node.attr.hotwarm_type: hot
暖節點或冷節點指定：
1node.attr.hotwarm_type: warm
第二：寫入操做
方案一：索引層面指定路由。
1PUT /logs_2019-10-01
2{
3 "settings": {
4 "index.routing.allocation.require.hotwarm_type": "hot",
5 "number_of_replicas": 0
6 }
7}
8
9
10PUT /logs_2019-08-01
11{
12 "settings": {
13 "index.routing.allocation.require.hotwarm_type": "warm",
14 "number_of_replicas": 0
15 }
16}
方案二：經過模板指定索引的冷熱存儲。
1PUT _template/logs_2019-08-template
2{
3 "index_patterns": "logs_2019-08-",
4 "settings": {
5 "index.number_of_replicas": "0",
6 "index.routing.allocation.require.hotwarm_type": "warm"
7 }
8}
9PUT _template/logs_2019-10-template
10{
11 "index_patterns": "logs_2019-10-",
12 "settings": {
13 "index.number_of_replicas": "0",
14 "index.routing.allocation.require.hotwarm_type": "hot"
15 }
16}
第三：效果圖詳見附件圖。

能夠看出，兩個索引分不到不一樣的節點上。

第四：藉助curator按期遷移數據
隨着時間發展，當前數據會成爲歷史數據。
歷史數據要自動切換到普通磁盤的節點存儲，能夠藉助curator實現。
cuator的安裝再也不追溯，詳細請參考官方文檔。
https://www.elastic.co/guide/en/elasticsearch/client/curator/5.8/command-line.html
步驟1：定義cuator.yml，填寫Elasticsearch集羣配置信息。

步驟2：定義action.yml。

1actions:
2 1:
3 action: allocation
4 description: >-
5 Apply shard allocation routing to 'require' 'tag=cold' for hot/cold node
6 setup for logstash- indices older than 3 days, based on index_creation
7 date
8 options:
9 key: hotwarm_type
10 value: warm
11 allocation_type: require
12 disableaction: false
13 filters:
14 - filtertype: pattern
15 kind: prefix
16 value: logs
17 - filtertype: age
18 source: name
19 direction: older
20 timestring: "%Y-%m-%d"
21 unit: days
22 unit_count: 3
步驟3：執行遷移。

1C:\Program Files\elasticsearch-curator>curator.exe --config .\conf\curator.yml .\conf\action.yml
22019-10-13 22:28:31,662 INFO Preparing Action ID: 1, "allocation"
32019-10-13 22:28:31,662 INFO Creating client object and testing connection
42019-10-13 22:28:31,668 INFO Instantiating client object
52019-10-13 22:28:31,668 INFO Testing client connectivity
62019-10-13 22:28:31,675 INFO Successfully created Elasticsearch client object with provided settings
72019-10-13 22:28:31,677 INFO Trying Action ID: 1, "allocation": Apply shard allocation routing to 'require' 'tag=cold' f....
82019-10-13 22:28:31,706 INFO Updating 2 selected indices: ['logs_2019-08-01', 'logs_2019-10-01']
92019-10-13 22:28:31,706 INFO Updating index setting {'index.routing.allocation.require.hotwarm_type': 'warm'}
102019-10-13 22:28:32,559 INFO Action ID: 1, "allocation" completed.
112019-10-13 22:28:32,560 INFO Job completed.
四、坑
1node.attr.hotwarm_type:
單純搜索官網你是找不到的。
由於：node.attr.*，你能夠指定type類型、各類結合業務場景你的須要指定的值。
包括：官方的按照磁盤大小設定。和我們的冷熱節點。
白話文：就是標定節點劃分分類的一個屬性類型值。
這個坑網友也有疑惑：node屬性(tag)如何設置，查資料看到了好幾種方法很混亂 - Elastic 中文社區，官方文檔說的不是特別清楚。
五、線上使用場景
來自星友的線上實戰反饋以下：
咱們現有的架構也是冷熱分離。
熱節點使用的是ssd，indexing和search性能都不錯，其中保存4天的數據，4天以後數據推到warm節點。
warm節點使用的是hdd。
在運維過程當中，能體會到這種架構的特色是：
冷節點或者熱節點的離羣不會影響另一個種類型節點的功能；
可是若是整個集羣中有節點產生stw（Java中一種全局暫停現象，全局停頓，全部Java代碼中止，native代碼能夠執行，但不能與JVM交互；這些現象多半是因爲gc引發。），整個集羣的性能都會被影響。
這種架構能在相對節約成本的前提下極大的提高性能，可是不能徹底作到一種類型節點的故障對其餘類型節點是無感的。
六、小結
Elasticsearch6.6版本後已推出索引生命週期管理ilm功能。涵蓋了冷熱集羣的部署和自動化實現。最新實現參考：
https://www.elastic.co/guide/en/elasticsearch/reference/7.4/index-lifecycle-management.html
官方最先2015年的博客就提到了冷熱集羣架構的實現，但「再顯而易見的道理，也有80%的人可能不知道」並考慮到你們使用場景的良莠不齊，才梳理出本篇文章。
你的集羣使用冷熱架構了嗎？ 歡迎交流。
七、Good 參考深刻學習
1）最新冷熱架構官方文檔：
https://www.elastic.co/cn/blog/deploying-a-hot-warm-logging-cluster-on-the-elasticsearch-service
2）最多參考冷熱架構文檔：
https://www.elastic.co/cn/blog/hot-warm-architecture-in-elasticsearch-5-x
3）國內最佳實踐：elasticsearch冷熱數據讀寫分離
https://elasticsearch.cn/article/6127