本文選自極術(shù)專(zhuān)欄“軟硬件融合”，授權(quán)轉(zhuǎn)自微信公眾號(hào)軟硬件融合，本篇將詳細(xì)評(píng)測(cè)虛擬機(jī)和容器的性能損耗在相關(guān)的應(yīng)用場(chǎng)景下的性能對(duì)比。

編者按

大家一直對(duì)虛擬機(jī)和容器的性能損耗都有一定的認(rèn)識(shí)，但具體多少應(yīng)該沒(méi)有幾個(gè)人能說(shuō)清楚。這篇文章詳細(xì)的評(píng)測(cè)了相關(guān)的應(yīng)用場(chǎng)景在容器、虛擬機(jī)、裸機(jī)三種場(chǎng)景下的性能對(duì)比，相信會(huì)對(duì)大家有所幫助。

參考鏈接：

An Updated Performance Comparison of Virtual Machines and Linux Containers, IBM Research
https://dominoweb.draco.res.ibm.com/reports/rc25482.pdf

摘要

云計(jì)算大量使用虛擬機(jī)(VM)，因?yàn)榭梢酝ㄟ^(guò)VM把工作負(fù)載彼此隔離，并在一定程度上控制資源使用。然而，虛擬化所涉及的額外抽象代價(jià)降低了工作負(fù)載的性能，并將其作為成本和性能降低轉(zhuǎn)嫁給了客戶(hù)?；谌萜鞯奶摂M化簡(jiǎn)化了應(yīng)用程序的部署，同時(shí)仍允許對(duì)分配給不同應(yīng)用程序的資源進(jìn)行控制。

在本文中，我們探討了傳統(tǒng)虛擬機(jī)部署的性能，并將其與Linux容器的使用進(jìn)行了對(duì)比。

我們使用一組工作負(fù)載，對(duì)CPU、內(nèi)存、存儲(chǔ)和網(wǎng)絡(luò)資源造成壓力。我們使用KVM作為虛擬化的Hypervisor，使用Docker作為容器管理器。

我們的結(jié)果顯示，在幾乎所有情況下，容器的性能都與VM相同或更好。VM和容器都需要優(yōu)化以支持IO密集型應(yīng)用程序。我們還討論了性能結(jié)果對(duì)未來(lái)云架構(gòu)的影響。

一、介紹

虛擬機(jī)廣泛應(yīng)用于云計(jì)算中。特別是，基礎(chǔ)設(shè)施即服務(wù)(Infrastructure as a Service, IaaS)中的最新技術(shù)在很大程度上等同于虛擬機(jī)。像Amazon EC2這樣的云平臺(tái)讓用戶(hù)可以使用VM，也可以在VM中運(yùn)行數(shù)據(jù)庫(kù)這樣的服務(wù)。許多“平臺(tái)即服務(wù)”(PaaS)和“軟件即服務(wù)”(SaaS)提供商都構(gòu)建在IaaS之上，它們的所有工作負(fù)載都運(yùn)行在VM中。

由于目前幾乎所有的云工作負(fù)載都在VM中運(yùn)行，所以VM性能是整體云性能的關(guān)鍵部分。一旦Hypervisor的開(kāi)銷(xiāo)增加，沒(méi)有任何其他層的手段可以刪除它。這樣的開(kāi)銷(xiāo)將成為云工作負(fù)載性能的普遍負(fù)擔(dān)。

有許多研究顯示了VM執(zhí)行與裸機(jī)執(zhí)行的對(duì)比情況，此類(lèi)研究已經(jīng)成為普遍提高VM技術(shù)質(zhì)量的一個(gè)激勵(lì)因素。

基于容器的虛擬化為云中的虛擬機(jī)提供了一個(gè)有趣的替代方案。虛擬專(zhuān)用服務(wù)器提供商，可能被視為云計(jì)算的先驅(qū)，已經(jīng)使用容器超過(guò)十年了。但他們中的許多人轉(zhuǎn)向VM以提供更一致的性能。盡管很好地理解了名稱(chēng)空間等容器的基礎(chǔ)概念，但是容器技術(shù)一直處于停滯狀態(tài)，直到因?yàn)樾枰焖俨渴鸬男枰琍aaS提供者采用并標(biāo)準(zhǔn)化了容器，使得采用容器來(lái)提供隔離和資源控制的復(fù)興。

Linux由于其免費(fèi)、龐大的生態(tài)系統(tǒng)、良好的硬件支持、良好的性能和可靠性而成為云計(jì)算的首選操作系統(tǒng)。在Linux中實(shí)現(xiàn)容器所需的內(nèi)核名稱(chēng)空間特性很早前就被討論，但直到最近幾年才變得成熟。在過(guò)去的兩年中，Docker已經(jīng)成為L(zhǎng)inux容器的標(biāo)準(zhǔn)運(yùn)行時(shí)、鏡像格式和構(gòu)建系統(tǒng)。

本文著眼于目前實(shí)現(xiàn)資源控制的兩種不同方式，即容器和虛擬機(jī)，并比較了兩種環(huán)境中一組工作負(fù)載的性能，以及與無(wú)虛擬化環(huán)境的性能。除了一系列強(qiáng)調(diào)計(jì)算、內(nèi)存帶寬、內(nèi)存延遲、網(wǎng)絡(luò)帶寬和I/O帶寬等不同方面的基準(zhǔn)測(cè)試外，我們還探討了兩個(gè)真實(shí)應(yīng)用程序的性能，即Redis和MySQL在不同環(huán)境下的性能。

我們的目標(biāo)是隔離并理解虛擬機(jī)(特別是KVM)和容器(特別是Docker)相對(duì)于非虛擬化Linux所帶來(lái)的開(kāi)銷(xiāo)。我們希望其他管理程序，如Xen、VMware ESX和Microsoft Hyper-V，能夠提供與KVM類(lèi)似的性能，因?yàn)樗鼈兪褂孟嗤挠布铀偬匦浴?/p>

同樣地，當(dāng)其他容器工具使用相同的機(jī)制時(shí)，它們應(yīng)該具有與Docker相同的性能。我們不評(píng)估在VM中運(yùn)行容器或在容器中運(yùn)行VM的情況，因?yàn)槲覀冋J(rèn)為這種雙重虛擬化是冗余的(至少?gòu)男阅芙嵌葋?lái)看)。Linux可以同時(shí)承載VM和容器，這一事實(shí)為這兩種技術(shù)之間的相互比較創(chuàng)造了機(jī)會(huì)——與以前的許多比較相比，混淆變量更少一些。

我們做出了如下貢獻(xiàn)：

我們提供了一個(gè)本地、容器和虛擬機(jī)環(huán)境的最新比較，使用最新的硬件和軟件，以及與云相關(guān)的有趣的基準(zhǔn)測(cè)試和工作負(fù)載。

我們確定了當(dāng)前虛擬化選項(xiàng)對(duì)高性能計(jì)算和服務(wù)器工作負(fù)載的主要性能影響。

我們?cè)敿?xì)闡述了一些影響虛擬化性能的不明顯的實(shí)際問(wèn)題。

我們證明，即使在整個(gè)服務(wù)器的規(guī)模下，容器也是可行的，且對(duì)性能的影響很小。

本文的其余部分組織如下：

第二節(jié)描述Docker和KVM，為理解論文的其余部分提供必要的背景；

第三節(jié)描述并評(píng)估這三個(gè)環(huán)境上的不同工作負(fù)載；

第四部分對(duì)相關(guān)工作進(jìn)行了回顧；

第五部分對(duì)全文進(jìn)行了總結(jié)。

二、背景

2.1 云虛擬化的動(dòng)機(jī)和要求

Unix傳統(tǒng)上并沒(méi)有強(qiáng)烈地實(shí)現(xiàn)最小權(quán)限原則，即“系統(tǒng)的每個(gè)程序和每個(gè)用戶(hù)都應(yīng)該使用完成工作所需的最小權(quán)限集進(jìn)行操作。”以及最不常見(jiàn)的機(jī)制原則，即“每個(gè)共享機(jī)制……代表了用戶(hù)之間的潛在信息路徑，在設(shè)計(jì)時(shí)必須非常小心，以確保它不會(huì)無(wú)意地危及安全性。”Unix中的大多數(shù)對(duì)象，包括文件系統(tǒng)、進(jìn)程和網(wǎng)絡(luò)堆棧，對(duì)所有用戶(hù)都是全局可見(jiàn)的。

