我們可以在改善虛擬機的隔離的同時擁有容器的高效嗎？在這篇論文中，幾位作者研究了基于Xen的虛擬機性能的邊界。他們發(fā)現(xiàn)了啟動大量輕量級虛擬機（包括unikernel和最小Linux虛擬機）時出現(xiàn)的瓶頸，并消除了瓶頸。因而獲得的系統(tǒng)名為LightVM，并借助最小的unikernel鏡像，可以在短短4ms內(nèi)啟動虛擬機。相比之下，Linux上的fork/exec則需要大約1ms。在同一個系統(tǒng)上，Docker容器啟動需要大約150ms。

64核機器上LightVM的啟動時間與Docker容器的啟動時間

這些結(jié)果是在LightVM來賓（guest）是unikernel的情況下獲得的。你可能只會在特殊情況下創(chuàng)建unikernel。（本文中一種頗有意思的例子是基于Micropython的unikernel，它可以用來支持serverless函數(shù)的執(zhí)行）。幾位作者還開發(fā)了一個名為TinyX的自動化構(gòu)建系統(tǒng)，用于創(chuàng)建旨在運行單個應(yīng)用程序的最小Linux虛擬機鏡像。如果我們比較一下TinyX虛擬機和Docker的啟動時間，性能非常接近于每個內(nèi)核大約250個虛擬機/容器。

unikernel來賓、Tinyx來賓與Docker容器三者的啟動時間

過了這個臨界點，Docker開始比虛擬機略占上風(fēng)，因為即使由TinyX創(chuàng)建的閑置的最小Linux發(fā)行版也確實運行一些偶爾的后臺任務(wù)。

虛擬機數(shù)量增加后，Xen擴展起來如何？瓶頸在哪里？

如下圖所示，限制虛擬化可伸縮性和性能的最大一個因素是來賓虛擬機的大小。為了制作該圖，從ramdisk啟動unikernel虛擬機，不同大小的二進制對象注入到未經(jīng)過壓縮的鏡像文件。所以所有影響與鏡像大小有關(guān)。

啟動時間隨虛擬機鏡像的大小呈線性增加

所以，如果我們想要快速啟動，我們知道鏡像大小會很重要。我們之前在The Morning Paper上見過unikernel，它們提供最小的來賓鏡像。在本文中，幾位作者使用Mini-OS創(chuàng)建諸多unikernel，包括實現(xiàn)返回當(dāng)前時間的一項TCP服務(wù)的“daytime”unikernel。大小是480KB（未經(jīng)壓縮），在3.6MB的內(nèi)存中運行。這個unikernel用于測試潛在虛擬機的內(nèi)存消耗的下限。

不過基于Mini-OS制作你自己的unikernel鏡像需要較大的工作量，許多人可能沒準(zhǔn)備好，于是幾位作者還構(gòu)建了Tinyx。

Tinyx是一種自動化構(gòu)建系統(tǒng)，可以創(chuàng)建旨在運行單個應(yīng)用程序的最小Linux虛擬機鏡像。實際上，該工具構(gòu)建的虛擬機包含基于Linux的最小發(fā)行版以及經(jīng)過優(yōu)化的Linux內(nèi)核。它在高度專業(yè)化的unikernel（擁有最佳性能，但需要將應(yīng)用程序移植到一款最小操作系統(tǒng)）與功能完備的通用操作系統(tǒng)虛擬機（默認情況下支持大量應(yīng)用程序，但是帶來了性能開銷）之間提供了一個中間點。

Tinyx創(chuàng)建的內(nèi)核鏡像大小只有典型Debian內(nèi)核的一半，運行時耗用的內(nèi)存卻少得多（Tinyx僅要1.6MB，Debian需要8MB）。

使用因而獲得的小巧虛擬機鏡像，我們可以在啟動大量虛擬機時探究Xen本身的行為。啟動1000個來賓時，以下是Debian最小安裝、Tinyx和MiniOS（unikernel）的啟動和創(chuàng)建時間，并在同樣硬件上進行了比較：Docker容器和簡單的進程創(chuàng)建。

比較了幾種來賓的域?qū)嵗蛦訒r間。如果是小巧來賓，實例化在啟用新虛擬機時出現(xiàn)的延遲中占了大頭

隨著我們不斷創(chuàng)建虛擬機，創(chuàng)建時間顯著延長（注意對數(shù)尺度）：創(chuàng)建第1000個Debian、Tinyx和unikernel來賓分別需要42s、10s和700ms。

虛擬機變小后，創(chuàng)建時間在獲得可用性所需的總時間中占了更大的比重。為了了解所有時間用在那里，研究團隊測量了Xen，得出了這張圖片：

對虛擬機創(chuàng)建的開銷細分后表明，與XenStore的交互和虛擬設(shè)備的創(chuàng)建是兩大開銷。

