在數(shù)字化業(yè)務實踐中，某些客有些用戶的業(yè)務場景需要在短時間內能夠批量創(chuàng)建大量的云主機，這些典型業(yè)務場景包括：
1.芯片設計，由于單機無法滿足高計算需求，需要上百臺云主機完成眾多job的計算;
2.3D渲染，基礎鏡像大且需要大量云主機滿足不同渲染需求;
3.搶購類業(yè)務，需要大量云主機并發(fā)以提高搶購效率。創(chuàng)建云主機的速度關系到這些客戶的核心體驗。
在創(chuàng)建云主機過程中，最耗時的操作為克隆虛擬機鏡像這一步驟，需要將虛擬機鏡像從鏡像源復制一份到云盤集群。虛擬機鏡像包含虛擬機上的操作系統(tǒng)及用戶預裝的軟件，一個完整的鏡像數(shù)據(jù)量非常大，從幾GB到幾十GB不等，在實踐中，甚至有的鏡像數(shù)據(jù)達到幾百GB。創(chuàng)建N臺云主機意味著將鏡像數(shù)據(jù)復制分發(fā)N份，而且大部分公有云存儲都采用三副本技術進行數(shù)據(jù)冗余，這意味著復制分發(fā)的數(shù)據(jù)量還要放大三倍。因此，在大批量創(chuàng)建云主機場景下，復制分發(fā)海量數(shù)據(jù)需要用戶等待大量時間，這個時間往往是用戶業(yè)務無法接受的。
為了緩解用戶批量創(chuàng)建云盤主機耗時過長的問題，我們采用過鏡像預灌作為過渡方案，即提前為用戶克隆好系統(tǒng)盤鏡像。該方案存在明顯缺陷，不僅需要提前知曉客戶的熱門鏡像，超額預灌也會額外占用后端存儲資源。為了從根本上解決批量創(chuàng)建云盤主機耗時過長問題，我們設計了基于ROW(Redirect-On-Write)的克隆/快照技術，實現(xiàn)了寫時重定向的鏈式克隆，達到了秒級克隆的效果。
一、快照克隆技術選型
COW(Copy-On-Write)，也被稱之寫時復制快照技術，這種方式通常也被稱為“元數(shù)據(jù)(源數(shù)據(jù)指針表)”拷貝。顧名思義，如果試圖改寫源數(shù)據(jù)塊上的原始數(shù)據(jù)，首先要將原始數(shù)據(jù)拷貝到新數(shù)據(jù)塊中，然后再進行改寫。當還原快照需要引用原始數(shù)據(jù)時，快照軟件會將原始數(shù)據(jù)原有的指針映射到新數(shù)據(jù)塊上。
ROW(Redirect-On-Write)，也被稱之為寫時重定向。ROW的實現(xiàn)原理與COW非常相似，區(qū)別在于ROW對原始數(shù)據(jù)卷的首次寫操作，會將新數(shù)據(jù)重定向到預留的快照卷中，而非COW一般會使用新數(shù)據(jù)將原始數(shù)據(jù)覆蓋。所以，ROW快照中的原始數(shù)據(jù)依舊保留在源數(shù)據(jù)卷中，并且為了保證快照數(shù)據(jù)的完整性，在創(chuàng)建快照時，源數(shù)據(jù)卷狀態(tài)會由讀寫變成只讀的。如果對一個虛擬機做了多次快照，就產(chǎn)生了一個快照鏈，虛擬機的磁盤卷始終掛載在快照鏈的最末端，即虛擬機的寫操作全都會落盤到最末端的快照卷中。
該特征導致了一個問題，就是如果一共做了10次快照，那么在恢復到最新的快照點時，則需要通過合并10個快照卷來得到一個完整的最新快照點數(shù)據(jù);如果是恢復到第8次快照時間點，那么就需要將前8次的快照卷合并成為一個完整的快照點數(shù)據(jù)。從這里可以看出ROW的主要缺點是沒有一個完整的快照卷，其快照之間的關系是鏈式的，如果快照層級越多，進行快照恢復時的系統(tǒng)開銷會比較大。但ROW的優(yōu)勢在于其解決了COW快照寫兩次的問題，所以就寫性能而言，ROW無疑是優(yōu)于COW的。
可以看出，ROW與COW最大的不同就是：COW的快照卷存放的是原始數(shù)據(jù)，而ROW的快照卷存放的是新數(shù)據(jù)。因為ROW這種設定，所以其多個快照之間的關系必定是鏈式的，因為最新一次快照的原始數(shù)據(jù)很可能就存放在了上一次快照時創(chuàng)建的快照卷中。另外，對于分布式系統(tǒng)來說，由于數(shù)據(jù)分散分布在不同存儲節(jié)點上，進而提供了并發(fā)讀的機會，因此，在分布式存儲系統(tǒng)中，ROW的讀寫性能優(yōu)于COW。
鑒于ROW與COW的對比優(yōu)勢，以及UDisk自身分布式部署特點，我們最終采用基于ROW的方式實現(xiàn)內部快照，并對UDisk的整體架構進行改進優(yōu)化。為了降低批量創(chuàng)建云盤主機時對鏡像存儲集群的壓力，引入Frigga模塊，管理UDisk內部鏡像，期望相同鏡像只從鏡像存儲集群拷貝一次，UDisk集群內部共享。
二、方案整體架構設計
Access：UDisk接入服務，接收外部請求，并下發(fā)請求到相應存儲集群中
Frigga：鏡像分發(fā)管理模塊，管理從鏡像系統(tǒng)克隆的鏡像。全局部署，采用主備模式，對于鏡像集群中存儲鏡像的云盤提供新建、查詢等功能;
Metaserver：UDisk存儲集群元數(shù)據(jù)管理模塊，存儲管理集群快照克隆的鏈式關系和集群的路由信息;
Chunk：UDisk存儲集群后端數(shù)據(jù)存儲引擎，負責數(shù)據(jù)的實際讀寫
Client：客戶端服務，UDisk存儲接入模塊，部署在宿主機上，負責虛機io下發(fā)到后端存儲集群
Ymer：負責從鏡像系統(tǒng)拷貝鏡像到UDisk存儲集群
鏡像集群：特殊的UDisk存儲集群，作為鏡像系統(tǒng)Cache，后端部署與普通集群一致。該集群只存儲基礎鏡像數(shù)據(jù)和克隆云盤數(shù)據(jù)，客戶批量創(chuàng)建云盤主機創(chuàng)建的云盤系統(tǒng)盤都會落在該集群中，后期通過遷移系統(tǒng)在線將云盤系統(tǒng)盤打散遷移到UDisk存儲集群中，遷移過程用戶無感知。該集群作為基礎鏡像緩存池，由Frigga模塊采用LRU策略淘汰冷鏡像數(shù)據(jù)，只存儲用戶的高頻熱點鏡像。
系統(tǒng)盤克隆整體流程
云主機服務下發(fā)系統(tǒng)盤克隆請求到Access接入服務，Access根據(jù)請求中的鏡像ID向Frigga查詢當前鏡像是否已存在后端鏡像集群。
若存在，則響應Access鏡像存在，同時返回鏡像對應云盤ID，Access根據(jù)云盤ID重新組織克隆請求，下發(fā)到鏡像集群Metaserver服務，Metaserver接收請求執(zhí)行內部克隆，更新克隆盤與鏡像盤對應關系，并將關系信息同步給集群內所有Chunk服務，通知完成后向上層返回，克隆流程結束(上圖綠色線+黑色線部分)。整個過程不涉及與鏡像系統(tǒng)的交互，無數(shù)據(jù)拷貝，純內存操作，毫秒級時間內完成。
當請求的鏡像不存在時，F(xiàn)rigga本地內存新增鏡像記錄，并持久化DB。然后響應Access鏡像不存在，需要從鏡像系統(tǒng)克隆鏡像。Access接收響應后，向Metaserver下發(fā)從鏡像系統(tǒng)克隆請求，Metaserver創(chuàng)建鏡像云盤并通知Ymer從鏡像系統(tǒng)拷貝鏡像數(shù)據(jù)，通知成功后，向上層Access返回已開始克隆，Access接收到響應后再次向Metaserver下發(fā)從鏡像云盤的內部克隆請求，流程同上(上圖紅色線+黑色線部分)。不過此時鏡像尚未克隆完成，F(xiàn)rigga會不斷查詢鏡像云盤狀態(tài)，直到數(shù)據(jù)拷貝完成，此時系統(tǒng)盤可用。相較上面流程，多了一次從鏡像系統(tǒng)拷貝數(shù)據(jù)的過程，但也只需要一次拷貝，降低了對鏡像系統(tǒng)的負載壓力。
UDisk整體架構如何適配是核心問題，幾乎涉及到UDisk所有模塊的改動，下文將詳細介紹如何基于ROW實現(xiàn)內部快照/克隆的技術細節(jié)。
三、快照/克隆云盤實現(xiàn)原理
為了便于理解，先介紹幾個基本概念：1.UDisk提供塊存儲服務，對外可見的為一個個裸設備(云盤，也稱為邏輯盤，lc)，每塊云盤對應一個全局唯一標識extern_id，每個extern_id會被分配到后端某個存儲集群，且在后端集群中為extern_id分配唯一id，即lc_id;2.每個Chunk服務管理一塊物理磁盤，底層以PC(4MB)為粒度管理整個物理磁盤的容量，并提供IO讀寫服務。
extern_id：云盤資源id，全局唯一
lc：邏輯盤，即云盤
lc_id:云盤在后端存儲集群內id，存儲集群內唯一
PC：邏輯存儲單元
Frigga鏡像管理
Frigga設計為主備模式，提高系統(tǒng)可用性。Frigga負責鏡像的導入，后端存儲集群鏡像管理以及克隆調度。與Ymer配合實現(xiàn)UDisk存儲集群間鏡像共享，從鏡像系統(tǒng)拷貝一次鏡像，UDisk存儲集群內數(shù)據(jù)共享，大大減輕鏡像系統(tǒng)負載。Frigga根據(jù)LRU策略管理本地鏡像，防止無效鏡像/冷鏡像占用存儲資源，當鏡像集群使用容量達到設定閾值時，根據(jù)LRU策略淘汰冷鏡像。
當鏡像集群容量到達使用閾值后，會根據(jù)LRU策略主動刪除長時間未使用鏡像。為防止單鏡像集群內從單一鏡像克隆過多云盤引起的訪問熱點問題，F(xiàn)rigga為每個鏡像集群內的鏡像設置單鏡像最大支持克隆盤數(shù)量閾值，當克隆盤數(shù)量超過設定閾值后，會重新從鏡像系統(tǒng)重新拷貝鏡像。
Metaserver元數(shù)據(jù)以及路由管理
UDisk原有架構設計中邏輯盤之間相互獨立，無相互關聯(lián)。為了實現(xiàn)UDisk存儲集群內部鏡像共享(鏡像在鏡像集群中也以邏輯盤存在)，以邏輯盤lc粒度管理鏡像/快照/克隆盤關系，通過維護邏輯盤之間的關系實現(xiàn)快照的創(chuàng)建/克隆等操作，邏輯盤間的對應關系由Metaserver統(tǒng)一管理，并同步給Chunk以及Client服務。對盤多次打快照后，從不同快照克隆云盤后，Metaserver側維護的邏輯盤之間的拓撲結構如下圖所示：
從同一鏡像批量克隆出多塊克隆盤后，邏輯盤之間的拓撲結構如下，所有克隆盤均指向鏡像云盤，只需要鏡像盤從鏡像系統(tǒng)拷貝一次，其他克隆盤的創(chuàng)建均為內存操作，Metaserver只需維護克隆盤到鏡像之間的映射關系即可，這樣極大提高了系統(tǒng)盤的克隆速度。
邏輯盤間的關系在Metaserver內存中都是一條條的鏈，鏈上的各邏輯盤都依賴其上層節(jié)點，從鏈的末尾節(jié)點可依次向上層查詢直到根節(jié)點。Metaserver會將邏輯盤之間的映射關系信息實時同步給Client以及Chunk服務，Client和Chunk服務與Metaserver之間也保持心跳消息，通過心跳主動同步邏輯盤映射關系信息，防止網(wǎng)絡分區(qū)導致的信息不一致。Metaserver通過version機制管理映射關系變化，通過比對Metaserver與Client/Chunk的version確定是否需要同步最新映射關系。
按照UDisk分布式設計原則，鏡像數(shù)據(jù)被分散存儲在鏡像集群不同物理主機上，按原有路由策略，克隆盤讀取鏡像數(shù)據(jù)時，可能會存在跨機器訪問的問題，增加數(shù)據(jù)讀取時延，影響云主機啟動速度。為此，我們優(yōu)化了路由策略：克隆盤和鏡像擁有相同的路由信息，克隆盤和鏡像數(shù)據(jù)由相同的Chunk服務管理。這樣，當云主機啟動加載系統(tǒng)盤數(shù)據(jù)時，可以直接讀取對應Chunk上的鏡像數(shù)據(jù)，本地讀操作，減少網(wǎng)絡訪問時延。
Client IO下發(fā)
Client作為UDisk存儲集群的接入服務，負責將虛機的IO下發(fā)到存儲集群不同的Chunk服務上，為了保證將克隆盤的IO下發(fā)到對應鏡像所在Chunk服務上，Client側需要獲取對應克隆盤的所有映射關系，從而獲取到鏡像信息，以鏡像的路由策略下發(fā)IO。
Chunk側IO讀/寫流程優(yōu)化
Chunk以PC為粒度管理磁盤，并處理IO，只有寫IO時Chunk才可能分配新PC。Chunk除了從Metaserver同步邏輯盤之間的映射關系外，還維護自身管理的PC信息。對lc多次做快照后，Chunk維護的PC間拓撲結構如下圖：
從同一鏡像克隆出多塊盤后，Chunk維護的PC間拓撲結構如下：
Chunk接收Client IO按照PC讀寫磁盤，每個PC對應一個pcmeta元數(shù)據(jù)，該元數(shù)據(jù)記錄了PC云盤與物理盤的映射關系，其中重定向標記位(bitmap)表示該數(shù)據(jù)是否需要從父節(jié)點讀取數(shù)據(jù);每個標記位代表256k數(shù)據(jù)重定向結果，對于新建的克隆盤PC初始化時所有的bitmap都是1，表示每個256k都需要重定向讀寫。Client下發(fā)的IO可以由一個四元組PC Entry(lc_id, pc_no, offset, length)表示，代表要讀寫的邏輯盤、讀寫位置所屬PC、PC內位置、讀寫大小以及數(shù)據(jù)。
讀io重定向
對于讀請求，首先根據(jù)四元組PC Entry確認PC是否存在，若存在，再根據(jù)pcmeta中bitmap對應位是否為1確認是否需要重定向讀，bitmap為0說明讀取的數(shù)據(jù)在當前PC上，直接讀取數(shù)據(jù)即可。發(fā)現(xiàn)對應的bitmap為1就尋找父節(jié)點繼續(xù)判斷標記位，直到父節(jié)點的標記位為0表示不需要重定向直接讀取父節(jié)點PC對應位置的數(shù)據(jù)。
寫io重定向
對于寫io判斷首先判斷PC是否存在，如果克隆的PC存在，再判斷bitmap是否為1(需要重定向)，如果為1就會找父節(jié)點對應的PC，先將父節(jié)點對應PC的256k數(shù)據(jù)讀取出來，再與當前寫io數(shù)據(jù)做合并，再寫入對應的磁盤。如果克隆的PC不存在，則先創(chuàng)建PC，創(chuàng)建PC的pcmeta中bitmap設置為1，再按照之前PC存在的流程同樣處理io。
四、總結
為了能夠達到秒級克隆的效果，達到短時間創(chuàng)建大批量虛機的需求，我們采用了ROW的方法，同時利用了鏡像緩存池作為熱點鏡像數(shù)據(jù)，提高了基礎鏡像克隆與內部克隆的速度與效率，能夠達到5min內批量創(chuàng)建1000以上虛機的要求。
目前，該方案已在海外洛杉磯、新加坡機房全量開放，國內上海、廣州、北京、香港等機房已針對特定客戶開放。主要目標客戶為短時間內有批量創(chuàng)建虛機需求或者大容量基礎鏡像的客戶，可以大大縮短用戶創(chuàng)建虛機時間。目前，可支撐用戶業(yè)務高峰期批量2500臺虛機的創(chuàng)建需求。
