如何高效的捕獲UDisk IO是個重要的問題，我們希望對UDisk的IO路徑影響到最低。對于SSD UDisk client和RSSD UDisk client，IO的捕獲模式是完全不同的。 

對于SSD UDisk，Bdev線程在接受一個IO后，先提交到UDisk的IO線程中，如果是寫IO還需要推送至方舟備份存儲集群。對此Bdev線程會構(gòu)建一個ArkIORequest，拷貝一份包含data的智能指針對象，加入到無鎖隊列中。ArkHandle線程從無鎖隊列中獲取IO，轉(zhuǎn)發(fā)給ArkIO線程進行推送。UDisk IO完成后，無需等待方舟IO完成即可返回成功。UDisk IO和方舟IO均完成后，data才會被釋放。

對于RSSD UDisk，由于采用SPDK Vhost方案，Vhost和guest VM共享內(nèi)存，UDisk IO完成后，data內(nèi)存空間會立即被guest VM使用。為此我們加入了一個copy線程，由copy線程從無鎖隊列中獲取bdev_io，進行數(shù)據(jù)copy，數(shù)據(jù)copy完畢后再構(gòu)建一個ArkIORequest轉(zhuǎn)發(fā)給ArkIO線程進行推送，方舟IO完成后data由方舟plug-in中的ArkHandle進行釋放。

我們模擬了各種類型的IO場景，研究方舟plug-in對UDisk性能的影響。發(fā)現(xiàn)在低io_depth的場景下，方舟功能對于UDisk性能的影響最大不會超過5%，在高io_depth的場景下，方舟功能對于UDisk性能的影響接近0%?？梢姺街踦lug-in實現(xiàn)了高效的數(shù)據(jù)捕獲與轉(zhuǎn)發(fā)，不會影響用戶的線上業(yè)務(wù)。

塊層IO可以理解為一個三元組（sector, sector_num, data），代表讀寫位置、讀寫大小和實際數(shù)據(jù)。對于CDP系統(tǒng)，IO的三元組信息是不夠的，需要標記額外信息，才能夠恢復(fù)到任何一個時間點。在數(shù)據(jù)捕獲時，所有的寫IO都會標記好序列號（seq_num），序列號保證嚴格連續(xù)遞增，這是我們保證塊級數(shù)據(jù)一致性的基礎(chǔ)。并且所有的寫IO也會打上時間戳，方舟plug-in會保證即使在出現(xiàn)時鐘跳變的情況下，時間戳也不會出現(xiàn)回退。這樣數(shù)據(jù)變化及其時間戳都被保存下來，后端可以根據(jù)這些信息通過某種方式回放，恢復(fù)到過去的任意時刻，這就是CDP技術(shù)的基本原理。在推送到方舟備份存儲集群前，方舟plug-in會對IO進行合并，這可以顯著減少方舟接入層的IOPS。

Front實時IO接入層

方舟備份集群采用分層存儲，實時IO接入層使用少量的NVME等高速存儲設(shè)備，承接海量實時IO，實時IO會定期下沉到采用大量HDD設(shè)備構(gòu)建的容量存儲層。方舟的接入層（Front）是整個數(shù)據(jù)方舟系統(tǒng)的門戶，其性能關(guān)系到能否接入SSD/RSSD云盤等高性能的設(shè)備。

原始的Front是基于Log-structured的設(shè)計，每塊邏輯盤會被分配一組Front節(jié)點，對于一次簡單的磁盤IO寫入操作，client將IO轉(zhuǎn)發(fā)到Primary Front節(jié)點，Primary Front節(jié)點將此次的IO追加寫入到最新的Log中，并將IO同步到Slavery Front節(jié)點。

分析可知該設(shè)計存在以下問題：1. 一塊邏輯盤的實時IO只落在一組(Primary-Slavery)Front節(jié)點上，所以系統(tǒng)對于單塊邏輯盤的接入性能受到Front單節(jié)點性能限制。這種設(shè)計是無法接入RSSD云盤這種超高性能設(shè)備的。2.雖然通過hash的方式將用戶邏輯盤打散分布到整個接入層集群，但是可能出現(xiàn)分配在同一組Front節(jié)點的多塊邏輯盤同時存在高IO行為，由此產(chǎn)生了熱點問題，雖然可以通過運維手段將其中的部分邏輯盤切換到空閑的Front節(jié)點上，但這并不是解決問題的最佳方式。

針對于此，我們提出了基于Stream數(shù)據(jù)流的設(shè)計，以滿足高IO場景下業(yè)務(wù)對于接入能力的要求。Stream數(shù)據(jù)流的概念即是將邏輯盤的所有寫入數(shù)據(jù)抽象成為一段數(shù)據(jù)流，數(shù)據(jù)只在Stream尾部進行追加寫。Stream按照固定大小分片，每個分片按照一致性hash算法映射到一個歸置組，歸置組代表一個副本組，由存儲資源按照一定策略組成。這樣就將一塊邏輯盤的實時IO打散到了所有接入層集群上，這不僅解決了接入RSSD云盤這種超高性能設(shè)備的問題，同時還解決了接入層熱點的問題。

Stream數(shù)據(jù)流符合Buffer的特性，即從尾部寫入、從頭部讀出。我們使用一組數(shù)據(jù)來標識Stream數(shù)據(jù)流的有效區(qū)域：read_offset和write_offset。當Stream有實時數(shù)據(jù)寫入，write_offset增長。Shuffle模塊會處理實時IO下沉到容量存儲層的工作。Shuffle會從Front定期拉取數(shù)據(jù)，在內(nèi)存中進行分片（sharding），并組織為Journal數(shù)據(jù)，推送至下層的Arker容量存儲層。推送Arker成功后，read_offset更新。對于已經(jīng)下沉到方舟Arker容量存儲層的數(shù)據(jù)，我們會對其進行回收以釋放存儲資源。

