域名預(yù)訂/競(jìng)價(jià)，好“米”不錯(cuò)過(guò)

作者：UCloud 趙新宇

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

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

計(jì)劃

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

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

挑戰(zhàn)

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

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

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

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

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

ZooKeeper服務(wù)的擴(kuò)縮容

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

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

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

首爾老機(jī)房的ZooKeeper集群是一個(gè)具有3個(gè)節(jié)點(diǎn)的普通集群(當(dāng)時(shí)規(guī)模相對(duì)較小，3個(gè)節(jié)點(diǎn)足夠)。 然而首爾新機(jī)房的規(guī)模要大很多，因此新機(jī)房ZooKeeper的集群規(guī)模也要擴(kuò)充，經(jīng)過(guò)我們的評(píng)估，將新機(jī)房的ZooKeeper集群擴(kuò)充到5個(gè)節(jié)點(diǎn)，基本上可以滿足所需。

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

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

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

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

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

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

而對(duì)于新機(jī)房新部署的需要注冊(cè)的服務(wù)來(lái)說(shuō)，他們的配置文件中對(duì)于ZooKeeper地址的配置，卻不是新建的8個(gè)IP的列表，而是只配置新機(jī)房5個(gè)IP的列表。這樣新老機(jī)房的后端服務(wù)使用同一套ZooKeeper，但是配置的卻是不同的IP，這樣做的目的，是為了后續(xù)老機(jī)房下線裁撤時(shí)，所有新機(jī)房的服務(wù)不需要因?yàn)閆ooKeeper集群的縮容而重啟更新配置，只要將集群中老機(jī)房所在的3個(gè)節(jié)點(diǎn)下線，剩余5個(gè)節(jié)點(diǎn)的配置更新重新選主即可。

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

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

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

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

新建集群灰度遷移模式

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

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

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

機(jī)房部署平臺(tái)SRE-Asteroid

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

圖7 UCloud內(nèi)部機(jī)房部署平臺(tái)SRE-Asteroid

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

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

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

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

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

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

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

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

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

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

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

收尾

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

寫(xiě)在最后

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

申請(qǐng)創(chuàng)業(yè)報(bào)道，分享創(chuàng)業(yè)好點(diǎn)子。點(diǎn)擊此處，共同探討創(chuàng)業(yè)新機(jī)遇！