引言
運維的同事常常遇到這么四個問題：
Nova 如何統計 OpenStack 計算資源?
為什么 free_ram_mb, free_disk_gb 有時會是負數?
即使 free_ram_mb, free_disk_gb 為負，為什么虛擬機依舊能創建成功?
資源不足會導致虛擬機創建失敗，但指定了 host 有時卻能創建成功?
本文以以上四個問題為切入點，結合 Kilo 版本 Nova 源碼，在默認 Hypervisor 為 Qemu-kvm 的前提下(不同 Hypervisor 的資源統計方式差別較大 )，揭開 OpenStack 統計資源和資源調度的面紗。
Nova 需統計哪些資源
云計算的本質在于將硬件資源軟件化，以達到快速按需交付的效果，最基本的計算、存儲和網絡基礎元素并沒有因此改變。就計算而言，CPU、RAM 和 DISK等依舊是必不可少的核心資源。
從源碼和數據庫相關表可以得出，Nova 統計計算節點的四類計算資源：
1.CPU: 包括 vcpus(節點物理 cpu 總線程數), vcpus_used(該節點虛擬機的 vcpu 總和)
2.RAM: 包括 memory_mb(該節點總 ram)，memory_mb_used(該節點虛擬機的 ram 總和)，free_ram_mb(可用 ram)
Note: memory_mb = memory_mb_used + free_ram_mb
3.DISK：local_gb(該節點虛擬機的總可用 disk)，local_gb_used(該節點虛擬機 disk 總和)，free_disk_gb(可用 disk)
Note：local_gb = local_gb_used + free_disk_gb
4.其它：PCI 設備、CPU 拓撲、NUMA 拓撲和 Hypervisor 等信息
本文重點關注 CPU、RAM 和 DISK 三類資源。
Nova 如何收集資源
從 源碼 可以看出，Nova 每分鐘統計一次資源，方式如下：
CPU
vcpus: libvirt 中 get_Info()
vcpu_used: 通過 libvirt 中 dom.vcpus() 從而統計該節點上所有虛擬機 vcpu 總和
RAM
memory: libvirt 中 get_Info()
memory_mb_used：先通過 /proc/meminfo 統計可用內存， 再用總內存減去可用內存得出(資源再統計時會重新計算該值)
DISK
local_gb: os.statvfs(CONF.instances_path)
local_gb_used: os.statvfs(CONF.instances_path)(資源再統計時會重新計算該值)
其它
hypervisor 相關信息：均通過 libvirt 獲取
PCI: libvirt 中 listDevices(‘pci’, 0)
NUMA: livirt 中 getCapabilities()
那么問題來了，按照上述收集資源的方式，free_ram_mb, free_disk_gb 不可能為負數啊!別急，Nova-compute 在上報資源至數據庫前，還根據該節點上的虛擬機又做了一次資源統計。
Nova 資源再統計
首先分析為什么需要再次統計資源以及統計哪些資源。從 源碼 可以發現，Nova 根據該節點上的虛擬機再次統計了 RAM、DISK 和 PCI 資源。
為什么需再次統計 RAM 資源?以啟動一個 4G 內存的虛擬機為例，虛擬機啟動前后，對比宿主機上可用內存，發現宿主機上的 free memory 雖有所減少(本次測試減少 600 MB)，卻沒有減少到 4G，如果虛擬機運行很吃內存的應用，可發現宿主機上的可用內存迅速減少 3G多。試想，以 64G 的服務器為例，假設每個 4G 內存的虛擬機啟動后，宿主機僅減少 1G 內存，服務器可以成功創建 64 個虛擬機，但是當這些虛擬機在跑大量業務時，服務器的內存迅速不足，輕著影響虛擬機效率，重者導致虛擬機 shutdown等。除此以外，宿主機上的內存并不是完全分給虛擬機，系統和其它應用程序也需要內存資源。因此必須重新統計 RAM 資源，統計的方式為：
free_memory = total_memory - CONF.reserved_host_memory_mb - 虛擬機理論內存總和
CONF.reserved_host_memory_mb：內存預留，比如預留給系統或其它應用
虛擬機理論內存總和：即所有虛擬機 flavor 中的內存總和
為什么要重新統計 DISK 資源?原因與 RAM 大致相同。為了節省空間， qemu-kvm 常用 QCOW2 格式鏡像，以創建 DISK 大小為 100G 的虛擬機為例，虛擬機創建后，其鏡像文件往往只有幾百 KB，當有大量數據寫入時磁盤時，宿主機上對應的虛擬機鏡像文件會迅速增大。而 os.statvfs 統計的是虛擬機磁盤當前使用量，并不能反映潛在使用量。因此必須重新統計 DISK 資源，統計的方式為：
free_disk_gb = local_gb - CONF.reserved_host_disk_mb / 1024 - 虛擬機理論磁盤總和
CONF.reserved_host_disk_mb：磁盤預留
虛擬機理論磁盤總和：即所有虛擬機 flavor 中得磁盤總和
當允許資源超配(見下節)時，采用上述統計方式就有可能出現 free_ram_mb, free_disk_gb 為負。
[page]資源超配與調度
即使 free_ram_mb 或 free_disk_gb 為負，虛擬機依舊有可能創建成功。事實上，當 nova-scheduler 在調度過程中，某些 filter 允許資源超配，比如 CPU、RAM 和 DISK 等 filter，它們默認的超配比為：
CPU: CONF.cpu_allocation_ratio = 16
RAM: CONF.ram_allocation_ratio = 1.5
DISK: CONF.disk_allocation_ratio = 1.0
以 ram_filter 為例，在根據 RAM 過濾宿主機時，過濾的原則為：
memory_limit = total_memory * ram_allocation_ratio
used_memory = total_memory - free_memory
memory_limit - used_memory 相關代碼如下(稍有精簡)： def host_passes(self, host_state, instance_type): """Only return hosts with sufficient available RAM.""" requested_ram = instance_type['memory_mb'] free_ram_mb = host_state.free_ram_mb total_usable_ram_mb = host_state.total_usable_ram_mb memory_mb_limit = total_usable_ram_mb * CONF.ram_allocation_ratio used_ram_mb = total_usable_ram_mb - free_ram_mb usable_ram = memory_mb_limit - used_ram_mb if not usable_ram >= requested_ram: LOG.debug("host does not have requested_ram") return False123456789101112 宿主機 RAM 和 DISK 的使用率往往要小于虛擬機理論使用的 RAM 和 DISK，在剩余資源充足的條件下，libvirt 將成功創建虛擬機。 隨想：內存和磁盤超配雖然能提供更多數量的虛擬機，當該宿主機上大量虛擬機的負載都很高時，輕著影響虛擬機性能，重則引起 qemu-kvm 相關進程被殺，即虛擬機被關機。因此對于線上穩定性要求高的業務，建議不要超配 RAM 和 DISK，但可適當超配 CPU。建議這幾個參數設置為： CPU: CONF.cpu_allocation_ratio = 4 RAM: CONF.ram_allocation_ratio = 1.0 DISK: CONF.disk_allocation_ratio = 1.0 RAM-Reserve: CONF.reserved_host_memory_mb = 2048 DISK-Reserve: CONF.reserved_host_disk_mb = 20480 指定 host 創建虛擬機 本節用于回答問題四，當所有宿主機的資源使用過多，即超出限定的超配值時(total_resource * allocation_ratio)，nova-scheduler 將過濾這些宿主機，若未找到符合要求的宿主機，虛擬機創建失敗。 創建虛擬機的 API 支持指定 host 創建虛擬機，指定 host 時，nova-scheduler 采取特別的處理方式：不再判斷該 host 上的資源是否滿足需求，而是直接將請求發給該 host 上的 nova-compute。 相關代碼如下(稍有精簡)： def get_filtered_hosts(self, hosts, filter_properties, filter_class_names=None, index=0): """Filter hosts and return only ones passing all filters.""" ... if ignore_hosts or force_hosts or force_nodes: ... if force_hosts or force_nodes: # NOTE(deva): Skip filters when forcing host or node if name_to_cls_map: return name_to_cls_map.values() return self.filter_handler.get_filtered_objects()123456789101112 當該 host 上實際可用資源時滿足要求時，libvirt 依舊能成功創建虛擬機。 最后，以一圖總結本文內容
京公網安備 11010502049343號