一.什么是snapshot？
Nova备份的操作叫Snapshot，其工作原理是对云主机的镜像文件（系统盘）进行全量备份，生成一个类型为snapshot的image，然后将其保存到Glance上。
云主机 snapshot 操作可用于备份或者将 云主机 保存为新的 image。大致流程如下图1
1．向nova-api发送请求
客户（可以是OpenStack最终用户，也可以是其他程序）向API（nova-api）发送请求：“对这个Instance做个快照”，
2.nova-api发送消息
nova-api向Messaging（RabbitMQ）发送了一条消息：“对这个Instance做快照”。
3.nova-compute执行
暂停云主机，对云主机的镜像文件做快照，恢复云主机，将快照上传到Glance，Snapshot成功保存在Glance中。
图1
二.在生产系统中进行snapshot需要确保什么？
如果在生产系统中执行 snapshot 操作，必须确保此操作快速且安全。这里有两个关键点：
- 快速。
为保证数据的一致性，snapshot 时需要 pause 云主机，操作完后再 resume。在这个过程中 instance 是无法对外服务的，为了减少对业务的影响，我们希望 snapshot 越快越好。
- 安全。
即数据一致性，snapshot 出来的 image 不能有没落盘的数据，能够正常启动。所以通常在执行 snapshot 前要 pause instance，暂停所有的 IO 操作。
三. 默认配置下的 snapshot 操作是否能满足快速和安全这两个条件呢？
snapshot 是对 云主机的镜像文件（系统盘）做快照，镜像文件位于计算节点。snapshot 的执行步骤：
1.pause instance
2.执行 qemu-img convert 命令复制 disk 文件，生成快照文件
3.resume instance
4.将快照文件上传到 Glance
其中第 1 步保证了安全，而是否快速取决于第 2 步要花多长时间。
qemu-img convert 的执行时间取决于 disk 及其 backing 文件的大小，通常 instance 系统盘都以 G 为单位，所以第 2 步花费的时间是分钟级别的。
让生产系统暂停几分钟通常是不能被接受的，所以默认的 snapshot 操作没法做到快速。
那么解决方案是什么呢？
四. 真正的解决方案
默认 snapshot 的问题在于 qemu-img convert 耗时太长，而耗时太长的原因是 instance 的系统盘是文件，拷贝文件本身就是一个耗时的操作。
真正的解决方案是： 让 instance 从 cinder volume 启动，利用 storage provider 自己的 snapshot 技术实现快速复制。
现代存储系统（无论开源还是商业存储）基本上都提供了 volume 的 snapshot 功能，而这个 snapshot 是基于指针的，不会真正拷贝数据，所以非常快，
通常一瞬间就完成，对业务几乎没有影响。
所以如果 云主机 是从 cinder volume 启动的，那么做快照的时候 OpenStack 就会使用 storage provider 的 snapshot 完成操作。这就实现了既安全又快速。
五. boot from volume
部署 instance 时指定创建 volume。
执行部署后，OpenStack 会完成如下工作：
- 在 ceph 中创建一个 volume。
- 将 image 数据拷贝到该 volume。
- 云主机 从该 volume 启动。
- 对云主机 执行 snapshot 操作。
操作会瞬间完成！注意到快照的Size是0字节，这是因为它真正的存放位置在 cehp。
boot from volume 其实是 OpenStack 部署 instance 的最佳实践，instance 的启动盘和数据盘都由 cinder 管理，而且做快照和做备份都很方便。
