運維的同事常常遇到這么4個問題：
本文以以上4個問題為切入點，結合 Kilo 版本 Nova 源碼，在默許 Hypervisor 為 Qemu-kvm 的條件下(不同 Hypervisor 的資源統計方式差別較大 )，揭開 OpenStack 統計資源和資源調度的面紗。
云計算的本質在于將硬件資源軟件化，以到達快速按需交付的效果，最基本的計算、存儲和網絡基礎元素并沒有因此改變。就計算而言，CPU、RAM 和 DISK等照舊是必不可少的核心資源。
從源碼和數據庫相干表可以得出，Nova 統計計算節點的4類計算資源：
本文重點關注 CPU、RAM 和 DISK 3類資源。
從 源碼 可以看出，Nova 每分鐘統計1次資源，方式以下：
那末問題來了，依照上述搜集資源的方式，free_ram_mb, free_disk_gb 不可能為負數??！別急，Nova-compute 在上報資源至數據庫前，還根據該節點上的虛擬機又做了1次資源統計。
首先分析為何需要再次統計資源和統計哪些資源。從 源碼 可以發現，Nova 根據該節點上的虛擬機再次統計了 RAM、DISK 和 PCI 資源。
為何需再次統計 RAM 資源？以啟動1個 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，它們默許的超配比為：
以 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。建議這幾個參數設置為：
本節用于回答問題4，當所有宿主機的資源使用過量，即超越限定的超配值時(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 照舊能成功創建虛擬機。
最后，以1圖總結本文內容
下一篇 微商時代
程序員人生，我編程，我富裕，記住wfuyu網，php教程，php學習，php手冊，CMS模版制作
聲明：本站大部分內容是作者原創，少部分收集于互聯網供大家一起學習，原版權很多不明，如有侵權請聯系本站，謝謝！
粵ICP備14040726號-1?? 2015-2020 程序員人生 版權所有
