揭開OpenStack 統(tǒng)計資源和資源調(diào)度的面紗
引言
運維的同事常常遇到這么四個問題：
- Nova 如何統(tǒng)計 OpenStack 計算資源?
- 為什么 free_ram_mb, free_disk_gb 有時會是負數(shù)?
- 即使 free_ram_mb, free_disk_gb 為負，為什么虛擬機依舊能創(chuàng)建成功?
- 資源不足會導(dǎo)致虛擬機創(chuàng)建失敗，但指定了 host 有時卻能創(chuàng)建成功?
本文以以上四個問題為切入點，結(jié)合 Kilo 版本 Nova 源碼，在默認 Hypervisor 為 Qemu-kvm 的前提下(不同 Hypervisor 的資源統(tǒng)計方式差別較大 )，揭開 OpenStack 統(tǒng)計資源和資源調(diào)度的面紗。
Nova 需統(tǒng)計哪些資源
云計算的本質(zhì)在于將硬件資源軟件化，以達到快速按需交付的效果，最基本的計算、存儲和網(wǎng)絡(luò)基礎(chǔ)元素并沒有因此改變。就計算而言，CPU、RAM 和 DISK等依舊是必不可少的核心資源。
從源碼和數(shù)據(jù)庫相關(guān)表可以得出，Nova 統(tǒng)計計算節(jié)點的四類計算資源：
1.CPU: 包括 vcpus(節(jié)點物理 cpu 總線程數(shù)), vcpus_used(該節(jié)點虛擬機的 vcpu 總和)
2.RAM: 包括 memory_mb(該節(jié)點總 ram)，memory_mb_used(該節(jié)點虛擬機的 ram 總和)，free_ram_mb(可用 ram)
Note: memory_mb = memory_mb_used + free_ram_mb
3.DISK：local_gb(該節(jié)點虛擬機的總可用 disk)，local_gb_used(該節(jié)點虛擬機 disk 總和)，free_disk_gb(可用 disk)
Note：local_gb = local_gb_used + free_disk_gb
4.其它：PCI 設(shè)備、CPU 拓撲、NUMA 拓撲和 Hypervisor 等信息
本文重點關(guān)注 CPU、RAM 和 DISK 三類資源。
Nova 如何收集資源
從 源碼 可以看出，Nova 每分鐘統(tǒng)計一次資源，方式如下：
CPU
- vcpus: libvirt 中 get_Info()
- vcpu_used: 通過 libvirt 中 dom.vcpus() 從而統(tǒng)計該節(jié)點上所有虛擬機 vcpu 總和
RAM
- memory: libvirt 中 get_Info()
- memory_mb_used：先通過 /proc/meminfo 統(tǒng)計可用內(nèi)存， 再用總內(nèi)存減去可用內(nèi)存得出(資源再統(tǒng)計時會重新計算該值)
DISK
- local_gb: os.statvfs(CONF.instances_path)
- local_gb_used: os.statvfs(CONF.instances_path)(資源再統(tǒng)計時會重新計算該值)
其它
- hypervisor 相關(guān)信息：均通過 libvirt 獲取
- PCI: libvirt 中 listDevices(‘pci’, 0)
- NUMA: livirt 中 getCapabilities()
那么問題來了，按照上述收集資源的方式，free_ram_mb, free_disk_gb 不可能為負數(shù)啊!別急，Nova-compute 在上報資源至數(shù)據(jù)庫前，還根據(jù)該節(jié)點上的虛擬機又做了一次資源統(tǒng)計。
Nova 資源再統(tǒng)計
首先分析為什么需要再次統(tǒng)計資源以及統(tǒng)計哪些資源。從 源碼 可以發(fā)現(xiàn)，Nova 根據(jù)該節(jié)點上的虛擬機再次統(tǒng)計了 RAM、DISK 和 PCI 資源。
為什么需再次統(tǒng)計 RAM 資源?以啟動一個 4G 內(nèi)存的虛擬機為例，虛擬機啟動前后，對比宿主機上可用內(nèi)存，發(fā)現(xiàn)宿主機上的 free memory 雖有所減少(本次測試減少 600 MB)，卻沒有減少到 4G，如果虛擬機運行很吃內(nèi)存的應(yīng)用，可發(fā)現(xiàn)宿主機上的可用內(nèi)存迅速減少 3G多。試想，以 64G 的服務(wù)器為例，假設(shè)每個 4G 內(nèi)存的虛擬機啟動后，宿主機僅減少 1G 內(nèi)存，服務(wù)器可以成功創(chuàng)建 64 個虛擬機，但是當這些虛擬機在跑大量業(yè)務(wù)時，服務(wù)器的內(nèi)存迅速不足，輕著影響虛擬機效率，重者導(dǎo)致虛擬機 shutdown等。除此以外，宿主機上的內(nèi)存并不是完全分給虛擬機，系統(tǒng)和其它應(yīng)用程序也需要內(nèi)存資源。因此必須重新統(tǒng)計 RAM 資源，統(tǒng)計的方式為：
free_memory = total_memory - CONF.reserved_host_memory_mb - 虛擬機理論內(nèi)存總和
CONF.reserved_host_memory_mb：內(nèi)存預(yù)留，比如預(yù)留給系統(tǒng)或其它應(yīng)用
虛擬機理論內(nèi)存總和：即所有虛擬機 flavor 中的內(nèi)存總和
為什么要重新統(tǒng)計 DISK 資源?原因與 RAM 大致相同。為了節(jié)省空間， qemu-kvm 常用 QCOW2 格式鏡像，以創(chuàng)建 DISK 大小為 100G 的虛擬機為例，虛擬機創(chuàng)建后，其鏡像文件往往只有幾百 KB，當有大量數(shù)據(jù)寫入時磁盤時，宿主機上對應(yīng)的虛擬機鏡像文件會迅速增大。而 os.statvfs 統(tǒng)計的是虛擬機磁盤當前使用量，并不能反映潛在使用量。因此必須重新統(tǒng)計 DISK 資源，統(tǒng)計的方式為：
free_disk_gb = local_gb - CONF.reserved_host_disk_mb / 1024 - 虛擬機理論磁盤總和
CONF.reserved_host_disk_mb：磁盤預(yù)留
虛擬機理論磁盤總和：即所有虛擬機 flavor 中得磁盤總和
當允許資源超配(見下節(jié))時，采用上述統(tǒng)計方式就有可能出現(xiàn) free_ram_mb, free_disk_gb 為負。
#p#
資源超配與調(diào)度
即使 free_ram_mb 或 free_disk_gb 為負，虛擬機依舊有可能創(chuàng)建成功。事實上，當 nova-scheduler 在調(diào)度過程中，某些 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 為例，在根據(jù) RAM 過濾宿主機時，過濾的原則為：
memory_limit = total_memory * ram_allocation_ratio
used_memory = total_memory - free_memory
memory_limit - used_memory < flavor[‘ram’]，表示內(nèi)存不足，過濾該宿主機;否則保留該宿主機。
相關(guān)代碼如下(稍有精簡)：
- 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 將成功創(chuàng)建虛擬機。
隨想：內(nèi)存和磁盤超配雖然能提供更多數(shù)量的虛擬機，當該宿主機上大量虛擬機的負載都很高時，輕著影響虛擬機性能，重則引起 qemu-kvm 相關(guān)進程被殺，即虛擬機被關(guān)機。因此對于線上穩(wěn)定性要求高的業(yè)務(wù)，建議不要超配 RAM 和 DISK，但可適當超配 CPU。建議這幾個參數(shù)設(shè)置為：
- 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 創(chuàng)建虛擬機
本節(jié)用于回答問題四，當所有宿主機的資源使用過多，即超出限定的超配值時(total_resource * allocation_ratio)，nova-scheduler 將過濾這些宿主機，若未找到符合要求的宿主機，虛擬機創(chuàng)建失敗。
創(chuàng)建虛擬機的 API 支持指定 host 創(chuàng)建虛擬機，指定 host 時，nova-scheduler 采取特別的處理方式：不再判斷該 host 上的資源是否滿足需求，而是直接將請求發(fā)給該 host 上的 nova-compute。
相關(guān)代碼如下(稍有精簡)：
- 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 依舊能成功創(chuàng)建虛擬機。
***，以一圖總結(jié)本文內(nèi)容