Unix的共享全局文件系統(tǒng)造成的一個(gè)問(wèn)題是缺乏配置隔離。多個(gè)應(yīng)用程序可能對(duì)系統(tǒng)范圍的配置設(shè)定有沖突的要求。共享庫(kù)依賴(lài)關(guān)系尤其有問(wèn)題，因?yàn)楝F(xiàn)代應(yīng)用程序使用許多庫(kù)，而且不同的應(yīng)用程序通常需要相同庫(kù)的不同版本。當(dāng)在一個(gè)操作系統(tǒng)上安裝多個(gè)應(yīng)用程序時(shí)，系統(tǒng)管理的成本可能超過(guò)軟件本身的成本。

普通服務(wù)器操作系統(tǒng)中的這些弱點(diǎn)導(dǎo)致管理員和開(kāi)發(fā)人員通過(guò)將每個(gè)應(yīng)用程序安裝在單獨(dú)的操作系統(tǒng)副本上(或者在專(zhuān)用服務(wù)器上，或者在虛擬機(jī)上)來(lái)簡(jiǎn)化部署。與共享服務(wù)器相比，這種隔離與在應(yīng)用程序之間共享任何代碼、數(shù)據(jù)或配置所需的顯式操作恰恰相反。

不管環(huán)境如何，客戶(hù)都想要得到他們?yōu)橹顿M(fèi)的性能。與基礎(chǔ)設(shè)施和工作負(fù)載屬于同一家公司的企業(yè)整合場(chǎng)景不同，在IaaS和PaaS中，提供者和客戶(hù)之間存在一種獨(dú)立的關(guān)系。這使得解決性能異常變得困難，所以*aaS提供商通常提供固定的容量單位(CPU內(nèi)核和RAM)，而沒(méi)有超額訂閱。虛擬化系統(tǒng)需要強(qiáng)制執(zhí)行這種資源隔離，以適應(yīng)云基礎(chǔ)設(shè)施的使用。

2.2 KVM

內(nèi)核虛擬機(jī)(KVM)是Linux的一個(gè)特性，它允許Linux充當(dāng)類(lèi)型1的Hypervisor，在Linux進(jìn)程中運(yùn)行未經(jīng)修改的Guest操作系統(tǒng)(OS)。

KVM在較新的處理器中使用硬件虛擬化特性來(lái)降低復(fù)雜性和開(kāi)銷(xiāo)；例如，Intel VT-x硬件消除了對(duì)復(fù)雜的Ring壓縮方案的需要，而這些方案是由早期的hypervisor，如Xen和VMware，所開(kāi)創(chuàng)的。

KVM既支持通過(guò)QEMU模擬I/O設(shè)備，也支持使用virtio的半虛擬（paravirtual）I/O設(shè)備。硬件加速和半虛擬I/O的結(jié)合是為了將虛擬化開(kāi)銷(xiāo)降低到非常低的水平。KVM支持實(shí)時(shí)遷移，允許騰出物理服務(wù)器甚至整個(gè)數(shù)據(jù)中心進(jìn)行維護(hù)，而不會(huì)中斷Guest操作系統(tǒng)。KVM也很容易通過(guò)libvirt等工具來(lái)管理。

因?yàn)樘摂M機(jī)有靜態(tài)數(shù)量的虛擬CPU (vCPU)和固定數(shù)量的RAM，它的資源消耗自然是有限的。一個(gè)vCPU不能使用一個(gè)以上的實(shí)際CPU周期，vRAM的每一頁(yè)最多映射到物理RAM的一頁(yè)(加上嵌套的頁(yè)表)。

KVM可以在運(yùn)行時(shí)通過(guò)“熱插拔”和“氣球”vCPU和vRAM來(lái)調(diào)整虛擬機(jī)的大小，盡管這需要客戶(hù)操作系統(tǒng)的支持，并且在云中很少使用。

因?yàn)槊總€(gè)虛擬機(jī)都是一個(gè)進(jìn)程，所以所有普通的Linux資源管理工具，如調(diào)度和cgroups(稍后將詳細(xì)描述)都適用于虛擬機(jī)。這簡(jiǎn)化了Hypervisor的實(shí)現(xiàn)和管理，但使Guest操作系統(tǒng)內(nèi)的資源管理變得復(fù)雜。操作系統(tǒng)通常假定CPU一直在運(yùn)行，內(nèi)存具有相對(duì)固定的訪問(wèn)時(shí)間，但在KVM下，vCPU可以在不通知的情況下被取消調(diào)度，虛擬RAM可以被換出，從而導(dǎo)致難以調(diào)試的性能異常。

虛擬機(jī)也有兩個(gè)級(jí)別的分配和調(diào)度：一個(gè)在hypervisor中，另一個(gè)在Guest操作系統(tǒng)中。

許多云提供商通過(guò)不過(guò)度使用資源、將每個(gè)vCPU固定到一個(gè)物理CPU、將所有虛擬RAM鎖定到實(shí)際RAM來(lái)解決這些問(wèn)題。(不幸的是，OpenStack還沒(méi)有啟用vCPU釘住功能，導(dǎo)致與私有公有云相比性能參差不齊。)這基本上消除了系統(tǒng)管理程序中的調(diào)度。這種固定的資源分配也簡(jiǎn)化了計(jì)費(fèi)。

由于狹窄的接口，虛擬機(jī)自然的提供了一定級(jí)別的隔離和安全；VM與外部世界通信的唯一方式是通過(guò)有限數(shù)量的超hypercall或模擬設(shè)備，它們都由hypervisor控制。這不是靈丹妙藥，因?yàn)橐呀?jīng)發(fā)現(xiàn)了一些Hypervisor特權(quán)升級(jí)漏洞，它們可能允許Guest操作系統(tǒng)“打破”其VM“沙箱”。

雖然VM擅長(zhǎng)隔離，但當(dāng)在Guest之間或Guest和Hypervisor之間共享數(shù)據(jù)時(shí)，它們?cè)黾恿碎_(kāi)銷(xiāo)。通常，這種共享需要相當(dāng)昂貴的編組和hypercall。在云中，虛擬機(jī)通常通過(guò)映像文件支持的模擬塊設(shè)備訪問(wèn)存儲(chǔ)；創(chuàng)建、更新和部署這樣的磁盤(pán)映像可能非常耗時(shí)，而包含大部分重復(fù)內(nèi)容的磁盤(pán)映像集合可能會(huì)浪費(fèi)存儲(chǔ)空間。

2.3 Linux容器

與虛擬硬件上運(yùn)行完整操作系統(tǒng)不同，基于容器的虛擬化通過(guò)修改操作系統(tǒng)以提供額外的隔離。通常，這包括向每個(gè)進(jìn)程添加一個(gè)容器ID，并向每個(gè)系統(tǒng)調(diào)用添加新的訪問(wèn)控制檢查。

因此，容器可以看作是除了用戶(hù)和組權(quán)限系統(tǒng)之外的另一個(gè)級(jí)別的訪問(wèn)控制。在實(shí)踐中，Linux使用下面描述的更復(fù)雜的實(shí)現(xiàn)。

Linux容器是一個(gè)建立在內(nèi)核命令空間特性上的概念，最初是用于處理高性能計(jì)算集群場(chǎng)景而產(chǎn)生的。這個(gè)特性可以被clone()系統(tǒng)調(diào)用訪問(wèn)，允許創(chuàng)建之前全局名稱(chēng)空間的獨(dú)立實(shí)例。Linux實(shí)現(xiàn)了文件系統(tǒng)、PID、網(wǎng)絡(luò)、用戶(hù)、IPC和主機(jī)名名稱(chēng)空間。例如，每個(gè)文件系統(tǒng)名稱(chēng)空間都有自己的根目錄和掛載表，類(lèi)似于chroot()，但功能更強(qiáng)大。

