值得關(guān)注的數(shù)據(jù)方舟

在2015年，UCloud推出了為云主機(jī)磁盤提供持續(xù)數(shù)據(jù)保護(hù)（CDP）的數(shù)據(jù)方舟（UDataArk）產(chǎn)品，支持最小精確到秒級(jí)的恢復(fù)，針對(duì)數(shù)據(jù)刪除或者丟失事件，能夠最大程度的挽回?cái)?shù)據(jù)。

數(shù)據(jù)方舟已經(jīng)在多個(gè)數(shù)據(jù)安全案例中得到應(yīng)用，并得到了眾多客戶的認(rèn)可。

近些年，隨著用戶高性能存儲(chǔ)場(chǎng)景需求的增多，SSD云盤和RSSD云盤成為主流選擇， 但是數(shù)據(jù)方舟只針對(duì)本地盤及普通云盤，SSD云盤和RSSD云盤缺乏高效的備份手段成為用戶的痛點(diǎn)。為此UCloud推出了磁盤快照服務(wù)（USnap），USnap基于數(shù)據(jù)方舟CDP技術(shù)并進(jìn)一步升級(jí)，以更低的成本為全系列云盤（普通/SSD/RSSD）提供了數(shù)據(jù)備份功能。

如何接入SSD/RSSD云盤等高性能設(shè)備以及如何降低連續(xù)數(shù)據(jù)保護(hù)功能的實(shí)現(xiàn)成本，是USnap產(chǎn)品要解決的兩個(gè)核心問(wèn)題。這不僅僅需要在數(shù)據(jù)方舟架構(gòu)層面上做出改進(jìn)，所有IO路徑的相關(guān)模塊也需要做重新設(shè)計(jì)。本文將詳細(xì)介紹USnap是如何使用數(shù)據(jù)方舟CDP技術(shù)并對(duì)其升級(jí)改造的技術(shù)細(xì)節(jié)。

Client捕獲用戶寫IO

方舟備份存儲(chǔ)集群獨(dú)立于UDisk存儲(chǔ)集群，是UCloud重要的設(shè)計(jì)前提，這保證了即使出現(xiàn)了UDisk集群遭遇故障而導(dǎo)致數(shù)據(jù)丟失的極端事件，用戶仍能從備份存儲(chǔ)集群中恢復(fù)數(shù)據(jù)。對(duì)此，UCloud實(shí)現(xiàn)了一個(gè)ark plug-in，集成到了UDisk的client中，這個(gè)plug-in會(huì)異步的捕獲UDisk的寫IO，并將其推送到方舟備份存儲(chǔ)集群。

如何高效的捕獲UDisk IO是個(gè)重要的問(wèn)題，UCloud希望對(duì)UDisk的IO路徑影響到最低。對(duì)于SSD UDisk client和RSSD UDisk client，IO的捕獲模式是完全不同的。

 

  

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

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

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

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

Front實(shí)時(shí)IO接入層

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

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

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

 

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

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

Arker容量存儲(chǔ)層

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

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

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

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

一次完整的回滾流程

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

如果是第一種情況，Chrono會(huì)命令Shuffle主動(dòng)拉取這部分?jǐn)?shù)據(jù)至Arker容量存儲(chǔ)層。在確認(rèn)目標(biāo)點(diǎn)數(shù)據(jù)已經(jīng)在Arker容量存儲(chǔ)層后，Chrono會(huì)查詢獲取到所有需要合并的Granu以及需要合并到哪個(gè)seq_num，并分發(fā)合并任務(wù)至所有Arker。Arker容量存儲(chǔ)層會(huì)對(duì)這些Granu進(jìn)行合并，對(duì)于一個(gè)合并任務(wù)，會(huì)首先進(jìn)行索引合并，隨后會(huì)根據(jù)已經(jīng)合并完成的索引進(jìn)行數(shù)據(jù)合并，合并完成后最終會(huì)生成一份新版本的BASE，這就是恢復(fù)后的全量數(shù)據(jù)。在得到恢復(fù)后的全量數(shù)據(jù)后，再將數(shù)據(jù)寫回到UDisk集群中。

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

總結(jié)

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

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

- END-

你

怎

么

看

  ？

歡迎文末評(píng)論補(bǔ)充！

歡迎新聞投稿

歡迎技術(shù)投稿

歡迎各種爆料

Aming全天候在線

全球存儲(chǔ)觀察為你開(kāi)啟新視野

歡迎點(diǎn)點(diǎn)贊，點(diǎn)在看，點(diǎn)分享