系統狀態
Nova提供這么幾個資源狀態的查詢。
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的概念不對外呈現，所以用戶看到的是AZ。其實，在Nova內部，AZ是AG的metadata而已。
- zone的確定，涉及到兩個配置項，對於非計算節點，zone的名稱依賴於配置項internalserviceavailability_zone（默認是inte rnal）。
- 對於計算節點，如果不屬於任何AG，或者所屬的AG沒有AZ的metadata信息，默認的zone依賴於配置項defaultavailabilityzone（默認是nova）。
- status是服務disable屬性的體現，該屬性可以直接通過API修改;
- state是服務真實的狀態，是通過servicegroup api獲取。每個服務在啟動時會加入servicegroup，以db后端為例，會在服務中啟動定時器，更新service表中的
report_count的值，同時也會刷新更新時間，后續會根據這個更新時間確定服務的死活；
當然，查詢service信息也支持過濾條件，比如：
- 查詢某個host相關的service；
- 按binary名稱查詢service。
$ nova --help |grep service- service-delete Delete the service. service-disable Disable the service. service-enable Enable the service. service-list Show a list of all running services. Filter by
$ nova help service-disable usage: nova service-disable [--reason <reason>] <hostname> <binary> Disable the service. Positional arguments: <hostname> Name of host. <binary> Service binary. $ nova service-disable ThinkStation nova-scheduler +----------------------+----------------+----------+ | Host | Binary | Status | +----------------------+----------------+----------+ | ThinkStation | nova-scheduler | disabled | +----------------------+----------------+----------+
service-list
+----+------------------+----------------------+----------+---------+-------+----------------------------+-----------------+ | Id | Binary | Host | Zone | Status | State | Updated_at | Disabled Reason | +----+------------------+----------------------+----------+---------+-------+----------------------------+-----------------+ | 3 | nova-scheduler | ThinkStation | internal | disabled | up | 2015-11-10T07:39:00.000000 | - |
將service標記為disable的作用是什么?
我們再來看看service-delete的實現
objects.Service.get_by_id(context, service_id).destroy()
通過soft_delete在DB中對該服務做上標記。
知道了service的信息后，就至少能夠獲取到Nova各個服務的運行狀態，從而判斷系統是否健康。
Host
其實Nova中沒有host這個獨立的資源（數據庫對象），但是Nova卻有針對host的API操作，其實，在內部實現中，就是通過前面的service信息，間接組裝返回host信息。
即：你可以獲取系統中所有的主機信息，其中包括：主機名稱、主機上的服務、主機所屬的AZ。
$ nova service-list +----+------------------+----------------------+----------+---------+-------+----------------------------+-----------------+ | Id | Binary | Host | Zone | Status | State | Updated_at | Disabled Reason | +----+------------------+----------------------+----------+---------+-------+----------------------------+-----------------+ | 1 | nova-conductor | ThinkStation | internal | enabled | up | 2015-11-10T07:38:08.000000 | - | | 2 | nova-cert | ThinkStation | internal | enabled | up | 2015-11-10T07:38:05.000000 | - | | 3 | nova-scheduler | ThinkStation | internal | enabled | up | 2015-11-10T07:38:00.000000 | - | | 4 | nova-consoleauth | ThinkStation | internal | enabled | up | 2015-11-10T07:38:01.000000 | - | | 5 | nova-compute | ThinkStation | nova | enabled | up | 2015-11-10T07:38:00.000000 | - | +----+------------------+----------------------+----------+---------+-------+----------------------------+-----------------+
$ nova host-list
+----------------------+-------------+----------+
| host_name | service | zone |
+----------------------+-------------+----------+
| ThinkStation | conductor | internal |
| ThinkStation | cert | internal |
| ThinkStation | consoleauth | internal |
| ThinkStation | compute | nova |
+----------------------+-------------+----------+
所以host的信息是通過service的信息來拼裝：
nova/api/openstack/compute/hosts.py
services = self.api.service_get_all(context, filters=filters, set_zones=True) hosts = [] for service in services: hosts.append({'host_name': service['host'], 'service': service['topic'], 'zone': service['availability_zone']}) return {'hosts': hosts}
compute/apy.py
result = self.rpcapi.host_power_action(context, action=action,
host=host_name)
compute/rpcapi.py
def host_power_action(self, ctxt, action, host): version = '4.0' cctxt = self.client.prepare(server=host, version=version) return cctxt.call(ctxt, 'host_power_action', action=action
host的信息較少，通過ComputeNode：
$ nova host-describe ThinkStation +----------------------+----------------------------------+-----+-----------+---------+ | HOST | PROJECT | cpu | memory_mb | disk_gb | +----------------------+----------------------------------+-----+-----------+---------+ | ThinkStation | (total) | 8 | 15935 | 901 | | ThinkStation | (used_now) | 1 | 1024 | 1 | | ThinkStation | (used_max) | 1 | 512 | 1 | | ThinkStation | 0d777ab85d9949c6ab961c6a883f3f40 | 1 | 512 | 1 | +----------------------+----------------------------------+-----+-----------+---------+
Hypervisor
hypervisor的概念在OpenStack中其實不好理解。在使用KVM的環境中，hypervisor通常是就是只nova-compute進程所在的主機；而在類VMware環境中（之所以說類VMware，是因為華為也有一款虛擬化產品FusionCompute也是類似的架構），hypervisor是指nova-compute進程下的一個’node’，對應於一個vCenter集群。換句話說，你可以把一個hypervisor看成一個nova-compute下的一個node，KVM的情況是一個特例而已。一個hypervisor，是創建虛擬機能夠調度到的最小單元。
Nova中對於hypervisor的查詢情況支持較為豐富。
- 查詢所有的hypervisor概要信息。包含一個id和一個hypervisor host name，如果啟用了os-hypervisor-status extension，還會返回hypervisor所屬的nova-compute服務狀態。
- 查詢所有的hypervisor詳細信息。除了包含上述信息外，還包含每個hypervisor的資源使用信息。如果啟用os-extended-hypervisors extension，還會包含hypervisor所屬的nova-compute所在主機的IP地址。
- 查詢所有hypervisor所使用的系統資源總量。即，系統計算資源使用量的一個總覽。
- 模糊查詢某些hypervisor的概要信息。
- 查詢單個hypervisor資源使用的詳細信息。
- 模糊查詢某些hypervisor上的虛擬機信息，包含虛擬機的ID和名稱。
可見，Nova中的hypervisor給管理員提供了較為豐富系統計算資源使用情況的查詢接口，通過對hypervisor使用情況的了解，管理員可以更有效地進行系統監控，並且為系統維護（擴容、減容、動態資源調整等）提供依據。
租戶視角的系統狀態
上面的幾個資源，默認都是管理員有權限查詢，普通租戶是看不到的。那么作為租戶，能夠對系統使用狀態有一個什么樣的了解呢？
租戶的資源配額
租戶可以查詢自己的資源配額限制和使用情況，管理員（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
}
}
虛擬機狀態
說到底，作為IaaS，OpenStack玩的還是虛擬機，因為各種資源（存儲、網絡）都是為了更好的使用虛擬機服務。所以對虛擬機狀態的掌握就顯得格外重要。
虛擬機操作事件通知
用戶對虛擬機的每個操作（開始和結束），都會通過消息隊列向外部發送通知，外部系統可以通過接收通知，了解系統的運行過程。使用通知的另外一個好處，就是可以與Nova解耦，作為外部系統的數據源，實現系統的監控分析。Ceilometer、StackTach和Monasca都用到了Nova的通知作為自己的數據源。
與此同時，虛擬機state或task_state發生變化時，也會向外部發送通知。前提是配置項notify_on_state_change要配置為vm_state或vm_and_task_state。
另外，Nova中除了上述說的操作事件通知外，還有一種審計通知，即在一段時間內的系統資源狀態，相關的配置項instance_usage_audit_period，目前Nova中只有event_type類型為compute.instance.exists一種審計通知，這種通知可以讓你對一段周期內系統中存在的虛擬機有一個全局的了解。
虛擬機操作事件記錄
Nova中的虛擬機每個操作（啟動、停止、暫停、恢復等），都會在db中保存相關的操作記錄，給用戶提供查詢。利用這個功能，用戶對自己的虛擬機整個生命周期的過程和狀態都會了如指掌，便於用戶的管理。參見這里。示例如下：
{
"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"
}
]
}
在內部實現中，nova-api層會記錄action開始的記錄，在nova-compute層，則會添加event開始和結束的信息，action和event根據request id（一次消息請求的標識）關聯。
虛擬機錯誤信息記錄
因為OpenStack的安裝部署復雜性，或者操作過程對環境、配置等要求比較苛刻，稍不注意，就有可能發生錯誤。一旦發生錯誤，除了從日志中獲取錯誤信息外，還有什么比較方便、快捷的方式能夠迅速定位錯誤呢？
在API層發生錯誤，用戶會立即看到錯誤碼和錯誤信息。但如果是在conductor，scheduler或compute層發生錯誤呢？
OpenStack智慧的社區開發者們已經為我們提供了這種能力。其實還是利用DB和通知機制來實現。
- 先說通知，虛擬機操作異常時，一般都會發送error通知，通知中包含異常的函數名稱、異常時函數的參數以及異常信息。
- 再說db，虛擬機操作異常時，無論是在conductor, scheduler還是compute層，除了會發送通知外，還會記錄異常信息到數據庫（
instance_faults表），當查詢虛擬機信息時，會返回虛擬機的異常信息。
虛擬機診斷信息
租戶可以查詢虛擬機使用過程中的一些統計信息，比如虛擬機磁盤的讀寫情況、網絡的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
}