openstack中 虚拟机实例的备份 与 恢复总结

最近公司用于线上openstack环境的设备已经到达，DELL R420两台做控制节点，DELL R620五台做计算节点，DELL MD3200做实例镜像的备份，由于采用的低端存储设备，所以直接把实例的镜像文件直接写入存储中，IO性能肯定达不到，该存储的作用只是用于备份，虚拟机实例镜像还是落在计算节点本地的，关于虚拟机实例的备份有以下三种方案：

1 每天在计算节点定时用rsync同步虚拟机实例的镜像文件，每台计算节点计划运行四个虚拟机实例，每个实例规划空间为150G。

2 在计算节点的虚拟机实例上启用chroot环境，让业务程序直接运行在虚拟机的chroot环境中，然后用国产神器sersync实时同步chroot的整个环境到后端MD3200存储上(排除一些不必要的系统运行目录)。

3 和方案2差不多，也是让业务运行于chroot环境中，不过不同步整个chroot环境，只是用sersync同步chroot环境中与业务有关的几个重点目录到后端存储上(排除一些不必要的系统运行目录)。

   至于方案的效率就要看sersync的效率和网络带宽了。还有一个是关于chroot环境的，由于公司DO未分离，而且chroot环境中并不是运行某些单一的任务，可能是多种业务，每台虚拟机实例可能都有自己的业务配置环境，这样chroot运行一段时间后，就可能和一个完整的小型系统一样，慢慢变得庞大起来，因此需要同步的内容也会变多。

以上三个方案的BUG：

   在方案1中，由于实例镜像过于庞大，rsync在同步文件时先扫描文件进行对比，然后同步不同的文件，这样会浪费计算节点的资源，而且同时同步四个实例的话，不知是否会影响业务带宽，经评测后决定只能在晚上定时同步，这样时效性就差了。openstack有个快照功能，不过150G的镜像文件在做快照时也会需要一段时间，而且业务会中断，如果是不能中断的业务就不好操作了。

   在方案2中，用sersync直接同步整个chroot环境，相当于在本地有一份内容，在后端存储也有一份内容，如果计算节点宕机，只要生成一台实例，把存储上的对应业务文件copy到新实例上即可运行，不过就如上面所说，由于同步的是整个chroot环境，chroot环境本身也可能会很大，其中相当大一部分数据可能并不需要同步，项目经常会产生大量的日志文件，动辄上百G的日志文件，应该是没有必要同步的。不过确实方便配置管理。

   在方案3种，也是同步chroot环境，不过只是同步一些和业务相关的重要目录，系统目录、业务日志之类的目录就可以被忽略，这样同步的内容就会大大减少，不过由于公司业务DO未分离，导致运营人员并未完全掌控生产环境，可能会导致个别重要目录被遗忘，由于公司架构关系，业务多达几十个，而只是由少数几个人维护，虽然在备份上提升了一点性能，但是在后期管理方面可能会相当复杂。

################################################################################

下面是方案1中具体方案

openstack中，虚拟机实例一般是放在nova/instances目录底下.

该目录的典型结构如下所示：

root@node77:~# ls /opt/stack/nova/instances/
_base instance-0000001a

其中

_base目录中存放的是虚拟机实例的base image

而instance-0000001a存放的是虚拟机实例镜像的增量部分。

instance-0000001a目录有如下的一些文件：

root@node77:~# ls /opt/stack/nova/instances/instance-0000001a/
console.log disk disk.local libvirt.xml

其中

console.log 保存虚拟机启动的日志信息

disk 和 disk.local为虚拟机实例的镜像文件

libvirt.xml为配置文件。

这其中需要注意的是，disk和disk.local并没有包含该虚拟机的所有数据，它们只是基于base image的增量部分

我们通过kvm-image 工具可以查看该信息，如下：

root@node77:/opt/stack/nova/instances/instance-0000001a# kvm-img info disk
image: disk
file format: qcow2
virtual size: 50G (53687091200 bytes)
disk size: 1.6G
cluster_size: 2097152
backing file: /opt/stack/nova/instances/_base/5dcb736a3fbb7f5b92657095aa77a877f4039ec0_10 (actual path: /opt/stack/nova/instances/_base/5dcb736a3fbb7f5b92657095aa77a877f4039ec0_10)

root@node77:/opt/stack/nova/instances/instance-0000001a# kvm-img info disk.local
image: disk.local
file format: qcow2
virtual size: 40G (42949672960 bytes)
disk size: 4.0M
cluster_size: 2097152
backing file: /opt/stack/nova/instances/_base/ephemeral_0_40_None (actual path: /opt/stack/nova/instances/_base/ephemeral_0_40_None)

其中backing file 即是base image

因此我们在备份虚拟机实例的时候，不仅要备份instance-0000001a目录下的数据，而且要备份该虚拟机相关的base image数据，即backing file给出的文件。

对于该例子：

我们需要备份如下的文件：

（1）console.log

（2）disk

（3）disk.local

（4）libvirt.xml

（5）/opt/stack/nova/instances/_base/ephemeral_0_40_None

（6）/opt/stack/nova/instances/_base/5dcb736a3fbb7f5b92657095aa77a877f4039ec0_10

如何根据备份的文件，在另外一台机器上恢复该虚拟机：

方法1：

我们将disk 和 disk.local磁盘文件分别和它们的base image合并，生成两个新的磁盘文件，那么这两个磁盘文件将包含虚拟机所有的数据。

qemu-img convert [-c] [-f format] [-o options] [-O output_format] filename output_filenameqemu-img convert disk –O qcow2 newdisk qemu-img convert disk.local –O qcow2 newdisk.local

方法2：

我们修改disk和disk.local文件中backing file的位置，为当前base image的位置

qemu-img rebase [-f format] [-u] -b backing_file [-F backing_format] filename正确处理完磁盘文件后，剩下的工作就是按照libvirt.xml文件的设置，启动虚拟机了。