背景

云(yun)主機(ji)創(chuang)建(jian)(jian)有兩(liang)種(zhong)(zhong)方(fang)式，一種(zhong)(zhong)通過鏡像(xiang)下載(zai)來(lai)(lai)創(chuang)建(jian)(jian)，另一種(zhong)(zhong)通過快照回(hui)滾(gun)來(lai)(lai)創(chuang)建(jian)(jian)， 前者(zhe)是通用的傳統方(fang)式，后(hou)者(zhe)依(yi)賴于(yu)CBS云(yun)盤(pan)能力。 隨著(zhu)CBS云(yun)盤(pan)使用越(yue)來(lai)(lai)越(yue)廣泛，騰訊云(yun)主機(ji)創(chuang)建(jian)(jian)也由(you)原來(lai)(lai)的鏡像(xiang)下載(zai)切換(huan)到CBS云(yun)盤(pan)快照回(hui)滾(gun)模式。

通(tong)過傳統(tong)鏡(jing)像(xiang)下(xia)載的(de)(de)方式來創建(jian)云(yun)主機(ji)，在云(yun)主機(ji)拉起前，需要將(jiang)整個鏡(jing)像(xiang)文件(jian)都下(xia)載到宿主機(ji)上，所以云(yun)主機(ji)的(de)(de)創建(jian)時(shi)間很大程度上依(yi)賴所選取的(de)(de)鏡(jing)像(xiang)和(he)當時(shi)下(xia)載鏡(jing)像(xiang)的(de)(de)帶(dai)寬。當遇到比較大的(de)(de)鏡(jing)像(xiang)時(shi)，云(yun)主機(ji)創建(jian)時(shi)間經常會達到幾百(bai)秒，這樣的(de)(de)用(yong)戶(hu)體驗不是太(tai)好； 另外，當批量創建(jian)時(shi)，需要消耗大量的(de)(de)內網帶(dai)寬資源，需要在盡量占用(yong)網絡帶(dai)寬的(de)(de)同時(shi)做(zuo)好Qos，保證不影響(xiang)用(yong)戶(hu)的(de)(de)正常使用(yong)。

使(shi)用(yong)云(yun)(yun)盤快照回滾的方式來創建云(yun)(yun)主機(ji)(ji)，不需要提前(qian)下載鏡像(xiang)，而是在云(yun)(yun)主機(ji)(ji)拉起時(shi)，優(you)先將(jiang)要訪(fang)問(wen)的數(shu)(shu)據從快照系(xi)統搬(ban)遷到CBS云(yun)(yun)盤系(xi)統中(zhong)。 我們觀察到，云(yun)(yun)主機(ji)(ji)拉起過程中(zhong)訪(fang)問(wen)的數(shu)(shu)據量和鏡像(xiang)大小并不是嚴格的線性關系(xi)，即便(bian)是較(jiao)大的鏡像(xiang)，在云(yun)(yun)主機(ji)(ji)拉起時(shi)也(ye)只會訪(fang)問(wen)到很少一部分數(shu)(shu)據，搬(ban)遷流程如下：

圖(tu)1. 云盤快照數據搬遷(qian)流程

當(dang)有快照(zhao)(zhao)回滾(gun)請求時，我們(men)首先(xian)會(hui)在后臺啟動(dong)一個任務，將快照(zhao)(zhao)數(shu)(shu)據按順序從COS讀(du)(du)出寫入(ru)到(dao)存儲(chu)池(chi)(chi)中，同時我們(men)不(bu)會(hui)阻礙用戶對回滾(gun)磁(ci)盤的(de)正常(chang)(chang)讀(du)(du)寫。 當(dang)有用戶請求過來時（步(bu)(bu)(bu)驟1），會(hui)先(xian)在driver中檢查對應(ying)lba的(de)快照(zhao)(zhao)數(shu)(shu)據是否(fou)已經被寫入(ru)，如(ru)果寫入(ru)則IO直接下發（步(bu)(bu)(bu)驟7），否(fou)則，會(hui)阻塞(sai)IO并(bing)先(xian)給scheduler發送trigger請求（步(bu)(bu)(bu)驟3），scheduler會(hui)優先(xian)將trigger請求處理，交給搬遷(qian)模塊將對應(ying)的(de)快照(zhao)(zhao)數(shu)(shu)據從COS讀(du)(du)出，寫入(ru)到(dao)存儲(chu)池(chi)(chi)（步(bu)(bu)(bu)驟3、4、5），等寫入(ru)完(wan)畢后，scheduler先(xian)記錄(lu)搬遷(qian)bitmap到(dao)zk并(bing)給driver返(fan)回trigger response和當(dang)前的(de)快照(zhao)(zhao)數(shu)(shu)據回滾(gun)進度（步(bu)(bu)(bu)驟6），driver收到(dao)后則不(bu)再阻塞(sai)io， 讓(rang)其(qi)正常(chang)(chang)下發（步(bu)(bu)(bu)驟7）。

