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技术放慢回滚速度，让用户可能享受到更先进技术带来的丰盛性能、性能晋升和价格红利。