背景

云主機(jī)創(chuàng)建有兩種方式，一種通過鏡像下載來創(chuàng)建，另一種通過快照回滾來創(chuàng)建， 前者是通用的傳統(tǒng)方式，后者依賴于CBS云盤能力。 隨著CBS云盤使用越來越廣泛，騰訊云主機(jī)創(chuàng)建也由原來的鏡像下載切換到CBS云盤快照回滾模式。

通過傳統(tǒng)鏡像下載的方式來創(chuàng)建云主機(jī)，在云主機(jī)拉起前，需要將整個(gè)鏡像文件都下載到宿主機(jī)上，所以云主機(jī)的創(chuàng)建時(shí)間很大程度上依賴所選取的鏡像和當(dāng)時(shí)下載鏡像的帶寬。當(dāng)遇到比較大的鏡像時(shí)，云主機(jī)創(chuàng)建時(shí)間經(jīng)常會(huì)達(dá)到幾百秒，這樣的用戶體驗(yàn)不是太好； 另外，當(dāng)批量創(chuàng)建時(shí)，需要消耗大量的內(nèi)網(wǎng)帶寬資源，需要在盡量占用網(wǎng)絡(luò)帶寬的同時(shí)做好Qos，保證不影響用戶的正常使用。

使用云盤快照回滾的方式來創(chuàng)建云主機(jī)，不需要提前下載鏡像，而是在云主機(jī)拉起時(shí)，優(yōu)先將要訪問的數(shù)據(jù)從快照系統(tǒng)搬遷到CBS云盤系統(tǒng)中。 我們觀察到，云主機(jī)拉起過程中訪問的數(shù)據(jù)量和鏡像大小并不是嚴(yán)格的線性關(guān)系，即便是較大的鏡像，在云主機(jī)拉起時(shí)也只會(huì)訪問到很少一部分?jǐn)?shù)據(jù)，搬遷流程如下：

圖1. 云盤快照數(shù)據(jù)搬遷流程

當(dāng)有快照回滾請(qǐng)求時(shí)，我們首先會(huì)在后臺(tái)啟動(dòng)一個(gè)任務(wù)，將快照數(shù)據(jù)按順序從COS讀出寫入到存儲(chǔ)池中，同時(shí)我們不會(huì)阻礙用戶對(duì)回滾磁盤的正常讀寫。 當(dāng)有用戶請(qǐng)求過來時(shí)（步驟1），會(huì)先在driver中檢查對(duì)應(yīng)lba的快照數(shù)據(jù)是否已經(jīng)被寫入，如果寫入則IO直接下發(fā)（步驟7），否則，會(huì)阻塞IO并先給scheduler發(fā)送trigger請(qǐng)求（步驟3），scheduler會(huì)優(yōu)先將trigger請(qǐng)求處理，交給搬遷模塊將對(duì)應(yīng)的快照數(shù)據(jù)從COS讀出，寫入到存儲(chǔ)池（步驟3、4、5），等寫入完畢后，scheduler先記錄搬遷bitmap到zk并給driver返回trigger response和當(dāng)前的快照數(shù)據(jù)回滾進(jìn)度（步驟6），driver收到后則不再阻塞io， 讓其正常下發(fā)（步驟7）。

聚焦延遲和并發(fā)，云主機(jī)創(chuàng)建優(yōu)化之路

云盤快照回滾優(yōu)先搬遷關(guān)鍵數(shù)據(jù)這種機(jī)制為我們批量創(chuàng)建云主機(jī)奠定了基礎(chǔ)，在此基礎(chǔ)上，我們還圍繞著延遲和并發(fā)這兩點(diǎn)做了一系列優(yōu)化。

transfer增加cache

