OpenStack使用Ceph存储，Ceph到底做了什么?

发布时间：2025-11-04 19:14:45 来源：创站工坊 作者：IT科技类资讯

1 背景知识

1.1 Ceph简介

Ceph是存储当前非常流行的开源分布式存储系统，具有高扩展性、到底高性能、存储高可靠性等优点，到底同时提供块存储服务(rbd)、存储对象存储服务(rgw)以及文件系统存储服务(cephfs)。到底目前也是存储OpenStack的主流后端存储，和OpenStack亲如兄弟，到底为OpenStack提供统一共享存储服务。存储使用Ceph作为OpenStack后端存储，到底具有如下优点：

Ceph的更多知识可以参考官方文档，这里我们只关注RBD，RBD管理的核心对象为块设备(block device)，通常我们称为volume，不过Ceph中习惯称之为image（注意和OpenStack image的区别）。Ceph中还有一个pool的概念，类似于namespace，不同的pool可以定义不同的副本数、pg数、放置策略等。每个image都必须指定pool。image的命名规范为pool_name/image_name@snapshot，比如openstack/test-volume@test-snap，表示在openstackpool中test-volumeimage的快照test-snap。因此以下两个命令效果是等同的:

在openstack pool上创建一个1G的image命令为:

image支持快照(snapshot)的功能，创建一个快照即保存当前image的状态，相当于git commit操作，用户可以随时把image回滚到任意快照点上(git reset)。创建快照命令如下:

查看rbd列表:

基于快照可以创建一个新的免费源码下载image，称为clone，clone不会立即复制原来的image，而是使用COW策略，即写时拷贝，只有当需要写入一个对象时，才从parent中拷贝那个对象到本地，因此clone操作基本秒级完成，并且需要注意的是基于同一个快照创建的所有image共享快照之前的image数据，因此在clone之前我们必须保护(protect)快照，被保护的快照不允许删除。clone操作类似于git branch操作，clone一个image命令如下:

我们可以查看一个image的子image(children)有哪些，也能查看一个image是基于哪个image clone的(parent)：

以上我们可以发现int32bit-test-2是int32bit-test-1的children，而int32bit-test-1是int32bit-test-2的parent。

不断地创建快照并clone image，就会形成一条很长的image链，链很长时，云服务器提供商不仅会影响读写性能，还会导致管理非常麻烦。可幸的是Ceph支持合并链上的所有image为一个独立的image，这个操作称为flatten，类似于git merge操作，flatten需要一层一层拷贝所有顶层不存在的数据，因此通常会非常耗时。

此时我们再次查看其parrent-children关系:

此时int32bit-test-1没有children了，int32bit-test-2完全独立了。

当然Ceph也支持完全拷贝，称为copy：

copy会完全拷贝一个image，因此会非常耗时，但注意copy不会拷贝原来的快照信息。

Ceph支持将一个RBD image导出(export):

导出会把整个image导出，Ceph还支持差量导出(export-diff)，即指定从某个快照点开始导出：

以上导出从快照点snap-1到快照点snap-2的数据。

当然与之相反的操作为import以及import-diff。通过export/import支持image的全量备份，而export-diff/import-diff实现了image的差量备份。

Rbd image是动态分配存储空间，通过du命令可以查看image实际占用的物理存储空间:

以上image分配的大小为1024M，实际占用的空间为12288KB。

删除image，注意必须先删除其所有快照，并且保证没有依赖的children:

1.2 OpenStack简介

OpenStack是一个IaaS层的云计算平台开源实现，关于OpenStack的更多介绍欢迎访问我的个人博客，这里只专注于当OpenStack对接Ceph存储系统时，基于源码分析一步步探测Ceph到底做了些什么工作。本文不会详细介绍OpenStack的整个工作流程，而只关心与Ceph相关的实现，如果有不清楚OpenStack源码架构的，可以参考我之前写的文章如何阅读OpenStack源码。

阅读完本文可以理解以下几个问题:

