虛擬機比容器來得更輕盈，還更安全！

科技 11-19

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

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

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

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

過了這個臨界點，Docker開始比虛擬機略佔上風，因為即使由TinyX創建的閑置的最小Linux發行版也確實運行一些偶爾的後台任務。

虛擬機數量增加後，Xen擴展起來如何？瓶頸在哪裡？

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

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

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

不過基於Mini-OS製作你自己的unikernel鏡像需要較大的工作量，許多人可能沒準備好，於是幾位作者還構建了Tinyx。

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

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

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

比較了幾種來賓的域實例化和啟動時間。如果是小巧來賓，實例化在啟用新虛擬機時出現的延遲中佔了大頭

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

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

對虛擬機創建的開銷細分後表明，與XenStore的交互和虛擬設備的創建是兩大開銷。

XenStore交互和設備創建佔了大頭。其中，設備創建的開銷相當穩定，但是XenStore開銷呈超線性增加。

LightVM的設計

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

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

LightVM重新設計了Xen控制平面，使用一種名為noxs（意為「noXenStore」）的精簡驅動程序來取代XenStore，並允許前端驅動程序和後端驅動程序之間通過共享內存來直接聯繫。

LightVM架構顯示了noxs、x1的替代者（chaos）、splittoolstack及配套的守護進程以及負責迅速為軟體交換機添加虛擬介面的xendevd

LightVM還備有一批預先準備好的虛擬機外殼，通過這些外殼，所有虛擬機共有的所有處理都在後台完成。虛擬機創建命令發出後，一個符合該虛擬機需求的合適的外殼從這批外殼中取出，只需要完成最後的初始化步驟，比如將內核鏡像載入到內存和完成設備的初始化。

標準Xen中的設備創建最後調用bash腳本，這是個緩慢的過程。LightVM換成了執行預定義設置的二進位守護程序，沒有forking或bash腳本。

性能

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

unikernel的內存使用非常接近Docker容器，Tinyx需要更多內存，但面對1000個來賓只需要多22GB。這只是當前伺服器內存容量的一小部分。

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

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

使用場合

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

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

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

2. 移動邊緣計算中的即時服務實例化（類似於JITSU）。

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

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

一台過載機器上的輕量級計算函數服務時間（Minipython unikernel）

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

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

點擊放大查看～