OpenStack中那些很少见但很有用的操作

[[207647]]

写在前面

从2013年开始折腾OpenStack，到目前Pike版本已经发布，也有好几年的时间了。在使用过程中，我发现有很多很有用的操作，但是却很少被提及。这里我不直接点明我要介绍什么，直接抛出以下几个问题：

• 如何把一个私有镜像共享给其它租户?
• 上传一个很大的镜像老是超时怎么办，用户上传恶意镜像怎么办?
• 如何阻止用户对虚拟机执行任何操作，保证虚拟机安全，防止误操作?
• 虚拟机长时间不用却一直占用资源怎么办?
• 虚拟机文件系统奔溃，如何进入rescue模式修复?
• 如何把存储系统已经存在的数据卷导入到OpenStack中?
• 能否把volume挂载到宿主机中?
• 怎么把一个volume转交给另一个租户?
• volume备份没有问题，但数据库数据丢失怎么办?

接下来我们针对每一点问题，详细介绍如何通过OpenStack已有的功能解决。

Glance

member

镜像是OpenStack中非常重要的数据，保存了用户的操作系统数据，因此保证镜像的安全性非常重要。通常上传到Glance的镜像可以设置为public和private，public的镜像对所有的租户可见，而private镜像只有租户自己可见。在新版本的Glance中，引入了一种新的visibility状态shared，该状态的镜像允许共享给指定的租户。共享的目标租户我们称为member，我们只需要把租户加到镜像的member中就可以访问该镜像了。

首先我们在admin租户下创建一个镜像如下:

glance image-create --disk-format raw --container-format bare --name cirror-3.0 --file cirros-3.0.img 

在demo租户下该镜像是不可见:

$ source  openrc_demo 
$ glance image-list 
+----+------+ 
| ID | Name | 
+----+------+ 
+----+------+ 

我们把demo加到镜像member中:

$ glance member-create ec5426f5-ab4d-43a6-a1e1-5a1919aa7bea fb498fdd27e74750a6b209158437696c 
+--------------------------------------+----------------------------------+---------+ 
| Image ID                             | Member ID                        | Status  | 
+--------------------------------------+----------------------------------+---------+ 
| ec5426f5-ab4d-43a6-a1e1-5a1919aa7bea | fb498fdd27e74750a6b209158437696c | pending | 
+--------------------------------------+----------------------------------+---------+ 

admin这边把demo加入到member中，还需要demo这边确认，即member-update:

$ glance member-update ec5426f5-ab4d-43a6-a1e1-5a1919aa7bea fb498fdd27e74750a6b209158437696c accepted 
+--------------------------------------+----------------------------------+----------+ 
| Image ID                             | Member ID                        | Status   | 
+--------------------------------------+----------------------------------+----------+ 
| ec5426f5-ab4d-43a6-a1e1-5a1919aa7bea | fb498fdd27e74750a6b209158437696c | accepted | 
+--------------------------------------+----------------------------------+----------+ 

此时在demo租户下可以看到共享的镜像了:

$ glance image-list 
+--------------------------------------+------------+ 
| ID                                   | Name       | 
+--------------------------------------+------------+ 
| ec5426f5-ab4d-43a6-a1e1-5a1919aa7bea | cirror-3.0 | 
+--------------------------------------+------------+ 

task

通常我们通过image-create上传镜像，这至少存在以下两个问题：

1. 镜像没有校验，你可以随便上传一个图片啥的，或者上传一个恶意文件，你甚至可以把Glance当作对象存储使用 :)。
2. 镜像通常很大，上传占资源多并且慢，上传大镜像很容易就导致上传超时。

因此Glance从V2版本开始提出了task的概念，task可以定义上传镜像的任务流程，然后Glance会异步执行，并反馈结果，关于Glance task介绍可以参考Get started with tasks api in glance.

首先定义task，json文件如下:

