在數字化業務實踐中，有些使用者的業務場景需要在短時間内能夠批量建立大量的雲主機，這些典型業務場景包括：
1. 晶片設計，由于單機無法滿足高計算需求，需要上百台雲主機完成衆多job的計算；
2. 3D渲染，基礎鏡像大且需要大量雲主機滿足不同渲染需求；
3. 搶購類業務，需要大量雲主機并發以提高搶購效率。建立雲主機的速度關系到這些客戶的核心體驗。
在建立雲主機過程中，最耗時的操作為克隆虛拟機鏡像這一步驟，需要将虛拟機鏡像從鏡像源複制一份到雲盤叢集。虛拟機鏡像包含虛拟機上的作業系統及使用者預裝的軟體，一個完整的鏡像資料量非常大，從幾GB到幾十GB不等，在實踐中，甚至有的鏡像資料達到幾百GB。建立N台雲主機意味着将鏡像資料複制分發N份，而且大部分公有雲存儲都采用三副本技術進行資料備援，這意味着複制分發的資料量還要放大三倍。是以，在大批量建立雲主機場景下，複制分發海量資料需要使用者等待大量時間，這個時間往往是使用者業務無法接受的。
為了緩解使用者批量建立雲盤主機耗時過長的問題，我們采用過鏡像預灌作為過渡方案，即提前為使用者克隆好系統盤鏡像。該方案存在明顯缺陷，不僅需要提前知曉客戶的熱門鏡像，超額預灌也會額外占用後端存儲資源。為了從根本上解決批量建立雲盤主機耗時過長問題，我們設計了基于ROW（Redirect-On-Write）的克隆/快照技術，實作了寫時重定向的鍊式克隆，達到了秒級克隆的效果。
一、快照克隆技術選型
COW(Copy-On-Write)，也被稱之寫時複制快照技術，這種方式通常也被稱為“中繼資料(源資料指針表)”拷貝。顧名思義，如果試圖改寫源資料塊上的原始資料，首先要将原始資料拷貝到新資料塊中，然後再進行改寫。當還原快照需要引用原始資料時，快照軟體會将原始資料原有的指針映射到新資料塊上。
ROW(Redirect-On-Write)，也被稱之為寫時重定向。ROW的實作原理與COW非常相似，差別在于ROW對原始資料卷的首次寫操作，會将新資料重定向到預留的快照卷中，而非COW一般會使用新資料将原始資料覆寫。是以，ROW快照中的原始資料依舊保留在源資料卷中，并且為了保證快照資料的完整性，在建立快照時，源資料卷狀态會由讀寫變成隻讀的。如果對一個虛拟機做了多次快照，就産生了一個快照鍊，虛拟機的磁盤卷始終挂載在快照鍊的最末端，即虛拟機的寫操作全都會落盤到最末端的快照卷中。
該特征導緻了一個問題，就是如果一共做了10次快照，那麼在恢複到最新的快照點時，則需要通過合并10個快照卷來得到一個完整的最新快照點資料；如果是恢複到第8次快照時間點，那麼就需要将前8次的快照卷合并成為一個完整的快照點資料。從這裡可以看出ROW的主要缺點是沒有一個完整的快照卷，其快照之間的關系是鍊式的，如果快照層級越多，進行快照恢複時的系統開銷會比較大。但ROW的優勢在于其解決了COW快照寫兩次的問題，是以就寫性能而言，ROW無疑是優于COW的。
可以看出，ROW與COW最大的不同就是：COW的快照卷存放的是原始資料，而ROW的快照卷存放的是新資料。因為ROW這種設定，是以其多個快照之間的關系必定是鍊式的，因為最新一次快照的原始資料很可能就存放在了上一次快照時建立的快照卷中。另外，對于分布式系統來說，由于資料分散分布在不同存儲節點上，進而提供了并發讀的機會，是以，在分布式存儲系統中，ROW的讀寫性能優于COW。
鑒于ROW與COW的對比優勢，以及UDisk自身分布式部署特點，我們最終采用基于ROW的方式實作内部快照，并對UDisk的整體架構進行改進優化。為了降低批量建立雲盤主機時對鏡像存儲叢集的壓力，引入Frigga子產品，管理UDisk内部鏡像，期望相同鏡像隻從鏡像存儲叢集拷貝一次，UDisk叢集内部共享。
二、方案整體架構設計
Access：UDisk接入服務，接收外部請求，并下發請求到相應存儲叢集中
Frigga：鏡像分發管理子產品，管理從鏡像系統克隆的鏡像。全局部署，采用主備模式，對于鏡像叢集中存儲鏡像的雲盤提供建立、查詢等功能；
Metaserver：UDisk存儲叢集中繼資料管理子產品，存儲管理叢集快照克隆的鍊式關系和叢集的路由資訊；
Chunk：UDisk存儲叢集後端資料存儲引擎，負責資料的實際讀寫
Client：用戶端服務，UDisk存儲接入子產品，部署在主控端上，負責虛機io下發到後端存儲叢集
Ymer：負責從鏡像系統拷貝鏡像到UDisk存儲叢集
鏡像叢集：特殊的UDisk存儲叢集，作為鏡像系統Cache，後端部署與普通叢集一緻。該叢集隻存儲基礎鏡像資料和克隆雲盤資料，客戶批量建立雲盤主機建立的雲盤系統盤都會落在該叢集中，後期通過遷移系統線上将雲盤系統盤打散遷移到UDisk存儲叢集中，遷移過程使用者無感覺。該叢集作為基礎鏡像緩存池，由Frigga子產品采用LRU政策淘汰冷鏡像資料，隻存儲使用者的高頻熱點鏡像。
系統盤克隆整體流程
雲主機服務下發系統盤克隆請求到Access接入服務，Access根據請求中的鏡像ID向Frigga查詢目前鏡像是否已存在後端鏡像叢集。
若存在，則響應Access鏡像存在，同時傳回鏡像對應雲盤ID，Access根據雲盤ID重新組織克隆請求，下發到鏡像叢集Metaserver服務，Metaserver接收請求執行内部克隆，更新克隆盤與鏡像盤對應關系，并将關系資訊同步給叢集内所有Chunk服務，通知完成後向上層傳回，克隆流程結束（上圖綠色線+黑色線部分）。整個過程不涉及與鏡像系統的互動，無資料拷貝，純記憶體操作，毫秒級時間内完成。
當請求的鏡像不存在時，Frigga本地記憶體新增鏡像記錄，并持久化DB。然後響應Access鏡像不存在，需要從鏡像系統克隆鏡像。Access接收響應後，向Metaserver下發從鏡像系統克隆請求，Metaserver建立鏡像雲盤并通知Ymer從鏡像系統拷貝鏡像資料，通知成功後，向上層Access傳回已開始克隆，Access接收到響應後再次向Metaserver下發從鏡像雲盤的内部克隆請求，流程同上（上圖紅色線+黑色線部分）。不過此時鏡像尚未克隆完成，Frigga會不斷查詢鏡像雲盤狀态，直到資料拷貝完成，此時系統盤可用。相較上面流程，多了一次從鏡像系統拷貝資料的過程，但也隻需要一次拷貝，降低了對鏡像系統的負載壓力。
UDisk整體架構如何适配是核心問題，幾乎涉及到UDisk所有子產品的改動，下文将詳細介紹如何基于ROW實作内部快照/克隆的技術細節。
三、快照/克隆雲盤實作原理
為了便于了解，先介紹幾個基本概念：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設計為主備模式，提高系統可用性。Frigga負責鏡像的導入，後端存儲叢集鏡像管理以及克隆排程。與Ymer配合實作UDisk存儲叢集間鏡像共享，從鏡像系統拷貝一次鏡像，UDisk存儲叢集内資料共享，大大減輕鏡像系統負載。Frigga根據LRU政策管理本地鏡像，防止無效鏡像/冷鏡像占用存儲資源，當鏡像叢集使用容量達到設定門檻值時，根據LRU政策淘汰冷鏡像。
當鏡像叢集容量到達使用門檻值後，會根據LRU政策主動删除長時間未使用鏡像。為防止單鏡像叢集内從單一鏡像克隆過多雲盤引起的通路熱點問題，Frigga為每個鏡像叢集内的鏡像設定單鏡像最大支援克隆盤數量門檻值，當克隆盤數量超過設定門檻值後，會重新從鏡像系統重新拷貝鏡像。
Metaserver中繼資料以及路由管理
UDisk原有架構設計中邏輯盤之間互相獨立，無互相關聯。為了實作UDisk存儲叢集内部鏡像共享（鏡像在鏡像叢集中也以邏輯盤存在），以邏輯盤lc粒度管理鏡像/快照/克隆盤關系，通過維護邏輯盤之間的關系實作快照的建立/克隆等操作，邏輯盤間的對應關系由Metaserver統一管理，并同步給Chunk以及Client服務。對盤多次打快照後，從不同快照克隆雲盤後，Metaserver側維護的邏輯盤之間的拓撲結構如下圖所示：
從同一鏡像批量克隆出多塊克隆盤後，邏輯盤之間的拓撲結構如下，所有克隆盤均指向鏡像雲盤，隻需要鏡像盤從鏡像系統拷貝一次，其他克隆盤的建立均為記憶體操作，Metaserver隻需維護克隆盤到鏡像之間的映射關系即可，這樣極大提高了系統盤的克隆速度。
邏輯盤間的關系在Metaserver記憶體中都是一條條的鍊，鍊上的各邏輯盤都依賴其上層節點，從鍊的末尾節點可依次向上層查詢直到根節點。Metaserver會将邏輯盤之間的映射關系資訊實時同步給Client以及Chunk服務，Client和Chunk服務與Metaserver之間也保持心跳消息，通過心跳主動同步邏輯盤映射關系資訊，防止網絡分區導緻的資訊不一緻。Metaserver通過version機制管理映射關系變化，通過比對Metaserver與Client/Chunk的version确定是否需要同步最新映射關系。
按照UDisk分布式設計原則，鏡像資料被分散存儲在鏡像叢集不同實體主機上，按原有路由政策，克隆盤讀取鏡像資料時，可能會存在跨機器通路的問題，增加資料讀取時延，影響雲主機啟動速度。為此，我們優化了路由政策：克隆盤和鏡像擁有相同的路由資訊，克隆盤和鏡像資料由相同的Chunk服務管理。這樣，當雲主機啟動加載系統盤資料時，可以直接讀取對應Chunk上的鏡像資料，本地讀操作，減少網絡通路時延。
Client IO下發
Client作為UDisk存儲叢集的接入服務，負責将虛機的IO下發到存儲叢集不同的Chunk服務上，為了保證将克隆盤的IO下發到對應鏡像所在Chunk服務上，Client側需要擷取對應克隆盤的所有映射關系，進而擷取到鏡像資訊，以鏡像的路由政策下發IO。
Chunk側IO讀/寫流程優化
Chunk以PC為粒度管理磁盤，并處理IO，隻有寫IO時Chunk才可能配置設定新PC。Chunk除了從Metaserver同步邏輯盤之間的映射關系外，還維護自身管理的PC資訊。對lc多次做快照後，Chunk維護的PC間拓撲結構如下圖：
從同一鏡像克隆出多塊盤後，Chunk維護的PC間拓撲結構如下：
Chunk 接收Client IO按照 PC讀寫磁盤，每個PC對應一個pcmeta中繼資料，該中繼資料記錄了PC雲盤與實體盤的映射關系，其中重定向标記位（bitmap）表示該資料是否需要從父節點讀取資料；每個标記位代表256k資料重定向結果，對于建立的克隆盤PC初始化時所有的bitmap都是1，表示每個256k都需要重定向讀寫。Client下發的IO可以由一個四元組PC Entry（lc_id, pc_no, offset, length）表示，代表要讀寫的邏輯盤、讀寫位置所屬PC、PC内位置、讀寫大小以及資料。
讀io重定向
對于讀請求，首先根據四元組PC Entry确認PC是否存在，若存在，再根據pcmeta中bitmap對應位是否為1确認是否需要重定向讀，bitmap為0說明讀取的資料在目前PC上，直接讀取資料即可。發現對應的bitmap為1就尋找父節點繼續判斷标記位，直到父節點的标記位為0表示不需要重定向直接讀取父節點PC對應位置的資料。
寫io重定向
對于寫io判斷首先判斷PC是否存在，如果克隆的PC存在，再判斷bitmap是否為1（需要重定向），如果為1就會找父節點對應的PC，先将父節點對應PC的256k資料讀取出來，再與目前寫io資料做合并，再寫入對應的磁盤。如果克隆的PC不存在，則先建立PC，建立PC的pcmeta中bitmap設定為1，再按照之前PC存在的流程同樣處理io。
四、總結
為了能夠達到秒級克隆的效果，達到短時間建立大批量虛機的需求，我們采用了ROW的方法，同時利用了鏡像緩存池作為熱點鏡像資料，提高了基礎鏡像克隆與内部克隆的速度與效率，能夠達到5min内批量建立1000以上虛機的要求。
目前，該方案已在海外洛杉矶、新加坡機房全量開放，國内上海、廣州、北京、香港等機房已針對特定客戶開放。主要目标客戶為短時間内有批量建立虛機需求或者大容量基礎鏡像的客戶，可以大大縮短使用者建立虛機時間。目前，可支撐使用者業務高峰期批量2500台虛機的建立需求。