强制删除 OpenStack Nova (Essex) 实例
2012年07月26日 | 标签: openstack nova | 作者:vpsee
上周在新版的 OpenStack (Essex) 上测了瞬间启动1000个 m1.tiny (512mb RAM) 实例的情况,主要看看 OpenStack 能否在短时间内正确处理大量创建实例请求以及各个节点、资源分配等情况。结果留下了大量状态为 ERROR 或 BUILD 的僵尸实例,这个结果和上个版本 Diablo 测试的情况差不多,没有明显改进,进一步调查发现主要原因在 RabbitMQ 服务,中途有很多连接都 timeout 了。这些僵尸实例没有运行或者创建不成功,只是在 nova 数据库里有纪录而已,直接用 nova delete 命令无法删除,那么如何强制删除呢?
# nova list +--------------------------------------+--------+--------+-------------------+ | ID | Name | Status | Networks | +--------------------------------------+--------+--------+-------------------+ | 6fc5696c-ed65-4e99-8fce-87dfc3cf36d9 | c23 | BUILD | private=10.0.0.23 | | 98f5f421-581f-43d2-b1c7-f27cf5b61f02 | c30 | BUILD | private=10.0.0.30 | | b768ebeb-4d73-4c31-8ec5-6bb2e90d4303 | c63 | ERROR | private=10.0.0.63 | | b79e213b-055c-414f-a9f1-f230ed9aaae1 | c95 | ERROR | private=10.0.0.95 | | efc6e9c7-4ef8-4350-9451-83bcfcafe101 | c12 | ACTIVE | private=10.0.0.12 | +--------------------------------------+--------+--------+-------------------+
先清理 instances 目录,看看对应的哪些 instance 是僵尸实例,有的话 rm -rf 删除即可:
# ls /var/lib/nova/instances/ _base instance-00000023 instance-00000030 # rm -rf /var/lib/nova/instances/instance-00000023
然后清理 nova 数据库,可以登陆数据库后手动删除纪录,不过这是常见操作,最好还是保存成一个脚本方便以后使用:
# vi deletevm.sh #!/bin/bash mysql -uroot << EOF use nova; DELETE a FROM nova.security_group_instance_association AS a INNER JOIN nova.instances AS b ON a.instance_id=b.id where b.uuid='$1'; DELETE FROM nova.instance_info_caches WHERE instance_id='$1'; DELETE FROM nova.instances WHERE uuid='$1'; EOF # chmod +x deletevm.sh
8月15日更新,才过了不到一个月,OpenStack 又更改了数据库表结构和字段,上面的脚本改为:
#!/bin/bash mysql -uroot << EOF use nova; DELETE FROM nova.security_group_instance_association where instance_uuid='$1'; DELETE FROM nova.instance_info_caches WHERE instance_uuid='$1'; DELETE FROM nova.instances WHERE uuid='$1'; EOF
运行脚本,比如删除 ID 为 6fc5696c-ed65-4e99-8fce-87dfc3cf36d9 的实例:
# ./deletevm.sh 6fc5696c-ed65-4e99-8fce-87dfc3cf36d9 # nova list +--------------------------------------+--------+--------+-------------------+ | ID | Name | Status | Networks | +--------------------------------------+--------+--------+-------------------+ | 98f5f421-581f-43d2-b1c7-f27cf5b61f02 | c30 | BUILD | private=10.0.0.30 | | b768ebeb-4d73-4c31-8ec5-6bb2e90d4303 | c63 | ERROR | private=10.0.0.63 | | b79e213b-055c-414f-a9f1-f230ed9aaae1 | c95 | ERROR | private=10.0.0.95 | | efc6e9c7-4ef8-4350-9451-83bcfcafe101 | c12 | ACTIVE | private=10.0.0.12 | +--------------------------------------+--------+--------+-------------------+
旧版本的 OpenStack (Diablo) 可以参考:如何删除 OpenStack Nova 僵尸实例。
这是不是说OpenStack还很不成熟呢?
openstack问题很多,期待下一个版本
确实,我也测试过,同时开20个就会出现这个问题。不知道新的版本会不会改进。这次亚太峰会,老哥你去吗?
博主,你的代码高亮用的什么插件?
@平阳
不去:(,主办方联系过一次,然后就没下文了~
@heaphy
?没有用插件,本博客代码也没有高亮啊。
我用我们自己的产品,同时发送1000个VM的请求,base image 是60G的rhel6, 有997个在30秒内正常起来显示获得IP了,hypervisor 是KVM, physical machine是40台idataplax.
vpsee大师,有个openstack存储相关的问题一直想搞清楚,就是各个计算节点是否可以共享iscsi或fc或nfs存储,实例镜像也在共享存储上面;另外就是实例与nova-volume之间的存储连接如果必须通过一台物理主机,那nova-volume有群集方案吗,否则规模扩大后如何承载呢?
@renni
存储方案组合起来有很多种,我们采用 SAN,nova-volume 独立运行在一个台服务器上,然后在 SAN 上分一块给这个 nova-volume 服务用,这样所有需要额外存储的虚拟机都相当于从 SAN 里 “取” 硬盘。这种方案简单、可靠、稳定、而且支持热迁移。如果要集群的话,可以用 Ceph, Sheepdog 等分布式文件集群系统做 nova-volume.
实例可以通过nfs等方式运行在共享存储上面,这一点明白了。
但是nova-volume相当于只能用一台服务器做san的前端,怎能满足众多实例的存储需求呢?
@renni
别忘了 nova-volume 还可以运行在多个节点上(理论上,没试过),每个 nova-compute 都可以放 nove-volume,compute 和 volume 在同一个机器上运行,只不过这个配置不推荐而且配置和操作起来都很复杂。openstack 正在把 nova-volume 单独剥离出来为一个新项目 openstack cinder,可能会有改善。
nova-volume和nova-compute一样可以部署在多个节点上,也和nova-compute一样有调度算法,我已经试过。vpsee大师,我想问一下你配置过vpn-instance?
@tinny77
vpn-instance? 没
请问一下,openstack上面删除了实例,但是貌似实例还存在在某个地方占着空间,怎么办啊,最搞笑的是,查看实例已经一个都没有了啊