聚(ju)焦(jiao)延遲(chi)和并(bing)發，云主機創建(jian)優(you)化之(zhi)路(lu)

云(yun)盤快照回滾優先搬(ban)遷(qian)關鍵數據這種機制為我們(men)批量創(chuang)建云(yun)主機奠定了基(ji)礎(chu)(chu)，在此基(ji)礎(chu)(chu)上，我們(men)還圍繞著延(yan)遲和并發(fa)這兩點做了一系(xi)列優化。

transfer增加cache

子(zi)(zi)機批(pi)量(liang)創(chuang)建(jian)時，經常是使(shi)用同一(yi)個(ge)(ge)鏡像(xiang)克隆(long)出幾百或上千臺子(zi)(zi)機，如果所(suo)有數據(ju)都從(cong)COS系(xi)統拉取，對COS的(de)讀壓力會(hui)非常大，會(hui)觸發COS的(de)Qos流控。為了(le)讓(rang)批(pi)量(liang)創(chuang)建(jian)時讀取鏡像(xiang)的(de)流量(liang)不(bu)再受限于COS的(de)帶(dai)寬(kuan)(kuan)， 我們在(zai)transfer中(zhong)增(zeng)加(jia)了(le)cache，每個(ge)(ge)transfer中(zhong)都緩存鏡像(xiang)的(de)部分數據(ju)塊，一(yi)旦命中(zhong)transfer的(de)cache就不(bu)再從(cong)COS拉取數據(ju)，這(zhe)樣每個(ge)(ge)transfer只需拉取一(yi)次鏡像(xiang)； 當cache流量(liang)達到瓶頸時，可(ke)以通過臨(lin)時增(zeng)加(jia)節點來(lai)增(zeng)加(jia)帶(dai)寬(kuan)(kuan)，具備水平擴展(zhan)能力。

 在增(zeng)加了(le)cache后(hou)，我(wo)們對(dui)transfer部署也做了(le)優(you)(you)化(hua)，每個zone都部署了(le)若干個節(jie)點，當有數據(ju)塊(kuai)搬遷請求時，任務總是會(hui)優(you)(you)先(xian)落(luo)到和(he)CBS盤(pan)底層存儲節(jie)點相同zone的transfer上，這樣(yang)就可以(yi)實現就近搬遷。

通過cache優化，可以將單(dan)個數據塊(kuai)的搬(ban)遷(qian)耗時(shi)從100+ms降低(di)到10+ms， 大大降低(di)了(le)IO延遲。

圖2. transfer cache

scheduler性能優化(hua)

在快(kuai)照(zhao)回滾創建云主機過程中，核(he)心處(chu)理邏(luo)輯在scheduler，因為client端每(mei)(mei)個(ge)IO trigger請求(qiu)都要經(jing)過scheduler， 并且(qie)由于每(mei)(mei)個(ge)由trigger觸(chu)發的(de)快(kuai)照(zhao)數據塊(kuai)搬遷都要在zk里記(ji)錄(lu)起(qi)來， 所以scheduler的(de)負載以及zk寫(xie)入能力會直(zhi)接(jie)影響(xiang)到整個(ge)快(kuai)照(zhao)系統的(de)吞吐。

首(shou)先(xian)，我(wo)們優化(hua)了(le)scheduler，將請(qing)求(qiu)接收(shou)、處(chu)(chu)理(li)以及與后端(duan)交互部分(fen)的(de)邏輯(ji)拆(chai)開來(lai)，形成(cheng)流水線，盡量減少因某個(ge)(ge)請(qing)求(qiu)處(chu)(chu)理(li)慢導(dao)致(zhi)其他請(qing)求(qiu)排隊(dui)的(de)情(qing)況， 每(mei)個(ge)(ge)部分(fen)都由一個(ge)(ge)線程池來(lai)并行處(chu)(chu)理(li)，盡量將整機的(de)計算能力利用(yong)起來(lai)；

其(qi)次(ci)，針對zk寫入壓(ya)力(li)大的(de)(de)問題，我(wo)們將(jiang)寫入zk的(de)(de)數(shu)據(ju)做(zuo)了分類，變(bian)化不(bu)頻繁的(de)(de)一些(xie)元數(shu)據(ju)還是寫入zk； 而(er)記錄trigger搬遷狀態的(de)(de)那些(xie)元數(shu)據(ju)，需要(yao)頻繁修改，這部分數(shu)據(ju)不(bu)適合存(cun)zk，我(wo)們將(jiang)其(qi)offload到一個qps更高的(de)(de)存(cun)儲系(xi)統上，這樣一來(lai)，scheduler的(de)(de)處理能力(li)得到了成(cheng)倍(bei)的(de)(de)增長。

