覺得這個方案比較不錯，轉載學習。日後可能會用到，來遷移叢集，不管是從共有雲還是私有雲。
作者介紹
李猛(ynuosoft)，Elastic-stack産品深度使用者，ES認證工程師，2012年接觸Elasticsearch，對Elastic-Stack開發、架構、運維等方面有深入體驗，實踐過多種Elasticsearch項目，最暴力的大資料分析應用，最複雜的業務系統應用；業餘為企業提供Elastic-stack咨詢教育訓練以及調優實施。
前言
Elastic自身設計了叢集分片的負載平衡機制，當有新資料節點加入叢集或者離開叢集，叢集會自動平衡分片的負載分布。
需求背景
公司原有大資料平台基于公有雲建構，由于種種原因，現在需要遷移到自建機房，Elasticsearch叢集承擔了大資料平台主要的對外查詢需求，也有部分實時計算需求基于Elasticsearch實作，是以需要在不影響應用系統體驗的情況下做到平滑的遷移。本次分享講述我們如何進行平滑遷移以及如何避坑。
需要遷移的主要有兩部分：
- 對外提供的服務API，這些API是與Elastic叢集綁定的，屬于業務場景定制化開發；
- Elasticsearch叢集遷移，資料需要遷移，節點也需要全部遷移。
圖示：公有雲叢集+自建機房叢集示意圖，業務系統查詢圖
遷移政策
大資料平台的Elastic叢集直接對外提供實時查詢服務，任何影響Elastic叢集平穩的操作都應該避免，那我們的叢集遷移政策也側重平穩，時間上可以寬松一些，遷移主要的工作有以下幾個：
- 關閉叢集自動平衡；
- 啟動自有機房新節點與公有雲自建叢集組成一個叢集；
- 人工遷移叢集資料到新節點；
- 外圍通路切換到新節點；
- 關閉公有雲節點；
- 開啟叢集自動平衡。
遷移步驟
遷移過程中有很多步驟操作，是有嚴格先後順序的，如果出錯則會造成叢集動蕩，影響應用體驗。此時Elastic的版本是6.5.X，當時最新的版本，遷移完成之後也全部更新到6.8.X。
1、原有叢集架構
圖示：原有叢集架構，資料節點與管理節點分離
1）Elasticsearch節點有很多角色（管理節點、資料節點，協調節點），預設單節點常用角色全部開啟。是以在早期搭建Elastic叢集時，就按照角色分離的職責将管理節點與資料節點分離部署，這也是後面叢集遷移能夠順利進行的重要前提。多數初學者在剛剛接觸Elastic投入生産環境時會犯一個錯誤，節點角色不分離，當資料節點的資源消耗過度會導緻叢集管理節點響應變慢，進而影響整體叢集響應。
#管理節點角色設定
node.master: true
node.data: false
#資料節點角色設定
node.master: false
node.data: true
2）Elastic對外提供服務時中間會增加一層負載代理，如定制服務API與實時計算應用通路Elastic叢集都需要走代理。
3）Hadoop叢集與Elastic叢集互相通路是基于官方提供的ES-Hadoop驅動包，由于實作原理的限制，不能做代理，是以是直接通路，都是離線任務互動。
2、配置新叢集
1）因為是遷移到新叢集節點，原有節點最後都需要關閉，新叢集節點同樣也需要管理節點與資料節點分離，新舊節點需要平滑遷移，是以新舊節點在啟動之後就需要在同一叢集中，新節點Hosts同時指向新管理節點與舊管理節點 ，關鍵設定如下：
#配置管理節點IP+PORT
discovery.zen.ping.unicast.hosts: ["多個舊管理節點 IP:PORT","多個新管理節點 IP:PORT"]
2）新叢集伺服器采用的全部是實體機，CPU核數很多，記憶體充足，挂載了多個硬碟，為了充分利用實體機性能，是以單伺服器會部署多執行個體，主要是部署多個資料節點。在同一機器啟動多個Elastic執行個體，需要做資源隔離，尤其是CPU核數隔離，CPU的核數決定了Elastic預設線程池的線程數，如果不做設定，預設啟動多個資料執行個體，會出現資源競争問題，設定如下：
#配置處理器數量
processors: 數值<=（CPU核數/執行個體數）
3）公有雲與自建機房直接通過專線連接配接，新舊叢集節點在啟動之後依然是一個叢集。
圖示：新舊叢集示意圖與多執行個體示意圖
3、禁用叢集資料平衡
Elasticsearch叢集有自動的資料分片平衡配置設定機制，預設是按照分片的數量平均分布，叢集每個資料節點上的索引分片數量預設是相同的，最多有奇偶不一緻。
當有新的帶有資料角色節點加入叢集或者離開叢集，叢集會預設啟動自動平衡機制，索引分片會在資料節點之間平衡漂移，達到平均分布之後停止，頻繁的叢集節點加入或者下線會嚴重影響叢集的IO，影響叢集響應速度，是以要盡量避免次情況發生。說到這裡，在我的從業中，發現很多初級運維人員在部署Elastic叢集時，會很喜歡設定系統級别Elastic執行個體程序自動啟動，這個其實是個很糟糕的機制，當發現伺服器Elastic執行個體關閉，不是馬上重新開機，而是需要人工介入分析具體原因，如果頻繁關閉重新開機，這樣很容易造成叢集問題。
1）第一個是禁用叢集自動平衡，首先要禁止叢集新建立索引，新索引之間配置設定到新的資料節點，其次防止新的資料節點啟動之後，叢集分片開始平衡遷移，影響叢集IO，設定如下：
#禁用叢集新建立索引配置設定
cluster.routing.allocation.enable: false
#禁用叢集自動平衡
cluster.routing.rebalance.enable: false
2）第二個是限制已有索引資料的分布範圍，暫時隻容許分布在舊的資料節點上，舊叢集資料節點在早期部署時并未設定自定義标簽，是以隻能通過設定IP範圍限制，還有就是後面在遷移資料時需要按找索引次元逐漸遷移，控制叢集遷移的并行度。設定如下：
#限制索引的分布範圍
"index.routing.allocation.include._ip": "多個舊叢集IP"
4、啟動新叢集資料節點
在禁用舊叢集的資料自動平衡之後，啟動新叢集資料節點，這一步是安全的，可以全部啟動，此時叢集資料節點有很多，舊資料節點有資料，新資料節點無資料，新的資料節點無任何查詢與寫入。
由于新資料節點是全新搭建，可以提前設定節點自定義屬性，友善之後運維設定。設定如下：
#叢集機架屬性
node.attr.rack: rack1
#叢集資料中心
node.attr.zone: zone1
#執行個體節點硬碟
node.attr.disk: ssd1
#更多屬性......
node.attr.xxxx: yyy1
圖示：僅優先啟動資料節點
5、切換叢集通路
Elasticsearch叢集主要有幾個使用方：
1）Hadoop平台離線資料寫入ES，從ES抽取資料。Elastic提供了Hadoop直連通路驅動。如Hive是通過建立映射表與Elasticsearch索引關聯的，新的資料節點啟動之後，原有所有Hive-Es映射表需要全部重新建立，更換其中的IP+PORT指向；由于Hive有很多與Elastic關聯的表，是以短時間内沒有那麼快替換完成，新舊資料節點需要共存一段時間，不能在資料遷移完成之後馬上關閉。
#Hive指定連接配接
es.nodes=多個資料節點IP+PORT
2）業務系統應用實時查詢。這種切換比較簡單，Elastic叢集對外提供了代理通路，業務系統應用通路首先要調用大資料提供的API，這些定制化的API内部也是通過代理通路Elastic叢集。
3）大資料中心應用實時計算資料寫入。實時計算程式上遊有kafka隊列，基于kafka自帶的offset機制，在新叢集啟動實時計算應用，然後關閉舊叢集實時計算應用，就可以完成切換。
6、手動轉移資料
為什麼要手動遷移資料 ？
- 公有雲與新叢集機房是跨網段，網絡帶寬有限；
- 叢集中有很多大索引，單索引資料超過數百GB，這種索引移動會會很傷叢集IO；
- 新舊資料節點會共存一段時間，自動平衡會導緻大量的跨網絡的查詢與寫入，很傷網絡IO。
遷移資料的原則如下：
- 索引資料量小的優先；
- 離線更新的索引資料優先；
- 業務系統查詢頻率低索引資料的優先；
- 遷移索引資料控制并行度，每次操作控制在網絡帶寬限制之内。
遷移資料也是通過限制索引分布IP範圍，設定如下：
#限制索引的分布範圍
"index.routing.allocation.include._ip": "多個新叢集IP"
7、關閉舊叢集資料節點
關閉舊叢集資料節點是一個逐漸的過程，一個一個關閉，在一段時間内新舊叢集資料節點需要共存，應用通路切換并沒有那麼快進行，且要支援随時復原操作。關閉舊叢集據節點有2個前提條件，如下：
- 舊叢集索引資料必須遷移完成；
- 叢集通路切換必須已經完成。
圖示：關閉舊叢集資料節點
8、啟動新叢集管理節點
為什麼要在最後啟動新叢集管理節點？并且同步關閉舊叢集管理節點？
- 一個Elasticsearch叢集隻有一個工作管理節點，負責維護叢集所有的中繼資料資訊；其餘的是備選管理節點，隻是同步叢集中繼資料資訊，不參與協調管理。工作主節點關閉叢集需要重新選舉工作主節點，此時叢集會處于半停頓狀态，雖然很快，也會有影響；
- 舊叢集已經有5個管理節點，其中一個是工作主節點，其餘4個是備選節點，因為Elastic版本是6.5.X，原有的叢集腦裂因子設定是3=（5/2+1），當啟動新叢集的管理節點，若網絡出現短暫通信問題，叢集腦裂因子設定會無效。
切換新舊管理節點的政策如下：
- 每啟動一個新叢集管理節點 ，關閉一個舊叢集備選管理節點；
- 最後關閉舊叢集工作管理節點，叢集重新選舉新的工作管理節點。
圖示：啟動新叢集管理節點
9、啟用叢集自動平衡
在叢集遷移之前，已經禁用了叢集的自動平衡機制，叢集遷移結束之後，需要恢複這種機制。
#禁用叢集新建立索引配置設定
cluster.routing.allocation.enable: true
#禁用叢集自動平衡
cluster.routing.rebalance.enable: true
涉及技術
1、叢集彈性
在我們能如此平滑的完成Elasticsearch從公有雲遷移到自有機房，得益于與共用叢集這個概念。
- 個人認為這是Elasticsearch最大特性賣點，設計上任意節點都可以很容易加入叢集或者離開叢集，叢集都可以彈性的平滑擴充，基本不影響系統運作穩定；
- 在業務系統發展早期，可以部署少量節點，發展後期可以部署更多節點或者部署更強的伺服器，以達到最佳的成本效益配置，從成本與性能平衡；
- 自動化運維方面節約成本，相比傳統的關系型資料庫叢集規模龐大之後，需要關注的點很多，而Elastic很少，大中型叢集規模以下幾乎無需專門的Elastic運維人員。
2、叢集選舉
- 主從架構模式，一個叢集隻能有一個工作狀态的管理節點，其餘管理節點是備選，備選數量原則上不限制。很多大資料産品管理節點僅支援一主一從，如Greenplum、Hadoop、Prestodb；
- 工作管理節點自動選舉，工作管理節點關閉之後自動觸發叢集重新選舉，無需外部三方應用，無需人工幹預。很多大資料産品需要人工切換或者借助第三方軟體應用，如Greenplum、Hadoop、Prestodb。
3、節點角色
Elasticsearch支援多種節點角色，一個節點可以支援多個角色，也可以支援一種角色。
圖示：叢集節點角色
節點角色說明：
- Master，管理節點，管理叢集中繼資料資訊，叢集節點資訊，叢集索引中繼資料資訊；
- Voting，投票節點，參與叢集管理節點選舉投票，注意7.X以上版本才支援；
- Data，資料節點，存儲實際資料，提供初步聯合查詢，初步聚合查詢，也可以作為協調節點；
- Ingest，資料處理節點，類似ETL處理；
- Coordinate，協調節點，資料查詢協調、資料寫入協調；
- Machine Learning，機器學習節點，模型訓練與模型預測。
4、協調路由
Elasticsearch叢集中有多個節點，其中任一節點都可以查詢資料或者寫入資料，叢集内部節點會有路由機制協調，轉發請求到索引分片所在的節點。我們在遷移叢集時采用應用代理切換，外部通路從舊叢集資料節點切換到新叢集資料節點，就是基于此特點。
5、分片副本
分片與副本是Elasticsearch叢集實作分布式最重要前提。
- 分片機制，一個索引可以分成多個分片，分片資料可以分布在任意叢集資料節點上，此機制可以保證我們遷移大的索引資料時，按照分片一個一個遷移，而不用一次性遷移所有的分片，有效減少磁盤IO與網絡IO；
- 副本機制，一個索引主分片可以有多個副本分片，主分片與副本分片可以任意切換，無需人工切換。這種機制可以保證我們在遷移大的資料索引時，僅遷移主分片資料即可，有效減少磁盤IO與網絡IO。
#副本設定
index.number_of_replicas: 數值，預設1
#分片遷移API
POST /_cluster/reroute
{
"commands" : [
{
"move" : {
"index" : "test_index", "shard" : 0,
"from_node" : "node1", "to_node" : "node2"
}
}
]} 6、分布過濾
Elasticsearch本身提供了多種索引分片分布過濾操作，特别是在叢集規模比較大時，需要按照業務領域隔離叢集資源。如有的業務索引是曆史資料，資料量很大，僅偶爾低頻率查詢，可以做一些冷熱分離設定。
# 分布過濾設定
index.routing.allocation.include.{attribute}
- Elastic叢集遷移到實體機之後，運作性能較之前有很大的提高，并行寫入性能提升好幾倍，查詢與寫入交叉影響降低很多；
- Elastic官方文檔非常詳細的描述了各種特性功能，但并沒有針對資料遷移專門列舉一個完整的步驟，掌握Elastic最好的方式是實戰與理論并行，深入Elastic背後的實作原理，嘗試多種項目的實戰。