UCloud首爾機房整體熱遷移是這樣煉成的

2018年下半年，UCloud首爾數(shù)據(jù)中心因外部原因無法繼續(xù)使用，需要在很短時間內(nèi)將機房全部遷走。為了不影響用戶現(xiàn)網(wǎng)業(yè)務(wù)，我們放棄了離線遷移方案，選擇了非常有挑戰(zhàn)的機房整體熱遷移。經(jīng)過5個月的多部門協(xié)作，終于完成了既定目標，在用戶無感知下，將所有業(yè)務(wù)完整遷移到同樣位于首爾的新機房內(nèi)。

本文將詳述這個大項目中最有難度的工作之一：公共組件與核心管理模塊遷移的方案設(shè)計和實踐歷程。

計劃

整個項目劃分為四個大階段（準備階段、新機房建設(shè)、新舊遷移、舊機房裁撤下線）。正如一位同事的比喻，機房的熱遷移，相當于把一輛高速行駛高鐵上的用戶遷移到另一輛高速行駛的高鐵上，高鐵是我們的機房，高鐵上的用戶是我們的業(yè)務(wù)。要讓遷移可行需要兩輛高鐵相對靜止，一個方法是把兩輛高鐵變成一輛，如此兩者速度就一致了。UCloud機房熱遷移采用類似方案，把兩個機房在邏輯上變成一個機房。為此，上層的業(yè)務(wù)邏輯要在新老機房間無縫遷移，下面的管理系統(tǒng)也要統(tǒng)一成一套。

其中，我們SRE和應(yīng)用運維團隊主要負責以下幾個工作：1）機房核心zookeeper服務(wù)的擴縮容服務(wù)；2）核心數(shù)據(jù)庫中間層udatabase服務(wù)的部署和擴容；3）大部分管理服務(wù)的部署和遷移；4）核心數(shù)據(jù)庫的部署和遷移。以上涉及到前期規(guī)劃、方案設(shè)計、項目實施、穩(wěn)定性保證、變更校驗等所有方面。

挑戰(zhàn)

我們剛接到機房整體熱遷移需求時，著實有些頭疼，首爾機房屬于較早期部署的機房之一，相關(guān)的技術(shù)架構(gòu)比較老舊。而核心數(shù)據(jù)庫、核心配置服務(wù)（zookeeper）、核心數(shù)據(jù)庫中間層（udatabase）等幾個服務(wù)都是比較重要的基礎(chǔ)組件，老舊架構(gòu)可能會因為基礎(chǔ)層面的變動發(fā)生復(fù)雜的大范圍異常，從而影響到存量用戶的日常使用。

幸好SRE團隊在過去一年里，針對各種服務(wù)的資源數(shù)據(jù)進行了全面的梳理，我們開發(fā)了一套集群資源管理系統(tǒng)（Mafia-RMS) ，該系統(tǒng)通過動態(tài)服務(wù)發(fā)現(xiàn)、靜態(tài)注冊等多種手段，對存量和增量的服務(wù)資源進行了整理，每一個機房有哪些服務(wù)、集群，某個集群有哪些服務(wù)器，每一個實例的端口、狀態(tài)、配置等信息，都記錄到了我們的資源管理系統(tǒng)中，如下圖所示：

圖1： UCloud SRE資源管理系統(tǒng)-集群管理功能

通過SRE資源管理系統(tǒng)，可以清楚地知道首爾機房存量內(nèi)部服務(wù)的集群信息、每個實例的狀態(tài)。我們基于SRE資源系統(tǒng)還構(gòu)建了基于Prometheus的SRE監(jiān)控體系，通過上圖右側(cè)Monitor按鈕就可以跳轉(zhuǎn)到監(jiān)控頁面，獲取整個業(yè)務(wù)的實時運行狀況。

有了這些資源數(shù)據(jù)之后，剩下的就是考慮怎么進行這些服務(wù)的擴容和遷移工作。

ZooKeeper服務(wù)的擴縮容

首先是內(nèi)部服務(wù)注冊中心zookeeper的擴縮容。

UCloud內(nèi)部大規(guī)模使用zookeeper作為內(nèi)部服務(wù)注冊和服務(wù)發(fā)現(xiàn)中心，大部分服務(wù)的互訪都是通過使用zookeeper獲取服務(wù)注冊地址，UCloud內(nèi)部使用較多的wiwo框架（C++) 和 uframework (Golang) 都是基于主動狀態(tài)機定時將自己的Endpoint信息注冊到zookeeper中，相同Endpoint前綴的服務(wù)屬于同一個集群，因此對于某些服務(wù)的擴容，新節(jié)點使用相同的Endpoint前綴即可。wiwo和uframework兩個框架的客戶端具備了解析zookeeper配置的能力，可以通過對Endpoint的解析獲取到真實的IP和端口信息。然后通過客戶端負載均衡的方式，將請求發(fā)送到真實的業(yè)務(wù)服務(wù)實例上去，從而完成服務(wù)間的相互調(diào)用。如下圖所示：

