面向PaaS云平臺的輕量級虛擬化性能測試研究

肖桂榮，肖榮生

(福州大學(xué)福建省空間信息工程研究中心，福建 福州 350116)

0 引言

隨著大數(shù)據(jù)迅猛發(fā)展，數(shù)據(jù)規(guī)模越來越大，數(shù)據(jù)種類越來越多，依托于云平臺的各種應(yīng)用呈現(xiàn)出種類繁多這一特征[1]. 各種云平臺應(yīng)用所依賴的生產(chǎn)環(huán)境千差萬別，云平臺應(yīng)用對云平臺中的資源利用率、隔離性和快速部署性提出了要求. 為統(tǒng)一管理云應(yīng)用和集群資源，出現(xiàn)了集群復(fù)用技術(shù)，它可以提高資源利用率，實現(xiàn)平臺應(yīng)用的統(tǒng)一管理以及平臺資源的共享. 傳統(tǒng)的虛擬化技術(shù)已經(jīng)不能滿足PaaS(platform as a service)平臺這種場景的需求，而輕量級虛擬化在高效性、隔離性和快速性方面非常適合PaaS平臺這種要求[2-3]，所以輕量級虛擬化在各大互聯(lián)網(wǎng)公司得到廣泛的應(yīng)用. 例如百度基于Docker[4]開發(fā)了Matrix，Google在Kubernetes[5]集群管理系統(tǒng)中用Docker或Rkt[6]作為底層容器.

目前主流輕量級虛擬化技術(shù)主要有Docker、OpenVZ[7]和Rkt，它們在實現(xiàn)高效性、隔離性和快速性方面有共性也有異性. 不同云平臺應(yīng)用，對PaaS場景中高效性、隔離性和快速性要求不一樣，因此對輕量級虛擬化技術(shù)進行技術(shù)分析和性能評測顯得十分重要. 目前輕量級虛擬化技術(shù)沒有標(biāo)準(zhǔn)的性能評測標(biāo)準(zhǔn)，F(xiàn)elter等[8]對Docker和Kvm(kernel-based virtual machine)[9]在CPU、內(nèi)存等方面進行了性能比較，中國存儲網(wǎng)對Docker、Rkt、OpenVZ利弊進行對比分析[10]. 本文對Docker、OpenVZ和Rkt在資源控制、隔離性方面進行技術(shù)實現(xiàn)分析，對它們在高效性、隔離性和快速性上進行性能評測，并選取Kvm進行實驗對比，為PaaS云平臺虛擬化技術(shù)的選型提供依據(jù)和參考指標(biāo).

1 主流輕量級虛擬化技術(shù)分析

1) OpenVZ. OpenVZ是Linux平臺下操作系統(tǒng)級的服務(wù)器虛擬化解決方案. 在資源控制方面，OpenVZ通過User Beancounters限制各種內(nèi)核對象使用，F(xiàn)air CPU Scheduling實現(xiàn)容器內(nèi)處理器資源和進程調(diào)度，VCPU Affinity控制容器CPU個數(shù)，Disk Quotas控制磁盤使用比例，I/O Scheduling實現(xiàn)對I/O分配.

OpenVZ通過Namespaces實現(xiàn)對容器資源隔離，使用PID(proportion integration differentiation)、IPC(inter-process communication)、Mount、Network、UTS(unix timesharing system)以及USER等Namespaces實現(xiàn)資源的隔離，使OpenVZ的容器運行環(huán)境相對獨立，擁有獨立的進程ID、內(nèi)存段、文件系統(tǒng)、網(wǎng)絡(luò)和唯一標(biāo)識的Hostname.

2) Docker. Docker是dotCloud 開源的高級容器引擎. Docker通過Libcontainer中Cgroups實現(xiàn)對資源的控制. Cgroups是Linux內(nèi)核提供的限制進程資源使用的機制，包含Blkio、CPU、CPUAcct(CPU accounting controller)、CPUSet、Devices、Freezer、Memory、Net_cls(network classid)、Ns(namespace)等控制器，對Docker容器資源使用進行控制.

Docker使用Namespaces實現(xiàn)容器資源隔離，對容器PID，IPC，Mount，Network，UTS進行隔離，由于USER Namespaces中的復(fù)雜性，Libcontainer沒有實現(xiàn)，用戶可通過配置Capabilities、Selinux 、Apparmor 等實現(xiàn)安全隔離.