{ "input": { "image_properties": { "container_format": "bare", "disk_format": "raw", "name": "cirros-0.3.5-x86_64" }, "import_from": "http://download.cirros-cloud.net/0.3.5/cirros-0.3.5-x86_64-disk.img", "import_from_format": "raw" }, "type": "import" } 

创建task:

$ glance task-create --type import --input "$(cat import_image.json | jq '.input')" 
+------------+----------------------------------------------------------------------------------+ 
| Property   | Value                                                                            | 
+------------+----------------------------------------------------------------------------------+ 
| created_at | 2017-09-28T08:03:47Z                                                             | 
| id         | 564b5ee4-56db-4360-bb71-d1d1c4d896a2                                             | 
| input      | {"image_properties": {"container_format": "bare", "name":                        | 
|            | "cirros-0.3.5-x86_64"}, "import_from_format": "raw", "import_from":              | 
|            | "http://download.cirros-cloud.net/0.3.5/cirros-0.3.5-x86_64-disk.img"}           | 
| message    |                                                                                  | 
| owner      | ae21d957967d4df0865411f0389ed7e8                                                 | 
| result     | None                                                                             | 
| status     | pending                                                                          | 
| type       | import                                                                           | 
| updated_at | 2017-09-28T08:03:47Z                                                             | 
+------------+----------------------------------------------------------------------------------+ 

查看task:

$ glance task-list 
+--------------------------------------+--------+------------+----------------------------------+ 
| ID                                   | Type   | Status     | Owner                            | 
+--------------------------------------+--------+------------+----------------------------------+ 
| 564b5ee4-56db-4360-bb71-d1d1c4d896a2 | import | processing | ae21d957967d4df0865411f0389ed7e8 | 
+--------------------------------------+--------+------------+----------------------------------+ 

此时glance会异步地下载镜像，完成后状态变成success：

$ glance task-show 564b5ee4-56db-4360-bb71-d1d1c4d896a2 
+------------+----------------------------------------------------------------------------------+ 
| Property   | Value                                                                            | 
+------------+----------------------------------------------------------------------------------+ 
| created_at | 2017-09-28T09:32:10Z                                                             | 
| expires_at | 2017-09-30T09:33:54Z                                                             | 
| id         | 564b5ee4-56db-4360-bb71-d1d1c4d896a2                                             | 
| input      | {"image_properties": {"container_format": "bare", "disk_format": "raw", "name":  | 
|            | "cirros-0.3.5-x86_64"}, "import_from_format": "raw", "import_from":              | 
|            | "http://download.cirros-cloud.net/0.3.5/cirros-0.3.5-x86_64-disk.img"}           | 
| message    |                                                                                  | 
| owner      | ae21d957967d4df0865411f0389ed7e8                                                 | 
| result     | {"image_id": "e5f8a941-f14f-4065-b381-b537271eba4c"}                             | 
| status     | success                                                                          | 
| type       | import                                                                           | 
| updated_at | 2017-09-28T09:33:54Z                                                             | 
+------------+----------------------------------------------------------------------------------+ 

result中保存了image的id。

该设计初衷是好的，不过从Mitaka版本开始，task API废弃了，社区准备重构import image流程，参考image import refactor。

Nova

lock

这个功能理解起来比较容易，即锁定虚拟机，普通用户不能对locked的虚拟机执行任何操作，管理员通过该操作可以保证虚拟机的安全性，阻止用户误操作。

但是需要注意的是，lock只作用于普通用户，管理员是无视lock的。

我们首先创建一台虚拟机：

nova boot --image f0b1239a-bb34-4cfb-ad06-e18cbb8ee4b9 --flavor m1.small --nic net-id=9f3aad86-f3c1-499b-ba62-5708dd229466 int32bit-test-lock 

执行lock操作:

nova lock d7873036-15b0-4a06-9507-999dbf097c62 

然后我们使用普通用户(非管理员)对虚拟机执行任意操作:

$ source openrc_demo 
$ nova reboot d7873036-15b0-4a06-9507-999dbf097c62 
Instance d7873036-15b0-4a06-9507-999dbf097c62 is locked (HTTP 409) (Request-ID: req-60271d7d-9afd-4ff4-a150-dfb632d5007f) 
ERROR (CommandError): Unable to reboot the specified server(s). 
$ nova delete d7873036-15b0-4a06-9507-999dbf097c62 
Instance d7873036-15b0-4a06-9507-999dbf097c62 is locked (HTTP 409) (Request-ID: req-3e63515b-6e2e-419a-8c91-b27b1a546f12) 
ERROR (CommandError): Unable to delete the specified server(s). 

另外需要强调的是，普通用户也可以执行lock操作，普通用户执行的lock，任意用户都可以unlock。但是如果是管理员执行的lock，默认policy情况下，普通用户不能执行unlock:

$ nova unlock d7873036-15b0-4a06-9507-999dbf097c62 
ERROR (Forbidden): Policy doesn't allow os_compute_api:os-lock-server:unlock:unlock_override to be performed. (HTTP 403) (Request-ID: req-9fabda60-4857-429e-ab1d-6ca6fb36844e)  

shelve

对于一些长期不用的虚拟机，即使关机了，仍然占用着资源，导致我们不能创建新的虚拟机。或者用户欠费时间很长了，又没有及时删掉虚拟机，导致一直占据着资源。此时我们可以通过shelve操作临时释放资源。

shelve操作的原理是先给虚拟机创建一个快照并上传到glance中，然后把虚拟机从OpenStack中删掉，从而释放所有资源。

nova shelve 5b540e93-e931-45ed-a7f3-1dc2e88d8d33 

shelve完成后我们查看虚拟机是否彻底从libvirt中删除:

$ nova list --fields id,name,status,instance_name 
+--------------------------------------+--------------------------------------+----------------------+-------------------+-------------------+ 
| ID                                   | Id                                   | Name                 | Status            | Instance Name     | 
+--------------------------------------+--------------------------------------+----------------------+-------------------+-------------------+ 
| 5b540e93-e931-45ed-a7f3-1dc2e88d8d33 | 5b540e93-e931-45ed-a7f3-1dc2e88d8d33 | int32ibt-test-shelve | SHELVED_OFFLOADED | instance-0000033b | 
+--------------------------------------+--------------------------------------+----------------------+-------------------+-------------------+ 
$ virsh list --all | grep instance-0000033b 

可以发现instance-0000033b已经删除了。

使用glance可以查看创建的快照:

$ glance image-list | grep shelved 
| 36d7d6a0-aa18-4373-ad79-afcae8609489 | int32ibt-test-shelve-shelved              | 

如果想恢复虚拟机，通过unshelve 完成，该操作基于快照重新启动虚拟机，并把快照删掉。

$ nova unshelve 5b540e93-e931-45ed-a7f3-1dc2e88d8d33 
$ nova list 
+--------------------------------------+----------------------+--------+------------+-------------+---------------------+ 
| ID                                   | Name                 | Status | Task State | Power State | Networks            | 
+--------------------------------------+----------------------+--------+------------+-------------+---------------------+ 
| 5b540e93-e931-45ed-a7f3-1dc2e88d8d33 | int32ibt-test-shelve | ACTIVE | -          | Running     | test-net=10.0.51.22 | 
+--------------------------------------+----------------------+--------+------------+-------------+---------------------+ 

rescue

我们经常在文件系统奔溃时，进入rescue模式修复，或者通过Live CD进入一个临时操作系统来修复奔溃的文件系统。

假如我们使用OpenStack启动的虚拟机出现问题导致启动不起来了，该怎么处理呢。

当然你可以把虚拟机的根磁盘挂载到本地(如果使用的是ceph，则直接通过rbd map)，然后在宿主机中修复。但是作为云提供商，显然是不可能这么做，否则用户的数据太不安全了。我们需要用户自己去修复。

Nova提供了rescue API，其实现原理和我们前面提到的方式基本一样，先来看看rescue子命令用法:

nova rescue [--password <password>] [--image <image>] <server> 

rescue会使用指定的image重新创建一个虚拟机，同时把原来的虚拟机根磁盘作为附加磁盘挂载到新创建的虚拟机，更确切地说是rebuild操作，它会重用原来虚拟机的信息，如flavor、network等。

注意：通过rescue新创建的虚拟机不支持指定keypair。rebuild也不支持，在前几天的邮件列表中有讨论这个问题，估计在Q版本中会实现。

我们尝试下

$ nova rescue  --image f0b1239a-bb34-4cfb-ad06-e18cbb8ee4b9 5b540e93-e931-45ed-a7f3-1dc2e88d8d33 
+-----------+--------------+ 
| Property  | Value        | 
+-----------+--------------+ 
| adminPass | 4mDD7BGsfvMN | 
+-----------+--------------+ 
$ nova list 
+--------------------------------------+------+--------+------------+-------------+---------------------+ 
| ID                                   | Name | Status | Task State | Power State | Networks            | 
+--------------------------------------+------+--------+------------+-------------+---------------------+ 
| 5b540e93-e931-45ed-a7f3-1dc2e88d8d33 | 2    | ACTIVE | rescuing   | Running     | test-net=10.0.51.22 | 
+--------------------------------------+------+--------+------------+-------------+---------------------+ 

当虚拟机rebuild完成后，查看其状态:

$ nova list 
+--------------------------------------+------+--------+------------+-------------+---------------------+ 
| ID                                   | Name | Status | Task State | Power State | Networks            | 
+--------------------------------------+------+--------+------------+-------------+---------------------+ 
| 5b540e93-e931-45ed-a7f3-1dc2e88d8d33 | 2    | RESCUE | -          | Running     | test-net=10.0.51.22 | 
+--------------------------------------+------+--------+------------+-------------+---------------------+ 

虚拟机状态变为RESCUE。

我们通过virsh查看挂载的block设备：

$ virsh domblklist 5b540e93-e931-45ed-a7f3-1dc2e88d8d33 
Target     Source 
------------------------------------------------ 
vda        /var/lib/nova/instances/5b540e93-e931-45ed-a7f3-1dc2e88d8d33/disk.rescue 
vdb        /var/lib/nova/instances/5b540e93-e931-45ed-a7f3-1dc2e88d8d33/disk 

其中disk.rescue是新创建虚拟机的临时根磁盘，disk是原来虚拟机的根磁盘。此时进入新创建的虚拟机，就可以对原来虚拟机的根磁盘进行操作了。

操作完成后，通过unrescue子命令恢复：

nova unrescue 5b540e93-e931-45ed-a7f3-1dc2e88d8d33 

unrescue会再次rebuild虚拟机，并重新使用之前的根磁盘作为根磁盘，删除前面创建的临时根磁盘。

Cinder

manage

Cinder创建一个volume时，通常会由后端存储系统负责创建一个volume，并与Cinder volume一一映射。

如果我们存储系统中已经有一些volume了，比如Ceph中已有的一些rbd image，如何让Cinder纳管起来呢?可幸的是，Cinder是支持导入OpenStack外部的一些存储数据卷，这个操作称为manage。接下来我们演示下这个过程。

假设我们使用的是LVM后端driver，首先我们创建一个LV:

$ lvcreate --name int32bit-test-LV --size 1G cinder-volumes 
  Logical volume "int32bit-test-LV" created. 
$ lvs | grep int32bit 
int32bit-test-LV                               cinder-volumes -wi-a-----  1.00g 

使用manage子命令创建volume:

$ cinder manage --name int32bit-test-manage 'devstack@lvm#cinder-volumes' int32bit-test-LV 
+--------------------------------+--------------------------------------+ 
|            Property            |                Value                 | 
+--------------------------------+--------------------------------------+ 
|          attachments           |                  []                  | 
|       availability_zone        |                 nova                 | 
|            bootable            |                false                 | 
|      consistencygroup_id       |                 None                 | 
|           created_at           |      2017-09-28T03:09:55.000000      | 
|          description           |                 None                 | 
|           encrypted            |                False                 | 
|               id               | 9394b827-4ad0-488e-8df8-26476b3a8662 | 
|            metadata            |                  {}                  | 
|        migration_status        |                 None                 | 
|          multiattach           |                False                 | 
|              name              |      int32bit-test-manage            | 
|     os-vol-host-attr:host      |     devstack@lvm#cinder-volumes      | 
| os-vol-mig-status-attr:migstat |                 None                 | 
| os-vol-mig-status-attr:name_id |                 None                 | 
|  os-vol-tenant-attr:tenant_id  |   42ee53fa480f49149ce5c3df4a953a6b   | 
|       replication_status       |                 None                 | 
|              size              |                  0                   | 
|          snapshot_id           |                 None                 | 
|          source_volid          |                 None                 | 
|             status             |               creating               | 
|           updated_at           |                 None                 | 
|            user_id             |   a61a3c0659bd4cca8cb5f66ea2fe3df7   | 
|          volume_type           |                 None                 | 
+--------------------------------+--------------------------------------+ 

以上两个参数，其中***个参数是host，注意Cinder的host格式为hostname@backend#pool，如果不清楚，使用admin账号show其中一个volume，查看其os-vol-host-attr:host。另一个参数为identifier，即后端存储数据卷名，对应LVM即LV name，对应Ceph rbd则为image name。

当volume状态变为available时，说明创建volume成功，并成功导入了指定的LV。

我们使用lvs查看我们创建的LV是否还存在:

$ lvs | grep int32bit 

我们发现创建的int32bit-test-LV不存在了，这是怎么回事呢?我们查看了源码如下:

def manage_existing(self, volume, existing_ref): 
   lv_name = existing_ref['source-name'] 
   self.vg.get_volume(lv_name) 
 
   if volutils.check_already_managed_volume(self.db, lv_name): 
       raise exception.ManageExistingAlreadyManaged(volume_ref=lv_name) 
 
   # Attempt to rename the LV to match the OpenStack internal name. 
   try: 
       self.vg.rename_volume(lv_name, volume['name']) 
   except processutils.ProcessExecutionError as exc: 
       exception_message = (_("Failed to rename logical volume %(name)s, " 
                              "error message was: %(err_msg)s") 
                            % {'name': lv_name, 
                               'err_msg': exc.stderr}) 
       raise exception.VolumeBackendAPIException( 
           data=exception_message) 

从源码中发现，Cinder会自动把LV重命名，与Cinder volume对应起来。由此可见manage和create***不同的是:

• create会调用后端driver创建一个volume。
• manage调用后端driver重命名一个volume。

当然，也有一个相反的操作，即unmanage，这个和delete操作基本一样，***不同的是，delete会调用后端存储把数据卷彻底删除，而unmanage只是删除volume数据库记录，并不会删除后端存储的数据卷。

不过Cinder目前还不支持import/export volume到本地，但其实当初manage功能就是为了实现import volume blue-print的，参考add export import volume.

local-attach

Cinder作为OpenStack的块存储服务，最典型的应用是挂载到OpenStack虚拟机中，当作虚拟硬盘使用。但volume能不能挂载到物理机呢，或者说挂载到宿主机呢?答案是可以!我们把volume挂载到本地，称为local attach。

不过默认的cinderclient没有local attach命令，我们需要安装cinderclient扩展包:

pip install python-brick-cinderclient-ext 

安装完后，可以发现cinder CLI多了两个子命令:

$ cinder --help | grep local local-attach 
local-detach 

下面演示如何把一个volume挂载到本地：

首先创建一个volume:

$ cinder create --volume-type lvm --name int32bit-test-local-attach 1 
+--------------------------------+--------------------------------------+ 
| Property                       | Value                                | 
+--------------------------------+--------------------------------------+ 
| attached_servers               | []                                   | 
| attachment_ids                 | []                                   | 
| availability_zone              | nova                                 | 
| bootable                       | false                                | 
| consistencygroup_id            | None                                 | 
| created_at                     | 2017-09-28T02:50:16.000000           | 
| description                    | None                                 | 
| encrypted                      | False                                | 
| id                             | af767c74-1902-4a7a-8fff-4ea68695a3f8 | 
| metadata                       | {}                                   | 
| migration_status               | None                                 | 
| multiattach                    | False                                | 
| name                           | int32bit-test-local-attach           | 
| os-vol-host-attr:host          | None                                 | 
| os-vol-mig-status-attr:migstat | None                                 | 
| os-vol-mig-status-attr:name_id | None                                 | 
| os-vol-tenant-attr:tenant_id   | ae21d957967d4df0865411f0389ed7e8     | 
| replication_status             | None                                 | 
| size                           | 1                                    | 
| snapshot_id                    | None                                 | 
| source_volid                   | None                                 | 
| status                         | creating                             | 
| updated_at                     | None                                 | 
| user_id                        | 70828c56f2844a9090d286c29a1fb599     | 
| volume_type                    | lvm                                  | 
+--------------------------------+--------------------------------------+ 

等待volume状态为available后，我们使用local-attach子命令挂载到本地:

$ cinder local-attach af767c74-1902-4a7a-8fff-4ea68695a3f8 
+----------+-----------------------------------+ 
| Property | Value                             | 
+----------+-----------------------------------+ 
| path     | /dev/sdb                          | 
| scsi_wwn | 360000000000000000e00000000010001 | 
| type     | block                             | 
+----------+-----------------------------------+ 

以上输出说明成功挂载volume到本地中，并映射为/dev/sdb。

我们安装文件系统并mount到本地:

$ mkfs.ext4 /dev/sdb 
mke2fs 1.42.13 (17-May-2015) 
Creating filesystem with 262144 4k blocks and 65536 inodes 
Filesystem UUID: 2a3fdcac-3a68-494a-830d-2bbebddaa875 
Superblock backups stored on blocks: 
        32768, 98304, 163840, 229376 
 
Allocating group tables: done 
Writing inode tables: done 
Creating journal (8192 blocks): done 
Writing superblocks and filesystem accounting information: done 
 
$ mount /dev/sdb /mnt 
$ ls /mnt 
lost+found 

此时我们可以把volume当作本地的一个硬盘使用了。可以使用local-detach子命令从本地中卸载volume。

transfer

我们知道Glance支持通过member把一个镜像分享给其它租户，自然想到的是，Cinder能不能把其中一个volume分享给其它租户呢?很遗憾，Cinder没有member的概念，即不支持通过member把一个volume共享给其它租户。

不过Cinder支持把一个volume的所有权转移给另一个租户，这种行为称为transfer。

首先我们在admin租户下创建一个volume:

cinder create --name int32bit-test-transfer 1 

此时我们在demo的租户下看不到刚刚创建的volume:

$ source  openrc_demo 
$ cinder list 
+----+--------+------+------+-------------+----------+-------------+ 
| ID | Status | Name | Size | Volume Type | Bootable | Attached to | 
+----+--------+------+------+-------------+----------+-------------+ 
+----+--------+------+------+-------------+----------+-------------+ 

在admin租户下创建一个transfer：

$ cinder transfer-create --name test-transfer int32bit-test-transfer 
+------------+--------------------------------------+ 
| Property   | Value                                | 
+------------+--------------------------------------+ 
| auth_key   | c259b651426121fd                     | 
| created_at | 2017-09-28T05:25:20.105051           | 
| id         | b03c0b07-1e1c-4df3-b096-be3c66b433f7 | 
| name       | test-transfer                        | 
| volume_id  | 093f41b1-39f9-4a01-bfb8-116baf1dbe2f | 
+------------+--------------------------------------+ 

以上输出的auth_key非常重要，并且只有创建的时候会输出，之后通过API就拿不到这个auth_key了。对方就是通过这个auth_key接收转移的。此时volume的状态将变为awaiting-transfer

