1. Cinder 简介
操作系统及应用使用存储空间的方式一般有两种：
- 通过 SATA、SCSI 等协议挂接物理硬盘或通过 iSCSI、FC 等协议访问 LUN 逻辑卷，然后分区、创建文件系统，或者直接使用裸的块设备存储数据（如某些数据库应用）；
- 通过 NFS、CIFS 等协议 mount 远程文件系统。
第一种为块存储（Block Storage），每个裸的块设备通常称作卷（Volume），第二种为文件系统存储。
Cinder 在 OpenStack 中为虚机提供块存储服务，从虚机的角度来看，挂载的每一个卷都是一块硬盘。Cinder 提供卷从创建到删除整个生命周期的管理，具体功能如下：
- 提供 RESTful API 查询和管理：卷、快照、备份等资源；
- 提供 scheduler 调度卷创建请求，优化存储资源的分配；
- 通过驱动（driver）架构支持多种存储后端（backend），包括 LVM、Ceph 等开源存储方案以及其它诸如 NetApp、EMC、IBM 等商业存储产品。
Cinder 包括：cinder-api, cinder-scheduler, cinder-volume 及 cinder-backup 等四个主要的功能模块，每个模块都是一个独立的服务进程，图示如下：
各模块的功能简单介绍如下：
- cinder-api 以 RESTful 接口的形式向外部客户（如 Cinder 命令行、OpenStack 其他服务组件等）暴露 Cinder 服务，负责将客户端的 HTTP 请求转换为内部组件间的 RPC 调用；
- cinder-scheduler 负责卷创建请求的调度，将 RPC 调用发往选择的 cinder-volume 进程；
- cinder-volume 负责具体的卷请求处理（如卷的创建、删除等）；
- cinder-backup 负责卷的备份相关的请求处理（如卷的备份、还原等）。
2. 数据保护技术
快照（Snapshot）、备份（Backup）、复制（Replication）是存储领域中最为常见的三种数据保护技术。
快照用于捕捉卷在某一个时刻的状态，用户可以随时回滚到这个状态，也可以基于该快照创建新卷。快照类似于 git 的 commit 操作，我们可以随时 reset/checkout 到任意历史 commit，但一旦保存 git 仓库的磁盘损坏，提交的 commit 信息将永久丢失，不能恢复。备份就是对卷进行导出并传输到远程存储设备中，当数据损坏时，用户可以从远端下载备份的数据，手动从备份数据中恢复，从而避免了数据损失。备份类似于 git 的 push 操作，即使本地的数据损坏，我们也能从远端的 git 仓库中恢复。数据复制则类似于 MySQL 的 master/slave 主从同步，通常只有 master 支持写操作，slave 不允许用户直接写数据，它只负责自动同步 master 的数据，但一旦 master 出现故障，slave 能够提升为 master 接管写操作。
简而言之，快照主要用于快速回溯，而备份则用于容灾，还能避免误删除操作造成的数据丢失。相对备份而已，复制则更进一步，不仅提供了实时备份的功能，还能实现故障的自动恢复（即高可用）。
3. Cinder 数据保护（Ceph backend）
Cinder 作为 OpenStack核心组件之一，为 OpenStack 虚机提供弹性的块存储服务，承载着用户大多数的业务数据，数据的损坏将可能导致灾难性后果，因此数据的保护至关重要。截至目前 Cinder（Ocata 版本）已经同时支持了对卷的快照、备份以及复制功能。
3.1 Cinder 快照
由于各种类型的存储后端基本上都支持快照相关的功能，因此 Cinder 的快照支持相对来说比较完善。Cinder 快照相关的命令行支持如下：
snapshot-create Creates a snapshot.
snapshot-delete Removes one or more snapshots.
snapshot-list Lists all snapshots.
snapshot-manage Manage an existing snapshot.
snapshot-manageable-list
Lists all manageable snapshots.
snapshot-metadata Sets or deletes snapshot metadata.
snapshot-metadata-show
Shows snapshot metadata.
snapshot-metadata-update-all
Updates snapshot metadata.
snapshot-rename Renames a snapshot.
snapshot-reset-state
Explicitly updates the snapshot state.
snapshot-show Shows snapshot details.
snapshot-unmanage Stop managing a snapshot.
对于 RBD 驱动而言，快照的创建、删除等操作，都是借助的 RBD image 已有的快照功能，快照回滚的功能在前几天刚合入，因此命令行或者 python-cinderclient Python API 的支持可能还需要一定时间，虽然 RBD 快照支持回滚，但是在 Cinder 的 RBD 驱动中并没有直接使用 RBD 的已有实现，而是采用的直接读取快照内容然后覆盖写入需执行回滚操作的卷，不是很理解为何这样设计。
对于某些卷驱动 Cinder 还支持一致性组快照操作，当前 Ceph 并不支持一致性组快照，但相关的 PR 即将合入。由于驱动对一致性组的支持非常有限，Cinder 在 N 版本引入了新的通用卷组的支持（兼容已有的一致性组），以实现非存储支持的卷组快照（无存储保证快照一致性）。
3.2 Cinder 备份
Cinder 在 G 版本引入了卷备份和恢复功能，该功能需要单独部署 cinder-backup 服务。cinder-backup 服务与 cinder-volume 服务类似，也通过支持各种不同的驱动，对接不同的存储后端，目前已完整支持 Ceph 后端。Cinder 备份相关的命令行支持如下：
backup-create Creates a volume backup.
backup-delete Removes one or more backups.
backup-export Export backup metadata record.
backup-import Import backup metadata record.
backup-list Lists all backups.
backup-reset-state Explicitly updates the backup state.
backup-restore Restores a backup.
backup-show Shows backup details.
备份创建的实现流程如下图所示。具体到 Ceph 驱动的实现，对于卷类型为 RBD image 的源卷，使用 rbd export-diff | rbd import-diff（该命令行同时支持增量和非增量两种形式的快照导出和导入）进行快照导出并通过管道导入至相同集群的不同存储池或不同集群的存储池。对于卷类型为非 RBD image 的源卷，则直接创建新的 RBD image，并将源卷的数据完整的写入新创建的 RBD image。因此对于卷类型为非 RBD image 的源卷，只支持全量备份，而 RBD image 类型的源卷则总是支持增量备份。
备份恢复的实现流程如下图所示。具体到 Ceph 驱动的实现，实际上与快照回滚的实现类似，读取备份操作时创建的 RBD image 的内容，然后覆盖写入源卷或者新的空白卷，这种类型称为全量恢复。对于 RBD 类型的新的空白卷同样支持通过 rbd export-diff | rbd import-diff 命令管道的形式进行增量恢复，由于 RBD image 自身的实现，这种方式对于稀疏卷而言写入的数据量相比全量恢复要少很多。
3.3 Cinder 复制
复制通常也称为远程复制或远程镜像，某些存储产品支持同步远程复制，可以做 RPO 为 0，即主站点的宕机不会导致数据丢失。实际上对于类似于两地三中心之类的这种部署形式，由于异地灾备中心与同城双活业务中心之间的网络时延太高，同步远程复制基本上不现实，因此同步复制基本上只适用于同城。
Cinder 对于复制的支持当前还不是很成熟，Cinder 复制相关的命令行支持如下：
failover-host Failover a replicating cinder-volume host.
卷复制操作是驱动的事情，在 Cinder 层只关心卷是否已启用复制，Cinder 在执行倒换操作时将所有已启用复制功能的卷进行倒换即可，因此在启用复制功能之前需要对 Cinder 以及存储后端都进行配置。
倒换的实现流程如下图所示。具体到 Ceph 驱动的实现，当前通过 RBD mirroring 功能实现对卷复制的支持，仅支持异步复制。RBD mirroring 在 Ceph 的 J 版本中引入，当前可能还缺少大规模的生成环境验证，且由于需要 RBD image journaling 特性的支持，会带来时延的大幅提升，因此性能会受到比较大的影响。
4. 总结
总的来看，Cinder 作为一个块存储服务框架，对于数据保护已经具备了基本的支持。Ceph 作为 Cinder 一个存储后端，已经基本具备了 Cinder 数据保护所要求的一些基本功能实现，但距离真正生成环境应用的成熟度感觉并不是很够。
5. 参考资料
VMware Virtual SAN Disaster Recovery
最后修改于 2019-01-05