3) Rkt. Rkt是CoreOS開源的高安全性、高執(zhí)行效率以及強兼容能力的容器引擎. Rkt運行模式分為Privileged、Container/Cgroups、Virtual Machine三種[6]，是可插拔的. Rkt默認運行Container/Cgroups模式，通過Cgroups做資源控制，控制Rkt中Pod對CPU、內(nèi)存、磁盤I/O等物理機資源使用. 在Privileged運行模式下，Rkt通過Chroot(change root)實現(xiàn)對宿主機資源特定權(quán)限的控制，控制Pod對宿主機資源訪問. 當(dāng)應(yīng)用程序?qū)\行環(huán)境有全虛擬化要求時，Rkt支持在Virtual Machine運行模式下通過LKVM(lightweight kernel-based virtual machine)技術(shù)實現(xiàn)以全虛擬化模式運行Pod，使其資源控制相對獨立.

Rkt在默認運行模式下，使用Namespaces做資源隔離，使Rkt容器的網(wǎng)絡(luò)、進程等運行在獨立的環(huán)境中. 用戶可選Virtual Machine運行模式代替Container/Cgroups，以全虛擬化的方式運行Pod，使虛擬機擁有獨立內(nèi)核和虛擬機管理程序.

2 測試指標(biāo)與方法

2.1 測試指標(biāo)

本實驗的性能測試指標(biāo)包括輕量級虛擬化技術(shù)的高效性、隔離性和快速性. 高效性測試包括CPU、內(nèi)存、磁盤I/O、網(wǎng)絡(luò)四個方面，隔離性測試包括在CPU、內(nèi)存、磁盤、網(wǎng)絡(luò)接收、網(wǎng)絡(luò)發(fā)送、Fork Bomb六種壓力程序下對同宿主機下其它虛擬機性能影響，快速性針對虛擬機啟動速度進行測試. 為了與基于Cgroups和Namespaces技術(shù)實現(xiàn)的Docker進行對比，實驗中Rkt選擇默認Container/Cgroups運行模式，并選取Kvm對比測試. 為保證數(shù)據(jù)準(zhǔn)確性，宿主機為同一臺，宿主機系統(tǒng)為Centos 6.7，宿主機CPU、內(nèi)存、硬盤環(huán)境分別為Intel(R) Xeon(R) CPU E5-2640 v2 @ 2.00GHz、64G/DDR3 1333、1T/7200，具體性能測試指標(biāo)和標(biāo)準(zhǔn)檢查程序如表1所示.

表1 測試指標(biāo)與標(biāo)準(zhǔn)檢查程序

2.2 測試方法

2.2.1 高效性測試方法

CPU測試：實驗選取Intel? Optimized LINPACK[11]進行CPU性能測試，該工具采用高斯消元法求解N元一次稠密線性組來評價其CPU處理性能. 該基準(zhǔn)實驗是根據(jù)用戶指定的參數(shù)生成一個線性方程組，通過方程的求解時間和計算量來計算CPU的浮點性能. 實驗中計算10 000階的稠密線性代數(shù)方程組來評估CPU性能.

內(nèi)存測試：實驗選取STREAM[12]進行內(nèi)存測試. STREAM是一個組合的基準(zhǔn)測試，用來測試持續(xù)的內(nèi)存帶寬，包含對內(nèi)存Add, Copy, Scale和Triad 4種操作測試.

磁盤I/O測試：實驗選取IOzone[13]進行磁盤I/O性能測試. 通過IOzone測試不同模式下磁盤的讀寫性能，包含寫、讀、重復(fù)讀、重復(fù)寫模式下磁盤I/O性能測試. 本實驗測試1 GB的大文件，其中每條記錄大小為8 KB，對寫、讀、重復(fù)讀、重復(fù)寫磁盤性能進行測試.

網(wǎng)絡(luò)性能測試：實驗選取Netperf[14]進行網(wǎng)絡(luò)性能測試. Netperf工具以Client/Server方式工作，通過Netserver端偵聽Netperf進行網(wǎng)絡(luò)性能測試. 選取與宿主機同屬一局域網(wǎng)的一物理機運行Netperf的Server端，在實驗物理機的Native、Docker、OpenVZ和Rkt上分別運行Netperf 的Client端進行網(wǎng)絡(luò)性能測試.

2.2.2 隔離性測試方法

