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

背景 //www.greatytc.com/p/56ea47e91b74

上回通过操作数据库删除了一个“自认为”多余的 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是一种扁平化的架构，用来在集群节点扩张时，降低数据库和消息队列访问瓶颈的。

参考 //www.greatytc.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 \u3002
2018-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_instances
2018-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_instances
2018-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 wrapped
2018-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_destinations
2018-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_method
2018-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_destinations
2018-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_destinations
2018-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 call
2018-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 _send
2018-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 send
2018-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 _send
2018-12-27 15:05:44.860 31027 ERROR nova.conductor.manager     raise result
2018-12-27 15:05:44.860 31027 ERROR nova.conductor.manager NoValidHost_Remote: \u627e\u4e0d\u5230\u6709\u6548\u4e3b\u673a\uff0c\u539f\u56e0\u662f \u3002
2018-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
2018-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 inner
2018-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
2018-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_destinations
2018-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.manager
2018-12-27 15:05:44.860 31027 ERROR nova.conductor.manager NoValidHost: \u627e\u4e0d\u5230\u6709\u6548\u4e3b\u673a\uff0c\u539f\u56e0\u662f \u3002
2018-12-27 15:05:44.860 31027 ERROR nova.conductor.manager
2018-12-27 15:05:44.860 31027 ERROR nova.conductor.manager
2018-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 \u3002
2018-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 id
gAAAAABcJZlJ1dBRNYO2994is9JdT7XYnL-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怎么使用，日后再说。

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

最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 217,542评论 6赞 504
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 92,822评论 3赞 394
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 163,912评论 0赞 354
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 58,449评论 1赞 293
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 67,500评论 6赞 392
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 51,370评论 1赞 302
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 40,193评论 3赞 418
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 39,074评论 0赞 276
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 45,505评论 1赞 314
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,722评论 3赞 335
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,841评论 1赞 348
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 35,569评论 5赞 345
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 41,168评论 3赞 328
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,783评论 0赞 22
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,918评论 1赞 269
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 47,962评论 2赞 370
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 44,781评论 2赞 354

推荐阅读更多精彩内容

  • Openstack 安装
    1.环境准备 centos7 1.1、yum安装设置 yum list |grep openstackcentos...
    davisgao阅读 5,483评论 1赞 16
  • OpenStack
    第一章 OpenStack基础 OpenStack管理的资源及提供的服务OpenStack做为一个操作系统，...
    sgt_tiger阅读 12,919评论 4赞 72
  • nova cell v2原理及流程
    为什么要引入nova cells 主要是为了降低数据库和消息队列的访问瓶颈。对于云端架构来说，它默认拥有非常大的资...
    JohnLee1100阅读 4,789评论 0赞 2
  • OpenStack组件 Nova
    都是自己的学习笔记，仅供参考。 核心模块-Nova简介 管理instance生命周期生成，调度，终止实例作用：处理...
    廖马儿阅读 3,562评论 0赞 3
  • 没出息的我又哭了
    下午偶然拿起小手机，发现打不开，原来是没电了，充好电后刚刚查了下话费，每个月可用59的可用余额居然还有57.48，...
    把泪化作相思雨阅读 288评论 0赞 0