Cinder 组件详解
理解 Block Storage
操作系统获得存储空间的方式一般有两种：
通过某种协议（SAS,SCSI,SAN,iSCSI 等）挂接裸硬盘，然后分区、格式化、创建文件系统；或者直接使用裸硬盘存储数据（数据库）
通过 NFS、CIFS 等 协议，mount 远程的文件系统
第一种裸硬盘的方式叫做 Block Storage（块存储），每个裸硬盘通常也称作 Volume（卷） 第二种叫做文件系统存储。NAS 和 NFS 服务器，以及各种分布式文件系统提供的都是这种存储。
理解 Block Storage Service
Block Storage Servicet 提供对 volume 从创建到删除整个生命周期的管理。
从 instance 的角度看，挂载的每一个 Volume 都是一块硬盘。
OpenStack 提供 Block Storage Service 的是 Cinder，其具体功能是：
提供 REST API 使用户能够查询和管理 volume、volume snapshot 以及 volume type
提供 scheduler 调度 volume 创建请求，合理优化存储资源的分配
通过 driver 架构支持多种 back-end（后端）存储方式，包括 LVM，NFS，Ceph 和其他诸如 EMC、IBM 等商业存储产品和方案
Cinder 架构
下图是 cinder 的逻辑架构图
Cinder 包含如下几个组件：
cinder-api
接收 API 请求，调用 cinder-volume 执行操作。
cinder-volume
管理 volume 的服务，与 volume provider 协调工作，管理 volume 的生命周期。运行 cinder-volume 服务的节点被称作为存储节点。
cinder-scheduler
scheduler 通过调度算法选择最合适的存储节点创建 volume。
volume provider
数据的存储设备，为 volume 提供物理存储空间。 cinder-volume 支持多种 volume provider，每种 volume provider 通过自己的 driver 与cinder-volume 协调工作。
Message Queue
Cinder 各个子服务通过消息队列实现进程间通信和相互协作。因为有了消息队列，子服务之间实现了解耦，这种松散的结构也是分布式系统的重要特征。
Database Cinder 有一些数据需要存放到数据库中，一般使用 MySQL。数据库是安装在控制节点上的，比如在我们的实验环境中，可以访问名称为“cinder”的数据库。
物理部署方案
Cinder 的服务会部署在两类节点上，控制节点和存储节点。 我们来看看控制节点 devstack-controller 上都运行了哪些 cinder-* 子服务。
cinder-api 和 cinder-scheduler 部署在控制节点上，这个很合理。
至于 cinder-volume 也在控制节点上可能有些同学就会迷糊了：cinder-volume 不是应该部署在存储节点上吗？
要回答这个问题，首先要搞清楚一个事实： OpenStack 是分布式系统，其每个子服务都可以部署在任何地方，只要网络能够连通。
无论是哪个节点，只要上面运行了 cinder-volume，它就是一个存储节点，当然，该节点上也可以运行其他 OpenStack服务。
cinder-volume 是一顶存储节点帽子，cinder-api 是一顶控制节点帽子。在我们的环境中，devstack-controller 同时戴上了这两顶帽子，所以它既是控制节点，又是存储节点。当然，我们也可以用一个专门的节点来运行 cinder-volume。
这再一次展示了 OpenStack 分布式架构部署上的灵活性： 可以将所有服务都放在一台物理机上，用作一个 All-in-One 的测试环境；而在生产环境中可以将服务部署在多台物理机上，获得更好的性能和高可用。
RabbitMQ 和 MySQL 通常是放在控制节点上的。
另外，也可以用 cinder service list 查看 cinder-* 子服务都分布在哪些节点上
还有一个问题：volume provider 放在那里？
一般来讲，volume provider 是独立的。cinder-volume 使用 driver 与 volume provider 通信并协调工作。所以只需要将 driver 与 cinder-volume 放到一起就可以了。在 cinder-volume 的源代码目录下有很多 driver，支持不同的 volume provider。
后面我们会以 LVM 和 NFS 这两种 volume provider 为例讨论 cinder-volume 的使用，其他 volume provider 可以查看 OpenStack 的 configuration 文档。
从 volume 创建流程看 cinder-* 子服务如何协同工作
对于 Cinder 学习来说，Volume 创建是一个非常好的场景，涉及各个 cinder-* 子服务，下面是流程图。
客户（可以是 OpenStack 最终用户，也可以是其他程序）向 API（cinder-api）发送请求：“帮我创建一个 volume”
API 对请求做一些必要处理后，向 Messaging（RabbitMQ）发送了一条消息：“让 Scheduler 创建一个 volume”
Scheduler（cinder-scheduler）从 Messaging 获取到 API 发给它的消息，然后执行调度算法，从若干计存储点中选出节点 A
Scheduler 向 Messaging 发送了一条消息：“让存储节点 A 创建这个 volume”
存储节点 A 的 Volume（cinder-volume）从 Messaging 中获取到 Scheduler 发给它的消息，然后通过 driver 在 volume provider 上创建 volume。
上面是创建虚机最核心的几个步骤，当然省略了很多细节，我们会在后面的章节详细讨论。
Cinder 的设计思想
Cinder 延续了 Nova 的以及其他组件的设计思想。
API 前端服务
cinder-api 作为 Cinder 组件对外的唯一窗口，向客户暴露 Cinder 能够提供的功能，当客户需要执行 volume 相关的操作，能且只能向 cinder-api 发送 REST 请求。这里的客户包括终端用户、命令行和 OpenStack 其他组件。
设计 API 前端服务的好处在于：
对外提供统一接口，隐藏实现细节
API 提供 REST 标准调用服务，便于与第三方系统集成
可以通过运行多个 API 服务实例轻松实现 API 的高可用，比如运行多个 cinder-api 进程
Scheduler 调度服务
Cinder 可以有多个存储节点，当需要创建 volume 时，cinder-scheduler 会根据存储节点的属性和资源使用情况选择一个最合适的节点来创建 volume。
调度服务就好比是一个开发团队中的项目经理，当接到新的开发任务时，项目经理会根据任务的难度，每个团队成员目前的工作负荷和技能水平，将任务分配给最合适的开发人员。
Worker 工作服务
调度服务只管分配任务，真正执行任务的是 Worker 工作服务。 在 Cinder 中，这个 Worker 就是 cinder-volume 了。这种 Scheduler 和 Worker 之间职能上的划分使得 OpenStack 非常容易扩展：
当存储资源不够时可以增加存储节点（增加 Worker）。 当客户的请求量太大调度不过来时，可以增加 Scheduler。
Driver 框架
OpenStack 作为开放的 Infrastracture as a Service 云操作系统，支持业界各种优秀的技术，这些技术可能是开源免费的，也可能是商业收费的。 这种开放的架构使得 OpenStack 保持技术上的先进性，具有很强的竞争力，同时又不会造成厂商锁定（Lock-in）。 那 OpenStack 的这种开放性体现在哪里呢？一个重要的方面就是采用基于 Driver 的框架。
以 Cinder 为例，存储节点支持多种 volume provider，包括 LVM, NFS, Ceph, GlusterFS，以及 EMC, IBM 等商业存储系统。 cinder-volume 为这些 volume provider 定义了统一的 driver 接口，volume provider 只需要实现这些接口，就可以 driver 的形式即插即用到 OpenStack 中。下面是 cinder driver 的架构示意图：
在 cinder-volume 的配置文件 /etc/cinder/cinder.conf 中 volume_driver 配置项设置该存储节点使用哪种 volume provider 的 driver，下面的示例表示使用的是 LVM。
Cinder 真正负责 Volume 管理的组件是 volume provider。
Cinder 支持多种 volume provider，LVM 是默认的 volume provider。
Devstack 安装之后，/etc/cinder/cinder 已经配置好了 LVM，如下图所示：
上面的配置定义了名为“lvmdriver-1”的 volume provider，也称作 back-end。其 driver 是 LVM，LVM 的 volume group 名为“stack-volumes-lvmdriver-1”。
Devstack 安装时并没有自动创建 volume group，所以需要我们手工创建。 如下步骤演示了在 /dev/sdb 上创建 VG “stack-volumes-lvmdriver-1”：
首先创建 physical volume /dev/sdb
Linux 的 lvm 默认配置不允许在 /dev/sdb 上创建 PV，需要将 sdb 添加到 /etc/lvm.conf 的 filter 中。然后创建 VG stack-volumes-lvmdriver-1
打开 Web GUI，可以看到 OpenStack 已经创建了 Volume Type “lvmdriver-1”
其 Extra Specs volume_backend_name 为 lvmdriver-1
上一节我们讨论了 Cinder 创建 Volume 的第一部分，cinder-api 的操作，本节继续第二部分，cinder-scheduler 调度工作。
cinder-scheduler 执行调度
cinder-scheduler 执行调度算法，通过 Filter 和 Weigher 挑选最优的存储节点 日志为 /opt/stack/logs/c-sch.log。
cinder-scheduler 通过 Flow volume_create_scheduler 执行调度工作。
该 Flow 依次执行 ExtractSchedulerSpecTask 和 ScheduleCreateVolumeTask。
主要的 filter 和 weighting 工作由 ScheduleCreateVolumeTask 完成。
经过 AvailabilityZoneFilter, CapacityFilter, CapabilitiesFilter 和 CapacityWeigher 的层层筛选，最终选择了存储节点 devstack-controller@lvmdriver-1#lvmdriver-1。
Flow volume_create_scheduler 完成调度，状态变为 SUCCESS。
cinder-scheduler 发送消息
cinder-scheduler 发送消息给 cinder-volume，让其创建 volume 源码 /opt/stack/cinder/cinder/scheduler/filter_scheduler.py，方法为 schedule_create_volume。
Volume 的最主要用途是作为虚拟硬盘提供给 instance 使用。Volume 是通过 Attach 操作挂载到 instance 上的。本节我们就来详细讨论 Cinder 是如何实现 Attach 的。
上一节我们成功创建了基于 LVM provider 的 volume。每个 volume 实际上是存储节点上 VG 中的一个 LV。
那么问题来了：存储节点上本地的 LV 如何挂载到计算节点的 instance 上呢？通常情况存储节点和计算节点是不同的物理节点。
解决方案是使用 iSCSI，如下图所示
iSCSI 是 Client-Server 架构，有 target 和 initiator 两个术语。
Target
提供 iSCSI 存储资源的设备，简单的说，就是 iSCSI 服务器。
Initiator
使用 iSCSI 存储资源的设备，也就是 iSCSI 客户端。
Initiator 需要与 target 建立 iSCSI 连接，执行 login 操作，然后就可以使用 target 上面的块存储设备了。 Target 提供的块存储设备支持多种实现方式，我们实验环境中使用的是 LV。 Cinder 的存储节点 cinder-volume 默认使用 tgt 软件来管理和监控 iSCSI target，在计算节点 nova-compute 使用 iscsiadm 执行 initiator 相关操作。
下面来看看 Attach 操作的流程图
向 cinder-api 发送 attach 请求
cinder-api 发送消息
cinder-volume 初始化 volume 的连接
nova-compute 将 volume attach 到 instance
下面我们详细讨论每一个步骤。
向cinder-api发送attach请求
客户（可以是 OpenStack 最终用户，也可以是其他程序）向 cinder-api 发送请求：“请将这个 volume attach 到指定的 instance 上。
这里我们将 volume “vol-1” attach 到 instance ”c2”上。 attach 操作之前，c2 上的虚拟磁盘如下：
进入 GUI 操作菜单 Project -> Compute -> Volumes
选择 volume “vol-1”，点击“Manage Attachments”
在 “Attach to Instance”下拉列表中，选择instance “c2”
点击 ”Attach Volume”
cinder-api 将接收到 attach volume 的请求，attach 请求实际上包含两个步骤：
初始化 volume 的连接 Volume 创建后，只是在 volume provider 中创建了相应存储对象（比如 LV），这时计算节点是无法使用的。Cinder-volume 需要以某种方式将 volume export 出来，计算节点才能够访问得到。这个 export 的过程就是“初始化 volume 的连接”。 下面是 cinder-api 的日志文件 /opt/stack/logs/c-api.log 中记录的相关信息Initialize_connection 的具体工作主要由 cinder-volume 完成，将在后面详细讨论。
Attach volume 初始化 volume 连接后，计算节点将 volume 挂载到指定的 instance，完成 attach 操作。下面是 cinder-api 的日志文件 /opt/stack/logs/c-api.log 中记录的相关信息
Attach 的具体工作主要由 nova-compute 完成，也将在后面详细讨论。
cinder-api 发送消息
cinder-api 分两步完成 attach 操作，所以对应地会先后向 RabbitMQ 发送了两条消息：
初始化 volume 的连接 cinder-api 没有打印发送消息的日志，只能通过源代码查看 /opt/stack/cinder/cinder/volume/api.py，方法为 initialize_connection
Attach volume cinder-api 没有打印发送消息的日志，只能通过源代码查看
上一节我们讨论了 attach volume 操作中 cinder-api 的工作，本节讨论 cinder-volume 和 nova-compute 如何将 volume attach 到 Instance。
cinder-volume 初始化 volume 的连接
cinder-volume 接收到 initialize_connection 消息后，会通过 tgt 创建 target，并将 volume 所对应的 LV 通过 target export 出来。日志为 /opt/stack/logs/c-vol.log
下面的日志显示：通过命令 tgtadm --lld iscsi --op show --mode target 看到已经将 1GB（1074MB）的 LV /dev/stack-volumes-lvmdriver-1/volume-1e7f6bd7-ce11-4a73-b95e-aabd65a5b188 通过 Target 1 export 出来了。
Initialize connection 完成。
nova-compute 将 volume attach 到 instance
计算节点作为 iSCSI initiator 访问存储节点 Iscsi Target 上的 volume，并将其 attach 到 instance。日志文件为 /opt/stack/logs/n-cpu.log
nova-compute 依次执行 iscsiadm 的 new, update, login, rescan 操作访问 target 上的 volume。
计算节点将 iSCSI target 上的 volume 识别为一个磁盘文件。
然后通过更新 instance 的 XML 配置文件将 volume 映射给 instance。
我们也可以通过 virsh edit 查看更新后的 XML。
可以看到，instance 增加了一个类型为 block 的虚拟磁盘，source 就是要 attach 的 volume，该虚拟磁盘的设备名为 vdb。
手工 Shut off 并 Start instance，通过 fdisk -l 查看到 volume 已经 attach 上来，设备为 vdb
GUI 界面也会更新相关 attach 信息
现在如果我们在存储节点执行 tgt-admin --show --mode target，会看到计算节点作为 initiator 已经连接到 target 1。cinder-volume 刚刚创建 target 的时候是没有 initiator 连接的，大家可以将下面的截图与之前的日志做个对比。
下图是 Detach 操作的流程图
向 cinder-api 发送 detach 请求
cinder-api 发送消息
nova-compute detach volume
cinder-volume 删除 target
下面我们详细讨论每一个步骤。
向 cinder-api 发送 attach 请求
客户（可以是 OpenStack 最终用户，也可以是其他程序）向 cinder-api 发送请求：“请 detach 指定 instance 上的 volume。
这里我们将 detach instance “c2”上的 volume “vol-1” 进入 GUI 操作菜单Project -> Compute -> Volumes。
选择 volume “vol-1”，点击“Manage Attachments”。
点击 “Detach Volume”。
再次确认。
cinder-api 将接收到 detach volume 的请求。日志文件在 /opt/stack/logs/c-api.log。
cinder-api 发送消息
cinder-api 发送消息 detach 消息。 cinder-api 没有打印发送消息的日志，只能通过源代码查看 /opt/stack/cinder/cinder/volume/api.py，方法为 detach。
Detach 的操作由 nova-compute 和 cinder-volume 共同完成：
首先 nova-compute 将 volume 从 instance 上 detach，然后断开与 iSCSI target 的连接。
最后 cinder-volume 删除 volume 相关的 iSCSI target。
后面两个小节将详细讨论这两个步骤。
nova-compute detach volume
nova-compute 首先将 volume 从 instance 上 detach 。 日志为 /opt/stack/logs/n-cpu.log。
这时通过 virsh edit 可以看到 XML 配置文件中已经不在有 volume 的虚拟磁盘。
接下来断开与 iSCSI target 的连接。
具体有下面几个步骤：
将缓存中的数据 Flush 到 volume。
删除计算节点上 volume 对应的 SCSI 设备。
通过 iscsiadm 的 logout，delete 操作断开与 iSCSI target 的连接。
compue-nova 完成了 detach 工作，接下来 cinder-volume 就可以删除 volume 相关的 target 了。
cinder-volume 删除 target
存储节点 cinder-volume 通过 tgt-admin 命令删除 volume 对应的 target。日志文件为 /opt/stack/logs/c-vol.log。
至此 detach volume 操作已经完成，GUI 也会更新 volume 的 attach 信息。
今天讨论 cinder 如何删除 volume 。
状态为 Available 的 volume 才能够被 delete。如果 volume 当前已经 attach 到 instance，需要先 detach 后才能 delete。
Delete操作实现比较简单，流程图如下：
向 cinder-api 发送 delete 请求
cinder-api 发送消息
cinder-volume 执行 delete 操作
下面我们详细讨论每一个步骤。
向 cinder-api 发送 delete 请求
客户（可以是 OpenStack 最终用户，也可以是其他程序）向 cinder-api 发送请求：“请 delete 指定的 volume。
这里我们将 delete volume “vol-2”
进入 GUI 操作菜单 Project -> Compute -> Volumes。
选择volume “vol-2”，点击“Delete Volume”。
再次确认。
cinder-api 将接收到 delete volume 的请求。日志文件在 /opt/stack/logs/c-api.log。
cinder-api 发送消息
cinder-api 发送消息 delete 消息。cinder-api 没有打印发送消息的日志，只能通过源代码查看 /opt/stack/cinder/cinder/volume/api.py，方法为 extend。
cinder-volume delete volume
cinder-volume 执行 lvremove 命令 delete volume。 日志为 /opt/stack/logs/c-vol.log。
这里比较有意思的是：cinder-volume 执行的是“安全”删除。 所谓“安全”实际上就是将 volume 中的数据抹掉，LVM driver 使用的是 dd 操作将 LV 的数据清零。日志如下：
然后删除 LV。
Snapshot 可以为 volume 创建快照，快照中保存了 volume 当前的状态，以后可以通过 snapshot 回溯。snapshot 操作实现比较简单，流程图如下：
向 cinder-api 发送 snapshot 请求
cinder-api 发送消息
cinder-volume 执行 snapshot 操作
下面我们详细讨论每一个步骤。
向 cinder-api 发送 snapshot 请求
客户（可以是 OpenStack 最终用户，也可以是其他程序）向 cinder-api 发送请求：“请 snapshot 指定的 volume。
这里我们将 snapshot volume “vol-1”。
进入 GUI 操作菜单 Project -> Compute -> Volumes。
选择 volume “vol-1”，点击 “Create Snapshot”。
为 snapshot 命名。
这里我们看到界面提示当前 volume 已经 attach 到某个 instance，创建 snapshot 可能导致数据不一致。我们可以先 pause instance，或者确认当前 instance 没有大量的磁盘 IO，处于相对稳定的状态，则可以创建 snapshot，否则还是建议先 detach volume 在做 sanpshot。
cinder-api 将接收到 snapshot volume 的请求。日志文件在 /opt/stack/logs/c-api.log。
cinder-api 发送消息
cinder-api 发送消息 snapshot 消息。cinder-api 没有打印发送消息的日志，只能通过源代码查看 /opt/stack/cinder/cinder/volume/api.py，方法为 _create_snapshot。
cinder-volume 执行 snapshot 操作
cinder-volume 执行 lvcreate 命令创建 snapshot。 日志为 /opt/stack/logs/c-vol.log。
对于 LVM volume provider，snapshot 实际上也是一个 LV，同时记录了与源 LV 的 snapshot 关系，可以通过 lvdisplay 查看。
GUI 的 Volume Snapshots 标签中可以看到新创建的 “vol-1-snapshot”。
有了 snapshot，我们就可以将 volume 回溯到创建 snapshot 时的状态。方法是通过 snapshot 创建新的 volume。
新创建的 volume 容量必须大于或等于 snapshot 的容量
其过程与 Create Volume 类似，不同之处在于 LV 创建之后会通过 dd 将 snapshot 的数据 copy 到新的 volume。
日志分析不再赘述，留个大家练习。
如果一个 volume 存在 snapshot，则这个 volume 是无法删除的。
这是因为 snapshot 依赖于 volume，snapshot 无法独立存在。
在 LVM 作为 volume provider 的环境中，snapshot 是从源 volume 完全 copy 而来，所以这种依赖关系不强。
但在其他 volume provider（比如商业存储设备或者分布式文件系统），snapshot 通常是源 volume 创建快照时数据状态的一个引用（指针），占用空间非常小，在这种实现方式里 snapshot 对源 volume 的依赖就非常明显了。
Backup 是将 volume 备份到别的地方（备份设备），将来可以通过 restore 操作恢复。
Backup VS Snapshot
初看 backup 功能好像与 snapshot 很相似，都可以保存 volume 的当前状态，以备以后恢复。但二者在用途和实现上还是有区别的，具体表现在：
Snapshot 依赖于源 volume，不能独立存在；而 backup 不依赖源 volume，即便源 volume 不存在了，也可以 restore。
Snapshot 与源 volume 通常存放在一起，都由同一个 volume provider 管理；而 backup 存放在独立的备份设备中，有自己的备份方案和实现，与 volume provider 没有关系。
上面两点决定了 backup 具有容灾功能；而 snapshot 则提供 volume provider 内便捷的回溯功能。
配置 cinder-backup
Cinder 的 backup 功能是由 cinder-backup 服务提供的，devstack 默认没有启用该服务，需要手工启用。与 cinder-volume 类似，cinder-backup 也通过 driver 架构支持多种备份 backend，包括 POSIX 文件系统、NFS、Ceph、GlusterFS、Swift 和 IBM TSM。支持的driver 源文件放在 /opt/stack/cinder/cinder/backup/drivers/
本节我们将以 NFS 为 backend 来研究 backup 操作。
在实验环境中，存放 volume backup 的 NFS 远程目录为 192.168.104.11:/backup cinder-backup 服务节点上 mount point 为 /backup_mount。
需要在 /etc/cinder/cinder.conf 中作相应配置。
然后手工启动 cinder-backup 服务。
/usr/bin/python /usr/local/bin/cinder-backup --config-file /etc/cinder/cinder.conf
一切准备就绪，下面我们来看 backup 操作的流程
向 cinder-api 发送 backup 请求
cinder-api 发送消息
cinder-backup 执行 backup 操作
下面我们详细讨论每一个步骤。
向 cinder-api 发送 backup 请求
客户（可以是 OpenStack 最终用户，也可以是其他程序）向 cinder-api 发送请求：“请 backup 指定的 volume。
这里我们将 backup volume “vol-1”，目前 backup 只能在 CLI 中执行。
这里因为 vol-1 已经 attach 到 instance，需要使用 --force 选项。
cinder-api 接收到 backup volume 的请求。日志文件在 /opt/stack/logs/c-api.log。
cinder-api 发送消息
cinder-api 发送 backup 消息。cinder-api 没有打印发送消息的日志，只能通过源代码查看 /opt/stack/cinder/cinder/backup/api.py，方法为 create。
cinder-backup 执行 backup 操作
cinder-backup 收到消息后，通过如下步骤完成 backup 操作，日志为 /opt/stack/logs/c-vol.log。
启动 backup 操作，mount NFS。
创建 volume 的临时快照。
创建存放 backup 的 container 目录。
对临时快照数据进行压缩，并保存到 container 目录。
创建并保存 sha256（加密）文件和 metadata 文件。
删除临时快照。
Backup 完成后，我们可以查看一下 container 目录的内容
里面有三个文件，根据前面的日志我们可以知道：
backup-00001，压缩后的 backup 文件。
backup_metadata，metadata 文件。
backup_sha256file，加密文件。
可以通过 cinder backup-list 查看当前存在的 backup。
另外我们可以查看一下 cinder backup-create 的用法。
这里有 --incremental 选项，表示可以执行增量备份。 如果之前做过普通（全量）备份，之后可以通过增量备份大大减少需要备份的数据量，是个很不错的功能。增量备份的操作和日志分析留给大家做练习。
restore 的过程其实很简单，两步走：
在存储节点上创建一个空白 volume。
将 backup 的数据 copy 到空白 voluem 上。
下面我们来看 restore 操作的详细流程：
向 cinder-api 发送 backup 请求
cinder-api 发送消息
cinder-scheduler 挑选最合适的 cinder-volume
cinder-volume 创建空白 volume
cinder-backup 将 backup 数据 copy 到空白 volume 上
我们先来看第 1 步。
向 cinder-api 发送 restore 请求
客户（可以是 OpenStack 最终用户，也可以是其他程序）向 cinder-api 发送请求：“请 restore 指定的 backup。这里我们将 restore 之前创建的 backup。
目前 restore 只能在 CLI 中执行。
cinder-api 接收到 restore 请求。日志文件在 /opt/stack/logs/c-api.log。
这里看到 cinder-api 转发请求，为 restore 创建 volume。 之后 cinder-scheduler 和 cinder-volume 将创建空白 volume，这个过程与 create volume 一样，不再赘述。
接下来分析数据恢复的过程。 首先，在 cinder-api 日志中可以看到相关信息。
这里注意日志中的 volume_id 和 backup_id 与前面 backup-restore 命令的输出是一致的。
下面来看 cinder-backup 是如何恢复数据的。
cinder-backup 执行 restore 操作
日志为 /opt/stack/logs/c-vol.log。
启动 restore 操作，mount NFS。
读取 container 目录中的 metadata。
将数据解压并写到 volume 中。
恢复 volume 的 metadata，完成 restore 操作。
此时，在 GUI 中已经可以看到 restore 创建的 volume。