基于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