名稱(chēng)空間可以通過(guò)許多不同的方式使用，但最常見(jiàn)的方法是創(chuàng)建一個(gè)隔離的容器，該容器對(duì)容器外部的對(duì)象屏蔽可見(jiàn)性或訪問(wèn)權(quán)。運(yùn)行在容器內(nèi)的進(jìn)程看起來(lái)像是運(yùn)行在普通的Linux系統(tǒng)上，盡管它們與位于其他名稱(chēng)空間中的進(jìn)程共享底層內(nèi)核。容器可以分層嵌套，盡管這種功能還沒(méi)有得到充分的挖掘。

與運(yùn)行完整操作系統(tǒng)的VM不同，容器可以只包含單個(gè)進(jìn)程。像一個(gè)完整的操作系統(tǒng)一樣運(yùn)行init、inetd、sshd、syslogd、cron等的容器稱(chēng)為系統(tǒng)容器，而只運(yùn)行應(yīng)用程序的容器稱(chēng)為應(yīng)用程序容器。這兩種類(lèi)型在不同的情況下都有用。由于應(yīng)用程序容器不會(huì)在冗余管理進(jìn)程上浪費(fèi)RAM，因此它通常比同等的系統(tǒng)容器或VM消耗更少的RAM。應(yīng)用程序容器通常沒(méi)有獨(dú)立的IP地址，這在地址缺乏的環(huán)境中是一個(gè)優(yōu)勢(shì)。

如果不希望完全隔離，那么很容易在容器之間共享一些資源。例如，綁定掛載允許一個(gè)目錄出現(xiàn)在多個(gè)容器中，可能在不同的位置。這是在Linux VFS層中有效實(shí)現(xiàn)的。容器之間或容器與主機(jī)(實(shí)際上可能只是父名稱(chēng)空間)之間的通信與普通Linux IPC一樣高效。

Linux控制組(cgroups)子系統(tǒng)用于對(duì)進(jìn)程進(jìn)行分組并管理它們的總資源消耗。它通常用于限制容器的內(nèi)存和CPU消耗。一個(gè)容器可以通過(guò)簡(jiǎn)單地改變其相應(yīng)的cgroup的限制來(lái)調(diào)整大小。Cgroups還提供了一種終止容器內(nèi)所有進(jìn)程的可靠方法。因?yàn)橐粋€(gè)容器化的Linux系統(tǒng)只有一個(gè)內(nèi)核，并且內(nèi)核對(duì)容器有完全的可見(jiàn)性，所以只有一個(gè)級(jí)別的資源分配和調(diào)度。

容器資源管理一個(gè)未解決的問(wèn)題是，在容器中運(yùn)行的進(jìn)程不知道它們的資源限制。例如，一個(gè)進(jìn)程可以看到系統(tǒng)中所有的CPU，即使它只被允許運(yùn)行在其中一個(gè)子集上運(yùn)行；這問(wèn)題，同樣適用于內(nèi)存。如果應(yīng)用程序試圖根據(jù)可用的系統(tǒng)總資源分配資源來(lái)自動(dòng)調(diào)優(yōu)自身，那么在資源受限的容器中運(yùn)行時(shí)，它可能會(huì)過(guò)度分配資源。隨著容器的成熟，這一限制可能會(huì)得到解決。

安全容器往往比管理Unix權(quán)限更簡(jiǎn)單，因?yàn)槿萜鞑荒茉L問(wèn)它不能看到的內(nèi)容，因此意外的權(quán)限越界的可能性大大降低。當(dāng)使用用戶(hù)名稱(chēng)空間時(shí)，容器內(nèi)的根用戶(hù)不會(huì)被視為容器外的根用戶(hù)，這增加了額外的安全性。容器中的主要安全漏洞類(lèi)型是不感知名稱(chēng)空間的系統(tǒng)調(diào)用，因此可能會(huì)在容器之間引入意外泄漏。因?yàn)長(zhǎng)inux系統(tǒng)調(diào)用API集是巨大的，審計(jì)與名稱(chēng)空間相關(guān)BUG的每個(gè)系統(tǒng)調(diào)用的工作仍在進(jìn)行中。這樣的錯(cuò)誤可以通過(guò)使用seccomp]將系統(tǒng)調(diào)用列入白名單來(lái)減輕(以潛在的應(yīng)用程序不兼容性為代價(jià))。

有幾個(gè)管理工具可用于Linux容器，包括LXC、systemd-nspawn、lmctfy、Warden和Docker。(有些人將Linux容器稱(chēng)為“LXC”，但這會(huì)引起混淆，因?yàn)長(zhǎng)XC只是管理容器的眾多工具之一)。

由于其特性集和易用性，Docker迅速成為容器的標(biāo)準(zhǔn)管理工具和鏡像格式。Docker的一個(gè)關(guān)鍵特性在大多數(shù)其他容器工具中都不存在，那就是分層文件系統(tǒng)映像，通常由AUFS (Another UnionFS)提供支持。

AUFS提供了一個(gè)分層的文件系統(tǒng)堆棧，并允許在容器之間重用這些層，減少了空間使用，簡(jiǎn)化了文件系統(tǒng)管理。一個(gè)操作系統(tǒng)映像可以作為許多容器的基礎(chǔ)，同時(shí)允許每個(gè)容器有自己的修改文件覆蓋(例如，應(yīng)用程序二進(jìn)制文件和配置文件)。

在許多情況下，Docker容器鏡像比同等的VM磁盤(pán)鏡像需要更少的磁盤(pán)空間和I/O。這使得在云中部署的速度更快，因?yàn)樵谔摂M機(jī)或容器啟動(dòng)之前，映像通常必須通過(guò)網(wǎng)絡(luò)復(fù)制到本地磁盤(pán)。

盡管本文主要關(guān)注穩(wěn)定狀態(tài)的性能，但是其他的測(cè)試顯示，容器的啟動(dòng)速度比VM快得多(在我們的硬件上容器啟動(dòng)速度小于1秒，而VM啟動(dòng)速度為11秒)，因?yàn)榕cVM不同，容器不需要啟動(dòng)操作系統(tǒng)的另一個(gè)副本。理論上CRIU可以執(zhí)行容器的動(dòng)態(tài)遷移，但殺死一個(gè)容器并啟動(dòng)一個(gè)新的可能更快。

三、評(píng)價(jià)

性能有許多方面。我們關(guān)注的是與非虛擬化環(huán)境下執(zhí)行相比的開(kāi)銷(xiāo)問(wèn)題，因?yàn)樗鼫p少了用于生產(chǎn)工作的可用資源。因此，我們研究了一個(gè)或多個(gè)硬件資源被充分利用的場(chǎng)景，并測(cè)量了吞吐量和延遲等工作負(fù)載指標(biāo)，以確定虛擬化的開(kāi)銷(xiāo)。

我們的所有測(cè)試都是在一臺(tái)IBM System x3650 M4服務(wù)器上執(zhí)行的，該服務(wù)器擁有兩個(gè)2.4-3.0 GHz Intel Sandy Bridge-EP Xeon E5-2665處理器，共16核(加上超線程)和256 GB RAM。兩個(gè)處理器/插槽通過(guò)QPI鏈路連接，使其成為一個(gè)NUMA系統(tǒng)。這是一個(gè)主流服務(wù)器配置，與流行的云提供商使用的配置非常相似。我們使用Ubuntu 13.10 (Saucy) 64位，Linux內(nèi)核為3.11.0，Docker 1.0, QEMU 1.5.0和libvirt 1.1.1。為了一致性，所有的Docker容器使用Ubuntu 13.10的基礎(chǔ)鏡像，所有的虛擬機(jī)使用Ubuntu 13.10的云鏡像。

通過(guò)使用性能cpufreq調(diào)控器為測(cè)試禁用電源管理。Docker容器不受cgroups的限制，所以它們可以消耗被測(cè)試系統(tǒng)的全部資源。同樣，VM配置了32個(gè)vCPU和足夠的RAM來(lái)容納基準(zhǔn)測(cè)試的工作集。在一些測(cè)試中，我們研究了普通KVM(類(lèi)似于默認(rèn)OpenStack配置)和高度調(diào)優(yōu)的KVM配置(類(lèi)似于EC2等公共云)之間的差異。我們使用微基準(zhǔn)測(cè)試來(lái)分別測(cè)量CPU、內(nèi)存、網(wǎng)絡(luò)和存儲(chǔ)開(kāi)銷(xiāo)。我們還測(cè)量了兩個(gè)實(shí)際的服務(wù)器應(yīng)用程序：Redis和MySQL。