圖2：UCloud 首爾機房部署調(diào)用及服務(wù)注冊/發(fā)現(xiàn)路徑圖

首爾老機房的zookeeper集群是一個具有3個節(jié)點的普通集群（當時規(guī)模相對較小，3個節(jié)點足夠）。 然而首爾新機房的規(guī)模要大很多，因此新機房zookeeper的集群規(guī)模也要擴充，經(jīng)過我們的評估，將新機房的zookeeper集群擴充到5個節(jié)點，基本上可以滿足所需。

其實，一個理想的遷移架構(gòu)應(yīng)該是如圖3所示，整個新機房使用和老機房相同的技術(shù)架構(gòu)（架構(gòu)和版本統(tǒng)一），新架構(gòu)完全獨立部署，與老機房并沒有數(shù)據(jù)交互工作，而用戶的業(yè)務(wù)服務(wù)（如UHost/UDB/EIP/VPC等）通過某種方式平滑的實現(xiàn)控制和管理面的遷移，以及物理位置的遷移工作。

圖3：理想狀態(tài)下的老舊機房服務(wù)遷移示意圖

但是理想狀態(tài)在現(xiàn)實中無法達到，內(nèi)部架構(gòu)和代碼邏輯的限制，導(dǎo)致業(yè)務(wù)實例無法平滑實現(xiàn)邏輯和控制層面的遷移，更何況物理層面的遷移。新部署的管理服務(wù)需要和老機房的管理服務(wù)進行通信，因此，我們調(diào)整了新機房服務(wù)的部署架構(gòu)，并適配實際情況分別使用兩種部署模式，如圖4和圖5所示：

圖4： 同集群擴容模式的跨機房服務(wù)部署

圖5： 新建集群灰度遷移模式的跨機房服務(wù)部署

無論是圖4的同集群擴容模式，還是圖5的新建集群灰度遷移模式，在zookeeper層面必須讓新舊機房的zookeeper集群處于一體的狀態(tài)，需要兩個集群的數(shù)據(jù)一致、實時同步。因此在zookeeper的技術(shù)層面，必須將這兩個集群變成一個集群，將原有的3節(jié)點的zookeeper集群，經(jīng)過異地機房擴容的方式擴充到8個節(jié)點（1個leader，7個follower），只有這種模式下數(shù)據(jù)才能夠保持一致性和實時性。

而對于新機房新部署的需要注冊的服務(wù)來說，他們的配置文件中對于zookeeper地址的配置，卻不是新建的8個ip的列表，而是只配置新機房5個IP的列表。這樣新老機房的后端服務(wù)使用同一套zookeeper，但是配置的卻是不同的IP，這樣做的目的，是為了后續(xù)老機房下線裁撤時，所有新機房的服務(wù)不需要因為zookeeper集群的縮容而重啟更新配置，只要將集群中老機房所在的3個節(jié)點下線，剩余5個節(jié)點的配置更新重新選主即可。

因此在zookeeper的機房擴容方案上，我們采用了先同集群擴容后拆分的模式。zookeeper的擴容是整個機房擴建的第一步，后續(xù)所有的服務(wù)都會依托于該操作新建的5個節(jié)點的zookeeper配置；而zookeeper集群的縮容是最后的操作，待所有的服務(wù)都擴容完成，所有業(yè)務(wù)實例遷移完成之后，將zookeeper集群進行縮容重新選主，這樣即可完成整個機房的裁撤。

數(shù)據(jù)庫中間層udatabase的遷移

接下來是數(shù)據(jù)庫中間層udatabase的遷移工作。

圖4和圖5兩種模式對于zookeeper的處理方式是相同的，不同點在于后端對于內(nèi)部管理和控制面服務(wù)的擴容遷移方式。udatabase遷移使用圖4模式，這種模式下相當于在原有的集群進行異地機房擴容，擴容的新實例使用和原有集群相同的Endpoint前綴，也就是說它們是屬于同一個集群，當服務(wù)啟動后，新擴容的實例的狀態(tài)會與原有集群的實例相同，框架（wiwo或uframework）層會通過客戶端方式從zookeeper中發(fā)現(xiàn)到該集群節(jié)點的變化（新增），同時使用某種負載均衡算法將請求流量路由到新的節(jié)點上。這樣屬于同一個集群，但卻處于兩個地址位置的實例都有部分流量，而進行縮容的方式就是直接將老機房同集群的服務(wù)下線即可，這樣客戶端就會將所有該集群的流量都轉(zhuǎn)發(fā)到新機房擴容的節(jié)點上，從而完成平滑的服務(wù)擴容。udatabase通過這樣的方式完成了集群的遷移過程。

