openStack kvm 虚拟机CPU颗粒化控制
前一篇理解cpu topology对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不是那么简单了.理解cpu topology应该能提供一点帮助. Guest Numa策略 更多查看virt-driver-numa-placement bp 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的绑定Virt driver pinning guest vCPUs to host pCPUs 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!官方文档有的时候很坑…… 参考文档 Pinning processors by common threads and cores https://wiki.openstack.org/wiki/VirtDriverGuestCPUMemoryPlacement 以上文档建议阅读
