排錯經(jīng)歷接上回(cell赏廓、placement)

背景 http://www.reibang.com/p/56ea47e91b74

上回通過操作數(shù)據(jù)庫刪除了一個“自認為”多余的 cell格遭,怎么刪的呢狠鸳?簡單回顧下揣苏,先刪了 nova_api 數(shù)據(jù)庫里 instance_mappings 里的 instance,再刪了 cell_mappings 里面的 cell碰煌。

當時還洋洋得意以為解決了一個大問題舒岸,睡前越想越覺得不對勁,我居然動了instance_mappings 表芦圾,萬一里面存了什么重要信息怎么辦蛾派?

果然自食其果了,在horizon界面上查看不了虛擬機詳情了,也無法操作虛擬機了洪乍。眯杏。。

且看下面

1. 消失的虛擬機

無法點開虛擬機查看詳情

provider0.png
錯誤:無法獲取實例 "2f565c93-6eec-4a74-b8e8-f55638b56da3" 的詳情壳澳。

在控制節(jié)點上查看

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)

看到這樣的提示岂贩,一般是出現(xiàn)僵尸實例了,但它確實運行著巷波,還連得上去呢:

provider2.png

數(shù)據(jù)庫里也有:

provider3.png

不行了萎津,趕快學一下 cell 的知識。在目前的Pike版本抹镊,cell版本為v2版本锉屈,簡單的說,cell_v2是一種扁平化的架構(gòu)垮耳,用來在集群節(jié)點擴張時颈渊,降低數(shù)據(jù)庫和消息隊列訪問瓶頸的。

參考 http://www.reibang.com/p/653e43a02ddc

cell的相關(guān)數(shù)據(jù)表在nova_api中终佛,看到這張圖就明白了:

provider4.png

虛擬機在 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_apiinstance_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行之上看到了這條:

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."

谷歌了一下损俭,看了某些回復(fù)蛙奖,答案的天平逐漸傾向了我最不敢相信的一處:是資源不夠。

我看著這張圖擦著眼睛杆兵,真的是資源不夠嗎雁仲?

provider6.png

等等,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是資源超配比廉嚼。

provider7.png

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ù)口四,一個人占兩份資源?

provider8.png

趕緊數(shù)據(jù)庫中查一下:

provider9.png

沒這號人物扒芈蔓彩?怎么回事?

我猜可能是這位仁兄在兩臺計算節(jié)點間遷移出錯驳概,成為僵尸實例赤嚼,我在nova數(shù)據(jù)庫的instances表中雖然把它刪除了,但它還留在nova_api表里顺又,占用著資源更卒。

看了下,allocations表中共245條記錄稚照,怎么不是3的倍數(shù)蹂空?

provider10.png

于是我找到了它,也是夠孤單的:

provider11.png

除去這條記錄果录,表中大約有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
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