3.1 CPU—PXZ?

壓縮是云工作負(fù)載中經(jīng)常使用的組件。PXZ是一個(gè)使用LZMA算法的并行無(wú)損數(shù)據(jù)壓縮實(shí)用程序。我們使用PXZ 4.999.9beta (build 20130528)來(lái)壓縮enwik9，這是一個(gè)1GB的Wikipedia轉(zhuǎn)儲(chǔ)文件，經(jīng)常用于壓縮基準(zhǔn)測(cè)試。為了專(zhuān)注于壓縮而不是I/O，我們使用了32個(gè)線程，輸入文件緩存在RAM中，輸出通過(guò)管道傳輸?shù)?dev/null。我們使用壓縮級(jí)別2。

表1 PXZ、Linkpack、Stream流和隨機(jī)訪問(wèn)的結(jié)果。每個(gè)數(shù)據(jù)點(diǎn)是十次運(yùn)行的算術(shù)平均值。在圓括號(hào)"()"中顯示與裸機(jī)執(zhí)行的偏差。標(biāo)準(zhǔn)偏差在方括號(hào)“[]”中標(biāo)識(shí)。

表1顯示了PXZ在不同配置下的吞吐量。正如預(yù)期的那樣，裸機(jī)和Docker的性能非常相似，而KVM的速度要慢22%。我們注意到，通過(guò)vCPU固定和暴露緩存拓?fù)鋪?lái)優(yōu)化KVM對(duì)性能的影響很小。雖然需要進(jìn)一步實(shí)驗(yàn)來(lái)確定KVM開(kāi)銷(xiāo)的來(lái)源，但我們懷疑這是由于嵌套分頁(yè)的額外TLB壓力造成的。PXZ可能受益于使用大頁(yè)。

3.2 HPC—Linpack?

Linpack解決了一個(gè)稠密的線性方程組，使用一種算法，執(zhí)行LU因子分解與部分樞軸。絕大多數(shù)計(jì)算操作都是在一個(gè)標(biāo)量與一個(gè)向量的雙精度浮點(diǎn)乘法中進(jìn)行的，然后將結(jié)果加到另一個(gè)向量上?；鶞?zhǔn)測(cè)試通?；诰€性代數(shù)庫(kù)，該庫(kù)針對(duì)現(xiàn)有的特定機(jī)器架構(gòu)進(jìn)行了大量?jī)?yōu)化。

我們使用了一個(gè)優(yōu)化的Linpack二進(jìn)制(版本11.1.2.005)，基于Intel Math Kernel Library (MKL)。英特爾MKL具有高度的自適應(yīng)性，并基于可用的浮點(diǎn)資源(例如，可用的多媒體操作)和系統(tǒng)的緩存拓?fù)鋬?yōu)化自身。默認(rèn)情況下，KVM不會(huì)向VM公開(kāi)拓?fù)湫畔?，因此Guest操作系統(tǒng)認(rèn)為它運(yùn)行在統(tǒng)一的32個(gè)插槽系統(tǒng)上，每個(gè)插槽一個(gè)核心。

表1顯示了Linpack在Linux、Docker和KVM上的性能。在Linux和Docker上的性能幾乎是相同的——考慮到在執(zhí)行過(guò)程中很少涉及操作系統(tǒng)，這并不奇怪。然而，未調(diào)優(yōu)的KVM性能明顯更差，這說(shuō)明了采用KVM的工作負(fù)載抽象/隱藏硬件細(xì)節(jié)的成本。由于無(wú)法檢測(cè)系統(tǒng)的確切問(wèn)題所在，執(zhí)行采用了更通用的算法，從而導(dǎo)致性能損失。通過(guò)調(diào)優(yōu)KVM，將vCPU固定到相應(yīng)的CPU上，并暴露底層緩存拓?fù)?，可以提高性能，幾乎與裸機(jī)不相上下。

我們希望這種方法成為其他類(lèi)似調(diào)優(yōu)、自適應(yīng)執(zhí)行的規(guī)范，除非系統(tǒng)拓?fù)浔恢覍?shí)地貫徹到虛擬化環(huán)境中。

3.3 內(nèi)存帶寬—STEAM

表2 STEAM流組件

STREAM基準(zhǔn)測(cè)試是一個(gè)簡(jiǎn)單的綜合基準(zhǔn)測(cè)試程序，它在對(duì)向量執(zhí)行簡(jiǎn)單操作時(shí)測(cè)量可持續(xù)內(nèi)存帶寬。性能由系統(tǒng)的內(nèi)存帶寬決定，而工作集被設(shè)計(jì)成比緩存大得多。決定性能的主要因素是主存的帶寬，以及處理TLB遺漏的成本(我們進(jìn)一步減少了對(duì)大頁(yè)的使用)。內(nèi)存訪問(wèn)模式是規(guī)則的，硬件預(yù)取器通常會(huì)鎖住訪問(wèn)模式，并進(jìn)行數(shù)據(jù)預(yù)取。因此，性能取決于內(nèi)存帶寬而不是延遲?；鶞?zhǔn)測(cè)試有四個(gè)組成部分：COPY、SCALE、ADD和TRIAD，這些在表2中描述。

表1顯示了在三個(gè)執(zhí)行環(huán)境中STREAM的性能。STREAM的所有四個(gè)組件都執(zhí)行常規(guī)內(nèi)存訪問(wèn)，一旦在TLB中保存了一個(gè)頁(yè)表項(xiàng)，就會(huì)訪問(wèn)該頁(yè)中的所有數(shù)據(jù)，然后再轉(zhuǎn)到下一頁(yè)。硬件TLB預(yù)取對(duì)于這種工作負(fù)載也非常有效。因此，在Linux、Docker和KVM上的性能幾乎是相同的，中間數(shù)據(jù)顯示在三個(gè)執(zhí)行環(huán)境中只有1.4%的差異。

3.4 隨機(jī)內(nèi)存訪問(wèn)—隨機(jī)訪問(wèn)

STREAM基準(zhǔn)測(cè)試以常規(guī)的方式壓測(cè)內(nèi)存子系統(tǒng)，允許硬件預(yù)取器在將數(shù)據(jù)用于計(jì)算之前從內(nèi)存中讀取數(shù)據(jù)到緩存。相反，隨機(jī)訪問(wèn)基準(zhǔn)測(cè)試是專(zhuān)門(mén)為強(qiáng)調(diào)隨機(jī)內(nèi)存性能而設(shè)計(jì)的。基準(zhǔn)測(cè)試將一大塊內(nèi)存初始化為它的工作集，這比緩存或TLB所能達(dá)到的范圍大很多個(gè)數(shù)量級(jí)。讀取、修改(通過(guò)一個(gè)簡(jiǎn)單的異或操作)并寫(xiě)回內(nèi)存中的隨機(jī)8字節(jié)單詞。隨機(jī)位置是通過(guò)使用不需要存儲(chǔ)器操作的線性反饋移位寄存器產(chǎn)生的。因此，連續(xù)操作之間不存在依賴(lài)關(guān)系，允許多個(gè)獨(dú)立操作在系統(tǒng)中流動(dòng)。隨機(jī)訪問(wèn)代表了具有大工作集和最小計(jì)算量的工作負(fù)載的行為，比如那些具有內(nèi)存哈希表和內(nèi)存數(shù)據(jù)庫(kù)的工作負(fù)載。

和STREAM一樣，隨機(jī)訪問(wèn)使用大頁(yè)面來(lái)減少TLB未命中的開(kāi)銷(xiāo)。因?yàn)樗碾S機(jī)內(nèi)存訪問(wèn)模式和一個(gè)大于TLB范圍的工作集，隨機(jī)訪問(wèn)顯著地使用硬件頁(yè)表遍歷器來(lái)處理TLB失敗。如表1所示，在我們的雙路服務(wù)器系統(tǒng)上，這對(duì)于虛擬化和非虛擬化環(huán)境都有相同的開(kāi)銷(xiāo)。

3.5 網(wǎng)絡(luò)帶寬—nuttcp?