注意本文都是在基于使用Ceph存储的前提下，即Glance、Nova、Cinder都是使用的Ceph，其它情况下结论不一定成立。

另外本文会先贴源代码，很长很枯燥，你可以快速跳到总结部分查看OpenStack各个操作对应的Ceph工作。

2 Glance

2.1 Glance介绍

Glance管理的核心实体是image，它是OpenStack的核心组件之一，为OpenStack提供镜像服务(Image as Service)，主要负责OpenStack镜像以及镜像元数据的生命周期管理、检索、下载等功能。Glance支持将镜像保存到多种存储系统中，后端存储系统称为store，访问镜像的地址称为location，location可以是一个http地址，也可以是一个rbd协议地址。只要实现store的driver就可以作为Glance的存储后端，其中driver的主要接口如下:

为了便于维护，glance store目前已经作为独立的库从Glance代码中分离出来，由项目glance_store维护。目前社区支持的store列表如下:

2.2 镜像上传

由前面的介绍可知，镜像上传主要由store的add方法实现：

其中注意image_file不是一个文件，而是LimitingReader实例，该实例保存了镜像的所有数据，通过read(bytes)方法读取镜像内容。

从以上源码中看，glance首先获取ceph的连接session，然后调用_create_image方法创建了一个rbd image，大小和镜像的size一样:

因此以上步骤通过rbd命令表达大致为:

在ceph中创建完rbd image后，接下来：

可见Glance逐块从image_file中读取数据写入到刚刚创建的rbd image中并计算checksum，其中块大小由rbd_store_chunk_size配置，默认为8MB。

我们接着看***步骤:

从代码中可以看出，***步骤为创建image快照（快照名为snap）并保护起来。

假设我们上传的镜像为cirros，镜像大小为39MB，镜像uuid为d1a06da9-8ccd-4d3e-9b63-6dcd3ead29e6，配置保存在ceph的openstack pool中，则对应ceph的操作流程大致为:

我们可以通过rbd命令验证:

启示

我们前面介绍了镜像上传到Ceph的过程，省略了镜像上传到Glance的流程，但毋容置疑的是镜像肯定是通过Glance API上传到Glance中的。当镜像非常大时，由于通过Glance API走HTTP协议，导致非常耗时且占用API管理网带宽。我们可以通过rbd import直接导入镜像的方式大幅度提高上传镜像的效率。

首先使用Glance创建一个空镜像，记下它的uuid:

假设uuid为d1a06da9-8ccd-4d3e-9b63-6dcd3ead29e6，使用rbd命令直接导入镜像并创建快照：

设置glance镜像location url:

设置glance镜像其它属性：

2.3 镜像删除

删除镜像就是相反的过程，即先执行unprotext -> snap rm -> rm，如下:

删除镜像必须保证当前rbd image没有子image，否则删除会失败。

3 Nova

3.1 Nova介绍

Nova管理的核心实体为server，为OpenStack提供计算服务，它是OpenStack最核心的组件。注意Nova中的server不只是指虚拟机，它可以是任何计算资源的抽象，除了虚拟机以外，也有可能是baremetal裸机、容器等。

不过我们在这里假定:

启动虚拟机之前首先需要准备根磁盘(root disk)，Nova称为image，和Glance一样，Nova的image也支持存储到本地磁盘、Ceph以及Cinder(boot from volume)中。需要注意的是，image保存到哪里是通过image type决定的，存储到本地磁盘可以是raw、qcow2、ploop等，如果image type为rbd，则image存储到Ceph中。不同的image type由不同的image backend负责，其中rbd的backend为nova/virt/libvirt/imageackend中的Rbd类模块实现。

3.2 创建虚拟机

创建虚拟机的过程不再详细分析，不清楚的可以查看我之前写的博客，我们直接进入研究Nova的libvirt driver是如何为虚拟机准备根磁盘image的，代码位于nova/virt/libvirt/driver.py的spawn方法，其中创建image调用了_create_image方法。

_create_image方法部分代码如下:

该方法首先在本地创建虚拟机的数据目录/var/lib/nova/instances/${uuid}/，然后调用了_create_and_inject_local_root方法创建根磁盘。

