云計算提供了一個令人難以置信的計算平臺。用戶通過點擊幾下用戶可以以每小時不到10美分的價格租用在云中的服務器,節約了使用物理設備的所有相關時間,精力和前期成本。云供應商提供虛擬機(虛擬機),而不是物理計算機來實現低成本運營。云計算的關鍵是虛擬化軟件,被稱為虛擬機監視器(虛擬機M),用來模擬一臺物理機器。用戶們非常安全地使用相互的客戶虛擬機,而沒有意識到他們通常與許多人共享物理機(“主機”)。
**18.1 SnowFlock簡介**
云計算是敏捷組織的福音。對于使用物理服務器而言,用戶需要焦急地等待著緩慢的審批流程,批準購買服務器,下訂單,直至服務器出貨,然后安裝和配置操作系統(OS)和應用程序組。而云用戶不需要等待數周的購買流程,只專注過程控制,并可以在幾分鐘內創建一個新的獨立服務器。
不幸的是,云服務器很少是獨立的。在快速實例化和按次使用模式的帶動下,云服務器通常是在配置相似的服務器可變池中的一個實例,能夠執行動態和可擴展的并行計算,數據挖掘,或web等任務。因為需要多次從相同的靜態模板中啟動新的實例,商業云還不能兌現真正的按需計算的承諾。服務器實例化后,云用戶仍然必須管理群集成員及通過增加新的服務器來調整。
SnowFlock通過虛擬機克隆技術解決了這些問題,這就是我們所提出的云API調用。應用程序代碼經常通過一個系統調用接口調用OS服務,它現在也可以以同樣的方式通過類似的接口調用云服務。通過SnowFlock的虛擬機克隆技術,我們可以將資源分配,集群管理和應用程序邏輯可編程等諸多方面交織在一起,并作為一個單一的邏輯操作。
根據父虛擬機,虛擬機克隆技術實例化了云服務器的多個完全相同副本。從邏輯上講,克隆的虛擬機繼承了其父節點的所有狀態,包括操作系統和應用程序級緩存。此外,虛擬機的克隆都將被自動添加到一個內部私有網絡中,從而有效地加入了這個動態可擴展的群集。新的計算資源,被封裝為相同的虛擬機,從而可以按需動態創建。
就實際使用而已,虛擬機克隆技術是可用,高效,而且快速的。在這一章中,我們將描述SnowFlock中對虛擬機克隆技術的實現,包括如何有效地在多個不同的編程模型和框架實現克隆, 如何在應用程序運行時使服務器的開銷最少,以及如何在5秒或更少的時間內來創造幾十個新的虛擬機,等等。
SnowFlock非常靈活,能夠使用C, C + +,Python和Java的API來實現虛擬機克隆的程序控制。我們已經成功地將SnowFlock移植到多個不同系統的原型實現中。在并行計算中,我們通過精確克隆技術有效地分擔了在許多物理主機的負載,并取得了良好的效果。對于在一個專用的服務器集群上運行的使用了消息傳遞接口(MPI)的多個并行應用,需要修改MPI的啟動管理器,從而提供了良好的性能和更少的開銷,并且不需要修改應用就能夠在每個新的克隆集群上運行。最后,在一些完全不同的應用案例中,我們使用SnowFlock來提高彈性服務器的效率和性能。今天,基于云服務的新業務一般需要啟動新的服務器。而通過克隆運行中的虛擬機,SnowFlock帶來了新的服務器功能。由于克隆的虛擬機繼承他們的父節點的熱緩沖區,從而使性能迅速達到峰值,使上線速度快了20倍。
**18.2 虛擬機克隆**
顧名思義,虛擬機克隆與父虛擬機幾乎是相同的。實際上,還是有一些輕微且必要的差異的,例如避免MAC地址沖突等問題,但我們會稍后討論。創建一個整個本地磁盤和內存狀態的虛擬機克隆是必須的,這也是我們第一個主要的設計權衡:應該如何按需復制前端的狀態?
實現虛擬機克隆最簡單的方式是采用標準的虛擬機“遷移”能力。通常情況下,遷移是指將運行中的虛擬機服務移動到不同的主機上,例如如當主機超載或需要維修的情況下。但是,因為虛擬機是純粹的軟件,所以可以被封裝在一個數據文件,然后將其復制到一個新的主機上,在短暫中斷后重新執行。要做到這一點,現有的VMMS要包含一個“檢查點”來創建文件,該文件包括本地文件系統,內存映像,虛擬CPU(VCPU)寄存器等等。在遷移過程中,新啟動的副本替換原來的虛擬機,但這個過程是可以改變的,例如離開原來的虛擬機運行時可以產生一個虛擬機克隆。在這種所謂的“渴望”進程中,因為整個虛擬機處于狀態轉移前的執行狀態,所以整個虛擬機提供了最好的初始性能。這種復制的缺點是在開始執行前必須費力地復制整個虛擬機,這嚴重地影響了實例化的過程。
SnowFlock采用了另一種極端方式,即是延遲狀態復制。不再復制全部虛擬機,而是復制虛擬機轉移時所需得重要數據,在虛擬機轉移后,SnowFlock在復制克隆中所需的其他數據。這有兩個好處,首先,它最大限度地減少了工作量,盡可能實例化延遲加載。其次,它只復 制真正使用的狀態數據,實際上是提高了虛擬機克隆的效率。當然,這樣做的好處取決于克隆的行為,但少量的應用程序需要訪問內存和在本地文件系統的每個文件的每一頁時就效果不大了。
然而,延時復制的好處不是免費的。由于狀態轉移被推遲到最后,需要在狀態到達時,才能繼續執行克隆。在時間共享工作站內將內存交換到磁盤,而并行的應用程序從高延遲的數據源獲取狀態可能被阻塞。在SnowFlock的用例中,這些阻塞降低了克隆的性能,其嚴重程度取決于應用程序。對于高性能計算應用,我們已經發現這種退化的影響不大,但可能會首先克隆的數據庫服務器性能。應當指出的是,這是一個瞬態影響:在幾分鐘之內,大多數必要的狀態已被轉移且性能父節點匹配。
順便說一句,如果你熟悉虛擬機,你可能考慮在這里使用實時遷移的優化。實時遷移的優化,可以縮短原始虛擬機的暫停和恢復執行新副本之間的間隔。要做到這一點,虛擬機監視器(VMM)需要在父節點仍在運行時預拷貝它的狀態,從而使只有最近更改過的頁才遷移。這項技術不會影響之間的遷移要求和副本開始執行的時間間隔,因此不會降低虛擬機克隆的實例化延遲。
**18.3 SnowFlock的實現方法**
SnowFlock實現虛擬機克隆被稱為“虛擬機fork”,這就像標準的Unix系統調用fork一樣,但有幾個重要的差異。第一,系統調用fork是復制一個單一的進程,虛擬機fork重復整個虛擬機,包括所有的內存,所有的進程和虛擬設備,以及本地文件系統。第二,系統調用fork是產生在同一物理主機上運行的單個副本,虛擬機fork可以同時產生多個并行備份。最后,虛擬機可以被復制到不同的物理服務器,讓你迅速提高云服務的需要。
以下是SnowFlock中的核心概念:
? 虛擬化:虛擬機封裝了計算環境,使機器復制和云服務成為可能。
? 延遲傳播:直到需要的時候才復制虛擬機的狀態,虛擬機克隆在幾秒鐘內生成。
? 組播:諸多的虛擬機克隆有著類似的狀態需求。通過多播,幾十個虛擬機克隆可以盡快執行。
? 頁故障:當一個克隆使用了無效的內存空間,這一故障將觸發一個請求到父節點,直到所需的內存頁可用了,才繼續執行克隆操作。
? 寫復制(COW):在虛擬機克隆生成前,父虛擬機先保留一個當前內存和磁盤頁的副本,在保留虛擬機克隆所需的狀態同時可以繼續運行。
我們使用Xen虛擬化系統來實現的SnowFlock,所以弄清一些Xen的專用術語是非常有用的。在Xen環境中,VMM被稱為虛擬機管理程序,虛擬機被稱為域。在每臺物理機(主機)說,是一個特權域,稱為“域0(dom0),每個特權域能夠完整地訪問主機及其物理設備。如果虛擬機被用來控制額外的“訪問者”或“用戶”,則被稱為“域U”(domU)。
廣義而言,SnowFlock包括一套修改了的Xen虛擬機管理程序(使其在無效資源被訪問時能夠順利恢復),一組運行在dom0上的支持進程和系統服務包括無效虛擬機狀態的合作遷移,以及一些虛擬機克隆中OS修改,由六個主要組成部分 。
? 虛擬機描述器:這個小對象是虛擬機克隆的抽象描述,描述了需要開始執行的虛擬機基本框架。它沒有需要執行任何實際工作血肉。
? 組播分發系統(mcdist):這是父節點系統,能夠同時向所有克隆有效地發布虛擬機的狀態信息。
? 內存服務器進程:父節點服務器進程中維護了父節點狀態的多個副本,并使其根據需求通過多播mcdist發布給所有克隆。
? Memtap進程:一個虛擬機克隆端的進程,與內存服務器通信請求那些克隆所需要但又缺失的內存頁。
? 克隆提示器:運行在克隆內的guest內核,通過為VMM提供線索來按需減少虛擬機狀態的遷移。盡管是可選的,卻是高效的。
? 控制棧:運行在每個物理主機上得守護進程,協調其他組件以及管理SnowFlock的父節點和虛擬機克隆。
圖18.1:SnowFlock 虛擬機復制架構
如圖所示,圖18.1描繪克隆一個虛擬機的過程,主要有四個主要步驟:(1)暫停父虛擬機并產生一個虛擬機描述器;(2)將虛擬機描述器分發到所有目標主機(3)克隆初始化;(4)按需加載狀態。該圖還描述了使用mcdist 進行組播分發的方法,并取通過訪問啟示避免相關問題 。
如果你有興趣嘗試SnowFlock,這里有兩種方法。多倫多大學SnowFlock研究項目組提供了文文檔和開放的源代碼1, . 如果您愿意采用一個工業化的版本,可以從GridCentric公司2 獲得一個免費的非商業許可證.由于SnowFlock包括hypervisor的修改和dom0的訪問的,所以安裝SnowFlock需要對主機的訪問權限。出于這個原因,你需要使用自己的硬件,將不能使用如亞馬遜的EC2云環境等商業云服務。
在接下來的幾節中,我們將描述瞬時實現和高效克隆的協同工作。我們將所以地內容結合在一起,如圖18.2所示 。
圖18.2:SnowFlock的的軟件組件
18.4 構建虛擬機描述器
SnowFlock的設計關鍵是決定推遲虛擬機的狀態復制到一個延遲運行操作。換句話說,復制虛擬機的內存是后期綁定操作,從而為優化的許多機會。
第一步的設計決定是生成虛擬機狀態的架構描述器。這是將用于創建克隆虛擬機的種子。它包含了創建一個虛擬機的最低必要條件,使其可以被調度。顧名思義,這一必要條件是由架構規范所需要的數據結構組成。在SnowFlock中,該架構是Intel x86處理器和Xen的結合。因此,架構的描述包含數據結構,如頁表,虛擬寄存器,設備元數據,wallclock時間戳等.我們推薦有興趣的讀者可以參考[LCWB +11 ]架構描述器的內容來深入理解。
一個架構描述器有三個重要的屬性:首先,它可以在短時間內創建200毫秒的情況并不少見。其次,它是小的,通常是小于原虛擬機的內存分配三個數量級(1 MB為1 GB的虛擬機)。第三,從一個描述符創建克隆虛擬機可以在一秒鐘之內(通常為800毫秒)。
當然,主要的時間開銷是從描述他們的記憶狀態創建克隆虛擬機全部的時間。以下各節我們說明如何解決這個問題,如何利用優勢,并提出優化的機會。
**18.5父節點組件**
一旦被克隆的虛擬機成為一個父節點, 就和所有其他父節點一樣,它需要為子節點提供克隆服務。父節點是通過維護一套內存和磁盤狀態,克隆的集會,為克隆虛擬機提供按需服務。
**18.5.1 memserver進程**
當創建架構描述器的時候,虛擬機將在進程中停止。這保證了虛擬機的內存狀態穩定;在暫停虛擬機并執行調度或取消調度前,內部OS驅動程序處于停頓狀態,從克隆可以重新連接到外部網絡。我們采取這種靜止狀態的優勢來創建一個“內存服務器”即memserver。
內存服務器將提供克隆虛擬機所需的所有父節點內存數據。內存轉移是以x86的內存頁(4字節)為粒度單位的。最簡單的形式是內存服務器等待來自克隆的內存頁請求,在一個時間上為一個克隆提供一個內存頁的轉移。
然而,這些需要轉移的內存在父虛擬機中需要繼續使用并執行。如果我們允許父節點去修改這個內存,那將會以損壞的內存內容克隆虛擬機:內存供應將是從不同的克隆點完成的,使克隆容易混淆。以破解內核的詞匯來說,這是一個堆棧信息跟蹤的問題。
為了克服這個問題,采用經典的操作系統概念來救援:Copy-on-Write, 即CoW memory.。通過輔助的Xen hypervisor,我們可以移除父虛擬機的所有內存頁寫入權限。當父節點試圖修改一個內存頁,將觸發硬件內存頁錯誤。Xen通過頁面的副本知道這種情況發生的原因。父虛擬機允許寫入到原來的頁面,并繼續執行,而被告知使用原來的副本,這就是保持只讀的內存服務器。在這種方式下,被克隆的內存狀態仍然凍結,且不混淆,而父節點能夠繼續執行。CoW的開銷是最小的:Linux使用了類似的機制,如創建一個新的進程。
**18.5.2 Multicast與Mcdist**
克隆通常存在被稱為“命運的決定”的問題。 我們希望創建克隆是為了一個單一的目的:例如,相對于Y調整一個數據庫的DNA中X鏈。此外,我們期望要創建一套克隆,使所有的兄弟姐妹做的一樣,也許對數據庫的不同部分對準相同的X鏈,或調整不同的鏈對準Y鏈,從而明確地表現為大量內存訪問的時間局部性:他們將使用相同的代碼和大部分常見的數據。
我們利用時間局部性,為SnowFlock量身定制了自己的組播分發系統—— mcdist。mcdist使用IP組播,同時為接收器集合分發相同的數據包。它利用網絡硬件并行處理的優勢減少了內存的服務器上的負載。因為所有克隆具有類似的內存訪問模式,通過對所有克隆的第一個要求發送一個應答,每個克隆的要求被作為它的兄弟姐妹預處理。
不像其他的組播系統,mcdist并不一定是可靠的,沒有以一個有序的方式提供數據包,也沒有以原子方式提供所有擬接收的應答。組播是嚴格意義上的優化,并確保克隆明確請求內存頁的需要。因此,該設計優雅簡單:簡單的服務器多播的響應,而因為客戶端超時,當克隆沒有收到一個請求的答復時重新請求。
SnowFlock的三個優化都體現在mcdist上:
? 一致性檢測:當時間局部性發生時,多個無差別請求都非常密切的繼承在同一頁。mcdist服務器忽略所有除第一個以外的請求。
? 流量控制:接收器的獲取率與請求相關。服務器的發送率取決于客戶端接受率的加權平均。否則,接收器將會淹沒在服務器發送過多的內存頁中。
? 游戲結束:當服務器已經發送了大多數頁面時,將回到單播響應。在這一時間點上的大多數請求是重試,從而通過網絡的內存頁轟炸所有克隆是不必要的。
**18.5.3虛擬磁盤**
SnowFlock的克隆,由于其短壽命和命運決定,很少使用的磁盤。SnowFlock 虛擬機的虛擬磁盤包括了二進制文件,庫和配置文件的根分區。通過合適的文件系統如HDFS 或PVFS 是完成大量的數據處理。因此,當SnowFlock克隆決定從他們的根磁盤讀取數據時,它們通常由內核的文件系統頁面緩存來滿足這樣要求。 盡管如此,我們仍需提供克隆的虛擬磁盤訪問,在一些罕見的實例中這種訪問需求是需要的。我們在這里采用了最小阻力路徑,依據內存復制的設計來實現虛擬磁盤訪問。首先,在克隆的時間里磁盤的狀態被凍結。父虛擬機保持以CoW的方式使用其磁盤:對存儲備份的寫操作被發送到單獨的位置,在磁盤克隆時也是不可改變的。二,磁盤的狀態將使用 mcdist組播到所有克隆,且具有相同的4 KB頁的粒度,并根據時間局部性完成相同的期望。第三,嚴格復制克隆虛擬機的磁盤狀態是短暫的:它存儲在一個文件中,當克隆被摧毀后被刪除。
**18.6克隆端組件**
克隆在從架構描述器創建時是空心彈,和我們一樣,他們需要從父母那里獲得很大的幫助才能長大:子虛擬機們遷出時要立即給家里打電話,他們發現很多需要的東西缺失,要求他們的父母馬上發送。
**18.6.1 memtap進程**
memtap進程連接到每個創建后的克隆,是一個克隆的生命線。它映射到克隆的所有內存并按需加載。通過Xen的hypervisor,它登記了一些關鍵的數據位:訪問克隆內存的權限被關閉,由第一次訪問一個內存頁造成的硬件故障由hypervisor路由到memtap進程。
在其最簡單的化身中,memtap進程只需簡單地要求內存的服務器處理錯誤內存頁,但也有更復雜的情況。首先,memtap助手使用了mcdist。這意味著,在任何時間點,任何頁面可以憑借已被另一個克隆的異步預取請求到達克隆。第二,我們允許SnowFlock虛擬機是多處理器的虛擬機。這就不那么有趣了。這意味著,在并行處理時存在同一頁的多個故障需要。第三,在以后的版本中,memtap助手可以明確地預取批量的內存頁,在缺乏保證情況下,以任何次序從mcdist服務器到達克隆。這些因素可能導致并發噩夢,我們遇到了所有這些問題。
內存頁位圖是整個memtap的設計中心。當處理架構描述器創建克隆虛擬機時,創建和初始化該位圖。該位圖是一個比特數組,其大小由虛擬機內存可容納的內存頁數量決定。英特爾處理器有方便的原子位互斥指令:設置了一個比特,或做一個測試和設置,可以保證原子發生與其他處理器在同一個盒子里。這使得我們在大多數情況下,從而提供不同的實體,在不同的保護域的訪問位圖以避免鎖:Xen管理程序,memtap進程,以及guest內核本身的克隆。
當Xen的處理由第一次訪問頁面產生的硬件頁錯誤時,它使用內存頁位圖來決定是否需要提醒 memtap。它還使用該位圖依賴于不在同一頁的多個虛擬處理器來隊列化memtap緩沖頁。當其緩沖區是滿的,或到達一個明確請求的內存頁時暫停虛擬機,位圖被用來丟棄那些已經到達的任何重復的已經存在內存頁。所需的任何剩余內存頁被復制到虛擬機的內存,并設置適當的位圖比特。
**18.6.2 明智的克隆,避免不必要的提取**
我們剛剛提到,運行于克隆內核的該內存頁位圖是可見的,并沒有鎖,需要修改。這給克隆提供了一個強大的“啟蒙”工具:它們可以防止通過修改位圖和假裝已經存在的是當前內存頁的抓取。這是非常有用的性能,在內存頁沒有完全覆蓋之前,他們都可以被安全使用。
恰好是一個非常普遍的情況,當發生這種情況,并獲取可避免。在內核中的所有內存分配(虛擬機alloc的使用 ,kzalloc,get_free_page,用戶空間的BRK,等等)最終處理內核頁分配器。內存頁通常由中間開始分配,管理細粒度塊要求是:slab分配器,glibc在一個用戶空間進程的malloc分配,等等。然而,無論是顯式或隱式的分配,一個關鍵的語法含義始終正確:沒有人關注內存頁中包含的內容,因為它的內容將隨時被覆蓋。為什么取這樣一個內存頁呢?沒有任何理由這樣做,實際經驗表明,避免這種獲取方式是極其有利的。
**18.7虛擬機克隆的應用程序接口**
到目前為止,我們都集中一個虛擬機有效克隆的內部機制。作為服務系統非常有趣,所以我們需要把注意力放在誰將使用這樣的系統:應用。
**18.7.1。API實現**
通過簡單的SnowFlock API(如圖18.1所示),應用程序可以利用虛擬機克隆。利用克隆的方式基本上是一個兩階段的過程。你第一次請求分配一個克隆實例,雖然依賴于系統策略的影響,分配的實例可能會小于所請求的內容。第二,你可以使用分配給你的虛擬機克隆。一個關鍵的假設是你的重點聚焦于虛擬機上一個操作。虛擬機克隆是適用于單一應用的虛擬機,如Web服務器或一個渲染工廠組件。如果你在一百多個桌面環境進程中的多個應用程序同時調用虛擬機克隆,你就頭大了。
sf_request_ticket(N) 請求分配n個克隆。返回一個分配M≤N 克隆的ticket。
sf_clone(ticket) 使用的ticket分配克隆。返回克隆ID,0≤ID
sf_checkpoint_parent() 準備一個檢查點?不可改變的父虛擬機,可用于以后任意創建克隆。
sf_create_clones(C,門票) 與sf_clone相同,只是使用檢查點?。在哪個對應點開始執行
sf_checkpoint_parent()時調用克隆。
sf_exit() 終止子克隆(1≤ID
sf_join(ticket) 父節點使用(ID = 0),塊,直到所有使用ticket的子節點調用sf_exit前一直處于阻塞狀態。在這一時間點上,所有的子節點都被終止和ticket被棄用。
sf_kill(ticket) 家長棄用ticket票,并立即殺死所有相關的子節點進程。
表18.1:SnowFlock虛擬機克隆API
API簡化了編組消息,同時傳遞給XenStore,Xen通過共享內存的低吞吐量接口來控制平面交易。在hypervisor上運行的一個SnowFlock本地守護進程(SFLD)執行監聽這樣的請求,包括消息解組,執行,并要求回調。
通過API,程序可以直接控制虛擬機的克隆。API編程語言包括C,C + +,Python和Java。我們既可以使用shell腳本執行程序,也可以使用所提供的命令行腳本。并行框架(如MPI)可以嵌入到API中:MPI程序就可以使用SnowFlock了,且并不需要修改源代碼。置于Web服務器或應用服務器前的負載平衡器可以使用API克隆他們所管理的服務器。
SFLDs協調虛擬機克的隆執行請求。他們創建和傳輸架構描述器,創建克隆的虛擬機,啟動磁盤和內存的服務器,并啟動memtap輔助進程。他們是分布在一個物理集群系統上負責管理虛擬機的一個微型發布系統。
SFLDs推遲分配的決策給一個集中SnowFlock的主守護進程(SFMD)。SFMD使用相應的集群管理軟件簡化了接口。我們沒有看到任何需求需要推倒重來,包括資源分配,配額,策略等,例如Sun的網格引擎或平臺的EGO等都是適合的。
**18.7.2必要的突變**
克隆后,大多數克隆的虛擬機進程不再是父節點,而且他們現在運行在一個副本上。在大多數情況下,這是正常的,沒有問題。畢竟,操作系統的主要任務是從低層次的細節(如網絡標識)隔離應用程序。然而,平穩過渡需要一套有效的機制。如果管理在克隆的網絡身份以避免沖突和混亂,我們就必須引入在克隆過程中的輕微突變。此外,因為這些調整可能需要更高級別的權限,所以允許用戶配置一個鉤子程序來插入到任何必要的任務中,例如依靠克隆的身份安裝網絡文件系統。
克隆的產生有可能是不必要的。盡管父虛擬機可能是由DHCP服務器管理的網絡的一部分,或系統管理員通過其他各種途徑能夠做到克隆的IP地址分配。為了保持靈活的應用場景,我們將父節點和所有克隆置于虛擬的私有網絡中。從同一父節點的克隆都分配一個唯一的ID,他們的IP地址在這個私有網絡中被自動設置后,克隆的ID生效。這保證了不需要系統管理員的干預參與,而且沒有IP地址沖突。
我們通過一個鉤子程序在虛擬的網絡驅動程序直接對IP進行重新配置。然而,我們也催動驅動程序自動生成合成的DHCP響應。因此,無論你如何分發,虛擬的網絡接口將確保正確的IP地址傳播到客戶機操作系統,甚至當你重新啟動主機是都可以。
為了防止來自不同父母的克隆碰撞以及隔離彼此的虛擬專用網絡,可以防止相互DDoS攻擊克隆虛擬網絡的以太網(或第二層交換)。我們劫持了以太網MAC OUIs范圍3,奉獻他們的克隆。OUI將是一個父虛擬機的功能。像通過一個虛擬機的ID確定其IP地址一樣,這同樣決定了其非OUI的以太網MAC地址。虛擬的網絡驅動器具有將虛擬機的MAC地址轉換成它所分配虛擬機ID的功能,過濾出所有虛擬專用網絡與不同OUI們的流量。這種隔離是通過 ebtables簡單實現的。
讓彼此克隆間通信可能是有趣的,但不是情趣盎然。有時我們會想讓克隆響應來自互聯網的HTTP請求,或連接公共數據倉庫。我們為虛擬機的任何一套父節點和克隆配備一個專用的路由器。這個路由器的小虛擬機執行從克隆到互聯網的防火墻,節流和NAT的功能。這也限制了父虛擬機的接入連接和眾所周知的端口。路由器的虛擬機是輕量級的,但代表了網絡流量的集中化,從而嚴重限制了可伸縮性的單點。相同的網絡規則,可用于每個克隆虛擬機運行主機的一個分布式環境。我們還沒有發布這個實驗室補丁。
SFLDs分配了虛擬機ID,并指導虛擬網絡驅動程序應該如何配置自己內部的MAC和IP地址,DHCP指令,路由器虛擬機的坐標,過濾規則,等等。
**18.8結論**
通過調整Xen hypervisor和延遲轉移虛擬機的狀態,SnowFlock可以在幾秒鐘內產生幾十個運行中的虛擬機克隆。SnowFlock克隆虛擬機的瞬時性和熱加載極大地改善了自動化集群管理的可用性和為應用提供云資源的更大可編程性。SnowFlock也提高了云的靈活性,虛擬機實例加快了20倍,并通過利用他們的父節點內存中的操作系統和應用程序緩存提高了最新創建的虛擬機的性能。SnowFlock高效性能的關鍵是啟發式,避免了不必要的頁面抓取,組播系統,讓克隆們合作預取它們的狀態。它是巧妙應用了一些嘗試和真正的技術,一些技巧,以及一些工業界調試的慷慨幫助。
我們認識到整個SnowFlock經歷了兩個重要的教訓。首先是經常被低估的價值KISS定理。我們期待實現復雜的預取技術,以減輕一連串的內存頁在克隆啟動時會發出的請求。令人驚訝的是這也許沒有必要。該系統作為以一個單一原則為基礎的許多工作有很好的表現:只是帶來了超出需要的內存。簡單化的另一個例子是內存頁位圖。通過一個簡單的數據結構和清晰的原子訪問語義,這大大簡化了由于多個虛擬CPU,頁面更新的競爭,通過多播的異步頁到達等可能產生的并發性問題。
第二個教訓是規模不再是謊言。換句話說,你發現每次你都會碰到準備切換系統和新出現瓶頸的規模性問題。這是緊密聯系在一起的教訓:隨著負載的增加,簡單而優雅的解決方案使規模化隱藏了起來。這個原則的一個最好的例子是mcdist系統。在大規模的測試表明,一個以TCP / IP為基礎的頁面分配機制進行數百克隆時經常慘遭失敗。mcdist憑借其極端的分發機制和角色良好定義的獲得了成功:客戶只關心自己的內存頁,服務器只關心維持一個全局的流量控制。保持mcdist優雅簡單,使SnowFlock能夠擴展得非常好。
如果你有興趣了解更多,您可以訪問網站多倫多大學的網站1獲得在GPLv2授權許可下的學術論文和開放源碼,GridCentric 4為一個工業化的實現。
注:
1. http://sysweb.cs.toronto.edu/projects/1
2. http://www.gridcentriclabs.com/architecture-of-open-source-applications
3. OUI:MAC地址分配的范圍。
4. http://www.gridcentriclabs.com/
- 前言(卷一)
- 卷1:第1章 Asterisk
- 卷1:第3章 The Bourne-Again Shell
- 卷1:第5章 CMake
- 卷1:第6章 Eclipse之一
- 卷1:第6章 Eclipse之二
- 卷1:第6章 Eclipse之三
- 卷1:第8章 HDFS——Hadoop分布式文件系統之一
- 卷1:第8章 HDFS——Hadoop分布式文件系統之二
- 卷1:第8章 HDFS——Hadoop分布式文件系統
- 卷1:第12章 Mercurial
- 卷1:第13章 NoSQL生態系統
- 卷1:第14章 Python打包工具
- 卷1:第15章 Riak與Erlang/OTP
- 卷1:第16章 Selenium WebDriver
- 卷1:第18章 SnowFlock
- 卷1:第22章 Violet
- 卷1:第24章 VTK
- 卷1:第25章 韋諾之戰
- 卷2:第1章 可擴展Web架構與分布式系統之一
- 卷2:第1章 可擴展Web架構與分布式系統之二
- 卷2:第2章 Firefox發布工程
- 卷2:第3章 FreeRTOS
- 卷2:第4章 GDB
- 卷2:第5章 Glasgow Haskell編譯器
- 卷2:第6章 Git
- 卷2:第7章 GPSD
- 卷2:第9章 ITK
- 卷2:第11章 matplotlib
- 卷2:第12章 MediaWiki之一
- 卷2:第12章 MediaWiki之二
- 卷2:第13章 Moodle
- 卷2:第14章 NginX
- 卷2:第15章 Open MPI
- 卷2:第18章 Puppet part 1
- 卷2:第18章 Puppet part 2
- 卷2:第19章 PyPy
- 卷2:第20章 SQLAlchemy
- 卷2:第21章 Twisted
- 卷2:第22章 Yesod
- 卷2:第24章 ZeroMQ