OpenStack中CPU绑定方法总结

来自：
前一篇对CPU Topology进行了学习总结，这里想总结下OpenStack下vCPU与pCPU常用的的绑定方式。 在尝试这些绑定之前，尤其是处理NUMA架构时还是建议看看前一篇文章，或者google一下相关概念，这样才能灵活自如。

使用启动参数isolcpus控制操作系统级别的CPU隔离

存在这样的一个需求,Compute节点操作系统自身与Hypervisor两个怎样才能隔离开，也就是不能让系统自身的服务占用了虚拟化资源。 解决起来很简单，就是指定操作系统只能用哪些cpu,而剩下的是留给hypervisor用的。具体的实现就是使用了isolcpus内核启动参数。

如isolcpus=4,5,6,7,8,表示系统启动后新进程不会使用4-8cpu，

isolcpus = [KNL,SMP]
    format: <cpu number>,...,<cpu number> or <cpu number>-<cpu number> or <cpu number>,...,<cpu number>-<cpu number> 

isolcpus的原理也很简单:通过设置进程的cpu亲和性来实现.启动时设置init进程的亲和性,后续的进程均会继承init进程的亲和性设置. 这样就达到了整个系统的亲和性一致．如果后续的用户想修改亲和性可以通过taskset来实现.

永久生效需要在grub中修改kernel的启动参数.

使用taskset设置进程亲和性

tasket使用非常简单,能够实时的进行cpu亲和性设置.

# 设置亲和性 taskset -cp mask pid taskset -cp 0-3 1234 # 获取亲和性 taskset -cp pid taskset -cp 1234 

使用Cgroup进行Cpu QOS

Cgroup能够管理cpu资源.cgroup使用了特殊的文件系统，可以像正常的文件操作一样完成cgroup的设置．也可是使用特定的命令来进行设置．具体操作可以参考Linux的Cgroup

Cgroup能够控制隔离cpu资源,但是更多的是QOS功能.

vCPUs Bindings on KVM

virsh vcpupin guest1 4 0,1,2,3,8,9,10,11 

主要是使用virsh vcpupin命令来实现，上面就是将虚机guest1的vcpu 4绑定到host的0,1,2,3,8,9,10,11上.

vCPUs Bindings On Openstack

I版的时候cpu bingdings非常简单,只要设置nova的vcpu_pin_set即可,也是挺粗糙的.

#nova.conf [DEFAULT]
...
vcpu_pin_set=4-31 

J版的时候社区完善了功能,可以针对numa特性来进行绑定了.在numa体系中玩binding不是那么简单了.应该能提供一点帮助.

• Guest Numa策略 更多查看
  • hw:numa_nodes=NN - numa of NUMA nodes to expose to the guest.
  • hw:numa_mempolicy=preferred|strict - memory allocation policy
  • hw:numa_cpus.0= - mapping of vCPUS N-M to NUMA node 0
  • hw:numa_cpus.1= - mapping of vCPUS N-M to NUMA node 1
  • hw:numa_mem.0= - mapping N GB of RAM to NUMA node 0
  • hw:numa_mem.1= - mapping N GB of RAM to NUMA node 1
• vCPUs与pCPUs的绑定,更多查看[vcpu与pcpu的绑定
  • hw:cpu_policy=shared|dedicated
  • hw:cpu_threads_policy=avoid|separate|isolate|prefer, 只有hw:cpu_policy为dedicated时本属性才生效
    • avoid: the scheduler will not place the guest on a host which has hyperthreads.
    • separate: if the host has threads, each vCPU will be placed on a different core. ie no two vCPUs will be placed on thread siblings
    • isolate: if the host has threads, each vCPU will be placed on a different core and no vCPUs from other guests will be able to be placed on the same core. ie one thread sibling is guaranteed to always be unused,
    • prefer: if the host has threads, vCPU will be placed on the same core, so they are thread siblings.

举例(未验证)

管理员可以设置flavor的元数据来控制vm行为.

nova flavor-key m1.large set hw:numa_mempolicy=strict hw:numa_cpus.0=0,1,2,3 hw:numa_cpus.1=4,5,6,7 hw:numa_mem.0=1 hw:numa_mem.1=1 hw:cpu_policy=decicated hw:cpu_threads_policy=separate 

用户可以自己设置image元数据来达到定制需求，当然flavor的元数据优先级是高于image优先级的.

glance image-update image_id –property hw_numa_mempolicy=strict –property hw_numa_cpus.0=0,1,2,3 –property hw_numa_cpus.1=4,5,6,7 –property hw_numa_mem.0=1 –property hw_numa_mem.1=1 --property hw_cpu_policy=decicated --property hw_cpu_threads_policy=separate 

上面的例子中,cpu的绑定hw:cpu_threads_policy参数其实是不起作用的，到M版代码中也没有相关实现.如果cpu_policy=decicated时,host开启超线程,相关vcpu会绑定在同一个core的threads上， 这样的绑定方式会导致vm性能很差, Be careful! 官方文档有的时候很坑……

参考文档

以上文档建议阅读

变更记录

Why	Who	When
create	fishcired	2014-11-27
整理	fishcired	2015-01-05
完善	fishcired	2015-01-09
验证例子	fishcired	2016-03-28