背景 http://www.reibang.com/p/56ea47e91b74
上回通過操作數(shù)據(jù)庫刪除了一個“自認為”多余的 cell格遭,怎么刪的呢狠鸳?簡單回顧下揣苏,先刪了 nova_api
數(shù)據(jù)庫里 instance_mappings
里的 instance,再刪了 cell_mappings
里面的 cell碰煌。
當時還洋洋得意以為解決了一個大問題舒岸,睡前越想越覺得不對勁,我居然動了instance_mappings
表芦圾,萬一里面存了什么重要信息怎么辦蛾派?
果然自食其果了,在horizon界面上查看不了虛擬機詳情了,也無法操作虛擬機了洪乍。眯杏。。
且看下面
1. 消失的虛擬機
無法點開虛擬機查看詳情
錯誤:無法獲取實例 "2f565c93-6eec-4a74-b8e8-f55638b56da3" 的詳情壳澳。
在控制節(jié)點上查看
tail /var/log/httpd/error_log
NotFound: Instance 2f565c93-6eec-4a74-b8e8-f55638b56da3 could not be found. (HTTP 404) (Request-ID: req-999c856a-e2b6-4360-9fba-3bf8db6e283f)
看到這樣的提示岂贩,一般是出現(xiàn)僵尸實例了,但它確實運行著巷波,還連得上去呢:
數(shù)據(jù)庫里也有:
不行了萎津,趕快學一下 cell
的知識。在目前的Pike版本抹镊,cell版本為v2版本锉屈,簡單的說,cell_v2是一種扁平化的架構(gòu)垮耳,用來在集群節(jié)點擴張時颈渊,降低數(shù)據(jù)庫和消息隊列訪問瓶頸的。
參考 http://www.reibang.com/p/653e43a02ddc
cell的相關(guān)數(shù)據(jù)表在nova_api中终佛,看到這張圖就明白了:
虛擬機在 instance_mappings
表里俊嗽,計算節(jié)點在 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
表里豌研,但被刪了妹田,再也找不回來了……
所以說,沒事還是別動數(shù)據(jù)庫鹃共,動之前一定要備份!J还啊霜浴!
發(fā)生了這種操作真的該敲警鐘了,要是在公司可以直接卷鋪蓋了》》》》
2. 神奇的NoValidHost(reason="")
也就是做以上改動的前后蓝纲,環(huán)境里突然創(chuàng)建不起虛擬機了阴孟,連 1GRam/1VCPU/10GBDisk
都創(chuàng)不起來,而且控制節(jié)點中除了 /var/log/nova/nova-conducter.log
中以下log税迷,/var/log/nova/nova-scheduler.log
中幾乎沒有有用的信息永丝,看不出nova filter的過濾log。
(奇怪的是箭养,210mbRam/1VCPU/10GBDisk
是創(chuàng)的起來了慕嚷,但當時并沒有懷疑到內(nèi)存真的不夠了)
/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
我查了下喝检,幾個計算節(jié)點的內(nèi)存嗅辣、vcpu數(shù)、磁盤絕對夠用挠说,為啥它就報 NoValidHost
的錯澡谭?而且 reason=""
?
我跟著日志中報錯的代碼一個文件一個文件的看,直到在 /usr/lib/python2.7/dist-packages/nova/scheduler/manager.py
的第138行之上看到了這條:
"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."
谷歌了一下损俭,看了某些回復(fù)蛙奖,答案的天平逐漸傾向了我最不敢相信的一處:是資源不夠。
我看著這張圖擦著眼睛杆兵,真的是資源不夠嗎雁仲?
等等,allocation candidates
拧咳,Placement API
伯顶,這些都是什么東西?我要創(chuàng)個虛擬機跟它們都有什么關(guān)系骆膝?
是時候?qū)W習一下了祭衩,原來,OpenStack現(xiàn)在使用 placement
來記錄跟蹤資源提供者的庫存和使用情況阅签,并使用CPU掐暮、內(nèi)存和磁盤來標記資源類型。
參考 https://blog.csdn.net/jmilk/article/details/81264240
于是政钟,我來到了數(shù)據(jù)庫路克。
在 nova_api
數(shù)據(jù)庫的 inventories
表中,我們可以看到每個 資源提供者(resource_provider)
提供三種資源养交,分別用resource_class_id
的0精算、1、2標記cpu碎连、內(nèi)存和磁盤灰羽。total
一列是資源總量,reserved
是保留大小鱼辙,allocation_ratio
是資源超配比廉嚼。
在 allocations
表中:
消費者(虛擬機)15372401-e970-4594-bc19-e65bac9613b8
使用了資源提供者1的1VCPU、1024MB內(nèi)存倒戏、10G磁盤
消費者 01b6377f-5b0c-4273-a24a-921f793b3004
使用了資源提供者3的1VCPU怠噪、1024MB內(nèi)存、10G磁盤杜跷,還使用了資源提供者1的1VCPU傍念、1024MB內(nèi)存矫夷、10G磁盤!
鬼鬼捂寿,還會分身術(shù)口四,一個人占兩份資源?
趕緊數(shù)據(jù)庫中查一下:
沒這號人物扒芈蔓彩?怎么回事?
我猜可能是這位仁兄在兩臺計算節(jié)點間遷移出錯驳概,成為僵尸實例赤嚼,我在nova數(shù)據(jù)庫的instances表中雖然把它刪除了,但它還留在nova_api表里顺又,占用著資源更卒。
看了下,allocations表中共245條記錄稚照,怎么不是3的倍數(shù)蹂空?
于是我找到了它,也是夠孤單的:
除去這條記錄果录,表中大約有80臺虛擬機上枕,還有很多虛擬機和上面一樣,一個人占用著兩份資源弱恒。這些虛擬機的絕大部分在horizon里看不到辨萍,只是在背后默默地吃著資源,導(dǎo)致我現(xiàn)在連一臺1VCPU返弹、1024MB內(nèi)存锈玉、10G磁盤的虛擬機都創(chuàng)不起來了……
數(shù)據(jù)庫之旅到此結(jié)束,我們還可以用另一種方法查看一下每個資源提供者具體的資源使用情況:
1.獲得placement服務(wù)的訪問入口
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
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
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
什么义起?內(nèi)存都使用了11426MB了拉背?總共才7841MB啊默终!我掏出計算器去团,乘一下超配比:
7841 * 1.5 = 11761.5
11761.5 - 11426 - 512(保留大小) = -176.5 穷蛹??昼汗?
怪不得創(chuàng)不出虛擬機了肴熏,內(nèi)存不夠啊顷窒!
又按照這個方法蛙吏,查了別的資源提供者(即計算節(jié)點)源哩,發(fā)現(xiàn)幾乎都是內(nèi)存不夠,有太多horizon上看不到的虛擬機在背后尸位素餐了鸦做!
該做一次全面清洗了励烦!
怎么辦?先查泼诱,查出哪些虛擬機是沒用的坛掠,得到它們的ID,然后治筒,刪屉栓!
比如那個一人占用兩份資源的仁兄 01b6377f-5b0c-4273-a24a-921f793b3004
,先拿它開刀耸袜!
怎么刪友多?
curl ${PLACEMENT_ENDPOINT}/allocations/01b6377f-5b0c-4273-a24a-921f793b3004 -H "x-auth-token: $TOKEN" -X DELETE
再看一下compute1的使用情況:
對比一下,心情舒爽多了堤框!
繼續(xù)刪吧域滥,唉。蜈抓。启绰。
3. 分析NoValidHost(reason="")
在placement的官方文檔上寫著這么一段
https://docs.openstack.org/nova/rocky/user/placement.html
大意是nova的scheduler調(diào)度從placement服務(wù)獲取資源分配候選人
scheduler從placement api獲取資源分配候選人
后用它從cell里取到計算節(jié)點,計算節(jié)點通過篩選后资昧,scheduler遍歷通過篩選的計算節(jié)點列表酬土,并嘗試在placement api中聲明要占用這些資源。
聲明資源包括找到符合虛擬機所需資源的資源分配候選人(即計算節(jié)點)格带,并要求placement api分配這些所需資源撤缴,當在聲明資源過程中資源分配候選人用盡,就報出NoValidHost錯誤叽唱。
哦哦哦屈呕。。棺亭。
再看一張圖理解一下:
好了虎眨,基本明白了。
在清理了一些廢棄的虛擬機后镶摘,根據(jù)官網(wǎng)文檔嗽桩,可查詢是否能提供資源:
查詢一下,失敗了凄敢,試了很多次碌冶,不知道怎么用。涝缝。扑庞。
curl ${PLACEMENT_ENDPOINT}/resource_providers?resources=VCPU:2,MEMORY_MB:1024,DISK_GB:50 -H "x-auth-token: $TOKEN"
算了譬重,反正虛擬機已經(jīng)可以創(chuàng)起來了。這個API怎么使用罐氨,日后再說臀规。
另外,數(shù)據(jù)庫里那么多尸位素餐的虛擬機是怎么產(chǎn)生的栅隐,為什么沒被刪掉塔嬉,還要好好追查一下,再研究下吧》》》》》》》》