基于Openstack的KVM虚拟机调优

张式勤　陈琪　丁伟

【摘 要】针对Openstack平台中KVM虚拟机CPU利用率异常过高的问题，从虚拟机CPU模式、NUMA运行状况两方面入手进行分析，通过调整Openstack参数、升级虚拟机操作系统等策略，提升了Openstack平台的可用性。未来，将通过cloud-init云个性初始化、Ceph系统维护与能力挖掘等措施进一步优化平台性能，在最大程度地发挥Openstack优势的同时规避其存在的短板和缺陷。

【关键词】Openstack KVM 虚拟机 调优

1 引言

浙江移动已经建设了面向业务支撑系统与管理信息系统等业务的私有云平台，平台虚拟化软件采用Vmware Vsphere 5.5 enterprise edition，目前已稳定运行了较长时间，但同时也存在以下不足：

（1）商业计算虚拟化软件价格过高，总体拥有成本偏高，有必要进行开源计算虚拟化软件验证研究。

（2）存储资源池是IaaS层的核心能力之一，能够提供灵活的分布式存储服务，现有存储资源池能力仅局限于传统磁盘阵列虚拟化，且占比较低，缺少基于X86服务器本地磁盘架构的分布式存储架构。

为了解决上述不足，浙江移动引入Openstack开源云化技术与Ceph开源分布式存储系统，将两者进行结合形成一个新模式的IaaS服务平台：

（1）基于一组思科UCS刀片服务器搭建Openstack平台（Juno版），采用KVM虚拟化技术，使Openstack具备Live Migration的能力。

（2）在Openstack网络模式选型上，综合考虑浙江移动IT系统自身架构的特点与Openstack的技术原理，定制了基于DVR的L3与Flat并存的网络模式，不仅为虚拟机提供了良好的网络性能，同时也具备了SDN的功能。

（3）选择阵列存储与Ceph分布式存储并存的模式，其中阵列存储主要用于主机操作系统的SAN Boot Disk，Ceph则为Openstack提供云存储。

2015年11月上旬，CRM APP系统所使用的KVM虚拟机的CPU出现了使用率过高异常的现象，异常率达到70%以上，相同业务压力下同性能配置的Vmware虚拟机的负载却非常低，只在10%以内波动，并且发现KVM宿主机的CPU使用率也异常高。由此可见，Openstack不是一个商业产品，为达到安全生产的标准，需要对其在虚拟机、网络、存储以及高可用性等方面进行模式选定与优化，在最大程度发挥Openstack优势的同时规避其存在的短板和缺陷。

2 原因分析

本文从两方面入手分析KVM虚拟机的CPU使用率过高异常的原因。

2.1 KVM虚拟机CPU模式

通过比较Vmware与KVM的虚拟机CPU信息，发现KVM虚拟机CPU模式存在如下问题：

（1）缺少L3 Cache：初步分析是虚拟机CPU虚拟化模式选择不合理所导致。

（2）CPU不是NUMA架构并且CPU Topology不合理：KVM宿主机物理CPU属于NUMA多node的结构，虚拟机的CPU只有一个NUMA node，所有CPU Core都在这一个node中，且虚拟机CPU的Topology是多Socket单Core的形式。KVM虚拟机CPU信息和Vmware虚拟机CPU信息分别如图1和图2所示。

2.2 KVM宿主机与NUMA运行状况

在NUMA的CPU内存架构下，无论是物理主机还是虚拟机，如果NUMA的配置不合理对应用程序的性能都有较大的影响，并且不同类型的应用都有不同的配置需求。

Vmware ESX 5.0及之后的版本支持vNUMA特性，它将Host的NUMA特征暴露给了GuestOS，从而使得Guest OS可以根据NUMA特征进行更高性能的调度。SUSE与Redhat作为原生的操作系统在NUMA调度上需人为根据应用程序类型做特殊配置。

在优化之前，CRM APP的KVM虚拟机的NUMA调度状态非常不理想，表现为所有NUMA节点的numa_miss统计数值大于numa_hit，这意味着CPU访问内存的路径不是优化的，存在大量CPU访问remote memory的情况。因为宿主机Ubuntu 12.02自身带有Automatic NUMA balancing，所以物理主机NUMA调度运行状态良好。

3 调优策略与效果

针对上述的原因分析，采取的调优策略如下所示。

3.1 KVM虚拟机CPU模式调优

（1）缺少L3 Cache

针对该问题，检查了Openstack的nova.conf配置文件libvirt部分的cpu_mode的参数配置是host-model，该参数含义是根据物理CPU的特性，选择一个最靠近的标准CPU型号进行虚拟化模拟。除了host-model外还可以有host-passthrough模式，该模式直接将物理CPU暴露给虚拟机使用，在虚拟机上完全可以看到的就是物理CPU的型號。

因Openstack仍承载业务，选择小范围修改cpu_mode的参数，通过将Openstack的代码文件driver.py中cpu_mode的取值修改为host-passthrough并重启宿主机上Nova-computer服务与KVM虚拟机，将自动重新生成虚拟机的libvirt.xml文件。

（2）CPU不是NUMA架构并且CPU Topology不合理