實驗選取StressTests[15]壓力測試工具，StressTests包含CPU、內(nèi)存、Fork、磁盤I/O、網(wǎng)絡(luò)方面的壓力測試程序. 另外，選取Apache Benchmark[16]模擬PaaS應(yīng)用，根據(jù)ab請求所用時間進行定量分析. 在一臺物理機上同時建立5個虛擬機(M1, M2, M3, M4, M5)，當(dāng)M1未運行StressTests壓力測試程序時，在M2, M3, M4, M5上運行Apache Benchmark模擬PaaS應(yīng)用，并獲取其平均消耗時間t1. 當(dāng)M1運行壓力測試程序時，在M2, M3, M4, M5上運行Apache Benchmark模擬PaaS應(yīng)用，并獲取其平均消耗時間t2. 通過將(t2-t1)/t1的值百分化，定量分析和評估各個虛擬化技術(shù)的隔離性能.

2.2.3 快速性測試方法

實驗設(shè)計一個DefinitionTime Benchmark程序, 該程序分為Server端，Client端，以及輔助程序Hander腳本. 實驗中Server端一直啟動，用于接收Client端和輔助程序Hander的Post請求，并記錄請求時間. 用戶通過Hander腳本啟動創(chuàng)建虛擬機，并給Server端發(fā)送Post請求，記錄Post請求時間t1. 當(dāng)虛擬機啟動創(chuàng)建好時執(zhí)行Client端，發(fā)送Post請求給Server端，記錄Post請求時間為t2，(t2-t1)為啟動創(chuàng)建一個可用虛擬機所需時間.

3 測試結(jié)果

3.1 高效性測試

1) CPU 性能測試. 實驗結(jié)果如圖1所示，Rkt和Docker的CPU性能和Native基本相同，OpenVZ性能損耗10%，Kvm虛擬機性能損耗60%. 因為Rkt和Docker與宿主機共享CPU，OpenVZ中FairCPU Scheduling需性能損耗，Kvm中Hypervisor層對CPU指令進行轉(zhuǎn)換，性能開銷大.

圖1 CPU測試Fig.1 CPU test

圖2 內(nèi)存測試Fig.2 Memory test

2) 內(nèi)存測試. 實驗結(jié)果如圖2所示，Docker虛擬機的內(nèi)存性能與Native幾乎一樣，Rkt虛擬機內(nèi)存性能與Native相近，OpenVZ內(nèi)存性能比Kvm略高，Kvm內(nèi)存性能損耗17%. 因為基于容器的虛擬化技術(shù)能返回未使用的內(nèi)存給主機或其它容器，使得高效地利用內(nèi)存，而基于管理程序的虛擬化層執(zhí)行內(nèi)存訪問指令的轉(zhuǎn)換消耗，造成性能損失.

3) 磁盤I/O測試. 實驗結(jié)果如圖3所示，Rkt磁盤性能與本地最接近，Docker磁盤性能與OpenVZ磁盤性能相似，但是在Read時Docker與OpenVZ性能消耗較多，Kvm性能最差. 因為Rkt文件系統(tǒng)是基于Pod創(chuàng)建，Docker基于AUFS文件系統(tǒng)，實現(xiàn)鏡像的寫時復(fù)制，OpenVZ中Disk Quotas需性能損耗，Kvm在管理層需對磁盤I/O命令進行轉(zhuǎn)換，性能消耗大.

4) 網(wǎng)絡(luò)性能測試. 實驗結(jié)果如圖4所示，Docker，OpenVZ和Rkt在網(wǎng)絡(luò)TCP方面的性能與本地接近，因為輕量級虛擬化在網(wǎng)絡(luò)方面支持都不強，基本都是使用本地I/O. Kvm在網(wǎng)絡(luò)方面的性能開銷較大，由于Kvm中獨立于主機的網(wǎng)絡(luò)I/O，設(shè)備驅(qū)動需要基于硬件的虛擬化層提供支持，訪問網(wǎng)絡(luò)I/O需要經(jīng)過一系列轉(zhuǎn)換才能執(zhí)行.

圖3 磁盤I/O測試Fig.3 Disk I/O test

圖4 網(wǎng)絡(luò)性能測試Fig.4 Network performance test

高效性性能測試結(jié)果表明，PaaS平臺應(yīng)用對CPU性能有高要求時適合選擇基于Rkt的PaaS云平臺，對內(nèi)存性能有高要求時適合選擇基于Docker的PaaS云平臺，對磁盤I/O有高要求時可以適合選擇基于Rkt的PaaS平臺，對TCP發(fā)送性能有高要求時適合選擇基于Docker的PaaS平臺，對TCP接收性能有高要求時適合選擇基于Rkt的PaaS平臺. 不同輕量級虛擬化技術(shù)因自身技術(shù)實現(xiàn)不同，在高效性上的性能測試表現(xiàn)不同，存在自身的優(yōu)缺點，用戶可以結(jié)合對CPU、內(nèi)存、磁盤I/O、網(wǎng)絡(luò)性能需求，并根據(jù)高效性性能測試結(jié)果選擇合適PaaS云平臺解決方案.

