有效定位和解決OpenStack問題

對OpenStack這樣一個龐大的系統來說，遇到問題很正常，如何對遇到的問題進行精确的定位和解決才是關鍵？但在很多時候，從使用者表象上看到的現象和後端真正的錯誤往往會有一些偏差。本文以OpenStack虛拟機啟動工作流為基礎，對OpenStack troubleshooting做一個介紹。從了解整個OpenStack中最核心的虛拟機管理，來對整個OpenStack的設計架構有個了解，為今後更複雜的問題提供一些參考。

從啟動虛拟機說起

在開始之前，如果你曾經使用過OpenStack，那請你花幾分鐘時間回憶一下，你所了解的虛拟機建立過程。如果你還沒來得及安裝OpenStack，那我建議你先安裝一個，這樣以便于讓你能更好的對下面的内容進行學習。

啟動一個虛拟機需要涉及的元件

• CLI：OpenStack指令行工具，可以通過指令來建立虛拟機。
• Horizon：OpenStack圖形化界面，可以更友好的通過圖形化來操作虛拟機。
• Nova：OpenStack計算核心元件，調用後端的虛拟化平台API接口來最終通過鏡像建立虛拟機。
• Glance：OpenStack鏡像管理元件，虛拟機建立過程中需要從這個元件擷取虛拟機鏡像。
• Cinder：OpenStack存儲管理元件，管理後端存儲資源，并為虛拟機提供持久化存儲的能力。
• Neutron：OpenStack網絡管理元件，虛拟機建立過程中需要通過此元件擷取網絡資訊。
• Keystone：OpenStack認證元件，虛拟機建立過程中使用者和服務認證需要此服務支撐。
• MQ(RabbitMQ)：消息中間件，支援OpenStack元件内通訊。

Nova元件架構和通訊方式

Nova元件是整個虛拟機啟動過程中最重要的元件，Nova的整個設計如下圖所示：

整個Nova的設計可以總結如下幾點：

• Nova元件内部子產品之前通訊采用AMQP
• Nova元件和其它元件之間通訊采用RESTful API
• Nova元件有本身資料庫存儲持久化資料

可以通過Nova的架構圖回味一下Cinder、Neutron、Ceilometer的結構，會發現OpenStack設計上都有類似的地方。當了解了Nova元件内群組件間的互動形式，就可以更好的把之前說到的整個虛拟機建立過程中涉及到的所有元件串起來，下面用一個虛拟機建立的流程想想說明這個過程。

啟動虛拟機流程

在OpenStack中，啟動虛拟機整個過程看似幾秒鐘完成的工作，其涉及的相關知識還是相當豐富。曾近有人統計了所涉及的技術，應該在100個知識點以上，這裡就不拿出來吓唬大家。重點把整個虛拟機啟動過程的圖就我的了解進行了整理，如下（有部分是盜用）：

虛拟機啟動過程如下：

1. 界面或指令行通過RESTful API向keystone擷取認證資訊。
2. keystone通過使用者請求認證資訊，并生成auth-token傳回給對應的認證請求。
3. 界面或指令行通過RESTful API向nova-api發送一個boot instance的請求（攜帶auth-token）。
4. nova-api接受請求後向keystone發送認證請求，檢視token是否為有效使用者和token。
5. keystone驗證token是否有效，如有效則傳回有效的認證和對應的角色（注：有些操作需要有角色權限才能操作）。
6. 通過認證後nova-api和資料庫通訊。
7. 初始化建立虛拟機的資料庫記錄。
8. nova-api通過rpc.call向nova-scheduler請求是否有建立虛拟機的資源(Host ID)。
9. nova-scheduler程序偵聽消息隊列，擷取nova-api的請求。
10. nova-scheduler通過查詢nova資料庫中計算資源的情況，并通過排程算法計算符合虛拟機建立需要的主機。
11. 對于有符合虛拟機建立的主機，nova-scheduler更新資料庫中虛拟機對應的實體主機資訊。
12. nova-scheduler通過rpc.cast向nova-compute發送對應的建立虛拟機請求的消息。
13. nova-compute會從對應的消息隊列中擷取建立虛拟機請求的消息。
14. nova-compute通過rpc.call向nova-conductor請求擷取虛拟機消息。（Flavor）
15. nova-conductor從消息隊隊列中拿到nova-compute請求消息。
16. nova-conductor根據消息查詢虛拟機對應的資訊。
17. nova-conductor從資料庫中獲得虛拟機對應資訊。
18. nova-conductor把虛拟機資訊通過消息的方式發送到消息隊列中。
19. nova-compute從對應的消息隊列中擷取虛拟機資訊消息。
20. nova-compute通過keystone的RESTfull API拿到認證的token，并通過HTTP請求glance-api擷取建立虛拟機所需要鏡像。
21. glance-api向keystone認證token是否有效，并傳回驗證結果。
22. token驗證通過，nova-compute獲得虛拟機鏡像資訊(URL)。
23. nova-compute通過keystone的RESTfull API拿到認證k的token，并通過HTTP請求neutron-server擷取建立虛拟機所需要的網絡資訊。
24. neutron-server向keystone認證token是否有效，并傳回驗證結果。
25. token驗證通過，nova-compute獲得虛拟機網絡資訊。
26. nova-compute通過keystone的RESTfull API拿到認證的token，并通過HTTP請求cinder-api擷取建立虛拟機所需要的持久化存儲資訊。
27. cinder-api向keystone認證token是否有效，并傳回驗證結果。
28. token驗證通過，nova-compute獲得虛拟機持久化存儲資訊。
29. nova-compute根據instance的資訊調用配置的虛拟化驅動來建立虛拟機。