我們使用nuttcp工具來(lái)測(cè)量系統(tǒng)的網(wǎng)絡(luò)性能，待測(cè)系統(tǒng)與另一臺(tái)機(jī)器之間通過(guò)兩張Mellanox ConnectX-2 EN網(wǎng)卡直連，CX2網(wǎng)卡提供10Gbps以太網(wǎng)鏈路連接的網(wǎng)絡(luò)帶寬。我們對(duì)10Gbps網(wǎng)絡(luò)應(yīng)用了標(biāo)準(zhǔn)的網(wǎng)絡(luò)調(diào)優(yōu)，比如啟用TCP窗口擴(kuò)展和增加Socket緩沖區(qū)大小。

如圖1所示，Docker將主機(jī)上的所有容器連接到網(wǎng)橋上，并通過(guò)NAT將網(wǎng)橋連接到網(wǎng)絡(luò)上。在我們的KVM配置中，我們使用Virtio和vHost來(lái)最小化虛擬化開(kāi)銷(xiāo)。

圖1 網(wǎng)絡(luò)配置

我們使用nuttcp來(lái)測(cè)量單個(gè)TCP連接上標(biāo)準(zhǔn)1500字節(jié)MTU的單向批量數(shù)據(jù)傳輸?shù)膶?shí)際吞吐量。在客戶(hù)機(jī)到服務(wù)器的情況下，被測(cè)系統(tǒng)(SUT)充當(dāng)發(fā)送器，在服務(wù)器到客戶(hù)機(jī)的情況下，SUT充當(dāng)接收器；有必要測(cè)量?jī)蓚€(gè)方向，因?yàn)門(mén)CP有不同的發(fā)送和接收代碼路徑。這三種配置在發(fā)送和接收方向上都達(dá)到9.3 Gbps，非常接近因?yàn)榘^而產(chǎn)生的9.41 Gbps的理論極限。

由于分片卸載，即使使用不同形式的虛擬化創(chuàng)建的額外層，批量數(shù)據(jù)傳輸也非常高效。這個(gè)測(cè)試中的瓶頸是NIC，使得其他資源大部分空閑。在這樣一個(gè)I/O受限的場(chǎng)景中，我們通過(guò)測(cè)量發(fā)送和接收數(shù)據(jù)所需的CPU周期量來(lái)確定開(kāi)銷(xiāo)。

圖2顯示了此測(cè)試的系統(tǒng)范圍CPU利用率，使用perf stat -a進(jìn)行測(cè)量。Docker使用橋接和NAT顯著地增加了傳輸路徑長(zhǎng)度;Vhost-net在傳輸方面是相當(dāng)有效的，但在接收端有很高的開(kāi)銷(xiāo)。不使用NAT的容器具有與本地Linux相同的性能。在實(shí)際的網(wǎng)絡(luò)密集型工作負(fù)載中，我們預(yù)計(jì)這種CPU開(kāi)銷(xiāo)會(huì)降低整體的性能。

圖2 TCP批量傳輸效率

過(guò)去，Xen和KVM一直難以提供線速率的網(wǎng)絡(luò)，因?yàn)橛鼗氐腎/O路徑將每個(gè)數(shù)據(jù)包發(fā)送到用戶(hù)空間。這導(dǎo)致了對(duì)諸如輪詢(xún)驅(qū)動(dòng)程序或管理程序旁路等復(fù)雜網(wǎng)絡(luò)加速技術(shù)的大量研究。

我們的結(jié)果表明，vHost允許虛擬機(jī)直接與主機(jī)內(nèi)核通信，直接解決了網(wǎng)絡(luò)吞吐量問(wèn)題。如果有更多的網(wǎng)卡，我們預(yù)計(jì)該服務(wù)器可以在不使用任何外來(lái)技術(shù)的情況下驅(qū)動(dòng)超過(guò)40Gbps的網(wǎng)絡(luò)流量。

3.6 網(wǎng)絡(luò)延遲—netperf?

我們使用netperf請(qǐng)求-響應(yīng)基準(zhǔn)測(cè)試來(lái)測(cè)量往返網(wǎng)絡(luò)延遲，使用與前一節(jié)中的nuttcp測(cè)試類(lèi)似的配置。在這種情況下，被測(cè)試的系統(tǒng)運(yùn)行netperf服務(wù)器(netserver)，而另一臺(tái)機(jī)器運(yùn)行netperf客戶(hù)機(jī)?？蛻?hù)端發(fā)送一個(gè)100字節(jié)的請(qǐng)求，服務(wù)器發(fā)送一個(gè)200字節(jié)的響應(yīng)，客戶(hù)端在發(fā)送另一個(gè)請(qǐng)求之前等待響應(yīng)。因此，一次只有一個(gè)事務(wù)在運(yùn)行中。

圖3：網(wǎng)絡(luò)往返延時(shí)(μs)

圖3顯示了基準(zhǔn)測(cè)試的TCP和UDP變體的事務(wù)延遲。在這個(gè)測(cè)試中，與Docker中使用的NAT一樣，將延遲增加了一倍。KVM為每個(gè)事務(wù)增加30μs的開(kāi)銷(xiāo)，比非虛擬化的網(wǎng)絡(luò)堆棧增加80%。TCP和UDP具有非常相似的延遲，因?yàn)樵谶@兩種情況下，一個(gè)事務(wù)都由每個(gè)方向上的單個(gè)包組成。與吞吐量測(cè)試不同，在這種情況下虛擬化開(kāi)銷(xiāo)不能被攤銷(xiāo)。

3.7 塊I/O—fio?

類(lèi)似于SAN的塊存儲(chǔ)通常用于云中，以提供高性能和強(qiáng)一致性。為了測(cè)試虛擬化塊存儲(chǔ)的開(kāi)銷(xiāo)，我們使用兩個(gè)8Gbps光纖通道連接到基于QLogic ISP2532的雙端口HBA卡，并使用dm\_multipath來(lái)合并這兩個(gè)連接，將一個(gè)20TB的IBM FlashSystem 840閃存SSD連接到我們的測(cè)試服務(wù)器。

我們使用默認(rèn)設(shè)置在它上面創(chuàng)建了一個(gè)ext4文件系統(tǒng)。在裸機(jī)情況下，文件系統(tǒng)是正常安裝的，而在Docker測(cè)試中，使用-v選項(xiàng)將它映射到容器中(避免AUFS開(kāi)銷(xiāo))。在VM的情況下，塊設(shè)備使用Virtio映射到VM，并掛載到VM中。

這些配置如圖4所示。我們使用fio 2.0.8和libaio后端在O\_DIRECT模式下對(duì)存儲(chǔ)在SSD上的16GB文件運(yùn)行幾個(gè)測(cè)試。使用O\_DIRECT允許訪問(wèn)繞過(guò)操作系統(tǒng)緩存。

圖4 采用fio的存儲(chǔ)配置

圖5 順序I/O吞吐量(MB/s)

圖5顯示了使用典型的1 MB I/O大小的連續(xù)讀寫(xiě)性能，平均時(shí)間超過(guò)60秒。在這種情況下，Docker和KVM引入的開(kāi)銷(xiāo)可以忽略不計(jì)，盡管KVM的性能差異大約是其他情況的四倍。與網(wǎng)絡(luò)類(lèi)似，光纖通道HBA卡似乎是測(cè)試的瓶頸。

圖6顯示了使用4KB塊大小和128并發(fā)隨機(jī)讀、寫(xiě)和混合(70%讀、30%寫(xiě))工作負(fù)載的性能，我們通過(guò)實(shí)驗(yàn)確定，這為特定的SSD提供了最大的性能。正如我們所料，與Linux相比，Docker沒(méi)有帶來(lái)任何開(kāi)銷(xiāo)，但是KVM只提供了一半的IOPS，因?yàn)槊總€(gè)I/O操作都必須經(jīng)過(guò)QEMU。雖然VM的絕對(duì)性能仍然相當(dāng)高，但它在每個(gè)I/O操作中使用了更多的CPU周期，而應(yīng)用程序則只有相對(duì)更少的CPU周期。

圖7顯示了KVM將讀取延遲增加2-3倍，這是一些實(shí)際工作負(fù)載的關(guān)鍵指標(biāo)。

圖6 隨機(jī)I/O吞吐量(IOPS)

圖7 隨機(jī)讀延遲CDF（累計(jì)分布曲線），并發(fā)16(μs)，裸機(jī)和容器線幾乎是重疊的