子機(jī)批量創(chuàng)建時(shí)，經(jīng)常是使用同一個(gè)鏡像克隆出幾百或上千臺(tái)子機(jī)，如果所有數(shù)據(jù)都從COS系統(tǒng)拉取，對(duì)COS的讀壓力會(huì)非常大，會(huì)觸發(fā)COS的Qos流控。為了讓批量創(chuàng)建時(shí)讀取鏡像的流量不再受限于COS的帶寬， 我們?cè)趖ransfer中增加了cache，每個(gè)transfer中都緩存鏡像的部分?jǐn)?shù)據(jù)塊，一旦命中transfer的cache就不再?gòu)腃OS拉取數(shù)據(jù)，這樣每個(gè)transfer只需拉取一次鏡像； 當(dāng)cache流量達(dá)到瓶頸時(shí)，可以通過臨時(shí)增加節(jié)點(diǎn)來增加帶寬，具備水平擴(kuò)展能力。

在增加了cache后，我們對(duì)transfer部署也做了優(yōu)化，每個(gè)zone都部署了若干個(gè)節(jié)點(diǎn)，當(dāng)有數(shù)據(jù)塊搬遷請(qǐng)求時(shí)，任務(wù)總是會(huì)優(yōu)先落到和CBS盤底層存儲(chǔ)節(jié)點(diǎn)相同zone的transfer上，這樣就可以實(shí)現(xiàn)就近搬遷。

通過cache優(yōu)化，可以將單個(gè)數(shù)據(jù)塊的搬遷耗時(shí)從100+ms降低到10+ms， 大大降低了IO延遲。

圖2. transfer cache

scheduler性能優(yōu)化

在快照回滾創(chuàng)建云主機(jī)過程中，核心處理邏輯在scheduler，因?yàn)閏lient端每個(gè)IO trigger請(qǐng)求都要經(jīng)過scheduler， 并且由于每個(gè)由trigger觸發(fā)的快照數(shù)據(jù)塊搬遷都要在zk里記錄起來， 所以scheduler的負(fù)載以及zk寫入能力會(huì)直接影響到整個(gè)快照系統(tǒng)的吞吐。

首先，我們優(yōu)化了scheduler，將請(qǐng)求接收、處理以及與后端交互部分的邏輯拆開來，形成流水線，盡量減少因某個(gè)請(qǐng)求處理慢導(dǎo)致其他請(qǐng)求排隊(duì)的情況， 每個(gè)部分都由一個(gè)線程池來并行處理，盡量將整機(jī)的計(jì)算能力利用起來；

其次，針對(duì)zk寫入壓力大的問題，我們將寫入zk的數(shù)據(jù)做了分類，變化不頻繁的一些元數(shù)據(jù)還是寫入zk； 而記錄trigger搬遷狀態(tài)的那些元數(shù)據(jù)，需要頻繁修改，這部分?jǐn)?shù)據(jù)不適合存zk，我們將其offload到一個(gè)qps更高的存儲(chǔ)系統(tǒng)上，這樣一來，scheduler的處理能力得到了成倍的增長(zhǎng)。

另外，為防止回滾的流量影響到其他用戶對(duì)磁盤的正常使用，我們?cè)趕cheduler做了必要的Qos。 首先限制落到同一個(gè)副本組的回滾帶寬， 在整個(gè)副本組帶寬空閑時(shí)，回滾流量不能超過限制； 而當(dāng)整個(gè)副本組的帶寬達(dá)到上限時(shí)，回滾帶寬會(huì)自動(dòng)回退，優(yōu)先保證用戶的正常IO延遲。其次，當(dāng)同時(shí)有順序搬遷任務(wù)和trigger請(qǐng)求任務(wù)時(shí)，優(yōu)先處理trigger請(qǐng)求任務(wù)，保證用戶體驗(yàn)。

最后，我們通過對(duì)scheduler改造，做到水平可擴(kuò)展， 使其不再成為性能瓶頸。

圖3. scheduler 拆分

買盤調(diào)度