XenStore交互和設(shè)備創(chuàng)建占了大頭。其中，設(shè)備創(chuàng)建的開銷相當(dāng)穩(wěn)定，但是XenStore開銷呈超線性增加。

LightVM的設(shè)計

我們的目標(biāo)是讓虛擬機啟動時間與進程啟動時間相當(dāng)。Xen不是為這個目標(biāo)而設(shè)計的，正如前面的結(jié)果顯示的那樣，這些問題的根源遠非代碼效率低下那么簡單。比如說，XenStore的一個基本問題是類似文件系統(tǒng)的集中式API，它在虛擬機創(chuàng)建和引導(dǎo)過程中太慢了、無法使用，需要幾十次中斷和越過權(quán)限域（privilegedomain）。

我敢打賭，這種設(shè)計第一次搞出來時，很難想象有人啟動1000個來賓虛擬機。

LightVM重新設(shè)計了Xen控制平面，使用一種名為noxs（意為“noXenStore”）的精簡驅(qū)動程序來取代XenStore，并允許前端驅(qū)動程序和后端驅(qū)動程序之間通過共享內(nèi)存來直接聯(lián)系。

LightVM架構(gòu)顯示了noxs、x1的替代者（chaos）、splittoolstack及配套的守護進程以及負責(zé)迅速為軟件交換機添加虛擬接口的xendevd

LightVM還備有一批預(yù)先準(zhǔn)備好的虛擬機外殼，通過這些外殼，所有虛擬機共有的所有處理都在后臺完成。虛擬機創(chuàng)建命令發(fā)出后，一個符合該虛擬機需求的合適的外殼從這批外殼中取出，只需要完成最后的初始化步驟，比如將內(nèi)核鏡像加載到內(nèi)存和完成設(shè)備的初始化。

標(biāo)準(zhǔn)Xen中的設(shè)備創(chuàng)建最后調(diào)用bash腳本，這是個緩慢的過程。LightVM換成了執(zhí)行預(yù)定義設(shè)置的二進制守護程序，沒有forking或bash腳本。

性能

我們在文章開頭看到了有許多鏡像的LightVM的啟動時間。此外，LightVM可以在30ms內(nèi)保存虛擬機，在20ms內(nèi)恢復(fù)虛擬機。而標(biāo)準(zhǔn)Xen分別需要128ms和550ms。

unikernel的內(nèi)存使用非常接近Docker容器，Tinyx需要更多內(nèi)存，但面對1000個來賓只需要多22GB。這只是當(dāng)前服務(wù)器內(nèi)存容量的一小部分。

虛擬機的CPU使用情況也與容器相當(dāng)，只要虛擬機經(jīng)過簡化，只包括必要的功能：

unikernel、Tinyx、Debian虛擬機和Docker的CPU使用情況

使用場合

幾位作者列出了LightVM +輕量級虛擬機大放異彩的四種不同的使用場合。

在所有下列場合下，使用容器將有助于提升性能，但會削弱隔離，而使用功能完備的虛擬機將提供與輕量級虛擬機同樣的隔離，但性能較差。

1. 每個移動用戶的個人防火墻在蜂窩基站或其附近的移動網(wǎng)關(guān)中運行（移動邊緣計算， MEC）。這里使用了ClickOSunikernel鏡像，8000個防火墻可在一臺64核AMD機器上運行，啟動時間為10ms。以這種方式在邊緣運行LightVM的一臺機器可以為蜂窩小區(qū)（cell）中的所有用戶運行個性化防火墻，而不會成為瓶頸。

2. 移動邊緣計算中的即時服務(wù)實例化（類似于JITSU）。

3. CDN處的高密度TLS終結(jié)，這需要內(nèi)容提供商的長期秘密密鑰。因此，不同內(nèi)容提供商的代理之間的強隔離頗受歡迎。

4. 創(chuàng)建輕量級計算服務(wù)，比如AWS Lambda。就這個使用場合而言，研究人員使用基于Micropython的unikernel來運行用Python編寫的計算。啟動和開始執(zhí)行一個函數(shù)需要大約1.3ms。如果有意給系統(tǒng)施加壓力，發(fā)送測試系統(tǒng)處理能力之外的更多請求，服務(wù)時間呈線性上升，直到大約800個虛擬機才停止線性上升。

一臺過載機器上的輕量級計算函數(shù)服務(wù)時間（Minipython unikernel）

我們介紹的使用場合表明，確實需要輕量級虛擬化，而且在獲得良好隔離的同時，還能獲得與容器同等或更好的性能。

谷歌云平臺博客上最近出現(xiàn)了一篇文章：《揭秘基于容器的安全vs基于虛擬機的安全：明文安全性》（https://cloudplatform./2017/08/demystifying-container-vs-VM-based-security-security-in-plaintext.html）。該文從一家長期以來運行基于容器的基礎(chǔ)設(shè)施的公司出發(fā)，闡述了容器安全和隔離方面一個值得關(guān)注的觀點。

點擊放大查看～