Nova 是如何統計 OpenStack 計算資源

引言

運維的同事常常遇到這麼四個問題：

• 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 統計計算節點的四類計算資源：

• CPU: 包括 vcpus(節點物理 cpu 總線程數), vcpus_used(該節點虛擬機的 vcpu 總和)
• RAM: 包括 memory_mb(該節點總 ram)，memory_mb_used(該節點虛擬機的 ram 總和)，free_ram_mb(可用 ram)
  Note: memory_mb = memory_mb_used + free_ram_mb
• DISK：local_gb(該節點虛擬機的總可用 disk)，local_gb_used（該節點虛擬機 disk 總和），free_disk_gb(可用 disk)
  Note：local_gb = local_gb_used + free_disk_gb
• 其它：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 爲負。

資源超配與調度

即使 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 < flavor[‘ram’]，表示內存不足，過濾該宿主機；否則保留該宿主機。

相關代碼如下(稍有精簡)：

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 False

宿主機 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()

當該 host 上實際可用資源時滿足要求時，libvirt 依舊能成功創建虛擬機。

最後，以一圖總結本文內容