在demo租户下accept:

$ cinder transfer-accept b03c0b07-1e1c-4df3-b096-be3c66b433f7 c259b651426121fd 
+-----------+--------------------------------------+ 
| Property  | Value                                | 
+-----------+--------------------------------------+ 
| id        | b03c0b07-1e1c-4df3-b096-be3c66b433f7 | 
| name      | test-transfer                        | 
| volume_id | 093f41b1-39f9-4a01-bfb8-116baf1dbe2f | 
+-----------+--------------------------------------+ 

其中***个参数为transfer id，第二个参数为auth_key。

我们在demo上查看volume:

$ cinder list 
+--------------------------------------+-----------+------------------------+------+-------------+----------+-------------+ 
| ID                                   | Status    | Name                   | Size | Volume Type | Bootable | Attached to | 
+--------------------------------------+-----------+------------------------+------+-------------+----------+-------------+ 
| 093f41b1-39f9-4a01-bfb8-116baf1dbe2f | available | int32bit-test-transfer | 1    | lvmdriver-1 | false    |             | 
+--------------------------------------+-----------+------------------------+------+-------------+----------+-------------+ 

可见该volume已经成功转接给demo租户。

需要注意的是，任何人拿到transfer_id和auth_key都可以接收转接的volume，因此注意auth_key保密。auth_key只能使用一次，完成交接后，对应的transfer实例将自动删除。

backup-export

Cinder backup可以把Cinder volume备份到远端的存储系统中，如Ceph、Swift等。但是backup的元数据怎么办呢，万一数据库记录丢失了，数据还是恢复不了。

有人可能会说，备份的时候不是会保存backup的元数据吗，为什么不用backup的元数据呢。这是因为并不是所有的备份都会在远端保存元数据，比如若cinder-volume和备份存储后端都是使用Ceph driver，则备份时直接使用rbd的import，不需要元数据，因此在备份的ceph中也不会保存元数据。

幸运的是，Cinder支持backup export，把metadata导出。

$ cinder --debug backup-export fcbbfcca-b83e-4fab-acb6-7dbbd017b151 
{ 
    "backup-record": { 
        "backup_service": "cinder.backup.drivers.swift", 
        "backup_url": "eyJzdGF0dXM...efQ==" 
    } 
} 

以上eyJzdGF0dXM...efQ==字符串很长，为了便于排版，省略了中间一大部分。输出的backup_url是一串字符串什么用途呢，我们查看源码:

def export_record(self, context, backup): 
# ... 
# Call driver to create backup description string 
try: 
   backup_service = self.service.get_backup_driver(context) 
   driver_info = backup_service.export_record(backup) 
   backup_url = backup.encode_record(driver_info=driver_info) 
   backup_record['backup_url'] = backup_url 
except Exception as err: 
   msg = six.text_type(err) 
   raise exception.InvalidBackup(reason=msg) 

我们从源码中发现export_record就是通过backup实例调用encode_record完成的，encode_record的作用很明显就是序列化过程，我们查看其源码:

@base.remotable 
def encode_record(self, **kwargs): 
    """Serialize backup object, with optional extra info, into a string.""" 
    # We don't want to export extra fields and we want to force lazy 
    # loading, so we can't use dict(self) or self.obj_to_primitive 
    record = {name: field.to_primitive(self, name, getattr(self, name)) 
              for name, field in self.fields.items()} 
    # We must update kwargs instead of record to ensure we don't overwrite 
    # "real" data from the backup 
    kwargs.update(record) 
    retval = jsonutils.dump_as_bytes(kwargs) 
    return base64.encode_as_text(retval) 

从源码中可以看出，首先把backup序列化为json格式，然后转化为base64，我可以验证下:

$ python 
Python 2.7.5 (default, Nov  6 2016, 00:28:07) 
[GCC 4.8.5 20150623 (Red Hat 4.8.5-11)] on linux2 
Type "help", "copyright", "credits" or "license" for more information. 
>>> import base64 
>>> base64.b64decode('eyJzdGF0dXM...fQ==') 
'{"status": "available", "temp_snapshot_id": null, "display_name": "2", "availability_zone": "nova", "deleted": false, "volume_id": "676ec7a5-d4ae-43d9-88cd-bd93dc143538", "restore_volume_id": null, "updated_at": "2017-08-30T05:56:47Z", "host": "devstack", "snapshot_id": null, "user_id": "a61a3c0659bd4cca8cb5f66ea2fe3df7", "service_metadata": "volume_676ec7a5-d4ae-43d9-88cd-bd93dc143538/20170830055626/az_nova_backup_fcbbfcca-b83e-4fab-acb6-7dbbd017b151", "id": "fcbbfcca-b83e-4fab-acb6-7dbbd017b151", "size": 1, "object_count": 22, "deleted_at": null, "container": "cinder-backup", "service": "cinder.backup.drivers.swift", "driver_info": {}, "created_at": "2017-08-30T05:56:23Z", "disk_size": 3444122, "display_description": "", "data_timestamp": "2017-08-30T05:56:23Z", "parent_id": null, "num_dependent_backups": 0, "fail_reason": null, "project_id": "42ee53fa480f49149ce5c3df4a953a6b", "temp_volume_id": null}' 

下面我们从数据库中删除该backup记录:

MariaDB [cinder]> delete from backups where id='fcbbfcca-b83e-4fab-acb6-7dbbd017b151'; 
Query OK, 1 row affected (0.00 sec) 

此时Cinder已经找不到该backup记录了:

$ cinder backup-show fcbbfcca-b83e-4fab-acb6-7dbbd017b151 
ERROR: No volumebackup with a name or ID of 'fcbbfcca-b83e-4fab-acb6-7dbbd017b151' exists. 

接下来我们使用backup-import恢复记录:

$ cinder backup-import cinder.backup.drivers.swift eyJzdGF0dXM...efQ== 
+------------+--------------------------------------+ 
|  Property  |                Value                 | 
+------------+--------------------------------------+ 
|     id     | fcbbfcca-b83e-4fab-acb6-7dbbd017b151 | 
|    name    |                 None                 | 
| parent_id  |                 None                 | 
| project_id |   42ee53fa480f49149ce5c3df4a953a6b   | 
+------------+--------------------------------------+ 

backup记录成功恢复：

$ cinder backup-show fcbbfcca-b83e-4fab-acb6-7dbbd017b151 
+-----------------------+--------------------------------------+ 
|        Property       |                Value                 | 
+-----------------------+--------------------------------------+ 
|   availability_zone   |                 nova                 | 
|       container       |            cinder-backup             | 
|       created_at      |      2017-08-30T05:56:23.000000      | 
|     data_timestamp    |      2017-08-30T05:56:23.000000      | 
|      description      |                                      | 
|       disk_size       |               3444122                | 
|      fail_reason      |                                      | 
| has_dependent_backups |                False                 | 
|           id          | fcbbfcca-b83e-4fab-acb6-7dbbd017b151 | 
|     is_incremental    |                False                 | 
|          name         |                  2                   | 
|      object_count     |                  22                  | 
|       parent_id       |                 None                 | 
|       project_id      |   42ee53fa480f49149ce5c3df4a953a6b   | 
|          size         |                  1                   | 
|      snapshot_id      |                 None                 | 
|         status        |              available               | 
|       updated_at      |      2017-08-30T05:56:47.000000      | 
|       volume_id       | 676ec7a5-d4ae-43d9-88cd-bd93dc143538 | 
+-----------------------+--------------------------------------+ 

总结

以上我们介绍了OpenStack的一些非常有用的操作，主要包括如下:

• glance member
• glance task
• nova lock
• nova shelve
• nova rescue
• cinder manage
• cinder local-attach
• cinder backup-export
• cinder transfer

以后发现有新的有意思的操作，再补充。

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

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