另外(wai)，為(wei)防止回(hui)(hui)(hui)滾(gun)(gun)的(de)(de)流(liu)量影響到其他用(yong)戶(hu)(hu)對磁盤的(de)(de)正(zheng)常(chang)使用(yong)，我們在(zai)scheduler做了必要的(de)(de)Qos。 首先限制(zhi)(zhi)落到同一個(ge)副(fu)本(ben)組(zu)(zu)的(de)(de)回(hui)(hui)(hui)滾(gun)(gun)帶(dai)寬， 在(zai)整個(ge)副(fu)本(ben)組(zu)(zu)帶(dai)寬空閑時，回(hui)(hui)(hui)滾(gun)(gun)流(liu)量不能超(chao)過限制(zhi)(zhi)； 而(er)當整個(ge)副(fu)本(ben)組(zu)(zu)的(de)(de)帶(dai)寬達到上(shang)限時，回(hui)(hui)(hui)滾(gun)(gun)帶(dai)寬會(hui)自動回(hui)(hui)(hui)退，優(you)先保(bao)證(zheng)用(yong)戶(hu)(hu)的(de)(de)正(zheng)常(chang)IO延遲。其次，當同時有順(shun)序搬遷(qian)任務和(he)trigger請求任務時，優(you)先處理trigger請求任務，保(bao)證(zheng)用(yong)戶(hu)(hu)體驗。

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

圖(tu)3. scheduler 拆分(fen)

買盤調度

當(dang)用(yong)(yong)快照回滾的(de)(de)方式(shi)批(pi)量創建(jian)(jian)云(yun)主機時(shi)， 會(hui)將(jiang)(jiang)(jiang)快照數據寫(xie)入新創建(jian)(jian)的(de)(de)所(suo)有CBS云(yun)盤。 如果大量的(de)(de)云(yun)盤落在(zai)同(tong)一(yi)(yi)(yi)個(ge)(ge)副(fu)(fu)(fu)(fu)本(ben)(ben)(ben)組(zu)(zu)，則會(hui)造成這個(ge)(ge)副(fu)(fu)(fu)(fu)本(ben)(ben)(ben)組(zu)(zu)寫(xie)入流(liu)量過大，觸發(fa)前(qian)一(yi)(yi)(yi)節提(ti)到的(de)(de)副(fu)(fu)(fu)(fu)本(ben)(ben)(ben)組(zu)(zu)回滾帶(dai)(dai)寬限制。為避免這個(ge)(ge)問題，我們(men)加入一(yi)(yi)(yi)個(ge)(ge)調度(du)系(xi)統，在(zai)批(pi)量購買云(yun)盤時(shi)，從副(fu)(fu)(fu)(fu)本(ben)(ben)(ben)組(zu)(zu)剩(sheng)余容量、已(yi)創建(jian)(jian)的(de)(de)volume數、回滾帶(dai)(dai)寬、副(fu)(fu)(fu)(fu)本(ben)(ben)(ben)組(zu)(zu)寫(xie)入帶(dai)(dai)寬四個(ge)(ge)緯(wei)度(du)綜合(he)考量，把同(tong)一(yi)(yi)(yi)批(pi)次創建(jian)(jian)的(de)(de)CBS云(yun)盤盡量打(da)散(san)到多個(ge)(ge)副(fu)(fu)(fu)(fu)本(ben)(ben)(ben)組(zu)(zu)。這樣一(yi)(yi)(yi)來(lai)，首先可以保證(zheng)在(zai)創建(jian)(jian)時(shi)，單個(ge)(ge)副(fu)(fu)(fu)(fu)本(ben)(ben)(ben)組(zu)(zu)不(bu)會(hui)成為流(liu)量熱點；其次可以在(zai)一(yi)(yi)(yi)定程度(du)上保證(zheng)所(suo)有的(de)(de)副(fu)(fu)(fu)(fu)本(ben)(ben)(ben)組(zu)(zu)在(zai)創建(jian)(jian)時(shi)流(liu)量均衡，將(jiang)(jiang)(jiang)整個(ge)(ge)存儲池的(de)(de)帶(dai)(dai)寬充分利用(yong)(yong)起來(lai)；最后，同(tong)一(yi)(yi)(yi)批(pi)次購買的(de)(de)CBS云(yun)盤打(da)散(san)，可以將(jiang)(jiang)(jiang)用(yong)(yong)戶因(yin)為某個(ge)(ge)副(fu)(fu)(fu)(fu)本(ben)(ben)(ben)組(zu)(zu)出(chu)故障受到的(de)(de)影響降到最低。

