cinder-backup细致分析

 创建backup流程图：

 

 恢复backup流程图：

二、可扩展接口

 下面给出了backup相关的层次接口，并显示了各层次功能接口的调用关系。主要分为以下几个层次：

层次	功能
cinder-api的API层接口	暴露给客户端的API接口
cinder-backup的API层接口	将RPC的接口进行封装使被import
cinder-backup的RPCAPI层接口	与manager.py进行交互
cinder-backup的manager层接口	与cinder-backup的driver进行交互
cinder-backup的driver层接口	与存储后端或后端提供的库进行交互

         从代码上能够发现，ceph作为backup的后端只提供了创建、恢复、删除备份的操作，对于export-record、import-record的操作

没有提供，其余接口则在本文件中被调用。

         这个地方比较疑惑，此前文档中采用nfs作为backend时，export-record、import-record功能能够使用，为什么ceph不提供该功能，了解到：

         swift、nfs的备份是基于chunk的备份，继承自ChunkedBackupDriver(位于/cinder/backup/chunkeddriver.py)，实现机制为将原始

volume拆分成chunk，然后保存到对应的存储上，做全量备份时，每次从volume读入chunk_size字节数据，从头每sha_block_size个字

节做一次SHA计算，并保存结果，然后将chunk_size数据（可压缩）保存到存储上，形成一个object，循环将整个volume保存到backend

 上，会生成两个文件：metadata、sha256file。

          其中metadata记录volume对应存储上的哪些object、object大小、压缩算法、长度、偏移量，sha256file按顺序记录每次SHA计算

结果。当增量备份时，将每sha_block_size数据的SHA值与上次保存在sha256file中的SHA值比对，若不等则备份相应sha_block。

          全量备份恢复时先指定volume id，通过metadata文件将存储端的备份文件和volume对应起来，而增量备份恢复时，由于增量备份的

特性，使得增量备份间有依赖，形成备份链。

          而ceph之所以没有提供export-record、import-record的操作，也是由于ceph作为cinder-backup后端的性质决定的。

ceph全量备份：

1. 调用librbd创建backup base image;

2. 调用cinder-volume的rbd driver获取该image相关元数据（ 池子、用户、配置文件等）;

3. 从源卷传输数据到该image;

 其中cinder-volume的rbd driver由RBDImageIOWrapper类实现，最终调用到librbd，对各个操作进行实现，其中获取image相关元数据在cinder.conf文件中进行配置;

ceph增量备份：

1. 判断是否有backup base image;

2. 若没有，判断source image是否具有snap(from_snap)，有的话删除该snap;

3. 若有，判断snap是否不存在，若不存在则报错;

4. 给source image创建一个新的snap(new_snap);

5. 调用rbd命令import-diff进行数据传输。

三、底层对接后端

这里有一个疑问，为什么ceph.py采用两种方式与后端进行对接？

 

四、consistency-group依赖条件、对接方式

序号	依赖条件	当前状态
1	后端存储设备支持，即提供相应的驱动	rbd驱动未提供此部分支持
2	数据库的变更（添加新表、外键的添加）	已支持
3	REST API的变更	已支持
4	cinderclient添加新的CLI	已支持

 

对接方式

 类似其它功能特性，consistency-group由cinder-volume的后端提供驱动实现，接口流程如下：

 根据前面的依赖条件，对接新的驱动仅需要在volume/drivers层添加对应的功能代码。