创建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全量备份:
-
调用librbd创建backup base image;
-
调用cinder-volume的rbd driver获取该image相关元数据( 池子、用户、配置文件等);
-
从源卷传输数据到该image;
其中cinder-volume的rbd driver由RBDImageIOWrapper类实现,最终调用到librbd,对各个操作进行实现,其中获取image相关元数据在cinder.conf文件中进行配置;
ceph增量备份:
-
判断是否有backup base image;
-
若没有,判断source image是否具有snap(from_snap),有的话删除该snap;
-
若有,判断snap是否不存在,若不存在则报错;
-
给source image创建一个新的snap(new_snap);
-
调用rbd命令import-diff进行数据传输。
三、底层对接后端
这里有一个疑问,为什么ceph.py采用两种方式与后端进行对接?
四、consistency-group依赖条件、对接方式
序号 | 依赖条件 | 当前状态 |
1 | 后端存储设备支持,即提供相应的驱动 | rbd驱动未提供此部分支持 |
2 | 数据库的变更(添加新表、外键的添加) | 已支持 |
3 | REST API的变更 | 已支持 |
4 | cinderclient添加新的CLI | 已支持 |
对接方式
类似其它功能特性,consistency-group由cinder-volume的后端提供驱动实现,接口流程如下:
根据前面的依赖条件,对接新的驱动仅需要在volume/drivers层添加对应的功能代码。