openstack自动绑核后Numa调度不均衡问题 1问题背景在某项目中，客户云平台底层使用openstack+ceph，在对虚拟机进行基准测试时，发现将虚拟机绑核在同一numa内可以提升stream和unixbench的性能。但需要提供自动绑核方案减少运维组的工作难度。给过分析，给出的自动绑核方案如下： (1)在控制节点的/etc/nova/nova.conf配置文件中，添加以下配置： [filter_scheduler] enabled_filters=…，NUMATopologyFilter 即在enabled_filters值尾部追加NUMATopologyFilter。修改后需重启相关服务。 (2)修改实例类型的配置执行以下命令，修改实例类型属性 openstack flavor set --property hw:numa_nodes=1 如果第1步中不添加NUMATopologyFilter，所有用这个实例类型创建出来的虚拟机cpu都会绑定在numa0上,不会分配在其他numa节点上。经过实验室验证，实施上述步骤后，创建出来的虚拟机cpu亲和性会先绑定在numa0上，待numa0上的cpu资源配额使用完毕后，再创建虚拟机会分配到下一个numa上，以此类推。例如鲲鹏5220机型，numa0上有32个cpu，nova没有设置cpu资源超额分配。创建的前面4台虚拟机cpu亲和性如下：在创建4个8c的虚拟机后，第5-8台虚拟机的cpu亲和性如下：但是在客户的环境上，不管创建了多少虚拟机，虚拟机的cpu亲和性始终绑定在numa0上，出现了numa调度不均衡的情况。 2问题排查和客户进行对比，客户创建虚拟机是通过他们的管理平台创建的，修改为使用命令创建后，发现导致该问题的原因为创建虚拟机时使用--availability-zone参数指定了宿主机。使用以下命令会导致创建出来的虚拟机cpu绑定在numa0上： openstack server create --flavor 8c8g-test --image openEuler-20.03-LTS-SP3 --nic net-id=private --security-group default --availability-zone nova:compute2 test-vm 使用以下命令创建的虚拟机表现正常： openstack server create --flavor 8c8g-test --image openEuler-20.03-LTS-SP3 --nic net-id=private --security-group default test-vm 以上两条命令的区别仅在于--availability-zone参数，该参数主要用于控制虚拟机创建在指定的物理机上，不添加该参数则虚拟机会被nova进行调度，自动选择合适的物理机来创建虚拟机。对于客户来说，通过云管理平台创建虚拟机，并且指定物理机是正常操作，必须满足该场景。 3解决方案修改/usr/lib/python3.7/site-packages/nova/scheduler/host_manager.py文件，在 if name_to_cls_map后添加这几行代码： for filter_ in self.enabled_filters: cls_name = filter_.__class__.__name__ if(cls_name='NUMATopologyFilter'): hosts = six.itervalues(name_to_cls_map) return self.filter_handler.get_filtered_objects([filter_],hosts,spec_obj,index) 修改完成后重启nova服务，经过验证，会在numa0上的cpu核分配完成后分配numa1上面的核。