當(dāng)用快照回滾的方式批量創(chuàng)建云主機(jī)時(shí)， 會(huì)將快照數(shù)據(jù)寫入新創(chuàng)建的所有CBS云盤。 如果大量的云盤落在同一個(gè)副本組，則會(huì)造成這個(gè)副本組寫入流量過大，觸發(fā)前一節(jié)提到的副本組回滾帶寬限制。為避免這個(gè)問題，我們加入一個(gè)調(diào)度系統(tǒng)，在批量購(gòu)買云盤時(shí)，從副本組剩余容量、已創(chuàng)建的volume數(shù)、回滾帶寬、副本組寫入帶寬四個(gè)緯度綜合考量，把同一批次創(chuàng)建的CBS云盤盡量打散到多個(gè)副本組。這樣一來，首先可以保證在創(chuàng)建時(shí)，單個(gè)副本組不會(huì)成為流量熱點(diǎn)；其次可以在一定程度上保證所有的副本組在創(chuàng)建時(shí)流量均衡，將整個(gè)存儲(chǔ)池的帶寬充分利用起來；最后，同一批次購(gòu)買的CBS云盤打散，可以將用戶因?yàn)槟硞�(gè)副本組出故障受到的影響降到最低。

減少子機(jī)拉起時(shí)的數(shù)據(jù)量

前面主要從降低延遲和增大回滾帶寬角度去考慮如何優(yōu)化，目的是讓后端系統(tǒng)能夠承載更大的回滾帶寬，提升快照數(shù)據(jù)搬遷效率。如果在快照數(shù)據(jù)搬遷過程中，CBS云盤有IO訪問到還未搬遷的數(shù)據(jù)塊，就會(huì)產(chǎn)生一個(gè)trigger請(qǐng)求，后臺(tái)系統(tǒng)需要優(yōu)先搬遷trigger請(qǐng)求對(duì)應(yīng)位置的快照數(shù)據(jù)，這對(duì)scheduler會(huì)造成額外的負(fù)擔(dān)，所以如何減少子機(jī)拉起時(shí)產(chǎn)生的IO trigger，減少對(duì)后端系統(tǒng)的壓力，對(duì)云主機(jī)并發(fā)創(chuàng)建很有意義。

對(duì)子機(jī)拉起過程進(jìn)行分析，我們發(fā)現(xiàn)，在子機(jī)拉起過程中，文件系統(tǒng)擴(kuò)容和配置文件修改都會(huì)在后端產(chǎn)生不少io trigger。 文件系統(tǒng)擴(kuò)容一般發(fā)生在快照里的文件系統(tǒng)size小于要回滾的CBS云盤size，在這種場(chǎng)景下，需要先將原文件系統(tǒng)的元數(shù)據(jù)全部讀到內(nèi)存中，修改后再寫入。像ext系列文件系統(tǒng)的元數(shù)據(jù)是散落在每個(gè)塊組中的，所以讀元數(shù)據(jù)會(huì)變成隨機(jī)讀操作，幾乎每個(gè)隨機(jī)讀都會(huì)產(chǎn)生一個(gè)trigger，觸發(fā)后端快照數(shù)據(jù)塊搬遷，而文件系統(tǒng)的block大小遠(yuǎn)小于快照粒度，這里相當(dāng)于發(fā)生了讀寫放大； 為此，我們通過修改文件系統(tǒng)配置，讓所有元數(shù)據(jù)集中，這樣讀元數(shù)據(jù)就變成了順序讀寫，這樣就可以將請(qǐng)求合并，從而減少后端壓力。 經(jīng)過優(yōu)化后，文件系統(tǒng)擴(kuò)容時(shí)，后端IO壓力可以降低到原來的五分之一，耗時(shí)降低到原來的四分之一。

其次，對(duì)于配置文件修改，如果直接在原文件上修改，既要讀寫文件元數(shù)據(jù)，又要讀寫文件數(shù)據(jù)，開銷比較大；所以改成刪除+寫新文件的方式，這樣不需要讀文件數(shù)據(jù)，可以有效減少IO。

總結(jié)：

通過上述幾個(gè)層面的技術(shù)優(yōu)化，目前，騰訊云已經(jīng)可以做到八千臺(tái)子機(jī)并發(fā)創(chuàng)建，為客戶提供更好的服務(wù)體驗(yàn)。后續(xù)，我們的優(yōu)化還會(huì)一直進(jìn)行下去，歡迎大家給我們提出寶貴意見。

標(biāo)簽： 騰訊云主機(jī) 服務(wù)器優(yōu)化 騰訊云 

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請(qǐng)聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點(diǎn)！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請(qǐng)與原作者聯(lián)系。