排错经历接上回（cell、placement）

上回通过操作数据库删除了一个“自认为”多余的 cell，怎么删的呢？简单回顾下，先删了 nova_api 数据库里 instance_mappings 里的 instance，再删了 cell_mappings 里面的 cell。

当时还洋洋得意以为解决了一个大问题，睡前越想越觉得不对劲，我居然动了instance_mappings 表，万一里面存了什么重要信息怎么办？

果然自食其果了，在horizon界面上查看不了虚拟机详情了，也无法操作虚拟机了。。。

且看下面

1. 消失的虚拟机

无法点开虚拟机查看详情

provider0.png

错误：无法获取实例 "2f565c93-6eec-4a74-b8e8-f55638b56da3" 的详情。

在控制节点上查看

tail /var/log/httpd/error_log

provider1.png

NotFound: Instance 2f565c93-6eec-4a74-b8e8-f55638b56da3 could not be found. (HTTP 404) (Request-ID: req-999c856a-e2b6-4360-9fba-3bf8db6e283f)

看到这样的提示，一般是出现僵尸实例了，但它确实运行着，还连得上去呢：

provider2.png

数据库里也有：

provider3.png

不行了，赶快学一下 cell 的知识。在目前的Pike版本，cell版本为v2版本，简单的说，cell_v2是一种扁平化的架构，用来在集群节点扩张时，降低数据库和消息队列访问瓶颈的。

参考 https://www.jianshu.com/p/653e43a02ddc

cell的相关数据表在nova_api中，看到这张图就明白了：

provider4.png

虚拟机在 instance_mappings 表里，计算节点在 host_mappings 表里，cell 在 cell_mappings表里。

当想要获取一个机器的详细信息时 :

1.nova-api 先从 instance_mappings 表拿到 instance 的 cell_id

2.再从 cell_mappings 表拿到所在 cell 的 DB connection

3.直接连接 cell 的 DB 拿到机器的详细信息

还记得之前为了删除多余的 cell，在nova_api 的 instance_mappings 里删了n多条记录吗？

这个虚拟机之前在 instance mapping 表里，但被删了，再也找不回来了……

所以说，没事还是别动数据库，动之前一定要备份！！！

发生了这种操作真的该敲警钟了，要是在公司可以直接卷铺盖了》》》》

2. 神奇的NoValidHost(reason="")

也就是做以上改动的前后，环境里突然创建不起虚拟机了，连 1GRam/1VCPU/10GBDisk 都创不起来，而且控制节点中除了 /var/log/nova/nova-conducter.log 中以下log，/var/log/nova/nova-scheduler.log 中几乎没有有用的信息，看不出nova filter的过滤log。

(奇怪的是，210mbRam/1VCPU/10GBDisk 是创的起来了，但当时并没有怀疑到内存真的不够了)

/var/log/nova/nova-conducter.log 中日志如下：

2018-12-27 15:05:44.860 31027 ERROR nova.conductor.manager [req-49530488-2149-4f15-85ea-5659267ffada 8668aa3368c0427c98b1d1824a36f720 f30a92c42d264a79ba5744b084346a2d - default default] Failed to schedule instances: NoValidHost_Remote: \u627e\u4e0d\u5230\u6709\u6548\u4e3b\u673a\uff0c\u539f\u56e0\u662f \u3002
Traceback (most recent call last):

  File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/server.py", line 232, in inner    return func(*args, **kwargs)

  File "/usr/lib/python2.7/site-packages/nova/scheduler/manager.py", line 138, in select_destinations
    raise exception.NoValidHost(reason="")

