Launch和Shut Off操作是怎樣的

Launch和Shut Off操作是怎樣的，針對(duì)這個(gè)問(wèn)題，這篇文章詳細(xì)介紹了相對(duì)應(yīng)的分析和解答，希望可以幫助更多想解決這個(gè)問(wèn)題的小伙伴找到更簡(jiǎn)單易行的方法。

分析 instance launch 和 shut off 操作，以及如何在日志中快速定位有用信息的技巧。

Launch

Launch instance 應(yīng)該算 Nova 最重要的操作。

仔細(xì)研究 lanuch 操作能夠幫助我們充分理解 Nova 各個(gè)子服務(wù)的協(xié)調(diào)配合和運(yùn)行機(jī)制。

前面我們已經(jīng)以 launch 操作為例詳細(xì)討論了各個(gè) nova-* 子服務(wù)。 這里不再贅述，只是再回顧一下流程。

1. 客戶(hù)（可以是 OpenStack 最終用戶(hù)，也可以是其他程序）向 API（nova-api）發(fā)送請(qǐng)求：“幫我創(chuàng)建一個(gè) Instance”

2. API對(duì)請(qǐng)求做一些必要處理后，向 Messaging（RabbitMQ）發(fā)送了一條消息：“讓 Scheduler 創(chuàng)建一個(gè) Instance”

3. Scheduler（nova-scheduler）從 Messaging 獲取到 API 發(fā)給它的消息，然后執(zhí)行調(diào)度算法，從若干計(jì)算節(jié)點(diǎn)中選出節(jié)點(diǎn) A

4. Scheduler 向 Messaging 發(fā)送了一條消息：“在計(jì)算節(jié)點(diǎn) A 上創(chuàng)建這個(gè) Instance”

5. 計(jì)算節(jié)點(diǎn) A 的 Compute（nova-compute）從 Messaging 中獲取到 Scheduler 發(fā)給它的消息，然后通過(guò)本節(jié)點(diǎn)的 Hypervisor Driver 創(chuàng)建 Instance。

6. 在 Instance 創(chuàng)建的過(guò)程中，Compute 如果需要查詢(xún)或更新數(shù)據(jù)庫(kù)信息，會(huì)通過(guò) Messaging 向 Conductor（nova-conductor）發(fā)送消息，Conductor 負(fù)責(zé)數(shù)據(jù)庫(kù)訪(fǎng)問(wèn)。

Shut Off

下面是 shut off instance 的流程圖

1. 向 nova-api 發(fā)送請(qǐng)求

2. nova-api 發(fā)送消息

3. nova-compute 執(zhí)行操作

下面我們?cè)敿?xì)討論每一個(gè)步驟。

向 nova-api 發(fā)送請(qǐng)求

客戶(hù)（可以是 OpenStack 最終用戶(hù)，也可以是其他程序）向 API（nova-api）發(fā)送請(qǐng)求：“幫我關(guān)閉這個(gè) Instance”

查看日志 /opt/stack/logs/n-api.log

對(duì)于如何在日志文件中快速查找到有用的信息這里多聊幾句。 對(duì)于初學(xué)者，這不是一件容易的事情，因?yàn)槿罩纠飾l目和內(nèi)容很多，特別是 debug 選項(xiàng)打開(kāi)之后，容易讓人眼花繚亂，無(wú)從下手。

這里給大家?guī)讉€(gè)小竅門(mén)：

1. 先確定大的范圍，比如在操作之前用 tail -f 打印日志文件，這樣需要查看的日志肯定在操作之后的打印輸出的這些內(nèi)容里。 另外也可以通過(guò)時(shí)間戳來(lái)確定需要的日志范圍。

2. 利用 “代碼模塊” 快速定位有用的信息。 nova-* 子服務(wù)都有自己特定的代碼模塊：
   nova-api
   nova.api.openstack.compute.servers
   nova.compute.api
   nova.api.openstack.wsgi
   
   nova-compute
   nova.compute.manager
   nova.virt.libvirt.*
   
   nova-scheduler
   nova.scheduler.*

3. 利用 Request ID 查找相關(guān)的日志信息。 在上面的日志中個(gè)，我們可以利用 “req-1758b389-a2d0-44cc-a95a-6f75e4dc07fd” 這個(gè) Request ID 快速定位 n-api.log 中相與 shut off 操作的其他日志條目。 需要補(bǔ)充說(shuō)明的是，Request ID 是跨日志文件的，這一個(gè)特性能幫助我們?cè)谄渌臃?wù)的日志文件中找到相關(guān)信息，我們后面馬上將會(huì)看到這個(gè)技巧的應(yīng)用。

nova-api 發(fā)送消息

nova-api 向 Messaging（RabbitMQ）發(fā)送了一條消息：“關(guān)閉這個(gè) Instance” nova-api 沒(méi)有將發(fā)送消息的操作記錄到日志中，不過(guò)我們可以通過(guò)查看源代碼來(lái)驗(yàn)證。 一提到源代碼，大家可能以為要大海撈針了。其實(shí)很簡(jiǎn)單，上面日志已經(jīng)清楚地告訴我們需要查看的源代碼在 /opt/stack/nova/nova/compute/api.py 的 1977 行，方法是 force_stop。

force_stop 方法最后調(diào)用的是對(duì)象 self.compute_rpcapi 的 stop_instance 方法。 在 OpenStack 源碼中，以 xxx_rpcapi 命名的對(duì)象，表示的就是 xxx 的消息隊(duì)列。 xxx_rpcapi.yyy() 方法則表示向 xxx 的消息隊(duì)列發(fā)送 yyy 操作的消息。

所以 self.compute_rpcapi.stop_instance() 的作用就是向 RabbitMQ 上 nova-compute 的消息隊(duì)列里發(fā)送一條 stop instance 的消息。

這里補(bǔ)充說(shuō)明一下： 關(guān)閉 instance 的前提是 instance 當(dāng)前已經(jīng)在某個(gè)計(jì)算節(jié)點(diǎn)上運(yùn)行，所以這里不需要 nova-scheduler 再幫我們挑選合適的節(jié)點(diǎn)，這個(gè)跟 launch 操作不同。

nova-compute 執(zhí)行操作

查看計(jì)算節(jié)點(diǎn)上的日志 /opt/stack/logs/n-cpu.log

這里我們利用了 Request ID “req-1758b389-a2d0-44cc-a95a-6f75e4dc07fd” 在 n-cpu.log 中快速定位到 nova-compute 關(guān)閉 instance 的日志條目。

分析某個(gè)操作時(shí)，我們首先要理清該操作的內(nèi)部流程，然后再到相應(yīng)的節(jié)點(diǎn)上去查看日志。 例如shut off 的流程為：

1. 向 nova-api 發(fā)送請(qǐng)求

2. nova-api 發(fā)送消息

3. nova-compute 執(zhí)行操作

1，2 兩個(gè)步驟是在控制節(jié)點(diǎn)上執(zhí)行的，查看 nova-api 的日志。 第 3 步是在計(jì)算節(jié)點(diǎn)上執(zhí)行的，查看 nova-compute 的日志。

關(guān)于Launch和Shut Off操作是怎樣的問(wèn)題的解答就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，如果你還有很多疑惑沒(méi)有解開(kāi)，可以關(guān)注億速云行業(yè)資訊頻道了解更多相關(guān)知識(shí)。