在虛拟機建立過程中，可以看到一個任務狀态（Task），可以通過這個狀态初步判斷虛拟機處于哪個步驟：

• scheduling(3~12)
• networking(23~25)
• block_device_mapping(26~28)
• spawing(29)
• none（虛拟機建立成功）

記住這些狀态，這個是在整個排錯過程中最重要的一個狀态。可以通過這個狀态初步判斷整個過程處于什麼位置，可以很快的把問題縮小在一個比較小的範圍。

永遠的日志

看到這裡估計在排錯的時候心裡就有底氣多了，不會滿世界的去找問題。但還是需要提醒大家，有問題——>找日志。别看這個大家都懂的事情，往往在操作起來，大家跟願意直接找個人問出了什麼問題。大概的歸類了一下OpenStack的日志：

• nova
  • /var/log/nova/*(api.log/compute.log)
• neutron
  • /var/log/neutron/*
• glance
  • /var/log/glance/*
• cinder
  • /var/log/cinder/*
• keystone
  • /var/log/keystone/*
• libvirtd
  • /var/log/libvirt/*(qemu裡的日志很重要！！)

虛拟機涉及檔案

一個虛拟機預設情況下啟動過程、或者啟動後會在其排程的nova-compute節點的/var/lib/nova/instances目錄下會生成如下的檔案：

• base目錄下一個base鏡像
• libvirt.xml
• disk
• disk-raw
• kernel
• ramdisk
• console.log

輔助的工具

工具千千萬隻是能提升效率的一個點，關鍵還是在于對整個過程的了解。在OpenStack使用過程中會用到一些工具輔助排除錯誤，常用工具如下：

工具名稱	工具用途	說明
strace	系統調用跟蹤	一個簡易且十分好用的系統調研跟蹤工具
lsof	檢視打開檔案	可以很容易的對打開的檔案進行檢視
tcpdump	網絡抓包分析	可以通過抓發分析網絡不通
kill	kill -USR1	最近發現的牛掰用法

strace用法

• strace -e open ping
• strace -p process_id
• strace -c ping
• strace -e trace=network nc 127.0.0.1 22

lsof用法

• lsof -p process_id
• lsof -i :22 -n

tcpdump用法

• tcpdump -i interface icmp（其它更多參考tcpdump指令）
• 建議配合wireshark來分析封包

kill -USR1用法

OpenStack提供SIGUSR1使用者定義的信号生成Guru Meditation報告，報告包含如下服務的完整資訊和狀态，這些狀态會輸出到标準錯誤輸出中，可以在錯誤日志中檢視。

[kevin@stack ~]$ ps -ef|grep nova-api
kevin      4320   3116 30 11:06 pts/7    00:00:03 /usr/bin/python /usr/bin/nova-api
kevin      4335   4320  2 11:06 pts/7    00:00:00 /usr/bin/python /usr/bin/nova-api
kevin      4336   4320  2 11:06 pts/7    00:00:00 /usr/bin/python /usr/bin/nova-api
kevin      4339   4320  4 11:06 pts/7    00:00:00 /usr/bin/python /usr/bin/nova-api
kevin      4340   4320  4 11:06 pts/7    00:00:00 /usr/bin/python /usr/bin/nova-api
kevin      4349   4320  9 11:06 pts/7    00:00:00 /usr/bin/python /usr/bin/nova-api
kevin      4350   4320 11 11:06 pts/7    00:00:00 /usr/bin/python /usr/bin/nova-api
kevin      4360   4205  0 11:07 pts/23   00:00:00 grep --color=auto nova-api
[kevin@stack ~]$ kill -USR1 4320
           

報告包含如下章節：

• 軟體包資訊
• Threads
• Green Threads
• 配置檔案

總結

OpenStack troubleshooting的過程中，最重要的是梳理OpenStack的流程。在梳理流程的基礎上，配合一些工具可以解決大部分在運作過程中遇到的問題。另外一方面，由于OpenStack本身是一個雲管理架構，在排錯的過程當中，你往往會遇到很多KVM、存儲、OVS、iptables這塊的問題，對于這塊的問題的解決，還是需要對其原理有一個深刻的了解才行。

幾個課後練習

• nova-api服務停止的情況下，nova-list可以列出虛拟機嗎？為什麼？
• 用kill指令嘗試終止nova-conductor程序，會有什麼報錯？（提示先從日志開始）
• 用strace跟蹤一下某個程序的系統調用。