我們還注意到，這種硬件配置在順序I/O中應(yīng)該能夠超過(guò)1.5 GB/s，在隨機(jī)I/O中應(yīng)該能夠超過(guò)35萬(wàn)IOPS，因此即使是裸機(jī)情況下也有很大的未發(fā)掘的潛力，而我們?cè)诮栌糜布r(shí)沒(méi)有設(shè)法利用這些潛力。

3.8 Redis?

在云中，基于內(nèi)存的鍵值存儲(chǔ)通常用于緩存、存儲(chǔ)會(huì)話信息，并作為維護(hù)熱門(mén)非結(jié)構(gòu)化數(shù)據(jù)集的便捷方式。操作在本質(zhì)上趨向于簡(jiǎn)單，并且需要客戶(hù)機(jī)和服務(wù)器之間的網(wǎng)絡(luò)往返。這種業(yè)務(wù)模型使得應(yīng)用程序?qū)W(wǎng)絡(luò)延遲非常敏感?？紤]到并發(fā)客戶(hù)機(jī)的數(shù)量很大，每個(gè)客戶(hù)機(jī)都向許多服務(wù)器發(fā)送非常小的網(wǎng)絡(luò)數(shù)據(jù)包，挑戰(zhàn)就更復(fù)雜了。因此，服務(wù)器在網(wǎng)絡(luò)堆棧中花費(fèi)了相當(dāng)多的時(shí)間。

在我們的評(píng)估中，我們選擇了Redis，因?yàn)樗母咝阅?，豐富的API和廣泛使用的PaaS提供商(例如Amazon Elasticache，谷歌計(jì)算引擎)。我們從主要的GitHub倉(cāng)庫(kù)中獲得了Redis 2.8.13，并在我們的Ubuntu 13.10平臺(tái)上構(gòu)建了它。

然后，生成的二進(jìn)制文件將用于每種部署模式：裸機(jī)、Docker和KVM。為了提高性能，考慮到Redis是一個(gè)單線程應(yīng)用程序，我們將容器或VM綁定到靠近網(wǎng)絡(luò)接口的核心上。測(cè)試由許多向服務(wù)器發(fā)出請(qǐng)求的客戶(hù)端組成。使用了50%讀和50%寫(xiě)的混合。每個(gè)客戶(hù)機(jī)都維護(hù)到服務(wù)器的持久TCP連接，并可以通過(guò)該連接傳輸多達(dá)10個(gè)并發(fā)請(qǐng)求。

因此，運(yùn)行中的請(qǐng)求總數(shù)是客戶(hù)端數(shù)量的10倍。鍵的長(zhǎng)度為10個(gè)字符，生成的值平均為50個(gè)字節(jié)。這個(gè)數(shù)據(jù)集代表了Steinberg等人描述的生產(chǎn)環(huán)境Redis用戶(hù)數(shù)據(jù)的典型特征。對(duì)于每次運(yùn)行，都將清除數(shù)據(jù)集，然后發(fā)出確定的操作序列，之后逐步創(chuàng)建1.5億個(gè)鍵。Redis服務(wù)器在執(zhí)行過(guò)程中的內(nèi)存消耗峰值為11GB。

圖8 在多個(gè)部署場(chǎng)景的NoSQL Redis性能評(píng)估(請(qǐng)求/秒)，每個(gè)數(shù)據(jù)點(diǎn)是10次運(yùn)行的算術(shù)平均值。

圖9 不同Redis部署上的平均操作延遲(毫秒)，每個(gè)數(shù)據(jù)點(diǎn)是10次運(yùn)行的算術(shù)平均值

圖8顯示了與不同部署模型的客戶(hù)機(jī)連接數(shù)相關(guān)的吞吐量(以每秒請(qǐng)求數(shù)為單位)。

圖9顯示了每個(gè)實(shí)驗(yàn)對(duì)應(yīng)的平均時(shí)延(用μs表示)。在裸機(jī)部署中，網(wǎng)絡(luò)子系統(tǒng)足以處理負(fù)載。所以，當(dāng)我們擴(kuò)展客戶(hù)端連接的數(shù)量時(shí)，限制Redis服務(wù)器吞吐量的主要因素是CPU的飽和——注意Redis是一個(gè)單線程的，基于事件的應(yīng)用程序。在我們的平臺(tái)中，這很快就會(huì)以每秒110k的請(qǐng)求速度到達(dá)CPU飽和。添加更多的客戶(hù)端會(huì)導(dǎo)致請(qǐng)求排隊(duì)，并增加平均延遲。

Redis服務(wù)器給網(wǎng)絡(luò)和內(nèi)存子系統(tǒng)帶來(lái)了很大的壓力。當(dāng)將Docker與主機(jī)網(wǎng)絡(luò)堆棧一起使用時(shí)，我們可以看到吞吐量和延遲實(shí)際上與裸機(jī)情況相同。

當(dāng)使用啟用了NAT的Docker時(shí)，情況就大不相同了，如圖1所示。在這種情況下，引入的延遲隨著通過(guò)網(wǎng)絡(luò)接收的數(shù)據(jù)包數(shù)量的增加而增加。雖然它可以與4個(gè)并發(fā)連接的裸機(jī)相提并論(51個(gè)μs或裸機(jī)的1.05倍)，但一旦連接數(shù)量增加，它就會(huì)迅速增長(zhǎng)(100個(gè)連接時(shí)超過(guò)1.11倍)。此外，NAT會(huì)消耗CPU周期，從而阻止Redis的部署達(dá)到使用裸機(jī)網(wǎng)絡(luò)堆棧時(shí)的最高性能。

類(lèi)似地，在KVM中運(yùn)行時(shí)，Redis看起來(lái)是網(wǎng)絡(luò)綁定的。KVM為每個(gè)事務(wù)增加大約83μs的延遲。我們看到VM在低并發(fā)時(shí)具有較低的吞吐量，但隨著并發(fā)性的增加，其性能漸近接近裸機(jī)性能。超過(guò)100個(gè)連接后，兩個(gè)部署的吞吐量實(shí)際上是相同的。這可以用利特爾定律來(lái)解釋?zhuān)挥捎贙VM下的網(wǎng)絡(luò)延遲更高，Redis需要更多的并發(fā)來(lái)充分利用系統(tǒng)性能。這可能是一個(gè)問(wèn)題，具體取決于云場(chǎng)景中最終用戶(hù)期望的并發(fā)級(jí)別。

3.9 MySQL

MySQL是一種流行的關(guān)系數(shù)據(jù)庫(kù)，在云中廣泛使用，通常強(qiáng)調(diào)內(nèi)存、IPC、文件系統(tǒng)和網(wǎng)絡(luò)子系統(tǒng)。我們針對(duì)MySQL 5.5.37的一個(gè)實(shí)例運(yùn)行了SysBench oltp基準(zhǔn)測(cè)試。MySQL被配置為使用InnoDB作為后端存儲(chǔ)，并且啟用了3GB的緩存；這個(gè)緩存足以緩存基準(zhǔn)測(cè)試運(yùn)行期間的所有讀取。

oltp基準(zhǔn)測(cè)試使用一個(gè)預(yù)加載了200萬(wàn)條記錄的數(shù)據(jù)庫(kù)，并執(zhí)行一組固定的讀/寫(xiě)事務(wù)，在5個(gè)SELECT查詢(xún)、2個(gè)UPDATE查詢(xún)、1個(gè)DELETE查詢(xún)和1個(gè)INSERT查詢(xún)之間進(jìn)行選擇。

SysBench提供的度量值是事務(wù)延遲和每秒事務(wù)吞吐量的統(tǒng)計(jì)數(shù)據(jù)?？蛻?hù)端數(shù)量不斷變化，直到達(dá)到飽和，每個(gè)數(shù)據(jù)點(diǎn)使用10次運(yùn)行。測(cè)量了五種不同的配置：MySQL在Linux上正常運(yùn)行(本機(jī))，MySQL在Docker下使用主機(jī)組網(wǎng)和卷(Docker net=主機(jī)卷)，使用卷但正常Docker組網(wǎng)(Docker NAT卷)，將數(shù)據(jù)庫(kù)存儲(chǔ)在容器文件系統(tǒng)(Docker NAT AUFS)和MySQL在KVM下運(yùn)行；表3總結(jié)了這些不同的配置。

