Launch和Shut Off操作詳解 - 每天5分鐘玩轉 OpenStack（30）LaunchShut Off小結

本節詳細分析 instance launch 和 shut off 操作，以及如何在日志中快速定位有用資訊的技巧。

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

仔細研究 lanuch 操作能夠幫助我們充分了解 Nova 各個子服務的協調配合和運作機制。

前面我們已經以 launch 操作為例詳細讨論了各個 nova-* 子服務。 這裡不再贅述，隻是再回顧一下流程。

客戶（可以是 OpenStack 最終使用者，也可以是其他程式）向 API（nova-api）發送請求：“幫我建立一個 Instance”

API對請求做一些必要處理後，向 Messaging（RabbitMQ）發送了一條消息：“讓 Scheduler 建立一個 Instance”

Scheduler（nova-scheduler）從 Messaging 擷取到 API 發給它的消息，然後執行排程算法，從若幹計算節點中選出節點 A

Scheduler 向 Messaging 發送了一條消息：“在計算節點 A 上建立這個 Instance”

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

在 Instance 建立的過程中，Compute 如果需要查詢或更新資料庫資訊，會通過 Messaging 向 Conductor（nova-conductor）發送消息，Conductor 負責資料庫通路。

下面是 shut off instance 的流程圖

向 nova-api 發送請求

nova-api 發送消息

nova-compute 執行操作

下面我們詳細讨論每一個步驟。

客戶（可以是 OpenStack 最終使用者，也可以是其他程式）向 API（nova-api）發送請求：“幫我關閉這個 Instance”

檢視日志 /opt/stack/logs/n-api.log

對于如何在日志檔案中快速查找到有用的資訊這裡多聊幾句。 對于初學者，這不是一件容易的事情，因為日志裡條目和内容很多，特别是 debug 選項打開之後，容易讓人眼花缭亂，無從下手。

這裡給大家幾個小竅門：

先确定大的範圍，比如在操作之前用 tail -f 列印日志檔案，這樣需要檢視的日志肯定在操作之後的列印輸出的這些内容裡。 另外也可以通過時間戳來确定需要的日志範圍。

利用 “代碼子產品” 快速定位有用的資訊。 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.*

利用 Request ID 查找相關的日志資訊。 在上面的日志中個，我們可以利用 “req-1758b389-a2d0-44cc-a95a-6f75e4dc07fd” 這個 Request ID 快速定位 n-api.log 中相與 shut off 操作的其他日志條目。 需要補充說明的是，Request ID 是跨日志檔案的，這一個特性能幫助我們在其他子服務的日志檔案中找到相關資訊，我們後面馬上将會看到這個技巧的應用。

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 操作不同。

檢視計算節點上的日志 /opt/stack/logs/n-cpu.log

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

分析某個操作時，我們首先要理清該操作的内部流程，然後再到相應的節點上去檢視日志。 例如shut off 的流程為：

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

本文轉自CloudMan6 51CTO部落格，原文連結:http://blog.51cto.com/cloudman/1770612