NoValidHost: \u627e\u4e0d\u5230\u6709\u6548\u4e3b\u673a\uff0c\u539f\u56e0\u662f \u30022018-12-27 15:05:44.860 31027 ERROR nova.conductor.manager Traceback (most recent call last):2018-12-27 15:05:44.860 31027 ERROR nova.conductor.manager   File "/usr/lib/python2.7/site-packages/nova/conductor/manager.py", line 1072, in schedule_and_build_instances2018-12-27 15:05:44.860 31027 ERROR nova.conductor.manager     instance_uuids)2018-12-27 15:05:44.860 31027 ERROR nova.conductor.manager   File "/usr/lib/python2.7/site-packages/nova/conductor/manager.py", line 636, in _schedule_instances2018-12-27 15:05:44.860 31027 ERROR nova.conductor.manager     request_spec, instance_uuids)2018-12-27 15:05:44.860 31027 ERROR nova.conductor.manager   File "/usr/lib/python2.7/site-packages/nova/scheduler/utils.py", line 586, in wrapped2018-12-27 15:05:44.860 31027 ERROR nova.conductor.manager     return func(*args, **kwargs)2018-12-27 15:05:44.860 31027 ERROR nova.conductor.manager   File "/usr/lib/python2.7/site-packages/nova/scheduler/client/__init__.py", line 52, in select_destinations2018-12-27 15:05:44.860 31027 ERROR nova.conductor.manager     instance_uuids)2018-12-27 15:05:44.860 31027 ERROR nova.conductor.manager   File "/usr/lib/python2.7/site-packages/nova/scheduler/client/__init__.py", line 37, in __run_method2018-12-27 15:05:44.860 31027 ERROR nova.conductor.manager     return getattr(self.instance, __name)(*args, **kwargs)2018-12-27 15:05:44.860 31027 ERROR nova.conductor.manager   File "/usr/lib/python2.7/site-packages/nova/scheduler/client/query.py", line 33, in select_destinations2018-12-27 15:05:44.860 31027 ERROR nova.conductor.manager     instance_uuids)2018-12-27 15:05:44.860 31027 ERROR nova.conductor.manager   File "/usr/lib/python2.7/site-packages/nova/scheduler/rpcapi.py", line 137, in select_destinations2018-12-27 15:05:44.860 31027 ERROR nova.conductor.manager     return cctxt.call(ctxt, 'select_destinations', **msg_args)2018-12-27 15:05:44.860 31027 ERROR nova.conductor.manager   File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/client.py", line 169, in call2018-12-27 15:05:44.860 31027 ERROR nova.conductor.manager     retry=self.retry)2018-12-27 15:05:44.860 31027 ERROR nova.conductor.manager   File "/usr/lib/python2.7/site-packages/oslo_messaging/transport.py", line 123, in _send2018-12-27 15:05:44.860 31027 ERROR nova.conductor.manager     timeout=timeout, retry=retry)2018-12-27 15:05:44.860 31027 ERROR nova.conductor.manager   File "/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py", line 566, in send2018-12-27 15:05:44.860 31027 ERROR nova.conductor.manager     retry=retry)2018-12-27 15:05:44.860 31027 ERROR nova.conductor.manager   File "/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py", line 557, in _send2018-12-27 15:05:44.860 31027 ERROR nova.conductor.manager     raise result2018-12-27 15:05:44.860 31027 ERROR nova.conductor.manager NoValidHost_Remote: \u627e\u4e0d\u5230\u6709\u6548\u4e3b\u673a\uff0c\u539f\u56e0\u662f \u30022018-12-27 15:05:44.860 31027 ERROR nova.conductor.manager Traceback (most recent call last):2018-12-27 15:05:44.860 31027 ERROR nova.conductor.manager2018-12-27 15:05:44.860 31027 ERROR nova.conductor.manager   File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/server.py", line 232, in inner2018-12-27 15:05:44.860 31027 ERROR nova.conductor.manager     return func(*args, **kwargs)2018-12-27 15:05:44.860 31027 ERROR nova.conductor.manager2018-12-27 15:05:44.860 31027 ERROR nova.conductor.manager   File "/usr/lib/python2.7/site-packages/nova/scheduler/manager.py", line 138, in select_destinations2018-12-27 15:05:44.860 31027 ERROR nova.conductor.manager     raise exception.NoValidHost(reason="")2018-12-27 15:05:44.860 31027 ERROR nova.conductor.manager2018-12-27 15:05:44.860 31027 ERROR nova.conductor.manager NoValidHost: \u627e\u4e0d\u5230\u6709\u6548\u4e3b\u673a\uff0c\u539f\u56e0\u662f \u30022018-12-27 15:05:44.860 31027 ERROR nova.conductor.manager2018-12-27 15:05:44.860 31027 ERROR nova.conductor.manager2018-12-27 15:05:45.321 31027 WARNING oslo_config.cfg [req-49530488-2149-4f15-85ea-5659267ffada 8668aa3368c0427c98b1d1824a36f720 f30a92c42d264a79ba5744b084346a2d - default default] Option "enable" from group "cells" is deprecated for removal (Cells v1 is being replaced with Cells v2.).  Its value may be silently ignored in the future.2018-12-27 15:05:45.402 31027 WARNING nova.scheduler.utils [req-49530488-2149-4f15-85ea-5659267ffada 8668aa3368c0427c98b1d1824a36f720 f30a92c42d264a79ba5744b084346a2d - default default] Failed to compute_task_build_instances: 找不到有效主机，原因是 。
Traceback (most recent call last):

  File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/server.py", line 232, in inner    return func(*args, **kwargs)

  File "/usr/lib/python2.7/site-packages/nova/scheduler/manager.py", line 138, in select_destinations
    raise exception.NoValidHost(reason="")