新建集群灰度遷移模式

其實圖4模式對于大部分服務(wù)來說都是可行的，但為什么還出現(xiàn)了圖5所示的新建集群灰度遷移模式呢？因為某些場景下圖4會有一定的不可控性。假如新建的實例（如圖4中Service A Instance 2）存在軟件穩(wěn)定性和可靠性的問題，比如配置異常、軟件版本異常、網(wǎng)絡(luò)異常，可能導(dǎo)致路由到新節(jié)點的請求出現(xiàn)問題，會直接影響在線業(yè)務(wù)，影響的規(guī)模由擴容的節(jié)點占集群總節(jié)點的比例決定，像我們這種1：1的擴容方式，如果服務(wù)有問題可能50%的請求就直接異常了。udatabase使用圖4方案，是因為其代碼的穩(wěn)定性比較高，功能和配置比較簡單，主要依托于其高性能的轉(zhuǎn)發(fā)能力。

而對于某些功能邏輯都比較復(fù)雜的業(yè)務(wù)來說（如ULB/CNAT），就使用了更穩(wěn)妥的圖5模式，由于業(yè)務(wù)層面支持跨集群遷移，因此可以新建一個全新的無業(yè)務(wù)流量的集群，該集群在zookeeper中的Endpoint路徑前綴和原有的集群不相同，使用一個全新的路徑，然后在業(yè)務(wù)層面，通過遷移平臺或工具，將后端服務(wù)或?qū)嵗葱柽w移，整個過程可控，出現(xiàn)問題立刻回滾，是最安全的遷移方案。我們通用的灰度遷移平臺SRE-Migrate如圖6所示。

圖6：UCloud內(nèi)部通用業(yè)務(wù)遷移系統(tǒng)SRE-Migrate

機房部署平臺SRE-Asteroid

UCloud產(chǎn)品線和產(chǎn)品名下服務(wù)數(shù)量繁多，無論是圖4還是圖5的方案，都需要大量的服務(wù)部署工作。SRE團隊在2018年中推進的機房部署優(yōu)化項目，意在解決UCloud新機房建設(shè)（國內(nèi)及海外數(shù)據(jù)中心、專有云、私有云等）交付時間長和人力成本巨大的問題，2018年底該項目成功產(chǎn)品化落地，覆蓋主機、網(wǎng)絡(luò)等核心業(yè)務(wù)近百余服務(wù)的部署管理，解決了配置管理、部署規(guī)范、軟件版本等一系列問題。首爾機房遷移也正是利用了這一成果，才能夠在很短的時間內(nèi)完成近百個新集群的部署或擴容工作，圖7所示就是我們的新機房部署平臺 SRE-Asteroid。

圖7：UCloud內(nèi)部機房部署平臺SRE-Asteroid

核心數(shù)據(jù)庫的部署和遷移

最后，是核心數(shù)據(jù)庫層面的部署和遷移工作如何進行。UCloud內(nèi)部服務(wù)所使用的數(shù)據(jù)庫服務(wù)為MySQL， 內(nèi)部MySQL集群采用物理機/虛擬機在管理網(wǎng)絡(luò)內(nèi)自行建設(shè)，以一個主庫、一個高可用從庫、兩個只讀從庫和一個備份庫的方式部署，使用MHA+VIP的方式解決主庫的高可用問題，使用BGP/ECMP+VIP的方式解決從庫的負載均衡和高可用問題，大體的架構(gòu)如圖8所示：

圖8：UCloud內(nèi)部MySQL服務(wù)架構(gòu)圖

首爾新老機房使用的內(nèi)部MySQL數(shù)據(jù)庫集群的架構(gòu)跟上圖類似，為了進行新老機房的集群切換，我們設(shè)計了如下的方案，如圖9所示：

圖9：首爾集群內(nèi)部數(shù)據(jù)庫集群遷移示意圖