雖然MySQL訪問(wèn)文件系統(tǒng)，我們的配置有足夠的緩存，它幾乎沒(méi)有執(zhí)行實(shí)際的磁盤(pán)I/O，使得不同的KVM存儲(chǔ)選項(xiàng)沒(méi)有意義。

表3 MySQL配置

圖10 MySQL吞吐量(事務(wù)/秒) vs并發(fā)

圖10顯示了事務(wù)吞吐量作為SysBench模擬的用戶(hù)數(shù)量的函數(shù)。右邊的Y軸顯示了與裸機(jī)相比的吞吐量損失。這條曲線的大致形狀與我們的預(yù)期一致:吞吐量隨著負(fù)載的增加而增加，直到機(jī)器飽和，然后在超載時(shí)由于爭(zhēng)搶沖突而略有損失而趨于平穩(wěn)。

Docker具有與裸機(jī)相似的性能，在更高的并發(fā)性下差異漸近接近2%。KVM的開(kāi)銷(xiāo)要高得多，在所有測(cè)量的情況下都高于40%。AUFS引入了顯著的開(kāi)銷(xiāo)，這并不奇怪，因?yàn)镮/O要經(jīng)過(guò)好幾層，通過(guò)比較Docker NAT卷和Docker NAT AUFS結(jié)果可以看出。AUFS開(kāi)銷(xiāo)演示了在文件系統(tǒng)上面進(jìn)行虛擬化(如Docker所做的)和在文件系統(tǒng)下面進(jìn)行虛擬化(如KVM所做的)之間的區(qū)別。

我們測(cè)試了不同的KVM存儲(chǔ)協(xié)議，發(fā)現(xiàn)對(duì)于類(lèi)似于此測(cè)試的緩存內(nèi)工作負(fù)載，它們對(duì)性能沒(méi)有影響。NAT也會(huì)帶來(lái)一些開(kāi)銷(xiāo)，但這種工作負(fù)載不是網(wǎng)絡(luò)密集型的。KVM顯示了一個(gè)有趣的結(jié)果，在網(wǎng)絡(luò)中達(dá)到了飽和，但在CPU中沒(méi)有達(dá)到(圖11)。基準(zhǔn)測(cè)試生成大量的小數(shù)據(jù)包，因此即使網(wǎng)絡(luò)帶寬很小，網(wǎng)絡(luò)堆棧也無(wú)法維持每秒所需的數(shù)據(jù)包數(shù)量。由于基準(zhǔn)測(cè)試使用同步請(qǐng)求，在給定并發(fā)級(jí)別下，延遲的增加也會(huì)降低吞吐量。

圖11 MySQL吞吐量(事務(wù)/秒) vs. CPU利用率

圖12 MySQL延遲(以毫秒為單位) vs. 并發(fā)

圖12顯示了SysBench模擬的用戶(hù)數(shù)量與延遲的關(guān)系。正如預(yù)期的那樣，延遲隨著負(fù)載的增加而增加，但有趣的是，Docker在中等負(fù)載水平下增加延遲的速度更快，這解釋了低并發(fā)水平下的低吞吐量。圖中擴(kuò)展的部分顯示，本機(jī)Linux能夠?qū)崿F(xiàn)更高的CPU峰值利用率，而Docker無(wú)法達(dá)到同樣的水平，差異約為1.5%。這一結(jié)果表明，Docker有一個(gè)較小但可測(cè)量的影響。

圖11描繪了吞吐量與CPU利用率之間的關(guān)系。

比較圖10到圖12，我們注意到在相同并發(fā)情況下，Docker和使用NAT的Docker的低吞吐量并沒(méi)有產(chǎn)生同等的CPU消耗增加。當(dāng)使用相同數(shù)量的CPU時(shí)，吞吐量的差異很小。在其他方面，由于Docker的并發(fā)性值較低，因此其延遲就大大增加了，我們把這種行為歸因于互斥鎖爭(zhēng)用?；コ庖沧柚筂ySQL在所有情況下充分利用CPU，但這在Docker情況下更明顯，因?yàn)槭聞?wù)需要更長(zhǎng)的時(shí)間。

圖11清楚地顯示，在VM的情況下，限制不是CPU，而是網(wǎng)絡(luò)，但即使在較低的客戶(hù)機(jī)數(shù)量下，KVM的開(kāi)銷(xiāo)也很明顯。

圖13 MySQL吞吐量(事務(wù)/秒) vs. 延遲

圖13中的吞吐量-延遲曲線便于比較給定目標(biāo)延遲或吞吐量的備選方案。這條曲線的一個(gè)有趣方面是，當(dāng)飽和后引入更多客戶(hù)機(jī)時(shí)，在幾種情況下，更高的上下文切換導(dǎo)致吞吐量降低。由于在Docker中有更多的空閑時(shí)間，因此更高的開(kāi)銷(xiāo)不會(huì)影響基準(zhǔn)測(cè)試中使用的客戶(hù)機(jī)數(shù)量的吞吐量。

3.10 討論

我們從這些結(jié)果中看到了幾個(gè)普遍的趨勢(shì)。正如我們所期望的那樣，容器和虛擬機(jī)對(duì)CPU和內(nèi)存的使用幾乎沒(méi)有任何開(kāi)銷(xiāo)；它們只影響I/O和OS交互。這種開(kāi)銷(xiāo)是以每個(gè)I/O操作的額外周期的形式出現(xiàn)的，所以小I/O比大I/O遭受的損失要大得多。這種開(kāi)銷(xiāo)增加了I/O延遲，減少了用于有用工作的CPU周期，從而限制了吞吐量。不幸的是，真正的應(yīng)用程序通常不能批量處理大型I/O。

Docker添加了一些特性，如分層鏡像和NAT，這使得它比LXC風(fēng)格的原始容器更容易使用，但這些特性是以性能為代價(jià)的。因此，使用默認(rèn)設(shè)置的Docker可能不會(huì)比KVM快。文件系統(tǒng)或磁盤(pán)密集型的應(yīng)用程序應(yīng)該通過(guò)使用卷繞過(guò)AUFS。使用-net =host可以很容易地消除NAT開(kāi)銷(xiāo)，但這放棄了網(wǎng)絡(luò)名稱(chēng)空間的好處。最終，我們相信Kubernetes項(xiàng)目提出的每個(gè)容器一個(gè)IP地址的模型可以提供靈活性和性能。

雖然KVM可以提供非常好的性能，但它的可配置性是一個(gè)弱點(diǎn)。良好的CPU性能需要仔細(xì)配置大頁(yè)面、CPU模型、vCPU固定和緩存拓?fù)?這些特性的文檔說(shuō)明很差，需要反復(fù)調(diào)優(yōu)才能配置妥當(dāng)。我們建議讀者避免直接使用Qemu-KVM，而是使用libvirt，因?yàn)樗?jiǎn)化了KVM配置。即使在最新版本的Ubuntu上，我們也無(wú)法讓vHost-scsi工作，所以仍然有改進(jìn)的空間。這種復(fù)雜性對(duì)任何有抱負(fù)的云運(yùn)營(yíng)商來(lái)說(shuō)都是一個(gè)進(jìn)入的障礙，無(wú)論是公共的還是私有的。

四、相關(guān)工作

Multics項(xiàng)目在20世紀(jì)60年代開(kāi)始建立公用事業(yè)計(jì)算基礎(chǔ)設(shè)施。盡管Multics從未得到廣泛的應(yīng)用，云計(jì)算直到互聯(lián)網(wǎng)普及后才得以起飛，但該項(xiàng)目產(chǎn)生了像端到端論證和一套安全原則這樣的想法，這些理念在今天仍然適用。

虛擬機(jī)在20世紀(jì)70年代的IBM大型機(jī)上被引入，然后在90年代后期由VMware在x86上重新發(fā)明。Xen和KVM在2000年將VM帶到了開(kāi)源世界。虛擬機(jī)的開(kāi)銷(xiāo)最初很高，但由于硬件和軟件的優(yōu)化，這些年來(lái)穩(wěn)步減少了。

