您好,登錄后才能下訂單哦!
Launch和Shut 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 的流程為:
向 nova-api 發送請求
nova-api 發送消息
nova-compute 執行操作
1,2 兩個步驟是在控制節點上執行的,查看 nova-api 的日志。 第 3 步是在計算節點上執行的,查看 nova-compute 的日志。
關于Launch和Shut Off操作是怎樣的問題的解答就分享到這里了,希望以上內容可以對大家有一定的幫助,如果你還有很多疑惑沒有解開,可以關注億速云行業資訊頻道了解更多相關知識。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。