NoValidHost: \u627e\u4e0d\u5230\u6709\u6548\u4e3b\u673a\uff0c\u539f\u56e0\u662f \u3002
: NoValidHost_Remote: \u627e\u4e0d\u5230\u6709\u6548\u4e3b\u673a\uff0c\u539f\u56e0\u662f \u3002
Traceback (most recent call last):

  File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/server.py", line 232, in inner    return func(*args, **kwargs)

  File "/usr/lib/python2.7/site-packages/nova/scheduler/manager.py", line 138, in select_destinations
    raise exception.NoValidHost(reason="")

NoValidHost: \u627e\u4e0d\u5230\u6709\u6548\u4e3b\u673a\uff0c\u539f\u56e0\u662f \u30022018-12-27 15:05:45.403 31027 WARNING nova.scheduler.utils [req-49530488-2149-4f15-85ea-5659267ffada 8668aa3368c0427c98b1d1824a36f720 f30a92c42d264a79ba5744b084346a2d - default default] [instance: c2963f0d-370c-43aa-8cee-0131760d6ef2] Setting instance to ERROR state.: NoValidHost_Remote: \u627e\u4e0d\u5230\u6709\u6548\u4e3b\u673a\uff0c\u539f\u56e0\u662f \u3002

我查了下，几个计算节点的内存、vcpu数、磁盘绝对够用，为啥它就报 NoValidHost 的错？而且 reason="" ?

我跟着日志中报错的代码一个文件一个文件的看，直到在 /usr/lib/python2.7/dist-packages/nova/scheduler/manager.py 的第138行之上看到了这条：

provider5.png

"Got no allocation candidates from the Placement ""API. This may be a temporary occurrence as compute ""nodes start up and begin reporting inventory to ""the Placement service."

谷歌了一下，看了某些回复，答案的天平逐渐倾向了我最不敢相信的一处：是资源不够。

我看着这张图擦着眼睛，真的是资源不够吗？

provider6.png

等等，allocation candidates ，Placement API，这些都是什么东西？我要创个虚拟机跟它们都有什么关系？

是时候学习一下了，原来，OpenStack现在使用 placement 来记录跟踪资源提供者的库存和使用情况，并使用CPU、内存和磁盘来标记资源类型。

参考 https://blog.csdn.net/jmilk/article/details/81264240

于是，我来到了数据库。

在 nova_api 数据库的 inventories 表中，我们可以看到每个 资源提供者（resource_provider） 提供三种资源，分别用resource_class_id的0、1、2标记cpu、内存和磁盘。total一列是资源总量，reserved是保留大小，allocation_ratio是资源超配比。

provider7.png

在 allocations 表中：

消费者（虚拟机）15372401-e970-4594-bc19-e65bac9613b8 使用了资源提供者1的1VCPU、1024MB内存、10G磁盘

消费者 01b6377f-5b0c-4273-a24a-921f793b3004 使用了资源提供者3的1VCPU、1024MB内存、10G磁盘，还使用了资源提供者1的1VCPU、1024MB内存、10G磁盘！

鬼鬼，还会分身术，一个人占两份资源？

provider8.png

赶紧数据库中查一下：

provider9.png

没这号人物啊？怎么回事？

我猜可能是这位仁兄在两台计算节点间迁移出错，成为僵尸实例，我在nova数据库的instances表中虽然把它删除了，但它还留在nova_api表里，占用着资源。

看了下，allocations表中共245条记录，怎么不是3的倍数？

provider10.png

于是我找到了它，也是够孤单的：

provider11.png

除去这条记录，表中大约有80台虚拟机，还有很多虚拟机和上面一样，一个人占用着两份资源。这些虚拟机的绝大部分在horizon里看不到，只是在背后默默地吃着资源，导致我现在连一台1VCPU、1024MB内存、10G磁盘的虚拟机都创不起来了……

数据库之旅到此结束，我们还可以用另一种方法查看一下每个资源提供者具体的资源使用情况:

1.获得placement服务的访问入口

openstack catalog list
root@controller:~# openstack catalog list+------------+----------------+------------------------------------------------------------------------+| Name       | Type           | Endpoints                                                              |+------------+----------------+------------------------------------------------------------------------+|            |                |                                                                        || placement  | placement      | RegionOne                                                              ||            |                |   public: http://controllerv:8778                                      ||            |                | RegionOne                                                              ||            |                |   admin: http://controllerv:8778                                       ||            |                | RegionOne                                                              ||            |                |   internal: http://controllerv:8778                                    ||            |                |                                                                        |

