cinder-backup细致分析

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/u010433148/article/details/54629195

 创建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

 上,会生成两个文件:metadatasha256file

          其中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层添加对应的功能代码。


展开阅读全文

没有更多推荐了,返回首页