经过梳理Openstack虚拟机的创建流程，并查阅Openstack官方文档与代码，发现在Juno版的Openstack中，KVM的CPU拓扑可以通过image或者flavor进行元数据传递来定义，如果没有特别地定义此类元数据，则模拟的CPU将是多Socket单Core单NUMA节点的CPU，这样的CPU与物理CPU完全不同。同时通过nova命令对flavor增加了hw：numa_cpu、hw：numa_nodes、hw：cpu_sockets等属性。endprint

（3）调优效果

经过上述两个方面的调优，新建KVM虚拟机的CPU信息发生了如图3所示的改变，CPU的使用率有了明显下降，在10%～20%波动：

1）从单个NUMA节点变成4个NUMA节点。

2）具备了L3 Cache。

3）CPU的Topology从32个Socket每个Socket 1个Core，变成了4个Socket每个Socket 8个Core。

3.2 KVM宿主机与NUMA运行状况

升级KVM虚拟机的操作系统到SUSE12，新版本的SUSE支持Automatic NUMA balancing，并且操作系统检测到硬件属于NUMA架构时将自动开启。升级完成后，在新建的KVM虚拟机的dmesg日志中可以看到如下信息：

Enablingautomatic NUMA balancing Configure with numa_balancing=or sysctl

同时经过24小时的运行，CRM APP系统的KVM虚拟机运行状态良好，CPU利用率可以稳定在10%左右，同时NUMA调度也有了较大程度的改善。

3.3 调优成果总结

通过各环节的优化，KVM虚拟机的CPU利用率过高问题不再发生，整体运行达到Vmware虚拟机水平。

不同類型的应用程序对于NUMA的适应性不同，需要进行有针对性的优化。JAVA在NUMA方面也可尝试进行优化。参考Oracle官方文档，JAVA7针对并行扫描垃圾回收站（Parallel Scavenger Garbage Collector）加入了对NUMA体系结构的支持，实现了NUMA感知的内存分配器，由它为Java应用提供自动的内存分配优化。

目前RedHat7与SUSE 12都加入了NUMA自动负载均衡的特性，可以尽量采用较新版本的操作系统，无论是物理机还是虚拟机，对于NUMA调度的优化不仅与KVM虚拟机有关，其实物理主机也应该关注NUMA调度是否是最优的。

4 结束语

Openstack是一个开源的云计算操作系统，在实际生产环境中可以根据不同的需求进行二次优化和调整。浙江移动通过KVM虚拟机调优完善了Openstack平台的功能，增强了平台的可用性，后续将在以下几个方面继续优化：

（1）cloud-init云个性初始化

通过cloud-init个性化制定虚拟机镜像，自适应不同业务系统要求，实现一个高效自动化的IaaS服务平台。

（2）Ceph系统维护与能力挖掘

目前Ceph搭建在Openstack计算节点中，较高程度的耦合不利于维护。同时Ceph对硬件有一定的要求，如较高吞吐能力的带宽和一定数量I/O性能较高的磁盘。目前已搭建的Openstack平台的Ceph瓶颈在于UCS内置磁盘的数量与性能，后续可尝试使用SSD磁盘提高OSD磁盘的整体性能。

（3）Openstack升级

Openstack做为一个开源项目，更新较快，不同版本在模式兼容性方面也存在问题，如何对运行环境进行升级是日后需要研究的问题。

参考文献：

[1] OpenStack Foundation. OpenStack Architecture Design Guide[EB/OL]. [2015-05-30]. http：//docs.openstack.org/arch-design/content/index.html.

[2] OpenStack Foundation. OpenStack Installation Guide for openSUSE 13.1 and SUSE Linux Enterprise Server 11 SP3[EB/OL]. [2015-05-30]. http：//docs.openstack.org/juno/install-guide/install/zypper/content/.

[3] Kenneth Hui. Designing a Multi-Hypervisor Cloud[EB/OL]. [2015-02-03]. http：//cloudarchitectmusings.com/2013/08/22/openstack-compute-for-vsphere-admins-part-5-designing-a-multi-hypervisor-cloud/.

[4] 吴庆波. Linux的NUMA技术[EB/OL]. [2015-05-30]. http：//www.ibm.com/developerworks/cn/linux/l-numa/.

[5] IBM Corporation. Tuning KVM for performance[EB/OL]. [2015-05-30]. http：//www.ibm.com/support/knowledgecenter/api/content/linuxonibm/liaat/liaattuning_pdf.pdf.

[6] 黄堆荣. Openstack J版本 NUMA特性相关分析[EB/OL]. （2014-12-08）[2015-05-30]. http：//blog.csdn.net/canxinghen/article/details/41810241.

[7] OPENSTACK. Virt driver guest NUMA node placement & topology[EB/OL]. [2015-05-30]. https：//specs.openstack.org/openstack/nova-specs/specs/juno/implemented/virt-driver-numa-placement.html.

[8] OPENSTACK. VirtDriverGuestCPUMemoryPlacement[EB/OL]. [2015-05-30]. https：//wiki.openstack.org/wiki/VirtDriverGuestCPUMemoryPlacement.

[9] OPENSTACK. OpenStack performance optimization[EB/OL]. [2015-05-30]. http：//events.linuxfoundation.org/sites/events/files/slides/kvm-forum-2014-openstack-perf.pdf.

[10] Steve Gordon. Driving in the Fast Lane—CPU Pinning and NUMA Topology Awareness in OpenStack Compute[EB/OL]. [2015-05-30]. http：//redhatstackblog.redhat.com/2015/05/05/cpu-pinning-and-numa-topology-awareness-in-openstack-compute/.endprint