Nova 中的系統(tǒng)狀態(tài)分析
寫此文的目的
轉(zhuǎn)眼間OpenStack已經(jīng)發(fā)展到了K，馬上L版本開發(fā)周期也要開始了。記得我最早接觸的是OpenStack的E版本，時(shí)間過去了2年多，OpenStack社區(qū)仍然如火如荼，OpenStack玩家，特別是重量級玩家越來越多，通過每次OpenStack峰會(huì)的報(bào)道、社區(qū)的user survey以及圈里的分享，我們發(fā)現(xiàn)OpenStack的生產(chǎn)環(huán)境部署也越來越多，但是相信很多企業(yè)，很多人，在使用OpenStack的過程中仍然很痛苦。安裝部署困難，系統(tǒng)復(fù)雜性，過于靈活的架構(gòu)，眼花繚亂的配置項(xiàng)，特別是系統(tǒng)搭建好以后，運(yùn)行過程中各種各樣的錯(cuò)誤等，足以讓一個(gè)充滿熱情的人望而卻步。關(guān)于安裝部署，目前已有有很多開源工具在做，像TripleO、Fuel、RDO以及一些像Ansible、Puppet、Chef等更native 的工具，已經(jīng)極大程度的降低了安裝OpenStack的門檻，我就不再過多闡述。而關(guān)于運(yùn)行期間如何排錯(cuò)，如何掌握系統(tǒng)的運(yùn)行狀態(tài)，在不了解系統(tǒng)實(shí)現(xiàn)原理的情況下，也會(huì)令人一籌莫展。當(dāng)然，已經(jīng)有很多發(fā)行版中包含了這部分功能。
本文的目的不是指導(dǎo)讀者寫一個(gè)新的類似的工具，而是分析為了配合這些工具，可以使用到的 OpenStack自身能力。當(dāng)然，系統(tǒng)的監(jiān)控運(yùn)維是一個(gè)大的話題，我能力和視野有限，噴不了那么多(沒有真正用過的東西，我也不愿意噴)，像主機(jī)的 CPU監(jiān)控、進(jìn)程監(jiān)控、網(wǎng)絡(luò)流量監(jiān)控、存儲(chǔ)監(jiān)控這些，也不在本文的范疇內(nèi)。
言歸正傳，說說本文主要內(nèi)容。OpenStack有很多模塊，但其中最為核心的當(dāng)然是Nova，所以本文就以Nova為例，來看一下如何通過Nova提供的能力來獲取系統(tǒng)運(yùn)行期間的狀態(tài)。我把這些狀態(tài)分為兩類，一類是系統(tǒng)整體情況一覽(系統(tǒng)狀態(tài))，而是虛擬機(jī)相關(guān)的狀態(tài)信息(虛擬機(jī)狀態(tài))。當(dāng)然，以我一貫的風(fēng)格，你會(huì)看到更多的OpenStack實(shí)現(xiàn)原理。
Nova版本：Kilo
系統(tǒng)狀態(tài)
Nova提供這么幾個(gè)資源狀態(tài)的查詢。
Service
Nova中的service有兩類，一類是所謂的control service，一類就是compute service。要想獲取Nova的service詳細(xì)信息，必須要啟用os-extended-services擴(kuò)展。
service的詳細(xì)信息主要包括如下幾項(xiàng)：
binary, host, zone, status, state
其中：
- binary，可以理解為service的名稱，類似于nova-compute。
- host是service所在的主機(jī)名稱。
zone是service所屬的AZ，其實(shí)就是service所在的主機(jī)所屬的aggregate，只是aggregate的概念不對外呈現(xiàn)，所以用戶看到的是AZ。其實(shí)，在Nova內(nèi)部，AZ是AG的metadata而已。
zone的確定，涉及到兩個(gè)配置項(xiàng)，對于非計(jì)算節(jié)點(diǎn)，zone的名稱依賴于配置項(xiàng)internalserviceavailability_zone(默認(rèn)是inte rnal)。
對于計(jì)算節(jié)點(diǎn)，如果不屬于任何AG，或者所屬的AG沒有AZ的metadata信息，默認(rèn)的zone依賴于配置項(xiàng)defaultavailabilityzone(默認(rèn)是nova)。
status是服務(wù)disable屬性的體現(xiàn)，該屬性可以直接通過API修改;
state是服務(wù)真實(shí)的狀態(tài)，是通過servicegroup api獲取。每個(gè)服務(wù)在啟動(dòng)時(shí)會(huì)加入servicegroup，以db后端為例，會(huì)在服務(wù)中啟動(dòng)定時(shí)器，更新service表中的report_count的值，同時(shí)也會(huì)刷新更新時(shí)間，后續(xù)會(huì)根據(jù)這個(gè)更新時(shí)間確定服務(wù)的死活;
當(dāng)然，查詢service信息也支持過濾條件，比如：
查詢某個(gè)host相關(guān)的service;
按binary名稱查詢service。
知道了service的信息后，就至少能夠獲取到Nova各個(gè)服務(wù)的運(yùn)行狀態(tài)，從而判斷系統(tǒng)是否健康。
Host
其實(shí)Nova中沒有host這個(gè)獨(dú)立的資源(數(shù)據(jù)庫對象)，但是Nova卻有針對host的API操作，其實(shí)，在內(nèi)部實(shí)現(xiàn)中，就是通過前面的service信息，間接組裝返回host信息。
即：你可以獲取系統(tǒng)中所有的主機(jī)信息，其中包括：主機(jī)名稱、主機(jī)上的服務(wù)、主機(jī)所屬的AZ。
Hypervisor
hypervisor的概念在OpenStack中其實(shí)不好理解。在使用KVM的環(huán)境中，hypervisor通常是就是只nova- compute進(jìn)程所在的主機(jī);而在類VMware環(huán)境中(之所以說類VMware，是因?yàn)槿A為也有一款虛擬化產(chǎn)品FusionCompute也是類似的架構(gòu))，hypervisor是指nova-compute進(jìn)程下的一個(gè)’node’，對應(yīng)于一個(gè)vCenter集群。換句話說，你可以把一個(gè) hypervisor看成一個(gè)nova-compute下的一個(gè)node，KVM的情況是一個(gè)特例而已。一個(gè)hypervisor，是創(chuàng)建虛擬機(jī)能夠調(diào)度到的最小單元。
Nova中對于hypervisor的查詢情況支持較為豐富。
- 查詢所有的hypervisor概要信息。包含一個(gè)id和一個(gè)hypervisor host name，如果啟用了os-hypervisor-status extension，還會(huì)返回hypervisor所屬的nova-compute服務(wù)狀態(tài)。
- 查詢所有的hypervisor詳細(xì)信息。除了包含上述信息外，還包含每個(gè)hypervisor的資源使用信息。如果啟用os- extended-hypervisors extension，還會(huì)包含hypervisor所屬的nova-compute所在主機(jī)的IP地址。
- 查詢所有hypervisor所使用的系統(tǒng)資源總量。即，系統(tǒng)計(jì)算資源使用量的一個(gè)總覽。
- 模糊查詢某些hypervisor的概要信息。
- 查詢單個(gè)hypervisor資源使用的詳細(xì)信息。
- 模糊查詢某些hypervisor上的虛擬機(jī)信息，包含虛擬機(jī)的ID和名稱。
可見，Nova中的hypervisor給管理員提供了較為豐富系統(tǒng)計(jì)算資源使用情況的查詢接口，通過對hypervisor使用情況的了解，管理員可以更有效地進(jìn)行系統(tǒng)監(jiān)控，并且為系統(tǒng)維護(hù)(擴(kuò)容、減容、動(dòng)態(tài)資源調(diào)整等)提供依據(jù)。
#p#
租戶視角的系統(tǒng)狀態(tài)
上面的幾個(gè)資源，默認(rèn)都是管理員有權(quán)限查詢，普通租戶是看不到的。那么作為租戶，能夠?qū)ο到y(tǒng)使用狀態(tài)有一個(gè)什么樣的了解呢?
租戶的資源配額
租戶可以查詢自己的資源配額限制和使用情況，管理員(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":
- ...
租戶的資源使用量
管理員可以查詢所有租戶對計(jì)算資源的使用量，也可以查詢某個(gè)租戶的計(jì)算資源使用量(包括每個(gè)虛擬機(jī)計(jì)算資源使用信息)，參見這里。
示例1，管理員查詢租戶對計(jì)算資源的使用量：
- {
- "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，查詢某個(gè)租戶的計(jì)算資源使用量：
- {
- "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#
虛擬機(jī)狀態(tài)
說到底，作為IaaS，OpenStack玩的還是虛擬機(jī)，因?yàn)楦鞣N資源(存儲(chǔ)、網(wǎng)絡(luò))都是為了更好的使用虛擬機(jī)服務(wù)。所以對虛擬機(jī)狀態(tài)的掌握就顯得格外重要。
虛擬機(jī)操作事件通知
用戶對虛擬機(jī)的每個(gè)操作(開始和結(jié)束)，都會(huì)通過消息隊(duì)列向外部發(fā)送通知，外部系統(tǒng)可以通過接收通知，了解系統(tǒng)的運(yùn)行過程。使用通知的另外一個(gè)好處，就是可以與Nova解耦，作為外部系統(tǒng)的數(shù)據(jù)源，實(shí)現(xiàn)系統(tǒng)的監(jiān)控分析。Ceilometer、StackTach和Monasca都用到了Nova的通知作為自己的數(shù)據(jù)源。
與此同時(shí)，虛擬機(jī)state或task_state發(fā)生變化時(shí)，也會(huì)向外部發(fā)送通知。前提是配置項(xiàng)notify_on_state_change要配置為vm_state或vm_and_task_state。
另外，Nova中除了上述說的操作事件通知外，還有一種審計(jì)通知，即在一段時(shí)間內(nèi)的系統(tǒng)資源狀態(tài)，相關(guān)的配置項(xiàng) instance_usage_audit_period，目前Nova中只有event_type類型為 compute.instance.exists一種審計(jì)通知，這種通知可以讓你對一段周期內(nèi)系統(tǒng)中存在的虛擬機(jī)有一個(gè)全局的了解。
虛擬機(jī)操作事件記錄
Nova中的虛擬機(jī)每個(gè)操作(啟動(dòng)、停止、暫停、恢復(fù)等)，都會(huì)在db中保存相關(guān)的操作記錄，給用戶提供查詢。利用這個(gè)功能，用戶對自己的虛擬機(jī)整個(gè)生命周期的過程和狀態(tài)都會(huì)了如指掌，便于用戶的管理。參見這里。示例如下：
- {
- "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)部實(shí)現(xiàn)中，nova-api層會(huì)記錄action開始的記錄，在nova-compute層，則會(huì)添加event開始和結(jié)束的信息，action和event根據(jù)request id(一次消息請求的標(biāo)識(shí))關(guān)聯(lián)。
虛擬機(jī)錯(cuò)誤信息記錄
因?yàn)镺penStack的安裝部署復(fù)雜性，或者操作過程對環(huán)境、配置等要求比較苛刻，稍不注意，就有可能發(fā)生錯(cuò)誤。一旦發(fā)生錯(cuò)誤，除了從日志中獲取錯(cuò)誤信息外，還有什么比較方便、快捷的方式能夠迅速定位錯(cuò)誤呢?
在API層發(fā)生錯(cuò)誤，用戶會(huì)立即看到錯(cuò)誤碼和錯(cuò)誤信息。但如果是在conductor，scheduler或compute層發(fā)生錯(cuò)誤呢?
OpenStack智慧的社區(qū)開發(fā)者們已經(jīng)為我們提供了這種能力。其實(shí)還是利用DB和通知機(jī)制來實(shí)現(xiàn)。
先說通知，虛擬機(jī)操作異常時(shí)，一般都會(huì)發(fā)送error通知，通知中包含異常的函數(shù)名稱、異常時(shí)函數(shù)的參數(shù)以及異常信息。
再說db，虛擬機(jī)操作異常時(shí)，無論是在conductor, scheduler還是compute層，除了會(huì)發(fā)送通知外，還會(huì)記錄異常信息到數(shù)據(jù)庫(instance_faults表)，當(dāng)查詢虛擬機(jī)信息時(shí)，會(huì)返回虛擬機(jī)的異常信息。
虛擬機(jī)診斷信息
租戶可以查詢虛擬機(jī)使用過程中的一些統(tǒng)計(jì)信息，比如虛擬機(jī)磁盤的讀寫情況、網(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ù)有限公司云計(jì)算領(lǐng)域OpenStack社區(qū)團(tuán)隊(duì)技術(shù)主管，2011年加入華為西安研究所，一直從事云計(jì)算相關(guān)方向的研發(fā)工作。于2012年開始研究OpenStack，其個(gè)人博客(CSDN博客：http://blog.csdn.net/lynn_kong，Github博客：http://lingxiankong.github.io/多次被業(yè)內(nèi)人士學(xué)習(xí)和轉(zhuǎn)載。同時(shí)，積極組織和推動(dòng)OpenStack在國內(nèi)的技術(shù)交流和活動(dòng)，多次以主講人的身份參加OpenStack西安meetup。
