程序员人生网站导航

Nova 是如何统计 OpenStack 计算资源

栏目：服务器时间：2015-05-05 08:32:27

引言

运维的同事常常遇到这么4个问题：

Nova 如何统计 OpenStack 计算资源？
为何 free_ram_mb, free_disk_gb 有时会是负数？
即便 free_ram_mb, free_disk_gb 为负，为何虚拟机照旧能创建成功？
资源不足会致使虚拟机创建失败，但指定了 host 有时却能创建成功？

本文以以上4个问题为切入点，结合 Kilo 版本 Nova 源码，在默许 Hypervisor 为 Qemu-kvm 的条件下(不同 Hypervisor 的资源统计方式差别较大 )，揭开 OpenStack 统计资源和资源调度的面纱。

Nova 需统计哪些资源

云计算的本质在于将硬件资源软件化，以到达快速按需交付的效果，最基本的计算、存储和网络基础元素并没有因此改变。就计算而言，CPU、RAM 和 DISK等照旧是必不可少的核心资源。

从源码和数据库相干表可以得出，Nova 统计计算节点的4类计算资源：

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 3类资源。

Nova 如何搜集资源

从源码可以看出，Nova 每分钟统计1次资源，方式以下：

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 在上报资源至数据库前，还根据该节点上的虚拟机又做了1次资源统计。

Nova 资源再统计

首先分析为何需要再次统计资源和统计哪些资源。从源码可以发现，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，它们默许的超配比为：

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 创建虚拟机

本节用于回答问题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图总结本文内容
这里写图片描述

------分隔线----------------------------

上一篇 JPA EntitManager进阶

下一篇 微商时代

------分隔线----------------------------