完美避坑！記一次Elasticsearch集群遷移架構(gòu)實戰(zhàn)
作者介紹
李猛(ynuosoft)，Elastic-stack產(chǎn)品深度用戶，ES認(rèn)證工程師，2012年接觸Elasticsearch，對Elastic-Stack開發(fā)、架構(gòu)、運維等方面有深入體驗，實踐過多種Elasticsearch項目，最暴力的大數(shù)據(jù)分析應(yīng)用，最復(fù)雜的業(yè)務(wù)系統(tǒng)應(yīng)用；業(yè)余為企業(yè)提供Elastic-stack咨詢培訓(xùn)以及調(diào)優(yōu)實施。
Elastic自身設(shè)計了集群分片的負(fù)載平衡機制，當(dāng)有新數(shù)據(jù)節(jié)點加入集群或者離開集群，集群會自動平衡分片的負(fù)載分布。
公司原有大數(shù)據(jù)平臺基于公有云構(gòu)建，由于種種原因，現(xiàn)在需要遷移到自建機房，Elasticsearch集群承擔(dān)了大數(shù)據(jù)平臺主要的對外查詢需求，也有部分實時計算需求基于Elasticsearch實現(xiàn)，所以需要在不影響應(yīng)用系統(tǒng)體驗的情況下做到平滑的遷移。本次分享講述我們?nèi)绾芜M行平滑遷移以及如何避坑。
需要遷移的主要有兩部分：
對外提供的服務(wù)API，這些API是與Elastic集群綁定的，屬于業(yè)務(wù)場景定制化開發(fā)；
Elasticsearch集群遷移，數(shù)據(jù)需要遷移，節(jié)點也需要全部遷移。
圖示：公有云集群+自建機房集群示意圖，業(yè)務(wù)系統(tǒng)查詢圖
大數(shù)據(jù)平臺的Elastic集群直接對外提供實時查詢服務(wù)，任何影響Elastic集群平穩(wěn)的操作都應(yīng)該避免，那我們的集群遷移策略也側(cè)重平穩(wěn)，時間上可以寬松一些，遷移主要的工作有以下幾個：
關(guān)閉集群自動平衡；
啟動自有機房新節(jié)點與公有云自建集群組成一個集群；
人工遷移集群數(shù)據(jù)到新節(jié)點；
外圍訪問切換到新節(jié)點；
關(guān)閉公有云節(jié)點；
開啟集群自動平衡。
遷移過程中有很多步驟操作，是有嚴(yán)格先后順序的，如果出錯則會造成集群動蕩，影響應(yīng)用體驗。此時Elastic的版本是6.5.X，當(dāng)時最新的版本，遷移完成之后也全部升級到6.8.X。
圖示：原有集群架構(gòu)，數(shù)據(jù)節(jié)點與管理節(jié)點分離
1）Elasticsearch節(jié)點有很多角色（管理節(jié)點、數(shù)據(jù)節(jié)點，協(xié)調(diào)節(jié)點），默認(rèn)單節(jié)點常用角色全部開啟。所以在早期搭建Elastic集群時，就按照角色分離的職責(zé)將管理節(jié)點與數(shù)據(jù)節(jié)點分離部署，這也是后面集群遷移能夠順利進行的重要前提。多數(shù)初學(xué)者在剛剛接觸Elastic投入生產(chǎn)環(huán)境時會犯一個錯誤，節(jié)點角色不分離，當(dāng)數(shù)據(jù)節(jié)點的資源消耗過度會導(dǎo)致集群管理節(jié)點響應(yīng)變慢，從而影響整體集群響應(yīng)。
#管理節(jié)點角色設(shè)置
node.master: true
node.data: false
#數(shù)據(jù)節(jié)點角色設(shè)置
node.master: false
node.data: true
2）Elastic對外提供服務(wù)時中間會增加一層負(fù)載代理，如定制服務(wù)API與實時計算應(yīng)用訪問Elastic集群都需要走代理。
3）Hadoop集群與Elastic集群互相訪問是基于官方提供的ES-Hadoop驅(qū)動包，由于實現(xiàn)原理的限制，不能做代理，所以是直接訪問，都是離線任務(wù)交互。
1）因為是遷移到新集群節(jié)點，原有節(jié)點最后都需要關(guān)閉，新集群節(jié)點同樣也需要管理節(jié)點與數(shù)據(jù)節(jié)點分離，新舊節(jié)點需要平滑遷移，所以新舊節(jié)點在啟動之后就需要在同一集群中，新節(jié)點Hosts同時指向新管理節(jié)點與舊管理節(jié)點 ，關(guān)鍵設(shè)置如下：
#配置管理節(jié)點IP+PORT
discovery.zen.ping.unicast.hosts: ["多個舊管理節(jié)點 IP:PORT","多個新管理節(jié)點 IP:PORT"]
2）新集群服務(wù)器采用的全部是物理機，CPU核數(shù)很多，內(nèi)存充足，掛載了多個硬盤，為了充分利用物理機性能，所以單服務(wù)器會部署多實例，主要是部署多個數(shù)據(jù)節(jié)點。在同一機器啟動多個Elastic實例，需要做資源隔離，尤其是CPU核數(shù)隔離，CPU的核數(shù)決定了Elastic默認(rèn)線程池的線程數(shù)，如果不做設(shè)置，默認(rèn)啟動多個數(shù)據(jù)實例，會出現(xiàn)資源競爭問題，設(shè)置如下：
#配置處理器數(shù)量
processors: 數(shù)值<=（CPU核數(shù)/實例數(shù)）
3）公有云與自建機房直接通過專線連接，新舊集群節(jié)點在啟動之后依然是一個集群。
圖示：新舊集群示意圖與多實例示意圖
Elasticsearch集群有自動的數(shù)據(jù)分片平衡分配機制，默認(rèn)是按照分片的數(shù)量平均分布，集群每個數(shù)據(jù)節(jié)點上的索引分片數(shù)量默認(rèn)是相同的，最多有奇偶不一致。
當(dāng)有新的帶有數(shù)據(jù)角色節(jié)點加入集群或者離開集群，集群會默認(rèn)啟動自動平衡機制，索引分片會在數(shù)據(jù)節(jié)點之間平衡漂移，達到平均分布之后停止，頻繁的集群節(jié)點加入或者下線會嚴(yán)重影響集群的IO，影響集群響應(yīng)速度，所以要盡量避免次情況發(fā)生。說到這里，在我的從業(yè)中，發(fā)現(xiàn)很多初級運維人員在部署Elastic集群時，會很喜歡設(shè)置系統(tǒng)級別Elastic實例進程自動啟動，這個其實是個很糟糕的機制，當(dāng)發(fā)現(xiàn)服務(wù)器Elastic實例關(guān)閉，不是馬上重啟，而是需要人工介入分析具體原因，如果頻繁關(guān)閉重啟，這樣很容易造成集群問題。
1）第一個是禁用集群自動平衡，首先要禁止集群新創(chuàng)建索引，新索引之間分配到新的數(shù)據(jù)節(jié)點，其次防止新的數(shù)據(jù)節(jié)點啟動之后，集群分片開始平衡遷移，影響集群IO，設(shè)置如下：
#禁用集群新創(chuàng)建索引分配
cluster.routing.allocation.enable: false
#禁用集群自動平衡
cluster.routing.rebalance.enable: false
2）第二個是限制已有索引數(shù)據(jù)的分布范圍，暫時只容許分布在舊的數(shù)據(jù)節(jié)點上，舊集群數(shù)據(jù)節(jié)點在早期部署時并未設(shè)置自定義標(biāo)簽，所以只能通過設(shè)置IP范圍限制，還有就是后面在遷移數(shù)據(jù)時需要按找索引維度逐步遷移，控制集群遷移的并行度。設(shè)置如下：
#限制索引的分布范圍
"index.routing.allocation.include._ip": "多個舊集群IP"
在禁用舊集群的數(shù)據(jù)自動平衡之后，啟動新集群數(shù)據(jù)節(jié)點，這一步是安全的，可以全部啟動，此時集群數(shù)據(jù)節(jié)點有很多，舊數(shù)據(jù)節(jié)點有數(shù)據(jù)，新數(shù)據(jù)節(jié)點無數(shù)據(jù)，新的數(shù)據(jù)節(jié)點無任何查詢與寫入。
由于新數(shù)據(jù)節(jié)點是全新搭建，可以提前設(shè)置節(jié)點自定義屬性，方便之后運維設(shè)置。設(shè)置如下：
#集群機架屬性
node.attr.rack: rack1
#集群數(shù)據(jù)中心
node.attr.zone: zone1
#實例節(jié)點硬盤
node.attr.disk: ssd1
#更多屬性......
node.attr.xxxx: yyy1
...
圖示：僅優(yōu)先啟動數(shù)據(jù)節(jié)點
Elasticsearch集群主要有幾個使用方：
1）Hadoop平臺離線數(shù)據(jù)寫入ES，從ES抽取數(shù)據(jù)。Elastic提供了Hadoop直連訪問驅(qū)動。如Hive是通過創(chuàng)建映射表與Elasticsearch索引關(guān)聯(lián)的，新的數(shù)據(jù)節(jié)點啟動之后，原有所有Hive-Es映射表需要全部重新創(chuàng)建，更換其中的IP+PORT指向；由于Hive有很多與Elastic關(guān)聯(lián)的表，所以短時間內(nèi)沒有那么快替換完成，新舊數(shù)據(jù)節(jié)點需要共存一段時間，不能在數(shù)據(jù)遷移完成之后馬上關(guān)閉。
#Hive指定連接
es.nodes=多個數(shù)據(jù)節(jié)點IP+PORT
2）業(yè)務(wù)系統(tǒng)應(yīng)用實時查詢。這種切換比較簡單，Elastic集群對外提供了代理訪問，業(yè)務(wù)系統(tǒng)應(yīng)用訪問首先要調(diào)用大數(shù)據(jù)提供的API，這些定制化的API內(nèi)部也是通過代理訪問Elastic集群。
3）大數(shù)據(jù)中心應(yīng)用實時計算數(shù)據(jù)寫入。實時計算程序上游有kafka隊列，基于kafka自帶的offset機制，在新集群啟動實時計算應(yīng)用，然后關(guān)閉舊集群實時計算應(yīng)用，就可以完成切換。
為什么要手動遷移數(shù)據(jù) ？
公有云與新集群機房是跨網(wǎng)段，網(wǎng)絡(luò)帶寬有限；
集群中有很多大索引，單索引數(shù)據(jù)超過數(shù)百GB，這種索引移動會會很傷集群IO；
新舊數(shù)據(jù)節(jié)點會共存一段時間，自動平衡會導(dǎo)致大量的跨網(wǎng)絡(luò)的查詢與寫入，很傷網(wǎng)絡(luò)IO。
遷移數(shù)據(jù)的原則如下：
索引數(shù)據(jù)量小的優(yōu)先；
離線更新的索引數(shù)據(jù)優(yōu)先；
業(yè)務(wù)系統(tǒng)查詢頻率低索引數(shù)據(jù)的優(yōu)先；
遷移索引數(shù)據(jù)控制并行度，每次操作控制在網(wǎng)絡(luò)帶寬限制之內(nèi)。
遷移數(shù)據(jù)也是通過限制索引分布IP范圍，設(shè)置如下：
#限制索引的分布范圍
"index.routing.allocation.include._ip": "多個新集群IP"
關(guān)閉舊集群數(shù)據(jù)節(jié)點是一個逐步的過程，一個一個關(guān)閉，在一段時間內(nèi)新舊集群數(shù)據(jù)節(jié)點需要共存，應(yīng)用訪問切換并沒有那么快進行，且要支持隨時回滾操作。關(guān)閉舊集群據(jù)節(jié)點有2個前提條件，如下：
舊集群索引數(shù)據(jù)必須遷移完成；
集群訪問切換必須已經(jīng)完成。
圖示：關(guān)閉舊集群數(shù)據(jù)節(jié)點
為什么要在最后啟動新集群管理節(jié)點？并且同步關(guān)閉舊集群管理節(jié)點？
一個Elasticsearch集群只有一個工作管理節(jié)點，負(fù)責(zé)維護集群所有的元數(shù)據(jù)信息；其余的是備選管理節(jié)點，只是同步集群元數(shù)據(jù)信息，不參與協(xié)調(diào)管理。工作主節(jié)點關(guān)閉集群需要重新選舉工作主節(jié)點，此時集群會處于半停頓狀態(tài)，雖然很快，也會有影響；
舊集群已經(jīng)有5個管理節(jié)點，其中一個是工作主節(jié)點，其余4個是備選節(jié)點，因為Elastic版本是6.5.X，原有的集群腦裂因子設(shè)置是3=（5/2+1），當(dāng)啟動新集群的管理節(jié)點，若網(wǎng)絡(luò)出現(xiàn)短暫通信問題，集群腦裂因子設(shè)置會無效。
切換新舊管理節(jié)點的策略如下：
每啟動一個新集群管理節(jié)點 ，關(guān)閉一個舊集群備選管理節(jié)點；
最后關(guān)閉舊集群工作管理節(jié)點，集群重新選舉新的工作管理節(jié)點。
圖示：啟動新集群管理節(jié)點
在集群遷移之前，已經(jīng)禁用了集群的自動平衡機制，集群遷移結(jié)束之后，需要恢復(fù)這種機制。
#禁用集群新創(chuàng)建索引分配
cluster.routing.allocation.enable: true
#禁用集群自動平衡
cluster.routing.rebalance.enable: true
在我們能如此平滑的完成Elasticsearch從公有云遷移到自有機房，得益于與共用集群這個概念。
個人認(rèn)為這是Elasticsearch最大特性賣點，設(shè)計上任意節(jié)點都可以很容易加入集群或者離開集群，集群都可以彈性的平滑擴展，基本不影響系統(tǒng)運行穩(wěn)定；
在業(yè)務(wù)系統(tǒng)發(fā)展早期，可以部署少量節(jié)點，發(fā)展后期可以部署更多節(jié)點或者部署更強的服務(wù)器，以達到最佳的性價比配置，從成本與性能平衡；
自動化運維方面節(jié)約成本，相比傳統(tǒng)的關(guān)系型數(shù)據(jù)庫集群規(guī)模龐大之后，需要關(guān)注的點很多，而Elastic很少，大中型集群規(guī)模以下幾乎無需專門的Elastic運維人員。
主從架構(gòu)模式，一個集群只能有一個工作狀態(tài)的管理節(jié)點，其余管理節(jié)點是備選，備選數(shù)量原則上不限制。很多大數(shù)據(jù)產(chǎn)品管理節(jié)點僅支持一主一從，如Greenplum、Hadoop、Prestodb；
工作管理節(jié)點自動選舉，工作管理節(jié)點關(guān)閉之后自動觸發(fā)集群重新選舉，無需外部三方應(yīng)用，無需人工干預(yù)。很多大數(shù)據(jù)產(chǎn)品需要人工切換或者借助第三方軟件應(yīng)用，如Greenplum、Hadoop、Prestodb。
Elasticsearch支持多種節(jié)點角色，一個節(jié)點可以支持多個角色，也可以支持一種角色。
圖示：集群節(jié)點角色
節(jié)點角色說明：
Master，管理節(jié)點，管理集群元數(shù)據(jù)信息，集群節(jié)點信息，集群索引元數(shù)據(jù)信息；
Voting，投票節(jié)點，參與集群管理節(jié)點選舉投票，注意7.X以上版本才支持；
Data，數(shù)據(jù)節(jié)點，存儲實際數(shù)據(jù)，提供初步聯(lián)合查詢，初步聚合查詢，也可以作為協(xié)調(diào)節(jié)點；
Ingest，數(shù)據(jù)處理節(jié)點，類似ETL處理；
Coordinate，協(xié)調(diào)節(jié)點，數(shù)據(jù)查詢協(xié)調(diào)、數(shù)據(jù)寫入?yún)f(xié)調(diào)；
Machine Learning，機器學(xué)習(xí)節(jié)點，模型訓(xùn)練與模型預(yù)測。
Elasticsearch集群中有多個節(jié)點，其中任一節(jié)點都可以查詢數(shù)據(jù)或者寫入數(shù)據(jù)，集群內(nèi)部節(jié)點會有路由機制協(xié)調(diào)，轉(zhuǎn)發(fā)請求到索引分片所在的節(jié)點。我們在遷移集群時采用應(yīng)用代理切換，外部訪問從舊集群數(shù)據(jù)節(jié)點切換到新集群數(shù)據(jù)節(jié)點，就是基于此特點。
圖示：集群路由示意圖，查詢過程/更新過程
分片與副本是Elasticsearch集群實現(xiàn)分布式最重要前提。
分片機制，一個索引可以分成多個分片，分片數(shù)據(jù)可以分布在任意集群數(shù)據(jù)節(jié)點上，此機制可以保證我們遷移大的索引數(shù)據(jù)時，按照分片一個一個遷移，而不用一次性遷移所有的分片，有效減少磁盤IO與網(wǎng)絡(luò)IO；
副本機制，一個索引主分片可以有多個副本分片，主分片與副本分片可以任意切換，無需人工切換。這種機制可以保證我們在遷移大的數(shù)據(jù)索引時，僅遷移主分片數(shù)據(jù)即可，有效減少磁盤IO與網(wǎng)絡(luò)IO。
#副本設(shè)置
index.number_of_replicas: 數(shù)值，默認(rèn)1
#分片遷移API
POST /_cluster/reroute
{
"commands" : [
{
"move" : {
"index" : "test_index", "shard" : 0,
"from_node" : "node1", "to_node" : "node2"
}
}
]}
Elasticsearch本身提供了多種索引分片分布過濾操作，特別是在集群規(guī)模比較大時，需要按照業(yè)務(wù)領(lǐng)域隔離集群資源。如有的業(yè)務(wù)索引是歷史數(shù)據(jù)，數(shù)據(jù)量很大，僅偶爾低頻率查詢，可以做一些冷熱分離設(shè)置。
# 分布過濾設(shè)置
index.routing.allocation.include.{attribute}
index.routing.allocation.require.{attribute}
index.routing.allocation.exclude.{attribute}
Elastic集群遷移到物理機之后，運行性能較之前有很大的提高，并行寫入性能提升好幾倍，查詢與寫入交叉影響降低很多；
Elastic官方文檔非常詳細(xì)的描述了各種特性功能，但并沒有針對數(shù)據(jù)遷移專門列舉一個完整的步驟，掌握Elastic最好的方式是實戰(zhàn)與理論并行，深入Elastic背后的實現(xiàn)原理，嘗試多種項目的實戰(zhàn)。
在跨越速運大數(shù)據(jù)部門任職時，基于公司實際需求，得出的一些經(jīng)驗與思考，提供后來者借鑒參考。
特別推薦一個分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒關(guān)注的小伙伴，可以長按關(guān)注一下：
長按訂閱更多精彩▼
如有收獲，點個在看，誠摯感謝
免責(zé)聲明：本文內(nèi)容由21ic獲得授權(quán)后發(fā)布，版權(quán)歸原作者所有，本平臺僅提供信息存儲服務(wù)。文章僅代表作者個人觀點，不代表本平臺立場，如有問題，請聯(lián)系我們，謝謝！
下載文檔