整體來說，為了保證核心數(shù)據(jù)庫集群能夠穩(wěn)定完成遷移工作，我們拋棄了雙主庫、雙寫的切換方案，防止因為網(wǎng)絡(luò)或其他因素導(dǎo)致新老集群的數(shù)據(jù)不一致、同步異常等問題。我們采用了最簡單的解決方案，在業(yè)務(wù)低峰期停止console服務(wù)，直接修改數(shù)據(jù)庫中間層配置切換的方案。

在部署階段，我們在首爾新機房部署了相同高可用架構(gòu)的MySQL集群，老機房的數(shù)據(jù)庫邏輯備份導(dǎo)入，將新老機房的集群做成級聯(lián)模式（圖9中綠色虛線），新機房的主庫作為老機房的從庫，通過MySQL異步同步的方式（binlog）進行數(shù)據(jù)同步。我們使用pt-table-checksum工具，定期對兩個集群的數(shù)據(jù)一致性進行校驗，以保證新老機房的數(shù)據(jù)完全一致。與此同時使用內(nèi)部開發(fā)的拓撲分析工具，將所有調(diào)用老集群數(shù)據(jù)庫主從庫的業(yè)務(wù)情況確認清楚（主要是哪些udatabase集群）。

部署完成后，數(shù)據(jù)一致性和實時性通過級聯(lián)得到保障，udatabase仍然訪問老機房的MySQL主庫的VIP（圖9藍色虛線），此時并沒有業(yè)務(wù)通過直連的方式寫入新機房的主庫（為保證數(shù)據(jù)的一致性，新機房的主庫暫時設(shè)置成只讀模式）。

在確定遷移時間和遷移方案之后，在某個業(yè)務(wù)低峰期的時間點，公告用戶后，首爾機房整個console的操作停止一段時間（期間首爾機房的API請求可能會失?。?，在確定流量很低的前提下，通過修改數(shù)據(jù)庫中間層（udatabase cluster）中數(shù)據(jù)庫主從庫VIP的配置，將業(yè)務(wù)從老機房MySQL集群切換到新機房MySQL集群，此時該業(yè)務(wù)所有的請求都會流入到新集群（圖9紅色虛線）。為了防止老集群仍然有業(yè)務(wù)寫入或讀取，我們將老集群主庫設(shè)置為只讀，然后繼續(xù)通過tcpdump抓包分析老集群上可能存在的請求并手動處理，最終保證所有業(yè)務(wù)都使用新的MySQL集群。

由于需要對主機、網(wǎng)絡(luò)、存儲和監(jiān)控等幾個業(yè)務(wù)都進行集群切換，為保證不互相影響，使用逐個集群處理的方式，整體切換加檢測的時間耗時近1個小時。

在整個機房切換的過程中，只有數(shù)據(jù)庫集群是有狀態(tài)的業(yè)務(wù)，因此重要性和危險性也比較高，該服務(wù)切換完成后，最重要的一個環(huán)節(jié)也宣告完成，剩下的業(yè)務(wù)層面（UHost/UDB/EIP等）的遷移工作由各個業(yè)務(wù)團隊自行完成即可。

收尾

最終所有業(yè)務(wù)實例完成遷移后，理論上就可以完成本次機房遷移工作了，不過還是要對老機房仍然運行的實例進行流量監(jiān)測，確認沒有流量后進行下線，停止服務(wù)。最后對老機房的zookeeper集群（老機房的3個zookeeper節(jié)點）進行請求監(jiān)測和連接監(jiān)測，確認沒有本機房以及新機房發(fā)來的請求（排除zookeeper集群自主同步的情況），在完成確認后，進行最后的zookeeper集群變更，將整個集群（8個節(jié)點）拆分成老機房（3個節(jié)點）和新機房（5個節(jié)點），老機房的集群直接停止服務(wù)，而新機房的新的zookeeper集群完成新的選主操作，確認同步正常和服務(wù)正常。

寫在最后

經(jīng)歷了上文所述的一切操作后，整個首爾機房的遷移工作就完成了，整個項目歷經(jīng)5個月，其中大部分時間用于業(yè)務(wù)實例的遷移過程，主要是針對不同的用戶要確定不同的遷移策略和遷移時間；內(nèi)部管理服務(wù)的遷移和部署所花費的時間還是比較少的。UCloud內(nèi)部針對本次遷移的每一個步驟都制定了詳細的方案規(guī)劃，包括服務(wù)依賴分析、操作步驟、驗證方式、切換風險、回滾方案等，為了完成如此巨大的新機房熱遷移工作，團隊投入了充足的人力和時間。首爾新機房具有更好的建設(shè)規(guī)劃、硬件配置和軟件架構(gòu)，能夠為用戶提供更好的服務(wù)，我們相信這一切都是很有價值的。