轉載自：https://www.talkwithtrend.com/Article/240419
OpenStack有三種資源視圖，分別爲用戶視圖、OpenStack視圖以及系統視圖，這幾個資源視圖經常容易混淆。我們將這三種視圖做個對比。
1 用戶視圖
用戶視圖是站在用戶的視角所看到的資源，位於資源抽象的最頂端。對於用戶來說，底層是個無限量的巨大抽象資源池，所能使用的資源僅僅受管理員的配額限制。用戶視圖的資源也稱爲邏輯資源，它的資源量通常與底層物理資源沒有關係，因爲底層資源對用戶是透明的。用戶視圖的資源在其所在的租戶內是封閉的，與其他租戶的資源完全隔離並且無感知。
用戶視圖資源使用量在OpenStack中通常稱爲quota usage，我們可以通過OpenStack的API獲取資源的使用量，以塊存儲資源Cinder爲例，查看其quota usage：
~/int32bit # cinder quota-usage 240e267f0c4043b3aac9123b4e7e85a0+----------------------+--------+----------+-------+| Type | In_use | Reserved | Limit |+----------------------+--------+----------+-------+| backup_gigabytes | 9 | 0 | 5120 || backups | 3 | 0 | 100 || gigabytes | 8 | 0 | 1000 || per_volume_gigabytes | 100 | 0 | -1 || snapshots | 10 | 0 | 10 || volumes | 4 | 0 | 10 |+----------------------+--------+----------+-------+
其中Limit就是配額的上限，即允許用戶申請的最大資源量，-1表示無限制。
quota usage包含三個閾值：
- limit：用戶允許使用的最大資源上限，當用戶超出limit資源時請求將直接被拒回。
- reserve：預留資源，即已分配資源給用戶但資源尚未被使用，比如用戶申請虛擬機，虛擬機已經完成調度但還未創建完成。
- usage：用戶已經使用的資源量。
以上三個數值關係滿足：
當limit不等於-1時， usage + reserve <= limit
limit由管理員設置，當管理員創建一個新的租戶時，默認繼承自稱爲default quota class的值，創建完成後管理員可以根據需要修改配額值。
2 OpenStack視圖
前面的用戶視圖資源是以租戶爲單位劃分的，而OpenStack視圖是個全局資源的概念，統計了OpenStack所納管資源的總量和使用量，因此OpenStack視圖的資源通常又稱爲物理資源。OpenStack基於該資源使用以及分佈情況進行調度。當資源不足時，將導致虛擬機調度失敗，用戶請求不會報錯，但虛擬機狀態爲ERROR。
但是需要注意的是，OpenStack視圖的資源是按分配量計算的，而不是按照實際使用量統計。比如用戶申請了一臺2C 4GB的雲主機，但該雲主機關機了，此時雲主機實際上並不佔用任何CPU和內存，但OpenStack在統計中還是需要減去2C 4GB資源。對於OpenStack來說，已經分配的資源，不管用戶究竟有沒有在使用，除非刪除，否則不會被回收，也不能被其他虛擬機搶佔。
OpenStack統計的資源總量在不超售的情況下等於所有物理資源總和，但如果設置了超售，OpenStack實際分配的資源可能大於資源總量。
OpenStack Nova通過hypervisor-stats查看整個集羣的資源使用情況:
~/int32bit # nova hypervisor-stats+----------------------+---------+| Property | Value |+----------------------+---------+| count | 18 || current_workload | 0 || disk_available_least | 3617 || free_disk_gb | 1562 || free_ram_mb | 1018842 || local_gb | 4452 || local_gb_used | 2890 || memory_mb | 4322820 || memory_mb_used | 3303978 || running_vms | 291 || vcpus | 561 || vcpus_used | 1148 |+----------------------+---------+
需要注意的是，以上統計的是整個集羣的物理資源，而不是單個計算節點的資源，這意味着並不是總量滿足請求資源就可以調度，可能存在資源碎片導致調度虛擬機失敗。比如，假設有20臺計算節點，每個計算節點剩餘2GB內存，統計總量內存剩餘量爲2GB * 20 == 40GB，但用戶若申請一臺4GB內存的虛擬機調度仍然會失敗，原因是沒有任何一個計算節點滿足內存資源。
要查看單個計算節點的資源可以使用hypervisor-show子命令:
~/int32bit # nova hypervisor-show 1+---------------------------+-----------------+| Property | Value |+---------------------------+-----------------+| free_disk_gb | 561 || free_ram_mb | 58978 || local_gb | 1181 || local_gb_used | 620 || memory_mb | 262002 || memory_mb_used | 203024 || vcpus | 32 || vcpus_used | 86 ||... | ... |+---------------------------+-----------------+
3 系統視圖
系統視圖是指資源供給者(provider)的資源統計，這是操作系統級別的統計，包括了宿主機的進程以及虛擬機所佔用的資源，我們可以通過free命令查看內存使用情況。OpenStack通過ceilometer收集宿主機的資源使用情況，與之相關的meters如下:
$ ceilometer meters-listhost.cpu.utilhost.disk.read.speedhost.disk.utilhost.disk.write.speedhost.memory.util...
需要注意的是，OpenStack調度時不會考慮計算節點的實時系統資源，而只考慮OpenStack視圖下的分配資源。經常有一些人在創建虛擬機由於內存不足導致調度失敗時，就跑去計算節點運行free命令，發現free命令結果中顯示內存還夠，於是很疑惑爲什麼會調度失敗，這就是弄混了OpenStack視圖下的資源和系統視圖下的資源統計。
4 三者的聯繫
理論上其實這三者並無聯繫，層層抽象，層層透明。但管理員在設置用戶的配額信息時肯定會參考OpenStack集羣的資源情況，而OpenStack視圖的資源總量是從計算節點的物理資源總量收集的，換句話說，只有資源總量存在一定的關聯，資源使用量以及剩餘量完全沒有關係，各自統計各自的，互不干擾。
注意：
- 當用戶資源配額不足(
request + usage > limit時，用戶申請新的資源請求將直接被駁回，提示資源配額不足。 - 當OpenStack資源不足時，用戶申請新的資源的請求不會報錯，但最終資源會調度失敗，創建的虛擬機狀態爲
Error. - 當計算節點的系統資源不足時，這個後果比較嚴重，可能出現OOM導致該節點的大量虛擬機被系統殺掉，虛擬機直接宕機，業務終止。管理員應該避免出現這種情況，儘量不要設置過高的超售比。
以下列舉幾個常見的場景對三個視圖資源的影響。
| 場景 | 用戶視圖 | OpenStack視圖 | 系統視圖 |
|---|---|---|---|
| 創建一臺2C4GB虛擬機 | CPU-2, RAM-2 | CPU-2,RAM-2 | 虛擬機所在計算節點可用資源減少 |
| 關機一臺虛擬機 | 不變 | 不變 | 虛擬機所在計算節點可用資源增加 |
| 增加一個計算節點(16C16G) | 不變 | CPU+16,RAM+16 | 不變 |
| 刪除一臺2C4GB虛擬機 | CPU+2,RAM+4 | CPU+2,RAM+4 | 虛擬機所在計算節點可用資源增加 |
| 掛起(suspend)一臺2C4GB虛擬機 | 不變 | 不變 | 虛擬機所在計算節點可用資源增加 |
| 擱置(shelve)一臺2C4GB虛擬機 | CPU+2,RAM+4 | CPU+2,RAM+4 | 虛擬機所在計算節點可用資源增加 |