作者|朱勇

绑核方案

1. 在控制节点的“/etc/nova/nova.conf”配置文件中，添加以下配置：

   [filter_scheduler] 
   enabled_filters=…，NUMATopologyFilter

2. 修改后需重启相关服务。
3. 执行以下命令修改实例类型的配置。

   openstack flavor set --property hw:numa_nodes=1 <flavor-name>

如果步骤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调度不均衡的情况。

问题排查

客户创建虚拟机是通过他们的管理平台创建的，修改为使用命令创建后，发现导致该问题的原因为创建虚拟机时使用--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进行调度，自动选择合适的物理机来创建虚拟机。

对于客户来说，通过云管理平台创建虚拟机，并且指定物理机是正常操作，必须满足该场景。

解决方案

修改“/usr/lib/python3.7/site-packages/nova/scheduler/host_manager.py”文件。

1. 打开“/usr/lib/python3.7/site-packages/nova/scheduler/host_manager.py”文件。

   vim /usr/lib/python3.7/site-packages/nova/scheduler/host_manager.py

2. 按“i”进入编辑模式，在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)

3. 按“Esc”键退出编辑模式，输入:wq!，按“Enter”键保存退出文件。
4. 修改完成后重启nova服务即可实现在NUMA0上的CPU核分配完成后分配NUMA1上面的核。