Cinder 中的增量备份支持

Launchpad 蓝图

https://blueprints.launchpad.net/cinder/+spec/incremental-backup

问题描述

目前 Cinder 备份功能的实现仅支持给定卷的完全备份和恢复。没有提供仅备份自上次备份以来发生的更改的机制。随着卷越来越大,卷之间的所有更改都相对较小,在备份期间复制整个卷将消耗大量资源,并且无法很好地扩展到更大的部署中。本规范详细讨论了 Cinder 中增量备份功能的实现。

用例

提议的变更

Cinder 备份 API 默认使用 Swift 作为其后端。当卷备份到 Swift 时,Swift 会创建一个清单文件,该文件描述了备份卷的内容。清单文件包含头部(元数据)和指向卷备份文件的指针数组。由于 Swift 对对象大小有限制,Cinder 备份 API 将卷数据拆分为 Swift 对象大小的单个块,并将这些单个块上传到 Swift。Cinder 卷备份清单文件包含这些对象的列表、它们对应的对象、每个对象在卷中的逻辑偏移量以及每个块的消息摘要,以检测对对象的任何未经授权的更改。在恢复操作期间,Cinder 根据清单和清单中引用的单个块重建卷。

为了支持增量备份功能,我们在备份文件列表中引入了另一个对象,称为 shafile。shafile 文件有助于跟踪自上次备份以来卷的更改。这个新对象保存卷的 SHA256 值。SHA-2 或 SHA256 的简要说明可以在 http://en.wikipedia.org/wiki/SHA-2 找到。备份清单文件将引用此对象。在完全备份操作期间,Cinder 将卷划分为用户可配置块大小的固定块。它计算每个块的 SHA256 值,并编译一个 SHA 列表,然后将 shafile 上传到备份容器。

为了使增量备份实现简单,增量操作仅相对于完全备份执行。在增量备份期间,cinder 读取完全备份的 shafile。它从当前卷数据创建新的 shafile,并将新的 shafile 与完全备份 shafile 进行比较,以计算自上次完全备份以来已更改的块。

我们将使用现有的清单机制来捕获 delta。由于完全备份不包含任何空洞,每个块的偏移量 + 长度描述了卷逻辑地址的全部长度。但是,对于增量备份,这种模型受到挑战,并且单个文件的偏移量/块变得稀疏。清单中偏移量/长度的缺失表示自上次备份以来未修改的数据。这种方法的潜在缺点是,如果对卷的更改是碎片化的,增量备份可能会导致 Swift 中过多的对象。但是,像 Swift 这样的对象存储构建为有效地处理许多小对象。

新的 shafile 作为增量备份的一部分上传。

清单头部标识此备份为增量备份,因此包含对完全备份容器的引用。

备份清单头部进行了以下更改

metadata['version'] = self.DRIVER_VERSION
metadata['backup_id'] = backup['id']
metadata['volume_id'] = volume_id
metadata['backup_name'] = backup['display_name']
metadata['backup_description'] = backup['display_description']
metadata['created_at'] = str(backup['created_at'])

# Changes to metadata section of manifest
metadata['shafile'] = <shafilename>  # Path to shafile name. Or
                                     # can be hardcoded to "shafile"
                                     # in the container

metadata['backup_type'] = "incrementa/full" # backup type
metadata['full_container'] = <object path> # path of full backup

预计恢复 API 不会更改,但是恢复实现将更改为处理增量备份。为了使从增量备份恢复简单易于测试,恢复操作首先从完全备份副本恢复整个卷,然后按照增量备份清单中描述的偏移量和长度应用增量更改。

基于快照的备份

Since existing backup implementation copies the data directly from the volume,
it requires the volume to be detached from the instance. For most cloud
workloads this may be sufficient but other workloads that cannot tolerate
prolonged downtimes, a snapshot based backup solution can be a viable
alternative. Snapshot based backup will perform a point in time copy of the
volume and backup the data from point in time copy. This approach does not
require volume to be detached from the instance. Rest of the backup and
restore functionality remain the same.

As an alternative, snapshot based backup can be implemented by extending
existing backup functionality to snapshot volumes. This approach can be lot
more simpler than backup API taking snapshot of the volume and then managing
the snapshots.

备选方案

增量备份提供了两个重要的好处
  1. 在存储备份镜像时使用更少的存储空间

  2. 减少网络带宽并提高备份过程在 CPU 和时间利用率方面的整体效率

第一个好处可以通过对备份镜像进行后处理以删除重复数据或使用启用去重功能的备份存储来实现。但是,除非 Cinder 备份支持增量备份,否则无法实现第二个好处。

数据模型影响

没有感知的数据模型更改

REST API 影响

没有提出新的 API。而是将增强现有的备份 API,以接受一个名为“--incr”的附加选项,其参数为“<完全备份容器的路径>”。

cinder backup-create <volumeid> --incr <full backup container>
  Performs incremental backup

cinder backup-create <volumeid> --snapshot
  Optionally backup-create will backup a snapshot of the volume. Snapshot
  based backups can be performed while the volume is still attached to the
  instance.

cinder backup-create <volumeid> --snapshot --incr <full backup container>
  Optionally backup-create will perform incremental backup from volume
  snapshot

预计不会对恢复 api 进行更改

安全影响

通知影响

其他最终用户影响

python-cinderclient 将被修改为接受“--incr”选项。它可能包含一些验证代码来验证完全备份容器路径是否有效

目前备份功能未与 OpenStack 控制台集成。当发生这种情况时,控制台将为用户提供选择增量备份的选项

性能影响

除了在完全备份操作期间计算 SHA 之外,对现有 API 没有其他性能影响。增量备份带来的效率可以轻松抵消性能损失。此外,新的硬件支持 CPU 指令来计算 SHA,这减轻了 CPU 周期的压力。

其他部署者影响

开发人员影响

实现

负责人

主要负责人:muralibalcha(murali.balcha@triliodata.com)

其他贡献者:giribasava(giri.basava@triliodata.com)

工作项

  1. python-cinderclient 接受“--incr”选项和一些验证代码

  2. cinder/api 解析“--incr”选项

  3. cinder/backup/api.py 备份 api 签名已修改

  4. cinder/backup/manager.py

  5. cinder/backup/driver/swift.py 大部分繁重的工作在这里完成。备份和恢复 api 都将被修改。

依赖项

测试

将为增量备份添加单元测试。

测试将主要关注以下方面
  1. SHA 文件生成

  2. 创建对原始卷的各种更改。这些包括

  1. 更改第一个块

  2. 更改最后一个块

  3. 更改连续奇数个块

  4. 更改连续偶数个块

  5. 更改分布在卷的多个部分

  1. 执行 1 个增量

  2. 执行多个增量备份

  3. 恢复一系列增量备份并比较内容

  4. 执行完全备份,然后增量备份,然后完全备份,然后从各种备份恢复卷。

文档影响

需要在块存储手册中记录新选项。

参考资料