背景
雲主機建立有兩種方式，一種通過映象**來建立，另一種通過快照回滾來建立， 前者是通用的傳統方式，後者依賴於cbs雲盤能力。 隨著cbs雲盤使用越來越廣泛，騰訊雲主機建立也由原來的映象**切換到cbs雲盤快照回滾模式。
通過傳統映象**的方式來建立雲主機，在雲主機拉起前，需要將整個映象檔案都**到宿主機上，所以雲主機的建立時間很大程度上依賴所選取的映象和當時**映象的頻寬。當遇到比較大的映象時，雲主機建立時間經常會達到幾百秒，這樣的使用者體驗不是太好；
另外，當批量建立時，需要消耗大量的內網頻寬資源，需要在盡量占用網路頻寬的同時做好qos，保證不影響使用者的正常使用。
使用雲盤快照回滾的方式來建立雲主機，不需要提前**映象，而是在雲主機拉起時，優先將要訪問的資料從快照系統搬遷到cbs雲盤系統中。
我們觀察到，雲主機拉起過程中訪問的資料量和映象大小並不是嚴格的線性關係，即便是較大的映象，在雲主機拉起時也只會訪問到很少一部分資料，搬遷流程如下：
圖1. 雲盤快照資料搬遷流程
當有快照回滾請求時，我們首先會在後台啟動乙個任務，將快照資料按順序從cos讀出寫入到儲存池中，同時我們不會阻礙使用者對回滾磁碟的正常讀寫。
當有使用者請求過來時（步驟1），會先在driver中檢查對應lba的快照資料是否已經被寫入，如果寫入則io直接下發（步驟7），否則，會阻塞io並先給scheduler傳送trigger請求（步驟3），scbhyxyojlztheduler會優先將trigger請求處理，交給搬遷模組將對應的快照資料從cos讀出，寫入到儲存池（步驟3、4、5），等寫入完畢後，scheduler先記錄搬遷bitmap到zk並給driver返回trigger
response和當前的快照資料回滾進度（步驟6），driver收到後則不再阻塞io， 讓其正常下發（步驟7）。
聚焦延遲和併發，雲主機建立優化之路
雲盤快照回滾優先搬遷關鍵資料這種機制為我們批量建立雲主機奠定了基礎，在此基礎上，我們還圍繞著延遲和併發這兩點做了一系列優化。
transfer增加cache
子機批量建立時，經常是使用同乙個映象轉殖出幾百或上千台子機，如果所有資料都從cos系統拉取，對cos的讀壓力會非常大，會觸發cos的qos流控。為了讓批量建立時讀取映象的流量不再受限於cos的頻寬，
我們在transfer中增加了cache，每個transfer中都快取映象的部分資料塊，一旦命中transfer的cach程式設計客棧e就不再從cos拉取資料，這樣每個transfer只需拉取一次映象；
當cache流量達到瓶頸時，可以通過臨時增加節點來增加頻寬，具備水平擴充套件能力。
在增加了cache後，我們對transfer部署也做了優化，每個zone都部署了若干個節點，當有資料塊搬遷請求時，任務總是會優先落到和cbs盤底層儲存節點相同zone的transfer上，這樣就可以實現就近搬遷。
通過cache優化，可以將單個資料塊的搬遷耗時從100+ms降低到10+ms， 大大降低了io延遲。
圖2. transfer cache
scheduler效能優化
在快照回滾建立雲主機過程中，核心處理邏輯在scheduler，因為client端每個io
trigger請求都要經過scheduler， 並且由於每個由trigger觸發的快照資料塊搬遷都要在zk裡記錄起來，
所以scheduler的負載以及zk寫入能力會直接影響到整個快照系統的吞吐。
首先，我們優化了scheduler，將請求接收、處理以及與後端互動部分的邏輯拆開來，形成流水線，儘量減少因某個請求處理慢導致其他請求排隊的情況， 每個部分都由乙個執行緒池來並行處理，盡量將整機的計算能力利用起來；
其次，針對zk寫入壓力大的問題，我們將寫入zk的資料做了分類，變化不頻繁的一些元資料還是寫入zk；
而記錄trigger搬遷狀態的那些元資料，需要頻繁修改，這部分資料不適合存zk，我們將其offload到乙個qps更高的儲存系統上，這樣一來，scheduler的處理能力得到了成倍的增長。
另外，為防止回滾的流量影響到其他使用者對磁碟的正常使用，我們在scheduler做了必要的qos。
首先限制落到同乙個副本組的回滾頻寬， 在整個副本組頻寬空閒時，回滾流量不能超過限制；
而當整個副本組的頻寬達到上限時，回滾頻寬會自動回退，優先保證使用者的正常io延遲。其次，當同時有順序搬遷任務和trigger請求任務時，優先處理trigger請求任務，保證使用者體驗。
最後，我們通過對scheduler改造bhyxyojlzt，做到水平可擴充套件， 使其不再成為效能瓶頸。
圖3. scheduler 拆分
買盤排程
當用快照回滾的方式批量建立雲主機時， 會將快照資料寫入新建立的所有cbs雲盤。
如果大量的雲盤落在同乙個副本組，則會造成這個副本www.cppcns.com組寫入流量過大，觸發前一節提到的副本組回滾頻寬限制。為避免這個問題，我們加入乙個排程系統，在批量購買雲盤時，從副本組剩餘容量、已建立的volume數、回滾頻寬、副本組寫入頻寬四個緯度綜合考量，把同一批次建立的cbs雲盤盡量打散到多個副本組。這樣一來，首先可以保證在建立時，單個副本組不會成為流量熱點；其次可以在一定程度上保證所有的副本組在建立時流量均衡，將整個儲存池的頻寬充分利用起來；最後，同一批次購買的cbs雲盤打散，可以將使用者因為某個副本組出故障受到的影響降到最低。
減少子機拉起時的資料量
前面主要從降低延遲和增大回滾頻寬角度去考慮如何優化，目的是讓後端系統能夠承載更大的回滾頻寬，提公升快照資料搬遷效率。如果在快照資料搬遷過程中，cbs雲盤有io訪問到還未搬遷的資料塊，就會產生乙個trigger請求，後台系統需要優先搬遷trigger請求對應位置的快照資料，這對scheduler會造成額外的負擔，所以如何減少子機拉起時產生的io
trigger，減少對後端系統的壓力，對雲主機併發建立很有意義。
對子機拉起過程進行分析，我們發現，在子機拉起過程中，檔案系統擴容和配置檔案修改都會在後端產生不少io
trigger。
檔案系統擴容一般發生在快照裡的檔案系統size小於要回滾的cbs雲盤size，在這種場景下，需要先將原檔案系統的元資料全部讀到記憶體中，修改後再寫入。像ext系列檔案系統的元資料是散落在每個塊組中的，所以讀元資料會變成隨機讀操作，幾乎每個隨機讀都會產生乙個trigger，觸發後端快照資料塊搬遷，而檔案系統的block大小遠小於快照粒度，這裡相當於發生了讀寫放大；
為此，我們通過修改檔案系統配置，讓所有元資料集中，這樣讀元資料就變成了順序讀寫，這樣就可以將請求合併，從而減少後端壓力。
經過優化後，檔案系統擴容時，後端io壓力可以降低到原來的五分之一，耗時降低到原來的四分之一。
其次，對於配置檔案修改，如果直接在原檔案上修改，既要讀寫檔案元資料，又要讀寫檔案資料，開銷比較大；所以改成bhyxyojlzt刪除+寫新檔案的方式，這樣不需要讀檔案資料，可以有效減少io。
總結：通過上述幾個層面的技術優化，目前，騰訊雲已經可以做到八千台子機併發建立，為客戶提供更好的服務體驗。後續，我們的優化還會一直進行下去，歡迎大家給我們提出寶貴意見。
本文標題: 支援八千台子機併發建立，詳解騰訊雲主機建立優化之路
本文位址:
一台機裝多個版本IE，支援WIN7
internet explorer 1.0 4.40.308 internet explorer 1.5 0.1.0.10 internet explorer 2.01 2.01.046 internet explorer 3.0 3.0.1152 internet explorer 3.01 3....