2.将访问入口写入变量

PLACEMENT_ENDPOINT=http://controllerv:8778

3.获得token

root@controller:~# openstack token issue -f value -c idgAAAAABcJZlJ1dBRNYO2994is9JdT7XYnL-IqcbZrkg_Sf9oZChTWwNjZG1HWV4KYTjVoxs82RP77lMHtud4NTgPEREK7LiDdSp2ABuw4pKlmi8ce8Z77uQueeeXNOAlzX6iXYIBJHDBuXTcjRTnKebNQdB57tw_OwRMufVIrPN4LMMpvCFFN10

4.将token写入变量

TOKEN=gAAAAABcJZlJ1dBRNYO2994is9JdT7XYnL-IqcbZrkg_Sf9oZChTWwNjZG1HWV4KYTjVoxs82RP77lMHtud4NTgPEREK7LiDdSp2ABuw4pKlmi8ce8Z77uQueeeXNOAlzX6iXYIBJHDBuXTcjRTnKebNQdB57tw_OwRMufVIrPN4LMMpvCFFN10

5.查看资源提供者

curl ${PLACEMENT_ENDPOINT}/resource_providers -H "x-auth-token: $TOKEN" | python -m json.tool

provider12.png

6.查看资源提供者库存

如查看 b266b258-d78d-414c-a71d-1bf5137abbe2 即上图compute1的资源库存：

curl ${PLACEMENT_ENDPOINT}/resource_providers/b266b258-d78d-414c-a71d-1bf5137abbe2/inventories -H "x-auth-token: $TOKEN" | python -m json.tool

provider13.png

7.查看资源提供者资源使用情况

如查看 b266b258-d78d-414c-a71d-1bf5137abbe2 即compute1的资源使用情况：

curl ${PLACEMENT_ENDPOINT}/resource_providers/b266b258-d78d-414c-a71d-1bf5137abbe2/usages -H "x-auth-token: $TOKEN" | python -m json.tool

provider14.png

什么？内存都使用了11426MB了？总共才7841MB啊！我掏出计算器，乘一下超配比：

7841 * 1.5 = 11761.5

11761.5 - 11426 - 512（保留大小） = -176.5 ？？？

怪不得创不出虚拟机了，内存不够啊！

又按照这个方法，查了别的资源提供者（即计算节点），发现几乎都是内存不够，有太多horizon上看不到的虚拟机在背后尸位素餐了！

该做一次全面清洗了！

怎么办？先查，查出哪些虚拟机是没用的，得到它们的ID，然后，删！

比如那个一人占用两份资源的仁兄 01b6377f-5b0c-4273-a24a-921f793b3004，先拿它开刀！

怎么删？

curl ${PLACEMENT_ENDPOINT}/allocations/01b6377f-5b0c-4273-a24a-921f793b3004 -H "x-auth-token: $TOKEN" -X DELETE

再看一下compute1的使用情况：

provider15.png

对比一下，心情舒爽多了！

继续删吧，唉。。。

3. 分析NoValidHost(reason="")

在placement的官方文档上写着这么一段
https://docs.openstack.org/nova/rocky/user/placement.html

provider16.png

大意是nova的scheduler调度从placement服务获取资源分配候选人

scheduler从placement api获取资源分配候选人后用它从cell里取到计算节点，计算节点通过筛选后，scheduler遍历通过筛选的计算节点列表，并尝试在placement api中声明要占用这些资源。

声明资源包括找到符合虚拟机所需资源的资源分配候选人（即计算节点），并要求placement api分配这些所需资源，当在声明资源过程中资源分配候选人用尽，就报出NoValidHost错误。

哦哦哦。。。

再看一张图理解一下：

provider17.png

好了，基本明白了。

在清理了一些废弃的虚拟机后，根据官网文档，可查询是否能提供资源：

provider18.png

查询一下，失败了，试了很多次，不知道怎么用。。。

curl ${PLACEMENT_ENDPOINT}/resource_providers?resources=VCPU:2,MEMORY_MB:1024,DISK_GB:50 -H "x-auth-token: $TOKEN"

provider19.png

算了，反正虚拟机已经可以创起来了。这个API怎么使用，日后再说。

另外，数据库里那么多尸位素餐的虚拟机是怎么产生的，为什么没被删掉，还要好好追查一下，再研究下吧》》》》》》》》

作者：Murray66
链接：https://www.jianshu.com/p/48e1451cf7dc