3.2 隔離性測試

表2 壓力測試結(jié)果

實驗結(jié)果如表2所示，CPU 壓力測試程序?qū)λ械奶摂M化技術(shù)都沒有影響，這表明Cgroups下CPU子系統(tǒng)和OpenVZ使用的VCPU Affinity都具有很好的CPU隔離性能. 在內(nèi)存隔離性上，Rkt和Docker都表現(xiàn)不好，而OpenVZ表現(xiàn)較好，說明Cgroups下Memory子系統(tǒng)的控制能力沒有User Beancounters好. 所有輕量級虛擬化技術(shù)在磁盤I/O和網(wǎng)絡(luò)I/O壓力測試程序下都有影響，因為輕量級虛擬化技術(shù)是在操作系統(tǒng)級別上對系統(tǒng)內(nèi)核和動態(tài)用戶進程進行支持的虛擬化技術(shù)，單個虛擬機在磁盤I/O和網(wǎng)絡(luò)I/O壓力下會對同宿主機其它虛擬機性能表現(xiàn)有影響. Fork Bomb是一個經(jīng)典的循環(huán)創(chuàng)建子進程的測試程序，它會一直創(chuàng)建進程，直到?jīng)]有可用資源. Fork Bomb的實驗結(jié)果表明Rkt和Docker存在一定的安全問題，因為Cgroups不能限制容器中的進程總數(shù). 通過實驗結(jié)果分析可知Kvm的隔離性比較好，因為Kvm虛擬機不與主機共享操作系統(tǒng)內(nèi)核，適合對內(nèi)存、磁盤、網(wǎng)絡(luò)隔離性有高要求的應(yīng)用部署.

隔離性測試結(jié)果表明，OpenVZ是輕量級虛擬化技術(shù)中隔離性最好的，適合用于對隔離性有較高要求的PaaS平臺構(gòu)建. 對于輕量級虛擬化技術(shù)在隔離性上的不足，用戶可以通過減少宿主機上虛擬機的個數(shù)來減緩對隔離性的影響，使用戶可以利用輕量級虛擬化技術(shù)的優(yōu)勢，同時彌補隔離性方面的不足.

3.3 快速性測試

表3 快速性測試結(jié)果

實驗結(jié)果如表3，Docker可以在0.1秒級啟動創(chuàng)建一個虛擬機，因為Docker是基于系統(tǒng)內(nèi)核Cgroups和Namespaces實現(xiàn). Rkt虛擬機創(chuàng)建時間比Docker稍慢，因為Docker容器進程由Docker Daemon守護進程接收命令工具消息進行Fork創(chuàng)建，Rkt容器進程由Rkt命令直接Fork創(chuàng)建，Rkt啟動的容器進程從屬于執(zhí)行Rkt的SSHD進程所在的Cgroups，Docker啟動的容器進程在一個獨立的Cgroups內(nèi). OpenVZ能在10秒級啟動創(chuàng)建，Kvm需要超過20 s的時間才能完成，因為OpenVZ創(chuàng)建虛擬機時需要鏡像拷貝，而Kvm虛擬機有獨立系統(tǒng)內(nèi)核，需要時間進行鏡像加載和系統(tǒng)初始化.

快速性測試結(jié)果表明，Docker具有最好的快速性，適合用于對快速性有高要求的PaaS平臺構(gòu)建. 對于其它虛擬化技術(shù)在快速性方面的不足，用戶可以通過提升宿主機硬件的方式提升快速性性能.

4 結(jié)語

分析Docker，OpenVZ和Rkt輕量級虛擬化技術(shù)在資源控制和隔離方面的技術(shù)實現(xiàn)，并對它們在高效性，隔離性和快速性方面進行測評. 實驗表明，OpenVZ具有較好的高效性，良好的隔離性，但快速性較差，適合對隔離性有高要求的PaaS場景； Docker具有很好的高效性，隔離性較弱，最好的快速性，適合對快速性和高效性有高要求的PaaS場景； Rkt具有最好的高效性，隔離性很弱，最好的快速性，適合對高效性有很高要求的PaaS場景； Kvm具有強隔離性，高效性和快速性表現(xiàn)較差，適合對隔離性有很高要求的場景. 研究結(jié)果對PaaS平臺輕量級虛擬化技術(shù)選型具有重要參考意義.