操作系統(tǒng)級(jí)虛擬化也有很長(zhǎng)的歷史。在某種意義上，操作系統(tǒng)的目的是虛擬化硬件資源，以便共享它們，但是由于文件系統(tǒng)、進(jìn)程和網(wǎng)絡(luò)的全局名稱(chēng)空間，Unix傳統(tǒng)上提供了較差的隔離?；谌萘康牟僮飨到y(tǒng)由于沒(méi)有任何全局名稱(chēng)空間而提供了類(lèi)似容器的隔離，但它們?cè)?0世紀(jì)80年代從商業(yè)上消失了。Plan 9引入了每個(gè)進(jìn)程的文件系統(tǒng)名稱(chēng)空間和bind掛載，啟發(fā)了支持Linux容器的名稱(chēng)空間機(jī)制。

Unix chroot()特性長(zhǎng)期以來(lái)一直用于實(shí)現(xiàn)基本的“監(jiān)獄”，而B(niǎo)SD監(jiān)獄特性擴(kuò)展了這個(gè)概念。Solaris 10在2004年引入并大力推廣了Zones，這是一種現(xiàn)代的容器實(shí)現(xiàn)。云提供商Joyent從2008年開(kāi)始提供基于zone的IaaS，盡管對(duì)整個(gè)云市場(chǎng)沒(méi)有影響。

Linux容器有著漫長(zhǎng)而曲折的歷史。Linux-VServer項(xiàng)目是“虛擬私有服務(wù)器”在2001年的最初實(shí)施，它從未合并到主流Linux中，但在PlanetLab中被成功使用。商業(yè)產(chǎn)品Virtuozzo及其開(kāi)源版本OpenVZ已經(jīng)廣泛用于Web托管，但也沒(méi)有合并到Linux中。Linux最終在2007年以?xún)?nèi)核名稱(chēng)空間和LXC用戶(hù)空間工具的形式添加了本地容器化來(lái)管理它們。

像Heroku這樣的平臺(tái)即服務(wù)提供商引入了使用容器高效且可重復(fù)部署應(yīng)用程序的思想。Heroku不是將容器視為虛擬服務(wù)器，而是將其視為具有額外隔離的進(jìn)程。由此產(chǎn)生的應(yīng)用程序容器的開(kāi)銷(xiāo)非常小，提供與VM類(lèi)似的隔離，但具有與普通進(jìn)程一樣的資源共享。谷歌在其內(nèi)部基礎(chǔ)結(jié)構(gòu)中也廣泛采用了應(yīng)用程序容器。Heroku的競(jìng)爭(zhēng)對(duì)手DotCloud(現(xiàn)在稱(chēng)為Docker Inc.)引入了Docker作為這些應(yīng)用程序容器的標(biāo)準(zhǔn)鏡像格式和管理系統(tǒng)。

對(duì)Hypervisor進(jìn)行了廣泛的性能評(píng)估，但大多是與其他虛擬管理程序或非虛擬化執(zhí)行進(jìn)行比較。

過(guò)去VM與容器的比較大多使用舊軟件，如Xen和樹(shù)外容器補(bǔ)丁。

五、總結(jié)和未來(lái)的工作?

VM和容器都是成熟的技術(shù)，它們受益于硬件性能提升和軟件優(yōu)化。通常，在我們測(cè)試的每一種情況下，Docker的性能都等于或超過(guò)KVM。我們的結(jié)果表明，KVM和Docker都為CPU和內(nèi)存性能帶來(lái)了微不足道的開(kāi)銷(xiāo)(除非在極端情況下)。對(duì)于I/O密集型工作負(fù)載，應(yīng)該謹(jǐn)慎使用這兩種形式的虛擬化。

我們發(fā)現(xiàn)，自創(chuàng)建以來(lái)，KVM的性能有了相當(dāng)大的改善。曾經(jīng)被認(rèn)為是非常具有挑戰(zhàn)性的工作負(fù)載，比如線速率10Gbps的網(wǎng)絡(luò)，現(xiàn)在使用2013年的硬件和軟件，只用一個(gè)核心就可以實(shí)現(xiàn)。即使使用可用的最快的半虛擬化形式，KVM仍然給每個(gè)I/O操作增加了一些開(kāi)銷(xiāo);當(dāng)執(zhí)行較小的I/O時(shí)，這一開(kāi)銷(xiāo)非常大，而當(dāng)它分?jǐn)偟捷^大的I/O時(shí)，則可以忽略不計(jì)。因此，KVM不太適合對(duì)延遲敏感或具有高I/O速率的工作負(fù)載。這些開(kāi)銷(xiāo)會(huì)顯著影響我們測(cè)試的服務(wù)器應(yīng)用程序。

盡管容器本身幾乎沒(méi)有開(kāi)銷(xiāo)，但Docker并非沒(méi)有性能問(wèn)題。Docker卷的性能明顯優(yōu)于存儲(chǔ)在AUFS中的文件。Docker的NAT還會(huì)帶來(lái)高包速率工作負(fù)載的開(kāi)銷(xiāo)。這些特性代表了易于管理和性能之間的權(quán)衡，應(yīng)該根據(jù)具體情況加以考慮。

在某種意義上，容器的比較只會(huì)變得更糟，因?yàn)樗鼈円婚_(kāi)始的開(kāi)銷(xiāo)接近于零，而VM隨著時(shí)間的推移變得更快。如果容器要被廣泛采用，它們必須提供穩(wěn)態(tài)性能以外的優(yōu)點(diǎn)。我們相信，在不久的將來(lái)，便利性、更快的部署、靈活性和性能的結(jié)合可能會(huì)變得引人注目。

我們的結(jié)果可以為如何構(gòu)建云基礎(chǔ)設(shè)施提供一些指導(dǎo)。傳統(tǒng)觀點(diǎn)認(rèn)為(在最新的云生態(tài)系統(tǒng)中存在這樣的東西)IaaS是用VM實(shí)現(xiàn)的，而PaaS是用容器實(shí)現(xiàn)的。我們沒(méi)有發(fā)現(xiàn)技術(shù)上的原因，尤其是基于容器的IaaS可以提供更好的性能或更容易的部署。容器還可以消除IaaS和“裸金屬”非虛擬化服務(wù)器之間的區(qū)別，因?yàn)樗鼈兲峁┝司哂新憬饘傩阅艿奶摂M機(jī)的控制和隔離。無(wú)需為虛擬化和非虛擬化服務(wù)器維護(hù)不同的映像，相同的Docker映像可以有效地部署在從Core的一小部分到整個(gè)機(jī)器上的任何地方。

我們還質(zhì)疑在VM中部署容器的做法，因?yàn)榕c直接在非虛擬化Linux上部署容器相比，這會(huì)增加VM的性能開(kāi)銷(xiāo)，而沒(méi)有任何好處。如果必須使用VM，那么在容器中運(yùn)行VM可以創(chuàng)建額外的安全層，因?yàn)槔肣EMU的攻擊者仍然在容器中。

雖然今天的典型服務(wù)器是NUMA架構(gòu)，但我們認(rèn)為，試圖在云中利用NUMA可能會(huì)付出更多的努力但不值得。將每個(gè)工作負(fù)載限制在單個(gè)CPU內(nèi)，極大地簡(jiǎn)化了性能分析和調(diào)優(yōu)?？紤]到云應(yīng)用程序通常是為可擴(kuò)展而設(shè)計(jì)的，而且每個(gè)CPU的Core數(shù)量會(huì)隨著時(shí)間的推移而增加，因此擴(kuò)展的單位可能應(yīng)該是CPU而不是服務(wù)器。這也不利于裸金屬，因?yàn)槊總€(gè)CPU運(yùn)行一個(gè)容器的服務(wù)器實(shí)際上可能比跨CPU分散工作負(fù)載要快，因?yàn)闇p少了交叉流量。

在本文中，我們創(chuàng)建了消耗整個(gè)服務(wù)器的單個(gè)VM或容器；在云中，更常見(jiàn)的做法是將服務(wù)器劃分為更小的單元。這就引出了幾個(gè)值得研究的附加問(wèn)題：在同一臺(tái)服務(wù)器上運(yùn)行多個(gè)工作負(fù)載時(shí)的性能隔離、實(shí)時(shí)調(diào)整容器和虛擬機(jī)的大小、擴(kuò)展和向外擴(kuò)展之間的權(quán)衡以及實(shí)時(shí)遷移和重新啟動(dòng)之間的權(quán)衡。