O030、Launch 和 shut off 操做詳解

參考 http://www.javashuo.com/article/p-pkdpxvfp-cv.html

 

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

 

Launch Instance

 

這是 Nova 最重要的操做。仔細研究 Lanuch 操做可以幫助咱們充分理解 Nova 各個子服務的協調配合和運行機制。前面咱們已經以 launch 操做爲例詳細討論了各個 nova-* 子服務。這裏再也不贅述，只是再回顧一下流程。

 

 

Shut Off  Instance

 

下面是 shut off instance 的流程圖

 

 

 

①用戶向 nova-api 發送關機請求

 

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

 

2019-05-23 21:21:22.174 DEBUG nova.api.openstack.wsgi [req-748d953f-42d8-4853-9816-d44fbbcdbed7 admin admin] Action: 'action', calling method: <bound method ServersController._stop_server of <nova.api.openstack.compute.servers.ServersController object at 0x7fb2f89b4fd0>>, body: {"os-stop": null} from (pid=28283) _process_stack /opt/stack/nova/nova/api/openstack/wsgi.py:623

2019-05-23 21:21:22.213 DEBUG nova.compute.api [req-748d953f-42d8-4853-9816-d44fbbcdbed7 admin admin] [instance: a0e2b485-f40c-43e4-beb6-049b6399f0ec] Going to try to stop instance from (pid=28283) force_stop /opt/stack/nova/nova/compute/api.py:2282

 

②nova-api 向 Messaging 發送一個關機的消息

 

nova-api 向messaging 發送消息，這條並無明顯的記錄到日誌文件中，但咱們仍是從日誌中找到了蛛絲馬跡，這裏經過 Requests ID 加 代碼模塊定位到了相關日誌

 

2019-05-23 21:21:22.325 DEBUG oslo_messaging._drivers.amqpdriver [req-748d953f-42d8-4853-9816-d44fbbcdbed7 admin admin] CAST unique_id: 97bb0cf9fd5b42fbabf2de4218d4a8cb exchange 'nova' topic 'compute.DevStack-Controller' from (pid=28283) _send /usr/local/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py:550

2019-05-23 21:21:22.329 INFO nova.osapi_compute.wsgi.server [req-748d953f-42d8-4853-9816-d44fbbcdbed7 admin admin] 10.12.31.241 "POST /v2.1/servers/a0e2b485-f40c-43e4-beb6-049b6399f0ec/action HTTP/1.1" status: 202 len: 337 time: 0.1873510

 

③nova-compute 從Messaging 獲取到關機的消息後執行關機操做

 

該操做在計算節點上，須要查看 /opt/stack/logs/n-cpu.log 日誌文件，同上，咱們使用 Requests ID 加 代碼模塊定位到了下面的日誌信息

 

root@DevStack-Controller:/opt/stack/logs# cat n-cpu.log | grep req-748d953f-42d8-4853-9816-d44fbbcdbed7 | grep nova.compute.manager

2019-05-23 21:21:22.363 DEBUG oslo_concurrency.lockutils [req-748d953f-42d8-4853-9816-d44fbbcdbed7 admin admin] Lock "a0e2b485-f40c-43e4-beb6-049b6399f0ec" acquired by "nova.compute.manager.do_stop_instance" :: waited 0.000s from (pid=4613) inner /usr/local/lib/python2.7/dist-packages/oslo_concurrency/lockutils.py:270

2019-05-23 21:21:22.364 DEBUG nova.compute.manager [req-748d953f-42d8-4853-9816-d44fbbcdbed7 admin admin] [instance: a0e2b485-f40c-43e4-beb6-049b6399f0ec] Checking state from (pid=4613) _get_power_state /opt/stack/nova/nova/compute/manager.py:1184

2019-05-23 21:21:22.368 DEBUG nova.compute.manager [req-748d953f-42d8-4853-9816-d44fbbcdbed7 admin admin] [instance: a0e2b485-f40c-43e4-beb6-049b6399f0ec] Stopping instance; current vm_state: active, current task_state: powering-off, current DB power_state: 1, current VM power_state: 1 from (pid=4613) do_stop_instance /opt/stack/nova/nova/compute/manager.py:2498

2019-05-23 21:21:25.826 DEBUG nova.compute.manager [req-748d953f-42d8-4853-9816-d44fbbcdbed7 admin admin] [instance: a0e2b485-f40c-43e4-beb6-049b6399f0ec] Checking state from (pid=4613) _get_power_state /opt/stack/nova/nova/compute/manager.py:1184

2019-05-23 21:21:25.950 DEBUG oslo_concurrency.lockutils [req-748d953f-42d8-4853-9816-d44fbbcdbed7 admin admin] Lock "a0e2b485-f40c-43e4-beb6-049b6399f0ec" released by "nova.compute.manager.do_stop_instance" :: held 3.587s from (pid=4613) inner /usr/local/lib/python2.7/dist-packages/oslo_concurrency/lockutils.py:282

 

root@DevStack-Controller:/opt/stack/logs# cat n-cpu.log | grep req-748d953f-42d8-4853-9816-d44fbbcdbed7 | grep nova.virt

2019-05-23 21:21:22.477 DEBUG nova.virt.libvirt.driver [req-748d953f-42d8-4853-9816-d44fbbcdbed7 admin admin] [instance: a0e2b485-f40c-43e4-beb6-049b6399f0ec] Shutting down instance from state 1 from (pid=4613) _clean_shutdown /opt/stack/nova/nova/virt/libvirt/driver.py:2562

2019-05-23 21:21:25.819 INFO nova.virt.libvirt.driver [req-748d953f-42d8-4853-9816-d44fbbcdbed7 admin admin] [instance: a0e2b485-f40c-43e4-beb6-049b6399f0ec] Instance shutdown successfully after 3 seconds.

 

---

分析日誌小竅門

 

 

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

 

這裏給你們幾個小竅門：

 

    一、先肯定大的範圍，好比在操做以前用tialf 命令實時打印日誌文件，這樣須要查看的日誌確定會在操做以後打印在屏幕上。另外也能夠經過時間戳來肯定須要的日誌範圍

 

    二、利用代碼模塊快速定位有用的信息。nova-* 子服務都有本身特定的代碼模塊

 

        nova-api

            nova.api.openstack.compute.services

            nova.compute.api

            nova.api.openstack.wsgi

 

        nova-compute

            nova.compute.manager

            nova.virt.libvirt.*

 

        nova-scheduler

            nova.scheduler.*

 

    三、利用 Requests ID 查找相關的日誌信息。在上面的日誌中，咱們能夠利用 req-748d953f-42d8-4853-9816-d44fbbcdbed7 這個Requests ID 快速定位 n-api.log 中與shut off操做相關的其餘日誌。須要補充說明的是，Requests ID 是跨日誌文件的，這一特性能幫助咱們在其餘子服務的日誌文件中找到相關信息