隨著基于輕量級虛擬化的PaaS云平臺的高速發(fā)展，傳統(tǒng)應(yīng)用部署難、遷移難、維護難等問題的日益突出，越來越多大數(shù)據(jù)相關(guān)應(yīng)用開始部署在基于輕量級虛擬化技術(shù)構(gòu)建的PaaS平臺上. 利用本文對面向PaaS平臺的輕量級虛擬化技術(shù)的研究成果，用戶可以根據(jù)應(yīng)用在高效性、隔離性、快速性上的權(quán)重選擇合適的PaaS平臺. 例如，分布式計算框架對高效性和快速性要求高，適合將計算框架打包成Rkt鏡像，使計算框架可以在基于Rkt的PaaS平臺上大規(guī)?？焖賳硬渴鹋c快速停止部署； 企業(yè)門戶網(wǎng)站對穩(wěn)定性要求高，高效性要求弱，為了減少應(yīng)用部署在PaaS平臺上其它服務(wù)對其干擾，對隔離性有一定要求，適合選擇基于OpenVZ構(gòu)建的PaaS平臺進行部署.

未來工作將研究測試不同宿主機操作系統(tǒng)中各輕量級虛擬化技術(shù)的性能表現(xiàn)，并針對Docker中不同文件管理系統(tǒng)中的各項性能進行評測，對Rkt中不同隔離機制下的性能表現(xiàn)進行對比分析.

[1] 林闖，蘇文博，孟坤，等． 云計算安全：架構(gòu)，機制與模型評價[J]. 計算機學(xué)報，2013，36(9)：1 765-1 784.

[2] 王亞玲，李春陽，崔蔚，等. 基于 Docker 的 PaaS 平臺建設(shè)[J]. 計算機系統(tǒng)應(yīng)用，2016，25(3)：72-77.

[3] MORABITO R. A performance evaluation of container technologies on Internet of things devices[C]//Computer Communications Workshops. San Francisco ：IEEE，2016：999-1 000.

[4] 于燁，李斌，劉思堯. Docker 技術(shù)的移植性分析研究[J]. 軟件，2015 (7)：57-60.

[5] 龔正，吳治輝，葉伙榮, 等. Kubernetes權(quán)威指南：從Docker到Kubernetes實踐全接觸[M]. 北京: 電子工業(yè)出版社, 2016.

[6] Rkt 官方幫助文檔[EB/OL]. (2014-11-27)[2016-04-01]. https://www.coreos.com/rkt/.

[7] BABU A，HAREESH M J，MARTIN J P，etal. System performance evaluation of para virtualization, container virtualization, and full virtualization using xen, openvz, and xenserver[C]//Advances in Computing and Communications. Cochin：IEEE，2014：247-250.

[8] FELTER W，F(xiàn)ERREIRA A，RAJAMONY R，etal. An updated performance comparison of virtual machines and linux containers[C]//Performance Analysis of Systems and Software. Philadelphia：IEEE，2015：171-172.

[9] 任永杰. KVM虛擬化技術(shù)實戰(zhàn)與原理解析[M]. 北京：機械工業(yè)出版社，2013.

[10] 中國存儲網(wǎng). 三大容器之戰(zhàn)Docker、Rocket/Rkt 和OpenVZ/Odin[EB/OL]. (2015-08-14)[2016-06-18]. http://www.chinastor.com/a/jishu/docker/0Q41A2H015.html.

[11] Intel? Optimized LINPACK官網(wǎng)[EB/OL]. (2013-09-27)[2016-04-16]. https://www.software.intel.com/zh-cn/articles/intel-mkl-benchmarks-suite.

[12] STREAM官網(wǎng)[EB/OL]. (2016-02-22)[2016-04-17]. http://www.cs.virginia.edu/stream/.

[13] IOzone[EB/OL]. (2016-01-23)[2016-04-26]. http://www.iozone.org/.

[14] Netperf[EB/OL]. (2015-06-21)[2016-05-10]. http://www.netperf.org/netperf/.

[15] StressTests[EB/OL]. (2007-01-14)[2016-05-16]. http://www.web2.clarkson.edu/class/cs644/isolation/index.html.

[16] Apache Benchmark[EB/OL]. (2015-12-20)[2016-05-29]. http://www.httpd.apache.org/.