什么义起?內(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的使用情況:

provider15.png

對比一下,心情舒爽多了堤框!

繼續(xù)刪吧域滥,唉。蜈抓。启绰。

3. 分析NoValidHost(reason="")

在placement的官方文檔上寫著這么一段
https://docs.openstack.org/nova/rocky/user/placement.html

provider16.png

大意是nova的scheduler調(diào)度從placement服務(wù)獲取資源分配候選人

scheduler從placement api獲取資源分配候選人后用它從cell里取到計算節(jié)點,計算節(jié)點通過篩選后资昧,scheduler遍歷通過篩選的計算節(jié)點列表酬土,并嘗試在placement api中聲明要占用這些資源。

聲明資源包括找到符合虛擬機所需資源的資源分配候選人(即計算節(jié)點)格带,并要求placement api分配這些所需資源撤缴,當在聲明資源過程中資源分配候選人用盡,就報出NoValidHost錯誤叽唱。

哦哦哦屈呕。。棺亭。

再看一張圖理解一下:

provider17.png

好了虎眨,基本明白了。

在清理了一些廢棄的虛擬機后镶摘,根據(jù)官網(wǎng)文檔嗽桩,可查詢是否能提供資源:

provider18.png

查詢一下,失敗了凄敢,試了很多次碌冶,不知道怎么用。涝缝。扑庞。

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

算了譬重,反正虛擬機已經(jīng)可以創(chuàng)起來了。這個API怎么使用罐氨,日后再說臀规。

另外,數(shù)據(jù)庫里那么多尸位素餐的虛擬機是怎么產(chǎn)生的栅隐,為什么沒被刪掉塔嬉,還要好好追查一下,再研究下吧》》》》》》》》

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末约啊,一起剝皮案震驚了整個濱河市邑遏,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌恰矩,老刑警劉巖记盒,帶你破解...
    沈念sama閱讀 219,270評論 6 508
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場離奇詭異外傅,居然都是意外死亡纪吮,警方通過查閱死者的電腦和手機,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 93,489評論 3 395
  • 文/潘曉璐 我一進店門萎胰,熙熙樓的掌柜王于貴愁眉苦臉地迎上來碾盟,“玉大人,你說我怎么就攤上這事技竟”龋” “怎么了?”我有些...
    開封第一講書人閱讀 165,630評論 0 356
  • 文/不壞的土叔 我叫張陵榔组,是天一觀的道長熙尉。 經(jīng)常有香客問我,道長搓扯,這世上最難降的妖魔是什么检痰? 我笑而不...
    開封第一講書人閱讀 58,906評論 1 295
  • 正文 為了忘掉前任,我火速辦了婚禮锨推,結(jié)果婚禮上铅歼,老公的妹妹穿的比我還像新娘。我一直安慰自己换可,他們只是感情好椎椰,可當我...
    茶點故事閱讀 67,928評論 6 392
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著沾鳄,像睡著了一般俭识。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上洞渔,一...
    開封第一講書人閱讀 51,718評論 1 305
  • 那天套媚,我揣著相機與錄音,去河邊找鬼磁椒。 笑死堤瘤,一個胖子當著我的面吹牛,可吹牛的內(nèi)容都是我干的浆熔。 我是一名探鬼主播本辐,決...
    沈念sama閱讀 40,442評論 3 420
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼医增!你這毒婦竟也來了慎皱?” 一聲冷哼從身側(cè)響起,我...
    開封第一講書人閱讀 39,345評論 0 276
  • 序言:老撾萬榮一對情侶失蹤叶骨,失蹤者是張志新(化名)和其女友劉穎茫多,沒想到半個月后,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體忽刽,經(jīng)...
    沈念sama閱讀 45,802評論 1 317
  • 正文 獨居荒郊野嶺守林人離奇死亡天揖,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 37,984評論 3 337
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發(fā)現(xiàn)自己被綠了跪帝。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片今膊。...
    茶點故事閱讀 40,117評論 1 351
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖伞剑,靈堂內(nèi)的尸體忽然破棺而出斑唬,到底是詐尸還是另有隱情,我是刑警寧澤黎泣,帶...
    沈念sama閱讀 35,810評論 5 346
  • 正文 年R本政府宣布恕刘,位于F島的核電站,受9級特大地震影響聘裁,放射性物質(zhì)發(fā)生泄漏雪营。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點故事閱讀 41,462評論 3 331
  • 文/蒙蒙 一衡便、第九天 我趴在偏房一處隱蔽的房頂上張望献起。 院中可真熱鬧,春花似錦镣陕、人聲如沸谴餐。這莊子的主人今日做“春日...
    開封第一講書人閱讀 32,011評論 0 22
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽岂嗓。三九已至,卻和暖如春鹊碍,著一層夾襖步出監(jiān)牢的瞬間厌殉,已是汗流浹背食绿。 一陣腳步聲響...
    開封第一講書人閱讀 33,139評論 1 272
  • 我被黑心中介騙來泰國打工氮块, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留妻献,地道東北人崩泡。 一個月前我還...
    沈念sama閱讀 48,377評論 3 373
  • 正文 我出身青樓盛垦,卻偏偏與公主長得像矫夯,于是被迫代替她去往敵國和親贴谎。 傳聞我的和親對象是個殘疾皇子叛溢,可洞房花燭夜當晚...
    茶點故事閱讀 45,060評論 2 355

推薦閱讀更多精彩內(nèi)容

  • 1.環(huán)境準備 centos7 1.1膏潮、yum安裝設(shè)置 yum list |grep openstackcentos...
    davisgao閱讀 5,489評論 1 16
  • 第一章 OpenStack基礎(chǔ) OpenStack管理的資源及提供的服務(wù)OpenStack做為一個操作系統(tǒng)罐柳,...
    sgt_tiger閱讀 12,932評論 4 72
  • 為什么要引入nova cells 主要是為了降低數(shù)據(jù)庫和消息隊列的訪問瓶頸掌腰。對于云端架構(gòu)來說,它默認擁有非常大的資...
    JohnLee1100閱讀 4,796評論 0 2
  • 都是自己的學習筆記张吉,僅供參考齿梁。 核心模塊-Nova簡介 管理instance生命周期生成,調(diào)度芦拿,終止實例作用:處理...
    廖馬兒閱讀 3,564評論 0 3
  • 下午偶然拿起小手機士飒,發(fā)現(xiàn)打不開,原來是沒電了蔗崎,充好電后剛剛查了下話費酵幕,每個月可用59的可用余額居然還有57.48,...
    把淚化作相思雨閱讀 289評論 0 0