UCloud在2015年推出了為雲主機磁盤提供持續資料保護（CDP）的資料方舟（UDataArk）産品，支援最小精确到秒級的恢複，針對資料删除或者丢失事件，能夠最大程度的挽回資料。資料方舟已經在多個資料安全案例中得到應用，并得到了衆多客戶的認可。
近些年，随着使用者高性能存儲場景需求的增多，SSD雲盤和RSSD雲盤成為主流選擇， 但是資料方舟隻針對本地盤及普通雲盤，SSD雲盤和RSSD雲盤缺乏高效的備份手段成為使用者的痛點。為此我們推出了磁盤快照服務（USnap），USnap基于資料方舟CDP技術并進一步更新，以更低的成本為全系列雲盤（普通/SSD/RSSD）提供了資料備份功能。
如何接入SSD/RSSD雲盤等高性能裝置以及如何降低連續資料保護功能的實作成本，是USnap産品要解決的兩個核心問題。這不僅僅需要在資料方舟架構層面上做出改進，所有IO路徑的相關子產品也需要做重新設計。本文将詳細介紹USnap是如何使用資料方舟CDP技術并對其更新改造的技術細節。
Client捕獲使用者寫IO
方舟備份存儲叢集獨立于UDisk存儲叢集，是我們重要的設計前提，這保證了即使出現了UDisk叢集遭遇故障而導緻資料丢失的極端事件，使用者仍能從備份存儲叢集中恢複資料。對此，我們實作了一個ark plug-in，內建到了UDisk的client中，這個plug-in會異步的捕獲UDisk的寫IO，并将其推送到方舟備份存儲叢集。
如何高效的捕獲UDisk IO是個重要的問題，我們希望對UDisk的IO路徑影響到最低。對于SSD UDisk client和RSSD UDisk client，IO的捕獲模式是完全不同的。
對于SSD UDisk，Bdev線程在接受一個IO後，先送出到UDisk的IO線程中，如果是寫IO還需要推送至方舟備份存儲叢集。對此Bdev線程會建構一個ArkIORequest，拷貝一份包含data的智能指針對象，加入到無鎖隊列中。ArkHandle線程從無鎖隊列中擷取IO，轉發給ArkIO線程進行推送。UDisk IO完成後，無需等待方舟IO完成即可傳回成功。UDisk IO和方舟IO均完成後，data才會被釋放。
對于RSSD UDisk，由于采用SPDK Vhost方案，Vhost和guest VM共享記憶體，UDisk IO完成後，data記憶體空間會立即被guest VM使用。為此我們加入了一個copy線程，由copy線程從無鎖隊列中擷取bdev_io，進行資料copy，資料copy完畢後再建構一個ArkIORequest轉發給ArkIO線程進行推送，方舟IO完成後data由方舟plug-in中的ArkHandle進行釋放。
我們模拟了各種類型的IO場景，研究方舟plug-in對UDisk性能的影響。發現在低io_depth的場景下，方舟功能對于UDisk性能的影響最大不會超過5%，在高io_depth的場景下，方舟功能對于UDisk性能的影響接近0%。可見方舟plug-in實作了高效的資料捕獲與轉發，不會影響使用者的線上業務。
塊層IO可以了解為一個三元組（sector, sector_num, data），代表讀寫位置、讀寫大小和實際資料。對于CDP系統，IO的三元組資訊是不夠的，需要标記額外資訊，才能夠恢複到任何一個時間點。在資料捕獲時，所有的寫IO都會标記好序列号（seq_num），序列号保證嚴格連續遞增，這是我們保證塊級資料一緻性的基礎。并且所有的寫IO也會打上時間戳，方舟plug-in會保證即使在出現時鐘跳變的情況下，時間戳也不會出現回退。這樣資料變化及其時間戳都被儲存下來，後端可以根據這些資訊通過某種方式回放，恢複到過去的任意時刻，這就是CDP技術的基本原理。在推送到方舟備份存儲叢集前，方舟plug-in會對IO進行合并，這可以顯著減少方舟接入層的IOPS。
Front實時IO接入層
方舟備份叢集采用分層存儲，實時IO接入層使用少量的NVME等高速儲存設備，承接海量實時IO，實時IO會定期下沉到采用大量HDD裝置建構的容量存儲層。方舟的接入層（Front）是整個資料方舟系統的門戶，其性能關系到能否接入SSD/RSSD雲盤等高性能的裝置。
原始的Front是基于Log-structured的設計，每塊邏輯盤會被配置設定一組Front節點，對于一次簡單的磁盤IO寫入操作，client将IO轉發到Primary Front節點，Primary Front節點将此次的IO追加寫入到最新的Log中，并将IO同步到Slavery Front節點。
分析可知該設計存在以下問題：1. 一塊邏輯盤的實時IO隻落在一組(Primary-Slavery)Front節點上，是以系統對于單塊邏輯盤的接入性能受到Front單節點性能限制。這種設計是無法接入RSSD雲盤這種超高性能裝置的。
2.雖然通過hash的方式将使用者邏輯盤打散分布到整個接入層叢集，但是可能出現配置設定在同一組Front節點的多塊邏輯盤同時存在高IO行為，由此産生了熱點問題，雖然可以通過運維手段将其中的部分邏輯盤切換到空閑的Front節點上，但這并不是解決問題的最佳方式。
針對于此，我們提出了基于Stream資料流的設計，以滿足高IO場景下業務對于接入能力的要求。Stream資料流的概念即是将邏輯盤的所有寫入資料抽象成為一段資料流，資料隻在Stream尾部進行追加寫。Stream按照固定大小分片，每個分片按照一緻性hash算法映射到一個歸置組，歸置組代表一個副本組，由存儲資源按照一定政策組成。這樣就将一塊邏輯盤的實時IO打散到了所有接入層叢集上，這不僅解決了接入RSSD雲盤這種超高性能裝置的問題，同時還解決了接入層熱點的問題。
Stream資料流符合Buffer的特性，即從尾部寫入、從頭部讀出。我們使用一組資料來辨別Stream資料流的有效區域：read_offset和write_offset。當Stream有實時資料寫入，write_offset增長。Shuffle子產品會處理實時IO下沉到容量存儲層的工作。Shuffle會從Front定期拉取資料，在記憶體中進行分片（sharding），并組織為Journal資料，推送至下層的Arker容量存儲層。推送Arker成功後，read_offset更新。對于已經下沉到方舟Arker容量存儲層的資料，我們會對其進行回收以釋放存儲資源。
Arker容量存儲層
CDP資料需要按照粒度（Granu）進行組織。根據業務需要，Granu被分為5種類型：journal、hour、day、base和snapshot，journal是秒級資料，包含使用者的原始寫請求；hour代表小時級别的增量資料；day代表天級别的增量資料；base是CDP的最底層資料；snapshot是使用者的手動快照資料。Granu會按照設定的備份政策進行合并。以預設的支援恢複到12小時内任意一秒、24小時内的任意整點以及3天内的任意零點為例，journal至少會被保留12小時，超過12小時的journal會被合并為hour，此時資料的tick資訊會被丢棄，之後的時間區間無法再恢複到秒級，超過24小時的hour會被合并為day，超過3天的day會和base合并為新的base，對于snapshot則會長久保留除非使用者主動删除了快照。
作為方舟的容量存儲層，Arker為5類不同的Granu提供了統一的存儲；對于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，我們直接按分片進行存儲，每個有資料存在的分片都唯一對應了一個inode對象，這個inode對象關聯一個JOURNAL Blob或CUT Blob。對于base和snapshot兩類Granu，我們将分片中的資料進一步細化，切分成一系列的TinyShard作為重删單元，每個TinyShard也會唯一對應一個inode對象，這個inode對象會關聯一個BASE Blob，資料相同的TinyShard會指向同一個inode對象，複用BASE Blob，由此達到了重删的目的。
為了提高合并效率，我們還将索引和資料的存儲進行分離，以上所有業務中繼資料（Granu、Shard/TinyShard、Inode）都以key-value的形式存儲在KVDevice中，Blob資料經過壓縮後存儲在FSDevice中，資料壓縮算法采用zstd算法，比起原先使用的snappy算法，又節約了至少30%的存儲成本。
一次完整的復原流程
整個復原流程由排程子產品Chrono進行控制。當使用者指定了一個復原時間點，Chrono首先通過查詢Granu中繼資料确認該目标點資料命中的位置。命中位置隻有兩種情況，一種是目标點資料還在Front接入層，尚未被Shuffle推送至Arker容量存儲層，另一種是已經被Shuffle推送至Arker容量存儲層。
如果是第一種情況，Chrono會指令Shuffle主動拉取這部分資料至Arker容量存儲層。在确認目标點資料已經在Arker容量存儲層後，Chrono會查詢擷取到所有需要合并的Granu以及需要合并到哪個seq_num，并分發合并任務至所有Arker。Arker容量存儲層會對這些Granu進行合并，對于一個合并任務，會首先進行索引合并，随後會根據已經合并完成的索引進行資料合并，合并完成後最終會生成一份新版本的BASE，這就是恢複後的全量資料。在得到恢複後的全量資料後，再将資料寫回到UDisk叢集中。
我們可以看到，資料合并階段是以shard為機關并發進行的，能利用到所有容量層磁盤的IO能力；資料回吐UDisk階段，也利用了方舟和UDisk都是分布式存儲，可以采取分片并發對拷的方式将資料寫入到UDisk叢集。是以恢複的RTO也能得到保證，1TB的資料恢複時間通常在30min以内。
總結
本文圍繞着公有雲CDP備份系統如何建構、CDP系統如何接入高性能IO裝置以及CDP系統如何降低實作成本等幾個主要問題，介紹了UCloud磁盤快照服務USnap在業務架構、存儲引擎等多方面的設計考慮和優化方案。
後續我們還會在多個方面繼續提升磁盤快照服務USnap的使用體驗。産品上将會提供可以自定義備份時間範圍的增值服務，讓使用者可以自定義秒級、小時級、天級的保護範圍，滿足使用者的不同需求。技術上，則會引入全量全删和Erasure Coding等技術進一步降低成本，以及使用Copy On Read技術加快復原速度，讓使用者能夠享受到更先進技術帶來的豐富功能、性能提升和價格紅利。