其中image_backend.by_name()方法通过image type名称返回image backend实例，这里是Rbd。从代码中看出，如果backend支持clone操作(SUPPORTS_CLONE)，则会调用backend的clone()方法，否则通过fetch_image()方法下载镜像。显然Ceph rbd是支持clone的。我们查看Rbd的clone()方法，代码位于nova/virt/libvirt/imagebackend.py模块:

该方法遍历Glance image的所有locations，然后通过driver.is_cloneable()方法判断是否支持clone，若支持clone则调用driver.clone()方法。其中driver是Nova的storage driver，代码位于nova/virt/libvirt/storage，其中rbd driver在rbd_utils.py模块下，我们首先查看is_cloneable()方法:

可见如下情况不支持clone:

其中尤其注意第三条，如果镜像为非raw格式，Nova创建虚拟机时不支持clone操作，因此必须从Glance中下载镜像。这就是为什么Glance使用Ceph存储时，镜像必须转化为raw格式的原因。

***我们看clone方法:

该方法只调用了ceph的clone方法，可能会有人疑问都是使用同一个Ceph cluster，为什么需要两个ioctx？这是因为Glance和Nova可能使用的不是同一个Ceph pool，一个pool对应一个ioctx。

以上操作大致相当于如下rbd命令:

假设Nova和Glance使用的pool都是openstack，Glance镜像uuid为d1a06da9-8ccd-4d3e-9b63-6dcd3ead29e6，Nova虚拟机的uuid为cbf44290-f142-41f8-86e1-d63c902b38ed，则对应的rbd命令大致为:

我们进一步验证:

由输出可见，Nova确实创建了一个名为cbf44290-f142-41f8-86e1-d63c902b38ed_disk rbd image，并且它的parent为openstack/d1a06da9-8ccd-4d3e-9b63-6dcd3ead29e6@snap。

启示

3.3 创建虚拟机快照

首先说点题外话，我感觉Nova把create image和create snapshot弄混乱了，我理解的这二者的区别:

可事实上，Nova创建快照的子命令为image-create，API方法也叫_action_create_image()，之后调用的方法叫snapshot()。而实际上，对于大多数image type，如果不是从云硬盘启动(boot from volume)，其实就是create image，即上传镜像到Glance中，而非真正的snapshot。

当然只是命名的区别而已，这里对create image和create snapshot不做任何区别。

虚拟机的快照由libvirtdriver的snapshot()方法实现，代码位于nova/virt/libvirt/driver.py，核心代码如下:

Nova首先通过disk_path获取对应的image backend，这里返回的是imagebackend.Rbd，然后调用了backend的direct_snapshot()方法，该方法如下:

从代码中分析，大体可分为以下几个步骤:

对应rbd命令，假设虚拟机uuid为cbf44290-f142-41f8-86e1-d63c902b38ed，快照的uuid为db2b6552-394a-42d2-9de8-2295fe2b3180，则对应rbd命令为:

其中3437a9bbba5842629cc76e78aa613c70是产生的临时快照名称，它一个随机生成的uuid。

启示

其它存储后端主要耗时会在镜像上传过程，而当使用Ceph存储时，主要耗在rbd的flatten过程，因此创建虚拟机快照通常要好几分钟的时间。有人可能会疑问，为什么一定要执行flatten操作呢，直接clone不就完事了吗？社区这么做是有原因的：

3.4 删除虚拟机

libvirt driver删除虚拟机的代码位于nova/virt/libvirt/driver.py的destroy方法:

注意前面的_destroy方法其实就是虚拟机关机操作，即Nova会首先让虚拟机先关机再执行删除操作。紧接着调用cleanup()方法，该方法执行资源的清理工作。这里我们只关注清理disks的过程:

由于我们的image type为rbd，因此调用的_cleanup_rbd()方法:

我们只考虑正常删除操作，忽略resize撤回操作，则filter_fn为lambda disk: disk.startswith(instance.uuid)，即所有以虚拟机uuid开头的disk(rbd image)。需要注意，这里没有调用imagebackend的Rbd driver，而是直接调用storage driver，代码位于nova/virt/libvirt/storage/rbd_utils.py:

该方法首先获取所有的rbd image列表，然后通过filter_fn方法过滤以虚拟机uuid开头的image，调用_destroy_volume方法:

该方法最多会尝试10+1次_cleanup_vol()方法删除rbd image，如果有快照，则会先删除快照。

假设虚拟机的uuid为cbf44290-f142-41f8-86e1-d63c902b38ed，则对应rbd命令大致为:

4 Cinder

4.1 Cinder介绍

Cinder是OpenStack的块存储服务，类似AWS的EBS，管理的实体为volume。Cinder并没有实现volume provide功能，而是负责管理各种存储系统的volume，比如Ceph、fujitsu、netapp等，支持volume的创建、快照、备份等功能，对接的存储系统我们称为backend。只要实现了cinder/volume/driver.py中VolumeDriver类定义的接口，Cinder就可以对接该存储系统。

Cinder不仅支持本地volume的管理，还能把本地volume备份到远端存储系统中，比如备份到另一个Ceph集群或者Swift对象存储系统中，本文将只考虑从源Ceph集群备份到远端Ceph集群中的情况。

4.2 创建volume

创建volume由cinder-volume服务完成，入口为cinder/volume/manager.py的create_volume()方法，

Cinder创建volume的流程使用了taskflow框架，taskflow具体实现位于cinder/volume/flows/manager/create_volume.py，我们关注其execute()方法:

从代码中我们可以看出，创建volume分为4种类型：

raw

创建空白卷是最简单的方式，代码如下:

直接调用driver的create_volume()方法，这里driver是RBDDriver，代码位于cinder/volume/drivers/rbd.py:

其中size单位为MB，vol_name为volume-${volume_uuid}。

假设volume的uuid为bf2d1c54-6c98-4a78-9c20-3e8ea033c3db，Ceph池为openstack，创建的volume大小为1GB，则对应的rbd命令相当于:

我们可以通过rbd命令验证:

create from snapshot

从快照中创建volume也是直接调用driver的方法，如下:

我们查看RBDDriver的create_volume_from_snapshot()方法:

从代码中看出，从snapshot中创建快照分为3个步骤:

假设新创建的volume的uuid为e6bc8618-879b-4655-aac0-05e5a1ce0e06，快照的uuid为snapshot-e4e534fc-420b-45c6-8e9f-b23dcfcb7f86，快照的源volume uuid为bf2d1c54-6c98-4a78-9c20-3e8ea033c3db，指定的size为2，rbd_flatten_volume_from_snapshot为False（默认值)，则对应的rbd命令为:

从源码上分析，Cinder从快照中创建volume时，用户可以配置是否执行flatten操作：

第二点可能会更复杂，比如基于快照创建了一个volume，然后基于该volume又创建了快照，基于该快照创建了volume，则用户不能删除源volume，不能删除快照。

create from volume

从volume中创建volume，需要指定源volume id(source_volid):

我们直接查看driver的create_cloned_volume()方法，该方法中有一个很重要的配置项rbd_max_clone_depth，即允许rbd image clone允许的最长深度，如果rbd_max_clone_depth <= 0，则表示不允许clone:

此时相当于rbd的copy命令。

如果rbd_max_clone_depth > 0:

这个过程和创建虚拟机快照非常相似，二者都是先基于源image创建snapshot，然后基于snapshot执行clone操作，区别在于是否执行flatten操作，创建虚拟机快照时一定会执行flatten操作，而该操作则取决于clone深度:

如果当前depth超过了允许的***深度rbd_max_clone_depth则执行flatten操作，并删除创建的快照。

假设创建的volume uuid为3b8b15a4-3020-41a0-80be-afaa35ed5eef，源volume uuid为bf2d1c54-6c98-4a78-9c20-3e8ea033c3db，则对应的rbd命令为:

当rbd_max_clone_depth > 0且depth < rbd_max_clone_depth时，通过rbd命令验证:

可见volume-3b8b15a4-3020-41a0-80be-afaa35ed5eef的parent为:

create from image

从镜像中创建volume，这里假定Glance和Cinder都使用的同一个Ceph集群，则Cinder可以直接从Glance中clone，不需要下载镜像:

我们查看driver的clone_image()方法：

rbd直接clone，这个过程和创建虚拟机基本一致。如果创建volume时指定了新的大小，则调用rbd resize执行扩容操作。

假设新创建的volume uuid为87ee1ec6-3fe4-413b-a4c0-8ec7756bf1b4，glance image uuid为db2b6552-394a-42d2-9de8-2295fe2b3180，则rbd命令为:

通过rbd命令验证如下:

可见新创建的rbd image的parent为openstack/db2b6552-394a-42d2-9de8-2295fe2b3180@snap。

注：其实我个人认为该方法需要执行flatten操作，否则当有volume存在时，Glance不能删除镜像，相当于Glance服务依赖于Cinder服务状态，这有点不合理。

4.3 创建快照

创建快照入口为cinder/volume/manager.py的create_snapshot()方法，该方法没有使用taskflow框架，而是直接调用的driver create_snapshot()方法，如下:

RBDDriver的create_snapshot()方法非常简单:

因此volume的快照其实就是对应Ceph rbd image快照，假设snapshot uuid为e4e534fc-420b-45c6-8e9f-b23dcfcb7f86，volume uuid为bf2d1c54-6c98-4a78-9c20-3e8ea033c3db，则对应的rbd命令大致如下:

从这里我们可以看出虚拟机快照和volume快照的区别，虚拟机快照需要从根磁盘rbd image快照中clone然后flatten，而volume的快照只需要创建rbd image快照，因此虚拟机快照通常需要数分钟的时间，而volume快照能够秒级完成。

4.4 创建volume备份

在了解volume备份之前，首先需要理清快照和备份的区别。我们可以通过git类比，快照类似git commit操作，只是表明数据提交了，主要用于回溯与回滚。当集群奔溃导致数据丢失，通常不能从快照中完全恢复数据。而备份则类似于git push，把数据安全推送到了远端存储系统中，主要用于保证数据安全，即使本地数据丢失，也能从备份中恢复。Cinder的磁盘备份也支持多种存储后端，这里我们只考虑volume和backup driver都是Ceph的情况，其它细节可以参考Cinder数据卷备份原理与实践。生产中volume和backup必须使用不同的Ceph集群，这样才能保证当volume ceph集群挂了，也能从另一个集群中快速恢复数据。本文只是为了测试功能，因此使用的是同一个Ceph集群，通过pool区分，volume使用openstackpool，而backup使用cinder_backuppool。

另外，Cinder支持增量备份，用户可以指定--incremental参数决定使用的是全量备份还是增量备份。但是对于Ceph后端来说，Cinder总是先尝试执行增量备份，只有当增量备份失败时，才会fallback到全量备份，而不管用户有没有指定--incremental参数。尽管如此，我们仍然把备份分为全量备份和增量备份两种情况，注意只有***次备份才有可能是全量备份，剩下的备份都是增量备份。

全量备份(***次备份)

我们直接查看CephBackupDriver的backup()方法，代码位于cinder/backup/drivers/ceph.py。

这里主要判断源volume是否是rbd，即是否使用Ceph后端，只有当volume也使用Ceph存储后端情况下才能执行增量备份。

我们查看_backup_rbd()方法:

from_snap为上一次备份时的快照点，由于我们这是***次备份，因此from_snap为None，base_name格式为volume-%s.backup.base，这个base是做什么的呢？我们查看下_create_base_image()方法就知道了:

可见base其实就是一个空卷，大小和之前的volume大小一致。

也就是说如果是***次备份，在backup的Ceph集群首先会创建一个大小和volume一样的空卷。

我们继续看源码:

首先在源volume中创建了一个新快照，快照名为backup.${backup_id}.snap.${timestamp}，然后调用了rbd_diff_transfer()方法:

