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 技术加快回滚速度，让用户能够享受到更先进技术带来的丰富功能、性能提升和价格红利。