減少子機拉起(qi)時的數據量

前(qian)面主(zhu)要(yao)從降低延遲(chi)和增大回(hui)滾帶寬角度去考(kao)慮如何優化，目的(de)(de)是讓后端(duan)系統(tong)(tong)(tong)能夠(gou)承載更大的(de)(de)回(hui)滾帶寬，提(ti)升(sheng)快照數據搬遷(qian)效率。如果在快照數據搬遷(qian)過程中，CBS云(yun)盤(pan)有IO訪問到(dao)還(huan)未搬遷(qian)的(de)(de)數據塊，就會(hui)產生一個trigger請(qing)求(qiu)，后臺(tai)系統(tong)(tong)(tong)需要(yao)優先搬遷(qian)trigger請(qing)求(qiu)對(dui)應位置的(de)(de)快照數據，這對(dui)scheduler會(hui)造成額外的(de)(de)負擔(dan)，所以如何減(jian)少子機拉起(qi)時產生的(de)(de)IO trigger，減(jian)少對(dui)后端(duan)系統(tong)(tong)(tong)的(de)(de)壓力，對(dui)云(yun)主(zhu)機并發(fa)創建很有意義。

對子機拉起(qi)過程(cheng)(cheng)進行(xing)分析，我們(men)發(fa)現，在(zai)(zai)子機拉起(qi)過程(cheng)(cheng)中，文(wen)(wen)(wen)件(jian)(jian)系統(tong)擴(kuo)容和配置文(wen)(wen)(wen)件(jian)(jian)修(xiu)改都會(hui)在(zai)(zai)后(hou)端(duan)(duan)產(chan)生(sheng)(sheng)不少io trigger。 文(wen)(wen)(wen)件(jian)(jian)系統(tong)擴(kuo)容一(yi)(yi)般發(fa)生(sheng)(sheng)在(zai)(zai)快照里的(de)文(wen)(wen)(wen)件(jian)(jian)系統(tong)size小(xiao)于要回滾的(de)CBS云盤(pan)size，在(zai)(zai)這種場景下，需要先將原(yuan)文(wen)(wen)(wen)件(jian)(jian)系統(tong)的(de)元(yuan)數據(ju)全部讀到(dao)內存中，修(xiu)改后(hou)再寫入。像ext系列(lie)文(wen)(wen)(wen)件(jian)(jian)系統(tong)的(de)元(yuan)數據(ju)是散落在(zai)(zai)每個(ge)塊(kuai)組中的(de)，所以讀元(yuan)數據(ju)會(hui)變(bian)成隨(sui)機讀操作，幾(ji)乎每個(ge)隨(sui)機讀都會(hui)產(chan)生(sheng)(sheng)一(yi)(yi)個(ge)trigger，觸(chu)發(fa)后(hou)端(duan)(duan)快照數據(ju)塊(kuai)搬遷，而(er)文(wen)(wen)(wen)件(jian)(jian)系統(tong)的(de)block大(da)小(xiao)遠(yuan)小(xiao)于快照粒(li)度，這里相當于發(fa)生(sheng)(sheng)了讀寫放大(da)； 為此，我們(men)通過修(xiu)改文(wen)(wen)(wen)件(jian)(jian)系統(tong)配置，讓所有元(yuan)數據(ju)集中，這樣(yang)讀元(yuan)數據(ju)就變(bian)成了順序讀寫，這樣(yang)就可以將請求合并，從而(er)減少后(hou)端(duan)(duan)壓力(li)。 經(jing)過優化后(hou)，文(wen)(wen)(wen)件(jian)(jian)系統(tong)擴(kuo)容時，后(hou)端(duan)(duan)IO壓力(li)可以降低(di)到(dao)原(yuan)來的(de)五分之一(yi)(yi)，耗時降低(di)到(dao)原(yuan)來的(de)四分之一(yi)(yi)。

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

總(zong)結：

通過(guo)上述幾個層面的技(ji)術優(you)化(hua)，目前(qian)，騰(teng)訊云已經可以做到(dao)八千臺子機并發(fa)創建，為(wei)客戶提供更好(hao)的服(fu)務體驗(yan)。后(hou)續，我們的優(you)化(hua)還(huan)會一直進行下(xia)去，歡(huan)迎(ying)大家(jia)給我們提出寶貴意(yi)見。