Launch和Shut Off操做詳解 - 天天5分鐘玩轉 OpenStack（30）

本節詳細分析 instance launch 和 shut off 操做，以及如何在日誌中快速定位有用信息的技巧。

Launch

Launch instance 應該算 Nova 最重要的操做。

仔細研究 lanuch 操做可以幫助咱們充分理解 Nova 各個子服務的協調配合和運行機制。

前面咱們已經以 launch 操做爲例詳細討論了各個 nova-* 子服務。 這裏再也不贅述，只是再回顧一下流程。

1. 客戶（能夠是 OpenStack 最終用戶，也能夠是其餘程序）向 API（nova-api）發送請求：「幫我建立一個 Instance」

2. API對請求作一些必要處理後，向 Messaging（RabbitMQ）發送了一條消息：「讓 Scheduler 建立一個 Instance」

3. Scheduler（nova-scheduler）從 Messaging 獲取到 API 發給它的消息，而後執行調度算法，從若干計算節點中選出節點 A

4. Scheduler 向 Messaging 發送了一條消息：「在計算節點 A 上建立這個 Instance」

5. 計算節點 A 的 Compute（nova-compute）從 Messaging 中獲取到 Scheduler 發給它的消息，而後經過本節點的 Hypervisor Driver 建立 Instance。

6. 在 Instance 建立的過程當中，Compute 若是須要查詢或更新數據庫信息，會經過 Messaging 向 Conductor（nova-conductor）發送消息，Conductor 負責數據庫訪問。

Shut Off

下面是 shut off instance 的流程圖

1. 向 nova-api 發送請求

2. nova-api 發送消息

3. nova-compute 執行操做

下面咱們詳細討論每個步驟。

向 nova-api 發送請求

客戶（能夠是 OpenStack 最終用戶，也能夠是其餘程序）向 API（nova-api）發送請求：「幫我關閉這個 Instance」

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

對於如何在日誌文件中快速查找到有用的信息這裏多聊幾句。 對於初學者，這不是一件容易的事情，由於日誌裏條目和內容不少，特別是 debug 選項打開以後，容易讓人眼花繚亂，無從下手。

這裏給你們幾個小竅門：

1. 先肯定大的範圍，好比在操做以前用 tail -f 打印日誌文件，這樣須要查看的日誌確定在操做以後的打印輸出的這些內容裏。 另外也能夠經過時間戳來肯定須要的日誌範圍。

2. 利用 「代碼模塊」 快速定位有用的信息。 nova-* 子服務都有本身特定的代碼模塊：
   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 查找相關的日誌信息。 在上面的日誌中個，咱們能夠利用 「req-1758b389-a2d0-44cc-a95a-6f75e4dc07fd」 這個 Request ID 快速定位 n-api.log 中相與 shut off 操做的其餘日誌條目。 須要補充說明的是，Request ID 是跨日誌文件的，這一個特性能幫助咱們在其餘子服務的日誌文件中找到相關信息，咱們後面立刻將會看到這個技巧的應用。

nova-api 發送消息

nova-api 向 Messaging（RabbitMQ）發送了一條消息：「關閉這個 Instance」 nova-api 沒有將發送消息的操做記錄到日誌中，不過咱們能夠經過查看源代碼來驗證。 一提到源代碼，你們可能覺得要大海撈針了。其實很簡單，上面日誌已經清楚地告訴咱們須要查看的源代碼在 /opt/stack/nova/nova/compute/api.py 的 1977 行，方法是 force_stop。

force_stop 方法最後調用的是對象 self.compute_rpcapi 的 stop_instance 方法。 在 OpenStack 源碼中，以 xxx_rpcapi 命名的對象，表示的就是 xxx 的消息隊列。 xxx_rpcapi.yyy() 方法則表示向 xxx 的消息隊列發送 yyy 操做的消息。

因此 self.compute_rpcapi.stop_instance() 的做用就是向 RabbitMQ 上 nova-compute 的消息隊列裏發送一條 stop instance 的消息。

這裏補充說明一下： 關閉 instance 的前提是 instance 當前已經在某個計算節點上運行，因此這裏不須要 nova-scheduler 再幫咱們挑選合適的節點，這個跟 launch 操做不一樣。

nova-compute 執行操做

查看計算節點上的日誌 /opt/stack/logs/n-cpu.log

這裏咱們利用了 Request ID 「req-1758b389-a2d0-44cc-a95a-6f75e4dc07fd」 在 n-cpu.log 中快速定位到 nova-compute 關閉 instance 的日誌條目。

小結

分析某個操做時，咱們首先要理清該操做的內部流程，而後再到相應的節點上去查看日誌。 例如shut off 的流程爲：

1. 向 nova-api 發送請求

2. nova-api 發送消息

3. nova-compute 執行操做

1，2 兩個步驟是在控制節點上執行的，查看 nova-api 的日誌。 第 3 步是在計算節點上執行的，查看 nova-compute 的日誌。