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

編者按

大家一直對虛擬機和容器的性能損耗都有一定的認識，但具體多少應(yīng)該沒有幾個人能說清楚。這篇文章詳細的評測了相關(guān)的應(yīng)用場景在容器、虛擬機、裸機三種場景下的性能對比，相信會對大家有所幫助。

參考鏈接：

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

摘要

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

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

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

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

一、介紹

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

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

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

基于容器的虛擬化為云中的虛擬機提供了一個有趣的替代方案。虛擬專用服務(wù)器提供商，可能被視為云計算的先驅(qū)，已經(jīng)使用容器超過十年了。但他們中的許多人轉(zhuǎn)向VM以提供更一致的性能。盡管很好地理解了名稱空間等容器的基礎(chǔ)概念，但是容器技術(shù)一直處于停滯狀態(tài)，直到因為需要快速部署的需要，PaaS提供者采用并標準化了容器，使得采用容器來提供隔離和資源控制的復(fù)興。

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

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

我們的目標是隔離并理解虛擬機(特別是KVM)和容器(特別是Docker)相對于非虛擬化Linux所帶來的開銷。我們希望其他管理程序，如Xen、VMware ESX和Microsoft Hyper-V，能夠提供與KVM類似的性能，因為它們使用相同的硬件加速特性。

同樣地，當其他容器工具使用相同的機制時，它們應(yīng)該具有與Docker相同的性能。我們不評估在VM中運行容器或在容器中運行VM的情況，因為我們認為這種雙重虛擬化是冗余的(至少從性能角度來看)。Linux可以同時承載VM和容器，這一事實為這兩種技術(shù)之間的相互比較創(chuàng)造了機會——與以前的許多比較相比，混淆變量更少一些。

我們做出了如下貢獻：

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

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

我們詳細闡述了一些影響虛擬化性能的不明顯的實際問題。

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

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

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

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

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

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

二、背景

2.1 云虛擬化的動機和要求

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

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

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

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

2.2 KVM

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

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

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

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

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

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

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

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

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

雖然VM擅長隔離，但當在Guest之間或Guest和Hypervisor之間共享數(shù)據(jù)時，它們增加了開銷。通常，這種共享需要相當昂貴的編組和hypercall。在云中，虛擬機通常通過映像文件支持的模擬塊設(shè)備訪問存儲；創(chuàng)建、更新和部署這樣的磁盤映像可能非常耗時，而包含大部分重復(fù)內(nèi)容的磁盤映像集合可能會浪費存儲空間。

2.3 Linux容器

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

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

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

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

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

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

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

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

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

有幾個管理工具可用于Linux容器，包括LXC、systemd-nspawn、lmctfy、Warden和Docker。(有些人將Linux容器稱為“LXC”，但這會引起混淆，因為LXC只是管理容器的眾多工具之一)。

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

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

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

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

三、評價

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

我們的所有測試都是在一臺IBM System x3650 M4服務(wù)器上執(zhí)行的，該服務(wù)器擁有兩個2.4-3.0 GHz Intel Sandy Bridge-EP Xeon E5-2665處理器，共16核(加上超線程)和256 GB RAM。兩個處理器/插槽通過QPI鏈路連接，使其成為一個NUMA系統(tǒng)。這是一個主流服務(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ǔ)鏡像，所有的虛擬機使用Ubuntu 13.10的云鏡像。

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

3.1 CPU—PXZ?

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

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

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

3.2 HPC—Linpack?

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

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

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

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

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

表2 STEAM流組件

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

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

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

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

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

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

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

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

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

我們使用nuttcp來測量單個TCP連接上標準1500字節(jié)MTU的單向批量數(shù)據(jù)傳輸?shù)膶嶋H吞吐量。在客戶機到服務(wù)器的情況下，被測系統(tǒng)(SUT)充當發(fā)送器，在服務(wù)器到客戶機的情況下，SUT充當接收器；有必要測量兩個方向，因為TCP有不同的發(fā)送和接收代碼路徑。這三種配置在發(fā)送和接收方向上都達到9.3 Gbps，非常接近因為包頭而產(chǎn)生的9.41 Gbps的理論極限。

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

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

圖2 TCP批量傳輸效率

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

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

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

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

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

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

3.7 塊I/O—fio?

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

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

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

圖4 采用fio的存儲配置

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

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

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

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

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

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

我們還注意到，這種硬件配置在順序I/O中應(yīng)該能夠超過1.5 GB/s，在隨機I/O中應(yīng)該能夠超過35萬IOPS，因此即使是裸機情況下也有很大的未發(fā)掘的潛力，而我們在借用硬件時沒有設(shè)法利用這些潛力。

3.8 Redis?

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

在我們的評估中，我們選擇了Redis，因為它的高性能，豐富的API和廣泛使用的PaaS提供商(例如Amazon Elasticache，谷歌計算引擎)。我們從主要的GitHub倉庫中獲得了Redis 2.8.13，并在我們的Ubuntu 13.10平臺上構(gòu)建了它。

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

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

圖8 在多個部署場景的NoSQL Redis性能評估(請求/秒)，每個數(shù)據(jù)點是10次運行的算術(shù)平均值。

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

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

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

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

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

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

3.9 MySQL

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

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

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

雖然MySQL訪問文件系統(tǒng)，我們的配置有足夠的緩存，它幾乎沒有執(zhí)行實際的磁盤I/O，使得不同的KVM存儲選項沒有意義。

表3 MySQL配置

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

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

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

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

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

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

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

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

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

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

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

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

3.10 討論

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

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

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

四、相關(guān)工作

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

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

操作系統(tǒng)級虛擬化也有很長的歷史。在某種意義上，操作系統(tǒng)的目的是虛擬化硬件資源，以便共享它們，但是由于文件系統(tǒng)、進程和網(wǎng)絡(luò)的全局名稱空間，Unix傳統(tǒng)上提供了較差的隔離。基于容量的操作系統(tǒng)由于沒有任何全局名稱空間而提供了類似容器的隔離，但它們在20世紀80年代從商業(yè)上消失了。Plan 9引入了每個進程的文件系統(tǒng)名稱空間和bind掛載，啟發(fā)了支持Linux容器的名稱空間機制。

Unix chroot()特性長期以來一直用于實現(xiàn)基本的“監(jiān)獄”，而BSD監(jiān)獄特性擴展了這個概念。Solaris 10在2004年引入并大力推廣了Zones，這是一種現(xiàn)代的容器實現(xiàn)。云提供商Joyent從2008年開始提供基于zone的IaaS，盡管對整個云市場沒有影響。

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

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

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

過去VM與容器的比較大多使用舊軟件，如Xen和樹外容器補丁。

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

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

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

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

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

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

我們還質(zhì)疑在VM中部署容器的做法，因為與直接在非虛擬化Linux上部署容器相比，這會增加VM的性能開銷，而沒有任何好處。如果必須使用VM，那么在容器中運行VM可以創(chuàng)建額外的安全層，因為利用QEMU的攻擊者仍然在容器中。

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

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