Arker容量存儲層

CDP數(shù)據(jù)需要按照粒度（Granu）進行組織。根據(jù)業(yè)務(wù)需要，Granu被分為5種類型：journal、hour、day、base和snapshot，journal是秒級數(shù)據(jù)，包含用戶的原始寫請求；hour代表小時級別的增量數(shù)據(jù)；day代表天級別的增量數(shù)據(jù)；base是CDP的最底層數(shù)據(jù)；snapshot是用戶的手動快照數(shù)據(jù)。Granu會按照設(shè)定的備份策略進行合并。以默認的支持恢復(fù)到12小時內(nèi)任意一秒、24小時內(nèi)的任意整點以及3天內(nèi)的任意零點為例，journal至少會被保留12小時，超過12小時的journal會被合并為hour，此時數(shù)據(jù)的tick信息會被丟棄，之后的時間區(qū)間無法再恢復(fù)到秒級，超過24小時的hour會被合并為day，超過3天的day會和base合并為新的base，對于snapshot則會長久保留除非用戶主動刪除了快照。

作為方舟的容量存儲層，Arker為5類不同的Granu提供了統(tǒng)一的存儲；對于5種類型的Granu，又存在3種存儲格式：BASE Blob、CUT Blob和JOURNAL Bob。其中base和snapshot兩類Granu以BASE Blob格式存儲，day和hour兩類Granu以CUT Blob格式存儲，journal類型的Granu以JOURNAL Blob格式存儲。

對于journal、hour和day三類Granu，我們直接按分片進行存儲，每個有數(shù)據(jù)存在的分片都唯一對應(yīng)了一個inode對象，這個inode對象關(guān)聯(lián)一個JOURNAL Blob或CUT Blob。對于base和snapshot兩類Granu，我們將分片中的數(shù)據(jù)進一步細化，切分成一系列的TinyShard作為重刪單元，每個TinyShard也會唯一對應(yīng)一個inode對象，這個inode對象會關(guān)聯(lián)一個BASE Blob，數(shù)據(jù)相同的TinyShard會指向同一個inode對象，復(fù)用BASE Blob，由此達到了重刪的目的。

為了提高合并效率，我們還將索引和數(shù)據(jù)的存儲進行分離，以上所有業(yè)務(wù)元數(shù)據(jù)（Granu、Shard/TinyShard、Inode）都以key-value的形式存儲在KVDevice中，Blob數(shù)據(jù)經(jīng)過壓縮后存儲在FSDevice中，數(shù)據(jù)壓縮算法采用zstd算法，比起原先使用的snappy算法，又節(jié)約了至少30%的存儲成本。

一次完整的回滾流程

整個回滾流程由調(diào)度模塊Chrono進行控制。當用戶指定了一個回滾時間點，Chrono首先通過查詢Granu元數(shù)據(jù)確認該目標點數(shù)據(jù)命中的位置。命中位置只有兩種情況，一種是目標點數(shù)據(jù)還在Front接入層，尚未被Shuffle推送至Arker容量存儲層，另一種是已經(jīng)被Shuffle推送至Arker容量存儲層。

如果是第一種情況，Chrono會命令Shuffle主動拉取這部分數(shù)據(jù)至Arker容量存儲層。在確認目標點數(shù)據(jù)已經(jīng)在Arker容量存儲層后，Chrono會查詢獲取到所有需要合并的Granu以及需要合并到哪個seq_num，并分發(fā)合并任務(wù)至所有Arker。

Arker容量存儲層會對這些Granu進行合并，對于一個合并任務(wù)，會首先進行索引合并，隨后會根據(jù)已經(jīng)合并完成的索引進行數(shù)據(jù)合并，合并完成后最終會生成一份新版本的BASE，這就是恢復(fù)后的全量數(shù)據(jù)。在得到恢復(fù)后的全量數(shù)據(jù)后，再將數(shù)據(jù)寫回到UDisk集群中。

我們可以看到，數(shù)據(jù)合并階段是以shard為單位并發(fā)進行的，能利用到所有容量層磁盤的IO能力；數(shù)據(jù)回吐UDisk階段，也利用了方舟和UDisk都是分布式存儲，可以采取分片并發(fā)對拷的方式將數(shù)據(jù)寫入到UDisk集群。因此恢復(fù)的RTO也能得到保證，1TB的數(shù)據(jù)恢復(fù)時間通常在30min以內(nèi)。

總結(jié)

本文圍繞著公有云CDP備份系統(tǒng)如何構(gòu)建、CDP系統(tǒng)如何接入高性能IO設(shè)備以及CDP系統(tǒng)如何降低實現(xiàn)成本等幾個主要問題，介紹了UCloud磁盤快照服務(wù)USnap在業(yè)務(wù)架構(gòu)、存儲引擎等多方面的設(shè)計考慮和優(yōu)化方案。

后續(xù)我們還會在多個方面繼續(xù)提升磁盤快照服務(wù)USnap的使用體驗。產(chǎn)品上將會提供可以自定義備份時間范圍的增值服務(wù)，讓用戶可以自定義秒級、小時級、天級的保護范圍，滿足用戶的不同需求。技術(shù)上，則會引入全量全刪和Erasure Coding等技術(shù)進一步降低成本，以及使用Copy On Read技術(shù)加快回滾速度，讓用戶能夠享受到更先進技術(shù)帶來的豐富功能、性能提升和價格紅利。

zhupb