虛擬機監(jiān)視器Xen和虛擬化技術(shù)（一）

2019-11-18 13:08:26

字體：大中小

供稿：網(wǎng)友

　　1. 引言
　　
　　現(xiàn)代計算機具有足夠強大的能力來利用虛擬化技術(shù)支持多個虛擬機（VM: virtual machines），并且在每個虛擬機上各自運行單獨的操作系統(tǒng)實例。這直接導致了虛擬機技術(shù)發(fā)展的又一個春天。在本文中，我們提出了Xen，一個高性能的用于資源治理的虛擬機監(jiān)視器（VMM: VM monitor）。Xen能夠支持的應用比如：server consolidation，co-located hosting facilities，distributed web services，secure computing platforms[12，16]和application mobility。
　　
　　成功地對一臺機器進行劃分，使它能夠支持多個操作系統(tǒng)的并發(fā)執(zhí)行，這個過程具有很多的挑戰(zhàn)。首先，虛擬機必須是彼此相隔離的：假如一個虛擬機的執(zhí)行會影響另一個的性能，這是不可以被接受的。這一點在操作各個虛擬機的用戶相互間并不信任的情況下顯得非凡重要。其次，它必須支持多種多樣的不同操作系統(tǒng)以提供給各種異構(gòu)（heterogeneity）的流行應用的支持（//這里的異構(gòu)指的是應用開發(fā)依托的操作系統(tǒng)不同，因此在實現(xiàn)上也就有很大差異，使得應用并不能夠跨平臺移植，因為Xen不需要對應用程序進行修改，那么它就必須支持各種常用的操作系統(tǒng)；所謂流行的應用，就是那些大家常用的、必需的應用）。第三，由虛擬化技術(shù)引入的性能開銷必須要小。
　　
　　Xen操控（//host：操作和控制）的是常用的操作系統(tǒng)，但是需要對操作系統(tǒng)中的某些相關(guān)部分進行一些修改。在本文中描述和評估的Xen原型系統(tǒng)能夠支持多個我們研發(fā)的Xenolinux guest OS實例的并發(fā)執(zhí)行；每個實例都給出了和非虛擬化情況下的Linux 2.4中相同的應用二進制接口。目前，我們對Windows xp到Xen的移植還沒有完全完成，但是已經(jīng)能夠運行簡單的用戶空間進程。移植NetBSD的工作也在進行中。
　　
　　Xen使得用戶能夠動態(tài)地實例化一個操作系統(tǒng)以執(zhí)行他們需要的應用。在XenoServer項目[15，35]中，我們在ISP或者Internet exchange（//布置在這些場合中經(jīng)濟劃算而且又具有戰(zhàn)略意義的地方）的標準服務(wù)器硬件上配置了Xen。我們在啟動一個新的虛擬機的時候需要執(zhí)行許可控制（admission control），希望每個虛擬機能夠以某種方式為它需要的資源付出代價。我們在其它文章中討論過我們在這個方向上的思路和方法[21]；現(xiàn)在這篇文章則將焦點關(guān)注于虛擬機。
　　
　　現(xiàn)在有一些方法用于構(gòu)建能夠在共享的機器上操控多個應用和服務(wù)器（//server：這里提到的server應該是大規(guī)模應用的意思，比如數(shù)據(jù)庫服務(wù)器）的系統(tǒng)。也許最簡單的方法就是部署一個或多個運行著標準操作系統(tǒng)（如Linux或者Windows）的主機，然后答應用戶們安裝文件和啟動進程— 應用間的保護是由傳統(tǒng)的操作系統(tǒng)技術(shù)提供的（//這里提到的做法，就是類似并行機性質(zhì)的，各個節(jié)點都是獨立的主機，但是一個應用可以在多個節(jié)點上面并行執(zhí)行）。實驗顯示：由于要針對各個脫節(jié)（//supposedly disjoint：邏輯上脫節(jié)，指的是應用不具有連貫性/兼容性，所以針對每個應用都要單獨配置一次，假如能想辦法將前后有關(guān)聯(lián)的應用放在一起執(zhí)行，可以大大減少相關(guān)的開銷，如配置開銷，通信開銷等等）的應用進行復雜的配置，這些配置過程導致的交互行為會使系統(tǒng)治理任務(wù)迅速成為時間消耗巨大的任務(wù)。
　　
　　更重要的是，這樣的系統(tǒng)不能夠充分地支持性能隔離；某個進程的調(diào)度優(yōu)先級，存儲要求，網(wǎng)絡(luò)通信量和磁盤訪問等等特征都會影響到其它進程的性能。假如是在資源供給充足而且用戶群體是限定（比如計算網(wǎng)格或者PlanetLab平臺實驗）的情況下，這個系統(tǒng)還是可以接受的。但是當資源是供不應求的時候，或者用戶間不相協(xié)作（//uncoOperative：不相協(xié)作，比如用戶間的需求有沖突，那么一定會互相影響的）的時候就不行了。一個解決這個問題的方法是改進對操作系統(tǒng)性能隔離的支持。這已經(jīng)在resource containers，Linux/RK，QLinux和SILK中被或多或少地實現(xiàn)了。這些方法中存在著一個難點是難以確保所有的資源都能夠正確地分配給有相應資源需求的進程。例如，緩沖區(qū)cache或者存儲頁面的替換算法導致的在應用間的復雜的交互行為（//比如存儲頁面替換的時候，某個進程的頁面替換序列會干擾到其它進程的，要免除這個影響就需要有復雜的機制用于進程間的協(xié)調(diào)）。這就是存在于操作系統(tǒng)中的“QoS干擾問題（QoS crosstalk）”。在低層采用多路執(zhí)行技術(shù)能夠緩解這個問題帶來的影響，這已經(jīng)在Exokerne和Nemesis操作系統(tǒng)中得到證實。在這些操作系統(tǒng)中，任務(wù)間無意識的或者不受歡迎的交互行為被最小化了。
　　
　　我們使用了同樣的基本方法來構(gòu)建Xen。Xen就是以整個操作系統(tǒng)的粒度復用物理資源，它能夠提供在操作系統(tǒng)間的性能隔離。相對于進程級的資源復用，Xen要答應一定范圍內(nèi)的guest OS“和平”共存，而并非去指定一個非凡的應用二進制接口（//假如限定了應用二進制接口，就意味著只能支持某個特定的操作系統(tǒng)）。為了獲得這種靈活性就必須付出一些代價 — 無論是在初始化過程（比如，boot和resume與fork和exec的比較）中，還是在資源消費上，運行一個完整的操作系統(tǒng)與運行一個進程相比分量都要重得多。
　　
　　為了達到我們的能夠支持多至100個被操控的操作系統(tǒng)實例的目標，我們認為這些代價是值得付出的。付出這些代價后獲得的系統(tǒng)答應單個用戶在資源受控的形式下，直接運行那些不需要修改的二進制代碼或者二進制代碼集合（例如，后端為PostgreSQL的Apache服務(wù)器）。更進一步的，因為用戶能夠動態(tài)地精確創(chuàng)建他們的軟件所需要的執(zhí)行環(huán)境，所以這個系統(tǒng)也就提供了在非常高的層次上的靈活性。另外，在各種服務(wù)和應用間的配置交互也是可以避免的（例如，每個Windows實例都有它們自己的寄存器文件）。
　　
　　本文的余下部分是這樣組織的：第2部分解釋了我們的虛擬化方法和Xen的工作概況。第3部分描述了我們的設(shè)計和實現(xiàn)的要害特征。第4部分給出了使用業(yè)界標準的測試程序評估運行在Xen上的XenoLinux與單獨的Linux，VMware Workstation和用戶模式Linux（UML）的性能比較結(jié)果。最后的第5部分討論了未來的工作并作了總結(jié)。

上一篇：如何把一圖畫變成圖形界面的背景

下一篇：怎樣用Java實現(xiàn)MSN Messager的功能