疑难杂症——解决 Cinder 僵尸卷问题
目录
问题描述
Cinder 的僵尸卷一般是因为操作不当导致分配的卷无法正常使用且无法正常分离或删除.
问题解决
解决僵尸卷问题的思路类似解决 Linux 系统中的僵尸进程, 需要手动的通过修改数据库和执行 CLI 来实现.
- 使用 CLI 定位僵尸卷的基本信息
最主要的是要获取其 id, 然后到数据库中查看其详细信息.
stack@fanguiju-dev:~$ openstack volume list
+--------------------------------------+--------------+--------+------+-----------------------------------------------------------+
| ID | Display Name | Status | Size | Attached to |
+--------------------------------------+--------------+--------+------+-----------------------------------------------------------+
| 0d71a98a-0d2c-4b73-9886-a98005d9f969 | mysql-vol | in-use | 5 | Attached to e1fd229f-413e-49dd-a741-1bbffa7f249c on /mnt |
+--------------------------------------+--------------+--------+------+-----------------------------------------------------------+可以看出这次的问题的原因是因为使用 openstackclient 挂载卷到 Instance 的时候指定了错误设配(/mnt), 应该指定挂载设备为(/dev/vdX). 而且使用 CLI 的 –force 也无法强制删除:
stack@fanguiju-dev:~$ openstack volume delete 0d71a98a-0d2c-4b73-9886-a98005d9f969 --force
Invalid volume: Volume must not be migrating, attached, belong to a consistency group or have snapshots. (HTTP 400) (Request-ID: req-8ec31dac-591a-4895-942d-3e4998c5407d)- 手动的修改 cinder 数据库的表 volumes 的 status 字段为 deleted
在挂载完卷之后该记录的字段 status 的值为 in-use.
*************************** 2. row ***************************
created_at: 2017-01-18 14:59:38
updated_at: 2017-01-18 16:12:09
deleted_at: NULL
deleted: 0
id: 0d71a98a-0d2c-4b73-9886-a98005d9f969
ec2_id: NULL
user_id: b03df4585b7d41cca635ec341217404d
project_id: d0f2734c0cd3421eaab8e7d3da5b61d1
host: fanguiju-dev@lvmdriver-1#lvmdriver-1
size: 5
availability_zone: nova
status: in-use
attach_status: attached
scheduled_at: 2017-01-18 14:59:39
launched_at: 2017-01-18 14:59:40
terminated_at: NULL
display_name: mysql-vol
display_description: backup volume of mysql server.
provider_location: 200.21.18.30:3260,2 iqn.2010-10.org.openstack:volume-0d71a98a-0d2c-4b73-9886-a98005d9f969 1
provider_auth: CHAP xvATFN4UYj3ueGXZBW5P aTsMksaXX6KSsw8n
snapshot_id: NULL
volume_type_id: 2fac34b8-f25c-490c-b0bb-6989d4778432
source_volid: NULL
bootable: 0
provider_geometry: NULL
_name_id: NULL
encryption_key_id: NULL
migration_status: NULL
replication_status: disabled
replication_extended_status: NULL
replication_driver_data: NULL
consistencygroup_id: NULL
provider_id: NULL
multiattach: 0
previous_status: NULL手动修改其 status 字段值:
mysql> update volumes set status='deleted' where id='0d71a98a-0d2c-4b73-9886-a98005d9f969';
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0- 执行指令删除卷
同样的, 在删除之前先要查看现在逻辑卷的使用情况.
stack@fanguiju-dev:~$ sudo vgs
VG #PV #LV #SN Attr VSize VFree
cinder-volumes-default 1 0 0 wz--n- 50.00g 50.00g
cinder-volumes-lvmdriver-1 1 1 0 wz--n- 50.00g 45.00g
ubuntu-dev-fanguiju-vg 1 2 0 wz--n- 99.76g 20.00m
stack@fanguiju-dev:~$ sudo lvs
LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert
volume-0d71a98a-0d2c-4b73-9886-a98005d9f969 cinder-volumes-lvmdriver-1 -wi-a---- 5.00g
root ubuntu-dev-fanguiju-vg -wi-ao--- 95.74g
swap_1 ubuntu-dev-fanguiju-vg -wi-ao--- 4.00g 通过 volume 的 id(0d71a98a-0d2c-4b73-9886-a98005d9f969) 我们不能判断出现问题的 lv 就是 /dev/cinder-volumes-lvmdriver-1/volume-0d71a98a-0d2c-4b73-9886-a98005d9f969.
但是在删除该 lv 之前, 我们需要保证该 lv 没有被任何的进程占用.
stack@fanguiju-dev:~$ lsof /dev/cinder-volumes-lvmdriver-1/volume-0d71a98a-0d2c-4b73-9886-a98005d9f969 使用 lsof 指令可以获取使用该设备的进程列表, 如果被占用的话, 需要使用 kill 指令来将这些进程杀掉. 之后再将该 lv remove 掉.
stack@fanguiju-dev:~$ sudo lvremove /dev/cinder-volumes-lvmdriver-1/volume-0d71a98a-0d2c-4b73-9886-a98005d9f969
Do you really want to remove and DISCARD active logical volume volume-0d71a98a-0d2c-4b73-9886-a98005d9f969? [y/n]: y
Logical volume "volume-0d71a98a-0d2c-4b73-9886-a98005d9f969" successfully removed
因为该僵尸卷在数据库中记录的状态已经修改为了 deleted, 所以 dashboard 不会读取该记录, 而且又使用了 lvremove 来将该逻辑卷删除了, 所以也算彻底的解决了这个问题.
最后
最后记录一下, 如果使用 cinderclient 包提供的 cinderclient.v2.volumes:VolumeManager.attach 来挂载卷的话, 其参数 mountpoint 的含义是指定该卷挂载到 Instance 的那一个设备文件上, 而不是指定挂载目录路径.