方法调用了rbd命令，先通过export-diff子命令导出源rbd image的差量文件，然后通过import-diff导入到backup的image中。

假设源volume的uuid为075c06ed-37e2-407d-b998-e270c4edc53c，大小为1GB，backup uuid为db563496-0c15-4349-95f3-fc5194bfb11a，这对应的rbd命令大致如下:

我们可以通过rbd命令验证如下:

从输出上看，源volume创建了一个快照，ID为52，在backup的Ceph集群中创建了一个空卷volume-075c06ed-37e2-407d-b998-e270c4edc53c.backup.base，并且包含一个快照backup.xxx.snap.1511344566.67，该快照是通过import-diff创建的。

增量备份

前面的过程和全量备份一样，我们直接跳到_backup_rbd()方法:

首先获取源volume对应rbd image的***快照最为parent，然后判断在backup的Ceph集群的base中是否存在相同的快照（根据前面的全量备份，一定存在和源volume一样的快照。

我们继续看后面的部分:

这个和全量备份基本是一样的，唯一区别在于此时from_snap不是None，并且后面会删掉from_snap。_rbd_diff_transfer方法可以翻前面代码。

假设源volume uuid为075c06ed-37e2-407d-b998-e270c4edc53c，backup uuid为e3db9e85-d352-47e2-bced-5bad68da853b，parent backup uuid为db563496-0c15-4349-95f3-fc5194bfb11a，则对应的rbd命令大致如下:

我们通过rbd命令验证如下:

和我们分析的结果一致，源volume的快照会删除旧的而只保留***的一个，backup则会保留所有的快照。

4.5 备份恢复

备份恢复是备份的逆过程，即从远端存储还原数据到本地。备份恢复的源码位于cinder/backup/drivers/ceph.py的restore()方法，该方法直接调用了_restore_volume()方法，因此我们直接看_restore_volume()方法:

其中_diff_restore_allowed()是一个非常重要的方法，该方法判断是否支持通过直接导入方式恢复，我们查看该方法实现:

从该方法中我们可以看出支持差量导入方式恢复数据，需要满足以下所有条件:

换句话说，虽然Cinder支持将数据还复到已有的volume（包括源volume）中，但如果使用Ceph后端就不支持增量恢复，导致效率会非常低。

因此如果使用Ceph存储后端，官方文档中建议将备份恢复到空卷中（不指定volume)，不建议恢复到已有的volume中。

Note that Cinder supports restoring to a new volume or the original volume the backup was taken from. For the latter case, a full copy is enforced since this was deemed the safest action to take. It is therefore recommended to always restore to a new volume (default).

这里假定我们恢复到空卷中，命令如下:

注意我们没有指定--volume参数。此时执行增量恢复，代码实现如下:

可见增量恢复非常简单，仅仅调用前面介绍的_rbd_diff_transfer()方法把backup Ceph集群对应的base image的快照export-diff到volume的Ceph集群中，并调整大小。

假设backup uuid为e3db9e85-d352-47e2-bced-5bad68da853b，源volume uuid为075c06ed-37e2-407d-b998-e270c4edc53c，目标volume uuid为f65cf534-5266-44bb-ad57-ddba21d9e5f9，则对应的rbd命令为:

如果不满足以上5个条件之一，则Cinder会执行全量备份，全量备份就是一块一块数据写入:

这种情况下效率很低，非常耗时，不建议使用。

5 总结

5.1 Glance

1. 上传镜像

2. 删除镜像

5.2 Nova

1 创建虚拟机

2 创建虚拟机快照

3 删除虚拟机

5.3 Cinder

1 创建volume

(1) 创建空白卷

(2) 从快照中创建

(3) 从volume中创建

(4) 从镜像中创建

2 创建快照

3 创建备份

(1) ***次备份

(2) 增量备份

4 备份恢复

 【本文是专栏作者“付广平”的原创文章，如需转载请通过获得联系】

戳这里，看该作者更多好文

相关文章