Nova 中的系統(tǒng)狀態(tài)分析
寫此文的目的
轉(zhuǎn)眼間OpenStack已經(jīng)發(fā)展到了K，馬上L版本開發(fā)周期也要開始了。記得我最早接觸的是OpenStack的E版本，時間過去了2年多，OpenStack社區(qū)仍然如火如荼，OpenStack玩家，特別是重量級玩家越來越多，通過每次OpenStack峰會的報道、社區(qū)的user survey以及圈里的分享，我們發(fā)現(xiàn)OpenStack的生產(chǎn)環(huán)境部署也越來越多，但是相信很多企業(yè)，很多人，在使用OpenStack的過程中仍然很痛苦。安裝部署困難，系統(tǒng)復(fù)雜性，過于靈活的架構(gòu)，眼花繚亂的配置項，特別是系統(tǒng)搭建好以后，運行過程中各種各樣的錯誤等，足以讓一個充滿熱情的人望而卻步。關(guān)于安裝部署，目前已有有很多開源工具在做，像TripleO、Fuel、RDO以及一些像Ansible、Puppet、Chef等更native 的工具，已經(jīng)極大程度的降低了安裝OpenStack的門檻，我就不再過多闡述。而關(guān)于運行期間如何排錯，如何掌握系統(tǒng)的運行狀態(tài)，在不了解系統(tǒng)實現(xiàn)原理的情況下，也會令人一籌莫展。當(dāng)然，已經(jīng)有很多發(fā)行版中包含了這部分功能。
本文的目的不是指導(dǎo)讀者寫一個新的類似的工具，而是分析為了配合這些工具，可以使用到的 OpenStack自身能力。當(dāng)然，系統(tǒng)的監(jiān)控運維是一個大的話題，我能力和視野有限，噴不了那么多(沒有真正用過的東西，我也不愿意噴)，像主機的 CPU監(jiān)控、進程監(jiān)控、網(wǎng)絡(luò)流量監(jiān)控、存儲監(jiān)控這些，也不在本文的范疇內(nèi)。
言歸正傳，說說本文主要內(nèi)容。OpenStack有很多模塊，但其中最為核心的當(dāng)然是Nova，所以本文就以Nova為例，來看一下如何通過Nova提供的能力來獲取系統(tǒng)運行期間的狀態(tài)。我把這些狀態(tài)分為兩類，一類是系統(tǒng)整體情況一覽(系統(tǒng)狀態(tài))，而是虛擬機相關(guān)的狀態(tài)信息(虛擬機狀態(tài))。當(dāng)然，以我一貫的風(fēng)格，你會看到更多的OpenStack實現(xiàn)原理。
Nova版本：Kilo
系統(tǒng)狀態(tài)
Nova提供這么幾個資源狀態(tài)的查詢。
Service
Nova中的service有兩類，一類是所謂的control service，一類就是compute service。要想獲取Nova的service詳細信息，必須要啟用os-extended-services擴展。
service的詳細信息主要包括如下幾項：
binary, host, zone, status, state
其中：
- binary，可以理解為service的名稱，類似于nova-compute。
- host是service所在的主機名稱。
zone是service所屬的AZ，其實就是service所在的主機所屬的aggregate，只是aggregate的概念不對外呈現(xiàn)，所以用戶看到的是AZ。其實，在Nova內(nèi)部，AZ是AG的metadata而已。
zone的確定，涉及到兩個配置項，對于非計算節(jié)點，zone的名稱依賴于配置項internalserviceavailability_zone(默認是inte rnal)。
對于計算節(jié)點，如果不屬于任何AG，或者所屬的AG沒有AZ的metadata信息，默認的zone依賴于配置項defaultavailabilityzone(默認是nova)。
status是服務(wù)disable屬性的體現(xiàn)，該屬性可以直接通過API修改;
state是服務(wù)真實的狀態(tài)，是通過servicegroup api獲取。每個服務(wù)在啟動時會加入servicegroup，以db后端為例，會在服務(wù)中啟動定時器，更新service表中的report_count的值，同時也會刷新更新時間，后續(xù)會根據(jù)這個更新時間確定服務(wù)的死活;
當(dāng)然，查詢service信息也支持過濾條件，比如：
查詢某個host相關(guān)的service;
按binary名稱查詢service。
知道了service的信息后，就至少能夠獲取到Nova各個服務(wù)的運行狀態(tài)，從而判斷系統(tǒng)是否健康。
Host
其實Nova中沒有host這個獨立的資源(數(shù)據(jù)庫對象)，但是Nova卻有針對host的API操作，其實，在內(nèi)部實現(xiàn)中，就是通過前面的service信息，間接組裝返回host信息。
即：你可以獲取系統(tǒng)中所有的主機信息，其中包括：主機名稱、主機上的服務(wù)、主機所屬的AZ。
Hypervisor
hypervisor的概念在OpenStack中其實不好理解。在使用KVM的環(huán)境中，hypervisor通常是就是只nova- compute進程所在的主機;而在類VMware環(huán)境中(之所以說類VMware，是因為華為也有一款虛擬化產(chǎn)品FusionCompute也是類似的架構(gòu))，hypervisor是指nova-compute進程下的一個’node’，對應(yīng)于一個vCenter集群。換句話說，你可以把一個 hypervisor看成一個nova-compute下的一個node，KVM的情況是一個特例而已。一個hypervisor，是創(chuàng)建虛擬機能夠調(diào)度到的最小單元。
Nova中對于hypervisor的查詢情況支持較為豐富。
- 查詢所有的hypervisor概要信息。包含一個id和一個hypervisor host name，如果啟用了os-hypervisor-status extension，還會返回hypervisor所屬的nova-compute服務(wù)狀態(tài)。
- 查詢所有的hypervisor詳細信息。除了包含上述信息外，還包含每個hypervisor的資源使用信息。如果啟用os- extended-hypervisors extension，還會包含hypervisor所屬的nova-compute所在主機的IP地址。
- 查詢所有hypervisor所使用的系統(tǒng)資源總量。即，系統(tǒng)計算資源使用量的一個總覽。
- 模糊查詢某些hypervisor的概要信息。
- 查詢單個hypervisor資源使用的詳細信息。
- 模糊查詢某些hypervisor上的虛擬機信息，包含虛擬機的ID和名稱。
可見，Nova中的hypervisor給管理員提供了較為豐富系統(tǒng)計算資源使用情況的查詢接口，通過對hypervisor使用情況的了解，管理員可以更有效地進行系統(tǒng)監(jiān)控，并且為系統(tǒng)維護(擴容、減容、動態(tài)資源調(diào)整等)提供依據(jù)。
#p#
租戶視角的系統(tǒng)狀態(tài)
上面的幾個資源，默認都是管理員有權(quán)限查詢，普通租戶是看不到的。那么作為租戶，能夠?qū)ο到y(tǒng)使用狀態(tài)有一個什么樣的了解呢?
租戶的資源配額
租戶可以查詢自己的資源配額限制和使用情況，管理員(admin)可以查詢普通租戶的資源配額使用情況(os-used-limits-for-admin extension)。參見這里, 這里和這里。
如下是租戶查到的自己的資源配額限制和使用情況(片段)：
- {
- "limits": {
- "absolute": {
- "maxImageMeta": 128,
- "maxPersonality": 5,
- "maxPersonalitySize": 10240,
- "maxSecurityGroupRules": 20,
- "maxSecurityGroups": 10,
- "maxServerMeta": 128,
- "maxTotalCores": 20,
- "maxTotalFloatingIps": 10,
- "maxTotalInstances": 10,
- "maxTotalKeypairs": 100,
- "maxTotalRAMSize": 51200,
- "maxServerGroups": 10,
- "maxServerGroupMembers": 10,
- "totalCoresUsed": 0,
- "totalInstancesUsed": 0,
- "totalRAMUsed": 0,
- "totalSecurityGroupsUsed": 0,
- "totalFloatingIpsUsed": 0,
- "totalServerGroupsUsed":
- ...
租戶的資源使用量
管理員可以查詢所有租戶對計算資源的使用量，也可以查詢某個租戶的計算資源使用量(包括每個虛擬機計算資源使用信息)，參見這里。
示例1，管理員查詢租戶對計算資源的使用量：
- {
- "tenant_usages": [
- {
- "start": "2012-10-08T21:10:44.587336",
- "stop": "2012-10-08T22:10:44.587336",
- "tenant_id": "openstack",
- "total_hours": 1.0,
- "total_local_gb_usage": 1.0,
- "total_memory_mb_usage": 512.0,
- "total_vcpus_usage": 1.0
- }
- ]
- }
示例2，查詢某個租戶的計算資源使用量：
- {
- "tenant_usage": {
- "server_usages": [
- {
- "ended_at": null,
- "flavor": "m1.tiny",
- "hours": 1.0,
- "instance_id": "1f1deceb-17b5-4c04-84c7-e0d4499c8fe0",
- "local_gb": 1,
- "memory_mb": 512,
- "name": "new-server-test",
- "started_at": "2012-10-08T20:10:44.541277",
- "state": "active",
- "tenant_id": "openstack",
- "uptime": 3600,
- "vcpus": 1
- }
- ],
- "start": "2012-10-08T20:10:44.587336",
- "stop": "2012-10-08T21:10:44.587336",
- "tenant_id": "openstack",
- "total_hours": 1.0,
- "total_local_gb_usage": 1.0,
- "total_memory_mb_usage": 512.0,
- "total_vcpus_usage": 1.0
- }
- }
#p#
虛擬機狀態(tài)
說到底，作為IaaS，OpenStack玩的還是虛擬機，因為各種資源(存儲、網(wǎng)絡(luò))都是為了更好的使用虛擬機服務(wù)。所以對虛擬機狀態(tài)的掌握就顯得格外重要。
虛擬機操作事件通知
用戶對虛擬機的每個操作(開始和結(jié)束)，都會通過消息隊列向外部發(fā)送通知，外部系統(tǒng)可以通過接收通知，了解系統(tǒng)的運行過程。使用通知的另外一個好處，就是可以與Nova解耦，作為外部系統(tǒng)的數(shù)據(jù)源，實現(xiàn)系統(tǒng)的監(jiān)控分析。Ceilometer、StackTach和Monasca都用到了Nova的通知作為自己的數(shù)據(jù)源。
與此同時，虛擬機state或task_state發(fā)生變化時，也會向外部發(fā)送通知。前提是配置項notify_on_state_change要配置為vm_state或vm_and_task_state。
另外，Nova中除了上述說的操作事件通知外，還有一種審計通知，即在一段時間內(nèi)的系統(tǒng)資源狀態(tài)，相關(guān)的配置項 instance_usage_audit_period，目前Nova中只有event_type類型為 compute.instance.exists一種審計通知，這種通知可以讓你對一段周期內(nèi)系統(tǒng)中存在的虛擬機有一個全局的了解。
虛擬機操作事件記錄
Nova中的虛擬機每個操作(啟動、停止、暫停、恢復(fù)等)，都會在db中保存相關(guān)的操作記錄，給用戶提供查詢。利用這個功能，用戶對自己的虛擬機整個生命周期的過程和狀態(tài)都會了如指掌，便于用戶的管理。參見這里。示例如下：
- {
- "instanceActions": [
- {
- "action": "resize",
- "instance_uuid": "b48316c5-71e8-45e4-9884-6c78055b9b13",
- "message": "",
- "project_id": "842",
- "request_id": "req-25517360-b757-47d3-be45-0e8d2a01b36a",
- "start_time": "2012-12-05 01:00:00.000000",
- "user_id": "789"
- },
- {
- "action": "reboot",
- "instance_uuid": "b48316c5-71e8-45e4-9884-6c78055b9b13",
- "message": "",
- "project_id": "147",
- "request_id": "req-3293a3f1-b44c-4609-b8d2-d81b105636b8",
- "start_time": "2012-12-05 00:00:00.000000",
- "user_id": "789"
- }
- ]
- }
在內(nèi)部實現(xiàn)中，nova-api層會記錄action開始的記錄，在nova-compute層，則會添加event開始和結(jié)束的信息，action和event根據(jù)request id(一次消息請求的標識)關(guān)聯(lián)。
虛擬機錯誤信息記錄
因為OpenStack的安裝部署復(fù)雜性，或者操作過程對環(huán)境、配置等要求比較苛刻，稍不注意，就有可能發(fā)生錯誤。一旦發(fā)生錯誤，除了從日志中獲取錯誤信息外，還有什么比較方便、快捷的方式能夠迅速定位錯誤呢?
在API層發(fā)生錯誤，用戶會立即看到錯誤碼和錯誤信息。但如果是在conductor，scheduler或compute層發(fā)生錯誤呢?
OpenStack智慧的社區(qū)開發(fā)者們已經(jīng)為我們提供了這種能力。其實還是利用DB和通知機制來實現(xiàn)。
先說通知，虛擬機操作異常時，一般都會發(fā)送error通知，通知中包含異常的函數(shù)名稱、異常時函數(shù)的參數(shù)以及異常信息。
再說db，虛擬機操作異常時，無論是在conductor, scheduler還是compute層，除了會發(fā)送通知外，還會記錄異常信息到數(shù)據(jù)庫(instance_faults表)，當(dāng)查詢虛擬機信息時，會返回虛擬機的異常信息。
虛擬機診斷信息
租戶可以查詢虛擬機使用過程中的一些統(tǒng)計信息，比如虛擬機磁盤的讀寫情況、網(wǎng)絡(luò)的IO情況等，對于KVM來講，這些信息都是通過libvirt接口獲取。
API示例參見這里。返回消息示例：
- {
- "vnet0_tx_errors": 0,
- "vda_errors": -1,
- "vda_read": 4447232,
- "vda_write": 4347904,
- "vnet0_tx_packets": 1259,
- "vda_write_req": 3523,
- "memory-actual": 524288,
- "cpu0_time": 195230000000,
- "vnet0_tx": 364840,
- "vnet0_rx_drop": 0,
- "vnet0_rx_packets": 1423,
- "vnet0_rx_errors": 0,
- "memory": 524288,
- "memory-rss": 243188,
- "vda_read_req": 291,
- "vnet0_rx": 363725,
- "vnet0_tx_drop": 0
- }
參考鏈接
https://wiki.openstack.org/wiki/SystemUsageData
https://wiki.openstack.org/wiki/NotificationEventExamples
https://github.com/rackerlabs/yagi
http://www.stacktach.com/
作者簡介
孔令賢，華為技術(shù)有限公司云計算領(lǐng)域OpenStack社區(qū)團隊技術(shù)主管，2011年加入華為西安研究所，一直從事云計算相關(guān)方向的研發(fā)工作。于2012年開始研究OpenStack，其個人博客(CSDN博客：http://blog.csdn.net/lynn_kong，Github博客：http://lingxiankong.github.io/多次被業(yè)內(nèi)人士學(xué)習(xí)和轉(zhuǎn)載。同時，積極組織和推動OpenStack在國內(nèi)的技術(shù)交流和活動，多次以主講人的身份參加OpenStack西安meetup。
